Azure SQL ハイパースケール データベースに関する FAQFAQ about Azure SQL Hyperscale databases

この記事では、Azure SQL Database ハイパースケール サービス レベルのデータベース (通常はハイパースケール データベースと呼ばれる) をご検討中のお客様向けに、よく寄せられる質問の回答を紹介します。This article provides answers to frequently asked questions for customers considering a database in the Azure SQL Database Hyperscale service tier, commonly called a Hyperscale database. この記事では、ハイパースケールでサポートするシナリオを示し、一般的に機能間サービスが SQL Database ハイパースケールと互換性があることを説明します。This article describes the scenarios that Hyperscale supports and the cross-feature services are compatible with SQL Database Hyperscale in general.

  • この FAQ は、ハイパースケール サービス レベルの概要を理解し、具体的な質問や懸案事項の回答を求める読者を対象としています。This FAQ is intended for readers who have a brief understanding of the Hyperscale service tier and are looking to have their specific questions and concerns answered.
  • この FAQ はガイドブックではなく、SQL Database ハイパースケールの使用方法に関する質問に回答するものでもありません。This FAQ isn’t meant to be a guidebook or answer questions on how to use a SQL Database Hyperscale database. そのような場合は、Azure SQL Database ハイパースケールに関する記事をご覧ください。For that, we recommend you refer to the Azure SQL Database Hyperscale documentation.

一般的な質問General questions

ハイパースケール データベースとはWhat is a Hyperscale database

ハイパースケール データベースとは、ハイパースケール スケールアウト ストレージ テクノロジによって支えられている、ハイパースケール サービス レベルの Azure SQL データベースです。A Hyperscale database is an Azure SQL database in the Hyperscale service tier that is backed by the Hyperscale scale-out storage technology. ハイパースケール データベースは最大 100 TB のデータをサポートし、高いスループットとパフォーマンスを実現すると同時に、ワークロード要件に適応するために迅速にスケーリングできます。A Hyperscale database supports up to 100 TB of data and provides high throughput and performance, as well as rapid scaling to adapt to the workload requirements. スケーリングは、アプリケーションにとって透過的に行われます。接続やクエリ処理などは他のすべての SQL データベースと変わりません。Scaling is transparent to the application – connectivity, query processing, and so on, work like any other SQL database.

ハイパースケールをサポートするリソースの種類と購入モデルWhat resource types and purchasing models support Hyperscale

ハイパースケール サービス レベルを利用できるのは、Azure SQL データベース において仮想コアベースの購入モデルを使用する単一のデータベースのみです。The Hyperscale service tier is only available for single databases using the vCore-based purchasing model in Azure SQL Database.

ハイパースケール サービス レベルと General Purpose サービス レベルおよび Business Critical サービス レベルとの違いHow does the Hyperscale service tier differ from the General Purpose and Business Critical service tiers

仮想コア ベースのサービス レベルは、主に、可用性、ストレージの種類、IOP に基づいて区別されます。The vCore-based service tiers are primarily differentiated based upon availability, storage type and IOPs.

  • General Purpose サービス レベルは、ほとんどのビジネス ワークロードに適しています。IO 待ち時間またはフェールオーバー回数が最優先ではない場合に、コンピューティングとストレージのオプションのバランスが取れた組み合わせを提供します。The General Purpose service tier is appropriate for most business workloads, offering a balanced set of compute and storage options where IO latency or failover times are not the priority.
  • ハイパースケール サービス レベルは、非常に大規模なデータベース ワークロードに対して最適化されています。The Hyperscale service tier is optimized for very large database workloads.
  • Business Critical サービス レベルは、IO 待ち時間が最優先されるビジネス ワークロードに適しています。The Business Critical service tier is appropriate for business workloads where IO latency is a priority.
リソースの種類Resource type 汎用General Purpose ハイパースケールHyperscale Business CriticalBusiness Critical
最適な用途Best for AllAll ほとんどのビジネス ワークロード。Most business workloads. 予算重視のバランスの取れたコンピューティングおよびストレージ オプションを提供します。Offers budget oriented balanced compute and storage options. 大きなデータ容量要件のデータ アプリケーション、および柔軟性の高いストレージの自動スケーリングとコンピューティングのスケーリングの機能。Data applications with large data capacity requirements and the ability to auto-scale storage and scale compute fluidly. トランザクション レートが高く、待ち時間 IO が最低のOLTP アプリケーション。OLTP applications with high transaction rate and lowest latency IO. 分離された複数のレプリカを使用して、最高の耐障害性が提供されます。Offers highest resilience to failures using several, isolated replicas.
リソースの種類Resource type 単一データベース/エラスティック プール/マネージド インスタンスSingle database / elastic pool / managed instance 単一データベースSingle database 単一データベース/エラスティック プール/マネージド インスタンスSingle database / elastic pool / managed instance
コンピューティング サイズCompute size 単一データベース/エラスティック プール *Single database / elastic pool * 1 - 80 の仮想コア1 to 80 vCores 1 - 80 の仮想コア *1 to 80 vCores* 1 - 80 の仮想コア1 to 80 vCores
マネージド インスタンスManaged instance 8、16、24、32、40、64、80 の仮想コア8, 16, 24, 32, 40, 64, 80 vCores 該当なしN/A 8、16、24、32、40、64、80 の仮想コア8, 16, 24, 32, 40, 64, 80 vCores
ストレージの種類Storage type AllAll Premium リモート ストレージ (インスタンスあたり)Premium remote storage (per instance) ローカル SSD キャッシュを使用して切り離したストレージ (インスタンスあたり)De-coupled storage with local SSD cache (per instance) 超高速ローカル SSD ストレージ (インスタンスあたり)Super-fast local SSD storage (per instance)
ストレージ サイズStorage size 単一データベース/エラスティック プールSingle database / elastic pool 5 GB – 4 TB5 GB – 4 TB 最大 100 TBUp to 100 TB 5 GB – 4 TB5 GB – 4 TB
マネージド インスタンスManaged instance 32 GB – 8 TB32 GB – 8 TB 該当なしN/A 32 GB – 4 TB32 GB – 4 TB
IO スループットIO throughput 単一データベース **Single database** 仮想コアあたり 500 IOPS (最大 7000 IOPS)500 IOPS per vCore with 7000 maximum IOPS 現在不明Unknown yet 5000 IOPS (最大 200,000 IOPS)5000 IOPS with 200,000 maximum IOPS
マネージド インスタンスManaged instance ファイル サイズに依存Depends on size of file 該当なしN/A Managed Instance:ファイル サイズに依存Managed Instance: Depends on size of file
可用性Availability AllAll 1 レプリカ、読み取りスケールなし、ローカル キャッシュなし1 replica, no read-scale, no local cache 複数のレプリカ、最大 15 の読み取りスケール、部分的ローカル キャッシュMultiple replicas, up to 15 read-scale, partial local cache 3 レプリカ、1 読み取りスケール、ゾーン冗長 HA、完全ローカル キャッシュ3 replicas, 1 read-scale, zone-redundant HA, full local cache
バックアップBackups AllAll RA-GRS、7 ~ 35 日 (既定では 7 日)RA-GRS, 7-35 days (7 days by default) RA-GRS、7 から 35 日 (既定では 7 日)、一定時間で特定の時点に復旧 (PITR)RA-GRS, 7-35 days (7 days by default), constant time point-in-time recovery (PITR) RA-GRS、7 ~ 35 日 (既定では 7 日)RA-GRS, 7-35 days (7 days by default)

*エラスティック プールはハイパースケール サービス レベルではサポートされていません。* Elastic pools not supported in the Hyperscale service tier

ハイパースケール サービス レベルを使用する必要があるユーザーWho should use the Hyperscale service tier

ハイパースケール サービス レベルの対象として主に意図されているのは、大規模なオンプレミスの SQL Server データベースを持っていて、クラウドに移行することによってアプリケーションを最新化することを考えているお客様、または既に Azure SQL Database を使用しており、データベースのサイズを増大するために大幅な拡張を望むお客様です。The Hyperscale service tier is primarily intended for customers who have large on-premises SQL Server databases and want to modernize their applications by moving to the cloud or for customers who are already using Azure SQL Database and want to significantly expand the potential for database growth. ハイパースケールでは、高いパフォーマンスと高いスケーラビリティを必要としているお客様も対象になります。Hyperscale is also intended for customers who seek both high performance and high scalability. ハイパースケールで得られるのは次のとおりです。With Hyperscale, you get:

  • 最大 100 TB のデータベース サイズのサポートSupport for up to 100 TB of database size
  • データベース サイズにかかわらないデータベースの高速バックアップ (ファイル スナップショットに基づいたバックアップ)Fast database backups regardless of database size (backups are based on file snapshots)
  • データベース サイズにかかわらないデータベースの高速復元 (ファイル スナップショットに基づいた復元)Fast database restores regardless of database size (restores are from file snapshots)
  • ログ スループットの向上によるデータベースのサイズにかかわらないトランザクション コミット時間の短縮Higher log throughput results in fast transaction commit times regardless of database size
  • 1 つ以上の読み取り専用ノードへの読み取りスケールアウト (読み取りワークロードのオフロードやホット スタンバイに対応)Read scale out to one or more read-only nodes to offload your read workload, and for hot-standbys.
  • コンピューティングの一定時間での迅速なスケールアップ (重いワークロードに対応するために性能を向上) と、その後の一定時間でのスケールダウン。Rapid scale up of compute, in constant time, to be more powerful to accommodate the heavy workload and then scale down, in constant time. これは、たとえば P6 から P11 でのスケール アップとスケール ダウンに似ていますが、さらに迅速に行われます。データ操作の規模ではないためです。This is similar to scaling up and down between a P6 to a P11, for example, but much faster as this is not a size of data operation.

現在ハイパースケールをサポートしているリージョンWhat regions currently support Hyperscale

Azure SQL Database の Hyperscale レベルは現在、Azure SQL Database の Hyperscale の概要に関するページに列挙されているリージョンで利用可能です。The Azure SQL Database Hyperscale tier is currently available in the regions listed under Azure SQL Database Hyperscale Overview.

論理サーバーごとに複数のハイパースケール データベースを作成できるかCan I create multiple Hyperscale databases per logical server

はい。Yes. 論理サーバーあたりのハイパースケール データベース数の詳細や制約について詳しくは、「SQL Database resource limits for single and pooled databases on a logical server」(論理サーバー上の単一データベースおよびプールされたデータベースの SQL Database のリソース制限) をご覧ください。For more information and limits on the number of Hyperscale databases per logical server, see SQL Database resource limits for single and pooled databases on a logical server.

ハイパースケール データベースのパフォーマンス特性とはWhat are the performance characteristic of a Hyperscale database

SQL Database ハイパースケール アーキテクチャは、大きなデータベース サイズをサポートする一方で高いパフォーマンスとスループットを提供します。The SQL Database Hyperscale architecture provides high performance and throughput while supporting large database sizes.

ハイパースケール データベースのスケーラビリティとはWhat is the scalability of a Hyperscale database

SQL Database ハイパースケールでは、ワークロードの需要に基づいて迅速なスケーラビリティを提供します。SQL Database Hyperscale provides rapid scalability based on your workload demand.

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

    ハイパースケールでは、CPU やメモリなどリソースの観点で主要なコンピューティング サイズをスケールアップしてから、一定時間でスケールダウンできます。With Hyperscale, you can scale up the primary compute size in terms of resources like CPU, memory and then scale down, in constant time. ストレージは共有されるため、スケールアップとスケールダウンはデータ操作の規模ではありません。Because the storage is shared, scaling up and scaling down is not a size of data operation.

  • スケールイン/スケールアウトScaling In/Out

    ハイパースケールでは、読み取り要求を処理するために使用できる 1 つ以上の追加計算ノードをプロビジョニングする機能も提供されます。With Hyperscale, you also get the ability to provision one or more additional compute nodes that you can use to serve your read requests. つまり、これらの追加計算ノードを読み取り専用ノードとして使用し、主なコンピューティングから読み取りワークロードをオフロードできます。This means that you can use these additional compute nodes as read-only nodes to offload your read workload from the primary compute. 読み取り専用だけではなく、これらのノードは、プライマリからフェールオーバーする際のホット スタンバイとしても利用できます。In addition to read-only, these nodes also serve as hot-standby’s in the event of a fail over from the primary.

    これらの追加計算ノードそれぞれのプロビジョニングは、オンライン操作であり、一定時間で行うことができます。Provisioning of each of these additional compute nodes can be done in constant time and is an online operation. これらの追加読み取り専用計算ノードに接続するには、接続文字列の ApplicationIntent 引数を read_only に設定してください。You can connect to these additional read-only compute nodes by setting the ApplicationIntent argument on your connection string to read_only. read-only がマークされたすべての接続は、追加読み取り専用計算ノードのいずれかに自動的にルーティングされます。Any connections marked with read-only are automatically routed to one of the additional read-only compute nodes.

具体的な質問Deep dive questions

1 つの論理サーバー上でハイパースケールと単一データベースを混在できるかCan I mix Hyperscale and single databases in a single logical server

はい、できます。Yes, you can.

ハイパースケールのためにアプリケーション プログラミング モデルを変更する必要があるかDoes Hyperscale require my application programming model to change

いいえ。アプリケーション プログラミング モデルはそのままでかまいません。No, your application programming model stays as is. いつもの接続文字列とその他の通常モードを使用して、Azure SQL データベースを操作します。You use your connection string as usual and the other regular modes to interact with your Azure SQL database.

どのトランザクション分離レベルが SQL Database ハイパースケール データベースで既定になるかWhat transaction isolation levels are going to be default on SQL Database Hyperscale database

プライマリ ノードでは、トランザクション分離レベルは RCSI (Read Committed スナップショット分離) です。On the primary node, the transaction isolation level is RCSI (Read Committed Snapshot Isolation). 読み取りスケールのセカンダリ ノードでは、分離レベルはスナップショットです。On the read scale secondary nodes, the isolation level is Snapshot.

オンプレミスまたは IaaS SQL Server ライセンスを SQL Database ハイパースケールで使用できるかCan I bring my on-premises or IaaS SQL Server license to SQL Database Hyperscale

はい。Azure ハイブリッド特典をハイパースケールで利用できます。Yes, Azure Hybrid Benefit is available for Hyperscale. SQL Server Standard コアそれぞれを 1 つのハイパースケール仮想コアにマップできます。Every SQL Server Standard core can map to 1 Hyperscale vCores. SQL Server Enterprise コアそれぞれを 4 つのハイパースケール仮想コアにマップできます。Every SQL Server Enterprise core can map to 4 Hyperscale vCores. セカンダリ レプリカの SQL ライセンスは不要です。You don’t need a SQL license for secondary replicas. Azure ハイブリッド特典の価格が読み取りスケール (セカンダリ) レプリカに自動的に適用されます。The Azure Hybrid Benefit price will be automatically applied to read-scale (secondary) replicas.

SQL Database ハイパースケールはどのようなワークロードを対象としているかWhat kind of workloads is SQL Database Hyperscale designed for

SQL Database ハイパースケールはすべての SQL Server ワークロードをサポートしますが、主に OLTP 用に最適化されています。SQL Database Hyperscale supports all SQL Server workloads, but it is primarily optimized for OLTP. ハイブリッド (HTAP) および分析 (データ マート) のワークロードにも対応できます。You can bring Hybrid (HTAP) and Analytical (data mart) workloads as well.

Azure SQL Data Warehouse と SQL Database ハイパースケールのどちらを選ぶべきかHow can I choose between Azure SQL Data Warehouse and SQL Database Hyperscale

現在、SQL Server をデータ ウェアハウスとして使用して対話型分析クエリを実行している場合、SQL Database ハイパースケールがオプションとして優れています。比較的小さなデータ ウェアハウス (数 TB から最大でも数十 TB) をホスティングするコストを抑えることができ、T-SQL コードを変更せずにデータ ウェアハウス ワークロードを SQL Database ハイパースケールに移行できます。If you are currently running interactive analytics queries using SQL Server as a data warehouse, SQL Database Hyperscale is a great option because you can host relatively small data warehouses (such as a few TB up to 10’s of TB) at a lower cost and you can migrate your data warehouse workload to SQL Database Hyperscale without T-SQL code changes.

Parallel Data Warehouse (PDW)、Teradata、またはその他の超並列プロセッサー (MPP) データ ウェアハウスを使用して、複雑なクエリで大規模にデータ分析を実行している場合は、SQL Data Warehouse が最適な選択肢となるでしょう。If you are running data analytics on a large scale with complex queries and using Parallel Data Warehouse (PDW), Teradata or other Massively Parallel Processor (MPP)) data warehouses, SQL Data Warehouse may be the best choice.

SQL Database ハイパースケールのコンピューティングに関する質問SQL Database Hyperscale compute questions

コンピューティングをいつでも一時停止できるかCan I pause my compute at any time

現時点ではできませんが、コンピューティングとレプリカの数をスケールダウンして、ピーク時以外のコストを削減することができます。Not at this time, however you can scale your compute and number of replicas down to reduce cost during non-peak times.

メモリ集中型ワークロードのために RAM を増やしてコンピューティングをプロビジョニングできるかCan I provision a compute with extra RAM for my memory-intensive workload

いいえ。No. RAM を増やすには、コンピューティング サイズをアップグレードして上げる必要があります。To get more RAM, you need to upgrade to a higher compute size. 詳しくは、ハイパースケールのストレージ サイズおよびコンピューティング サイズをご覧ください。For more information, see Hyperscale storage and compute sizes.

サイズが違う複数の計算ノードをプロビジョニングできるかCan I provision multiple compute nodes of different sizes


サポートされる読み取りスケール レプリカの数How many read-scale replicas are supported

ハイパースケール データベースは、既定で 1 つの読み取りスケール レプリカを含むように作成されます (合計 2 つのレプリカ)。The Hyperscale databases are created with one read-scale replica (two replicas in total) by default. Azure portalT-SQLPowerShell または CLI を使用して、読み取り専用のレプリカの数を 0 から 4 の間でスケールすることができます。You can scale the number of read-only replicas between 0 and 4 using the Azure portal, T-SQL, Powershell or CLI..

高可用性のために追加の計算ノードをプロビジョニングできるかFor high availability, do I need to provision additional compute nodes

ハイパースケール データベースでは、回復性はストレージ レベルで提供されます。In Hyperscale databases, the resiliency is provided at the storage level. 回復性を実現するために必要なのは 1 つのレプリカだけです。You only need one replica to provide resiliency. コンピューティング レプリカが停止すると、新しいレプリカが自動的に作成されるためデータは失われません。When the compute replica is down, a new replica is created automatically with no data loss.

ただし、レプリカが 1 つしかない場合は、フェールオーバー後に新しいレプリカにローカル キャッシュを構築するために少し時間がかかることがあります。However, if there’s only one replica, it may take some time to build the local cache in the new replica after failover. キャッシュ再構築フェーズで、データベースはページ サーバーからデータを直接フェッチするため、IOPS とクエリのパフォーマンスが低下します。During the cache rebuild phase, the database fetches data directly from the page servers, resulting in degraded IOPS and query performance.

高可用性を必要とするミッション クリティカル アプリケーションでは、プライマリ計算ノード (既定) を含めて少なくとも 2 つの計算ノードをプロビジョニングする必要があります。For mission-critical apps that require high availability, you should provision at least 2 compute nodes including the primary compute node (default). そうすることで、フェールオーバー時のホットスタンバイを用意できます。That way there is a hot-standby available in the case of a failover.

データ サイズとストレージに関する質問Data size and storage questions

SQL Database ハイパースケールでサポートされる最大データベース サイズとはWhat is the max db size supported with SQL Database Hyperscale

100 TB100 TB

ハイパースケールでのトランザクション ログのサイズとはWhat is the size of the transaction log with Hyperscale

ハイパースケールでのトランザクション ログは実質的に無制限です。The transaction log with Hyperscale is practically infinite. ログ スループットが高いシステム上では、ログ領域の不足を心配する必要はありません。You do not need to worry about running out of log space on a system that has a high log throughput. ただし、高いワークロードが継続する場合にはログ生成速度が調整される可能性があります。However, the log generation rate might be throttled for continuous aggressive workloads. ピークが持続するログ生成速度は、約 100 MB/秒です。The peak sustained log generation rate is approximately 100 MB/sec.

データベースのサイズ増大につれて一時データベースをスケーリングできるかDoes my temp db scale as my database grows

tempdb データベースはローカル SSD ストレージに配置され、プロビジョニングするコンピューティング サイズに基づいて構成されます。Your tempdb database is located on local SSD storage and is configured based on the compute size that you provision. tempdb は、最大のパフォーマンス メリットを得られるように最適化およびレイアウトされています。Your tempdb is optimized and laid out to provide maximum performance benefits. tempdb サイズを構成することはできません。これは記憶域サブシステムによって管理されます。The tempdb size is not configurable and is managed for you by storage sub-system.

データベース サイズが自動的に拡張されるか、データ ファイルのサイズを自分で管理する必要があるかDoes my database size automatically grow, or do I have to manage the size of the data files

データベースのサイズは、データの挿入/取り込みに応じて自動的に拡大します。Your database size automatically grows as you insert/ingest more data.

SQL Database ハイパースケールでサポートされる最小データベース サイズ (ハイパースケールを使用開始できる最小サイズ) とはWhat is the smallest database size that SQL Database Hyperscale supports or starts with

10 GB10 GB

データベースのサイズが拡張される単位とはIn what increments does my database size grow

1 GB1 GB

SQL Database ハイパースケールのストレージはローカルかリモートかIs the storage in SQL Database Hyperscale local or remote

ハイパースケールでは、データ ファイルは Azure Standard ストレージに格納されます。In Hyperscale, data files are stored in Azure standard storage. 計算ノードに近いマシンでは、データは重点的にローカル SSD ストレージにキャッシュされます。Data is heavily cached on local SSD storage, on machines close to the compute nodes. さらに、計算ノードは、ローカル SSD とメモリ内 (バッファ プールなど) にキャッシュを持ち、リモート ノードからデータをフェッチする回数を減らします。In addition, compute nodes have a cache on local SSD and in-memory (Buffer Pool, and so on), to reduce the frequency of fetching data from remote nodes.

ハイパースケールを使用してファイルまたはファイルグループを管理または定義できるかCan I manage or define files or filegroups with Hyperscale


データベースのデータ増加にハード キャップをプロビジョニングできるかCan I provision a hard cap on the data growth for my database


SQL Database ハイパースケールではどのようにデータ ファイルがレイアウトされるかHow are data files laid out with SQL Database Hyperscale

データ ファイルはページ サーバーによって制御されます。The data files are controlled by page servers. データ サイズが大きくなると、データ ファイルと関連するページ サーバー ノードが追加されます。As the data size grows, data files and associated page server nodes are added.

データベースの縮小はサポートされるかIs database shrink supported


データベースの圧縮はサポートされるかIs database compression supported


大きなテーブルのデータを複数のデータ ファイルに分散できるかIf I have a huge table, does my table data get spread out across multiple data files

はい。Yes. 特定のテーブルに関連付けられたデータ ページを、同じファイルグループに含まれる複数のデータ ファイルに分散することができます。The data pages associated with a given table can end up in multiple data files, which are all part of the same filegroup. SQL Server は、比例配分方式を使用してデータをデータ ファイルに均等配置します。SQL Server uses a proportional fill strategy to distribute data over data files.

データの移行に関する質問Data migration questions

既存の Azure SQL データベースをハイパースケール サービス レベルに移行できるかCan I move my existing Azure SQL databases to the Hyperscale service tier

はい。Yes. ハイパースケールには既存の Azure SQL データベースを移行できます。You can move your existing Azure SQL databases to Hyperscale. これは一方向にしか移行できません。This is a one-way migration. ハイパースケールから他のサービス レベルにデータベースを移行することはできません。You can’t move databases from Hyperscale to another service tier. 運用データベースのコピーを作成して、概念実証 (POC) のためにハイパースケールに移行することをお勧めします。We recommend you make a copy of your production databases and migrate to Hyperscale for proof of concepts (POCs).

ハイパースケール データベースを他のエディションに移行できるかCan I move my Hyperscale databases to other editions

いいえ。No. 現時点では、ハイパースケール データベースを別のサービス レベルに移行することはできません。At this time, you can’t move a Hyperscale database to another service tier.

ハイパースケール サービス レベルに移行した後で使えなくなる機能があるかDo I lose any functionality or capabilities after migration to the Hyperscale service tier

はい。Yes. 長期的な保有期間のバックアップを始めとする Azure SQL Database の一部の機能は、まだハイパースケールではサポートされていません。Some of Azure SQL Database features are not supported in Hyperscale yet, including but not limited long term retention backup. ハイパースケールにデータベースを移行した後、これらの機能は動作を停止します。After you migrate your databases to Hyperscale, those features stop working. これらの制限は一時的なものであると想定しています。We expect these limitations to be temporary.

オンプレミスの SQL Server データベースまたは my SQL Server 仮想マシン データベースをハイパースケールに移行できるかCan I move my on-premises SQL Server database or my SQL Server virtual machine database to Hyperscale

はい。Yes. BACPAC、トランザクション レプリケーション、論理データ読み込みなど、既存のすべての移行方法を使用して、ハイパースケールに移行できます。You can use all existing migration technologies to migrate to Hyperscale, including BACPAC, transactional replication, logical data loading. Azure Database Migration Service とは」もご覧ください。See also the Azure Database Migration Service.

オンプレミスまたは仮想マシン環境からハイパースケールへの移行時のダウンタイム、および最小限にするための方法What is my downtime during migration from an on-premises or virtual machine environment to Hyperscale and how can I minimize it

ダウンタイムは、データベースを Azure SQL Database 内の単一データベースに移行する際のダウンタイムと同じです。Downtime is the same as the downtime when you migrate your databases to a single database in Azure SQL Database. トランザクション レプリケーションを使用すると、サイズが数 TB までのデータベースについて移行時のダウンタイムを最小限に抑えることができます。You can use transactional replication to minimize downtime migration for databases up to few TB in size. 特に大規模なデータベース (10 TB 超) の場合は、ADF、Spark、またはその他のデータ移動方法を使用してデータを移行することを検討してください。For very large database (10+ TB), you can consider to migrate data using ADF, Spark, or other data movement technologies.

容量 X のデータを SQL Database ハイパースケールに移行するためにかかる時間How much time would it take to bring in X amount of data to SQL Database Hyperscale

ハイパースケールでは、新しいデータまたは変更されたデータを 100 MB/秒使用できます。Hyperscale is capable of consuming 100 MB/sec of new/changed data.

BLOB ストレージからデータを読み取って高速読み込みできるか (Polybase や SQL Data Warehouse のように)Can I read data from blob storage and do fast load (like Polybase and SQL Data Warehouse)

Azure Storage からデータを読み取り、ハイパースケール データベースに読み込むことができます (通常の単一データベースの場合と同様です)。You can read data from Azure Storage and load data load into a Hyperscale database (just like you can do with a regular single database). Polybase は現在 Azure SQL Database でサポートされていません。Polybase is currently not supported on Azure SQL Database. Polybase を実行するには、Azure Data Factory を使用するか、SQL 用 Spark コネクタを使用して Spark ジョブを Azure Databricks で実行します。You can do Polybase using Azure Data Factory or running a Spark job in Azure Databricks with the Spark connector for SQL. SQL 用の Spark コネクタでは一括挿入がサポートされます。The Spark connector to SQL supports bulk insert.

単純復旧モデルまたは一括ログ記録モデルはハイパースケールではサポートされていません。Simple recovery or bulk logging model is not supported in Hyperscale. 高可用性を実現するには完全復旧モデルが必要です。Full recovery model is required to provide high availability. ただし、ハイパースケールでは、単一の Azure SQL データベースと比較して、新しいログ アーキテクチャのためにデータ取り込み率が向上しています。However, Hyperscale provides a better data ingest rate compared to a single Azure SQL database because of the new log architecture.

SQL Database ハイパースケールは取り込むデータ容量を増やすために複数のノードをプロビジョニングできるかDoes SQL Database Hyperscale allow provisioning multiple nodes for ingesting large amounts of data

いいえ。No. SQL Database ハイパースケールは SMP アーキテクチャです。非対称マルチプロセッシングまたはマルチマスター アーキテクチャではありません。SQL Database Hyperscale is a SMP architecture and is not an asymmetric multiprocessing or a multi-master architecture. 読み取り専用ワークロードをスケールアウトするためには複数のレプリカを作成するしかありません。You can only create multiple replicas to scale out read-only workloads.

SQL Database ハイパースケールへの移行がサポートされる最も古い SQL Server バージョンとはWhat is the oldest SQL Server version will SQL Database Hyperscale support migration from

SQL Server 2005。SQL Server 2005. 詳しくは、「単一データベースまたはプールされたデータベースに移行する」をご覧ください。For more information, see Migrate to a single database or a pooled database. 互換性の問題について詳しくは、「データベース移行に関する互換性の問題の解決」をご覧ください。For compatibility issues, see Resolving database migration compatibility issues.

SQL Database ハイパースケールで他のデータ ソース (Aurora、MySQL、Oracle、DB2、その他のデータベース プラットフォーム) からの移行がサポートされるかDoes SQL Database Hyperscale support migration from other data sources such as Aurora, MySQL, Oracle, DB2, and other database platforms

はい。Yes. SQL Server 以外のさまざまなデータ ソースから移行するには、論理的な移行が必要です。Coming from different data sources other than SQL Server requires logical migration. 論理的な移行では Azure Database Migration Service を使用できます。You can use the Azure Database Migration Service for a logical migration.

ビジネス継続性とディザスター リカバリーに関する質問Business continuity and disaster recovery questions

ハイパースケール データベースではどのような SLA が提供されるかWhat SLA’s are provided for a Hyperscale database

既定のプライマリと 1 つの読み取り可能なセカンダリでは、SLA は 99.95% の可用性です。With the default primary plus 1 readable secondary, the SLA is 99.95% availability. 複数のレプリカでは、SLA は 99.99% まで上がります。With more replicas, the SLA goes up to 99.99%.

Azure SQL Database サービスによってデータベース バックアップが管理されるかAre the database backups managed for me by the Azure SQL Database service


データベース バックアップの実行頻度How often are the database backups taken

SQL Database ハイパースケール データベースでは、従来の完全バックアップ、差分バックアップ、およびログ バックアップは存在しません。There are no traditional full, differential, and log backups for SQL Database Hyperscale databases. 代わりに、データ ファイルの定期スナップショットと生成されるログがあり、構成した保存期間中はそのまま単純に保存され、ユーザーが利用できます。Instead, there are regular snapshots of the data files and log that is generated is simply retained as is for the retention period configured or available to you.

SQL Database ハイパースケールで特定の時点への復元はサポートされるかDoes SQL Database Hyperscale support Point in Time Restore


SQL Database ハイパースケールにおいてバックアップ/復元の回復ポイントの目標 (RPO)/回復時刻の目標 (RTO) とはWhat is the Recovery Point Objective (RPO)/Recovery Time Objective (RTO) with backup/restore in SQL Database Hyperscale

RPO は 0 分です。RTO はデータベース サイズにかかわらず 10 分未満です。The RPO is 0 min. The RTO goal is less than 10 minutes, regardless of database size.

大規模データベースのバックアップがプライマリ上のコンピューティング パフォーマンスに影響するかDo backups of large databases affect compute performance on my primary

いいえ。No. バックアップは記憶域サブシステムによって管理され、ファイル スナップショットを利用します。Backups are managed by the storage subsystem, and leverage file snapshots. プライマリ上のユーザー ワークロードには影響しません。They do not impact the user workload on the primary.

SQL Database ハイパースケール データベースを使用して geo リストアを実行できるかCan I perform geo-restore with a SQL Database Hyperscale database

はい。Yes. geo リストアは完全にサポートされています。Geo-restore is fully supported.

SQL Database ハイパースケール データベースを使用して geo レプリケーションを設定できるかCan I setup Geo-Replication with SQL Database Hyperscale database

現時点ではありません。Not at this time.

SQL Database ハイパースケールを使用してセカンダリ計算ノードの geo レプリケーションを実行できるかDo my secondary compute nodes get geo-replicated with SQL Database Hyperscale

現時点ではありません。Not at this time.

SQL Database ハイパースケール データベースのバックアップを使ってオンプレミス サーバーまたは VM の SQL Server を復元できるかCan I take a SQL Database Hyperscale database backup and restore it to my on-premises server or SQL Server in VM

いいえ。No. ハイパースケール データベースのストレージ形式は、従来の SQL Server とは異なります。バックアップの管理またはバックアップへのアクセスはできません。The storage format for Hyperscale databases is different from traditional SQL Server, and you don’t control backups or have access to them. SQL Database ハイパースケール データベースからデータを取り出すには、エクスポート サービスを使用するか、スクリプトと BCP を使用します。To take your data out of a SQL Database Hyperscale database, either use the export service or use scripting plus BCP.

移行前後の機能に関する質問Cross Feature questions

ハイパースケール サービス レベルに移行した後で使えなくなる機能があるかDo I lose any functionality or capabilities after migration to the Hyperscale service tier

はい。Yes. 長期的な保有期間のバックアップを始めとする Azure SQL Database の一部の機能は、ハイパースケールではサポートされていません。Some of Azure SQL Database features are not supported in Hyperscale, including but not limited long term retention backup. ハイパースケールにデータベースを移行した後、これらの機能は動作を停止します。After you migrate your databases to Hyperscale, those features stop working.

Polybase は SQL Database ハイパースケールで作動するかWill Polybase work with SQL Database Hyperscale

いいえ。No. Polybase は Azure SQL Database でサポートされていません。Polybase isn’t supported on Azure SQL Database.

コンピューティングで R と Python がサポートされるかDoes the compute have support for R and python

いいえ。No. R と Python は Azure SQL Database でサポートされていません。R and Python are not supported in Azure SQL Database.

コンピューティング ノードはコンテナー化されるかAre the compute nodes containerized

いいえ。No. データベースは、コンテナー上ではなくコンピューティング VM 上に存在しています。Your database resides on a compute VM and not a container.

パフォーマンスに関する質問Performance questions

最大の SQL Database ハイパースケール コンピューティングでどれくらいスループットを向上できるかHow much throughput can I push on the largest SQL Database Hyperscale compute

一貫した 100 MB/秒のデータの変更 (トランザクション ログ データの生成) が見られますWe have seen a consistent 100 MB/sec of change data (transaction log data generation)

最大の SQL Database ハイパースケール コンピューティングにおいて得られる IOPS 数How many IOPS do I get on the largest SQL Database Hyperscale compute

IOPS と IO 待ち時間は、ワークロードのパターンによって異なります。IOPS and IO latency will vary depending on the workload patterns. アクセスされる必要があるデータがコンピューティングのキャッシュに対してローカルの場合、ローカル SSD と同じ IO パターンになります。If the data needing to be accessed is local to the compute's cache, it will be the same IO patterns as local SSD.

スループットがバックアップの影響を受けるかDoes my throughput get affected by backups

いいえ。No. コンピューティングへの影響を避けるために、コンピューティングはストレージ レイヤーから切り離されます。Compute is decoupled from the storage layer to avoid impact on compute.

追加の計算ノードをプロビジョニングするとスループットが影響を受けるかDoes my throughput get affected as I provision additional compute nodes

ストレージが共有されており、プライマリ計算ノードとセカンダリ計算ノードの間では物理的なレプリケーションが直接発生しないために、技術的には、プライマリ ノード上のスループットは読み取りスケール ノードを追加することによる影響を受けません。Because the storage is shared and there is no direct physical replication happening between primary and secondary compute nodes, technically, the throughput on primary node will not be affected by adding read-scale nodes. ただし、継続する活発なワークロードを調整して、セカンダリ ノードとページ サーバー上でログを適用できます。これで遅れを取り戻し、セカンダリ ノード上での読み取りパフォーマンスの悪化を回避できます。However, we may throttle continuous aggressive workload to allow log apply on secondary nodes and page servers to catch up, and avoid bad read performance on secondary nodes.

スケーラビリティに関する質問Scalability questions

計算ノードのスケールアップとスケールダウンにかかる時間How long would it take to scale up and down a compute node

コンピューティングのスケールアップまたはスケールダウンには、データ サイズに関係なく、5 分から 10 分かかります。Scaling compute up or down should take 5-10 minutes regardless of data size.

スケールアップ/スケールダウン操作の進行中にデータベースはオフラインになるかIs my database offline while the scaling up/down operation is in progress

いいえ。No. スケールアップ/スケールダウンはオンラインで行われます。The scaling up and down will be online.

スケール操作が進行中に接続が切断されるかShould I expect connection drop when the scaling operations are in progress

スケールアップまたはスケールダウンによって既存の接続が切断されるのは、目標サイズの計算ノードへのフェールオーバーが発生したときです。Scaling up or down results in existing connections being dropped when failover happens to the compute node with the target size. 読み取りレプリカの追加では接続は切断されません。Adding read replicas does not result in connection drops.

計算ノードのスケールアップとスケールダウンは自動で行われるか (エンドユーザーが開始する操作か)Is the scaling up and down of compute nodes automatic or end-user triggered operation

エンドユーザー。End-user. 自動ではありません。Not automatic.

コンピューティングがスケールアップされると tempb も拡張されるかDoes my tempb also grow as the compute is scaled up

はい。Yes. 一時 db は、コンピューティングの拡張に合わせて自動的にスケールアップされます。Temp db will scale up automatically as the compute grows.

複数のプライマリ コンピューティング ヘッドが高レベルの同時実行を推進できる、複数のプライマリ コンピューティング (マルチマスター システムなど) をプロビジョニングできるかCan I provision multiple primary computes such as a multi-master system where multiple primary compute heads can drive a higher level of concurrency

いいえ。No. 読み取り/書き込み要求を受け入れるのはプライマリ計算ノードのみです。Only the primary compute node accepts read/write requests. セカンダリ計算ノードは、読み取り専用要求のみを受け入れます。Secondary compute nodes only accept read-only requests.

読み取りスケールに関する質問Read scale questions

セカンダリ計算ノードをいくつプロビジョニングできるかHow many secondary compute nodes can I provision

既定では、ハイパースケール データベース用にレプリカを 2 つ作成します。We create 2 replicas for Hyperscale databases by default. レプリカの数を調整する場合は、Azure portal を使用して行うことができます。If you want to adjust the number of replicas, you can do so using Azure portal.

これらのセカンダリ コンピューティング ノードにどのように接続するかHow do I connect to these secondary compute nodes

これらの追加読み取り専用計算ノードに接続するには、接続文字列の ApplicationIntent 引数を read_only に設定してください。You can connect to these additional read-only compute nodes by setting the ApplicationIntent argument on your connection string to read_only. read-only がマークされたすべての接続は、追加読み取り専用計算ノードのいずれかに自動的にルーティングされます。Any connections marked with read-only are automatically routed to one of the additional read-only compute nodes.

読み取りスケール レプリカ専用のエンドポイントを作成できるかCan I create a dedicated endpoint for the read-scale replica

いいえ。No. ApplicationIntent=ReadOnly と指定した場合のみ、読み取りスケール レプリカに接続できます。You can only connect to read-scale replica by specifying ApplicationIntent=ReadOnly.

読み取りワークロードのインテリジェントな負荷分散がシステムで行われるかDoes the system do intelligent load balancing of the read workload

いいえ。No. 読み取り専用ワークロードは、ランダムな読み取りスケール レプリカにリダイレクトされます。The read only workload is re-directed to a random read-scale replica.

セカンダリ計算ノードをプライマリ コンピューティングと別にスケールアップ/スケールダウンできるかCan I scale up/down the secondary compute nodes independently of the primary compute

いいえ。No. セカンダリ計算ノードは高可用性のためにも使用されるため、フェールオーバーの場合は、プライマリと同じ構成にする必要があります。The secondary compute nodes are also used for HA, so they need to be the same configuration as the primary, in case of a failover.

プライマリ計算ノードと追加のセカンダリ計算ノードで異なる一時 db サイズを設定できるかDo I get different temp db sizing for my primary compute and my additional secondary compute nodes

いいえ。No. tempdb はコンピューティング サイズのプロビジョニングに基づいて構成され、セカンダリ計算ノードはプライマリ コンピューティングと同じサイズです。Your tempdb is configured based on the compute size provisioning, your secondary compute nodes are the same size as the primary compute.

セカンダリ計算ノードにインデックスとビューを追加できるかCan I add indexes and views on my secondary compute nodes

いいえ。No. ハイパースケール データベースではストレージが共有されます。つまり、すべての計算ノードは同じテーブル、インデックス、ビューを見ることができます。Hyperscale databases have shared storage, meaning that all compute nodes see the same tables, indexes and views. 読み取りに対して最適化したインデックスをセカンダリに追加したい場合は、まずプライマリに追加する必要があります。If you want additional indexes optimized for reads on secondary – you must add them on the primary first.

プライマリ計算ノードとセカンダリ計算ノードの間の遅延はどれくらいかHow much delay is there going to be between the primary and secondary compute node

ログ生成速度によって異なりますが、トランザクションがプライマリ上でコミットされた時点から、すぐ、または数ミリ秒です。From the time a transaction is committed on the primary, depending on the log generation rate, it can either be instantaneous or in low milliseconds.

次の手順Next steps

ハイパースケール サービス レベルについて詳しくは、ハイパースケール サービス レベルに関するページをご覧ください。For more information about the Hyperscale service tier, see Hyperscale service tier.