>>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 Regards, Karol Bieniaszewski ----- Reply message ----- Od: "Thomas Steinmaurer t...@iblogmanager.com [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 t...@iblogmanager.com > <mailto:t...@iblogmanager.com> [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. > > > > >
