本文主要是介绍熟练使用alert.log日志，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
熟练使用alert.log日志
1）、日志存放的位置：$ORACLE_BASE/admin/SID/bdump/alert_sid.log
⊙ 定期检查警报日志文件存入的内容，其中包括：检查内部错误（ORA-600）和块损坏信息
2）、alert.log文件包含以下可以用于数据库调试的信息：
检查点启动和结束的时间
因为检查点时，会关联ＬＧＷＲ写、ＤＢＷＲ写、ＡＲＣＨ写，一旦ＬＧＷＲ写、ＡＲＣＨ过于快，而ＣＫＰＴ过于慢，就会跟不上，就会造成检查点未完成。需要设置LOG_CHECKPOINTS_TO_ALERT才可以很清楚的了解检查点频率。
设置了后，从告警日志中发现检查点发生的时间、目标RBA的地址及目标SCN、检查点完成时间
SQL> alter system set log_checkpoints_to_alert=true scope=both; 默认为FALSE
Beginning log switch checkpoint up to RBA [0x3d.2.10], SCN: 1776415 --开启之后会多这么一行
Thread 1 advanced to log sequence 61
Current log# 3 seq# 61 mem# 0: /oracle/app/oracle/oradata/orcl/redo03.log
Completed checkpoint up to RBA [0x3d.2.10], SCN: 1776415
未完成的检查点
通常检查点的速度赶不上日志写或者DBWR写时，会提示检查点未完成，不允许覆盖该日志。在一些事务量比较大的OLTP系统 可能都会遇到
执行归档的时间
可以通过这个时间结合未完成的检查点来判断日志文件大小是否合理。日志过小，可能会造成日志切换过于频繁
实例恢复开始和完成的时间
Beginning crash recovery of 1 threads
Thu Mar 21 00:28:11 2013
Started redo scan
Thu Mar 21 00:28:11 2013
Completed redo scan
74 redo blocks read, 38 data blocks need recovery
Thu Mar 21 00:28:11 2013
Started redo application at
Thread 1: logseq 55, block 44383
Thu Mar 21 00:28:11 2013
Recovery of Online Redo Log: Thread 1 Group 3 Seq 55 Reading mem 0
Mem# 0 errs 0: /oracle/app/oracle/oradata/orcl/redo03.log
Thu Mar 21 00:28:11 2013
Completed redo application
Thu Mar 21 00:28:12 2013
Completed crash recovery at Thread 1: logseq 55, block 44457, scn 1776051
死锁和超时错误
死锁的信息 也会出现在alert.log里
Oracle服务器将有关后台进程的错误检测信息写入跟踪文件。
Oracle支持使用这些跟踪文件来诊断和错误处理。
这篇关于熟练使用alert.log日志的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
