我已经失败了几次了。在 UI 中，我能够成功地将查询存储保留设置中的查询存储大小从 250 mb 增加到 1000 mb。我进行更改，关闭数据库属性窗口，重新打开，看起来更改成功，显示 1000 mb。然后当我再次查看它时（可能是第二天左右），它又恢复到 250 mb。
版本为 Microsoft SQL Server 2017 (RTM-CU13) (KB4466404) - 14.0.3048.4。
这里会发生什么？
在下面的查询计划 - https://www.brentozar.com/pastetheplan/?id=H1dwOCHed（它有 3 个部分，最后一个是问题），最底部有一个节点，消耗了 37% 的资源. 这是实际的查询计划，而不是估计的查询计划。但是，当通过 Set Statistics IO 查看逻辑读取时，它引用的表根本不显示。这包括 ActivityFeedTeamCache 和 ActivityFeedCache 的 2 个部分。
过去，我已经能够使用逻辑读取作为性能的一个很好的代理。减少逻辑读取，您就为性能做了正确的事情。
但是，由于在这种情况下，对于最差的块（ActivityFeedTeamCache、ActivityFeedCache、Locales）没有逻辑读取，那么什么是测试性能的好代理？仅仅是实际执行计划中的成本百分比下降了吗？
重新启动后，SQL Server 上意外未启用 SQL 代理，并且 3 周内没有运行任何作业，包括没有备份（完整、差异或日志）。SQL 代理现已启用。数据库的完整备份已运行。现在日志备份正在运行，并且已经运行了一个多小时（通常在完整备份运行后需要几秒钟）。
有什么潜在的问题需要考虑吗？日志文件变得非常大，大约 200 GB。