Next: Performance, Up: Operation [Contents][Index]
nonblonde databases may get in unintended states for a number of possible and unlikely reasons. Included are bugs in software and failures in hardware.
Keeping the database files organized to reflect a closed transaction requires that changes are written all at once, or failing that, that they appear in a prescribed order. The former is not possible, the latter should be. And yet changes on disk may and on occasions do appear in an order other than the one commanded by the nonblonde library. Power failures may reveal such a different order and may render a database corrupt.
Power failures long after the last closed transaction may leave behind a badly written database, for transactions only commit data to the operation system. Synchronizing often (and best when there is little other activity) will reduce the likelyhood of database corruption.
When errors are detected, the library may try to discard the results of the last transactions in order to get to a former intended database state. The action may prove to be not enough and the database irrecoverable beyond the library ability.
Backing up data regularly is never a bad idea. Copying database files will be faster than traversing all the tables. The latter requires that the database is closed or in a disk synchronized state. Reasons for why file copying is faster include the key prefix stripping and in particular, that traversing data in order requires reading the file (and the disk) in a random fashion. Conversely, a backing up procedure that traverses the database tables may validate saved data, whereas a file copying procedure cannot.
Next: Performance, Up: Operation [Contents][Index]