使用 DB2 for Linux, UNIX, and Windows 加速 SAP CO-PA
簡介
傳統的在線事務處理 (OLTP) 工作負載包含大量并行查詢。彼此獨立地執行的查詢可由數據庫服務器并行計算。因此，通過一次由一個核心來處理一個查詢，大型、多核系統的容量可得到充分使用。
另一方面，在線分析處理 (OLAP) 工作負載通常包含少量并行運行查詢。它們讀取和聚合大量數據，并建模應用程序邏輯的各個部分。因此，OLAP 查詢更復雜，需要花較長時間來運行。單個 CPU 核心的處理能力有限。所以，要加速 OLAP 查詢，需要并行處理它們，以便使用大型的、多核系統的所有核心。這種并行處理要么通過使用數據庫分區功能 (DPF) 而面向數據，要么通過使用分區間并行性 而面向查詢。因為它很簡單且容易維護，所以分區間并行性是使用 IBM? DB2? 實現并行查詢處理的最佳選擇。
SAP? Profitability Analysis (CO-PA) 報告（主要用于下鉆分析）抓取大量記錄并將它們聚合為一個較小的結果集。在傳統上，這些結果被提前計算并存儲在 SAP 應用服務器上，以便為用戶提供可接受的響應時間。使用分區間并行性可以顯著加速查詢處理。這種速度使應用程序能夠跳過預計算步驟，直接從數據庫讀取每個導航步驟的數據。這消除了由于應用服務器上的有限資源而導致的功能限制，減少了所需的摘要級別數。根據一份示例報告，速度可提升 8 倍或更高。
SAP CO-PA 中的數據訪問方法
在 SAP CO-PA 報告中，所有數據最初都具有粗粒度細節級別。您可以細化查詢來獲得某個方面的更詳細視圖。可以 配置 SAP CO-PA，在程序啟動時一次加載所有數據，或者在您執行下鉆步驟時，在每一步中加載數據。
如果您請求在程序啟動時加載所有數據，從數據庫讀取的數據具有很細的粒度。如果按需讀取，數據具有相應的步驟所需的粒度。兩種方法各有其優勢，都可以從分區間并行性獲益。
在加載報告時僅請求數據一次有一些缺點：
- 初始報告的加載時間可能很長。
- 在報告的整個運行過程中，應用服務器上的內存使用很高。
- 報告可計算的數據量受可供應用服務器上的單個進程使用的內存的限制。
按需加載數據不需要將數據保留在應用服務器上，這降低了內存使用。此外，報告能更快地啟動，因為從數據庫傳輸到應用服務器的行數更少。通過這種方式加載的數據需要更高的與性能相關的要求。處理大量數據時，可接受的響應時間只能通過進程間并行性來實現。
摘要級別
為了減少內存使用和加速查詢處理，SAP CO-PA 使用了預先計算的摘要級別。這些摘要級別在不同的細節級別上以物理方式持久聚合。為了抓取盡可能少的數據，SAP CO-PA 使用與報告的需求匹配的最粗粒度的摘要級別。這些摘要級別可與 SAP CO-PA 報告獨立地定義和使用，以便訪問所有 SAP CO-PA 數據。另外，您可以使用特定于報告的摘要數據，其中僅包括一個 SAP CO-PA 報告的數據。
減少摘要級別數量可以消除冗余信息，節省應用服務器上的空間，并減少構建摘要級別所需的時間和資源消耗。
按需讀取數據可消除應用服務器上的內存限制。借助更快的查詢處理，只需更少的摘要級別即可滿足運行時間需求，并更快地創建它們。
方法
下面的示例演示了如何使用分區間并行性來提高 SAP CO-PA 查詢的性能。為了展示 SAP CO-PA 的工作負載特征，我將介紹報告配置，解釋 SAP CO-PA 的數據流和結構。我還將討論此場景中使用的數據的屬性。此外，我將介紹如何確定最佳摘要級別，如何啟用分區間并行性。
報告配置
報告使用 KE30 事務來配置。要查看性能設置，可以選擇 Edit Report > Options > Performance > Presummarized data 。在這里，您需要選擇 3 種數據訪問方法之一：
- Use summarization data ：使用特定于報告、動態創建的摘要數據（凍結的報告數據）。
- Use a summarization level ：讀取系統級、既定的摘要級別。
- Read upon each navigation step ：按需讀取數據。此選項也使用了摘要級別。
首選的選項是 “Read upon each navigation step”。這種數據方法方法可實現按需報告，消除執行長時間計算來逐步聚合的需求，還可以消除與應用服務器上的內存使用相關的限制。
環境
SAP CO-PA 收集的所有數據都單獨存儲在與公司的組織單元相對應的操作關注點中。每個操作關注點將其數據保存在 4 個表中。它們依據模式 CEnxxxx 來命名，其中 n 是 1 到 4 之間的一個數字， xxxx 是特定的操作關注點的名稱。為了簡便起見，下面的示例中將它們稱為 CEn 。
明細項目被寫入到按計劃和實際數據劃分的表 CE1 和 CE2 中。此數據已被合并和預先聚合，結果被拆分并寫入到分段級別 CE3 和分段表 CE4 中。關鍵數據和特定于分段的特征記錄類型、計劃/實際指標、版本和時段寫入到 CE3 中。剩余特征被寫入到 CE4 中。這兩個表是報告和創建摘要級別的主要數據來源。通常，一些明細項目包含相同的特征組合。因此，表 CE4 可再次壓縮。在這個示例場景中，這會導致 CE3 的基數變為 62,509,896 行， CE4 變為 24,603,426 行。
一個報告提供了通過定義一些謂詞和下鉆可能性來創建的數據視圖。 謂詞 縮小了報告的范圍，可根據任意特征來定義它。 下鉆 通過一系列特征來定義。最初，數據由第一個下鉆特征 c 0 來聚合。這種粗粒度概述是提供給用戶的。選擇一個條目時，會將它的值 v 0 添加到謂詞列表中，將下一個特征 c 1 添加到相應 SQL 語句的 GROUP BY 子句中。
由于所有下鉆特征都存儲在 CE4 中，所以從 CE4 抓取的行數會在每一步中減少，而從 CE3 抓取的行數保持不變。合并 CE3 和 CE4 可消除因為 CE3 上的限制而過濾掉的過時特征或項目組合。由于 CE3 與 CE4 之間存在 n:1 映射關系，所以合并結果的大小對應于 CE3 的限定行數。
您應該知道 4 個與處理的行數相關的指標：
- 從 CE4 讀取的行數
- 滿足合并謂詞的行數
- 合并結果的基數
- 分組的結果集的大小
這些基數如所示。
圖 1. 這個簡化的訪問計劃顯示了每個處理步驟的重要基數。
示例報告在表 CE3 上有一個謂詞。在表 CE4 上，只應用了下鉆謂詞。表 1 給出了每個導航步驟的 4 行。
表 1. 每個步驟和運算符讀取和返回的行
| 步驟 | 抓取的 CE4 行數 | 合并的 CE4 行數 | 合并結果 | 聚合結果 |
|---|---|---|---|---|
| 0 | 24,603,426 | 15,627,348 | 46,882,044 | 186 |
| 1 | 4,092,840 | 2,599,524 | 7,798,572 | 817 |
| 2 | 113,796 | 72,864 | 218,592 | 618 |
| 3 | 2,880 | 2,160 | 6,480 | 101 |
| 4 | 144 | 126 | 378 | 7 |
特定于報告的謂詞將從 CE3 抓取的行數從 6200 萬行減少到 4700 萬行。所以，該報告分析了 75% 的可用數據。在步驟 0 中，從 CE4 抓取的行數可以確認：最初此表上沒有限制性謂詞。從 CE4 抓取的 2400 萬行中，只有 1500 萬行滿足合并條件，這表明 37% 的數據已過時或被 CE3 上的謂詞間接過濾掉。
摘要級別
摘要級別提供來自 CE3 和 CE4 的數據作為持久化的聚合數據。使用 KEDV 事務，按選定的特征來定義細節級別。聚合數據被物化到兩個表中： K81n 和 K81(n+1) ，其中 n 和 n+1 是填充了 0 的四位數。
表 K81(n+1) 類似于 CE3 ，而且為了簡便起見，我們將它命名為 CE3S 。它包含所有關鍵數據，但只包含 period 和 year 特征。所有特征（包括最初存儲在 CE3 中的剩余 4 個特征）都被寫入 K81n 中，為了簡便起見，在本文中將它命名為 CE4S 。報告從最低細節級別的聚合級別讀取數據，以減少必須處理的數據量。
因為它會花如此長的時間來處理它們，所以摘要級別數應盡可能少。但是，在摘要級別中擁有較高的細節級別很重要，這樣就能讓其他報告共享和重用這些數據。摘要級別應該能夠減少行數。如果將特定于分段的特征從 CE3 轉移到 CE4S ，則會增加特征組合數，同時保持 CE3S 的基數不變。因此，選擇更高的細節級別有可能增加數據量，而不是減少它。
顯示了示例場景的每個下鉆級別的摘要級別表的基數。除了相應的下鉆特征之外，還添加了一個額外的特征來避免太小的表。
表 2. 每個下鉆步驟的原始表基數與摘要級別表基數的對比
| 范圍 | CE3S | CE4S |
|---|---|---|
| 原始表 | 62,509,896 | 24,603,426 |
| 步驟 0 | 13,392 | 576 |
| 步驟 1 | 429,336 | 21,888 |
| 步驟 2 | 10,863,000 | 950,616 |
| 步驟 3 | 54,721,800 | 30,890,952 |
| 步驟 4 | 62,304,984 | 61,293,816 |
| 一次性 | 62,487,792 | 62,314,560 |
步驟 3 和 4 的摘要級別太過詳細了。步驟 2 適用于一般性的摘要級別，因為它是最詳細的級別， CE4S 的基數明顯低于 CE4 的基數。根據性能需要，您可能還會考慮采用步驟 1。
啟用分區間并行性
默認情況下，SAP 環境禁用了分區間并行性。 SAP Note 2047006 解釋了如何在系統級別上或為某些語句或應用程序而啟用它。 SAP Note 2052896 描述了特定于 SAP CO-PA 的方面。
系統級的啟用將分區間并行性的默認程度設置為 ANY 。這意味著將該程度設置為基于可用 CPU 核心數量而自動計算的值。如果可能的話，將該程度設置為 ANY 是最佳選擇，因為它需要的設置和維護工作量最少。
如果為某些應用程序而啟用它，則會在數據庫端啟用分區間并行性，但默認程度被設置為 1。這最小化了對其他應用程序或工作負載的影響。默認程度可以被數據庫共享庫 (DBSL) 添加到查詢的合適的指南所覆蓋。SAP Optimizer 配置文件提供了一種方法，根據相應的數據庫對象和查詢結構向查詢添加優化指南。 SAP Note 1818503 中介紹了它們的一般用法。
針對 SAP CO-PA 查詢的分區間并行性可通過啟用一個優化器指南來設置，該指南為從 CE3 和 CE4 讀取的查詢設置了一個并行程度。要實現此目的，可使用事務 SE16 向 DB6_OPTPROFILE 添加一個條目，以便創建優化器指南。
列選項卡名稱對應于性能跟蹤信息中顯示的對象名稱。在本例中，它是屬于該操作關注點的 CE4 表的名稱。該模式必須與對 CE4 和相應的 CE3 表的所有讀取模式相匹配。實際指南以相同名稱寫入該列中。將程度值設置為 ANY ，讓 DB2 能夠根據可用的 CPU 核心數量來設置該值。這會導致產生一個 DB6_OPTPROFILE 條目，如所示。
表 3. DB6_OPTPROFILE 示例條目
| 字段 | 值 |
|---|---|
| Tabname | CE4xxxx |
| Guideline | <DEGREE VALUE="ANY"/> |
| Pattern | +[SELECT%FROM%CE4xxxx%JOIN%CE3xxxx] |
SAP CO-PA 為每個操作關注點使用不同的表。您必須為每個操作關注點和摘要級別使用單獨的配置文件條目。
因為 SAP CO-PA 查詢的謂詞是在 CE4 的字段上定義的，所以首先計算它們，然后使用索引來合并 CE3 是一種明智的做法。但是，根據謂詞的類型和數據的分布，優化器可能選擇使用其他訪問計劃。此行為可能對性能帶來負面影響，從而導致不同的響應時間。可能必須擴展該指南來對 CE4 和 CE3 執行一種固定方法方法，如下面的示例所示：
<DEGREE VALUE="ANY" /><NLJOIN><ACCESS TABLE='CE4xxxx' /><IXSCAN TABLE='CE3xxxx' /></NLJOIN>
結果
結果描述了一個從 CE3 、 CE4 或相應的摘要級別表抓取大部分數據的查詢的數據庫運行時間。所有聚合都已更新，而且沒有從 CE1 和 CE2 加載額外的數據。
我們使用的一種參考度量啟用了分區間并行性，并將默認程度設置為 “1”。基于可用的硬件資源，為使用分區間并行性的度量使用查詢程度 “16”。
沒有摘要級別
中的運行時間在度量時沒有任何摘要級別，并指明了如何在大量數據上執行報告。但是，構建摘要級別不僅能夠減少必須處理的數據量，還能改變表基數的關系和比率，如所示。一個簡單的操作關注點上的度量與一個具有類似大小的摘要級別具有有限的可比性。
表 4. 沒有摘要級別的下鉆運行時間按需讀取
| 步驟 | 程度 1 | 程度 16 | 加速 |
|---|---|---|---|
| 0 | 482.63 秒 | 61.49 秒 | 7.85 倍 |
| 1 | 106.45 秒 | 14.24 秒 | 7.47 倍 |
| 2 | 12.46 秒 | 1.63 秒 | 7.66 倍 |
| 3 | 9.79 秒 | 1.30 秒 | 7.51 倍 |
| 4 | 9.48 秒 | 1.32 秒 | 7.16 倍 |
| 總和 | 620.81 秒 | 79.98 秒 | 7.76 倍 |
一次讀取所有數據會花費 3,014.93 秒的時間。使用程度為 16 的分區間并行性，可以將查詢運行時間縮短至 1,117.82 秒，提速 2.70 倍。
使用單一摘要級別
摘要級別的最合適的細節級別取決于場景和需求。確定最詳細但仍合理的細節級別的方式如中所述。要調優單個報告，可能需要選擇較低的細節級別。
此示例場景的最詳細摘要級別在步驟 2 中。給出了在使用步驟 2 上的摘要級別的分區間并行性時獲得的運行時間和性能改進。使用分區間并行性將平均性能提高了 8.05 倍。
表 5. 具有步驟 2 中的摘要級別的下鉆運行時間按需讀取
| 步驟 | 程度 1 | 程度 16 | 加速 |
|---|---|---|---|
| 0 | 63.32 秒 | 6.87 秒 | 9.21 倍 |
| 1 | 13.30 秒 | 2.40 秒 | 5.55 倍 |
| 2 | 0.69 秒 | 0.10 秒 | 7.18 倍 |
| 3 | 9.79 秒 | 1.30 秒 | 7.51 倍 |
| 4 | 9.48 秒 | 1.32 秒 | 7.16 倍 |
| 總和 | 96.59 秒 | 11.99 秒 | 8.05 倍 |
要在此報告中獲得最佳性能，摘要級別的細節深度必須盡可能得低。您需要檢查中沒有摘要級別的每個導航步驟的運行時間。如果此場景需要短于 2 秒的數據庫運行時間，則必須為摘要級別選擇步驟 1，因為它是第一個不滿足該需求的步驟。此過程可能需要對更大的場景反復執行，以確定其他摘要級別。具有步驟 1 中的摘要級別的下鉆結果如所示。
表 6. 具有步驟 1 中的摘要級別的下鉆運行時間按需讀取
| 步驟 | 程度 1 | 程度 16 | 加速 |
|---|---|---|---|
| 0 | 2.77 秒 | 0.37 秒 | 7.43 倍 |
| 1 | 0.37 秒 | 0.19 秒 | 1.99 倍 |
| 2 | 12.46 秒 | 1.63 秒 | 7.66 倍 |
| 3 | 9.79 秒 | 1.30 秒 | 7.51 倍 |
| 4 | 9.48 秒 | 1.32 秒 | 7.16 倍 |
| 總和 | 34.88 秒 | 4.81 秒 | 7.24 倍 |
該度量結果顯示，使用分區間并行性比不使用分區間并行性快 7.24 倍。盡管它只比使用更詳細的摘要級別的速度慢一點，但下鉆過程的總運行時間快了 2.49 倍，而且每個查詢運行時間都少于 2 秒。
具有更詳細的摘要級別的分區間并行性所帶來的提速表明，速度會隨著數據庫處理的數據的增加而增加。根據數據量的大小，在使用更高程度的并行性和更多 CPU 核心時，可實現更好的性能提升。
結束語
分區間并行性的使用顯著提高了查詢的性能。在使用分區間并行性時，需要更少的摘要級別即可滿足響應時間需求。因為數據模型基于操作關注點并在所有報告之間共享，所以在應用服務器一次讀取所有數據時，或者在某個報告通常以粗粒度的細節級別讀取數據時，可能仍有必要定義一些摘要級別。
一般而言，按需讀取數據來減少應用服務器上的資源使用是可取的。這樣，摘要級別可用在出于性能原因而需要的任何地方，但它們不再需要應對應用服務器上的內存限制所導致的功能限制。使用分區間并行性可減少查詢處理時間，為用戶提供可接受的響應時間。
度量結果證實，分區間并行性的優勢會隨著分析的數據量增長而增長。示例場景已證明，速度提升可高達 8 倍。我們嘗試使用了一種逼真的測試設置，但在您的生產環境中可能會看到不同的結果。