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 は、複数のハードウェア構成に展開できます。

Note

Gen5 ハードウェアの名前は Standard シリーズ (Gen5) に変更されています。

ハードウェア構成には、次の表に示したさまざまな特性があります。

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: 最大 5.5 TB
General Purpose: 最大 16 TB
Business Critical: 最大 16 TB

1 2 仮想コア インスタンスのデプロイは、インスタンス プール内でのみ可能です。
2仮想コアの数によって異なります。

Note

ワークロードで必要なストレージ サイズが Azure SQL Managed Instance で使用できるリソース制限を超える場合は、Azure SQL Database の Hyperscale サービス レベルを検討してください。

メモリ最適化 Premium シリーズ ハードウェアと 16 TB ストレージのリージョンごとのサポート

16 TB (テラバイト) ストレージのサポートは、メモリ最適化 Premium シリーズ ハードウェアのサポートと同じ可用性を備えています。 メモリ最適化 Premium シリーズ ハードウェアと 16 TB ストレージのサポートは、現在、次の特定のリージョンでのみ利用できます。

地理的な場所 メモリ最適化 Premium シリーズ HW と 16 TB ストレージをサポートするリージョン
ヨーロッパ フランス中部、ドイツ中西部、イタリア北部、北ヨーロッパ、ポーランド中部、スウェーデン中部、スイス北部、英国南部、西ヨーロッパ
中東、アフリカ カタール中部
アメリカ ブラジル南部、カナダ中部、米国中部、米国東部、米国東部 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 には 2 つのサービス レベルがあります。General PurposeBusiness Critical です。

重要

Business Critical サービス レベルには、読み取り専用ワークロードに使用できる SQL Managed Instance の追加の組み込みコピー (セカンダリ レプリカ) が用意されています。 読み取りおよび書き込みクエリと、読み取り専用、分析、レポート クエリとを分離できる場合は、同じ価格で仮想コアとメモリを 2 度取得することになります。 セカンダリ レプリカは、プライマリ インスタンスよりも数秒遅れる場合があるため、データの正確な現在の状態を必要としないレポートと分析のワークロードをオフロードするように設計されています。 次の表で、読み取り専用クエリは、セカンダリ レプリカ上で実行されるクエリです。

機能 汎用 Business Critical
vCores* の数 21、4、8、16、24、32、40、64、80 スタンダード シリーズ (Gen5) : 4、8、16、24、32、40、64、80
プレミアム シリーズ: 4、6、8、10、12、16、20、24、32、40、48、56、64、80、962、1282
メモリ最適化プレミアム シリーズ: 4、6、8、10、12、16、20、24、32、40、48、56、64、802、962、12822
*同じ数の仮想コアが読み取り専用クエリに割り当てられます。
最大メモリ Standard シリーズ (Gen5) : 20.4 GB - 408 GB (5.1 GB/仮想コア)
Premium シリーズ: 28 GB - 560 GB (7 GB/仮想コア)
メモリ最適化 Premium シリーズ: 54.4 GB - 870.4 GB (13.6 GB/仮想コア)
スタンダード シリーズ (Gen5): レプリカごとに 20.4 GB - 408 GB (5.1 GB/仮想コア)
プレミアム シリーズ: レプリカごとに 28 GB - 560 GB (7 GB/仮想コア、最大80 個の仮想コア2)
メモリ最適化プレミアム シリーズ: レプリカごとに 54.4 GB - 870.4 GB (13.6 GB/仮想コア、最大 64 個の仮想コア2)
インスタンスの最大ストレージ サイズ (予約済み) - 4 仮想コアの場合は 2 TB
- 8個の仮想コアの場合は 8 TB
- その他のサイズの場合は 16 TB
スタンダード シリーズ (Gen5) :
- 4、8、16 仮想コアの場合は 1 TB
- 24 個の仮想コアの場合は 2 TB
- 32、40、64、80 個の仮想コアの場合は 4 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 仮想コアの場合は、5.5 TB または 16 TB (リージョンに応じて) 3
メモリ最適化プレミアム シリーズ:
- 4、6 仮想コアの場合は 1 TB
- 8、10、12 仮想コアの場合は 2 TB
- 16、20 仮想コアの場合は 4 TB
- 24 仮想コアの場合は 5.5 TB
- 32、40 仮想コアの場合は 5.5 TB または 8 TB (リージョンに応じて)4
- 48、56 仮想コアの場合は 12 TB
- 64、80、96、128 仮想コアの場合は 16 TB
最大データベース サイズ 現在利用可能なインスタンスのサイズまで (仮想コア数に応じて)。 現在利用可能なインスタンスのサイズまで (仮想コア数に応じて)。
最大 tempdb データベース サイズ 24 GB/仮想コア (96 から 1,920 GB) と現在利用可能なインスタンスのストレージ サイズに制限されています。
tempdb 領域を増やすには、仮想コアを追加します。
ログ ファイルは 120 GB に制限されています。
現在利用可能なインスタンスのストレージ サイズまで。
tempdb ファイルの最大数 128 128
インスタンスごとの最大データベース数 インスタンスのストレージ サイズの上限に達していない限り、データベースごとに 100 ユーザー。 インスタンスのストレージ サイズの上限に達していない限り、データベースごとに 100 ユーザー。
データベース ファイルの最大数 インスタンスのストレージ サイズまたは Azure Premium ディスクの記憶域割り当ての領域の上限に達していない限り、インスタンスごとの 280 個。 インスタンスのストレージ サイズの上限に達していない限り、データベースごとに 32,767 ファイル。
データ ファイルの最大サイズ 各データ ファイルの最大サイズは 8 TB です。 8 TB を超えるデータベースの場合、少なくとも 2 つのデータ ファイルを使用します。 現在利用可能なインスタンスのサイズまで (仮想コア数に応じて)。
最大ログ ファイル サイズ 2 TB と現在利用可能なインスタンスのストレージ サイズに制限されています。 2 TB と現在利用可能なインスタンスのストレージ サイズに制限されています。
データ/ログの IOPS (概算) ファイルあたり 500 ~ 7,500
*IOPS を増やすには、ファイル サイズを大きくします
16 K - 320 K (4000 IOPS/仮想コア)
IO パフォーマンスを向上させるには、仮想コアを追加します。
ログ書き込みのスループット制限 (インスタンスあたり) 仮想コアあたり 4.5 MiB/秒
インスタンスあたり最大 120 MiB/秒
DB あたり 22 - 65 MiB/秒 (ログ ファイルのサイズに応じて)
*IO パフォーマンスを向上させるには、ファイル サイズを増やします
仮想コアあたり 4.5 MiB/秒
最大 192 MiB/秒
データ スループット (概算) ファイルあたり 100 - 250 MiB/秒
*IO パフォーマンスを向上させるには、ファイル サイズを増やします
制限なし。
ストレージ IO 待機時間 (概算) 5 ~ 10 ms 1 ~ 2 ms
インメモリ OLTP サポートされていません 利用可能、サイズは仮想コアの数に依存
最大セッション数 30000 30000
最大同時 worker 数 105 * 仮想コアの数 + 800 105 * 仮想コアの数 + 800
読み取り専用レプリカ 0 1 (価格に含まれます)
コンピューティングの分離 汎用インスタンスによって、他のインスタンスと物理ハードウェアが共有される可能性があるため、サポートされていません スタンダード シリーズ (Gen5) :
64 以上の仮想コアを持つ構成でサポートされます
プレミアム シリーズ: 64 以上の仮想コアを持つ構成でサポートされます
メモリ最適化 プレミアム シリーズ: 64 以上の仮想コアを持つ構成でサポートされます

1 2 仮想コア インスタンスのデプロイは、インスタンス プール内でのみ可能です。
2 メモリと仮想コアの比率は、プレミアム シリーズ ハードウェアでは最大 80 個の仮想コア、メモリ最適化プレミアム シリーズでは最大 64 個の仮想コアのみに使用できます。 最大メモリは、80 個を超えるプレミアム シリーズ仮想コアの場合は 560 GB、64 個を超えるメモリ最適化プレミアム シリーズ仮想コアの場合は 870.4 GB に制限されます。
3 これらの CPU 仮想コア数に対して Premium シリーズ ハードウェアに 16 TB のストレージを提供できるのは、主要リージョンのみです。小さいリージョンでは、5.5 TB で使用可能なストレージが制限されます。
4 これらの CPU 仮想コア数に対して Premium シリーズのメモリ最適化ハードウェアに 8 TB のストレージを提供できるのは、主要リージョンのみです。小さいリージョンでは、5.5 TB で使用可能なストレージが制限されます。

追加の考慮事項:

  • 現在利用可能なインスタンスのストレージ サイズは、予約インスタンスのサイズと使用されているストレージ スペースの差です。
  • ユーザー データベースとシステム データベースのデータ ファイルおよびログ ファイルのサイズはどちらも、最大ストレージ サイズの制限と比較されるインスタンス ストレージ サイズに含まれます。 データベースによって使用される合計領域を確認するには、sys.master_files システム ビューを使用します。 エラー ログは保持されず、サイズには含まれません。 バックアップは、ストレージ サイズに含まれません。
  • General Purpose レベルではスループットと IOPS も、SQL Managed Instance によって明示的に制限されないファイル サイズに依存します。 フェールオーバー グループを利用すれば、異なる Azure リージョンで別の読み取り可能レプリカを作成できます
  • 最大インスタンス IOPS は、ワークロードにおけるファイルのレイアウトおよび分散に依存します。 たとえば、それぞれ最大 5 K IOPS を持つ 1-TB ファイルを 7 個と、それぞれ 500 IOPS を持つ小さいファイル (128 GB 未満) を 7 個作成したとすると、ワークロードですべてのファイルを使用できる場合、インスタンスあたり 38500 IOPS (7 x 5000 + 7 x 500) を取得できます。 一部の IOPS は、自動バックアップにも使用されることに注意してください。
  • tempdb ファイルの名前は、16 文字以内にする必要があります。

詳細については、こちらの記事の SQL Managed Instance プールでのリソース制限に関する説明を参照してください。

データとログのストレージ

次の要因は、データ ファイルとログ ファイルに使用されるストレージの量に影響し、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」(長期バックアップ リテンション) をご覧ください。

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/秒などの値については上記の表を参照)、インスタンスのスループット制限に達したため、ログ ファイルに対する最大ファイル スループットに達することができない場合があります。

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

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 サブネットの既定の制限 仮想コア ユニットの既定の制限*
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 のクォータの増加を要求する」を参照してください。

次のステップ