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 viene riattivata la modalità online 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 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, 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 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 usare il modello di recupero con registrazione completa o con registrazione minima delle operazioni bulk.
• È 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

Annullamento dello stato di transazione posticipata

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. Quando il filegroup in questione diventa offline, lo stato di transazione posticipata viene annullato.

  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 attivare di nuovo la modalità online per il database in uno stato fisicamente consistente. È 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)
Rimuovere filegroup inattivi (SQL Server)
Ripristini di file (modello di recupero con registrazione completa)
Ripristini di file (modello di recupero con registrazione minima)
Ripristino di pagine (SQL Server)
Ripristini a fasi (SQL Server)
ALTER DATABASE (Transact-SQL)
RESTORE (Transact-SQL)