Transactions différées (SQL Server)

  • Article

S’applique à :SQL Server

Dans SQL Server Enterprise, une transaction endommagée peut devenir différée si les données requises par la restauration (annuler) sont hors connexion 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 restauration par progression s’achève et dont la restauration ne peut pas être annulée en raison d’une erreur. Si la transaction ne peut pas être annulée, elle est différée.

Note

Les transactions endommagées sont différées uniquement dans SQL Server Enterprise. Dans d’autres éditions de SQL Server, une transaction endommagée provoque l’échec du démarrage.

Généralement, une transaction différée peut se produire si, au cours d'une séquence de restauration de la base de données, une erreur d'E/S a empêché la lecture d'une page requise par la transaction. Cependant, une erreur au niveau des fichiers peut également engendrer des transactions différées. Une transaction différée peut aussi se produire lorsqu'une séquence de restauration partielle s'arrête à un point où l'annulation de la transaction est nécessaire et où une transaction requiert des données hors connexion.

Les transactions utilisateur en cours d'annulation qui rencontrent une erreur d'E/S provoquent la mise hors connexion de la totalité de la base de données. Lorsque la base de données est remise en ligne, la restauration par progression acquiert de nouveau tous les verrous qu'elle possédait et tente de restaurer toutes les transactions non validées. Toutes les données modifiées par une transaction demeurent correctement verrouillées jusqu'à ce que la transaction ait été restaurée. Les transactions qui ne peuvent pas être restaurées abandonneront leurs verrous une fois l'altération corrigée et la base de données redémarrée ou, après une restauration en ligne, une fois que sont résolues les transactions différées tandis que la base de données est en ligne. À ce stade, une transaction différée peut contenir des verrous qui empêchent certaines opérations sur la base de données dans sa globalité. Par exemple, si une transaction différée contient une instruction CREATE TABLE, aucun utilisateur ne peut créer de table tant que la transaction différée n'a pas été résolue.

Une transaction différée peut aussi se produire lorsqu'une restauration fragmentaire récupère une base de données à un point où une ou plusieurs transactions actives affectent un groupe de fichiers hors connexion et n'ayant pas encore été restaurés. Si les transactions ne peuvent pas être restaurées, elles deviennent différées.

Le tableau suivant répertorie les actions qui amènent une base de données à réaliser une récupération et le résultat en cas de problème d'E/S.

Action Résolution (en cas de problèmes d'E/S ou de données requises hors connexion)
Démarrage du serveur transaction différée
Restaurer transaction différée
Joindre Échec de l'attachement
Redémarrage automatique transaction différée
Création d'une base de données ou d'un instantané de base de données Échec de la création
Restauration par progression sur mise en miroir de bases de données transaction différée
Groupe de fichiers hors connexion transaction différée

Limitations et exigences

  • La base de données doit utiliser le mode de récupération FULL ou BULK-LOGGED.
  • Au moins une sauvegarde de base de données et de journal doit avoir été effectuée pour la base de données.
  • Les transactions différées ne s’appliquent pas aux erreurs rencontrées pendant la restauration d’une transaction une fois que la base de données est en ligne (p.ex., une erreur d’exécution).
  • Les transactions ne peuvent pas être différées pour les échecs de récupération pendant un attachement de base de données.
  • Certaines transactions telles que les transactions système (par exemple, l’allocation de pages) ne peuvent pas être différées

Mise d'une transaction hors de l'état DEFERRED

Important

Une transaction différée maintient actif le journal des transactions. Un fichier journal virtuel qui contient des transactions différées ne peut pas être tronquées tant que ces transactions n'ont pas quitté l'état différé. Pour plus d’informations sur la troncation du journal, consultez le journal des transactions (SQL Server).

Pour que la transaction ne soit plus dans un état différé, la base de données doit démarrer correctement sans erreurs d'E/S. Si des transactions différées existent, vous devez corriger la source des erreurs d'E/S. Les solutions possibles sont répertoriées ci-dessous dans l'ordre dans lequel elles sont essayées habituellement :

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

  • Si les transactions ont été différées parce qu'un groupe de fichiers se trouvait hors connexion, placez le groupe de fichiers en ligne.

    Pour revenir 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.

    En mode de restauration complète ou en mode de récupération utilisant les journaux de transactions, si les transactions différées sont dues à quelques pages endommagées, une restauration de pages en ligne peut éventuellement résoudre les erreurs (là où elle est prise en charge).

  • Si vous n'avez plus besoin d'un groupe de fichiers dont l'état hors connexion entraîne des transactions différées, rendez-les obsolètes. Les transactions qui étaient différées en raison du groupe de fichiers hors connexion quittent l'état différé une fois que le groupe de fichiers est obsolète.

    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 erronée et s'il n'existe pas de bonne sauvegarde de la base de données, procédez comme suit 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 urgence, consultez États d’une 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 CHECKALLOCou DBCC CHECKTABLE.

      Lorsque la commande DBCC rencontre la page erronée, elle la désalloue et répare les éventuelles erreurs associées. Cette approche permet de remettre en ligne la base de données dans un état physique cohérent. Il se peut néanmoins que d'autres données soient perdues ; c'est pourquoi cette approche ne doit être adoptée qu'en 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 restauration complète)
Restaurations de fichiers (mode de récupération simple)
Restaurer des pages (SQL Server)
Restaurations fragmentaires (SQL Server)
ALTER DATABASE (Transact-SQL)
RESTORE (Transact-SQL)