Поделиться через

Диагностика и устранение неполадок с высокой загрузкой ЦП в Базе данных SQL Azure

  • Статья

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

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

Сведения о количестве виртуальных ядер

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

Определение количества виртуальных ядер на портале Azure

Вы можете быстро определить количество виртуальных ядер для базы данных на портале Azure, если вы используете уровень обслуживания на основе виртуальных ядер с уровнем подготовленных вычислительных ресурсов. В этом случае ценовая категория, указанная для базы данных на странице Обзор, будет содержать количество виртуальных ядер. Например, ценовая категория базы данных может быть "Общего назначения: стандартный ряд (5-го поколения), 16 виртуальных ядер".

Для баз данных на бессерверном уровне вычислений количество виртуальных ядер всегда эквивалентно максимальному количеству виртуальных ядер для базы данных. Количество виртуальных ядер будет показано в сведениях о ценовой категории, указанной для базы данных на странице Обзор. Например, ценовая категория базы данных может быть "Общего назначения: бессерверная, стандартная серия (5-го поколения), 16 виртуальных ядер".

Если вы используете базу данных в модели приобретения на основе DTU, для запроса количества виртуальных ядер базы данных нужно использовать Transact-SQL.

Определение количества виртуальных ядер с помощью Transact-SQL

Вы можете определить текущее количество виртуальных ядер для любой базы данных с помощью Transact-SQL. Вы можете запускать Transact-SQL для База данных SQL Azure с помощью SQL Server Management Studio (SSMS), Azure Data Studio или редактора запросов портал Azure.

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

SELECT 
    COUNT(*) as vCores
FROM sys.dm_os_schedulers
WHERE status = N'VISIBLE ONLINE';
GO

Определение причин высокой загрузки ЦП

Вы можете измерять и анализировать потребление ресурсов ЦП с помощью портала Azure, интерактивных средств хранилища запросов в SSMS и запросов Transact-SQL в SSMS и Azure Data Studio.

Портал Azure и хранилище запросов показывают статистику выполнения завершенных запросов, например метрики ЦП. Если у вас возникает текущий инцидент с высоким уровнем ЦП, который может быть вызван одним или несколькими текущими длительными запросами, определите текущие выполняемые запросы с помощью Transact-SQL.

Распространенные причины новой и необычной высокой загрузки ЦП:

  • Новые запросы в рабочей нагрузке, которые используют большой объем ЦП.
  • Увеличение частоты регулярно обновляемых запросов.
  • Снижение эффективности плана запроса, включая снижение эффективности из-за проблем в плане с учетом параметров (PSP), в результате чего один или несколько запросов потребляют больше ресурсов ЦП.
  • Существенное увеличение объемов компиляции и повторной компиляции планов запросов.
  • Базы данных, в которых в запросах используется избыточный параллелизм.

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

Рассмотрите следующие вопросы:

Примечание.

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

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

Выполните эти действия, чтобы найти процентные метрики ЦП.

  1. Перейдите к базе данных на портале Azure.
  2. В разделе Интеллектуальные средства повышения производительности в меню слева выберите Анализ производительности запросов.

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

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

Снимок экрана: анализ производительности запросов в портал Azure.

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

Запишите идентификатор запроса, чтобы подробнее изучить план запроса с помощью хранилища запросов в следующем разделе.

Просмотр планов запросов для запросов с наибольшим потреблением, выявленных на портале Azure

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

  1. Откройте SSMS.
  2. Подключитесь к Базе данных SQL Azure в обозревателе объектов.
  3. Разверните узел базы данных в обозреватель объектов.
  4. Разверните папку Хранилище запросов.
  5. Откройте область Отслеживаемые запросы.
  6. Введите идентификатор запроса в поле Запрос для отслеживания в левом верхнем левом углу экрана и нажмите клавишу ВВОД.
  7. При необходимости выберите Настройка, чтобы настроить интервал времени в зависимости от времени высокой загрузки ЦП.

На странице будут показаны планы выполнения и связанные с ними метрики для запроса за последние 24 часа.

Определение текущих запросов с помощью Transact-SQL

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

Метрики ЦП можно запрашивать с помощью SQL Server Management Studio (SSMS), Azure Data Studio или редактора запросов портал Azure. При использовании SSMS или Azure Data Studio откройте новое окно запроса и подключите его к базе данных (а не master к базе данных).

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

SELECT
    req.session_id,
    req.status,
    req.start_time,
    req.cpu_time AS 'cpu_time_ms',
    req.logical_reads,
    req.dop,
    s.login_name,
    s.host_name,
    s.program_name,
    object_name(st.objectid,st.dbid) 'ObjectName',
    REPLACE (REPLACE (SUBSTRING (st.text,(req.statement_start_offset/2) + 1,
        ((CASE req.statement_end_offset    WHEN -1    THEN DATALENGTH(st.text) 
        ELSE req.statement_end_offset END - req.statement_start_offset)/2) + 1),
        CHAR(10), ' '), CHAR(13), ' ') AS statement_text,
    qp.query_plan,
    qsx.query_plan as query_plan_with_in_flight_statistics
FROM sys.dm_exec_requests as req  
JOIN sys.dm_exec_sessions as s on req.session_id=s.session_id
CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as st
OUTER APPLY sys.dm_exec_query_plan(req.plan_handle) as qp
OUTER APPLY sys.dm_exec_query_statistics_xml(req.session_id) as qsx
ORDER BY req.cpu_time desc;
GO

Этот запрос возвращает две копии плана выполнения. Столбец query_plan содержит план выполнения из sys.dm_exec_query_plan. Эта версия плана запроса содержит только оценки количества записей и не содержит статистику выполнения.

Если столбец query_plan_with_in_flight_statistics возвращает план выполнения, он содержит дополнительные сведения. Столбец query_plan_with_in_flight_statistics возвращает данные из sys.dm_exec_query_statistics_xml, которая включает статистику выполнения "в тестовом режиме", например фактическое количество строк, возвращаемых до сих пор выполняемым запросом.

Просмотр показателей потребления ресурсов ЦП за последний час

Следующий запрос к sys.dm_db_resource_stats возвращает среднее потребление ресурсов ЦП через 15-секундные интервалы приблизительно за последний час.

SELECT
    end_time,
    avg_cpu_percent,
    avg_instance_cpu_percent
FROM sys.dm_db_resource_stats
ORDER BY end_time DESC; 
GO

Важно не сосредотачиваться только на столбце avg_cpu_percent. Столбец avg_instance_cpu_percent содержит потребление ресурсов ЦП как пользователями, так и внутренними рабочими нагрузками. Если avg_instance_cpu_percent почти равняется 100 %, ресурсы ЦП исчерпаны. В этом случае следует устранить проблемы с высоким потреблением ЦП, если пропускная способность приложения недостаточна или задержка запросов высока.

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

Примеры других запросов см. в sys.dm_db_resource_stats.

Запрос 15 запросов с наибольших использованием ЦП

Хранилище запросов отслеживает статистику выполнения запросов, в том числе потребление ресурсов ЦП. Следующий запрос возвращает 15 самых популярных запросов, которые были выполнены за последние 2 часа, отсортированные по потреблению ресурсов ЦП. Будет показано время ЦП в миллисекундах.

WITH AggregatedCPU AS 
    (SELECT
        q.query_hash, 
        SUM(count_executions * avg_cpu_time / 1000.0) AS total_cpu_ms, 
        SUM(count_executions * avg_cpu_time / 1000.0)/ SUM(count_executions) AS avg_cpu_ms, 
        MAX(rs.max_cpu_time / 1000.00) AS max_cpu_ms, 
        MAX(max_logical_io_reads) max_logical_reads, 
        COUNT(DISTINCT p.plan_id) AS number_of_distinct_plans, 
        COUNT(DISTINCT p.query_id) AS number_of_distinct_query_ids, 
        SUM(CASE WHEN rs.execution_type_desc='Aborted' THEN count_executions ELSE 0 END) AS aborted_execution_count, 
        SUM(CASE WHEN rs.execution_type_desc='Regular' THEN count_executions ELSE 0 END) AS regular_execution_count, 
        SUM(CASE WHEN rs.execution_type_desc='Exception' THEN count_executions ELSE 0 END) AS exception_execution_count, 
        SUM(count_executions) AS total_executions, 
        MIN(qt.query_sql_text) AS sampled_query_text
    FROM sys.query_store_query_text AS qt
    JOIN sys.query_store_query AS q ON qt.query_text_id=q.query_text_id
    JOIN sys.query_store_plan AS p ON q.query_id=p.query_id
    JOIN sys.query_store_runtime_stats AS rs ON rs.plan_id=p.plan_id
    JOIN sys.query_store_runtime_stats_interval AS rsi ON rsi.runtime_stats_interval_id=rs.runtime_stats_interval_id
    WHERE 
            rs.execution_type_desc IN ('Regular', 'Aborted', 'Exception') AND 
        rsi.start_time>=DATEADD(HOUR, -2, GETUTCDATE())
     GROUP BY q.query_hash), 
OrderedCPU AS 
    (SELECT *, 
    ROW_NUMBER() OVER (ORDER BY total_cpu_ms DESC, query_hash ASC) AS RN
    FROM AggregatedCPU)
SELECT *
FROM OrderedCPU AS OD
WHERE OD.RN<=15
ORDER BY total_cpu_ms DESC;
GO

Этот запрос группируется по хэшированному значению запроса. Если в столбце number_of_distinct_query_ids есть высокое значение, определите, правильно ли заданы параметры часто выполняемого запроса. Не параметризованные запросы могут быть скомпилированы при каждом выполнении, что потребляет значительные ресурсы ЦП и влияет на производительность хранилище запросов.

Чтобы узнать больше об отдельном запросе, запишите его хэш и используйте его для определения потребления ресурсов ЦП и плана запроса.

Запросите наиболее часто компилируемые запросы по хэшу запроса

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

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

SELECT TOP (20)
    query_hash,
    MIN(initial_compile_start_time) as initial_compile_start_time,
    MAX(last_compile_start_time) as last_compile_start_time,
    CASE WHEN DATEDIFF(mi,MIN(initial_compile_start_time), MAX(last_compile_start_time)) > 0
        THEN 1.* SUM(count_compiles) / DATEDIFF(mi,MIN(initial_compile_start_time), 
            MAX(last_compile_start_time)) 
        ELSE 0 
        END as avg_compiles_minute,
    SUM(count_compiles) as count_compiles
FROM sys.query_store_query AS q
GROUP BY query_hash
ORDER BY count_compiles DESC;
GO

Чтобы узнать больше об отдельном запросе, запишите его хэш и используйте его для определения потребления ресурсов ЦП и плана запроса.

Определение использования ресурсов ЦП и плана запроса для данного хэша запроса

Чтобы найти для отдельного query_hash идентификатор запроса, текст и планы выполнения, запустите приведенные ниже запрос. Будет показано время ЦП в миллисекундах.

Замените значение переменной @query_hash допустимым query_hash для рабочей нагрузки.

declare @query_hash binary(8);

SET @query_hash = 0x6557BE7936AA2E91;

with query_ids as (
    SELECT
        q.query_hash,
        q.query_id,
        p.query_plan_hash,
        SUM(qrs.count_executions) * AVG(qrs.avg_cpu_time)/1000. as total_cpu_time_ms,
        SUM(qrs.count_executions) AS sum_executions,
        AVG(qrs.avg_cpu_time)/1000. AS avg_cpu_time_ms
    FROM sys.query_store_query q
    JOIN sys.query_store_plan p on q.query_id=p.query_id
    JOIN sys.query_store_runtime_stats qrs on p.plan_id = qrs.plan_id
    WHERE q.query_hash = @query_hash
    GROUP BY q.query_id, q.query_hash, p.query_plan_hash)
SELECT qid.*,
    qt.query_sql_text,
    p.count_compiles,
    TRY_CAST(p.query_plan as XML) as query_plan
FROM query_ids as qid
JOIN sys.query_store_query AS q ON qid.query_id=q.query_id
JOIN sys.query_store_query_text AS qt on q.query_text_id = qt.query_text_id
JOIN sys.query_store_plan AS p ON qid.query_id=p.query_id and qid.query_plan_hash=p.query_plan_hash
ORDER BY total_cpu_time_ms DESC;
GO

Этот запрос возвращает одну строку для каждого варианта плана выполнения для query_hash за весь период использования вашего хранилища запросов. Результаты сортируются по суммарному времени использования ЦП.

Использование интерактивных средств хранилища запросов для отслеживания использования ЦП за прошлые периоды

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

  1. Откройте SSMS и подключите к базе данных в обозревателе объектов.
  2. В обозревателе объектов разверните узел "Базы данных".
  3. Разверните папку Хранилище запросов.
  4. Откройте область Общее потребление ресурсов.

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

Снимок экрана: представление

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

Использование интерактивных средств хранилища запросов в SSMS, чтобы определить запросы, потребляющие больше всего времени ЦП

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

Снимок экрана: область

В представлении по умолчанию на области Основные запросы, потребляющие ресурсы, показаны запросы по показателю Длительность (мс). Иногда длительность может быть меньше времени ЦП: запросы с помощью параллелизма могут использовать гораздо больше времени ЦП, чем общая длительность. Длительность также может быть выше времени ЦП, если время ожидания имеет значительное значение. Чтобы отобрать запросы по ЦП, выберите в левом верхнем углу области раскрывающееся меню Метрика и выберите Время ЦП (мс).

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

Примечание.

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

Уменьшение потребления ресурсов ЦП

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

Рассмотрите следующие стратегии в этом разделе.

Уменьшение потребления ресурсов ЦП с помощью автоматической настройки индекса

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

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

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

Уменьшение потребления ресурсов ЦП с помощью автоматической корректировки плана (принудительного плана)

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

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

Настройка индексов вручную

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

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

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

Настройка параметров приложения, запросов и базы данных

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

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

Если вы определяете случаи, когда запросы иногда используют план выполнения, который не является оптимальным для производительности, просмотрите решения в запросах, которые проблемы с конфиденциальным планом параметров (PSP)

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

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

Уменьшение потребления ресурсов ЦП за счет настройки максимальной степени параллелизма

Параметр Максимальная степень параллелизма (MAXDOP) управляет параллелизмом в ядре СУБД. Более высокие значения MAXDOP обычно приводят к большему количеству параллельных потоков на запрос и более быстрому выполнению запроса.

В некоторых случаях одновременное выполнение большого количества запросов параллельно может замедлить рабочую нагрузку и вызвать высокое потребление ресурсов ЦП. Избыточный параллелизм чаще всего возникает в базах данных с большим количеством виртуальных ядер, где в качестве значения MAXDOP задано большое число или ноль. Если MAXDOP равно нулю, ядро СУБД устанавливает количество дополнительных планировщиков, которые будут использоваться параллельными потоками, равным общему количеству логических процессоров или 64, в зависимости от того, что меньше.

С помощью Transact-SQL можно определить максимальную степень параллельности в базе данных. Подключитесь к базе данных с помощью SSMS или Azure Data Studio и запустите следующий запрос:

SELECT 
    name, 
    value, 
    value_for_secondary, 
    is_value_default 
FROM sys.database_scoped_configurations
WHERE name=N'MAXDOP';
GO

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

Когда нужно добавить ресурсы ЦП

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

Вы можете добавить дополнительные ресурсы ЦП в Базу данных SQL Azure, настроив конфигурацию оборудования для баз данных с помощью модели приобретения на основе виртуальных ядер.

В модели приобретения на основе DTU вы можете повысить уровень обслуживания и увеличить количество единиц транзакций базы данных (DTU). Единицы транзакций базы данных рассчитываются на основе показателей ЦП, памяти, операций чтения и записи. Одним из преимуществ модели приобретения на основе виртуальных ядер является возможность более детального управления используемым оборудованием и количеством виртуальных ядер. Вы можете осуществить перенос Базы данных SQL Azure из модели на основе единиц DTU в модель на основе виртуальных ядер для перехода с одной модели приобретения на другую.

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

Ознакомьтесь с дополнительными сведениями о мониторинге и настройке производительности Базы данных SQL Azure в следующих статьях: