问题[waits](dba)

我有一个扩展事件，它过滤我的慢查询。我为它创建了以下脚本。

CREATE EVENT SESSION [SlowQueriesAndStatementsLargerThan3Seconds] ON SERVER 
ADD EVENT sqlserver.rpc_completed(SET collect_statement=(1)
    ACTION(sqlserver.client_app_name,sqlserver.client_hostname,sqlserver.database_id,sqlserver.database_name,sqlserver.nt_username,sqlserver.session_id,sqlserver.session_nt_username,sqlserver.sql_text,sqlserver.username)
    WHERE ([duration]>=(3000000))),
ADD EVENT sqlserver.sp_statement_completed(
    ACTION(sqlserver.client_app_name,sqlserver.client_hostname,sqlserver.client_pid,sqlserver.database_name,sqlserver.nt_username,sqlserver.server_principal_name,sqlserver.session_id)
    WHERE ([duration]>=(3000000))),
ADD EVENT sqlserver.sql_batch_completed(
    ACTION(sqlserver.client_app_name,sqlserver.client_hostname,sqlserver.database_id,sqlserver.database_name,sqlserver.nt_username,sqlserver.session_id,sqlserver.session_nt_username,sqlserver.sql_text,sqlserver.username)
    WHERE ([duration]>=(3000000)))
ADD TARGET package0.event_file(SET filename=N'SlowQueriesAndStatementsLargerThan3Seconds'),
ADD TARGET package0.ring_buffer
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=ON,STARTUP_STATE=ON)
GO

我想包括我的查询在缓慢时等待的位置。我想为它包含 wait_info，但是当我添加它时，我的跟踪会填充其他查询的不相关等待。为了跟踪等待，我添加了以下事件：

    CREATE EVENT SESSION [SlowQueriesAndStatementsLargerThan3Seconds] ON SERVER 
ADD EVENT sqlos.wait_info(
    ACTION(sqlos.task_elapsed_quantum,sqlos.task_time,sqlserver.client_app_name,sqlserver.client_hostname,sqlserver.database_id,sqlserver.database_name,sqlserver.session_id,sqlserver.sql_text)
    WHERE ([opcode]='End')),
ADD EVENT sqlserver.rpc_completed(SET collect_statement=(1)
    ACTION(sqlserver.client_app_name,sqlserver.client_hostname,sqlserver.database_id,sqlserver.database_name,sqlserver.nt_username,sqlserver.session_id,sqlserver.session_nt_username,sqlserver.sql_text,sqlserver.username)
    WHERE ([duration]>=(3000000))),
ADD EVENT sqlserver.sp_statement_completed(
    ACTION(sqlserver.client_app_name,sqlserver.client_hostname,sqlserver.client_pid,sqlserver.database_name,sqlserver.nt_username,sqlserver.server_principal_name,sqlserver.session_id)
    WHERE ([duration]>=(3000000))),
ADD EVENT sqlserver.sql_batch_completed(
    ACTION(sqlserver.client_app_name,sqlserver.client_hostname,sqlserver.database_id,sqlserver.database_name,sqlserver.nt_username,sqlserver.session_id,sqlserver.session_nt_username,sqlserver.sql_text,sqlserver.username)
    WHERE ([duration]>=(3000000)))
ADD TARGET package0.event_file(SET filename=N'SlowQueriesAndStatementsLargerThan3Seconds'),
ADD TARGET package0.ring_buffer
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=ON,STARTUP_STATE=ON)
GO

是否可以只包含在这种情况下运行 3 秒或更长时间的查询的等待？

在迁移到 SQL Server 2017（从 SQL Server 2008）后PAGELATCH，我看到PAGEIOLATCH和等待的增加。WRITELOG虽然我可以解释增加PAGEIOLATCH和WRITELOG（我们有其他磁盘 - HDD 而不是 SSD），但不知道为什么PAGELATCH也会增加。

它们有关系吗？

我周围看到的不是，原因PAGELATCH属于内存，而其他属于IO。

我一直在尝试解决一个我认为可以通过在我的 CentOS 机器上更改 MySQL（5.1.67）中的 wait_timeout 变量来解决的问题。

所以，我用我想要的值（180）更新了 /etc/my.cnf，并重新启动了 MySQL，但现在我惊讶地发现我得到不同的 wait_timeout 值取决于我的显示方式（见下文） ：

mysql> show global variables like "%wait%";
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| innodb_lock_wait_timeout | 50    |
| table_lock_wait_timeout  | 50    |
| wait_timeout             | 180   |
+--------------------------+-------+
3 rows in set (0.00 sec)

mysql> show variables like "%wait%";
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| innodb_lock_wait_timeout | 50    |
| table_lock_wait_timeout  | 50    |
| wait_timeout             | 28800 |
+--------------------------+-------+
3 rows in set (0.00 sec)

我猜第二个查询显示的是会话变量，而不是全局变量，但我不明白为什么它们会有所不同，在退出我的 MySQL 会话后，重新启动 MySQL，然后再次登录。他们怎么不一样？而且，我想，如何确保相同的值（180）在所有内容中都是一致的？

任何建议/帮助表示赞赏。谢谢。

我正在尝试使用 sys.dm_io_virtual_file_stats DMF 在我的许多服务器上生成所以 IO 等待信息。我遇到了 Paul Randall 的这篇文章：http ://www.sqlskills.com/blogs/paul/survey-tempdb-and-transaction-log-io-latencies/ 。在其中，他要求人们用这个查询的结果来回应：

SELECT
    [database_id],
    [file_id],
    [ReadLatency] =
        CASE WHEN [num_of_reads] = 0
            THEN 0 ELSE ([io_stall_read_ms] / [num_of_reads]) END,
    [WriteLatency] =
        CASE WHEN [num_of_writes] = 0
            THEN 0 ELSE ([io_stall_write_ms] / [num_of_writes]) END
FROM
    sys.dm_io_virtual_file_stats (NULL, NULL)
WHERE
    [file_id] = 2 OR [database_id] = 2;
GO

我的问题是他为什么要使用io_stall_read_ms / num_of_reads而不是io_stall_read_ms / num_of_bytes_read为了获得平均值。我认为 ms/byte 会比 ms/read 提供更多信息。这至少在一定程度上让我相信我不明白 num_of_reads/writes 列实际代表什么。

BOL 只是说

对文件发出的读取次数。

这对我帮助不大。我会很感激我能得到的任何澄清。

我有一个运行 SELECT * 的编写不佳的应用程序，每隔几秒就会产生一个 2MB 的结果集。我无法纠正这个。不过，我很困惑，连接遇到 ASYNC_NETWORK_IO 等待。该应用程序在数据库服务器本地。

我已经验证了 dm_exec_connections 中的 session_id 是“共享内存”。client_net_address 是“本地机器”。

以前有人经历过吗？或者能够向我解释为什么会这样？

谢谢！

给定某种等待，您如何在生产 SQL 2008 R2 服务器上安全地找到导致这些等待的查询？

在这种特殊情况下，我想知道async_network_io.