適用対象:
Azure SQL Managed Instance
この記事では、Azure SQL Managed Instanceの技術的特徴とリソース制限の概要を提供します。 また、これらの限度額への引き上げを申請する方法についても情報を提供しています。
注
サポート機能とT-SQL文の違いについては、「 機能の違い 」および 「T-SQL文のサポート」を参照してください。 Azure SQL DatabaseとSQL Managed Instanceのサービス層の違いについては、General PurposeおよびBusiness Critical service tiersを参照してください。
ハードウェア構成の特性
このセクションの内容は次のとおりです。
SQL Managed Instance には、基になるインフラストラクチャとアーキテクチャによって異なる特性とリソース制限があります。 SQL Managed Instanceは複数のハードウェア世代に展開できます。
ハードウェアの世代には、次の表に示したさまざまな特性があります。
| 特徴 | Standard シリーズ (Gen5) | Premium シリーズ | メモリ最適化 Premium シリーズ |
|---|---|---|---|
| CPU | Intel® E5-2673 v4 (Broadwell) 2.3 GHz プロセッサ、Intel® SP-8160 (Skylake) プロセッサ、および Intel® 8272CL (Cascade Lake) 2.5 GHz プロセッサ | Intel® 8370C (Ice Lake) 2.8 GHz プロセッサ | Intel® 8370C (Ice Lake) 2.8 GHz プロセッサ |
|
仮想コアの数 仮想コア = 1 LP (ハイパースレッド) |
21 -80 仮想コア | 21 -128 仮想コア | 4 - 128 仮想コア |
| 最大メモリ (メモリ/仮想コア比) | 仮想コアあたり 5.1 GB - 最大 408 GB メモリ量を増やすには、仮想コアを追加します。 |
仮想コアあたり 7 GB (最大 80 個の仮想コア) - 最大 560 GB | 仮想コアあたり 13.6 GB (最大 64 個の仮想コア) - 最大 870.4 GB |
| 最大インメモリ OLTP メモリ | インスタンスの制限:仮想コアあたり 0.8 から 1.65 GB | インスタンスの制限: 仮想コアあたり 1.1 から 2.3 GB | インスタンスの制限: 仮想コアあたり 2.2 から 4.5 GB |
| インスタンスの予約済み最大ストレージ2 |
汎用: 最大 32 TB4 Business Critical: 最大 4 TB |
汎用: 最大 32 TB4 Business Critical: 最大 16 TB3 |
汎用: 最大 32 TB4 Business Critical: 最大 16 TB |
1インスタンスプール内に2vコアのインスタンスしかデプロイできません。
2仮想コアの数によって異なります。
3次のリージョン では 16 TB のストレージを提供できますが、他のリージョンでは使用可能なストレージが 5.5 TB に制限されています。
従来の汎用では 4 16 TB。
次世代汎用サービス層のみ32TB
注
ワークロードで必要なストレージ サイズが Azure SQL Managed Instance で使用できるリソース制限を超える場合は、Azure SQL Database の Hyperscale サービス レベルを検討してください。
メモリ最適化されたプレミアムシリーズハードウェアおよび16TBストレージを持つプレミアムシリーズハードウェアへの地域サポート
16 TB ストレージのプレミアム シリーズ ハードウェアのサポートには、メモリ最適化のプレミアム シリーズ ハードウェアのサポートと同じ可用性があります。 詳細については、 メモリ最適化されたプレミアムシリーズハードウェアおよび16TBストレージを持つプレミアムシリーズハードウェアの地域サポートをご覧ください。
使用可能なインメモリ OLTP 領域
ビジネスクリティカルサービス層におけるインメモリOLTPの容量は、vCoreの数とハードウェア構成によって異なります。 以下の表は、インメモリOLTPオブジェクトで使用できるメモリの制限を示しています。
| 仮想コア | Standard シリーズ (Gen5) | Premium シリーズ | メモリ最適化 Premium シリーズ |
|---|---|---|---|
| 4 仮想コア | 3.14ギガバイト | 4.39ギガバイト | 8.79ギガバイト |
| 6 仮想コア | - | 6.59ギガバイト | 15.32ギガバイト |
| 8 仮想コア | 6.28ギガバイト | 8.79ギガバイト | 22.06ギガバイト |
| 10 仮想コア | - | 12.11ギガバイト | 30.94ギガバイト |
| 12 仮想コア | - | 15.43ギガバイト | 39.82ギガバイト |
| 16 仮想コア | 15.77ギガバイト | 22.06ギガバイト | 57.58ギガバイト |
| 20 仮想コア | - | 28.70ギガバイト | 75.34ギガバイト |
| 24 仮想コア | 25.25ギガバイト | 35.34ギガバイト | 93.09ギガバイト |
| 32 仮想コア | 37.94ギガバイト | 53.09ギガバイト | 128.61ギガバイト |
| 40 仮想コア | 52.23ギガバイト | 73.09ギガバイト | 164.13ギガバイト |
| 48 仮想コア | - | 95.34ギガバイト | 199.64ギガバイト |
| 56 仮想コア | - | 117.58ギガバイト | 244.13ギガバイト |
| 64 仮想コア | 99.9ギガバイト | 139.82ギガバイト | 288.61ギガバイト |
| 80 仮想コア | 131.68ギガバイト | 184.30ギガバイト | 288.61ギガバイト |
| 96 個の仮想コア | 該当なし | 184.30ギガバイト | 288.61ギガバイト |
| 128 個の仮想コア | 該当なし | 184.30ギガバイト | 288.61ギガバイト |
サービス レベルの特性
SQL Managed Instance には、General Purpose と Business Critical という 2 つのサービス レベルがあります。 アップグレードされた 次世代 General Purpose サービス レベルを使用することを選択できます。
重要
Business Critical service tierは、読み取り専用ワークロードに使用されるSQL Managed Instance(セカンダリカ)の追加組み込みコピーを提供します。 読み書きクエリを読み取り専用、解析クエリ、報告クエリと分けると、同じ価格でvCoreとメモリが2倍になります。 セカンダリプレカはプライマリインスタンスより数秒遅れることがあるため、正確な現在のデータ状態を必要としないレポートや解析ワークロードをオフロードするよう設計されています。 以下の表では、 読み取り専用クエリ はセカンダリカレプリカ上で実行されるクエリのことです。
このセクションの内容は次のとおりです。
- 仮想コアの数
- 最大メモリ
- インスタンスの最大ストレージ サイズ
- サービス レベルの特性の比較
- IOPS とスループット
- データストレージとログストレージ
- バックアップとストレージ
- その他の特性に関する考慮事項
仮想コアの数
| ハードウェアの生成 | General Purpose | 次世代の汎用 | Business Critical |
|---|---|---|---|
| Standard シリーズ (Gen5) | 21、4、8、16、24、32、40、64、80 | 4、8、16、24、32、40、64、80 | 4、8、16、24、32、40、64、80 |
| Premium シリーズ | 21、4、8、16、24、32、40、64、80 | 4、6、8、10、12、16、20、24、32、40、48、56、64、80、96、128 | 4、6、8、10、12、16、20、24、32、40、48、56、64、80、96、128 |
| メモリ最適化 Premium シリーズ | 4、8、16、24、32、40、64、80 | 4、6、8、10、12、16、20、24、32、40、48、56、64、80、96、128 | 4、6、8、10、12、16、20、24、32、40、48、56、64、80、96、128 |
1 2 仮想コア インスタンスのデプロイは、インスタンス プール内でのみ可能です。
最大メモリ
| ハードウェアの生成 | General Purpose | 次世代の汎用 | Business Critical |
|---|---|---|---|
| Standard シリーズ (Gen5) | 20.4GB - 408GB 5.1 GB/仮想コア |
20.4GB - 408GB 5.1 GB/仮想コア |
20.4GB - 408GB 各レプリカで 5.1 GB/仮想コア |
| Premium シリーズ | 28 GB から 560 GB 7 GB/仮想コア |
28 GB から 560 GB 7 GB/仮想コア |
28 GB から 560 GB 各レプリカで 7 GB/仮想コア最大 80 仮想コア1 |
| メモリ最適化 Premium シリーズ | 54.4GB - 870.4GB 13.6 GB/仮想コア |
54.4GB - 870.4GB 13.6 GB/仮想コア |
54.4GB - 870.4GB 各レプリカで 13.6 GB/仮想コア最大 64 仮想コア1 |
1 メモリと仮想コアの比率は、プレミアム シリーズ ハードウェアでは最大 80 個の仮想コア、メモリ最適化プレミアム シリーズでは最大 64 個の仮想コアのみに使用できます。 最大メモリは、80 個を超えるプレミアム シリーズ仮想コアの場合は 560 GB、64 個を超えるメモリ最適化プレミアム シリーズ仮想コアの場合は 870.4 GB に制限されます。
インスタンスの最大ストレージ サイズ (予約済み)
次の表に、各ハードウェア世代とサービス レベルの仮想コアの数に基づく最大ストレージ サイズを示します。
| ハードウェアの生成 | 一般目的1 | 次世代の汎用 | ビジネスクリティカル2 |
|---|---|---|---|
| Standard シリーズ (Gen5) | - 4 仮想コアの場合は 2 TB - 8 仮想コアの場合は 8 TB - その他のサイズの場合は 16 TB |
- 4 仮想コアの場合は 2 TB - 8 仮想コアの場合は 8 TB - 16、24 仮想コアの場合は 16 TB - 32、40、64、80 仮想コアの場合は 32 TB |
- 4、8、16 仮想コアの場合は 1 TB - 24 仮想コアの場合は 2 TB - 32、40、64、80 仮想コアの場合は 4 TB |
| Premium シリーズ | - 4 仮想コアの場合は 2 TB - 8 仮想コアの場合は 8 TB - その他のサイズの場合は 16 TB |
- 仮想コアが 4、6 の場合は 2 TB - 仮想コアが 8、10、12 の場合は 8 TB - 仮想コアが 16、20、24 の場合は 16 TB - 仮想コアが 32、40、48、56、64、80、96、128 の場合は 32 TB |
- 4、6 仮想コアの場合は 1 TB - 8 個、10 個、12 個の仮想コアの場合は 2 TB - 16、20 仮想コアの場合は 4 TB - 24、32、40、48、56 仮想コアの場合は 5.5 TB - 64、80、96、128 仮想コア3 の場合、5.5 TB または 16 TB (リージョンに応じて) |
| メモリ最適化 Premium シリーズ | - 4 仮想コアの場合は 2 TB - 8 仮想コアの場合は 8 TB - その他のサイズの場合は 16 TB |
- 仮想コアが 4、6 の場合は 2 TB - 仮想コアが 8、10、12 の場合は 8 TB - 仮想コアが 16、20、24 の場合は 16 TB - 仮想コアが 32、40、48、56、64、80、96、128 の場合は 32 TB |
- 4、6 仮想コアの場合は 1 TB - 8 個、10 個、12 個の仮想コアの場合は 2 TB - 16、20 仮想コアの場合は 4 TB - 24 仮想コアの場合は 5.5 TB - 32、40 仮想コア4 の場合、5.5 TB または 8 TB (リージョンによって異なります) - 48、56 仮想コアの場合は 12 TB - 64、80、96、128 仮想コアの場合は 16 TB |
1 General Purpose サービス レベルでは、 tempdb はローカル SSD ストレージを使用します。
2 Business Critical サービス レベルでは、 tempdb はローカル SSD ストレージとデータ ファイルとログ ファイルを共有します。
tempdbのサイズは、現在使用可能なインスタンス ストレージ サイズまで拡大できます。
3 これらの CPU 仮想コア番号に対して Premium シリーズ ハードウェアに 16 TB のストレージを提供できるのは 、主要リージョン のみです。 リージョンが小さい場合、使用可能なストレージは 5.5 TB に制限されます。
4 これらの CPU 仮想コア数に対して Premium シリーズメモリ最適化ハードウェアに 8 TB のストレージを提供できるのは 、主要リージョン のみです。 リージョンが小さい場合、使用可能なストレージは 5.5 TB に制限されます。
サービス レベルの特性の比較
| 特徴 | General Purpose | 次世代の汎用 | Business Critical |
|---|---|---|---|
| 最大データベース サイズ | 現在利用可能なインスタンスのサイズまで (仮想コア数に応じて)。 | 現在利用可能なインスタンスのサイズまで (仮想コア数に応じて)。 | 現在利用可能なインスタンスのサイズまで (仮想コア数に応じて)。 |
最大 tempdb データベース サイズ |
24 GB/仮想コア (96 から 1,920 GB) と現在利用可能なインスタンスのストレージ サイズに制限されています。tempdb 領域を増やすには、仮想コアを追加します。ログ ファイルは 120 GB に制限されています。 |
24 GB/仮想コア (96 から 1,920 GB) と現在利用可能なインスタンスのストレージ サイズに制限されています。tempdb 領域を増やすには、仮想コアを追加します。ログ ファイルは 120 GB に制限されています。 |
現在利用可能なインスタンスのストレージ サイズまで。 |
tempdb ファイルの最大数 |
128 | 128 | 128 |
| インスタンスごとの最大データベース数 | インスタンスのストレージ サイズの上限に達していない限り、1 インスタンスにつき 100 ユーザーデータベース。 | 500 ユーザー データベース | インスタンスのストレージ サイズの上限に達していない限り、1 インスタンスにつき 100 ユーザーデータベース。 |
| データベース ファイルの最大数 | インスタンスのストレージ サイズまたは Azure Premium ディスクの記憶域割り当ての領域の上限に達していない限り、インスタンスごとの 280 個。 | データベースあたり 4,096 ファイル | インスタンスのストレージ サイズの上限に達していない限り、データベースごとに 32,767 ファイル。 |
| データ ファイルの最大サイズ | 各データ ファイルの最大サイズは 8 TB です。 8 TB を超えるデータベースの場合、少なくとも 2 つのデータ ファイルを使用します。 | 現在利用可能なインスタンスのサイズまで (仮想コア数に応じて)。 | 現在利用可能なインスタンスのサイズまで (仮想コア数に応じて)。 |
| 最大ログ ファイル サイズ | 2 TB と現在利用可能なインスタンスのストレージ サイズに制限されています。 | 2 TB と現在利用可能なインスタンスのストレージ サイズに制限されています。 | 2 TB と現在利用可能なインスタンスのストレージ サイズに制限されています。 |
| データ/ログの IOPS (概算) | ファイルあたり 500 ～ 7,500 * IOPS を増やすには、ファイル サイズを大きくします |
予約ストレージ * 3 - VM の上限まで。 予約ストレージが 32 GB、64 GB、96 GB の場合は 300。 VM の上限は仮想コアの数により異なる 仮想コアが 4 つの VM の場合は 6400 IOPS - 仮想コアが 128 個の VM の場合は 80 K IOPS |
16 K - 320 K (4000 IOPS/仮想コア) IO パフォーマンスを向上させるには、仮想コアを追加します。 |
| データ スループット (概算) | ファイルあたり 100 - 250 MiB/秒 * IO パフォーマンスを向上させるには、ファイル サイズを増やします |
IOPS / 30 MBps - VM の上限まで。 予約ストレージが 32 GB、64 GB、96 GB の場合は 75 MBps。 | 制限なし。 |
| ログ書き込みのスループット制限 (インスタンスあたり) | 仮想コアあたり 4.5 MiB/秒 インスタンスあたり最大 120 MiB/秒 DB あたり 22 - 65 MiB/秒 (ログ ファイルのサイズに応じて) * IO パフォーマンスを向上させるには、ファイル サイズを増やします |
Standard シリーズ: 仮想コアあたり 4.5 MiB/秒 最大120 MiB/s Premium シリーズとメモリ最適化 Premium シリーズ: 仮想コアあたり 4.5 MiB/秒 最大 192 MiB/秒 |
Standard シリーズ: vCoreあたり16 MiB/s 最大160 MiB/s Premium シリーズとメモリ最適化 Premium シリーズ: vCoreあたり16 MiB/s 最大 192 MiB/秒 |
| ストレージ IO 待機時間 (約1) | 5 ～ 10 ms | 3 - 5 ms | 1 ～ 2 ms |
| インメモリ OLTP | サポート対象外 | サポート対象外 | 利用可能、サイズは仮想コアの数に依存 |
| 最大セッション数 | 30000 | 30000 | 30000 |
| 最大同時 worker 数 | 105 * 仮想コアの数 + 800 | 105 * 仮想コアの数 + 800 | 105 * 仮想コアの数 + 800 |
| 読み取り専用レプリカを使用して読み取り専用クエリ ワークロードをオフロード | 0 | 0 | 1 (価格に含まれます) |
| コンピューティングの分離 | General Purpose インスタンスは物理ハードウェアを他のインスタンスと共有する可能性があるため、サポートされていません | 次世代汎用インスタンスは物理ハードウェアを他のインスタンスと共有する可能性があるため、サポートされていません |
Standard シリーズ (Gen5): 64 以上の仮想コアを持つ構成でサポートされます Premium シリーズの: 64 以上の仮想コアを持つ構成でサポートされます メモリ最適化 プレミアム シリーズ: 64 以上の仮想コアを持つ構成でサポートされます |
| 可用性用のレプリカ | 高可用性のためのスタンバイ ノード | 高可用性のためのスタンバイ ノード | 高可用性レプリカが 4 つで、1 つは読み取りスケール レプリカでもあります |
| フェールオーバー グループが有効になっている読み取り専用レプリカ | 追加の読み取り専用レプリカを 1 つ。 プライマリ レプリカを含めて、読み取り可能なレプリカが合計 2 つ。 | 追加の読み取り専用レプリカを 1 つ。 プライマリ レプリカを含めて、読み取り可能なレプリカが合計 2 つ。 | 追加の読み取り専用レプリカを 2 つと読み取り専用レプリカを合計 3 つ。 プライマリ レプリカを含めて、読み取り可能なレプリカが合計 4 つ。 |
| 価格/課金 |
仮想コア、予約ストレージ、バックアップ ストレージに対して請求されます。 IOPS が課金されない |
仮想コア、予約ストレージ、バックアップ ストレージ、IOPS (無料クォータ超) が課金されます。 |
仮想コア、予約ストレージ、バックアップ ストレージに対して請求されます。 IOPS は課金されません。 |
| 割引モデル | Azure の予約 を Azure ハイブリッド特典 - Azure SQL Database & SQL Managed Instance (開発/テスト サブスクリプションでは使用できません) Enterprise および開発テスト用の従量課金制プラン サブスクリプション |
Azure の予約 を Azure ハイブリッド特典 - Azure SQL Database & SQL Managed Instance (開発/テスト サブスクリプションでは使用できません) Enterprise および開発テスト用の従量課金制プラン サブスクリプション |
Azure の予約 を Azure ハイブリッド特典 - Azure SQL Database & SQL Managed Instance (開発/テスト サブスクリプションでは使用できません) Enterprise および開発テスト用の従量課金制プラン サブスクリプション |
1 これは平均範囲です。 IO 要求期間の大部分は範囲の最上位に当たりますが、範囲を超える外れ値が可能です。
IOPS とスループット
IOPS とスループットは、IO ファイル システムの特性です。
IOPS とスループットは、次の方法でサービス レベルによって異なります。
- Business Critical サービス レベルでは、スループットは無制限です。
- General Purpose サービス レベルでは、スループットはファイル サイズによって異なります。
- 次世代 General Purpose サービス レベルでは、スループットは、インスタンスに割り当てられた IOPS の数に比例してスケーリングされます。
以降のセクションでは、サービス レベル別の IO 特性について詳しく説明します。
General Purpose サービス レベルの IOPS とスループット
General Purpose サービス レベルでは、すべてのデータベース ファイルで、ファイルのサイズに依存する専用の IOPS とスループットが取得されます。 ファイルが大きいほど、IOPS とスループットも大きくなります。
次の表に、 General Purpose サービス レベルのデータベース ファイルの IO 特性を示します。
| ファイル サイズ | >=0 および <=129 GiB | >129 および <=513 GiB | >513 および <=1025 GiB | >1025 および <=2049 GiB | >2049 および <=4097 GiB | >4097 GiB および <=8 TiB |
|---|---|---|---|---|---|---|
| ファイル あたりの IOPS を |
500 | 2300 | 5,000 | 7500 | 7500 | 7500 |
| ファイル あたりのスループットの |
100 MiB/秒 | 150 MiB/秒 | 200 MiB/秒 | 250 MiB/秒 | 250 MiB/秒 | 250 MiB/秒 |
何らかのデータベース ファイルに対する IO 待機時間が長いことに気付いた場合、または IOPS/スループットが上限に達している場合は、ファイルのサイズを大きくすることで、パフォーマンスを改善できる場合があります。
最大ログ書き込み処理能力に対するインスタンス レベルの制限もあるため (22 MiB/秒などの値については上記の表を参照)、インスタンスの処理能力制限に達したことが原因で、ログ ファイルに対する最大ファイル処理能力に達することができない場合があります。
次世代 General Purpose サービス レベルの IOPS とスループット
次世代の General Purpose サービス レベルには、次の IOPS 特性があります。
- 最小保証 IOPS: 予約ストレージに関係なく、すべてのインスタンスで最低 300 IOPS が保証されます。
- IOPS は予約ストレージを使用してスケーリングされます。1 GB の予約ストレージごとに、3 つの組み込み IOPS が得られます。 たとえば、1024 GB の予約ストレージがある場合、3072 IOPS が割り当てられます。
- 追加の IOPS: 上限まで、組み込みの値を超える IOPS の量を増やすことができます。
- 仮想コア数あたりの最大 IOPS 上限: 仮想コアテーブルあたりの最大 IOPS が示すように、各仮想コア構成には最大 IOPS 制限があります。
次世代 General Purpose サービス レベルには、次のスループット特性があります。
- 最小保証スループット: 仮想コアの数に関係なく、すべてのインスタンスで最低 75 MB/秒のスループットが保証されます。
-
スループットは IOPS でスケーリングされます。スループットは、数式
throughput (MB/s) = IOPS / 30を使用して、インスタンスに割り当てられた IOPS の数に比例してスケーリングされます。 たとえば、3,000 IOPS で割り当てられたインスタンスは、100 MB/秒のスループットを受け取ります。 - 仮想コアあたりの最大スループット上限: 仮想コアテーブルあたりの最大スループットが示すように、各仮想コア構成には最大スループット制限があります。 この上限に達するために必要な IOPS がプロビジョニングされると、追加の IOPS を割り当てると IOPS 容量は増加しますが、スループットはそれ以上増加しません。 たとえば、4 仮想コア インスタンス (最大 6,400 IOPS) は、4,350 IOPS で 145 MB/秒のスループット上限に達します。 IOPS を 4,350 から 6,400 にスケーリングすると、インスタンスに対してより多くの IOPS が提供されますが、スループットは 145 MB/秒に制限されたままです。 最大スループットを増やすには、仮想コアを追加します。
次の表は、次世代 General Purpose サービス レベルのインスタンスに割り当てられた仮想コアの数あたりの最大 IOPS とスループットを示しています。
| 仮想コアの数 | 最大 IOPS | 最大スループット (MB/秒) |
|---|---|---|
| 4 | 6,400 | 145 |
| 6 | 9,600 (九千六百) | 217 |
| 8 | 12,800 | 290 |
| 10 | 16,000 | 367 |
| 12 | 19,200 | 445 |
| 16 | 25,600 | 600 |
| 20 | 32,000 | 665 |
| 二十四 | 三万八千四百 | 730 |
| 32 | 5万1,200 | 865 |
| 40 | 64,000 | 1,152 |
| 48 | 76,800 | 1,152 |
| 56 - 128 | 80,000 | 1,200 |
次世代汎用の IOPS 価格
追加の IOPS を使用する場合は、次の点を考慮してください。
- 追加の IOPS は IOPS/月ごとに課金されます
- 課金対象の IOPS は、次の数式によって計算されます:
Billable IOPS = Total IOPS - default IOPS。
たとえば、従量課金制の 4 仮想コア インスタンスが 6400 IOPS の場合、次の料金が発生します。
- 4 仮想コア
- 4 仮想コアの SQL ライセンス
- 1024 GB の予約ストレージ
- 課金対象の IOPS
(6400 - (1024*3) = 3328 IOPS)の 3328。
Business Critical サービス レベルの IOPS とスループット
Business Critical サービス レベルでは、使用可能な IOPS は、数式 4000 IOPS/vCoreを使用した仮想コアの数によって決まります。 Business Critical サービス レベルではデータ ファイルとログ ファイルにローカル ストレージが使用されるため、スループットは無制限です。
次の表に、仮想コアの数に基づいて Business Critical サービス レベルで使用できる最大 IOPS を示します。
| 仮想コアの数 | Business Critical |
|---|---|
| 4 | 16,000 |
| 6 | 24,000 |
| 8 | 32,000 |
| 10 | 40,000 |
| 12 | 48,000 |
| 16 | 64,000 |
| 20 | 80,000 |
| 二十四 | 96,000 |
| 32 | 128,000 |
| 40 | 160,000 |
| 48 | 192,000 |
| 56 | 224,000 |
| 64 | 256,000 |
| 80 | 320,000 |
| 96 | 320,000 |
| 128 | 320,000 |
データとログのストレージ
以下の要因がデータおよびログファイルの保存容量に影響を与えます。 これらの要素は、汎用層とビジネスクリティカル層の両方に当てはまります。
- General Purpose サービス レベルでは、
tempdbによってローカル SSD が使用され、このストレージ コストは、仮想コアの価格に含まれます。 - ビジネスクリティカルサービス層では、
tempdbローカルSSDストレージとデータおよびログファイルを共有し、tempdbストレージコストはvCore価格に含まれます。 現在使用可能なインスタンスストレージサイズまでtempdbサイズを設定できます。 - SQL Managed Instanceの最大ストレージ容量は32GBの倍数で指定する必要があります。
重要
どちらのサービス層でも、SQL Managed Instanceで設定された最大ストレージサイズに対して料金を支払います。
SQL Managed Instance の消費されている合計インスタンス ストレージ サイズを監視するには、storage_space_used_mbメトリックを使用します。 T-SQL を使用して、データベース内の個々のデータ ファイルとログ ファイルの現在の割り当て済みおよび使用されているストレージ サイズを監視するには、sys.database_files ビューと FILEPROPERTY(... , 'SpaceUsed') 関数を使用します。
ヒント
状況によっては、使用されていない領域を再利用するためにデータベースを圧縮する必要がある場合があります。 詳細については、DBCC SHRINKFILE に関するページを参照してください。
バックアップとストレージ
データベース バックアップ用のストレージは、SQL Managed Instance のポイントインタイム リストア (PITR) および長期保有 (LTR) 機能をサポートするために割り当てられます。 このストレージは、データファイルとログファイルのストレージとは別に、別途請求されます。
PITR: General Purpose レベルと Business Critical レベルでは、個々のデータベース バックアップは、読み取りアクセス geo 冗長 (RA-GRS) ストレージに自動的にコピーされます。 ストレージ サイズは、新しいバックアップが作成されるにつれて、動的に増大します。 ストレージは、完全バックアップ、差分バックアップ、およびトランザクション ログ バックアップで使われます。 ストレージの使用量は、データベースの変化率とバックアップに構成された保有期間に応じて異なります。 保有期間は、データベースごとに、SQL Managed Instance の場合は 1 日から 35 日の間で個別に構成できます。 構成済みの最大データ サイズに等しいバックアップ ストレージ容量が、追加料金なしで提供されます。
LTR: 最大 10 年間の完全バックアップとなる長期保存を構成することもできます。 LTR ポリシーを設定した場合、これらのバックアップは、RA-GRS ストレージに自動的に格納されますが、バックアップがコピーされる頻度は制御できます。 異なるコンプライアンス要件を満たすために、週ごとの、月ごとの、年間のバックアップの保存期間を異なるものに設定できます。 選択した構成によって、LTR バックアップに使われるストレージの量が決まります。 詳細については、「長期的なリテンション期間 - Azure SQL Database と Azure SQL Managed Instance」を参照してください。
その他の特性に関する考慮事項
現在利用可能なインスタンスのストレージ サイズは、予約インスタンスのサイズと使用されているストレージ スペースの差です。
ユーザー データベースとシステム データベースのデータ ファイルおよびログ ファイルのサイズはどちらも、最大ストレージ サイズの制限と比較されるインスタンス ストレージ サイズに含まれます。 データベースによって使用される合計領域を確認するには、sys.master_files システム ビューを使用します。 エラー ログは保持されず、サイズには含まれません。 バックアップはストレージ サイズに含まれません。
General Purpose レベルの処理能力と IOPS もファイル サイズによって変わり、明示的には SQL Managed Instance によって制限されません。
最大インスタンス IOPS は、ワークロードにおけるファイルのレイアウトおよび分散に依存します。 たとえば、それぞれ最大 5 K IOPS を持つ 1-TB ファイルを 7 個と、それぞれ 500 IOPS を持つ小さいファイル (128 GB 未満) を 7 個作成したとすると、ワークロードですべてのファイルを使用できる場合、インスタンスあたり 38500 IOPS (7 x 5000 + 7 x 500) を取得できます。 一部の IOPS は、自動バックアップにも使用されます。
フェールオーバー グループを利用すれば、異なる Azure リージョンで別の読み取り可能レプリカを作成できます
tempdbファイルの名前は、16 文字を超えることができません。
詳細については、こちらの記事の SQL Managed Instance プールでのリソース制限に関する説明を参照してください。
フレキシブルメモリ
既定では、Azure SQL Managed Instance に割り当てられるメモリの量は、選択した仮想コア数によって決まる静的な値です。 柔軟なメモリ機能を使用すると、仮想コアの数を変更することなく、SQL マネージド インスタンスに割り当てられたメモリの量を変更できます。 この機能は、特定の数の仮想コアに対する既定の割り当てよりも多くのメモリを必要とするワークロードに役立ちます。
柔軟なメモリ機能は、 Premium シリーズ ハードウェア上の次のサービス レベルとデプロイ構成で使用できます。
- 次世代汎用: ローカル冗長 および ゾーン冗長 インスタンス。 フレキシブルメモリはローカル冗長インスタンス向けに一般に提供されており(GA)、現在ゾーン冗長インスタンス向けにプレビュー段階です。 ゾーン冗長性の次世代汎用インスタンスは、Azure Elastic SANゾーン冗長ストレージ(ZRS)を必要としますが、SQL Managed Instanceのゾーン冗長性をサポートする一部のマルチゾーン地域では利用できません。 Elastic SAN ZRSの利用可能性については、「Create and deploy an Azure Elastic SAN」をご覧ください。
- Business Critical: ローカル冗長 インスタンスと ゾーン冗長 インスタンス。 FlexibleメモリはBusiness Critical Service Tier向けに一般に提供されています(GA)。
AzureポータルやREST APIを使って、新規および既存インスタンスに対してSQL管理インスタンスに割り当てられるメモリ量をいつでも変更できます。 メモリ割り当ての変更はインスタンス内のすべてのデータベースに適用され、最終操作ステップとしてインスタンスのフェイルオーバーを実行します。 管理操作の期間を確認して、操作が完了するまでの推定時間を決定します。
AzureポータルのCompute + storageパネルを使ってメモリ割り当てや、2024年8月1日プレビュー版からManaged Instance - REST の作成または更新API呼び出しのproperties.memorySizeInGB値を変更してください。 メモリ割り当てをギガバイト(GB)で指定してください。
メモリを割り当てるときは、最小値と最大値の間で選択し、仮想コアに対するメモリの比率を決定することもできます。 最小値と最大値は、インスタンスで選択したvCoreの数によって異なります。 メモリと仮想コアの比率は、インスタンスに割り当てられたメモリの合計に対する割合です。
次の表は、フレキシブル メモリ機能の最小メモリ値と最大メモリ値を示しています。
| 仮想コア | 最小 RAM (GB) | 最大 RAM (GB) | サポートされている API RAM 値 | 最小比率 | 最大比率 | サポートされている比率 |
|---|---|---|---|---|---|---|
| 4 | 28 | 48 | 28, 32, 40, 48 | 7 | 12 | 7, 8, 10, 12 |
| 6 | 42 | 72 | 42, 48, 60, 72 | 7 | 12 | 7, 8, 10, 12 |
| 8 | 56 | 96 | 56, 64, 80, 96 | 7 | 12 | 7, 8, 10, 12 |
| 10 | 70 | 120 | 70, 80, 100, 120 | 7 | 12 | 7, 8, 10, 12 |
| 12 | 84 | 144 | 84, 96, 120, 144 | 7 | 12 | 7, 8, 10, 12 |
| 16 | 112 | 192 | 112, 128, 160, 192 | 7 | 12 | 7, 8, 10, 12 |
| 20 | 140 | 240 | 140, 160, 200, 240 | 7 | 12 | 7, 8, 10, 12 |
| 二十四 | 168 | 288 | 168, 192, 240, 288 | 7 | 12 | 7, 8, 10, 12 |
| 32 | 224 | 384 | 224, 256, 320, 384 | 7 | 12 | 7, 8, 10, 12 |
| 40 | 280 | 480 | 280, 320, 400, 480 | 7 | 12 | 7, 8, 10, 12 |
| 48 | 336 | 480 | 336, 384, 480 | 7 | 10 | 7, 8, 10 |
| 56 | 392 | 448 | 392, 448 | 7 | 8 | 7、8 |
| 64 | 448 | 448 | 448 | 7 | 7 | 8 |
| 80 | 560 | 560 | 560 | 7 | 7 | 8 |
| 96 | 560 | 560 | 560 | 5.83 | 5.83 | 5.83 |
| 128 | 560 | 560 | 560 | 4.38 | 4.38 | 4.38 |
価格設定
フレキシブルメモリ機能を使う際は、以下の点を考慮してください。
- 追加メモリは1時間あたりGB単位で支払っています。
- 請求可能なメモリは次の式を使います:
Billable memory = Total memory - default memory。
例えば、40GBメモリの使い古分課金型4 vCoreインスタンスを使う場合、以下の料金を支払います:
- 4 仮想コア
- 4 仮想コアの SQL ライセンス
- 12 GB の課金対象メモリ (40 GB - (4*7) = 12 GB)。
サポートされているリージョン
SQL Managed Instanceはサポートされているリージョンでのみ作成可能です。 現在サポートされていないリージョンでSQL Managed Instanceを作成するには、Azureポータルを通じてサポートリクエストを送信してください。
サポートされているサブスクリプションの種類
SQL Managed Instanceは現在、以下のサブスクリプションタイプでのみ展開をサポートしています:
- エンタープライズ契約(EA)
- 従量課金制
- クラウド サービス プロバイダー (CSP)
- エンタープライズ開発/テスト
- 開発テスト用の従量課金制プラン
- Visual Studio サブスクライバー向けの毎月の Azure クレジット付きサブスクリプション
- 無料試用版
- 学生向けの Azure
- Azure イン オープン プラン
- Azure プラン
リージョンのリソース制限
注
サブスクリプションの利用可能なリージョンに関する最新情報については、まず、リージョンの選択に関するページを確認してください。
サポートされているサブスクリプションの種類には、リージョンごとのリソース数の制限を組み入れることができます。 SQL Managed Instanceには、サブスクリプションの種類に応じてAzureリージョンごとに1つのデフォルト制限があります(Azureポータルで特別なサポートリクエストを作成してオンデマンドで増やせます):
- vCoreユニット制限:ハードウェア世代あたり、単一のリージョン内の全インスタンスに展開できる最大vCoreユニット数。 1 つの GP 仮想コアでは仮想コア ユニットを 1 つ使用し、1 つの BC 仮想コアでは仮想コア ユニットを 4 つ使用します。 インスタンスの合計数は、仮想コアユニットの制限内にある限り制限されません。
注
これらの制限は既定の設定であり、技術的な制限ではありません。 現在のリージョンでより多くのインスタンスが必要な場合は、Azureポータルで特別なサポートリクエストを作成してオンデマンドで制限を増やすことができます。 サポート リクエストを送信せずに、代わりに、別の Azure リージョンに SQL Managed Instance の新しいインスタンスを作成することも可能です。
次の表は、サポートされている種類のサブスクリプションを対象に、既定のリージョン別制限についてまとめたものです (既定の制限は、サポート リクエストを利用して拡張できます)。
| サブスクリプションの種類 | 仮想コア ユニットの既定の制限 1 |
|---|---|
| CSP | 960 (一部の地域では 14402) |
| EA | 960 (一部の地域では 14402) |
| Enterprise Dev/Test | 320 |
| 従量課金制 | 320 |
| 開発テスト用の従量課金制プラン | 320 |
| Azure Pass | 64 |
| BizSpark | 64 |
| ビズパークプラス | 64 |
| Microsoft Azure スポンサー プラン | 64 |
| Microsoft Partner Network | 64 |
| Visual Studio エンタープライズ (MPN) | 64 |
| Visual Studio Enterprise | 32 |
| Visual Studio Enterprise (BizSpark) | 32 |
| Visual Studio Professional | 32 |
| MSDN Platforms | 32 |
1 展開計画においては、ビジネスクリティカル(BC)サービス層は汎用(GP)サービス層の4倍のvCore容量を必要とすることを考慮してください。 次に例を示します。1 つの GP 仮想コア = 1 つの仮想コア ユニット、1 つの BC 仮想コア = 4 つの仮想コアとなります。 デフォルトの制限に対する消費分析を簡単にするために、SQL Managed Instanceが展開されている地域の全インスタンスのハードウェア世代ごとのvCoreユニットを要約し、サブスクリプションタイプのvCoreユニットの上限と比較してください。 vCore ユニットの最大数 制限は、各地域のハードウェア世代ごとのサブスクリプションに適用されます。
以下の地域で利用可能な2つのより大きなvCore制限があります:オーストラリア東部、東部米国、東部米国2、北ヨーロッパ、南中部米国、東南アジア、英国南部、西ヨーロッパ、西米国2。
重要
もしvCoreの制限が0なら、サブスクリプションタイプのデフォルトの地域制限が設定されていないことを意味します。 特定の地域でサブスクリプションアクセスを得るためにも同じ手順でクォータ増加リクエストを使い、必要なvCore値を指定することもできます。
地域の容量制限がある場合、デフォルトの地域vCore制限は減少または停止可能です。
PowerShellでvCoreのクォータ制限と使用状況を確認してください
サブスクリプション使用履歴 - REST APIを使って、サブスクリプションとリージョンにおけるAzure SQL Managed Instanceの現在のvCoreクォータの上限と消費量を取得してください。 各ハードウェア世代ごとに、使用名を指定することで個別にクエリを行います:
| ハードウェアの生成 | 使用名 |
|---|---|
| Standard シリーズ (Gen5) | SubscriptionSQLManagedInstanceStandardSeriesVCoreQuota |
| Premium シリーズ | SubscriptionSQLManagedInstancePremiumSeriesVCoreQuota |
| メモリ最適化 Premium シリーズ | SubscriptionSQLManagedInstancePremiumSeriesMemoryOptimizedVCoreQuota |
AzモジュールをインストールしたPowerShellセッションで、またはPowerShellを使ってAzure Cloud Shellで以下のスクリプトを実行します。 サブスクリプション使用状況を読むには、サブスクリプション範囲で割り当てられた リーダーの役割 など、アカウントの許可が必要です。
<subscription-id>をサブスクリプションIDに置き換え、$locationをAzureリージョン名(例:eastus)に設定し、前の表の$usageNameのいずれかに設定します。 すでにCloud Shellでサインインしている場合は、Connect-AzAccountを省略してください。
$subscriptionId = "<subscription-id>"
$location = "eastus"
$usageName = "SubscriptionSQLManagedInstanceStandardSeriesVCoreQuota"
Connect-AzAccount -ErrorAction Stop | Out-Null
Set-AzContext -SubscriptionId $subscriptionId -ErrorAction Stop | Out-Null
$path = "/subscriptions/$subscriptionId/providers/Microsoft.Sql/locations/$location/usages/${usageName}?api-version=2025-01-01"
$response = Invoke-AzRestMethod -Method GET -Path $path -ErrorAction Stop
if ($response.StatusCode -ne 200) {
throw "Unable to retrieve quota usage. HTTP $($response.StatusCode): $($response.Content)"
}
$response.Content | ConvertFrom-Json -ErrorAction Stop | ConvertTo-Json -Depth 10
例示の出力(抜粋;値は図示的):
{
"name": "SubscriptionSQLManagedInstanceStandardSeriesVCoreQuota",
"properties": {
"currentValue": 80,
"limit": 320,
"unit": "SubscriptionSQLManagedInstanceStandardSeriesVCoreQuota"
}
}
この例では、 properties.currentValue は現在の割当消費量、すなわち 80 vCoreユニットです。
properties.limit 現在のクォータ制限である 320 vCoreユニットです。 残りのクォータは、指定されたサブスクリプションおよび地域における標準シリーズハードウェア向けに limit - currentValue台、すなわち 240台のvCoreユニットです。
このセクションの前述のように、各汎用vCoreは1ユニットのvCoreを消費し、1つのBusiness Critical vCoreは4つのvCoreユニットを消費します。 別の $usageName や $location でリクエストを繰り返し、別のハードウェア世代や地域を確認してください。 制限を増やすには 、「割当量増額の要求」をご覧ください。
重要
以前はすべてのハードウェア世代で共有される単一の地域割当を表す VCoreQuota 使用名は廃止され、ハードウェア世代固有の割当に置き換えられています。 前の表に記載されている使用名を使って、各ハードウェア世代のクォータ制限と消費量を取得します。
クォータの増加を要求する
現在のリージョンでより多くのインスタンスが必要な場合は、Azureポータルを使ってクォータ延長のサポートリクエストを送ってください。 詳細については、「Azure SQL Database と SQL Managed Instanceのクォータの引き上げを要求する」を参照してください。
注
2026年8月以降、SQL Managed Instanceのクォータ要求タイプが変更されました。 サブネットのクォータは適用されなくなり、vCoreのクォータはハードウェア世代ごとにスコープ化されています。 詳細については、SQL Managed Instance quota request types をご覧ください。
関連コンテンツ
- Azure SQL Managed Instance とは
- SQL Managed Instance の価格 を
する - クイック スタート ガイドの を
する - Azure SQL Managed Instance 用 SLA
- Azure SQL マネージド インスタンスの変更可能な構成リファレンス