IDS Forum

Re: Doubt on logical log - in your answer to CAN IDS run lo

Posted By:
Date:

----- Original Message -----
From: Vasantha Kumarr <Vasantha.KumarR@in.efunds.com>
At: 2/19 1:17

> Hai,

Hi all. Jonathan Leffer has pointed out that I misspoke (wrote?). I posted
what I had been told several years ago and have always believed. I don't know
if I was mis-informed or things have changed. I'll find out. Anyway there were
accuracies in the posting but let me restate the facts:

According to my testing today it looks like only a minimal amount it flushed to
the log from the buffer so the log bloat is a red herring, at least for 7.31
and later (still don't know if earlier releases behaved differently), my
apologies.

According to the Admin Guide (p 7-49 in the 9.3 manual) if any of the following
is written to the logical log buffer by a transaction in a database that is
UNBUFFERED (or in a session that has run SET LOG) then the current logical log
buffer is flushed to disk: COMMIT, PREPARE, XPREPARE, ENDTRANS or at the end of
any session. The contents flushed will include any buffered pages from BUFFERED
LOG database transactions that are waiting to be flushed.

To answer Vasanth's concerns see below:

> With repect to the below mail, I have a doubt like,
>
> 1. In shared memory (Resident portion), as we have separate buffers for both
> logical logs and
> physical logs , as per your mail,it states that the logical log buffers holds
> the pre and post
> images of the records. But as per my understanding the logical log buffers
holds
> only DML statements
> and physical logs holds the pre image of the record. Could you pls. brief the
> answer what you have
> given.

No. The PHYSICAL LOG holds a preimage of any PAGE that was changed since the
last checkpoint. There will be only one image of the page there no matter how
many changes occur during the period prior to the next checkpoint. The Physical
Log page is ONLY used during crash recovery, NEVER for transaction rollback.
If when the engine is brought up and the physical log on disk is not empty it
indicates that the engine was not properly shutdown indicating that either the
engine or the host crashed. So the engine restores the physical log pre-image
pages to their original locations to set up a pristine environment for logical
log roll-forward/roll-back in case any writes to those pages were interrupted
during the crash making the pages inconsistent or perhaps garbage. Note that
this restores the pages to their condition as of the last checkpoint which might
be mid-transaction and does not include any physical log pages that were in the
physical log buffer at the time of the crash.

The logical log contains ROW LEVEL pre- and/or post images (as appropriate to
the operation) of any rows modified and transaction control records in a logged
database plus DDL and session records for all databases. So for a delete there
is a pre-image record (there is no post-image), for an insert a post-image
record only (what was in the slot before the insert is assumed to be garbage),
and for an update both a pre- and post-image of the row are saved. These are
the records that are used for transaction rollback and for fast recovery to
restore the database to a consistent condition after a crash by rolling forward
the logical log records from the last hard checkpoint to the end of the log then
rolling back any incomplete transactions, again using the logical log records.

Strictly speaking the physical log records are NEVER used for transaction
rollback and are not NEEDED for recovery at all. Recovery using the logical log
records is sufficient normally. The physical log 'slapdown' at startup is done
to insure that in case a row that was NOT modified was contained on a page that
was partially written during the crash and trashed in the process is restored
before logical recovery begins since such a row will not be restored by the
logical recovery.

> 2. Moreover the entires from the logical log buffers will be flushed to the
disk
> only when there is
> commit since it is under unbuffered logging.Can you pls. explain the sentence
> which i have made bold
> below.

NO! You have it backwards. In a BUFFERED LOG database the current logical log
buffer is not flushed until the current log buffer fills. In an UNBUFFERED LOG
database the current log buffer is flushed as I describe at the top of this
reply above basically when something finishes and also if it fills due to large
records like BLOBS.

Art S. Kagel

> Thanks in Advance
>
> Vasanth
> Informix DBA
>
> First a side note, one reason that logical logs seem to fill too fast when
> using unbuffered logging is that the logical log buffer size (LOGBUFF in
> the ONCONFIG file) is set to large. Remember that with unbuffered
> logging an entire logical log buffer will be written out whenever it
> contains a complete set of matching log records (like a pre-image and
> post-image of a modified page) even though there may not even be other
> partial records from other transactions in the buffer. So in such case
> the buffer might contain 4-6K of log records but if you have set LOGBUFF
> to 128K then 128K gets written out to the logical log causing it to fill
> rather too quickly.
>
> ********************************************
> This electronic mail message is intended solely for the named
> recipients and may contain
> confidential and proprietary business information of eFunds Corporation and
> all its subsidiaries.
> If you are not a named recipient, please notify the sender immediately.
You
> may not disclose the
> contents to any other person; use this electronic mail message or its
> contents for any other
> purpose; or further store or copy its contents in any medium.
> ********************************************

IDS Forum is maintained by Administrator with WebBBS 5.12.