内存 OLTP 数据库在启动期间需要很长时间才能恢复

Question

我们在 Windows 上使用 SQL Server 2019，并在某些数据库上激活了内存中 oltp。服务器重新启动/服务重新启动后，内存数据库需要很长时间才能可用（超过一个小时），即使大多数表不持久。内存优化对象的大小非常小：10 MB

我们看到主数据库上有一个等待类型为（110514580ms）WAIT_XTP_RECOVERY的后台会话，并且几乎没有读取。CPU 核心利用率为 100%。磁盘闲置。

我们对此数据库使用透明数据加密（TDE）。该数据库使用同义词来访问同一实例上的另一个数据库。它使用服务代理。实例在数据库上设置了事务复制，但未激活内存。

添加 CPU 使其速度更快。这是一台低端机器，但并不垃圾。XTP 引擎 2.11。

知道发生了什么事吗？

Answer 1

服务器重新启动/服务重新启动后，内存数据库需要很长时间才能可用（超过一个小时），即使大多数表不持久。

除了耐用或不耐用之外，还有很多方面。持久表需要将其数据/增量文件读回内存，这需要时间。是不是一直都需要时间？不知道，我们需要更多数据。

如果您有许多内存中对象（表、存储过程），则所有这些对象（无论类型如何）都需要重新编译并加载到内存中，然后关联的（持久）表才能将其索引加载到内存中。编译过程单独应该不会花费很长时间，但组合在一起可能会花费很长时间。这不包括诸如反*软件扫描您正在做的事情 1500 次并妨碍您的事情。

如果您查看等待统计信息，是否PREMPTIVE_OS_FINDFILE会PREEMPTIVE_OS_CREATEDIRECTORY表明与系统上正在编译和加载的对象数量发生争用 - 为此，TF 9944将禁用调试符号 (PDB) 和输出文件的创建以及其他优化。这可能会对具有大量内存优化项目的系统产生重大影响。

最后，这个服务器的规格是什么？性能计数器显示什么？CPU 很高，这表明我有很多项目和/或反*软件攻击了您（或两者都有！）。CPU现在处于什么状态？您是否有涵盖启动时间的 etw 跟踪？VLF和日志情况如何，需要读取多少日志？

评论摘要及回复

• 大部分等待时间都会显示 PREEMPTIVE_OS_CREATEDIRECTORY
• 我们使用四个核心的 Xeon Gold 6354，内存为 96 GB；存储大约有 20.000 个 I/O。虚拟机。
• TF 9944 有所帮助，我们现在可以快速启动
• 编译内存中对象花费了 15 分钟，而不是现在的 2 小时
• 数据库有 800 个对象，但只有 100 个是 MEMORY_OPTIMIZED

我现在问自己的是，我们如何才能防止在启动时重新编译 DLL？

你真的不知道，这就是它目前在 SQL Server 中的工作方式。编译代码可能/很昂贵，这就是这里发生的情况，目前只有 4 个处理器是瓶颈。

SQL Server 在关闭时执行隐式检查点。这够好吗？或者我们应该在关闭之前调用显式的检查点？

给出的数据均未表明这是一个问题。

KB3147012 怎么样？除了 TF 9944 之外，我还尝试设置 TF 9929。您对此有何建议？

您想让文件以较小的文件大小开始吗？这就是 9929 所做的，我不认为这是你的问题。