sp_cursoropen ve paralellik

Ben başımı etrafında almak gibi olamaz bir sorgu ile bir performans sorunu ile karşılaşıyorum.

Sorguyu bir imleç tanımından çıkardım.

Bu sorgunun yürütülmesi birkaç saniye sürüyor

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

Gerçek yürütme planı şuna benzer.

Sunucu genelinde ayarın MaxDOP olarak ayarlandığını fark ettim 1 Maxdop ayarlarıyla oynatmayı denedim.

OPTION (MAXDOP 0)Sorguyu eklemek veya sunucu ayarlarını değiştirmek çok daha iyi performans ve bu sorgu planı ile sonuçlanır.

Ancak, söz konusu uygulama (Dynamics AX) böyle sorgular yürütmez, imleçler kullanır.

Yakalanan asıl kod şudur.

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

sonuçta bu yürütme planı (ve ne yazık ki aynı çok saniyelik yürütme süreleri).

Önbelleğe alınmış planları bırakmak, sorguya imleç tanımının içine seçenekler eklemek gibi birçok şey denedim ... Ama hiçbiri bana paralel bir plan getirmiyor gibi görünüyor.

Ayrıca imleçlerin paralellik sınırlamalarını aramak için google'da arama yaptım, ancak herhangi bir sınırlama bulamıyorum.

Burada bariz bir şeyi mi kaçırıyorum?

Gerçek SQL yapı SQL Server 2008 (SP1) - 10.0.2573.0 (X64)desteklediğini fark, ancak uygun gördüğüm gibi bu örneği yükseltemiyorum. Başka bir sunucuya veritabanını aktarmak gerekir ve bu yavaş bir WAN üzerinde oldukça büyük sıkıştırılmamış bir yedekleme çekmek anlamına gelir.

4199 izleme bayrağı bir fark yaratmaz ve OPTION (RECOMPILE) öğelerini de etkilemez.

İmleç özellikleri:

API | Fast_Forward | Read Only | Global (0)

FAST_FORWARDimleçler paralelliği desteklemez (ancak planı oluşturan sunucunun NonParallelPlanReason, showplan XML'inin bir parçası olarak almak için 2012 veya üstü olması gerekir ).

Belirttiğinizde FAST_FORWARD, optimize edici sizin için STATICve arasında seçim yaparDYNAMIC .

Sağlanan yürütme planı, optimizatöre statik benzeri bir plan seçtiğini gösterir. Sorgu toplama içerdiğinden, dinamik bir imleç planının burada bile mümkün olduğundan şüpheliyim. Bununla birlikte, FAST_FORWARDimleç türü istemek paralel bir planı engelliyor.

İmleç türünü açıkça STATICveya KEYSETörneğin olarak değiştirmeniz gerekir . Her iki imleç türü de paralellik kullanabilir.

Bununla birlikte, bu bir API imleci olduğundan, imleç türünü değiştirmek muhtemelen bir uygulama değişikliği gerektirecektir. Doğal olarak, imleç türünü değiştirmenin gerçekten sizin için en iyi seçenek olup olmadığını kontrol etmek için performansı karşılaştırmanız gerekir.