.NET thực thi một truy vấn SQL và Active Monitor hiển thị nhiều hàng chặn nhau

Tôi sử dụng .NET để thực thi các hoạt động SQL trên SQL Server 2014, đây là mã được sử dụng:

using(SqlConnection conn = new SqlConnection(connectionString)){
    ///programming/1880471/capture-stored-procedure-print-output-in-net
    conn.InfoMessage += new SqlInfoMessageEventHandler(logSqlMessages);
    conn.Open();
    using(SqlCommand stmt = new SqlCommand{
        Connection = conn,
        CommandText = sql,
        CommandTimeout = 30000 // The time in seconds to wait for the command to execute. The default is 30 seconds.
        //,CommandType = CommandType.StoredProcedure
    })
    {
        affectedRecords = stmt.ExecuteNonQuery();
    } // using stmt
} // using conn

Khi tôi nhìn vào Active Monitor, có hàng chục hàng tham chiếu cùng một thao tác. Tất cả chúng đều giống nhau session_id, một số trong số chúng có Trạng thái nhiệm vụ đang chạy và hầu hết chúng đều bị treo. Một số trong số họ có LastWaitTime CXPACKETvà hầu hết là PAGEIOLATCH_SH.

Tôi cũng đã chạy một truy vấn trên SQL Server và hành vi tương tự đã xảy ra trên Active Monitor.

Có thể đó là một hành vi bình thường của nó, nhưng thật kỳ lạ khi một thao tác CHỌN tạo ra nhiều hàng và tự chặn như thế. Bất kỳ ý tưởng về những gì có thể gây ra nó?

Nhiều hàng trong trình giám sát hoạt động cho cùng một SPID có nghĩa là truy vấn của bạn đã được chọn để được thực thi song song trên nhiều luồng.

Mỗi hàng trên Activity Monitor thực sự đại diện cho một ECID, không phải một SPID.

Trình giám sát hoạt động chỉ hiển thị SPIDcột ( session_id), nhưng có một cột bổ sung được hiển thị trong sys.sys Processes được gọi là ECID( E xecut C ontext ID ) - đây là một định danh duy nhất cho mỗi luồng mà truy vấn đang sử dụng.

Các sysprocessesquan điểm hệ thống bị phản đối, nhưng bạn có thể tìm ECID bằng một tên khác ( exec_context_id) trong sys.dm_os_tasksview (cũng như quan điểm khác nhiệm vụ liên quan đến).

Dưới đây là một truy vấn mẫu có thể nắm bắt tất cả các ID bối cảnh thực hiện được liên kết với các truy vấn đang chạy trong một phiên cụ thể và nếu có bất cứ điều gì, chúng sẽ chờ đợi:

SELECT 
    dot.session_id,
    dot.exec_context_id,
    dot.task_state,
    dowt.wait_type,
    dowt.wait_duration_ms,
    dowt.blocking_session_id,
    dowt.resource_description
FROM sys.dm_os_tasks dot
    LEFT JOIN sys.dm_os_waiting_tasks dowt
        ON  dowt.exec_context_id = dot.exec_context_id
            AND dowt.session_id = dot.session_id
WHERE dot.session_id = 51
ORDER BY exec_context_id;

Trong SQL 2016, hai cột mới đã được thêm vào sys.dm_exec numquests - DOPvà parallel_worker_count- chúng có thể được sử dụng để kiểm tra xem yêu cầu có chạy song song hay không.

Một mục quan trọng khác cần lưu ý là sự CXPACKETchờ đợi vốn dĩ là sự chờ đợi song song - chính điều này cho chúng ta biết truy vấn đang sử dụng nhiều hơn một luồng.

Các PAGEIOLATCH_SHlà chờ đợi cho thấy những chủ đề đang đọc dữ liệu từ đĩa vào bộ nhớ.