web-dev-qa-db-fra.com

Reconstruction du journal des transactions

Nous avons une très grande base de données (~ 6 To), dont le fichier journal des transactions a été supprimé (alors que SQL Server était fermé. Nous avons essayé:

  1. Détacher et rattacher la base de données; et
  2. Annulation de la suppression du fichier journal des transactions

... mais rien n'a fonctionné jusqu'à présent.

Nous gérons actuellement:

ALTER DATABASE <dbname> REBUILD 
LOG ON (NAME=<dbname>,FILENAME='<logfilepath>')

... mais étant donné la taille de la base de données, cela prendra probablement quelques jours.

Des questions

  • Y a-t-il une différence entre la commande ci-dessus et la suivante?

    DBCC CHECKDB ('<dbname>', REPAIR_ALLOW_DATA_LOSS)

  • Devrions-nous exécuter REPAIR_ALLOW_DATA_LOSS au lieu?

Il convient de noter que les données sont dérivées d'autres sources afin que la base de données puisse être reconstruite, mais nous pensons qu'il sera beaucoup plus rapide de réparer la base de données que de réinsérer à nouveau toutes les données.

Mise à jour

Pour ceux qui gardent un score: le ALTER DATABASE/REBUILD LOG commande terminée après environ 36 heures et signalant:

Avertissement: le journal de la base de données 'dbname' a été reconstruit. La cohérence transactionnelle a été perdue. La chaîne RESTORE a été rompue et le serveur n'a plus de contexte sur les fichiers journaux précédents, vous devrez donc savoir de quoi il s'agit.
Vous devez exécuter DBCC CHECKDB pour valider la cohérence physique. La base de données a été mise en mode dbo uniquement. Lorsque vous êtes prêt à rendre la base de données disponible pour utilisation, vous devrez réinitialiser les options de base de données et supprimer tous les fichiers journaux supplémentaires.

Nous avons ensuite exécuté un DBCC CHECKDB (a pris environ 13 heures) qui a réussi. Disons simplement que nous avons tous appris l'importance des sauvegardes de bases de données (et de l'accès des chefs de projet au serveur ...).

sql-serversql-server-2005recoverydbcc-checkdb
20
Fuzzy Purple Monkey

Ne détachez jamais une base de données Suspect. Quoi qu'il en soit, comment avez-vous attaché la base de données après l'avoir détachée? Vous avez utilisé CREATE DATABASE Avec l'option FOR ATTACH_REBUILD_LOG?

Ces commandes auraient dû faire l'affaire:

ALTER DATABASE recovery_test_2 SET EMERGENCY;   
ALTER DATABASE recovery_test_2 SET SINGLE_USER;  

DBCC CHECKDB (recovery_test_2, REPAIR_ALLOW_DATA_LOSS) 
WITH NO_INFOMSGS, ALL_ERRORMSGS;

J'ai écrit un post pour cette situation:

Procédure de récupération de base de données SQL 2005/2008 - Fichier journal supprimé (partie 3)

Vous avez demandé la différence entre:

  • DBCC CHECKDB ('<dbname>', REPAIR_ALLOW_DATA_LOSS) et
  • ALTER DATABASE <dbname> REBUILD LOG ON (NAME=<dbname>,FILENAME='<logfilepath>')

Le fait est que vous pouvez exécuter les deux pour reconstruire le fichier journal, mais avec CHECKDB vous reconstruisez le journal et recherchez également les erreurs d'intégrité dans la base de données.

De plus, la seconde (modifier la base de données) ne fonctionnera pas s'il y avait des transactions actives (non écrites sur le disque) lorsque le fichier journal a été perdu. Au démarrage ou à l'attachement, SQL Server voudra effectuer une récupération (restauration et restauration) à partir du fichier journal qui n'est pas là. Cela se produit lorsqu'un disque tombe en panne ou qu'un arrêt inattendu du serveur se produit et que la base de données n'est pas correctement arrêtée. Je suppose que ce n'était pas votre cas et tout s'est bien passé pour vous.

  1. DBCC CHECKDB (DBNAME, REPAIR_ALLOW_DATA_LOSS) exécuté sur une base de données en état d'urgence vérifie la base de données pour les erreurs d'incohérence, essaie d'abord d'utiliser le fichier journal pour récupérer de toute incohérence. Si cela manque, le journal des transactions est reconstruit.

  2. ALTER DATABASE REBUILD LOG ON... Est une procédure non documentée et nécessite un DBCC CHECKDB Pour corriger les erreurs.

20
yrushka

Oui, ce sont deux déclarations différentes, chacune faisant des choses très différentes.

En fonction de l'état de la base de données lorsque le fichier a été supprimé, vous pouvez être opérationnel en attachant la base de données et en reconstruisant le journal à l'aide de :

EXEC sp_attach_single_file_db 'dbname here', 'file path and name here'

Voir sp_attach_single_file_db (Transact-SQL) dans la documentation du produit.

Voir également cet article de blog par Paul S. Randal :

Réparation en mode URGENCE: le tout dernier recours

12
SQLRockstar