2012-07-27日星期五, 下午5點(diǎn)左右，海外客戶報(bào)告我們(樂思軟件)外網(wǎng)監(jiān)測(cè)到的數(shù)據(jù)無法傳輸?shù)絻?nèi)網(wǎng)了，他們已經(jīng)重啟過網(wǎng)閘，刪除日志也無濟(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)閘，但這些方法都無法讓JDBC恢復(fù)正常。
我們只好讓客戶采用原來設(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è)試過的，我們立即在我們自己的測(cè)試環(huán)境中試，也可以順利執(zhí)行。
看看Oracle的DBMS_ASSERT，竟然又是加密的。連忙在Oracle在線支持系統(tǒng)中申請(qǐng)一個(gè)緊急SR。
以我們的經(jīng)驗(yàn)，Oracle支持一般都無法真正及時(shí)解決問題，還得靠自立更生。

指導(dǎo)客戶試了多種方法， 結(jié)果每次導(dǎo)入還是這個(gè)錯(cuò)誤。幾個(gè)小時(shí)很快過去了。
這時(shí)我們擬定如下方案：次日讓網(wǎng)閘技術(shù)人員輔助解決，我們同時(shí)立即開發(fā)一個(gè)導(dǎo)入導(dǎo)出程序來替換Oracle的 impdp工具。

開發(fā)與支持，一直持續(xù)到凌晨4點(diǎn)，仍然無法解決。這時(shí)Oracle支持英語電話打過來了，但已經(jīng)是凌晨4點(diǎn)，我們已經(jīng)非常疲憊了，只好讓他明日再打過來。
Oracle支持后來在線回復(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ù)庫服務(wù)器都是連通的，說明網(wǎng)絡(luò)狀況沒有問題，檢查了JDBC版本也沒有問題，
最后決定讓用戶重啟內(nèi)外網(wǎng)數(shù)據(jù)庫服務(wù)器以及網(wǎng)閘，果然，重啟后，從我們的監(jiān)測(cè)界面上看外網(wǎng)數(shù)據(jù)立即同步到內(nèi)網(wǎng)了。
這時(shí)已經(jīng)晚上八點(diǎn)了，我們?yōu)榱藨c祝成功為客戶排除障礙，到外面吃飯。

吃完飯后，回到辦公室一看，原來高興的太早，客戶反映幾個(gè)小時(shí)前的數(shù)據(jù)都還在內(nèi)網(wǎng)沒有同步到外網(wǎng)，立即電話網(wǎng)閘技術(shù)人員，原來當(dāng)時(shí)我們做配置生效操作時(shí)，網(wǎng)閘會(huì)傳輸并清空數(shù)據(jù)，而當(dāng)時(shí)正有故障。因此這部分?jǐn)?shù)據(jù)還需要我們手工導(dǎo)出來并導(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ò)誤。

開始按網(wǎng)上解決方法重新排列字段名但沒有用。后來發(fā)現(xiàn)另外一臺(tái)計(jì)算機(jī)導(dǎo)入不會(huì)有這個(gè)錯(cuò)誤，比較了Oracle客戶端版本，出錯(cuò)的是11.1.0，正常的是11.2.0，看來是Oracle OLE驅(qū)動(dòng)問題，要升級(jí)客戶端到11.2.0才行。后來該機(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í)非常慢，一查原因，原來是一條SQL語句非常慢, 幾乎無法完成, 是由于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è)試通過的自己開發(fā)的導(dǎo)出導(dǎo)入工具交給客戶，順利導(dǎo)入了所有數(shù)據(jù)。

總結(jié)

本次故障應(yīng)是數(shù)據(jù)庫服務(wù)器長(zhǎng)時(shí)間運(yùn)行后與網(wǎng)閘之間的通路出現(xiàn)潛在通信問題造成，通過重啟核心設(shè)備與關(guān)聯(lián)設(shè)備解決。重啟關(guān)聯(lián)設(shè)備作為可能的方法之一一開始被我們忽略了。
Oracle impdp工具導(dǎo)入時(shí)出現(xiàn)的錯(cuò)誤也許在升級(jí)Oracle客戶端后可以得到解決，但我們沒有機(jī)會(huì)再試了。
關(guān)鍵時(shí)候，還是自己的工具管用（因?yàn)橛凶畲蠓秶恼瓶夭⒖呻S時(shí)修改），應(yīng)盡量減少對(duì)第三方工具的使用。
嘗試各種方法以及沒有遠(yuǎn)程桌面靠文字與文件的溝通非常花時(shí)間， 應(yīng)加以改進(jìn)采用更方便的軟件（客戶不允許使用遠(yuǎn)程桌面）。
客戶端及時(shí)采用最新Oracle 版本。