黃金週裡處理了一起緊急的問題，在外面幸虧有同事幫忙協助，等我趕回家去，趕緊繼續處理。 首先問題是在晚飯時間左右開始發生，但是過了沒多久又恢復了，所以這個問題暫時就沒有引起太多關注，但是後面發現問題開始反覆，而且資料庫的負載開始急劇提升，後面也開始收到了不少的報警資訊，一下子問題就變得緊急起來。 環境是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

趕緊把例項啟動起來，因為有應用重連機制，所以問題的影響還在可控範圍，火速調整shared_pool的大小，重啟後，問題就得到了一定的緩解，當然問題的根本還是設計不當採用了大量的DB link的方式，把問題的影響放大。需要引以為戒。