Diagnosticare e risolvere i problemi relativi all'utilizzo elevato della CPU in Database SQL di Azure
Si applica a: Database SQL di Azure
Il database SQL di Azure fornisce strumenti predefiniti per identificare le cause dell'utilizzo elevato della CPU e ottimizzare le prestazioni del carico di lavoro. È possibile usare questi strumenti per risolvere i problemi di utilizzo elevato della CPU mentre si verificano, o in modo reattivo dopo il completamento dell'evento imprevisto. È anche possibile abilitare l'ottimizzazione automatica per ridurre in modo proattivo l'utilizzo della CPU nel tempo per il database. Questo articolo illustra come diagnosticare e risolvere i problemi relativi all'utilizzo elevato della CPU con strumenti predefiniti nel database SQL di Azure e spiega quando aggiungere risorse della CPU.
Comprendere il numero di vCore
È utile comprendere il numero di core virtuali (vCore) disponibili per il database durante la diagnosi di un evento imprevisto di utilizzo elevato della CPU. Un vCore equivale a una CPU logica. Il numero di vCore consente di comprendere le risorse della CPU disponibili per il database.
Identificare il numero di vCore nel portale di Azure
È possibile identificare rapidamente il numero di vCore per un database nel portale di Azure se si usa un livello di servizio basato su vCore con il livello di calcolo con provisioning. In questo caso, il piano tariffario elencato per il database nella relativa pagina Panoramica conterrà il numero di vCore. Ad esempio, il piano tariffario di un database potrebbe essere "Utilizzo generico: serie Standard (Gen5), 16 vCore".
Per i database nel livello di calcolo serverless, il numero di vCore sarà sempre equivalente all'impostazione max vCore per il database. Il numero di vCore verrà visualizzato nel piano tariffario elencato per il database nella relativa pagina Panoramica. Ad esempio, il piano tariffario di un database potrebbe essere "Utilizzo generico: serverless, serie standard (Gen5), 16 vCore".
Se si usa un database in base al modello di acquisto basato su DTU, è necessario usare Transact-SQL per eseguire query sul numero di vCore del database.
Identificare il numero di vCore con Transact-SQL
È possibile identificare il numero di vCore corrente per qualsiasi database con Transact-SQL. È possibile eseguire Transact-SQL sul database SQL di Azure con SQL Server Management Studio (SSMS), Azure Data Studio o l'editor di query del portale di Azure.
Connettersi al database ed eseguire la query seguente:
SELECT
COUNT(*) as vCores
FROM sys.dm_os_schedulers
WHERE status = N'VISIBLE ONLINE';
GO
Identificare le cause dell'utilizzo elevato della CPU
È possibile misurare e analizzare l'utilizzo della CPU usando il portale di Azure, gli strumenti interattivi di Query Store in SSMS, e le query Transact-SQL in SSMS e Azure Data Studio.
Il portale di Azure e Query Store mostrano statistiche di esecuzione, ad esempio le metriche della CPU, per le query completate. Se si verifica un evento imprevisto corrente di utilizzo elevato della CPU che potrebbe essere causato da una o più query a esecuzione prolungata in corso, identificare le query attualmente in esecuzione con Transact-SQL.
Le cause comuni dell'utilizzo elevato nuovo e insolito della CPU sono:
- Nuove query del carico di lavoro che usano una grande quantità di CPU.
- Aumento della frequenza di esecuzione regolare delle query.
- Regressione del piano di query, inclusa la regressione a causa di problemi del piano sensibile ai parametri, che causa un utilizzo più elevato della CPU da parte di una o più query.
- Aumento significativo della compilazione o della ricompilazione dei piani di query.
- Database in cui le query usano un parallelismo eccessivo.
Per comprendere cosa sta causando l'evento imprevisto di utilizzo elevato della CPU, identificare quando si verifica un utilizzo elevato della CPU sul database e le query principali che usano la CPU in quel momento.
Verifica:
- Le nuove query che usano una CPU in maniera significativa vengono visualizzate nel carico di lavoro o si riscontra un aumento della frequenza di esecuzione regolare delle query? Usare uno dei seguenti metodi per verificare. Cercare query con cronologia limitata (nuove query) e frequenza di esecuzione per query con cronologia più lunga.
- Esaminare le metriche della CPU e le query principali correlate nel portale di Azure
- Eseguire una query sulle prime 15 query recenti in base all'utilizzo della CPU con Transact-SQL.
- Usare gli strumenti interattivi di Query Store in SSMS per identificare le query principali in base al tempo della CPU
- Alcune query nel carico di lavoro usano più CPU per esecuzione rispetto al passato? In tal caso, il piano di esecuzione della query è stato modificato? Queste query potrebbero avere problemi relativi al piano sensibile ai parametri (PSP). Usare una delle tecniche seguenti per verificare. Cercare query con più piani di esecuzione di query con variazioni significative nell'utilizzo della CPU:
- Esistono prove di una grande quantità di compilazioni o ricompilazioni in corso? Eseguire una query sulle query compilate più di frequente dall'hash delle query ed esaminare la frequenza con cui vengono compilate.
- Le query usano un parallelismo eccessivo? Eseguire una query sulla configurazione con ambito database MAXDOP ed esaminare il numero di vCore. Il parallelismo eccessivo si verifica spesso nei database in cui MAXDOP è impostato su
0
con un numero di vCore superiore a otto.
Nota
Il database SQL di Azure richiede risorse di calcolo per implementare funzionalità di base del servizio, come ad esempio disponibilità elevata e ripristino di emergenza, backup e ripristino del database, monitoraggio, Query Store, ottimizzazione automatica e così via. L'uso di queste risorse di calcolo potrebbe essere particolarmente evidente nei database con numeri di vCore bassi o database in pool elastici densi. Per saperne di più, vedere Gestione delle risorse nel database SQL di Azure.
Esaminare le metriche di utilizzo della CPU e le query principali correlate nel portale di Azure
Usare il portale di Azure per tenere traccia delle varie metriche della CPU, inclusa la percentuale di CPU disponibile usata dal database nel corso del tempo. Il portale di Azure combina le metriche della CPU con le informazioni del Query Store del database, che consente di identificare quali query hanno utilizzato la CPU nel database in un determinato momento.
Seguire questi passaggi per trovare le metriche relative alla percentuale di CPU.
- Spostarsi nel database nel portale di Azure.
- In Prestazioni intelligenti nel menu a sinistra, selezionare Informazioni dettagliate sulle prestazioni delle query.
La visualizzazione predefinita di Informazioni dettagliate sulle prestazioni delle query mostra 24 ore di dati. L'utilizzo della CPU viene visualizzato come percentuale del totale della CPU disponibile usata per il database.
Le prime cinque query in esecuzione in quel periodo vengono visualizzate in barre verticali sopra il grafico relativo all'utilizzo della CPU. Selezionare una fascia di tempo nel grafico o usare il menu Personalizza per esplorare periodi di tempo specifici. È anche possibile aumentare il numero di query visualizzate.
Selezionare ogni ID di query che presenta un utilizzo elevato della CPU per aprire i dettagli per la query. I dettagli includono il testo della query insieme alla cronologia delle prestazioni per la query. Verificare se la CPU sia aumentata di recente per la query.
Prendere nota dell'ID di query per analizzare ulteriormente il piano di query usando Query Store nella sezione seguente.
Esaminare i piani di query per le query principali identificate nel portale di Azure
Seguire questi passaggi per usare un ID di query negli strumenti interattivi di Query Store di SSMS per esaminare il piano di esecuzione della query nel tempo.
- Aprire SSMS.
- Connettersi al database SQL di Azure in Esplora oggetti.
- Espandere il nodo database in Esplora oggetti.
- Espandere la cartella Query Store.
- Aprire il riquadro Query rilevate.
- Immettere l'ID di query nella casella Rilevamento Query nella parte superiore sinistra della schermata e premere invio.
- Se necessario, selezionare Configura per regolare l'intervallo di tempo in modo che corrisponda al momento in cui si è verificato un utilizzo elevato della CPU.
La pagina mostrerà il piano o più piani di esecuzione e le metriche correlate per la query nelle ultime 24 ore.
Identificare le query attualmente in esecuzione con Transact-SQL
Transact-SQL consente di identificare le query attualmente in esecuzione con il tempo di CPU usato finora. È anche possibile usare Transact-SQL per eseguire query sull'utilizzo recente della CPU nel database, sulle query principali in base alla CPU e sulle query compilate più di frequente.
È possibile eseguire query sulle metriche della CPU con SQL Server Management Studio (SSMS), Azure Data Studio o l'editor di query del portale di Azure. Quando si usa SSMS o Azure Data Studio, aprire una nuova finestra di query e connetterla al database (non al database master
).
Trovare le query attualmente in esecuzione con i piani di utilizzo e esecuzione della CPU eseguendo la query seguente. Il tempo della CPU viene restituito in millisecondi.
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
Questa query restituisce due copie del piano di esecuzione. La colonna query_plan
contiene il piano di esecuzione da sys.dm_exec_query_plan. Questa versione del piano di query contiene solo stime dei conteggi delle righe e non contiene statistiche di esecuzione.
Se la colonna query_plan_with_in_flight_statistics
restituisce un piano di esecuzione, questo piano fornisce altre informazioni. La colonna query_plan_with_in_flight_statistics
restituisce dati da sys.dm_exec_query_statistics_xml, che include statistiche di esecuzione "in anteprima", ad esempio il numero effettivo di righe restituite finora da una query attualmente in esecuzione.
Esaminare le metriche di utilizzo della CPU per l'ultima ora
La query seguente su sys.dm_db_resource_stats
restituisce l'utilizzo medio della CPU superiore a intervalli di 15 secondi, all'incirca per l'ultima ora.
SELECT
end_time,
avg_cpu_percent,
avg_instance_cpu_percent
FROM sys.dm_db_resource_stats
ORDER BY end_time DESC;
GO
È importante non concentrarsi solo sulla colonna avg_cpu_percent
. La colonna avg_instance_cpu_percent
include la CPU usata sia dagli utenti che dai carichi di lavoro interni. Se avg_instance_cpu_percent
è vicino al 100%, le risorse della CPU sono sature. In questo caso, è consigliabile risolvere i problemi di utilizzo elevato della CPU se la velocità effettiva dell'app è insufficiente o se la latenza delle query è elevata.
Per saperne di più, vedere Gestione delle risorse nel database SQL di Azure.
Per altre query, vedere gli esempi in sys.dm_db_resource_stats.
Eseguire query sulle prime 15 query recenti in base all'utilizzo della CPU
Query Store tiene traccia delle statistiche di esecuzione, incluso l'utilizzo della CPU, per le query. La query seguente restituisce le prime 15 query eseguite nelle ultime 2 ore, ordinate in base all'utilizzo della CPU. Il tempo della CPU viene restituito in millisecondi.
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
Questa query raggruppa in base a un valore hash della query. Se si trova un valore elevato nella colonna number_of_distinct_query_ids
, verificare se una query di esecuzione frequente non sia parametrizzata correttamente. È possibile che a ogni esecuzione vengano compilate query non parametrizzate, che consumano una quantità significativa di CPU e influiscono sulle prestazioni di Query Store.
Per altre informazioni su una singola query, prendere nota dell'hash della query e usarlo per identificare l'utilizzo della CPU e il piano di query per un determinato hash di query.
Eseguire query sulle query compilate più di frequente in base all'hash delle query
La compilazione di un piano di query è un processo a elevato utilizzo di CPU. Piani di cache del database SQL di Azure in memoria per il riutilizzo. Alcune query potrebbero essere compilate di frequente se non sono parametrizzate o se gli hint RECOMPILE forzano la ricompilazione.
Query Store tiene traccia del numero di volte in cui vengono compilate le query. Eseguire la query seguente per identificare le prime 20 query in Query Store in base al numero di compilazioni, insieme al numero medio di compilazioni al minuto:
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
Per altre informazioni su una singola query, prendere nota dell'hash della query e usarlo per identificare l'utilizzo della CPU e il piano di query per un determinato hash di query.
Identificare l'utilizzo della CPU e il piano di query per un determinato hash di query
Eseguire la query seguente per trovare l'ID di query, il testo della query e i piani di esecuzione delle query per un determinato query_hash
. Il tempo della CPU viene restituito in millisecondi.
Sostituire il valore per la variabile @query_hash
con un query_hash
valido per il carico di lavoro.
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
Questa query restituisce una riga per ogni variante di un piano di esecuzione per query_hash
lungo l'intera cronologia del Query Store. I risultati vengono ordinati in base a tempo totale della CPU.
Usare gli strumenti interattivi di Query Store per tenere traccia dell'utilizzo cronologico della CPU
Se si preferisce usare gli strumenti grafici, seguire questi passaggi per usare gli strumenti interattivi di Query Store in SSMS.
- Aprire SSMS e connettersi al database in Esplora oggetti.
- Espandere il nodo database in Esplora oggetti
- Espandere la cartella Query Store.
- Aprire il riquadro Utilizzo complessivo delle risorse.
Il tempo totale della CPU per il database nell'ultimo mese viene visualizzato in millisecondi nella parte inferiore sinistra del riquadro. Nella visualizzazione predefinita, il tempo della CPU viene aggregato per giorno.
Selezionare Configura in alto a destra nel riquadro per selezionare un periodo di tempo diverso. È anche possibile modificare l'unità di aggregazione. Ad esempio, è possibile scegliere di visualizzare i dati per un intervallo di date specifico e aggregare i dati per ora.
Usare gli strumenti interattivi di Query Store per identificare le query principali in base al tempo di CPU
Seleziona una barra nel grafico per approfondire e visualizzare le query in esecuzione in un periodo di tempo specifico. Si aprirà il riquadro Principali query che utilizzano risorse. In alternativa, è possibile aprire direttamente le Principali query che utilizzano risorse dal nodo Query Store nel database in Esplora oggetti.
Nella visualizzazione predefinita, il riquadro Principali query che utilizzano risorse mostra le query in base alla durata (ms). La durata potrebbe talvolta essere inferiore al tempo della CPU: le query che usano il parallelismo potrebbero usare molto più tempo della CPU rispetto alla durata complessiva. La durata potrebbe anche essere superiore al tempo della CPU se i tempi di attesa sono significativi. Per visualizzare le query in base al tempo della CPU, selezionare l'elenco a discesa Metrica nella parte superiore sinistra del riquadro e selezionare Tempo CPU (ms).
Ogni barra nel quadrante superiore sinistro rappresenta una query. Selezionare una barra per visualizzare i dettagli per la query. Il quadrante in alto a destra della schermata mostra quanti piani di esecuzione sono presenti in Query Store per quella query e li mappa in base a quando sono stati eseguiti e alla quantità di metrica selezionata usata. Selezionare ogni ID del piano per controllare quale piano di esecuzione delle query viene visualizzato nella metà inferiore della schermata.
Nota
Per una guida all'interpretazione delle visualizzazioni di Query Store e delle forme visualizzate nella visualizzazione Principali urulizzatori di risorse, vedere Procedure consigliate con Query Store
Ridurre l'utilizzo della CPU
Parte della risoluzione dei problemi dovrebbe includere l'apprendimento di ulteriori informazioni sulle query identificate nella sezione precedente. È possibile ridurre l'utilizzo della CPU ottimizzando gli indici, modificando i modelli di applicazione, ottimizzando le query e modificando le impostazioni relative alla CPU per il database.
- Se sono state trovate nuove query che usano una CPU in maniera significativa nel carico di lavoro, verificare che gli indici siano stati ottimizzati per tali query. È possibile ottimizzare gli indici manualmente o ridurre l'utilizzo della CPU con l'ottimizzazione automatica degli indici. Valutare se l'impostazione massimo grado di parallelismo è corretta per il carico di lavoro aumentato.
- Se è stato rilevato che il numero complessivo di esecuzioni delle query è superiore a quello usato, ottimizzare gli indici per le query con utilizzo più elevato della CPU e prendere in considerazione di effettuare l'ottimizzazione automatica degli indici. Valutare se l'impostazione massimo grado di parallelismo è corretta per il carico di lavoro aumentato.
- Se nel carico di lavoro sono state trovate query con problemi di piano sensibile ai parametri (PSP), prendere in considerazione di effettuare la correzione automatica dei piani (piano forzato). È anche possibile forzare manualmente un piano in Query Store o ottimizzare Transact-SQL per la query per ottenere un piano di query costantemente con prestazioni elevate.
- Se sono state rilevate prove che si sta verificando una grande quantità di compilazione o ricompilazione, ottimizzare le query in modo che siano correttamente parametrizzate o che non richiedano hint di ricompilazione.
- Se si rileva che le query usano un parallelismo eccessivo, ottimizzare il grado massimo di parallelismo.
Considerare le strategie seguenti in questa sezione.
Ridurre l'utilizzo della CPU con l'ottimizzazione automatica degli indici
L'ottimizzazione efficace dell'indice riduce l'utilizzo della CPU per molte query. Gli indici ottimizzati riducono le letture logiche e fisiche per una query, il che spesso comporta che la query debba svolgere meno lavoro.
Il database SQL di Azure offre la gestione automatica degli indici per i carichi di lavoro nelle repliche primarie. La gestione automatica degli indici usa l'apprendimento automatico per monitorare il carico di lavoro e ottimizzare gli indici non cluster basati su disco rowstore per il database.
Esaminare le raccomandazioni sulle prestazioni, incluse le raccomandazioni sugli indici, nel portale di Azure. È possibile applicare queste raccomandazioni manualmente o abilitare l'opzione di ottimizzazione automatica CREATE INDEX per creare e verificare le prestazioni dei nuovi indici nel database.
Ridurre l'utilizzo della CPU con correzione automatica del piano (forza il piano)
Un'altra causa comune di eventi imprevisti relativi all'elevato utilizzo della CPU è la regressione della scelta del piano di esecuzione. Il database SQL di Azure offre l'opzione di ottimizzazione automatica forza piano per identificare le regressioni nei piani di esecuzione delle query nei carichi di lavoro sulle repliche primarie. Con questa funzionalità di ottimizzazione automatica abilitata, il database SQL di Azure testerà se forzare un piano di esecuzione delle query comporti prestazioni migliorate affidabili per le query con regressione del piano di esecuzione.
Se il database è stato creato dopo marzo 2020, l'opzione di ottimizzazione automatica forza piano è stata abilitata automaticamente. Se il database è stato creato prima di tale periodo, è possibile abilitare l'opzione di ottimizzazione automatica forza piano.
Ottimizzare manualmente gli indici
Usare i metodi descritti in Identificare le cause dell'utilizzo elevato della CPU per identificare i piani di query per le query con utilizzo elevato della CPU. Questi piani di esecuzione consentiranno di identificare e aggiungere indici non cluster per velocizzare le query.
Ogni indice non cluster basato su disco nel database richiede spazio di archiviazione e deve essere gestito dal motore SQL. Modificare gli indici esistenti anziché aggiungere nuovi indici quando possibile e assicurarsi che i nuovi indici riducano correttamente l'utilizzo della CPU. Per una panoramica degli indici non cluster, vedere Linee guida per la progettazione di indici non cluster.
Per alcuni carichi di lavoro, gli indici columnstore potrebbero essere la scelta migliore per ridurre la CPU delle query di lettura frequenti. Vedere Indici columnstore - Linee guida per la progettazione per consigli di alto livello sugli scenari in cui gli indici columnstore potrebbero essere appropriati.
Ottimizzare le impostazioni dell'applicazione, delle query e del database
Esaminando le query principali, è possibile trovare antipattern dell'applicazione, come ad esempio il comportamento "chatty", i carichi di lavoro che trarrebbero vantaggio dal partizionamento orizzontale e dalla progettazione dell'accesso al database non ottimale. Per i carichi di lavoro con utilizzo elevato di lettura, considerare le repliche di sola lettura per eseguire l'offload dei carichi di lavoro di query di sola lettura e il caching a livello di applicazione come strategie a lungo termine per aumentare il numero di istanze dei dati letti di frequente.
È anche possibile scegliere di ottimizzare manualmente la CPU superiore usando query identificate nel carico di lavoro. Le opzioni di ottimizzazione manuale includono la riscrittura di istruzioni Transact-SQL, la forzatura del piano in Query Store e l'applicazione di hint per la query.
Se si identificano i casi in cui le query a volte usano un piano di esecuzione non ottimale per le prestazioni, esaminare le soluzioni nelle query che presentano problemi relativi al piano sensibile ai parametri (PSP)
Se si identificano query non parametrizzate con un numero elevato di piani, valutare la possibilità di parametrizzare queste query, assicurandosi di dichiarare tutti i tipi di dati dei parametri, inclusa lunghezza e precisione. Questa operazione può essere eseguita modificando le query, creando una guida del piano per forzare la parametrizzazione di una query specifica o abilitando la parametrizzazione forzata a livello di database.
Se si identificano le query con frequenze di compilazione elevate, identificare le cause della compilazione frequente. La causa più comune della compilazione frequente sono gli hint RECOMPILE. Quando possibile, identificare quando è stato aggiunto l'hint RECOMPILE
e quale problema intendeva risolvere. Esaminare se è possibile implementare una soluzione alternativa di ottimizzazione delle prestazioni per garantire prestazioni coerenti per l'esecuzione frequente di query senza alcun hint RECOMPILE
.
Ridurre l'utilizzo della CPU ottimizzando il massimo grado di parallelismo
L'impostazione massimo grado di parallelismo (MAXDOP) controlla il parallelismo all'interno della query nel motore di database. I valori MAXDOP più elevati comportano in genere più thread paralleli per ogni query e un'esecuzione più rapida delle query.
In alcuni casi, un numero elevato di query parallele in esecuzione contemporaneamente può rallentare un carico di lavoro e causare un utilizzo elevato della CPU. È molto probabile che si verifichi un eccessivo parallelismo nei database con un numero elevato di vCore in cui MAXDOP è impostato su un numero elevato o su zero. Quando MAXDOP è impostato su zero, il motore di database imposta il numero di pianificatori da usare da thread paralleli sul numero totale di core logici o 64, a seconda di quale sia il minore.
È possibile identificare l'impostazione massimo grado di parallelismo per il database con Transact-SQL. Connettersi al database con SSMS o Azure Data Studio ed eseguire la query seguente:
SELECT
name,
value,
value_for_secondary,
is_value_default
FROM sys.database_scoped_configurations
WHERE name=N'MAXDOP';
GO
Provare a sperimentare piccole modifiche nella configurazione MAXDOP a livello di database o modificare singole query problematiche per usare un MAXDOP non predefinito usando un hint per la query. Per maggiori informazioni, consultare gli esempi in Configurare il massimo grado di parallelismo.
Quando aggiungere risorse CPU
È possibile che le query e gli indici del carico di lavoro siano ottimizzati correttamente, o che l'ottimizzazione delle prestazioni richieda modifiche che non è possibile apportare a breve termine a causa di processi interni o altri motivi. L'aggiunta di altre risorse della CPU potrebbe essere utile per questi database. È possibile dimensionare le risorse di database con un tempo di inattività minimo.
È possibile aggiungere altre risorse CPU al database SQL di Azure configurando il numero di vCore o la configurazione hardware per i database usando il modello di acquisto vCore.
Nel modello di acquisto basato su DTU è possibile aumentare il livello di servizio e aumentare il numero di unità di transazione di database (DTU). Una DTU rappresenta una misura combinata di CPU, memoria e operazioni di lettura e scrittura. Uno dei vantaggi del modello di acquisto vCore è che consente un controllo più granulare sull'hardware in uso e sul numero di vCore. È possibile eseguire la migrazione del database SQL di Azure dal modello basato su DTU al modello basato su vCore per eseguire la transizione tra i modelli di acquisto.
Contenuto correlato
Altre informazioni su monitoraggio e sull'ottimizzazione delle prestazioni nel database SQL di Azure sono disponibili nei seguenti articoli:
- Monitoraggio del database SQL di Microsoft Azure e delle prestazioni dell'Istanza gestita di SQL di Azure tramite le viste a gestione dinamica
- Architettura e guida per la progettazione degli indici di SQL Server
- Abilitare l'ottimizzazione automatica nel portale di Azure per monitorare le query e migliorare le prestazioni del carico di lavoro
- Guida sull'architettura di elaborazione delle query
- Procedure consigliate per Query Store
- Tipi rilevabili di colli di bottiglia delle prestazioni delle query nel database SQL di Azure
- Analizzare e impedire il verificarsi di deadlock nel database SQL di Azure