SELECT / INSERT Deadlock

อินสแตนซ์นี้โฮสต์ฐานข้อมูล SharePoint 2007 (SP) เราประสบปัญหาการหยุดชะงัก SELECT / INSERT จำนวนมากต่อตารางที่ใช้งานหนักจำนวนหนึ่งในฐานข้อมูลเนื้อหา SP ฉัน จำกัด ทรัพยากรที่เกี่ยวข้องให้แคบลงกระบวนการทั้งสองต้องการล็อคในดัชนีที่ไม่ใช่คลัสเตอร์
INSERT ต้องการล็อค IX บนทรัพยากร SELECT และ SELECT ต้องการล็อค S บนทรัพยากร INSERT กราฟเดดล็อกแสดงให้เห็นและสามทรัพยากร 1. ) สองรายการจาก SELECT (เธรดขนานผู้ผลิต / ผู้บริโภค) และ 2) INSERT
ฉันได้แนบกราฟการหยุดชะงักเพื่อตรวจสอบของคุณ เนื่องจากนี่คือรหัส Microsoft และโครงสร้างตารางเราไม่สามารถทำการเปลี่ยนแปลงใด ๆ
อย่างไรก็ตามฉันได้อ่านบนเว็บไซต์ MSFT SP ว่าพวกเขาแนะนำให้ตั้งค่าตัวเลือกการกำหนดค่าระดับอินสแตนซ์ MAXDOP เป็น 1 เนื่องจากอินสแตนซ์นี้มีการใช้งานร่วมกันระหว่างฐานข้อมูล / แอปพลิเคชันอื่น ๆ อีกมากมาย

ดังนั้นฉันตัดสินใจลองและป้องกันคำสั่ง SELECT เหล่านี้ไม่ให้ขนานกัน ฉันรู้ว่านี่ไม่ใช่วิธีแก้ปัญหา แต่เป็นการแก้ไขชั่วคราวเพิ่มเติมเพื่อช่วยแก้ไขปัญหา ดังนั้นฉันจึงเพิ่ม“ เกณฑ์ต้นทุนสำหรับความเท่าเทียม” จากมาตรฐานของเราที่ 25 ถึง 40 เมื่อทำเช่นนั้นแม้ว่าภาระงานจะไม่เปลี่ยนแปลง (SELECT / INSERT ที่เกิดขึ้นบ่อยครั้ง) การหยุดชะงักได้หายไป คำถามของฉันคือทำไม

SPID 356 INSERT มีการล็อก IX บนเพจที่เป็นของดัชนีที่ไม่ใช่คลัสเตอร์
SPID 690 SELECT ID การดำเนินการ 0 มีการล็อก S บนหน้าของดัชนีที่ไม่ใช่คลัสเตอร์เดียวกัน

ตอนนี้

SPID 356 ต้องการล็อก IX บนทรัพยากร SPID 690 แต่ไม่สามารถรับได้เพราะ SPID 356 กำลังถูกบล็อกโดย SPID 690 รหัสการดำเนินการ 0 ล็อค S
SPID 690 รหัสการดำเนินการ 1 ต้องการล็อค S บนทรัพยากร SPID 356 แต่ไม่สามารถรับได้เพราะ SPID 690 รหัสการดำเนินการ 1 กำลังถูกบล็อคโดย SPID 356 และตอนนี้เรามีการหยุดชะงัก

แผนปฏิบัติการสามารถพบได้ใน SkyDrive ของฉัน

รายละเอียดการหยุดชะงักเต็มสามารถดูได้ที่นี่

หากใครบางคนสามารถช่วยฉันเข้าใจว่าทำไมฉันจะขอบคุณมันจริงๆ

ตาราง EventReceivers
Id uniqueidentifier ไม่มี 16
ชื่อ nvarchar ไม่มี 512
SiteId uniqueidentifier ไม่มี 16
WebId uniqueidentifier ไม่มี 16
hostid uniqueidentifier ไม่มี 16
HostType int ไม่มี 4
Itemid int ไม่มี 4
dirname nvarchar ไม่มี 512
LeafName nvarchar ไม่มี 256
ชนิด int ไม่มี 4
sequenceNumber int ที่ 4
สภา nvarchar ไม่มี 512
ชั้น nvarchar no 512
Data nvarchar no 512
ตัวกรอง nvarchar no 512
SourceId tContentTypeId no 512
SourceType int no 4
ข้อมูลประจำตัว int 4 ไม่มี
ContextType varbinary 16
ContextEventType varbinary ไม่มี 16
varbinary ContextId ไม่มี 16
ContextObjectId varbinary ไม่มี 16
ContextCollectionId varbinary ไม่มี 16

index_name index_description index_keys
EventReceivers_ByContextCollectionId nonclustered ตั้งอยู่บนหลัก SiteId, ContextCollectionId
EventReceivers_ByContextObjectId nonclustered ตั้งอยู่บนหลัก SiteId, ContextObjectId
EventReceivers_ById nonclustered ที่ไม่ซ้ำกันตั้งอยู่บนหลัก SiteId, Id
EventReceivers_ByTarget คลัสเตอร์ที่ไม่ซ้ำกันตั้งอยู่บนหลัก SiteId, WebId, hostid, HostType, ประเภท ContextCollectionId, ContextObjectId, ContextId, ContextType, ContextEventType, SequenceNumber, แอสเซมบลี, คลาส
EventReceivers_IdUnique คีย์ที่ไม่ซ้ำกันที่ไม่ซ้ำกันของคลัสเตอร์ซึ่งตั้งอยู่บน Primary Id

บนใบหน้าของมันนี้ดูเหมือนว่าคลาสสิกการหยุดชะงักการค้นหา ส่วนผสมที่สำคัญสำหรับรูปแบบการหยุดชะงักนี้คือ:

• SELECTแบบสอบถามที่ใช้ดัชนี nonclustered ที่ไม่ครอบคลุมกับคีย์ค้นหา
• INSERTแบบสอบถามที่ปรับเปลี่ยนดัชนีคลัสเตอร์และจากนั้นดัชนี nonclustered

SELECTเข้าถึงดัชนี nonclustered ก่อนแล้วดัชนีคลัสเตอร์ การINSERTเข้าถึงดัชนีคลัสเตอร์ก่อนจากนั้นดัชนีที่ไม่คลัสเตอร์ การเข้าถึงทรัพยากรเดียวกันในลำดับที่แตกต่างกันเพื่อรับการล็อคที่เข้ากันไม่ได้เป็นวิธีที่ดีในการ 'บรรลุ' การหยุดชะงักของหลักสูตร

ในกรณีนี้SELECTแบบสอบถามคือ:

... และINSERTแบบสอบถามคือ:

แจ้งให้ทราบการบำรุงรักษาดัชนีที่ไม่ได้เน้นสีเขียวที่เน้น

เราจำเป็นต้องดูแผนอนุกรมSELECTในกรณีที่แตกต่างจากรุ่นขนานมาก แต่เนื่องจาก Jonathan Kehayias บันทึกไว้ในคำแนะนำของเขาในการจัดการ Deadlocksรูปแบบการหยุดชะงักโดยเฉพาะนี้มีความอ่อนไหวต่อเวลาและรายละเอียดการดำเนินการสอบถามภายใน การหยุดชะงักประเภทนี้มักเกิดขึ้นและไปโดยไม่มีเหตุผลภายนอกที่ชัดเจน

จากการเข้าถึงระบบที่เกี่ยวข้องและการอนุญาตที่เหมาะสมฉันมั่นใจว่าในที่สุดเราก็สามารถทำงานได้อย่างถูกต้องว่าทำไมการหยุดชะงักเกิดขึ้นกับแผนขนาน แต่ไม่ใช่อนุกรม (สมมติว่าเป็นรูปร่างทั่วไปแบบเดียวกัน) เส้นที่มีศักยภาพของการสอบสวนรวมถึงการตรวจสอบสำหรับการเพิ่มประสิทธิภาพลูปซ้อนกันและ / หรือ prefetching - ทั้งที่ภายในสามารถบานปลายระดับแยกไปREPEATABLE READในช่วงระยะเวลาของคำสั่ง เป็นไปได้ว่าคุณลักษณะบางอย่างของดัชนีแบบขนานค้นหาช่วงที่กำหนดมีส่วนช่วยในเรื่องนี้ หากแผนอนุกรมพร้อมใช้งานฉันอาจใช้เวลาศึกษารายละเอียดเพิ่มเติมเนื่องจากอาจน่าสนใจ

ทางออกปกติสำหรับการหยุดชะงักประเภทนี้คือการทำให้ดัชนีครอบคลุมแม้ว่าจำนวนคอลัมน์ในกรณีนี้อาจทำให้การทำไม่ได้ผล (และนอกจากนี้เราไม่ควรยุ่งกับสิ่งเหล่านี้บน SharePoint ฉันบอก) ในที่สุดคำแนะนำสำหรับแผนแบบอนุกรมเท่านั้นเมื่อใช้ SharePoint มีอยู่ด้วยเหตุผล (แม้ว่าไม่จำเป็นต้องเป็นสิ่งที่ดีเมื่อมันมาถึงมัน) หากการเปลี่ยนแปลงในเกณฑ์ค่าใช้จ่ายสำหรับการขนานการแก้ไขปัญหาในขณะนี้เป็นสิ่งที่ดี ในระยะยาวฉันอาจจะมองแยกเวิร์กโหลดบางทีอาจใช้ Resource Governor เพื่อให้เคียวรีภายในของ SharePoint ได้รับMAXDOP 1พฤติกรรมตามที่ต้องการและแอปพลิเคชันอื่นสามารถใช้การขนานได้

คำถามของการแลกเปลี่ยนที่ปรากฏในร่องรอยการหยุดชะงักดูเหมือนว่าปลาเฮอริ่งแดงกับฉัน เป็นผลสืบเนื่องมาจากกระทู้อิสระที่เป็นเจ้าของทรัพยากรซึ่งในทางเทคนิคจะต้องปรากฏในต้นไม้ ฉันไม่เห็นอะไรเลยที่จะแนะนำว่าการแลกเปลี่ยนตัวเองนั้นมีส่วนโดยตรงกับปัญหาการหยุดชะงัก

หากนี่คือการหยุดชะงักการค้นหาแบบคลาสสิกรายการทรัพยากรจะมีทั้งดัชนีแบบคลัสเตอร์และดัชนีแบบไม่เป็นกลุ่ม โดยทั่วไป SELECT จะถือล็อค SHARED ในดัชนี NC และรอให้ล็อค SHARED บน CI ในขณะที่ INSERT จะได้รับล็อค EXCLUSIVE บน CI และรอการล็อค EXCLUSIVE บน NC รายการทรัพยากรใน deadlock xml จะแสดงรายการวัตถุทั้งสองนี้ในกรณีนี้

เนื่องจากกราฟการหยุดชะงักเกี่ยวข้องกับดัชนี NC เท่านั้นเราจึงสามารถแยกตัวเลือกนั้นออกได้

นอกจากนี้หากนี่เป็นล็อคที่ไม่ทำงานเนื่องจากการวนซ้ำเข้าร่วมกับการตั้งค่า UNORDEREDแผนการดำเนินการจะแจ้งให้เราทราบว่าใช้อัลกอริทึมการกำหนดค่าล่วงหน้าแบบ UNORDERED ซึ่งไม่ใช่กรณีที่นี่อีกครั้ง (ดูการอัปเดตด้านล่าง)

นั่นทำให้เราต้องคิดว่านี่เป็นจุดหยุดชะงักเนื่องจากแผนขนาน

กราฟเดดล็อกแสดงผลไม่ถูกต้อง แต่ถ้าคุณดู Deadlock XML คุณจะเห็นว่าสองเธรดจากคำสั่ง SELECT (SPID 690) เกี่ยวข้องกับเดดล็อก เธรดคอนซูเมอร์กำลังถือกุญแจ SHARED ไว้ที่หน้า 1219645 และรอผู้ผลิตบนพอร์ต 801f8ed0 (e_waitPipeGetRow) เธรดผู้ผลิตกำลังรอการล็อคที่ใช้ร่วมกันในหน้า 1155940

คำสั่ง INSERT กำลังถือล็อค IX บนหน้า 1155940 และรอการล็อก IX บนหน้า 1219645 ส่งผลให้เกิดการหยุดชะงัก

ฉันเชื่อว่าการหยุดชะงักจะถูกนำไปใช้เมื่อใช้แผนอนุกรมสำหรับคำสั่ง SELECT เนื่องจากไม่มีประเด็นใดที่จะต้องใช้ SHARED lock ในมากกว่าหนึ่งหน้า ฉันยังคิดว่าแผนอนุกรมจะเหมือนกันเกือบจะเป็นแผนขนาน

[อัพเดทตามความคิดเห็นของ Paul]

เห็นได้ชัดว่าแผนกำลังใช้อัลกอริทึมลูปที่ซ้อนกันที่เหมาะสม

นั่นอธิบายว่าทำไมล็อค SHARED จึงถูกเก็บไว้จนกระทั่งสิ้นสุดคำสั่ง การอ่านซ้ำได้รวมกับแผนขนานมีความเสี่ยงต่อการหยุดชะงักมากกว่าแผนอนุกรมเนื่องจากแผนขนานอาจได้รับและเก็บล็อคจากช่วงต่าง ๆ ของดัชนีในขณะที่แผนอนุกรมได้รับล็อคในลักษณะที่เป็นลำดับมากขึ้น