คำถามติดแท็ก locking

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

2
MySQL ล็อคขณะสร้างตารางตามที่เลือก
ฉันกำลังเรียกใช้แบบสอบถาม (จำลอง) ต่อไปนี้ CREATE TABLE large_temp_table AS SELECT a.*, b.*, c.* FROM a LEFT JOIN b ON a.foo = b.foo LEFT JOIN c ON a.bar = c.bar สมมติว่าแบบสอบถามใช้เวลา 10 นาทีในการเรียกใช้ การพยายามอัปเดตค่าในตาราง a, b หรือ c ในขณะที่มันกำลังทำงานอยู่จะรอให้คิวรีด้านบนทำงานให้เสร็จก่อน ฉันต้องการหลีกเลี่ยงการล็อคนี้ (ความสอดคล้องของข้อมูลไม่เป็นที่สนใจ) ฉันจะบรรลุสิ่งนั้นได้อย่างไร การใช้: MySQL 5.1.41 และตาราง InnoDB ps ชุดแยกธุรกรรมระดับการอ่านไม่ได้รับอนุญาต; ไม่มีการเปลี่ยนแปลงในพฤติกรรม อัปเดต ในขณะที่กำลังดำเนินการค้นหาผลลัพธ์ของ SHOW …
10 mysql  locking  ctas 

2
SQL Server กำหนดลำดับการล็อคในขณะที่เลือกตารางได้อย่างไร
ฉันมีสองโพรซีเดอร์ที่เก็บไว้ซึ่งหยุดชะงักเมื่อระบบอยู่ระหว่างการโหลด Proc A กำลังเลือกจากตารางในขณะที่ Proc B กำลังแทรกลงในตารางเดียวกัน กราฟล็อคแสดงว่า Proc A มีการล็อกหน้าโหมด S ที่ Proc B ต้องการล็อคโหมด IX สำหรับ Proc A อย่างไรก็ตามกำลังรอการล็อกหน้าโหมด S สำหรับหน้าอื่นที่ Proc B มีการล็อกหน้าโหมด IX แล้ว . เห็นได้ชัดว่าสามารถแยกออกได้ด้วยการทำให้แน่ใจว่าทั้งคิวรีล็อคหน้าในตารางในลำดับเดียวกัน แต่ฉันไม่สามารถหาวิธีที่จะทำ คำถามของฉันคือSQL Server จะกำหนดลำดับที่จะล็อคหน้าในขณะที่ทำ INSERTs และ SELECT และวิธีที่คุณสามารถปรับเปลี่ยนพฤติกรรมนี้ได้อย่างไร

1
ไม่สามารถสแกนด้วย NOLOCK ต่อเนื่องจากการเคลื่อนไหวของข้อมูล
เราเรียกใช้ SQL Server 2000 และเราได้รับข้อผิดพลาดเล็กน้อยทุกคืน Could not continue scan with NOLOCK due to data movement แบบสอบถามที่ส่งข้อผิดพลาดนี้เป็นแบบสอบถามที่ซับซ้อนขนาดใหญ่ที่รวมอยู่เหนือตารางโหล ข้อมูลพื้นฐานของเราสามารถอัปเดตบ่อยครั้ง 'การปฏิบัติที่ดีที่สุด' ทางวัฒนธรรมคือในอดีตการแนะนำของNOLOCKคำแนะนำที่เพิ่มประสิทธิภาพและการปรับปรุงพร้อมกัน แบบสอบถามนี้ไม่จำเป็นต้องมีความแม่นยำ 100% เช่นเราจะทนต่อการอ่านที่สกปรก ฯลฯ อย่างไรก็ตามเราพยายามที่จะเข้าใจว่าเหตุใดฐานข้อมูลจึงโยนข้อผิดพลาดนี้ถึงแม้ว่าเราจะมีคำแนะนำการล็อคเหล่านี้ทั้งหมด ทุกคนสามารถให้ความกระจ่างเกี่ยวกับเรื่องนี้ - อ่อนโยนฉันเป็นโปรแกรมเมอร์ไม่ใช่ DBA :) PS: เราได้ใช้การแก้ไขที่กล่าวถึงด้านล่างก่อนหน้านี้: http://support.microsoft.com/kb/815008

2
Shared Lock ออกเมื่อ IsolationLevel.ReadUncommitted
ฉันอ่านว่าถ้าฉันใช้ IsolationLevel.ReadUncommitted แบบสอบถามไม่ควรออกล็อคใด ๆ อย่างไรก็ตามเมื่อฉันทดสอบสิ่งนี้ฉันเห็นล็อคต่อไปนี้: Resource_Type: HOBT Request_Mode: S (แชร์แล้ว) ล็อค HOBT คืออะไร มีอะไรเกี่ยวข้องกับ HBT (ฮีปหรือล็อคแบบทรีไบนารี) ทำไมฉันยังคงได้ล็อค S ฉันจะหลีกเลี่ยงการล็อคที่ใช้ร่วมกันได้อย่างไรเมื่อทำการสอบถามโดยไม่เปิดตัวเลือกสแนปชอตระดับการแยก ฉันกำลังทดสอบสิ่งนี้ใน SQLServer 2008 และตัวเลือกสแนปชอตตั้งเป็นปิด แบบสอบถามจะทำการเลือกเท่านั้น ฉันเห็นว่าจำเป็นต้องใช้ Sch-S แม้ว่า SQL Server จะไม่แสดงในแบบสอบถามที่ล็อคอยู่ ทำไมมันถึงยังมีการล็อคที่ใช้ร่วมกันอยู่? ตาม: ระดับการแยกธุรกรรม SET (Transact-SQL) ธุรกรรมที่รันที่READ UNCOMMITTEDระดับจะไม่ออกการล็อกที่ใช้ร่วมกันเพื่อป้องกันไม่ให้ธุรกรรมอื่นแก้ไขข้อมูลที่อ่านโดยธุรกรรมปัจจุบัน ดังนั้นฉันสับสนเล็กน้อย

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

2
จะปลอดภัยไหมที่จะยกเลิกการสืบค้น PostgreSQL ALTER TABLE ที่รอการล็อก?
เราเริ่มALTER TABLEคำถามเมื่อหลายชั่วโมงก่อนและเพิ่งรู้ว่าเพิ่งผ่านpg_stat_activityการล็อค เราค้นพบแบบสอบถามอื่น ๆ ที่ถือล็อคบนตารางที่เราต้องการแก้ไขและไม่ปล่อยให้มันไป แบบสอบถามของเราคือแบบสอบถามแบบ "ง่าย" (การเปลี่ยนชนิดข้อมูลคอลัมน์) แต่กำลังทำงานบนตารางขนาดใหญ่ ALTER TABLEแทนที่จะฆ่ากระบวนการที่จะถือไว้ล็อคเราได้ตัดสินใจว่าเราอยากจะฆ่า เราไม่ได้ห่อALTER TABLEในการทำธุรกรรม เท่าที่ฉันเข้าใจความจริงที่ว่าแบบสอบถามของเรากำลังรอการล็อกหมายความว่ามันกำลังรอการล็อคอยู่เสมอและมันไม่เคยเปลี่ยนแปลงอะไรเลย มันเป็นเรื่องจริงเหรอ? ปลอดภัยALTER TABLEหรือไม่ที่เราจะยกเลิกการสอบถามของเราทันที หรือเป็นไปได้ว่าแบบสอบถามได้แก้ไขบางสิ่งบางอย่างแล้วและการยกเลิกจะทำให้ฐานข้อมูลของเราอยู่ในสถานะกึ่งกลางหรือไม่ PS: SELECT pg_cancel_backend(pid);แผนคือการยกเลิกการใช้ หากนี่เป็นความคิดที่ไม่ดีโปรดแจ้งให้เราทราบ

1
วิธีสอบถามและเพิ่มมูลค่า (ตัวนับ) ในวิธีที่ปลอดภัยต่อเธรด (หลีกเลี่ยงสภาพการแข่งขัน)
ในตารางที่แต่ละแถวมีเคาน์เตอร์ (เพียงค่าจำนวนเต็ม) ผมจำเป็นต้องได้รับค่าปัจจุบันและเพิ่มขึ้นในเวลาเดียวกัน อย่างมีประสิทธิภาพฉันต้องการทำสิ่งนี้: SELECT counter FROM table WHERE id=123 UPDATE table SET counter=counter+1 WHERE id=123 แต่การทำเช่นนี้เนื่องจากเคียวรีสองรายการนั้นไม่ปลอดภัยสำหรับเธรด: หลายกระบวนการที่ทำสิ่งเดียวกัน (ในแถวเดียวกัน) อาจได้รับค่าตัวนับเดียวกัน ฉันต้องการให้ทุกอย่างไม่ซ้ำกันดังนั้นแต่ละกระบวนการจะได้รับมูลค่าปัจจุบันตามจริงและเพิ่มขึ้นทีละรายการ ฉันสามารถนึกถึงการก่อสร้างที่ฉันใช้การล็อกแบบแมนนวลต่อแถว แต่ฉันสงสัยว่าจะมีวิธีที่ง่ายกว่านี้หรือไม่
10 mysql  locking 

1
เซสชันที่ถูกบล็อกรอด้วย PAGELATCH_ * รอประเภทหรือไม่
แก้ไข: เหตุใดการรายงานเซสชันถูกบล็อก แต่รอด้วยPAGELATCH_*และไม่LCK_M_เกี่ยวข้องกับประเภทการรอ ก่อนหน้านี้ฉันสันนิษฐานว่าเซิร์ฟเวอร์ SQL จะรายงานเฉพาะเซสชันการบล็อกในคอลัมน์บล็อค_session_Idเท่านั้น PAGELATCH_*หากการประชุมที่ถูกบล็อกกำลังรอล็อคตรรกะและไม่ได้อะไรอย่างอื่นเช่น

1
การปรับปรุงการอัพเดทพร้อมกันใน Postgres
ฉันใช้คำสั่ง Postgres พร้อมกันเช่นนี้: UPDATE foo SET bar = bar + 1 WHERE baz = 1234 แบบสอบถามแต่ละรายการมีผลต่อจำนวน K แถวคงที่และฉันไม่สามารถหาวิธีบังคับใช้ลำดับที่แถวนั้นได้รับการอัปเดตได้ฉันจะสิ้นสุดด้วยการหยุดชะงัก ขณะนี้ฉันแก้ไขปัญหาด้วยการบังคับใช้คำสั่งซื้อด้วยตนเอง แต่นั่นหมายความว่าฉันต้องดำเนินการค้นหามากกว่าที่ฉันต้องการในขณะที่เพิ่มความซับซ้อนในการค้นหาจาก O (log N + K) เป็น O (K log N) มีวิธีการปรับปรุงประสิทธิภาพโดยไม่สิ้นสุดความเสี่ยงต่อการหยุดชะงักหรือไม่? ฉันสงสัยว่าการแทนที่(baz)ดัชนีด้วย(baz, id)ดัชนีอาจทำงานได้หาก Postgres อัปเดตแถวในลำดับเดียวกันกับที่สแกนไปแล้วนี่เป็นวิธีการที่คุ้มค่าหรือไม่

5
เหตุใดการล็อกในแง่ดีจึงเร็วกว่าการล็อกในแง่ร้าย
การล็อกทั้งสองรูปแบบทำให้กระบวนการรอสำเนาบันทึกที่ถูกต้องหากกระบวนการอื่นกำลังใช้งานอยู่ กลไกล็อคนั้นมาจากฐานข้อมูล DB (วัตถุล็อคพื้นเมือง) ในขณะที่การล็อคในแง่ดีกลไกการล็อคเป็นรูปแบบของการกำหนดเวอร์ชันของแถวเหมือนเวลาประทับเพื่อตรวจสอบว่าบันทึกนั้นเป็น "เก่า" หรือไม่ แต่ทั้งคู่ทำให้กระบวนการที่ 2 หยุดทำงาน ดังนั้นฉันจึงถามว่า: ทำไมการล็อคแง่ดีโดยทั่วไปถือว่าเร็วกว่าการล็อคในแง่ร้าย และมีกรณีการใช้งานที่ต้องการมองโลกในแง่ร้ายมากกว่าแง่ดีหรือไม่? ขอบคุณล่วงหน้า!

3
SSRS ล็อคตารางเมื่อทำการสอบถามหรือไม่?
DBA อาวุโสของฉันบอกฉันว่าการประมวลผลแบบสอบถาม SQL โดยค่าเริ่มต้นจะไม่ล็อคตาราง ฉันมีปัญหาบางอย่างกับรายงาน SQL Server Reporting Services (SSRS) ซึ่งดูเหมือนว่าจะมีปัญหาในการล็อคและรับข้อผิดพลาด ฉันทำ Googling แล้ว แต่หาอะไรไม่เจอ รายงาน SSRS ล็อคตารางที่กำลังสอบถามอยู่หรือไม่? มีเอกสาร MSDN ใดที่บันทึกพฤติกรรมนี้โดยเฉพาะ?

3
วิธีแก้ปัญหา enq: TX - การช่วงชิงล็อกการล็อกแถว
ฉันมีสถานการณ์ต่อไปนี้ ฉันมี RAC บนโหนดทั้งสองมีการล็อคอยู่ บนโหนดแรก SID EVENT USERNAME BLOCKING_SESSION ROW_WAIT_OBJ# OBJECT_NAME LOCKWAIT SQL_ID STATUS 1 102 enq: TX - row lock contention MYUSER 155 136972 TABLE1V 0000000810EFA958 5f4bzdg49fdxq ACTIVE 2 111 enq: TX - row lock contention MYUSER 155 136972 TABLE1V 0000000810EFAC98 5f4bzdg49fdxq ACTIVE การปิดกั้นข้อมูลเซสชั่น SID EVENT USERNAME ROW_WAIT_OBJ# OBJECT_NAME …

2
หมดเวลาธุรกรรม SQL Server
มีวิธีใดใน SQL Server 2008 R2 ที่จะทำให้เกิดการหมดเวลาสำหรับการปรับเปลี่ยนฐานข้อมูลที่เกี่ยวข้องกับการทำธุรกรรมหรือไม่? เรามีสถานการณ์ที่รหัสแอปพลิเคชันของเราแฮงค์หรือส่งข้อยกเว้นและไม่สามารถย้อนกลับหรือคอมมิท นี่เป็นสาเหตุให้เซสชันอื่นหยุดทำงานเพื่อรอธุรกรรมให้เสร็จสมบูรณ์

3
SQL Server - ระดับการแยกใดสำหรับคำสั่ง select ที่ไม่ได้บล็อก?
ฉันมีธุรกรรมที่ใช้เวลานาน (เรียกว่า, T1) ที่ดำเนินการลบปรับปรุงและแทรกบางอย่างในตารางใน SQL Server 2008 R2 ในเวลาเดียวกันกระบวนการอื่นเรียกใช้คำสั่งที่เลือกจากตารางนี้เป็นระยะ ภายใต้การตั้งค่าการแยกเริ่มต้น (READ COMMITTED ฉันคิดว่า?) T1 จะบล็อกคำสั่งที่เลือกไม่ให้ทำงานจนกว่าธุรกรรมจะทำหน้าที่หรือย้อนกลับ สิ่งที่ฉันต้องการเห็นคือคำสั่ง select เพื่อทำงานกับข้อมูลที่สอดคล้องกันแม้ในขณะที่ธุรกรรมกำลังดำเนินการอยู่ ฉันเชื่อว่าการแยก SNAPSHOT สามารถช่วยได้ แต่ไม่แน่ใจว่าฉันไปในทิศทางที่ถูกต้องหรือไม่ นี่จะเป็นระดับการแยกที่ดีที่สุดสำหรับแอปพลิเคชันนี้หรือไม่ ประการที่สองฉันไม่มีการควบคุมกระบวนการที่เรียกใช้คำสั่ง select แต่ฉันมีการควบคุมแอปพลิเคชัน. NET ที่เรียก T1 การเปลี่ยนแปลงระดับการแยกใด ๆ จะต้องการทั้งข้อความสั่งการเลือกและ T1 หรือว่าจะเพียงพอที่จะทำเครื่องหมายว่า T1 มีระดับการแยกต่างกันหรือไม่
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.