ハイパースケール サービス レベル

適用対象:Azure SQL データベース

Azure SQL Database Hyperscale は、コスト効率に優れた、高パフォーマンスのクラウド データベースです。

Azure SQL Databaseは SQL データベース エンジンに基づいています。 ハイパースケールは、他のAzure SQL Databaseサービス レベルとは異なります。

  • 他のサービス レベルとは異なり、Hyperscale には SQL ソフトウェア ライセンス料金がないため、高パフォーマンス データベースの他の Azure SQL Database サービス レベルよりも大きな価格上の利点があります。
  • ハイパースケール アーキテクチャ は、ほぼ瞬時のバックアップ、高速復元、読み取りと書き込みの高スループットを提供します。
  • Hyperscale では、データ移動なしでオンデマンドで高速なコンピューティング スケーリングが提供されます。
  • 読み取りスケールアウト戦略は簡単で、独立した構成可能なコンピューティングを備えた最大 30 個の名前付きレプリカに加えて、組み込みの高可用性レプリカと構成可能な geo レプリカが世界中に存在します。

Hyperscale サービス レベルは、すべてのワークロードの種類に適しています。 Hyperscale のコンピューティング リソースとストレージ リソースは、Azure SQL Database General Purpose レベルと Business Critical レベルで使用可能なリソースを大幅に超えています。

Azure SQL Database内の既存のデータベースを Hyperscale に簡単に変換することも、任意のSQL Server データベースから Hyperscale に移行することもできます。 他のデータベースをAzure SQL Databaseに移行するには、「Azure データベース移行ガイド」を参照してください。

Hyperscale サービス レベルは現在、Azure SQL Databaseでのみ使用でき、Azure SQL Managed Instanceでは使用できません。

ハイパースケールの機能とは

Azure SQL Databaseの Hyperscale サービス レベルには、次の追加機能があります。

  • 迅速なスケールアップ - コンピューティング リソースをスケールアップして、必要に応じて負荷の高いワークロードに対応し、不要なときにコンピューティング リソースをスケールダウンします。
  • 迅速なスケールアウト - 読み取り ワークロードをオフロードし、ホット スタンバイとして使用するために、1 つ以上の読み取り専用レプリカをプロビジョニングします。
  • サーバーレス コンピューティングでの使用量に基づくコンピューティングの自動スケールアップ、スケールダウンおよび課金。
  • Elastic Pool を使用したさまざまなリソース要求がある Hyperscale データベース グループの価格/パフォーマンスの最適化。
  • 最大 128 TB のデータベースまたは 100 TB のエラスティック プール サイズをサポートするストレージの自動スケーリング。
  • データ ボリュームに関係なく、高いトランザクション ログ スループットと速いトランザクション コミット時間による、全体的に高いパフォーマンス。
  • コンピューティング リソースに I/O の影響を与えない、(ファイル スナップショットに基づく) 高速データベース バックアップ。
  • 数時間または数日間ではなく、数分間で迅速なデータベース復元またはコピー（ファイルスナップショットに基づく）。

Hyperscale サービス レベルでは、クラウド データベースにおいて従来見られた実質的な制限の多くが取り除かれます。 他のほとんどのデータベースは 1 つのノードで使用可能なリソースによって制限されますが、Hyperscale サービス レベルのデータベースにはそのような制限はありません。 ストレージ アーキテクチャの柔軟性が高く、必要に応じてストレージが拡張されます。 実際、Hyperscale データベースの作成時には最大サイズは定義されません。 Hyperscale データベースは必要に応じて拡大し、割り当てられたストレージ容量に対してのみ課金されます。 読み取り集中型ワークロードでは、Hyperscale サービス レベルにより、読み取りワークロードのオフロード用に必要に応じて追加のレプリカがプロビジョニングされ、迅速なスケールアウトが提供されます。

さらに、データベース バックアップの作成に必要な時間や、スケールアップまたはスケールダウンに必要な時間は、データベース内のデータの量に関連しなくなっています。 Hyperscale データベースはほぼ瞬時にバックアップされます。 プロビジョニングされたコンピューティング レベルで数十テラバイトのデータベースを数分以内にスケールアップまたはスケールダウンしたり、サーバーレスを使ってコンピューティングを自動的にスケーリングしたりすることもできます。 この機能により、初期構成の選択によって縛り付けられることを心配する必要はなくなります。

ハイパースケール サービス レベルのコンピューティング サイズについて詳しくは、「サービス レベルの特性」をご覧ください。

仮想コアベースの購入モデルでの General Purpose サービス レベルと Business Critical サービス レベルの詳細については、General Purpose サービス レベルと Business Critical サービス レベルの記事を参照してください。 仮想コアベースの購入モデルと DTU ベースの購入モデルの比較については、「Azure SQL Database の Compare 仮想コアおよび DTU ベースの購入モデル」を参照してください。

Hyperscale サービス レベルを検討する必要があるユーザー

Hyperscale サービス レベルは、より高いパフォーマンスと可用性、高速なバックアップと復元、高速なストレージとコンピューティングのスケーラビリティを必要とするすべてのお客様を対象としています。 Hyperscale は、アプリケーションを最新化するためにクラウドに移行しているお客様や、Azure SQL Databaseで既に他のサービス レベルを使用しているお客様に最適です。 Hyperscale サービス レベルでは、純粋な OLTP から純粋な分析まで、幅広いデータベース ワークロードがサポートされています。 OLTP、ハイブリッドトランザクション、分析処理(HTAP)ワークロードに最適化されています。

ハイパースケールの価格モデル

ハイ パフォーマンス データベースの場合、Hyperscale は他の Azure SQL Database サービス レベルよりも大幅な価格上の利点を提供します。 詳細については、「ブログ: Ignite 2023 での Azure SQL Database Hyperscale の価格に関するお知らせ」を参照してください。 価格の変更の詳細については、「ブログ: Azure SQL Database Hyperscale - 低コストで簡略化された価格」を参照してください。

Hyperscale サービス レベルは 、仮想コア モデル でのみ使用でき、2 つのコンピューティング レベルで提供されます。 Hyperscale の課金は、プロビジョニングされたコンピューティング レベルまたはサーバーレス コンピューティング レベルに基づいています。

  • プロビジョニングされた コンピューティング レベル:

    仮想コアのコンピューティング コストには、アプリケーション用に継続的にプロビジョニングされているコンピューティング容量の合計が反映されます。 ハイパースケール コンピューティング ユニットの料金はレプリカ単位です。

  • サーバーレス コンピューティング レベル:

    サーバーレス コンピューティングの課金は使用量に基づきます。 詳細については、「Azure SQL Database の Serverless コンピューティング レベル」を参照してください。

Hyperscale データベースを構成するときに、最大データ サイズを指定しません。 Hyperscale レベルでは、実際の割り当てに基づいてストレージの料金が発生します。 ストレージは 10 GB から 128 TB の間で自動的に割り当てられ、必要に応じて拡張されます。 詳細については、データベース サイズはどの単位で増加しますか?をご覧ください。

スケールとパフォーマンスの利点

Hyperscale は、メイン データベース エンジンを、データの長期的なストレージと持続性を提供するコンポーネントから分離します。 このアーキテクチャを使用すると、データ移動なしでコンピューティング リソースを迅速にスケーリングし、コンピューティングとは無関係にストレージ (最大 128 TB) をスケーリングできます。 アーキテクチャ図など、詳細については、 ハイパースケール アーキテクチャに関するページを参照してください。

  • Hyperscale アーキテクチャでは、追加の読み取り専用コンピューティング ノードを迅速にスピンアップまたはスピンダウンできるため、読み取りスケール機能が大幅に向上し、プライマリ コンピューティング ノードを解放して、より多くの要求を処理することもできます。
  • セカンダリノード向けにコンピュートをプロビジョニングするか、 サーバーレスコンピュートを使うことができます。 どちらの場合も、Hyperscale の共有ストレージ アーキテクチャにより、すばやくスケールアップまたはスケールダウンできます。
    • Hyperscale のセカンダリ高可用性コンピューティング ノード レプリカは、プライマリのコンピューティング レベルに従います。その結果、影響の少ないフェールオーバーが発生します。
  • サーバーレス、プライマリ、またはセカンダリのコンピューティング ノードを使用すると、ワークロードの需要に基づいて自動的にスケーリングされます。

プライマリ Azure SQL Database Hyperscale データベースは読み取りワークロードと書き込みワークロードの両方を処理しますが、アプリケーション戦略の一部として読み取り専用レプリカを簡単に作成できます。

  • 可用性とスケーラビリティの要件に応じて、 高可用性セカンダリ レプリカ の合計数を 0 から 4 に調整できます。
  • 最大 30 個の 名前付きレプリカ を作成して、読み取りスケールアウト ワークロードをサポートできます。
  • geo レプリカを使用することで、Azure のグローバル データセンター全体にわたって、地理的に分散された読み取りスケールアウトを実現できます。

Hyperscale でのデータベースの高可用性

他のすべてのサービス レベルと同様に、Hyperscale は、コンピューティング レプリカの可用性に関係なく、コミットされたトランザクションのデータの持続性を保証します。 プライマリ レプリカが使用できなくなったことによるダウンタイムの期間は、フェールオーバーの種類 (計画的か、計画外か)、ゾーン冗長が構成されているかどうか、少なくとも 1 つの高可用性レプリカが存在することに依存します。 計画フェールオーバー (メンテナンス イベントなど) では、システムはフェールオーバーを開始する前に新しいプライマリ レプリカを作成するか、既存の高可用性レプリカをフェールオーバー ターゲットとして使用します。 計画外のフェールオーバー (つまりプライマリ レプリカでのハードウェア障害) では、システムによって、高可用性レプリカがフェールオーバー ターゲットとして使用されるか (存在する場合)、または使用可能なコンピューティング容量のプールから新しいプライマリ レプリカが作成されます。 後者の場合、新しいプライマリ レプリカの作成に必要な追加の手順により、ダウンタイムの期間が長くなります。

メンテナンス期間を選択して、影響の大きいメンテナンス イベントを予測可能にし、ワークロードの中断を減らすことができます。

ハイパースケール SLA については、Azure SQL Database の SLA を参照してください。

バッファー プールと回復性のあるバッファー プール拡張機能

Azure Database Hyperscale では、コンピューティングとストレージの間に個別の分離があります。 ストレージには、1 つのデータベース内のすべてのデータベース ページが含まれており、データベースの拡大に合わせて複数のマシンに割り当てられます。 ただし、計算ノードでは、最近使用されているもののみがキャッシュされます。 コンピューティングで最近使用されたページは、バッファー プール (BP) と呼ばれる構造のメモリ内に保持されます。 また、ローカル SSD (回復性のあるバッファー プール拡張機能 (RBPEX)) にも格納されるため、コンピューティング プロセスが再起動した場合に備えて、データをより高速に取得できます。

クラウド システムでは、コンピューティングは必要に応じて異なるマシンに移動できます。 コンピューティング レイヤーには複数のレプリカを含めることができます。 1 つのレプリカはプライマリであり、すべての更新プログラムを受信し、他のレプリカはセカンダリ レプリカです。 プライマリが失敗した場合、システムは高可用性セカンダリ レプリカの 1 つをフェールオーバーと呼ばれるプロセスでプライマリに昇格します。 セカンダリ レプリカの BP と RBPEX に、プライマリ ワークロード用に最適化されたキャッシュがない可能性があります。

連続プライミング

継続的プライミングは、すべてのコンピューティング レプリカで最も頻繁にアクセスされる (最もホットな) ページに関する情報を収集するプロセスです。 このプロセスではこの情報が集計され、高可用性セカンダリ レプリカでは、一般的な顧客のワークロードに対応する最もホットなページの一覧が使用されます。 このプロセスにより、BP と RBPEX の両方に最もホットなページが継続的に埋め込まれるので、お客様のワークロードの変化に対応できます。

連続プライミングがなければ、BPとRBPEXは新しい高可用性レプリカに継承されず、ユーザーの作業中にのみ再構築されます。 継続的プライミングは時間を節約し、キャッシュが再び完全にハイドレートされるまでの待ち時間がないため、パフォーマンスの不整合を防ぎます。 継続的プライミングにより、新しい高可用性セカンダリ レプリカは、BP と RBPEX のプライミングをすぐに開始します。 これにより、フェールオーバーが発生した場合の一貫したパフォーマンスの維持に役立ちます。

継続的プライミングは、高可用性セカンダリ レプリカとプライマリの両方向に機能します。高可用性セカンダリ レプリカでは、プライマリ レプリカで使用されているページをキャッシュし、プライマリでは、セカンダリ レプリカのワークロードを含むページをキャッシュします。

現在、継続的プライミングは、Hyperscale プロビジョニングコンピューティング レベルで使用できます。

バックアップと復元

Hyperscale データベースのバックアップと復元操作は、ファイル スナップショットに基づきます。 この方法により、これらの操作はほぼ瞬時に行われます。 Hyperscale アーキテクチャではバックアップと復元にストレージ レイヤーが使用されるため、コンピューティング レプリカの処理負荷とパフォーマンスへの影響が軽減されます。 詳細については、「 ハイパースケール バックアップとストレージの冗長性」を参照してください。

Hyperscale データベースのディザスター リカバリー

Azure SQL Database内の Hyperscale データベースを現在ホストされているリージョン以外のリージョンに復元するには、geo リストアを実行します。 この方法は、ディザスター リカバリー操作、訓練、再配置、またはその他の理由で機能します。 geo リストアは、ストレージの冗長性に geo 冗長ストレージ (RA-GRS) が選択されている場合にのみ使用できます。

詳細については、「 Hyperscale データベースを別のリージョンに復元する」を参照してください。

リソースの制限の比較

仮想コアベースのサービス レベルは、データベースの可用性、ストレージの種類、パフォーマンス、最大ストレージ サイズによって異なります。 次の表では、これらの違いについて説明します。

ㅤ 汎用 ビジネスクリティカル ハイパースケール
最適な用途 予算指向のバランスの取れたコンピューティングとストレージのオプション。 トランザクション レートが高く I/O 待ち時間が低い OLTP アプリケーション。 複数のホットスタンバイレプリカを使用することで、障害に対する高い耐障害性と高速なフェールオーバーを実現します。 OLTP および HTAP のすべての新規および最新化ワークロードに対して推奨される既定のサービス レベル。 拡張性の高いストレージと読み取りスケールの要件を持つワークロードなど、さまざまなワークロードに最適です。 複数の高可用性セカンダリ レプリカの構成を許可することで、障害に対するより高い回復性を提供します。
コンピューティング サイズ 2 - 128 の仮想コア 2 - 128 の仮想コア 2 ~ 192 仮想コア3
ストレージの種類 Premium リモート ストレージ (インスタンスあたり) 超高速ローカル SSD ストレージ (インスタンスあたり) ローカル SSD キャッシュ（コンピューティングレプリカごと）を持つ分離 Storage
ストレージ サイズ 1 GB から 4 TB 1 GB から 4 TB 10 GB から 128 TB
最大 IOPS 仮想コアあたり 320 IOPS (最大 16,000 IOPS) 仮想コアあたり 4,000 IOPS (最大 327,680 IOPS) 仮想コアあたり 5,500 IOPS、最大ローカル SSD IOPS 544,000。
Hyperscale は、複数のレベルのキャッシュが存在する複数レベル アーキテクチャです。 有効な IOPS はワークロードによって異なります。
仮想コアあたりのメモリ 5.1 GB 5.1 GB 5.1 GB または 10.2 GB
Backups ローカル冗長(LRS)、ゾーン冗長(ZRS)、geo 冗長(GRS)ストレージの選択肢
1 ~ 35 日間のリテンション期間 (既定では 7 日間)、最大 10 年間の長期保有期間が利用可能		 ローカル冗長(LRS)、ゾーン冗長(ZRS)、geo 冗長(GRS)ストレージの選択肢
1 ~ 35 日間のリテンション期間 (既定では 7 日間)、最大 10 年間の長期保有期間が利用可能		 ローカル冗長(LRS)、ゾーン冗長(ZRS)、geo 冗長(GRS)ストレージの選択肢
1 ~ 35 日間のリテンション期間 (既定では 7 日間)、最大 10 年間の長期保有期間が利用可能
可用性 レプリカ 1 つ、読み取りスケールアウト レプリカなし。 ゾーン冗長 HA レプリカ 3 つ、読み取りスケールアウト レプリカなし。 ゾーン冗長 HA 複数のレプリカ (最大 4 つの読み取りスケールアウト レプリカ)。 ゾーン冗長 HA
価格設定/請求 仮想コア、予約ストレージ、バックアップ ストレージの が課金されます。
IOPS は課金されません。		 仮想コア、予約ストレージ、バックアップ ストレージの が課金されます。
IOPS は課金されません。		 レプリカごとの仮想コア、割り当てたデータストレージ、バックアップストレージは課金されます。
IOPS は課金されません。
割引モデル Azure Reservations
Azure ハイブリッド特典2
Enterprise サブスクリプションと開発テスト用の従量課金制プラン		 Azure Reservations
Azure ハイブリッド特典2
Enterprise サブスクリプションと開発テスト用の従量課金制プラン		 Hyperscale には SQL ソフトウェア ライセンス料金1 がないため、Azure ハイブリッド特典は新しい Hyperscale データベース2 では使用できません。
インメモリ テーブル いいえ はい いいえ

1 SQL Database Hyperscale の簡略化された価格は、2023 年 12 月に導入されました。 詳細については、Hyperscale の価格に関するブログを参照してください。

2 2023 年 12 月現在、Azure ハイブリッド特典は新しい Hyperscale データベースや開発/テスト サブスクリプションでは使用できません。 プロビジョニングされたコンピューティングを備えた既存の Hyperscale 単一データベースでは、2026 年 12 月まで引き続き Azure ハイブリッド特典 を使用してコンピューティング コストを節約できます。 詳細については、「Hyperscale 価格のブログ」を確認してください。

3 現在、160 と 192 の仮想コア オプションはプレビュー機能です。

コンピューティング リソース

次の表では、Azure SQL Database Hyperscale のさまざまなハードウェア構成とコンピューティング レベルのコンピューティング リソースを比較します。 ハイパースケール以外の Azure SQL Database については、「 仮想コア購入モデル - Azure SQL Database」を参照してください。

ハードウェア構成 CPU メモリ
Standard シリーズ (Gen5) プロビジョン済みのコンピュート
- Intel® E5-2673 v4 (Broadwell) 2.3 GHz、 Intel® SP-8160 (Skylake)*、Intel® 8272CL (Cascade Lake) 2.5 GHz*、Intel® Xeon® Platinum 8370C (Ice Lake)*、AMD EPYC™ 7763v (ミラノ)*、AMD EPYC 9004 (ジェノヴァ)*、Intel® Xeon® Platinum 8573C (エメラルド ラピッズ)* プロセッサ
- 最大 128 個の仮想コアをプロビジョニング (ハイパースレッド)

サーバーレス コンピューティング
- Intel® E5-2673 v4 (Broadwell) 2.3 GHz、 Intel® SP-8160 (Skylake)*、Intel® 8272CL (Cascade Lake) 2.5 GHz*、Intel® Xeon® Platinum 8370C (Ice Lake)*、AMD EPYC™ 7763v (ミラノ)*、AMD EPYC 9004 (ジェノヴァ)*、Intel® Xeon® Platinum 8573C (エメラルド ラピッズ)* プロセッサ
- 最大 80 個の仮想コア（ハイパースレッディング）を自動スケーリング
- メモリと仮想コアの比率は、ワークロードの需要に基づくメモリと CPU の使用率に動的に適合し、仮想コアあたり最大 24 GB まで使用できます。 たとえば、特定の時点でワークロードが使用し、240 GB のメモリと 10 個の仮想コアに対してのみ課金される場合があります。		 プロビジョン済みのコンピュート
- 仮想コアあたり 5.1 GB
- 最大 625 GB をプロビジョニング

サーバーレス コンピューティング
- 仮想コアごとに最大 24 GB を自動スケーリング
- 最大 240 GB を自動スケーリング
Premium シリーズ プロビジョン済みのコンピュート
- Intel® Xeon® Platinum 8370C (Ice Lake)*、AMD EPYC™ 7763v (ミラノ)*、AMD EPYC 9004 (ジェノヴァ)*、Intel® Xeon® Platinum 8573C (エメラルド ラピッズ)* プロセッサ
- 最大 192 個の仮想コア (ハイパースレッド) をプロビジョニングします。		 仮想コアあたり 5.2 GB
メモリ最適化された Premium シリーズ プロビジョン済みのコンピュート
- Intel® Xeon® Platinum 8370C (Ice Lake)*、AMD EPYC™ 7763v (ミラノ)*、AMD EPYC 9004 (ジェノヴァ)*、Intel® Xeon® Platinum 8573C (エメラルド ラピッズ)* プロセッサ
- 最大 80 個の仮想コア (ハイパースレッド) をプロビジョニングします。		 仮想コアあたり 10.2 GB

* 特定のコンピューティング サイズとハードウェア構成の場合、リソースの制限は CPU の種類 (Intel® Broadwell、Skylake、Ice Lake、Cascade Lake、エメラルド ラピッド、AMD ミラノ、ジェノヴァ) に関係なく同じです。 sys.dm_user_db_resource_governance動的管理ビューでは、次を使用してデータベースのハードウェアを生成します。

  • Intel® SP-8160 (Skylake) プロセッサが Gen6 として表示される
  • Intel® 8272CL (Cascade Lake) が Gen7 として表示される
  • Intel® Xeon® Platinum 8370C (Ice Lake) または AMD EPYC™ 7763v (ミラノ) が Gen8 として表示される
  • AMD EPYC™ 9004 (ジェノヴァ) は Gen9 として表示され、Intel® Xeon® Platinum 8573C (エメラルド ラピッズ) は Gen10 として表示されます

詳細については、エラスティック プール単一データベース と のリソース制限を参照してください。

Hyperscale データベースを作成して管理する

Azure ポータル、Transact-SQL、PowerShell、およびAzure CLIを使用して、Hyperscale データベースを作成および管理できます。 詳細については、「クイックスタート: Hyperscale データベースを作成する」を参照してください。

操作 詳細情報 詳細情報
Hyperscale データベースの作成 ハイパースケール データベースは、 仮想コアベースの購入モデルを使用してのみ使用できます。 Quickstart: Azure SQL Database で Hyperscale データベースを作成する で Hyperscale データベースを作成する例を見つけます。
既存のデータベースを Hyperscale に変換する 既存のデータベースを Azure SQL Database Hyperscale レベルに変換できます。 変換期間は、データのサイズによって異なります。 詳細については、「既存のデータベースを Hyperscaleに変換する」を参照してください。
Hyperscale データベースを General Purpose サービス レベルに逆移行する 以前に既存のAzure SQL Databaseを Hyperscale に移行した場合は、元の Hyperscale への移行から 45 日以内に、データベースを General Purpose サービス レベルに逆移行できます。

データベースを Business Critical などの別のサービス レベルに移行する場合は、まず General Purpose サービス レベルに逆移行してから、サービス レベルを変更します。		 逆移行に関する制限事項など、Hyperscale から逆移行する方法を確認してください。

制限事項

これらの制限は現在、Hyperscale サービス レベルに適用されます。 製品チームは、できるだけ多くの制限を取り除くために積極的に取り組んでいます。

問題 説明
TDE が無効の場合、縮小がブロックされる 現在、Azure SQL Database Hyperscale では、Transparent Data Encryption (TDE) が無効になっている場合、データベースとファイルの圧縮操作はサポートされていません。
他のサービス レベルからデータベースを復元する Hyperscale 以外のデータベースを Hyperscale データベースとして復元することはできません。 Hyperscale データベースを非 Hyperscale データベースとして復元することもできません。

他のAzure SQL Database サービス レベルから Hyperscale に移行されたデータベースの場合、移行前バックアップは、長期的な保持ポリシーを含む、ソース データベースのバックアップ保有期間の間保持されます。 コマンド ラインを使用して、データベースのバックアップ保有期間内に移行前バックアップを復元できます。 これらのバックアップは、Hyperscape 以外のサービス レベルに復元できます。
インメモリ OLTP オブジェクトを使用したデータベースの移行 Hyperscale では、メモリ最適化テーブルの型、テーブル変数、ネイティブ コンパイルされたモジュールなど、インメモリ OLTP オブジェクトのサブセットがサポートされています。 ただし、どのようなインメモリ OLTP オブジェクトでも移行されているデータベースに存在すると、Premium および Business Critical サービス レベルから Hyperscale に移行できません。 このようなデータベースを Hyperscale に移行するには、すべての In-Memory OLTP オブジェクトとその依存関係を削除する必要があります。 データベースが移行されたら、これらのオブジェクトを再作成できます。 永続的と非永続的なメモリ最適化テーブルは Hyperscale では現在サポートされておらず、ディスク テーブルに変更する必要があります。
データベースの整合性チェック DBCC CHECKDBそしてDBCC CHECKFILEGROUPは現在、Azure SQL Databaseハイパースケールデータベースにはサポートされていません。 回避策として DBCC CHECKTABLE ('TableName') WITH TABLOCKを使いましょう。 Azure SQL Databaseでのデータ整合性管理の詳細については、Azure SQL Databaseのデータ整合性に関するページを参照してください。
エラスティック ジョブ Hyperscale データベースをジョブ データベースとして使用することはサポートされていません。 ただし、エラスティック ジョブは、Azure SQL Database内の他のデータベースと同じ方法で Hyperscale データベースをターゲットにすることができます。
データ同期 Hyperscale データベースをハブまたは同期メタデータ データベースとして使用する機能はサポートされていません。 ただし、Hyperscale データベースは、データ同期 トポロジ内のメンバー データベースにすることができます。
Hyperscale サービスレベルの Premium シリーズハードウェア プレミアム シリーズとメモリ最適化プレミアム シリーズのハードウェアでは、現在のところ、サーバーレス コンピューティング レベルはサポートされていません。 サーバーレスは、Standard シリーズ (Gen5) のハードウェアでのみサポートされます。
利用可能なリージョン Hyperscale サービス レベルの Premium シリーズと Premium シリーズのメモリ最適化ハードウェアは、限られたAzure リージョンで利用できます。 一覧については、[Hyperscale Premium シリーズの可用性]を参照してください。

関連するコンテンツ

  • Last updated on