資料庫無響應問題的緊急處理和分析
黃金週裡處理了一起緊急的問題,在外面幸虧有同事幫忙協助,等我趕回家去,趕緊繼續處理。
首先問題是在晚飯時間左右開始發生,但是過了沒多久又恢復了,所以這個問題暫時就沒有引起太多關注,但是後面發現問題開始反覆,而且資料庫的負載開始急劇提升,後面也開始收到了不少的報警資訊,一下子問題就變得緊急起來。
環境是10.2.0.3的資料庫,在Solaris 10環境中。
當時的DB time情況如下,從負載來看,壓力是非常大的,資料庫幾度出現了無響應的情況,這對於核心業務而言還是影響很大的。
這是一套很穩定的資料庫,很穩定的說法主要是很少有變更,而且多年來系統一直表現穩定。
檢視資源的使用情況如下,可以看到在問題發生時段,沒有大批量的事務,沒有大批量的資源消耗。
那看看等待事件,發現都是和鎖相關的。根據wait class的指示是和併發相關的。如果看到如此的情況,而且很緊急,想必是很糾結的。
我們來看看問題時間段的SQL情況,看看是否因為SQL問題導致了嚴重的等待和鎖爭用。
這個地方就有一些誤區,看SQL語句,預設會定位到top的幾個SQL語句,細看所佔的比例也蠻高,所以同事的注意力就集中在了SQL優化上,但是檢視語句是一個很簡單的查詢,而且也是走了唯一性索引,那問題的癥結在哪裡呢。
可以從awrsqrpt的報告看出端倪,那就是存在大量的等待。其實執行的時間還是很短的。
那問題的原因怎麼解釋,到底在等待什麼呢。這個需要對整個系統的架構和技術細節需要有一些瞭解。
首先現在的網路卡使用了邏輯IP,如下所示。伺服器存在兩個物理網路卡,現在對外使用的是一個網路卡1(e1000g0)上繫結的一個邏輯IP,當然這麼做也是有一些歷史原因的。
而對系統的架構有一定的瞭解,會發現其實和另外一個資料庫有一些關聯。怎麼解釋呢,就是在問題發生的時候,另外一臺資料庫的負載也急劇提升。
我直接到另外一臺伺服器上檢視發現存在大量的活躍會話,而在等待的就是下面的這樣一個語句。看起來也沒有什麼問題,如果檢視執行計劃就會發現其實另外一臺伺服器中是使用了DB link來訪問現在出問題的資料庫。
其實問題的原因也無須掉書袋,經過快速定位和分析,就是因為這樣的DB link,聽起來好像也不大合理,怎麼會有這樣的問題呢,問題伺服器上存在著大量的資料庫連線,會直接更新本地表,間接通過db link來引用其他的表,在業務穩定的時候沒有差別,在一定程度上和設定的邏輯IP有一些關係,網路一旦發生抖動和不穩定,就會把這個網路的延遲放大,傳播,大批量的會話開始阻塞,等待,就會變成活躍會話,資料庫負載急劇提升,如果應用端持續呼叫都存在等待,系統資源就會逐漸耗盡,導致出現無響應的情況,這種問題的解決方案目前是採用了折中的一個方案,既然通過db link,我們把一部分的網路壓力放在物理網路卡2上。在tnsnames.ora中修改對應的IP和埠即可。至少在一定程度上能夠極大緩解問題,後續會建議從應用層面,系統層面來持續改進。
當然處理問題的過程中,發現有大量的等待,首要的等待就是library cache的爭用,這個可以從下面的圖示看出。可以看到shared pool確實很緊張,而且同時buffer cache其實使用一點都不緊張,我們重置一下SGA的元件,這個地方需要提醒一下,在這種情況下需要評估影響範圍。
我印象中是存在一個bug,會導致例項直接宕掉,評估了之後決定先改進一下。alter system set shared_pool=xxx執行下去,例項還真宕掉了。
首先問題是在晚飯時間左右開始發生,但是過了沒多久又恢復了,所以這個問題暫時就沒有引起太多關注,但是後面發現問題開始反覆,而且資料庫的負載開始急劇提升,後面也開始收到了不少的報警資訊,一下子問題就變得緊急起來。
環境是10.2.0.3的資料庫,在Solaris 10環境中。
當時的DB time情況如下,從負載來看,壓力是非常大的,資料庫幾度出現了無響應的情況,這對於核心業務而言還是影響很大的。
這是一套很穩定的資料庫,很穩定的說法主要是很少有變更,而且多年來系統一直表現穩定。
檢視資源的使用情況如下,可以看到在問題發生時段,沒有大批量的事務,沒有大批量的資源消耗。
那看看等待事件,發現都是和鎖相關的。根據wait class的指示是和併發相關的。如果看到如此的情況,而且很緊急,想必是很糾結的。
我們來看看問題時間段的SQL情況,看看是否因為SQL問題導致了嚴重的等待和鎖爭用。
這個地方就有一些誤區,看SQL語句,預設會定位到top的幾個SQL語句,細看所佔的比例也蠻高,所以同事的注意力就集中在了SQL優化上,但是檢視語句是一個很簡單的查詢,而且也是走了唯一性索引,那問題的癥結在哪裡呢。
可以從awrsqrpt的報告看出端倪,那就是存在大量的等待。其實執行的時間還是很短的。
那問題的原因怎麼解釋,到底在等待什麼呢。這個需要對整個系統的架構和技術細節需要有一些瞭解。
首先現在的網路卡使用了邏輯IP,如下所示。伺服器存在兩個物理網路卡,現在對外使用的是一個網路卡1(e1000g0)上繫結的一個邏輯IP,當然這麼做也是有一些歷史原因的。
而對系統的架構有一定的瞭解,會發現其實和另外一個資料庫有一些關聯。怎麼解釋呢,就是在問題發生的時候,另外一臺資料庫的負載也急劇提升。
我直接到另外一臺伺服器上檢視發現存在大量的活躍會話,而在等待的就是下面的這樣一個語句。看起來也沒有什麼問題,如果檢視執行計劃就會發現其實另外一臺伺服器中是使用了DB link來訪問現在出問題的資料庫。
update enthralcert set logout_date = sysdate, status = 0 where cert_number in (select cert_number from enthralcn where cn = lower(:cn))
其實問題的原因也無須掉書袋,經過快速定位和分析,就是因為這樣的DB link,聽起來好像也不大合理,怎麼會有這樣的問題呢,問題伺服器上存在著大量的資料庫連線,會直接更新本地表,間接通過db link來引用其他的表,在業務穩定的時候沒有差別,在一定程度上和設定的邏輯IP有一些關係,網路一旦發生抖動和不穩定,就會把這個網路的延遲放大,傳播,大批量的會話開始阻塞,等待,就會變成活躍會話,資料庫負載急劇提升,如果應用端持續呼叫都存在等待,系統資源就會逐漸耗盡,導致出現無響應的情況,這種問題的解決方案目前是採用了折中的一個方案,既然通過db link,我們把一部分的網路壓力放在物理網路卡2上。在tnsnames.ora中修改對應的IP和埠即可。至少在一定程度上能夠極大緩解問題,後續會建議從應用層面,系統層面來持續改進。
當然處理問題的過程中,發現有大量的等待,首要的等待就是library cache的爭用,這個可以從下面的圖示看出。可以看到shared pool確實很緊張,而且同時buffer cache其實使用一點都不緊張,我們重置一下SGA的元件,這個地方需要提醒一下,在這種情況下需要評估影響範圍。
我印象中是存在一個bug,會導致例項直接宕掉,評估了之後決定先改進一下。alter system set shared_pool=xxx執行下去,例項還真宕掉了。
Errors
in file /U03/app/oracle/admin/test/bdump/test_mman_944.trc:
ORA-00600: internal error code, arguments: [kmgs_pre_process_request_6], [1],
[107], [18], [3], [0xA7024DB68], [], []
Mon Oct 3 22:45:17 2016
MMAN: terminating instance due to error 822
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/23718752/viewspace-2125850/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- Oracle日常問題處理-資料庫無法啟動Oracle資料庫
- 應用使用JNDI,資料庫無法連線,導致的程序無法啟動問題處理資料庫
- Oracle資料庫中的逐行處理問題NEOracle資料庫
- 應急響應:日誌分析
- Oracle優化案例-緊急處理一條sql引起cpu使用率99%的問題(十六)Oracle優化SQL
- 資料處理--pandas問題
- openGauss資料庫xlog目錄滿問題處理資料庫
- 如何處理Oracle資料庫中的壞塊問題(轉)Oracle資料庫
- 使用資料庫處理併發可能導致的問題資料庫
- python中多程式處理資料庫連線的問題Python資料庫
- 遇到緊急問題,不要慌:抓包分析來救你(一)
- 響應式關聯式資料庫處理R2DBC資料庫
- iview Tree資料格式問題,無限遞迴樹處理資料View遞迴
- 資料庫主機重啟卡住問題處理分享資料庫
- 資料泵expdp匯出遇到ORA-01555和ORA-22924問題的分析和處理
- openGauss資料庫分析問題資料庫
- 一次資料庫響應慢分析資料庫
- 時間緊急!資料庫遷移怎麼才能更快?資料庫
- Oracle資料庫處理壞塊問題常用命令Oracle資料庫
- 主庫千萬級的資料更新後,STANDBY日誌應用大量延遲的問題處理
- Kubernetes-應用部署問題定位和處理
- 資料庫索引分裂 問題分析資料庫索引
- 處理請求(AFURLRequestSerialization)和響應(AFURLResponseSerialization)
- X7一體機資料庫遷移問題處理資料庫
- 達夢資料庫日常管理之問題處理筆記1資料庫筆記
- 銀河麒麟系統安裝ORACLE資料庫問題處理Oracle資料庫
- 【應急響應】Windows應急響應入門手冊Windows
- Sql Server資料庫類似正規表示式的字元處理問題SQLServer資料庫字元
- JVM問題分析處理手冊JVM
- “企業應急響應和反滲透”之真實案例分析
- X86環境大記憶體下資料庫啟動問題分析與處理記憶體資料庫
- 大資料處理需留意哪些問題大資料
- 資料分析--資料預處理
- Dede呼叫資料庫失敗,無法實現資料處理資料庫
- Excel高階應用教程:資料處理與資料分析Excel
- ES同步Mysql資料庫(包括出現問題怎麼處理哦)MySql資料庫
- 什麼是應急響應?網路安全應急響應體系的要素!
- 乾貨丨RPA工程中的資料處理問題
- iOS和macOS應用程式本地資料庫金鑰處理設計iOSMac資料庫