I am using a batch process and I wan't to know if there is a way not to use roll back for this transaction?
I wan't to cutdown the transaction time in this way, also the data is not critical so I don't care if I am unable to rollback or not I can always re run the program.
Please reply even if you are not sure in that case i can assume that there is no way
sorry I was out and not able to reply promptly.
I have few maintainance tables in Oklahoma. I query the DB in Houston every week.
during that process I re create few old tables and update some others. but its a lot amount of re do generated when updating. I am using 7.3 , so can I use
NOLOGGING has nothing in common with rollbacks!!! Nologging deals with *redo* entries, while rollback deals with *undo* entries.
Answer to original question: No, it can't be done. There is no way you could prevent undo entries to be written to rollback segments. No way, no documented way to do it and even not undocumented one (AFAIK).
On the other hand you could (at least up to a point) prevent redo entries to be generated by using some of the unrecoverable methods oracle provides for you. Or you could even totaly prevent redo generation by setting some undocumented init parameters - but you surely don't want to do this on a production database....
There is a reason why it is quite easily to prevent generation of redo entries, but is impossible to prevent generation of undo entries. Redo entries have only one main purpose: in case a database recovery (either instnace or media recovery) is needed they provide a way to recover the transactions. If it is OK with you not to be able to recover some of your transactions its OK with Oracle too, so it offers you that option. But on the other hand, rollback entries have more than one purpose. Beside the capability to rollback (undo) your transactions and the role that they play during recovery process, they play a crucial role in one additional basic functionality of Oracle's database: they provide a READ CONSISTENT VIEW of data for each and every query and DML on datablocks that you are modifying with your transaction. And here is a point where Oracle can not allow you not to generate rollback entries. You realy might not need them , but other concurent session must have them for the duration of your transaction. And that's why they must be generated.
Jurij Modic ASCII a stupid question, get a stupid ANSI
24 hours in a day .... 24 beer in a case .... coincidence?
I was above to correct my entry to say these options are not to generate redo not Rollback...
Hope you got the picture with Jmodic explaination. If you are sure its Rollback issue... there is nothing much you can do and if its with redo... you can use those options. have a read on the following docs of 734 docs create table syntax with that option.
I got this section:
Direct-load INSERT with no-logging. In this mode, data is inserted without redo or undo logging. (Some minimal logging is still done for marking new extents invalid, and dictionary changes are always fully logged.) When applied during media recovery, the extent invalidation records mark a range of blocks as logically corrupt, since the redo data is not logged.