Join The Works program to have access to the most current content, and to be able to ask questions and get answers from Revelation staff and the Revelation community

At 20 MAR 2024 11:15:22AM Nick Stevenson wrote:

On one of our newly migrated systems we are starting to get errors returned by an RLIST Select - "262 20" which I am assuming is a timeout on a lock. Not sure why, the indexes are all flushed prior to the Select. The Database Environment Settings has the Update Before Query ticked.

It is hitting only one of the indexed tables at the moment - this particular table has a few btrees on data items that are nearly all identical, so likely to be badly balanced. Around 800,000 rows in the table.

Never happened in OI9.4.4 and is occurring only in one of the (very similar) systems.

The indexes have all been rebuilt since the migration from OI9.4.4. LHVerify reports all OK.

Any suggestions?


At 20 MAR 2024 11:48AM bob carten wrote:

If you EXEC LIST_USER_LOCKS can you see which rows are locked in the ! file ?


At 20 MAR 2024 11:52AM Nick Stevenson wrote:

Currently:

STATUS*ROOT

STATUS being a column name.


At 20 MAR 2024 12:12PM bob carten wrote:

That row should not stay locked if nothing else is locked.

It's possible that something failed an left it locked.

You can release that, see if it works afterward, or if the problem recurs.


At 20 MAR 2024 12:20PM Nick Stevenson wrote:

I can replicate the lock by running an RLIST on the file, including a select on the data column STATUS.

That STATUS*ROOT record stays permanently locked until I log out of the system and then log back in again.

View this thread on the Works forum...

  • third_party_content/community/commentary/forums_works/3f3f803a883cd641aed6a503de65ec4e.txt
  • Last modified: 2025/05/29 20:25
  • by 127.0.0.1