KB2653893 - CORRECTIF : la restauration d’une base de données dans SQL Server 2008 R2, dans SQL Server 2008 ou dans SQL 2012 prend beaucoup de temps

Symptômes

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

Cause

Ce problème se produit car la création de la liste du fichier journal virtuel (VLF) prend beaucoup de temps lorsque la base de données contient de nombreux fichiers journaux virtuels.

Résolution

État

Microsoft a confirmé l’existence de ce problème dans les produits Microsoft répertoriés dans la section « S’applique à ».

Informations supplémentaires

Vous pouvez case activée le nombre de segments VLF en examinant le fichier journal des erreurs SQL, puis en recherchant le numéro séquentiel du journal (LSN) dans chaque fichier de sauvegarde du journal des transactions. Les premiers chiffres avant le symbole deux-points dans les numéros LSN correspondent au numéro du LSN.

Par exemple, le premier nombre du premier message d’information pour le numéro LSN est 1. Toutefois, le premier nombre du deuxième message d’information pour le LSN est 100001. Dans ce scénario, 100 000 fichiers journaux virtuels sont utilisés entre l’heure du premier message d’information et celle du deuxième message d’information. Par conséquent, le journal des transactions fragmenté journalisé qui a de nombreux Files de journaux virtuels (VDF) ressemble à ce qui suit :

{Le journal 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 de périphériques de vidage : 1, informations sur l’appareil : (FILE=1, TYPE=DISK : {'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 numéro LSN : 100001:5108:1, dernier LSN : 100002:5108:1, nombre de périphériques de vidage : 1, informations sur l’appareil : (FILE=2, TYPE=DISK : {'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 journal (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, visitez 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 les fichiers journaux virtuels du journal des transactions, 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 avez une base de données non récupérée qui connaît des performances lentes lorsque vous restaurez ou récupérez la base de données, vous devrez peut-être attendre que l’opération de restauration ou de récupération soit terminée. Par exemple, vous pouvez voir le status hors connexion ou le status de récupération dans SQL Server Management Studio (SSMS) pour une base de données non récupérée. L’arrêt de SQL Server n’offre généralement aucun soulagement pour une récupération lente et peut prendre plus de temps pour répéter la même phase d’analyse de récupération, phase de restauration ou phase d’annulation.

• Évitez de restaurer la séquence du journal des transactions qui contient des milliers de
  
  fichiers journaux virtuels Si vous constatez des performances lentes lors de la restauration et de la récupération d’une base de données à l’aide d’un fichier de sauvegarde, vous pouvez éviter de restaurer les séquences du journal des transactions qui contiennent des milliers de fichiers journaux virtuels. Pour identifier le fichier de sauvegarde contenant le plus de fichiers journaux virtuels enregistrés, utilisez l’instruction suivante pour afficher les colonnes FirstLSN et LastLSN dans les fichiers de sauvegarde des journaux :
  RESTORE HEADERONLY FROM DISK='C :\folder\file.trn’Vous pouvez décider d’éviter
  
  la restauration des fichiers de sauvegarde des journaux. Vous pouvez également utiliser l’instruction STOP AT dans les commandes RESTORE pour éviter les parties très fragmentées des journaux des transactions. Si vous ne restaurez pas entièrement les séquences de journal jusqu’au dernier point dans le temps pendant un scénario de récupération d’échec, la perte de données se produit dans votre base de données SQL Server. Cette perte de données se produit car toutes les transactions ne sont pas conservées. Par conséquent, il y a un compromis commercial. Vous pouvez restaurer entièrement un journal des transactions très fragmenté. Toutefois, cette opération peut prendre de nombreuses heures. Vous pouvez également 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 omettez sont perdues.
  
  Remarque Sans installer ce correctif logiciel, il n’existe généralement aucun recours sécurisé pour la récupération accélérée après avoir redémarré SQL Server. SQL Server devez localiser la liste des fichiers journaux pour analyser les fichiers journaux, rétablir les transactions terminées, puis annuler les transactions incomplètes pour terminer la récupération et mettre la base de données en ligne en toute sécurité. Vous ne pouvez pas ignorer en toute sécurité les transactions pendant la récupération.