is there a way not to generate rollback?
DBAsupport.com Forums - Powered by vBulletin
Results 1 to 7 of 7

Thread: is there a way not to generate rollback?

  1. #1
    Join Date
    Mar 2001
    Posts
    61
    Hi,
    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

    thanks in advance

  2. #2
    Join Date
    Jan 2001
    Posts
    3,131
    Can you specify "NO LOGGING" for this?
    I think that would do it.
    MH

  3. #3
    Join Date
    Feb 2000
    Location
    Washington DC
    Posts
    1,843
    Elaborate on what kinda transaction you are doing ? its regular business transaction/batch process updating lots of data ? or what ?

    as MH suggested you can use NOLOGGING Option(8i) UNRECOVERABLE Option(Old versions). But thses ooptions are with table data maintenance...
    Reddy,Sam

  4. #4
    Join Date
    Mar 2001
    Posts
    61
    hi,
    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

    set tranasaction unrecoverable?




  5. #5
    Join Date
    Dec 2000
    Location
    Ljubljana, Slovenia
    Posts
    4,439
    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?

  6. #6
    Join Date
    Feb 2000
    Location
    Washington DC
    Posts
    1,843
    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.

    http://otn.oracle.com/doc/server73x/...h4a.htm#toc103
    Reddy,Sam

  7. #7
    Join Date
    Apr 2001
    Posts
    219
    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.

    out of this Link:
    http://otn.oracle.com/doc/oracle8i_8...dlins.htm#2545

    Here is another link:
    http://otn.oracle.com/doc/oracle8i_8...5/c09parti.htm

    Hope this helps.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Click Here to Expand Forum to Full Width