标签云
asm 恢复 asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 kfed MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-01110 ORA-01555 ORA-01578 ORA-08103 ORA-600 2662 ORA-600 2663 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 ORACLE恢复 Oracle 恢复 ORACLE数据库恢复 oracle 比特币 OSD-04016 YOUR FILES ARE ENCRYPTED 勒索恢复 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (100)
- 数据库 (1,598)
- DB2 (22)
- MySQL (70)
- Oracle (1,463)
- Data Guard (49)
- EXADATA (7)
- GoldenGate (21)
- ORA-xxxxx (158)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (13)
- ORACLE 21C (3)
- Oracle ASM (65)
- Oracle Bug (7)
- Oracle RAC (47)
- Oracle 安全 (6)
- Oracle 开发 (27)
- Oracle 监听 (27)
- Oracle备份恢复 (530)
- Oracle安装升级 (84)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (75)
- PostgreSQL (18)
- PostgreSQL恢复 (6)
- SQL Server (27)
- SQL Server恢复 (8)
- TimesTen (7)
- 达梦数据库 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (36)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (19)
-
最近发表
- PostgreSQL解析wal日志之—walminer
- Oracle 19c/21c最新patch信息-202404
- PostgreSQL恢复系列:pg_filedump批量处理
- PostgreSQL部分主要字典信息
- PostgreSQL恢复系列:pg_filedump恢复字典构造
- PostgreSQL 16 源码安装
- ORA-00742 ORA-00312 恢复
- 数据库open成功后报ORA-00353 ORA-00354错误引起的一系列问题(本质ntfs文件系统异常)
- ORA-600 ktsiseginfo1故障
- ORA-00600: internal error code, arguments: [16703], [1403], [4] 原因
- 最近遇到几起ORA-600 16703故障(tab$被清空),请引起重视
- ORA-600 2662快速恢复之Patch scn工具
- TNS-12518: TNS:listener could not hand off client connection
- ora.storage无法启动报ORA-12514故障处理
- 断电引起文件scn异常数据库恢复
- ORA-16188: LOG_ARCHIVE_CONFIG settings inconsistent with previously started instance
- .[hudsonL@cock.li].mkp勒索加密数据库完美恢复
- 模拟带库实现rman远程备份
- 又一例:ORA-600 kclchkblk_4和2662故障
- Oracle误删除数据文件恢复
月归档:八月 2016
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 1 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 1 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 |
ORA-600 kdsgrp1
在硬件恢复,断电,redo异常等恢复case中ORA-600 [kdsgrp1]是一个比较常见的错误,这里该出来官方关于该错误的解释说明和处理方法
RROR: Format: ORA-600 [kdsgrp1] VERSIONS: versions 10.1 and above DESCRIPTION: This error was introduced in 10g with the fix to Bug 2442351, it provides for an extra health check on a block, we detected a null row header, see Note:2442351.9 for more information. Error may be caused by: Case 1. A row referenced in an index that does not exist in the table. Case 2. An non-existent rowid pointed to by a chained row. Trace Examples: Case 1. Mismatch between table and index: ==================================================== Trace file has: row 02433566.13 continuation at file# 9 block# 210278 slot 20 not found The file=9 block=210278 is rdba=0x02433566 which was taken from an index: row#3[7549] flag: ------, lock: 0, len=85, data:(6): 02 43 35 66 00 14 But the slot 20 does not exist in the table block: tab 0, row 1, @0x1e62 tl: 2 fb: --HDFL-- lb: 0x3 tab 0, row 12, @0x191a tl: 2 fb: --HDFL-- lb: 0x1 tab 0, row 17, @0x1675 tl: 2 fb: --HDFL-- lb: 0x2 tab 0, row 21, @0x1459 tl: 2 fb: --HDFL-- lb: 0x4 ORA-1499 may be produced by analyze: analyze table <table name> validate structure cascade; Case 2. A row points to another rowid which does not exist (Chained row does not exist). ============================================================================================ Trace file has: row 1186b11a.ffffffff continuation at file# 70 block# 441621 slot 1 not found It means that row with rdba 0x1186b11a continues in file# 70 block# 441621 slot 1. But the information in file# 70 block# 441621 slot 1 does not exist. It is: tab 0, row 16, @0xd7f ---> This is the slot with the problem. tl: 29 fb: -------- lb: 0x0 cc: 11 nrid: 0x1186bd15.1 ---> It points to rdba=0x1186bd15 slot 1 (file# 70 block# 441621 slot 1) but that row does not exist in that block. For this case ANALYZE TABLE .. VALIDATE STRUCTURE is not detecting this logical corruption Referece Bug 6858313 Run an export (exp) or Full Table Scan to identify if there is a permanent invalid chained row. Workaround for Case 2: The row producing the ORA-600 [kdsgrp1] can be skipped by setting the Event 10231 Note that a testcase has concluded that event 10231 does not skip rows in an Index Organized Table (IOT) when there is an invalid nrid as explained in Case 2. It only works for regular tables. Event 43810 skip corrupt block in IOT?s (10.2.0.4) nor parameter _index_scan_check_skip_corrupt (11g) work for this case 2 on IOTs either. FUNCTIONALITY: Kernel Data layer Seek/Scan IMPACT: PROCESS FAILURE POSSIBLE PHYSICAL CORRUPTION
ORA-600 2663
在大家熟悉的ORA-600 2662错误中还有一个类似的ORA-600 2663的错误,以下是对该2663的解释说明
ERROR: Format: ORA-600 [2663] [a] [b] {c} [d] VERSIONS: versions 10.1 to 11.1 DESCRIPTION: A data block SCN is ahead of the current SCN. The ORA-600 [2663] occurs when an SCN is compared to the dependent SCN stored in a UGA variable. If the SCN is less than the dependent SCN then we signal the ORA-600 [2663] internal error. ARGUMENTS: Arg [a] Current SCN WRAP Arg [b] Current SCN BASE Arg {c} dependent SCN WRAP Arg [d] dependent SCN BASE FUNCTIONALITY: Kernel Cache Redo File Redo Generation IMPACT: INSTANCE FAILURE POSSIBLE PHYSICAL CORRUPTION SUGGESTIONS: There are different situations where ORA-600 [2663] can be raised. It can be raised on startup or duing database operation. If not using RAC, Real Application Clusters,, check that 2 instances have not mounted the same database. Check for SMON traces and have the alert.log and trace files ready to send to support. Check the SCN difference [argument d]-[argument b]. If the SCNs in the error are very close, then try to shutdown and startup the instance several times. In some situations, the SCN increment during startup may permit the database to open. Keep track of the number of times you attempted a startup.