oracle数据库mount,急，数据库mount不上了！

Problem Description

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

This article helps to resolve problems with the error ora-600[kccsbck_first].

The ORA-600[kccsbck_first] error occurs when Oracle detects that another

instance has this database already mounted. For some reason, Oracle already sees

a thread with a heartbeat. This could be the expected behaviour if running OPS.

In such a case the parallel_server parameter needs to be set.

In cases where Parallel Server is not linked in, this is not the expected behaviour.

WHAT TO CHECK :

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

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 %ORACLE_HOME%/rdbms/log/alert_%ORACLE_SID%.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 8.1.5 instead of 8.0.5. The database

and software versions need to be synchronized.

2- You installed HACMP 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/clsif

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- 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 4:

-----------

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 4:

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

The new 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.

When "parallel_server=false" or not set in "init.ora", the instance will always

startup in exclusive mode.  The first instance will start up successfully, but

the second or subsequent OPS instances will fail. Make sure you can start up

all your Parallel Server instances in shared mode successfully.

5- 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 5:

-----------

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 5:

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

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.

6- 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 6:

-----------

- 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  <68281.1>68281.1>

- 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 6:

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

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.