디비 아키텍처 - Redo

Redo 로그는 무엇을 담는 로그일까

---

• 데이터파일과 컨트롤 파일에 가해지는 모든 변경사항을 기록함.
• Online Redo 와 Archived Redo 로그로 구성.

Online Redo 와 Archived Redo 가 뭘까…??

---

✅ 1. 온라인 리두 로그 (Online Redo Log)

📌 정의

• 데이터베이스의 변경 사항을 실시간으로 기록하는 파일
• Oracle은 트랜잭션 발생 즉시, 변경 내용을 Redo Log Buffer에 기록하고 → Online Redo Log 파일로 플러시함
• 장애 복구(Crash Recovery) 시 이 파일을 읽어 데이터를 복구함

📁 특징

• 일정 개수의 로그 파일 그룹으로 구성 (ex: redo01.log, redo02.log, ...)
• 순환 구조로 사용됨: 로그 파일이 다 차면 다음 파일로 교체되며 덮어쓰기
• 파일 그룹은 최소 2개 이상 필요

🔁 작동 순서 (예시)

1. 트랜잭션 실행 → Redo 정보 생성
2. Redo Log Buffer에 먼저 기록(리두 로그도 파일 쓰기 전에 버퍼캐시를 사용하네… 다들 캐시쓰네)
3. 커밋되면 Redo Buffer → Online Redo Log 파일로 기록
4. Online Redo Log 파일이 가득 차면 → 다음 그룹으로 Switch(이때 !!! 중요. 가득차면 덮어쓰는데 이때 기존 기록 보존해야하잖슴? 그래서 아카이브 리두 로그에 저장하는거임)

---

✅ 2. 아카이브 리두 로그 (Archived Redo Log)

📌 정의

• 온라인 리두 로그를 덮어쓰기 전에 보존용으로 백업한 파일
• 데이터베이스를 ARCHIVELOG 모드로 설정해야 생성됨
• 보관된 redo 로그로 인해 장애 복구 뿐 아니라 Media Recovery도 가능

📁 특징

• Online Redo Log를 물리적으로 백업해 둔 것
• 물리적으로 별도 디렉토리(예: /oracle/archivelog)에 저장됨
• 일반적으로 백업, PITR(Point-In-Time Recovery), 복제 등에 사용됨
• 삭제는 수동(또는 RMAN을 통한 자동 삭제)

---

📊 두 로그 비교 정리

구분 Online Redo Log Archived Redo Log

생성 시점	트랜잭션 수행 중 즉시	Online 로그가 가득 차서 로그 스위치될 때
보관 기간	순환적으로 덮어쓰기	수동/자동 삭제 전까지 영구 보존
저장 목적	Crash Recovery	Media Recovery, PITR, 백업
필요한 설정	기본	ARCHIVELOG 모드 필요
삭제 여부	자동 덮어쓰기	자동 or 수동 (RMAN)
파일 위치	redo log group에 지정	archive log 저장소 (지정 디렉토리)

---

그러면 롤백할때 redo 로그 사용하는건가?

---

정답은 아니다.

이에 대해서는 undo 로그 를 설명하면서 추가 설명하겟음.

Redo 로그를 사용하는 목적 3가지

---

• 데이터 베이스 리커버리
• 캐시 리커버리
• 패스트 커밋

데이터베이스 리커버리

---

redo 로그는 물리적으로 디스크가 깨지는 등의 media fail 발생 시 데이터베이스를 복구하기 위해 사용.

이때 archived redo 로그 사용.

캐시 리커버리

---

디비에서 사용하는 버퍼 캐시는 휘발성임.

그래서 인스턴스가 비정상적으로 정전이나 이렇게 종료되면 작업내용 날아감.

이때 redo 로그 사용.

장애 이후 재가동하면 redo 로그 읽어서 사고 발생 전까지 수행된 트랜젝션 다시 실행. - 이를 통해 얻을 수 있는것은 버퍼 캐시를 셧다운 전으로 얻을 수 있음.

이후 undo로그를 사용하여 시스템이 셧다운 전에 커밋이 아직 안된 트렌젝션들을 롤백함.

이러면 기존 상태와 동일한 상태가 된다.

패스트 커밋

---

변경된 메모리 블록을 디스크에 기록하는것은 random 엑세스 방식으로 이루어지기 때문에 느리다.

• 여기서 궁금한점.
• 메모리 블록은 해시체인으로 접근하니까 빠른거아님?
• ㄴㄴ
• 버퍼캐시에서 원하는 데이터 찾을때 해시체인으로 접근하니까 빠른거임. 메모리 상에서만.
• 근데 기록하는건 진짜 디스크에 써야하잖음?
• 근데 물리적으로 실제 디스크 보면 원형에 앞뒤로 왓다갓다하면서 끼긱끼긱 대면서 입력됨.
• 근데 그 입력이 앞뒤로 많이많이 왓다갓다하면 안좋겟지?
• 그걸 랜덤 엑세스 방식이라고 하는거고 그래서 느린거다.

자 그래서 느린걸 보완하기위해 변경 사항을 리두 로그 파일에만 저장하고. 나아아아아아아아중에 배치 처리로 리두로그에 있는 정보들을 디스크에 동기화 시킴. (리두 로그파일에만 저장되있으면 언제든 복구가 가능. 데이터에 반영이 아직 안되있어도 그 내역이 남앗기때문 - 언제든 복구 가능한 상태임)

이 매커니즘을 패스트 커밋이라고 한다~~~

그런데 패스트 커밋을 구현하는데 오라클만 가지고 있는 특징적인 기능이 있음. 그건 딜레이드 블록 클린아웃이라고한다. 이건 나중에 설명~

리두 로그 버퍼

---

리두 로그도 바로 쓰기가 되는게 아님 여기도 버퍼가 있음

항상 뭐 저장할때 다들 버퍼사용하네.

리두 로그 버퍼 → 리두 로그에 반영 하는 프로세스가 LGWR 프로세스임.

제일 처음 개념 정리할때 나온 백그라운드 프로세스 종류중 하나 기억하지?

이 LGWR 프로세스가 리두 버퍼를 리두 로그에 기록하는 시점은???!!!

• 3초마다 dbwr 프로세스로부터 신호를 받을때. (dbwr은 더티버퍼를 데이터파일에 기록하기전에 로그 버퍼 내용을 리두 로그 파일에 기록하도록 lgwr에 신호 보냄)
• 로그 버퍼의 1/3이 차거나 기록된 redo 레코드 량이 1mb를 넘을때
• 사용자가 커밋 또는 롤백 명령을 날릴때 ( 영속성을 보장받으려면 최소한 커밋 시점에는 리두 정보가 메모리가 아닌 디스크 상에 존재해야함)

주의 : 꼭 더티버퍼 데이터에 입력하기전에 리두로그 부터 반영해야함. 안그러면 인스턴스 깨졋을때 리두로그에 기록되지 않은 데이터가 들어가있을 수 있음. - 이를 write ahead logging 이라고 한다.