If you cannot recover data by yourself, ask Parnassusdata, the professional ORACLE database recovery team for help.

ERROR:              

 
VERSIONS:           
  versions 8.1.5 to 10.2
 
DESCRIPTION:

  We receive this error because we are attempting to be the first 
  thread/instance to mount the database and cannot because it appears that 
  at least one other thread has mounted the database already.

  We therefore abort the mount attempt and log this error.
 
ARGUMENTS:          
  Arg [a] thread number which has database mounted
  Arg [b] mount id of the thread
 
FUNCTIONALITY:      
  CONTROL FILE COMPONENT
 
IMPACT:             
  PROCESS FAILURE
  GENERALLY NON CORRUPTIVE - No underlying data corruption. Although see
                             Alert in Note:137322.1 for Tru64
 
SUGGESTIONS: 

  See article: Note:157536.1  ORA-600 [KCCSBCK_FIRST] What to check

  Reference Notes: 
  Note:137322.1  ALERT: Node panic or shutdown can cause partitioned 
                   cluster and database corruption 8.1.5 - 8.1.7 Tru64
  Note:139812.1  ORA-600 [KCCSBCK_FIRST] When starting up second instance
  Note:105904.1  ORA-600 [KCCSBCK_FIRST] After Failed Migration 805/816
       

  Known Issues:

NB	Prob	Bug	Fixed	Description
II	7360390	10.2.0.4.CRS04, 10.2.0.5, 11.1.0.7.CRS07, 11.2.0.1	Split brain in case of multi-failures (network and VD) / ORA-600 [kccsbck_first]
II	6117754	10.2.0.5, 11.1.0.6	OERI[kccsbck_rtenq] db instance fail to start after storage cable restore
–	3814603	10.1.0.4	OERI[kccsbck_first] from CSS problem with split brain resolution
P*	II	2646914	9.2.0.4	Linux: OERI:[KCCSBCK_FIRST] possible on node startup
P*	–	2695783	9.2.0.3	Win: OERI:[KCCSBCK_FIRST] possible if Oracle & CM restarted

PURPOSE

This article helps to resolve problems with the error ORA-600 [kccsbck_first]
after having read Note:139013.1 .

SCOPE

DETAILS

1- YOU TRY TO START THE INSTANCE YOU JUST CREATED
==============================================

sqlplus> startup

ORA-600 [KCCSBCK_FIRST]

The error is recorded only on the screen and no errors are reported in the alert.log.

Several other instances run fine on the box. None of them has a similar db_name. They all run different Oracle versions.

Solution 1:
———–

Make sure that the initSID.ora soft link points to the correct release location.

Explanation 1
————-

The initSID.ora in $ORACLE_HOME/dbs is pointing to a higher release of Oracle.
E.g., init.ora points to 11.2.0.2 instead of 11.1.0.7. The database and software versions need to be synchronized.

Refer also to : Note 730108.1 One Instance Of Two Node RAC Fails to Start with ORA-600 [kccsbck_first]

2- YOU INSTALLED HA/CMP SOFTWARE
=============================

List all cluster nodes with the following:

$ $ORACLE_HOME/bin/lsnodes

The following verification doesn’t show any error:

$ /usr/sbin/cluster/diag/clverify

Check HACMP interconnect network adapter configuration with the following:

$ /usr/sbin/cluster/utilities/cllsif

Adapter Type Network Net Type Attribute Node IP Address
pfpdb3 service pfpdb3 ether private pfpdb3 11.2.18.24
pfpdb4 service pfpdb4 ether private pfpdb4 11.2.18.3

The network parameter doesn’t match. It has to be identical for both adapters.

cllsif on a working configuration should look like this:

Adapter Type Network Net Type Attribute Node IP Address
pfpdb3 service pfpdb ether private pfpdb3 11.2.18.24
pfpdb4 service pfpdb ether private pfpdb4 11.2.18.3

Solution 2:
———–

Please change the HACMP interconnect network adapter configuration.

3- YOU ARE RUNNING ORACLE ON AN NT CLUSTER
=======================================

You encounter one the following errors:

ORA-00600: internal error code, arguments: [kccsbck_first],[1],[number]

– OR –

ORA-00600: internal error code, arguments: [KSIRES_1],[KJUSERSTAT_not attached]

The OPS database had been running for some time with no problems; therefore,
cluster and database configuration issues can be ruled out.

Rebooting the node itself also does not clear the problem.

Solution 3:
———–

Reboot the entire NT cluster.

Explanation 3:
————–

When the primary instance mounts the database, a lock is enabled that will
prevent other instances from mounting the database in exclusive mode. If there
is a problem with the status of this lock, Oracle will return either of these
errors until the entire cluster is rebooted and the locks are reinitialized.

4- YOU ARE MOUNTING SECOND INSTANCE WHEN OTHER INSTANCE IS RUNNING
===========================================================

Restarting instance while other instance is running fails.
Executing the following sql:

Alter database mount

you receive the following error code:

ORA-00600 [KCCSBCK_FIRST]

with stack: ksedmp ksfdmp kgesinv ksesin kccsbck kccocf kcfcmb kcfmdb

Explanation 4:
————–

See Bug:2646914 Linux: OERI:[KCCSBCK_FIRST] possible on node startup

5- CHECK THE PARAMETERS
=======================

You encounter these 2 errors:

ORA-00600: internal error code, arguments: [kccsbck_first],[1],[number]

– AND –

ORA-00439 “feature not enabled: %s”

Solution 5:
———–

Please check the “init.ora” to verify that the “parallel_server” option is not
set. Setting the parameter “Parallel_Server” to true in the “init.ora” of both
instances yields these errors.

You need to make sure you can start up all your Parallel Server instances in
shared mode successfully.

Explanation 5:
————–

The parameter “PARALLEL_SERVER” was introduced in 8.x. When this
parameter is set to TRUE, then the instance will always come up in shared
mode. In RAC the parameter CLUSTER_DATABASE must be set to TRUE
to allow the instances to come up in shared mode.

When “parallel_server=false” or “cluster_database=false”, or they are not set in
“init.ora” or spfile, the instance will always startup in exclusive mode. The first
instance will start up successfully, but the second or subsequent OPS/RAC instances
will fail. Make sure you can start up all your Parallel Server instances in shared mode
successfully.

6- ORA-600 [kccsbck_rtenq] TRYING TO START AN ORACLE PARALLEL SERVER DATABASE
===========================================================

ORA-600 [kccsbck_rtenq]

From the alert.log:

Mon Jan 31 08:48:41 2000
Errors in file /u01/app/oracle/admin/nps3/udump/ora_6676.trc:
ORA-00600: internal error code, arguments: [kccsbck _rtenq], [1],
[3775228464], [], [], [], [], []

When trying to start the second node in cluster, you encounter this
error:

ORA-600 [kccsbck_first]

Solution 6:
———–

Ensure the ‘oracle’ binary is the same across all nodes of the OPS cluster.
Specifically, check that the GROUPS are the same on each node.
For example:

Node jag2:
% ls -l oracle
oracle backup 28262400, Jan 31 1:15

Node jag1:
% ls -l oracle
oracle backup 28262400, Jan 31 1 :26

Logged in as the ‘oracle’ software owner…

Node jag1:
%id uid=1001, gid=13, groups=101 dba
Node jag2:
%id uid=1001, gid=13, groups =15 users, 101

Note that the primary GROUPS displayed for the oracle user are not the same
on each node of the cluster. Correct this and restart the OGMS to correct
the problem.

Explanation 6:
————–

It is assumed that the lock management/node monitor divides up the lock domain
by unix group id. Instances with the same dbname should belong to the same
lock domain, therefore the user which starts the instance must belong to
the same groups.

7- ON STARTUP AFTER DATABASE CRASHED
==============================

You are attempting to start your database after it crashed, and are
getting the following errors on startup mount:

skgm warning: Not enough physical memory for SHM_SHARE_MMU segment of size 000000000795a000

ORA-00600: internal error code, arguments: [kccsbck_first], [1], [3141290959]

Solution 7:
———–

– check if background processes for this SID are still running and kill them
with the unix kill command.

– check also if shared memory segments still exist for this instance and
remove them.

See Note:68281.1
and
Note:123322.1 SYSRESV Utility for instruction

– check also if the “sgadefSID” file exists in the “$ORACLE_HOME/dbs”
directory for the SID and remove it.

– check if OPS is linked in:
$ cd $ORACLE_HOME/rdbms/lib
$ ar tv libknlopt* | grep kcs
$ kcsm.o => OPS is linked in
$ ksnkcs.o => OPS is not linked in

Explanation 7:
————–

In most cases when a shutdown abort is issued for an instance, the background
processes will die. In this case they did not. There was not enough information
to determine why the database crashed and the Oracle background processes
continued to run. Other things to check for ,in this case, are shared memory
segments that are still running for the instance that crashed, and the “sgadefSID”
file existence in the “$ORACLE_HOME/dbs” directory for the SID that is receiving
the error.

See also ORA-600[KCCSBCK_FIRST]: ON STARTUP AFTER DATABASE CRASHED Note 1074067.6

8- ORA-600 [kccsbck_rtenq] DURING INSTANCE STARTUP OF AN INSTANCE ON RAC DATABASE
==============================================================

Refer to the following document for more details:
Startup (mount) of 2nd RAC instance fails with ORA-00600 [kccsbck_first]  Note 395156.1

Solution 8
—————

Make sure ‘db_unique_name’ is the same for all RAC instances using this database.

9- ON STARTUP WHEN DATABASE IS RESIDING ON NFS
==========================================

You are using NFS for datafile storage, without Real Application Clusters (RAC), and the mount point with the datafiles is using the ‘nolock’ NFS mount option. Then 2 nodes accidentally open the same database.
Problem occurs either at database startup or corruptions occur while it is up and will need recovery.

Solution 9
————–

Clear Stuck NFS Locks on NetApp Filer(s) .

For details see NetApp: Using ‘nolock’ NFS Mount Option with non-RAC Systems Results in Database Corruption  Note 430920.1

10- CORRUPT CONTROLFILE(S)
==========================

If the instance is setup with multiple control files check if the instance will start with any of the control files, one at a time. To do so edit the control_files parameter to point to one control file at a time and check if the instance will start.

If the instance starts then shut it down and replace the bad control files with a copy of this one. Then adjust the control_files parameter back to its original value and restart the instance.

Refer also to
Ora-00600 [kccsbck_first] Error Occuring On Alter Database Mount Exclusive Command Note 291684.1

11-ON STARTUP AFTER AN RMAN RESTORE

==============================

A restore (RMAN or other) has occurred … and now the controlfiles are in a new location

Upon attempted startup of the first instance in the cluster an ORA-600 [kccsbck_first] is signaled.

Explanation 10

============

The controlfiles no longer have the same name as the CONTROL_FILE entry in the parameter file (PFILE or SPFILE)

EXAMPLE:

FILE: initORCL.ora

*.control_files=’+DATADG/ORCL/controlfile/current.1710.827252719′,’+RECODG/ORCL/controlfile/current.13011.827252719′

FILE: RMAN_restore_output.txt

output file name=+DATADG/ORCL/controlfile/current.1849.828899339

output file name=+RECODG/ORCL/controlfile/current.18173.828899341

Solution 11

—————

Modify the parameter file such that the CONTROL_FILE parameter points to the location of the current control files