最近某客戶現(xiàn)場(chǎng)一套12C的RAC在一天內(nèi)出現(xiàn)多次librarycache lock,cursor:pinSwait on X,enq:TX-rowlock contention異常等待事件,通過介入針對(duì)數(shù)據(jù)庫(kù)會(huì)話進(jìn)行kill后,數(shù)據(jù)庫(kù)等待事件恢復(fù)正常。
詳細(xì)分析過程如下:
一、通過查看故障時(shí)間點(diǎn)awr報(bào)告存在sql頻繁解析失敗,導(dǎo)致大量硬解析
節(jié)點(diǎn)2,15:00-16:00,awr報(bào)告sql解析和硬解析占用大量db_time 節(jié)點(diǎn)2,18:00-19:00,awr報(bào)告sql解析和硬解析占用大量db_time 節(jié)點(diǎn)2,22:00-22:53,awr報(bào)告sql解析和硬解析占用大量db_time 故障時(shí)間點(diǎn)ash報(bào)告中存在未執(zhí)行成功sql 節(jié)點(diǎn)2,22:15-22:20存在未執(zhí)行成功sql |
二、通過檢查節(jié)點(diǎn)1,2都發(fā)生過sharepool抖動(dòng),另外從故障時(shí)間點(diǎn)(22:00-22:53)采集節(jié)點(diǎn)2的ADDM報(bào)告可以看出主要集中在SharedPool Latches的競(jìng)爭(zhēng)。
節(jié)點(diǎn)1:share pool自動(dòng)調(diào)整 節(jié)點(diǎn)2:share pool自動(dòng)調(diào)整 另外從故障時(shí)間點(diǎn)(22:00-22:53)采集節(jié)點(diǎn)2的ADDM報(bào)告可以看出主要集中在Shared Pool Latches的競(jìng)爭(zhēng)。 |
三、在故障發(fā)生過程中,發(fā)現(xiàn)系統(tǒng)存在自動(dòng)任務(wù)調(diào)起的情況(自動(dòng)統(tǒng)計(jì)信息收集,自動(dòng)分段顧問),因?yàn)樽詣?dòng)統(tǒng)計(jì)信息收集發(fā)起導(dǎo)致cursor失效,sql需要重新解析,這也是故障原因之一。
檢查發(fā)現(xiàn)目前數(shù)據(jù)庫(kù)已開啟如下自動(dòng)任務(wù)如下: 任務(wù)說(shuō)明: 1、自動(dòng)優(yōu)化器統(tǒng)計(jì)收集:為所有方案對(duì)象收集陳舊的或缺少的統(tǒng)計(jì)數(shù)據(jù),所收集的統(tǒng)計(jì)信息將被用來(lái)提高SQL的執(zhí)行的性能,任務(wù)名是"autooptimizer stats collection" 2、自動(dòng)分段顧問:標(biāo)識(shí)數(shù)據(jù)庫(kù)中的段是否有可以回收的空間,并以此信息統(tǒng)計(jì)為基礎(chǔ)做出怎樣整理段的碎片以節(jié)約空間。也可以手動(dòng)的執(zhí)行此job來(lái)獲取最新的建議信息,或者獲取自動(dòng)段advisor 不檢測(cè)的但又可以回收的段的信息,任務(wù)名是"auto space advisor" 3、自動(dòng)SQL調(diào)整顧問:自動(dòng)標(biāo)識(shí)并嘗試調(diào)整高負(fù)載的SQL,任務(wù)名是"sqltuning advisor"。 4、ORACLE_OCM用戶主要是用于Oracle配置管理器,當(dāng)發(fā)出SR請(qǐng)求時(shí),它和數(shù)據(jù)庫(kù)實(shí)例配置相聯(lián)系,把配置信息發(fā)送給Oracle供分析。 通過檢查故障時(shí)間點(diǎn)前后范圍ash報(bào)告,在故障前22:05:00-22:15:00,(故障發(fā)生時(shí)間為22:16分),自動(dòng)優(yōu)化器統(tǒng)計(jì)收集和自動(dòng)分段顧問都自動(dòng)調(diào)度起來(lái)。 |
數(shù)據(jù)庫(kù)在開啟10035后發(fā)現(xiàn)后臺(tái)有未執(zhí)行成功的SQL。
啟用10035事件
Altersystem set events 10035 trace name context forever,level 1;
關(guān)閉10035事件
Altersystem set events 10035 trace name context off;
注:
開啟10035事件抓取解析失敗sql不能作為日常項(xiàng)來(lái)開展,此類sql均是因?yàn)閟ql語(yǔ)法錯(cuò)誤,訪問對(duì)象不存在或字段缺失等原因?qū)е拢?/span>
應(yīng)用應(yīng)該上線前應(yīng)該做好評(píng)審把控,做好功能測(cè)試(這類報(bào)錯(cuò)往往功能測(cè)試都是通不過的),將此類問題sql控制在源頭,扎好上線的口袋;
長(zhǎng)期開啟10035事件有以下兩點(diǎn)不利因素:
1、數(shù)據(jù)庫(kù)開啟10035并不是一種日常維護(hù)手段。
2、10035事件會(huì)將解析失敗的語(yǔ)句信息寫入數(shù)據(jù)庫(kù)alert,易造成錯(cuò)誤信息刷屏,增加了數(shù)據(jù)庫(kù)目錄撐爆的風(fēng)險(xiǎn),以及日常巡檢維護(hù)難度。
總結(jié):
首先是應(yīng)用發(fā)起的SQL解析失敗及硬解析導(dǎo)致cursor。然后統(tǒng)計(jì)信息收集導(dǎo)致部分cursor失效,從而加重了SQL解析壓力。sharedpool本來(lái)剩余空間就有點(diǎn)不足了,所以壓力一來(lái)就會(huì)grow,但是在dbcache空間不能及時(shí)釋放出來(lái)的,sharedpool grow失敗的情況下,更加加重了sharedpool閂鎖的競(jìng)爭(zhēng)。
建議如下:
1、協(xié)助應(yīng)用整改未執(zhí)行成功sql。
2、目前數(shù)據(jù)庫(kù)兩個(gè)節(jié)點(diǎn)sharepool頻繁調(diào)整,將sharepool size 從10G調(diào)整至15G。
alter system set shared_pool_size=15G scope=spfile; |
3、關(guān)閉autospace advisor,sqltuningadvisor(已關(guān)閉理賠庫(kù)該參數(shù))和oracle_ocm相關(guān)job及調(diào)整autooptimizerstats collection調(diào)度時(shí)間。
文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://specialneedsforspecialkids.com/yun/130061.html
Oracle數(shù)據(jù)庫(kù)4031故障分析 img{ display:block; margin:0 auto !important; width:100%; } body{ width:75%; m...
摘要:命令行方式獲取顯示當(dāng)前的用戶操作。類似于的可以監(jiān)控所有慢的以及不慢的查詢。以及其他第三方鏈接性能調(diào)優(yōu)場(chǎng)景現(xiàn)實(shí)的首頁(yè)我們希望現(xiàn)實(shí)最近發(fā)布的條。自動(dòng)刪除舊文檔為了給新文檔創(chuàng)建空間,在集合中自動(dòng)刪除老舊的文檔,不需要執(zhí)行額外的腳本和操作。 轉(zhuǎn)載請(qǐng)注明出處 http://www.paraller.com 原文排版地址 http://www.paraller.com/2016/10/22/m...
摘要:清楚了以上流程,我們直接來(lái)看函數(shù)主要用作初始化應(yīng)用監(jiān)聽端口以及啟動(dòng)。其中就是保存聊天室所有聊天消息的結(jié)構(gòu)。關(guān)于的解讀我會(huì)放到閱讀源碼時(shí)講。然后把消息加到緩存里,如果緩存大于限制則取最新的條消息。 tornado 源碼自帶了豐富的 demo ,這篇文章主要分析 demo 中的聊天室應(yīng)用: chatdemo 首先看 chatdemo 的目錄結(jié)構(gòu): ├── chatdemo.py ├── ...
閱讀 1346·2023-01-11 13:20
閱讀 1684·2023-01-11 13:20
閱讀 1132·2023-01-11 13:20
閱讀 1858·2023-01-11 13:20
閱讀 4100·2023-01-11 13:20
閱讀 2704·2023-01-11 13:20
閱讀 1385·2023-01-11 13:20
閱讀 3597·2023-01-11 13:20