มีความเสี่ยงอะไรบ้างถ้าเราเปิดใช้งานสแนปชอตการอ่านใน sql-server

ฉันได้อ่านที่นี่ว่าข้อมูลพิเศษบางอย่างจะถูกจัดเก็บต่อแถวดังนั้นเราจึงอาจเห็นประสิทธิภาพลดลง แต่มีความเสี่ยงอื่นอีกหรือไม่

เช่น. สิ่งนี้จะส่งผลต่อการกู้คืนฐานข้อมูลหรือไม่? มีอะไรอีกบ้างที่เราต้องทำเพื่อใช้ประโยชน์จากสิ่งนี้?

ฉันวางแผนที่จะดำเนินการคำสั่งเหล่านี้:

ALTER DATABASE DatabaseName SET READ_COMMITTED_SNAPSHOT ON
ALTER DATABASE DatabaseName SET ALLOW_SNAPSHOT_ISOLATION ON

ฉันเชื่อว่าสิ่งนี้จะทำให้เรามีบางสิ่งที่ใกล้เคียงกับ oracle มากขึ้นหากว่ามีธุรกรรมหนึ่งธุรกรรมที่กำลังอัพเดทธุรกรรมอื่น ๆ ยังคงสามารถอ่านข้อมูลเก่าได้ ถูกต้องหรือไม่

ฉันกำลังมองหาสิ่งนี้เพราะฉันเบื่อปัญหาการล็อคใน SQL Server 2005 ฉันหวังว่าสิ่งนี้อาจลดการหยุดชะงักเป็นครั้งคราวที่ผู้ใช้ของเราเห็นช่วยให้ประสิทธิภาพโดยรวมของแอปพลิเคชันของเราและกระตุ้นให้นักพัฒนาของเรา กลัว.

สรุป

1. หากคุณมีปัญหาในการล็อคคุณมีปัญหากับรหัสของคุณ: มันไม่ได้เป็นเครื่องมือฐานข้อมูล
2. มันไม่ใช่กระสุนวิเศษ
3. คุณอาจเพิ่มปัญหามากขึ้น

ภาระ

มันจะเพิ่มภาระให้กับ tempdb และCPU ของคุณ ดูเพิ่มเติมที่:

• "ผลกระทบด้านประสิทธิภาพ: ค่าใช้จ่ายที่เป็นไปได้ของ Read_Committed_Snapshot" ( Linchi Shea)

ความปลอดภัย

สิ่งที่สำคัญที่สุด isolations ภาพรวมจะไม่ปลอดภัยในหลายกรณีโดยค่าเริ่มต้น อ่าน"การแยก Snapshot" (Wikipedia)สำหรับข้อมูลเพิ่มเติมเกี่ยวกับความผิดปกติของการเขียนแบบเอียง ส่วนถัดไปคือ "การสร้าง Snapshot Isolation Serializable" เพื่อแก้ไขปัญหานี้

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

ดูเพิ่มเติมที่:

• "อันตรายที่อาจเกิดขึ้นจากระดับการแยกสแนปช็อตการอ่านที่ยอมรับ" (JimMcLeod โต้แย้งในความคิดเห็นโดย Alex Kuznetsov)
• การหยุดชะงัก!: "สแนปชอตที่อ่านแล้ว" อธิบาย (Nick Berardi)
• Serializable vs. Snapshot Isolation Level, ปัญหาหินอ่อน (Craig Freedman)
• การอ่านที่เกี่ยวข้องกับ UDF ภายใต้ READ_COMMITTED_SNAPSHOT อาจดูเหมือนไม่สอดคล้องกัน (Alex Kuznetsov)

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

จากประสบการณ์ของฉันการโหลดเพิ่มเติมใน TEMPDB นั้นเล็กน้อยและประโยชน์ของการกำหนดเวอร์ชันของแถวในการลดจำนวนผู้อ่านที่ถูกบล็อกนั้นมีขนาดใหญ่มาก

สำหรับการอ้างอิง, เวอร์ชันแถว (แยก snapshot) เป็นวิธีการที่ออราเคิลได้ใช้มานานหลายทศวรรษที่จะเกิดการแยกโดยไม่ต้องให้ผู้อ่านการปิดกั้นและออราเคิลดีบีเอสผมเคยทำงานในเกือบ 20 ปีมีประสบการณ์ให้ห่างไกลปัญหาการปิดกั้นน้อยกว่า SQL Server ไม่ นักพัฒนา SQL ส่วนใหญ่ลังเลที่จะใช้การแยกสแน็ปช็อต แต่เนื่องจากพวกเขาทดสอบโค้ดกับฐานข้อมูลที่ใช้การตั้งค่าเริ่มต้นเท่านั้น

สองสามคะแนนเพิ่มเติมเพื่อเพิ่มไปยังคำตอบอื่น ๆ :

SET ALLOW_SNAPSHOT_ISOLATION ONเปิดใช้งานการแยกสแน็ปช็อตในฐานข้อมูลเท่านั้น ในการใช้ประโยชน์จากมันคุณจะต้องทำการถอดรหัสและSET TRANSACTION ISOLATION LEVEL SNAPSHOTการทำธุรกรรมที่คุณต้องการนำไปใช้ รหัสการโทรจะต้องมีการเปลี่ยนแปลงเพื่อจัดการข้อผิดพลาดความขัดแย้งในการปรับปรุง

หลังจากนั้นSET READ_COMMITTED_SNAPSHOT ONข้อความสั่งที่อ่านแล้วจะใช้การกำหนดเวอร์ชันแถว หมายเหตุนี้เป็นระดับคำสั่งแถวเวอร์ชันสำหรับอ่านเท่านั้น สำหรับการอัปเดตแถว "ของจริง" จะถูกดึงออกมาและใช้การล็อคการอัปเดต ดูหัวข้อสรุปพฤติกรรมในการทำความเข้าใจระดับการแยกแถวตามเวอร์ชัน

ทั้งเส้นทางโดยไม่มีการทดสอบอย่างละเอียดคุณมีแนวโน้มที่จะแนะนำชุดของปัญหาใหม่ทั้งหมดให้กับระบบ

ฉันเชื่อว่าสิ่งนี้จะทำให้เรามีบางสิ่งที่ใกล้เคียงกับ oracle มากขึ้นหากว่ามีธุรกรรมหนึ่งธุรกรรมที่กำลังอัพเดทธุรกรรมอื่น ๆ ยังคงสามารถอ่านข้อมูลเก่าได้ ถูกต้องหรือไม่

ใช่ถูกต้องแล้ว

คุ้มค่าที่จะอ่านลิงก์ในคำตอบของ gbn และฉันเชื่อว่าเช่นเดียวกันกับ MVCC เริ่มต้นของ Oracle เช่นเดียวกับ SQL Server ในโหมด Snapshot Isolation ฉันจะเพิ่มว่าหากคุณเข้าใจถึงข้อผิดพลาดที่อาจเกิดขึ้น IMO ประโยชน์นั้นมีมากกว่าความยากลำบากที่เพิ่มขึ้น (พูดจากมุมมองของ Oracle) - และแน่นอนว่าปัญหาการล็อคบางอย่างหายไปอย่างถูกต้องนั่นคือประเด็นของ MVCC ปัญหาการล็อคที่จะไม่หายไปเนื่องจากปัญหารหัส แต่ฉันสมมติว่าคุณเข้าใจสิ่งนี้)

เรากำลังใช้ SNAPSHOT ISOLATION ในทุกโครงการของเราที่ใช้ SQL Server DB ไม่มีข้อผิดพลาดของ SQL มากกว่า 1205 ที่เกิดขึ้นไม่ใช่เพราะรหัสแอปพลิเคชันไม่ถูกต้อง แต่จากการล็อกหน้าเริ่มต้นและพฤติกรรมการล็อกแถว

ผลกระทบด้านประสิทธิภาพมีน้อยมากและผ่านมา 7 ปีแล้วการดำเนินการหลายร้อยล้านครั้งได้ถูกประมวลผลในระบบที่แตกต่างกันโดยไม่มีปัญหาเกี่ยวกับ SNAPSHOT ISOLATION

สถานการณ์ที่เธรดที่แตกต่างกันหลายตัวกำลังอัปเดตข้อมูลสำคัญทางธุรกิจในแถวเดียวในแนวขนานนั้นยอดเยี่ยมมากและโอกาสที่ SNAPSHOT ISOLATION จะเป็นสาเหตุของปัญหาความไม่สอดคล้องใด ๆ อยู่ใกล้กับศูนย์มาก

หากคุณมีระบบ OLTP นั่นเป็นการปรับปรุงการออกแบบแถวเดี่ยวตามข้อมูลแถวปัจจุบันในหลายเธรดแน่นอนว่า SNAPSHOTS จะไม่ได้รับการยอมรับในกรณีดังกล่าว

เรามีการใช้งานและคำสั่ง sql เลือกแปลกใช้ 4 เคยบล็อกฐานข้อมูลทั้งหมดไม่ว่าจะมีกี่แกนและทั้งหมด การตั้งค่า RCSI off คงที่ ฉันจะเปิดใช้งานเมื่อคุณเผชิญกับการหยุดชะงักอื่น ๆ ไม่ใช่โดยค่าเริ่มต้น