FirebirdSQL logo

Disabling forced writes

Firebird is installed with forced writes (synchronous writes) enabled by default.Modifications 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 an attempt to improve performance during large batch operations.

Disabling forced writes on Windows

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.

docnext count = 5

Disabling forced writes on Linux

Linux servers are safer for running an operation with forced writes disabled temporarily.Still, do not leave it disabled once your large batch task is completed, unless you have a very robust fall-back power system.

Restoring a backup to a running database

One of the restore options in the gbak utility (gbak -rep[lace_database]) allows you to restore a gbak file over 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.

Note

Notice that the shortest form of this command is gbak -rep, not gbak -r as it used to be in older Firebird versions.What happened to gbak -r?It is now short for gbak -recreate_database, which functions the same as gbak -c[reate] and throws an error if the specified database already exists.You can force overwriting of the existing database by adding the o[verwrite] flag though.This flag is only supported with gbak -r, not with gbak -c.

These changes have been made because many users thought that the -r switch meant restore instead of replace — and only found out otherwise when it was too late.

Warning

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.

If is practicable to do so, it is recommended to restore to spare disk space using the gbak -c option and test the restored database using isql or your preferred admin tool.If the restored database is good, shut down the old database (you can use the gfix command-line tool for this;see Firebird Database Housekeeping Utility (HTML) or Firebird Database Housekeeping Utility (PDF)).Make a filesystem copy of the old database just in case and then copy the restored database file(s) over their existing counterparts.

Allowing users to log in during a restore

If you do not block access to users while performing a restore using gbak -rep then users may be able to log in and attempt to do operations on data.Corrupted structures will result.

How to get help

The community of willing helpers around Firebird goes a long way back, to many years before the source code for its ancestor, InterBase® 6, was made open source.Collectively, the Firebird community does have all the answers!It even includes some people who have been involved with it since it was a design on a drawing board in a bathroom in Boston.

How to give help

Firebird exists, and continues to be improved, thanks to a community of volunteers who donate their time and skills to bring you this wonderful piece of software.But volunteer work alone is not enough to keep an enterprise-level RDBMS such as Firebird up-to-date.The Firebird Foundation supports Firebird development financially by issuing grants to designers and developers.If Firebird is useful to you, and you’d like to give something back, please visit the Foundation’s pages and consider making a donation or becoming a member or sponsor.