Discussion :

[silveraxe]

Boujour,

Alors je vais essayer d'etre le plus clair possible.

Donc j'ai une base oracle 7.3 et dessus tourne une appli de comptabilité.
Tout ceci fonnctionne depuis un peut plus de 4ans avec des performances correct (bien que pas fabuleuses) et sans souci mis a part des erreur de script ou des tablespace plein.

Mais depuis quelques semaine les performances de cette base sont devenu desastreuses.
ex. un traitement qui mettait une 20n de minutes dur dans les 16h

Peut avant cette degradation j'ai eu un max extent d'attein. Donc j'ai du l'augmenter (505->600) Du coup j'en ai deduit que le probleme etait probablment du a cette modification. Mais c'est pas sur.

la table en question fait 4000000 de lignes (c'est de loin la plus grosse de la table la 2nd est a 500000 lignes)
et c'est la seule table a depasser les 10 extent (la quasi totalité des autres est a 1)

l'outil d'analise tuning>server stats de toad me donne ces 3 points :
disk sort ratio | 12,5859 | increase sort_area_size or tune the sql
chained fetch ratio | 1,5271 | PCTFREE too low for a table
parse/execute ratio | 72,3028 | high parse to execute ratio

il me semble que j'ai le premier uniquement depuis la baisse de performence
le probleme de PCTFREE est sur une autre table (50000lignes chain_cnt:62508)

Voila un peut le probleme. Je suis loin de metriser oracle donc si quelqu'un a des solution pour resoudre mon probleme, ou l'identifier si ce n'est pas lié aux quelques piste que j'ai trouvé.

Je vous remerci d'avance


-- Je reste a votre disposition pour toute information complementaire.

PS: cette base est voué a disparaitre d'ici 4mois donc il faudrait plutot des solution a court terme simple a metre en oeuvre.

[pifor]

Le plus simple serait d'identifier ce qui a été modifié:
- le code applicatif SQL ou PL/SQL ?
- le schéma de la base (un index supprimé ?)
- la mise à jour de statistiques ?
- une option de la base dans le init.ora ?
- quelque chose sur la machine au niveau système ?
- le traitement s'exécute-t-il toujours dans le même environnement
mono-utilisateur ou multi-utilisateur ?

Il faudrait aussi mettre la trace SQL et utiliser tkprof et poster le résultat
avec la/les requêtes, le source SQL de création des objets concernés
Voir http://oracle.developpez.com/guide/tuning/tkprof/#LIII

[silveraxe]

Je vais voir pour la trace ais en attendant je peux deja essayer de repondre aux questions :

Le plus simple serait d'identifier ce qui a été modifié:
- le code applicatif SQL ou PL/SQL ? => non
- le schéma de la base (un index supprimé ?) => non la seule chose modifié sur la base est l'augmentation de l'extent max d'une table
- la mise à jour de statistiques ? => C.à.D. ?
- une option de la base dans le init.ora ? => non
- quelque chose sur la machine au niveau système ? => Oui en fait nous avont changé tout notre adressage IP a cette periode donc il a ete rajouté une 2eme IP sur ce serveur. Pour qu'il continu a trouner dans l'ancien et le nouveau systeme.
- le traitement s'exécute-t-il toujours dans le même environnement
mono-utilisateur ou multi-utilisateur ? => les traitements sont toujours effectué par le meme user au niveau de la base mais lancé par de multiple poste physique via une interface graphique.

[pifor]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

- la mise à jour de statistiques ? => C.à.D. ?

Est-ce que vous avez changé la façon d'exécuter les commandes ANALYZE pour mettre à jour les statistiques dans la base utilisées pour générer les plans d'exécutions ?

[silveraxe]

Heu non je serais bien incapable de savoir comment faire cela.
J'avou metriser beaucoup mieux le sql et le pl/sql que la base oracle.

En tout cas merci pour les reponses.

[childeric]

Mais depuis quelques semaine les performances de cette base sont devenu desastreuses.
ex. un traitement qui mettait une 20n de minutes dur dans les 16h

C'est toujours comme ça avec les dégradations de performences , c'est pourquoi il faut faire un suivi régulier de ces bases.

Sinon tu as plusieurs possibilité

- Migrer en oracle 9IR2 ou 10g ( a terme tu n'as pas le choix, le jour ou tu as un problème machine tu es très mal)
- exporter ton utilisateur, le supprimer, le recrée puis le réimporter
- reconstruire tous tes index

[gregory.broissard]

Effectivement, comme le dit Childeric, malheureusement bien souvent, les dégradations surviennent soudainement et de manière exponentielle !

Le plus simple, je pense, si tu n'as pas de fortes contraintes derrière ton business serait de faire un export/import de tes données afin de les réorganiser.

Ensuite, passer un petit coup de collecte de statistics. Analyze .... en 7.3 puisque qu'il me semble qu'en 7, le package dbms_stats n'existe pas.

[j6m]

"disk sort ratio | 12,5859 | increase sort_area_size or tune the sql"

si tu as de la mémoire sur ta machine pourquoi ne pas augmenter la taille de cet espace mémoire?
Il suffit que le nombre d'extents ait fait dépasser ce qu'Oracle peut gérer en mémoire vive pour tout mettre par terre, surtout avec des disques aussi agés que la 7.3 ça ne doit pas aider si c'est le cas.

Donc sous réserve de bien bien être sûr - et d'avoir bien bien sauvegardé, ça semble une solution à court terme.
Quels sont les paramètres mémoire de cette base et de son serveur?
Il n'y a pas de messages dans l'alert log?