ORACLE的告警日志里面包含许多有用的信息，尤其是一些ORACLE的ORA错误信息，美国服务器，所以有必要及时归档、监控数据库告警日志的ORA错误，及时提醒数据库管理员DBA处理这些错误信息，那么我们首先来看看告警日志的内容片断：
Thread 1 advanced to log sequence 37749 (LGWR switch) Current log# 6 seq# 37749 mem# 0: /u01/oradata/SCM2/redo06.logThu Jun 27 15:02:30 2013Thread 1 advanced to log sequence 37750 (LGWR switch) Current log# 2 seq# 37750 mem# 0: /u01/oradata/SCM2/redo02.logThu Jun 27 15:13:43 2013Thread 1 advanced to log sequence 37751 (LGWR switch) Current log# 3 seq# 37751 mem# 0: /u01/oradata/SCM2/redo03.logThu Jun 27 15:25:30 2013Thread 1 advanced to log sequence 37752 (LGWR switch) Current log# 4 seq# 37752 mem# 0: /u01/oradata/SCM2/redo04.logThu Jun 27 15:32:20 2013ORA-00060: Deadlock detected. More info in file /u01/app/oracle/admin/SCM2/bdump/scm2_s001_14052.trc.Thu Jun 27 15:35:05 2013Thread 1 advanced to log sequence 37753 (LGWR switch) Current log# 5 seq# 37753 mem# 0: /u01/oradata/SCM2/redo05.logThu Jun 27 15:43:11 2013Thread 1 advanced to log sequence 37754 (LGWR switch) Current log# 1 seq# 37754 mem# 0: /u01/oradata/SCM2/redo01.logThu Jun 27 15:49:58 2013Thread 1 advanced to log sequence 37755 (LGWR switch) Current log# 6 seq# 37755 mem# 0: /u01/oradata/SCM2/redo06.logThu Jun 27 16:01:25 2013Thread 1 advanced to log sequence 37756 (LGWR switch) Current log# 2 seq# 37756 mem# 0: /u01/oradata/SCM2/redo02.logThu Jun 27 16:12:14 2013Thread 1 advanced to log sequence 37757 (LGWR switch) Current log# 3 seq# 37757 mem# 0: /u01/oradata/SCM2/redo03.logThu Jun 27 16:24:10 2013Thread 1 advanced to log sequence 37758 (LGWR switch)
View Code
归档告警日志文件
告警日志文件如果不加管理的话，那么文件会持续增长，有时候文件会变得非常大，不利于读写。一般建议将告警日志按天归档，归档文件保留三个月（视情况而定），下面来看看将告警日志文件归档的两个Shell脚本：
alert_log_archive.sh version 1
其实脚本1和脚本差别不大，仅仅是mv与cat >>的区别
alert_log_archive.sh version 2
然后在crontab定时任务里面加上下面语句，每天23点59对告警日志进行归档。
[oracle@DB-Server scripts]$ crontab -l
# the alert log archived every day Add by kerry 2013-07-02
59 23 * * * /home/oracle/scripts/alert_log_archive.sh >/dev/null 2>$1
细心的朋友可能已经发现上面的脚本、配置错误了，我在部署测试的过程中，是指定二十分钟执行一次，但是等了四十分钟，发现定时任务一次都没有执行，手工执行上面脚本是完全没有问题的，最后仔细的检查一遍，居然发现悲剧的发现时自己一时粗心将&符号写成了$,真是很二的一个错误
59 23 * * * /home/oracle/scripts/alert_log_archive.sh >/dev/null 2>$1
59 23 * * * /home/oracle/scripts/alert_log_archive.sh >/dev/null 2>&1
接下来测试发现脚本执行有问题，在crontab 里执行该shell脚本时，获取不到ORACLE的环境变量，这是因为crontab环境变量问题，Crontab的环境默认情况下并不包含系统中当前用户的环境。所以，你需要在shell脚本中添加必要的环境变量的设置，修改的脚本如下：
alert_log_archive.sh V1
alert_log_archive.sh V2
监控告警日志文件
接下来看看如何监控告警日志文件的ORA错误，这里是采用Perl结合Shell的方式，因为Shell获取错误的时间、行数等不如Perl操作字符串方便。
monitoring_alert_log.pl
monitoring_alert_log.sh
*/20 6-21 * * * /home/oracle/scripts/monitoring_alert_log.sh >/dev/null 2>&1
问题/优化脚本:Crontab 定时任务配置每二十分钟执行一次，结果，又有麻烦事情来了，假如8点发生了ORA错误，之后到下午6点都没有发生ORA错误，上面的脚本会每隔二十分钟发送一次邮件，重复发送，美国空间，感觉比较烦人，而我需要的是：只有当新的ORA错误出现，才给DBA发送邮件，否则就不要发送，其次，感觉二十分钟的时间段太长了，如果出现了严重错误，二十分钟后才去处理，就显得时延比较滞后，香港空间，但是如果你频率短的话， 基于第一个bug，你回收到N多邮件，那么我们继续改写，优化下面脚本吧
Code Snippet
但是我在部署过程中，由于环境问题（多台ORACLE服务器，不同的操作系统、不同的环境），发送邮件的部分出现改动，又有下面两个小版本的改动
Code Snippet
Code Snippet
流转的时光，都成为命途中美丽的点缀，
