點擊上方藍字關(guān)注我們
大家好!最近一套Oracle12C的生產(chǎn)庫LMS進程產(chǎn)生超大trace日志,本文就這個問題做下分析介紹。
環(huán)境介紹: 操作系統(tǒng):AIX 數(shù)據(jù)庫版本:12CR2 是否RAC:是 |
先普及下LMS進程:
LMS:GlobalCache Service Process,LMS進程會維護在GlobalResource Directory (GRD)中的數(shù)據(jù)文件以及每個cachedblock的狀態(tài)。LMS用于在RAC的實例間進行message以及數(shù)據(jù)塊的傳輸。LMS是CacheFusion的一個重要部分。LMS進程可以說是RAC上最活躍的后臺進程,會消耗較多的CPU。一般每個實例會有多個LMS進程,每個Oracle版本的默認的LMS進程數(shù)目會有所不同。
問題是這樣的,在trace目錄,LMS進程的trace日志很大,導(dǎo)致目錄告警。
查看其trace內(nèi)容如下:
在LMStrace日志中除了包含gesmsg buffers交互時間較長的信息和MQL:MQLNAME INVALID ENDIANNESS這段關(guān)鍵詞之外。沒有發(fā)現(xiàn)更多有用的信息。于是在MOS上根據(jù)MQLNAME INVALID ENDIANNESS搜了一把,找到Bug28808314 - mql:mql name invalid endianness messages flooding lmstraces (Doc ID 28808314.8),并發(fā)現(xiàn)有多帶帶的小補丁。
在打完補丁之后,確認問題解決。
注:Bug28808314影響版本:12.2.0.1-19.8,但其修復(fù)已經(jīng)包含在2020年7月份的DBRU中,打了7月份的DBRU或之后更新的DBRU,均無需擔(dān)心觸發(fā)該BUG了啦。
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://systransis.cn/yun/130033.html
摘要:需要對每個用戶的每個內(nèi)容對象維護一個數(shù)據(jù)結(jié)構(gòu)。并沒有直接和相連,所以是將數(shù)據(jù)由暫存的內(nèi)存中取出。采用實現(xiàn)的可用進行數(shù)據(jù)提交。記錄的完成情況,包括未嘗試未學(xué)習(xí)未完成,已完成。 簡介 SCORM定義了一個網(wǎng)絡(luò)化學(xué)習(xí)的內(nèi)容聚合模型(Content Aggregaion Model)和學(xué)習(xí)對象的實時運行環(huán)境(Run-time Environment)。簡單說,它是為了滿足對網(wǎng)絡(luò)化學(xué)習(xí)內(nèi)容的高水...
摘要:相對的在性能優(yōu)化方面,相當(dāng)于將的功能集成到了中。手機連接電腦后運行應(yīng)用,在中會看到以下視圖左上角可以選擇設(shè)備和進程,點擊區(qū)域,即可進入視圖左上角可以選擇跟蹤模式按默認采樣率捕獲應(yīng)用的調(diào)用堆棧。 前言 性能優(yōu)化的過程分兩部分: 發(fā)現(xiàn)性能瓶頸 制定方案,解決性能問題 解決性能問題的方案需要具體情況具體分析,并沒有完全固定的路子,更多的是靠經(jīng)驗的積累,本文不做涉及。但是發(fā)現(xiàn)性能瓶頸確實有著固...
閱讀 1356·2023-01-11 13:20
閱讀 1707·2023-01-11 13:20
閱讀 1215·2023-01-11 13:20
閱讀 1906·2023-01-11 13:20
閱讀 4165·2023-01-11 13:20
閱讀 2757·2023-01-11 13:20
閱讀 1402·2023-01-11 13:20
閱讀 3671·2023-01-11 13:20