Re: [Info-ingres] Deciphering errors





I've always been able to pick out the locking session in IPM by tracking
down the transaction id - and , if necessary killing. Only takes a few
seconds
usually. And armed with the session/transaction ID - I can then get
iimonitor to do it for me.

That's my 2p

Andy


--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------





"Paul Andrews"
<ac297@xxxxxxxxxx
.com> To
Sent by: <info-ingres@xxxxxxxxxxxxxxx>
info-ingres-admin cc
@cariboulake.com
Subject
[Info-ingres] Deciphering errors
09/12/2006 05:35
AM


Please respond to
"Paul Andrews"
<ac297@xxxxxxxxxx
.com>






I just thought I'd make a general comment about all this stuff - ie how to
decipher errors in ingres to get at the information you need.

Some recent posts have highlighted (in my mind) just how lazy and
complacement we can get with software. I' ve used ingres since 1987 and you
get
used to what it does and what it gives you. As other posters have
demonstrated, all the information you need from ingres is there, it's just
a question
of knowing how to get to it.

Sometimes people say wouldn't it be nice if ingres support 'some SQL
feature' in ingres, yet for a DBA and live systems, even simple things such
as error messages really do affect us and the service we can give to the
end users.

I look at the ingres messages and I suspect that they come from the pen of
an evil programmer, who is saying what's going on, but not always in a way
that's relevant to an end-user or DBA. Ingres really hasn't changed much in
this respect at all from those days back in 1987.

I think that spending a bit of attention to the error message mechanisms
could work wonders.

If you get a deadlock, the system should tell us when, who and with what
and if need be add the really technical stuff to the end.
If a disconnect happens, it could suggest what the cause might be. "user
disconnected unexpectedly from the DBMS, this may either be to premature
termination of the ingres client/program or a networking problem or
misconfiguration (see ... )", or "User fred has encountered a deadlock
condition whilst running query "update sometable set x=y where y=10". A
table lock is held 'bill', who also holds the following locks..".

You get my drift.

Some of you will think my suggestion is a bit akin to a net nanny, but I
remember the hassle of trying to identify deadlocked sessions (probably the
#1 cause of hassle on one of the systems I've worked on and certainly very
time consuming against the clock), etc. Maybe such verbose messages could
just be an option so that 'experts' can continue to enjoy the status quo.

OK, ingres may not be alone in this respect, but that's not a reason for
not improving it. Surely we can do better in 2006?

2p over.

Paul



.

Relevant Pages