你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

使用 Log Replay 服务从 SQL Server 迁移数据库 - Azure SQL 托管实例

本文介绍如何使用 Log 重播服务（LRS）将SQL Server数据库迁移到Azure SQL 托管实例。 LRS 是一项免费的云服务，用于Azure SQL 托管实例迁移，基于SQL Server日志传送技术。了解从先决条件到直接转换的完整过程，包括成功进行数据库迁移的最佳做法。

注意

现在，可以通过Azure Arc直接通过Azure门户将启用的SQL Server实例迁移到Azure SQL 托管实例。若要了解详细信息，请查看 Migrate 到 Azure SQL 托管实例。

支持以下源：

虚拟机上的 SQL Server
Amazon EC2 （弹性计算云）
适用于SQL Server的 Amazon RDS （关系数据库服务）
Google Compute Engine
云端 SQL for SQL Server - GCP（Google Cloud Platform）

先决条件

重要

将数据库迁移到“业务关键”服务层级之前，请考虑这些限制，它们不适用于“常规用途”服务层级。
在迁移过程完成之前，不能使用正在通过 LRS 还原的数据库。
LRS 不支持在迁移期间对数据库进行只读访问。
迁移结束后，迁移过程就终止了，无法通过其他差异备份恢复。

在开始之前，请考虑本部分中SQL Server实例和Azure的要求。请仔细查看限制和最佳做法部分，确保成功迁移。

SQL Server

请确保满足SQL Server的以下要求：

SQL Server 版本 2008 到 2022。
SQL Server数据库正在使用完整恢复模式（必需）。
数据库的完整备份（一个或多个文件）。
差异备份（一个或多个文件）。
日志备份（不为事务日志文件进行拆分）。
对于 2008 到 2016 版本的 SQL Server，请在本地备份并手动上传备份到您的 Azure Blob 存储帐户。
对于 SQL Server 2016 及更高版本，可以将备份直接传输到 Azure Blob 存储帐户。
虽然不需要为备份启用 CHECKSUM，但强烈推荐启用它，以防止无意中迁移损坏的数据库并加快还原操作速度。
根据SQL Server版本的支持性，任何版本的Windows Server都可以得到支持。
对于 SQL Server 2019 及更高版本，应启用加速数据库恢复，并将持久性版本存储设置为 PRIMARY。有关详细信息，请参阅本文中的迁移到 SQL 托管实例后出现的问题。
若要在迁移到Azure SQL 托管实例的数据库上使用 Service Broker，必须在迁移前在源数据库上启用 Service Broker。有关详细信息，请参阅本文中的迁移到 SQL 托管实例后出现的问题。

Azure

请确保满足Azure的以下要求：

PowerShell Az.SQL模块版本 4.0.0 或更高版本（安装或通过 Azure Cloud Shell 访问）。
Azure CLI版本 2.42.0 或更高版本（安装）。
预配的Azure Blob 存储容器。
一个共享访问签名（SAS）安全令牌，其中包含为Blob 存储容器生成的Read和List权限，或可以访问容器的托管标识。授予超出 Read 和 List 的权限会导致 LRS 失败。
使用平面文件结构将单个数据库的备份文件放入存储帐户的单独文件夹中（必需）。不支持数据库文件夹内的嵌套文件夹。

Azure RBAC 权限

通过提供的客户端运行 LRS 需要以下Azure基于角色的访问控制（RBAC）角色之一：

SQL 托管实例 Contributor 角色
具有以下权限的角色：Microsoft.Sql/managedInstances/databases/*

最佳实践

使用 LRS 时，请考虑以下最佳做法：

将完整备份和差异备份拆分为多个文件，而不是使用一个文件。
启用备份压缩以帮助提高网络传输速度。
使用Cloud Shell运行 PowerShell 或 CLI 脚本，因为它将始终更新为使用最新发布的 cmdlet。
配置维护时段，以便在迁移时段之外的特定日期和时间计划系统更新，防止延迟或中断迁移。
计划在最多 30 天内完成单个 LRS 迁移作业。在此时间范围到期时，LRS 作业会自动取消。
为了防止无意中迁移损坏的数据库并加快还原操作速度，请在进行备份时启用 CHECKSUM。尽管SQL 托管实例在没有 CHECKSUM 的情况下对备份执行基本完整性检查，但不能保证捕获所有形式的损坏。使用 CHECKSUM 进行备份是确保还原到SQL 托管实例的备份未损坏的唯一方法。在没有 CHECKSUM 的情况下对备份进行基本完整性检查会增加数据库的还原时间。
迁移到“业务关键”服务层级时，请考虑直接转换后数据库可用性中的长时间延迟，因为数据库会播种到次要副本。对于具有最短停机时间要求的大型数据库，请考虑先迁移到常规用途服务层，然后再升级到 Business Critical 服务层级，或使用托管实例链接迁移数据。
上传数千个数据库文件进行还原可能会导致迁移时间过长，甚至失败。将数据库合并到更少的文件中来加快迁移过程，并确保迁移成功。
若要最大程度地减少切换时间并降低故障风险，请确保最后一次备份尽可能小。

配置维护窗口

SQL 托管实例的系统更新优先于正在进行的数据库迁移。

迁移因服务层的不同而受到影响：

在“常规用途”服务层级中，所有挂起的 LRS 迁移会暂停，仅在应用更新后才恢复。此系统行为可能会延长迁移时间，尤其是对于大型数据库。
在“业务关键”服务层级中，所有挂起的 LRS 迁移会被取消，并在应用更新后自动重启。此系统行为可能会延长迁移时间，尤其是对于大型数据库。

若要实现数据库迁移的可预测时间，请考虑配置维护时段以计划特定日期和时间的系统更新，并在指定维护时段外运行和完成迁移作业。例如，对于从星期一开始的迁移，请在周日配置自定义维护时段，以便有最多的时间来完成迁移。

虽然配置维护时段不是必需的，但对于大型数据库，我们强烈建议这样做。

注意

虽然维护窗口可以控制计划内更新的可预测性，但不能保证不会发生计划外的故障转移或意外的安全补丁更新。计划外故障转移或安全修补程序（优先于所有其他更新）仍可能会中断迁移。

迁移多个数据库

如果要使用相同的Azure Blob 存储容器迁移多个数据库，则必须将不同数据库的备份文件放置在容器内的单独文件夹中。单个数据库的所有备份文件必须放在数据库文件夹内的平面文件结构中，并且文件夹不能嵌套。不支持数据库文件夹内的嵌套文件夹。

下面是Azure Blob 存储容器中的文件夹结构示例，这是使用 LRS 迁移多个数据库所需的结构。

-- Place all backup files for database 1 in a separate "database1" folder in a flat-file structure.
-- Don't use nested folders inside the database1 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database1>/<all-database1-backup-files>

-- Place all backup files for database 2 in a separate "database2" folder in a flat-file structure.
-- Don't use nested folders inside the database2 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database2>/<all-database2-backup-files>

-- Place all backup files for database 3 in a separate "database3" folder in a flat-file structure.
-- Don't use nested folders inside the database3 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database3>/<all-database3-backup-files>

创建存储帐户

使用 Azure Blob 存储帐户作为 SQL Server 实例与 SQL 托管实例部署之间的备份文件的中间存储。若要在存储帐户中创建新的存储帐户和 blob 容器：

创建存储帐户。
在存储帐户中创建 blob 容器。

在防火墙后面配置Azure存储

支持使用受防火墙保护的 Azure Blob 存储，但需要额外配置。若要在启用 Azure 防火墙的情况下启用对 Azure 存储的读写访问，您必须通过使用 MI 子网委派和存储服务终结点，将 SQL 托管实例的子网添加到存储帐户的虚拟网络的防火墙规则中。存储帐户和托管实例必须位于同一区域或两个配对区域。

如果Azure存储位于防火墙后面，则可能在 SQL 托管实例错误日志中看到以下消息：

Audit: Storage access denied user fault. Creating an email notification:

这会生成一封电子邮件，通知你对 SQL 托管实例的审核未能将审核日志写入存储帐户。如果看到此错误或收到此电子邮件，请按照本部分中的步骤配置防火墙。

要配置防火墙，请执行以下步骤：

转到 Azure 门户中的 SQL 托管实例，然后选择子网以打开 Subnets 页。

Azure 门户的 SQL 托管实例概述页的
在“子网”页上，选择子网的名称以打开子网配置页。
在 Subnet 委派下，从 将子网委派给服务下拉列表中选择Microsoft.Sql/managedInstances。等待大约一小时以使权限传播，然后在 Service endpoints 下，从 Services 下拉列表中选择 Microsoft.Storage。
接下来，转到 Azure 门户中的存储帐户，选择 NetworkingSecurity + networking，然后选择Firewalls 和虚拟网络选项卡。
在存储帐户的“防火墙和虚拟网络”选项卡上，选择“+ 添加现有虚拟网络”，打开“添加网络”页面。
从下拉列表菜单中选择相应的订阅、虚拟网络和托管实例子网，然后选择“ 添加 ”，将 SQL 托管实例的虚拟网络添加到存储帐户。

向Blob 存储帐户进行身份验证

使用 SAS 令牌或托管标识访问Azure Blob 存储帐户。

警告

不能在同一存储帐户上同时使用 SAS 令牌和托管标识。可以使用 SAS 令牌或托管标识，但不能同时使用两者。

SAS 令牌
托管标识

为 LRS 生成Blob 存储 SAS 身份验证令牌

使用 SAS 令牌访问Azure Blob 存储帐户。

可以将Azure Blob 存储帐户用作SQL Server实例与SQL 托管实例部署之间的备份文件的中间存储。为 LRS 生成仅具有只读和列出权限的 SAS 身份验证令牌。该令牌使 LRS 能够访问Blob 存储帐户，并使用备份文件将其还原到托管实例。

按照以下步骤生成令牌：

转到 Azure 门户中的 Storage 中心并选择存储帐户。
在 “安全性 + 网络”下，选择 “共享访问签名 ”以打开 “共享访问签名 ”窗格。
在 “共享访问签名 ”窗格中，将设置配置为为 LRS 生成 SAS 令牌。使用以下准则配置设置：
1. 允许的服务： Blob 和文件。
2. 允许的资源类型：服务。
3. 权限：只读和列出。
  
  重要
  
  不要选择任何其他权限。如果这样，LRS 将无法启动。此安全要求是设计使然。
4. Blob 版本控制权限：可选
5. 允许的 Blob 索引权限：可以禁用。
6. 选择令牌的时区：UTC 或本地时间。
  
  重要
  
  令牌的时区与您所管理的实例可能不匹配。请确保 SAS 令牌具有适当的时间有效性，并考虑时区因素。若要考虑时区差异，请在迁移窗口开始前很早就设置From值的有效性，并在预期迁移完成后很久再设置To值。
7. 选择 生成 SAS 和连接字符串 以生成令牌：
系统将使用你指定的时间有效性生成 SAS 身份验证。
复制 Blob 服务 SAS URL 字段中提供的值，这是启动 LRS 所需的令牌的 URI 版本。

注意

目前不支持通过定义存储访问策略设置的权限创建的 SAS 令牌。请按照本过程中的说明，手动指定 SAS 令牌的 “读取” 和 “列出” 权限。

从 SAS 令牌复制参数

使用 SAS 令牌或托管标识访问Azure Blob 存储帐户。

在使用 SAS 令牌启动 LRS 之前，你需要了解其结构。系统生成的 SAS 令牌的 URI 由两部分组成，这两部分用问号 (?) 隔开，如以下示例所示：

第一部分从 https:// 开始，一直到问号 (?) 前结束，该部分用于作为输入馈送到 LRS 的 StorageContainerURI 参数。它向 LRS 提供存储数据库备份文件的文件夹的相关信息。

第二部分是 ? 参数，该部分从问号 (StorageContainerSasToken) 后开始一直到字符串末尾。此部分是实际签名的身份验证令牌，在指定时间内有效。此部分不一定需要像示例所示的那样从 sp= 开始。你的方案可能有所不同。

按如下方式复制参数：

复制令牌的第一部分，从 https:// 一直到问号 (?)（不含）。在 PowerShell 中将其用作 StorageContainerUri 参数，或在启动 LRS 时用作 Azure CLI 参数。
复制该令牌的第二部分，从问号 (?) 后面开始，一直复制到该字符串的结尾。在启动 LRS 时，将其用作 PowerShell 或 Azure CLI 中的 StorageContainerSasToken 参数。

注意

复制令牌的任一部分时，请勿包含问号 (?)。

验证托管实例存储访问权限

验证托管实例是否可以访问Blob 存储帐户。

首先，将任何数据库备份（如 full_0_0.bak）上传到Azure Blob 存储容器。

接下来，连接到托管实例，并运行示例测试查询，以确定托管实例是否能够访问容器中的备份。

SAS 令牌
托管标识

如果使用 SAS 令牌对存储帐户进行身份验证，请将 <sastoken> 替换为 SAS 令牌，并在实例上运行以下查询：

CREATE CREDENTIAL [https://<mystorageaccountname>.blob.core.windows.net/databases]
    WITH IDENTITY = 'SHARED ACCESS SIGNATURE',
    SECRET = '<sastoken>';

RESTORE HEADERONLY
    FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/full_0_0.bak';

如果使用托管标识对存储帐户进行身份验证，请使用存储帐户 URL 更新 CREATE CREDENTIAL，并在实例上运行以下查询：

RESTORE HEADERONLY
    FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/full_0_0.bak';

CREATE CREDENTIAL [https://<mystorageaccountname>.blob.core.windows.net/<containername>]
    WITH IDENTITY = 'MANAGED IDENTITY';

将备份上传到Blob 存储帐户

Blob 容器准备就绪且已确认托管实例可以访问容器后，可以开始将备份上传到Blob 存储帐户。您可以选择：

将备份复制到Blob 存储帐户。
如果环境允许备份（从 SQL Server 版本 2012 SP1 CU2 和 SQL Server 2014 开始），请使用 BACKUP TO URL 命令从 SQL Server 直接备份到 Blob 存储帐户。

将现有备份复制到Blob 存储帐户

如果使用的是早期版本的 SQL Server，或者环境不支持直接备份到 URL，请像往常一样在SQL Server实例上备份备份，然后将其复制到Blob 存储帐户。

在SQL Server实例上备份

将想要迁移到完整恢复模式的数据库设置为允许日志备份。

-- To permit log backups, before the full database backup, modify the database to use the full recovery
USE master;

ALTER DATABASE SampleDB
SET RECOVERY FULL;
GO

若要手动将数据库完整、差异和日志备份到本地存储，请使用以下示例 T-SQL 脚本。不需要 CHECKSUM，但建议使用它，以防止迁移损坏的数据库并加快还原时间。

以下示例将数据库完整备份到本地磁盘：

-- Take full database backup to local disk
BACKUP DATABASE [SampleDB]
    TO DISK = 'C:\BACKUP\SampleDB_full.bak'
    WITH INIT, COMPRESSION, CHECKSUM;
GO

以下示例将在本地磁盘上进行差异备份：

-- Take differential database backup to local disk
BACKUP DATABASE [SampleDB]
    TO DISK = 'C:\BACKUP\SampleDB_diff.bak'
    WITH DIFFERENTIAL, COMPRESSION, CHECKSUM;
GO

以下示例将事务日志备份到本地磁盘：

-- Take transactional log backup to local disk
BACKUP LOG [SampleDB]
    TO DISK = 'C:\BACKUP\SampleDB_log.trn'
    WITH COMPRESSION, CHECKSUM;
GO

将备份复制到Blob 存储帐户

备份准备就绪后，想要使用 LRS 开始将数据库迁移到托管实例，可以使用以下方法将现有备份复制到 Blob 存储帐户：

下载并安装 AzCopy。
下载并安装 Azure 存储资源管理器。
在 Azure 门户中使用存储资源管理器。

注意

若要使用相同的Azure Blob 存储容器迁移多个数据库，请将单个数据库的所有备份文件放入容器内的单独文件夹中。为每个数据库文件夹使用平面文件结构。不支持数据库文件夹内的嵌套文件夹。

直接将备份备份到Blob 存储帐户

如果你使用的是受支持的 SQL Server 版本（从 SQL Server 2012 SP1 CU2 和 SQL Server 2014 开始），并且企业和网络策略允许它，则可以使用本机SQL Server直接从 SQL Server 备份到 Blob 存储帐户BACKUP TO URL 选项。如果可以使用 BACKUP TO URL，则无需备份到本地存储并将其上传到Blob 存储帐户。

将本机备份直接复制到 Blob 存储帐户时，必须向存储帐户进行身份验证。

使用以下命令创建将 SAS 令牌导入SQL Server实例的凭据：

CREATE CREDENTIAL [https://<mystorageaccountname>.blob.core.windows.net/<containername>]
    WITH IDENTITY = 'SHARED ACCESS SIGNATURE',
    SECRET = '<SAS_TOKEN>';

有关使用 SAS 令牌的详细说明，请查看教程使用 Azure Blob 存储与 SQL Server。

创建凭据以使用 Blob 存储对SQL Server实例进行身份验证后，可以使用 BACKUP TO URL 命令直接备份到存储帐户。建议启用 CHECKSUM，但不是必需的。

以下示例将数据库完整备份到 URL：

-- Take a full database backup to a URL
BACKUP DATABASE [SampleDB]
    TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_full.bak'
    WITH INIT, COMPRESSION, CHECKSUM;
GO

以下示例将数据库差异备份到 URL：

-- Take a differential database backup to a URL
BACKUP DATABASE [SampleDB]
    TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_diff.bak'
    WITH DIFFERENTIAL, COMPRESSION, CHECKSUM;
GO

以下示例将事务日志备份到 URL：

-- Take a transactional log backup to a URL
BACKUP LOG [SampleDB]
    TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_log.trn'
    WITH COMPRESSION, CHECKSUM;

使用以下 PowerShell cmdlet 登录Azure：

Login-AzAccount

使用以下 PowerShell cmdlet 选择托管实例所在的订阅：

Select-AzSubscription -SubscriptionId <subscription ID>

开始迁移

通过启动 LRS 开始进行迁移。你可以在自动完成或连续模式下启动该服务。

当使用自动完成模式时，在最后一个指定的备份文件已还原时，迁移会自动完成。此选项要求提前提供整个备份链，并将其上传到Blob 存储帐户。它不允许在迁移正在进行期间添加新备份文件。此选项要求 start 命令指定最后一个备份文件的文件名。对于不需要数据补充的被动工作负载，建议使用此模式。

使用连续模式时，服务会持续扫描Azure Blob 存储文件夹，并还原迁移过程中添加的任何新备份文件。迁移仅在请求了手动直接转换后才会完成。当没有提前提供整个备份链时，以及计划在迁移进行后添加新备份文件时，需要使用连续模式迁移。对于需要数据补充的活动工作负载，建议使用此模式。

计划在最多 30 天内完成单个 LRS 迁移作业。此时间到期后，LRS 作业会自动取消。

注意

迁移多个数据库时，每个数据库必须位于其自己的文件夹中。必须为每个数据库单独启动 LRS，指向Azure Blob 存储容器和单个数据库文件夹的完整 URI 路径。不支持数据库文件夹内的嵌套文件夹。

在自动完成模式下启动 LRS

确保整个备份链已上传到Azure Blob 存储帐户。此选项不允许在迁移进行期间添加新备份文件。

若要在自动完成模式下启动 LRS，请使用 PowerShell 或Azure CLI命令。使用 -LastBackupName 参数指定最后一个备份文件的名称。最后一个指定的备份文件还原完成后，服务会自动启动切换。

使用 SAS 令牌或托管标识从存储帐户还原数据库。

重要

在自动完成模式下开始迁移之前，请确保已将整个备份链上传到Azure Blob 存储帐户。此模式不允许在迁移过程中添加新备份文件。
确保正确指定了最后一个备份文件，并且之后未上传更多文件。如果系统在最后一个指定备份文件后检测到更多备份文件，则迁移会失败。

SAS 令牌
托管标识

以下 PowerShell 示例使用 SAS 令牌在自动完成模式下启动 LRS：

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" `
    -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerSasToken "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D" `
    -AutoCompleteRestore `
    -LastBackupName "last_backup.bak"

以下Azure CLI示例使用 SAS 令牌在自动完成模式下启动 LRS：

az sql midb log-replay start -g mygroup --mi myinstance -n mymanageddb -a --last-bn "backup.bak"
    --storage-uri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>"
    --storage-sas "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"

以下 PowerShell 示例使用托管标识在自动完成模式下启动 LRS：

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" `
    -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerIdentity ManagedIdentity  `
    -AutoCompleteRestore `
    -LastBackupName "last_backup.bak"

在连续模式下启动 LRS

确保已将初始备份链上传到Azure Blob 存储帐户。

重要

在连续模式下启动 LRS 后，你可以将新的日志和差异备份添加到存储帐户，直到进行手动切换。启动手动直接转换后，无法添加其他差异文件，也无法还原。

SAS 令牌
托管标识

以下 PowerShell 示例使用 SAS 令牌在连续模式下启动 LRS：

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerSasToken "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"

以下Azure CLI示例在连续模式下启动 LRS：

az sql midb log-replay start -g mygroup --mi myinstance -n mymanageddb
    --storage-uri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>"
    --storage-sas "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"

以下 PowerShell 示例使用托管标识在连续模式下启动 LRS：

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerIdentity ManagedIdentity

编写迁移作业脚本

在连续模式下启动 LRS 的 PowerShell 和Azure CLI客户端是同步的。在此模式下，PowerShell 和Azure CLI等待 API 响应在启动作业之前报告成功或失败。

在等待过程中，命令不会将控制权返回给命令提示符。如果你正在编写迁移体验的脚本，并且需要 LRS start 命令立即交还控制权，以便继续执行脚本的其余部分，则可以使用 -AsJob 开关将 PowerShell 作为后台作业运行。例如：

$lrsjob = Start-AzSqlInstanceDatabaseLogReplay <required parameters> -AsJob

启动后台作业后，即使后台作业需要较长时间才能完成，系统也会立即返回一个作业对象。任务运行时，你可以在会话中不受干扰地继续工作。有关将 PowerShell 作为后台作业运行的详细信息，请参阅 PowerShell Start-Job 文档。

同样，若要在 Linux 上启动Azure CLI命令作为后台进程，请在 LRS 启动命令的末尾使用 ampersand （&）：

az sql midb log-replay start <required parameters> &

监视迁移进度

Az.SQL 4.0.0 及更高版本提供了详细的进度报告。查看托管数据库还原详细信息 - 获取以获取示例输出。

若要通过 PowerShell 监视正在进行的迁移进度，请使用以下命令：

Get-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName"

若要通过Azure CLI监视正在进行的迁移进度，请使用以下命令：

az sql midb log-replay show -g mygroup --mi myinstance -n mymanageddb

若要跟踪失败请求的其他详细信息，请使用 PowerShell 命令 Get-AzSqlInstanceOperation或使用 Azure CLI 命令 az sql mi op show。

停止迁移（可选）

如果需要停止迁移，请使用 PowerShell 或Azure CLI。停止迁移会删除托管实例上正在还原的数据库，因此无法恢复迁移。

若要通过 PowerShell 停止迁移过程，请使用以下命令：

Stop-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName"

若要通过Azure CLI停止迁移过程，请使用以下命令：

az sql midb log-replay stop -g mygroup --mi myinstance -n mymanageddb

完成迁移（连续模式）

如果在连续模式下启动 LRS，请确保已停止应用程序和SQL Server工作负荷，以防止生成任何新的备份文件。确保已将SQL Server实例中的最后一个备份上传到Azure Blob 存储帐户。监视托管实例上的还原进度，确保还原了最后一个日志结尾备份。

在托管实例上还原了最后一个日志结尾备份后，启动手动转换来完成迁移。转换完成后，数据库可用于在托管实例上进行读取和写入操作。

若要通过 PowerShell 在 LRS 连续模式下完成迁移过程，请使用以下命令：

Complete-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
-InstanceName "ManagedInstance01" `
-Name "ManagedDatabaseName" `
-LastBackupName "last_backup.bak"

若要通过 Azure CLI 在 LRS 连续模式下完成迁移过程，请使用以下命令：

az sql midb log-replay complete -g mygroup --mi myinstance -n mymanageddb --last-backup-name "backup.bak"

限制

使用 LRS 迁移时，请考虑以下限制：

在迁移过程完成之前，不能使用正在通过 LRS 还原的数据库。
在迁移过程中，迁移的数据库不能用于对SQL 托管实例进行只读访问。
迁移结束后，迁移过程就终止了，无法通过其他差异备份恢复。
LRS 仅支持数据库 .bak、.log 和 .diff 文件。不支持 Dacpac 和 bacpac 文件。
必须配置维护时段，在特定日期和时间安排系统更新。计划在安排的维护时段外运行并完成迁移。
在没有 CHECKSUM 的情况下进行的数据库备份：
- 可能会迁移损坏的数据库。
- 与启用 CHECKSUM 的数据库备份相比，花费更多时间来还原。
必须为整个 Azure Blob 存储容器生成供 LRS 使用的共享访问签名（SAS）令牌，并且该令牌只能具有 Read 和 List 权限。例如，如果授予 Read、List 和 Write 权限，则由于额外的 Write 权限，LRS 无法启动。
不支持创建通过定义存储访问策略并设置权限的 SAS 令牌。按照本文中的说明手动指定 SAS 令牌的读取和列出权限。
必须将不同数据库的备份文件放在平面文件结构中Blob 存储帐户上的单独文件夹中。不支持数据库文件夹内的嵌套文件夹。
如果使用自动完成模式，则需要在 Blob 存储帐户上提前提供整个备份链。无法在自动完成模式下添加新备份文件。如果需要在迁移正在进行期间添加新备份文件，请使用连续模式。
必须针对指向包含单个数据库文件夹的完整 URI 路径的每个数据库单独启动 LRS。
备份 URI 路径、容器名称或文件夹名称不能包含 backup 或 Backup 因为这些是保留关键字。
在针对同一存储容器并行启动多个日志重播还原时，请确保为每个还原操作提供相同的有效的 SAS 令牌。
LRS 支持将数据库的总数量迁移到单个实例，直到达到服务层的资源限制。例如，可以在 “常规用途 ”服务层级中还原最多 100 个数据库，以及 下一代常规用途 服务层级中最多 500 个数据库总数。
LRS 支持同时将 100 个数据库还原到单个实例，单个订阅中所有实例总共支持 150 个同时数据库还原。例如，可以同时将 100 个数据库并行还原到同一订阅中的两个实例，也可以将三个同时批处理中的 50 个数据库并行还原到同一订阅中的四个单独的实例。
单个 LRS 作业最多可以运行 30 天，之后会自动取消。
虽然可以在防火墙后面使用Azure 存储帐户，但需要额外的配置，并且存储帐户和托管实例必须位于同一区域或两个配对区域。有关详细信息，请参阅配置防火墙。
可以并行还原的数据库的最大数量是每个订阅 150 个。在某些情况下，可通过开具支持票证来增加此限制。
上传数千个数据库文件进行还原可能会导致迁移时间过长，甚至失败。将数据库合并到更少的文件中来加快迁移过程，并确保迁移成功。
有两个场景，分别在迁移过程的开始和结束：在这些场景中，如果发生故障转移，迁移将中止，并且必须从头手动重启迁移作业，因为数据库会从 SQL 托管实例中删除。
- 如果在首次启动迁移作业时，将第一个完整数据库备份还原到SQL 托管实例发生故障转移，则必须从一开始就手动重启迁移作业。
- 如果启动迁移直接转换后发生故障转移，则必须从头开始手动重启迁移作业。确保最后一个备份文件尽可能小，以缩短切换时间，并降低切换过程中故障转移的风险。
如果在源 SQL Server 2019 及更高版本的实例上禁用了加速数据库恢复，则在迁移到 Azure SQL 托管实例后将无法再启用它。此外，如果未将持久性版本存储（PVS）设置为 PRIMARY，则可能会遇到目标 SQL 托管实例上的还原作问题。
如果在源SQL Server实例上禁用了 Service Broker，则迁移后无法在目标 SQL 托管实例上使用 Service Broker。

注意

如果在迁移过程中需要只读访问数据库，并且希望迁移时间框架较长且停机时间最小，建议使用托管实例概述功能作为迁移解决方案。

迁移到业务关键服务层级时的限制

迁移到 Business Critical 服务层级中的SQL 托管实例时，请考虑以下限制：

迁移大型数据库时，可能会有相当长的停机时间，原因如下：在切换后，数据库在播种到业务关键服务层级的次要副本期间，数据库是不可用的。有关解决方法，请参阅更长时间的直接转换部分。
如果迁移被计划外故障转移、系统更新或安全修补程序中断，迁移会从头开始自动重启，因此很难规划可预测的迁移，而不会造成最后一刻的意外。

重要

这些限制仅适用于迁移到 “业务关键”服务层级的情况，不适用于“常规用途”服务层级的情况。

业务关键服务层级中的较长切换时间

如果要迁移到 Business Critical 服务层级中的 SQL 托管实例，需要考虑在将数据库复制到次要副本时，使主副本的数据库联机的延迟。这尤其适用于大型数据库。

迁移到 SQL 托管实例 Business Critical 服务层级需要比常规用途服务层级更长的时间才能完成。在切换到 Azure 完成后，数据库将不可用，直到主副本与三个次要副本同步，这可能需要很长时间，具体取决于数据库的大小。数据库越大，播种到次要副本耗时更长，可能需要长达数小时的时间。

如果在切换完成后数据库立即可用很重要，请考虑以下解决方法：

首先迁移到常规用途服务层，然后升级到 业务关键 服务层级。升级服务层级是一项联机操作，它使数据库保持联机状态，直到短暂的故障转移（这是在升级操作的最后一步）。
使用托管实例链接在线迁移到 Business Critical 实例，而无需等待数据库在切换后可用。

迁移到 SQL 托管实例后的已知问题

迁移到Azure SQL 托管实例后，请考虑以下已知问题：

迁移到SQL 托管实例后还原操作失败

如果将数据库从 SQL Server 2019 及更高版本迁移到 Azure SQL 托管实例，并且启用了 accelerated 数据库恢复，但配置了持久性版本存储（PVS）设置为除 PRIMARY 文件组以外的其他版本，则可以在目标 SQL 托管实例上遇到还原操作失败。

若要解决此问题，请确保将源SQL Server数据库上的 persistent 版本存储（PVS）设置为 PRIMARY，然后再将其迁移到SQL 托管实例。如果已迁移数据库而不将 PVS 设置为 PRIMARY，则可以在源SQL Server数据库上设置该数据库，然后将数据库重新迁移到SQL 托管实例。

迁移到SQL 托管实例后无法使用加速数据库恢复

从 SQL Server 2019 开始，如果将数据库迁移到 Azure SQL 托管实例，并且源数据库已禁用 accelerated 数据库恢复，则无法在目标 SQL 托管实例上使用加速数据库恢复。

若要解决此问题，在将源SQL Server数据库迁移到SQL 托管实例之前，请确保可启用加速数据库恢复。如果已在未启用加速数据库恢复的情况下迁移数据库，则可以在源SQL Server数据库上启用该数据库，然后将数据库重新迁移到 SQL 托管实例。

SQL Server 2017 和早期版本不支持加速数据库恢复，因此此问题不适用于从这些版本的SQL Server迁移的数据库。

迁移到 SQL 托管实例后无法使用 Service Broker

如果将数据库迁移到 Azure SQL 托管实例，并且源数据库上禁用了 Service Broker，则无法在目标 SQL 托管实例上使用 Service Broker。

若要解决此问题，请确保在将源SQL Server数据库上启用 Service Broker，然后再将其迁移到SQL 托管实例。如果已在未启用 Service Broker 的情况下迁移数据库，则可以在源SQL Server数据库上启用它，然后将数据库重新迁移到SQL 托管实例。

排查 LRS 问题

启动 LRS 后，请使用以下任一监视 cmdlet 查看正在进行的操作的状态：

对于 PowerShell：get-azsqlinstancedatabaselogreplay
对于 Azure CLI ：az_sql_midb_log_replay_show

若要查看有关失败操作的详细信息，请执行以下操作：

对于 PowerShell：Get-AzSqlInstanceOperation
对于 Azure CLI：az sql mi op show

如果一段时间后 LRS 无法启动，并且出现错误，请检查最常见的问题：

托管实例上的现有数据库是否与尝试从SQL Server实例迁移的名称相同？可通过重命名其中一个数据库来解决此冲突。
授予 SAS 令牌的权限是否只有读取和列出？授予超出 Read 和 List 的权限会导致 LRS 失败。
是否在问号 (?) 后开始复制用于 LRS 的 SAS 令牌，内容类似于 sv=2020-02-10...？
SAS 令牌的有效时间是否适用于启动和完成迁移的时间范围？由于用于SQL 托管实例部署和 SAS 令牌的不同时区，可能会出现不匹配的情况。尝试重新生成 SAS 令牌，并将令牌有效期延长到当前日期之前和之后的时间窗口。
在针对同一存储容器并行启动多个日志重播还原时，请确保为每个还原操作提供相同的有效的 SAS 令牌。
数据库名称、资源组名称和托管实例名称的拼写是否正确？
如果在自动完成模式下启动 LRS，是否为最后一个备份文件指定了有效文件名？
备份 URI 路径是否包含关键字 backup 或 backups？重命名使用 backup 或 backups 的容器或文件夹，因为它们是保留关键字。

反馈

此页面是否有帮助？

Last updated on 2026-04-17