主页 / dba / 问题 / 33870
Accepted
MacGyver
Asked: 2013-01-31 13:06:13 +0800 CST

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

  • 772

我读到，出于向后兼容性的原因，只要您从旧版本恢复到新版本，就可以在 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)
sql-server compatibility-level

2 个回答

  1. Best Answer

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

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

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

    但是要涵盖可能使人们遇到此问题的其他情况（例如，有人想从开发人员-> 标准或企业-> Express 或您有什么）...

    如果您使用了 Express 中不支持的任何功能，则还有其他版本 -> 版本升级不会那么顺利，例如从 Developer -> 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. 并行索引操作也是如此，可能还有很多其他优化，这些优化目前没有想到（谢天谢地，我几乎只在企业领域工作，所以在大多数情况下我不必担心低版本的限制)。

    基于此副本的更新：

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

    服务器“服务器\实例”的 RESTORE 失败。
    RESTORE 无法启动数据库“databasename”。

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

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

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

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

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

    • 15

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

    您应该可以在目的地恢复此数据库。

    • 3

相关问题