สาเหตุของกระบวนการที่ตกเป็นเหยื่อการหยุดชะงัก

ฉันมีกระบวนการกับ Select ซึ่งใช้เวลานานในการดำเนินการตามลำดับ 5 ถึง 10 นาที
ขณะนี้ฉันไม่ได้ใช้ NOLOCK เป็นคำแนะนำสำหรับเอ็นจินฐานข้อมูล MS SQL
ในเวลาเดียวกันเรามีกระบวนการอื่นในการอัปเดตและแทรกลงในฐานข้อมูลเดียวกันและตารางเดียวกัน
กระบวนการแรกได้เริ่มต้นเมื่อเร็ว ๆ นี้เพื่อสิ้นสุดก่อนเวลาอันควรด้วยข้อความ

SQLEXCEPTION: ธุรกรรมหยุดชะงักในทรัพยากรที่ถูกล็อกด้วยกระบวนการอื่นและได้รับเลือกให้เป็นเหยื่อการชะงักงัน

กระบวนการแรกนี้กำลังทำงานในไซต์อื่น ๆ ในเงื่อนไขที่เหมือนกัน แต่มีฐานข้อมูลที่เล็กกว่าดังนั้นคำสั่ง select ที่เป็นปัญหาจึงใช้เวลาสั้นกว่ามาก (ตามลำดับ 30 วินาทีหรือมากกว่านั้น) ในไซต์อื่น ๆ เหล่านี้ฉันไม่ได้รับข้อความหยุดชะงักในไซต์อื่น ๆ เหล่านี้ ฉันยังไม่ได้รับข้อความนี้ในไซต์ที่มีปัญหาในตอนแรก แต่ฉันคิดว่าเนื่องจากฐานข้อมูลเติบโตขึ้นฉันเชื่อว่าฉันต้องข้ามเกณฑ์บางอย่าง นี่คือคำถามของฉัน:

1. เวลาที่ใช้ในการดำเนินการธุรกรรมอาจทำให้กระบวนการที่เกี่ยวข้องมีแนวโน้มที่จะถูกตั้งค่าสถานะเป็นเหยื่อการชะงักงัน
2. หากฉันดำเนินการเลือกด้วยคำใบ้ NOLOCK สิ่งนี้จะลบปัญหาหรือไม่
3. ฉันสงสัยว่าฟิลด์วันที่และเวลาที่ถูกตรวจสอบเป็นส่วนหนึ่งของคำสั่ง WHERE ในคำสั่ง select ทำให้เวลาในการค้นหาช้า ฉันสามารถสร้างดัชนีตามฟิลด์นี้ได้หรือไม่ จะแนะนำหรือไม่?

คำถามที่ 1: เวลาที่ใช้ในการทำธุรกรรมอาจทำให้กระบวนการที่เกี่ยวข้องมีแนวโน้มที่จะถูกตั้งค่าสถานะเป็นเหยื่อการชะงักงัน

ไม่ SELECT เป็นเหยื่อเนื่องจากมีการอ่านข้อมูลเท่านั้นดังนั้นธุรกรรมจึงมีต้นทุนต่ำกว่าที่เกี่ยวข้องจึงถูกเลือกให้เป็นเหยื่อ:

โดยค่าเริ่มต้นเลือกโปรแกรมฐานข้อมูลการหยุดชะงักเป็นเหยื่อเซสชั่นที่ใช้ทำธุรกรรมที่มีราคาแพงอย่างน้อยที่จะย้อนกลับ หรืออีกวิธีหนึ่งคือผู้ใช้สามารถระบุลำดับความสำคัญของเซสชันในสถานการณ์ที่หยุดชะงักโดยใช้SET DEADLOCK_PRIORITYคำสั่ง DEADLOCK_PRIORITY สามารถตั้งค่าเป็น LOW, NORMAL หรือ HIGH หรือจะกำหนดเป็นค่าจำนวนเต็มใดก็ได้ในช่วง (-10 ถึง 10)

คำถามที่ 2 หากฉันดำเนินการเลือกด้วยคำใบ้ NOLOCK สิ่งนี้จะลบปัญหาหรือไม่

ไม่ด้วยเหตุผลหลายประการ:

• ก่อนอื่นคุณควรพยายามกำจัดการหยุดชะงักอย่างถูกต้องโดยการตรวจสอบสาเหตุที่แท้จริง
• สกปรกอ่านมีความไม่สอดคล้องกันอ่าน
• วิธีที่เหมาะสมในการระบุการอ่านสกปรกคือการใช้ระดับการแยกธุรกรรม
• มีทางออกที่ดีมาก: อ่านความมุ่งมั่นภาพรวม

ไตรมาสที่ 3 ฉันสงสัยว่าฟิลด์วันที่และเวลาที่ถูกตรวจสอบเป็นส่วนหนึ่งของคำสั่ง WHERE ในคำสั่ง select ทำให้เวลาในการค้นหาช้า ฉันสามารถสร้างดัชนีตามฟิลด์นี้ได้หรือไม่ จะแนะนำหรือไม่?

อาจ. สาเหตุของการชะงักงันนั้นเกือบจะเป็นฐานข้อมูลที่มีการจัดทำดัชนีไม่ดีการสืบค้น 10 นาทีเป็นที่ยอมรับในสภาวะที่แคบเช่นนี้ฉันมั่นใจ 100% ในกรณีของคุณไม่สามารถยอมรับได้

ด้วยความมั่นใจ 99% ฉันขอประกาศว่าการหยุดชะงักของคุณเกิดจากการสแกนตารางขนาดใหญ่ที่ขัดแย้งกับการอัปเดต เริ่มจากการจับกราฟการหยุดชะงักเพื่อวิเคราะห์สาเหตุ คุณมีแนวโน้มที่จะต้องเพิ่มประสิทธิภาพสคีมาของฐานข้อมูลของคุณ ก่อนที่คุณจะทำการแก้ไขใด ๆ โปรดอ่านหัวข้อนี้การออกแบบดัชนีและบทความย่อย

นี่คือวิธีที่ปัญหาการชะงักงันนี้เกิดขึ้นจริงและวิธีการแก้ไขจริง นี่เป็นฐานข้อมูลที่ค่อนข้างใช้งานได้โดยมีธุรกรรม 130K เกิดขึ้นทุกวัน ดัชนีในตารางในฐานข้อมูลนี้เดิมเป็นแบบคลัสเตอร์ ลูกค้าขอให้เราจัดทำดัชนีแบบไม่รวมกลุ่ม ทันทีที่เราทำการหยุดชะงักก็เริ่มขึ้น เมื่อเราสร้างดัชนีใหม่เป็นคลัสเตอร์การหยุดชะงักจะหยุดลง

คุณควรลองคำตอบที่นี่ แต่คุณควรตรวจสอบโค้ดของคุณด้วย คุณสามารถอ่านคำตอบของ Polyfun ได้ที่นี่: จะกำจัดการชะงักงันในแอปพลิเคชัน SQL Server 2005 และ C # ได้อย่างไร

โดยจะอธิบายถึงปัญหาการเกิดพร้อมกันและการใช้ "with (updlock)" ในข้อความค้นหาของคุณอาจแก้ไขสถานการณ์การชะงักงันของคุณได้อย่างไร - ขึ้นอยู่กับว่าโค้ดของคุณกำลังทำอะไรอยู่ หากโค้ดของคุณเป็นไปตามรูปแบบนี้น่าจะเป็นวิธีแก้ไขที่ดีกว่าก่อนที่จะหันไปใช้การอ่านแบบสกปรกเป็นต้น

แม้ว่า @ รีมัส Rusanu 's อยู่แล้วคำตอบที่ดีเยี่ยมในกรณีหนึ่งคือการมองไปข้างหน้ามีความเข้าใจที่ดีขึ้นในSQL Server ของการหยุดชะงักสาเหตุและกลยุทธ์การติดตามผมจะแนะนำให้คุณอ่านแบรด McGehee ' s วิธีการติดตามชะงักงันใช้ SQL Server 2005 Profiler