Oracle9i 數(shù)據(jù)倉庫執(zhí)行性能增強

2024-08-29 13:41:24

字體：大中小

供稿：網(wǎng)友

　　Oracle9i 數(shù)據(jù)倉庫執(zhí)行性能增強
　　簡介
　　Oracle9i 顯著改進了基本數(shù)據(jù)倉庫(DWH) 功能的執(zhí)行性能。由于無需更改任何模式或應(yīng)用程序代碼來利用絕大多數(shù)性能上的改進成果，因此幾乎所有的客戶都可以僅通過升級Oracle 安裝而從中獲益。本白皮書通過在測試數(shù)據(jù)倉庫中執(zhí)行典型的數(shù)據(jù)倉庫任務(wù)和比較Oracle8i 和Oracle9i 的結(jié)果，說明了Oracle9i 對于執(zhí)行性能的增強。
　　所有任務(wù)都是在受到嚴密控制的單個系統(tǒng)中進行的，確保了對Oracle8i 和Oracle9i 進行公正的比較。從加載數(shù)據(jù)、在整個轉(zhuǎn)換過程中更改數(shù)據(jù)、創(chuàng)建實體化視圖并對其刷新到最后訪問數(shù)據(jù)，我們發(fā)現(xiàn)Oracle9i 顯著改善了執(zhí)行性能和系統(tǒng)利用率。
　　資源需求和相關(guān)性
　　本測試在相同硬件系統(tǒng)中，使用相同容量的內(nèi)存、I/O 子系統(tǒng)和相同數(shù)目的CPU 對Oracle8i 和Oracle9i 進行了比較。每個測試都受到監(jiān)視，以此證實結(jié)果的正確，且沒有受到在同一時刻運行的其他工作負載的不利影響。所有時間信息都用mi:ss 格式來表示。
　　硬件
　　系統(tǒng)配置：Sun Microsystems sun4u 8 槽Sun EnterPRise 4000/5000
　　　12 x 400 MHZ CPU
　　　10 GB 內(nèi)存
　　　128 x 磁盤，原始設(shè)備，64KB Stripe Unit Size，最大吞吐量90 MB/秒
　　數(shù)據(jù)庫
　　建立兩個帶有等價初始化參數(shù)(init.ora) 的基于TPC-H 模式的30 GB 數(shù)據(jù)庫，啟用新特性所需的參數(shù)除外。
　　　Oracle9i (9iopt)，整個系統(tǒng)全局范圍662995316 字節(jié)
　　　Oracle8i (8iopt)，整個系統(tǒng)全局范圍616460448 字節(jié)
　　基本執(zhí)行性能增強
　　本白皮書說明了通過Oracle9i 帶來的執(zhí)行性能增強并非專門與那些需要明確激活的新特性有關(guān)。許多執(zhí)行性能增強不需要對應(yīng)用程序代碼或數(shù)據(jù)庫方案進行任何改動。因此，許多運行于現(xiàn)有的Oracle8i DWH 環(huán)境的語句在移植到Oracle9i 后可自動重新使用。我們將貫穿數(shù)據(jù)倉庫進程，從加載、轉(zhuǎn)換和構(gòu)建階段開始，然后將數(shù)據(jù)匯集到實體化視圖中，刷新這些視圖，使用典型查詢語句來訪問數(shù)據(jù)。最后，我們將查看在Oracle8i 和Oracle9i 中完成整個進程所需的時間，展示每種增強功能為執(zhí)行性能帶來的改進。
　　合并/更新插入
　　合并/更新插入增強
　　在一個數(shù)據(jù)倉庫環(huán)境中，表（典型情況為事實表）需要使用來安閑線系統(tǒng)的新數(shù)據(jù)進行周期性刷新。這些新數(shù)據(jù)可能包括數(shù)據(jù)倉庫表中現(xiàn)有行的改變和/或需要插入的新行。假如新數(shù)據(jù)中的某一行對應(yīng)于表中已經(jīng)存在的某一項，則執(zhí)行一次UPDATE；
　　假如此行的主鍵沒有存在于表中，就執(zhí)行一次INSERT。在Oracle9i 之前，無論是插入還是更新數(shù)據(jù)，這些操作都是針對每一行以一個DML (INSERT/UPDATE) 序列或者一個PL/SQL 循環(huán)判決來表達。但是兩種方法都在執(zhí)行性能和可用性上存在不足。
　　Oracle9i 通過MERGE 語句這個新語法對SQL 進行了擴展，也就是說，將條件型INSERT 和UPDATE 序列包含在一條單一的基本語句中，從而克服了這些不足，使得數(shù)據(jù)倉庫應(yīng)用程序的實現(xiàn)更加簡單和直觀。
　　‘IF ROW EXISTS -THEN-UPDATE ELSE-INSERT’ 條件序列也稱為UPSERT。
　　合并/更新插入結(jié)果
　　在Oracle9i 中，對于更新插入進程使用新的基本MERGE 語句就能夠改善執(zhí)行性能，而不是通過相同語義使用一個條件INSERT 和UPDATE 語句序列，這主要取決于含有要被合并的新行的源數(shù)據(jù)大小；這是在與目的表的大小相比較的情況下，在該表中新行會被合并。與只改動目的表中的幾行相比，改動多行會從更新插入中受益更多。假如更新插入通過一個MERGE 的語句來執(zhí)行，源數(shù)據(jù)只需被掃描一次。然而，通過一個INSERT/UPDATE 序列，源數(shù)據(jù)表則需被掃描兩次。
　　假如需要額外程序的檢查或轉(zhuǎn)換等進一步的約束，而這些約束又無法以標準的SQL來表達，這時從執(zhí)行的角度來講通過PL/SQL 進行一次合并至少是最不可取的選擇。PL/SQL 方法明顯比MERGE 或UPSERT/INSERT 的方法慢許多，而后兩者都采用了面向集合的處理邏輯。
　　假如ETL （提取/轉(zhuǎn)換/加載）進程要求在插入之前進行一次程序的轉(zhuǎn)換，以流模式使用全新的可并行的PL/SQL 表函數(shù)，并且將結(jié)果傳送給后繼的合并操作，會顯著地改善執(zhí)行性能。
　　
　　在測試中，我們分析了一個三百萬新客戶的記錄更新插入到一個包含四百五十萬行的客戶表中。運行在Oracle9i 中的全新的MERGE 語句與運行在Oracle8i 中的條件式UPDATE 和INSERT 語句序列相比較。在兩個測試里，分別有一百五十萬個記錄被插入和更新。在這兩個方案中，都采用了Oracle 的并行DML 功能來執(zhí)行并行度為16的語句。執(zhí)行性能的改善是由于源表的最小化掃描，除此之外，對于通過并行DML插入的行，內(nèi)部優(yōu)化的索引維護操作也對執(zhí)行性能的改善起到了一定的作用。與Oracle8i 中同樣的INSERT 語句相比，在Oracle9i 中通過‘普通的’并行化INSERT，同樣的內(nèi)部優(yōu)化也能提高執(zhí)行性能。
　　執(zhí)行性能測試Oracle8i Oracle9i
　　差異百分比改進
　　更新插入更新/插入03:28 合并02:24 01:04 30.7%
　　　 Oracle9i 數(shù)據(jù)倉庫執(zhí)行性能增強（圖一）

　　圖1：更新插入測試結(jié)果
　　外部表
　　外部表增強
　　在Oracle9i 中，外部表新特性能以‘視覺表’的形式利用外部數(shù)據(jù)。通過該界面，外部表可被并行查詢并且直接連接到內(nèi)部的常規(guī)表，無需事先將外部數(shù)據(jù)加載到數(shù)據(jù)庫中。
　　使用外部表能使ETL 過程流水線化，從而轉(zhuǎn)換階段不會因加載階段而停滯不前。
轉(zhuǎn)換進程可與加載進程合并，卻不會中斷數(shù)據(jù)的連續(xù)性。不再需要為對比或轉(zhuǎn)換而在存儲區(qū)域存儲數(shù)據(jù)。
　　外部表與常規(guī)表之間的重大區(qū)別在于外部編排表是只讀的。任何DML 操作都不可行，而且無法對它們創(chuàng)建任何索引。在Oracle9i 中，外部表補充了現(xiàn)有SQL Loader 的功能。它們在特定的環(huán)境下很有用，一種情況是完整的外部資源必須連接到現(xiàn)有的數(shù)據(jù)庫對象上并以復(fù)雜的方式轉(zhuǎn)換；一種情況是外部數(shù)據(jù)量大且只使用過一次。
　　另一方面，在需要存儲表的額外索引時，SQL*Loader 對于加載數(shù)據(jù)來說仍不失為一個較好的選擇。對于數(shù)據(jù)在獨立綜合的轉(zhuǎn)換中使用的操作或數(shù)據(jù)在進一步處理中只部分采用的操作來說，情況就是如此。
　　外部表結(jié)果
　　對外部表所做測試是對更新插入測試的一個補充。
　　在Oracle8i 中，一個倉庫模式需要三個步驟加載新記錄：
　　1. 將外部文件的數(shù)據(jù)加載到數(shù)據(jù)庫的存儲表中（在本例中為CUSTOMER_MERGE）
　　2. 在升級表中創(chuàng)建獨特的索引（更新所需）
　　3. 通過UPDATE/INSERT 將數(shù)據(jù)合并到目的表中(CUSTOMER)
　　在Oracle9i 中，整個過程可縮短為兩步：
　　1. 在數(shù)據(jù)庫中創(chuàng)建元數(shù)據(jù)（CREATE TABLE …ORGANIZATION external）
　　2. 直接運用外部表（CUSTOMER_MERGE）作為Oracle9i MERGE 語句的來源。
　　上面所提的Oracle9i 的第一步很簡單，因為SQL Loader 在基于現(xiàn)有的Oracle8i Loader控制文件上生成了完整的CREATE TABLE 語法。Oracle9i 方法的運用使Oracle8i 中兩個必要的維護任務(wù)可以省略：數(shù)據(jù)加載和索引創(chuàng)建。與UPDATE 語句不同，MERGE語句對源表的索引不作非凡的要求。
　　在本例中，Oracle8i 加載和索引的步驟所需時間如下：
　　1. 加載（三百萬行，16 倍直接并行處理） 19 秒
　　2. 索引存儲表（16 倍并行處理） 14秒
　　因此使用Oracle9i 外部表將節(jié)省33 秒。該測試同時證實，使用將外部表而不是內(nèi)部表作為MERGE 的一種直接源僅僅會讓執(zhí)行性能略有下降：外部表需2:27 完成MERGE，而內(nèi)部表需2:24 完成。
　　　 Oracle9i 數(shù)據(jù)倉庫執(zhí)行性能增強（圖二）

　　圖2：外部表測試結(jié)果(*)：公平起見，結(jié)果取自于Oracle9i-MERGE
　　Group By
　　可變長度聚合
　　在DWH 的應(yīng)用中，Group By 是個很要害的基本操作。Group By 在Oracle9i 中已經(jīng)提升到運用可變長度聚合的高度。
　　在Group By、Cube 和Rollup 處理過程中，Oracle8i 的執(zhí)行引擎把Oracle 數(shù)字作為聚合的累加器。分類引擎中填寫了許多記錄，這些記錄由一連串的Group By 鍵和一系列聚合工作區(qū)域組成。當(dāng)Group By 操作通過同樣的分組鍵使用行時，聚合就會發(fā)生。Oracle8i 的聚合中SUM 占用了23 個字節(jié)、AVG 占用了31 個字節(jié)、VARIANCE 占用了54 個字節(jié)來累加所聚合的數(shù)值。分類記錄的數(shù)量可以不斷地增長，能反過來促使內(nèi)存分類區(qū)域的快速消耗。
　　對于大多數(shù)應(yīng)用程序來講，為聚合而使用全長的Oracle 數(shù)字很顯然是浪費空間。假如知道一個特定的Oracle 數(shù)字只需7 個字節(jié)而不是22 個字節(jié)的話，我們就能壓縮聚合工作區(qū)域從而多得到3 倍空間。這可以直接轉(zhuǎn)化為執(zhí)行性能的改善。如此更加充分地利用空間，分類引擎幾乎不會占用磁盤的空間；即使確實發(fā)生這樣的情形，分類引擎讀寫的數(shù)據(jù)也只會是該示例中讀寫數(shù)據(jù)的四分之一。
　　聚合測試結(jié)果
　　隨著Group By 查詢中處理的組數(shù)不斷增加，Oracle9i 對于Oracle8i 的優(yōu)勢也不斷加強。針對組數(shù)很少的一組查詢，兩次釋放的區(qū)別并不太明顯。為了測試，我們選定了8 個聚合操作符（GroupBy.sql）并且通過設(shè)定SORT_AREA_SIZE 規(guī)定了所用內(nèi)存為20MB 和30MB。具有20MB 內(nèi)存的條件下，Oracle8i 和Oracle9i 都占用了磁盤空間。此時，Oracle9i 所占用的磁盤空間幾乎只是Oracle8i 所占用的一半而且速度還快10％。具有30MB 的內(nèi)存條件下，Oracle9i 正好達到內(nèi)存要求而Oracle8i 仍需占用磁盤空間。在該測試中，Oracle9i 的速度要快20％。兩個測試中所用的并行度均為24，這表明在第一個測試中，24 個進程的每一個進程都使用了20MB 的內(nèi)存；在第二個測試中使用的內(nèi)存則為30MB。
　　
　　　 Oracle9i 數(shù)據(jù)倉庫執(zhí)行性能增強（圖三）

　　圖3：Group By 測試結(jié)果DOP 為并行度，
　　Sort = SORT_AREA_SIZE
　　動態(tài)內(nèi)存治理
　　專用服務(wù)器的PGA 內(nèi)存
　　在Oracle9i 之前，諸如SORT_AREA_SIZE、HASH_AREA_SIZE、BITMAP_MERGE_AREA_SIZE 和CREATE_B

上一篇：巧妙轉(zhuǎn)換ORACLE數(shù)據(jù)庫字符集

下一篇：Oracle9i實體化視圖