Tại sao các giao dịch không được cam kết phải được hoàn tác theo thứ tự ngược?

19

Tôi có một nhật ký cơ sở dữ liệu trong đó một số giao dịch giành chiến thắng (chúng được cam kết trước khi sụp đổ) và một số mất (chưa được cam kết). Chúng tôi đã học được trong lớp rằng hành động của người thua cuộc phải được hoàn tác ngược.

Có bất kỳ lý do để làm điều này ngược? Bất cứ ai cũng có thể đưa ra một ví dụ đơn giản về một bản ghi trong đó các bản hoàn tác chuyển tiếp sẽ cho kết quả sai?

concurrency databases

— prjctdth
nguồn

Không nên hỏi câu hỏi này trong một trang web cụ thể hơn?

— nbro

35

Giao dịch gốc:

Chèn bản ghi . $r$
Cập nhật một số trường của . $f$ $r$

Chuyển tiếp hoàn tác:

Xóa hồ sơ . $r$
Đảo ngược bản cập nhật thành - oh chờ đã, không còn tồn tại! Điều này gây ra lỗi. $r$ $r$

— DylanSp
nguồn

Có phải mọi thứ cần phải được hoàn tác về mặt vật lý theo thứ tự ngược lại nếu hệ thống có thể tìm ra trạng thái nào cần được khôi phục và có thể áp dụng tất cả các thay đổi cần thiết trước khi xử lý bất kỳ điều gì khác không?

— supercat

11

Hoàn tác thay đổi theo thứ tự ngược lại làm cho nó dễ dàng. Tại sao bạn lại cố gắng làm khó bản thân?

— gnasher729

1

Không, hệ thống sẽ không làm mọi thứ nhưng vẫn sẽ tìm ra điều đó theo thứ tự lạc hậu.

— Ác

3

Trong nhiều hệ thống cơ sở dữ liệu trong thế giới thực, việc này không theo thứ tự ngược lại thậm chí sẽ không thể thực hiện được do các ràng buộc chính trên các bảng.

— SeanR

11

Để thêm vào câu trả lời của DylanSp, cố gắng cập nhật một trường trong bản ghi không tồn tại sẽ thất bại, nhưng kết quả vẫn sẽ là kết quả mong đợi: bản ghi r không tồn tại.

Tuy nhiên, hãy xem xét một tình huống trong đó việc xóa một bản ghi thực sự sẽ thất bại:

Chèn thứ tự O.
Chèn thứ tự L.

Giả sử, không phải phi thực tế, rằng mọi OrderLine phải liên quan đến một Đơn hàng.

Bây giờ, việc khôi phục giao dịch bắt đầu bằng việc xóa Đơn hàng sẽ thất bại vì điều đó sẽ vi phạm quy tắc kinh doanh của chúng tôi.

Vậy sau

Xóa đơn hàng O. (FAIL)
Xóa Ordeline L. (THÀNH CÔNG)

Chúng tôi có thể kết thúc với một Đơn hàng hiện tại (không có Đơn hàng).

Tất nhiên, trong trường hợp này chúng ta có thể sử dụng xóa tầng, nhưng điều đó có nghĩa là bước 2 sẽ thất bại (không có tác động). Tồi tệ hơn, nó có thể là hành vi không mong muốn để thực hiện xóa tầng theo đơn đặt hàng.

— oerkelens
nguồn

Được rồi điều này có ý nghĩa. Thx vì sự giúp đỡ của bạn

— prjctdth 13/07/2016

Có đúng không khi cho rằng các ràng buộc không bị vi phạm trước hoặc sau giao dịch trong các trường hợp "bình thường"? Bình thường, ý tôi là giao dịch sẽ không thất bại nếu chỉ có một người sử dụng cơ sở dữ liệu. Nếu điều này là đúng, tại sao điều quan trọng là không đưa ra các vi phạm ràng buộc trong quá trình hoàn tác? Có vẻ như các ràng buộc có thể được tắt khi bắt đầu hoàn tác và được bật khi hoạt động hoàn tất.

— Noctis Skytower

2

@NoctisSkytower Tắt các ràng buộc trong hoạt động I / O bình thường làm cho chúng vô dụng. Chúng tồn tại vì một lý do. Ví dụ của tôi minh họa rõ ràng làm thế nào các ràng buộc có thể được đáp ứng trong các trường hợp bình thường, nhưng đã bị vi phạm trong quá trình khôi phục. Tắt các ràng buộc trong quá trình khôi phục là vấn đề phức tạp không cần thiết và khắc phục vấn đề sai. Vấn đề không phải là sự ràng buộc, vấn đề là sự vi phạm của nó bằng cách cố gắng không chính xác để quay trở lại.

— oerkelens

Vâng, điều đó có ý nghĩa, nhưng tại sao kiểm tra các ràng buộc trong quá trình rollback? Giả sử rollback được thiết kế để đảm bảo hoàn thành mà không gặp vấn đề gì, tại sao lại lãng phí thời gian một cách không cần thiết nếu biết rằng chúng sẽ không bị vi phạm vào thời điểm rollback hoàn thành? BTW, đó phải là một sự đảm bảo bởi vì nếu việc khôi phục thất bại, DB dường như cần phải cuộn lại mà điều đó không thể làm được.

— Noctis Skytower

1

@NoctisSkytower DB không thể ở trạng thái mà các ràng buộc bị vi phạm, ngay cả khi đó là trạng thái tạm thời. Nếu toàn bộ rollback là nguyên tử, thì nó không thành vấn đề theo thứ tự nào vì không có thứ tự, đó là một hướng dẫn duy nhất "xảy ra cùng một lúc". nếu có hai hoặc nhiều giao dịch được quay ngược lại theo một thứ tự nào đó, thì bắt buộc là thứ tự đó sao cho bất kỳ người quan sát nào đọc dữ liệu ở giữa chỉ có thể thấy tình huống mà tất cả các ràng buộc giữ.

— Peteris

6

Hãy đi theo cách tương tự: giả sử bạn đang đi ăn tối.

Mang vớ vào.
Mang giày vào.
Đứng lên.
Đi bộ đến cửa.

Sau đó, bạn nhận được một cuộc gọi điện thoại. Kế hoạch ăn tối bị hủy bỏ.

Cởi tất đi.
Cởi giày ra.
Ngồi xuống.
Đi ra khỏi cửa.

Có gì đó không ổn trong đó. Bạn có thể vấp ngã và làm tổn thương chính mình. Hoặc nhiều khả năng, bạn sẽ nhận ra rằng một số hành động không thể hoàn tác cho đến khi các hành động sau được hoàn tác trước.

Hoàn tác việc cuối cùng bạn đang làm sẽ đưa bạn trở lại vị trí của mình khi bước tiếp theo đến bước cuối cùng xảy ra. Sau đó, bạn hoàn tác bước đó và lặp lại, di chuyển trở lại cho đến khi không còn gì. Mặt khác, việc đảo ngược bước đầu tiên có thể không thực hiện được với các trạng thái theo các bước sau.

về mặt toán học: các hành động có thể không đi lại, vì vậy bất cứ khi nào nó quan trọng bước nào bạn thực hiện đầu tiên hoặc thứ hai, thứ tự mà bạn hoàn tác các bước sẽ quan trọng.

— Tham gia
nguồn

3

Điều này là đúng bởi vì các giao dịch được xây dựng chồng chéo lên nhau và kết quả của một giao dịch phụ thuộc rất nhiều vào tình huống trước khi nó được thực hiện.

Hãy xem xét các giao dịch tài chính:

(lúc đầu, trước khi giao dịch anợ tôi 100 USD)

a nợ tôi 100 USD (hiện tại tổng nợ 200)
anhận được giảm giá 10% cho những gì anh ta nợ tôi. (hiện tại tổng nợ 180)

Giả sử tôi muốn hủy hai giao dịch.

Nếu chúng tôi hủy lần đầu tiên, chúng tôi sẽ kết thúc bằng:

nợ dưới 100 (hiện có nợ 80)
hủy chiết khấu 10% (hiện có nợ 80 / 0,9 = 88)

Điều này là sai, chúng tôi cần lấy lại khoản nợ 100. Điều đó sẽ đúng nếu chúng tôi hủy các giao dịch theo thứ tự ngược lại.

hủy chiết khấu - bây giờ nợ là 200
nợ 100 thấp hơn - bây giờ nợ là 100

— thebeancount
nguồn

2

Giả sử có một bảng T chỉ có một cột.

Giả sử rằng "hoàn tác nhật ký" là một tệp cơ sở dữ liệu chứa các giao dịch không được cam kết và "nhật ký làm lại" là một tệp cơ sở dữ liệu chứa cả các giao dịch không được cam kết và đã cam kết chưa được áp dụng cho các tệp dữ liệu.

At 8:00 A.M., Transaction 100 inserts rows with values 101, 102 and 103 into table T. At 8:10 A.M., Transaction 100 is committed and the commit for transaction 100 completes. At 8:15 A.M., Transaction 200 updates row 101 to 201, 102 to 202 and 103 to 203. At 8:20 A.M., Transaction 200 has not been committed and remains in the undo log of the database. At 8:25 A.M., Transaction 300 increments each row by 50, changing row 201 to 251, 202 to 252, and 203 to 253. At 8:30 A.M., Transaction 300 has not been committed and remains in the undo log of the database. At 8:35 A.M., The instance providing access to the database crashes.



At 8:40 A.M., The instance is restarted, and the database files are
              opened as the instance is started:

              The committed values in T are still 101, 102 and 103.

              Since 201, 202, and 203, and 251, 252 and 253
              are not committed, if they are written into the "redo
              log" of the database, there is a need to "roll back"
              the transactions AFTER the "redo log" is applied.

              Since 201, 202, and 203, and 251, 252 and 253
              are not committed, they are in the "undo log"
              of the database.

              The undo log of the database is used BOTH to (1) roll
              back a transaction that is deliberately rolled 
              back in the memory structure of the database instance, 
              and also (2) during the instance recovery at 8:40 A.M.


At 8:41 A.M., The redo log has been applied, and the T table
              contains values 251, 252 and 253 in the instance memory.

              The undo log has not yet been applied.

At 8:42 A.M., The undo log is applied in the reverse order: Uncommitted transaction 300 is undone, and Uncommitted transaction 200 is undone.

Tại sao cả hai giao dịch cam kết và không cam kết được ghi vào tệp nhật ký làm lại? Lý do cho điều này là để cung cấp phục hồi tại thời điểm.

Điều này có nghĩa là nội dung của tệp "làm lại nhật ký" KHÔNG nhất quán giao dịch. Vì lý do này, bất cứ khi nào nhật ký làm lại được sử dụng để áp dụng các giao dịch đã cam kết vào các tệp dữ liệu, "hoàn tác nhật ký" PHẢI C ALNG được sử dụng để khôi phục các giao dịch không được cam kết.

Tại sao các giao dịch trong "nhật ký hoàn tác" được khôi phục theo thứ tự ngược lại? Giao dịch 300 đã thêm 50 vào giá trị hiện tại của mỗi cột của mỗi hàng. Do đó, nếu giao dịch 200 được khôi phục trước, các giá trị sẽ thay đổi từ 251, 252 và 253 thành 201, 202 và 203. Nếu giao dịch 300 sau đó được khôi phục sau cùng, các giá trị sẽ là 151, 152 và 153 - không khớp các giá trị cam kết ban đầu.

NGƯỜI GIỚI THIỆU:

https://asktom.oracle.com/pls/asktom/f?p=100:11 0 ::::P11_QUESTION_ID:1670195800346464273

— AB
nguồn

0

Điều đó vốn không đúng. Rollback có thể chỉ cần áp dụng lại các khối đã được lưu trong bộ đệm trong nhật ký hoàn tác để trạng thái cuối cùng giống như trạng thái ban đầu. Bởi vì nhật ký được viết theo thứ tự chuyển tiếp, tôi đã thực hiện rollback của mình cũng áp dụng theo thứ tự chuyển tiếp. Thứ tự không có vấn đề gì vì rollback sẽ thử lại cho đến khi tệp nhật ký được đánh dấu là đã giải quyết.

— Joshua
nguồn