Consultor Eletrônico

-Mf parameter - What does it really do?


To enforce transaction consistancy, every time we log a COMMIT note,
we must flush the buffer containing that note immediately. If a
system crash occurs, we can then recover the database and recover the
transaction associated with that COMMIT because it was flushed out to
disk.

In order to adhear to Write Ahead Logging, all writes to the BI file
must be done UNBUFFERED.

The -Mf parameter relaxes the rule that a COMMIT note forces a flush.

By doing this, we put the COMMIT note into the buffer and inform the
client that the transaction has committed. In the event of a system
crash, the transcation commit would not be in the BI file, hence the
transaction would be backed out. It is alright to do this provided
the end users check to see that their last transcations were committed
after the system comes up.

The default for -Mf is 3. If a COMMIT note gets logged, then the
buffer will be flushed to disk in one of two ways.

- the buffer fills up
- three seconds have passed

The hope is that more than 1 COMMIT note will be logged in a BI
buffer.

On a very busy system, the amount of time it takes for a BI buffer to
fill up is milliseconds. On a slow system without a lot of update
activity, it could take the full 3 seconds to flush out the COMMIT
note.

NOTE: Turning on 2 phase commit forces the -Mf parameter to be 0,
hence disallowing this optimization.

The -biblocksize parameter plays a role in performance with -Mf. The
larger the -biblocksize, the more likely multiple COMMIT notes reside
in a BI buffer, hence performance can be improved.

Here is an example:

3 COMMIT notes in a row all get put into 1 BI buffer.

With -Mf 0, this would cause 3 UNBUFFERED writes to the BI file; with
-Mf 3, there would be 1 UNBUFFERED write to the BI file, either when
the buffer is completely full, or when 3 seconds have passed.


26-Jan-96
LJF

Progress Software Technical Support Note # 15425