Reprise du message précédent :

pas forcement... certains softs (et donc leurs bdd) ont étaient conçu y'a tellement longtemps que tout ce qui était reporting n'était meme pas encore une idée en l'air... et donc quand maintenant des cdp te sortent des fonctionnels te demandent d'en extraire tout un tas de données/dashboard/reports/... bah tu dois jongler avec ce qui existe et trouver un compromis... tu peux pas toujours au model de badd, et tu peux pas forcement faire des datawarehouse pour ca... donc tu te manges de la requête tordu
 
et c'est parfois en suivant le plan d'execution que tu te retrouves a faire des jointures qui semblent a premiere vu improbable, mais qui au final permettent de passer par un certains nombres de champs indexé et qui te font gagner en vitesse au final meme en bdd, le chemin le plus "court" visuellement, n'est pas toujours le plus optimisé

 
Pas vraiment.
Le business est roi donc quand le business te demande un report précis tu fais ce report précis même s"il faut requéter 50 tables pour avoir toutes les infos.
Mr l'éditeur ne peut pas avoir mis tous les reports possible dans son outil ou pensé à toute les façon de le détourner et donc mis de belles tables et vues qu i s'enchaninent parfaitement.  
L'informatique de gestion c'est rarement du fait maison et même quand ça l'est le transactionnel est prioritaire sur le reporting donc les tables sont faites dans ce sens.

[1] c'est le plus relou dans notre metier, l'heritage de l'existant et ses limites avec lesquelles il faut jongler
[2] au pris du Go actuel (particulierement pour du non critique qui peut tres bien tourner sur du moins fiable que la prod), ca devient de moins en moins un argument non ?
[3] deja, tu profiles tes requetes, c'est beau mais...
[4] ... justement, ca depend normalement de la pureté de l'analyse non ?

[5] comme d'hab, cravate en vue, ennuis a l'horizon !
[6] la pire situation : un soft hérité, d'un editeur tiers qui n'existe plus et meme s'il existe en fait... chui old school a ce niveau, j'ai vu trop de ptits bijous "metier" réalisé en interne et maintenus en interne pour ne pas realiser l'enorme avantage que ca peut représenter par rapport a du "a l'arrache" made in SSII pompe a fric
[7] oui, l'important c'est de faire tourner la boutique evidemment, mais un export puis une moulinette dans une becane séparée c'est pas si problématique surtout aujourd'hui, avec la virtu et les SANs qui permettent pas mal de jouer avec la capacité inutilisée (je dirais que c'est le marché de ces technos d'ailleurs )

 
Quand tu vois ce qu était le logiciel sur lequel je bosse y a 5 ans et ce qu'il est devenu maintenant, personne ne pouvait prévoir les croisements que je fais en ce moment, ca, je peux te le jurer. Faut arrêter de vivre dans un monde d'architecte où on prévoit le SI à 10 ans sans se gourrer et on se barre ailleurs 2 ans après.

chui pas architecte mais DUT/BTS
 
par contre je crois aux bonnes pratiques et a faire vivre un systeme, ainsi qu'aux moulinettes sur un coin de table, tournant a base d'extractions ciblées

 
pour certaines boites, si, rajouter "quelques gigas" c'est pas ca surtout quand tu parles de bdd avec un lourd passif, qui gonfle pas mal tout les jours, et qui ne sont pas tres cnil compliant enfin on en reparlera plus en détail plus tard
 
 
[3] et je viens d'apprendre aujourd'hui une nouvelle optimisation, le "select * [...]" et moins performant qu'un "select '*' ..." dans une close NOT IN mais bon, la prochaine fois que j'aurais a faire un enot in (select *" j'aurais surement zappé (c'était pas une de mes requêtes )
 
[4] faut le temps et les connaissances sur la base avant de démarrer le dev, pour ça c'est pas toujours le cas non plus la demande qui tombe en urgence pour sortir tels données depuis les bases d'une appli YY que tu n'as jamais vu... bon, bah cf. point [5] / [7]

roh !

3: spécifité a la con ca encore le genre de trucs qui peut sauter a une migration de version, "putain tout rame"
"ouais mais en meme temps y a rien de conforme sur ce diesel "  
" "
"

4 :  

Les admins ici présent te répondront surement mieux que moi mais de mon point de vue : une data est au moins répliquée 2 fois via le backup et le drp ce qui  fait que tu dois prendre en compte l'espace utilisable sur chaque serveur et lla capacité de la ligne pour la réplication.
Un disque grand publique ne vaut plus grand chose mais tous ne vont pas dans les baies de stckages qui n'ont pas non plus une capacité d'accueil infinie...
Les bases transactionelles ont une tendances naturelles à grossir et les projets d'archivages à être vu comme non prioritaires  par rapport aux évolutions...
Le budget de la dsi n'est pas infini non plus dans la plupart des entreprises.
Bref tu te retrouve vite avec des problématique où techniquement tu n'as pas le choix.

dans mon nouveau job, suite à quelques problème ultra abusé à base de full scan de table le dsi a indiqué très clairement aux dev qu'à partir de maintenant les perfs étaient leur problème et que ça n’était pas à l'infra de pallier à leur incompétence  

Perso, pour la requete, là, je :  
1) mettrai toutes les jointures entre lignes 9 à 27 dans des inner join bien propre , histoire de se faire une idée de l'ordre "logique" des jointures
2) engloberai tout ca dans un vue imbriquée, et remplacer les not exists par des jointures externes

1) le reporting n'a clairement pas besoin d'un temps de reponse de 300ms, tu peux tres bien generer tes chiffres DSI a l'avance, et a la compta de decaler de 2 ou 3j les données. bon, pour les requetes qui tombent du ciel N+5 comme un cheveu sur la soupe, ouais bon la c'est toute la boutique qui foire a un moment, y a un gars qui a dit "oui bien sur" et personne n'a osé démentir depuis
 
2) capacité bon, t'utilises pas TOUT les champs (ou alors la c'est le soft métier qu'il faut modif, ca prendra moins de temps que de reinventer la roue...) donc deja l'export dédié reporting est plus petit que l'equivalent full prod. ensuite, les DD grand publics non pas forcément, jparlais surtout de matos moins critique : un serveur ou un rack SAN en SATA plutot que SAS, ce genre de choses. ca reduit grandement la facture on va dire jparle PAS de faire tourner la requete un disque 3To jte rassure
 
3) ca, c'est ce qu'on a deja appellé devant moi "force de proposition", tu te pointes avec graphes et arguments, si le mec il dit non devant temoins, il passe pour un con et du coup il dit oui
4) justement, autant essayer de menager la chevre et le chou (vive les vieilles expressions francaises !)
5) plutot que tout mettre sur le dos de la bete de somme...
 
c'est par ptites touches qu'on se fait respecter ou recommander de boites en boites, et certainement pas en se contentant de dire "oui monsieur" et de passer la nuit suivante au boulot. jme trompe ?

un dsi qui met des triques qui fait son taf en fait  

 
Marre des développeurs qui utilisent les ressources systèmes comme excuse pour masquer leur incompétence
 
D'ailleurs là où je bosse, on crée des tables mais on se soucie même pas de créer des indexes

Moi là où je bosse, c'est 3 formulaires pour créer un index et 1h de réunion avec un DBA convoqué pour l'occasion pour vérifier que, oui on a la place dans le Tablespace et non, ca ne va pas changer les plans d'executions d'une requete vitale ni massacrer les perfs de mes insert.  
J'ai déjà vérifié tout ça, avant, bien sur, mais ils ont pas l'habitude des dev. qui pigent tout ces trucs...

Mais chez nous les DBAs sont aussi des consultants et j'ai l'impression qu'ils se contentent de déployer ce qu'on leur donne, ou à tuer des processes qui sont partis en couille.
 
Dans une autre boite où j'ai bossé, les DBAs sont impliqués dès le début des développements et posent leur véto si la base ne répond pas à leurs exigences. Et mon chef de projet (qui avait fait le design de la base) aurait sans doute pondu une énorme merde si les DBAs n'avaient pas mis le holà à ses ambitions

 
Pendant ce temps, ailleurs...

Oué pareil ici.  

J'avais des collegues d'un autre logiciel qui avaient un traitement qui ramait à mort, c'est du Java, je leur fait faire quelques dump et vais voir quelques logs peu connus (spécifique au produit) > à 99% sur que ca vient de requetes qui rament .

Je leur dis de demander un audit par un DBA ... le DBA a fait ce que fond tous les DBA qui bossent chez nous quand on les apelle pour cette situation : ils appuient sur un bouton qui lance un reporting sur quelques indicateurs, le top 10 des requetes en terme de temps CPU et le top 10 des requetes en terme de temps d'exec.   Le DBA voit rien et dit : regardez votre logiciel.  

Le traitement qui ramait était en fait, du point de vue global du logiciel, un petit traitement, donc la requete foireuse ne sortait pas dans le top 10, et en plus, y avait une requete non liée plus loin dans le traitement.  Le DBA n'a rien vu de ça parce qu'on lui a pas dit où chercher et parce que 9 fois sur 10, dans ce cas là, ils vont pas chercher d'eux meme.
Diag. fait finalement en passant à mes collegues l'équivalent des indicateurs du DBA mais limité au top 1000 des requetes ....

Drapal (stagiaire ingénieur système d'information d'exploitation, j'ai aucune idée de ce que ça veut dire, connerie de vocabulaire )

Contexte again...
Une cloture mensuelle complète est à faire en 3 jours chez nous, donc il est impensable qu'un report indispensable pour la faire ne soit pas "à la demande" et disponible.
 

Again un beau SAN ne veut pas dire capacité infinie
 
Une grosse PME peut générer (légitimement) une volumétrie monstre de transactions et avoir des besoin de reporting très variés, dupliquer de la data en créant un pseudo warehouse peut vraiment devenir très problématique : comme indiqué si tu as un drp tu dois être capable de transférer  tes data, tu dois avoir du backup, éventuellement de la redondance via du raid...
 
 

Certes j'ai un profil dev mais je suis sur un poste clé entre les admins, les dev, le business... donc négocier, faire des propositions techniques mais aussi fonctionnelles, gérer les serveurs au mieux des ressources c'est mon boulot quotidien et j'ai vite appris que pour se faire respecter et écouter il faut aussi respecter les autres et apprendre leur problématique et contrainte et que le dev tout puissant qui impose tout cela ne marche pas...
 
 
 
 
 

 
euh...

j'ai arrete de lire a partir de là.  j'etais sûr de la suite...
 
on a eu le meme genre de connerie .
un dev qui ne connaissait que le java avait ete mis sur un projet C++. Il faisait de son mieux mais avait de tres mauvaises "habitudes".
il recuperait toutes les données de requetes dans une map , et ensuite transferait cette map de fonction en fonction . Rien a dire , c'est une façon de faire comme une autre.
Sauf qu'en C++ le passage par defaut est par valeur et non pas par reference ... (en java c'est par reference par defaut pour les objets)  
Donc la map etait copiée a chaque appel de fonctions. Plusieurs dizaine de fois a chaque requete client (car evidement le mec s'etait efforcé de faire un truc bien modularisé , bien séparé donc bcp d'appels intermediaires ...)  
 
Bien entendu , au dev sur un petit echantillon et des machines costaudes,  ca se voyait a peine .  
mais quand la map a commencé  a contenir plusieurs centaines d'elements ...  
 
Resultat  : 60-70% du temps de traitement dans le prog et 30% pour les requetes sgbd  ... Alors que ca aurait dû etre l'inverse.
 
Et impossible de reparer les degats sans refaire le code pas a pas. On a gratté 10-15% mais pas plus .  
 

Euh, le truc que tu racontes a rien à voir avec le mien
 
Bon dans les écols de dev maintenant, ils leur font presque tjs faire du C avant de faire du Java pour éviter ce genre de bétises ^^  
 
J'ai malheureusement commencé par le Java et vu le C après, et c'est pas évident de se poser les bonnes questions niveau gestion de la mémoire quand on a commencé avec le Java...

Oui mais la reaction des DBA avait ete la meme : Y a pas de probleme chez nous , regardez dans votre m... pardon votre logiciel .  
et cette fois ils avaient raison.

Ce débat que j'ai lancé à partir d'une requête SQL  
Bon, tout çà pour dire que j'ai pêté tout le code et découpé le traitement pour effectuer de 'petites' requêtes (4 tables maxi).
Il y a plus de code Java, mais au moins, c'est lisible, plus rapide et plus facilement débuggable...

J'espère que ce sera chiffré aussi
Parce que c'est bien gentil de chier sur les devs, mais on fait ce qu'on nous demande dans le temps qu'on nous donne
Donc en générale, l'opti ça passe en dernier (ou presque) et du coup tu fais de l'opti après coup pendant les phases de recettes/etc.

Chuis dev alors j'ai le droit
 
Et la personne qui fait les estimations admet qu'elle n'y connait rien alors je lui dis qu'elle devrait demander aux devs justement.
 
Résultat: un projet estimé à 3 jours plié en 30 minutes (3 minutes pour l'implémentation sans déconner, les 27 minutes restantes, c'est pour les tests et le déploiement )

 
pas de reporting sur les bases de prod        d'ailleurs chez nous ça va passer en techno in-memory... en attendant l'erp
 

 
tu es presque jeune  , avec de la volonté tu peux t'en sortir pour pas finir à sos amitié    
 

 
quand tout ton CA passe par une appli (en gros) t'as plutôt intérêt à te poser la question avant ça ...  

Un mois sans message sur le site en question. Quelle tristesse

Ah bah j'espère bien

chez nous le soft gere sa BDD ..... comme il peut mais ca marche pas si mal
il y a juste chez un client une comptable relou qui passe sa vie a faire des stats que ca faisait des problèmes
car oui ... curieusement une requête qui prend 45 secondes et mobilise les 4 tables principales ou tous le monde voudrai écrire, ca fait ramer les autres postes    
chez eux on a fini par faire une BDD local sur le poste de la comptable en replication de la base serveur et comme ca elle bosse dans son coin sans faire chier personne  

 
La base de prod est la seule où il y a tout ce qu'il faut pour les faire quand l'appli contient tout ce qu'utilise l'entreprise (vive les erp   ).
On a commencé à parler datawarehouse et cubes mais il faudrait toutes les colonnes dans tous les sens pour répondre à tout le monde ce qui nous a ramené à la problématique terre à terre de combien ça prend en espace, besoin de réplication une fois de plus.  
 

 
ah ça c'est sur que  généralement le datawarehouse est plus gros que l'erp en lui même     et que la modélisation d'un BI est un métier à pars mais ça évite de pourrir les perfs du transactionnel    
 
et en passant en in memory on devrait passer de 4 à 1 terra  et des temps de reponse divisé par 10 donc c'est plutôt un gros gros progrès  

sinon tu peux suivre des formations en ligne hein  

Putain cette chose...
Avec l'envoi de mail daubé...
Et des images des sims en illustration...

et ouais .....

J'arrive sûrement après la guerre (je lurk pas assez souvent par ici) mais zabbix fait ca nativement en 3 clics.

On a ca en place pour une de nos maquette avec la photo de deux baies et des indicateurs d'État a chaque U.

C'est painless et usefull o/

essayes nagvis

Je suis parti sur nagios + nagvis.
Enfin c'est installé mais je n'ai pas encore eu le temps de le configurer

J'apprends qu'un des mes users va se casser son projet étant terminé, normalement je devrais hériter de deux R815 blindés. ha haha. Mais j'ose pas trop y croire, pas de fausse joie toussa.    
 
Faut toujours acheter du matos pour ses users en pensant que tu vas peut-être pouvoir mettre la main dessus plus tard.

Si tu penses pouvoir accaparer le matos d'un user un jour tu prends un truc top, et dans le contraire tu lui prends moins bien ?  

Disons que je sais révéler au monde le potentiel caché de certains équipements.