Failed Assertion

  • hi,

    here's the situation:

    we are running a Microsoft Business Solutions - Navision database on win2003 clustered, SQL Server2000 SP3

    Last sunday I was optimizing some tables (a function in Navision, it basicly deletes "empty" records and rebuilds indexes.) I had the db in bulklogged mode. When I thought it took too long I killed the client. Usually this triggers a rollback and every thing is back to normal. Not this time. The rollback failed and I ended up with a suspect database. Instead off fiddling around with it trying to get it going again I opted for the easy solution (due to nice weather) and restored the backup. Now I have some time to reflect and I wonder if any of you gurus have a clue what happened.

    It looks very similar to the bug reported in article Q319851

    http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q319851

    and READ UNCOMMITTED is used extensively in Navision so that makes sense.

    But this bug is said to be fixed in SP3.

    Any thoughts are appreciated.

    /JW

    This is the part of the errorlog I think is of interest:

    2005-07-10 16:24:25.47 spid17Database 'MBSPROD' (database ID 8) could not recover. Contact Technical Support

    2005-07-10 16:24:25.47 spid17Error: 3414, Severity: 21, State: 1

    2005-07-10 16:24:23.25 spid17An error occurred while processing the log for database 'MBSPROD'..

    2005-07-10 16:24:23.25 spid17Error: 9004, Severity: 23, State: 7

    2005-07-10 16:23:18.00 spid17Error while undoing logged operation in database 'MBSPROD'. Error at log record

    2005-07-10 16:23:18.00 spid17Error: 3314, Severity: 21, State: 3

    2005-07-10 16:23:18.00 spid17Error: 3624, Severity: 20, State: 1.

    2005-07-10 16:23:18.00 spid17Location: logrec.cpp:499...

    2005-07-10 16:23:18.00 spid17SQL Server Assertion: File: , line = 499 ...

    2005-07-10 16:23:17.98 spid17Stack Signature for the dump is 0x41A19CCE

    2005-07-10 16:23:17.25 spid17Using 'dbghelp.dll' version '4.0.5'...

    2005-07-10 16:23:17.22 spid17Recovery of database 'MBSPROD' (8) is 1% complete (approximately 9127 more seco

    2005-07-10 16:23:17.03 spid1717 transactions rolled forward in database 'MBSPROD' (8).

    2005-07-10 16:23:17.03 spid17Recovery of database 'MBSPROD' (8) is 1% complete (approximately 9127 more seco

    2005-07-10 16:22:47.54 spid17Recovery of database 'MBSPROD' (8) is 1% complete (approximately 9130 more seco

    2005-07-10 16:22:27.54 spid17Recovery of database 'MBSPROD' (8) is 1% complete (approximately 9140 more seco

    2005-07-10 16:22:15.22 spid17Recovery of database 'MBSPROD' (8) is 0% complete (approximately 9151 more seco

    2005-07-10 16:21:55.22 spid17Recovery of database 'MBSPROD' (8) is 0% complete (approximately 9171 more seco

    2005-07-10 16:21:35.22 spid17Recovery of database 'MBSPROD' (8) is 0% complete (approximately 9194 more seco

    2005-07-10 16:21:15.22 spid17Recovery of database 'MBSPROD' (8) is 0% complete (approximately 9215 more seco

    2005-07-10 16:20:55.20 spid17Recovery of database 'MBSPROD' (8) is 0% complete (approximately 10536 more sec

    2005-07-10 16:20:55.19 spid17Analysis of database 'MBSPROD' (8) is 100% complete (approximately 0 more secon

    2005-07-10 16:20:52.89 spid17Analysis of database 'MBSPROD' (8) is 56% complete (approximately 4 more second

    2005-07-10 16:20:47.78 spid17Analysis of database 'MBSPROD' (8) is 4% complete (approximately 9 more seconds

    2005-07-10 16:20:47.17 spid17Starting up database 'MBSPROD'.

    2005-07-10 15:41:48.39 spid62Error while undoing logged operation in database 'MBSPROD'. Error at log record

    2005-07-10 15:41:48.39 spid62Error: 3314, Severity: 21, State: 5

    2005-07-10 15:41:48.37 spid62An error occurred while processing the log for database 'MBSPROD'..

    2005-07-10 15:41:48.37 spid62Error: 9004, Severity: 23, State: 7

    2005-07-10 15:41:48.37 spid62SQL Server Assertion: File: , line=3282 ...

    2005-07-10 15:41:48.36 spid62Stack Signature for the dump is 0x039F40FE

    2005-07-10 15:41:47.25 spid62Using 'dbghelp.dll' version '4.0.5'...

    2005-07-10 15:41:47.23 spid62SQL Server Assertion: File: , line=3063 ...

    2005-07-10 15:41:47.22 spid62Stack Signature for the dump is 0xAE8146A3

    2005-07-10 15:41:46.11 spid62Using 'dbghelp.dll' version '4.0.5'...

    2005-07-10 15:40:41.86 spid62Error while undoing logged operation in database 'MBSPROD'. Error at log record

    2005-07-10 15:40:41.86 spid62Error: 3314, Severity: 21, State: 4

    2005-07-10 15:40:41.86 spid62Error: 9001, Severity: 21, State: 1

    2005-07-10 15:40:41.86 spid62The log for database 'MBSPROD' is not available..

    2005-07-10 15:40:41.84 spid62An error occurred while processing the log for database 'MBSPROD'..

    2005-07-10 15:40:41.84 spid62Error: 9004, Severity: 23, State: 7

    2005-07-10 15:40:41.83 spid62SQL Server Assertion: File: , line=3282 ...

    2005-07-10 15:40:41.83 spid62Stack Signature for the dump is 0xB6446434

    2005-07-10 15:40:40.69 spid62SQL Server Assertion: File: , line=3063 ...

    2005-07-10 15:40:40.69 spid62Using 'dbghelp.dll' version '4.0.5'...

    2005-07-10 15:40:40.65 spid62Stack Signature for the dump is 0xEC78688F

    2005-07-10 15:40:39.54 spid62Using 'dbghelp.dll' version '4.0.5'...

    2005-07-10 15:39:34.78 spid62Error: 3624, Severity: 20, State: 1.

    2005-07-10 15:39:34.76 spid62SQL Server Assertion: File: , line = 499 ...

    2005-07-10 15:39:34.76 spid62Stack Signature for the dump is 0x62A62094

    2005-07-10 15:39:32.11 spid62Using 'dbghelp.dll' version '4.0.5'...

    2005-07-10 15:22:12.89 spid61Process ID 60 killed by hostname IISNL081-NT8014, host process ID 14412.

    2005-07-10 15:19:11.17 spid61DBCC TRACEON 3604, server process ID (SPID) 61.

  • Hello JW,

    You say " I was optimizing some tables (a function in Navision..)..Usually this triggers a rollback "

    We don't know how this function is coded by Microsoft programmers. Some transactions may have been commited by the function before you decided to stop the client. Maybe the database or log files were left in some inconsistent state. It is a good practice to backup database before doing anything major in the database and it appears that it was exactly what you did, good for you!

    It would help if you describe your actions between "killed the client" and "ended up with suspect database"

    Yelena

     

    Regards,Yelena Varsha

Viewing 2 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic. Login to reply