动机

　　SQL 语言提供了模式的概念，用来对所有类型的 SQL 对象进行分组。可以将 SQL 语言中的模式 理解成文件系统中的目录。DB2 UDB for Linux, UNIX, and Windows 很好地支持 SQL 模式概念，可以将 USER 与 CURRENT SCHEMA 隔离开，并为例程解析提供了 PATH。

　　使用模式很轻易，但是它们的治理就不同了。模式的重命名、模式级备份和恢复以及模式的复制等任务比较困难，因为必须手工进行脚本编程，而且对象及其依靠性可能很复杂。

　　本文提供一个具有简单接口的过程库，使用户能够将给定模式中的所有对象备份到文件系统中、在另一个模式下恢复备份以及删除给定模式中的所有对象。

　　安装

　　下载并解压缩本文包含的 backupschema.zip 文件之后，会得到以下文件：

　　backupschema.sql

　　这个文件包含一些 DDL 语句，这些语句安装过程以及各个 helper 例程和表。在默认情况下，所有对象使用的模式是 "ADMIN"。假如要改变这个模式，只需修改这个文件开头的 SET SCHEMA 和 SET PATH 语句，将 "ADMIN" 替换为您选择的模式名。

　　为了执行这个脚本，作为 DB2 治理员连接到数据库，然后执行 db2 -tvf backupschema.sql。

　　这些过程使用 SYSPROC.ADMIN_CMD() 存储过程进行导出并使用 SYSPROC.DB2LOAD() 存储过程进行装载。（SYSPROC.ADMIN_CMD() 是在 DB2 V8.2.2（FP 9）中引入的。因此，需要的最低版本是 V8.2.2。）SYSPROC.ADMIN_CMD() 在 sqllibadm.fenced 的所有者指定的 fenced 用户 id 和组 之下执行。因此，导出的文件具有与 sqllibadm.fenced 相同的所有者和组。因此一定要确保这个用户和组对指定的目录有写特权，而且用来访问文件的用户 id 也有访问权。简单的解决方案是将 sqllibadm.fenced 的所有者改为实例所有者。更安全的解决方案是让这两个 ID 成为同一个组的成员，然后只将 sqllibadm.fenced 的组所属权改为这个组。这样就能够通过组成员关系访问产生的文件。

　　规范

　　DROPSCHEMA()

　　这个过程将删除模式中定义的所有对象，并最终删除这个模式本身。

　　参数

　　要删除的模式的名称。SQL 标识符是大小写敏感的。要删除模式 "MYSCHEMA"，模式名必须是大写的：'MYSCHEMA'。

　　假如另一个模式中的对象依靠于要删除的模式，那么应用删除对象的常规规则。因此，在大多数情况下，依靠对象也会被删除或失效。但是，一些对象（比如 SQL 函数）实施 RESTRICT 语义。假如碰到这种情况，那么这个过程将失败。

　　DROPSCHEMA 过程在事务控制下执行，它自己不执行提交或回退。所以，要想让模式的删除持久化，必须提交删除操作。同样，假如发生错误，那么过程的调用者需要决定是否将过程回退。

　　BACKUPSCHEMA(,)

　　这个过程将模式中的所有对象逻辑备份到文件系统中。支持的对象是：

　　表，包括统计数据。不支持范围簇表（RCT）、物化查询表（MQT）和有类型的表。

　　视图，但是不包括有类型的视图。

　　函数，包括源、SQL 和外部函数。注重，对外部函数的可执行代码不进行备份。函数的统计数据也不备份。

　　SQL 过程和外部过程。注重，对外部过程的可执行代码不进行备份。

　　不同的数据类型。注重，不支持结构化数据类型。

　　索引，但是不包括索引扩展。

　　所有约束。

　　序列，包括它们的高水位标志。

　　支持的所有对象上的注释。

　　支持的所有对象上的特权。

　　这个备份过程可以包括 PATH、SCHEMA 和 PREP 选项。

　　不支持联邦对象（比如 NICKNAME）以及数据库分区特性（DPF）。

　　参数

　　要备份的模式的大小写敏感名。

　　对象要备份到的文件系统目录。这个目录必须存在，在 UNIX 或 Linux 上以斜线结尾，在 Windows 上以反斜线结尾；例如 'D:TEMPMYSCHEMA'。假如这个目录是 NULL 或空字符串，那么不导出文件。这个过程只用 DDL 语句填充 DDLLOG 表。COPYSCHEMA 过程要使用这个方式。

　　在成功地备份之后，这个目录包含以下对象的 IXF 文件：

　　备份的模式中的表。

　　SYSSTAT 视图，包含表、列和索引统计数据。

　　DDL 日志，包含重建所有对象所需的信息。

　　用户可以在这个目录中添加其他文件，比如外部例程的可执行代码。完成之后，可以根据需要用 zip 和 tar 对这个目录进行压缩、打包或传输。

　　RESTORESCHEMA(,,,)

　　这个过程恢复以前用 BACKUPSCHEMA 备份的模式。使用当前用户的 ID 创建所有对象。假如恢复的任何对象引用另一个模式中的对象，而被引用的对象在目标数据库中不存在，那么这个过程将失败。这个过程执行内部提交。

　　假如恢复到与 BACKUPSCHEMA 不同的模式中，那么所有包含 SQL 体（比如视图、SQL 例程和检查约束）的 SQL 对象在它们的定义中必须没有显式地引用源模式。例如，CHECK (MYSCHEMA.MYTABLE.C1 > 0) 无法成功地恢复到 "MYSCHEMA" 之外的模式中，而 CHECK (MYTABLE.C1 > 0) 可以。为了能够在 RESTORESCHEMA 中指定其他模式，建议在定义 SQL 对象时利用非凡寄存器 CURRENT PATH 和 CURRENT SCHEMA，而不是显式地指定局部模式。

　　参数

　　要将对象恢复到的模式的大小写敏感名。假如这个模式已经存在，那么先删除它。假如模式是 NULL 或空字符串，那么这个过程采用备份时的模式名进行恢复。COPYSCHEMA 过程采用这种方式。

　　包含要添加到每个表定义中的表空间信息的字符串。这个子句可能包含 IN 、LONG IN 和 INDEX IN 子句。假如应该使用默认值，那么这个参数可以是空字符串或 NULL。　　例如：'IN DATA8K INDEX IN INDEX4K'

　　文件系统中存放 BACKUPSCHEMA 生成的文件的目录。这个目录在 UNIX 或 Linux 上必须以斜线结尾，在 Windows 上必须以反斜线结尾；例如 'D:TEMPMYSCHEMA'。 文件系统中的一个目录，这个过程将把装载消息文件写到这个目录中。这个目录必须根据操作系统以适当的斜线或反斜线结尾。

　　COPYSCHEMA(,,) 　　这个过程在相同的数据库中创建模式的副本。

　　参数

　　新模式的大小写敏感名。

　　包含要添加到每个表定义中的表空间信息的字符串。假如是 NULL 或 ''，那么使用默认值。

　　要复制的模式的大小写敏感名。

　　REBINDPROCEDURES()

　　这个过程对一个模式中的所有 SQL 过程进行重新绑定。在为模式中过程使用的表收集新的统计数据之后，应该调用这个过程。这个过程将重新优化 SQL 过程中使用的所有 SQL 语句。

　　参数

　　模式的大小写敏感名。

　　示例

　　CALL ADMIN.DROPSCHEMA('SAMPLE')

　　这个过程调用会删除模式 "SAMPLE" 中的所有对象。

　　CALL ADMIN.BACKUPSCHEMA('UTIL', 'D:TEMPUTIL_SCHEMA')

　　这个过程调用将模式 "UTIL" 中的所有对象存储在目录 D:TEMPUTIL_SCHEMA 中。

　　CALL ADMIN.RESTORESCHEMA(NULL, NULL, 'D:TEMPUTIL_SCHEMA', 'D:TEMP')

　　这个过程调用从 D:TEMPUTIL_SCHEMA 中获取对象，并使用默认表空间将它们恢复到原来的模式中。来自装载过程的消息写入 D:TEMP 中。

　　CALL ADMIN.RESTORESCHEMA('SRIELAU', 'IN "DATA" INDEX IN "INDEX"', 'D:TEMPUSER_SCHEMA', 'D:TEMP')

　　这个过程调用从 D:TEMPUSER_SCHEMA 中获取对象，并将它们恢复到 "SRIELAU" 模式中，对于表数据使用表空间 "DATA"，对于索引使用 "INDEX"。来自装载过程的消息写入 D:TEMP 中。

　　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。

　　用来恢复模式的强制性方式也用于删除模式。DROPSCHEMA 过程简单地不断尝试删除对象，直到这个过程进行不下去或者所有对象都被删除为止。

　　结束语

　　本文提供了一组强大的过程，可以执行模式级操作，比如对给定模式中的所有对象进行逻辑备份、恢复和复制。除了用这个库帮助 ISV 和最终用户之外，本文还演示了如何利用 DB2 UDB 中丰富的 SQL API 为用户提供更多功能。