Diagnostika a řešení potíží s vysokým využitím procesoru ve službě Azure SQL Database

  • Článek

Platí pro:Azure SQL Database

Azure SQL Database poskytuje integrované nástroje pro identifikaci příčin vysokého využití procesoru a optimalizace výkonu úloh. Tyto nástroje můžete použít k řešení potíží s vysokým využitím procesoru, když k němu dochází, nebo reaktivním způsobem po dokončení incidentu. Automatické ladění můžete také povolit, abyste proaktivně snížili využití procesoru v průběhu času pro vaši databázi. Tento článek vás naučí diagnostikovat a řešit potíže s vysokým využitím procesoru pomocí integrovaných nástrojů ve službě Azure SQL Database a vysvětluje , kdy přidat prostředky procesoru.

Vysvětlení počtu virtuálních jader

Při diagnostice vysokého incidentu procesoru je užitečné porozumět počtu virtuálních jader dostupných pro vaši databázi. Virtuální jádro je ekvivalentní logickému procesoru. Počet virtuálních jader vám pomůže pochopit prostředky procesoru dostupné pro vaši databázi.

Identifikace počtu virtuálních jader na webu Azure Portal

Počet virtuálních jader pro databázi můžete rychle identifikovat na webu Azure Portal, pokud používáte úroveň služby založenou na virtuálních jádrech se zřízenou výpočetní úrovní. V takovém případě bude cenová úroveň uvedená pro databázi na stránce Přehled obsahovat počet virtuálních jader. Cenová úroveň databáze může být například "Pro obecné účely: Řada Standard (Gen5), 16 virtuálních jader".

U databází na úrovni výpočetních prostředků bez serveru bude počet virtuálních jader vždy odpovídat nastavení maximálního počtu virtuálních jader pro databázi. Počet virtuálních jader se zobrazí v cenové úrovni uvedené pro databázi na stránce Přehled . Cenová úroveň databáze může být například "Pro obecné účely: Bezserverová řada, řada Standard (Gen5), 16 virtuálních jader".

Pokud používáte databázi v nákupním modelu založeném na DTU, budete muset k dotazování počtu virtuálních jader databáze použít Transact-SQL.

Identifikace počtu virtuálních jader pomocí jazyka Transact-SQL

Aktuální počet virtuálních jader můžete identifikovat pro libovolnou databázi pomocí jazyka Transact-SQL. Transact-SQL můžete spouštět ve službě Azure SQL Database pomocí aplikace SQL Server Management Studio (SSMS), Azure Data Studia nebo editoru dotazů na webu Azure Portal.

Připojení do databáze a spusťte následující dotaz:

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

Identifikace příčin vysokého využití procesoru

Využití procesoru můžete měřit a analyzovat pomocí webu Azure Portal, interaktivních nástrojů úložiště dotazů v SSMS a dotazů Transact-SQL v SSMS a Azure Data Studiu.

Na webu Azure Portal a v úložišti dotazů se zobrazují statistiky spouštění dokončených dotazů, jako jsou metriky procesoru. Pokud dochází k aktuálnímu vysokému incidentu procesoru, který může být způsobený jedním nebo několika probíhajícími dlouhotrvajícími dotazy, identifikujte aktuálně spuštěné dotazy pomocí jazyka Transact-SQL.

Mezi běžné příčiny nového a neobvyklého vysokého využití procesoru patří:

  • Nové dotazy v úloze, které používají velké množství procesoru.
  • Zvýšení četnosti pravidelně spouštěných dotazů.
  • Regrese plánu dotazů, včetně regrese kvůli problémům s plánem citlivým na parametry (PSP), což vede k tomu, že jeden nebo více dotazů spotřebovává více procesoru.
  • Významné zvýšení množství kompilace nebo rekompilace plánů dotazů.
  • Databáze, ve kterých dotazy používají nadměrný paralelismus.

Pokud chcete zjistit, co způsobuje vysoké využití procesoru, zjistěte, kdy dochází k vysokému využití procesoru v databázi, a nejčastější dotazy využívající procesor v tuto chvíli.

Zkoumat:

Poznámka:

Azure SQL Database vyžaduje výpočetní prostředky k implementaci základních funkcí služby, jako je vysoká dostupnost a zotavení po havárii, zálohování a obnovení databáze, monitorování, úložiště dotazů, automatické ladění atd. Použití těchto výpočetních prostředků může být obzvláště patrné u databází s nízkým počtem virtuálních jader nebo databázemi v hustých elastických fondech. Další informace o správě prostředků ve službě Azure SQL Database

Pomocí webu Azure Portal můžete sledovat různé metriky procesoru, včetně procenta dostupného procesoru používaného databází v průběhu času. Azure Portal kombinuje metriky procesoru s informacemi z úložiště dotazů vaší databáze, což umožňuje zjistit, které dotazy spotřebovávají procesor v databázi v daném okamžiku.

Pokud chcete najít metriky procent procesoru, postupujte podle těchto kroků.

  1. Přejděte k databázi na webu Azure Portal.
  2. V části Inteligentní výkon v nabídce vlevo vyberte Query Performance Insight.

Výchozí zobrazení Query Performance Insight zobrazuje 24 hodin dat. Využití procesoru se zobrazuje jako procento celkového dostupného procesoru použitého pro databázi.

Prvních pět dotazů spuštěných v daném období se zobrazuje ve svislých pruhech nad grafem využití procesoru. Vyberte pruh času v grafu nebo pomocí nabídky Přizpůsobit můžete prozkoumat konkrétní časová období. Můžete také zvýšit počet zobrazených dotazů.

Screenshot shows Query Performance Insight in the Azure portal.

Výběrem každého ID dotazu s vysokým využitím procesoru otevřete podrobnosti pro dotaz. Podrobnosti zahrnují text dotazu spolu s historií výkonu dotazu. Zkontrolujte, jestli se u dotazu v poslední době zvýšil procesor.

Poznamenejte si ID dotazu, abyste plán dotazu mohli podrobněji prozkoumat pomocí úložiště dotazů v následující části.

Kontrola plánů dotazů pro nejčastější dotazy identifikované na webu Azure Portal

Pomocí těchto kroků můžete v interaktivních nástrojích úložiště dotazů SSMS použít ID dotazu k prozkoumání plánu provádění dotazu v průběhu času.

  1. Otevřete aplikaci SSMS.
  2. Připojení do služby Azure SQL Database v Průzkumník objektů.
  3. Rozbalte uzel databáze v Průzkumník objektů.
  4. Rozbalte složku Úložiště dotazů.
  5. Otevřete podokno Sledované dotazy.
  6. Do pole sledovacího dotazu v levém horním rohu obrazovky zadejte ID dotazu a stiskněte enter.
  7. V případě potřeby vyberte Konfigurovat a upravte časový interval tak, aby odpovídal době, kdy došlo k vysokému využití procesoru.

Na stránce se zobrazí plány provádění a související metriky dotazu za posledních 24 hodin.

Identifikace aktuálně spuštěných dotazů pomocí jazyka Transact-SQL

Transact-SQL umožňuje identifikovat aktuálně spuštěné dotazy s časem procesoru, který dosud používal. Transact-SQL můžete také použít k dotazování nedávného využití procesoru v databázi, nejčastějších dotazů podle procesoru a dotazů, které se kompilovaly nejčastěji.

Metriky procesoru můžete dotazovat pomocí aplikace SQL Server Management Studio (SSMS), Nástroje Azure Data Studio nebo editoru dotazů na webu Azure Portal. Pokud používáte SSMS nebo Azure Data Studio, otevřete nové okno dotazu a připojte ho k databázi (ne k master databázi).

Spuštěním následujícího dotazu vyhledejte aktuálně spuštěné dotazy s využitím procesoru a plány spouštění. Čas procesoru se vrátí v milisekundách.

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

Tento dotaz vrátí dvě kopie plánu provádění. Sloupec query_plan obsahuje plán provádění z sys.dm_exec_query_plan. Tato verze plánu dotazu obsahuje pouze odhady počtu řádků a neobsahuje žádné statistiky provádění.

Pokud sloupec query_plan_with_in_flight_statistics vrátí plán provádění, poskytne tento plán další informace. Sloupec query_plan_with_in_flight_statistics vrací data z sys.dm_exec_query_statistics_xml, která zahrnují statistiky provádění "v letu", jako je skutečný počet řádků vrácených zatím spuštěným dotazem.

Kontrola metrik využití procesoru za poslední hodinu

Následující dotaz sys.dm_db_resource_stats vrátí průměrné využití procesoru za přibližně poslední hodinu v 15sekundových intervalech.

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

Je důležité se nezaměřovat jenom na avg_cpu_percent sloupec. Sloupec avg_instance_cpu_percent obsahuje procesor používaný uživateli i interními úlohami. Pokud avg_instance_cpu_percent je blízko 100 %, prostředky procesoru jsou nasycené. V takovém případě byste měli řešit potíže s vysokým využitím procesoru, pokud propustnost aplikace není dostatečná nebo je vysoká latence dotazů.

Další informace o správě prostředků ve službě Azure SQL Database

Další dotazy najdete v příkladech v sys.dm_db_resource_stats .

Dotazování na posledních 15 dotazů podle využití procesoru

Úložiště dotazů sleduje statistiky provádění, včetně využití procesoru, pro dotazy. Následující dotaz vrátí prvních 15 dotazů, které se spustily za posledních 2 hodiny seřazené podle využití procesoru. Čas procesoru se vrátí v milisekundách.

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

Tento dotaz seskupí podle hodnoty hash dotazu. Pokud ve sloupci najdete vysokou hodnotu number_of_distinct_query_ids , prozkoumejte, jestli často spuštěný dotaz není správně parametrizovaný. Neparametrizované dotazy se můžou zkompilovat při každém spuštění, které spotřebovávají významný procesor a ovlivňují výkon úložiště dotazů.

Pokud chcete získat další informace o jednotlivých dotazech, poznamenejte si hodnotu hash dotazu a použijte ji k identifikaci využití procesoru a plánu dotazů pro danou hodnotu hash dotazu.

Dotazování nejčastěji kompilovaných dotazů pomocí hodnoty hash dotazu

Kompilace plánu dotazů je proces náročný na procesor. Plány mezipaměti Azure SQL Database v paměti pro opakované použití Některé dotazy mohou být často kompilovány, pokud nejsou parametrizovány nebo pokud rady RECOMPILE vynucují rekompilace.

Úložiště dotazů sleduje, kolikrát se dotazy kompilují. Spuštěním následujícího dotazu identifikujte prvních 20 dotazů v úložišti dotazů podle počtu kompilací spolu s průměrným počtem kompilací za minutu:

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

Pokud chcete získat další informace o jednotlivých dotazech, poznamenejte si hodnotu hash dotazu a použijte ji k identifikaci využití procesoru a plánu dotazů pro danou hodnotu hash dotazu.

Určení využití procesoru a plánu dotazů pro danou hodnotu hash dotazu

Spuštěním následujícího dotazu vyhledejte individuální ID dotazu, text dotazu a plány provádění dotazů pro danou query_hashosobu . Čas procesoru se vrátí v milisekundách.

Nahraďte hodnotu proměnné platnou @query_hashquery_hash pro vaši úlohu.

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

Tento dotaz vrátí jeden řádek pro každou variantu plánu provádění pro query_hash celou historii úložiště dotazů. Výsledky se seřadí podle celkového času procesoru.

Použití interaktivních nástrojů úložiště dotazů ke sledování historického využití procesoru

Pokud raději používáte grafické nástroje, použijte interaktivní nástroje úložiště dotazů v SSMS pomocí těchto kroků.

  1. Otevřete SSMS a připojte se k databázi v Průzkumník objektů.
  2. Rozbalení uzlu databáze v Průzkumník objektů
  3. Rozbalte složku Úložiště dotazů.
  4. Otevřete podokno Celkové využití prostředků.

Celkový čas procesoru pro vaši databázi za poslední měsíc v milisekundách se zobrazuje v levé dolní části podokna. Ve výchozím zobrazení se čas procesoru agreguje podle dne.

Screenshot shows the Overall Resource Consumption view of Query Store in SSMS.

Výběrem možnosti Konfigurovat v pravém horním rohu podokna vyberte jiné časové období. Můžete také změnit jednotku agregace. Můžete například zobrazit data pro konkrétní rozsah kalendářních dat a agregovat data po hodinách.

Použití interaktivních nástrojů úložiště dotazů k identifikaci nejčastějších dotazů podle času procesoru

Výběrem pruhu v grafu přejdete k podrobnostem a zobrazíte dotazy spuštěné v určitém časovém období. Otevře se podokno Dotazy s nejvyšším využitím prostředků. Alternativně můžete otevřít dotazy s nejvyšším využitím prostředků z uzlu Úložiště dotazů v databázi přímo v Průzkumník objektů.

Screenshot shows the Top Resource Consuming Queries pane for Query Store in S S M S.

Ve výchozím zobrazení se v podokně Dotazy s nejvyšším využitím prostředků zobrazují dotazy podle doby trvání (ms). Doba trvání může být někdy nižší než čas procesoru: dotazy používající paralelismus můžou používat mnohem více času procesoru než jejich celková doba trvání. Doba trvání může být vyšší než doba využití procesoru, pokud jsou významné doby čekání. Pokud chcete zobrazit dotazy podle času procesoru, vyberte rozevírací seznam Metriky v levém horním rohu podokna a vyberte Čas procesoru (ms).

Každý pruh v levém horním kvadrantu představuje dotaz. Výběrem pruhu zobrazíte podrobnosti pro tento dotaz. Pravý horní kvadrant obrazovky ukazuje, kolik plánů provádění je v úložišti dotazů pro daný dotaz a mapuje je podle toho, kdy byly provedeny a kolik z vybrané metriky se použilo. Výběrem každého ID plánu můžete určit, který plán provádění dotazů se zobrazí v dolní polovině obrazovky.

Poznámka:

Průvodce interpretací zobrazení úložiště dotazů a obrazců, které se zobrazují v zobrazení Hlavní příjemci prostředků, najdete v tématu Osvědčené postupy pro úložiště dotazů.

Snížení využití procesoru

Součástí řešení potíží by mělo být další informace o dotazech identifikovaných v předchozí části. Využití procesoru můžete snížit laděním indexů, úpravou vzorů aplikací, laděním dotazů a úpravou nastavení souvisejících s procesorem pro vaši databázi.

V této části zvažte následující strategie.

Snížení využití procesoru pomocí automatického ladění indexu

Efektivní ladění indexů snižuje využití procesoru pro mnoho dotazů. Optimalizované indexy snižují logické a fyzické čtení dotazu, což často vede k tomu, že dotaz potřebuje méně práce.

Azure SQL Database nabízí automatickou správu indexů pro úlohy na primárních replikách. Automatická správa indexů pomocí strojového učení monitoruje úlohy a optimalizuje neclusterované indexy disku založené na úložišti řádků pro vaši databázi.

Zkontrolujte doporučení k výkonu, včetně doporučení indexů, na webu Azure Portal. Tato doporučení můžete použít ručně nebo povolit možnost automatického ladění CREATE INDEX a vytvořit a ověřit výkon nových indexů ve vaší databázi.

Snížení využití procesoru pomocí automatické opravy plánu (vynucený plán)

Další běžnou příčinou vysokého počtu incidentů procesoru je regrese plánu provádění. Azure SQL Database nabízí možnost automatického ladění vynuceného plánu pro identifikaci regresí v plánech spouštění dotazů v úlohách na primárních replikách. Když je tato funkce automatického ladění povolená, Azure SQL Database otestuje, jestli vynucení plánu provádění dotazů vede ke spolehlivému lepšímu výkonu dotazů s regresí plánu provádění.

Pokud byla vaše databáze vytvořena po březnu 2020, byla možnost automatického ladění plánu vynucení povolena automaticky. Pokud byla vaše databáze vytvořena před tímto časem, možná budete chtít povolit možnost automatického ladění plánu vynucení.

Ruční ladění indexů

Pomocí metod popsaných v tématu Identifikace příčin vysokého využití procesoru identifikujte plány dotazů pro dotazy s nejvyšším využitím procesoru. Tyto plány provádění vám pomůžou identifikovat a přidat neclusterované indexy , které urychlí vaše dotazy.

Každý neclusterovaný index na disku v databázi vyžaduje místo na úložišti a musí ho udržovat modul SQL. Pokud je to možné, upravte existující indexy místo přidávání nových indexů a ujistěte se, že nové indexy úspěšně snižují využití procesoru. Přehled neclusterovaných indexů najdete v tématu Pokyny k návrhu neclusterovaného indexu.

U některých úloh může být indexy columnstore nejlepší volbou pro snížení procesoru častých dotazů na čtení. Viz indexy Columnstore – Pokyny k návrhu pro doporučení vysoké úrovně pro scénáře, kdy mohou být indexy columnstore vhodné.

Ladění nastavení aplikace, dotazů a databáze

Při zkoumání nejčastějších dotazů můžete najít antipatterny aplikací, jako je "chatty" chování, úlohy, které by mohly těžit z horizontálního dělení a neoptimální návrh přístupu k databázi. U úloh náročných na čtení zvažte replikace jen pro čtení, aby se úlohy dotazů jen pro čtení a ukládání aplikační vrstvy do mezipaměti odložily jako dlouhodobé strategie horizontálního navýšení kapacity často čtených dat.

Můžete se také rozhodnout ručně ladit hlavní procesor pomocí dotazů identifikovaných ve vaší úloze. Mezi možnosti ručního ladění patří přepisování příkazů Jazyka Transact-SQL, vynucení plánů v úložišti dotazů a použití nápovědy k dotazům.

Pokud identifikujete případy, kdy dotazy někdy používají plán provádění, který není optimální pro výkon, projděte si řešení v dotazech, u kterých dochází k problémům s plánem citlivým na parametry (PSP).

Pokud identifikujete neparametrizované dotazy s velkým počtem plánů, zvažte parametrizaci těchto dotazů a ujistěte se, že plně deklarujete datové typy parametrů, včetně délky a přesnosti. To může být provedeno úpravou dotazů, vytvořením průvodce plánem vynucení parametrizace konkrétního dotazu nebo povolením vynucené parametrizace na úrovni databáze.

Pokud identifikujete dotazy s vysokou mírou kompilace, zjistěte, co způsobuje častou kompilaci. Nejčastější příčinou časté kompilace jsou rady RECOMPILE. Kdykoli je to možné, určete, kdy RECOMPILE byla nápověda přidána a jaký problém měl být vyřešen. Prozkoumejte, jestli je možné implementovat alternativní řešení ladění výkonu, aby poskytovalo konzistentní výkon pro často spuštěné dotazy bez RECOMPILE nápovědy.

Snížení využití procesoru vyladěním maximálního stupně paralelismu

Nastavení maximálního stupně paralelismu (MAXDOP) řídí paralelismus uvnitř dotazu v databázovém stroji. Vyšší hodnoty MAXDOP obvykle vedou k většímu počtu paralelních vláken na dotaz a rychlejšímu provádění dotazů.

V některých případech může velký počet paralelních dotazů spuštěných souběžně zpomalit úlohu a způsobit vysoké využití procesoru. V databázích s velkým počtem virtuálních jader, u kterých je maximální hodnota MAXDOP nastavená na vysoké číslo nebo nulu, se s největší pravděpodobností vyskytuje nadměrné paralelismus. Pokud je parametr MAXDOP nastaven na nulu, nastaví databázový stroj počet plánovačů , které mají být používány paralelními vlákny, na celkový počet logických jader nebo 64, podle toho, co je menší.

Maximální stupeň paralelismu pro vaši databázi můžete identifikovat pomocí jazyka Transact-SQL. Připojení do databáze pomocí SSMS nebo Azure Data Studia a spusťte následující dotaz:

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

Zvažte experimentování s malými změnami v konfiguraci MAXDOP na úrovni databáze nebo úpravou jednotlivých problematických dotazů tak, aby používaly nedefaultní maxDOP pomocí nápovědy k dotazu. Další informace najdete v příkladech konfigurace maximálního stupně paralelismu.

Kdy přidat prostředky procesoru

Můžete zjistit, že dotazy a indexy vaší úlohy jsou správně vyladěné nebo že ladění výkonu vyžaduje změny, které nemůžete provést v krátkodobém horizontu kvůli interním procesům nebo jiným důvodům. Přidání dalších prostředků procesoru může být pro tyto databáze přínosné. Prostředky databáze můžete škálovat s minimálními výpadky.

Do služby Azure SQL Database můžete přidat další prostředky procesoru tak, že nakonfigurujete počet virtuálních jader nebo konfiguraci hardwaru pro databáze pomocí nákupního modelu virtuálních jader.

V nákupním modelu založeném na jednotkách DTU můžete zvýšit úroveň služby a zvýšit počet jednotek databázových transakcí (DTU). DTU představuje kombinovanou míru procesoru, paměti, čtení a zápisů. Jednou z výhod nákupního modelu virtuálních jader je, že umožňuje podrobnější kontrolu nad hardwarem, který se používá, a počtem virtuálních jader. Azure SQL Database můžete migrovat z modelu založeného na DTU na model založený na virtuálních jádrech a přejít mezi nákupními modely.

Související obsah

Další informace o monitorování a ladění výkonu služby Azure SQL Database najdete v následujících článcích: