数据库关闭的诊断案例一则

在一个客户案例中，客户尝试关闭数据库启动归档模式，但是发现通过immediate方式无法关闭数据库，只能abort关闭，但是再次重新启动数据库之后，发现仍然无法正常关闭数据库，还是只能abort关闭，但是abort关闭数据库之后，下次启动需要执行数据库的实例恢复（Instance Recovery），无法启用归档模式。

诊断这个问题，首先在会话级别启用10046跟踪，然后执行shutdown 操作，示范如下：

[eygle@hpserver2 ~]$ sqlplus / as sysdba
SQL*Plus: Release 10.2.0.5.0 - Production on Fri Jun 15 17:24:23 2012
Copyright (c) 1982, 2010, Oracle.  All Rights Reserved.
SQL> alter session set events '10046 trace name context forever,level 12';
 
Session altered.
 
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.

分析生成的跟踪文件，即可进行数据库关闭相关的分析。如下内容是在客户案例中生成的跟踪文件，跟踪文件显示，在immediate过程中，数据库以instance state change等待事件处于循环等待。该事件含义为：等待实例状态改变，此处是等待实例由Open变更为Close。这个等待只说明当前状况，造成等待的原因来自之前的SQL：

我们注意DELETE语句对SYS用户的mon_mods$表进行操作，该表的创建语句如下，可以看出其作用是为了记录对于数据库对象的修改操作，包括增（INSERT）删（DELETE）改（UPDATE）的次数：

create table mon_mods$
(
  obj#              number,                                 /* object number */
  inserts           number,  /* approx. number of inserts since last analyze */
  updates           number,  /* approx. number of updates since last analyze */
  deletes           number,  /* approx. number of deletes since last analyze */
  timestamp         date,     /* timestamp of last time this row was changed */
  flags             number,                                         /* flags */
                                           /* 0x01 object has been truncated */
  drop_segments     number   /* number of segemnt in part/subpartition table */
)
  storage (initial 200K next 100k maxextents unlimited pctincrease 0)
/

数据库关闭时需要执行的DELETE操作,目的是将那些OBJ$不存在的对象内容删除（可能有些对象被DROP掉），由于早期版本中，NOT IN操作的执行计划走了全表扫描，导致该操作可能极其缓慢。

在这个案例中，有两个选择，一是手工删除这些记录，或者多等一段时间，数据库完成这个删除操作之后，自然就可以正常关闭了。这个问题作为BUG，在Oracle 9i之后的版本中已经被修正。