| Subject | Re: [firebird-support] Firebird file questions |
|---|---|
| Author | Helen Borrie |
| Post date | 2011-01-25T22:41:39Z |
At 10:52 AM 26/01/2011, tseyfarth wrote:
A Firebird database is one file, whose space is managed by the Firebird server engine. It stores "table" data and index data on "pages" (blocks of disk of a configurable size). The "table" concept is an inventory of disk addresses it maintains so that it knows where to find the requested data.
A data page will store only data for a single table but the data pages for any given table may be physically anywhere in the file.
The engine cleans up obsolete record versions from the data and index pages and recycles the space freed for re-use. The OS has no idea of what is stored where. All it knows about is requests from the engine to allocate another block of disk space. Later versions of Fb request two pages at a time, although this is also configurable.
In fact, on non-Windows platforms, a Fb database doesn't need to be a file at all - it can be maintained directly on raw disk space and accessed as a device.
In the days when disks and file size limits were small compared to the potential size of databases, a database could be split up across several files which could be physically located on different disks. Logically, the multi-file database is no different to the single-file one: only the engine knows where anything is. You can still do the multi-file thing, although it's mostly not necessary any more.
./heLen
>Hello all.Those desktop database systems are "file-based", meaning "records" are written to "tables" (groups of files that are managed by the OS file system). They use filesystem locking facilities (write locks, etc.) to manage concurrency locking.
>
>I am a new user to Firebird and to this forum. I noticed with FB, there is only a single file created with the extension .FDB
>
>In other SQL relational DB's I've used (mySQL, Postgre, Pervasive/Btrieve) there is always a file for each table.
A Firebird database is one file, whose space is managed by the Firebird server engine. It stores "table" data and index data on "pages" (blocks of disk of a configurable size). The "table" concept is an inventory of disk addresses it maintains so that it knows where to find the requested data.
A data page will store only data for a single table but the data pages for any given table may be physically anywhere in the file.
The engine cleans up obsolete record versions from the data and index pages and recycles the space freed for re-use. The OS has no idea of what is stored where. All it knows about is requests from the engine to allocate another block of disk space. Later versions of Fb request two pages at a time, although this is also configurable.
In fact, on non-Windows platforms, a Fb database doesn't need to be a file at all - it can be maintained directly on raw disk space and accessed as a device.
>Am I using the correct flavor of FB?All "flavours" of Fb store and retrieve data in exactly the same way. Each *version* of Fb (1.0.x, 1.5.x, 2.0.x, 2.1.x, 2.5.0 so far, with 3.0 waiting in the wings) creates databases with a new on-disk structure (ODS). An older *version* of the server cannot read databases created with an ODS that is newer than the ODS that it creates itself; new *versions* of the server can read databases with an older ODS.
In the days when disks and file size limits were small compared to the potential size of databases, a database could be split up across several files which could be physically located on different disks. Logically, the multi-file database is no different to the single-file one: only the engine knows where anything is. You can still do the multi-file thing, although it's mostly not necessary any more.
>Any info on the subject would be greatly appreciated!Ask specific questions - you'll get a better range of answers. Busy people tend to ignore very broad questions!
./heLen