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

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

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

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

Общие вопросы

Что такое база данных уровня "Гипермасштабирование"?

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

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

Уровень службы "Гипермасштабирование" доступен только для отдельных баз данных в рамках модели приобретения на основе виртуальных ядер в Базе данных SQL Azure. Она недоступна в модели приобретения на основе DTU.

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

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

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

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

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

Какие регионы сейчас поддерживают уровень "Гипермасштабирование"?

Уровень служб "Гипермасштабирование" доступен во всех регионах, где доступно База данных SQL Azure.

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

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

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

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

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

Гипермасштабирование обеспечивает высочайшую скорость масштабирования в соответствии с требованиями рабочей нагрузки.

  • Увеличение и уменьшение масштаба

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

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

  • Свертывание и развертывание

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

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

Детализированные вопросы

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

Да, вы можете.

Требуется ли изменять модель программирования приложения для уровня "Гипермасштабирование"?

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

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

На первичной реплике по умолчанию используется уровень изоляции "Чтение зафиксированных данных с моментального снимка" (RCSI). На вторичных репликах с горизонтальным увеличением масштаба для чтения по умолчанию используется уровень изоляции "Моментальный снимок". Это так же, как и в любой другой базе данных SQL Azure.

Можно ли на уровне "Гипермасштабирование" использовать локальную лицензию или лицензию IaaS SQL Server?

Благодаря новому упрощенному ценообразованию с 15 декабря 2023 года цена на вычислительные ресурсы для недавно созданных баз данных Гипермасштабирования сократилась, все бессерверные базы данных гипермасштабирования и все эластичные пулы гипермасштабирования. При использовании новых, упрощенных цен нет необходимости применять Преимущество гибридного использования Azure (AHB) для получения эквивалентной экономии. Преимущество гибридного использования Azure (AHB) можно применять только к старым (созданным до 15 декабря 2023 г.) базам данных гипермасштабирования с подготовленными вычислительными ресурсами. Для этих старых баз данных AHB применяется только до декабря 2026 года, после чего эти базы данных также будут выставляться в соответствии с новыми, упрощенными ценами. Дополнительные сведения см. в блоге о ценах на гипермасштабирование и База данных SQL Azure Гипермасштабирование — более низкие, упрощенные цены!.

Для каких рабочих нагрузок предназначен уровень "Гипермасштабирование"?

Гипермасштабирование поддерживает все типы рабочих нагрузок, включая рабочие нагрузки OLTP, гибридные (HTAP) и аналитические рабочие нагрузки (киоск данных).

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

Если в настоящее время выполняется интерактивные аналитические запросы с помощью SQL Server в качестве хранилища данных, гипермасштабирование — отличный вариант, так как вы можете размещать небольшие и средние хранилища данных (например, несколько ТБ до 100 ТБ) с более низкой стоимостью, и вы можете перенести рабочие нагрузки хранилища данных SQL Server в гипермасштабирование с минимальными изменениями кода T-SQL.

Если вы выполняете аналитику данных в большом масштабе с сложными запросами и устойчивыми скоростями приема выше 100 МБ/с или с помощью параллельного хранилища данных (PDW), Teradata или других хранилищ данных СИПП, Azure Synapse Analytics или Microsoft Fabric может быть лучшим выбором.

Вопросы о вычислениях на уровне "Гипермасштабирование"

Можно ли приостановить вычисления в любое время?

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

Можно ли подготовить вычислительную реплику с дополнительной оперативной памятью для рабочей нагрузки с интенсивным использованием памяти?

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

Можно ли подготовить несколько вычислительных реплик разного размера?

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

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

Число вторичных реплик высокой доступности можно масштабировать в диапазоне от 0 до 4 с помощью портала Azure или REST API. Кроме того, можно создать до 30 именованных реплик для различных сценариев масштабирования для чтения.

Нужно ли подготавливать дополнительные вычислительные реплики для обеспечения высокой доступности?

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

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

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

Вопросы по размеру и хранению данных

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

100 ТБ.

Каков размер журнала транзакций на уровне "Гипермасштабирование"?

В гипермасштабировании журнал транзакций практически бесконечно, при этом активной части журнала не может превышать 1 ТБ. Активная часть журнала может расти из-за длительных транзакций или из-за обработки отслеживания измененных данных , не выполняющихся в соответствии с скоростью изменения данных. Избегайте ненужных длительных и больших транзакций, чтобы оставаться ниже этого ограничения. Кроме этого ограничения, вам не нужно беспокоиться о том, что не требуется места в журнале в системе с высокой пропускной способностью журнала. Вместе с тем, для нагрузок, ведущих интенсивную запись, может быть ограничена скорость создания журнала. Пиковая долговременная скорость создания журнала составляет 100 МБ/с.

Масштабируется ли база данных tempdb по мере роста базы данных?

База данных tempdb хранится локально на SSD, и ее размер устанавливается пропорционально объему подготовленных вычислительных ресурсов (количеству ядер). Размер tempdb не настраивается и управляется для вас. Чтобы определить максимальный размер tempdb базы данных, см. статью Объем хранилища и вычислительных ресурсов на уровне "Гипермасштабирование".

Размер базы данных увеличивается автоматически или его нужно регулировать самостоятельно?

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

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

10 ГБ. База данных Гипермасштабирования создается с начальным размером 10 ГБ и увеличивается по мере необходимости в блоках размером 10 ГБ.

На сколько увеличивается размер базы данных за один шаг?

Размер каждого файла данных увеличивается на 10 ГБ. Одновременно может увеличиваться несколько файлов данных.

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

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

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

№ Файлы данных автоматически добавляются в файловую группу PRIMARY. Архитектура хранилища на уровне "Гипермасштабирование" и Базы данных SQL Azure в целом исключает причины, по которым обычно создаются дополнительные файловые группы.

Можно ли задать жестко фиксированное увеличение объема данных в базе данных?

Поддерживается ли уменьшение базы данных?

В настоящее время нет.

Поддерживается ли сжатие данных?

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

Распространяются ли данные в огромной таблице по нескольким файлам данных?

Да. Страницы данных, связанные с заданной таблицей, могут оказаться в нескольких файлах данных, которые входят в одну файловую группу. Данные в ядре СУБД MSSQL распределяются по файлам данных на основе стратегии пропорционального заполнения.

Вопросы, связанные с миграцией данных

Можно ли перенести имеющиеся базы данных SQL Azure на уровень служб "Гипермасштабирование"?

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

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

Получите пример кода для переноса существующих баз данных Azure SQL на уровень "Гипермасштабирование" на портале Azure, в Azure CLI, PowerShell и Transact-SQL в статье Перенос существующей базы данных в гипермасштабирование.

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

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

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

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

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

Будут ли утеряны функции или возможности после миграции на уровень служб "Гипермасштабирование"?

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

Можно ли переместить локальную базу данных SQL Server или базу данных SQL Server в облачной виртуальной машине в гипермасштабирование?

Да. Для перехода на уровень служб "Гипермасштабирование" можно пользоваться различными существующими технологиями миграции, включая репликацию транзакций, а также любыми другими технологиями перемещения данных (массовое копирование, Фабрика данных Azure, Azure Databricks, службы SSIS). См. также службу Azure Database Migration Service, которая поддерживает многие сценарии миграции.

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

Время простоя при переходе на уровень служб "Гипермасштабирование" такое же, как и при переносе баз данных на другие уровни служб Базы данных SQL Azure. Вы можете использовать репликацию транзакций, чтобы минимизировать время простоя при миграции баз данных размером до нескольких TБ. Для сверхбольших баз данных (более 10 ТБ) можно рассмотреть возможность переноса данных с помощью ADF, Spark или других технологий массового перемещения данных.

Сколько времени потребуется, чтобы перенести объем данных X на уровень служб "Гипермасштабирование"?

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

Можно ли считывать данные из хранилища BLOB-объектов и быстро загружать (например, Polybase в Azure Synapse Analytics)?

Клиентское приложение может считывать данные из службы хранилища Azure и загружать их в базу данных уровня "Гипермасштабирование" (как и в случае с любой другой базой данных SQL Azure). В настоящее время База данных SQL Azure не поддерживает Polybase. Альтернативой быстрой загрузке могут служить Фабрика данных Azureили задание Spark в Azure Databricks с соединителем Spark для SQL. Соединитель Spark для SQL поддерживает массовую вставку.

Кроме того, возможно массовое чтение данных из Хранилища BLOB-объектов Azure с помощью операторов BULK INSERT или OPENROWSET: см. статью "Примеры массового доступа к данным в Хранилище BLOB-объектов Azure".

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

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

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

Поддерживается ли на уровне служб "Гипермасштабирование" перенос данных из других источников, таких как Amazon Aurora, MySQL, PostgreSQL, Oracle, DB2 и другие платформы баз данных?

Да. Служба Azure Database Migration Service поддерживает многие сценарии миграции.

Вопросы о непрерывности бизнес-процессов и аварийном восстановлении

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

См. статью "SLA для Базы данных SQL Azure". Для критически важных рабочих нагрузок рекомендуется добавить вторичные реплики высокой доступности. Это обеспечит быструю отработку отказа и сократит возможное снижение производительности сразу после нее.

Осуществляется ли в Базе данных SQL Azure автоматическое управление резервным копированием баз данных?

Да.

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

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

Поддерживает ли гипермасштабирование эластичные пулы?

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

Как часто создаются резервные копии баз данных?

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

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

Да.

Каковы целевая точка восстановления (RPO) и целевое время восстановления (RTO) для баз данных на уровне служб "Гипермасштабирование"?

Значение RPO для восстановления до точки во времени составляет 0 мин. Большинство операций восстановления выполняются в пределах 60 минут независимо от размера базы данных. Время восстановления может быть дольше для больших баз данных, и если база данных испытала значительное действие записи до точки восстановления. Изменение избыточности хранилища при выполнении восстановления может привести к более длительному времени восстановления, так как восстановление — это размер данных, поэтому время будет пропорциональным размеру базы данных.

Влияет ли резервное копирование базы данных на производительность вычислений на первичной или вторичной репликах?

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

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

Да. Геовосстановление полностью поддерживается при использовании геоизбыточного хранилища. Это распространяется по умолчанию на новые базы данных. В отличие от восстановления на определенный момент времени, геовосстановление — операция, затрагивающая весь объем данных. Файлы данных копируются параллельно, поэтому длительность этой операции зависит главным образом от размера самого крупного файла в базе данных, а не общего размера базы данных. Геовосстановление займет существенно меньше времени, если восстанавливать базу данных в регионе Azure, парном относительно региона исходной базы данных.

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

Да. Геомасштабирование реплика можно настроить для баз данных гипермасштабирования.

Можно ли взять резервную копию базы данных уровня "Гипермасштабирование" и восстановить ее на локальном сервере или на сервере SQL Server на виртуальной машине?

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

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

Да. Начиная с 4 мая 2022 года резервные копии для всех новых баз данных взимается на основе используемого и выбранного хранилища резервного копирования с учетом частоты, записанной на странице цен на База данных SQL Azure. Для баз данных гипермасштабирования, созданных до 4 мая 2022 г., резервные копии будут взиматься только в том случае, если срок хранения резервных копий превышает семь дней. Дополнительные сведения см. в разделе Резервные копии с гипермасштабированием и избыточность хранилища.

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

Сведения об измерении размера хранилища резервных копий описаны в разделе Автоматические резервные копии.

Как узнать стоимость резервного копирования?

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

Как рабочая нагрузка повлияет на стоимость резервного копирования?

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

Как можно сократить затраты на хранилище резервных копий?

Сведения о сокращении затрат на хранилище резервных копий описаны в разделе Автоматические резервные копии.

Вопросы о производительности

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

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

Какое число операций ввода-вывода в секунду обеспечивается при наибольшем объеме вычислительных ресурсов?

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

Влияет ли резервное копирование на пропускную способность?

№ Вычислительные ресурсы отделены от уровня хранилища. Это устраняет влияние на производительность резервного копирования.

Снижается ли пропускная способность при подготовке дополнительных вычислительных реплик?

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

Хорошо ли гипермасштабирование подходит для ресурсоемких, длительных запросов и транзакций?

Да. Однако так же, как и в других базах данных БАЗЫ данных SQL Azure, подключения могут быть прерваны очень редкими временными ошибками, которые могут прервать длительные запросы и откат транзакций. Одна из причин временных ошибок заключается в том, что система быстро перемещает базу данных на другой вычислительный узел, чтобы обеспечить постоянную доступность ресурсов вычислений и хранилища, а также выполнять плановое обслуживание. Большинство этих событий перенастройки длится менее 10 секунд. Приложения, подключающиеся к базе данных, должны учитывать это и допускать редко возникающие временные ошибки за счет реализации логики повторных попыток. Кроме того, рассмотрите возможность настройки периода обслуживания, который соответствует расписанию рабочих нагрузок, чтобы избежать возникновения временных ошибок из-за планового обслуживания.

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

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

Как максимальное ограничение памяти в бессерверном режиме сравнивается с подготовленными вычислительными ресурсами?

Максимальный объем памяти, масштабируемой бессерверной базы данных, составляет 3 ГБ/виртуальные ядра, чем максимальное количество виртуальных ядер, настроенных по сравнению с более чем 5 ГБ/виртуальными ядрами, тем же числом виртуальных ядер в подготовленных вычислительных ресурсах. Дополнительные сведения см . в ограничениях бессерверных ресурсов гипермасштабирования.

Вопросы о масштабируемости

Сколько времени займет увеличение и уменьшение масштаба вычислительной реплики?

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

Переходит ли база данных в автономный режим при увеличении и уменьшении масштаба?

№ База данных остается в сети во время операций увеличения масштаба или уменьшения масштаба.

Следует ли ожидать, что при выполнении операций масштабирования происходит падение подключения?

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

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

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

Увеличивается ли размер базы данных `tempdb` и кэша RBPEX с увеличением масштаба вычислительных ресурсов?

Да. Размер tempdb кэша базы данных и RBPEX на вычислительных узлах увеличивается автоматически по мере увеличения числа ядер. Дополнительные сведения см. в разделе Хранилище и объем вычислительных ресурсов на уровне служб "Гипермасштабирование".

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

№ Запросы на чтение и запись принимает только первичная вычислительная реплика. Вторичные вычислительные реплики принимают запросы только на чтение.

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

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

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

Сколько вторичных реплик высокой доступности можно подготовить?

От 0 до 4. Если вы хотите изменить количество реплик, это можно сделать с помощью портала Azure или REST API.

Как подключиться ко вторичным репликам высокой доступности?

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

Разделы справки проверить, успешно ли я подключен к вторичному вычислительному реплика с помощью SQL Server Management Studio (SSMS) или других клиентских средств?

Для этого можно выполнить следующий запрос на языке T-SQL: SELECT DATABASEPROPERTYEX ('<database_name>', 'Updateability'). Результатом будет READ_ONLY, если установлено подключение к вторичной реплике только для чтения, и READ_WRITE, если подключение установлено к первичной реплике. Контекст базы данных должен иметь имя базы данных, а не master базу данных.

Можно ли создать выделенную конечную точку для вторичной реплики высокой доступности?

№ Подключиться ко вторичным репликам высокой доступности можно, указав параметр ApplicationIntent=ReadOnly. Но для именованных реплик можно использовать выделенные конечные точки.

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

№ Новое подключение с намерением только для чтения перенаправляется на произвольную вторичную реплику высокой доступности.

Можно ли увеличивать и уменьшать масштаб вторичных реплик высокой доступности независимо от первичной реплики?

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

Будет ли отличаться размер tempdb у первичной вычислительной реплики и у вторичных реплик высокой доступности?

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

Можно ли добавлять индексы и представления на вторичных вычислительных репликах?

№ Базы данных уровня "Гипермасштабирование" имеют общее хранилище, т. е. все вычислительные реплики работают с одними и теми же таблицами, индексами и другими объектами баз данных. Если вам нужны дополнительные индексы, оптимизированные для чтения на вторичных репликах, нужно сначала добавить их в первичную реплику. Вы по-прежнему можете создавать временные таблицы (имена таблиц с префиксом # или ##) для каждой вторичной реплики для хранения временных данных. Временные таблицы читают и записывают.

Какова задержка между первичной и вторичной вычислительными репликами?

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

Можно ли использовать именованную реплику в качестве целевого объекта отработки отказа?

Нет, именованную реплику нельзя использовать в качестве целевого объекта отработки отказа. Для этой цели используйте реплики высокого уровня доступности.

Как можно распределить рабочую нагрузку только для чтения между именованными репликами?

Так как каждая именованной реплика может иметь другую цель уровня обслуживания и, таким образом, использоваться для разных вариантов использования, нет встроенного способа направлять трафик только для чтения, отправляемый в основной набор именованных реплика. Например, можно использовать восемь именованных реплика, и вы можете направлять рабочую нагрузку OLTP только в именованные реплика s 1–4, а аналитические рабочие нагрузки Power BI используют именованные реплика s 5 и 6, а рабочая нагрузка обработки и анализа данных использует реплика 7 и 8. В зависимости от используемого средства или языка программирования стратегии распространения такой рабочей нагрузки могут отличаться. Пример создания решения маршрутизации рабочей нагрузки, позволяющего серверной части REST масштабироваться, просмотрите пример горизонтального масштабирования OLTP.

Может ли именованная реплика находиться в регионе, отличном от региона первичной реплики?

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

Может ли именованная реплика влиять на доступность или производительность первичной реплики?

Именованная реплика не может влиять на доступность первичной реплики. В обычных обстоятельствах именованные реплики вряд ли повлияют на производительность первичной реплики, но это может произойти, если выполняются ресурсоемкие рабочие нагрузки. Как и реплика высокой доступности, именованная реплика синхронизируется с первичной через службу журнала транзакций. Если именованная реплика по какой-либо причине не может использовать журнал транзакций достаточно быстро, она попросит первичную реплику замедлить (отрегулировать) создание журнала, чтобы не отставать. Хотя это поведение не повлияет на доступность первичного источника, это может повлиять на производительность рабочих нагрузок записи на первичном сервере. Чтобы избежать такой ситуации, убедитесь, что у ваших именованных реплик достаточно свободных ресурсов — в основном ЦП, — чтобы обрабатывать журнал транзакций без задержки. Например, если основной объект обрабатывает многочисленные изменения данных, рекомендуется назвать реплика с по крайней мере тем же целевым уровнем обслуживания, что и основной, чтобы избежать насыщения ЦП на реплика, и таким образом, принудив основной к замедлению.

Что происходит с именованными реплика, если основной реплика недоступен, например из-за планового обслуживания?

Именованные реплики будут доступны только для чтения, как обычно.

Как можно улучшить доступность именованных реплик?

По умолчанию именованные реплика не имеют собственных реплика высокого уровня доступности. Для отвода именованной реплики сначала требуется создать новую реплику, что обычно занимает около 1–2 минут. Однако именованная реплика также может использовать преимущества более высокой доступности и более коротких отработок отказа, обеспечиваемые репликами высокого уровня доступности. Чтобы добавить реплики высокого уровня доступности для именованной реплики, можно использовать параметр ha-replicas с AZ CLI или параметр HighAvailabilityReplicaCount с PowerShell или свойство highAvailabilityReplicaCount с REST API. Количество реплика высокой доступности можно задать во время создания именованного реплика и может быть изменено только с помощью AZ CLI, PowerShell или REST API в любое время после создания именованного реплика. Цены на реплики высокого уровня доступности для именованных реплик совпадают с ценами на реплики высокого уровня доступности для обычных баз данных гипермасштабирования.

Дополнительные сведения об уровне служб "Гипермасштабирование" см. в статье " Уровень служб ''Гипермасштабирование''".