sp_cursoropen та паралелізм

У мене виникає проблема продуктивності із запитом, який, здається, не можу опустити.

Я витягнув запит із визначення курсору.

Цей запит займає секунди для виконання

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

Фактичний план виконання виглядає приблизно так.

Помітивши налаштування для широкого сервера, було встановлено MaxDOP 1. Я спробував розігратися з налаштуваннями maxdop.

Додавання OPTION (MAXDOP 0)запиту або зміна налаштувань сервера призводить до набагато кращої продуктивності та цього плану запитів.

Однак відповідна програма (Dynamics AX) не виконує такі запити, вона використовує курсори.

Фактичний захоплений код такий.

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

в результаті цього плану виконання (і, на жаль, ті ж самі кілька разів секунди виконання).

Я спробував кілька речей, таких як скидання кешованих планів, додавання параметрів у запит усередині визначення курсору, ... Але, схоже, жодна з них не отримує мені паралельного плану.

Я також шукав google досить небагато, шукаючи обмеження паралелізму курсорів, але не можу знайти обмежень.

Я пропускаю тут щось очевидне?

Фактична збірка SQL - це те, SQL Server 2008 (SP1) - 10.0.2573.0 (X64)що я розумію, не підтримується, але я не можу оновити цей примірник, як вважаю за потрібне. Мені потрібно перенести базу даних на інший сервер, і це означатиме перетягування досить великої нестисненої резервної копії через повільну WAN.

Прапор сліду 4199 не має жодних значень, а також ОПЦІЯ (РЕКОМПЛІЯ).

Властивості курсору:

API | Fast_Forward | Read Only | Global (0)

FAST_FORWARDкурсори не підтримують паралелізм (хоча сервер, що генерує план, повинен бути 2012 або вище, щоб отримати його NonParallelPlanReasonяк частину XML-шоу Showplan).

Коли ви вказуєте FAST_FORWARD, оптимізатор вибирає між вами STATICта DYNAMICдля вас.

Наданий план виконання показує оптимізатору вибору статичного плану. Оскільки запит містить агрегацію, я сумніваюсь, що динамічний план курсора тут навіть можливий. Тим не менш, запит на FAST_FORWARDтип курсору перешкоджає паралельному плану.

Ви повинні чітко змінити тип курсору на STATICабо KEYSET, наприклад. Обидва ці типи курсорів можуть використовувати паралелізм.

Однак, оскільки це курсор API, зміна типу курсора, ймовірно, вимагатиме зміни програми. Звичайно, вам потрібно буде орієнтувати продуктивність, щоб перевірити, чи зміна типу курсора дійсно найкращий варіант для вас.