本文示例源代码或素材下载 　　您是否有过想知道数据库何时被更改的经历？有了 IBM® DB2® Change Management Expert，您将不再有疑问！该工具可以帮助您跟踪变更，与其他小组成员合作无间，逆转或者撤消变更，以及审计对数据库作出的任何变更。本文描述这样一个场景：DBA 所在公司使用 DB2 Change Management Expert 和 Eclipse Team 项目来增强协作和确保一致的审计路径。您将学习连接到库控制系统并将变更治理项目、模型和脚本保存到库控制中，以及审计变更。而且，还将发现如何从库控制中检索变更，以及使用部署脚本撤消变更。　　简介　　数据库的维护不外乎变更 二字。假如您的目标是保证质量，那么就需要治理变更。您需要确保数据库应用程序按预期运行，变更能够顺利进行，并且，假如出现错误，可以调查问题。虽然数据库可以用日志记录某些活动，但是日志比较难于分析。最后，日志只能提供对数据库变更的一个不完整的描述。那么，为什么不借助软件开发中的技术呢？在软件开发中，跟踪变更的传统方法是使用某种类型的变更治理系统、过程或工具。这种方法有很多名称：配置治理、变更治理、源代码控制、库控制、版本控制等等。对于本文，我们使用术语版本控制。　　不管是对于应用程序还是对于产品代码本身，变更治理的过程都相当成熟。大多数程序员都熟悉对代码进行签入和签出操作，并知道什么版本与哪个软件发行版是对应的。但是，应用程序开发周期中扮演其它角色的人清楚这些因素的重要性吗？他们使用版本控制工具吗？架构师的设计、项目经理的计划、编程人员的文档以及测试人员的场景和结果又如何呢？数据库治理员呢？应用程序可不仅仅是代码。组成一个发行版的所有部分都应该在一起。作为应用程序一部分的任何对象都可以、也应该成为版本控制工具或过程的一部分。 123456789下一页 　　总体过程　　下面的图显示了使用 DB2 Change Management Expert 和版本控制系统更改一个数据库的总体过程：　　图 1. 使用 DB2 Change Management Expert 更改一个数据库的总体过程　　　　DB2 Change Management Expert 与 Eclipse　　DB2 Change Management Expert 是一个工具，它可以帮助 DBA 跟踪变更，与作出不同变更的其它 DBA 协作，审计和治理那些变更的历史，并逆转或撤销不再需要的变更。　　DB2 Change Management Expert 是基于 Eclipse 的工具。Eclipse 是用于交付胖客户机应用程序的一种与平台无关的开源软件框架。Eclipse 平台使其它工具开发人员可以轻松地构建和交付集成的工具。该框架被用于开发用于 DB2 Change Management Expert 的集成开发环境（IDE）。欲了解关于 Eclipse 平台的更多信息，请参阅本文的 参考资料 小节。DB2 Change Management Expert 中的一个成功的版本控制过程包括使用 Eclipse Team 功能。　　Eclipse Team 集成是 DB2 Change Management Expert 版本控制功能的要害组成部分。Eclipse Team 组件提供了一种机制，答应储存库工具将它们的储存库解决方案的完整的、丰富的功能集成到 Eclipse 工作台中。本文中的例子例释了 Eclipse Team 功能。欲了解关于 Eclipse Team 的更多信息，请参阅本文的 参考资料 小节。　　当数据库被更改后，DB2 Change Management Expert 项目（包括它所包含的所有资源）应该被注册到版本控制中，并被赋予一个标记或标签。　　还可以使用 Eclipse Team 功能归档 DB2 Change Management Expert 项目。为了跟踪变更，应该先归档项目。可以在变更开发的过程中，在部署任何变更之前进行归档。这样一来，就可以引入迭代，其它团队成员或 DBA 可以参与进来并提供变更，其他人则可以查看和修改已经作出的变更。 上一页123456789下一页 　　Data Design Projects、数据库与版本控制之间的关系　　可以以不同的方式使用版本控制来治理数据库变更项目。可以使用正式的或非正式的版本控制系统。版本控制系统可以像计算机上的文件系统一样简单，也可以像 Concurrent Visioning System (CVS) 或 IBM Rational Clear Case 一样全面。对于大多数示例，本文使用 CVS。　　DB2 Change Management Expert 通过项目将需要作出变更的不同资源组织在一起。一个数据设计项目通常跟踪一个数据库的生命周期。通过使用 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，提供了与 DB2 Change Management Expert 的最佳集成。但是，由于 DB2 Change Management Expert 将所有数据文件和文件夹存储在本地文件系统上，甚至可以使用未与 Eclipse 集成的版本控制系统来治理 DB2 Change Management Expert 资源。还可以在没有正式的版本控制系统的情况下治理变更。本文在 如何在不使用版本控制系统的情况下使用 DB2 Change Management Expert 小节对这种情况作了描述。 上一页123456789下一页 　　结合使用版本控制系统和 DB2 Change Management Expert　　这个示例演示如何使用版本控制审计变更，以及协调由不同 DBA 做出的变更。示例中的图显示了使用 DB2 V9 情况下的 DB2 Change Management Expert。示例被分为以下四个部分：　　Jaya 对数据库做出一个更改。　　Jaya 通过将项目提交到版本控制系统与他人共享项目。　　Eric 锁定项目，并做出其他更改。　　Jaya 不喜欢 Eric 做出的更改，并逆转这些更改。　　注重：本场景使用 CMEDEMO 数据库。可以从本文的 下载 小节下载 sample01.zip 文件，并将其解压到一个本地目录，以安装用于创建和设置该数据库的 DDL（CreateCMEDEMO.chx）。下面是设置该数据库的步骤：　　选择 File -> New -> Data Design Project，创建一个 Data Design Project，并将该项目命名为 test。　　图 2. New Data Design Project　　　　在 DB2 Change Management Expert 的 Data Project Explorer 视图中，将 CreateCMEDEMO.chx 文件导入到 test 项目中。展开 CMEDEMO 项目中的 SQL Scripts 文件夹的内容，右键单击 CreateCMEDEMO.chx 文件，并选择 Run SQL。确认选择了适当的数据库版本。输入用户名和密码，不选择复选框 Create Deployment Project and Script file，然后单击 Finish。　　在 Database Explorer 视图中，确认 CMEDEMO 数据库已经被创建，并且存在一个连接。现在可以继续完成本文中的所有步骤。　　第 1 部分。DBA Jaya 对数据库做出更改。　　和 Jaya 一样，您将完成以下步骤：　　创建一个名为 TestAudit 的新的部署脚本。部署脚本是一种 DB2 Change Management Expert 资源，用于跟踪变更治理过程。可以在 New Deployment Script 向导中指定被更改的数据库的位置和名称。这里将为指定的数据库创建两个模型。一个模型是基本模型，表示数据库的当前状态，另一个模型是目标模型，可以通过编辑该模型来定义新的变更。 上一页123456789下一页 　　对目标模型做出更改。例如，为 CL_SCHED 表创建一个名为 LOCATION 的 CHAR(128) 类型的新列。可以在属性视图中添加这个新列。做出更改后，保存模型。　　图 3. CL_SCHED 表中的数据列 'LOCATION'　　　　打开该部署脚本。为了生成变更命令，在 Outline 视图中右键单击 Change Commands，选择 Generate Change Commands。这时弹出 Generate Change Commands 向导。除了变更命令外，该向导还创建数据保留（data-preservation）命令。这里必须为部署时生成的数据文件指定文件系统上的一个位置。通过在向导中选择 auto-cast，可以解决任何导入与导出列数据类型的冲突。　　图 4. Generate Change Commands 向导生成的变更命令清单　　　　第 2 部分。Jaya 做出的变更就此完成，现在她可以将项目添加到版本控制系统中，从而共享项目。之后，可以从版本控制系统中提取变更，并用于继续变更治理过程。必要时，其他治理员也可以审计变更。这样很轻易组合和协调两个甚至更多 DBA 做出的变更。　　这个例子中使用 CVS 作为版本控制系统。　　安装 CVS Server，并设置一个储存库。　　在 DB2 Change Management Expert 中，打开 CVS Repository Exploring 透视图。该透视图包括一个名为 CVS Repositories 的视图，在这里可以添加多个不同的储存库位置。　　为了添加 DB2 Change Management Expert Data Design Project 的储存库位置，在该视图中单击右键，选择 New -> Repository。这时显示以下对话框： 上一页123456789下一页 　　图 5. Add CVS Repository 对话框　　　　在所需字段内输入信息，然后选择 Finish。您将看到添加到 CVS Repository 视图中的储存库。　　图 6. Repository Exploring 视图，包含新的储存库位置　　　　可以进行下拉操作，浏览该储存库中的内容。　　切换回 Data 透视图。选择要注册到 CVS 中的项目，在该项目上单击右键，选择 Team -> Share Project。这时弹出 Share Project 向导。　　图 7. Share Project 向导　　　　选择已有的储存库位置（在上一步中已经添加）。接受所有默认设置，单击 Finish。 记住：可以签入所有 ASCII 类型的 DB2 Change Management Expert 资源。 任何被答应访问这个特定储存库位置的 DBA 现在都可以打开和查看该项目，并且可以做出更改。　　第 3 部分。 另一个 DBA Eric 可以打开该项目，并做出其它更改。Eric 完成以下步骤：　　打开 CVS Repository Exploring 透视图。在 CVS Repository 视图中选择该项目，单击右键，并选择 Check Out。这将在当前工作区中创建该项目的一个副本。现在可以修改该项目和任何相关的文件。　　编辑目标模型。将 EMP_PHOTO table 拖入到模型中，重新生成变更命令。可以参考第 1 部分中的步骤。　　完成更改后，查看数据库模型。假如该模型没有达到预期的结果，则可以通过恢复到 Jaya 创建的版本，撤消新的更改。为了撤消更改，在 Data Project Explorer 中右键单击该项目（或该项目中的某个资源），选择 Replace With -> Latest from Head。这一步将 EMP_PHOTO 表添加回目标模型。 注重：对 EMP_PHOTO 表做出的新更改是本地的，只有在显式地提交之后才会被注册到 CVS 中。 上一页123456789下一页 　　在物理数据库编辑器中，打开目标模型，再次修改它。下面是可以对模型做出的更改的一个例子。更改完成之后，保存模型，并重新生成变更命令。此外还将生成撤消命令：　　添加一个名为 COMPLETION_CODE 的新表，表中列 CODE 的数据类型为 INTEGER，列 DESC 的数据类型为 VARCHAR(128)。将列 CODE 设为表 COMPLETION_CODE 的主键。　　将一个类型为 INTEGER、名为 CODE 的新列添加到 PROJECT TABLE 表中。将 PROJECT 表的 CODE 列定义为 nullable。　　创建 PROJECT 表中列 CODE 与 COMPLETION_CODE 表中主键列 CODE 之间的外键关系。　　选择 Deploy Changes 将更改部署到目标数据库。 注重： 当在 DB2 Change Management Expert 中部署时，更改被记录到工作区中的一个部署日志文件中。这个部署日志文件也应该与 test 项目一起注册到 CVS 中。　　更改将沿着 Deployment Script Editor 概述页面指定的连接部署。假如工作区内不存在连接，则必须创建一个与目标数据库同名的连接。为此可以从 Database Explorer 视图中选择 Connections -> New Connection。　　图 8. New Connection 向导　　　　选择 Team -> Commit 将更改注册到 CVS 中。　　现在整个团队可以查看 Jaya 和 Eric 做出的更改。　　第 4 部分。第一个 DBA Jaya 打开项目，并查看 Eric 做出的更改。假如 Jaya 想要撤消 Eric 对数据库部署的更改，则可以执行以下步骤：　　打开部署脚本，并在 Deployment Script Editor 的 Undo Changes 标签页上选择 Deploy Undo Commands。　　要么重置部署脚本，重新开始变更过程，要么再次修改模型，以生成她想要部署的变更命令。 上一页123456789下一页 　　可以通过打开部署脚本并单击 deployment script editor 的菜单项重置部署脚本。选择 Deploy -> Reset。这样将启动一个向导，该向导将帮助重置部署脚本。　　如何在不使用版本控制系统的情况下使用 DB2 Change Management Expert　　假如不能使用一个版本控制系统，是否仍然可以使用 DB2 Change Management Expert？当然！但是，出于审计和跟踪的目的，可能仍然需要遵从某些控制，那么，假如 DB2 变更都存储在 DB2 Change Management Expert 中，则应该如何做呢？Data Project 信息存储在一开始定义的 DB2 Change Management Expert Workspace 中。工作区是本地磁盘上的一组目录，因此可以将那些文件保存在一起，作为该版本的文件集。　　我们使用本文中的示例，但是假设您没有版本控制系统。　　使用储存库存储变更的一个好处是工作区可以使用大量的变更历史。出于审计的目的，或者为了撤消一次变更，可能需要这些历史。假如只处理项目文件本身，那么就需要由您来跟踪发生了什么变更，以及是谁做出的变更。　　可以与其他用户共享整个工作区吗？　　从技术上讲，是这样的，可以共享整个工作区，例如在一个共享驱动器上。但是，假如在其他人已打开工作区的时候尝试打开工作区，就会收到一条错误消息，说该文件已经在使用。共享工作区的另一个缺点是所有设置也随之被共享，所以假如其他人更改设置的话，就可能丢失定制。所以不建议共享工作区。　　如何在多个 DBA 之间共享文件？　　有一些方法可以共享项目文件。本文使用的、也是最简单的方法是将整个项目导出为一个归档文件（ZIP 文件），让其他用户将项目导入到他们的工作区中。 遵循上述场景之后（Jaya 和 Eric 完成某些数据库变更），当生成所有变更命令之后，Jaya 现在处在第 1 部分的最后位置。Jaya 现在不是将文件注册到版本控制中，而是需要保护更改，使之可以被正在处理该项目的另一个 DBA 使用。Jaya 执行以下步骤： 上一页123456789下一页 　　选择项目，然后选择 File -> Export，打开 Export 对话框。　　展开 General 文件夹，选择 Archive File 并单击 Next。　　在接下来的屏幕上，选择项目、输出文件位置、文件名和格式（ZIP 或 TAR），然后单击 Finish。这样将在磁盘上创建 ZIP 文件。　　Jaya 可以离开 DB2 Change Management Expert，使导出的 ZIP 文件可以被 Eric 使用。　　Eric 现在需要处理该项目。Eric 不是从 CVS 中读出它，而是必须手动地将那个项目导入他的工作区中。Eric 执行以下步骤：　　在工作区中，选择 File -> Import。　　展开 General 文件夹并选择 Existing Projects into Workspace。　　使用 Select archive file 浏览至 Jaya 导出的归档文件的位置。那个归档文件中的项目将出现在 Projects 列表框中。　　选择项目并单击 Finish。　　现在，项目就处在 Eric 的工作区中，他可以继续第 3 部分中描述的变更。当 Eric 做出更改并生成 DDL 时，部署脚本同时包含来自 Jaya 和 Eric（Eric 可能已经删除或修改了 Jaya 的更改，但是这里没有）。　　在第 3 部分中，Eric 删除一个表，但是后来改变了主意，并返回到 CVS 中项目的版本。假如不使用版本控制系统，如何可以做到这一点？　　在 CME 中，有些本地历史存在于工作区中。在这个特定的场景中，Eric 可以继续从目标模型中删除 EMP_PHOTO 表，然后通过从 Data Project Explorer 视图中右键单击目标模型并选择 Replace with Local History 将其放回模型中。Eric 可以逆转之前的更改。但并不是所有情况下都能这样，而是只有在工作区中才能这样。也就是说，Eric 和 Jaya 不能相互逆转对方的更改。　　在第 4 部分中，当 Eric 将项目导出到一个归档文件（ZIP/TAR）之后，Jaya 可以将项目导回到工作区中。Jaya 应该从工作区中删除已有的项目，并导入 Eric 做出的新的项目归档。这个项目将包含从第 1 部分到第 3 部分的所有变更。但是，Jaya 不能访问关于 Eric 做出的变更的任何本地历史，所以要恢复到之前的变更就变得更困难。　　从这个场景可以看出，当进行团队协作时，版本控制系统是多么的重要。　　通过整个项目文件共享变更的另一种方法是共享各个模型或部署脚本，并使用 DB2 Change Management Expert 合并和迁移特性集成变更。这种方法要求更多地注重细节，但是当处理多个变更或者更复杂的变更时，可以提供更多的灵活性。不管使用何种方法，都不能获得比版本控制系统所提供的更丰富的历史功能。　　结束语　　结合使用版本控制系统和 DB2 Change Management Expert，可以为治理业务需求提供一个强制性的资源。使用这两种工具有助于顺利完成对应用程序开发周期中涉及的所有变更的跟踪。即使没有版本控制系统，通过使用 DB2 Change Management Expert 和一个规划良好的系统，也仍然可以获得上述好处。希望本文能够鼓励您进一步探索 DB2 Change Management Expert 如何满足您的要求。 上一页123456789