Hi,

What recommends baan about logging , buffered logging or unbuffered logging.

Thanks

Caner

Caner,

What exactly do you mean by 'logging'?

Hi ,
I meant the database logging status. When we were using baan on NT our database (informix) was using unbuffered logging but now on Unix buffered logging . I asked this to our local baan office . they said that buffered logging is used on unix and unbuffered on NT for better performance.
Is this what baan recommends. are all the baan users on NT using unbuffered logging and on unix buffered logging?

Where can I find documents about baan/unix and baan/informix administration?

Below is a part of database logging subject from informix administration document .
The Database-Logging Status
Every database that the database server manages has a logging status. The
logging status indicates whether the database uses transaction logging and,
if so, which log-buffering mechanism the database employs. To find out the
transaction-logging status of a database, use the database server utilities,The database-logging
status indicates any of the following types of logging:
* No logging
* Unbuffered transaction logging
* Buffered transaction logging
* ANSI-compliant transaction logging
The last three items in this list refer to different log-buffering mechanisms.
information that the database server manages passes through shared
memory to disk. Logical-log records are no exception. Before the database
server writes logical-log records to the logical log, which is on disk, the
records must pass through shared memory. They do this through the logical-log buffers,
In one sense, all the database server logging is buffered because all log
records pass through the logical-log buffer in shared memory before the
database server writes them to the logical log on disk. However, the point at
which the database server flushes the logical-log buffer is different for
buffered transaction logging and unbuffered transaction logging.

+ Unbuffered Transaction Logging
If transactions are made against a database that uses unbuffered logging, the
records in the logical-log buffer are guaranteed to be written to disk before
the COMMIT statement (and before the PREPARE statement for distributed
transactions) returns to the application. The database server flushes the
records as soon as any transaction in the buffer is committed (that is, a
commit record is written to the logical-log buffer).
When the database server flushes the buffer, only the used pages are written
to disk. Used pages include pages that are only partially full, however, so
some space is wasted. For this reason, the logical-log files on disk fill up faster
than if all the databases on the same database server used buffered logging.

+ Buffered Transaction Logging
If transactions are against a database that uses buffered logging, the records
are held (buffered) in the logical-log buffer for as long as possible; they are not
flushed from the logical-log buffer in shared memory to the logical log on
disk until one of the following situations occurs:
* The buffer is full.
* A commit on a database with unbuffered logging flushes the buffer.
* A checkpoint occurs.
* The connection is closed.

+ When to Buffer Transaction Logging
If a database does not use logging, you do not need to consider whether
buffered or unbuffered logging is more appropriate.
ANSI-compliant databases always use unbuffered logging. You cannot
change the buffering status of ANSI-compliant databases.
Unbuffered logging is the best choice for most databases because it
guarantees that all committed transactions can be recovered. In the event of
a failure, only uncommitted transactions at the time of the failure are lost.
However, with unbuffered logging, the database server flushes the logical-log
buffer to disk more frequently, and the buffer contains many more
partially full pages, so it fills the logical log faster than buffered logging does.
If you use buffered logging, and a failure occurs, you cannot expect the
database server to recover the transactions that were in the logical-log buffer
when the failure occurred. Thus, you could lose some committed transac-tions.
In return for this risk, performance during alterations improves
slightly. Buffered logging is best for databases that are updated frequently
(when the speed of updating is important), as long as you can re-create the
updates in the event of failure. You can tune the size of the logical-log buffer
to find an acceptable balance for your system between performance and the
risk of losing transactions to system failure.
Thanks

Caner

Hi Caner,

Sorry I can't help much here, I don't know enough about the Informix-Baan combination. But the additional text will make your case clearer to members who might be able to help you.

Just 2 comments though:

a. regardless of what buffering mode you use on database level, you will always have your data cached on OS level in the file system/buffer cache unless you use raw volumes (for your logs)

b. I know that in alot of Informix environments the logical-log information is directly sent to a tape device. In that a scenario I think buffered logging would be preferable because then the log data can be streamed in bigger chunks to the tape, ultimately helping I/O performance.