从不同版本/版本的备份文件恢复数据库

Question

我了解到，出于向后兼容性的原因，只要您从旧版本恢复到新版本，就可以在 SQL Server 中恢复数据库。

有谁知道您是否可以从不同版本的 SQL Server 的 *.bak 文件还原数据库？我们正在通过 FTP 移动一个非常大的数据库，这需要几天时间，所以我们宁愿只做一次。如果在我们通过 FTP 传输数据库时没有人响应，我们显然会尝试一下，通过测试看看它是否有效，然后回答我们自己的问题。

以下是获取 SQL Server 版本详细信息的查询。该productversion格式为{major revision}.{minor revision}.{release revision}.{build number}。在我的情况下，源和目标{release revision}的值为。所以看起来没问题。然而，情况不同。55005512edition

询问：

SELECT 
  SERVERPROPERTY('productversion'), 
  SERVERPROPERTY('productlevel'), 
  SERVERPROPERTY('edition')

源数据库：

10.0.5500.0
SP3
Developer Edition (64-bit)

目标数据库：

10.0.5512.0
SP3
Enterprise Edition (64-bit)

Answer 1

从开发人员到企业都可以，只要确保如果您使用处理器许可，您在目标服务器上拥有涵盖所有 CPU 的许可证。仅仅对 SQL 隐藏它们是不够的，如果它们物理连接到机器，你就要对它们负责。

此外，当您从较低版本转到较高版本时，您的数据库版本会增加。在某些情况下这可能会出现问题 - 例如，如果您在 2008 的特定版本上使用 15,000 分区支持，则在升级到 2008 R2 的特定版本时将无法工作。您可能还依赖优化（并有适当的变通方法），这些优化实际上是旧版本中的错误，但在新版本中已修复，这可能会导致性能下降。检查源端正在使用的任何跟踪标志并确定它们是否也应在目标端启用也很重要。别介意工作、登录等。

当然不能倒退。我从未尝试过像 10.0.5512 -> 10.0.5500 这样的小降级，但绝对不可能降级服务包或版本。因此，如果您的 Developer Edition 实例上有一个 2012 数据库，并且您想将它放在生产环境中的 2008 实例上，那么您将需要为您完成工作（请参阅此处和此处）——尤其是如果您已经使用了 2012 功能.

但是为了涵盖可能让人们回答这个问题的其他情况（例如，有人想从开发人员 -> 标准或企业 -> 快速或你有什么）......

还有其他版本 -> 版本升级不会那么顺利，例如从 Developer -> Express 如果您使用了 Express 不支持的任何功能（实际上除 Enterprise 之外的任何版本也是如此）。您将无法在下层版本上使用的一些功能示例（在这种情况下，还原将在尝试使数据库联机时终止）：

• 分区
• 变更数据捕获
• 数据压缩
• 透明数据加密

我不知道是否有办法直接从 .BAK 文件中得知这一点（我确信可以从某个地方的页眉中提取一些魔法，或者如果你有一个周末可以使用十六进制编辑器进行烧录） ，但是虽然源实例上的数据库仍然完好无损，但您始终可以执行以下操作，以查看您是否正在使用由于您所在的 SKU 而可用的任何功能：

SELECT feature_name FROM sys.dm_db_persisted_sku_features;

我不确定 SQL Server Audit 是否应该在该列表中 - 该功能的版本独占性已更改，因此可能取决于您使用它做什么。还有一些你可能正在使用但不会出现在 DMV 中的东西（有些是因为它们在你的代码中，DMV 没有解析，有些是因为你的数据库依赖于外部事物，比如 SQL Server 代理、服务代理等）：

• 镜像
• 某些形式的复制
• 日志传送
• 数据库快照
• 在线索引
• 可更新的分布式分区视图
• 备份压缩
• 政策管理
• 计划指南
• 数据库邮件
• 维护计划
• 全文检索

在某些情况下，由于文件大小限制（Express 数据库的总数据文件大小限制为 10GB），您将无法从 Developer 转到 Express。

当然，可能还有其他一些您不会被警告的问题——它们不会阻止迁移，但它们可能会导致目标的性能非常不同。例子：

1. 目标版本（甚至目标上的底层操作系统）的不同内存/CPU 限制。很多人从 2008 R2 Enterprise 到 2012 Enterprise (CAL)，其中服务被人为地限制在前 20 个内核）。这可能会导致直接的性能差异（例如，没有足够的内存来满足查询，或者并行查询性能要慢得多）；更微妙的包括由于不同的底层硬件而做出的计划选择。
2. 在不更改要使用的源代码的情况下，对源的索引视图匹配等功能的依赖不会自动在目标上得到尊重NOEXPAND。您甚至可能没有意识到这种功能是您的查询突然变慢的原因。
3. 并行索引操作也是如此，可能还有很多其他的优化现在暂时没有想到（幸好我几乎只在企业领域工作，所以在大多数情况下我不必担心低版本的限制）。

基于此重复的更新：

在某些情况下，您可能会尝试将数据库从某个版本恢复到较低版本（即使在同一版本上），但您会收到无用的错误：

服务器 'server\instance' 的 RESTORE 失败。
RESTORE 无法启动数据库“databasename”。

这不是很直观。但是，如果您更深入地查看 SQL Server 的事件日志，您会看到更多有用的错误（仅举一个例子）：

无法启动数据库“databasename”，因为某些数据库功能在当前版本的 SQL Server 中不可用。
无法在此版本的 SQL Server 中启动数据库“databasename”，因为它包含分区函数“_dta_pf__9987”。只有企业版 SQL Server 支持分区功能。

现在，这并不完全正确 - 您还可以恢复到评估版或开发者版，但这不是重点。为了恢复这个数据库，你基本上有两个选择：

1. 还原到适当版本的 SQL Server - 这意味着定位或安装新实例。
2. 将源服务器上的备份恢复为具有不同名称的新数据库，删除所有企业功能，然后再次备份数据库，并在较低版本上恢复该数据库。（在这种特定情况下，我在错误消息中留下了分区函数的名称，因为无论如何这似乎是一个可以丢弃的东西 - 它是由数据库引擎优化顾问创建的，并且可能是由不完全了解的人完成的知道他们在做什么。情况并非总是如此。）

(2) 的一个变体是只删除源数据库上的分区和其他功能，并进行另一个备份。但如果它没有坏...