| Subject | Re: [firebird-support] gbak /tmp minimum disk space |
|---|---|
| Author | Helen Borrie |
| Post date | 2007-11-22T01:30:14Z |
At 11:28 AM 22/11/2007, you wrote:
For restore, it depends on the size of your largest index. That requires some research from you in your development lab since, obviously, some large indexes grow slowly and some small ones grow fast. You should be able to develop some statistics that give you an idea of how much temp space you need.
Restore (use the Create option, please!) reads the text file and reconstructs the database from scratch. So, obviously, you need to have (non-temp) space adequate to accommodate a clean database. Usually this space is much smaller than the size of the DB that was backed up - but how much depends greatly on how well maintained the database is from day to day.
The first thing restore does is to create the database; then it creates the system objects; then user objects (permissions, generators, tables, PSQL modules, etc.). Next, it installs constraints embryonically and pushes data into the tables. At this point RI constraints are not enforced: indexes are yet to be built for them.
Finally, the indexes are built, beginning with the constraint indexes. Here is where temp space is used. The widest indexes (key fields large, composite keys, collations) on the largest tables need the most temp space.
If you are just allowing your server to use the generic temp space that is defined by the OS, you are not doing yourself any favours. You can't control how much of that space gets used by other applications. Always configure temp space explicitly, via the firebird.conf parameter TempDirectories. Choose an ample partition on your fastest disk and make sure that disk gets defragged regularly. You can assign multiple temp spaces if you need to: the server will move on to request space from the next location[s] if the OS can't deliver enough from the first one.
Firebird itself can't tell you the amount of free space but it will bark at you when it doesn't get what it asks for. Controlling your own temp space and monitoring the adequacy of free space in your temp directories is definitely a part of "good practice" in managing a database server. You can always configure more space when it's needed...relying only on a free space check as part of a *user-initiated* activity isn't quite the *ideal* way to manage a database server - it's a lot like a "morning-after pill".
./heLen
>Recently I have noticed gbak failing to complete a backup/restore whenRestore uses temp space for index rebuilding. Backup doesn't use it.
>the disk space in my temporary folder is low and the database size is
>large. I would like to add some automatic disk space checking before I
>start up the backup/restore process. But, of course, I need to know
>the minimum safe amount of disk space required for a backup/restore
>for a database of a certain size.
>Are there any specific guidelines I should be following?Assuming you mean "overall disk space", for backup, allow 30-40% of database size in your .fbk location.
For restore, it depends on the size of your largest index. That requires some research from you in your development lab since, obviously, some large indexes grow slowly and some small ones grow fast. You should be able to develop some statistics that give you an idea of how much temp space you need.
>I can probably assume a safe minimum is free_space>=database_size butBackup queries the database and writes data out to a standardized (XDR) text file.
>since the database could be fairly large, it would be nice to know if
>gbak would not use more than a specific amount of free space, or a
>specific percent of the database size, or maybe the size of the
>largest table.
Restore (use the Create option, please!) reads the text file and reconstructs the database from scratch. So, obviously, you need to have (non-temp) space adequate to accommodate a clean database. Usually this space is much smaller than the size of the DB that was backed up - but how much depends greatly on how well maintained the database is from day to day.
The first thing restore does is to create the database; then it creates the system objects; then user objects (permissions, generators, tables, PSQL modules, etc.). Next, it installs constraints embryonically and pushes data into the tables. At this point RI constraints are not enforced: indexes are yet to be built for them.
Finally, the indexes are built, beginning with the constraint indexes. Here is where temp space is used. The widest indexes (key fields large, composite keys, collations) on the largest tables need the most temp space.
If you are just allowing your server to use the generic temp space that is defined by the OS, you are not doing yourself any favours. You can't control how much of that space gets used by other applications. Always configure temp space explicitly, via the firebird.conf parameter TempDirectories. Choose an ample partition on your fastest disk and make sure that disk gets defragged regularly. You can assign multiple temp spaces if you need to: the server will move on to request space from the next location[s] if the OS can't deliver enough from the first one.
Firebird itself can't tell you the amount of free space but it will bark at you when it doesn't get what it asks for. Controlling your own temp space and monitoring the adequacy of free space in your temp directories is definitely a part of "good practice" in managing a database server. You can always configure more space when it's needed...relying only on a free space check as part of a *user-initiated* activity isn't quite the *ideal* way to manage a database server - it's a lot like a "morning-after pill".
./heLen