【IT168 技术文档】
简介
随着企业的成长，越来越多的用户和客户需要访问数据库中的数据。因此，需要增加数据库的容量，以满足这一需求。与此同时，容量的增加又间接地增加了硬件需求，以便在物理上能够存储日益增长的信息和数据。虽然与十五年前相比（那时候一个 250 MB 的硬盘就要花费 200 美元），硬盘的成本降低了很多，但是对于企业来说，增加磁盘驱动器仍然需要一笔不容忽视的成本。
最后，随着内部用户和客户数量的增加，需要确保在适当的级别上为适当的人员授予特权，以避免数据库的潜在安全风险。
DB2 Viper 2 提供了一个 最近重新设计的离线重分发数据库分区组实用程序，通过该实用程序，不必使用之前版本的 REDISTRIBUTE DATABASE PARTITON GROUP 所要求的那么多的数据库日志空间或时间就可以增加容量。
行压缩 是在 DB2 9 中引入的。行压缩的一个优点是，如果压缩有效，则可以提高查询的性能，因为预取器可以将更多的数据放进缓冲池。但是，只能使用离线 reorg table 命令或 inspect 实用程序来创建压缩字典。DB2 Viper 2 中引入了 自动字典创建特性，以进一步增强行压缩。
最后，Viper 2 中现在提供了 数据库角色特性。通过该特性可以使权限和特权的建模更贴近企业结构。它还可以缓解由组特权限制导致的某些问题。
1. 重新设计的重分发数据库分区组实用程序
欲调用这个最近重新设计的实用程序，可像之前那样发出 REDISTRIBUTE DATABASE PARTITON GROUP 命令，但是这里可以指定更多的选项（见 1.2 小节的演示）。1.3 小节会详细解释该特性。
为了添加新的数据库分区，首先需要更新实例，使之包括新的分区。和之前的版本一样，如果数据库管理器已经被停止，或者您愿意通过 db2stop 使数据库管理器离线，则可以使用 db2start add node 命令来更新。如果数据库实例仍在运行，那么可以使用 sqleaddn API 或者 add dbpartitionnum 命令。
将新的数据库分区添加到实例之后，该实例中的每个数据库就可以利用新添加的数据库分区。可以选择将这个额外分区添加到某一个数据库分区组。建议发出 ALTER DATABASE PARTITION GROUP 语句来定制表空间设置，并控制新分区中的容器布局。如果想复制分区组中第一个分区的设置，则可以在 REDISTRIBUTE DATABASE PARTITON GROUP 命令中利用新的 add dbpartitionnum 选项。
和从前一样，有三种方法可生成数据库分区映射：平均法，通过分布数组指定权重（使用 distfile），以及用户指定（使用 targetmap）。
旧版本的重分发实用程序通过子选择语句使用特殊的 insert 和 delete。对于每个重分发的表，它都要进行提交。因此，该实用程序会生成很多数据库日志活动。如果数据库日志文件比较小，则会很快用完日志空间，并导致重分发失败。对于所移动的每一行，有两个动作 — insert 和 delete。数据是逐行移动的。因此，这样大大增加了重分发时间。
新版本的重分发实用程序使用小型日志记录模型和页级数据移动（见 1.1 小节中的解释）。因此可以减少对数据库日志文件的使用和提高数据移动的速度。
性能在三个方面得到了提高：
消除了逐行操作（使用页级数据移动）
支持并发表
将多个操作合并成一个操作
通常，在数据库分区组重分发之后，需要在重分发的表上执行离线的 table reorg、index recreation（必要时）和 runstats。这些操作中：redistribute、table reorg、index create 和 runstats，每个操作都需要扫描一次表数据。因此，如果能将所有这三个操作合并成一个操作，则可以大大提高性能。此外，日志记录被减至最少，以免多次分解重分发实用程序，并且不必管理大量的活动日志空间和日志归档空间。最后，重分发实用程序的可用性方面也得到了提高，现在可以指定表顺序，并且可以逐个表地停止和继续重分发数据表。此外，新版本还引入了一个用户友好的进程监视特性和一个 SQL 接口，可以从任何客户机远程访问该特性。可以通过命令行处理器（CLP）（list utilities 和 list utilities show details）或 管理视图（SNAPUTIL 和 SNAPUTIL_PROGRESS）或管理表用户定义函数（UDF）（SNAP_GET_UTIL 和 SNAP_GET_UTIL_PROGRESS） 检索进程信息。
1.1 非前滚可恢复性
由于与每种对象类型的数据移动相关的所有更新都没有被记录到日志中，因此重分发实用程序不是前滚可恢复的。这意味着，通过 redistribute 操作进行前滚的效果是，所有被重分发的表都被标记为 “invalid”（无效）。这些表没有任何用处，只得删掉。
建议在运行离线重分发实用程序之前，对数据库进行完全备份。最起码要确保在使用重分发实用程序之前采取了足够的表空间备份，以便必要时能将数据库恢复到 redistribute 操作之前的时间点上。
当该实用程序开始重分发一个表时，它将与该表有关的所有表空间（数据表空间、索引表空间和 long 表空间）都置于 BACKUP PENDING 状态，并将这个表本身标记为 unavailable 和 redistribute_pending。在这个表被重分发之后（回到正常状态），需要进行一个表空间级的备份，以便重新获得对该表的全部访问权。
理论上讲，可以在数据库分区组中尚未重分发的表上执行 select、insert、update 或 delete 语句。而且，当重分发实用程序仍在运行时，如果在与该表相关的表空间上执行了表空间备份，那么也可以在被重分发的表上执行相同的操作。但是，由于重分发不是前滚可恢复的，如果由于任意原因使重分发恢复选项 — 继续或终止 — 不能继续或终止之前失败的重分发，那么在重分发期间并发运行的任何事务都可能被丢失。因此，最好不要执行只读操作（例如 SELECT）之外的任何操作。
*******************************************************************
提示：
如果日志中间有重分发操作，那么不要前滚这样的日志！
在使用重分发实用程序前后总是进行备份。
*******************************************************************
1.2 最近重新设计的实用程序的语法
清单 1. 语法图
>>-REDISTRIBUTE DATABASE PARTITION GROUP--database partition group--> >--NOT ROLLFORWARD RECOVERABLE--------------------------------------> >--+-+-UNIFORM------------------+--+--+----------------------------+-> | '-USING DISTFILE--distfile-' | '--| ADD/DROP DBPARTITION |--+ +-USING TARGETMAP--targetmap------------------------------------| +-CONTINUE------------------------------------------------------+ '-ABORT---------------------------------------------------------' >--+---------------------------------------+------------------------> | .-,----------. | | v | ,--ONLY-, | '--TABLE-(---table name-+-)--+-------+--+ '-FIRST-, >--+----------------------------+---------------------------------->< '--| REDISTRIBUTE OPTIONS |--' ADD/DROP DATABASE PARTITION SPEC: >--+-----------------------------------------------------+----------> | .-,----------------. | | v | | +--ADD--+-DBPARTITIONNUM--+-(---n--+---------+--+-)--+ '-DBPARTITIONNUMS-' '--TO m--' >--+-----------------------------------------------------+----------> | .-,---------------. | | v | | +--DROP--+-DBPARTITIONNUM--+-(---n--+--------+--+-)--+ '-DBPARTITIONNUMS-' '--TO m--' REDISTRIBUTE OPTIONS: |--+---------------------------------------------+------------------> | | +---PARALLEL TABLE --n------------------------+ | | | ,--COMPACT ON---, | +---+ +-------------------------+ | '--COMPACT OFF--' | | | | ,--INDEXING MODE AUTOSELECT--, | +---+ +------------+ | +--INDEXING MODE INCREMENTAL-+ | | +--INDEXING MODE REBUILD-----+ | | '--INDEXING MODE DEFERRED----' | | | +---DATA BUFFER --n---------------------------+ | | | ,--STATISTICS USE PROFILE--, | +---+ +--------------+ | '--STATISTICS NONE---------' | | | '---STOP AT--local-isotime-------------------'
注意，关键字方面有一个变化。旧的关键字 ROLLBACK 已经不赞成使用，而被新的关键字 ABORT 取代。这是因为 ROLLBACK 很容易与事务回滚混淆，而 ABORT 则与其他实用程序更加一致。
1.3 最近重新设计的实用程序中的特性
第一个特性是为已有数据库分区组添加或删除数据库分区，以及在相同命令上执行重分发的能力。这在过去是由两个步骤组成的一个过程，首先需要发出 ALTER DATABASE PARTITION GROUP 语句来添加或删除分区。如果您正在添加数据库分区，那么会被请求为新的分区指定表空间信息。
可以在同一个命令上同时指定添加和删除数据库分区，但是必需先添加，后删除。否则，语法就不能被识别。如果想撤掉一些旧的计算机，并添加更强大的计算机到数据库 DPF 集群中，那么您很可能会同时指定添加和删除。注意，如前所述，添加分区选项会自动根据组中第一个分区的表空间设置在新分区上创建表空间。
在发出 REDISTRIBUTE DATABASE PARTITION GROUP 命令时，可以指定 8 个新选项：TABLE FIRST、TABLE ONLY、PARALLEL TABLE、COMPACT、INDEXING MODE、DATA BUFFER、STATISTICS 和 STOP AT。可以将所有这些选项应有到开始的 redistribute 命令上，或者应用到随后的 redistribute continue 或 redistribute abort 命令上。
TABLE FIRST
TABLE FIRST 选项允许指定数据重分发期间优先于其他表的一组表。在这组表被重分发之后，再根据 DB2 决定的顺序对数据库分区组中剩下的表进行重分发。如果命令成功，并返回 sqlcode 0，则组中所有的表都被重分发。
TABLE ONLY
TABLE ONLY 选项允许指定数据重分发期间将被重分发的一组表。在重分发这组表之后，不再重分发数据库分区组中剩下的表。因此，分区组只是部分重分发，剩下的表可以在下次使用 redistribute 命令和 continue 选项来重分发。
PARALLEL TABLE
PARALLEL TABLE 选项告诉重分发实用程序，在表级并行执行重分发，并同时重分发其中的多个表。如果不显式地指定该选项，DB2 默认地使用两个表的并行度（parallel table 2 选项）。
COMPACT
COMPACT ON 是重分发实用程序的默认选项，它像离线 table reorg 那样执行空间压缩。可以显式地指定或者关闭该选项。
INDEXING MODE
默认情况下，当重分发数据时，使用索引模式 autoselect。这意味着，DB2 从重新构建和增量索引维护两种方法中选择最合适的方法。也可以指定重新构建或者增量选项。如果按照指定的方法不能合法地使用索引，则重新创建索引。如果您想先将所有索引标记为坏索引，以后再重新创建它们，那么可以指定 deferred 选项。
DATA BUFFER
和装载实用程序一样，可以指定想从实用程序堆中获得多少内存来运行这个实用程序。如果不指定一个值，DB2 自行决定一个最适合的值，并使用那个值。
STATISTICS
如果一个表已经有一个来自之前运行的 runstats 操作的 statistics profile，那么可以指定 statistics use profile（或保留默认设置）。当数据被移动到适当的分区之后，该实用程序自动使用已有的 statistics profile 在任何表上执行 runstats。可以通过指定 STATISTICS NONE 关闭该选项。
可能出现这样的情况：表已经有一个 statistics profile，虽然指定了 statistics 选项，但是实用程序不能执行统计信息收集。如果所有分区都处于 combo 状态，都在发送和接收数据，那么不能收集统计信息。这通常被称作交叉数据移动（xcross data movement）。例如使用具有如下数据移动的目标映射的重分发：
partition 11 -> partition 11, 19, 51
partition 19 -> partition 11, 19, 51
partition 51 -> partition 11, 19, 51
因此，每个分区都将数据发送到所有其他分区，同时留有部分数据。
STOP AT
STOP AT 允许指定一个时间，当到了这个时间时，即使重分发实用程序还没有完全完成所有表的重分发，也必须停止执行。重分发实用程序估计重分发一个表需要多长时间，并比较当前时间和停止时间（如果指定了的话），看看是否能在允许的时间内完成。如果估计可以按时完成，那么它就开始重分发那个表。由于这只是一个估计，因此未必能在指定时间停止，但是尽可能接近指定的时间。
1.4 监视重分发进程
DB2 Viper 2 允许使用已有的实用程序监视界面监视重分发实用程序的进程：CLP（LIST UTILITIES 和 LIST UTILITIES SHOW DETAILS 命令）或管理视图（SNAPUTIL 和 SNAPUTIL_PROGRESS）或管理表 UDF（SNAP_GET_UTIL 和 SNAP_GET_UTIL_PROGRESS）。
下面是正在进行数据重分发时发出 db2 LIST UTILITIES SHOW DETAILS 后得到的输出。这里正在用一个新添加的分区对数据库分区组 RDST_V10_015 进行重分发。指定的其他选项有 COMPACT ON （默认）、INDEXING MODE INCREMENTAL 和 PARALLEL TABLE 3。还应注意，该输出只显示了一个分区。实际的输出会显示每个分区，包括新添加的分区。
清单 2. 监视重分发进程的示例输出
db2 list utilities show detail ID = 1 Type = REDISTRIBUTE Database Name = RDST819 Partition Number = 11 Description = RDST_V10_015 UNIFORM ADD NODES COMPACT ON SPACE REUSE RECORD LEVEL INDEXING MODE INCREMENTAL Start Time = 02-20-2007 23:21:33.785819 State = Executing Invocation Type = User Progress Monitoring: Estimated Percentage Complete = 8 Summary: Total Work = 1965600 Completed Work = 155221 Total Number Of Tables = 15 Tables Completed = 0 Tables In Progress = 3 Current Table 1: Description = "NEWTON "."RDST_V10_015A" Total Work = 655200 bytes Completed Work = 55001 bytes Current Table 2: Description = "NEWTON "."RDST_V10_015B" Total Work = 450200 bytes Completed Work = 54220 bytes Current Table 3: Description = "NEWTON "."RDST_V10_015C" Total Work = 978901 bytes Completed Work = 46000 bytes
1.5 示例场景
在线图书销售商 “XYZ” 有一个三分区的 DPF 集群（为简化问题，假设这三个分区分别使用分区号 11、19 和 51），用于存储客户交易（在表空间 CUSTOMER 中）、内部 HR 信息和很多其他数据的后端 DB2 数据库。他们注意到，有一个分区在性能上不如另外两个分区，因为它是一个较旧的、不够强大的机器。
成功地完成了一项生意后，IT 部门购买了两台新机器。系统管理员或 DBA 被要求将这两台机器（假设分区号分别为 171 和 999）编入集群中，并撤掉那台旧机器（假设分区号为 19）。
由于数据库的某一部分是 24x7 地被使用的，因此对系统中每个数据库分区组和每个表的变更必须逐步进行，因为维护窗口非常小，而系统又需要立即上线运行。另外还需要收集统计信息，重新构建所有无效的索引。
首先，必需使用 add dbpartitionnums 和 modify the db2nodes.cfg 添加两个新的分区，将这两个新分区包括进来。这样，实例级的工作就完成了。
下一步是决定重分发的表的优先级。显然，在这种情况下，与在线图书销售有关的任何表都是优先的。假设数据库分区组 SALES 包含与图书销售事务有关的所有表，且表 TRANS（包含客户信用卡交易）比表 CATALOG（包含更多静态的目录信息）和其他相关的表优先级更高。
首先发出以下命令： redistribute database partition group SALES uniform add dbpartitionnums (171,999)
drop dbpartitionnums (19) table (TRANS) first stop at xxxx compact on
statistics use profile indexing mode rebuild
接着，为表空间 CUSTOMER 执行一个表空间级备份，以便能够重新获得对 TRANS 和 CATALOG 表的完全访问权。
几周过去了。在接下来的一个维护窗口中，您决定只重分发 CATALOG 表，因为还有其他具有更高优先级的项目要做。您很可能会执行像下面这样的命令： redistribute database partition group SALES CONTINUE table (CATALOG) ONLY compact on statistics use profile indexing mode rebuild
您需要为表空间 CUSTOMER 执行一个表空间级备份，以便能够重新获得 TRANS 和 CATALOG 表的完全访问权。
您想重分发剩下的表，但是时间有限，因此使用 STOP AT 选项: redistribute database partition group SALES CONTINUE stop at xxxcompact on statistics use profile indexing mode rebuild
继续使用以上的 redistribute continue 命令和 STOP AT 选项，直到重分发完所有的表。如果有更多的表要重分发，但是由于 STOP AT 时间限制重分发被停止，那么该命令返回 sqlcode +1379。
下面是 sqlcode +1379 的一个例子：
SQL1379W Database partition group "RDST_V10_017" has been partially
redistributed. The number of tables redistributed is "1", and the
number of tables yet to be redistributed is "2". Reason code = "2".
如果所有表最终都被重分发，那么最后一次带 STOP AT 选项的 redistribute continue 命令将返回：
DB20000I The REDISTRIBUTE DATABASE PARTITON GROUP command completed. successfully.
每当 redistribute 命令完成时，记住在被重分发的表所在的表空间上执行一个表空间级备份。否则，该表空间仍然处于 backup pending 状态。
当所有表和数据库分区组都从驻留在旧机器上的分区中转移出来之后，可以使用 drop dbpartitionnums 从实例中完全删除分区。
注意：记住也要重分发 IBMDEFAULTGROUP 数据库分区组。IBMDEFAULTGROUP 是在数据库创建时自动创建的。
