เครื่อง SQL Server 2005 ที่เหมือนกัน (?) การค้นหาใช้เวลา 2 วินาทีในหนึ่ง 15 นาทีในอีกอัน

สิ่งแวดล้อม:

เรามีเครื่อง Windows Server 2003 R2 32 บิตสองเครื่องที่รัน SQL Server 2005 การกำหนดค่าฮาร์ดแวร์เป็นเซิร์ฟเวอร์ที่เหมือนกันกับ Xeon 5160 CPU, 4GB RAM และ 13GB RAID0 ไม่ได้เปิดใช้งานการตั้งค่าสถานะ AWE และ / 3GB

เซิร์ฟเวอร์ถูกตั้งค่าแบบเคียงข้างกันโดยใช้รายการตรวจสอบการติดตั้งที่กำหนดไว้ล่วงหน้าและซอฟต์แวร์ที่ติดตั้งทั้งหมดนั้นเหมือนกันในทั้งสองเครื่อง

ทุกการตั้งค่าการติดตั้งเซิร์ฟเวอร์ SQL และระดับแพตช์ที่เรารู้ว่าจะเหมือนกัน สิ่งหนึ่งที่แตกต่างคือ TEMPDB คือ 400MB บนเครื่องที่เร็วและ 1.2GB สำหรับเครื่องที่ช้า อย่างไรก็ตามในทั้งสองกรณีเราไม่เห็นการจัดสรร TEMPDB ใด ๆ

ปัญหา:

มีขั้นตอนการจัดเก็บซึ่งทำงานใน 2 วินาทีในหนึ่ง แต่อีก 15 นาที ในช่วง 15 นาทีที่ผ่านมาไม่มีกิจกรรมของดิสก์เพียงเล็กน้อยไม่มีการเปลี่ยนแปลงการใช้หน่วยความจำ แต่มี CPU core หนึ่งอันที่ 100% ตลอดเวลา

ลักษณะการทำงานนี้จะยังคงอยู่แม้ว่าจะมีการสำรองฐานข้อมูลจากที่หนึ่งและเรียกคืนไปยังอีก

เนื่องจากเป็นกระบวนงานที่เก็บไว้ตัวตรวจสอบกิจกรรมและตัวสร้างโปรไฟล์จะไม่แสดงรายละเอียดใด ๆ เกี่ยวกับตำแหน่งที่อยู่ในกระบวนงานที่เก็บไว้กิจกรรม CPU สูงนี้กำลังเกิดขึ้น

คำถาม:

เราควรมองอะไรอีก

ติดตาม:

ความเชื่องช้าเกิดขึ้นในคำสั่ง FETCH NEXT สำหรับการกำหนดเคอร์เซอร์ดังต่อไปนี้:

DECLARE C CURSOR FOR
    SELECT X, Y
    FROM dbo.A
    WHERE X NOT IN (SELECT X FROM dbo.B)
    AND Z <=0
...
<snip>
...
FETCH NEXT FROM C INTO @X, @Y
FETCH NEXT FROM C INTO @X, @Y
...

แต่ละคำสั่ง FETCH - บนตารางที่มีเพียง 1,000 แถวเท่านั้นต้องใช้เวลาประมาณ 7.25 นาที (ไม่ฉันไม่รู้ว่าทำไมจึงมีสองอย่างติดต่อกันต้องถามผู้พัฒนา แต่มันทำงานได้อย่างถูกต้องบนเซิร์ฟเวอร์ทั้งสอง)

ฉันสงสัยเล็กน้อยว่า "ไม่ได้อยู่ใน (เลือก ... )" เนื่องจากดูเหมือนว่า Virtual Reads นั้นสูงมาก

การใช้วิธีการแก้ไขปัญหาประสิทธิภาพเช่นWaits และ Queues จะระบุสาเหตุของการใช้ CPU สูงดังนั้นจึงสามารถแนะนำการดำเนินการที่เหมาะสมเมื่อพบปัญหาคอขวด

SQL Server เลือกแผนอื่นในกล่องอื่น

โดยทั่วไปการกู้คืนจะลบปัญหาตามสถิติดังนั้นฉันจะดูความแตกต่างของเซิร์ฟเวอร์

ตรวจสอบหยาบก่อน อย่าถือว่า: ตรวจสอบ

• ตรวจสอบว่าการตั้งค่า SQL Server เหมือนกันในsys.configurationเช่น Max degree หรือ parallelism
• เรียกใช้ DBCC USEROPTIONS เพื่อดูว่าการตั้งค่า ANSI ใด ๆ แตกต่างกันในขณะใช้งานหรือไม่ (การตั้งค่า ANS สามารถส่งผลกระทบต่อแผนที่เลือก)
• ตรวจสอบบันทึก Windows และ SQL Server เพื่อดูว่ามีปัญหาใด ๆ หรือไม่

จากนั้นกระโดดไปที่ปลายลึกตามคำตอบของรีมัส

หากทุกอย่างเท่าเทียมกันเป็นไปได้ (ตามคำตอบของ @ gbn) ว่ามีการสร้างแผนการดำเนินการที่แตกต่างกันในแต่ละเซิร์ฟเวอร์ ในฐานะที่เป็นแบบฝึกหัดทางวิชาการมันจะน่าสนใจที่จะเห็นทั้งสองแผนดังนั้นคว้าพวกเขาจากแคชแผนในแต่ละเซิร์ฟเวอร์และเพิ่มลงในคำถามของคุณถ้าเป็นไปได้ จากนั้นเราสามารถระบุความแตกต่างในแผนที่ก่อให้เกิดการเปลี่ยนแปลงครั้งใหญ่ในประสิทธิภาพ

สำหรับการแก้ไขอย่างรวดเร็วลองดูคำแนะนำการใช้งาน สิ่งนี้ทำให้สามารถแนบแผนที่ดีจากเซิร์ฟเวอร์ที่รวดเร็วไปยังกระบวนการที่เก็บไว้บนเซิร์ฟเวอร์ที่ช้า

แก้ไข: ติดตามการอัพเดทใหม่: เคอร์เซอร์

รูปแบบอื่นของแบบสอบถามของคุณเพื่อลองดูว่าฉันไม่เห็นคำตอบในคำตอบอื่น:

DECLARE C CURSOR FOR
    SELECT X, Y
    FROM dbo.A
    WHERE NOT EXISTS (SELECT 1 FROM dbo.B WHERE dbo.B.X = dbo.A.X)
    AND Z <=0
...
<snip>
...
FETCH NEXT FROM C INTO @X, @Y
FETCH NEXT FROM C INTO @X, @Y

ขำฉันและลองแทนที่:

DECLARE C CURSOR FOR
SELECT X, Y
FROM dbo.A
WHERE X NOT IN (SELECT X FROM dbo.B)
AND Z <=0

ด้วยสิ่งนี้:

DECLARE C CURSOR FOR
SELECT 
    X, 
    Y
FROM dbo.A

    LEFT OUTER JOIN dbo.B
        ON dbo.A.X = dbo.b.X

WHERE dbo.B.X IS NULL
AND Z <=0

ฉันไม่คิดว่าสิ่งนี้จะแสดงให้เห็นว่าตัวเองเป็นปัญหาด้านประสิทธิภาพในส่วนต่อไป FETCH จากรหัสของคุณ แต่ฉันยังไม่ได้ฉีดคาเฟอีน ลองข้อเสนอแนะของฉันและแจ้งให้เราทราบ

หวังว่าจะช่วยได้

ด้าน

ตรวจสอบดัชนีของคุณและอัพเดตสถิติทั้งหมดของคุณ ฉันมีปัญหา similer มากและปรากฎว่าสถิติในเครื่องหนึ่งนั้นไม่มีประสิทธิภาพ

ฉันเคยมีพฤติกรรมเช่นนี้สองครั้งและฉันจะบอกคุณว่าได้รับการแก้ไขในแต่ละครั้ง:

1. ) ฉันเพิ่มคำใบ้ด้วย RECOMPILE ลงในกระบวนงานที่เก็บไว้เนื่องจากแผนแคชแย่มาก

2. ) ฉันเปลี่ยนกระบวนงานที่เก็บไว้เพื่อใช้ตารางชั่วคราวแทนตัวแปรตาราง

ฉันหวังว่าจะช่วยได้ โชคดี.