Category Archives: Oracle Recovery Tools

校验代码为 6054 坏块故障修复

Posted on by

联系：手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题：校验代码为 6054 坏块故障修复

作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

有客户反馈数据库操作报错,希望我们给予处理,报错信息如下:
20211204223138

通过对system01.dbf数据文件分析

C:\Users\XFF>dbv file=H:\BAIDUNETDISK\GS6.0BAK20211202\SYSTEM01.DBF

DBVERIFY: Release 11.2.0.4.0 - Production on 星期六 12月 4 20:45:23 2021

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

DBVERIFY - 开始验证: FILE = H:\BAIDUNETDISK\GS6.0BAK20211202\SYSTEM01.DBF

DBV-00200: 块 DBA 4330012 已标记为损坏
csc(0x0000.1686df22) higher than block scn(0x0000.00000000)
页 135708 失败, 校验代码为 6054


DBVERIFY - 验证完成

检查的页总数: 184320
处理的页总数 (数据): 93105
失败的页总数 (数据): 0
处理的页总数 (索引): 31365
失败的页总数 (索引): 1
处理的页总数 (其他): 43622
处理的总页数 (段)  : 1
失败的总页数 (段)  : 0
空的页总数: 16228
标记为损坏的总页数: 1
流入的页总数: 0
加密的总页数        : 0
最高块 SCN            : 378591519 (0.378591519)

确认block 135708 有问题,确认起对象为I_OBJ5

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 的值:  1
原值    3:  WHERE FILE_ID = &FILE_ID
新值    3:  WHERE FILE_ID = 1
输入 block_id 的值:  135708
原值    4:    AND &BLOCK_ID BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS - 1
新值    4:    AND 135708 BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS - 1

OWNER                          SEGMENT_NAME    SEGMENT_TYPE       TABLESPACE_NAME                PARTITION_NAME
------------------------------ --------------- ------------------ ------------------------------ -----------------
SYS                            I_OBJ5          INDEX
                    SYSTEM

这个对象为核心对象obj$的index,无法直接rebuild,当然可以通过参考以前blog文档进行重建:bootstrap$核心index(I_OBJ1,I_USER1,I_FILE#_BLOCK#,I_IND1,I_TS#,I_CDEF1等)异常恢复—ORA-00701错误解决,直接对该坏块进行修复.

BBED> p kcbh
struct kcbh, 20 bytes                       @0
   ub1 type_kcbh                            @0        0x06
   ub1 frmt_kcbh                            @1        0xa2
   ub1 spare1_kcbh                          @2        0x00
   ub1 spare2_kcbh                          @3        0x00
   ub4 rdba_kcbh                            @4        0x0042121c
   ub4 bas_kcbh                             @8        0x00000000
   ub2 wrp_kcbh                             @12       0x0000
   ub1 seq_kcbh                             @14       0xff
   ub1 flg_kcbh                             @15       0x04 (KCBHFCKV)
   ub2 chkval_kcbh                          @16       0xe8c4
   ub2 spare3_kcbh                          @18       0x0000

BBED> m /x 23df8616
 File: H:\BAIDUNETDISK\GS6.0BAK20211202\SYSTEM01.DBF (0)
 Block: 135709           Offsets:    8 to  519           Dba:0x00000000
------------------------------------------------------------------------
 23df8616 00000104 44fe0000 02000000 28000000 22df8616 00000000 02000200
 00000000 0a001800 f7dc1b00 8002c000 bdd80100 00e00000 f331b114 0a001f00
 14081e00 4505c000 2c103b00 01200000 2adf8616 00008009 01000000 3f00a200
 35074010 00000000 e1b24100 56694100 06000000 641f0000 57119211 cd11d208
 97080812 43127e12 b912f412 2f130d09 e013bd09 1b14cc14 0715ab07 5c087d15
 b715f215 a3167007 3507de16 19175417 21088f17 ca170518 4018330a 1f0b7b18
 2c196719 a219dd19 181a531a 8e1a4709 031be607 f809791b b41bef1b 2a1c651c
 db1ce20d 8c1d310d c71d021e 3d1e781e b31e8209 291f291f 291f291f 291f291f
 291f291f 291f0000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

 <32 bytes per line>

然后dbv报以下错误

C:\Users\XFF>dbv file=H:\BAIDUNETDISK\GS6.0BAK20211202\SYSTEM01.DBF

DBVERIFY: Release 11.2.0.4.0 - Production on 星期六 12月 4 22:06:49 2021

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

DBVERIFY - 开始验证: FILE = H:\BAIDUNETDISK\GS6.0BAK20211202\SYSTEM01.DBF
itl[2] has higher commit scn(0x0000.1686df2a) than block scn (0x0000.1686df23)
页 135708 失败, 校验代码为 6056


DBVERIFY - 验证完成

检查的页总数: 184320
处理的页总数 (数据): 95152
失败的页总数 (数据): 0
处理的页总数 (索引): 34569
失败的页总数 (索引): 1
处理的页总数 (其他): 38386
处理的总页数 (段)  : 1
失败的总页数 (段)  : 0
空的页总数: 16213
标记为损坏的总页数: 0
流入的页总数: 0
加密的总页数        : 0
最高块 SCN            : 378683101 (0.378683101)

再次对其进行修复

BBED> m /x 22df8616
 File: H:\BAIDUNETDISK\GS6.0BAK20211202\SYSTEM01.DBF (0)
 Block: 135709           Offsets:   88 to  599           Dba:0x00000000
------------------------------------------------------------------------
 22df8616 00008009 01000000 3f00a200 35074010 00000000 e1b24100 56694100
 06000000 641f0000 57119211 cd11d208 97080812 43127e12 b912f412 2f130d09
 e013bd09 1b14cc14 0715ab07 5c087d15 b715f215 a3167007 3507de16 19175417
 21088f17 ca170518 4018330a 1f0b7b18 2c196719 a219dd19 181a531a 8e1a4709
 031be607 f809791b b41bef1b 2a1c651c db1ce20d 8c1d310d c71d021e 3d1e781e
 b31e8209 291f291f 291f291f 291f291f 291f291f 291f0000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

 <32 bytes per line>

再次dbv检查修复成功

C:\Users\XFF>dbv file=H:\BAIDUNETDISK\GS6.0BAK20211202\SYSTEM01.DBF

DBVERIFY: Release 11.2.0.4.0 - Production on 星期六 12月 4 22:30:14 2021

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

DBVERIFY - 开始验证: FILE = H:\BAIDUNETDISK\GS6.0BAK20211202\SYSTEM01.DBF


DBVERIFY - 验证完成

检查的页总数: 184320
处理的页总数 (数据): 95152
失败的页总数 (数据): 0
处理的页总数 (索引): 34569
失败的页总数 (索引): 0
处理的页总数 (其他): 38386
处理的总页数 (段)  : 1
失败的总页数 (段)  : 0
空的页总数: 16213
标记为损坏的总页数: 0
流入的页总数: 0
加密的总页数        : 0
最高块 SCN            : 378683101 (0.378683101)

对于这类的坏块,也可以通过我们的Oracle recovery tools进行快速恢复
20211204225050

Oracle Recovery Tools恢复—ORA-00704 ORA-01555故障

Posted on by

联系：手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题：Oracle Recovery Tools恢复—ORA-00704 ORA-01555故障

作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

由于虚拟化环境使用了精简模式(预分配),后面出现分布式存储空间不足,导致虚拟化环境中的数据库服务器异常,通过一系列操作恢复好系统,发现数据库无法open,请求我们给予解决
通过我们的Oracle Database Recovery Check脚本分析,分析文件的checkpoint scn 有部分3月2日,还有一些是2月28日,是严重不一致,而且对应的归档也丢失
20210314194011

基于这样的情况,试试看强制打开库

C:\Users\XIFENFEI>sqlplus  / as sysdba

SQL*Plus: Release 11.2.0.4.0 Production on 星期四 3月 11 23:51:39 2021

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> startup mount pfile='d:/pfile.txt'
ORACLE 例程已经启动。

Total System Global Area 1603411968 bytes
Fixed Size                  2281656 bytes
Variable Size             469765960 bytes
Database Buffers         1124073472 bytes
Redo Buffers                7290880 bytes
数据库装载完毕。
SQL> recover database until cancel;
ORA-00279: 更改 57834775 (在 02/28/2021 22:37:35 生成) 对于线程 1 是必需的
ORA-00289: 建议:
D:\APP\XIFENFEI\PRODUCT\11.2.0.4\DBHOME_1\RDBMS\ARC0000003072_1043082043.0001
ORA-00280: 更改 57834775 (用于线程 1) 在序列 #3072 中


指定日志: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
ORA-01547: 警告: RECOVER 成功但 OPEN RESETLOGS 将出现如下错误
ORA-01194: 文件 1 需要更多的恢复来保持一致性
ORA-01110: 数据文件 1: 'D:\BAIDUNETDISKDOWNLOAD\DATA\PROD\SYSTEM01.DBF'


ORA-01112: 未启动介质恢复


SQL> alter database open resetlogs;
alter database open resetlogs
*
第 1 行出现错误:
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00604: error occurred at recursive SQL level 1
ORA-01555: snapshot too old: rollback segment number 10 with name
"_SYSSMU10_1197734989$" too small
进程 ID: 7928
会话 ID: 96 序列号: 3

在数据库open的过程中,报ORA-01555错误,这类问题比较明显以前写过类似文章:
在数据库open过程中常遇到ORA-01555汇总
数据库open过程遭遇ORA-1555对应sql语句补充
使用_allow_resetlogs_corruption导致ORA-00704/ORA-01555故障
这次尝试使用自己开发的小程序:Oracle Recovery Tools进行恢复
20210311235641

然后直接尝试打开数据库成功

SQL> alter database open;
alter database open
*
第 1 行出现错误:
ORA-01113: ?? 1 ??????
ORA-01110: ???? 1: 'D:\BAIDUNETDISKDOWNLOAD\DATA\XFF\SYSTEM01.DBF'


SQL> recover database;
完成介质恢复。
SQL> alter database open;

数据库已更改。

这次证明,对于数据库open过程汇总报ORA-00704 ORA-01555故障,可以通过Oracle Recovery Tools工具一键式open库。
后续安排数据导出,对于个别导出报错的表利用dul进行处理,完成本次恢复任务

Oracle Recovery Tools 解决ORA-01190 ORA-01248等故障

Posted on by

联系：手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题：Oracle Recovery Tools 解决ORA-01190 ORA-01248等故障

作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

今天有一个客户数据库恢复请求,通过Oracle数据库异常恢复检查脚本(Oracle Database Recovery Check)脚本分析发现resetlog信息异常
20210106182747

导致数据库恢复报ORA-01190 ORA-01110错

alter database open
Errors in file c:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_4404.trc:
ORA-01190: 控制文件或数据文件 1 来自最后一个 RESETLOGS 之前
ORA-01110: 数据文件 1: 'C:\APP\ADMINISTRATOR\ORADATA\ORCL\SYSTEM01.DBF'
ORA-1190 signalled during: alter database open...

通过Oracle Recovery Tools工具进行修复resetlog 信息
20210106183450

再次尝试open数据库报ORA-1248错

SQL> alter database open resetlogs;
alter database open resetlogs
*
第 1 行出现错误:
ORA-01248: ?? 44 ????????????
ORA-01110: ???? 44: 'E:\ORADATA\ORCL\XIFENFEI.DBF'

Wed Jan 06 14:44:44 2021
alter database open resetlogs
RESETLOGS is being done without consistancy checks. This may result
in a corrupted database. The database should be recreated.
ORA-1248 signalled during: alter database open resetlogs...

再次通过Oracle Recovery Tools进行修复SCN,数据库open成功

T:\xff>sqlplus / as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on 星期三 1月 6 14:47:36 2021

Copyright (c) 1982, 2010, Oracle.  All rights reserved.

已连接到空闲例程。

SQL> startup mount 
ORACLE 例程已经启动。

Total System Global Area 6.9214E+10 bytes
Fixed Size                  2182712 bytes
Variable Size            3.5165E+10 bytes
Database Buffers         3.3823E+10 bytes
Redo Buffers              224296960 bytes
数据库装载完毕。
SQL>
SQL>
SQL> alter database open;

数据库已更改。

一键恢复ORA-01113 ORA-01110—Oracle Recovery Tools

Posted on by

联系：手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题：一键恢复ORA-01113 ORA-01110—Oracle Recovery Tools

作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

一般由于归档日志丢失或者非归档库可能在数据库启动的时候出现类似如下错误

SQL> startup
ORACLE instance started.

Total System Global Area 2137886720 bytes
Fixed Size                  2282960 bytes
Variable Size             587205168 bytes
Database Buffers         1543503872 bytes
Redo Buffers                4894720 bytes
Database mounted.
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: 'F:\ORADATA\XIFENFEI\SYSTEM01.DBF'

主要是由于数据文件不一致需要比较老的日志,但是日志不存在从而导致该问题
1

以前是通过一系列的方法强制open库,以前类似文章:
12c ORA-01113 ORA-01110 恢复
分享一次ORA-01113 ORA-01110故障处理过程

现在可以通过Oracle Recovery Tools工具一键解决
2
3

尝试open数据库

SQL> recover database;
Media recovery complete.
SQL> alter database open;

Database altered.

Oracle Recovery Tools恢复MISSING00000文件故障

Posted on by

联系：手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题：Oracle Recovery Tools恢复MISSING00000文件故障

作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

前几天介绍了自己开发的Oracle Recovery Tools工具,今天有客户遇到故障,数据库由于断电无法正常启动,第三方对其进行了重建控制文件操作,但是有两个数据文件没有加入到重建控制文件脚本中,当数据库被resetlogs方式打开之后出现如下效果
20200808142132

20200808142248
数据库已经被多次resetlogs打开,这两个丢失的文件无法正常加载进去,通过Oracle Recovery Tools进行处理
20200808143542
这里可以明显看到,resetlogs scn和checkpoint scn均不一样,常规方法肯定无法处理.
20200808143640
直接在恢复库只读情况下把文件加入到数据库中
20200808142722
通过Oracle Recovery Tools点击鼠标就可以快速的解决这类问题,省去的大量的bbed处理的烦劳(在win上要去找bbed软件,要去考虑各种偏移量,修改目标值等)