Hello Karol,

>>>Possible further enhancements during index re-creation would be to
> re-create several indexes in parallel becoming more and more IO bound,
> especially with low latency storage. >>>AFAIK InterBase added something
> like that in a recent version. >>Potentially Firebird has that on the
> roadmap as well.
>
>
> yes, Interbase XE7 have this and restore speed is 2 times faster then in XE3
> but it is still 2 times slower then restore time on FB3 ;)
>
> We have 5GB database and times looks like with the same restore settings
> buffers and others settings, and the same db structure and data:
>
> IB XE3 - 93 minutes
> IB XE7 - 45 minutes
> FB 3- 26 minutes

From a throughput perspective, this would mean:

IB XE3 => 0,918 MB/s
IB XE7 => 1,896 MB/s
FB 3 => 3,282 MB/s

To be honest, astonishing low numbers in 2015, for all three.


--
With regards,
Thomas Steinmaurer
http://www.upscene.com

Professional Tools and Services for Firebird
FB TraceManager, IB LogManager, Database Health Check, Tuning etc.

> Regards,
> Karol Bieniaszewski
>
>
> ----- Reply message -----
> Od: "Thomas Steinmaurer ts@... [firebird-support]"
> <firebird-support@yahoogroups.com>
> Do: <firebird-support@yahoogroups.com>
> Temat: [firebird-support] Database restore speed with IBExpert and Gbak
> Data: wt., maj 26, 2015 19:02
> Hello Walter,
>
>
>
>> Hello Thomas
>
>>
>
>> That seems an interesting idea. Can you explain it with more details?
>
>
>
> For the restore process, gbak supports a -BU(FFERS) switch to override
>
> the database page buffer value. While page buffers tends to be rather
>
> small for Classic/SuperClassic hosted databases, you could try to
>
> increase that value by up to a factor of 100 through the -BU switch for
>
> the restore process.
>
>
>
> This gives the restore connection a much higher Firebird page cache. But
>
> this setting is persisted in the header page after the restore, thus
>
> before going back to production, you have to reset to the original value.
>
>
>
> I can't recall my exact test results from the past. There was also some
>
> sort of sweet spot where further increasing didn't help anymore, so run
>
> your own tests before applying that in your environment.
>
>
>
> Possible further enhancements during index re-creation would be to
>
> re-create several indexes in parallel becoming more and more IO bound,
>
> especially with low latency storage. AFAIK InterBase added something
>
> like that in a recent version. Potentially Firebird has that on the
>
> roadmap as well.
>
>
>
> --
>
> With regards,
>
> Thomas Steinmaurer
>
> http://www.upscene.com/
>
>
>
> Professional Tools and Services for Firebird
>
> FB TraceManager, IB LogManager, Database Health Check, Tuning etc.
>
>
>
>> Greetings.
>
>>
>
>> Walter.
>
>>
>
>>
>
>> On Tue, May 26, 2015 at 12:25 PM, Thomas Steinmaurer ts@...
>
>> <mailto:ts@...> [firebird-support]
>
>> <firebird-support@yahoogroups.com
>
>> <mailto:firebird-support@yahoogroups.com>> wrote:
>
>>
>
>> __
>
>>
>
>> Halim,
>
>>
>
>> > Thank you for your reply.
>
>> > I just tested a GBAK restore using -se(rvice) switch on a 1 GB DB. It
>
>> > took about 8 minutes. Restoring the same database using IBExpert took
>
>> > about 3 minutes.
>
>> > I'm looking for a faster restore time because I want to automate the
>
>> > process using a batch file. Our DB is over 50 GB.
>
>>
>
>> What is the size of table vs. index data?
>
>>
>
>> Restore is basically limited by single core throughput and I've hardly
>
>> seen restore being IO bound.
>
>>
>
>> What you could try is to provide a much larger (temporary) page buffers
>
>> value (which you have to reduce before the restored database is
>
>> going to
>
>> be used in production!) during the restore, which might help during
>
>> index re-creation.
>
>>
>
>> --
>
>> With regards,
>
>> Thomas Steinmaurer
>
>> http://www.upscene.com/
>
>>
>
>> Professional Tools and Services for Firebird
>
>> FB TraceManager, IB LogManager, Database Health Check, Tuning etc.
>
>>
>
>>
>
>>
>
>>
>
>>
>
>
>
>
>
>
>
>
>
>