DB2 最佳实践: 数据生命周期管理最佳实践

核心提示：内容提要现在的数据库应用程序通常需要伸缩性、快速转入及转出数据——在尽量不影响应用程序访问数据的情况下，转入转出数据涉及添加新数据和移除（通常归档）历史数据，DB2 最佳实践: 数据生命周期管理最佳实践，今天的很多应用程序是 24X7 访问的，因此消除了以前提供的批处理窗口的数据更新，你可以确定

内容提要

现在的数据库应用程序通常需要伸缩性、快速转入及转出数据——在尽量不影响应用程序访问数据的情况下。转入转出数据涉及添加新数据和移除（通常归档）历史数据。今天的很多应用程序是 24X7 访问的，因此消除了以前提供的批处理窗口的数据更新。同样，很多应用程序需要在并行访问数据的情况下才能连续进行数据更新。

DB2数据库系统提供了多种工具来实现伸缩性和在最低限度影响数据访问的情况下，方便连续填充或转入转出数据。本文建议的最佳实践可用来设计并实施这些 DB2 工具，以达到这些目的。

介绍

本文描述了最佳 DB2 设计实践，简化 DB2 数据生命周期管理。生命周期管理是有效增加（即转入）新数据，并将主数据库中不再需要的数据进行归档（即转出）。 DB2 系统提供了下列功能，这些功能你可以组合使用，可以简化生命周期管理：

数据库分区

表分区

多维集群

UNION ALL 视图

除了这些 DB2 功能，IBM Optim Data Growth 解决方案还简化了数据归档生命周期的管理。

DB2数据库系统分区工具的一个最重要的好处是，可以部署和更改这些工具而不影响现有应用程序的代码。

本文是最佳实践文章家族的一员，你也能通过阅读其它最佳实践从中受益。

本文的目标读者是负责为 DB2 应用程序设计数据库的人员（如果要达到伸缩性和有效的数据生命周期管理，数据库人员同样会发现本文的价值）。本文认为你需要有一定的 DB2 数据库设计的经验。

这篇文章的内容是基于 DB2 版本 9.5 提供的工具。 DB2 数据库系统的后续版本可能会有所提高，这将对本文的最佳实践建议带来变化。

分区技术

什么是数据库分区？

数据库分区（之前称为 DPF）是通过使用哈希键值算法把数据分布在数据库中的各个逻辑节点上。数据库分区的目标是通过在计算机集群之间均匀的分布数据来最大化可扩展性。数据库分区通过减少 DB2 实用工具操作粒度来增强扩展性。它并行的在数据库上进行查询和更新操作。

下面的例子演示了如何指定数据库分区：

CREATE　TABLE　Test　
　(Account_Number　INTEGER,　
　Trade_date　DATE　)　
　DISTRIBUTE　BY(Account　Number)USING　HASHING　

注意：在 DB2 版本 9 中，PARTITION KEY 子句被重命名为 DISTRIBUTE BY 。

数据库分区是完全透明的，因此并不影响现有应用程序代码。同样，你可以使用 redistribution 实用工具来在线更改，而不会影响应用程序代码。

在设计你的数据库分区策略时，使用一个有较高基数性的分区键列，来确保数据在各个逻辑节点间均匀分布。一个有较高基数的列有大量唯一值（而非大部分值相同）。同样，唯一索引必须是分区键的超集。

对那些要进行连接的表，尝试使用相同的分区键。这增加了连接并置。

什么是表分区？

表分区（通常叫做范围分区）是在一个逻辑数据库分区中的一个或多个物理对象上，通过制定键值范围来分割数据。表分区的目的是组织数据以便于优化数据访问和数据转出。对于特定的应用程序，表分区也有助于转入数据，然而，多维集群（在下面“ Multi-Dimensional Clustering ”章节讨论）往往是增强转入的更好选择。数据库分区是减少实用工具操作粒度以及超大型数据库的可扩展性的最佳实践。

表分区的好处是：

通过消除不恰当分区来提高查询性能。优化器可以把 SQL 查询，限制到仅在和 WHERE 子句相关的分区里。

优化表分区的转入和转出处理。表分区可以很容易的添加或删除表的分区，而不发生数据移动。应用程序可以在添加分区时，对原来的数据执行读写操作 ( 查询被安排在一段很短的时间内 ) 。

以前提供的维护方法压缩率会随着时间推移发生变化。由于每个表分区都有它自己的压缩字典。因此，以前分区上的压缩数据并不会随新数据的插入而发生改变。

优化对超大型表的管理。表分区可以拥有几乎无限的大小，因为限制只存在于各个分区中（而不是整个表）。你可以把范围数据存放到多个表空间中，以便于备份和恢复数据。

使 SMS 表空间的索引有更大的灵活性。你可以将索引存储到不同的 SMS 大型表空间中（仅支持分区表）。所有表都可以把索单独存放到 DMS 表空间中。

下面例子演示了指定表分区：

CREATE　TABLE　Test　
　(Account_Number　INTEGER,　
　Trade_date　DATE)　
　IN　ts1,　ts2,　ts3PARTITIONED　BY　RANGE(Trade_date)　
　(STARTING'1/1/2000'　
　　ENDING'3/31/2000',STARTING'4/1/2000'　
　　ENDING'6/30/2000',STARTING'7/1/2000'　
　　ENDING'9/30/2000)　

在你的 DB2 文档中有很多其他技术可以用来指定表如何进行分区。

多维集群

多维集群（MDC）是一个 DB2 数据库系统具有的独特能力。 MDC 在表中通过多维键值（单元）来组织数据。 MDC 的目的就是通过多个维度方便的存取数据，以保持数据访问只选择那些相关的单元。 MDC 通过维度确保数据随时处于集群状态，从而避免了重组数据的需求（数据永远不会变得无序）。

MDC也利用在每个维度上的块索引（并结合维度）对比行 ID（RID）索引。这样做的结果就是极大的减少了索引大小和索引级别。例如，如果在一个 DB2 单元中能装入 100 行，块索引将只指向单元而不是这 100 行数据的每一条。这样减少了读取和更新数据的 I/O( 索引值在块满了的时候进行更新 ) 。

MDC使转入和转出数据变得很方便，而且是对应用程序完全透明的。

下面的例子演示了如何指定多维集群：

CREATE　TABLE　order　
　(Account_Number　INTEGER,　
　Trade_Date　DATE,　
　Region　CHAR(10,　
　order_month　INTEGER　generated　always　as　month(order_dt))　
　IN　ts1　
　ORGANIZED　BY　DIMENSIONS　(region,　order_month)　

在设计你的 MDC 策略时，指定有较低基数的列，以避免稀疏填充单元。稀疏填充的单元会显著的增加磁盘空间的使用量。一个有较低基数的列，会有很多相同的值（而不是很多唯一值）。你也可以使用一个生成列来产生一个高度集群的维度。例如，一个生成列或内部函数可以把日期转换成月份。这样就显著的减少了基数（对于一年的数据，基数从 365 减少到了 12）。

MDC 功能有助于转入和转出数据

MDC 保证了在所有维度上的集群维护避免了重组数据的需求。这在转入过程中极大的减少了 I/O（而使用连续的大块 I/O）。同样，由于 MDC 维度上的索引是块索引，这也使得 MDC 在转入过程中避免了过多的索引 I/O 。块索引比普通基于 RID 的索引要更小也更浅，这是因为索引条目指向的是一个数据块而非一行。

同样，在转入过程中，MDC 减少了索引维护，因为块索引只在块满了的时候更新一次（不是像其他索引那样每插入一行就更新一次）。这也有助于减少 I/O 。

INSERT语句在你使用 MDC 时运行的更快，因为 MDC 从用现有空的数据块不需要进行分页。插入锁定同样得到了减少，因为锁发生在块级别而不是行级别。

MDC提高了转出数据的效率，因为删除的是整个页面而不是每一条记录。在 MDC 删除过程中日志同样会减少（每个页面只会有几个字节）。

使用只有一列的 MDC 设计，以便于转入和转出数据，而不会增加磁盘使用量。

见“连续更新情况下转入和转出数据的最佳实践”章节中，一个假设从使用 MDC 转入数据中获益的应用程序。

在一个数据库设计中同时使用数据库分区、表分区和多维集群

开发大型应用程序方法的最佳实践是在一个数据库设计中同时实现数据库分区、表分区和 MDC 。数据库分区提供了可扩展性并且确保了在逻辑分区上均匀分布数据；表分区方便了查询分区删除和转出数据； MDC 提高了查询性能并使数据转入更加方便。

例如：

CREATE　TABLE　Test　
　(A　INT,　B　INT,　C　INT,　D　INT　…　)　
　IN　Tablespace　A,　Tablespace　B,　Tablespace　C　…　
　INDEX　IN　Tablespace　B　
　DISTRIBUTE　BY　HASH　(A)　
　PARTITION　BY　RANGE　(B)　(STARTING　FROM　(100)　ENDING　(300)　EVERY　(100))　
　ORGANIZE　BY　DIMENSIONS　(C,D)　

表分区不能完全解决在 DB2 版本 9.5 中的扩展问题。需要继续使用数据库分区来解决大型数据仓库的扩展问题。 DB2 数据库分区不共享架构是对你的应用程序提供线性扩展而没有软件瓶颈的最好方法。

支持生命周期管理的其他技术

大型表空间

使用大型表空间（在 DB2 版本 9 中默认使用）能更好的调节大型的表或索引。在 DB2 服务器上这也使每页能存更多的行。

对深度压缩的表（一页中有很多行）和表分区全局索引（预计会超过 4K 页 64G 容量）使用大型表空间。如果你不受这些问题的影响，就不要使用大型表空间。同样你可以通过把每个表分区的全局索引拆分到不同的表空间（强烈建议）来避免大型表空间的需求。

下面的图比较了可用空间在不同页面大小的情况下能存储的记录数目，包括普通表空间和大型表空间。

Page Size	REG TBSP Max Size RID – 4 Bytes	REG TBSP Max Records/Min Record Length	LARGE TBSP Max Size RID – 6 Bytes	LARGE TBSP Max Records/Min Record Length
4 KB	64 GB	251 / 14	2 TB	287 / 12
8 KB	128 GB	253 / 30	4 TB	580 / 12
16 KB	256 GB	254 / 62	8 TB	1165 / 12
32 KB	512 GB	253 / 127	16 TB	2335 / 12

注意：如果你把一个表空间改成大型表空间，在与所有表相关的索引重组完成之前，它不会立即生效。

SET INTEGRITY 操作

当附加了一个新的分区到表中，或者当你分离了一个表分区和物化查询表（MQT）时，就需要运行 SET INTEGRITY（注意，这些数据在新的分区中 SET INTEGRITY 处理完成之前是不可见的）。 SET INTEGRITY 可能是一个要运行很长时间的操作，它验证数据并维护全局索引。这个维护操作需要记录日志并可能产生大量的日志输入。

SET INTEGRITY的关键好处是，操作期间现有数据可以被读写访问。你可以把对大数据量运行 SET INTEGRITY 的影响通过使用 MDC 来减到最小，而且也可以最小化对全局索引和 MQTs 的使用。另外一个选择是你可以指定用户维护 MQT 来加速 SET INTEGRITY

“设计并实现你的表分区策略”这一章节有使用 SET INTEGRITY 的建议。

异步索引清除

异步索引清除（AIC）是 DB2 的一个新功能，它在表分区分离后释放索引空间（清除程序作为较低优先级的后台进程运行）。由于有 AIC 功能，分离表分区几乎是一瞬间的。分离操作不需要等待索引清除完成。 AIC 是一个后台进程，它是 DB2 数据库系统自动调用的。

设计并实现你的表分区策略

从表分区获益的应用程序使用了下列类型的表：

超大型表

有查询访问表的范围子集的表

有转出需求的表

有转入需求的表。另外可以考虑使用 MDC 来转入数据。

设计最佳实践：

表分区设计，你需要考虑的内容包括：

在日期上的分区列（以方便转出）

协助分区删除的分区列，这会在后面讨论

匹配转入和转出标准粒度。这避免了在你运行 DETACH 时需要重组来释放空间。

考虑把不同的范围分别存放到单独的表空间中以便于备份和恢复。 DB2 数据库系统可以备份和恢复整个范围分区——如果他们存放在单独的表空间中的话。

考虑把活动数据和历史数据分开。

为了在以后的 DB2 数据库系统版本进一步提高，可以考虑对表分区键建立唯一索引。非唯一索引可以建在任何其他列上。

把你的全局索引指定存放在它们各自的表空间中（如有需要，就使用大型表空间）。为了缩短备份时间，这是最小化存放全局索引所需表空间的最佳实践。同样的，使用数据库分区来减少全局索引的粒度。

把全局索引拆分到多个表空间中，以确保一个单独的表空间不会变得过大。

考虑最小化 SET INTEGRITY 的策略。考虑日志的影响以及当涉及较大范围时的 SET INTEGRITY 花费的时间。如果失败了 SET INTEGRITY 也会影响重启时间。在环境中建立原型以查看花费的时间是否可以接受。另外，考虑其他设计策略，这在“转入数据：用什么方法”和“转入压缩表分区的最佳实践”中进行了讨论。

DB2 版本 9.5 强力建议进行深度压缩，因为它可以在 LOAD、IMPORT 或 INSERT 操作时自动建立压缩字典。如果没有压缩字典的话，DB2 版本 9.1 需要进行表重组来压缩一个表分区中的数据。

从分区删除中获得最大的好处：

表分区提供了一个强大的功能，以限制到分区的数据访问必须满足 SQL WHERE 子句。为了从分区删除中获益，需做好以下工作：

把集群键和分区键放在前面

确保范围分区列在 WHERE 子句中经常使用

确保组合分区键的引导列在 WHERE 子句中

如果你在使用生成列，那么，正确的使用它们可以协助分区删除。

把生成列用作 MDC 的维度，这能适当减少维度的基数。

如果有可能使用多个不同的范围来消除不必要的搜索。例如，分区删除可以只访问 1 月和 12 月，而不是全年。

如果你使用了连接，那么分区删除就仅仅被用做嵌套循环的内部访问。

分区删除参数标记被推送到运行时，然后值在运行时被绑定。

操作方面的考虑

使用下列最佳实践来增强表分区的操作性特征：

在每次转入或转出操作后，运行一个 COMMIT 语句来释放锁（例如，在 ATTACH、DETACH、SET INTEGRITY，等等）。

为每个表分区取一个明确的名字。这些名字管理起来比系统生成的名字要容易得多。

一定要终止一个运行失败的 LOAD 。在 LOAD 被终止之前，不能执行后续操作（例如，DROP TABLE）。

如果你正在附加数据到一个分区中，指定 LOAD INSERT 。在一个分区上执行 LOAD REPLACE 将会覆盖整个表（所有分区）。

避免附加一个与被分离的分区有相同名字的分区。在异步索引清除（AIC）完成之前，这会导致重名。

转入数据：用什么方法？

有很多因素会影响你在安装中如何选择最佳转入的解决方案：

尽量减少新数据转入系统并减少使它可用的时间

最小化在转入过程中作为 SET INTEGRITY 操作一部分日志活动总量。

你是否需要连续更新而不是每天进行批量操作。

最大限度的压缩新的范围，以有效的管理数据倾斜。

下面是两个把数据以分区形式转入的不同技术：

1.ALTER/ATTACH

你使用 ALTER/ATTACH 方法首先离线填充表，然后附加这个分区。你必须运行 SET INTEGRITY（对于大数据量来说，这个操作可能会运行很长时间）。

优点：

并发访问：

所有之前的分区都可以进行更新

没有部分数据视图（在 SET INTEGRITY 完成之前，新数据不可见）

缺点：

需要额外的日志空间

花费较长时间

肯定会流失查询

2.ALTER/Add

使用 ALTER/Add 方法，你可以附加一个空的表分区，然后使用 LOAD 实用工具或 INSERT 语句来填充它。

你不需要运行 SET INTEGRITY

优点：

花费更少的时间

不再需要一致性检查

全局索引维护需要更少的空间

缺点：

当你使用 INSERT 语句（而不是 LOAD 实用工具）插入的时候会发生部分数据视图

LOAD 实用工具允许对原来分区进行只读访问

建议：

对于更大的数据量，利用 ALTER/Add 方法来转入一个表分区或利用 MDC 来转入。

转入压缩表分区的最佳实践

这些最佳实践使用 ALTER/Attach 附加一个表分区，这在前面的章节中已经介绍过了。

在版本 9.1 上，快速附加一个有压缩数据的表分区的技术是：

装载数据子集（一个真正的随机抽样）到另外一个 DB2 表

更改独立的表启用压缩

重组数据子集以建立一个压缩字典

清空表或保留最少数据（因此字典得到了保留）

ALTER/ATTACH表作为一个新的表分区（保留字典）

执行 SET INTEGRITY（因为数据很少，所以这很快）

使用 LOAD 实用工具或 INSERT 语句（会发生压缩）。对于有连续更新、装载数据到中间过渡表的应用程序，使用 LOAD 实用工具。然后用一个有对中间过渡表的查询的插入或者运行一个 ETL（抽取，转换和装载）任务来更新主表（会发生压缩）。如果你在表分区中利用 MDC 的优势转入数据性能可以得到进一步提高。

对版本 9.5，自动创建压缩字典简化了这个快速附加一个表分区的技术。

ALTER/Add空表

通过使用 LOAD 实用工具或一个 INSERT/SELECT 语句，用数据填充这个表（数据被自动创建的压缩字典压缩）

注意，在一个完全装载的分区上进行离线重组，可以得到比只有这个月归档的分区更好的压缩。

连续更新情况下转入和转出数据的最佳实践

这个数据库设计包含了多个 DB2 数据库系统功能，以方便在连续更新的请求下的数据转入和转出。

这些应用程序的设计有以下特点：

全天的连续更新（这妨碍了执行 ALTER/Add 来添加一个分区）

数据是按天增加的

查询经常访问某天

基于 day 的表分区会产生过多的分区（例如，有 3 年，每年 365 天）

每周或者每月进行转出（通常在一个报告边界）

关于数据库设计的建议：

为了方便转入数据，指定只有一个在 day 上的维度的 MDC（见“ MDC 功能有助于转入和转出数据”部分）

为了方便转出数据，对每周或每个月指定一个表分区范围。对 MDC 提供相同的时间维度不过是更粗的粒度。

有很长运行报告的程序对 DB2 LOAD 实用工具通常不能排除查询。在这种情况下的最佳实践是使用 LOAD 实用工具来快速装载数据到中间过渡表，然后使用一个有子查询的插入来填充主表。

在转出以后：如何管理数据增长和数据保持？

为了符合公司政策、管理章程、或审计需求，你可能需要保留你的数据并保持它们在很长时间内可用。例如，Health Insurance Portability and Accountability Act (HIPAA) 法案，要求健康护理组织保留至少 5 年的原始医疗记录。另外，一些企业也发现了对历史数据进行分析的价值，并因此保留更长时期的数据。

因此，为了实施一个恰当的转入转入策略和适当的数据库设计，你需要考虑数据的寿命，包括数据保留和获取政策。出于保留数据的目的，你可以什么都不做并不停的增加硬件能力和资源，来保持这些附加的数据增长，然而本文介绍的是数据保留的最佳实践。

使用 UNION All 视图

一个实践就是在数据库中保留所有数据，把某些范围转出作为数据保留，并对这些范围创建 UNION ALL 视图以便于访问。

下面的例子演示了如何创建一个 UNION ALL 视图：

CREATE　VIEW　all_sales　AS　
　(　
　SELECT　*　FROM　sales_0105　
　WHERE　sales_date　BETWEEN　'01-01-2005'　AND　'01-31-2005'　
　UNION　ALL　
　SELECT　*　FROM　sales_0205　
　WHERE　sales_date　BETWEEN　'02-01-2005'　AND　'02-28-2005'　
　UNION　ALL　
　...　
　UNION　ALL　
　SELECT　*　FROM　sales_1207　
　WHERE　sales_date　BETWEEN　'12-01-2007'　AND　'12-31-2007'　
　);　

在数据库使用主存储把所有数据保持在线时，使用 UNION ALL 视图定位数据保留和实时访问。这个方法带来的一个问题是你可能不需要再维护和备份镜像相关的数据。同样，历史数据一般不需要高性能，所以不需要进行索引或使用在你主数据上的高成本的因素。

有很多使用 UNION ALL 视图的方法：

使用 UNION ALL 视图访问活动数据，并把你的历史数据保持在分区表中。

在范围分区中保持活动数据 , 使用 UNION ALL 视图来访问在其他范围分区中的历史数据。

对使用 UNION ALL 视图有一些限制。当你有很多范围时，最好使用范围分区表。这是因为某些复杂谓词不能用在 UNION ALL 视图上。

然而，在某些情况下 UNION ALL 视图又很有优势。例如，一个 UNION ALL 视图可以在联邦数据库中使用，相反，范围分区表不能。

使用 IBM Optim Data Growth

根据你的历史数据的服务级别协议（SLA），通常同时讨论数据增长和保存的最佳实践是用 IBM Optim Data Growth 实施数据归档。

IBM Optim Data Growth是在处理增长、遵守和管理上领先的解决方案。它通过归档已完成的业务对象，来保持应用程序的完整性，而非单个表。例如它在归档中保持外键并保留原数据。这些功能使你能够：

灵活的访问数据

可以有选择的或完整的恢复归档数据到原始数据库表或一个新表中，甚至恢复到另外一个数据库中。

完成下列步骤指南来判断如何最好的实施你的归档策略：

第1步：对你的应用程序进行分类

首先，你需要根据它们的归档需求来对你的应用程序进行分类。通过了解需要从你的应用程序数据中保留什么事务，你可以根据相似数据需求来对应用程序进行分组，来提高可访问性和性能。一些应用程序只需要保留当前事务；一些只需要访问历史事务；其他的需要混合访问现在的和历史的事务（以不同的比例）。

你也需要客观的对归档数据考虑服务层协议（SLA）。 SLA 是一个各个组织间著名的协议，它定义了它们之间的期望，包括客观的条目，比如服务、优先级和职责。 SLA 的目的通常被定义为使用响应时间的目标。例如，可能需要在五分钟内运行一个特定的人力资源报告。

第2步：评估你的数据温度

数据温度来自于：

数据访问有多频繁

花费多长时间

数据变化（挥发性）有多快

用户和应用程序需求

在不同的企业，数据温度也有所不同，不过通常来说，数据温度是根据产业间的区别进行的一般分类。下表提供了数据温度的指南：

数据温度	描述
Hot	策略数据 – 对当前数据查询的体积、频繁访问的和需要提升快速反应时间。
Warm	传统决策支持数据 – 查询对这类数据的访问不那么频繁而且数据获取也不需要紧急提升响应时间。
Cold	深度历史数据 – 查询很少访问这类数据不过它们必须可以周期性的访问。
Dormant	监控数据它们需要能够在某些例外情况下访问。

有很多方法可以访问数据温度，例如，使用你的转出策略和系统跟踪。你需要访问的温度信息：

什么对象有（或没有）被访问。

每个对象访问的平率

某个对象被访问的通常的时间间隔

例如 THIS_WEEK, LAST_WEEK, THIS_QUARTER, LAST_QUARTER 。

在一个对象中的那些数据被访问了。

你可以使用 DB2 版本 9.5 负载管理器（WLM）来帮助发现数据的温度。 WLM 历史分析工具提供了关于那些表、索引和列被访问了，那些没有以及有多频繁的信息。

WLM历史分析工具有两个脚本组成：

wlmhist.pl：产生历史数据

wlmhisrep.pl：从历史数据中产生报告

要发现对象中的那些数据被访问过，你需要分析 SQL 语句。要这么做，使用一个 ACTIVITIES 事件监视器来搜集运行的活动数据（包括 SQL 语句文本）。你可能想搜集关于工作负载管理对象比如工作负载、服务类型和工作类型（通过工作活动）。要启用活动搜集，在这些市哦那个 COLLECT ACTIVITY DATA WITH DETAILS 子句的对象上执行 CREATE 或 ALTER 语句，如下所示

ALTER　SERVICE　CLASS　sysdefaultsubclass　
　
　UNDER　sysdefaultuserclass　
　
　COLLECT　ACTIVITY　DATAON　ALLWITH　DETAILS　
　　　

WITH DETAILS选项启用对静态语句和动态 SQL 语句的语句文本搜集。

如果应用程序在语句文本中使用了参数标记，也应该包括 AND VALUES 选项，（指定 COLLECT ACTIVITY DATA WITH DETAILS 和 AND VALUES）。 AND VALUES 选项搜集和参数变量相关的数据值以获得详细语句信息。

第3步：发现并对你的业务对象进行分类

业务对象，比如一个保单、一个发票、或购物清单、代表了一个事务交易。通过指定你的业务对象，你可以开始定义规则和相关业务驱动以在数据生命周期的不同阶段管理这些对象。

从数据库透视图来看，一个业务对象表示了一组相关表中相关的行

业务对象的简单例子

给出了下面 3 个表：

业务对象是：

出于保持和归档的目的，你希望表现整个业务对象，比如你有一个事务交易的历史“时间点”快照。创建一个历史快照需要交易细节和相关主要数据，这包含数据库中的多个表。可以完整精确的对整个业务对象进行归档，并提供单独的交易历史存储库。为了响应质询或发现需求，你可以查询这个存储库而不需要访问 HOT 数据。

在这个例子中，为了确保所有对象可用，归档业务对象必须由来自 DEPARTMENT 和 EMPLOYEE 表中的相关数据组成。在归档后，你会只想删除生产 PROJECT 表中的数据以及和 EMPLOYEE、DEPARTEMENT 无关的数据。

就像在这个例子中展示的，你会发现基于模式间的关系的业务对象。 不过，你或许也想包含其它没有任何模式关系的相关表，却通过使用一个应用程序相关联。另外，你或许会选择删除从某个业务对象上某个发现的关系

第4步：生成你的综合数据分类：

在你对你的应用程序和业务对象完以成分类并对他们相关数据温度做出判断后，你可以生成一个数据分类表来总结这些信息。这张表可以明白的说明数据的年龄。

下表提供了一个分类样本：

第5步：判断后归档存储类型

为了判断什么存储类型岁适合你的老数据：

谁需要访问归档数据，处于什么目的？

期望的响应时间是多少？

什么数据年龄将被归档？

有多少层以及应该部署在什么存储类型上，例如，SAN、WORM 或磁带

例如，对于在线归档你可以使用 ATA 磁盘或更大容量的较慢驱动。对离线归档，你可以使用磁带或 WORM（IBM DR550，EMC Centera）。

第6步：访问归档数据

Optim Data Growth访问层使用 SQL92 容量和多种协议（如上图所示）以支持对归档数据的访问。这个访问能力和生产系统完全不同，而且不会使用任何生产系统资源

另外，你可以使用一个联邦系统（使用 IBM DB2 联邦服务器）从生产系统上来对归档数据提供透明访问。

这两种方法都允许对归档数据的直接访问，不需要取得或回复归档数据。

下面例子演示了如何使用 UNION ALL 视图来同时访问活动和归档数据。在例子中把数据库中叫做project表重命名为另外一个名字，然后创建一个也叫做project的 UNION ALL 视图。

RENAME　TABLE　project　TO　project_active　
　
　CREATE　VIEW　project　AS　
　SELECT　*　FROM　project_active　WHERE　prjendate　>=　(CURRENT_DATE　–　5　YEARS)　
　UNION　ALL　
　SELECT　*　FROM　project_arch　WHERE　prjendate　<　(CURRENT_DATE　–　5　YEARS)　

另外，下面例子避免了在数据库中重名表的需求。例子中创建了一个叫project_all的 UNION ALL 视图作为替代，应用程序可以从这里查询到完整的project数据集：

CREATE　VIEW　project_all　AS　
　SELECT　*　FROM　project　WHERE　prjendate　>=　(CURRENT_DATE　–　5　YEARS)　
　UNION　ALL　
　SELECT　*　FROM　project_arch　WHERE　prjendate　<　(CURRENT_DATE　–　5　YEARS)　

结论

通过仔细选择在你的 DB2 数据库中最适合分区方法，以及在你的系统上使用最有效的转入和转出技术，你可以最大化整体系统性能和效率。

投入足够的时间来分析和理解你的数据，这样你可以最好的利用本文中的指南，并获得 DB2 数据库提供功能的好处来使你的系统尽可能有效率。

你可以使用数据库分区来提供扩展性并确保数据在分区间均匀分布。下面指南在“设计并实现你的表分区策略”这一章中设计最有效的表分区策略。使用 MDC 来提高查询性能并使转入数据更容易。

如果你需要从压缩的额表分区中转入大量数据，升级到 DB2 版本 9.5 数据库系统并使用 ALTER/Add 方法来附加一个表分区。

如果你需要提供连续更新，你的最佳策略是使用 MDC 以方便转入处理。

紧接着在“在转出以后：如何管理数据增长和数据保持？”指南中确定了如何处理你的历史数据需求。

在你准备好转出你的数据并归档之前，你需要对数据保留和从归档中取回数据确定一个和你的组织匹配的数据策略。

你可以确定你组织对保留数据的需求，并通过下列因素取回：

你需要保留的事务类型

你的数据的“温度”

你的业务对象是怎么组成的

你的策略应该包含什么类型的后归档存储是最合适的，以及如何最好的访问归档数据。