Масштабирование ресурсов отдельной базы данных в Базе данных SQL Azure

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

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

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

• Transact-SQL
• Портал Azure
• PowerShell
• Azure CLI
• REST API

Воздействие

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

1. Создание нового вычислительного экземпляра для базы данных

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

2. Переключение маршрутизации подключений на новый вычислительный экземпляр.

   Существующие подключения к базе данных в исходном вычислительном экземпляре удаляются. Все новые подключения устанавливаются для базы данных в новом вычислительном экземпляре. При некоторых сочетаниях изменений уровня служб и объема вычислительных ресурсов файлы базы данных отсоединяются и повторно присоединяются во время переключения. Тем не менее переключение может привести к краткосрочному прерыванию работы службы. При этом база данных, как правило, остается недоступной менее 30 секунд, а зачастую — всего несколько секунд. Если при удалении подключений выполняются длительные транзакции, длительность этого шага может занять больше времени для восстановления прерванных транзакций. Ускорение восстановления базы данных в Azure SQL может снизить влияние от прерывания длительных транзакций.

Задержка

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

SELECT s.file_id,
       s.type_desc,
       s.name,
       FILEPROPERTYEX(s.name, 'AccountType') AS AccountType
FROM sys.database_files AS s
WHERE s.type_desc IN ('ROWS', 'LOG');

Мониторинг или отмена изменений масштабирования

Изменение уровня служб или операция перемасштабирования вычислительных ресурсов можно отслеживать и отменять.

Login-AzAccount
$SubscriptionID = "<YourSubscriptionIdHere>"
Select-AzSubscription -SubscriptionName $SubscriptionID

Get-AzSqlDatabaseActivity -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database01"

Stop-AzSqlDatabaseActivity -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database01" -OperationId af97005d-9243-4f8a-844e-402d1cc855f5

$resourceGroupName = "<resource group name>"
$serverName = "<server name>"
$databaseName = "<sql database name>"
az sql db op list --resource-group $resourceGroupName --server $serverName --database $databaseName --query "[?state=='InProgress'].name" --out tsv

$resourceGroupName = "<resource group name>"
$serverName = "<server name>"
$databaseName = "<sql database name>"
$operationName = (az sql db op list --resource-group $resourceGroupName --server $serverName --database $databaseName --query "[?state=='InProgress'].name" --out tsv)
if (-not [string]::IsNullOrEmpty($operationName)) {
    (az sql db op cancel --resource-group $resourceGroupName --server $serverName --database $databaseName --name $operationName)
        "Operation " + $operationName + " has been canceled"
}
else {
    "No service tier change or compute rescaling operation found"
}

Разрешения

Для масштабирования баз данных с помощью Transact-SQLALTER DATABASE используется. Чтобы масштабировать базу данных, необходимо либо имя входа администратора сервера (созданное при подготовке База данных SQL Azure логического сервера), администратор Microsoft Entra сервера, член роли базы данных dbmanager в master, член роли базы данных db_owner в текущей базе данных или dbo базы данных. Дополнительные сведения см. в статье Параметры инструкции ALTER DATABASE для файлов и файловых групп (Transact-SQL).

Для масштабирования баз данных с помощью портал Azure, PowerShell, Azure CLI или REST API требуются разрешения Azure RBAC, в частности роль участника, роль участника базы данных SQL или роли участника RBAC SQL Server. Дополнительные сведения см. в статье о встроенных ролях Azure RBAC.

Дополнительные рекомендации

• При переходе к более высокому уровню служб или объему вычислительных ресурсов максимальный размер базы данных не увеличивается, если явно не указать для него большее значение (maxsize).
• При понижении уровня базы данных используемое ею пространство не должно превышать максимальный допустимый размер целевых уровня служб и объема вычислительных ресурсов.
• При понижении уровня служб Премиум до уровня Стандартный дополнительная плата взимается в следующих случаях: 1) максимальный размер базы данных поддерживается в целевом объеме вычислительных ресурсов; 2) максимальный размер превышает включенный объем хранилища целевого объема вычислительных ресурсов. Например, если уровень базы данных P1 с максимальным размером в 500 ГБ понижается до уровня S3, то взимается плата за дополнительное хранилище, так как на уровне S3 поддерживается максимальный размер в 1 ТБ, а включенный объем хранилища составляет только 250 ГБ. Поэтому дополнительный объем хранилища равен 500 – 250 = 250 ГБ. Цены на дополнительное хранилище см. в разделе Цены Базы данных SQL Azure. Если фактический объем пространства, которое используется, меньше, чем включенный объем хранилища, то этих дополнительных затрат можно избежать, уменьшив максимальный размер базы данных до включенного объема.
• Если вы повышаете уровень базы данных со включенной георепликацией, перед повышением уровня базы данных-источника сначала обновите базы данных-получатели до требуемого уровня служб и объема вычислительных ресурсов (общая рекомендация для оптимальной производительности). При переходе на использование более позднего выпуска необходимо в первую очередь обновить базу данных-получатель.
• Если вы понижаете уровень базы данных со включенной георепликацией, перед понижением уровня базы данных-получателя сначала понизьте категорию ее базы данных-источника до требуемого уровня служб и объема вычислительных ресурсов (общая рекомендация для оптимальной производительности). При переходе на использование более раннего выпуска необходимо в первую очередь обновить базу данных-источник.
• Предложения службы восстановления отличаются для разных уровней служб. При переходе на уровень Базовый уменьшится период хранения резервной копии. См. статью "Автоматические резервные копии" в База данных SQL Azure.
• Новые свойства базы данных применяются только после завершения изменений.
• При необходимости копирования данных для масштабирования базы данных (см . задержку) при изменении уровня служб высокая загрузка ресурсов, параллельная с операцией масштабирования может привести к увеличению времени масштабирования. При ускоренном восстановлении базы данных (ADR) откат длительных транзакций не является значительным источником задержки, но высокая параллельная загрузка ресурсов может оставить меньше ресурсов вычислений, хранилища и пропускной способности сети для масштабирования, особенно для небольших размеров вычислительных ресурсов.

Выставление счетов

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

Изменение размера хранилища

Модель приобретения на основе виртуальных ядер

• Хранилище данных может быть расширено до максимально возможного размера с шагом приращения в 1 ГБ. Минимальный настраиваемый размер хранилища данных составляет 1 ГБ. Сведения об ограничениях максимального размера для хранилища данных см. в документации по ограничениям ресурсов: Ограничения ресурсов для отдельных баз данных с моделью приобретения виртуальных ядер и Ограничения ресурсов для отдельных баз данных с моделью приобретения DTU.

• Хранилище для отдельной базы данных можно подготовить, увеличив или уменьшив его максимальный размер с помощью портала Azure, Transact-SQL, PowerShell, Azure CLI или REST API. Если значение максимального размера указано в байтах, оно должно быть кратно 1 ГБ (1073741824 байт).

• Объем данных, которые можно хранить в файлах данных базы данных, не может превышать настроенный максимальный размер хранилища данных. В дополнение к хранилищу База данных SQL Azure автоматически добавляет 30% больше хранилища, которое будет использоваться для журнала транзакций. Стоимость хранилища для отдельной базы данных или эластичного пула равна суммарному объему хранилищ данных и журналов транзакций, умноженному на цену единицы хранения для этого уровня служб. Например, если для хранилища данных задано значение 10 ГБ, то дополнительное хранилище журнала транзакций составляет 10 ГБ * 30 % = 3 ГБ, а общий объем оплачиваемого хранилища составляет 10 ГБ + 3 ГБ = 13 ГБ.

  Примечание.

  Максимальный размер файла журнала транзакций управляется автоматически, и в некоторых случаях может превышать 30 % максимального размера хранилища данных. Это не увеличивает цену хранилища для базы данных.

• База данных SQL Azure автоматически выделяет 32 ГБ на виртуальное ядро для базы данных tempdb. tempdb находится в локальном хранилище SSD на всех уровнях служб. Стоимость включается в цену tempdb одной базы данных или эластичного пула.

• Подробнее о ценах на хранилище см. в разделе Цены Базы данных SQL Azure.

Модель приобретения на основе единиц DTU

• Цена DTU для отдельной базы данных включает в себя определенный объем хранилища, не требующий дополнительной платы. Дополнительный объем хранилища, сверх включенного, можно подготовить за дополнительную плату в пределах максимального допустимого размера с шагом в 250 ГБ при объеме хранилища до 1 ТБ и с шагом в 256 ГБ — при объеме более 1 ТБ. Сведения о включенном объеме хранилища и ограничениях максимального размера см. в разделе Отдельная база данных: размеры хранилища и объемы вычислительных ресурсов.
• Дополнительное хранилище для отдельной базы данных можно подготовить, увеличив ее максимальный размер с помощью портала Azure, Transact-SQL, PowerShell, Azure CLI или REST API.
• Стоимость дополнительного хранилища для отдельной базы данных равна объему хранилища, умноженному на цену единицы хранения этого хранилища для уровня служб. Подробнее о цене на дополнительное хранилище см. в разделе Цены Базы данных SQL Azure.

Геореплицированная база данных

Чтобы изменить размер реплицированной базы данных-получателя, измените размер базы данных-источника. Это изменение будет реплицировано и реализовано и в базе данных-получателе.

Ограничения P11 и P15 при максимальном размере более 1 ТБ

Хранилище размером более 1 ТБ на уровне "Премиум" в настоящее время доступно во всех регионах, за исключением Восточного и Северного Китая, а также Центральной и Северо-Восточной Германии. В этих регионах максимальный объем хранилища класса Premium ограничен 1 ТБ. Ниже приведены рекомендации и ограничения для баз данных P11 и P15 с максимальным размером, превышающим 1 ТБ.

• Если в качестве максимального размера базы данных P11 или P15 когда-либо было задано значение больше 1 ТБ, то ее можно восстановить или скопировать только в базу данных P11 или P15. Следовательно, базу данных можно масштабировать до другого объема вычислительных ресурсов при условии, что объем пространства, выделяемого во время операции изменения масштаба, не превышает ограничения максимального размера нового объема вычислительных ресурсов.
• Для активных сценариев георепликации:
  • Настройка отношений георепликации: если база данных-источник относится к типу P11 или P15, базы данных-получатели тоже должны относиться к типу P11 или P15. Более низкий размер вычислительных ресурсов отклоняется в качестве вторичных файлов, так как они не могут поддерживать более 1 ТБ.
  • Обновление базы данных-источника в отношениях георепликации. При изменении максимального размера и указании значения больше 1 ТБ в базе данных-источнике такие же изменения произойдут в базе данных-получателе. Чтобы изменения в базе данных-источнике вступили в силу, оба обновления должны быть успешными. При этом применяются ограничения по регионам для максимального размера больше 1 ТБ. Если база данных-получатель находится в регионе, который не поддерживает больше 1 TB, то база данных-источник не обновляется.
• Использование службы импорта и экспорта для загрузки баз данных P11 и P15 размером больше 1 ТБ не поддерживается. Используйте SqlPackage для импорта и экспорта данных.

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

• Ограничения ресурсов для отдельных баз данных с использованием модели приобретения виртуального ядра
• Resource limits for single databases using the DTU purchasing model (Ограничения ресурсов для отдельных баз данных при использовании модели приобретения DTU)