Subject Re: [firebird-support] Firebird BLOB vs. File Name Storage
Author Ann W. Harrison
At 10:47 AM 3/29/2004, Edward Flick wrote:


>Assuming I am only selecting or inserting data into my database, what is
>the worst possible outcome scenario assuming the drive is not bad, and
>there is a sudden power loss mid transaction commit:

There is no "mid commit". A commit is an atomic operation, consisting of
the physical write of a single page containing the transaction
state. Before that page is written, all pages that the transaction changed
have been written to disk. The on-disk representation is such that change
written by a transaction that rolls back, or dies in some mishap, are
recognizable and will be removed by subsequent users.

>* Entire database or table absolutely corrupted, gfix won't work

No. If you have forced write on, you should be able to unplug the server,
replug it, and continue.

>* Database corrupted, gfix will fix it, but lose all records involved in
>transaction

No. Or maybe yes and no. If a transaction fails, all its data will be
marked as inconsistent and will be removed overtime.

>* Database corrupted, gfix will fix it, but lose only records which have
>not finished commiting

As above, the commit applies to the state of the transaction. Records
belong to transactions that create them. If their transaction fails, they
disappear. When a transaction modifies or deletes a record, then fails,
the record reverts to its previous state.

>* Database not corrupted, but still lose all records involved in transaction

A record isn't part of the database until the transaction that created it
commits. It may be present on the disk, but logically, it's just useless
bits until the transaction commits.

>* Database not corrupted, but lose only records which have not finished
>commiting

As above.


>As far as I am concerned as long as the database (worst case) does not
>get corrupted beyond repair by gfix, I am fine with storing images in
>the database.

The usual reason for storing images outside the database is sheer database
size which affects the ability to backup and restore the database.


Regards,

Ann
www.ibphoenix.com
We have answers.