您的位置：首页 > 数据库 > Oracle

ORACLE告警日志文件

2016-06-08 16:50 357 查看
告警日志介绍
 
告警日志文件是一类特殊的跟踪文件（tracefile）。告警日志文件命名一般为alert_<SID>.log，其中SID为ORACLE数据库实例名称。数据库告警日志是按时间顺序记录message和错误信息。
 
告警日志位置
在ORACLE10g中，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参数所指定的目录。
在ORACLE11g以及ORACLE12c中，告警日志文件的位置有了变化。主要是因为引入了ADR(AutomaticDiagnosticRepository:一个存放数据库诊断日志、跟踪文件的目录)，关于ADR对应的目录位置可以通过查看v$diag_info系统视图。如下所示（ORACLE12c）

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.





如上所示，DiagTrace对应的目录为文本格式的告警日志文件所在的目录,而DiagAlert对应的目录为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涉及物理结构的所有操作：例如创建、删除、重命名数据文件与联机重做日志文件的ALTERDATABASE命令，此外还涉及重新分配数据文件大小以及将数据文件联机与脱机的操作。
       2.2表空间操作，例如DROP与CREATE命令，此外还包括为了进行用户管理的备份而将表空间置入和取出热备份模式的操作
3：与共享服务器或调度进程相关功能的消息和错误信息。
4：物化视图的自动刷新过程中出现的错误。
5：动态参数的修改信息。
 
告警日志监控：
既然告警日志如此重要，而我们也不可能随时手工去查看告警日志文件，那么我们就必须监控告警日志，那么监控告警日志有哪些方案呢？下面归纳一下
方案1：Tom大师给出的一个方案(仅适用于ORACLE10g)，将告警日志文件信息读入全局临时表，然后我们就可以定制一些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))


||','||


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,


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://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1352202934074

作者：潇湘隐者
出处：http://www.cnblogs.com/kerrycode/
                                            

                                        

                        
                        内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 点击这里给我发消息 
                    

                    

                    

                        

                         标签： 
                                                

                        

                    


                

            


            

                
相关文章推荐

                

                
            

        

        

            

            
            

                

                    
新的分享

                    

                        
                    

                

            


            

                

                    
章节导航