将日志传送升级到 SQL Server 2014 （Transact-SQL）

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

在升级前保护好您的数据

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

保护数据

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

   有关详细信息，请参阅创建完整数据库备份 (SQL Server)。

2. 对各个主数据库运行 DBCC CHECKDB 命令。

升级 Monitor Server 实例

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

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

使用单个辅助服务器升级日志传送配置

本节中所述的升级过程假定配置由主服务器和一个辅助服务器组成。 下图显示了此配置，其中显示了主服务器实例、A 和单个辅助服务器实例 B。

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

升级辅助服务器实例

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

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

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

升级辅助服务器后，日志传送代理作业将恢复并继续从主服务器实例服务器 A 复制和还原日志备份。辅助服务器使辅助数据库保持最新所需的时间各不相同，具体取决于升级辅助服务器所需的时间和主服务器上的备份频率。

升级主服务器实例

规划升级时，需要考虑数据库不可用的时间量。 最简单的升级方案涉及在升级主服务器时数据库不可用（方案 1，如下所示）。

为了最大程度地提高数据库的可用性，您可以在升级原始主服务器之前，将SQL Server 2005或更高版本的主服务器切换到SQL Server 2014辅助服务器（下述方案2），尽管这样会使升级过程更复杂。 故障转移场景有两种变体。 可以切换回原始主服务器并保留原始日志传送配置。 或者，可以在升级原始主服务器之前删除原始日志传送配置，然后使用新的主服务器创建新的配置。 本部分介绍这两种方案。

方案 1：在不中断服务的情况下升级主服务器实例

这是更简单的方案，但它导致的停机时间比使用故障转移要更长。 主服务器实例只是升级，并且此升级期间数据库不可用。

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

方案 2：使用故障切换升级主服务器实例

此方案可最大程度地提高可用性并最大程度地减少停机时间。 它利用控制下的故障转移到次要服务器实例，使数据库在原始主服务器实例升级期间保持可用。 停机时间限制为故障转移所需的时间，这段时间相对较短，而不是升级主服务器实例所需的时间。

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

过程 1：执行到备用服务器的受控故障切换

有计划的故障转移到备用服务器：

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

   以下示例在主服务器上为AdventureWorks数据库创建尾日志备份。 备份文件命名为 Failover_AW_20080315.trn

   BACKUP LOG AdventureWorks 
     TO DISK = N'\\FileServer\LogShipping\AdventureWorks\Failover_AW_20080315.trn' 
      WITH NORECOVERY;
   GO
   

   建议使用不同的文件命名约定来区分手动创建的备份文件与日志传送备份作业创建的备份文件。

2. 在辅助服务器上：

   1. 确保已应用由日志传送备份作业自动生成的所有备份。 若要检查已应用的备份作业，请在监视服务器或主服务器和辅助服务器上使用系统存储过程 sp_help_log_shipping_monitor。 同一文件应列在 last_backup_file、 last_copied_file和 last_restored_file 列中。 如果未复制和还原任何备份文件，请手动调用日志传送配置的代理复制和还原作业。

      有关启动作业的信息，请参阅 “启动作业”。

   2. 将你在步骤 1 中创建的最终日志备份文件从文件共享复制到辅助服务器上日志传送使用的本地位置。

   3. 将最终日志备份使用 WITH RECOVERY 选项进行还原，以使数据库联机。 作为上线的一部分，数据库将升级到 SQL Server 2014。

      以下示例将 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 2005or 更高的日志传送配置，请切换回原始主服务器实例。 有关详细信息，请参阅本节后面的 “切换回原始主服务器实例”。

• 如果在故障转移之前删除了日志传送配置，请创建一个新的日志传送配置，其中原始辅助服务器实例是新的主服务器实例。 有关详细信息，请参阅本节后面的 “将旧的辅助服务器实例保留为新的主服务器实例”。

切换回原始主服务器实例

1. 在临时主服务器（服务器 B）上，使用 WITH NORECOVERY 备份日志的尾部，以创建尾日志备份并使数据库脱机。 尾日志备份被命名为Switchback_AW_20080315.trn。例如：

   BACKUP LOG AdventureWorks 
     TO DISK = N'\\FileServer\LogShipping\AdventureWorks\Switchback_AW_20080315.trn' 
      WITH NORECOVERY;
   GO
   

2. 如果在临时主数据库上执行任何事务日志备份（步骤 1 中创建的结尾备份除外），请使用 WITH NORECOVERY 将这些日志备份还原到原始主服务器上的脱机数据库（服务器 A）。 还原第一个日志备份时，数据库将升级到 SQL Server 2014 格式。

3. 使用 WITH RECOVERY 在原始主数据库（服务器 A 上）上还原结尾日志备份 Switchback_AW_20080315.trn，使数据库联机。

4. 通过将客户端从原始主服务器重定向到联机辅助服务器，故障转移回原始主数据库（在服务器 A 上）。

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

将旧的辅助服务器实例保留为新的主服务器实例

使用旧的辅助服务器实例 B 作为主服务器和旧的主服务器实例 A 建立新的日志传送配置，作为新的辅助服务器，如下所示：

1. 为了避免在新辅助服务器（服务器 A）上执行数据库的完整备份和还原，请将新主数据库的日志备份应用到新的辅助数据库。 在示例配置中，这涉及到将服务器 B 上执行的日志备份还原到服务器 A 上的数据库。

2. 从新的主数据库（在服务器 B 上）备份日志。

3. 使用 WITH NORECOVERY 将日志备份还原到新的辅助服务器实例（服务器 A）。 首次还原操作将数据库升级到 SQL Server 2014。

4. 将以前的辅助服务器（服务器 B）配置为主服务器实例并配置日志传送。

   重要

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

   有关详细信息，请参阅配置日志传送 (SQL Server)。

5. 通过将客户从原主服务器（服务器 A）重定向到在线辅助服务器（服务器 B）来进行数据库故障切换。

   重要

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

升级多个辅助服务器实例

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

本部分讨论如何使用故障转移进行升级，然后切换回原始主服务器。 使用故障转移升级主实例时，当有多个辅助服务器实例时，该过程会更加复杂。 在以下过程中，在升级所有辅助服务器后，主服务器将故障转移到升级的辅助数据库之一。 原始主服务器已升级，日志传送已切换回该服务器。

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

1. 升级所有辅助服务器实例（服务器 B 和服务器 C）。

2. 通过使用 WITH NORECOVERY 备份事务日志，获取主数据库的事务日志尾部（在服务器 A 上），使数据库脱机。

3. 在计划故障转移到的辅助服务器 B 上，通过使用 WITH RECOVERY 来还原日志备份，将辅助数据库联机。

4. 在所有其他辅助服务器（服务器 C）上，使用 WITH NORECOVERY 还原日志备份，使辅助数据库保持脱机状态。

   注释

   日志传送复制和还原作业将在辅助服务器上运行，但作业将不会执行任何操作，因为新的日志备份文件将不会被放置在备份共享上。

5. 将客户端从原始主服务器（服务器 A）重定向到联机辅助服务器（服务器 B）来故障转移数据库。 联机数据库将成为临时主服务器，使数据库保持可用，而原始主服务器处于脱机状态（服务器 A）。

6. 升级原始主服务器（服务器 A）。

7. 在发生故障转移的临时主数据库（位于服务器 B 上）中，使用 WITH NORECOVERY 手动备份事务日志。 这会使数据库脱机。

8. 使用 WITH NORECOVERY 将临时主数据库（服务器 B 上）上创建的所有事务日志备份还原到所有其他辅助数据库（在服务器 C 上）。 这样，日志传送就可以在升级后继续从原始主数据库继续，而无需在每个辅助数据库上还原完整数据库。

9. 使用 WITH RECOVERY 将事务日志从临时主服务器（服务器 B）还原到原始主数据库（在服务器 A 上）。

重新部署日志传送

如果不想使用上面所示的过程之一迁移日志传送配置，可以通过使用主数据库的完整备份和还原重新初始化辅助数据库，从头开始重新部署日志传送。 如果你有小型数据库或在升级过程中高可用性不重要，这可能是一个理想的选择。

有关启用日志传送的信息，请参阅“配置日志传送”（SQL Server）。

另请参阅

事务日志备份（SQL Server）应用事务日志备份（SQL Server）日志传送表和存储过程