7

We recently converted a table to memory optimized data. Our backups have all ballooned (3x300GB files to 3x600GB files for Full, 3x50GB to 3x250GB for Diffs), and startup has been getting progressively slower.

In an attempt to stave off these issues we converted the table in question to SCHEMA_ONLY durability, but now the database will not leave 'In Recovery' status.

The errorlog originally was updating on recovery status every 20 seconds, predicting analysis would take ~9days to complete, after roughly an hour however, the updates ceased.

SP_WHO2 shows only one process accessing the DB in question with the command XTP_DB_RECOVERY, however SELECT * FROM sys.dm_db_xtp_checkpoint_files returns no rows.

Do I have any recourse? Or way to see the estimated time remaining for this XTP_DB_RECOVERY command?

  • What's the exact version number you're on? In SSMS, look at the name of the server, and there will be a set of numbers next to it, or SELECT @@VERSION. – Brent Ozar Oct 15 at 18:20
  • 13.0.5492.2, Just updated to CU10 – InMemoryHardships Oct 15 at 18:30
  • 1
    I would worry that it's related to KB 4520109, which just got added to CU10. I know the symptoms don't sound the same, but the fact that it's related to in-memory restores makes me think there might be a related bug that you're hitting. I'd open a support case with Microsoft. – Brent Ozar Oct 15 at 18:40
  • I appreciate your response. Previously we were able to get up and running by enabling trace flag 9918 (per this article). Ultimately the restore ended up completing after 2 hours of silence from the error log. – InMemoryHardships Oct 15 at 19:17
  • Try running the query in this db<>fiddle and see if that gives you any information back. – HandyD Oct 15 at 21:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.