 
          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 -Eexec 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 MSSQLSERVERLe 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.mdfLe journal de transactions TEST.ldf nouvellement créé pour la base TEST est
            supprimé
DOS> rename TEST.ldf TEST.ldf.savLe service MSSQLSERVER est redémarré
DOS> net start MSSQLSERVERAu 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 -Ealter database [dbname] set emergency go
DOS> osql -Ealter 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') go2009-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
goalter database TEST set multi_user go2009-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.