No job logs available for this job

过年回来，检查一下开发系统，发现DB备份都不成功,check也失败，检查一下日志，里面什么都没有，只有：No job logs available for this job。这到引起我的注意。检查sm37，发现所有的后台任务也都失败，检查sm21发现报同样的错误：不能写入日志文件。是什么原因造成日志文件不能写入呢？我想还是登陆OS去看一眼。

 

 果然，发现根目录这个目录空间是满的，所以日志文件不能写入了。日志文件都是保存在/sapmnt/ 这个路径下的，而由于是开发系统，我们并没有单独mount出一个/sapmnt 的目录，所以根目录满了就不能写入日志了。

 更深入的看里面文件夹的大小：

 

发现怎么000这个client怎么joblog这么大！很反常！可能这个就是造成空间很快沾满的原因吧！我便进入sm37检查以往的job，发现如图的问题

RDDIMPDP 这个job出奇的多，而且都是失败！进入检查，发现这个任务的周期是个event出发周期，用户名是DDIC。

 检查以往成功的任务记录，每天基本也就跑一次，为什么现在这么多？我想是因为一直失败的原因吧！继续调查原因，不禁让我对DDIC这个用户产生怀疑！马上登陆000client的su01查看，的却DDIC被锁定了（可能是老大觉得不安全给锁了吧），马上给解除，任务就可以正常运行了，观察了一两个小时，发现周期也不再频繁，终于吃了颗定心丸。

 继续解决问题，我又检查了一下生产机，发现生产机的任务日志很少的，并且以往的任务都不存在了，一定有任务给定期删除job的日志。再次检查，找到了这个任务名称。

 经过对照，找出RSBTCDEL2这个程序可以删除以前的job，便对开发系统也做后台任务，定期跑这个程序，并且手工跑了一把，结果如图：

任务设置无误，我想这个问题就算彻底解决了。通过这次检查，也发现了开发系统很多有问题的job，也正好进行了处理。。。

经验总结：

1.跑后台job的用户最好统一设成一个，比如建立一个jobrun用户，专门跑job使用，这样可以避免很多由于锁用户造成的任务失败。

2.RSBTCDEL2这个程序可以删除job

3.joblogs储存在 /sapmnt/<sid>/global 路径下

4.开发系统、测试系统等，虽然没有生产系统那么重要，但是该做的job也要做，也要经常检查，不然也会让你很费时间

5.如果出了问题，找相同的其他系统进行对比，会帮助你更快的解决问题