Bonjour tout le monde,
je voudrais savoir si y'a un outil oracle qui aide à l'optimisation d'une requête qui contient 789 ligne très compliqué a comprendre pour l'optimiser sois même .
CORDIALEMENT
Version imprimable
Bonjour tout le monde,
je voudrais savoir si y'a un outil oracle qui aide à l'optimisation d'une requête qui contient 789 ligne très compliqué a comprendre pour l'optimiser sois même .
CORDIALEMENT
Oui, c'est le SQL Tuning Advisor (et SQL Access Advisor) mais attention, pour l'utiliser il faut avoir payé le Diagnostic Pack et le Tuning Pack.
Une fois cela fait, le plus simple est d’utiliser le Cloud Control pour tuner ta requête : il y a une option de menu dédiée au SQL Tuning Advisor et aussi au SQL Access Advisor.
Si tu n'as pas le Cloud Control, il faudra via SQL*Plus utiliser le package DBMS_SQlTUNE et là, c'est moins simple...
J'ai pas bien compris c'est compliqué ça , ya pas une solution en ligne ou bien un logiciel a installer qui fera l'affaire ?
Tu te doutes bien que pour faire ce genre de travail, c'est des milliers et des milliers d'heures de développement, de test etc etc
Oracle vend très cher le Tuning Pack et ce n'est pas par hasard : il te permet justement de faire ce que tu veux, optimiser si possible des requêtes très complexes.
Tu ne trouveras rien en ligne puisque l'optimisation ne peut se faire que depuis ta base car l'outil a besoin de connaître tes statistiques, paramètres de la base ...
Je vois , Merci en tout cas , je vais voir avec l'équipe DBA ce qu'ils peuvent faireCitation:
Envoyé par Ikebukuro
Si la demande est plus modeste : pourvoir mieux comprendre une requête de plus de 700 lignes quand elle a été écrite par d'autre et qu'il n'y a pas de commentaires pour aider,
alors oui, il existe plusieurs sites et outils qui permettent de présenter de façon standard et donc de mieux "lire" la requête.
Sql developper a une option pour ça.
(sinon une recherche internet avec les mots SQL et formatter vous donnera une liste plus exhaustive que je ne pourrais faire.)
et avec l'onglet Query Builder de SQL developper on peut "voir" graphiquement la construction de l'ordre
exactement c'est difficile de comprendre ce que quelqu'un a écrit dans une requête sans commentaire ni aucune indication et que le nombres de lignes et très grand , j'ai recherché sur google mais je ne trouve pas d'indications comme tu as mentionné , est-ce-que tu as un lien ?
Honnêtement le plus simple est d'utiliser SQLdevelopper (un des rares outils Oracle gratuits) surtout pour la partie "requête graphique"
sinon pour les outils en ligne :
https://www.google.com/search?client...q=sql+formater
c'est avec SQL developer que je travaille , je vais voir l'onglet Builder comme tu as dis et je vais voir aussi le lien google que tu as envoyer , merci beaucoup pour tes indications.Citation:
Envoyé par Michel.Priori
Ne pas oublier l'excellent SQL*Plus!Citation:
Envoyé par Michel.Priori
:lol:
c'est vrai que SQL*plus est un vrai couteau suisse.
Mais lire, voire éditer, une requête de 700 lignes avec SQL*plus, c'est un peu comme utiliser son couteau suisse pour couper un arbre : on fini par y arriver :mouarf:
Si je me rappelle bien le projet "raptor" a presque atteint son but : être un toad killer.
je me demande si c'est pas pour ça qu'on voit de moins en moins de princesses en tant que DBA ... :ptdr:
C'est vite vu.
Tu lance un : set autotrace on
Puis tu te concentre sur ce qui coûte le plus cher.
Ton optimisation sera rapide.
Ensuite tu remplace les sous requête de type in ou not in par des EXISTS et not EXISTS et tu peux rapidement gagner en perfs.
Malheureusement, pour optimiser au maximum une requête, le mieux reste la réécriture... Mais tu en as pour 1 semaine.
Ne pas hésiter à créer les bons indexés.
Bonjour,
En fonction des options (Enterprise Edition avec Tuning Pack) il faut voir les statistiques d'exécution pour voir où le temps est passé et le nombre d'exécution de chaque opération. Cf.: https://blog.dbi-services.com/best-p...xecution-plan/
Ensuite,voir le pourquoi, par exemple sous-estimation d'un nombre de lignes qui fait que l'optimiseur choisit un nested loop pas optimal, ou predicats complexes pour lesquels il n'y a pas de statistiques ou d'index.
En bref, il y a des outils pour voir où est le problème. La résolution, elle sera plutôt humaine même si Tuning Advisor peut donner des idées.
Franck.
Ceci montre les coûts estimés, et si la requête est longue, c'est probablement que l'estimation n'est pas bonne.Citation:
Envoyé par bizu31
Probablement aucune différence, les deux seront probablement transformées en semi-join et anti-join par l'optimiseurCitation:
Envoyé par bizu31