问题
我们有一个 SQL Server 实例 (2008) 运行我们的软件，我们认为用户数量很少（在任何给定时间大约有 30 个并发连接到服务器）
作为供应商，我们不是 SQL DBA，只能提供解决此类问题的基本技能。大多数客户都有自己的 SQL DBA 来为他们担任此角色，但有时如果客户得不到足够的支持，我们必须介入并提供帮助。
尽管他们确实将该服务器用于 SQL 以外的用途，而且这是一个必须单独处理的问题，但我们最近注意到，该客户端的 sqlservr.exe 进程使用的 RAM 比我们预期的软件多得多。
背景
首先，我要说的是，我理解 SQL 最大服务器内存默认设置基本上是使用服务器的所有可用内存。我们将该值更改为 10GB，因为考虑到服务器的大小和所用软件的比例，我们预计它们在任何给定时间只需要大约 4-6GB。
一些可能与我的问题相关或不相关的信息：
- 他们将我们软件的数据库设置为完整恢复模式，并且日志一直在增长，大约 3 年来无需维护。
- 当我们重新启动 SQL 服务时，用户将返回软件，在约 24 小时的时间内，他们将使用我们预期的 RAM 量（分配的 10GB 中约 4-6GB）
- 我们一直在运行 Perfmon，将一些计数器结果与没有出现此问题的时间段进行比较，但没有注意到日志之间存在任何显著差异
- 检查事件查看器是否存在明显的内存问题
结论
我目前唯一的猜测是，这与庞大的日志/恢复模型或与缓存相关的某些 SQL 设置有关。也许这是 SQL 专家希望看到的正常行为，但根据我们在 SQL Server 中运行软件的有限经验，对于这种规模的安装来说，这是不正常的。
因此，总结一下就是一个 TLDR：
SQL Server 2008 恢复模型和日志大小是否会影响 sqlservr.exe 进程的内存使用情况？如果答案是肯定的，那么我所描述的“问题”对于 SQL 来说是否正常，我们之前是否没有遇到过这种情况？如果答案是否定的，您建议调查哪些其他事项来解决我的问题？
答案1
这个数据库有多大？SQL Server 喜欢将整个数据库放在内存中。从您的问题来看，它听起来像是 200 MB MDF 和 250 GB LDF，或者类似的东西。
恢复模型不会进入其中，除非他们严重忽视数据库，而他们显然是这样做的。
- 将数据库设置为简单恢复。
- 将日志文件缩小到合理的大小。
- 将数据库设置为完全恢复。
- 运行完整备份。
- 立即地日程常规的完整和事务日志备份。
我个人不会浪费时间考虑其他任何东西，除非您实施基本的数据库维护（尽管我认为 10 GB 对于 SQL Server 来说是一个吝啬的内存分配）。