win70xc000025-(win70xc0000225)

win70xc000025

(win70xc0000225)

恢复专家的前任为我们精心准备了一个故障，埋了四个雷。整个恢复过程感觉像过山车。我希望它能帮助你。

恢复文件

给一个压缩system，起库。

恢复过程

首先，获取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/arch1_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

这个对象是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句子的另一部分没有直接指定存储位置，如簇成员。

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

那怎样才能爬过第一雷呢？这里有两个方案：

1）方法一

最简单的方法是通过bbed cp覆盖同一平台和版本的同一块。BBED> copy file 6 block 338 to file 1 block 338

但是如果I_OBJ1有大量的坏块，cp的效率比较低。

2）方法二

删除IOBJ但我们这里不删除IND$里的IOBJ当索引再次重启时，它又被创建了。在这里我们需要删除它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

3）方法三[ora11@zdata bin]$ strings $ORACLE_HOME/bin/oracle |wc -l1341571

11.2.0.执行文件包含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 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完成一致性阅读的情况有很多:

itl有活动事务，回顾undo段头发现事务确实处于活动状态，所以一定要undo一致性读；itl有活动事务，回顾undo如果段头发现事务已经提交或回滚，则需要清理并确定commit scn，如果query scn<commit scn，则也需要undo清除一致性读块需要找到大于query scn的commit scn，upper也可以，会做一致性读取 否则直接01555；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=&# 39