2012-07-27日星期五, 下午5點左右,海外客戶報告我們(樂思軟件)外網監測到的數據無法傳輸到內網了,他們已經重啟過網閘,刪除日志也無濟于事。
我們立即加以響應,發現是網閘JDBC連接錯誤:
“url=jdbc:oracle:thin:@… “
“OraConnect->connect(),DB creat driver upload error1!
“dbs->connect failed”
我們立即指導其讓所有同步任務重新啟用,換用備用網閘,但這些方法都無法讓JDBC恢復正常。
我們只好讓客戶采用原來設計好的備用方案,利用程序將外網數據導出,然后導入內網。
導出成功,但用Orcle impdp工具導入時,遇到以下錯誤:
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
真是禍不單行,竟然備用方案也不能成功運行。該備用方案以前是測試過的,我們立即在我們自己的測試環境中試,也可以順利執行。
看看Oracle的DBMS_ASSERT,竟然又是加密的。連忙在Oracle在線支持系統中申請一個緊急SR。
以我們的經驗,Oracle支持一般都無法真正及時解決問題,還得靠自立更生。
指導客戶試了多種方法, 結果每次導入還是這個錯誤。幾個小時很快過去了。
這時我們擬定如下方案:次日讓網閘技術人員輔助解決,我們同時立即開發一個導入導出程序來替換Oracle的 impdp工具。
開發與支持,一直持續到凌晨4點,仍然無法解決。這時Oracle支持英語電話打過來了,但已經是凌晨4點,我們已經非常疲憊了,只好讓他明日再打過來。
Oracle支持后來在線回復讓我們收集Oracle相關信息,但這時客戶已經下班了。
第二天星期六上午趕緊聯系網閘技術人員,同時完善我們的導入導出程序。
下午時,讓網閘技術人員趕到我公司,指導客戶利用一些工具登錄到網閘查看, 發現網閘telnet內外網的數據庫服務器都是連通的,說明網絡狀況沒有問題,檢查了JDBC版本也沒有問題,
最后決定讓用戶重啟內外網數據庫服務器以及網閘,果然,重啟后,從我們的監測界面上看外網數據立即同步到內網了。
這時已經晚上八點了,我們為了慶祝成功為客戶排除障礙,到外面吃飯。
吃完飯后,回到辦公室一看,原來高興的太早,客戶反映幾個小時前的數據都還在內網沒有同步到外網,立即電話網閘技術人員,原來當時我們做配置生效操作時,網閘會傳輸并清空數據,而當時正有故障。因此這部分數據還需要我們手工導出來并導入內網。
我們在內網一測試,發現我們的程序導入時出現了奇怪的Oracle錯誤:
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 — 在實際的 LONG 或 LOB 列之后提供了擴展的非 LONG 綁定數據錯誤。
開始按網上解決方法重新排列字段名但沒有用。后來發現另外一臺計算機導入不會有這個錯誤,比較了Oracle客戶端版本,出錯的是11.1.0,正常的是11.2.0,看來是Oracle OLE驅動問題,要升級客戶端到11.2.0才行。后來該機器僅升級了Oracle OLEDB驅動到ODTwithODAC112030,重新導入成功,這個錯誤消失了。需要以管理員身份登錄計算機,否則會有TNS錯誤。
繼續檢查發現大部分數據還是導入了,但后面操作導入的數據時非常慢,一查原因,原來是一條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))
我們將其插入方式改為先插入一個空的CLOB字段值,然后再更新該CLOB字段值,速度立即加快幾十倍,很快完成操作。
最后我們將測試通過的自己開發的導出導入工具交給客戶,順利導入了所有數據。
總結
本次故障應是數據庫服務器長時間運行后與網閘之間的通路出現潛在通信問題造成,通過重啟核心設備與關聯設備解決。重啟關聯設備作為可能的方法之一一開始被我們忽略了。
Oracle impdp工具導入時出現的錯誤也許在升級Oracle客戶端后可以得到解決,但我們沒有機會再試了。
關鍵時候,還是自己的工具管用(因為有最大范圍的掌控并可隨時修改),應盡量減少對第三方工具的使用。
嘗試各種方法以及沒有遠程桌面靠文字與文件的溝通非常花時間, 應加以改進采用更方便的軟件(客戶不允許使用遠程桌面)。
客戶端及時采用最新Oracle 版本。