UPDATE sans redlog

**shadeoner** · 27/05/2008, 11h25

Bonjour à tous,

Je souhaite faire un update, mais il ne passe pas à cause de l'espace disque qui arrive à saturation.

Comment puis-je désactiver le redolog temporairement ?

Merci d'avance

**philcero** · 27/05/2008, 11h36

Les REDO LOGS ne consomment ni plus ni moins d'espace quelle que soit la transaction, ils restent à taille constante...

Veux-tu parler des ARCHIVE LOGS dans ce cas ?

En ce qui concerne l'utilisation des REDO LOGS (Qui créé de l'ARCHIVE LOG si la base est bien configurée) tu peux déclarer ta table en mode NOLOGGING mais mesure bien les conséquences car en cas de pépin, adieu la base, faudra restaurer à T-N.

Pour ma part je pense qu'il est largement préférable de faire un script qui compresse et transmet les ARCHIVE LOGS sur une autre machine si vraiment il y a besoin de place. Mais bypasser les REDO LOGS c'est loin d'être top...

**orafrance** · 27/05/2008, 12h13

NOLOGGING n'a aucun effet sur l'update

http://download-west.oracle.com/docs...ables.htm#8262

The NOLOGGING clause also specifies that subsequent direct loads using SQL*Loader and direct load INSERT operations are not logged. Subsequent DML statements (UPDATE, DELETE, and conventional path insert) are unaffected by the NOLOGGING attribute of the table and generate redo.

Le problème d'espace disque est lié à quoi ? Tablespace, UNDO, archivelog, flashback logs ?

**shadeoner** · 27/05/2008, 12h20

Pour faire simple, voici le message que j'ai :

Code :

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

ORA-01562: failed to extend rollback segment number 239

que me conseillez-vous ? Sachant que je n'ai pas la main pour augmenter le tablespace.

**McM** · 27/05/2008, 12h45

Quelle version de base ?

Dans les versions 8, on pouvait spécifier un rollback segment à utiliser (généralement un RBS_BIG était créé)

Sinon, faut séquencer ton update et commiter.

**shadeoner** · 27/05/2008, 12h46

Je suis en 10g. J'ai fais justement un where ultra précis, mais ça passe pas

Envoyé par McM

Quelle version de base ?

Dans les versions 8, on pouvait spécifier un rollback segment à utiliser (généralement un RBS_BIG était créé)

Sinon, faut séquencer ton update et commiter.

**McM** · 27/05/2008, 12h48

Tu dois mettre à jour combien de lignes ?

**philcero** · 27/05/2008, 13h09

NOLOGGING n'a aucun effet sur l'update

Merci pour l'info, j'étais resté sur une idée erronée, et vu que j'ai jamais vérifié par la suite...

Maintenant si on en revient à ses moutons, il veut faire un update massif si j'ai bien compris.

Pourquoi dans ce cas ne pas, en PL/SQL, cibler par un curseur les clefs des lignes à modifier, récupérer celles-ci avec un BULK COLLECT, et ensuite faire le traitement par tranches avec un commit tous les N lignes ?

**shadeoner** · 27/05/2008, 13h22

J'ai trouvé encore plus préçis....
ça va être long mais je devrais y arrivé, merci pour votre aide à tous.

**McM** · 27/05/2008, 13h27

J'avoue ne pas comprendre le "plus précis".
Tu faisais des updates qui servaient à rien, c'est ça ?

**shadeoner** · 27/05/2008, 13h37

Je faisais un update en utilisans dans le where une date, je faisais par jour, là je suis descendu par heure...

**mnitu** · 27/05/2008, 13h37

Envoyé par McM

J'avoue ne pas comprendre le "plus précis".
Tu faisais des updates qui servaient à rien, c'est ça ?

You made my day

Je pense qu'il n'a pas envie de partager cette découverte avec nous.

**shadeoner** · 27/05/2008, 13h43

Je ne comprends pas pourquoi vous concluez ça ?

**philcero** · 27/05/2008, 14h24

Je faisais un update en utilisans dans le where une date, je faisais par jour, là je suis descendu par heure...

Fais attention car en se basant sur la date & heure rien ne dit que la répartition de tes données ne va pas faire arriver ton algorithme sur une date & heure qui à elle seule représente 5% de ta base...