Hi,

I've run some tests, using firebird 2.1.5 on centos 5.9, a database of 36Gb:

22 mins $ gbak -user sysdba -pass xxx -backup localhost:/opt/db/mydb.fdb
/opt/archive/db/nu3.fbk

28 mins $ gbak -user sysdba -pass xxx -backup -se localhost:service_mgr
/opt/db/mydb.fdb /opt/archive/db/nu2.fbk

29 mins $ gbak -user sysdba -pass xxx -backup /opt/db/mydb.fdb
/opt/archive/db/nu1.fbk

22 mins $ gbak -user sysdba -pass xxx -backup localhost:/opt/db/mydb.fdb
stdout > /opt/archive/db/nu0.fbk


my original 6 hours for 76Gb included (I didn't realise at the time)
compression of the backup 'on the fly' (piped stdout from gbak into gzip),
removing this and doing the gzip separately saved 50% of the time compared
to piping it

e.g. 37GB database was taking 120 mins, now gbak backup is 30 mins & gzip
is 30 mins, so total time is halved and the period gbak is running (holding
a transaction open) is a quarter

On 11 April 2013 13:16, Dmitry Kuzmenko <kdv@...> wrote:

> **
>
>
> Hello, Nick!
>
> Thursday, April 11, 2013, 4:06:22 PM, you wrote:
>
> NU> all programs that access the database use the same path component as
> either
> NU> "localhost:/db/mydb.fdb" - if running on the server and
> NU> "myhost:/db/mydb.fdb" - if accessing it from elsewhere
>
> no difference.
>
> NU> possible new setup:
>
> NU> all programs that access the database use the same path component as
> either
> NU> "/db/mydb.fdb" - if running on the server and "myhost:/db/mydb.fdb" -
> if
> NU> accessing it from elsewhere
>
> mmm, why ? why to use local protocol? Yes, you can mix connection
> strings, but here is another point - what if you will need to move
> your applications from server? Will reconfigure connection string for
> all of them?
>
> NU> Dmitry has suggested that I should get significant performance
> improvement
> NU> by avoiding the tcp stack but I recall (perhaps wrongly) there being
> issues
> NU> with this approach.
>
> you missed the point that I said about different gbak behavior.
>
> 1. gbak -b -g localhost:c:\db\db.fdb localfile.fbk
> here backup transfers data from server to localfile via tcp
>
> 2. gbak -b -g -se localhost:service_mgr c:\db\db.fdb localfile.fbk
> here gbak sends COMMAND to the server (via tcp) to make backup by
> itself.
> And localfile.fbk - is local to the server, not to gbak.
>
> For better understanding I can add that if you kill gbak
> with the first command line, the backup will stop, because gbak did it.
>
> With the second command line backup will still continue, because
> after gbak sent command via -se, it only waits for output from the
> server, not for the data of the database. And the server does backup,
> not gbak.
>
> And, switching protocol for your local
> server apps will not give you any visible performance improvement.
> Gbak is another thing, it reads (without -se) the whole database.
> So, for gbak speed protocol matters.
>
> --
> Dmitry Kuzmenko, www.ib-aid.com
>
>
>



--
Nick Upson, Telensa Ltd


[Non-text portions of this message have been removed]