Fattori che possono ritardare il troncamento del log
Data aggiornamento: 17 luglio 2006
Il troncamento del log libera spazio nel file di log che può essere riutilizzato dal log delle transazioni. Poiché non è possibile troncare o rimuovere la 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 rimanere attivi in diverse condizioni, descritte in questo argomento. È possibile individuare la condizione che impedisce il troncamento del log utilizzando le colonne log_reuse_wait e log_reuse_wait_desc della vista del catalogo sys.database.
[!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 tabella seguente vengono descritti i valori delle colonne log_reuse_wait e log_reuse_wait_desc della vista del catalogo sys.database.
log_reuse_wait value
log_reuse_wait_desc value
Descrizione
0
NOTHING
Esistono attualmente 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
È necessario un backup del log per spostare in avanti l'inizio del log (solo per modelli di recupero completo o con registrazione minima delle transazioni di massa).
.gif "ms345414.note(it-it,SQL.90).gif")
Nota:
I backup del log non impediscono il troncamento.
Quando il backup del log è completato, l'inizio del log viene spostato in avanti e una certa quantità di spazio del log potrebbe essere riutilizzata.
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).
- Potrebbe essere presente una transazione con esecuzione prolungata all'inizio del backup del log. In questo caso, la liberazione dello spazio potrebbe richiedere un altro backup del log. Per ulteriori informazioni, vedere "Transazioni attive con esecuzione prolungata" di seguito in questo argomento.
- Una transazione viene posticipata (solo in SQL Server 2005 Enterprise Edition e versioni successive). Una transazione posticipata è in effetti una transazione attiva il cui rollback viene bloccato a causa di alcune risorse non disponibili. Per informazioni sulle cause delle transazioni posticipate e sul loro spostamento dallo stato di transazione posticipata, vedere Transazioni posticipate.
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. Quando si eseguono backup di file, l'utilizzo dell'opzione WITH NO_LOG può consentire di evitare il problema che impedisce il troncamento del log.
Per ulteriori informazioni sul troncamento del log, vedere Troncamento del log delle transazioni.
| Importante: |
|---|
| Le opzioni NO_LOG e TRUNCATE_ONLY dell'istruzione BACKUP LOG verranno rimosse a partire da una delle prossime versioni di SQL Server. Queste opzioni rimuovono la parte inattiva del log senza crearne una copia di backup e troncano il log eliminando tutto tranne il log attivo. In questo modo, viene interrotta la catena di log. Il database rimane infatti non protetto da errori dei supporti fino al successivo backup completo o differenziale del database. È pertanto consigliabile evitare di utilizzare queste opzioni e pianificare la modifica delle applicazioni che ne fanno uso. |
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 oppure impostarlo per 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
Concetti
Relazione tra i checkpoint e la parte attiva del log
Troncamento del log delle transazioni
Compattazione del log delle transazioni
Risoluzione dei problemi relativi a un log delle transazioni pieno (Errore 9002)
Altre risorse
Gestione del log delle transazioni