This is my first post, so apologies if I'm missing any of the protocols.
We are running SQL Server 2017 with the latest patches applied (14.0.3238.1). We use memory optimized tables in our database. There appears to be a number of issues which we can't get to the bottom of.
1. On startup, the database in question takes 10 mins or so to be available. Shortly afterwards there is a stack dump
2019-10-21 22:19:03.99 spid5s Recovery is complete. This is an informational message only. No user action is required.
2019-10-21 22:19:10.92 spid25s ***Stack Dump being sent to C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\LOG\SQLDump0080.txt
2019-10-21 22:19:10.92 spid25s SqlDumpExceptionHandler: Process 25 generated fatal exception c0000005 EXCEPTION_ACCESS_VIOLATION. SQL Server is terminating this process.
2019-10-21 22:19:10.92 spid25s * *******************************************************************************
2019-10-21 22:19:10.92 spid25s *
2019-10-21 22:19:10.92 spid25s * BEGIN STACK DUMP:
2019-10-21 22:19:10.92 spid25s * 10/21/19 22:19:10 spid 25
2019-10-21 22:19:10.92 spid25s *
2019-10-21 22:19:10.92 spid25s *
2019-10-21 22:19:10.92 spid25s * Exception Address = 00007FFB54A91860 Module(hkengine+0000000000191860)
2019-10-21 22:19:10.92 spid25s * Exception Code = c0000005 EXCEPTION_ACCESS_VIOLATION
2019-10-21 22:19:10.92 spid25s * Access Violation occurred reading address 0000000000000030
2. After this, the database appears to function normally - but the server uses 100% of one CPU continuously. When we check for long running queries, there doesn't appear to be any (we also checked using a trace).
3. If we backup the database, then try and restore it on a different Windows server with a similar error, but it never recovers, with an error 'The database 'dotnetnuke' is marked RESTORING and is in a state that does not allow recovery to be run.'
4. Running:
SELECT log_bytes_since_last_close /(1024*1024) as Log_bytes_since_last_close_mb,
time_since_last_close_in_ms,
current_checkpoint_id, outstanding_checkpoint_count, recovery_checkpoint_id, recovery_checkpoint_ts, closing_checkpoint_id, *
FROM sys.dm_db_xtp_checkpoint_stats
GO
as suggested on some forums gives:
Log_bytes_since_last_close_mb: 9655
time_since_last_close_in_ms: 24760718
current_checkpoint_id: 91
outstanding_checkpoint_count: 4
recovery_checkpoint_id: 87
recovery_checkpoint_ts: 247888
closing_checkpoint_id: 88
Running:
SELECT name, log_reuse_wait_desc
FROM sys.databases
GO
shows that log reuse is waiting for XTP_CHECKPOINT. However, when we run CHECKPOINT manually the logs say that the checkpoint is complete - the command in SQL Server management studio doesn't exit though and stays in 'Executing'
In summary, we are running constantly high CPU and can't restore the database backups to a different server. Any thoughts would be much appreciated.
BTW: Our server has 4 virtual CPUs and 16Mb RAM, and 20Gb of disk space spare. The database is in Simple recovery mode and the transaction log is 1Gb, while the transaction log has bloated to 10Gb.
1.0.0.20