SQL Server 就地升级是否像过去一样不明智？

Question

自 SQL Server 6.5 以来，我一直在使用 SQL Server，但仍然萦绕在我脑海中的旧建议是永远不要进行就地升级。

我目前正在将我的 2008 R2 DEV 和 TEST 系统升级到 SQL Server 2012，并且需要使用相同的硬件。不必恢复我的报告服务配置的想法非常有吸引力，我真的很聪明。不涉及分析服务或任何不寻常或非标准的东西——只安装了数据库引擎和报告服务。

有没有人遇到过就地升级的严重问题？或者我应该重新评估我对就地升级的立场？

Answer 1

非常简短的回答- 就地就可以了。您可以随后查看您的配置并实施 SQL Server 2012 的最佳实践。

关于 SQL Server 升级/迁移的更长答案

所以这是一个意见问题，不一定有错误或正确的答案，但出于很多原因，我更喜欢迁移风格升级而不是就地升级。话虽这么说 - 我的一些客户出于各种原因别无选择，只能进行就地升级，而且自 SQL Server 2005 以来，就地升级并没有像以前那样糟糕。

为什么我更喜欢迁移而不是就地升级

• 更轻松的回滚- 如果出现问题，您可以通过简单地说“我们中止升级.. 请在我们解决此问题时将连接字符串更改为旧服务器”来回滚。使用原位，您正在修复它或您失败了。
• 刷新硬件- 硬件变化很快。通过就地升级，您很容易陷入 4 年前适合您公司但不适合今天和未来四年的硬件。无论如何，您可能必须在某个时候为新硬件进行迁移。
• 感觉更好- 当然......这个是主观的，但知道你开始安装新的操作系统，新的 SQL 安装感觉很好今天），这可能会在未来让你头疼。
• 新操作系统- 如果您今天没有使用最新和最好的操作系统，那么迁移让您有机会开始使用新的操作系统版本。
• 您可以对其进行测试- 在安装 SQL 并使用数据库和使用对其进行云计算之前，是否曾经想在新机器上获得一组基线？你现在可以这样做了。
• 有时更容易潜入最佳实践- 也许 SQL Server 服务帐户是本地管理员。也许内置管理员处于 SA 服务器角色中。也许之前的事情已经被黑客攻击过以使其正常工作。您可以解决所有问题并重新开始。
• 免费的测试环境和额外的睡眠- 当您使这个新环境生效时，拥有一个可以在实际转换日之前工作的环境是一个很大的好处。迁移到新环境意味着您可以在工作时间构建它，远早于实际切换日，并提前以多种方式对其进行测试。您可以在所有应用程序和系统上运行完整的回归测试数天，并且在您实际执行最后一组还原/附加和切换所有应用程序并访问新环境之前，可以高枕无忧。
• 您不必一次完成所有操作- 我遇到的一个非常常见的情况是尝试将环境合并为几个实例。也许每个版本一个，也许每个“层”和版本一个。许多这些项目根据测试、项目计划和供应商认证的及时性，对各种应用程序和数据库有不同的时间表。进行迁移意味着您可以移动那些准备好的数据库，当它们准备好时，仍然可以处理那些由于某种原因而无法移动的数据库的请求。

请注意，我并不是说您必须将其作为迁移来执行。就地工作，如果您不打算在预算内购买新硬件并且无法为这次升级做到这一点，那么它工作得很好。升级过程中的支持比 6.5 天时要好得多，因此您不会因此而陷入困境。

如果您确实计划为开发/测试进行就地迁移，但想要为生产进行迁移，您可能会考虑在生产之前至少进行一次迁移。通过这种方式，您可以提前制定检查清单并处理您没有想到的任何潜在问题。

附加/分离与迁移的备份/恢复

如果您决定采用迁移方法，那么还有一个决定您可能仍有争论，那就是如何将数据库迁移到新环境。您可以将数据库与旧服务器分离并将其附加到新服务器，也可以备份并在那里恢复。

我更喜欢备份/恢复。我听说分离/附加的最大优点是它可以节省一些时间。对我来说，备份/恢复获胜有几个原因：

• 保持旧的可访问- 这允许您在源服务器上仍然有一个可访问的数据库。detach/attach 应该做同样的事情，但它需要几个步骤，并且 detach/attach 存在人为错误的空间，这可能会使这变得复杂。
• 你保证你有一个备份——而不是仅仅从分离中获取一个数据库并可能忘记备份步骤，你已经确保你已经进行了备份。
• 人为错误- 如果您删除了错误的文件、忘记了发送内容的位置或以其他方式弄乱了您的步骤，则为您的数据库移动数据和日志文件会带来很大的风险。现在你可以通过复制而不是剪切来缓解这种情况（如果你真的分离了，你应该摆脱剪切和粘贴的习惯），但你仍然可以搞砸。SQL Server 不再锁定这些文件，而且很容易意外删除文件，我冒着风险。
• 这是不是真的是慢-以一个备份和复制它是多一点的时间，但它不是那么多，我愿意支付额外的风险吧。事实上 - 使用完整恢复模型和日志备份，您可以将停机时间降低到更低，如下面的“如何加快迁移方法”中所述

如果您决定进行备份/恢复 - 这意味着您的旧源数据库仍将在线。我喜欢在备份后将该数据库脱机。在编写安全性、作业、链接服务器、证书、数据库邮件设置和其他实例范围的信息后，有时我会更进一步，使整个 SQL 实例脱机。这避免了在测试期间有人说“一切看起来都很棒！”的问题。一两天后才意识到他们一直在与旧服务器上的旧数据库交谈。使这些数据库脱机或整个实例脱机可以防止这些误报和它们造成的混乱。

如何使迁移方法更快

通过利用完整恢复模型，您可以将繁忙的生产环境从旧环境切换到新环境所需的停机时间降至最低，停机时间很少。基本上 - 通过恢复最新的完整备份、任何差异备份和任何已指定的日志备份来暂存您要迁移到的环境NORECOVERY- 然后您为最终切换要做的就是恢复尚未恢复的日志备份和您希望恢复的最终日志备份指定WITH RECOVERY. 通过这种方式，对于大型数据库，可以通过在停机时间窗口之前支付完整、差异和大多数日志恢复的成本来极大地减少实际切换停机时间窗口。感谢陶在评论中指出这一点！

如何使就地升级更安全

在选择就地方法时，您可以采取一些措施来改善体验和结果。

• 备份- 提前对您环境中的所有用户和系统数据库进行适当的备份，并确保它们是好的（我很偏执.. 我实际上会先在某个地方恢复它们以真正知道它们是好的.. 可能是在浪费您的时间。 . 但是，如果发生灾难，您可能会感谢自己。.. 在该环境中编写有关 SQL 和 OS 安装的任何配置信息的脚本。
• 在开始之前先测试一下- 确认您拥有良好的环境和良好的数据库。您应该做一些事情，例如查看错误日志和定期运行 DBCC CHECKDB，但在进行就地升级之前是开始的好时机。提前解决任何问题。
• 确保操作系统健康- 不要只是确保 SQL 是健康的，还要确保您的服务器是健康的。您的系统或应用程序错误事件日志中是否有任何严重错误？你的空闲空间怎么样？
• 准备最坏的-我有一个博客帖子系列前一段时间说的前提是，如果你不准备去失败-你实际上是准备要失败。我仍然相信这一点。因此，请仔细考虑您可能遇到的问题并提前相应地处理它们。让自己陷入“失败”的心态，你会想到其他情况下不会有的事情。

升级或迁移清单的重要性

如果您决定进行升级（无论是就地升级还是迁移），您应该认真考虑创建一个清单并在每个环境中使用这个清单。您应该在此清单中包含很多内容，其中最重要的是：

1. 开始时- 执行一些操作，例如执行测试升级、在最新的数据库兼容性级别上测试您的应用程序，并考虑提前运行SQL Server Upgrade Advisor 之类的工具，以查看在执行 SQL 之前需要完成哪些类型的任务服务器升级或迁移。
2. 准备步骤- 清理、操作系统任务、提前修补、为升级准备应用程序（干净关闭、连接字符串工作）、备份等。
3. 升级/迁移步骤- 您必须按照正确顺序成功升级或迁移的所有步骤。安装、更改（或不更改，取决于您的测试和方法）对数据库的兼容性模式更改等。
4. 迁移/升级后步骤- 各种测试、发布新版本或新服务器配置选项、最佳实践实施、安全更改等。
5. 回滚步骤- 在整个过程中，您应该有回滚步骤和里程碑。如果你走到这一步并发生这种情况，你会怎么做？什么是“完全回滚”标准？以及如何进行回滚（反向连接字符串更改、更改设置、返回到旧版本、如果到位重新安装、如果迁移则指向旧服务器等）

然后让将要进行生产升级的人在生产以外的其他环境中遵循清单 - 特别是如果可能的话，关闭类似于生产的环境（“生产南部”，正如我所说的......）并注意任何问题或要点由于检查表的缺失，他们不得不从检查表中转移或即兴发挥。然后合并更改并享受您的生产更改。

我不能过分强调在迁移或升级后以及在迁移之前进行彻底测试的重要性。在升级过程中做出回滚决定应该很容易——尤其是在迁移期间。如果有什么不舒服的地方，请回滚并找出是否在迁移过程中无法有效和可靠地对其进行故障排除。一旦你在这个新环境中生活并且用户连接 - 回滚成为一项艰巨的任务。您无法将 SQL Server 数据库还原到早期版本。这意味着手动工作和数据迁移。我总是等待几周来终止旧环境，但您应该尽一切努力避免需要旧环境，在您的实时用户接触新环境之前找到所有问题。最好在您开始升级/迁移之前。

关于 SQL Server Reporting Services 迁移/升级的快速说明 迁移 SSRS 安装并不是许多人认为的一项艰巨的任务。这篇技术网/在线书籍文章实际上非常方便。该文章中最重要的警告之一是“备份加密密钥”，尤其是如果您保存了大量敏感信息，例如预定报告电子邮件收件人的电子邮件地址、多个连接的连接信息等。可以问问我的一位客户前一段时间这有多重要。他们知道是因为我把那一步搞砸了，花了很多时间修改报告计划和连接字符串权限。

Answer 2

根据我的经验，应该像以前一样做出相同的决策过程。AFAIK 在安装 SQL Server 时，在 MS SQL Server 产品本身中没有任何“世界改变者”，以及在推出具有数百万行代码的软件时遇到的潜在问题。可能会发生一些不好的事情，现在您无法使用“回滚”选项。

但是，您确实有其他选择。您可以考虑制作系统快照，在其他地方还原，执行升级并查看会发生什么。这个测试应该会给你很大的安慰，但它并不能绝对保证 prod box 不会出现问题。但是，这是一个在 SQL 6.5 天内不可用的选项。

我只会假设最坏的情况。您进行了就地升级，但它失败了。然后，您必须在 RTO 和 RCO 中从中恢复。企业是否了解风险，您是否制定了减轻风险的计划？

如果企业对此不满意，那么不要这样做是我的建议。