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)

Les points clés pour une certification réussie :

• Une bonne présentation orale (prestance, voix, ton, mouvement dans la salle, etc.)
• Un brin de diplomatie dans la gestion des conflits (pour le QCM)
• Un support de formation propre (Power Point, à préparer par vos soins avant le passage de la certification)
• Une attention particulière à vos étudiants (est-ce qu’ils suivent, est ce qu’ils ont tout compris)
• Interaction avec votre auditoire

Si certains d’entre vous se sentent l’âme d’un formateur…

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