当然了，哲学中有句话是 存在即合理，可能在早期的时候数据量不大，处于某种需要，可能需要全表扫描，或者这部分逻辑是直接从某个地方参考而来，而其中的hint都忘了变更，导致了这样的问题。
出了问题，找问题的理由也是多种多样。当然最终这个问题还是发生了，能够及时发现修复才是更重要的。
对于这个问题的分析暂时告一段落，但是还有dml对于undo的影响也不容小视，可供参考的就是前面表格中的delete语句了。
对于这个语句，delete涉及的表也是很大的一个分区表，数据量亿级以上。在基于索引扫描的前提下，做了根据时间戳进行数据清理的操作。对于这种操作，我们可以反过来考虑一下，目前delete的逻辑是对的，在排除了ac1_control_hist全表扫描影响的前提下，delete操作还是会消耗大量的undo资源。这个时候也需要同时考虑目前的undo大小是否完全满足系统的要求。目前的库里undo的大小在17G左右，几个大分区表都在百G以上，如果删除所限定的时间戳大一些，undo的消耗就会更大，所以也需要考量undo的大小，根据目前的情况，可以考虑适当增大undo空间。
所以这个问题的分析结果就是两个建议，第一个就是对于本该索引扫描的语句走了全表扫描进行改进，规范hint的使用。另外一方面是建议适当调大undo的大小，以满足系统的需求，使得系统的负载更有张力。