At 05:30 PM 3/30/2004, Edward Flick wrote:

>| Nope. Not everything that's written is data. If your transaction
>| inventory page (for one) dies in the file cache, the database is going to
>| require major resuscitation.
>So you are saying it is the unknown boundary at which the disk cache
>pauses at that can cause inconsistencies, if the boundary happens to
>stop in the middle of a critical page write?

Unh, not exactly. A Firebird database is a file broken into
"pages". Every page is the same length, oddly enough the "page length"
that you specify when you create the database or the default, 4096
bytes. Some pages contain data. Some contain indexes. Some contain
blobs. Others have internal structural information. The "hottest" pages,
those with the most changes, are the header page and the last transaction
inventory page(TIP). The header, the first page in the database, contains
the id for the next transaction. It is updated when a transaction
starts. The last TIP contains the state of the most recent transactions:
active, committed, rolled back, or limbo. Limbo is an advanced
topic. Check the IBPhoenix site for more information on limbo.

The database schedules its writes in an order that maintains the
consistency of the database file. The operating system schedules writes in
an order that it considers efficient, unless you've asked for forced writes
in which case it throws up its hands and says "whatever, but don't say I
didn't warn you."

If you've chosen to let the operating system schedule your writes and its
decided not to write the last TIP just yet even though it's been changed a
few times and then the operating system crashes hard, you'll find one of
two cases. The better case is that you lose a few committed
transactions. The worse case is that the old TIP was filled and written,
and new TIP was allocated but never written to disk. When you try to do
anything with the database, you get "attempt to read beyond end of file",
or some similar message. Then you hope your most recent backup is very recent.

> Do hard drives in general
>have a mechanism to where it won't start writing to a new page if it
>detects power failure, or what would keep this from happening with
>forced writes on? Just the probability of such a small page write being
>interrupted?

Beats me. People who live in areas with flaky power, who don't use UPS,
and who don't use forced-write have problems. Reliable power, UPS, or
forced writes avoid the problem.

>| The problem with backing up stable blobs is that you spend a lot of time
>| (and space) creating new copies of exactly the same old stuff.
>How tough would it be to modify gbak to support incremental backups? Is
>the generation number (is this the correct term?) backed up with the
>data?

Tough. Gbak makes a logical backup of the database - it gets the data and
metadata and when it does a "restore" it creates and populates a new
database. It has no idea of generations or anything of the sort. On the
other hand, replication will maintain a live copy of the database, as will
shadowing, and other techniques that are being introduced.


Regards,


Ann