Subject | Re: [firebird-support] Firebird BLOB vs. File Name Storage |
---|---|
Author | Ann W. Harrison |
Post date | 2004-03-29T19:42:05Z |
At 10:47 AM 3/29/2004, Edward Flick wrote:
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.
replug it, and continue.
marked as inconsistent and will be removed overtime.
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.
commits. It may be present on the disk, but logically, it's just useless
bits until the transaction commits.
size which affects the ability to backup and restore the database.
Regards,
Ann
www.ibphoenix.com
We have answers.
>Assuming I am only selecting or inserting data into my database, what isThere is no "mid commit". A commit is an atomic operation, consisting of
>the worst possible outcome scenario assuming the drive is not bad, and
>there is a sudden power loss mid transaction commit:
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 workNo. 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 inNo. Or maybe yes and no. If a transaction fails, all its data will be
>transaction
marked as inconsistent and will be removed overtime.
>* Database corrupted, gfix will fix it, but lose only records which haveAs above, the commit applies to the state of the transaction. Records
>not finished commiting
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 transactionA 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 finishedAs above.
>commiting
>As far as I am concerned as long as the database (worst case) does notThe usual reason for storing images outside the database is sheer database
>get corrupted beyond repair by gfix, I am fine with storing images in
>the database.
size which affects the ability to backup and restore the database.
Regards,
Ann
www.ibphoenix.com
We have answers.