SQL> show parameter dump
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
background_core_dump string partial
background_dump_dest string /u01/app/oracle/diag/rdbms/orc
l/orcl/trace
core_dump_dest string /u01/app/oracle/diag/rdbms/orc
l/orcl/cdump
max_dump_file_size string unlimited
shadow_core_dump string partial
user_dump_dest string /u01/app/oracle/diag/rdbms/orc
l/orcl/trace
告警日志:在参数文件里对应的 Name 与 value分别是:
background_dump_dest string /u01/app/oracle/diag/rdbms/orc
l/orcl/trace
告警日志内容:
那么告警日志非常关键与重要,那么告警日志里面包含了那些内容信息呢?告警日志包含了下面一些内容的信息。像一些ORA错误,对于监控数据库有极其重要的作用。
1:所有的内部错误(ORA-600)信息,块损坏错误(ORA-1578)信息,以及死锁错误(ORA-60)信息等。
2:管理操作,例如CREATE、ALTER、DROP语句等,以及数据库启动、关闭以及日志归档的一些信息。
2.1 涉及物理结构的所有操作:例如创建、删除、重命名数据文件与联机重做日志文件的ALTER DATABASE命令,此外还涉及重新分配数据文件大小以及将数据文件联机与脱机的操作。
2.2 表空间操作,例如DROP与CREATE命令,此外还包括为了进行用户管理的备份而将表空间置入和取出热备份模式的操作
3:与共享服务器或调度进程相关功能的消息和错误信息。
4:物化视图的自动刷新过程中出现的错误。
5:动态参数的修改信息。
可以使用 tail -f 命令跟踪告警日志文件来分析原因。
ls -trl 这个命令将所有trace文件按新旧顺序排列
排序后就可以找相应的日志文件。
用户生成的trace记录文件:
user_dump_dest string /u01/app/oracle/diag/rdbms/orc
l/orcl/trace
udump中一般放置sql trace之后session的trace文件,用户服务器进程产生的跟踪文件,sql问题
关于SQL trace :
这部分来自来源网络:
DBA可以采用两种方式进行跟踪:
. 跟踪整个数据库实例。只需要简单的修改参数文件(pfile/spfile)参数 SQL_TRACE = TRUE ,然后重新启动数据库即可。在全局启用SQL_TRACE会导致所有进程的活动被跟踪,包括后台进程及所有用户进程,这样也会数据库导致性能下降比较明显。
. 会话级跟踪。SQL_TRACE的通常使用方式是仅跟踪一个会话。被跟踪的会话可以是您自己的,也可以是其它用户的会话。如果是自己的会话,只需要在SQL*PLUS中运行一下命令即可:
SQL> alter session set sql_trace = true;
类似的如果取消对会话的跟踪,运行一下命令:
SQL> alter session set sql_trace = false;
如果需要跟踪一个特定的会话,首先需要获取会话的SID和Serial#,这些信息可以在视图V$SESSION中获得,一旦知道了这两个参数,就可以运行一下命令:
SQL> execute SYS.dbms_system.set_sql_trace_in_session(13,9,true);
同样也可以使用这个过程关闭会话跟踪:
SQL> execute SYS.dbms_system.set_sql_trace_in_session(13,9,false);
--------------------------------------但是11g的话,直接利用adrci命令查看相应的日志了,很方便,不用去专门目录下了!
--------------------------------------adrci命令具体用法下一篇会讲到。