一次數據庫同步異常停止的風波

筆者是數據庫管理員，隨著企業業務的發展變化，不斷增加了新的數據庫服務器。這些服務器硬件配置不同，操作系統不同，數據庫版本各異，因此在建設數據中心時，需要相應的同步備份軟件來集中各數據庫服務器的數據。

經過綜合考量，選用了Oracle GoldenGate軟件來實現異構IT環境間實時數據集成和復制。

發現問題

某次在例行檢查中，發現GoldenGate異常停止，不再同步數據，鑒于服務器環境不穩定，決定先重新啟動看看，執行啟動操作后，狀態顯示“abending”，說明同步仍然未能成功啟動，如圖1所示。

圖1 重啟后仍未同步成功

圖2 查看日志發現磁盤空間已滿

解決問題

1.查 看 日 志， 提示“Oracle GoldenGate Command Interpreter for Oracle”，登 錄 遠 端 主 機，發現災備端安裝文件夾/oracle磁盤空間滿了，如圖2。

2.做災備端磁盤空間清

理， 用“find”命令查找超大文件：

查找結果除了Oracle的users表空間文件，并未查找到超大文件，再查找大于100M文件。不免心生疑惑，每天上午都做例行檢查，昨天磁盤空間都正常，為什么今天就磁盤空間暴漲了呢？

如圖3所示，這一次的搜尋結果顯示，在/oracle/admin/oracle/cdump文件中，有大量的core文件，進入“/oracle/admin/oracle/cdump”查看，發現這些文件都產生在前一天下午！

那是什么原因導致了這些文件的產生呢？

3.檢查Oracle數據庫服務器運行情況，發現不時出現客戶端連接間歇性失敗，報錯“ORA-12519”。這類錯誤常見的問題就是數據庫上當前的連接數目已經超過了它能夠處理的最大值，那就檢查數據庫連接情況：

圖3 顯示搜尋結果

檢查結果顯示是用戶YJCJ會話數過多，且存在大量INACTIVE狀 態。Oracle數據庫會話有ACTIVE、INACTIVE、KILLED、 CACHED、SNIPED五種狀態。INACTIVE狀態的會話表示此會話處于非活動、空閑、等待狀態。例如PL/SQL Developer連接到數據庫，執行一條SQL語句后，如果不繼續執行SQL語句，那么此會話就處于INACTIVE狀態。

一般情況下，少量的INACTVIE會話對數據庫并沒有什么影響，如果由于程序設計等某些原因導致數據庫出現大量會話長時間處于INACTIVE狀態，那么將會導致大量系統資源被消耗，造成會話數超過系統session的最大值，出現連接錯誤。與相關開發人員聯系，原來是集中了100余客戶在做培訓測試，連接又一直沒有釋放，最終超過了設定的最大連接數（150），導致數據庫異常，日志文件寫進了cdump中，造成磁盤空間暴漲。

4.現在找到原因后，就可以按部就班進行處理了。

首先，刪除無效連接，通知相關開發人員調整YJCJ登錄用戶數。

其次，清除日志，恢復磁盤空間，重新啟動Oracle GoldenGate，狀 態 顯 示RUNNING，說明同步已經正常。

第三，修改參數，增加最大連接數，重新啟動數據庫后生效。

Oracle文 檔 要 求，SESSIONS和TRANSACTIONS的初始化參數應該源于PROCESSES參數，根據默認設置SESSIONS = PROCESSES *1.1 + 5

后記

在不久之后，另一臺數據庫服務器也發生同步停止。同樣是因磁盤空間已滿，但這次故障出現是“/oracle/admin/oracle/bdump”中的日志文件暴漲，每分鐘產生一個80M左右的.trc文件，2個小時磁盤空間就滿了，經過仔細查看，在trace文件中記錄有如下提示：

經過檢查，發現用戶有定時任務，每分鐘調用過程SCDL__KUA01和S_GTCR_DMY，而這兩個過程執行語句有問題，導致每分鐘產生一個.trc文件，最終撐滿了磁盤空間！

在日常運維過程中發現的問題，往往由背后盤枝錯節的因素導致。如果只是頭疼醫頭，腳疼醫腳的話，很有可能還會繼續出現錯誤，就像本例中，同步停，就只啟同步，空間滿就只管刪除文件，那過不了多久，問題還要出現。這需要我們在解決問題的過程中，多思考、多測試、準確判斷，找到產生故障的源頭，徹底解決問題！