一、識別占用資源較多的語句的方法（4種方法）
1.測試組和最終用戶反饋的與反應緩慢有關的問題。
2.利用V_$SQLAREA視圖提供了執行的細節。（執行、讀取磁盤和讀取緩沖區的次數）
•數據列
EXECUTIONS：執行次數
DISK_READS：讀盤次數
COMMAND_TYPE：命令類型（3:select,2:insert;6:update;7delete;47:pl/sql程序單元）
OPTIMIZER_MODE：優化方式
SQL_TEXT：Sql語句
SHARABLE_MEM：占用shared pool的內存多少
BUFFER_GETS：讀取緩沖區的次數
•用途
1、幫忙找出性能較差的SQL語句
2、幫忙找出最高頻率的SQL
3、幫忙分析是否需要索引或改善聯接
3.監控當前Oracle的session，如出現時鐘的標志，表示此進程中的sql運行時間較長。
4.Trace工具：
a)查看數據庫服務的初始參數：timed_statistics、user_dump_dest和max_dump_file_size
b)Step 1: alter session set sql_trace=true
c)Step 2: run sql；
d)Step 3: alter session set sql_trace=false
e)Step 4:使用 “TKPROF”轉換跟蹤文件
f)Parse，解析數量大通常表明需要增加數據庫服務器的共享池大小，
query或current提取數量大表明如果沒有索引，語句可能會運行得更有效，
disk提取數量表明索引有可能改進性能，
library cache中多於一次的錯過表明需要一個更大的共享池大小
二、如何管理語句處理和選項
•基於成本（Cost Based） 和基於規則（Rule Based） 兩種優化器， 簡稱為CBO 和RBO
•Optimizer Mode參數值:
Choose：如果存在訪問過的任何表的統計數據 ，則使用基於成本的Optimizer,目標是獲得最優的通過量。如果一些表沒有統計數據，則使用估計值。如果沒有可用的統計數據，則將使用基於規則的Optimizer
All_rows：總是使用基於成本的Optimizer，目標是獲得最優的通過量
First_rows_n：總是使用基於成本的Optimizer，目標是對返回前N行（“n”可以是1，10，100或者1000）獲得最優的響應時間
First_rows：用於向後兼容。使用成本與試探性方法的結合，以便快速傳遞前幾行
RULE：總是使用基於規則的Optimizer
三、使用數據庫特性來獲得有助於查看性能的處理統計信息（解釋計劃和AUTOTRACE）
No1: Explain Plan
A）使用Explain工具需要創建Explain_plan表，這必須先進入相關應用表、視圖和索引的所有者的帳戶內. (@D:Oracleora92 dbmsadminutlxplan)
B）表結構：
STATEMENT_ID：為一條指定的SQL語句確定特定的執行計劃名稱。如果在EXPLAN PLAN語句中沒有使用SET STATEMENT_ID，那麼此值會被設為NULL。
OperaTION：在計劃的某一步驟執行的操作名稱，例如：Filters，Index，Table，Marge Joins and Table等。
OPTION：對OPERATION操作的補充，例如：對一個表的操作，OperaTION可能是TABLE Access，但OPTION可能為by ROWID或FULL。
Object_Owner：擁有此database Object的Schema名或Oracle帳戶名。
Object_name：Database Object名
Object_type：類型，例如：表、視圖、索引等等
ID：指明某一步驟在執行計劃中的位置。
PARENT_ID：指明從某一操作中取得信息的前一個操作。通過對與ID和PARENT_ID使用Connect By操作，我們可以查詢整個執行計劃樹。
C）EXPLAIN搜索路徑解釋
•全表掃描（Full Table Scans）(無可用索引,大量數據,小表 ,全表掃描hints,HWM(High Water Mark), Rowid掃描)
•索引掃描
索引唯一掃描（Index Unique Scans）
索引范圍掃描（Index Range Scans）
索引降序范圍掃描（Index Range Scans Descending）
索引跳躍掃描（Index Skip Scans）
全索引掃描（Full Scans）
快速全索引掃描（Fast Full Index Scans）
索引連接（Index Joins）
位圖連接（Bitmap Joins）
•如何選擇訪問路徑： CBO首先檢查WHERE子句中的條件以及FROM子句，確定有哪些訪問路徑是可用的。然後CBO使用這個訪問路徑產生一組可能的執行計劃，再通過索引、表的統計信息評估每個計劃的成本，最後優化器選擇成本最低的一個。
•表的連接方式：
Nested Loops會循環外表（驅動表），逐個比對和內表的連接是否符合條件。在驅動表比較小，內表比較大，而且內外表的連接列有索引的時候比較好。當SORT_AREA空間不足的時候，Oracle也會選擇使用NL。基於Cost的Oracle優化器(CBO)會自動選擇較小的表做外表。（優點：嵌套循環連接比其他連接方法有優勢,它可以快速地從結果集中提取第一批記錄,而不用等待整個結果集完全確定下來。缺點：如果內部行源表(讀取的第二張表（內表）已連接的列上不包含索引,或者索引不是高度可選時, 嵌套循環連接效率是很低的。如果驅動行源表(從驅動表中提取的記錄)非常龐大時,其他的連接方法可能更加有效。）
SORT- merge JOIN，將兩表的連接列各自排序然後合並，只能用於連接列相等的情況，適合兩表大小相若的情況（在缺乏數據的選擇性或者可用的索引時,或者兩個源表都過於龐大(超過記錄數的5%)時,排序合並連接將比嵌套循環連更加高效。但是,排列合並連接只能用於等價連接(WHERE D.deptno=E.dejptno,而不是WHERE D.deptno>=E.deptno)。排列合並連接需要臨時的內存塊,以用於排序(如果SORT_AREA_SIZE設置得太小的話)。這將導致在臨時表空間占用更多的內存和磁盤I/O。）
HASH JOIN在其中一表的連接列上作散列，因此只有另外一個表做排序合並，理論上比SORT JOIN會快些，需要有足夠的內存，而且打開了SORT_JOIN_ENABLE參數。(當缺少有用的索引時，哈希連接比嵌套循環連接更加有效。哈希連接可能比排序合並連接更快，因為在這種情況下只有一張源表需要排序。哈希連接也可能比嵌套循環連接更快，因為處理內存中的哈希表比檢索B_樹索引更加迅速。和排序合並連接、群集連接一樣，哈希連接只能用於等價連接。和排序合並連接一樣，哈希連接使用內存資源，並且當用於排序內存不足時，會增加臨時表空間的I/O（這將使這種連接方法速度變得極慢）。最後，只有基於代價的優化器才可以使用哈希連接。)
索引連接:
No2: AUTOTRACE
•set autotrace 使用步驟：
1、以system登錄
2、創建plustrace角色; <your_Oracle_home>sqlplusadminplustrce.sql
3、向常規用戶授予權限：grant plustrace to <user id>
4、如果沒有plan_table也要創建: <your_Oracle_home> dbmsadminutlxplan.sql
•set autotrace 選項
on 顯示查詢結果，執行計劃，統計數據
on statistics 顯示查詢結果，統計數據，不顯示執行計劃
on explain顯示查詢結果，執行計劃，不顯示統計數據
traceonly 顯示執行計劃和統計結果，但不包括查詢結果
traceonly statistics 僅顯示統計數據
recursive calls在用戶級別和系統級別上生成的遞歸調用的數量。Oracle維護了一些用於內部處理的表。當Oracle需要對這些表進行更改時，它就會在內部生成一個SQL語句，然後這個語句再生成一個遞歸調用。
db block gets請求一個CURRENT塊的次數
consistent gets為一塊請求consistent read的次數
physical reads從磁盤讀取得數據塊總數。這個數量等於“直接物理讀取”的值加上讀入緩沖區的所有數據塊
redo size生成的重做的總數量（以字節為單位）
bytes sent via SQL * Net to clIEnt從前台進程發送給客戶的總字節數
bytes received via SQL * Net from clIEnt通過Oracle Net從客戶接收的總字節數
SQL*Net roundtrips to/from clIEnt發送給客戶和從客戶接收的Oracle Net消息的總數
sorts (memory)完全在內存中執行並且不需要任何磁盤寫入的排序操作的數量
sorts (disk)至少需要一個磁盤寫入的排序操作的數量
rows processed在操作過程中處理的行數
四、最後，使用計時特性來測量和比較處理時間
Set timing on
