LMS进程产生超大trace日志分析

点击上方蓝字关注我们

大家好！最近一套Oracle12C的生产库LMS进程产生超大trace日志，本文就这个问题做下分析介绍。

      先普及下LMS进程：

LMS：GlobalCache Service Process，LMS进程会维护在GlobalResource Directory (GRD)中的数据文件以及每个cachedblock的状态。LMS用于在RAC的实例间进行message以及数据块的传输。LMS是CacheFusion的一个重要部分。LMS进程可以说是RAC上最活跃的后台进程，会消耗较多的CPU。一般每个实例会有多个LMS进程，每个Oracle版本的默认的LMS进程数目会有所不同。

问题是这样的，在trace目录，LMS进程的trace日志很大，导致目录告警。

查看其trace内容如下：

在LMStrace日志中除了包含gesmsg buffers交互时间较长的信息和MQL:MQLNAME INVALID ENDIANNESS这段关键词之外。没有发现更多有用的信息。于是在MOS上根据MQLNAME INVALID ENDIANNESS搜了一把，找到Bug28808314 - 'mql:mql name invalid endianness' messages flooding lmstraces (Doc ID 28808314.8)，并发现有单独的小补丁。

在打完补丁之后，确认问题解决。

注：Bug28808314影响版本：12.2.0.1-19.8，但其修复已经包含在2020年7月份的DBRU中，打了7月份的DBRU或之后更新的DBRU，均无需担心触发该BUG了啦。

END