juillet
2010
Un article de patriceharel
Voici un petit cas d’utilisation permettant de montrer l’utilité du paramètre ForceCommitTimeout d’AS :
- Lorsque vous lancez un process de vos données (Cube ou Dimension), AS va d’abord écrire dans des fichiers différents de ceux qui existent actuellement dans son système de fichiers. La raison à cela, c’est de pouvoir permettre par exemple aux MDX lancées avant le début du process de se terminer correctement.
Pour visualiser ce phénomène simplement, allez par exemple dans le répertoire contenant les données de faits de la partition 2001 du groupe de mesure Internet Sales de votre base Adventure Works préférée, puis faites un Process de la partition. Vous devriez voir apparaître dans votre répertoire des fichiers supplémentaires avec dans leur nom, un numéro incrémenté de un par rapport au nom de la version des fichiers existants avant le process (en fonction du type de process utilisé, tous les fichiers ne sont pas obligatoirement modifiés).
- Une fois que ces nouveaux fichiers sont prêts à être publiés (« commités » en bon franglais), AS va vouloir poser des locks sur ceux contenant les anciennes données afin d’être sûre que plus aucun job ne les utilisera.
- Imaginons justement qu’AS ne puisse pas vérouiller ces fichiers, car ils sont actuellement utilisés par le moteur pour satisfaire une requête. C’est à ce moment que le ForceCommitTimeout entre en jeu. AS va attendre l’expiration de ce Timeout (par défaut à 30 secondes sur AS 2005 SP3 et AS 2008 SP1) avant de commencer à annuler les jobs des requêtes utilisant ces fichiers.
- Une fois les requêtes annulées, AS pose ses verroux, supprime les anciens fichiers et référence les nouveaux.
Si vous êtes un adepte du SQL Profiler, vous pouvez voir l’effet du ForceCommit de cette manière. Pour vous facilliter les choses, changez sa valeur dans les propriétés de votre instance de manière à être sûre d’annuler une requête : 4 secondes c’est pas mal, 4000 ms dans le fichier de configuration (c’est vrai que je ne l’ai pas précisé, mais le ForceCommit est applicable à l’ensemble de votre instance).
Lancez une requête bien sale, arrangez vous pour que son temps d’exécution soit supérieure à 5-6 secondes (videz le Cache d’AS). Voici le résultat sur le Profiler :
- Lignes 1 à 3 : AS a fini d’écrire dans ses nouveaux fichiers
- Ligne 4 à 11 : tentative d’annulation de la requête en cours. Notons le session ID auquel appartient la transaction : 162150 dans la seonde colonne (TextData). Notons maintenant le SPID qui a lancé l’ordre : 161355 dans la troisième colonne (SPID)
- Ligne 12 : La requête est terminée, son SPID : 162150
- Ligne 13 : Confirmation que la requête s’est terminée, mais avec une erreur : l’opération a été annulée par le serveur. C’est le ForceCommit
- Ligne 14 : Confirmation de la part d’AS que les fichiers ont bien été mis à jour et sont disponibles
- Ligne 15 : Fin du Process
_04.png)
On peut donc dire que le ForceCommit a pour objectif de prioriser plus ou moins fortement les opérations de process par rapport aux opérations de requêtage (ce qui est logique dans la plupart des cas).
On comprend qu’un ForceCommit avec une valeur trop importante pourra entraîner un délai de process plus long car AS laissera plus de temps aux jobs pour se terminer avant de les annuler.
A l’inverse, un ForceCommit trop faible pourra potentiellement annuler les requêtes trop rapidement et vous attirer les foudres de vos utilisateurs.
Attention donc : il faut lui donner une valeur en adéquation avec vos contraintes business, en fonction du nombre de process lancé dans une journée et du temps moyen d’exécution de vos requêtes.
Et pour finir, je précise, car certains font parfois une erreur d’interprétation, que le ForceCommit sert à définir un Timeout sur les requêtes en cours d’exécution pendant un process et non pas de manière générale.