| Subject | RE: [firebird-support] Database Corrupted Due to Zero Disk Space |
|---|---|
| Author | Helen Borrie |
| Post date | 2009-04-02T06:56:10Z |
At 04:04 PM 2/04/2009, you wrote:
Of course, you *wouldn't* be letting them write backups onto the *same* hard disk that you're using for the database, would you now?
From the DB engine's POV, it has to ask the OS for blocks of disk space. Pre v.2.1, it asks for one "page" worth - how much this might be depends on the page size of that particular *database*. From v.2.1.1 onward, it asks for a larger number of pages' worth (which you can configure).
A freshly-restored database uses the least possible disk space, because the restore has no freed-up space to concern itself with: it just lays in pages as required and all data is just one record version per record. So, of course, estimating needs on the basis of the size of a newly (or recently) restored database is - well - gormless. You have to make disk available for the largest possible size that the file will grow to, taking in garbage as well as data growth.
And - well - if you have your database mounted on the same hard disk partition that the whole organisation is using for internet caches, M$ exchange, M$ shadows, swap files and what-all else is munching up server storage, you're walking the high wire, anyway. A nice big dedicated disk (or a RAID pair) is exponentially cheaper than the cost of recovering from corruptions.
./heLen
>>>Subject: Re: [firebird-support] Database Corrupted Due to Zero DiskSorry, but this must be something you provide for. The database engine has no way of knowing how much disk space there is, nor how much is needed, nor whether the host is allocating space to other applications. It is a hardware management issue for the administrator of *any* server host to ensure that there's enough diskspace available for applications s/he is running there.
>Space
>> Gfix is unable to fix databases corrupted this way. Either restore
>>database from backup or call database repair service.
>> SY, SD.
>
>Ouch! Is there any easy way of querying the Firebird Server for free
>disk space on the server when logging on from a client PC? That way we
>can alert the user they are running out of space when they log on, or
>are about to do a restore etc.
Of course, you *wouldn't* be letting them write backups onto the *same* hard disk that you're using for the database, would you now?
From the DB engine's POV, it has to ask the OS for blocks of disk space. Pre v.2.1, it asks for one "page" worth - how much this might be depends on the page size of that particular *database*. From v.2.1.1 onward, it asks for a larger number of pages' worth (which you can configure).
A freshly-restored database uses the least possible disk space, because the restore has no freed-up space to concern itself with: it just lays in pages as required and all data is just one record version per record. So, of course, estimating needs on the basis of the size of a newly (or recently) restored database is - well - gormless. You have to make disk available for the largest possible size that the file will grow to, taking in garbage as well as data growth.
And - well - if you have your database mounted on the same hard disk partition that the whole organisation is using for internet caches, M$ exchange, M$ shadows, swap files and what-all else is munching up server storage, you're walking the high wire, anyway. A nice big dedicated disk (or a RAID pair) is exponentially cheaper than the cost of recovering from corruptions.
./heLen