| Subject | Re: [firebird-support] Database restore speed with IBExpert and Gbak |
|---|---|
| Author | Thomas Steinmaurer |
| Post date | 2015-05-26T17:02:41Z |
Hello Walter,
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.
> Hello ThomasFor the restore process, gbak supports a -BU(FFERS) switch to override
>
> That seems an interesting idea. Can you explain it with more details?
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.
>
>
>
>
>