Database SOS – 第109页 – Professional Database Recovery Support@+8617813235971

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

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备份对各种数据块操作

有不少人对于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

密码保护：dul实现exp dump文件转换sqlldr格式

11GR2 Control file enqueue hold time tracking dump

如果你比较心细,可能在11.2的数据库中发现alert文件中存在存在类此下面的记录

Errors in file /oradb/diag/rdbms/offon/offon2/trace/offon2_ckpt_19660878.trc:

查看trace文件发现

*** 2012-08-01 03:36:03.520
  1: 1450ms (rw) file: kct.c line: 1011 count: 1 total: 1450ms time: 1594117
  2: 890ms (rw) file: kcrf.c line: 10012 count: 6 total: 4266ms time: 1820928
  3: 830ms (ro) file: kcf.c line: 5306 count: 1 total: 830ms time: 1594116
  4: 530ms (rw) file: kcv.c line: 11783 count: 1 total: 530ms time: 3207607
Control file enqueue hold time tracking dump at time: 3376956
*** 2012-08-03 02:14:38.714
  1: 1450ms (rw) file: kct.c line: 1011 count: 1 total: 1450ms time: 1594117
  2: 890ms (rw) file: kcrf.c line: 10012 count: 7 total: 4953ms time: 1820928
  3: 830ms (ro) file: kcf.c line: 5306 count: 1 total: 830ms time: 1594116
  4: 530ms (rw) file: kcv.c line: 11783 count: 1 total: 530ms time: 3207607
Control file enqueue hold time tracking dump at time: 3384212

这个类此我们在10g中看到的lgwr的警告类此,见Warning: log write time 560ms, size 3KB,其实也就是oracle对lgwr进程写入日志慢的时候的一个trace功能记录下来的.
我们这里遇到的是因为oracle对ckpt进程的trace,当control file enqueue holding time tracking size超过10的时候，就会记录到trace文件中,oracle 内部文档对于该问题的一些描述如下:

About the issue, this is the expected behavior on 11.2.
New controlfile enqueue hold time tracking statistics have been added in 11.2 to
aid diagnosis of controlfile transaction related performance related issues:
Control File Enqueue AWR Statistics:
* max cf enq hold time - The maximum amount of time in milliseconds a client has held the control file enqueue.
* total cf enq hold time - The total amount of time in milliseconds all clients have held the control file enqueue.
* total number of cf enq holders - The total number of times clients have held the control file enqueue.
Periodically, the CKPT process dumps statistics for the top N control file enqueue holders.
N defaults to 10, but can be modified with the static hidden parameter:
_controlfile_enqueue_holding_time_tracking_size.The dump looks like the following:
Preface: "Control file enqueue hold time tracking dump at time: [relative time]".
* a. Time the client has held the control file enqueue.
* b. Type of client's control file enqueue transaction - rw or ro.
* c. File name where the client obtained control file enqueue.
* d. Line number where the client obtained control file enqueue.
* e. Number of times the client has held the control file enqueue since it became a member of the top N.
* f. Total time the client has held the control file in all those times from [e].
* g. Relative time the client obtained the control file enqueue from [a].

查询数据库默认值

SQL> col value for a24
SQL> col description for a70
SQL> set linesize 180
SQL> select a.ksppinm name,b.ksppstvl value,a.ksppdesc description
  2    from x$ksppi a,x$ksppcv b
  3    where a.inst_id = USERENV ('Instance')
  4     and b.inst_id = USERENV ('Instance')
  5     and a.indx = b.indx
  6     and upper(a.ksppinm) LIKE upper('%&param%')
  7  order by name
  8  /
Enter value for param: _controlfile_enqueue_holding_time_tracking_size
old   6:    and upper(a.ksppinm) LIKE upper('%&param%')
new   6:    and upper(a.ksppinm) LIKE upper('%_controlfile_enqueue_holding_time_tracking_size%')
NAME                                               VALUE    DESCRIPTION
-------------------------------------------------- -------- ------------------------------------------------
_controlfile_enqueue_holding_time_tracking_size    10       control file enqueue holding time tracking size

虽然在alert日志中使用Error的形式显示该错误,但是这只是一个oracle作为诊断数据库Control File Enqueue性能的一个依据,大部分情况下,我们可以选择忽略或者关闭该诊断功能.屏蔽该提示方法如下:

The way to shut off is set _controlefile_enqueue_holding_time_tracking_size = 0 then restart the database
-- spfile
alter system set "_controlfile_enqueue_holding_time_tracking_size"=0 scope=spfile;
-- pfile
_controlfile_enqueue_holding_time_tracking_size=0
Restart database

ORA-609 TNS-12537 and TNS-12547 in 11g Alert.log

数据库alert日志出现如下错误

Fatal NI connect error 12537, connecting to:
 (LOCAL=NO)
  VERSION INFORMATION:
        TNS for IBM/AIX RISC System/6000: Version 11.2.0.2.0 - Production
        TCP/IP NT Protocol Adapter for IBM/AIX RISC System/6000: Version 11.2.0.2.0 - Production
        Oracle Bequeath NT Protocol Adapter for IBM/AIX RISC System/6000: Version 11.2.0.2.0 - Production
  Time: 21-AUG-2012 09:50:15
  Tracing not turned on.
  Tns error struct:
    ns main err code: 12537
TNS-12537: TNS:connection closed
    ns secondary err code: 12560
    nt main err code: 0
    nt secondary err code: 0
    nt OS err code: 0
opiodr aborting process unknown ospid (15204768) as a result of ORA-609

错误的原因

The ORA-609 error is thrown when a client connection of any kind failed to complete or
aborted the connection process before the connection/authentication process was complete.
Very often, this connection abort is due to a timeout.  Beginning with 10gR2, a default value for
inbound connect timeout has been set at 60 seconds.
This time limit is often inadequate for the entire connection process to complete.
We have also discovered that the ORA-609 occurs frequently in installations
where the database is monitored by DB Console and the Enterprise Manager agent (emagent).
After the DB Console is started and as a matter of routine, the emagent will repeatedly try to
connect to the target instances.
We can see frequent emagent connections in the listener.log without error.
However, on occasion it may have failed to complete the connection process at the database so an ORA-609 is thrown.
The emagent will simply retry the connection and may be successful on the subsequent try.
(Provided there is no real fault occurring at the listener or database).
This temporary failure to connect will not be reported back to DB Console and there will be no indication,
 except for the ORA-609, that a fault occurred.

出现这个问题的主要原因是因为从10.2开始inbound connect timeout默认为60 seconds,而在很多建立连接过程可能超过这个时间从而出现类此错误,常见的诱因是DB Console 和 Enterprise Manager agent (emagent). EM会重复的尝试连接到数据库。其过程中会偶尔的出现连接超时的问题，但是接下来会继续尝试，并获得成功。这种临时的失败不会导致EM报错而只会以ora-609的形式记录在alert log中.

处理方法

For that reason, we often recommend increasing the values for INBOUND_CONNECT_TIMEOUT at both listener
and server side sqlnet.ora file as a preventive measure.
If the problem  is due to connection timeouts, an increase in the following parameters should eliminate
or reduce the occurrence of the ORA-609s.
e.g.
Sqlnet.ora: SQLNET.INBOUND_CONNECT_TIMEOUT=180
Listener.ora: INBOUND_CONNECT_TIMEOUT_listener_name=120
These settings are in seconds.  Again, the default is 60.

问题跟踪方法

If the issue persists and inbound connect does not have any effect, the following steps are intended to
help locate  the client that may be causing the errors.
1)  Suppress the TNS errors in the alert.log by setting the following listener.ora file parameter:
DIAG_ADR_ENABLED_listener_name=OFF
This will cause the TNS errors to be posted to the ORACLE_HOME/network/log/sqlnet.log file that is
local to the database and
may yield useful information about the client's address.
For example, here's a snippet from a server side sqlnet.log where client address info was posted:
Production Time: 15-FEB-2010 07:15:01
Fatal NI connect error 12537, connecting to:
(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(Host=yourhost)(Port=1521))(CONNECT_DATA=(SID=PROD1DR)
(CID=(PROGRAM=sqlplus)(HOST=client_host)(USER=client))))
Observe the PROGRAM and HOST fields on the last line.  This is where the connection originated.
Be sure to match timestamps in the sqlnet.log with the timestamps of the alert.log errors.
Once you've located the offending client,
you can enable client tracing to try and determine the cause:
TRACE_LEVEL_CLIENT=16
TRACE_DIRECTORY_CLIENT=<dir location>
TRACE_TIMESTAMP_CLIENT=TRUE
DIAG_ADR_ENABLED=off   <<<<<11g or newer client requirement
If you need assistance with client or server tracing, please open an SR with Global Customer Support.
2)  Check the listener.log for client connections that were logged at timestamps that match the ORA-609
timestamps as they appear in the alert.log.
The client information is recorded in each listener.log entry.
Since this error occurs AFTER the listener has handled the connection,
do not expect to see errors in the listener.log.
Here's an example snippet of an incoming client connection that was posted to the listener.log:
20-JAN-2009 17:08:45 (CONNECT_DATA=(SID=orcl)(CID=
(PROGRAM=D:\oracle\product\10.1.0\Db_1\perl\5.6.1\bin\MSWin32-x86\perl.exe)(HOST=myclient)
Note that the exact timestamp, program name and client host will often be recorded.  Again,
once you've located the offending client,
enable tracing (see above) to try to capture the connection failure.
3)  Enable server side Oracle Net tracing and capture the TNS error along with the incoming connection.
Match the PID that accompanies the ORA-609 to the server trace label.  e.g.
ORA-609 : opiodr aborting process unknown ospid (4799_1)  *Note the PID
This PID would correspond to server trace labeled:  svr_4799.trc.  Check the server trace for either
TNS error (the 609 will not appear)
and try to locate the originating client address.  If assistance is needed for this investigation,
please open an SR with Oracle Support.
See below for instuctions on enabling Oracle Net server tracing.
The following details the discovery of the source of an ORA-609 for a real case:
The alert.log reports the following messages intermittently but frequently:
Mon Nov 16 22:39:22 2009
ORA-609 : opiodr aborting process unknown ospid (nnnn)
Enabled Oracle Net server tracing:
TRACE_LEVEL_SERVER=16
TRACE_DIRECTORY_SERVER=<dir location>
TRACE_TIMESTAMP_SERVER=TRUE
DIAG_ADR_ENABLED=off
Reloaded listener and wait for error to appear again.:
ORA-609 : opiodr aborting process unknown ospid (5233_1)
Note that the server trace file set that corresponded to this event was named svr_5233*.trc.
Of course the timestamps of the alert.log event and the server trace creation matched as well.
A review of the server trace showed only an EOF failure and the  TNS-12537 error:
Read unexpected EOF ERROR
nserror: nsres: id=0, op=68, ns=12537
In this particular case, there was no information about the client in the trace.
This is atypical for a server trace.
It may be that the client aborted before all the client information was posted to the file.
However, there was post in the listener.log f
or an emagent connection that was established at the same point in time.
Here's an excerpt from a listener.log entry where an emagent establishes a connection:
PROGRAM=D:\oracle\product\10.1.0\Db_1\bin\emagent.exe)
Checked the EM Agent traces and logs and discovered the following entry:
Fatal NI connect error 12547, connecting to:
(LOCAL=NO)
VERSION INFORMATION:
TNS for Solaris: Version 11.1.0.7.0 - Production
Oracle Bequeath NT Protocol Adapter for Solaris: Version 11.1.0.7.0 - Production
TCP/IP NT Protocol Adapter for Solaris: Version 11.1.0.7.0 - Production
Time: 16-NOV-2009 22:39:22
****Tracing to file: /backup/sid_traces/sqlnetlog/svr_5233.trc
Tns error struct:
ns main err code: 12547
TNS-12547: TNS:lost contact
ns secondary err code: 12560
nt main err code: 0
nt secondary err code: 0
nt OS err code: 0
****Note the name of the server trace which contains the PID:  svr_5233.trc
Also, the timestamp of the agent event matches the timestamp of the alert.log error.
Check the following locations for EM Agent traces. If working with support on this issue and
the EM Agent is suspected, upload ALL files under:
$ORACLE_HOME/sysman/log/emagent.trc < Single node agent trace location
$ORACLE_HOME/host/sysman/log/emagent.trc < RAC agent trace location
It was determined that in this case, the emagent was aborting the connection
before it was complete and then simply reconnecting
and succeeding on the subsequent try.  No errors were reported in the listener log or listener trace.
No errors were returned to the DB Console.
There was no apparent outage of any kind.  No action was taken to correct the ORA-609 in this case.
It was decided that the message was informational and completely benign.

参考文档：
ORA-609 TNS-12537 and TNS-12547 in 11g Alert.log (Doc ID 1116960.1)
Troubleshooting Guide ORA-609 : Opiodr aborting process unknown ospid (Doc ID 1121357.1)

ORACLE用户重命名

从oracle 11.2.0.2开始提供了用户重命名的新特性，在以前的版本中，如果想对用户重命名，一般来说是先创建一个新的用户并授权，然后将原用户下的所有对象导入，然后删除旧的用户！
数据库版本信息

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> create user xifenfei identified by xifenfei;
User created.
SQL> grant connect,resource to xifenfei;
Grant succeeded.
SQL> conn xifenfei/xifenfei
Connected.
SQL> create table t_xifenfei   as select * from user_users;
Table created.
SQL> create index ind_t_xifenfei on t_xifenfei(user_id);
Index created.
SQL> conn / as sysdba
Connected.
SQL> select object_type,object_name from dba_objects where owner='XIFENFEI';
OBJECT_TYPE         OBJECT_NAME
------------------- ---------------------------------------------------------
TABLE               T_XIFENFEI
INDEX               IND_T_XIFENFEI

尝试修改用户名

SQL> alter user xifenfei rename to xff identified by xifenfei;
alter user xifenfei rename to xff identified by xifenfei
                    *
ERROR at line 1:
ORA-00922: missing or invalid option
--默认值是false
SQL> col name for a32
SQL> col value for a24
SQL> col description for a70
SQL> set linesize 150
SQL> select a.ksppinm name,b.ksppstvl value,a.ksppdesc description
  2    from x$ksppi a,x$ksppcv b
  3   where a.inst_id = USERENV ('Instance')
   and b.inst_id = USERENV ('Instance')
  4    5     and a.indx = b.indx
  6     and upper(a.ksppinm) LIKE upper('%&param%')
  7  order by name
  8  /
Enter value for param: _enable_rename_user
old   6:    and upper(a.ksppinm) LIKE upper('%&param%')
new   6:    and upper(a.ksppinm) LIKE upper('%_enable_rename_user%')
NAME                             VALUE                    DESCRIPTION
-------------------------------- ------------------------ ------------------------------------------------
_enable_rename_user              FALSE                    enable RENAME-clause using ALTER USER statement
SQL> startup force restrict
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.
--_enable_rename_user=false,在restrict模式也不能修改用户名
SQL> ALTER user XFF RENAME TO xffei IDENTIFIED BY xifenfei;
ALTER user XFF RENAME TO xffei IDENTIFIED BY xifenfei
               *
ERROR at line 1:
ORA-00922: missing or invalid option

设置隐含参数

SQL> alter system set "_enable_rename_user"=true scope=spfile;
System altered.
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup restrict
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> ALTER user xifenfei RENAME TO xff IDENTIFIED BY xifenfei;
User altered.

测试结果

SQL> startup force
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 object_type,object_name from dba_objects where owner='XIFENFEI';
no rows selected
SQL> select object_type,object_name from dba_objects where owner='XFF';
OBJECT_TYPE         OBJECT_NAME
------------------- ----------------------------------------------------
TABLE               T_XIFENFEI
INDEX               IND_T_XIFENFEI
SQL> conn xff/xifenfei
Connected.
SQL> select count(*) from t_xifenfei;
  COUNT(*)
----------
         1

相关文档和上面的测试,得出结论:数据库版本在11.2.0.2及其以上版本,_enable_rename_user设置为true,数据库启动到restrict模式可以修改用户名

bbed 使用实现 drop index 操作

这里个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 删除 cluster table 记录

对应cluster table使用bbed删除其中的部分记录,一直没有被攻克的难关,今天突发灵感,解决了cluster table 通过bbed删除记录后验证不能通过的难题.主要修改操作:oracle在index cluster中删除一条记录实际上只是把这条记录的行头由0x6c修改为0x7c,并且把这条记录所对应的聚簇键所在行的行头中记录的comc减1;修改验证信息
模拟cluster table 环境

SQL> create cluster clu_xff(id number(4));
Cluster created.
SQL> create table t_xifenfei
  2  (id number(4)
  3  ,name      varchar2(25)
  4  )CLUSTER clu_xff (id);
Table created.
SQL> create index ind_clu_xff ON CLUSTER clu_xff;
Index created.
SQL> insert into t_xifenfei values(1,'xifenfei');
1 row created.
SQL> insert into t_xifenfei values(2,'www.xifenfei.com');
1 row created.
SQL> insert into t_xifenfei values(3,'XIFENFEI');
1 row created.
SQL> insert into t_xifenfei values(4,'WWW.XIFENFEI.COM');
1 row created.
SQL> insert into t_xifenfei values(2,'WWW.xifenfei.COM');
1 row created.
SQL> insert into t_xifenfei values(3,'XFF_CHF');
1 row created.
SQL> COMMIT;
Commit complete.
SQL> select t.*,
  2  dbms_rowid.rowid_relative_fno(rowid)||'_'||dbms_rowid.rowid_block_number(rowid) location
  3  from t_xifenfei t;
        ID NAME                      LOCATION
---------- ------------------------- ----------
         2 www.xifenfei.com          4_171
         2 WWW.xifenfei.COM          4_171
         3 XIFENFEI                  4_172
         3 XFF_CHF                   4_172    <----需要删除记录
         4 WWW.XIFENFEI.COM          4_174
         1 xifenfei                  4_175
6 rows selected.
SQL> alter system checkpoint;
System altered.
SQL> conn / as sysdba
Connected.
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.

bbed删除记录操作

[oracle@xifenfei ~]$ bbed listfile=listfile mode=edit password=blockedit
BBED: Release 2.0.0.0.0 - Limited Production on Thu Aug 9 09:33:58 2012
Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
************* !!! For Oracle Internal Use only !!! ***************
BBED> set file 4 block 172
        FILE#           4
        BLOCK#          172
BBED> map
 File: /u01/oracle/oradata/ora11g/users01.dbf (4)
 Block: 172                                   Dba:0x010000ac
------------------------------------------------------------
 KTB Data Block (Table/Cluster)
 struct kcbh, 20 bytes                      @0
 struct ktbbh, 72 bytes                     @20
 struct kdbh, 14 bytes                      @100
 struct kdbt[2], 8 bytes                    @114
 sb2 kdbr[3]                                @122
 ub1 freespace[8013]                        @128
 ub1 rowdata[47]                            @8141
 ub4 tailchk                                @8188
--查看该块的相关数据值
BBED> p kdbr
sb2 kdbr[0]                                 @122      8066
sb2 kdbr[1]                                 @124      8053
sb2 kdbr[2]                                 @126      8041
BBED> p *kdbr[0]
rowdata[25]
-----------
ub1 rowdata[25]                             @8166     0xac
BBED> x /rn
rowdata[25]                                 @8166
-----------
flag@8166: 0xac (KDRHFL, KDRHFF, KDRHFH, KDRHFK)
lock@8167: 0x00
cols@8168:    1
kref@8169:    2
mref@8171:    2
hrid@8173:0x010000ac.0
nrid@8179:0x010000ac.0
col    0[2] @8185: 3
BBED> p *kdbr[1]
rowdata[12]
-----------
ub1 rowdata[12]                             @8153     0x6c
BBED> x /rc
rowdata[12]                                 @8153
-----------
flag@8153: 0x6c (KDRHFL, KDRHFF, KDRHFH, KDRHFC)
lock@8154: 0x00
cols@8155:    1
col    0[8] @8157: XIFENFEI
BBED> p *kdbr[2]
rowdata[0]
----------
ub1 rowdata[0]                              @8141     0x6c
BBED> x /rc
rowdata[0]                                  @8141
----------
flag@8141: 0x6c (KDRHFL, KDRHFF, KDRHFH, KDRHFC)
lock@8142: 0x02
cols@8143:    1
col    0[7] @8145: XFF_CHF   <----需要删除记录
BBED> m /x 7c offset 8141
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y
 File: /u01/oracle/oradata/ora11g/users01.dbf (4)
 Block: 172              Offsets: 8141 to 8191           Dba:0x010000ac
------------------------------------------------------------------------
 7c020100 07584646 5f434846 6c000100 08584946 454e4645 49ac0001 02000200
 010000ac 00000100 00ac0000 02c10402 066c1d
 <32 bytes per line>
BBED> m /x 01 offset 8171
 File: /u01/oracle/oradata/ora11g/users01.dbf (4)
 Block: 172              Offsets: 8171 to 8191           Dba:0x010000ac
------------------------------------------------------------------------
 01000100 00ac0000 010000ac 000002c1 0402066c 1d
 <32 bytes per line>
BBED> p *kdbr[0]
rowdata[25]
-----------
ub1 rowdata[25]                             @8166     0xac
BBED> x /rn
rowdata[25]                                 @8166
-----------
flag@8166: 0xac (KDRHFL, KDRHFF, KDRHFH, KDRHFK)
lock@8167: 0x00
cols@8168:    1
kref@8169:    2
mref@8171:    1
hrid@8173:0x010000ac.0
nrid@8179:0x010000ac.0
col    0[2] @8185: 3
BBED> sum apply
Check value for File 4, Block 172:
current = 0x8f87, required = 0x8f87
BBED> verify
DBVERIFY - Verification starting
FILE = /u01/oracle/oradata/ora11g/users01.dbf
BLOCK = 172
Block Checking: DBA = 16777388, Block Type = KTB-managed data block
data header at 0xb53ed264
kdbchk: the amount of space used is not equal to block size   <----数据块使用空间错误
        used=67 fsc=0 avsp=8013 dtl=8088
Block 172 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                       @100
   ub1 kdbhflag                             @100      0x00 (NONE)
   sb1 kdbhntab                             @101      2
   sb2 kdbhnrow                             @102      3
   sb2 kdbhfrre                             @104     -1
   sb2 kdbhfsbo                             @106      28
   sb2 kdbhfseo                             @108      8041
   sb2 kdbhavsp                             @110      8013
   sb2 kdbhtosp                             @112      8013
BBED> m /x 551f offset 110
 File: /u01/oracle/oradata/ora11g/users01.dbf (4)
 Block: 172              Offsets:  110 to  126           Dba:0x010000ac
------------------------------------------------------------------------
 551f4d1f 00000100 01000200 821f751f
 <32 bytes per line>
BBED>  p kdbh
struct kdbh, 14 bytes                       @100
   ub1 kdbhflag                             @100      0x00 (NONE)
   sb1 kdbhntab                             @101      2
   sb2 kdbhnrow                             @102      3
   sb2 kdbhfrre                             @104     -1
   sb2 kdbhfsbo                             @106      28
   sb2 kdbhfseo                             @108      8041
   sb2 kdbhavsp                             @110      8021
   sb2 kdbhtosp                             @112      8013
BBED> sum apply
Check value for File 4, Block 172:
current = 0x8f9f, required = 0x8f9f
BBED> verify
DBVERIFY - Verification starting
FILE = /u01/oracle/oradata/ora11g/users01.dbf
BLOCK = 172
Block Checking: DBA = 16777388, Block Type = KTB-managed data block
data header at 0xb53ed264
kdbchk: avsp(8021) > tosp(8013)           <----avsp 不能大于tosp
Block 172 failed with check code 6128
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 551f offset 112
 File: /u01/oracle/oradata/ora11g/users01.dbf (4)
 Block: 172              Offsets:  112 to  128           Dba:0x010000ac
------------------------------------------------------------------------
 551f0000 01000100 0200821f 751f691f
 <32 bytes per line>
BBED> sum apply
Check value for File 4, Block 172:
current = 0x8f87, required = 0x8f87
BBED> verify
DBVERIFY - Verification starting
FILE = /u01/oracle/oradata/ora11g/users01.dbf
BLOCK = 172
Block Checking: DBA = 16777388, Block Type = KTB-managed data block
data header at 0xb53ed264
kdbchk: space available on commit is incorrect
        tosp=8021 fsc=0 stb=4 avsp=8021        <----tosp值不合适
Block 172 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> set count 64
        COUNT           64
BBED> m /x 591f offset 112
 File: /u01/oracle/oradata/ora11g/users01.dbf (4)
 Block: 172              Offsets:  112 to  175           Dba:0x010000ac
------------------------------------------------------------------------
 591f0000 01000100 0200821f 751f691f 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 <32 bytes per line>
BBED> sum apply
Check value for File 4, Block 172:
current = 0x8f8b, required = 0x8f8b
--修改块工作完成
BBED> verify
DBVERIFY - Verification starting
FILE = /u01/oracle/oradata/ora11g/users01.dbf
BLOCK = 172
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

启动库验证

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> conn chf/xifenfei
Connected.
SQL> select * from t_xifenfei;
        ID NAME
---------- -------------------------
         2 www.xifenfei.com
         2 WWW.xifenfei.COM
         3 XIFENFEI
         4 WWW.XIFENFEI.COM
         1 xifenfei
--XFF_CHF记录被删除
SQL> insert into t_xifenfei values(3,'惜分飞');
1 row created.
SQL> delete from t_xifenfei where name='XIFENFEI';
1 row deleted.
SQL> commit;
Commit complete.
SQL> select * from t_xifenfei;
        ID NAME
---------- -------------------------
         2 www.xifenfei.com
         2 WWW.xifenfei.COM
         3 惜分飞
         4 WWW.XIFENFEI.COM
         1 xifenfei
--证明XFF_CHF所在数据块其他dml操作正常,证明修改正确

bbed 恢复 GLOBAL_NAME 为空故障

看到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>

利用bbed找回ORACLE更新前值

模拟数据块更新

SQL> create table t_xifenfei(id number,name varchar2(10));
Table created.
SQL> insert into t_xifenfei values(1,'XFF');
1 row created.
SQL> insert into t_xifenfei values(2,'CHF');
1 row created.
SQL> commit;
Commit complete.
SQL> alter system checkpoint;
System altered.
SQL> select id,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 t_xifenfei;
        ID ROWID                 REL_FNO    BLOCKNO      ROWNO
---------- ------------------ ---------- ---------- ----------
         1 AAASc+AAEAAAACvAAA          4        175          0
         2 AAASc+AAEAAAACvAAB          4        175          1
SQL> select dump(1,'16') from dual;
DUMP(1,'16')
-----------------
Typ=2 Len=2: c1,2
SQL> select dump(2,'16') from dual;
DUMP(2,'16')
-----------------
Typ=2 Len=2: c1,3
SQL> select dump('XFF','16') FROM DUAL;
DUMP('XFF','16')
----------------------
Typ=96 Len=3: 58,46,46
SQL> SELECT DUMP('CHF','16') FROM DUAL;
DUMP('CHF','16')
----------------------
Typ=96 Len=3: 43,48,46
SQL> update t_xifenfei set name='XIFENFEI' where id=1;
1 row updated.
SQL> commit;
Commit complete.
SQL> select dump('XIFENFEI','16') from dual;
DUMP('XIFENFEI','16')
-------------------------------------
Typ=96 Len=8: 58,49,46,45,4e,46,45,49
SQL> alter system checkpoint;
System altered.
SQL> select * from t_xifenfei;
        ID NAME
---------- ----------
         1 XIFENFEI
         2 CHF

这里我们对数据库进行了一次更新操作,并且dump出来对应值,为了方便定位到相应记录

bbed查看相关值

[oracle@xifenfei ~]$ bbed listfile=listfile mode=edit password=blockedit
BBED: Release 2.0.0.0.0 - Limited Production on Wed Aug 8 20:50:47 2012
Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
************* !!! For Oracle Internal Use only !!! ***************
BBED> set file 4 block 175
        FILE#           4
        BLOCK#          175
BBED> map
 File: /u01/oracle/oradata/ora11g/users01.dbf (4)
 Block: 175                                   Dba:0x010000af
------------------------------------------------------------
 KTB Data Block (Table/Cluster)
 struct kcbh, 20 bytes                      @0
 struct ktbbh, 72 bytes                     @20
 struct kdbh, 14 bytes                      @100
 struct kdbt[1], 4 bytes                    @114
 sb2 kdbr[2]                                @118
 ub1 freespace[8031]                        @122
 ub1 rowdata[35]                            @8153
 ub4 tailchk                                @8188
BBED> p kdbr
sb2 kdbr[0]                                 @118      8053
sb2 kdbr[1]                                 @120      8068
BBED> p *kdbr[1]
rowdata[15]
-----------
ub1 rowdata[15]                             @8168     0x2c
BBED> x /rnc
rowdata[15]                                 @8168
-----------
flag@8168: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@8169: 0x00
cols@8170:    2
col    0[2] @8171: 2
col    1[3] @8174: CHF
BBED> p *kdbr[0]
rowdata[0]
----------
ub1 rowdata[0]                              @8153     0x2c
BBED> x /rnc
rowdata[0]                                  @8153
----------
flag@8153: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@8154: 0x02
cols@8155:    2
col    0[2] @8156: 1
col    1[8] @8159: XIFENFEI
BBED> set count 64
        COUNT           64
 <32 bytes per line>
BBED> d /v
 File: /u01/oracle/oradata/ora11g/users01.dbf (4)
 Block: 175     Offsets: 8153 to 8191  Dba:0x010000af
-------------------------------------------------------
 2c020202 c1020858 4946454e 4645492c l ,......XIFENFEI,
 000202c1 03034348 462c0002 02c10203 l ......CHF,......
 58464602 068de8                     l XFF....
 <16 bytes per line>

使用bbed找回历史值

--准备工作,通过dump出来的值,推算出来第一条记录的起点02c10203584646,
--在这个值的基础上offset-3得到offset值为8078
BBED> p kdbr
sb2 kdbr[0]                                 @118      8053
sb2 kdbr[1]                                 @120      8068
--修改row directory指针位置
BBED> m /x 8e1f
 File: /u01/oracle/oradata/ora11g/users01.dbf (4)
 Block: 175              Offsets:  118 to  181           Dba:0x010000af
------------------------------------------------------------------------
 8e1f841f 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 <32 bytes per line>
BBED> p kdbr
sb2 kdbr[0]                                 @118      8078
sb2 kdbr[1]                                 @120      8068
BBED> sum apply
Check value for File 4, Block 175:
current = 0xdff8, required = 0xdff8
BBED> verify
DBVERIFY - Verification starting
FILE = /u01/oracle/oradata/ora11g/users01.dbf
BLOCK = 175
Block Checking: DBA = 16777391, Block Type = KTB-managed data block
data header at 0xb53cd264
kdbchk: xaction header lock count mismatch
        trans=2 ilk=1 nlo=0     --提示事务锁错误
Block 175 failed with check code 6108
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[0]
rowdata[25]
-----------
ub1 rowdata[25]                             @8178     0x2c
BBED> d
 File: /u01/oracle/oradata/ora11g/users01.dbf (4)
 Block: 175              Offsets: 8178 to 8191           Dba:0x010000af
------------------------------------------------------------------------
 2c000202 c1020358 46460206 8de8
 <32 bytes per line>
BBED> x /rnc
rowdata[25]                                 @8178
-----------
flag@8178: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@8179: 0x00  --被更新前的记录事务锁标识为0,而更新后的事务锁标识为2
cols@8180:    2
col    0[2] @8181: 1
col    1[3] @8184: XFF
--修改事务锁标识为2
BBED> m /x 02 offset 8179
 File: /u01/oracle/oradata/ora11g/users01.dbf (4)
 Block: 175              Offsets: 8179 to 8191           Dba:0x010000af
------------------------------------------------------------------------
 020202c1 02035846 4602068d e8
 <32 bytes per line>
BBED> set offset 8153
        OFFSET          8153
BBED> d
 File: /u01/oracle/oradata/ora11g/users01.dbf (4)
 Block: 175              Offsets: 8153 to 8191           Dba:0x010000af
------------------------------------------------------------------------
 2c020202 c1020858 4946454e 4645492c 000202c1 03034348 462c0202 02c10203
 58464602 068de8
 <32 bytes per line>
--把更新后值的事务锁标识改为0
BBED> m /x 00 offset +1
 File: /u01/oracle/oradata/ora11g/users01.dbf (4)
 Block: 175              Offsets: 8154 to 8191           Dba:0x010000af
------------------------------------------------------------------------
 000202c1 02085849 46454e46 45492c00 0202c103 03434846 2c020202 c1020358
 46460206 8de8
 <32 bytes per line>
BBED> sum apply
Check value for File 4, Block 175:
current = 0xddfa, required = 0xddfa
BBED> verify
DBVERIFY - Verification starting
FILE = /u01/oracle/oradata/ora11g/users01.dbf
BLOCK = 175
Block Checking: DBA = 16777391, Block Type = KTB-managed data block
data header at 0xb53cd264
kdbchk: the amount of space used is not equal to block size
        used=42 fsc=0 avsp=8041 dtl=8088   -->提示块的空间使用不正确
Block 175 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 ktbbh
struct ktbbh, 72 bytes                      @20
   ub1 ktbbhtyp                             @20       0x01 (KDDBTDATA)
   union ktbbhsid, 4 bytes                  @24
      ub4 ktbbhsg1                          @24       0x0001273e
      ub4 ktbbhod1                          @24       0x0001273e
   struct ktbbhcsc, 8 bytes                 @28
      ub4 kscnbas                           @28       0x0000e88a
      ub2 kscnwrp                           @32       0x0002
   sb2 ktbbhict                             @36       2
   ub1 ktbbhflg                             @38       0x32 (NONE)
   ub1 ktbbhfsl                             @39       0x00
   ub4 ktbbhfnx                             @40       0x010000a8
   struct ktbbhitl[0], 24 bytes             @44
      struct ktbitxid, 8 bytes              @44
         ub2 kxidusn                        @44       0x0006
         ub2 kxidslt                        @46       0x001e
         ub4 kxidsqn                        @48       0x000002c6
      struct ktbituba, 8 bytes              @52
         ub4 kubadba                        @52       0x00c000d9
         ub2 kubaseq                        @56       0x0086
         ub1 kubarec                        @58       0x2a
      ub2 ktbitflg                          @60       0x8000 (KTBFCOM)
      union _ktbitun, 2 bytes               @62
         sb2 _ktbitfsc                      @62       2
         ub2 _ktbitwrp                      @62       0x0002
      ub4 ktbitbas                          @64       0x0000e550
   struct ktbbhitl[1], 24 bytes             @68
      struct ktbitxid, 8 bytes              @68
         ub2 kxidusn                        @68       0x0006
         ub2 kxidslt                        @70       0x0008
         ub4 kxidsqn                        @72       0x000002c7
      struct ktbituba, 8 bytes              @76
         ub4 kubadba                        @76       0x00c000da
         ub2 kubaseq                        @80       0x0086
         ub1 kubarec                        @82       0x12
      ub2 ktbitflg                          @84       0x2001 (KTBFUPB)
      union _ktbitun, 2 bytes               @86
         sb2 _ktbitfsc                      @86       0
         ub2 _ktbitwrp                      @86       0x0000
      ub4 ktbitbas                          @88       0x0000e88d
--所有的_ktbitfsc修改为0
BBED> m /x 00 offset 62
 File: /u01/oracle/oradata/ora11g/users01.dbf (4)
 Block: 175              Offsets:   62 to  125           Dba:0x010000af
------------------------------------------------------------------------
 000050e5 00000600 0800c702 0000da00 c0008600 12000120 00008de8 00000000
 00000000 00000001 0200ffff 1600751f 691f691f 00000200 8e1f841f 00000000
 <32 bytes per line>
BBED> sum apply
Check value for File 4, Block 175:
current = 0xddf8, required = 0xddf8
BBED> verify
DBVERIFY - Verification starting
FILE = /u01/oracle/oradata/ora11g/users01.dbf
BLOCK = 175
Block Checking: DBA = 16777391, Block Type = KTB-managed data block
data header at 0xb53cd264
kdbchk: the amount of space used is not equal to block size
        used=42 fsc=0 avsp=8041 dtl=8088
Block 175 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                       @100
   ub1 kdbhflag                             @100      0x00 (NONE)
   sb1 kdbhntab                             @101      1
   sb2 kdbhnrow                             @102      2
   sb2 kdbhfrre                             @104     -1
   sb2 kdbhfsbo                             @106      22
   sb2 kdbhfseo                             @108      8053
   sb2 kdbhavsp                             @110      8045
   sb2 kdbhtosp                             @112      8045
--修改kdbhtosp和kdbhavsp值
BBED>  m /x 6e1f  offset 112
 File: /u01/oracle/oradata/ora11g/users01.dbf (4)
 Block: 175              Offsets:  112 to  175           Dba:0x010000af
------------------------------------------------------------------------
 6e1f0000 02008e1f 841f0000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 <32 bytes per line>
BBED> m /x  6e1f  offset 110
 File: /u01/oracle/oradata/ora11g/users01.dbf (4)
 Block: 175              Offsets:  110 to  173           Dba:0x010000af
------------------------------------------------------------------------
 6e1f6e1f 00000200 8e1f841f 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 <32 bytes per line>
BBED> sum apply
Check value for File 4, Block 175:
current = 0xddf8, required = 0xddf8
--数据块验证通过
BBED> verify
DBVERIFY - Verification starting
FILE = /u01/oracle/oradata/ora11g/users01.dbf
BLOCK = 175
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

重启数据库

SQL> shutdown abort
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area  313860096 bytes
Fixed Size                  1344652 bytes
Variable Size             251661172 bytes
Database Buffers           54525952 bytes
Redo Buffers                6328320 bytes
Database mounted.
Database opened.
--找回更新前值
SQL> select * from chf.t_xifenfei;
        ID NAME
---------- ----------
         1 XFF
         2 CHF