SQL性能優化跟蹤以及分析
【1】在未執行SQL的時候，應該先對SQL進行預先分析，一般分析是看執行計劃（查看是否走索引，驅動表的連接方式等），查看執行計劃方式：
①：SQL Development 的F5鍵
②：explain plan for select from xxx where xxx;
select from table(dbms_xplan.display);
其中①等價於②，是優化器通過讀取數據字典的統計信息做出最佳的執行方法。
【2】如果要獲取SQL執行的所有分析結果（分析時間，執行時間，邏輯讀等），可已通過以下幾種方法：
o SET AUOTRACE
SET AUOTRACE 詳細用法如下：
https://blog.csdn.net/seven_tt/article/details/3409141
o alter session set events '10046 trace name context forever, level 12' ；
o DBMS_XPLAN.DISPLAY_COURSOR /DBMS_XPLAN.DISPLAY_AWR
o 查詢V$SQL_PLAN
【3】[重要]如果覺得系統執行效率比較低，一個比較好的方法是通過跟蹤用戶的會話並且使用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
3) alter session set events '10046 trace name context forever, level 12' ;
{ --多條sql等級爲level12的信息輸出到trac文件中}
收集一段時間後，記得關閉trace,因爲消耗性能。
exec dbms_monitor.session_trace_disable(sid,serial#);
alter session set events '10046 trace name context off';
---這裏涉及oracle dump轉儲知識，可以參考以下資料：
https://www.cnblogs.com/einyboy/archive/2012/06/26/2563838.html
Trace文件的位置
· 如果使用專用服務器連接，會在USER_DUMP_DEST參數指定的目錄中生成跟蹤文件。
· 如果使用共享服務器連接，則在BACKGROUND_DUMP_DEST參數指定的目錄中生成跟蹤文件。
關於專用服務器/共享服務器->http://blog.csdn.net/fw0124/article/details/6898693
可以使用參數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/password@connectstring
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語句數量。