>
> > One thing is not clear to me however. ALTER DATABASE shouldn't be IO
> > intensive,
>
> ALTER DATABASE is just a trigger to invoke nbackup.
>
>

What I meant is that ALTER DATABASE is only creates the delta file and not
starting to backup database pages.

> > also the server computers seem to handle the traffic of nbackup
> > really well. We have monitored the resources at the moment when the FB
> > service stopped responding, but no memory, Disk/Network IO or CPU
> > overload happened.
>
> The Firebird page cache and OS caches can mask the IO intensity of the
> actual operation. Since nbackup is IO constrained, CPU load would be
> nominal.
>
>
> > I might not be clear about the "freezing" behavior. The FB service seem
> to be
> > running but no response at all, the existing connections are not served
> and
> > no new connections could be made until killing the process and
> restarting the
> > FB service. This kind of behavior is not expected at all, the process
> should get
> > into some usable state after the bottleneck is eliminated.
>
> This is a common symptom of SuperServer with heavy activity taking place.
>
> We surely experience heavy load sometimes that cause slowdowns, but no

lockup or "freeze" occured in ten years of our clients' several hundred
database until we started using nbackup.


Thanks again for the answer.

Regards

Zsolt


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