Перенос базы данных SQL Azure из модели на основе DTU в модель на основе виртуальных ядер

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

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

Перенос базы данных

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

Базу данных можно перенести в другую модель приобретения с помощью портала Azure, PowerShell, Azure CLI и Transact-SQL.

$parameters = @{
     ResourceGroupName = "<resource group name>"
     DatabaseName = "<database name>"
     ServerName = "<server name>"
     Edition = "<service tier, such as Hyperscale>"
     RequestedServiceObjectiveName = "<hardware such as HS_Gen5_2>"
}

Set-AzSqlDatabase @parameters

az sql db update --resource-group "<resource group name>" --server "<server name>" --name "<database name>" --edition <service tier, such as Hyperscale> --capacity 4 --family Gen5

ALTER DATABASE <database name> MODIFY (EDITION = '<service tier, such as Hyperscale>');

Выбор уровня службы "Виртуальное ядро" и объекта службы

Для большинства сценариев миграции с DTU на виртуальные ядра базы данных и эластичные пулы на уровнях служб "Базовый" и "Стандартный" соответствуют уровню служб общего назначения. Базы данных и эластичные пулы на уровне обслуживания "Премиум" соответствуют уровню обслуживания Критически важный для бизнеса. В зависимости от сценария и требований приложения уровень служб гипермасштабирования часто можно использовать в качестве целевого объекта миграции для баз данных и эластичных пулов во всех уровнях служб DTU.

Чтобы выбрать цель службы или размер вычислительных ресурсов для перенесенной базы данных в модели виртуальных ядер, можно использовать базовое, но приблизительное правило: каждые 100 единиц в единицах DTU на уровнях "Базовый" или "Стандартный" требуют не менее 1 виртуального ядра, а для каждого 125 единиц в единицах DTU на уровне "Премиум" требуется не менее 1 виртуального ядра.

В модели DTU система может выбрать любую доступную конфигурацию оборудования для базы данных или эластичного пула. Таким образом, в модели на основе DTU вы можете получить только непрямое регулирование количества виртуальных ядер (логических центральных процессоров (ЦП)), выбрав более высокие или более низкие значения DTU или eDTU.

При использовании модели на основе виртуальных ядер клиентам необходимо явно выбрать как конфигурацию оборудования, так и число виртуальных ядер (логических ЦП). Хотя модель DTU не предлагает эти варианты, тип оборудования и количество логических ЦП, используемых для каждой базы данных и эластичного пула, предоставляются с помощью динамических административных представлений. Это позволяет точнее определить соответствующую цель службы виртуального ядра.

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

Сопоставление DTU с виртуальным ядром

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

Примеры сценариев переноса с использованием этого подхода приведены в разделе Примеры.

Выполните этот запрос в контексте переносимой базы данных, а не в базе данных master. При переносе эластичного пула выполните запрос в контексте любой базы данных в пуле.

;WITH dtu_vcore_map
AS (
    SELECT rg.slo_name,
        CAST(DATABASEPROPERTYEX(DB_NAME(), 'Edition') AS NVARCHAR(40)) COLLATE DATABASE_DEFAULT AS dtu_service_tier,
        CASE 
            WHEN slo.slo_name LIKE '%SQLG4%' THEN 'Gen4' --Gen4 is retired.
            WHEN slo.slo_name LIKE '%SQLGZ%' THEN 'Gen4' --Gen4 is retired.
            WHEN slo.slo_name LIKE '%SQLG5%' THEN 'standard_series'
            WHEN slo.slo_name LIKE '%SQLG6%' THEN 'standard_series'
            WHEN slo.slo_name LIKE '%SQLG7%' THEN 'standard_series'
            WHEN slo.slo_name LIKE '%GPGEN8%' THEN 'standard_series'
            END COLLATE DATABASE_DEFAULT AS dtu_hardware_gen,
        s.scheduler_count * CAST(rg.instance_cap_cpu / 100. AS DECIMAL(3, 2)) AS dtu_logical_cpus,
        CAST((jo.process_memory_limit_mb / s.scheduler_count) / 1024. AS DECIMAL(4, 2)) AS dtu_memory_per_core_gb
    FROM sys.dm_user_db_resource_governance AS rg
    CROSS JOIN (
        SELECT COUNT(1) AS scheduler_count
        FROM sys.dm_os_schedulers
        WHERE status COLLATE DATABASE_DEFAULT = 'VISIBLE ONLINE'
        ) AS s
    CROSS JOIN sys.dm_os_job_object AS jo
    CROSS APPLY (SELECT UPPER(rg.slo_name) COLLATE DATABASE_DEFAULT AS slo_name) slo
    WHERE rg.dtu_limit > 0
        AND DB_NAME() COLLATE DATABASE_DEFAULT <> 'master'
        AND rg.database_id = DB_ID()
)
SELECT dtu_logical_cpus,
    dtu_memory_per_core_gb,
    dtu_service_tier,
    CASE 
        WHEN dtu_service_tier = 'Basic' THEN 'General Purpose'
        WHEN dtu_service_tier = 'Standard' THEN 'General Purpose or Hyperscale'
        WHEN dtu_service_tier = 'Premium' THEN 'Business Critical or Hyperscale'
        END AS vcore_service_tier,
    CASE 
        WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus * 1.7
        WHEN dtu_hardware_gen = 'standard_series' THEN dtu_logical_cpus
        END AS standard_series_vcores,
    5.05 AS standard_series_memory_per_core_gb,
    CASE 
        WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus
        WHEN dtu_hardware_gen = 'standard_series' THEN dtu_logical_cpus * 0.8
        END AS Fsv2_vcores,
    1.89 AS Fsv2_memory_per_core_gb,
    CASE 
        WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus * 1.4
        WHEN dtu_hardware_gen = 'standard_series' THEN dtu_logical_cpus * 0.9
        END AS M_vcores,
    29.4 AS M_memory_per_core_gb
FROM dtu_vcore_map;

Дополнительные факторы

Помимо количества виртуальных ядер (логических ЦП) и типа оборудования, некоторые другие факторы могут повлиять на выбор цели службы виртуальных ядер:

• Сопоставление запроса Transact-SQL соответствует целям службы DTU и виртуальных ядер в отношении их вычислительной мощности, что делает результаты более точными для задач, зависящих от производительности процессора.

• Для того же типа оборудования и того же количества виртуальных ядер ограничения ресурсов пропускной способности IOPS и журнала транзакций для баз данных виртуальных ядер часто выше, чем для баз данных DTU. Для рабочих нагрузок, связанных с операцией ввода-вывода, можно уменьшить количество виртуальных ядер в модели vCore, чтобы обеспечить тот же уровень производительности. Фактические ограничения ресурсов для баз данных с DTU и виртуальными ядрами показаны в представлении sys.dm_user_db_resource_governance. Сравнение этих значений между базой данных или пулом DTU, которые необходимо перенести, и базой данных или пулом виртуальных ядер с приблизительно соответствующей целью обслуживания может помочь вам более точно выбрать цель обслуживания виртуальных ядер.

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

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

• При переносе баз данных с временными или непредсказуемыми шаблонами использования рассмотрите возможность использования бессерверного уровня вычислений для База данных SQL Azure уровня вычислений. Максимальное число одновременных рабочих в бессерверном режиме составляет 75 % от лимита в вычислительных мощностях для того же числа настроенных максимальных виртуальных ядер. Также максимальный объем доступной памяти в бессерверной конфигурации составляет 3 ГБ, умноженные на настроенное максимальное число виртуальных ядер, что меньше предоставляемой на каждое ядро памяти для подготовленных вычислений. Например, для поколения 5 максимальный объем памяти в бессерверной конфигурации составит 120 ГБ, если настроено ограничение в 40 виртуальных ядер, а для подготовленных вычислений при 40 виртуальных ядрах это значение составит 204 ГБ.

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

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

• Некоторые конфигурации оборудования могут быть недоступны в каждом регионе. Проверьте доступность в разделе "Конфигурация оборудования для Базы данных SQL".

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

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

Примеры переноса DTU на виртуальное ядро

Перенос стандартной базы данных S9

Запрос сопоставления возвращает следующий результат (некоторые столбцы, не показанные для наглядности):

Мы видим, что стандартная база данных DTU имеет 24 логических ЦП (виртуальные ядра) с 5,4 ГБ памяти на виртуальное ядро. Прямым аналогом этого является база данных общего назначения с 2 виртуальными ядрами на оборудовании стандартной серии (пятого поколения) с целевой задачей сервиса GP_Gen5_24.

Перенос стандартной базы данных S0

Запрос сопоставления возвращает следующий результат (некоторые столбцы, не показанные для наглядности):

Мы видим, что база данных DTU имеет эквивалент 0,25 логических ЦП (виртуальных ядер) с 1,3 ГБ памяти на виртуальное ядро. Наименьшие цели службы виртуальных ядер в стандартной серии оборудования (5-го поколения) GP_Gen5_2 предоставляют больше вычислительных ресурсов, чем база данных Standard S0, поэтому прямое сопоставление невозможно. Вариант GP_Gen5_2 предпочтителен. Кроме того, если рабочая нагрузка хорошо подходит для бессерверного уровня вычислений, то GP_S_Gen5_1 будет более подходящим вариантом.

Перенос базы данных Премиум P15

Запрос сопоставления возвращает следующий результат (некоторые столбцы, не показанные для наглядности):

Мы видим, что база данных DTU имеет 42 логических ЦП (виртуальные ядра) с 4,86 ГБ памяти на виртуальное ядро. Хотя нет цели службы виртуальных ядер с 42 ядрами, цель службы BC_Gen5_40 почти эквивалентна с точки зрения емкости ЦП и памяти и является хорошим совпадением.

Перенос эластичного пула 200 eDTU базового уровня

Запрос сопоставления возвращает следующий результат (некоторые столбцы, не показанные для наглядности):

Мы видим, что эластичные пулы DTU имеют 4 логических ЦП (виртуальные ядра) с 5,4 ГБ памяти на каждое виртуальное ядро. Аппаратное обеспечение стандартной серии требует 4 виртуальных ядра, однако эта целевая служебная конфигурация поддерживает максимум 200 баз данных на пул, тогда как эластичный пул уровня "Базовый" на 200 eDTU поддерживает до 500 баз данных. Если переносимый эластичный пул содержит более 200 баз данных, соответствующей целью службы виртуального ядра должно быть GP_Gen5_6 с поддержкой до 500 баз данных.

Перенос геореплицируемых баз данных

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

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

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

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

В следующей таблице приведены рекомендации для конкретных сценариев переноса:

Перенос групп аварийного переключения

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

Создание вторичной базы данных для георепликации

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

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

Используйте копию базы данных для миграции с DTU на vCore

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

Вы можете скопировать любую базу данных с объемом вычислительных ресурсов на основе DTU в базу данных с размером вычислительных ресурсов на основе виртуальных ядер с помощью PowerShell, Azure CLI или Transact-SQL без ограничений или специальных последовательностей, если целевой размер вычислительных ресурсов поддерживает максимальный размер базы данных-источника. Копирование базы данных на другой уровень служб не поддерживается в портал Azure.

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

• Ограничения ресурсов для отдельных баз данных с использованием модели приобретения виртуального ядра
• Ограничения ресурсов для эластичных пулов в рамках модели покупки vCore