> Tech > Restaurer la base de données

Restaurer la base de données

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

Sauvegarder l'état courant de la base de données dans un fichier n'est que la moitié (ou moins) de l'opération de sauvegarde/restauration : une sauvegarde ne sert à  rien si l'on ne peut pas restaurer les données ultérieurement. Malheureusement, la restauration est un peu plus complexe. SQL Server exige qu'aucun utilisateur

ne soit
connecté à  la base de données pendant
l’opération de restauration. Dans
MSDE for SQL Server 7.0, vous devez
pratiquer les sauts que j’ai décrits ciaprès,
pour que le serveur s’arrête et
redémarre en mode mono-utilisateur.
Dans SQL Server 2000, il est beaucoup
plus facile de passer en mode monoutilisateur
: vous pouvez simplement
exécuter une commande ALTER DATABASE
pour changer l’état de la base de
données. La commande LATER DATABASE
du renvoi I, que m’a montrée ma
collègue Kimberly Tripp-Simmonet,
termine toutes les transactions (ou les
annule rétroactivement) et déconnecte
tous les utilisateurs de la base de
données. Cette commande ordonne
au serveur d’arrêter net son traitement,
de stopper d’éventuelles transactions
en suspens, et d’annuler rétroactivement
les opérations si elles ne
se finissent pas dans un délai de 10 secondes.
Pour exécuter cette commande
T-SQL, vous devez avoir des autorisations
sa ou db-creator, ou vous
connecter en tant que membre du rôle
des opérateurs de sauvegarde.

Vous ne devez arrêter un serveur
de production actif que si vous êtes
certain que c’est un SGBD mono-utilisateur.
Si votre MSDE fonctionne en
mode multi-utilisateur, veillez à  déconnecter
tous les utilisateurs avant d’entamer
les opérations de maintenance.

Si votre MSDE est fondé sur SQL
Server 7.0, il faut basculer le serveur en
mode mono-utilisateur. J’ai essayé plusieurs
procédés pour effectuer ce basculement,
mais ils ne donnent pas toujours
des résultats homogènes. Bien
que vous puissiez fermer toutes les
connexions ADO (y compris
Enterprise Manager, Query Analyzer, et
autres outils), le pool de session OLE
DB garde les connexions ouvertes pendant
une minute ou plus après que
vous les ayez « fermées ». Pour
contourner ce problème, j’ai fait fermer
le serveur à  SQL-DMO, attendre quelques secondes, puis le redémarrer.
Si vous essayez de redémarrer SQL
Server trop tôt après l’avoir arrêté, il
donne l’impression de « caler ».

Après l’arrêt du serveur et une attente
de quelques secondes, vous pouvez
tenter un redémarrage. Là  encore,
vous devrez peut-être ajuster le timing
pour votre système cible. Pour exécuter
la commande RESTORE, vous devrez
vous connecter comme sa, dbcreator,
ou comme un membre du rôle
des opérateurs de sauvegarde. Après le
redémarrage, laissez quelques secondes
au serveur pour qu’il atteigne
sa vitesse de croisière. La routine du
renvoi J redémarre, attend, puis exécute
la requête RestoreDatabase. Le
gestionnaire d’erreurs du renvoi K est
prêt à  intercepter des erreurs Server
not found, puis à  attendre quelques secondes
de plus et à  réessayer.

Ensuite, le code du renvoi L met
SingleUser DBOption de la base de
données active à  True, pour empêcher
d’autres connexions d’interférer avec
l’opération de restauration. Ce réglage
est obligatoire pour la commande RESTORE
de SQL Server 7.0. Votre serveur
étant en mode mono-utilisateur, vous
pouvez exécuter la commande RESTORE
DATABASE. Dans ce cas, utilisez
l a méthode SQL-DMO Server.
ExecuteImmediate, qui exécute simplement
la requête d’action montrée
par le renvoi M – la commande T-SQL
RESTORE DATABASE.

Si la restauration réussit, vous pouvez
remettre immédiatement la base
de données en mode multi-utilisateur. Après avoir fermé l’objet SQL-DMO
Server, vous êtes prêt à  revenir à  l’application.
Dites à  l’utilisateur que vous
avez fini puis arrêtez l’application pour
amener les données nouvellement restaurées.
C’est ce que fait le code du
renvoi N.

Téléchargez cette ressource

Guide de Sécurité IA et IoT

Guide de Sécurité IA et IoT

Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010