9. 오라클 REDO와 UNDO의 동작

• 복구를 위한 기초지식
• 데이터의 보증 메커니즘
• 읽기 일관성

왜 배워야하는가?

• 트랜잭션 특성 ACID 가 있는데 이를 구현하기 위해선 REDO와 UNDO가 빠질 수 없다.
  • Atomicity(원자성): all or nothing
    • 장비가 꺼지더라도 복구 가능하여야함
    • 장비가 꺼져도 복구 가능하다는 건 트랜잭션 중간에 종료된 것은 롤백되어야 할것임
  • Consistency(일관성)
    • 데이터가 A 가 변경되었는데 A 를 포함한 통계에 적용이 안된다는 둥.
  • Isolation(고립성): 트랜잭션끼리는 독립적
    • 고립의 레벨 설정: MySQL 격리 수준 설정
    • 고립 레벨을 어떻게 가져가냐에 따라 I/O 성능을 좌우할 수 있어 어플리케이션 성능과 데이터 정합성에 직접적으로 영향을 끼치기 때문에 가장 중요하지않을까 싶음
  • Durability(지속성)
    • 커밋한 데이터는 지키는 특성
    • 오라클 경우에 메모리에서 DBWR 가 쓰지 못한것은 REDO 로그에 남아 있어야한다는 것을 의미?

지속성 구현

• 지속성 구현을 위해 REDO 로그 이용

Q) 그림 9.4 왜 회전 대기시간이 한 번이지? 어쨌든 추가,변경,삭제를 위해서 실제 데이터 위치로 가기위해 세번돌아야하는 게 아닌지..

REDO 와 UNDO 의 개념

• 누군가 무엇을 했다를 기록한 게 REDO
• 어떻게 하면 과거의 상태로 돌아갈 수 있는지 기록한 게 UNDO

REDO 의 구조

• 데이터 변경이 버퍼 캐시에 일어날떄 REDO와 UNDO 를 서버 프로세스가 생성함
• 커밋이 발생하기전에 디스크에 기록하는 방식
• 이역시 바로 디스크에 기록하는 것은 아니고 REDO 로그 버퍼가 공유 메모리에 존재
• 디스크 기록은 LGWR 라는 프로세스가 수행
• REDO 로그 파일 - 일시적 보관, 아카이브 REDO 로그 파일 - 오래 보관
• REDO 로그 파일은 반드시 다중화 필요

UNDO 의 구조

• 롤백 세그먼트라고도 함
• 세그먼트이므로 테이블스페이스들 중 어딘가에 보관
  • 지난 공부 https://velog.io/@kyukim/oracle7
• 링 버퍼라고 함
• 한 트랜잭션이 한 UNDO 세그먼트 사용하도록 동작하고 필요할때 세그먼트 수를 늘림
• 링버 퍼라고하는데 가장 오래된 UNDO 정보가 덮어쓰고하는 구조

그림 9.9

여러 상황에서 REDO 와 UNDO 동작

롤백할때의 동작

• 롤백이 수행될때 UNDO 를 이용하여 데이터를 원래값으로 되돌림
• 서버프로세스가 비정상적으로 종료하면 PMON 백그라운드 프로세스가 정기적으로 체크 및 종료된 서버 프로세스 정리
• SMON 백그라운드 프로세스가 트랜잭션 시작전 상태로 되돌림

읽기 일관성에 동반되는 동작

• 예를 들어 검색을 해서 한 10초 걸린다면 10초 동안에 검색되는 데이터는 검색을 시작한 시점의 데이터를 보여주도록 하는 것이 읽기 일관성
  • 이 때 UNDO 를 사용

커밋되지 않은 데이터를 읽어올 떄의 동작

• 오라클은 고립성 지키기 위해 레벨을 read committed 로 하도록 설정

ORA-1555

• 스냅샷이 너무 오래되었습니다(Snapshot too old)
  • 과거의 데이터를 보려 했으나 필요한 정보가 이미 없어졌다
• 흠...

체크포인트의 동작

• DBWR 이 디스크에 기록할 때를 말함