sql-server – SQL Server就地升级是否像过去那样不明智？

我目前正在将我的2008 R2 DEV和TEST系统升级到SQL Server 2012,并且需要使用相同的硬件.不必恢复我的报告服务配置的想法是非常有吸引力的,我真的很反对时间.没有涉及分析服务或任何异常或非标准 – 仅安装数据库引擎和报告服务.

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

解决方法

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

所以这是一个观点,并没有一定的错误或正确的答案,但我更喜欢迁移式升级,因为很多原因.话虽这么说 – 由于各种原因我的一些客户别无选择,只能做就地,而且自从SQL Server 2005以来,就地升级并没有像过去那样糟糕.

为什么我更喜欢迁移到就地升级

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

请注意,我并不是说你必须做这个迁移.就地工作,如果您没有计划在预算中购买新硬件并且无法为此升级做到这一点,则它可以正常工作.升级过程中的支持比6.5天好得多,所以你不会把自己置于糟糕的位置.

如果您计划为dev / test进行就地操作但是想要进行生产迁移,则可以考虑在生产之前至少进行一次迁移.通过这种方式,您可以提前制定清单并处理您没有想到的任何潜在问题.

附加/分离与备份/还原以进行迁移

如果您决定采用迁移方法,还有一个决定可能仍然存在争议,这就是您将数据库移动到新环境的方式.您可以从旧服务器分离数据库并将其附加到新服务器或备份它并在那里将其还原.

我更喜欢备份/恢复.我听说分离/附着的最大优点是节省了一些时间.对我来说,备份/恢复获胜的原因有以下几点：

>保持旧的可访问性 – 这允许您在源服务器上仍具有可访问的数据库.分离/连接应该做同样的事情,但它需要几个步骤,并且分离/连接存在人为错误的空间,这可能使此复杂化.
>您要保证您有备份 – 您不必仅从分离中获取数据库并且可能忘记备份步骤,而是确保您已经进行了备份.
>人为错误 – 如果删除了错误的文件,忘记发送内容的位置或者弄乱你的步骤,那么通过移动数据库的数据和日志文件会带来很大的风险.现在你可以通过复制而不是剪切来缓解这种情况(如果你做分离,你应该摆脱剪切和粘贴习惯)但你可能会陷入困境. SQL Server不再锁定这些文件,而且我很容易意外地删除文件以免冒险.
>实际上并不是那么慢 – 备份并复制它需要更多时间,但我愿意为此付出额外风险并不是那么多.实际上 – 使用完全恢复模型和日志备份,您可以将停机时间降低甚至更低,如下文“如何使迁移方法更快”中所述

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

如何使迁移方法更快

通过利用完整恢复模型,您可以最大限度地缩短从旧环境到新环境的切换所需的停机时间,从而使繁忙的生产环境几乎不会停机.基本上 – 通过恢复最新的完整备份,任何差异备份和任何已经采用的指定NORECOVERY的日志备份来暂存要迁移到的环境 – 然后您需要做的最后一次切换就是恢复尚未恢复的日志备份以及要恢复的最终日志备份,指定WITH RECOVERY.对于大型数据库,通过在停机时间窗口之前支付完整,差异和大多数日志恢复的成本,可以极大地减少实际的切换停机时间窗口.感谢Tao在评论中指出这一点！

如何使就地升级更安全

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

>备份 – 提前对您环境中的所有用户和系统数据库进行适当的备份并确保它们是好的(我是偏执的……我实际上会先将它们恢复到某个地方才真正知道它们很好……可能会浪费你的时间..但是,如果发生灾难,您可能会感谢自己).在该环境中编写有关SQL和OS安装的任何配置信息.
>在开始之前做好测试 – 确认您拥有良好的环境和良好的数据库.你应该做的事情就是查看错误日志并定期运行DBCC CHECKDB,但在进行就地升级之前是一个很好的开始时间.提前解决任何问题.
>确保操作系统健康 – 不要只确保SQL健康,确保服务器运行正常.您的系统或应用程序错误事件日志中的任何粗糙错误？你的自由空间怎么样？
>做好最坏的准备 – 前一段时间我有一个博客文章系列,其前提是如果你没有为失败做准备 – you are actually preparing to fail ..我仍然相信.因此,请仔细考虑您可能遇到的问题,并提前做出相应处理.让自己陷入“失败”的心态,你会想到你不会有的事情.

升级或迁移清单的重要性

如果您决定进行升级(无论是到位还是迁移),您应该认真考虑创建一个清单并在每个环境中使用此清单.你应该在这份清单中加入一堆东西,其中最重要的是：

>在开始时 – 做一些事情,比如执行测试升级,在最新的数据库兼容级别上测试应用程序,并考虑提前运行像SQL Server Upgrade Advisor这样的工具,看看在进行SQL Server升级之前需要完成哪些任务或迁移.
>预备步骤 – 清理,操作系统任务,提前修补,准备升级应用程序(清理关闭,连接字符串工作),备份等.
>升级/迁移步骤 – 升级或迁移所需的一切都要成功并按正确的顺序进行.安装,更改(或根据您的测试和方法不改变)兼容模式更改为数据库等.
>迁移后/升级步骤 – 各种测试,发布新版本或新服务器配置选项,最佳实践实施,安全性更改等.
>回滚步骤 – 您应该拥有回滚步骤和里程碑.如果你走得这么远,这会发生,你会怎么做？什么是“完全回滚”标准？你是如何进行回滚的(反向连接字符串更改,更改设置,返回旧版本,如果安装就重新安装,如果迁移则返回旧服务器等)

然后让生产升级的人员在生产以外的某些环境中遵循清单 – 特别是如果可能的话,关闭生产类似的生产(正如我所说,“生产的南方”),并注意任何问题或要点由于缺乏清单,他们不得不从清单转移或即兴发挥.然后将合并的更改合并到您的生产变更中.

我不能过分强调在迁移或升级之后彻底测试的重要性.在升级过程中做出回滚决定应该很容易 – 尤其是在迁移过程中.如果有什么不舒服的东西,如果你无法在迁移的热量中有效可靠地解决问题,请回滚并弄明白.一旦您在这个新环境中生活并且用户连接 – 回滚就变成了一项艰巨的任务.您无法将SQL Server数据库还原到早期版本.这意味着手动工作和数据迁移.我总是等待几个星期来杀死旧环境,但是你应该尽可能地避免在现场用户触摸新环境之前找到所有问题来避免需要旧环境.最好在你开始升级/迁移之前.

有关SQL Server Reporting Services迁移/升级的快速说明迁移SSRS安装并不是许多人认为的艰巨任务.这篇文章中最重要的警告之一是“备份加密密钥”,特别是如果您有大量已保存的敏感信息,如预定报告电子邮件收件人电子邮件地址,多个连接的连接信息,等一段时间你可以向我的一位客户询问这有多重要.他们知道,因为我搞砸了这一步,花了很多时间修改报表计划和连接字符串权限.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!