本文就SQL_TRACE的使用作簡單探討，並通過具體案例對sql_trace的使用進行說明.
一、 基礎介紹
(a) SQL_TRACE說明
SQL_TRACE可以作爲初始化參數在全局啓用，也可以通過命令行方式在具體session啓用。
1． 在全局啓用
在參數文件(pfile/spfile)中指定:
sql_trace =true
在全局啓用SQL_TRACE會導致所有進程的活動被跟蹤，包括後臺進程及所有用戶進程，這通常會導致比較嚴重的性能問題，所以在生產環境中要謹慎使用，這個參數在10g之後是動態參數，可以隨時調整，在某些診斷中非常有效。
提示: 通過在全局啓用sql_trace，我們可以跟蹤到所有後臺進程的活動，很多在文檔中的抽象說明，通過跟蹤文件的實時變化，我們可以清晰的看到各個進程之間的緊密協調.
2． 在當前session級設置
大多數時候我們使用sql_trace跟蹤當前進程.通過跟蹤當前進程可以發現當前操作的後臺數據庫遞歸活動(這在研究數據庫新特性時尤其有效)，
研究SQL執行，發現後臺錯誤等.
在session級啓用和停止sql_trace方式如下:
啓用當前session的跟蹤:
SQL> alter session set sql_trace=true;
Session altered.
此時的SQL操作將被跟蹤:
SQL> select count(*) from dba_users;
COUNT(*)
----------
34
結束跟蹤:
SQL> alter session set sql_trace=false;
Session altered.
3． 跟蹤其他用戶進程
在很多時候我們需要跟蹤其他用戶的進程，而不是當前用戶，這可以通過Oracle提供的系統包DBMS_SYSTEM. SET_SQL_TRACE_IN_SESSION
來完成
SET_SQL_TRACE_IN_SESSION過程序要提供三個參數:
SQL> desc dbms_system ... PROCEDURE SET_SQL_TRACE_IN_SESSION Argument Name Type In/Out Default? ------------------------------ ----------------------- ------ -------- SID NUMBER IN SERIAL# NUMBER IN SQL_TRACE BOOLEAN IN ...
通過v$session我們可以獲得sid、serial#等信息:
獲得進程信息，選擇需要跟蹤的進程:
SQL> select sid,serial#,username from v$session
2 where username is not null;
SID SERIAL# USERNAME
---------- ---------- ------------------------------
8 2041 SYS
9 437 EYGLE
設置跟蹤:
SQL> exec dbms_system.set_sql_trace_in_session(9,437,true)
PL/SQL procedure successfully completed.
....
可以等候片刻，跟蹤session執行任務,捕獲sql操作...
....
停止跟蹤:
SQL> exec dbms_system.set_sql_trace_in_session(9,437,false)
PL/SQL procedure successfully completed.
(b) 10046事件說明
10046事件是Oracle提供的內部事件，是對SQL_TRACE的增強.
10046事件可以設置以下四個級別:
1 - 啓用標準的SQL_TRACE功能,等價於sql_trace
4 - Level 1 加上綁定值(bind values)
8 - Level 1 + 等待事件跟蹤
12 - Level 1 + Level 4 + Level 8
類似sql_trace，10046事件可以在全局設置，也可以在session級設置。
1． 在全局設置
在參數文件中增加:
event="10046 trace name context forever,level 12"
此設置對所有用戶的所有進程生效、包括後臺進程.
2． 對當前session設置
通過alter session的方式修改，需要alter session的系統權限:
SQL> alter session set events '10046 trace name context forever';
Session altered.
SQL> alter session set events '10046 trace name context forever, level 8';
Session altered.
SQL> alter session set events '10046 trace name context off';
Session altered.
3． 對其他用戶session設置
通過DBMS_SYSTEM.SET_EV系統包來實現:
SQL> desc dbms_system ... PROCEDURE SET_EV Argument Name Type In/Out Default? ------------------------------ ----------------------- ------ -------- SI BINARY_INTEGER IN SE BINARY_INTEGER IN EV BINARY_INTEGER IN LE BINARY_INTEGER IN NM VARCHAR2 IN ... 其中的參數SI、SE來自v$session視圖: 查詢獲得需要跟蹤的session信息: SQL> select sid,serial#,username from v$session where username is not null;
SID SERIAL# USERNAME
---------- ---------- ------------------------------
8 2041 SYS
9 437 EYGLE
執行跟蹤:
SQL> exec dbms_system.set_ev(9,437,10046,8,'eygle');
PL/SQL procedure successfully completed.
結束跟蹤:
SQL> exec dbms_system.set_ev(9,437,10046,0,'eygle');
PL/SQL procedure successfully completed.
(c) 獲取跟蹤文件
以上生成的跟蹤文件位於user_dump_dest目錄中，位置及文件名可以通過以下SQL查詢獲得:
SQL> select
2 d.value||'/'||lower(rtrim(i.instance, chr(0)))||'_ora_'||p.spid||'.trc' trace_file_name 3 from 4 ( select p.spid 5 from sys.v$mystat m,sys.v$session s,sys.v$process p 6 where m.statistic# = 1 and s.sid = m.sid and p.addr = s.paddr) p, 7 ( select t.instance from sys.v$thread t,sys.v$parameter v 8 where v.name = 'thread' and (v.value = 0 or t.thread# = to_number(v.value))) i, 9 ( select value from sys.v$parameter where name = 'user_dump_dest') d 10 /TRACE_FILE_NAME
--------------------------------------------------------------------------------
/opt/oracle/admin/hsjf/udump/hsjf_ora_1026.trc
(d) 讀取當前session設置的參數
當我們通過alter session的方式設置了sql_trace,這個設置是不能通過show parameter的方式得到的,我們需要通過dbms_system.read_ev來獲取：
SQL> set feedback off
SQL> set serveroutput onSQL> declare
2 event_level number;
3 begin
4 for event_number in 10000..10999 loop
5 sys.dbms_system.read_ev(event_number, event_level);
6 if (event_level > 0) then
7 sys.dbms_output.put_line(
8 'Event ' ||
9 to_char(event_number) ||
10 ' is set at level ' ||
11 to_char(event_level)
12 );
13 end if;
14 end loop;
15 end;
16 /
Event 10046 is set at level 1
四、如何反跟蹤
有時候，我們不希望自己的sql被人跟蹤。比如，我們不希望別人能看到我們程序中寫的sql。方法有很多，這裏介紹一種簡單的方法。思路就是：強迫SQLServer停止跟蹤。具體存儲過程如下：
名稱：[DBO].[Performance_Trace_StopAll]
功能：防止反跟蹤
作者：junling
創建時間：2011-02-09
項目名稱：XXXX
歷史記錄：
編號 日期 作者 備註
1.0 2011-02-09 junling 創建
代碼的執行過程如下：
- create proc [dbo].[Performance_Trace_StopAll]
- AS
- declare traceCursor cursor for select id from sys.traces where id <> 1
- open traceCursor
- declare @curid int
- fetch next from traceCursor into @curid
- while(@@fetch_status=0)
- begin
- exec sp_trace_setstatus @curid,0
- exec sp_trace_setstatus @curid,2
- fetch next from traceCursor into @curid
- end
- close traceCursor
- deallocate traceCursor
具體什麼時候調用，就是看你具體的情況了。
五、SQL Trace跟蹤原則
這裏主要列出我們在跟蹤時應該注意的事項，或者說按照下面的原則會降低跟蹤對生產環境的影響。
1、不要使用Profiler GUI跟蹤，如果使用了儘量不要運行在跟蹤的SQLServer所在服務器；
2、不要把跟蹤數據直接寫入表，我們可以採用系統不是很繁忙時才把跟蹤信息導入表中（除非你想立刻分析數據）；
3、跟蹤會有大量的I/O操作，儘量把跟蹤文件單獨放在物理磁盤中；
4、只選擇自己感興趣的事件，多選一個事件都會帶來開銷（除非你多選的事件不發生，那樣也就沒有選擇的必要；
5、過濾你的跟蹤信息，比如你只對某數據庫感興趣，你只對某些列感興趣（注意這裏僅僅是減少了架構圖中的I/O提供者的開銷，想想爲什麼）；
6、像XXXXXXStarting之類的事件往往沒有太大意義；
7、要注意你跟蹤的sql中是否使用了標量函數，對這些sql的跟蹤會嚴重影響性能，每個標量函數每處理一行都會觸發事件（如果表很大，這是件很恐怖的事件)；
8、只給需要跟蹤的用戶指定跟蹤權限。