Уровень служб "Гипермасштабирование"Hyperscale service tier

База данных SQL Azure основана на архитектуре ядра СУБД 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. Существует три модели архитектуры, которые используются в Базе данных SQL Azure.There are three architectural models that are used in Azure SQL Database:

  • уровни "Общего назначения" или "Стандартный";General Purpose/Standard
  • Уровень "Гипермасштабирование"Hyperscale
  • уровни "Критически важный для бизнеса" или "Премиум";Business Critical/Premium

Уровень служб "Гипермасштабирование" в Базе данных SQL Azure — это новейший уровень в рамках модели приобретения на основе виртуальных ядер.The Hyperscale service tier in Azure SQL Database is the newest service tier in the vCore-based purchasing model. Этот высокомасштабируемый уровень производительности ресурсов хранения и вычислений, который использует архитектуру Azure для масштабирования этих ресурсов для службы "База данных SQL Azure" за пределы, доступные для уровней служб "Общего назначения" и "Критически важный для бизнеса".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 см. в статье Ресурсы и модели приобретения для Базы данных SQL Azure.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

Уровень служб "Гипермасштабирование" в службе "База данных SQL Azure" предоставляет следующие дополнительные возможности:The Hyperscale service tier in Azure SQL Database provides the following additional capabilities:

  • Поддержка размера базы данных до 100 ТБ.Support for up to 100 TB of database size
  • Почти мгновенное резервное копирование базы данных (на основе моментальных снимков файлов, хранящихся в хранилище BLOB-объектов Azure) независимо от размера без влияния ввода-вывода на ресурсы вычислений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 point-in-time 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. Увеличивать или уменьшать масштаб баз данных с десятками терабайт данных можно за считаные минуты.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 ТБ это отличный вариант для клиентов, которые: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 ТБ).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 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

Уровень служб "Гипермасштабирование" доступен только в модели на основе виртуальных ядер.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 ГБ до 100 ТБ, с приращениями, которые динамически корректируются между 10 ГБ и 40 ГБ.Storage is automatically allocated between 10 GB and 100 TB, in increments that are dynamically adjusted between 10 GB and 40 GB.

Дополнительные сведения о ценах категории "Гипермасштабирование" см. в разделе цен на Базу данных SQL Azure.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 ТБ).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 ГБ и 1 ТБ.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.

Хранилище AzureAzure 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. Восстановление — это операция постоянного времени, и даже несколько терабайт баз данных могут быть восстановлены за считаные минуты, а не часы или дни.Restore is a constant-time operation, and even multiple-terabyte databases can be restored in minutes instead of hours or days. Создание новых баз данных путем восстановления существующей резервной копии также использует преимущества этой функции: создание копий базы данных в пределах одного логического сервера для разработки или тестирования, даже из баз данных размером терабайта, выполнимо в минутах.Creation of new databases by restoring an existing backup also takes advantage of this feature: creating database copies within the same logical server 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-SQL, PowerShell или интерфейса командной строки.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 ядрами.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

Можно переместить существующие базы данных SQL Azure на уровень служб ценовой категории "Гипермасштабирование" с помощью портала Azure, T-SQL, PowerShell или интерфейса командной строки.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. Перенос существующей базы данных SQL Azure на уровень "горизонтальный" — это размер операции с данными.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.

Сведения об уровне обслуживания для этой службы см. в статье соглашение об уровне обслуживания для базы данных SQL Azure.For Hyperscale SLA, see SLA for Azure SQL Database.

Аварийное восстановление для баз данных с масштабированиемDisaster Recovery for Hyperscale Databases

Восстановление базы данных с помощью масштабирования в другую географиюRestoring a Hyperscale database to a different geography

Если необходимо восстановить базу данных SQL Azure с помощью службы масштабирования в регионе, отличном от того, на котором она размещена в, в рамках операции аварийного восстановления или детализации, перемещения или любой другой причины, основной метод заключается в выполнении географического восстановления базы данных.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. Это включает в себя те же действия, что и при восстановлении любой другой базы данных SQL AZURE в другом регионе.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. Следуйте инструкциям в разделе географическое восстановление на странице Восстановление баз данных SQL Azure из автоматически создаваемых резервных копий.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

Уровень масштабирования базы данных SQL Azure в настоящее время доступен в следующих регионах: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

    Запрос на создание базы данных SQL Azure Scale в новом регионе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
    Предполагаемое количество ТБ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 (Описание)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.
Восстановление базы данных, отличной от Хипсерскале, и наоборот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 ТБ, миграция завершается сбоемIf a database has one or more data files larger than 1 TB, migration fails В некоторых случаях эту ошибку можно обойти, уменьшая размер больших файлов до 1 ТБ.In some cases, it may be possible to work around this issue by shrinking the large files to be less than 1 TB. При миграции базы данных, используемой в процессе миграции, убедитесь, что размер файла не превышает 1 ТБ.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 Управляемый экземпляр Базы данных SQL Azure в настоящее время не поддерживается в базах данных с поддержкой масштабирования.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 Масштабирование поддерживает только непостоянные объекты в памяти (типы таблиц, собственные SPs и функции).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 Вы еще не можете настроить и использовать Отслеживание изменений с помощью масштабируемых баз данных SQL Azure.You cannot yet configure and use Change Tracking with Azure SQL Hyperscale databases.
ГеорепликацияGeo Replication Вы еще не можете настроить георепликацию для масштабирования базы данных SQL Azure.You cannot yet configure geo-replication for Azure SQL Database Hyperscale.
Копирование базы данныхDatabase Copy Вы еще не можете использовать копию базы данных для создания новой базы данных в службе масштабирования SQL Azure.You cannot yet use Database Copy to create a new database in Azure SQL Hyperscale.
Интеграция TDE и AKVTDE/AKV Integration Прозрачное шифрование базы данных с помощью Azure Key Vault (которое обычно называется "TDE" с собственным ключом или BYOK) еще не поддерживается для функции масштабирования базы данных SQL Azure, однако с ключами, управляемыми службой, полностью поддерживается.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