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

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

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