-
3D Cloud
asm mount asm恢复 bbed bootstrap$ dmp损坏 dul In Memory kccpb_sanity_check_2 kfed MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-01110 ORA-01190 ORA-01555 ORA-01578 ORA-08103 ORA-600 2662 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kccpb_sanity_check_2 ORA-15042 ORACLE 12C oracle dul ORACLE PATCH oracle异常恢复 ORACLE恢复 Oracle 恢复 ORACLE数据库恢复 oracle 比特币 redo异常 undo异常 YOUR FILES ARE ENCRYPTED _ALLOW_RESETLOGS_CORRUPTION 勒索恢复 数据库恢复 比特币 比特币 oracle 比特币加密 比特币勒索
文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (87)
- 数据库 (1,312)
- DB2 (22)
- MySQL (56)
- Oracle (1,198)
- Data Guard (39)
- EXADATA (7)
- GoldenGate (19)
- ORA-xxxxx (145)
- ORACLE 12C (71)
- ORACLE 18C (6)
- ORACLE 19C (8)
- Oracle ASM (56)
- Oracle Bug (7)
- Oracle RAC (40)
- Oracle 安全 (6)
- Oracle 开发 (25)
- Oracle 监听 (26)
- Oracle备份恢复 (392)
- Oracle安装升级 (54)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (41)
- PostgreSQL (10)
- SQL Server (26)
- SQL Server恢复 (7)
- TimesTen (7)
- 达梦数据库 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (23)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (6)
-
最近发表
- incaseformat 病毒删除文件恢复
- xfs文件系统mysql删库恢复
- 对恢复案例:因对工作调整不满,链家一员工删除公司 9 TB数据:被判7年事件有感
- Oracle Recovery Tools 解决ORA-01190 ORA-01248等故障
- Oracle Recovery Tools 12月份更新
- -bash: /bin/rm: Argument list too long
- ORA-27303: failure occurred at: skgpwinit6
- ORA-600 kffmLoad_1 kffmVerify_4
- ORA-00600 kfrHtAdd01
- ORA-00600 [2662]和ORA-00600 [4194]恢复
- 记录oracle安装的两个小问题(INS-30060和弹出子窗口异常)
- dblink会话引起library cache lock
- asm磁盘类似_DROPPED_0001_DATA名称故障处理
- 12C数据库报ORA-600 kcbzib_kcrsds_1故障处理
- 再次遇到ORA-600 kokasgi1故障恢复
- sysaux表空间不足—WRH$_ACTIVE_SESSION_HISTORY
- sql server 删除数据库恢复
- .eight加密数据库恢复
- xiaolinghelper@firemail.cc加密数据库恢复
- 加密.CC4H扩展名数据库恢复支持
友情链接
标签归档:ORA-600 3020
硬件故障数据库异常恢复
硬件故障数据库crash
有客户由于硬件故障导致数据库异常ORA-00345 ORA-00312 ORA-27070 OSD-04016
Tue Feb 05 16:58:26 2019 Thread 1 advanced to log sequence 17139 (LGWR switch) Current log# 12 seq# 17139 mem# 0: S:\ORADATA\ORCL\REDO12A.LOG Current log# 12 seq# 17139 mem# 1: S:\ORADATA\ORCL\REDO12B.LOG Tue Feb 05 19:47:24 2019 Errors in file c:\oracle\diag\rdbms\orcl\orcl\trace\orcl_lgwr_2420.trc: ORA-00345: redo log write error block 152097 count 8 ORA-00312: online log 12 thread 1: 'S:\ORADATA\ORCL\REDO12A.LOG' ORA-27070: async read/write failed OSD-04016: 异步 I/O 请求排队时出错。 O/S-Error: (OS 1) 函数不正确。 ORA-00345: redo log write error block 152097 count 8 ORA-00312: online log 12 thread 1: 'S:\ORADATA\ORCL\REDO12B.LOG' ORA-27070: async read/write failed OSD-04016: 异步 I/O 请求排队时出错。 O/S-Error: (OS 1) 函数不正确。 ORA-00345: redo log write error block 152105 count 1 ORA-00312: online log 12 thread 1: 'S:\ORADATA\ORCL\REDO12A.LOG' ORA-27070: async read/write failed OSD-04016: 异步 I/O 请求排队时出错。 O/S-Error: (OS 1) 函数不正确。
直接启动数据库报错
修复好硬件之后,直接启动数据库报ORA-00600 kcratr_scan_lastbwr错误
Fri Feb 08 20:58:15 2019 alter database mount exclusive Successful mount of redo thread 1, with mount id 1527506791 Database mounted in Exclusive Mode Lost write protection disabled Completed: alter database mount exclusive alter database open Beginning crash recovery of 1 threads Started redo scan Errors in file c:\oracle\diag\rdbms\orcl\orcl\trace\orcl_ora_3672.trc (incident=41353): ORA-00600: ??????, ??: [kcratr_scan_lastbwr], [], [], [], [], [], [], [], [], [], [], [] Incident details in: c:\oracle\diag\rdbms\orcl\orcl\incident\incdir_41353\orcl_ora_3672_i41353.trc Aborting crash recovery due to error 600 Errors in file c:\oracle\diag\rdbms\orcl\orcl\trace\orcl_ora_3672.trc: ORA-00600: ??????, ??: [kcratr_scan_lastbwr], [], [], [], [], [], [], [], [], [], [], [] Errors in file c:\oracle\diag\rdbms\orcl\orcl\trace\orcl_ora_3672.trc: ORA-00600: ??????, ??: [kcratr_scan_lastbwr], [], [], [], [], [], [], [], [], [], [], [] ORA-600 signalled during: alter database open... Fri Feb 08 20:58:24 2019 Trace dumping is performing id=[cdmp_20190208205824] Fri Feb 08 20:59:04 2019 alter database open Beginning crash recovery of 1 threads Started redo scan Errors in file c:\oracle\diag\rdbms\orcl\orcl\trace\orcl_ora_1696.trc (incident=41354): ORA-00600: 内部错误代码, 参数: [kcratr_scan_lastbwr], [], [], [], [], [], [], [], [], [], [], [] Incident details in: c:\oracle\diag\rdbms\orcl\orcl\incident\incdir_41354\orcl_ora_1696_i41354.trc Aborting crash recovery due to error 600 Errors in file c:\oracle\diag\rdbms\orcl\orcl\trace\orcl_ora_1696.trc: ORA-00600: 内部错误代码, 参数: [kcratr_scan_lastbwr], [], [], [], [], [], [], [], [], [], [], [] Errors in file c:\oracle\diag\rdbms\orcl\orcl\trace\orcl_ora_1696.trc: ORA-00600: 内部错误代码, 参数: [kcratr_scan_lastbwr], [], [], [], [], [], [], [], [], [], [], [] ORA-600 signalled during: alter database open ...
recover database报错
执行recover database报错ORA-00600 6101,ORA-00600 kdourp_inorder2,ORA-00600 ktbsdp1,ORA-00600 3020
Fri Feb 08 21:09:20 2019 ALTER DATABASE RECOVER database Media Recovery Start started logmerger process Parallel Media Recovery started with 4 slaves Fri Feb 08 21:09:21 2019 Recovery of Online Redo Log: Thread 1 Group 12 Seq 17139 Reading mem 0 Mem# 0: S:\ORADATA\ORCL\REDO12A.LOG Mem# 1: S:\ORADATA\ORCL\REDO12B.LOG Fri Feb 08 21:09:21 2019 Errors in file c:\oracle\diag\rdbms\orcl\orcl\trace\orcl_pr02_3780.trc (incident=49379): ORA-00600: internal error code, arguments: [6101], [17], [21], [0], [], [], [], [], [], [], [], [] Incident details in: c:\oracle\diag\rdbms\orcl\orcl\incident\incdir_49379\orcl_pr02_3780_i49379.trc Fri Feb 08 21:09:21 2019 Errors in file c:\oracle\diag\rdbms\orcl\orcl\trace\orcl_pr01_2040.trc (incident=49371): ORA-00600: internal error code, arguments: [kdourp_inorder2], [34], [0], [0], [44], [], [], [], [], [], [], [] Incident details in: c:\oracle\diag\rdbms\orcl\orcl\incident\incdir_49371\orcl_pr01_2040_i49371.trc Fri Feb 08 21:09:21 2019 Errors in file c:\oracle\diag\rdbms\orcl\orcl\trace\orcl_pr03_1068.trc (incident=49387): ORA-00600: internal error code, arguments: [ktbsdp1], [], [], [], [], [], [], [], [], [], [], [] Incident details in: c:\oracle\diag\rdbms\orcl\orcl\incident\incdir_49387\orcl_pr03_1068_i49387.trc Fri Feb 08 21:09:24 2019 Trace dumping is performing id=[cdmp_20190208210924] Slave exiting with ORA-10562 exception Errors in file c:\oracle\diag\rdbms\orcl\orcl\trace\orcl_pr03_1068.trc: ORA-10562: Error occurred while applying redo to data block (file# 4, block# 1716972) ORA-10564: tablespace USERS ORA-01110: data file 4: 'S:\ORADATA\ORCL\USERS01.DBF' ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# 204127 ORA-00600: internal error code, arguments: [ktbsdp1], [], [], [], [], [], [], [], [], [], [], [] Slave exiting with ORA-10562 exception Errors in file c:\oracle\diag\rdbms\orcl\orcl\trace\orcl_pr02_3780.trc: ORA-10562: Error occurred while applying redo to data block (file# 4, block# 1738552) ORA-10564: tablespace USERS ORA-01110: data file 4: 'S:\ORADATA\ORCL\USERS01.DBF' ORA-10561: block type 'TRANSACTION MANAGED INDEX BLOCK', data object# 211606 ORA-00600: internal error code, arguments: [6101], [17], [21], [0], [], [], [], [], [], [], [], [] Slave exiting with ORA-10562 exception Errors in file c:\oracle\diag\rdbms\orcl\orcl\trace\orcl_pr01_2040.trc: ORA-10562: Error occurred while applying redo to data block (file# 4, block# 1725898) ORA-10564: tablespace USERS ORA-01110: data file 4: 'S:\ORADATA\ORCL\USERS01.DBF' ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# 73907 ORA-00600: internal error code, arguments: [kdourp_inorder2], [34], [0], [0], [44], [], [], [], [], [], [], [] Recovery Slave PR03 previously exited with exception 10562 Fri Feb 08 21:09:28 2019 Errors in file c:\oracle\diag\rdbms\orcl\orcl\trace\orcl_pr04_2608.trc (incident=49395): ORA-00600: internal error code, arguments: [3020], [4], [1739291], [18516507], [], [], [], [], [], [], [], [] ORA-10567: Redo is inconsistent with data block (file# 4, block# 1739291, file offset is 1363369984 bytes) ORA-10564: tablespace USERS ORA-01110: data file 4: 'S:\ORADATA\ORCL\USERS01.DBF' ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# 211552 Incident details in: c:\oracle\diag\rdbms\orcl\orcl\incident\incdir_49395\orcl_pr04_2608_i49395.trc Slave exiting with ORA-600 exception Errors in file c:\oracle\diag\rdbms\orcl\orcl\trace\orcl_pr04_2608.trc: ORA-00600: internal error code, arguments: [3020], [4], [1739291], [18516507], [], [], [], [], [], [], [], [] ORA-10567: Redo is inconsistent with data block (file# 4, block# 1739291, file offset is 1363369984 bytes) ORA-10564: tablespace USERS ORA-01110: data file 4: 'S:\ORADATA\ORCL\USERS01.DBF' ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# 211552 Media Recovery failed with error 448 Errors in file c:\oracle\diag\rdbms\orcl\orcl\trace\orcl_pr00_1548.trc: ORA-00283: recovery session canceled due to errors ORA-00448: normal completion of background process Slave exiting with ORA-283 exception Errors in file c:\oracle\diag\rdbms\orcl\orcl\trace\orcl_pr00_1548.trc: ORA-00283: recovery session canceled due to errors ORA-00448: normal completion of background process ORA-10562 signalled during: ALTER DATABASE RECOVER database ...
出现上述问题主要是由于硬件突然故障,数据写丢失导致相关问题.
处理思路
RMAN> recover datafile 1; 启动 recover 于 09-2月 -19 使用通道 ORA_DISK_1 正在开始介质的恢复 介质恢复完成, 用时: 00:00:01 完成 recover 于 09-2月 -19 RMAN> recover datafile 2; 启动 recover 于 09-2月 -19 使用通道 ORA_DISK_1 正在开始介质的恢复 介质恢复完成, 用时: 00:00:01 完成 recover 于 09-2月 -19 RMAN> recover datafile 3; 启动 recover 于 09-2月 -19 使用通道 ORA_DISK_1 正在开始介质的恢复 介质恢复完成, 用时: 00:00:02 完成 recover 于 09-2月 -19 RMAN> recover datafile 4; 启动 recover 于 09-2月 -19 使用通道 ORA_DISK_1 正在开始介质的恢复 无法恢复介质 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: recover 命令 (在 02/09/2019 21:48:19 上) 失败 ORA-00283: recovery session canceled due to errors RMAN-11003: 在分析/执行 SQL 语句期间失败: alter database recover if needed datafile 4 ORA-00283: 恢复会话因错误而取消 ORA-10562: Error occurred while applying redo to data block (file# 4, block# 172 5913) ORA-10564: tablespace USERS ORA-01110: 数据文件 4: 'S:\ORADATA\ORCL\USERS01.DBF' ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# 73907 ORA-00600: 内部错误代码, 参数: [kdourp_inorder2], [34], [43], [44], [44], [], [] , [], [], [], [], [] SQL> recover datafile 4; ORA-00283: 恢复会话因错误而取消 ORA-10562: Error occurred while applying redo to data block (file# 4, block# 1725913) ORA-10564: tablespace USERS ORA-01110: 数据文件 4: 'S:\ORADATA\ORCL\USERS01.DBF' ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# 73907 ORA-00600: 内部错误代码, 参数: [kdourp_inorder2], [34], [43], [44], [44], [], [], [], [], [], [], [] --通过bbed修改异常文件,屏蔽文件恢复,直接open库 SQL> alter database open; 数据库已更改。
数据库open之后,逻辑方式导出数据,重建新库,导入数据.
ORA-600 4042 故障恢复
通过Oracle数据库异常恢复检查脚本(Oracle Database Recovery Check) 检查结果
通过上图可以知道file 2未能正常恢复(需要看日志分析原因),file 3以前就被offline,需要历史归档(非归档状态,所以这个先放着,后续再处理)
分析file 2 不成功原因
Wed Aug 3 15:21:11 2016 ALTER DATABASE RECOVER datafile 2 Wed Aug 3 15:21:11 2016 Media Recovery Start parallel recovery started with 2 processes Wed Aug 3 15:21:11 2016 Recovery of Online Redo Log: Thread 1 Group 1 Seq 1916 Reading mem 0 Mem# 0 errs 0: /home/oracle/orabase/oradata/ORACLE/redo01.log Wed Aug 3 15:21:11 2016 Errors in file /u01/app/oracle/admin/oracle/bdump/oracle_p001_22017.trc: ORA-00600: internal error code, arguments: [3020], [2], [41], [8388649], [], [], [], [] ORA-10567: Redo is inconsistent with data block (file# 2, block# 41) ORA-10564: tablespace UNDOTBS1 ORA-01110: data file 2: '/home/oracle/orabase/oradata/ORACLE/undotbs01.dbf' ORA-10560: block type '0' Wed Aug 3 15:21:13 2016 Errors in file /u01/app/oracle/admin/oracle/bdump/oracle_p001_22017.trc: ORA-00600: internal error code, arguments: [3020], [2], [41], [8388649], [], [], [], [] ORA-10567: Redo is inconsistent with data block (file# 2, block# 41) ORA-10564: tablespace UNDOTBS1 ORA-01110: data file 2: '/home/oracle/orabase/oradata/ORACLE/undotbs01.dbf' ORA-10560: block type '0' Wed Aug 3 15:21:18 2016 Media Recovery failed with error 12801 ORA-283 signalled during: ALTER DATABASE RECOVER datafile 2 ...
通过日志可以知道由于ORA-600 3020导致file 2不能正常的恢复.
处理file 2
SQL> recover datafile 2 allow 1 corruption; Media recovery complete.
Thu Aug 4 01:58:35 2016 ALTER DATABASE RECOVER datafile 2 allow 1 corruption Media Recovery Start ALLOW CORRUPTION option must use serial recovery Thu Aug 4 01:58:35 2016 Recovery of Online Redo Log: Thread 1 Group 1 Seq 1916 Reading mem 0 Mem# 0 errs 0: /home/oracle/orabase/oradata/ORACLE/redo01.log Thu Aug 4 01:58:35 2016 Media Recovery Complete (oracle) Completed: ALTER DATABASE RECOVER datafile 2 allow 1 corruption
尝试open数据库
SQL> alter database open ; alter database open * ERROR at line 1: ORA-01092: ORACLE instance terminated. Disconnection forced
Thu Aug 4 01:59:20 2016 alter database open Thu Aug 4 01:59:21 2016 Beginning crash recovery of 1 threads parallel recovery started with 2 processes Thu Aug 4 01:59:21 2016 Started redo scan Thu Aug 4 01:59:21 2016 Completed redo scan 1619 redo blocks read, 0 data blocks need recovery Thu Aug 4 01:59:21 2016 Started redo application at Thread 1: logseq 1916, block 12724 Thu Aug 4 01:59:21 2016 Recovery of Online Redo Log: Thread 1 Group 1 Seq 1916 Reading mem 0 Mem# 0 errs 0: /home/oracle/orabase/oradata/ORACLE/redo01.log Thu Aug 4 01:59:21 2016 Completed redo application Thu Aug 4 01:59:21 2016 Completed crash recovery at Thread 1: logseq 1916, block 14343, scn 3303614971196 0 data blocks read, 0 data blocks written, 1619 redo blocks read Thu Aug 4 01:59:21 2016 LGWR: STARTING ARCH PROCESSES ARC0 started with pid=18, OS id=5542 Thu Aug 4 01:59:21 2016 ARC0: Archival started ARC1: Archival started LGWR: STARTING ARCH PROCESSES COMPLETE ARC1 started with pid=19, OS id=5544 Thu Aug 4 01:59:21 2016 Thread 1 advanced to log sequence 1917 Thread 1 opened at log sequence 1917 Current log# 2 seq# 1917 mem# 0: /home/oracle/orabase/oradata/ORACLE/redo02.log Successful open of redo thread 1 Thu Aug 4 01:59:21 2016 MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set Thu Aug 4 01:59:21 2016 ARC1: STARTING ARCH PROCESSES Thu Aug 4 01:59:21 2016 ARC0: Becoming the 'no FAL' ARCH ARC0: Becoming the 'no SRL' ARCH Thu Aug 4 01:59:21 2016 SMON: enabling cache recovery Thu Aug 4 01:59:21 2016 ARC2: Archival started ARC1: STARTING ARCH PROCESSES COMPLETE ARC1: Becoming the heartbeat ARCH ARC2 started with pid=20, OS id=5546 Thu Aug 4 01:59:21 2016 db_recovery_file_dest_size of 2048 MB is 1.05% used. This is a user-specified limit on the amount of space that will be used by this database for recovery-related files, and does not reflect the amount of space available in the underlying filesystem or ASM diskgroup. Thu Aug 4 01:59:22 2016 Errors in file /u01/app/oracle/admin/oracle/udump/oracle_ora_5505.trc: ORA-00600: internal error code, arguments: [4042], [0], [], [], [], [], [], [] Thu Aug 4 01:59:23 2016 Errors in file /u01/app/oracle/admin/oracle/udump/oracle_ora_5505.trc: ORA-00600: internal error code, arguments: [4042], [0], [], [], [], [], [], [] Thu Aug 4 01:59:23 2016 Error 600 happened during db open, shutting down database USER: terminating instance due to error 600 Instance terminated by USER, pid = 5505 ORA-1092 signalled during: alter database open ...
由于ORA-600 4042错误导致数据库无法正常open.
分析ORA-600 4042
PARSING IN CURSOR #4 len=142 dep=1 uid=0 oct=3 lid=0 tim=1435788503594313 hv=361892850 ad='a7ab2db8' select /*+ rule */ name,file#,block#,status$,user#,undosqn,xactsqn,scnbas,scnwrp, DECODE(inst#,0,NULL,inst#),ts#,spare1 from undo$ where us#=:1 END OF STMT PARSE #4:c=0,e=11,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=3,tim=1435788503594311 BINDS #4: kkscoacd Bind#0 oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00 oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0 kxsbbbfp=2aae75802218 bln=22 avl=02 flg=05 value=3 EXEC #4:c=0,e=39,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=3,tim=1435788503594393 FETCH #4:c=0,e=8,p=0,cr=2,cu=0,mis=0,r=1,dep=1,og=3,tim=1435788503594412 STAT #4 id=1 cnt=1 pid=0 pos=1 obj=15 op='TABLE ACCESS BY INDEX ROWID UNDO$ (cr=2 pr=0 pw=0 time=8 us)' STAT #4 id=2 cnt=1 pid=1 pos=1 obj=34 op='INDEX UNIQUE SCAN I_UNDO1 (cr=1 pr=0 pw=0 time=3 us)' WAIT #1: nam='db file sequential read' ela= 10 file#=2 block#=41 blocks=1 obj#=-1 tim=1435788503594468 Dump of buffer cache at level 4 for tsn=1, rdba=8388649 BH (0x95ff3c58) file#: 2 rdba: 0x00800029 (2/41) class: 21 ba: 0x95ef0000 set: 3 blksize: 8192 bsi: 0 set-flg: 2 pwbcnt: 0 dbwrid: 0 obj: -1 objn: 0 tsn: 1 afn: 2 hash: [a8b77880,a8b77880] lru: [95ff3dd0,a8e70338] ckptq: [NULL] fileq: [NULL] objq: [a43da110,a43da110] use: [a8e6e658,a8e6e658] wait: [NULL] st: XCURRENT md: SHR tch: 0 flags: gotten_in_current_mode LRBA: [0x0.0.0] HSCN: [0xffff.ffffffff] HSUB: [65535] buffer tsn: 1 rdba: 0x00800029 (2/41) scn: 0x0000.00000000 seq: 0x01 flg: 0x01 tail: 0x00000001 frmt: 0x02 chkval: 0x0000 type: 0x00=unknown Hex dump of block: st=0, typ_found=0 Dump of memory from 0x0000000095EF0000 to 0x0000000095EF2000 095EF0000 0000A200 00800029 00000000 01010000 [....)...........] 095EF0010 00000000 00000000 00000000 00000000 [................] Repeat 509 times 095EF1FF0 00000000 00000000 00000000 00000001 [................] Dump of memory from 0x0000000095EF0014 to 0x0000000095EF1FFC 095EF0010 00000000 00000000 00000000 [............] 095EF0020 00000000 00000000 00000000 00000000 [................]
这里可以发现,file 2 block 41的type为unknown,注意观察ORA-600 3020的错误,我们发现当时报的坏块也正好是该block.基本上可以确定由于前面的allow 1 corruption操作导致了后面的ORA-600 4042的错误.官方关于ORA-600[4042]解释
通过修改undo$中的回滚段状态(参考:bbed修改undo$(回滚段)状态)
正常open数据库,修改file 3的scn并online数据文件
SQL> shutdown immediate; Database closed. Database dismounted. ORACLE instance shut down. SQL> startup mount ORACLE instance started. Total System Global Area 1224736768 bytes Fixed Size 2020384 bytes Variable Size 318770144 bytes Database Buffers 889192448 bytes Redo Buffers 14753792 bytes Database mounted. SQL> SELECT thread#, 2 a.sequence#, 3 a.group#, 4 TO_CHAR (first_change#, '9999999999999999') "SCN", 5 a.status, 6 MEMBER 7 FROM v$log a, v$logfile b 8 WHERE a.group# = B.GROUP# 9 ORDER BY a.sequence# DESC; THREAD# SEQUENCE# GROUP# SCN ---------- ---------- ---------- ---------------------------------- STATUS -------------------------------- MEMBER -------------------------------------------------------------------------------- 1 1919 1 3303615011212 CURRENT /home/oracle/orabase/oradata/ORACLE/redo01.log 1 1918 3 3303614991206 INACTIVE /home/oracle/orabase/oradata/ORACLE/redo03.log THREAD# SEQUENCE# GROUP# SCN ---------- ---------- ---------- ---------------------------------- STATUS -------------------------------- MEMBER -------------------------------------------------------------------------------- 1 1917 2 3303614971197 INACTIVE /home/oracle/orabase/oradata/ORACLE/redo02.log SQL> recover database using backup controlfile; ORA-00279: change 3303615011452 generated at 08/04/2016 02:06:52 needed for thread 1 ORA-00289: suggestion : /u01/app/oracle/flash_recovery_area/ORACLE/archivelog/2016_08_04/o1_mf_1_1919_%u _.arc ORA-00280: change 3303615011452 for thread 1 is in sequence #1919 Specify log: {<RET>=suggested | filename | AUTO | CANCEL} /home/oracle/orabase/oradata/ORACLE/redo01.log Log applied. Media recovery complete. SQL> alter database datafile 3 online; Database altered. SQL> alter database open resetlogs; Database altered. SQL>
至此该数据库基本上恢复完成,强烈建议使用逻辑方式导出导入重建库.
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 |