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

----- 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. > ********************************************