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

  • Статья

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

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

Внимание

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

Примечание.

Идентификатор Microsoft Entra ранее был известен как Azure Active Directory (Azure AD).

Воздействие

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

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

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

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

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

Внимание

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

Задержка

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

Задержка масштабирования базы данных Для базовой отдельной базы данных(
S0-S1) уровня "Стандартный"		 Для одной базы данных уровня "Стандартный" (S2-S12),
отдельная база данных общего назначения,
база данных с эластичным пулом "Базовый", база данных с эластичным пулом "Стандартный",

база данных с пулом общего назначения		 Для одной базы данных или базы данных с пулом уровня "Премиум",
критически важный для бизнеса отдельную базу данных или базу данных с пулом		 Для гипермасштабирования отдельной базы данных или базы данных с пулом
Из базовой отдельной базы данных(
S0-S1) уровня "Стандартный"		 • Задержка постоянного времени независимо от используемого пространства.
• Как правило, менее 5 минут.		 • Задержка пропорциональна пространству базы данных, используемому из-за копирования данных.
• Как правило, менее 1 минуты в секунду на используемое пространство.		 • Задержка пропорциональна пространству базы данных, используемому из-за копирования данных.
• Как правило, менее 1 минуты в секунду на используемое пространство.		 • Задержка пропорциональна пространству базы данных, используемому из-за копирования данных.
• Как правило, менее 1 минуты в секунду на используемое пространство.
Из базы данных с пулом "Базовый",
"Стандартная отдельная база данных" (S2-S12),
стандартная база данных с пулом,
отдельная база данных общего назначения или база данных с пулом		 • Задержка пропорциональна пространству базы данных, используемому из-за копирования данных.
• Как правило, менее 1 минуты в секунду на используемое пространство.		 • Для отдельных баз данных задержка постоянного времени не зависит от используемого пространства.
• Как правило, менее 5 минут для отдельных баз данных.
• Для эластичных пулов пропорционально количеству баз данных.		 • Задержка пропорциональна пространству базы данных, используемому из-за копирования данных.
• Как правило, менее 1 минуты в секунду на используемое пространство.		 • Задержка пропорциональна пространству базы данных, используемому из-за копирования данных.
• Как правило, менее 1 минуты в секунду на используемое пространство.
Из отдельной базы данных класса Premium или базы данных с пулом,
критически важный для бизнеса отдельную базу данных или базу данных с пулом		 • Задержка пропорциональна пространству базы данных, используемому из-за копирования данных.
• Как правило, менее 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.

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

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

На странице "Обзор базы данных SQL" найдите баннер, указывающий, что выполняется операция масштабирования, и выберите ссылку "Дополнительные сведения о развертывании".

Screenshot from the Azure portal showing a scaling operation in progress.

На результирующей странице текущих операций нажмите кнопку "Отменить эту операцию".

Screenshot from the Azure portal showing the Ongoing operations page and the cancel this operation button.

Разрешения

Для масштабирования баз данных с помощью Transact-SQL ALTER DATABASE используется. Чтобы масштабировать базу данных, необходимо либо имя входа администратора сервера (созданное при подготовке База данных SQL Azure логического сервера), администратор Microsoft Entra сервера, член роли базы данных 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% больше хранилища, которое будет использоваться для журнала транзакций. Стоимость хранилища для отдельной базы данных или эластичного пула равна суммарному объему хранилищ данных и журналов транзакций, умноженному на цену единицы хранения для этого уровня служб. Например, если для хранилища данных задано значение 10 ГБ, то дополнительное хранилище журнала транзакций составляет 10 ГБ * 30 % = 3 ГБ, а общий объем оплачиваемого хранилища составляет 10 ГБ + 3 ГБ = 13 ГБ.

    Примечание.

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

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

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

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