Azure SQL Managed Instance の管理操作の概要Overview of Azure SQL Managed Instance management operations

適用対象: Azure SQL Managed Instance

Azure SQL Managed Instance には、新しいマネージド インスタンスを自動的にデプロイしたり、インスタンスのプロパティを更新したり、不要になったインスタンスを削除したりする際に使用できる管理操作が用意されています。Azure SQL Managed Instance provides management operations that you can use to automatically deploy new managed instances, update instance properties, and delete instances when no longer needed.

管理操作とはWhat are management operations?

すべての管理操作は次のように分類できます。All management operations can be categorized as follows:

  • インスタンスのデプロイ (新しいインスタンスの作成)Instance deployment (new instance creation)
  • インスタンスの更新 (仮想コアや予約済み記憶域などの、インスタンスのプロパティの変更)Instance update (changing instance properties, such as vCores or reserved storage)
  • インスタンスの削除Instance deletion

Azure 仮想ネットワーク内のデプロイをサポートし、顧客に分離とセキュリティを提供するため、SQL Managed Instance では仮想クラスターに依存しています。To support deployments within Azure virtual networks and provide isolation and security for customers, SQL Managed Instance relies on virtual clusters. 仮想クラスターは、お客様の仮想ネットワーク サブネット内にデプロイされている分離された仮想マシンの専用セットを表します。The virtual cluster represents a dedicated set of isolated virtual machines deployed inside the customer's virtual network subnet. 基本的に、空のサブネットにマネージド インスタンスをデプロイするとその都度、新しい仮想クラスターが構築されます。Essentially, every managed instance deployed to an empty subnet results in a new virtual cluster buildout.

それ以降、マネージド インスタンスに対して実行された管理操作は、基盤となる仮想クラスターに影響する可能性があります。Subsequent management operations on managed instances may impact the underlying virtual cluster. 基盤となる仮想クラスターに影響する変更が、管理操作の所要時間に影響を及ぼすことがあります。新たな仮想マシンのデプロイにはオーバーヘッドが伴うためです。新たなデプロイや既存のマネージド インスタンスに対する更新を計画する際には、このオーバーヘッドを考慮する必要があります。Changes that impact the underlying virtual cluster may affect the duration of management operations, as deploying additional virtual machines comes with an overhead that you need to consider when you plan new deployments or updates to existing managed instances.

DurationDuration

仮想クラスターに対する操作は、所要時間がさまざまですが、通常かなり時間がかかります。The duration of operations on the virtual cluster can vary, but typically have the longest duration.

既存のサービス利用統計情報に基づいて一般的に見込まれる値を以下に示します。The following are values that you can typically expect, based on existing service telemetry data:

  • 仮想クラスターの作成:作成はインスタンス管理操作で同期的に実行されるステップです。Virtual cluster creation: Creation is a synchronous step in instance management operations.
    操作の 90% は 4 時間以内に完了します90% of operations finish in 4 hours.
  • 仮想クラスターのサイズ変更 (拡張または縮小) :拡張は同期的に実行されるステップです。一方、縮小は非同期的に実行されます (インスタンス管理操作の所要時間には影響しません)。Virtual cluster resizing (expansion or shrinking): Expansion is a synchronous step, while shrinking is performed asynchronously (without impact on the duration of instance management operations).
    クラスター拡張の 90% は 2.5 時間未満で終了します90% of cluster expansions finish in less than 2.5 hours.
  • 仮想クラスターの削除:削除は非同期で実行されるステップですが、空の仮想クラスターに対して手動で開始することもでき、その場合は同期的に実行されます。Virtual cluster deletion: Deletion is an asynchronous step, but it can also be initiated manually on an empty virtual cluster, in which case it executes synchronously.
    仮想クラスターの削除の 90% は 1.5 時間以内に完了します90% of virtual cluster deletions finish in 1.5 hours.

加えて、インスタンスの管理には、ホストされたデータベースに対するいずれかの操作が伴うこともあり、その場合、所要時間はさらに長くなります。Additionally, management of instances may also include one of the operations on hosted databases, which result in longer durations:

  • Azure Storage からのデータベース ファイルのアタッチ:General Purpose サービス レベルにおけるコンピューティング (仮想コア) やストレージのスケールアップやスケールダウンなどのような同期的に実行されるステップです。Attaching database files from Azure Storage: A synchronous step, such as scaling compute (vCores), or storage up or down in the General Purpose service tier.
    これらの操作の 90% は 5 分以内に完了します90% of these operations finish in 5 minutes.
  • Always On 可用性グループのシード処理:Business Critical サービス レベルにおけるコンピューティング (仮想コア) やストレージのスケーリング、General Purpose から Business Critical (またはその逆) へのサービス レベルの変更などのような同期的に実行されるステップです。Always On availability group seeding: A synchronous step, such as compute (vCores), or storage scaling in the Business Critical service tier as well as in changing the service tier from General Purpose to Business Critical (or vice versa). この操作の所要時間は、合計データベース サイズおよび現在のデータベース アクティビティ (アクティブなトランザクションの数) に比例します。Duration of this operation is proportional to the total database size as well as current database activity (number of active transactions). インスタンスを更新しているときのデータベース アクティビティによって、総所要時間は大きく変動する場合があります。Database activity when updating an instance can introduce significant variance to the total duration.
    これらの操作の 90% は毎時 220 GB 以上で実行されます90% of these operations execute at 220 GB/hour or higher.

次の表は、操作と標準的な総所要時間を、操作のカテゴリごとにまとめたものです。The following tables summarize operations and typical overall durations, based on the category of the operation:

カテゴリ: デプロイCategory: Deployment

操作Operation 実行時間の長いセグメントLong-running segment 推定所要時間Estimated duration
空のサブネットへの最初のインスタンスFirst instance in an empty subnet 仮想クラスターの作成Virtual cluster creation 操作の 90% は 4 時間以内に完了。90% of operations finish in 4 hours.
空ではないサブネットへの別のハードウェア世代の最初のインスタンス (Gen 4 インスタンスを含んだサブネットへの初の Gen 5 インスタンスなど)First instance of another hardware generation in a non-empty subnet (for example, first Gen 5 instance in a subnet with Gen 4 instances) 仮想クラスターの作成1Virtual cluster creation1 操作の 90% は 4 時間以内に完了。90% of operations finish in 4 hours.
空ではないサブネットに後続のインスタンス (第 2、第 3 のインスタンスなど) を作成Subsequent instance creation within the non-empty subnet (2nd, 3rd, etc. instance) 仮想クラスターのサイズ変更Virtual cluster resizing 操作の 90% は 2.5 時間以内に完了。90% of operations finish in 2.5 hours.

1 仮想クラスターは、ハードウェアの世代ごとに構築されます。1 Virtual cluster is built per hardware generation.

カテゴリ: 更新Category: Update

操作Operation 実行時間の長いセグメントLong-running segment 推定所要時間Estimated duration
インスタンスのプロパティ変更 (管理者パスワード、Azure AD ログイン、Azure ハイブリッド特典フラグ)Instance property change (admin password, Azure AD login, Azure Hybrid Benefit flag) 該当なしN/A 最大 1 分。Up to 1 minute.
インスタンスのストレージのスケールアップとスケールダウン (General Purpose サービス レベル)Instance storage scaling up/down (General Purpose service tier) データベース ファイルのアタッチAttaching database files 操作の 90% は 5 分以内に完了。90% of operations finish in 5 minutes.
インスタンスのストレージのスケールアップとスケールダウン (Business Critical サービス レベル)Instance storage scaling up/down (Business Critical service tier) - 仮想クラスターのサイズ変更- Virtual cluster resizing
- Always On 可用性グループのシード処理- Always On availability group seeding
操作の 90% は 2.5 時間以内に完了。それに加えて、すべてのデータベースにシード処理する時間 (毎時 220 GB)。90% of operations finish in 2.5 hours + time to seed all databases (220 GB/hour).
インスタンスのコンピューティング (仮想コア) のスケールアップとスケールダウン (General Purpose)Instance compute (vCores) scaling up and down (General Purpose) - 仮想クラスターのサイズ変更- Virtual cluster resizing
- データベース ファイルのアタッチ- Attaching database files
操作の 90% は 2.5 時間以内に完了。90% of operations finish in 2.5 hours.
インスタンスのコンピューティング (仮想コア) のスケールアップとスケールダウン (Business Critical)Instance compute (vCores) scaling up and down (Business Critical) - 仮想クラスターのサイズ変更- Virtual cluster resizing
- Always On 可用性グループのシード処理- Always On availability group seeding
操作の 90% は 2.5 時間以内に完了。それに加えて、すべてのデータベースにシード処理する時間 (毎時 220 GB)。90% of operations finish in 2.5 hours + time to seed all databases (220 GB/hour).
インスタンスのサービス レベルの変更 (General Purpose から Business Critical、またはその逆へ)Instance service tier change (General Purpose to Business Critical and vice versa) - 仮想クラスターのサイズ変更- Virtual cluster resizing
- Always On 可用性グループのシード処理- Always On availability group seeding
操作の 90% は 2.5 時間以内に完了。それに加えて、すべてのデータベースにシード処理する時間 (毎時 220 GB)。90% of operations finish in 2.5 hours + time to seed all databases (220 GB/hour).

カテゴリ: 削除Category: Delete

操作Operation 実行時間の長いセグメントLong-running segment 推定所要時間Estimated duration
インスタンスの削除Instance deletion すべてのデータベースに対するログ テールのバックアップLog tail backup for all databases 操作の 90% は最長でも 1 分以内に完了。90% operations finish in up to 1 minute.
メモ: サブネットの最後のインスタンスが削除された場合、この操作により 12 時間後に仮想クラスターが削除されるようにスケジュールされます。1Note: if the last instance in the subnet is deleted, this operation will schedule virtual cluster deletion after 12 hours.1
(ユーザーによって開始された操作としての) 仮想クラスターの削除Virtual cluster deletion (as user-initiated operation) 仮想クラスターの削除Virtual cluster deletion 操作の 90% は最長でも 1.5 時間以内に完了。90% of operations finish in up to 1.5 hours.

1 12 時間は現在の構成です。将来は変更される可能性があります。112 hours is the current configuration but this is subject to change in the future. もっと早く仮想クラスターを削除する必要がある場合は (サブネットを解放するためなど)、マネージド インスタンスの削除後のサブネットの削除に関するページを参照してください。If you need to delete a virtual cluster earlier (to release the subnet, for example), see Delete a subnet after deleting a managed instance.

インスタンスの可用性Instance availability

SQL Managed Instance は、更新操作中の利用が可能です。ただし、更新の最後に実行されるフェールオーバーによって短いダウンタイムが発生します。SQL Managed Instance is available during update operations, except a short downtime caused by the failover that happens at the end of the update. 高速データベース復旧のおかげで、実行時間の長いトランザクションが中断された場合でも、通常は最大で 10 秒です。It typically lasts up to 10 seconds even in case of interrupted long-running transactions, thanks to accelerated database recovery.

デプロイおよび削除の操作中は、SQL Managed Instance はクライアント アプリケーションに対して利用不可能になります。SQL Managed Instance is not available to client applications during deployment and deletion operations.

重要

実行時間の長いトランザクション (データのインポート、データ処理ジョブ、インデックスの再構築など) と同時に、Azure SQL Managed Instance のコンピューティングやストレージをスケーリングしたり、サービス レベルを変更したりすることは推奨されません。It's not recommended to scale compute or storage of Azure SQL Managed Instance or to change the service tier at the same time as long-running transactions (data import, data processing jobs, index rebuild, etc.). 操作の最後に実行されるデータベースのフェールオーバーで、実行中のトランザクションはすべてキャンセルされます。The failover of the database at the end of the operation cancels all ongoing transactions.

管理操作のステップManagement operations steps

管理操作は、複数のステップから成ります。Management operations consist of multiple steps. Operations API の導入に伴い、これらのステップは公開され、操作のサブセット (デプロイと更新) に使用されます。With Operations API introduced these steps are exposed for subset of operations (deployment and update). デプロイ操作は 3 つのステップから成ります。一方、更新操作は 6 つのステップで実行されます。Deployment operation consists of three steps while update operation is performed in six steps. 操作の所要時間の詳細については、管理操作の所要時間に関するセクションを参照してください。For details on operations duration, see the management operations duration section. ステップは、実行順に記載しています。Steps are listed by order of execution.

マネージド インスタンスのデプロイ ステップManaged instance deployment steps

[ステップ名]Step name ステップの説明Step description
要求の検証Request validation 送信したパラメーターが検証されます。Submitted parameters are validated. 構成に誤りがある場合、エラーが発生して操作は失敗します。In case of misconfiguration operation will fail with an error.
仮想クラスターのサイズ変更と作成Virtual cluster resizing / creation サブネットの状態に応じて、仮想クラスターは作成またはサイズ変更の状態となります。Depending on the state of subnet, virtual cluster goes into creation or resizing.
新しい SQL インスタンスの起動New SQL instance startup デプロイされた仮想クラスターで SQL プロセスが起動されます。SQL process is started on deployed virtual cluster.

マネージド インスタンスの更新ステップManaged instance update steps

[ステップ名]Step name ステップの説明Step description
要求の検証Request validation 送信したパラメーターが検証されます。Submitted parameters are validated. 構成に誤りがある場合、エラーが発生して操作は失敗します。In case of misconfiguration operation will fail with an error.
仮想クラスターのサイズ変更と作成Virtual cluster resizing / creation サブネットの状態に応じて、仮想クラスターは作成またはサイズ変更の状態となります。Depending on the state of subnet, virtual cluster goes into creation or resizing.
新しい SQL インスタンスの起動New SQL instance startup デプロイされた仮想クラスターで SQL プロセスが起動されます。SQL process is started on deployed virtual cluster.
データベース ファイルのシード処理とデータベース ファイルのアタッチSeeding database files / attaching database files 更新処理の種類に応じて、データベースのシード処理またはデータベース ファイルのアタッチが実行されます。Depending on the type of the update operation, either database seeding or attaching database files is performed.
フェールオーバーの準備とフェールオーバーPreparing failover and failover データのシード処理またはデータベース ファイルの再アタッチが完了すると、システムはフェールオーバーに備えて準備されます。After data has been seeded or database files reattached, system is being prepared for the failover. すべての準備が整うと、短いダウンタイムでフェールオーバーが実行されます。When everything is set, failover is performed with a short downtime.
古い SQL インスタンスのクリーンアップOld SQL instance cleanup 古い SQL プロセスが仮想クラスターから削除されます。Removing old SQL process from the virtual cluster

注意

インスタンスをスケーリングすると、未使用キャパシティの解放と、場合によってはキャパシティの最適化プロセスが、基盤となる仮想クラスターに適用され、作成操作にもスケーリング操作にも参加しなかったインスタンスに影響が生じることがあります。As a result of scaling instances, underlying virtual cluster will go through process of releasing unused capacity and possible capacity defragmentation, which could impact instances that did not participate in creation / scaling operations.

管理操作の相互影響Management operations cross-impact

マネージド インスタンスでの管理操作は、同じ仮想クラスター内に配置されたインスタンスの他の管理操作に影響を及ぼす場合があります。Management operations on a managed instance can affect other management operations of the instances placed inside the same virtual cluster:

  • 仮想クラスター内の実行時間の長い復元操作により、同じサブネット内での他のインスタンスの作成やスケーリング操作が保留されます。Long-running restore operations in a virtual cluster will put other instance creation or scaling operations in the same subnet on hold.
    例: 実行時間の長い復元操作があり、同じサブネットに作成またはスケーリングの要求がある場合、この要求は復元操作の終了を待って続行されるため、完了までに通常より長い時間がかかります。Example: If there is a long-running restore operation and there is a create or scale request in the same subnet, this request will take longer to complete as it waits for the restore operation to complete before it continues.

  • 後続のインスタンスの作成またはスケーリングの操作は、以前に開始されたインスタンスの作成、または仮想クラスターのサイズ変更を開始したインスタンスのスケールによって保留されます。A subsequent instance creation or scaling operation is put on hold by a previously initiated instance creation or instance scale that initiated a resize of the virtual cluster.
    例: 同じ仮想クラスターの同じサブネット内に複数の作成またはスケーリングの要求がある場合に、そのうちの 1 つで仮想クラスターのサイズ変更が開始されると、初期操作要求から 5 分以上経過した後で送信された要求はすべて、予想よりも長く時間がかかります。これらの要求は必ず、サイズ変更の完了を待って再開されるためです。Example: If there are multiple create and/or scale requests in the same subnet under the same virtual cluster, and one of them initiates a virtual cluster resize, all requests that were submitted 5+ minutes after the initial operation request will last longer than expected, as these requests will have to wait for the resize to complete before resuming.

  • 5 分以内に送信された作成/スケーリング操作は、バッチ処理されて並列で実行されます。Create/scale operations submitted in a 5-minute window will be batched and executed in parallel.
    例: 5 分以内 (最初の操作要求を実行した時点から測定されます) に送信されたすべての操作に対して、仮想クラスターのサイズ変更は 1 回だけ実行されます。Example: Only one virtual cluster resize will be performed for all operations submitted in a 5-minute window (measuring from the moment of executing the first operation request). 最初の要求が送信されてから 5 分以上経過した後に別の要求が送信された場合、仮想クラスターのサイズ変更が完了するのを待って、実行が開始されます。If another request is submitted more than 5 minutes after the first one is submitted, it will wait for the virtual cluster resize to complete before execution starts.

重要

進行中の別の操作が原因で保留になっている管理操作は、続行の条件が満たされると、自動的に再開されます。Management operations that are put on hold because of another operation that is in progress will automatically be resumed once conditions to proceed are met. 一時停止された管理操作を再開するために必要なユーザー操作はありません。No user action is necessary to resume the temporarily paused management operations.

管理操作の監視Monitoring management operations

管理操作の進行状況と状態を監視するには、管理操作の監視に関するページを参照してください。To learn how to monitor management operation progress and status, see Monitoring management operations.

管理操作のキャンセルCanceling management operations

管理操作を取り消す方法については、管理操作のキャンセルに関するページを参照してください。To learn how to cancel management operation, see Canceling management operations.

次のステップNext steps