> Tech > Modèles de reprise

Modèles de reprise

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

Le modèle de reprise, une nouvelle option de SQL Server 2000, détermine quel sera le niveau de reprise de la base de données et des dernières données entrées en cas de défaillance du système. Pour définir un modèle de reprise, faire un clic droit sur la base de données dans

Modèles de reprise

Enterprise Manager, sélectionner Properties, puis sélectionner l’onglet Options. Choisir le modèle de reprise approprié puis fermer la boîte de dialogue.

Le modèle Full (complet) permet de récupérer toutes les données jusqu’au point de défaillance – sauf si le journal est lui aussi endommagé. Dans ce dernier cas, les données entrées depuis la dernière sauvegarde du journal devront être introduites à  nouveau. Si un fichier de données est endommagé, on peut toujours récupérer les transactions engagées (committed). Si l’on opte pour la reprise complète (full recovery), SQL Server journalise toutes les modifications de la base de données, y compris des opérations comme SELECT INTO et des chargements de données massifs, qui sont généralement effectués sous forme d’opérations non journalisées. Bien que ce mode de reprise soit le plus sûr, il peut alourdir considérablement la tâche du SQL Server.

Le modèle de reprise Simple est l’extrême opposé. Ce modèle prend la place de l’option de base de données trunc. log on checkpoint qui existe dans SQL Server 7.0 et versions précédentes. A un point de contrôle, après avoir écrit les données dans la base de données, SQL Server supprime les transactions engagées du journal des transactions. Avec ce modèle de reprise, il est peu probable que le journal se remplisse ; mais on ne peut pas effectuer de sauvegardes du journal des transactions ou des sauvegardes de fichiers ou de groupes de fichiers qui nécessitent le journal. Il faut recourir à  des sauvegardes complètes et à  des sauvegardes différentielles. On court donc le risque de perdre toutes les données entrées depuis la dernière sauvegarde. Ce modèle de reprise ne convient pas pour des systèmes de production.

Le modèle de reprise Bulk-Logged est un compromis. Il permet des sauvegardes du journal des transactions, pour pouvoir récupérer jusqu’au point où le système a défailli, à  quelques restrictions près. Bulk-Logged signifie que quand on effectue une opération, comme un chargement de données massif, SQL Server ne journalise pas chaque ligne que l’on a insérée. Il journalise plutôt les références aux extensions qui contiennent ces lignes. Quand la sauvegarde du journal des transactions s’effectue, SQL Server sauvegarde le journal et utilise ses références pour sauvegarder les données insérées à  partir du fichier de données. Mais si l’on perd le fichier de données et si l’on a effectué des opérations Bulk-Logged, on ne peut pas sauvegarder le journal qui est sur le disque ; donc, on sera peut-être contraint de réentrer quelques données.

Il est facile de faire la navette entre les modèles de reprise Full et Bulk-Logged. On peut donc choisir le modèle le mieux adapté à  un moment donné, tout en sachant qu’on pourra changer en cas de besoin. (Pour plus d’informations sur la manière d’utiliser les modèles de reprise, voir l’article de Kalen Delaney, Inside SQL Server, « Database Recovery Modes », juin 2000.

Téléchargez cette ressource

Les mégatendances cybersécurité et cyber protection 2024

Les mégatendances cybersécurité et cyber protection 2024

L'évolution du paysage des menaces et les conséquences sur votre infrastructure, vos outils de contrôles de sécurité IT existants. EPP, XDR, EDR, IA, découvrez la synthèse des conseils et recommandations à appliquer dans votre organisation.

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