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 🙂

Mais où est Charlie?

Thomas Larock pose une bonne question: mais où sont donc passé les bons managers?

Il pose la question en réponse à l’éternelle questionnement dans le monde des bases de données: mais où sont donc passés les bons dBa? (database administrators, administrateurs de bases de données).
Pour la faire courte: pour reconnaître un dBa qui a du potentiel, l’accompagner dans son chemin d’expertise et lui poser des challenges qui le motiveront à s’investir, et bien il faut un bon manager.

Pas de bon manager, pas d’expert SQL Server. On peut même élargir: pas de bon manager, pas de bon rien du tout. Une évidence qu’il fait du bien de rappeler sous la forme d’un auto-diagnostic: si vous vous plaignez du manque de compétence de vos experts, il existe une forte chance que ce soit avant tout un problème de management, et non d’expertise technique ou de recrutement.

Pourquoi j’ajoute recrutement dans la dernière phrase? C’est David Heinemeier Hansson de 37 Signals qui nous en rappelle la raison: le talent ne s’achète pas. Et comme à chaque fois qu’on parle de 37 Signals, j’en profite pour en remettre une couche: lisez ReWork, ça change la vision du monde professionnel, il n’y a pas que moi qui le dit.

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.