mardi 27 juillet 2010

Vider le cache des objets SSAS

Je remets ici un morceau de code bien pratique qui permet de vider le cache de quelques objets sur SSAS.
Au niveau de la base :
<ClearCache xmlns="http://schemas.microsoft.com/analysisservices/2003/engine">
  <Object>
    <DatabaseID>Adventure Works DW 2008</DatabaseID>
  </Object>
</ClearCache>


Au niveau du cube d’une base :
<ClearCache xmlns="http://schemas.microsoft.com/analysisservices/2003/engine">
  <Object>
    <DatabaseID>Adventure Works DW 2008</DatabaseID>
    <CubeID>Adventure Works</CubeID>
  </Object>
</ClearCache>


Pour un groupe de mesure :
<ClearCache xmlns="http://schemas.microsoft.com/analysisservices/2003/engine">
  <Object>
    <DatabaseID>Adventure Works DW 2008</DatabaseID>
    <CubeID>Adventure Works</CubeID>
    <MeasureGroupID>Internet Orders</MeasureGroupID>
  </Object>
</ClearCache>


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.


lundi 26 juillet 2010

Freeze d'AS : Concurrence entre Processing et MDX

Voici un problème récurrent de freeze constaté sur une instance SSAS 2005 auquel j’ai été confronté un certain nombre de fois (attention, ce problème n’a pas été constaté sur 2008).

jeudi 22 juillet 2010

Utilité du ForceCommitTimeout

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).

mercredi 21 juillet 2010

Tracer SQL Browser

Dernièrement, j'ai eu un problème de perte de connexion complètement aléatoire sur AS (je ferai un compte rendu sur ce problème dans un autre post). J'ai cherché à savoir à quel niveau se trouvait cette perte de connexion : donc forcément on pense au SQL Browser à un moment ou à un autre.
Question : comment tracer les évènements de ce service? Il faut le lancer avec l'option -c (sqlbrowser.exe -c). De cette manière, vous voyez toutes les connexions résolues par le Browser et les erreurs sont "loguées" dans l'Event Viewer de votre serveur.