กุญแจต่างประเทศสามารถทำให้เกิดการหยุดชะงักและขัดขวางการอ่าน SNAPSHOT ได้หรือไม่?

นี่เป็นคำถามติดตามจาก: /programming/7684477/is-it-possible-to-set-transaction-isolation-level-snapshot-automatically

ฉันยังคงมีสถานการณ์การหยุดชะงัก / หมดเวลาในโปรแกรมประยุกต์ ASP.NET READ_COMMITTED_SNAPSHOT ONเมื่อเรียกใช้รายงานขนาดใหญ่พร้อมกันถึงแม้ว่า

ดังนั้นฉันมีสองคำถาม:

1. ฉันจะตรวจสอบว่าภาพรวมธุรกรรมการแยกระดับการทำงานเป็นไปตามที่คาดไว้หรือไม่?
2. ฉันสมมติว่าคีย์ต่างประเทศ (ในตารางของเว็บแอปพลิเคชันไปยังตารางรายงาน) มีหน้าที่รับผิดชอบการหยุดชะงัก ฉันพบบทความที่น่าสนใจนี้ :

หมายเหตุ SQL Server จะได้รับการล็อกที่ใช้ร่วมกันเมื่อตรวจสอบคีย์ต่างประเทศแม้ว่าธุรกรรมกำลังใช้ snapshot ที่อ่านแล้ว (อ่านโดยใช้การกำหนดเวอร์ชันแถว) หรือระดับการแยกสแน็ปช็อต ระวังสิ่งนี้เมื่อตรวจสอบกราฟ deadlock จากทรานแซคชันเมื่อใช้ระดับการแยกทรานแซคชันเหล่านี้ หากคุณเห็นการล็อคที่ใช้ร่วมกันให้ตรวจสอบเพื่อดูว่าการล็อคนั้นเกิดขึ้นกับวัตถุที่อ้างอิงโดยคีย์ต่างประเทศหรือไม่

ฉันจะตรวจสอบได้อย่างไรว่า FK รับผิดชอบต่อสถานการณ์การหยุดชะงัก / หมดเวลาจริง ๆ หรือไม่นั่นหมายความว่าฉันสามารถลบกุญแจต่างประเทศเหล่านั้นเพื่อป้องกันการหยุดชะงัก (สิ่งที่จะเป็นความพยายามที่ยอมรับได้)?

หมายเหตุ : ฉันแค่อ่านจากตารางที่ทำให้เกิดการหยุดชะงัก

ความคิดใด ๆ ในหัวข้อนี้ชื่นชมอย่างมาก

แก้ไข นี่คือการหยุดชะงักกราฟ บางทีใครบางคนอาจช่วยให้ฉันเข้าใจสิ่งที่ทำให้เกิดการหยุดชะงัก ดูเหมือนว่ามันจะเกิดขึ้นโดยไม่มีรายงานใด ๆ ที่ทำงานที่เกิดจากเว็บแอ็พพลิเคชันเท่านั้นเมื่อธุรกรรมสองรายการต้องการเขียนตารางเดียวกัน (หนึ่งการอัปเดตและหนึ่งการแทรกหนึ่งรายการ เหตุใดจึงมีการล็อกหน้าและวิธีเปิดใช้งานการล็อกแถวเท่านั้น? แทรก-SP TRANSACTION ISOLATION LEVEL REPEATABLE READใช้แล้ว

ฉันมีความสงสัยอย่างมากว่าทริกเกอร์สองตัว (หนึ่งอัปเดตและหนึ่งแทรก) รับผิดชอบการหยุดชะงัก นี่คือตัวแทรก:

CREATE TRIGGER [dbo].[CreateRMAFiDates] 
   ON  [dbo].[RMA] 
   AFTER INSERT
AS 
BEGIN
    SET NOCOUNT ON;

    UPDATE RMA 
    SET [fiCreationDate]=(SELECT idDate FROM tdefDate 
        WHERE CONVERT(VARCHAR, INSERTED.Creation_Date, 112) = tdefDate.Text),
        [fiPopDate]=(SELECT idDate FROM tdefDate 
        WHERE CONVERT(VARCHAR, INSERTED.POP_Date, 112) = tdefDate.Text),
        [fiManufactureDate]=(SELECT idDate FROM tdefDate 
        WHERE CONVERT(VARCHAR, INSERTED.Manufacture_Date, 112) = tdefDate.Text)
    FROM INSERTED;
END

ดังนั้นทริกเกอร์นี้จะอัปเดต RMA-Table สิ่งที่ทำให้ทริกเกอร์อัปเดตทำงาน (สิ่งที่คล้ายกัน) กราฟหยุดชะงักยืนยันการสันนิษฐานของฉันหรือไม่ ฉันคิดว่าฉันจะลบทริกเกอร์เหล่านั้นและสร้าง SP ที่ทำงานวันละครั้งสิ่งที่จะเพียงพออย่างสมบูรณ์เพราะคอลัมน์เหล่านี้มีไว้สำหรับ SSAS-Cube (Molap) เท่านั้น

แก้ไข : อย่างไรก็ตามไม่มีการหยุดชะงักอีกต่อไปเนื่องจากฉันลบทริกเกอร์เหล่านี้ :)

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

วิธีเดียวที่จะทำให้ความคืบหน้าคือการจับกราฟการหยุดชะงัก

สำหรับคำถามอื่น ๆ วิธีที่คุณสามารถตรวจสอบว่าคุณดำเนินงานภายใต้การแยกภาพรวม: sys.dm_tran_active_snapshot_database_transactionsมองใน

การตรวจสอบที่สำคัญต่างประเทศมีการเกิดขึ้นภายใต้ (ล็อค) อ่านความมุ่งมั่นความถูกต้อง ดูภาพรวมการแยก: การคุกคามสำหรับความสมบูรณ์หรือไม่ โดย Hugo Kornelis เพื่อดูรายละเอียด

กราฟการหยุดชะงักแสดงการประหารชีวิตพร้อมกันสองครั้งเพื่อRM2.dbo.RMAทำให้เกิดการหยุดชะงัก ทริกเกอร์ของคุณหายไปเป็นเงื่อนไขร่วมระหว่างและRMAinserted

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