適用対象:
Azure SQL Managed Instance
この記事では、Azure SQL Managed Instance の技術特性とリソース制限の概要を示し、これらの制限の引き上げを要求する方法について説明します。
注
サポートされている機能と 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 |
汎用: 最大 32 TB4 Business Critical: 最大 4 TB |
汎用: 最大 32 TB4 Business Critical: 最大 16 TB3 |
汎用: 最大 32 TB4 Business Critical: 最大 16 TB |
1 2 仮想コア インスタンスのデプロイは、インスタンス プール内でのみ可能です。
2仮想コアの数によって異なります。
3次のリージョン では 16 TB のストレージを提供できますが、他のリージョンでは使用可能なストレージが 5.5 TB に制限されています。
従来の汎用では 4 16 TB。
次世代 General Purpose サービス レベルの場合のみ 32 TB (プレビュー)
注
ワークロードで必要なストレージ サイズが Azure SQL Managed Instance で使用できるリソース制限を超える場合は、Azure SQL Database の Hyperscale サービス レベルを検討してください。
メモリ最適化のプレミアム シリーズ ハードウェアおよび 16 TB ストレージのプレミアム シリーズ ハードウェアのリージョン サポート
16 TB ストレージのプレミアム シリーズ ハードウェアのサポートには、メモリ最適化のプレミアム シリーズ ハードウェアのサポートと同じ可用性があります。 詳細については、「 メモリ最適化プレミアム シリーズ ハードウェアと 16 TB ストレージを備えたプレミアム シリーズ ハードウェアのリージョン別サポート」を参照してください。
使用可能なインメモリ OLTP 領域
Business Critical サービス レベルのインメモリ OLTP 領域の容量は、仮想コアの数とハードウェアの構成によって異なります。 次の表では、インメモリ 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 つのサービス レベルがあります。 アップグレードされた Next-gen General Purpose サービス レベル (プレビュー) の使用を選択できます。
重要
Business Critical サービス レベルには、読み取り専用ワークロードに使用できる SQL Managed Instance の追加の組み込みコピー (セカンダリ レプリカ) が用意されています。 読み取り/書き込みクエリと読み取り専用/分析/レポート クエリを分離できる場合、同じ価格で仮想コアとメモリの 2 倍が得られます。 セカンダリ レプリカはプライマリ インスタンスから数秒遅れる可能性があるため、データの正確な現在の状態を必要としないレポート/分析ワークロードをオフロードするように設計されています。 次の表で、読み取り専用クエリは、セカンダリ レプリカ上で実行されるクエリです。
仮想コアの数
| ハードウェアの生成 | 汎用 | 次世代の汎用 | ビジネスに不可欠 |
|---|---|---|---|
| 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 仮想コア インスタンスのデプロイは、インスタンス プール内でのみ可能です。
最大メモリ
| ハードウェアの生成 | 汎用 | 次世代の汎用 | ビジネスに不可欠 |
|---|---|---|---|
| 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 に制限されます。
インスタンスの最大ストレージ サイズ (予約済み)
| ハードウェアの生成 | 汎用 | 次世代の汎用 | ビジネスに不可欠 |
|---|---|---|---|
| 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 仮想コア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 に制限されます。
機能の比較
| 特徴 | 汎用 | 次世代の汎用 | ビジネスに不可欠 |
|---|---|---|---|
| 最大データベース サイズ | 現在利用可能なインスタンスのサイズまで (仮想コア数に応じて)。 | 現在利用可能なインスタンスのサイズまで (仮想コア数に応じて)。 | 現在利用可能なインスタンスのサイズまで (仮想コア数に応じて)。 |
最大 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/秒 Standard シリーズの場合: 最大 96 MiB/秒 Premium シリーズおよびメモリ最適化 Premium シリーズの場合: 最大 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 を示します。
| 仮想コアの数 | 次世代の汎用 | ビジネスに不可欠 |
|---|---|---|
| 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 |
| 二十四 | 三万八千四百 | 96,000 |
| 32 | 5万1,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 | 5,000 | 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」を参照してください。
柔軟なメモリ (プレビュー)
注
フレキシブル メモリ機能は現在 プレビュー段階です。
既定では、Azure SQL Managed Instance に割り当てられるメモリの量は、選択した仮想コア数によって決まる静的な値です。 次世代 General Purpose サービス レベルの柔軟なメモリ機能を使用すると、仮想コアの数を変更することなく、マネージド インスタンスに割り当てられたメモリの量を変更できます。 この機能は、特定の数の仮想コアに対する既定の割り当てよりも多くのメモリを必要とするワークロードに役立ちます。
現在、フレキシブル メモリ機能は、Premium シリーズ ハードウェア上の次世代 General Purpose サービス レベルのローカル冗長インスタンスでのみ使用できます。
Azure portal または REST API を使用して、新しいインスタンスと既存のインスタンスに対してマネージド インスタンスに割り当てられるメモリの量をいつでも変更できます。 メモリ割り当ての変更は、インスタンス内のすべてのデータベースに適用され、最後の操作手順としてインスタンスのフェールオーバーを実行します。 管理操作の期間を確認して、操作が完了するまでの推定時間を決定します。
Azure portal の [コンピューティングとストレージ] ブレードを使用して、メモリ割り当てを変更するか、properties.memorySizeInGB REST API 呼び出しの値を 2024-08-01-preview バージョンから変更します。 メモリ割り当てはギガバイト (GB) 単位で指定されます。
メモリを割り当てるときは、最小値と最大値の間で選択し、仮想コアに対するメモリの比率を決定することもできます。 最小値と最大値は、インスタンスに対して選択された仮想コアの数によって決まります。 メモリと仮想コアの比率は、インスタンスに割り当てられたメモリの合計に対する割合です。
次の表は、フレキシブル メモリ機能の最小メモリ値と最大メモリ値を示しています。
| 仮想コア | 最小 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。
たとえば、従量課金制の 4 仮想コア インスタンスのメモリが 40 GB の場合、次の料金が発生します。
- 4 仮想コア
- 4 仮想コアの SQL ライセンス
- 12 GB の課金対象メモリ (40 GB - (4*7) = 12 GB)。
サポートされているリージョン
SQL Managed Instance は、サポートされているリージョンでのみ作成できます。 現在サポートされていないリージョンで SQL Managed Instance を作成するには、Azure portal でサポート リクエストを送信できます。
サポートされているサブスクリプションの種類
SQL Managed Instance では、現在、次の種類のサブスクリプションでのデプロイだけがサポートされています。
- Enterprise Agreement (EA)
- 従量課金制
- クラウド サービス プロバイダー (CSP)
- エンタープライズ開発/テスト
- 開発テスト用の従量課金制プラン
- Visual Studio サブスクライバー向けの毎月の Azure クレジット付きサブスクリプション
- 無料試用版
- 学生向けの Azure
- Azure イン オープン プラン
リージョンのリソース制限
注
サブスクリプションの利用可能なリージョンに関する最新情報については、まず、リージョンの選択に関するページを確認してください。
サポートされているサブスクリプションの種類には、リージョンごとのリソース数の制限を組み入れることができます。 SQL Managed Instance には、サブスクリプションの種類に応じて、(特別なサポート リクエストを Azure portal で作成することによって、オンデマンドで増加する可能性がある) Azure リージョンごとに 2 つの既定の制限があります。
- サブネットの制限: SQL Managed Instance のインスタンスが単一リージョンにデプロイされているサブネットの最大数。
- 仮想コア ユニットの制限: 単一リージョン内のすべてのインスタンスを超えてデプロイできる仮想コア ユニットの最大数。 1 つの GP 仮想コアでは仮想コア ユニットを 1 つ使用し、1 つの BC 仮想コアでは仮想コア ユニットを 4 つ使用します。 インスタンスの合計数は、仮想コアユニットの制限内にある限り制限されません。
注
これらの制限は既定の設定であり、技術的な制限ではありません。 現在のリージョンでさらに多くのインスタンスが必要な場合、Azure portal でサポート リクエストを特別に作成して、これらの制限をオンデマンドで引き上げることができます。 サポート リクエストを送信せずに、代わりに、別の Azure リージョンに SQL Managed Instance の新しいインスタンスを作成することも可能です。
次の表は、サポートされている種類のサブスクリプションを対象に、既定のリージョン別制限についてまとめたものです (既定の制限は、サポート リクエストを利用して拡張できます)。
| サブスクリプションの種類 | SQL Managed Instance サブネットの既定の制限 | 仮想コア ユニットの既定の制限 1 |
|---|---|---|
| コンテンツ セキュリティ ポリシー (CSP) | 16 (一部の地域では 302) | 960 (一部の地域では 14402) |
| EAの | 16 (一部の地域では 302) | 960 (一部の地域では 14402) |
| エンタープライズ開発/テスト | 6 | 320 |
| 従量課金制 | 6 | 320 |
| 開発テスト用の従量課金制プラン | 6 | 320 |
| Azure Pass | 3 | 64 |
| ビズパーク | 3 | 64 |
| ビズパークプラス | 3 | 64 |
| Microsoft Azure スポンサー プラン | 3 | 64 |
| マイクロソフト パートナー ネットワーク | 3 | 64 |
| Visual Studio エンタープライズ (MPN) | 3 | 64 |
| Visual Studio Enterprise | 3 | 32 |
| Visual Studio Enterprise (BizSpark) | 3 | 32 |
| Visual Studio Professional | 3 | 32 |
| MSDN プラットフォーム | 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のクォータの引き上げを要求する」を参照してください。
関連コンテンツ
- Azure SQL Managed Instance とは
- SQL Managed Instance の価格 を
する - クイック スタート ガイドの を
する - Azure SQL Managed Instance 用 SLA