下午的時候收到這麼一條報警。 ZABBIX-監控系統: ------------------------------------ 報警內容: Too many parallel sessions on xxxxx_xx機房_xxxxx ------------------------------------ 報警級別: PROBLEM ------------------------------------ 監控專案: parallel_session_cnt：66 ------------------------------------ 報警時間:2016.08.22-17:27:54 這個報警的意思是並行會話數達到了66個。已經遠超出了閾值。

在幾分鐘後我又收到了恢復的郵件，可見問題自動修復了。那這個問題該怎麼解釋呢。 如果通過AWR來定位很可能捕捉不到這個抖動，而且把AWR快照的收集頻度降低本身也不能完全解決問題，所以這個時候就需要藉助ASH了。 對於ASH生成報告而言，我對於裡面需要設定的時間格式深惡痛絕，所以在很早之前就做了簡單定製，手工輸入兩個時間戳，還可以靈活調整範圍，很快就定位到了一條語句。 可以看到在時間範圍內的SQL基本都是從Orabbix端觸發的，而這裡有一條語句引起了我的注意。

其它的語句都是查詢資料字典的資訊，而藍色部分標示的這條語句一看就是應用層面的。檢視執行計劃，馬上就明白了原委。

這條語句做了全表掃描，因為資料量巨大，所以執行效率低下，而且同時啟用了並行，所以相對來看執行效率還可以，但是由此可見系統層面的資源消耗會非常大。 所以問題又來了，為什麼全表掃描，啟用了並行，怎麼會有66個並行會話。看這個語句似乎也沒有什麼Hint的痕跡。 那麼這個問題的原因就更加容易定位了。 SQL> select degree,table_name from dba_tables where table_name='TEST_VIP_NEW' and owner='TEST’; DEGREE TABLE_NAME -------------------- ------------------------------ 32 TEST_VIP_NEW

可以通過這個配置看出並行度為32，所以問題的原因就馬上可以定位出來了。現在的問題是這個語句存在效能問題，一方面會導致大量的資源耗費，二來執行時間也相對比較長，為什麼這個大的表執行效率會如此差呢，問題的方向應該在於索引，排除了其它的因素，發現這個表的資料千萬級，存在幾個索引，但是唯獨這個語句where條件中的欄位不存在相關的索引，而這個問題可以進一步分析和檢視，其實就是根據rank=0,grade=0來得到結果集，從執行計劃可以看出這個結果集非常大，其實就算是得到了對應CN列值，本身處理起來也是一個很龐大的工程。所以這個語句從應用層面來看也是存在問題。而另外一個就是並行度，這個表的並行度有些太高，可以適當做一個調整，同時結合起來和開發同學做進一步的確認。我想這個問題在監控體系之內應該是不會報警了。