数据库版本：10.2.0.3
数据库架构：双节点RAC
主机平台：IBM小型机，AIX5.3
这次问题解决过程确认辽宁目前存在2个问题，记录如下：
第一，数据库实例异常重启。第二，数据库异常重启后造成的整个数据库进行DML操作异常缓慢，直接导致“抽数”时间大幅延长。
经过深入分析，这2个问题的原因和解决方案如下：
一、数据库实例异常重启
1、根本原因
观察jcfx1实例的alert日志发现在18号数据库jcfx1实例自动重启前，发生如下事件，
Mon Oct 18 11:02:06 2010
Errors in file /app/oracle/admin/jcfx/bdump/jcfx1_smon_753802.trc:
ORA-00600: internal error code, arguments: [15709], [29], [1], [], [], [], [], []
ORA-30319: Message 30319 not found; product=RDBMS; facility=ORA
SMON: terminating instance due to error 474
Mon Oct 18 11:02:06 2010
System state dump is made for local instance
System State dumped to trace file /app/oracle/admin/jcfx/bdump/jcfx1_diag_1699996.trc
Mon Oct 18 11:02:07 2010
Shutting down instance (abort)
即先抛出ora-600事件，然后传递给SMON进程，由SMON进程将实例强制关闭。由于是RAC环境，为了保证高可用性，Oracle clusterware的底层服务又将实例jcfx1启动。给用户的感觉就是数据库实例突然异常重启，其实是jcfx1实例由于600事件自己crash掉了，后又被CRS服务强制启动的结果。为什么会发生这样的问题呢？为什么会出现ora-600事件？根本原因是Oracle的一个未被发布的Bug在做怪，这个Bug平时不被触发，只有当数据库在处理“long transaction”并大量用到Undo段的时候才有可能被触发（而且也不是每次都触发），这个未被发布的Bug的Bug号是“6954722”。
2、解决方案
要想数据库实例以后不会再因为Bug6954722触发600事件而重启，有如下3种解决办法，一个是临时救急，另两个是根本解决。临时救急的方法是修改初始化参数“fast_start_parallel_rollback”为“false”，修改“recovery_parallelism”为0。注意，由于只是临时解决方法，并没有根本消除bug，不能保证完全不出现，只能保证出现次数会显著降低，故建议只是短期使用，临时救急。另两个方法，根本解决，一个是打一个“one-off”类型的patch，patch号也是“6954722”；另一个是升级Oracle软件至10.2.0.5。
二、数据库运行缓慢，抽数时间大大延长
1、根本原因
这个问题是发生在数据库实例异常宕机并重新启动之后，是属于“数据库异常重启”事件的衍生结果。实例启动以后，整个数据库好像换了个样子，无精打采，除了查询干什么都慢，这是为什么呢？我再看数据库实例启动后的alert日志，如下：
Transaction recovery: lock conflict caught and ignored
Transaction recovery: lock conflict caught and ignored
Transaction recovery: lock conflict caught and ignored
Transaction recovery: lock conflict caught and ignored
Transaction recovery: lock conflict caught and ignored
Transaction recovery: lock conflict caught and ignored
............
这说明数据库启动后做的各种操作（比如抽数）时不时得在等待其它事务rollback，这些rollback的事务一般来说都是异常中断或者被手工rollback，结合本次案例，显然是由于数据库实例异常重启造成，当时数据库正在进行抽数，有很多大事务正在进行。同时，辽宁的DBA龚工也在现场连接数据库查询动态性能视图V$FAST_START_TRANSACTIONS也发现有3个事务正在rollback，而且需要rollback的量极大，其中一个事务通过查询X$表进行估算竟需要rollback到第15天才能完成。龚工在现场发现的这3个事务也从另一个角度佐证了“数据库运行缓慢”事件的原因。这些正在rollback的事务因为一些锁没有释放，一些事务等待rollback完成，导致很多语句执行效率低，从而阻塞了其它会话。
2、解决方案
这些事务如果无法全部rollback，就有可能会造成数据库不一致。所以，除非使用备份恢复，否则唯一的方法就是加快SMON进程对这些事务进行rollback的速度，让它尽快rollback完毕。
如果数据库允许手工重启，可以采用如下方案提高SMON进程进行rollback的速度：
第一，待数据库空闲时，将除数据库后台进程外的各种进程全部杀掉，并关闭数据。
第二，修改初始化参数fast_start_parallel_rollback为false，修改隐藏参数“_cleanup_rollback_entries”为400或者给一个更大的值。
第三，关闭监听。
第四，启动数据库。
第五，等待。
第六，观察“V$FAST_START_TRANSACTIONS”查看rollback进度，直到事务rollback完毕。
以上方法可以加快SMON进程对事务rollback的速度。
说明：（1）如果数据库不得不执行DML操作且事务依然还没有rollback完毕，也可以先启动监听，一边执行DML操作，一边进行事务rollback，这时事务rollback速度会受到一定程度的影响，DML操作也不快，它相互影响对方的执行速度。（查询业务不会相互影响，任何时候都可以执行查询操作）
（2）如果有时间、有精力，可以现场测试一下数据库开启并行rollback后的速度，如果测试发现并行rollback比上述方法更快，可以将隐藏参数“_cleanup_rollback_entries”从参数文件去掉并修改fast_start_parallel_rollback为high，然后重启数据库来开启“并行回滚”功能。
数据库在进行实例恢复的时候，有时候时间会很长，可以修改fast_start_mttr_target 为一个限定值如:300
SQL>startup nomount;
SQL> alter system set fast_start_mttr_target =300
SQL> alter database mount;
SQL>alter database open;
可以缩短实例恢复的时间，让实例先OPEN，剩下的工作放在后台继续做。