Discussion :

[zidane2012]

Bonjour
J’ai une application développé en Oracle Forms.
L’utilisateur après avoir rempli quelques champs dans l’interface (IHM) clique sur un bouton pour lancer un traitement lourd et complexe qui prend 3 heures.
Ce traitement fait appel à plusieurs procédures/packages PL/SQL afin d’effectuer des déchargements et chargements de plusieurs tables volumineuses (truncate , insert , update , merge et delete ...).
Afin de mettre en place un calcul de statistiques 11gR2 permettant d’optimiser ce traitement complexe existe-t-il une méthode permettant de savoir à quel moment dois-je calculer les statistiques ?
J’ai pensé à la table DBA_TAB_MODIFICATIONS en mettant chaque table ( 1200 tables ! ) en mode monitoring ? puis exécuter FLUSH_DATABASE_MONITORING_INFO à la fin du traitement ?
Autre question : comment initialiser cette table DBA_TAB_MODIFICATIONS avant de lancer mon traitement ? un simple delete / truncate ?
L’objectif est de trouver une méthode pratique permettant d’auditer le cycle de vie des données avant , pendant et après ce traitement.
Peut-être c’est une fausse piste …
Merci pour votre retour
Z.

[mnitu]

Faite un profilage du traitement pour trouver où le temps passe et surtout dans quelles proportions. Vous allez pouvoir identifier ainsi les parties du traitement qui sont susceptibles d’être optimisés et qui apportèrent un gain du temps important.

[rouardg]

Bonjour,

On n'initialise pas la table DBA_TAB_MODIFICATIONS !

Cette table est automatiquement remplie par Oracle, parce que vos tables sont en monitoring. Elle est alors plus ou moins remplie en fonction de l'activité (INSERT, UPDATE, DELETE et TRUNCATE) que subissent vos tables.

Toute cette activité est en mémoire, et Oracle l'écrit de temps en temps dans cette table. Effectivement, vous pouvez appeler la procédure FLUSH_DATABASE_MONITORING_INFO du package DBMS_STATS pour forcer cette écriture.

On n'efface pas non plus cette table. Cette table est en fait automatiquement effacée, table par table, lorsque les statistiques de la table sont recalculées.

N'oublier pas que les statistiques sont calculées automatiquement par Oracle, la nuit. Oracle compare, table par table, l'activité qui est dans DBA_TAB_MODIFICATIONS avec les dernières statistiques de chaque table. Si celle-ci varie de + ou - 10 %, alors Oracle recalcule les stats.

Pour votre pb de packages PL/SQL, vous semblez partir bille en tête sur les statistiques. Moi jaurai tendance à dire qu'il faut regarder le pb de manière plus globale, à savoir identifier les traitements qui prennent du temps dans votre code, et voir ensuite d'où viennent ces pb.

Cela peut être un pb de conception du code, de modélisation de la base, d'écriture de code SQL et PL/SQL, d'indexation ou autre.

Cela peut aussi être un pb de stats. En règle général, dans un batch, ou avant un batch, on recalcule les stats sur les tables qui en ont vraiment besoin, à savoir quand le volume de données peut varier significativement, ou bien lorsque les données ne sont pas uniformes, et que l'on a besoin des histogrammes en plus des statistiques.

[pachot]

Bonjour,

Afin de mettre en place un calcul de statistiques 11gR2 permettant d’optimiser ce traitement complexe existe-t-il une méthode permettant de savoir à quel moment dois-je calculer les statistiques ?

Tant que le volume des tables est très fluctuant, il faut mieux ne pas avoir de statistiques -> dynamic sampling
Puis dès qu'une table est chargée avec ses données définitives, calcul de stats.

Cordialement,
Franck.

[zidane2012]

Bonjour ,

Tant que le volume des tables est très fluctuant, il faut mieux ne pas avoir de statistiques -> dynamic sampling
Puis dès qu'une table est chargée avec ses données définitives, calcul de stats.

Est-il possible de combiner les 2 techniques dans le même traitement ?
En terme de % combien dure l'échantionage dans le dynamic sampling (level 10 par exemple ) par rapport au temps global d'une requête ?

A ma connaissance le dynamic sampling exige 2 conditions :
- Données volatiles.
- Temps d'exécution des requêtes ( > 2 à 3 min) ?
Non recommandé pour les requêtes instantanées ?
Or mon traitement contient des requêtes instantanées et des requêtes qui prennent 30 min aussi ...

Z.

[pachot]

Bonjour,

- Temps d'exécution des requêtes ( > 2 à 3 min) ?

Non. dynamic sampling prend un peu plus de temps au parse, pas à l'exécution. Si on a des requêtes qui on un temps d'exécution 'instantané' elles sont probablement parsées (hard parse) une fois pour être exécutées de nombreuses fois. Et ces requêtes rapides ne devraient pas avoir besoin d'un dynamic sampling important. Si elles sont si rapides, le plan d'exécution est probablement simple.

Est-il possible de combiner les 2 techniques dans le même traitement ?

Oui: calculer des stats pour les tables qui ont un volume fixe. Supprimer les stats pour celles qui ont un volume variable puis calculer les stats dès qu'elles ont atteint leur volume.

Cordialement,
Franck.

[zidane2012]

Bonjour , Je ne connais pas trop le fonctionnel de l'application et le cycle de vie des données. Est-il possible d'utiliser des méthodes techniques (DBA_TAB_MODIFICATIONS par exemple ou autre ?) pour lister les tables ayant des données volatiles et les tables ayant des données quasi-statiques ? Dois-je obligatoirement voir cela avec la maîtrise d'ouvrage.et/ou en regardant le code de l'application ... ? merci Z.

[pachot]

Dois-je obligatoirement voir cela avec la maîtrise d'ouvrage.et/ou en regardant le code de l'application

Oui !