在 DB2 LUW 中，我什么时候应该使用 4K、8K 或 16K 表空间，而不是仅仅创建一个 32K 表空间并完成它？

Question

我们在 Windows 和 Linux 系统上使用 DB2 LUW 10.5 和 11.1，以防它与他的答案相关。

问题：是否有时间使用 4K 而不是 32K 是正确的？如果是这样，为什么？（当它可以使用时它的性能会更好吗？）或者，它只是史前时代的遗留附属物，当时 4K 只是页面大小？

背景：当我创建 DB2 数据库时，我总是只创建 4K、8K、16K 和 32K 表空间和关联的缓冲池。

我的经理在这方面向我提出挑战。（对他有好处 - 我应该知道这一点！）他认为我们应该创建一个 32K 的表空间并完成它。

我找不到任何告诉我的信息，例如，当行大小允许时，我们应该使用 4K 而不是 32K，因为 XYZ。它告诉我，我CAN做到这一点，但不是说/我应该在何时。

Answer 1

这是一个很好的问题，但遗憾的是，答案值得在一本并不存在的书中写一整章。您链接到的 Ember Crooks 的文章是一个很好的概述；我将在此处添加一些在决定表空间页面大小时可能需要考虑的随机因素。

TL; 博士。

考虑以下几点，选择最适合您的数据的页面尺寸。如果您的性能测试显示可以通过将某些表移动到具有不同页面大小的表空间来解决的问题，请谨慎执行。

决定因素。

正如您所提到的，表格行宽决定了容纳它们所需的最小页面大小。尽管您总是想要“适用于您的数据的最小的”，但这并不意味着。

首先，以较小的页面大小“避免不必要的 I/O”和“一次处理更少的数据”的常见论点可能有点错位。如果您的表空间容器位于可能使用旋转磁盘或 SSD 的未知数量的 RAID6 设备上的 Ceph 卷上的 VMWare 虚拟磁盘上的 LVM 卷上的 ZFS 文件系统上，您真的知道您的 4K 有多少物理 I/O （或32K）读请求会引起什么？

如果您的工作负载创建了无法通过其他方式解决的表空间热点（大多数 I/O 请求进入有限数量的页面），则较小的页面大小肯定会有所帮助。在这种情况下，较小的页面可以提高缓冲池效率并减少代理之间竞争访问同一页面的页面闩锁等待。另一方面，较小的页面大小意味着较长的 LRU 链，因此可能效率较低的页面清理。

对于更大的页面大小也有争论。

LOB 数据的存在。

通常 LOB 数据存储在表行之外，在单独的数据结构中，有几个性能缺点：

• 您只能通过绕过数据库缓冲池的同步直接读取和写入来访问它们；如果为表空间启用，唯一可用的缓存是底层文件系统的缓存；直接读取也不利用页面预取。
• 由于 LOB 未加载到缓冲池中，因此对相同数据的重复访问将导致重复直接读取请求。
• 即使启用了表压缩，它们也不会被压缩。

如果您的大部分 LOB 值相对较小，并且可以在页面大小较大的情况下放入行本身（通常情况下），您可以将它们内联存储，从而减轻这些缺点。

压缩。

较大的页面大小可提高自适应（页面级）压缩的效率。通常，数据压缩提供的 I/O 减少超过其 CPU 成本。

不要忘记临时表空间。

即使您的每个表都可以单独放置到 4K 表空间中，也可能需要具有更大页面大小（和相应的缓冲池）的系统临时表空间。如果查询连接来自两个或多个表的低于 4K 的行，结果集宽度可能会超过 4K 限制，如果需要溢出，则需要一个适当大小的表空间。

值得一提的是，“以防万一”创建每个可能页面大小的表空间并不是一个好主意，因为正如您所说，每个表空间都需要一个专用的缓冲池，并且除非必要，否则多个缓冲池几乎总是比一个大的。