Comment réparer les erreurs de cohérence de la base de données
J'ai une base de données Microsoft Dynamics AX SQL Server. Je viens de courir DBCC CHECKDB afin de vérifier l'intégrité. Après quelques minutes, j'ai obtenu à la fin des résultats ce qui suit:
CHECKDB a trouvé 0 erreur d'allocation et 4 erreurs de cohérence dans la base de données 'AXPROD'. repair_rebuild est le niveau de réparation minimum pour les erreurs trouvées par DBCC CHECKDB (AXPROD). L'exécution de DBCC est terminée. Si DBCC a imprimé des messages d'erreur, contactez votre administrateur système.
Étant donné que j'ai eu 4 erreurs de cohérence, je voudrais savoir s'il existe un moyen de résoudre ce problème ou d'obtenir des informations plus détaillées sur ces erreurs.
Je voudrais savoir s'il existe un moyen de résoudre ce problème
Ces erreurs de cohérence peuvent être corrigées avec le REPAIR_REBUILD option de DBCC CHECKDB :
Effectue des réparations qui n'ont aucune possibilité de perte de données. Cela peut inclure des réparations rapides, telles que la réparation des lignes manquantes dans les index non groupés, et des réparations plus longues, telles que la reconstruction d'un index.
Comme le mentionne la réponse de Shanky, toute réparation DBCC doit également être effectuée à l'intérieur d'une transaction, afin que vous puissiez inspecter les modifications avant de vous y engager.
Comme toujours, veuillez vous assurer d'avoir un ensemble de sauvegardes complètement récupérable (y compris le log tail le cas échéant) avant d'exécuter la reconstruction. Si vous disposez d'un ensemble complet de sauvegardes valides (y compris la queue du journal, le cas échéant) et que vous pouvez vous permettre le temps d'arrêt, la restauration peut être l'option préférée. Assurez-vous de ne pas écraser la base de données actuelle si vous procédez ainsi, juste au cas où la restauration échouerait ou si elle n'est pas aussi complète que prévu. Bien sûr, il est fort probable que la base de données restaurée contienne à nouveau la corruption, selon la manière et le moment où cela s'est produit :)
ou un moyen d'obtenir des informations plus détaillées sur ces erreurs
Les détails des quatre erreurs de cohérence se trouvent dans le DBCC CHECKDB sortie, avant la section récapitulative à la fin. Vous devez les consulter pour vous assurer de bien comprendre le problème et ce qui peut l'avoir causé avant de tenter toute réparation.
Vous pouvez réduire la quantité de DBCC CHECKDB sortie en utilisant le WITH NO_INFOMSGS option.
Ajoutez les détails du message d'erreur DBCC à votre question si vous avez besoin d'aide pour analyser les erreurs. Il est important d'identifier et de corriger tout problème matériel sous-jacent qui pourrait avoir causé la corruption.
Selon les détails de la corruption, il peut y avoir d'autres façons de résoudre les problèmes (comme la reconstruction manuelle d'un index non cluster).
Si la réparation ou la reconstruction réussit, vous devrez vérifier à nouveau la base de données avec DBCC CHECKDB avec l'ensemble de vérifications le plus complet pris en charge par votre version de SQL Server.
Pour votre question, je suppose que le point important de la restauration à partir d'une sauvegarde valide connue est manqué, j'ajouterais donc ce point également.
Bien que REPAIR_REBUILD soit suggéré comme niveau minimum de réparation et puisse fonctionner dans votre cas, vous devez savoir que lorsque vous exécutez repair_rebuild, il n'est pas garanti de résoudre votre problème et de supprimer la corruption. Si cela se produit, la restauration à partir d'une sauvegarde serait une bonne option. Vous pouvez utiliser repair_rebuild dans une transaction et voir les modifications si vous êtes Ok avec elle, validez-le sinon, restaurez ce qui suit Article BOL dit
Étant donné que DBCC CHECKDB avec l'une des options de RÉPARATION est complètement enregistré et récupérable, Microsoft recommande toujours à un utilisateur d'utiliser CHECKDB avec toutes les options de RÉPARATION dans une transaction (exécutez BEGIN TRANSACTION avant d'exécuter la commande) afin que l'utilisateur puisse confirmer qu'il souhaite accepter les résultats de l'opération. L'utilisateur peut ensuite exécuter COMMIT TRANSACTION pour valider tout le travail effectué par l'opération de réparation. Si l'utilisateur ne souhaite pas accepter les résultats de l'opération, il peut exécuter une ROLLBACK TRANSACTION pour annuler les effets des opérations de réparation.
Pour réparer les erreurs, nous vous recommandons de restaurer à partir d'une sauvegarde. Les opérations de réparation ne prennent en compte aucune des contraintes pouvant exister sur ou entre les tables. Si la table spécifiée est impliquée dans une ou plusieurs contraintes, nous vous recommandons d'exécuter DBCC CHECKCONSTRAINTS après une opération de réparation. Si vous devez utiliser REPAIR, exécutez DBCC CHECKDB sans option de réparation pour trouver le niveau de réparation à utiliser. Si vous utilisez le niveau REPAIR_ALLOW_DATA_LOSS, nous vous recommandons de sauvegarder la base de données avant d'exécuter DBCC CHECKDB avec cette option.
Donc, s'il existe une telle contrainte, vous pourriez aussi bien envisager l'idée de restaurer à partir d'une sauvegarde valide. Avant cela, vous devez exécuter restaurer vérifier uniquement pour la sauvegarde que vous essayez de restaurer pour vérifier si la sauvegarde est cohérente. Vous devez également noter que seule une restauration réussie peut garantir la cohérence de la sauvegarde dans [~ # ~] tous les formats [~ # ~]
Enfin, vous devez vérifier les journaux d'erreurs de SQL Server et le visualiseur d'événements Windows pour découvrir la raison pour laquelle l'incohérence est apparue en premier lieu. Beaucoup de mauvais matériel en sont la cause.