by Pavel Císař
Before "cheap" and reliable SSD drives, some Firebird users with medium-sized databases and plenty of RAM would speed up database operations using RAM-disks. However, because RAM-disk is not permanent memory, it's necessary to get the database onto permanent storage (HDD), either in parallel, or as part of a backup strategy. The Firebird SHADOW mechanism was natural choice to solve this problem. As it's possible to create the shadow on HDD, so read operations are performed from database that resides in RAM-disk, but all writes are also stored in shadow file on HDD. Alternatively it's possible to create (an additional) shadow on demand as a physical database backup.
Using the shadowing mechanism as a physical backup has one pitfall: it's not possible to disconnect the shadow from the primary database without destroying the associated shadow file (the DROP SHADOW command deletes it). However, clever users discovered a neat trick how not let the database server do that:
- create a fake shadow file somewhere (any file).
- update the RDB$FILES table and replace the shadow filename with the fake file name.
- drop the shadow. The database engine disconnects the shadow, deletes the fake file and the shadow file is preserved.
However, this trick also has several drawbacks:
- The shadow file is not updated using the dirty pages in the cache when its dropped. It should be still safe as everything on disk should be internally consistent due to careful write, but it's recommended to verify the shadow file for internal consistency (usign GFIX).
- This trick doesn't work anymore with Firebird 3.0, because this version does not allow direct modification to system tables.
- Since version 2.5 it's much better to use NBACKUP to create physical backups instead of utilising shadows.