如何在事务日志备份过程中排除db/app延迟
我有一个使用server (2008年R2)数据库的应用程序，我们的应用程序周期性地出现性能问题，这与我们15分钟的事务日志备份是一致的。
应用程序控制延迟敏感的工业机器，我们发现当系统出现高事务量时，应用程序的查询时间太长(短时间内>5秒)。当事务日志备份发生时，这些查询只能同时缓慢运行，因此它似乎与事务日志备份相关。当系统执行时没有问题，我们的事务日志备份需要2-4秒，当我们处于较重的负载下，并且我们有问题，他们需要6-7秒。显然，这足以导致FIFO消息分派队列填满应用程序。
首先，我的印象是，事务日志应该对应用程序非常透明，没有锁定或任何其他操作。如果我们在执行事务日志备份时看到数据库延迟，这是否指向某种IO争用作为发票。移动到像5分钟的事务日志备份频率这样的东西而不是15分钟的优缺点是什么？
磁盘后端是一个带有600 GB 10k SAS驱动器的NetApp FAS2220。DBA确信这是应用程序问题，而不是数据库问题，因此我需要知道如何解决这个问题，以解决应用程序或数据库的问题。
TLDR:在事务日志备份期间在重负载下看到的数据库或应用程序延迟。如何排除和解决问题？
回答 1
Database Administration用户
发布于 2013-08-19 16:14:05
听起来，您的事务日志上可能有很多VLFs，这会导致SQL Server在执行事务日志备份时受到影响。你可以通过运行
use {MyDatabase}
GO
DBCC LOGINFO
GO要查看的重要部分是返回的行数。如果返回的行超过100行，则会出现问题(请用返回的行数进行注释)。
解决这个问题很容易。记录事务日志的大小。将事务日志缩小到尽可能小的范围(上面的命令将返回2行)。这是使用命令完成的。您可能需要运行几次收缩命令才能使其足够小。尝试在收缩命令之间等待一分钟，以便日志循环，并在运行收缩文件命令之前运行日志备份。
DBCC SHRINKFILE (2,1)
GO然后，一旦事务日志文件尽可能小，就可以使用中的GUI或使用ALTER命令以8000 meg块的形式增长该文件。
ALTER DATABASE MyDatabase
MODIFY FILE (name='MyLogFile', FILESIZE=8000MB)
GO如果您需要文件大于8000 Megs，那么大小为16000 megs，然后大小为24000 megs，每次都会增长8000 megs。与事务日志的先前大小相比，低于8000 meg标记的事务日志大小超过了日志的大小。
如果这不起作用，请告诉我。
https://dba.stackexchange.com/questions/48352
复制相似问题
腾讯云开发者
