Results 1 to 4 of 4
  1. #1
    Join Date
    Oct 2003
    Location
    Rio de Janeiro, RJ, Brazil
    Posts
    3

    Unhappy Unanswered: Trying to understand...

    Hi everybody.

    I'm in a Oracle traning (wanting to be a DBA) and I was doing great until last Saturday, when the teacher started to explain Oracle's architecture.

    I did understand the whole thing, but some questions took place in my mind when the teacher explained Redo Log Buffer, Redo Log Files, Database Buffer Cache, etc.

    I'd like to describe the proccess of it and someone who knows more than me (what is more likely) could tell me if I'm right.

    Well, let's suppose I'm in an Oracle session and I do an UPDATE. The server process receives it, sends it to the Shared Pool Area, that verifies the syntax, verifies if there's another identical command to be shared, verifies my privileges in the data dictionary, and gets the execution plan. Then it is passed to the Database Buffer Cache, that will do the operations to find the rows that will be updated.

    Well, found the rows, Oracle will apply the commands to update the rows, "dirting" the blocks that will be updated and sending it to the write list. At the same time, it generates records of commands in the Redo Log Buffer, like: 1. copy the data that will be updated to the undo/rollback area; 2. lock these rows (for the people who will try to access it go the undo/rollback area); 3. do the update in the rows. These 3 commands are stored in the Redo Log Buffer.

    Then, I do some other commands, like DELETE, INSERT, etc. If the dirty list is 50% full, the DBWr process writes physically the updated data on the disk, and if the Redo Log Buffer is 33% full, the LGWr process writes the commands on the current Redo Log File.

    If I make a COMMIT, it also cleans the Redo Log Buffer (writing its data on the Redo Log Files), creates an SCN (system change number) and writes it on the Control File and then shows the response for me, saying that the transaction was committed successfully. Then, the resources used in the transaction (the undo space, locks, etc) are set free.

    Am I correct up to now?

    Question: as the DBWr and LGWr processes doesn't are synchronized one with the other, is there a moment that the DBWr writes the data to the disk and the LGWr doesn't? Thus, if there is a blackout at that moment, or a "shutdown abort", when the database stands up again and Oracle does the automatic recovery, the record of the data is lost forever (it wasn't write on the disk), and the real data is there on the disk? Wouldn't that be a serious inconsistance?

    Sorry about my english, and thanks in advance, my DBA friends.

    Mozart L. Archilla

  2. #2
    Join Date
    Jul 2003
    Posts
    2,296
    Okay, you are already way ahead of a lot of people.
    If you wrote that all out from the top of your head, great job.

    Your Answer:
    The point is moot.
    You would be recovering to a point-in-time. This point-in-time would be before the commit took place anyways. Or, you would be recovering until a specific checkpoint which has not occurred yet.

    Maybe someone like Bill can shed some light on this. I could be wrong.
    - The_Duck
    you can lead someone to something but they will never learn anything ...

  3. #3
    Join Date
    Jun 2003
    Location
    Toronto, Canada
    Posts
    5,516
    Provided Answers: 1
    Originally posted by The_Duck
    Okay, you are already way ahead of a lot of people.
    If you wrote that all out from the top of your head, great job.

    Your Answer:
    The point is moot.
    Not really. The Concepts manual says this:

    LGWR writes one contiguous portion of the buffer to disk. LGWR writes:
    -- A commit record when a user process commits a ransaction
    -- Redo log buffers
    Every three seconds
    When the redo log buffer is one-third full
    When a DBWn process writes modified buffers to disk, if necessary

    Note: Before DBWn can write a modified buffer, all redo records associated with the changes to the buffer must be written to disk (the write-ahead protocol). If DBWn finds that some redo records have not been written, it signals LGWR to write the redo records to disk and waits for LGWR to complete writing the redo log buffer before it can write out the data buffers.
    ---
    "It does not work" is not a valid problem statement.

  4. #4
    Join Date
    Oct 2003
    Location
    Rio de Janeiro, RJ, Brazil
    Posts
    3
    Originally posted by The_Duck
    Okay, you are already way ahead of a lot of people.
    If you wrote that all out from the top of your head, great job.

    Your Answer:
    The point is moot.
    You would be recovering to a point-in-time. This point-in-time would be before the commit took place anyways. Or, you would be recovering until a specific checkpoint which has not occurred yet.

    Maybe someone like Bill can shed some light on this. I could be wrong.
    Originally posted by n_i
    Not really. The Concepts manual says this:

    LGWR writes one contiguous portion of the buffer to disk. LGWR writes:
    -- A commit record when a user process commits a ransaction
    -- Redo log buffers
    Every three seconds
    When the redo log buffer is one-third full
    When a DBWn process writes modified buffers to disk, if necessary

    Note: Before DBWn can write a modified buffer, all redo records associated with the changes to the buffer must be written to disk (the write-ahead protocol). If DBWn finds that some redo records have not been written, it signals LGWR to write the redo records to disk and waits for LGWR to complete writing the redo log buffer before it can write out the data buffers.
    Funny, this is not said in my apostil... these "LGWR triggers" that you've posted are almost the same of my lesson book, except for the last item... I'll ask my teacher about it...
    Well, Duck, I took it all from my mind... so, is my ratiocination correct? wow, I thought that I was completely lost! hehehe

    thanks so much!

    Mozart

Posting Permissions

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