分类：
2008-04-12 09:55:51
| 来源：IBM developerWorks 中国网站 |
|
实现：
本节在较高的层面上概述本文前面讨论的过程的实现。
成功地恢复一个模式中的所有对象的主要困难是，处理模式中不同对象之间的依赖性。例如，表可能依赖于用户定义的不同类型；检查约束依赖于函数；视图依赖于视图、别名和函数；等等。
因为 DB2 UDB 不能创建依赖于不存在的实体的对象，所以正确的执行次序是非常重要的。但是，如果仔细考虑一下这个问题，就会发现依赖图的深度一般不大，而且某些对象是自然的端点。比如，用户定义的类型不能依赖于其他 DDL 对象，而且表（不包括约束）只依赖于不同的类型。意识到这一情况，就可以分三个阶段实现恢复：
恢复所有不同的类型，然后恢复所有表及其索引。
将数据复制到表中并获取统计数据。这样做是为了确保 SQL 过程的执行计划是正确的。
在一个循环中恢复所有其他对象。因此，如果任何给定对象的创建失败了，那么不必担心，只要能够继续遍历要恢复的对象的列表。只有当过程进行不下去时，才会返回错误。
利用这种基本的恢复算法，很容易实现一种简单的基础设施。
BACKUPSCHEMA 过程使用 DDLLOG 表记录 DDL 语句。第一行（编号为 0）包含源模式。后面是不同类型的 DDL 语句，然后是表的 DDL 语句。这个阶段的末尾由一个空行表示，空行后面是所有其他对象。
这个表包含一个 SUCCESS 列，RESTORESCHEMA 使用这一列记录一个对象是否成功创建了。
DDL 对象的组成完全基于文档记录的 SYSCAT 编目视图，只有一个例外。IDENTITY 列的高水位标志需要从 SYSIBM.SYSSEQUENCES.LASTASSIGNVAL 中获得，在 DB2 UDB V8 中没有提供这个值。
与文件系统的交互是通过 SYSPROC.ADMIN_CMD 过程实现的，这个过程支持导出，用于将 DDLLOG 表、用户数据和统计数据写到文件中。对于装载，要使用 SYSPROC.DB2LOAD。
用来恢复模式的强制性方式也用于删除模式。DROPSCHEMA 过程简单地不断尝试删除对象，直到这个过程进行不下去或者所有对象都被删除为止。
结束语
本文提供了一组强大的过程，可以执行模式级操作，比如对给定模式中的所有对象进行逻辑备份、恢复和复制。除了用这个库帮助 ISV 和最终用户之外，本文还演示了如何利用 DB2 UDB 中丰富的 SQL API 为用户提供更多功能。 |
