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

สถานการณ์ที่เกิดจากกระบวนการสองกระบวนการขึ้นไปที่ไม่สามารถดำเนินการได้ (และปล่อยการล็อก) เนื่องจากถูกบล็อกโดยการล็อกทรัพยากรที่กระบวนการอื่นถืออยู่

2
ฉันจะกำหนดค่า MySQL Innodb ให้จัดการกับเม็ดมีด 1000 ต่อชั่วโมงได้อย่างไร
ฉันมีเว็บไซต์ที่มีปริมาณการใช้งานสูงซึ่งเป็นไปได้ที่จะมีการแทรกระเบียนใหม่ 1,000 รายการทุกชั่วโมง ข้อผิดพลาดเดียวนี้ทำให้หมดอำนาจเว็บไซต์: PDOException: SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction: INSERT INTO {location_instance} (nid, vid, uid, genid, lid) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4); Array ( [:db_insert_placeholder_0] => 1059 [:db_insert_placeholder_1] => 1059 [:db_insert_placeholder_2] => 0 [:db_insert_placeholder_3] => cck:field_item_location:1059 [:db_insert_placeholder_4] => 1000 …

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

2
วิธีการป้องกัน Deadlocks ของคอลัมน์ที่แบ่งพาร์ติชันบน SELECT
ฉันมีตารางดัชนีคอลัมน์หลัก (CCI) สามตารางใน SQL Server 2016 CCI ทั้งหมดเหล่านี้อยู่ในรูปแบบการแบ่งพาร์ติชันเดียวกันโดยยึดตาม ID ผู้เช่า เมื่อเร็ว ๆ นี้และไม่สอดคล้องกันฉันได้รับการหยุดชะงักในงบเลือกง่าย ๆ จากการเข้าร่วมตารางเหล่านี้ ตัวอย่างแบบสอบถามที่ deadlocks: SELECT TOP 33 r.tenantid FROM Table_r r INNER JOIN Table_cm cm ON r.MyKey=cm.MyKey INNER JOIN Table_pe pe ON r.MyKey=pe.MyKey WHERE r.TenantId = 69 AND pe.TenantId = 69 AND cm.TenantId = 69 ข้อความผิดพลาด: ทรานแซคชัน …

1
MySQL InnoDB Deadlock สำหรับการสืบค้นง่ายๆ 2 แบบ
ฉันมีการหยุดชะงักสำหรับข้อความค้นหาแทรกสองรายการนี้: insert into PlayerClub (modifiedBy, timeCreated, currentClubId, endingLevelPosition, nextClubId, account_id) values (0, '2014-12-23 15:47:11.596', 180, 4, 181, 561) insert into PlayerClub (modifiedBy, timeCreated, currentClubId, endingLevelPosition, nextClubId, account_id) values (0, '2014-12-23 15:47:11.611', 180, 4, 181, 563) นี่คือสถานะ InnoDB: ------------------------ LATEST DETECTED DEADLOCK ------------------------ 2014-12-23 15:47:11 1f4c *** (1) TRANSACTION: TRANSACTION 19896526, …
10 mysql  innodb  deadlock 

2
SELECT / INSERT Deadlock
อินสแตนซ์นี้โฮสต์ฐานข้อมูล SharePoint 2007 (SP) เราประสบปัญหาการหยุดชะงัก SELECT / INSERT จำนวนมากต่อตารางที่ใช้งานหนักจำนวนหนึ่งในฐานข้อมูลเนื้อหา SP ฉัน จำกัด ทรัพยากรที่เกี่ยวข้องให้แคบลงกระบวนการทั้งสองต้องการล็อคในดัชนีที่ไม่ใช่คลัสเตอร์ INSERT ต้องการล็อค IX บนทรัพยากร SELECT และ SELECT ต้องการล็อค S บนทรัพยากร INSERT กราฟเดดล็อกแสดงให้เห็นและสามทรัพยากร 1. ) สองรายการจาก SELECT (เธรดขนานผู้ผลิต / ผู้บริโภค) และ 2) INSERT ฉันได้แนบกราฟการหยุดชะงักเพื่อตรวจสอบของคุณ เนื่องจากนี่คือรหัส Microsoft และโครงสร้างตารางเราไม่สามารถทำการเปลี่ยนแปลงใด ๆ อย่างไรก็ตามฉันได้อ่านบนเว็บไซต์ MSFT SP ว่าพวกเขาแนะนำให้ตั้งค่าตัวเลือกการกำหนดค่าระดับอินสแตนซ์ MAXDOP เป็น 1 เนื่องจากอินสแตนซ์นี้มีการใช้งานร่วมกันระหว่างฐานข้อมูล / แอปพลิเคชันอื่น …

1
“ * รหัสผ่าน ------------” หมายความว่าอย่างไรในรายงานการหยุดชะงักของโปรไฟล์
ใน SQL Server 2008 R2 ฉันได้รับรายงานการหยุดชะงักหลายครั้งที่มี "* รหัสผ่าน ------------" ในบัฟเฟอร์อินพุต ดูเหมือนว่าจะเป็นการโจมตี แต่ในกรณีนั้นฉันไม่รู้เหตุผลหรือชนิดของการโจมตี (บันทึกถูกสร้างขึ้นโดย DBA ผู้เชี่ยวชาญมีประสบการณ์มากมายและบอกฉันว่าไม่ใช่ฉัน) ไม่มีใครรู้ว่ามันคืออะไร? ขอบคุณ! ตัวอย่าง: <?xml version="1.0"?> <blocked-process> <process id="process879948" taskpriority="0" logused="0" waitresource="KEY: 5:72057602473263104 (1d69201d0ba6)" waittime="5185" ownerId="88389135" transactionname="SELECT" lasttranstarted="2012-09-25T18:11:02.507" XDES="0x1f7d2a590" lockMode="S" schedulerid="2" kpid="4552" status="suspended" spid="86" sbid="2" ecid="0" priority="0" trancount="0" lastbatchstarted="2012-09-25T18:11:02.507" lastbatchcompleted="2012-09-25T18:11:02.507" lastattention="2012-09-25T18:07:35.740" clientapp=".Net SqlClient Data Provider" hostname="IP-xxxxxxxx" …

1
กราฟ SQL Server Deadlock - ล็อคตารางหน้าหรือแถว?
มีวิธีการถอดรหัสถ้าล็อคในกราฟการหยุดชะงักเป็นระดับตารางหน้าหรือแถว? ฉันมีข้อมูลทั้งหมดที่ฉันต้องการจากกราฟรวมถึงระดับการแยก (2) แต่ฉันก็อยากรู้สิ่งนี้เช่นกัน ขอบคุณทุกคนที่สามารถช่วยได้!

1
เห็นได้ชัดว่าฟังก์ชั่นการประกอบ CLR ของฉันทำให้เกิดการหยุดชะงัก
แอปพลิเคชันของเราต้องทำงานอย่างเท่าเทียมกันกับฐานข้อมูล Oracle หรือฐานข้อมูล Microsoft SQL Server เพื่ออำนวยความสะดวกในเรื่องนี้เราได้สร้าง UDF จำนวนหนึ่งเพื่อทำให้ไวยากรณ์การสืบค้นของเราเป็นเนื้อเดียวกัน ตัวอย่างเช่น SQL Server มี GETDATE () และ Oracle มี SYSDATE พวกเขาทำหน้าที่เดียวกัน แต่เป็นคำที่ต่างกัน เราเขียน wrapper UDF ชื่อ NOW () สำหรับทั้งสองแพลตฟอร์มซึ่งล้อมรอบไวยากรณ์เฉพาะแพลตฟอร์มที่เกี่ยวข้องในชื่อฟังก์ชันทั่วไป เรามีฟังก์ชั่นอื่น ๆ ซึ่งบางส่วนไม่ทำอะไรเลย แต่มีอยู่เพียงเพื่อความเป็นเนื้อเดียวกัน น่าเสียดายที่ค่าใช้จ่ายนี้สำหรับ SQL Server UDF สเกลาร์แบบอินไลน์สร้างความหายนะต่อประสิทธิภาพและปิดการใช้งานความขนานอย่างสมบูรณ์ เป็นทางเลือกเราเขียนฟังก์ชันการประกอบ CLR เพื่อให้บรรลุเป้าหมายเดียวกัน เมื่อเราปรับใช้สิ่งนี้กับลูกค้าพวกเขาเริ่มประสบกับการหยุดชะงักบ่อยครั้ง ลูกค้ารายนี้ใช้การจำลองแบบและเทคนิคความพร้อมใช้งานสูงและฉันสงสัยว่ามีการโต้ตอบบางอย่างเกิดขึ้นที่นี่หรือไม่ ฉันไม่เข้าใจว่าการแนะนำฟังก์ชัน CLR จะทำให้เกิดปัญหาเช่นนี้ได้อย่างไร สำหรับการอ้างอิงฉันได้รวมข้อกำหนด UDF สเกลาร์ต้นฉบับไว้รวมถึงข้อกำหนดการแทนที่ CLR ใน …

1
เอาชนะการผสานเข้าร่วม (สแกนดัชนี) ด้วยค่าคีย์เดี่ยวอย่างชัดเจนบนคีย์ต่างประเทศ
เพิ่ม 7/11ปัญหานี้เกิดจากการหยุดชะงักเนื่องจากการสแกนดัชนีระหว่าง MERGE JOIN ในกรณีนี้ธุรกรรมที่พยายามรับ S lock ในดัชนีทั้งหมดที่ตารางหลัก FK แต่ก่อนหน้านี้ธุรกรรมอื่นวาง X lock ไว้ในค่าคีย์ของดัชนี ให้ฉันเริ่มต้นด้วยตัวอย่างเล็ก ๆ (ใช้ TSQL2012 DB จาก 70-461 cource): CREATE TABLE [Sales].[Orders]( [orderid] [int] IDENTITY(1,1) NOT NULL, [custid] [int] NULL, [empid] [int] NOT NULL, [shipperid] [int] NOT NULL, ... ) คอลัมน์[custid], [empid], [shipperid]เป็นพารามิเตอร์ที่มีการเชื่อมโยงกัน[Sales].[Customers], [HR].[Employees], [Sales].[Shippers]ตามลำดับ ในแต่ละกรณีเรามีดัชนีคลัสเตอร์ในคอลัมน์ที่อ้างถึงในตาราง parrent ALTER …

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 อัปเดตแถวในลำดับเดียวกันกับที่สแกนไปแล้วนี่เป็นวิธีการที่คุ้มค่าหรือไม่

3
ต้องการความช่วยเหลือในการแก้ไขปัญหาสถานการณ์การหยุดชะงักของ SQL Server 2005
ฉันกำลังทำงานในสถานการณ์การหยุดชะงักที่ผู้เข้าร่วมเพียงคนเดียวในการหยุดชะงักดูเหมือนจะเป็นตารางเดียวและขั้นตอนการจัดเก็บเดียวที่ถูกลบออกจากตารางนั้น ฉันดึงข้อสรุปนั้นจากการวิเคราะห์บันทึกข้อผิดพลาด sql ของฉันในช่วงเวลาของการหยุดชะงักหลายครั้งโดยใช้บทความ MSDN ด้านล่างเป็นแนวทางในการถอดรหัสการติดตามในบันทึกข้อผิดพลาด ตาราง DEXTable และขั้นตอนการจัดเก็บ ClearDEXTableRows มีการกำหนดไว้ด้านล่าง มีกระบวนงานที่เก็บไว้อีก InsertDEXTableRow ที่แทรกแถวลงใน DEXTable แต่ proc ที่ดูเหมือนจะไม่เกี่ยวข้องในการหยุดชะงักตามรายการในบันทึกข้อผิดพลาด sql DEXTable มีแถวที่อยู่ประมาณ 8.3 ล้านแถวและมีแนวโน้มที่จะเติบโตอย่างต่อเนื่อง ตารางผู้ตอบแบบสอบถามมีขนาดใหญ่และมีแนวโน้มที่จะเติบโตอย่างต่อเนื่อง มันเข้าถึงได้จากเว็บไซต์ปริมาณการใช้งานสูงที่มีหน้าเว็บที่เรียก ClearDEXTableRows และ InsertDEXTableRow บ่อย ๆ อย่างต่อเนื่อง การหยุดชะงักเกิดขึ้นระหว่าง 0 ถึง 9 ครั้งต่อวันในช่วง 10 วันที่ผ่านมา ฉันเปิดใช้งานการติดตาม sql สำหรับ 1222 (โดยใช้ DBCC TRACEON 1222) และเพิ่งเปิดใช้งานการตั้งค่าสถานะ 1204 มีคำอธิบายที่ดีเกี่ยวกับผลลัพธ์สำหรับการตั้งค่าสถานะเหล่านี้ในการตรวจจับและการสิ้นสุด Deadlocks …
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.