SMON对于Undo(Rollback)segment的日常管理还不止于OFFLINE UNDO SEGMENT ,在AUM(automatic undo management或称SMU)模式下SMON还定期地收缩Shrink Rollback/undo segment。
触发场景
这种AUM下rollback/undo segment的undo extents被shrink的现象可能被多种条件触发:
若smon shrink rollback/undo真的发生时,会这样处理:
计算平均的undo retention大小,按照下列公式:
retention size=(undo_retention * undo_rate)/(#online_transaction_table_segment 在线回滚段的个数)
对于每一个undo segment
注意SMON的定期Shrink,每12个小时才发生一次,具体发生时可以参考SMON进程的TRACE。
若系统中存在大事务,则rollback/undo segment可能扩展到很大的尺寸;视乎事务的大小,则undo tablespace上的undo/rollback segment会呈现出不规则的空间占用分布。
SMON的定期清理undo/rollback segment就是要像一个大锤敲击钢铁那样,把这些大小不规则的online segment清理成大小统一的回滚段,以便今后使用。
当然这种定期的shrink也可能造成一些阻碍,毕竟在shrink过程中会将undo segment header锁住,则事务极低概率可能遇到ORA-1551错误:
[oracle@vmac1 ~]$ oerr ora 1551 01551, 00000, "extended rollback segment, pinned blocks released" // *Cause: Doing recursive extent of rollback segment, trapped internally // by the system // *Action: None
如何禁止SMON SHRINK UNDO SEGMENT?
可以通过设置诊断事件event=’10512 trace name context forever, level 1’来禁用SMON OFFLINE UNDO SEGS;
SQL> select * from global_name; GLOBAL_NAME -------------------------------------------------------------------------------- SQL> alter system set events '10512 trace name context forever,level 1'; System altered.
相关BUG
这些BUG主要集中在9.2.0.8之前,10.2.0.3以后几乎绝迹了:
Bug 1955307 – SMON may self-deadlock (ORA-60) shrinking a rollback segment in SMU mode [ID 1955307.8]
Bug 3476871 : SMON ORA-60 ORA-474 ORA-601 AND DATABASE CRASHED
Bug 5902053 : SMON WAITING ON ‘UNDO SEGMENT TX SLOT’ HANGS DATABASE
Bug 6084112 : INSTANCE SLOW SHOW SEVERAL LONGTIME RUNNING WAIT EVENTS
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/22990797/viewspace-2128781/ ,如需转载,请注明出处,否则将追究法律责任。