ハイパースケール サービス レベルHyperscale service tier

Azure SQL Database は、インフラストラクチャに障害が発生した場合でも 99.99% の可用性を確保するために、クラウド環境に合わせて調整された SQL Server データベース エンジン アーキテクチャに基づいています。Azure SQL Database is based on SQL Server Database Engine architecture that is adjusted for the cloud environment in order to ensure 99.99% availability even in the cases of infrastructure failures. Azure SQL Database で使用されているアーキテクチャ モデルは 3 つあります。There are three architectural models that are used in Azure SQL Database:

  • General Purpose/StandardGeneral Purpose/Standard
  • ハイパースケールHyperscale
  • Business Critical/PremiumBusiness Critical/Premium

Azure SQL Database の Hyperscale サービス レベルは、仮想コアベースの購入モデルにおける最新のサービス レベルです。The Hyperscale service tier in Azure SQL Database is the newest service tier in the vCore-based purchasing model. このサービス レベルは、拡張性の高いストレージおよびコンピューティング パフォーマンス レベルであり、Azure のアーキテクチャを利用して、General Purpose および Business Critical サービス レベルの制限を大きく超えて、Azure SQL Database 用のストレージおよびコンピューティング リソースをスケールアウトします。This service tier is a highly scalable storage and compute performance tier that leverages the Azure architecture to scale out the storage and compute resources for an Azure SQL Database substantially beyond the limits available for the General Purpose and Business Critical service tiers.

注意

仮想コアベースの購入モデルでの General Purpose サービス レベルと Business Critical サービス レベルの詳細については、General Purpose サービス レベルと Business Critical サービス レベルの記事を参照してください。For details on the General Purpose and Business Critical service tiers in the vCore-based purchasing model, see General Purpose and Business Critical service tiers. 仮想コアベースの購入モデルと DTU ベースの購入モデルとの比較については、Azure SQL Database の購入モデルとリソースに関する記事をご覧ください。For a comparison of the vCore-based purchasing model with the DTU-based purchasing model, see Azure SQL Database purchasing models and resources.

ハイパースケールの機能とはWhat are the Hyperscale capabilities

Azure SQL Database の Hyperscale サービス レベルでは、次の追加機能が提供されます。The Hyperscale service tier in Azure SQL Database provides the following additional capabilities:

  • 最大 100 TB のデータベース サイズのサポートSupport for up to 100 TB of database size
  • サイズに関係なく、コンピューティング リソースに対する IO の影響もなく、ほぼ瞬間的に行われるデータベース バックアップ (Azure BLOB Storage に格納されたファイル スナップショットに基づく)Nearly instantaneous database backups (based on file snapshots stored in Azure Blob storage) regardless of size with no IO impact on compute resources
  • 時間単位や日単位ではなく、数分で行われる、(ファイルのスナップショットに基づく) 高速なデータベース ポイントインタイム リストア (データのサイズに左右される操作ではありません)Fast database point-in-time restores (based on file snapshots) in minutes rather than hours or days (not a size of data operation)
  • データ ボリュームに関係なく、高いログ スループットと速いトランザクション コミット時間による、全体的に高いパフォーマンスHigher overall performance due to higher log throughput and faster transaction commit times regardless of data volumes
  • 迅速なスケールアウト - 読み取りワークロードのオフロード用と、ホット スタンバイ用に、1 つ以上の読み取り専用ノードをプロビジョニングできます。Rapid scale out - you can provision one or more read-only nodes for offloading your read workload and for use as hot-standbys
  • 迅速なスケールアップ - 大きいワークロードに対応する必要があるときはコンピューティング リソースを一定の時間でスケールアップでき、必要がなくなったらコンピューティング リソースをスケールダウンして戻すことができます。Rapid Scale up - you can, in constant time, scale up your compute resources to accommodate heavy workloads as and when needed, and then scale the compute resources back down when not needed.

Hyperscale サービス レベルでは、クラウド データベースにおいて従来見られた実質的な制限の多くが取り除かれます。The Hyperscale service tier removes many of the practical limits traditionally seen in cloud databases. 他のほとんどのデータベースは 1 つのノードで使用可能なリソースによって制限されますが、Hyperscale サービス レベルのデータベースにはそのような制限はありません。Where most other databases are limited by the resources available in a single node, databases in the Hyperscale service tier have no such limits. ストレージ アーキテクチャの柔軟性が高く、必要に応じてストレージが拡張されます。With its flexible storage architecture, storage grows as needed. 実際、Hyperscale データベースの作成時には最大サイズは定義されません。In fact, Hyperscale databases aren’t created with a defined max size. Hyperscale データベースは必要に応じて拡大し、使用している容量に対してのみ課金されます。A Hyperscale database grows as needed - and you are billed only for the capacity you use. 読み取り集中型ワークロードでは、Hyperscale サービス レベルは、読み取りワークロードのオフロード用に必要に応じて追加の読み取りレプリカをプロビジョニングし、迅速なスケールアウトを提供します。For read-intensive workloads, the Hyperscale service tier provides rapid scale-out by provisioning additional read replicas as needed for offloading read workloads.

さらに、データベース バックアップの作成に必要な時間や、スケールアップまたはスケールダウンに必要な時間は、データベース内のデータの量に関連しなくなっています。Additionally, the time required to create database backups or to scale up or down is no longer tied to the volume of data in the database. Hyperscale データベースはほぼ瞬時にバックアップできます。Hyperscale databases can be backed up virtually instantaneously. また、数十テラバイトのデータベースを、数分でスケールアップまたはスケールダウンできます。You can also scale a database in the tens of terabytes up or down in minutes. この機能により、初期構成の選択によって縛り付けられることを心配する必要はなくなります。This capability frees you from concerns about being boxed in by your initial configuration choices.

ハイパースケール サービス レベルのコンピューティング サイズについて詳しくは、「サービス レベルの特性」をご覧ください。For more information about the compute sizes for the Hyperscale service tier, see Service tier characteristics.

Hyperscale サービス レベルを検討する必要があるユーザーWho should consider the Hyperscale service tier

Hyperscale サービス レベルは、個別にスケーラブルなコンピューティング リソースとストレージ リソースを使用して優れた柔軟性と高パフォーマンスを提供するため、ほとんどのビジネス ワークロードを対象としています。The Hyperscale service tier is intended for most business workloads as it provides great flexibility and high performance with independently scalable compute and storage resources. ストレージを最大 100 TB まで自動スケールする機能により、次のようなお客様にとって最適な選択肢となります。With the ability to auto-scale storage up to 100 TB, it's a great choice for customers who:

  • オンプレミスに大規模なデータベースがあり、クラウドに移行してアプリケーションを最新化する必要がある場合Have large databases on-premises and want to modernize their applications by moving to the cloud
  • 既にクラウドを利用しているが、他のサービス レベルのデータベースの最大サイズ制限によって制限されている (1 ~ 4 TB)Are already in the cloud and are limited by the maximum database size restrictions of other service tiers (1-4 TB)
  • 使用するデータベースは小さいが、垂直方向と水平方向の高速なコンピューティング スケーリング、高パフォーマンス、インスタント バックアップ、データベースの高速復元を必要としている。Have smaller databases, but require fast vertical and horizontal compute scaling, high performance, instant backup, and fast database restore.

Hyperscale サービスレベルは、純粋な OLTP から純粋な分析まで、さまざまな SQL Server ワークロードをサポートしていますが、主に OLTP とハイブリッド トランザクションおよび分析処理 (HTAP) のワークロード向けに最適化されています。The Hyperscale service tier supports a broad range of SQL Server workloads, from pure OLTP to pure analytics, but it is primarily optimized for OLTP and hybrid transaction and analytical processing (HTAP) workloads.

重要

エラスティック プールでは、Hyperscale サービス レベルはサポートされていません。Elastic pools do not support the Hyperscale service tier.

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

ハイパースケール サービス レベルは仮想コア モデルのみで提供されています。Hyperscale service tier is only available in vCore model. 新しいアーキテクチャに合わせて、価格モデルは General Purpose または Business Critical サービス モデルとは少し異なります。To align with the new architecture, the pricing model is slightly different from General Purpose or Business Critical service tiers:

  • コンピューティング:Compute:

    ハイパースケール コンピューティング ユニットの料金はレプリカ単位です。The Hyperscale compute unit price is per replica. Azure ハイブリッド特典の価格が読み取りスケール レプリカに自動的に適用されます。The Azure Hybrid Benefit price is applied to read scale replicas automatically. 既定では、Hyperscale データベースごとにプライマリ レプリカと 1 つの読み取り専用レプリカを作成します。We create a primary replica and one read-only replica per Hyperscale database by default. ユーザーは、プライマリを含むレプリカの総数を、1 から 5 までの間で調整できます。Users may adjust the total number of replicas including the primary from 1-5.

  • ストレージ:Storage:

    ハイパースケールのデータベースを構成するときに、最大データ サイズを指定する必要はありません。You don't need to specify the max data size when configuring a Hyperscale database. ハイパースケール レベルでは、実際の使用量に基づき、データベース用のストレージに料金が発生します。In the hyperscale tier, you are charged for storage for your database based on actual usage. ストレージは 10 GB から 100 TB の間で自動的に割り当てられ、増加分は 10 GB から 40 GB の間で動的に調整されます。Storage is automatically allocated between 10 GB and 100 TB, in increments that are dynamically adjusted between 10 GB and 40 GB.

ハイパースケールの価格について詳しくは、「Azure SQL Database の価格」をご覧ください。For more information about Hyperscale pricing, see Azure SQL Database Pricing

分散機能アーキテクチャDistributed functions architecture

1 つの場所/プロセスにすべてのデータ管理機能を集中させる従来のデータベース エンジンとは異なり (今日の運用環境で分散データベースと呼ばれているものでも、モノリシックなデータ エンジンの複数のコピーを使用しています)、Hyperscale データベースでは、さまざまなデータ エンジンのセマンティクスが分岐しているクエリ処理エンジンと、データの長期的なストレージと持続性を提供するコンポーネントが分かれています。Unlike traditional database engines that have centralized all of the data management functions in one location/process (even so called distributed databases in production today have multiple copies of a monolithic data engine), a Hyperscale database separates the query processing engine, where the semantics of various data engines diverge, from the components that provide long-term storage and durability for the data. これにより、ストレージ容量をスムーズに必要な限りスケールアウトできます (初期ターゲットは 100 TB)。In this way, the storage capacity can be smoothly scaled out as far as needed (initial target is 100 TB). 読み取り専用レプリカは同じストレージ コンポーネントを共有しているので、新しい読み取り可能レプリカを起動するためにデータのコピーは必要ありません。Read-only replicas share the same storage components so no data copy is required to spin up a new readable replica.

次の図では、Hyperscale データベースでのノードのさまざまな種類を示します。The following diagram illustrates the different types of nodes in a Hyperscale database:

アーキテクチャ

Hyperscale データベースには、次の種類のコンポーネントが含まれます。A Hyperscale database contains the following different types of components:

ComputeCompute

コンピューティング ノードにはリレーショナル エンジンが存在するので、すべての言語要素、クエリ処理などがここで発生します。The compute node is where the relational engine lives, so all the language elements, query processing, and so on, occur. Hyperscale データベースとユーザーのすべてのやり取りは、これらのコンピューティング ノードを通して行われます。All user interactions with a Hyperscale database happen through these compute nodes. データのページをフェッチするために必要なネットワーク ラウンドトリップの数を最小限に抑えるため、コンピューティング ノードは SSD ベースのキャッシュ (前の図の RBPEX - 弾性バッファー プール拡張機能) を備えています。Compute nodes have SSD-based caches (labeled RBPEX - Resilient Buffer Pool Extension in the preceding diagram) to minimize the number of network round trips required to fetch a page of data. プライマリ コンピューティング ノードが 1 つあり、すべての読み書きワークロードとトランザクションがそこで処理されます。There is one primary compute node where all the read-write workloads and transactions are processed. 1 つ以上のセカンダリ コンピューティング ノードがあり、フェールオーバーのためのホット スタンバイ ノードとして、また (この機能が必要な場合は) 読み取りワークロードをオフロードするための読み取り専用コンピューティング ノードとして機能します。There are one or more secondary compute nodes that act as hot standby nodes for failover purposes, as well as act as read-only compute nodes for offloading read workloads (if this functionality is desired).

ページ サーバーPage server

ページ サーバーは、スケールアウトされたストレージ エンジンを表すシステムです。Page servers are systems representing a scaled-out storage engine. 各ページ サーバーは、データベース内のページのサブセットを受け持ちます。Each page server is responsible for a subset of the pages in the database. 通常、各ページ サーバーでは 128 GB から 1 TB のデータが制御されます。Nominally, each page server controls between 128 GB and 1 TB of data. 複数のページ サーバーでデータが共有されることはありません (冗長性と可用性のために保持されているレプリカの外部)。No data is shared on more than one page server (outside of replicas that are kept for redundancy and availability). ページ サーバーの役割は、必要に応じてコンピューティング ノードにデータベース ページを提供し、トランザクションでデータが更新されたらページを更新することです。The job of a page server is to serve database pages out to the compute nodes on demand, and to keep the pages updated as transactions update data. ページ サーバーは、ログ サービスからのログ レコードを再生することによって最新の状態に維持されます。Page servers are kept up-to-date by playing log records from the log service. また、ページ サーバーはパフォーマンスを強化するために SSD ベースのキャッシュも備えています。Page servers also maintain SSD-based caches to enhance performance. 信頼性向上のため、データ ページの長期的なストレージが Azure Storage に保持されます。Long-term storage of data pages is kept in Azure Storage for additional reliability.

ログ サービスLog service

ログ サービスは、プライマリ コンピューティング レプリカからログ レコードを受け取り、持続性キャッシュにそれを保持し、他のコンピューティング レプリカ (キャッシュを更新できるように) および関連するページ サーバーにログ レコードを転送して、それらの場所でデータを更新できるようにします。The log service accepts log records from the primary compute replica, persists them in a durable cache, and forwards the log records to the rest of compute replicas (so they can update their caches) as well as the relevant page server(s), so that the data can be updated there. このようにして、プライマリ コンピューティング レプリカからのすべてのデータ変更が、ログ サービスを介して、すべてのセカンダリ コンピューティング レプリカとページ サーバーに伝達されます。In this way, all data changes from the primary compute replica are propagated through the log service to all the secondary compute replicas and page servers. 最後に、ログ レコードは、実質的に無制限のストレージ リポジトリである Azure Storage の長期ストレージにプッシュされます。Finally, the log records are pushed out to long-term storage in Azure Storage, which is a virtually infinite storage repository. このメカニズムにより、頻繁にログを切り捨てる必要がなくなります。This mechanism removes the need for frequent log truncation. ログ サービスは、ログ レコードへのアクセスを高速化するためのローカル キャッシュも備えています。The log service also has local cache to speed up access to log records.

Azure StorageAzure storage

Azure Storage には、データベース内のすべてのデータ ファイルが格納されています。Azure Storage contains all data files in a database. ページ サーバーは Azure Storage 内のデータ ファイルを最新の状態に保ちます。Page servers keep data files in Azure Storage up to date. このストレージは、バックアップ目的だけでなく、Azure リージョン間のレプリケーションにも使用されます。This storage is used for backup purposes, as well as for replication between Azure regions. バックアップはデータ ファイルのストレージ スナップショットを使用して実行されます。Backups are implemented using storage snapshots of data files. スナップショットを使用した復元操作は、データ サイズに関係なく高速です。Restore operations using snapshots are fast regardless of data size. データはデータベースのバックアップ保有期間内の任意の時点に復元できます。Data can be restored to any point in time within the backup retention period of the database.

バックアップと復元Backup and restore

バックアップはファイル スナップショット ベースなので、ほぼ瞬時に実行されます。Backups are file-snapshot based and hence they are nearly instantaneous. ストレージとコンピューティングの分離により、バックアップ/復元操作をストレージ層に移すことができるので、プライマリ コンピューティング レプリカの処理の負荷が軽減されます。Storage and compute separation enables pushing down the backup/restore operation to the storage layer to reduce the processing burden on the primary compute replica. その結果、データベースのバックアップはプライマリ コンピューティング ノードのパフォーマンスに影響を与えません。同様に、復元はファイル スナップショットに戻すことによって行われるため、データ サイズに左右される操作ではありません。As a result, database backup does not impact performance of the primary compute node; similarly, restores are done by reverting to file snapshots, and as such are not a size of data operation. 復元は一定時間の操作であり、数テラバイトのデータベースであっても数時間や数日ではなく数分で復元できます。Restore is a constant-time operation, and even multiple-terabyte databases can be restored in minutes instead of hours or days. 既存のバックアップを復元することによって新しいデータベースを作成する場合もこの機能を利用します。開発またはテスト目的での同じ論理サーバー内のデータベース コピーの作成は、テラバイト サイズのデータベースであっても数分で実行できます。Creation of new databases by restoring an existing backup also takes advantage of this feature: creating database copies within the same logical server for development or testing purposes, even of terabyte sized databases, is doable in minutes.

スケールとパフォーマンスの利点Scale and performance advantages

追加の読み取り専用コンピューティング ノードを迅速に起動/停止できるので、Hyperscale アーキテクチャでは、読み取りのスケーリング機能が優れ、より多くの書き込み要求に対応できるようにプライマリ コンピューティング ノードを解放することもできます。With the ability to rapidly spin up/down additional read-only compute nodes, the Hyperscale architecture allows significant read scale capabilities and can also free up the primary compute node for serving more write requests. また、Hyperscale アーキテクチャの共有ストレージ アーキテクチャのため、コンピューティング ノードをすばやくスケールアップ/スケールダウンできます。Also, the compute nodes can be scaled up/down rapidly due to the shared-storage architecture of the Hyperscale architecture.

ハイパースケール データベースの作成Create a HyperScale database

ハイパースケール データベースは、Azure portalT-SQLPowershell、または CLI を使用して作成できます。A HyperScale database can be created using the Azure portal, T-SQL, Powershell or CLI. ハイパースケール データベースは、仮想コアベースの購入モデルのみを使用して入手できます。HyperScale databases are available only using the vCore-based purchasing model.

次の T-SQL コマンドによって、ハイパースケール データベースが作成されます。The following T-SQL command creates a Hyperscale database. CREATE DATABASE ステートメントにエディションとサービス目標の両方を指定する必要があります。You must specify both the edition and service objective in the CREATE DATABASE statement. 有効なサービス目標の一覧についてはリソースの制限に関するページを参照してください。Refer to the resource limits for a list of valid service objectives.

-- Create a HyperScale Database
CREATE DATABASE [HyperScaleDB1] (EDITION = 'HyperScale', SERVICE_OBJECTIVE = 'HS_Gen5_4');
GO

これにより、4 コア搭載の Gen5 ハードウェアに Hyperscale データベースが作成されます。This will create a Hyperscale database on Gen5 hardware with 4 cores.

既存の Azure SQL Database のハイパースケール サービス レベルへの移行Migrate an existing Azure SQL Database to the Hyperscale service tier

既存の Azure SQL データベースをハイパースケールに移行するには、Azure portalT-SQLPowershell、または CLI を使用します。You can move your existing Azure SQL databases to Hyperscale using the Azure portal, T-SQL, Powershell or CLI. 現時点で、これは一方向にしか移行できません。At this time, this is a one-way migration. データのエクスポートとインポート以外の方法で、Hyperscale から別のサービス レベルにデータベースを移動することはできません。You can't move databases from Hyperscale to another service tier, other than by exporting and importing data. 概念実証 (POC) のために、運用データベースのコピーを作成して、コピーを Hyperscale に移行することをお勧めします。For proofs of concept (POCs), we recommend making a copy of your production databases, and migrating the copy to Hyperscale. 既存の Azure SQL データベースの Hyperscale レベルへの移行は、データ サイズに左右される操作です。Migrating an existing Azure SQL database to the Hyperscale tier is a size of data operation.

次の T-SQL コマンドによってデータベースがハイパースケール サービス レベルに移行されます。The following T-SQL command moves a database into the Hyperscale service tier. ALTER DATABASE ステートメントにエディションとサービス目標の両方を指定する必要があります。You must specify both the edition and service objective in the ALTER DATABASE statement.

-- Alter a database to make it a HyperScale Database
ALTER DATABASE [DB2] MODIFY (EDITION = 'HyperScale', SERVICE_OBJECTIVE = 'HS_Gen5_4');
GO

ハイパースケール データベースの読み取りスケールへの接続Connect to a read-scale replica of a Hyperscale database

ハイパースケール データベースでは、クライアントによって提供された接続文字列の ApplicationIntent 引数により、接続が書き込みレプリカと読み取り専用セカンダリ レプリカのどちらにルーティングされるかが指定されます。In HyperScale databases, the ApplicationIntent argument in the connection string provided by the client dictates whether the connection is routed to the write replica or to a read-only secondary replica. ApplicationIntentREADONLY に設定され、データベースにセカンダリ レプリカがない場合、接続はプライマリ レプリカにルーティングされ、既定で ReadWrite の動作になります。If the ApplicationIntent set to READONLY and the database does not have a secondary replica, connection will be routed to the primary replica and defaults to ReadWrite behavior.

-- Connection string with application intent
Server=tcp:<myserver>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadOnly;User ID=<myLogin>;Password=<myPassword>;Trusted_Connection=False; Encrypt=True;

ハイパースケールのセカンダリ レプリカはすべて同じであり、プライマリ レプリカと同じサービス レベル目標が使用されます。Hyperscale secondary replicas are all identical, using the same Service Level Objective as the primary replica. 複数のセカンダリ レプリカが存在する場合、ワークロードは使用可能なすべてのセカンダリ レプリカに分散されます。If more than one secondary replica is present, the workload is distributed across all available secondaries. 各セカンダリ レプリカは個別に更新されるため、レプリカごとに、プライマリ レプリカに対して異なるデータ遅延が生じる可能性があります。Each secondary replica is updated independently, thus different replicas could have different data latency relative to the primary replica.

ハイパースケールでのデータベースの高可用性Database High Availability in Hyperscale

他のすべてのサービス レベルと同様に、Hyperscale は、コンピューティング レプリカの可用性に関係なく、コミットされたトランザクションのデータの持続性を保証します。As in all other service tiers, Hyperscale guarantees data durability for committed transactions regardless of compute replica availability. プライマリ レプリカが使用できなくなったことによるダウンタイムの程度は、フェールオーバーの種類 (計画されたものと計画外のもの)、および少なくとも 1 つのセカンダリ レプリカの存在に左右されます。The extent of downtime due to the primary replica becoming unavailable depends on the type of failover (planned vs. unplanned), and on the presence of at least one secondary replica. 計画フェールオーバー (つまりメンテナンス イベント) では、システムはフェールオーバーを開始する前に新しいプライマリ レプリカを作成するか、既存のセカンダリ レプリカをフェールオーバーのターゲットとして使用します。In a planned failover (i.e. a maintenance event), the system either creates the new primary replica before initiating a failover, or uses an existing secondary replica as the failover target. 計画外のフェールオーバー (つまりプライマリ レプリカでのハードウェア障害) では、システムはセカンダリ レプリカが存在する場合はこれをフェールオーバーのターゲットとして使用し、あるいは使用可能なコンピューティング能力のプールから新しいプライマリ レプリカを作成します。In an unplanned failover (i.e. a hardware failure on the primary replica), the system uses a secondary replica as a failover target if one exists, or creates a new primary replica from the pool of available compute capacity. 後者の場合、新しいプライマリ レプリカの作成に必要な追加の手順により、ダウンタイムの期間が長くなります。In the latter case, downtime duration is longer due to extra steps required to create the new primary replica.

Hyperscale の SLA については、「SLA for Azure SQL Database の SLA」を参照してください。For Hyperscale SLA, see SLA for Azure SQL Database.

Hyperscale データベースのディザスター リカバリーDisaster Recovery for Hyperscale Databases

Hyperscale データベースを別の地理的な場所に復元するRestoring a Hyperscale database to a different geography

ディザスター リカバリー操作の一環として、またはドリル、再配置などの他の理由で、Azure SQL Database Hyperscale DB を、現在ホストされているリージョン以外のリージョンに復元する必要がある場合、主な方法として、データベースの geo リストアを実行します。If you need to restore an Azure SQL Database Hyperscale DB to a region other than the one it is currently hosted in, as part of a disaster recovery operation or drill, relocation, or any other reason, the primary method is to do a geo-restore of the database. これには、他の AZURE SQL DB を別のリージョンに復元するときとまったく同じ手順が含まれます。This involves exactly the same steps as what you would use to restore any other AZURE SQL DB to a different region:

  1. ターゲット リージョンにまだ適切なサーバーが存在しない場合は、そこに SQL Database サーバーを作成します。Create a SQL Database server in the target region if you do not already have an appropriate server there. このサーバーは、元の (ソース) サーバーと同じサブスクリプションが所有する必要があります。This server should be owned by the same subscription as the original (source) server.
  2. 自動バックアップからの Azure SQL データベースの復元に関するページの「geo リストア」トピックにある手順に従ってください。Follow the instructions in the geo-restore topic of the page on restoring Azure SQL Databases from automatic backups.

注意

ソースとターゲットが別々のリージョンにあるため、データベースは、geo リストア以外と同様に、スナップショット ストレージをソース データベースと共有することができません。これは、非常に短時間で完了します。Because the source and target are in separate regions, the database cannot share snapshot storage with the source database as in non-geo restores, which complete extremely quickly. Hyperscale データベースの geo リストアの場合、ターゲットが geo レプリケーション ストレージのペア リージョンにある場合でも、データのサイズに関連した操作になります。In the case of a geo-restore of a Hyperscale database, it will be a size-of-data operation, even if the target is in the paired region of the geo-replicated storage. つまり、geo リストアを実行すると、復元されるデータベースのサイズに比例した時間がかかります。That means that doing a geo-restore will take time proportional to the size of the database being restored. ターゲットがペア リージョンにある場合、コピーはデータセンター内にあり、インターネット経由の遠距離コピーよりもかなり高速ですが、それでもすべてのビットがコピーされます。If the target is in the paired region, the copy will be within a datacenter, which will be significantly faster than a long distance copy over the internet, but it will still copy all of the bits.

対応リージョンAvailable regions

現在、Azure SQL Database Hyperscale レベルは次のリージョンで使用できます。The Azure SQL Database Hyperscale tier is currently available in the following regions:

  • オーストラリア東部Australia East
  • オーストラリア南東部Australia Southeast
  • ブラジル南部Brazil South
  • カナダ中部Canada Central
  • 米国中部Central US
  • 中国東部 2China East 2
  • 中国北部 2China North 2
  • 東アジアEast Asia
  • East USEast US
  • 米国東部 2East Us 2
  • フランス中部France Central
  • 東日本Japan East
  • 西日本Japan West
  • 韓国中部Korea Central
  • 韓国南部Korea South
  • 米国中北部North Central US
  • 北ヨーロッパNorth Europe
  • 南アフリカ北部South Africa North
  • 米国中南部South Central US
  • 東南アジアSoutheast Asia
  • 英国南部UK South
  • 英国西部UK West
  • 西ヨーロッパWest Europe
  • 米国西部West US
  • 米国西部 2West US 2

サポート対象として掲載されていないリージョンに Hyperscale データベースを作成したい場合は、Azure portal 経由でオンボード要求を送信できます。If you want to create Hyperscale database in a region that is not listed as supported, you can send an onboarding request via Azure portal. サポート対象リージョンの一覧は随時更新されているため、最新のリージョンの一覧を確認してください。We are working to expand the list of supported regions so please check back for latest region list.

掲載されていないリージョンに Hyperscale データベースを作成できるように要求するには:To request the ability to create Hyperscale databases in regions not listed:

  1. Azure の [ヘルプとサポート] ブレードに移動しますNavigate to Azure Help and Support Blade

  2. [新しいサポート リクエスト] をクリックしますClick on New support request

    Azure の [ヘルプとサポート] ブレード

  3. [問題の種類] で、 [サービスとサブスクリプションの制限 (クォータ)] を選択しますFor Issue Type, select Service and subscription limits (quotas)

  4. データベースの作成に使用するサブスクリプションを選択しますChoose the subscription you would use to create the database(s)

  5. [クォータの種類] で、 [SQL データベース] を選択しますFor Quota Type, select SQL database

  6. [次へ: ソリューション] をクリックしますClick Next: Solutions

  7. [詳細の指定] をクリックしますClick Provide Details

    問題の詳細

  8. [SQL Database のクォータの種類][その他のクォータ要求] を選択しますChoose SQL Database quota type: Other quota request

  9. 次のテンプレートを入力します。Fill in the following template:

    クォータの詳細

    テンプレートで、以下の情報を指定しますIn the template, provide the following information

    新しいリージョンで Azure Hyperscale SQL Database を作成するための要求Request to create Azure Hyperscale SQL Database in a new region
    リージョン: [要求対象のリージョンを入力]Region: [Fill in your requested region]
    コンピューティング SKU/コア総数 (読み取り可能なレプリカを含む)Compute SKU/total cores including readable replicas
    推定 TB 数Number of TB estimated

  10. [重要度 C] を選択します。Choose Severity C

  11. 適切な連絡方法を選択し、詳細を入力します。Choose the appropriate contact method and fill in details.

  12. [保存][続行] の順にクリックしますClick Save and Continue

既知の制限事項Known limitations

以下は、一般提供時点の Hyperscale サービス レベルに対する現在の制限事項です。These are the current limitations to the Hyperscale service tier as of GA. これらの制限事項ができるだけなくなるように、積極的に取り組んでいます。We are actively working to remove as many of these limitations as possible.

問題Issue 説明Description
[バックアップの管理] ウィンドウに、ハイパースケール データベースが表示されません。"SQL server" でフィルター処理すると表示されます。The Manage Backups pane for a logical server does not show Hyperscale databases will be filtered from SQL server ハイパースケールは別の方法でバックアップを管理しています。そのため、長期的な保有期間と特定の時点のバックアップなどの保有設定が適用されず、無効になります。Hyperscale has a separate method for managing backups, and as such the Long-Term Retention and Point in Time backup Retention settings do not apply / are invalidated. したがって、ハイパースケールのデータベースは、[バックアップの管理] ウィンドウに表示されません。Accordingly, Hyperscale databases do not appear in the Manage Backup pane.
ポイントインタイム リストアPoint-in-time restore データベースがハイパースケール サービス レベルに移行された後で、移行よりも前の特定の時点への復元はサポートされません。Once a database is migrated into the Hyperscale service tier, restore to a point-in-time prior to the migration is not supported.
Hyperscale 以外の DB と Hypserscale の間での復元Restore of non-Hyperscale DB to Hypserscale and vice-versa Hyperscale データベースを Hyperscale 以外のデータベースに復元することも、Hyperscale 以外のデータベースを Hyperscale データベースに復元することもできません。You cannot restore a Hyperscale database into a non-Hyperscale database, nor can you restore a non-Hyperscale database into a Hyperscale database.
1 TB を超えるデータ ファイルがデータベースに 1 つ以上ある場合、移行に失敗します。If a database has one or more data files larger than 1 TB, migration fails 場合によっては、サイズの大きいファイルを 1 TB 未満に圧縮することで、この問題を回避できることがあります。In some cases, it may be possible to work around this issue by shrinking the large files to be less than 1 TB. 移行プロセス中に使用されているデータベースを移行する場合は、1 TB を超えるファイルがないことを確認してください。If migrating a database being used during the migration process, make sure that no file gets larger than 1 TB. データベース ファイルのサイズを確認するには、以下のクエリを使用してください。Use the following query to determine the size of database files. SELECT *, name AS file_name, size * 8. / 1024 / 1024 AS file_size_GB FROM sys.database_files WHERE type_desc = 'ROWS';SELECT *, name AS file_name, size * 8. / 1024 / 1024 AS file_size_GB FROM sys.database_files WHERE type_desc = 'ROWS';
マネージド インスタンスManaged Instance Azure SQL Database Managed Instance は、現在、Hyperscale データベースではサポートされていません。Azure SQL Database Managed Instance is not currently supported with Hyperscale databases.
エラスティック プールElastic Pools エラスティック プールは、現在、SQL Database Hyperscale ではサポートされていません。Elastic Pools are not currently supported with SQL Database Hyperscale.
ハイパースケールへの移行は現在一方向Migration to Hyperscale is currently a one-way operation データベースがハイパースケールにいったん移行されると、ハイパースケール以外のサービス レベルに直接移行することはできません。Once a database is migrated to Hyperscale, it cannot be migrated directly to a non-Hyperscale service tier. 現時点では、ハイパースケールからハイパースケール以外にデータベースを移行する唯一の方法は、BACPAC ファイルまたはその他のデータ移動テクノロジ (一括コピー、Azure Data Factory、Azure Databricks、SSIS など) を使用してエクスポート/インポートすることです。At present, the only way to migrate a database from Hyperscale to non-Hyperscale is to export/import using a BACPAC file or other data movement technologies (Bulk Copy, Azure Data Factory, Azure Databricks, SSIS, etc.)
永続メモリ内オブジェクトを含むデータベースの移行Migration of databases with persistent in-memory objects ハイパースケールでは、非永続メモリ内オブジェクト (テーブル型、ネイティブ SP、関数) のみがサポートされます。Hyperscale only supports non persistent In-Memory objects (table types, native SPs and functions). データベースがハイパースケール サービス レベルに移行される前に、永続メモリ内テーブルとその他のオブジェクトは削除され、メモリ内ではないオブジェクトとして再作成されます。Persistent In-Memory tables and other objects must be dropped and recreated as non-In-Memory objects before migrating a database to the Hyperscale service tier.
変更の追跡Change Tracking 現時点では、Azure SQL Hyperscale データベースを使用して Change Tracking を構成および使用することはできません。You cannot yet configure and use Change Tracking with Azure SQL Hyperscale databases.
geo レプリケーションGeo Replication Azure SQL Database Hyperscale の geo レプリケーションは、まだ構成できません。You cannot yet configure geo-replication for Azure SQL Database Hyperscale.
データベース コピーDatabase Copy 現時点では、データベース コピーを使用して、Azure SQL Hyperscale に新しいデータベースを作成することはできません。You cannot yet use Database Copy to create a new database in Azure SQL Hyperscale.
TDE/AKV の統合TDE/AKV Integration Azure Key Vault を使用した透過的データベース暗号化 (通常、Bring Your Own Key (BYOK) と呼ばれます) は、Azure SQL Database Hyperscale ではまだサポートされていませんが、サービス マネージド キーを使用した TDE は完全にサポートされています。Transparent Database Encryption using Azure Key Vault (commonly referred to as Bring-Your-Own-Key or BYOK) is not yet supported for Azure SQL Database Hyperscale, however TDE with Service Managed Keys is fully supported.
インテリジェント データベース機能Intelligent Database Features [Force Plan] オプションを除き、他のすべての自動チューニング オプションは Hyperscale ではまだサポートされていません。オプションは有効になっているように見えますが、推奨事項やアクションは実行されません。With the exception of the "Force Plan" option, all other Automatic tuning options are not yet supported on Hyperscale: options may appear to be enabled, but there won't be any recommendations or actions made.

次の手順Next steps