Discussion :

[gaboo_bl]

Bonjour,

Je suis en train de réécrire un traitement et je me pose des questions auxquelles je ne trouve pas de réponse. La problématique est la suivante :

- J'ai un vieux traitement qui utilise des tables de travail, sous la forme de tables "normales" qu'il drop à chaque début de traitement et recrée à l'aide d'insert..select. Ce traitement ajoute des indexes sur ces tables et calcule des stats à l'aide d'analyze. A la fin il fait un spool d'une requête basée sur ces tables de travail.
- J'ai remarqué qu'en dehors de ce traitement, les tables en question ne sont utilisées nulle part, j'ai décider de remplacer ces tables par des global temporary table. J'ai par contre conservé les indexes.

Mes questions sont les suivantes : Est ce que mes indexes vont être utilisés quand ce sera judicieux? Est ce qu'il faut que je conserve mes calculs de stats dans le traitement, car j'ai cru comprendre que les stats sont calculées automatiquement quand elles sont manquantes. En fait je vois mal comment oracle se débrouille pour les stats sur les tables temporaires, vu que logiquement chaque session voit ses propres données mais pas les autres.

merci de votre aide.

Edit: j'ai oublié de préciser, je suis sur 10g

[pifor]

Quelques éléments de réponse dans la section "Query Plans with Temporary Tables" de l'article http://www.oracle.com/technology/ora...o54asktom.html qui concerne 9.2 et 10.1.

En résumé: Oracle calcule les statistiques avec du dynamic sampling càd qui est exécuté à la volée lors de la compilation de la requête. Mais vous pouvez également utiliser DBMS_STATS pour les coder en dur si nécessaire.

[gaboo_bl]

Merci pifor çà répond tout à fait à ma question.

[Severn]

Le calcul des stats semble agir sur l'optimiseur pour des tables temporaires.

En 10.2.4, en testant l'option DELETE ROWS, le lancement de l'analyse produit un commit et donc vide la table, ce qui n'est pas le but recherché.

Un test fait avec l'option PRESERVE ROWS permet d'utiliser (ou non) l'index.
- Sans stats, le mode rule est utilisé, ou bien du dynamic sampling si jointure avec une table non temporaire.
- Avec stats, j'obtiens dans les 2 cas des plans sans dynamic sampling.

Donc logiquement l'analyse permet d'orienter le plan d'exécution même sur une global temporary table.
Cependant en cherchant à optimiser dans ce sens, tu prends le risque de changer un plan et un mécanisme peut-être déjà prévu pour une table non temporaire.
Es tu sûr qu'il n'y a vraiment pas des traitements annexes qui se basent sur cette table (monitoring, audit fonctionnel, etc) ?
En cas de plantage ou d'arrêt du traitement utilisant cette table, la perte les données insérées peut aussi poser pour l'analyse du problème et l'éventuelle reprise du traitement.
De plus, je crois que les options de flashback ne sont pas possible pour ce type de tables.

edit: le temps de faire le test, pifor a apporté une réponse donumentée.