Question

I have a strange issue with a SQLServer 2014 (12.0.4439.1) database.

I created some months ago a data file and table to play with In-Memory basic features and see if could improve some of our processes. When I finished I wanted to clean everything but I didn't know that "Once you create a memory-optimized filegroup, you can only remove it by dropping the database".

Well, I didn't want to delete my database (since it is used in the real life by real people) nor re-create / re-fill it (quite a lot of work).

So everything stayed like that : a normal DB with one empty file for in-memory stuff. And everything is going well.

But, once, log file of this database is going crazy : its size increases and nothing can stop it. And when I try to shrink it, I often (not always) get a "shrink failed for log file due to XTP_CHECKPOINT" which looks like related to in-memory features. And after trying backup / service restart / checkpoint and other esoteric commands, log file can be manipulated and shrunk correctly.

So briefly : I don't understand what happened.

Does someone has experienced that ? and/or know a clean way to avoid/fix this strange behaviour ?

[EDIT] : the issue looks very similar to https://support.microsoft.com/en-us/kb/3090141 but in my case, hotfix is already installed and the workaround suggested (offline / online) doesn't work

Usually, in SQLServer logs there's a HkHostLogCheckpointRecord() message every hour. Log file increasing started to happen when this messages stopped to appear. Is it the cause or the consequence ? that's the question....

Was it helpful?

Solution

OK, I didn't find a clear explanation, but found how to fix that.

It was because file used to store in-memory objects was full and could not allocate more space. So no more checkpoints, and logs and growing more and more. This is happening even though there is no in-memory objects in the database (and therefore no reason for the data file to grow).

Allowing file to grow more is not working, you need to add another file to your filegroup.

So, knowing that, it's easy to fix.

  1. add another file into the filegroup for in-memory
  2. checkpoint (or, if you can afford it, restart SQLServer service)
  3. shrink log file to a more reasonable size

Conclusion of the story : carefully monitoring data size is even more important with in-memory.

Licensed under: CC-BY-SA with attribution
Not affiliated with dba.stackexchange
scroll top