ORACLE告警日志文件
告警日志介绍
告警日志文件是一类特殊的跟踪文件（trace file）。告警日志文件命名一般为alert_<SID>.log，其中SID为ORACLE数据库实例名称。数据库告警日志是按时间顺序记录message和错误信息。
告警日志位置
在ORACLE 10g中，BACKGROUND_DUMP_DEST参数确定了告警日志的位置，但是告警日志的文件名无法修改，告警日志的名称为：alert_<SID>.log,其中<SID>是实例的名称。BACKGROUND_DUMP_DEST参数是动态的。
sql>showparameterbackground_dump_dest;
NAMETYPEVALUE
--------------------------------------------------------------
background_dump_deststring/u01/app/oracle/admin/GSP/bdump
sql>
告警日志以及所有后台跟踪文件都会被写至BACKGROUND_DUMP_DEST参数所指定的目录。
在ORACLE 11g 以及ORACLE 12c中，告警日志文件的位置有了变化。主要是因为引入了ADR(Automatic Diagnostic Repository:一个存放数据库诊断日志、跟踪文件的目录)，关于ADR对应的目录位置可以通过查看v$diag_info系统视图。如下所示（ORACLE 12c ）
sql>select*fromv$diag_info;
INST_IDNAMEVALUECON_ID
------------------------------------------------------------------------------------
1DiagEnabledTRUE0
1ADRBase/u01/app/oracle0
1ADRHome/u01/app/oracle/diag/rdbms/ignite/epps0
1DiagTrace/u01/app/oracle/diag/rdbms/ignite/epps/trace0
1DiagAlert/u01/app/oracle/diag/rdbms/ignite/epps/alert0
1DiagIncident/u01/app/oracle/diag/rdbms/ignite/epps/incident0
1DiagCdump/u01/app/oracle/diag/rdbms/ignite/epps/cdump0
1HealthMonitor/u01/app/oracle/diag/rdbms/ignite/epps/hm0
1DefaultTraceFile/u01/app/oracle/diag/rdbms/ignite/epps/trace/epps_0
ora_13810.trc
1ActiveProblemCount00
1ActiveIncidentCoun00
t
11rowsselected.
如上所示，Diag Trace对应的目录为文本格式的告警日志文件所在的目录,而Diag Alert对应的目录为XML格式的警告日志(对应为log_x.xml)
[oracle@gettestlnx01trace]$pwd
/u01/app/oracle/diag/rdbms/ignite/epps/trace
[oracle@gettestlnx01trace]$lsalert_epps.log
alert_epps.log
[oracle@gettestlnx01trace]$cd../alert/
[oracle@gettestlnx01alert]$pwd
/u01/app/oracle/diag/rdbms/ignite/epps/alert
[oracle@gettestlnx01alert]$ls
log_1.xmllog_2.xmllog_3.xmllog_4.xmllog_5.xmllog_6.xmllog_7.xmllog_8.xmllog_9.xmllog.xml
告警日志内容：
那么告警日志非常关键与重要，那么告警日志里面包含了那些内容信息呢？告警日志包含了下面一些内容的信息。像一些ORA错误，对于监控数据库有极其重要的作用。
1：所有的内部错误（ORA-600）信息，块损坏错误（ORA-1578）信息，以及死锁错误（ORA-60）信息等。
2：管理操作，例如CREATE、ALTER、DROP语句等，以及数据库启动、关闭以及日志归档的一些信息。
2.1 涉及物理结构的所有操作：例如创建、删除、重命名数据文件与联机重做日志文件的ALTER DATABASE命令，此外还涉及重新分配数据文件大小以及将数据文件联机与脱机的操作。
2.2 表空间操作，例如DROP与CREATE命令，此外还包括为了进行用户管理的备份而将表空间置入和取出热备份模式的操作
5：动态参数的修改信息。
告警日志监控：
既然告警日志如此重要，而我们也不可能随时手工去查看告警日志文件，那么我们就必须监控告警日志，那么监控告警日志有哪些方案呢？下面归纳一下
方案1：Tom大师给出的一个方案(仅适用于ORACLE 10g)，将告警日志文件信息读入全局临时表，然后我们就可以定制一些sql语句查询告警日志的信息。
createglobaltemporarytablealert_log
(lineintprimarykey,
textvarchar2(4000)
)
oncommitpreserverows
/
createorreplaceprocedureload_alert
as
l_background_dump_destv$parameter.value%type;
l_filenamevarchar2(255);
l_bfilebfile;
l_lastnumber;
l_currentnumber;
l_startnumber:=dbms_utility.get_time;
begin
selecta.value,'alert_'||b.instance||'.log'
intol_background_dump_dest,l_filename
fromv$parametera,v$threadb
wherea.name='background_dump_dest';
executeimmediate
'createorreplacedirectoryx$alert_log$xas
'''||l_background_dump_dest||'''';
dbms_output.put_line(l_background_dump_dest);
dbms_output.put_line(l_filename);
deletefromalert_log;
l_bfile:=bfilename('X$ALERT_LOG$X',l_filename);
dbms_lob.fileopen(l_bfile);
l_last:=1;
forl_linein1..50000
loop
dbms_application_info.set_client_info(l_line||','||
to_char(round((dbms_utility.get_time-l_start)/100,2))
||',monospace;border-top-style:none;color:#000000;font-size:12pt;border-left-style:none;padding-top:0px;">to_char((dbms_utility.get_time-l_start)/l_line)
);
l_current:=dbms_lob.instr(l_bfile,'0A',l_last,1);
exitwhen(nvl(l_current,0)=0);
insertintoalert_log
(line,text)
values
(l_line,
utl_raw.cast_to_varchar2(
dbms_lob.substr(l_bfile,l_current-l_last+1,monospace;border-top-style:none;color:#000000;font-size:12pt;border-left-style:none;padding-top:0px;">l_last))
l_last:=l_current+1;
endloop;
dbms_lob.fileclose(l_bfile);
end;
/
但是这又一个问题，如果数据库宕机了的情况下，是无法获取这些错误信息，比方案3（从操作系统监控告警日志）对比，有些特定场景不适用。另外有一定不足之处，就是日志文件比较大的时候，监控告警日志信息比较频繁的时候，会产生不必要的IO操作。
方案2：通过外部表来查看告警日志文件的内容。相当的方便。然后也是使用定制sql语句来查询错误信息。
sql>createorreplacedirectorybdumpas'/u01/app/oracle/admin/GSP/bdump';
Directorycreated.
sql>createtablealert_logs
2(
3textvarchar2(2000)
4)
5organizationexternal
6(
7typeoracle_loader
8defaultdirectorybdump
9accessparameters
10(
11recordsdelimitedbynewline
12fields
13rejectrowswithallnullfields
14)
15location
16(
17'alert_GSP.log'
18)
19)
20rejectlimitunlimited;
Tablecreated.
sql>select*fromalert_logs;
TEXT
--------------------------------------------------------------------------------
ThuAug714:50:282014
Thread1advancedtologsequence14
Currentlog#1seq#14mem#0:/u01/app/oracle/oradata/GSP/redo01.log
sql>
方案3：我以前一篇博客归档―监控ORACLE数据库告警日志里面介绍了如何对告警日志进行归档、监控。这些脚本也确实很有效的替我监控着数据库的运行。
告警日志归档
告警日志如果不及时归档，时间长了，告警日志文件会变得非常大，查看、读取告警日志会引起额外的IO开销。所以一般应该按天归档告警日志文件，保留一段时间（例如 90天），超过规定时间的删除。
告警日志是否可以删除呢？ 以前有位同事说background_dump_dest目录下的跟踪文件除了告警日志外都能删除，如果删除告警日志文件有可能会产生意想不到的错误，我半信半疑，在测试服务器删除告警日志，验证后发现没有什么影响，系统会重新生成告警日志文件（时间上不会立即生成告警日志文件，而是当进程向告警日志写入记录时就会生成新的告警日志文件）。
原文链接：https://www.f2er.com/oracle/208956.html