Discussion :

[sygale]

Bonjour,

je dois faire des grosses modifications (delete from tb where ...)sur une tables (plusieurs Go de donée à supprimer).

Je suis sûr de mes modifications, je voudrais savoir si je mets le tablespace undo offline cela gargnera du temps lors de modification ?

Code :

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

1
2
3
select 'ALTER TABLESPACE '||tablespace_name || ' OFFLINE;' 
from dba_tablespaces
where contents = 'UNDO'

[NGasparotto]

Ca ne marchera pas.
La suppression de plusieurs millions de lignes doit avoir une autre issue (par ex. create table as select..., drop la table source, rename de la nouvelle table).

Nicolas.

[Harry Potter]

Ou alors passe par une petite procédure stockée crée pour l'occasion qui va te permettre de faire un loop dans lequel tu vas deleter tes lignes par paquets (mettons par paquets de 3000) enchaîné avec un commit, une vérification du fait qu'il reste des lignes à supprimer (sinon exit) et le tour est joué. La

[Harry Potter]

Ou alors passe par une petite procédure stockée crée pour l'occasion qui va te permettre de faire un loop dans lequel tu vas deleter tes lignes par paquets (mettons par paquets de 3000) enchaîné avec un commit, une vérification du fait qu'il reste des lignes à supprimer (sinon exit) et le tour est joué.

La seule chose délicate est de choisir le bon tempo de commit

[NGasparotto]

Ou alors passe par une petite procédure stockée crée pour l'occasion ...

Il y a de forte chance qu'une procédure stockée ne soit pas plus rapide qu'un simple sql d'update.

Nicolas.

[pifor]

De plus, augmenter le nombre de COMMIT tend en général à dégrader les performances.

[Harry Potter]

NGasparotto a écrit :
Il y a de forte chance qu'une procédure stockée ne soit pas plus rapide qu'un simple sql d'update.

Je ne vois pas bien le rapport avec le problème, un simple sql d'update sur des millions de lignes va exploser le undo, alors qu'une procédure stockée qui va faire la même chose chose mais disons par paquets de 2000 lignes va permettre de faire l'opération.

[sygale]

De plus, augmenter le nombre de COMMIT tend en général à dégrader les performances.

Je suis d'accord, comme je souhaite supprimer 70 % de la table, je vais donc
- créer une table de 30% des données à garder
- truncate de la table
- insert des 30 %

je pense que cela sera la solution la moins couteuse

Merci en tout cas pour vos aides

[Harry Potter]

pifor a écrit :
De plus, augmenter le nombre de COMMIT tend en général à dégrader les performances.

Quand au fait d'augmenter le nombre de commit, c'est un peu plus fin que ça, si on part d'un commit toute les lignes et qu'on augmente la valeur de celui-ci on va avoir un gain qui se met à stagner pour redescend (grosso modo) => il faut trouver la bonne valeur

[Harry Potter]

Attention à l'insert des 30 % !

[NGasparotto]

Je ne vois pas bien le rapport avec le problème, un simple sql d'update sur des millions de lignes va exploser le undo, alors qu'une procédure stockée qui va faire la même chose chose mais disons par paquets de 2000 lignes va permettre de faire l'opération.

Ben le problème ici n'est pas les undo mais les performances, pour rappel le premier post :

je voudrais savoir si je mets le tablespace undo offline cela gargnera du temps lors de modification ?

Nicolas.

[sygale]

pour info
table T1 33 millions de lignes, nous gardons 9 millions de lignes

- create table 30% = 10 min
- truncate table T1 drop storage = 1 min
- drop index table T1 = 1 min
- insert into T1 des 30 % (découpé en 500 000 lignes max avec commit) = 1h30
- create index T1 = 25 min
- analyze T1 et ses index = 10 min

environ 2h20 de traitements mais cela fonctionne !!

[NGasparotto]

pour info
table T1 33 millions de lignes, nous gardons 9 millions de lignes

- create table 30% = 10 min
- truncate table T1 drop storage = 1 min
- drop index table T1 = 1 min
- insert into T1 des 30 % (découpé en 500 000 lignes max avec commit) = 1h30
- create index T1 = 25 min
- analyze T1 et ses index = 10 min

environ 2h20 de traitements mais cela fonctionne !!

Est-ce une possiblité de dropper la table d'origine et de renommer la table venant d'être créée avec les 30% (tu économiserais l'insertion) ?

Nicolas.

[orafrance]

En créant des temporary tables tu peux gagner pas mal de temps aussi

Sinon, export avec l'option query et imp