CALL ADMIN.COPYSCHEMA('SRIELAU', 'IN "DATA" INDEX IN "INDEX" LONG IN "LONG"', 'STOLZE')
这个过程调用将模式 "STOLZE" 中的所有对象复制到模式 "SRIELAU" 中，对于表数据使用表空间 "DATA"，对于索引使用 "INDEX"，对于 LOB 数据使用 "LONG"。
CALL ADMIN.REBINDPROCEDURES('SRIELAU'')
这个过程调用对模式 SRIELAU 中的所有 SQL 过程进行重新绑定，获取新的统计数据。
实现
本节在较高的层面上概述本文前面讨论的过程的实现。
成功地恢复一个模式中的所有对象的主要困难是，处理模式中不同对象之间的依赖性。例如，表可能依赖于用户定义的不同类型；检查约束依赖于函数；视图依赖于视图、别名和函数；等等。
因为 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。
Web: http://www.qqread.com/sys-soft/v349557.html
更多内容请看系统备份专题、DB2、DB2中的数据处理专题，或进入讨论组讨论。
