Comment faire pour résoudre les problèmes liés à l’erreur 3414 et une restauration de base de données a échoué avec SQL Server

S’applique à : SQL Server 2014

Symptômes


Lors de la récupération d’une base de données échoue, une erreur semblable à celle-ci est écrite dans le journal des erreurs ou le journal des événements applications Windows avec EventID = 3414 :

Erreur : 3414, gravité : 21, état : 1. une erreur s’est produite lors de la récupération, empêchant le redémarrage de la base de données 'mydb » (13 de l’ID de base de données). Diagnostiquer les erreurs de récupération et corrigez-les ou restaurer à partir d’une sauvegarde correcte. Si les erreurs ne sont pas corrigées ou prévus, contactez le Support technique)

La raison de l’échec de la récupération est généralement une erreur qui précède 3414 d’erreur dans le journal des erreurs ou le journal des événements.

En cas d’échec de récupération avec cette erreur d’une base de données, l’état de la base de données a la valeur suspecte. Vous allez voir ce statut dans SQL Server Management Studio (près de l’icône de la base de données) et lorsque vous examinez la colonne sys.databases.state_desc. Toute tentative d’utilisation d’une base de données dans cet état entraîne l’erreur suivante :

Msg 926, niveau 14, état 1, ligne 1Database 'mydb' ne peut pas être ouvert. Elle a été marquée SUSPECT lors de la récupération. Consultez le journal des erreurs SQL Server pour plus d’informations

Cause


La cause de l’échec de la récupération se trouve dans les erreurs précédentes dans le journal des erreurs lorsque la ligne dans le fichier journal a la même valeur spid < n >. Par exemple, Voici un échec de la récupération suite à une erreur de total de contrôle lors de la tentative de lecture d’un bloc de journal pour restaurer par progression une transaction :

31-03-2010 17:33:13.00 spid15s erreur : 824, gravité : 24, état : 31-03-4.2010 17:33:13.00 spid15s SQL Server a détecté une erreur d’e/s basée sur la cohérence logique : (somme de contrôle incorrecte). Il s’est produit lors de la lecture de la page (0 : -1) dans la base de données ID 13 au décalage 0x0000000000b800 dans le fichier ' C:\Program Files\Microsoft SQL Server\MSSQL10. SQL2008\MSSQL\DATA\mydb_log. LDF ».  Des messages supplémentaires dans le journal d’événements SQL Server erreur système ou le journal peuvent fournir plus de détails. Il s’agit d’une condition d’erreur sévère qui menace l’intégrité de la base de données et doit être corrigée immédiatement. Effectuer une vérification de cohérence de base de données complète (DBCC CHECKDB). Cette erreur peut être provoquée par de nombreux facteurs ; Pour plus d’informations, consultez SQL Server Books Online.2010-03-31 17:33:13.16 spid15s erreur : 3414, gravité : 21, état : 1.2010-03-31 spid15s 17:33:13.16 une erreur s’est produite lors de la récupération, empêchant le redémarrage de la base de données 'mydb » (13 de l’ID de base de données). Diagnostiquer les erreurs de récupération et corrigez-les ou restaurer à partir d’une sauvegarde correcte. Si les erreurs ne sont pas corrigées ou prévus, contactez le Support technique

Il existe un large éventail d’erreurs qui pourraient provoquer l’échec de la restauration de base de données. Alors que vous devez évaluer chaque erreur dans un cas par cas, la résolution d’un échec de la récupération de base de données est généralement identique à celle décrite dans la section de résolution ci-dessous.

Résolution


Le message d’erreur indique à « diagnostiquer des erreurs de récupération et corrigez-les ou restaurer à partir d’une sauvegarde correcte ». En réalité, la restauration à partir d’une sauvegarde est votre option tout d’abord, la meilleure pour résoudre ce problème. Toutefois, si vous ne pouvez pas le récupérer à partir d’une sauvegarde, vous avez deux options :

  • Utilisez la méthode de réparation d’urgence fournie par DBCC CHECKDB
  • Essayez de copier autant que possible à une autre base de données

La première méthode est probablement la meilleure solution pour obtenir la base de données en ligne et accessibles. Toutefois, vous devez savoir que la cohérence transactionnelle ne peut être garantie car la récupération a échoué. Il n’y a aucun moyen de savoir ce qui doivent avoir été restaurées ou annulée avant transactions mais n’étaient pas autorisées en raison de l’échec de la récupération. Les étapes pour procéder à la réparation d’urgence sont décrites dans la section intitulée Résolution des erreurs de base de données en Mode d’urgence dans la documentation en ligne de SQL Server sous la commande DBCC CHECKDB .

Si cette méthode ne fonctionne pas et que vous souhaitez tenter de copier des données vers une autre base de données, le seul moyen d’obtenir l’accès à la base de données doit tout d’abord mettre la base de données en mode d’urgence à l’aide de la commande ALTER DATABASE < dbname > commande définir d’urgence.

Informations supplémentaires


Pas de toutes les erreurs rencontrées lors de la récupération de la base de données provoque un échec de la récupération et une base de données suspecte :

Si des erreurs sont rencontrées lors de l’ouverture de tout d’abord les fichiers de journaux de base de données et des transactions ce qui se produit avant la récupération et provoquera des erreurs telles que Msg 17204 et 17207. Une fois que ces erreurs sont corrigées récupération peut être autorisée à poursuivre (mais pas garantie pour terminer le cas d’autres erreurs de récupération). Erreurs de 17204 et 17207 n’aboutissent pas à une base de données suspecte. En fait, l’état de la base de données est RECOVERY_PENDING lorsque ces problèmes se produisent. Pour plus d’informations sur la résolution de l’erreur 17204 ou 17207, consultez l’article suivant : Comment faire pour résoudre l’erreur 17204 et 17207 dans SQL Server.

SQL Server 2005 a introduit un nouveau concept pour permettre la récupération effectuer la même lorsqu’une erreur de niveau page est rencontrée tout en conservant la cohérence transactionnelle. Cela a réduit le nombre de scénarios qui résulte dans une base de données suspecte. Ce concept est généralement appelé transactions différées.

Si l’erreur s’est produite lors de la restauration est un problème avec une page de base de données comme une erreur de total de contrôle ou un Msg 824, récupération peut-être avoir terminé avec des erreurs en attente. Dans le cas où une transaction est non validée, une situation appelée une transaction différée permettant la restauration peut entraîner une erreur sur une page comme la somme de contrôle.  Pour en savoir plus sur les transactions différées et de les résoudre, consultez la section intitulée les Transactions reportées dans la documentation en ligne de SQL Server.

Les entrées du journal d’erreurs suivantes montre un exemple d’un Msg 824 erreur lors de la récupération mais la récupération a été autorisée à effectuer une transaction différée. Notez l’absence d’erreur 3414 dans cette situation, le message que la récupération est terminée pour la base de données :

2010-03-31 19:17:18.45 spid7s erreur : 824, gravité : 24, état : 2.2010-03-31 19:17:18.45 spid7s SQL Server a détecté une erreur d’e/s basée sur la cohérence logique : total de contrôle incorrect (attendu : 0xb2c87a0a ; réel : 0xb6c0a5e2). Il s’est produite lors de la lecture de la page (1:153) dans la base de données ID 13 au décalage 0x00000000132000 dans le fichier ' C:\Program Files\Microsoft SQL Server\MSSQL10. SQL2008\MSSQL\DATA\mydb.mdf'.  Des messages supplémentaires dans le journal d’événements SQL Server erreur système ou le journal peuvent fournir plus de détails. Il s’agit d’une condition d’erreur sévère qui menace l’intégrité de la base de données et doit être corrigée immédiatement. Effectuer une vérification de cohérence de base de données complète (DBCC CHECKDB). Cette erreur peut être provoquée par de nombreux facteurs ; Pour plus d’informations, consultez SQL Server Books Online.2010-03-31 19:17:18.45 spid7s erreur : 3314, gravité : 21, état : 1.2010-03-31 spid7s de 19:17:18.45 lors de l’annulation d’une opération journalisée dans la base de données 'mydb », une erreur est survenue au niveau de l’enregistrement de journal ID (25:100:19). En général, l’erreur spécifique est enregistré précédemment sous la forme d’une erreur dans le service journal des événements Windows. Restaurer la base de données ou un fichier à partir d’une sauvegarde ou réparer le spid7s 31-03-database.2010 19:17:18.45 erreur s’est produite lors de la récupération lors de la restauration d’une transaction. La transaction a été différée. Restaurer le fichier ou la page défectueuse et ré-exécuter la récupération.spid7s de 19:17:18.45 2010-03-31, la récupération est terminée pour la base de données mydb (13 de l’ID de base de données) dans la seconde (s) 2 (analyse ms 204, rétablir 25 ms, annulation 1832 Mme) il s’agit d’un message d’information uniquement. Aucune action utilisateur n’est requise.

Dans le cas d’une transaction validée doit être reprise, la page peut être signalée comme inaccessible (les futures tentatives d’accès au résultat de la page dans Msg 829) et de récupération peut être autorisée à effectuer. Dans ce cas, l’erreur doit être corrigée par la restauration à partir d’une sauvegarde de la page ou la désaffectation de la page à l’aide de DBCC CHECKDB avec réparation.

Remarque : Les transactions différées est une fonctionnalité avancée de SQL Server d’uniquement disponible dans l’édition entreprise et a certaines limitations en matière de :

  • La base de données doit utiliser le modèle de récupération complète ou JOURNALISÉE en bloc.
  • Au moins une base de données et la sauvegarde du journal doit avoir été effectué pour la base de données
  • Cela ne s’applique pas aux erreurs rencontrées pendant le rollback d’une transaction, une fois la base de données est en ligne. (par exemple, une erreur d’exécution )
  • Ne fonctionne pas pour joindre des échecs de récupération au cours d’une base de données
  • Certaines transactions, comme les transactions du système (par exemple allocation de page) ne sont pas pris en charge pour le différé