rowid的概念：
rowid是乙個偽列，既然是偽列，那麼這個列就不是使用者定義，而是系統自己給加上的。對每個表都有乙個rowid的偽列，但是表中並不物理儲存rowid列的值。不過你可以像使用其它列那樣使用它，但是不能刪除改列，也不能對該列的值進行修改、插入。一旦一行資料插入資料庫，則rowid在該行的生命週期內是唯一的，即即使該行產生行遷移，行的rowid也不會改變。
為什麼使用rowid
rowid對訪問乙個表中的給定的行提供了最快的訪問方法，通過rowid可以直接定位到相應的資料塊上，然後將其讀到記憶體。我們建立乙個索引時，該索引不但儲存索引列的值，而且也儲存索引值所對應的行的rowid，這樣我們通過索引快速找到相應行的rowid後，通過該rowid，就可以迅速將資料查詢出來。這也就是我們使用索引查詢時，速度比較快的原因。
在oracle8以前的版本中，rowid由file 、block、row number構成。隨著oracle8中物件概念的擴充套件，rowid發生了變化，rowid由object、file、block、row number構成。利用dbms_rowid可以將rowid分解成上述的各部分，也可以將上述的各部分組成乙個有效的rowid。
recursive
sql概念
有時為了執行使用者發出的乙個
sql語句，oracle必須執行一些額外的語句，我們將這些額外的語句稱之為'recursive calls'或'recursive
sql statements'。如當乙個ddl語句發出後，oracle總是隱含的發出一些recursive
sql語句，來修改資料字典資訊，以便使用者可以成功的執行該ddl語句。當需要的資料字典資訊沒有在共享記憶體中時，經常會發生recursive calls，這些recursive calls會將資料字典資訊從硬碟讀入記憶體中。使用者不比關心這些recursive
sql語句的執**況，在需要的時候，oracle會自動的在內部執行這些語句。當然dml語句與select都可能引起recursive
sql。簡單的說，我們可以將觸發器視為recursive
sql。
row source(行源)
用在查詢中，由上一操作返回的符合條件的行的集合，即可以是表的全部行資料的集合；也可以是表的部分行資料的集合；也可以為對上2個row source進行連線操作(如join連線)後得到的行資料集合。
predicate(謂詞)
乙個查詢中的where限制條件
driving table(驅動表)
該錶又稱為外層表(outer table)。這個概念用於巢狀與hash連線中。如果該row source返回較多的行資料，則對所有的後續操作有負面影響。注意此處雖然翻譯為驅動表，但實際上翻譯為驅動行源(driving row source)更為確切。一般說來，是應用查詢的限制條件後，返回較少行源的表作為驅動表，所以如果乙個大表在where條件有有限制條件(如等值限制)，則該大表作為驅動表也是合適的，所以並不是只有較小的表可以作為驅動表，正確說法應該為應用查詢的限制條件後，返回較少行源的表作為驅動表。在執行計畫中，應該為靠上的那個row source，後面會給出具體說明。在我們後面的描述中，一般將該錶稱為連線操作的row source 1。
probed table(被探查表)
該錶又稱為內層表(inner table)。在我們從驅動表中得到具體一行的資料後，在該表中尋找符合連線條件的行。所以該錶應當為大表(實際上應該為返回較大row source的表)且相應的列上應該有索引。在我們後面的描述中，一般將該錶稱為連線操作的row source 2。
組合索引(concatenated index)
由多個列構成的索引，如create index idx_emp on emp(col1, col2, col3, ……)，則我們稱idx_emp索引為組合索引。在組合索引中有乙個重要的概念：引導列(leading column)，在上面的例子中，col1列為引導列。當我們進行查詢時可以使用」where col1 = ? 」，也可以使用」where col1 = ? and col2 = ?」，這樣的限制條件都會使用索引，但是」where col2 = ? 」查詢就不會使用該索引。所以限制條件中包含先導列時，該限制條件才會使用該組合索引。
可選擇性(selectivity)：
比較一下列中唯一鍵的數量和表中的行數，就可以判斷該列的可選擇性。如果該列的」唯一鍵的數量/表中的行數」的比值越接近1，則該列的可選擇性越高，該列就越適合建立索引，同樣索引的可選擇性也越高。在可選擇性高的列上進行查詢時，返回的資料就較少，比較適合使用索引查詢。
有了這些背景知識後就開始介紹執行計畫。為了執行語句，oracle可能必須實現許多步驟。這些步驟中的每一步可能是從資料庫中物理檢索資料行，或者用某種方法準備資料行，供發出語句的使用者使用。oracle用來執行語句的這些步驟的組合被稱之為執行計畫。執行計畫是
sql優化中最為複雜也是最為關鍵的部分，只有知道了oracle在內部到底是如何執行該
sql語句後，我們才能知道優化器選擇的執行計畫是否為最優的。執行計畫對於dba來說，就象財務報表對於財務人員一樣重要。所以我們面臨的問題主要是：如何得到執行計畫；如何分析執行計畫，從而找出影響效能的主要問題。下面先從分析樹型執行計畫開始介紹，然後介紹如何得到執行計畫，再介紹如何分析執行計畫。
舉例：
這個例子顯示關於下面
sql語句的執行計畫。
select ename, job, sal, dname from emp, dept where emp.deptno = derpt.deptno and not exists ( select * from salgrade where emp.sal between losal and hisal );
此語句查詢薪水不在任何建議薪水範圍內的所有雇員的名字，工作，薪水和部門名。
通過分析SQL語句的執行計畫優化SQL （二）
第1章 效能調整綜述 oracle資料庫是高度可調的資料庫產品。本章描述調整的過程和那些人員應與oracle伺服器的調整有關，以及與調整相關聯的作業系統硬體和軟體。本章包括以下方面 l 誰來調整系統?l 什麼時候調整?l 建立有效調整的目標 l 在設計和開發時的調整 l 調整產品系統 l 監控產品系...
通過分析SQL語句的執行計畫優化SQL 四
五 oracle的執行計畫 背景知識 為了更好的進行下面的內容我們必須了解一些概念性的術語 共享sql語句 為了不重複解析相同的sql語句 因為解析操作比較費資源，會導致效能下降 在第一次解析之後，oracle將sql語句及解析後得到的執行計畫存放在記憶體中。這塊位於系統全域性區域sga syste...
通過分析SQL語句的執行計畫優化SQL 三
四 oracle的優化器 優化器有時也被稱為查詢優化器，這是因為查詢是影響資料庫效能最主要的部分，不要以為只有select語句是查詢。實際上，帶有任何where條件的dml insert update delete 語句中都包含查詢要求，在後面的文章中，當說到查詢時，不一定只是指select語句，也...