SQL Server 2005 - Reconstruction d’une base à partir d’un simple fichier mdf (rebuild log)

Logo

Introduction

Un éditeur vient un jour sur site livrer une base non par son backup mais directement avec le fichier de données mdf. Le hic : l’éditeur a oublié le journal de transactions qui accompagne le fichier de données. Le journal des transactions étant manquant, l’utilisation de la commande sp_attach_db est impossible. Cette pratique est de plus en plus courante avec les éditeurs travaillant autour de Microsoft SQL Server.

Cette note détaille la méthode pour monter la base dans ce contexte, méthode qui consiste à reconstruire un journal de transactions avec l’option rebuild log de la commande ALTER DATABASE.

Dans les exemples ci-dessous, l’instance s’appelle MSSQLSERVER et il ne s’agit pas d’une instance nommée, la base à remonter s’appelle TEST, les fichiers de data et log sont sur d:\MSSQL\data.

Étapes

Permissions sur les tables systèmes

DOS> osql -E

exec sp_configure 'allow updates',1
go
reconfigure with override
go

Création de la base TEST

Une base de données ayant le même nom que la base de données à monter est créée.

create database TEST
on primary (name='TEST_data', filename='D:\MSSQL\Data\TEST.mdf')
log on (name='TEST_log', filename='D:\MSSQL\Data\TEST.ldf')

Mise en place du fichier de données mdf fourni par l’éditeur

Le service MSSQLSERVER est arrêté.

DOS> net stop MSSQLSERVER

Le fichier de données TEST.mdf nouvellement créé pour la base TEST est remplacé par le fichier fourni par l’éditeur

DOS> d:
DOS> cd d:\MSSQL\data
DOS> rename TEST.mdf TEST.mdf.sav
DOS> rename mon_fichier_TEST.mdf TEST.mdf

Le journal de transactions TEST.ldf nouvellement créé pour la base TEST est supprimé

DOS> rename TEST.ldf TEST.ldf.sav

Le service MSSQLSERVER est redémarré

DOS> net start MSSQLSERVER

Au démarrage de l’instance, le système va tenter de monter la base TEST précédemment - correctement - créée. L’absence de journal de transactions va causer une erreur ( et permettre de manipuler la base ). Les erreurs 17207 et 5123 sont remontées dans le fichier de log de l’instance MS SQL Server :

2009-06-03 16:49:42.68 spid15s     Error: 17207, Severity: 16, State: 1.
2009-06-03 16:49:42.68 spid15s     FileMgr::StartLogFiles: Operating system error 2(error not found) occurred 
while creating or opening file 'D:\MSSQL\Data\TEST.ldf'. 
Diagnose and correct the operating system error, and retry the operation.
2009-06-03 16:49:42.70 spid15s     File activation failure. The physical file name "D:\MSSQL\Data\TEST.ldf" may be incorrect.
2009-06-03 16:49:42.70 spid15s     Error: 5123, Severity: 16, State: 1.
2009-06-03 16:49:42.70 spid15s     CREATE FILE encountered operating system error 3(error not found) 
while attempting to open or create the physical file 'D:\MSSQL\Data\TEST_log.LDF'.
2009-06-03 16:49:42.71 spid15s     Error: 5123, Severity: 16, State: 1.
2009-06-03 16:49:42.71 spid15s     CREATE FILE encountered operating system error 3(error not found) 
while attempting to open or create the physical file 'D:\MSSQL\Data\TEST_log.LDF'.

Reconstruction du journal

Pour reconstruire le journal, la base TEST est d’abord mise en mode emergency avec la commande ALTER DATABASE SET EMERGENCY :

DOS> osql -E

alter database [dbname] set emergency
go
DOS> osql -E

alter database TEST set emergency
go
2009-06-03 16:52:00.25 spid51      The database 'TEST' is marked EMERGENCY_MODE and is in a state 
that does not allow recovery to be run. 
2009-06-03 16:52:00.26 spid51      Starting up database 'TEST'.

L’option rebuild log de la commande ALTER DATABASE est ensuite lancée pour reconstuire le journal :

alter database TEST rebuild log
on (name=TEST_log,filename='D:\MSSQL\data\TEST.ldf')
go
          2009-06-03 16:52:00.31 spid51      Warning: The log for database 'TEST' has been rebuilt. 
Transactional consistency has been lost. 
The RESTORE chain was broken, and the server no longer has context on the previous log files, 
so you will need to know what they were. 
You should run DBCC CHECKDB to validate physical consistency. 
The database has been put in dbo-only mode. 
When you are ready to make the database available for use, 
you will need to reset database options and delete any extra log files. 

La commande rebuild log positionne la base de données en mode 'dbo-only' : seul le propriétaire dbo de la base de données peut y accéder. L’option multi_user est donc appliquée ensuite avec la commande ALTER DATABASE SET MULTI_USER.

alter database [dbname] set multi_user
go
alter database TEST set multi_user
go
          2009-06-03 16:52:00.33 spid51      Setting database option MULTI_USER to ON for database TEST.

Opérations post-reconstruction

Pour plus de sécurité, il est conseillé de lancer une commande dbcc checkdb à l’issue de la reconstruction du journal afin de vérifier l’intégrité de la base.

Il reste ensuite à positionner les options nécessaires sur la base de données : mode de restauration (FULL, SIMPLE, etc.), etc.

Et l’opération est terminée.