當前，各個(gè)行業(yè)越來(lái)越關(guān)注數據倉庫了，因為公司希望從數據資產(chǎn)中找出有意義的業(yè)務(wù)智能化信息，從而驅動(dòng)更好的決策。本文我們將介紹熟悉 DB2 在線(xiàn)事務(wù)處理 (OLTP) 的老手是否能夠同樣有效地支持數據倉庫，尤其是在性能管理方面。 在去年 10 月在華沙召開(kāi)的 International DB2 Users Group 大會(huì )上，IBM 的 Willie Favero 做了關(guān)于數據倉庫的演講，其中引用了 1983 年引入 DB2 數據庫管理系統時(shí)的公告。這份公告把 DB2 定位為決策支持應用程序的優(yōu)良基礎（當時(shí) “數據倉庫” 這個(gè)詞還沒(méi)有出現）。 我還記得 DB2 的誕生，因為我當時(shí)正在為 IBM 工作。 DB2 確實(shí)是業(yè)務(wù)智能化 (BI) 系統的絕佳選擇，但是對于負責構建和維護操作性應用程序的 IT 人員來(lái)說(shuō)，它的編程生產(chǎn)力優(yōu)勢同樣很有吸引力，比如與英語(yǔ)相似的數據操縱語(yǔ)言和由 DBMS 選擇數據訪(fǎng)問(wèn)路徑。應客戶(hù)的要求，IBM 在各個(gè) DB2 版本中不斷改進(jìn)性能，極大地提高了應用程序吞吐量。 Linux, Unix, and Windows (LUW) 服務(wù)器和大型機上的 DB2 作為處理事務(wù)性工作負載的數據服務(wù)器越來(lái)越流行了，其中許多系統的吞吐量超過(guò)每秒 1,000 個(gè)事務(wù)。 當前，各個(gè)行業(yè)越來(lái)越關(guān)注數據倉庫了，因為公司希望從數據資產(chǎn)中找出有意義的業(yè)務(wù)智能化信息，從而驅動(dòng)更好的決策。長(cháng)期使用 DB2 支持操作性應用程序的企業(yè)和政府機構現在正在構建基于 DB2 的 BI 系統。這一趨勢讓一些 DB2 在線(xiàn)事務(wù)處理 (OLTP) 老手想到了一個(gè)問(wèn)題：他們是否能夠同樣有效地支持數據倉庫，尤其是在性能管理方面。本文就是為這些專(zhuān)業(yè)人員準備的。由于這個(gè)主題很廣泛，我將分兩期討論。 DB2 數據倉庫環(huán)境中的性能管理與基于 DB2 的 OLTP 應用程序中的監視和調優(yōu)很不一樣。重要的差異包括： 單獨的 SQL 語(yǔ)句與事務(wù)。在 OLTP 環(huán)境中，典型的事務(wù)包含多個(gè) SQL 語(yǔ)句，常?？梢栽谝幻雰韧瓿?。對于 BI 應用程序，“事務(wù)”（用戶(hù)與系統的一次交互）可能只執行一個(gè) SQL 語(yǔ)句，但是這個(gè)語(yǔ)句可能要運行幾分鐘，甚至一小時(shí)以上，而且這不被認為是 “慢”。如果一個(gè)報告原本要運行 10 小時(shí)，而現在可以在一小時(shí)內完成，用戶(hù)會(huì )非常高興。 事實(shí)和維。用于 OLTP 工作的 DB2 數據庫很可能采用傳統 3NF 設計（或相近的設計）。而數據倉庫數據庫設計常常采用維，按照 “星型模式” 組織相關(guān)的表（位于中心的 “事實(shí)” 表和相關(guān)聯(lián)的維表）。 連續與夜間數據庫更新。對于 OLTP 應用程序，往往隨時(shí)進(jìn)行數據庫更新。對于 BI 應用程序，盡管對接近實(shí)時(shí)地更新數據庫值的興趣正在增長(cháng)，但是數據倉庫數據庫通常在夜間進(jìn)行更新，常常要執行大量提取、轉換和裝載 (ETL) 操作。在 ETL 處理期間通常不能進(jìn)行查詢(xún)訪(fǎng)問(wèn)，這要求必須及時(shí)地完成數據庫更新過(guò)程。 小結果集與大結果集。OLTP 事務(wù)程序中的 SELECT 語(yǔ)句通常只獲取少量數據庫行（常常只有一兩行）。數據倉庫查詢(xún)（尤其是那些用來(lái)生成報告或在線(xiàn)分析處理多維數據集的查詢(xún)）可能返回成千上萬(wàn)（甚至上百萬(wàn)）行。 復雜查詢(xún)與簡(jiǎn)單查詢(xún)。OLTP 事務(wù)程序中的 SELECT 語(yǔ)句常常非常簡(jiǎn)單：只訪(fǎng)問(wèn)一兩個(gè)表，很少或不需要構建動(dòng)態(tài)表，很少或不需要動(dòng)態(tài)地轉換數據值或類(lèi)型。與 BI 應用程序相關(guān)的查詢(xún)可能長(cháng)達幾頁(yè)，包含十幾個(gè)甚至更多表的聯(lián)結，包含嵌套的或通用的表表達式、遞歸的 SQL、數據值不同的 CASE 表達式和數據類(lèi)型轉換（通過(guò) CAST 聲明或標量函數）。 不得不使用的 SQL 與自己編寫(xiě)（至少是自己檢查過(guò)）的 SQL 。在數據倉庫環(huán)境中，常常由報告或 OLAP 工具生成 SQL，您在執行它之前沒(méi)有機會(huì )修改它。您要負責設置適當的 DB2 環(huán)境，讓這些查詢(xún)能夠良好地運行。 總的來(lái)說(shuō)，DB2 專(zhuān)業(yè)人員要通過(guò)兩方面的工作幫助實(shí)現良好的數據倉庫性能：
本文主要關(guān)注 DB2 環(huán)境的設置。在下一期中，將討論數據倉庫 SQL 語(yǔ)句的調優(yōu)。
建立有助于提高查詢(xún)性能的 DB2 數據倉庫環(huán)境涉及系統級和應用程序級措施。對于 DB2 系統，應該注意以下方面： 使用 64 位尋址。更大的 DB2 緩沖區池總是有助于提高性能，但是它們對于 I/O 密集型的數據倉庫工作負載尤其有用。許多有經(jīng)驗的 DB2 專(zhuān)業(yè)人員已經(jīng)習慣了 2GB（大型機）或 4GB（Linux/Unix/Windows）的內存空間限制，他們要花點(diǎn)兒時(shí)間適應 64 位程序。 當前的服務(wù)器擁有極大的內存：在 IBM System z 大型機、System p 服務(wù)器（AIX 或 Linux）或 System x 服務(wù)器（Windows 或 Linux）上，可以有 1TB 甚至更多的系統內存。這些平臺上的 DB2 支持至少 1TB 的緩沖區池配置。 如果服務(wù)器有大量?jì)却尜Y源，就應該好好利用 DB2 緩沖區池。我曾經(jīng)見(jiàn)過(guò)在有 40GB 系統內存的服務(wù)器上運行的 DB2 只配置了 800MB 的緩沖區池。這太小了：在這種情況下（至少）10-20GB 要適合得多。 請記住，隨著(zhù)緩沖區池大小的增加，磁盤(pán)讀 I/O 活動(dòng)的數量會(huì )減少。還可以讓 DB2 自己選擇緩沖區池大小。自動(dòng)內存管理是 DB2 9 for LUW 中非常受歡迎的特性，現在 DB2 9 for z/OS（與 z/OS Workload Manager 協(xié)作）可以通過(guò) ALTER BUFFERPOOL 命令的 AUTOSIZE(YES) 選項管理緩沖區池大小。 利用查詢(xún)并行性。DB2 可以把處理查詢(xún)所需的工作分割為片段，并行地執行這些片段，這會(huì )顯著(zhù)減少運行時(shí)間。使用這個(gè)特性需要通過(guò)參數啟用它。對于 DB2 for LUW，通過(guò)把數據庫管理程序參數 intraparallel 的值設置為 YES，就可以啟用單一服務(wù)器中的并行性。在大型機和 LUW 平臺上，給定的動(dòng)態(tài) SELECT 語(yǔ)句（動(dòng)態(tài) SQL 是數據倉庫環(huán)境中常用的特性）的并行性取決于特殊注冊表 CURRENT DEGREE 的設置。如果 CURRENT DEGREE 的值（這個(gè)值應用于給定的客戶(hù)機 -DB2 連接，而不是系統范圍的值）是 1，那么查詢(xún)就不會(huì )并行執行；如果值是 ANY，查詢(xún)就可以并行執行（如果優(yōu)化器認為這會(huì )提高性能的話(huà)）。由 DB2 決定并行度。 在許多站點(diǎn)上，首選方法是把 CURRENT DEGREE 的默認值設置為 1（非并行），對于特定的查詢(xún)，使用 SQL 語(yǔ)句 SET CURRENT DEGREE 把它改為 ANY 。如果無(wú)法使用 SET CURRENT DEGREE（一些查詢(xún)生成工具可能不支持使用這個(gè)語(yǔ)句），可以通過(guò) DB2 for z/OS 的 CDSSRDEF ZPARM 參數或 DB2 for LUW 的 dft_degree 數據庫參數把這個(gè)特殊注冊表的默認值設置為 ANY 。 除了能夠在單一服務(wù)器中分割查詢(xún)之外，DB2 還可以通過(guò) DB2 for z/OS 的 sysplex 查詢(xún)并行性和 DB2 for LUW 的 Data Partitioning Feature 跨集群配置中的多個(gè)服務(wù)器分割查詢(xún)。請記住，DB2 for z/OS 查詢(xún)并行性是提高 zIIP 引擎利用率的好方法，zIIP 引擎是專(zhuān)用的大型機處理器，有助于為組織節省計算成本。
可以通過(guò)下面這些與數據庫相關(guān)的措施讓 DB2 數據倉庫環(huán)境更適應查詢(xún)： 對大型表進(jìn)行范圍分區。范圍分區在大型機 DB2 平臺上已經(jīng)存在很長(cháng)時(shí)間了，從 DB2 9 開(kāi)始在 LUW 服務(wù)器上也可用了。這個(gè)特性根據鍵值范圍把表行存儲在幾個(gè)不同的物理文件中。它對于促進(jìn)大型機服務(wù)器上的查詢(xún)并行性尤其重要。在 LUW 服務(wù)器上，它還可以通過(guò)一種稱(chēng)為數據分區消除的查詢(xún)優(yōu)化技術(shù)提高查詢(xún)的性能。 對于哪些表應該進(jìn)行范圍分區，并沒(méi)有絕對的規則，但是可以考慮對包含一百萬(wàn)或更多行的表進(jìn)行范圍分區。為表選擇的分區鍵（可以是單一列，也可 以包含多列）取決于您的需要，但是基于時(shí)間的鍵（例如日期列）對于數據存檔過(guò)程是非常高效的。注意，范圍分區與散列分區算法不同，DB2 for LUW 在使用 Data Partitioning Feature 時(shí)使用散列分區算法把表行分布到多服務(wù)器集群的節點(diǎn)上。 維持豐富、準確的編目統計信息。在我看來(lái)，DB2 具有市場(chǎng)上最好的查詢(xún)優(yōu)化器（IBM 首創(chuàng )了基于成本的 SQL 語(yǔ)句優(yōu)化），但是它必須有足夠的信息，才能做出合理的訪(fǎng)問(wèn)路徑?jīng)Q策。查詢(xún)優(yōu)化的關(guān)鍵輸入是 DB2 編目表中的統計信息，所以這些統計信息應該是最新的。最好的實(shí)現方法是定期運行 RUNSTATS（DB2 for LUW 系統上的命令，DB2 for z/OS 環(huán)境中的實(shí)用程序）。注意，DB2 9 for LUW 有一個(gè)自動(dòng)統計信息收集特性。 編目統計信息是否豐富也很重要（DB2 對數據庫中的數據了解越全面，查詢(xún)的性能就可能越好），所以應該收集您能夠收集的所有信息：關(guān)于索引和表的統計信息，盡可能多的列的基數和分布信息。請記 住，RUNSTATS 收集的信息越多，它消耗的 CPU 時(shí)間就越多；因此，如果處理能力不足，可能需要把列統計信息生成限制在查詢(xún)謂詞中使用（或很可能使用）的列。 利用索引。對于支持 OLTP 應用程序的數據庫，人們在為表創(chuàng )建索引方面往往非常保守，這有一個(gè)很合理的原因：在表上定義的每個(gè)索引都會(huì )增加每個(gè) INSERT 和 DELETE 操作的成本（如果更新的列是索引鍵的組成部分，UPDATE 操作的成本也會(huì )增加）。 在 BI 環(huán)境中，數據獲?。ǘ皇菙祿模┎僮鞯男阅芡匾?；因此，與 OLTP 數據庫相比，在數據倉庫數據庫中創(chuàng )建更多索引通常是有意義的。但是，也不要為數據倉庫表創(chuàng )建過(guò)多的索引，否則定期的 ETL 數據更新過(guò)程可能無(wú)法及時(shí)完成（這會(huì )導致數據倉庫向查詢(xún) “開(kāi)放” 的時(shí)間推遲，有時(shí)候會(huì )讓用戶(hù)不滿(mǎn)）。 在 OLTP 環(huán)境中，我一般會(huì )把每個(gè)表的平均索引數量限制在四或五個(gè)。對于 BI 系統中的數據庫，我覺(jué)得每個(gè)表八到十個(gè)索引更合適，但是我不會(huì )一開(kāi)始就創(chuàng )建這么多索引。相反，我會(huì )先為每個(gè)表創(chuàng )建五或六個(gè)索引，如果以后發(fā)現需要減少某些 查詢(xún)的運行時(shí)間，那么可以定義更多索引。 明智地使用聚簇。數據聚簇（表行的物理次序）在數據倉庫中是個(gè)重要的問(wèn)題，因為常常會(huì )大批地獲取行（而不是像典型的 OLTP 系統那樣獲取小結果集）。在連續獲取大量行時(shí)，引用的局部化（所需的行在目標表中的物理位置相互接近）會(huì )對運行時(shí)間產(chǎn)生顯著(zhù)的影響。應該盡可能精確地預測 用戶(hù)希望查詢(xún)的東西 —— 具有給定的客戶(hù) ID 的所有行？關(guān)于給定的產(chǎn)品的所有行？某一日期范圍內的所有行？ 如果兩個(gè)或更多聚簇鍵對于某個(gè)表都是有意義的，那么可以考慮使用 DB2 9 for LUW 的多維聚簇 (MDC) 特性。大型機 DB2 管理員可以使用 DB2 for z/OS V8 中提供的表分區改進(jìn)來(lái)實(shí)現多維聚簇，具體地說(shuō)，按一個(gè)鍵進(jìn)行數據分區，然后按另一個(gè)鍵對分區中的行進(jìn)行聚簇。
現在，已經(jīng)設置了 DB2 系統和數據庫，為良好的數據倉庫性能奠定了基礎。然后，用戶(hù)要執行他們的查詢(xún)和報告請求，他們很可能會(huì )發(fā)現一部分查詢(xún)的運行時(shí)間比期望的要長(cháng)?，F在怎么辦 呢？現在，要分析這些查詢(xún)，找到讓它們運行得更快的方法。我將在下一期中分享一些有用的經(jīng)驗。 學(xué)習
獲得產(chǎn)品和技術(shù)
討論
| ||||||||||||||||||
聯(lián)系客服
