Partager via

La restauration d’une base de données SQL Server à l’aide d’une application VDI avec multi-bandes peut échouer avec l’erreur 3456

  • Article

Cet article vous aide à résoudre un problème qui se produit lorsque vous utilisez des applications VDI (Virtual Device Interface) pour restaurer vos bases de données SQL Server.

Symptômes

Lorsque vous restaurez une sauvegarde complète de l’interface de périphérique virtuel à plusieurs bandes sur SQL Server 2019 ou une version ultérieure, vous pouvez obtenir l’erreur MSSQLSERVER_3456 :

Msg 3456, Level 16, State 1, Line <LineNumber>
Could not redo log record (120600:18965748:1), for transaction ID (0:1527178398), on page (14:1987189), allocation unit 72057761533001728, database 'DB1_STRIPE' (database ID 8).
Page: LSN = (120598:23255372:8), allocation unit = 72057761317781504, type = 1. Log: OpCode = 6, context 2, PrevPageLSN: (120600:18965371:85).

Cause

Quand SQL Server sauvegarde vers VDI, il transmet les données à l’infrastructure VDI via une mémoire tampon. L’infrastructure VDI gère ensuite la mise en forme de la façon de stocker cette sauvegarde. Toutefois, dans de nombreux cas, le client VDI peut s’attendre à une seule copie de chaque page de données.

Lorsque vous associez une sauvegarde à VDI, plusieurs périphériques de sauvegarde composent le contenu d’une sauvegarde complète. Les données sont écrites de manière asynchrone et l’ordre de copie des données est géré par la logique du client VDI. Étant donné que la phase de copie de données est asynchrone, les données peuvent être écrites hors ordre. Toutefois, dans un scénario de sauvegarde complète avant SQL Server 2019, il n’existe qu’une seule copie par page de données. Par conséquent, lorsque le client VDI envoie des données à la mémoire tampon à partir de laquelle SQL Server lit pour une restauration, SQL Server peut toujours savoir exactement où et comment restaurer chaque page de données. Avec l’introduction de l’épinglage différé du journal dans SQL Server 2019, plusieurs copies de la page de données peuvent être trouvées dans les fichiers de sauvegarde. Plusieurs copies existent en raison d’une sauvegarde mini différentielle qui se produit à l’intérieur de la sauvegarde complète (consultez la section Plus d’informations pour plus d’informations ). Le client VDI ne s’attend pas à plusieurs copies de la même page de données, ou à transmettre les pages de données à SQL Server dans un ordre incorrect. Ce comportement provoque l’échec de la restauration. L’erreur 3456 Could not redo log record indique que SQL Server tente d’appliquer un enregistrement de journal qui attend la dernière version de la page de données, mais qu’il trouve une version antérieure.

Résolution

  1. Selon votre configuration, vous devez activer un ou plusieurs indicateurs de trace en tant que paramètres de démarrage pour votre instance SQL Server :

    • Si vous effectuez des sauvegardes complètes lorsque l’instance joue le rôle de réplica principal ou d’instance sans groupes de disponibilité, activez l’indicateur de trace 3471 pour désactiver la fonctionnalité d’épinglage de journal différée pour les sauvegardes complètes.

    • Si vous effectuez des sauvegardes différentielles lorsque l’instance joue le rôle de réplica principal ou d’instance sans groupes de disponibilité, activez l’indicateur de trace 3475 pour désactiver la fonctionnalité d’épinglage de journal différée pour les sauvegardes différentielles.

    • Si vous effectuez des sauvegardes complètes avec COPY_ONLY lorsque l’instance agit en tant que réplica secondaire, activez l’indicateur de trace 3472 pour désactiver la fonctionnalité d’épinglage de journal différée pour les sauvegardes différentielles.

  2. Redémarrez SQL Server.

  3. Effectuez à nouveau vos sauvegardes complètes ou différentielles.

Note

Vous pouvez également activer temporairement ces indicateurs de trace à l’aide de la commande DBCC TRACEON .

DBCC TRACEON(3471,3472,3475,-1)

Cette commande peut être utilisée pour atténuer le problème si vous ne pouvez pas redémarrer votre instance SQL Server immédiatement.

Important

En raison de ce problème, les sauvegardes existantes peuvent ne pas être restaurées si les conditions suivantes sont remplies :

  • La sauvegarde est effectuée avec la fonctionnalité d’épinglage de journal différée activée.
  • L’outil de sauvegarde utilise VDI.
  • La sauvegarde est effectuée à l’aide du multi-bandes (sauvegarde dans plusieurs fichiers).

Nous vous encourageons à restaurer vos sauvegardes existantes sur un serveur de test pour vérifier si elles peuvent être restaurées avec succès.

Plus d’informations

SQL Server 2019 introduit une fonctionnalité appelée épinglage différé du journal. Avant l’introduction de cette fonctionnalité, lors d’une sauvegarde complète de la base de données, SQL Server bloque les transactions (épingle le journal), copie les données et le journal, puis supprime l’épingle directement au début. Avec la fonctionnalité présente, SQL Server retarde les transactions (épingle le journal) vers la fin de la durée de sauvegarde, au lieu de droite au début. Cette fonctionnalité est conçue pour éviter un problème complet de journal des transactions (MSSQLSERVER_9002 erreur) pendant une sauvegarde complète qui prend beaucoup de temps. Étant donné que l’épinglage du journal est retardé, les transactions sont toujours autorisées à être appliquées aux pages de données de la base de données pendant que la sauvegarde est en cours. SQL Server gère une bitmap pour identifier les pages qui ont changé depuis l’heure de début de la sauvegarde complète en cours, afin qu’il puisse effectuer une sauvegarde mini différentielle. De cette façon, il obtient une copie mise à jour de chaque page de données qui a été modifiée pendant la sauvegarde de l’intégralité de la base de données. Cela entraîne une copie supplémentaire de certaines pages de données. En outre, cette section supplémentaire de la sauvegarde complète est créée.