是否有可能减轻延迟持久性造成的数据丢失风险

Question

由于磁盘性能较差，我需要使用 SQL Server 2016 中的延迟持久性设置进行评估。

微软明确表示，这会带来数据丢失的风险，因为事务是在内存中而不是在磁盘上提交的。

这种风险不仅限于 SQL Server 崩溃，其他原因也可能导致这种风险，例如服务器重新启动。

如果有人尝试重新启动服务器，是否有任何方法可以通过将 SQL Server 将数据闪存到磁盘来降低风险？我搜索过诸如事件触发之类的内容，但一无所获。

除了我上面提到的风险之外，您还认为我应该考虑其他风险吗？这是一个独立的 SQL Server，不参与故障转移群集，也不属于可用性组的一部分。

---

我提到的性能不佳与日志延迟有关；此 SQL Server 实例中等待时间最长的是 CX*，其次是 WriteLog。目前将事务写入磁盘需要 3-4 毫秒。这是关于云的，即使在 SQL Server 中激活 T1800 后，系统也会受到日志延迟的影响。我猜这与虚拟化/vSAN 固件和更深层次的卷设置有关；我们已经打开了供应商服务票，但为了以防万一供应商无法提供帮助，我必须调查所有可能提高性能的可能性。

Answer 1

如果有人尝试重新启动服务器，是否有可能减轻将 SQL Server 将数据闪存到磁盘的风险？

SQL Server 使用预写日志记录来保证持久性，因此包含已提交的延迟持久性事务的日志缓冲区必须刷新到磁盘以减少数据丢失。存储过程sys.sp_flush_log可用于刷新日志缓冲区，包括延迟的持久性事务。以下是文档指导的摘录：

如果您因为性能优势而选择使用延迟事务持久性，但您还希望对服务器崩溃或故障转移时丢失的数据量有保证的限制，那么请定期执行 sys.sp_flush_log。例如，如果您想确保不会丢失超过 n 秒的数据，则可以每 n 秒执行一次 sp_flush_log。

通过 SQL 代理作业执行的示例脚本：

USE YourDatabase;
DECLARE @RPO datetime = '00:00:05'; --no more than 5 seconds of data loss
WHILE 1 = 1
BEGIN
    WAITFOR DELAY @RPO;
END;

我不相信有一种方法可以在关闭时自动运行进程，即使有，数据也总是可能丢失并延迟持久性。该功能并不是为了解决“日志磁盘性能不佳”的问题，而是为了减少可接受的某些数据丢失时的日志延迟。

顺便说一句，缓慢的日志写入通常与基础设施有关。对于许多应用程序来说，甚至 3 毫秒到 4 毫秒都是可以忍受的，但我不能说这对于您的工作负载是否可以接受。如果不是，您的云提供商可能除了延迟持久性之外还有其他选择，延迟持久性是一把重锤。