今天遇到一个问题，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基本处于停滞状态。