DBA工作隨想：MBA和PHD的重要性

    其實這篇文章，說講述的跟DBA沒有太大的關係，但是    我寫出來，希望對DBA有所幫助。
上個月一博士客戶的某重要業務，出現2小時故障，事情鬧得很大。故障發生在一個簡單的INSERT語句上面，不幸的時執行那個SQL時總是報ORA-600[kcbget_24]這樣的錯誤，其實導致事務一直失敗。不過幸運的是，那個INSERT語句所要完成的業務功能只是整個業務環節中的可選功能，開發商也有開關來控制是否啟動這個可選功能。雖然這個ORA-600錯誤，不能很快查到原因，但是卻可以通過設置那個業務功能的開關來繞過這個問題。當時是我在現場處理的這個問題，從接到問題報告到解決問題，只花了很短的時間。那為什麼整個故障歷時了2小時。其主要原因在於，這個客戶沒有有效的監控手段，來監控錯誤，完全靠業務人員的反映，而業務人員又不能很快地發現問題。
事後檢查錯誤出現的原因，發現是INSERT語句時，維護一個索引出現了索引，在做索引節點塊分裂時報了ORA-600[kcbget_24]錯誤。ORA-600錯誤基本上是由BUG或資料損壞引起的，但BUG引起的可能性更大。那為什麼之前好好的，怎麼突然就出現錯誤了，再進一步追查發現出現問題的索引是新建的索引，而建這個索引的，是開發商的一個開發人員，未經過流程，就直接在表上建了。結果索引一建好，就出現問題了。
這裏我想說的是，做DBA工作，不能有任何僥倖心理。這次發生的事故，是ORACLE的BUG引起，但是如果之前有過充分的測試，按流程來操作，很可能就分避免了這個問題的產生。對一個複雜的系統的維護，技術或許比較重要，但是我認為，流程和測試更重要。
這件事也讓我想起2年前，我還在上一家單位(相對目前的工作性質來說是甲方)時，一個非常重要的業務系統，在一個非常重要的時間，崩潰了，完全不能用。這套系統本來還有一個月就功成身退，被新的業務系統所代替，結果最後一班崗也沒站好，潛伏的一個致命的BUG爆發了(不是資料庫軟體的BUG,是業務軟體的BUG)。頭一天晚上系統的BBA配置資料做了改動，按正常的流程是需要測試的，或許業務人員認為，配置的改動是常有的事，不需要測試，結果忽略了測試，結果第二天…..
工作中的某些環節，比如測試，是枯燥的，但是實在是不可或缺的。