Redo Log files

Redo Log files

- 오라클 서버는 데이터가 변경될 경우 장애를 대비해 변경되기 전의 내용과 변경된 후의 내용을 기록해 둠

- 기록되는 장소 중 메모리는 Redo Log Buffer

- 기록되는 장소 중 파일은 Redo Log File

 

1. Redo Log 생성 원리

· Write Log Ahead

  - 데이터를 변경하기 전에 Redo Log에 먼저 기록 후 데이터를 변경 (LGWR 작동 후 DBWR 작동)

· Log Force at commit

  - 사용자로부터 Commit 요청이 들어오면 관련된 모든 Redo Recode들을 redo Log file에 저장한 후 Commit을 완료

  - 대량의 데이터 변경 후 commit이 한꺼번에 수행 시 성능이슈(부하가 걸림)

 

STEP1)

  · 사용자가 특정 데이터 변경을 요청하는 쿼리를 수행하면, 해당 SQL을 받은 서버프로세스는 원하는 Block이 DB Buffer cache에 있는지 확인,

   없는 경우 Data File에서 읽어와 메모리에 올림

  · 해당 Block을 다른 사람이 바꿀 수 없도록 Lock을 설정한 후 PGA Redo Change Vector 생성

  · Redo Change Vector : 세션에 대한 모든 변경사항을 저장하는 PGA 영역

STEP2)

  · 서버프로세스는 PGA Change Vector를 생성한 후 Redo Log Buffer에 복사하기 위해 필요한 용량을 계산

  · PGA에 생성된 Change Vector를 redo log buffer에 복사하기 위해 Redo copy Latch를 획득해야 함

  · Redo copy latch는 Change Vector가 모두 Redo Log buffer에 기록될 때까지 계속 유지됨

  · Redo copy latch는 여러 개가 존재하며 기본 값은 CPU개수 * 2 (_log_simultaneous_copies로 변경가능)

STEP3)

  · Redo Copy Latch를 확보한 서버 프로세스는 Redo Log buffer에 내용을 기록하기 위해 Redo Allocation Latch를 확보

  · 8i버전까지는 Redo Allocation Latch는 1개 밖에 없어서 데이터 변경이 많이 되는 서버일 경우 Redo Allocation Latch를 확보하기 위해

   많은 경합 발생

  · 9i버전부터 Redo Log Buffer를 여러 개의 공간으로 나누어서 각 공간별로 Redo Allocation latch를 할당해주는

    Shared Redo strand라는 기능이 도입

STEP4)

  · Redo Log Buffer에 기록된 내용들은 특정상황이 되면 LGWR이 일부를 Redo Log File에 기록한 후

   기록된 Redo Entries들은 Redo Log Buffer에서 삭제

  · Server Process는 Redo Writing Latch를 확보한 후 Redo Log Buffer에 있는 내용을 Redo Log File에 기록하라고 요청

 

2. Redo Log File 구성

- Redo Log File은 그룹과 멤버라는 개념으로 관리

- 최소 그룹의 개수는 2개이며, 그룹별로 필요한 최소 Member 수는 1개

- 같은 그룹의 Member는 같은 내용 저장

- Member를 많이 추가하면 안정적일 수는 있지만, 기록시간이 커서 부하를 줄 수 있음

- 같은 그룹의 멤버는 서로 다른 디스크에 저장되는 것을 권장

- 그룹에 멤버가 여러 개일 경우 병렬로 동시에 같은 내용을 기록하는데 멤버가 같은 디스크에 존재한다면

직렬로 기록하게 된다.

 

- LGWR이 Redo Log Buffer의 내용을 Redo Log File에 내려 쓰다가 해당 파일이 가득 차게 되면

Log Switch가 발생하여 자동으로 다음 그룹으로 넘어감

- Log Switch가 발생하게 되면 Checkpoint 신호가 발생

- Log Switch가 일어나는 그룹의 순서는 Oracle이 라운드 로빈 방식으로 결정

- Redo Log File크기가 너무 작을 경우 LOG SWITCH가 자주 발생하여 성능저하가 될 수 있고,

너무 크면 데이터의 손상 가능성이 커지므로 적절하게 설정 필요

 

◆ 빈번한 Log Switch와 관련된 에러

- checkpoint not completed -----> Redo log size를 올린다

· Log Switch가 너무 빈번하게 일어날 경우 DBWR이 이전에 발생한 Check point 내용을 Data file에 다 기록을 못한 상태에서

다시 Log Switch가 발생하여 checkpoint 신호가 들어올 경우 발생

 

Redo Log File 상태

- CURRENT : LGWR이 내용을 기록하고 있는 상태

- ACTIVE : Redo log file의 내용이 아직 DB Buffer Cache에서 Data file로 저장이 안되서

지워지면 안 되는 상태(checkpoint 발생 후 inactive로 변경 됨)

- INACTIVE : Redo log file의 내용이 Data file로 저장되어 삭제되어도 된다는 의미

 

*참조 뷰, 쿼리

select * from v$log;

select * from v$logfile;

select a.group#, a.member, b.bytes/1024/1024 MB, b.sequence# "SEQ#", b.status, b.archived "ARC"

from v$logfile a, v$log b

where a.group#=b.group#

order by 1,2;

 

alter system switch logfile; -- redo 스위칭

alter system checkpoint; -- 체크포인트신호 강제 주입

 

3. Redo Log File 관리

--group 추가

alter database add logfile group 4

'/oracle11/oracle/oradata/testdb/redo04.log' size 50M;

* 이미 생성된 파일명은 시스템에서 지우기전에는 재생성 불가능

* 사이즈 지정 안 할시 기존 것과 똑같이 설정

 

--member 추가

alter database add logfile member

'/oracle11/oracle/oradata/testdb/redo04_b.log' to group 4;

 

--member 삭제

alter database drop logfile member

'/oracle11/oracle/oradata/testdb/redo04_b.log' ;

* ACTIVE , CURRENT 상태에서는 삭제 불가능 -> 스위칭, 체크포인트 발생시켜야함

alter database drop logfile group 4;

 

4. SCN

- 사용자가 Commit을 수행하게 되면, Oracle은 내부적으로 SCN이라는 고유번호를 생성해서 트랜잭션을 관리하게 된다.,

- 이러한 SCN 번호를 통해 트랜잭션을 관리하면서, 장애 발생 시 복구 한다.

- System Commit Number(SCN)

· Recover 시 Oracle은 SCN 정보를 사용하여 데이터베이스에 문제가 있는지 판별하고, 문제가 있다고 판단되는 경우 복구를 수행

· SCN번호는 DML문장 단위가 아니라 트랜잭션 단위로 할당

SCN 기록 되는 곳

1) Control File

- Check point 발생했을 때

- Reset Log 발생했을 때

- Incomplete Recovery 수행 때

2) Data blocks

- Block Cleanout시 마지막 SCN을 각 Block에 기록

3) Data File Headers

- 모든 파일의 헤더에 아래의 경우 SCN을 기록한다.

· 마지막 Check Point 발생 시

· Begin Backup 수행 때

· 복구가 되었다면, 사용된 마지막 SCN을 기록한다.

4) Redo Records, Log Buffer

- Commit이 수행되면 Commit Record에 SCN을 포함하여 저장함

5) Undo Segment와 Tablespace Headers에도 기록이 된다.

 

5. CHECKPOINT

- Commit된 데이터를 어디까지 저장했는지 확인하기(SCN으로 확인) 위해서 만들어 놓은 개념

ex) SCN이 100번까지 Commit되었고, CheckPoint 정보가 90번이라면 SCN 90번 트랜잭션까지 데이터 파일에 저장 되었다고 확인

-->　91번부터 100번까지의 정보는 redo에서 리 트랜잭션을 시켜줌

- Datafile의 복구를 결정하는 기초적인 정보로써 Control File과 Data File의 Check Point 정보를 비교하고

서로 정보가 다르면 틀린 부분을 Online Redo나 Archived Redo Log를 참조해서 복구

1) Database / Global Checkpoint ( DB를 내릴 때 발생 )

- DB Buffer Cache내에 있는 모든 저장 안 된 Dirty Buffer들의 내용을 전부 데이터 파일로 저장

- 저장된 SCN 중 가장 큰 SCN번호를 Control File과 Data File Header부분에 기록

2) Thread Checkpoint / Logical Checkpoint

- 해당 Thread 내의 저장되지 않은 모든 Dirty Buffer들을 Datafile로 내려 쓴다

- Log Switch가 발생 시 생김

- RAC환경일 경우 각 노드 별로 다르게 발생

3) Datafile Checkpoint

- 특정 데이터파일에만 발생하는 Check Point

- 해당 테이블스페이스를 offline, begin backup시 발생 ( 테이블 스페이스 단위로 작업 )

- 이 체크포인트 발생하면 해당 정보를 Control File과 데이터 파일 헤더 부분에 기록

4) Mini Checkpoint

- Drop Table과 같이 특정한 DDL 발생 시 특정 블록에만 발생 하는 Checkpoint

5) Recovery Checkpoint

- 데이터 파일에 장애가 발생 했을 때 백업된 데이터파일 복원 시 Recovery된 블록을 데이터 파일에 저장해야 하는데

이때 발생하는 CheckPoint를 Recovery Check Point라고 함