Sauvegardes partielles sous SQL

La commande LOAD TABLE est le mécanisme de SQL Server 6.5 pour restaurer des données en provenance d’une table. Les données de la table peuvent provenir d’un fichier de sauvegarde ou simplement de cette table, que l’on crée en utilisant la commande DUMP TABLE, ou une sauvegarde de base de données complète. Mais cette possibilité de restauration d’une seule table n’est pas aussi utile qu’il y paraît. Pour faire une sauvegarde d’une table, il faut anticiper la nécessité de sa restauration. Si la base de données est constituée de centaines de tables, il faut savoir lesquelles sont le plus susceptibles d’avoir besoin d’une reprise individuelle. Ou plutôt que de décider quelles tables il faut sauvegarder, on peut décider de sauvegarder chaque table individuellement. Mais, le temps, l’espace et les ressources administratives nécessaires pour gérer de telles sauvegardes risquent de rendre cette technique encore moins pratique que la restauration pure et simple de toute la base de données.

Autre possibilité quand on utilise SQL Server 6.5 : restaurer la table à  partir d’une sauvegarde de base de données complète. Cette solution semble idéale : on possède probablement des sauvegardes de base de données complètes, et donc les opérations de sauvegarde ne demandent aucun temps, espace ou ressources administratives supplémentaires. Mais, cette solution présente un grave inconvénient : les données d’une table dans un fichier de sauvegarde de la base de données ne seront pas forcément cohérentes d’un point de vue transactionnel, et donc, si l’on restaure simplement les données provenant d’une seule table, elles risquent d’être incohérentes et de refléter une transaction en cours. Supposons, par exemple, que pendant qu’une opération de base de données se déroule, on émette la transaction suivante dans une version bien plus grande de la base de données Pubs :

UPDATE titres
SET prix = prix * 0.80

Cette instruction a pour but de mettre à  jour le prix de chaque titre dans la table titres avec une diminution de prix de 20 %. L’opération de sauvegarde dans SQL Server 6.5 tente de sauvegarder chaque page dans l’ordre des numéros de pages, mais les pages d’une table ne sont pas forcément dans un ordre particulier. Supposons que la table titres occupe les pages 100 à  200 et les pages 800 à  1.000 dans la base de données. L’opération de sauvegarde pourrait fort bien écrire les pages 100 à  200 sur l’unité de sauvegarde avant que l’instruction UPDATE ne démarre. Et donc, ces pages garderaient les prix originaux. Ensuite, quand la file de sauvegarde écrit les pages 201 à  799, SQL Server met à  jour toute la table conformé-ment à  l’instruction ci-dessus. Donc, au moment où la file de sauvegarde écrit les pages 800 à  1.000, ces pages contiennent les nouvelles valeurs de données mises à  jour. De ce fait, la table titres dans la sauvegarde complète est maintenant incohérente sur le plan des transactions. Si quelqu’un effectue une opération LOAD TABLE pour la table titres, certaines lignes contiendront les valeurs de prix originales et d’autres contiendront les valeurs mises à  jour. Par conséquent, SQL Server 6.5 ne peut pas garantir que les transactions sont atomiques -c’est- à -dire que soit toutes les modifications se produisent, soit aucune d’elles ne se produit.

Cependant, si personne n’effectue une opération LOAD TABLE, les données de table incohérentes ne posent pas de problème, parce que la sauve-garde de base de données complète contient aussi une partie du journal des transactions. Si l’on restaure toute la base de données (plutôt qu’une table), SQL Server effectuera le même processus de reprise qu’il le fait chaque fois qu’il démarre. Pendant la reprise, SQL Server compare les transactions dans le journal avec les données dans la base de données. Il détectera que certaines pages dans la table titres ne sont pas à  jour et il répercutera en avant les modifications sur les lignes des pages 100 à  200. Quand le processus de reprise sera terminé et que la base de données sera entièrement restaurée, la table titres sera cohérente sur le plan transactionnel et toutes les lignes refléteront les valeurs modifiées par l’instruction UPDATE. En raison de ces lacunes dans la possibilité qu’a SQL Server 6.5 de sauvegarder et de restaurer une seule table, SQL Server 2000 et 7.0 n’ont pas cette possibilité. Dans ces releases, Micro-soft donne le moyen de sauvegarder et de restaurer des fichiers et de groupes de fichiers.