Ora-01052:required destination log_archive_duplex_dest is not specified recovery steps

Today, a netizen found me, said database recovery in the process of pushing the SCN encountered ora-01052:required destination log_archive_duplex_dest is not specified error can not be resolved, Let me give my support. It makes me think that now because of database bugs and Dblink causes many database SCN is very close to the ceiling, so that the database recovery process can not be directly simple push SCN, here is the case Simple description of the ORA-01052 fault handling. Similar documents have been written before: Similar articles on the cause of ORA-01052

The database cannot be recovered because of bad blocks
Beginning crash recovery of 1 threads
Started Redo scan
Completed Redo Scan
Read 1901 KB Redo, 276 data blocks need recovery
Started Redo application at
Thread 1:logseq 1004, Block 172771
Recovery of Online Redo log:thread 1 Group 2 Seq 1004 Reading Mem 0
mem# 0:f:\app\administrator\oradata\xff\redo02. LOG
Fri May 29 10:59:56 2015
RECOVERY of THREAD 1 stuck at block 439938 of FILE 19
Fri May 29 11:00:00 2015
Exception [Type:access_violation, Unable_to_read] [addr:0x2048] [pc:0x6215134, __intel_new_memcpy () +260]
Fri May 29 11:00:12 2015
Trace dumping is performing id=[cdmp_20150529110012]
Fri May 29 11:00:12 2015
Slave exiting with ORA-1172 exception
Errors in file f:\app\administrator\diag\rdbms\XFF\XFF\trace\XFF_p007_1612.trc:
ORA-01172: Thread 1 recovery stopped at block 439938 (in file 19)
ORA-01151: If necessary, use media recovery to recover blocks and restore backups
Fri May 29 11:00:27 2015
Damage to Ora-01578:oracle data block (file number 19, block number 450245)
ORA-01110: Data file: ' F:\APP\ADMINISTRATOR\ORADATA\XFF\PSTORE_02.DBF '
Ora-10564:tablespace Pstore
ORA-01110: Data file: ' F:\APP\ADMINISTRATOR\ORADATA\XFF\PSTORE_02.DBF '
Ora-10561:block type ' TRANSACTION MANAGED INDEX block ', Data object# 91642
ORA-00607: An internal error occurred while changing the data block
ORA-00602: Internal Programming exception error
ORA-07445: Unexpected error: Core dump [_intel_new_memcpy () +260] [access_violation] [addr:0x2048]
[pc:0x6215134] [Unable_to_read] []
Fri May 29 11:00:27 2015
Aborting crash recovery due to slave death, attempting serial crash
RECOVERY of THREAD 1 stuck at block 439938 of FILE 19
Fri May 29 11:00:45 2015
Trace dumping is performing id=[cdmp_20150529110045]
Aborting crash recovery due to error 1172
ORA-1172 signalled during:alter database open ...
Set _allow_resetlogs_corruption and Resetlogs try to open the database
assigning activation ID 4272042346 (0XFEA2316A)
Thread 1 opened at log sequence 1
Current log# 1 seq# 1 mem# 0:f:\app\administrator\oradata\xff\redo01. LOG
Successful open of Redo thread 1
MTTR advisory is disabled because fast_start_mttr_target are not set
Fri May 29 11:30:47 2015
Smon:enabling Cache Recovery
Fri May 29 11:30:47 2015
Errors in File F:\app\administrator\diag\rdbms\XFF\XFF\trace\XFF_ora_3004.trc (incident=181236):
ORA-00600:??????,??: [2662], [3360], [2233437186], [3360], [2235447064], [4194545], [], [], [], [], [], []
Incident Details IN:F:\APP\ADMINISTRATOR\DIAG\RDBMS\XFF\XFF\INCIDENT\INCDIR_181236\XFF_ORA_3004_I181236.TRC
Errors in file f:\app\administrator\diag\rdbms\XFF\XFF\trace\XFF_ora_3004.trc:
ORA-00704:????????
ORA-00704:????????
ORA-00600:??????,??: [2662], [3360], [2233437186], [3360], [2235447064], [4194545], [], [], [], [], [], []
Errors in file f:\app\administrator\diag\rdbms\XFF\XFF\trace\XFF_ora_3004.trc:
ORA-00704:????????
ORA-00704:????????
ORA-00600:??????,??: [2662], [3360], [2233437186], [3360], [2235447064], [4194545], [], [], [], [], [], []
Error 704 happened during DB Open, shutting down database
USER (ospid:3004): Terminating the instance due to error 704
Instance terminated by USER, PID = 3004
ORA-1092 signalled during:alter database open resetlogs ...
OPIODR aborting process unknown ospid (3004) as a result of ORA-1092
Here you can see the database by setting the _allow_resetlogs_corruption parameters, do not complete recovery, skip the database Startup instance recovery, and then force pull the library, and then encounter the familiar ora-600[2662] error, so that the recovery failed, according to experience, To bypass the error by pushing the SCN

Use _MINIMUM_GIGA_SCN to try to push the SCN
sql> shutdown Immediate
Database closed.
Database dismounted.
ORACLE instance shut down.

--------------------------------
*._minimum_giga_scn=13443
--------------------------------

sql> startup pfile= '/tmp/pfile '
ORACLE instance started.

Total System Global area 236000356 bytes
Fixed Size 451684 bytes
Variable Size 201326592 bytes
Database buffers 33554432 bytes
Redo buffers 667648 bytes
Database mounted.

Here the maximum allowable propulsive SCN is 13442.7, but the conventional minimal push SCN method has a minimum value of 1024*1024*1024 multiples, so there is trouble here.

Using the Oracle database Recovery Check check found that the SCN is already very large, close to the ceiling
_minimum_giga_scn

Here the maximum allowable propulsive SCN is 13442.7, but the conventional minimal push SCN method has a minimum value of 1024*1024*1024 multiples, so there is trouble here.

Here the database encountered a ORA-01052 error, causing the push SCN was unsuccessful and the database could not start properly. This happens because the SCN can increase the space very small, Therefore, you can use the Oradebug to modify the database SCN or directly modify the control file SCN to precisely control the value of the push SCN (the SCN can increase any value, as long as it does not exceed the ceiling), you can also modify the database SCN distance from the ceiling through the method, so as to achieve significant use _ MINIMUM_GIGA_SCN to push the SCN. There is also a workaround: Because the ORA-01052 is caused by the SCN being too large (exceeding the current ceiling SCN of the database), there is a ORA-01052. So the alternative approach, It is by adjusting the ceiling SCN of the database so that _MINIMUM_GIGA_SCN can continue to push the SCN. Restore using the simplest way to increase the ceiling SCN in this recovery (although the method restores the library after it has been restored, it actually uses the suppressed parameters to mask redo recovery, itself suggests rebuilding the library to ensure data dictionary consistency)

Contact: Mobile Phone (13429648788) QQ (107644445)

Link: http://www.xifenfei.com/5909.html

Author: Xi-FEI