Un petit strip de Dilbert, même en retard, ça fait toujours plaisir le vendredi 🙂
Traduction approximative:
Dilbert : « Il n’existe pas vraiment de standard objectif pour mesurer combien je devrais accomplir chaque jour »
Dilbert : « Par ailleurs, on ne peut pas vraiment savoir si les choses auraient pu mieux se passer si j’avais fait les choses différemment. »
Boss : « Et alors? »
Dilbert : « Alors je rentre chez moi. Essayez de voir si vous sentez la différence. »
Un petit concentré de bon sens de Brendan Daws (via Max Voltar) :
« Le monde est rempli de choses moyennes faites par des gens qui ne veulent déranger personne, ou par des gens qui ne recherchent que la reconnaissance de leurs pairs. »
Cette idée est loin d’être neuve, la remise en cause du statu quo qui dérange la masse endormie, elle revient d’ailleurs souvent chez Seth Godin et consort, ça fait juste du bien de la voir se propager.
Pour ma part, vu le nombre de personnes qui m’en veulent au boulot, c’est vraiment que je dois faire des choses hors du commun 😀
D’ailleurs il ne faut pas oublier son corolaire : lorsque des gens s’énervent au boulot, ce n’est pas forcément un mauvais signe. En effet, cela signifie qu’ils se préoccupent encore suffisamment de ce qu’ils font pour que cela puisse provoquer des émotions fortes comme de la colère. A tord ou à raison, c’est au manager de gérer, mais au moins les émotions sont là, et cela il faut le cultiver.
La petite astuce de la journée concerne le proactive caching (mise en cache proactive alias MOLAP automatique) sur un cube dont le service account ne dispose pas des droits sysadmin.
Pour faire court, les droits strictement nécessaires pour la connexion (niveau serveur) dans ce cas sont :
Si les droits en ALTER TRACE ne sont pas valides, le cube plante complétement, avec le message d’erreur suivant :
Erreur OLE DB: erreur OLE DB ou ODBC: Vous n'avez pas l'autorisation d'exécuter "Sp_trace_create : 42000"
Voici l’article de 2006 de Darren Gosbell qui nous a sauvé la mise sur le sujet.
NB : La connexion dont on parle c’est celle du service account, c’est à dire le compte qui fait tourner le service « SQL Server Analysis Services (#Instance) » sur le serveur. Et pour que l’astuce s’applique il faut évidemment que la DS du cube soit configurée pour utiliser le service account…
PS : Si vous aussi vous galérez à trouver l’écran des permissions sur lequel déclarer les droits ALTER TRACE, on le trouve dans SSMS : Sécurité (du serveur) > Connexions > (click droit sur la connexion) > Propriétés > Éléments Sécurisables > Ajouter > Le serveur concerné > et là ça apparaît dans la fenêtre du bas…
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:
Pour ceux qui ne suivent pas directement Jamie, je pense linker régulièrement ses bons articles par ici. A suivre donc!
Tout d’abord, qui est ce Michael Stonebraker?
Bah juste un vieux de la vieille de la base de données. Il a contribué à Ingres, Postgre, il est prof au MIT, et maintenant il bosse dans 4/5 boîtes autour des bases de données à stockage vertical. Il en impose en somme. Et si je peux me permettre, il n’est pas très photogénique… Mais ce n’est manifestement pas un défaut pour sa carrière 🙂
Ensuite, qu’a dit ce monsieur qui me fait m’exclamer qu’il casse la baraque? En fait pas grand chose, c’était juste une tentative foireuse de faire un jeu de mot avec son nom…
Mais bon, il a quand même dit des choses dernièrement, particulièrement, il a fait son top 10 des vérités à propos des data-warehouses. Et tout d’un coup, ça devient vachement plus intéressant que tout ce que j’ai dit avant non?
Pour le commentaire de texte, on va se faire ses vérités une par une, du goret quoting comme on disait à mon époque, ça sera plus simple:
Hum, rien à redire là dessus, avec une nette préférence pour les étoiles par ici!
Là, ça me semble plus être du whisful thinking de la part d’un gars qui a mis tous ses oeufs dans un panier vertical qu’une prédiction réellement motivée. En même temps il a prévenu dans l’intro qu’il était biaisé vers sa techno.
Dans tous les cas, si ça doit arriver, je verrais bien un paramètre de base dans SQL Server qui indiquerait le type de stockage souhaité: colonne ou ligne. Ça ce serait sympa!
En gros: les DWH sont trop gros pour être stockés en RAM ou sur de la flash, compte tenu du prix de ces mémoires par rapport à la quantité de données à stocker. Ils seront donc cantonnés aux disques durs pour un bout de temps.
Rien à redire là dessus, il prend pas trop de risques en même temps.
Mouais. Faut voir ce qu’il appelle le « marché ». S’ils ne considèrent que les DWH qui pèsent des Peta, alors là oui. Pour la majorité des DWH, ceux qui sont dans les Giga, ça risque de prendre plus de temps. Dans tous les cas, nous on est prêt, on a rien à craindre!
Je suis carrément d’accord là dessus. Ça dit que l’augmentation du nombre d’options et de paramètres dans la configuration des bases implique une baisse de la compétence des dBa. C’est normal! Avec 20 pages de paramètres, il faut des magiciens pour arriver à tuner correctement une base en perte de performance.
Et j’aime l’approche prise du côté SQL Server sur ce point: installer une base ça prend 15 minutes. Elle pourra tourner pendant 5 ans sans aucun problème. La plupart des options sont très correctement configurées par défaut. Et si besoin, on peut quand même accéder à 15 pages d’options pour les cas bien tordus.
Encore d’accord. Teradata héberge des gens extrêmement brillants, mais je n’accroche pas du tout à leur modèle.
Pour la BI sur laquelle je bosse, c’est trop compliqué, trop figé et surtout trop cher.
Mouais. Tout dépend de l’échelle des applications. On peut faire cohabiter de l’OLTP et de l’OLAP (au sens large) dans une même base SQL Server sans tout crasher, tout dépend du dimensionnement et des volumétries.
Ce point 7 c’est surtout une occasion pour reparler de stockage vertical! Quel coquin!
Hum. Toutes? Là on va pas être d’accord Mister!
Toutes les applis qui nécessitent des dizaines de serveurs de plusieurs K€, 25 personnes à temps plein pour la maintenance et qui brassent des terabytes de données? Là on est d’accord!
Mais réduire la BI à ça, c’est bien dommage.
Joker, pas mon sujet.
Même remarque que pour la 8. Encore une fois le monde du BI est réduit aux monstres. C’est bien dommage!
Conclusion:
Je suis d’accord sur 4 points (1,3,5,6), pas d’accord sur 1 (2), et pas d’accord sur la définition du marché de la BI sur 4 (4,7,8,10). Plus un NSPP, le 9.
Et vous? 🙂
Ouais, ça claque pas mal comme conversion ça, non?
C’est un article de FlowingData qui m’a pointé vers ce Data Converter, et franchement je trouve qu’il mérite d’apparaître dans mes bookmarks (alias ici même).
Ca + un rechercher/remplacer, ça sauve des vies 🙂
La BI ça vous gagne! 