使用 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 ₀ 来聚合。这种粗粒度概述是提供给用户的。选择一个条目时，会将它的值 v ₀ 添加到谓词列表中，将下一个特征 c ₁ 添加到相应 SQL 语句的 GROUP BY 子句中。

由于所有下钻特征都存储在 CE4 中，所以从 CE4 抓取的行数会在每一步中减少，而从 CE3 抓取的行数保持不变。合并 CE3 和 CE4 可消除因为 CE3 上的限制而过滤掉的过时特征或项目组合。由于 CE3 与 CE4 之间存在 n:1 映射关系，所以合并结果的大小对应于 CE3 的限定行数。

您应该知道 4 个与处理的行数相关的指标：

• 从 CE4 读取的行数
• 满足合并谓词的行数
• 合并结果的基数
• 分组的结果集的大小

这些基数如所示。

图 1. 这个简化的访问计划显示了每个处理步骤的重要基数。

示例报告在表 CE3 上有一个谓词。在表 CE4 上，只应用了下钻谓词。表 1 给出了每个导航步骤的 4 行。

表 1. 每个步骤和运算符读取和返回的行

特定于报告的谓词将从 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. 每个下钻步骤的原始表基数与摘要级别表基数的对比

步骤 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 示例条目

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. 没有摘要级别的下钻运行时间按需读取

一次读取所有数据会花费 3,014.93 秒的时间。使用程度为 16 的分区间并行性，可以将查询运行时间缩短至 1,117.82 秒，提速 2.70 倍。

使用单一摘要级别

摘要级别的最合适的细节级别取决于场景和需求。确定最详细但仍合理的细节级别的方式如中所述。要调优单个报告，可能需要选择较低的细节级别。

此示例场景的最详细摘要级别在步骤 2 中。给出了在使用步骤 2 上的摘要级别的分区间并行性时获得的运行时间和性能改进。使用分区间并行性将平均性能提高了 8.05 倍。

表 5. 具有步骤 2 中的摘要级别的下钻运行时间按需读取

要在此报告中获得最佳性能，摘要级别的细节深度必须尽可能得低。您需要检查中没有摘要级别的每个导航步骤的运行时间。如果此场景需要短于 2 秒的数据库运行时间，则必须为摘要级别选择步骤 1，因为它是第一个不满足该需求的步骤。此过程可能需要对更大的场景反复执行，以确定其他摘要级别。具有步骤 1 中的摘要级别的下钻结果如所示。

表 6. 具有步骤 1 中的摘要级别的下钻运行时间按需读取

该度量结果显示，使用分区间并行性比不使用分区间并行性快 7.24 倍。尽管它只比使用更详细的摘要级别的速度慢一点，但下钻过程的总运行时间快了 2.49 倍，而且每个查询运行时间都少于 2 秒。

具有更详细的摘要级别的分区间并行性所带来的提速表明，速度会随着数据库处理的数据的增加而增加。根据数据量的大小，在使用更高程度的并行性和更多 CPU 核心时，可实现更好的性能提升。

结束语

分区间并行性的使用显著提高了查询的性能。在使用分区间并行性时，需要更少的摘要级别即可满足响应时间需求。因为数据模型基于操作关注点并在所有报告之间共享，所以在应用服务器一次读取所有数据时，或者在某个报告通常以粗粒度的细节级别读取数据时，可能仍有必要定义一些摘要级别。

一般而言，按需读取数据来减少应用服务器上的资源使用是可取的。这样，摘要级别可用在出于性能原因而需要的任何地方，但它们不再需要应对应用服务器上的内存限制所导致的功能限制。使用分区间并行性可减少查询处理时间，为用户提供可接受的响应时间。

度量结果证实，分区间并行性的优势会随着分析的数据量增长而增长。示例场景已证明，速度提升可高达 8 倍。我们尝试使用了一种逼真的测试设置，但在您的生产环境中可能会看到不同的结果。