今天下午的时候客户发邮件反馈说，对于某个环境中的文件系统监控和表空间使用情况的邮件收到的比较频繁，感觉是1个小时发送一次，完全可以3个小时发送一次，接到这个问题后，最直接的联想就是使用crontab。
结果登录到服务器端之后查看，得到的结果如下：
> crontab -l
# Minute    Hour    Month    Day    Month    Weekday Command
###############################################################################
52 6,9,12,15,18,21 * * * /oravl01/orainst/XXXXX/FileSystem.ksh  
################### TABLESPACE ALERT - FOR ALL ######################################
52 6,9,12,15,18,21 * * * /bin/ksh "/oravl01/orainst/dba/ENV/free_tbs_alert.ksh XXXX" 
简单再来回顾一下crontab的使用,crontab中含有6个参数，分别代表分，小时，天，周，月，待运行的脚本。
所以对于这个问题来说，
52 6,9,12,15,18,21 * * * 代表的意义就是 在每天的6点，9点，12点，15点，18点，21点，在52分的时候运行一次指定的脚本内容。
按照这个配置还是很合理的，在大半夜也不会频繁发送不是很紧急的一些邮件造成不必要的干扰。从配置来看是每3个小时运行一次。
但是根据客户的反馈说发送的频率有些频繁了，在这一点上，问题就有些蹊跷了。
带着疑问查看了对应的脚本内容，也没有发现特别的时间设定，都是一些例行的检查点。
最后带着疑惑和客户做了简单的沟通，根据目前的配置确实是3个小时，如果在3个小时以内，应该是出现了什么问题，可以把邮件转给我。客户的反馈也很快，他们给我转来了最新的邮件，发现两封基本相同的邮件，时间点很近，一个是52分的时候，这个和crontab里面的配置是吻合的，另外一个是在0分的时候发送的。对于这点就有些疑惑了。带着疑问排除了本地的crontab的配置问题，开始在相关的环境中查找，因为有了方向查找起来不算太费劲，终于在一个环境中使用crontab -l找到了类似的配置。
### TRAINING ENVIRONMENT- DB SERVER FS ALERT REPORT ###
00 6,9,12,15,18,21 * * * ssh orainst@XXXX '/bin/ksh /oravl01/orainst/XXXX/FileSystem.ksh'

### TRAINING ENVIRONMENT- DB SERVER TABLE SPACE ALERT REPORT ###
00 6,9,12,15,18,21 * * * ssh orainst@XXXX '/bin/ksh /oravl01/orainst/dba/ENV/free_tbs_alert.ksh XXXXX'
这个配置的意思就是在每天的6点，9点，12点，15点，18点，21点，在0分的时候开始运行脚本并发送相应的邮件。
明白了这点问题的处理就很简单了，现在需要弄明白的是为什么这个crontab需要在其它服务器中配置而不是本地。如果需要禁用，改禁用哪个。
做了简单的沟通，最后明白，原来这里他们使用的另外一台服务器是一个类似代理的角色，其中配置着大量的crontab的设置，通过这个客户端能够控制各个服务端的一些数据运行情况，按照最初的约定，是3个小时运行一次脚本，做一次相应的检查工作。
那么为什么服务端又莫名其妙的启用了crontab设置呢，最后发现是在上周五的时候有个DBA做了一个crontab的测试，结果没有注意到已经在后台统一配置了，简单做了禁用问题就修复了。
这个简单的案例我们可以发现，很多蹊跷的问题都是事出有因，如果去追查根本的原因，不是一些配置问题就是一些相关的协调不一致导致的问题。这类问题的处理方式还是建立统一的标准和权限，就能够在一定程度上规避类似的问题了，说起来容易做起来难，还是需要慢慢改进了。