> Tech > Variations sur un thème

Variations sur un thème

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

Voyons quelques autres situations comportant une sauvegarde partielle. Que restaure SQL Server si la sauve-garde que l'on utilise a été effectuée au milieu d'une transaction impliquant de multiples lignes de Table1 ? Et que restaure-t-on si la sauvegarde a été effectuée après une transaction terminée concernant Table1 et Table 2

Variations sur un thème

?

Pour simuler la première situation, il faut utilise Query Analyzer pour exécuter une transaction en batches multiples, en mettant en évidence et en exécutant quelques instructions seulement à  la fois. Comme SQL Server ne permettra pas d’exécuter une commande de sauvegarde à  partir d’une session qui se trouve au milieu d’une transaction, il faudra utiliser une autre fenêtre de connexion pour exécuter une commande de sauvegarde. Donc, dans une fenêtre de requête, exécuter le début d’une transaction :

BEGIN TRAN
INSERT INTO table1
SELECT ‘Ceci est avant la sauvegarde'
GO

Et, dans une seconde fenêtre de connexion, sauvegarder la base de données testdb, en utilisant l’option INIT pour remplacer la sauvegarde précédente :

BACKUP DATABASE testdb
TO DISK = ‘c:\backup\testdb.bak'
WITH INIT
GO

Une fois la sauvegarde effectuée, revenir à  la première fenêtre de connexion et terminer la transaction :

INSERT INTO table1
SELECT ‘Ceci est après la sauvegarde'
COMMIT TRAN
GO

Voyons maintenant ce que la sauvegarde a capturé. Assurez-vous qu’il n’y a aucune connexion avec la base de données testdb_partial, puis réexécutez le script de Listing 2 pour recréer testdb_partial. Si on sélectionne les données de Table2, on ne voit que la ligne originale :

a b
i This is table in FG1

Une sauvegarde et une restauration effectuées avec SQL Server 2000 ne laissent aucune donnée incohérente. Comme la transaction était en cours au moment où la sauvegarde s’effectuait, la transaction n’a été reflétée que partiellement dans la base de données restaurée. Toutefois, le processus de restauration a appliqué la portion du journal de transactions que l’on a sauvegardée en même temps que la sauvegarde de la base de données. Cette opération de restauration du journal a défait les éventuelles modifications que l’on n’avait pas «committed» quand la sauvegarde a été effectuée, et donc la table retrouve son état original.

On peut utiliser le script de Listing 3 pour simuler la situation dans laquelle la sauvegarde a été effectuée après une transaction exécutée impliquant Table1 et Table2. Le script laisse tomber testdb_partial et recrée les tables de FG1 et FG2 dans la base de données testdb originale. Le code de Listing4 montre une transaction qui recouvre Table1 et Table2, qui se trouvent sur deux groupes de fichiers différents. La transaction s’engage (commits), puis le script démarre la sauve-garde. Supposons qu’après cette sauvegarde, quelqu’un endommage ou modifie les données de Table1 et que l’on veuille remettre celle-ci dans l’état où elle était à  la dernière sauvegarde de base de données. Pour récupérer les données, on peut utiliser le script de Listing 2 pour restaurer testdb_partial.

En examinant les données de Table1, on constate qu’elles contiennent la nouvelle ligne insérée pendant la transaction dans Listing 4, mais Table2, dans laquelle une ligne a été insérée pendant la même transaction, est complètement indisponible. On effectue la restauration partielle parce que Table1 sur le groupe de fichiers FG1 était indisponible ou endommagée ; par conséquent, la seule chose importante à  restaurer est Table1. On peut maintenant copier les données de Table1 à  partir de testdb_partial dans le testdb original, où Table2 existe encore avec les données que le code du Listing 4 a modifiées. Une fois que l’on a effectué la restauration partielle et copié les données de la base de données partiellement restaurée dans l’original, le testdb original présente maintenant Table1 et Table2 dans un état cohérent – toutes deux reflètent les changements de la transaction «committed» du Listing 4.

La possibilité de ne restaurer qu’un sous-ensemble de fichiers ou de groupes de fichiers dans une base de données existante aide à  récupérer après une défaillance de média, sans les exigences de temps et d’espace qu’exigerait la restauration de toute la base de données. Quant à  la possibilité de restaurer partiellement une base de données dans un nouvel emplacement, puis de copier ces données dans la base de données d’origine, elle permet de récupérer des erreurs utilisateur.

Téléchargez cette ressource

Comment sécuriser une PME avec l’approche par les risques ?

Comment sécuriser une PME avec l’approche par les risques ?

Disposant de moyens financiers et humains contraints, les PME éprouvent des difficultés à mettre en place une véritable stratégie de cybersécurité. Opérateur de services et d’infrastructures, Naitways leur propose une approche pragmatique de sécurité « by design » en priorisant les risques auxquelles elles sont confrontées.

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