Discussion :

[stepd]

Bonjour,

J'ai une base oracle en 9iR2 qui est paramétrée en mode Archivelog.

Je voudrais purger massivement les données d'une table (environ 17 millions de lignes).
Par contre cela va générer des très gros fichiers d'archivelog et du coup lorsque RMAN va passer cela va plomber les temps de réponses de la base.

Existe-t'il une option pour désactiver la création des archive logs juste pour une requête de delete ?

Merci beaucoup de votre aide.

[Oracle4Ever]

Je voudrais purger massivement les données d'une table (environ 17 millions de lignes).

C'est à dire toute la table? Tu fais une delete sans clause where?

Si tel est le cas, ce n'est pas un delete que tu dois faire mais un truncate. Il n'y aura alors aucun archivelog, cela sera rapide MAIS tu ne pourras pas faire de rollback.
Si en plus il n'y a pas de clef primaire sur cette table qui est référencée sur d'autres tables, alors je pense que c'est truncate ta solution.

[ojo77]

Bonjour

Si l'effacement est massif sans toucher toutes les lignes il est recommandé de créer la table finale par un create table as select puis créer les index sur la nouvelle table, de faire des renommages pour que la nouvelle table prenne la place de l'ancienne le tout en gérant les diverses PK/FK ...

A savoir, cette technique ne génère que très peu d'archivelog sauf si vous êtes en mode force logging (pour dataguard par exemple).

[stepd]

Effectivement je veux bien faire un delete avec une clause where portant sur des dates et donc ne pas supprimer toutes les lignes.

Je vais essayer ta solution ojo77.

Merci

[stepd]

Par contre petite question sur cette méthode, d'accord le create table as select ... va me créer ma nouvelle table sans générer beaucoup d'archivelog.
Par contre il va falloir que je DROP ma table d'origine avant de pouvoir renommer la nouvelle table.
Ce DROP va lui provoquer beaucoup d'archivelog ?

[Oracle4Ever]

Le DROP ne génère pas d'archivelog, c'est une commande DDL. Elle est immédiate et sans retour arrière possible par rollback.

Attention prévoir donc a un instant T la table n'existera plus le temps de renommer la nouvelle avec l'ancien nom (je dis ça si il y a une application connecté)

Aussi à prévoir avant le DROP de récupérer les droits de l'ancienne table qui va être supprimée pour savoir quel droit il faut remettre.

[alexisongagna]

Bonjour,

Si les archivelog posent un problème de volume, tu peux encore les désactiver le temps de ta purge. Dans l'ordre les étapes à réaliser :

1. shutdown immediate
2. startup mount
3. alter database noarchivelog;
4. alter database open;
5. CREATE TABLE TAB_TMP as SELECT ... FROM <tab_à_purger>;
6. DROP TABLE <tab_à_purger>;
7. ALTER TABLE TAB_TMP rename to <tab_à_purger>;
8. Tu remets tous les grants, synonymes et index éventuels
9. Refaire les étapes 1. et 2.
10. Tu remets le mode archivelog : alter database archivelog;
11. alter database open;

Bien évidemment, en production il va falloir te synchroniser avec ton DBA de prod le jour de la mise en production de ce traitement one shot.

Bon courage

[Heaven93]

bonsoir
avec une sauvegarde avant la désactivation des archivelogs précédant l'opération et une après si ça s'est bien passé, c'est plus sûr