Re: Oracle Instance Recovery (I don't get it :)

Redo is basically on block level. So every block that gets changed generates redo. Now if that blocks stays in the buffer cache, no problem. However it may be very likely that the block is no longer in the buffer cache when we commit.

That means that the change to the block has been written to disk. The disk contains the datablock with uncommitted changes. If a crash occurs before the commit, we can't rollback the changes.

What Oracle does is to make sure that if a datablock is written, we check to see if the redo for the block has been written (even though it is not committed). So first we write the redo and then the datablock.

The redo contains of redo vectors. Each vector describes a change to a block. Normally 3 blocks: undo header, undo block, datablock. This means that we can see in the undo header if a tx has been committed, and if that is not the case we can find in the undo block the information to rollback the tx.

So I think that there is no waste, you could consider it waste if you don't care about being able to recover a database.

.

Bass Chorng wrote:

> Andrey Dmitriev (netcomradeNOSPAM_at_earthlink.net) wrote:
> : Now I am really confused. I thought so too, but as I was reading
> : Oracle 8 Tuning (Oracle series) I have noticed that the author(s) say
> : that Redo Logs contain only committed information. Does anybody else
> : have an opinion? Thanx. Meanwhile I think I am going to order Oracle 8
> : Architecture from bn or amazon :)
>
> Yes, redo ALSO contains uncommitted data.
>
> So everyone must have asked this question: why
> do the same job that rollback segment is already doing ?
> Why duplicates the effort?
>
> I am sure there are lots of technical reasons.
>
> But the only reason I can think of is although RBS has
> the rollback info, it is not available at recovery
> cuz database is not open. Redo is the only place available.
> This is a design issue, over the years I still think
> this is a terrible waste of effort.
>
> -Bass Chorng
Received on Mon Jul 05 1999 - 03:44:12 CDT