最多 100 TB 的超大規模服務層Hyperscale service tier for up to 100 TB

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.

注意

若要深入了解以虛擬核心為基礎的購買模型中的一般用途與商務關鍵服務層級,請參閱一般目的業務關鍵服務層。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 中的超大規模資料庫服務層級提供下列額外功能: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 儲存體中儲存的檔案快照集),不論大小,且不會對 Compute 造成任何 IO 影響Nearly instantaneous database backups (based on file snapshots stored in Azure Blob storage) regardless of size with no IO impact on Compute
  • 快速的資料庫還原 (根據檔案快照集),僅需數分鐘,而非數小時或數天 (不是資料作業的大小)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 as and 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 are 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

超大規模資料庫服務層級主要適用於在內部部署具有大型資料庫且想要藉由移至雲端來現代化其應用程式的客戶,或已在雲端且受限於資料庫大小上限限制 (1-4 TB) 的客戶。The Hyperscale service tier is primarily intended for customers who have large databases either on-premises and want to modernize their applications by moving to the cloud or for customers who are already in the cloud and are limited by the maximum database size restrictions (1-4 TB). 它也適用於搜尋高效能和高延展性儲存體和計算的客戶。It is also intended for customers who seek high performance and high scalability for storage and compute.

超大規模資料庫服務層級支援所有 SQL Server 工作負載,但主要針對 OLTP 最佳化。The Hyperscale service tier supports all SQL Server workloads, but it is primarily optimized for OLTP. 超大規模資料庫服務層級也支援混合和分析 (資料超市) 工作負載。The Hyperscale service tier also supports hybrid and analytical (data mart) 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 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 which are dynamically adjusted between 10GB and 40GB.

如需有關超大規模定價的詳細資訊,請參閱 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 nodes:

計算節點Compute node

計算節點就是關聯式引擎的所在位置,因此會發生所有語言元素、查詢處理等等。The compute node is where the relational engine lives, so all the language elements, query processing, and so on, 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).

頁面伺服器節點Page server node

頁面伺服器是代表相應放大儲存引擎的系統。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 儲存體中,以獲得額外的可靠性。Long-term storage of data pages is kept in Azure Storage for additional reliability.

記錄服務節點Log service node

記錄服務節點接受來自主要計算節點的記錄檔記錄,並將它們持續保存在長期快取中,然後將記錄檔記錄轉送至其餘的計算節點 (以更新其快取) 和相關頁面伺服器 (以在該處更新資料)。The log service node accepts log records from the primary compute node, persists them in a durable cache, and forwards the log records to the rest of the compute nodes (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 node are propagated through the log service to all the secondary compute nodes and page servers. 最後,記錄檔記錄會推送至 Azure 儲存體中的長期儲存體,即無限儲存體存放庫。Finally, the log record(s) are pushed out to long-term storage in Azure Storage, which is an infinite storage repository. 此機制不需要經常截斷記錄。This mechanism removes the necessity for frequent log truncation. 記錄服務也會有本機快取,以加速存取。The log service also has local cache to speed up access.

Azure 儲存體節點Azure storage node

Azure 儲存體節點是來自頁面伺服器之資料的最終目的地。The Azure storage node is the final destination of data from page servers. 此儲存體用於備份以及用於 Azure 區域之間的複寫。This storage is used for backup purposes as well as for replication between Azure regions. 備份包含資料檔案的快照集。Backups consist of snapshots of data files. 從這些快照集可以快速執行還原作業,而且可以將資料還原到任何時間點。Restore operation are fast from these snapshots and data can be restored to any point in time.

備份與還原Backup and restore

備份是檔案快照集庫,因此幾乎為即時。Backups are file-snapshot base and hence they are nearly instantaneous. 儲存體和計算區隔可將備份/還原作業下推到儲存體層,以減少主要計算節點的處理負擔。Storage and compute separation enable pushing down the backup/restore operation to the storage layer to reduce the processing burden on the primary compute node. 因此,備份大型資料庫不會影響主要計算節點的效能。As a result, the backup of a large database does not impact the performance of the primary compute node. 同樣地,還原是透過複製檔案快照集完成,因此不是資料作業大小。Similarly, restores are done by copying the file snapshot and as such are not a size of data operation. 針對相同儲存體帳戶內的還原,還原作業十分快速。For restores within the same storage account, the restore operation is fast.

規模和效能優點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-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 個核心的第 5 代硬體上。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 入口網站T-SQLPowershell 或是 CLI,將現有的 Azure SQL 資料庫移至超大規模資料庫服務層級。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. 您無法將資料庫從超大規模資料庫移到另一個服務層級中。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).

下列 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 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;

超大規模資料庫的災害復原Disaster Recovery for Hyperscale Databases

超大規模資料庫還原到不同的地理位置Restoring a Hyperscale database to a different geography

如果您要還原至不同於目前裝載於,做為一部分的災害復原作業或向下鑽研、 重新配置或任何其他原因,區域的 Azure SQL Database 超大規模 DB 的主要方法是執行異地還原的資料庫。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 Database 頁面的主題。Follow the instructions in the geo-restore topic of the page on restoring Azure SQL Databases 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 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 的超大規模層有目前在下列區域: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 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

如果您想要在未列出所支援的區域中建立超大規模資料庫,您可以傳送的登入要求,透過 Azure 入口網站。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.

若要要求在未列出的區域中建立超大規模資料庫的能力: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 資料庫配額類型:其他配額要求Choose SQL Database quota type: Other quota request

  9. 填寫下列範本:Fill in the following template:

    配額的詳細資料

    在範本中,提供下列資訊In the template, provide the following information

    要求新的區域中建立 Azure 超大規模的 SQL DatabaseRequest 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

這些是超大規模的服務層,自 ga。 目前的限制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 serverThe 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.
還原的非超大規模 DB 到 Hypserscale,反之亦然Restore of non-Hyperscale DB to Hypserscale and vice-versa 您無法將超大規模將資料庫還原到非超大規模資料庫,也可以到超大規模資料庫還原的非超大規模資料庫。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 的界限,則移轉會失敗If a database file grows during migration due to an active workload and crosses the 1 TB per file boundary, the migration fails 緩和措施:Mitigations:
- 可能的話,請在不執行更新工作負載時遷移資料庫。- If possible, migrate the database when there is no update workload running.
- 重試移轉,只要在移轉期間不超過 1 TB 的界限就會成功。- Re-try the migration, it will succeed as long as the 1 TB boundary is not crossed during the migration.
受控執行個體Managed Instance Azure SQL Database 受控執行個體目前不支援使用超大規模資料庫。Azure SQL Database Managed Instance is not currently supported with Hyperscale databases.
彈性集區Elastic Pools 彈性集區目前不支援 SQL 資料庫的超大規模使用。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 檔案進行匯出/匯入。At present, the only way to migrate a database from Hyperscale to non-Hyperscale is to export/import using a BACPAC file.
資料庫具有記憶體中物件的移轉Migration of databases with in-memory objects 記憶體內物件必須卸除並重新建立為非記憶體內物件,才能將資料庫遷移至超大規模資料庫服務層級。In-Memory objects must be dropped and recreated as non-In-Memory objects before migrating a database to the Hyperscale service tier.
變更資料追蹤Change Data Tracking 您無法變更資料追蹤與資料庫搭配使用超大規模。You will not be able to use Change Data Tracking with Hyperscale databases.
異地複寫Geo Replication 您尚無法設定異地複寫的 Azure SQL Database 的超大規模。You cannot yet configure geo-replication for Azure SQL Database Hyperscale. 您可以執行異地還原 (在不同的地理位置,將資料庫還原的 DR 或其他目的)You can perform geo-restores (restoring the database in a different geography, for DR or other purposes)
TDE/AKV 整合TDE/AKV Integration 透明資料庫加密,使用 Azure 金鑰保存庫 (通常稱為自備您-金鑰或 BYOK) 尚未支援的 Azure SQL Database 的超大規模,但完全支援搭配服務管理金鑰的 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 1.建立索引,Drop Index 顧問超大規模資料庫的未定型模型。1. Create Index, Drop Index adviser models are not trained for Hyperscale DBs.
2.結構描述問題 」、 「 DbParameterization-最近新增的超大規模資料庫不支援顧問。2. Schema Issue, DbParameterization - recently added advisers are not supported for Hyperscale Database.

後續步驟Next steps