超大規模資料庫服務層級Hyperscale service tier

Azure SQL Database 是以會針對雲端環境調整的 SQL Server 資料庫引擎架構為基礎,以確保 99.99% 的可用性 (即使在基礎結構失敗的情況下)。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 中使用三個架構模型:There are three architectural models that are used in Azure SQL Database:

  • 一般目的/標準General Purpose/Standard
  • 超大規模資料庫Hyperscale
  • 業務關鍵/進階Business Critical/Premium

Azure SQL Database 中的超大規模服務層是以虛擬核心為基礎的購買模型中的最新服務層。The Hyperscale service tier in Azure SQL Database is the newest service tier in the vCore-based purchasing model. 此服務層級是可高度擴充的儲存體和計算效能層,可利用 Azure 架構以相應放大 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.

注意

  • 如需 vCore 為基礎的購買模型中的一般用途和業務關鍵服務層級的詳細資訊,請參閱 一般用途業務關鍵 服務層級。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.
  • 超大規模服務層級目前僅適用于 Azure SQL Database,而不是 Azure SQL 受控執行個體。The Hyperscale service tier is currently only available for Azure SQL Database, and not Azure SQL Managed Instance.

超大規模資料庫功能有哪些What are the Hyperscale capabilities

Azure SQL Database 中的超大規模資料庫服務層級提供下列額外功能:The Hyperscale service tier in Azure SQL Database provides the following additional capabilities:

  • 支援最多 100 TB 的資料庫大小Support for up to 100 TB of database size
  • 近乎即時的資料庫 (備份會根據儲存在 Azure Blob 儲存體中的檔案快照集) ,不論大小為何,都不會對計算資源造成任何 IO 影響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 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
  • 快速相應放大 - 您可以佈建一或多個唯讀節點來卸載讀取工作負載,並用來作為熱待命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 when needed, and then scale the compute resources back down when not needed.

超大規模資料庫服務層級會移除傳統上會在雲端資料庫中看到的許多實際限制。The Hyperscale service tier removes many of the practical limits traditionally seen in cloud databases. 大部分其他資料庫都受限於單一節點中的可用資源,但超大規模資料庫服務層級中的資料庫沒有這類限制。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. 事實上,並不會使用定義的大小上限來建立超大規模資料庫。In fact, Hyperscale databases aren't created with a defined max size. 超大規模資料庫會視需要成長,您只需支付所使用的容量。A Hyperscale database grows as needed - and you're billed only for the capacity you use. 針對大量讀取工作負載,超大規模資料庫服務層級會視需要佈建額外的讀取複本來卸載讀取工作負載,以提供快速相應放大。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 databases can be backed up virtually instantaneously. 您也可以在數分鐘內相應增加或減少數十個 TB 的資料庫。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.

誰應該考慮使用超大規模資料庫服務層級Who should consider the Hyperscale service tier

超大規模服務層級適用于大部分的商務工作負載,因為它可提供絕佳的彈性和高效能,並提供可獨立調整的計算和儲存體資源。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 autoscale 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.

超大規模服務層級支援廣泛的 SQL Server 工作負載,從純 OLTP 到純分析,但主要是針對 OLTP 和混合式交易和分析處理進行優化, (HTAP) 工作負載。The Hyperscale service tier supports a broad range of SQL Server workloads, from pure OLTP to pure analytics, but it's primarily optimized for OLTP and hybrid transaction and analytical processing (HTAP) workloads.

重要

彈性集區不支援超大規模資料庫服務層級。Elastic pools do not support the Hyperscale service tier.

超大規模資料庫定價模型Hyperscale pricing model

超大規模資料庫服務層級僅在虛擬核心模型中提供。Hyperscale service tier is only available in vCore model. 為配合新的架構,定價模型會與一般用途或業務關鍵服務層級稍微不同: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 Hybrid Benefit 價格會自動套用到讀取縮放複本。The Azure Hybrid Benefit price is applied to read scale replicas automatically. 根據預設,我們會為每個超大規模資料庫建立一個主要複本和一個唯讀複本。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're charged for storage for your database based on actual allocation. 儲存體會在 40 GB 和 100 TB 之間自動設定,以 10 GB 為單位遞增。Storage is automatically allocated between 40 GB and 100 TB, in 10-GB increments. 如有需要,多個資料檔案可能會同時成長。Multiple data files can grow at the same time if needed. 建立超大規模資料庫的起始大小為 10 GB,且每隔10分鐘就會開始增加 10 GB,直到達到 40 GB 的大小。A Hyperscale database is created with a starting size of 10 GB and it starts growing by 10 GB every 10 minutes, until it reaches the size of 40 GB.

如需有關超大規模定價的詳細資訊,請參閱 Azure SQL Database 定價For more information about Hyperscale pricing, see Azure SQL Database Pricing

分散式函式架構Distributed functions architecture

傳統資料庫引擎將所有資料管理功能都集中到一個位置/處理序 (因此,生產環境中的分散式資料庫現在會有多份整合型資料引擎),但超大規模資料庫不同,會具有不同的查詢處理引擎,而各種資料引擎的語意都會與提供資料長期儲存和持久性的元件不同。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.

下圖說明超大規模資料庫中不同類型的節點:The following diagram illustrates the different types of nodes in a Hyperscale database:

架構

超大規模資料庫包含下列不同類型的元件:A Hyperscale database contains the following different types of components:

計算Compute

計算節點是關聯式引擎所在的位置。The compute node is where the relational engine lives. 這是發生語言、查詢和交易處理的地方。This is where language, query, and transaction processing occur. 所有與超大規模資料庫的使用者互動都是透過這些計算節點進行。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. 有一個主要計算節點可以處理所有讀寫工作負載和交易。There is one primary compute node where all the read-write workloads and transactions are processed. 有一或多個次要計算節點作為容錯移轉的熱待命節點,以及作為用於卸載讀取工作負載的唯讀計算節點 (如果想要使用此功能)。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).

在超大規模計算節點上執行的資料庫引擎與其他 Azure SQL Database 服務層級相同。The database engine running on Hyperscale compute nodes is the same as in other Azure SQL Database service tiers. 當使用者與超大規模計算節點上的 database engine 互動時,支援的介面區和引擎行為會與其他服務層級相同,但 已知的限制除外。When users interact with the database engine on Hyperscale compute nodes, the supported surface area and engine behavior are the same as in other service tiers, with the exception of known limitations.

頁面伺服器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 either up to 128 GB or up to 1 TB of data. 在頁面伺服器複本以外的頁面伺服器複本上,不會有任何資料共用 (,而這些複本會保留以提供冗余和可用性) 。No data is shared on more than one page server (outside of page server 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 covering SSD-based caches to enhance performance. 資料頁面的長期儲存體會保存在 Azure 儲存體中,以獲得額外的可靠性。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 儲存體的長期儲存空間,這是幾乎無限儲存的儲存機制。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. 記錄服務也有本機記憶體和 SSD 快取,以加速存取記錄檔記錄。The log service also has local memory and SSD caches to speed up access to log records.

Azure 儲存體Azure storage

Azure 儲存體包含資料庫中的所有資料檔案。Azure Storage contains all data files in a database. 頁面伺服器會將資料檔案保留在 Azure 儲存體的最新狀態。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're 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 doesn't impact performance of the primary compute node. 同樣地,「時間點復原」 (PITR) 是藉由還原至檔案快照集來完成,因為這不是資料作業的大小。Similarly, point in time recovery (PITR) is done by reverting to file snapshots, and as such is not a size of data operation. 在相同的 Azure 區域中還原超大規模資料庫是一項固定時間的作業,甚至可以在數分鐘內還原多 tb 的資料庫,而不是數小時或數天的時間。Restore of a Hyperscale database in the same Azure region is a constant-time operation, and even multiple-terabyte databases can be restored in minutes instead of hours or days. 藉由還原現有的備份來建立新的資料庫也會利用此功能:建立資料庫複本以供開發或測試之用(即使是多 tb 的資料庫),在幾分鐘內就會雖可行。Creation of new databases by restoring an existing backup also takes advantage of this feature: creating database copies for development or testing purposes, even of multi-terabyte databases, is doable in minutes.

如需超大規模資料庫的異地還原,請參閱將 超大規模資料庫還原到不同的區域For geo-restore of Hyperscale databases, see Restoring a Hyperscale database to a different region.

規模和效能優點Scale and performance advantages

超大規模資料庫架構可以快速加速/減速其他唯讀計算節點,因而允許大規模讀取功能,也可以釋出主要計算節點來提供更多寫入要求。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. 此外,基於超大規模資料庫架構的共用儲存體架構,也可以快速相應增加/減少計算節點。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 入口網站t-sqlPowerShellCLI來建立超大規模資料庫。A Hyperscale database can be created using the Azure portal, T-SQL, PowerShell, or CLI. 超大規模資料庫只適用于以 vCore 為基礎的購買模型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

這將會在具有四個核心的第5代硬體上建立超大規模資料庫。This will create a Hyperscale database on Gen5 hardware with four cores.

將現有的資料庫升級至超大規模Upgrade existing database to Hyperscale

您可以使用 Azure 入口網站t-sqlPowerShellCLI,將 Azure SQL Database 中的現有資料庫移至超大規模。You can move your existing databases in Azure SQL Database to Hyperscale using the Azure portal, T-SQL, PowerShell, or CLI. 這次,這是單向的遷移。At this time, this is a one-way migration. 您無法將資料庫從超大規模移至另一個服務層級,而不是藉由匯出和匯入資料。You can't move databases from Hyperscale to another service tier, other than by exporting and importing data. 針對 (Poc) 的概念證明,建議您建立生產資料庫的複本,並將複本遷移至超大規模。For proofs of concept (POCs), we recommend making a copy of your production databases, and migrating the copy to Hyperscale. 將 Azure SQL Database 中的現有資料庫移轉至超大規模層是資料作業的大小。Migrating an existing database in 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. 如果 ApplicationIntent 設定為 READONLY 且資料庫沒有次要複本,連接將會路由傳送至主要複本,並預設為 ReadWrite 行為。If the ApplicationIntent set to READONLY and the database doesn't 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

如同所有其他服務層級,超大規模可保證已認可交易的資料持久性,而不考慮計算複本的可用性。As in all other service tiers, Hyperscale guarantees data durability for committed transactions regardless of compute replica availability. 因為主要複本變成無法使用所造成的停機時間,取決於已規劃的容錯移轉類型 (計畫與未計畫的) ,以及至少有一個次要複本存在。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.

如需超大規模 SLA,請參閱 Azure SQL Database 的 slaFor Hyperscale SLA, see SLA for Azure SQL Database.

超大規模資料庫的嚴重損壞修復Disaster recovery for Hyperscale databases

將超大規模資料庫還原至不同區域Restoring a Hyperscale database to a different region

如果您需要將 Azure SQL Database 中的超大規模資料庫還原至目前所裝載的區域以外的區域,做為損毀修復作業或切入、重新配置或任何其他原因的一部分,主要方法是進行資料庫的異地還原。If you need to restore a Hyperscale database in Azure SQL Database to a region other than the one it's 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. 這包含與您在 SQL Database 中將任何其他資料庫還原至不同區域時所用的完全相同步驟:This involves exactly the same steps as what you would use to restore any other database in SQL Database to a different region:

  1. 如果您還沒有適當的伺服器,請在目的地區域中建立 伺服器Create a server in the target region if you don't already have an appropriate server there. 此伺服器應與原始 (源) 伺服器擁有相同的訂用帳戶。This server should be owned by the same subscription as the original (source) server.
  2. 請依照頁面的 異地還原 主題中的指示,從自動備份還原 Azure SQL Database 中的資料庫。Follow the instructions in the geo-restore topic of the page on restoring a database in Azure SQL Database from automatic backups.

注意

因為來源和目標位於不同的區域,所以資料庫無法與源資料庫共用快照集儲存體,就像在非異地還原中一樣,這會非常快速完成。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. 在異地還原超大規模資料庫的情況下,它將會是資料大小的作業,即使目標位於異地複寫儲存體的配對區域中也是如此。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. 這表示執行異地還原的時間會與要還原的資料庫大小成正比。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 region, which will be significantly faster than a cross-region copy, but it will still be a size-of-data operation.

可用區域Available regions

Azure SQL Database 超大規模層適用于所有區域,但預設為啟用,如下所欄區域所提供。The Azure SQL Database Hyperscale tier is available in all regions but enabled by default available in the following regions listed below. 如果您想要在未列為支援的區域中建立超大規模資料庫,您可以透過 Azure 入口網站傳送登入要求。If you want to create Hyperscale database in a region that isn't listed as supported, you can send an onboarding request via Azure portal. 如需相關指示,請參閱 Azure SQL Database 的要求配額增加 以取得指示。For instructions, see Request quota increases for Azure SQL Database for instructions. 提交您的要求時,請使用下列指導方針:When submitting your request, use the following guidelines:

  • 使用 區域存取 SQL Database 配額類型。Use the Region access SQL Database quota type.
  • 在 [文字詳細資料] 中,新增計算 SKU/總核心數,包括可讀取的複本。In the text details, add the compute SKU/total cores including readable replicas.
  • 也請指定估計的 TB。Also specify the estimated TB.

啟用的區域:Enabled Regions:

  • 澳大利亞東部Australia East
  • 澳大利亞東南部Australia Southeast
  • 澳大利亞中部Australia Central
  • 巴西南部Brazil South
  • 加拿大中部Canada Central
  • 美國中部Central US
  • 中國東部 2China East 2
  • 中國北部 2China North 2
  • 東亞East Asia
  • 美國東部East US
  • 美國東部2East Us 2
  • 法國中部France Central
  • 德國中西部Germany West Central
  • 日本東部Japan East
  • 日本西部Japan West
  • 南韓中部Korea Central
  • 南韓南部Korea South
  • 美國中北部North Central US
  • 北歐North Europe
  • 挪威東部Norway East
  • 挪威西部Norway West
  • 南非北部South Africa North
  • 美國中南部South Central US
  • 東南亞Southeast Asia
  • 瑞士西部Switzerland West
  • 英國南部UK South
  • 英國西部UK West
  • US DoD 中部US DoD Central
  • US DoD 東部US DoD East
  • Us Govt 亞利桑那州Us Govt Arizona
  • US Govt 德克薩斯州US Govt Texas
  • 美國中西部West Central US
  • 西歐West Europe
  • 美國西部West US
  • 美國西部 2West US 2

已知的限制Known limitations

這些是超大規模服務層級目前在 GA 的限制。These are the current limitations to the Hyperscale service tier as of GA. 我們正積極地盡可能移除這些限制。We're actively working to remove as many of these limitations as possible.

問題Issue 描述Description
伺服器的 [管理備份] 窗格不會顯示超大規模資料庫。The Manage Backups pane for a server doesn't show Hyperscale databases. 這些將會從視圖進行篩選。These will be filtered from the view. 超大規模有個別的方法可管理備份,因此不適用 Long-Term 保留和時間點備份保留設定。Hyperscale has a separate method for managing backups, so the Long-Term Retention and Point-in-Time backup retention settings don't apply. 因此,超大規模資料庫不會出現在 [管理備份] 窗格中。Accordingly, Hyperscale databases don't appear in the Manage Backup pane.

針對從其他 Azure SQL Database 服務層級遷移至超大規模的資料庫,系統會在源資料庫的 備份保留 期間內保留預先遷移備份。For databases migrated to Hyperscale from other Azure SQL Database service tiers, pre-migration backups are kept for the duration of backup retention period of the source database. 這些備份可以用來將源資料庫 還原 到遷移之前的時間點。These backups can be used to restore the source database to a point in time before migration.
時間點還原Point-in-time restore 非超大規模資料庫無法還原為超大規模資料庫,且超大規模資料庫無法還原為非超大規模資料庫。A non-Hyperscale database can't be restored as a Hyperscale database, and a Hyperscale database can't be restored as a non-Hyperscale database. 針對已藉由變更其服務層級遷移至超大規模的非超大規模資料庫,請在遷移之前,還原至資料庫的備份保留期限內的時間點。For a non-Hyperscale database that has been migrated to Hyperscale by changing its service tier, restore to a point in time before migration and within the backup retention period of the database is possible programmatically. 還原的資料庫將不會超大規模。The restored database will be non-Hyperscale.
如果資料庫有一或多個資料檔案大於 1 TB,則遷移會失敗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';
SQL 受控執行個體SQL Managed Instance 超大規模資料庫目前不支援 Azure SQL 受控執行個體。Azure SQL Managed Instance isn't currently supported with Hyperscale databases.
彈性集區Elastic Pools 超大規模目前不支援彈性集區。Elastic Pools aren't currently supported with Hyperscale.
移轉至超大規模資料庫模目前是單向作業Migration to Hyperscale is currently a one-way operation 一旦資料庫移轉至超大規模之後,就無法直接遷移至非超大規模服務層級。Once a database is migrated to Hyperscale, it can't be migrated directly to a non-Hyperscale service tier. 目前將資料庫從超大規模遷移至非超大規模的唯一方法,是使用 bacpac 檔案或其他資料移動技術來匯出/匯入 (大量複製、Azure Data Factory、Azure Databricks、SSIS 等 ) Bacpac 匯出/匯入、從 Azure 入口網站使用 AzSqlDatabaseExportAzSqlDatabaseImport、從 Azure CLI 使用 az sql db 匯出az sql db 匯入,以及從 REST API 不受支援。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.) Bacpac export/import from Azure portal, from PowerShell using New-AzSqlDatabaseExport or New-AzSqlDatabaseImport, from Azure CLI using az sql db export and az sql db import, and from REST API isn't supported. 使用 SSMS 和 SqlPackage 18.4 版和更新版本可支援較小超大規模資料庫的 Bacpac 匯入/匯出 (高達 200 GB 的) 。Bacpac import/export for smaller Hyperscale databases (up to 200 GB) is supported using SSMS and SqlPackage version 18.4 and later. 針對較大的資料庫,bacpac 匯出/匯入可能需要很長的時間,而且可能會因各種原因而失敗。For larger databases, bacpac export/import may take a long time, and may fail for various reasons.
使用 In-Memory OLTP 物件遷移資料庫Migration of databases with In-Memory OLTP objects 超大規模支援 In-Memory OLTP 物件的子集,包括記憶體優化資料表類型、資料表變數和原生編譯模組。Hyperscale supports a subset of In-Memory OLTP objects, including memory-optimized table types, table variables, and natively compiled modules. 不過,當要遷移的資料庫中有任何種類的 In-Memory OLTP 物件時,不支援從高階和業務關鍵服務層級遷移至超大規模。However, when any kind of In-Memory OLTP objects are present in the database being migrated, migration from Premium and Business Critical service tiers to Hyperscale is not supported. 若要將這類資料庫移轉至超大規模,必須卸載所有 In-Memory OLTP 物件及其相依性。To migrate such a database to Hyperscale, all In-Memory OLTP objects and their dependencies must be dropped. 遷移資料庫之後,就可以重新建立這些物件。After the database is migrated, these objects can be recreated. 超大規模目前不支援持久性和非持久性記憶體優化資料表,且必須重新建立為磁片資料表。Durable and non-durable memory-optimized tables are not currently supported in Hyperscale, and must be recreated as disk tables.
異地複寫Geo Replication 您還無法設定 Azure SQL Database 超大規模的異地複寫。You can't yet configure geo-replication for Azure SQL Database Hyperscale.
資料庫複製Database Copy 超大規模上的資料庫複製現在處於公開預覽狀態。Database copy on Hyperscale is now in public preview.
TDE/AKV 整合TDE/AKV Integration 使用 Azure Key Vault (的透明資料庫加密通常稱為「自備金鑰」或「BYOK) 」,目前處於公開預覽狀態。Transparent Database Encryption using Azure Key Vault (commonly referred to as Bring-Your-Own-Key or BYOK) is currently in public preview.
智慧型資料庫功能Intelligent Database Features 除了 [強制執行計畫] 選項之外,超大規模上還不支援所有其他自動調整選項:可能會顯示選項已啟用,但不會有任何建議或動作。With the exception of the "Force Plan" option, all other Automatic Tuning options aren't yet supported on Hyperscale: options may appear to be enabled, but there won't be any recommendations or actions made.
查詢效能深入解析Query Performance Insights 超大規模資料庫目前不支援查詢效能深入解析。Query Performance Insights is currently not supported for Hyperscale databases.
壓縮資料庫Shrink Database 超大規模資料庫目前不支援 DBCC SHRINKDATABASE 或 DBCC SHRINKFILE。DBCC SHRINKDATABASE or DBCC SHRINKFILE isn't currently supported for Hyperscale databases.
資料庫完整性檢查Database integrity check 超大規模資料庫目前不支援 DBCC CHECKDB。DBCC CHECKDB isn't currently supported for Hyperscale databases. DBCC CHECKFILEGROUP 和 DBCC CHECKTABLE 可以用來做為因應措施。DBCC CHECKFILEGROUP and DBCC CHECKTABLE may be used as a workaround. 如需 Azure SQL Database 中資料完整性管理的詳細資訊,請參閱 Azure SQL Database 中的資料完整性See Data Integrity in Azure SQL Database for details on data integrity management in Azure SQL Database.

後續步驟Next steps