Ma question : comment déterminer la base qui est utilisée par défaut par notre instance ? Sur SQL, une requête du type Exec sp_defaultdb @loginame=’monLogin’, @defdb=’maBase’ permet de modifier ce paramètre facilement. Je n’ai pas trouvé l’équivalent sur SSAS, en tous les cas pas en 2005 (je n’ai pas regardé pour 2008 et 2008R2).

En fouillant un peu dans les fichiers xml d’AS, j’ai trouvé la solution. Chaque base de données possède un fichier qualifié de « référence » pour l’ensemble de l’instance. Le nom de ce fichier est de la forme NomDeMaBaseAS.db.xml. Il contient entre autre le nom et l’ID de la base, les paramètres de traduction, les annotations, etc. Il contient également une propriété qui se nomme Ordinal, et qui précise justement la place de la base de données parmi les autres via un numéro. Si l’ordinal est 0, cette base sera la première, 1 la seconde et ainsi de suite. La base possédant le plus petit ordinal sera celle qui sera considérée comme étant celle par défaut. Il suffit donc de s’arranger pour que la base que vous souhaitez définir comme étant celle par défaut possède le plus petit ordinal. Fastidieux quand il y a beaucoup de base de données (une petite astuce pour éviter d’avoir à parcourir tous les fichiers pour trouver le plus petit ordinal consiste à donner une valeur négative à l’ordinal de la base par défaut : ça marche). C’est pour cela que si jamais vous connaissez une autre solution, je suis preneur. Autre précision, je ne sais pas comment sont déterminés ces ordinaux au moment des déploiements.

Les deux derniers paramètres de la méthode WriteCreate de votre Scripter sont :

fullExpanded :

• false :le script ne contriendra que la création de la base
• true : il incluera tous les objets de votre base (dimensions, cubes, etc.)

allowOverwrite :

• false : lors de l’exécution du script, si la base existe, elle ne sera pas écrasée
• true : c’est l’inverse

L’objet Scripter possède bien d’autres méthodes que vous pouvez retrouver sur le net ou dans le livre MS SQL Server Analysis Services Unleashed.

Si jamais il y en a qui aime se prendre la tête, vous pouvez aussi « parser » le résultat d’une requête XMLA comme DISCOVER_XML_METADATA qui contient lui aussi toute la description de votre base (je dis ça parce que c’est ce que je cherchais à faire au début).

Source :
MS SQL Server Analysis Services Unleashed (chapitre 34, p 694)

Edit du 08/10/2010 : Je viens de tomber sur un post du très bon blog de François Jehl qui explique les subtilités de ce paramétrage : voir ici

AS 2008 introduit une nouvelle propriété pour son modèle de gestion de la mémoire : le HardMemoryLimit (HML). Peu de documents parlent de cette propriété. J’ai trouvé une référence ici (merci Thomas).
Le HML se paramètre de la même manière que le LML et le TML. Il permet de rentrer dans un mode encore plus agressif de nettoyage de la mêmoire : si besoin l’ensemble de la mémoire shrinkable pourra être vidée, de même que les commandes en cours (processing et requête) pourront être annulées.
Attention cependant, de manière analogue aux LML et TML, le HML ne constitue pas une limite physique de consommation de la mémoire, ce qui nous fait d’ailleurs penser que son nom est mal choisi.

Source :

BOL (d’ailleurs il y a une erreur sur cette page car le HardMemoryLimit n’existe pas en 2005)
Connect

En observant les compteurs de performance, on constate que, dans mon cas, l’instance est toujours en train de calculer les indexes de mes partitions, et ça fait longtemps que ça dure :

Courbe verte : nombre de lignes lues
Courbe bleue : nombre de lignes « processées »
Courbe verte : nombre de lignes écrites
Courbe jaune : Nombre de partitions pour lesquelles les indexes et les agrégations sont en cours de calcul (axe des ordonnées de droite)

Et dans le même temps, au niveau de la consommation processeur, on constate que plus grand chose ne se passe, ce qui n’est absolument pas normal étant donné que généralement, les étapes d’indexation/agrégation sont les plus consommatrices de ressources CPU au cours du processing :

Courbe verte : conso CPU en %

Ce cas de figure se présente surtout sur les grosses configurations serveur en 64 bits. Un article de Wayne Robertson ici explique parfaitement le pourquoi du comment.

C’est en fait un problème d’attribution de threads à AS lorsque leur nombre dépasse la valeur de la propriété ThreadPool Process Max. Il existe une manière empirique pour calculer la valeur à imposer à cette propriété, et elle est également expliquée dans l’article ci-dessus. Je vais quand même la rappeller ici :

Faire la somme des valeurs des compteurs de performance suivants (valeurs relevées pendant le hang du processing) :

• Processing Pool Idle Threads
• Processing Pool Busy Threads
• Processing Pool Job Queue Length

Remarque : attention toute fois à la modification de ce paramètre. D’autres propriétés d’AS sont à prendre en compte afin de maintenir l’équilibre du système. Des infos sont disponibles dans le célébrissime livre blanc Performance guide que vous trouverez ici (cf page 65 : Executing Processing jobs).

Et pour aller plus loin, un chapitre tout entier est consacré à la gestion des threads dans le livre SQL Server 2008 Analysis Services Unleashed (chapitre 28, p 521).

Avec ASCMD, un XMLA avec cette tête permet de se passer de Management Studio (un vraie plaie de temps en temps) :

La modification de son emplacement se fait via l’éditeur de registre. Il faut modifier la valeur d’ImagePath située dans HKLM-SYSTEM-CurrentControlSet-Services puis MSSQLServerOLAPService (pour une instance par défaut) ou MSOLAP$InstanceName (pour une instance nommée). Le chemin du msmdsrv.ini se trouve après l’option -s

Petit conseil, la manipulation doit se faire avec l’instance AS éteinte.

Remarque : si jamais l’emplacement spécifié dans la clé de registre n’est pas le bon (une faute de frappe est si vite arrivée), SSAS va quand même démarré et va créer un fichier de configuration tout neuf à l’emplacement spécifié, mais avec tous les paramètres par défaut. Prudence donc si vous avez customisé votre fichier, car dans ce cas, les valeurs de vos paramètres seront celles que nous trouvons à l’installation de l’instance.

Je commence par préciser que les freeze AS peuvent être dû à une multitude de sources, je n’exposerai ici que l’une d’entre elles, clairement identifiée.

Vous avez donc une instance SSAS qui tourne bien jusqu’à ce que vous constatiez que :

• Vous avez une opération de processing en cours sur l’une de vos bases qui ne se termine pas
• Une partie de vos utilisateurs se plaignent car ils ne parviennent plus à obtenir des données de leur cube
• Toute nouvelle connexion à l’instance est impossible, cependant, les connexions établies avant le freeze restent actives, mais comme vu ci-dessus, une partie des requêtes ne passe plus

Voilà pour les symptômes de base. Maintenant, regardons ce qui se passe sur nos outils de monitoring (ici Performance Monitor et SQL Profiler).

On constate sur le Profiler qu’une transaction est en train d’être annulée par AS : pourquoi cela ? Parce qu’un processing est sur le point de se finir et tente d’annuler les requêtes en cours qui utilisent les fichiers que ce processing tente de modifier (voir le ForceCommitTimeout).

Sur le Perfmon, nous pouvons observer qu’il y’a un problème d’utilisation du CPU (plateau à partir de 13h40 généré par la non libération des ressources par le processing en cours et par l’annulation des requêtes). D’ailleurs, si on contrôle la valeur du nombre de thread accordé à AS, nous remarquons qu’il évolue peu ou pas du tout.

Note : Courbe Verte : Utilisation CPU du serveur/Courbe violette : Utilisation CPU par AS
Ordonnées: % d’utilisation
Abscisses: Heure

Le blocage quasi complet de l’instance est donc dû à deux facteurs :

• Une opération de processing en cours
• Une requête dont le temps d’annulation est extrêmement long : dans notre cas, c’est lors du calcul des cellules NON EMPTY que le rollback prend beaucoup de temps. Ce comportement a été modifié avec 2008 et l’apparition du Subspace Computation (ou Block Computation). Voilà pourquoi pour le moment ce problème n’a été observé que sous 2005

Pourquoi les nouvelles connexions à l’instance ne peuvent aboutir ? Simplement parce qu’AS n’établit pas de nouvelles connexions/requêtes quand une opération de processing est dans sa phase de commit. Il les place dans sa file d’attente.

Si vous vous trouvez dans cette situation, il existe deux solutions :

• Attendre l’annulation effective de la requête
• Ou redémarrer l’instance AS

Le constat est que ces deux propositions ne sont pas du tout satisfaisantes. Attendre plusieurs minutes/heures, ou redémarrer l’instance. Heureusement, il existe des moyens de contournement de ce problème :

• L’utilisation du NON EMPTY BEHAVIOUR pour l’optimisation des ordres NON EMPTY (attention à son utilisation sur 2008)
• La réécriture des MDX (pas toujours possible, cela dépend de l’outil client)
• Le passage à 2008 (et oui)

Voici quelques documents :

Subspace/Block Computing :
SSAS 2008 Performance Guide, paragraphe 2.3.2.1

NON EMPTY BEHAVIOUR :
Blog de Marco Russo
SSAS Unleashed, chapitre 12, p196-197, chapitre 29 p 541

• 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

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.

Au niveau de la base :

Au niveau du cube d’une base :

Pour un groupe de mesure :

Attention, ces commandes XMLA nécessitent bien l’ID des objets, et non leur nom. Sous Management Studio, pour les bases de données et les cubes, on retrouve l’information dans les propriétés de ces objets (clic droit-Properties).
En revanche, cette manipulation n’est pas possible pour les groupes de mesures. Dans ce cas, on peut le faire de cette manière : clic droit sur le groupe de mesure-Script Measure Group As-Create To et récupérer l’ID dans le script de création. D’ailleurs, si jamais vous avez une autre solution, je suis preneur : celle-ci ne me satisfait pas.

Et pour ne pas avoir à rechercher par la suite ces scripts, nous pouvons les intégrer aux templates déjà présents sur Management Studio (merci Romuald). Pour cela, allez dans le menu View-Template Explorer pour afficher le volet Template Explorer, puis cliquez sur le cube de la fenêtre pour visualiser les modèles.

Sources :
SSAS-info : Vidas Matelis