Rétablir Online un fichier d’un FileGroup OffLine (par erreur) – Utilisation d’une connexion DAC

Petit mémo de survie si un jour un des fichiers composant un FileGroup de votre base de données la plus critique se retrouve Offline par erreur.

CECI N’EST PAS UN BEST PRACTICE MAIS PLUTOT UN SURVIVAL TRICK

Petit rappel important, théoriquement un fichier est passé manuellement au statut OffLine parce qu’il est inutilisable. Le fichier est alors écarté du FileGroup de manière à permettre de restaurer la base de données Online privée du fichier fautif. La seule opération possible sur le fichier est alors la suppression.
Mettons-nous dans le cas en déclarant explicitement Offline le fichier TestFG d’une base de données Demo, ce qu’il est possible de faire avec un simple ALTER TABLE :

ALTER DATABASE Demo
MODIFY File (NAME= TestFG, OFFLINE)


Evidemment, il n’existe pas d’opération me permettant de faire marche arrière, « ONLINE » n’étant pas un argument valide pour l’opération MODIFY File. Mon Filegroup est désormais considéré comme Offline et accessoirement ma base comme suspecte. L’opération attendue ici est en fait la restauration d’un backup de ce fichier pour permettre son retour Online.
Maintenant, si l’état de ce fichier est erroné (fausse manipulation par exemple) et que vous n’avez pas de backup voici une solution qui permet de tomber en marche.
4 Etapes pour vous sortir de l’embarras :

Etape 1 : Passer l’instance en single user
Arrêter l’instance SQL Server hébergeant la base de données
Redémarrer l’instance avec la commande suivant (exécutée dans le sous-répertoire BInn de l’installation de SQL Server) :

SQLServer –s InstanceName -m

Etape 2 : Etablir une connexion D.A.C. (Dedicated Administrator Connection)
Dans SSMS (ou via SQLCMD), créer une nouvelle requête en établissant une connexion au serveur dont vous précéder le nom par « ADMIN: »
Connexion DAC - localhost

Etape 3 : Modifier le statut du fichier dans les tables système
Les tables systèmes sont désormais accessibles.
Pour connaitre les tables contenant les informations concrètes liées à nos FileGroup, une astuce est d’activer le plan d’exécution et d’interroger les vues catalog.
En l’occurrence, pour les fichiers participant aux FileGroup, il s’agit de la table sys.sysbrickFiles

select * from sys.sysbrickfiles

update sys.sysbrickfiles
set internalstatus = 0
where lname = 'TestFG'

La première requête permet de vérifier le nom et l’état logique du fichier, la seconde de modifier son état pour rétablir un état ONLINE.

Etape 4 : Vérifier l’état de la base de données
Relancer l’instance en mode classique via le SQL Server Configuration Manager et contrôler le retour du FileGroup perdu.
Un DBCC CheckDb peut être nécessaire pour repasser la base en mode normal.