Discussion :

[Invité]

Bonjour,

Nous avons dans notre base une table sur laquelle ont été définis des index bitmap. Jusque ce jour la mise à jour de cette table se fait 2 fois par mois : une fois par un calcul provisoire qui insère des données, une seconde par un calcul définitif consistant à supprimer les données provisoire du mois correspondant puis à les recalculer. Ce fonctionnement ne pose pas de problème.
Nous mettons en place un mécanisme de purge basé sur un critère de date. Cette purge au premier lancement, supprime les données sur plusieurs années. Une fois la purge jouée dans l'environnement de recette, la procédure de suppression puis ré-insertion de données s'est traduite par une erreur :

ORA-01654 : impossible d'étendre l'index ... dans le tablespace ...

Afin de libérer de la place nous avons reconstruit l'ensemble des index bitmap par la commande

alter index ... rebuild.

L'espace libre passe alors de 2,6% à 73%.
Hélas, la relance de l'insertion provoque à nouveau la même erreur ORA-01654.
Sur notre serveur de développement nous observons le même comportement : l'insertion entraine un accroissement exponentiel des index bitmap (avec ou non l'erreur ORA-01654 selon le mois de données choisi).

Pourquoi une opération d'insertion de données qui fonctionnait avant la purge massive et/ou le rebuild ne fonctionnerait plus ensuite ?

Quelles solutions pouvons-nous mettre en place ?

[ORA-007]

Bonjour,

Les index et tables sont sur les mêmes tablespaces ?

Sinon, je pense que ton problème porte un nom : high water mark

mais je me trompe peut être, à faire confirmer.

Cordialement. GM.

[Invité]

Les index et les tables sont dans des tablespaces distincts.

[ORA-007]

ce topic peut t'aider je pense :

par ici

cordialement, GM

[Invité]

J'ai supprimé puis reconstruit les index bitmap et j'ai toujours le même problème.
Pour info :
notre procédure insère les nouveaux enregistrements ligne par ligne (et effectue aussi des update sur ceux-ci).
Un test d'insertion en bloc à partir d'une table de sauvegarde

Code :

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

insert into table1 select * from table2 where condition

ne provoque pas d'extension abusive des index bitmap. La condition porte sur les données d'un mois de façon à avoir un volume de données du même ordre de grandeur que celui inséré par la procédure de calcul.

[Invité]

Suite à mes tests quelques informations supplémentaires :
j'ai effectué dans notre environnement de développement un truncate de la table puis ré-inséré des données en jouant en boucle la procédure de calcul qui alimente la table : aucun problème de saturation. J'ai effectué différentes purges suivies de calcul et n'observe qu'une très légére augmentation de la taille des index.
J'ai alors effectué un rebuild de l'index : suite à ce rebuild une insertion ligne par ligne par la procédure est très ralentie par rapport à la même insertion avant rebuild et la taille des index croit exponentiellement.

On observe donc qu'un rebuild d'index au lieu d'améliorer le comportement le dégrade complétement.