标签：str index 本地 slow careful contain mmu prope word
背景环境：
|
1
2
3
4
5
6
7
8
9
|
select session_id, db_name(database_id) as "db_name", status, wait_type, wait_time, textfrom sys.dm_exec_requests cross apply sys.dm_exec_sql_text(sql_handle)where session_id>50 |
|
1
2
3
4
5
6
7
8
9
10
|
select session_id, most_recent_session_id, net_transport, auth_scheme, client_net_address, client_tcp_port, local_net_address, local_tcp_portfrom sys.dm_exec_connections |
从查询结果可以大致推断出本地SSMS作为一个客户端如果使用TCP/IP协议也是要走网卡的，而且执行结果显示了登录使用的协议以及登录验证方式还有使用的端口号。使用shared memory协议的连接不通过socket通信的方式获取数据，而是直接通过系统总线从共享内存读取。
关于等待事件：
This wait type is where SQL Server has sent some data to a client through TDS and is waiting for the client to acknowledge that is has consumed the data, and can also show up with transaction replication if the Log Reader Agent job is running slowly for some reason.
这个等待类型表示SQL Server正在通过TDS向客户端传送请求的数据，也可能表示事务复制的日志读取代理由于某些原因运作缓慢。
(Books Online description: “Occurs on network writes when the task is blocked behind the network. Verify that the client is processing data from the server.”)
（联机丛书的解释：当任务由于被阻塞于网络时出现，证明客户端正在接收服务端的数据）
Other information:
This wait type is never indicative of a problem with SQL Server, and the vast majority of the time it is nothing to do with the network either (it’s very common to see advice stating that this is a network issue). A simple test for network issues is to test the ping time between the SQL Server and the client/application/web server, and if the ping time is close to the average wait time, then the wait is because of the network (which may just be the normal network latency, not necessarily a problem).
这个等待类型表示并非SQL Server的问题，绝大多数情况下也与网络问题无关（很多时候大家都认为是网络问题），一个简单的测试方式是从客户端ping一下服务端，如果延迟接近sys.dm_exec_requests中wait_time的平均值则证明确实与网络相关（很多时候都只是正常的网络延迟，并不是网络故障）。
There is usually nothing that you can do with your SQL Server code that will affect this wait type. There are a few causes of this on the client side, including:
针对此等待事件一般无需对SQL代码做什么改动，引发此问题的原因基本都是由于来源于客户端，例如：
。客户端代码使用RBAR方式处理数据集，每次只从结果集拉取一条数据，而不是全部获取完毕后再处理。
。客户端所在的服务器有某些性能问题，导致客户端运作缓慢。
。客户端运行在配置错误或者过载的虚拟机上，总之也是服务器本身的问题。
On the SQL Server side, the only possibility I know of for causing this is using MARS (Multiple Active Result Sets) with large result sets.
You can demonstrate this wait type easily by running a query with a large result set through SSMS on the SQL Server itself, with no network involved.
在数据库服务端，就我所知唯一可能的原因就是使用了MARS的大结果集引起的。（其实就是因为结果集太大）
你可以很轻易的通过在数据库服务器上使用本机名登录的方式，运行一个获取大结果集的查询，来验证这个等待事件是否会出现。
Some other things you can try:
Description:
This wait type is when a thread is calling the Windows WaitForSingleObject function for synchronization with an external client process that is communicating using that object.
(Books Online description: N/A --表示联机丛书没有说明)
这个等待事件表示一个线程正在向外部客户端进程同步某个对象的数据，因此出现此种等待。一般此种等待出现在SQL Server 2012及以上的版本，以前用ASYNC_NETWORK_IO代替。
Other information:
This wait type is commonly seen in conjunction（同时出现） with ASYNC_NETWORK_IO, depending on the network transport used to communicate with the client, so to troubleshoot, follow the same steps as for ASYNC_NETWORK_IO.
Note that when a thread calls out to Windows, the thread changes from non-preemptive (SQL Server controls the thread) to preemptive (Windows controls the thread) mode. The thread’s state will be listed as RUNNING, as SQL Server doesn’t know what Windows is doing with the thread.
这种等待事件一般与ASYNC_NETWORK_IO等待事件一起出现，取决于连接所使用的网络传输类型，因此解决步骤参考ASYNC_NETWORK_IO的解决方式。
注意，当一个连接线程被从SQL Server控制（非抢占式）到被Windows控制（抢占式）的后，线程的状态就会变为running,此时SQL Server并不知道windows在对此线程做什么。
关于抢占式与非抢占式的区别，参考官网博客中关SQL OS与Windows OS对线程的不同处理方式的介绍。
ASYNC_NETWORK_IO和PREEMPTIVE_OS_WAITFORSINGLEOBJECT等待事件
标签：str index 本地 slow careful contain mmu prope word
原文地址：https://www.cnblogs.com/littlewrong/p/9417255.html
