Как управлять базой данных уровня "Гипермасштабирование"

Применимо к: База данных SQL Azure

Уровень служб "Гипермасштабирование" предоставляет высокомасштабируемый уровень производительности хранилища и вычислительных ресурсов, который использует архитектуру Azure для горизонтального увеличения масштаба этих ресурсов для службы "База данных SQL Azure" за пределы, доступные для уровней служб "Общего назначения" и "Критически важный для бизнеса". В этой статье объясняется, как выполнять основные задачи администрирования для баз данных уровня "Гипермасштабирование", включая переход на этот уровень, восстановление базы данных уровня "Гипермасштабирование" в другой регион, обратный переход с уровня "Гипермасштабирование" на другой уровень служб, а также мониторинг состояния текущих и недавно выполненных операций с базой данных уровня "Гипермасштабирование".

Узнайте, как создать новую базу данных уровня "Гипермасштабирование", из статьи Краткое руководство. Создание базы данных уровня "Гипермасштабирование" в Базе данных SQL Azure.

Совет

Упрощенная цена на База данных SQL Гипермасштабирование в декабре 2023 года. Дополнительные сведения см. в блоге о ценах на гипермасштабирование.

Перенос существующей базы данных на уровень "Гипермасштабирование"

Вы можете переместить существующие базы данных в Базе данных SQL Azure на уровень "Гипермасштабирование" с помощью портала Azure, Azure CLI, PowerShell или Transact-SQL.

Время, необходимое для переноса имеющейся базы данных на уровень служб "Гипермасштабирование", состоит из времени копирования данных и времени воспроизведения изменений, которые были внесены в исходную базу данных при копировании. Время копирования данных пропорционально их объему. Мы рекомендуем перейти на гипермасштабирование в течение более низкого периода действия записи, чтобы время воспроизведения накопленных изменений было короче.

Вы будете испытывать только короткий период простоя, как правило, через несколько минут во время окончательного перехода на уровень служб гипермасштабирования.

Необходимые компоненты

Чтобы перенести базу данных в рамках отношения георепликации как базу данных-источник или базу данных-получатель на уровень "Гипермасштабирование", сначала нужно завершить репликацию данных между первичной и вторичной репликами. Базы данных в группе отработки отказа должны быть сначала удалены из группы.

После того как база данных будет переведена в гипермасштабируемый формат, вы можете создать новую гипермасштабируемую геореплику для этой базы данных.

Как перенести базу данных на уровень служб "Гипермасштабирование"

Чтобы перенести существующую базу данных в Базе данных SQL Azure на уровень служб "Гипермасштабирование", сначала определите целевую службу. Просмотрите ограничения ресурсов для отдельных баз данных, если вы не определились с тем, какая целевая служба подходит для вашей базы данных. Во многих случаях можно выбрать целевую службу с таким же количеством виртуальных ядер и тем же поколением оборудования, что и исходная база данных. При необходимости вы можете изменить цель службы с минимальным временем простоя.

Выберите вкладку для предпочитаемого средства переноса базы данных:

Портал

Портал Azure позволяет перейти на уровень служб "Гипермасштабирование", изменив ценовую категорию для базы данных.

1. Перейдите к базе данных, которую хотите перенести на портал Azure.
2. На панели навигации слева выберите элемент Вычисления и хранилище.
3. Выберите раскрывающийся список уровня служб, чтобы развернуть параметры уровней служб.
4. Выберите гипермасштабирование (масштабируемое хранилище по запросу) в раскрывающемся меню.
5. Просмотрите указанную конфигурацию оборудования. При необходимости выберите команду Изменить конфигурацию, чтобы выбрать соответствующую конфигурацию оборудования для рабочей нагрузки.
6. Выберите ползунок vCores, если вам нужно изменить количество виртуальных ядер, доступных для базы данных на уровне служб "Гипермасштабирование".
7. Выберите ползунок High-AvailabilitySecondaryReplicas, если вам нужно изменить количество реплик на уровне служб "Гипермасштабирование".
8. Выберите Применить.

Вы можете отслеживать операции для базы данных уровня "Гипермасштабирование" во время выполнения операции.

Azure CLI

В этом примере кода вызывается az sql db update для переноса существующей базы данных в Базе данных SQL Azure на уровень служб "Гипермасштабирование". Необходимо указать целевые выпуск и службу.

Перед выполнением следующего примера кода замените resourceGroupName, serverName, databaseName, и serviceObjective соответствующими значениями:

resourceGroupName="myResourceGroup"
serverName="server01"
databaseName="mySampleDatabase"
serviceObjective="HS_Gen5_2"

az sql db update -g $resourceGroupName -s $serverName -n $databaseName \
    --edition Hyperscale --service-objective $serviceObjective

Вы можете отслеживать операции для базы данных уровня "Гипермасштабирование" во время выполнения операции.

PowerShell

В следующем примере для перевода существующей базы данных в Базе данных SQL Azure на уровень служб "Гипермасштабирование" используется командлет Set-AzSqlDatabase. Необходимо указать целевые выпуск и службу.

Перед выполнением этого примера кода замените $resourceGroupName, $serverName, $databaseName, и $serviceObjective соответствующими значениями:

$resourceGroupName = "myResourceGroup"
$serverName = "server01"
$databaseName = "mySampleDatabase"
$serviceObjective = "HS_Gen5_2"

Set-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName `
    -DatabaseName $databaseName -Edition "Hyperscale" `
    -RequestedServiceObjectiveName $serviceObjective

Вы можете отслеживать операции для базы данных уровня "Гипермасштабирование" во время выполнения операции.

Transact-SQL

Чтобы перенести существующую базу данных в База данных SQL Azure на уровень служб Гипермасштабирования с помощью Transact-SQL, сначала подключитесь к master базе данных на логическом сервере SQL Server с помощью редактора запросов портал Azure для База данных SQL Azure, SQL Server Management Studio (SSMS) или Azure Data Studio.

Необходимо указать целевые выпуск и службу в инструкции ALTER DATABASE.

В этом примере база данных с именем mySampleDatabase с помощью инструкции переводится на уровень служб "Гипермасштабирование" с целевой службой HS_Gen5_2. Замените имя базы данных соответствующим значением перед выполнением инструкции.

ALTER DATABASE [mySampleDatabase]
    MODIFY (EDITION = 'Hyperscale', SERVICE_OBJECTIVE = 'HS_Gen5_2');
GO

Вы можете отслеживать операции для базы данных уровня "Гипермасштабирование" во время выполнения операции.

Обратная миграция с уровня "Гипермасштабирование"

Обратная миграция на уровень служб "Общего назначения" позволяет клиентам, которые недавно перевели существующую базу данных в Базе данных SQL Azure на уровень служб "Гипермасштабирование", оперативно выполнить обратное перемещение, если уровень "Гипермасштабирование" больше не соответствует их потребностям. Обратная миграция инициируется изменением уровня службы, но по сути это перемещение определенного объема данных между разными архитектурами.

Ограничения для обратной миграции

Обратная миграция доступна в следующих условиях:

• Обратную миграцию можно выполнить только в течение 45 дней после первоначального перехода на уровень "Гипермасштабирование".
• Базы данных, изначально созданные на уровне служб гипермасштабирования, не имеют права на обратную миграцию.
• Вы можете отменить миграцию только на уровень служб общего назначения . Переход с уровня "Гипермасштабирование" на уровень "Общего назначения" может охватывать как бессерверные, так и подготовленные уровни вычислительных ресурсов. Если вы хотите перенести базу данных на другой уровень служб, например на уровень Критически важный для бизнеса, сначала выполните обратную миграцию на уровень служб Общего назначения, а затем измените уровень служб.
• Обратная миграция в базы данных с менее чем 2 виртуальными ядрами не поддерживается. Вы можете уменьшить масштаб базы данных до менее 2 виртуальных ядер после завершения миграции.
• Прямая обратная миграция из пула эластичных баз данных не поддерживается. Можно отменить миграцию только одной базы данных с гипермасштабированием в одну базу данных общего назначения.
  • Если база данных Гипермасштабирования является частью эластичного пула гипермасштабирования (предварительная версия), перед обратной миграцией необходимо сначала удалить ее из эластичного пула гипермасштабирования.
  • После завершения обратной миграции при необходимости можно добавить отдельную базу данных общего назначения в эластичном пуле общего назначения.
• Для баз данных, которые не соответствуют требованиям обратной миграции, единственным способом миграции с уровня "Гипермасштабирование" на другой уровень является экспорт и импорт с помощью BACPAC-файла или других технологий перемещения данных (массового копирования, фабрики данных Azure, Azure Databricks, служб SSIS и т. д.). Экспорт и импорт BACPAC с портала Azure, из PowerShell с помощью командлета New-AzSqlDatabaseExport или New-AzSqlDatabaseImport, из интерфейса командной строки Azure с помощью команд az sql db export и az sql db import, а также из REST API не поддерживается. Bacpac import/export for small Hyperscale database (до 150 ГБ) поддерживается с помощью SSMS и SqlPackage версии 18.4 и более поздних версий. Для больших баз данных bacpac export/import может занять много времени и может завершиться сбоем по различным причинам.

Длительность и простой

В отличие от обычных операций изменения целевого уровня служб на уровне "Гипермасштабирование", миграция на уровень "Гипермасштабирование" и обратная миграция на уровень "Общего назначения" — это операции с размером данных.

Длительность операции обратной миграции зависит главным образом от размера базы данных и параллельных операций записи, происходящих во время миграции. Количество виртуальных ядер, назначенных целевой базе данных общего назначения, также влияет на длительность обратной миграции. Рекомендуется подготовить целевую базу данных общего назначения с числом виртуальных ядер больше или равно количеству виртуальных ядер, назначенных исходной базе данных Гипермасштабирования, для поддержания аналогичных рабочих нагрузок.

Во время обратной миграции исходная база данных Гипермасштабирования может столкнуться с снижением производительности при значительной нагрузке. В частности, скорость журнала транзакций может быть сокращена (регулирование), чтобы обеспечить прогресс обратной миграции.

Вы будете испытывать короткий период простоя, как правило, через несколько минут во время окончательного переключения на новую целевую базу данных общего назначения.

Необходимые компоненты

Перед началом обратной миграции с уровня служб "Гипермасштабирование" на уровень служб "Общего назначения" необходимо убедиться, что база данных соответствует ограничениям для обратной миграции, а также в следующем:

• У вашей базы данных нет поддержки георепликации.
• У вашей базы данных нет именованных реплик.
• База данных (выделенный размер) достаточно мала, чтобы соответствовать целевому уровню служб.
• Если вы указываете максимальный размер для целевой базы данных уровня "Общего назначения", убедитесь, что выделенный размер базы данных достаточно мал, чтобы соответствовать этому максимальному размеру.

Проверки готовности выполняются до запуска операции обратной миграции. Если предварительные требования не выполнены, операция обратной миграции завершается сбоем немедленно.

Политики резервного копирования

Плата взимается с помощью обычных цен на все существующие резервные копии базы данных в течение настроенного периода хранения. Плата взимается за моментальные снимки хранилища с гипермасштабированием и для больших двоичных объектов хранилища данных, которые должны храниться для восстановления резервной копии.

Вы можете многократно переводить базу данных на уровень "Гипермасштабирование" и выполнять обратную миграцию на уровень "Общего назначения". Для восстановления доступны только резервные копии из текущего и предыдущего уровня базы данных. Если вы перешли с уровня служб "Общего назначения" на уровень "Гипермасштабирование" и выполнили обратную миграцию на уровень "Общего назначения", доступны только резервные копии из текущей базы данных уровня "Общего назначения" и непосредственно предыдущей базы данных уровня "Гипермасштабирование". Счета за эти сохраненные резервные копии выставляются в соответствии с моделью выставления счетов за Базу данных SQL Azure. Для всех уровней, с которыми вы пытались работать ранее, не будет доступных резервных копий и не будут выставляться счета.

Например, вы можете переходить между уровнем "Гипермасштабирование" и другими уровнями служб:

1. Общего назначения
2. Переход на уровень служб "Гипермасштабирование".
3. Обратная миграция на уровень "Общего назначения".
4. Изменение уровня служб на уровень "Критически важный для бизнеса".
5. Переход на уровень служб "Гипермасштабирование".
6. Обратная миграция на уровень "Общего назначения".

В этом случае единственными доступными резервными копиями будут созданные между этапами 5 и 6 временной шкалы, если они по-прежнему находятся в пределах настроенного периода хранения. Все резервные копии с предыдущих этапов будут недоступны. Внимательно рассмотрите доступность резервных копий при попытке повторной миграции одной базы данных между гипермасштабированием и уровнями служб общего назначения. Резервные копии баз данных старше предыдущей базы данных становятся недоступными сразу после запуска обратной миграции и остаются недоступными, даже если миграция отменена.

Как выполнить обратный перенос базы данных с уровня служб "Гипермасштабирование" на уровень служб "Общего назначения"

Чтобы отменить миграцию существующей базы данных гипермасштабирования в База данных SQL Azure на уровень служб общего назначения, сначала определите цель целевой службы на уровне служб общего назначения и хотите ли вы перейти на подготовленные или бессерверные уровни вычислений. Просмотрите ограничения ресурсов для отдельных баз данных, если вы не определились с тем, какая целевая служба подходит для вашей базы данных.

Если вы хотите изменить дополнительный уровень служб после обратной миграции на уровень "Общего назначения", определите целевую службу и убедитесь, что выделенный размер базы данных достаточно мал, чтобы соответствовать этой целевой службе.

Выберите вкладку для предпочитаемого метода обратного переноса базы данных:

Портал

Портал Azure позволяет выполнить обратную миграцию на уровень служб "Общего назначения", изменив ценовую категорию для базы данных.

1. Перейдите к базе данных, которую хотите перенести на портал Azure.
2. На панели навигации слева выберите элемент Вычисления и хранилище.
3. Выберите раскрывающийся список уровня служб, чтобы развернуть параметры уровней служб.
4. Выберите "Общего назначения" (параметры масштабируемого вычислений и хранилища) в раскрывающемся меню.
5. Просмотрите указанную конфигурацию оборудования. При необходимости выберите команду Изменить конфигурацию, чтобы выбрать соответствующую конфигурацию оборудования для рабочей нагрузки.
6. Выберите ползунок vCores, если вам нужно изменить количество виртуальных ядер, доступных для базы данных на уровне служб "Общего назначения".
7. Выберите Применить.

Azure CLI

В этом примере кода вызывается az sql db update для обратного переноса существующей базы данных уровня "Гипермасштабирование" на уровень служб "Общего назначения". Необходимо указать целевые выпуск и службу. Можно выбрать Provisioned Serverless или для целевой модели вычислений.

Перед выполнением следующего примера кода замените resourceGroupName, serverName, databaseName, и serviceObjective соответствующими значениями:

resourceGroupName="myResourceGroup"
serverName="server01"
databaseName="mySampleDatabase"
serviceObjective="GP_Gen5_2"
computeModel="Provisioned"

az sql db update -g $resourceGroupName -s $serverName -n $databaseName \
    --edition GeneralPurpose --service-objective $serviceObjective \
    --compute-model $computeModel

При необходимости вы можете включить аргумент maxsize. maxsize Если значение превышает допустимый максимальный размер целевой цели службы, возвращается ошибка. maxsize Если аргумент не указан, операция по умолчанию имеет максимальный размер, доступный для заданной цели службы. В следующем примере указывается maxsize:

resourceGroupName="myResourceGroup"
serverName="server01"
databaseName="mySampleDatabase"
serviceObjective="GP_Gen5_2"
computeModel="Provisioned"
maxsize="200GB"

az sql db update -g $resourceGroupName -s $serverName -n $databaseName \
    --edition GeneralPurpose --service-objective $serviceObjective \
    --compute-model $computeModel --max-size $maxsize

Вы можете отслеживать операции для базы данных уровня "Гипермасштабирование" во время выполнения операции.

PowerShell

В этом примере кода для обратного переноса существующей базы данных уровня "Гипермасштабирование" на уровень служб "Общего назначения" используется командлет Set-AzSqlDatabase. Необходимо указать целевые выпуск и службу. Можно выбрать или Provisioned Serverless для целевого уровня вычислений.

Перед выполнением этого примера кода замените $resourceGroupName, $serverName, $databaseName, $serviceObjective и $computeModel соответствующими значениями:

$resourceGroupName = "myResourceGroup"
$serverName = "server01"
$databaseName = "mySampleDatabase"
$serviceObjective = "GP_Gen5_2"
$computeModel = "Provisioned"

Set-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName `
    -DatabaseName $databaseName -Edition "GeneralPurpose" -computemodel $computeModel `
    -RequestedServiceObjectiveName $serviceObjective

При необходимости вы можете включить аргумент maxsize. maxsize Если значение превышает допустимый максимальный размер целевой цели службы, возвращается ошибка. maxsize Если аргумент не указан, операция по умолчанию имеет максимальный размер, доступный для заданной цели службы. В следующем примере указывается maxsize:

$resourceGroupName = "myResourceGroup"
$serverName = "server01"
$databaseName = "mySampleDatabase"
$serviceObjective = "GP_Gen5_2"
$computeModel = "Provisioned"
$maxSizeBytes = "268435456000"

Set-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName `
    -DatabaseName $databaseName -Edition "GeneralPurpose" -computemodel $computeModel `
    -RequestedServiceObjectiveName $serviceObjective -MaxSizeBytes $maxSizeBytes

Вы можете отслеживать операции для базы данных уровня "Гипермасштабирование" во время выполнения операции.

Transact-SQL

Чтобы отменить миграцию базы данных Гипермасштабирования на уровень служб общего назначения с помощью Transact-SQL, сначала подключитесь к master базе данных на логическом сервере SQL Server Management Studio (SSMS), Azure Data Studio .

Необходимо указать целевые выпуск и службу в инструкции ALTER DATABASE.

В этом примере база данных с именем mySampleDatabase с помощью инструкции переводится на уровень служб "Общего назначения" с целевой службой GP_Gen5_4. Перед выполнением инструкции замените имя базы данных и целевую службу соответствующими значениями.

ALTER DATABASE [mySampleDatabase]
    MODIFY (EDITION = 'GeneralPurpose', SERVICE_OBJECTIVE = 'GP_Gen5_2');
GO

При необходимости вы можете включить аргумент maxsize. maxsize Если значение превышает допустимый максимальный размер целевой цели службы, возвращается ошибка. maxsize Если аргумент не указан, операция по умолчанию имеет максимальный размер, доступный для заданной цели службы. В следующем примере указывается maxsize:

ALTER DATABASE [mySampleDatabase]
    MODIFY (EDITION = 'GeneralPurpose', SERVICE_OBJECTIVE = 'GP_Gen5_2', MAXSIZE = 200 GB);
GO

Вы можете отслеживать операции для базы данных уровня "Гипермасштабирование" во время выполнения операции.

Мониторинг операций для базы данных уровня "Гипермасштабирование"

Вы можете отслеживать состояние текущих или недавно завершенных операций для Базы данных SQL Azure с помощью портал Azure, Azure CLI, PowerShell или Transact-SQL.

Выберите вкладку для предпочитаемого метода мониторинга операций.

Портал

При выполнении такой операции, как миграция, обратная миграция или восстановление на портале Azure отображается уведомление для базы данных в Базе данных SQL Azure.

1. Перейдите к базе данных на портале Azure.
2. На левой панели навигации выберите Обзор.
3. Просмотрите раздел Уведомления в нижней части панели справа. Если операции выполняются, появится окно уведомлений.
4. Выберите поле уведомлений, чтобы просмотреть подробные сведения.
5. Откроется область текущих операций . Просмотрите сведения о текущих операциях.

Azure CLI

В этом примере кода вызывается az sql db op list для вывода сведений о недавно выполненных или текущих операциях для базы данных в Базе данных SQL Azure.

Перед выполнением следующего примера кода замените resourceGroupName, serverName, databaseName, и serviceObjective соответствующими значениями:

resourceGroupName="myResourceGroup"
serverName="server01"
databaseName="mySampleDatabase"

az sql db op list -g $resourceGroupName -s $serverName --database $databaseName

PowerShell

Командлет Get-AzSqlDatabaseActivity возвращает сведения о недавно выполненных или текущих операциях для базы данных в Базе данных SQL Azure.

Перед запуском примера кода задайте для параметров $resourceGroupName, $serverName и $databaseName соответствующие значения для своей базы данных:

$resourceGroupName = "myResourceGroup"
$serverName = "server01"
$databaseName = "mySampleDatabase"

Get-AzSqlDatabaseActivity -ResourceGroupName $resourceGroupName -ServerName $serverName -DatabaseName $databaseName

Transact-SQL

Чтобы отслеживать операции с базой данных с гипермасштабированием, сначала подключитесь к master базе данных на логическом сервере с помощью SQL Server Management Studio (SSMS), Azure Data Studio или клиента, выбранного для выполнения команд Transact-SQL.

Запросите динамическое административное представление sys.dm_operation_status, чтобы просмотреть сведения о последних операциях, выполненных с базами данных на [логическом сервере](logical-servers.md].

Этот пример кода возвращает все записи в sys.dm_operation_status для указанной базы данных, отсортированные по операциям, выполнение которых было начато позднее всего. Замените имя базы данных соответствующим значением перед выполнением примера кода.

SELECT *
FROM sys.dm_operation_status
WHERE major_resource_id = 'mySampleDatabase'
ORDER BY start_time DESC;
GO

Просмотр баз данных на уровне служб "Гипермасштабирование"

После переноса базы данных в гипермасштабирование или перенастройки базы данных на уровне служб "Гипермасштабирование" может потребоваться просмотреть и/или задокументировать конфигурацию базы данных гипермасштабирования.

Портал

На портале Azure отображается список всех баз данных на логическом сервере. Столбец Ценовая категория включает уровень служб для каждой базы данных.

1. Перейдите к логическому серверу на портале Azure.
2. На левой панели навигации выберите Обзор.
3. Прокрутите список ресурсов в нижней части панели. В окне отображаются эластичные пулы и базы данных SQL на логическом сервере.
4. Просмотрите столбец Ценовая категория, чтобы определить базы данных на уровне служб "Гипермасштабирование".

Azure CLI

В этом примере кода Azure CLI вызывается az sql db list для перечисления баз данных уровня "Гипермасштабирование" на логическом сервере с указанием их имени, расположения, целевого уровня служб, максимального размера и количества реплик с высоким уровнем доступности.

Перед выполнением следующего примера кода замените resourceGroupName и serverName соответствующими значениями:

resourceGroupName="myResourceGroup"
serverName="server01"

az sql db list -g $resourceGroupName -s $serverName --query "[].{Name:name, Location:location, SLO:currentServiceObjectiveName, Tier:currentSku.tier, maxSizeBytes:maxSizeBytes,HAreplicas:highAvailabilityReplicaCount}[?Tier=='Hyperscale']" --output table

PowerShell

Командлет Azure PowerShell Get-AzSqlDatabase возвращает список баз данных уровня "Гипермасштабирование" на логическом сервере с указанием их имени, расположения, целевого уровня служб, максимального размера и количества реплик с высоким уровнем доступности.

Перед запуском примера кода задайте для параметров $resourceGroupName и $serverName соответствующие значения:

$resourceGroupName = "myResourceGroup"
$serverName = "server01"

Get-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName | `
    Where-Object { $_.Edition -eq 'Hyperscale' } | `
        Select-Object DatabaseName, Location, currentServiceObjectiveName, Edition, `
        MaxSizeBytes, HighAvailabilityReplicaCount | `
            Format-Table

Просмотрите столбец Выпуск, чтобы определить базы данных на уровне служб "Гипермасштабирование".

Transact-SQL

Чтобы просмотреть уровни служб всех баз данных гипермасштабирования на логическом сервере с помощью Transact-SQL, сначала подключитесь к master базе данных с помощью SQL Server Management Studio (SSMS) или Azure Data Studio.

Запросите представление системного каталога sys.database_service_objectives, чтобы просмотреть базы данных на уровне служб "Гипермасштабирование":

SELECT d.name, dso.edition, dso.service_objective
FROM sys.database_service_objectives AS dso
JOIN sys.databases as d on dso.database_id = d.database_id
WHERE dso.edition = 'Hyperscale';
GO

Связанный контент

Дополнительные сведения о базах данных уровня "Гипермасштабирование" см. в следующих статьях:

• Краткое руководство. Создание базы данных уровня "Гипермасштабирование" в База данных SQL Azure
• Уровень служб "Гипермасштабирование"
• Часто задаваемые вопросы об уровне служб "Гипермасштабирование" в Базе данных SQL Azure
• Вторичные реплики гипермасштабирования
• Часто задаваемые вопросы об именованных репликах уровня "Гипермасштабирование" в Базе данных SQL Azure