一只‘大虫’终于被抓出来了

公司的一影像系统，分为c/s影像采集和b/s查询维护两部份。系统大致流程是，外部系统调用影像的接口，将影像索引数据和对应的条码信息，保存到数据库中的业务主表和流水表中。然后通过c/s程序扫描纸质文件，根据图像上识别的条码到数据库流水表中查找该条码对应的流水信息。

这套系统在该地方刚上线没多久，有用户反应有不少条码提示无流水匹配。我在排除了条码方面的原因后，到后台的数据库中查看，在业务主表中存在相关记录，图像记录的最终存储表中没有记录表示图像没有发布，排除了重复扫描图像的可能性。但是在流水信息表中却找不到该条码对应的流水信息，这个就奇怪了。正常情况是应该存在有对应的流水信息才对，因为因为主表中已经存在相关的记录了。流水删除也是在正常发布后才会进行的。

仔细分析下，有可能的原因有两个，一是外部系统调用接口保存时出错。另外就是程序什么地方出差把流水记录删除了。 仔细检查了下保存接口的代码，发先保存操作是放在同一个事务里操作的，所以不大可能。那么分析下日志看看是不是什么地方误删除了，因为删除更新操作在日志中都有记录。分析日志时又遇上了麻烦，日志文件好多个，每个都几M的，日志中还混杂了正常的删除操作，要靠肉眼查找，岂不麻烦死了。想用正则表达式，但是好像很难写出来。就编个小程序来解决了，操起VC6.0写了小程序分析结果居然都是正常的删除操作。

从逻辑上来考虑，这种情况是不大可能出现的了，和几个同事交流后也是无果。有同事提起以前遇到过更怪的，每天阳光射进来的时候系统就会死机，结果最后原因居然是服务器太烂，阳光照上去散热不好而死机，听起来像个笑话。

被这个问题困扰了好久，发生的时间和数据好像都没什么规律。真不知道从何下手了。
偶尔一天，查看系统的参数配置表时，发现问题所在了，原来b/s程序的后台居然有个自动清理的线程，这个线程会删除过7天没匹配的流水数据。我晕啊，居然是这鸟原因，害的搞了好多天，绞尽了脑汁，我靠我靠。