Discussion :

[Kropernic]

Hello à tous,

J’ai fait une boulette avec une query UPDATE et je voudrais restaurer la DB (j'ai oublié la clause WHERE ). En soi, rien de sorcier.

Sauf que SSMS me dit qu’il ne peut pas car le DB est utilisée (« in use » qu’il dit en anglais).

Je me suis dit : « Ok, je mets la DB offline et je pourrais faire mon restore puisqu’elle ne pourra plus être utilisée par personne »

Je clique donc sur « Take Offline » dans sous menu Tasks (qui apparaît quand on fait un clic droit sur la db dans SSMS) et le petit pop-up apparaît. Mais il ne disparaît jamais et est toujours en traitement. Même si je le ferme, derrière ça tourne toujours je pense. Mais ma DB n’est toujours pas offline (ou alors ce n'est pas indiqué).

Ensuite, je vais voir dans kankuru (programme fourni gratuitement par darkelend) et là, en cliquant droit sur la DB, on peut faire « alter status --> set single user rollback immediate ». Ce qui me convient bien vu qu’en fait, y a jamais que des select qui sont fait par les users sur cette DB. Mais je reçois un message d’erreur (sûrement à cause du take offline qui est en cours).

Bref, je cherche comment démêler ce bordel pour que je puisse faire mon restore (j'aimerais autant éviter de redémarrer le server )

Merci d'avance.

[Kropernic]

Finalement, via l'activity monitor de SSMS, j'ai vu que le compte sa était connecté sur la DB.
J'ai kill le process.
Du coup, la DB s'est mise offline.
Là j'ai constasté que je ne pouvais pas faire de restore sur un db offline.
Je l'ai remise online.
J'ai restoré jusqu'au point de sauvegarde le plus récent (je sauvegarde les logs toutes les heures).
Et voilà, tout est bien qui finit bien.

Bon, j'ai fait ça un peu dans l'urgence... J'avais déjà restauré plusieurs fois des DB mais toujours vers des serveurs de tests donc pas de problème d'utilisation.

Quelle est la bonne pratique pour restaurer une DB en cours d'utilisation ?

[bvesan]

Bonjour,
L'une des bonnes pratiques est effectivement de systématiser le "ALTER DATABASE <BASE> SET OFFLINE WITH ROLLBACK IMMEDIATE" qui terminera nécessairement toutes les transactions sur la base. Mais bien entendu, puisque les transactions en cours sont annulées, il est possible que la commande mette du temps à s'exécuter (de longues minutes en cas de transactions ouvertes depuis très longtemps)...

[Kropernic]

Bonjour,
L'une des bonnes pratiques est effectivement de systématiser le "ALTER DATABASE <BASE> SET OFFLINE WITH ROLLBACK IMMEDIATE" qui terminera nécessairement toutes les transactions sur la base. Mais bien entendu, puisque les transactions en cours sont annulées, il est possible que la commande mette du temps à s'exécuter (de longues minutes en cas de transactions ouvertes depuis très longtemps)...

Ce ne serait pas plutôt SET SINGLE USER ?

Détail en plus, la DB était en mirroring. Ici, pour pas chipoter, vu qu'il me racontait des histoires que je ne comprenais pas avec des "taillog", j'ai coupé le mirroring le temps de faire le restore.
Comment sans couper le mirroring ? (et là, je galère pour le remettre XD)

[bvesan]

Ce ne serait pas plutôt SET SINGLE USER ?

Le problème du SINGLE_USER, c'est qu'il suffit qu'une autre connexion (un automate par exemple) s'établisse entre le ALTER DATABASE et le RESTORE DATABASE pour que la restaution échoue.
Avec SET OFFLINE, on est sûr qu'aucun accès ne pourra être fait à la base !

Détail en plus, la DB était en mirroring. Ici, pour pas chipoter, vu qu'il me racontait des histoires que je ne comprenais pas avec des "taillog", j'ai coupé le mirroring le temps de faire le restore.
Comment sans couper le mirroring ? (et là, je galère pour le remettre XD)

Le message qui parle d'effectuer une sauvegarde de type Tail-Log (BACKUP LOG WITH NORECOVERY) est valable lorsque l'on tente de restaurer une base qui est dans le mode de recouvrement Complet. Pour forcer la restauration d'une base en mode Complet, il faut utiliser l'option REPLACE de l'ordre RESTORE DATABASE. La encore, si la base est hors ligne, cette question ne se pose pas.

Bien entendu, le fait de restaurer la base primaire d'une configuration miroir va nécessairement casser le miroir (puisque les pages de données de la base primaire seront remplacées, et le miroir travaille en ne synchronisant que les pages des journaux de transactions). Il faudra donc recréer le miroir depuis le début...