“超大规模”服务层级Hyperscale service tier

Azure SQL 数据库基于 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 数据库中使用了三种体系结构模型:There are three architectural models that are used in Azure SQL Database:

  • 常规用途/标准General Purpose/Standard
  • 超大规模Hyperscale
  • 业务关键/高级Business Critical/Premium

Azure SQL 数据库中的“超大规模”服务层级是基于 vCore 的购买模型中的最新服务层级。The Hyperscale service tier in Azure SQL Database is the newest service tier in the vCore-based purchasing model. 此服务层级是一个高度可缩放的存储和计算性能层,它利用 Azure 体系结构来横向扩展 Azure SQL 数据库的存储和计算资源,远远超出了“常规用途”和“业务关键”服务层级的可用限制。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. 有关基于 vCore 购买模型与基于 DTU 购买模型的比较,请参阅 Azure SQL 数据库购买模型和资源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 数据库,不可用于 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 数据库中的“超大规模”服务层级提供了以下附加功能: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

vCore 模型提供“超大规模”服务层级。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 混合权益价格会自动应用到读取扩展副本。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 数据库定价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, 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

页面服务器是表示横向扩展存储引擎的系统。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

日志服务接受来自主要计算副本的日志记录,将其保存在永久缓存中,并将日志记录转发给其余计算副本(以便它们可以更新缓存)以及一个或多个相关页面服务器,以便可在此处更新数据。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. 日志服务还具有本地缓存,可加快日志记录的访问速度。The log service also has local cache 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. 同样,还原是通过还原为文件快照完成的,因此不是数据操作的大小。Similarly, restores are done by reverting to file snapshots, and as such aren't a size of data operation. 还原是时间恒定的操作,即使是若干 TB 的数据库,也能在数分钟内还原,而无需几个小时甚至几天。Restore 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 terabyte sized databases, is doable in minutes.

缩放和性能优势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

这会在配有 4 个核心的第 5 代硬件上创建一个超大规模数据库。This will create a Hyperscale database on Gen5 hardware with four cores.

将现有数据库升级到超大规模Upgrade existing database to Hyperscale

可以使用 Azure 门户T-SQLPowerShellCLI 将 Azure SQL 数据库中的现有数据库迁移到“超大规模”层级。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 数据库中的现有数据库迁移到“超大规模”层级是与数据大小相关的操作。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.chinacloudapi.cn;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 数据库的 SLAFor Hyperscale SLA, see SLA for Azure SQL Database.

超大规模数据库的灾难恢复Disaster recovery for Hyperscale databases

将超大规模数据库还原到其他地理位置Restoring a Hyperscale database to a different geography

如果在执行灾难恢复操作或演练、重新定位期间或者出于任何其他原因,需要将 Azure SQL 数据库中的某个超大规模数据库还原到其他位置(而不是其当前所在位置),主要方法是执行数据库的异地还原。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 数据库中任何其他数据库还原到其他区域的步骤完全相同: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 数据库中数据库的页面上的异地还原主题中的说明操作。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 数据库超大规模层级选项,但在下列区域中该层级是默认启用的。The Azure SQL Database Hyperscale tier is available in all regions but enabled by default available in the following regions listed below.

  • 中国东部 2China East 2
  • 中国北部 2China North 2

已知的限制Known limitations

下面是正式版发布之前“超大规模”服务层级的当前限制。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. “超大规模”服务层级具有单独的备份管理方法,因此“长期保留”和“时间点备份保留”设置不适用。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 数据库服务层级迁移到超大规模的数据库,预迁移备份会在源数据库的备份保持期持续时间内保留。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 数据工厂、SSIS 等)进行导出/导入。不支持从 Azure 门户、PowerShell(使用 New-AzSqlDatabaseExportNew-AzSqlDatabaseImport)、Azure CLI(使用 az sql db exportaz sql db import)以及从 REST API 进行 bacpac 导出/导入。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, 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 及更高版本对较小的超大规模数据库(最多 200 GB)进行 bacpac 导入/导出。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.
迁移包含持久性内存中 OLTP 对象的数据库Migration of databases with persistent In-Memory OLTP objects “超大规模”服务层级仅支持非持久性内存中 OLTP 对象(表类型、本机 SP 和函数)。Hyperscale only supports nonpersistent In-Memory OLTP objects (table types, native SPs and functions). 将数据库迁移到“超大规模”服务层级之前,必须删除持久性内存中 OLTP 表和其他对象,并将其重新创建为基于磁盘的对象。Persistent In-Memory OLTP tables and other objects must be dropped and recreated as disk-based objects before migrating a database to the Hyperscale service tier.
异地复制Geo Replication 目前无法为超大规模 Azure SQL 数据库配置异地复制。You can't yet configure geo-replication for Azure SQL Database Hyperscale.
数据库复制Database Copy 目前无法使用“数据库复制”在 Azure SQL“超大规模”中创建新数据库。You can't yet use Database Copy to create a new database in Azure SQL Hyperscale.
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 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。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 数据库中数据完整性管理的详细信息,请参阅 Azure SQL 数据库中的数据完整性See Data Integrity in Azure SQL Database for details on data integrity management in Azure SQL Database.

后续步骤Next steps