REDO LOGS vs ROLLBACK segments
DBAsupport.com Forums - Powered by vBulletin
Results 1 to 9 of 9

Thread: REDO LOGS vs ROLLBACK segments

  1. #1
    Join Date
    Feb 2001
    Posts
    66
    Hi all,

    I trying to get clear on my mind what is the difference or relation between the redo log files and the rollback segments.

    The redo log file definition said: disk resources that store data changes made by users on Oracle.
    The rollback segments is: stores data changes for transactions to provide read consistency and transaction concurency, stores old data values when a process is making changes.

    So, the redo logs is for storing the new value of data, and the rollback the old one.

    Phsysicaly, the redo logs have members with 2 files each that oracle recommends to put on different HD, and the rollback segments the file or files set up for the related tablespace.

    1. Until here is no relation, rigth?
    2. The redo log must be much more important because there are 2 files containing identical copy of another's data, why the rollback are less important?
    3. The new value of data(redo log information) are written to database when commit or checkpoint occurs?


    putting this down already cleared my mind a little, did I miss something?


  2. #2
    Join Date
    Feb 2000
    Location
    Washington DC
    Posts
    1,843
    Better not to confuse with more details.Simple to look at this way.

    REDOLOG: Changes made will be available irrespective of transaction/task status.

    ROLLBACK: Chnages will be available respective to transaction status commited/rolledback.


    Reddy,Sam

  3. #3
    Join Date
    Feb 2001
    Posts
    295
    Imagine that one user makes a query on a table during an updata by another user. To provide consistency, the first user will query data being updated from ROLLBACK SEGMENT, until the second one commits his transaction. Just an example.

    REDO LOGS has recovery purpose: all changes made to the database (commited or not) are saved as redo records on online redo logs. If the instance fails, or anything else, one can recover transactions until the failure time.

    If the database is always ok, redo logs will only be written until they get full (so they are cleaned and started to be written again). They work as a complement to backup, in other words.

    Rollback segments are different, they are heavily used during updates/queries, not just being written but readed too, when it's needed to provide a consistent query.

    Hope I was clear, not sure.

    Adriano.

  4. #4
    Join Date
    Dec 2000
    Location
    Ljubljana, Slovenia
    Posts
    4,439
    [QUOTE][i]Originally posted by m_d_marian [/i]
    [B]2. The redo log must be much more important because there are 2 files containing identical copy of another's data, why the rollback are less important?
    [/B][/QUOTE]
    You can't say which is more and which is less important for a database. You have to have both of them (plus a bunch of other things) to keep the database running. If one part of database is missing it will crash and/or you won't be able to start it again. Also, it is not true that you have to have 2 members of each redolog group. Oracle will gladly allow you to have only one copy of each redolog, but it is much more safe and recomended if you have them mirrored.

    [QUOTE]
    [B]3. The new value of data(redo log information) are written to database when commit or checkpoint occurs?
    [/B][/QUOTE]
    Not necessarilly at commit time. DBWR writes dirty buffers only when it finds it necessary to do so. COMMITS do not trigger DBWR to write blocks to database files. But they do trigger LGWR to write changes from redo log buffer to redo log file on disk.

    HTH,
    Jurij Modic
    ASCII a stupid question, get a stupid ANSI
    24 hours in a day .... 24 beer in a case .... coincidence?

  5. #5
    Join Date
    Feb 2001
    Posts
    66
    Thanks guy, this make sense

    but Jurij, you said that COMMIT do not triggers DBWR to write blocks to database files. That means that if USER1 made a change and commit, LGWR write changes to redo log file, so how could USER2 see the changes? the SELECT statement fetch rows on redo log files also?


  6. #6
    Join Date
    Feb 2001
    Posts
    295
    [QUOTE][i]Originally posted by m_d_marian [/i]
    [B]Thanks guy, this make sense

    but Jurij, you said that COMMIT do not triggers DBWR to write blocks to database files. That means that if USER1 made a change and commit, LGWR write changes to redo log file, so how could USER2 see the changes? the SELECT statement fetch rows on redo log files also?

    [/B][/QUOTE]


    If DBWR did not write information on database files, that information is still in db buffer cache. Don't think it's neccessary to read datafiles.




    Adriano.

  7. #7
    Join Date
    Dec 2000
    Location
    Ljubljana, Slovenia
    Posts
    4,439
    Exactly.
    Jurij Modic
    ASCII a stupid question, get a stupid ANSI
    24 hours in a day .... 24 beer in a case .... coincidence?

  8. #8
    Join Date
    Jan 2001
    Posts
    126
    Hi,

    The select statement fetches rows from the table blocks and not from redo logs.

    When user1 changes any information, the changed blocks will be in SGA till the DBWR writes them to datafiles. They may continue to be in SGA based on the LRU algorithm. Hence user2 will see the changes made by user1 as the changed block will be read from SGA.

    Baliga

  9. #9
    Join Date
    Feb 2001
    Posts
    66
    Thanks very much guys, now I can figure out how this work.

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