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

經(jīng)過綜合考量，選用了Oracle GoldenGate軟件來實現(xiàn)異構IT環(huán)境間實時數(shù)據(jù)集成和復制。

發(fā)現(xiàn)問題

某次在例行檢查中，發(fā)現(xiàn)GoldenGate異常停止，不再同步數(shù)據(jù)，鑒于服務器環(huán)境不穩(wěn)定，決定先重新啟動看看，執(zhí)行啟動操作后，狀態(tài)顯示“abending”，說明同步仍然未能成功啟動，如圖1所示。

圖1 重啟后仍未同步成功

圖2 查看日志發(fā)現(xiàn)磁盤空間已滿

解決問題

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

2.做災備端磁盤空間清

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

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

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

那是什么原因導致了這些文件的產(chǎn)生呢？

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

圖3 顯示搜尋結果

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

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

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

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

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

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

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

后記

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

經(jīng)過檢查，發(fā)現(xiàn)用戶有定時任務，每分鐘調用過程SCDL__KUA01和S_GTCR_DMY，而這兩個過程執(zhí)行語句有問題，導致每分鐘產(chǎn)生一個.trc文件，最終撐滿了磁盤空間！

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