Firebird Documentation Index → Firebird 1.0 Quick Start → How to corrupt a database |
Firebird stores and maintains all of the metadata for its own and
your user-defined objects in – a Firebird database! More precisely, it
stores them in relations (tables) right in the database itself. The
identifiers for the system tables, their columns and several other types
of system objects begin with the characters
RDB$
.
Because these are ordinary database objects, they can be queried and manipulated just like your user-defined objects. However, just because you can does not say you should. The Firebird engine implements a high-level subset of SQL (DDL) for the purpose of defining and operating on metadata objects, typically through CREATE, ALTER and DROP statements.
It cannot be recommended too strongly that you use DDL – not direct SQL operations on the system tables – whenever you need to alter or remove metadata. Defer the “hot fix” stuff until your skills in SQL and your knowledge of the Firebird engine become very advanced. A wrecked database is neither pretty to behold nor cheap to repair.
Firebird is installed with forced writes (synchronous writes) enabled by default. Changed and new data are written to disk immediately upon posting.
It is possible to configure a database to use asynchronous data writes – whereby modified or new data are held in the memory cache for periodic flushing to disk by the operating system's I/O subsystem. The common term for this configuration is forced writes off (or disabled). It is sometimes resorted to in order to improve performance during large batch operations.
The big warning here is: do not disable forced writes on a Windows server. It has been observed that the Windows server platforms do not flush the write cache until the Firebird service is shut down. Apart from power interruptions, there is just too much that can go wrong on a Windows server. If it should hang, the I/O system goes out of reach and your users' work will be lost in the process of rebooting.
Windows 9x and ME do not support deferred data writes
One of the restore options in the gbak
utility (gbak -r[eplace]
) allows you to restore a
gbak file over the top of an existing database. It is possible for this
style of restore to proceed without warning while users are logged in to
the database. Database corruption is almost certain to be the
result.
Be aware that you will need to design your Admin tools and procedures to prevent any possibility for any user (including SYSDBA) to restore to your active database if any users are logged in.
For gbak instructions see chapter 21, Database Backup and Restore, of Using Firebird.
For instructions about blocking access to users, see chapter 14, Getting exclusive access to a database, of Using Firebird.
If is practicable to do so, it is recommended to restore to spare
disk space using the gbak -c[reate]
option and test
the restored database using isql or your
preferred admin tool. If the restored database is good, shut down the
server. Make a filesystem copy of the old database and then copy the
restored database file (or files) over their existing
counterparts.
Firebird Documentation Index → Firebird 1.0 Quick Start → How to corrupt a database |