常用的SQL Server升级方法

对比原文有删改，原文请参考最下方链接

一、选择SQL Server升级方法

1. 问题

您计划将SQL Server升级到最新版本。您会选择哪种SQL Server升级方法？有许多选项可供选择，其中一些选项在您的业务设置中有意义，而其他选项则不然。有哪些不同类型的升级方法，我应该选择哪一种？

2. 解决方法

您选择升级SQL Server的方法归结为两个业务目标：尽可能少的停机时间或者最少的花费；或者您两者都需要：更便宜，更快捷。

您可以通过多种方式升级SQL Server。您选择的方法取决于您愿意承担多少风险。例如，一种方法可以更快地升级系统，而不会对数据造成太大风险，并节省应用程序停机时间；这意味着您节省了时间，但您需要在硬件和许可成本上花费更多。另一种选择提供了更便宜的解决方案，也可以更快，但风险是，如果出现任何问题，你无法回滚。一个是昂贵的，另一个更便宜但风险更高。一个需要大量应用程序中断而另一个不需要。

每种方法都有利弊，因此根据您的业务情况选择正确的升级方法非常重要。

以下是业界用于升级或迁移SQL Server实例的最常用选项：

1) 备份还原

2) 附加和分离

3) 就地升级

4) 大型数据库的差异还原

5) 并排升级（无高可用性）

6) 滚动升级（具有高可用性）

3. SQL Server升级 vs 迁移

首先区别一下SQL Server中的迁移和升级术语。我已经看到这些术语被互换使用。但是它们有一些不同之处。

1) 升级SQL Server可能意味着您：

只升级Edition 的SQL Server。也许您正在从SQL Server 2014标准版（SE）升级到SQL Server 2014企业版（EE）。
只升级SQL Server version。例如从SQL Server 2012（EE）SP4升级到SQL Server 2016（EE）SP2。
升级Edition 和version。如果要从SQL Server 2012（SE）升级到SQL Server 2017（EE），则会出现这种情况。
此外，每当您将Service Pack（SP）或累积更新（CU）作为常规维护的一部分应用于SQL Server时，您实际上正在进行小型升级。

2) 迁移可能包括也可能不包括SQL Server的升级，但这意味着将数据库从一个SQL Server实例移动到另一个实例。

也许您只是在进行SQL Server的硬件和操作系统刷新
或者一个SQL Server实例上可能存在太多数据库，并且维护作业执行与业务时间重叠，您想分割负载。
您可能同一VM计算机上启动了多个SQL Server实例需要申请新的VM安装SQL Server并将一些并移动到新实例。
它还可能意味着您正在将数据库从本地迁移到云，例如Azure。最后，迁移还可以包括升级SQL Server。

简而言之，升级是指SQL Server实例升级，这将导致用户和系统数据库的升级。升级可以是数据库迁移的一部分。另一方面，迁移是指在SQL Server的同一版本\版本或升级的版本\版本的SQL Server上的SQL Server实例之间移动数据库。

下面我们讨论上面列表中的提到的升级方法。

二、使用备份和还原进行SQL Server升级

这是迁移期间升级数据库的最基本，最简单的方法。通常，这种升级方法是50 GB以下的数据库的理想选择，具体取决于虚拟机（VM）上的资源。

1. 场景

您计划将SQLDev实例从SQL Server 2012（Developer Edition）升级并迁移到SQL Server 2016（Developer Edition）。您的SQLDev实例上有10个Dev数据库。您想要将他们升级到新的实例SQL2016上。VM计算机名称为SQLVM1。您在SQLVM1\SQL2016上安装了SQL Server 2016（DE）。每个dev数据库都小于50 GB。您选择使用“备份和还原”方法进行升级。

2. 执行

在这里，我们采用非常简单的方法，并跳过计划任何升级项目的许多细节。由于这是一个开发环境，应用程序停机时间不是问题。这些是我们将用于迁移和升级dev数据库的最小步骤。

在升级之前创建作业“Do Backup”，使用脚本备份SQLVM1\SQLDev实例上的每个数据库。

BACKUP DATABASE [Db1] TO DISK = N'C:\MSSQL\SQLBackups\Db1.bak'

GO

BACKUP DATABASE [Db2] TO DISK = N'C:\MSSQL\SQLBackups\Db2.bak'

GO

在升级之前创建作业“Do Restore”，使用脚本还原SQLVM1\SQL2016实例上的每个数据库。

RESTORE DATABASE [Db1] FROM  DISK = N'C:\MSSQL\SQLBackups\Db1.bak'

GO

RESTORE DATABASE [Db2] FROM  DISK = N'C:\MSSQL\SQLBackups\Db2.bak'

GO

在SQLVM1\SQLDev上运行“Do Backup”作业备份数据库。

在SQLVM1\SQL2016上运行作业“Do Restore”以还原数据库。

验证成功后，卸载SQL Server 2012实例SQLVM1\SQLDev。将SQLVM1\SQL2016实例重命名为SQLVM1\SQLDev。

EXEC master.sys.sp_dropserver @server = 'SQLVM1\SQL2016 ';

GO

EXEC master.sys.sp_addserver @server= 'SQLVM1\SQLDev', @local = local;

GO

SELECT @@SERVERNAME

三、使用分离和附加数据库进行SQL Server升级

这是在迁移期间升级SQL Server数据库的另一种基本且简单的方法。它不是推荐的最佳实践方法。基本上，它与“备份和还原”方法完全相同。对于较小的数据库，使用“备份和还原”进行升级更加安全可靠。

1. 场景：

您的数据库实例SQLQA位于非常旧的物理计算机上，您希望回收该计算机。实例中有8个QA数据库，大小小于30 GB。应用程序停机时间并不重要，但您必须在1个工作日内完成。您选择使用Detach and Attach方法。希望将SQL实例移动到基础架构团队创建的新VM，SQLVM2。您不想升级SQL Server Version 或 Edition。

2. 执行：

同样，我们省略了成功迁移的许多步骤，以保持示例简单。这些是我们需要采取的最低步骤。

1) 在SQLVM2计算机上安装SQL Server实例SQLQA2。

2) 对SQLQA上的每个数据库执行Detach命令。

USE [master]

GO

ALTER DATABASE [DB1] SET  SINGLE_USER WITH ROLLBACK IMMEDIATE

GO

EXEC master.dbo.sp_detach_db @dbname = N'DB1'

GO

3) 将.mdf，.ndf和.ldf文件复制到SQLVM2计算机上的新位置。

4) 对SQLVM2\SQLQA2实例上的每个数据库运行Attach命令。

USE [master]

GO

CREATE DATABASE DB1

    ON (FILENAME = 'C:\SQLBackups\DB1_Data.mdf'), (FILENAME = 'C:\SQLBackups\DB1_Log.ldf')

    FOR ATTACH;

5) 验证成功迁移后，关闭物理服务器SQLQA并在适当的时间后停用它。

这不是推荐的迁移数据库的方法，因为您可能会遇到各种类型的问题。例如，如果源SQL Server与目标SQL Server之间存在SQL Server排序规则差异，则attach命令可能会失败。如果在新服务器上复制数据库文件的目录没有SQL Server服务帐户的适当权限，则可能会失败。另一个重要原因是，如果在分离数据库并尝试附加之间的时间已经过了一两天，文件可能被误删除。如果服务器重新启动，文件可能会损坏。

---------------------------------------------------------------------------------------------------------------------------------------

1. 问题

为SQL Server升级或迁移项目选择升级方法并不容易。这取决于您环境中的许多因素，它必须是业务团队和技术团队的综合决策。假设您的数据库大于50 GB，并且您还有预算限制。在这种情况下，哪种升级SQL Server的方法是合适的？

2. 解决方法

在前面的部分，我们讨论了可以进行数据库迁移和/或升级的不同方法。我们使用一些业务场景研究了两种最基本的数据库迁移方法; 备份和还原方法以及分离和附加方法。我们还讨论了SQL Server环境中升级与迁移定义的差异。

在这篇文章中，我们将介绍另外两种SQL Server升级方法。

就地升级
大型数据库的差异还原

四、就地升级

此方法不能用于迁移，因为所有操作都发生在同一服务器上，因此称为“就地升级”。这是最便宜、最快但却最危险的升级方法，因此不建议您在生产SQL Server使用。

由于是直接升级现有SQL实例，如果出现任何问题，您将无法回滚（打快照？？）。所有系统和用户数据库的系统对象都会升级，唯一的选择是使用旧的SQL Server版本以及完全相同的Service Pack和累积更新来恢复不同服务器上的数据库备份。预算较低且无法花钱购买硬件和软件许可证的公司将选择这种方法，但是在升级失败的情况下，返回旧版本将花费更多，并且还需要更多时间。另一个警告是，在就地升级期间，您无法添加其他SQL Server功能，只能在安装完成后进行。

1. 场景：

让我们举一个XYZ技术公司的例子。该公司正在与其供应商就其新产品进行概念验证。为此，他们需要在SQL Server 2012，SQL Server 2014和SQL Server 2016上测试供应商应用程序。XYZ技术的资源有限，因此他们决定首先安装SQL Server 2012并安装所有供应商工具数据库并完成测试。然后进行就地升级到SQL Server 2014并执行相同的测试并重复使用SQL Server 2016。

2. 执行：

此方法可以节省XYZ公司执行数据库备份和还原的时间。使用此方法，无需编写登录，作业和链接服务等脚本。如果在其中一个升级过程中出现问题，他们不关心，他们将重建服务器重新开始。

您将至少执行以下步骤。

1) 将所有Windows更新\修补程序应用于现有Windows服务器

2) 安装SQL Server 2012和所有Service Pack

3) 连接到供应商工具，它会创建所有必需的数据库

4) 运行测试

5) 运行SQL Server 2014安装向导，然后选择就地升级的选项。你会看到几个告警

6) 应用所有Service Pack

7) 更改数据库兼容级别

8) 运行测试

9) 运行SQL Server 2016安装向导并选择就地升级的选项，忽略告警

10)应用所有Service Pack

11)更改数据库兼容级别

12)运行测试和文档

与此示例一样，可能存在一些就地升级方法的其他用例，但它们很少。大多数情况下，您可以在测试环境中执行此操作，以查看不同版本下不同SQL Server功能的工作方式。

五、差异还原升级

1. 场景：

假设您在简单恢复模式下有一个大型数据库，比如说500 GB。您可以在周日晚上每周进行一次完整备份，并在其他6晚进行差异备份。此数据库位于SQL Server 2012（源）上，您有另一个具有SQL Server 2017实例（目标）的SQL Server，并且希望升级和迁移此实例。这两个SQL Server位于不同的数据中心。两个数据中心之间的网络带宽为10 GB。进行迁移的唯一可用窗口是星期六早上，期望在2小时内完成迁移并随后进行测试。

2. 执行：

1) 您是一名勤奋的DBA，您在实际迁移前几周进行了测试。这是一周测试备份，复制和恢复的方式。您的计划是在实际迁移之前尽可能多地完成工作。

每周备份和还原信息
星期几	备份时间	备份类型	备份大小	备份持续时间	复制持续时间	恢复持续时间
星期日	晚上11点	全备	500 GB	5小时	2小时	6小时
星期一	晚上11点	差异备份	50 GB	30分钟	20分钟	35分钟
星期二	晚上11点	差异备份	60 GB	35分钟	22分钟	42分钟
星期三	晚上11点	差异备份	70 GB	40分钟	24分钟	49分钟
星期四	晚上11点	差异备份	80 GB	50分钟	26分钟	56分钟
星期五	晚上11点	差异备份	90 GB	55分钟	28分钟	63分钟
星期六	晚上11点	差异备份	100 GB	60分钟	30分钟	70分钟
维护窗口
星期几	开始时间	时间结束
星期六	8:00 AM	10:00 AM

2) 设置一个文件复制作业以在星期日晚上的完整备份作业之后运行，将备份文件复制到目标服务器。星期一早上，您验证目标服务器上的备份文件是否可用。

3) 星期一晚上在目标服务器上以no Recovery 模式还原备份。

4) 从星期二到星期五，利用作业复制备份文件到目标服务器并以no Recovery 模式还原差异备份。

5) 星期六上午7点，维护窗口前一小时，在源服务器上启动数据库的最后一次差异备份。由于您已经精心计算，因此您可以完美地计时并且备份在上午8点结束。立即将数据库设置为只读，这样您就不会丢失任何数据。您的维护窗口已经开始，您有2个小时的时间来完成工作。

6) 手动将最后一个差异备份文件复制到目标服务器并使用Recovery模式还原。

7) 将兼容模式更改为最新，并将数据库升级到新的SQL版本。

8) 您已将应用程序连接指向了此升级的数据库。测试了您的应用程序。

9) 在2小时内完成您的任务，应用程序在新的数据库后端上线。

10) 在目标服务器上启动全备作业。

这种使用差异还原的方法在复杂性较低但数据库很大的情况下工作很简单。其他升级方法（如“备份和还原”和“分离和附加”）将无法正常工作，因为它们无法满足应用程序2小时停机时间的SLA。

关于回滚策略，在步骤＃8中，如果应用程序测试失败，您只需将源服务器上的数据库更改回读写模式。

六、 使用日志传送并行SQL Server升级

1. 问题

您的业务正在增长，您的数据库和应用程序复杂性也在增长。花时间升级或迁移数据库变得越来越难。客户希望在发生灾难时，他们的应用程序应在几小时内可用。您的雇主现在正在赚钱，他们可以在关键数据库的灾难恢复和业务连续性基础设施上花一些钱。在这种情况下，哪种SQL Server升级方法更有意义？

2. 解决方法

在这篇文章中，我们将介绍一些高级升级方法。并排升级涉及在同一台计算机或不同计算机上升级SQL Server。对于新的SQL实例在同一台计算机上的情况，请检查新SQL Server的文档以查看它是否支持现有的操作系统。例如，SQL Server 2016和2017不支持Windows Server 2008或2008 R2。

3. 使用日志传送并排升级SQL Server

日志传送从一开始就在SQL Server中可用（或者至少从SQL Server 7.0就开始），这种方法已经存在了20多年，并且仍然被世界各地的各个行业广泛使用，作为主要的灾难恢复解决方案。

Log Shipping的概念非常简单。有一对主服务器和辅助服务器。主服务器上的SQL Server数据库可用于所有用户的所有读写活动。来自主数据库的事务日志通过SQL Server代理作业继续得到应用，到辅助服务器上的辅助数据库。辅助服务器上的数据库可以处于以下两种模式之一：待机模式或无恢复模式。待机模式允许将此数据库用作只读副本，并用于报告目的以及应用其他事务日志的功能。No Recovery模式不允许读取辅助数据库。辅助数据库将处于还原状态，并且可以对其应用其他事务日志。

4. 场景：

您有2个SQL 2012企业版（EE）服务器：SQL1在Domain1中是primary，而SQL2在Domain2中是secondary。这两台服务器上的操作系统是Windows Server 2012 R2。SQL1到SQL2的数据库DB3（大小为500 GB）设置了事务日志传送。

DB3当前使用数据库压缩和数据库快照功能，这些功能仅在SQL Server 2012的EE中可用。企业希望将这些企业版（EE）2012 SQL Server升级到标准版（SE）SQL Server 2017以节省许可成本。还希望利用SQL Server 2017中的一些新功能，例如时态表和行级安全性。自SQL Server 2016 SP1以来，Microsoft已在SE中提供了许多EE级功能。升级到SE SQL Server 2017后，DB3仍然可以使用压缩和数据库快照功能，并且不需要其他配置。

5. 执行：

您决定使用当前日志传送设置进行并排升级。当前的Windows操作系统（Windows Server 2012 R2）支持SQL Server 2017，因此您无需升级操作系统。您计划首先升级SQL2。如果出现任何问题，您的回滚计划是将您的应用程序连接回SQL Server 2012实例SQL1上的数据库DB3。

当前的生产环境日志传送简图：

在您的研究过程中，您发现SQL Server 2012 EE无法升级到SQL Server 2017 SE，因为您从较高edition 的SQL Server降到较低edition 。您决定在具有SQL Server 2017 SE版本的Domain2中安装另一个SQL3实例。

以下是使用SQL Server日志传送升级和/或迁移数据库的一般步骤：

1) 关闭主（SQL1）和辅助（SQL2）服务器上的日志传送作业。

2) 在SQL1上，使用NoRecovery 对DB3的最后一个事务日志进行备份。使用No Recovery选项进行日志备份时，它会将DB3数据库置于还原模式，并且没有用户可以连接到它。

BACKUP LOG [DB3] TO DISK = 'C:\SQLBackups\DB3.trn' WITH NORECOVERY;

3) 手动在SQL2上运行复制和还原作业以确保应用所有日志。

4) 然后手动复制您对DB1进行的最后一次日志备份，并使用with Recovery选项在SQL2 DB3上手动将其还原。当您使用with recovery应用日志时，DB3在SQL2上online 。

RESTORE LOG DB3 FROM DISK = 'C:\SQL2012\SQL2\LogShip\DB3.trn' WITH RECOVERY

5) 在SQL2上完整备份DB3。

6) 在SQL3上还原DB3。由于SQL2和SQL3位于同一服务器上，因此您无需复制备份文件。这将节省相当多的时间。

7) 将DB3兼容级别更新为140。

USE [master]

ALTER DATABASE [DB3] SET COMPATIBILITY_LEVEL = 140

8) 将应用程序连接到SQL3.DB3并进行测试。SQL3现在是您的新primary实例。注意：在SQL1上执行DB3的最后一次日志备份时，将停止启动，因为使用“无恢复”选项的日志备份将使数据库在SQL1上处于还原模式。成功将应用程序连接到SQL3.DB3时，停机时间结束。

9) 升级成功完成后，您可以在此处停止。但是，如果要创建日志传送，请执行以下后续步骤。

10)在Domain1中安装SQL Server 2017实例SQL4。这是一个新的辅助SQL Server。

11)创建从SQL3到SQL4的事务日志传送。下面的文章详细介绍如何设置事务日志传送。

12)卸载SQL1和SQL2实例。

以下是使用Log Shipping, 特别是升级的一些优点和缺点，。

1) 大多数数据可以预先移动到目标SQL Server，因此在实际数据迁移切换发生时需要更少的停机时间。如果数据库非常大，并且源和目标SQL实例位于不同的域中，这将特别有用。

2) 与同一服务器上的就地数据库升级相比，您有了一些应急计划。旧主数据库上的数据库仍处于还原状态。因此，如果辅助数据库的升级不顺利，则可以通过将应用程序连接回旧数据库版本来回滚。要使旧数据库联机，您只需发出以下命令：

RESTORE DATABASE [DB3] WITH RECOVERY;

3) 日志传送的辅助数据库是生产数据库的只读副本，在那里运行报告查询等。它可以缓解主数据库的资源压力。

4) 一个主数据库可以有多个辅助服务器。升级一个辅助数据库后，它可以作为其余辅助服务器的主数据库。

5) 没有自动故障转移，您必须手动执行它。

6) 一些应用程序停机是不可避免的。

7) 使用日志传送需要另一个SQL Server，因此需要额外的硬件和许可成本。

8) 必须为每个数据库设置事务日志传送。如果您有超过20个数据库，它将变得乏味。在这种情况下，对于大于50 GB的数据库，请使用“日志传送”。对于小于50 GB的数据库，请使用“备份和还原”升级方法。50 GB不是Microsoft设置的数字。根据我的经验，这是一个很好的分界线。

6. 摘要

在这篇文章中，我们介绍了如何使用Log Shipping升级SQL Server。我们看到虽然日志传送很容易设置，但它仍然需要应用程序停机时间。仔细规划和提前准备可以缩短升级过程。我使用了非常简单的例子来说明这些概念。但是这些学习要点可以应用于任何真实的升级情况。

七、最大限度地减少SQL Server升级的停机时间

1. 问题

贵公司的业务是需要每年24x7x365天正常运行的数据库。在构建可靠的基础架构方面投入了大量资金，在VM主机级别和网络级别具有大量冗余。他们要求您（SQL Server DBA）确保数据库服务器是冗余的，并且您可以在不到5分钟的时间内完成Windows修补和SQL Server升级。您必须向您的老板提供解决方案，以便将来在新版本发布时升级SQL Server，而无需停止任何应用程序。

2. 解决方法

这是正在进行的SQL Server升级方法系列的第4部分。基本上，您被问到的是如何让您的数据库处于高可用性（HA）模式。您必须选择满足您的业务RPO（恢复点目标）和RTO（恢复时间目标）的技术。

3. 并排升级 vs 滚动升级

1) 并排升级涉及2个（或以上）SQL实例。这两个实例可以位于同一个VM主机上，也可以位于不同的主机上。一个实例具有最新的SQL Server。您停止旧SQL Server上的应用程序，备份并还原数据库（或使用日志传送）到新实例，然后将应用程序连接到新的SQL实例。这被称为并排升级，因为数据库的旧实例和新实例都可用。涉及应用程序停机时间，并且需要在目标服务器上编写脚本等。此方法的优点是，如果由于某种原因升级出错，您可以将应用程序连接回旧实例。缺点是应用程序需要停机时间。

2) 滚动升级方法也需要至少2个SQL Server实例。升级前，主服务器和辅助服务器始终保持同步。可用性组（AG）是进行滚动升级的一种方法。通过使用此升级方法，您的应用程序始终可用。这也意味着用户，作业，链接服务器等在辅助服务器上都可用并准备就绪。该应用程序还配置为自动检测主数据库。当您的应用程序连接到主节点时，进行辅助节点升级。只要辅助SQL version 与主节点相同或更高，事务就会从主节点流向辅助节点，不过事务将在辅助服务器上排队，直到升级完成。在这种情况下，您可以使用异步/手动AG模式，因为您不希望在升级过程中自动进行故障转移。

当辅助程序完成升级时，确保应用所有事务（将辅助模式更改为同步模式）并且两个数据库都处于同步状态，然后手动故障转移到辅助实例。此步骤可确保故障转移期间零数据丢失。角色立即更改，升级后的辅助节点承担主节点的角色，应用程序开始使用它并开始将数据发送到旧主节点（新的辅助节点为异步模式）。旧的主节点的事务在其SQL version 与新的主节点相同之前不会应用。升级完成后，您可以选择故障回复到原始主节点。在滚动升级中，应用程序基本不会停止运行（切换期间会有中断）。

4. 升级场景

您有一个生产SQL服务器，其中包含10个业务关键数据库，大小从5 GB到500 GB不等。您已设置2节点可用性组（AG）; SQLA和SQLB是2个AG节点。根据您的业务流程，您创建了2个AG，AG1和AG2以及需要同时进行故障转移的分组数据库，以确保应用程序在这些AG故障转移时在辅助设备上连接并顺利运行。

这些SQL Server运行在最新的Windows操作系统（OS），版本为SQL Server 2016 SP2。AG辅助副本SQLB，以异步提交模式运行，您在距离主数据中心200英里的不同数据中心内有一台灾难恢复服务器SQLC（日志传送实现同步）。日志备份和恢复每5分钟发生一次。

一些客户希望他们的数据库托管在SQL Server 2017上，因为他们的应用程序希望利用Graph数据库支持（2017中的新功能）。其余客户没有偏好。

在升级过程中，您需要始终保持数据库高可用性。

5. 执行步骤

您将把SQLA，SQLB和SQLC升级到SQL Server 2017。您完成了所有升级前的任务和测试。您现在将按照这些步骤操作。升级前完成步骤1和步骤2。

1) 确保在升级之前，在2台服务器和第二台数据中心之间获得额外的网络带宽。

2) 由于要求零数据丢失并始终保持HA，因此维护日志传送没有意义。将SQLC作为第三个异步副本添加到AG。（相当于一主两从）