Microsoft distribue Microsoft SQL Server 2008 R2 Service Pack 1 (SP1) ou Microsoft SQL Server 2008 ou Microsoft SQL Server 2012 résolu dans un fichier téléchargeable. Dans la mesure où les correctifs sont cumulatifs, chaque nouvelle version contient tous les correctifs et toutes les mises à jour de sécurité qui ont été incluses dans les versions antérieures de SQL Server 2008 R2 Service Pack 1 (SP1) ou SQL Server 2008 ou Microsoft SQL Server 2012 Update.

Symptômes

La restauration d’une base de données dans Microsoft SQL Server 2008 R2 ou dans Microsoft SQL Server 2008 ou Microsoft SQL Server 2012 peut prendre un certain temps.

Cause

Ce problème se produit parce que le temps nécessaire à la génération de la liste du fichier journal virtuel (VLF) est important lorsque de nombreux VLFs sont présents dans la base de données.

Résolution

Informations sur les mises à jour cumulatives

SQL Server 2012

Le correctif de ce problème a été émis pour la première fois dans la mise à jour cumulative 1 pour SQL Server 2012. Pour plus d’informations sur ce package de mise à jour cumulative, cliquez sur le numéro ci-dessous pour consulter l’article de la base de connaissances Microsoft :

2679368 Package de mise à jour cumulative 1 pour SQL Server 2012Remarque Dans la mesure où les builds sont cumulatives, chaque nouvelle version du correctif contient tous les correctifs et les correctifs de sécurité inclus dans l’ancienne version du correctif SQL Server 2012. Microsoft vous recommande d’appliquer la version de correctif la plus récente qui contient ce correctif. Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :

2692828 Builds SQL Server 2012 publiées après la sortie de SQL Server 2012 Vous devez appliquer un correctif SQL Server 2012 à une installation de SQL Server 2012.

SQL Server 2008 Service Pack 2

Le correctif de ce problème a été émis pour la première fois dans la mise à jour cumulative 8 pour SQL Server 2008 Service Pack 2. Pour plus d’informations sur ce package de mise à jour cumulative, cliquez sur le numéro ci-dessous pour consulter l’article de la base de connaissances Microsoft :

2648096 Package de mise à jour cumulative 8 pour SQL Server 2008 Service Pack 2Remarque Dans la mesure où les builds sont cumulatives, chaque nouvelle version du correctif contient tous les correctifs et les correctifs de sécurité inclus dans l’ancienne version du correctif SQL Server 2008. Microsoft vous recommande d’appliquer la version de correctif la plus récente qui contient ce correctif. Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :

2402659 Builds SQL Server 2008 publiées après la sortie de SQL Server 2008 Service Pack 2 Des correctifs Microsoft SQL Server 2008 sont créés pour des service packs SQL Server spécifiques. Vous devez appliquer un correctif SQL Server 2008 Service Pack 2 à une installation de SQL Server 2008 Service Pack 2. Par défaut, tout correctif fourni dans un service pack SQL Server est inclus dans le prochain Service Pack SQL Server.

SQL Server 2008 Service Pack 3

Le correctif de ce problème a été émis pour la première fois dans la mise à jour cumulative 3 pour SQL Server 2008 Service Pack 3. Pour plus d’informations sur ce package de mise à jour cumulative, cliquez sur le numéro ci-dessous pour consulter l’article de la base de connaissances Microsoft :

2648098 Package de mise à jour cumulative 3 pour SQL Server 2008 Service Pack 3Remarque Dans la mesure où les builds sont cumulatives, chaque nouvelle version du correctif contient tous les correctifs et les correctifs de sécurité inclus dans l’ancienne version du correctif SQL Server 2008. Microsoft vous recommande d’appliquer la version de correctif la plus récente qui contient ce correctif. Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :

2629969 Builds SQL Server 2008 publiées après la sortie de SQL Server 2008 Service Pack 3 Des correctifs Microsoft SQL Server 2008 sont créés pour des service packs SQL Server spécifiques. Vous devez appliquer un correctif SQL Server 2008 Service Pack 3 à une installation de SQL Server 2008 Service Pack 3. Par défaut, tout correctif fourni dans un service pack SQL Server est inclus dans le prochain Service Pack SQL Server.

Package de mise à jour cumulative 11 pour SQL Server 2008 R2

Le correctif de ce problème a été émis pour la première fois dans la mise à jour cumulative 11. Pour plus d’informations sur la façon d’obtenir ce package de mise à jour cumulative pour SQL Server 2008 R2, cliquez sur le numéro ci-dessous pour consulter l’article de la base de connaissances Microsoft :

2633145 Package de mise à jour cumulative 11 pour SQL Server 2008 R2Remarque Dans la mesure où les builds sont cumulatives, chaque nouvelle version du correctif contient tous les correctifs et les correctifs de sécurité inclus dans la version précédente du correctif SQL Server 2008 R2. Nous vous recommandons d’appliquer la version de correctif la plus récente qui contient ce correctif. Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :

981356 Builds SQL Server 2008 R2 publiées après la sortie de SQL Server 2008 R2

Package de mise à jour cumulative 4 pour SQL Server 2008 R2 SP1

Le correctif de ce problème a été émis pour la première fois dans la mise à jour cumulative 4. Pour plus d’informations sur la façon d’obtenir ce package de mise à jour cumulative pour SQL Server 2008 R2 SP1, cliquez sur le numéro ci-dessous pour consulter l’article de la base de connaissances Microsoft :

2633146 Package de mise à jour cumulative 4 pour SQL Server 2008 R2 SP1Remarque Dans la mesure où les builds sont cumulatives, chaque nouvelle version du correctif contient tous les correctifs et les correctifs de sécurité inclus dans la version précédente du correctif SQL Server 2008 R2 SP1. Nous vous recommandons d’appliquer la version de correctif la plus récente qui contient ce correctif. Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :

2567616 Builds SQL Server 2008 R2 publiées après la sortie de SQL Server 2008 R2 SP1

Statut

Microsoft a confirmé l'existence de ce problème dans les produits Microsoft figurant dans la liste des produits concernés par cet article.

Informations supplémentaires

Vous pouvez vérifier le nombre de segments VLF en passant en revue le fichier journal des erreurs SQL, puis en recherchant le numéro de séquence (LSN) dans chaque fichier de sauvegarde du journal des transactions. Les premiers chiffres précédant le signe deux-points dans le LSNs correspondent au numéro du LSN. Par exemple, le premier nombre du premier message d’information pour le LSN est 1. Toutefois, le premier numéro du second message d’information pour le LSN est 100001. Dans ce scénario, il existe des VLFs 100 000 qui sont utilisées entre la date du premier message d’information et du deuxième message d’information. C’est la raison pour laquelle le journal des transactions fragmentées en journal comporte de nombreux fichiers journaux virtuels (VLFs), qui ressemble à ce qui suit :

{Log a été sauvegardé. Base de données : mydbname, date de création (heure) : 2010/07/08 (12:36:46), premier LSN : 1:5068:70, dernier LSN : 1:5108:1, nombre d’appareils de vidage : 1, informations sur l’appareil : (fichier = 1, TYPE = disque : {'C:\folder\logbackup1.TRN'}). Il s’agit d’un message d’information uniquement. Aucune action de l’utilisateur n’est requise. Le journal a été sauvegardé. Base de données : mydbname, date de création (heure) : 2010/07/08 (15:36:46), premier LSN : 100001:5108:1, dernier LSN : 100002:5108:1, nombre d’appareils de vidage : 1, informations sur l’appareil : (fichier = 2, TYPE = disque : {'C:\folder\logbackup2.TRN'}). Il s’agit d’un message d’information uniquement. Aucune action de l’utilisateur n’est requise.}

Références

Pour plus d’informations sur les numéros de séquence de journaux (LSN), visitez le site Web MSDN suivant :

Informations générales sur les numéros de séquence de journal

Pour plus d’informations sur la façon dont une structure de fichier journal peut affecter le temps de récupération de la base de données, consultez le site Web MSDN suivant :

Comment une structure de fichier journal peut affecter le temps de récupération de la base de donnéesPour plus d’informations sur le journal des transactions de VLFs, visitez le site Web MSDN suivant :

Informations générales sur le fichier journal des transactions

Solution de contournement

  • Attendez la fin de l’opération de restauration ou de récupération.Si vous disposez d’une base de données non récupérée présentant des performances dégradées lors de la restauration ou de la récupération de la base de données, vous devrez peut-être attendre la fin de l’opération de restauration ou de récupération. Par exemple, vous pouvez voir l’état hors connexion ou l’État récupération dans SQL Server Management Studio (SSMS) pour une base de données non récupérée. Le fait d’arrêter SQL Server n’est en général pas en relief pour une récupération lente et risque de durer plus longtemps pour répéter la même phase d’analyse de récupération, la phase de rétablissement ou la phase d’annulation.

  • Evitez de restaurer la séquence du journal des transactions qui contient des milliers de VLFsSi vous subissez une baisse des performances lors de la restauration et de la restauration d’une base de données à l’aide d’un fichier de sauvegarde, vous pouvez éviter de restaurer les séquences du journal de transactions qui contiennent des milliers de VLFs. Pour identifier le fichier de sauvegarde qui comporte le plus de fichiers journaux enregistrés, utilisez les instructions suivantes pour afficher les colonnes FirstLSN et LastLSN dans les fichiers de sauvegarde du journal : RESTORE HEADERONLY de DISK = 'C:\folder\file.TRN’vous pouvez éviter de restaurer les fichiers de sauvegarde du journal. Vous pouvez aussi utiliser l’instruction STOP AT dans les commandes de restauration pour éviter les parties très fragmentées des journaux de transactions. Si vous ne restaurez pas entièrement les séquences de journaux jusqu’au dernier point dans le temps au cours d’un scénario de récupération d’échec, une perte de données se produit dans votre serveur SQL Server. Cette perte de données se produit parce que toutes les transactions ne sont pas conservées. Par conséquent, il existe une décision de compromis pour les entreprises. Vous pouvez entièrement restaurer un journal de transactions fortement fragmenté. Toutefois, cette opération risque de prendre plusieurs heures. Vous pouvez aussi utiliser l’instruction STOP AT dans la récupération pour arrêter la récupération avant la partie très fragmentée du journal. Toutefois, toutes les transactions manquantes que vous avez omises sont perdues.Remarque Si vous n’avez pas installé ce correctif, il n’y a généralement pas de recours sécurisé pour la récupération après le redémarrage de SQL Server. SQL Server doit rechercher la liste des VLFs afin d’analyser les fichiers journaux, de rétablir les transactions terminées, puis d’annuler les transactions inachevées pour finaliser la base de données en ligne. Vous ne pouvez pas ignorer de transactions en toute sécurité lors de la récupération.

Besoin d’aide ?

Développez vos compétences
Découvrez des formations
Accédez aux nouvelles fonctionnalités en avant-première
Rejoindre Microsoft Insider

Ces informations vous ont-elles été utiles ?

Dans quelle mesure êtes-vous satisfait(e) de la qualité de la langue ?
Qu’est-ce qui a affecté votre expérience ?

Nous vous remercions de vos commentaires.

×