Qu’est-ce que le « recovery model » SQL Server ?
Il s’agit d’un paramètre de base de données définissant le comportement de son journal de transaction. Ce paramètre est lié aux opérations de restauration et doit être adapaté en fonction de la stratégie de sauvegarde définie.
SELECT name, recovery_model_desc FROM sys.databases
Le « recovery model » SIMPLE ne permet pas une restauration précise dans le temps, mais uniquement à partir d’un backup complet. Avec ce modèle, le contenu du journal de transaction est automatiquement recyclé. Cela a pour effet de simplifier les tâches d’administration (pas de gestion du journal de transaction), mais rend la base plus vulnérable aux pertes de données.
A l’inverse, le recovery model FULL permet une restauration à un point précis dans le temps (grâce à la possibilité de restaurer une chaine de backups de journaux) :
Chaque transaction est ainsi écrite dans le journal, celui-ci continuant de croître jusqu’à ce qu’il soit sauvegardé. La sauvegarde ne réduira pas la taille physique du journal, mais marquera la portion du journal sauvegardée comme vide, et prête à être réemployée. Une base en « recovery model » FULL doit obligatoirement être accompagnée de sauvegardes régulières de son journal, au risque de remplir complètement le disque associé au journal.
Ce paramètre et le comportement de base de données qui en découle sont assimilables à l’ « Archive log mode » d’ Oracle. Le « recovery model » SIMPLE est associé au mode « no archive log », tandis que le « recovery model » FULL est associé au mode « archive log » :
archive log list;
A noter qu’il existe un autre « recovery model » appelé « bulk-logged », destiné à être utilisé temporairement ; Celui-ci améliore les performances de certaines opérations massives en ne les loggant que minimalement.
Le changement de type de « recovery model » se fait à chaud avec SQL Server, tandis qu’un redémarrage de la base est nécessaire sous Oracle.
Le même mécanisme de journaux transactionnels (ici WAL, pour « Write-Ahead Logging ») existe pour PostgreSQL. Similairement, l’archivage des WAL permet les sauvegardes à chaud et les point in time recovery. Quant à MySQL, un article complet est dédié au sujet.