|Subject||RE: [firebird-support] FB freeze|
> Your suggestion to change to Classic engine is one thing I really consider.Funny, we only run Classic and have been for 15+ years.
> 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.
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 IOALTER DATABASE is just a trigger to invoke nbackup.
> also the server computers seem to handle the traffic of nbackupThe 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.
> 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.
> I might not be clear about the "freezing" behavior. The FB service seem to beThis is a common symptom of SuperServer with heavy activity taking place.
> 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.
> > > The database sizes are around 10 - 30 GB and are fully backuped andWe 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.
> > > 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.