一次ORA-03113引起的思考

一次ORA-03113引起的思考[@more@]

一次ORA-03113引起的思考
近期客戶報表系統頻繁發生ORA-03113錯誤，收到訊息後，遠端支援。
由於是突發性的，所以詢問了使用者在事發前，系統有沒有什麼改動,使用者表示沒有。
透過分析應用日誌，發現引發該錯誤的99%都和a表查詢相關，另外1%是和b表相關的查詢，對照17613.1-ORA-03113 on Unix - What Information to Collect，這屬於突發性特定查詢引起的，於是自然的想到，可能是該表的索引可能出了問題，根據現有資訊，確認該表不是分割槽表。於是讓客戶手工在SQL*PLUS裡測試這兩個表的查詢，測試語句是直接從應用日誌摘出的引發錯誤的語句，但結果卻出乎意料-全部正常。
於是讓使用者手工啟動報表輸出，成功了。
看來資料庫是正常的，還是跟當時的系統狀況有關。於是問事發之時，系統資源是否正常，網路是否正常-已告知客戶該錯誤屬於網路通訊問題。客戶表示，事發時沒有監控系統資源，網路經過ping，沒有問題-沒有丟包，反應也很快。
於是於是讓使用者提供資料庫日誌alert listener sqlnet udump下日誌資訊，沒有獲得有效資訊。
陷入迷茫。。。，由於遠端支援，很多事情沒法做。
晚上，使用者還要跑報表，到時跟下吧，希望能過去。
然而，結果比想象的還要糟糕-控制檯直接報報表伺服器響應失敗，接收反應失敗。
於是讓客戶查網路，客戶告知網路OK。也被告知這步已經被跳過去了，待會手工做。
真的暈了。。。
晚些時候，收到使用者訊息，發現這個問題跟新上的交換機有關。
我暈。。。
但回過頭看這個問題，其實有很多線索可查的。
1、問系統有沒有什麼改動的時候，在問題可能與網路有關的時候，應該附帶一些提示：比方有沒有換過網路卡網線交換機路由器之類的，有沒有插拔過相關的網線。這時，應該可以得到更換交換機這個重要線索了。
2、分析應用日誌時，沒有進一步分析相關查詢之間的共性，這兩個查詢返回的資料量都應該很大，而且報表是批次出的，這時交換機流量也應該很大的。這時如果用大包去ping對應主機，可能會發現網路其實並不是那麼好。
3、使用者反應網路OK的時候，如果自己對網路關注更多的情況下，應該會問怎麼測的，然後讓使用者用大包去測，也可能發現問題。
4、自己水平有限，想不到的線索，，

思考整個處理過程，
1、溝通的能力，這裡可能說是些技巧跟確切，怎麼樣誘導對方，充分調動對方的思維，以便對方提供更多跟有效的資訊，是很重要的。
2、資訊處理能力，加工原始資訊，從大量原始資訊中，抽取挖掘資訊的能力，資訊時代、、、
3、專業知識，不說了，能力再強，在真正面對問題的時候，也很難彌補專業知識和經驗不足的問題，所以專業知識的學習和實踐鍛鍊，沒有任何介面去推掉他們。
4、處理問題的時候，靠的綜合能力，綜合能力不是句空話，他是真真切切存在的，木桶效應其實也有另一面的，當整個桶都很淺的時候，可能更多的是看他的負面效應，可是反過來看，木桶的“成長”總是要些部分先長長的，我們也要看到先變長部分的積極效應。處理問題的時候，充分發揮自己的優勢，從自己比較擅長的角度出發，事情往往更容易解決。
5、但到達一定高度的時候，世界的各個角落看起來都是一樣的。。。別把自己的思維禁錮在一個層面上，其實對其他層面的理解愈多，也會增加對自己所處的層面的理解的。這裡的層面既包含水面層面，也包括縱向分割。大家都知道，馬克思在是個哲學家，其實他在數學，物理，天文，經濟等等很多方面都很不錯的，所以，套用以前老師的一句話，真正的強者其實在各個方面都很強，幹什麼事情都能幹好。或許我們不能變的強到那種地步，但是我們應該看到這點，至少也要有個自己的領域吧，在這個領域相關的方面，任何問題都能處理，當然這裡的領域不是說廣袤的科學領域，只是一個小小自己的“空間”。
很多人喜歡偵探故事吧，我們處理資料庫問題其實不也是在偵查在破案吧，down機不就是命案嗎，對於這種案件，想想警察是怎麼處理的，保護現場，調查現場，取證，尋找目擊者，口供，當事人的各種關係，近期狀況，綜合資訊，判斷案件性質，嫌疑犯，審訊，處理。。。
對於slow不就是傷害事件嗎，這時，怎麼做。。。
當然相通的是隻是方法，其實花就是花，水就是水，事物原本就是那樣，不同的只是我們的“心”，從更高層看，我們的“心”本來就是這樣的，，世界本來就是世界的樣子，我們看到的世界，是我們的世界，也只是我們的世界，這不是唯心論，而是客觀存在，因為本來就是這樣子的。。。
扯遠了。。。
方法不是萬能的，因為方法只是方法，不能代替別的存在，如果存在上帝的話，可能對他而已，方法根本就不存在，因為他根本不需要，不受任何限制的創造者，但真的能擺脫任何限制嗎，其實自身的存在就是最大的限制啊，哎讓人抓頭的問題。。。
方法是要需要一塊基石的，，這個基石既是它存在的基礎，也是它發展的基礎。有可能一個方法發展到最後，轟然倒塌。。。

回到資料庫吧，3113，這個最常見的問題，卻是最麻煩的問題，因為源頭太多，路太多，，而最麻煩的問題，其實解決起來往往是最簡單的，因為有跡可循，，真正的問題是“莫名其妙”問題，問題都不明白的，怎麼去消滅呢，消滅問題最大的問題是找到問題，

儘管事務循著辯證法的軌跡發展--在我們的“心情”中--是那麼的繁雜，前進，跳躍，輪迴，消失，重生。。。，然而橫向切割的話，其實卻是那麼的簡單--其實它就是那樣子的，它本來就是那樣的。。。