Gestione di risorse nel database SQL di Azure

Si applica a:database SQL di Azure

Questo articolo offre una panoramica della gestione delle risorse in database SQL di Azure. Fornisce informazioni su cosa accade quando vengono raggiunti i limiti delle risorse e descrive i meccanismi di governance delle risorse usati per applicare questi limiti.

Per limiti di risorse specifici per piano tariffario (noto anche come obiettivo di servizio) per database singoli, vedere Limiti delle risorse di database singoli basati su DTU o limiti delle risorse di database singolo basati su vCore. Per i limiti delle risorse del pool elastico, fare riferimento ai limiti delle risorse del pool elastico basato su DTU o ai limiti delle risorse del pool elastico basati su vCore. Per i limiti del pool SQL dedicato di Azure Synapse Analytics, vedere Limiti di capacità e memoria e limiti di concorrenza.

Nota

L'hardware gen5 nel modello di acquisto vCore è stato rinominato in serie standard (Gen5).

Suggerimento

Per i limiti del pool SQL dedicato di Azure Synapse Analytics, vedere Limiti di capacità e memoria e limiti di concorrenza.

Limiti del server logico

Risorsa Limite
Database per server logico 5000
Numero predefinito di server logici per sottoscrizione in un'area 20
Numero massimo di server logici per sottoscrizione in un'area 250
Quota DTU/eDTU 1 per server logico 54.000
Quota vCore 1 per server logico 2 540
Numero massimo di pool elastici per server logico Limitato dal numero di DTU o vCore. Se ad esempio ogni pool è da 1000 DTU, un server può supportare 54 pool.

1 I database e i pool elastici di cui è stato effettuato il provisioning con il modello di acquisto DTU vengono conteggiati anche rispetto alla quota vCore e viceversa. Ogni vCore utilizzato è considerato equivalente a 100 DTU utilizzate per la quota a livello di server.

2 Sono inclusi i vCore configurati per i database di calcolo di cui è stato effettuato il provisioning o i pool elastici e i "max vCore" configurati per i database serverless .

Importante

Poiché il numero di database si avvicina al limite per ogni server logico, può verificarsi quanto segue:

  • Aumento della latenza nell'esecuzione di query sul master database. Sono incluse le visualizzazioni delle statistiche di utilizzo delle risorse, sys.resource_statsad esempio .
  • Latenza in aumento nelle operazioni di gestione e nel portale di esecuzione del rendering dei punti di visualizzazione che coinvolgono l'enumerazione dei database nel server.

Nota

Per ottenere più quote DTU/eDTU, quota vCore o più server logici rispetto al numero predefinito, inviare una nuova richiesta di supporto nel portale di Azure. Per altre informazioni, vedere Richiedere aumenti di quota per il database SQL di Azure.

Cosa accade quando vengono raggiunti i limiti delle risorse

CPU di calcolo

Quando l'utilizzo della CPU di calcolo del database diventa elevato, la latenza delle query aumenta e le query possono persino verificarsi un timeout. In queste condizioni, le query possono essere accodate dal servizio e vengono fornite risorse per l'esecuzione man mano che le risorse diventano gratuite. Se si osserva un utilizzo elevato del calcolo, le opzioni di mitigazione includono:

Storage

Quando lo spazio dati usato raggiunge il limite massimo di dimensioni dei dati, a livello di database o a livello di pool elastico, gli inserimenti e gli aggiornamenti che aumentano le dimensioni dei dati hanno esito negativo e i client ricevono un messaggio di errore. le istruzioni edizione Standard LECT e DELETE rimangono invariate.

Nei livelli di servizio Premium e Business Critical, i client ricevono anche un messaggio di errore se il consumo combinato di archiviazione per dati, log delle transazioni e tempdb per un singolo database o un pool elastico supera le dimensioni massime di archiviazione locale. Per altre informazioni, vedere governance dello spazio Archiviazione.

Se si osserva un utilizzo elevato dello spazio di archiviazione, le opzioni di mitigazione includono:

  • Aumentare le dimensioni massime dei dati del database o del pool elastico o aumentare le prestazioni fino a un obiettivo di servizio con un limite massimo massimo di dimensioni dei dati. Vedere Ridimensionare le risorse del database singolo e Ridimensionare le risorse del pool elastico.
  • Se il database si trova in un pool elastico, in alternativa il database può essere spostato all'esterno del pool, in modo che lo spazio di archiviazione non sia condiviso con altri database.
  • Compattare un database per recuperare spazio inutilizzato. Nei pool elastici la compattazione di un database offre più spazio di archiviazione per altri database nel pool. Per altre informazioni, vedere Gestire lo spazio file nel database SQL di Azure.
  • Controllare se l'utilizzo dello spazio elevato è dovuto a un picco delle dimensioni dell'archivio versioni persistenti (PVS). PvS fa parte di ogni database e viene usato per implementare il ripristino accelerato del database. Per determinare le dimensioni correnti del pvs, vedere Risoluzione dei problemi relativi ai pvs.To determine current PVS size, see PVS troubleshooting. Un motivo comune per le dimensioni pvS di grandi dimensioni è una transazione aperta per molto tempo (ore), impedendo la pulizia delle versioni precedenti delle righe in PVS.
  • Per i database e i pool elastici nei livelli di servizio Premium e Business Critical che utilizzano grandi quantità di spazio di archiviazione, è possibile che venga visualizzato un errore di spazio insufficiente anche se lo spazio usato nel database o nel pool elastico è inferiore al limite massimo di dimensioni dei dati. Ciò può verificarsi se tempdb i file di log delle transazioni utilizzano una grande quantità di spazio di archiviazione verso il limite massimo di archiviazione locale. Eseguire il failover del database o del pool elastico per ripristinare tempdb le dimensioni iniziali minori o ridurre il log delle transazioni per ridurre il consumo di archiviazione locale.

Sessioni, ruoli di lavoro e richieste

Le sessioni, i ruoli di lavoro e le richieste sono definiti come segue:

  • Una sessione rappresenta un processo connesso al motore di database.
  • Una richiesta è la rappresentazione logica di una query o di un batch. Una richiesta viene eseguita da un client connesso a una sessione. Nel corso del tempo, più richieste possono essere inviate nella stessa sessione.
  • Un thread di lavoro, noto anche come thread di lavoro, è una rappresentazione logica di un thread del sistema operativo. Una richiesta può avere molti ruoli di lavoro quando vengono eseguiti con un piano di esecuzione di query parallela o un singolo ruolo di lavoro quando viene eseguito con un piano di esecuzione seriale (a thread singolo). I ruoli di lavoro sono inoltre necessari per supportare attività esterne alle richieste: ad esempio, un ruolo di lavoro deve elaborare una richiesta di accesso come sessione si connette.

Per altre informazioni su questi concetti, vedere guida all'architettura di thread e attività.

Il numero massimo di ruoli di lavoro è determinato dal livello di servizio e dalle dimensioni di calcolo. Le nuove richieste vengono rifiutate quando vengono raggiunti i limiti delle sessioni o dei ruoli di lavoro e i clienti ricevono un messaggio di errore. Anche se il numero di connessioni può essere controllato dall'applicazione, il numero di ruoli di lavoro simultanei è spesso più difficile da stimare e controllare. Ciò vale soprattutto durante i periodi di carico di picco quando vengono raggiunti i limiti delle risorse del database e i ruoli di lavoro si accumulano a causa di query con esecuzione più lunga, catene di blocco di grandi dimensioni o un parallelismo eccessivo delle query.

Nota

L'offerta iniziale di database SQL di Azure supporta solo query a thread singolo. In quel momento, il numero di richieste era sempre equivalente al numero di ruoli di lavoro. Il messaggio di errore 10928 in database SQL di Azure contiene la parola "Il limite di richieste per il database è N ed è stato raggiunto" per motivi di compatibilità con le versioni precedenti. Il limite raggiunto è in realtà il numero di ruoli di lavoro. Se l'impostazione max degree of parallelism (MAXDOP) è uguale a zero o è maggiore di una, il numero di ruoli di lavoro può essere molto superiore al numero di richieste e il limite può essere raggiunto molto prima di quando MAXDOP è uguale a uno. Altre informazioni sull'errore 10928 sono disponibili in Errori di governance delle risorse.

È possibile attenuare l'avvicinamento o il raggiungimento dei limiti di lavoro o sessione in base a:

Trovare limiti di lavoro e sessione per database SQL di Azure in base al livello di servizio e alle dimensioni di calcolo:

Altre informazioni sulla risoluzione di errori specifici per i limiti di sessione o di lavoro in Errori di governance delle risorse.

Connessioni esterne

Il numero di connessioni simultanee agli endpoint esterni eseguite tramite sp_invoke_external_rest_endpoint è limitato al 10% dei thread di lavoro, con un limite massimo di 150 ruoli di lavoro.

Memoria

A differenza di altre risorse (CPU, ruoli di lavoro, archiviazione), il raggiungimento del limite di memoria non influisce negativamente sulle prestazioni delle query e non causa errori e errori. Come descritto in dettaglio nella Guida all'architettura di gestione della memoria, il motore di database usa spesso tutta la memoria disponibile, in base alla progettazione. La memoria viene usata principalmente per la memorizzazione nella cache dei dati, per evitare un accesso di archiviazione più lento. Di conseguenza, un utilizzo più elevato della memoria migliora in genere le prestazioni delle query grazie a operazioni di lettura più veloci dalla memoria, anziché operazioni di lettura più lente dalla risorsa di archiviazione.

Dopo l'avvio del motore di database, quando il carico di lavoro inizia a leggere i dati dall'archiviazione, il motore di database memorizza nella cache i dati in memoria in modo aggressivo. Dopo questo periodo iniziale di ramp-up, è comune e si prevede che le avg_memory_usage_percent colonne e avg_instance_memory_percent in sys.dm_db_resource_stats siano vicine o uguali al 100%, in particolare per i database che non sono inattive e non rientrano completamente nella memoria.

Oltre alla cache dei dati, la memoria viene usata in altri componenti del motore di database. Quando è richiesta memoria e tutta la memoria disponibile è stata usata dalla cache dei dati, il motore di database riduce le dimensioni della cache dei dati per rendere disponibile la memoria ad altri componenti e aumenta dinamicamente la cache dei dati quando altri componenti rilasciano memoria.

In rari casi, un carico di lavoro abbastanza impegnativo può causare una condizione di memoria insufficiente, dando origine a errori di memoria insufficiente. Gli errori di memoria insufficiente possono verificarsi a qualsiasi livello di utilizzo della memoria compreso tra 0% e 100%. È più probabile che si verifichino errori di memoria insufficiente su dimensioni di calcolo più piccole con limiti di memoria proporzionalmente inferiori e/o con carichi di lavoro che usano più memoria per l'elaborazione di query, ad esempio in pool elastici densi.

Se si verificano errori di memoria insufficiente, le opzioni di mitigazione includono:

Soluzione Descrizione
Ridurre le dimensioni delle concessioni di memoria Per altre informazioni sulle concessioni di memoria, vedere il post di blog Informazioni sulle concessioni di memoria di SQL Server. Una soluzione comune per evitare concessioni di memoria eccessivamente grandi è mantenere aggiornate le statistiche. Ciò comporta stime più accurate del consumo di memoria da parte del motore di query, evitando concessioni di memoria di grandi dimensioni.

Per impostazione predefinita, nei database che usano il livello di compatibilità 140 e superiori, il motore di database può modificare automaticamente le dimensioni delle concessioni di memoria usando il feedback delle concessioni di memoria in modalità batch. Analogamente, nei database che usano il livello di compatibilità 150 e versioni successive, il motore di database usa anche il feedback delle concessioni di memoria in modalità riga per le query in modalità riga più comuni. Questa funzionalità predefinita consente di evitare errori di memoria insufficiente a causa di concessioni di memoria di grandi dimensioni.
Ridurre le dimensioni della cache dei piani di query Il motore di database memorizza nella cache i piani di query in memoria, per evitare di compilare un piano di query per ogni esecuzione di query. Per evitare il blob della cache del piano di query causato dalla memorizzazione nella cache dei piani usati una sola volta, assicurarsi di usare query con parametri e valutare la possibilità di abilitare OPTIMIZE_FOR_AD_HOC_WORKLOADS configurazione con ambito database.
Ridurre le dimensioni della memoria di blocco Il motore di database usa la memoria per i blocchi. Quando possibile, evitare transazioni di grandi dimensioni che possono acquisire un numero elevato di blocchi e determinare un utilizzo elevato della memoria di blocco.

Consumo di risorse da parte di carichi di lavoro utente e processi interni

database SQL di Azure richiede risorse di calcolo per implementare funzionalità di base del servizio, ad esempio disponibilità elevata e ripristino di emergenza, backup e ripristino del database, monitoraggio, Query Store, Ottimizzazione automatica e così via. Il sistema riserva una parte limitata delle risorse complessive per questi processi interni usando meccanismi di governance delle risorse, rendendo disponibile il resto delle risorse per i carichi di lavoro degli utenti. In alcuni casi in cui i processi interni non usano risorse di calcolo, il sistema li rende disponibili per i carichi di lavoro degli utenti.

Il consumo totale di CPU e memoria da parte dei carichi di lavoro degli utenti e dei processi interni viene segnalato nelle visualizzazioni sys.dm_db_resource_stats e sys.resource_stats, in avg_instance_cpu_percent e avg_instance_memory_percent . Questi dati vengono anche segnalati tramite le sql_instance_cpu_percent metriche di Monitoraggio sql_instance_memory_percent di Azure e per database singoli e pool elastici a livello di pool.

Nota

Le sql_instance_cpu_percent metriche di Monitoraggio di Azure e sql_instance_memory_percent sono disponibili a partire da luglio 2023. Sono completamente equivalenti alle metriche e sqlserver_process_memory_percent disponibili sqlserver_process_core_percent in precedenza, rispettivamente. Le ultime due metriche rimangono disponibili, ma verranno rimosse in futuro. Per evitare un'interruzione del monitoraggio del database, non usare le metriche meno recenti.

Queste metriche non sono disponibili per i database che usano obiettivi di servizio Basic, S1 e S2. Gli stessi dati sono disponibili nelle viste a gestione dinamica a cui si fa riferimento di seguito.

Il consumo di CPU e memoria da parte dei carichi di lavoro utente in ogni database viene segnalato nelle visualizzazioni sys.dm_db_resource_stats e sys.resource_stats, in avg_cpu_percent e avg_memory_usage_percent. Per i pool elastici, l'utilizzo delle risorse a livello di pool viene segnalato nella visualizzazione sys.elastic_pool_resource_stats (per gli scenari di creazione di report cronologici) e in sys.dm_elastic_pool_resource_stats per il monitoraggio in tempo reale. L'utilizzo della CPU del carico di lavoro utente viene segnalato anche tramite la cpu_percent metrica monitoraggio di Azure per database singoli e pool elastici a livello di pool.

Nelle visualizzazioni sys.dm_resource_governor_resource_pools_history_ex e sys.dm_resource_governor_workload_groups_history_ex viene segnalata una suddivisione più dettagliata del consumo di risorse recenti da parte dei carichi di lavoro degli utenti e dei processi interni. Per informazioni dettagliate sui pool di risorse e sui gruppi di carico di lavoro a cui si fa riferimento in queste viste, vedere Governance delle risorse. Queste visualizzazioni segnalano l'utilizzo delle risorse da parte dei carichi di lavoro utente e processi interni specifici nei pool di risorse e nei gruppi di carico di lavoro associati.

Suggerimento

Quando si esegue il monitoraggio o la risoluzione dei problemi relativi alle prestazioni del carico di lavoro, è importante considerare sia l'utilizzo della CPU dell'utente (avg_cpu_percent, cpu_percent) sia il consumo totale della CPU da parte dei carichi di lavoro degli utenti e dei processi interni (avg_instance_cpu_percent,sql_instance_cpu_percent). Le prestazioni possono essere notevolmente influenzate se una di queste metriche si trova nell'intervallo del 70-100%.

L'utilizzo della CPU utente viene definito come percentuale rispetto al limite di CPU del carico di lavoro dell'utente in ogni obiettivo di servizio. Analogamente, il consumo totale della CPU viene definito come percentuale verso il limite di CPU per tutti i carichi di lavoro. Poiché i due limiti sono diversi, l'utente e il consumo totale della CPU vengono misurati su scale diverse e non sono direttamente confrontabili tra loro.

Se l'utilizzo della CPU dell'utente raggiunge il 100%, significa che il carico di lavoro dell'utente usa completamente la capacità della CPU disponibile nell'obiettivo di servizio selezionato, anche se il consumo totale della CPU rimane inferiore al 100%.

Quando il consumo totale della CPU raggiunge l'intervallo del 70-100%, è possibile visualizzare l'aumento della velocità effettiva del carico di lavoro utente e la latenza delle query, anche se l'utilizzo della CPU dell'utente rimane significativamente inferiore al 100%. Ciò è più probabile quando si usano obiettivi di servizio più piccoli con un'allocazione moderata di risorse di calcolo, ma carichi di lavoro utente relativamente intensi, ad esempio in pool elastici densi. Ciò può verificarsi anche con obiettivi di servizio più piccoli quando i processi interni richiedono temporaneamente risorse aggiuntive, ad esempio quando si crea una nuova replica del database o si esegue il backup del database.

Analogamente, quando l'utilizzo della CPU dell'utente raggiunge l'intervallo del 70-100%, la velocità effettiva del carico di lavoro utente si appiattirà e la latenza delle query aumenterà, anche se il consumo totale della CPU potrebbe essere ben inferiore al limite.

Quando l'utilizzo della CPU dell'utente o il consumo totale della CPU è elevato, le opzioni di mitigazione sono le stesse indicate nella sezione Cpu di calcolo e includono l'aumento dell'obiettivo di servizio e/o l'ottimizzazione del carico di lavoro dell'utente.

Nota

Anche in un database completamente inattiva o in un pool elastico, il consumo totale della CPU non è mai a zero a causa delle attività del motore di database in background. Può variare in un'ampia gamma a seconda delle attività in background, delle dimensioni di calcolo e del carico di lavoro utente precedente.

Governance delle risorse

Per applicare i limiti delle risorse, database SQL di Azure usa un'implementazione di governance delle risorse basata su SQL Server Resource Governor, modificata ed estesa per l'esecuzione nel cloud. In database SQL, più pool di risorse e gruppi di carico di lavoro, con limiti di risorse impostati sia a livello di pool che di gruppo, forniscono un database come servizio bilanciato. I carichi di lavoro utente e i carichi di lavoro interni vengono classificati in pool di risorse e gruppi di carico di lavoro separati. Il carico di lavoro utente nelle repliche secondarie primarie e leggibili, incluse le repliche geografiche, viene classificato nel SloSharedPool1 pool di risorse e UserPrimaryGroup.DBId[N] nei gruppi di carico di lavoro, dove [N] è l'acronimo del valore ID del database. Sono inoltre disponibili più pool di risorse e gruppi di carico di lavoro per vari carichi di lavoro interni.

Oltre a usare Resource Governor per gestire le risorse all'interno del motore di database, database SQL di Azure usa anche oggetti processo di Windows per la governance delle risorse a livello di processo e Gestione risorse file server di Windows per la gestione delle quote di archiviazione.

database SQL di Azure governance delle risorse è gerarchica. Dall'alto verso il basso, i limiti vengono applicati a livello di sistema operativo e a livello di volume di archiviazione usando i meccanismi di governance delle risorse del sistema operativo e Resource Governor, quindi a livello di pool di risorse usando Resource Governor e quindi a livello di gruppo del carico di lavoro usando Resource Governor. I limiti di governance delle risorse applicati per il database corrente o il pool elastico vengono segnalati nella vista sys.dm_user_db_resource_governance .

Governance di I/O dei dati

La governance di I/O dei dati è un processo in database SQL di Azure usato per limitare le operazioni di I/O fisiche in lettura e scrittura rispetto ai file di dati di un database. I limiti delle operazioni di I/O al secondo vengono impostati per ogni livello di servizio per ridurre al minimo l'effetto "vicino rumoroso", per garantire l'equità di allocazione delle risorse in un servizio multi-tenant e per rimanere entro le funzionalità dell'hardware e dell'archiviazione sottostanti.

Per i database singoli, i limiti dei gruppi di carico di lavoro vengono applicati a tutte le operazioni di I/O di archiviazione sul database. Per i pool elastici, i limiti dei gruppi di carico di lavoro si applicano a ogni database nel pool. Inoltre, il limite del pool di risorse si applica anche all'I/O cumulativo del pool elastico. In tempdble operazioni di I/O sono soggette ai limiti dei gruppi di carico di lavoro, ad eccezione del livello di servizio Basic, Standard e Utilizzo generico, in cui si applicano limiti di I/O più elevati tempdb . In generale, i limiti del pool di risorse potrebbero non essere raggiungibili dal carico di lavoro rispetto a un database (singolo o in pool), perché i limiti del gruppo di carico di lavoro sono inferiori ai limiti del pool di risorse e limitano le operazioni di I/O al secondo/o la velocità effettiva prima. Tuttavia, i limiti del pool possono essere raggiunti dal carico di lavoro combinato rispetto a più database nello stesso pool.

Ad esempio, se una query genera 1000 operazioni di I/O al secondo senza governance delle risorse di I/O, ma il limite massimo di operazioni di I/O al secondo del gruppo di carico di lavoro è impostato su 900 operazioni di I/O al secondo, la query non può generare più di 900 operazioni di I/O al secondo. Tuttavia, se il limite massimo di operazioni di I/O al secondo del pool di risorse è impostato su 1500 operazioni di I/O e il totale di I/O di tutti i gruppi di carico di lavoro associati al pool di risorse supera 1500 operazioni di I/O al secondo, l'I/O della stessa query può essere ridotta al di sotto del limite di 900 operazioni di I/O al secondo del gruppo di lavoro.

I valori massimi di operazioni di I/O al secondo e velocità effettiva restituiti dalla visualizzazione sys.dm_user_db_resource_governance fungono da limiti/limiti, non come garanzie. Inoltre, la governance delle risorse non garantisce una latenza di archiviazione specifica. La latenza, le operazioni di I/O al secondo e la velocità effettiva ottimali per un determinato carico di lavoro utente dipendono non solo dai limiti di governance delle risorse di I/O, ma anche dalla combinazione di dimensioni di I/O usate e dalle funzionalità dell'archiviazione sottostante. database SQL usa operazioni di I/O che variano in dimensioni comprese tra 512 byte e 4 MB. Ai fini dell'applicazione dei limiti delle operazioni di I/O al secondo, ogni I/O viene tenuto conto indipendentemente dalle dimensioni, ad eccezione dei database con file di dati in Archiviazione di Azure. In tal caso, le operazioni di I/O superiori a 256 KB vengono considerate come più operazioni di I/O da 256 KB per allinearsi alla contabilità di I/O Archiviazione di Azure.

Per i database Basic, Standard e Per utilizzo generico, che usano file di dati in Archiviazione di Azure, il primary_group_max_io valore potrebbe non essere raggiungibile se un database non dispone di file di dati sufficienti per fornire in modo cumulativo questo numero di operazioni di I/O al secondo o se i dati non vengono distribuiti uniformemente tra i file o se il livello di prestazioni dei BLOB sottostanti limita le operazioni di I/O al secondo/o la velocità effettiva al di sotto dei limiti di governance delle risorse. Analogamente, con piccole operazioni di I/O del log generate da frequenti commit di transazioni, il primary_max_log_rate valore potrebbe non essere raggiungibile da un carico di lavoro a causa del limite di operazioni di I/O al secondo sul BLOB di Archiviazione di Azure sottostante. Per i database che usano Azure Archiviazione Premium, database SQL di Azure usa BLOB di archiviazione sufficientemente grandi per ottenere le operazioni di I/O al secondo/o la velocità effettiva necessarie, indipendentemente dalle dimensioni del database. Per i database di dimensioni maggiori, vengono creati più file di dati per aumentare la capacità totale di IOPS/velocità effettiva.

I valori di utilizzo delle risorse, ad esempio avg_data_io_percent e avg_log_write_percent, segnalati nelle viste sys.dm_db_resource_stats, sys.resource_stats, sys.dm_elastic_pool_resource_stats e sys.elastic_pool_resource_stats , vengono calcolati come percentuali dei limiti massimi di governance delle risorse. Pertanto, quando i fattori diversi dal limite di governance delle risorse limitano le operazioni di I/O al secondo/o la velocità effettiva, è possibile visualizzare l'appiattimento delle operazioni di I/O al secondo e la velocità effettiva aumentano man mano che il carico di lavoro aumenta, anche se l'utilizzo delle risorse segnalato rimane inferiore al 100%.

Per monitorare le operazioni di I/O al secondo, velocità effettiva e latenza di lettura e scrittura per ogni file di database, usare la funzione sys.dm_io_virtual_file_stats(). Questa funzione espone tutte le operazioni di I/O sul database, incluse le operazioni di I/O in background non accountate verso avg_data_io_percent, ma usa operazioni di I/O al secondo e velocità effettiva dell'archiviazione sottostante e può influire sulla latenza di archiviazione osservata. La funzione segnala una latenza aggiuntiva che può essere introdotta dalla governance delle risorse di I/O per letture e scritture, rispettivamente nelle io_stall_queued_read_ms colonne e io_stall_queued_write_ms .

Governance della frequenza dei log delle transazioni

La governance della frequenza dei log delle transazioni è un processo in database SQL di Azure usato per limitare tassi di inserimento elevati per carichi di lavoro, ad esempio inserimento bulk, edizione Standard LECT INTO e compilazioni di indici. Questi limiti vengono rilevati e applicati a livello di sottosecondo alla velocità di generazione dei record del log, limitando la velocità effettiva indipendentemente dal numero di operazioni di I/O che possono essere rilasciate nei file di dati. Le frequenze di generazione del log delle transazioni attualmente aumentano in modo lineare fino a un punto dipendente dall'hardware e dipendente dal livello di servizio.

Le tariffe dei log vengono impostate in modo che possano essere ottenute e sostenute in vari scenari, mentre il sistema complessivo può mantenere le funzionalità con un impatto ridotto al minimo sul carico dell'utente. La governance della frequenza dei log garantisce che i backup del log delle transazioni rimangano entro i contratti di servizio di recuperabilità pubblicati. Questa governance impedisce inoltre un backlog eccessivo nelle repliche secondarie che altrimenti potrebbero causare tempi di inattività più lunghi del previsto durante i failover.

Le operazioni di I/O fisiche effettive per i file di log delle transazioni non sono regolate o limitate. Quando vengono generati record di log, ogni operazione viene valutata e valutata per determinare se deve essere ritardata per mantenere una velocità massima di log desiderata (MB/sec al secondo). I ritardi non vengono aggiunti quando i record di log vengono scaricati nell'archiviazione, ma la governance della frequenza dei log viene applicata durante la generazione della frequenza dei log stessa.

Le velocità di generazione dei log effettive imposte in fase di esecuzione possono anche essere influenzate dai meccanismi di feedback, riducendo temporaneamente i tassi di log consentiti in modo che il sistema possa stabilizzarsi. La gestione dello spazio dei file di log, evitando l'esaurimento delle condizioni di spazio dei log e i meccanismi di replica dei dati possono ridurre temporaneamente i limiti complessivi del sistema.

La modellazione del traffico di Log Rate Governor viene rilevata tramite i tipi di attesa seguenti (esposti nelle visualizzazioni sys.dm_exec_requests e sys.dm_os_wait_stats ):

wait_type Note
LOG_RATE_GOVERNOR Limitazione del database
POOL_LOG_RATE_GOVERNOR Limitazione del pool
INSTANCE_LOG_RATE_GOVERNOR Limitazione a livello di istanza
HADR_THROTTLE_LOG_RATE_edizione StandardND_RECV_QUEUE_SIZE Controllo dei commenti e suggerimenti, replica fisica del gruppo di disponibilità in Premium/Business Critical non mantenendo
HADR_THROTTLE_LOG_RATE_LOG_SIZE Controllo dei commenti e suggerimenti, limitazione delle frequenze per evitare una condizione di spazio del log insufficiente
HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO Controllo del feedback della replica geografica, limitazione della frequenza dei log per evitare una latenza elevata dei dati e un'indisponibilità di repliche geografiche secondarie

Quando si verifica un limite di frequenza dei log che ostacola la scalabilità desiderata, prendere in considerazione le opzioni seguenti:

  • Aumentare fino a un livello di servizio superiore per ottenere la frequenza massima di log di un livello di servizio o passare a un livello di servizio diverso. Il livello di servizio Hyperscale offre una frequenza di log di 100 MB/s per database e 125 MB/s per ogni pool elastico, indipendentemente dal livello di servizio scelto.

    Nota

    I pool elastici per Hyperscale sono attualmente in anteprima.

  • Se i dati in fase di caricamento sono temporanei, ad esempio dati di staging in un processo ETL, è possibile caricarli in tempdb, per cui è prevista la registrazione minima.

  • Per gli scenari analitici, eseguire il caricamento in una tabella columnstore in cluster o una tabella con indici che usano la compressione dei dati. Questo approccio consente di ridurre la frequenza di registrazione necessaria. Questa tecnica aumenta l'utilizzo della CPU ed è applicabile solo a set di dati che traggono vantaggio da indici columnstore in cluster o dalla compressione dei dati.

governance dello spazio Archiviazione

Nei livelli di servizio Premium e Business Critical, i dati dei clienti, inclusi i file di dati, i file di log delle transazioni e tempdb i file, vengono archiviati nell'archiviazione SSD locale del computer che ospita il database o il pool elastico. L'archiviazione SSD locale offre operazioni di I/O al secondo e velocità effettiva elevate e bassa latenza di I/O. Oltre ai dati dei clienti, l'archiviazione locale viene usata per il sistema operativo, il software di gestione, i dati di monitoraggio e i log e altri file necessari per il funzionamento del sistema.

La dimensione dell'archiviazione locale è limitata e dipende dalle funzionalità hardware, che determinano il limite massimo di archiviazione locale o l'archiviazione locale messa da parte per i dati dei clienti. Questo limite è impostato per ottimizzare l'archiviazione dei dati dei clienti, garantendo al tempo stesso operazioni di sistema sicure e affidabili. Per trovare il valore massimo di archiviazione locale per ogni obiettivo di servizio, vedere la documentazione relativa ai limiti delle risorse per database singoli e pool elastici.

È anche possibile trovare questo valore e la quantità di archiviazione locale attualmente usata da un determinato database o pool elastico, usando la query seguente:

SELECT server_name, database_name, slo_name, user_data_directory_space_quota_mb, user_data_directory_space_usage_mb
FROM sys.dm_user_db_resource_governance
WHERE database_id = DB_ID();
Colonna Descrizione
server_name Nome server logico
database_name Nome database
slo_name Nome dell'obiettivo del servizio, inclusa la generazione dell'hardware
user_data_directory_space_quota_mb Spazio di archiviazione locale massimo, in MB
user_data_directory_space_usage_mb Utilizzo corrente dell'archiviazione locale per file di dati, file di log delle transazioni e tempdb file, in MB. Aggiornato ogni cinque minuti.

Questa query deve essere eseguita nel database utente, non nel master database. Per i pool elastici, la query può essere eseguita in qualsiasi database nel pool. I valori segnalati si applicano all'intero pool.

Importante

Nei livelli di servizio Premium e Business Critical, se il carico di lavoro tenta di aumentare il consumo combinato di archiviazione locale per file di dati, file di log delle transazioni e tempdb file oltre il limite massimo di archiviazione locale, si verificherà un errore di spazio insufficiente. Ciò si verifica anche se lo spazio usato in un file di database non ha raggiunto le dimensioni massime del file.

L'archiviazione SSD locale viene usata anche dai database nei livelli di servizio diversi da Premium e Business Critical per il database e la tempdb cache RBPEX hyperscale. Man mano che i database vengono creati, eliminati e aumentati o diminuiscono le dimensioni, il consumo totale di risorse di archiviazione locali in un computer varia nel tempo. Se il sistema rileva che l'archiviazione locale disponibile in un computer è bassa e un database o un pool elastico rischia di esaurire lo spazio, il database o il pool elastico viene spostato in un computer diverso con spazio di archiviazione locale sufficiente disponibile.

Questo spostamento avviene in modo online, in modo analogo a un'operazione di ridimensionamento del database e ha un impatto simile, incluso un failover breve (secondi) alla fine dell'operazione. Questo failover termina le connessioni aperte ed esegue il rollback delle transazioni, che potenzialmente influisce sulle applicazioni che usano il database in quel momento.

Poiché tutti i dati vengono copiati in volumi di archiviazione locali in computer diversi, lo spostamento di database di dimensioni maggiori nei livelli di servizio Premium e Business Critical può richiedere una notevole quantità di tempo. Durante tale periodo, se il consumo di spazio locale da un database o da un pool elastico o dal tempdb database aumenta rapidamente, il rischio di esaurimento dello spazio aumenta. Il sistema avvia lo spostamento del database in modo bilanciato per ridurre al minimo gli errori di spazio insufficiente evitando failover non necessari.

tempdb Dimensioni

I limiti delle dimensioni per tempdb in database SQL di Azure dipendono dal modello di acquisto e distribuzione.

Per altre informazioni, vedere i tempdb limiti delle dimensioni per:

Hardware precedentemente disponibile

Questa sezione include informazioni dettagliate sull'hardware disponibile in precedenza.

  • L'hardware Gen4 è stato ritirato e non è disponibile per il provisioning, l'upscaling o il ridimensionamento. Eseguire la migrazione del database a una generazione hardware supportata per una gamma più ampia di scalabilità di vCore e archiviazione, rete accelerata, prestazioni di I/O ottimali e latenza minima. Per altre informazioni, vedere Supporto terminato per l'hardware di generazione 4 in database SQL di Azure.

È possibile usare Azure Resource Graph Explorer per identificare tutte le risorse database SQL di Azure che attualmente usano hardware Gen4 oppure controllare l'hardware usato dalle risorse per un server logico specifico nel portale di Azure.

Per visualizzare i risultati in Azure Resource Graph Explorer, è necessario disporre almeno read delle autorizzazioni per l'oggetto o il gruppo di oggetti di Azure.

Per usare Resource Graph Explorer per identificare le risorse SQL di Azure che usano ancora hardware Gen4, seguire questa procedura:

  1. Vai al portale di Azure.

  2. Resource graph Cercare nella casella di ricerca e scegliere il servizio Resource Graph Explorer nei risultati della ricerca.

  3. Nella finestra della query digitare la query seguente e quindi selezionare Esegui query:

    resources
    | where type contains ('microsoft.sql/servers')
    | where sku['family'] == "Gen4"
    
  4. Il riquadro Risultati visualizza tutte le risorse attualmente distribuite in Azure che usano l'hardware Gen4.

    Screenshot of Azure Resources Graph Explorer in the Azure portal showing query results to identify gen4 hardware.

Per controllare l'hardware usato dalle risorse per un server logico specifico in Azure, seguire questa procedura:

  1. Vai al portale di Azure.
  2. SQL servers Cercare nella casella di ricerca e scegliere SQL Server dai risultati della ricerca per aprire la pagina SQL Server e visualizzare tutti i server per le sottoscrizioni scelte.
  3. Selezionare il server di interesse per aprire la pagina Panoramica per il server.
  4. Scorrere verso il basso fino alle risorse disponibili e controllare la colonna Piano tariffario per le risorse che usano hardware gen4.

Screenshot of the Overview page for a logical server in Azure, the overview page selected, and gen4 highlighted.

Per eseguire la migrazione delle risorse all'hardware della serie standard, vedere Modificare l'hardware.

Passaggi successivi