温馨提示×

温馨提示×

您好,登录后才能下订单哦!

密码登录×
登录注册×
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》

数据库中3*2*2*3种随机的特殊恢复方法是什么

发布时间:2021-11-04 09:33:26 阅读:137 作者:iii 栏目:关系型数据库
亿速云云数据库,读写分离,安全稳定,弹性扩容,低至0.3元/天!! 点击查看>>

这篇文章主要介绍“数据库中3*2*2*3种随机的特殊恢复方法是什么”,在日常操作中,相信很多人在数据库中3*2*2*3种随机的特殊恢复方法是什么问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答”数据库中3*2*2*3种随机的特殊恢复方法是什么”的疑惑有所帮助!接下来,请跟着小编一起来学习吧!

恢复过程

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

第一个雷

SQL> startup nomount pfile='/gauss/init.ora';ORACLE instance started.Total System Global Area  396668928 bytesFixed Size                  2253624 bytesVariable Size             125832392 bytesDatabase Buffers          264241152 bytesRedo Buffers                4341760 bytesSQL> @cfControl file created.ORA-00279: change 4936537 generated at 04/21/2020 00:03:57 needed for thread 1ORA-00289: suggestion :/guass/app/oracle/product/11.2.0/db_1/dbs/arch2_41_1033397865.dbfORA-00280: change 4936537 for thread 1 is in sequence #41Specify log: {<RET>=suggested | filename | AUTO | CANCEL}cancelMedia recovery cancelled.SQL> alter database open resetlogs;alter database open resetlogs*ERROR at line 1:ORA-01092: ORACLE instance terminated. Disconnection forcedORA-00704: bootstrap process failureORA-00704: bootstrap process failureORA-00604: error occurred at recursive SQL level 1ORA-01578: ORACLE data block corrupted (file # 1, block # 338)--坏块ORA-01110: data file 1: '/gauss/system.dbf'Process ID: 32245Session ID: 1 Serial number: 3

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

TABLESPACE_NAME    SEGMENT_TYPE    OWNER         SEGMENT_NAME------------------ --------------- ------------- --------------SYSTEM             INDEX           SYS           I_OBJ1这个对象是I_OBJ1,I_OBJ1是什么?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语句,还有一部分是没有直接指定存储位置的,比如簇成员。

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

方法一

最简单的方法就是通过bbed cp同平台同版本的相同块去覆盖。
BBED> copy file 6 block 338 to file 1 block 338AI代码助手复制代码

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

方法二

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

BBED> x /rnnc *kdbr[1]rowdata[3681]                               @7322-------------flag@7322: 0x2c (KDRHFL, KDRHFF, KDRHFH)lock@7323: 0x01cols@7324:    3col    0[2] @7325: 36col    1[2] @7328: 36col  2[208] @7331: CREATE UNIQUE INDEX I_OBJ1 ON OBJ$(OBJ#,OWNER#,TYPE#) PCTFREE 10 INITRANS 2 MAXTRANS 255 STORAGE (  INITIAL 64K NEXT 1024K MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 OBJNO 36 EXTENTS (FILE 1 BLOCK 336))BBED> assign /x offset 7322 =0x3c --删除索引ub1 rowdata[0]                              @7322     0x3cBBED>  x /rnnc dba 1,523 *kdbr[1]rowdata[3681]                               @7322-------------flag@7322: 0x3c (KDRHFL, KDRHFF, KDRHFD, KDRHFH)lock@7323: 0x01cols@7324:    0  --已经删除BBED> sum applyCheck value for File 1, Block 523:current = 0x7e06, required = 0x7e06

方法三

[ora11@zdata bin]$ strings $ORACLE_HOME/bin/oracle |wc -l1341571AI代码助手复制代码

11.2.0.4的执行文件包含1341571个函数,可以通过修改oracle执行文件指定<hint +full>,绕过索引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 forcedORA-00704: bootstrap process failureORA-00704: bootstrap process failureORA-00604: error occurred at recursive SQL level 1ORA-01555: snapshot too old: rollback segment number 27 with name"$" too smallProcess ID: 17397Session 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#=:1END OF STMTPARSE #140193661586512:c=242,e=243,p=0,cr=0,cu=0,mis=1,r=0,dep=2,og=3,plh=0,tim=1587333670689090BINDS #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,那么恢复方案也有两种。

方法一

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

BBED> assign ktbbhitl[0].ktbitbas=0x004b531fub4 ktbitbas                                @64       0x004b531fAI代码助手复制代码

方法二

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

SQL> oradebug setmypidSQL> oradebug dumpvar sga kcsgscn_kcslf kcsgscn_ [06001AE70, 06001AEA0) = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 6001AB50 00000000SQL> oradebug poke 0x06001AE74 4 0x50BEFORE: [06001AE70, 06001AE78) = 00000000 00000000AFTER:  [06001AE70, 06001AE78) = 004B60E0 00000000

第三个雷

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

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

方法一

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

*._corrupted_rollback_segments='_SYSSMU28_79026890$','_SYSSMU24_100127047$','_SYSSMU28_79026890$','_SYSSMU21_1449495591$','_SYSSMU24_100127047$','_SYSSMU21_1449495591$','_SYSSMU30_493042799$','_SYSSMU30_493042799$','_SYSSMU23_1725104698$','_SYSSMU23_1725104698$','_SYSSMU22_3628056578$','_SYSSMU22_3628056578$','_SYSSMU25_3360715651$','_SYSSMU22_3628056578$','_SYSSMU25_3360715651$','_SYSSMU22_36280565.......AI代码助手复制代码

方法二

SQL> select OWNER,SEGMENT_NAME,FILE_ID,BLOCK_ID from dba_extents where segment_name='UNDO$';OWNER      SEGMENT_NAME       FILE_ID   BLOCK_ID---------- --------------- ---------- ----------SYS        UNDO$                    1        224BBED> p ktetbstruct ktetb[0], 8 bytes                    @108   ub4 ktetbdba                             @108      0x004000e1--extent的首地址   ub4 ktetbnbk                             @112      0x00000007--连续7个块BBED> x /rnc *kdbr[0rowdata[2337]                               @8146-------------flag@8146: 0x2c (KDRHFL, KDRHFF, KDRHFH)lock@8147: 0x00cols@8148:   17col    0[1] @8149: 0col    1[6] @8151: SYSTEMcol    2[1] @8158: .col    3[2] @8160: ........省略BBED> x /rnc *kdbr[1rowdata[2267]                               @8076-------------flag@8076: 0x2c (KDRHFL, KDRHFF, KDRHFH)lock@8077: 0x00cols@8078:   17col    0[2] @8079: 1col   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 channelProcess ID: 26280Session 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 recoveryException [type: SIGSEGV, Address not mapped to object] [ADDR:0xD0C5CD7] [PC:0x97DF62E, kgebse()+776] [flags: 0x2, count: 2]Fri Apr 24 06:42:13 2020PMON (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=1587681730297305Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0xD0C5CD7] [PC:0x97E0BBA, kgegpa()+40] [flags: 0x0, count: 1]DDE previous invocation failed before phase IIDDE 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        SYSTEMAI代码助手复制代码
我来看窥探file 1 block 140 到底有什么问题。
BBED> p dba 1,140 ktubhstruct 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       0x00BBED> p dba 1,128 ktuxcstruct 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 41960x0025改成了0x0030
有三种方案恢复
方法一

把128块的offset 4196从0x0030改成了0x0025
BBED> assign dba 1,128 4196=0x0025ub2 kubaseq                                 @4196     0x0025

方法二

需要修改ktuxcnfb和ktuxcfbp[1] 即可。其中将ktuxcnfb修改为0,ktuxcfbp[1]中的uba修改为0,表示回滚的时候让oracle认为没有可以分配的undo块,相当于不回滚。
BBED> modify /x 00 offset 4168BBED> modify /x 000000 offset 4192AI代码助手复制代码方法三通过strace跟踪,得到如下的trace。
01:13:27 write(14, "[32]: ktuiup []", 15) = 15 <0.000012>  --ktuiup01: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 ktuiniBreakpoint 1 at 0xf21352(gdb) cContinuing.--session 2导出数据export NLS_LANG=AMERICAN_AMERICA.AL32UTF8exp \'/ as sysdba \' file=/home/ora11/meta.dmp ROWS=n  buffer=102400000AI代码助手复制代码

到此,关于“数据库中3*2*2*3种随机的特殊恢复方法是什么”的学习就结束了,希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习,快去试试吧!若想继续学习更多相关知识,请继续关注亿速云网站,小编会继续努力为大家带来更多实用的文章!

亿速云「云数据库 MySQL」免部署即开即用,比自行安装部署数据库高出1倍以上的性能,双节点冗余防止单节点故障,数据自动定期备份随时恢复。点击查看>>

向AI问一下细节

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

原文链接:http://blog.itpub.net/31556440/viewspace-2701008/

AI

开发者交流群×