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

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

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

Важно!

Иногда требуется сжать базу данных, чтобы освободить неиспользуемое пространство. Дополнительные сведения см. в статье об управлении файловым пространством в Базе данных SQL Azure.

Влияние

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

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

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

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

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

Важно!

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

Задержка

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

Уровень служб Отдельная простая база данных,
уровень "Стандартный" (S0-S1)
Простой эластичный пул,
уровень "Стандартный" (S2-S12),
отдельная база данных или эластичный пул общего назначения
Отдельная база данных или эластичный пул уровня "Премиум" или "Критически важный для бизнеса" Уровень "Гипермасштабирование"
Отдельная простая база данных,
уровень "Стандартный" (S0-S1)
• Постоянная задержка во времени независимо от используемого пространства
• Обычно менее 5 минут
• Задержка, пропорциональная используемому пространству базы данных, вызванная копированием данных
• Обычно менее 1 минуты на 1 ГБ используемого пространства
• Задержка, пропорциональная используемому пространству базы данных, вызванная копированием данных
• Обычно менее 1 минуты на 1 ГБ используемого пространства
• Задержка, пропорциональная используемому пространству базы данных, вызванная копированием данных
• Обычно менее 1 минуты на 1 ГБ используемого пространства
Простой эластичный пул,
уровень "Стандартный" (S2-S12),
отдельная база данных или эластичный пул общего назначения
• Задержка, пропорциональная используемому пространству базы данных, вызванная копированием данных
• Обычно менее 1 минуты на 1 ГБ используемого пространства
• Для отдельных баз данных, постоянная задержка во времени независимо от используемого пространства
• Как правило, для отдельных баз данных — менее 5 минут
• Для эластичных пулов — пропорционально количеству баз данных
• Задержка, пропорциональная используемому пространству базы данных, вызванная копированием данных
• Обычно менее 1 минуты на 1 ГБ используемого пространства
• Задержка, пропорциональная используемому пространству базы данных, вызванная копированием данных
• Обычно менее 1 минуты на 1 ГБ используемого пространства
Отдельная база данных или эластичный пул уровня "Премиум" или "Критически важный для бизнеса" • Задержка, пропорциональная используемому пространству базы данных, вызванная копированием данных
• Обычно менее 1 минуты на 1 ГБ используемого пространства
• Задержка, пропорциональная используемому пространству базы данных, вызванная копированием данных
• Обычно менее 1 минуты на 1 ГБ используемого пространства
• Задержка, пропорциональная используемому пространству базы данных, вызванная копированием данных
• Обычно менее 1 минуты на 1 ГБ используемого пространства
• Задержка, пропорциональная используемому пространству базы данных, вызванная копированием данных
• Обычно менее 1 минуты на 1 ГБ используемого пространства
Уровень "Гипермасштабирование" Н/Д Просмотр обратной миграции из гипермасштабирования Недоступно • Постоянная задержка во времени независимо от используемого пространства
• Обычно менее 2 минут

Примечание

Кроме того, для баз данных уровня “Стандартный” (S2-S12) и общего назначения задержка при перемещении базы данных в эластичный пул, из него или между эластичными пулами будет пропорциональна размеру базы данных, если база данных использует хранилище файлового ресурса уровня “Премиум” (PFS).

Чтобы определить, использует ли база данных хранилище PFS, выполните следующий запрос в контексте базы данных. Если столбец AccountType содержит значение PremiumFileStorage или PremiumFileStorage-ZRS, то база данных использует хранилище PFS.

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');

Примечание

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

Совет

О том, как отслеживать выполняемые операции, см. в статье Управление операциями с помощью REST API SQL, Управление операциями с помощью CLI, Управление операциями с помощью T-SQL. Кроме того, можно использовать следующие две команды PowerShell: Get-AzSqlDatabaseActivity и Stop-AzSqlDatabaseActivity.

Отмена изменений

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

Портал Azure

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

Текущая операция

Затем нажмите кнопку Отменить эту операцию.

Отмена текущей операции

PowerShell

В командной строке PowerShell задайте $resourceGroupName, $serverName и $databaseName, а затем выполните следующую команду:

$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"
}

Разрешения

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

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

Дополнительные сведения

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

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

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

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

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

  • Хранилище данных может быть расширено до максимально возможного размера с шагом приращения в 1 ГБ. Минимальный настраиваемый размер хранилища данных составляет 1 ГБ. Сведения об ограничениях максимального размера для хранилища данных см. в документации по ограничениям ресурсов: Ограничения ресурсов для отдельных баз данных с моделью приобретения виртуальных ядер и Ограничения ресурсов для отдельных баз данных с моделью приобретения DTU.
  • Хранилище для отдельной базы данных можно подготовить, увеличив или уменьшив его максимальный размер с помощью портала Azure, Transact-SQL, PowerShell, Azure CLI или REST API. Если значение максимального размера указано в байтах, оно должно быть кратно 1 ГБ (1073741824 байт).
  • Объем данных, которые можно хранить в файлах данных базы данных, не может превышать настроенный максимальный размер хранилища данных. В дополнение к этому хранилищу База данных SQL Azure автоматически выделяет на 30% больше места для хранения журнала транзакций.
  • База данных SQL Azure автоматически выделяет 32 ГБ на виртуальное ядро для базы данных tempdb. tempdb находится в локальном хранилище SSD на всех уровнях служб.
  • Стоимость хранилища для отдельной базы данных или эластичного пула равна суммарному объему хранилищ данных и журналов транзакций, умноженному на цену единицы хранения для этого уровня служб. Стоимость tempdb входит в эту цену. Подробнее о ценах на хранилище см. в разделе Цены Базы данных SQL Azure.

Важно!

Иногда требуется сжать базу данных, чтобы освободить неиспользуемое пространство. Дополнительные сведения см. в статье об управлении файловым пространством в Базе данных SQL Azure.

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

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

Важно!

Иногда требуется сжать базу данных, чтобы освободить неиспользуемое пространство. Дополнительные сведения см. в статье об управлении файловым пространством в Базе данных SQL Azure.

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

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

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

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

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

Дальнейшие действия

Подробнее об общих ограничениях ресурсов см. в статьях Ограничения ресурсов Базы данных SQL Azure в модели приобретения на основе виртуальных ядер — отдельные базы данных и Ограничения ресурсов Базы данных SQL Azure в модели приобретения на основе DTU — отдельные базы данных.