Monday, March 25, 2013

Linux


Linux

Check number of CPU’s
$cat /proc/cpuinfo
Check memory information
cat /proc/meminfo
Check swap
$swapon -s
Kernel parameter
#/sbin/sysctl -a
cat /etc/sysctl.conf
System error log
/var/log/messages
Nic configuration
ifconfig -a
Useful Links-

11gR2 – SysAsm vs SysDba



SYSASM role was introduced in 11gR1 and was designed to administer ASM instances. In 11gR1 , if you connected with SYSDBA role , you used to get a warning which was only recorded in alert log (Refer to my earlier post here). But things have changed in 11gR2. While trying to dismount a Diskgroup, I found following errors


SQL> alter diskgroup flash_arc mount;alter diskgroup flash_arc mount*ERROR at line 1:ORA-15032: not all alterations performedORA-15260: permission denied on ASM disk group


Above error indicates that I do not have permission on the ASM Diskgroup.  As per 11gR2 documentation, SYSASM privilege is used for carrying out administration tasks on ASM Diskgroups. SYSDBA privilege can be used only for creating/deleting aliases and querying ASM dictionary views.  Frankly speaking, you should unlearn the habit of connecting as “/ as sysdba” to ASM instance and learn connecting as “/ as sysasm”

Solving ORA-1031 while connecting as “/ as sysdba”


Many times we see an issue like this:

SQL> conn / as sysdba
ERROR:
ORA-01031: insufficient privileges
This is a very common and frequent error that can occur after the new oracle software install
or due to some permissions changes at OS level.
I will dicuss the approach to solve ORA-1031 error on UNIX environment.
1. Check that oracle_sid and oracle_home are set correctly as:
$ echo $ORACLE_SID
$ echo $ORACLE_HOME
Find the values returned by above command and match these values under /etc/oratab file, these
have to be listed there.
EXAMPLE:
========
$ echo $ORACLE_SID
BSNL
$ echo $ORACLE_HOME
/u01/app/oracle/product/10.2.0/db_2
$ cat /etc/oratab
BSNL:/u01/app/oracle/product/10.2.0/db_2:N
VSNL:/u01/app/oracle/product/10.2.0/db_2:N
The values above are matching with /etc/oratab entries
If the oracle_sid and oracle_home are not set properly then set it as:
$ export ORACLE_SID=BSNL
$ export ORACLE_HOME=/u01/app/oracle/product/10.2.0/db_2
And try to connect as “/ as sysdba” It should work now.
If these are correct but still the error is coming then move to step 2.
2. Ensure TWO_TASK is not set
$ echo $TWO_TASK
If it return any lines as:
TWO_TASK=
OR
TWO_TASK=
Then unset the environment variable as:
$ unset TWO_TASK
Now try to connect as “/ as sysdba”
If these are correct but still the error is coming then move to step 3.
3.Check the permissions on the oracle executable file:
$ cd $ORACLE_HOME/bin
$ ls -la oracle
It should show the following permissions:
-rwsr-s–x 1 oracle oinstall 96725724 Apr 2 13:43 oracle
If its not the same then issue the following command to set the correct permissions:
$ chmod 6751 oracle
If these are correct but still the error is coming then move to step 4.
4. Check for the dba group at OS level. We need to make sure that Operating System users issuing / as sysdba belongs to dba group at OS level.
There is one file we need to check for this i.e $ORACLE_HOME/rdbms/lib/config.s OR $ORACLE_HOME/rdbms/lib/config.c (File name vary from OS to OS on some OS it is config.c and on some OS it is config.s). The value in these file is typically set to “dba” as:
.ascii “dba”
Login as oracle user:
# su – oracle
$ id
uid=111(oracle) gid=123(usdba)
Look for the gid value here.(usdba)
The gid value is usdba so we need to modify the config.c or config.s so that it should look like:
.ascii “usdba”
After making changes to config file relink oracle binaries as:
- Make sure that no oracle processes running
- Login as oracle
- Make sure LD_LIBRARY_PATH and ORACLE_HOME are set properly
$ORACLE_HOME/bin/relink all
If these are correct but still the error is coming then move to step 5.
5. Make sure that dba group at OS level only exists once in /etc/group file and that the users belonging to the dba group are properly comma separated.
Example:
usdba::123:oracle,oracle1
ii) Check that the oracle user uid and gid are same in /etc/group and /etc/passwd
If all these 5 settings are correct and still ora-1031 is coming then the only option is to take truss output and check while opening which file the error is coming.
e.g.
$ truss -aefo /tmp/truss.out sqlplus “/ as sysdba”
6. Ensure you are invoking sqlplus from correct ORACLE_HOME
This actually came as comment on this post and I would agree. Ensure that you are using sqlplus from correct ORACLE_HOME. To do this set
export PATH=$PATH:$ORACLE_HOME/bin
You can confirm the home using which sqlplus command

How To Change/Restore User Password in 11G



Oracle 11g introduces Case-sensitive passwords for database authentication. Along with this if you wish to change the password (temporarily) and reset it back to old , you will find that password field in dba_users is empty. Prior to 11g we could use following technique to change/restore password
SQL> create user amit identified by amit;

User created.

SQL> grant create session to amit;

Grant succeeded.

SQL> conn sys as sysdba
Enter password:
Connected.
SQL> select username,password from dba_users where username='AMIT';

USERNAME                       PASSWORD
------------------------------ ------------------------------
AMIT                           9DEC0D889E8E9A6B

SQL> alter user amit identified by abc;

User altered.

SQL> conn amit/abc
Connected.
SQL> conn sys as sysdba
Enter password:
Connected.
SQL> alter user amit identified by values '9DEC0D889E8E9A6B';

User altered.

SQL> conn amit/amit
Connected.
In 11g if you query password field, it will return NULL.
SQL> select username,password from dba_users where username='AMIT';

USERNAME                       PASSWORD
------------------------------ ------------------------------
AMIT
Let’s first see Case-sensitive password feature in 11g and then steps to change/restore passwords
SQL> create user amit identified by AMIT;

User created.

SQL> grant connect,resource to amit;

Grant succeeded.

SQL> conn amit/amit
ERROR:
ORA-01017: invalid username/password; logon denied

Warning: You are no longer connected to ORACLE.
SQL> conn amit/AMIT
Connected.
This behavior is controlled by “sec_case_sensitive_logon” initialization paramter. If the value is true then it will enforce case sensitive passwords
SQL> select NAME,VALUE from V$SPPARAMETER where NAME='sec_case_sensitive_logon';

NAME                                     VALUE
---------------------------------------- --------------------
sec_case_sensitive_logon                 TRUE

SQL> conn / as sysdba
Connected.
SQL> alter system set sec_case_sensitive_logon=false;

System altered.

SQL> conn amit/amit
Connected.
SQL> conn / as sysdba
Connected.
SQL> alter system set sec_case_sensitive_logon=true;

System altered.

SQL> conn amit/amit
ERROR:
ORA-01017: invalid username/password; logon denied

Warning: You are no longer connected to ORACLE.
SQL> conn amit/AMIT
Connected.
Now to reset the password in 11g, we need to query spare4 column in user$ table
SQL> select spare4 from user$ where name='AMIT';

SPARE4
--------------------------------------------------------------------------------
S:2D058976AE8FAD8ECFCDB93835ACEE94C83EDE19169209155BB81FEE7DBB

SQL> alter user amit identified by abc12;

User altered.

SQL> conn amit/abc12
Connected.
SQL> conn / as sysdba
Connected.
SQL> alter user amit identified by values 'S:2D058976AE8FAD8ECFCDB93835ACEE94C83EDE19169209155BB81FEE7DBB';

User altered.

SQL> conn amit/abc12
ERROR:
ORA-01017: invalid username/password; logon denied

Warning: You are no longer connected to ORACLE.
SQL> conn amit/AMIT
Connected.
As per Metalink Note 429465.1 , view DBA_USERS has new column PASSWORD_VERSIONS rendered as follows:
decode(length(u.password),16,'10G ',NULL)||NVL2(u.spare4, '11G ' ,NULL)
for example:

SQL> select USERNAME, PASSWORD_VERSIONS from dba_users where rownum <5 ------------------------------="" --------="" 10g="" 11g="" dip="" font="" outln="" password="" sys="" system="" username="">
In this case it means both old and new-style hash values are available for the users, the new hash value is stored in the USER$.SPARE4 column, as long as this remains NULL it means the password has not been changed since the migration and the user will have the old case insensitive password.
SQL> create user test identified by test;
User created.
SQL> select USERNAME, PASSWORD_VERSIONS from dba_users where username in (‘AMIT’,'TEST’);
USERNAME                       PASSWORD
—————————— ——–
AMIT                           11G
TEST                           10G 11G
As I had reset password using only spare4 string, password will be case -sensitive irrespective of setting for sec_case_sensitive_logon parameter value. i.e why we see value of “11G”  for user Amit.
Update
When resetting the password, we need to also query password column from user$ column if we wish to use case-insensitive feature in future. i.e In my above example I used only spare4 column value to reset the password. Now if I set sec_case_sensitive_logon=false , I will not be able to connect.
SQL> alter system set sec_case_sensitive_logon=false;

System altered.

SQL> conn amit/amit
ERROR:
ORA-01017: invalid username/password; logon denied
In case we wish to use both, we need to set identified by values ‘S:spare4;password’. As I didnot use password field while resetting, I find that password field in user$ is empty. To correct it, I had to change the password again.
SQL> select password,spare4 from user$ where name='AMIT';

PASSWORD                       SPARE4
------------------------------ ----------------------------------------------------------------------
                               S:2D058976AE8FAD8ECFCDB93835ACEE94C83EDE19169209155BB81FEE7DBB

SQL>  alter system set sec_case_sensitive_logon=true;

System altered.

SQL> alter user amit identified by AMIT;

User altered.

SQL> select password,spare4 from user$ where name='AMIT';

PASSWORD                       SPARE4
------------------------------ ----------------------------------------------------------------------
9DEC0D889E8E9A6B               S:F5DEBF680433864AA5A744C2368D8677A120939D083D74A2F6E99C5952AE
So to reset the password, following needs to be used.
SQL> select password,spare4 from user$ where name='AMIT';

PASSWORD                       SPARE4
------------------------------ ----------------------------------------------------------------------
9DEC0D889E8E9A6B               S:F5DEBF680433864AA5A744C2368D8677A120939D083D74A2F6E99C5952AE

SQL> alter user amit identified by values 'S:F5DEBF680433864AA5A744C2368D8677A120939D083D74A2F6E99C5952AE;9DEC0D889E8E9A6B';

User altered.
Thanks to Laurent for pointing this. You can see his article for more information.You can use below code to get the password script
1select 'alter user '||name||' identified by values '''||password||''';' from userwhere spare4 is null andpassword is not null
2union
3select 'alter user '||name||' identified by values '''||spare4||';'||password||''';' from userwhere spare4is not null and password is not null;

Recovering database from ORA-01207


One of our database crashed due to filer crash. When we tried to start the database back, we got following errors
1ORA-01122: database file 43 failed verification check
2ORA-01110: data file 43: '/u07/oradata/orcl/test_idx_4m001.dbf'
3ORA-01207: file is more recent than control file - old control file
4ORA-1122 signalled during: ALTER DATABASE OPEN /* db agent *//* {1:43923:2704} */...
Searching for above errors, lead to posts where people were recommending recovery from backup controlfile and opening database with resetlogs.
This is not correct approach as none of archive/redo log files were lost and its issue of missing update in control file.
Correct solution would be to recreate controlfile and recover database. I am documenting steps used for recovering database
1. Mount database and take controlfile backup which will be used to recreate controlfile
1sqlplus / as sysdba
2startup mount
3alter database backup controlfile to trace as /home/oracle/backup_cntrl.sql';
2. Make a copy of this file and edit it so as to keep “create controlfile” with noresetlogs option
3. Shutdown the database and take cold backup (Always take backup of existing db before recovery)
4. Rename/remove the existing control files(can check control_files parameter from init.ora file)
5. If this is RAC, set cluster_database=false and start only one instance with startup nomount
6. Run the script to create controlfile
7. Issue “recover database”
8. Open database now
“Alter database open;”
Hope this helps!!!!!!!