4._Redo
2012.03.11 22:22
- Redo 로그
- 데이터 파일과 컨트롤 파일에 가해지는 모든 변경사항을 하나의 Redo로그 엔트리로 저장하는 것
- Online Redo
- Redo 로그 버퍼에 버퍼링된 로그 엔트리를 기록하는 파일 최소 두개이상
- 라운드로빈 방식 (마지막 사용후 첫번째 사용)
- Archived(Offline) Redo : Online Redo 로그가 재사용되기 전에 백업해둔 파일
- Redo 로그의 목적
- 1. Database Recovery
- Media Recovery, 물리적 디스크 복구 Archive Redo 로그 이용
- 2. Cache Recovery (Instance Recovery 시 roll forward 단계)
- - Instance Recovery , 버퍼 캐시의 휘발성을 대비하기위해 트랜잭션 데이터의 유실에 대비하기 위해 Redo 로그를 사용
- Instance Carash 발생후 재기동하면 마지막 checkpoint 이후부터 발생직전까지의 트랜잭선을 재현하여 버퍼캐시를 시스템 셧다운 이전 상태로 복구 하고 이후 Undo 데이터를 이용해 커밋되지 않은 데이터를 롤백 (Transaction Recovery) 진행-> Roll forward 와 rollback 단계를 모두 완료하면 동기화(다운전상태로) 완료
- 3. Fast Commit
- - 변경된 메모리 블록을 디스크상에 기록할대는 random access가 발생하여 느리지만 Append 방식인 로그에 우선 기록하면 빠르게 저장가능 이후 DBWR,CHECKPINT를 이용해 나중에 BATCH 방식으로 일괄 수행
- 오라클 뿐아니라 다른 DBMS 공통적인 사항이지만 오라클은 Delayed 블록 클린아웃을 사용
- Delayed 블록 클린아웃 - Undo 세그먼트 헤더의 트랜잭션 테이블에만 커밋 정보록 기록하고 블록 클린 아웃은 이후 수행 -> 8절
- Redo 기록
- 데이터 블륵 버퍼를 변경하기 전에 Redo 로그 버퍼에 먼저 기록
- LGWR 프로세스에 의해 Redo 로그 버퍼에 있는 내용을 Redo 로그 파일에 기록
- 1. 3초마다 DBWR 프로세스로 신호를 받을때
- DIRY 버퍼를 기록하기전에 LGWR에게 신호를보내 Redo 엔트리를 Redo 로그에 기록
- Write Ahead Logging
- 2. 로그 버퍼의 1/3이 차거나 기록된 Redo 레코드량이 1MB를 넘을때
- 3. 사용자가 커밋 또는 롤백 명령을 보낼때
- Fast Commit 메커니즘
1) 사용자 Commit
2) LGWR은 커밋 레코드를 Redo 로그 버퍼에 기록
3) 트랜잭션 로그 엔트리와 함께 redo 로그파일에 저장
4) 커밋 수행한 트랜잭션에 ‘success code’를 리턴
2) LGWR은 커밋 레코드를 Redo 로그 버퍼에 기록
3) 트랜잭션 로그 엔트리와 함께 redo 로그파일에 저장
4) 커밋 수행한 트랜잭션에 ‘success code’를 리턴
- 사용자가 커밋 또는 롤백할 때마다 log file sync라는 대기 이벤트가 발생
- LGWR 프로세스가 로그 버퍼 내용을 Redo 로그 파일에 기록할때 까지 프로세스가 대기하는 현상때문에 발생
- 오라클 고도화 원리와 해법 1 (bysql.net 2012년 1차 스터디)
- 작성자: 남송휘 (tofriend)
- 최초작성일: 2012년 3월 11일
- 본문서는 bysql.net 스터디 결과입니다 .본 문서를 인용하실때는 출처를 밝혀주세요. http://www.bysql.net
- 문서의 잘못된 점이나 질문사항은 본 문서에 댓글로 남겨주세요. ^^
댓글 0
번호 | 제목 | 글쓴이 | 날짜 | 조회 수 |
---|---|---|---|---|
26 | 3._SQL트레이스 | sapius | 2012.04.03 | 37297 |
25 | 8._Statspack_AWR | 시와처 | 2012.04.01 | 11767 |
24 |
7._Response_Time_Analysis_방법론과_OWI
![]() | 시와처 | 2012.04.01 | 5916 |
23 | 6._V$SYSTEM_EVENT | 시와처 | 2012.04.01 | 3507 |
22 | 4._동시성_구현_사례 [1] | dasini | 2012.03.26 | 11962 |
21 |
5._오라클_Lock
![]() | 시와처 | 2012.03.25 | 12875 |
20 | 3._비관적_vs._낙관적_동시성_제어 | dasini | 2012.03.25 | 6396 |
19 | 2._AutoTrace | 남송휘 | 2012.03.25 | 3138 |
18 | 1._Explain_Plan | 남송휘 | 2012.03.25 | 4543 |
17 | 3장._오라클_성능_관리 | 남송휘 | 2012.03.25 | 3117 |
16 |
2._트랜잭션_수준_읽기_일관성
![]() | AskZZang | 2012.03.20 | 6364 |
15 | 1._트랜잭션_동시성_제어 | AskZZang | 2012.03.19 | 4883 |
14 | 11._Shared_Pool | 박영창 | 2012.03.19 | 3395 |
13 | 10._대기_이벤트 | 박영창 | 2012.03.18 | 10624 |
12 | 9._Snapshot_too_old | 박영창 | 2012.03.18 | 9969 |
11 | 8._블록_클린아웃 | 시와처 | 2012.03.18 | 12305 |
10 |
7._Consistent_vs._Current_모드_읽기
![]() | 시와처 | 2012.03.18 | 5708 |
9 | 2장._트랜잭션과_Lock | AskZZang | 2012.03.16 | 5462 |
8 |
6._문장수준_읽기_일관성
![]() | 정찬호 | 2012.03.11 | 57563 |
» |
4._Redo
![]() | 남송휘 | 2012.03.11 | 5606 |