Oracle數據庫厲行計劃的相關知識是本文我們主要要介紹的內容，我們首先介紹了厲行計劃的概念，然后給出了兩個厲行計劃的實例進行說明，最后介紹了Oracle優化器的形式以及厲行計劃對我們的用途，接下來就讓我們一起來了解一下這部分內容。

Q：什么是厲行計劃

        所謂厲行計劃，望文生義，即便對一個查詢任務，做出一份怎樣去告終任務的翔實計劃。舉個生存中的例子，我從珠海要去英國，我能夠抉擇先去香港然后起色，也能夠先去北京起色，可能去廣州也能夠。然而究竟怎樣去英國劃算，也即便我的開支起碼，這是一件劃算考究的事情。同樣對于查詢而言，我們提交的SQL僅僅是描寫出了我們的目標地是英國，但至于怎么去，等閑我們的SQL中是未曾給出提醒消息的，是由數據庫來定奪的。

        我們先容易的看一個厲行計劃的比擬：SQL> set autotrace traceonly

厲行計劃一：

SQL> select count(*) from t;

COUNT(*)

----------

24815

Execution Plan

0　SELECT STATEMENT Optimizer=CHOOSE

10　 SORT (AGGREGATE)

21 TABLE Access (FULL) OF 'T'

厲行計劃二：

SQL> select count(*) from t;

COUNT(*)

24815

Execution Plan

0　SELECT STATEMENT Optimizer=CHOOSE (Cost=26 Card=1)

10　 SORT (AGGREGATE)

21 INDEX (FULL SCAN) OF 'T_INDEX' (NON-UNIQUE)(Cost=26 Card=28180)

這兩個厲行計劃中，第一個表示求和是穿越舉行全表掃描來做的，把全副表中數據讀入內存來逐條累加;第二個表示依據表中索引，把全副索引讀進內存來逐條累加，而無須去讀表中的數據。然而這兩種措施究竟哪種快呢?等閑來說可能二比一快，但也不是絕對的。這是一個很容易的例子演示厲行計劃的差異。對于混雜的SQL(表連接、嵌套子查詢等)，厲行計劃可能幾十種甚至上百種，然而究竟那種良好呢?我們事前并不懂得，數據庫本身也不懂得，然而數據庫會依據定然的法定可能普查消息(statistics)去抉擇一個厲行計劃，等閑來說抉擇的是比擬優的，但也有抉擇失手的時候，這即便這次談論的價值所在。

Q：Oracle優化器形式

        Oracle優化器有兩大類，基于法定的和基于代價的，在SQLPLUS中我們能夠察看init文件中定義的缺省的優化器形式。

SQL> show parameters optimizer_mode NAME TYPEVALUE optimizer_mode string　 CHOOSE  SQL>

這是Oracle8.1.7 企業版，我們能夠看出，默認安裝后數據庫優化器形式為CHOOSE,我們還能夠設置為 RULE、FIRST_ROWS,ALL_ROWS。能夠在init文件中對全副instance的所有會話設置，也能夠獨自對某個會話設置：

SQL> ALTER SESSION SET optimizer_mode　= RULE;

會話已改動。

SQL>　ALTER SESSION SET optimizer_mode　= FIRST_ROWS;

會話已改動。

SQL>　ALTER SESSION SET optimizer_mode　= ALL_ROWS;

會話已改動。

基于法定的查詢，數據庫依據表和索引等定義消息，按照定然的法定來發生厲行計劃;基于代價的查詢，數據庫依據搜集的表和索引的數據的普查消息(穿越analyze 號召可能利用dbms_stats包來搜集)歸納來定奪撥取一個數據庫感受最優的厲行計劃(切實上無須定最優)。RULE是基于法定的，CHOOSE表示萬一查詢的表存在搜集的普查消息則基于代價來厲行(在CHOOSE形式下Oracle批準的是 FIRST_ROWS)，否則基于法定來厲行。在基于代價的兩種措施中，FIRST_ROWS指厲行計劃批準起碼資源盡快的歸來局部收獲給客戶端，對于排序分頁頁揭示這種查詢尤其實用，ALL_ROWS指以大局花費資源起碼的措施歸來收獲給客戶端。

        基于法定的形式下，數據庫的厲行計劃等閑比擬安寧。但在基于代價的形式下，我們才有更大的時機抉擇最優的厲行計劃。也由于Oracle的許多查詢方面的個性定然在基于代價的形式下能力揭示出來，因而我們等閑不抉擇RULE(并且Oracle號稱從 Oracle 10i版本數據庫開始將不再扶持 RULE)。既然是基于代價的形式，也即便說厲行計劃的抉擇是依據表、索引等定義和數據的普查消息來定奪的，這個普查消息是依據 analyze 號召可能dbms_stats包來定期搜集的。率先存在著一種可能，即便由于搜集消息是一個很花費資源和工夫的動作，尤其當表數據量很大的時候，因為搜集消息是對全副表數據舉行重新的全面普查，因而這是我們定然端莊琢磨的問題。我們只能在服務器安逸的時候定期的舉行消息搜集。這解釋我們在一段日期內，普查消息可能和數據庫本身的數據并不合乎;另外即便Oracle的普查數據本身也存在著不準確局部(翔實參看Oracle DOCUMENT)，更重要的一個問題即便及時普查數據相對曾經比擬準確，然而Oracle的優化器的抉擇也并不是始終是最優的計劃。這也攀附于Oracle對不同厲行計劃的代價的計算法定(我們等閑是無法懂得翔實的計算法定的)。這好像我們定奪從香港還是從北京去英國，車票、機票等切實價格究竟是怎么核算出來的我們并不懂得，可能說我們目前打聽的價格消息，在我們乘車前往的時候，懇摯價格跟我們的核算曾經發生了改變。所有的因素，都將波及我們的全副開支。

Q：厲行計劃安寧功能帶給我們什么

      Oracle存在著厲行計劃抉擇失手的可能。這也是我們經常碰見的一些假象，例如總有人說我的過程在測驗數據庫中跑的很好，但在產品數據庫上即便跑的很差，甚至后者硬件條件比前者還好，這究竟是為什么?硬件資源、普查消息、參數設置都可能對厲行計劃發生波及。由于因素太多，我們總是對未來懷著一種莫名的生怕，我的產品數據庫上線后究竟跑的好不好?于是Oracle供給了一種安寧厲行計劃的力氣，也即便把在測驗環境中的運行良好的厲行計劃所發生的OUTLINES移植到產品數據庫，使得厲行計劃不會隨著其他因素的改變而改變。

    那么OUTLINES是什么呢?先要推薦一個內容，Oracle供給了在SQL中利用HINTS來領導優化器發生我們想要的厲行計劃的力氣。這在多表連接、混雜查詢中尤其管用。HINTS的種類許多，能夠設置優化器目標(RULE、CHOOSE、FIRST_ROWS、ALL_ROWS)，能夠指定表連接的次序，能夠指定利用哪個表的哪個索引等等，能夠對SQL舉行許多精細的扼制。穿越這種措施發生我們想要的厲行計劃的這些HINTS,Oracle能夠存儲這些HINTS，我們稱之為OUTLINES。穿越STORE OUTLINES能夠使得我們具有爾后發生雷同厲行計劃的力氣，也即便使我們具有了安寧厲行計劃的力氣。

      這里想給出一個附帶的解釋即便，切實上，我們穿越工具修改SQL，例如利用SQL　EXPERT修改后的SQL，這些不但僅是加了HINTS而且文本都曾經發生了改變的SQL，也能夠存儲OUTLINES，并可被利用到利用中。但這不是定然見效，我們定然測驗察看是否見效。但由于就算給了訛謬的OUTLINES,數據庫在厲行的時候，揖　智疏忽過去重新生成厲行計劃而不會歸來訛謬，因而我們才敢塌心的這么利用。當然在Oracle文檔中并未曾指明能夠這么做，文檔中只是解釋，萬一存在OUTLINES的同時又在SQL中加了HINTS，則會利用OUTLINES而疏忽HINTS。這秉功能在LECCO將公布的產品中會利用這一功能，這么能夠將SQL EXPERT的修改SQL的力氣和安寧厲行計劃的力氣聯合起來，那么我們就對不能改動源代碼的利用具有了相當壯大的SQL優化力氣。

      可能我們會有疑問，假定安寧了厲行計劃，那還搜集普查消息干嗎?這是因為幾個起因構成的，率先，目前的厲行計劃對于未來發生了改變的數據未必即便輕便的，存在著目前的厲行計劃不中意未來數據的改變后的效率，而新的普查消息的情形下所發生的厲行計劃也并不是全副都科學的。那這個時候，我們能夠批準新搜集的普查消息，然而卻對新普查消息下不良的厲行計劃批準Oracle供給的厲行計劃安寧性這個力氣安寧厲行計劃，這么聯合起來我們能夠發生順心的高效的數據庫運行環境。

     我們還必需關懷的一個東西，Oracle供給的dbms_stats包除非具有搜集普查消息的力氣，還具有把數據庫中普查消息(statistics)export/import的力氣，還具有只搜集普查消息而使得普查消息不利用于數據庫的力氣(把普查消息搜集到一個特定的表中而不是即刻見效)，在這個基礎上我們就能夠把普查消息export出來再import到一個測驗環境中，再運行我們的利用，在測驗環境中我們考察最新的普查消息會導致哪些厲行計劃發生改變(DB EXPERT的Plan Version Tracer是模仿不同環境并積極察看不同環境中厲行計劃改變的工具)，是變好了還是變差了。我們能夠把變差的這一局部在測驗環境中利用hints可能利用工具(SQL EXPERT是在重寫SQL這一領土現在最強有力的工具)發生良好的厲行計劃的SQL，利用這些SQL能夠發生OUTLINES,然后在產品數據庫利用最新的普查消息的同時移植進這些OUTLINES。

 java報表工具：

http://www.finereport.com/javareport