>
> one of our client have ~118gb database,
> and performance is much better than yours. Since that database have
> ~300 concurrent users, they paid attention to the storage, and bought
> new raid (md3220 from dell with 8 or 12 hard drives).
> Now they have
> sweep - from 5 to 40 minutes, depending on garbage amount
> restore - ~7 hours
> backup - ~2 hours
>

in fact on the server the backup is around 2 hours (restore 24hours but
this
because of index i m not surprise). but backup from different server
than the
FB server take twice more time :(

hard drive: 5 RAID 0 SAS 15k on DELL server

yes i take some risk but i have no other choice need speed !

> >> yes, up to 2-4 times faster. we made tests 3 years ago and found that.
> VCS> hmm i not understand why ?
>
> when gbak runs itself, it also makes backup by itself, telling
> server to read the data. So, here is "intercommunication" between
> 2 processes - gbak and server.
>

that explain why it's so slow on the remote computer :)

> VCS> everyday the difference between oldest transaction and next
> transaction
> VCS> grow by more than 20 000 :(
>
> Then you need to check transaction management in your applications.
> First task is to eliminate long running transactions whenever
> possible, or use read read committed transactions for reading
>

to select or update the data we do only like this :

procedure doSQL
begin
StartTransaction
Try
select or update data
committransaction
except
rollbacktransaction
end;
end;

for now the only explanation i see is that we do very lot of transaction
(average 225 / Secondes is it lot ?)
on the server and this why 20000 sean to be too little ... with around
19 millions transactions by days
i thing i must use much more than 20000 (1 million?)



[Non-text portions of this message have been removed]