主页 / dba / 问题 / 14279
Accepted
Chris Aldrich
Asked: 2012-03-03 07:23:48 +0800 CST

使用索引进行变更管理的最佳实践

  • 772

我们的 IT 商店首先开始建立一组 DBA。我们所有人（包括我自己）都来自应用程序开发/架构领域，因此 DBA 领域对我们来说还是相当陌生的。

在构建 DBA 团队的同时，我们正在寻求构建变更管理程序和流程（希望基于最佳实践），以便在我们需要移动变更时使用。

我发现以下帖子主要对触发器、存储过程和/或 DDL 更改很有帮助。但它不一定涉及索引或供应商数据库。

我们混合使用了自己的数据库和供应商数据库。在我们的案例中，一些供应商（虽然不是全部）正在与我们公司合作构建数据库和应用程序。我们正在“上线”之前对我们的应用程序进行性能测试。因此，我们正在大量分析索引（或缺乏索引）。

当我们遇到我们认为应该制定的索引时，我们如何最好地处理与这些有关的变更管理，包括我们自己的数据库以及任何供应商？

你在店里做什么？我不太担心工具，而是担心过程。

编辑：到目前为止，我很感谢这个问题的反馈、评论和答案。我注意到有些答案有点特定于工具。如果可以的话，我正在寻找更多“不可知论者”的做法。

然而，如果不可知论是不可能的，那么对于工具集，我们主要使用 IBM DB2 LUW（实际上是在 AIX 上）。我们有一些 DB2 on Windows 和 DB2 for i（IBM 的 i5/OS），但我们主要是 AIX DB2。我们确实使用源代码控制，特别是 Subversion。

同样，寻找一般的最佳实践，但上面是我们使用的是供应商特定的。

编辑： 当前决定：我们打算跟踪我们的推理以及我们的变化。所以我们将在我们的问题跟踪软件（在我们的例子中是 JIRA）中打开一个问题。现在我们可以添加关于更改优先级的文档、支持更改应该是什么的数据、更改以及来自测试更改的另一个环境的更改结果。

然后我们还打算跟踪我们在 SVN 中的脚本更改（很像下面的建议）。这样我们就可以跟踪哪里存在什么版本。这可以记录在我们的 JIRA 问题中（以及我们使用的任何其他审计软件，即粘贴链接）。我们可以更确定地知道什么变化发生在什么环境以及为什么。然后，我们还可以跟踪索引是否是我们在供应商实施之外或在其实施之前添加的，等等。）

best-practices index

3 个回答

  1. Best Answer

    我强烈建议您像对待应用程序代码一样对待数据库。您可以将数据库的脚本编写成它的组成部分，并将它们签入源代码管理，然后使用与您的应用程序相同的标签和版本。

    要将对象置于源代码管理中，您可以使用多种工具。Microsoft 有一个绰号为 Data Dude 的工具。它适用于 Visual Studio。他们还准备发布一个名为 SQL Server 数据库工具 (SSDT) 的新工具，同样与 Visual Studio 一起使用。我的公司 Red Gate Software 制作了一个与 SSMS 配合使用的工具，称为 SQL Source Control。

    在过程方面，我为《红门团队开发指南》这本书写了好几章。它可以免费下载（或者如果您想砍掉一棵树，您可以从亚马逊购买一棵）。我在那里详细介绍了有关在开发团队中使用数据库的更多细节。

    • 11

    1. 我们维护数据库脚本作为我们的应用程序代码库的一部分，该代码库在版本控制下维护。但是我们对开发和生产代码使用不同的“过程”

    2. 开发我们维护以下脚本：

      • base.sql - 创建模式表和示例数据
      • stagingchanges.sql - 对暂存环境的 base.sql 进行更改，主要是电子邮件地址、路径和其他可能更改的资产
      • prodchanges.sql - 为生产部署更改 base.sql。对于新项目，我们通常会在实际生产环境中进行测试

    3. 维护

      • base.sql - 生产数据库的净化版本
      • stagingchanges.sql 和 prodchanges.sql - 如上所述
      • changerequest.sql（通常具有变更请求的 ID），它为我们正在处理的当前变更请求应用任何架构变更
      • changerequest-rollback.sql - 撤消为更改请求所做的更改并将数据库重置为生产
      • 以前的变更请求脚本的存档（文件夹）

    所以在维护模式下，我们需要做的就是在部署到生产期间应用 changerequest.sql 脚本

    • 3

  3. 在数据库版本控制领域工作了 5 年（作为DBmaestro的产品管理总监）并且作为 DBA 工作了 20 多年，我可以告诉你一个简单的事实，即你不能像对待 Java 那样对待数据库对象， C# 或其他文件。

    原因有很多，我举几个：

    • 文件本地存储在开发人员的 PC 上，他/她
      所做的更改不会影响其他开发人员。同样，开发人员不会受到同事所做更改的影响。在数据库中
      （通常）情况并非如此，开发人员共享相同的数据库
      环境，因此提交给数据库的任何更改都会影响其他人。
    • 发布代码更改是使用签入/提交更改等完成的（取决于您使用的源代码控制工具）。那时，开发人员本地目录中的代码被插入
      到源代码控制存储库中。想要获取
      最新代码的开发人员需要从源代码控制工具中请求它。在
      数据库中，更改已经存在并影响其他数据，即使它没有签入存储库。
    • 在文件签入期间，源代码控制工具执行冲突检查，以查看在您修改本地副本期间同一文件是否被其他开发人员修改和签入。同样，数据库中没有对此进行检查。如果您从本地 PC 更改程序，而同时我使用本地 PC 的代码修改相同的程序，那么我们将覆盖彼此的更改。
    • 代码的构建过程是通过将标签/最新版本的代码获取到一个空目录，然后执行构建-编译来完成的。输出是二进制文件，我们在其中复制并替换现有的。我们不在乎以前是什么。在数据库中，我们不能重新创建数据库，因为我们需要维护数据！部署还执行在构建过程中生成的 SQL 脚本。
    • 在执行 SQL 脚本（使用 DDL、DCL、DML（用于静态内容）命令）时，您假定环境的当前结构与创建脚本时的结构相匹配。如果没有，那么您的脚本可能会失败，因为您正在尝试添加已经存在的新列。
    • 将 SQL 脚本视为代码并手动生成它们将导致语法错误、数据库依赖性错误、不可重用的脚本，这会使开发、维护和测试这些脚本的任务复杂化。此外，这些脚本可能在与您认为运行的环境不同的环境中运行。
    • 有时版本控制存储库中的脚本与被测试对象的结构不匹配，然后在生产中会发生错误！

    还有更多，但我想你明白了。

    我发现有效的是：

    1. 使用强制版本控制系统，对数据库对象强制执行签出/签入操作。这将确保版本控制存储库与签入的代码匹配，因为它在签入操作中读取对象的元数据，而不是作为手动完成的单独步骤
    2. 使用将基线用作比较的一部分的影响分析来识别冲突并确定更改（在比较源代码控制存储库和数据库之间的对象结构时）是源自开发的真实更改还是源自不同的路径，然后应该跳过它，例如不同的分支或紧急修复。

    我写的一篇文章发表在这里，欢迎阅读。

    • 1

相关问题