Instance recovery behaviour

[DaPi]

Thanks for the link quester.

[DaPi]

Hi Amar, nice of you to go to the trouble to prove it works. Personally I had no doubts - just lacked the right words to explain it properly the first time!
(Big difference between knowing and teaching - that's why training courses cost!)

[adewri]

Originally posted by DaPi
Hi Amar, nice of you to go to the trouble to prove it works. Personally I had no doubts - just lacked the right words to explain it properly the first time!
(Big difference between knowing and teaching - that's why training courses cost!)

See i learned something new today... Hope this (learning one new thing everday) becomes regular for me...

Over all an excellent discussion we all had.

[alison]

Thanks all for your responses.

Just to clarify, PANDO you wrote

"RBS and that's what I have been trying to say in the beginning

Oracle reads redo log and RBS, then use redo to rebuild RBS and read RBS again. RBS are just data, they are flushed to disk by checkpoints as well and checkpoints will ensure you that the redo log which protects the undo can be overwritten (the dirty RBS data is flushed to disk)"

I understand that this is the case, and that Oracle will rebuild the RBS along with the datablock from the REDO.

My actual question was that if this REDO was in a log that has been overwritten and the dirty block and RBS from the transaction has been written to the datafiles (due to checkpointing or normal DBWR activity)

During instance recovery the actual REDO to recreate the datablock and RBS is no longer there (because it's overwritten and not in ARCHIVELOG mode)

How does oracle know to roll the transaction back? - I know the data to perform the rollback is in the datafiles (just normal oracle blocks) but the record of the transaction is not in the REDO.

I know that it works and that there is no problem with it, I'm just not sure from where Oracle decides that this transaction is to be rolled back - keeping in mind that the REDO has been overwritten.

I think that from other responses that the existence of the transaction in the RBS implies that it is to be rolled back, is this the case?

Kind and grateful regards

Alison

[DaPi]

Originally posted by alison
How does oracle know to roll the transaction back? - I know the data to perform the rollback is in the datafiles (just normal oracle blocks) but the record of the transaction is not in the REDO.

I think that from other responses that the existence of the transaction in the RBS implies that it is to be rolled back, is this the case?

That's my understanding too, Alison!

[Thomasps]

What Pando telling absoluteley correct but let me explain.
Again the confusion is at

"Oracle reads redo log and RBS, then use redo to rebuild RBS and read RBS again. RBS are just data, they are flushed to disk by checkpoints as well and checkpoints will ensure you that the redo log which protects the undo can be overwritten (the dirty RBS data is flushed to disk)"

Oracle Doc Says

"Rollback entries change data blocks in the rollback segment, and Oracle records all changes to data blocks, including rollback entries, in the redo log. This second recording of the rollback information is very important for active transactions (not yet committed or rolled back) at the time of a system crash. If a system crash occurs, Oracle automatically restores the rollback segment information, including the rollback entries for active transactions, as part of instance or media recovery. Once the recovery is complete, Oracle performs the actual rollbacks of transactions that had been neither committed nor rolled back at the time of the system crash. "

Again from Oracle Doc (***)

"For each rollback segment, Oracle maintains a transaction table--a list of all transactions that use the associated rollback segment and the rollback entries for each change performed by these transactions."


From metalink

"Oracle7 keeps a transaction table in the header of every rollback segment. Every transaction must have update access to the transaction table for its rollback segment."

So it is clear that the status of the transaction is available from the ROLLBACK Segment.

Coming back to Pando's answer
"Oracle reads redo log and RBS, then use redo to rebuild RBS and read RBS again. RBS are just data, they are flushed to disk by checkpoints as well and checkpoints will ensure you that the redo log which protects the undo can be overwritten (the dirty RBS data is flushed to disk)"

let me divide the Rollback Information in to two Category

1. Rollback Information available in the RBS with transaction status
2. Rollback information not avaialble in the RBS which is populated from REDO Log

Case 1:

In this case there will be no problem for recovery (Roolback) since all the information ia availbale in the RBS. Refer ***

Case 2:

Well, this case, keep in mind that, there was a check point happened during the logswitch. SO all the RBS infomation is flushed to the disk. So only RBS infomation is not availbale in the disk is partial of the current REDO logo file. And which is populated from the redo log during the ( I am talking only about the Instance recovery) startup. ie oracle is not rebuilding the RBS 100% from the redo log, but rather rebuilding the RBS for missing data only. This missing RBS data is only "PARTIAL OF THE CURENT REDO LOG FILE". So over writing your redo log files in noarchive log mode is not going to tamper the instance recovery.

Guys, agree with me or I am wrong..?


Thomas

[SANJAY_G]

Originally posted by Thomasps
Guys, agree with me or I am wrong..?


Thomas

Good conclusion.. Agree with what you explained.

[adewri]

Originally posted by Thomasps
"PARTIAL OF THE CURENT REDO LOG FILE". Guys, agree with me or I am wrong..?

Agree, but can you explain your PARTIAL OF THE CURRENT REDOLOG FILE theory...
Tell me what information does this PARTIAL OF THE CURRENT REDOLOG FILE contains and why is this not required...

Guys this one is for Thomasps only...

[Thomasps]

Hi

Woops... Amar, You caught my neck!

Well,

Step 1: Since there is Checkpoint during the logswitch then using other than current redo log file is ruled out. So restricting only to current redo log file.

Step 2. DBWR flushing dirty blocks to the data files, Oracle DOC:

The initialization parameter DB_WRITER_PROCESSES specifies the number of DBWn processes. If your system uses multiple DBWn processes, you should adjust the value of the DB_BLOCK_LRU_LATCHES parameter so that each DBWn process has the same number of latches (LRU buffer lists).The DBWn process writes dirty buffers to disk under the following conditions:

When a server process cannot find a clean reusable buffer after scanning a threshold number of buffers, it signals DBWn to write. DBWn writes dirty buffers to disk asynchronously while performing other processing.

DBWn periodically writes buffers to advance the checkpoint, which is the position in the redo thread (log) from which crash or instance recovery would need to begin. This log position is determined by the oldest dirty buffer in the buffer cache.

So it is clear that some of the RBS infomation must be flushed to the data files except the latest or complete. From that knowledge I concluded that it is taking PARTIAL of the current redo log file which is missing in the RBS

Amar, tell me me where I am wrong..?

I appreciate!


Regards

Thomas

[adewri]

i'm not saying you are wrong or right. My point is making conclusion on what others have said or proved is easy, but proving what you say is quite a difficult task.

BTW you can be a good writer (who can gather information from here and there and put it in one place)