百度360必应搜狗淘宝本站头条
当前位置:网站首页 > 技术教程 > 正文

经典故障:四个雷,3*2*2*3种随机方法的特殊恢复案例

mhr18 2024-09-29 14:02 23 浏览 0 评论

恢复专家前辈给我们精心准备了个故障,埋了四个雷,整个恢复过程感觉像是过山车,整理分享至此,希望对大家有帮助。

恢复文件

就给一个压缩的system,起库。

恢复过程

首先,获取system文件的字符集,数据库名,然后创建参数文件,重建控制文件,这里就不过多介绍,话不多说,先尝试启动数据库。

第一个雷

SQL> startup nomount pfile='/gauss/init.ora';
ORACLE instance started.

Total System Global Area  396668928 bytes
Fixed Size                  2253624 bytes
Variable Size             125832392 bytes
Database Buffers          264241152 bytes
Redo Buffers                4341760 bytes
SQL> @cf
Control file created.
ORA-00279: change 4936537 generated at 04/21/2020 00:03:57 needed for thread 1
ORA-00289: suggestion :
/guass/app/oracle/product/11.2.0/db_1/dbs/arch1_41_1033397865.dbf
ORA-00280: change 4936537 for thread 1 is in sequence #41


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
Media recovery cancelled.
SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 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-01578: ORACLE data block corrupted (file # 1, block # 338)--坏块
ORA-01110: data file 1: '/gauss/system.dbf'
Process ID: 32245
Session ID: 1 Serial number: 3

数据启动报file 1, block 338存在坏块的错误,我们来查一下这个块对应的对象。

TABLESPACE_NAME    SEGMENT_TYPE    OWNER         SEGMENT_NAME
------------------ --------------- ------------- --------------
SYSTEM             INDEX           SYS           I_OBJ1

这个对象是IOBJ1,IOBJ1是什么?

SQL> select * from bootstrap$ where SQL_TEXT like '%I_OBJ1%' order by  LINE#;

     LINE#       OBJ# SQL_TEXT
---------- ---------- --------------------------------------------------------------------------------
        36         36 CREATE UNIQUE INDEX I_OBJ1 ON OBJ$(OBJ#,OWNER#,TYPE#) PCTFREE 10 INITRANS 2 MAXT
                      RANS 255 STORAGE (  INITIAL 64K NEXT 1024K MINEXTENTS 1 MAXEXTENTS 2147483645 PC
                      TINCREASE 0 OBJNO 36 EXTENTS (FILE 1 BLOCK 336))

I_OBJ1是核心基表OBJ$的一个索引,当普通的索引出现坏块,我们可以通过重建去处理,但是OBJ#<59 的索引出现坏块,是不能够通过rebuild的方式处理。数据库open的情况下可以通过swap的方式处理,不过这里我们数据库都没打开。

首先我们先来介绍下数据库启动的过程:

1、在system 表空间的第一个数据文件的特定偏移位置,找到root dba变量

2、root dba变量的值就是指向 sys.bootstrap$表的物理位置的指针

3、sys.bootstrap$表中记录了数据库基础字典表的物理位置

4、基础字典表内记录了用户段段头的物理存储位置

下一步就是要通过某个段的segment header block从数据文件中直接读出表的数据。

在sys.bootstrap$表中记录的数据字典表的create语句,还有一部分是没有直接指定存储位置的,比如簇成员。

那么怎么去爬过第一个雷?这里有两个方案:

1)方法一

最简单的方法就是通过bbed cp同平台同版本的相同块去覆盖。

BBED> copy file 6 block 338 to file 1 block 338 

但是如果I_OBJ1存在大量的坏块情况下,cp的效率比较低。

2)方法二

删除IOBJ1,但是我们这里不是删除IND$里的IOBJ1索引,再次重启的时候又创建了,这里我们需要删除sys.bootstrap里的索引。

BBED> x /rnnc *kdbr[1]
rowdata[3681]                               @7322   
-------------
flag@7322: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@7323: 0x01
cols@7324:    3

col    0[2] @7325: 36
col    1[2] @7328: 36
col  2[208] @7331: CREATE UNIQUE INDEX I_OBJ1 ON OBJ$(OBJ#,OWNER#,TYPE#) P
CTFREE 10 INITRANS 2 MAXTRANS 255 STORAGE (  INITIAL 64K NEXT 1024K MINEXTE
NTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 OBJNO 36 EXTENTS (FILE 1 BLOCK 33
6))

BBED> assign /x offset 7322 =0x3c --删除索引
ub1 rowdata[0]                              @7322     0x3c

BBED>  x /rnnc dba 1,523 *kdbr[1]
rowdata[3681]                               @7322   
-------------
flag@7322: 0x3c (KDRHFL, KDRHFF, KDRHFD, KDRHFH)
lock@7323: 0x01
cols@7324:    0  --已经删除

BBED> sum apply
Check value for File 1, Block 523:
current = 0x7e06, required = 0x7e06

3)方法三

[ora11@zdata bin]$ strings $ORACLE_HOME/bin/oracle |wc -l
1341571

11.2.0.4的执行文件包含1341571个函数,可以通过修改oracle执行文件指定,绕过索引I_OBJ1来处理。

第二个雷

通过上面两种方式排了第一个雷,我们顺利到达第二关。赶紧尝试打开,看看又会报什么错。

SQL> oradebug event 10046 trace name context forever,level 12;
Statement processed.
SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 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 27 with name
"#34; too small
Process ID: 17397
Session ID: 1 Serial number: 5

ORA-01555快照过旧的报错,这个故障熟悉又陌生,尝试去推荐推进低位的scn,发现并没有效果,看来这个雷埋的还是很深的。

当oracle读取一个块,是否需要undo来完成一致性读,有很多种情况:

  1. itl有活动事务,回查undo段头发现事务确实是活动状态,那么肯定要undo来做一致性读;
  2. itl有活动事务,回查undo段头发现事务已经提交或者回滚,那么需要做块清除来确定commit scn,如果query scn<commit scn,则也需要undo来做一致性读块清除一直要找到大于query scn的commit scn,upper的也可以,才会做一致性读 否则直接01555了;
  3. itl事务已经提交 flag为C/U/CU,则扫描itl的commit scn,如果发现有query scn<commit scn,则也需要undo来做一致性读。
WAIT #140193663907536: nam='db file sequential read' ela= 788 file#=1 block#=241 blocks=1 obj#=18 tim=1587333670688800
=====================
PARSING IN CURSOR #140193661586512 len=142 dep=2 uid=0 oct=3 lid=0 tim=1587333670689091 hv=361892850 ad='775596a0' sqlid='7bd391hat42zk'  
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 #140193661586512:c=242,e=243,p=0,cr=0,cu=0,mis=1,r=0,dep=2,og=3,plh=0,tim=1587333670689090
BINDS #140193661586512:

event 10046 trace 发现在访问块241的时候出现故障,这里我们就去看看这个块到底有什么问题。

BBED> p ktbbh
.........省略
         ub2 kxidusn                        @44       0x001b
         ub2 kxidslt                        @46       0x000b
         ub4 kxidsqn                        @48       0x00000186
      struct ktbituba, 8 bytes              @52      
         ub4 kubadba                        @52       0x00c00a97
         ub2 kubaseq                        @56       0x0219
         ub1 kubarec                        @58       0x26
      ub2 ktbitflg                          @60       0x2001 (KTBFUPB)
      union _ktbitun, 2 bytes               @62      
         sb2 _ktbitfsc                      @62       0
         ub2 _ktbitwrp                      @62       0x0000
      ub4 ktbitbas                          @64       0xffffffff --这里被改成0xffffffff

这里低位scn都改成最大值了,难怪怎么poke scn都没效果。。这个雷特么阴险,太坏了。

好了我们知道问题所在了,就是ktbitbas被人工改成0xffffffff,那么恢复方案也有两种。

1)方法一

修改scn,我们手动修改ktbitbas的值。

BBED> assign ktbbhitl[0].ktbitbas=0x004b531f
ub4 ktbitbas                                @64       0x004b531f

2)方法二

既然低位已经最大了,再怎么推也不会超过0xffffffff,那么我们就尝试poke推进高位scn。

SQL> oradebug setmypid
SQL> oradebug dumpvar sga kcsgscn_
kcslf kcsgscn_ [06001AE70, 06001AEA0) = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 6001AB50 00000000
SQL> oradebug poke 0x06001AE74 4 0x50
BEFORE: [06001AE70, 06001AE78) = 00000000 00000000
AFTER:  [06001AE70, 06001AE78) = 004B60E0 00000000

第三个雷

SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-01173: data dictionary indicates missing data file from system tablespace
Process ID: 26639
Session ID: 1 Serial number: 3

看到这个报错,说明顺利进入第三关。

1)方法一

通过一键脚本设置*.corruptedrollback_segments隐患参数,屏蔽回滚段。

*._corrupted_rollback_segments='_SYSSMU28_79026890#39;,'_SYSSMU24_100127047#39;,'_SYSSMU28_79026890#39;,'_SYSSMU21_1449495591#39;,'_SYSSMU24_100127047#39;,'_SYSSMU21_1449495591#39;,'_SYSSMU30_493042799#39;,'_SYSSMU30_493042799#39;,'_SYSSMU23_1725104698#39;,'_SYSSMU23_1725104698#39;,'_SYSSMU22_3628056578#39;,'_SYSSMU22_3628056578#39;,'_SYSSMU25_3360715651#39;,'_SYSSMU22_3628056578#39;,'_SYSSMU25_3360715651#39;,'_SYSSMU22_36280565.......

2)方法二

SQL> select OWNER,SEGMENT_NAME,FILE_ID,BLOCK_ID from dba_extents where segment_name='UNDO#39;;

OWNER      SEGMENT_NAME       FILE_ID   BLOCK_ID
---------- --------------- ---------- ----------
SYS        UNDO$                    1        224

BBED> p ktetb
struct ktetb[0], 8 bytes                    @108     
   ub4 ktetbdba                             @108      0x004000e1--extent的首地址
   ub4 ktetbnbk                             @112      0x00000007--连续7个块

BBED> x /rnc *kdbr[0
rowdata[2337]                               @8146    
-------------
flag@8146: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@8147: 0x00
cols@8148:   17

col    0[1] @8149: 0 
col    1[6] @8151: SYSTEM 
col    2[1] @8158: .
col    3[2] @8160: ..
......省略
BBED> x /rnc *kdbr[1
rowdata[2267]                               @8076    
-------------
flag@8076: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@8077: 0x00
cols@8078:   17

col    0[2] @8079: 1 
col   1[19] @8082: _SYSSMU1_770609302$  --需要删除
col    2[2] @8102: ..
col    3[2] @8105: ..
col    4[3] @8108: ...
......省略

Oracle数据库服务进程在定位某行数据时,采用了数据字典+段头extent map的“集中—分散”存储模式,具体为:

  1. 在数据字典中存放数据段(对应表或分区)头的物理位置;
  2. 在数据段头存放段中所有extent(即连续的block集合)的物理位置 ktetb其实就是UNDO$的extent map,该结构体记录了segment中的extent的首地址 通过一键脚本找到dba 0x004000e1,也就是1,225,然后连续7个块,删除里面除了system的其他所有回滚段,这种方法实际操作太麻烦,大家有兴趣可以挑战下。

第四个雷

趟过前三个雷,恭喜顺利达到第四个雷。这个雷来者不善,毕竟是终极BOSS,处理完这个就要顺利通关了,胜利在望。

SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-03113: end-of-file on communication channel
Process ID: 26280
Session ID: 1 Serial number: 3

这个报错,数据库直接挂了,并没有出现什么错误,设置个10046事件去追踪下。

SQL> oradebug event 10046 trace name context forever,level 12;
SQL> alter database open resetlogs;
alter database open resetlogs

--后台alert的报错
SMON: enabling cache recovery
Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0xD0C5CD7] [PC:0x97DF62E, kgebse()+776] [flags: 0x2, count: 2]
Fri Apr 24 06:42:13 2020
PMON (ospid: 19501): terminating the instance due to error 397

--file#=1 block#=140需要关注
WAIT #140452738872120: nam='db file sequential read' ela= 670 file#=1 block#=140 blocks=1 obj#=0 tim=1587681730297305
Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0xD0C5CD7] [PC:0x97E0BBA, kgegpa()+40] [flags: 0x0, count: 1]
DDE previous invocation failed before phase II
DDE was called in a 'No Invocation Mode'
----- Start Diag Diagnostic Dump -----
Diag diagnostic dump is performed due to an error in the diagfw code during error handling.
DDE is switched to protected mode during the diagnostic dump to prevent recursive errors in the error hadnling code.

从SMON: enabling cache recovery这里其实也能看出来,数据库正在做一些回滚操作,file 1 block 140 对应的是system回滚段,访问到140块的时候数据库直接宕机。

TABLESPACE_NAME      SEGMENT_TYPE       OWNER      SEGMENT_NAME
-------------------- ------------------ ---------- ---------------
SYSTEM               ROLLBACK           SYS        SYSTEM

我来看窥探file 1 block 140 到底有什么问题。

BBED> p dba 1,140 ktubh
struct ktubh, 22 bytes                      @20      
   struct ktubhxid, 8 bytes                 @20      
      ub2 kxidusn                           @20       0x0000
      ub2 kxidslt                           @22       0x003b
      ub4 kxidsqn                           @24       0x0000002b
   ub2 ktubhseq                             @28       0x0025  --seq 是0x0025
   ub1 ktubhcnt                             @30       0x03
   ub1 ktubhirb                             @31       0x03
   ub1 ktubhicl                             @32       0x00
   ub1 ktubhflg                             @33       0x00


BBED> p dba 1,128 ktuxc
struct ktuxc, 104 bytes                     @4148    
   struct ktuxcscn, 8 bytes                 @4148    
      ub4 kscnbas                           @4148     0x004996f7
      ub2 kscnwrp                           @4152     0x0000
   .....省略
   struct ktuxcfbp[0], 12 bytes             @4192    
      struct ktufbuba, 8 bytes              @4192    
         ub4 kubadba                        @4192     0x0040008c
         ub2 kubaseq                        @4196     0x0030   --seq 是0x0030
         ub1 kubarec                        @4198     0x03
      sb2 ktufbext                          @4200     1
      sb2 ktufbspc                          @4202     7340

这里感觉是人为把128块的offset 4196由0x0025改成了0x0030

有三种方案恢复

1)方法一

把128块的offset 4196从0x0030改成了0x0025

BBED> assign dba 1,128 4196=0x0025

2)方法二

需要修改ktuxcnfb和ktuxcfbp[1] 即可。其中将ktuxcnfb修改为0,ktuxcfbp[1]中的uba修改为0,表示回滚的时候让oracle认为没有可以分配的undo块,相当于不回滚。

BBED> modify /x 00 offset 4168

BBED> modify /x 000000 offset 4192 

3)方法三

通过strace跟踪,得到如下的trace。

01:13:27 write(14, "[32]: ktuiup []", 15) = 15 <0.000012>  --ktuiup
01:13:27 write(15, "!gF\n", 4)          = 4 <0.000011>
01:13:27 lseek(14, 0, SEEK_CUR)         = 3425947 <0.000009>
01:13:27 write(14, "\n", 1)             = 1 <0.000011>
01:13:27 write(15, "!A1\n", 4)          = 4 <0.000012>
01:13:27 lseek(14, 0, SEEK_CUR)         = 3425948 <0.000010>
01:13:27 write(14, "[33]: ktuini []", 15) = 15 <0.000012>    ------注意这里ktuini函数
01:13:27 write(15, "!gF\n", 4)          = 4 <0.000011> 
01:13:27 lseek(14, 0, SEEK_CUR)         = 3425963 <0.000009>
01:13:27 write(14, "\n", 1)             = 1 <0.000012>
01:13:27 write(15, "!A1\n", 4)          = 4 <0.000012>
01:13:27 lseek(14, 0, SEEK_CUR)         = 3425964 <0.000010>
01:13:27 write(14, "[34]: adbdrv []", 15) = 15 <0.000011>
01:13:27 write(15, "!gF\n", 4)          = 4 <0.000012>
01:13:27 lseek(14, 0, SEEK_CUR)         = 3425979 <0.000009>
01:13:27 write(14, "\n", 1)             = 1 <0.000012>
01:13:27 write(15, "!A1\n", 4)          = 4 <0.000011>
01:13:27 lseek(14, 0, SEEK_CUR)         = 3425980 <0.000009>
01:13:27 write(14, "[35]: opiexe []", 15) = 15 <0.000012>
01:13:27 write(15, "!gF\n", 4)          = 4 <0.000011>
01:13:27 lseek(14, 0, SEEK_CUR)         = 3425995 <0.000009>
01:13:27 write(14, "\n", 1)             = 1 <0.000012>

注意这里ktuini函数,SEEK_CUR表示文件的相对当前位置,这里也能看出来数据库再做一些recovery的动作,调用ktuiup函数,开始恢复回滚段上的死事务。

既然数据库调用函数ktuini报错,那我们就通过再这个函数设置断点,然后导出数据。

--session 1
(gdb) break ktuini
Breakpoint 1 at 0xf21352
(gdb) c
Continuing.

--session 2
导出数据
export NLS_LANG=AMERICAN_AMERICA.AL32UTF8
exp \'/ as sysdba \' file=/home/ora11/meta.dmp ROWS=n  buffer=102400000

总结

通过这个3x2x2x3种随机方法来处理这个异常恢复案例分享,希望大家有所收获。另外说个题外话,今天是我在恩墨工作的4年第三天,感觉在恩墨工作还是挺有挑战,挺有意思的,尤其晋级的时候,独享与多位大咖交流,面对三小时灵魂式拷问,那种全方位沉浸式体验让人无法忘却。欢迎有志之士,各位踊跃加入恩墨大家庭,we are family!

原文阅读:https://www.modb.pro/db/24687?YYF

更多数据库相关干货,欢迎访问墨天轮官网:https://www.modb.pro/?YYF

相关推荐

jdk17安装和配置环境变量(jdk安装步骤环境变量配置)

简单介绍JDK17是Java的一个长期支持(LTS)版本,于2021年9月发布。作为LTS版本,它将获得Oracle的长期支持,这意味着会获得安全更新和错误修复,直到2...

jdk8安装和配置环境变量(jdk8配置环境变量win10)

简单介绍JDK8是Java开发工具包的一个重大版本,于2014年3月发布。它引入了许多重要的新特性,极大地改进了Java编程的体验,并提高了代码的效率和可读性。总结JDK8是一...

Java开发环境的准备流程!(java开发环境的准备流程有哪些)

准备开发环境工欲善其事,必先利其器。在学习本书的技术内容之前,应先将开发环境搭建好。本书所涉及的基础环境将在本章准备,包括JDK、IntelliJIDEA和Maven。如果读者对这些环境较为熟悉,可...

skywalking-全链路跟踪(链路追踪sleuth)

一、概述1、skywalking简介SkyWalking是一款广受欢迎的国产APM(ApplicationPerformanceMonitoring,应用性能监控)产品,主要针对微服务、Clou...

Oracle项目管理系统之成本状态跟踪

卷首语成本费用管理模块功能分为公司级、项目级两个层级,其中公司级功能包括概预算管理、概预算定额管理、预算模板管理,以及控制估算管理等功能。费用与成本成本费用管理主要是为了合理利用资金资源,控制企业的成...

从入门到精通,Java最全学习路线(java自学路线)

最近好多小伙伴询问,该如何学习java?那些视频适合零基础学习呢?大多数都是一些刚入门的新手,还不了解这个行业,也不知道从何学起,开始的时候非常迷茫,在这给大家整理出一些学习路线。Java学习路线在这...

SPARC M7最新技术 甲骨文首度在台发表

甲骨文首度在台发表SPARCM7最新技术,宣布推出全新SPARC系统產品系列,採用革命性的32内核、256执行绪SPARCM7微处理器。这套SPARC系统提供:先进的入侵防护和加密的Securit...

轻量化的企业级OLAP方案2(轻量化ar)

上一篇文章讲了一个轻量化的企业级OLAP方案,这一篇文章继续介绍另外一个方案。方案2:Greenplum1Greenplum介绍1.1Greenplum概念Greenplum数据库是一种基于Po...

时序数据库在水电站领域的应用(时序数据库优缺点)

大家好,上期经过了王宏志教授对数据库前沿领域的介绍,不知道小伙伴们是否对数据库领域有了更深的认识呢,本期让我们回归时序数据库,再来聊一聊时序数据库在水电站领域的应用。本文仅代表个人观点,如有偏颇之处,...

数据库SQL引擎比较(数据库引擎有哪些,有什么区别)

数据库SQL引擎的典型工作机制及详细分析如下,涵盖查询处理全流程中的核心机制与实际案例:一、SQL引擎核心处理流程1.解析与校验阶段词法/语法解析:SQL语句被拆解为Token序列,构建...

Ubuntu系统密码(root密码)的修改方法

本文介绍在Linux系统的Ubuntu电脑中,修改账户用户密码(同时也修改了root用户密码)的方法。首先,如果此时处于登录页面(也就是意识到自己忘记密码的那个页面),就先点击右上角的关闭按钮...

TablePlus:一个跨平台的数据库管理工具

TablePlus是一款现代化的跨平台(Window、Linux、macOS、iOS)数据库管理工具,提供直观的界面和强大的功能,可以帮助用户轻松管理和操作数据库。TablePlus免费版可以永久...

云满足用户对通过单一视图了解整体运营和数据的需求

ZD至顶网软件频道消息:云在简化IT和业务的同时也带来了新问题,这很有趣,不是吗?毫无疑问,云大幅降低了企业运行基础设施和应用的复杂性和成本;但您仍然面临一个老生常谈的问题——孤岛,只不过这次是在云...

SQL_TOP(显示数据条数)(sqlserver显示查询的行数)

(8)SELECT(9)DISTINCT(11)<topNum><selectlist>(1)FROM[left_table](3)<join_type>...

php搭建小型部门网站(php构建网站)

熟悉前端html,js,css,后端熟悉php,python,java只能称得上一般,还有很多坑待踩。鉴于所学很杂,决定利用对业务的熟悉来搞一个部门网站来简化大家的工作流程。初步设计方案后端用p...

取消回复欢迎 发表评论: