Lors d’une opération de mise à jour logicielle, beaucoup d’administrateurs commencent par faire une sauvegarde de la base de données avant de lancer les scripts de mise à jour fournis par les équipes de développement. Cette opération est souvent très coûteuse en temps, alors qu’il existe une manière beaucoup plus rapide de restaurer l’état d’une base de données en cas de soucis lors d’un traitement ponctuel.
En effet, depuis sa version 2005, SQL Server gère la notion de Snapshot (capture instantanée). Une capture instantanée de base de données permet de fixer un point de référence, sur lequel on pourra s’appuyer non seulement pour consulter les données dans leur état précédent, mais aussi pour effectuer une restauration.
Dans un premier temps, créons une base sur laquelle nous ferons quelques tests.

CREATE DATABASE PRODUCTION;

Remplissons maintenant cette base avec quelques données :

USE PRODUCTION
GO
CREATE TABLE DONNEES (ID INT IDENTITY, DONNEES char(8000) DEFAULT SPACE(8000));
DECLARE @i int = 0;
WHILE @i<100000
BEGIN
	INSERT INTO DONNEES (DONNEES) VALUES (DEFAULT)
END

Comme nous pouvons le constater, nous avons mis en place un certain volume de données :

Prenons maintenant le temps de faire une capture instantanée de notre base.

CREATE DATABASE PROD_SNAPSHOT
ON (NAME='PRODUCTION', FILENAME='C:\WINDOWS\TEMP\PROD_SNAP.MDF')
AS SNAPSHOT OF PRODUCTION

Et là, on constate l’aspect « instantané » de cette capture. En effet, la commande ci-dessus ne copie pas les données, mais travaille simplement autour des métadonnées. Elle crée donc ce qui parait être une copie, mais en quelques dixièmes de secondes seulement.

Maintenant, jouons un petit script simulant une modification de base (données et structure).

USE PRODUCTION
GO
declare @Id int
select @Id=MAX(Id) FROM DONNEES
delete FROM DONNEES WHERE Id=@Id
CREATE TABLE NEW (ID int, VALEUR varchar(MAX))

Nous constatons bien que la capture instantanée n’a pas été impactée :

Et enfin, voici l’élément annoncé en introduction de cet article ; supposons que le script de « migration » soit erroné. Nous n’avons pas pris le temps de faire une sauvegarde complète de la base de production avant de le passer, mais nous avons tout de même la possibilité de remettre la base de production dans l’état dans lequel elle était.

USE master
GO
ALTER DATABASE PRODUCTION SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
RESTORE DATABASE PRODUCTION
FROM DATABASE_SNAPSHOT='PROD_SNAPSHOT';

Et en un temps record, la base est revenue dans l’état d’avant le script de migration !
En résumé, quelques opérations de très courte durée permettent d’éviter une grosse sauvegarde tout en conservant la capacité à restaurer la base de données dans son état initial.