1

I need to move two databases, WES and WILL from a Win2012/SQL2012 instance to a Win2016/SQL2016 instance for a software upgrade. I'm using the full backup files from the SQL2012 maintenance plans. I've verified I can restore them to the original SQL2012 instance with no errors.

Restoring WES to SQL2016 reports no errors, but dbcc checkdb shows errors:

Msg 8939, Level 16, State 98, Line 13 Table error: Object ID 60, index ID 1, partition ID 281474980642816, alloc unit ID 281474980642816 (type In-row data), page (1:453). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 133129 and -4. ...etc

Restoring WILL to SQL2016 stops partway through the upgrade steps with

Database 'WILL' running the upgrade step from version 805 to version 806. Msg 601, Level 12, State 3, Line 2 Could not continue scan with NOLOCK due to data movement.

I thought the upgrade between versions was automatic. Is there anything else I need to do?

Improve this question
6
  • Does DBCC CHECKDB come back clean when you run it on the SQL Server 2012 instance?
    – Josh Darnell
    Feb 25, 2022 at 16:33
  • Yes it does. I've since tried restoring to Win2016/SQL2012 Express on the new server with similar results. So it seems to be something with the source server, and not so much with the different versions.
    – JeffH
    Feb 25, 2022 at 17:13
  • On the SQL2012 instance, dbcc is clean on both the original db, as well as the newly created db i created from the restore.
    – JeffH
    Feb 25, 2022 at 17:21
  • Would you add the DBCC page output (specifically the page header) to the question, please?
    – Sean Gallardy
    Feb 26, 2022 at 11:34
  • have you tried running DBCC in SQL 2012? Is there any record in msdb..suspect_pages? It seems you have data corruption.
    – Meyssam Toluie
    Feb 28, 2022 at 9:45

1 Answer 1

Reset to default
0

It turned out the problem was introduced as soon as I copied the file from one system to the other. The MD5 checksum was different each time I tried to copy.

I could successfully restore the database to the new server only when the MD5 checksums matched.

C:\GPCentral>certutil -hashfile \sql2\c$\backup\GP\DYNAMICS\DYNAMICS.bak MD5 MD5 hash of file \sql2\c$\backup\GP\DYNAMICS\DYNAMICS.bak: 4aec5a57a83bbb14e7bb9d5b038e0dee CertUtil: -hashfile command completed successfully.

C:\GPCentral>xcopy \sql2\c$\backup\GP\DYNAMICS\DYNAMICS.bak . /j /v /y \sql2\c$\backup\GP\DYNAMICS\DYNAMICS.bak 1 File(s) copied

C:\GPCentral>certutil -hashfile .\DYNAMICS.bak MD5 MD5 hash of file .\DYNAMICS.bak: 50bba7fbeae579567b95166a1950e25e CertUtil: -hashfile command completed successfully.

C:\GPCentral>xcopy \sql2\c$\backup\GP\DYNAMICS\DYNAMICS.bak . /j /v /y \sql2\c$\backup\GP\DYNAMICS\DYNAMICS.bak 1 File(s) copied

C:\GPCentral>certutil -hashfile .\DYNAMICS.bak MD5 MD5 hash of file .\DYNAMICS.bak: eb4e1b214e197939c2e7e1aa9a29d9ab CertUtil: -hashfile command completed successfully.

C:\GPCentral>

I still need to investigate why this is happening, but wanted to mark this question answered.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.