Batch update - Cannot read system catalog (systabl

IDS 10 AIX 5 We have a Java application, that updates batches of records in the database. Normally we do not have any problems, but we are now sitting with a back log of records, and are processing high amounts of records. And we are getting the following error: [2011-06-20 15:48:03,318]ERROR887327[main] - com.eppixcomm.eppix.rica.blo.RicaBLO.updateRicaPersonVerification(RicaBLO.java:5 49) - Could not clean record into RicaPersonVerification table: A database error has occurred: SQL Error: Reason: Cannot read system catalog (systables)., SQL State: IX000, Vendor Code: -211, DML Name: RicaPersonVerification, SQL Statement: UPDATE RICA_PERSON_VERIFICATION SET RPV_TRICKLE_DESC = ? WHERE RPV_SERIAL = ?, Argument(s): None SERIAL NO: 3611439 FOR ACCOUNT: A3319957 MSISDN: 832981712 I did a couple of checks. I can do an info on the table the update is being done on. I can also lock the table in exclusive mode from dbaccess. I look at systables, and the lock level for this table is set to (R)ow. Any tips / suggestions ? Dirk ________________________________ NOTE: This e-mail message is subject to the MTN Group disclaimer see http://www.mtn.co.za/SUPPORT/LEGAL/Pages/EmailDisclaimer.aspx

Dirk, Getting the ISAM error would help. I would expect that this error has something to do with locking. The fact that the error message states that the table that was unable to be read is systables lead me to wonder what in the code ( or other code running on your system at the same time ) might have placed a lock on a row in systables and not released. Does this application , or other applications that run against this DB run in Repeatable Read isolation level? Is this a "Mode Ansi" DB? Are there table modifications ( alters to change structure of the table ) embedded in the application ? Does the application do embedded "update statistics" which would occur inside of a transaction? I would be working on the theory that the application is not completing a transaction in a timely fashion, and may not be waiting on locks. Table alters, updates statistics ( in some level ), and automatic re-compilation of stored procedure, as well as other items I may have not mentioned, can change system catalogs, if these happen inside a transaction that the application leaves open, may cause the -211 errors ( ISAM errors would be -154 or -107 depending on if you have lock mode set to wait or not. ) I would look into these items that may change values in systables first, and attempt to find what session might have a lock that is holding a systables row locked while other session would be needing it. Generally a -211 error is not an error that indicates something is wrong inside the database, Good luck finding the cause of the -211. George. From: "Dirk Cornel...." <moolma_dc@mtn.co.za> To: ids@iiug.org Date: 06/20/2011 08:58 AM Subject: Batch update - Cannot read system catalog (sys.... [24083] Sent by: ids-bounces@iiug.org IDS 10 AIX 5 We have a Java application, that updates batches of records in the database. Normally we do not have any problems, but we are now sitting with a back log of records, and are processing high amounts of records. And we are getting the following error: [2011-06-20 15:48:03,318]ERROR887327[main] - com.eppixcomm.eppix.rica.blo.RicaBLO.updateRicaPersonVerification (RicaBLO.java:549) - Could not clean record into RicaPersonVerification table: A database error has occurred: SQL Error: Reason: Cannot read system catalog (systables)., SQL State: IX000, Vendor Code: -211, DML Name: RicaPersonVerification, SQL Statement: UPDATE RICA_PERSON_VERIFICATION SET RPV_TRICKLE_DESC = ? WHERE RPV_SERIAL = ?, Argument(s): None SERIAL NO: 3611439 FOR ACCOUNT: A3319957 MSISDN: 832981712 I did a couple of checks. I can do an info on the table the update is being done on. I can also lock the table in exclusive mode from dbaccess. I look at systables, and the lock level for this table is set to (R)ow. Any tips / suggestions ? Dirk ________________________________ NOTE: This e-mail message is subject to the MTN Group disclaimer see http://www.mtn.co.za/SUPPORT/LEGAL/Pages/EmailDisclaimer.aspx ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

Great, thank you for the help. :-) Dirk > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of > George_Palmer@aotx.uscourts.gov > Sent: Monday, 20 June 2011 10:04 PM > To: ids@iiug.org > Subject: Re: Batch update - Cannot read system catalog .... [24098] > > Dirk, > > Getting the ISAM error would help. > I would expect that this error has something to do with locking. The > fact > that the error message states that the table that was unable to be read > is > systables lead me to wonder what in the code ( or other code running on > your system at the same time ) might have placed a lock on a row in > systables and not released. > > Does this application , or other applications that run against this DB > run > in Repeatable Read isolation level? Is this a "Mode Ansi" DB? > Are there table modifications ( alters to change structure of the table > ) > embedded in the application ? > Does the application do embedded "update statistics" which would occur > inside of a transaction? > > I would be working on the theory that the application is not completing > a > transaction in a timely fashion, and may not be waiting on locks. > > Table alters, updates statistics ( in some level ), and automatic > re-compilation of stored procedure, as well as other items I may have > not > mentioned, can change system catalogs, if these happen inside a > transaction > that the application leaves open, may cause the -211 errors ( ISAM > errors > would be -154 or -107 depending on if you have lock mode set to wait or > not. ) > > I would look into these items that may change values in systables > first, > and attempt to find what session might have a lock that is holding a > systables row locked while other session would be needing it. Generally > a > -211 error is not an error that indicates something is wrong inside the > database, > > Good luck finding the cause of the -211. > > George. > > From: "Dirk Cornel...." <moolma_dc@mtn.co.za> > To: ids@iiug.org > Date: 06/20/2011 08:58 AM > Subject: Batch update - Cannot read system catalog (sys.... [24083] > Sent by: ids-bounces@iiug.org > > IDS 10 > AIX 5 > > We have a Java application, that updates batches of records in the > database. > Normally we do not have any problems, but we are now sitting with a > back > log > of records, and are processing high amounts of records. And we are > getting > the > following error: > > [2011-06-20 15:48:03,318]ERROR887327[main] - > com.eppixcomm.eppix.rica.blo.RicaBLO.updateRicaPersonVerification > (RicaBLO.java:549) > - Could not clean record into RicaPersonVerification table: > > A database error has occurred: SQL Error: Reason: Cannot read system > catalog > (systables)., SQL State: IX000, > > Vendor Code: -211, DML Name: RicaPersonVerification, SQL Statement: > UPDATE > RICA_PERSON_VERIFICATION SET RPV_TRICKLE_DESC = ? > WHERE RPV_SERIAL = ?, Argument(s): None > SERIAL NO: 3611439 > FOR ACCOUNT: A3319957 > MSISDN: 832981712 > > I did a couple of checks. I can do an info on the table the update is > being > > done on. I can also lock the table in exclusive mode from dbaccess. > I look at systables, and the lock level for this table is set to (R)ow. > > Any tips / suggestions ? > > Dirk > > ________________________________ > NOTE: This e-mail message is subject to the MTN Group disclaimer see > http://www.mtn.co.za/SUPPORT/LEGAL/Pages/EmailDisclaimer.aspx > > > *********************************************************************** > ******** > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > *********************************************************************** > ******** > Forum Note: Use "Reply" to post a response in the discussion forum. NOTE: This e-mail message is subject to the MTN Group disclaimer see http://www.mtn.co.za/SUPPORT/LEGAL/Pages/EmailDisclaimer.aspx