将日志传送升级到 SQL Server 2014 (Transact-SQL)

项目
06/13/2017

从 SQL Server 2005、SQL Server 2008、SQL Server 2008 R2 或 SQL Server 2012 升级到 2014 SQL Server 时，可以保留日志传送配置。本主题介绍升级日志传送配置的备用方案和最佳做法。

注意

中引入了备份压缩 SQL Server 2008 Enterprise。升级后的日志传送配置使用“备份压缩默认值”服务器级配置选项控制是否对事务日志备份文件使用备份压缩。可以为每个日志传送配置指定日志备份的备份压缩行为。有关详细信息，请参阅配置日志传送 (SQL Server)。

在升级前保护好您的数据

建议您最好在日志传送升级之前保护好您的数据。

保护数据

对各个主数据库执行完整数据库备份。

有关详细信息，请参阅创建完整数据库备份 (SQL Server)。
对各个主数据库运行 DBCC CHECKDB 命令。

升级监视服务器实例

监视服务器实例（如果存在）可随时升级。

升级监视服务器时，日志传送配置仍将有效，但其状态不会记录在监视器上的表中。监视服务器正在升级期间，已配置的任何警报都不会触发。升级完毕后，可以通过执行 sp_refresh_log_shipping_monitor 系统存储过程来更新监视器表中的信息。

对具有单一辅助服务器的日志传送配置进行升级

本节讲述的升级过程适用于由主服务器和唯一一个辅助服务器组成的配置。下图显示了此配置，其中 A 为主服务器实例，B 为单一辅助服务器实例。

一个辅助服务器和无监视服务器

有关升级多个辅助服务器的信息，请参阅本主题后面的升级多个辅助服务器实例。

升级辅助服务器实例

升级过程涉及在升级主服务器实例之前，将 SQL Server 2005 或更高版本日志传送配置的辅助服务器实例升级到 SQL Server 2014。辅助服务器实例必须总是先于主服务器实例升级。如果在辅助服务器之前升级了主服务器，日志传送将失败，因为在较新版本的 SQL Server 上创建的备份无法在较旧版本的 SQL Server 上还原。

日志传送会在整个升级过程中继续，因为升级后的辅助服务器继续从 SQL Server 2005 或更高版本的主服务器还原日志备份。升级辅助服务器实例的过程部分取决于日志传送配置是否具有多个辅助服务器。有关详细信息，请参阅本主题后面的升级多个辅助服务器实例。

辅助服务器实例正在升级期间，日志传送复制和还原作业不运行，因此未还原的事务日志备份将累积。累积的数量取决于主服务器上进行计划备份的频率。此外，如果还配置了单独的监视服务器，则若未执行还原的时间超过了所配置的时间间隔，就会引发警报。

辅助服务器升级完毕后，日志传送代理作业即开始继续复制和还原主服务器实例（服务器 A）的日志备份。辅助服务器使辅助数据库达到最新所需的时间会有所不同，具体情况取决于升级辅助服务器占用的时间和主服务器上进行备份的频率。

注意

在服务器升级期间，辅助数据库不会升级到 SQL Server 2014 数据库。只有联机时它才会升级。

重要

对于要求升级的数据库，不支持 RESTORE WITH STANDBY 选项。如果已使用 RESTORE WITH STANDBY 配置了升级的辅助数据库，则在升级后可能不再能够还原事务日志。要对该辅助数据库恢复日志传送，您需要再次对该备用服务器设置日志传送。有关 STANDBY 选项的详细信息，请参阅 RESTORE 参数 (Transact-SQL) 。

升级主服务器实例

计划升级时，需要考虑的一个重要事项是数据库将处于不可用状态的时间。最简单的升级方案（下文的方案 1）将使得数据库在主服务器升级期间不可用。

以更复杂的升级过程为代价，可以将 SQL Server 2005 或更高版本的主服务器故障转移到 SQL Server 2014 辅助服务器，然后再将原始主服务器 (方案 2（低于) ）来最大程度地提高数据库可用性。故障转移方案有两种不同的形式。一种是切换回原始主服务器并保持原始日志传送配置。另一种是在升级原始主服务器之前删除原始日志传送配置，随后使用新的主服务器创建新配置。本节介绍这两种方案。

重要

一定要先升级辅助服务器实例，然后再升级主服务器实例。有关详细信息，请参阅本主题前面的升级辅助服务器实例。

方案 1：不借助故障转移升级主服务器实例

这个方案比较简单，但导致的停机时间要比使用故障转移时间长。主服务器实例进行简单的升级，数据库在升级期间不可用。

服务器升级完毕后，数据库即自动回到联机状态，随即进行升级。数据库升级完毕后，日志传送作业将继续进行。

方案 2：借助故障转移升级主服务器实例

此方案最大限度地提高了可用性，同时使停机时间降低到最短。此方案采取向辅助服务器实例实行受控故障转移的方式，使数据库在原始主服务器实例升级期间保持可用状态。停机时间限于故障转移所需的相对短的时间，而不是升级主服务器实例所需的时间。

使用故障转移升级主服务器实例涉及三个常规过程：对辅助服务器执行受控故障转移，将原始主服务器实例升级到 SQL Server 2014，并在 SQL Server 2014 主服务器实例上设置日志传送。本节后面将对这三个过程进行介绍。

重要

如果计划使辅助服务器实例成为新的主服务器实例，则需要删除日志传送配置。原始主服务器实例升级完毕后，需要重新配置从新的主服务器实例到新的辅助服务器实例的日志传送。有关详细信息，请参阅删除日志传送 (SQL Server) 。

过程 1：执行到辅助服务器的受控故障转移

到辅助服务器的受控故障转移：

在指定 WITH NORECOVERY 的主数据库上手动执行事务日志的结尾日志备份。此日志备份捕获任何尚未备份的日志记录并使数据库脱机。请注意：数据库脱机期间，日志传送备份作业将失败。

下面的示例在主服务器上创建 AdventureWorks 数据库的一个结尾日志备份。此备份文件名为 Failover_AW_20080315.trn：
```
BACKUP LOG AdventureWorks 
  TO DISK = N'\\FileServer\LogShipping\AdventureWorks\Failover_AW_20080315.trn' 
   WITH NORECOVERY;
GO
```
建议您使用非重复的文件命名约定区分手动创建的备份文件和日志传送备份作业创建的备份文件。
在辅助服务器上：
1. 确保日志传送备份作业自动进行的所有备份都已应用。若要检查已应用了哪些备份作业，请在监视服务器或主服务器和辅助服务器上使用 sp_help_log_shipping_monitor 系统存储过程。同一个文件应列在 last_backup_file、 last_copied_file和 last_restored_file 列中。如果尚未复制和还原任何备份文件，则请手动调用代理复制和还原作业以进行日志传送配置。
  
  有关启动作业的信息，请参阅 Start a Job。
2. 将您在第一步中创建的最后一个日志备份文件从文件共享复制到辅助服务器上的日志传送使用的本地位置。
3. 还原指定 WITH RECOVERY 的最后一个日志备份以使数据库联机。作为联机的一部分，数据库将升级到 2014 SQL Server。
  
  下面的示例还原辅助数据库中的 AdventureWorks 数据库的结尾日志备份。此示例使用 WITH RECOVERY 选项，该选项将使数据库联机：
```
RESTORE LOG AdventureWorks 
  FROM DISK = N'c:\logshipping\Failover_AW_20080315.trn' 
   WITH RECOVERY;
GO
```
  注意
  
  对于包含多个辅助服务器的配置，还有额外的注意事项。有关详细信息，请参阅本主题后面的升级多个辅助服务器实例。
4. 将客户端从原始主服务器（服务器 A）重定向到联机辅助服务器（服务器 B），以对数据库进行故障转移。
5. 请注意：辅助数据库在处于联机状态时，它的事务日志并未填满。若要阻止事务日志填满，可能需要备份此日志。如果是这样，建议您将它备份到共享位置，即备份到“备份共享” ，以便在其他服务器实例上可以还原这些备份。

过程 2：将原始主服务器实例升级到 SQL Server 2014

将原始主服务器实例升级到 SQL Server 2014 后，数据库仍将处于脱机状态且格式为。

过程 3：在 SQL Server 2014 上设置日志传送

剩余的升级过程取决于是否仍配置日志传送，如下所述：

如果保持SQL Server 2005 或更高的日志传送配置，请切换回原始主服务器实例。有关详细信息，请参阅本节后面的切换回原始主服务器实例。
如果在进行故障转移之前删除了日志传送配置，则请创建一个新的日志传送配置，其中原始辅助服务器实例是新的主服务器实例。有关详细信息，请参阅本节后面的将原来的辅助服务器实例作为新的主服务器实例。

切换回原始主服务器实例

在临时主服务器（服务器 B）上使用 WITH NORECOVERY 备份日志尾部，以创建结尾日志备份并使数据库脱机。该结尾日志备份命名为 Switchback_AW_20080315.trn。例如：
```
BACKUP LOG AdventureWorks 
  TO DISK = N'\\FileServer\LogShipping\AdventureWorks\Switchback_AW_20080315.trn' 
   WITH NORECOVERY;
GO
```
如果任何事务日志备份都是在临时主数据库上进行的，则将那些使用 WITH NORECOVERY 的日志备份（不包括在第一步中创建的结尾备份）还原到原始主服务器（服务器 A）上的脱机数据库。还原第一个日志备份时，数据库将升级到SQL Server 2014 格式。
在原始主数据库上（即在服务器 A 上）使用 WITH RECOVERY 还原结尾日志备份 Switchback_AW_20080315.trn，从而使数据库联机。
将客户端从原始主服务器重定向到联机辅助服务器，从而故障转移回原始主数据库（位于服务器 A 上）。

数据库联机后，原始日志传送配置将恢复。

将原来的辅助服务器实例作为新的主服务器实例

按照下面所述建立新的日志传送配置，其中原来的辅助服务器实例 B 用作主服务器，而原来的主服务器实例 A 用作新的辅助服务器：

重要

在此过程开始时且在进行使数据库脱机的手动事务日志备份之前，应该已从原始主服务器上删除原来的日志传送配置。

若要避免对新的辅助服务器（服务器 A）上的数据库执行完整的备份和还原，请将新的主数据库的日志备份应用到新的辅助数据库。在示例配置中，这包括将在服务器 B 上进行的日志备份还原到服务器 A 上的数据库。
备份新的主数据库（位于服务器 B 上）的日志。
使用 WITH NORECOVERY 将日志备份还原到新的辅助服务器实例（服务器 A）。第一个还原操作会将数据库更新为 SQL Server 2014。
配置日志传送，使原来的辅助服务器（服务器 B）作为主服务器实例。

重要

如果使用 SQL Server Management Studio，请指定辅助数据库已初始化。

有关详细信息，请参阅配置日志传送 (SQL Server)。
将客户端从原始主服务器（服务器 A）重定向到联机辅助服务器（服务器 B），以对数据库进行故障转移。

重要

故障转移到新的主数据库时，应确保其元数据与原始主数据库的元数据一致。有关详细信息，请参阅当数据库在其他服务器实例上可用时管理元数据 (SQL Server)。

升级多个辅助服务器实例

下图显示了此配置，其中 A 为主服务器实例，B 和 C 都是辅助服务器实例。

两个辅助服务器和无监视服务器

本节讨论如何使用故障转移进行升级，然后再切换回原始主服务器。如果有多个辅助服务器实例，则借助故障转移升级主实例的过程将更加复杂。在下面的过程中，所有辅助服务器升级完毕后，主服务器故障转移到其中一个已升级的辅助数据库。原始主服务器得到升级，然后日志传送重新故障转移到原始主服务器。

重要

必须先对所有辅助服务器实例进行升级，然后再升级主服务器。

借助故障转移进行升级，然后切换回原始主服务器

升级全部辅助服务器实例（服务器 B 和服务器 C）。
获取主数据库（位于服务器 A 上）的事务日志尾部，并使用 WITH NORECOVERY 备份此事务日志，以使该数据库脱机。
通过使用 WITH RECOVERY 还原日志备份，使您计划故障转移到的辅助服务器（服务器 B）上的辅助数据库联机。
在所有其他辅助服务器（服务器 C）上，通过使用 WITH NORECOVERY 还原日志备份，使辅助数据库仍处于脱机状态。

注意

日志传送复制和还原作业将在辅助服务器上运行，但由于新的日志备份文件不会放在备份共享中，因此这些作业不执行任何操作。
将客户端从原始主服务器（服务器 A）重定向到联机辅助服务器（服务器 B），以对数据库进行故障转移。联机数据库将成为临时主服务器，从而保持该数据库在原始主服务器（服务器 A）脱机期间仍可用。
升级原始主服务器（服务器 A）。
在服务器 B) 上将临时主数据库 (故障转移到的数据库上，使用 WITH NORECOVERY 手动备份事务日志。这将使该数据库脱机。
将使用 WITH NORECOVERY 在临时主数据库（位于服务器 B 上）上创建的所有事务日志备份还原到所有其他辅助数据库（位于服务器 C 上）。从而在原始主数据库升级后，可以继续从其进行日志传送，而无需对每个辅助数据库进行完全的数据库还原。
使用 WITH RECOVERY 将临时主服务器（服务器 B）上的事务日志还原到的原始主数据库（位于服务器 A 上）。

重新部署日志传送

如果不想使用上述过程之一迁移日志传送配置，可以通过使用主数据库的完整备份和恢复来重新初始化辅助数据库，从而从头开始重新部署日志传送。如果数据库较小，或者在升级过程中高可用性并不是至关重要的，此方法将是个不错的选择。

有关启用日志传送的信息，请参阅配置日志传送 (SQL Server) 。

通过