When they talk about "redo log entries" in the doc. is
it a synonym of "redo block" or is it a different structure ?

Thanks.
Sp

Spendius wrote:

> When they talk about "redo log entries" in the doc. is
> it a synonym of "redo block" or is it a different structure ?
>
> Thanks.
> Sp

A redo log entry is (I think -it's difficult to advise without seeing
the actual quote and putting it into context) just the data that is
generated whenever you perform some DML -namely, the before and
after-images of the column data, plus associated overhead.

If you update someone's salary from 600 to 700, for example, the before
image is the rowid, come column identification, plus the number 600. The
after image is the same stuff, plus the number 700. (Actually, there's a
lot more to a redo entry than that, but that's the general idea. Have a
desc of v$logmnr_contents to get an idea for how much "overhead" is
actually associated with the stuff that's actually yours!).

If you insert, the before image is essentially just the rowid, but the
after image is the entire row. And the reverse is the case for a delete.

They're the entries, anyway. And they are made in the first place in the
redo log buffer, in memory. Eventually they get flushed to one or other
of your online redo logs (at a commit, before DBWR flushes, when the log
buffer is 1/3rd full, or when 1MB of uncommitted redo is generated).

Redo logs (the physical files) are not internally formatted to have
Oracle blocks like a data file is. Therefore, they essentially are just
made up of file system blocks, and a log block is just another name for
a file system block.

And just as a peanut-sized text file written in notepad nevertheless has
to be stored in a complete file system block (or cluster), with
attendant issues of 'slack space' on your hard disk, so LGWR has to fill
a complete file system/redo log block even if the amount of redo being
flushed is tiny. Generally, file systems use 512 byte blocks, so the
smallest update will have to occupy 512 bytes of redo log space.

That's broadly speaking it, anyway. As far as I can tell, when "they"
talk about log entries, they're talking about the actual data, which
sure enough eventually ends up being stored inside a redo log block
(a.k.a. file system or even operating system block).

Regards
HJR

"Howard J. Rogers" <hjr@dizwell.com> wrote...
> And just as a peanut-sized text file written in notepad nevertheless has
> to be stored in a complete file system block (or cluster), with
> attendant issues of 'slack space' on your hard disk, so LGWR has to fill
> a complete file system/redo log block even if the amount of redo being
> flushed is tiny. Generally, file systems use 512 byte blocks, so the
> smallest update will have to occupy 512 bytes of redo log space.

So I guess that means there can be a lot of "redo entries" inside
a "redo block" doesn't it ?

spendius@muchomail.com (Spendius) wrote in message news:<aba30b75.0405022321.424a901d@posting.google. com>...
> "Howard J. Rogers" <hjr@dizwell.com> wrote...
> > And just as a peanut-sized text file written in notepad nevertheless has
> > to be stored in a complete file system block (or cluster), with
> > attendant issues of 'slack space' on your hard disk, so LGWR has to fill
> > a complete file system/redo log block even if the amount of redo being
> > flushed is tiny. Generally, file systems use 512 byte blocks, so the
> > smallest update will have to occupy 512 bytes of redo log space.
>
> So I guess that means there can be a lot of "redo entries" inside
> a "redo block" doesn't it ?

The size of Oracle "redo entries" is entirely unrelated to the
physical block size of the logfile. Most redo entries are indeed
relatively small, but some may be quite large depending upon the needs
of the Oracle RDBMS developer. For example, I believe an index split
records a copy of the parent branch block (maybe 8K big) in the "redo
entry" for recovery purposes. Redo entries often span redo block
boundaries. Also redo blocks need not be completely full to be
written. For example, a "COMMIT" will force a redo write, and on a
quiet system the block is not likely to be full. In a busy system,
the commit entry will likely be bundled with changes from other
transactions so very little, if any, space would be "wasted".

It's probably best to think of a stream of redo entries as being
entirely unrelated in form to redo blocks. The redo stream is simply
"laid" out as it falls onto redo blocks (often causing individual
record records to land on more than one block). The redo blocks
themselves have a small header (and I believe a small footer) - but
the redo layer takes care of all that for the RDBMS developer. He
simply sees an endless stream of entries.

Hope that helps.
SCott.
P.S. I know a little bit about redo file format as I wrote SQL*Trax,
the log browser for Oracle, back in 1994 before Oracle had a log
miner. Please come see our new tool - a graphical data block browser
for Oracle at www.tlingua.com...