Discussion :

[ldiaz]

Bonsoir a tous

CentOs et Oracle 10G standard edition.

N'ayant pas le Enterrprise edition, je ne peux pas utiliser les partitions. Donc nous avons des tables super remplies... Nous voudrions degager des rows pour alleger les requêtes.

Mais, vue que la base est en production es les tables en question sont soumises a des updates, insert et select perpetuel (OTLP), je me demande quelle est la meilleur solution.
J'ai pensé a celles ci:

1 creer una table _hist et laisser dans la table master les 2 dernieres années. Dans la table _hist tout le reste.
le probleme c'est que le delete est telement couteux que ça va penaliser le fonctionnement. (j'ai aucune fenêtre d'arrêt).

par ailleurs apres le delete j'ai des blocks asignés mais vide, donc je dois utiliser dbms_redefinition, mais je perds les index pendant le procesus et la c'est la catastrophe.

2 Au lieu de faire une table _hist j'ai pensé a creer une nouvelle table avec les 2 dernieres années, creer les index et a la fin faire un RENAME

rename tableA to tablaA_orig
rename table_TMP to tablaA

mais voila, pendant le rename, j'ai peur ... si pile a ce moment une transaction fait un insert ou un delete.

Et puis j'ai pensé utiliser un synonym, faire pointer le synonym a l'autre table lorsqu'elle est prete.

Qu'en pensez vous?

D'avance merci

[Pomalaix]

Il y a une incohérence dans ce que vous dites, car DBMS_REDEFINITION n'est pas disponible avec l'édition standard.

Cependant, il n'y a aucune raison de perdre les index.
Ou alors c'est que vous oubliez d'appeler la procédure COPY_TABLE_DEPENDENTS, qui se charge justement de transférer tous les objets rattachés à la table : index, contraintes, déclencheurs...

[ldiaz]

Bonjour
a oui c'est possible car cet appel je ne l'ai pas dans la liste des commandes que je passe avec dbms_redefinition.
Bien que comme je disais, cette voie est sans issue car le delete est trop massif et boque l'application. Je pourrais faire par tranche de 6 mois pour reduire les deletes, mais vue qu'il y a 15 tables a traiter, je vais jamais finir, d'autant qu'il faut que les delete soient coherent (pk / fk).

Que pensez - vous du synonym?

[ORA-007]

Peut etre que la solution est dans le Delete même.

vous devez surement faire qq chose du genre :

Code :

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

DELETE matable where date < add_months(sysdate,-24);

Plusieurs points :

le champ date est il indexé ? les stats sont elles à jour ?

le champ date est il bien au format date ? et nom pas stocké dans un varchar ce qui entraînerait des conversions implicites.

présence de delete cascade ?

présence de trigger before / after delete ?

[ldiaz]

Bonjouor ORA-007

oui je fait le delete de cette façon. Le champs est indexé, y'a des stats, mais le scripts efface presque 3 millons de lignes et malgré l'index ça bloque l'application.
C'est pourquoi j'avais pensé ... au lieu de faire un delete, l'idée est de creer une table nouvelle tableA_N avec la quantité de données ideal, creer ses indexes et a la fin faire 2 rename.
Mon doute est: que peux il se passer pendant les 3 ou 4 segondes que durent les 2 rename ?

[skuatamad]

Le problème n'est pas que lors du RENAME, il est surtout pendant la création de la table + réindexation car toutes les données insérées/modifiées pendant ce temps ne seront pas présentent dans la nouvelle table, d'où l'intérêt du package DBMS_REDEFINITION.

Sinon vous n'avez pas répondu à 2 des questions d'ORA-007, y a t'il du ON DELETE CASCADE et/ou des triggers (spécialement les for each row) ?

J'en rajouterais une, est ce que les FK sont toutes indexées ?
A lire à ce sujet Unindexed Foreign Keys

[ldiaz]

Bonsoir,
oui pardon... Je complete l'information, dans le script il n'y pas de delete cascade ni de triggers.

La question que tu ajoute a propos des FK, je dois valider car la je n'ai pas l'info sous les yeux.
Par rapport aux données qui vont s'inserer pendant le traitement, je peux faire un select dans la table master_orig qui ont une date > a la plus haute date de la nouvelle table... Je crois que ça devrait suffire comme mesure.

Que ce passe t'il si pendant le rename ? si la table est lockée par une transaction de update ou insert, le rename se declenche au commit?

D'avance merci a tous pour votre aide.