At 12:58 AM 9/08/2007, Dalton Calford wrote:

>To continue with this thread - I have been performing a series of tests.
>
>Test platform
>
>2x Quad Core Xeon Processor 2.33Ghz
>16 GB Ram (667 MHz.)
>4x 73 GB 15K rpm Serial Attach SCSI - 3 Gbps Harddrives
>
>OS - Fedora Core 7 32 bit and 64 bit
>
>Test Database - a small 28GB database, with only three tables. Data
>has natural primary keys - two indexes per table
>All restore operations are coming from a single gbak file in
>transportable format.
>
>Firebird libraries set to client instead of embed.
>
>Firebird 2.01 32 bit and 64 bit, Firebird 1.53 32 bit
>
>Fedora 64 Bit, Firebird 2 64 Bit
>
>gbak -c backup.gbak /home/fb/restore1.001 -page_size 16384 -bu 10000 -v
>-y restore1.out
>Total time for the restore - 5 hours 8 minutes
>gbak -c backup.gbak localhost:/home/fb/restore2.001 -user SYSDBA
>-password masterkey -page_size 16384 -bu 10000 -v -y restore2.out
>Total time for the restore - 11 hours, 19 minutes

[etc.]
It appears that the fb_inet_server process is much slower in generating

>indexes than gbak is.
>I monitored the process and very little CPU bouncing was going on - the
>fb_inet_server process remained on the same CPU for the whole process
>while the gbak process rarely jumped cpu's

How about including a test that uses service_mgr?

gbak -c -se localhost:service_mgr /path/to/backup.gbak
/home/fb/restore2.001 -user SYSDBA -password masterkey -page_size
16384 -bu 10000 -v -y restore2.out

./heLen