Subject | Re: [firebird-support] Re: Nbackup |
---|---|
Author | Jojakim Stahl |
Post date | 2008-11-13T14:12:31Z |
There are two (as far as I know) protocols how clients can communicate
with Firebird Server:
- a computer internal local protocol called XNET
with a connection string containing only the path to the database file
or an alias out of aliases.conf
- TCP
with a connection string starting with the hostname followed by a colon
followed by the path to the database file relative to the server.
Refer to <http://www.firebirdsql.org/manual/qsg2-databases.html>.
There are some command line utilities that do not (or can be told to do
not) take there route through the Server processes to access the database,
or at least do not always. One of this is nbackup which locks the database
and than copies it by direct file access via the OS file system layer.
Bye
Joja
Am 13.11.2008, 14:51 Uhr, schrieb Branimir Trumbic <seronimo@...>:
Jojakim
with Firebird Server:
- a computer internal local protocol called XNET
with a connection string containing only the path to the database file
or an alias out of aliases.conf
- TCP
with a connection string starting with the hostname followed by a colon
followed by the path to the database file relative to the server.
Refer to <http://www.firebirdsql.org/manual/qsg2-databases.html>.
There are some command line utilities that do not (or can be told to do
not) take there route through the Server processes to access the database,
or at least do not always. One of this is nbackup which locks the database
and than copies it by direct file access via the OS file system layer.
Bye
Joja
Am 13.11.2008, 14:51 Uhr, schrieb Branimir Trumbic <seronimo@...>:
> 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?
>
> 2. Can multiple database clients safely connect to the same database
> using direct access method ("C:\MyDb.fdb")? Under 'safely' I mean: no
> database corruption, deadlocks, transactions are safe, no multi thread
> problems or other problems that can be caused by concurrent database
> connections.
>
> I was under impression that if more then ONE database client is using
> SAME database, that all connections must go through TCP layer
> (localhost or remote) to ensure database stability (I'm using FireBird
> as superserver (as service) on Windows Server OS).
>
>
>
> Thanks,
>
> Branimir
>
>
> --- In firebird-support@yahoogroups.com, "Martijn Tonies"
> <m.tonies@...> wrote:
>>
>> Hi,
>>
>> > > Why do you need a localhost prefix? NBackup is expected to work fine
>> > > without it, regardless of the TCP port of the FB server.
>> >
>> > I need TCP, because I don't want 'direct access to the database file'
>> > as I understand that this kind of access is not multi-thread safe. All
>> > my database clients are connected to the database through TCP
>> > (localhost).
>>
>> NBackup only works by using direct access (via the server), you can
>> safely continu working on the database. Thread safety has nothing
>> to do with it.
>>
>> > > > 3. Is full nbackup database dump (-B0 option) compatible with
> the gbak
>> > > > dump and vice versa?
>> > >
>> > > Nope, they're completely different beasts.
>> >
>> > Pity, but I understand that gbak is doing some 'database cleaning'
>> > while performing backup and nbackup does not. If I start to use
>> > nbackup for regular backups, is there any other tool that can be used
>> > to 'maintain compact' database?
>>
>> gbak will not "maintain compact" the database either, it -can- clean
>> up the garbage, but the database file(s) will stay the same size.
>>
>> > - when making full backup, seems that whole database file is copied to
>> > the backup file, prior to this nbackup seems to lock database with
>> > ALTER DATABASE BEGIN BACKUP thus allowing somewhat safer copy...
>>
>> Not a "somewhat safer copy", this functionality was -exactly- created
>> for NBackup.
>>
>> > - when restoring database, original database file must not exist, you
>> > have to delete it manually
>> > - when making incremental backups u are never exactly sure what is
>> > last full backup file from which incremental backup is done. I
>> > recently found that you can find last full backup in the
>> > RDB$BACKUP_HISTORY syste table, sort by date and find last backup with
>> > level 0
>> > - only thing that I can say is that I've tested nbackup on 'live
>> > database with connected clients' and it seems to work without error
>> > and very fast.
>>
>> Which is what is was created for.
>>
>> > - with all these in mind and with warning that nbackup versions prior
>> > to 2.1.1 can cause database deadlock probably I should give up on
>> > incremental backups for firebird database until nbackup becomes more
>> > stable.
>> >
>> > Final question:
>> > Does anybody actually use nbackup for database backups? Anyone has
>> > practical experiences with this tool?
>>
>> Martijn Tonies
>> Database Workbench - tool for InterBase, Firebird, MySQL, NexusDB,
> Sybase
>> SQL Anywhere, Oracle & MS SQL Server
>> Upscene Productions
>> http://www.upscene.com
>> My thoughts:
>> http://blog.upscene.com/martijn/
>> Database development questions? Check the forum!
>> http://www.databasedevelopmentforum.com
>>
>
>
Jojakim