used up all locks

RH AS 3 Linux IDS 10.00.UC4 Had a user doing free-form SQL do a "delete from tbl_name" on a table with 2M+ rows (and a PK). Without using a TX (and locking the table), this dynamically allocated locks until it could no longer add them; expected behavior. The delete statement died (or maybe user cancelled it?). After, kept getting alarms from the db engine of "no more locks". I checked "onstat -k" and it showed - at most - all user sessions using about 1000 locks. The alarms kept coming until I killed off that user session. Is this a "feature" that the db engine keeps thinking all (2M?) locks are still in use until the offending user session is killed off? Any better behavior in Cheetah? Bob Roussey Unix / Informix Administration Spirit Airlines Robert.Roussey@SpiritAir.com

It became an issue because other user sessions were in the ALARM messages stating "no more locks" despite "onstat -k" not showing all locks were in use. Bob Roussey Unix / Informix Administration Spirit Airlines Robert.Roussey@SpiritAir.com -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Robert Roussey(IT) Sent: Tuesday, August 07, 2007 6:57 PM To: ids@iiug.org Subject: used up all locks [9721] RH AS 3 Linux IDS 10.00.UC4 Had a user doing free-form SQL do a "delete from tbl_name" on a table with 2M+ rows (and a PK). Without using a TX (and locking the table), this dynamically allocated locks until it could no longer add them; expected behavior. The delete statement died (or maybe user cancelled it?). After, kept getting alarms from the db engine of "no more locks". I checked "onstat -k" and it showed - at most - all user sessions using about 1000 locks. The alarms kept coming until I killed off that user session. Is this a "feature" that the db engine keeps thinking all (2M?) locks are still in use until the offending user session is killed off? Any better behavior in Cheetah? Bob Roussey Unix / Informix Administration Spirit Airlines Robert.Roussey@SpiritAir.com ************************************************************************ ******* Forum Note: Use "Reply" to post a response in the discussion forum.

Hi, there is a know bug with onstat -k not showing all locks after a lock table overflow and dynamic lock allocation. Maybe that's your problem: http://www-1.ibm.com/support/docview.wss?uid=swg21215191 Regards, Andreas Kutsche > ------------------------------------------- SPAR Österreichische Warenhandels-AG Hauptzentrale A - 5015 Salzburg, Europastrasse 3 FN 34170 a Tel: +43 662 4470 24223 Mobile: +43 664 6259575 E-Mail: Andreas.KUTSCHE@spar.at Internet: http://www.spar.at Wichtiger Hinweis: Der Inhalt dieser E-Mail kann vertrauliche und rechtlich geschützte Informationen, insbesondere Betriebs- oder Geschäftsgeheimnisse, enthalten, zu deren Geheimhaltung der Empfänger verpflichtet ist. Die Informationen in dieser E-Mail sind ausschließlich für den Adressaten bestimmt. Sollten Sie die E-Mail irrtümlich erhalten haben so ersuchen wir Sie, die Nachricht von Ihrem System zu löschen und sich mit uns in Verbindung zu setzen. Über das Internet versandte E-Mails können leicht manipuliert oder unter fremdem Namen erstellt werden. Daher schließen wir die rechtliche Verbindlichkeit der in dieser Nachricht enthaltenen Informationen aus. Der Inhalt der E-Mail ist nur rechtsverbindlich, wenn er von uns schriftlich bestätigt und gezeichnet wird. Sollte trotz der von uns verwendeten Virus-Schutzprogramme durch die Zusendung von E-Mails ein Virus in Ihre Systeme gelangen, haften wir nicht für evtl. hieraus entstehende Schäden. Wir danken für Ihr Verständnis. Important notice: The contents of this e-mail may contain confidential and legally protected information that is in particular related to operational and trade secrets, which the recipient is obliged to treat as confidential. The information in this e-mail is made available exclusively for use by the addressee. In the event that the e-mail may have been sent to you in error, we would ask you to kindly delete this communication from your system and to contact us. E-mails sent via the Internet can be easily manipulated or sent out under someone else's name. We therefore do not accept legal liability for the information contained in this communication. The contents of the e-mail are only legally binding if they have been confirmed and signed by us in writing. If, in spite of our using Antivirus protection software, a virus may have penetrated your system through the sending of this e-mail, we do not accept liability for any damage that may possibly arise as a result of this. We trust that you appreciate our position. ------------------------------------------- -----Ursprüngliche Nachricht----- > Von: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org]Im Auftrag von > Robert Roussey(IT) > Gesendet: Mittwoch, 08. August 2007 01:22 > An: ids@iiug.org > Betreff: RE: used up all locks [9722] > > > It became an issue because other user sessions were in the ALARM > messages stating "no more locks" despite "onstat -k" not showing all > locks were in use. > > Bob Roussey > Unix / Informix Administration > Spirit Airlines > Robert.Roussey@SpiritAir.com > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of > Robert Roussey(IT) > Sent: Tuesday, August 07, 2007 6:57 PM > To: ids@iiug.org > Subject: used up all locks [9721] > > RH AS 3 Linux > IDS 10.00.UC4 > > Had a user doing free-form SQL do a "delete from tbl_name" on a table > with 2M+ rows (and a PK). Without using a TX (and locking the table), > this dynamically allocated locks until it could no longer add them; > expected behavior. The delete statement died (or maybe user cancelled > it?). After, kept getting alarms from the db engine of "no > more locks". > I checked "onstat -k" and it showed - at most - all user > sessions using > about 1000 locks. The alarms kept coming until I killed off that user > session. > > Is this a "feature" that the db engine keeps thinking all (2M?) locks > are still in use until the offending user session is killed off? Any > better behavior in Cheetah? > > Bob Roussey > Unix / Informix Administration > Spirit Airlines > Robert.Roussey@SpiritAir.com > > ************************************************************** > ********** > ******* > Forum Note: Use "Reply" to post a response in the discussion forum. > > > ************************************************************** > ***************** > Forum Note: Use "Reply" to post a response in the discussion forum. > >

No, but it queues one message for each time any user tries to acquire any lock until the table is free. Alarm messages are processed one at a time. Since each message requires a process fork/exec so the messages queue up much faster than the queue is drained. Look at my alarm handler eventalarm.c in utils3_ak, it ignores multiple similar messages send within a configurable time period (IB I defaulted it to 5 mins) by writing a stamp file and reading it back when processing messages like Logical Log Full and Lock Table Overflow that come in huge batches so that it only forwards one message every N minutes and doesn't fill my email box. Art S. Kagel ----- Original Message ----- From: Robert Roussey <ids@iiug.org> At: 8/07 18:57:18 RH AS 3 Linux IDS 10.00.UC4 Had a user doing free-form SQL do a "delete from tbl_name" on a table with 2M+ rows (and a PK). Without using a TX (and locking the table), this dynamically allocated locks until it could no longer add them; expected behavior. The delete statement died (or maybe user cancelled it?). After, kept getting alarms from the db engine of "no more locks". I checked "onstat -k" and it showed - at most - all user sessions using about 1000 locks. The alarms kept coming until I killed off that user session. Is this a "feature" that the db engine keeps thinking all (2M?) locks are still in use until the offending user session is killed off? Any better behavior in Cheetah? Bob Roussey Unix / Informix Administration Spirit Airlines Robert.Roussey@SpiritAir.com ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.