9. 오라클 REDO와 UNDO의 동작
- 복구를 위한 기초지식
- 데이터의 보증 메커니즘
- 읽기 일관성
왜 배워야하는가?
- 트랜잭션 특성 ACID 가 있는데 이를 구현하기 위해선 REDO와 UNDO가 빠질 수 없다.
- Atomicity(원자성): all or nothing
- 장비가 꺼지더라도 복구 가능하여야함
- 장비가 꺼져도 복구 가능하다는 건 트랜잭션 중간에 종료된 것은 롤백되어야 할것임
- Consistency(일관성)
- 데이터가 A 가 변경되었는데 A 를 포함한 통계에 적용이 안된다는 둥.
- Isolation(고립성): 트랜잭션끼리는 독립적
- 고립의 레벨 설정: MySQL 격리 수준 설정
- 고립 레벨을 어떻게 가져가냐에 따라 I/O 성능을 좌우할 수 있어 어플리케이션 성능과 데이터 정합성에 직접적으로 영향을 끼치기 때문에 가장 중요하지않을까 싶음
- Durability(지속성)
- 커밋한 데이터는 지키는 특성
- 오라클 경우에 메모리에서 DBWR 가 쓰지 못한것은 REDO 로그에 남아 있어야한다는 것을 의미?
지속성 구현
Q) 그림 9.4 왜 회전 대기시간이 한 번이지? 어쨌든 추가,변경,삭제를 위해서 실제 데이터 위치로 가기위해 세번돌아야하는 게 아닌지..
REDO 와 UNDO 의 개념
- 누군가 무엇을 했다를 기록한 게 REDO
- 어떻게 하면 과거의 상태로 돌아갈 수 있는지 기록한 게 UNDO
REDO 의 구조
- 데이터 변경이 버퍼 캐시에 일어날떄 REDO와 UNDO 를 서버 프로세스가 생성함
- 커밋이 발생하기전에 디스크에 기록하는 방식
- 이역시 바로 디스크에 기록하는 것은 아니고 REDO 로그 버퍼가 공유 메모리에 존재
- 디스크 기록은 LGWR 라는 프로세스가 수행
- REDO 로그 파일 - 일시적 보관, 아카이브 REDO 로그 파일 - 오래 보관
- REDO 로그 파일은 반드시 다중화 필요
UNDO 의 구조
- 롤백 세그먼트라고도 함
- 세그먼트이므로 테이블스페이스들 중 어딘가에 보관
- 링 버퍼라고 함
- 한 트랜잭션이 한 UNDO 세그먼트 사용하도록 동작하고 필요할때 세그먼트 수를 늘림
- 링버 퍼라고하는데 가장 오래된 UNDO 정보가 덮어쓰고하는 구조
그림 9.9
여러 상황에서 REDO 와 UNDO 동작
롤백할때의 동작
- 롤백이 수행될때 UNDO 를 이용하여 데이터를 원래값으로 되돌림
- 서버프로세스가 비정상적으로 종료하면 PMON 백그라운드 프로세스가 정기적으로 체크 및 종료된 서버 프로세스 정리
- SMON 백그라운드 프로세스가 트랜잭션 시작전 상태로 되돌림
읽기 일관성에 동반되는 동작
- 예를 들어 검색을 해서 한 10초 걸린다면 10초 동안에 검색되는 데이터는 검색을 시작한 시점의 데이터를 보여주도록 하는 것이 읽기 일관성
커밋되지 않은 데이터를 읽어올 떄의 동작
- 오라클은 고립성 지키기 위해 레벨을 read committed 로 하도록 설정
ORA-1555
- 스냅샷이 너무 오래되었습니다(Snapshot too old)
- 과거의 데이터를 보려 했으나 필요한 정보가 이미 없어졌다
- 흠...
체크포인트의 동작