联系：手机/微信(+86 17813235971) QQ(107644445)
标题：ORA-600 3020
作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]
ORA-600 3020官方解释说明
ERROR:
Format: ORA-600 [3020] [a] [b] {c} [d] [e]
VERSIONS:
version 6.0 and above
DESCRIPTION:
This is called a 'STUCK RECOVERY'.
There is an inconsistency between the information stored in the redo
and the information stored in a database block being recovered.
ARGUMENTS:
For Oracle 9.2 and earlier:
Arg [a] Block DBA
Arg [b] Redo Thread
Arg Redo RBA Seq
Arg [d] Redo RBA Block No
Arg [e] Redo RBA Offset.
For Oracle 10.1
Arg [a] Absolute file number of the datafile.
Arg [b] Block number
Arg Block DBA
FUNCTIONALITY:
kernel cache recovery parallel
IMPACT:
INSTANCE FAILURE during recovery.
SUGGESTIONS:
There have been cases of receiving this error when RECOVER has
been issued, but either some datafiles were not restored to disk,
or the restoration has not finished.
Therefore, ensure that the entire backup has been restored and that
the restore has finished PRIOR to issuing a RECOVER database command.
If problems continue, consider restoring from a backup and doing a
point-in-time recovery to a time PRIOR to the one implied by
the ORA-600[3020] error.
Example:
SQL> recover database until time 'YYYY-MON-DD:HH:MI:SS';
This error can also be caused by a lost update.
During normal operations, block updates/writes are being performed to
a number of files including database datafiles, redo log files,
archived redo log files etc.
This error can be reported if any of these updates are lost for some
reason.
Therefore, thoroughly check your operating system and disk hardware.
In the case of a lost update, restore an old copy of the datafile and
attempt to recover and roll forward again.
相关bug信息
|
NB |
Prob |
Bug |
Fixed |
Description |
|
III |
11.2.0.4.6, 11.2.0.4.BP15, 12.1.0.2, 12.2.0.0 |
RMAN bad backup – causes recovery to fail with ORA-600 [3020] |
||
|
III |
11.2.0.3.BP22, 11.2.0.4, 12.1.0.1.2, 12.1.0.2 |
Exadata cell optimized incremental backup can skip some blocks to backup |
||
|
I |
12.2.0.0 |
ORA-753 ORA-756 or ORA-600 [3020] with KCOX_FUTURE after RMAN Restore / PITR with BCT after Open Resetlogs in 12c |
||
|
II |
12.1.0.2.160719, 12.2.0.0 |
ORA-600 [3020] KCOX_FUTURE by RECOVERY for KTU UNDO BLOCK SEQ:254 sometime after RMAN Restore of UNDO datafile in Source Database |
||
|
III |
11.2.0.4.BP20, 12.1.0.2.160119, 12.1.0.2.DBBP09, 12.2.0.0 |
ORA-600 [3020] / ORA-752 Wrong Results after Parallel Direct Load or RMAN ORA-600 [krcrfr_nohist] in RAC (caused by fix for bug 9962369) |
||
|
II |
12.2.0.0 |
ORA-1172 or ORA-600 [3020] Stuck recovery in RAC after attempted block rebuild |
||
|
III |
11.2.0.4.BP13, 12.1.0.2, 12.2.0.0 |
ORA-600 [3020] on ASSM blocks in Standby Database after CONVERT TO PHYSICAL or ORA-8103 ORA-600 [4552] in non-standby after FLASHBACK |
||
|
III |
12.1.0.2, 12.2.0.0 |
ORA-600 [3020] ORA-10567 and ORA-10560: block type ‘0’ / ORA-600 [kdBlkCheckError] ORA-600 [ktfbbset-2] after flashback which reversed a datafile extend – superseded |
||
|
I |
11.2.0.4, 12.1.0.2, 12.2.0.0 |
ORA-600 [3020] or ORA-752 if db_lost_write_protect is enabled. Bystander standby recovers wrong redo log after switchover or failover. |
||
|
+ |
III |
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-600 [kclchkblkdma_3] ORA-600 [3020] or ORA-600 [kcbchg1_16] Join of temp and permanent table in RAC might lead to corruption – superseded |
|
|
I |
11.2.0.3.9, 11.2.0.3.BP22, 11.2.0.4, 12.1.0.2 |
ORA-600 [3020] after flashback database in a RAC |
||
|
III |
11.2.0.3.BP24, 11.2.0.4, 12.1.0.2 |
ORA-600 [kcl_sanity_check_cr_1] ORA-600 [kclchkblkdma_3] in RAC or ORA-752 ORA-600 [3020] during recovery |
||
|
II |
ORA-752 or ORA-600 [3020] on recovery of Block Cleanout Operation OP:4.6 |
|||
|
I |
Session hang after applying the patch for Bug 9587912 which causes ORA-600 [3020] |
|||
|
+ |
III |
11.2.0.2.9, 11.2.0.2.BP15, 11.2.0.3.3, 11.2.0.3.BP04, 11.2.0.4, 12.1.0.1 |
Join of temp and permanent tables in RAC might cause corruption of permanent table. Regression by bug 10352368 |
|
|
E |
– |
11.2.0.2.BP11, 11.2.0.3.BP01, 11.2.0.4, 12.1.0.1 |
ORA-600 [3020] / ORA-333 Recovery of datafile or async transport do not read mirror if there is a stale block |
|
|
II |
11.2.0.3.8, 11.2.0.3.BP18, 11.2.0.4, 12.1.0.1 |
Direct NFS appears to be sending zero length windows to storage device. It may also cause Lost Writes |
||
|
I |
11.2.0.3, 12.1.0.1 |
ORA-8103/ORA-600 [3020] on RMAN recovered locally managed tablespace |
||
|
P |
I |
12.1.0.1 |
EXADATA LSI firmware for lost writes |
|
|
III |
11.2.0.2.5, 11.2.0.2.BP13, 11.2.0.2.GIPSU05, 11.2.0.3, 12.1.0.1 |
ORA-600 [3020] during recovery after datafile RESIZE (to smaller size) |
||
|
+ |
II |
11.2.0.3, 12.1.0.1 |
Stale data blocks may be returned by Exadata FlashCache |
|
|
– |
11.2.0.1.BP10, 11.2.0.2.2, 11.2.0.2.BP03, 11.2.0.2.GIBUNDLE02, 11.2.0.2.GIPSU02, 11.2.0.3, 12.1.0.1 |
Lost write in ASM with multiple DBWs and a disk is offlined and then onlined |
||
|
II |
11.2.0.2.2, 11.2.0.2.BP02, 11.2.0.3, 12.1.0.1 |
ORA-600 [3020] during recovery / on standby |
||
|
+ |
II |
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 |
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 |
|
|
II |
11.2.0.2.4, 11.2.0.2.BP09, 11.2.0.3, 12.1.0.1 |
Block change tracking on physical standby can cause data loss |
||
|
– |
11.2.0.2.BP02, 11.2.0.3, 12.1.0.1 |
Lost write / ORA-600 [kclchkblk_3] / ORA-600 [3020] in RAC – superceded |
||
|
– |
11.2.0.2, 12.1.0.1 |
ORA-600 [3020] in datafile that went offline/online in a RAC instance |
||
|
– |
11.2.0.1.2, 11.2.0.1.BP06, 11.2.0.2, 12.1.0.1 |
OERI[3020] reinstating primary |
||
|
+ |
III |
11.2.0.2, 12.1.0.1 |
ORA-600 [kcbzib_5] on multi block read in RAC. Invalid lock in RAC. ORA-600 [3020] in Recovery |
|
|
P |
II |
10.2.0.5, 11.2.0.2, 12.1.0.1 |
Solaris: directio may be disabled for RAC file access. Corruption / Lost Write |
|
|
+ |
II |
11.2.0.1.BP06, 11.2.0.2, 12.1.0.1 |
Lost Write in ASM when normal redundancy is used |
|
|
+E |
II |
11.2.0.3.9, 11.2.0.3.BP22, 11.2.0.4.2, 11.2.0.4.BP03 |
ORA-600 [kclchkblkdma_3] ORA-600 [3020] RAC diagnostic/fix to avoid a block being modified in Shared Mode and prevent corruption – Superseded |
|
|
III |
10.2.0.5, 11.2.0.2 |
ORA-600 [3020] for block type 0x3a (58) during recovery for block restored by RMAN backup |
||
|
I |
11.2.0.4 |
ORA-600 [kjbmpocr:alh] ORA-600 [kclchkblkdma_3] by LMS in RAC which may lead to corruption |
||
|
– |
11.2.0.1 |
ORA-600 [3020] on standby involving “BRR” redo when db_lost_write_protect is enabled |
||
|
– |
10.2.0.4.1, 10.2.0.5, 11.1.0.7.1, 11.2.0.1 |
Physical standby media recovery gets OERI[krr_media_12] |
||
|
+ |
II |
10.2.0.5, 11.1.0.7.1, 11.2.0.1 |
ORA-600 [kclexpandlock_2] in LMS / instance crash. Incorrect locks in RAC. ORA-600 [3020] in recovery |
|
|
II |
10.2.0.3, 11.1.0.6 |
IMU transactions can produce out-of-order redo (OERI [3020] on recovery) |
||
|
– |
9.2.0.8, 10.2.0.2, 11.1.0.6 |
Write IO error can cause incorrect file header checkpoint information |
||
|
– |
10.2.0.2, 11.1.0.6 |
OERI:3020 / corruption errors from multiple FLASHBACK DATABASE |
||
|
III |
10.2.0.4.1, 10.2.0.5 |
Standby Recovery session cancelled due to ORA-600 [3020] “CHANGE IN FUTURE OF BLOCK” |
||
|
II |
10.2.0.5 |
MRP terminated by ORA-600[krr_media_12] / OERI:3020 after flashback |
||
|
– |
9.2.0.7, 10.1.0.4, 10.2.0.1 |
ALTER DATABASE RECOVER MANAGED STANDBY fails with OERI[3020] |
||
|
I |
10.2.0.1 |
OERI[3020] stuck recovery under RAC |
||
|
– |
9.2.0.5, 10.1.0.3, 10.2.0.1 |
ALTER SYSTEM KILL SESSION of recovery slave causes stuck recovery |
||
|
* |
– |
10.2.0.1 |
Backups from RAC DB before Data Guard Failover cannot be used |
|
|
– |
9.2.0.6, 10.1.0.4 |
OERI[3020] / ORA-10567 from RAC with standby in max performance mode |
||
|
– |
9.2.0.8, 10.1.0.2 |
Incorrect checkpoint possible in datafile headers |
||
|
– |
9.2.0.6, 10.1.0.4 |
Stuck recovery (OERI:3020) / ORA-1172 on startup after a crash |
||
|
II |
9.2.0.1 |
OERI:3020 possible on recovery of LOB DATA |
||
|
P+ |
– |
7.3.3.4, 7.3.4.0, 8.0.3.0 |
AlphaNT only: Corrupt Redo (zeroed byte) OERI:3020 |