十多年前，ORA-1555是一个十分经典的面试问题，超过60%的面试官都会像求职者提出这个问题。在10年前老白的《Oracle DBA 优化日记》中，也深入的讨论了这个问题。传统的对ORA-1555的看法是从快照过旧这个错误上引申开来的，重点还是关注UNDO空间，回滚段，UNDO_RETENTION，以及QUERY DURATION等因素，考虑从SQL优化，增加UNDO，优化RBS等角度去解决问题。随着存储设备越来越廉价，UNDO 不足的问题已经不存在了，我们也不需要像运行ORACLE 8i/9i时候一样，为UNDO用20G好还是40g好去犯愁，一个几百GB的UNDO也是很容易获得的。最近这几年里，大家对ORA-1555这个错误已经不大关注了，因为大家也发现绝大多数这个错误是因为不够优化的SQL引起的，甚至很多企业的日志报警系统里，为了避免过多的报错，把ORA-1555列在了排除列表里。前年，在我们开始开发日志深度分析工具的时候，ORA-1555这个经典的问题当然是不会错过的，于是老白的团队按照日志深度分析的架构重新梳理了这个经典错误号。这一梳理不要紧，老白发现以前对ORA-1555的认知完全是不足的。实际上ORA-1555错误并不全是因为快照过旧引起的，经过初步分析，我们至少可以把ORA-1555错误分为6大类：

第一类是UNDO与回滚段相关的；第二类是SQL执行计划由于表分析数据不准等原因出现错误导致执行效率过低；第三类是开发商编写的SQL质量太低；第四类是Bug 22241601导致的索引逻辑损坏，遇到这种情况，需要重建索引解决；第五类是Bug 8231583 导致的错误，必须重建UNDO表空间来解决；第六类是应用程序写LOB字段出现问题，主要原因是LOB字段初始化代码存在问题，需要开发商修改应用解决。大家也看出来了，不同的类别的错误，其处置方法是不一样的，我们以前面对这个错误的时候只看到了其中的一面，而没有看到其全貌。经过继续梳理，我们发现ORA-1555错误的情况实际上更为复杂。

这张思维导图也仅仅是列出了ORA-1555的常见情况，并没有覆盖所有的可能问题。从这里我们也看出，日志的分析实际上是一个十分复杂的工作。以前遇到一些未知的或者导致严重后果的错误的时候，我们往往会请专家来协助分析或者到MOS上去查找相关的资料。这种效率十分低下。通过日志深度分析工具来解决问题，可以帮我们解决一大部分的问题，当分析工具无法从已知诊断路径中发现问题的时候，会被记录下来，后续就需要专家介入，对此类未知问题进行分析，并优化诊断路径。在这种复杂的分析场景中，目前十分热的AI技术并没有办法发挥更大的作用，靠数据和算法无法解决深度推理的问题，这个也已经是业内的常识了。工具不能解决所有的问题，只有工具+人的生态才能不断演进和积累知识，使工具越来越强大(我这里不敢说越来越智能，目前阶段，运维工具的智能大多数还是来自于专家智能，而不是数据智能)。对日志问题的诊断路径进行分类后，后续就可以提供更为强大的功能了。

针对某个日志报错，自动分析工具可以生成分析报告，在报告中可以帮你列出和该日志报错相关的后续诊断建议，以及已知的优化处置建议。似乎这一切很完美，不过还有一个问题，这些诊断路径不是从天上掉下来的，需要大量的技术团队去做分析与整理，这个工作必须是人工的，而且严重依赖于专家。能做这种工作的专家是稀缺资源，另外一点，很多这方面的专家并不愿意把自己脑子里的东西拿出来做成工具，和大家分享。于是这个工作想要大规模的推广开来还是存在难度的。要解决这个问题，还是要走互联网+的路子，建立一个更为广泛的技术江湖，一方面有更多的用户通过技术江湖结成联盟，他们系统中发现的一些未被深度分析的错误信息能够贡献出来，把相关的错误信息与日志文件提交到社区，由社区的虚拟专家团队去进行分析与处理，最终形成分析工具下发到社区成员。经过不断的积累，日志分析知识点工具的积累会良性发展，这个工具也能够越来越强大了。老白希望这样的技术社区能够早点建立起来，届时，老白的团队也十分愿意成为社区的用户和知识贡献者。