Pianificazione delle attività o dei batch di SQL Server

Informazioni sulla pianificazione

Ogni istanza di SQL Server dispone di un livello interno che implementa un ambiente simile a un sistema operativo. Questo livello interno viene utilizzato per la pianificazione e la sincronizzazione delle attività simultanee, senza necessità di chiamare il kernel di Windows. Questo livello interno è inoltre in grado di pianificare i fiber o thread di Windows in modo efficace. Ogni istanza di SQL Server mantiene un pool di thread o fiber di Windows per l'elaborazione delle query utente. La dimensione massima del pool viene controllata tramite l'opzione di configurazione del server max worker threads.

Per acquisire familiarità con le modalità di elaborazione di una richiesta o di un'attività, è utile comprendere i termini di base seguenti:

• connessione
  Una connessione viene stabilita quando l'utente accede correttamente al sistema. L'utente è quindi in grado di inviare una o più istruzioni Transact-SQL per l'esecuzione. Una connessione viene chiusa quando l'utente esegue la disconnessione in modo esplicito oppure quando la connessione viene terminata.

• batch
  Un batch SQL è un set di una o più istruzioni Transact-SQL inviate da un client a un'istanza di SQL Server per l'esecuzione e rappresenta un'unità di lavoro inviata al Motore di database dagli utenti.

• attività
  Un'attività rappresenta un'unità di lavoro pianificata da SQL Server. Un batch può essere mappato a una o più attività. Una query parallela, ad esempio, verrà eseguita da più attività.

• thread di Windows
  Ogni thread di Windows rappresenta un meccanismo di esecuzione indipendente.

• fiber
  Un fiber è un thread di tipo lightweight che richiede risorse minori rispetto a un thread di Windows ed è in grado di passare a un altro contesto se in modalità utente. Un thread di Windows può essere mappato a molti fiber.

• thread di lavoro
  Il thread di lavoro rappresenta un thread logico in SQL Server mappato internamente (1:1) a un thread di Windows oppure, se il lightweight pooling è attivo, a un fiber. Il mapping viene mantenuto finché il thread di lavoro viene deallocato a motivo delle richieste di memoria oppure qualora sia rimasto inattivo per un periodo prolungato. L'associazione di un'attività a un thread di lavoro viene mantenuta per tutta la durata dell'attività.

Gestione delle connessioni utente e delle risorse dei thread di lavoro

I thread e i fiber non impegnano eccessivamente le risorse. Tuttavia, in sistemi con centinaia o migliaia di connessioni utente, la disponibilità di un thread di lavoro per ogni connessione può richiedere una quantità di risorse tale da ridurre l'efficienza di SQL Server. Inoltre, l'allocazione di un thread di lavoro dedicato per ogni connessione utente non è necessaria poiché gran parte del tempo di connessione trascorre in attesa che il client riceva i batch. L'istanza di SQL Server utilizza invece un pool di thread di lavoro. Il pool di thread di lavoro deve avere dimensioni sufficienti per servire il numero di connessioni utente che eseguono batch contemporaneamente in tale istanza. Lasciando l'opzione max worker threads impostata sul relativo valore predefinito (0) l'istanza di SQL Server è in grado di eseguire in modo efficace il mapping delle connessioni utente su vari thread di lavoro. Questo assicura che i thread non utilizzino troppe risorse.

Configurazione di SQL Server per i fiber

L'opzione di configurazione del server lightweight pooling determina se un'istanza di SQL Server utilizza i thread di Windows o i fiber. Il valore predefinito per questa opzione è 0. Questo indica che l'istanza di SQL Server pianifica un thread di Windows per ogni thread di lavoro, fino al valore impostato nell'opzione max worker threads. Se l'opzione lightweight pooling è impostata su 1, SQL Server utilizza i fiber anziché i thread. Si tratta dell'esecuzione in modalità fiber. In modalità fiber, un'istanza di SQL Server assegna un thread di Windows per ogni utilità di pianificazione di SQL e quindi assegna un fiber per ogni thread di lavoro, fino al valore impostato nell'opzione max worker threads. Per la pianificazione e la sincronizzazione delle attività, un'istanza di SQL Server utilizza gli stessi algoritmi sia per l'esecuzione con i thread che in modalità fiber. SQL Server Express non supporta i fiber. Per ulteriori informazioni, vedere Utilizzo dell'opzione lightweight pooling. Si consiglia di non utilizzare la modalità fiber per la pianificazione dell'operazione di routine. Questo perché può ridurre le prestazioni bloccando i vantaggi normali dello scambio del contesto e perché alcuni componenti di SQL Server non possono funzionare correttamente in modalità fiber. Per ulteriori informazioni, vedere lightweight pooling.

Funzionamento della pianificazione delle attività o dei batch

Quando un'applicazione si connette a Motore di database, le viene assegnato un ID sessione (SPID). Tutte le informazioni che devono essere mantenute per la durata della connessione vengono gestite in strutture di dati interne associate allo SPID. Quando un'istanza di SQL Server riceve i batch dai client, suddivide il batch in una o più attività e quindi associa ogni attività a un thread di lavoro disponibile da un pool di thread di lavoro. Un thread di lavoro è associato all'attività per la durata dell'attività. Un thread di lavoro esegue la richiesta sull'utilità di pianificazione SQL associata. Se non sono disponibili thread di lavoro e non è stato raggiunto il valore di max worker threads, l'istanza di SQL Server assegna un nuovo thread di lavoro al nuovo batch. Se non sono disponibili thread o fiber ed è già stato raggiunto il valore di max worker threads, la nuova attività viene bloccata dall'istanza di SQL Server fino a quando non viene reso disponibile un thread di lavoro.

Dopo che il thread di lavoro è stato associato a un'attività, rimane tale finché non viene completato, ad esempio finché l'ultimo set di risultati generato dal batch è stato restituito al client. In quel momento, il thread di lavoro viene reso disponibile e può essere abbinato alle attività associate al batch successivo.

È necessario che Motore di database esegua attività in modo attivo per una connessione solo dal momento della ricezione di un batch fino alla restituzione al client dei risultati. Durante tale intervallo, in alcuni momenti è possibile che il batch non richieda un'elaborazione attiva. Ad esempio, in alcuni momenti è possibile che Motore di database debba attendere che un'operazione di lettura recuperi i dati necessari per la query corrente, oppure che un altro batch rilasci un blocco. L'associazione tra attività e thread di lavoro viene mantenuta anche quando l'attività è bloccata su una risorsa.

Ogni volta che Motore di database inizia l'elaborazione di un'attività associata a un batch, pianifica il thread di lavoro associato all'attività perché esegua il lavoro. Dopo che il thread di lavoro ha completato il lavoro per l'attività, l'istanza di SQL Server invia il thread di lavoro all'attività successiva già pronta. Uno SPID rimane costante per una connessione per tutta la sua durata. È possibile che le singole attività di batch delle connessioni con esecuzione prolungata siano eseguite da molti thread di lavoro diversi. Ad esempio le attività dal primo batch possono essere eseguite da worker1, mentre le attività del secondo batch da worker2. Alcune istruzioni possono essere elaborate in parallelo. In questo caso, un batch può includere più attività eseguite da più thread di lavoro contemporaneamente.

Vedere anche

Concetti

Altre risorse