久久亚洲视频-成人av免费在线-亚洲免费大片-www.国产精品.com-又黄又爽又色的视频-精品乱子伦一区二区-无码人妻精品一区二区三区66-欧美一级做-国产在线国偷精品免费看-欧美性极品少妇-精品无码久久久久久久久久

2012-07-27日星期五, 下午5點左右，海外客戶報告我們(樂思軟件)外網(wǎng)監(jiān)測到的數(shù)據(jù)無法傳輸?shù)絻染W(wǎng)了，他們已經(jīng)重啟過網(wǎng)閘，刪除日志也無濟于事。
我們立即加以響應，發(fā)現(xiàn)是網(wǎng)閘JDBC連接錯誤：

“url=jdbc:oracle:thin:@… “
“OraConnect->connect(),DB creat driver upload error1！
“dbs->connect failed”

我們立即指導其讓所有同步任務重新啟用，換用備用網(wǎng)閘，但這些方法都無法讓JDBC恢復正常。
我們只好讓客戶采用原來設計好的備用方案，利用程序將外網(wǎng)數(shù)據(jù)導出，然后導入內網(wǎng)。
導出成功，但用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

真是禍不單行，竟然備用方案也不能成功運行。該備用方案以前是測試過的，我們立即在我們自己的測試環(huán)境中試，也可以順利執(zhí)行。
看看Oracle的DBMS_ASSERT，竟然又是加密的。連忙在Oracle在線支持系統(tǒng)中申請一個緊急SR。
以我們的經(jīng)驗，Oracle支持一般都無法真正及時解決問題，還得靠自立更生。

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

開發(fā)與支持，一直持續(xù)到凌晨4點，仍然無法解決。這時Oracle支持英語電話打過來了，但已經(jīng)是凌晨4點，我們已經(jīng)非常疲憊了，只好讓他明日再打過來。
Oracle支持后來在線回復讓我們收集Oracle相關信息，但這時客戶已經(jīng)下班了。

第二天星期六上午趕緊聯(lián)系網(wǎng)閘技術人員，同時完善我們的導入導出程序。

下午時，讓網(wǎng)閘技術人員趕到我公司，指導客戶利用一些工具登錄到網(wǎng)閘查看， 發(fā)現(xiàn)網(wǎng)閘telnet內外網(wǎng)的數(shù)據(jù)庫服務器都是連通的，說明網(wǎng)絡狀況沒有問題，檢查了JDBC版本也沒有問題，
最后決定讓用戶重啟內外網(wǎng)數(shù)據(jù)庫服務器以及網(wǎng)閘，果然，重啟后，從我們的監(jiān)測界面上看外網(wǎng)數(shù)據(jù)立即同步到內網(wǎng)了。
這時已經(jīng)晚上八點了，我們?yōu)榱藨c祝成功為客戶排除障礙，到外面吃飯。

吃完飯后，回到辦公室一看，原來高興的太早，客戶反映幾個小時前的數(shù)據(jù)都還在內網(wǎng)沒有同步到外網(wǎng)，立即電話網(wǎng)閘技術人員，原來當時我們做配置生效操作時，網(wǎng)閘會傳輸并清空數(shù)據(jù)，而當時正有故障。因此這部分數(shù)據(jù)還需要我們手工導出來并導入內網(wǎng)。

我們在內網(wǎng)一測試，發(fā)現(xiàn)我們的程序導入時出現(xiàn)了奇怪的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 綁定數(shù)據(jù)錯誤。

開始按網(wǎng)上解決方法重新排列字段名但沒有用。后來發(fā)現(xiàn)另外一臺計算機導入不會有這個錯誤，比較了Oracle客戶端版本，出錯的是11.1.0，正常的是11.2.0，看來是Oracle OLE驅動問題，要升級客戶端到11.2.0才行。后來該機器僅升級了Oracle OLEDB驅動到ODTwithODAC112030，重新導入成功，這個錯誤消失了。需要以管理員身份登錄計算機，否則會有TNS錯誤。

繼續(xù)檢查發(fā)現(xiàn)大部分數(shù)據(jù)還是導入了，但后面操作導入的數(shù)據(jù)時非常慢，一查原因，原來是一條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字段值，速度立即加快幾十倍，很快完成操作。

最后我們將測試通過的自己開發(fā)的導出導入工具交給客戶，順利導入了所有數(shù)據(jù)。

總結

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