由一个案例引出SMON的一个功能： Recover Dead transaction

该bug的现象：

1)  Deadlock

2)  Hang(Process Hang)

3)  Waits for "library cachelock"

4)  Waits for "row cachelock"

5)  Stack is likely to includedtbdrp

该bug的解决方案是：

Disable and drop all the referentialintegrity constraints before dropping the child table.

 eg:

 alter table <child_table_name> disable constraint<constraint_name>;

 alter table <child_table_name> drop constraint<constraint_name>;

 drop table <child_table_name> cascade constraints purge;

实际上这个方案在朋友这不可取，所以Oracle 最后建议将数据库升级到11.2.0.3。 这个方案同样也不可取。因为这个变动太大了。

朋友的这个环境太复杂了，出现问题的表是一张簇表，表中有5亿的数据，又使用了同义词，关联太多。 这个表是一年前系统从9i升级到10g时迁移过来的。 测试的时候导过一次，后来drop掉了，又正式迁移了一次。

出现问题的时候，这个系统灵异的访问了原来在回收站里的表，这个也是后来通过10046 跟踪出来。最终他们的解决方案是把回收站里的表恢复出来，然后重新创建了同义词，系统就回复正常了。

    没有参与整个过程，因此无法具体描述，也是后来听朋友说起整个处理过程，了解了一个大概过程。 

通过这个案例引出我们SMON的一个重要功能：Recover Dead transaction。

二．SMON 的功能：Recover Dead transaction

2.1 Recover Dead transaction 说明

服务进程在提交事务(commit)前意外终止的话会形成死事务(dead transaction)，PMON进程负责轮询Oracle进程，找出这类意外终止的死进程(dead process)，通知SMON将与该dead process相关的dead transaction回滚清理，并且PMON还负责恢复dead process原本持有的锁和latch。

因此当我们kill掉一个正在运行的大事务，不管是用kill session（或者shutdown abort），数据库都可能被hang住，或者SMON进程会占用所有可用的CPU资源，用来roll back 中断的大事务，因为事务很大，可能会消耗大量的资源，从而影响数据库的性能。

这个时候不建议关闭数据库，因为这个时候执行shutdown immediate，也可能会hang住，所以最终只能用abort的方式来关闭数据库。这样不会降低SMON进程完成rollback的进度，反而会让情况更糟。

当SMON 进程执行rollback时，我们可以能在alert log里看到如下信息：

Waiting for smon to disable tx recovery

SMON: about to recover undo segment 12
SMON: mark undo segment 12 as available
SMON: about to recover undo segment 12
*** 2009-11-12 10:08:11.389
SMON: mark undo segment 12 as available

可以使用如下SQL 查看SMON进程处理事务recovery的进度：

SET LINESIZE 100

ALTER SESSIONSETNLS_DATE_FORMAT='DD-MON-YYYYHH24:MI:SS';

SELECT usn,

       state,

      undoblockstotal "Total",

      undoblocksdone "Done",

      undoblockstotal - undoblocksdone"ToDo",

       DECODE(

         cputime,

          0, 'unknown',

            SYSDATE

          +(  (  (undoblockstotal-undoblocksdone)

               / (undoblocksdone/cputime))

             /86400))

          "Estimatedtime to complete"

  FROMv$fast_start_transactions;

在有些版本里，cputime 参数值不正常，一直为0，因此不能估算进度。

在某些案例中，v$fast_start_transactions视图也不能正常显示，不过还可以查询oracle 内部的数据字典：x$ktuxe。 该字典代表rollback 需要剩余的undo blocks的数量。

SELECT ktuxeusn,

       TO_CHAR(SYSDATE,'DD-MON-YYYYHH24:MI:SS') "Time",

      ktuxesiz,

      ktuxesta

  FROMx$ktuxe

 WHEREktuxecfl = 'DEAD';

2.2 FAST_START_PARALLEL_ROLLBACK 参数说明

fast_start_parallel_rollback参数可以提高SMON 进程进行回滚的并行度。将该参数设置为false那么并行回滚将被禁用，若设置为Low(默认值)那么会以2*CPU_COUNT数目的并行度回滚，当设置为High则4*CPU_COUNT数目的回滚进程将参与进来。

官网的说明如下：

FAST_START_PARALLEL_ROLLBACK specifies thedegree of parallelism used when recovering terminated transactions.

Terminated transactions are transactionsthat are active before a system failure. If a system fails when there areuncommitted parallel DML or DDL transactions,thenyou can speed up transaction recovery during startup byusing this parameter.

Values:

FALSE： Parallelrollback is disabled

LOW： Limitsthe maximum degree of parallelism to 2 * CPU_COUNT

HIGH： Limitsthe maximum degree of parallelism to 4 * CPU_COUNT

Note:

If you change the value of this parameter, thentransaction recovery will be stopped andrestarted with the new implied degree of parallelism.

关于该参数具体的使用案例可以参考惜分飞的blog：

FAST_START_PARALLEL_ROLLBACK与回滚恢复

http://www.xifenfei.com/2534.html

当fast_start_parallel_rollback= Low/High，即启用并行回滚时，可能会出现并行进程因为各种资源互相阻塞导致回滚工作停滞，如果遇到这种情况，可以将该参数设置为FALSE。一般可以保证恢复工作以串行形式在较长时间内完成。

版权所有，文章允许转载，但必须以链接方式注明源地址，否则追究法律责任!

QQ:492913789

Email:ahdba@qq.com

Blog:  http://www.cndba.cn/dave

Weibo:    http://weibo.com/tianlesoftware

Twitter:  http://twitter.com/tianlesoftware

Facebook: http://www.facebook.com/tianlesoftware

Linkedin: http://cn.linkedin.com/in/tianlesoftware