Discussion :

[palver]

Bonjour,

J'effectue des tests de performance sur une une table avec une colonne XMLTYPE.

J'ai effectué plusieurs insertions de buffers de taille variant de 1ko à 30Mo mais je constate que le delete (dans le cas d'une purge ciblée) est extrèmement lent (sur un échantillon de 200 inserts avec :

- 30% à 1Mo
- 30% à 5Mo
- 15% à 7 Mo
- 10% à 10 Mo
- 5% à 30 Mo
)

J'obtiens un temps de delete de plus de 10h et j'avoue que je manque de billes sur l'explication sur ces performances désolantes.

Auriez-vous des pistes sur l'origine du problème et des moyens d'optimiser le traitement ?

Merci d'avance.

[orafrance]

t'aurais pas un trigger sur le DELETE par hasard ou une contrainte avec DELETE CASCADE ? Sinon, fait une trace, tu seras fixé sur ce qu'il attend

[Vincent Rogier]

XMLTYPE est un type de donnée très lent (que ce soit les fonctions les manipulants ou même sur les DML)

Si le delete opère une sélectivité sur le contenu du champs XMLTYPE, je ne suis pas étonné du résultat sur de gros contenus...

[palver]

Rebonjour,

Désolé pour le délai...
En fait la selection des tuples à supprimer est basé sur la clé primaire donc pas d'accès au contenu.
Il semblerait que le délai de suppression soit liée aux nombre de blocs de données à supprimer (la suppression d'un contenu de 10Mo ou de 10x1Mo est sensiblement identique).

Comme nous avons un certains nombre d'indexs couteux à rebuilder positionné sur le contenu xmltype, il n'est pas génial de les dropper et les remettre une fois la suppression terminée (quoique c'est pour l'instant la solution conservée puisqu'il est toujours moins couteux de le faire que de ne juste faire les delete...).

Quelle plaie

Prochain test : analyse de la modification de la taille des blocs sur les délais.