曲折的dump匯入及問題分析(r5筆記第47天)
今天下午的時候得到反饋，說開發在匯入一個dump的時候報了錯誤，他們嘗試連線資料庫，發現連線都有問題，讓我們趕緊看看。
這是一個測試環境的庫，在伺服器上同時還跑著十多個資料庫不同應用的資料庫例項。
> sqlplus / as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Mon May 25 14:28:50 2015
Copyright (c) 1982, 2011, Oracle. All rights reserved.
ERROR:
ORA-09817: Write to audit file failed.
Linux-x86_64 Error: 28: No space left on device
Additional information: 12
ORA-01075: you are currently logged on
SQL> select count(*)from csm_ben;
COUNT(*)
----------
248
SQL> select count(*)from csm_account;
COUNT(*)
----------
0
這個時候看問題就比較明顯了，很顯然在外來鍵列所在的表csm_account中竟然沒有資料，為什麼會出現這種問題,我也懷疑是不是dump出問題了，而只是從開發提供的一個ORA錯誤還是所知甚少。需要更多的資訊來佐證。
我們可以直接嘗試把資料匯入csm_account，做一個嘗試，看看dump中是否丟失了這個表的資料。
imp xxxx/xxxx file=test_data.dmp statistics=none grants=n indexes=n ignore=Y buffer=9102000 tables=csm_account
結果就出錯了，發現是由於一個表中的欄位丟失造成的。
IMP-00058: ORACLE error 904 encountered
ORA-00904: "L9_xxxxxx_NO": invalid identifier
Import terminated successfully with warnings
問題真是層出不窮，而且解決問題的思路都是類似的，為什麼會出現這個問題，接下來改做些什麼，開發會這麼問我，我也會自問。
最後排查得知，這套環境的版本很低，和現有的生產環境的版本相去甚遠，所以這些額外的變更就不存在，這個時候就可以和開發確認，為什麼要選用這套很老的環境，最後他們確認後，找了一套版本比較新的環境就沒有問題了。
從這個問題的處理來看，問題本身比較簡單，處理思路也很簡單，感覺每個問題都是一些很常規的處理方式，但是帶給我們的反思就是很多簡單的問題湊在一塊兒，就可能是一個嚴重的問題，在問題的處理過程中，也需要明確分工和職責，有時候僅僅得到一個ora錯誤就去做全面的分析是遠遠不夠的，還得結合環境和具體的場景，上面兩個簡單的問題從表面來看似乎都很明顯，但是結合具體的處理場景來分析發現原因和錯誤提示資訊還是有比較大的出入。