Catégorie Techno

La Sagesse du Junkie

Fleid 3 commentaires

Le Junkie en question c’est Jamie Thomson, le célébre SSIS Junkie.

Dernièrement il a écrit 3 articles qui ont retenu mon attention:

  • Repenser les méthodes de diffusion de la BI. Utiliser Outlook, les flux RSS, twitter/facebook, que sais-je, pour délivrer les infos issues de la BI, pour moi c’est définitivement sexy. Des variations non seulement sur le medium (iPhone, SmartPhone, Mac…) mais aussi sur la méthode. Ça peut devenir un gros sujet pour nous.
  • Comment ne pas transformer le dataflow en un curseur. Dans un flux de données, il faut savoir bien répartir les taches entre les différentes ressources et composants, sous peine d’être violemment pénalisé en performance. Cet article est une bonne piqure de rappel. Cela dit, attention à l’effet inverse qui consiste à passer toute l’intelligence du flux dans la requête SQL source. Rien de pire qu’une requête de 3 pages dans la source et hop une destination. Quand je vois ça, je m’énerve tout rouge!
  • Le dépivot dynamique : comment dépivoter des données lorsqu’on ne connaît pas à l’avance les colonnes que l’on obtiendra en sortie. A noter que c’est possible quelque part dans un coin de sa tête 😉

Pour ceux qui ne suivent pas directement Jamie, je pense linker régulièrement ses bons articles par ici. A suivre donc!

Reporting Services, des fois je te hais. Vraiment.

Fleid Laisser un commentaire

Et une journée de perdue, une!

En même temps c’est de ma faute, je n’ai pas vérifié les versions de Visual Studio installées sur les postes des développeurs en arrivant, et ça n’a pas raté, merci les versions d’outre-tombe!

J’ai eu droit au bug catastrophe dans SSRS : les requêtes MDX qui disparaissent dans les datasets des rapports.

Pour faire court, BIDS se mélange parfois les pinceaux dans les RDL. Ce faisant il oublie de fermer les tags qui marquent le fait qu’un dataset SSAS utilise une requête MDX spécifique et pas le designer de base… Ce qui spécifiquement déclenche le bug, je ne saurais pas le dire…

Quand ça arrive, il n’arrive évidemment pas à ouvrir la requête peaufinée aux petits oignons dans son designer tout étriqué, et donc il plante. Et quand il plante, il efface la requête…

Hum, hum…

Et malheureusement, quand ça arrive, ça ne se manifeste que lorsqu’on ouvre un dataset. Si on ne touche pas aux datasets et qu’on ne fait que du design/aperçu,  le bug n’apparaît pas!

Hum, hum…

Donc au programme de la journée nous avons:

  • Installation du SP1 de Visual Studio sur tous les postes
  • Extraction dans NotePad++ des requêtes MDX depuis les RDL ressortis du SVN
  • Insertion des requêtes dans tous les rapports, remappage de tous les paramètres (oh joie)
  • Allumage d’un cierge en espérant que l’installation du SP1 suffira à régler le problème…

Chouette! ><

Update 05/09/2010 : Le cierge a fait son effet, on a pu se remettre au boulot!

Au final c’était un seul des postes qui était responsable, et pour lui on a été obligé de faire une réinstall complète. Et lors de l’installation du SP3 de SQL Server, un des KB (le KB955706) ne passait pas. On a dû la réinstaller à la main. Passé ça, tout est rentré dans l’ordre.

…et un cube pour les diriger tous!

Fleid Laisser un commentaire

Chris Webb (pour rappel, l’auteur de la bible des cubes SSAS) reprend la discussion sur la question : faut il monter tous ses groupes de mesures dans un seul gros cube ou dans plein de petits cubes?

Le débat a repris suite à une question posée sur le technet, et Mister Webb fait le point dans cet article.

Je vous donne son avis en version courte, avis auquel j’adhère à 100% :

  • Il faut mieux démarrer avec un seul gros cube afin d’accéder à toutes les mesures dans tous les rapports.
  • Deux exceptions:
    • Dès le départ, si les groupes de mesures sont complétement disjoints (ils n’utilisent que très peu de dimensions en commun), cela ne présente pas d’intérêt de les mélanger,
    • Plus tard, en cas de problème de performances, cela a du sens de créer des petits cubes qui feront des zooms sur les sujets critiques.

C’est ce que je pratique et personnellement je n’ai jamais eu de problème!

Ps: Suis-je seul à systématiquement enlever la deuxième syllabe à « cube » dès que je l’entends dans une phrase pour voir si ça devient cochon? Je suis sûr que non… 😉

Accéder aux attributs d’un cube dans SSRS

Fleid Laisser un commentaire

L’utilisation des attributs de membres d’un cube SSAS dans un rapport SSRS ne se fait pas de manière transparente.

En effet, alors que les attributs sont visibles dans l’éditeur graphique de source de données SSAS de Reporting Services, ils ne sont pas sélectionnables.

Pour y avoir accès dans un rapport, il est nécessaire de basculer en mode Requête MDX, et de modifier sa requête de la manière suivante:

SELECT

 NON EMPTY { [Measures].[...]} ON COLUMNS,
 NON EMPTY { ([Dimension].[Hierarchy].[Level].ALLMEMBERS * [Dimension].[Hierarhcy].[Level].ALLMEMBERS * ... ) }
 DIMENSION PROPERTIES MEMBER_CAPTION, MEMBER_UNIQUE_NAME, [Dimension].[Hierarchy].[Level].[Attribute]
 ON ROWS

FROM    [Cube]
WHERE  ...

Les mots clefs DIMENSION PROPERTIES permettent de passer les valeurs des attributs directement dans le résultat de la requête MDX, les rendant accessibles dans l’onglet mise en page de SSRS.

Ainsi, dans le rapport, la syntaxe à utiliser sera : Fields!######(« Nom de l’attribut »)

Sources:
Blog de Braulio Malaga (Avanade)
MSDN

Le Data Shrink c’est le mal.

Fleid 2 commentaires

Pour les consultants BI Microsoft, il existe trois sets de compétences complémentaires indispensables pour bien traiter les projets exigeants:

  1. Savoir bricoler en ASP.NET: un petit gridview pour faire de la saisie de donnée, ça assure!
  2. Avoir un petit bagage en VB ou en C#, pour les scripts SSIS et autres (cf point n°1)…
  3. Connaître 2/3 astuces de dBa, histoire d’éviter de plomber les serveurs pour une bête histoire de recovery mode.

L’astuce du jour s’inscrit dans cette dernière veine. Elle est très simple donc facile à se souvenir: il ne faut jamais réduire (shrink) une base de données SQL Server. Jamais.

Et ce n’est pas moi qui le dit, c’est Paul Randal d’In Recovery, dans cet article d’Avril.

D’après Randal, non seulement les performances s’écroulent pendant le shrink (normal), mais surtout après, et ça c’est moins marrant.

J’avoue qu’il m’est arrivé de le faire, plusieurs fois, pour sauver des serveurs aux disques durs agonisants. C’était la solution de facilité! Mais maintenant que je sais que ça se paye à moyen terme, je ne le ferais plus. Promis!

Pour savoir comment bien gérer la taille de ses fichiers de données, c’est cet article, du même bonhomme, qu’il faut aller consulter.

McFly, y’a quelqu’un à l’appareil?

Fleid Laisser un commentaire

Dans SSIS, rien de plus frustrant qu’un script qui plante, ou pire, qui ne fait pas ce qu’on lui demande!

Un bon moyen de voir ce qu’il se passe c’est d’utiliser une Message Box pour retourner les valeurs qui sont manipulées par le script. La syntaxe en VB ça donne ça:

Public Sub Main()
     MsgBox("Texte" & Dts.Variables("Nom_de_la_variable").Value.ToString)
     Dts.TaskResult = Dts.Results.Success
End Sub

En C# il faut faire ça:

MessageBox(Dts.Variables["Nom_de_la_variable"].Value.ToString())

Évidemment dans ce cas là faut pas oublier de passer la variable en paramètre d’entrée du script hein…

Source