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

สำหรับคำถามเกี่ยวกับปัญหาที่เกิดขึ้นเมื่อผู้ใช้หลายคนหรือดำเนินการพร้อมกันเข้าถึงหรือแก้ไขข้อมูลที่แชร์ในระบบฐานข้อมูล

1
เลื่อนระดับอัปเดต… จำกัด 1
ฉันมีฐานข้อมูล Postgres ซึ่งมีรายละเอียดเกี่ยวกับกลุ่มของเซิร์ฟเวอร์เช่นสถานะเซิร์ฟเวอร์ ('ใช้งาน', 'สแตนด์บาย' ฯลฯ ) เซิร์ฟเวอร์ที่ใช้งานอยู่ตลอดเวลาอาจจำเป็นต้องล้มเหลวในการสแตนด์บายและฉันไม่สนใจว่าจะใช้สแตนด์บายใดเป็นพิเศษ ฉันต้องการคิวรีฐานข้อมูลเพื่อเปลี่ยนสถานะของสแตนด์บาย - เพียงแค่หนึ่ง - และส่งคืน IP ของเซิร์ฟเวอร์ที่จะใช้ การเลือกสามารถโดยพลการ: เนื่องจากสถานะของเซิร์ฟเวอร์เปลี่ยนแปลงด้วยแบบสอบถามจึงไม่สำคัญว่าจะเลือกสแตนด์บายใด เป็นไปได้หรือไม่ที่จะ จำกัด คิวรีของฉันให้อัปเดตเดียว นี่คือสิ่งที่ฉันมี: UPDATE server_info SET status = 'active' WHERE status = 'standby' [[LIMIT 1???]] RETURNING server_ip; Postgres ไม่ชอบสิ่งนี้ ฉันจะทำอะไรที่แตกต่างกัน

5
ปัญหาการล็อคด้วย DELETE / INSERT พร้อมกันใน PostgreSQL
มันค่อนข้างง่าย แต่ฉันก็งงกับสิ่งที่ PG ทำ (v9.0) เราเริ่มต้นด้วยตารางง่ายๆ CREATE TABLE test (id INT PRIMARY KEY); และไม่กี่แถว: INSERT INTO TEST VALUES (1); INSERT INTO TEST VALUES (2); การใช้เครื่องมือสืบค้น JDBC ที่ฉันโปรดปราน (ExecuteQuery) ฉันเชื่อมต่อหน้าต่างสองเซสชันเข้ากับฐานข้อมูลที่ตารางนี้ใช้งานอยู่ ทั้งคู่เป็นธุรกรรม (เช่น auto-commit = false) ลองเรียกพวกมันว่า S1 และ S2 รหัสเดียวกันสำหรับแต่ละ: 1:DELETE FROM test WHERE id=1; 2:INSERT INTO test VALUES (1); 3:COMMIT; …

4
คุณจะทดสอบเงื่อนไขการแข่งขันในฐานข้อมูลได้อย่างไร
ฉันพยายามเขียนรหัสฐานข้อมูลเพื่อให้แน่ใจว่าไม่มีเงื่อนไขการแข่งขันเพื่อให้แน่ใจว่าฉันได้ล็อกแถวหรือตารางที่ถูกต้อง แต่ฉันมักจะสงสัยว่า: รหัสของฉันถูกต้องหรือไม่ เป็นไปได้ไหมที่จะบังคับให้เงื่อนไขการแข่งขันใด ๆ ฉันต้องการแน่ใจว่าหากพวกเขาเกิดขึ้นในสภาพแวดล้อมการผลิตแอปพลิเคชันของฉันจะทำสิ่งที่ถูกต้อง ฉันมักจะรู้ว่าการค้นหาพร้อมกันที่น่าจะทำให้เกิดปัญหา แต่ฉันไม่รู้ว่าจะบังคับให้พวกเขาทำงานพร้อมกันเพื่อดูว่าพฤติกรรมที่ถูกต้องเกิดขึ้น (เช่นฉันใช้ล็อคประเภทที่ถูกต้อง) ว่าข้อผิดพลาดถูกต้อง โยน ฯลฯ หมายเหตุ: ฉันใช้ PostgreSQL และ Perl ดังนั้นหากไม่สามารถตอบได้โดยทั่ว ๆ ไปก็น่าจะได้รับการติดซ้ำเช่นนี้ อัปเดต:ฉันต้องการถ้าการแก้ปัญหาเป็นแบบโปรแกรม ด้วยวิธีนี้ฉันสามารถเขียนการทดสอบอัตโนมัติเพื่อให้แน่ใจว่าไม่มีการถดถอย

3
การจัดการภาวะพร้อมกันเมื่อใช้รูปแบบ SELECT-UPDATE
สมมติว่าคุณมีรหัสต่อไปนี้ (โปรดอย่าสนใจว่ามันแย่มาก): BEGIN TRAN; DECLARE @id int SELECT @id = id + 1 FROM TableA; UPDATE TableA SET id = @id; --TableA must have only one row, apparently! COMMIT TRAN; -- @id is returned to the client or used somewhere else ในสายตาของฉันนี่ไม่ใช่การจัดการภาวะพร้อมกันอย่างเหมาะสม เพียงเพราะคุณมีการทำธุรกรรมไม่ได้หมายความว่าคนอื่นจะไม่อ่านค่าเดียวกันกับที่คุณทำก่อนที่คุณจะได้รับการปรับปรุงของคุณ ตอนนี้ปล่อยให้รหัสตามที่เป็นอยู่ (ฉันตระหนักดีว่านี่คือการจัดการที่ดีกว่าเป็นคำสั่งเดียวหรือดียิ่งขึ้นโดยใช้คอลัมน์ autoincrement / เอกลักษณ์) สิ่งที่แน่ใจว่าวิธีที่จะทำให้มันจัดการพร้อมกันอย่างถูกต้องและป้องกันเงื่อนไขการแข่งขัน ค่า …

6
ฉันสามารถอ่านค่า SQL Server Identity ตามลำดับได้หรือไม่?
TL: DR:คำถามด้านล่างนี้ลดลงเหลือ: เมื่อแทรกแถวจะมีหน้าต่างของโอกาสระหว่างการสร้างIdentityค่าใหม่และการล็อคกุญแจแถวที่สอดคล้องกันในดัชนีคลัสเตอร์ซึ่งผู้สังเกตการณ์ภายนอกจะเห็นที่ใหม่กว่า Identityมูลค่าแทรกโดยการทำธุรกรรมพร้อมกันหรือไม่ (ใน SQL Server) รุ่นโดยละเอียด ฉันมีตาราง SQL Server พร้อมIdentityคอลัมน์ที่เรียกว่าCheckpointSequenceซึ่งเป็นกุญแจสำคัญของดัชนีคลัสเตอร์ของตาราง (ซึ่งยังมีดัชนี nonclustered เพิ่มเติมอีกจำนวนหนึ่ง) แถวถูกแทรกเข้าไปในตารางโดยกระบวนการและเธรดพร้อมกันจำนวนมาก (ที่ระดับการแยกREAD COMMITTEDและไม่มีIDENTITY_INSERT) ในเวลาเดียวกันมีกระบวนการที่อ่านแถวจากดัชนีคลัสเตอร์เป็นระยะโดยเรียงลำดับตามCheckpointSequenceคอลัมน์นั้น(เช่นเดียวกับที่ระดับการแยกREAD COMMITTEDด้วยREAD COMMITTED SNAPSHOTตัวเลือกที่ถูกปิด) ขณะนี้ฉันพึ่งพาข้อเท็จจริงที่ว่ากระบวนการอ่านไม่สามารถ "ข้าม" จุดตรวจสอบได้ คำถามของฉันคือ: ฉันสามารถพึ่งพาอสังหาริมทรัพย์นี้ได้หรือไม่? และถ้าไม่ฉันจะทำอย่างไรเพื่อทำให้เป็นจริง ตัวอย่าง: เมื่อแทรกแถวที่มีค่าเอกลักษณ์ 1, 2, 3, 4 และ 5 ผู้อ่านจะต้องไม่เห็นแถวที่มีค่า 5 ก่อนที่จะเห็นแถวที่มีค่า 4 การทดสอบแสดงให้เห็นว่าแบบสอบถามซึ่งมีORDER BY CheckpointSequenceข้อ ( และWHERE CheckpointSequence > -1ประโยค) บล็อกได้อย่างน่าเชื่อถือเมื่อใดก็ตามที่ต้องอ่านแถว 4 …


1
อ่านแถวที่อัปเดตบางส่วนหรือไม่
สมมติว่าฉันมีสองแบบสอบถามทำงานในสองช่วงแยกกันใน SSMS: เซสชั่นแรก: UPDATE Person SET Name='Jonny', Surname='Cage' WHERE Id=42 เซสชั่นที่สอง: SELECT Name, Surname FROM Person WITH(NOLOCK) WHERE Id > 30 เป็นไปได้ไหมที่SELECTคำแถลงสามารถอ่านแถวที่มีการอัพเดตครึ่งหนึ่งได้เช่นเดียวกับName = 'Jonny'และSurname = 'Goody'? แบบสอบถามจะถูกดำเนินการเกือบจะพร้อมกันในเซสชันที่แยกต่างหาก

3
แทรกถ้าไม่มีอยู่พร้อมกัน
ฉันกำลังมีปัญหาการใช้งานพร้อมกันกับส่วนแทรกในขั้นตอนการจัดเก็บ ส่วนที่เกี่ยวข้องของขั้นตอนนี้คือ: select @_id = Id from table1 where othervalue = @_othervalue IF( @_id IS NULL) BEGIN insert into table1 (othervalue) values (@_othervalue) select @_id = Id from table1 where othervalue = @_othervalue END เมื่อเรารัน proc ที่เก็บไว้ 3 หรือ 4 ของพร้อมกันนี้เราได้รับการแทรกหลายครั้ง ฉันกำลังวางแผนในการแก้ไขเช่นนี้: insert into table1 (othervalue) select TOP(1) @_othervalue as …

1
ระบบจัดเก็บข้อมูลพร้อมกันสูง
ลองนึกภาพความต้องการของคุณคือคุณมีตารางขนาดใหญ่ 3 ตาราง (ข้อมูลที่มีโครงสร้าง) โดยมีจำนวนแถวละ 30,000 ล้านแถว (ขนาดรวม 4TB) และผู้ใช้ที่ใช้งานพร้อมกันจำนวนมาก (ซึ่งเป็นเธรดระบบปฏิบัติการแบบขนานบนเครื่อง LAN ระยะไกล) ข้อมูลผ่าน SELELCT WHERE GROUPBY ของพวกเขาและพร้อมกันสูงพูด 10,000 อ่านพร้อมกันในเวลาเดียวกันและผู้ใช้จำเป็นต้องแทรกข้อมูล (ไม่มีการปรับปรุง) ลงในตารางเหล่านี้พร้อมกันสูงเช่นนักเขียนพร้อมกัน 2000 (ทั่วเครือข่าย LAN ของศูนย์ข้อมูล) . ผู้ใช้ต้องการอ่านและแทรกให้เร็วที่สุดเท่าที่จะเป็นไปได้ในรูปแบบที่เก็บข้อมูลนี้ซึ่งการอ่านและเขียนแต่ละอันจะเกิดขึ้นคือ ms ถึง 1 วินาที เทคโนโลยีใดที่คุณแนะนำให้ตอบสนองความต้องการดังกล่าว มีที่เก็บข้อมูลหรือที่เก็บค่าคีย์ที่สามารถทำสิ่งนี้ได้หรือไม่? คลาวด์ไม่ใช่ตัวเลือก ชี้แจงบางส่วน: ผู้ใช้ไม่จำเป็นต้องเห็นข้อมูลทันทีและยอมรับความสอดคล้องในที่สุด ข้อมูลสามารถเข้าถึงได้ผ่านทุกไดรเวอร์ที่หน่วยเก็บข้อมูลสามารถให้และผู้ใช้จะเป็นเพียงเธรดที่ทำงานบนเครื่องระยะไกลของศูนย์ข้อมูล ข้อความค้นหาส่วนใหญ่จะเป็นเหมือน SELECT WHERE GROUPBY ข้อมูลอยู่ในรูปแบบตารางและแต่ละแถวมีขนาดประมาณ 60 ไบต์ ไม่มีตัวเลือกคลาวด์ที่ฉันไม่สามารถใช้ DynamoDB หรือโซลูชันที่คล้ายกัน ฉันต้องสามารถโฮสต์ภายในศูนย์ข้อมูลได้ ข้อมูลทั้งหมดของตารางสามารถอ่านได้ตลอดเวลาและรูปแบบการใช้งานไม่แน่นอน …

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

1
ล็อคใน Postgres สำหรับชุด UPDATE / INSERT
ฉันมีสองตาราง หนึ่งคือตารางบันทึก; อีกอันประกอบด้วยรหัสคูปองที่สามารถใช้ได้ครั้งเดียวเท่านั้น ผู้ใช้ต้องสามารถแลกคูปองซึ่งจะแทรกแถวลงในตารางบันทึกและทำเครื่องหมายคูปองที่ใช้ (โดยอัปเดตusedคอลัมน์เป็นtrue) โดยธรรมชาติมีปัญหาสภาพการแข่งขัน / ความปลอดภัยที่เห็นได้ชัดที่นี่ ฉันเคยทำสิ่งที่คล้ายกันในอดีตในโลกของ mySQL ในโลกนั้นฉันจะล็อกทั้งสองตารางทั่วโลกทำตรรกะให้ปลอดภัยด้วยความรู้ที่ว่าสิ่งนี้จะเกิดขึ้นได้ครั้งละครั้งแล้วปลดล็อกตารางเมื่อฉันทำเสร็จแล้ว Postgres มีวิธีที่ดีกว่าในการทำเช่นนี้หรือไม่? โดยเฉพาะอย่างยิ่งฉันกังวลว่าการล็อกนั้นเป็นแบบโกลบอล แต่ไม่จำเป็นต้องเป็น - ฉันแค่ต้องทำให้แน่ใจว่าไม่มีใครพยายามป้อนรหัสนั้นดังนั้นบางทีการล็อกระดับแถวอาจจะใช้งานได้

2
LATCH_EX รอทรัพยากร METADATA_SEQUENCE_GENERATOR
เรามีกระบวนการที่สร้างรายงานสินค้าคงคลัง ในฝั่งไคลเอ็นต์กระบวนการแยกจำนวนเธรดผู้ปฏิบัติงานที่สามารถกำหนดค่าได้เพื่อสร้างกลุ่มข้อมูลสำหรับรายงานที่สอดคล้องกับที่เก็บหนึ่งแห่งจากหลาย ๆ ที่ (อาจเป็นพันหลายสิบโดยทั่วไป) เธรดผู้ปฏิบัติงานแต่ละคนเรียกบริการเว็บที่ดำเนินการตามขั้นตอนที่เก็บไว้ กระบวนการฐานข้อมูลสำหรับการประมวลผลแต่ละกลุ่มรวบรวมข้อมูลลงในตาราง #Temporary ในตอนท้ายของแต่ละชิ้นประมวลผลข้อมูลจะถูกเขียนไปยังตารางถาวรใน tempdb ในที่สุดเมื่อสิ้นสุดกระบวนการหนึ่งเธรดที่ฝั่งไคลเอ็นต์ร้องขอข้อมูลทั้งหมดจากตาราง tempdb ถาวร ยิ่งผู้ใช้ที่เรียกใช้รายงานนี้ยิ่งได้รับช้า ฉันวิเคราะห์กิจกรรมในฐานข้อมูล ณ จุดหนึ่งฉันเห็นคำขอ 35 รายการที่ถูกบล็อกทั้งหมดถูกบล็อก ณ จุดหนึ่งในกระบวนการ SPIDs ทั้งหมดเหล่านี้ได้ในคำสั่งของ 50 มิลลิวินาทีรอประเภททรัพยากรLATCH_EX METADATA_SEQUENCE_GENERATOR (00000010E13CA1A8)SPID หนึ่งมีทรัพยากรนี้และอื่น ๆ ทั้งหมดกำลังบล็อก ฉันไม่พบสิ่งใดเกี่ยวกับทรัพยากรการรอนี้ในการค้นหาเว็บ ตารางใน tempdb ที่เราใช้อยู่มีIDENTITY(1,1)คอลัมน์ SPID เหล่านี้กำลังรอคอลัมน์ประจำตัวหรือไม่ เราสามารถใช้วิธีการใดในการลดหรือกำจัดการบล็อก เซิร์ฟเวอร์เป็นส่วนหนึ่งของคลัสเตอร์ เซิร์ฟเวอร์กำลังเรียกใช้ SQL Server 2012 Standard Edition SP1 64 บิตใน Windows 2008 R2 …

6
สถานการณ์ที่ดีที่สุดในการใช้ระดับการแยก READ UNCOMMITTED
ดังที่เราทุกคนทราบกันดีว่าการอ่านไม่ได้รับการยอมรับนั้นเป็นระดับการแยกต่ำสุดที่สิ่งต่าง ๆ เช่นการอ่านสกปรกและการอ่าน phantom อาจเพิ่มขึ้น เวลาที่ดีที่สุดในการใช้ระดับการแยกนี้เมื่อใดและด้วยเหตุผลใดบ้างที่ควรใช้ ที่จริงฉันอ่านคำตอบก่อนหน้านี้ แต่ฉันไม่สามารถเข้าใจได้อย่างสมบูรณ์เพราะมีตัวอย่างไม่เพียงพอ

1
การวางคำสั่ง Select ในธุรกรรม
ข้อแตกต่างระหว่าง 2 ข้อความค้นหาเหล่านี้คืออะไร: START TRANSACTION; SELECT * FROM orders WHERE id=1; UPDATE orders SET username='John' WHERE id=1; COMMIT; และไม่มีการทำธุรกรรม: SELECT * FROM orders WHERE id=1; UPDATE orders SET username='John' WHERE id=1; ผลของการมีSELECTการทำธุรกรรมภายในคืออะไร? หากDELETE FROM orders WHERE id=1ถูกเรียกจากเซสชันอื่นหลังจากSELECTทั้งสองกรณีจะถูกประมวลผลเมื่อใด

3
ความไม่สอดคล้องกันในการอ่านซ้ำ
http://www.postgresql.org/docs/9.2/static/transaction-iso.html โหมดการอ่านซ้ำจะให้การรับประกันอย่างเข้มงวดว่าแต่ละธุรกรรมจะเห็นมุมมองที่สมบูรณ์ของฐานข้อมูล อย่างไรก็ตามมุมมองนี้จะไม่จำเป็นต้องสอดคล้องกับการดำเนินการอนุกรม (ทีละครั้ง) เสมอของการทำธุรกรรมที่เกิดขึ้นพร้อมกันในระดับเดียวกัน ตัวอย่างเช่นแม้แต่ธุรกรรมแบบอ่านอย่างเดียวในระดับนี้อาจเห็นระเบียนควบคุมที่อัปเดตเพื่อแสดงว่าแบทช์เสร็จสมบูรณ์แล้ว แต่ไม่เห็นหนึ่งในบันทึกรายละเอียดซึ่งเป็นส่วนหนึ่งในเชิงตรรกะของแบทช์เพราะอ่านการแก้ไขเรคคอร์ดควบคุมก่อนหน้านี้ . ความพยายามในการบังคับใช้กฎเกณฑ์ทางธุรกิจโดยธุรกรรมที่ทำงานในระดับการแยกนี้ไม่น่าจะทำงานได้อย่างถูกต้องโดยไม่ต้องใช้การล็อคอย่างชัดเจนเพื่อป้องกันการทำธุรกรรมที่ขัดแย้งกัน นั่นไม่ใช่ phantom read ซึ่งเป็นไปไม่ได้ในโหมดอ่านซ้ำ เอกสารระบุว่าแบบสอบถามในธุรกรรมอ่านซ้ำสามารถดูสแน็ปช็อตเมื่อเริ่มต้นธุรกรรมจากนั้นจึงเป็นไปได้อย่างไรที่แบบสอบถามจะอ่านข้อมูลที่ไม่สอดคล้องกัน

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.