Category Archives: Oracle备份恢复

通过odu验证rman backup对于truncate对象备份处理

Posted on by

rman backup 对于truncate和drop等相关操作的extent到底是怎么处理的,这里通过rman backup 结合odu证明出来,在较新版本的rman中,rman backup 并未完全的备份这些被认为不需要的extent.
创建模拟环境

SQL> select * from v$version;
 
BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Prod
PL/SQL Release 10.2.0.4.0 - Production
CORE    10.2.0.4.0      Production
TNS for Linux: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production

SQL> create tablespace xifenfei datafile '/u01/oracle/oradata/XFF/xifenfei01.dbf' 
   2 size 10m autoextend on maxsize 10g;

Tablespace created.

SQL> conn chf/xifenfei
Connected.

SQL> create table t_xifenfei tablespace xifenfei
  2  as
  3  select * from dba_objects;

Table created.

SQL> insert into t_xifenfei
  2  select * from dba_objects;

50055 rows created.

SQL> commit;

Commit complete.

SQL> select BYTES from dba_free_space where TABLESPACE_NAME='XIFENFEI';

     BYTES
----------
    983040

SQL> select BYTES from v$datafile where name='/u01/oracle/oradata/XFF/xifenfei01.dbf';

     BYTES
----------
  12582912

SQL> select 12582912-983040 from dual;

12582912-983040
---------------
       11599872

SQL> select object_id,data_object_id from dba_objects where object_name='T_XIFENFEI';

 OBJECT_ID DATA_OBJECT_ID
---------- --------------
     51833          51833

--这里我们得到信息有:
--1.dataobj#=51833
--2.使用数据文件空间为:11599872

rman备份no truncate table 数据文件

[oracle@xifenfei ~]$ rman target /

Recovery Manager: Release 10.2.0.4.0 - Production on Thu Dec 15 06:00:05 2011

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

connected to target database: XFF (DBID=3440302261)

RMAN> backup tablespace xifenfei format '/u01/oracle/oradata/tmp/no_truncate_xifenfei';

Starting backup at 15-DEC-11
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=158 devtype=DISK
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00005 name=/u01/oracle/oradata/XFF/xifenfei01.dbf
channel ORA_DISK_1: starting piece 1 at 15-DEC-11
channel ORA_DISK_1: finished piece 1 at 15-DEC-11
piece handle=/u01/oracle/oradata/tmp/no_truncate_xifenfei tag=TAG20111215T060343 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
Finished backup at 15-DEC-11

truncate table 操作

[oracle@xifenfei ~]$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.4.0 - Production on Thu Dec 15 06:03:58 2011

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.


Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> truncate table chf.t_xifenfei;

Table truncated.

rman备份truncate table 数据文件

RMAN> backup tablespace xifenfei format '/u01/oracle/oradata/tmp/truncate_xifenfei';

Starting backup at 15-DEC-11
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=140 devtype=DISK
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00005 name=/u01/oracle/oradata/XFF/xifenfei01.dbf
channel ORA_DISK_1: starting piece 1 at 15-DEC-11
channel ORA_DISK_1: finished piece 1 at 15-DEC-11
piece handle=/u01/oracle/oradata/tmp/truncate_xifenfei tag=TAG20111215T060445 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 15-DEC-11

[root@xifenfei ~]# ls -l /u01/oracle/oradata/tmp/*_xifenfei
-rw-r----- 1 oracle oinstall 11640832 Dec 15 06:03 /u01/oracle/oradata/tmp/no_truncate_xifenfei
-rw-r----- 1 oracle oinstall   630784 Dec 15 06:04 /u01/oracle/oradata/tmp/truncate_xifenfei

odu挖rman备份前数据文件

ODU> unload dict
CLUSTER C_USER# file_no: 1 block_no: 89
TABLE OBJ$ file_no: 1 block_no: 121
CLUSTER C_OBJ# file_no: 1 block_no: 25
CLUSTER C_OBJ# file_no: 1 block_no: 25
found IND$'s obj# 19
found IND$'s dataobj#:2,ts#:0,file#:1,block#:25,tab#:3
found TABPART$'s obj# 266
found TABPART$'s dataobj#:266,ts#:0,file#:1,block#:2121,tab#:0
found INDPART$'s obj# 271
found INDPART$'s dataobj#:271,ts#:0,file#:1,block#:2161,tab#:0
found TABSUBPART$'s obj# 278
found TABSUBPART$'s dataobj#:278,ts#:0,file#:1,block#:2217,tab#:0
found INDSUBPART$'s obj# 283
found INDSUBPART$'s dataobj#:283,ts#:0,file#:1,block#:2257,tab#:0
found IND$'s obj# 19
found IND$'s dataobj#:2,ts#:0,file#:1,block#:25,tab#:3
found LOB$'s obj# 151
found LOB$'s dataobj#:2,ts#:0,file#:1,block#:25,tab#:6
found LOBFRAG$'s obj# 299
found LOBFRAG$'s dataobj#:299,ts#:0,file#:1,block#:2393,tab#:0

ODU> scan extent tablespace 6

scan extent start: 2011-12-15 06:12:28
scanning extent...
scanning extent finished.
scan extent completed: 2011-12-15 06:12:28

ODU> unload table chf.t_xifenfei object 51833 

Unloading table: T_XIFENFEI,object ID: 51833
Unloading segment,storage(Obj#=51833 DataObj#=51833 TS#=6 File#=5 Block#=11 Cluster=0)
100110 rows unloaded
--这里可以看到odu全部找到被truncate掉的记录条数

使用rman 备份后数据文件

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> exit
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
[oracle@xifenfei odu]$ rm /u01/oracle/oradata/XFF/xifenfei01.dbf
[oracle@xifenfei odu]$ rman target /

Recovery Manager: Release 10.2.0.4.0 - Production on Thu Dec 15 06:14:00 2011

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

connected to target database (not started)

RMAN> startup mount;

Oracle instance started
database mounted

Total System Global Area     318767104 bytes

Fixed Size                     1267236 bytes
Variable Size                104860124 bytes
Database Buffers             205520896 bytes
Redo Buffers                   7118848 bytes

RMAN> restore datafile 5;

Starting restore at 15-DEC-11
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=157 devtype=DISK

channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00005 to /u01/oracle/oradata/XFF/xifenfei01.dbf
channel ORA_DISK_1: reading from backup piece /u01/oracle/oradata/tmp/truncate_xifenfei
channel ORA_DISK_1: restored backup piece 1
piece handle=/u01/oracle/oradata/tmp/truncate_xifenfei tag=TAG20111215T060445
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
Finished restore at 15-DEC-11

odu挖rman还原后数据文件

ODU> scan extent tablespace 6

scan extent start: 2011-12-15 06:14:43
scanning extent...
scanning extent finished.
scan extent completed: 2011-12-15 06:14:43

ODU>  unload table chf.t_xifenfei object 51833 

Unloading table: T_XIFENFEI,object ID: 51833
Unloading segment,storage(Obj#=51833 DataObj#=51833 TS#=6 File#=5 Block#=11 Cluster=0)
4774 rows unloaded
--odu只找到极少数数据4774/100110

通过odu挖rman备份前和备份后的数据文件,得知rman backup备份的过程,对绝大多数truncate的表的原始数据未正常备份(为什么是绝大多数,我无法给出解释),这里也可以看出rman backup并非是真正意义上的完全物理上复制(和rman copy还是有区别,copy不能完全被取代)

rman备份对各种数据块操作

Posted on by

有不少人对于rman的backup功能,到底备份数据文件的什么级别,一直有着不明确的说法,我这里以10.2.0.4版本的rman backup 测试,进行一个简单的说明.这里提供的是一种思路.如果你在实际工作中,遇到一些rman到底会不会备份相关数据块的时候,可以通过类此的试验来证明你的版本的rman的功能.
模拟环境

SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Prod
PL/SQL Release 10.2.0.4.0 - Production
CORE    10.2.0.4.0      Production
TNS for Linux: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production

SQL> create tablespace xifenfei datafile '/u01/oracle/oradata/XFF/xifenfei01.dbf' 
   2 size 10m autoextend on next 10m maxsize 30g;

Tablespace created.

备份空数据文件

SQL> select BYTES from v$datafile where name='/u01/oracle/oradata/XFF/xifenfei01.dbf';

     BYTES
----------
  10485760

SQL> select BYTES from dba_free_space where TABLESPACE_NAME='XIFENFEI';

     BYTES
----------
  10420224

SQL> SELECT 10485760-10420224 FROM DUAL;

10485760-10420224
-----------------
            65536

RMAN> backup tablespace xifenfei format '/u01/oracle/oradata/tmp/no_table_xifenfei';

[root@xifenfei tmp]# ls -l no_table_xifenfei
-rw-r----- 1 oracle oinstall 106496 Dec 15 01:03 no_table_xifenfei

从这里可以看出来rman备份的时候,数据文件中未格式化的块并没有备份(数据文件10m,备份集只有106k左右,比文件实际使用的65536b稍微大点)

备份create表数据文件

SQL> create table t_rman tablespace xifenfei
  2  as
  3  select * from chf.t_xifenfei1;

Table created.

SQL> select BYTES from dba_free_space where TABLESPACE_NAME='XIFENFEI';

     BYTES
----------
   9371648

SQL> select BYTES from v$datafile where name='/u01/oracle/oradata/XFF/xifenfei01.dbf';

     BYTES
----------
  20971520

SQL> select 20971520-9371648 from dual;

20971520-9371648
----------------
        11599872

RMAN> backup tablespace xifenfei format '/u01/oracle/oradata/tmp/crt_table_xifenfei';

[root@xifenfei ~]# ls -l /u01/oracle/oradata/tmp/crt_table_xifenfei
-rw-r----- 1 oracle oinstall 11608064 Dec 15 01:29 /u01/oracle/oradata/tmp/crt_table_xifenfei

这里可以得出结论,rman的备份集大小可以从一定程度上近似等于数据文件使用空间大小

备份truncate表数据文件

SQL> truncate table t_rman;

Table truncated.

SQL> SELECT 20840448-9371648 from dual;

20840448-9371648
----------------
        11468800

SQL> select 20971520-20840448 from dual;

20971520-20840448
-----------------
           131072

RMAN>  backup tablespace xifenfei format '/u01/oracle/oradata/tmp/truncate_table_xifenfei';

[root@xifenfei ~]# ls -l /u01/oracle/oradata/tmp/truncate_table_xifenfei
-rw-r----- 1 oracle oinstall 630784 Dec 15 01:30 /u01/oracle/oradata/tmp/truncate_table_xifenfei

通过这里可以看出来,truncate 对象后,数据文件释放了对象空间,rman备份集也同样未备份这部分空间

备份insert表数据文件

SQL> insert into t_rman  select * from chf.t_xifenfei1;

100062 rows created.

SQL> commit;

Commit complete.

SQL> alter system checkpoint;

System altered.

SQL> select BYTES from v$datafile where name='/u01/oracle/oradata/XFF/xifenfei01.dbf';

     BYTES
----------
  20971520

SQL> select BYTES from dba_free_space where TABLESPACE_NAME='XIFENFEI';

     BYTES
----------
   9371648

SQL>  select 20971520 - 9371648 from dual;

20971520-9371648
----------------
        11599872

RMAN> backup tablespace xifenfei format '/u01/oracle/oradata/tmp/insert_table_xifenfei';

[root@xifenfei ~]# ls -l /u01/oracle/oradata/tmp/insert_table_xifenfei
-rw-r----- 1 oracle oinstall 11640832 Dec 15 02:19 /u01/oracle/oradata/tmp/insert_table_xifenfei

和直接创建表的出来结论相似

备份delete表数据文件

SQL> delete from t_rman;

100062 rows deleted.

SQL> commit;

Commit complete.

SQL>  alter system checkpoint;

System altered.

SQL> select BYTES from v$datafile where name='/u01/oracle/oradata/XFF/xifenfei01.dbf';

     BYTES
----------
  20971520

SQL>  select BYTES from dba_free_space where TABLESPACE_NAME='XIFENFEI';

     BYTES
----------
   9371648

SQL> select 20971520 - 9371648 from dual;

20971520-9371648
----------------
        11599872

RMAN> backup tablespace xifenfei format '/u01/oracle/oradata/tmp/delete_table_xifenfei';

[root@xifenfei ~]# ls -l /u01/oracle/oradata/tmp/delete_table_xifenfei
-rw-r----- 1 oracle oinstall 11640832 Dec 15 02:45 /u01/oracle/oradata/tmp/delete_table_xifenfei

这里是直接delete数据,产生了明显的高水位现象(高水位之下部分无数据),但是rman备份,还是会备份高水位之下的所有数据

备份drop表数据文件

SQL> drop table t_rman;

Table dropped.

SQL> select BYTES from v$datafile where name='/u01/oracle/oradata/XFF/xifenfei01.dbf';

     BYTES
----------
  20971520

SQL> select BYTES from v$datafile where name='/u01/oracle/oradata/XFF/xifenfei01.dbf';

     BYTES
----------
  20971520
SQL> select sum(bytes) from  dba_free_space where TABLESPACE_NAME='XIFENFEI';

SUM(BYTES)
----------
  20905984

SQL> select 20971520-20905984 from dual;

20971520-20905984
-----------------
            65536

RMAN> backup tablespace xifenfei format '/u01/oracle/oradata/tmp/drop_table_xifenfei';

[root@xifenfei ~]# ls -l /u01/oracle/oradata/tmp/drop_table_xifenfei
-rw-r----- 1 oracle oinstall 11640832 Dec 15 02:51 /u01/oracle/oradata/tmp/drop_table_xifenfei

在10g中,因为默认使用回收站功能,对象还存在回收站中,rman为了使得还原出来的数据库可以继续使用回收站中相应的表的闪回功能,所以也会备份回收站中数据

备份purge表数据文件

SQL> select OBJECT_NAME,ORIGINAL_NAME from user_recyclebin;

OBJECT_NAME                    ORIGINAL_NAME
------------------------------ --------------------------------
BIN$tBHa31bTe3jgQKjACgEImw==$0 T_RMAN

SQL> purge table "BIN$tBHa31bTe3jgQKjACgEImw==$0";

Table purged.

RMAN> backup tablespace xifenfei format '/u01/oracle/oradata/tmp/PURGE_table_xifenfei';

[root@xifenfei ~]# ls -l /u01/oracle/oradata/tmp/PURGE_table_xifenfei
-rw-r----- 1 oracle oinstall 106496 Dec 15 03:08 /u01/oracle/oradata/tmp/PURGE_table_xifenfei

可以看到purge表之后,其实效果类此truncate(当然truncate做的工作更多),rman备份集大小和无数据对象时相同,结合drop和purge也可以知道在删除大对象或者比较多对象而且又确定不再需要,且有rman备份,这个时候建议直接加上purge.

各个备份集汇总

[root@xifenfei tmp]# ll *table_xifenfei
-rw-r----- 1 oracle oinstall 11608064 Dec 15 01:29 crt_table_xifenfei
-rw-r----- 1 oracle oinstall 11640832 Dec 15 02:45 delete_table_xifenfei
-rw-r----- 1 oracle oinstall 11640832 Dec 15 02:51 drop_table_xifenfei
-rw-r----- 1 oracle oinstall 11640832 Dec 15 02:19 insert_table_xifenfei
-rw-r----- 1 oracle oinstall   106496 Dec 15 01:03 no_table_xifenfei
-rw-r----- 1 oracle oinstall   106496 Dec 15 03:08 PURGE_table_xifenfei
-rw-r----- 1 oracle oinstall   630784 Dec 15 01:30 truncate_table_xifenfei

rman的备份功能本身就是在不断的增强,不同的版本会有不同的结果,最明显的就是在9i版本会备份truncate的数据.

SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
PL/SQL Release 9.2.0.4.0 - Production
CORE    9.2.0.3.0       Production
TNS for Linux: Version 9.2.0.4.0 - Production
NLSRTL Version 9.2.0.4.0 - Production

SQL> create tablespace xifenfei datafile
  2  '/u01/oracle/oradata/xifenfei/xifenfei01.dbf' size 10m autoextend on next 10m maxsize 10240m;

Tablespace created.

SQL> create table t_xifenfei tablespace xifenfei
  2  as
  3  select * from dba_objects;

Table created.

SQL> insert into t_xifenfei
  2  select * from dba_objects;

30803 rows created.

SQL> commit;

Commit complete.

SQL> alter system checkpoint;

System altered.

RMAN> backup tablespace xifenfei format '/tmp/no_truncate_xifenfei';

SQL> truncate table t_xifenfei;

Table truncated.

[oracle@xifenfei ~]$ ls -l /tmp/*truncate_xifenfei
-rw-r-----  1 oracle oinstall 7004160 Aug 26 22:52 /tmp/no_truncate_xifenfei
-rw-r-----  1 oracle oinstall 7004160 Aug 26 22:53 /tmp/truncate_xifenfei

bbed 使用实现 drop index 操作

Posted on by

这里个bbed的测试是为了实现通过bbed来实现删除index,该方法有两个用途:
1.数据库因为index出了问题不能启动,使用该方法可以屏蔽index,来实现数据库正常启动
2.bootstrap$中的某个index异常
准备环境

SQL> conn chf/xifenfei
Connected.
SQL>  create table t_xifenfei
  2  as
  3  select * from dba_objects;

Table created.

SQL> create index ind_t_xifenfei on t_xifenfei(object_id);

Index created.

SQL> SET LINES 150
SQL> col owner for a5 
SQL> select OWNER,INDEX_NAME,TABLE_NAME,status from dba_indexes where index_name='IND_T_XIFENFEI';

OWNER INDEX_NAME                     TABLE_NAME                     STATUS
----- ------------------------------ ------------------------------ --------
CHF   IND_T_XIFENFEI                 T_XIFENFEI                     VALID

SQL> select object_id from dba_objects where object_name='IND_T_XIFENFEI';

 OBJECT_ID
----------
     75558

SQL> select obj#,dataobj#,ts#,file#,block#,bo#,FLAGS from sys.ind$ where obj#=75558;

      OBJ#   DATAOBJ#        TS#      FILE#     BLOCK#        BO#      FLAGS
---------- ---------- ---------- ---------- ---------- ---------- ----------
     75558      75558          4          4        298      75557          2

SQL> select   rowid,
  2  dbms_rowid.rowid_relative_fno(rowid)rel_fno,
  3  dbms_rowid.rowid_block_number(rowid)blockno,
  4  dbms_rowid.rowid_row_number(rowid) rowno
  5  from sys.ind$ where obj#=75558;

ROWID                 REL_FNO    BLOCKNO      ROWNO
------------------ ---------- ---------- ----------
AAAAACAABAAAT50AAA          1      81524          0

SQL>  alter system checkpoint;

System altered.

SQL> select dump(75558,'16') from dual;

DUMP(75558,'16')
-----------------------
Typ=2 Len=4: c3,8,38,3b

SQL> select dump(4,'16') from dual;

DUMP(4,'16')
-----------------
Typ=2 Len=2: c1,5

SQL> select dump(298,'16') from dual;

DUMP(298,'16')
--------------------
Typ=2 Len=3: c2,3,63

SQL> select dump(75557,'16') from dual;

DUMP(75557,'16')
-----------------------
Typ=2 Len=4: c3,8,38,3a

SQL> conn / as sysdba
Connected.
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.

删除ind$中记录

[oracle@xifenfei ~]$ bbed listfile=listfile mode=edit password=blockedit

BBED: Release 2.0.0.0.0 - Limited Production on Thu Aug 9 17:09:55 2012

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

************* !!! For Oracle Internal Use only !!! ***************

BBED> info all
 File#  Name                                                        Size(blks)
 -----  ----                                                        ----------
     1  /u01/oracle/oradata/ora11g/system01.dbf                              0
     2  /u01/oracle/oradata/ora11g/sysaux01.dbf                              0
     3  /u01/oracle/oradata/ora11g/undotbs01.dbf                             0
     4  /u01/oracle/oradata/ora11g/users01.dbf                               0

BBED> set file 1 block 81524
        FILE#           1
        BLOCK#          81524

BBED> map
 File: /u01/oracle/oradata/ora11g/system01.dbf (1)
 Block: 81524                                 Dba:0x00413e74
------------------------------------------------------------
 KTB Data Block (Table/Cluster)

 struct kcbh, 20 bytes                      @0       

 struct ktbbh, 72 bytes                     @20      

 struct kdbh, 14 bytes                      @92      

 struct kdbt[6], 24 bytes                   @106     

 sb2 kdbr[33]                               @130     

 ub1 freespace[5420]                        @196     

 ub1 rowdata[2572]                          @5616    

 ub4 tailchk                                @8188    


BBED> p kdbr
sb2 kdbr[0]                                 @130      8074
sb2 kdbr[1]                                 @132      7987
sb2 kdbr[2]                                 @134      7896
sb2 kdbr[3]                                 @136      7618
sb2 kdbr[4]                                 @138      7523
sb2 kdbr[5]                                 @140      6700
sb2 kdbr[6]                                 @142      6573
sb2 kdbr[7]                                 @144      5524
sb2 kdbr[8]                                 @146      5633
sb2 kdbr[9]                                 @148     -1
sb2 kdbr[10]                                @150      7771
sb2 kdbr[11]                                @152      7703
sb2 kdbr[12]                                @154      7642
sb2 kdbr[13]                                @156      7546
sb2 kdbr[14]                                @158      7459
sb2 kdbr[15]                                @160      7397
sb2 kdbr[16]                                @162      7330
sb2 kdbr[17]                                @164      7267
sb2 kdbr[18]                                @166      6516
sb2 kdbr[19]                                @168      6450
sb2 kdbr[20]                                @170      6384
sb2 kdbr[21]                                @172      6327
sb2 kdbr[22]                                @174      6265
sb2 kdbr[23]                                @176      6202
sb2 kdbr[24]                                @178      6147
sb2 kdbr[25]                                @180      6086
sb2 kdbr[26]                                @182      6025
sb2 kdbr[27]                                @184      5967
sb2 kdbr[28]                                @186      5906
sb2 kdbr[29]                                @188      5845
sb2 kdbr[30]                                @190      5784
sb2 kdbr[31]                                @192      5727
sb2 kdbr[32]                                @194      5663

--这里使用直接查看的方法,来找出来ind$中相关记录,实际中方法很多find/第三方工具都可以
BBED> p *kdbr[0]
rowdata[2550]
-------------
ub1 rowdata[2550]                           @8166     0xac

BBED> x /rn
rowdata[2550]                               @8166    
-------------
flag@8166: 0xac (KDRHFL, KDRHFF, KDRHFH, KDRHFK)
lock@8167: 0x00
cols@8168:    1
kref@8169:    1
mref@8171:    1
hrid@8173:0x00400095.1
nrid@8179:0x00400095.1

col    0[2] @8185: 80 


BBED> p *kdbr[1]
rowdata[2463]
-------------
ub1 rowdata[2463]                           @8079     0xac

BBED> x /rn
rowdata[2463]                               @8079    
-------------
flag@8079: 0xac (KDRHFL, KDRHFF, KDRHFH, KDRHFK)
lock@8080: 0x00
cols@8081:    1
kref@8082:    1
mref@8084:    1
hrid@8086:0x004000a1.1
nrid@8092:0x004000a1.1

col    0[3] @8098: 330 


BBED> p *kdbr[2]
rowdata[2372]
-------------
ub1 rowdata[2372]                           @7988     0xac


BBED> x /rn
rowdata[2372]                               @7988    
-------------
flag@7988: 0xac (KDRHFL, KDRHFF, KDRHFH, KDRHFK)
lock@7989: 0x00
cols@7990:    1
kref@7991:    1
mref@7993:    1
hrid@7995:0x004000a7.6
nrid@8001:0x004000a7.6

col    0[3] @8007: 471 


BBED> p *kdbr[3]
rowdata[2094]
-------------
ub1 rowdata[2094]                           @7710     0xac

BBED> x /rn
rowdata[2094]                               @7710    
-------------
flag@7710: 0xac (KDRHFL, KDRHFF, KDRHFH, KDRHFK)
lock@7711: 0x00
cols@7712:    1
kref@7713:    1
mref@7715:    1
hrid@7717:0x0040eb9a.6
nrid@7723:0x0040eb9a.6

col    0[4] @7729: 59484 


BBED>  p *kdbr[4]
rowdata[1999]
-------------
ub1 rowdata[1999]                           @7615     0xac

BBED> x /rn
rowdata[1999]                               @7615    
-------------
flag@7615: 0xac (KDRHFL, KDRHFF, KDRHFH, KDRHFK)
lock@7616: 0x00
cols@7617:    1
kref@7618:    4
mref@7620:    4
hrid@7622:0x00403371.6
nrid@7628:0x00403371.6

col    0[3] @7634: 8871 


BBED> p *kdbr[5]
rowdata[1176]
-------------
ub1 rowdata[1176]                           @6792     0xac

BBED> x /rn
rowdata[1176]                               @6792    
-------------
flag@6792: 0xac (KDRHFL, KDRHFF, KDRHFH, KDRHFK)
lock@6793: 0x00
cols@6794:    1
kref@6795:   18
mref@6797:   18
hrid@6799:0x00413e74.5
nrid@6805:0x00413e74.5

col    0[4] @6811: 75557 


BBED>  p *kdbr[6]
rowdata[1049]
-------------
ub1 rowdata[1049]                           @6665     0x6c

BBED> x /rn
rowdata[1049]                               @6665    
-------------
flag@6665: 0x6c (KDRHFL, KDRHFF, KDRHFH, KDRHFC)
lock@6666: 0x00
cols@6667:   36
ckix@6668:    5

col    0[4] @6669: 75557 
col    1[2] @6674: 4 
col    2[2] @6677: 4 
col    3[3] @6680: 170 
col    4[0] @6684: *NULL*
col    5[0] @6685: *NULL*
col    6[2] @6686: 15 
col    7[0] @6689: *NULL*
col    8[2] @6690: 10 
col    9[2] @6693: 40 
col   10[2] @6696: 1 
col   11[3] @6699: 255 
col   12[6] @6703: 1073741825 
col  13[38] @6710:  0x2d  0x2d  0x2d  0x2d  0x2d  0x2d  0x2d  0x2d  0x2d  0x2d 
 0x2d  0x2d  0x2d  0x2d  0x2d  0x2d  0x2d  0x2d  0x2d  0x2d  0x2d  0x2d  0x2d 
 0x2d  0x2d  0x2d  0x2d  0x2d  0x2d  0x2d  0x2d  0x2d  0x2d  0x2d  0x2d  0x2d 
 0x2d  0x2d 
col   14[0] @6749: *NULL*
col   15[0] @6750: *NULL*
col   16[0] @6751: *NULL*
col   17[0] @6752: *NULL*
col   18[0] @6753: *NULL*
col   19[0] @6754: *NULL*
col   20[0] @6755: *NULL*
col   21[0] @6756: *NULL*
col   22[0] @6757: *NULL*
col   23[0] @6758: *NULL*
col   24[0] @6759: *NULL*
col   25[0] @6760: *NULL*
col   26[2] @6761: 15 
col   27[2] @6764: 15 
col   28[6] @6767: 536870912 
col   29[1] @6774: 0 
col   30[3] @6776: 736 
col   31[0] @6780: *NULL*
col   32[0] @6781: *NULL*
col   33[0] @6782: *NULL*
col   34[0] @6783: *NULL*
col   35[7] @6784: ######################################### 


BBED> p *kdbr[7]
rowdata[0]
----------
ub1 rowdata[0]                              @5616     0x6c

BBED> x /rn
rowdata[0]                                  @5616    
----------
flag@5616: 0x6c (KDRHFL, KDRHFF, KDRHFH, KDRHFC)
lock@5617: 0x02
cols@5618:   33
ckix@5619:    5

col    0[4] @5620: 75558 
col    1[4] @5625: 75558 
col    2[2] @5630: 4 
col    3[2] @5633: 4 
col    4[3] @5636: 298 
col    5[1] @5640: 0 
col    6[2] @5642: 1 
col    7[2] @5645: 10 
col    8[2] @5648: 2 
col    9[3] @5651: 255 
col   10[0] @5655: *NULL*
col   11[2] @5656: 1 
col   12[2] @5659: 2 
col   13[1] @5662: 0 
col   14[2] @5664: 1 
col   15[3] @5667: 165 
col   16[4] @5671: 74491 
col   17[2] @5676: 1 
col   18[2] @5679: 1 
col   19[3] @5682: 1720 
col   20[7] @5686: ######################################### 
col   21[4] @5694: 74491 
col   22[4] @5699: 74491 
col   23[2] @5704: 1 
col   24[0] @5707: *NULL*
col   25[0] @5708: *NULL*
col   26[0] @5709: *NULL*
col   27[2] @5710: 1 
col   28[0] @5713: *NULL*
col   29[0] @5714: *NULL*
col   30[0] @5715: *NULL*
col   31[0] @5716: *NULL*
col   32[7] @5717: ######################################### 


BBED> set count 64
        COUNT           64

BBED> d
 File: /u01/oracle/oradata/ora11g/system01.dbf (1)
 Block: 81524            Offsets: 5616 to 5679           Dba:0x00413e74
------------------------------------------------------------------------
 6c022105 04c30838 3b04c308 383b02c1 0502c105 03c20363 018002c1 0202c10b 
 02c10303 c20338ff 02c10202 c1030180 02c10203 c2024204 c3082d5c 02c10202 

 <32 bytes per line>

BBED> m /x 7c
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y
 File: /u01/oracle/oradata/ora11g/system01.dbf (1)
 Block: 81524            Offsets: 5616 to 5679           Dba:0x00413e74
------------------------------------------------------------------------
 7c022105 04c30838 3b04c308 383b02c1 0502c105 03c20363 018002c1 0202c10b 
 02c10303 c20338ff 02c10202 c1030180 02c10203 c2024204 c3082d5c 02c10202 

 <32 bytes per line>

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

BBED> verify
DBVERIFY - Verification starting
FILE = /u01/oracle/oradata/ora11g/system01.dbf
BLOCK = 81524

Block Checking: DBA = 4275828, Block Type = KTB-managed data block
data header at 0xb53c625c
kdbchk:  key comref count wrong
         keyslot=5
Block 81524 failed with check code 6121

DBVERIFY - Verification complete

Total Blocks Examined         : 1
Total Blocks Processed (Data) : 1
Total Blocks Failing   (Data) : 1
Total Blocks Processed (Index): 0
Total Blocks Failing   (Index): 0
Total Blocks Empty            : 0
Total Blocks Marked Corrupt   : 0
Total Blocks Influx           : 0
Message 531 not found;  product=RDBMS; facility=BBED


BBED> p *kdbr[5]
rowdata[1176]
-------------
ub1 rowdata[1176]                           @6792     0xac

BBED> x /rn
rowdata[1176]                               @6792    
-------------
flag@6792: 0xac (KDRHFL, KDRHFF, KDRHFH, KDRHFK)
lock@6793: 0x00
cols@6794:    1
kref@6795:   18
mref@6797:   18
hrid@6799:0x00413e74.5
nrid@6805:0x00413e74.5

col    0[4] @6811: 75557 


BBED> d offset 6797
 File: /u01/oracle/oradata/ora11g/system01.dbf (1)
 Block: 81524            Offsets: 6797 to 6860           Dba:0x00413e74
------------------------------------------------------------------------
 12000041 3e740005 00413e74 000504c3 08383a7c 02140502 c10602c1 0602c102 
 01800d52 4f4c4c42 41434b5f 4f4e4c59 02c16102 c1020180 ffff0180 ffff02c1 

 <32 bytes per line>

BBED> m /x 11 
 File: /u01/oracle/oradata/ora11g/system01.dbf (1)
 Block: 81524            Offsets: 6797 to 6860           Dba:0x00413e74
------------------------------------------------------------------------
 11000041 3e740005 00413e74 000504c3 08383a7c 02140502 c10602c1 0602c102 
 01800d52 4f4c4c42 41434b5f 4f4e4c59 02c16102 c1020180 ffff0180 ffff02c1 

 <32 bytes per line>

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

BBED> verify
DBVERIFY - Verification starting
FILE = /u01/oracle/oradata/ora11g/system01.dbf
BLOCK = 81524

Block Checking: DBA = 4275828, Block Type = KTB-managed data block
data header at 0xb53c625c
kdbchk: the amount of space used is not equal to block size
        used=1835 fsc=0 avsp=6156 dtl=8096
Block 81524 failed with check code 6110

DBVERIFY - Verification complete

Total Blocks Examined         : 1
Total Blocks Processed (Data) : 1
Total Blocks Failing   (Data) : 1
Total Blocks Processed (Index): 0
Total Blocks Failing   (Index): 0
Total Blocks Empty            : 0
Total Blocks Marked Corrupt   : 0
Total Blocks Influx           : 0
Message 531 not found;  product=RDBMS; facility=BBED


BBED> p kdbh
struct kdbh, 14 bytes                       @92      
   ub1 kdbhflag                             @92       0x00 (NONE)
   sb1 kdbhntab                             @93       6
   sb2 kdbhnrow                             @94       33
   sb2 kdbhfrre                             @96       9
   sb2 kdbhfsbo                             @98       104
   sb2 kdbhfseo                             @100      5524
   sb2 kdbhavsp                             @102      6156
   sb2 kdbhtosp                             @104      6156

BBED> d offset 102
 File: /u01/oracle/oradata/ora11g/system01.dbf (1)
 Block: 81524            Offsets:  102 to  165           Dba:0x00413e74
------------------------------------------------------------------------
 0c180c18 00000600 06000100 07000000 07000100 08000200 0a001700 8a1f331f 
 d81ec21d 631d2c1a ad199415 0116ffff 5b1e171e da1d7a1d 231de51c a21c631c 

 <32 bytes per line>

BBED> m /x 7518
 File: /u01/oracle/oradata/ora11g/system01.dbf (1)
 Block: 81524            Offsets:  102 to  165           Dba:0x00413e74
------------------------------------------------------------------------
 75180c18 00000600 06000100 07000000 07000100 08000200 0a001700 8a1f331f 
 d81ec21d 631d2c1a ad199415 0116ffff 5b1e171e da1d7a1d 231de51c a21c631c 

 <32 bytes per line>

BBED> m /x 7518 offset 104
 File: /u01/oracle/oradata/ora11g/system01.dbf (1)
 Block: 81524            Offsets:  104 to  167           Dba:0x00413e74
------------------------------------------------------------------------
 75180000 06000600 01000700 00000700 01000800 02000a00 17008a1f 331fd81e 
 c21d631d 2c1aad19 94150116 ffff5b1e 171eda1d 7a1d231d e51ca21c 631c7419 

 <32 bytes per line>

BBED> p kdbh
struct kdbh, 14 bytes                       @92      
   ub1 kdbhflag                             @92       0x00 (NONE)
   sb1 kdbhntab                             @93       6
   sb2 kdbhnrow                             @94       33
   sb2 kdbhfrre                             @96       9
   sb2 kdbhfsbo                             @98       104
   sb2 kdbhfseo                             @100      5524
   sb2 kdbhavsp                             @102      6261
   sb2 kdbhtosp                             @104      6261

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

BBED> verify
DBVERIFY - Verification starting
FILE = /u01/oracle/oradata/ora11g/system01.dbf
BLOCK = 81524

Block Checking: DBA = 4275828, Block Type = KTB-managed data block
data header at 0xb53c625c
kdbchk: space available on commit is incorrect
        tosp=6261 fsc=0 stb=4 avsp=6261
Block 81524 failed with check code 6111

DBVERIFY - Verification complete

Total Blocks Examined         : 1
Total Blocks Processed (Data) : 1
Total Blocks Failing   (Data) : 1
Total Blocks Processed (Index): 0
Total Blocks Failing   (Index): 0
Total Blocks Empty            : 0
Total Blocks Marked Corrupt   : 0
Total Blocks Influx           : 0
Message 531 not found;  product=RDBMS; facility=BBED


BBED> m /x 7918 offset 104
 File: /u01/oracle/oradata/ora11g/system01.dbf (1)
 Block: 81524            Offsets:  104 to  167           Dba:0x00413e74
------------------------------------------------------------------------
 79180000 06000600 01000700 00000700 01000800 02000a00 17008a1f 331fd81e 
 c21d631d 2c1aad19 94150116 ffff5b1e 171eda1d 7a1d231d e51ca21c 631c7419 

 <32 bytes per line>

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

BBED> verify
DBVERIFY - Verification starting
FILE = /u01/oracle/oradata/ora11g/system01.dbf
BLOCK = 81524


DBVERIFY - Verification complete

Total Blocks Examined         : 1
Total Blocks Processed (Data) : 1
Total Blocks Failing   (Data) : 0
Total Blocks Processed (Index): 0
Total Blocks Failing   (Index): 0
Total Blocks Empty            : 0
Total Blocks Marked Corrupt   : 0
Total Blocks Influx           : 0
Message 531 not found;  product=RDBMS; facility=BBED

启动数据库测试ind$是否修改成功

SQL> startup
ORACLE instance started.

Total System Global Area  230162432 bytes
Fixed Size                  1344088 bytes
Variable Size              88083880 bytes
Database Buffers          134217728 bytes
Redo Buffers                6516736 bytes
Database mounted.
Database opened.
SQL> select OWNER,INDEX_NAME,TABLE_NAME,status from dba_indexes where index_name='IND_T_XIFENFEI';
select OWNER,INDEX_NAME,TABLE_NAME,status from dba_indexes where index_name='IND_T_XIFENFEI'
                                               *
ERROR at line 1:
ORA-00600: internal error code, arguments: [kdsgrp1], [], [], [], [], [], [],
[], [], [], [], []

SQL> set autot trace exp
SQL> set lines 150
SQL> select /*+ full(t) */obj#,dataobj#,ts#,file#,block#,bo#,FLAGS,rowid from sys.ind$ t where obj#=75558;

Execution Plan
----------------------------------------------------------
Plan hash value: 3378156415

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     1 |    41 |   206   (0)| 00:00:03 |
|*  1 |  TABLE ACCESS FULL| IND$ |     1 |    41 |   206   (0)| 00:00:03 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("OBJ#"=75558)

SQL> select obj#,dataobj#,ts#,file#,block#,bo#,FLAGS,rowid from sys.ind$ t where obj#=75558;

Execution Plan
----------------------------------------------------------
Plan hash value: 3312860272

--------------------------------------------------------------------------------------
| Id  | Operation                   | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |        |     1 |    41 |     2   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| IND$   |     1 |    41 |     2   (0)| 00:00:01 |
|*  2 |   INDEX UNIQUE SCAN         | I_IND1 |     1 |       |     1   (0)| 00:00:01 |
--------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("OBJ#"=75558)

SQL> select count(*) from ind$ where obj#=75558;

Execution Plan
----------------------------------------------------------
Plan hash value: 4150977594

-----------------------------------------------------------------------------
| Id  | Operation          | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |        |     1 |     5 |     1   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE    |        |     1 |     5 |            |          |
|*  2 |   INDEX UNIQUE SCAN| I_IND1 |     1 |     5 |     1   (0)| 00:00:01 |
-----------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("OBJ#"=75558)

SQL> select /*+ full(t) */ count(*)  from sys.ind$ t where obj#=75558;

Execution Plan
----------------------------------------------------------
Plan hash value: 809192456

---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |     1 |     5 |   206   (0)| 00:00:03 |
|   1 |  SORT AGGREGATE    |      |     1 |     5 |            |          |
|*  2 |   TABLE ACCESS FULL| IND$ |     1 |     5 |   206   (0)| 00:00:03 |
---------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter("OBJ#"=75558)


SQL> set autot off
SQL> select /*+ full(t) */obj#,dataobj#,ts#,file#,block#,bo#,FLAGS,rowid from sys.ind$ t where obj#=75558;

no rows selected

SQL>  select obj#,dataobj#,ts#,file#,block#,bo#,FLAGS,rowid from sys.ind$ t where obj#=75558;

      OBJ#   DATAOBJ#        TS#      FILE#     BLOCK#        BO#      FLAGS ROWID
---------- ---------- ---------- ---------- ---------- ---------- ---------- ------------------
     75558      75558          4          4        298      75557          2 AAAAACAABAAAT50AAA

SQL> select count(*) from ind$ where obj#=75558;

  COUNT(*)
----------
         1

SQL> select /*+ full(t) */ count(*)  from sys.ind$ t where obj#=75558;

  COUNT(*)
----------
         0

SQL> COL COLUMN_NAME FOR A15
SQL> SELECT INDEX_OWNER,COLUMN_NAME,INDEX_NAME FROM DBA_IND_COLUMNS WHERE TABLE_NAME='IND$' AND TABLE_OWNER='SYS';

INDEX_OWNER                    COLUMN_NAME     INDEX_NAME
------------------------------ --------------- ------------------------------
SYS                            OBJ#            I_IND1

通过上面的查询我们可以知道ind$本身有一个关于obj#列的index,当我们查询使用该index的时候出现上面的ora-600[kdsgrp1]错误.而因为ind$相关index是bootstarp$中对象,不能直接或者upgrade,甚至event 38003都不能drop或者rebuid

分析I_IND1 索引信息

SQL>  select obj#,dataobj# from obj$ where name='I_IND1';

      OBJ#   DATAOBJ#
---------- ----------
        41         41

SQL> alter session set events 'immediate trace name treedump level 41';

Session altered.

SQL> select value from v$diag_info where name='Default Trace File';

VALUE
---------------------------------------------------------------------------------------
/u01/oracle/diag/rdbms/ora11g/ora11g/trace/ora11g_ora_17321.trc

--通过这个dump出来的rdba信息,结合我们dump出来其他数据块信息可以找到叶子节点的值用来匹配我们需要delete值在I_IND1中位置
----- begin tree dump
branch: 0x400179 4194681 (0: nrow: 10, level: 1)
   leaf: 0x40017a 4194682 (-1: nrow: 575 rrow: 575)
   leaf: 0x40017b 4194683 (0: nrow: 569 rrow: 567)
   leaf: 0x40017c 4194684 (1: nrow: 540 rrow: 540)
   leaf: 0x40017d 4194685 (2: nrow: 533 rrow: 533)
   leaf: 0x40017e 4194686 (3: nrow: 362 rrow: 361)
   leaf: 0x40017f 4194687 (4: nrow: 533 rrow: 533)
   leaf: 0x411d98 4267416 (5: nrow: 533 rrow: 532)
   leaf: 0x411d99 4267417 (6: nrow: 533 rrow: 533)
   leaf: 0x411d9a 4267418 (7: nrow: 533 rrow: 533)
   leaf: 0x411d9b 4267419 (8: nrow: 386 rrow: 386)
----- end tree dump

SQL> set serveroutput on
SQL> declare
  2     p_dba   VARCHAR2 (255) :='0x00411d9b';
  3     l_str   VARCHAR2 (255) DEFAULT NULL;
  4  BEGIN
  5      l_str :=
  6           'datafile# is:'
  7        || DBMS_UTILITY.data_block_address_file (TO_NUMBER (LTRIM (p_dba, '0x'),'xxxxxxxx'))
  8        || chr(10)||'datablock is:'
  9        || DBMS_UTILITY.data_block_address_block (TO_NUMBER (LTRIM (p_dba, '0x'),'xxxxxxxx'));
 10     dbms_output.put_line(l_str);
 11  END;
 12  /
datafile# is:1
datablock is:73115

PL/SQL procedure successfully completed.


SQL> alter system dump datafile 1 block 73115;

System altered.

SQL> select value from v$diag_info where name='Default Trace File';

VALUE
--------------------------------------------------------------------------------
/u01/oracle/diag/rdbms/ora11g/ora11g/trace/ora11g_ora_17583.trc

--找到对应块在叶子节点中的块的信息
Block header dump:  0x00411d9b
 Object id on Block? Y
 seg/obj: 0x29  csc: 0x00.c92c9  itc: 2  flg: O  typ: 2 - INDEX
     fsl: 0  fnx: 0x411d9c ver: 0x01
 
 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0001.002.000001c6  0x00c0483f.004a.01  CB--    0  scn 0x0000.000a66a1
0x02   0x0006.009.000002b3  0x00c02389.0075.2e  --U-    1  fsc 0x0000.000c92cb

row#385[2538] flag: ------, lock: 2, len=13, data:(6):  00 41 3e 74 00 00
col 0; len 4; (4):  c3 08 38 3b

--对于ASSM：76+（itc-1)*24
--对于MSSM：68+（itc-1)*24

SQL> select 2538+68+(2-1)*24 from dual;

2538+68+(2-1)*24
----------------
            2630

bbed修改I_IND1中记录

[oracle@xifenfei ~]$ bbed listfile=listfile mode=edit password=blockedit

BBED: Release 2.0.0.0.0 - Limited Production on Thu Aug 9 17:36:59 2012

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

************* !!! For Oracle Internal Use only !!! ***************

BBED> set block 73115
        BLOCK#          73115

BBED> set offset 2630
        OFFSET          2630

BBED> x /rn
rowdata[4]                                  @2630    
----------
flag@2630:     0x00 (NONE)
lock@2631:     0x02
keydata[6]:    0x00  0x41  0x3e  0x74  0x00  0x00 
data key:
col    0[4] @2639: 75558 


BBED> set count 64
        COUNT           64

BBED> d
 File: /u01/oracle/oradata/ora11g/system01.dbf (1)
 Block: 73115            Offsets: 2630 to 2693           Dba:0x00411d9b
------------------------------------------------------------------------
 00020041 3e740000 04c30838 3b000000 40264a00 0104c308 38380100 0040264a 
 000004c3 08383701 00004026 4a000004 c3083832 01000040 264a0001 04c30838 

 <32 bytes per line>

BBED> m /x 01
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y
 File: /u01/oracle/oradata/ora11g/system01.dbf (1)
 Block: 73115            Offsets: 2630 to 2693           Dba:0x00411d9b
------------------------------------------------------------------------
 01020041 3e740000 04c30838 3b000000 40264a00 0104c308 38380100 0040264a 
 000004c3 08383701 00004026 4a000004 c3083832 01000040 264a0001 04c30838 

 <32 bytes per line>


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

BBED> verify
DBVERIFY - Verification starting
FILE = /u01/oracle/oradata/ora11g/system01.dbf
BLOCK = 73115

Block Checking: DBA = 4267419, Block Type = KTB-managed data block
**** actual free space credit for itl 2 = 15 != # in trans. hdr = 0  <----修改_ktbitfsc信息
**** actual rows marked deleted = 1 != kdxlende = 0 <----修改kdxlende信息
---- end index block validation
Block 73115 failed with check code 6401

DBVERIFY - Verification complete

Total Blocks Examined         : 1
Total Blocks Processed (Data) : 0
Total Blocks Failing   (Data) : 0
Total Blocks Processed (Index): 1
Total Blocks Failing   (Index): 1
Total Blocks Empty            : 0
Total Blocks Marked Corrupt   : 0
Total Blocks Influx           : 0
Message 531 not found;  product=RDBMS; facility=BBED


BBED> map
 File: /u01/oracle/oradata/ora11g/system01.dbf (1)
 Block: 73115                                 Dba:0x00411d9b
------------------------------------------------------------
 KTB Data Block (Index Leaf)

 struct kcbh, 20 bytes                      @0       

 struct ktbbh, 72 bytes                     @20      

 struct kdxle, 32 bytes                     @92      

 sb2 kd_off[386]                            @124     

 ub1 freespace[1730]                        @896     

 ub1 rowdata[5494]                          @2626    

 ub4 tailchk                                @8188    


BBED> p kdxle
struct kdxle, 32 bytes                      @92      
   struct kdxlexco, 16 bytes                @92      
      ub1 kdxcolev                          @92       0x00
      ub1 kdxcolok                          @93       0x00
      ub1 kdxcoopc                          @94       0x80
      ub1 kdxconco                          @95       0x01
      ub4 kdxcosdc                          @96       0x00000001
      sb2 kdxconro                          @100      386
      sb2 kdxcofbo                          @102      808
      sb2 kdxcofeo                          @104      2538
      sb2 kdxcoavs                          @106      2210
   sb2 kdxlespl                             @108      0
   sb2 kdxlende                             @110      0   <----需要修改
   ub4 kdxlenxt                             @112      0x00000000
   ub4 kdxleprv                             @116      0x00411d9a
   ub1 kdxledsz                             @120      0x06
   ub1 kdxleflg                             @121      0x00 (NONE)

BBED> d offset 110
 File: /u01/oracle/oradata/ora11g/system01.dbf (1)
 Block: 73115            Offsets:  110 to  173           Dba:0x00411d9b
------------------------------------------------------------------------
 00000000 00009a1d 41000600 0e00601f 0000531f 461f391f 2c1f1f1f 121f051f 
 f81eeb1e de1ed11e c41eb71e aa1e9d1e 901e831e 761e691e 5c1e4f1e 421e351e 

 <32 bytes per line>

BBED> m /x 01
 File: /u01/oracle/oradata/ora11g/system01.dbf (1)
 Block: 73115            Offsets:  110 to  173           Dba:0x00411d9b
------------------------------------------------------------------------
 01000000 00009a1d 41000600 0e00601f 0000531f 461f391f 2c1f1f1f 121f051f 
 f81eeb1e de1ed11e c41eb71e aa1e9d1e 901e831e 761e691e 5c1e4f1e 421e351e 

 <32 bytes per line>

BBED> p ktbbh
struct ktbbh, 72 bytes                      @20      
   ub1 ktbbhtyp                             @20       0x02 (KDDBTINDEX)
   union ktbbhsid, 4 bytes                  @24      
      ub4 ktbbhsg1                          @24       0x00000029
      ub4 ktbbhod1                          @24       0x00000029
   struct ktbbhcsc, 8 bytes                 @28      
      ub4 kscnbas                           @28       0x000c92c9
      ub2 kscnwrp                           @32       0x0000
   sb2 ktbbhict                             @36       2
   ub1 ktbbhflg                             @38       0x03 (KTBFONFL)
   ub1 ktbbhfsl                             @39       0x00
   ub4 ktbbhfnx                             @40       0x00411d9c
   struct ktbbhitl[0], 24 bytes             @44      
      struct ktbitxid, 8 bytes              @44      
         ub2 kxidusn                        @44       0x0001
         ub2 kxidslt                        @46       0x0002
         ub4 kxidsqn                        @48       0x000001c6
      struct ktbituba, 8 bytes              @52      
         ub4 kubadba                        @52       0x00c0483f
         ub2 kubaseq                        @56       0x004a
         ub1 kubarec                        @58       0x01
      ub2 ktbitflg                          @60       0xc000 (KTBFIBI, KTBFCOM)
      union _ktbitun, 2 bytes               @62      
         sb2 _ktbitfsc                      @62       0
         ub2 _ktbitwrp                      @62       0x0000
      ub4 ktbitbas                          @64       0x000a66a1
   struct ktbbhitl[1], 24 bytes             @68      
      struct ktbitxid, 8 bytes              @68      
         ub2 kxidusn                        @68       0x0006
         ub2 kxidslt                        @70       0x0009
         ub4 kxidsqn                        @72       0x000002b3
      struct ktbituba, 8 bytes              @76      
         ub4 kubadba                        @76       0x00c02389
         ub2 kubaseq                        @80       0x0075
         ub1 kubarec                        @82       0x2e
      ub2 ktbitflg                          @84       0x2001 (KTBFUPB)
      union _ktbitun, 2 bytes               @86      
         sb2 _ktbitfsc                      @86       0    <----需要修改
         ub2 _ktbitwrp                      @86       0x0000
      ub4 ktbitbas                          @88       0x000c92cb

BBED> d offset 86
 File: /u01/oracle/oradata/ora11g/system01.dbf (1)
 Block: 73115            Offsets:   86 to  149           Dba:0x00411d9b
------------------------------------------------------------------------
 0000cb92 0c000000 80010100 00008201 2803ea09 a2080000 01000000 00009a1d 
 41000600 0e00601f 0000531f 461f391f 2c1f1f1f 121f051f f81eeb1e de1ed11e 

 <32 bytes per line>

BBED> m /x 0f
 File: /u01/oracle/oradata/ora11g/system01.dbf (1)
 Block: 73115            Offsets:   86 to  149           Dba:0x00411d9b
------------------------------------------------------------------------
 0f00cb92 0c000000 80010100 00008201 2803ea09 a2080000 01000000 00009a1d 
 41000600 0e00601f 0000531f 461f391f 2c1f1f1f 121f051f f81eeb1e de1ed11e 

 <32 bytes per line>

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

BBED> verify
DBVERIFY - Verification starting
FILE = /u01/oracle/oradata/ora11g/system01.dbf
BLOCK = 73115


DBVERIFY - Verification complete

Total Blocks Examined         : 1
Total Blocks Processed (Data) : 0
Total Blocks Failing   (Data) : 0
Total Blocks Processed (Index): 1
Total Blocks Failing   (Index): 0
Total Blocks Empty            : 0
Total Blocks Marked Corrupt   : 0
Total Blocks Influx           : 0
Message 531 not found;  product=RDBMS; facility=BBED

启动数据库测试

SQL> startup
ORACLE instance started.

Total System Global Area  230162432 bytes
Fixed Size                  1344088 bytes
Variable Size              88083880 bytes
Database Buffers          134217728 bytes
Redo Buffers                6516736 bytes
Database mounted.
Database opened.
SQL> select count(*) from ind$ where obj#=75558;

  COUNT(*)
----------
         0

SQL> select /*+ full(t) */ count(*)  from sys.ind$ t where obj#=75558;

  COUNT(*)
----------
         0

SQL> select OWNER,INDEX_NAME,TABLE_NAME,status from dba_indexes where index_name='IND_T_XIFENFEI';

no rows selected

扫尾和测试工作

SQL> delete from obj$ where obj# =75558;

1 row deleted.

SQL> delete from icol$ where obj#=75558;

1 row deleted.

SQL> delete from seg$ where ts#=4 and file#=4 and block#=298;

1 row deleted.

SQL> commit;

Commit complete.

--重新创建/删除一个同名的index成功
SQL> create index chf.ind_t_xifenfei on chf.t_xifenfei(object_id);

Index created.

SQL> drop index chf.ind_t_xifenfei;

Index dropped.

通过以上对于ind$和I_IND1操作大体上完成对于ind_t_xifenfei索引的手工删除,比较完美的实现了bbed drop index操作过程.

bbed 恢复 GLOBAL_NAME 为空故障

Posted on by

看到dbsnake关于UPDATE GLOBAL_NAME为空之后的恢复写的不是很完整,自己通过试验和对bbed的研究,完善他的blog内容(泄露一点内部的东西)
模拟错误

SQL> select * from v$version;

BANNER
------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production
PL/SQL Release 11.2.0.3.0 - Production
CORE    11.2.0.3.0      Production
TNS for Linux: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production

SQL> select * from global_name ;

GLOBAL_NAME
--------------------------------------------------------------------
ORA11G

SQL> update global_name set global_name='';

1 row updated.

SQL> COMMIT;

Commit complete.

SQL> SHUTDOWN IMMEDIATE
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> STARTUP
ORACLE instance started.

Total System Global Area  313860096 bytes
Fixed Size                  1344652 bytes
Variable Size             260049780 bytes
Database Buffers           46137344 bytes
Redo Buffers                6328320 bytes
Database mounted.
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00600: internal error code, arguments: [18062], [], [], [], [], [], [], [],
[], [], [], []
Process ID: 28306
Session ID: 125 Serial number: 5

alert日志

Errors in file /u01/oracle/diag/rdbms/ora11g/ora11g/trace/ora11g_ora_28306.trc  (incident=20556):
ORA-00600: internal error code, arguments: [18062], [], [], [], [], [], [], [], [], [], [], []
Incident details in: /u01/oracle/diag/rdbms/ora11g/ora11g/incident/incdir_20556/ora11g_ora_28306_i20556.trc
Wed Aug 08 23:21:48 2012
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Errors in file /u01/oracle/diag/rdbms/ora11g/ora11g/trace/ora11g_ora_28306.trc:
ORA-00600: internal error code, arguments: [18062], [], [], [], [], [], [], [], [], [], [], []
Errors in file /u01/oracle/diag/rdbms/ora11g/ora11g/trace/ora11g_ora_28306.trc:
ORA-00600: internal error code, arguments: [18062], [], [], [], [], [], [], [], [], [], [], []
Error 600 happened during db open, shutting down database
USER (ospid: 28306): terminating the instance due to error 600
Instance terminated by USER, pid = 28306
ORA-1092 signalled during: ALTER DATABASE OPEN...
opiodr aborting process unknown ospid (28306) as a result of ORA-1092
Wed Aug 08 23:21:48 2012
ORA-1092 : opitsk aborting process

找出global_name相关信息(另外库中)

SQL> SET LONG 1000
SQL> select dbms_metadata.get_ddl('VIEW','GLOBAL_NAME','SYS') from dual;

DBMS_METADATA.GET_DDL('VIEW','GLOBAL_NAME','SYS')
--------------------------------------------------------------------------------

  CREATE OR REPLACE FORCE VIEW "SYS"."GLOBAL_NAME" ("GLOBAL_NAME") AS
  select value$ from sys.props$ where name = 'GLOBAL_DB_NAME'

SQL> select * from props$ where value$='XIFENFEI';

NAME                           VALUE$
------------------------------ ----------------------------------------
COMMENT$
--------------------------------------------------------------------------
GLOBAL_DB_NAME                 XIFENFEI
Global database name

SQL> select dump('GLOBAL_DB_NAME','16') from dual;

DUMP('GLOBAL_DB_NAME','16')
--------------------------------------------------------
Typ=96 Len=14: 47,4c,4f,42,41,4c,5f,44,42,5f,4e,41,4d,45
--得出GLOBAL_DB_NAME存储字16进制字符串为:0e474c4f42414c5f44425f4e414d45

bbed操作

--通过第三方工具定位props$表中的GLOBAL_DB_NAME列在数据块0x00400321的31行上

[oracle@xifenfei ~]$ bbed listfile=listfile mode=edit password=blockedit

BBED: Release 2.0.0.0.0 - Limited Production on Thu Aug 9 00:26:12 2012

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

************* !!! For Oracle Internal Use only !!! ***************

BBED> info
 File#  Name                                                        Size(blks)
 -----  ----                                                        ----------
     1  /u01/oracle/oradata/ora11g/system01.dbf                              0
     2  /u01/oracle/oradata/ora11g/sysaux01.dbf                              0
     3  /u01/oracle/oradata/ora11g/undotbs01.dbf                             0
     4  /u01/oracle/oradata/ora11g/users01.dbf                               0

BBED> set block 801
        BLOCK#          801

BBED> map
 File: /u01/oracle/oradata/ora11g/system01.dbf (1)
 Block: 801                                   Dba:0x00400321
------------------------------------------------------------
 KTB Data Block (Table/Cluster)

 struct kcbh, 20 bytes                      @0       

 struct ktbbh, 72 bytes                     @20      

 struct kdbh, 14 bytes                      @92      

 struct kdbt[1], 4 bytes                    @106     

 sb2 kdbr[37]                               @110     

 ub1 freespace[5771]                        @184     

 ub1 rowdata[2233]                          @5955    

 ub4 tailchk                                @8188    

BBED>  p *kdbr[31]
rowdata[0]
----------
ub1 rowdata[0]                              @5955     0x2c

BBED> x /rccc
rowdata[0]                                  @5955    
----------
flag@5955: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@5956: 0x02
cols@5957:    3

col   0[14] @5958: GLOBAL_DB_NAME
col    1[0] @5973: *NULL*
col   2[20] @5974: Global database name

BBED> set count 64
        COUNT           64

BBED> f /x 0e474c4f
 File: /u01/oracle/oradata/ora11g/system01.dbf (1)
 Block: 801              Offsets: 5958 to 6021           Dba:0x00400321
------------------------------------------------------------------------
 0e474c4f 42414c5f 44425f4e 414d45ff 14476c6f 62616c20 64617461 62617365 
 206e616d 652c0003 0e474c4f 42414c5f 44425f4e 414d4506 4f524131 31471447 

 <32 bytes per line>

BBED> f
 File: /u01/oracle/oradata/ora11g/system01.dbf (1)
 Block: 801              Offsets: 5998 to 6061           Dba:0x00400321
------------------------------------------------------------------------
 0e474c4f 42414c5f 44425f4e 414d4506 4f524131 31471447 6c6f6261 6c206461 
 74616261 7365206e 616d652c 00030a44 4254494d 455a4f4e 45053030 3a30300c 

 <32 bytes per line>

BBED> f
 File: /u01/oracle/oradata/ora11g/system01.dbf (1)
 Block: 801              Offsets: 6460 to 6523           Dba:0x00400321
------------------------------------------------------------------------
 0e474c4f 42414c5f 44425f4e 414d4508 53454544 44415441 14476c6f 62616c20 
 64617461 62617365 206e616d 652c0003 114e4c53 5f524442 4d535f56 45525349 

 <32 bytes per line>

BBED> f
BBED-00212: search string not found

BBED> d /v offset 5958
 File: /u01/oracle/oradata/ora11g/system01.dbf (1)
 Block: 801     Offsets: 5958 to 6021  Dba:0x00400321
-------------------------------------------------------
 0e474c4f 42414c5f 44425f4e 414d45ff l .GLOBAL_DB_NAME.
 14476c6f 62616c20 64617461 62617365 l .Global database
 206e616d 652c0003 0e474c4f 42414c5f l  name,...GLOBAL_
 44425f4e 414d4506 4f524131 31471447 l DB_NAME.ORA11G.G

 <16 bytes per line>

BBED> d /v offset 5998
 File: /u01/oracle/oradata/ora11g/system01.dbf (1)
 Block: 801     Offsets: 5998 to 6061  Dba:0x00400321
-------------------------------------------------------
 0e474c4f 42414c5f 44425f4e 414d4506 l .GLOBAL_DB_NAME.
 4f524131 31471447 6c6f6261 6c206461 l ORA11G.Global da
 74616261 7365206e 616d652c 00030a44 l tabase name,...D
 4254494d 455a4f4e 45053030 3a30300c l BTIMEZONE.00:00.

 <16 bytes per line>

BBED> d /v offset 6460
 File: /u01/oracle/oradata/ora11g/system01.dbf (1)
 Block: 801     Offsets: 6460 to 6523  Dba:0x00400321
-------------------------------------------------------
 0e474c4f 42414c5f 44425f4e 414d4508 l .GLOBAL_DB_NAME.
 53454544 44415441 14476c6f 62616c20 l SEEDDATA.Global 
 64617461 62617365 206e616d 652c0003 l database name,..
 114e4c53 5f524442 4d535f56 45525349 l .NLS_RDBMS_VERSI

 <16 bytes per line>
--通过时上面的查找可以知道数据库对GLOBAL_DB_NAME有进行两次update操作
--GLOBAL_DB_NAME初始化值SEEDDATA,第一次更新为ORA11G,第二次更新为null

BBED> p  kdbr[31]
sb2 kdbr[31]                                @172      5863
--这里可以发现我们看到offset 5995开始有值,但是row directory却指向了5863

BBED> d offset 5863 count 128
 File: /u01/oracle/oradata/ora11g/system01.dbf (1)
 Block: 801              Offsets: 5863 to 5990           Dba:0x00400321
------------------------------------------------------------------------
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 2c02030e 
 474c4f42 414c5f44 425f4e41 4d45ff14 476c6f62 616c2064 61746162 61736520 

 <32 bytes per line>
--通过dump看到row directory指向的值和实际的数据相差(5995-5863),都是0

BBED> d /v offset 5900
 File: /u01/oracle/oradata/ora11g/system01.dbf (1)
 Block: 801     Offsets: 5900 to 6027  Dba:0x00400321
-------------------------------------------------------
 00000000 00000000 00000000 00000000 l ................
 00000000 00000000 00000000 00000000 l ................
 00000000 00000000 00000000 00000000 l ................
 00000000 0000002c 02030e47 4c4f4241 l .......,...GLOBA
 4c5f4442 5f4e414d 45ff1447 6c6f6261 l L_DB_NAME..Globa
 6c206461 74616261 7365206e 616d652c l l database name,
 00030e47 4c4f4241 4c5f4442 5f4e414d l ...GLOBAL_DB_NAM
 45064f52 41313147 14476c6f 62616c20 l E.ORA11G.Global 

 <16 bytes per line>
--需要指定的新值前面也存在同样的0,所以模仿的处理方法,让row directory同样向前偏移92

BBED> m /x 0f17 offset 172
 File: /u01/oracle/oradata/ora11g/system01.dbf (1)
 Block: 801              Offsets:  172 to  299           Dba:0x00400321
------------------------------------------------------------------------
 0f176018 16189a17 5e173d17 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>

BBED> p kdbr[31]
sb2 kdbr[31]                                @172      5903

BBED> p *kdbr[31]
rowdata[40]
-----------
ub1 rowdata[40]                             @5995     0x2c

BBED> x /rccc
rowdata[40]                                 @5995    
-----------
flag@5995: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@5996: 0x00
cols@5997:    3

col   0[14] @5998: GLOBAL_DB_NAME
col    1[6] @6013: ORA11G
col   2[20] @6020: Global database name

修改lock信息
BBED> m /x 02 offset 5996
 File: /u01/oracle/oradata/ora11g/system01.dbf (1)
 Block: 801              Offsets: 5996 to 6123           Dba:0x00400321
------------------------------------------------------------------------
 02030e47 4c4f4241 4c5f4442 5f4e414d 45064f52 41313147 14476c6f 62616c20 
 64617461 62617365 206e616d 652c0003 0a444254 494d455a 4f4e4505 30303a30 
 300c4442 2074696d 65207a6f 6e652c00 02174e4f 5f555345 5249445f 56455249 
 46494552 5f53414c 54203633 39364335 38414231 37414530 30374539 41373238 

 <32 bytes per line>

BBED> d offset 5955
 File: /u01/oracle/oradata/ora11g/system01.dbf (1)
 Block: 801              Offsets: 5955 to 6082           Dba:0x00400321
------------------------------------------------------------------------
 2c02030e 474c4f42 414c5f44 425f4e41 4d45ff14 476c6f62 616c2064 61746162 
 61736520 6e616d65 2c02030e 474c4f42 414c5f44 425f4e41 4d45064f 52413131 
 4714476c 6f62616c 20646174 61626173 65206e61 6d652c00 030a4442 54494d45 
 5a4f4e45 0530303a 30300c44 42207469 6d65207a 6f6e652c 0002174e 4f5f5553 

 <32 bytes per line>

BBED> m /x 2c00  
 File: /u01/oracle/oradata/ora11g/system01.dbf (1)
 Block: 801              Offsets: 5955 to 6082           Dba:0x00400321
------------------------------------------------------------------------
 2c00030e 474c4f42 414c5f44 425f4e41 4d45ff14 476c6f62 616c2064 61746162 
 61736520 6e616d65 2c02030e 474c4f42 414c5f44 425f4e41 4d45064f 52413131 
 4714476c 6f62616c 20646174 61626173 65206e61 6d652c00 030a4442 54494d45 
 5a4f4e45 0530303a 30300c44 42207469 6d65207a 6f6e652c 0002174e 4f5f5553 

 <32 bytes per line>

--验证块
BBED> sum apply
Check value for File 1, Block 801:
current = 0xe836, required = 0xe836

BBED> verify
DBVERIFY - Verification starting
FILE = /u01/oracle/oradata/ora11g/system01.dbf
BLOCK = 801

Block Checking: DBA = 4195105, Block Type = KTB-managed data block
data header at 0xb677b25c
kdbchk: the amount of space used is not equal to block size
        used=2056 fsc=6 avsp=6040 dtl=8096
Block 801 failed with check code 6110

DBVERIFY - Verification complete

Total Blocks Examined         : 1
Total Blocks Processed (Data) : 1
Total Blocks Failing   (Data) : 1
Total Blocks Processed (Index): 0
Total Blocks Failing   (Index): 0
Total Blocks Empty            : 0
Total Blocks Marked Corrupt   : 0
Total Blocks Influx           : 0

--修改_ktbitfsc信息，让其通过块验证
BBED> p ktbbhitl
struct ktbbhitl[0], 24 bytes                @44      
   struct ktbitxid, 8 bytes                 @44      
      ub2 kxidusn                           @44       0x0004
      ub2 kxidslt                           @46       0x000e
      ub4 kxidsqn                           @48       0x000001d4
   struct ktbituba, 8 bytes                 @52      
      ub4 kubadba                           @52       0x00c00a93
      ub2 kubaseq                           @56       0x0083
      ub1 kubarec                           @58       0x33
   ub2 ktbitflg                             @60       0x8000 (KTBFCOM)
   union _ktbitun, 2 bytes                  @62      
      b2 _ktbitfsc                          @62       0
      ub2 _ktbitwrp                         @62       0x0000
   ub4 ktbitbas                             @64       0x000c78fe
struct ktbbhitl[1], 24 bytes                @68      
   struct ktbitxid, 8 bytes                 @68      
      ub2 kxidusn                           @68       0x000a
      ub2 kxidslt                           @70       0x0016
      ub4 kxidsqn                           @72       0x000001eb
   struct ktbituba, 8 bytes                 @76      
      ub4 kubadba                           @76       0x00c0015b
      ub2 kubaseq                           @80       0x008f
      ub1 kubarec                           @82       0x0d
   ub2 ktbitflg                             @84       0x0001 (NONE)
   union _ktbitun, 2 bytes                  @86      
      b2 _ktbitfsc                          @86       6
      ub2 _ktbitwrp                         @86       0x0006
   ub4 ktbitbas                             @88       0x00000000

BBED> m /x 00 offset 86
 File: /u01/oracle/oradata/ora11g/system01.dbf (1)
 Block: 801              Offsets:   86 to  213           Dba:0x00400321
------------------------------------------------------------------------
 00000000 00000001 25000600 5c00e716 98179e17 00002500 701f571e 92189c1e 
 101efb1d ffff981d 551d0f1d d91cb71c 941c731c 4a1c1a1c ef1bc51b 9c1b701b 
 471b191b d61a931a 3c1a101a ee19bc19 86194e19 0d190f17 60181618 9a175e17 
 3d170000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 

 <32 bytes per line>

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

BBED> verify
DBVERIFY - Verification starting
FILE = /u01/oracle/oradata/ora11g/system01.dbf
BLOCK = 801

Block Checking: DBA = 4195105, Block Type = KTB-managed data block
data header at 0xb677b25c
kdbchk: space available on commit is incorrect
        tosp=6046 fsc=0 stb=0 avsp=6040
Block 801 failed with check code 6111

DBVERIFY - Verification complete

Total Blocks Examined         : 1
Total Blocks Processed (Data) : 1
Total Blocks Failing   (Data) : 1
Total Blocks Processed (Index): 0
Total Blocks Failing   (Index): 0
Total Blocks Empty            : 0
Total Blocks Marked Corrupt   : 0
Total Blocks Influx           : 0

--修改kdbhtosp信息
BBED> p kdbh
struct kdbh, 14 bytes                       @92      
   ub1 kdbhflag                             @92       0x00 (NONE)
   b1 kdbhntab                              @93       1
   b2 kdbhnrow                              @94       37
   sb2 kdbhfrre                             @96       6
   sb2 kdbhfsbo                             @98       92
   sb2 kdbhfseo                             @100      5863
   b2 kdbhavsp                              @102      6040
   b2 kdbhtosp                              @104      6046

BBED> d offset 102
 File: /u01/oracle/oradata/ora11g/system01.dbf (1)
 Block: 801              Offsets:  102 to  229           Dba:0x00400321
------------------------------------------------------------------------
 98179e17 00002500 701f571e 92189c1e 101efb1d ffff981d 551d0f1d d91cb71c 
 941c731c 4a1c1a1c ef1bc51b 9c1b701b 471b191b d61a931a 3c1a101a ee19bc19 
 86194e19 0d190f17 60181618 9a175e17 3d170000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 

 <32 bytes per line>

BBED> d offset 104
 File: /u01/oracle/oradata/ora11g/system01.dbf (1)
 Block: 801              Offsets:  104 to  231           Dba:0x00400321
------------------------------------------------------------------------
 9e170000 2500701f 571e9218 9c1e101e fb1dffff 981d551d 0f1dd91c b71c941c 
 731c4a1c 1a1cef1b c51b9c1b 701b471b 191bd61a 931a3c1a 101aee19 bc198619 
 4e190d19 0f176018 16189a17 5e173d17 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 

 <32 bytes per line>

BBED> m /x 98
 File: /u01/oracle/oradata/ora11g/system01.dbf (1)
 Block: 801              Offsets:  104 to  231           Dba:0x00400321
------------------------------------------------------------------------
 98170000 2500701f 571e9218 9c1e101e fb1dffff 981d551d 0f1dd91c b71c941c 
 731c4a1c 1a1cef1b c51b9c1b 701b471b 191bd61a 931a3c1a 101aee19 bc198619 
 4e190d19 0f176018 16189a17 5e173d17 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 

 <32 bytes per line>

--至此修改row directory指针完成
BBED> sum apply
Check value for File 1, Block 801:
current = 0xe836, required = 0xe836

BBED> verify
DBVERIFY - Verification starting
FILE = /u01/oracle/oradata/ora11g/system01.dbf
BLOCK = 801


DBVERIFY - Verification complete

Total Blocks Examined         : 1
Total Blocks Processed (Data) : 1
Total Blocks Failing   (Data) : 0
Total Blocks Processed (Index): 0
Total Blocks Failing   (Index): 0
Total Blocks Empty            : 0
Total Blocks Marked Corrupt   : 0
Total Blocks Influx           : 0

重新启动数据库

SQL> startup 
ORACLE instance started.

Total System Global Area  313860096 bytes
Fixed Size                  1344652 bytes
Variable Size             260049780 bytes
Database Buffers           46137344 bytes
Redo Buffers                6328320 bytes
Database mounted.
Database opened.
SQL> select * from global_name ;

GLOBAL_NAME
--------------------------------------------------------
ORA11G

SQL>

使用oradebug修改数据库scn

Posted on by

闲着无事看到几篇文章介绍了使用oradebug修改数据库scn的案例,这里也做了两个测试,发现该功能确实很巧妙,通过修改内存中的scn值,然后写入控制文件和数据文件,实现修改scn的方法,不过同样该方法的危害性极大,这里仅供测试使用,生产环境切不可乱使用,可能引起很严重后果
数据库版本信息

SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Prod
PL/SQL Release 10.2.0.4.0 - Production
CORE    10.2.0.4.0      Production
TNS for Linux: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production

SQL> select '惜分飞' XIFENFEI FROM DUAL;

XIFENF
------
惜分飞

在open库中修改scn

SQL> oradebug setmypid
Statement processed.

--查看当前scn
SQL>  oradebug DUMPvar SGA kcsgscn_
kcslf kcsgscn_ [20009228, 20009248) = 00000000 0007A09F 00000019 00000000 00000000 00000000 00000000 20009034
SQL>  select CHECKPOINT_CHANGE# a from v$datafile;

         A
----------
    499314
    499314
    499314
    499314

SQL> select dbms_flashback.get_system_change_number a from dual;

         A
----------
    499877

SQL> select to_number('7A09F','xxxxxxxxx') from dual;

TO_NUMBER('7A09F','XXXXXXXXX')
------------------------------
                        499871

--修改内存中scn值(十进制)
SQL>  oradebug poke 0x20009228 4 8
BEFORE: [20009228, 2000922C) = 00000000
AFTER:  [20009228, 2000922C) = 00000008
SQL> oradebug DUMPvar SGA kcsgscn_
kcslf kcsgscn_ [20009228, 20009248) = 00000008 0007A0D8 00000052 00000000 00000000 00000000 00000000 20009034

SQL> col a for 999999999999999
SQL> select dbms_flashback.get_system_change_number a from dual;

         A
------------
34360238301

SQL> select to_number('8','xx')*4294967296+to_number('0007A0D8','xxxxxxxx') a from dual;

               A
----------------
     34360238296

--做一个checkpoint为了内存中的scn值写入控制文件和数据文件
SQL>  alter system checkpoint;

System altered.

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.

Total System Global Area  318767104 bytes
Fixed Size                  1267236 bytes
Variable Size              96471516 bytes
Database Buffers          213909504 bytes
Redo Buffers                7118848 bytes
Database mounted.
Database opened.

SQL> col a for 999999999999999
SQL> select CHECKPOINT_CHANGE# a from v$datafile;

               A
----------------
     34360238496
     34360238496
     34360238496
     34360238496

SQL> select CHECKPOINT_CHANGE# a from v$datafile_header;

               A
----------------
     34360238496
     34360238496
     34360238496
     34360238496

在mount库中修改scn

SQL> startup mount
ORACLE instance started.

Total System Global Area  318767104 bytes
Fixed Size                  1267236 bytes
Variable Size              96471516 bytes
Database Buffers          213909504 bytes
Redo Buffers                7118848 bytes
Database mounted.
SQL> oradebug setmypid
Statement processed.
--因为数据库是mount状态不能看到scn值
SQL>  oradebug DUMPvar SGA kcsgscn_
kcslf kcsgscn_ [20009228, 20009248) = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 20009034
SQL>  col a for 999999999999999
SQL> select CHECKPOINT_CHANGE# a from v$datafile_header;

               A
----------------
     34360240739
     34360240739
     34360240739
     34360240739

--求出WRAP SCN值
SQL> select 34360240739/4294967296 from dual;

34360240739/4294967296
----------------------
            8.00011697

--修改内存中scn值(十六进制)
SQL> oradebug poke 0x20009228 4 0x0000000a
BEFORE: [20009228, 2000922C) = 00000000
AFTER:  [20009228, 2000922C) = 0000000A
SQL> oradebug DUMPvar SGA kcsgscn_
kcslf kcsgscn_ [20009228, 20009248) = 0000000A 00000000 00000000 00000000 00000000 00000000 00000000 20009034

SQL> alter database open;

Database altered.

SQL> select dbms_flashback.get_system_change_number a from dual
  2  ;

               A
----------------
     42949673074

--注意:使用此种方法修改BASE SCN如果不指定,会从0开始计数
SQL>  oradebug DUMPvar SGA kcsgscn_
kcslf kcsgscn_ [20009228, 20009248) = 0000000A 00000077 0000001C 00000000 00000000 00000000 00000000 20009034
SQL> select to_number('A','xx')*4294967296+to_number('00000077','xxxxxxxx') a from dual;

               A
----------------
     42949673079

SQL> alter system checkpoint;

System altered.

SQL> select CHECKPOINT_CHANGE# a from v$datafile_header;

               A
----------------
     42949673095
     42949673095
     42949673095
     42949673095

SQL> select CHECKPOINT_CHANGE# a from v$datafile;

               A
----------------
     42949673095
     42949673095
     42949673095
     42949673095

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.

Total System Global Area  318767104 bytes
Fixed Size                  1267236 bytes
Variable Size              96471516 bytes
Database Buffers          213909504 bytes
Redo Buffers                7118848 bytes
Database mounted.
Database opened.
SQL> select CHECKPOINT_CHANGE# a from v$datafile_header;

               A
----------------
     42949673231
     42949673231
     42949673231
     42949673231

在oradebug推进scn的过程中，需要注意不同平台，不同位数的ORACLE数据库可能推进方式有一定的区别，操作前最好在系统平台位数上进行测试，否则有可能导致恢复后果更加麻烦