oracle查询undo表空间使用率,Oracle 11gR2 Database UNDO表空间使用率居高不下

最新推荐文章于 2024-05-20 07:45:00 发布

继小驹

最新推荐文章于 2024-05-20 07:45:00 发布

阅读量975

点赞数

文章标签： oracle查询undo表空间使用率

本文介绍了在Oracle 11.2.0.3.0数据库中遇到的UNDO表空间使用率高达98%的问题。客户发现即使扩展了UNDO表空间，数据仍未被释放。分析表明，Oracle自动调整的TUNED_UNDORETENTION参数导致数据长时间保留。解决方案包括设置数据文件为自动扩展，调整_smu_debug_mode参数或禁用_undo_autotune。采用这些方法后，问题得到解决，空间得到释放。

摘要由CSDN通过智能技术生成

客户的数据库是Oracle Database 11.2.0.3.0 for AIX 6.1 64bit的单机数据库。客户查询DBA_FREE_SPACE发现UNDO表空间的使用率高达98%以上。客户的UNDO表空间已经手动扩展到了25GB，且一直在增加，为了UNDO表空间能及时的被释放，UNDO表空间对应的所有数据文件自动扩展都被关闭。查询DBA_UNDO_EXTENTS发现在UNDO表空间中当前没有ACTIVE的EXTENT存在，UNEXPIRED的占到总空间的60%，有30%是EXPIRED，但Oracle并没有及时的释放这些空间。

客户的UNDO表空间并没有设置成GUARANTEE模式，所以根据我们的知识都明白UNDO表空间中的EXPIRED和UNEXPIRED都是可能被重用的，但是这么高的UNDO表空间使用率看着让人不踏实。

虽然我们在初始化参数中设置了UNDO_RETENTION等参数，但从Oracle 10gR2开始，默认Oracle都开启了UNDO表空间的自动调整功能，查找V$UNDOSTAT.TUNED_UNDORETENTION发现最近一段时间该值都被自动调整到了3500多分钟，也就是说UNDO表空间中的数据要保留接近3天才会过期，正是因为这么长的数据未过期时间，且表空间又足够的大，才导致了UNDO表空间的空间一致未被释放，同时也找到了Oracle下面的一段解释：

Why TUNED_UNDORETENTION is calculated so high making undo space grow fast ?

When non-autoextensible undo space is used, tuned_undoretention is

calculated based on a percentage of the undo tablespace size. In some

cases especially with large undo tablespace, This will make it to be

calculated so large.

To fix this behaviour, Set the following instance parameter:

_smu_debug_mode=33554432

With this setting, TUNED_UNDORETENTION is not calculated based on a

percentage of the fixed size undo tablespace. Instead it is set to the

maximum of (MAXQUERYLEN secs + 300) and UNDO_RETENTION.

简单的说，就是当UNDO表空间对应的数据文件非自动扩展，且UNDO表空间又比较大的时候，tuned_undoretention的值是根据UNDO表空间大小的百分比来计算的，在一些情况下会将tuned_undoretention的值调整得特别大。

解决办法，如果设置_smu_debug_mode=33554432，那么Oracle的UNDO RETENTION自动调整功能依然被开启&