Em 1/5/2012 14:51, Fabricio Araujo escreveu:

> Remember Alexandre, GBAK (and Services API) are a DataPump-style backup,
> diffent of NBAK (which AFAIR restores database pages instead of loginal
> structure)
> which makes me think: you tried that restore on a heavily fragmented
> storage?
>
> Since GBAK works as a datapump, certainly it makes the Server grows the
> *.fdb file
> so many times. Would be nice if we could (if it already doesn't
> do that) specify an file size on restore and it could be created using
> instant file instancing
> (I know it have something to do with a volume operation, since the
> service user
> need to have disk volume operations' permission on Windows - MSSQL use that
> and brings the restore multi GB time to a half - or less).
>
>

Yes, I know, but the same occurs to an gorwing database file with just
simple types (varchar, date, integer, etc.) and the time is considerably
diferent. There is a new feature on Fb (I can't remember in wich
version) that grows the database more than a page at once, this was
implemented to avoid disk full problems, but as a side effect it could
improve a lot the restore time.

But the case I faced has something to do with my hardware and/or
filesystem. The very same back-up restored under 3s on Cantu's and
Kuzmenko's computers, where in my server it need more than 10 minutes to
finish. I did another test on my notebook out of my VM and it took under
3s too.

I ruled hardware out to fast, because I faced the slow restore on a
costumer, and did a test on my server, and on both the time was so big,
this leads me to rule out hardware, but perhaps the filesystem on both
machines are the same, unfortunatelly I did not have remote access to
that costumer server, and did not visited them since, so I could not
tell anything about the costumer filesystem.

Something is very diferent on restoring blobs than simple types, I know
it's comparing apple to orange, but 2 databases with the same size has
considerably diferent times for back-up/restore if it's made of simple
datatypes or with blob content. I know it's not a fair comparison, but
anyway, I think it's not completely invalid.

I am very busy this days, but I will perform more tests on distinct
hardware to see some numbers about it.

Thanks for your message.

see you !