Discussion :

[mnitu]

Si par exemple pour la table 2 cela prends bien moins de 1027 seconds oui.

[Zidmann]

Bonjour,

Comme l'insertion de chaque table durait moins de 1027 secondes, j'ai suivi vos conseils et j'ai détruit les indexes, insérait les informations puis régénérait les indexes. Malheureusement, cela prend plus de temps que de réaliser les insertions elles-mêmes.

Si cela vous intéresses, je vous transmettrai le détail des durées mardi en revenant travailler.
Est-ce que vous auriez d'autres pistes à me proposer ?

Merci d'avance de vos commentaires.

Zidmann

[mnitu]

C’était la reconstruction des indexes qui devrait durer moins de 1027 secondes. Avez vous reconstruit les indexes en parallèle ?

Si vous avez assez des ressources sur la machine je pense que vous devez essayer d’appliquer l’exécution en parallèle et le direct path load en désactivant les contraintes de type clé étrangère. Pour chaque méthode que vous utilisez, vous devez faire une trace étendue et chaque fois analyser les événements d’attente pour comprendre où ça coince.

[Zidmann]

Bonjour,

Je ne crois pas avoir recontruit les indexs de mémoires en parrallèle. Il faudra que je regarde si j'ai un gain ou pas en utilisant plusieurs CPUs.

Qu'est-ce que vous entendez par trace entendue ?
Est-ce que ce terme désigne le fichier brut de trace SQL ?

Zidmann

[mnitu]

...
Qu'est-ce que vous entendez par trace entendue ?
...

C'est une trace SQL qui inclut les événements d'attente.
Si vous tracez avec la commande

Code :

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

1
2
 
alter session set sql_trace = true;

ces événements ne sont pas présents. Pour les inclure vous devez tracer avec l'événement 10046 ou via le package dbms_monitor, etc.

[Zidmann]

Bonjour,

Bien que cette discussion n'ait pas eu de suite depuis un certain temps, j'écris la solution à mon problème dans le cas où une autre personne serait confrontée à la même situation.

En analysant le fichier de trace brut (avant de le simplifier avec Tkprof), j'ai observé les actions de mes deux insertions consécutives. J'ai découvert que lors de l'insertion, Oracle passait son temps à insérer peu de lignes dans chaque block comme il y avait peu de lignes consécutives qui allaient dans la même partition. Ainsi Oracle perd son à sauter d'un block à l'autre en changeant frequemment de partition d'arrivée.

Pour y remédier, j'ai rajouté un ORDER BY à ma requête sur le champ définissant le partitionnement. Ainsi en triant au préalable ma table pour rassembler les lignes destinées aux mêmes partitions, j'ai économisé 70% de ma durée d'exécution en diminuant de 50% la durée CPU et de 80% la durée des Wait Event.

Voilà c'était très simple mais il m'a fallu du temps avant de bien comprendre le problème et comment y remédier.

Cordialement,

Zidmann