Oracle数据库在面对UNDO表空间持续增长的问题时，通常涉及到一系列复杂的故障排查和修复步骤。在本案例中，问题源于一次存储阵列故障，导致数据库出现异常，使得UNDO表空间持续增长。UNDO表空间在Oracle数据库中主要用于回滚事务，确保数据一致性。当其异常增长，可能是由于未完成的事务、索引错误或系统进程异常等原因。
当遇到此类问题，首要任务是查看alert日志，以定位故障类型。在本例中，错误提示为ORA-08102和ORA-00600，这两个错误通常与索引不一致有关。为解决这个问题，需要对出现问题的索引进行重建，若索引无法重建，可能需要清空表（TRUNCATE）后再导入数据。
接着，当日志错误排除后，发现UNDO表空间仍在增长，通过v$transaction视图发现SMON进程（System Monitor进程）在长时间执行事务，消耗大量UNDO空间。尝试通过ALTER SESSION命令结束SMON会话无效，且考虑到数据库安全，避免直接在操作系统级别终止进程，以免引发更大问题，选择重启数据库。然而，即使数据库重启，SMON仍在进行死事务恢复，导致UNDO空间占用未减少。
进一步分析发现，SMON可能在恢复其在数据库关闭前的事务。锁定SMON的并行恢复（FAST_START_PARALLEL_ROLLBACK）无效，因为表SYS.smon_scn_time被锁住。此表用于记录SCN（System Change Number）到系统时间的映射，与UNDO表空间增长的时间一致。使用systemstate dump工具观察SMON尝试写入数据到该表，怀疑表的索引存在错误。
在锁定问题定位后，尝试通过设置事件12500暂时阻止SMON更新此表，然后分析并尝试重建索引，但由于表被锁定，重建失败。因此，决定删除表中的所有数据（TRUNCATE），之后解除阻止SMON更新的设置。随着数据库重启和一段时间的监控，发现UNDO表空间的增长停止，并在SMON完成死事务恢复后，空间缩小到正常水平。
此故障的解决过程表明，对于Oracle数据库的故障排查，应从日志分析开始，深入到系统视图和进程分析，甚至可能涉及索引重建和数据清理。在处理过程中，必须谨慎操作，以保证数据库的稳定性和数据的完整性。此外，定期维护和备份是防止类似问题的关键，同时，了解和熟悉Oracle数据库的内部机制，如SMON进程的作用和UNDO表空间管理，对快速定位和解决问题至关重要。
VIP享7折，此内容立减4.47元 
