Discussion :

[romu92]

Bonjour,

j'ai la problématique suivante :

j'ai 2 tables Table1 et Table1_BAK de structures identiques. Dans ces tables j'ai une clé primaire sur environ 8 champs. Parmi ces 8 champs 3 se nomment MODELID, VERSIONID et PERIODID. J'ai un traitement amont (que je ne peux pas modifier) qui vide toutes les donneés de table1 pour un MODELID donné (les données des autres MODELID ne sont pas affectées) puis qui exporte des données pour plusieurs combinaisons du triplet (MODELID, VERSIONID, PERIODID). Le problème est qu'au prochain export si je ne réexpore pas les combinaisons précédemment exportées elles disparaitront de table1 alors que je dois les conserver (ce cas se présentera).


J'ai donc à mettre en place le traitement suivant :

dans Table1_BAK je supprime toutes les données des triplets (MODELID, VERSIONID, PERIODID) présents dans Table1

Je recopie les données de Table1 vers Table1_BAK en filtrant sur le MODELID

Je supprime les données dans Table1 en filtrant sur MODELID

Je recopie les données de Table1_BAK vers Table1 en filtrant sur MODELID


je dois appliquer ce traitement à une dizaine de tables comportant souvent quelques millions de lignes donc je dois optimiser ma procédure.



question 1 : le principe vous paraît-il tenir la route ou voyez-vous d'autres solutions?

question 2 : Lorsque je fais un DELETE en filtrant sur le MODELID, est-il nécessaire de désactiver des indexs (tous?) et les contraintes (toutes?) de la table en question.

question 3 : idem lors des insertions, est-ce que je dois jouer sur les contraintes et indexs pour améliorer les performances


merci pour votre aide,

Romuald

[orafrance]

1- Pourquoi tu fais pas un trigger BEFORE DELETE qui insére dans la table d'archivage ?
2- On ne peut pas désactiver un index Et sinon, surtout pas si ce sont des contraintes de type DELETE CASCADE
3- Eventuellement mais gare aux incohérences des données.

T'as pensé au partitionnement sinon ?

[romu92]

Merci pour cette réponse. En fait je travaille sur la base de données d'un éditeur, je n'ai donc pas la possibilité de modifier ses objects ORACLE. Je ne peux donc pas ajouter de TRIGGER.

Je n'ai pas de contraintes DELETE CASCADE, uniquement des contraintes d'intégrité. Comme je recopie des données déjà présentes dans des tables respectant les mêmes contraintes, je n'ai pas de risques d'incohérence de données, je m'en suis assuré.

Est-il utile que je rende mon index UNUSABLE avant mes suppression ou insertion et qu'ensuite je fasse un REBUILD?

Bizarrement lorsque j'ai les mêmes données dans TABLE1 et dans TABLE1_BAK, la suppression dans TABLE1 dure 15min et celle dans TABLE1_BAK 2min. J'ai bcp moins d'indexs sur la table BAK et surtout j'ai un trigger sur TABLE1 du type AFTER INSERT OR UPDATE FOR EACH ROW.

J'ai récemment inséré beaucoup de données dans TABLE1. Le REBUILD des indexs n'est pas suffisant? Faut-il que je joue les statistiques?

Pour être honnête je suis loin d'être un expert ORACLE, je ne connais pas le partitionnement. Si cela nécessite de modifier la structure ou les propriétés des tables existantes, je ne pourrai pas.

merci pour votre précieuse aide!

[orafrance]

Oui les indexes consomment quand tu deletes mais le REBUILD n'arrangera pas les choses. Que tu mettes l'index à jour au fil de l'eau ou après ça change pas grand chose.

[pacmann]

Salut !

Hmmm Orafrance, ça dépend du pourcentage de la table que tu traites, non ?
Romu :
Tu dois "déplacer" combien de lignes environ ?
Tes temps de traitement, ça donne quoi ?
Est-ce que tu as les bons indexes pour cibler tes lignes à supprimer ?
(c'est à dire soit en tête de clef, soit uniquement précédées de colonnes à très faible cardinalité)


Sinon, je ne sais pas trop quelle étape prend le plus de temps... mais comme tu dois effacer + insérer dans _bak, tu pourrais peut être tenter le MERGE ?