DB2 for LinuxUNIX and Windows 中重复数据删除设备的完整支持

Posted 2021-04-30 ibm软件技术联盟

什么是重复数据删除及其工作原理是什么？

重复数据删除是一种减少粗粒度冗余数据的专业数据压缩技术。该技术用于提高存储利用率。在重复数据删除过程中，惟一数据块或字节模式在分析过程中被识别并进行存储。随着分析的继续，其他数据块与存储的副本进行比较，每当出现匹配时，冗余数据块就被一个指向存储数据块的小型引用所替代。由于相同字节模式可能会出现几十、几百、甚至几千次（匹配频率取决于数据块大小），所以必须存储或传送的数据量将大大减少。图 1 描述了这种概念。

图 1. 重复数据删除

例如，一个典型的电子邮件系统可能包含同一个 1 兆字节 (MB) 文件附件的 100 个实例。如果电子邮件平台进行了备份或归档，要将 100 个实例都保存，那么将需要 100 MB 的存储空间。通过进行重复数据删除，实际上只存储了一个附件实例。随后的每个实例只是重新引用到一个已保存的副本。在这个示例中，一个 100 MB 的存储需求可能会减少到只有 1 MB，外加一些有名无实的开销来作为重复数据的引用。

重复数据删除还有其他好处。较低的存储空间要求将节省磁盘支出费用。高效的磁盘空间利用支持更长的磁盘保留期限，这会长时间提供较好的恢复时间目标 (RTO) 并降低磁带备份需求。重复数据删除也减少了必须通过 WAN 发送以实现远程备份、复制和灾难恢复的数据。

重复数据删除通常可在文件或块数据上进行操作。文件删除消除了重复文件（如上述示例所示），但这并不是非常有效的删除方式。数据块删除看起来好像是在一个文件中并且保存了每个块的惟一迭代。每个数据块使用一个散列算法（MD5 或 SHA-1）进行处理。这个处理过程为每个数据片生成一个惟一数字，然后将这个数字存储到一个索引中。如果文件进行了更新，就只能保存更改的数据。也就是说，如果只更改文档或演示中的一些字节，则只能保存更改的数据块。这些更改没有构成一个全新文件。这种处理使数据块删除变得更加有效。但是，数据块删除需更强的处理能力，且需要使用更大的索引来跟踪单个数据片。

通常，使用下面两种方法之一来执行重复数据删除：在线 或后处理。通过在线删除，散列计算和查找在数据写入磁盘前执行。所以，在线删除大大降低了原始磁盘容量需求，因为尚未删除的数据不再写入磁盘。为此，在线删除常常被认为是最有效且最经济可用的重复数据删除方法。但是，因为执行散列计算和查找需要一些时间，所以在线删除会使一些操作变慢，但某些在线删除解决方案供应商已能实现与后处理删除相当的性能。

通过后处理删除，启动删除流程之前，所有数据将写入存储区。该方法的优点是在数据存储之前不需等待散列计算和查找的完成。缺点是最初需要大量的可用存储区，因为重复数据必须在短时间内写入存储区。该方法在完成重复数据删除前还会增加延迟时间。

传统的 DB2 备份操作如何工作

DB2 备份实用程序旨在实现最大性能。调用该实用程序时，会创建三组线程：

• DB2 代理 (db2agent) 线程

• 缓冲区操作者 (db2bm) 线程

• 媒体控制器 (db2med) 线程

db2agent 线程负责用户及其从属线程间的所有通信。db2bm 线程负责从指定表空间读取数据，并将数据放置在共享内存缓冲区。db2med 线程负责从共享内存缓冲区读取数据并将其写入目标设备。

BACKUP DATABASE 命令的 PARALLELISM 选项控制使用的 db2bm 线程数量。OPEN n SESSIONS 选项或目标设备的数量控制 db2med 线程的数量。该流程如图 2 所示。

图 2. DB2 的备份流程模型

因此，当输出流指向重复数据删除设备时，该设备会尽力识别已备份的数据块，因为每次备份数据库时，数据都以不同顺序到达。

图 3. 默认的数据库备份行为

注意：表空间的元数据将在其数据出现之前出现在输出流中，并且不会将空的区段放置在输出流上。

回页首

如何修改 DB2 以支持重复数据删除设备

将数据以一致且可预测的方式发送到重复数据删除设备时，这些设备运行状态最佳；也就是说，数据每次以相同顺序到达。如果以随机顺序接收数据，那么重复数据删除设备将在整个索引中进行搜索以寻求匹配，从而增加了设备需要执行的工作。正因为如此，所以要将一个新的选项 (DEDUP_DEVICE) 添加到备份实用程序中，以表明目标设备就是支持重复数据删除的设备。这个新选项将确保数据以一致且可预测的方式发送到目标设备。DEDUP_DEVICE 选项将更改媒体控制器处理数据的方式。单个表空间的数据实际上将按顺序仅发送到一个媒体控制器 (db2med) 线程上。

特定表空间的所有数据始终以由低到高的顺序进行写入表空间页面。每个输出流中可预测和确定性数据模式使重复数据删除设备更容易识别之前已经备份的数据块。图 4 演示了使用 BACKUP DATABASE 命令的 DEDUP_DEVICE 选项时备份行为中的变化情况。

图 4. 指定 DEDUP_DEVICE 选项时的默认数据库备份行为

最初的其中一名客户利用 DB2 备份上的 DEDUP_DEVICE 选项时具有以下经历。客户进行 4 TB 的备份时超过了 6 个半小时，而且重复数据删除结果很糟糕，仅为 2:1 或 3:1。通过利用备份调用上的 DEDUP_DEVICE 选项，备份运行时间降到 5 个半小时，并且重复数据删除结果在 11:1（节约 90%）和 15:1 （节约 93%）之间。注意：任何结果都依赖于数据的波动性。数据更改得越少，重复数据删除率就越高。

回页首

DB2 增量备份如何与重复数据删除备份进行比较？

DB2 增量备份将读取表空间上的所有页面，并且只将更改页面发送到备份映像。因缺乏固定的页面格式，整个 LOB 和出现在表空间中的 Long Field 数据将作为一个整体添加到备份映像上。正因为如此，DB2 增量备份产生一个与重复的数据备份映像大小非常相似的备份对象。实际上，只有新网页才消耗空间。

增量备份上重复数据备份的其中一个优点是处理 LOB 的方式。如前所述，增量备份往往包括整个 LOB。重复数据备份的缺点是其通过 LAN/SAN 将整个表空间的内容发送到重复数据删除设备上，从而消耗大量带宽，而 DB2 增量备份并不消耗带宽。

回页首

压缩与重复数据删除设备兼容吗？

探讨几种可用于 DB2 DBA 的压缩形式：

• 行压缩（也称作表压缩）

• 自适应压缩（也称作页面压缩）

• DB2 备份压缩

• Tivoli Storage Manager (TSM) 客户端压缩

以前的经验法则是任何形式的压缩与重复数据删除不兼容。测试已表明这种假设是错误的，而且存在压缩和重复数据删除完全兼容的情况。需要确定的关键因素是：如果数据保持不变，那么在进行压缩时，数据的物理二进制表示法会在备份之间发生变化吗？

对于上述列表中的前两项（行压缩和自适应压缩），答案是不会发生变化。一旦在磁盘上压缩数据，那么数据的二进制格式将不会在备份间发生改变，但已修改的数据除外。这被称为静态压缩。只要数据不发生改变，那么表示方法依然相同。这种压缩类型兼容重复数据删除，因为重复数据删除设备可以轻松检测到这种模式。

列表上的另外两个压缩形式（db2 备份和 TSM 压缩）被称为动态压缩。每当备份数据库时，数据的二进制表示法可能会根据数据流中数据发生故障的位置进行改变。这两种压缩技术使用 “滑动窗口” 检测模式。如果备份间的窗口对齐不相同，那么该模式检测将产生一个不同的压缩输出结果，从而降低重复数据删除设备找到模式匹配的可能性。

回页首

性能建议

DB2 备份用于最佳执行重复数据删除设备的调优参数与用于备份非重复数据删除设备的参数稍有不同。具体地说，因为有较大的缓冲区大小（例如 8192 或 16384），以及更多目标会话，所以重复数据删除性能更好。还需要额外的目标会话，因为 DB2 备份将不再通过目标设备多路复用数据，而是以一个表空间中每个数据的目标设备为目标。

DB2 备份的默认行为是通过优化提高吞吐量，所以将从所有会话的表空间上将数据多路复用到 TSM。结果可能是在重复数据删除设备上生成一个糟糕的分解比率。要应对这种后果，应使用最大的缓冲区大小（即 16384），以及更多目标会话。还需要额外的目标会话，因为 DB2 备份将不再通过目标设备多路复用数据，而是以一个表空间中每个数据的目标设备为目标。要获得最佳的重复数据删除比率，应减少会话和并行数量，但其代价是完成 DB2 备份将需要更长的运行时间。

一些基本的经验法则如下：

• 更改 logarchmeth1 以确保归档日志不再存储在重复数据删除设备上。

• 至少将 util_heap_sz 增加到 200000。

• 更改缓冲区大小（缓冲区）为 16384。

这里是一个 DB2 备份调用示例：

db2 backup db databasename use tsm open 10 sessions buffer 16384

注意: 上述操作需要 1.3 GB 的内存。如果内存太大的话，使用缓冲区 8192 替代缓冲区 16384。

回页首

Tivoli Storage Manager 原生重复数据删除功能

TSM 提供两种选择实现重复数据删除：客户端删除和服务器端删除。两种方法都使用同样的算法识别冗余数据，但是删除处理的时间 和地点 各不相同。

TSM 服务器端删除

使用服务器端删除技术，在将数据备份后，冗余数据的所有处理都在 TSM 服务器端进行。服务器端删除也称为 “目标端” 删除。服务器端删除的关键特征有：

• 在将备份数据传输到存储池卷之后识别重复数据。

• 重复数据识别处理必须在服务器端定期运行，并将消耗 TSM 服务器 CPU 和 TSM 数据库资源。

• 在将数据从删除存储池转移到另一个存储池卷之后，才能实现存储池数据缩减，这通常通过一个回收过程来完成，但是也可能出现在 TSM “MOVE DATA” 过程中。

TSM 客户端删除

在存储元数据的主机系统上，客户端删除在备份过程中处理冗余数据。除了存储空间节省即刻实现外，重复数据删除的最终结果实际上与服务器端删除一样，因为整体上看，只将非重复数据发送到服务器。复制数据只需要一个小小的签名就可以发送到 TSM 服务器。当节约 TSM 客户端和服务器之间的带宽非常重要时，客户端删除就特别有效。

TSM 删除

Tivoli Storage Manager 管理员可以指定要使用的重复数据删除位置（客户端还是服务器），通过在 REGISTER NODE 或 UPDATE NODE 服务器命令中使用 DEDUP 参数来实现这一点。

IBM Tivoli Storage Manager 服务器端和客户端重复数据删除支持共享源设备以及目标设备生成的数据区段，反之亦然。重复数据删除方法通过允许用户在客户端（源）和服务器（目标）之间切换删除位置来处理上述列表中的问题。删除位置可在节点上选择。例如，节点 A 客户可执行客户端重复数据删除，而节点 B 可执行服务器端重复数据删除。重复数据删除也可以在文件上进行。无论是哪种情况，区段都可以在两个节点以及不同文件间重用。请注意，如果使用的是免费的 LAN 配置，则不支持 TSM 客户端重复数据删除。

在哪里启用 TSM 重复数据删除

当确定对 TSM 服务器进行删除处理这种架构后，需要确定在 TSM 客户端还是 TSM 服务器端进行删除，或者两者兼而有之。TSM 删除实现支持存储池管理客户端和 TSM 服务端执行的删除。优化服务器来只对 TSM 客户端没有删除的数据执行删除。此外，无论是在客户端还是服务器端执行删除，重复数据都遍布所有对象。

这些优势支持混合配置，将客户端删除高效应用到一部分子客户端，并对其余客户端使用服务器端删除。通常，结合使用客户端和服务器端重复数据删除是最适合的方式。还有几点需要进一步考虑：

• 服务器端删除是一个两步过程，先是识别重复数据，接着是回收删除的重复数据。客户端删除直接以删除格式存储数据，这就减少了额外的回收处理需求。

• 客户端删除可以结合压缩技术提供最大可能的存储空间节省。

• 客户端删除处理可以增加备份持续时间。如果网络带宽不受限制，我们当然希望增加备份持续时间。当在不受网络约束的环境中使用客户端备份时，备份持续时间加倍是一个较为合理的估计。此外，如果使用存储池备份（其中副本存储池不使用删除）创建一个辅助副本，那么数据传输将需要很长的时间，因为重构重复数据需要额外的处理。

• 客户端删除可以将重要负载放置在 TSM 服务器上，在这种情况下，大量客户端同时进行删除处理。负载是 TSM 服务器处理客户端重复块查询的结果。另一方面，服务器端删除通常有数量相对较小的识别流程以一种受控的方式运行。

• 使用 SAN 特性的 Tivoli Storage Manager 时，客户端删除不能与免费 LAN 数据移动结合使用。如果实现了一个 TSM 支持的免费 LAN 磁盘解决方案，那么仍然可以考虑使用服务器端删除。

有关优化 TSM 实现重复数据删除的更多信息，请参阅 developerWorks 社区 Tivoli Storage Manager 维基中的 删除主题。

利用 TSM 6.2 Server 重复数据删除的性能结果

以下几组测试在一个 DB2 V10.1 数据库上执行的，该数据库有 16 个表空间。每个备份都是一个全数据库离线备份，且在交互过程中没有更改用户数据。这些测试的目的是看看 TSM 服务器重复数据删除特性的效果究竟怎样。

测试 #1

设置：
Util_heap_sz=300000
网络：1 GB Ethernet

表 1. 命令：DB2 backup db PERF use TSM open 8 sessions dedup_device with 18 buffers buffer 16384 parallelism 8

开始	结束	运行时间 (HH:MM:SS)	实际数据库大小（单位：字节）	TSM 服务器上存储的数据量	节省的空间百分比
1:17:08 PM	1:45:16 PM	0:28:08	136499490816	136499490816	0%
1:45:16 PM	2:11:42 PM	0:26:26	136499490816	136499490816	0%
2:11:42 PM	2:38:51 PM	0:27:09	136499490816	136499490816	0%
2:38:51 PM	3:05:51 PM	0:27:00	136499490816	136499490816	0%
3:05:51 PM	3:32:58 PM	0:27:07	136499490816	136499490816	0%

在 TSM 服务器上运行 IDENTIFY DUPLICATES 和 RECLAIM STGPOOL 之后，将删除重复数据。确定实际使用存储的查询如下：

select sum(reporting_mb) as "Before dedup (MB)", sum(logical_mb) as "After dedup (MB)",
 (sum(reporting_mb) - sum(logical_mb)) 
  as "Dedup savings (MB)" from tsmdb1.occupancy where STGPOOL_NAME='DEDUPPOOL'

表 2. 重复数据删除节省的空间

删除前 (MB)	删除后 (MB)	删除节省的空间 (MB)
650978.52	130532.88	520445.64

总节省空间 80%