Log Replay Service を使用して SQL Server からデータベースを移行する - Azure SQL Managed Instance

適用対象:Azure SQL Managed Instance

この記事では、ログ再生サービス (LRS)を使用してデータベースを Azure SQL Managed Instance に移行する方法について説明します。 LRS は、SQL Server のログ配布テクノロジに基づく無料のクラウド サービスであり、Azure SQL Managed Instance に利用できます。

次のソースがサポートされています。

• SQL Server on Virtual Machines
• Amazon EC2 (Elastic Compute Cloud)
• SQL Server 用 Amazon RDS (Relational Database Service)
• Google Compute Engine
• Cloud SQL for SQL Server - GCP (Google Cloud Platform)

前提条件

開始する前に、SQL Server インスタンスと Azure の両方の要件について、このセクションの要件を検討してください。 移行を確実に成功させるために、「制限事項」と「ベスト プラクティス」のセクションを慎重に確認してください。

SQL Server

SQL Server に関する次の要件を満たしていることを確認します。

• SQL Server バージョン 2008 から 2022。
• SQL Server データベースで完全復旧モデルを使用していること (必須)。
• データベースの完全バックアップ (1 つまたは複数のファイル)。
• 差分バックアップ (1 つまたは複数のファイル)。
• ログ バックアップ (トランザクション ログ ファイル用に分割されていない)。
• SQL Server バージョン 2008 から 2016 の場合は、ローカル環境でバックアップを作成し、それを Azure Blob Storage アカウントに手動でアップロードします。
• SQL Server 2016 以降では、Azure Blob Storage アカウントに直接バックアップすることができます。
• バックアップに対して CHECKSUM を有効にすることは必須ではありませんが、破損したデータベースを誤って移行するのを防ぎ、復元操作を高速化するために、有効にすることを強くお勧めします。

Azure

Azure に関する次の要件を満たしていることを確認します。

• PowerShell Az.SQL モジュール バージョン 4.0.0 以降 (インストールされているか、Azure Cloud Shell 経由でアクセスできること)。
• Azure CLI バージョン 2.42.0 以降 (インストールされていること)。
• プロビジョニングされた Azure Blob Storage コンテナー。
• Blob Storage コンテナー用に生成された Read と List のアクセス許可が付与されている Shared Access Signature (SAS) セキュリティ トークン、またはそのコンテナーにアクセスできるマネージド ID。 Read と List 以外のアクセス許可を付与すると、LRS が失敗します。
• 個々のデータベースのバックアップ ファイルを、フラットファイル構造を使用してストレージ アカウント内の個別のフォルダー内に配置する (必須)。 データベース フォルダー内の入れ子になったフォルダーはサポートされていません。

Azure RBAC アクセス許可

指定したクライアントを介して LRS を実行するには、次のいずれかの Azure ロールベースのアクセス制御 (RBAC) のロールが必要です。

• SQL Managed Instance 共同作成者ロール
• 次のアクセス許可を持つロール: Microsoft.Sql/managedInstances/databases/*

ベスト プラクティス

LRS を使用する場合は、次のベスト プラクティスを考慮します。

• Data Migration Assistant を実行して、データベースを SQL Managed Instance に移行する準備ができていることを確認します。
• 1 つのファイルを使用するのではなく、完全バックアップと差分バックアップを複数のファイルに分割します。
• バックアップ圧縮を有効にして、ネットワーク転送速度を向上させます。
• 最新リリースのコマンドレットを使うように常に更新されるため、PowerShell または CLI スクリプトを実行するには Cloud Shell を使います。
• 移行の遅延や中断を防ぐために、システムの更新が移行期間外の特定の日時にスケジュールされるようにメンテナンス期間を構成します。
• 最大 30 日以内に 1 つの LRS 移行ジョブを完了するように計画します。 この期間が終了すると、LRS ジョブは自動的に取り消されます。
• 破損したデータベースを誤って移行するのを防ぎ、データベースの復元を高速化するために、バックアップを作成するときに CHECKSUM を有効にします。 CHECKSUM を有効にしなくても SQL Managed Instance により、バックアップに対して基本的な整合性チェックは実行されますが、すべての形態の破損を検出できる保証はありません。 CHECKSUM を有効にしてバックアップを作成することは、SQL Managed Instance に復元されたバックアップが破損していないことを保証する唯一の方法です。 CHECKSUM が有効ではないバックアップに対して基本的な整合性チェックを実行すると、データベースの復元時間が長くなります。
• Business Critical サービス レベルに移行する場合、データベースがセカンダリ レプリカにシード処理されている間、一括移行後のデータベースの可用性が長時間遅延することを考慮します。 特にダウンタイム要件が最小限である大規模なデータベースの場合は、まず General Purpose サービス レベルに移行してから Business Critical サービス レベルにアップグレードするか、Managed Instance リンクを使用してデータを移行することを検討します。
• 復元のために何千ものデータベース ファイルをアップロードすると、移行時間が長くなりすぎる可能性があり、失敗する場合さえあります。 移行プロセスを高速化し、確実に成功するには、データベースを少数のファイルに統合します。
• カットオーバー時間を最小限に抑え、障害のリスクを軽減するには、最後のバックアップが可能な限り小さいことを確認します。

メンテナンス期間を構成する

SQL Managed Instance のシステム更新は、進行中のデータベース移行より優先されます。

移行の影響は、サービス レベルによって異なります。

• General Purpose サービス レベルでは、保留中のすべての LRS 移行が中断され、更新が適用された後にのみ再開されます。 このシステム動作によって、特に大規模なデータベースでは、移行時間が長くなる可能性があります。
• Business Critical サービス レベルでは、保留中のすべての LRS 移行が取り消され、更新が適用された後に自動的に再開されます。 このシステム動作によって、特に大規模なデータベースでは、移行時間が長くなる可能性があります。

データベースの移行の時間を予測できるようにするために、システムの更新が特定の日時にスケジュールされるようにメンテナンス期間を構成することを検討し、指定したメンテナンス期間の概算時間外に移行ジョブを実行して完了します。 たとえば、月曜日に移行を開始する場合、移行を完了するための時間を最大限に確保するために、カスタム メンテナンス期間を日曜日にスケジュールするように構成します。

メンテナンス期間の構成は必須ではありませんが、大規模なデータベースの場合は強くお勧めします。

複数のデータベースを移行する

同じ Azure Blob Storage コンテナーを使用して複数のデータベースを移行する場合は、異なるデータベースのバックアップ ファイルをコンテナー内の別々のフォルダーに配置する必要があります。 1 つのデータベースのすべてのバックアップ ファイルを、データベース フォルダー内のフラットファイル構造に配置する必要があり、フォルダーを入れ子にすることはできません。 データベース フォルダー内の入れ子になったフォルダーはサポートされていません。

次に示すのは、Azure Blob Storage コンテナー内のフォルダー構造の例であり、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 Storage アカウントは、SQL Server インスタンスと SQL Managed Instance デプロイの間の、バックアップ ファイル用の中間ストレージとして使用します。 新しいストレージ アカウントと、ストレージ アカウント内の BLOB コンテナーを作成するには:

1. ストレージ アカウントの作成。
2. ストレージ アカウント内に BLOB コンテナーを作成します。

ファイアウォールの内側に Azure Storage を構成する

ファイアウォールの内側で保護されている Azure Blob Storage の使用はサポートされていますが、追加の構成が必要です。 Azure Firewall が有効になっている Azure Storage への読み取りと書き込みのアクセスを有効にするには、MI サブネットの委任と Storage サービス エンドポイントを使用して、ストレージ アカウント用の仮想ネットワークのファイアウォール規則に、SQL マネージド インスタンスのサブネットを追加する必要があります。 ストレージ アカウントとマネージド インスタンスは、同じリージョン内またはペアになった 2 つのリージョンに存在する必要があります。

Azure Storage がファイアウォールの内側にある場合は、SQL マネージド インスタンスのエラー ログに次のメッセージが記録されることがあります。

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

これにより、SQL マネージド インスタンスの監査でストレージ アカウントへの監査ログの書き込みが失敗したことをユーザーに通知するメールが生成されます。 このエラーが表示された場合、またはこのメールを受け取った場合は、このセクションの手順に従ってファイアウォールを構成します。

ファイアウォールを構成するには、次の手順のようにします。

1. Azure portal でマネージド インスタンスに移動し、サブネットを選んで [サブネット] ページを開きます。

   

2. [サブネット] ページで、サブネットの名前を選んでサブネット構成ページを開きます。

   

3. [サブネット委任] で、[サブネットをサービスに委任] ドロップダウン メニューから Microsoft.Sql/managedInstances を選びます。 アクセス許可が反映されるまで約 1 時間待ってから、[サービス エンドポイント] の [サービス] ドロップダウンで Microsoft.Storage を選びます。

   

4. 次に、Azure portal でお使いのストレージ アカウントに移動し、[セキュリティとネットワーク] で [ネットワーク] を選んだ後、[ファイアウォールと仮想ネットワーク] タブを選びます。

5. ストレージ アカウントの [ファイアウォールと仮想ネットワーク] タブで、[+ 既存の仮想ネットワークを追加する] を選んで [ネットワークの追加] ページを開きます。

   

6. ドロップダウン メニューから適切なサブスクリプション、仮想ネットワーク、マネージド インスタンス サブネットを選んでから [追加] を選び、SQL マネージド インスタンスの仮想ネットワークをストレージ アカウントに追加します。

Blob Storage アカウントに対して認証を行う

Azure Blob Storage アカウントにアクセスするには、SAS トークンまたはマネージド ID を使います。

マネージド インスタンスのストレージ アクセスを検証する

お使いのマネージド インスタンスで Blob Storage アカウントにアクセスできることを検証します。

最初に、full_0_0.bak などのデータベース バックアップを Azure Blob Storage コンテナーにアップロードします。

次に、マネージド インスタンスに接続し、サンプル テスト クエリを実行して、マネージド インスタンスでコンテナー内のバックアップにアクセスできるかどうかを確認します。

CREATE CREDENTIAL [https://mitutorials.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' 

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 Storage アカウントにバックアップをアップロードする

BLOB コンテナーの準備が整い、マネージド インスタンスでそのコンテナーにアクセスできることを確認したら、Blob Storage アカウントへのバックアップのアップロードを開始できます。 次のいずれかを実行できます。

• Blob Storage アカウントにバックアップをコピーします。
• 環境で許される場合は (SQL Server バージョン 2012 SP1 CU2 および SQL Server 2014 以降)、BACKUP TO URL コマンドを使って、SQL Server から Blob Storage アカウントにバックアップを直接作成します。

既存のバックアップを Blob Storage アカウントにコピーする

以前のバージョンの SQL Server を使っている場合、またはお使いの環境で URL への直接バックアップがサポートされていない場合は、通常どおり、SQL Server インスタンスでバックアップを作成し、それを Blob Storage アカウントにコピーします。

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 Storage アカウントにコピーする

バックアップの準備が整い、LRS を使用してマネージド インスタンスへのデータベースの移行を開始できるようになったら、次の方法を使って、既存のバックアップを Blob Storage アカウントにコピーできます。

• AzCopy をダウンロードしてインストールします。
• Azure Storage Explorer をダウンロードしてインストールします。
• Azure portal で Storage Explorer を使います。

Blob Storage アカウントに直接バックアップする

サポートされているバージョンの SQL Server を使用しており (SQL Server 2012 SP1 CU2 および SQL Server 2014 以降)、企業およびネットワーク ポリシーで許可されている場合は、SQL Server ネイティブの BACKUP TO URL オプションを使って、SQL Server から Blob Storage アカウントに直接バックアップすることができます。 BACKUP TO URL を使用できる場合は、バックアップをローカル ストレージに作成してそれを Blob Storage アカウントにアップロードする必要はありません。

ネイティブのバックアップを Blob Storage アカウントに直接作成するときは、ストレージ アカウントに対する認証を行う必要があります。

次のコマンドを使用して、SAS トークンを SQL Server インスタンスにインポートする資格情報を作成します。

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

SAS トークンを使用する詳細な手順については、Azure Blob Storage と SQL Server の使用に関するチュートリアルを参照してください。

Blob Storage で 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

Azure にサインインしてサブスクリプションを選択する

次の PowerShell コマンドレットを使って Azure にサインインします。

Login-AzAccount

次の PowerShell コマンドレットを使って、マネージド インスタンスが存在するサブスクリプションを選びます。

Select-AzSubscription -SubscriptionId <subscription ID>

移行を開始する

移行を開始するには、LRS を開始します。 サービスは "オートコンプリート" または "連続" モードで開始できます。

オートコンプリート モードを使用する場合、指定した最後のバックアップ ファイルが復元されると、移行が自動的に完了します。 このオプションでは、バックアップ チェーン全体を事前に使用でき、Blob Storage アカウントにアップロードできる必要があります。 移行の進行中に新しいバックアップ ファイルを追加することはできません。 このオプションでは、最後のバックアップ ファイルのファイル名を start コマンドで指定する必要があります。 データのキャッチアップが必要ないパッシブ ワークロードの場合は、このモードをお勧めします。

連続モードを使うと、サービスは Azure Blob Storage フォルダーを継続的にスキャンし、移行の進行中に追加される新しいバックアップ ファイルを復元します。 移行は、手動一括移行が要求された後でのみ完了します。 バックアップ チェーン全体が事前に存在しない場合や、移行の進行中に新しいバックアップ ファイルを追加する予定がある場合は、連続モードの移行を使用する必要があります。 データのキャッチアップが必要なアクティブ ワークロードの場合は、このモードをお勧めします。

最大 30 日以内に 1 つの LRS 移行ジョブを完了するように計画します。 この時間が経過すると、LRS ジョブは自動的に取り消されます。

LRS をオートコンプリート モードで開始する

バックアップ チェーン全体が Azure Blob Storage アカウントにアップロードされていることを確認します。 このオプションでは、移行の進行中に新しいバックアップ ファイルを追加することはできません。

LRS をオートコンプリート モードで開始するには、PowerShell または Azure CLI コマンドを使用します。 -LastBackupName パラメーターを使用して、最後のバックアップ ファイル名を指定します。 最後に指定されているバックアップ ファイルの復元が完了すると、サービスは自動的に一括移行を開始します。

SAS トークンまたはマネージド ID を使って、データベースをストレージ アカウントから復元します。

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"

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"

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 Storage アカウントにアップロードしたことを確認します。

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"

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"

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 start コマンドの最後にアンパサンド (&) 記号を使用します。

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

移行の進行状況を監視する

Az.SQL 4.0.0 以降では、詳細な進行状況レポートが提供されます。 サンプル出力については、「マネージド データベースの復元の詳細 - Get」を参照してください。

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 Storage アカウントにアップロードされていることを確認します。 マネージド インスタンスで復元の進行状況を監視し、最後のログ末尾のバックアップが復元されたことを確認します。

マネージド インスタンスで最後のログ末尾のバックアップが復元されたら、手動一括移行を開始して移行を完了します。 一括移行が完了すると、データベースはマネージド インスタンスで読み取りおよび書き込みアクセスができるようになります。

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 Managed Instance 上での読み取り専用アクセスで使用することはできません。
• 移行が完了すると、移行プロセスは確定し、追加の差分バックアップを使用して再開することはできません。
• LRS では、データベースの .bak、.log、および .diff ファイルのみがサポートされています。 dacpac ファイルと bacpac ファイルはサポートされていません。
• 特定の日時にシステムの更新をスケジュールするようにメンテナンス期間を構成する必要があります。 スケジュールされたメンテナンス期間外に移行の実行と完了を計画します。
• CHECKSUM を有効にしないでデータベースのバックアップを作成した場合:
  • 破損したデータベースを移行する可能性があります。
  • CHECKSUM を有効にしたデータベースのバックアップよりも復元に時間がかかります。
• LRS によって使用される Shared Access Signature (SAS) トークンは、Azure Blob Storage コンテナー全体に対して生成する必要があり、Read と List のアクセス許可のみを付与する必要があります。 たとえば、Read、List、Write のアクセス許可を付与すると、Write アクセス許可が余分であるため、LRS を起動できません。
• 保存されているアクセス ポリシーの定義によって設定されたアクセス許可を使用して作成された SAS トークンの使用はサポートされていません。 この記事の指示に従って、SAS トークンの読み取りと一覧表示のアクセス許可を手動で指定してください。
• 異なるデータベースのバックアップ ファイルは、Blob Storage アカウント上の個別のフォルダーにフラットファイル構造で配置する必要があります。 データベース フォルダー内の入れ子になったフォルダーはサポートされていません。
• オートコンプリート モードを使用する場合は、Blob Storage アカウントでバックアップ チェーン全体を事前に使用できる必要があります。 オートコンプリート モードで新しいバックアップ ファイルを追加することはできません。 移行の進行中に新しいバックアップ ファイルを追加する必要がある場合は、連続モードを使用します。
• LRS は、個々のデータベース フォルダーを含む完全な URI パスを指すデータベースごとに個別に開始する必要があります。
• バックアップ URI パス、コンテナー名、またはフォルダー名に、backup または backups を含めないでください。これらは予約済キーワードです。
• 同じストレージ コンテナーをターゲットにして複数のログ再生の復元を並列で開始する場合は、復元操作ごとに同じ有効な SAS トークンが提供されていることを確認します。
• LRS は、1 つのマネージド インスタンスごとに最大 100 個の同時復元プロセスをサポートできます。
• 1 つの LRS ジョブは最大 30 日間実行でき、その後は自動的に取り消されます。
• ファイアウォールの内側の Azure ストレージ アカウントを使うことはできますが、追加の構成が必要であり、ストレージ アカウントとマネージド インスタンスが、同じリージョン内またはペアになった 2 つのリージョンに存在する必要があります。 詳しくは、ファイアウォールの構成に関する記事をご覧ください。
• 並行して復元できるデータベースの最大数は、1 つのサブスクリプションにつき 200 個です。 サポート チケットを開くことで、この制限を引き上げることができる場合があります。
• 復元のために何千ものデータベース ファイルをアップロードすると、移行時間が長くなりすぎる可能性があり、失敗する場合さえあります。 移行プロセスを高速化し、確実に成功するには、データベースを少数のファイルに統合します。
• 移行プロセスの開始時と終了時には、フェールオーバーが発生した場合に移行が中止され、SQL Managed Instance からデータベースが削除されるときに移行ジョブを最初から手動で再起動する必要がある 2 つのシナリオがあります。
  • 最初にデータベースの完全バックアップが SQL Managed Instance に復元されるときにフェールオーバーが発生した場合、移行ジョブは最初から手動で再起動する必要があります。
  • 移行のカットオーバーが開始された後にフェールオーバーが発生した場合は、移行ジョブを最初から手動で再起動する必要があります。 カットオーバー時間を最小限に抑え、カットオーバー プロセス中のフェールオーバーのリスクを軽減するために、最後のバックアップ ファイルができるだけ小さいことを確認します。

Business Critical サービス レベルに移行する際の制限事項

Business Critical サービス レベルの SQL Managed Instance に移行する場合、次の制限事項を考慮します。

• 大規模なデータベースを移行する場合、データベースが Business Critical サービス レベルのセカンダリ レプリカにシード処理されている間、一括移行後にデータベースが使用できないため、かなりのダウンタイムが発生する可能性があります。 回避策は、「一括移行の時間が長くなる」セクションに示してあります。
• 計画外のフェールオーバー、システムの更新、またはセキュリティ パッチによって移行が中断された場合、移行は最初から自動的に再開されます。このため、直前に予期しない事態が発生しない予測可能な移行を計画することは困難です。

Business Critical サービス レベルでの一括移行の時間が長くなる

Business Critical サービス レベルの SQL Managed Instance に移行する場合、データベースがセカンダリ レプリカにシード処理されている間、プライマリ レプリカでデータベースがオンラインになるまで遅延が生じることを考慮してください。 これは、特に大規模なデータベースの場合に当てはまります。

Business Critical サービス レベルの SQL Managed Instance への移行は、General Purpose サービス レベルの場合よりも完了するまでに時間がかかります。 Azure への一括移行が完了した後、データベースは、プライマリ レプリカから 3 つのセカンダリ レプリカにシード処理されるまで使用できません。データベースのサイズによっては、このシード処理に長時間かかる場合があります。 データベースが大きいほど、セカンダリ レプリカへのシード処理にかかる時間が長くなり、最大で数時間かかる可能性があります。

一括移行が完了したらすぐにデータベースを使用できるようにする必要がある場合は、次の回避策を検討してください。

• まず General Purpose サービス レベルに移行してから、Business Critical サービス レベルにアップグレードします。 サービス レベルのアップグレードはオンライン操作であり、アップグレード操作の最後のステップとして短いフェールオーバーが行われるまでデータベースはオンラインのままです。
• 一括移行後にデータベースが使用可能になるまで待たずに Business Critical インスタンスへのオンライン移行を実行するには、Managed Instance リンクを使用します。

LRS の問題のトラブルシューティング

LRS を開始した後は、次のいずれかの監視コマンドレットを使って、実行中の操作の状態を確認します。

• 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 Managed Instance のデプロイと SAS トークンで、使われているタイム ゾーンが異なるため、一致していない可能性があります。 時間枠のトークンの有効期間を現在の日付より前および後に拡張して、SAS トークンを再生成してみてください。
• 同じストレージ コンテナーをターゲットにして複数のログ再生の復元を並列で開始する場合は、復元操作ごとに同じ有効な SAS トークンが提供されていることを確認します。
• データベース名、リソース グループ名、マネージド インスタンス名のスペルは正しいですか?
• LRS をオートコンプリート モードで開始した場合、最後のバックアップ ファイルに有効なファイル名を指定しましたか?
• バックアップ URI パスにキーワード backup または backups が含まれていますか? backup または backups は予約済みキーワードであるため、使用しているコンテナーまたはフォルダーの名前を変更します。

次のステップ

• リンク機能を使用した Azure SQL Managed Instance への移行についての詳細を理解します。
• SQL Server から Azure SQL Managed Instance への移行についての詳細を理解します。
• SQL Server と SQL Managed Instance の違いについての詳細を理解します。
• Azure に移行するワークロードのコストとサイズ設定のベスト プラクティスについて学ぶ。