2012-07-27日星期五, 下午5點(diǎn)左右，海外客戶報(bào)告我們(樂(lè)思軟件)外網(wǎng)監(jiān)測(cè)到的數(shù)據(jù)無(wú)法傳輸?shù)絻?nèi)網(wǎng)了，他們已經(jīng)重啟過(guò)網(wǎng)閘，刪除日志也無(wú)濟(jì)于事。
我們立即加以響應(yīng)，發(fā)現(xiàn)是網(wǎng)閘JDBC連接錯(cuò)誤：
“url=jdbc:oracle:thin:@… “
“OraConnect->connect(),DB creat driver upload error1！
“dbs->connect failed”
我們立即指導(dǎo)其讓所有同步任務(wù)重新啟用，換用備用網(wǎng)閘，但這些方法都無(wú)法讓JDBC恢復(fù)正常。
我們只好讓客戶采用原來(lái)設(shè)計(jì)好的備用方案，利用程序?qū)⑼饩W(wǎng)數(shù)據(jù)導(dǎo)出，然后導(dǎo)入內(nèi)網(wǎng)。
導(dǎo)出成功，但用Orcle impdp工具導(dǎo)入時(shí)，遇到以下錯(cuò)誤：
ORA-31693: Table data object “WDM_APP”.”TEMP_ARTICLE_DETAIL”:”SYS_P2624″ failed to load/unload and is being skipped due to error:
ORA-44002: invalid object name
ORA-06512: at “SYS.DBMS_ASSERT”, line 293
ORA-06512: at “SYS.KUPD$DATA”, line 2427
ORA-20998: Attempt To Drop
真是禍不單行，竟然備用方案也不能成功運(yùn)行。該備用方案以前是測(cè)試過(guò)的，我們立即在我們自己的測(cè)試環(huán)境中試，也可以順利執(zhí)行。
看看Oracle的DBMS_ASSERT，竟然又是加密的。連忙在Oracle在線支持系統(tǒng)中申請(qǐng)一個(gè)緊急SR。
以我們的經(jīng)驗(yàn)，Oracle支持一般都無(wú)法真正及時(shí)解決問(wèn)題，還得靠自立更生。
指導(dǎo)客戶試了多種方法， 結(jié)果每次導(dǎo)入還是這個(gè)錯(cuò)誤。幾個(gè)小時(shí)很快過(guò)去了。
這時(shí)我們擬定如下方案：次日讓網(wǎng)閘技術(shù)人員輔助解決，我們同時(shí)立即開(kāi)發(fā)一個(gè)導(dǎo)入導(dǎo)出程序來(lái)替換Oracle的 impdp工具。
開(kāi)發(fā)與支持，一直持續(xù)到凌晨4點(diǎn)，仍然無(wú)法解決。這時(shí)Oracle支持英語(yǔ)電話打過(guò)來(lái)了，但已經(jīng)是凌晨4點(diǎn)，我們已經(jīng)非常疲憊了，只好讓他明日再打過(guò)來(lái)。
Oracle支持后來(lái)在線回復(fù)讓我們收集Oracle相關(guān)信息，但這時(shí)客戶已經(jīng)下班了。
第二天星期六上午趕緊聯(lián)系網(wǎng)閘技術(shù)人員，同時(shí)完善我們的導(dǎo)入導(dǎo)出程序。
下午時(shí)，讓網(wǎng)閘技術(shù)人員趕到我公司，指導(dǎo)客戶利用一些工具登錄到網(wǎng)閘查看， 發(fā)現(xiàn)網(wǎng)閘telnet內(nèi)外網(wǎng)的數(shù)據(jù)庫(kù)服務(wù)器都是連通的，說(shuō)明網(wǎng)絡(luò)狀況沒(méi)有問(wèn)題，檢查了JDBC版本也沒(méi)有問(wèn)題，
最后決定讓用戶重啟內(nèi)外網(wǎng)數(shù)據(jù)庫(kù)服務(wù)器以及網(wǎng)閘，果然，重啟后，從我們的監(jiān)測(cè)界面上看外網(wǎng)數(shù)據(jù)立即同步到內(nèi)網(wǎng)了。
這時(shí)已經(jīng)晚上八點(diǎn)了，我們?yōu)榱藨c祝成功為客戶排除障礙，到外面吃飯。
吃完飯后，回到辦公室一看，原來(lái)高興的太早，客戶反映幾個(gè)小時(shí)前的數(shù)據(jù)都還在內(nèi)網(wǎng)沒(méi)有同步到外網(wǎng)，立即電話網(wǎng)閘技術(shù)人員，原來(lái)當(dāng)時(shí)我們做配置生效操作時(shí)，網(wǎng)閘會(huì)傳輸并清空數(shù)據(jù)，而當(dāng)時(shí)正有故障。因此這部分?jǐn)?shù)據(jù)還需要我們手工導(dǎo)出來(lái)并導(dǎo)入內(nèi)網(wǎng)。
我們?cè)趦?nèi)網(wǎng)一測(cè)試，發(fā)現(xiàn)我們的程序?qū)霑r(shí)出現(xiàn)了奇怪的Oracle錯(cuò)誤：
ORA-24816 —?Expanded non LONG bind data supplied after actual LONG or LOB column
// *Cause: A Bind value of length potentially > 4000 bytes follows binding for
// LOB or LONG.
// *Action: Re-order the binds so that the LONG bind or LOB binds are all
// at the end of the bind list.
ORA-24816 — 在實(shí)際的 LONG 或 LOB 列之后提供了擴(kuò)展的非 LONG 綁定數(shù)據(jù)錯(cuò)誤。
開(kāi)始按網(wǎng)上解決方法重新排列字段名但沒(méi)有用。后來(lái)發(fā)現(xiàn)另外一臺(tái)計(jì)算機(jī)導(dǎo)入不會(huì)有這個(gè)錯(cuò)誤，比較了Oracle客戶端版本，出錯(cuò)的是11.1.0，正常的是11.2.0，看來(lái)是Oracle OLE驅(qū)動(dòng)問(wèn)題，要升級(jí)客戶端到11.2.0才行。后來(lái)該機(jī)器僅升級(jí)了Oracle OLEDB驅(qū)動(dòng)到ODTwithODAC112030，重新導(dǎo)入成功，這個(gè)錯(cuò)誤消失了。需要以管理員身份登錄計(jì)算機(jī)，否則會(huì)有TNS錯(cuò)誤。
繼續(xù)檢查發(fā)現(xiàn)大部分?jǐn)?shù)據(jù)還是導(dǎo)入了，但后面操作導(dǎo)入的數(shù)據(jù)時(shí)非常慢，一查原因，原來(lái)是一條SQL語(yǔ)句非常慢, 幾乎無(wú)法完成, 是由于article_detail有CLOB字段。這條SQL如下：
insert into article_detail
select * from TEMP_ARTICLE_DETAIL_I_M
where article_detail_id not in(select article_detail_id from article_detail where transfer_done_time>trunc(sysdate-4))
我們將其插入方式改為先插入一個(gè)空的CLOB字段值,然后再更新該CLOB字段值，速度立即加快幾十倍，很快完成操作。
最后我們將測(cè)試通過(guò)的自己開(kāi)發(fā)的導(dǎo)出導(dǎo)入工具交給客戶，順利導(dǎo)入了所有數(shù)據(jù)。
總結(jié)
本次故障應(yīng)是數(shù)據(jù)庫(kù)服務(wù)器長(zhǎng)時(shí)間運(yùn)行后與網(wǎng)閘之間的通路出現(xiàn)潛在通信問(wèn)題造成，通過(guò)重啟核心設(shè)備與關(guān)聯(lián)設(shè)備解決。重啟關(guān)聯(lián)設(shè)備作為可能的方法之一一開(kāi)始被我們忽略了。
Oracle impdp工具導(dǎo)入時(shí)出現(xiàn)的錯(cuò)誤也許在升級(jí)Oracle客戶端后可以得到解決，但我們沒(méi)有機(jī)會(huì)再試了。
關(guān)鍵時(shí)候，還是自己的工具管用（因?yàn)橛凶畲蠓秶恼瓶夭⒖呻S時(shí)修改），應(yīng)盡量減少對(duì)第三方工具的使用。
嘗試各種方法以及沒(méi)有遠(yuǎn)程桌面靠文字與文件的溝通非常花時(shí)間， 應(yīng)加以改進(jìn)采用更方便的軟件（客戶不允許使用遠(yuǎn)程桌面）。
客戶端及時(shí)采用最新Oracle 版本。
ORA-12541:TNS:no listener
查了很久原因，各方面都正常，嘗試了一些方法，數(shù)據(jù)庫(kù)也重起了2次，耗用了大約1小時(shí)，還是同樣錯(cuò)誤。
最后查到網(wǎng)上提及l(fā)istener.log 太大也可能引起監(jiān)聽(tīng)器異常，于是讓用戶檢查，發(fā)現(xiàn)其大小為4G，讓其重命名，然后重起監(jiān)聽(tīng)器，便可以正常登錄了。
總結(jié)如下：
應(yīng)用出錯(cuò)一般是連接Oracle出問(wèn)題了，連接Oracle出問(wèn)題很可能是監(jiān)聽(tīng)器出問(wèn)題了。
需要在Windows服務(wù)管理器中重起監(jiān)聽(tīng)器。如果仍無(wú)法解決問(wèn)題，請(qǐng)按以下步驟：
如果 listener 啟動(dòng)(lsnrctl start)不成功，且有錯(cuò)誤提示，可查看提示或以下原因：
1. 計(jì)算機(jī)名字或IP作了更改
2. Oracle_Home沒(méi)有設(shè)置或不正確
如果 listener 啟動(dòng)(lsnrctl start)成功，且無(wú)錯(cuò)誤信息，而Oracle_Home也正確且近期沒(méi)有修改過(guò)計(jì)算機(jī)名或IP，且系統(tǒng)連續(xù)運(yùn)行了很長(zhǎng)時(shí)間如幾個(gè)月，而突然出現(xiàn)這個(gè)問(wèn)題，那很可能是
3. D:\app\Administrator\diag\tnslsnr\DBServer\listener\trace\listener.log太大 （這里路徑僅作示例用）
這個(gè)一般是Oracle運(yùn)行很長(zhǎng)時(shí)間后爆發(fā)，原因很隱蔽。
Oracle很強(qiáng)大，但出了問(wèn)題需要較多時(shí)間或技巧來(lái)解決，這一點(diǎn)不是很好，它完全應(yīng)開(kāi)發(fā)一個(gè)針對(duì)常見(jiàn)問(wèn)題的自動(dòng)診斷程序來(lái)輔助用戶快速定位與解決。
]]>