ORACLE告警日志alert过大的处理

  现在,对于我来说,处理ORACLE告警日志alert多大不再是什么难题;但是,由于数据库是公司最重要的设备,不容有失,处理数据库相关的进程或文件还是要特别小心。
 目前,ORACLE数据库主要分widows和LINUX/UNIX版本,对于LINUX/UNIX平台,我们可以使用tail -n /path/alert*.log|more来查看,很方便;但是,windows操作平台,我们遇到如下图所示那么大个的告警日志,该怎么查看。你要说直接TXT文本打开,估计是不会成功的;有人说可以上传到linux查看,那还不如当初就在linux上部署Oracle数据库。所以,过大的ORACLE告警日志是很不方便查看的,需要我们运维人员定期查看并处理。
ORACLE 告警日志alert过大的处理
 对于linux平台,处理很简单,就是echo /dev/null > /path/alert*.log,举例如下:
 首先,查看告警日志的位置:
[oracle@oradbs ~]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Thu May 19 18:09:19 2016
Copyright (c) 1982, 2011, Oracle.  All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> show parameter dump
NAME     TYPE VALUE
------------------------------------ ----------- ------------------------------
background_core_dump     string partial
background_dump_dest     string /home/oracle/oracle/diag/rdbms/oradb/oradb/trace
core_dump_dest     string /home/oracle/oracle/diag/rdbms/oradb/oradb/cdump
max_dump_file_size     string unlimited
shadow_core_dump     string partial
user_dump_dest     string /home/oracle/oracle/diag/rdbms/oradb/oradb/trace
[oracle@oradbs ~]$ ls -l /home/oracle/oracle/diag/rdbms/oradb/oradb/trace/alert*.log
-rw-r----- 1 oracle dba 94275 May 19 18:00 /home/oracle/oracle/diag/rdbms/oradb/oradb/trace/alert_oradb.log
 其次,一定要先做备份:
[oracle@oradbs ~]$ cp /home/oracle/oracle/diag/rdbms/oradb/oradb/trace/alert*.log /home/oracle/alert_bak20160607
[oracle@oradbs ~]$ ls
alert_bak20160607  oracle  oraInventory
  再次,对告警日志进行截断处理:
[oracle@oradbs ~]$ echo /dev/null > /home/oracle/oracle/diag/rdbms/oradb/oradb/trace/alert*.log
[oracle@oradbs ~]$ ls -l /home/oracle/oracle/diag/rdbms/oradb/oradb/trace/alert*.log
-rw-r----- 1 oracle dba 10 May 19 18:13 /home/oracle/oracle/diag/rdbms/oradb/oradb/trace/alert_oradb.log
处理的结果:
[oracle@oradbs ~]$ cat /home/oracle/oracle/diag/rdbms/oradb/oradb/trace/alert*.log
/dev/null
  有人怀疑,动了告警日志,数据库是不是就不在往这个告警日志写日志了,答案是不会的,我们切换redo日志看看:
[oracle@oradbs ~]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Thu May 19 18:15:49 2016
Copyright (c) 1982, 2011, Oracle.  All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> alter system switch logfile;
System altered.
SQL> 
SQL> !cat /home/oracle/oracle/diag/rdbms/oradb/oradb/trace/alert*.log
/dev/null
Thu May 19 18:15:58 2016
Thread 1 advanced to log sequence 7 (LGWR switch)
  Current log# 1 seq# 7 mem# 0: /oradata/oradb/redo01.log
Thu May 19 18:15:58 2016
Archived Log entry 4 added for thread 1 sequence 6 ID 0x9ecc00e3 dest 1:
看吧!数据库还是会写到截断的告警日志里。
 那么,widows的告警日志过大又该怎么处理呢,流程是这样的:先做备份,然后直接删除即可,当数据库发生检查点或切换redo日志时,数据库会自动创建新的告警日志。举例如下:
 查看告警日志:
C:\Users\localadmin>sqlplus sys/oracle as sysdba
SQL*Plus: Release 11.2.0.1.0 Production on 星期二 6月 7 08:59:53 2016
Copyright (c) 1982, 2010, Oracle.  All rights reserved.
连接到:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> show parameter dump
NAME                                 TYPE             VALUE
------------------------------------ ----------------------  ------------------------------
background_core_dump                 string
partial
background_dump_dest                 string
c:\oracle\diag\rdbms\oradb\ora
db\trace
core_dump_dest                       string
c:\oracle\diag\rdbms\oradb\ora
db\cdump
max_dump_file_size                   string
unlimited
shadow_core_dump                     string
none
user_dump_dest                       string
c:\oracle\diag\rdbms\oradb\ora
db\trace
SQL>
ORACLE 告警日志alert过大的处理
由于是演示,我就在trace目录进行告警日志备份了:
ORACLE 告警日志alert过大的处理
  接下来,就可以删除原来的告警日志:
ORACLE 告警日志alert过大的处理
  通过切redo日志,可以使数据库生成新的告警日志文件:
SQL> alter system switch logfile;
系统已更改。
SQL>
 ORACLE 告警日志alert过大的处理





名称栏目:ORACLE告警日志alert过大的处理
转载来于:http://ybzwz.com/article/iecjcc.html