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 [email protected] [firebird-support]" > <[email protected]> > Do: <[email protected]> > 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 [email protected] > >> <mailto:[email protected]> [firebird-support] > >> <[email protected] > >> <mailto:[email protected]>> 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. > >> > >> > >> > >> > >> > > > > > > > > > >
