Transactions différées (SQL Server)

Dans l'édition Enterprise de SQL Server, une transaction endommagée peut devenir différée si les données requises pour l'annulation sont hors ligne pendant le démarrage de la base de données. Une transaction différée est une transaction qui n’est pas validée lorsque la phase de roll forward est terminée et qui a rencontré une erreur qui l’empêche d’être annulée. Étant donné que la transaction ne peut pas être restaurée, elle est différée.

En règle générale, une transaction différée se produit parce que, pendant la restauration de la base de données, une erreur d’E/S empêchait de lire une page requise par la transaction. Toutefois, une erreur au niveau du fichier peut également entraîner des transactions différées. Une transaction différée peut également se produire lorsqu’une séquence de restauration partielle s’arrête à un moment où la restauration des transactions est nécessaire et qu’une transaction nécessite des données hors connexion.

Les transactions utilisateur qui sont annulées et qui atteignent une erreur d’E/S entraînent la mise hors connexion de l’ensemble de la base de données. Lorsque la base de données est remise en ligne, le redo réacquiert tous les verrous qu'il avait et tente d'annuler toutes les transactions non validées. Toutes les données modifiées par une transaction restent correctement verrouillées jusqu’à ce que la transaction puisse être rétablie. Les transactions qui ne peuvent pas être restaurées abandonnent leurs verrous lorsque l’altération est corrigée et que la base de données a redémarré ou, après une restauration en ligne, lorsque les transactions différées sont résolues pendant que la base de données reste en ligne. Jusqu’à ce stade, une transaction différée peut contenir des verrous qui empêchent certaines opérations sur la base de données dans son ensemble. Par exemple, si une transaction différée contient une instruction CREATE TABLE, aucun utilisateur ne peut créer une table tant que la transaction différée n’a pas été résolue.

La transaction différée peut également se produire, car une restauration fragmentaire récupère une base de données à un point auquel une ou plusieurs transactions actives affectent un groupe de fichiers qui n’a pas encore été restauré et est hors connexion. Étant donné que les transactions ne peuvent pas être restaurées, elles deviennent différées.

Le tableau suivant répertorie les actions qui provoquent une récupération d’une base de données et le résultat si un problème d’E/S se produit.

Déplacement d’une transaction hors de l’état DIFFÉRÉ

Pour déplacer la transaction hors de l’état différé, la base de données doit démarrer correctement sans aucune erreur d’E/S. Si des transactions différées existent, vous devez corriger la source des erreurs d’E/S. Les solutions disponibles, répertoriées dans l’ordre dans lequel elles sont généralement essayées, sont les suivantes :

• Redémarrez la base de données. Si le problème était temporaire, la base de données doit démarrer sans transactions différées.

• Si les transactions ont été différées, car un groupe de fichiers était hors connexion, ramenez le groupe de fichiers en ligne.

  Pour remettre en ligne un groupe de fichiers hors connexion, utilisez l’instruction Transact-SQL suivante :

  RESTORE DATABASE database_name FILEGROUP=<filegroup_name>  
  

• Restaurez la base de données. Après une restauration en ligne, toutes les transactions différées sont résolues.

  Sous le modèle de récupération complète ou journalisée en bloc, si les transactions différées étaient causées par seulement quelques pages endommagées, une restauration de page en ligne peut résoudre les erreurs (où prises en charge).

• Si vous n’avez plus besoin d’un groupe de fichiers dont l’état hors connexion provoque des transactions différées, désactivez le groupe de fichiers hors connexion. Les transactions qui ont été différées, car le groupe de fichiers était hors connexion sont déplacées hors de l’état différé après la fin du groupe de fichiers.

  Important

  Un groupe de fichiers obsolète ne peut jamais être récupéré.

  Pour plus d’informations, consultez Supprimer les groupes de fichiers obsolètes (SQL Server).

• Si les transactions ont été différées en raison d’une page incorrecte et si une bonne sauvegarde de la base de données n’existe pas, utilisez le processus suivant pour réparer la base de données :

  • Commencez par placer la base de données en mode d’urgence en exécutant l’instruction Transact-SQL suivante :

    ALTER DATABASE <database_name> SET EMERGENCY  
    

    Pour plus d’informations sur le mode d’urgence, consultez États de base de données.

  • Ensuite, réparez la base de données à l’aide de l’option DBCC REPAIR_ALLOW_DATA_LOSS dans l’une des instructions DBCC suivantes : DBCC CHECKDB, DBCC CHECKALLOC ou DBCC CHECKTABLE.

    Lorsque DBCC rencontre la page incorrecte, DBCC la désalloue et répare toutes les erreurs associées. Cette approche permet à la base de données d’être remise en ligne dans un état physiquement cohérent. Toutefois, des données supplémentaires peuvent également être perdues ; par conséquent, cette approche devrait être utilisée comme dernier recours.

Voir aussi

Vue d'ensemble de la restauration et de la récupération (SQL Server)
Supprimer des groupes de fichiers obsolètes (SQL Server)
Restaurations de fichiers (mode de récupération complète)
Restaurations de fichiers (modèle de récupération simple)
Restaurer des pages (SQL Server)
Restaurations partielles (SQL Server)
MODIFIER LA BASE DE DONNÉES (Transact-SQL)
RESTORE (Transact-SQL)