love wife & love life —Roger的Oracle&MySQL技术博客

Phone:18180207355 提供专业Oracle&MySQL数据恢复、性能优化、迁移升级、紧急救援等服务

10g 中DEPENDENCY$被move 数据库无法open

本站文章除注明转载外,均为本站原创: 转载自love wife & love life —Roger的Oracle&MySQL技术博客

本文链接地址: 10g 中DEPENDENCY$被move 数据库无法open

51放假期间,同事问我一个问题,那就是dependency$被move后,数据库起不来了,虽然是测试环境。 他的环境是10204版本.
自己测试了,跟9i不太一样了,参考了dbsnake的文章,似乎差别很大。如下:

—-trace log

怪异,我这里居然10046没有打出该sql的执行计划.无所谓,我在另外一个10g的数据库跑下sql即可:

从上面我们可以知道,该sql需要访问其中的一个索引,而该为unusable,索引导致bootstrap$的时候就报错了,以至于无法open.

我在自己测试的时候,也参考了dbsnake的文章,他的操作就是通过bbed来讲索引I_DEPENDENCY1和I_DEPENDENCY2从ind$中
删掉,以至于该sql在执行的时候就不知道了,只能进行full table scan。 那么也就不会报错了。

根据他的思路,我也模拟了一下,但是后面发现不行,由于10.2版本都是一样的,所以我这里也通过另外一个10201环境来看下
index cluster 删除某条记录后,其实质变化如何:

—–创建测试范例

从上面可以看到,我的测试环境test_killdb1 的数据分别存放在8个block中。

我们的目的是要来观察下针对该表发生delete操作的变化情况:

注意,我们这里看到的row 有3行,第一行是聚簇键,第2行是非聚簇键. 大家可以发现一点,那就是聚簇键值的行头是0xac,
而非聚簇键的行头呢,是0x6c。我们知道我们普通的数据块行头都是0x2c,而这里是不同的.

我们将object_id=9的记录删除,然后再来观察下。该block的变化情况:

我们可以清楚的看到,curc的值不变,而comc的值减少了1.也就是等于block内的已commit实际数量条数.

我们此时仍然使用bbed来观察下该block的一些变化:

现在我们来简单总结下,关于index cluster的删除,其实就是将其所在的聚簇行头所记录的comc值减少了,同时
将该记录的行头有正常情况下的0x6c改成0x7c.
现在我们回到问题上来,我的目的是要从ind$里面将I_DEPENDENCY1 和I_DEPENDENCY2的记录删除掉,这样就可以让这2个sql
无法识别到这2个索引,也就不会报错了。

在10.2版本中,这2个index的object_id如下,且在ind$中对应的位置都是一样的:

知道了10gR2中index cluster删除记录的实质后,我们就可以利用bbed来进行操作了,如下是我的操作过程:

操作完成之后,尝试启动数据库:

此时数据库不停的报错:
Fri May 03 01:26:58 PDT 2013
Errors in file /home/ora10g/admin/roger/bdump/roger_smon_25401.trc:
ORA-00604: error occurred at recursive SQL level 1
ORA-01502: index ‘.’ or partition of such index is in unusable state
Fri May 03 01:27:08 PDT 2013

按理说这里应该是可以delete 进行相关对象的删除完毕,然后就可以重建这2个索引了,但是发现情况不是这样,或许是我这里
操作有些问题。当时报错后,后来我重启了一下,就起不来了,比较遗憾:

Fri May 03 03:07:30 PDT 2013
SMON: enabling cache recovery
Fri May 03 03:07:34 PDT 2013
Errors in file /home/ora10g/admin/roger/udump/roger_ora_28635.trc:
ORA-00600: internal error code, arguments: [kkdlusr1], [123], [], [], [], [], [], []
Fri May 03 03:07:36 PDT 2013
Errors in file /home/ora10g/admin/roger/udump/roger_ora_28635.trc:
ORA-00600: internal error code, arguments: [kkdlusr1], [123], [], [], [], [], [], []
Fri May 03 03:07:36 PDT 2013
Error 600 happened during db open, shutting down database
USER: terminating instance due to error 600
Instance terminated by USER, pid = 28635
ORA-1092 signalled during: alter database open..

经过多次方法尝试,都无法绕过这个[kkdlusr1] 错误,极度郁闷。

无奈之下,我建该库直接rm -rf删掉,利用上次的rman 备份重新恢复了一个,然后再次模拟,通过如下方式顺利解决了这个问题:

使用隐含参数_db_always_check_system_ts 直接打开数据库.

这里有几个地方需要注意:

1. drop index的实质就是操作几个数据字典表:obj$,icol$,seg$,ind$. 这一点,大家可以通过10046 event
去跟踪drop index的过程可以发现。

2. 上面关于删除seg$的记录,需要知道对象的段头,经过我检查发现,10gR2版本中段头block号都是一样的,所以
根本不需要通过其他工具去获取。

3. 数据字典维护操作完成之后,进行索引重建,仍然报错,需要将数据库重启一下,否则是不行的。

4. 重建这2个索引的脚本可以在$ORACLE_HOME/rdbms/admin/sql.bsq中找到.

 

补充:在11gR2版本中,这个发生变化了

[ora11g@11gR2test ~]$ sqlplus “/as sysdba”

SQL*Plus: Release 11.2.0.2.0 Production on Fri May 3 08:02:21 2013

Copyright (c) 1982, 2010, Oracle.  All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 – Production
With the Partitioning, Automatic Storage Management, OLAP, Data Mining
and Real Application Testing options

SQL> set lines 200
SQL> select owner,object_name,object_id from dba_objects where object_name=’DEPENDENCY$’;

OWNER                          OBJECT_NAME                     OBJECT_ID
—————————— —————————— ———-
SYS                            DEPENDENCY$                           104

SQL> select owner,index_name,index_type from dba_indexes
2  where table_name=’DEPENDENCY$’;

OWNER                          INDEX_NAME                     INDEX_TYPE
—————————— —————————— —————————
SYS                            I_DEPENDENCY2                  NORMAL
SYS                            I_DEPENDENCY1                  NORMAL

SQL> select owner,object_name,object_id from dba_objects where object_name like ‘%I_DEPENDENCY%’;

OWNER                          OBJECT_NAME                     OBJECT_ID
—————————— —————————— ———-
SYS                            I_DEPENDENCY1                         106
SYS                            I_DEPENDENCY2                         107
SQL> shutdown abort;
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Database mounted.
SQL> oradebug setmypid
Statement processed.
SQL> oradebug event 10046 trace name context forever,level 12
Statement processed.
SQL> alter database open;

Database altered.

SQL> oradebug close_trace
Statement processed.
SQL> oradebug tracefile_name
/home/ora11g/diag/rdbms/roger/roger/trace/roger_ora_25330.trc
SQL>
SQL>

通过分析trace文件,我发现在open的过程中,根本不涉及DEPENDENCY$相关的对象了,而且即使是索引失效了,smon也不会去检测了,如下:

SQL> alter table DEPENDENCY$ move;

Table altered.

SQL> col index_name for a30
SQL> col tablespace_name for a25
SQL> select owner,index_name,tablespace_name,status from dba_indexes where table_name=’DEPENDENCY$’;

OWNER                          INDEX_NAME                     TABLESPACE_NAME           STATUS
—————————— —————————— ————————- ——–
SYS                            I_DEPENDENCY2                  SYSTEM                    UNUSABLE
SYS                            I_DEPENDENCY1                  SYSTEM                    UNUSABLE

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

Total System Global Area  313860096 bytes
Fixed Size                  1343888 bytes
Variable Size             192941680 bytes
Database Buffers          113246208 bytes
Redo Buffers                6328320 bytes
Database mounted.
Database opened.
SQL>
SQL> select owner,index_name,tablespace_name,status from dba_indexes where table_name=’DEPENDENCY$’;

OWNER                          INDEX_NAME                     TABLESPACE_NAME           STATUS
—————————— —————————— ————————- ——–
SYS                            I_DEPENDENCY2                  SYSTEM                    UNUSABLE
SYS                            I_DEPENDENCY1                  SYSTEM                    UNUSABLE

SQL> alter index I_DEPENDENCY2 rebuild;

Index altered.

SQL> alter index I_DEPENDENCY1 rebuild;

Index altered.

换句话说,11gR2版本中这个表你可以随便move,哈哈~~~~    不过这个测试实际上没有什么价值,大家就当随便玩玩了。

5 Responses to “10g 中DEPENDENCY$被move 数据库无法open”

  1. 10g 中DEPENDENCY$被move 数据库无法open - iew3c Says:

    […] 详见原文博客链接地址:10g 中DEPENDENCY$被move 数据库无法open var jiathis_config={ data_track_clickback:true, summary:"", hideMore:false } 0 本文链接: 10g 中DEPENDENCY$被move 数据库无法open 版权所有: 非特殊声明均为本站原创文章,转载请注明出处:iew3c 订阅更新: 您可以通过RSS订阅我们的内容更新 […]

  2. tony Says:

    先看再顶,大神

  3. xifenfei Says:

    bbed 可以修改成功,你的应该是还有很多使用bbed 删除ind$的记录时候,还有一些块的验证部分没有修改完全,具体可以看看我的blog,详细的东西,就不说了,你懂的

  4. lizhenxu Says:

    发现一种不需要bbed的方法,很easy。

  5. 10g 中DEPENDENCY$被move 数据库无法open | love Oracle Says:

    […] 51放假期间,同事问我一个问题,那就是dependency$被move后,数据库起不来了,虽然是测试环境。 他的环境是10204版本. 自己测试了,跟9i不太一样了,参考了dbsnake的文章,似乎差别很大。如下: ? […]

Leave a Reply

You must be logged in to post a comment.