Denali – Indirect Checkpoint

Une nouveauté de taille est disponible dans la CTP3 de Denali. Il s’agit des Indirect Checkpoints. Etonnamment, j’ai trouvé peu de post sur le sujet, alors qu’il s’agit une avancée majeur en ce qui concerne la disponibilité d’une base, car on peut ainsi réduire le durée nécessaire au redémarrage de la base.

Petit rappel sur les checkpoint.

Le checkpoint est un mécanisme qui permet à SQL Server de matérialiser les transactions qui ont été effectuées (et donc enregistrées dans la log, le fichier LDF) dans les fichiers de données, le fichier MDF ou bien un fichier NDF. Que votre base de données soit en mode de récupération simple, journalisé en bloc ou bien complet, il n’y a que le checkpoint qui permet de recopier les pages de données dans le fichier de données. Certes il y a aussi le lazy writer, mais ce n’est pas l’objet aujourd’hui.

Autrement dit, lorsque le checkpoint survient, les informations du journal de transaction et les dirty pages sont recopiées depuis la mémoire vers le fichier de données. L’intérêt principal est de minimiser le temps qu’il faut à SQL Server pour rendre la base de données opérationnelle lorsque celle ci démarre. Plus il y a de transactions à rejouer depuis le dernier checkpoint, plus le démarrage prends du temps, ce que vous avez peut être déjà constaté en regardant la log de SQL Server.

Il existe depuis longtemps la notion de Recovery Interval, ou intervalle de récupération. Cette option de niveau serveur permet de gérer les checkpoint automatiques. SQL Server va estimer combien de transactions il peut rejouer dans le temps imparti par l’intervalle de récupération. Une fois atteint ce nombre de transactions, le checkpoint est automatiquement “provoqué”. De fait une base fortement transactionnelle “subira” de fréquents checkpoints, alors qu’une base peu utilisée verra un intervalle bien plus conséquent entre deux points de contrôle. Si votre base de données est en mode de récupération simple, alors un checkpoint est automatiquement appelé lorsque le taux de remplissage du journal de transaction atteint 70%.

Quelles est la conséquence d’un checkpoint : une grosse activité disque … S’il y a beaucoup de dirty pages a écrire sur disque, il va y avoir un gros pic d’activité à ce moment là (sur le disque de log et sur le disque de data, d’où la recommandation de les séparer pour que cette phase dure le moins possible). On sépare aussi les data des logs pour d’autres raisons, comme la sécurité … On peut jouer sur la valeur du recovery interval de manière à “lisser” l’activité disque ou bien privilégier des pics en augmentant l’intervalle de récupération. L’inconvénient de ce paramètre, c’est qu’il influe sur la totalité des bases, quelle que soit leur activité. Le contrôle du temps de démarrage n’était pas optimum.

C’est pourquoi la CTP3 de Denali introduit les Indirect Checkpoints, qui permettent un contrôle plus fin (niveau base et non plus niveau instance) et prédictible de l’intervalle de récupération. Le but est de permettre une récupération plus rapide de la base de donnée, entendez par là un redémarrage plus rapide. Pour augmenter la fréquence des checkpoint automatiques (SQL Server est conçu pour minimiser les dirty pages en mémoire), il suffit de paramétrer la base comme suit :
ALTER DATABASE … SET TARGET_RECOVERY_TIME = 20 SECONDS

Je pense que cette options va permettre d’obtenir des RTO plus faible, donc d’obtenir une meilleure disponibilité. Cependant, avant d’inciter mes clients à passer sur de mode de checkpoint indirect, je testerais l’impact sur le sous système disque. Microsoft met aussi en garde contre la dégradation de performances sur des systèmes transactionnels (probablement fortement sollicités).

Il reste aussi la possibilité de forcer un checkpoint. C’était possible par le passé, cela reste possible avec Denali.

Quelle est l’interaction entre le target_recovery_time et le recovery interval ?

  • Si pour une base, le target_recovery_time est paramétré, alors la fréquence du checkpoint ne sera influencée que par ce paramètre.
  • Si pour une base, le target_recovery_time n’est pas paramétré, si la valeur du recovery interval est laissée par défaut, le checkpoint interviendra de manière à obtenir un temps de démarrage de l’ordre d’une minute
  • Si pour une base, le target_recovery_time n’est pas paramétré, si la valeur du recovery interval est spécifiée, le checkpoint interviendra de manière à obtenir un temps de démarrage équivalent à la valeur spécifiée.

 

Voilà un paramètre dont on devraient entendre parler dans le futur. J’essaie de préparer une démo sur les avantages et  les inconvénients …

A propos Christophe

Consultant SQL Server Formateur certifié Microsoft MVP SQL Server MCM SQL Server 2008
Cet article, publié dans SQL Server, est tagué , . Ajoutez ce permalien à vos favoris.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s