Subject | Re: Nbackup |
---|---|
Author | Adam |
Post date | 2008-11-13T22:23:19Z |
--- In firebird-support@yahoogroups.com, "Branimir Trumbic"
<seronimo@...> wrote:
Imagine you wrote a tool that did the following:
* Connect to the database (in the same method as any other client
program).
* Query the system tables to get the table structures, index
definitions, constraints etc, then wrote these out to a file.
* Run a select * from each table, then wrote these out to a file.
Congratulations, you just wrote gbak.
Now imagine you wrote a different tool that did the following.
* Flag the database to tell the database engine it is not allowed to
write to the file any more, but instead it must keep track of any
changes inside a delta file.
* Read the database file directly byte-by-byte from the disk and write
those bytes to a destination file.
* Flag the database to tell the database engine it is now allowed to
write to the file again, and that it needs to synchronise the changes
in the delta file.
Congratulations, you just wrote NBackup.
(Apologies for oversimplifying what happens under the hood).
So conceptually, there is no difference between running gbak on the
server or on a client machine; just like in any client-server
application there is no difference (apart from speed) whether the
client and server are the same machine or not.
But NBackup, by the way it works, must be able to take a byte-wise
copy of the database file. Normally such a byte-wise copy would
potentially cause corruption, but because it has temporarily flagged
the database in such a way that the database engine will not touch the
file during the copy it is safe in this case.
In terms of your earlier presumption that gbak does database cleaning
as it goes, this is true by default but if you use the -g switch, it
does not. Gbak is still a lot slower than NBackup. The reason is
simple. GBak is treating the database like a logical data store, and
so must obey access rules in terms of record level visibility etc. On
the otherhand, NBackup is simply streaming bytes between files.
Adam
<seronimo@...> wrote:
>GBak and NBackup are conceptually different beasts.
> Just some unrelated questions that is bugging me and I didn't find
> right answer:
>
> 1. What is difference between database connection string "C:\MyDb.fdb"
> and "localhost:C:\MyDb.fdb", or in other words what is difference
> between 'direct access' and 'tcp' access?
Imagine you wrote a tool that did the following:
* Connect to the database (in the same method as any other client
program).
* Query the system tables to get the table structures, index
definitions, constraints etc, then wrote these out to a file.
* Run a select * from each table, then wrote these out to a file.
Congratulations, you just wrote gbak.
Now imagine you wrote a different tool that did the following.
* Flag the database to tell the database engine it is not allowed to
write to the file any more, but instead it must keep track of any
changes inside a delta file.
* Read the database file directly byte-by-byte from the disk and write
those bytes to a destination file.
* Flag the database to tell the database engine it is now allowed to
write to the file again, and that it needs to synchronise the changes
in the delta file.
Congratulations, you just wrote NBackup.
(Apologies for oversimplifying what happens under the hood).
So conceptually, there is no difference between running gbak on the
server or on a client machine; just like in any client-server
application there is no difference (apart from speed) whether the
client and server are the same machine or not.
But NBackup, by the way it works, must be able to take a byte-wise
copy of the database file. Normally such a byte-wise copy would
potentially cause corruption, but because it has temporarily flagged
the database in such a way that the database engine will not touch the
file during the copy it is safe in this case.
In terms of your earlier presumption that gbak does database cleaning
as it goes, this is true by default but if you use the -g switch, it
does not. Gbak is still a lot slower than NBackup. The reason is
simple. GBak is treating the database like a logical data store, and
so must obey access rules in terms of record level visibility etc. On
the otherhand, NBackup is simply streaming bytes between files.
Adam