ITPub博客

首页 > Linux操作系统 > Linux操作系统 > oracle的死事务

oracle的死事务

原创 Linux操作系统 作者:zhouly1861 时间:2009-05-11 09:41:10 0 删除 编辑

http://space.itpub.net/9134/viewspace-567209

这两个月遇到两次死事务的问题,都是同事对一张表做了一个大的事务,然后pc机掉电了,在oracle后台把相应的进程kill掉问题就产生了,smon在做死事务清理,会有进程在等待事务恢复完成,其余一些进程会出现enqueue等待。

一般说来DBA没有什么办法,只能乖乖的等着smon清理完,可业务等不急,如此下来一堆人围着你心情巨不爽。

1、如何看还有多少个块需要恢复?

SELECT KTUXEUSN ROLLBACK_SEGS_NUM,
       KTUXESIZ UNDO_BLOCKS,
       KTUXESLT,
       KTUXESQN, /* Transaction ID */
       KTUXESTA STATUS,
       KTUXECFL FLAGS
  FROM SYS.X$KTUXE
 WHERE KTUXESTA != 'INACTIVE'

2、如何算一下需要多少时间恢复完?

可以看一下eygle的文章:http://www.eygle.com/archives/2007/09/smon_rollback_dead_transaction.html

3、碰到这样的问题DBA能做什么?

 最好让应用或业务人员能在业务、程序流程中把相应的表给跳过去,如果能停业务及重启库的话那样更好,没有业务的情部下速度是很快的。

4、并行回滚与串行回滚的选择

有人说并行快,有人说串行快,其实不用争,改一下参数观察一下就明了了

改成串行的:alter system set fast_start_parallel_rollback=false;
改成并行的:alter system set fast_start_parallel_rollback=HIGH;
其默认值是:LOW

5、DBA还能做的一件事

DBA可以暂时关闭smon的事务清理,等到营业结束,如17:00后再打开,这样可以不影响到业务。

关闭smon清理:
SVRMGR> oradebug setorapid
SVRMGR> oradebug event 10513 trace name context forever, level 2
打开smon清理:
SVRMGR> oradebug setorapid
SVRMGR> oradebug event 10513 trace name context off

需要说明的是命令可能会hang,原因在于你敲入命令的瞬间smon可能正在工作,control+c掉,多试几次就成功了.

6、其它

个人觉得也可以对有主键的表给它在线重定义掉,这样就不影响业务了,这个没测过,有精力的可以测一测,及时反馈给我。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/8797129/viewspace-594679/,如需转载,请注明出处,否则将追究法律责任。

下一篇: 新环境与DBA
请登录后发表评论 登录
全部评论

注册时间:2008-08-03

  • 博文量
    53
  • 访问量
    106646