> Tech > Modèles de reprise

Modèles de reprise

Tech - Par iTPro - 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 gratuitement cette ressource

Aborder la Blockchain, comprendre et démarrer

Aborder la Blockchain, comprendre et démarrer

Une véritable révolution se prépare progressivement... les entreprises doivent veiller à ne pas rester à l’écart et se faire prendre de vitesse. Tout comme la mobilité ou encore le cloud, la blockchain est une composante essentielle de la transformation numérique. Découvrez, dans ce dossier, comment aborder, comprendre et démarrer la Blockchain

Tech - Par iTPro - Publié le 24 juin 2010