Lors des forums d’aide au public de SQL Server, une question revient souvent : « Comment puis-je récupérer une seule des tables de ma base de données ? ». La reprise d’une seule table peut s’avérer nécessaire si quelqu’un émet une instruction UPDATE ou DELETE inappropriée qui modifie une quantité appréciable des données de la table de manière non prévue.Dans un tel cas, l’administrateur peut souhaiter remplacer les données de cette table par les dernières sauvegardées. Autre cas où il peut être intéressant de ne restaurer qu’une sous-ensemble des données de la base de données : quand l’un des disques contenant la base de données SQL Server est défaillant mais que les autres disques fonctionnent correctement. Si l’on a une sauvegarde de la base de données antérieure à la modification intempestive ou à la défaillance du disque, on peut fort bien restaurer la base de données dans un nouvel endroit, puis copier les données appropriées de la base de données ainsi restaurée dans la base de données originale. Mais, pour de très grandes bases de données (VLDB, very large databases) contenant des dizaines ou des centaines de giga-octets, des considérations de temps et d’espace peuvent contrarier cette solution. Il n’est pas si simple d’ordonner à SQL Server de restaurer les données appartenant à une table ou à un ensemble de tables. Toutefois, les releases 6.5 et ultérieures de SQL Server donnent des moyens de ne récupérer que certaines parties d’une base de données.
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.
Téléchargez cette ressource
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.
