您现在访问的是微软AZURE全球版技术文档网站,若需要访问由世纪互联运营的MICROSOFT AZURE中国区技术文档网站,请访问 https://docs.azure.cn.

“超大规模”服务层级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.

“超大规模”服务层级具有哪些功能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 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

超大规模服务层适用于大多数业务工作负荷,因为它通过可单独缩放的计算和存储资源提供极大的灵活性和高性能。The Hyperscale service tier is intended for most business workloads as it provides great flexibility and high performance with independently scalable compute and storage resources. 由于能够自动缩放最大为 100 TB 的存储,因此对于以下客户来说,这是一个很好的选择:With the ability to auto-scale storage up to 100 TB, it's a great choice for customers who:

  • 在本地部署大型数据库,并想要通过迁移到云来实现应用程序的现代化Have large databases on-premises and want to modernize their applications by moving to the cloud
  • 已在云中,受限于其他服务层的最大数据库大小限制(1-4 TB)Are already in the cloud and are limited by the maximum database size restrictions of other service tiers (1-4 TB)
  • 具有较小的数据库,但需要快速的垂直和水平计算缩放、高性能、即时备份和快速数据库还原。Have smaller databases, but require fast vertical and horizontal compute scaling, high performance, instant backup, and fast database restore.

超大规模服务层支持从纯 OLTP 到纯分析的各种 SQL Server 工作负荷,但它主要针对 OLTP 和混合事务以及分析处理(HTAP)工作负荷进行了优化。The Hyperscale service tier supports a broad range of SQL Server workloads, from pure OLTP to pure analytics, but it is primarily optimized for OLTP and hybrid transaction and analytical processing (HTAP) workloads.

重要

弹性池不支持“超大规模”服务层级。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 are charged for storage for your database based on actual usage. 在 10 gb 到 100 TB 之间,以动态方式在 10 GB 和 40 GB 之间动态调整存储空间。Storage is automatically allocated between 10 GB and 100 TB, in increments that are dynamically adjusted between 10 GB and 40 GB.

有关“超大规模”服务层级定价的详细信息,请参阅 Azure SQL 数据库定价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 are nearly instantaneous. 通过存储和计算分离功能,可以将备份/还原操作推送到存储层,以减少主计算副本上的处理负担。Storage and compute separation enables pushing down the backup/restore operation to the storage layer to reduce the processing burden on the primary compute replica. 因此,数据库备份不会影响主计算节点的性能;同样,还原是通过还原到文件快照来完成的,因此不是数据操作的大小。As a result, database backup does not impact performance of the primary compute node; similarly, restores are done by reverting to file snapshots, and as such are not a size of data operation. 还原是一项恒定的操作,甚至可以在几分钟内(而不是几小时或几天)还原多 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-SQLPowershell 或者 CLI 创建超大规模数据库。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个内核的 Gen5 硬件上创建超大规模数据库。This will create a Hyperscale database on Gen5 hardware with 4 cores.

将现有 Azure SQL 数据库迁移到“超大规模”服务层级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, 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 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 does not have a secondary replica, connection will be routed to the primary replica and defaults to ReadWrite behavior.

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

超大规模辅助副本都是相同的,它们使用与主副本相同的服务级别目标。Hyperscale secondary replicas are all identical, using the same Service Level Objective as the primary replica. 如果存在多个辅助副本,则会在所有可用的辅助副本之间分布工作负荷。If more than one secondary replica is present, the workload is distributed across all available secondaries. 每个辅助副本单独更新,因此不同的副本相对于主副本可能具有不同的数据延迟。Each secondary replica is updated independently, thus different replicas could have different data latency relative to the primary replica.

超大规模中的数据库高可用性Database High Availability in Hyperscale

与所有其他服务层一样,超大规模保证已提交事务的数据持久性,而不考虑计算副本的可用性。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 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 数据库还原到不同区域时使用的步骤完全相同的步骤:This involves exactly the same steps as what you would use to restore any other AZURE SQL DB to a different region:

  1. 如果你还没有适当的服务器,请在目标区域中创建一个 SQL 数据库服务器。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 数据库页上的 "异地还原" 主题中的说明进行操作。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. 如果目标在配对的区域中,则副本将位于数据中心内,其速度要快于 internet 上的长距离副本,但它仍将复制所有的位。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 数据库Request to create Azure Hyperscale SQL Database in a new region
    区域: [填写所需区域]Region: [Fill in your requested region]
    计算 SKU/总内核数,包括可读副本Compute SKU/total cores including readable replicas
    估计的 TB 数Number of TB estimated

  10. 选择“严重性 C”Choose Severity C

  11. 选择适当的联系方法并填写详细信息。Choose the appropriate contact method and fill in details.

  12. 单击 "保存继续"Click Save and Continue

已知限制Known limitations

这是公开上市后超大规模服务层的当前限制。These are the current limitations to the Hyperscale service tier as of GA. 我们正在努力尽可能多地删除这些限制。We are actively working to remove as many of these limitations as possible.

问题Issue 描述Description
逻辑服务器的 "管理备份" 窗格不显示将从 SQL server 筛选超大规模数据库The Manage Backups pane for a logical server does not show Hyperscale databases will be filtered from SQL server 超大规模具有用于管理备份的单独方法,因此,长期保留期和时间点备份保留设置不适用/无效。Hyperscale has a separate method for managing backups, and as such the Long-Term Retention and Point in Time backup Retention settings do not apply / are invalidated. 相应地,“超大规模”数据库不会显示在“管理备份”窗格中。Accordingly, Hyperscale databases do not appear in the Manage Backup pane.
时间点还原Point-in-time restore 将数据库迁移到超大规模服务层后,不支持在迁移之前还原到某个时间点。Once a database is migrated into the Hyperscale service tier, restore to a point-in-time prior to the migration is not supported.
将非超大规模 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 has one or more data files larger than 1 TB, migration fails 在某些情况下,可以通过将大文件收缩为小于 1 TB 来解决此问题。In some cases, it may be possible to work around this issue by shrinking the large files to be less than 1 TB. 如果迁移在迁移过程中使用的数据库,请确保没有任何文件大于 1 TB。If migrating a database being used during the migration process, make sure that no file gets larger than 1 TB. 使用以下查询来确定数据库文件的大小。Use the following query to determine the size of database files. SELECT *, name AS file_name, size * 8. / 1024 / 1024 AS file_size_GB FROM sys.database_files WHERE type_desc = 'ROWS';SELECT *, name AS file_name, size * 8. / 1024 / 1024 AS file_size_GB FROM sys.database_files WHERE type_desc = 'ROWS';
托管实例Managed Instance 超大规模数据库当前不支持 Azure SQL 数据库托管实例。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 文件或其他数据移动技术(大容量复制、Azure 数据工厂、Azure Databricks、SSIS 等)进行导出/导入。At present, the only way to migrate a database from Hyperscale to non-Hyperscale is to export/import using a BACPAC file or other data movement technologies (Bulk Copy, Azure Data Factory, Azure Databricks, SSIS, etc.)
迁移具有持久性内存中对象的数据库Migration of databases with persistent in-memory objects 超大规模仅支持非持久性内存中对象(表类型、本机 Sp 和函数)。Hyperscale only supports non persistent In-Memory objects (table types, native SPs and functions). 在将数据库迁移到超大规模服务层之前,必须删除持久性内存中表和其他对象,并将其重新创建为非内存对象。Persistent In-Memory tables and other objects must be dropped and recreated as non-In-Memory objects before migrating a database to the Hyperscale service tier.
更改跟踪Change Tracking 你还不能使用 Azure SQL 超大规模数据库配置和使用更改跟踪。You cannot yet configure and use Change Tracking with Azure SQL Hyperscale databases.
异地复制Geo Replication 你尚未配置 Azure SQL 数据库超大规模的异地复制。You cannot yet configure geo-replication for Azure SQL Database Hyperscale.
数据库复制Database Copy 你还不能使用数据库副本在 Azure SQL 超大规模中创建新数据库。You cannot yet use Database Copy to create a new database in Azure SQL Hyperscale.
TDE/AKV 集成TDE/AKV Integration 对于 Azure SQL 数据库超大规模,尚不支持使用 Azure Key Vault (通常称为 "自带密钥" 或 BYOK)的透明数据库加密,但是,完全支持具有服务托管密钥的 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 除了 "强制计划" 选项外,所有其他自动优化选项在超大规模中尚不受支持:选项可能看起来已启用,但不会有任何建议或操作。With the exception of the "Force Plan" option, all other Automatic tuning options are not yet supported on Hyperscale: options may appear to be enabled, but there won't be any recommendations or actions made.

后续步骤Next steps