曲折的dump匯入及問題分析

今天下午的時候得到反饋，說開發在匯入一個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
看這個錯誤是audit的部分無法寫入了，可能是audit表佔用的空間較大，也可能是系統空間不足導致。
嘗試登陸其它的幾個庫，也是類似的問題，這個時候問題一下子變得嚴重起來，需要趕緊修復。
使用sysdba都無法登入，所以直接定位到日誌目錄還是有點困難的，這個時候我們可以藉助引數檔案，這個路徑是固定的 $ORACLE_HOME/dbs下面，直接檢視init.ora檔案找到diagnostic_dest對應的路徑。
簡單定位後，發現所在的分割槽系統空間不足了，發現歸檔檔案佔用了大部分的空間，這個時候需要儘快釋放這部分的空間，一種思路就是把修改歸檔路徑，但是這種方式可行但不值得提倡，這個環境會有很多人來維護，其中的引數和配置資訊基本都是統一的，如果隨意修改，後續的人來支援就會遇到一些問題，如此反覆，簡單的一個小問題就可能導致一些複雜潛在的問題，這個時候還是建議保留原值，但是可以考慮建立一個連結直接連結到空間比較充足的分割槽下。
比如下面的例子就是建立一個連結 arc, 連結到 /oravl20/oradata/CNVxxxx/arc下面。
ln -s /oravl20/oradata/CNVxxxx/arc  arc
這個錯誤比較明顯，基本可以判定是由於資料問題導致的，但是資料抽取工具抽取的資料都是嚴格按照抽取邏輯來執行的，應該不會出現這種錯誤。這種問題一般來說DBA都不會直接確認都會直接交給開發自己去確認這類資料問題，今天因為問題比較急，就順帶查了一下。
因為提供的日誌資訊有限，所以就馬上連線到這套環境，找到對應的外來鍵對應關係，做了兩個簡單的查詢。

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錯誤就去做全面的分析是遠遠不夠的，還得結合環境和具體的場景，上面兩個簡單的問題從表面來看似乎都很明顯，但是結合具體的處理場景來分析發現原因和錯誤提示資訊還是有比較大的出入。