Je trouve ca ce matin au bureau en arrivant. Puis-je faire un abandon de poste pour mise en danger du salarié? Devrais-je porter plainte pour qu'une enquête permette de retrouver le dépositaire de l'objet?
Réponse sérieuse uniquement.
 
Cordialement.

bah là, le problème, c'était pas tant l'optimisation de la base de données que vraiment le fait que le moteur de base de données dans l'application était une version "gratuite" qui ne tournait que sur un seul core d'exécution. meme pas un processeur, un core !
 
donc la solution d'origine faite sur AS/400 était bien plus rapide, peut-etre mieux optimisée, mais surtout elle prenait tout le CPU dispo, elle ! (sur l'AS/400, par contre )
 
par contre, en gros, pour calculer les prévisions, on avait plusieurs années d'historique et on calculait une moyenne, à pondérer par les données externes rentrées par les employés du client dont c'était le role. d'où le calcul qu'était quand meme assez lourd puisqu'il y avait les chiffres de vente de chaque jour, chaque journal, et ce sur plusieurs années.

Sauf qu'au lieu de rajouter uniquement les nouvelles valeurs, le script vide la table et la reconstruit intégralement... no comment.

 
Pour rester dans le sujet, ça me rappelle ce billet : https://blog.romainfallet.fr/desenchantement-logiciel/
Je sais plus si je l'ai vu passer ici.

 Parce qu'il y a une table de plusieurs millions de lignes où chaque nuit le traitement est sensé rajouter de nouvelles lignes récupérées via l'interrogation d'un web service. Sauf qu'au lieu de rajouter uniquement les nouvelles valeurs, le script vide la table et la reconstruit intégralement... no comment.

C'est que de l'ajout de lignes, pas d'updates ?
Car si y a de l'update ca peut etre bcp plus rapide de passer par du truncate / bulk.
Je gère de gros projets décisionnels et j'ai décidé de tout passer en bulk / insert meme pour des traitements à plusieurs millions de lignes.
Meme si y a que 200-300 modifications, c'est bcp, bcp plus rapide comme méthode.
La pour une table > 100 Millions j'ai un peu rusé
Je ne recupère que les enregistrements modifiées les 48h dernieres heures.
Jointure avec ma table fianle qui contient l'ensemble des millions de lignes et je recrée une nouvelle table avec les lignes non modiifées + les nouvelles / modifiées
Et hop je remets dans ma table finale en truncate / bulk

ca peut etre bcp plus rapide de passer par du truncate / bulk.

Après sachant que ton SGBD est limité à 1 core (un Oracle 11xe ?), la solution serait peut-être de déporter les calculs sur un serveur applicatif ? Ou de stocker des résultats de calculs ?

C'est que de l'ajout de lignes, pas d'updates ?
Car si y a de l'update ca peut etre bcp plus rapide de passer par du truncate / bulk.
Je gère de gros projets décisionnels et j'ai décidé de tout passer en bulk / insert meme pour des traitements à plusieurs millions de lignes.
Meme si y a que 200-300 modifications, c'est bcp, bcp plus rapide comme méthode.

 
non, un truc style raimaDB (pas sur du nom exact, j'ai retrouvé ça sur wikipedia, mais je me souviens qu'à l'époque, sur la page wikipedia, yavait marqué en toutes lettre qu'il existait une version gratuite limitée à un core d'exécution, et la version payante, après )
 
en tous cas, un moteur de base de données en version de test gratuite, que t'es sensé évaluer, puis payer après en passant commande d'une version complète...
 
mais bon, entre les consultants spécialisés payés au prix d'un français avec leurs emails en .cn, et ce coup-là de la version gratuite, ça puait quand meme un peu les aigrefins, quoi

 
ct'incompétence crasse qui mérite la faute lourde et le renvoi a l'école de dev...

 
Tu dis qu'insérer des millions de lignes en bcp est plus rapide que d'en update 200 ou 300 ?

Ce genre d'histoires ne me surprend pas du tout.
Le logiciel original avait du être développé par des types compétents sur un environnement d'une autre époque qui n'avait pas la puissance de calcul des machines actuelles.
On peut supposer que les concepteurs avaient bien réfléchi le schéma de leur base, le type et le dimensionnement de chaque champs de chaque table, les endroits judicieux où positionner des index...et que le code du logiciel avait été optimisé au maximum.
Aujourd'hui je vois arriver en production des logiciels dont la base de données est constituée de 5 tables... dont une contient 300 champs... tous déclarés en varchar(4000).
Je vois des requêtes avec une jointure entre deux tables, dont la jointure se fait sur un champs LOB (non indexable).
Forcément les perfs sont merdiques dès qu'on dépasse quelques milliers de lignes. Mais tant que le fonctionnement renvoie le résultat attendu avant passage en prod tout va bien.
Dernier exemple en date, un traitement devenu tellement lourd qu'on l’exécute un jour sur un serveur et le lendemain sur un autre, et on fait pointer l'appli alternativement sur celui dont les calculs ne sont pas en cours. Et pourquoi ces calcul sont si lourds ? Parce qu'il y a une table de plusieurs millions de lignes où chaque nuit le traitement est sensé rajouter de nouvelles lignes récupérées via l'interrogation d'un web service. Sauf qu'au lieu de rajouter uniquement les nouvelles valeurs, le script vide la table et la reconstruit intégralement... no comment.

Bonjour une question.
Pour un responsable informatique qui encadre jusqu’à 6 agents. Une certification Itil v4 fondation c’est un gros plus ou pas ?

 
gros plus à quel niveau ? sur une embauche, dans le quotidien ?

Sur l’embauche

gros plus à quel niveau ? sur une embauche, dans le quotidien ?

Ce matin j'ai passé un entretien suite à une candidature spontanée pour une compagnie qui fait des services IT (cloud, infrastructure, dev, etc, je reste vague volontairement). Quel plaisir de voir une compagnie avec une structure et une organisation, des procédures, des techs équipés de bons ordis, du télétravail possible, deux fois plus de vacances, des avantages sociaux, un vrai processus d'embauche, des projets sérieux et solides et des clients qui ont de la gueule. A côté de la compagnie de tata pour laquelle je travaille depuis un an, il y a tout un monde. J'ai dit à personne que j'allais passer un entretien, si je me casse c'est 33% de techniciens en moins, j'en ai rien à faire, il s'arrangeront avec leurs problèmes, leurs projets mal branlés et leur structure qui se casse la gueule. J'ai assez perdu mon temps ici à apprendre des trucs mais avec certainement de très mauvaises pratiques (si ça vous intéresse...). J'ai essayé de faire changer les choses, c'est possible vu qu'on est peu nombreux, mais comme la direction s'en cogne, ça sert à rien et les vieux briscards ne veulent rien changer car ils ont une belle planque à se croire important.  
 
Ouf, ça fait du bien
 
Merci

 
j'ai eu tout ça.
Ca n'empeche pas de faire de la merde en prod

ct'incompétence crasse qui mérite la faute lourde et le renvoi a l'école de windev...

 
j'ai eu tout ça.
Ca n'empeche pas de faire de la merde en prod

 
j'ai eu tout ça.
Ca n'empeche pas de faire de la merde en prod

 
Aujourd'hui je vois arriver en production des logiciels dont la base de données est constituée de 5 tables... dont une contient 300 champs... tous déclarés en varchar(4000).

Ce genre d'histoires ne me surprend pas du tout.
Le logiciel original avait du être développé par des types compétents sur un environnement d'une autre époque qui n'avait pas la puissance de calcul des machines actuelles.
On peut supposer que les concepteurs avaient bien réfléchi le schéma de leur base, le type et le dimensionnement de chaque champs de chaque table, les endroits judicieux où positionner des index...et que le code du logiciel avait été optimisé au maximum.
Aujourd'hui je vois arriver en production des logiciels dont la base de données est constituée de 5 tables... dont une contient 300 champs... tous déclarés en varchar(4000).
Je vois des requêtes avec une jointure entre deux tables, dont la jointure se fait sur un champs LOB (non indexable).
Forcément les perfs sont merdiques dès qu'on dépasse quelques milliers de lignes. Mais tant que le fonctionnement renvoie le résultat attendu avant passage en prod tout va bien.
Dernier exemple en date, un traitement devenu tellement lourd qu'on l’exécute un jour sur un serveur et le lendemain sur un autre, et on fait pointer l'appli alternativement sur celui dont les calculs ne sont pas en cours. Et pourquoi ces calcul sont si lourds ? Parce qu'il y a une table de plusieurs millions de lignes où chaque nuit le traitement est sensé rajouter de nouvelles lignes récupérées via l'interrogation d'un web service. Sauf qu'au lieu de rajouter uniquement les nouvelles valeurs, le script vide la table et la reconstruit intégralement... no comment.

Yep tout à fait mais sans comparaison possible. (sur nos serveurs c'est du genre < 2 minutes pour faire du bulk / insert [1.5 Millions de lignes], ca me prends plus de 50 minutes si je devais faire de l'update [35k lignes]
Pas de Redolog, pas de search
Surtout sur des environnements décisionnels.
Mais à l'usage et dans bcp de discussions sur du SQL c'est très souvent conseillé justement de recréer les tables plutot que de faire de l'update.

BBQ ce midi ? Faudra du papier pour allumer le feu

Déjà entre les 200 ou 300 updates de ton message initial et les 35000 de maintenant, on n'est pas tout à fait dans le même ordre de grandeur.

Ensuite même ainsi, c'est épouvantable comme performance.

J'ai fait un test rapide chez moi: pour update 3 champs sur 35k lignes dans une table de 2M, je suis à peu près à 30s en les faisant une par une depuis un autre serveur et ~10s en les faisant en un seul batch de requêtes toujours depuis un autre serveur.

Certes c'est sur un sql server et pas sur cette vieille bouse séchée de oracle

Je suis bien bien chaud pour un dredi soir:  
 
Cette semaine, j'ai refusé de prendre un client au téléphone parce qu'il refusait d'expliquer son problème "nous avons un problème, l'autre prestataire dit que ca vient de chez vous, bougez votre c*l !"
Je me suis fait incendier par mon N+1 a qui j'ai répondu que les diagnostics avaient déjà tous été faits, que le problème ne venait pas de chez nous. Il a forcé un de mes techs à aller constater sur place problème de l'autre prestataire: aucun de ses POS (points de vente) et aucune de ses imprimantes, tous branchés sur le même switch, toujours fourni par ce prestataire,  ne communiquent entre eux au niveau 2. Nous gérons le routeur.
 
Parce que ces foutus POS n'avaient jamais été configurés et qu'une des imprimantes étaient KO.
 
Quand j'ai pointé du doigt que j'avais raison, j'ai encore mangé sévère :-(
 
De même, et j'en avais parlé il y a quelques mois, un opérateur avec un nom en trois lettres et un logo rouge carré à résilié unilatéralement tous les MPLS d'un ensemble de clients (hôtels 5* sur Paris). Il refuse de les remonter, arguant qu'ils ne proposent plus ce service. Nous avons fourni une solution de dépannage avec des VPN IPSEC sur ADSL (lol la synchro à 600kb/s), qui forcément ne fonctionne pas suffisamment bien pour assurer une bonne qualité de service vu la quantité de trafic qui passe dessus.
La solution temporaire est devenue plus ou moins permanente car la direction groupe, voyant que les hotels tournent aunsi, ne veut pas investir un kopeck dans une solution adaptée (ils bloquent même l'upgrade en VDSL des lignes, au même prix, c'est dire...)
Évidemment, les hôtels hurlent, nous mettent copieusement en cause dans les dysfonctionnements multi quotidien, harcèlent notre N1, ...
Après avoir refusé de remettre mon nez dans le problème, le diagnostic étant déjà fait, j'ai hier répondu à mon N+1 que si il voulait que je fasse la communication client, il fallait s'attendre à ce que je mette en cause le siège du groupe. Il n'a pas aimé du tout.
 
Bref, je ne suis pas en odeur de sainteté.  
D'ailleurs, mon entretien annuel de ce jour s'est très, très mal passé.

J'avoue que j'ai la flemme de tout refaire à la mano pour te montrer la diff.
Mais on est sur des bases decisionnelles, donc pas forcement taillée de la meme facon.
Genre les tables font regulièrement plus de 50-60 colonnes (la par exemple celle que j'ai regardé hier c'est 123 colonnes en cibles plus ou moins 200 en sources)
 
Qu'on ne connait pas quel champ a été mis à jour, juste une date de dernière mise à jour ; donc tu fais un update sur les 123 champs
Que c'est que des champs varchars, que les clés c'est des clés composés genre 5 champs, qu'il n'y a de toute façon ni index, ni contraintes ou autre (tjs pareil modèle décisionnel)
Et que de toute facon l'Exadata, l'ETL, l'ensemble des bases etc etc est tuné pour ce genre d'actions.
 
Et de toute facon ils veulent tout faire passer sur Azure / Aws, foutre du PowerBI dessus, etc, et que pour l'instant je me marre bien des perfs vs mon on-premise qui n'a plus odeur de sainteté

Ce matin j'ai passé un entretien suite à une candidature spontanée pour une compagnie qui fait des services IT (cloud, infrastructure, dev, etc, je reste vague volontairement). Quel plaisir de voir une compagnie avec une structure et une organisation, des procédures, des techs équipés de bons ordis, du télétravail possible, deux fois plus de vacances, des avantages sociaux, un vrai processus d'embauche, des projets sérieux et solides et des clients qui ont de la gueule. A côté de la compagnie de tata pour laquelle je travaille depuis un an, il y a tout un monde. J'ai dit à personne que j'allais passer un entretien, si je me casse c'est 33% de techniciens en moins, j'en ai rien à faire, il s'arrangeront avec leurs problèmes, leurs projets mal branlés et leur structure qui se casse la gueule. J'ai assez perdu mon temps ici à apprendre des trucs mais avec certainement de très mauvaises pratiques (si ça vous intéresse...). J'ai essayé de faire changer les choses, c'est possible vu qu'on est peu nombreux, mais comme la direction s'en cogne, ça sert à rien et les vieux briscards ne veulent rien changer car ils ont une belle planque à se croire important.

Ouf, ça fait du bien

Merci