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
Plan de sécurité Microsoft 365
Les attaquants savent comment prendre le contrôle de votre tenant Microsoft 365, et vous, savez-vous comment le reprendre en main ?
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- La bataille de la 6G se gagne dans la donnée en temps réel
- BlueSecure repense la sensibilisation à la cybersécurité avec des formats immersifs et engageants
- Les agents d’IA fragilisent la sécurité : pour les sécuriser, inutile de repartir de zéro
- Yampa : innovation en IA, souveraineté et sécurité au service des DSI
Articles les + lus
Computex 2026 : 5 signaux forts à retenir
La chaîne d’approvisionnement, point de rupture récurent du SI
Microsoft Build 2026 : contre-offensive des modèles maison face à OpenAI et Anthropic
Rhea1 : SiPearl allume le CPU européen le plus ambitieux pour le HPC et l’IA souveraine
Analyse Patch Tuesday Mai 2026
À la une de la chaîne Tech
- Computex 2026 : 5 signaux forts à retenir
- La chaîne d’approvisionnement, point de rupture récurent du SI
- Microsoft Build 2026 : contre-offensive des modèles maison face à OpenAI et Anthropic
- Rhea1 : SiPearl allume le CPU européen le plus ambitieux pour le HPC et l’IA souveraine
- Analyse Patch Tuesday Mai 2026
