Un fichier journal de transactions corrompu ou manquant est l’une des situations les plus stressantes qu’un DBA puisse rencontrer. Le premier réflexe est de restaurer depuis la dernière sauvegarde complète — mais selon les circonstances, SQL Server offre des chemins de récupération plus rapides qui minimisent à la fois les temps d’arrêt et la perte de données. Cet article présente les deux scénarios principaux et la procédure pour chacun.

Avertissement : ces procédures impliquent de contourner les mécanismes de récupération normaux. Validez toujours la cohérence des données au niveau applicatif après avoir terminé la récupération, et effectuez une sauvegarde complète dès que la base de données est accessible.

Conditions de départ possibles

• Fichier journal corrompu (défaillance matérielle, erreur de stockage)
• Fichier journal corrompu pendant une transaction longue
• Volume du fichier journal perdu ou démonté pendant que des transactions étaient en cours

Scénario 1 : aucune transaction n’était en cours au moment du crash

Si la base de données était inactive quand le fichier journal a été perdu ou corrompu, SQL Server peut reconstruire automatiquement le fichier journal au démarrage. C’est le chemin de récupération le plus propre.

1. Détacher la base de données : sp_detach_db
2. Renommer le fichier journal corrompu en *.OLD (ne pas le supprimer encore)
3. Rattacher avec FOR ATTACH_REBUILD_LOG

-- SQL Server reconstruira le fichier journal au chemin d'origine
CREATE DATABASE [MABASE] ON
    (FILENAME = N'D:SQLDataDatabase.mdf')
FOR ATTACH_REBUILD_LOG
GO

Scénario 2 : des transactions étaient en cours au moment du crash

ATTACH_REBUILD_LOG n’est pas autorisé quand SQL Server détecte des transactions non validées dans le MDF. Dans ce cas, vous devez utiliser la procédure d’urgence :

-- Mettre la base en mode urgence
ALTER DATABASE [MABASE] SET EMERGENCY
GO

-- Vérifier la cohérence (ignorera les erreurs de journal)
DBCC CHECKDB([MABASE]) WITH NO_INFOMSGS, ALL_ERRORMSGS
GO

-- Passer en mode utilisateur unique et réparer
ALTER DATABASE [MABASE] SET SINGLE_USER
GO
DBCC CHECKDB([MABASE], REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS
GO

-- Remettre en ligne
ALTER DATABASE [MABASE] SET ONLINE
GO
ALTER DATABASE [MABASE] SET MULTI_USER
GO

Note : REPAIR_ALLOW_DATA_LOSS peut entraîner une perte de données. Utilisez cette option uniquement si vous n’avez pas d’autre alternative et que vous avez évalué l’impact.