Hi Folks,

Each time I want to test VDBA Monitoring my favorite test is the following :
1/ isql demodb
create table jpz as select * from iitables;
commit;
update jpz set table_name = 'aaa';
2/ isql demodb (other session)
update jpz set table_owner = 'ttt';

Then the 2nd session is locked.

With VDBA Monitoring, if I can see that one session is locked, the "Blocking
Session(s)" branch is (almost) alway "< Data unavailable >", where (the old
good) ipm show me some locks.

Due to this consideration, I'm always shy to advice my customers to use this
tool in a real production context.

I'm don't think this "quiet simple" test is inappropriate.

Here again, where I'm wrong ?

Last test on (a previon 9.2.0 upgraded) II 9.2.0 (int.w32/143) ...

Thx
--
Jean-Pierre Zuate
La Fage Conseil
+33(0)6 11 40 11 09
jean-pierre.zuate (AT) lafageconseil (DOT) fr
http://lafageconseil.fr/

Jean-Pierre Zuate, La Fage Conseil wrote:

You aren't doing anything wrong. I just ran into the same issue with a
Patrol script that had been stable for years and quit working after the
system was upgraded from 9.1 to 9.2.

It turns out that some thoughtless person changed the values returned
in ima_locks.lock_state from WAITING and GRANTED to "WT" and "GR". :-(
GR indeed. More like Grrrr. Someone deserves a slap.

--
Roy

UK Ingres User Association Conference 2009 will be on Tuesday June 9,
2009
Go to http://www.iua.org.uk/join to get on the mailing list.