Azure SQL Database ハイパースケールに関する FAQ

Hyperscale データベースは、Azure SQL Database のデータベースであり、Hyperscale スケールアウト ストレージ テクノロジによってサポート。 Hyperscale データベースは最大 128 TB のデータをサポートし、高いスループットとパフォーマンスを実現すると同時に、ワークロードの要件に合わせてすばやくスケーリングできます。 接続、クエリ処理、データベース エンジンの機能など、Azure SQL Database の他のデータベースと同様に機能します。

Hyperscale サービス レベルは、単一データベース (プロビジョニング済みとサーバーレスの両方) と、仮想コアベースの購入モデルを使用するエラスティック プールで使用できます。 DTU ベースの購入モデルでは利用できません。

リソース制限の比較で説明されているように、仮想コアベースのサービス レベルは、データベースの可用性とストレージの種類、パフォーマンス、最大ストレージ サイズに基づいて区別されます。

Hyperscale サービス レベルは、より高いパフォーマンスと可用性、高速のバックアップと復元、高速ストレージ、およびコンピューティングのスケーラビリティを求めるすべてのお客様を対象としています。 これには、小規模から始めて成長しているお客様、大規模なミッション クリティカルなデータベースを実行しているお客様、アプリケーションを最新化するためにクラウドに移行中のお客様、および Azure SQL Database の他のサービス レベルを既に使用しているお客様が含まれます。

ハイパースケールで得られるのは次のとおりです。

• コンピューティング サイズに関係なく、10 GB から 128 TB まで拡張できるデータベース サイズ。
• 2 個の仮想コアから最大 128 個の仮想コアの仮想コア リソースを計算します。
• データベース サイズにかかわらないデータベースの高速バックアップ (ストレージ スナップショットに基づいたバックアップ)
• データベース サイズにかかわらないデータベースの高速復元 (ストレージ スナップショットに基づいた復元)
• データベース サイズと仮想コアの数に関係なく、トランザクション ログのスループットが高くなります。
• 1 つ以上の読み取り専用レプリカを使用した読み取りスケールアウト (オフロード読み取り専用ワークロードまたはホット スタンバイデータベースに対応)。
• コンピューティングの一定時間での迅速なスケールアップ (重いワークロードに対応するために性能を向上) と、その後の一定時間でのスケールダウン。 スケーリング操作にかかる時間は、プロビジョニングされたコンピューティングでは 1 桁の分、サーバーレス コンピューティングではデータベース サイズに関係なく 1 秒未満です。
• サーバーレス コンピューティングでは、従量課金制 (使用量に基づいた課金) のオプションを使用できます。

Hyperscale サービス レベルは、Azure SQL Database が利用可能なすべてのリージョンで利用できます。

はい。 サーバーあたりのデータベース数の詳細や制限については、サーバー上の単一データベースおよびプールされたデータベースの SQL Database リソース制限に関するページをご覧ください。

ハイパースケール アーキテクチャは、大きなデータベース サイズをサポートする一方でハイ パフォーマンスとスループットを提供します。

ハイパースケールでは、ワークロードの需要に基づいて迅速なスケーラビリティを提供します。

• スケールアップ/スケールダウン

  ハイパースケールでは、CPU やメモリなどのリソースの観点で主要なコンピューティング サイズをスケールアップしてから、一定時間でスケールダウンできます。 ストレージはリモートであるため、スケールアップとスケールダウンはデータサイズ操作ではありません。

  サーバーレス コンピューティング のサポートにより、使用量に基づく自動スケールアップとスケールダウン、コンピューティング課金が提供されます。

• スケールイン/スケールアウト

  Hyperscale では、読み取りスケールアウト、高可用性、geo レプリケーションの各要件に対応するために 3 種類のセカンダリ レプリカを使用できます。 これには次のものが含まれます

  • プライマリと同じコンピューティング サイズを持つ最大 4 つの高可用性レプリカ。 これらは、プライマリからすばやくフェールオーバーするためのホット スタンバイ レプリカとして機能します。 また、これらは、プライマリから読み取りワークロードをオフロードするためにも使用できます。
  • プライマリと同じまたは異なるコンピューティング サイズを持つ最大 30 個の名前付きレプリカ (さまざまな読み取りスケールアウト シナリオに対応するため)。
  • 別の Azure リージョン内にある geo レプリカ (リージョンの停止から保護するため、および地理的な読み取りスケールアウトを可能にするため)。

はい、できます。

いいえ。アプリケーションのプログラミング モデルは、他の MSSQL データベースと同じままです。 いつもの接続文字列とその他の通常の方法を使用して、ハイパースケール データベースを操作します。 アプリケーションが Hyperscale データベースを使用すると、セカンダリ レプリカなどの機能を利用できます。

プライマリ レプリカでは、既定のトランザクション分離レベルが READ COMMITTED され、READ_COMMITTED_SNAPSHOT データベース オプション (RCSI) が有効になります。 セカンダリ レプリカでは、分離レベルは SNAPSHOT。 これは、他の Azure SQL データベースと同じです。

シンプルな新しい価格プランが 2023 年 12 月 15 日に施行され、新しく作成された Hyperscale データベース、すべてのサーバーレス Hyperscale データベース、すべての Hyperscale Elastic Pool などのコンピューティング価格が引き下げられました。 新しい、簡素化された価格設定により、同等の節約を得るためにAzure ハイブリッド特典（AHB）を適用する必要はありません。 Azure ハイブリッド特典 (AHB) は、プロビジョニングされたコンピューティングを使用する古い (2023 年 12 月 15 日より前に作成した) Hyperscale 単一データベースにのみ適用できます。 これらの古いデータベースの場合、AHB は 2026 年 12 月までしか適用されません。その後、これらのデータベースも新しい簡略化された価格に従って課金されます。

詳細については、Hyperscale の価格に関するブログの と Azure SQL Database Hyperscale の に関するページを参照してください。価格が低く、簡略化されています。

Hyperscale は、OLTP、ハイブリッド (HTAP)、分析 (データ マート) ワークロードなど、すべてのワークロードの種類に適しています。

現在、SQL Server をデータ ウェアハウスとして使って対話型分析クエリを実行している場合、Hyperscale がオプションとして優れています。小規模から中規模のデータ ウェアハウス (数 TB から最大 128 TB) を低コストでホストでき、T-SQL のコードに最小限の変更を加えるだけで SQL Server データ ウェアハウスのワークロードを Hyperscale に移行できます。

複雑なクエリを使い、100 MB/秒を常に超えるインジェスト速度で大規模にデータ分析を実行している場合、または Parallel Data Warehouse (PDW)、Teradata、その他の超並列処理 (MPP) データ ウェアハウス (Azure Synapse Analytics など) を使っている場合は、Microsoft Fabric を選ぶのが最適である可能性があります。

インジェストまたはログ生成率 150 MiB/秒は、Premium シリーズと Premium シリーズのメモリ最適化のオプトイン プレビュー機能として利用できます。 詳細については、150 MiB/秒にオプトインするには、ブログを参照してください。2024 年 11 月の Hyperscale 拡張機能。

現時点ではありません。 ただし、コンピューティングとレプリカの数をスケールダウンしてピーク時以外のコストを削減したり、サーバーレスを使って使用量に基づいてコンピューティングを自動的にスケーリングしたりできます。

読み取りワークロードの場合、プライマリよりも高いコンピューティング サイズ (より多くのコアおよびメモリ) を持つ名前付きレプリカを作成できます。 使用可能なコンピューティング サイズの詳細については、Hyperscale のストレージおよびコンピューティング サイズに関するページをご覧ください。

読み取りワークロードの場合、これは名前付きレプリカを使用して実現できます。

Azure portal または REST API を使用して、HA セカンダリ レプリカの数を 0 から 4 の間でスケーリングすることができます。 さらに、さまざまな読み取りスケールアウト シナリオに対応するために、最大 30 個の名前付きレプリカを作成できます。 各名前付きレプリカには、最大 4 つの HA セカンダリ レプリカを含めることができます。

ハイパースケール データベースでは、データ回復性はストレージ レベルで提供されます。 回復性を実現するために必要なのレプリカは 1 つだけです。 コンピューティング レプリカが失敗した場合、またはメンテナンス中の場合は、データ損失なしで新しいレプリカが自動的に作成されます。

ただし、プライマリ レプリカしかない場合は、新しいレプリカの作成に 1 ~ 2 分かかることがあります。HA セカンダリ レプリカが使用可能な場合は秒です。 新しいレプリカには、最初はコールド キャッシュがあるため、ストレージの待機時間が長くなり、フェールオーバー直後のクエリ パフォーマンスが低下する可能性があります。

フェールオーバーへの影響を最小限に抑えて高可用性を必要とするミッション クリティカルなアプリケーションの場合は、少なくとも 1 つの HA セカンダリ レプリカをプロビジョニングして、フェールオーバー ターゲットとして機能するホット スタンバイ レプリカを使用できるようにする必要があります。

単一の Hyperscale データベースの最大サイズは、現在、コンピューティング サイズに関係なく 128 TB です。 現在、Hyperscale エラスティック プール内のデータベースの最大サイズは 100 TB です。

Hyperscale において、トランザクション ログは、1 つのトランザクションで 1 TB を超えるログを生成できないという制限はありますが、実質的には無限です。 ログのアクティブな部分は、実行時間の長いトランザクションや、変更データ キャプチャ処理がデータ変更速度に追いつかないことが理由で増加する可能性があります。 この制限を超えないよう、不必要に長くて大きなトランザクションが作成されないようにしてください。 この制限以外、ログ処理能力が高いシステム上では、ログ領域の不足を心配する必要はありません。 ただし、ワークロードを積極的に継続的に書き込む場合は、ログ生成率が低下する可能性があります。 ピークが持続するログ生成速度は、100 MB/秒です。

150 MiB/秒のログ生成レートは、Premium シリーズと Premium シリーズのメモリ最適化のオプトイン プレビュー機能として利用できます。 詳細については、150 MiB/秒にオプトインするには、ブログを参照してください。2024 年 11 月の Hyperscale 拡張機能。

tempdb データベースはローカル SSD ストレージに配置され、プロビジョニングするコンピューティング サイズ (コア数) に比例してサイズが調整されます。 tempdb のサイズを構成することはできません。これは自動的に管理されます。 データベースの最大 tempdb サイズを決定するには、tempdbに関するセクションを参照してください。

データベースのサイズは、データの挿入/取り込みに応じて自動的に拡大します。

10 GB。 Hyperscale データベースは、開始サイズが 10 GB で作成され、必要に応じて拡張されます。

各データ ファイルは 10 GB ずつ拡張されます。 複数のデータ ファイルが同時に拡張される可能性があります。

ハイパースケールでは、データ ファイルは Azure Standard ストレージに格納されます。 計算レプリカに対してリモートのページ サーバーでは、データは完全にローカル SSD ストレージにキャッシュされます。 さらに、計算レプリカは、ローカル SSD とメモリ内にデータ キャッシュを持ち、リモート ページ サーバーからデータをフェッチする回数を減らします。

いいえ。 データ ファイルは、PRIMARY ファイル グループに自動的に追加されます。 追加のファイル グループを作成する一般的な理由は、Hyperscale ストレージ アーキテクチャやより広範な Azure SQL Database には当てはまりません。

いいえ。

はい。データベースとファイルの縮小操作は現在プレビュー段階です。 プレビューの詳細については、「Azure SQL データベース Hyperscale の縮小」をご覧ください。

はい。他の Azure SQL DB データベースと同様です。 これには、行、ページ、列ストア 圧縮が含まれます。

はい。 特定のテーブルに関連付けられたデータ ページを、同じファイルグループに含まれる複数のデータ ファイルに分散することができます。 MSSQL データベース エンジンでは、比例したデータ格納方法を使用してデータをデータ ファイルに均等配置します。

はい。 概念実証 (POC) のために、データベースのコピーを作成して、そのコピーをハイパースケールに移行することをお勧めします。

既存のデータベースを Hyperscale に移動するのに必要な時間は、データのコピーにかかる時間と、データのコピー中にソース データベースに加えられた変更を再生する時間で構成されます。 データのコピー時間は、データのサイズに比例します。 書き込みアクティビティが少ない期間に移動が行われた場合、変更の再生にかかる時間は短くなります。

「既存のデータベースを Hyperscale に移行する」で、Azure portal、Azure CLI、PowerShell、Transact-SQL を使用して既存の Azure SQL データベースを Hyperscale に移行するサンプル コードを取得します。

Azure SQL Database 内の既存のデータベースを Hyperscale サービス レベルに最近移行したお客様は、Hyperscale でニーズを満たせなかった場合、General Purpose サービス レベルへの逆移行により元に戻すことができます。 逆移行はサービス レベルの変更によって開始されますが、基本的には異なるアーキテクチャ間のデータのサイズ操作です。 Hyperscale への移行と同様に、書き込みアクティビティが少ない期間中に行うと、逆移行が速くなります。 逆移行の制限事項について学習します。

以前に既存の Azure SQL Database を Hyperscale サービス レベルに移行している場合、元の Hyperscale への移行から 45 日以内であれば、General Purpose サービス レベルに逆移行できます。 データベースを別のサービス レベル (Business Critical など) に移行する場合は、まず General Purpose サービス レベルに逆移行してから、サービス レベルを変更します。 逆移行は、データサイズの操作です。

Hyperscale サービス レベルで作成されたデータベースは、他のサービス レベルに移動できません。

逆移行に関する制限事項やバックアップ ポリシーなど、Hyperscale から逆移行する方法を確認してください。

はい。 一部の Azure SQL Database 機能は、Hyperscale ではサポートされていません。 これらの機能の一部がデータベースで有効になっている場合、Hyperscale への移行がブロックされたり、移行後にこれらの機能が機能しなくなる可能性があります。 詳細については、「既知の制限事項」を参照してください。

はい。 既存の多くの移行テクノロジ (トランザクション レプリケーションやその他のデータ移動テクノロジ (一括コピー、Azure Data Factory、Azure Databricks、SSIS) など) を使用して、Hyperscale に移行することができます。 Azure Database Migration Service に関するページもご覧ください。このサービスでは、多くの移行シナリオがサポートされています。

ハイパースケールへの移行のダウンタイムは、ご自身のデータベースを他の Azure SQL Database サービス レベルに移行する際のダウンタイムと同じです。 トランザクション レプリケーションを使用すると、ダウンタイムを最小限に抑えて、サイズが数 TB までのデータベースを移行できます。 特に大規模なデータベース (10 TB 以上) の場合は、ADF、Spark、またはその他の一括データ移動テクノロジを使用した移行プロセスを実装することを検討してください。

Hyperscale では、100 MB/秒の新しいデータまたは変更されたデータを消費できますが、Azure SQL Database のデータベースへのデータの移動に必要な時間は、使用可能なネットワーク スループット、ソースの読み取り速度、読み込みの種類 (一括と行単位)、およびターゲット データベース サービス レベル目標の影響も受けます。 150 MiB/秒のログ生成レートは、Premium シリーズと Premium シリーズのメモリ最適化のオプトイン プレビュー機能として利用できます。 詳細については、150 MiB/秒にオプトインするには、ブログを参照してください。2024 年 11 月の Hyperscale 拡張機能。

クライアント アプリケーションで Azure Storage からデータを読み取り、ハイパースケール データベースに読み込むことができます (他の Azure SQL Database データベースの場合と同様です)。 Polybase は現在 Azure SQL Database でサポートされていません。 高速読み込みを提供する代替手段として、Azure Data Factory を使用するか、SQL 用 Spark コネクタで Spark ジョブを Azure Databricks で使用できます。 SQL 用の Spark コネクタでは一括挿入がサポートされます。

BULK INSERT または OPENROWSET を使用して、Azure BLOB ストアからデータを一括で読み取ることもできます。Azure Blob Storage のデータに一括アクセスする例。

Hyperscale では、単純復旧モデルまたは一括ログ復旧モデルはサポートされていません。 高可用性を実現して特定の時点に復旧するには、完全復旧モデルが必要です。 ただし、ハイパースケール ログ アーキテクチャでは、他の Azure SQL Database サービス レベルと比較してデータ取り込み率が向上しています。

いいえ。 ハイパースケールは対称型マルチプロセッシング (SMP) アーキテクチャです。超並列処理アーキテクチャ (MPP) またはマルチマスター アーキテクチャではありません。 複数のレプリカを作成して、読み取り専用ワークロードをスケールアウトできます。

はい。 Azure Database Migration Service では多くの移行シナリオがサポートされています。

「Azure SQL Database の SLA」を参照してください。 クリティカル ワークロード用に HA セカンダリ レプリカを追加することをお勧めします。 これにより、フェールオーバーが高速化され、フェールオーバー直後のパフォーマンスに対する潜在的な影響が軽減されます。

はい。

はい、Hyperscale では、ゾーン冗長構成がサポートされています。 Hyperscale のゾーン冗長構成を有効にするには、少なくとも一つの HA セカンダリ レプリカと、ゾーン冗長または geo ゾーン冗長ストレージの使用が必要です。

はい。 詳細については、「Hyperscale Elastic Pool」および「ブログ: Hyperscale Elastic Poolの一般提供開始」を参照してください。

Hyperscale データベースでは、従来の完全バックアップ、差分バックアップ、トランザクション ログ バックアップは存在しません。 代わりに、データ ファイルの定期的なストレージ スナップショットがあります (スナップショット頻度はファイルごとに固有です)。 生成されたトランザクション ログは、構成された保有期間だけそのまま保持されます。 復元時、関連するトランザクション ログ レコードが、復元されたストレージ スナップショットに適用されます。 スナップショットの周期に関係なく、これにより、データが失われることなく、保有期間内に指定された時点でトランザクションに一貫性のあるデータベースが作成されます。 実際、Hyperscale でのデータベース バックアップは継続的です。

はい。

ポイントインタイム リストアの RPO は 0 分です。 ほとんどのポイントインタイム リストア操作は、データベース サイズにかかわらず、60 分以内に完了します。 大規模なデータベースの場合、および復元ポイントの前とそこに至るまでの時間に大量の書き込みアクティビティが発生した場合は、復元時間が長くなる可能性があります。 ストレージ冗長 の最近の変更後に復元を発行すると、復元がデータのサイズ操作になる可能性があり、復元時間がデータベース サイズに比例する可能性があるため、復元時間が長くなる可能性があります。

いいえ。 バックアップはストレージ サブシステムによって管理され、ストレージ スナップショットを使用します。 ユーザー ワークロードには影響しません。

はい。 geo 冗長ストレージまたは geo ゾーン冗長ストレージが使用されている場合、geo リストアは完全にサポートされます。 geo 冗長ストレージは、新しいデータベースの既定値です。 ポイントインタイム リストアとは異なり、geo リストアでは、データ サイズに応じた操作が必要です。 データ ファイルは並行してコピーされるため、この操作の実行時間は、データベースの合計サイズではなく、データベース内の最大ファイルのサイズによって主に決まります。 ソース データベースのリージョンとペアリングされた Azure リージョンでデータベースを復元した場合、Geo リストアの時間は大幅に短くなります。

はい。 geo レプリケーションの と フェールオーバー グループ は、Hyperscale データベース用に設定できます。

いいえ。 Hyperscale データベースのストレージ形式は、リリース バージョンの SQL Server とは異なります。バックアップの管理またはバックアップへのアクセスはできません。 Hyperscale データベースからデータを取り出すには、Azure Data Factory、Azure Databricks、SSIS などの任意のデータ移動テクノロジを使用してデータを抽出できます。

はい。 2022 年 5 月 4 日より、すべての新しいデータベースは、消費されたバックアップ ストレージと、「Azure SQL Database の価格」ページに示されているレートの選択されたストレージ冗長に基づいて課金されます。 2022 年 5 月 4 日より前に作成されたハイパースケール データベースの場合、設定されたバックアップ保持期間が 7 日間を超える場合にのみ、バックアップに対して課金されます。 詳細については、「Hyperscale のバックアップとストレージの冗長性」を参照してください。

バックアップ ストレージ サイズを測定する方法の詳細については、「自動バックアップを参照してください。

バックアップ ストレージの請求額を決定するために、バックアップ ストレージ サイズが定期的に計算され、バックアップ ストレージ レートと最後の計算からの時間数が乗算されれます。 ある期間のバックアップ請求額を見積もるには、その期間の 1 時間ごとの請求対象バックアップ ストレージ サイズにバックアップ ストレージ レートを掛け、1 時間あたりの金額をすべて合計します。 プログラムで複数の時間単位の間隔で関連する Azure Monitor メトリックのクエリを実行するには、Azure Monitor REST API を使用します。 サーバーレス コンピューティング レベルでのバックアップ課金は、プロビジョニング済みコンピューティング レベルの場合と同じです。

データベース内の大量のデータを追加、変更、または削除するワークロードの場合、バックアップ コストは高くなります。 逆に、ほとんどが読み取り専用のワークロードでは、バックアップ コストが低くなる可能性があります。

バックアップ ストレージのコストを最小限に抑える方法の詳細については、「自動バックアップを参照してください。

現時点では、Hyperscale 以外のサービス レベル (Basic/Standard/Premium/General Purpose/Business Critical) のバックアップを Hyperscale サービス レベルに geo リストアすることはできません。その逆も同様です。 Hyperscale 以外のデータベースを Hyperscale データベースに変換するには、リストア後にサービス レベルを変更します。

トランザクション ログのスループット制限は、任意の Hyperscale コンピューティング サイズに対して 100 MB/秒です。 この速度を達成する能力は、ワークロードの種類やクライアントの構成、パフォーマンスなど、さまざまな要因によって異なります。また、プライマリ計算レプリカ上に、この速度でログ記録を生成するための十分なコンピューティング容量があるかどうかによっても影響されます。 150 MiB/秒のログ生成レートは、Premium シリーズと Premium シリーズのメモリ最適化のオプトイン プレビュー機能として利用できます。 詳細については、150 MiB/秒にオプトインするには、ブログを参照してください。2024 年 11 月の Hyperscale 拡張機能。

IOPS と IO 待ち時間は、ワークロードのパターンによって異なります。 アクセスされるデータがコンピューティング レプリカのローカル SSD ストレージにキャッシュされている場合、Business Critical または Premium サービス レベルと同様の IO パフォーマンスが表示されます。

いいえ。 コンピューティングはストレージ レイヤーから切り離されます。 これによりパフォーマンスへのバックアップの影響がなくなります。

ストレージは共有されており、プライマリとセカンダリのコンピューティング レプリカの間で直接物理レプリケーションが行われていないため、プライマリ レプリカのスループットはセカンダリ レプリカの追加による直接の影響を受けません。 ただし、継続的かつ積極的な書き込みワークロードのログレートは、セカンダリ レプリカとページ サーバーにログを適用して追いつくために、プライマリで制限される場合があります。 これにより、セカンダリ レプリカでの読み取りパフォーマンスの低下と、HA セカンダリ レプリカへのフェイルオーバー後の長時間の復旧が回避されます。

はい。 ただし、他の Azure SQL データベースと同様に、非常に頻度の低い一時的なエラーによって接続が終了する可能性があります。このエラーにより、実行時間の長いクエリが中止され、トランザクションがロールバックされる可能性があります。 一時的なエラーの原因の 1 つとして、コンピューティングやストレージ リソースの継続的可用性を確保したり、計画メンテナンスを実行したりするために、システムによってデータベースが別のコンピューティング ノードにすばやくシフトされる場合があります。 これらの再構成イベントの多くは、10 秒未満で終了します。 データベースに接続するアプリケーションは、再試行ロジックを実装することによって、これらの発生頻度の低い一時的なエラーを想定して許容するように構築する必要があります。 また、計画メンテナンスのために一時的なエラーが発生しないように、ワークロードのスケジュールに一致するメンテナンス期間を構成することを検討してください。

ほとんどのパフォーマンスの問題 (特にストレージ パフォーマンスに根ざしていない問題) には、一般的な MSSQL の診断とトラブルシューティングの手順が適用されます。 ハイパースケール固有のストレージ診断については、「SQL Hyperscale のパフォーマンスのトラブルシューティング診断」を参照してください。

サーバーレス データベースでスケールアップできるメモリの最大量は、構成された仮想コアの最大数に 3 GB/仮想コアを掛けたものです。これに対して、プロビジョニング済みコンピューティングでは、5 GB/仮想コアに同じ数の仮想コアを掛けたものよりも大きくなります。 詳細については、サーバーレス Hyperscale リソースの制限に関するセクションをご確認ください。

プロビジョニング済みコンピューティング レベルでのスケールアップ、またはダウンは、データサイズに関わらず最大 2 分かかります。 サーバーレス コンピューティング レベルでは、ワークロードの需要に基づいてコンピューティングが自動的にスケーリングされ、スケーリング時間は、通常、1 秒未満ですが、プロビジョニング済みコンピューティングをスケーリングする場合と同じくらい時間がかかることもあります。

いいえ。 スケールアップまたはスケールダウンの操作中、データベースはオンラインのままです。

プロビジョニング済みコンピューティングをスケールアップまたはダウンすることで接続が切断されるのは、スケーリング操作の終了時にフェールオーバーが発生したときです。 サーバーレス コンピューティングでは、通常、自動スケーリングで接続が切断されることはありませんが、場合によっては接続が切断されることがあります。 セカンダリ レプリカを追加または削除しても、プライマリの接続は切断されません。

プロビジョニング済みコンピューティングのスケーリングは、エンド ユーザーによって行われます。 サーバーレス コンピューティングの自動スケーリングは、サービスによって行われます。

はい。 tempdb データベースと コンピューティング SSD キャッシュ コンピューティング ノードのサイズは、コアの数が増えた時点で自動的にスケールアップされます。 詳細については、Hyperscale のストレージとコンピューティング サイズに関するセクションを参照してください。

いいえ。 読み取り/書き込み要求を受け入れるのはプライマリ計算レプリカのみです。 セカンダリ計算レプリカは、読み取り専用要求のみを受け入れます。

Hyperscale では、高可用性 (HA) レプリカ、名前付きレプリカ、および geo レプリカがサポートされます。 詳細については、「Hyperscale セカンダリ レプリカ」を参照してください。

1 から 4 の間。 レプリカの数を調整する場合は、Azure portal または REST API を使用します。

これらの追加読み取り専用計算レプリカに接続するには、接続文字列の ApplicationIntent プロパティを ReadOnly に設定します。 ReadOnly でマークされたすべての接続は、HA セカンダリ レプリカのいずれかに自動的にルーティングされます (あれば)。 詳細については、「読み取り専用レプリカを使用して読み取り専用クエリ ワークロードをオフロードする」を参照してください。

T-SQL クエリ SELECT DATABASEPROPERTYEX ('<database_name>', 'Updateability') を実行できます。 結果は、読み取り専用セカンダリ レプリカに接続されている場合は READ_ONLY、プライマリ レプリカに接続されている場合は READ_WRITE になります。 データベース コンテキストは、master データベースではなく、お使いのデータベースの名前に設定する必要があります。

いいえ。 ApplicationIntent=ReadOnly を指定することによって、HA セカンダリ レプリカだけに接続できます。 ただし、名前付きレプリカには専用エンドポイントを使用できます。

いいえ。 読み取り専用の意図との新しい接続は、任意の HA セカンダリ レプリカにリダイレクトされます。

プロビジョニング済みコンピューティング レベルではできません。 HA セカンダリ レプリカは高可用性フェールオーバー ターゲットとして使用されるため、フェールオーバー後、期待されるパフォーマンスを提供できるように、プライマリと同じ構成にする必要があります。 サーバーレスでは、コンピューティングは個々のワークロードの需要に基づいて HA レプリカごとに自動的にスケーリングされます。 各 HA セカンダリは、フェールオーバー後のロールに対応するために、構成された最大コアに自動スケーリングできます。 名前付きレプリカ は、各名前付きレプリカを個別にスケーリングする機能を提供します。

いいえ。 tempdb データベースはプロビジョニングされたコンピューティング サイズに基づいて構成され、HA セカンダリ レプリカは、tempdb も含めて、プライマリ計算と同じサイズになります。 名前付きレプリカでは、tempdb のサイズはレプリカのコンピューティング サイズに応じて設定されるため、プライマリの tempdb より小さくなったり大きくなったりすることがあります。

いいえ。 Hyperscale データベースの計算レプリカはストレージを共有します。つまり、すべての計算レプリカが同じテーブル、インデックス、その他のデータベース オブジェクトを参照します。 読み取りに対して最適化したインデックスをセカンダリに追加したい場合は、プライマリに追加する必要があります。 各セカンダリ レプリカに一時テーブル (#または ## がプレフィックス付きのテーブル名) を作成して、tempdb データベースに一時データを格納できます。 一時テーブルは読み取り/書き込みです。

トランザクションがプライマリ上でコミットされてからセカンダリで読み取り可能になるまでのデータ待機時間は、現在のログ生成速度、トランザクション サイズ、レプリカへの負荷、およびその他の要因によって異なります。 小規模なトランザクションの一般的なデータ待機時間は数十ミリ秒ですが、データ待機時間に上限はありません。 特定のセカンダリ レプリカ上のデータは、トランザクション上一貫性があるため、トランザクションが大きいほど伝達に時間がかかります。 特定の時点で、セカンダリ レプリカごとにデータの待機時間とデータベースの状態が異なる場合があります。 コミットされたデータの読み取りが直ちに必要なワークロードは、プライマリ レプリカで実行される必要があります。

いいえ。名前付きレプリカをプライマリ レプリカのフェールオーバー ターゲットとして使用することはできません。 その目的でプライマリ レプリカの HA レプリカを追加します。

すべての名前付きレプリカは、異なるサービス レベル目標を持つ場合があり、したがって異なるユース ケースに使用される可能性があるため、プライマリに直接送信された読み取り専用トラフィックを一連の名前付きレプリカに転送する組み込みの方法はありません。 たとえば、8 個の名前付きレプリカがある場合、OLTP ワークロードは名前付きレプリカ 1 から 4 にのみ転送し、Power BI 分析ワークロードでは名前付きレプリカ 5 と 6 を使用し、データ サイエンス ワークロードにはレプリカ 7 と 8 を使用することができます。 そのようなワークロードを分散する戦略は、使用するツールまたはプログラミング言語によって異なる場合があります。 REST バックエンドをスケールアウトできるようにするワークロード ルーティング ソリューションを作成する例については、OLTP スケールアウト サンプルを確認してください。

いいえ。名前付きレプリカではプライマリ レプリカと同じページ サーバーが使用されるため、それらは同じリージョンに存在する必要があります。 ただし、別のリージョンのプライマリ レプリカの geo レプリカを作成した場合は、geo レプリカの名前付きレプリカを作成できます。

名前付きレプリカによってプライマリ レプリカの可用性が影響を受けることはありません。 通常の状況では、名前付きレプリカがプライマリのパフォーマンスに影響を与える可能性はほとんどありませんが、負荷の高いワークロードが実行されている場合は発生する可能性があります。 HA レプリカと同様に、名前付きレプリカはトランザクション ログ サービスを介してプライマリと同期されます。 何らかの理由で名前付きレプリカがトランザクション ログを十分に高速に使用できない場合は、ログ生成率を下げて追いつくことができるようにプライマリ レプリカに要求を開始します。 この動作はプライマリの可用性には影響しませんが、プライマリでの書き込みワークロードのパフォーマンスに影響を与える可能性があります。 このような状況を回避するには、名前付きレプリカに、トランザクション ログを遅延なく処理するための十分なリソース ヘッドルーム (主に CPU) があることを確認します。 たとえば、プライマリが多数のデータ変更を処理している場合は、レプリカの CPU の飽和とプライマリの速度低下の強制を回避するために、少なくともプライマリと同じコンピューティング サイズの名前付きレプリカを使用することをお勧めします。

通常どおり、名前付きレプリカは読み取り専用アクセスで引き続き使用できます。

既定では、名前付きレプリカには独自の HA レプリカはありません。 名前付きレプリカのフェールオーバーでは、最初に新しいレプリカを作成する必要があります。これには通常、約1 - 2分かかります。 ただし、名前付きレプリカは、HA レプリカによって提供される可用性の向上とフェールオーバーの短縮の恩恵を受けることもできます。 Azure portal で名前付きレプリカの HA レプリカを追加するか、az CLIでパラメーター を使用するか、PowerShellでパラメーター を使用するか、REST APIを使用して プロパティを使用できます。 HA レプリカの数は、名前付きレプリカの作成時に設定でき、名前付きレプリカが作成された後はいつでも変更できます。 名前付きレプリカの HA レプリカの価格は、プライマリ レプリカの HA レプリカと同じです。

はい。 列マスター キーはユーザー データベースに格納され、クエリ SELECT * FROM sys.column_master_keys を実行して検証されます。 名前付きレプリカと高可用性セカンダリ レプリカは、プライマリ Hyperscale データベースと同じページ サーバー/ストレージ レイヤからデータを読み取ります。 どちらの種類のレプリカも、ログ サービスを介してプライマリ Hyperscale データベースと同期されます。 キーの変更はトランザクションと見なされ、すべてのセカンダリ レプリカに自動的にレプリケートされます。

プライマリ レプリカで sys.dm_database_replica_states クエリを実行するときではありません。 ただし、次のサンプル クエリを使用して、名前付きレプリカに接続して、そのレプリカ ID とその他の詳細を確認できます。

  SELECT replica_id,
         DB_NAME() AS named_replica_database_name,
         synchronization_state_desc,
         log_send_queue_size / 1024.0 / 1024.0 AS log_send_queue_size_gb,
         last_sent_time,
         last_received_time,
         last_commit_time,
         redo_queue_size / 1024.0 / 1024.0 AS redo_queue_size_gb,
         redo_rate,
         secondary_lag_seconds
  FROM sys.dm_database_replica_states
  WHERE is_local = 1
        AND
        replica_id = DATABASEPROPERTYEX(DB_NAME(), 'ReplicaID');

関連するコンテンツ

ハイパースケール サービス レベルについて詳しくは、ハイパースケール サービス レベルに関するページをご覧ください。