上个月，我在这篇博客上发布了一篇关于期待已久的以在线方式将表从多表分段或简单表空间迁移到多个单表按增长分区表空间的功能（这是 Db2 12 for z/OS 的功能级别 508 提供的功能）的条目。本月，我将介绍一个更新的 Db2 功能部件，该特性还支持将表从一种表空间类型联机迁移到另一种表空间类型。此功能是随 Db2 13 for z/OS 的函数级别 500 一起引入的，它允许 DBA 使用 ALTER TABLE 语句和随后的联机 REORG 将表从按范围分区的表空间迁移到按范围分区的表空间。请继续阅读以了解更多信息。
动机
当 Db2 9 for z/OS 引入通用按增长分区 （PBG） 表空间类型时，许多 DBA 的反应非常热烈，这其中有很好的理由：它使表的大小能够增长到 64 GB 以上，而不必进行范围分区。毕竟，对表进行范围分区需要大量的前期分析。表的分区键应该是什么？表应具有多少个分区？每个分区的限制键值应该是多少？相比之下，PBG 表空间具有更多的“设置并忘记它”的质量 - 您只需确定表空间的适当 DSSIZE 值（表空间分区的最大大小）和最大分区数（MAXPARTITIONS 规范 - 如果需要，可以在以后轻松更改），您就完成了。例如，如果表空间的 DSSIZE 值是 16G（即 16 GB），那么当分区 1 达到该大小时，那么 Db2 将自动为该表空间添加第二个分区，当该分区达到 16 GB 时，Db2 将添加第三个分区，依此类推。容易。
随着某些 PBG 表空间变得越来越大，在多个 Db2 for z/OS 站点上出现了一些“买方的悔恨”。为什么？因为表越大，所以将表放在按范围分区 （PBR） 表空间中越有利。我在几年前发布到此博客的条目中描述了这些PBR与PBG的优势（对于大型表）。它们包括潜在的更大（可能更大）的插入吞吐量，这要归功于能够让多个行插入进程同时执行PBR表空间的不同分区;非常适合在时间序列的基础上管理的数据行;和最大的分区级实用程序独立性。然而，这是一个难题：在 Db2 13 之前，将表从 PBG 获取到 PBR 表空间的唯一方法是卸载表，删除表，在 PBR 表空间中重新创建表，然后重新装入表的数据。然后，您遇到了这种恼人的情况：随着表变大，PBR与PBG的优势会更加明显，但是由于卸载/删除/重新创建/重新加载要求，随着表变大，从PBG更改为PBR更具挑战性。
进入 Db2 13，这种情况会有很大的变化。
Db2 13 的区别
假设您在 PBG 表空间中有表，并且您非常希望 BIGTAB 位于 PBR 表空间中。在 Db2 13 系统（Db2 13 于今年 5 月 31 日正式发布）中，激活了函数级别 500（或更高版本），您可以发出以下 SQL 语句（我以绿色突出显示了新语法，并且我假设 BIGTAB 的ACCT_NUM列是所需的分区键）：
ALTER TABLE BIGTAB
ALTER PARTITIONING TO PARTITION BY RANGE (ACCT_NUM)
(PARTITION 1 ENDING AT (199),
PARTITION 2 ENDING AT (299),
PARTITION 3 ENDING AT (399),
PARTITION 4 ENDING AT (MAXVALUE));
复制该更改是挂起的更改。当随后为 BIGTAB 的表空间执行联机重组组时，从该联机重组中出来，BIGTAB 表将位于 PBR 表空间中。做。该表将具有与以前相同的索引，并且用户和程序将立即可以访问该表。
一些其他信息和注意事项
请记住以下几点：
-
新 PBR 表空间的分区最初将具有与要迁移到 PBR 的 PBG 表空间相同的 DSSIZE，这很重要。原因如下：在确定新 PBR 表空间的分区方案时，需要考虑在给定 DSSIZE 的情况下，属于给定分区的所有行（根据 PBR 表空间的分区方案）是否适合该分区。例如，假设（并继续前面引用的 BIGTAB 表），BIGTAB 的 PBG 表空间的 DSSIZE 值为 4G，并且 BIGTAB 中ACCT_NUM值大于 199 且小于或等于 299 的行数（即，将进入新 PBR 表空间的分区 2 的行）将不适合 4 GB 的数据集。在这种情况下，更改后的在线重组将失败。为了避免这种失败，您需要更改分区方案，以便分配给给定分区的行将适合 4 GB 的数据集，或者将 BIGTAB PBG 表空间的 DSSIZE 值更改为大于 4G 的值。如果您决定后一种操作（增加 BIGTAB 的 PBG 表空间的 DSSIZE 值），请了解您需要为表空间发出该 ALTER（以转到较大的 DSSIZE 值），然后执行联机重组以实现该更改，然后发出 ALTER 以从 PBG 更改为 PBR 并执行另一个联机重组以实现该挂起的更改。为什么是两个在线重组？因为，当您采取措施以联机方式将 PBG 表空间更改为 PBR 时，PBG 表空间不能有任何其他未完成（即尚未实现）的挂起更改 – 对 PBR 的更改必须是 PBG 表空间的唯一挂起更改。
-
新的 PBR 表空间将使用相对页码 （RPN），这是在 Db2 12 for z/OS 中引入的。这是一件非常好的事情。要了解原因，请查看我几年前写的关于RPN的博客文章。
-
与实现挂起的更改时经常发生的情况一样，将 PBG 表空间更改为 PBR 的联机 REORG 将使依赖于关联表的包失效。您可以通过查询 Db2 目录中的 SYSPACKDEP 表来标识这些依赖包。
-
从 PBG 到 PBR 的此“更改 + 联机重组”路由不适用于具有 XML 列或 LOB 列的表。
结束语
如果您使用的是 Db2 12，并且您有一些 PBG 表空间，并且希望以在线方式轻松地将其更改为 PBR，那么我在此描述的增强功能可能是启动 Db2 13 迁移项目的一个很好的理由。
原文标题：Db2 for z/OS: The Online Path from a Partition-by-Growth Table Space to Partition-by-Range
原文作者：Robert Catterall
原文地址：https://planetmainframe.com/2022/06/db2-for-z-os-the-online-path-from-a-partition-by-growth-table-space-to-partition-by-range/
