标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-00742 ORA-01110 ORA-01555 ORA-01578 ORA-01595 ORA-08103 ORA-600 2131 ORA-600 2662 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)
- 操作系统 (103)
- 数据库 (1,749)
- DB2 (22)
- MySQL (76)
- Oracle (1,594)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (162)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (68)
- Oracle Bug (8)
- Oracle RAC (54)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (28)
- Oracle备份恢复 (584)
- Oracle安装升级 (96)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (84)
- PostgreSQL (30)
- pdu工具 (6)
- PostgreSQL恢复 (9)
- SQL Server (30)
- SQL Server恢复 (11)
- TimesTen (7)
- 达梦数据库 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (38)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (21)
-
最近发表
- [MY-013183] [InnoDB] Assertion failure故障处理
- Oracle 19c 202504补丁(RUs+OJVM)-19.27
- Oracle Recovery Tools修复ORA-600 6101/kdxlin:psno out of range故障
- pdu完美支持金仓数据库恢复(KingbaseES)
- 虚拟机故障引起ORA-00310 ORA-00334故障处理
- pg创建gbk字符集库
- PostgreSQL运行日志管理
- ora-600 kdsgrp1 错误描述
- GAM、SGAM 或 PFS 页上存在页错误处理
- ORA-600 krhpfh_03-1208
- VMware勒索加密恢复(vmdk勒索恢复)
- ORA-39773: parse of metadata stream failed故障处理
- sql数据库备份失败—失败: 23(数据错误(循环冗余检查)
- vmdk文件被加密恢复(虚拟机文件加密)
- 差点被误操作的ORA-600 kcratr_nab_less_than_odr故障
- win平台19c 打patch遭遇2个小问题汇总
- pg单个数据库目录恢复-pdu恢复单个数据库目录数据
- pg删除数据恢复—pdu恢复pg delete数据
- .[OnlyBuy@cyberfear.com].REVRAC勒索mysql恢复
- 表dml操作权限授权给public,导致只读用户失效
标签归档:Oracle Recovery Tools
Oracle Recovery Tools修复空闲坏块
我们经常遇到由于某种原因,表上面有坏块,通过event或者dbms包跳过坏块,然后重建该表之后,但是dbv和rman检查坏块依旧存在(而且导致常规情况下rman无法正常备份),最近在Oracle Recovery Tools工具中增加的这种异常数据块修复功能,通过试验重现类似故障:
创建表并进行破坏
C:\Users\XFF>sqlplus / as sysdba SQL*Plus: Release 11.2.0.4.0 Production on 星期一 8月 8 14:00:34 2022 Copyright (c) 1982, 2013, Oracle. All rights reserved. 连接到: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL> create tablespace ts_test datafile 'e:/oradata/test/ts_test.dbf' size 128M autoextend on; 表空间已创建。 SQL> create table t_xifenfei tablespace ts_test 2 as 3 select * from dba_objects; 表已创建。 SQL> alter system checkpoint; 系统已更改。 SQL> set pages 100 SQL> select file_id,block_id,blocks from dba_extents where segment_name='T_XIFENFEI'; FILE_ID BLOCK_ID BLOCKS ---------- ---------- ---------- 5 128 8 5 136 8 5 144 8 5 152 8 5 160 8 5 168 8 5 176 8 5 184 8 5 192 8 5 200 8 5 208 8 5 216 8 5 224 8 5 232 8 5 240 8 5 248 8 5 256 128 5 384 128 5 512 128 5 640 128 5 768 128 5 896 128 5 1024 128 5 1152 128 5 1280 128 已选择25行。 SQL> SELECT COUNT(1) FROM T_XIFENFEI; COUNT(1) ---------- 86048 SQL> shutdown immediate; 数据库已经关闭。 已经卸载数据库。 ORACLE 例程已经关闭。 C:\Windows\system32>dd of=e:/oradata/test/ts_test.dbf if=/dev/zero bs=1k seek=1419 conv=notrunc count=1 rawwrite dd for windows version 0.6beta3. Written by John Newbigin <jn@it.swin.edu.au> This program is covered by terms of the GPL Version 2. notrunc 1+0 records in 1+0 records out SQL> startup ORACLE 例程已经启动。 Total System Global Area 3206836224 bytes Fixed Size 2285512 bytes Variable Size 754974776 bytes Database Buffers 2432696320 bytes Redo Buffers 16879616 bytes 数据库装载完毕。 数据库已经打开。 SQL> select count(1) from t_xifenfei; select count(1) from t_xifenfei * 第 1 行出现错误: ORA-01578: ORACLE 数据块损坏 (文件号 5, 块号 177) ORA-01110: 数据文件 5: 'E:\ORADATA\TEST\TS_TEST.DBF'
跳过坏块重建该表
SQL> alter session set events '10231 trace name context forever, level 10'; 会话已更改。 SQL> create table t_xifenfei_bak tablespace ts_test 2 as select * from t_xifenfei; 表已创建。 SQL> select count(1) from t_xifenfei_bak; COUNT(1) ---------- 85968 SQL> drop table t_xifenfei purge; 表已删除。 SQL> rename t_xifenfei_bak to t_xifenfei; 表已重命名。 SQL> select count(1) from t_xifenfei; COUNT(1) ---------- 85968
检查坏块情况
通过rman和dbv检查,均表明file 5 block 177为坏块
C:\Users\XFF>dbv file=E:\ORADATA\TEST\TS_TEST.DBF DBVERIFY: Release 11.2.0.4.0 - Production on 星期一 8月 8 17:25:57 2022 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. DBVERIFY - 开始验证: FILE = E:\ORADATA\TEST\TS_TEST.DBF 页 177 标记为损坏 Corrupt block relative dba: 0x014000b1 (file 5, block 177) Bad check value found during dbv: Data in bad block: type: 6 format: 2 rdba: 0x014000b1 last change scn: 0x0000.000ebc27 seq: 0x2 flg: 0x04 spare1: 0x0 spare2: 0x0 spare3: 0x0 consistency value in tail: 0xbc270602 check value in block header: 0x5b2a computed block checksum: 0xbb32 DBVERIFY - 验证完成 检查的页总数: 16384 处理的页总数 (数据): 2456 失败的页总数 (数据): 0 处理的页总数 (索引): 0 失败的页总数 (索引): 0 处理的页总数 (其他): 155 处理的总页数 (段) : 0 失败的总页数 (段) : 0 空的页总数: 13772 标记为损坏的总页数: 1 流入的页总数: 0 加密的总页数 : 0 最高块 SCN : 967616 (0.967616) RMAN> backup validate check logical datafile 5; 启动 backup 于 08-8月 -22 使用目标数据库控制文件替代恢复目录 分配的通道: ORA_DISK_1 通道 ORA_DISK_1: SID=118 设备类型=DISK 通道 ORA_DISK_1: 正在启动全部数据文件备份集 通道 ORA_DISK_1: 正在指定备份集内的数据文件 输入数据文件: 文件号=00005 名称=E:\ORADATA\TEST\TS_TEST.DBF 通道 ORA_DISK_1: 备份集已完成, 经过时间:00:00:01 数据文件列表 ================= 文件状态 标记为损坏 空块 已检查的块 高 SCN ---- ------ -------------- ------------ --------------- ---------- 5 FAILED 0 13744 16384 967621 文件名: E:\ORADATA\TEST\TS_TEST.DBF 块类型 失败的块 已处理的块 ---------- -------------- ---------------- 数据 1 2457 索引 0 0 其他 0 183 验证找到一个或多个损坏的块 有关详细信息, 请参阅跟踪文件 C:\APP\XFF\diag\rdbms\test\test\trace\test_ora_22284.trc 完成 backup 于 08-8月 -22 SQL> select * from v$database_block_corruption ; FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO ---------- ---------- ---------- ------------------ --------- 5 177 1 0 CHECKSUM
查询坏块所属对象
没有查询到该坏块所属对象,证明该block为游离块[不属于任何数据对象,是空闲块,但是损坏]
SQL> SELECT OWNER, SEGMENT_NAME, SEGMENT_TYPE, TABLESPACE_NAME, A.PARTITION_NAME 2 FROM DBA_EXTENTS A 3 WHERE FILE_ID = &FILE_ID 4 AND &BLOCK_ID BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS - 1; 输入 file_id 的值: 5 原值 3: WHERE FILE_ID = &FILE_ID 新值 3: WHERE FILE_ID = 5 输入 block_id 的值: 177 原值 4: AND &BLOCK_ID BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS - 1 新值 4: AND 177 BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS - 1 未选定行
再次检查坏块
通过工具修复之后,dbv和rman检查均正常
C:\Users\XFF>rman target / 恢复管理器: Release 11.2.0.4.0 - Production on 星期一 8月 8 17:59:26 2022 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. 已连接到目标数据库: TEST (DBID=2410248200) RMAN> backup validate check logical datafile 5; 启动 backup 于 08-8月 -22 使用目标数据库控制文件替代恢复目录 分配的通道: ORA_DISK_1 通道 ORA_DISK_1: SID=54 设备类型=DISK 通道 ORA_DISK_1: 正在启动全部数据文件备份集 通道 ORA_DISK_1: 正在指定备份集内的数据文件 输入数据文件: 文件号=00005 名称=E:\ORADATA\TEST\TS_TEST.DBF 通道 ORA_DISK_1: 备份集已完成, 经过时间:00:00:01 数据文件列表 ================= 文件状态 标记为损坏 空块 已检查的块 高 SCN ---- ------ -------------- ------------ --------------- ---------- 5 OK 0 13745 16384 967621 文件名: E:\ORADATA\TEST\TS_TEST.DBF 块类型 失败的块 已处理的块 ---------- -------------- ---------------- 数据 0 2456 索引 0 0 其他 0 183 完成 backup 于 08-8月 -22 C:\Users\XFF>dbv file=E:\ORADATA\TEST\TS_TEST.DBF DBVERIFY: Release 11.2.0.4.0 - Production on 星期一 8月 8 17:56:45 2022 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. DBVERIFY - 开始验证: FILE = E:\ORADATA\TEST\TS_TEST.DBF DBVERIFY - 验证完成 检查的页总数: 16384 处理的页总数 (数据): 2456 失败的页总数 (数据): 0 处理的页总数 (索引): 0 失败的页总数 (索引): 0 处理的页总数 (其他): 183 处理的总页数 (段) : 0 失败的总页数 (段) : 0 空的页总数: 13745 标记为损坏的总页数: 0 流入的页总数: 0 加密的总页数 : 0 最高块 SCN : 967621 (0.967621) SQL> select * from v$database_block_corruption ; 未选定行
Oracle Recovery Tools 解决ORA-600 3020故障
尝试recover datafile,部分文件报ORA-600 3020,其他文件recover成功
ALTER DATABASE RECOVER datafile 1 Media Recovery Start Serial Media Recovery started Recovery of Online Redo Log: Thread 1 Group 3 Seq 24972 Reading mem 0 Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO03.LOG Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_72232.trc (incident=749532): ORA-00600: 内部错误代码, 参数: [3020], [1], [272255], [4466559], [], [], [], [], [], [], [], [] ORA-10567: Redo is inconsistent with data block (file# 1, block# 272255, file offset is 2230312960 bytes) ORA-10564: tablespace SYSTEM ORA-01110: 数据文件 1: 'D:\APP\ADMINISTRATOR\ORADATA\ORCL\SYSTEM01.DBF' ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# 383 Media Recovery failed with error 600 ORA-283 signalled during: ALTER DATABASE RECOVER datafile 1 ... Tue Aug 02 10:28:24 2022 Trace dumping is performing id=[cdmp_20220802102824] Tue Aug 02 10:28:31 2022 ALTER DATABASE RECOVER datafile 2 Media Recovery Start Serial Media Recovery started Recovery of Online Redo Log: Thread 1 Group 3 Seq 24972 Reading mem 0 Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO03.LOG Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_72232.trc (incident=749533): ORA-00600: 内部错误代码, 参数: [3020], [2], [92323], [8480931], [], [], [], [], [], [], [], [] ORA-10567: Redo is inconsistent with data block (file# 2, block# 92323, file offset is 756310016 bytes) ORA-10564: tablespace SYSAUX ORA-01110: 数据文件 2: 'D:\APP\ADMINISTRATOR\ORADATA\ORCL\SYSAUX01.DBF' ORA-10561: block type 'TRANSACTION MANAGED INDEX BLOCK', data object# 12330 Media Recovery failed with error 600 ORA-283 signalled during: ALTER DATABASE RECOVER datafile 2 ...
利用Oracle数据库异常恢复检查脚本(Oracle Database Recovery Check)检查文件头相关信息,发现recover 失败的两个文件异常
通过Oracle Recovery Tools工具进行修复

数据库recover 成功,并顺利open

Tue Aug 02 10:56:13 2022 ALTER DATABASE RECOVER datafile 1 Media Recovery Start Serial Media Recovery started Recovery of Online Redo Log: Thread 1 Group 3 Seq 24972 Reading mem 0 Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO03.LOG Completed: ALTER DATABASE RECOVER datafile 1 ALTER DATABASE RECOVER datafile 2 Media Recovery Start Serial Media Recovery started Recovery of Online Redo Log: Thread 1 Group 3 Seq 24972 Reading mem 0 Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO03.LOG Completed: ALTER DATABASE RECOVER datafile 2 Tue Aug 02 10:56:34 2022 alter database open Beginning crash recovery of 1 threads parallel recovery started with 7 processes Started redo scan Completed redo scan read 8504 KB redo, 0 data blocks need recovery Started redo application at Thread 1: logseq 24972, block 2, scn 177712270 Recovery of Online Redo Log: Thread 1 Group 3 Seq 24972 Reading mem 0 Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO03.LOG Completed redo application of 0.00MB Completed crash recovery at Thread 1: logseq 24972, block 17011, scn 177734679 0 data blocks read, 0 data blocks written, 8504 redo k-bytes read Tue Aug 02 10:56:35 2022 Thread 1 advanced to log sequence 24973 (thread open) Thread 1 opened at log sequence 24973 Current log# 1 seq# 24973 mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO01.LOG Successful open of redo thread 1 MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set Tue Aug 02 10:56:35 2022 SMON: enabling cache recovery Successfully onlined Undo Tablespace 2. Dictionary check beginning Tablespace 'TEMP' #3 found in data dictionary, but not in the controlfile. Adding to controlfile. Dictionary check complete Verifying file header compatibility for 11g tablespace encryption.. Verifying 11g file header compatibility for tablespace encryption completed SMON: enabling tx recovery ********************************************************************* WARNING: The following temporary tablespaces contain no files. This condition can occur when a backup controlfile has been restored. It may be necessary to add files to these tablespaces. That can be done using the SQL statement: ALTER TABLESPACE <tablespace_name> ADD TEMPFILE Alternatively, if these temporary tablespaces are no longer needed, then they can be dropped. Empty temporary tablespace: TEMP ********************************************************** WARNING: Files may exists in db_recovery_file_dest that are not known to the database. Use the RMAN command CATALOG RECOVERY AREA to re-catalog any such files. If files cannot be cataloged, then manually delete them using OS command. One of the following events caused this: 1. A backup controlfile was restored. 2. A standby controlfile was restored. 3. The controlfile was re-created. 4. db_recovery_file_dest had previously been enabled and then disabled. ********************************************************** replication_dependency_tracking turned off (no async multimaster replication found) LOGSTDBY: Validating controlfile with logical metadata LOGSTDBY: Validation complete Completed: alter database open
增加tempfile,导出数据该库恢复完成
Oracle Recovery Tools实战批量坏块修复
有客户数据库无法正常启动ORA-600 6711错误
SQL> startup mount pfile='d:/pfile.txt' ORACLE instance started. Total System Global Area 4294964032 bytes Fixed Size 9036608 bytes Variable Size 889192448 bytes Database Buffers 3388997632 bytes Redo Buffers 7737344 bytes Database mounted. SQL> alter database open ; alter database open * ERROR at line 1: ORA-00603: ORACLE server session terminated by fatal error ORA-01092: ORACLE instance terminated. Disconnection forced ORA-00600: internal error code, arguments: [6711], [4313028], [1], [4309898], [0], [], [], [], [], [], [], [] Process ID: 22708 Session ID: 978 Serial number: 56675
alert日志报错
2022-06-26T12:34:41.855326+08:00 alter database open 2022-06-26T12:34:41.984974+08:00 Ping without log force is disabled: instance mounted in exclusive mode. Endian type of dictionary set to little Undo initialization finished serial:0 start:313418906 end:313418906 diff:0 ms (0.0 seconds) Database Characterset is ZHS16GBK No Resource Manager plan active 2022-06-26T12:34:43.302315+08:00 Errors in file C:\APP\XFF\diag\rdbms\orcl\ora19c\trace\ora19c_ora_22708.trc (incident=38629): ORA-00600: internal error code, arguments: [6711], [4313028], [1], [4309898], [0], [], [], [], [], [], [], [] Incident details in: C:\APP\XFF\diag\rdbms\orcl\ora19c\incident\incdir_38629\ora19c_ora_22708_i38629.trc Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. 2022-06-26T12:34:44.232115+08:00 ***************************************************************** An internal routine has requested a dump of selected redo. This usually happens following a specific internal error, when analysis of the redo logs will help Oracle Support with the diagnosis. It is recommended that you retain all the redo logs generated (by all the instances) during the past 12 hours, in case additional redo dumps are required to help with the diagnosis. ***************************************************************** 2022-06-26T12:34:44.315431+08:00 Errors in file C:\APP\XFF\diag\rdbms\orcl\ora19c\trace\ora19c_ora_22708.trc: ORA-00600: internal error code, arguments: [6711], [4313028], [1], [4309898], [0], [], [], [], [], [], [], [] 2022-06-26T12:34:44.315431+08:00 Errors in file C:\APP\XFF\diag\rdbms\orcl\ora19c\trace\ora19c_ora_22708.trc: ORA-00600: internal error code, arguments: [6711], [4313028], [1], [4309898], [0], [], [], [], [], [], [], [] Error 600 happened during db open, shutting down database Errors in file C:\APP\XFF\diag\rdbms\orcl\ora19c\trace\ora19c_ora_22708.trc (incident=38630): ORA-00603: ORACLE server session terminated by fatal error ORA-01092: ORACLE instance terminated. Disconnection forced ORA-00600: internal error code, arguments: [6711], [4313028], [1], [4309898], [0], [], [], [], [], [], [], [] Incident details in: C:\APP\XFF\diag\rdbms\orcl\ora19c\incident\incdir_38630\ora19c_ora_22708_i38630.trc 2022-06-26T12:34:45.266678+08:00 opiodr aborting process unknown ospid (22708) as a result of ORA-603 2022-06-26T12:34:45.274688+08:00 ORA-603 : opitsk aborting process License high water mark = 1 USER (ospid: (prelim)): terminating the instance due to ORA error
通过分析trace文件进行分析,确认是由于histgrm$表异常导致,通过一些特殊处理,绕过该表相关sql,open数据库,并且尝试导出数据
SQL> startup mount pfile='d:/pfile.txt'; ORACLE instance started. Total System Global Area 4294964032 bytes Fixed Size 9036608 bytes Variable Size 889192448 bytes Database Buffers 3388997632 bytes Redo Buffers 7737344 bytes Database mounted. SQL> SQL> SQL> alter database open; Database altered.
通过分析是由于system有坏块导致,dbv检查文件

通过Oracle Recovery Tools工具批量坏块修复功能修复


通过工具修复大量主要坏块被修复,还有一些内部逻辑错误(后续工具继续完善),再次尝试逻辑导出数据,无任何报错,数据比较完美恢复

发表在 小工具, 非常规恢复
标签为 expdp ora-1578, ORA-600 6711, Oracle Recovery Tools, Oracle Recovery Tools修复坏块, 恢复修复
评论关闭