SQE存储系列之一 —— 我的存储去哪儿了？（译文）

IBM DB2 for i 的 SQL 查询引擎所使用的五种临时存储

原文作者 Tim Clark

存储的故事

如果你有准备和服务一顿丰盛的晚餐的经验，你就会知道厨房里所用的菜的数量往往比上桌的菜的数量多好几倍。准备一份简单的沙拉可能需要使用多个碗，滤器和切菜板，直到最后的作品准备好上桌。虽然每个容器在准备过程中可能只使用很短的时间，但没有它们，将一顿饭放在一起将是困难的。

就像五星级餐厅的厨师一样， SQL 查询引擎（ SQE ）寻求快速地为您提供最好的结果。和那个厨师一样， SQE 经常需要额外的工作空间。它通过分配临时存储空间来优化和运行查询来实现这一点。随着时间的推移， IBM DB2 继续添加新的功能， SQE 在 IBM i 上的数据库工作负载中所占的份额也越来越大。例如， IBM i 7.2 通过将 SQE 作为本地数据库访问的默认引擎（包括 WRKQRY 、 RUNQRY 和 OPNQRYF 命令），实现了这一最大的转变。因此，即使您的工作负载保持不变， SQE 所使用的临时存储的数量也可能会在版本到版本的升级之中产生增加。而随着 SQE 去做更多的工作，它也将消耗更多的临时空间来实现有效的操作。

大多数时候，您不需要考虑或了解系统上临时存储的状态。 IBM i 存储管理及其精心调优的算法会负责保持工作负载的平稳运行。但是，偶尔您可能会看到编写得很差的查询或糟糕的计划导致临时存储的过度使用。 SQE 将防止一个查询耗尽系统的存储空间，但是一个或几个查询使用过多的存储空间仍然会对其他 IBM i 工作负载产生不利的影响。有时，增加的存储使用量表明存在某个错误的数据模型或某个编写糟糕的查询。您（或您的数据库工程师）必须能够检测这样的情况，进而清除它并防止它再次发生。要能够这样做，就需要您能理解为什么需要临时存储，以及系统上正常的数据库工作负载是什么样子的。有许多 IBM i 工具可以帮助您，在后续文章中，我们将讨论那些可以用来分析和管理临时 SQE 存储的工具和技术。

现在，我们将通过探索 SQE 所使用的五种临时存储来奠定基础。从 IBM i 7.2 开始，您可以看到 SQE 当前使用的每种存储的数量。只需查询 QSYS2.SYSTMPSTG 这个视图（详情请参见 IBM Knowledge Center ）。在这个视图中，系统范围的临时存储由 GLOBAL_BUCKET_NAME 列中出现的值来标识。那些和 SQE 相关的最重要的 Bucket （分类）名都以 *DATABASE 开头。

图 1 – 查询 SYSTMPSTG

select GLOBAL_BUCKET_NAME, 
          BUCKET_CURRENT_SIZE 
  from QSYS2.SYSTMPSTG 
  where GLOBAL_BUCKET_NAME like '*DATABASE%' 
  order by 2 desc;

在具有较高 SQL 负载的系统中，这五个 Bucket （如图 1 所示）的数值可能相对较大，但它们在使查询引擎能够快速交付结果方面发挥着重要的作用。针对一个特定的工作负载，这些 Bucket 的取值将各自趋向于达到一个（相对）稳定的状态。不过，达到这种稳定状态可能需要时间。记住，这些分配是在临时的存储当中进行的，所以它们在系统进行初始程序加载（ IPL ）时就会消失。结果就是，在 IPL 后，它可能需要几个小时或着几天的时间来使存储的使用趋于平缓。重要的是要意识到这是正常的。熟悉系统和数据库工作负载的正常情况是检测和诊断潜在问题的关键。

临时存储总是从系统硬盘池 —— 也称为系统辅助存储池（ ASP ），中分配。这适用于 SQE 所涉及的临时存储，即使那些存储数据的永久对象（表和索引）位于用户 ASP 或者独立辅助存储池（ IASP ）当中。这意味着，如果系统 ASP 中的空间受到限制，即使在具有足够空闲空间的 IASP 中运行的数据库工作负载也可能仍旧会遇到困难。而如果您拥有跨多个 IASP 的多个数据库工作负载，这将变得尤为重要。高效运行的数据库需要系统 ASP 具有足够的存储空间，以满足所有 ASP 及其工作负载的临时存储需求。

在这五个 SQE 的 Bucket 当中，最重要的是 “DATABASE SQE Heap” 、 “DATABASE Segment Cache” 和 “DATABASE DSI SQE MTI” 。这些通常是最大的部分，我们将对它们投入最多的注意力。另外两个 Bucket ， “DATABASE DS SQQQ LOB” 和 “*DATABASE DS SQQQ LOB” ，我们将在本文的最后对它们进行简要的讨论。

*DATABASE SQE Heap

我们关注的第一个 Bucket 是 “*DATABASE SQE Heap” 。堆是查询引擎的优化器在处理和优化查询时用作临时暂存区的存储。优化所需的内部数据结构不断地从堆中分配和取消分配。一些堆存储只在短时间内使用，并在优化完成时返回给系统。不过另外一些堆的分配可能会持续长得多的时间 —— 几个小时或者几天。这是因为堆也是存放那些用于产生 SQE 计划缓存（ Plan Cache ）的数据结构的初始场所。

计划缓存是保存计划的地方，允许多次运行相同的查询，而不必在每次执行时都经过优化过程。 IBM 知识中心 对其进行了更详细的描述。作为已被优化了的访问计划（ Access Plan ）的存储库，计划缓存必须保留有足够的信息，以便下次再运行其中的查询时，能够直接运行与之相关的访问计划。该信息是从堆存储中分配的。计划缓存中的访问计划越多，意味着被分配给 SQE 堆的系统存储空间越多。分配给计划缓存的存储空间数量受计划缓存大小（ Plan Cache Size ）的限制。这个大小通常由查询引擎管理。这个大小也可以由具有适当权限的用户进行显式地设置，但很少有必要去这样做。

*DATABASE Segment Cache

当需要运行 SQL 查询时，查询引擎可能还需要一定数量的存储空间（按 “ 区段 ” 分配），以便在处理数据时临时保存它们。这些数据被保留在那些查询运行时对象当中 —— 例如像列表、缓冲区和哈希表那样的数据结构。这些运行时对象主要为实现诸如排序、聚合、同步多处理（ SMP ）的缓冲区以及其它的一些功能和特性。分配给这些对象的存储被标记为 “*DATABASE Segment Cache” 。根据优化器的自主决断，这些临时数据对象有时可能会在查询完成后继续存储在计划缓存中。这允许查询的后续运行能够跳过重新填充这些临时对象的那些工作（如果其底层数据源没有更改的话）。随着计划缓存的变大 —— 受系统配置和优化器内部管理的限制 —— 通常也会缓存更多的临时数据对象。

当运行时对象不再被需要时，关联的区段可能不会立即返回给系统。取而代之的是适当地将一部分的存储空间放入区段缓存当中，以便其他的查询可以来使用这些缓存。这样做的目的是为了避免系统分配缓存和回收缓存过程中所产生的额外开销。这些缓存所涉及的存储空间也被包含在 “*DATABASE Segment Cache” 这个 Bucket 所报告的取值当中。

*DATABASE DSI SQE MTI

与上面描述的查询运行时对象类似，临时维持索引（ MTI ）可以用来帮助查询引擎进行优化和运行查询。在结构和功能上，这些临时索引与用户创建的永久基数索引是相同的，但它们完全由查询引擎来管理。与用户索引类似，每个 MTI 都与某个特定的表相关联，并且所有数据都驻留在临时存储中。用于 MTI 的存储在 SYSTMPSTG 视图中被标记为 “*DATABASE DSI SQE MTI” 。 MTI 的生命周期及其相应的内存分配可能会因其用途、使用情况，和其他因素而有所不同。有关更多信息，请参见 IBM 知识中心 。

The LOB Buckets

正如您可能从名称中推测的那样，最后两个 Bucket 是专门针对数据库中的大对象（ LOB ）的使用的：包括字符大对象（ CLOB ）和二进制大对象（ BLOB ）。标记为 “DATABASE DS SQQQ LOB” 的 Bucket 所代表的存储用于在处理查询时临时保存大对象数据。在关闭查询之后，相关存储空间将得以回收。标记为 “DATABASE DS SQE LOB” 的 Bucket 与区段缓存的关系更为密切，因为它为查询运行时对象所引用的那些大对象提供存储。因此，当查询运行时对象被和缓存计划一同保留的情况下（参见上面的内容），任何关联的 LOB 存储也将同样被继续保留在缓存里。当然，一个只有很少 LOB 数据或没有 LOB 数据的系统很可能会看到这两个 Bucket 的取值较小。

祝你胃口好

把这些部分放在一起，我们可以看到标记为 “DATABASE SQE Heap” 的 Bucket 既包括分配给计划缓存的存储，也包括优化器当前使用的存储。标记为 “DATABASE Segment Cache” 的 Bucket 包括了与计划缓存相关的临时数据对象的存储，包括了当前运行的查询正在使用的数据所占用的存储，以及用于快速重用的缓存存储。标记为 “*DATABASE DSI SQE MTI” 的 Bucket 则用于优化器选择构建的临时维护索引（ MTI ）。最后的两个涉及 LOB 的 Bucket 则是为了便于高效地使用大型对象。为使查询获得快速响应，这些 Bucket 中的每一个对于相关 SQE 的运行工作都是至关重要的。

既然我们已经完成了对厨房的简短参观，我希望你能够更清楚地了解厨师在那里做什么以及他为什么把那些平底锅整的动静老大。他的 “ 疯狂 ” 是有原因的。与此同时，也许你可以做一些事情来帮助他，使一切井然有序。这将是本系列第二篇文章的主题。我们将了解如何使用 IBM i 中已有的工具来调试临时存储问题，以确保数据库工作负载的平稳运行。下次见！

原文地址：Where did my storage go? – IBM Developer