Subject RE: [firebird-support] FB freeze
Author Leyne, Sean
> Your suggestion to change to Classic engine is one thing I really consider.
> It needs to be planned carefully in our case because the system is operated
> without real competent supervision and our operating mechanisms - that
> were serving us well in the past 10 years, starting from IB 6.0 - relying on
> some specialties of the SS architecture, like stopping the FB service.

Funny, we only run Classic and have been for 15+ years.

Stop Firebird requires that you create a simple batch file which executes the following command:
taskkill /F /IM fb_inet_server.exe

> One thing is not clear to me however. ALTER DATABASE shouldn't be IO
> intensive,

ALTER DATABASE is just a trigger to invoke nbackup.

> 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.

> > > The database sizes are around 10 - 30 GB and are fully backuped and
> > > restored at every weekend.
> >
> > Why are you performing regular backup/restore?
> >
> As I mentioned these systems operated without much supervision and
> monitoring and a lot of different problem can be solved (although they may
> happen infrequently or even never) by issuing a full backup/restore. It may
> sound a bit tough but it saves us s lot of headache.

We have over 100 databases installed worldwide (ranging from 10GB to 150GB) and we only perform backup/restores every 6-9 months, and have never had a problem.