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

APPLIES TO:

Oracle Database – Standard Edition – Version 8.0.6.0 to 12.1.0.1 [Release 8.0.6 to 12.1]
Oracle Database – Enterprise Edition – Version 8.0.6.0 to 12.1.0.1 [Release 8.0.6 to 12.1]
Information in this document applies to any platform.

PURPOSE

This article provides information about error ORA-1578 and possible actions.

SCOPE

This note is intended for general audience as initial starting point for beginning diagnosis of ORA-1578.

DETAILS

Description

Error ORA-1578 reports a Physical Corruption within a block or a block marked as software corrupt.  Reference Note 840978.1 for Physical Corruption concept.

ORA-1578 – Solution (excludes NOLOGGING case)

• Main article describing corruption issues in different Oracle areas and Solutions:

Note 28814.1 Handling Oracle Block Corruptions in Oracle7/8/8i/9i/10g

Database in ARCHIVELOG mode

• • Repair the Block with RMAN Block Media recovery.  In order to repair a block causing ORA-1578 with Block Media Recovery, the database must be in archivelog mode.

Note 144911.1 RMAN : Block-Level Media Recovery – Concept & Example

Note 342972.1 How to perform Block Media Recovery (BMR) when backups are not taken by RMAN

Database in NOARCHIVELOG mode or there is not a valid backup:

• • Identify the segment producing ORA-1578:

NOTE 819533.1 How to identify the corrupt Object reported by ORA-1578 / RMAN / DBVERIFY

NOTE 472231.1 How to identify all the Corrupted Objects in the Database reported by RMAN

NOTE 836658.1 Identify the corruption extension using RMAN/DBV/ANALYZE etc. Main sections in Note 836658.1 to identify corrupt blocks causing ORA-1578 are:

RMAN – Identify Datafile Block Corruptions
DBVerify – Identify Datafile Block Corruptions

• • For INDEX segment type consider to recreate the index.

• • Drop the segment and recover it from a different source.  Or use the next options to recover the information from the current segment:

• • For TABLES the corrupt block can be skipped using DBMS_REPAIR and decide to create a new table using “Create Table As Select”:

Note 556733.1 DBMS_REPAIR script
Note 68013.1 DBMS_REPAIR example

• • A Datapump export with ACCESS_METHOD=DIRECT_PATH (default value) may also be used to skip the corrupt block, then the table may be truncated or dropped and imported.
  • Another option is to MOVE the table with “ALTER TABLE MOVE &TABLE_NAME” as the MOVE skips corrupt blocks causing ORA-1578; it is recommended to take a backup (e.g. datapump export before moving the table it).
  • Reference Note 28814.1 for additional cases.

ORA-1578 / ORA-26040 due to NOLOGGING

Error ORA-1578 can also be produced along with error ORA-26040 meaning that the block is corrupt due to a NOLOGGING operation after a recovery.

ORA-1578 / ORA-26040 due to NOLOGGING – SOLUTION

• Reference the next article to fix error ORA-1578 caused by NOLOGGING:

Note 794505.1 ORA-1578 / ORA-26040 Corrupt blocks by NOLOGGING – Error explanation and solution

ORA-1578 due to incorrect wallet in encrypted database

• Reference the next article for ORA-1578 caused by incorrect wallet:

Known Corruption issues caused by 3rd party Software Provider

• Reference the next document for 3rd party known issues causing corruption:

White Paper: Preventing, Detecting, and Repairing Block Corruption: Oracle Database 11g

Oracle Maximum Availability Architecture White Paper

You can restrict the list below to issues likely to affect one of the following versions by clicking the relevant button:

NB	Prob	Bug	Fixed	Description
	III	16776922	12.1.0.2, 12.2.0.0	ORA-1578/ORA-600 block corruption messages on the temporary data blocks
E	I	22228324	12.2.0.0	Enhancement to Avoid Block Memory Corruption being propagated to Disk by Direct Path (prevents future ORA-1578 / adds ORA-600[kcblco_2] )
	II	20437153	12.2.0.0	Unnecessary incident files after ORA-603 following CTRL-C or session kill on Global Temporary Tables
+	–	20144308	12.2.0.0	ORA-27086 or ORA-1182 RMAN May Overwrite a SOURCE Database File during TTS, TSPITR, etc when OMF is used in SOURCE. ORA-1578 ORA-1122 in SOURCE afterwards
	II	18323690	12.1.0.2, 12.2.0.0	ORA-600 [kcbz_blk_decrypt_failed] [2001] / ORA-1578. Logical Corrupt undo block code 2001 when decryption with incorrect wallet. Error message changed
	II	18252487	12.1.0.2, 12.2.0.0	ORA-1578 for an encrypted block (TDE) after master REKEY of incorrect wallet. Error message changed
E	I	17511071	12.1.0.2, 12.2.0.0	Datapump expdp silently skips corrupt block that produce ORA-1578 – This fix prints a warning message in export log when the corupt block is the first block
	II	17210525	12.2.0.0	ORA-1 on SYS.I_PLSCOPE_SIG_IDENTIFIER$ / ORA-600 [kqlidchg0] / ORA-1578 in SYSTEM or SYSAUX Tablespaces
	IIII	17437634	11.2.0.3.9, 11.2.0.3.BP22, 11.2.0.4.2, 11.2.0.4.BP03, 12.1.0.1.3, 12.1.0.2	ORA-1578 or ORA-600 [6856] transient in-memory corruption on TEMP segment during transaction recovery / ROLLBACK (eg: after Ctrl-C)
	I	20658524		A query using direct read may fail with ORA-1578 ORA-26040 due to former corrupt block version
	II	14828059	11.2.0.3.BP15, 11.2.0.4, 12.1.0.1	Wrong Results / False ORA-1578 in SuperCluster
	III	13804294	11.2.0.3.4, 11.2.0.3.BP07, 11.2.0.4, 12.1.0.1	Internal errors, corruptions, using pipelined function whose rows raise exceptions
P	I	12330911	12.1.0.1	EXADATA LSI firmware for lost writes
	I	11707302	11.2.0.2.3, 11.2.0.2.BP06, 11.2.0.3, 12.1.0.1	Corruption from ASM crash during rebalance diskgroup. Misplaced Blocks
	II	11659016	11.2.0.3, 12.1.0.1	ORA-1578 against recently create tablespace that once was encrypted
+	II	10209232	11.1.0.7.7, 11.2.0.1.BP08, 11.2.0.2.1, 11.2.0.2.BP02, 11.2.0.2.GIBUNDLE01, 11.2.0.3, 12.1.0.1	ORA-1578 / ORA-600 [3020] Corruption. Misplaced Blocks and Lost Write in ASM
*	III	10205230	11.2.0.1.6, 11.2.0.1.BP09, 11.2.0.2.2, 11.2.0.2.BP04, 11.2.0.3, 12.1.0.1	ORA-600 / corruption possible during shutdown in RAC
	I	9965085	11.2.0.3, 12.1.0.1	ORA-1578 / ORA-8103 Temporary table block corruption / space wastage from PDML – superseded
	III	9739664	11.2.0.2, 12.1.0.1	ORA-1578 / ORA-26040 MANUAL RECOVER marks block as corrupt NOLOGGING in even if LOGGING is enabled
+	III	9724970	11.2.0.1.BP08, 11.2.0.2.2, 11.2.0.2.BP02, 11.2.0.3, 12.1.0.1	Block Corruption with PDML UPDATE. ORA_600 [4511] OERI[kdblkcheckerror] by block check
	II	9407198	11.2.0.3, 12.1.0.1	“LOG ERRORS INTO” can cause ORA-600 [kcb***] or hang scenarios
*	II	9406607	11.2.0.1.3, 11.2.0.1.BP06, 11.2.0.2, 12.1.0.1	Corrupt blocks in 11.2 in table with unique key. OERI[kdBlkCheckError] by block check
*	III	8943287	11.2.0.2, 12.1.0.1	ORA-1578 corrupt block with AUTH SQL*Net strings
*	III	8898852	11.1.0.7.2, 11.2.0.1.1, 11.2.0.1.BP04, 11.2.0.2, 12.1.0.1	ORA-1578 Blocks misplaced in ASM when file created with compatible.asm < 11 and resized
	III	8885304	11.2.0.2, 12.1.0.1	ORA-7445 [ktu_format_nr] during RMAN CONVERT or Corrupt fractured block of UNDO tablespace datafile
*	III	8768374	10.2.0.5, 11.1.0.7.8, 11.2.0.1.BP11, 11.2.0.2, 12.1.0.1	RFS in Standby with a wrong location for archived log corrupting/overwriting database files when max_connections > 1
E	II	8760225	11.2.0.2, 12.1.0.1	Auto Block Media Recovery reports ORA-1578 on first query
	II	8731617	11.2.0.3, 12.1.0.1	ORA-1578 from DESCRIBE or CTAS even if table not accessed / ORA-959 from DBMS_STATS
E	II	8720802	10.2.0.5, 11.2.0.1.BP07, 11.2.0.2, 12.1.0.1	Add check for row piece pointing to itself (db_block_checking,dbv,rman,analyze)
E	II	8493978	11.2.0.2, 12.1.0.1	Reserve file descriptors for datafile access
	II	10025963	11.2.0.1.BP09, 11.2.0.2	Block corruption of LOB blocks with checksum value but block has checksum disabled
	II	8714541	11.2.0.2	ORA-1578 Corrupt Block in ASM with 0xbadfda7a after ASM block repair due to disk read error when ASM mirror is used
	I	13101288		ORA-600, corruption or check errors dropping a column in a OLTP compressed table
+	–	8354682	11.2.0.1	ORA-1578 – Blocks can be misplaced in ASM when there is IO error and AU > 1MB
+	III	8339404	10.2.0.5, 11.1.0.7.1, 11.2.0.1	ORA-1578 – Blocks can be misplaced in ASM during a REBALANCE
	–	8227257	11.2.0.1	ORA-1578 corruption found after media recovery on encrypted datafile
E	II	7396077	10.2.0.5, 11.2.0.1	RMAN does not differentiate NOLOGGING corrupt blocks that produce ORA-1578/ORA-26040
	–	6471351	10.2.0.5, 11.1.0.7, 11.2.0.1	ORA-1578 / ORA-26040 due to NOLOGGING after recovery despite of FORCE LOGGING
	II	6674196	10.2.0.4, 10.2.0.5, 11.1.0.6	OERI / buffer cache corruption using ASM, OCFS or any ksfd client like ODM
	–	5515492	10.2.0.3, 11.1.0.6	ORA-1578 corruption with Block Misplaced during ASM rebalance after IO error
E	–	5031712	10.2.0.4, 11.1.0.6	DBV enhanced to report NOLOGGING corrupt blocks with DBV-201 instead of DBV-200
+	–	4724358	11.1.0.6	ORA-27045 ORA-1578 ORA-27047 corruption caused by DBMS_LDAP
	–	4684074	10.2.0.2, 11.1.0.6	OERI:510 / block corruption (ORA-1578) with DB_BLOCK_CHECKING
	–	4655520	10.2.0.3, 11.1.0.6, 9.2.0.8	Block corrupted during write not noticed
	–	4411228	9.2.0.8, 10.2.0.3, 11.1.0.6	ORA-1578 Block misplaced with mixture of file system and RAW files
	II	4344935	10.2.0.4, 11.1.0.6	OERI from DML on TEMPORARY TABLE after autonomous TRUNCATE
	II	7381632	11.1.0.6	ORA-1578 Free corrupt blocks may not be reformatted when Flashback is enabled
	–	8976928	10.2.0.5	ORA-1578 caused by a former free corrupt block and remains unformatted
	I	8684999	10.2.0.5	ORA-1578 caused by a former free corrupt block and remains unformatted
+	–	3544995	9.2.0.6, 10.1.0.3, 10.2.0.1	LOB segments with “CACHE READS” generate no REDO even with the logging option
+	–	1281962	9.2.0.1	Media recovery after ORA-1578 on rollback can cause logical inconsistency
	–	589855	7.3.3.6, 7.3.4.1	ORA:1578 or ORA:8103 selecting invalid ROWID
	–	406863	7.3.3.4, 7.3.4.0, 8.0.3.0	ORA-1578 using PQ with heavy simultaneous INSERTS
P	–	707304	7.3.4.4	AIX: Resizing RAW datafile can corrupt a DB block
	–	603502	7.3.4.3, 8.0.4.4, 8.0.5.0	Possible Corruption if a session with LOOPBACK DB Links aborts.

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

Format: ORA-600 [4137]
VERSIONS:
versions 7.0 to 10.1

DESCRIPTION:

While backing out an undo record (i.e. at the time of rollback) we found a transaction id mis-match indicating either a corruption in the rollback segment or corruption in an object which the rollback segment is trying to apply undo records on.
This would indicate a corrupted rollback segment.

FUNCTIONALITY:

Kernel Transaction Undo Recovery

IMPACT:

POSSIBLE PHYSICAL CORRUPTION in Rollback segments

SUGGESTIONS:

Signalled during rollback (also rollback for consistent read). The consistency check that compares the transaction id of the transaction being rolled back against the transaction id in undo block being applied is failing.
A possible cause is a lost write to the undo segment.

The main approach is to identify the file containing the bad undo segment block and treat it as if the file is corrupt. Consult the trace file for this information.

If in archivelog mode, restore the file & roll forward.

If in Noarchivelog mode, restore from a cold backup taken before the error was reported.
Alternatively, you can look at dba_rollback_segs data dictionary view.

If the status column that describes what state the rollback segment is currently in is “needs recovery” then lookup the following article for posible solution.

NB Bug Fixed Description
8240762
10.2.0.5,
11.1.0.7.10,
11.2.0.1
Undo corruptions with ORA-600 [4193]/ORA-600 [4194] or ORA-600
[4137] / SMON may spin to recover transaction
671491 8.1.6.0 Rollback Segment corruption possible if RBS has > 32767 extents

ORA-600 [4137] []
Versions: 7.x – 10.x Source: ktur.c
===========================================================================
Meaning:
While backing out an undo record ktuko finds that the transaction
id (txid) in the header of the undo block doesn’t match the
txid in the transaction state object.
—————————————————————————
Argument Description:
No arguments are returned.
—————————————————————————
Diagnosis:
This is a similar kind of error to <OERI:4147>, and basically indicates some kind of corruption with the UNDO block.
The main approach is to identify the file containing the bad RBS block and treat the problem as if this file is corrupt. E.g., if in archivelog mode, restore and roll forward.
At the end of the day, this usually comes down to a lost write to the RBS so it is a corruption. The redo stream should be ok.
In the trace file, the transaction ids that do not match are dumped together with the undo block. In 9i and 10G there is also a redo dump for the block. The redo dump shows the file number.
If there is no redo dump, you can use the uba of the undo block and determine which file to restore and roll forward. See <SupTool:ODBA>.

Search for “buffer tsn” (Oracle8) or “buffer dba” (Oracle7) in the
trace file and find the UNDO block containing the bad transaction ID.
This is the file/block that needs to be recovered.
Here is the code that shows you two transaction IDs and which
is which.
10G:
if (!KXIDEQ(xid, &ubh->ktubhxid)) /* make sure the txid matches */
{
ksdwrf(“XID passed in =”);
KXIDDMP(xid);
ksdwrf(“\nXID from Undo block =”);
KXIDDMP(&ubh->ktubhxid);
ksdwrf(“\n”);
/* dump useg header diagnostics */
KTUR_DIAG_DUMP(&udes->ktusdbds);
/* dump undo block diagnostics */
KTUR_DIAG_DUMP(ubdes);
ksesic0(OERI(4137));
}
9i:
if (!KXIDEQ(xid, &ubh->ktubhxid)) /* make sure the txid matches */
{
ksdwrf(“XID passed in =”);
KXIDDMP(xid);
ksdwrf(“\nXID from Undo block =”);
KXIDDMP(&ubh->ktubhxid);
ksdwrf(“\n”);
KCLDLCK(ubdes->kcbdsafn, ubdes->kcbdsrdba, ubdes->kcbdscls);
kcradx(ubdes->kcbdsafn, KTSNINV, ubdes->kcbdsrdba, 0, 0, 3, (char *)0);
ksesic0(OERI(4137));
}
7.3 – 8.1.7
if (!KXIDEQ(xid, &ubh->ktubhxid)) /* make sure the txid matches */
{
ksdwrf(“XID passed in =”);
KXIDDMP(xid);
ksdwrf(“\nXID from Undo block = “);
KXIDDMP(&ubh->ktubhxid);
ksdwrf(“\n”);
ksesic0(OERI(4137));
}
Before 7.3:
The transaction IDs dumped in the file are in this order:
Expected txid
undo txid
if (!KXIDEQ(xid, &ubh->ktubhxid)) /* make sure the txid matches */
{
KXIDDMP(xid);
KXIDDMP(&ubh->ktubhxid);
ksesic0(OERI(4137));
}
Note: It is unlikely that we will be able to ‘repair/trace’ the corrupt
undo block. With this scenario we typically have two options:
o Assuming the redo is good, we can restore the database file
o Assuming the redo is good, we can restore the database file
and roll forward.
o As a last resort, use undocumented parameter (_offline_rollback_segment or
_corrupted_rollback_segment) and rebuild the database.
—————————————————————————
Articles:
Note:106638.1 Handling Rollback Segment Corruptions in Oracle7.3/8

ora-600 ora-600 ora-600 ora-600 ora-600 ora-600 ora-600
ora-600 ora-600 ora-600 ora-600 ora-600 ora-600 ora-600
4137 4137 4137 4137 4137 4137 4137 4137 4137 4137
4137 4137 4137 4137 4137 4137 4137 4137 4137 4137

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

ERROR:

VERSIONS:
  versions 10.1 and above



SUGGESTIONS:

  If the Known Issues section below does not help in terms of identifying
  a solution, please submit the trace files and alert.log to Oracle 
  Support Services for further analysis.

  Known Issues:

You can restrict the list below to issues likely to affect one of the following versions by clicking the relevant button:

qertbfetchbyrowid qertbfetchbyrowid qertbfetchbyrowid qertbfetchbyrowid qertbfetchbyrowid qertbfetchbyrowid

qertbfetchbyrowid qertbfetchbyrowid qertbfetchbyrowid qertbfetchbyrowid qertbfetchbyrowid qertbfetchbyrowid

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

SYMPTOMS

o Create controlfile fails with the following errors:

o Database duplication using RMAN fails with the following errors

CHANGES

The problem occurs if compatible parameter is set to 10.2 or higher

CAUSE

This is unpublished bug 4877360
Abstract: APPSST SRV 10G :ORA-600: INTERNAL ERROR CODE, ARGUMENTS: [KCCSCF_1], [9], [65732], [65535]

Problem is related to parameter MAXLOGHISTORY specified in create controlfile  command.  It’s complaining that maximum should  be 65535.

SOLUTION

A possible workaround is to manually recreate the control file, and change the maxloghistory set to 65535 or lower in the script.

The bug is fixed in 10.2.0.4 and 11.1.0.6 versions.

For some platforms a backport fix is available. Please check availability of Patch 4877360 on MOS.

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

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

ERROR:
ORA-600 [kccpb_sanity_check_2] [a] [b] [c]

VERSIONS:

Versions 10.2 to 11.2
DESCRIPTION:

This internal error is raised when the sequence number (seq#) of the current block of the controlfile is greater than the seq# in the controlfile header. The header value should always be equal to, or greater than the value held in the control file block(s).
This extra check was introduced in Oracle 10gR2 to detect lost writes or stale reads to the header.
ARGUMENTS:
Arg [a] seq# in control block header.
Arg [b] seq# in the control file header.
Arg [c]
FUNCTIONALITY:

Kernel Cache layer Control file component.

IMPACT:

INSTANCE FAILURE
PROCESS FAILURE
POSSIBLE CONTROLFILE CORRUPTION

ORA-00600: [kccpb_sanity_check_2] During Instance Startup

Symptoms

The database is getting the following errors on Startup:

ORA-00600: internal error code, arguments: [kccpb_sanity_check_2], [3621501], [3621462], [0x000000000]

Changes

In this case, the customer moved the box from one data center to another.

Cause
ORA-600 [kccpb_sanity_check_2] indicates that the seq# of the last read block is higher than the seq# of the control file header block.

This is indication of the lost write of the header block during commit of the previous cf transaction.

Solution

1) restore a backup of a controlfile and recover
OR

2) recreate the controlfile

OR

3) restore the database from last good backup and recover

NOTE: If you do not have any special backup of control file to restore and you are using Multiple Control File copies in your pfile/init.ora/spfile you can attempt to mount the database using each control file one by one. If you are able to mount the database with any of these control file copies you can then issue ‘alter database backup controlfile to trace’ to recreate controlfile.

ora-600 ora-600 ora-600 ora-600 ora-600 ora-600 ora-600
ora-600 ora-600 ora-600 ora-600 ora-600 ora-600 ora-600
kccpb_sanity_check_2 kccpb_sanity_check_2 kccpb_sanity_check_2 kccpb_sanity_check_2
kccpb_sanity_check_2 kccpb_sanity_check_2 kccpb_sanity_check_2 kccpb_sanity_check_2
kccpb_sanity_check_2 kccpb_sanity_check_2 kccpb_sanity_check_2 kccpb_sanity_check_2
kccpb_sanity_check_2 kccpb_sanity_check_2 kccpb_sanity_check_2 kccpb_sanity_check_2
kccpb_sanity_check_2 kccpb_sanity_check_2 kccpb_sanity_check_2 kccpb_sanity_check_2

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

PURPOSE
——-
This bulletin explains how to use the known hidden parameters such as
_OFFLINE_ROLLBACK_SEGMENTS and _CORRUPTED_ROLLBACK_SEGMENTS with undo segments
when
–> Automatic Undo Management is active : UNDO_MANAGEMENT=AUTO
–> Corrupted undo information prevents the database from being accessible :
undo segments like _SYSSMUn$ are in NEEDS RECOVERY status
–> Backup of RBS datafiles / archive redo log files are not available and
therefore no recovery is possible
Be aware that the use of _OFFLINE_ROLLBACK_SEGMENTS may lead to the recreation
of the database, depending on whether there were active transactions in the
dropped undo segments. If so, then this may lead to logical corruption, and
hence to the recreation of the database. (Refer Note:106638.1 that explains
how to check the transaction table : you can use the same SELECT statements)
Be aware that the use of _CORRUPTED_ROLLBACK_SEGMENTS requires the recreation
of the database.
SCOPE & APPLICATION
——————-
For all DBAs having to manage the recovery of databases with corrupted undo
segments.
Example of situations
———————
–> Situation 1
===========
After setting an UNDO datafile OFFLINE and shutting the database down
normally, the following errors occur :
SQL> show parameter undo
NAME TYPE VALUE
———————————— ———– ——————————
undo_management string AUTO
undo_retention integer 10800
undo_suppress_errors boolean FALSE
undo_tablespace string UNDOTBS1
SQL> select segment_name , status from dba_rollback_segs;
SEGMENT_NAME STATUS
—————————— —————-
SYSTEM ONLINE
_SYSSMU1$ ONLINE
_SYSSMU2$ ONLINE
_SYSSMU3$ ONLINE
…
_SYSSMU10$ ONLINE
11 rows selected.
SQL> alter database datafile ‘C:\ORANT\DB1\UNDOTBS01.DBF’ offline;
alter database datafile ‘C:\ORANT\DB1\UNDOTBS01.DBF’ offline
*
ERROR at line 1:
ORA-00603: ORACLE server session terminated by fatal error
In alert.log:
————
alter database datafile ‘C:\ORANT\DB1\UNDOTBS01.DBF’ offline
Thu Mar 07 16:52:55 2002
ORA-376 signalled during: alter database datafile ‘C:\ORANT\DB1\UNDOTBS01.DB…
Thu Mar 07 16:52:55 2002
Errors in file C:\ORANT\admin\DB1\bdump\db1SMON.TRC:
ORA-00376: file 2 cannot be read at this time
ORA-01110: data file 2: ‘C:\ORANT\DB1\UNDOTBS01.DBF’

In user trace file on NT:
————————
KCRA: start recovery buffer claims
*** 2002-03-07 17:13:32.000
KCRA: buffers claimed = 0/0, eliminated = 0
ORA-00376: file 2 cannot be read at this time
ORA-01110: data file 2: ‘C:\ORANT\DB1\UNDOTBS01.DBF’
In user trace file on Unix:

————————–
kssxdl: error deleting SO: 82af3fc0, type: 38, owner: 8320de58, flag: I/-/-/0x00:
ORA-00376: file 2 cannot be read at this time
ORA-01110: data file 2: ‘/filer/9.0.2/DB1/undotbs01.dbf’
–> Situation 2
===========
When RBS datafiles are in a RECOVER status, and no backup is available to
recover appropriately, you need to drop the UNDO tablespace.
In alert.log:
————
Successfully onlined Undo Tablespace 1.
Mon May 27 17:17:14 2002
SMON: enabling tx recovery
SMON: about to recover undo segment 1
SMON: mark undo segment 1 as needs recovery
SMON: about to recover undo segment 2
SMON: mark undo segment 2 as needs recovery
SMON: about to recover undo segment 3
SMON: mark undo segment 3 as needs recovery
…
Errors in file /oracle3/djeunot/DB1/udump/ora_19462.trc:
ORA-00376: file 2 cannot be read at this time
ORA-01110: data file 2: ‘/oracle3/djeunot/DB1/undotbs01.dbf’
Mon May 27 17:17:14 2002
Error 376 happened during db open, shutting down database
USER: terminating instance due to error 376
Instance terminated by USER, pid = 19462
ORA-1092 signalled during: alter database open…
–> Situation 3
===========
The datafile of the undo tablespace is removed.
The database is in NOARCHIVELOG mode.
$ rm undotbs01.dbf
SQL> update x.t set a=1;
update x.t set a=1
*
ERROR at line 1:
ORA-01115: IO error reading block from file 2 (block # 3)
ORA-01110: data file 2: ‘/oracle3/djeunot/DB1/undotbs01.dbf’
ORA-27091: skgfqio: unable to queue I/O
ORA-27072: skgfdisp: I/O error
Additional information: 2
At startup:
SQL> startup pfile=/oracle3/djeunot/DB1/pfile/initDB1.ora
ORACLE instance started.
Total System Global Area 235693108 bytes
Fixed Size 279604 bytes
Variable Size 167772160 bytes
Database Buffers 67108864 bytes
Redo Buffers 532480 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 2 – see DBWR trace file
ORA-01110: data file 2: ‘/oracle3/djeunot/DB1/undotbs01.dbf’
In alert.log
————
Tue May 28 14:53:37 2002
Errors in file /oracle3/djeunot/DB1/bdump/dbw0_23154.trc:
ORA-01157: cannot identify/lock data file 2 – see DBWR trace file
ORA-01110: data file 2: ‘/oracle3/djeunot/DB1/undotbs01.dbf’
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Actions
——-
————————————————
1/ | Set the following parameters in the init.ora |
————————————————
UNDO_MANAGEMENT=MANUAL
_OFFLINE_ROLLBACK_SEGMENTS=(_SYSSMU1$, _SYSSMU2$, _SYSSMU3$, …etc)
or
_CORRUPTED_ROLLBACK_SEGMENTS=(_SYSSMU1$, _SYSSMU2$, _SYSSMU3$, …etc)
Note:
To get the list of the _SYSSMUn undo segments to OFFLINE when the database
is not accessible, you can use the following :
$ strings system01.dbf | grep _SYSSMU | cut -d $ -f 1 | sort -u > listSMU

where system01.dbf is the name of the datafile for the SYSTEM tablespace.
** From this list, do not forget to rename the _SYSSMU9 to _SYSSMU9$ **
a/ If you keep UNDO_MANAGEMENT=AUTO, when you want to DROP the UNDO
tablespace, you get the following error:
SQL> drop tablespace undotbs including contents and datafiles;
drop tablespace undotbs including contents and datafiles
*
ERROR at line 1:
ORA-30013: undo tablespace ‘UNDOTBS’ is currently in use
though you may have dropped all undo segments.
b/ Be aware that the names of the undo segments do not start back at
_SYSSMU1$ once the tablespace has been dropped and recreated.
The names take the next sequence numbers: if the undo tablespace dropped
contained _SYSSMU1$ to _SYSSMU10$, then the creation of the new undo
tablespace generates undo segments whose names start at _SYSSMU11$.
c/ To know which one of the parameters _OFFLINE_ROLLBACK_SEGMENTS or
_CORRUPTED_ROLLBACK_SEGMENTS to use, refer to
@Note:106638.1 Handling Rollback Segment Corruptions in Oracle7.3 to 8.1.7
d/ Dumping the transaction table and undo for active transactions from undo
segments such as “_SYSSMUn$” is strictly the same procedure as defined in
the referenced note above.
———————
2/ | Open the database |
———————
a/ If the RBS datafiles are not missing, the database may open:
———————————————————–
SQL> startup
ORACLE instance started.
Total System Global Area 118560016 bytes
Fixed Size 451856 bytes
Variable Size 100663296 bytes
Database Buffers 16777216 bytes
Redo Buffers 667648 bytes
Database mounted.
Database opened.
SQL> select name, status, enabled, checkpoint_change# from v$datafile;
NAME STATUS ENABLED CHECKPOINT_CHANGE#
———————————- ——- ———- ——————
/oracle3/djeunot/DB1/system01.dbf SYSTEM READ WRITE 62315
/oracle3/djeunot/DB1/undotbs01.dbf RECOVER READ WRITE 62241
/oracle3/djeunot/DB1/users01.dbf ONLINE READ WRITE 62315
SQL> select SEGMENT_NAME, STATUS from dba_rollback_segs;
SEGMENT_NAME STATUS
———— —————-
SYSTEM ONLINE
_SYSSMU2$ NEEDS RECOVERY
_SYSSMU3$ NEEDS RECOVERY
…
b/ If the RBS datafiles are missing, the database does not open:
————————————————————
Use the _OFFLINE_ROLLBACK_SEGMENTS parameter to allow the undo segments to
be dropped once the database opened.
SQL> startup pfile=/oracle3/djeunot/DB1/pfile/initDB1.ora
ORACLE instance started.
Total System Global Area 235693108 bytes
Fixed Size 279604 bytes
Variable Size 167772160 bytes
Database Buffers 67108864 bytes
Redo Buffers 532480 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 2 – see DBWR trace file
ORA-01110: data file 2: ‘/oracle3/djeunot/DB1/undotbs01.dbf’
SQL> select * from v$recover_file;
FILE# ONLINE ONLINE_STATUS ERROR CHANGE# TIME
———- ——- ————- ————— ——- —-
2 ONLINE ONLINE FILE NOT FOUND 0

Before opening the database, OFFLINE DROP the missing datafiles :
SQL> alter database datafile ‘/oracle3/djeunot/DB1/undotbs01.dbf’
2 offline drop;
Database altered.
SQL> alter database open;
Database altered.
—————————————————–
3/ | The Undo Segments need to be individually dropped |
—————————————————–
SQL> drop rollback segment “_SYSSMU1$”;
Rollback segment dropped.
SQL> drop rollback segment “_SYSSMU2$”;
Rollback segment dropped.
…..
If you get the following error:
SQL> drop rollback segment “_SYSSMU11$”;
drop rollback segment “_SYSSMU11$”
*
ERROR at line 1:
ORA-30025: DROP segment ‘_SYSSMU11$’ (in undo tablespace) not allowed
this means that you did not specify the right undo segment name in the
list of the hidden parameter at startup time, and therefore the undo segment
is not offlined. Define the correct list and re-startup the database.
——————————————————————–
4/ | Once the Undo Segments are all dropped, drop the UNDO tablespace |
——————————————————————–
SQL> drop tablespace UNDOTBS including contents and datafiles;
Tablespace dropped.
If you get the following error:
SQL> drop tablespace undotbs including contents and datafiles;
drop tablespace undotbs including contents and datafiles
*
ERROR at line 1:
ORA-01548: active rollback segment ‘_SYSSMU11$’ found, terminate dropping
tablespace
this means that undo segments still exist in the undo tablespace to be dropped.
——————————–
5/ | Recreate the undo tablespace |
——————————–
SQL> create undo tablespace undotbs
2 datafile ‘/DB1/undotbs01.dbf’ size 500k reuse;
Tablespace created.
————————————————–
6/ | Reset the following parameters in the init.ora |
————————————————–
UNDO_MANAGEMENT=AUTO
#_OFFLINE_ROLLBACK_SEGMENTS=(_SYSSMU1$, _SYSSMU2$, _SYSSMU3$, …etc)
or
#_CORRUPTED_ROLLBACK_SEGMENTS=(_SYSSMU1$, _SYSSMU2$, _SYSSMU3$, …etc)

 
7/ If you used these hidden ROLLBACK_SEGMENTS parameter, perform a full
export since the database may be in an inconsistent state.
Then you MUST recreate the database and perform a full import in the case of
the use of _CORRUPTED_ROLLBACK_SEGMENTS .
In the case of _OFFLINE_ROLLBACK_SEGMENTS with active transactions that may
lead to logical corruption, you need to recreate the database and import the
data back. If there were no active transactions, then there is no need to
recreate the database: an export is nevertheless a good backup.

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

Parnassusdata Software Database Recovery Team

Service Hotline:  +86 13764045638 E-mail: service@parnassusdata.com

ORA-01173: data dictionary indicates missing data file from system tablespace

Cause: Either the database has been recovered to a point in time in the future of the control file or a datafile from the system tablespace was omitted from the create control file command previously issued.

Action: For the former problem you need to recover the database from a more recent control file. For the latter problem, simply recreate the control file checking to be sure that you include all the datafiles in the system tablespace.

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

Parnassusdata Software Database Recovery Team

Service Hotline:  +86 13764045638 E-mail: service@parnassusdata.com

Applies to:
Oracle Server – Enterprise Edition – Version 10.2.0.4 and later
Information in this document applies to any platform.

Symptoms

Database is been Force opened using the following Document 283945.1

Alter database open resetlog fails with

ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00604: error occurred at recursive SQL level 1
ORA-01555: snapshot too old: rollback segment number 11 with name “_SYSSMU11$” too small

Tue Jan 17 04:46:17 2012

Error 704 happened during db open, shutting down database

USER: terminating instance due to error 704

Instance terminated by USER, pid = 5496

ORA-1092 signalled during: ALTER DATABASE OPEN RESETLOGS…

Changes

Database is been Force open

Cause

Database is been forced open.All files are not in sycn.

File would be having block scn higher than database scn

Solution

If no trace file is available for Ora-1555 please do the following to generate a trace file for 704 And ora-1555 :-

SQL>Startup mount ;
SQL>Alter session set tracefile_identifier=new1555 ;
Now try open resetlogs

SQL>Alter database open resetlogs ;
It will error out with ORA-1092
Alert log would show 1555 error message.
Go to udump or trace directory
ls -lrt *new1555*
Case one undo segment name is reported in alert log
ORA-01555: snapshot too old: rollback segment number 11 with name “_SYSSMU11$” too small
In the above case the Ora-1555 was reported on _SYSSMU11$ which is undo segment number 11.
Hex value of same is 11 –> b
Search the trace file from Table or index block header dump whose transaction layer has an undo segment 11
been used in the ITL.Scroll up to get the Buffer header dump of that block
BH (0xacff8e48) file#: 1 rdba: 0x0040003e (1/62) class: 1 ba: 0xacf66000
set: 3 blksize: 8192 bsi: 0 set-flg: 2 pwbcnt: 0
dbwrid: 0 obj: 18 objn: 18 tsn: 0 afn: 1
hash: [d0e04c98,d0e04c98] lru: [acff8fd8,acff8db8]
ckptq: [NULL] fileq: [NULL] objq: [cc9a3d00,cc9a3d00]
use: [ce699910,ce699910] wait: [NULL]
st: CR md: EXCL tch: 0
cr: [scn: 0x0.4124e1e],[xid: 0x6.0.c28d],[uba: 0x820075.ea1.23],[cls: 0x0.46b5261],[sfl: 0x1]
flags:
Using State Objects
—————————————-
SO: 0xce6998d0, type: 24, owner: 0xd04439e8, flag: INIT/-/-/0x00
(buffer) (CR) PR: 0xd02fa378 FLG: 0x500000
class bit: (nil)
kcbbfbp: [BH: 0xacff8e48, LINK: 0xce699910]
where: kdswh02: kdsgrp, why: 0
buffer tsn: 0 rdba: 0x0040003e (1/62)
scn: 0x0000.046b527a seq: 0x00 flg: 0x00 tail: 0x527a0600
frmt: 0x02 chkval: 0x0000 type: 0x06=trans data
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x00000000ACF66000 to 0x00000000ACF68000
0ACF67FF0 FFFF02C1 01FF8001 02C10280 527A0600 […………..zR]

Block header dump: 0x0040003e
Object id on Block? Y
seg/obj: 0x12 csc: 0x00.46b519e itc: 1 flg: – typ: 1 – DATA
fsl: 0 fnx: 0x0 ver: 0x01
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x000b.00b.00000e7a 0x00802042.00db.1a C— 0 scn 0x0000.04624228

So here we see ITL allocated is 0x01.
Transaction identifier –> <undo no>.<slot>.<wrap> —> 0x000b.00b.00000e7a
Undo segment no —> 0x000b –> 11 in decimal .
This block belong to 0x0040003e –(1/62)
Find the SCN of this block from the BH(Buffer header) for 0x0040003e –(1/62)
So in this case its the one highlighted above in trace scn: 0x0000.046b527a
Now set _mimimum_giga_scn value based on this SCN
scn: 0x0000.046b527a
Convert 0x0000 –> Decimal –> 0
Convert 046b527a –> Decimal –>74142330
Combine both these value and find the value for _minimum_giga_scn
Convert –> 074142330 /1024/1024/1024 =0.069050
Add + 2G to the above value and round it up
_minimum_giga_scn = 3G
Set this parameter in the pfile along with the other force open parameter
SQL>Startup mount pfile=<> ;
SQL>recover database using backup controlfile until cancel ;
Cancel
SQL>Alter database open resetlogs ;
As per the force open steps do complete export and create new database and do import

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

Parnassusdata Software Database Recovery Team

Service Hotline:  +86 13764045638 E-mail: service@parnassusdata.com

Goal

This note will give an Brief overview of the steps to resolve ORA-600 [4194]/[4193]:-

Fix

Short Description of ORA-00600[4194]

—————————————

A mismatch has been detected between Redo records and rollback (Undo) records.

ARGUMENTS:

Arg [a] Maximum Undo record number in Undo block
Arg [b] Undo record number from Redo block

When we try to apply redo to an undo block (forward changes are made by the application of redo to a block), we check that the number of undo records in the undo block +1 matches the record number in the redo record.

Because we are adding a new undo record, we know that the record number in that undo block must be one greater than the maximum number in that block.
ORA-600 [4194] and ORA-600 [4193] happens when Oracle is trying to add a new undo block for an existent transaction.

In order to do that the UBA is taken from the FREE POOL in the undo segment compared with the undo block.

If there is a mismatch, the error is produced.

Refer to Note:39283.1 for more details on the description of this error.
Basic Steps that Need to be Followed to Solve an ORA-00600[4194] Error
There are two Options to resolve this issue.
Options along with their solutions are given below.

Option 1:- Support Method(Drop the undo tablespace).
@Option 2: – Drop the Problematic undo segment
@Option 3:- If System undo segment is involved

There is no need to use Unsupported parameter like _offline_rollback_segments and @_corrupted_rollback_segments to resolve ora-00600[4193]/[4194]

Option 1 :- Supported Method
======================
Drop the undo tablespace.

Single instance
This error normally happens for a new transaction. The trace file actually shows an active transaction for the undo segment because this is the transaction created by the process.If the undo segment happens to have an active transaction , then Oracle
may recover it later with no problems .
Normally if the header is dumped after the error, the active transactin is gone.
So a Simpler option to resolve this issue is.
Step 1
——–
SQL> Startup nomount ; –> using spfile
SQL> Create pfile=’/tmp/corrupt.ora’ from spfile ;
SQL> Shutdown immediate;
Step 2
——-
Modify the corrupt.ora and set Undo_managment=Manual
SQL> Startup mount pfile=’/tmp/corrupt.ora’
SQL> Show parameter undo
it should show manual
SQL> Alter database open ;
If it comes up
SQL> Create rollback segment r01 ;
SQL> Alter rollback segment r01 online ;
Create a new undo tablespace
SQL> Create undo tablespace undotbs_new datafile ‘<>’ size <> M ;
Please note :- You can delay the drop of the Old undo tablespace this is just to allow the block cleanout to happen for dead transaction.
So the below step can be issued after database has been up and running with new undo tablespace for couple of hours.
Also note if your database has been forced open(datafiles are not in sync and archivelogs missing ) using any unsupported method then please donot drop This note is supported method however If your database has been forced open using unsupported method and then you are encountering this ora-00600[4194]/[4193] during database open tablespace. Just create the New undo tablespace and make it the default and do the full database export.
when your database has been forced open using _allow_resetlogs_corruption and _corrupted_rollback_segments the undo$ is not populated with the correct version information undo tablespace you would get errors like ora-00600[4097] or ORA-1555 during the export if the undo segment number gets reused by new undo tablespace So its advisable tablespace as default undo tablespace without dropping the old one. This is very important. This is applicable only if you have used unsupported parameters _allow_resetlogs__corrupted_rollback_segments

Drop the Old undo tablespace
SQL> Drop tablespace <undo tablespace name> including contents and datafiles
Step 3
——-
SQL> Shutdown immediate;
SQL> Startup nomount ; —> Using spfile
SQL>Alter system set undo_tablespace=<new Undo tablespace created> scope=spfile;
SQL> Shutdown immediate ;
SQL> Startup
Check if error is reported
For Rac Instance(If one instance is down and other is up and running)
————————
If one node is up and running and other node is failing with ORA-00600[4194]/[4193] then
From the instance which is up and running create a new undo tablespace and make it the default one for the other instance which is down with the error.Startup the failing the new undo tablespace.
From Instance which is up and running

Create undo tablespace undo_new datafile ‘<filename>’ size <> m ;
Alter system set undo_tablespace=<New undo tablespace name> sid=<instance which has corrupt undo tablespace and is down> ;
Now Startup the Instance which is down
SQL>Startup mount
SQL>Show parameter undo
Should show the new undo tablespace created above
SQL>Alter database open ;
SQL>Drop tablespace <Old undo tablespace of the failing instance> including contents and datafiles
If all the Instance is down in the Rac due to this error then following the instruction given for Single instance and create new undo tablespace.

For 8i database and Below
SQL>Startup restrict
Drop the Manual rollback segments and recreate it
@Go to option 2 to identify which undo segment has issue

Please note :-
Option 1 would fail if the undo segment involved is System undo .
Please open a Service request with Oracle to diagnose the issue further
if option 1 fails.

 
Option 2 (Drop the Rollback segment)
—————————————————
From the ora-00600[4194] trace file identify the undo segment
For example
ORA-00600: internal error code, arguments: [4194], [19], [33], [], [], [],
In the above example
ARGUMENTS:
Arg [a] Maximum Undo record number in Undo block
Arg [b] Undo record number from Redo block
a—-> 19
Search for UNDO BLK in the trace file
********************************************************************************
UNDO BLK:
xid: 0x0002.014.0004d316 seq: 0x7817 cnt: 0x13 irb: 0x13 icl: 0x0 flg: 0x0000
cnt—>0x13 –> Decimal –> 19
First argument of xid is Undo segment number in Hex.
So in the above example its confirmed its undo segment 0x0002 –> @Decimal=2 which has the issue .
Once the database is up after following step1 and step 2 of Option 1
Identify the rollback segment
SQL>Select name,us# from undo$ where us# =<value found in the trace>
Identify the current value of _smu_debug_mode
SELECT a.ksppinm “Parameter”,a.ksppdesc “Description”, b.ksppstvl “Session Value”,c.ksppstvl “Instance Value” FROM x$ksppi a, x$ksppcv b, x$ksppsv c WHERE a.indx = b.indx AND a.indx = @ Alter system set “_smu_debug_mode”=4;
Alter rollback segment “_SYSSMUX$” offline;
drop rollback segment “_SYSSMUX$”;
alter system set “_smu_debug_mode”=<original value>;

 
Option 3(System undo segment erroring with Ora-00600[4194/4193]
——————————————————————————————
Option 1 would fail if the undo segment involved is System undo segment.
Please refer the note given below for patching the same.
Note.452620.1 :Int/Pub ORA-600 [4193] ORA-600 [4194] IN SYSTEM ROLLBACK SEGMENT. HOW TO @PATCH