Discussion :

[iSylvain]

Bonjour,

Je travaille sur une application qui utilise Oracle 9.2.0.8.
Fin novembre 2008, le calcul des statistiques a été désactivé sur cette application car il était trop long.
Nous avons réactivé ce calcul de stats ce WE.
Durant cette période, nous n'avons pas remarqué de gros changement au niveau des temps de traitements.

Par contre depuis ce WE que le stats ont été remise en place un traitement qui mettait environ 5min avant tourne maintenant en plus de 300min. La seule chose qui a changé est le calcul de statistique.

Voici la facon dont on calcul les stats :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
DBMS_STATS.GATHER_TABLE_STATS(ownname => NULL,
                                  tabname => 'MA_TABLE', 
                                  partname => NULL,                                   estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, 
                                  block_sample => FALSE, 
                                  method_opt => 'FOR ALL COLUMNS SIZE 1', 
                                  degree => 4, 
                                  granularity => 'DEFAULT',                                   cascade => TRUE, 
                                  stattab => NULL, 
                                  statid => NULL, 
                                  statown => NULL, 
                                  no_invalidate => FALSE);

Pensez vous que les stats soit la cause de mon problème sachant qu'avant novembre elles étaient calculées toute les semaines et que nous n'avions aucun problème

Merci pour votre aide
Sylvain

[13thFloor]

Un traitement qui dure 60 fois la durée initiale ? Le plan d'exécution a dû changé.
Peux-tu les comparer ?

[iSylvain]

C'est ce que jai pensé.
Du coup j'ai regardé mais je ne peux malheureusement pas le comparer à un plan d'éxecution datant d'avant les stats car je ne l'ai pas gardé

Sylvain

[elharet]

C'est normale que le plan d'execution va changer aprés le calcul des statistiques, parce qu'il va se baser sur ces statistiques pour choisir le plan d'execution le plus optimale; et par conséquant un temps de réponse réduit, et non pas l'inverse.

[13thFloor]

Si tu connais les statistiques que tu avais lorsque l'exécution était acceptable, tu peux setter les stat pour la table et voir ce que donne le nouveau plan d'exécution.

Le problème ne se trouverait pas du coté du bind peeking ?
Je pense à une bind variable qui ferait un full table scan quand c'est nécessaire et qui forcerait toutes les requêtes similaires, mais avec d'autres valeurs, à utiliser ce plan alors qu'un autre plan serait meilleur, tel qu'un index scan.
C'est à dire :
Nouvelles stats => invalidation des curseurs sur la table.
Donc, parsing et nouveau plan déterminé, sans doute bon pour la première exécution (une valeur trés présente dans la table => FTS).
Seconde exécution, avec une valeur peu présente dans la table (voir les cardinalité des valeurs) : un parcours par index serait optimal mais cet andouille d'optimiseur a en mémoire l'ancien plan et il l'utilise.

@elharet : ce n'est hélas pas toujours le cas. Recalcul des stats n'implique pas systématiquement meilleur temps de réponse et/ou nouveau plan.

[fatsora]

Bonjour,

Je travaille sur une application qui utilise Oracle 9.2.0.8.
Fin novembre 2008, le calcul des statistiques a été désactivé sur cette application car il était trop long.
Nous avons réactivé ce calcul de stats ce WE.
Durant cette période, nous n'avons pas remarqué de gros changement au niveau des temps de traitements.

Par contre depuis ce WE que le stats ont été remise en place un traitement qui mettait environ 5min avant tourne maintenant en plus de 300min. La seule chose qui a changé est le calcul de statistique.

Voici la facon dont on calcul les stats :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
DBMS_STATS.GATHER_TABLE_STATS(ownname => NULL,
                                  tabname => 'MA_TABLE', 
                                  partname => NULL,                                   estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, 
                                  block_sample => FALSE, 
                                  method_opt => 'FOR ALL COLUMNS SIZE 1', 
                                  degree => 4, 
                                  granularity => 'DEFAULT',                                   cascade => TRUE, 
                                  stattab => NULL, 
                                  statid => NULL, 
                                  statown => NULL, 
                                  no_invalidate => FALSE);

Pensez vous que les stats soit la cause de mon problème sachant qu'avant novembre elles étaient calculées toute les semaines et que nous n'avions aucun problème

Merci pour votre aide
Sylvain

dans la syntaxe


il faut peut etre faire cascade =>TRUE pour avoir les stats des indexes

et faire estimate_percent=>15 pour ne pas faire 100 des grosses tables

ca diminuerai le temps de collecte statistique

Code sql :

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

1
2
3
 
 
exec DBMS_STATS.GATHER_TABLE_STATS(OWNNAME => NULL, TABNAME => 'MA_TABLE', CASCADE => TRUE, ESTIMATE_PERCENT => 15,degree=>4);

ceci dit , quel est le plan actuel ?
Y a -t-il des jointures ?

le changement peut etre fait la aussi (nested loop vs hash join )

[iSylvain]

@13thFloor
A priori tu as raison !
Un DBA est intervenu pour m'aider et nous en sommes arriver à cette conclusion.
Lorsque je prenais la requête en question pour voir le plan d'exécution, il passait bien par un le bon index.
En revanche en regardant dans la vue v$sql_plan nous avons vu que le traitement qui traînait passait par un autre index qu'il n'aurait pas du utiliser dans ce cas ...

En exécutant la requête à la main, Oracle a bien repris le bon plan d'exécution. Du coup, le traitement suivant est passé sans problème en utilisant le bon plan d'exécution.

En revanche je pense qu'au prochain calcul de stat je risque d'avoir le même problème.
Je vais devoir revoir cela ...

@fatsora
Bizaremment mon copier-coller n'a pas bien fonctionné
Dans mon cas, j'avais mis le estimate _percent à AUTO_SAMPLE_SIZE.
Par contre le DBA m'a conseillé de mettre 50% pour les petites tables et 10% pour les grosses tables.
De plus nous désactivions le monitoring, ce qu'il m'a déconseillé (DBMS_STATS.ALTER_DATABASE_TAB_MONITORING).

J'ai pas mal fait de recherche sur le fonctionnement des statistiques par contre qq a t il un lien sur les bonnes pratiques et les choses à éviter ?

Encore merci pour vos réponses !
Sylvain

[fatsora]

Bonjour,

tu peux essayer ca
en plus du monitoring activé

Code :

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

exec DBMS_STATS.GATHER_SCHEMA_STATS(OWNNAME => NULL, options=>'GATHER AUTO');

avec gather auto et monitoring activé , oracle va decider d'analyser les objects (tables,index) qui ont besoin d'etre analysé : etat stale ou no stats.



cf metalink Doc ID: 237901.1

tom kytes encore lui tu tapes dbms_stats .... il y a beaucoup d'infos utiles

[iSylvain]

Ok je vais rechercher

Merci !