Quá trình quét liên tục mất 0 giây hoặc 2-3 phút

Một truy vấn như câu hỏi dưới đây được đảm bảo không trả về bất kỳ hàng nào, mất bất kỳ thứ gì từ 0 đến 160 giây trên một trong các máy chủ của chúng tôi:

select col1, col2, col3
from tab1
where 0 = 1

Hai tuần trước, điều này đã xảy ra sáu lần trong khoảng thời gian 48 giờ. Tuần trước cùng một truy vấn mất ~ 0 giây. Tôi có nhật ký SQL của ứng dụng của chúng tôi nhưng chưa tìm thấy bất kỳ nghi phạm nào. Bên cạnh đó, tôi nghĩ rằng một truy vấn loại 0 / trong đó 0 = 1 không bao giờ đánh vào các trang dữ liệu, vì vậy nó có thể chống lại các khóa dữ liệu ở cấp hàng / trang / bảng không? Lược đồ không bị chạm bởi bất kỳ SQL (đã biết) nào.

Vì vấn đề không nhất quán và máy chủ đang chịu tải rất nặng nên tôi muốn hiểu lý thuyết đằng sau những gì đang xảy ra trước khi đính kèm hồ sơ SQL. Các truy vấn khác chạy mà không có vấn đề trong những chậm trễ. Một vấn đề được biết đến trong ứng dụng là một số lượng lớn các truy vấn SQL được tạo động - khoảng 200 nghìn truy vấn duy nhất trong tổng số 850k truy vấn (đã ghi) trong khoảng thời gian 48 giờ, điều này có thể gây ra vấn đề như thế này không?

Máy chủ đang chạy phiên bản tiêu chuẩn SQL Server 2005, RAM 96 GB, đĩa trên SAN và 4 CPU / 16 lõi. Các tệp cơ sở dữ liệu và các nhóm tệp được tối ưu hóa tốt và không phải là vấn đề (nhưng chúng tôi đang xem xét vấn đề này một cách riêng biệt).

Bất kỳ con trỏ nơi để tìm được đánh giá rất cao.

Chỉnh sửa: Hoàn hảo! Phát lại truy vấn để thêm kế hoạch thực hiện và mất 1 phút 35 giây. Đây là kế hoạch thực hiện và ảnh chụp màn hình hiển thị thời lượng truy vấn:

Chỉnh sửa 2: chi tiết thời gian thống kê cho lần chạy thứ hai. Có vẻ như luôn chậm chạp ngay bây giờ, vì vậy chúng tôi sẽ gắn hồ sơ và perfmon:

SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 97402 ms.
SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

Nó xuất hiện như thể ngay cả với một ... WHERE 0 = 1mệnh đề rằng vẫn sẽ có một yêu cầu cho một ISkhóa chia sẻ ý định ( ) trên bàn. Hãy chứng minh điều này:

Tôi sẽ bắt đầu bằng cách tạo một bảng thử nghiệm:

use TestDb1;
go

create table dbo.MyTestTable1
(
    Id int identity(1, 1) not null,
    SomeInt int not null
);
go

insert into dbo.MyTestTable1 (SomeInt)
values (10), (20), (30), (40), (50);
go

Bây giờ tôi đã có bảng thử nghiệm của mình, trong một phiên (cửa sổ truy vấn) tôi sẽ thực hiện các thao tác sau để đặt Xkhóa ( ) độc quyền dbo.MyTestTable1:

use TestDb1;
go

begin tran;
    select
        Id, SomeInt
    from dbo.MyTestTable1 with (tablockx);
--commit tran;

Tôi có thể xác minh khóa độc quyền bằng cách nhìn vào sys.dm_tran_locksDMV. Sau đó, trong một phiên khác (cửa sổ truy vấn mới) tôi thực hiện chính xác những gì truy vấn của bạn làm:

use TestDb1;
go

select
    Id, SomeInt
from dbo.MyTestTable1
where 0 = 1;

Thoạt nhìn tôi thấy nó chưa hoàn thành. Nhìn vào sys.dm_exec_requests, tôi thấy chính xác tại sao đây là trường hợp:

select
    r.session_id,
    r.status,
    r.wait_type,
    r.wait_time,
    r.wait_resource,
    r.blocking_session_id
from sys.dm_exec_requests r
cross apply sys.dm_exec_sql_text(r.sql_handle) st
where st.text like '%where 0 = 1%'
and r.session_id <> @@spid;

Tôi có thể thấy ở đây rằng ... WHERE 0 = 1truy vấn của tôi đang chờ ISkhóa cho đối tượng này (object_id dịch sang dbo.MyTestTable1).

Tôi không có ý nói rằng đồng thời là vấn đề của bạn , nhưng bằng âm thanh của nó, bạn đang thể hiện các triệu chứng. Ví dụ trên là để chứng minh rằng bạn không được miễn khóa và chặn ngay cả với một WHEREđiều khoản sẽ không bao giờ trả lại dữ liệu.

Tất cả những gì chúng ta có thể làm là đoán, vì vậy, những gì bạn cần làm khi "mất nhiều thời gian" là để xem chính xác yêu cầu đó đang làm gì mà mất quá nhiều thời gian. Nếu nó đang chờ đợi điều gì đó, thì hãy xem điều gì đang chờ đợi.

Tùy thuộc vào mức độ gai và luồng yêu cầu truy vấn của bạn, hệ thống của bạn có thể chỉ cần xếp hàng truy vấn đó. Số lượng nhân viên mặc định (tức là số lượng luồng máy chủ SQL đồng thời) cho thiết lập của bạn sẽ vào khoảng 700.

Kiểm tra sys.dm_os_schedulers và sys.dm_os_waiting_t Nhiệm để xem đó có phải là một vấn đề không.