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 plutôt exécuter REPAIR_ALLOW_DATA_LOSS?

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 toutes les données à nouveau.

Mise à jour

Pour ceux qui gardent le score: la ALTER DATABASE/REBUILD LOGcommande s'est terminée après environ 36 heures et a rapporté:

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 ...).

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 DATABASEavec FOR ATTACH_REBUILD_LOGoption?

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 la 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 CHECKDBvous reconstruisez le journal et vérifiez également la base de données pour les erreurs d'intégrité.

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 se bloque 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écuter 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 d'éventuelles incohérences. 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 une suite DBCC CHECKDBpour corriger les erreurs.

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 pourrez peut- être être opérationnel en attachant la base de données et en reconstruisant le journal en utilisant:

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 de Paul S. Randal :

Réparation en mode URGENCE: le tout dernier recours