Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Si applica a:
SQL Serverdatabase SQL di AzureIstanza gestita di SQL di Azure
Una riga di dati viene considerata non aggiornata se è stata eliminata da una transazione non più attiva. Una riga obsoleta è qualificata per il processo di Garbage Collection. Di seguito sono riportate le caratteristiche del processo di Garbage Collection in OLTP in memoria:
Non bloccante. Il processo di Garbage Collection viene distribuito nel tempo con un impatto minimo sul carico di lavoro.
Cooperativo. Le transazioni utente partecipano al processo di Garbage Collection con un thread principale di Garbage Collection.
Efficiente. Con le transazioni utente vengono scollegate le righe non aggiornate nel percorso di accesso (indice) utilizzato. In questo modo viene ridotto il lavoro richiesto per la rimozione finale della riga.
Reattivo. La pressione della memoria porta a un'operazione aggressiva di raccolta automatica della memoria.
Scalabile. Dopo il commit, tramite le transazioni utente viene eseguita parte del lavoro di Garbage Collection. Più sono le attività transazionali, più sono numerose le transazioni tramite cui vengono scollegate le righe non aggiornate.
Il processo di Garbage Collection è controllato dal thread principale di Garbage Collection. Il thread principale di Garbage Collection viene eseguito ogni minuto o quando il numero di transazioni completate supera una soglia interna. Il compito del garbage collector è di:
Individuare le transazioni che hanno eliminato o aggiornato un insieme di righe e sono state confermate prima della transazione attiva più vecchia.
Identificare le versioni di riga create dalle transazioni precedenti.
Raggruppare le righe precedenti in una o più unità di 16 righe ciascuna. Questa attività permette di distribuire il lavoro di Garbage Collector in unità più piccole.
Sposta queste unità di lavoro nella coda di garbage collection, una per ciascuno scheduler. Per informazioni dettagliate, vedi le viste a gestione dinamica (DMV) del Garbage Collector: sys.dm_xtp_gc_stats (Transact-SQL), sys.dm_db_xtp_gc_cycle_stats (Transact-SQL) e sys.dm_xtp_gc_queue_stats (Transact-SQL).
Dopo il commit di una transazione utente, il sistema identifica tutti gli elementi accodati associati all'utilità di pianificazione su cui è stata eseguita e quindi rilascia la memoria. Se la coda di raccolta dei rifiuti nello scheduler è vuota, cerca una coda non vuota nel nodo NUMA corrente. Se l'attività transazionale è scarsa e sono presenti richieste di memoria, tramite il thread principale di Garbage Collection è possibile accedere alle righe di Garbage Collection da qualsiasi coda. Se non vi è alcuna attività transazionale dopo aver eliminato, ad esempio, un numero elevato di righe e non vi è pressione sulla memoria, le righe eliminate non verranno eliminate dal processo di garbage collection finché l'attività transazionale non riprende o non si verifica pressione sulla memoria.