Un peu de lecture pour le dBa qui sommeille en vous

Si vous ne connaissez pas le terme, pas de panique, un dBa ce n’est pas quelque chose de vulgaire. L’acronyme signifie database administrator, ou administrateur de bases de données en français. C’est le compère éternel du consultant décisionnel: si le consultant utilise les bases de données, le dBa lui les maintient en vie! On en avait déjà parlé un petit peu avant.

Pour revenir au sujet de cet article, Paul Randal (In Recovery / SQL Skills) nous avait fait en avril un marathon sur son blog en postant un article chaque jour qui clarifiait un des mythes de SQL Server. J’avais d’ailleurs déjà fait un lien vers son article sur le Data Shrink (c’est le mal).

Pour bien terminer les choses, ce monsieur a décidé de regrouper tous ces articles dans un seul PDF librement téléchargeable par ici. C’est évidemment avant tout destiné aux dBa, mais c’est de la culture « générale » bien utile pour un consultant décisionnel.

Et si vous n’avez jamais ouvert SQL Server Management Studio de votre vie, j’avoue, cet article ne sert à rien 🙂

La rentrée!

Bin oui c’est la rentrée pour les gros bloggeurs BI français, qui étaient partis en vacances et qui reviennent enfin nous distiller leur sagesse 🙂

Le premier à rentrer c’est François Jehl, d’abord avec un article sur comment tricher dans SSRS pour réaliser un Magic Quadrant, ensuite avec une méthode pour mettre à plat une dimension parent child en T-SQL. Que du bon!

Le second c’est Christian Robert. Avec Christian c’est pas difficile: à chaque fois je crois maitriser un sujet, à chaque fois il publie un article et je me rend compte que je ne voyais que la partie visible de l’iceberg. Cette fois-ci c’est sur le merveilleux monde du 32/64bit dans SQL Server.

Bonne lecture!

Ps: quand je dis « gros bloggeurs BI français », c’est gros par le talent hein, je ne me permettrai pas… 😉

SQL Server 2008 SP2 et autres sucreries

La nouvelle de la journée : le SQL Server 2008 SP2 sort aujourd’hui! Il est détaillé sur le Team Blog, et se télécharge par là.

J’en profite pour faire le relai d’une sélection d’articles techniques que j’ai collectionné ces 2 derniers mois:

SSRS

  • Importer des cartes autres que celle des USA dans les rapports, via Kasper de Jonge.

SSIS

  • Minimiser les dégâts lorsqu’on effectue un produit cartésien (cross join) dans un flux de données, via Todd McDermid.
  • Une belle remise à plat sur l’utilisation des variables dans les Script Tasks et Script Components, via Todd McDermid encore.
  • Un composant à tester: un nouveau Data Conversion, via Todd McDermid toujours.
  • Une petite piqure de rappel sur les Events et Event Handlers, via le Database Journal.
  • Importer les valeurs d’un result set ADO dans un chaîne, séparées par des virgules. C’est un peu tortueux, mais c’est parfait pour générer des requêtes SQL à la volée. Via SqlServerCentral (enregistrement gratuit)

SSAS

  • MDX : Existing, Count et Filter via Thomas Ivarsson. Il n’explique pas assez à mon gout, mais en jouant avec ses requêtes on comprend bien.

T-SQL

  • Implémenter des tests unitaires automatisés dans Visual Studio 2010 pour le développement des procédures stockées. Ça c’est un sujet à creuser, via Jamie Thomson.
  • Utiliser le MERGE dans SQL Server 2008, via Robert Sheldon de Simple Talk. J’ai honte mais je n’ai pas encore eu le temps de vraiment regarder… Bouh!
  • Dédoublonner un data set grâce à la clause PARTITION BY. Pas sur que ça nous soit très utile en BI cependant, via SqlServerCentral (enregistrement gratuit)

ASP.NET

SharePoint

  • Un livre blanc sur l’authentification Kerberos dans SharePoint 2010, via Kasper de Jonge.

Le Data Shrink c’est le mal.

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.