Oracle調優總結(經典實踐重要)

本文轉載自查看原文 2014-02-28 03:41 4574 database

轉載：http://langgufu.iteye.com/blog/1974211

Problem Description:
1.每個表的結構及主鍵索引情況
2.每個表的count(*)記錄是多少
3.對於創建索引的列，索引的類型是什么？count(distinct indexcol)的值是多少？
4.最后一次對表進行分析是在什么時間，分析后，是否又對相關表做過大的操作
5.索引最后一次rebuild，是在什么時間，此后對表的操作類型又是什么狀況？索引中浪費的空間是多少？
6.這些表的存儲情況，表的存儲參數，表空間的類型，存儲參數等
7.執行該SQL語句時，系統等候的資源是什么？ Trace SQL語句的執行過程
8.另一台執行相似SQL速度很快的機器上的相關表的如上信息是什么？

一：SQL tuning 類
1:列舉幾種表連接方式
hash join/merge join/nest loop(cluster join)/index join

2:不借助第三方工具，怎樣查看sql的執行計划
set autotrace on
set autotrace traceonly

explain plan set statement_id = &item_id for &sql;
select * from table(dbms_xplan.display);
http://download-west.oracle.com/ ... /b10752/ex_plan.htm

3:如何使用CBO,CBO與RULE的區別
在optimizer_mode=choose時,如果表有統計信息（分區表外）,優化器將選擇CBO,否則選RBO。

RBO遵循簡單的分級方法學,使用15種級別要點，當接收到查詢，優化器將評估使用到的要點數目,
然后選擇最佳級別（最少的數量）的執行路徑來運行查詢。
CBO嘗試找到最低成本的訪問數據的方法,為了最大的吞吐量或最快的初始響應時間,計算使用不同
的執行計划的成本，並選擇成本最低的一個,關於表的數據內容的統計被用於確定執行計划。

4:如何定位重要(消耗資源多)的SQL
select sql_text
from v$sql
where disk_reads > 1000 or (executions > 0 and buffer_gets/executions > 30000);

5:如何跟蹤某個session的SQL
exec dbms_system.set_sql_trace_in_session(sid,serial#,&sql_trace);

select sid,serial# from v$session where sid = (select sid from v$mystat where rownum = 1);
exec dbms_system.set_ev(&sid,&serial#,&event_10046,&level_12,'');

6:SQL調整最關注的是什么
查看該SQL的response time(db block gets/consistent gets/physical reads/sorts (disk))

7:說說你對索引的認識（索引的結構、對dml影響、為什么提高查詢性能）
b-tree index/bitmap index/function index/patitional index(local/global)
索引通常能提高select/update/delete的性能,會降低insert的速度,

8:使用索引查詢一定能提高查詢的性能嗎？為什么
索引就是為了提高查詢性能而存在的,
如果在查詢中索引沒有提高性能,
只能說是用錯了索引,或者講是場合不同

9:綁定變量是什么？綁定變量有什么優缺點？
綁定變量是相對文本變量來講的,所謂文本變量是指在SQL直接書寫查詢條件，
這樣的SQL在不同條件下需要反復解析,綁定變量是指使用變量來代替直接書寫條件，
查詢bind value在運行時傳遞，然后綁定執行。

優點是減少硬解析,降低CPU的爭用,節省shared_pool
缺點是不能使用histogram,sql優化比較困難

10:如何穩定(固定)執行計划
query_rewrite_enabled = true
star_transformation_enabled = true
optimizer_features_enable = 9.2.0

創建並使用stored outline
  http://download-west.oracle.com/ ... /outlines.htm#26854

這個貼子:
http://www.cnoug.org/viewthread.php?tid=27598

11:和排序相關的內存在8i和9i分別怎樣調整，臨時表空間的作用是什么
   8i中sort_area_size/sort_area_retained_size決定了排序所需要的內存
如果排序操作不能在sort_area_size中完成,就會用到temp表空間

9i中如果workarea_size_policy=auto時,
排序在pga內進行,通常pga_aggregate_target的1/20可以用來進行disk sort;
如果workarea_size_policy=manual時,排序需要的內存由sort_area_size決定

在執行order by/group by/distinct/union/create index/index rebuild/minus等操作時,
如果在pga或sort_area_size中不能完成,排序將在臨時表空間進行（disk sort）,
臨時表空間主要作用就是完成系統中的disk sort.

12:存在表T(a,b,c,d),要根據字段c排序后取第21—30條記錄顯示，請給出sql
   create table t(a number(,b number(,c number(,d number();
/
begin
    for i in 1 .. 300 loop
      insert into t values(mod(i,2),i/2,dbms_random.value(1,300),i/4);
    end loop;
end;
/
   select * from (select c.*,rownum as rn from (select * from t order by c desc) c) where rn between 21 and 30;
   /
select * from (select * from test order by c desc) x where rownum < 30
minus
   select * from (select * from test order by c desc) y where rownum < 20 order by 3 desc
   相比之 minus性能較差

二：數據庫基本概念類

1:pctused and pctfree 表示什么含義有什么作用
pctused與pctfree控制數據塊是否出現在freelist中,
pctfree控制數據塊中保留用於update的空間,當數據塊中的free space小於pctfree設置的空間時,
該數據塊從freelist中去掉,當塊由於dml操作free space大於pct_used設置的空間時,該數據庫塊將
被添加在freelist鏈表中。
--PCTFREE存儲參數
　　PCTFREE存儲參數告訴ORACLE什么時候應該將數據塊從對象的空閑列表中移出。ORACLE的默認參數是PCTFREE=10；
也就是說，一旦一個INSERT操作使得數據塊的90%被使用，這個數據塊就從空閑列表(free list)中移出。
　--PCTUSED存儲參數
　　PCTUSED存儲參數告訴ORACLE什么時候將以前滿的數據塊加到空閑列表中。當記錄從數據表中刪除時，數據庫的數
據塊就有空間接受新的記錄，但只有當填充的空間降到PCTUSED值以下時，該數據塊才被連接到空閑列表中，才可以往
其中插入數據。PCTUSED的默認值是PCTUSED=40。
--存儲參數規則小結
　　（1）PCTUSED較高意味着相對較滿的數據塊會被放置到空閑列表中，從而有效的重復使用數據塊的空間，但會導致
I/O消耗。PCTUSED低意味着在一個數據塊快空的時候才被放置到空閑列表中，數據塊一次能接受很多的記錄，因此可以
減少I/O消耗，提高性能。
　　（2）PCTFREE的值較大意味着數據塊沒有被利用多少就從空閑列表中斷開連接，不利於數據塊的充分使用。PCTFREE
過小的結果是，在更新時可能會出現數據記錄遷移(Migration)的情況。(注：數據記錄遷移(Migration)是指記錄在是
UPDATE操作擴展了一個VARCHAR2類型的列或BLOB列后,PCTFREE參數所指定的空間不夠擴展，從而記錄被ORACLE強制遷移到
新的數據塊，發生這種情況將較嚴重的影響ORACLE的性能，出現更新緩慢)。
　　（3）在批量的插入、刪除或者更新操作之前，先刪除該表上的索引，在操作完畢之后在重新建立，這樣有助於提高
批量操作的整體速度，並且保證B樹索引在操作之后有良好的性能。

對於不同的應用系統，表的pctfree 和pctused兩個參數有不同的設計原則，以下是根據特定的應用系統進行估算的例子，從中可以掌握基本的估算方法。

表的存儲參數調整，一般情況，設置為pctfree 5 pctused 85即可（缺省為pctfree 10 pctused 40）
1.對於Pctfree參數
除了可以按字段及字段長度估算平均行長外，下面的方面可以根據已有數據分析出平均行長和每塊行數
例：
analyze table 病人信息 compute statistics for table for all indexes for all indexed columns;
Select Num_Rows,Blocks,Round(Num_Rows / Blocks) Avg_Rows_Block, Avg_Row_Len From User_Tables Where Table_Name = '病人信息'

NUM_ROWS BLOCKS AVG_ROWS_BLOCK AVG_ROW_LEN
857291 14161 61 117

對於一般8192的塊，實際可用空間為8100左右.
假設以前該表的pctfree為15，改為5后，pctfree減少10，就可以再存入約7行.

相同的1萬4千塊就可以多存放約10萬行數據，
這10萬行數據，如果按每塊60行算，就可以少占用約1700塊(約13M的空間)
如果全表掃描該表的話，少讀1700塊數據，少106次IO操作(按缺省db_file_multiblock_read_count=16計算)
少占13M的內存

另外，需要考慮的兩個因素
1。更新操作時，數據增長量大不大，例如：主要是把狀態字段由1改為3，還是把摘要由空改為一段文字
2。並發事務的多少，因為一個事務信息在塊中要占用約24Byte，如果有10個並發事務的話，至少額外考慮240Byte的空閑空間。

2.對於Pctused參數
主要考慮刪除后插入數據的情況多不多，以及平均行長大小
例如：
病人費用記錄，醫保如果存在校對操作的話，是先產生預交結算數據，正式結算時，刪除這些數據再重新生成
所以，病人預交記錄,Pctused不能設置太高，否則重用那些低於Pctused的塊，只能插入少量數據行，增加了IO操作
analyze table 病人預交記錄 compute statistics for table for all indexes for all indexed columns;
Select Num_Rows,Blocks,Round(Num_Rows / Blocks) Avg_Rows_Block, Avg_Row_Len From User_Tables Where Table_Name = '病人預交記錄'

NUM_ROWS BLOCKS AVG_ROWS_BLOCK AVG_ROW_LEN
181758 2147 85 83

如果設置pctfree 5 pctused 85，那么當刪除一些行使塊的已用空間低於85%時，塊會被重用，但是因為要預留5%的空閑空間，
所以,對於已用空間剛剛低於85%的塊，重用空間就只有10%,對於8K的塊，可用810Byte,平均行長83,可以再放入9行，所以這個參數也是可以的。

但是，如果是病人費用記錄,平均行長229，這樣設置，只能放下3行，這個參數就不太合適了

NUM_ROWS BLOCKS AVG_ROWS_BLOCK AVG_ROW_LEN
925133 38278 24 229

根據分析，病人費用記錄的數據更新量不大，但是並發操作比較大，最好把Pctfree設置高一點
所以，可以設置為pctfree 10 pctused 75（重用的塊至少可以放5行，約1-2張單據）,甚至pctused 70也是可以的。

如果一個塊的數據行數太多，可能造成熱塊爭用，但是相對於減少存儲，減少IO，減少內存占用帶來的好處來說，熱塊不是特別突出的情況下可以不考慮。

--MartriWang@gmail.com 17/05/2007--

PCTFREE=(Average Row Size-Initial Row Size)*100/Average Row Size
PCTUSED=(100-PCTFREE) -Average Row Size * 100/Availabe Data Space
　　
　　Oracle的其中一個優點時它可以管理每個表空間中的自由空間。Oracle負責處理表和索引的空間管理，這樣就可以讓我們無需懂得Oracle的表和索引的
內部運作。不過，對於有經驗的Oracle調優專家來說，他需要懂得Oracle是如何管理表的extent和空閑的數據塊。對於調整擁有高的insert或者update的系
統來說，這是非常重要的。
　　
　　要精通對象的調整，你需要懂得freelists和freelist組的行為，它們和pctfree及pctused參數的值有關。這些知識對於企業資源計划（ERP）的應用是
特別重要的，因為在這些應用中，不正確的表設置通常是DML語句執行慢的原因。　
　　對於初學者來說，最常見的錯誤是認為默認的Oracle參數對於所有的對象都是最佳的。除非磁盤的消耗不是一個問題，否則在設置表的pctfree和pctused
參數時，就必須考慮平均的行長和數據庫的塊大小，這樣空的塊才會被有效地放到freelists中。當這些設置不正確時，那些得到的freelists也是"dead"塊，
因為它們沒有足夠的空間來存儲一行，這樣將會導致明顯的處理延遲。
　　Freelists對於有效地重新使用Oracle表空間中的空間是很重要的，它和pctfree及pctused這兩個存儲參數的設置直接相關。如果將pctused設置為一個高的值，
這時數據庫就會盡快地重新使用塊。不過，高性能和有效地重新使用表的塊是對立的。在調整Oracle的表格和索引時，需要認真考慮究竟需要高性能還是有效的空
間重用，並且據此來設置表的參數。以下我們來看一下這些freelists是如何影響Oracle的性能的。
　　
　　當有一個請求需要插入一行到表格中時，Oracle就會到freelist中尋找一個有足夠的空間來容納一行的塊。你也許知道，freelist串是放在表格或者索引的第
一個塊中，這個塊也被稱為段頭（segment header）。pctfree和pctused 參數的唯一目的就是為了控制塊如何在freelists中進出。雖然freelist link和 unlink
是簡單的Oracle功能，不過設置freelist link (pctused) 和unlink (pctfree) 對Oracle的性能確實有影響。
　　
　　由DBA的基本知識知道，pctfree參數是控制freelist un-links的（即將塊由freelists中移除）。設置pctfree=10 意味着每個塊都保留10%的空間用作行擴展。
pctused參數是控制freelist re-links的。設置pctused=40意味着只有在塊的使用低於40%時才會回到表格的freelists中。
　　
　　許多新手對於一個塊重新回到freelists后的處理都有些誤解。其實，一旦由於一個刪除的操作而令塊被重新加入到freelist中，它將會一直保留在freelist中
即使空間的使用超過了60%，只有在到達pctfree時才會將數據塊由freelist中移走。
　　
　　表格和索引存儲參數設置的要求總結
　　
　　以下的一些規則是用來設置freelists, freelist groups, pctfree和pctused存儲參數的。你也知道，pctused和pctfree的值是可以很容易地通過alter table
命令修改的，一個好的DBA應該知道如何設置這些參數的最佳值。
　　
　　有效地使用空間和高性能之間是有矛盾的，而表格的存儲參數就是控制這個方面的矛盾：
　　
　　. 對於需要有效地重新使用空間，可以設置一個高的pctused值，不過副作用是需要額外的I/O。一個高的pctused值意味着相對滿的塊都會放到freelist中。因
此，這些塊在再次滿之前只可以接受幾行記錄，從而導致更多的I/O。
　　
　　. 追求高性能的話，可以將pctused設置為一個低的值，這意味着Oracle不會將數據塊放到freelists中直到它幾乎是空的。那么塊將可以在滿之前接收更多的行，
因此可以減少插入操作的I/O。要記住Oracle擴展新塊的性能要比重新使用現有的塊高。對於Oracle來說，擴展一個表比管理freelists消耗更少的資源。
　　
　　讓我們來回顧一下設置對象存儲參數的一些常見規則：
　　
　　．經常將pctused設置為可以接收一條新行。對於不能接受一行的free blocks對於我們來說是沒有用的。如果這樣做，將會令Oracle的性能變慢，因為Oracle將
在擴展表來得到一個空的塊之前，企圖讀取5個"dead" 的free block。
　　
　　．表格中chained rows的出現意味着pctfree太低或者是db_block_size太少。在很多情況下，RAW和LONG RAW列都很巨大，以至超過了Oracle的最大塊的大小，
這時chained rows是不可以避免的。
　　
　　．如果一個表有同時插入的SQL語句，那么它需要有同時刪除的語句。運行單一個一個清除的工作將會把全部的空閑塊放到一個freelist中，而沒有其它包含有任何
空閑塊的freelists出現。
　　
　　．freelist參數應該設置為表格同時更新的最大值。例如，如果在任何時候，某個表最多有20個用戶執行插入的操作，那么該表的參數應該設置為freelists=20。
　　
　　應記住的是freelist groups參數的值只是對於Oracle Parallel Server和Real Application Clusters才是有用的。對於這類Oracle，freelist groups應該設置
為訪問該表格的Oracle Parallel Server實例的數目。

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

2:簡單描述table / segment / extent / block之間的關系
table創建時,默認創建了一個data segment,
每個data segment含有min extents指定的extents數,
每個extent據據表空間的存儲參數分配一定數量的blocks

3:描述tablespace和datafile之間的關系
一個tablespace可以有一個或多個datafile,每個datafile只能在一個tablespace內,
table中的數據,通過hash算法分布在tablespace中的各個datafile中,
tablespace是邏輯上的概念,datafile則在物理上儲存了數據庫的種種對象。

4:本地管理表空間和字典管理表空間的特點，ASSM有什么特點
本地管理表空間（Locally Managed Tablespace簡稱LMT）
8i以后出現的一種新的表空間的管理模式，通過位圖來管理表空間的空間使用。
字典管理表空間（Dictionary-Managed Tablespace簡稱DMT）
8i以前包括以后都還可以使用的一種表空間管理模式，通過數據字典管理表空間的空間使用。
動段空間管理（ASSM），
它首次出現在Oracle920里有了ASSM，鏈接列表freelist被位圖所取代，它是一個二進制的數組，
能夠迅速有效地管理存儲擴展和剩余區塊（free block），因此能夠改善分段存儲本質，
ASSM表空間上創建的段還有另外一個稱呼叫Bitmap Managed Segments（BMB 段）。

5:回滾段的作用是什么
事務回滾：當事務修改表中數據的時候，該數據修改前的值（即前影像）會存放在回滾段中，
當用戶回滾事務（ROLLBACK）時，ORACLE將會利用回滾段中的數據前影像來將修改的數據恢復到原來的值。
　
事務恢復：當事務正在處理的時候，例程失敗，回滾段的信息保存在undo表空間中，
ORACLE將在下次打開數據庫時利用回滾來恢復未提交的數據。

　讀一致性：當一個會話正在修改數據時，其他的會話將看不到該會話未提交的修改。
           當一個語句正在執行時，該語句將看不到從該語句開始執行后的未提交的修改（語句級讀一致性）
      當ORACLE執行SELECT語句時，ORACLE依照當前的系統改變號（SYSTEM CHANGE NUMBER-SCN）
      來保證任何前於當前SCN的未提交的改變不被該語句處理。可以想象：當一個長時間的查詢正在執行時，
      若其他會話改變了該查詢要查詢的某個數據塊，ORACLE將利用回滾段的數據前影像來構造一個讀一致性視圖。
  http://www.itpub.net/showthread. ... E%B5%C4%D7%F7%D3%C3

6:日志的作用是什么
記錄數據庫事務,最大限度地保證數據的一致性與安全性

重做日志文件：含對數據庫所做的更改記錄，這樣萬一出現故障可以啟用數據恢復,一個數據庫至少需要兩個重做日志文件
歸檔日志文件：是重做日志文件的脫機副本，這些副本可能對於從介質失敗中進行恢復很必要。

http://www.cnoug.org/viewthread. ... hlight=%C8%D5%D6%BE

7:SGA主要有那些部分，主要作用是什么
SGA：db_cache/shared_pool/large_pool/java_pool
db_cache:
數據庫緩存（Block Buffer）對於Oracle數據庫的運轉和性能起着非常關鍵的作用，
   它占據Oracle數據庫SGA（系統共享內存區）的主要部分。Oracle數據庫通過使用LRU
   算法，將最近訪問的數據塊存放到緩存中，從而優化對磁盤數據的訪問.
shared_pool:
共享池的大小對於Oracle 性能來說都是很重要的。
共享池中保存數據字典高速緩沖和完全解析或編譯的的PL/SQL 塊和SQL 語句及控制結構
large_pool:
使用MTS配置時，因為要在SGA中分配UGA來保持用戶的會話，就是用Large_pool來保持這個會話內存
   使用RMAN做備份的時候，要使用Large_pool這個內存結構來做磁盤I/O緩存器
java_pool:
為java procedure預備的內存區域,如果沒有使用java proc,java_pool不是必須的

8racle系統進程主要有哪些，作用是什么
數據寫進程(dbwr)：負責將更改的數據從數據庫緩沖區高速緩存寫入數據文件
日志寫進程(lgwr)：將重做日志緩沖區中的更改寫入在線重做日志文件
系統監控(smon) ：檢查數據庫的一致性如有必要還會在數據庫打開時啟動數據庫的恢復
進程監控(pmon) ：負責在一個Oracle 進程失敗時清理資源
檢查點進程(chpt)：負責在每當緩沖區高速緩存中的更改永久地記錄在數據庫中時,更新控制文件和數據文件中的數據庫狀態信息。
歸檔進程(arcn) ：在每次日志切換時把已滿的日志組進行備份或歸檔
作業調度器(cjq) :負責將調度與執行系統中已定義好的job,完成一些預定義的工作.
恢復進程(reco) :保證分布式事務的一致性,在分布式事務中,要么同時commit,要么同時rollback;

三：備份恢復類

1:備份如何分類
邏輯備份：exp/imp
物理備份：
    RMAN備份
     full backup/incremental backup(累積/差異)
     熱備份:alter tablespace begin/end backup;
     冷備份:脫機備份(database shutdown)

2:歸檔是什么含義
關於歸檔日志：Oracle要將填滿的在線日志文件組歸檔時,則要建立歸檔日志（archived redo log）。
其對數據庫備份和恢復有下列用處：
    <1>數據庫后備以及在線和歸檔日志文件，在操作系統和磁盤故障中可保證全部提交的事物可被恢復。
    <2>在數據庫打開和正常系統使用下，如果歸檔日志是永久保存，在線后備可以進行和使用。
數據庫可運行在兩種不同方式下：
   NOARCHIVELOG方式或ARCHIVELOG 方式
數據庫在NOARCHIVELOG方式下使用時，不能進行在線日志的歸檔,
如果數據庫在ARCHIVELOG方式下運行，可實施在線日志的歸檔。

3:如果一個表在2004-08-04 10:30:00 被drop，在有完善的歸檔和備份的情況下，如何恢復?
手工拷貝回所有備份的數據文件
sql>startup mount;
sql>alter database recover automatic until time '2004-08-04:10:30:00';
sql>alter database open resetlogs;

4:rman是什么,有何特點?
RMAN(Recovery Manager)是DBA的一個重要工具，用於備份、還原和恢復oracle數據庫,
RMAN 可以用來備份和恢復數據庫文件、歸檔日志、控制文件、系統參數文件,也可以用來執行完全或不完全的數據庫恢復。
RMAN有三種不同的用戶接口：
COMMAND LINE方式、GUI 方式（集成在OEM 中的備份管理器）、API 方式（用於集成到第三方的備份軟件中）。
具有如下特點：
1）功能類似物理備份，但比物理備份強大N倍；
2）可以壓縮空塊；
3）可以在塊水平上實現增量；
4）可以把備份的輸出打包成備份集，也可以按固定大小分割備份集；
5）備份與恢復的過程可以自動管理；
6）可以使用腳本（存在Recovery catalog 中）
7）可以做壞塊監測

5:standby的特點
備用數據庫（standby database）：ORACLE推出的一種高可用性(HIGH AVAILABLE)數據庫方案，
在主節點與備用節點間通過日志同步來保證數據的同步，備用節點作為主節點的備份
可以實現快速切換與災難性恢復,從920開始，還開始支持物理與邏輯備用服務器。
9i中的三種數據保護模式分別是：
1)、MAXIMIZE PROTECTION ：最大數據保護與無數據分歧，LGWR將同時傳送到備用節點，
    在主節點事務確認之前，備用節點也必須完全收到日志數據。如果網絡不好，引起LGWR不能傳送數據，將引起嚴重的性能問題，導致主節點DOWN機。
2)、MAXIMIZE AVAILABILITY ：無數據丟失模式，允許數據分歧，允許異步傳送。
    正常情況下運行在最大保護模式，在主節點與備用節點的網絡斷開或連接不正常時，自動切換到最大性能模式，
   主節點的操作還是可以繼續的。在網絡不好的情況下有較大的性能影響。
3)、MAXIMIZE PERFORMANCE：這種模式應當可以說是從8i繼承過來的備用服務器模式，異步傳送，
    無數據同步檢查，可能丟失數據，但是能獲得主節點的最大性能。9i在配置DATA GUARD的時候默認就是MAXIMIZE PERFORMANCE

6:對於一個要求恢復時間比較短的系統(數據庫50G,每天歸檔5G)，你如何設計備份策略
rman/每月一號 level 0 每周末/周三 level 1 其它每天level 2

四：系統管理類

1:對於一個存在系統性能的系統，說出你的診斷處理思路
1 做statspack收集系統相關信息
了解系統大致情況/確定是否存在參數設置不合適的地方/查看top 5 event/查看top sql等
2 查v$system_event/v$session_event/v$session_wait
從v$system_event開始,確定需要什么資源(db file sequential read)等
深入研究v$session_event,確定等待事件涉及的會話
從v$session_wait確定詳細的資源爭用情況(p1-p3的值:file_id/block_id/blocks等)
3 通過v$sql/v$sqltext/v$sqlarea表確定disk_reads、(buffer_gets/executions)值較大的SQL

2:列舉幾種診斷IO、CPU、性能狀況的方法
top/vmstat
statspack
sql_trace/tkprof
查v$system_event/v$session_event/v$session_wait
查v$sqlarea(disk_reads或buffer_gets/executions較大的SQL)

3:對statspack有何認識
StapSpack是Oracle公司提供的一個收集數據庫運行性能指標的軟件包，該軟件包從8i起，在9i、10g都有顯著的增強
該軟件包的輔助表（存儲相關參數與收集的性能指標的表）由最初的25個增長到43個
收集級別參數由原來的3個（0、5、10）增加到5個（0、5、6、7、10）
通過分析收集的性能指標，數據庫管理員可以詳細地了解數據庫目前的運行情況，對數據庫實例、等待事件、SQL等進行優化調整
利用statspack收集的snapshot,可以統計制作數據庫的各種性能指標的統計趨勢圖表。

4:如果系統現在需要在一個很大的表上創建一個索引，你會考慮那些因素，如何做以盡量減小對應用的影響
在系統比較空閑時
nologging選項（如果有dataguard則不可以使用nologging）
大的sort_ared_size或pga_aggregate_target較大

5:對raid1+0 和raid5有何認識
RAID 10(或稱RAID 1＋0)與RAID 0＋1不同，它是用硬盤驅動器先組成RAID 1陣列，然后在RAID 1陣列之間再組成RAID 0陣列。
RAID 10模式同RAID 0+1模式一樣具有良好的數據傳輸性能，但卻比RAID 0+1具有更高的可靠性。RAID 10陣列的實際容量為M×n/2，
磁盤利用率為50％。RAID 10也需要至少4個硬盤驅動器構成，因而價格昂貴。
RAID 10的可靠性同RAID 1一樣，但由於RAID 10硬盤驅動器之間有數據分割，因而數據傳輸性能優良。

RAID 5與RAID 3很相似，不同之處在於RAID 5的奇偶校驗信息也同數據一樣被分割保存到所有的硬盤驅動器，
而不是寫入一個指定的硬盤驅動器，從而消除了單個奇偶校驗硬盤驅動器的瓶頸問題。RAID 5磁盤陣列的性能比RAID 3有所提高，
但仍然需要至少3塊硬盤驅動器。其實際容量為M×(n-1)，磁盤利用率為(n-1)/n 。

五：綜合隨意類

1:你最擅長的是oracle哪部分?
pl/sql及sql優化

2:喜歡oracle嗎？喜歡上論壇嗎？或者偏好oracle的哪一部分？
喜歡,sql的優化

3:隨意說說你覺得oracle最有意思的部分或者最困難的部分
latch free的處理

4:為何要選擇做DBA呢?
興趣所在

--MartriWang@gmail.com 17/05/2007--
消耗在准備利用Oracle執行計划機制提高查詢性能新的SQL語句的時間是Oracle SQL語句執行時間的最重要的組成部分。
但是通過理解Oracle內部產生執行計划的機制，你能夠控制Oracle花費在評估連接順序的時間數量，並且能在大體上提高查詢性能。
准備執行SQL語句
當SQL語句進入Oracle的庫緩存后，在該語句准備執行之前，將執行下列步驟：
1) 語法檢查：檢查SQL語句拼寫是否正確和詞序。

2) 語義分析：核實所有的與數據字典不一致的表和列的名字。

3) 輪廓存儲檢查：檢查數據字典，以確定該SQL語句的輪廓是否已經存在。

4) 生成執行計划：使用基於成本的優化規則和數據字典中的統計表來決定最佳執行計划。

5) 建立二進制代碼：基於執行計划，Oracle生成二進制執行代碼。

一旦為執行准備好了SQL語句，以后的執行將很快發生，因為Oracle認可同一個SQL語句，並且重用那些語句的執行。然而，對於生成
特殊的SQL語句，或嵌入了文字變量的SQL語句的系統，SQL執行計划的生成時間就很重要了，並且前一個執行計划通常不能夠被重用。
對那些連接了很多表的查詢，Oracle需要花費大量的時間來檢測連接這些表的適當順序。

評估表的連接順序

在SQL語句的准備過程中，花費最多的步驟是生成執行計划，特別是處理有多個表連接的查詢。當Oracle評估表的連接順序時，它必須
考慮到表之間所有可能的連接。例如：六個表的之間連接有720（6的階乘，或6 * 5 * 4 * 3 * 2 * 1 = 720）種可能的連接線路。
當一個查詢中含有超過10個表的連接時，排列的問題將變得更為顯著。對於15個表之間的連接，需要評估的可能查詢排列將超過1萬億
（准確的數字是1,307,674,368,000）種。

使用optimizer_search_limit參數來設定限制

通過使用optimizer_search_limit參數，你能夠指定被優化器用來評估的最大的連接組合數量。使用這個參數，我們將能夠防止優化器
消耗不定數量的時間來評估所有可能的連接組合。如果在查詢中表的數目小於optimizer_search_limit的值，優化器將檢查所有可能的
連接組合。

例如：有五個表連接的查詢將有120（5! = 5 * 4 * 3 * 2 * 1 = 120）種可能的連接組合，因此如果optimizer_search_limit等於5
（默認值），則優化器將評估所有的120種可能。optimizer_search_limit參數也控制着調用帶星號的連接提示的閥值。當查詢中的表的
數目比optimizer_search_limit小時，帶星號的提示將被優先考慮。

另一個工具：參數optimizer_max_permutations

初始化參數optimizer_max_permutations定義了優化器所考慮組合數目的上限，且依賴於初始參數optimizer_search_limit。
optimizer_max_permutations的默認值是80,000。

參數optimizer_search_limit和optimizer_max_permutations一起來確定優化器所考慮的組合數目的上限：除非（表或組合數目）
超過參數optimizer_search_limit 或者 optimizer_max_permutations設定的值，否則優化器將生成所有可能的連接組合。一旦優
化器停止評估表的連接組合，它將選擇成本最低的組合。

使用ordered提示指定連接順序

你能夠設定優化器所執行的評估數目的上限。但是即使采用有很高價值的排列評估，我們仍然擁有使優化器可以盡早地放棄復雜的查詢
的重要機會。回想一下含有15個連接查詢的例子，它將有超過1萬億種的連接組合。如果優化器在評估了80,000個組合后停止，那么它才
僅僅評估了0.000006%的可能組合，而且或許還沒有為這個巨大的查詢找到最佳的連接順序。

在Oracle SQL中解決此問題的最好的方法是手工指定表的連接順序。為了盡快創建最小的解決方案集，這里所遵循的規則是將表結合起
來，通常優先使用限制最嚴格的WHERE子句來連接表。

下面的代碼是一個查詢執行計划的例子，該例子在emp表的關聯查詢上強制執行了嵌套的循環連接。注意，我已經使用了ordered提示來
直接最優化表的評估順序，最終它們表現在WHERE子句上。
select /*+ ordered use_nl(bonus) parallel(e, 4) */
　　 e.ename,
　　 hiredate,
　　 b.comm.
from
　　 emp e,
　　 bonus b
where
　　 e.ename = b.ename
這個例子要求優化器按順序連接在SQL語句的FROM子句中指定的表，在FROM子句中的第一個表指定了驅動表。ordered提示通常被用來與
其它的提示聯合起來來保證采用正確的順序連接多個表。它的用途更多的是在扭轉連接表數在四個以上的數據倉庫的查詢方面。
另外一個例子，下面的查詢使用ordered提示按照指定的順序來連接表：emp、dept、sal，最后是bonus。我通過指定emp到dept使用哈
希連接和sal到bonus使用嵌套循環連接，來進一步精煉執行計划。　
select /*+ ordered use_hash (emp, dept) use_nl (sal, bonus) */
　　
from
　　 emp,
　　 dept,
　　 sal,
　　 bonus
where . . .
　　
實踐建議
實際上，更有效率的做法是在產品環境中減小optimizer_max_permutations參數的大小，並且總是使用穩定的優化計划或存儲輪廓來
防止出現耗時的含有大量連接的查詢。一旦找到最佳的連接順序，您就可以通過增加ordered提示到當前的查詢中，並保存它的存儲輪廓，
來為這些表手工指定連接順序，從而使其持久化。
當你打算使用優化器來穩定計划，則可以照下面的方法使執行計划持久化，臨時將optimizer_search_limit設置為查詢中的表的數目，
從而允許優化器考慮所有可能的連接順序。然后，通過重新編排WHERE子句中表的名字，並使用ordered提示，與存儲輪廓一起使變更
持久化，來調整查詢。在查詢中包含四個以上的表時，ordered提示和存儲輪廓將排除耗時的評估SQL連接順序解析的任務，從而提高
查詢的速度。
一旦檢測到最佳的連接順序，我們就可以使用ordered提示來重載optimizer_search_limit和optimizer_max_permutations參數。
ordered提示要求表按照它們出現在FROM子句中的順序進行連接，所以優化器沒有加入描述。
作為一個Oracle專業人員，你應該知道在SQL語句第一次進入庫緩存時可能存在重大的啟動延遲。但是聰明的Oracle DBA和開發人
員能夠改變表的搜索限制參數或者使用ordered提示來手工指定表的連接順序，從而顯著地減少優化和執行新查詢所需的時間

--MartriWang@gmail.com 14/05/2007--

Oracle專家調優秘密

在過去的十年中， Oracle 已經成為世界上最專業的數據庫之一。對於 IT 專家來說，就是要確保利用 Oracle 的強大特性來提高他們公司的生產力。最有效的方法之一
是通過 Oracle 調優。它有大量的調整參數和技術來改進你的 Oracle 數據庫的性能。 Oracle 調優是一個復雜的主題。關於調優可以寫整整一本書，不過，為了改善
Oracle 數據庫的性能，有一些基本的概念是每個 Oracle DBA 都應該遵從的。
　　在這篇簡介中，我們將簡要地介紹以下的 Oracle 主題：
　　-- 外部調整：我們應該記住 Oracle 並不是單獨運行的。因此我們將查看一下通過調整 Oracle 服務器以得到高的性能。
　　--Row re-sequencing 以減少磁盤 I/O ：我們應該懂得 Oracle 調優最重要的目標是減少 I/O 。
　　--Oracle SQL 調整。 Oracle SQL 調整是 Oracle 調整中最重要的領域之一，只要通過一些簡單的 SQL 調優規則就可以大幅度地提升 SQL 語句的性能，這是一點都
不奇怪的。
　　-- 調整 Oracle 排序：排序對於 Oracle 性能也是有很大影響的。
　　-- 調整 Oracle 的競爭：表和索引的參數設置對於 UPDATE 和 INSERT 的性能有很大的影響。

　　我們首先從調整 Oracle 外部的環境開始。如果內存和 CPU 的資源不足的話，任何的 Oracle 調整都是沒有幫助的。

　　外部的性能問題
　　
　　Oracle 並不是單獨運行的。 Oracle 數據庫的性能和外部的環境有很大的關系。這些外部的條件包括有：
　　．CPU--CPU 資源的不足令查詢變慢。當查詢超過了 Oracle 服務器的 CPU 性能時，你的數據庫性能就受到 CPU 的限制。
　　．內存 -- 可用於 Oralce 的內存數量也會影響 SQL 的性能，特別是在數據緩沖和內存排序方面。
　　．網絡 -- 大量的 Net8 通信令 SQL 的性能變慢。
　　許多新手都錯誤的認為應該首先調整 Oracle 數據庫，而不是先確認外部資源是否足夠。實際上，如果外部環境出現瓶頸，再多的 Oracle 調整都是沒有幫助的。
　　在檢查 Oracle 的外部環境時，有兩個方面是需要注意的：
　　1 、當運行隊列的數目超過服務器的 CPU 數量時，服務器的性能就會受到 CPU 的限制。補救的方法是為服務器增加額外的 CPU 或者關閉需要很多處理資源的組件，
例如 Oracle Parallel Query 。
　　2 、內存分頁。當內存分頁時，內存容量已經不足，而內存頁是與磁盤上的交換區進行交互的。補救的方法是增加更多的內存，減少 Oracle SGA 的大小，或者關閉
Oracle 的多線程服務器。
　　可以使用各種標准的服務器工具來得到服務器的統計數據，例如 vmstat,glance,top 和 sar 。 DBA 的目標是確保數據庫服務器擁有足夠的 CPU 和內存資源來處理
Oracle 的請求。
　　以下讓我們來看一下 Oracle 的 row-resequencing 是如何能夠極大地減少磁盤 I/O 的。

　　Row-resequencing （行的重新排序）
　　
　　就象我們上面提到的，有經驗的 Oracle DBA 都知道 I/O 是響應時間的最大組成部分。其中磁盤 I/O 特別厲害，因為當 Oracle 由磁盤上的一個數據文件得到一個
數據塊時，讀的進程就必須等待物理 I/O 操作完成。磁盤操作要比數據緩沖慢 10,000 倍。因此，如果可以令 I/O 最小化，或者減少由於磁盤上的文件競爭而帶來的瓶頸
，就可以大大地改善 Oracle 數據庫的性能。如果系統響應很慢，通過減少磁盤 I/O 就可以有一個很快的改善。如果在一個事務中通過按一定的范圍搜索 primary-key
索引來訪問表，那么重新以 CTAS 的方法組織表將是你減少 I/O 的首要策略。通過在物理上將行排序為和 primary-key 索引一樣的順序，就可以加快獲得數據的速度。
就象磁盤的負載平衡一樣，行的重新排序也是很簡單的，而且也很快。通過與其它的 DBA 管理技巧一起使用，就可以在高 I/O 的系統中大大地減少響應的時間。在高容量
的在線事務處理環境中（ online transaction processing ， OLTP ），數據是由一個 primary 索引得到的，重新排序表格的行就可以令連續塊的順序和它們的 primary
索引一樣，這樣就可以在索引驅動的表格查詢中，減少物理 I/O 並且改善響應時間。這個技巧僅在應用選擇多行的時候有用，或者在使用索引范圍搜索和應用發出多個查詢
來得到連續的 key 時有效。對於隨機的唯一 primary-key （主鍵）的訪問將不會由行重新排序中得到好處。
　　讓我們看一下它是如何工作的。考慮以下的一個 SQL 的查詢，它使用一個索引來得到 100 行：
select salary from employee where last_name like 'B%';
這個查詢將會使用 last_name_index ，搜索其中的每一行來得到目標行。這個查詢將會至少使用 100 次物理磁盤的讀取，因為 employee 的行存放在不同的數據塊中。
　　不過，如果表中的行已經重新排序為和 last_name_index 的一樣，同樣的查詢又會怎樣處理呢？我們可以看到這個查詢只需要三次的磁盤 I/O 就讀完全部 100 個
員工的資料（一次用作索引的讀取，兩次用作數據塊的讀取），減少了 97 次的塊讀取。
　重新排序帶來的性能改善的程度在於在你開始的時候行的亂序性如何，以及你需要由序列中訪問多少行。至於一個表中的行與索引的排序鍵的匹配程度，可以查看數據
字典中的 dba_indexes 和 dba_tables 視圖得到。
　　在 dba_indexes 的視圖中，查看 clustering_factor 列。如果 clustering_factor 的值和表中的塊數目大致一樣，那么你的表和索引的順序是一樣的。不過，如果
clustering_factor 的值接近表中的行數目，那就表明表格中的行和索引的順序是不一樣的。
　　行重新排序的作用是不可以小看的。在需要進行大范圍的索引搜索的大表中，行重新排序可以令查詢的性能提高三倍。
　　一旦你已經決定重新排序表中的行，你可以使用以下的工具之一來重新組織表格。
　　. 使用 Oracle 的 Create Table As Select (CTAS) 語法來拷貝表格
　　. Oracle9i 自帶的表格重新組織工具
　　
SQL 語句的調優
　　SQL 調優
　　Oracle 的 SQL 調優是一個復雜的主題，甚至是需要整本書來介紹 Oracle SQL 調優的細微差別。不過有一些基本的規則是每個
Oracle DBA 都需要跟從的，這些規則可以改善他們系統的性能。 SQL 調優的目標是簡單的：
　　消除不必要的大表全表搜索：不必要的全表搜索導致大量不必要的 I/O ，從而拖慢整個數據庫的性能。調優專家首先會根據查詢
返回的行數目來評價 SQL 。在一個有序的表中，如果查詢返回少於 40% 的行，或者在一個無序的表中，返回少於 7% 的行，那么這個
查詢都可以調整為使用一個索引來代替全表搜索。對於不必要的全表搜索來說，最常見的調優方法是增加索引。可以在表中加入標准的
B 樹索引，也可以加入 bitmap 和基於函數的索引。要決定是否消除一個全表搜索，你可以仔細檢查索引搜索的 I/O 開銷和全表搜索
的開銷，它們的開銷和數據塊的讀取和可能的並行執行有關，並將兩者作對比。在一些情況下，一些不必要的全表搜索的消除可以通過
強制使用一個index 來達到，只需要在 SQL 語句中加入一個索引的提示就可以了。
　　在全表搜索是一個最快的訪問方法時，將小表的全表搜索放到緩存中，調優專家應該確保有一個專門的數據緩沖用作行緩沖。在
Oracle7 中，你可以使用 alter table xxx cache 語句，在 Oracle8 或以上，小表可以被強制為放到 KEEP 池中緩沖。
　確保最優的索引使用：對於改善查詢的速度，這是特別重要的。有時 Oracle 可以選擇多個索引來進行查詢，調優專家必須檢查
每個索引並且確保 Oracle 使用正確的索引。它還包括 bitmap 和基於函數的索引的使用。
　　. 確保最優的 JOIN 操作：有些查詢使用 NESTED LOOP join 快一些，有些則是 HASH join 快一些，另外一些則是
sort-merge join 更快。
這些規則看來簡單，不過它們占 SQL 調優任務的 90% ，並且它們也無需完全懂得 Oracle SQL
的內部運作。以下我們來簡單概覽以下 Oracle SQL 的優化。
　　調整 Oracle 的排序操作
　　排序是 SQL 語法中一個小的方面，但很重要，在 Oracle 的調整中，它常常被忽略。當使用 create index 、 ORDER BY 或者
GROUP BY 的語句時， Oracle 數據庫
將會自動執行排序的操作。通常，在以下的情況下 Oracle 會進行排序的操作：
　　使用 Order by 的 SQL 語句
　　使用 Group by 的 SQL 語句
　　在創建索引的時候
　　進行 table join 時，由於現有索引的不足而導致 SQL 優化器調用 MERGE SORT
　　當與 Oracle 建立起一個 session 時，在內存中就會為該 session 分配一個私有的排序區域。如果該連接是一個專用的連接
(dedicated connection) ，那么就會根據 init.ora 中 sort_area_size 參數的大小在內存中分配一個 Program Global Area (PGA)
如果連接是通過多線程服務器建立的，那么排序的空間就在 large_pool 中分配。不幸的是，對於所有的 session ，用做排序的內存
量都必須是一樣的，我們不能為需要更大排序的操作分配額外的排序區域。因此，設計者必須作出一個平衡，在分配足夠的排序區域以
避免發生大的排序任務時出現磁盤排序（ disk sorts ）的同時，對於那些並不需要進行很大排序的任務，就會出現一些浪費。當然，
當排序的空間需求超出了 sort_area_size 的大小時，這時將會在 TEMP 表空間中分頁進行磁盤排序。磁盤排序要比內存排序大概慢
14,000 倍。
　　上面我們已經提到，私有排序區域的大小是有 init.ora 中的 sort_area_size 參數決定的。每個排序所占用的大小由 init.ora
中的 sort_area_retained_size 參數決定。當排序不能在分配的空間中完成時，就會使用磁盤排序的方式，即在 Oracle 實例中的臨
時表空間中進行。磁盤排序的開銷是很大的，有幾個方面的原因。首先，和內存排序相比較，它們特別慢；而且磁盤排序會消耗臨時
表空間中的資源。 Oracle 還必須分配緩沖池塊來保持臨時表空間中的塊。無論什么時候，內存排序都比磁盤排序好，磁盤排序將會
令任務變慢，並且會影響 Oracle 實例的當前任務的執行。還有，過多的磁盤排序將會令free buffer waits 的值變高，從而令其它
任務的數據塊由緩沖中移走。
　　接着，讓我們看一下 Oracle 的競爭，並且看一下表的存儲參數的設置是如何影響 SQL UPDATE 和 INSERT 語句的性能的。

調整 Oracle 的競爭
　　Oracle 的其中一個優點時它可以管理每個表空間中的自由空間。 Oracle 負責處理表和索引的空間管理，這樣就可以讓我們無需
懂得 Oracle 的表和索引的內部運作。不過，對於有經驗的 Oracle 調優專家來說，他需要懂得 Oracle 是如何管理表的 extent 和空
閑的數據塊。對於調整擁有高的 insert 或者 update 的系統來說，這是非常重要的。
　　要精通對象的調整，你需要懂得 freelists 和 freelist 組的行為，它們和 pctfree 及 pctused 參數的值有關。這些知識對於
企業資源計划（ ERP ）的應用是特別重要的，因為在這些應用中，不正確的表設置通常是 DML 語句執行慢的原因。
　　對於初學者來說，最常見的錯誤是認為默認的 Oracle 參數對於所有的對象都是最佳的。除非磁盤的消耗不是一個問題，否則在設
置表的 pctfree 和 pctused 參數時，就必須考慮平均的行長和數據庫的塊大小，這樣空的塊才會被有效地放到 freelists 中。當這些
設置不正確時，那些得到的 freelists 也是 "dead" 塊，因為它們沒有足夠的空間來存儲一行，這樣將會導致明顯的處理延遲。
Freelists 對於有效地重新使用 Oracle 表空間中的空間是很重要的，它和 pctfree 及 pctused 這兩個存儲參數的設置直接相關。
通過將 pctused 設置為一個高的值，這時數據庫就會盡快地重新使用塊。不過，高性能和有效地重新使用表的塊是對立的。在調整
Oracle 的表格和索引時，需要認真考慮究竟需要高性能還是有效的空間重用，並且據此來設置表的參數。以下我們來看一下這些
freelists 是如何影響 Oracle 的性能的。
　　當有一個請求需要插入一行到表格中時， Oracle 就會到 freelist 中尋找一個有足夠的空間來容納一行的塊。你也許知道，
freelist 串是放在表格或者索引的第一個塊中，這個塊也被稱為段頭（ segment header ）。 pctfree 和 pctused 參數的唯一目的就
是為了控制塊如何在 freelists 中進出。雖然 freelist link 和 unlink 是簡單的 Oracle 功能，不過設置 freelist link (pctused)
和 unlink (pctfree) 對 Oracle 的性能確實有影響。
　　由 DBA 的基本知識知道， pctfree 參數是控制 freelist un-links 的（即將塊由 freelists 中移除）。設置 pctfree=10
意味着每個塊都保留 10% 的空間用作行擴展。 pctused 參數是控制 freelist re-links 的。設置 pctused=40 意味着只有在塊的
使用低於 40% 時才會回到表格的 freelists 中。
　　許多新手對於一個塊重新回到 freelists 后的處理都有些誤解。其實，一旦由於一個刪除的操作而令塊被重新加入到 freelist
中，它將會一直保留在 freelist 中即使空間的使用超過了 60% ，只有在到達 pctfree 時才會將數據塊由 freelist 中移走。

　　表格和索引存儲參數設置的要求總結
　　以下的一些規則是用來設置 freelists, freelist groups, pctfree 和 pctused 存儲參數的。你也知道， pctused 和 pctfree
的值是可以很容易地通過 alter table 命令修改的，一個好的 DBA 應該知道如何設置這些參數的最佳值。
　　有效地使用空間和高性能之間是有矛盾的，而表格的存儲參數就是控制這個方面的矛盾：
. 對於需要有效地重新使用空間，可以設置一個高的 pctused 值，不過副作用是需要額外的 I/O 。一個高的 pctused 值意味着相對滿
的塊都會放到 freelist 中。因此，這些塊在再次滿之前只可以接受幾行記錄，從而導致更多的 I/O 。
. 追求高性能的話，可以將 pctused 設置為一個低的值，這意味着 Oracle 不會將數據塊放到 freelists 中直到它幾乎是空的。
那么塊將可以在滿之前接收更多的行，
因此可以減少插入操作的 I/O 。要記住 Oracle 擴展新塊的性能要比重新使用現有的塊高。對於 Oracle 來說，擴展一個表比管理
freelists 消耗更少的資源。
　　讓我們來回顧一下設置對象存儲參數的一些常見規則：
　　．經常將 pctused 設置為可以接收一條新行。對於不能接受一行的 free blocks 對於我們來說是沒有用的。如果這樣做，
將會令 Oracle 的性能變慢，因為
Oracle 將在擴展表來得到一個空的塊之前，企圖讀取 5 個 "dead" 的 free block 。
　　．表格中 chained rows 的出現意味着 pctfree 太低或者是 db_block_size 太少。在很多情況下， RAW 和 LONG RAW 列都很巨
大，以至超過了 Oracle 的最大塊的大小，這時 chained rows 是不可以避免的。
　　．如果一個表有同時插入的 SQL 語句，那么它需要有同時刪除的語句。運行單一個一個清除的工作將會把全部的空閑塊放到一個
freelist 中，而沒有其它包含有任何空閑塊的 freelists 出現。
　　． freelist 參數應該設置為表格同時更新的最大值。例如，如果在任何時候，某個表最多有 20 個用戶執行插入的操作，那么
該表的參數應該設置為 freelists=20 。
　　應記住的是 freelist groups 參數的值只是對於 Oracle Parallel Server 和 Real Application Clusters 才是有用的。對於這
類 Oracle ， freelist groups
應該設置為訪問該表格的 Oracle Parallel Server 實例的數目。

---------------------------------------------------------------------------------------------------------------------------------------------------
--MartriWang@gmail.com 13/04/2007--　　
  --在rbo中，連接表的順序，和predicate的順序都是有要求的，一般會按照從右往左來訪問FROM clause的表，從下往上來訪問where clause的predicates，
選擇小表作驅動表是關鍵的。
  --cbo中，則主要是根據表的統計信息來覺得訪問路徑，所以保持表的統計信息准確性就很有必要了。
  --在optimizer_mode＝choose時候，系統首先會判斷FROM clause中的表是否有統計信息，如果有，則根據CBO來執行sql，否則根據rbo來執行。也可以通過
hints來改變sql的訪問路徑。
  --ORACLE檢索順序有關--自底向上，所以小表放在最後面可以縮小檢索范圍,數據量大的放在最左邊（以FROM作參考）

優化器模式
　　rule模式
　　
　　。總忽略CBO和統計信息而基於規則
　　choose模式
　　
　　。Oracle根據情況選擇rule or first_rows or all_rows
　　first_rows 模式
　　
　　。基於成本，以最快的速度返回記錄，會造成總體查詢速度的下降或消耗更多的資源，傾向索引掃描，適合OLTP系統

　　all_rows模式
　　
　　。基於成本，確保總體查詢時間最短，傾向並行全表掃描
　　
　　例如：
　　Select last_name from customer order by last_name;用first_rows時，迅速返回記錄，但I/O量大，用all_rows時，返回記錄慢，但使用資源少。
　　
　　調整SQL表訪問
　　
　　全表掃描
　　
　　。返回記錄：未排序表>40%，排序表>7%，建議采用並行機制來提高訪問速度，DDS；
　　
　　索引訪問
　　
　　。最常用的方法，包括索引唯一掃描和索引范圍掃描，OLTP；
　　
　　快速完全索引掃描
　　
　　。訪問索引中所有數據塊，結果相當於全表掃描，可以用索引掃描代替全表掃描，例如：
　　
　　Select serv_id,count(* ) from tg_cdr01 group by serv_id;
　　
　　評估全表掃描的合法性
　　
　　如何實現並行掃描
　　
　　。永久並行化（不推薦）
　　alter table customer parallel degree 8;
　　
　　。單個查詢並行化
　　select /*+ full(emp) parallel(emp,8)*/ * from emp;
　　
　　分區表效果明顯
　　
　　優化SQL語句排序
　　
　　排序的操作：
　　
　　。order by 子句
　　。group by 子句
　　。select distinct子句
　　。創建索引時
　　。union或minus
　　。排序合並連接
　　
　　如何避免排序
　　
　　。添加索引
　　。在索引中使用distinct子句
　　。避免排序合並連接
　　
　　使用提示進行調整
　　
　　使用提示的原則
　　
　　。語法：/*+ hint */
　　。使用表別名:select /*+ index(e dept_idx)*/ * from emp e
　　。檢驗提示
　　
　　常用的提示
　　
　　。rule (基於規則)
　　。all_rows
　　。first_rows
　　。use_nl
　　。use_hash
　　。use_merge
　　。index
　　。index_asc
　　。no_index
　　。index_desc（常用於使用max內置函數）
　　。index_combine(強制使用位圖索引)
　　。index_ffs（索引快速完全掃描）
　　。use_concat(將查詢中所有or條件使用union all)
　　。parallel
　　。noparallel
　　。full
　　。ordered（基於成本）
　　
5.調整表連接
　　
　　表連接的類型
　　
　　。等連接
　　where 條件中用等式連接；
　　。外部連接（左、右連接）
　　
　　在where條件子句的等式謂詞放置一個(+)來實現，例如：
　　select a.ename,b.comm from emp a,bonus b where a.ename=b.ename(+);
　　
　　該語句返回所有emp表的記錄；
　　。自連接
　　　Select a.value total, B.value hard, (A.value - b.value) soft ,
　　Round((b.value/a.value)*100,1) perc
　　From v$sysstat a,v$sysstat b
　　Where a.statistic# = 179
　　and B.statistic# = 180;
　　
　　反連接
　　
　　反連接常用於not in or not exists中，是指在查詢中找到的任何記錄都不包含在結果集中的子查詢；不建議使用not in or not exists;
　　
　　。半連接
　　
　　查詢中使用exists，含義：即使在子查詢中返回多條重復的記錄，外部查詢也只返回一條記錄。
　　
　　嵌套循環連接
　　
　　。被連接表中存在索引的情況下使用；
　　。使用use_nl。
　　
　　hash連接
　　
　　。Hash連接將驅動表加載在內存中，並使用hash技術連接第二個表，提高等連接速度。
　　。適合於大表和小表連接；
　　。使用use_hash。
　　
　　排序合並連接
　　
　　。排序合並連接不使用索引
　　。使用原則：
　　
　　連接表子段中不存在可用索引；
　　
　　查詢返回兩個表中大部分的數據快；
　　
　　CBO認為全表掃描比索引掃描執行的更快。
　　
　　。使用use_merge
　　
　　使用臨時/中間表
　　
　　多個大表關聯時，可以分別把滿足條件的結果集存放到中間表，然后用中間表關聯；
　　
　　SQL子查詢的調整
　　
　　關聯與非關聯子查詢
　　
　　。關聯：子查詢的內部引用的是外部表，每行執行一次；
　　。非關聯：子查詢只執行一次，存放在內存中。
　　
　　調整not in 和not exists語句
　　
　　。可以使用外部連接優化not in子句，例如：
　　select ename from emp where dept_no not in
　　(select dept_no from dept where dept_name =‘Math’);
　　
　　改為：
　　select ename from emp,dept
　　where emp.dept_no=dept.dept_no
　　and dept.dept_name is null;
　　
6.使用索引調整SQL
　　
　　Oracle 為什么不使用索引
　　
　　。檢查被索引的列或組合索引的首列是否出現在PL/SQL語句的WHERE子句中，這是“執行計划”能用到相關索引的必要條件。
　　
　　。看采用了哪種類型的連接方式。ORACLE的共有Sort Merge Join（SMJ）、Hash Join（HJ）和Nested Loop Join（NL）。
在兩張表連接，且內表的目標列上建有索引時，只有Nested Loop才能有效地利用到該索引。SMJ即使相關列上建有索引，最多
只能因索引的存在，避免數據排序過程。HJ由於須做HASH運算，索引的存在對數據查詢速度幾乎沒有影響。
　　
　　。看連接順序是否允許使用相關索引。假設表emp的deptno列上有索引，表dept的列deptno上無索引，WHERE語句有
emp.deptno=dept.deptno條件。在做NL連接時，emp做為外表，先被訪問，由於連接機制原因，外表的數據訪問方式是全表掃描，
emp.deptno上的索引顯然是用不上，最多在其上做索引全掃描或索引快速全掃描。
　　
　　。是否用到系統數據字典表或視圖。由於系統數據字典表都未被分析過，可能導致極差的“執行計划”。但是不要擅自對數據
字典表做分析，否則可能導致死鎖，或系統性能下降。
　　
　　。索引列是否函數的參數。如是，索引在查詢時用不上。
　　
　　。是否存在潛在的數據類型轉換。如將字符型數據與數值型數據比較，ORACLE會自動將字符型用to_number()函數進行轉換，
從而導致上一種現象的發生。
　　
　　。是否為表和相關的索引搜集足夠的統計數據。對數據經常有增、刪、改的表最好定期對表和索引進行分析，可用SQL語句
“analyze table xxxx compute statistics for all indexes;”。ORACLE掌握了充分反映實際的統計數據，才有可能做出正確的選擇。
　　
　　。索引列的選擇性不高。　　我們假設典型情況，有表emp，共有一百萬行數據，但其中的emp.deptno列，數據只有4種不同的值，
如10、20、30、40。雖然emp數據行有很多，ORACLE缺省認定表中列的值是在所有數據行均勻分布的，也就是說每種deptno值各有25萬
數據行與之對應。假設SQL搜索條件DEPTNO=10，利用deptno列上的索引進行數據搜索效率，往往不比全表掃描的高。
　　
　　。索引列值是否可為空（NULL）。如果索引列值可以是空值，在SQL語句中那些要返回NULL值的操作，將不會用到索引，如COUNT（*）
，而是用全表掃描。這是因為索引中存儲值不能為全空。
　　
　　。看是否有用到並行查詢（PQO）。並行查詢將不會用到索引。
　　
　　。如果從以上幾個方面都查不出原因的話，我們只好用采用在語句中加hint的方式強制ORACLE使用最優的“執行計划”。　hint采用注
釋的方式，有行注釋和段注釋兩種方式。　如我們想要用到A表的IND_COL1索引的話，可采用以下方式：
　SELECT /*+ INDEX（A IND_COL1）*/ * FROM A WHERE COL1 = XXX;
　　
　　如何屏蔽索引
　　
　　語句的執行計划中有不良索引時，可以人為地屏蔽該索引，方法：
　　
　　。數值型：在索引字段上加0，例如
　　select * from emp where emp_no+0 = v_emp_no;
　　
　　。字符型：在索引字段上加‘’，例如
　　select * from tg_cdr01 where msisdn||’’=v_msisdn;
---------------------------------------------------------------------------------------------------------------------------------------------------
--MartriWang@gmail.com 17/04/2007--

（1）RBO&CBO。

Oracle有兩種執行優化器，一種是RBO(Rule Based Optimizer)基於規則的優化器，這種優化器是基於sql語句寫法選擇執行路徑的；
另一種是CBO（Cost Based Optimizer）基於規則的優化器，這種優化器是Oracle根據統計分析信息來選擇執行路徑，如果表和索引
沒有進行分析，Oracle將會使用RBO代替CBO；如果表和索引很久未分析，CBO也有可能選擇錯誤執行路徑，不過CBO是Oracle發展的
方向，自8i版本來已經逐漸取代RBO.

（2）AUTOTRACE。

要看索引是否被使用我們要借助Oracle的一個叫做AUTOTRACE功能,它顯示了sql語句的執行路徑，我們能看到Oracle內部是怎么執行
sql的，這是一個非常好的輔助工具，在sql調優里廣泛被運用。我們來看一下怎么運用AUTOTRACE：

① 由於AUTOTRACE自動為用戶指定了Execution Plan,因此該用戶使用AUTOTRACE前必須已經建立了PLAN_TABLE。如果沒有的話，請
運行utlxplan.sql腳本（它在$ORACLE_HOME/rdbms/admin目錄中）。

② AUTOTRACE可以通過運行plustrce.sql腳本(它在$ORACLE_HOME/sqlplus/admin目錄中)來設置，用sys用戶登陸然后運行
plustrce.sql后會建立一個PLUSTRACE角色，然后給相關用戶授予PLUSTRACE角色，然后這些用戶就可以使用AUTOTRACE功能了。

③ AUTOTRACE的默認使用方法是set autotrace on，但是這方法不總是適合各種場合，特別當返回行數很多的時候。
Set autotrace traceonly提供了只查看統計信息而不查詢數據的功能。

    SQL> set autotrace on
SQL> select * from test;
         A
----------
         1
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE
   1    0   TABLE ACCESS (FULL) OF 'TEST'
Statistics
----------------------------------------------------------
          0 recursive calls
          0 db block gets
          0 consistent gets
          0 physical reads
          0 redo size
          0 bytes sent via SQL*Net to client
          0 bytes received via SQL*Net from client
          0 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
rows processed

SQL> set autotrace traceonly
SQL> select * from test.test;

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 TABLE ACCESS (FULL) OF 'TEST'

Statistics
----------------------------------------------------------
          0 recursive calls
          0 db block gets
          0 consistent gets
          0 physical reads
          0 redo size
          0 bytes sent via SQL*Net to client
          0 bytes received via SQL*Net from client
          0 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
rows processed

Hints是Oracle提供的一個輔助用法，按字面理解就是‘提示’的意思，確實它起得作用也是提示優化器按它所提供的關鍵字來
選擇執行路徑，特別適用於sql調整的時候。使用方法如下：

{DELETE|INSERT|SELECT|UPDATE} /*+ hint [text] [hint[text]]... */

具體可參考Oracle SQL Reference。

有了前面這些知識點，接下來讓我們來看一下什么時候索引是不起作用的。以下列出幾種情況。

（1）類型不匹配時。

SQL> create table test.testindex (a varchar(2),b number);
表已創建。
SQL> create index ind_cola on test.testindex(a);
索引已創建。
SQL> insert into test.testindex values('1',1);
已創建 1 行。
SQL> commit;
提交完成。
SQL> analyze table test.testindex compute statistics for all indexes;
表已分析。
SQL> set autotrace on;

SQL> select /*+RULE */* FROM test.testindex where a='1';(使用基於rule的優化器，數據類型匹配的情況下)
A           B
-- ----------
1           1
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=HINT: RULE
   1    0   TABLE ACCESS (BY INDEX ROWID) OF 'TESTINDEX'
   2    1     INDEX (RANGE SCAN) OF 'IND_COLA' (NON-UNIQUE)（使用了索引ind_cola）
――――――――――――――――――――――――――――――――――
SQL> select /*+RULE */* FROM test.testindex where a=1;（數據類型不匹配的情況）
A           B
-- ----------
1           1
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=HINT: RULE
   1    0   TABLE ACCESS (FULL) OF 'TESTINDEX'（優化器選擇了全表掃描）

（2）條件列包含函數但沒有創建函數索引。

SQL> select /*+ RULE */* FROM test.testindex where upper(a)= 'A';（使用了函數upper()在列a上）;
A           B
-- ----------
a           2
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=HINT: RULE
   1    0   TABLE ACCESS (FULL) OF 'TESTINDEX'（優化器選擇全表掃描）
----------------------------------------------------------
創建基於函數的索引
SQL> create index test.ind_fun on test.testindex(upper(a));
索引已創建。
SQL> insert into testindex values('a',2);
已創建1行。
SQL> commit;
提交完成。
SQL> select /*+ RULE*/* FROM test.testindex where upper(a)='A';
A           B
-- ----------
a           2
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=HINT: RULE
   1    0   TABLE ACCESS (FULL) OF 'TESTINDEX'
(在RULE優化器下忽略了函數索引選擇了全表掃描)
-----------------------------------------------------------
SQL> select * FROM test.testindex where upper(a)
='A';
A           B
-- ----------
a           2
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=5)
   1    0   TABLE ACCESS (BY INDEX ROWID) OF 'TESTINDEX' (Cost=2 Card=
          1 Bytes=5)
   2    1     INDEX (RANGE SCAN) OF 'IND_FUN' (NON-UNIQUE) (Cost=1 Car
          d=1)(CBO優化器使用了ind_fun索引)

（3）復合索引中的前導列沒有被作為查詢條件。

創建一個復合索引
SQL> create index ind_com on test.testindex(a,b);
索引已創建。
SQL> select /*+ RULE*/* from test.testindex where a='1';
A           B
-- ----------
1           2
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=HINT: RULE
   1    0   INDEX (RANGE SCAN) OF 'IND_COM' (NON-UNIQUE)(條件列表包含前導列時使用索引ind_com)
SQL> select /*+ RULE*/* from test.testindex where b=1;
未選定行
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=HINT: RULE
   1    0   TABLE ACCESS (FULL) OF 'TESTINDEX'(條件列表不包括前導列是選擇全表掃描)
-----------------------------------------------------------

（4）CBO模式下選擇的行數比例過大，優化器采取了全表掃描。

SQL> select * from test.testindex where a='1';
A           B
-- ----------
1           2
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=1 Card=1 Bytes=5)
   1    0   TABLE ACCESS (FULL) OF 'TESTINDEX' (Cost=1 Card=1 Bytes=5)
（表一共2行，選擇比例為50%,所以優化器選擇了全表掃描）
――――――――――――――――――――――――――――――――――
下面增加表行數
SQL> declare i number;
2 begin
3 for i in 1 .. 100 loop
4 insert into test.testindex values (to_char(i),i);
5 end loop;
6 end;
7 /
PL/SQL 過程已成功完成。
SQL> commit;
提交完成。
SQL> select count(*) from test.testindex;
COUNT(*)
----------
102
SQL> select * from test.testindex where a='1';
A             B
---- ----------
1             1
1             2
Execution Plan
SELECT STATEMENT Optimizer=CHOOSE (Cost=1 Card=1 Bytes=5)
1    0   INDEX (RANGE SCAN) OF 'IND_COM' (NON-UNIQUE) (Cost=1 Card=1 Bytes=5)
（表一共102行，選擇比例為2/102=2%,所以優化器選擇了索引掃描）

（5）CBO模式下表很久沒分析，表的增長明顯，優化器采取了全表掃描。

SQL> select * from test.testindex where a like '1%';
A             B
---- ----------
1             2
1             1
10           10
11           11
12           12
13           13
14           14
15           15
16           16
17           17
18           18
19           19
100         100
已選擇13行。
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=1 Card=13 Bytes=52)
   1   0 TABLE ACCESS (FULL) OF 'TESTINDEX' (Cost=1 Card=13 Bytes=52)
(表一共102行，選擇比例為13/102>10%,優化器選擇了全表掃描)
――――――――――――――――――――――――――――――――――
增加表行數
SQL> declare i number;
2 begin
3 for i in 200 .. 1000 loop
4 insert into test.testindex values (to_char(i),i);
5 end loop;
6 end;
7 /

PL/SQL 過程已成功完成。
SQL> commit;
提交完成。
SQL> select count(*) from test.testindex;
COUNT(*)
----------
903
SQL> select * from test.testindex where a like '1%';
A             B
---- ----------
1             2
1             1
10           10
11           11
12           12
13           13
14           14
15           15
16           16
17           17
18           18
19           19
100          100
1000         1000
已選擇14行。
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=1 Card=13 Bytes=52)
   1 0 TABLE ACCESS (FULL) OF 'TESTINDEX' (Cost=1 Card=13 Bytes=52)
(表一共903行，選擇比例為14/903<5%,優化器選擇了全表掃描,選擇路徑是錯誤的)
―――――――――――――――――――――――――――――
給表做分析

SQL> analyze table test.testindex compute statistics for table for all indexed c
olumns for all indexes;
表已分析。
SQL> select * from test.testindex where a like '1%';
A             B
---- ----------
1             2
1             1
10           10
100         100
1000       1000
11           11
12           12
13           13
14           14
15           15
16           16
17           17
18           18
19           19
已選擇14行。
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=4 Card=24 Bytes=120)
   1   0 TABLE ACCESS (BY INDEX ROWID) OF 'TESTINDEX' (Cost=4 Card=
          24 Bytes=120)
   2 1 INDEX (RANGE SCAN) OF 'IND_COLA' (NON-UNIQUE) (Cost=2 Ca
          rd=24)
（經過分析后優化器選擇了正確的路徑，使用了ind_cola索引）

---------------------------------------------------------------------------------------------------------------------------------------------------
--MartriWang@gmail.com 18/05/2007--

--PCTFREE和PCTUSED調整

PCTFREE存儲參數
　　PCTFREE存儲參數告訴ORACLE什么時候應該將數據塊從對象的空閑列表中移出。ORACLE的默認參數是
PCTFREE=10；也就是說，一旦一個INSERT操作使得數據塊的90%被使用，這個數據塊就從空閑列表(free
list)中移出。
PCTUSED存儲參數
　　PCTUSED存儲參數告訴ORACLE什么時候將以前滿的數據塊加到空閑列表中。當記錄從數據表中刪除時，
數據庫的數據塊就有空間接受新的記錄，但只有當填充的空間降到PCTUSED值以下時，該數據塊才被連接
到空閑列表中，才可以往其中插入數據。PCTUSED的默認值是PCTUSED=40。
　　存儲參數規則小結
　　（1）PCTUSED較高意味着相對較滿的數據塊會被放置到空閑列表中，從而有效的重復使用數據塊的空間，
但會導致I/O消耗。PCTUSED低意味着在一個數據塊快空的時候才被放置到空閑列表中，數據塊一次能接受很多
的記錄，因此可以減少I/O消耗，提高性能。
　　（2）PCTFREE的值較大意味着數據塊沒有被利用多少就從空閑列表中斷開連接，不利於數據塊的充分使用。
PCTFREE過小的結果是，在更新時可能會出現數據記錄遷移(Migration)的情況。(注：數據記錄遷移(Migration
)是指記錄在是UPDATE操作擴展了一個VARCHAR2類型的列或BLOB列后,PCTFREE參數所指定的空間不夠擴展，從而
記錄被ORACLE強制遷移到新的數據塊，發生這種情況將較嚴重的影響ORACLE的性能，出現更新緩慢)。
　　（3）在批量的插入、刪除或者更新操作之前，先刪除該表上的索引，在操作完畢之后在重新建立，這樣有
助於提高批量操作的整體速度，並且保證B樹索引在操作之后有良好的性能。

--同優化器下的調整；
　　基於成本優化器(CBO)：
　　（1）ORACLE 8i 以上版本更多地使用成本優化器，因為它更加智能；
　　（2）通過optimizer_mode=all_rows 或 first_rows來選擇CBO；通過
alter session set optimizer_goal=all_rows 或 first_rows來選擇CBO;通過添加hint來選擇CBO;
　　（3）使用基於成本優化的一個關鍵是：存在表和索引的統計資料。通過analyze table 獲得表
的統計資料；通過analyze index獲得索引的統計資料。
　　（4）對於超過5個表的連接的查詢，建議不要使用成本優化器，而是在SQL語句中通過添加
/* + rule */提示或者通過指定的執行計划來避免可能會在20分鍾以上的SQL解析時間。
　　基於規則優化器(RBO)：
　　（1）ORACLE 8i以及ORACLE的以前版本主要用(RBO),並且比較有效；
　　（2）通過optimizer_mode=rule來選擇RBO；通過alter session set optimizer_goal=rule來選擇
RBO; 通過添加/* + rule */來選擇RBO;
　　（3）在RBO中，from 子句的表的順序決定表的連接順序。From 子句的最后一個表是驅動表，這個
表應該是最小的表。
　　（4）限定性最強的布爾表達式放在最底層。

--跟蹤、優化SQL語句的方法
　　保證在實例級將TIMED_STATISTICS設置為TRUE(在 INIT.ORA中永久的設置它或執行 ALTER SYSTEM命
令臨時設置它)；
　　保證將MAX_DUMP_FILE_SIZE設置的較高。此參數控制跟蹤文件的大小。
　　決定USER_DUMP_DEST所指向的位置，並保證有足夠的磁盤空間。這是放置跟蹤文件的位置。
　　在應用系統運行時，打開所懷疑的回話的SQL_TRACE.(在 INIT.ORA中通過SQL_TRACE=TRUE永久的設置
對所有的回話進行跟蹤或通過使用系統包DBMS_SYSTEM.set_sql_trace_in_session(sid，serial,true);命
令臨時設置它)
　　執行業務相關操作；
　　設置跟蹤結束(DBMS_SYSTEM.set_sql_trace_in_session(sid,serial,false)，如果沒有該步驟，可能
跟蹤文件中的信息不全，因為可能有一部分還在緩存中)；
　　定位跟蹤文件；
　　對步驟6的跟蹤文件進行TKPROF，生成報告文件；
　　研究此報告文件，可以看到CPU、DISK、 QUERY、 COUNT等參數和execution plan(執行計划)，優化開
銷最大的SQL；
---------------------------------------------------------------------------------------------------------------------------------------------------
--MartriWang@gmail.com 20/05/2007--
這是因為當進行index full scan的時候 oracle定位到索引的root block，然后到branch block（如果有的話），
再定位到第一個leaf block, 然后根據leaf block的雙向鏈表順序讀取。它所讀取的塊都是有順序的，也是經過排序的。
而index fast full scan則不同，它是從段頭開始，讀取包含位圖塊，root block,所有的branch block, leaf block，
讀取的順序完全有物理存儲位置決定，並采取多塊讀，沒次讀取db_file_multiblock_read_count個塊。
索引是提高數據查詢最有效的方法，也是最難全面掌握的技術，因為正確的索引可能使效率提高10000倍，而無效的索引
可能是浪費了數據庫空間，甚至大大降低查詢性能。

　　索引的管理成本

　　1、存儲索引的磁盤空間

　　2、執行數據修改操作(INSERT、UPDATE、DELETE)產生的索引維護

　　3、在數據處理時回需額外的回退空間。

　　實際數據修改測試:

　　一個表有字段A、B、C，同時進行插入10000行記錄測試

　　在沒有建索引時平均完成時間是2.9秒

　　在對A字段建索引后平均完成時間是6.7秒

　　在對A字段和B字段建索引后平均完成時間是10.3秒

　　在對A字段、B字段和C字段都建索引后平均完成時間是11.7秒

　　從以上測試結果可以明顯看出索引對數據修改產生的影響

　　索引按存儲方法分類

　　B*樹索引

　　B*樹索引是最常用的索引，其存儲結構類似書的索引結構，
有分支和葉兩種類型的存儲數據塊，分支塊相當於書的大目錄，葉塊相當於索引到的具體的書頁。一般索引及唯一約束索引都使用B*樹索引。

　　位圖索引

　　位圖索引儲存主要用來節省空間，減少ORACLE對數據塊的訪問，它采用位圖偏移方式來與表的行ID號對應，采用位圖索引一般是重復值
太多的表字段。位圖索引在實際密集型OLTP(數據事務處理)中用得比較少，因為OLTP會對表進行大量的刪除、修改、新建操作，ORACLE每次
進行操作都會對要操作的數據塊加鎖，所以多人操作很容易產生數據塊鎖等待甚至死鎖現象。在OLAP(數據分析處理)中應用位圖有優勢，因
為OLAP中大部分是對數據庫的查詢操作，而且一般采用數據倉庫技術，所以大量數據采用位圖索引節省空間比較明顯。

　　索引按功能分類

　　唯一索引

　　唯一索引有兩個作用，一個是數據約束，一個是數據索引，其中數據約束主要用來保證數據的完整性，唯一索引產生的索引記錄中每一
條記錄都對應一個唯一的ROWID。

　　主關鍵字索引

　　主關鍵字索引產生的索引同唯一索引，只不過它是在數據庫建立主關鍵字時系統自動建立的。

　　一般索引

　　一般索引不產生數據約束作用，其功能主要是對字段建立索引表，以提高數據查詢速度。

　　索引按索引對象分類

　　單列索引(表單個字段的索引)

　　多列索引(表多個字段的索引)

　　函數索引(對字段進行函數運算的索引)

　　建立函數索引的方法:

　　create index 收費日期索引 on GC_DFSS(trunc(sk_rq))

　　create index 完全客戶編號索引 on yhzl(qc_bh||kh_bh)

　　在對函數進行了索引后，如果當前會話要引用應設置當前會話的query_rewrite_enabled為TRUE。

　　alter session set query_rewrite_enabled=true

　　注:如果對用戶函數進行索引的話，那用戶函數應加上 deterministic參數，意思是函數在輸入值固定的情況下返回值也固定。例:

　　create or replace function trunc_add(input_date date)return date deterministic

　　begin

　　return trunc(input_date+1);

　　end trunc_add;

　　應用索引的掃描分類

　　INDEX UNIQUE SCAN(按索引唯一值掃描)

　　select * from zl_yhjbqk where hbs_bh='5420016000'

　　INDEX RANGE SCAN(按索引值范圍掃描)

　　select * from zl_yhjbqk where hbs_bh>'5420016000'

　　select * from zl_yhjbqk where qc_bh>'7001'

　　INDEX FAST FULL SCAN(按索引值快速全部掃描)

　　select hbs_bh from zl_yhjbqk order by hbs_bh

　　select count(*) from zl_yhjbqk

　　select qc_bh from zl_yhjbqk group by qc_bh

　　什么情況下應該建立索引

　　表的主關鍵字

　　自動建立唯一索引

　　如zl_yhjbqk(用戶基本情況)中的hbs_bh(戶標識編號)

　　表的字段唯一約束

　　ORACLE利用索引來保證數據的完整性

　　如lc_hj(流程環節)中的lc_bh+hj_sx(流程編號+環節順序)

　　直接條件查詢的字段

　　在SQL中用於條件約束的字段

　　如zl_yhjbqk(用戶基本情況)中的qc_bh(區冊編號)

　　select * from zl_yhjbqk where qc_bh=’7001’

　　查詢中與其它表關聯的字段

　　字段常常建立了外鍵關系

　　如zl_ydcf(用電成份)中的jldb_bh(計量點表編號)

　　select * from zl_ydcf a,zl_yhdb b where a.jldb_bh=b.jldb_bh and b.jldb_bh=’540100214511’

　　查詢中排序的字段

　　排序的字段如果通過索引去訪問那將大大提高排序速度

　　select * from zl_yhjbqk order by qc_bh(建立qc_bh索引)

　　select * from zl_yhjbqk where qc_bh='7001' order by cb_sx(建立qc_bh+cb_sx索引，注:只是一個索引，其中包括qc_bh和cb_sx字段)

　　查詢中統計或分組統計的字段

　　select max(hbs_bh) from zl_yhjbqk

　　select qc_bh,count(*) from zl_yhjbqk group by qc_bh

　　什么情況下應不建或少建索引

　　表記錄太少

　　如果一個表只有5條記錄，采用索引去訪問記錄的話，那首先需訪問索引表，再通過索引表訪問數據表，一般索引表與數據表不在同一個
數據塊，這種情況下ORACLE至少要往返讀取數據塊兩次。而不用索引的情況下ORACLE會將所有的數據一次讀出，處理速度顯然會比用索引快。

　　如表zl_sybm(使用部門)一般只有幾條記錄，除了主關鍵字外對任何一個字段建索引都不會產生性能優化，實際上如果對這個表進行了統
計分析后ORACLE也不會用你建的索引，而是自動執行全表訪問。如:

　　select * from zl_sybm where sydw_bh='5401'(對sydw_bh建立索引不會產生性能優化)

　　經常插入、刪除、修改的表

　　對一些經常處理的業務表應在查詢允許的情況下盡量減少索引，如zl_yhbm，gc_dfss，gc_dfys，gc_fpdy等業務表。

　　數據重復且分布平均的表字段

　　假如一個表有10萬行記錄，有一個字段A只有T和F兩種值，且每個值的分布概率大約為50%，那么對這種表A字段建索引一般不會提高數據庫
的查詢速度。

　　經常和主字段一塊查詢但主字段索引值比較多的表字段

　　如gc_dfss(電費實收)表經常按收費序號、戶標識編號、抄表日期、電費發生年月、操作標志來具體查詢某一筆收款的情況，如果將所有的
字段都建在一個索引里那將會增加數據的修改、插入、刪除時間，從實際上分析一筆收款如果按收費序號索引就已經將記錄減少到只有幾條，如
果再按后面的幾個字段索引查詢將對性能不產生太大的影響。

　　如何只通過索引返回結果

　　一個索引一般包括單個或多個字段，如果能不訪問表直接應用索引就返回結果那將大大提高數據庫查詢的性能。對比以下三個SQL，其中對表
zl_yhjbqk的hbs_bh和qc_bh字段建立了索引:

　　1 select hbs_bh,qc_bh,xh_bz from zl_yhjbqk where qc_bh=’7001’

　　執行路徑:

　　SELECT STATEMENT, GOAL = CHOOSE 11 265 5565

　　TABLE ACCESS BY INDEX ROWID DLYX ZL_YHJBQK 11 265 5565

　　INDEX RANGE SCAN DLYX 區冊索引 1 265

　　平均執行時間(0.078秒)

　　2 select hbs_bh,qc_bh from zl_yhjbqk where qc_bh=’7001’

　　執行路徑:

　　SELECT STATEMENT, GOAL = CHOOSE 11 265 3710

　　TABLE ACCESS BY INDEX ROWID DLYX ZL_YHJBQK 11 265 3710

　　INDEX RANGE SCAN DLYX 區冊索引 1 265

　　平均執行時間(0.078秒)

　　3 select qc_bh from zl_yhjbqk where qc_bh=’7001’

　　執行路徑:

　　SELECT STATEMENT, GOAL = CHOOSE 1 265 1060

　　INDEX RANGE SCAN DLYX 區冊索引 1 265 1060

　　平均執行時間(0.062秒)

　　從執行結果可以看出第三條SQL的效率最高。執行路徑可以看出第1、2條SQL都多執行了TABLE ACCESS BY INDEX ROWID(通過ROWID訪問表)
這個步驟，因為返回的結果列中包括當前使用索引(qc_bh)中未索引的列(hbs_bh,xh_bz)，而第3條SQL直接通過QC_BH返回了結果，這就是通過
索引直接返回結果的方法。

　　如何重建索引

　　alter index 表電量結果表主鍵 rebuild

　　如何快速新建大數據量表的索引

　　如果一個表的記錄達到100萬以上的話，要對其中一個字段建索引可能要花很長的時間，甚至導致服務器數據庫死機，因為在建索引的時候
ORACLE要將索引字段所有的內容取出並進行全面排序，數據量大的話可能導致服務器排序內存不足而引用磁盤交換空間進行，這將嚴重影響服
務器數據庫的工作。解決方法是增大數據庫啟動初始化中的排序內存參數，如果要進行大量的索引修改可以設置10M以上的排序內存(ORACLE缺省
大小為64K)，在索引建立完成后應將參數修改回來，因為在實際OLTP數據庫應用中一般不會用到這么大的排序內存。

--MartriWang@gmail.com 15/06/2007--

通過分析SQL語句的執行計划優化SQL （三）
　　第4章 ORACLE的優化器

　　優化器有時也被稱為查詢優化器，這是因為查詢是影響數據庫性能最主要的部分，不要以為只有SELECT語句是查詢。實際上，帶有任何
WHERE條件的DML(INSERT、UPDATE、DELETE)語句中都包含查詢要求，在后面的文章中，當說到查詢時，不一定只是指SELECT語句，也有可能
指DML語句中的查詢部分。優化器是所有關系數據庫引擎中的最神秘、最富挑戰性的部件之一，從性能的角度看也是最重要的部分，它性能的
高低直接關系到數據庫性能的好壞。

　　我們知道，SQL語句同其它語言(如C語言)的語句不一樣，它是非過程化(non-procedural)的語句，即當你要取數據時，不需要告訴數據
庫通過何種途徑去取數據，如到底是通過索引取數據，還是應該將表中的每行數據都取出來，然后再通過一一比較的方式取數據(即全表掃描)，
這是由數據庫的優化器決定的，這就是非過程化的含義，也就是說，如何取數據是由優化器決定，而不是應用開發者通過編程決定。在處理SQL
的SELECT、UPDATE、INSERT或DELETE語句時，Oracle 必須訪問語句所涉及的數據，Oracle的優化器部分用來決定訪問數據的有效路徑，使得語
句執行所需的I/O和處理時間最小。

　　為了實現一個查詢，內核必須為每個查詢定制一個查詢策略，或為取出符合條件的數據生成一個執行計划(execution plan)。典型的，對於
同一個查詢，可能有幾個執行計划都符合要求，都能得到符合條件的數據。例如，參與連接的表可以有多種不同的連接方法，這取決於連接條件
和優化器采用的連接方法。為了在多個執行計划中選擇最優的執行計划，優化器必須使用一些實際的指標來衡量每個執行計划使用的資源(I/0次
數、CPU等)，這些資源也就是我們所說的代價(cost)。如果一個執行計划使用的資源多，我們就說使用執行計划的代價大。以執行計划的代價大
小作為衡量標准，優化器選擇代價最小的執行計划作為真正執行該查詢的執行計划，並拋棄其它的執行計划。

　　在ORACLE的發展過程中，一共開發過2種類型的優化器：基於規則的優化器和基於代價的優化器。這2種優化器的不同之處關鍵在於：取得代
價的方法與衡量代價的大小不同。現對每種優化器做一下簡單的介紹：

　　基於規則的優化器 -- Rule Based (Heuristic) Optimization(簡稱RBO)：

　　在ORACLE7之前，主要是使用基於規則的優化器。ORACLE在基於規則的優化器中采用啟發式的方法(Heuristic Approach)或規則(Rules)來生
成執行計划。例如，如果一個查詢的where條件(where clause)包含一個謂詞(predicate，其實就是一個判斷條件，如”=”, “>”, ”<”等)，而且
該謂詞上引用的列上有有效索引，那么優化器將使用索引訪問這個表，而不考慮其它因素，如表中數據的多少、表中數據的易變性、索引的可選
擇性等。此時數據庫中沒有關於表與索引數據的統計性描述，如表中有多上行，每行的可選擇性等。優化器也不考慮實例參數，如multi block
i/o、可用排序內存的大小等，所以優化器有時就選擇了次優化的計划作為真正的執行計划，導致系統性能不高。

　　如，對於select * from emp where deptno = 10這個查詢來說，如果是使用基於規則的優化器，而且deptno列上有有效的索引，則會通過
deptno列上的索引來訪問emp表。在絕大多數情況下，這是比較高效的，但是在一些特殊情況下，使用索引訪問也有比較低效的時候，現舉例說
明：　
　　1) emp表比較小，該表的數據只存放在幾個數據塊中。此時使用全表掃描比使用索引訪問emp表反而要好。因為表比較小，極有可能數據全
在內存中，所以此時做全表掃描是最快的。而如果使用索引掃描，需要先從索引中找到符合條件記錄的rowid，然后再一一根據這些rowid從emp
中將數據取出來，在這種條件下，效率就會比全表掃描的效率要差一些。

　　2) emp表比較大時，而且deptno = 10條件能查詢出表中大部分的數據如(50%)。如該表共有4000萬行數據，共放在有500000個數據塊中，
每個數據塊為8k，則該表共有約4G，則這么多的數據不可能全放在內存中，絕大多數需要放在硬盤上。此時如果該查詢通過索引查詢，則是你夢
魘的開始。db_file_multiblock_read_count參數的值200。如果采用全表掃描，則需要500000/db_file_multiblock_read_count=500000/200=
2500次I/O。但是如果采用索引掃描，假設deptno列上的索引都已經cache到內存中，所以可以將訪問索引的開銷忽略不計。因為要讀出4000萬x
50% = 2000萬數據，假設在讀這2000萬數據時，有99.9%的命中率，則還是需要20000次I/O,比上面的全表掃描需要的2500次多多了，所以在這種
情況下，用索引掃描反而性能會差很多。在這樣的情況下，用全表掃描的時間是固定的，但是用索引掃描的時間會隨着選出數據的增多使查詢時
間相應的延長。

　　上面是枯燥的假設數據，現在以具體的實例給予驗證：
　　環境: oracle 817 + linux + 陣列櫃，表SWD_BILLDETAIL有3200多萬數據；
　　表的id列、cn列上都有索引
　　經查看執行計划，發現執行select count(id) from SWD_BILLDETAIL;使用全表掃描，執行完用了大約1.50分鍾(4次執行取平均，每次分別為
1.45 1.51 2.00 1.46)。而執行select count(id) from SWD_BILLDETAIL where cn <'6';卻用了2個小時還沒有執行完，經分析該語句使用了cn列
上的索引，然后利用查詢出的rowid再從表中查詢數據。我為什么不使用select count(cn) from SWD_BILLDETAIL where cn <'6';呢？
后面在分析執行路徑的索引掃描時時會給出說明。

　　下面就是基於規則的優化器使用的執行路徑與各個路徑對應的等級：
　　RBO Path 1: Single Row by Rowid(等級最高)
　　RBO Path 2: Single Row by Cluster Join
　　RBO Path 3: Single Row by Hash Cluster Key with Unique or Primary Key
　　RBO Path 4: Single Row by Unique or Primary Key
　　RBO Path 5: Clustered Join
　　RBO Path 6: Hash Cluster Key
　　RBO Path 7: Indexed Cluster Key
　　RBO Path 8: Composite Index
　　RBO Path 9: Single-Column Indexes
　　RBO Path 10: Bounded Range Search on Indexed Columns
　　RBO Path 11: Unbounded Range Search on Indexed Columns
　　RBO Path 12: Sort Merge Join
　　RBO Path 13: MAX or MIN of Indexed Column
　　RBO Path 14: ORDER BY on Indexed Column
　　RBO Path 15: Full Table Scan(等級最低)

　　上面的執行路徑中，RBO認為越往下執行的代價越大，即等級越低。在RBO生成執行計划時，如果它發現有等級高的執行路徑可用，則肯定
會使用等級高的路徑，而不管任何其它影響性能的元素，即RBO通過上面的路徑的等級決定執行路徑的代價，執行路徑的等級越高，則使用該執
行路徑的代價越小。如上面2個例子所述，如果使用RBO，則肯定使用索引訪問表，也就是選擇了比較差的執行計划，這樣會給數據庫性能帶來很
大的負面影響。為了解決這個問題，從ORACLE 7開始oracle引入了基於代價的優化器，下面給出了介紹。

基於代價的優化器 -- Cost Based Optimization(簡稱CBO)

　　Oracle把一個代價引擎(Cost Engine)集成到數據庫內核中，用來估計每個執行計划需要的代價，該代價將每個執行計划所耗費的資源進行
量化，從而CBO可以根據這個代價選擇出最優的執行計划。一個查詢耗費的資源可以被分成3個基本組成部分：I/O代價、CPU代價、network代價。
I/O代價是將數據從磁盤讀入內存所需的代價。訪問數據包括將數據文件中數據塊的內容讀入到SGA的數據高速緩存中，在一般情況下，該代價是
處理一個查詢所需要的最主要代價，所以我們在優化時，一個基本原則就是降低查詢所產生的I/O總次數。CPU代價是處理在內存中數據所需要的
代價，如一旦數據被讀入內存，則我們在識別出我們需要的數據后，在這些數據上執行排序(sort)或連接(join)操作，這需要耗費CPU資源。

　　對於需要訪問跨節點(即通常說的服務器)數據庫上數據的查詢來說，存在network代價，用來量化傳輸操作耗費的資源。查詢遠程表的查詢
或執行分布式連接的查詢會在network代價方面花費比較大。

　　在使用CBO時，需要有表和索引的統計數據(分析數據)作為基礎數據，有了這些數據，CBO才能為各個執行計划計算出相對准確的代價，從而
使CBO選擇最佳的執行計划。所以定期的對表、索引進行分析是絕對必要的，這樣才能使統計數據反映數據庫中的真實情況。否則就會使CBO選擇
較差的執行計划，影響數據庫的性能。分析操作不必做的太頻繁，一般來說，每星期一次就足夠了。切記如果想使用CBO，則必須定期對表和索引
進行分析。

　　對於分析用的命令，隨着數據庫版本的升級，用的命令也發生了變換，在oracle 8i以前，主要是用ANALYZE命令。在ORACLE 8I以后，又引入
了DBMS_STATS存儲包來進行分析。幸運的是從ORACLE 10G以后，分析工作變成自動的了，這減輕的DBA的負擔，不過在一些特殊情況下，還需要一
些手工分析。

　　如果采用了CBO優化器，而沒有對表和索引進行分析，沒有統計數據，則ORACLE使用缺省的統計數據(至少在ORACLE 9I中是這樣)，這可以從
oracle的文檔上找到。使用的缺省值肯定與系統的實際統計值不一致，這可能會導致優化器選擇錯誤的執行計划，影響數據庫的性能。

　　要注意的是：雖然CBO的功能隨着ORACLE新版本的推出，功能越來越強，但它不是能包治百病的神葯，否則就不再需要DBA了，那我就慘了
實際上任何一個語句，隨着硬件環境與應用數據的不同，該語句的執行計划可能需要隨之發生變化，這樣才能取得最好的性能。所以有時候不
在具體的環境下而進行SQL性能調整是徒勞的。

　　在ORACLE8I推出的時候，ORACLE極力建議大家使用CBO，說CBO有種種好處，但是在那是ORACLE開發的應用系統還是使用基於規則的優化器，
從這件事上我們可以得出這樣的結論：
　　
　　1) 如果團隊的數據庫水平很高而且都熟悉應用數據的特點，RBO也可以取得很好的性能。
　　
　　2）CBO不是很穩定，但是一個比較有前途的優化器，Oracle極力建議大家用是為了讓大家盡快發現它的BUG，以便進一步改善，但是
ORACLE為了對自己開發的應用系統負責，他們還是使用了比較熟悉而且成熟的RBO。從這個事情上給我們的啟發就是：我們在以后的開發中，
應該盡量采用我們熟悉並且成熟的技術，而不要一味的采用新技術，一味采用新技術並不一定能開發出好的產品。幸運的是從ORACLE 10G后，
CBO已經足夠的強大與智能，大家可以放心的使用該技術，因為ORACLE 10G后，Oracle自己開發的應用系統也使用CBO優化器了。而且ORACLE
規定，從ORACLE 10G開始，開始廢棄RBO優化器。這句話並不是指在ORACLE 10G中不能使用RBO，而是從ORACLE 10G開始開始，不再為RBO的
BUG提供修補服務。

　　在上面的第2個例子中，如果采用CBO優化器，它就會考慮emp表的行數，deptno列的統計數據，發現對該列做查詢會查詢出過多的數據，
並且考慮db_file_multiblock_read_count參數的設置，發現用全表掃描的代價比用索引掃描的代價要小，從而使用全表掃描從而取得良好
的執行性能。

　　判斷當前數據庫使用何種優化器：

　　主要是由optimizer_mode初始化參數決定的。該參數可能的取值為：first_rows_[1 | 10 | 100 | 1000] | first_rows | all_rows |
choose | rule。具體解釋如下：
　　RULE為使用RBO優化器。
　　CHOOSE則是根據實際情況，如果數據字典中包含被引用的表的統計數據，即引用的對象已經被分析，則就使用CBO優化器，否則為RBO優
化器。
　　ALL_ROWS為CBO優化器使用的第一種具體的優化方法，是以數據的吞吐量為主要目標，以便可以使用最少的資源完成語句。
　　FIRST_ROWS為優化器使用的第二種具體的優化方法，是以數據的響應時間為主要目標，以便快速查詢出開始的幾行數據。
　　FIRST_ROWS_[1 | 10 | 100 | 1000] 為優化器使用的第三種具體的優化方法，讓優化器選擇一個能夠把響應時間減到最小的查詢執行
計划，以迅速產生查詢結果的前 n 行。該參數為ORACLE 9I新引入的。

　　從ORACLE V7以來，optimizer_mode參數的缺省設置應是"choose"，即如果對已分析的表查詢的話選擇CBO，否則選擇RBO。在此種設置中，
如果采用了CBO，則缺省為CBO中的all_rows模式。

　　注意：即使指定數據庫使用RBO優化器，但有時ORACLE數據庫還是會采用CBO優化器，這並不是ORACLE的BUG，主要是由於從ORACLE 8I后引
入的許多新特性都必須在CBO下才能使用，而你的SQL語句可能正好使用了這些新特性，此時數據庫會自動轉為使用CBO優化器執行這些語句。

　　什么是優化

　　優化是選擇最有效的執行計划來執行SQL語句的過程，這是在處理任何數據的語句（SELECT,INSERT,UPDATE或DELETE）中的一個重要步驟。
對Oracle來說，執行這樣的語句有許多不同的方法，譬如說，將隨着以什么順序訪問哪些表或索引的不同而不同。所使用的執行計划可以決定
語句能執行得有多快。Oracle中稱之為優化器（Optimizer）的組件用來選擇這種它認為最有效的執行計划。

　　由於一系列因素都會會影響語句的執行，優化器綜合權衡各個因素，在眾多的執行計划中選擇認為是最佳的執行計划。然而，應用設計人
員通常比優化器更知道關於特定應用的數據特點。無論優化器多么智能，在某些情況下開發人員能選擇出比優化器選擇的最優執行計划還要好
的執行計划。這是需要人工干預數據庫優化的主要原因。事實表明，在某些情況下，確實需要DBA對某些語句進行手工優化。
　　注：從Oracle的一個版本到另一個版本，優化器可能對同一語句生成不同的執行計划。在將來的Oracle 版本中，優化器可能會基於它可以
用的更好、更理想的信息，作出更優的決策，從而導致為語句產生更優的執行計划。

在物理層，oracle讀取數據，一次讀取的最小單位為數據庫塊(由多個連續的操作系統塊組成)，一次讀取的最大值由操作系統一次I/O的最大值
與multiblock參數共同決定，所以即使只需要一行數據，也是將該行所在的數據庫塊讀入內存。邏輯上，oracle用如下存取方法訪問數據：
--MartriWang@gmail.com 15/06/2007--

　　1) 全表掃描（Full Table Scans, FTS）

　　為實現全表掃描，Oracle讀取表中所有的行，並檢查每一行是否滿足語句的WHERE限制條件。Oracle順序地讀取分配給表的每個數據塊，直
到讀到表的最高水線處(high water mark, HWM，標識表的最后一個數據塊)。一個多塊讀操作可以使一次I/O能讀取多塊數據塊
(db_block_multiblock_read_count參數設定)，而不是只讀取一個數據塊，這極大的減少了I/O總次數，提高了系統的吞吐量，所以利用多塊讀
的方法可以十分高效地實現全表掃描，而且只有在全表掃描的情況下才能使用多塊讀操作。在這種訪問模式下，每個數據塊只被讀一次。由於
HWM標識最后一塊被讀入的數據，而delete操作不影響HWM值，所以一個表的所有數據被delete后，其全表掃描的時間不會有改善，一般我們需要
使用truncate命令來使HWM值歸為0。幸運的是oracle 10G后，可以人工收縮HWM的值。

　　由FTS模式讀入的數據被放到高速緩存的Least Recently Used (LRU)列表的尾部，這樣可以使其快速交換出內存，從而不使內存重要的數據
被交換出內存。使用FTS的前提條件：在較大的表上不建議使用全表掃描，除非取出數據的比較多，超過總量的5% -- 10%，或你想使用並行查詢
功能時。
　　使用全表掃描的例子：
　　~~~~~~~~~~~~~~~~~~~~~~~~
SQL> explain plan for select * from dual;
Query Plan
-----------------------------------------
SELECT STATEMENT [CHOOSE] Cost=
TABLE ACCESS FULL DUAL

　　2) 通過ROWID的表存取（Table Access by ROWID或rowid lookup）

　　行的ROWID指出了該行所在的數據文件、數據塊以及行在該塊中的位置，所以通過ROWID來存取數據可以快速定位到目標數據上，是Oracle存取
單行數據的最快方法。為了通過ROWID存取表，Oracle 首先要獲取被選擇行的ROWID，或者從語句的WHERE子句中得到，或者通過表的一個或多個索
引的索引掃描得到。Oracle然后以得到的ROWID為依據定位每個被選擇的行。

　　這種存取方法不會用到多塊讀操作，一次I/O只能讀取一個數據塊。我們會經常在執行計划中看到該存取方法，如通過索引查詢數據。

　　使用ROWID存取的方法：
SQL> explain plan for select * from dept where rowid = 'AAAAyGAADAAAAATAAF';
Query Plan
------------------------------------
SELECT STATEMENT [CHOOSE] Cost=1
TABLE ACCESS BY ROWID DEPT [ANALYZED]

3）索引掃描（Index Scan或index lookup）

　　我們先通過index查找到數據對應的rowid值(對於非唯一索引可能返回多個rowid值)，然后根據rowid直接從表中得到具體的數據，這種查找方式
稱為索引掃描或索引查找(index lookup)。一個rowid唯一的表示一行數據，該行對應的數據塊是通過一次i/o得到的，在此情況下該次i/o只會讀取
一個數據庫塊。

　　在索引中，除了存儲每個索引的值外，索引還存儲具有此值的行對應的ROWID值。索引掃描可以由2步組成：
　　(1) 掃描索引得到對應的rowid值。
　　(2) 通過找到的rowid從表中讀出具體的數據。每步都是單獨的一次I/O，但是對於索引，由於經常使用，絕大多數都已經CACHE到內存中，所以第
1步的I/O經常是邏輯I/O，即數據可以從內存中得到。但是對於第2步來說，如果表比較大，則其數據不可能全在內存中，所以其I/O很有可能是物理I/O，
這是一個機械操作，相對邏輯I/O來說，是極其費時間的。所以如果多大表進行索引掃描，取出的數據如果大於總量的5% -- 10%，使用索引掃描會效率
下降很多。
　　如下列所示：
SQL> explain plan for select empno, ename from emp where empno=10;
Query Plan
------------------------------------
SELECT STATEMENT [CHOOSE] Cost=1
TABLE ACCESS BY ROWID EMP [ANALYZED]
INDEX UNIQUE SCAN EMP_I1

　　注意TABLE ACCESS BY ROWID EMP部分，這表明這不是通過FTS存取路徑訪問數據，而是通過rowid lookup存取路徑訪問數據的。在此例中，所需要
的rowid是由於在索引查找empno列的值得到的，這種方式是INDEX UNIQUE SCAN查找，后面給予介紹，EMP_I1為使用的進行索引查找的索引名字。

　　但是如果查詢的數據能全在索引中找到，就可以避免進行第2步操作，避免了不必要的I/O，此時即使通過索引掃描取出的數據比較多，效率還是很
高的，因為這只會在索引中讀取。所以上面我在介紹基於規則的優化器時，使用了select count(id) from SWD_BILLDETAIL where cn <'6'，而沒有使
用select count(cn) from SWD_BILLDETAIL where cn <'6'。因為在實際情況中，只查詢被索引列的值的情況極為少，所以，如果我在查詢中使用count
(cn)，則不具有代表性。

SQL> explain plan for select empno from emp where empno=10; -- 只查詢empno列值
Query Plan
------------------------------------
SELECT STATEMENT [CHOOSE] Cost=1
INDEX UNIQUE SCAN EMP_I1

　　進一步講，如果sql語句中對索引列進行排序，因為索引已經預先排序好了，所以在執行計划中不需要再對索引列進行排序

SQL> explain plan for select empno, ename from emp
where empno > 7876 order by empno;
Query Plan
--------------------------------------------------------------------------------
SELECT STATEMENT [CHOOSE] Cost=1
TABLE ACCESS BY ROWID EMP [ANALYZED]
INDEX RANGE SCAN EMP_I1 [ANALYZED]

　　從這個例子中可以看到：因為索引是已經排序了的，所以將按照索引的順序查詢出符合條件的行，因此避免了進一步排序操作。

　　根據索引的類型與where限制條件的不同，有4種類型的索引掃描：
　　索引唯一掃描(index unique scan)
　　索引范圍掃描(index range scan)
　　索引全掃描(index full scan)
　　索引快速掃描(index fast full scan)

　　(1) 索引唯一掃描(index unique scan)

　　通過唯一索引查找一個數值經常返回單個ROWID。如果該唯一索引有多個列組成(即組合索引)，則至少要有組合索引的引導列參
與到該查詢中，如創建一個索引：
create index idx_test on emp(ename, deptno, loc)。則select ename from emp where ename = 'JACK' and deptno = 'DEV'語
句可以使用該索引。如果該語句只返回一行，則存取方法稱為索引唯一掃描。而select ename from emp where deptno = 'DEV'語句
則不會使用該索引，因為where子句種沒有引導列。如果存在UNIQUE 或PRIMARY KEY 約束（它保證了語句只存取單行）的話，

Oracle經常實現唯一性掃描。
　　使用唯一性約束的例子：
SQL> explain plan for
select empno,ename from emp where empno=10;
Query Plan
------------------------------------
SELECT STATEMENT [CHOOSE] Cost=1
TABLE ACCESS BY ROWID EMP [ANALYZED]
INDEX UNIQUE SCAN EMP_I1

　　(2) 索引范圍掃描(index range scan)

　　使用一個索引存取多行數據，同上面一樣，如果索引是組合索引，如(1)所示，
而且select ename from emp where ename = 'JACK' and deptno = 'DEV'語句返回多行數據，雖然該語句還是使用該組合索引進行查
詢，可此時的存取方法稱為索引范圍掃描。在唯一索引上使用索引范圍掃描的典型情況下是在謂詞(where限制條件)中使用了范圍操作
符(如>、<、<>、>=、<=、between)

　　使用索引范圍掃描的例子：
SQL> explain plan for select empno,ename from emp
where empno > 7876 order by empno;
Query Plan
--------------------------------------------------------------------------------
SELECT STATEMENT [CHOOSE] Cost=1
TABLE ACCESS BY ROWID EMP [ANALYZED]
INDEX RANGE SCAN EMP_I1 [ANALYZED]

　　在非唯一索引上，謂詞col = 5可能返回多行數據，所以在非唯一索引上都使用索引范圍掃描。
　　使用index rang scan的3種情況：
　　(a) 在唯一索引列上使用了range操作符(> < <> >= <= between)
　　(b) 在組合索引上，只使用部分列進行查詢，導致查詢出多行
　　(c) 對非唯一索引列上進行的任何查詢。

　　(3) 索引全掃描(index full scan)

　　與全表掃描對應，也有相應的全索引掃描。在某些情況下，可能進行全索引掃描而不是范圍掃描，需要注意的是全索引掃描只在
CBO模式下才有效。CBO根據統計數值得知進行全索引掃描比進行全表掃描更有效時，才進行全索引掃描，而且此時查詢出的數據都必
須從索引中可以直接得到。
　　全索引掃描的例子：
An Index full scan will not perform single block i/o s and so it may prove to be inefficient.

e.g.
Index BE_IX is a concatenated index on big_emp (empno, ename)

SQL> explain plan for select empno, ename from big_emp order by empno,ename;
Query Plan
--------------------------------------------------------------------------------
SELECT STATEMENT [CHOOSE] Cost=26
INDEX FULL SCAN BE_IX [ANALYZED]

　　(4) 索引快速掃描(index fast full scan)

　　掃描索引中的所有的數據塊，與 index full scan很類似，但是一個顯著的區別就是它不對查詢出的數據進行排序，即數據不是
以排序順序被返回。在這種存取方法中，可以使用多塊讀功能，也可以使用並行讀入，以便獲得最大吞吐量與縮短執行時間。

　　索引快速掃描的例子：
　　BE_IX索引是一個多列索引：big_emp (empno,ename)

SQL> explain plan for select empno,ename from big_emp;
Query Plan
------------------------------------------
SELECT STATEMENT [CHOOSE] Cost=1
INDEX FAST FULL SCAN BE_IX [ANALYZED]

　　只選擇多列索引的第2列：

SQL> explain plan for select ename from big_emp;
Query Plan
------------------------------------------
SELECT STATEMENT [CHOOSE] Cost=1
INDEX FAST FULL SCAN BE_IX [ANALYZED]

--MartriWang@gmail.com 15/06/2007--
表之間的連接

　　Join是一種試圖將兩個表結合在一起的謂詞，一次只能連接2個表，表連接也可以被稱為表關聯。在后面的敘述中，我們將會使用”row

source”來代替”表”，因為使用row source更嚴謹一些，並且將參與連接的2個row source分別稱為row source1和row source 2。Join過程

的各個步驟經常是串行操作，即使相關的row source可以被並行訪問，即可以並行的讀取做join連接的兩個row source的數據，但是在將表中

符合限制條件的數據讀入到內存形成row source后，join的其它步驟一般是串行的。有多種方法可以將2個表連接起來，當然每種方法都有自己

的優缺點，每種連接類型只有在特定的條件下才會發揮出其最大優勢。

　　row source(表)之間的連接順序對於查詢的效率有非常大的影響。通過首先存取特定的表，即將該表作為驅動表，這樣可以先應用某些限

制條件，從而得到一個較小的row source，使連接的效率較高，這也就是我們常說的要先執行限制條件的原因。一般是在將表讀入內存時，應

用where子句中對該表的限制條件。

　　根據2個row source的連接條件的中操作符的不同，可以將連接分為等值連接(如WHERE A.COL3 = B.COL4)、非等值連接(WHERE A.COL3 >

B.COL4)、外連接(WHERE A.COL3 = B.COL4(+))。上面的各個連接的連接原理都基本一樣，所以為了簡單期間，下面以等值連接為例進行介紹。

在后面的介紹中，都已：
　　SELECT A.COL1, B.COL2
　　FROM A, B
　　WHERE A.COL3 = B.COL4;

　　為例進行說明，假設A表為Row Soruce1，則其對應的連接操作關聯列為COL 3；B表為Row Soruce2，則其對應的連接操作關聯列為COL 4；

　　連接類型：

　　目前為止，無論連接操作符如何，典型的連接類型共有3種：
　　排序 - - 合並連接(Sort Merge Join (SMJ) )
　　嵌套循環(Nested Loops (NL) )
　　哈希連接(Hash Join)

　　排序 - - 合並連接(Sort Merge Join, SMJ)

　　內部連接過程：
　　1) 首先生成row source1需要的數據，然后對這些數據按照連接操作關聯列(如A.col3)進行排序。
　　2) 隨后生成row source2需要的數據，然后對這些數據按照與sort source1對應的連接操作關聯列(如B.col4)進行排序。
　　3) 最后兩邊已排序的行被放在一起執行合並操作，即將2個row source按照連接條件連接起來
　　下面是連接步驟的圖形表示：
　　　　　　　　　　　　　MERGE
　　　　　　　　　　　　/　　　 \
　　　　　　　　　　 SORT 　　　 SORT
　　　　　　　　　　　| 　　　　　|
　　　　　　　Row Source 1　　　 Row Source 2

　　如果row source已經在連接關聯列上被排序，則該連接操作就不需要再進行sort操作，這樣可以大大提高這種連接操作的連接速度，因為

排序是個極其費資源的操作，特別是對於較大的表。預先排序的row source包括已經被索引的列(如a.col3或b.col4上有索引)或row source已

經在前面的步驟中被排序了。盡管合並兩個row source的過程是串行的，但是可以並行訪問這兩個row source(如並行讀入數據，並行排序).

　　SMJ連接的例子：

SQL> explain plan for
select /*+ ordered */ e.deptno, d.deptno
from emp e, dept d
where e.deptno = d.deptno
order by e.deptno, d.deptno;

Query Plan
-------------------------------------
SELECT STATEMENT [CHOOSE] Cost=17
MERGE JOIN
SORT JOIN
TABLE ACCESS FULL EMP [ANALYZED]
SORT JOIN
TABLE ACCESS FULL DEPT [ANALYZED]

　　排序是一個費時、費資源的操作，特別對於大表。基於這個原因，SMJ經常不是一個特別有效的連接方法，但是如果2個row source都已經

預先排序，則這種連接方法的效率也是蠻高的。

　　嵌套循環(Nested Loops, NL)

　　這個連接方法有驅動表(外部表)的概念。其實，該連接過程就是一個2層嵌套循環，所以外層循環的次數越少越好，這也就是我們為什么將

小表或返回較小row source的表作為驅動表(用於外層循環)的理論依據。但是這個理論只是一般指導原則，因為遵循這個理論並不能總保證使

語句產生的I/O次數最少。有時不遵守這個理論依據，反而會獲得更好的效率。如果使用這種方法，決定使用哪個表作為驅動表很重要。有時如

果驅動表選擇不正確，將會導致語句的性能很差、很差。

　　內部連接過程：
　　Row source1的Row 1 -------------- -- Probe -> Row source 2
　　Row source1的Row 2 -------------- -- Probe -> Row source 2
　　Row source1的Row 3 -------------- -- Probe -> Row source 2
　　…….
　　Row source1的Row n -------------- -- Probe -> Row source 2

　　從內部連接過程來看，需要用row source1中的每一行，去匹配row source2中的所有行，所以此時保持row source1盡可能的小與高效的訪

問row source2(一般通過索引實現)是影響這個連接效率的關鍵問題。這只是理論指導原則，目的是使整個連接操作產生最少的物理I/O次數，

而且如果遵守這個原則，一般也會使總的物理I/O數最少。但是如果不遵從這個指導原則，反而能用更少的物理I/O實現連接操作，那盡管違反

指導原則吧！因為最少的物理I/O次數才是我們應該遵從的真正的指導原。

　　在上面的連接過程中，我們稱Row source1為驅動表或外部表。Row Source2被稱為被探查表或內部表。

　　在NESTED LOOPS連接中，Oracle讀取row source1中的每一行，然后在row sourc2中檢查是否有匹配的行，所有被匹配的行都被放到結果集

中，然后處理row source1中的下一行。這個過程一直繼續，直到row source1中的所有行都被處理。這是從連接操作中可以得到第一個匹配行

的最快的方法之一，這種類型的連接可以用在需要快速響應的語句中，以響應速度為主要目標。

　　如果driving row source(外部表)比較小，並且在inner row source(內部表)上有唯一索引，或有高選擇性非唯一索引時，使用這種方法

可以得到較好的效率。NESTED LOOPS有其它連接方法沒有的的一個優點是：可以先返回已經連接的行，而不必等待所有的連接操作處理完才返

回數據，這可以實現快速的響應時間。

　　如果不使用並行操作，最好的驅動表是那些應用了where 限制條件后，可以返回較少行數據的的表，所以大表也可能稱為驅動表，關鍵看

限制條件。對於並行查詢，我們經常選擇大表作為驅動表，因為大表可以充分利用並行功能。當然，有時對查詢使用並行操作並不一定會比查

詢不使用並行操作效率高，因為最后可能每個表只有很少的行符合限制條件，而且還要看你的硬件配置是否可以支持並行(如是否有多個CPU，

多個硬盤控制器)，所以要具體問題具體對待。

　　NL連接的例子：
SQL> explain plan for
select a.dname,b.sql
from dept a,emp b
where a.deptno = b.deptno;

Query Plan
-------------------------
SELECT STATEMENT [CHOOSE] Cost=5
NESTED LOOPS
TABLE ACCESS FULL DEPT [ANALYZED]
TABLE ACCESS FULL EMP [ANALYZED]

　　哈希連接(Hash Join, HJ)

　　這種連接是在oracle 7.3以后引入的，從理論上來說比NL與SMJ更高效，而且只用在CBO優化器中。較小的row source被用來構建hash

table與bitmap，第2個row source被用來被hansed，並與第一個row source生成的hash table進行匹配，以便進行進一步的連接。Bitmap被用

來作為一種比較快的查找方法，來檢查在hash table中是否有匹配的行。特別的，當hash table比較大而不能全部容納在內存中時，這種查找

方法更為有用。這種連接方法也有NL連接中所謂的驅動表的概念，被構建為hash table與bitmap的表為驅動表，當被構建的hash table與

bitmap能被容納在內存中時，這種連接方式的效率極高。

　　HASH連接的例子：
SQL> explain plan for
select /*+ use_hash(emp) */ empno
from emp, dept
where emp.deptno = dept.deptno;

Query Plan
----------------------------
SELECT STATEMENT [CHOOSE] Cost=3
HASH JOIN
TABLE ACCESS FULL DEPT
TABLE ACCESS FULL EMP

　　要使哈希連接有效，需要設置HASH_JOIN_ENABLED=TRUE，缺省情況下該參數為TRUE，另外，不要忘了還要設置hash_area_size參數，以使

哈希連接高效運行，因為哈希連接會在該參數指定大小的內存中運行，過小的參數會使哈希連接的性能比其他連接方式還要低。

　　總結一下，在哪種情況下用哪種連接方法比較好：

　　排序 - - 合並連接(Sort Merge Join, SMJ)：
　　a) 對於非等值連接，這種連接方式的效率是比較高的。
　　b) 如果在關聯的列上都有索引，效果更好。
　　c) 對於將2個較大的row source做連接，該連接方法比NL連接要好一些。
　　d) 但是如果sort merge返回的row source過大，則又會導致使用過多的rowid在表中查詢數據時，數據庫性能下降，因為過多的I/O。

　　嵌套循環(Nested Loops, NL)：
　　a) 如果driving row source(外部表)比較小，並且在inner row source(內部表)上有唯一索引，或有高選擇性非唯一索引時，使用這種方

法可以得到較好的效率。
　　b) NESTED LOOPS有其它連接方法沒有的的一個優點是：可以先返回已經連接的行，而不必等待所有的連接操作處理完才返回數據，這可以

實現快速的響應時間。

　　哈希連接(Hash Join, HJ)：
　　a) 這種方法是在oracle7后來引入的，使用了比較先進的連接理論，一般來說，其效率應該好於其它2種連接，但是這種連接只能用在CBO

優化器中，而且需要設置合適的hash_area_size參數，才能取得較好的性能。
　　b) 在2個較大的row source之間連接時會取得相對較好的效率，在一個row source較小時則能取得更好的效率。
　　c) 只能用於等值連接中

　　笛卡兒乘積(Cartesian Product)

　　當兩個row source做連接，但是它們之間沒有關聯條件時，就會在兩個row source中做笛卡兒乘積，這通常由編寫代碼疏漏造成(即程序員

忘了寫關聯條件)。笛卡爾乘積是一個表的每一行依次與另一個表中的所有行匹配。在特殊情況下我們可以使用笛卡兒乘積，如在星形連接中，

除此之外，我們要盡量使用笛卡兒乘積，否則，自己想結果是什么吧！

　　注意在下面的語句中，在2個表之間沒有連接。
SQL> explain plan for
select emp.deptno,dept,deptno
from emp,dept

Query Plan
------------------------------
SLECT STATEMENT [CHOOSE] Cost=5
MERGE JOIN CARTESIAN
TABLE ACCESS FULL DEPT
SORT JOIN
TABLE ACCESS FULL EMP

　　CARTESIAN關鍵字指出了在2個表之間做笛卡爾乘積。假如表emp有n行，dept表有m行，笛卡爾乘積的結果就是得到n * m行結果。
使用全套的hints：
　　當使用hints時，在某些情況下，為了確保讓優化器產生最優的執行計划，我們可能指定全套的hints。例如，如果有一個復雜的查詢，
包含多個表連接，如果你只為某個表指定了INDEX提示(指示存取路徑在該表上使用索引)，優化器需要來決定其它應該使用的訪問路徑和相
應的連接方法。因此，即使你給出了一個INDEX提示，優化器可能覺得沒有必要使用該提示。這是由於我們讓優化器選擇了其它連接方法和
存取路徑，而基於這些連接方法和存取路徑，優化器認為用戶給出的INDEX提示無用。為了防止這種情況，我們要使用全套的hints，如不
但指定要使用的索引，而且也指定連接的方法與連接的順序等。
　　
--MartriWang@gmail.com 15/06/2007--
使用全套hints的例子，ORDERED提示指出了連接的順序，而且為不同的表指定了連接方法：

SELECT /*+ ORDERED INDEX (b, jl_br_balances_n1) USE_NL (j b)
USE_NL (glcc glf) USE_MERGE (gp gsb) */
b.application_id, b.set_of_books_id ,
b.personnel_id, p.vendor_id Personnel,
p.segment1 PersonnelNumber, p.vendor_name Name
FROM jl_br_journals j, jl_br_balances b,
gl_code_combinations glcc, fnd_flex_values_vl glf,
gl_periods gp, gl_sets_of_books gsb, po_vendors p
WHERE ...

　　指示優化器的方法與目標的hints：

ALL_ROWS -- 基於代價的優化器，以吞吐量為目標
FIRST_ROWS(n) -- 基於代價的優化器，以響應時間為目標
CHOOSE -- 根據是否有統計信息，選擇不同的優化器
RULE -- 使用基於規則的優化器

　　例子：
SELECT /*+ FIRST_ROWS(10) */ employee_id, last_name, salary, job_id
FROM employees
WHERE department_id = 20;

SELECT /*+ CHOOSE */ employee_id, last_name, salary, job_id
FROM employees
WHERE employee_id = 7566;

SELECT /*+ RULE */ employee_id, last_name, salary, job_id
FROM employees
WHERE employee_id = 7566;

　　指示存儲路徑的hints：

FULL 　　/*+ FULL ( table ) */
　　　　　指定該表使用全表掃描
ROWID 　/*+ ROWID ( table ) */
　　　　　指定對該表使用rowid存取方法，該提示用的較少
INDEX 　/*+ INDEX ( table [index]) */
　　　　　使用該表上指定的索引對表進行索引掃描
INDEX_FFS /*+ INDEX_FFS ( table [index]) */
　　　　　使用快速全表掃描
NO_INDEX /*+ NO_INDEX ( table [index]) */
　　　　　不使用該表上指定的索引進行存取，仍然可以使用其它的索引進行索引掃描

SELECT /*+ FULL(e) */ employee_id, last_name
FROM employees e
WHERE last_name LIKE :b1;

SELECT /*+ROWID(employees)*/ *
FROM employees
WHERE rowid > 'AAAAtkAABAAAFNTAAA' AND employee_id = 155;

SELECT /*+ INDEX(A sex_index) use sex_index because there are few
male patients */ A.name, A.height, A.weight
FROM patients A
WHERE A.sex = 'm';

SELECT /*+NO_INDEX(employees emp_empid)*/ employee_id
FROM employees
WHERE employee_id > 200;

　　指示連接順序的hints:
ORDERED 　/*+ ORDERED */
　　　　　按from 字句中表的順序從左到右的連接
STAR 　　/*+ STAR */
　　　　　指示優化器使用星型查詢

SELECT /*+ORDERED */ o.order_id, c.customer_id, l.unit_price * l.quantity
FROM customers c, order_items l, orders o
WHERE c.cust_last_name = :b1
AND o.customer_id = c.customer_id
AND o.order_id = l.order_id;

/*+ ORDERED USE_NL(FACTS) INDEX(facts fact_concat) */

指示連接類型的hints：
USE_NL 　/*+ USE_NL ( table [,table, ...] ) */
　　　　　使用嵌套連接
USE_MERGE /*+ USE_MERGE ( table [,table, ...]) */
　　　　　使用排序- -合並連接
USE_HASH /*+ USE_HASH ( table [,table, ...]) */
　　　　　使用HASH連接
注意：如果表有alias(別名)，則上面的table指的是表的別名，而不是真實的表名

--MartriWang@gmail.com 25/06/2007--

oracle最重要的9個動態性能視圖！

v$session + v$session_wait
v$process
v$sql
v$sqltext
v$bh (更寧願是x$bh)
v$lock
v$latch_children
v$sysstat
v$system_event

按組分的幾組重要的性能視圖

1。System 的 over view
v$sysstat , v$system_event , v$parameter

2。某個session 的當前情況
v$process , v$session , v$session_wait ,v$session_event , v$sesstat

3。SQL 的情況
v$sql , v$sqlarea , v$SQL_PLAN , V$SQL_PLAN_STATISTICS, v$sqltext_with_newlines

3. Latch / lock /ENQUEUE
v$latch , v$latch_children , v$latch_holder , v$lock ,V$ENQUEUE_STAT ,V$ENQUEUE_LOCK

4. IO 方面的
v$segstat , v$filestat , v$tempstat ,v$datafile , v$tempfile

5.shared pool / Library cache
v$Librarycache , v$rowcache , x$ksmsp

6.幾個advice也不錯
v$db_cache_advice , v$PGA_TARGET_ADVICE, v$SHARED_POOL_ADVICE

轉載自：

Oracle調優總結收藏
/*==========================================================================
*Author: MartriWang@gmail.com
*Date: 09/05/2007
*Description:ORACLE Summary
*==========================================================================*/
Problem Description:
1.每個表的結構及主鍵索引情況
2.每個表的count(*)記錄是多少
3.對於創建索引的列，索引的類型是什么？count(distinct indexcol)的值是多少？
4.最后一次對表進行分析是在什么時間，分析后，是否又對相關表做過大的操作
5.索引最后一次rebuild，是在什么時間，此后對表的操作類型又是什么狀況？索引中浪費的空間是多少？
6.這些表的存儲情況，表的存儲參數，表空間的類型，存儲參數等
7.執行該SQL語句時，系統等候的資源是什么？ Trace SQL語句的執行過程
8.另一台執行相似SQL速度很快的機器上的相關表的如上信息是什么？