The database storage is abnormally crashed, and there is a problem with the control file first.
ORA-01122: ????? 1 ???? ORA-01110: ???? 1: '/oracledata/oradata/orc11rac/orc11rac/system01.dbf' ORA-01207: ????????? - ??????
/home/oracle>oerr ora 1207 01207, 00000, "file is more recent than control file - old control file" // *Cause: The control file change sequence number in the data file is // greater than the number in the control file. This implies that // the wrong control file is being used. Note that repeatedly causing // this error can make it stop happening without correcting the real // problem. Every attempt to open the database will advance the // control file change sequence number until it is great enough. // *Action: Use the current control file or do backup control file recovery to // make the control file current. Be sure to follow all restrictions // on doing a backup control file recovery. /home/oracle>oerr ora 1110 01110, 00000, "data file %s: '%s'" // *Cause: Reporting file name for details of another error // *Action: See associated error message /home/oracle>oerr ora 1122 01122, 00000, "database file %s failed verification check" // *Cause: The information in this file is inconsistent with information // from the control file. See accompanying message for reason. // *Action: Make certain that the db files and control files are the correct // files for this database.
This problem can be solved by rebuilding the control file and then recovering the database.
It should be noted that in a RAC environment, cluster_database needs to be closed.
That is, operate in a single-threaded environment.
Otherwise, you may encounter the following problems:
ORA-01503: CREATE CONTROLFILE failed ORA-12720: operation requires database is in EXCLUSIVE mode
I thought that things could pass, but during the recovery, the files, redolog, and archivedlog were all corrupted, and they could not be opened after recovery by conventional means.
Finally, try the _allow_resetlogs_corruption parameter.
Add parameters in pfile file
*._allow_resetlogs_corruption=true
When using this parameter resetlogs to open the database, you may encounter ORA-00600 2662 error due to SCN inconsistency.
ORA-00600: internal error code, arguments: [2662], [2739], [1998974916], [2739], [1998994896], [12582921], [], [] 1998994896 - 1998974916 = 19980
The error parameter of ORA-600 will change every time you try to restart.
ORA-00600: internal error code, arguments: [2662], [2739], [1998974924], [2739], [1998994896], [12582921], [], [] 1998994896 - 1998974924 = 19972
It can be found that from 19980 to 19972, this value is shrinking, this error, if the value is relatively close, you can try to restart several times.
But it needs to restart 2497 times, which is unacceptable in the short term.
At this point we can adjust the SCN through Oracle's internal events:
There are two common methods for enhancing SCN:
1. Through the immediate trace name method (in the database Open state)
alter session set events 'IMMEDIATE trace name ADJUST_SCN level x';
2. Through the 10015 event (when the database cannot be opened, in the mount state)
alter session set events '10015 trace name adjust_scn level x';
Note: Level 1 is to increase SCN 1 billion (1 billion) (1024*1024*1024), usually Level 1 is enough. It can also be adjusted appropriately according to the actual situation.
SQL> alter session set events 'IMMEDIATE trace name ADJUST_SCN level 10'; Session altered. SQL> alter database open; alter database open * ERROR at line 1: ORA-01113: file 1 needs media recovery ORA-01110: data file 1: '/oracledata/oradata/orc11rac/orc11rac/system01.dbf' SQL> recover database Media recovery complete. SQL> alter database open; alter database open * ERROR at line 1: ORA-00603: ORACLE server session terminated by fatal error Process ID: 27474 Session ID: 1105 Serial number: 5
Still can't open, an error is reported in the background
ORA-00600: internal error code, arguments: [4193], [28923], [28936], [], [], [], [], []
The error report of ORA-600 has changed, and the above operation has taken effect. But new errors are induced.
DESCRIPTION: A mismatch has been detected between Redo records and Rollback (Undo) records. We are validating the Undo block sequence number in the undo block against the Redo block sequence number relating to the change being applied. This error is reported when this validation fails. ARGUMENTS: Arg [a] Undo record seq number Arg [b] Redo record seq number FUNCTIONALITY: KERNEL TRANSACTION UNDO NOW - 600 [ 4193 ] [a] [b] [] [] [] Versions: 7.2.2 - 9.2.0 Source: ktuc.c =========================================================================== Meaning: seq# mismatch while adding an undo record to an undo block. This is done by the application of redo. --------------------------------------------------------------------------- Argument Description: a. (ktubhseq): undo record seq# - this is the seq# of the block that this undo record WILL BE APPLIED TO. This is from the Undo Block. It is NOT the seq# of the undo block itself. b. (ktudbseq): redo RECORD seq# - this is the seq# number in the block that this redo WILL BE APPLIED TO. This is from the Redo Record. --------------------------------------------------------------------------- Diagnosis: This error is raised in kturdb which handles the adding of undo records by the application of redo. 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 seq# in the undo record matches the seq# in the redo record. These seq# should be the same because when we apply a redo record we must apply it to the correct version of the block. We can only apply a redo record to a block that contains the same seq# as in the redo record. If the seq# do not match then this error is raised. This implies some kind of block corruption in either the redo or the undo block. 7.3.x - 8.1.7.x ASSERT2 (ubh -> ktubhseq == db-> ktudbseq, OERI ( 4193 ), KSESVSGN, ubh->ktubhseq, db->ktudbseq); 9.2.x ksesic2 (OERI ( 4193 ), ksenrg (ubh-> ktubhseq), ksenrg (db-> ktudbseq)); struct ktubh { kxid ktubhxid; /* txid of tx currently using or last used this block */ ub2 ktubhseq; /* undo block sequence number */ ub1 ktubhcnt; /* high water mark record index, number of undo entries */ ub1 ktubhirb; /* rollback record index, rec index to start the rollback */ ub1 ktubhicl; /* collecting record index, rec index to start retrieving col info */ ub1 ktubhflg; /* dummy */ ub2 ktubhidx[1]; /* byte offset of record in block, grows at runtime */ }; struct ktudb Kernel Transaction Undo Data operation Block (redo) { ub2 ktudbsiz; /* size of entry */ ub2 ktudbspc; /* verification: space left in undo block */ ub2 ktudbflg; /* flag to indicate the kind of redo operation */ kxid ktudbxid; /* current tx id */ ub2 ktudbseq; /* block sequence number */ ub1 ktudbrec; /* new record index for this change */ };
The processing method is
1. Create a new UNDO tablespace;
2. Modify the undo management to manual;
this time, the manual method is selected, and the parameter file is modified
*.undo_management=manual
SQL> startup mount ORACLE instance started. Total System Global Area 1.3429E+10 bytes Fixed Size 2149040 bytes Variable Size 6845105488 bytes Database Buffers 6576668672 bytes Redo Buffers 4730880 bytes Database mounted. SQL> alter database open; Database altered.
At this point, the database is successfully opened. At this point, the required data can be exported for backup.
Some versions of the database still require the temp file addition of the TEMP tablespace.
But at this time, the required data can be exported for backup.
Continue to observe the background log for errors, or you can create a new UNDO tablespace for auto management.