次の方法で共有


Azure SQL Managed Instance のリソース制限の概要

適用対象:Azure SQL Managed Instance

この記事では、Azure SQL Managed Instance の技術特性とリソース制限の概要を示し、これらの制限の引き上げを要求する方法について説明します。

Note

サポートされている機能と T-SQL ステートメントの違いについては、機能の違いT-SQL ステートメントのサポートに関するページをご覧ください。 Azure SQL Database と SQL Managed Instance の間の一般的な違いについては、General PurposeBusiness 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
汎用: 最大 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、インド中部、東アジア、東日本、東南アジア

使用可能なインメモリ 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 待機時間 (約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 要求期間の大部分は範囲の最上位に当たりますが、範囲を超える外れ値が可能です。

その他の考慮事項

  • 現在利用可能なインスタンスのストレージ サイズは、予約インスタンスのサイズと使用されているストレージ スペースの差です。

  • ユーザー データベースとシステム データベースのデータ ファイルおよびログ ファイルのサイズはどちらも、最大ストレージ サイズの制限と比較されるインスタンス ストレージ サイズに含まれます。 データベースによって使用される合計領域を確認するには、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 バックアップに使われるストレージの量が決まります。 詳細については、「長期的なリテンション期間 - Azure SQL Database と Azure SQL Managed Instance」を参照してください。

サポートされているリージョン

SQL Managed Instance は、サポートされているリージョンでのみ作成できます。 現在サポートされていないリージョンで SQL Managed Instance を作成するには、Azure portal でサポート リクエストを送信できます。

サポートされているサブスクリプションの種類

SQL Managed Instance では、現在、次の種類のサブスクリプションでのデプロイだけがサポートされています。

リージョンのリソース制限

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 サブネットの既定の制限 仮想コア ユニットの既定の制限 1
CSP 16 (一部の地域では 302) 960 (一部の地域では 14402)
EA 16 (一部の地域では 302) 960 (一部の地域では 14402)
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

1 デプロイを計画する際に、Business Critical (BC) サービス レベルには General Purpose (GP) サービス レベルの 4 倍の仮想コア容量が必要であることを考慮してください。 次に例を示します。1 つの GP 仮想コア = 1 つの仮想コア ユニット、1 つの BC 仮想コア = 4 つの仮想コアとなります。 既定の制限に対する消費量分析を簡素化するために、SQL Managed Instance がデプロイされているリージョン内のすべてのサブネットの仮想コア ユニットを集計して、その結果をサブスクリプションの種類のインスタンス ユニットの制限と比較します。 「最大仮想コア ユニット数」の制限は、リージョン内の各サブスクリプションに適用されます。 複数のサブネットにわたりデプロイされたすべての仮想コアの総数は最大仮想コア ユニット数以下でなければならないことを除き、個々のサブネットあたりの制限はありません。

2 大規模なサブネットと仮想コアの制限は、オーストラリア東部、米国東部、米国東部 2、北ヨーロッパ、米国中南部、東南アジア、英国南部、西ヨーロッパ、米国西部 2 のリージョンで利用できます。

重要

仮想コアとサブネットの制限が 0 の場合は、サブスクリプションの種類の既定のリージョン制限が設定されていないことを意味します。 また、必要な仮想コアとサブネットの値を指定する際と同じ手順に従って、特定のリージョンでサブスクリプションのアクセスを取得するためにクォータの引き上げ要求を使用することもできます。

クォータの増加を要求する

現在のリージョンでより多くのインスタンスが必要な場合、Azure portal を使用してクォータを拡張するためのサポート リクエストを送信します。 詳細については、「Azure SQL Database と SQL Managed Instanceのクォータの引き上げを要求する」を参照してください。