Startup of inconsistent Oracle implicit parameters scn

Oracle implicit parameter: Use of allow_resetlogs_uption

Tip: Implicit parameters of Oracle should be used only in the test environment or with the Support of Oracle Support.

When the redo file in oracle is corrupted:
1: If the damaged non-current redo file is archived:
In this case, you can use alter database clear logfile group xx to clear the log file.
2: If the damaged file is not the current redo file and the file group is not archived:
Use alter database clear unarchived logfile group xx to forcibly clear logs.
3: In archive mode, there are two types of log corruption:
1. The database is shut down normally, and no pending transactions in the log file need to be recovered by the instance. If the current log group is damaged, you can directly use alter database clear unarchived logfile group n for reconstruction.
2. There are active transactions in the log group, the database needs to be restored by media, and the log group needs to be used for synchronization. There are two ways to remedy this problem.
A: The best way is to ensure Database Consistency through Incomplete recovery. However, this method requires that the archive method and available backup be available.
B: mandatory recovery may cause Database Inconsistency.

The following situation assumes that the current log is corrupted and there is no backup, so only mandatory recovery is adopted:
SQL> startup force;
ORACLE instance started.
Total System Global Area 97588504 bytes
Fixed Size 451864 bytes
Variable Size 33554432 bytes
Database Buffers 62914560 bytes
Redo Buffers 667648 bytes
Database mounted.
ORA-00354: upt redo log block header
ORA-00353: log uption near block 3 change 897612314 time 14:19:34
ORA-00312: online log 3 thread 1: '/opt/oracle/oradata/conner/redo03.log'
The damaged log file is active:
SQL> select * from v $ log;
GROUP # THREAD # SEQUENCE # bytes members arc status FIRST_CHANGE # FIRST_TIM
---------------------------------------------------------------------
1 1 159 10485760 1 no inactive 897592312
2 1 158 10485760 1 no inactive 897572310 19--0-05
3 1 160 10485760 1 no active 897612314
4 1 161 1048576 1 no current 897612440
You have to use another implicit parameter _ allow_resetlogs_uption to force the database to start. After this parameter is set, Oracle will skip some consistency checks during the database Open process, so that the database may skip the inconsistent state, open:
SQL> alter system set "_ allow_resetlogs_uption" = true scope = spfile;
System altered.
SQL> shutdown immediate;
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.
Total System Global Area 97588504 bytes
Fixed Size 451864 bytes
Variable Size 33554432 bytes
Database Buffers 62914560 bytes
Redo Buffers 667648 bytes
Database mounted.
SQL> recover database using backup controlfile until cancel;
ORA-00279: change 897612315 generated at 16:54:18 needed for thread 1
ORA-00289: suggestion:/opt/oracle/oradata/conner/archive/410160.dbf
ORA-00280: change 897612315 for thread 1 is in sequence #160
Specify log: {= suggested | filename | AUTO | CANCEL}
Cancel
ORA-01547: warning: RECOVER succeeded but open resetlogs wocould get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/opt/oracle/oradata/conner/system01.dbf'
ORA-01112: media recovery not started
SQL> alter database open resetlogs;
Database altered.
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 97588504 bytes
Fixed Size 451864 bytes
Variable Size 33554432 bytes
Database Buffers 62914560 bytes
Redo Buffers 667648 bytes
Database mounted.
Database opened.
Fortunately, the database can be successfully Open, if unfortunately it may encounter a series of Ora-600 errors (the most common is 2662 errors), or in openOra-600 errors, or the Ora-600 error occurs after the open operation database data moment, at this time you need to use a variety of means to continue to adjust the recovery.
If you observe the alert Log, you may find a log similar to the following:
Fri Jun 10 16:30:25 2005
Alter database open resetlogs
Fri Jun 10 16:30:25 2005
RESETLOGS is being done without consistancy checks. This may result in a specified upted database. The database shocould be recreated.
RESETLOGS after incomplete recovery until change 240677200
Resetting resetlogs activation ID 3171937922 (0xbd0fee82)
Oracle tells us that forcing resetlogs to skip the consistency check may cause database corruption and the database should be rebuilt. The Change number that was last restored to the inconsistent recovery is: 240677200. After you use this method to Open a database, you should export and import it to recreate the database immediately.