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

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

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

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

圖1 重啟后仍未同步成功

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

解決問(wèn)題

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

2.做災(zāi)備端磁盤(pán)空間清

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

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

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

那是什么原因?qū)е铝诉@些文件的產(chǎn)生呢？

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

圖3 顯示搜尋結(jié)果

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

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

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

首先，刪除無(wú)效連接，通知相關(guān)開(kāi)發(fā)人員調(diào)整YJCJ登錄用戶(hù)數(shù)。

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

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

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

后記

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

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

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