如題，近幾天在利用Kettle進行數據遷移的工作（也就是把數據全量導入到新數據庫中，其中有些字段有些許調整），在寫好腳本並執行後發現一個很嚴重的問題——每次腳本在執行到某個位置的時候就會意外停止，如下兩圖所示
而自帶的日誌中提示類似如下：
2019/01/12 14:43:07 - 表輸出.0 - ORA-12592: TNS: 包錯誤
2019/01/12 11:37:46 - 表輸出。0 Caused by : java.sql.BatchUpdateException: ORA-01438:值大於為此列指定的允許精度
百度谷歌了一下這種錯誤，是屬於Oracle的錯誤，在關於kettle的提問當中也有人遇到類似錯誤，但是在樓下回復的內容中並沒有找到太多有用的信息。
所以猜想其中可能有部分數據是“髒數據”，導致插入到新數據庫中時報錯，至於圖中在表輸出時數量都是整百是因為在腳本的“表輸出”環節中設置了默認為1000條提交一次，也就是1000條commit一次，而當這一千條中有數據插不進去的時候，當然會報錯了，那麼我們現在大概知道了錯誤的原因，我們要想怎麼解決它……
下面有兩個疑問：
我怎麼能越過錯誤數據並記錄下來直接進行下面數據的提交
我怎麼能找出來這些錯誤數據？具體到每條？
後來專程因為這個去我的兩個kettle群裡問了一下，結果有一個人回答了我說讓我用日誌，後來私聊他問具體情況的時候他過半小時沒回我於是我用出了殺手鐧——給紅包，把我QQ錢包裡僅有的四塊錢塞在了裡面，這樣他處於好奇心一定會點開，那麼在中國，拿了錢你還能不辦事嗎（滑稽），雖然最後他也沒有給出特別有建設性的建議，但是我修改了一下腳本，至少解決了出了錯就越過的需求
這裡我們看到了表輸入的地方輸入時有28W，是因為我中間進行強制暫停了，實際上源數據大概有128W
我在後面加了這個 表輸入的地方填的是500 現在空操作裡有31000條數據 就是大概有至少62個錯誤 ，也就是說現在的這個腳本可以實現的功能就是—— 遇到錯誤可以略過，但是連同錯誤數據一起提交的其他數據也上傳不了，
這當然也不是我們想要的
因為在使用kettle的轉換過程中 我們發現在連接每兩個步驟的時候如果慢一點鬆開鼠標我們是可以看到有輸出步驟和錯誤輸出步驟的選項，而後者就是為了我們這種需求而存在的，在這個步驟中一旦遇到了錯誤 ，我們可以讓它去執行下面的語句。
總結一下可以理解成：之前版本的沒有錯誤處理的相當於只有一個if語句，那麼如果一旦不滿足 就跳出來報錯，而我們第二種解決方案也就是上圖 ，加了一個else功能，如果不滿足，那麼還有備選，或者這裡理解成一個try塊也是一樣的。
那麼我們是不是可以繼續增加功能呢 比如把下面的空操作換成別的 比如。。。日誌？
但是在接下來的實踐中，kettle轉換中的“寫日誌”步驟貌似是要鏈接數據庫的，那麼問題就來了，我只是想知道這些錯誤數據是哪些，然後找出來，改正它，再導入到新的數據庫而已，我為了找出這幾個錯誤數據還要建表？？，想想公司配的電腦，想想鏈接Oracle時那緩慢的速度於是瞬間打消了念頭，。。
那麼。。。
我們為啥不在它後面加上別的輸出呢，比如txt？excel？？？
於是我先使用了txt 並把日誌類型設置成詳細日誌（其它的還有 沒有日誌 最小日誌 ，基本日誌，調試，行級日誌等），執行了一會後發現實在是太多太多了， ——瞬間清屏了，，一個可拉的滾動條只能看見兩秒鐘內的數據傳輸，而且包括輸出成功的數據（真是夠詳細的=。=），而且txt在看數據的時候特別不方便，於是下面又用了錯誤日誌 + excel輸出
考慮到每次提交都會把連帶一起commit的數據也扔掉，所以在“表輸入”的時候選項改成了1，為了找出錯誤就是如此喪心病狂，已經無所謂效率了
最後如下
也就是這128W的數據中有62個髒數據來阻止我們正常進行數據遷移，好可恨啊！
那麼我們下面只要好好分析一下這些髒數據到底是哪裡出了問題，然後改正它們，最後再把所有的數據重新導入，問題就應該全部解決了。。
但是這裡還有個最後的問題，這種解決方案是最優的嗎？我們為了保證正確數據的不缺失而讓每次提交的數據量為1 ，這樣大大降低了效率，但是目前我還沒有更好的解決方案，也不知道該問誰，但是最後看問題解決了就很好，如果有哪位大神在看到這裡，如果有更好的解決方案請與本人聯繫，本人一定虛心學習。
閱讀更多 音樂電影混剪 的文章
