主页 / dba / 问题 / 93262
Accepted
M.Ali
Asked: 2015-02-19 13:33:39 +0800 CST

最大等待WriteLog

  • 772

我已经获得了运行我们的应用程序的服务器（SQL Server 2008R2 64 位）。应用程序的性能逐渐下降。现在它已经到了性能已成为一个严重问题的地步。我开始调查并经历了以下步骤。

  1. 检查了 sql server 上的处理器和内存使用情况（没有任何东西被最大化）大量可用资源。

  2. 索引碎片最少，但重建了索引并更新了统计信息。

  3. 没有对应用程序中的代码（应用程序代码/sql 服务器代码）进行任何更改，因此由于编写不佳的代码而导致的性能不佳不太可能是应用程序整体性能不佳的原因。

  4. 终于拿到保罗兰德尔的剧本了Wait statistics, or please tell me where it hurts。脚本的结果表明，sql server 在写入日志文件时必须等待很多。最大的等待类型是 WRITELOG。

我使用 SQLIO 工具来测量磁盘的读/写性能，它看起来和任何其他磁盘一样快。

我知道一个事实，我怀疑日志写入过程更有可能出现问题，但是我已经没有地方可以寻找了，有人可以告诉我我应该在哪里寻找问题。

日志写入缓慢的可能原因是什么？或任何正确方向的建议或指示都非常感谢。谢谢你。

╔═══════════════╦═════════════╦═══════════╗
║   WaitType    ║   Wait_S    ║ WaitCount ║
╠═══════════════╬═════════════╬═══════════╣
║ IO_COMPLETION ║ 4850500.20  ║ 4553514   ║
║ WRITELOG      ║ 25291893.90 ║ 795877    ║
╚═══════════════╩═════════════╩═══════════╝
sql-server sql-server-2008-r2

1 个回答

  1. Best Answer

    在做了更多调查之后，这是我发现的。

    它解决了这个问题（显着的性能提升和 WRITELOG 的平均等待时间为 0.0126，最初是 14.681）

    显然问题出在我的物理日志文件中的虚拟日志文件数上。

    有一个计划每晚重建索引的作业，该作业创建 36GB 的日志，直到几周前，有人添加了一个每周收缩日志文件的作业。日志文件被缩小到 500MB。

    由于它是一个非常繁忙的服务器，日志文件的大小会增长，并且它被设置为自动增长 3%。每次增长时，它都会添加越来越多的 VLF。结果，我的 35.5GB 日志文件有 1600 个 VLF。

    为了解决这个问题，我做了以下事情： 

    -- To get the number of VLFs in a physical Log file.
DECLARE @count INT, @DBname SYSNAME;
------------------------------------------------------------
SET @DBname = N'TEST_DB'
------------------------------------------------------------

DBCC LOGINFO(@DBname)
     SET @count = @@ROWCOUNT;

SELECT @DBname AS DatabaseName , @count Total_VLFs;
GO

    上述查询返回数据库名称和 VLF 数量（1600）

    为了减少 VLF 的数量，我这样做了：

    USE TEST_DB;
GO

DBCC SHRINKFILE (TEST_DB_log, 0, TRUNCATEONLY)
GO

DBCC SHRINKFILE (TEST_DB_log  , 0)
GO

ALTER DATABASE TEST_DB
  MODIFY FILE ( NAME       = TEST_DB_log
              , SIZE       = 36864MB
              , FILEGROWTH = 4096MB)
GO

    这将 VLF 的数量从 减少1600到20. 最终用户已经看到应用程序性能的突然改善。

    现在我不确定的一件事是，如果 20 个 VLF 是 36GB 日志文件的正确 VLF 数量。但它似乎对数据库的性能有很好的影响。

    • 1

相关问题