- 論壇徽章:
- 0
|
問一個(gè)簡單的問題，請(qǐng)各位不吝賜教
[quote]原帖由 "lusimon"]對(duì)于操作系統(tǒng)來說，SQL和QUERY處理的Optimizer是不同的。SQL是有SQE處理，Query是由CQE。IBM將慢慢使用SQE取代CQE，所以SQL是以后的發(fā)展方向。[/quote 發(fā)表：
你說SQE、CQE可能沒幾個(gè)人能看懂，既然已經(jīng)提及，我就順帶詳細(xì)解釋一下: 
最新設(shè)計(jì)的iSeries DB2 UDB查詢引擎已經(jīng)今非昔比了，無論是現(xiàn)在的SQL查詢引擎（SQE）還是傳統(tǒng)查詢引擎（CQE）都可以處理你的查詢請(qǐng)求，但是SQL查詢引擎（SQE）簡化并加速了查詢。處理包含傳統(tǒng)查詢引擎（CQE）的基本功能外，SQL查詢引擎（SQE）還提供以下功能：
l 將查詢優(yōu)化器移到機(jī)器界面（MI）層以下，以加速查詢的處理
l 在統(tǒng)計(jì)管理器的面板中將改良過的統(tǒng)計(jì)分開處理
l 使用了面向?qū)ο蟮脑O(shè)計(jì)來加速傳遞新的數(shù)據(jù)庫功能
l 使用更靈活，更獨(dú)立的數(shù)據(jù)訪問方式來提供自主的查詢循環(huán)控制
l 使用增強(qiáng)的算法來提供更好的響應(yīng)能力和查詢處理能力
l 增強(qiáng)了對(duì)處理需要長時(shí)間運(yùn)行的復(fù)雜查詢提供了的性能
l 保留對(duì)查詢操作的路徑，以提高其易用性
優(yōu)化器移至MI層以下：
在操作系統(tǒng) OS/400 V5R2上, 為了提供對(duì)元數(shù)據(jù)更快的訪問速度，SQE優(yōu)化器是在MI層以下創(chuàng)建的，這樣做同時(shí)也是為了更精確地統(tǒng)計(jì)和更好地了解整個(gè)操作系統(tǒng)（包括內(nèi)存，CPU，硬盤驅(qū)動(dòng)器的能力等）。
大多數(shù)的CQE的處理機(jī)制是位于MI層以上的，但是處理SQE的主要機(jī)制都是位于MI層以下的，這使得SQE在處理查詢的時(shí)候更加有效率。因?yàn)樵贑QE中處理查詢的時(shí)候，在優(yōu)化器和查詢的執(zhí)行部件之間的交互要反復(fù)穿越MI層，這樣做的結(jié)果就使得接口相關(guān)的性能下降了。但對(duì)于SQE，這種行為就不存在。
只有集成在操作系統(tǒng)內(nèi)的數(shù)據(jù)庫才能夠自由地獲取系統(tǒng)極其數(shù)據(jù)的內(nèi)部詳細(xì)信息，使用SQE，就可以有效地獲取詳細(xì)系統(tǒng)信息。除了集成在操作系統(tǒng)中以外，iSeries DB2 UDB 將繼續(xù)增強(qiáng)其在業(yè)界獨(dú)特的位置。
統(tǒng)計(jì)管理器面板：
使用了SQE后，統(tǒng)計(jì)數(shù)據(jù)的收集和分析從優(yōu)化器中移走了，并且現(xiàn)在分別由兩個(gè)不同的部件：統(tǒng)計(jì)管理器和元數(shù)據(jù)管理器來處理。統(tǒng)計(jì)管理器生成并維護(hù)列的統(tǒng)計(jì)數(shù)據(jù)，元數(shù)據(jù)管理器回答由優(yōu)化器在查詢最優(yōu)路徑時(shí)提出的問題。這使得優(yōu)化器從回答數(shù)據(jù)統(tǒng)計(jì)問題的處理中解放出來。
元數(shù)據(jù)管理器為優(yōu)化器提供三種統(tǒng)計(jì)數(shù)據(jù)：記錄計(jì)數(shù)，記錄選擇（選擇的記錄數(shù)）和基數(shù)性（特殊計(jì)數(shù)）。當(dāng)優(yōu)化器詢問元數(shù)據(jù)管理器一個(gè)問題（例如：在表tableCar中有多少紅色汽車）時(shí)，元數(shù)據(jù)管理器就會(huì)從表的索引或者對(duì)顏色字段的統(tǒng)計(jì)結(jié)果中找出答案：
SELECT *
FROM tableCar
WHERE color = 'Red'
如果元數(shù)據(jù)管理器沒有從表索引或統(tǒng)計(jì)結(jié)果中得到答案，它會(huì)產(chǎn)生一個(gè)默認(rèn)的回答。同時(shí)，它會(huì)從后臺(tái)向統(tǒng)計(jì)管理器拋出這個(gè)問題，如果下次有相同的問題問出，那么會(huì)產(chǎn)生一個(gè)更精確的答案。這種優(yōu)化器和統(tǒng)計(jì)管理器之間的交互提供了優(yōu)化器對(duì)適當(dāng)?shù)慕y(tǒng)計(jì)的自動(dòng)處理的需要。
對(duì)于每一個(gè)答案，元數(shù)據(jù)管理器同時(shí)還會(huì)返回一個(gè)信心級(jí)別，當(dāng)比默認(rèn)回答好的答案返回的時(shí)候，信心級(jí)別就會(huì)提高。這使元數(shù)據(jù)管理器能夠致力于對(duì)統(tǒng)計(jì)問題找到最佳答案，而優(yōu)化器致力于使用這些答案，與信心級(jí)別結(jié)合，給應(yīng)用提供最佳的計(jì)劃。您要想瀏覽表的統(tǒng)計(jì)結(jié)果，打開iSeries操作導(dǎo)航器，選擇“庫”，然后用鼠標(biāo)右鍵點(diǎn)中要瀏覽的表，選擇“統(tǒng)計(jì)數(shù)據(jù)”。
面向?qū)ο蟮脑O(shè)計(jì)：
SQE查詢優(yōu)化器是運(yùn)用了面向?qū)ο蟮睦砟钤O(shè)計(jì)并實(shí)施的，它使用查詢的樹型結(jié)構(gòu)，樹型結(jié)構(gòu)的每一個(gè)節(jié)點(diǎn)是獨(dú)立的，并且可以重復(fù)使用的部件。這些節(jié)點(diǎn)可以以任何順序及組合與另外的節(jié)點(diǎn)交互或者接口。
這種設(shè)計(jì)使得在產(chǎn)生新的查詢方法的時(shí)候有更大的靈活性。它允許SQE獨(dú)立地執(zhí)行和優(yōu)化這些節(jié)點(diǎn)，因此更加靈活有效。
圖1向您展示了一個(gè)SQE中索引探測(cè)器節(jié)點(diǎn)的實(shí)施。NODE1代表一個(gè)典型的節(jié)點(diǎn)探測(cè)器訪問方法， NODE1與 NODE2是相互獨(dú)立的。
每一個(gè)節(jié)點(diǎn)都可以被獨(dú)立地執(zhí)行和優(yōu)化。在圖1的例子里，NODE2只有一個(gè)功能：將索引找出來并存在內(nèi)存中。因此，這似的樹型結(jié)構(gòu)中的其它節(jié)點(diǎn)可以調(diào)用NODE2來執(zhí)行應(yīng)用要求的查找索引的功能。所以，SQE實(shí)現(xiàn)了數(shù)據(jù)庫新功能和附加功能的開發(fā)簡易性和可用性，并且加速其新功能的傳遞。
數(shù)據(jù)訪問功能：
SQE比CQE提供了更多數(shù)據(jù)訪問方法的功能和機(jī)會(huì)，總體來說，查詢引擎需要具備兩方面的素材來滿足查詢：包含數(shù)據(jù)的數(shù)據(jù)庫對(duì)象和將提取的信息組成有用信息的指令。您可以使用兩種永久的數(shù)據(jù)庫對(duì)象―表（物理文件）和索引。當(dāng)這些條件對(duì)于SQE和CQE都符合時(shí)，SQE有更好的技術(shù)將對(duì)于更好的使用這些對(duì)象，特別是對(duì)于索引。
當(dāng)考慮使用索引時(shí)，CQE試圖檢查大多數(shù)，如果不是所有，將會(huì)在表上創(chuàng)建索引，直到CQE超時(shí)。相反的，SQE只考慮元數(shù)據(jù)管理器返回的和表的列吻合的索引。這大大減少了優(yōu)化器需要考慮的索引數(shù)量，并且摒棄了由于索引在創(chuàng)建時(shí)的不同順序引起的歧義。
更重要的是，優(yōu)化器可以更頻繁地使用索引以找出更快的數(shù)據(jù)訪問路徑。由于對(duì)單個(gè)節(jié)點(diǎn)的關(guān)注，索引可以在查詢的樹型結(jié)構(gòu)中更靈活地被使用。下面是一個(gè)實(shí)現(xiàn)對(duì)一個(gè)字段不符合ORDER BY的排序：
CREATE INDEX IX1 ON T1(C1 ASC)
SELECT T1.C1
FROM T1
ORDER BY T1.C1 DESC
索引的鍵值是升序的，而查詢要求降序，當(dāng)您使用CQE的時(shí)候，這個(gè)索引是沒法使用的，但是，這對(duì)于SQE卻不是問題，它只需要在索引的樹型結(jié)構(gòu)中加入一個(gè)反向的節(jié)點(diǎn)就可以處理這樣的排序要求了。
這種索引的一個(gè)缺點(diǎn)是，在索引和表中對(duì)數(shù)據(jù)的訪問通常是隨機(jī)的，所以會(huì)增加系統(tǒng)I/O和調(diào)頁的頻率。SQE的優(yōu)化器智能地將事先裝載的邏輯放置到查詢的樹型結(jié)構(gòu)中，以減少在隨機(jī)數(shù)據(jù)上的I/O等待時(shí)間，并使得其更有效地利用系統(tǒng)資源并更快地返回查詢結(jié)果。
除了表和索引，查詢引擎會(huì)希望使用臨時(shí)對(duì)象來保存中間結(jié)果，臨時(shí)對(duì)象對(duì)于通過改善系統(tǒng)I/O來提高性能并滿足客戶的需求（例如：ORDER BY的排序結(jié)果）。當(dāng)需要時(shí)，CQE首先會(huì)使用臨時(shí)結(jié)果，這或多或少能提高性能；而對(duì)于SQE，它會(huì)更積極地使用臨時(shí)結(jié)果，無論是不是會(huì)提高查詢性能。
哈希表就是一個(gè)臨時(shí)對(duì)象的例子，當(dāng)將兩個(gè)表聯(lián)合的時(shí)候，經(jīng)常會(huì)用到，特別是索引不可用的時(shí)候。CQE在有限的情況下使用到哈希表來實(shí)現(xiàn)表的聯(lián)合，一旦用了哈希聯(lián)合，表中剩余部分的聯(lián)合也必須使用哈希表。對(duì)于SQE，任何表的聯(lián)合，都會(huì)用到哈希表，并將哈希表和索引及全表檢索混合使用。
因?yàn)镾QE優(yōu)化器更傾向于使用哈希表和排序列表，實(shí)際數(shù)據(jù)的訪問就稍顯不同。盡管也滿足了查詢的定義，但是可能就不象以前操作系統(tǒng)版本上對(duì)實(shí)際數(shù)據(jù)的查詢操作。如果你要求查詢實(shí)際數(shù)據(jù)，你必須告訴查詢優(yōu)化器關(guān)于這一點(diǎn)。必須對(duì)以前版本中對(duì)實(shí)際數(shù)據(jù)錯(cuò)誤的編碼進(jìn)行評(píng)估，如果是需要的，那么必須指定ALWCPYDTA *NO或者游標(biāo)SENSITIVE來消除這些數(shù)據(jù)的中間拷貝。
SQE對(duì)每一個(gè)節(jié)點(diǎn)的優(yōu)化是獨(dú)立的，但是在整個(gè)查詢中使用全局化的知識(shí)，所以SQE的結(jié)果在整個(gè)查詢的樹型結(jié)構(gòu)中是通用的。
響應(yīng)和處理能力：
SQE優(yōu)化器用多中方式重新改寫查詢語句。在決定聯(lián)合的順序，分組，數(shù)據(jù)的排序，顯式查詢和索引查詢的時(shí)候，常規(guī)的和靈活的優(yōu)化策略是獨(dú)立作用的。這些策略允許優(yōu)化器生成更多的選擇來訪問數(shù)據(jù)，這也增加了對(duì)查詢最佳方案的可選性。
SQE優(yōu)化器首先使用各種可能的轉(zhuǎn)化技術(shù)，將樹型結(jié)構(gòu)的查詢語句翻譯成相當(dāng)?shù)母鬃x/易優(yōu)化的查詢樹結(jié)構(gòu)。例如，一些查詢的樹結(jié)構(gòu)暗示了沒有顯式表現(xiàn)的條件：
SELECT...
FROM T1, T2
WHERE T1.ID = T2.ID and T1.ID >; 100
這個(gè)查詢中暗示了T2.ID >;100也需要滿足。明確的增加顯式的謂詞使得優(yōu)化器能夠考慮到后續(xù)添加的條件，并減少需要處理的記錄數(shù)量。
另一個(gè)翻譯的例子發(fā)生在跟在WHERE子句后面的ORDER BY子句中：
SELECT...
FROM T1
WHERE T1.C1 = 5
ORDER BY T1.C1.
ORDER BY子句可以去掉，因?yàn)?是從字段C1中返回的唯一的值，當(dāng)查詢的樹型結(jié)構(gòu)從邏輯的翻譯的結(jié)果填充，最優(yōu)化的查詢結(jié)構(gòu)就取代了原來的結(jié)構(gòu)。通過使用優(yōu)化策略，優(yōu)化器深入查詢的樹型結(jié)構(gòu)并開始在多個(gè)可能的查詢結(jié)構(gòu)之間執(zhí)行一系列的時(shí)間花費(fèi)比較，找出最優(yōu)化的結(jié)構(gòu)。
優(yōu)化策略是如何知道要考慮哪個(gè)數(shù)據(jù)訪問路徑？每一個(gè)策略都只有一個(gè)特定的目標(biāo)，一個(gè)排序的策略是按照查詢的ORDER BY子句來確定節(jié)點(diǎn)中數(shù)據(jù)的順序。如果數(shù)據(jù)訪問路徑滿足了節(jié)點(diǎn)中數(shù)據(jù)排序的要求，排序策略就選擇它并算出實(shí)際取出數(shù)據(jù)所要花費(fèi)的時(shí)間。
每一個(gè)數(shù)據(jù)訪問路徑都要經(jīng)過選擇，時(shí)間花費(fèi)的計(jì)算，然后與節(jié)點(diǎn)中其他的數(shù)據(jù)訪問路徑相比較，花費(fèi)最少的路徑將被選中，并依附在查詢樹型結(jié)構(gòu)的那個(gè)節(jié)點(diǎn)上。
為了確保精確性，單個(gè)的數(shù)據(jù)訪問花費(fèi)的時(shí)間時(shí)間源自于特定的iSeries機(jī)器上SQE引擎實(shí)際的數(shù)據(jù)提取時(shí)間，一旦硬件更換了，訪問花費(fèi)時(shí)間也將更新，這樣能使得實(shí)際該機(jī)器上剩下的數(shù)據(jù)訪問時(shí)間是精確的。
SQE優(yōu)化器比CQE優(yōu)化器對(duì)FirstIO和AllIO環(huán)境設(shè)置的響應(yīng)更快，這些設(shè)置提供了優(yōu)化器關(guān)于用戶實(shí)際從查詢中提取出多少記錄，或者少數(shù)的記錄（FirstIO），或者所有的記錄（AllIO）。它不會(huì)指出查詢到底總共有多少記錄數(shù)被返回，這部分是由優(yōu)化器從統(tǒng)計(jì)結(jié)果中獲得。這些設(shè)置是非常重要的，因?yàn)樗鼌^(qū)分了查詢是否需要被優(yōu)化成利用FirstIO實(shí)現(xiàn)最快的訪問路徑，或者利用AllIO實(shí)現(xiàn)最有效的訪問路徑。如果這些設(shè)置與實(shí)際使用的不一樣，那么性能就不是最理想的。
盡管環(huán)境的默認(rèn)設(shè)置是通過每一種SQL接口提供的，這種環(huán)境設(shè)定是通過OPTIMIZE FOR N ROWS子句顯式設(shè)定的。請(qǐng)注意，不同的SQL接口環(huán)境的默認(rèn)設(shè)置都是不一樣的。
ODBC和JDBC（客戶端）接口默認(rèn)設(shè)置成FirstIO是不支持打包的，而AllIO則支持打包。CLI，JDBC內(nèi)部和靜態(tài)接口的默認(rèn)設(shè)置是AllIO。如果查詢要選取大量的記錄，而應(yīng)用只希望看到少部分的記錄，那么指定OPTIMIZE FOR N ROWS子句，或者指定使用FirstIO是非常重要的。
增強(qiáng)效率：
如果您的系統(tǒng)上安裝了DB2對(duì)稱多處理（SMP）這個(gè)軟件，那么SQE就可以通過并發(fā)處理來提高查詢的性能。對(duì)于整個(gè)查詢樹型結(jié)構(gòu)或者其子樹，都可以考慮使用并發(fā)處理。如果機(jī)器上存在多個(gè)處理器（CPU），那么SQE支持在查詢中使用多線程處理每一個(gè)節(jié)點(diǎn)或者節(jié)點(diǎn)組。SQE使用線程（CQE使用任務(wù)）來分割工作，因此，SMP更容易遵循作業(yè)和子系統(tǒng)的優(yōu)先級(jí)。這樣，用戶可能會(huì)更樂意接受SMP來實(shí)現(xiàn)并發(fā)處理并提高性能。
看一下下面這個(gè)聯(lián)合的例子：
SELECT COUNT(*)
FROM Cust, Trans
WHERE Cust.ID = Trans.CID and Trans.DateFld >;
'06/01/03'
假定優(yōu)化器決定在表Trans上創(chuàng)建一個(gè)哈希表，然后與表Cust聯(lián)合，那么，如果安裝了SMP，哈希表的創(chuàng)建（使用條件Trans.DateFld >; ‘06/01/03’來減小哈希表的大小）就會(huì)被分割成多個(gè)線程并發(fā)地運(yùn)行。當(dāng)將表Cust聯(lián)合到哈希表中的時(shí)候，也會(huì)并發(fā)地運(yùn)行。在CQE中已經(jīng)可以實(shí)現(xiàn)并發(fā)創(chuàng)建哈希表，但是并發(fā)處理聯(lián)合對(duì)于SQE也是新的功能（參見圖2）。
對(duì)Cache的計(jì)劃：
一個(gè)已經(jīng)優(yōu)化過的查詢可能再次被使用，所以那個(gè)查詢的訪問路徑將被保存在CACHE中，CACHE中還保存了查詢的信息，環(huán)境信息，以及優(yōu)化過的那個(gè)查詢最終使用的訪問路徑。
在優(yōu)化一個(gè)查詢之前，優(yōu)化器會(huì)先在CACHE里查找，如果能找到一個(gè)相當(dāng)?shù)牟樵�，并且其環(huán)境與當(dāng)前運(yùn)行環(huán)境兼容，那么優(yōu)化器就會(huì)使用這個(gè)已經(jīng)優(yōu)化好的查詢路徑，避免了重復(fù)的行為。
保存并重復(fù)使用訪問路徑的概念對(duì)于SQE來說并不是新的，CQE也具有同樣的功能。但是，與CQE不同的是，SQE的CACHE是數(shù)據(jù)庫范圍內(nèi)的，它保存從任何SQL接口―靜態(tài)的，動(dòng)態(tài)的，JDBC，ODBC等等過來的查詢，并且從不同借口過來的查詢路徑都保存在相同的CACHE中。而在從前，從不同接口過來的查詢路徑保存在各自不同的CACHE中，因此即使是相同的查詢路徑也不能跨接口被重復(fù)使用。
此外，與CQE不同的是，SQE可以保存一個(gè)查詢的多個(gè)不同查詢路徑。這對(duì)于在查詢路徑依賴于用戶輸入，可用內(nèi)存等因素的環(huán)境下，是非常靈活機(jī)動(dòng)的。
對(duì)于SQE來說，真正具備潛在優(yōu)勢(shì)的地方在于，在將來的OS/400版本中會(huì)具備體現(xiàn)優(yōu)化器自學(xué)習(xí)，自適應(yīng)的能力。這樣的查詢優(yōu)化器可以比較在CACHE中存儲(chǔ)的訪問路徑與SQL要求的實(shí)際運(yùn)行時(shí)間相比較，并自動(dòng)地調(diào)整訪問策略以提高查詢的效率。
結(jié)論：
SQE的設(shè)計(jì)理念將以下的目標(biāo)融入其中：
l 提供在更復(fù)雜查詢環(huán)境中增強(qiáng)處理能力的功能
l 持續(xù)地并可預(yù)計(jì)地增強(qiáng)查詢處理的性能
l 技術(shù)發(fā)展水平一體化
l 無縫地替代CQE
換句話說，使用SQE繼續(xù)使用更少的工作，更好的方法將您的查詢處理向前推動(dòng)！ |
-
圖1.gif
(16.59 KB, 下載次數(shù): 51)
下載附件
2005-01-08 14:06 上傳
圖1
-
圖2.gif
(18.63 KB, 下載次數(shù): 54)
下載附件
2005-01-08 14:05 上傳
圖2
|
免費(fèi)注冊(cè)
發(fā)表于 2005-01-07 19:27
發(fā)表于 2005-01-07 19:39
