sp_cursoropen และขนาน


15

ฉันพบปัญหาด้านประสิทธิภาพด้วยข้อความค้นหาที่ฉันไม่สามารถเข้าใจได้

ฉันดึงแบบสอบถามออกจากคำจำกัดความของเคอร์เซอร์

แบบสอบถามนี้ใช้เวลาไม่กี่วินาทีในการดำเนินการ

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 ไม่สร้างความแตกต่างและไม่มีตัวเลือก (RECOMPILE)

คุณสมบัติเคอร์เซอร์คือ:

API | Fast_Forward | Read Only | Global (0)

คำตอบ:


20

FAST_FORWARDเคอร์เซอร์ไม่สนับสนุนความเท่าเทียม (แม้ว่าเซิร์ฟเวอร์สร้างแผนจะต้อง 2,012 หรือสูงกว่าเพื่อให้ได้NonParallelPlanReasonเป็นส่วนหนึ่งของ XML showplan)

เมื่อคุณระบุFAST_FORWARD, เพิ่มประสิทธิภาพการเลือกระหว่างSTATICและDYNAMICสำหรับคุณ

แผนการดำเนินการที่ให้ไว้จะแสดงเครื่องมือเพิ่มประสิทธิภาพที่เลือกแผนแบบคงที่ เนื่องจากแบบสอบถามมีการรวมฉันสงสัยว่าแผนเคอร์เซอร์แบบไดนามิกอาจเป็นไปได้ที่นี่ อย่างไรก็ตามการขอFAST_FORWARDประเภทเคอร์เซอร์กำลังป้องกันแผนขนาน

คุณควรเปลี่ยนประเภทเคอร์เซอร์เป็นอย่างชัดเจนSTATICหรือKEYSETตัวอย่างเช่น เคอร์เซอร์ทั้งสองประเภทนี้สามารถใช้การขนาน

ที่กล่าวเนื่องจากเป็นเคอร์เซอร์ API การเปลี่ยนประเภทของเคอร์เซอร์น่าจะต้องมีการเปลี่ยนแปลงแอปพลิเคชัน โดยปกติคุณจะต้องทำการวัดประสิทธิภาพเพื่อตรวจสอบว่าการเปลี่ยนประเภทเคอร์เซอร์เป็นตัวเลือกที่ดีที่สุดสำหรับคุณจริงๆ

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.