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

PerformanceTuning筆記1 常用工具

相關文章