SE の雑記

本投稿は 2018/4 時点の Public Preview の内容です。
一般提供開始時には変更されている可能性があります。
SQL Database Managed Instance (MI) の大きな特徴の一つとして「ネイティブバックアップのリストア」をする機能があります。
ネイティブバックアップとは、オンプレミスの SQL Server で取得されているバックアップのことを指します。
従来から提供されている PaaS 型の SQL Server ベースの RDBMS である「Azure SQL Database」「Azure SQL Data Warehouse」では、ネイティブバックアップのリストアはサポートされていませんでした。
そのため、SQL Server のデータベースを移行しようとした場合、

• スキーマ / データをエクスポートしたものをベースにして移行を検討
• BACPAC ファイルで移行

というような手法をとる必要がありました。
しかし、大規模なデータベースの場合、これらの方法は効率的ではありませんし、何回も移行をするという作業には適していませんでした。
この辺がネックになり、PaaS ではなく、IaaS の「SQL Server on Azure VM」を採用したというケースもあるのではないでしょうか。
このような現状に対して「SQL Database Managed Instance」は、オンプレミスの SQL Server のバックアップをリストア可能にしています。
これにより、PaaS で提供されているデータベースへの「リフト & シフト」を容易にしているというのが特徴としてあります。
リストア可能なデータベースは「ユーザーデータベース」のみとなっており、システムデータベースはリストアすることができません。
そのため、ログインや SQL Server Agent のジョブの情報についてはスクリプトでの移行を検討する必要があります。
それでは、ユーザーデータベースのリストアを、どのように実施するのか、流れを見ていきましょう。

細かな作業内容については、Restore a database backup to an Azure SQL Database Managed Instance に記載されています。
流れを書くと、

1. SQL Server でデータベースの完全バックアップを主おtく
2. 取得したバックアップを Azure BLOB ストレージにアップロード
3. MI にバックアップを配置した Azure BLOB ストレージの資格情報を登録
4. MI で Azure BLOB ストレージのバックアップをリストア

という手順になります。

SQL Server で取得するバックアップですがすべてのバックアップが使用できるというわけではありません。
リストア可能なバックアップの制限については、RESTORE ステートメント に記載されています。
代表的なものとしては、

• 一つのバックアップファイルに複数のバックアップが含まれているファイルをリストアすることはできない
• 複数のログファイルで構成されたデータベースをリストアすることはできない
• FILESTREAM が含まれたデータベースをリストアすることはできない
• In-Memory OLTP が含まれたデータベースをリストアすることはできない
• WITH 句が使用できない

というような制限があります。
バックアップについては、SQL Server 2005 / SQL Server 2017 のバックアップはリストアすることができましたので、SQL Server のバージョンとしては幅広く対応しているかと。
(SQL Server 2000 は試していませんが、たぶん無理かと)
MI はデータベースの構成に制限があるため、リストア後にその制限に適応した状態になっているデータベースをリストアする必要があります。
また、現状は「WITH 句」が使用できないため、「WITH NORECOVERY」で複数のバックアップを順次リストアするということができないようです。
そのため、差分バックアップや、トランザクションログバックアップを組み合わせて MI にリストアをするということができません。
 
SQL Server のバックアップを取得したら、AZCopy や、Azure Storege Explorer でバックアップをアップロードします。
SQL Server 2012 SP1 CU2 以降の場合、直接 BLOB ストレージにバックアップを取得 することも可能ですが、MI の移行対象で 2012 以降を使用するのはもう少し先でしょうかね。
(現状、SQL Server 2005 ～ 2008 R2 までが対象になりやすいかと思います)
今回は、Storage Explorer を使用してアップロードしています。

ファイルのアップロードが終わったら、MI 側の作業です。
最初に BLOB ストレージに接続を可能とするために資格情報を登録します。

CREATE CREDENTIAL [https://<ストレージアカウント名>.blob.core.windows.net/<コンテナー名>]
   WITH IDENTITY = 'SHARED ACCESS SIGNATURE'
   , SECRET = '<Shared Access Signature>'
GO

資格情報は、BLOB ストレージの SAS を登録する必要がありますので、Storage Explorer や、Azure Portal から作成を行います。
(作成された SAS の先頭の ? より後ろの部分を使用します)

これで、MI から BLOB ストレージに接続が可能となりましたので、最後にリストアを行います。
リストアはシンプルに、バックアップファイルを指定するだけです。

RESTORE DATABASE [<DB 名>]
FROM URL = 'https://<ストレージアカウント>.blob.core.windows.net/<コンテナー>/<バックアップファイル>'

 
これでリストアが開始されます。
通常の SQL Server ですと、リストアを実行したセッションから同期的にリストアの実行状況が返されますが、MI の場合、リストアの要求を投げた後は非同期でリストアされます。
これが、RESTORE ステートメント に記載されている次の内容に該当します。

ASYNC RESTORE – クライアント接続が切断されても、復元は続行されます。 接続が破棄された場合は、sys.dm_operation_status ビューで復元操作の状態 (およびデータベースの CREATE 操作と DROP 操作) を確認できます。 sys.dm_operation_status に関する記事をご覧ください。

RESTORE ステートメントを実行したセッションが切断されても、リストア自体は非同期でバックグラウンド実行が継続しますので、リストアの状況については次のクエリで確認することになります。

SELECT * FROM sys.dm_operation_status
 WHERE operation = 'CreateManagedRestoreRequest'

MI へのリストアに適していないバックアップファイルを使用した場合などはエラーで落ちますのでご注意を。
次のステートメントでバックアップファイルの内容を確認することができますので、リストアするバックアップの内容を確認するように意識しておいてもよいかもしれないですね。

RESTORE HEADERONLY
FROM URL = 'https://<ストレージアカウント>.blob.core.windows.net/<コンテナー>/<バックアップファイル>'
RESTORE FILELISTONLY
FROM URL = 'https://<ストレージアカウント>.blob.core.windows.net/<コンテナー>/<バックアップファイル>'

 
SQL Server 2005 で使用していたデータベースをリストアした際には、互換性レベルが「100」に強制的にアップグレードされますので、古い DB をリストアする場合はこの辺も意識しておいた方がよいかと。
リストアしたデータベースのログインのマッピングが崩れ、孤立したユーザーが存在していないかどうかについても、合わせて確認しておくとよいかと思います。
孤立ユーザーのトラブルシューティング (SQL Server)
データベースのデータファイルについては、元のデータベースのファイル数がそのまま移行されますので、1 データファイルで構成していた場合などは、複数のデータファイルの構成に変更し、一度インデックスの再構築を実施して、データファイル内の領域の使用量のリバランスをすることで、最適なパフォーマンスを出すような構成に変更するということを検討してもよいかもしれないですね。
MI のネイティブバックアップのリストアは、シンプルにデータベースを移行することが可能ですので、有効に活用していくのがポイントかと。
注意点のもう一つとしては、リストアしたデータベースのリネームでしょうか。
現状、MI では、データベースのリネームがサポートされていません。
SQL Database だと、システムで取得されているバックアップを違う名前でリストアし、内容に問題がなければ、最終的な名称にリネームするという運用をするかと思いますが、この方法は MI では、現状使用することができません。
そのため、MI でリストアを実施する際には、「最終的な DB 名でリストアをする」ということは注意点として覚えておくとよろしいかと。