遠端協助解決重建索引的危機問題

   最近在工作忙碌之餘也幫幾位網友檢視了幾個問題，有一個問題讓我印象挺深，其實也可以分享出來作為一些參考，問題之外還是有一些值得借鑑的地方。
首先是在週末的一個晚上，白天已經比較累了，大概在晚上11點左右，就準備收拾收拾睡覺了，但是突然qq閃動起來，有一個網友發訊息給我，在反覆問我，在不在不？看起來還挺著急。
於是我就帶著試探的口吻來問他，他說剛剛做了一個操作，系統現在的負載很高，想讓我幫忙看看。
然後他就在qq那頭給我焦急的解釋，當時聽了的大體感覺是他建立了一個索引，但是執行了19分鐘還沒有反應，現在的系統負載很高，希望我能夠給點意見。
當我問系統負載有多高的時候，看到的截圖如下：

通過這個看不到系統負載很高，所以我就想他要了最新的ash,awr報告，因為他手頭剛好收集了ash報告，所以就直接發給我了。
top等待事件為：

Event	% Event	P1 Value, P2 Value, P3 Value	% Activity	Parameter 1	Parameter 2	Parameter 3
resmgr:cpu quantum	67.19	"3","0","0"	53.69	location
		"2","0","0"	13.33
direct path read	13.54	"15","115072","128"	0.02	file number	first dba	block cnt
read by other session	2.06	"15","481314","1"	0.06	file#	block#	class#
db file sequential read	1.11	"2","114340","1"	0.00	file#	block#	blocks

對於第一個等待事件還真比較陌生，不過ash報告的好處是這些資訊得來都不費功夫。top1的sql已經很清楚的說明了這些等待事件的歸屬。

SQL ID	Planhash	Sampled # of Executions	% Activity	Event	% Event	Top Row Source	% RwSrc	SQL Text
fjyagwts516j8	1886057869	204	75.71	resmgr:cpu quantum	55.01	TABLE ACCESS - FULL	55.01	select o.TRX_AMT as tradeAmoun...
				direct path read	12.03	TABLE ACCESS - FULL	12.03
				CPU + Wait for CPU	8.64	TABLE ACCESS - FULL	8.64

    所以這個問題看起來是由於全表掃描導致的。檢視了執行計劃，我問他對於這個表的全表掃描，其實可以考慮新增索引來緩解。
他說剛試過了，就是重建了索引，等了19分鐘沒反應，所以就取消了。
等等，他說的是重建，而不是新建，經過確認，他說是重建索引，相關的一個表是分割槽表，之前是存在全域性索引，後來想改用本地索引，但是刪除快，要新增就難了。
而他在等待了19分鐘之後還沒有任何反應就有些慌了，不知道該怎麼辦，這是一個線上環境，情況還是比較緊急的。
這個時候我已經不打算早點休息了，於是就準備遠端協助，看看更多的問題資訊，方便診斷。
這是一套11gR2的rac環境，簡單檢視了一些系統情況，發現CPU使用率到到了90%以上，iowait都在30%以上，已經是一個比較嚴重的情況了，而且檢視session的使用情況，發現裡面竟然有400多個active的session，而大部分的session都在同一條語句上卡住了，就是剛剛看到的sql(sql_id fjyagwts516j8),隊友這種情況，一種比較省事的辦法就是停掉前端應用，馬上建立索引來緩解，檢視有些sql語句，執行時間竟然已經達到了1個半小時，而後面還有一大堆的session被阻塞，這個時候來看，情況確實也比較危急，而且rac環境中，兩個階段的iowait都極高，如此下去，很可能導致嚴重的IO問題，後果不堪設想。
     我讓他提供了準備的指令碼，把需要執行的建立語句發給我，簡單評估一下，然後就是嘗試重建索引了。
當然這類操作，其實還是有一些技巧可循，本來想嘗試index的online，但是發現裡面都是大量的讀請求，本身使用online還是有一些限制，在正常的情況下建立，發現持續時間要高很多，而這些資訊都可以完全通過v$session中繫結對應的sql_id來得到一些資訊，如果不加並行，整體的索引建立時間預估是1個小時40分鐘，這個效率顯然是不可接受的，現在每耽誤一些時間，系統的負載和出現故障的概率就會高一些。所以看到了相關的執行計劃，還是不能接受，於是簡單整理一下思緒，強制開啟了會話級的並行ddl，配合查到的執行計劃，根據預估需要14分鐘，但是我明顯感覺會晚一些，因為目前的系統資源還是比較緊俏，所以預估時間可能要長一些，比如20分鐘到30分鐘的樣子。
在得到了這類資訊之後，就開始密切關注v$session中的資料變化情況，並行程式確實得到了啟用，而且檢視執行的情況還是在計劃之中，到了14分鐘，我安慰他說，目前系統的資源使用率較高，會有適當的延遲，應該會很快完成，需要等待一下。
      又過了近10分鐘，這個操作才終於順利的完成了，我心裡終於鬆了一口氣，看看錶，已經用了近半個小時的時間看問題，看來還是有一些收穫。
馬上檢視v$session中的資訊，發現那些持久執行的會話依然存在，對於這種情況和這位網友確認，他還不敢去強制停應用，或者殺掉那些會話，不過從新進入的sql情況可以看出，效能確實是得到了改善，所以我也就安慰他，這個問題已經告一段落，剩下的事情就是等待哪些被卡住的語句順利執行完了，因為系統負載降低了不少，所以這個過程相對要快一些了。
在簡單交代之後就去休息了，在第二天早上向他確認問題情況，他說現在一切都正常了，哪些活躍的會話連線都得到了釋放。
    對於這個問題，其實如果明白了其中的原委，可以看出其實處理方式還是很肯定的，需要藉助索引來大幅度改善效能，但是建立索引還是最好評估一下，如果沒有任何的參考，那種大海里撈針的感覺著實不好受，無法評估這個操作的時長和影響範圍，在具體實施操作的時候就會心虛很多。但是一旦你明白了問題的邊界，就可以很快調整自己的焦躁狀態，哪些事情是緊急的需要馬上處理，哪些是可能的問題原因需要重點關注，這些準備工作和操作都會一目瞭然。而對於這個問題的更多啟示，就是不要低估任何風險，這位網友說當時看後臺也沒有多少的session於是就想修正一些索引的情況，沒想到畫蛇添足了。
   

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/23718752/viewspace-2088227/，如需轉載，請註明出處，否則將追究法律責任。