SEO

What is significance of Informix database buffered log or unbuffered log parameter.

"Suket" <suketsinha@indiatimes.com> wrote in message
news:b30fd489.0309090232.303118c7@posting.google.c om...
> What is significance of Informix database buffered log or unbuffered log
parameter.
Logs are used to implement transactions and database consistency. All
changes are written to log and to database. When you're using buffered log,
server first fills the internal buffers and when buffers are full, then
writes them to disk. When you're using unbuffered logging, logs are written
to disk directly without buffering. First option is faster, but may cause
you to loose some data when server crashes, second option is more secure,
but hurts server performance. We're always using buffered logging.

Gorazd

On Tue, 09 Sep 2003 06:32:19 -0400, Suket wrote:

> What is significance of Informix database buffered log or unbuffered log
> parameter.

Gorazd almost got it. Informix ALWAYS write logical log records to one of the
three logical log buffers (sized with the LOGBUFF onconfig parameter). If the
database for which a logical log record is being written is UNBUFFERED LOG the
whenever a COMMIT or ROLLBACK record is written to the log buffer is it
immediately flushed to disk. If the database is BUFFERED LOG then the buffer is
ONLY flushed when it fills.

In the BUFFERED case if the system crashes before the logical log buffer is
flushed then the transaction, which the user thought was completed and committed
successfully, is considered incomplete and will be rolled back when the engine
is restarted and goes through 'fast recovery'. In the UNBUFFERED case this
cannot happen, once the user gets the transaction committed response the logical
log buffer has been flushed to disk and all is safe (barring the disk controller
cache problems discussed on this list last week).

Another possible problem when using BUFFERED LOG is that some transactions
require multiple logical log records to be written as part of the commit. In
the BUFFERED case it is possible for the first few of these to be written to an
almost full log buffer which would then flush while the final record(s) is
written to the next buffer and is not flushed immediately. If the system
crashes at this point the engine will not restart as fast recovery will find the
partial commit record and not know whether to commit or rollback. When this
happens one must call tech support to log in and truncate the last logical log
at a point before the partial COMMIT possible causing other transactions to
rollback as well when the engine is finally brought online.

I NEVER use BUFFERED log. Yes it is a bit faster, but I like my data. Besides
<grinn from ear to ear> I figure the DBAs using BUFFERED LOG are the same ones
using RAID5. Since I only use RAID10 I figure I'm still running faster than
they are <snicker>. ;-)

Art S. Kagel

"Art S. Kagel" <kagel@bloomberg.net> wrote in message news:<pan.2003.09.09.13.41.20.171091.10594@bloombe rg.net>...

> I NEVER use BUFFERED log. Yes it is a bit faster, but I like my data. Besides
> <grinn from ear to ear> I figure the DBAs using BUFFERED LOG are the same ones
> using RAID5. Since I only use RAID10 I figure I'm still running faster than
> they are <snicker>. ;-)
>
> Art S. Kagel

I could hear you laughing all the way down in Amsterdam.

Robert A. Reissaus
RISDI
Ibm/Informix Consultants
Amsterdam, the Netherlands
r.a.reissaus@risdi.com
www.risdi.com