sp_cthonopen và song song

Tôi đang gặp vấn đề về hiệu năng với một truy vấn mà dường như tôi không thể hiểu được.

Tôi kéo truy vấn ra khỏi một định nghĩa con trỏ.

Truy vấn này mất vài giây để thực thi

SELECT A.JOBTYPE
FROM PRODROUTEJOB A
WHERE ((A.DATAAREAID=N'IW')
AND ((A.CALCTIMEHOURS<>0)
AND (A.JOBTYPE<>3)))
AND EXISTS (SELECT 'X'
FROM PRODROUTE B
WHERE ((B.DATAAREAID=N'IW')
AND (((((B.PRODID=A.PRODID)
AND ((B.PROPERTYID=N'PR1526157') OR (B.PRODID=N'PR1526157')))
AND (B.OPRNUM=A.OPRNUM))
AND (B.OPRPRIORITY=A.OPRPRIORITY))
AND (B.OPRID=N'GRIJZEN')))
AND NOT EXISTS (SELECT 'X'
FROM ADUSHOPFLOORROUTE C
WHERE ((C.DATAAREAID=N'IW')
AND ((((((C.WRKCTRID=A.WRKCTRID)
AND (C.PRODID=B.PRODID))
AND (C.OPRID=B.OPRID))
AND (C.JOBTYPE=A.JOBTYPE))
AND (C.FROMDATE>{TS '1900-01-01 00:00:00.000'}))
AND ((C.TODATE={TS '1900-01-01 00:00:00.000'}))))))
GROUP BY A.JOBTYPE
ORDER BY A.JOBTYPE

Kế hoạch thực hiện thực tế trông như thế này.

Nhận thấy cài đặt rộng của máy chủ được đặt thành MaxDOP 1 Tôi đã thử chơi xung quanh với cài đặt maxdop.

Thêm OPTION (MAXDOP 0)vào truy vấn hoặc thay đổi cài đặt máy chủ sẽ mang lại hiệu suất tốt hơn nhiều và gói truy vấn này.

Tuy nhiên, ứng dụng được đề cập (Dynamics AX) không thực hiện các truy vấn như thế này, nó sử dụng các con trỏ.

Mã thực tế bị bắt là đây.

declare @p1 int
set @p1=189527589
declare @p3 int
set @p3=16
declare @p4 int
set @p4=1
declare @p5 int
set @p5=2
exec sp_cursoropen @p1 output,N'SELECT A.JOBTYPE FROM PRODROUTEJOB A WHERE ((A.DATAAREAID=N''IW'') AND ((A.CALCTIMEHOURS<>0) AND (A.JOBTYPE<>3))) AND EXISTS (SELECT ''X'' FROM PRODROUTE B WHERE ((B.DATAAREAID=N''IW'') AND (((((B.PRODID=A.PRODID) AND ((B.PROPERTYID=N''PR1526157'') OR (B.PRODID=N''PR1526157''))) AND (B.OPRNUM=A.OPRNUM)) AND (B.OPRPRIORITY=A.OPRPRIORITY)) AND (B.OPRID=N''GRIJZEN''))) AND NOT EXISTS (SELECT ''X'' FROM ADUSHOPFLOORROUTE C WHERE ((C.DATAAREAID=N''IW'') AND ((((((C.WRKCTRID=A.WRKCTRID) AND (C.PRODID=B.PRODID)) AND (C.OPRID=B.OPRID)) AND (C.JOBTYPE=A.JOBTYPE)) AND (C.FROMDATE>{TS ''1900-01-01 00:00:00.000''})) AND ((C.TODATE={TS ''1900-01-01 00:00:00.000''})))))) GROUP BY A.JOBTYPE ORDER BY A.JOBTYPE ',@p3 output,@p4 output,@p5 output
select @p1, @p3, @p4, @p5

dẫn đến kế hoạch thực hiện này (và không may là cùng thời gian thực hiện nhiều giây).

Tôi đã thử một số thứ như bỏ các gói được lưu trong bộ nhớ cache, thêm các tùy chọn trong truy vấn bên trong định nghĩa con trỏ, ... Nhưng dường như không có cái nào trong số chúng có được cho tôi một kế hoạch song song.

Tôi cũng đã tìm kiếm trên google khá nhiều để tìm kiếm các giới hạn song song của các con trỏ nhưng dường như không thể tìm thấy bất kỳ giới hạn nào.

Tôi có thiếu một cái gì đó rõ ràng ở đây?

Bản dựng SQL thực tế SQL Server 2008 (SP1) - 10.0.2573.0 (X64)mà tôi nhận ra là không được hỗ trợ, nhưng tôi không thể nâng cấp phiên bản này khi tôi thấy phù hợp. Tôi sẽ cần chuyển cơ sở dữ liệu sang một máy chủ khác và điều đó có nghĩa là kéo một bản sao lưu không nén khá lớn qua mạng WAN chậm.

Cờ theo dõi 4199 không tạo ra sự khác biệt và cũng không TÙY CHỌN (RECOMPILE).

Các thuộc tính con trỏ là:

API | Fast_Forward | Read Only | Global (0)

FAST_FORWARDcác con trỏ không hỗ trợ song song (mặc dù máy chủ tạo kế hoạch sẽ cần từ 2012 trở lên để có được NonParallelPlanReasonnhư một phần của XML kế hoạch).

Khi bạn chỉ định FAST_FORWARD, trình tối ưu hóa sẽ chọn giữa STATICvà DYNAMICcho bạn.

Kế hoạch thực hiện được cung cấp cho thấy trình tối ưu hóa chọn một kế hoạch giống như tĩnh. Bởi vì truy vấn có chứa tổng hợp, tôi nghi ngờ một kế hoạch con trỏ động thậm chí có thể ở đây. Tuy nhiên, yêu cầu một FAST_FORWARDloại con trỏ đang ngăn một kế hoạch song song.

Bạn nên thay đổi loại con trỏ rõ ràng thành STATIChoặc KEYSET, ví dụ. Cả hai loại con trỏ này có thể sử dụng song song.

Điều đó nói rằng, bởi vì đây là một con trỏ API, việc thay đổi loại con trỏ có thể sẽ yêu cầu thay đổi ứng dụng. Đương nhiên, bạn sẽ cần hiệu suất điểm chuẩn để kiểm tra xem việc thay đổi loại con trỏ thực sự là lựa chọn tốt nhất cho bạn.