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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

№

Да, операции сжатия баз данных и файлов в настоящее время находятся в предварительной версии. Дополнительные сведения о предварительной версии см. в разделе "Сжатие" для База данных SQL Azure гипермасштабирования.

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

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

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

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

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

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

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

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

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

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

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

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

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

Клиентское приложение может считывать данные из службы хранилища 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) или с несколькими источниками. Вы можете создать всего несколько реплик для горизонтального увеличения масштаба рабочих нагрузок только для чтения.

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

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

Да.

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

Да. Дополнительные сведения см. в статье "Эластичные пулы с гипермасштабированием" и "Блог: эластичные пулы с гипермасштабированием" теперь общедоступны.

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

Да.

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

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

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

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

№ Формат хранения баз данных уровня "Гипермасштабирование" отличается от формата, используемого в выпусках 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 на вычислительных узлах увеличивается автоматически по мере увеличения числа ядер. Дополнительные сведения см. в разделе Хранилище и объем вычислительных ресурсов на уровне служб "Гипермасштабирование".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да. Главный ключ столбца хранится в пользовательской базе данных и может быть проверен путем выполнения запроса SELECT * FROM sys.column_master_keys. Именованные реплики и вторичные реплики высокого уровня доступности считывают данные с одного и того же уровня страниц или уровня хранилища, что и база данных гипермасштабирования. Оба типа реплик синхронизированы с основной базой данных гипермасштабирования через службу журналов. Изменение ключа считается транзакцией и автоматически реплицируется в именованную реплику и вторичную реплика высокой доступности.

Функция, выполняемая DATABASEPROPERTYEX() в контексте именованной реплики, может сопоставить replica_id ее с соответствующей именованной репликой. Однако в настоящее время невозможно связать replica_id ее с соответствующей именованной репликой для каждой sys.dm_database_replica_states записи в динамическом представлении управления при запросе из первичной реплики. Следующий пример запроса можно выполнить в контексте именованной реплики, чтобы определить имя реплики, идентификатор реплики и сведения о синхронизации.

  SELECT replica_id, DB_NAME() AS 'Database/Replica name', 
  synchronization_state_desc, log_send_queue_size/1024.0/1024.0 AS log_send_queue_size_gb,
  last_sent_time, last_received_time, last_commit_time, secondary_lag_seconds
  FROM sys.dm_database_replica_states
  WHERE replica_id = DATABASEPROPERTYEX(DB_NAME(),'REPLICAID');

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

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