Lenteur soudaine d'un script

[Melmock2]

Bonjours à tous,
Dans ma société nous utilisons Oracle 8i avec les forms pour notre ERP. Chaque soir nous lancons un calcul de besoin un traitement qui durait au début 3h puis petit à petit il est monté en temps.

J'ai une procedure simple que je lancais de temps à autre 3 ou 4 fois par an pour optimiser les tables => analyse estimate statistics 20% soit avec l'outil graphique soit en script sql.

En général je passais de 8h à 3h de calcul, mais depuis début septembre nous sommes passé de 8h à 16h puis maintenant 30h !!! J'ai bien lancé l'analyse mais cela n'a absolument rien changé. Les changements ont eu lieu par "bond" un jour c'est 8h le lendemain 16h.

Le volume de donnée dans la base à une progression constante, nous n'avons pas pu relier cette augmentation de temps à une forte augmentation de donnée.

Avez vous des idées ? Augmenter l'analyse en passant de 20% à 30% ? Detruire les stats et les recalculer ?

PS: Cette base est utilisée depuis 7ans sans jamais avoir rencontré de problème.

Merci d'avance pour vos idées

[heffer69]

Bonjour,

Qu'en est-il de vos index?
Les avez-vous reconstruit?

[Melmock2]

Oui mes tables ont bien des index mais je ne connais pas la manip pour les reconstruire par contre doit on renseigner a nouveau tous les champs de toutes les tables pour refaire les index ?

J'ai lu sur des faq que l'on devait parfois supprimer les stats, reconstruire les index puis recalculer les stats, c'est de cette opération que vous parlez ?

Merci

[lca94]

Code :

ALTER INDEX <index_name> REBUILD;

mais aussi exemple pour les stats:

Code :

1
2
3
4
5
ANALYZE TABLE scott compute statistics;
ANALYZE TABLE scott estimate statistics sample 25 percent;
ANALYZE TABLE scott estimate statistics sample 1000 rows;
analyze INDEX sc_idx compute statistics;
analyze INDEX sc_idx validate structure;

[7gyY9w1ZY6ySRgPeaefZ]

Envoyé par Melmock2

doit on renseigner a nouveau tous les champs de toutes les tables pour refaire les index ?

Le recréation de l'index n'affecte aucunement l'intégrité de tes données.
Un index c'est juste un outil pour optimiser les requêtes.

N'hésite pas à relancer plus souvent le calcul de tes statistiques, surtout si ta base bouge beaucoup. Un job qui lance ça une fois par semaine est un bon compromis.

[ZashOne]

Pout trouver la source de ton probleme ,

tu peux utililiser different outil oracle dont tu trouvera facilement la doc sur le net (tuto developpez.net, doc officiele oracle )tel que

-statpack
-wait events
-Explain plan
-trassage de session / TKPROF
(-hint)

Le but de ces outils est de relever la necessite de realiser un upgrade materiel et/ou la modification de parametres Oracle.

Mais si tu n,a ni le temps ni le courage d'etudier ces outils, tu peux essayer d augmenter l'equivalant oracle 8 du parametre oracle 9 db_cache_size. Lorsque je debutai sur Oracle, cette manip m avait permis de regler en 5 minutes un probleme similaire au tien.

[Melmock2]

Merci de votre aide

Malheureusement pour l'instant rien n'a changé voici ce que j'ai lancé:
Sur environ 2000 indexes j'ai utilisé les commandes suivantes
ALTER INDEX <index_name> REBUILD;
ANALYZE INDEX <index_name> estimate statistics sample 25 percent;

Puis j'ai lancé sur les tables une analyse
ANALYZE <table> estimate statistics sample 25 percent;

Pour le moment le traitement qui durait 8h debut septembre dure toujours 30 heures voir plus. Pourtant le volume de la base n'a pas augmenté plus que l'habituel !

Merci encore

[13thFloor]

Le plan d'exécution a t-il changé entre les versions 8h et 30h ?
Statspack devrait te fournir des indications sur le type d'attentes observées.
Les index utilisés sont-ils valides (en principe oui car tu as tout reconstruis) ?

Une des clé d'index n'a peut être pas une cardinalité suffisante.
Essaie un :
dbms_stats.gather_table_stats(owner=>'ton_schema',tabname=>'ta_table',
estimate_percent=>20,method_opt=>'for all indexed columns');

Ta hash/sort_area_size est peut être trop petite si la requête fait du hash join ou du tri (order by, group by...) => écritures dans le tablespace temporaire. Augmentes sensiblement sort_area_size et/ou hash_area_size
Si hash_area_size non définie, modifies sort_area_size (non dynamique en 8i).

[McM]

Si ça se trouve un index à été supprimé, ou alors un trigger de créé sur une table du script.

Le plus simple c'est de revoir le code du traitement point par point.

[ZashOne]

Il est fort possible que ton systeme os + oracle pagine de maniere excessive.

Malheureusement dans ce cas il n y a pas de procedure concrete (utilisation de differents outils , requete, et lecture de beaucoup de doc,...) , ni de solution concrete (modif parametre oracle, upgrade materiel, upgrade logiciel,...)

Voici un cas auquel j.ai ete confronte sur un systeme windows 2000 serveur standard avec un moteur oracle 9 et qui pourra peut-etre t aider.

-tout les jours en fin de journee une longue requete etait lancee et se realisait correctement
-En journee toute les requetes des differentes appli se deroulait normalement
-Une nouvelle appli avait ete developee dont certaine option realisait des requete jointe qui n avait jamais ete executee avant sur le systeme
-Lorsque ce type de requete etait lancee sur le site de travail, tout le systeme devenait execessivement lent et cela etait du a une pagination os excessive
-Si l on redemarrai le server , tout revenait a son etat normal.

- Au final on a juste modifier le code de l application.

Je te conseille donc de redemarre ton systeme et voir si sa resout le probleme.

Sinon jete un oeuil a sort_area_size et db_cache_size

[tomca]

Sinon, au niveau de l'analyze, je l'utilise de la manière suivante, et ca a l'air de fonctionner plutot bien jusque maintenant :
analyze table ma_table compute statistics for table for all indexes for all indexed columns;

[jbe77]

Bonjour,

Merci beaucoup tomca pour ta requête
Après plusieurs essais et tentatives infructeuses (pb de tablespace), j'ai exécuté ton script sur toutes les tables de mon schéma.
Ma requête s'est ensuite exécutée très rapidement comme par magie.
Maintenant reste à savoir à quelle fréquence exécuté ce calcul de stats.

[orafrance]

attention depuis la 9i c'est DBMS_STATS qui doit être utilisé plutôt que ANALYZE.

[jmguiche]

Envoyé par grungy77

Bonjour,

Merci beaucoup tomca pour ta requête
Après plusieurs essais et tentatives infructeuses (pb de tablespace), j'ai exécuté ton script sur toutes les tables de mon schéma.
Ma requête s'est ensuite exécutée très rapidement comme par magie.
Maintenant reste à savoir à quelle fréquence exécuté ce calcul de stats.

Deux solutions : soit tu attend que cela dérive à nouveau, soit tu rajoute ça dans un traitement batch qui tourne quand ta base n'est pas solicitée.

La fréquence necessaire dépend de la vitesse à laquelle ta base évolue. Si ça se trouve tu n'en a besoin qu'une fois par an !

Le plus simple et de greffer le calcul des stats sur un traitement batch déjà plannifié qui tourne de temps en temps... Toutes les semaines ou tout les mois... Tout les jours si tu es d'un naturel inquiet ! De toute façon, c'est sans risque !

[Alain B.]

Envoyé par jmguiche

De toute façon, c'est sans risque !

Attention quand même à surveiller l'occupation des tablespaces.
Faut bien qu'Oracle stocke ses statistiques ....

[orafrance]

ouais enfin qu'en t'en es à des stats qui pêtent le tablespace c'est que t'as d'autres problèmes qui vont pas tarder aussi

[jmguiche]

Et comme Oracle à ma connaissance ne garde pas les anciennes statistiques, d'un coup sur l'autre, ça va pas être la mort !