1,出问题首先看日志

作为DBA每天必须查看该文件来及时发现问题
tail -100 alert_.log

错误日志的位置
SQL> show parameter dump

background_dump_dest代表错误日志

2,在错误日志中查找ORA报错
vi alert_.log

/ORA- 回车

尤其关注ORA-600、block corruption等错误

3，定期清除alert日志
错误日志会随着时间增长一直增大，可以适当的清除历史数据缩小日志文件
cat /dev/null > alert_.log

4, alert日志中的关注点
4.1 checkpoint的开始时间和结束时间

SQL> alter system set log_checkpoints_to_alert=true scope=spfile;

在告警日志中的提示信息
tial -100 alert_log
Mon Nov 03 20:04:06 2014
ALTER SYSTEM SET log_checkpoints_to_alert=TRUE SCOPE=SPFILE;

4.2 实例启动和停止的时间
4.3 归档日志的频率。
如果过于频繁可以适当增大redo log的大小减少切换的频率来提供性能。
4.4 deadlock 和 timeout错误

5, 后台trace 文件
trace文件和进程相关。当后台进程出现错误会将信息写入trace文件。

6，用户trace文件
user_dump_dest

select sid,serial#,username from v$session;

其中serial#=1的进程是数据库的后台进程。

6.1 为当前用户生成trace文件
SQL> alter session set sql_trace=true;
该命令执行后会在/u01/diag/rdbms/practice/practice/trace下生成用户trace文件。
文件名practice_ora_25911.trc中的25911是该进程的PID

$ ls
alert_practice.log practice_ora_25911.trc practice_ora_25911.trm

6.2 系统用户调用包创建用户trace文件

SYS@PROD1 > select sid,serial#,username from v$session;

       SID    SERIAL# USERNAME
---------- ---------- ------------------------------
        59        685
        60        393
        61        225 OGGADMIN
        62        157 OGGADMIN
        63        315
        65        339 OGGADMIN
        66        865 OGGADMIN
        67        449
        68        659 OGGADMIN
        69         63
        70         87 SYS

       SID    SERIAL# USERNAME
---------- ---------- ------------------------------
        72         19

SYS@PROD1 > execute dbms_system.set_sql_trace_in_session(68,659,true);

[oracle@node3 trace]$ pwd
/u01/app/oracle/diag/rdbms/prod/PROD1/trace
[oracle@node3 trace]$ ll
total 252
-rw-r----- 1 oracle asmadmin 244136 Nov 3 16:06 alert_PROD1.log
-rw-r----- 1 oracle asmadmin   1607 Nov 3 16:06 PROD1_dbrm_6496.trc
-rw-r----- 1 oracle asmadmin     69 Nov 3 16:06 PROD1_dbrm_6496.trm

ITPub博客

PerformanceTuning笔记1 常用工具

最新文章