Subject | Re: Firebird database portability |
---|---|
Author | Adam |
Post date | 2006-11-29T22:58Z |
Chris,
Let me simplify the answer.
A firebird database is usually a single fdb file (but can be multiple
files or have other extensions, for simplicity I will talk about the
database as being a single fdb file, but the same applies even if it
is not).
When you ask whether the database is portable, pretty much everyone is
going to assume you want to know if you can copy that fdb file from
one computer to another computer. As I answered in my original
response, if you are copying it to a machine with the same endianness
(eg Intel -> AMD) and both machines are 32 bit or both machines are 64
bit, then yes. Otherwise, no - you will need to make a transportable
backup which will restore natively on the target machine.
I know Ann has on the architect list proposed a method "to allow two
systems that share alignment rules and datatypes to access the same
database, even if the systems have different endian rules".
You should *never* take a file system copy of a database while the
'server' is running. Running means different things to different
models. In some models, even if there are no users connected, the
engine could be finishing up some garbage collection.
Copying a database while it is 'in use' can cause:
* Inconsistent data in target.
(just look at careful writes, there is no way your FS is doing that -
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_expert3 )
* Server crash
* Reportedly can corrupt source
The GBAK tool and services API both provide methods of backing up a
database while the server is running. There are also third party
options like DBAK (not sure about whether there is a Linux port though).
There is a new NBACKUP tool that makes the appropriate changes to
allow a file system copy.
There are massive performance benefits to a freshly restored database
over one simply file copied. Nice balanced indices and no garbage.
Adam
Let me simplify the answer.
A firebird database is usually a single fdb file (but can be multiple
files or have other extensions, for simplicity I will talk about the
database as being a single fdb file, but the same applies even if it
is not).
When you ask whether the database is portable, pretty much everyone is
going to assume you want to know if you can copy that fdb file from
one computer to another computer. As I answered in my original
response, if you are copying it to a machine with the same endianness
(eg Intel -> AMD) and both machines are 32 bit or both machines are 64
bit, then yes. Otherwise, no - you will need to make a transportable
backup which will restore natively on the target machine.
I know Ann has on the architect list proposed a method "to allow two
systems that share alignment rules and datatypes to access the same
database, even if the systems have different endian rules".
> I was aware of Firebird's ability to have the database copied from aLet me clear this up.
> local machine, where it was being used solely by one person, to another
> location to be 'shared' by a server. I just wondered how far it went.
You should *never* take a file system copy of a database while the
'server' is running. Running means different things to different
models. In some models, even if there are no users connected, the
engine could be finishing up some garbage collection.
Copying a database while it is 'in use' can cause:
* Inconsistent data in target.
(just look at careful writes, there is no way your FS is doing that -
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_expert3 )
* Server crash
* Reportedly can corrupt source
The GBAK tool and services API both provide methods of backing up a
database while the server is running. There are also third party
options like DBAK (not sure about whether there is a Linux port though).
There is a new NBACKUP tool that makes the appropriate changes to
allow a file system copy.
There are massive performance benefits to a freshly restored database
over one simply file copied. Nice balanced indices and no garbage.
Adam