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