การเปรียบเทียบ Schema SSDT ไม่ทำงานในขณะที่ BULK INSERT กำลังดำเนินการอยู่

ฉันกำลังทำงานในโครงการ ETL และ DW ขนาดใหญ่ที่เราใช้ TFS / แหล่งควบคุมร่วมกับทั้ง SSIS และ SSDT

วันนี้ฉันค้นพบว่าในขณะที่แพคเกจ SSIS กำลังทำ BULK INSERT ในตารางฐานข้อมูลเป็นไปไม่ได้ที่จะทำการเปรียบเทียบ SSDT Schema กับฐานข้อมูลนั้น นี่เป็นสิ่งที่โชคไม่ดีเนื่องจากแพ็คเกจบางรายการของเราใช้เวลาค่อนข้างนานในการดำเนินการให้เสร็จสมบูรณ์ เราต้องการใช้ฟังก์ชั่น Schema Compare เพื่อตรวจจับการเปลี่ยนแปลงโครงสร้างฐานข้อมูลเพื่อบันทึกไว้ในโครงการ SSDT ของเราสำหรับการควบคุมเวอร์ชันของฐานข้อมูล

เมื่อดูเพิ่มเติมเล็กน้อยฉันพบว่าฟังก์ชัน Schema Compare ใน SSDT เรียกใช้งานสคริปต์ SQL ที่เรียกใช้OBJECTPROPERTY()ฟังก์ชันระบบบนตารางในฐานข้อมูล โดยเฉพาะอย่างยิ่งในกรณีของฉันการโทรใด ๆ ที่OBJECTPROPERTY(<object_id>, N'IsEncrypted')ดูเหมือนว่าจะถูกบล็อกเมื่อ<object_id>อ้างถึงตารางที่กำลังถูกแทรกจำนวนมากในปัจจุบัน

ใน Visual Studio นั้น SSDT Schema เปรียบเทียบจะหมดเวลาเพียงครู่เดียวและอ้างว่าไม่มีการตรวจพบความแตกต่าง

มีวิธีแก้ไขปัญหานี้ใน SSDT หรือฉันควรลองรายงานข้อผิดพลาด MS Connect หรือไม่

อีกทางหนึ่งเนื่องจาก BULK INSERT เกิดขึ้นจากแพ็คเกจ SSIS อาจมีวิธีใดวิธีหนึ่งในการแทรกโดยไม่ต้องล็อคOBJECTPROPERTY-calls บนโต๊ะ? แก้ไข:ใน SSIS OLE DB Destinations เราสามารถลบเครื่องหมายถูกออกจาก "Lock Table" ซึ่งทำตามที่ระบุไว้ แต่สิ่งนี้อาจส่งผลกระทบต่อประสิทธิภาพการทำงานในบางสถานการณ์ ฉันสนใจโซลูชันที่ช่วยให้ SSDT Schema เปรียบเทียบทำงานได้มากขึ้นแม้ว่าวัตถุบางอย่างจะถูกล็อค

sql-server ssis ssdt

— แดน
แหล่งที่มา

ดูที่การควบคุมพฤติกรรมการล็อคสำหรับการนำเข้าจำนวนมาก - คุณอาจเปิดใช้งาน 'การล็อคตารางสำหรับการโหลดจำนวนมาก' นอกจากนี้ตรวจสอบแทรกกลุ่มของคุณไม่ได้ระบุTABLOCK

— stuartd

หากคุณกำลังล็อคตารางคุณอาจพบว่าโหลดเร็วขึ้นถ้าคุณปิดการใช้งานอยู่ดี ( technet.microsoft.com/en-us/library/ms177445.aspx ) - ไม่ว่าสาเหตุใดที่ฉันจะเพิ่มการเชื่อมต่อเพราะการหมดเวลาควรอยู่ที่ ล้มเหลวน้อยที่สุดแทนที่จะพูดเพียงว่าไม่มีการเปลี่ยนแปลง

— เอ็ดเอลเลียต

ขอบคุณสำหรับการตอบกลับ stuartd และ Ed Elliot ปรากฎว่าเราต้องการล็อคตารางด้วยเหตุผลด้านประสิทธิภาพ ในความคิดของฉัน SSDT ควรสามารถจัดการกับสิ่งนี้ได้เพราะเราต้องการเปรียบเทียบฐานข้อมูลเท่านั้นไม่ใช้การเปลี่ยนแปลงกับวัตถุในฐานข้อมูล ฉันจะสร้างโพสต์เชื่อมต่อเพื่อแก้ไขปัญหานี้

— ด่าน

Internals ไม่ใช่มือขวาของฉัน แต่อย่างที่ฉันเข้าใจคุณมีล็อคอยู่บนโต๊ะ อะไรก็ตามที่นำมาล็อคนั้นมีไว้สำหรับการแทรกจำนวนมากไม่สามารถใช้ร่วมกับการล็อคที่จำเป็นในการตรวจสอบสคีมา การอ่านที่เกี่ยวข้องล็อค BOL Schema

— billinkc

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

— billinkc

การOBJECTPROPERTYโทรต้องใช้การล็อค schema เสถียรภาพ (Sch-S) ซึ่งเข้ากันไม่ได้กับล็อคการปรับเปลี่ยน schema (Sch-M) เท่านั้น

BULK INSERTจะใช้ล็อค SCH-M ในบางสถานการณ์ สิ่งเหล่านี้แสดงอยู่ในส่วน "การล็อกและการบันทึกตารางระหว่างการนำเข้าจำนวนมาก" ของหลักเกณฑ์สำหรับการปรับการนำเข้าจำนวนมากในหนังสือออนไลน์:

ล็อคการนำเข้าจำนวนมาก

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

ฉันไม่รู้ว่าทำไม SSDT ตรวจสอบIsEncryptedคุณสมบัติของตาราง ฉันไม่สามารถจินตนาการถึงสถานการณ์ที่เหมาะสม แต่เป็นคำถามสำหรับคน SSDT

— พอลไวท์ 9
แหล่งที่มา

นี่เป็นคำตอบที่ครอบคลุมและน่าพอใจมาก ขอบคุณมาก.

— ด่าน