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

  

一．故障说明

前段时间一朋友遇到的案例，根据他的描述，我小整理了一下。

数据库环境：AIX + ORACLE 10.2.0.5， 单机。

朋友说一个大事务不能完成回滚操作,系统异常。 查看等待事件，如下图：

 

这里的row cache lock 较为严重。 row cache lock 对应的cache#=11，对应的child latch是dc_object_ids。

如何获取这个child latch可以参考如下blog：

latch row cache objects 等待事件及 child latch对象 说明

http://blog.csdn.net/tianlesoftware/article/details/6537227

 

Trace 文件出现大量的: waitfor stopper event to be increased。

 

这个wait forstopper event to be increased的等待事件是SMON进程的event，也就是说我们的SMON 进程在这个时候出现了异常。

    SMON 进程有一个非常重要的功能，就是Recover Dead transaction。

使用如下SQL 查看了一下Recover的进度：

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;

返回结果如下：

 

粗略的看一下，需要5个月的时间。 开了一个国际玩笑。

刚拿到数据，以为是如下文档里说的现象：

Database Appearsto Hang Waits for "Wait for a undo record" and "Wait for stopperevent to be increased" Due to Parallel Transaction Recover [ID 464246.1]

MOS的现象有3种：

1)  Database appears to hang

2)  Undo tablespace is growing.

3)  Systemstate dump shows thesignificant waits are for "Wait for a undo record" and "Wait forstopper event to be increased".

和朋友确认了一下，数据库没有hang住，UNDO 表空间分配了96G，使用了86%。也正常。所以排除了这个方法。

在[ID 464246.1]中，MOS提供的解决方法是：

fast_start_parallel_rollback= false

参考如下MOS文档：

Database Hangs Because SMON Is Taking 100% CPUDoing Transaction Recovery [ID 414242.1]

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

尝试设置fast_start_parallel_rollback=High，提高SMON的回滚速度，测试的实际结果是没有变化。

后来Oracle 原厂说是bug：

Bug 11693365 - Concurrent Droptable and Select on Reference constraint table hangs (deadlock) [ID 11693365.8]

该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。一般可以保证恢复工作以串行形式在较长时间内完成。

---------------------------------------------------------------------------------------

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

Skype:    tianlesoftware

QQ:       tianlesoftware@gmail.com

Email:    tianlesoftware@gmail.com

Blog:     http://blog.csdn.net/tianlesoftware

Weibo:    http://weibo.com/tianlesoftware

Twitter:  http://twitter.com/tianlesoftware

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

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