Don't laugh, but I am still using IngresII 2.5 on Reliant UNIX.

Every 6 months or so our weekly iidbdb online "ckpdb" batch job hangs,
locking the entire installation. Last time the final part of the log
file was "CPP: Preparing stall of database, active xact cnt: 2".

Suspecting that we had active sessions (at 6 am when the checkpoint
job runs!) I added a "-timeout" flag to the "ckpdb" command and a "-v"
flag to get details of the sessions.

So far, so logical. We've had no recurrences of the problem yet and
no instances of "xact cnt" > 0 during iidbdb checkpoints. However I
have noticed that values of "xact cnt" greater than zero don't seem to
cause problems during online checkpoints of other databases in the
same installation.

Is the "ckpdb iidbdb" process uniquely vulnerable to active sessions,
or is the cause of our problems more likely to be something else?

Thanks.

L Jackson.

The master database (iidbdb) is accessed whenever a session starts,
but those sessions should not be persistent. Sometimes an
installation will use a process (program, script, or even window kept
in the background) that will connect to a database and wait for a
shutdown event. This keeps the database in the logging system and
minimizes overhead a little.

You could use ipm / iimonitor to look for persistent sessions, and
could also try "sql -l iidbdb" to get an exclusive lock on the
database (although you definitely don't want to hold that lock long or
nobody else will be able to connect).

Aside from that I can't think of any reason why the database would be
busy. HTH.

Chip

On May 1, 2008, at 5:40 AM, spammeiloveit@googlemail.com wrote:

> Don't laugh, but I am still using IngresII 2.5 on Reliant UNIX.
>
> Every 6 months or so our weekly iidbdb online "ckpdb" batch job hangs,
> locking the entire installation. Last time the final part of the log
> file was "CPP: Preparing stall of database, active xact cnt: 2".
> ...
>
> Is the "ckpdb iidbdb" process uniquely vulnerable to active sessions,
> or is the cause of our problems more likely to be something else?

The queue tables used by the Remote Command Server used to be in iidbdb.
They got moved to imadb, and I thought that was in 2.5; but it could
be that I am wrong. Or it could be that if the upgrade didn't do
just the right thing, they'd stay in iidbdb. Is this an upgrade
installation from an older version?

Other than rmcmd queue tables, I can't think of anything that would
normally hold iidbdb open for any length of time, unless some
hideously misguided (and privileged) application put something
nonstandard in there.

Karl