SMON这个老牌的后台关键进程的作用还包括对UNDO/ROLLBACK SEGMENT的维护， 这种维护主要体现在2个方面: OFFLINE和SHRINK UNDO/ROLLBACK SEGMENT， 今天我们主要介绍OFFLINE ROLLBACK SEGMENT。
你肯定要问，Oracle为什么OFFLINE UNDO/ROLLBACK SEGMENT?
最主要的目的是减轻高并发事务环境中对UDNO SPACE撤销空间使用的压力。
触发场景
在10g之前的9i中每12个小时SMON会根据V$UNDOSTAT中记录来决定在现有基础上要OFFLINE多少个UNDO SEGMENT，又要保留多少个UNDO SEGMENT； 在9i中被OFFLINED UNDO SEGMENT 还会被SMON DROP掉，以进一步回收空间。
具体保留多少个UNDO SEGMENT，取决于过去12个小时内的V$UNDOSTAT动态视图记录的最大并发事务数量在加上1，具体公式可以参考下面的SQL:
SQL> select max(MAXCONCURRENCY)+1 from v$undostat where begin_time> (sysdate-1/2); MAX(MAXCONCURRENCY)+1 --------------------- 4
若你在alert.log中发现类似以下的信息则说明OFFLINE UNDO SEGS已经在你的系统中发生过了:
SMON offlining US=13 Freeing IMU pool for usn 13 SMON offlining US=14 SMON offlining US=15 SMON offlining US=16 SMON offlining US=17
9i中SMON通过ktusmofd函数实现对UDNO SEGMENT的OFFLINE，ktusmofd的含义为[K]ernel [T]ransaction [U]ndo [S]ystem [M]anaged OFFLINE & DROP
通过ktsmgfru函数返回必要保留的ONLINE UNDO SEGMENT， 其详细的算法如下：
SMON调用ktusmofd ，并发现instance启动未超过12个小时并且_smu_debug_mode未设置KTU_DEBUG_SMU_SMON_SHRINK标志位
(_smu_debug_mode是SYSTEM MANAGED UNDO内部参数，KTU_DEBUG_SMU_SMON_SHRINK标志位控制是否强制SMON做SHRINK)
YES - SMON不OFFLINE任何东西直接返回
NO - 调用ktsmgfru 获得过去12小时的最大并发事务数
设置keep_online变量为ktsmgfru 返回值加上1
尝试hold TA ENQUEUE(该队列锁控制UNDO TABLESPACE的串行操作)，该操作的超时限制为30s
若无法获得该ENQUEUE则说明正在切换UNDO TABLESPACE，ktusmofd将直接返回且不OFFLINE任何UNDO SEGMENTS
成功获得该ENQUEUE锁，进一步调用ktusmofxu并使用之前获得的keep_online作为参数，开始OFFLINE
调用kslgpl函数获得KTU LATCH 包括parent和所有的children
LOOP 在现有的ONLINE UNDO SEGMENT之间循环
若发现该UNDO SEGMENT是SMU-SYSTEM MANAGED UNDO且其所在表空间是当前undo_tablespace指向的表空间的话
若keep_online >0 ， 则keep_online--
否则
释放KTU latches
调用kturof1函数实际OFFLINE 该UNDO SEGMENT
重新get KTU latches
END LOOP
释放 KTU latches
SMON 调用ktusmofd维护OFFLINE UNDO SEGMENT的常见STACK CALL如下：
ktmmon->ktusmofd->ktusmdxu->ktcrcm->ktccpcmt->ktcccdel->ktadrpc->ktssdro_segment-> ktssdrbm_segment->ktsxbmdelext->kqrcmt->ktsscu xctrol ktcpoptx ktccpcmt ktcrcm ktusmdxu ktusmofd ktmmon ksedmp ksfdmp kgeasnmierr ktusmgmct ktusmdxu ktusmofd ktmmon ksbrdp opirip opidrv sou2o main
10g以前的UNDO OFFLINE算法仍不完善，这导致在实例重启或切换UNDO TABLESPACE撤销表空间时，生成一定数量ONLINE UNDO SEGMENT的系统预热时间可能长达几分钟，对于高并发的环境来说这种延时是难以接受的。
从10g开始改进了SMON OFFLINE UNDO SEGMENT的算法，SMON会基于过去7天的(而非12个小时的)V$UNDOSTAT动态视图信息或者AWR自动负载仓库中的UNDO历史快照使用信息来决定OFFLINE UNDO SEGMENT的数量， 且在10g中SMON 不再DROP掉多余的UNDO SEGS，而仅仅OFFLINE掉；作为一种SMU的改良算法这种做法被叫做”Fast Ramp-Up”。”Fast Ramp-Up”避免了早期版本中由SMON维护UNDO SEGS引起的等待或性能问题; 此外，未公开的BUG 5079978可能在版本10.2.0.1中被触发，该BUG的信息如下:
Unpublished
Bug 5079978 – APPST GSI 10G : – PRODUCTION INSTANCE UNUSABLE DUE TO US ENQUEUE WAITS
is fixed in 11.1 and patch set 10.2.0.4 and interim patches are available for several earlier versions.
Please refer to Note 5079978.8
可以通过后面要介绍的 10511 event来规避以上bug，Oracle官方也推荐在10g以前的版本中使用 10511 event来避免SMON过度OFFLINE UNDO SEGS所引起的问题。
10g以后的具体算法如下：
判断实例启动是否超过7天？
YES - 直接使用v$undostat中过去7天的最大并发事务数max(maxconcurrency)
NO - 判断是否是第一次调用OFFLINE UNDO SEGMENT的内核函数
YES - 检查是否存在select_workload_repository function (SWRF)快照数据
NO - ONLINE 最小数目的UNDO SEGMENTS
YES - 尝试获取AWR记录表wrh$_undostat中过去7天的最大并发事务数max(maxconcurrency)
若无法获得以上值，则尝试读取wrh$_rollstat中最近7天的最大rollback segs数量max(rbs cnt)
将返回值保存到内部变量中
NO - 直接使用内部变量中的值
如何禁止SMON OFFLINE UNDO SEGMENT?
可以通过设置诊断事件event=’10511 trace name context forever, level 1′ 来禁用SMON OFFLINE UNDO SEGS; 但是10511事件不会跳过”Fast Ramp Up”，而仅会限制SMON对UNDO SEGS产生的工作负载。 一旦设置了10511 event， 则所有已生成的 UNDO SEGS会始终保持ONLINE状态。
具体的设置方法：
SQL> select * from v$version; BANNER ---------------------------------------------------------------- Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bi PL/SQL Release 10.2.0.5.0 - Production CORE 10.2.0.5.0 Production TNS for Linux: Version 10.2.0.5.0 - Production NLSRTL Version 10.2.0.5.0 - Production SQL> select * from global_name; GLOBAL_NAME -------------------------------------------------------------------------------- www.askmac.cn [oracle@vrh8 ~]$ oerr ora 10511 10511, 00000, "turn off SMON check to cleanup undo dictionary" // *Cause: // *Action: SQL> alter system set events '10511 trace name context forever,level 1'; System altered.
OFFLINE UNDO SEGS的相关BUG
以下列出了SMON OFFLINE UNDO SEGS的一些公开的BUG，这些BUG一般都存在于10.2.0.3之前; 若你真的遇到了，可以在考虑升级之余 采用10511 event workaround规避该问题：
Hdr: 2726601 9.2.0.2 RDBMS 9.2.0.2 TXN MGMT LOCAL PRODID-5 PORTID-46 ORA-600 3439552
Abstract: ORA-600 [4406] IN ROUTINE KTCRAB(); 4 NODE RAC CLUSTER
Hdr: 6878461 9.2.0.4.0 RDBMS 9.2.0.4.0 TXN MGMT LOCAL PRODID-5 PORTID-23 ORA-601 5079978
Abstract: ESSC: ORA-601 ORA-474 AFTER OFFLINING UNDO SEGMENTS
Hdr: 4253991 9.2.0.4.0 RDBMS 9.2.0.4.0 TXN MGMT LOCAL PRODID-5 PORTID-23 ORA-600 2660394
Abstract: ORA-600 [KTSXR_ADD-4] FOLLOWED BY ORA-600 [KTSISEGINFO1]
Hdr: 2696314 9.2.0.2.0 RDBMS 9.2.0.2.0 TXN MGMT LOCAL PRODID-5 PORTID-46
Abstract: RECEIVING ORA-600: [KTUSMGMCT-01] AFTER APPLYING 92020 PATCH SET
Hdr: 3578807 9.2.0.4 RDBMS 9.2.0.4 TXN MGMT LOCAL PRODID-5 PORTID-23 ORA-600
Abstract: OERI 4042 RAISED INTERMITTENTLY
Hdr: 2727303 9.2.0.1.0 RDBMS 9.2.0.1.0 TXN MGMT LOCAL PRODID-5 PORTID-100 ORA-600
Abstract: [RAC] ORA-600: [KTUSMGMCT-01] ARE OCCURED IN HIGH LOAD
Leave a Reply