Monday, July 21, 2014

ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr] in Oracle 12C

Version:

DB: 12.1.0.1.0
OS: OEL 6, 64 bit

Issue:

The file system on which DB files were available crashed, resulting in a DB crash. The next DB startup is failing with Internal errors. DB is coming up to the mount stage only.

Error:

Database mounted.
ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [1],
[1895], [12597], [12603], [], [], [], [], [], [], []

Reason:

Because of the file system crash when DB was running,the data files became in accessible. This resulted in a "lost Write" into the Online RedoLogs. So the normal Instance Recovery procedure became impossible to happen causing the ORA-600 error.

Solution:

We can manually recover the DB by specifying the online redo thread at the time of crash if the full set of redo logs are available in the storage. 

Note: It is better to have a full backup of all the files before trying the steps.

1. Backup all DB files if possible

2. Identify the current log sequence group and file.

SQL> startup mount;

SQL> select GROUP#,STATUS from v$log;

    GROUP# STATUS
---------- ----------------
         1 INACTIVE
         3 INACTIVE
         2 CURRENT

SQL> select GROUP#,MEMBER from v$logfile;

    GROUP# MEMBER
---------  -----------------------
1   /u01/oradata/orcl/redo01.log  
2   /u01/oradata/orcl/redo02.log
3   /u01/oradata/orcl/redo03.log


Here Group# 2 is current. So I am going to pass it manually

3. Manually Recover the DB

SQL> recover database until cancel using backup controlfile;
ORA-00279: change 23977161 generated at 07/18/2014 07:00:59 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/product/121010/dbs/arch1_1895_847740493.dbf
ORA-00280: change 23977161 for thread 1 is in sequence #1895


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/u01/oradata/orcl/redo02.log
Log applied.
Media recovery complete.
SQL> alter database open resetlogs;

Database altered.

DB is now open.

Note: If the above step fails then the only option left is to restore/recover from latest backup.

Thursday, July 17, 2014

ORA-04036: PGA memory used by the instance exceeds PGA_AGGREGATE_LIMIT

Version:

DB: 12.1.0.1.0 EE

Issue:

Errors are obtained while running migration script in a 12C DB and the sessions are getting killed.

ORA-00028: your session has been killed
ORA-04036: PGA memory used by the instance exceeds PGA_AGGREGATE_LIMIT
PGA memory used by the instance exceeds PGA_AGGREGATE_LIMIT of 2048 MB

Reason:


From Oracle 12C, a new parameter called PGA_AGGREGATE_LIMIT sets a hard limit on the amount of PGA taken up by an instance.

The parameter pga_aggregate_limit, if not explicitly defined, defaults to the greater of these three numbers:
a) 2 GB
b) 3 MB times the value of the processes parameter
c) 2 times the value of the parameter pga_aggregate_target

SQL> show parameter pga_ag

NAME                                            TYPE                        VALUE
------------------------------------ -----------       ------------------------------
pga_aggregate_limit                       big integer                       2G
pga_aggregate_target                     big integer                       764M

When the overall PGA occupied by all the sessions in that instance exceed the limit, Oracle kills the session holding the most untunable PGA memory, releasing all PGA memory held by that session.

The error can be noticed in the alert log file and the incident would be reported in a trace file, where the current offending SQL can be found.

ORA-04036: PGA memory used by the instance exceeds PGA_AGGREGATE_LIMIT
Incident details in: /u01/app/diag/rdbms/orcl/orcl/incident/incdir_24367/orcl_ora_13239_i24367.trc

In trace file

----- Current SQL Statement for this session (sql_id=2fsstt9a4tqz7) -----


Solution:

One way is to go back to the previous (pre-12c) behavior. To do that set the value of pga_aggregate_limit to 0 and the parameter will not have any impact.

alter system set pga_aggregate_limit=0 scope=both;

Obviously another option is to set this value to a much higher value if you have enough physical memory in the server

alter system set pga_aggregate_limit=3072M scope=both;

Tuesday, July 1, 2014

Could not connect to asm due to following error ora-01031: insufficient privilege on RAC DB creation

Version: 

11.2.0.3.0 in RHEL 6

Scenario: 

A RAC DB creation on two nodes using DBCA.
Chose ASM as storage type in the Storage Type details screen of DBCA. But the disk groups those were created already were not visible.

Tried giving +DATA manually and clicked Next, and ended up getting the following error.


"Could not connect to asm due to following error ora-01031: insufficient privilege"

Verified from ASMCMD > lsdg command that all the disk groups were mounted.

Reason:

This was clearly a case of missing privilege as indicated by the error

Grid software owner was "grid" and DB S/W owner was "oracle". I missed to add "asmdba" as a secondary group to oracle user. 

[root@node1 app]# id oracle
uid=1901(oracle) gid=54321(oinstall) groups=8500(dba),8501(oper),54321(oinstall)


Solution:

Added asmdba as a secondary group to oracle. 

/usr/sbin/usermod -g oinstall -G dba,oper,asmdba oracle

[root@node1 app]# id oracle
uid=1901(oracle) gid=54321(oinstall) groups=8500(dba),8501(oper),9601(asmdba),54321(oinstall)

Took a new terminal session as "oracle" and re initiated DBCA.

This time the disk groups were displayed and chosen by default.