Azure SQL Managed Instance の管理操作の概要
適用対象: 
Azure SQL Managed Instance
Azure SQL Managed Instance には、新しいマネージド インスタンスを自動的にデプロイしたり、インスタンスのプロパティを更新したり、不要になったインスタンスを削除したりする際に使用できる管理操作が用意されています。
管理操作とは
すべての管理操作は次のように分類できます。
- インスタンスのデプロイ (新しいインスタンスの作成)
- インスタンスの更新 (仮想コアや予約済み記憶域などの、インスタンスのプロパティの変更)
- インスタンスの削除
Azure 仮想ネットワーク内のデプロイをサポートし、顧客に分離とセキュリティを提供するため、SQL Managed Instance では仮想クラスターに依存しています。 仮想クラスターは、お客様の仮想ネットワーク サブネット内にデプロイされ、仮想マシン グループ内で構成されている分離された仮想マシンの専用セットを表します。 基本的に、空のサブネットにデプロイされたそれぞれのマネージド インスタンスは、最初の仮想マシン グループをビルドする新しい仮想クラスター構成となります。
それ以降のマネージド インスタンスに対して実行された管理操作は、基盤となる仮想マシン グループに影響を与える場合があります。 基盤となる仮想マシン グループに影響する変更が、管理操作の所要時間に影響を及ぼすことがあります。新たな仮想マシンの仮想クラスターへのデプロイにはオーバーヘッドが伴うためです。新たなデプロイや既存のマネージド インスタンスに対する更新を計画する際には、このオーバーヘッドを考慮する必要があります。
Fast provisioning (迅速なプロビジョニング)
2022 年 11 月の機能ウェーブが有効になっているサブネットは、SQL Managed Instance のプロビジョニングを利用できます。これにより、サブネット内に最初のインスタンスを作成するのにかかる時間を (平均 45～60 分から) 30 分にまで短縮できます。 操作の所要時間に関する詳細は、「管理操作」を確認してください。
高速プロビジョニングは、以下に対してのみ適用されます。
- サブネットでプロビジョニングされた最初のインスタンス。
- 4～8 個の仮想コアを持つインスタンス。
- 既定のメンテナンス期間を使用するインスタンス。
- ゾーン冗長ではないインスタンスに対して。
Duration
仮想クラスターに対する操作は、所要時間がさまざまですが、通常かなり時間がかかります。
次の表に、作成、更新、または削除操作の一部としてトリガーできる実行時間の長いステップを示します。 表には、既存サービスの利用統計情報に基づいて、通常予想できる所要時間も示されています。
| 手順 | 説明 | 推定所要時間 |
|---|---|---|
| 仮想クラスターの作成 (高速プロビジョニング)1 | 高速プロビジョニングは、インスタンス管理操作の同期手順であり、その間、最初の仮想マシン グループをすぐに使用できるようになります。 | 操作の 90% は 30 分で完了 |
| 仮想クラスターの作成 | 作成は、インスタンス管理操作の同期ステップであり、その間に最初の仮想マシン グループが作成されます。 | 操作の 90% は 4 時間未満で完了 |
| 仮想クラスターのサイズ変更 (拡張または縮小) | 既存の仮想マシン グループへの新しいマシンの追加、未使用の仮想マシンの削除、仮想マシン グループ全体の追加または削除。 拡張は同期的に実行されるステップです。一方、縮小は非同期的に実行されます (インスタンス管理操作の所要時間には影響しません)。 | 新しい仮想マシン グループの作成によるクラスター拡張の 90% は 4 時間未満で完了 既存の仮想マシン グループの拡張によるクラスター拡張の 90% が 60 分で完了 |
| 仮想クラスターの削除 | 仮想クラスターの削除は、最後のインスタンスがサブネットから削除されたときにトリガーされます。 | クラスターの削除の 90% は 1.5 時間で完了 |
| データベース ファイルのシード処理2 | Business Critical サービス レベルにおけるコンピューティング (仮想コア) やストレージのスケーリング中、および General Purpose から Business Critical (またはその逆) へのサービス レベルの変更時にトリガーされる同期的ステップ。 この操作の所要時間は、合計データベース サイズおよび現在のデータベース アクティビティ (アクティブなトランザクションの数) に比例します。 インスタンスを更新しているときのデータベース アクティビティによって、総所要時間は大きく変動する場合があります。 | これらの操作の 90% は毎時 220 GB 以上で実行される |
1 高速プロビジョニングは現在、サブネット内の最初のインスタンス (4 個または 8 個の仮想コアあり) で、既定のメンテナンス期間構成でのみサポートされています。
2 Business Critical サービス レベルでコンピューティング (仮想コア) またはストレージをスケーリングする場合、またはサービス レベルを General Purpose から Business Critical に切り替える場合、シード処理には Always On 可用性グループのシード処理も含まれます。
重要
General Purpose サービス レベルでのストレージのスケール アップまたはダウンは、メタデータの更新と、送信された要求に対する応答の伝達で構成されます。 ダウンタイムやフェールオーバーはなく、最大 5 分で完了する高速操作です。
管理操作での実行時間の長いセグメント
次の表は、操作と標準的な総所要時間を、操作のカテゴリごとにまとめたものです。
カテゴリ: デプロイ
| 操作 | 実行時間の長いセグメント | 推定所要時間 |
|---|---|---|
| 空のサブネットへの最初のインスタンス1 | 仮想クラスターの作成 (高速プロビジョニング) | 操作の 90% は 30 分で完了。 |
| 空のサブネットへの最初のインスタンス | 仮想クラスターの作成 | 操作の 90% は 4 時間未満で完了します。 |
| 空ではないサブネット内の別のハードウェア生成またはメンテナンス期間の最初のインスタンス (たとえば、Standard シリーズ インスタンスを含むサブネット内の Premium シリーズ インスタンス) | 仮想クラスターへの新しい仮想マシン グループの追加 2 | 操作の 90% は 4 時間未満で完了します。 |
| 空ではないサブネットに後続のインスタンス (第 2、第 3 のインスタンスなど) を作成 | 仮想クラスターのサイズ変更 | 操作の 90% は 60 分で完了。 |
1 高速プロビジョニングは現在、サブネット内の最初のインスタンス (4 個または 8 個の仮想コアあり) で、既定のメンテナンス期間構成でのみサポートされています。 2 ハードウェアの生成とメンテナンス期間の構成ごとに、個別の仮想マシン グループが作成されます。
カテゴリ: 更新
| 操作 | 実行時間の長いセグメント | 推定所要時間 |
|---|---|---|
| インスタンス プロパティの変更 (管理者パスワード、Microsoft Entra ログイン、Azure ハイブリッド特典フラグ) |
該当なし | 最大 1 分。 |
| インスタンス ストレージのスケールアップ/スケールダウン (General Purpose) |
実行時間の長いセグメントはありません | 操作の 99% は 5 分以内に完了。 |
| インスタンス ストレージのスケールアップ/スケールダウン (Business Critical) |
- 仮想クラスターのサイズ変更 - Always On 可用性グループのシード処理 |
操作の 90% は 60 分で完了。それに加えて、すべてのデータベースにシード処理する時間 (毎時 220 GB) |
| インスタンス ストレージのスケールアップ/スケールダウン (Next-gen General Purpose) |
- 仮想クラスターの作成/仮想マシン グループのサイズ変更 - Always On 可用性グループのシード処理 |
操作の 90% は、4 時間未満 (仮想マシン グループの作成) または 60 分 (仮想マシン グループのサイズ変更) と、すべてのデータベースのシード処理 (220 GB/時間)、フェールオーバー、古いインスタンスのクリーンアップにかかる時間で終了します |
| インスタンスのコンピューティング (仮想コア) のスケールアップとスケールダウン (General Purpose) |
- 仮想クラスターのサイズ変更 | 操作の 90% は 60 分で完了。 |
| インスタンスのコンピューティング (仮想コア) のスケールアップとスケールダウン (Business Critical) |
- 仮想クラスターのサイズ変更 - Always On 可用性グループのシード処理 |
操作の 90% は 60 分で完了。それに加えて、すべてのデータベースにシード処理する時間 (毎時 220 GB) |
| インスタンスのコンピューティング (仮想コア) のスケールアップとスケールダウン (Next-gen General Purpose) |
仮想クラスターの作成/仮想マシン グループのサイズ変更 - Always On 可用性グループのシード処理 |
操作の 90% は、4 時間未満 (仮想マシン グループの作成) または 60 分 (仮想マシン グループのサイズ変更) と、すべてのデータベースのシード処理 (220 GB/時間)、フェールオーバー、古いインスタンスのクリーンアップにかかる時間で終了します |
| インスタンス サービス レベルの変更 (General Purpose から Business Critical とその逆) |
- 仮想クラスターのサイズ変更 - Always On 可用性グループのシード処理 |
操作の 90% は 60 分で完了。それに加えて、すべてのデータベースにシード処理する時間 (毎時 220 GB) |
| インスタンス サービス レベルの変更 (General Purpose または Business Critical から Next-gen General Purpose とその逆) |
仮想クラスターの作成/仮想マシン グループのサイズ変更 - Always On 可用性グループのシード処理 |
操作の 90% は、4 時間未満 (仮想マシン グループの作成) または 60 分 (仮想マシン グループのサイズ変更) と、すべてのデータベースのシード処理 (220 GB/時間)、フェールオーバー、古いインスタンスのクリーンアップにかかる時間で終了します |
| インスタンス ハードウェアまたはメンテナンス期間の変更 (General Purpose) |
- 仮想クラスターのサイズ変更1 | 操作の 90% は、4 時間未満 (仮想マシン グループの作成) または 60 分 (仮想マシン グループのサイズ変更) で完了します。 |
| インスタンス ハードウェアまたはメンテナンス期間の変更 (Business Critical) |
- 仮想クラスターのサイズ変更1 - Always On 可用性グループのシード処理 |
操作の 90% は、4 時間未満 (仮想マシン グループの作成) または 60 分 (仮想マシン グループのサイズ変更) および、すべてのデータベースのシード処理 (220 GB/時間) にかかる時間で完了します。 |
| インスタンス ハードウェアまたはメンテナンス期間の変更 (Next-gen General Purpose) |
- 仮想クラスターの作成/仮想マシン グループのサイズ変更 - Always On 可用性グループのシード処理 |
操作の 90% は、4 時間未満 (仮想マシン グループの作成) または 60 分 (仮想マシン グループのサイズ変更) と、すべてのデータベースのシード処理 (220 GB/時間)、フェールオーバー、古いインスタンスのクリーンアップにかかる時間で終了します |
1 マネージド インスタンスは、同一の対応するハードウェアとメンテナンス期間を持つ仮想マシン グループに配置する必要があります。 そのようなグループが仮想クラスターに存在しない場合は、そのインスタンス構成を格納するために、最初に新しいものを作成する必要があります。
カテゴリ: 削除
| 操作 | 実行時間の長いセグメント | 推定所要時間 |
|---|---|---|
| 最後以外のインスタンスの削除 | すべてのデータベースに対するログ テールのバックアップ | 操作の 90% は最長 1 分で完了。1 |
| 最後のインスタンスの削除 | - すべてのデータベースのログテールバックアップ - 仮想クラスターの削除 |
操作の 90% は最長 1.5 時間で完了。2 |
1 クラスターに複数の仮想マシン グループがある場合、グループ内の最後のインスタンスを削除すると、すぐに仮想マシン グループ の非同期的な削除がトリガーされます。
2 サブネット内の最後のインスタンスが削除されると、仮想クラスターの削除が直ちに、同期的にトリガーされます。
重要
削除操作がトリガーされるとすぐに、SQL Managed Instance に対する課金が無効になります。 削除操作の所要時間は、課金に影響を与えません。
インスタンスの可用性
SQL Managed Instance は、更新操作中の利用が可能です。ただし、更新の最後に実行されるフェールオーバーによって短いダウンタイムが発生します。 高速データベース復旧のおかげで、実行時間の長いトランザクションが中断された場合でも、通常は最大で 10 秒です。
Note
General Purpose マネージド インスタンス ストレージのスケーリングが、更新の最後にフェールオーバーを引き起こすことはありません。
デプロイおよび削除の操作中は、SQL Managed Instance はクライアント アプリケーションに対して利用不可能になります。
重要
実行時間の長いトランザクション (データのインポート、データ処理ジョブ、インデックスの再構築など) と同時に、Azure SQL Managed Instance のコンピューティングやストレージをスケーリングしたり、サービス レベルを変更したりすることは推奨されません。 操作の最後に実行されるデータベースのフェールオーバーで、実行中のトランザクションはすべてキャンセルされます。
管理操作のステップ
管理操作は、複数のステップから成ります。 Operations API の導入に伴い、これらのステップは公開され、操作のサブセット (デプロイと更新) に使用されます。 デプロイ操作は 3 つのステップから成ります。一方、更新操作は 6 つのステップで実行されます。 操作の所要時間の詳細については、管理操作の所要時間に関するセクションを参照してください。 ステップは、実行順に記載しています。
マネージド インスタンスのデプロイ ステップ
| [ステップ名] | ステップの説明 |
|---|---|
| 要求の検証 | 送信したパラメーターが検証されます。 構成に誤りがある場合、エラーが発生して操作は失敗します。 |
| 仮想クラスターのサイズ変更と作成 | 仮想クラスターの状態に応じて、クラスターは作成中またはリサイズ中の状態になります。 |
| 新しい SQL インスタンスの起動 | デプロイされた仮想マシンで SQL プロセスが起動されます。 |
マネージド インスタンスの更新ステップ
| [ステップ名] | ステップの説明 |
|---|---|
| 要求の検証 | 送信したパラメーターが検証されます。 構成に誤りがある場合、エラーが発生して操作は失敗します。 |
| 仮想クラスターのサイズ変更と作成 | 仮想クラスターの状態に応じて、クラスターは作成中またはリサイズ中の状態になります。 |
| 新しい SQL インスタンスの起動 | デプロイされた仮想マシンで SQL プロセスが起動されます。 |
| データベース ファイルのシード処理とデータベース ファイルのアタッチ | 更新処理の種類に応じて、データベースのシード処理またはデータベース ファイルのアタッチが実行されます。 |
| フェールオーバーの準備とフェールオーバー | データのシード処理またはデータベース ファイルの再アタッチが完了すると、システムはフェールオーバーに備えて準備されます。 すべての準備が整うと、短いダウンタイムでフェールオーバーが実行されます。 |
| 古い SQL インスタンスのクリーンアップ | 古い SQL プロセスを仮想マシンから削除する |
マネージド インスタンスの削除ステップ
| [ステップ名] | ステップの説明 |
|---|---|
| 要求の検証 | 送信したパラメーターが検証されます。 構成に誤りがある場合、エラーが発生して操作は失敗します。 |
| SQL インスタンスのクリーンアップ | 仮想マシンから SQL プロセスを削除する |
| 仮想クラスターの削除 | 削除されるインスタンスがサブネット内で最後かどうかによって、仮想クラスターは最後のステップとして同期的に削除されます。 |
Note
インスタンスをスケーリングすると、未使用キャパシティの解放と、場合によってはキャパシティの最適化プロセスが、基盤となる仮想クラスターに適用され、作成操作にもスケーリング操作にも参加しなかったインスタンスに影響が生じることがあります。
管理操作の相互影響
マネージド インスタンスでの管理操作は、同じサブネット内に配置された他のインスタンスの管理操作に影響を及ぼす場合があります。
仮想クラスター内の実行時間の長い復元操作により、同じ仮想マシン グループ内の、作成やスケーリングなどの他の操作が保留されます。
例: 実行時間の長い復元操作があり、さらに仮想マシン グループを縮小する必要のあるスケール要求がある場合、縮小要求の完了までにかかる時間は、それを続行する前に復元操作の完了を待つ必要があるため、長くなります。後続のインスタンスの作成またはスケーリングの操作は、以前に開始されたインスタンスの作成、または仮想マシン グループのサイズ変更を開始したインスタンスのスケールによって保留されます。
例: 同じ仮想マシン グループの同じサブネット内に複数の作成またはスケーリングの要求がある場合に、そのうちの 1 つで仮想マシン グループのサイズ変更が開始されると、初期操作要求から 5 分以上経過した後で送信された要求はすべて、予想よりも長く時間がかかります。これらの要求は必ず、サイズ変更の完了を待って再開されるためです。5 分以内に送信された作成/スケーリング操作は、バッチ処理されて並列で実行されます。
例: 5 分以内 (最初の操作要求を実行した時点から測定されます) に送信されたすべての操作に対して、仮想クラスターのサイズ変更は 1 回だけ実行されます。 最初の要求が送信されてから 5 分以上経過した後に別の要求が送信された場合、仮想クラスターのサイズ変更が完了するのを待って、実行が開始されます。
重要
進行中の別の操作が原因で保留になっている管理操作は、続行の条件が満たされると、自動的に再開されます。 一時停止された管理操作を再開するために必要なユーザー操作はありません。
管理操作の監視
管理操作の進行状況と状態を監視するには、管理操作の監視に関するページを参照してください。
管理操作のキャンセル
管理操作を取り消す方法については、管理操作のキャンセルに関するページを参照してください。
次のステップ
- 最初のマネージド インスタンスを作成する方法については、クイック スタート ガイドを参照してください。
- 機能と比較の一覧については、共通の SQL 機能に関するページを参照してください。
- VNet の構成の詳細については、SQL Managed Instance VNet の構成に関するページを参照してください。
- 仮想マシン グループと仮想クラスターの詳細については、「SQL Managed Instance 仮想クラスターのアーキテクチャ」を参照してください 。
- マネージド インスタンスを作成し、バックアップ ファイルからデータベースを復元するためのクイック スタートについては、マネージド インスタンスの作成に関するページを参照してください。
- Azure Database Migration Service を使用して移行する方法のチュートリアルについては、Database Migration Service を使用した SQL Managed Instance の移行に関するページを参照してください。