本次BUG事件排查爲兩天，事發是實施在客戶處收到一個線上BUG，我們提供的webservice服務在操作的時部分數據入庫有問題。
第一反應是：數據本身有問題，因爲有部分數據入庫，而部分數據入庫。但我們的業務邏輯是對數據進行加密，同時將原始數據和加密後的數據進行入庫，那麼首要操作需要排查出出問題的原始數據。這時，問題出現了，客戶沒按原來的定好的邏輯操作，而是將原始數據加密後，作爲原始數據傳給程序，我們的程序再次加密，同時，提供給我們的爲
dmp文件，故需要導入數據庫才能查看（後發現，這個細節沒有引起我足夠的注意，導致浪費了很多時間）。導入oracle 10g後發現數據已經是以亂碼形式存在，根本無法比較正確入庫和未入庫的數據有什麼區別。
然後想到的是，查看日誌，但是，因爲是產品，真正運行環境是實施所在的外地，在人家的環境，所以在第一時間沒有獲得日誌。
然後想到的是，最痛苦的過程 重現環境。。。。產品分爲兩部分，一部分是提供webservice接口的服務，一部分是提供一個管理平臺，問題又來了，管理平臺源碼居然沒有了！
後來千辛萬苦，找到了一份可以執行的.class。。重現搭建好環境後，第一天已經過去了。。
第二天的情況是，得到了客戶環境的日誌，發現
出錯的數據分爲兩類，1是對應的字段爲varchar2(200)但是，持久化的字段只要爲中文，就會報錯。2對應字段爲clob，但是當存入的數據超出某個長度的時候，也會報錯，而報出的錯誤爲一個：ORA-01461: can bind a LONG value only for insert into a LONG column。
經過google後，發現大家對這個錯誤的解決爲：1，更新jdbc驅動 2將clob數據分開儲存。而引起中文這個問題的可能性最大是因爲數據庫的字符集。
突然想到是不是數據庫版本有問題 然後確定客戶數據庫版本，，他們果然是11g...當時有種莫名的東西堵在胸口。。。要知道，這可是線上運行很久的系統了，我是從接到bug的時候纔開始知道這個項目的。NND,更換了驅動，本機測試，，一切正常。。。
最後總結這兩天，排查過程艱辛而有趣，但是解決方法很簡單。。反而無趣了。