今天遇到一個問題，job不停的在那里運行，然后link上的數(shù)據(jù)顯示各個環(huán)節(jié)都是正確的，包括最后插入數(shù)據(jù)庫的link上也顯示了數(shù)據(jù)，但是最后數(shù)據(jù)庫里并沒有數(shù)據(jù)。在Director的log中，日志在從兩個源文件把所有數(shù)據(jù)load出來完之后，日志就死在那里了。
以前這個job是正確的，昨天由于重新load其中一個源文件的元數(shù)據(jù)，所以出現(xiàn)了上述問題。所以先前以為是由于load的新的源數(shù)據(jù)有問題，就從此處來找問題的原因，并且認為可能是改了元數(shù)據(jù)，在其他地方映射的時候有位置不對的地方，所以整了很久。因為以前是好好的，然后又以為是服務(wù)器的問題。

這都是定勢思維的錯誤，然后又一急，所以浪費了很多時間，其實很多時候都是這樣，出了問題我們不能理性的好好思考。

其實問題很簡單：
如果我們按照正常邏輯來分析的話，既然不能讀入數(shù)據(jù)庫，肯定是數(shù)據(jù)不符合數(shù)據(jù)庫對數(shù)據(jù)的約束，包括主鍵啊，非空啊，本問題就是由于在stage的不斷流轉(zhuǎn)中產(chǎn)生了很多空格，使得最后待插入的數(shù)據(jù)長度遠遠大于數(shù)據(jù)庫中定義的字段長度。由于在那里不斷reject，所以影響了速度，job一直在那里運行。最后用APT_STRING_PADDER,將其設(shè)為0x0（用null代替空格）搞定。
ps：在插入數(shù)據(jù)庫時使用一個reject文件對查錯有好處，這樣能看到reject是些什么數(shù)據(jù)，然后就能知道為什么被reject了。
同時我們可以得出如果最后插入數(shù)據(jù)庫時很多數(shù)據(jù)被reject，但是你并沒有用一個reject文件來接收這些reject掉的數(shù)據(jù)，將使得job基本處于停滯狀態(tài)。