UPDATE sans redlog [Résolu]

[shadeoner]

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]

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]

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]

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

Code :

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]

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]

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]

Tu dois mettre à jour combien de lignes ?

[philcero]

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]

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

[McM]

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

[shadeoner]

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

[mnitu]

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]

Je ne comprends pas pourquoi vous concluez ça ?

[philcero]

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...

[shadeoner]

Oui, c'est plutot aléatoire, mais ça se passe bien pour le moment

[mnitu]

Envoyé par shadeoner

Je ne comprends pas pourquoi vous concluez ça ?

Désolé, je répondu trop vite et je me suis trompé. Voilà.