如何在事务日志备份期间解决 db/app 延迟问题

Question

我有一个使用 SQL Server (2008 R2) 数据库的应用程序，我们定期遇到应用程序的性能问题，这与我们的 15 分钟事务日志备份一致。

该应用程序控制对延迟敏感的工业机械，我们发现当系统发生高交易量时，应用程序的查询运行时间过长（短时间超过 5 秒）。这些查询只会在事务日志备份发生的同时运行缓慢，因此它似乎与事务日志备份相关。当系统正常运行时，我们的事务日志备份需要 2-4 秒，而当我们处于较重的负载下并且出现问题时，它们需要 6-7 秒。这显然足以导致一些 FIFO 消息调度队列在应用程序上被填满。

首先，我的印象是事务日志应该对应用程序非常透明，没有锁定或其他任何事情。如果我们在执行事务日志备份时看到数据库延迟，这是否表明某种 IO 争用正在被调用。改用 5 分钟事务日志备份节奏而不是 15 分钟这样的方式的利弊是什么？

磁盘后端是带有一堆 600 GB 10k SAS 驱动器的 NetApp FAS2220。DBA 确信这是一个应用程序问题而不是数据库问题，所以我需要知道如何解决这个问题，无论是应用程序问题还是数据库问题。

TLDR：事务日志备份期间在重负载下看到的数据库或应用程序延迟。如何排查和解决？

Answer 1

听起来您的事务日志上可能有很多 VLF，这会导致 SQL Server 在执行事务日志备份时受到影响。你可以通过运行找到这个

use {MyDatabase}
GO
DBCC LOGINFO
GO

要查看的重要部分是返回的行数。如果返回的行数超过 100 行，则说明您遇到了问题（请对返回的行数发表评论）。

修复很容易。记下事务日志的大小。将事务日志缩小到尽可能小（上面的命令将返回 2 行）。这是使用 DBCC SHRINKFILE 命令完成的。您可能需要多次运行收缩命令以使其足够小。尝试在收缩命令之间等待一分钟，以便日志在运行收缩文件命令之前循环并运行日志备份。

DBCC SHRINKFILE (2,1)
GO

然后，一旦事务日志文件尽可能小，使用 SQL Server Management Studio 中的 GUI 或使用 ALTER DATABASE 命令以 8000 兆块的方式增大文件。

ALTER DATABASE MyDatabase
MODIFY FILE (name='MyLogFile', FILESIZE=8000MB)
GO

如果您需要文件大于 8000 兆，则大小为 8000 兆，然后是 16000 兆，然后是 24000 兆，每次总是增加 8000 兆。与事务日志的先前大小相比，日志的大小增长到 8000 兆标记的低位。

如果这不起作用，请告诉我。