Subject | Re: [firebird-support] Forces writes and transaction throughput? |
---|---|
Author | Michael Ludwig |
Post date | 2008-12-07T22:48:40Z |
Kjell Rilbe schrieb am 04.12.2008 um 09:20:19 (+0100):
maintain a sequential log of transactions that records all changes and
allows the engine to defer writing of the data to the actual storage
location to a future, calm moment. The point here is that appending data
to the end of the log is faster than doing random disk seeks. Searching
for "sequential transaction log" will bring up some information.
This does not seem to be the way Firebird handles the issue, though.
Googling for "firebird transaction logging", I find that Firebird does
not have a transaction log, but instead relies on a feature called
"careful write" to maintain consistency, thereby possibly incurring a
disk seek penalty on commit. Here's a good article explaining how this
is done:
Firebird for the Database Expert: Episode3 - On disk consistency
by Ann Harrison
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_expert3
Michael Ludwig
>A common way for a DBMS to increase transaction throughput is to
> 1. How to configure FB or the DB to reduce head seeks on commits with
> forced writes on?
>
> 2. How to improve FB itself (future development) to do the same?
>
> I note that IB and FB are the only DB:s I've seen that do so many head
> seeks on commit. So how do other engines do it?
maintain a sequential log of transactions that records all changes and
allows the engine to defer writing of the data to the actual storage
location to a future, calm moment. The point here is that appending data
to the end of the log is faster than doing random disk seeks. Searching
for "sequential transaction log" will bring up some information.
This does not seem to be the way Firebird handles the issue, though.
Googling for "firebird transaction logging", I find that Firebird does
not have a transaction log, but instead relies on a feature called
"careful write" to maintain consistency, thereby possibly incurring a
disk seek penalty on commit. Here's a good article explaining how this
is done:
Firebird for the Database Expert: Episode3 - On disk consistency
by Ann Harrison
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_expert3
Michael Ludwig