커밋되지 않은 트랜잭션을 역순으로 취소해야하는 이유는 무엇입니까?

일부 트랜잭션이 이기고 (충돌 전에 커밋 됨) 일부가 손실 된 (아직 커밋되지 않은) 데이터베이스 로그가 있습니다. 우리는 패자들의 행동이 거꾸로 되돌려 져야한다는 것을 수업에서 배웠다.

이것을 거꾸로 할 이유가 있습니까? 앞으로 실행 취소가 잘못된 결과를 제공하는 간단한 로그 예를 누구나 볼 수 있습니까?

최초 거래 :

1. 레코드 삽입하십시오 .$r$
2. 일부 필드 를 업데이트하십시오 .$f$$r$

앞으로 실행 취소 :

1. 레코드 삭제 .$r$
2. 업데이트를 로 .-기다리십시오. 더 이상 존재하지 않습니다! 오류가 발생합니다.$r$$r$

DylanSp의 답변에 추가하기 위해 존재하지 않는 레코드의 필드를 업데이트하려고하면 실패하지만 결과는 여전히 예상되는 결과입니다. 레코드 r이 존재하지 않습니다.

그러나 레코드 삭제가 실제로 실패하는 상황을 고려하십시오.

1. 주문 삽입 O.
2. 주문 라인 L을 삽입하십시오.

모든 OrderLine에 해당의가 아니라 비현실적, 가정 해 봅시다 해야한다 주문에 관련 될 수있다.

이제 주문 삭제로 시작된 트랜잭션을 롤백하면 비즈니스 규칙에 위배되므로 실패합니다.

그래서 후

1. 주문 삭제 O. (FAIL)
2. Ordeline L을 삭제하십시오. (성공)

우리는 기존 주문 (주문없이)으로 끝날 수 있습니다.

물론이 경우 계단식 삭제를 사용할 수 있지만 2 단계 (영향없이)가 실패한다는 의미입니다. 게다가 주문에 대해 계단식 삭제를 구현하는 것은 원하지 않는 동작 일 수 있습니다.

비유로 가자. 저녁 식사를하러 가겠다 고 말하자.

1. 양말을 신 으세요.
2. 신발을 신 으세요.
3. 일어나
4. 문으로 걸어가십시오.

그런 다음 전화를받습니다. 저녁 식사 계획이 취소되었습니다.

1. 양말을 벗으십시오.
2. 신발을 벗으십시오.
3. 앉아.
4. 문에서 멀어 지십시오.

거기에 문제가 있습니다. 넘어져 다칠 수 있습니다. 또는 이후의 작업이 먼저 실행 취소되기 전에는 일부 작업을 실행 취소 할 수 없다는 것을 알고있을 것입니다.

마지막으로 수행 한 작업을 취소하면 마지막 단계에서 다음 단계가 발생한 시점으로 돌아갑니다. 그런 다음 해당 단계를 실행 취소하고 아무 것도 남지 않을 때까지 뒤로 이동하여 반복하십시오. 다른 한편으로, 제 1 단계를 반전시키는 것은 이후 단계 이후의 상태에서 가능하지 않을 수있다.

수학적으로 말하면 : 작업이 출퇴근하지 않을 수 있으므로 어떤 단계를 처음 또는 두 번째로 수행해야하는지에 따라 단계를 실행 취소하는 순서가 중요합니다.

이것은 트랜잭션이 서로 위에 구축되고 트랜잭션의 결과가 커밋되기 전의 상황에 크게 의존하기 때문에 옳습니다.

금융 거래를 살펴 보자.

(처음 거래가 a100 USD를 빚 지기 전에 )

1. a 빚진 100 USD (현재 총 부채 200)
2. a그가 나에게 빚진 것에 대해 10 % 할인을받습니다. (현재 총 부채 180)

두 거래를 취소하고 싶다고 가정 해 봅시다.

첫 번째를 취소하면 다음과 같이 끝납니다.

1. 낮은 부채 100 (현재 부채 80)
2. 10 % 할인 취소 (현재 부채 80 / 0.9 = 88)

이것은 잘못입니다. 우리는 100의 부채로 돌아 가야합니다. 거래를 역순으로 취소하면 맞습니다.

1. 할인 취소-이제 부채는 200입니다
2. 낮은 100 부채-이제 부채는 100입니다

하나의 열만있는 테이블 T가 있다고 가정하십시오.

"실행 취소 로그"는 커미트되지 않은 트랜잭션을 포함하는 데이터베이스 파일이고 "다시 실행 로그"는 아직 데이터 파일에 적용되지 않은 커미트되지 않은 트랜잭션과 커미트 된 트랜잭션을 모두 포함하는 데이터베이스 파일이라고 가정하십시오.

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.

              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.

              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.

커밋되고 커밋되지 않은 트랜잭션이 리두 로그 파일에 기록되는 이유는 무엇입니까? 그 이유는 특정 시점 복구를 제공하기위한 것입니다.

이것은 "재실행 로그"파일의 내용이 트랜잭션과 일치하지 않음을 의미합니다. 이러한 이유로, 리두 로그를 사용하여 커밋 된 트랜잭션을 데이터 파일에 적용 할 때마다 커밋되지 않은 트랜잭션을 롤백하는 데에도 "실행 취소 로그"를 사용해야합니다.

"실행 취소 로그"의 트랜잭션이 역순으로 롤백되는 이유는 무엇입니까? 트랜잭션 (300)은 각 행의 각 열의 기존 값에 50을 추가했다. 따라서 트랜잭션 200이 먼저 롤백되면 값이 251, 252 및 253에서 201, 202 및 203으로 변경됩니다. 트랜잭션 300이 마지막으로 롤백 된 경우 값은 151, 152 및 153이됩니다. 커밋 된 원래 값

참조 :

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

본질적으로 사실이 아닙니다. 롤백은 단순히 실행 취소 로그에 캐시 된 블록을 다시 적용하여 최종 상태가 초기 상태와 동일하도록 할 수 있습니다. 로그가 전달 순서대로 작성되었으므로 롤백도 전달 순서로 적용했습니다. 로그 파일이 정산 된 것으로 표시 될 때까지 롤백이 재 시도되므로 순서는 중요하지 않습니다.