Oracle Undo Tablespace 使用率暴涨案例分析
案例说明：
客户XXX数据库是4节点Oracle RAC架构,节点1监控undo tablespace使用率超过阈值告警，并且还在快速增长，经检查发现，一事务在对物化视图执行delete时，长时间未完成，导致undo表空间被占用，使用率快速增长。
数据库版本：12.1.2.0
一、查看undo空间使用率
通过以下脚本查看undo表空间使用率，发现undo tablespace存储空间在短时间内快速增长，使用率达到90%以上：
二、执行表空间扩容
如下所示，执行以下脚本对undo tablespace进行扩容，从100G扩容到200G，但undo tablespace的使用率仍在快速增长：
三、查看当前事务对undo段占用信息
如下所示，通过以下脚本查询当前事务占用undo段的信息，并获取事务对应的SQL_ID:
图1： 事务占用undo段信息
四、查看数据库告警日志
如下所示，在数据库的alert日志中出现ORA-01555故障：
图2： 告警日志信息
数据库undo_retention配置：
如下所示，数据库undo_retention为14400分钟，说明当前在undo中有大量expired的undo数据占用undo表空间
图3：undo retention配置信息
查看undo表空间使用信息：
如下所示，当前事务已经占用大量undo段空间（Active）：
图4：undo 段使用信息
五、获取SQL执行计划
如下所示，依据前面获取的事务对应的SQL_ID ，查询具体执行的sql文本：
六、查看SQL执行计划
如下所示，当前占用undo tablespace的事务是delete操作，执行对物化视图的删除操作
图5：事务所执行SQL执行计划信息
七、查看物化视图DDL语句
如下所示，delete语句涉及的物化视图有多张表的查询构建，现场测试目前物化视图的刷新效率非常低,长达几个小时：
图6： 物化视图定义信息
八、查看物化视图对应表的统计分析信息
如下所示，对物化视图对应的表，查询其统计分析结果，和实际的表记录的行数对比，判断是否是因为表统计分析有误，导致物化视图对应表的查询执行计划异常：
1、查看表统计分析结果
2、查看表实际记录行数
如下所示，对物化视图对应表，查看实际的表记录行数；对比表统计分析后结果和表实际记录行数（通过对比查看，统计分析结果和表实际记录行数没有大的差别，排除因为统计分析有误导致的执行计划异常的问题）：
图7： 表实际记录行数
九、根据告警异常信息查询MOS
如下截图所示，根据告警日志异常信息，查询MOS的相关处理建议：
图8：告警日志异常信息
图9： MOS建议解决方案
如上所示，Oracle建议对物化视图采用非原子性的方式执行refresh。
原子性刷新与非原子性刷新的区别（官方文档说明）
1）原子性刷新：
在原子性刷新中，整个物化视图的刷新过程被视为一个单一的操作。如果刷新过程中发生错误，Oracle会回滚整个操作，确保物化视图的数据状态保持一致。这种方式保证了数据的一致性和完整性。
2）非原子性刷新：
非原子性刷新允许在刷新过程中出现错误时只回滚部分数据更改。这意味着如果在刷新过程中某个部分失败，只有那部分会回滚，而其他成功刷新的部分则保留下来。这种方式可以提高性能，因为它减少了因单个错误导致的整个刷新操作的失败。
如何设置非原子性刷新
在Oracle中，可以通过DBMS_MVIEW包中的REFRESH过程来刷新物化视图，并通过指定method_opt参数来控制刷新的方式。对于非原子性刷新，你可以使用FAST或COMPLETE选项，但要注意的是，Oracle官方文档中并没有直接提及COMPLETE选项作为非原子性的明确标识。通常，使用FAST选项可以实现非原子性的快速刷新，而使用COMPLETE选项则会尝试进行更完整的刷新，但这不一定等同于非原子性（在某些情况下，COMPLETE也可以是原子性的）。
十、采用fast refresh方式重建物化视图
如下所示，重新定义后的物化视图的结构：
图10：物化视图定义
查看重新定义后物化视图刷新时间：
如下所示，物化视图最近的刷新时间为35分钟，恢复正常：
图11：物化视图刷新时间
十一、总结
本案例因为对物化视图执行delete操作导致的undo tablespace表空间使用率暴涨的问题，以重建物化视图解决，重建物化视图后，物化视图的刷新恢复正常，delete操作事务亦可以快速commit，事务的undo block不再长期占用undo tablespace。
对于物化视图刷新效率低，delete事务长期不能提交，还需要进一步分析其原因。