我有一个使用 SQL Server (2008 R2) 数据库的应用程序,我们定期遇到应用程序性能问题,这与我们的 15 分钟事务日志备份相吻合。
应用程序控制对延迟敏感的工业机械,我们发现当系统发生大量事务时,应用程序的查询运行时间过长(在短时间内 > 5 秒)。这些查询仅在事务日志备份发生的同时运行缓慢,因此它似乎与事务日志备份有关。当系统运行没有问题时,我们的事务日志备份需要 2-4 秒,而当我们处于较重的负载并且遇到问题时,它们需要 6-7 秒。这显然足以导致一些 FIFO 消息调度队列填满应用程序。
首先,我的印象是事务日志应该对应用程序非常透明,没有锁定或其他任何事情。如果我们在执行事务日志备份时看到数据库延迟,这是否表明某种类型的 IO 争用被引入。改用 5 分钟的事务日志备份节奏而不是 15 分钟的节奏有哪些优点和缺点?
磁盘后端是带有一堆 600 GB 10k SAS 驱动器的 NetApp FAS2220。DBA 确信这是一个应用程序问题,而不是数据库问题,因此我需要知道如何解决这个问题,无论是应用程序问题还是数据库问题。
TLDR:事务日志备份期间在重负载下看到的数据库或应用程序延迟。如何排查和解决?
听起来您的事务日志上可能有很多 VLF,这会导致 SQL Server 在执行事务日志备份时受到打击。你可以通过运行找到这个
要查看的重要部分是返回的行数。如果返回的行数超过 100 行,那么您就有问题(请评论返回的行数)。
修复很容易。记下事务日志的大小。将事务日志缩小到尽可能小(上述命令将返回 2 行)。这是使用 DBCC SHRINKFILE 命令完成的。您可能需要多次运行收缩命令以使其足够小。尝试在收缩命令之间等待一分钟以使日志循环并在运行收缩文件命令之前运行日志备份。
然后,一旦事务日志文件尽可能小,则使用 SQL Server Management Studio 中的 GUI 或使用 ALTER DATABASE 命令以 8000 兆块的大小将文件增长。
如果您需要文件大于 8000 Megs,请执行 8000 megs 大小,然后 16000 megs 大小,然后 24000 megs 大小总是一次增长 8000 megs。与事务日志的先前大小相比,日志大小增长到 8000 兆标记。
如果这不起作用,请告诉我。