Performance insertion dans une table partitionnée

[regal]

Nous disposons d'une table partitionnée (une partition par mois comptable).
Sur cette table sont définis des index bitmap eux aussi partitionnés.
Des requêtes d'insertion (via l'ETL datastage) dont la performance est généralement de 160 rows/sec environ se retrouvent à tourner à 1 à 3 rows/sec.
Sur un volume de 200000 lignes à insérer, après environ 15000 lignes traitées nous obtenons une erreur :
ORA-30036: impossible d'étendre le segment par 4 dans le tablespace d'annulation 'UNDO'.
L'insertion s'arrête car l'outil est paramétré pour sortir au bout de 50 erreurs.

Les insertions dans la partition précédente (reliquat des données de mars) se passent sans problème.

Nous avons déjà eu ce problème auparavant et nous l'avions résolu en sauvegardant les données de la partition courante en la recréant, et en y insérant à nouveau les données.
De plus nous avions rejoué le rafraichissement des statistiques sur la partition.
Cette erreur nous était arrivée une fois par an environ, mais cela fait 2 mois de suite que cela se produit sur une partition contenant encore peu de données.

Quelle peut-être la cause de ce problème ? Logicielle ? Matérielle (problème lié au disque ?)
Peut-il être résolu sans suppression et nouvelle création de la partition ? Est-ce que par exemple rejouer les statistiques et la reconstruction des partitions d'index peu suffire ?

Pour info nous avons :
112 partitions pour notre table
29 index bitmap sur cette table ayant chacun aussi 112 partitions
Nous fonctionnons sous oracle 9.2.0.8

[scheu]

Envoyé par regal

ORA-30036: impossible d'étendre le segment par 4 dans le tablespace d'annulation 'UNDO'.

Essaie de faire des commits intermédiaires ou augmente la taille du tablespace UNDO, ton problème n'a apparemment rien à voir avec le partitionnement, c'est jusque que le volume que tu insères est trop grand pour tenir dans le UNDO

[regal]

Envoyé par scheu

Essaie de faire des commits intermédiaires ou augmente la taille du tablespace UNDO, ton problème n'a apparemment rien à voir avec le partitionnement, c'est jusque que le volume que tu insères est trop grand pour tenir dans le UNDO

Le problème ne semble pas là car le même nombre de lignes à insérer a déjà été traité sans problème les mois précédents.
Pour le mois précédent, une fois la partition reconstruite, le chargement du même volume de ligne s'est déroulé correctement.
Important : le ralentissement s'observe aussi avec un faible nombre de lignes à traiter (44 minutes pour insérer 9760 lignes le jour ou le problème est apparu contre 9 minutes pour 59500 lignes la veille pour le même job datastage).
La reconstruction de la partition n'a pas corrigé le problème. Le mois dernier, nous avons cependant dû la reconstruire 2 fois - en la créant dans un tablespace différent la seconde fois - sans être certains qu'il y ait le moindre impact concernant ce changement de tablespace.
Nous créons les partitions dans 3 tablespaces de façon circulaire, pour ce mois-ci ce n'est pas le même que pour le mois dernier.

[orafrance]

C'est pas la taille de données mais celle des extents qui importe. Si tes tablespaces sont en AUTOALLOCATE plutot qu'UNIFORM SIZE alors la taille du NEXT est variable.

[regal]

Une précision : nous avons 3 tablespaces data_xl_1, data_xl_2 et data_xl_3.
Nous avons comme le mois dernier forcé la création de la partition dans data_xl_2 et cela fonctionne.
Il apparait donc que si la partition est dans data_xl_1 ou data_xl_3 l'insertion est très ralentie et non dans data_xl_2.
Un agrandissement des file systems et l'ajout d'un fichier .dbf aux tablespaces avait été effectué mi-février donc juste avant que le problème ne survienne.
Il semble - je ne sais pour quelle raison - que le fichier additionnel ne soit pas utilisé sur le tablespace data_xl_2.
Est-ce que un tablespace créé sur 2 fichiers peut poser problème avec ora9208 - en particulier pour des tables partitionnées ?

PS : les années précédentes quand le problème était apparu, cela faisait suite à une suppression massive de données, ce qui n'est pas le cas cette fois.

[lmartin]

Proposition de distribution de tes partitions :

une partition/tablespace/mois, chacun de tes tablespaces aura une extension uniforme et tu peux générer un ensemble de tablespace en fin d'année pour l'année suivante. Tu initialise les stats par partition et calcul les stats globales mensuellement.
Tu auras une qualité de distribution de tes données condensée, une lecture plus claire de l'évolution de ta volumétrie (fameux "capacity planning" à la mode).
Les temps d'attentes sur un fichier t'indiqueront directement quel objet est en lecture/écriture.
Tu gagneras aussi en souplesse de maintenance. Par exemple tu peux passer en READ ONLY,par le biais des tablespaces, tes données comptables qui ne doivent plus évoluer.

Pour ton problème de perf après suppression massive de données, je mettrais ça sur le compte des allocations non uniformes transformant tes fichiers dbf en gruyère après suppression.

[salim11]

Envoyé par regal

Sur cette table sont définis des index bitmap eux aussi partitionnés.

Je pense que l'utilisation de l'index bitmap est mal placée dans une table qui change (insert, update) fréquemment
Un index bitmap : gèle les autres sessions au moment de l'insert ou l'update