Oracle database ora-00600[kjhn_post_ha_alert0-862] Cause analysis

Database version and Platform information

The database version is 10.2.0.1 and is above the 32-bit win 2003 SP2
ORACLE v10.2.0.1.0-production vsnsta=0
Vsnsql=14 vsnxtr=3
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0-production
With the partitioning, OLAP and Data Mining options
Windows Server 2003 Version V5.2 Service Pack 2
Cpu:2-type 586, 1 physical cores
Process affinity:0x00000000
Memory (avail/total): ph:2608m/3990m, ph+pgf:4511m/5871m, va:1242m/2047m
Instance NAME:ORCL
Database reports a large number of ora-600[kjhn_post_ha_alert0-862] errors
The Mmon process of the database reports a large number of ora-00600:internal error code, arguments: [kjhn_post_ha_alert0-862], [], [], [], [], [], [], [] Error
Wed June 03 21:50:40 2015
Restarting dead background process Mmon
Mmon started with pid=11, OS id=3804
Wed June 03 21:50:43 2015
Errors in file e:\oracle\product\10.2.0\admin\orcl\bdump\orcl_mmon_3804.trc:
Ora-00600:internal error code, arguments: [kjhn_post_ha_alert0-862], [], [], [], [], [], [], []

Wed June 03 21:50:49 2015
Errors in file e:\oracle\product\10.2.0\admin\orcl\bdump\orcl_mmon_3804.trc:
Ora-00600:internal error code, arguments: [kjhn_post_ha_alert0-862], [], [], [], [], [], [], []

Wed June 03 21:55:44 2015
Errors in file e:\oracle\product\10.2.0\admin\orcl\bdump\orcl_mmon_3804.trc:
Ora-00600:internal error code, arguments: [kjhn_post_ha_alert0-862], [], [], [], [], [], [], []

Wed June 03 21:55:49 2015
Errors in file e:\oracle\product\10.2.0\admin\orcl\bdump\orcl_mmon_3804.trc:
Ora-00600:internal error code, arguments: [kjhn_post_ha_alert0-862], [], [], [], [], [], [], []

Wed June 03 22:00:40 2015
Thread 1 advanced to log sequence 476
Current log# 1 seq# 476 mem# 0:e:\oracle\product\10.2.0\oradata\orcl\redo01. LOG
Wed June 03 22:00:44 2015
Errors in file e:\oracle\product\10.2.0\admin\orcl\bdump\orcl_mmon_3804.trc:
Ora-00600:internal error code, arguments: [kjhn_post_ha_alert0-862], [], [], [], [], [], [], []
Query corresponding trace file discovery
Ora-00600:internal error code, arguments: [kjhn_post_ha_alert0-862], [], [], [], [], [], [], []
Current SQL statement for this session:
Begin:success: = dbms_ha_alerts_prvt.check_ha_resources; End;
Manual execution of this procedure
sql> var success varchar2
Sql> begin
2:success: = sys.dbms_ha_alerts_prvt.check_ha_resources;
3 END;
4/

Pl/sql procedure successfully completed.

Sql> Print Success

SUCCESS

--------------------------------

N
Through the relevant information to obtain the following description
@ This check are triggered with FAN enabled in this instance and it seems to be
@ associated with a startup action. From the procedure itself which is called
@ This is a run-once Mmon (startup) action which supports instance down
@ Notification reliability. It does the folowing a) registers the current
@ Instance incarnation in recent_resource_incarnations$ if it's not already
@ there B) deletes recent_resource_incarnations$ records that don ' t apply to
@ This database. They may, e.g., have been copied from seed DB or from a former
@ DataGuard primary c) scans recent_resource_incarnations$ for instance
@ incarnations that are no longer alive, and submits instance down alerts for
@ them. If it good then return ' Y ' Else ' N ' (or error) if there is a
@ failure. That's failure is ' to ' to ' mmon, so ' it may retry ' this
@ action later. In the local instance I get a ' Y ' but in the customer ' s system
@ It fails with a ' N ' which seems related to the ORA-600 assert.

@ This function is kjhn_post_ha_alert0 () which was internal and does the real work of
@ Posting HA alerts. It is used by both Kjhn_post_ha_alert and
@ kjn_post_ha_alert_plsql. Its parameters are basically the same as those of
@ kjhn_post_ha_alert,other than the fact that it uses individual parameters
@ rather than the more easily extensible structure. Also the parameters passed
@ To it are the instance_name and the host_name which is the kernelized
@ implementation for posting HA alerts. Without actually has the arguments
@ The guess is this either the HOST_NAME or the instance_name raised in the
@ assert is null which triggered it.
The Mmon process attempts to invoke the associated program, then fails to get the correct value, returns N, and then always
Try, if you can't get back to Y, you will always report ORA-600, error. All three of these cases are related to the recent_resource_incarnations$ table.
The reason for this failure is that the error will be reported if the parameter host_name or instance_name null is found when the KJHN_POST_HA_ALERT0 function is invoked Mmon.

Processing methods

This problem has been documented as Bug 5173066 repeated the ORA-600 [kjhn_post_ha_alert0-862] from Mmon PROCESS.
The bug is fixed in 11.1.0.6. A workaround is available for the problem.
The bug was fixed in the 11.1.0.6
To implement the workaround, please execute the following steps as the SYS User:

1. Collect the following information and spool it to a file for your records.

A. Output of select * from V$instance
B. Show parameter instance_name
C. Set pages 1000
D. Select * FROM recent_resource_incarnations$

2. Create A backup table of recent_resource_incarnations$.

Sql> CREATE TABLE RECENT_RESOURCE_INC$BK as SELECT * from recent_resource_incarnations$;


3. Truncate recent_resource_incarnations$. Being sure to does this while the instance are up and running.
Don't issue this statement if a shutdown is pending.

sql> truncate TABLE recent_resource_incarnations$;


4. Perform a clean shutdown, followed by a startup.
Specific reference:
ORA-600 [kjhn_post_ha_alert0-862] continuously repeated in the Alert Log (Doc ID 401640.1)
Bug 5173066:repeated ORA-600 [kjhn_post_ha_alert0-862] from Mmon PROCESS