ธุรกรรมใน Fabric Data Warehouse

นําไปใช้กับ:✅ จุดสิ้นสุดการวิเคราะห์ SQL และ Warehouse ใน Microsoft Fabric

คล้ายกับลักษณะการทํางานของพวกเขาใน SQL Server ธุรกรรมช่วยให้คุณสามารถควบคุมการยอมรับหรือย้อนกลับของคิวรีที่อ่านและเขียนได้

Fabric Data Warehouse รองรับธุรกรรมที่สอดคล้องกับ ACID ธุรกรรมแต่ละรายการเป็นแบบอะตอม สอดคล้องกัน แยกได้ และทนทาน (ACID) การดําเนินการทั้งหมดภายในธุรกรรมเดียวจะได้รับการปฏิบัติแบบอะตอม ทั้งหมดสําเร็จหรือล้มเหลวทั้งหมด ถ้าใบแจ้งยอดใด ๆ ในธุรกรรมล้มเหลว ธุรกรรมทั้งหมดจะถูกย้อนกลับ

ธุรกรรมที่ชัดเจน

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

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

คุณสามารถใช้กลไกการควบคุมไวยากรณ์ T-SQL (BEGIN TRAN, COMMIT TRAN, และ ROLLBACK TRAN) มาตรฐานสําหรับธุรกรรมที่ชัดเจน สําหรับข้อมูลเพิ่มเติม ให้ดูที่:- เริ่ม - ธุรกรรมการย้อนกลับธุรกรรม - COMMIT

สนับสนุนทรานแซคชันแบบสอบถามข้ามฐานข้อมูล

คลังสินค้าใน Microsoft Fabric สนับสนุนธุรกรรมที่ครอบคลุมทั่วทั้งคลังสินค้าที่อยู่ภายในพื้นที่ทํางานเดียวกัน รวมถึงการอ่านจากจุดสิ้นสุดการวิเคราะห์ SQL ของ Lakehouse สําหรับตัวอย่าง โปรดดู การเขียนแบบสอบถาม SQL ข้ามฐานข้อมูล

ทําความเข้าใจการล็อกและการบล็อกใน Fabric Data Warehouse

Fabric Data Warehouse ใช้การล็อกระดับตาราง ไม่ว่าคิวรีจะสัมผัสกับแถวเดียวหรือหลายแถว ตารางต่อไปนี้แสดงรายการของล็อคที่ใช้สําหรับการดําเนินการ T-SQL ที่แตกต่างกัน

ชนิดคําสั่ง	ล็อคแล้ว
ดีเอ็มแอล
เลือก	Schema-Stability (Sch-S)
สอด	เจตนาพิเศษ (IX)
ลบ	เจตนาพิเศษ (IX)
อัพเดต	เจตนาพิเศษ (IX)
ควบ	เจตนาพิเศษ (IX)
คัดลอกไปยัง	เจตนาพิเศษ (IX)
ดีดีแอล
สร้างตาราง	Schema-Modification (Sch-M)
เปลี่ยนตาราง	Schema-Modification (Sch-M)
วางโต๊ะ	Schema-Modification (Sch-M)
ตารางตัดแต่ง	Schema-Modification (Sch-M)
สร้างตารางเป็นเลือก	Schema-Modification (Sch-M)
สร้างตารางเป็นโคลนของ	Schema-Modification (Sch-M)

คุณสามารถคิวรีล็อกที่เก็บไว้ใน sys.dm_tran_locks มุมมองการจัดการแบบไดนามิก (DMV) ในขณะนี้

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

การแยกสแนปช็อต

Fabric Data Warehouse บังคับใช้การแยกสแนปช็อตในธุรกรรมทั้งหมด การแยกสแนปช็อตเป็นระดับการแยกตามแถวที่ให้ความสอดคล้องระดับธุรกรรมสําหรับข้อมูล และใช้เวอร์ชันแถวที่จัดเก็บไว้เพื่อ tempdb เลือกแถวที่จะอัปเดต ธุรกรรมใช้รุ่นแถวข้อมูลที่มีอยู่เมื่อธุรกรรมเริ่มต้น สิ่งนี้ทําให้มั่นใจได้ว่าแต่ละธุรกรรมจะทํางานบนสแนปช็อตที่สอดคล้องกันของข้อมูลตามที่มีอยู่ในตอนเริ่มต้นของธุรกรรม

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

ถ้าคุณใช้ T-SQL เพื่อเปลี่ยนระดับการแยก การเปลี่ยนแปลงจะถูกละเว้นในเวลาที่ดําเนินการคิวรี และจะใช้การแยกสแนปช็อต

ในการแยกสแนปช็อต อาจมีข้อขัดแย้งในการเขียน-เขียน หรืออัปเดต สําหรับข้อมูลเพิ่มเติม โปรดดู ทําความเข้าใจข้อขัดแย้งในการเขียน-เขียนใน Fabric Data Warehouse

ล็อคสคีมา

การล็อก Schema ป้องกันความขัดแย้งในคําสั่ง DDL เช่น Schema ของตารางมีการเปลี่ยนแปลงในขณะที่แถวกําลังได้รับการอัปเดตในธุรกรรม โปรดทราบว่าการดําเนินการ DDL เช่น การเปลี่ยนแปลง Schema และการย้ายข้อมูล สามารถบล็อกหรือถูกบล็อกโดยปริมาณงานการอ่านที่ใช้งานอยู่

• ในระหว่างการดําเนินการภาษานิยามข้อมูล (DDL) กลไกจัดการฐานข้อมูลจะใช้การล็อกการแก้ไข schema (Sch-M) ในช่วงเวลาที่ถือ Sch-M ไว้ ล็อคจะป้องกันการเข้าถึงโต๊ะพร้อมกันทั้งหมดจนกว่าจะปลดล็อค
• ในระหว่างการดําเนินการภาษาการจัดการข้อมูล (DML) กลไกจัดการฐานข้อมูลจะใช้การล็อกความเสถียรของสคีมา (Sch-S) การดําเนินการที่ได้รับการ Sch-M ล็อคจะถูกบล็อกโดย Sch-S ล็อค ธุรกรรมอื่นๆ ยังคงทํางานต่อไปในขณะที่กําลังคอมไพล์แบบสอบถาม แต่การดําเนินการ DDL จะถูกบล็อกจนกว่าจะสามารถเข้าถึง Schema ได้
• การดําเนินการ DDL ยังได้รับการล็อก (X) พิเศษบนแถวในมุมมองระบบ เช่น sys.tables และ sys.objects เชื่อมโยงกับตารางเป้าหมาย ตลอดระยะเวลาของธุรกรรม สิ่งนี้จะบล็อกคําสั่งพร้อมกันSELECTบน sys.tables และsys.objects

แนวทางปฏิบัติแนะนําเพื่อหลีกเลี่ยงการบล็อก

• หลีกเลี่ยงการทําธุรกรรมที่ดําเนินไปเป็นเวลานาน หรือจัดกําหนดการในช่วงเวลาที่มีกิจกรรมพร้อมกันต่ําหรือไม่มีเลย
• กําหนดเวลาการดําเนินการ DDL เฉพาะในช่วงระยะเวลาการบํารุงรักษาเพื่อลดการบล็อก
• หลีกเลี่ยงการวางคําสั่ง DDL ภายในธุรกรรมของผู้ใช้ที่ชัดเจน (BEGIN TRAN) ธุรกรรมที่ทํางานเป็นเวลานานซึ่งแก้ไขตารางอาจทําให้เกิดปัญหาการบล็อกสําหรับการดําเนินการและ SELECT แบบสอบถาม DML อื่นๆ ทั้งบนตารางผู้ใช้และมุมมองแค็ตตาล็อกระบบ เช่น sys.tables. เมื่อต้องการตรวจสอบและแก้ไขปัญหาความขัดแย้งในการล็อกที่อาจเกิดขึ้น ให้ใช้sys.dm_tran_locks
• ตรวจสอบการล็อกและความขัดแย้งในคลังสินค้า
  • ใช้ sys.dm_tran_locks เพื่อตรวจสอบล็อคปัจจุบัน
• Fabric Data Warehouse สนับสนุนคําสั่ง DDL บางอย่างภายในธุรกรรมที่ผู้ใช้กําหนด แต่ไม่แนะนําในธุรกรรมที่ทํางานเป็นเวลานาน ภายในธุรกรรม คําสั่ง DDL สามารถบล็อกธุรกรรมที่เกิดขึ้นพร้อมกันหรือทําให้เกิดความขัดแย้งในการเขียน-เขียน

ทําความเข้าใจข้อขัดแย้งในการเขียน-เขียนใน Fabric Data Warehouse

ความขัดแย้งในการเขียน-เขียนอาจเกิดขึ้นได้เมื่อธุรกรรมสองรายการพยายาม UPDATE, DELETE, MERGE, หรือ TRUNCATE ตารางเดียวกัน

ข้อขัดแย้งในการเขียน-เขียนหรือข้อขัดแย้งในการอัปเดตเป็นไปได้ที่ระดับตาราง เนื่องจาก Fabric Data Warehouse ใช้การล็อกระดับตาราง ถ้าธุรกรรมสองรายการพยายามปรับเปลี่ยนแถวที่ต่างกันในตารางเดียวกัน ธุรกรรมเหล่านั้นยังคงสามารถขัดแย้งกันได้

ความขัดแย้งในการเขียน-เขียนส่วนใหญ่เกิดขึ้นจากสองสถานการณ์:

• ความขัดแย้งของปริมาณงานที่เกิดจากผู้ใช้
  • ผู้ใช้หรือกระบวนการหลายคนปรับเปลี่ยนตารางเดียวกันพร้อมกัน
  • อาจเกิดขึ้นในไปป์ไลน์ ETL การอัปเดตชุดงาน หรือธุรกรรมที่ทับซ้อนกัน
• ความขัดแย้งที่เกิดจากระบบ
  • งานระบบพื้นหลัง เช่น การบดอัดข้อมูลอัตโนมัติ เขียนไฟล์ใหม่ที่มีคุณภาพต่ํา
  • สิ่งเหล่านี้อาจขัดแย้งกับธุรกรรมของผู้ใช้ แม้ว่าการ บดอัดข้อมูลล่วงหน้า จะป้องกันความขัดแย้งในการเขียน-เขียนชนิดนี้อย่างแข็งขัน

หากเกิดข้อขัดแย้งระหว่างการเขียนและเขียน คุณอาจเห็นข้อความแสดงข้อผิดพลาด เช่น

• ข้อผิดพลาด 24556: ธุรกรรมการแยกสแนปช็อตถูกยกเลิกเนื่องจากความขัดแย้งในการปรับปรุง การใช้การแยกสแนปช็อตเพื่อเข้าถึงตาราง '%.*ls' โดยตรงหรือโดยอ้อมในฐานข้อมูล '%.*ls' อาจทําให้เกิดข้อขัดแย้งในการอัปเดตหากแถวในตารางนั้นถูกลบหรือปรับปรุงโดยธุรกรรมที่เกิดขึ้นพร้อมกันอื่น ลองทําธุรกรรมอีกครั้ง
• ข้อผิดพลาด 24706: ธุรกรรมการแยกสแนปช็อตถูกยกเลิกเนื่องจากความขัดแย้งในการปรับปรุง คุณไม่สามารถใช้การแยกสแน็ปช็อตเพื่อเข้าถึงตาราง '%.*ls' โดยตรงหรือโดยอ้อมในฐานข้อมูล '%.*ls' เพื่อปรับปรุง ลบ หรือแทรกแถวที่ถูกแก้ไขหรือลบโดยธุรกรรมอื่น โปรดลองทําธุรกรรมอีกครั้ง

หากคุณพบข้อความแสดงข้อผิดพลาดเหล่านี้ แสดงว่าธุรกรรมอย่างน้อยหนึ่งรายการสําเร็จ และธุรกรรมที่ขัดแย้งกันอย่างน้อยหนึ่งรายการล้มเหลว ลองทําธุรกรรมที่ล้มเหลวอีกครั้ง

Note

แม้ว่า MERGE ธุรกรรมจะส่งผลให้เกิดการเปลี่ยนแปลงแบบผนวกเท่านั้น แต่ก็ยังคงสร้างข้อขัดแย้งในการเขียน-เขียน เมื่อ MERGE ธุรกรรมมีผลต่อแถวที่แตกต่างจากธุรกรรม DML ที่เกิดขึ้นพร้อมกันอื่น ๆ อาจพบข้อผิดพลาดนี้หาก MERGE ไม่ใช่ธุรกรรมแรกที่ยอมรับ: 'ธุรกรรมการแยกสแนปช็อตถูกยกเลิกเนื่องจากความขัดแย้งในการอัปเดต'

แนวทางปฏิบัติที่ดีที่สุดในการหลีกเลี่ยงความขัดแย้งระหว่างการเขียนและการเขียน

วิธีหลีกเลี่ยงความขัดแย้งระหว่างการเขียนและเขียน

• หลีกเลี่ยงการ UPDATEดําเนินการ , DELETE, พร้อมกัน MERGE บนตารางเดียวกัน
  • ให้ความสนใจอย่างระมัดระวังกับUPDATEการดําเนินการDELETEMERGEภายในธุรกรรมหลายขั้นตอน
• ใช้ตรรกะลองใหม่ในแอปพลิเคชันและคิวรีทั้งหมด
  • ใช้ตรรกะการลองใหม่ในกระบวนงานที่เก็บไว้และไปป์ไลน์ ETL
  • เพิ่มตรรกะการลองใหม่ที่มีความล่าช้าในไปป์ไลน์หรือแอปเพื่อจัดการกับข้อขัดแย้งชั่วคราว
    • ใช้การแบ็คออฟแบบเอ็กซ์โพเนนเชียลเพื่อหลีกเลี่ยงพายุลองใหม่ที่ทําให้การหยุดชะงักของเครือข่ายชั่วคราวแย่ลง สําหรับข้อมูลเพิ่มเติม โปรดดู รูปแบบการลองใหม่
• ข้อขัดแย้งในการเขียน-เขียนกับบริการการบดอัดข้อมูลเบื้องหลังของ Fabric Data Warehouse เป็นไปได้ แต่โดยทั่วไปจะถูกป้องกันโดยคุณลักษณะ การบดอัดข้อมูลล่วงหน้า

การบล็อกตะไบโต๊ะและไม้ปาร์เก้

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

คําสั่ง INSERT จะสร้างไฟล์ parquet ใหม่เสมอ ซึ่งหมายความว่าความขัดแย้งกับธุรกรรมอื่นน้อยลง ยกเว้น DDL เนื่องจากอาจเปลี่ยนแปลง Schema ของตาราง

ข้อจำกัด

• ไม่รองรับธุรกรรมแบบกระจาย เช่น BEGIN DISTRIBUTED TRANSACTION.
• ALTER TABLE ไม่ได้รับการสนับสนุนภายในธุรกรรมที่ชัดเจน
• ไม่สนับสนุนจุดบันทึก
• ไม่สนับสนุนธุรกรรมที่มีชื่อ
• ธุรกรรมที่ทําเครื่องหมายไม่ได้รับการสนับสนุน
• ในขณะนี้ มีฟังก์ชัน T-SQL แบบจํากัดในคลังสินค้า ดู พื้นที่ผิว T-SQL ใน Fabric Data Warehouse สําหรับรายการคําสั่ง T-SQL ที่ไม่พร้อมใช้งานในขณะนี้
• ถ้าทรานแซคชันมีการแทรกข้อมูลลงในตารางที่ว่างเปล่าและออก SELECT ก่อนย้อนกลับ สถิติที่สร้างขึ้นโดยอัตโนมัติจะยังคงแสดงข้อมูลที่ไม่ได้ผูกมัด ซึ่งก่อให้เกิดสถิติที่ไม่ถูกต้อง สถิติที่ไม่ถูกต้องอาจนําไปสู่แผนคิวรีที่ไม่ได้เปลี่ยนแปลงและเวลาการดําเนินการ ถ้าคุณย้อนกลับธุรกรรมด้วย SELECTs หลังจากการแทรกขนาดใหญ่ อัปเดต สถิติ สําหรับคอลัมน์ที่ระบุใน SELECT ของคุณ

เนื้อหาที่เกี่ยวข้อง

• คิวรีจุดสิ้นสุดการวิเคราะห์ SQL หรือ Warehouse ใน Microsoft Fabric
• ตาราง