Version imprimable
Bonjour
Je souhaite optimiser ma base Oracle, j'ai fais quelques essais sur une base test, pour le moment infructueux ...
Voici quelques uns de mes paramètres actuel :
processes 400
open_cursors 300
sessions 622
transactions 684
optimizer_index_caching 25
Qu'en pensez-vous ?
merci
Avez-vous essayé alter system set fast = true; ?
C'est une plaisanterie bien entendu, mais c'est quelque part ce que vous cherchez à faire.
En effet, votre message donne l'impression que vous prenez le problème dans le mauvais sens.
Vous essayez des commandes et "ça n'optimise pas".
Pour améliorer une base, il faut commencer par lister les problèmes concrets, relever des métriques, regarder ce qui peut influer sur ces métriques : optimisation, réécriture de code, changement de matériel, paramétrage.
On évalue la charge (cinq jours de réécriture pour gagner une minute sur un traitement qui dure une heure n'est pas rentable), on se le fait valider et enfin on y va.
Avec cette méthode, on obtient des résultats.
Alors un problème concret, j'en ai un, un de mes traitements prenait 2 heures environ, il en prend 5/6h aujourd'hui, depuis migration de version de base sur une machine plus puissante.
Activez une trace SQ étendue et analyser le fichier de trace ainsi obtenu.Citation:
Envoyé par Arkyano
Bonjour
J'ai maintenant une trace (énorme) avec les requête sql exécutées.
Passez votre fichier de trace avec l'utilitaire tkprof :
http://oracle.developpez.com/guide/tuning/tkprof/
Ou vous pouvez employer un utilitaire de type profiler comme Tvd$xtat ou similaire pour mieux comprendre ce qui se passe pendant le traitement.
Bonjour
donc, à ce que je peux voir, la plus grosse requête dure en temps CPU, 60 secondes et en Elapsed, 62 secondes sur un nombre de Parse/execute/fetch de plus de 17000,
toutes les autres requêtes ne durent même pas 1 seconde, mais sont par contre très nombreuses.
Vous nous avez dit que votre traitement prends 5 à 6 heures. Vous avez activé la trace SQL sur disons 1 heure de traitement. Sur cette heure de traitement combiens de temps le fichier de trace permet d'expliquer ?
Deuxième question la requête parsée et exécutée 17000 fois prends 62 secondes de temps écoulés au total ? Comment avez vous triée votre fichier trace ?
Et troisième: pourriez-vous comparer la trace sur la nouvelle machine et sur l'ancienne ? Quelles sont les différences ?
La trace contient la totalité des 5/6h de traitement.
62 secondes, c'est effectivement sur le total de la requête, après être passé par tkprof, j'ai fait une recherche sur "total", et j'ai pu ainsi récupérer chaque ligne, contenant les durées, ...
Pour comparer avec l'ancienne version, ça va être assez délicat, mais peut-être faisable.
Si vous avez une trace de 5 heures l'outil de type profiler que je vous aie indiqué permet de comprendre où le temps passe c'est-à-dire comment ces 5 heures se reparties entre divers actions dans la base que le fichier de trace contient.
Mais sans employer l'artillerie lourde avez vous généré le fichier de trace avec tri par execpu (sort=execpu) ? Si oui pouvez vous poster juste les informations concernant la requête qui arrivent en première position avec cette option ?
Sinon dans la cas où toutes vos requêtes s'exécutent "super-vite" vous avez peut-être un traitement de type ligne à ligne avec des requêtes contenant des littéraux en dur au lieu d'utiliser des variables de liaison (bind variables).
Je vois que vous avez du mal à analyser la requête tracée, mais il faut générer le rapport avec l'utilitaire TKPROF, et ne pas inclure les activités de sys=no, afin de cibler votre analyse sur les evenements d'attentes .
Une autre alternative, c'est encore plus rapide et plus comprehensible :
créer une task avec dbms_sqltune.create_tuning_task, en passant la requête problematique
en suite éxécute le task, puis générer le rapport toujours avec le package dbms_sqltune ,
Et là, vous aurez probablement des recommendations avec les plans d'execution origine et nouveau,
eventuellement un profil SQL , etc ..
Cordialement !