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

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

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

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

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

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

Чтобы выбрать цель службы или размер вычислительных ресурсов, для перенесенной базы данных в модели виртуальных ядер можно использовать базовое, но приблизительное правило отпечатка: каждые 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. Для рабочих нагрузок, связанных с операцией ввода-вывода, можно уменьшить количество виртуальных ядер в модели виртуальных ядер, чтобы обеспечить тот же уровень производительности. Фактические ограничения ресурсов для баз данных на основе 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 виртуальных ядер на оборудовании стандартной серии (5-го поколения), цель службы 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 баз данных на пул, а эластичные пулы EDTU уровня "Базовый" 200 поддерживают до 500 баз данных. Если переносимый эластичный пул содержит более 200 баз данных, соответствующей целью службы виртуального ядра должно быть GP_Gen5_6 с поддержкой до 500 баз данных.

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

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

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

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

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

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

Перенос групп отработки отказа

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

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

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

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

Копирование базы данных для переноса модели DTU в модель виртуального ядра

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

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

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

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