Discussion :

[CleeM]

Bonjour à tous,

J'ai mis au point un petit script qui me permet de sauvegarder une base de données à l'aide de la commande BACKUP DATABASE (Options : WITH INIT, FORMAT), et qui permet ensuite de les restaurer avec la commande RESTORE DATABASE.

Je sais qu'il est possible à l'aide de ces commandes de sauvegarder à chaud une base. Cependant, quelque chose me chagrine.

Voici un petit schéma pour vous expliquer (timeline) :

|-1--------2------------------3----4--->

1: Je lance une grosse requête d'Insert dans ma base de données (~2min).
2: Je lance un 1er backup (A).
3: Je lance un 2ème backup (B).
4: La requête d'insertion se termine.

Déjà premier point, aucune connexion n'a été coupée, et tout s'est bien déroulé.

Je remarque que le backup A pèse 231Mo et le backup B pèse 493M, je me dit que le contenu doit être différent car énormément de données ont été insérées entre les deux.
Mais, lorsque je restaure ma base, que ce soit avec le backup A ou B, je me retrouve avec la base à son état avant la requête d'Insertion (1).


Donc deux questions : pourquoi les deux backup ne font pas la même taille s'ils restaurent une base identique? Comment puis-je m'y prendre pour ne pas perdre les insertions qui pourraient être effectuées lors de mes backups? (Journaux de transaction?)

Merci d'avance, en espérant que vous ayez compris mes explications

[SQLpro]

Il faut savoir comment est faite la sauvegarde pour comprendre la restauration...
La sauvegarde SQL Server à chaud est assez simple :
1) on met un marqueur dans le journal de transaction afin de spécifier à quel moment a débuté la sauvegarde.
2) on enregistre binairement toutes les pages de données depuis la mémoire et le disque
3) on enregistre le journal de transaction

Aussi, le fichier de sauvegarde contient absolument tout pour reconstituer la base dans l'état ou elle se trouvait au moment de la fin de la sauvegarde.

La restauration procède comme suit :
1) lecture dans le fichier de sauvegarde de la table système donnant la structure des fichiers de la base
2) création des fichiers de la base à l'identique, mais vide
3) lecture des pages de données depuis le fichier de sauvegarde et écriture de ceux-ci dans les fichiers correspondants
4) lecture du journal de transaction depuis la marque de sauvegarde et ré-exécution de toutes les transactions VALIDÉES

Votre requête d'insertion n'étant pas encore terminée, la transaction n'est pas validée et elle ne peut en aucun cas être prise en compte lors de la restauration, car elle apparait dans un état indéterminé (non validation). !

En effet, il est indispensable de conserver l'intégrité des données dans tous les cas, y compris lors de la restauration d'une BD !

A +