ORA-08103

没有一个异常是无缘故的，就像恐怖片里的故事，我们观众一路看下来都觉得疑点重重，好几处证据，好些角色的行为都很诡异，但是我们就是查不到原因，找不到答案。等到疑点之间开始有联系，从已知联系去关联至其他需要处理的难题上才把难题解決。问题解决完后，之前的所有疑点才个个地解开，真相大白。。。。

就如昨天遇到的报错一样，CTM生产环境报了下面的错误：

The Ocl function execute Direct returned status-1. Error code: 8103,Error message

ORA-08103: obiect no longer exists(...)

背景是共有4个作业ABCD。C作业报了ORA-08103的错，而这个报错情况是，C在SELECT的时候，同时有DDL操作（通常是 TRUNCATE)，SELECT和 TRUNCATE并行操作，从而导致“obiect no longer exists”的报错。查了作业控件里SQL放置，并没有与其他正常作业有异常。到堡垒机查询目标表，可以看到B、C两个作业的目标表一直在刷新，从上午到中午，理论上应的作业都是在调的，但是作业就停在上午八点了。另外A、D作业的目标表和CTM调度状态一样都是在8点再也没有刷新。

这也是，8点这个时刻的C作业已经报错了，如果不处理C那不会生产一个新任务再循环调度。

突然想到昨晚在新ODS库部署名字相似的作业可能昨晚上线的作业和LTS在调我旧ODS库的作业。这里规划的是CTM配置的是日ODS库，LTS配置的是新ODS库。因此我打开新ODS库把这个任务我的所有作业都查了ー下发现，只有AD作业配置在新库的目标表有数据而BC对应的目标表均无数据。一下子突然搞清楚了，原来是昨晚试部署LTS调度(项目组开始使用LTS慢慢替换CTM调度工具)，实施人员选错选了我的旧库的DS名(4个作业选了2个)用TS调度了我旧ODS的DS。I旧DS上配置的参数是旧库的，新DS配置的参数是新库的。新DS没被选到的，所以新库对应大目标表均无数居，有被选到的才有数据，同时LTS选中的旧的DS就和CTM里一致了，同时调度就会报错，就在8点开始了同时调度(作业C)的操作就报错了。

任务中有一个作业报错，需要处理这个作业这个任务才会完成;在这个作业还没有处理的时，那其他作业即使正常调度也不会进入下一个新执行环节。因而作业ABD当时均无调度。