Articolo
09/28/2010

Transazioni posticipate

In SQL Server 2005 Enterprise Edition e versioni successive una transazione danneggiata può diventare posticipata se i dati necessari per il rollback (annullamento) non sono in linea durante l'avvio del database. Una transazione posticipata è una transazione di cui non è stato eseguito il commit al termine della fase di rollforward e per la quale si è verificato un errore che ne impedisce il rollback. Non essendo possibile eseguire il rollback, la transazione viene posticipata.

[!NOTA]

Le transazioni danneggiate vengono posticipate solo in SQL Server 2005 Enterprise Edition e versioni successive. Nelle altre edizioni di SQL Server una transazione danneggiata causa un errore di avvio.

In genere, una transazione posticipata si verifica perché durante il rollforward del database un errore di I/O ha impedito la lettura di una pagina necessaria per la transazione. Anche un errore a livello di file può tuttavia determinare transazioni posticipate. Una transazione posticipata si può verificare anche quando una sequenza di ripristino parziale si interrompe in un punto in cui è necessario eseguire il rollback della transazione e i dati richiesti dalla transazione non sono in linea.

Se si verifica un errore di I/O durante il rollback delle transazioni utente, verrà attivata la modalità non in linea per l'intero database. Quando viene riattivata la modalità in linea per il database, il rollforward riacquisisce tutti i blocchi precedenti e tenta di eseguire il rollback delle transazioni di cui non è stato eseguito il commit. Tutti i dati modificati da una transazione rimangono bloccati nel modo appropriato fino a quando non è possibile eseguire il rollback della transazione. Le transazioni di cui non è possibile eseguire il rollback rilasciano i relativi blocchi quando il problema di danneggiamento viene risolto e il database viene riavviato oppure, dopo un ripristino in linea, quando le transazioni posticipate vengono risolte mentre il database rimane in linea. Fino a quel momento, una transazione posticipata può mantenere attivi blocchi che impediscono l'esecuzione di determinate operazioni sull'intero database. Ad esempio, se una transazione posticipata contiene un'istruzione CREATE TABLE, verrà impedito agli utenti di creare una tabella fino alla risoluzione della transazione posticipata.

Una transazione posticipata si può anche verificare quando un ripristino a fasi recupera un database fino a un punto in cui una o più transazioni attive influiscono su un filegroup che non è ancora stato ripristinato e non è in linea. Non essendo possibile eseguire il rollback, le transazioni diventano posticipate.

Nella tabella seguente sono illustrate le azioni che determinano l'esecuzione di un recupero in un database e il risultato ottenuto nel caso si verifichi un errore di I/O.

Azione	Risoluzione (se si verificano problemi di I/O oppure i dati necessari non sono in linea)
Avvio del server	Transazione posticipata
Ripristino	Transazione posticipata
Collegamento	Il collegamento ha esito negativo
Riavvio automatico	Transazione posticipata
Creazione di database o di snapshot del database	La creazione ha esito negativo
Rollforward nel mirroring del database	Transazione posticipata
Filegroup non in linea	Transazione posticipata

Annullamento dello stato di transazione posticipata

Importante
Le transazioni posticipate mantengono attivo il log delle transazioni. Un file di log virtuale contenente transazioni posticipate non può essere troncato fino a quando lo stato di transazione posticipata non viene annullato. Per ulteriori informazioni sul troncamento del log, vedere Troncamento del log delle transazioni.

Per annullare lo stato di transazione posticipata, è necessario che durante l'avvio del database non si verifichino errori di I/O. Se sono presenti transazioni posticipate, è necessario correggere l'origine degli errori di I/O. Di seguito sono riportate le soluzioni possibili, elencate nell'ordine in cui solitamente vengono tentate:

Riavviare il database. Se il problema era temporaneo, il database verrà avviato senza transazioni posticipate.
Se le transazioni sono state posticipate a causa di un filegroup non in linea, attivare di nuovo la modalità in linea per il filegroup.

Per attivare di nuovo la modalità in linea per un filegroup, utilizzare l'istruzione Transact-SQL seguente:
```
RESTORE DATABASE database_name FILEGROUP=<filegroup_name>
```
Ripristinare il database. Dopo un ripristino in linea, eventuali transazioni posticipate vengono risolte.

In base al modello di recupero con registrazione completa o con registrazione minima delle operazioni bulk, se le transazioni posticipate sono causate da un numero ridotto di pagine danneggiate, un ripristino delle pagine in linea può risolvere gli errori (se supportato).
Se non è più necessario un filegroup non in linea che causa transazioni posticipate, è possibile renderlo inattivo. Quando il filegroup in questione diventa inattivo, lo stato di transazione posticipata viene annullato.

Importante

Un filegroup inattivo non può in alcun modo essere recuperato.

Per ulteriori informazioni, vedere Filegroup inattivi.
Se le transazioni sono state posticipate a causa di una pagina danneggiata e non è disponibile un backup valido del database, eseguire le operazioni seguenti per correggere gli errori del database:
- Attivare innanzitutto la modalità di emergenza del database eseguendo l'istruzione Transact-SQL seguente:
```
ALTER DATABASE <database_name> SET EMERGENCY
```
  Per informazioni sulla modalità di emergenza, vedere Stati del database.
- Correggere quindi gli errori del database utilizzando l'opzione DBCC REPAIR_ALLOW_DATA_LOSS in una delle istruzioni DBCC seguenti: DBCC CHECKDB, DBCC CHECKALLOC o DBCC CHECKTABLE.
  
  Quando rileva la pagina danneggiata, DBCC ne esegue la deallocazione e corregge gli eventuali errori correlati. Questo approccio consente di attivare di nuovo la modalità in linea per il database in uno stato fisicamente consistente. È tuttavia possibile che vengano persi dati aggiuntivi. Utilizzare pertanto questo approccio solo se strettamente necessario.