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命令具體用法下一篇會講到。