通过备份将 SQL Server 数据库部署到生产服务器是否有任何问题？

Question

这是一个稍微复杂的问题，因为我已经假设所描述的场景是错误的。

DBA 正在部署我编写的应用程序，其中包含一个 MS SQL Server 2008 数据库。他让我从我的开发机器上获取数据库备份，以便他可以将其恢复到生产服务器，从而部署它。这是一个全新的部署，因此没有要迁移的现有数据。我期待提供一个 DDL 脚本，我已经努力测试并确保它包含所需的一切。如果我在 SSMS 中执行它，则一键创建数据库。

对我来说，使用备份工具进行部署似乎不太合适，但如果不是 SQL Server 专家，我想不出不这样做的充分理由。例如，我会认为开发机器会对数据库造成一些“污染”——可能是计算机名称、目录结构或存储在某处的用户名。是这种情况，还是备份和恢复是一种有效的部署技术？

Answer 1

使用备份文件作为部署的一切都是错误的。但负担不在 DBA 上提供 DDL，在开发上。您的设计和开发工件应该是数据库安装和升级脚本。永远不要手动更改数据库中的任何内容，应该使用您的应用程序修改所有内容。Rails 与整个迁移基础架构完全一致，您也应该尝试采用它。我长期以来一直提倡使用类似的技术，请参阅版本控制和您的数据库。

首先让我说明为什么基于源代码的部署/升级优于基于二进制的部署（.bak 或 diff 工具）：

• 源代码可以签入到源代码管理中。仅此一项就可以解决整个争论。源代码控制为您提供历史，未来您可以回顾并阅读签入说明，了解当前状态背后的原因。
• 可以一目了然地快速检查源代码。你看着它并阅读它。需要附加二进制数据库，并且需要对元数据目录有广泛的了解才能阅读基本属性
• 源代码很干净。你看CREATE TABLE Foo (...)，这清楚地传达了意图。二进制分布，如果你想提取对象，会为你提供大量的默认属性。你失去了最初的意图。
• 源代码可以在签入时进行同行评审。
• 源代码集成在连续部署中

我也有理由为什么通过备份部署不好（非常糟糕）：

• 你只是推迟了这个问题。应用程序的第一个更新将面临部署更新而不丢失数据的问题。这可能会在部署后的第二天发生，当生产中发现问题时，您将面临空白：如何修改生产数据库以匹配开发数据库？
• 数据库不是自包含的。部署调用数据库外的对象（登录名、SQL 代理作业、维护计划等），这些对象都不能通过备份进行部署。
• 你永远不知道你部署了什么。开发过程中遗留的被遗忘的表？测试数据？清理数据库非常困难，但保持源代码最新和正确是很自然的。

Answer 2

不，使用备份进行初始部署并没有错，事实上我会说这通常是最安全的方法。除非您有硬编码的东西，如生产环境中与测试环境中不同的服务器名称或数据库名称，否则不会真正发生任何“污染”。

尽管备份/恢复（很像您自己的仅限于数据库的 DDL 脚本）不会带来诸如服务器级登录、链接服务器、SQL 代理作业等之类的东西。

使用 DDL 脚本不一定能通过备份获得其他一些好处，例如，如果您像这样创建原始表：

CREATE TABLE dbo.foo
(
  bar INT PRIMARY KEY,
  mort INT FOREIGN KEY REFERENCES dbo.mort(MortID),
  x TINYINT CHECK (x IN (1,2)),
  y INT NOT NULL DEFAULT 1
);

所有这些约束都有系统生成的名称，例如PK__foo__DE90ECFFA28BBAB8. 当您在生产中运行相同的脚本时，名称将不同，除非您在测试环境中编写了准确的表定义脚本。如果您从测试生成 drop/create/alter 脚本并需要在生产中运行它们，这可能会在以后导致问题。

当您进行备份时，您还将获得查找表等中的所有数据，您必须手动编写脚本以便将该数据投入生产。（尽管您也必须确保清除您不希望在生产中使用的任何测试数据。）

自己编写脚本的一个弱点是您必须确保所有对象都以正确的依赖顺序创建。您可能在测试中存在生产中缺少的依赖项，因为对象没有以正确的顺序生成。

归根结底，备份更干净。并且您应该在部署数据库时对其进行测试，因此您应该很快发现任何“污染”，并在两种环境中进行纠正。

一旦最初部署了数据库，很明显，以后部署更改的唯一方法就是编写它们的脚本。我很幸运使用 Red-Gate 的 SQL 比较生成比较/部署脚本。虽然 Remus 是绝对正确的，但源代码管理是解决此问题的最佳解决方案，但实际上，源代码管理通常会存储一个CREATE TABLE脚本，当您添加一列并更改另一列的数据类型时，这不会让您走得太远 -您仍然需要构建某种差异脚本，该脚本仅将更改应用于生产，而不是删除并重新创建表。

如果您有其他数据库中或可能位于不同服务器中的本地查找表之类的东西，那么您应该使用同义词而不是在代码中硬编码这些名称。然后，您只需确保每个环境中的同义词都是正确的，而不是在所有模块中查找所有三/四部分名称并在部署时更新它们。如果您的本地文件路径因环境而异，请使用中央属性表，而不是将这些路径硬编码到您的程序等中。

从理论上讲，您可以稍后使用备份和恢复方法，但如果生产数据库已在使用中，则效果不佳 - 从测试中恢复数据库并且不丢失在生产中收集的任何数据会有点棘手.