Subject | Re: [firebird-support] Re: Gbak Restore - SuperServer vs. SuperClassic |
---|---|
Author | Thomas Steinmaurer |
Post date | 2014-11-17T10:40:01Z |
Hello Michael,
Beside your gbak restore issue, your counters here show some interesting throughput numbers, when taking the creation date of the database into account:
~ 170 transactions / sec
~ 9 connections / sec
Especially opening 9 physical connections per second sounds a bit like a design flaw adding unnecessary overhead.
And a 96GB database with a page size of 4K might result in index depth > 3 for larger tables.
- Where is the restore process stuck? Probably while creating indexes?
- I would seriously look into running gbak for both, backup and restore through the Services Manager. Check out the -se option
Just some hints, but I don't have a real answer for your SS vs. SC issue.
--
With regards,
Thomas Steinmaurer
http://www.upscene.com
Professional Tools and Services for Firebird
FB TraceManager, IB LogManager, Database Health Check, Tuning etc.
> * What is the page buffers value at database level? (gstat -h)Ok, so at least you are not running with a page buffers value of 0 which maps to a default value in firebird.conf of 75 for CS/SC.
> E:\DB\Kaufmann>"c:\Program Files\Firebird\Firebird_2_5\bin\gstat.exe"
> localhost:
> e:\db\Kaufmann\OCCEasyPos.FDB -h
>
>
> Database "e:\db\Kaufmann\OCCEasyPos.FDB"
> Database header page information:
> Flags 0
> Checksum 12345
> Generation 101077117
> Page size 4096
> ODS version 11.2
> Oldest transaction 96356704
> Oldest active 96356705
> Oldest snapshot 96356705
> Next transaction 96384172
> Bumped transaction 1
> Sequence number 0
> Next attachment ID 4930121
> Implementation ID 26
> Shadow count 0
> Page buffers 2048
> Next header page 0
> Database dialect 1
> Creation date Nov 11, 2013 23:47:15
> Attributes force write
>
>
> Variable header data:
> Sweep interval: 0
> *END*
Beside your gbak restore issue, your counters here show some interesting throughput numbers, when taking the creation date of the database into account:
~ 170 transactions / sec
~ 9 connections / sec
Especially opening 9 physical connections per second sounds a bit like a design flaw adding unnecessary overhead.
And a 96GB database with a page size of 4K might result in index depth > 3 for larger tables.
> E:\DB\Kaufmann>- Any special reason that you use both -FIX* options everytime for the restore?
>
>
>
>
>
>
>
>
>
>
> * How does your gbak restore call look like?
>
> GBak -C -User %1 -Pas %2 G:\FBDump\OCCEasyPos.fbk
> "LocalHost:F:\DB\Kaufmann\Uddannelse\OCCEasyPos.fdb" -v -rep -o
> -FIX_FSS_METADATA ISO8859_1 -fix_fss_data ISO8859_1 -y
> "G:\FBDump\RestoreEasyPos.txt"
- Where is the restore process stuck? Probably while creating indexes?
- I would seriously look into running gbak for both, backup and restore through the Services Manager. Check out the -se option
Just some hints, but I don't have a real answer for your SS vs. SC issue.
--
With regards,
Thomas Steinmaurer
http://www.upscene.com
Professional Tools and Services for Firebird
FB TraceManager, IB LogManager, Database Health Check, Tuning etc.