Requisiti: Ci sono molte ragioni per cui il database SQL Server causa blocchi; in produzione, tutti possono incontrare problemi di blocchi e la causa specifica potrebbe non essere individuata solo in base alle informazioni anomale dei blocchi applicativi, quindi è necessario utilizzare eventi di estensione in SQL Server per monitorare i problemi di blocchi e registrare i dettagli specifici di quando si verificano questi blocchi.
Panoramica estesa dell'evento
Extended Events è una funzione leggera di monitoraggio delle prestazioni che permette agli utenti di raccogliere i dati necessari per monitorare e risolvere problemi. Questa funzione consente di visualizzare dettagli sulle operazioni interne del motore dati per scopi legati al monitoraggio delle prestazioni e alla risoluzione dei problemi.
Con l'architettura Extended Events (XEvents), gli utenti possono utilizzare quanti o quanti pochi dati siano necessari per monitorare, identificare o risolvere i problemi delle prestazioni di SQL Server, Azure SQL Database e Azure SQL Managed Instance. Gli eventi estesi sono altamente configurabili, leggeri e scalabili in modo efficace.
Riferimento:
Il login del link ipertestuale è visibile.
Il login del link ipertestuale è visibile.
Cause degli stalli
I blocchi sono causati da blocchi di concorrenza in un database, solitamente in transazioni a più fasi. Ogni sessione utente può avere una o più attività in esecuzione per suo conto, in cui ogni attività può recuperare o aspettare di recuperare varie risorse. I seguenti tipi di risorse possono causare blocchi e infine causare uno stallo.
- Blocchi: Le serrature in attesa di recuperare risorse come oggetti, pagine, righe, metadati e applicazioni possono causare blocchi. Ad esempio, la transazione T1 ha un lock condiviso (lock S) sulla riga r1 e attende di ottenere un lock esclusivo (lock X) per la riga r2. La transazione T2 ha un lock condiviso (lock S) sulla riga r2 e attende di ottenere un lock esclusivo (lock X) per la riga r1. Questo provoca un ciclo di blocco in cui sia T1 che T2 aspettano che l'altro rilasci la risorsa bloccata.
- Worker thread: Le coda di compiti per i worker thread disponibili possono causare blocchi. Se un compito in coda ha una risorsa che blocca tutti i worker thread, si comporterà un deadlock. Ad esempio, dopo che la sessione S1 avvia una transazione e acquisisce un blocco condiviso (S-lock) per la linea r1, va in sospensione. Una sessione attiva in esecuzione su tutti i thread worker disponibili sta cercando di ottenere un lock esclusivo (X-lock) per la linea r1. Poiché la sessione S1 non può ottenere un thread di lavoro, non può effettuare il commit della transazione e liberare il lock sulla linea r1. Questo porterà a uno stallo.
- Memoria: Può verificarsi un deadlock quando una richiesta concorrente attende di acquisire memoria e la memoria attualmente disponibile non è sufficiente per le sue esigenze. Ad esempio, due query concorrenti (Q1 e Q2) vengono eseguite come funzioni definite dall'utente, acquisendo rispettivamente 10 MB e 20 MB di memoria. Se ogni query richiede 30 MB e la memoria totale disponibile è di 20 MB, Q1 e Q2 devono aspettare l'uno dell'altro per liberare memoria, il che comporterà un deadlock.
- Risorse di query e esecuzione parallele: Coordinatori di elaborazione, generatori o thread consumer tipicamente associati a porte commutate possono bloccarsi a vicenda quando contengono almeno un processo che non fa parte di una query parallela, causando blocchi di interruzione. Inoltre, quando una query parallela inizia l'esecuzione, SQL Server determina il grado di parallelismo o il numero di worker thread in base al carico di lavoro corrente. Un deadlock può verificarsi se c'è un cambiamento inaspettato nel carico di lavoro del sistema, ad esempio quando una nuova query inizia a essere eseguita nel server o quando il sistema esaurisce i thread di lavoro.
- Multiple Activity Outcome Set (MARS): Queste risorse vengono utilizzate per controllare l'esecuzione incrociata di richieste di attività multiple sotto MARS.
Riferimento:
Il login del link ipertestuale è visibile.
Logging degli eventi estesi di deadlock
Crea un evento di estensione per registrare le informazioni di deadlock con il seguente comando:
Avvia una sessione di evento di blocco
Interrompi una sessione evento
Elimina una sessione evento
Consulta i dati della sessione degli eventi
Blocchi di prova
Creare una nuova tabella Tab1 per i test, creare due nuove finestre di esecuzione ed eseguire rispettivamente i seguenti comandi:
Si verifica un blocco come segue:
Una transazione (ID processo 68) con un altro processo è bloccata su una risorsa bloccata ed è stata selezionata come vittima di deadlock. Per favore, riesegui la transazione.
La transazione (ID processo 68) era bloccata sulle risorse del blocco con un altro processo ed è stata scelta come vittima del deadlock. Riesegui la transazione. 
Visualizza i dati della sessione dell'evento come mostrato nella figura seguente:
I dati XML dettagliati sono i seguenti:
(Fine)
|
Pubblicato su 02/03/2024 19:13:04
|
|
|
|
Padrone di casa|
Pubblicato su 02/03/2024 19:14:35
|
