Fattori che possono ritardare il troncamento del log.
Il troncamento del log libera spazio nel file di log per consentirne il riutilizzo da parte del log delle transazioni. Poiché non è possibile troncare o rimuovere una parte attiva del log tramite compattazione, il troncamento può essere posticipato quando i record dei log restano attivi per molto tempo.
[!NOTA]
Per informazioni sul funzionamento del troncamento del log, vedere Troncamento del log delle transazioni.
I record di log possono restare attivi in una varietà di condizioni descritte in questo argomento. Per individuare l'eventuale condizione che impedisce il troncamento del log, utilizzare le colonne log_reuse_wait e log_reuse_wait_desc della vista del catalogo sys.databases.
[!NOTA]
Alcuni di questi fattori, come una transazione con esecuzione estremamente prolungata o una sessione di mirroring del database sospesa, possono causare il riempimento del log delle transazioni. Per informazioni sulla gestione di un log delle transazioni pieno, vedere Risoluzione dei problemi relativi a un log delle transazioni pieno (Errore 9002).
Nella seguente tabella vengono descritti brevemente i valori di log_reuse_wait e log_reuse_wait_desc della vista del catalogo sys.database.
log_reuse_wait value |
valore log_reuse_wait_desc |
Descrizione |
---|---|---|
0 |
NOTHING |
Attualmente vi sono uno o più file di log virtuali riutilizzabili. |
1 |
CHECKPOINT |
Non si è verificato alcun checkpoint dall'ultimo troncamento del log oppure l'inizio del log non è stato ancora spostato oltre un file di log virtuale (tutti i modelli di recupero). Si tratta di una motivazione comune per il posticipo del troncamento del log. Per ulteriori informazioni, vedere Relazione tra i checkpoint e la parte attiva del log. |
2 |
LOG_BACKUP |
Un backup del log è necessario per spostare in avanti l'intestazione del log (solo modelli di recupero con registrazione completa o con registrazione minima delle operazioni bulk).
Nota
I backup del log non impediscono il troncamento.
Quando il backup del log viene completato, l'intestazione del log viene spostata in avanti e parte dello spazio del log potrebbe divenire riutilizzabile. |
3 |
ACTIVE_BACKUP_OR_RESTORE |
È in esecuzione un processo di backup o ripristino dei dati (tutti i modelli di recupero). Un processo di backup dei dati è analogo a una transazione attiva e, quando è in esecuzione, impedisce il troncamento. Per ulteriori informazioni, vedere "Operazioni di backup e ripristino dei dati" di seguito in questo argomento. |
4 |
ACTIVE_TRANSACTION |
Una transazione è attiva (tutti i modelli di recupero).
|
5 |
DATABASE_MIRRORING |
Il mirroring del database è sospeso o in modalità a prestazioni elevate, il database mirror è notevolmente in ritardo rispetto al database principale (solo modello di recupero con registrazione completa). Per ulteriori informazioni, vedere "Mirroring del database e log delle transazioni" di seguito in questo argomento. |
6 |
REPLICATION |
Durante le repliche transazionali, le transazioni significative per le pubblicazioni non sono ancora state recapitate al database di distribuzione (solo modello di recupero con registrazione completa). Per ulteriori informazioni, vedere "Replica transazionale e log delle transazioni" di seguito in questo argomento. |
7 |
DATABASE_SNAPSHOT_CREATION |
È in corso la creazione di uno snapshot del database (tutti i modelli di recupero). Si tratta di una motivazione comune, e generalmente di breve durata, per il posticipo del troncamento del log. |
8 |
LOG_SCAN |
È in corso una scansione del log (tutti i modelli di recupero). Si tratta di una motivazione comune, e generalmente di breve durata, per il posticipo del troncamento del log. |
9 |
OTHER_TRANSIENT |
Questo valore non è attualmente utilizzato. |
Operazioni di backup e ripristino dei dati
Durante le operazioni di backup o ripristino non può verificarsi il troncamento del log. In SQL Server 2005 e versioni successive i processi di backup del log possono essere eseguiti durante un backup dei dati. Non è tuttavia possibile eseguire il troncamento del log durante il backup dello stesso poiché l'intero log delle transazioni deve restare disponibile per l'operazione di backup dei dati. Se il troncamento del log è impedito da un backup dei dati, l'annullamento del backup può risolvere il problema immediato.
Per ulteriori informazioni sul troncamento del log, vedere Troncamento del log delle transazioni.
Transazioni attive con esecuzione prolungata
Per una transazione attiva è necessario che il log resti attivo dal record del log contenente l'inizio della transazione. Se, ad esempio, l'inizio e la fine di una transazione sono controllati dall'utente, una causa tipica di una transazione con esecuzione prolungata è l'avvio di una transazione da parte di un utente senza la successiva immissione di una risposta. In questi casi, sebbene la transazione in attesa di una risposta produca di per se stessa un aumento minimo del log, posticipa il troncamento del log con una conseguente considerevole crescita delle relative dimensioni.
[!NOTA]
Per informazioni su come evitare transazioni con esecuzione prolungata, vedere Codifica di transazioni efficienti.
Mirroring del database e log delle transazioni
Per il mirroring di database è necessario che ogni record del log resti attivo fino a quando l'istanza del server principale riceve la notifica dall'istanza del server mirror che il record è stato scritto su disco nel server mirror. Se l'istanza del server mirror non riesce a far fronte al carico di lavoro dell'istanza del server principale, la quantità di spazio nel log attivo aumenta di conseguenza. In questo caso può essere necessario interrompere il mirroring del database, eseguire un backup del log che consenta di troncare il log, applicare tale backup del log al database mirror (tramite WITH NORECOVERY) e riavviare il mirroring.
Importante |
---|
Inoltre, prima di avviare il mirroring, se sono stati eseguiti backup aggiuntivi del log dopo quello richiesto, è necessario applicare manualmente ogni backup del log aggiuntivo (sempre tramite WITH NORECOVERY). Dopo aver applicato l'ultimo backup del log, è possibile avviare il mirroring. |
Per ulteriori informazioni, vedere Rimozione del mirroring del database e Impostazione del mirroring del database.
Replica transazionale e log delle transazioni
A differenza della replica di tipo merge e della replica snapshot, la replica transazionale può influire sulle dimensioni del log delle transazioni. Se un database include una o più pubblicazioni transazionali, il log non viene troncato finché tutte le transazioni significative per le pubblicazioni non sono state recapitate al database di distribuzione. Se la dimensione del log delle transazioni sta aumentando in modo eccessivo e l'agente di lettura log viene eseguito in base a una pianificazione, è consigliabile ridurre l'intervallo tra le esecuzioni o impostare l'esecuzione in modalità continua. Se l'agente viene impostato per l'esecuzione in modalità continua (impostazione predefinita), verificare che sia in esecuzione. Per ulteriori informazioni sulla verifica dello stato dell'agente di lettura log, vedere Procedura: Visualizzazione delle informazioni ed esecuzione di attività relative agli agenti associati a una pubblicazione (Monitoraggio replica).
Inoltre, se nel database di pubblicazione o in quello di distribuzione è stata impostata l'opzione 'sync with backup', il troncamento del log viene posticipato fino al completamento del backup di tutte le transazioni. Se la dimensione del log delle transazioni sta aumentando in modo eccessivo e questa opzione è stata impostata, è consigliabile ridurre l'intervallo tra l'esecuzione dei backup di tale log. Per ulteriori informazioni sul backup e sul ripristino di database coinvolti nella replica transazionale, vedere Strategie per il backup e il ripristino della replica snapshot e della replica transazionale.
Per gestire la replica
Per monitorare la replica
Vedere anche