Applying Log Causes Assertion 100904 - User 'another user' has row locked

[justin_willey]

v 10.0.1.4116

When applying a log file to a standby database we get an assertion 100904 with the message: User 'another user' has the row in 'WPKView' locked

Clearly there is no other user as we only have the server up for applying the log - but what could be causing this? We have re-tried recopying the original database and reapplying the logs but have the same problem.

This is a process that has been running for several years without previous issues and nothing particular has changed and has been very reliable. Each week a full db copy is taken and moved to the standby server, then during the course of the week log backups are applied. At the same time a live backup is running, so that we could quickly bring the standby server right up-to-date in the event of a failure of the main server.

We now can't get past the log causing the problem - leaving us exposed. Does the problem also imply some sort of potential corruption of the main database?

I can see reports of this error in previous versions but no explanation of what causes it. Any suggestions appreciated.

---

From the console:

I. 07/24 08:23:52. Finished checkpoint of "pears" (pears.db) at Tue Jul 24 2012 08:23
E. 07/24 08:23:52. *** ERROR *** Assertion failed: 100904 (10.0.1.4116)
E. 07/24 08:23:52. Failed to redo a database operation (id=4, page_no=0xd00008a0, offset=0xa4e) - Error: User 'another user' has the row in 'WPKView' locked
I. 07/24 08:23:52. *** ERROR *** Assertion failed: 100904 (10.0.1.4116)
I. 07/24 08:23:52. Failed to redo a database operation (id=4, page_no=0xd00008a0, offset=0xa4e) - Error: User 'another user' has the row in 'WPKView' locked
I. 07/24 08:23:52. 
I. 07/24 08:28:52. Database server will shut down after startup completes

[Breck_Carter]

This may be related to User 'another user' has the row in 'mytable' locked which refers to a fix that your build may or may not contain... and it refers to a situation (idle time) completely unlike yours.

FWIW 10.0.1.4310 is the most recent (and final?) EBF for 10.0.1 on Windows. The read me contains this one mention of your symptom...

    ================(Build #3535  - Engineering Case #476067)================

The CREATE INDEX statement was not respecting the setting of the Blocking 
    option, and would always have failed if another transaction had the table 
    locked (for shared or exclusive access). As of version 10.0, this is more 
    likely to be an issue as the cleaner locks tables temporarily as it does 
    its work. In particular, a reload could have failed with errors of the form 
    "User 'another user' has the table ... locked". This has now been 
    fixed.

Plunging onwards...

Please show us the following two command lines: the dbsrv10 command line that was in effect when the log files were originally created, and the dbsrv10 command line that was used to apply the logs via the -a, -ad or -ar options.

If the two command lines are significantly different (e.g., dbeng10 -a was used instead of dbsrv10), the roll forward process may not have the same resources available to apply the logs that the engine had when the transactions in the logs were originally processed; e.g., not enough threads, RAM, whatever. The roll forward process is pretty much a replay of what went on before, minus the wetware 🙂

[justin_willey]

Thanks Breck - there are two things there I can follow up on. First the live server is on build 4310 so we'll apply the same ebf to the standby, second although both command lines are using dbsrv there are significant differences in RAM etc so we can try altering that.

[Breck_Carter]

...don't forget to wave a dead chicken over the keyboard, might not help but never hurts 🙂

[justin_willey]

Unfortunately neither updating the version of the software on the standby machine or getting the memory & thread options in-line helps. It leaves us copying the later backup down and hoping it doesn't happen again- but at 150G zipped its going to take a while 😞

[Breck_Carter]

"Call tech support" is the next step... usually... but if it's a bug in V10 it ain't gonna get fixed... 11.0.1 is highly recommended, and you don't need to unload/reload the database.

[Former Member]

Justin, please contact technical support. I have an idea what is going on, and I think we should be able to come up with a workaround for you.

[justin_willey]

Thanks Glenn - I'll do that

[justin_willey]

It's opened as case #11747103 - thanks