--- In firebird-support@yahoogroups.com, "Ali Benzes" <ali@...> wrote:

>
> Hi martin,
>
>
> On my company;
> Sometimes there are bugs, for example our problem;
> One hard query working and all server using this query because this hard
> query working with %100 cpu rate all on cores.

With Classic server, each connection may only use one core at a time.
If all cores are pegged, you must have different queries (or the same
query from different connections).

> For Each user application on server running with

fbinetserver.exe*32 my

> company have 20 users + web clients

fb_inet_server.exe*32 means you are running Classic server on a 64bit
variety of Windows running in WOW64 mode.

> If I kill any working %100 cpu fbinetserver.exe*32 my database need to
> repair.

What do you mean by 'repair'? It shouldn't damage the database (but it
will leave a mess so don't do it if you don't have to).

> If I don't make repair its working very very slowly.

I think I might need to explain what you are doing by terminating that
process. Each process represents a connection to the database. If that
process is consuming 100% of the CPU core it runs on for a long time,
then it is obviously making a lot of changes. If you terminate the
process, then you are abandoning the connection and hence implicitly
rolling back the active transaction.

But now you have a problem. The most recent version all those changed
records now needs to be undone because that transaction is rolled
back. The next transaction to encounter this 'mess' takes on this
task, which is why it works slowly.

Given the amount of garbage in the database it is probably quickest to
perform a backup restore cycle. Make sure everyone is disconnected,
then make a backup using gbak with the -g flag to skip garbage
collection. (Rename the original database and keep it safe in case you
need to go back). Restore the backup file which will leave you with a
clean database.

Avoid killing the database process if you don't want this situation.

Adam