日志分析是分析数据库故障的重要手段，记得三十多年前刚刚开始学Oracle的时候，前辈告诫我做数据库运维，遇到故障，ALERT LOG永远是第一个要关注的要素。这么多年的实践也证明了，没有遵循这个原则的时候往往会吃苦头。有一次遇到一个十分棘手的问题，STATSPACK报告也分析了、各种指标、TOP SQL也看了，没有发现问题。折腾了半天，快绝望的时候突然想起了看看alert log。一看吓了一跳，数据库不断的在报ORA-00600[kcbgtcr_1]，每分钟写出几个GB的日志。这种故障以前遇到过几次，一下子就明白咋回事了。

在数据库国产化时代，我有点蒙圈了。各种数据库的日志文件各异，格式也五花八门，因为对数据库的原理知之甚少，因此看起来如看天书。这些数据库日志的唯一的相似点就是看着让人蒙圈。有些数据库系统都慢得快挂了，各种日志文件里干净得很，找不到可以让人参考的信息。有些数据库则是没事都每个小时几百个MB的日志信息，好像写日志对性能没任何影响似的。最大的问题是日志虽然多，但是没有太多有用的东西，或者说让人看得有些费解，有点像我们程序没写好，忘了把一些调试信息删掉一样。

就看日志上头的问题，我也与许多国产数据库厂商的研发人员做过交流，他们回答的理由五花八门，不过有一点是相似的，那就是他们希望在日志里多输出一些信息，以便于故障时更为准确的定位。这个观点让我对国产数据库日志为什么如此杂乱有了一个初步的认知，那就是国产数据库的日志实际上包含了两部分内容：log和trace。大家可能知道，可观测性的三大来源是metric、log和trace。有些朋友可能会混淆log和trace，把这二者混淆起来。Log是记录事件的，让运维人员知道某些信息、告警、错误在某个时刻发生了,一般情况下，log可以只包含事件发生时的一些关键数据和信息，但是不包含事件的详情，比如详细的堆栈，内存，消息信息等。而Trace是一种更为详细记录事件或者告警的机制，可以用于细致分析和调试跟踪，因此Trace一般记录了某个事件或者故障的详细追踪信息，可以用于故障分析或者BUG定位。

在大多数数据库中并没有明确的将log和trace区分开来，而是统一输出到日志里的。这样就让我们在查看日志的时候感到十分困惑。在上面的日志中，我们看到一些unkwon的告警，但是我们无法对这些告警展开分析，因为缺乏trace的信息，按理说在数据库处于生产运行的时候，对于diag/info类的信息可以不记录日志，只记录一些十分关键的Info类信息，比如日志切换，检查点发生等。而对于ERROR/FATAL/UNKOWN的错误，则要做详细一些的记录，比较严重的不能忽略的，要记录trace信息，这样才便于跟踪与定位问题，或者用于售后服务人员分析问题。

但是我们是不是愿意看到这样的日志文件呢?密密麻麻都是trace信息。有心人可以一眼就看出这是Oceanbase的日志文件，为了便于跟踪与定位问题，oceanbase数据库在各类server的日志中记录了大量的这样的信息。实际上这些内容应该属于trace信息，对于原厂的运维人员定位与分析问题十分有用，但是对于甲方或者第三方的DBA来说，不亚于看天书一样。

为此，Oceanbase的小伙伴还开发了一款用于OB日志分析的工具-obdiag，借助obdiag，DBA终于可以部分看懂这些天书了。

国产数据库的日志最大的问题是没有仔细区分log和trace,并且没有把写log和trace的尺度掌握好。其实这方面我们已经有了一个很好的老师-Oracle。

Oracle很好的解决了我上面所说的国产数据库日志的问题，日志和trace是完全分离的。Alert log是日志，而trace则是*.trc。在alert log中十分干净整洁地按照时间顺序记录了相关的事件。如果某个事件产生了trace文件，则记录下trace文件的文件名。根据alert log我们可以十分清晰的看到在某个事件区间里发生了什么。如果我们要了解某个事件的详细信息，则去trace里查看就可以了 。

比如在1月23号发生的某个事件需要做process state dump，我们没必要把这个几十MB的TRACE都写入alert log，而是放在一个独立的事件trace里就可以了。如果我们的国产数据库的日志都这样有条理，是不是对运维和原厂的售后服务很有帮助呢?