Questions tagged «wait-types»

每当服务器运行查询时，它就会跟踪等待瓶颈的时间。这些等待统计信息是识别瓶颈的最简单方法。

1
SQL Server中的SLEEP_TASK等待类型-它表示什么？
我以前没有看过SLEEP_TASK等待类型，今天我似乎收到了很多。 我不是官方的DBA，而是知道某些DBA知识的SQL Server开发人员。上周末我们将服务器升级到10.52.2500.0-R2SP1。 我在网上可以找到的所有信息都表明SLEEP_TASK服务器正在等待某种内部过程完成。我没有任何阻塞或任何后台进程（如检查点或幽灵清理）运行，因此我有些困惑。 以前有没有人看过这种等待类型，如果可以的话，您能告诉我原因是什么吗？
1
是否需要担心ASYNC_NETWORK_IO等待类型？
在查看需要花费很长时间才能执行的存储过程的列表时，最引人注目的是它。但是，大多数等待时间（81％）是ASYNC_NETWORK_IO，我知道原因：存储过程传输大约400 MB的信息。 在文档中，它指出ASYNC_NETWORK_IO的原因是客户端无法跟上大量数据的流传，这可能是事实。我不确定如何使客户端保持同步，因为它所做的只是通过ADO.NET调用存储过程，然后仅处理数据集。 因此，鉴于此信息，我是否应该担心此过程的ASYNC_NETWORK_IO等待类型？它实际上对服务器性能有影响吗？ 其他信息： 我正在使用SQL Server 2005的Service Pack 2。 客户端应用程序与SQL Server位于同一盒子上（我知道，我知道...但是我对此无能为力）。
1
对SOS_SCHEDULER_YIELD等待进行故障排除
在运行我们的企业ERP（Dynamics AX 2012）时，我注意到我们的生产环境似乎比我们的开发系统慢得多。 在运行跟踪的同时在开发和生产环境中执行相同的活动后，我确认与开发相比，SQL查询在我们的生产环境中执行得非常慢（平均慢10到50倍）。 最初，我将其归因于负载，并在下班时间在生产环境上重新运行了相同的活动，并在跟踪中找到了相同的结果。 我在SQL Server中清除了等待统计信息，然后让服务器在其正常生产负载下运行了一段时间，然后运行了以下查询： WITH [Waits] AS (SELECT [wait_type], [wait_time_ms] / 1000.0 AS [WaitS], ([wait_time_ms] - [signal_wait_time_ms]) / 1000.0 AS [ResourceS], [signal_wait_time_ms] / 1000.0 AS [SignalS], [waiting_tasks_count] AS [WaitCount], 100.0 * [wait_time_ms] / SUM ([wait_time_ms]) OVER() AS [Percentage], ROW_NUMBER() OVER(ORDER BY [wait_time_ms] DESC) AS [RowNum] FROM sys.dm_os_wait_stats …
3
高CXPACKET和LATCH_EX等待
我正在使用的数据处理系统存在一些性能问题。我从一个小时的周期中收集了等待统计信息，其中显示了大量CXPACKET和LATCH_EX等待事件。 该系统由3个处理SQL Server组成，这些SQL Server进行了大量的数字运算和计算，然后将数据馈送到中央群集服务器中。处理服务器可以一次最多运行6个作业。这些等待统计数据是针对我认为正在引起瓶颈的中央集群的。中央群集服务器具有16个核心和64GB RAM。MAXDOP设置为0。 我猜CXPACKET来自正在运行的多个并行查询，但是我不确定LATCH_EX等待事件指示什么。从我读到的内容来看，这可能是非缓冲等待？ 谁能说出这种等待统计的原因是什么，我应该采取什么行动来调查这个性能问题的根本原因？ 顶部查询结果是等待的总计统计信息，底部查询结果是1小时内的统计信息
2
LATCH_EX等待资源METADATA_SEQUENCE_GENERATOR
我们有一个生成库存报告的过程。在客户端，该过程拆分可配置数量的工作线程，以为报告构建大量数据，这些数据对应于许多商店（可能是数千个，通常是几十个）中的一个商店。每个工作线程都调用一个执行存储过程的Web服务。 用于处理每个块的数据库过程将一堆数据收集到#Temporary表中。在每个处理块的末尾，数据将被写入tempdb中的永久表。最后，在该过程结束时，客户端上的一个线程从永久tempdb表中请求所有数据。 运行此报告的用户越多，获取速度就越慢。我分析了数据库中的活动。在某一时刻，我看到35个单独的请求在流程的某一时刻全部被阻塞。所有这些SPID LATCH_EX在资源上的类型等待时间约为50 ms METADATA_SEQUENCE_GENERATOR (00000010E13CA1A8)。一个SPID拥有此资源，而其他所有SPID都被阻止。我没有在网络搜索中找到有关此等待资源的任何信息。 我们正在使用的tempdb中的表确实有一IDENTITY(1,1)列。这些SPID是否正在等待IDENTITY列？我们可以使用什么方法来减少或消除阻塞？ 该服务器是集群的一部分。该服务器在64位Windows 2008 R2 Enterprise上运行64位SQL Server 2012 Standard Edition SP1。该服务器具有64 GB RAM和48个处理器，但是该数据库是标准版本，因此只能使用16个。 （请注意，我对在tempdb中使用永久表来保存所有这些数据的设计并不感到兴奋。对此进行更改将是一个有趣的技术和政治挑战，但我愿意接受建议。） 更新4/23/2013 我们已经与Microsoft开立了支持案例。随着我们了解更多信息，我将不断更新此问题。 更新5/10/2013 SQL Server支持工程师同意等待是由IDENTITY列引起的。删除IDENTITY消除了等待。我们无法在SQL 2008 R2上重复该问题；它仅发生在SQL 2012上。
3
如何解决enq：TX-行锁争用？
我有以下情况。 我有RAC。在两个节点上都有锁。 在第一个节点上 SID EVENT USERNAME BLOCKING_SESSION ROW_WAIT_OBJ# OBJECT_NAME LOCKWAIT SQL_ID STATUS 1 102 enq: TX - row lock contention MYUSER 155 136972 TABLE1V 0000000810EFA958 5f4bzdg49fdxq ACTIVE 2 111 enq: TX - row lock contention MYUSER 155 136972 TABLE1V 0000000810EFAC98 5f4bzdg49fdxq ACTIVE 阻止会话信息 SID EVENT USERNAME ROW_WAIT_OBJ# OBJECT_NAME LOCKWAIT SQL_ID …
2
间歇性RESOURCE_SEMAPHORE_QUERY_COMPILE等待统计
我正在尝试解决一些生产SQL Server上出现的间歇性CPU高峰问题。我们正在运行具有28 GB RAM和4个CPU内核的SQL Server 2008 R2标准版。发生这种情况时，我们注意到大量的RESOURCE_SEMAPHORE_QUERY_COMPILER等待，持续约一两分钟，然后停止，然后CPU使用率恢复正常。 经过研究后，我了解到这通常是由于编译了许多不可重用的执行计划而引起的，我们目前正在对应用程序进行更改以解决该问题。 由于内存压力，计划缓存逐出也会触发此行为吗？如果是这样，我将如何检查？我正在尝试查看是否有可以做的短期补救措施，例如升级服务器RAM，直到我们部署应用程序修补程序为止。我能想到的唯一其他短期选择是将某些最繁忙的数据库移至其他服务器。
2
SQL Server性能：PREEMPTIVE_OS_DELETESECURITYCONTEXT主导等待类型
我昨天接到一个客户的电话，该客户抱怨他们的SQL Server上的CPU使用率过高。我们正在使用SQL Server 2012 64位SE。服务器正在运行Windows Server 2008 R2 Standard，2.20 GHz Intel Xeon（4核），16 GB RAM。 在确定罪魁祸首实际上是SQL Server之后，我在这里使用DMV查询在顶部等待实例。前两个等待是：（1）PREEMPTIVE_OS_DELETESECURITYCONTEXT和（2）SOS_SCHEDULER_YIELD。 编辑：这是“最等待查询”的结果（尽管有人违反了我的意愿今天早晨重新启动了服务器）： 我们进行了大量的计算/转换，所以我可以理解SOS_SCHEDULER_YIELD。但是，我很好奇PREEMPTIVE_OS_DELETESECURITYCONTEXT等待类型以及为什么它可能是最高的。 最好的说明/讨论，我可以找到这个等待类型，可以发现在这里。它提到： PREEMPTIVE_OS_等待类型是离开数据库引擎的调用，通常是对Win32 API的调用，它们正在SQL Server外部执行代码以执行各种任务。在这种情况下，它将删除以前用于远程资源访问的安全上下文。相关的API实际上被命名为DeleteSecurityContext（） 据我所知，我们没有任何外部资源，例如链接服务器或文件表。而且，我们不进行任何模拟操作，等等。备份是否可能导致备份激增或域控制器出现故障？ 到底什么会导致这成为主要的等待类型？如何进一步跟踪此等待类型？ 编辑2：我检查了Windows安全日志的内容。我看到了一些可能感兴趣的条目，但不确定这些是否正常： Special privileges assigned to new logon. Subject: Security ID: NT SERVICE\MSSQLServerOLAPService Account Name: MSSQLServerOLAPService Account Domain: NT Service Logon ID: 0x3143c Privileges: SeImpersonatePrivilege Special privileges …
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.