您是否想知道数据库何时更改？Data Studio Administrator（以前是 DB2 Change Management Expert）能够帮助您！它可以帮助您跟踪变更、与其他小组成员无缝合作、逆转或者撤消变更，以及审计数据库的任何变更。本文描述这样一个场景：DBA 所在的公司使用 Data Studio Administrator 和 Eclipse Team 项目来增强协作和确保一致的审计路径。您将学习连接到库控制系统并将变更管理项目、模型和脚本保存到库控制中，以及审计变更。此外，还将了解如何从库控制中检索变更，以及使用部署脚本撤消变更。

注意：本书是已经发表的文章 “DB2 Change Management Expert” 的更新。本文解释了新的名称 “IBM Data Studio Administrator”，以及其他可用于 Data Studio Administrator Version 1.2 的变更。

简介

数据库的维护不外乎变更变更 二字。您需要确保数据库应用程序按预期运行，变更能够顺利进行，并且，如果出现错误，可以找到问题的根源。虽然数据库可以用日志记录某些活动，但是日志的分析比较困难。最后，日志只能提供对数据库变更的一个不完整的描述。那么，为何不借助软件开发中的技术来帮助管理变更呢？在传统的软件开发中，跟踪变更的方法是使用某种类型的变更管理系统、过程或工具。这种方法有很多名称：配置管理、变更管理、源代码控制、库控制、版本控制等等。对于本文，我们使用的术语是版本控制。

不管是对于应用程序还是对于产品代码本身，变更管理的过程都相当成熟。大多数程序员都熟悉对代码进行签入和签出操作，并知道什么版本与哪个软件发行版是对应的。但是，应用程序开发周期中的其他参与者清楚这些因素的重要性吗？他们使用版本控制工具吗？架构师的设计、项目经理的计划、编程人员的文档以及测试人员的场景和结果又如何呢？数据库管理员呢？应用程序可不仅仅是代码。组成一个发行版的所有部分都应该在一起。作为应用程序一部分的任何对象都可以、也应该成为版本控制工具或过程的一部分。

总体过程

下面的图显示了使用 Data Studio Administrator 和版本控制系统更改一个数据库的总体过程：

Data Studio Administrator 和 Eclipse

Data Studio Administrator 是一个工具，它可以帮助 DBA 跟踪变更，与作出不同变更的其它 DBA 协作，审计和管理那些变更的历史，并逆转或撤销不再需要的变更。

Data Studio Administrator 是基于 Eclipse 的工具。Eclipse 是用于交付胖客户机应用程序的一种与平台无关的开源软件框架。Eclipse 平台使其它工具开发人员可以轻松地构建和交付集成的工具。该框架用于开发 Data Studio Administrator 的集成开发环境（IDE）。欲了解关于 Eclipse 平台的更多信息，请参阅本文的 参考资料 小节。中的一个成功的版本控制过程包括使用 Eclipse Team 功能。

Eclipse Team 集成是 Data Studio Administrator 版本控制功能的关键组件。Eclipse Team 组件提供了一种机制，允许储存库工具将它们的储存库解决方案的完整的、丰富的功能集成到 Eclipse 工作台中。本文中的例子例释了 Eclipse Team 功能。欲了解关于 Eclipse Team 的更多信息，请参阅本文的 参考资料 小节。

当数据库更改后，Data Studio Administrator 项目（包括它所包含的所有资源）应该签入到版本控制中，并被赋予一个标记或标签。

还可以使用 Eclipse Team 功能归档 Data Studio Administrator 项目。在跟踪变更之前，应该先归档项目。可以在变更开发的过程中，在部署任何变更之前进行归档。这样一来，就可以引入迭代，其它团队成员或 DBA 可以参与进来并提供变更，其他人则可以查看和修改已经作出的变更。

Data Design Projects、数据库与版本控制之间的关系

可以以不同的方式使用版本控制来管理数据库变更项目。可以使用正式的或非正式的版本控制系统。版本控制系统可以像计算机上的文件系统一样简单，也可以像 Concurrent Visioning System (CVS) 或 IBM Rational Clear Case 一样完善。本文的大多数示例都使用 CVS。

Data Studio Administrator 通过项目将需要变更的不同资源进行分组。一个数据设计项目通常跟踪一个数据库的生命周期。通过使用 Eclipse team 功能，可以共享项目，以便多个 DBA 在变更上实现协作。Data Design Projects 在特定的时间点上表示变更。部署变更之后，资源通常被提交到版本控制系统，并被赋予一个标记或标签。可以使用标记或标签返回到变更保存点，以撤销变更，或者审计特定的变更。

在更复杂的数据库中，可以使用 Data Design Project 来管理一个特定数据库应用程序的生命周期。在某些公司，表或模式被拆分开来，由特定的 DBA 或 DBA 团队管理。可以修改 Data Design Projects 以匹配这些环境。因此，可以将一个数据库拆分开，由数个 Data Design Projects 来管理。如果一个主数据库有多个副本，则可以使用一个 Data Design Project 来管理这些数据库。这就是所谓的多重配置（multiple provisioning），即首先为一个数据库构造变更，然后将其部署到多个数据库。

插入到 Eclipse 中的版本控制系统，例如 CVS 或 IBM Rational Clear Case，能够与 Data Studio Administrator 完美集成。但是，由于 Data Studio Administrator 将所有数据文件和文件夹存储在本地文件系统上，因此也可以使用未与 Eclipse 集成的版本控制系统来管理 Data Studio Administrator 资源。还可以在没有正式的版本控制系统的情况下管理变更。本文在 如何在没有版本控制系统的情况下使用 Data Studio Administrator 小节对此进行了描述。

结合使用版本控制系统和 Data Studio Administrator

这个示例演示如何使用版本控制审计变更，以及协调由不同 DBA 做出的变更。示例中的图显示了使用 DB2 V9.1 的 Data Studio Administrator。示例分为以下四个部分：

1. Jaya 对数据库进行更改。
2. Jaya 通过将项目提交到版本控制系统与他人共享项目。
3. Eric 查看项目，并进行其他更改。
4. Jaya 不喜欢 Eric 的更改，并撤销了这些更改。

注意：注意：本场景使用 DSADEMO 数据库。可以从本文的 下载 小节下载 sample02.zip 文件，并将其解压到一个本地目录，以安装用于创建和设置该数据库的 DDL（CreateDSADEMO.chx）。下面是设置该数据库的步骤：

1. 选择 File -> New -> Data Design Project 创建 Data Design Projectand，并将其命名为 test。
   
   图 2. 新的 Data Design Project
   
   
   
2. 在 Data Studio Administrator 的 Data Project Explorer 视图中，将 CreateDSADEMO.chx 文件导入到 test 项目中。在 test 项目中展开 SQL Scripts 文件夹的内容，右键单击 CreateDSADEMO.chx 文件，然后选择 Run SQL。确认选择了适当的数据库版本。输入用户名和密码，不需选择 Create Deployment Project and Script file 复选框，然后单击 Finish。

   在 Database Explorer 视图中，确认已经创建 DSADEMO 数据库，并且存在一个连接。现在可以继续完成本文中的所有步骤。

第 1 部分。DBA Jaya 对数据库进行更改。

和 Jaya 一样，您将完成以下步骤：

1. 创建一个名为 TestAudit 的新的部署脚本。部署脚本是一种 Data Studio Administrator 资源，用于跟踪变更管理过程。可以在 New Deployment Script 向导中指定被更改的数据库的位置和名称。选择 Change in Place 过程，但不要选择复选框 Migrate Table Data。只选择 HR 模式。这里将为指定的数据库创建两个模型。一个模型是基本模型 ，表示数据库的当前状态，另一个模型是目标模型，可以编辑该模型来定义新的变更。
2. 从 Outline 视图更改目标模型。例如，为 CL_SCHED 表创建一个名为 LOCATION 的 CHAR(128) 类型的新列。可以在屏幕顶端中间的 Data Model Editor 中添加新列。更改完成后保存模型。图 3 展示了这个步骤。
   
   图 3. CL_SCHED 表中的数据列 ‘LOCATION’
   
   
   
3. 打开该部署脚本。在 Deployment Script Overview 中单击 Generate 生成变更命令。这时会显示 Generate Change Commands 向导。除了变更命令以外，该向导还创建数据保存命令。必须在文件系统上为部署生成的数据文件指定一个位置。通过在向导中选择 auto-cast，可以解决导入与导出列数据类型之间的冲突。Data Studio Administrator 还创建了一个 Summary of Changes Report，通过它可以查看或审计更改。
   
   图 4. Generate Change Commands 向导生成的变更命令列表
   
   
   

第 2 部分。Jaya 进行的变更到此就完成了，现在她可以将项目添加到版本控制系统中，从而共享项目。以后可以从版本控制系统中提取变更，并用于继续变更管理过程。必要时，其他管理员也可以审计变更。这样很容易组合和协调两个甚至更多 DBA 做出的变更。

这个例子中使用 CVS 作为版本控制系统。

1. 安装 CVS Server 并设置一个存储库。
2. 在 Data Studio Administrator 中，打开 CVS Repository Exploring 透视图。该透视图包括一个名为 CVS Repositories 的视图，在这里可以添加多个不同的储存库位置。
3. 要为 Data Studio Administrator Data Design Project 添加存储库位置，在 CVS Repositories 视图中单击右键，然后选择 New -> Repository Location。这时显示以下对话框：
   
   图 5. Add CVS Repository 对话框
   
   
   
4. 在所需字段内输入信息，然后选择 Finish。您将看到添加到 CVS Repository 视图中的储存库。
   
   图 6. Repository Exploring 视图，包含新的储存库位置
   
   
   可以进行下拉操作，浏览该储存库中的内容。
5. 切换回 Data 透视图。选择要签入 CVS 的 test 项目，单击右键该项目，然后选择 Team -> Share Project。这时弹出 Share Project 向导。
   
   图 7. Share Project 向导
   
   
   
6. 选择已有的储存库位置（在上一步中已经添加）。接受所有默认设置，单击 Finish。 记住：可以签入所有 ASCII 类型的 Data Studio Administrator 资源。任何有权访问这个特定储存库位置的 DBA 现在都可以打开和查看该项目，并且可以进行更改。

第 3 部分。另一个 DBA Eric 可以打开并更改该项目。Eric 完成以下步骤：

1. 打开 CVS Repository Exploring 透视图。在 CVS Repository 视图中选择 test 项目，右键单击，并选择 Check Out。这将在当前工作区中创建该项目的一个副本。现在可以修改该项目和任何相关的文件。
2. 编辑目标模型。将 EMP_PHOTO table 拖入到模型中，重新生成变更命令。可以参考第 1 部分中的步骤。
3. 完成更改后，查看数据库模型。如果该模型没有达到预期的结果，则可以通过恢复到 Jaya 创建的版本，撤消新的更改。为了撤消更改，在 Data Project Explorer 中右键单击该项目（或该项目中的某个资源），选择 Replace With -> Latest from Head。这一步将 EMP_PHOTO 表添加回目标模型。注意：对 EMP_PHOTO 表做出的新更改是本地的，只有在显式地提交之后才会签入到 CVS 中。
4. 在物理数据库编辑器中，打开目标模型，再次修改它。下面是可以对模型做出的更改的一个例子：
   1. 在 HR 模式中添加一个名为 COMPLETION_CODE 的新表，表中列 CODE 的数据类型为 INTEGER，列 DESC 的数据类型为 VARCHAR(128)。将列 CODE 设为表 COMPLETION_CODE 的主键。
   2. 将一个类型为 INTEGER、名为 CODE 的新列添加到 PROJECT TABLE 表中。将 PROJECT 表的 CODE 列定义为 nullable。
   3. 创建 PROJECT 表中的列 CODE 与 COMPLETION_CODE 表中的主键列 CODE 之间的外键关系。
   更改完成之后，保存模型并重新生成变更命令。同时也生成撤销命令。
5. 在 Deployment Script Overview 选项卡上，选择 Deploy 将您的更改部署到目标数据库。 注意：当在 Data Studio Administrator 中部署时，更改被记录到工作区中的一个部署日志文件中。这个部署日志文件也应该与 test 项目一起签入到 CVS 中。
6. 更改将根据 Deployment Script Editor 概述页面指定的连接进行部署。如果工作区内不存在连接，则必须创建一个与目标数据库同名的连接。要实现这个步骤，可以从 Database Explorer 视图中选择 Connections -> New Connection。这时将出现 New Connection 向导。
   
   图 8. New Connection 向导
   
   
   
7. 右键单击 test 项目并选择 Team -> Commit 将更改签入到 CVS。

现在整个团队都可以查看 Jaya 和 Eric 所做的更改。

第 4 部分。第一个 DBA Jaya 打开项目，并查看 Eric 做出的更改。如果 Jaya 想要撤消 Eric 对数据库部署的更改，则可以执行以下步骤：

1. 打开部署脚本，并在 Deployment Script Editor 的 Overview 选项卡上选择 Undo。
2. 要么重置部署脚本，重新开始变更过程，要么再次修改模型，以生成她想要部署的变更命令。

可以通过打开部署脚本并从菜单栏选择 Deploy -> Reset 重置部署脚本。这样将启动一个向导，该向导将帮助重置部署脚本。

如何在没有版本控制系统的情况下使用 Data Studio Administrator

如果没有版本控制系统，是否仍然可以使用 Data Studio Administrator？当然！但是，出于审计和跟踪的目的，可能仍然需要遵从某些控制，那么，如果 DB2 变更都存储在 Data Studio Administrator Workspace 中，则应该如何做呢？Data Project 信息存储在一开始就定义的 Data Studio Administrator Workspace 中。工作区是本地磁盘上的一组目录，因此可以将那些文件保存在一起，作为该版本的文件集。

我们使用本文中的示例，但是假设您没有版本控制系统。

使用储存库存储变更的一个好处是工作区可以使用大量的变更历史。审计或撤消变更可能需要这些历史。如果只处理项目文件本身，那么就需要由您来跟踪发生了什么变更，以及是谁做出的变更。

可以和其他用户共享整个工作区吗？

从技术上讲，可以共享整个工作区，例如在一个共享驱动器上。但是，如果在其他人已打开工作区的时候尝试打开工作区，就会收到一条错误消息，说该文件已经在使用。共享工作区的另一个缺点是所有设置也随之共享，所以如果其他人更改设置的话，就可能丢失定制。所以不建议共享工作区。

如何在多个 DBA 之间共享文件？

有一些方法可以共享项目文件。本文使用的、也是最简单的方法是将整个项目导出为一个归档文件（ZIP 文件），让其他用户将项目导入到他们的工作区中。遵循上述场景之后（Jaya 和 Eric 进行某些数据库变更），当生成所有变更命令之后，Jaya 现在处在第 1 部分的最后位置。Jaya 现在不是将文件签入到版本控制中，而是需要保护更改，这样，正在参与该项目的另一个 DBA 就可以使用它。Jaya 需要执行以下步骤：

1. 选择项目，然后选择 File -> Export 打开 Export 对话框。
2. 展开 General 文件夹，选择 Archive File 并单击 Next。
3. 在接下来的屏幕上，选择项目、输出文件位置、文件名和格式（ZIP 或 TAR），然后单击 Finish。这样将在磁盘上创建 ZIP 文件。
4. Jaya 可以退出 Data Studio Administrator，使 Eric 能够使用导出的 ZIP 文件。

Eric 现在需要处理该项目。Eric 不是从 CVS 中读出它，而是必须手动地将那个项目导入他的工作区中。Eric 需要执行以下步骤：

1. 在工作区中，选择 File -> Import。
2. 展开 General 文件夹并选择 Existing Projects into Workspace。
3. 使用 Select archive file 浏览至 Jaya 导出的归档文件的位置。那个归档文件中的项目将出现在 Projects 列表框中。
4. 选择项目并单击 Finish。

现在，项目就处在 Eric 的工作区中，他可以继续第 3 部分中描述的变更。当 Eric 做出更改并生成 DDL 时，部署脚本同时包含来自 Jaya 和 Eric（Eric 可能删除或修改 Jaya 的更改，但在本示例中他没有这样做）。

在第 3 部分中，Eric 删除一个表，但是后来改变了主意，并返回到 CVS 中项目的版本。如果不使用版本控制系统，如何能实现这一点？

在 Data Studio Administrator 中，有些本地历史存在于工作区中。在这个特定的场景中，Eric 可以继续从目标模型中删除 EMP_PHOTO 表，然后通过从 Data Project Explorer 视图中右键单击目标模型并选择 Replace with Local History 将其放回模型中。Eric 可以撤销之前的更改。但并不是所有情况下都能这样，而是只有在工作区中才能这样。也就是说，Eric 和 Jaya 不能相互撤销对方的更改。

在第 4 部分中，当 Eric 将项目导出到一个归档文件（ZIP/TAR）之后，Jaya 可以将项目导回到工作区中。Jaya 应该从工作区中删除已有的项目，并导入 Eric 的新项目归档。这个项目将包含从第 1 部分到第 3 部分的所有变更。但是，Jaya 不能访问关于 Eric 做出的变更的任何本地历史，所以要恢复到之前的变更就变得更困难。

从这个场景可以看出，当进行团队协作时，版本控制系统是多么的重要。

通过整个项目文件共享变更的另一种方法是共享各个模型或部署脚本，并使用 Data Studio Administrator 的合并和迁移特性集成变更。这种方法要求更多地注意细节，但是当处理多个变更或者更复杂的变更时，可以提供更多的灵活性。不管使用何种方法，都不能像版本控制系统那样提供丰富的历史特性。

结束语

结合使用版本控制系统和 Data Studio Administrator 可以为管理业务需求提供可靠的资源。使用这两种工具有助于顺利跟踪应用程序开发周期中涉及到的所有变更。即使没有现成的版本控制系统，通过将 Data Studio Administrator 和您自己良好规划的系统结合起来，也可以达到上述的效果。希望您能进一步探索 Data Studio Administrator 如何才能满足您的要求。（责任编辑：A6）