{"id":292,"date":"2010-09-25T00:00:02","date_gmt":"2010-09-25T00:00:02","guid":{"rendered":"http:\/\/www.sqlserver.fr\/blog\/?p=292"},"modified":"2026-05-02T14:31:24","modified_gmt":"2026-05-02T12:31:24","slug":"restore-from-snapshot","status":"publish","type":"post","link":"https:\/\/www.sqlserver.fr\/blog\/restore-from-snapshot\/","title":{"rendered":"RESTORE from SNAPSHOT"},"content":{"rendered":"<p>Lors d\u2019une op\u00e9ration de mise \u00e0 jour logicielle, beaucoup d\u2019administrateurs commencent par faire une sauvegarde de la base de donn\u00e9es avant de lancer les scripts de mise \u00e0 jour fournis par les \u00e9quipes de d\u00e9veloppement. Cette op\u00e9ration est souvent tr\u00e8s co\u00fbteuse en temps, alors qu\u2019il existe une mani\u00e8re beaucoup plus rapide de restaurer l\u2019\u00e9tat d\u2019une base de donn\u00e9es en cas de soucis lors d\u2019un traitement ponctuel.<!--more--><br \/>\nEn effet, depuis sa version 2005, SQL Server g\u00e8re la notion de Snapshot (capture instantan\u00e9e). Une capture instantan\u00e9e de base de donn\u00e9es permet de fixer un point de r\u00e9f\u00e9rence, sur lequel on pourra s\u2019appuyer non seulement pour consulter les donn\u00e9es dans leur \u00e9tat pr\u00e9c\u00e9dent, mais aussi pour effectuer une restauration.<br \/>\nDans un premier temps, cr\u00e9ons une base sur laquelle nous ferons quelques tests.<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"sql\">CREATE DATABASE PRODUCTION;<\/pre>\n<p>Remplissons maintenant cette base avec quelques donn\u00e9es :<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"sql\">USE PRODUCTION\r\nGO\r\nCREATE TABLE DONNEES (ID INT IDENTITY, DONNEES char(8000) DEFAULT SPACE(8000));\r\nDECLARE @i int = 0;\r\nWHILE @i&lt;100000\r\nBEGIN\r\n\tINSERT INTO DONNEES (DONNEES) VALUES (DEFAULT)\r\nEND<\/pre>\n<p style=\"text-align: left;\">Comme nous pouvons le constater, nous avons mis en place un certain volume de donn\u00e9es :<br \/>\n<a href=\"https:\/\/www.sqlserver.fr\/blog\/wp-content\/uploads\/2012\/03\/Disk_Usage.png\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter  wp-image-293\" title=\"Disk_Usage\" src=\"https:\/\/www.sqlserver.fr\/blog\/wp-content\/uploads\/2012\/03\/Disk_Usage.png\" alt=\"\" width=\"620\" height=\"158\" srcset=\"https:\/\/www.sqlserver.fr\/blog\/wp-content\/uploads\/2012\/03\/Disk_Usage.png 746w, https:\/\/www.sqlserver.fr\/blog\/wp-content\/uploads\/2012\/03\/Disk_Usage-300x76.png 300w\" sizes=\"auto, (max-width: 620px) 100vw, 620px\" \/><\/a><br \/>\nPrenons maintenant le temps de faire une capture instantan\u00e9e de notre base.<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"sql\">CREATE DATABASE PROD_SNAPSHOT\r\nON (NAME='PRODUCTION', FILENAME='C:\\WINDOWS\\TEMP\\PROD_SNAP.MDF')\r\nAS SNAPSHOT OF PRODUCTION<\/pre>\n<p style=\"text-align: left;\">Et l\u00e0, on constate l\u2019aspect \u00ab instantan\u00e9 \u00bb de cette capture. En effet, la commande ci-dessus ne copie pas les donn\u00e9es, mais travaille simplement autour des m\u00e9tadonn\u00e9es. Elle cr\u00e9e donc ce qui parait \u00eatre une copie, mais en quelques dixi\u00e8mes de secondes seulement.<br \/>\n<a href=\"https:\/\/www.sqlserver.fr\/blog\/wp-content\/uploads\/2012\/03\/PROD_SNAPSHOT.png\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-294\" title=\"PROD_SNAPSHOT\" src=\"https:\/\/www.sqlserver.fr\/blog\/wp-content\/uploads\/2012\/03\/PROD_SNAPSHOT.png\" alt=\"\" width=\"183\" height=\"76\" \/><\/a><br \/>\nMaintenant, jouons un petit script simulant une modification de base (donn\u00e9es et structure).<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"sql\">USE PRODUCTION\r\nGO\r\ndeclare @Id int\r\nselect @Id=MAX(Id) FROM DONNEES\r\ndelete FROM DONNEES WHERE Id=@Id\r\nCREATE TABLE NEW (ID int, VALEUR varchar(MAX))<\/pre>\n<p style=\"text-align: left;\">Nous constatons bien que la capture instantan\u00e9e n\u2019a pas \u00e9t\u00e9 impact\u00e9e :<br \/>\n<a href=\"https:\/\/www.sqlserver.fr\/blog\/wp-content\/uploads\/2012\/03\/Comptage.png\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-295\" title=\"Comptage\" src=\"https:\/\/www.sqlserver.fr\/blog\/wp-content\/uploads\/2012\/03\/Comptage.png\" alt=\"\" width=\"442\" height=\"268\" srcset=\"https:\/\/www.sqlserver.fr\/blog\/wp-content\/uploads\/2012\/03\/Comptage.png 442w, https:\/\/www.sqlserver.fr\/blog\/wp-content\/uploads\/2012\/03\/Comptage-300x181.png 300w\" sizes=\"auto, (max-width: 442px) 100vw, 442px\" \/><\/a><br \/>\nEt enfin, voici l\u2019\u00e9l\u00e9ment annonc\u00e9 en introduction de cet article ; supposons que le script de \u00ab migration \u00bb soit erron\u00e9. Nous n\u2019avons pas pris le temps de faire une sauvegarde compl\u00e8te de la base de production avant de le passer, mais nous avons tout de m\u00eame la possibilit\u00e9 de remettre la base de production dans l\u2019\u00e9tat dans lequel elle \u00e9tait.<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"sql\">USE master\r\nGO\r\nALTER DATABASE PRODUCTION SET SINGLE_USER WITH ROLLBACK IMMEDIATE;\r\nRESTORE DATABASE PRODUCTION\r\nFROM DATABASE_SNAPSHOT='PROD_SNAPSHOT';<\/pre>\n<p style=\"text-align: left;\">Et en un temps record, la base est revenue dans l\u2019\u00e9tat d\u2019avant le script de migration !<br \/>\nEn r\u00e9sum\u00e9, quelques op\u00e9rations de tr\u00e8s courte dur\u00e9e permettent d\u2019\u00e9viter une grosse sauvegarde tout en conservant la capacit\u00e9 \u00e0 restaurer la base de donn\u00e9es dans son \u00e9tat initial.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Lors d\u2019une op\u00e9ration de mise \u00e0 jour logicielle, beaucoup d\u2019administrateurs commencent par faire une sauvegarde de la base de donn\u00e9es avant de lancer les scripts de mise \u00e0 jour fournis par les \u00e9quipes de d\u00e9veloppement. Cette op\u00e9ration est souvent tr\u00e8s &hellip; <a href=\"https:\/\/www.sqlserver.fr\/blog\/restore-from-snapshot\/\">Continuer la lecture <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":7,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-292","post","type-post","status-publish","format-standard","hentry","category-article_sql"],"_links":{"self":[{"href":"https:\/\/www.sqlserver.fr\/blog\/wp-json\/wp\/v2\/posts\/292","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.sqlserver.fr\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.sqlserver.fr\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.sqlserver.fr\/blog\/wp-json\/wp\/v2\/users\/7"}],"replies":[{"embeddable":true,"href":"https:\/\/www.sqlserver.fr\/blog\/wp-json\/wp\/v2\/comments?post=292"}],"version-history":[{"count":12,"href":"https:\/\/www.sqlserver.fr\/blog\/wp-json\/wp\/v2\/posts\/292\/revisions"}],"predecessor-version":[{"id":1970,"href":"https:\/\/www.sqlserver.fr\/blog\/wp-json\/wp\/v2\/posts\/292\/revisions\/1970"}],"wp:attachment":[{"href":"https:\/\/www.sqlserver.fr\/blog\/wp-json\/wp\/v2\/media?parent=292"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.sqlserver.fr\/blog\/wp-json\/wp\/v2\/categories?post=292"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.sqlserver.fr\/blog\/wp-json\/wp\/v2\/tags?post=292"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}