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.