标签: performance-tuning

我有一个很大的查询要调整。我写了很多查询，但没有做很多调整。我已经包含了 SQL Sentry Plan Explorer Free (SSPEF) 的屏幕截图：

在计划的上述部分中，表 pb_WorkRquestLog 包含 229,001 行。但是，查询计划显示大约。3.48 亿行（229,001 x 1,520 次迭代）：

没有 where 子句，因此查询使用的是聚集索引扫描。我已经用 FULLSCAN 重建了所有索引并更新了所有统计信息。

这部分计划正在执行的代码是：

select distinct 
            wrs.ServiceKey 
            , owner.DepartmentName AS GroupName
            , owner.UserName AS UserId
            , owner.WRLCreateDateTime
            , owner.WRLNotes
            , wrx.CreatedDate as WRCreateDateTime
            , wrx.Id
            , wrx.Description 
            , cast(wrx.Notes as varchar(2500)) as Notes
        from    
            prism72ext.dbo.pb_WorkRequestService wrs 
            Join prism72ext.dbo.pb_WorkRequest wrx on (wrs.WorkRequestId = wrx.Id and wrx.Status = 'Incomplete')
            left join (
                select
                    wl.WorkRequestId
                    ,   d.Name AS DepartmentName
                    ,   u.UserName
                    , wl.CreatedDate as …

最近，我们的一台服务器出现了 CPU 问题，在调查此问题的同时，我们也注意到查询运行缓慢，等待PAGEIOLATCH_XX. 特别是，重新索引作业似乎总是具有这种等待类型。

作为回应，我运行了一个收集sys.dm_io_virtual_file_stats，然后将其分解为时间块并计算出每个操作的平均停顿。虽然主要是尖峰，但磁盘似乎有规律地低于 20 毫秒的值。据我所知，20 毫秒是推荐值（？）。

除此之外，我还运行了 Glenn Barry 的脚本：

select db_name(database_id) as DatabaseName, file_id
,io_stall_read_ms
,num_of_reads
,cast(io_stall_read_ms/(1.0+num_of_reads) as numeric(10,1)) as 'avg_read_stall_ms'
,io_stall_write_ms
,num_of_writes
,cast(io_stall_write_ms/(1.0+num_of_writes) as numeric(10,1)) as 'avg_write_stall_ms'
,io_stall_read_ms + io_stall_write_ms as io_stalls
,num_of_reads + num_of_writes as total_io
,cast((io_stall_read_ms+io_stall_write_ms)/(1.0+num_of_reads +
num_of_writes) as numeric(10,1)) as 'avg_io_stall_ms'
from sys.dm_io_virtual_file_stats(null,null) --where db_name(database_id) = 'tempdb'
order by [DatabaseName] desc'

它还计算平均 I/O 停顿，这也确认停顿时间小于 20 毫秒。

我还查看了以下内容，看看是否有任何挂起的任务花费的时间比建议的要长，但这并没有抛出任何挂起的 I/O 操作的时间通常超过 20 毫秒。

SELECT db_name(database_id) as 'Database',
file_name(file_id) as 'File',
io_stall, …

在我们的数据库（RDS 上的 MySQL 5.6.22）中，我们有很多事务（~500）在负载下处于“清理”状态：

> SHOW ENGINE innodb STATUS;
...
------------
TRANSACTIONS
------------
...
---TRANSACTION 70150348714, not started
MySQL thread id 132590, OS thread handle 0x2b2a712ca700, query id 10842420427 <ip> <user> cleaning up
...

我找到的唯一信息是：

线程已经处理了一个命令并准备释放内存并重置某些状态变量。

https://dev.mysql.com/doc/refman/5.6/en/general-thread-states.html

而这个问题评论提到：

如果您经常在实例中看到这种情况，您可能需要微调一些与内存相关的参数。

许多交易陷入“清理”状态——是什么导致了这种情况？

实际问题可能是什么？为什么这么多交易处于“清理”状态？我可以微调哪些内存参数来防止它？

任何建议将不胜感激。

我正在努力减少在我们的 SQL Server 上进行关键查找的事务量。

首先，我想为该指标的正常或可容忍数字定义一个基线，并且由于我们在生产中不断发布版本，然后，我想基于它创建一个自动化，当它下降时通知我。

我遇到的问题实际上是在perfmon或 SQL DMV上找到正确的计数器来获取数据。

我查看了明显的对象SQL Server，访问方法对象，但找不到特定的对象。我还尝试了其他计数器或 SQL 视图，但找不到。

任何建议将不胜感激！

这适用于 SQL Server 2012。

我正在对 Dynamics AX 环境中的整体性能缓慢进行故障排除。一切都很慢 - 应用程序本身、报告、临时等。马上，我可以看到没有配置 SQL Server 的最佳实践 - MAXDOP、tempdb、特定于 Dynamics 的跟踪标志和索引/碎片化维护。我很确定存在低效查询、缺失或非最佳索引等。

我花了一点时间查看等待统计数据，但现在我想知道我是否应该首先应用所有推荐的最佳实践（DynamicsAX 的行业标准最佳实践），然后解决缓慢的问题，或者深入研究每个问题一个，并在它到来时解决它？我知道有些人会说，在您确定需要翻转开关之前，不要开始翻转开关。

你会如何处理这种情况？

我们最近将我们的 ERP 系统从 IBM Universe 转换为 SQL Server。应用程序性能通常是可以接受的，但偶尔会降级到可怕的程度。

我们在具有 32 Gb RAM 的 VMWare 上的 Win Server 2012 和 SQL Server 2012 上运行数据库。SQL 最大内存设置为 27Gb。db 服务器仅托管此数据库，不执行任何其他功能。总数据库大小约为 110Gb。该应用程序有它自己的专用服务器。

供应商广泛使用 CLR 来移植代码（超过 36,000 个标量函数）。我了解单个 CLR 在应用程序 OLTP 上下文中运行正常，但由于逐行而不是基于设置的操作而尝试执行批量作业时，不能很好地扩展。很好……很酷……继续前进。

我运行了Brent Ozar 的脚本，该脚本将高可用内存确定为需要查看的内容，以及每个查询的大量执行计划。供应商建议向服务器添加更多 RAM，但这让我很恼火，因为应用程序似乎没有使用现在的内存。

我感兴趣的是 SQL 的整体性能和行为。我看到一系列症状表明某些事情不正确，但我无法确定。这就像服务器拒绝运行。它决心走。

粗略地说，在我看来，大约 10Gb 的内存被数据库用于缓存，大约 11GB 是免费的，大约 3.5Gb 用于计划缓存，其余的我无法解释。我对一些定义有点不确定，例如免费、保留、被盗等。它们是否重复计算？

活动监视器显示：

当我运行此查询时：

-- what's happening inside my buffer pool?
SELECT counter_name, instance_name, mb = cntr_value/1024.0
  FROM sys.dm_os_performance_counters 
  WHERE (counter_name = …

我们有一个写入量很大的 SQL 数据库（SQL Server 2008），一段时间后插入速度会降低。我阅读了这些类似的问题：Sql insert speed up，SQL：如果不是 CPU 或 IO，什么会降低插入速度？和加速插入。

此外，我阅读了这篇关于如何分析 SQL Server 性能的文章，这有助于我了解如何找到瓶颈（例如，通过查询sys.dm_exec_requests和sys.dm_os_wait_stats），但我仍然难以解释查询结果和解决问题。

首先，我开始查询sys.dm_exec_requests只返回一个状态为“正在运行”的会话 ID（选择查询）（即，我发现没有暂停会话）。那么，如果没有任何东西阻止我的插入，为什么它会变慢？

接下来，我曾经sys.dm_os_wait_stats检查有关所有等待类型的统计信息。结果显示LATCH_EX、CXPACKET和PAGEIOLATCH_SH的wait_time最长（分别为 694379 ms、310364 ms 和 308335 ms）。

然后我曾经sys.dm_os_latch_stats找到最流行的闩锁类型，在我的情况下是ACCESS_METHODS_DATASET_PARENT.

• 首先，我不知道如何在查询的结果中找到与每个 session_id 相关的查询sys.dm_exec_requests。
• 其次，sys.dm_os_wait_stats应该将多少等待时间（in ）视为高？如果上述数字（sys.dm_os_wait_stats 的结果）很高，我该如何减少它们？
• 据我了解，ACCESS_METHODS_DATASET_PARENT与并行性有关，我发现的解决方案之一是降低并行度。那正确吗？
• 在 MySQL 中，有一些可以在安装后立即完成的调整设置（例如，增加 innodb 缓冲池大小），SQL Server …

我正在编写一个从parent表中返回单个记录的查询。如果它有任何孩子，我也想在这个查询中返回。这是一对多的关系。

parent:
 -parent_id
 -name

child:
-child_id
-name
-parent_id

我的第一直觉是编写以下查询：

select name, (select count(child_id) from child c  where c.parent_id=p.parent_id) children
     from parent p
     where name like 'some name'

但我想知道是否有更有效的方法来做到这一点，因为我实际上并不关心计数，只关心它是否有孩子。任何指针？

我正在努力解决各种数据库索引之间的差异。我为自己创建了一个小例子，我不知道我是否正确理解了所有内容。

假设我们有一个这样的虚构数据库表：

addr col1  col2
===============
1    a     b
2    c     b
3    a     c
4    d     d
5    c     a
6    a     b
7    c     b
8    d     d
9    a     c

addr这是相应元组的物理位置。这是我对单列、多列和覆盖索引的外观的理解（不是物理上的，而是概念上的）：

create index on col1
a - 1, 3, 6, 9
c - 2, 5, 7
d - 4, 8

create index on (col1, col2)
a b - 1, 6
a c - 3, 9
c a - 5
c b - 2, 7
d d …

过去几周，我们一直在努力找出导致这些 I/O 问题和检查点变慢的可能原因的根本原因。

乍一看，这显然是 I/O 子系统错误，应该归咎于 SAN 管理员。但最近我们将 SAN 更改为使用全闪存，但截至今天，错误仍然弹出，我不知道为什么，因为我运行的每个指标，无论是等待统计数据还是任何其他指标，都是为了检查 SQL 服务器是否可行罪魁祸首似乎恢复正常。

它并没有真正加起来。也很可能是其他东西正在咀嚼磁盘并且 SQL Server 在这里成为受害者......但我无法找出什么？

数据库位于可用性组中，当这些事件发生时，我们确实会看到角色更改和翻转以及超时发生。

任何帮助解决这个问题将不胜感激。如果需要任何进一步的细节，请告诉我。

错误消息。以下

SQL Server 在数据库 [ABC] (7) 中的文件 [E:\MSSQL\DATA\ABC.mdf] 上遇到了 14212 次 I/O 请求需要超过 15 秒才能完成。操作系统文件句柄是 0x0000000000000D64。最新的long I/O的偏移量为：0x0000641262c000

SQL Server 在数据库 [XYZ] (7) 中的文件 [E:\MSSQL\DATA\XYZ.mdf] 上遇到了 5347 次 I/O 请求需要超过 15 秒才能完成。操作系统文件句柄是 0x0000000000000D64。最新的long I/O的偏移量为：0x0000506c060000

FlushCache：在 925084 毫秒内清理了 111476 个 buf，其中 62224 次写入（避免了 19 个新的脏 buf），用于 db 7:0 平均吞吐量：0.94 MB/秒，I/O 饱和度：55144，上下文切换 98407 最后一个未完成的目标：101241077 次写入FlushCache：在 248687 毫秒内清理了 5616 个 buf，其中 3126 个写入（避免了 3626 个新的脏 buf），用于 …