如果一個系統的執行效率比較低，一個比較好的方法是通過跟蹤使用者的會話並且使用tkprof工具使用排序功能格式化輸出，從而找出有問題的SQL語句。
例如首先從os上利用top命令找到當前佔用cpu資源最高的一個程序的PID號9999；
然後在資料庫中根據PID號找到相應的sid和serial#
select s.sid,s.serial# from v$session s,v$process p where s.paddr=p.addr and p.spid='9999';
然後通過exec dbms_monitor.session_trace_enable(sid,serial#)開啟trace；
最後利用tkprof察看trace輸出。

開啟Trace檔案輸出
可以通過以下方法開啟Trace檔案輸出（需要ALTER SESSION系統許可權）:
1) alter session/system set sql_trace=true
2) exec dbms_monitor.session_trace_enable/dbms_monitor.database_trace_enable
3) alter session set events '10046 trace name context forever, level 12'

Trace檔案的位置
· 如果使用專用伺服器連線，會在USER_DUMP_DEST引數指定的目錄中生成跟蹤檔案。
· 如果使用共享伺服器連線，則在BACKGROUND_DUMP_DEST引數指定的目錄中生成跟蹤檔案。
關於專用伺服器/共享伺服器->

http://blog.csdn.net/fw0124/article/details/6898693

對於DEDICATED方式，Oracle11g之前，可以通過如下語句獲得Trace檔案路徑：
select c.value || '/' || d.instance_name || '_ora_' || a.spid || '.trc' trace
  from v$process a, v$session b, v$parameter c, v$instance d
 where a.addr = b.paddr
   and b.audsid = userenv('sessionid')
   and c.name = 'user_dump_dest'；
Oracle11g之後，可以訪問v$diag_info來獲得Trace檔案存放路徑：
select * from v$diag_info where name='Default Trace File';

可以使用引數TRACEFILE_IDENTIFIER，為跟蹤檔名增加一個可以惟一標識的串。例如：
alter session set tracefile_identifier='my_trace_file';
這樣，生成的Trace檔名就會以my_trace_file.trc結尾。

共享伺服器模式下，或者需要跟蹤某些特定客戶端，可以使用DBMS_MONITOR.CLIENT_ID_TRACE_ENABLE。方法是：
a) sqlplus登陸，exec DBMS_MONITOR.CLIENT_ID_TRACE_ENABLE('mytest');
這裡mytest是客戶端標示符。
*可以通過select * from DBA_ENABLED_TRACES;檢視當前的活動trace。
b) 需要被跟蹤的客戶端連線執行exec DBMS_SESSION.SET_IDENTIFIER ('mytest');
c) 不需要跟蹤的時候可以sqlplus登陸，執行exec DBMS_MONITOR.CLIENT_ID_TRACE_DISABLE('mytest');
d) 到USER_DUMP_DEST目錄下執行trcsess output=mytest_trc.txt clientid=mytest，會自動合併各個會話的trace檔案，生成mytest_trc.txt 
e) 利用tkprof來生成分析報告。

利用tkprof工具分析Trace檔案
可以利用tkprof工具分析Trace檔案，產生一個更加清晰合理的輸出結果。tkprof可以在$ORACLE_HOME/bin下面找到。

1）命令格式
命令格式為：
tkprof tracefile outputfile [explain= ] [table= ] [print= ] [insert= ] [sys= ] [sort= ]
引數說明：
tracefile：要分析的trace檔案 
outputfile：格式化後的檔案
explain=user/[email protected] 
table=schema.tablename 
    上述兩個引數是一起使用的，explain指示tkprof要為在跟蹤檔案中找到的每個SQL語句提供一個執行計劃。
    這是通過執行SQL語句EXPLAIN PLAN通過連線資料庫對在trace檔案中出現的每條sql語句檢視執行計劃，並將之輸出到outputfile中。
    指定的table名將提供給EXPLAIN PLAN語句。
print=n：只列出最初N個sql執行語句，預設是無限制的，只有在和引數sort一起使用的時候才有意義
insert=filename：會產生一個sql檔案，執行此檔案可將收集到的資料insert到資料庫表中
sys=no：sys使用者執行的SQL語句(例如，解析操作階段對資料字典的遞迴查詢)不輸出到輸出檔案中。
record=filename：可將非巢狀執行的sql語句過濾到指定的檔案中去 
waits=yes|no：是否統計任何等待事件，預設是yes 
aggregate=yes|no：是否將相同sql語句的執行資訊合計起來，預設為yes 
sort= option：設定排序選項，可以用逗號分隔多個選項。預設是跟蹤檔案中發現的SQL順序。具體選項可以檢視tkprof的命令幫助輸出得到。

例如：
tkprof <tracefile> <outputfile> sys=no sort=prsela,exeela,fchela
    prsela  elapsed time parsing
    exeela  elapsed time executing
    fchela  elapsed time fetching

2）輸出結果格式
輸出結果中，首先是頭部內容。
之後針對每個SQL語句提供如下資訊：SQL 語句文字、執行統計、關於解析的資訊、執行計劃以及等待事件。
執行計劃以及等待事件是可選的，只有儲存在跟蹤檔案中才會出現。
例如下面的輸出：
********************************************************************************

SQL ID: 0c07h414zr55p
Plan Hash: 1968341081
update emp set sal=2451 
where
 empno=7782

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        2      0.01       0.00          0          0          0           0
Execute      2      0.00       3.71          0          3          7           2
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        4      0.01       3.72          0          3          7           2

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 86  (TONY)

Rows     Row Source Operation
-------  ---------------------------------------------------
      0  UPDATE  EMP (cr=1 pr=0 pw=0 time=0 us)
      1   INDEX UNIQUE SCAN EMP_PK (cr=1 pr=0 pw=0 time=0 us cost=0 size=26 card=1)(object id 73464)

Rows     Execution Plan
-------  ---------------------------------------------------
      0  UPDATE STATEMENT   MODE: ALL_ROWS
      0   UPDATE OF 'EMP'
      1    INDEX   MODE: ANALYZED (UNIQUE SCAN) OF 'EMP_PK' (INDEX 
               (UNIQUE))

********************************************************************************

執行統計有如下的幾列：
count：表示執行的資料庫呼叫數量。
cpu：表示處理資料呼叫花去的CPU時間，以秒為單位。
elapsed：是處理資料庫呼叫花費的總的時間，以秒為單位，如果這個值比CPU時間高，下一節關於執行統計中的等待事件會提供在等待的資源或同步點。
disk：表示物理讀的資料塊數量。要當心，這不是物理I/O操作的數量，物理I/O運算元在關於等待事件一節給出。如果這個值大於邏輯讀的數量(disk > query +current)，這意味著資料塊填充進了臨時表空間。
query：是在一致性模式（consistent mode）下從快取記憶體邏輯讀取的塊數量。通常，這型別的邏輯讀用作查詢。 
current：代表在當前模式下從快取記憶體邏輯讀取的塊數量。通常，這類邏輯讀被INSERT、DELETE、MERGE以及UPDATE等語句所使用。
rows：代表處理的資料行數量。對於查詢來說，這就是獲取的行數量。對於INSERT、DELETE、MERGE以及UPDATE 等語句來說，這是所影響的行數量。

關於解析的資訊開始兩行Misses in library cache during parse和Misses in library cache during execute提供了發生在解析和執行呼叫階段的硬解析數量。
如果在執行呼叫時沒有硬解析發生，Misses in library cache during execute這一行將不存在。
接下來是優化器模式以及用於解析SQL語句的使用者。

執行計劃分為兩部分，第一部分稱為行源操作(Row Source Operation )，是遊標關閉且開啟跟蹤情況下寫到跟蹤檔案中的執行計劃。這意味著如果應用程式不關閉遊標而重用它們的話，不會有新的針對重用遊標的執行計劃寫入到跟蹤檔案中。第二部分，叫做執行計劃 (Execution Plan)，是由指定了explain引數的TKPROF生成的。既然這是隨後生成的，所以和第一部分不一定完全匹配。萬一你看到不一致，前者是正確的。
兩個執行計劃都通過Rows列提供執行計劃中每個操作返回的行數（不是處理的--要注意）。 
對於每個行源操作來說，可能還會提供如下的執行時統計： 
cr是一致性模式下邏輯讀出的資料塊數。
pr是從磁碟物理讀出的資料塊數。
pw是物理寫入磁碟的資料塊數。
time是以微秒錶示的總的消逝時間。要注意根據統計得到的值不總是精確的。實際上，為了減少開銷，可能用了取樣。
cost是操作的評估開銷。這個值只有在Oracle 11g才提供。
size是操作返回的預估資料量(位元組數)。這個值只有在Oracle 11g才提供。 
card是操作返回的預估行數。這個值只有在Oracle 11g才提供。

輸出檔案的結尾給出了所有關於跟蹤檔案的資訊。首先可以看到跟蹤檔名稱、版本號、用於這個分析所使用的引數sort的值。然後，給出了所有會話數量與SQL語句數量。