Transazioni posticipate (SQL Server)

Si applica a:SQL Server

In SQL Server Enterprise una transazione danneggiata può diventare posticipata se i dati necessari per il rollback (annullamento) sono offline 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.

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 arresta in un punto in cui è necessario eseguire il rollback della transazione e i dati richiesti dalla transazione sono offline.

Se si verifica un errore di I/O durante il rollback delle transazioni utente, verrà attivata la modalità offline per l'intero database. Quando il database viene riportato online, il redo riacquisisce tutti i lock che aveva e tenta di eseguire il rollback di tutte le transazioni non sottoposte a 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 online, quando le transazioni posticipate vengono risolte mentre il database rimane online. 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 , nessun utente può creare una tabella fino a quando non viene risolta la 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 ed è offline. 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.

Requisiti e limitazioni

• Il database deve utilizzare il modello di recupero FULL o BULK-LOGGED.
• È necessario che sia stato completato almeno un backup del database e dei log
• Le transazioni posticipate non si applicano agli errori rilevati durante un rollback di una transazione dopo che il database è online. ad esempio un errore di runtime.
• Le transazioni non possono essere posticipate per errori di recupero durante una connessione di database
• Alcune transazioni, come le transazioni di sistema (allocazione di pagine, ad esempio) non possono essere posticipate

Rimozione di una transazione dallo stato DEFERRED

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 offline, attivare di nuovo la modalità online per il filegroup.

  Per attivare di nuovo la modalità online per un filegroup, utilizzare l'istruzione Transact-SQL seguente:

  RESTORE DATABASE database_name FILEGROUP=<filegroup_name>  
  

• Ripristinare il database. Dopo un ripristino online, 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 online può risolvere gli errori (se supportato).

• Se non è più necessario un filegroup offline che causa transazioni posticipate, è possibile renderlo inattivo. Le transazioni che erano state differite perché il filegroup era offline escono dallo stato differito dopo che il filegroup diventa inutilizzabile.

  Importante

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

  Per altre informazioni, vedere Rimuovere filegroup inattivi (SQL Server).

• 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 usando l'opzione DBCC REPAIR_ALLOW_DATA_LOSS in una delle istruzioni DBCC seguenti: DBCC CHECKDB, DBCC CHECKALLOCo DBCC CHECKTABLE.

    Quando rileva la pagina danneggiata, DBCC ne esegue la deallocazione e corregge gli eventuali errori correlati. Questo approccio consente di riportare il database online in uno stato di consistenza fisica. È tuttavia possibile che vengano persi dati aggiuntivi. Utilizzare pertanto questo approccio solo se strettamente necessario.

Vedi anche

Panoramica del ripristino e del recupero (SQL Server)
Rimuovi filegroup obsoleti (SQL Server)
Ripristino dei file (modello di recupero completo)
Ripristino dei file (modello di recupero semplice)
Ripristino di pagine (SQL Server)
Ripristini parziali (SQL Server)
ALTER DATABASE (Transact-SQL)
RESTORE (Transact-SQL)