L’alerte arrive t\u00f4t le matin : le disque qui h\u00e9berge une base de donn\u00e9es de production est plein, et l’application ne peut plus \u00e9crire. Le coupable est un fichier de journal des transactions qui a atteint des centaines de gigaoctets. Une recherche en ligne sugg\u00e8re une porte de sortie facile et, en quelques minutes, la base de donn\u00e9es passe au mod\u00e8le de r\u00e9cup\u00e9ration SIMPLE, le journal est r\u00e9duit et le syst\u00e8me est de nouveau en ligne. Personne ne remarque qu’une d\u00e9cision beaucoup plus importante vient d’\u00eatre prise au passage. Avec une seule sauvegarde par nuit, l’entreprise a discr\u00e8tement accept\u00e9 de pouvoir perdre jusqu’\u00e0 une journ\u00e9e compl\u00e8te de transactions, sans que quiconque en dehors de la salle des serveurs ait \u00e9t\u00e9 consult\u00e9.<\/p>\n\n\n\n
SQL Server inscrit les modifications dans le journal des transactions avant qu’elles atteignent les fichiers de donn\u00e9es. Le sort de ces enregistrements d\u00e9pend ensuite du mod\u00e8le de r\u00e9cup\u00e9ration, un param\u00e8tre propre \u00e0 chaque base de donn\u00e9es. En mode SIMPLE, le moteur r\u00e9utilise automatiquement l’espace du journal d\u00e8s qu’il n’est plus n\u00e9cessaire. En mode FULL, le journal conserve chaque modification jusqu’\u00e0 une sauvegarde du journal, parce que ces enregistrements permettent une restauration \u00e0 un moment pr\u00e9cis. Sa proche variante, BULK_LOGGED, retient le journal de la m\u00eame fa\u00e7on, mais journalise au minimum la plupart des op\u00e9rations en bloc. Lorsqu’une base de donn\u00e9es en mode FULL re\u00e7oit des sauvegardes compl\u00e8tes mais aucune sauvegarde du journal, rien ne lib\u00e8re cet espace, et le fichier grossit jusqu’\u00e0 atteindre sa taille maximale ou remplir le disque. Les mod\u00e8les de r\u00e9cup\u00e9ration existent depuis SQL Server 2000, et pourtant nous trouvons r\u00e9guli\u00e8rement des bases de donn\u00e9es dont personne n’a choisi le mod\u00e8le de r\u00e9cup\u00e9ration. Chaque base de donn\u00e9es cr\u00e9\u00e9e sur une instance h\u00e9rite de son param\u00e8tre de la base syst\u00e8me model, si bien que la configuration refl\u00e8te souvent une valeur par d\u00e9faut plut\u00f4t qu’une d\u00e9cision.<\/p>\n\n\n\n
Quand le journal attend seulement une sauvegarde, passer au mode SIMPLE r\u00e8gle bel et bien le probl\u00e8me de disque, et c’est exactement ce qui le rend dangereux. En mode SIMPLE, une base de donn\u00e9es ne peut \u00eatre restaur\u00e9e qu’\u00e0 la fin de sa sauvegarde la plus r\u00e9cente, de sorte qu’aucune modification effectu\u00e9e depuis n’est prot\u00e9g\u00e9e. Avec une seule sauvegarde compl\u00e8te par nuit, cela peut repr\u00e9senter une journ\u00e9e de commandes, de factures et de donn\u00e9es de production \u00e0 saisir de nouveau \u00e0 la main, \u00e0 condition de pouvoir les reconstituer. Il devient impossible de restaurer \u00e0 la minute pr\u00e9c\u00e9dant une mise \u00e0 jour erron\u00e9e. Le changement brise aussi la cha\u00eene de sauvegardes du journal : aucune sauvegarde du journal ne peut faire avancer la base de donn\u00e9es au-del\u00e0 de ce changement tant qu’elle n’est pas revenue en mode FULL et qu’une nouvelle sauvegarde compl\u00e8te ou diff\u00e9rentielle n’a pas \u00e9t\u00e9 effectu\u00e9e. Imaginez un fabricant dont le syst\u00e8me de commandes tombe en panne l’apr\u00e8s-midi m\u00eame : la restauration ram\u00e8ne les donn\u00e9es de la veille au soir, et l’entreprise d\u00e9couvre une promesse de r\u00e9cup\u00e9ration qu’elle avait faite sans le savoir.<\/p>\n\n\n\n
Le bon mod\u00e8le de r\u00e9cup\u00e9ration est la r\u00e9ponse technique \u00e0 deux questions d’affaires. Combien de donn\u00e9es pouvons-nous nous permettre de perdre, ce qu’on appelle l’objectif de point de r\u00e9cup\u00e9ration, ou RPO? En combien de temps devons-nous \u00eatre de nouveau op\u00e9rationnels, ce qu’on appelle l’objectif de temps de r\u00e9cup\u00e9ration, ou RTO? Ces r\u00e9ponses appartiennent aux personnes responsables du processus d’affaires, pas seulement \u00e0 la personne qui g\u00e8re le serveur. Une base de donn\u00e9es qui ne tol\u00e8re que quelques minutes de perte fonctionne en mode FULL, avec des sauvegardes du journal au moins \u00e0 cette fr\u00e9quence. Une copie destin\u00e9e aux rapports, reconstruite chaque nuit \u00e0 partir de ses sources, peut sans risque fonctionner en mode SIMPLE, puisque la perdre ne co\u00fbte qu’un rechargement. La r\u00e9ponse est rarement la m\u00eame dans tout un environnement : un environnement sain documente donc des cibles pour chaque base de donn\u00e9es, y aligne le mod\u00e8le de r\u00e9cup\u00e9ration et les sauvegardes, et teste les restaurations pour prouver que ces cibles sont atteignables. L’espace disque devient alors une question de dimensionnement planifi\u00e9e \u00e0 l’avance, et non le d\u00e9clencheur d’une d\u00e9cision de r\u00e9cup\u00e9ration.<\/p>\n\n\n\n
Bien faire les choses demande une s\u00e9quence r\u00e9fl\u00e9chie plut\u00f4t qu’un grand projet. Premi\u00e8rement, nous dressons la liste de chaque base de donn\u00e9es avec son mod\u00e8le de r\u00e9cup\u00e9ration, tir\u00e9 de sys.databases, et les dates de ses derni\u00e8res sauvegardes compl\u00e8te et du journal, tir\u00e9es de l’historique des sauvegardes que SQL Server conserve dans msdb. Deuxi\u00e8mement, nous convenons avec les responsables d’affaires d’un RPO et d’un RTO pour chaque base de donn\u00e9es, en commen\u00e7ant par les syst\u00e8mes qui g\u00e9n\u00e8rent des revenus. Troisi\u00e8mement, nous planifions des sauvegardes du journal l\u00e0 o\u00f9 le mode FULL est requis et n’utilisons le mode SIMPLE que l\u00e0 o\u00f9 la tol\u00e9rance convenue le permet. Lorsqu’une base de donn\u00e9es passe de SIMPLE \u00e0 FULL, nous effectuons imm\u00e9diatement une sauvegarde compl\u00e8te ou diff\u00e9rentielle, parce que le changement ne prend effet qu’apr\u00e8s cette premi\u00e8re sauvegarde des donn\u00e9es. Quatri\u00e8mement, une fois que les sauvegardes du journal s’ex\u00e9cutent de fa\u00e7on fiable, nous redimensionnons une seule fois tout fichier journal surdimensionn\u00e9, puis nous n’y touchons plus, puisqu’apr\u00e8s chaque r\u00e9duction, le fichier finit par grossir de nouveau. Enfin, nous testons une restauration par rapport \u00e0 chaque cible, parce qu’un objectif de r\u00e9cup\u00e9ration jamais test\u00e9 n’est qu’un espoir.<\/p>\n\n\n\n
Au fond, il s’agit moins d’un param\u00e8tre de configuration que du moment o\u00f9 la conversation sur la r\u00e9cup\u00e9ration a lieu. Passer en mode SIMPLE une fois le disque plein est un choix r\u00e9actif, fait sous pression par la personne de garde. La position la plus solide consiste \u00e0 fixer les cibles de r\u00e9cup\u00e9ration avant le moindre incident et \u00e0 traiter la croissance du journal comme un signal de routine plut\u00f4t que comme une urgence. Quand le mod\u00e8le de r\u00e9cup\u00e9ration refl\u00e8te une d\u00e9cision que l’entreprise a r\u00e9ellement prise, un disque plein devient un simple \u00e9v\u00e9nement d’entretien plut\u00f4t qu’un pari cach\u00e9, et tout le monde sait ce qu’une restauration ram\u00e8nera. Cette certitude vaut bien plus que l’espace disque qu’elle co\u00fbte.<\/p>\n\n\n\n
Pourquoi le journal des transactions SQL Server continue-t-il de grossir?<\/strong> \u00c0 quoi sert le mod\u00e8le de r\u00e9cup\u00e9ration BULK_LOGGED?<\/strong> Toutes les bases de donn\u00e9es SQL Server doivent-elles utiliser le mod\u00e8le de r\u00e9cup\u00e9ration FULL?<\/strong> Vous ne savez pas o\u00f9 en est votre environnement? R\u00e9servez une conversation gratuite de 30 minutes avec notre \u00e9quipe.<\/p>\n","protected":false},"excerpt":{"rendered":" L’alerte arrive t\u00f4t le matin : le disque qui h\u00e9berge une base de donn\u00e9es de production est plein, et l’application ne peut plus \u00e9crire. Le coupable est un fichier de journal des transactions qui a atteint des centaines de gigaoctets. Une recherche en ligne sugg\u00e8re une porte de sortie facile et, en quelques minutes, la […]<\/p>\n","protected":false},"author":3,"featured_media":3297,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[371],"tags":[162],"class_list":["post-3299","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-database-services","tag-bases-de-donnees"],"acf":[],"yoast_head":"\n
Une cause fr\u00e9quente est une base de donn\u00e9es en mode FULL sans sauvegardes r\u00e9guli\u00e8res du journal. Des transactions de longue dur\u00e9e, la r\u00e9plication ou un r\u00e9plica de groupe de disponibilit\u00e9 en retard peuvent aussi bloquer la r\u00e9utilisation du journal. SQL Server en indique la raison dans la colonne log_reuse_wait_desc de sys.databases.<\/p>\n\n\n\n
BULK_LOGGED est une variante de FULL qui journalise au minimum la plupart des op\u00e9rations en bloc, comme les chargements massifs de donn\u00e9es. Il exige tout de m\u00eame des sauvegardes du journal, et une sauvegarde du journal qui contient des op\u00e9rations en bloc ne peut \u00eatre restaur\u00e9e que jusqu’\u00e0 sa fin, pas \u00e0 un moment pr\u00e9cis \u00e0 l’int\u00e9rieur.<\/p>\n\n\n\n
Non, parce que le bon choix d\u00e9pend de la quantit\u00e9 de donn\u00e9es que chaque base peut se permettre de perdre. Les groupes de disponibilit\u00e9 Always On exigent le mode FULL, et la copie des journaux de transaction exige FULL ou BULK_LOGGED, alors qu’une base de donn\u00e9es interm\u00e9diaire reconstruite \u00e0 partir de ses sources peut souvent fonctionner en mode SIMPLE.<\/p>\n\n\n\n
\n\n\n\n