Discussion :

[Le-DOC]

Bonjour,

Je dois effectuer une purge de plusieurs tables imbriquées les une dans les autres avec des delete cascade.
la table principale n'a que 200 000 lignes a supprimer, mais avec les cascade, ça m'en fait plusieurs millions a supprimer;

Je me pose des questions sur la méthode a utiliser.

1° - Basculer la bases en noarchivelogs
- Isoler un rollback segment pour n'en faire gonfler qu'un seul
- Delete morceau par morceau
- Reorg de mes tables restantes pour recuperer l'espace

2° - Bourrain:
- Datapump global
- Drop des tables
- Import avec Query (mais ça fait peur, c'est la production)

3° - le CTAS, mais j'ai une centaine de tables a créer alors :/

Quelqu'un aurai une idée ?
Merci

[Fabien Celaia]

1. C'est en production... donc c'est le seul point noir du mode noarchivelog... Mais si vous partez sur un déni de service (faut rebooter la base pour changer le mode d'archivelog), ca va grandement accélérer vos deletes.
2. Si vous avez une vision claire de ce qui doit être détruit (le schéma et l'ordre des deletes), le faire par petits bouts peut être moins intrusif
3. Le mode datapump, je n'y crois pas trop... et qcroyez bien que je suis un féru de DP.
4. Comment sont gérés vos cascades ? via déclencheurs ? en déclaratif ?

[Le-DOC]

Bonjour,

1/ L'interruption de service sera prévue.
Donc pas de probleme pour basculer en mode NOARCHIVELOG, puis remettre en ARCHIVELOG une fois la purge terminée.

2/ J'avais pensé le faire petit bout par petit bout, soit via un module pour fragmenter les ordres en parties égale, soit mois par mois, mais les rollback segments gonflent assez rapidement. 10G/2h de trt pour 1 annee. Dans tous les cas, les cascades impliquent plus de 90 tables.

4/ Les cascades sont gérés déclarativement, et impliquent la cohérence des données.

De plus faudra que je fasse une reorg pour boucher le trou béant que je vais faire dans la base. Indisponibilité supplémentaire.