Restaurer WITH STANDBY

aimeriez restaurer la base
de données à  une heure aussi proche
que possible de celle de l’incident.

Dans une restauration classique,
comme je l’ai déjà  dit, vous pouvez
spécifier WITH RECOVERY pour annuler
des transactions incomplètes ou
spécifier WITH NORECOVERY. Avec
WITH RECOVERY, vous ne pouvez pas
restaurer les sauvegardes du journal
suivantes, mais la base de données est
entièrement utilisable. Avec WITH NORECOVERY,
la base de données pourrait
être incohérente, auquel cas SQL
Server vous empêchera de l’utiliser.

Et si l’on pouvait combiner les
deux méthodes en restaurant une sauvegarde
du journal, puis en examinant
les données avant de restaurer d’autres
sauvegardes du journal ? Cette combinaison
est intéressante si vous souhaitez
faire une reprise à  une certaine
heure, sans connaître l’heure exacte.

SQL Server propose une option appelée
STANDBY qui permet de récupérer
la base de données tout en restaurant
d’autres sauvegardes du journal.
Si vous restaurez une sauvegarde du
journal et indiquez

WITH STANDBY = '<un nom de fichier>'

L'opération RESTORE LOG suivante
lit le contenu du fichier undo, refait
les opérations qui ont été annulées,
puis restaure la sauvegarde du journal
indiquée dans la commande RESTORE
LOG. Si cette commande RESTORE
LOG indique aussi WITH STANDBY, la
restauration annule à  nouveau les transactions
incomplètes mais garde une
trace de ces transactions annulées.
Après chaque opération RESTORE
LOG … WITH STANDBY, les données
sont cohérentes parce qu'aucune transaction
effectuée à  moitié n'a été incluse
dans la base de données, et donc
les utilisateurs peuvent y accéder et lire
les données. Vous pouvez ainsi déterminer
après avoir restauré chaque
journal si un changement particulier a
déjà  eu lieu. (Sachez que vous ne pouvez
modifier aucune donnée si vous
avez restauré WITH STANDBY: si vous
essayez, vous obtenez un message
d'erreur de SQL Server. Mais vous pouvez
lire les données et continuer à  restaurer
d'autres journaux si vous le souhaitez.)
Vous devez restaurer le journal
final WITH RECOVERY (et SQL Server
ne gardera pas un fichier undo) pour
que la base de données soit entièrement
utilisable.

Vous pouvez utiliser l'option RESTORE
WITH STANDBY pour essayer de
connaître l'heure de l'incident, mais ce
n'est pas amusant. Quand, après avoir
restauré un journal, vous découvrez
qu'il contient l'opération indésirable,
vous devez essayer, dans cet intervalle
d'enregistrements du journal, de déterminer
le moment de l'incident.
Vous devez reculer jusqu'au début du
processus de restauration et utiliser
l'option STOPAT pour vous arrêter à 
un certain point au milieu du temps
qu'englobe la sauvegarde du journal. Si
vous examinez les données et constatez
qu'elles sont encore bonnes, vous
savez que le dommage est survenu ultérieurement
; si le dommage est déjà 
apparent, vous savez que le changement
s'est produit antérieurement au milieu de la sauvegarde du journal.
Vous répétez ensuite cette bisection,
en vous arrêtant un peu après ou un
peu avant dans le journal, à  chaque
fois. Cette opération fastidieuse vous
aide à  récupérer jusqu'à  une heure
précédant de peu l'incident et vous
pouvez ensuite minimiser la perte de
données.

Autre possibilité : utiliser Log
Explorer 2.5 de Lumigent Technologies,
qui peut montrer tous les enregistrements
du journal de transactions et
l'heure à  laquelle chaque transaction a
été initiée. Vous pouvez utiliser l'information
de date et d'heure de la transaction
pour déterminer le point à  indiquer
dans votre option STOPAT, ou
bien utiliser les fonctions de Log
Explorer pour inverser la transaction.
Mais faites attention à  n'utiliser Log
Explorer pour annuler un changement
que s'il n'y a pas d'autre moyen :
d'autres changements peuvent dépendre
de celui que vous essayez d'annuler.
Dans la mesure du possible, utilisez
Log Explorer pour des
informations uniquement, et recourez
à  la fonction restauration de SQL
Server pour ramener les bases de données
à  un état voulu.