Discussion :

[Ikebukuro]

Hello le forum!

Nous avons une table qui est vide puis remplie par un Insert As Select avant d'être entièrement vidée par un delete une fois les traitements effectués. Selon les tests des users, le delete prends trop de temps (quelques minutes sans que j'aie la volumétrie de la table). Une solution rapide a été de faire un Truncate, ce qui a parait-il grandement amélioré la situation MAIS de façon temporaire : le problème est revenu.

Nous cherchons une solution définitive et j'ai proposé d'utiliser une table temporaire pour faire l'insert, sans le delete car Oracle fait un Truncate sur la table temporaire à la fin de la session.

Un autre DBA déconseille TRES fortement l'utilisation des tables temporaires sous prétexte qu'Oracle les gérerait très mal mais sans avancer de preuves

Pouvez-vous me dire si effectivement les tables temporaires sont à éviter ou bien si c'était vrai par le passé et plus aujourd'hui?

Par avance merci pour vos conseils.

[Ikebukuro]

Personne n'a d'idée

[McM]

J'avais commencé à répondre, sans aller au bout.

Je ne vois aucune raison de ne pas utiliser de table temporaire pour ton cas (sauf peut être une volumétrie excessive).
Le truc à savoir c'est que les GTT vont dans le TEMP (donc tu peux le remplir s'il est trop petit)

Petit lien récap des GTT https://oracle-base.com/articles/misc/temporary-tables

Pour les problèmes de perf, il aurait fallu voir l'évolution de la volumétrie de la table, ainsi que du nombre d'Insert/delete appliqués.

J'utilise assez souvent des GTT sans jamais avoir eu de souci.

[mnitu]

Le seul argument contre l'utilisation des tables temporaires est que souvent elle ne servent à rien sauf à alourdir le traitement en question. Mais comme cela fait partie des mauvaise habitudes des programmation les plus répandues...
Demandez à DBA en question pourquoi ou en quoi Oracle gère mal ce type de tables. Si il n'a pas des arguments cela dit clairement qu'il n'as pas compris de quoi il parle!
Ce type de table est apparue dans Oracle spécialement pour répondre aux problèmes que vous signalez!

[Ikebukuro]

Merci beaucoup les gars, vous êtes une fois de plus d'excellent conseil.

L'autre DBA ne m'a pas donné d'arguments mais comme il est plus expérimenté que moi je n'ai pas voulu mettre en doute publiquement ses propos.

En tout cas je suis rassuré car en allant sur le Net j'avais bien identifié cet objet comme une solution à nos problèmes.

[Pomalaix]

Il y a un critère pratique à prendre en compte avant même de se préoccuper des performances : les données stockées dans cette table temporaire ont-elles besoin d'être accédées par plusieurs sessions ? Si oui, on abandonne, vu que les données dans une telle table sont propres à la session, et ne peuvent pas être partagées.

Côté performances, les tables temporaires sont censées être gagnantes notamment grâce au fait qu'elles génèrent considérablement moins de journalisation REDO que les tables ordinaires.
On leur reproche parfois des "problèmes" de statistiques, mais à vrai dire de ce point de vue elles ne se distinguent pas d'une table ordinaire qu'on viendrait de créer et d'alimenter.
On peut alors ne pas calculer les statistiques et laisser l'échantillonnage dynamique opérer, ou bien calculer les statistiques normalement (GATHER_TABLE_STATS), ou encore introduire des statistiques en dur (SET_TABLE_STATS), et pourquoi pas les verrouiller (LOCK_TABLE_STATS).

[pachot]

Bonjour,

L'autre DBA ne m'a pas donné d'arguments mais comme il est plus expérimenté que moi je n'ai pas voulu mettre en doute publiquement ses propos.

... tu as bien fait. Balancer un 'oracle le gère mal' sans préciser le contexte, la version et la raison suffit à mettre en doute ces propos

Sur des domaines qui évoluent si vite comme l'IT c'est les gens qui se posent des questions qui sont les plus expérimentés, pas ceux qui se basent sur des idées préconçues. Donc tu es du bon côté.

Du moment que les données n'ont pas à être persistées au delà de la session, et n'ont pas à être vues par les autres session, les GTT sont la bonne réponse. Si tu est en 12c tu peux mettre temp_undo_enabled=true;

Seul inconvénient des GTT: si un traitement plante au milieu tu ne pourras pas voir dans quel état étaient les donnés, ce qui aurait pu aider au débogage.

Mais je suis quand même étonné du côté temporaire de l'amélioration avec truncate. Le truncate est immédiat, non?
Une première chose à faire c'est TRUNCATE au lieu de delete et INSERT /*+ append */ au lieu d'insert conventionnels. Ensuite, passer aux GTT avec ça.


Cordialement,
Franck.