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

[アーティクル]
11/04/2024

この記事では、ログ再生サービス (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 の両方に関する次の要件を検討してください。移行を確実に成功させるために、「制限事項」と「ベストプラクティス」のセクションを慎重に確認してください。

重要

データベースを Business Critical サービスレベルに移行する前に、以下に示す制限事項を検討してください。これらは General Purpose サービスレベルには適用されません。
移行プロセスが完了するまで、LRS で復元されているデータベースを使うことはできません。
移行中のデータベースに対する読み取り専用アクセスは、LRS ではサポートされていません。
移行が完了すると、移行プロセスは確定し、追加の差分バックアップを使用して再開することはできません。

データベースを Business Critical サービスレベルに移行する前に、以下に示す制限事項を検討してください。これらは General Purpose サービスレベルには適用されません。

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 移行が取り消され、更新が適用された後に自動的に再開されます。このシステム動作によって、特に大規模なデータベースでは、移行時間が長くなる可能性があります。

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

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

Note

メンテナンス期間により、"計画された" 更新の予測可能性を制御できますが、計画外のフェールオーバーやセキュリティパッチ更新プログラムが発生しないという保証はありません。計画外のフェールオーバーまたはセキュリティパッチ (他のすべての更新よりも優先されます) によって、移行が中断される可能性があります。

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

同じ 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 コンテナーを作成するには:

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

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

Azure portal でマネージドインスタンスに移動し、サブネットを選んで [サブネット] ページを開きます。
[サブネット] ページで、サブネットの名前を選んでサブネット構成ページを開きます。
[サブネット委任] で、[サブネットをサービスに委任] ドロップダウンメニューから Microsoft.Sql/managedInstances を選びます。アクセス許可が反映されるまで約 1 時間待ってから、[サービスエンドポイント] の [サービス] ドロップダウンで Microsoft.Storage を選びます。
次に、Azure portal でお使いのストレージアカウントに移動し、[セキュリティとネットワーク] で [ネットワーク] を選んだ後、[ファイアウォールと仮想ネットワーク] タブを選びます。
ストレージアカウントの [ファイアウォールと仮想ネットワーク] タブで、[+ 既存の仮想ネットワークを追加する] を選んで [ネットワークの追加] ページを開きます。
ドロップダウンメニューから適切なサブスクリプション、仮想ネットワーク、マネージドインスタンスサブネットを選んでから [追加] を選び、SQL マネージドインスタンスの仮想ネットワークをストレージアカウントに追加します。

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

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

警告

同じストレージアカウントで SAS トークンとマネージド ID の両方を並行して使用することはできません。 SAS トークン "または" マネージド ID の "いずれか" を使うことはできますが、両方を使うことはできません。

SAS トークン
管理対象 ID

Blob Storage の LRS 用の SAS 認証トークンを生成する

SAS トークンを使って Azure Blob Storage アカウントにアクセスします。

Azure Blob Storage アカウントは、SQL Server インスタンスと SQL Managed Instance デプロイの間の、バックアップファイル用の中間ストレージとして使用できます。読み取りと一覧表示のアクセス許可のみを持つ、LRS 用の SAS 認証トークンを生成します。このトークンを使うと、LRS で Blob Storage アカウントにアクセスし、バックアップファイルを使ってマネージドインスタンスにそれを復元できます。

トークンを生成するには、次の手順を実行します。

Azure portal で Storage Explorer を開きます。
[BLOB コンテナー] を展開します。
BLOB コンテナーを右クリックして、 [Shared Access Signature の取得] を選択します。
トークンの有効期限までの期間を選択します。移行中、トークンが確実に有効であるようにします。
トークンのタイムゾーン (UTC または現地時間) を選択します。

重要

トークンとご利用のマネージドインスタンスのタイムゾーンが一致していない場合があります。タイムゾーンを考慮した適切な有効期間を SAS トークンに確実に設定するようにします。タイムゾーンの違いを考慮し、有効期間の FROM 値を移行期間の開始よりかなり前に設定し、TO 値を移行の完了予定よりかなり後に設定します。
読み取りとリストのアクセス許可のみを選択します。

重要

他のアクセス許可は選択しないでください。行うと、LRS は起動しません。このセキュリティ要件は仕様です。
[作成] を選択します。

指定した有効期限を持つ SAS 認証が生成されます。次のスクリーンショットに示すように、URI バージョンのトークンが必要です。

URI バージョンの SAS トークンを示すスクリーンショット。

Note

現時点では、保存されているアクセスポリシーの定義によって設定されたアクセス許可で作成された SAS トークンの使用はサポートされていません。この手順に従って、SAS トークンに読み取りと一覧表示のアクセス許可を手動で指定します。

SAS トークンからパラメーターをコピーする

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

SAS トークンを使用して LRS を開始する前に、その構造を理解しておく必要があります。生成された SAS トークンの URI は、次の例に示すように、疑問符 (?) で区切られた 2 つの部分で構成されています。

Log Replay Service 用に生成された SAS トークンの URI の例。

https:// から疑問符 (?) までの前半部分は、LRS への入力として指定する StorageContainerURI パラメーターに使用します。これにより、データベースバックアップファイルが格納されているフォルダーの情報が LRS に提供されます。

疑問符 (?) の後から文字列の終わりまでの後半部分は、StorageContainerSasToken パラメーターです。この部分が実際の署名付き認証トークンで、指定した期間有効です。この部分は、必ずしも例のように sp= で始まる必要はありません。シナリオが異なる場合があります。

次のようにパラメーターをコピーします。

https:// から疑問符 (?) の前までのトークンの最初の部分をコピーします。 LRS を始めるとき、PowerShell または Azure CLI の StorageContainerUri パラメーターとしてこれを使います。
トークンの疑問符 (?) の後から文字列の終わりまでの後半部分をコピーします。 LRS を始めるとき、PowerShell または Azure CLI の StorageContainerSasToken パラメーターとしてこれを使います。

Note

トークンのどちらの部分をコピーする際も、疑問符 (?) は含めないようにしてください。

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

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

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

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

SAS トークン
管理対象 ID

ストレージアカウントに対する認証に SAS トークンを使用している場合は、<sastoken> を自分の SAS トークンに置き換え、自分のインスタンスで次のクエリを実行します。

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'

ストレージアカウントに対する認証にマネージド ID を使用している場合は、CREATE CREDENTIAL をストレージアカウントの URL で更新して、インスタンスで次のサンプルクエリを実行します。

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 を使います。

Note

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

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

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

Login-AzAccount

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

Select-AzSubscription -SubscriptionId <subscription ID>

移行を開始する

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

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

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

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

Note

複数のデータベースを移行する場合は、各データベースを独自のフォルダー内に配置する必要があります。 LRS はデータベースごとに個別に開始し、Azure Blob Storage コンテナーと個々のデータベースフォルダーの完全な URI パスを指すようにする必要があります。データベースフォルダー内の入れ子になったフォルダーはサポートされていません。

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

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

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

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

重要

オートコンプリートモードで移行を始める前に、バックアップチェーン全体が Azure Blob Storage アカウントにアップロードされていることを確認します。このモードでは、移行の進行中に新しいバックアップファイルを追加することはできません。
最後のバックアップファイルが正しく指定されていることと、その後にさらにファイルがアップロードされていないことを確認します。最後に指定したバックアップファイル以降のバックアップファイルがシステムによって検出された場合、移行は失敗します。

SAS トークン
管理対象 ID

次の 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 の例では、マネージド ID を使ってオートコンプリートモードで 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 Storage アカウントにアップロードしたことを確認します。

重要

連続モードで LRS を開始した後は、手動一括移行を行うまで、新しいログと差分バックアップをストレージアカウントに追加できます。手動一括移行が開始された後では、追加の差分ファイルを追加することも、復元することもできません。

SAS トークン
管理対象 ID

次の 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 の例では、マネージド ID を使って連続モードで 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 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 個です。サポートチケットを開くことで、この制限を引き上げることができる場合があります。
復元のために何千ものデータベースファイルをアップロードすると、移行時間が長くなりすぎる可能性があり、失敗する場合さえあります。移行プロセスを高速化し、確実に成功させるには、データベースを少数のファイルに統合します。

Note

移行中にデータベースに読み取り専用でアクセスできるようにする必要があり、移行の実行に非常に長い時間がかかり、かつダウンタイムを最小限に抑える必要がある場合は、推奨される移行ソリューションとして Managed Instance リンク機能を使用することを検討してください。

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

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

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

重要

これらの制限事項は、Business Critical サービスレベルに移行する場合にのみ適用され、General Purpose サービスレベルに移行する場合には適用されません。

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 に移行するワークロードのコストとサイズ設定のベストプラクティスについて学ぶ。

次の方法で共有

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

前提条件

SQL Server

Azure

Azure RBAC アクセス許可

ベストプラクティス

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

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

ストレージアカウントの作成

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

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

Blob Storage の LRS 用の SAS 認証トークンを生成する

SAS トークンからパラメーターをコピーする

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

Blob Storage アカウントにバックアップをアップロードする

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

SQL Server インスタンスでバックアップを作成する

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

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

移行を開始する

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

LRS を連続モードで開始する

移行ジョブのスクリプトを作成する

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

移行を停止する (省略可能)

移行を完了する (連続モード)

制限事項

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

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

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

次のステップ

フィードバック

その他のリソース

次の方法で共有

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

前提条件

SQL Server

Azure

Azure RBAC アクセス許可

ベスト プラクティス

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

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

ストレージ アカウントの作成

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

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

Blob Storage の LRS 用の SAS 認証トークンを生成する

SAS トークンからパラメーターをコピーする

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

Blob Storage アカウントにバックアップをアップロードする

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

SQL Server インスタンスでバックアップを作成する

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

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

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

移行を開始する

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

LRS を連続モードで開始する

移行ジョブのスクリプトを作成する

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

移行を停止する (省略可能)

移行を完了する (連続モード)

制限事項

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

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

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

次のステップ

フィードバック

その他のリソース

ベストプラクティス

ストレージアカウントの作成

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

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

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

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