MetaTips

Cet article, vous explique quels sont les mécanismes à mettre en œuvre, pour récupérer la main sur une base de donnée qui n'est plus joignable.

Type : Article / Tutorial

Niveau : 3/5

Durée de lecture : env. 1 heure

Compatibilité / s'applique à :

o    Microsoft SQL Seveur 2005 (9.0.XXXX)

o    Microsoft SQL Seveur 2008 (10.0.XXXX)  

Symptômes :

La base peut être dans plusieurs possible :

1. ONLINE

• If it's one of the data files that is damaged and the damage is hit during a query or some other operation then the database will remain online and accessible.

• The database will be in this state if SQL Server knows that recovery needs to be run on the database but something is preventing recovery from starting. This is different from SUSPECT because there's nothing to say that recovery is going to fail - it just hasn't started yet.
• An example of this is when the database wasn't cleanly shut down (i.e. there was at least one uncommitted transaction active at the time the database was shut down) and the log file has been deleted.

• The database will be in this state if the transaction log is damaged and it prevents recovery or a transaction rollback from completing.
• Some examples of this are:

• When the database wasn't cleanly shut down and recovery tries to read a corrupt data page or comes across a corrupt log record.
• A regular transaction rolls back and tries to read a corrupt data page or comes across a corrupt log record.

Pour connaitre l'état de votre base de donnée si vous n'avez pas management studio, vous pouvez effectuer une requete sur la vue sys.databases :

SELECT state_desc FROM sys.databases WHERE name = 'master';

GO

Ou à l'aide de la fonction DATABASEPROPERTYEX :

SELECT DATABASEPROPERTYEX ('master', 'STATUS');

GO

Si votre base est entrain de faire un rollback, ou de remonter son journal de transactions, pour se retrouver sur un état stable, vous pouvez tentez de vous en passer si les éléments qu'elle remonte ne vous sont pas utiles. Mais attention, cette opération pourrait vous couter la stabilité de votre base !

1. Arrêtez le service
2. Faites une copie de sauvegarde des fichiers mdf et ldf de la base
3. Renommez le fichier ldf en *.ldf.old
4. Redémarrez le service
5. Passez la base en mode emergency :

sp_configure 'allow updates', 1

reconfigure with override

alter database DatabaseName set emergency

1. Reconstruisez le fichier ldf :

alter database DatabaseName rebuild log on (name=logname_log,filename='c:\program files\microsoft sql server\mssql.1\mssql\data\logname.ldf')

Changez le chemin et le nom du fichier pour recréer le même fichier que précédemment

1. Repassez la base en multi_user :

alter database DatabaseName set multi_user

Avant d'effectuer cette ultime étape et remettre la base en production, il est fortement conseillé de vérifier le cohérence de la base, et ceci en single user, sinon le serveur va utiliser des snapshot masqués de la base (appelé '') et risquer de reproduire le problème de non accessibilité :

DBCC CHECKDB (DatabaseName)

Mots clés : Possible schema corruption. Run DBCC CHECKCATALOG