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

กลไกสำหรับการกระทำชุดการเปลี่ยนแปลงที่สอดคล้องกันลงในฐานข้อมูลแบบอะตอม

5
ความสัมพันธ์ที่แน่นอนระหว่างธุรกรรมฐานข้อมูลและการล็อกคืออะไร
นี่เป็นคำถามถ่อมใจที่ถามในวิญญาณของการเพิ่มความรู้ของฉัน; กรุณาอ่อนโยนในการตอบสนองของคุณ ในฐานะนักพัฒนาแอปพลิเคชั่นที่ใช้เวลานานฉันรู้ในระดับหนึ่งว่าธุรกรรมคืออะไร (ฉันใช้พวกเขาตลอดเวลา) ออกจากระดับการแยกธุรกรรมในขณะนี้ในระดับสูงธุรกรรมอนุญาตให้บล็อกการทำงานเสร็จสมบูรณ์ทั้งหมดหรือไม่เลยและอนุญาตให้มีการแยกจำนวนหนึ่งจากกิจกรรมการแก้ไขฐานข้อมูลอื่น ๆ ฉันยังรู้ว่า (ในฐานข้อมูลต่าง ๆ ) คืออะไรล็อคหรืออย่างน้อยหนึ่งวิธีการทำงาน (ถ้าฉันล็อคตารางในบางวิธีอย่างชัดเจนแล้วไม่มีกระบวนการหรือด้ายอื่น ๆ สามารถปรับปรุงอะไรเกี่ยวกับตารางที่) สิ่งที่ฉันมากที่สุดอย่างเห็นได้ชัดไม่ชัดเจนเกี่ยวกับการเป็นในฐานข้อมูลต่างๆเมื่อฉันอย่างชัดเจนล็อคแถวหรือตารางฉันกำลังจ้างโครงสร้างเดียวกันที่ใช้โดยฐานข้อมูลของสิ่งอำนวยความสะดวกการทำธุรกรรมภายใต้ครอบคลุมเพื่อให้การทำงานการทำธุรกรรมที่ถูกต้องหรือไม่ นั่นคือมันเกิดขึ้นกับฉันว่าเพื่อให้การทำธุรกรรมเป็นปรมาณูและโดดเดี่ยวนั้นจะต้องมีการล็อค การล็อคทรานแซคชั่นซ่อนเร้นจากทรานแซคชันนี้เป็นการล็อกแบบเดียวกับที่ฐานข้อมูลต่างๆให้ฉันเข้าถึงผ่านการสร้างเช่นSELECT FOR UPDATEหรือLOCKคำสั่งที่ชัดเจน? หรือแนวคิดทั้งสองนี้แตกต่างอย่างสิ้นเชิง? อีกครั้งฉันขอโทษสำหรับnaïvetéของคำถามนี้ ฉันมีความสุขที่จะชี้ไปที่แหล่งข้อมูลพื้นฐานเพิ่มเติม

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

2
หลีกเลี่ยงการละเมิดที่ไม่ซ้ำกันในการทำธุรกรรมอะตอม
เป็นไปได้ในการสร้างธุรกรรมอะตอมมิกใน PostgreSQL? พิจารณาฉันมีหมวดหมู่ตารางที่มีแถวเหล่านี้: id|name --|--------- 1 |'tablets' 2 |'phones' และชื่อคอลัมน์มีข้อ จำกัด ที่ไม่ซ้ำกัน ถ้าฉันลอง: BEGIN; update "category" set name = 'phones' where id = 1; update "category" set name = 'tablets' where id = 2; COMMIT; ฉันได้รับ: ERROR: duplicate key value violates unique constraint "category_name_key" DETAIL: Key (name)=(tablets) already exists.

4
ฉันสามารถเปลี่ยนโครงสร้างตารางในธุรกรรมแล้วย้อนกลับหากมีข้อผิดพลาดได้หรือไม่?
ฉันมีALTER TABLEข้อความบางส่วนที่ฉันใช้อยู่ ไม่ใช่ทั้งหมดที่ทำงาน (เป็นผลมาจากการรันการเปรียบเทียบข้อมูล SQL) และฉันต้องการจัดกลุ่มพวกเขาในบางธุรกรรมและย้อนกลับคำสั่งหากมีสิ่งผิดปกติ เป็นไปได้หรือเป็นเพียงข้อมูลที่สามารถย้อนกลับได้?

2
ดัชนีที่ไม่ซ้ำที่เลื่อนออกไปใน postgres
เมื่อมองไปที่เอกสารประกอบของ postgres สำหรับตารางการเปลี่ยนแปลงดูเหมือนว่าข้อ จำกัด ทั่วไปสามารถทำเครื่องหมายเป็นDEFERRABLE(เพิ่มเติมอย่างชัดเจนINITIALLY DEFERREDซึ่งเป็นสิ่งที่ฉันสนใจ) ดัชนียังสามารถเชื่อมโยงกับข้อ จำกัด ได้ตราบใดที่: ดัชนีไม่สามารถมีคอลัมน์นิพจน์หรือดัชนีบางส่วนได้ ซึ่งทำให้ฉันเชื่อว่าขณะนี้ไม่มีวิธีที่จะมีดัชนีที่ไม่ซ้ำกับเงื่อนไขเช่น: CREATE UNIQUE INDEX unique_booking ON public.booking USING btree (check_in, check_out) WHERE booking_status = 1; จะINITIALLY DEFERREDหมายถึงว่า 'ข้อ จำกัด ' ที่ไม่ซ้ำกันจะได้รับการตรวจสอบในตอนท้ายของการทำธุรกรรม (ถ้าSET CONSTRAINTS ALL DEFERRED;ใช้) การสันนิษฐานของฉันถูกต้องและถ้าเป็นเช่นนั้นมีวิธีใดบ้างที่จะบรรลุเป้าหมายที่ต้องการ? ขอบคุณ

1
เราจำเป็นต้องจัดการธุรกรรมในรหัส C # หรือในขั้นตอนการจัดเก็บ
เราจำเป็นต้องมีการจัดการธุรกรรมใน c # หรือไม่รวมถึงการจัดเก็บฐานข้อมูลทั้งสองด้าน ค#: Using(transaction with transaction scope) { Execute stored proc; Transaction. Complete; } โพรซีเดอร์ที่เก็บ SQL: Create process As Begin try Begin transaction Commit End try Begin catch Rollback End catch

1
MySQL มุ่งมั่นที่จะไม่เห็นข้อมูลเพื่อเลือกแบบสอบถาม
บริบท: เฟรมเวิร์กที่ใช้คือ Spring และเคียวรีทั้งหมดรันด้วย JdbcTemplate เซิร์ฟเวอร์ Mysql คือ 5.6.19 tableเป็นInnoDB tableและค่าเริ่มต้นเหมือนauto commitและระดับการแยกทำซ้ำอ่านเป็นชุด ปัญหา : Insertเกิดขึ้นภายในธุรกรรมและselectที่อ่านข้อมูลเดียวกันที่แทรกไว้ไม่เห็นข้อมูล selectวิ่งหลังจากinsertและหลังการทำธุรกรรมมีinsertcommited ฉันได้เปิดใช้งาน bin log รวมถึง log ทั่วไปใน mysql แล้ว บันทึกที่เกี่ยวข้องด้านล่าง ถังเข้าสู่ระบบ: SET TIMESTAMP=1438265764/*!*/; BEGIN /*!*/; # at 249935389 #150730 14:16:04 server id 1 end_log_pos 249935606 CRC32 0xa6aca292 Query thread_id=40 exec_time=0 error_code=0 SET TIMESTAMP=1438265764/*!*/; insert into …

1
ใน Postgres วิธีรับรายการ savepoint ที่กำหนดในปัจจุบันต้องทำอย่างไร?
ฉันใช้ postgres SAVEPOINTซึ่งสร้าง savepoint ใหม่ภายในธุรกรรมปัจจุบันและต้องการแสดงรายการของ savepoint ที่กำหนดไว้ในปัจจุบันในการเชื่อมต่อ เพื่อให้แม่นยำยิ่งขึ้น: ฉันต้องการตรวจสอบชื่อที่จะไม่เรียกข้อผิดพลาด "no savepoint" ในการเชื่อมต่อ

1
MySQL: ธุรกรรมจะล็อกแถวหรือไม่
ฉันไม่เคยลองใช้ธุรกรรม MySQL มาก่อนฉันแค่ต้องการชี้แจงบางอย่าง หากผู้ใช้สองคนเรียกใช้แบบสอบถามในเวลาที่แน่นอน MySQL จะจัดการเรื่องนี้อย่างไร เช่นผู้ใช้พยายามอัปเดตบันทึก user1: อัปเดตชุดตารางคอลัมน์ = คอลัมน์ - 4 โดยที่ column_id = 1; user2: อัปเดตชุดคอลัมน์ตาราง = คอลัมน์ - 7 โดยที่ column_id = 1; ตอนนี้ถ้าฉันใช้ทรานแซกชัน MySQL จะเลือกแบบสอบถามที่จะถูกดำเนินการก่อนและล็อกผู้ใช้รายที่สองจนกว่าจะมีการสืบค้นครั้งแรก จะเป็นล็อคตารางหรือล็อคแถวหรือไม่? จะเป็นอย่างไรถ้าผู้ใช้รายที่สามออกคำสั่ง select? MySQL จะคืนค่าอะไร? ป.ล. นี้จะอยู่ที่ Innodb

1
วิธีการเปรียบเทียบ xmin และ txid_current () หลังจากการทำธุรกรรม ID wraparound?
นอกจากคอลัมน์ปกติแล้วตาราง Postgres ยังมีคอลัมน์ระบบต่าง ๆให้ใช้งาน หนึ่งในนั้นxminเก็บ ID ธุรกรรมที่ใช้ในการสร้างแถว ชนิดข้อมูลของมันคือxidจำนวนเต็มสี่ไบต์ที่ล้อมรอบในบางจุด (เช่นไม่จำเป็นต้องไม่ซ้ำกัน) ฟังก์ชันtxid_current()จะส่งคืน ID ธุรกรรมปัจจุบัน แต่bigintเนื่องจาก "ขยาย" ด้วยตัวนับ "ยุค" ดังนั้นมันจะไม่ล้อมรอบในช่วงอายุการติดตั้ง "(เพื่ออ้างอิงคู่มือ ) หากการรวมธุรกรรมไม่ได้เกิดขึ้นค่าทั้งคู่ดูเหมือนจะตรงกัน: # CREATE TABLE test (label text); CREATE TABLE # INSERT INTO test VALUES ('test') RETURNING txid_current(); txid_current -------------- 674500 (1 row) INSERT 0 1 # SELECT xmin FROM test; xmin …

1
ปิดใช้งานคอมมิชชันที่ชัดเจนใน JDBC ตรวจจับใน SQL หรือทำให้ฐานข้อมูลอยู่ในสถานะอ่านอย่างเดียว
พื้นหลัง : ฉันกำลังทำงานในhttp://sqlfiddle.com (เว็บไซต์ของฉัน) และกำลังพยายามป้องกันไม่ให้มีการละเมิดวิธีใดวิธีหนึ่ง ฉันหวังว่าด้วยการถามเกี่ยวกับปัญหาที่ฉันกำลังพูดถึงอยู่ในปัจจุบันฉันไม่ได้ตั้งใจทำให้การละเมิดที่อาจเกิดขึ้นแย่ลงโดยไม่ได้ตั้งใจ แต่คุณจะทำอย่างไร ฉันเชื่อใจพวกคุณ ฉันต้องการป้องกันไม่ให้ผู้ใช้ออกการเรียก 'ส่งสัญญาณ' อย่างชัดเจนภายในบล็อคธุรกรรม จากบริบทของ SQL Fiddle บล็อกธุรกรรมคือรหัสที่เรียกใช้งานบนแผงด้านขวา โดยทั่วไปฉันจะวนซ้ำและดำเนินการรายการคำสั่ง plaintext SQL และฉันต้องการให้แน่ใจว่าการเปลี่ยนแปลงทั้งหมดที่ทำจะถูกย้อนกลับในตอนท้ายของแบทช์ โดยปกติการเปลี่ยนแปลงของพวกเขาจะได้รับการย้อนกลับ แต่บางครั้งก็มีคำสั่ง 'กระทำ' ที่ชัดเจนภายในข้อความและแน่นอนว่าการย้อนกลับของฉันจะไม่ทำงาน ความมุ่งมั่นที่ชัดเจนนี้มีแนวโน้มมากจากผู้ใช้ที่พยายามจะทำลาย schema บน SQL Fiddle ดังนั้นคนอื่น ๆ ที่ทำงานกับมันจะเห็นข้อผิดพลาด ผลลัพธ์หลักที่ต้องการ : ฉันต้องการปิดใช้งานการกระทำที่ชัดเจนในระดับ JDBC ถ้าเป็นไปได้ นี่เป็นเพราะฉันต้องสนับสนุนผู้ขายแบ็กเอนด์ฐานข้อมูลหลายคนและแน่นอนว่าแต่ละคนมีนิสัยใจคอในระดับต่ำ ตัวเลือกสำรอง : หากไม่สามารถกำหนดค่า JDBC เพื่อปิดใช้งานการกระทำที่ชัดเจนได้ฉันจะเปิดให้มีการตรวจหาการกระทำที่ชัดเจนในขณะประมวลผลชุดข้อมูลสำหรับแบ็กเอนด์ต่อไปนี้: SQL Server, Oracle, MySQL และ PostgreSQL สำหรับ SQL …

2
การทำธุรกรรมในขั้นตอนการจัดเก็บ
ฉันต้องการดำเนินการ UPDATE และ INSERT ในธุรกรรมเดียว รหัสนั้นทำงานได้ดีในตัวของมันเอง แต่ฉันต้องการที่จะสามารถเรียกมันได้อย่างง่ายดายและผ่านพารามิเตอร์ที่ต้องการ เมื่อฉันพยายามทำธุรกรรมนี้ในขั้นตอนการจัดเก็บฉันพบข้อผิดพลาดทางไวยากรณ์มากมาย ฉันจะแค็ปซูลโค้ดต่อไปนี้เพื่อให้สามารถเรียกได้อย่างง่ายดาย? BEGIN TRANSACTION AssignUserToTicket GO DECLARE @updateAuthor varchar(100) DECLARE @assignedUser varchar(100) DECLARE @ticketID bigint SET @updateAuthor = 'user1' SET @assignedUser = 'user2' SET @ticketID = 123456 UPDATE tblTicket SET ticketAssignedUserSamAccountName = @assignedUser WHERE (ticketID = @ticketID); INSERT INTO [dbo].[tblTicketUpdate] ([ticketID] ,[updateDetail] ,[updateDateTime] …

2
InnoDB เก็บข้อมูลธุรกรรมไว้ก่อนที่จะส่งมอบที่ไหน
ฉันได้ทำการทดสอบบางอย่างโดยใช้READ_COMMITTEDและREAD_UNCOMMITTEDที่บ้านโดยใช้เทคโนโลยี JDBC ฉันเห็นว่าREAD_UNCOMMITTEDจริง ๆ แล้วสามารถอ่านข้อมูลที่ไม่มีข้อผูกมัดเช่นข้อมูลจากธุรกรรมบางรายการที่ยังไม่ได้รับการยืนยัน คำถาม ข้อมูลที่ไม่ได้รับการจัดเก็บอยู่ที่ไหนเช่นการREAD_UNCOMMITTEDทำธุรกรรมสามารถอ่านข้อมูลที่ปราศจากข้อผูกมัดจากการทำธุรกรรมอื่นได้หรือไม่ เหตุใดจึงเป็นไปไม่ได้ที่การREAD_COMMITTEDทำธุรกรรมในการอ่านข้อมูลที่ไม่มีข้อผูกมัดนั่นคือการ "อ่านสกปรก" กลไกอะไรบังคับใช้ข้อ จำกัด นี้

3
ผลของการมีธุรกรรมเปิดใน MSSQL นานเกินไปคืออะไร?
ฉันแค่สงสัยว่าจะเกิดอะไรขึ้นถ้าคุณเริ่มทำธุรกรรมในฐานข้อมูลและลืมที่จะกระทำหรือย้อนกลับ เซิร์ฟเวอร์จะล่มหรือไม่ ให้บอกว่าคุณทิ้งไว้ 3 วัน นอกจากนี้ยังมีผู้ใช้ที่ใช้งานสมมติว่าผู้ใช้รายอื่นไม่ทราบว่ามีการทำธุรกรรมที่ไม่เปิดเผย (ขอเพียงสมมติว่าผู้ใช้กำลังแทรกข้อมูลในฐานข้อมูล) อะไรคือผลที่ตามมาของการกระทำนี้?

1
ตัวเลือก“ ตัดทอนล็อกออนจุดตรวจสอบ” ใน SQL Server
เรื่องยาว แต่ที่ปรึกษาระยะยาวของเรา (อดีตพนักงาน) เขียนสคริปต์ที่กำหนดเองปีที่ผ่านมา (2006 หรือดังนั้น) เพื่อติดต่อกับ Tivoli Storage Manager และดูเหมือนว่ามันจะได้รับการตรวจสอบตัวเลือก SQL Server DB truncate log on checkpointชื่อ การเรียกร้องของพวกเขาคือมันป้องกันสคริปต์จากการทำงานและการสำรองข้อมูลในอินสแตนซ์ซึ่งเป็น SQL 2012 ฉันรู้สึกว่า BS นั้นสมบูรณ์เพราะฉันไม่พบตัวเลือกดังกล่าวผ่านทางsp_configureและการสำรองข้อมูลทำงานได้ทุกที่ยกเว้นกรณีเดียว อย่างไรก็ตามฉันต้องการที่จะลบทุ่นระเบิดถ้านั่นคือสิ่งที่มันเป็นและลบองค์ประกอบที่ล้าสมัยอื่น ๆ ฉันให้พวกเขาตรวจสอบกับผู้ขาย แต่ฉันไม่มีความมั่นใจในระดับสูงในสิ่งที่พวกเขาพูด การวิจัยที่ฉันได้รับกลับมายิ่งกว่านั้นอาจเป็นตัวเลือกสำหรับ SQL 2000 หรือตัวเลือก Sybase การอ้างสิทธิ์อีกอย่างคือมันถูกเรียก / ใช้โดยนัยในรุ่นที่ใหม่กว่า (2008 ขึ้นไป) เมื่อรูปแบบการกู้คืนเป็นSIMPLEและไม่มีตัวเลือกที่ชัดเจนในการเปิดหรือปิด เนื่องจากTRUNCATE LOGคำสั่งล้าสมัยเนื่องจากบันทึกการทำงานของธุรกรรมในปัจจุบันฉันคิดว่านี่ไม่ใช่ตัวเลือกที่สามารถสอบถามได้ที่จุดนี้ เนื่องจากฉันไม่มีอินสแตนซ์ของ SQL Server 2000 ฉันหวังว่าจะมีบางคนจำได้หรือสามารถตรวจสอบได้จากที่วางไว้ ฉันบอกพวกเขาว่ามันไม่มีอะไรจะแนะนำ ฉันก็หวังว่าบางคนสามารถยืนยันได้ว่านี่เป็นสิ่งล้าสมัย

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