![\"twitter\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/twitter.png\" "\\"Share")
<\/a><\/a>![\"linkedin\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/linkedin.png\" "\\"Share")
<\/a>![\"mail\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/mail.png\" "\\"Share")
<\/a>Rien de plus simple de que faire une sauvegarde sur SQL Server:<\/span><\/p>\n Et voil\u00e0. L’avantage d’une telle sauvegarde est que je peux la lancer sans stopper mon service, sous entendu avec de l’activit\u00e9: connexions utilisateurs, transactions en cours, etc… Et tout \u00e7a en me garantissant de restaurer une base transactionnellement coh\u00e9rente. Pour y parvenir, elle commence par sauvegarder les donn\u00e9es puis les transactions pr\u00e9sentes dans le journal.<\/span><\/p>\n Avant de parler de ce que fait le BACKUP DATABASE, il faut parler un peu des r\u00f4les respectifs du CHECKPOINT <\/strong>et du COMMIT <\/strong>dans le processus de RECOVERY.<\/span><\/p>\n i)<\/span><\/span>Lorsqu\u2019un utilisateur initie une transaction, ses modifications sont d\u2019abord journalis\u00e9es en m\u00e9moire dans une zone qui est r\u00e9serv\u00e9e pour sa session. Puis les pages de donn\u00e9es et d\u2019index concern\u00e9es sont modifi\u00e9es dans le cache de donn\u00e9es. <\/span><\/span><\/p>\n ii)<\/span><\/span>Lorsqu\u2019il valide sa transaction de mani\u00e8re implicite ou explicite (avec COMMIT TRANSACTION), le contenu de son journal de session est enregistr\u00e9 physiquement dans le fichier LDF. Il est imp\u00e9ratif de s\u2019assurer que le COMMIT ne peut rendre la main \u00e0 la commande appelante que lorsque la transaction a \u00e9t\u00e9 v\u00e9ritablement \u00e9crite sur disque (le \u2018write-ahead logging\u2019 en d\u2019autres termes). Ce m\u00e9canisme permet de pouvoir r\u00e9cup\u00e9rer la transaction valid\u00e9e lorsqu\u2019un probl\u00e8me survient avant que les pages de donn\u00e9es n\u2019aient pu \u00eatre \u00e9crites.<\/span><\/span><\/p>\n iii)<\/span><\/span>De mani\u00e8re compl\u00e8tement ind\u00e9pendante et asynchrone, le processus d\u2019arri\u00e8re plan CHECKPOINT \u00e9crit les pages de donn\u00e9es et d\u2019index modifi\u00e9es (dirty pages) sur le disque, sans se pr\u00e9occuper de savoir si elles appartiennent \u00e0 une transaction valid\u00e9e ou non. <\/span><\/span><\/p>\n A partir de l\u00e0, deux situations peuvent se produire au point de crash: <\/span><\/p>\n 1)<\/span><\/span>Une transaction peut \u00eatre valid\u00e9e (committ\u00e9e) par l\u2019utilisateur mais le CHECKPOINT n\u2019a pas eu le temps d\u2019\u00e9crire les pages de donn\u00e9es \/ d\u2019index sur disque. Il va falloir r\u00e9\u00e9crire ces pages dans le fichier de donn\u00e9es au red\u00e9marrage de l\u2019instance (REDO <\/strong>ou ROLL-FORWARD). <\/span><\/span><\/p>\n 2)<\/span><\/span>Le CHECKPOINT qui n\u2019a pas de vision sur l\u2019\u00e9tat de la transaction peut avoir \u00e9crit ses pages sur disque avant qu\u2019elle n\u2019ait \u00e9t\u00e9 valid\u00e9e par l\u2019utilisateur. Auquel cas il faudra d\u00e9faire les pages \u00e9crites car au point de crash car la transaction ne peut \u00eatre consid\u00e9r\u00e9e comme valide. (UNDO <\/strong>ou ROLLBACK). <\/span><\/span><\/p>\n C\u2019est la combinaison de ces deux actions que l\u2019on appelle le RECOVERY<\/strong>. Ce processus intervient dans de nombreux changements d\u2019\u00e9tat de la base, et notamment pour ce qui nous int\u00e9resse, lors de la phase de restauration d\u2019une sauvegarde.<\/span><\/p>\n Lorsque le BACKUP DATABASE est ex\u00e9cut\u00e9, il commence par forcer l\u2019ex\u00e9cution d\u2019un CHECKPOINT dans la base concern\u00e9e. Ce CHECKPOINT aura pour effet d\u2019ent\u00e9riner des transactions valid\u00e9es depuis ma derni\u00e8re sauvegarde de journal : Les pages de donn\u00e9es \/ d\u2019index sont \u00e9crites sur disque, la sauvegarde n\u2019a donc plus besoin de s\u2019en pr\u00e9occuper. Bien s\u00fbr il peut aussi \u00e9crire les pages de donn\u00e9es \/ d\u2019index d\u2019une transaction qui n\u2019est pas encore valid\u00e9e. Imm\u00e9diatement ensuite, il va relever un num\u00e9ro de transaction (LSN pour Log Sequence Number)dans le journal pour s\u2019en servir comme borne de d\u00e9part pour le RECOVERY. Appelons-le LSN1<\/strong>. <\/span><\/p>\n Puis il va lire et \u00e9crire les pages de donn\u00e9es depuis le fichier MDF ou les diff\u00e9rents filegroups, et les \u00e9crire dans le fichier de sauvegarde. Une fois termin\u00e9es ces \u00e9critures, il renote le LSN courant (qui entre temps peut avoir\u00e9volu\u00e9), et s\u2019en sert comme borne de fin (LSN2<\/strong>). Puis il va sauvegarder tout ce qui se trouve entre (LSN2 \u2013 LSN1<\/strong>). Certaines transactions seront valid\u00e9es, certaines ne seront peut \u00eatre pas termin\u00e9es, mais peut importe, car au moment de la restauration, le processus de RECOVERY fera son \u0153uvre pour ramener la base \u00e0 un \u00e9tat transactionnel consistant. <\/span><\/p>\n Si le LSN2 lui ne change pas car c\u2019est toujours le dernier num\u00e9ro g\u00e9n\u00e9r\u00e9 dans le journal qui sera utilis\u00e9, le probl\u00e8me vient plus du calcul du LSN de d\u00e9part car il va d\u00e9pendre de la situation dans laquelle se trouve le BACKUP DATABASE au d\u00e9part. Globalement, je peux me trouver dans deux cas :<\/strong><\/span><\/p>\n –<\/span>Soit il n\u2019y a aucune transaction en cours au moment o\u00f9 commence la sauvegarde <\/span><\/strong><\/span>: auquel cas LSN1 sera \u00e9gale \u00e0 la valeur du LSN g\u00e9n\u00e9r\u00e9 par le CHECKPOINT (lanc\u00e9 par le BACKUP):<\/span><\/p>\n L\u2019effet du CHECKPOINT ici est de flusher les pages de donn\u00e9es modifi\u00e9es par T1, T2 et T3, pour ne pas \u00e0 avoir \u00e0 les prendre dans la sauvegarde du journal. Ces pages se retrouvent sur disque, et seront captur\u00e9es lors de la copie de donn\u00e9es. <\/span><\/p>\n LSN2 est toujours le LSN courant capt\u00e9 d\u00e8s la fin de la copie de donn\u00e9es. Dans ce cas, T4 est termin\u00e9e mais on est en plein milieu de T5, donc on prend quand m\u00eame ce \u2018fragment\u2019 de T5. Lors de la restauration, T4 sera r\u00e9appliqu\u00e9e et T5 sera rollback\u00e9e:<\/span><\/p>\n Soit il yaura au moins une transaction en cours <\/span><\/strong>: auquel cas, SQL Server va aller rechercher le LSN de d\u00e9part de la transaction active la plus ancienne. Dans l’exemple ci-dessous, il s’agit de T2: Dans ce cas, T2 et T4 qui sont termin\u00e9es avant la fin de la copie de donn\u00e9es seront r\u00e9appliqu\u00e9es et T5 et T3 rollback\u00e9es:<\/span><\/p>\n La table msdb.dbo.backupset qui stocke des donn\u00e9es pour chaque sauvegarde effectu\u00e9e permet de v\u00e9rifier dans quel \u00e9tat se trouvait la base au moment de la sauvegarde. Pour le d\u00e9terminer, il faut comparer les valeurs de checkpoint_lsn et first_lsn:<\/p>\n – checkpoint_lsn = first_lsn:<\/strong> alors il n’y avait pas de transaction en cours au moment du BACKUP DATABASE.<\/p>\n – first_lsn < checkpoint_lsn:<\/strong> alors il y avait au moins une transaction en cours.<\/p>\n Rien de plus simple de que faire une sauvegarde sur SQL Server: BACKUP DATABASE maBase to disk=’D:\\MSSQL.1\\MSSQL\\Backup\\maBase.bak’ with init, stats 10 percent processed. 21 percent processed. 32 percent processed. 43 percent processed. 54 percent processed. 60 percent processed. 71 percent… Continuer la lecture BACKUP DATABASE maBase to disk='D:\\MSSQL.1\\MSSQL\\Backup\\maBase.bak' with init, stats<\/span><\/pre>\n10 percent processed.<\/span><\/pre>\n21 percent processed.<\/span><\/pre>\n32 percent processed.<\/span><\/pre>\n43 percent processed.<\/span><\/pre>\n54 percent processed.<\/span><\/pre>\n60 percent processed.<\/span><\/pre>\n71 percent processed.<\/span><\/pre>\n82 percent processed.<\/span><\/pre>\n93 percent processed.<\/span><\/pre>\nProcessed 144 pages for database 'maBase', file 'maBase' on file 1.<\/span><\/pre>\n100 percent processed.<\/span><\/pre>\nProcessed 2 pages for database 'maBase', file 'maBase_log' on file 1.<\/span><\/pre>\nBACKUP DATABASE successfully processed 146 pages in 0.816 seconds (1.463 MB\/sec).<\/span><\/pre>\n![\"hotbackup1\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2008\/12\/hotbackup1-300x257.png\")
<\/a><\/p>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2008\/12\/hotbackup5-300x117.png\")
<\/a><\/p>\n
\n<\/span><\/p>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2008\/12\/hotbackup2-300x244.png\")
<\/a><\/p>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2008\/12\/hotbackup4-300x73.png\")
<\/a><\/p>\n\n\nselect first_lsn, checkpoint_lsn, last_lsn from msdb.dbo.backupset where database_name= \u2018CAPDATA\u2019 <\/span><\/pre>\n<\/div>\n\nfirst_lsn checkpoint_lsn last_lsn <\/span><\/pre>\n<\/div>\n\n-------------------- -------------------- -------------------- <\/em><\/span><\/pre>\n<\/div>\n\n1341<\/strong> 0000000302<\/strong> 00051<\/strong>1341<\/strong> 0000000302<\/strong> 00051<\/strong>1341 0000000323 00001<\/em> <\/em><\/strong><\/span><\/pre>\n<\/div>\n<\/div>\n\n\nselect first_lsn, checkpoint_lsn, last_lsn from msdb.dbo.backupset where database_name= \u2018CAPDATA\u2019 <\/span> first_lsncheckpoint_lsnlast_lsn <\/span><\/pre>\n<\/div>\n\n-------------------- --------------- -------------------- <\/em><\/span><\/pre>\n<\/div>\n\n1341<\/em><\/span><\/strong> 0000000<\/em><\/span>510<\/em><\/span><\/strong> 000<\/em><\/span>2<\/em><\/span><\/strong>1341 <\/strong>0000000523<\/strong> 00098<\/strong>1341 0000000563 00001<\/em><\/span><\/pre>\n<\/div>\n<\/div>\n[ David B.]<\/div>\n<\/a><\/a><\/a>","protected":false},"excerpt":{"rendered":"