使用10046 event跟蹤session

10046event是oracle用於系統性能分析時的一個最重要的事件。當激活這個事件後，將通知oracle kernel追蹤會話的相關即時信息，並寫入到相應trace文件中。這些有用的信息主要包括sql是如何進行解析，綁定變量的使用狀況，會話中發生的等 待事件等。10046event 可分紅不一樣的級別（level），分別追蹤記錄不一樣程度的有用信息。對於這些不一樣的級別，應當注意的是向下兼容的，即高一級的trace信息包含低於此級 的全部信息。

10046event的追蹤級別大體有：

level 1：跟蹤sql語句，包括解析、執行、提取、提交和回滾等。

level 4：包括變量的詳細信息

level 8：包括等待事件

level 12：包括綁定變量與等待事件

其中，level 1至關於打開了sql_trace

10046event的啓用和關閉：

前提條件：（先確保要event的會話環境符合條件）

一、必須確保timed_statistics爲TRUE，這個參數能夠在會話級上進行修改。

二、爲了確保trace輸出可以完整進行，還要調整此會話對trace文件大小的限制，通常將此限制取消，即將max_dump_file_size設置爲UNLIMITED，或者設置爲一個很大的闕值。

在知足了上述條件後，就能夠啓用10046event對會話進行後臺跟蹤了。

這裏還有幾種方式來啓用10046event：

一種是在當前會話啓用event，能夠利用alter session + 事件名稱 + level，

如：sql>alter session set event ‘10046 trace name context forever, level 12’;

另一種是啓用別的會話進行event跟蹤，能夠利用oracle提供的dbms_system來完成。

如：sql>exec dbms_system.set_ev(sid,serial#,10046,12,’’);

注意：

sql>exec dbms_system.set_sql_trace_in_session(sid,serial#,true);

至關於打開了sql_trace。

event的關閉：

能夠在經過下面的語句來關閉當前會話的event：

sql>alter session set event ‘10046 trace name context off’;

也能夠利用dbms_system包來關閉某個會話的event：

sql>execute dbms_system.set_ev(sid,serial#,0,’’);

這裏應當值得一提的是，TRACE將消耗至關的系統資源，所以咱們在使用TRACE的時候應當慎重。對於正式的系統，應當只在必要的時候進行TRACE操做，而且應當及時關閉。

當利用事件trace完當前或某個session後，接下來咱們的工做就是找到oracle生成的trace了。Oracle的初始化文件中user_dump_dest參數的設置將決定trace文件的生成位置。

從trace文件中查找和發現有用的信息，而後尋找必要的性能調整點並進行相應的調整：

大部分狀況下，經過10046事件trace到文件裏的信息包含了此會話中存在的性能問題，能夠根據trace到的等待事件、SQL語句執行狀況以及綁定變量的使用狀況來進行分析和查找。

oracle提供了一個工具tkprof來對trace文件進行格式的翻譯，以便trace文件中記錄的信息可以被咱們容易掌握和獲取。

小知識：

檢查當前會話的sql_trace狀態或級別：

SQL>set serveroutput on

2 declare i_event number;

3 begin

3 sys.dbms_system.read_ev(10046,i_event);

4 dbms_output.put_line(‘the session sql_trace level is: ‘||i_event);

5 end;

6 /

the session sql_trace level is: 12

PL/SQL 過程已成功完成。

oracle tkprof使用小結

1.chechk init.ora

timed_statistics=true

TOP查出最耗資源的PID

2.SQL> select s.sid,s.serial# from v$session s,v$process p

where s.paddr=p.addr and p.spid='17397';

3.若是須要在session級別上設置trace，能夠在sqlplus中使用下列語句：

SQL> alter session set sql_trace=true;

或者SQL> execute dbms_session.set_sql_trace(TRUE);

會話已更改。

4.若是要在PL/SQL中對session級別上設置trace，可使用dbms_session這個包：

SQL>exec dbms_system.set_sql_trace_in_session(sid，serial#,true);

PL/SQL 過程已成功完成。

5.在user_dump_dest下找到該trc文件,文件最大容量由 max_dump_file_size決定

6.使用tkprof生成相關文件,tkprof放在$ORACLE_HOME/bin目錄下，如沒法執行請檢查環境變量和PATH

tkprof erptest_ora_27576.trc session.txt explain=system/manager aggregate=yes sys=no waits=yes sort=fchela

相關說明:

sys=no：表示阻止全部以sys用戶執行的sql被顯示出來，默認爲YES

aggregate=yes|no 若用戶指定AGGREGATE=NO，TKPROF將不會對相同SQL文本的多個用戶進行彙總

waits=yes|no Record summary for any wait events found in the trace file.

CALL： 每次SQL語句的處理都分紅三個部分（Parse，Execute,Fetch）

Parse： 這步將SQL語句轉換成執行計劃，包括檢查是否有正確的受權和所須要用到的表、列以及其餘引用到的對象是否存在。

Execute： 這步是真正的由Oracle來執行語句。對於insert、update、delete操做，這步會修改數據，對於select操做,這步就只是肯定選擇的記錄。

Fetch： 返回查詢語句中所得到的記錄，這步只有select語句會被執行。

COUNT: 這個語句被parse、execute、fetch的次數。

CPU： 這個語句對於全部的parse、execute、fetch所消耗的cpu的時間，以秒爲單位。

ELAPSED： 這個語句全部消耗在parse、execute、fetch的總的時間。

DISK： 從磁盤上的數據文件中物理讀取的塊的數量。通常來講更想知道的是正在從緩存中讀取的數據而不是從磁盤上讀取的數據。

QUERY： 在一致性讀模式下，全部parse、execute、fetch所得到的buffer的數量。 一致性模式的buffer是用於給一個長時間運行的事務提供一個一致性讀的快照，緩存實際上在頭部存儲了狀態。

CURRENT：在current模式下所得到的buffer的數量。通常在current模式下執行insert、update、delete操做都會獲取 buffer。在current模式下若是在高速緩存區發現有新的緩存足夠給當前的事務使用，則這些buffer都會被讀入了緩存區中。

ROWS: 全部SQL語句返回的記錄數目，可是不包括子查詢中返回的記錄數目。對於select語句，返回記錄是在fetch這步，

對於insert、update、delete操做，返回記錄則是在execute這步。

tkprof產生出來的文件示例:

call count cpu elapsed disk query current rows

------- ------ --------

Parse 5 0.00 0.00 0 0 0 0

Execute 7 0.10 0.14 0 0 0 0

Fetch 12 0.00 0.06 5 38 0 9

------- ------ --------

total 24 0.11 0.21 5 38 0 9

問題判斷：

1. query+current/rows 平均每行所需的block數，太大的話（超過20）SQL語句效率過低

2. Parse count/Execute count parse count應儘可能接近1，若是過高的話，SQL會進行沒必要要的reparse。

要檢查Pro*C程序的MAXOPENCURSORS是否是過低了，或不適當的使用的RELEASE_CURSOR選項

3. rows Fetch/Fetch Fetch Array的大小，過小的話就沒有充分利用批量Fetch的功能，

增長了數據在客戶端和服務器之間的往返次數。在Pro*C中能夠用prefetch=NN,Java/JDBC中可調用SETROWPREFETCH,

在PL/SQL中能夠用BULK COLLECT,SQLPLUS中的arraysize(缺省是15)

4. disk/query+current 磁盤IO所佔邏輯IO的比例，太大的話有多是db_buffer_size太小(也跟SQL的具體特性有關)

5. elapsed/cpu 太大表示執行過程當中花費了大量的時間等待某種資源

6. cpuORelapsed 太大表示執行時間過長，或消耗了大量的CPU時間，應該考慮優化

7.執行計劃中的Rows 表示在該處理階段所訪問的行數，要儘可能減小