Azure SQL Managed Instance のリソース制限の概要
適用対象: Azure SQL Managed Instance
この記事では、Azure SQL Managed Instance の技術特性とリソース制限の概要を示し、これらの制限の引き上げを要求する方法について説明します。
Note
サポートされている機能と T-SQL ステートメントの違いについては、機能の違いと T-SQL ステートメントのサポートに関するページをご覧ください。 Azure SQL Database と SQL Managed Instance の間の一般的な違いについては、General Purpose と Business Critical のサービス レベルを確認してください。
ハードウェア構成の特性
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 | 汎用: 最大 16 TB Business Critical: 最大 4 TB |
汎用: 最大 16 TB Business Critical: 最大 16 TB3 |
General Purpose: 最大 16 TB Business Critical: 最大 16 TB |
1 2 仮想コア インスタンスのデプロイは、インスタンス プール内でのみ可能です。
2 仮想コアの数によって異なります。
3 主要リージョン に限り 16 TB のストレージを提供できます。 リージョンが小さい場合、使用可能なストレージは 5.5 TB に制限されます。
Note
ワークロードで必要なストレージ サイズが Azure SQL Managed Instance で使用できるリソース制限を超える場合は、Azure SQL Database の Hyperscale サービス レベルを検討してください。
メモリ最適化のプレミアム シリーズ ハードウェアおよび 16 TB ストレージのプレミアム シリーズ ハードウェアのリージョン サポート
16 TB ストレージのプレミアム シリーズ ハードウェアのサポートには、メモリ最適化のプレミアム シリーズ ハードウェアのサポートと同じ可用性があります。 メモリ最適化のプレミアム シリーズ ハードウェアおよび 16 TB ストレージのプレミアム シリーズ ハードウェアのサポートは、現在次の特定のリージョンでのみ利用できます。
地理的な場所 | メモリ最適化の Premium シリーズ HW および 16 TB (テラバイト) ストレージを持った Premium シリーズ ハードウエアをサポートするリージョン |
---|---|
ヨーロッパ | フランス中部、ドイツ中西部、イタリア北部、北ヨーロッパ、ポーランド中部、スウェーデン中部、スイス北部、英国南部、西ヨーロッパ |
中東、アフリカ | カタール中部 |
アメリカ | ブラジル南部、カナダ中部、米国中部、米国東部、米国東部 2、米国中北部、米国中南部、米国西部、米国西部 2、米国西部 3 |
アジア太平洋 | オーストラリア東部、オーストラリア南東部、中国北部 3、インド中部、インド南部、東アジア、東日本、東南アジア |
使用可能なインメモリ OLTP 領域
Business Critical サービス レベルのインメモリ OLTP 領域の容量は、仮想コアの数とハードウェアの構成によって異なります。 次の表では、インメモリ OLTP オブジェクトに使用できるメモリの制限の一覧を示します。
仮想コア | Standard シリーズ (Gen5) | Premium シリーズ | メモリ最適化 Premium シリーズ |
---|---|---|---|
4 仮想コア | 3.14 GB | 4.39 GB | 8.79 GB |
6 仮想コア | - | 6.59 GB | 15.32 GB |
8 仮想コア | 6.28 GB | 8.79 GB | 22.06 GB |
10 仮想コア | - | 12.11 GB | 30.94 GB |
12 仮想コア | - | 15.43 GB | 39.82 GB |
16 仮想コア | 15.77 GB | 22.06 GB | 57.58 GB |
20 仮想コア | - | 28.70 GB | 75.34 GB |
24 仮想コア | 25.25 GB | 35.34 GB | 93.09 GB |
32 仮想コア | 37.94 GB | 53.09 GB | 128.61 GB |
40 仮想コア | 52.23 GB | 73.09 GB | 164.13 GB |
48 仮想コア | - | 95.34 GB | 199.64 GB |
56 仮想コア | - | 117.58 GB | 244.13 GB |
64 仮想コア | 99.9 GB | 139.82 GB | 288.61 GB |
80 仮想コア | 131.68 GB | 184.30 GB | 288.61 GB |
96 個の仮想コア | 該当なし | 184.30 GB | 288.61 GB |
128 個の仮想コア | 該当なし | 184.30 GB | 288.61 GB |
サービス レベルの特性
SQL Managed Instance には、General Purpose と Business Critical という 2 つのサービス レベルがあります。 アップグレードされた Next-gen General Purpose サービス レベル (プレビュー) の使用を選択できます。
重要
Business Critical サービス レベルには、読み取り専用ワークロードに使用できる SQL Managed Instance の追加の組み込みコピー (セカンダリ レプリカ) が用意されています。 読み取りおよび書き込みクエリと、読み取り専用、分析、レポート クエリとを分離できる場合は、同じ価格で仮想コアとメモリを 2 度取得することになります。 セカンダリ レプリカは、プライマリ インスタンスよりも数秒遅れる場合があるため、データの正確な現在の状態を必要としないレポートと分析のワークロードをオフロードするように設計されています。 次の表で、読み取り専用クエリは、セカンダリ レプリカ上で実行されるクエリです。
仮想コアの数
ハードウェアの世代 | 汎用 | Next-gen 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 仮想コア インスタンスのデプロイは、インスタンス プール内でのみ可能です。
最大メモリ
ハードウェアの世代 | 汎用 | Next-gen General Purpose | Business Critical |
---|---|---|---|
Standard シリーズ (Gen5) | 20.4 GB 〜 408 GB 5.1 GB/仮想コア |
20.4 GB 〜 408 GB 5.1 GB/仮想コア |
20.4 GB 〜 408 GB 各レプリカで 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.4 GB 〜 870.4 GB 13.6 GB/仮想コア |
54.4 GB 〜 870.4 GB 13.6 GB/仮想コア |
54.4 GB 〜 870.4 GB 各レプリカで 13.6 GB/仮想コア最大 64 仮想コア1 |
1 メモリと仮想コアの比率は、プレミアム シリーズ ハードウェアでは最大 80 個の仮想コア、メモリ最適化プレミアム シリーズでは最大 64 個の仮想コアのみに使用できます。 最大メモリは、80 個を超えるプレミアム シリーズ仮想コアの場合は 560 GB、64 個を超えるメモリ最適化プレミアム シリーズ仮想コアの場合は 870.4 GB に制限されます。
インスタンスの最大ストレージ サイズ (予約済み)
ハードウェアの世代 | 汎用 | Next-gen General Purpose | Business Critical |
---|---|---|---|
Standard シリーズ (Gen5) | - 4 仮想コアの場合は 2 TB - 8 仮想コアの場合は 8 TB - その他のサイズの場合は 16 TB |
- 4 仮想コアの場合は 2 TB - 8 仮想コアの場合は 8 TB - その他のサイズの場合は 16 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 仮想コア1の場合は、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 仮想コア2の場合は 5.5 TB または 8 TB (リージョンに応じて) - 48、56 仮想コアの場合は 12 TB - 64、80、96、128 仮想コアの場合は 16 TB |
1 これらの CPU 仮想コア数に対してプレミアム シリーズ ハードウェアに 16 TB のストレージを提供できるのは、主要リージョンのみです。 リージョンが小さい場合、使用可能なストレージは 5.5 TB に制限されます。
2 これらの CPU 仮想コア数に対してプレミアム シリーズのメモリ最適化ハードウェアに 8 TB のストレージを提供できるのは、主要リージョンのみです。 リージョンが小さい場合、使用可能なストレージは 5.5 TB に制限されます。
機能の比較
機能 | 汎用 | Next-gen 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 |
インスタンスごとの最大データベース数 | インスタンスのストレージ サイズの上限に達していない限り、データベースごとに 100 ユーザー。 | 500 ユーザー データベース | インスタンスのストレージ サイズの上限に達していない限り、データベースごとに 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 パフォーマンスを向上させるには、ファイル サイズを増やします |
仮想コアあたり 4.5 MiB/秒 最大 192 MiB/秒 |
仮想コアあたり 4.5 MiB/秒 最大 192 MiB/秒 |
ストレージ IO 待機時間 (概算) | 5 ~ 10 ms | 3 - 5 ms | 1 ~ 2 ms |
インメモリ OLTP | サポート対象外 | サポート対象外 | 利用可能、サイズは仮想コアの数に依存 |
最大セッション数 | 30000 | 30000 | 30000 |
最大同時 worker 数 | 105 * 仮想コアの数 + 800 | 105 * 仮想コアの数 + 800 | 105 * 仮想コアの数 + 800 |
読み取り専用レプリカ | 0 | 0 | 1 (価格に含まれます) |
コンピューティングの分離 | 汎用インスタンスによって、他のインスタンスと物理ハードウェアが共有される可能性があるため、サポートされていません | Next-gen General Purpose インスタンスによって、物理ハードウェアが他のインスタンスと共有される場合があるため、サポートされていません | スタンダード シリーズ (Gen5) : 64 以上の仮想コアを持つ構成でサポートされます プレミアム シリーズ: 64 以上の仮想コアを持つ構成でサポートされます メモリ最適化 プレミアム シリーズ: 64 以上の仮想コアを持つ構成でサポートされます |
可用性用のレプリカ | 高可用性のためのスタンバイ ノード | 高可用性のためのスタンバイ ノード | 高可用性レプリカが 4 つで、1 つは読み取りスケール レプリカでもあります |
フェールオーバー グループが有効になっている読み取り専用レプリカ | 追加の読み取り専用レプリカを 1 つ。 プライマリ レプリカを含めて、読み取り可能なレプリカが合計 2 つ。 | 追加の読み取り専用レプリカを 1 つ。 プライマリ レプリカを含めて、読み取り可能なレプリカが合計 2 つ。 | 追加の読み取り専用レプリカを 2 つと読み取り専用レプリカを合計 3 つ。 プライマリ レプリカを含めて、読み取り可能なレプリカが合計 4 つ。 |
価格/課金 | 仮想コア、予約ストレージ、バックアップ ストレージに対して請求されます。 IOPS は課金されません |
仮想コア、予約ストレージ、バックアップ ストレージ、IOPS (無料クォータ超) が課金されます。 | 仮想コア、予約ストレージ、バックアップ ストレージに対して請求されます。 IOPS は課金されません。 |
割引モデル | 予約インスタンス Azure ハイブリッド特典 (開発テスト サブスクリプションでは利用不可) Enterprise および開発テスト用の従量課金制プラン サブスクリプション |
予約インスタンス Azure ハイブリッド特典 (開発テスト サブスクリプションでは利用不可) Enterprise および開発テスト用の従量課金制プラン サブスクリプション |
予約インスタンス Azure ハイブリッド特典 (開発テスト サブスクリプションでは利用不可) Enterprise および開発テスト用の従量課金制プラン サブスクリプション |
その他の注意点:
- 現在利用可能なインスタンスのストレージ サイズは、予約インスタンスのサイズと使用されているストレージ スペースの差です。
- ユーザー データベースとシステム データベースのデータ ファイルおよびログ ファイルのサイズはどちらも、最大ストレージ サイズの制限と比較されるインスタンス ストレージ サイズに含まれます。 データベースによって使用される合計領域を確認するには、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 プールでのリソース制限に関する説明を参照してください。
IOPS
Next-gen General Purpose および Business Critical サービス レベルの場合、使用可能な IOPS は仮想コアの数によって決まります。
- Next-gen General Purpose サービス レベル: 仮想コアの数に基づく IOPS の固定値。 ストレージの価格には、最小 IOPS が含まれます。 最小値を超えた場合は、次のように課金されます。1 IOPS = ストレージ価格 (リージョン別) ÷ 3。 たとえば、ストレージの 1 GB のコストが 0.115 の場合、1 IOPS = 0.115/3 = 1 IOPS あたり 0.038 になります。
- Business Critical サービス レベル: 数式 (4000 IOPS/仮想コア) を使用して IOPS の上限が決定されます。
次の表に、仮想コアの数に基づいて、各サービス レベルで使用できる最大 IOPS を示します。
仮想コアの数 | Next-gen General Purpose | Business Critical |
---|---|---|
4 | 6,400 | 16,000 |
6 | 9,600 | 24,000 |
8 | 12,800 | 32,000 |
10 | 16,000 | 40,000 |
12 | 19,200 | 48,000 |
16 | 25,600 | 64,000 |
20 | 32,000 | 80,000 |
24 | 38,400 | 96,000 |
32 | 51,200 | 128,000 |
40 | 64,000 | 160,000 |
48 | 76,800 | 192,000 |
56 | 80,000 | 224,000 |
64 | 80,000 | 256,000 |
80 | 80,000 | 320,000 |
96 | 80,000 | 320,000 |
128 | 80,000 | 320,000 |
General Purpose サービス レベルでのファイル IO 特性
General Purpose サービス レベルでは、すべてのデータベース ファイルで、ファイルのサイズに依存する専用の IOPS とスループットが取得されます。 ファイルが大きいほど、IOPS とスループットも大きくなります。 次の表に、データベース ファイルの IO 特性を示します。
ファイル サイズ | >=0 および <=129 GiB | >129 および <=513 GiB | >513 および <=1025 GiB | >1025 および <=2049 GiB | >2049 および <=4097 GiB | >4097 GiB および <=8 TiB |
---|---|---|---|---|---|---|
ファイルあたりの IOPS | 500 | 2300 | 5000 | 7500 | 7500 | 7500 |
ファイルあたりのスループット | 100 MiB/秒 | 150 MiB/秒 | 200 MiB/秒 | 250 MiB/秒 | 250 MiB/秒 | 250 MiB/秒 |
何らかのデータベース ファイルに対する IO 待機時間が長いことに気付いた場合、または IOPS/スループットが上限に達している場合は、ファイルのサイズを大きくすることで、パフォーマンスを改善できる場合があります。
最大ログ書き込み処理能力に対するインスタンス レベルの制限もあるため (22 MiB/秒などの値については上記の表を参照)、インスタンスの処理能力制限に達したことが原因で、ログ ファイルに対する最大ファイル処理能力に達することができない場合があります。
データとログのストレージ
次の要因は、データ ファイルとログ ファイルに使用されるストレージの量に影響し、General Purpose レベルと Business Critical レベルに適用されます。
- General Purpose サービス レベルでは、
tempdb
によってローカル SSD が使用され、このストレージ コストは、仮想コアの価格に含まれます。 - Business Critical サービス レベルでは、
tempdb
によって、データ ファイルやログ ファイルとローカル SSD が共有され、tempdb
のストレージ コストは、仮想コアの価格に含まれます。 - SQL Managed Instance での最大ストレージ サイズは、32 GB の倍数で指定する必要があります。
重要
両方のサービス レベルで、マネージド インスタンス用に構成された最大ストレージ サイズに対して課金されます。
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 バックアップに使われるストレージの量が決まります。 詳細については、「Long-term backup retention」(長期バックアップ リテンション) をご覧ください。
サポートされているリージョン
SQL Managed Instance は、サポートされているリージョンでのみ作成できます。 現在サポートされていないリージョンで SQL Managed Instance を作成するには、Azure portal でサポート リクエストを送信できます。
サポートされているサブスクリプションの種類
SQL Managed Instance では、現在、次の種類のサブスクリプションでのデプロイだけがサポートされています。
- Enterprise Agreement (EA)
- 従量課金制
- クラウド サービス プロバイダー (CSP)
- Enterprise Dev/Test
- 開発テスト用の従量課金制プラン
- Visual Studio サブスクライバー向けの毎月の Azure クレジット付きサブスクリプション
- 無料試用版
- Azure For Students
- Azure イン オープン プラン
リージョンのリソース制限
Note
サブスクリプションの利用可能なリージョンに関する最新情報については、まず、リージョンの選択に関するページを確認してください。
サポートされているサブスクリプションの種類には、リージョンごとのリソース数の制限を組み入れることができます。 SQL Managed Instance には、サブスクリプションの種類に応じて、(特別なサポート リクエストを Azure portal で作成することによって、オンデマンドで増加する可能性がある) Azure リージョンごとに 2 つの既定の制限があります。
- サブネットの制限: SQL Managed Instance のインスタンスが単一リージョンにデプロイされているサブネットの最大数。
- 仮想コア ユニットの制限: 単一リージョン内のすべてのインスタンスを超えてデプロイできる仮想コア ユニットの最大数。 1 つの GP 仮想コアでは仮想コア ユニットを 1 つ使用し、1 つの BC 仮想コアでは仮想コア ユニットを 4 つ使用します。 インスタンスの総数は、仮想コア ユニットの制限内である限り、制限されません。
Note
これらの制限は既定の設定であり、技術的な制限ではありません。 現在のリージョンでさらに多くのインスタンスが必要な場合、Azure portal でサポート リクエストを特別に作成して、これらの制限をオンデマンドで引き上げることができます。 サポート リクエストを送信せずに、代わりに、別の Azure リージョンに SQL Managed Instance の新しいインスタンスを作成することも可能です。
次の表は、サポートされている種類のサブスクリプションを対象に、既定のリージョン別制限についてまとめたものです (既定の制限は、サポート リクエストを利用して拡張できます)。
サブスクリプションの種類 | SQL Managed Instance サブネットの既定の制限 | 仮想コア ユニットの既定の制限* |
---|---|---|
CSP | 16 (リージョンによっては 30**) | 960 (リージョンによっては 1440**) |
EA | 16 (リージョンによっては 30**) | 960 (リージョンによっては 1440**) |
Enterprise Dev/Test | 6 | 320 |
従量課金制 | 6 | 320 |
開発テスト用の従量課金制プラン | 6 | 320 |
Azure Pass | 3 | 64 |
BizSpark | 3 | 64 |
BizSpark Plus | 3 | 64 |
Microsoft Azure スポンサー プラン | 3 | 64 |
Microsoft Partner Network | 3 | 64 |
Visual Studio Enterprise (MPN) | 3 | 64 |
Visual Studio Enterprise | 3 | 32 |
Visual Studio Enterprise (BizSpark) | 3 | 32 |
Visual Studio Professional | 3 | 32 |
MSDN Platforms | 3 | 32 |
* デプロイの計画では、Business Critical (BC) サービス レベルの場合、仮想コアの容量が General Purpose (GP) サービス レベルより 4 倍多い必要があることを考慮してください。 次に例を示します。1 つの GP 仮想コア = 1 つの仮想コア ユニット、1 つの BC 仮想コア = 4 つの仮想コアとなります。 既定の制限に対する消費量分析を簡素化するために、SQL Managed Instance がデプロイされているリージョン内のすべてのサブネットの仮想コア ユニットを集計して、その結果をサブスクリプションの種類のインスタンス ユニットの制限と比較します。 「最大仮想コア ユニット数」の制限は、リージョン内の各サブスクリプションに適用されます。 複数のサブネットにわたりデプロイされたすべての仮想コアの総数は最大仮想コア ユニット数以下でなければならないことを除き、個々のサブネットあたりの制限はありません。
** 次のリージョンには、より大きなサブネットと仮想コアの制限があります。オーストラリア東部、米国東部、米国東部 2、北ヨーロッパ、米国中南部、東南アジア、英国南部、西ヨーロッパ、米国西部 2。
重要
仮想コアとサブネットの制限が 0 になっている場合、サブスクリプションの種類に対して既定のリージョン制限が設定されていないことを意味します。 また、必要な仮想コアとサブネットの値を指定する際と同じ手順に従って、特定のリージョンでサブスクリプションのアクセスを取得するためにクォータの引き上げ要求を使用することもできます。
クォータの増加を要求する
現在のリージョンでより多くのインスタンスが必要な場合、Azure portal を使用してクォータを拡張するためのサポート リクエストを送信します。 詳細については、「Azure SQL Database のクォータの増加を要求する」を参照してください。
次のステップ
- SQL Managed Instance の詳細については、「SQL Managed Instance とは何か」を参照してください。
- 料金情報については、SQL Managed Instance の価格に関するページを参照してください。
- 最初の SQL Managed Instance を作成する方法については、クイックスタート ガイドを参照してください。
- Azure SQL Managed Instance 用 SLA