今天下午的時候客戶發郵件反饋說，對於某個環境中的檔案系統監控和表空間使用情況的郵件收到的比較頻繁，感覺是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的測試，結果沒有注意到已經在後臺統一配置了，簡單做了禁用問題就修復了。 這個簡單的案例我們可以發現，很多蹊蹺的問題都是事出有因，如果去追查根本的原因，不是一些配置問題就是一些相關的協調不一致導致的問題。這類問題的處理方式還是建立統一的標準和許可權，就能夠在一定程度上規避類似的問題了，說起來容易做起來難，還是需要慢慢改進了。