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
Version imprimable
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
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...
NOLOGGING n'a aucun effet sur l'update ;)
http://download-west.oracle.com/docs...ables.htm#8262
Le problème d'espace disque est lié à quoi ? Tablespace, UNDO, archivelog, flashback logs ?Citation:
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.
Pour faire simple, voici le message que j'ai :
que me conseillez-vous ? Sachant que je n'ai pas la main pour augmenter le tablespace.Code:ORA-01562: failed to extend rollback segment number 239
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.
Je suis en 10g. J'ai fais justement un where ultra précis, mais ça passe pas :(
Citation:
Envoyé par McM
Tu dois mettre à jour combien de lignes ?
Merci pour l'info, j'étais resté sur une idée erronée, et vu que j'ai jamais vérifié par la suite...Citation:
NOLOGGING n'a aucun effet sur l'update
:oops:
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 ?
J'ai trouvé encore plus préçis....
ça va être long mais je devrais y arrivé, merci pour votre aide à tous.
J'avoue ne pas comprendre le "plus précis".
Tu faisais des updates qui servaient à rien, c'est ça ?
Je faisais un update en utilisans dans le where une date, je faisais par jour, là je suis descendu par heure... :(
You made my day :lol:Citation:
Envoyé par McM
Je pense qu'il n'a pas envie de partager cette découverte avec nous.
Je ne comprends pas pourquoi vous concluez ça ?
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...Citation:
Je faisais un update en utilisans dans le where une date, je faisais par jour, là je suis descendu par heure...
Oui, c'est plutot aléatoire, mais ça se passe bien pour le moment :)
Désolé, je répondu trop vite et je me suis trompé. Voilà.Citation:
Envoyé par shadeoner