从不同版本的备份文件还原数据库

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

有谁知道您是否可以从* .bak文件中为不同版本的SQL Server还原数据库？我们正在通过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)

从Developer到Enterprise都可以，只要确保您使用的是处理器许可，就可以在目标服务器上拥有可以覆盖所有CPU的许可。仅将它们从SQL中隐藏是不够的，如果它们物理连接到计算机，则您要对它们负责。

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

当然，你不能倒退。我从未尝试过像10.0.5512-> 10.0.5500这样的小规模降级，但是绝对不可能在Service Pack或版本中降级。因此，如果您在Developer Edition实例上有一个2012数据库，并且想在生产环境中将它放在您的2008实例上，那么您的工作就会变得很麻烦（请参见此处和此处）-特别是如果您使用了2012年的功能。

但是要涵盖可能使人们陷入此问题的其他情况（例如，某人想从开发人员->标准或企业-> Express或您拥有的东西中去）...

还有其他版本->版本升级效果不佳，例如从Developer-> Express，如果您使用了Express中不支持的任何功能（除Enterprise以外的任何版本也是如此）。您将无法在较低版本上使用的一些功能示例（在这种情况下，还原将在尝试使数据库联机时消失）：

• 分区
• 更改数据捕获
• 资料压缩
• 透明数据加密

我不知道是否有办法直接从.BAK文件中告诉这一点（我确定可以从某个地方的页眉中提取一些魔术，或者是否有一个周末可以用十六进制编辑器刻录） ，但是尽管数据库仍在源实例上完整无缺，但您始终可以执行以下操作来查看是否由于使用SKU而使用了任何可用功能：

SELECT feature_name FROM sys.dm_db_persisted_sku_features;

我不确定SQL Server Audit是否应列在该列表中-该功能的版本专有性已更改，因此它可能取决于您在使用该功能。您可能正在使用其他东西，但它们不会显示在DMV中（某些原因是因为它们在您的代码中，DMV无法解析），某些原因是您的数据库依赖于外部事物，例如SQL Server Agent ，服务经纪人等）：

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

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

当然，可能还有其他陷阱，您不会被警告-它们不会阻止迁移，但是它们可能导致目标设备的性能大不相同。例子：

1. 目标版本（甚至目标上的基础操作系统）的内存/ CPU限制不同。从2008 R2 Enterprise到2012 Enterprise（CAL）的人很多，那里的服务人为地限制在前20个内核中。这可能导致直接的性能差异（例如，内存不足以满足查询，或者并行查询性能大大降低）；更细微的选择包括由于底层硬件不同而做出的计划选择。
2. 在不更改要使用的源代码的情况下，将不会自动依赖目标（例如源上的索引视图匹配）之类的功能NOEXPAND。您甚至可能不知道此功能是查询突然变慢的原因。
3. 并行索引操作和现在可能不会想到的许多其他优化也是如此（非常感谢，我几乎只在企业级领域工作，因此在大多数情况下，我不必担心较低版本的局限性）。

根据此重复项进行更新：

在某些情况下，您尝试将数据库从某个版本还原到一个较低版本（即使在同一版本上），并且得到的错误不足以帮助您：

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

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

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

现在，这还不是很正确-您还可以还原到评估版或开发人员版，但这已不重要。为了还原此数据库，您基本上有两个选择：

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

（2）的一种变化是仅删除源数据库上的分区和其他功能，然后进行另一个备份。但是如果还没有破裂...

Developer和Enterprise是相同的软件，只是具有不同的许可协议。

您应该可以在目的地还原该数据库。