| Subject | Re: [IBO] Too many savepoints ... |
|---|---|
| Author | Helen Borrie |
| Post date | 2006-08-03T00:02:57Z |
At 02:54 AM 3/08/2006, you wrote:
find what is making it happen. The clues are 'Too many savepoints'
and the CPU running at 100%.
You said that your inserts "work". Do you verify that by querying
from an external tool? I smell a long-uncommitted transaction here,
where the undo-log for the bulk insert reaches a point where it has
consumed all the available RAM (both physical and extended). If you
are using Superserver and have multiple connections, we're not
talking about unlimited RAM here - it will max out at 2 Gb total RAM
regardless.
Consider the possibility that your bulk insert is causing some kind
of infinite loop. Don't forget to examine what any Before Insert
triggers on that table are doing.
connections eventually, after it has established that the connection
has disappeared and the TCP/IP timeout (usually 2 hours) has elapsed.
check" indicates a set of internal conditions that the server doesn't
know how to handle because the cause is beyond its control. Hence,
it can't deliver an exception code that IBO can respond to, so it's
beyond IBO's capability to be an ambulance at the bottom of the cliff.
-- Instead of pseudocode, show the actual SQL and the actual client-side code.
--You mentioned "Internet connection" - are you trying to run a
two-tier application across the Internet?
-- If you are passing blobs, show that as well.
-- Also provide details of the server version and model (SS/Classic)
you are using, and of the client library that the application is using.
-- Provide the transaction settings, including whether Autocommit is active.
Helen
> >It will be the cause of the error but you need to do the forensics to
> > >then FB hanged with 100% CPU performance.
> > >After shutting down the service, the logfile telled:
> > >"internal gds software consistency check
> > > (Too many savepoints (287))"
> > >
> > >The records where inserted correctly.
> > >What can be the reason for that error?
> >
> > Low memory.
>
>I'll pay attention to, but I think that can't be the reason.
>(1 GB Memory, MS-SQL-Server (not much to do), FB and 4 running
>applications - I will check for memory-leaks)
>
>Is there something other that can cause the error?
find what is making it happen. The clues are 'Too many savepoints'
and the CPU running at 100%.
You said that your inserts "work". Do you verify that by querying
from an external tool? I smell a long-uncommitted transaction here,
where the undo-log for the bulk insert reaches a point where it has
consumed all the available RAM (both physical and extended). If you
are using Superserver and have multiple connections, we're not
talking about unlimited RAM here - it will max out at 2 Gb total RAM
regardless.
Consider the possibility that your bulk insert is causing some kind
of infinite loop. Don't forget to examine what any Before Insert
triggers on that table are doing.
>Maybe uncommitted transactions when the remote-client lostThe Fb server will clean up the uncommitted work from dead
>connection to FB via the internet?
connections eventually, after it has established that the connection
has disappeared and the TCP/IP timeout (usually 2 hours) has elapsed.
>Or something else ...Not enough forensic info to make guesses. The "gds inconsistency
check" indicates a set of internal conditions that the server doesn't
know how to handle because the cause is beyond its control. Hence,
it can't deliver an exception code that IBO can respond to, so it's
beyond IBO's capability to be an ambulance at the bottom of the cliff.
-- Instead of pseudocode, show the actual SQL and the actual client-side code.
--You mentioned "Internet connection" - are you trying to run a
two-tier application across the Internet?
-- If you are passing blobs, show that as well.
-- Also provide details of the server version and model (SS/Classic)
you are using, and of the client library that the application is using.
-- Provide the transaction settings, including whether Autocommit is active.
Helen