一、选择SQL Server升级方法
升级SQL Server的方法归结为几个业务目标：最短的停机时间、最少的花费、最小的风险。
这几个目标通常是无法兼具的，以下每种方法都有利弊，因此根据业务情况选择正确的升级方法非常重要。
1. 业界最常用的升级或迁移SQL Server方法
全备还原
附加和分离
就地升级
大型数据库的差异还原
使用日志传送升级SQL Server
滚动升级（停机时间最短）
2. SQL Server升级 vs 迁移
首先区别一下SQL Server中的迁移和升级术语，有时这些术语会被互换使用，但它们确实有一些不同之处。
1) 升级SQL Server意味着
只升级Edition，例如从SQL Server 2014标准版（SE）升级到SQL Server 2014企业版（EE）。
只升级Version，例如从SQL Server 2012（EE）升级到SQL Server 2016（EE）。
升级Edition和Version。例如从SQL Server 2012（SE）升级到SQL Server 2017（EE）。
Service Pack（SP）和累积更新（CU）的安装相当于小版本升级。
2) 迁移可能包括也可能不包括SQL Server的升级，但这意味着将数据库从一个实例移动到另一个实例。
例如更换SQL Server的物理机或操作系统
例如一个SQL Server实例上可能存在太多数据库，并且维护作业执行与业务时间重叠，想分割负载。
例如同一VM机器上启动了多个SQL Server实例，需要申请新的VM并移动一些实例到新机器。
例如将数据库从本地迁移到云，例如Azure。
当然，迁移还可以包括升级SQL Server。
下面我们讨论上面列表中提到的升级方法思路，具体操作方法不一一列出了。
二、 使用全备+还原进行SQL Server升级
这是迁移期间升级数据库的最基本、最简单的方法，这种升级方法是50G以下的数据库的理想选择。
这其实就是异机全备+还原了，操作方法非常简单，这里略了。
三、 使用分离和附加数据库进行SQL Server升级
这是在迁移期间升级的另一种基本且简单的方法，但注意它不是推荐的最佳实践方法。思路与前一种方法基本相同，对于较小的数据库，使用“备份和还原”进行升级更加安全可靠。
这不是推荐的迁移数据库的方法，因为您可能会遇到各种类型的问题。例如，如果源与目标之间存在SQL Server排序规则差异，attach可能会失败。
如果在新服务器上复制数据库文件的目录没有SQL Server服务帐户的适当权限，则可能会失败。另一个重要原因是，如果在分离数据库并尝试附加之间的时间已经过了一两天，文件可能被误删除。
如果服务器重新启动，文件可能会损坏。
假设数据库大于50 GB，并且还有预算限制。在这种情况下，哪种升级方法是合适的？
四、 就地升级
参考：https://blog.51cto.com/daisywei/1878767
此方法不能用于迁移，因为所有操作都发生在同一服务器上，因此称为“就地升级”。这是最便宜、最快但却最危险的升级方法，不建议在生产SQL Server使用。
由于是直接升级现有SQL Server实例（所有系统和用户数据库的系统对象都会升级），如果出现任何问题，很可能将无法回滚（虚拟机可以打快照、物理机做存储快照）。预算较低且无法花钱购买硬件和软件许可证的公司可以选择这种方法，但是在升级失败的情况下，回退旧版本的花费很可能更多，并且还需要更多时间。另一个警告是，在就地升级期间，无法添加其他SQL Server功能，只能在安装完成后进行。
五、 差异还原升级
1. 场景
假设在sample模式下有一个大型数据库，比如500 GB，在每周日晚进行一次完整备份，并在其他6晚进行差异备份。
此数据库位于SQL Server 2012（源）上，另有一个SQL Server 2017实例（目标），希望升级和迁移源实例。这两个SQL Server位于不同的数据中心，两个数据中心之间的网络带宽为10 GB。进行迁移的唯一可用窗口是星期六早上，期望在2小时内完成迁移，随后进行测试。
设置一个文件复制作业在星期日晚上的完整备份完成后运行，将备份文件复制到目标服务器。星期一早上，验证目标服务器上的备份文件是否可用。
星期一晚上在目标服务器上以no Recovery 模式还原备份。
从星期二到星期五，利用作业复制备份文件到目标服务器并以no Recovery 模式还原差异备份。
星期六上午7点，维护窗口前一小时，在源服务器上启动数据库的最后一次差异备份。由于已精心计算，可以完美地计时并且备份在上午8点结束。立即将数据库设置为只读，避免丢失数据。
手动将最后一个差异备份文件复制到目标服务器并使用Recovery模式还原。
将兼容模式更改为最新，并将数据库升级到新的SQL版本。
将应用程序连接指向升级后的数据库，测试应用程序。
这种使用差异还原的方法在复杂性较低但数据库很大的情况下工作很简单。
关于回滚策略，如果升级失败，只需将源服务器上的数据库更改回读写模式，应用切回即可。
六、 使用日志传送升级SQL Server/使用高性能模式的数据库镜像
其实这就是把前面那种手动备份+复制+还原的方法大部分让sqlserver自动做了。
1. 场景
有2个企业版SQL Server 2012实例SQL1和SQL2，操作系统是Windows Server 2012 R2。SQL1到SQL2的数据库DB3（500 GB）设置了事务日志传送。
现在希望将这些企业版SQL Server 2012升级到标准版SQL Server 2017以节省许可成本，还希望利用2017的一些新功能。自SQL Server 2016 SP1以来，微软已在SE中提供了许多EE级功能，例如压缩和数据库快照等。
2. 执行
决定使用当前的日志传送设置进行并排升级。当前的Windows Server 2012 R2操作系统支持SQL Server 2017，因此无需升级操作系统。计划首先升级SQL2，如果出现任何问题，回滚计划是将应用程序切回SQL Server 2012的SQL1实例。
当前生产环境日志传送简图（均为2012 EE）：
注意SQL Server 2012 EE无法直接升级到SQL Server 2017 SE，因为这是从高edition降到了低edition 。因此需要在Domain2中安装另一个SQL Server 2017 SE版本的SQL3实例，如果是2012 EE到2017 EE，则不需要。
以下是使用SQL Server日志传送升级和/或迁移数据库的一般步骤：
停掉实例SQL1和SQL2上的日志传送作业
在SQL1上，使用NORECOVERY选项对DB3的last事务日志进行备份。使用NORECOVERY选项进行日志备份时，会将DB3数据库置于还原模式，这样将没有用户可以连接到它
BACKUP LOG [DB3] TO DISK = \'C:\SQLBackups\DB3.trn\' WITH NORECOVERY;
手动在SQL2上运行复制和还原作业以确保应用所有日志（若已应用可略过）
手动复制对DB1进行的last日志备份，并使用WITH RECOVERY选项在SQL2 DB3上手动进行还原。使用with recovery应用日志时，DB3将在SQL2上online
RESTORE LOG DB3 FROM DISK = \'C:\SQL2012\SQL2\LogShip\DB3.trn\' WITH RECOVERY
在SQL2上完整备份DB3
在SQL3上还原DB3，将DB3兼容级别更新为140
USE [master]
GO
ALTER DATABASE [DB3] SET COMPATIBILITY_LEVEL = 140
GO
将应用程序连接到SQL3的DB3进行测试，SQL3现在是新的主实例
如果验证成功，则升级已经完成后，可以在此处停止。但是，如果要创建日志传送，还需执行以下后续步骤
在Domain1中安装SQL Server 2017实例SQL4，将作为新的辅助SQL Server
创建从SQL3到SQL4的日志传送
卸载SQL1和SQL2实例
3. 使用日志传送升级的优点
大多数数据可以预先移动到目标SQL Server，在实际数据迁移时需要的停机时间更少。如果数据库非常大，并且源和目标SQL实例位于不同的域中，这将特别有用。
与就地升级相比，有了回滚方案，如果辅助数据库的升级不顺利，可以通过将应用程序连接回旧数据库版本来回滚。要使旧数据库联机，只需发出以下命令：
RESTORE DATABASE [DB3] WITH RECOVERY;
一个主数据库可以有多个辅助数据库。升级一个辅助数据库后，它可以作为其余辅助服务器的主数据库。
4. 使用日志传送升级的优点
故障转移不方便
应用程序停机是不可避免的，而且时间可能还是比较长
日志传送需要另一个SQL Server，因此需要额外的硬件和许可成本。
必须为每个数据库设置事务日志传送，如果有超过20个数据库，你会崩溃的。在这种情况下，对大于50 GB的数据库，建议使用“日志传送”方法。对于小于50 GB的数据库，建议使用“全备还原”升级方法。50 GB不是微软设置的数字，是个经验值。
七、 滚动升级
对于核心数据库，业务要求停机时间最短，例如在5分钟内完成Windows和SQL Server升级。此时应该如何规划？
1. 滚动升级
滚动升级需要至少2个SQL Server实例。升级前，主服务器和从服务器始终保持同步。可用性组（AlwaysOn AG）是进行滚动升级的一种方法，通过此方法，可保证最短的停机时间（用户、作业、链接服务器等在从服务器上都可用并准备就绪）
当应用程序连接到主节点时，进行从节点升级。只要从实例版本不低于与主节点，AG同步就不会断。不过在从节点进行升级时，事务在从服务器上将被阻塞，直到升级完成。当从实例完成升级时，确保从库已应用所有事务（建议设为同步模式）并且两个数据库都处于同步状态，然后再手动故障转移到辅助实例，此步骤可确保故障转移期间零数据丢失。
升级后的辅助节点承担主节点的角色，在旧主节点的版本与新主节点相同之前，事务不会在旧主节点应用。升级完成后，可以选择故障转移回到原主节点。在滚动升级中，应用程序基本不会停止（切换期间有中断）。
2. 业务场景
有一个业务关键数据库（500 GB），已设置2节点AG（SQLA和SQLB）。这些SQL Server运行在最新的Windows操作系统，版本为SQL Server 2016 SP2。现在需要将它们升级到SQL Server 2017，在升级过程中，需要保证始终有主从同步、同时停机时间最短。
3. 执行步骤
由于要求保证始终有主从同步，需要再建一个SQLC实例，作为第三个异步副本添加到AG（一主两从）
SQLA SQLB SQLC AG1
Primary Secondary （同步） Secondary （异步）
首先升级SQLC。在升级时，SQLA和SQLB处于同步状态，应用程序正常运行
下一步升级SQLB。在升级时，SQLA和SQLC保持同步，应用程序正常运行（A主C从，A版本低于C）
升级并同步SQLB后，将AG1故障转移到SQLB。SQLB 变为主库，应用程序通过vip连接到SQLB。SQLC开始与SQLB同步。SQLA无法同步，因为其版本低于主库SQLB
升级SQLA
等待SQLA升级完成后重新与SQLB同步
如果您愿意，可以在升级后将主库故障转移回SQLA
参考
https://www.mssqltips.com/sqlservertip/5646/choosing-a-sql-server-upgrade-method--part-1/
https://www.mssqltips.com/sqlservertip/5652/sql-server-upgrade-methods-inplace-upgrades-and-differential-restore-upgrades--part-2/
https://www.mssqltips.com/sqlservertip/5669/side-by-side-sql-server-upgrade-with-log-shipping--part-3/
https://www.mssqltips.com/sqlservertip/5737/minimizing-downtime-for-sql-server-upgrades--part-4/
https://www.mssqltips.com/sqlservertip/1233/differential-database-backups-for-sql-server/
http://www.sqlservercentral.com/articles/SQL/152815/
https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/upgrading-always-on-availability-group-replica-instances?view=sql-server-2017
————————————————
版权声明：本文为****博主「Hehuyi_In」的原创文章，遵循CC 4.0 BY-SA版权协议
原文链接：https://blog.****.net/Hehuyi_In/article/details/89670209