并不是所有的SQL服务器升级都需要复杂的计划和大量的工作。有时，你可以使用一些简单的方法来升级SQL Server，在升级过程中，你并不会因为方法简单而损失什么，而节省下来的时间，你还可以用来进行下一步的计划。然而，如果你想要简化升级过程，你必须知道在什么时候流程简化对你来说安全可靠的，以及何时你必须付出额外的努力，这是至关重要的。
本文的目的是为你提供一个框架，有了它，你就可以较为容易地在数据库升级过程中，确定所需的工作量，以及需要多少资源等。
SQL Server 升级的分类
要确定升级所付出的努力和需要消耗的成本，你有很多因素需要考虑。在本文中,我们将讨论一些最常见的问题。当然，还有其他有助于判断SQL服务器升级所需付出成本的因素，但本文讨论的因素是***有代表性。
第三方应用程序。在许多企业中，大多数的数据库是通过独立软件供应商(isv)购买的，他们提供标准流程，以帮助用户将SQL Server升级到***版本。如果你想升级来自第三方ISV的数据库，遵循供应商规定的升级策略是***的做法。它能够帮助你预先确定升级需要多大的工作量。
任务关键型应用程序。任务关键型应用程序需要更为健壮的升级计划和更多的测试工作。对于较小的应用程序，付出的工作量应该相应减少，因为升级造成功能受损的风险较低，且恢复所需的工作相对较少，对业务影响也不会很大。这个因素与当前数据库架构是否具有高可用性以及是否具有灾难恢复组件等条件密切相关。如果答案是肯定的，那我们可以预料到，尽可能缩短停机时间是至关重要的。这增加了升级计划的准备时间和升级本身的测试时间。
临时SQL。当应用程序运行在一个数据库上，它生成大量的SQL查询，且这些查询并没有嵌入在存储过程中时，升级所需的工作量将增加。类似微软的内置的Upgrade Advisor之类的工具，将会检查数据库本身的元数据，包括存储过程和其他数据库对象。不仅如此，Upgrade Advisor还有其他作用，因为它可以检查临时SQL语句追踪文件。通常遇到的问题，可以通过捕获和分析特定跟踪文件来解决，这些文件提供了较为广泛的SQL代码覆盖率。
大型数据库。在这种情况下，大的定义是相对主观的。例如，10年前，1 TB的数据库被认为是大型数据库，但在如今这已司空见惯。以gb或tb为单位的数据以及数据库对象的数量会影响升级数据库的时间，如果需要回滚，也会影响回滚完成的时间。
副本。这不会影响所有数据库使用者，但如果在你的数据库环境中有SQL Server副本，副本组件的升级顺序是至关重要的，这与升级过程的持续性同样重要。副本在升级过程中可能会成为系统处理的一个主要因素，以何种顺序完成升级，将会影响你所需要的工作量。
图1：用于确定升级过程所需工作量的决策树
升级项目分类
一旦你考虑到各种因素，你可以根据SQL Server升级项目涉及的因素将其进行分类。这里有几种类型的升级项目，以复杂度从高到低排列;它们之间的关系，以及与各种因素之间的联系，如图1所示。
复杂升级。这是一种升级的类型，它需要在计划和执行方面付出了大量的努力。确保尽可能的考虑多种情况，并在升级中不断的测试是至关重要的，为了减少数据库和应用程序升级时的停机时间。这些升级项目往往会给项目人员带来很大压力，它们需要付出额外的努力，以确保升级的成功。通常，会有正式的项目计划和管理流程，以协调企业内部的工作安排，包括一个升级过程中的测试，以及升级失败的回退计划，以备不时之需。
基本升级。这种类型的项目会考虑到一些基本的测试，但它通常不需要部署团队来亲自完成这些测试。如果由他们完成，在涉及到任务关键型应用程序时，将依然需要很多的工作，而且这需要采取合理的预防措施。至少，这包括升级之前对数据库的备份，以及创建一个可靠的回退计划。
有回退计划的非关键升级。这种类型的升级过程用于那些在自身领域十分重要的数据库，这些数据库并不涉及关键业务和监管合规问题。此类情况下，数据库升级时，如果需要，退回计划将被执行。
供应商指导下的升级计划。这也许是最常见的SQL服务器升级项目。有时候，这样的升级就是供应商对用户说我们现在支持新版本，就像一句话这么简单，但它也可能更为复杂。例如，如果你的前端程序连接到了数据库的后端，你可能需要将前端应用程序升级到新版本。不同的供应商，细节可能会有很大不同。在企业内部，你可以把它当做一个基本升级项目来看待。
随着数据库升级项目类型的确定，你还需要内部应用程序所有者对计划的签字认可。根据工作安排，设定升级预期，估计升级所带来的效益。对于所有类型的数据库升级，你要确保至少从Upgrade Advisor开始你的升级过程，并及时修复发现的问题。在没有进行基本的审查前，不要开始升级任务。
