There are a couple of extracts we run that if they terminate abnormally have the propensity to bring the whole database down. We get the following in the log: Does anyone have any ideas what this locked buffer might be? Progress 11.2.1
[2014/12/04@14:36:30.779+0000] P-12908 T-17196 I SRV 36: (2520) Stopped.
[2014/12/04@14:36:30.779+0000] P-22176 T-18640 I WDOG 167: (2523) User 212 died with 1 buffers locked.
Where 212 is pertinent to the user in question. I've compiled the offending code with listing and there are no transactions. It's just an extract after all.
There are a couple of extracts we run that if they terminate abnormally have the propensity to bring the whole database down. We get the following in the log:
Does anyone have any ideas what this locked buffer might be?
Fair enough - that makes sense. Thanks Tom. Any ideas (short of kicking the developer who wrote awful code) of things one can look at to try and reduce block locking by these extracts?
Good call on the -b thing. I will make sure that gets implemented tomorrow.
Connecting with -S definitely isn't an option as you surmise due to the data being read. I suspect that if the queries were given FIELDS lists then they would run much quicker on a client/server connection, but that's beyond the understanding of the coder - see below.
The clients are usually abnormally terminated because someone realises they have gone out of control (due to a code change that wasn't tested). They kill the process.
Unfortunately (for me), the extracts are written by someone who has no understanding of proper index selection and reducing reads. It happens to be our IT manager. He writes the extracts because nobody else has time. He writes them badly and then someone else has to fix them. Not at all fun.
> Does anyone have any ideas what this locked buffer might be?
If ai is enabled then you can find out what session did right before its death.
If the client process does have to be killed, disconnecting it from the database with promon or proshut will reduce the chance of bringing down the database.
Good call [mention:4b133177ec1e4b6f9a6a7832e6f29913:e9ed411860ed4f2ba0265705b8793d05].
[mention:ae2ea2f6412743fc8be36c522f414ef0:e9ed411860ed4f2ba0265705b8793d05], how would i go about seeing this?
> how would i go about seeing this?
1) In db log find ai file that was active at 14:36:30;
2) Scan the ai file (and a few of its predecessors);
3) Find the login name of user 212;
4) grep the scans by the user's name;
5) grep the scans by TRIDs found by the previous grep.
or you can use my grepAiScan.p instead of 'grep' command:
> If the client process does have to be killed
...then don't use 'kill -9' for self-service users. Use: kill -SIGUSR1; kill -SIGTERM etc
Maybe a weeks worth of training (for the IT Manager), can save you months worth of problems. :-)
lol [mention:ff09ecb5f26245d181a46a061b650f24:e9ed411860ed4f2ba0265705b8793d05] we've tried... :)
[mention:ae2ea2f6412743fc8be36c522f414ef0:e9ed411860ed4f2ba0265705b8793d05], thanks for that really useful post. Spasibo!