SCN과 Checkpoint

1. SCN(System Commit Number) 의 정의
 
- commit이 발생할 때 트랜잭션이 부여받는 고유한 번호(=SCN)
- 장애 발생시 복구의 중심!
- instance recovery때나 사용자가 recover명령을 수행할 때 DB에 문제가 있는지 판단하는 지표
- DB를 다시 생성하지 않는 한 RESET(0)되지 않음
- SCN은 크게 SCN base(4 bytes) + SCN Wrap(2 bytes)로 구성되어 있음

SCN 조회법

SQL> select * from v$sysstat where name='calls to kcmgas';
- Sequence에서 발생시키는 것이 아니라 "kcmgas"라는 fuction에서 구현됨
- 발생된 내역에 대한 시간정보 등의 자세한 사항은 smon_scn_time테이블을 조회하면 확인가능
- 다음에 발생될 SCN에 대한 정보는 DML수행 후 v$transaction을 조회하면 됨


2. SCN 기록 솔루션

(1) Control file header
- checkpoint 발생 때
- resetlogs 발생 때
- incomplete recovery 수행 때

(2) Data blocks (cache layer)
- block cleanout시 마지막 scn을 각 block에 기록

(3) Data blocks (ITL entries)
- data block의 transaction layer 안에 있는 ITL(interested transaction list) entries에 commit된 SCN정보를 기록(Delayed block cleanout)

(4) data file headers
 아래의 경우, 모든 데이터 파일 헤더에 SCN을 기록
- 마지막 checkpoint발생 때
- begin backup 수행 때
- 복구가 되었다면 사용자의 마지막 scn을 기록

(5) redo records / log buffer
- commit이 수행되면 commit record에 scn을 포함하여 저장

(6) 그 외 rollback segment(undo segment)와 tablespace headers에도 기록
 

3. 10g R2버전의  commit 관련 파라미터

SQL> show parameter commit;

- commit_point_strength : 분산 DB환경의 2-Phase commit에서 사용
- commit_write
user commit; -> LGWR이 해당 transaction을 redo log file에 기록!

위 내용과 관련된 4가지 방식 중 어떤 조합으로 이용할지를 결정하는 파라미터

(1) WAIT: 변경된 트랜잭션이 redo log file에 기록될때까지 기다림
(2) NOWAIT: redo log file에 기록될때까지 기다리지 않음
(3) IMMEDIATE: commit요청이 들어오면 즉시 redo log file에 기록
(4) BATCH: commit에 요청이 들어오더라도 일정시간 모아 한번에 기록

BATCH나 NOWAIT같이 redo log buffer의 내용이 아직 redo log file에 기록이 완료되지 않아도 다른 작업을 할 수 있게해서 성능을 높이는 방식을 비동기식 커밋(asynchronuos commit)이라고 한다. BUT, 성능은 빠르겠지만 데이터까지 안전하다고 생각하는건 오산!

- max_commit_propagation_delay

RAC환경에서 어떤 데이터가 양쪽 인스턴스에 호출되었다고 가정하였을 때 (각 node1, node2) 오라클에서는 node1에서 발생한 정보를 node2에 전송할 때 piggyback이란 방식으로 전송하는데 이 방식의 특징은 commit이 발생하면 즉시 보내는 것이 아니라 다른 메시지가 갈 때 함께 업혀서 가는 방식이다. 그러다 보니 메시지 발생양은 작고 트래픽 양은 작은 장점은 있으나 틀린 내용을 조회할 수 있다는 심각한 단점이 생김. 그래서 max_commit_propagation_delay 파라미터를 사용해서 전송시간을 제어하게 됨.

10g부터는 이 파라미터의 기본값이 0으로 설정이 되어있다 (commit하면 즉시 전송)
이런 방식을 broadcast on commit(줄여서 BOC) 방식이라고 부름


4. System Change Number

SCN의 또 다른 이름
이것은 datafile, redo log file, control file간의 동기화 정보를 맞추기 위해 사용된다
이 SCN은 scn_base(4 bytes) + scn_wrap(2 bytes) + scn_sequence (1 byte)로 구성되어 있고 sequence는 동일한 scn block을 여러개의 서버프로세스가 동시에 변경할 경우에 이를 구분하게 위해 사용한다.
이 SCN은 Data block header, redo records, segment header에 기록이 된다.


5. Checkpoint


checkpoint란 commit된 데이터를 어디까지 저장했는지 확인하기 위해서 만들어 놓은 개념
data file의 복구를 결정하는 기초적인 정보
control file과 data file의 checkpoint정보를 비교하고 서로 정보가 다르면 틀린 부분을 online redo log나 archived redo log를 참조해서 복구를 하게 됨.

- database / global checkpoint

이 checkpoint가 발생하게 되면 DB buffer cache내에 있는 모든 저장안된 dirty buffer들의 내용을 전부 data file로 저장함
그리고 저장된 scn 중 가장 번호가 큰 scn번호를(=checkpoint scn) control file과 data file header부분에 기록함

- thread checkpoint / logical checkpoint

해당 thread내의 저장되지 않은 모든 dirty buffer들을 data file로 전부 내려씀
이 checkpoint는 log switch가 발생하면 생김
RAC환경일 경우는 각 노드별로 다르게 발생하며 sing instance일 경우는 database checkpoint와 같은역할

- data file checkpoint

특정 data file에만 발생하는 checkpoint
해당 tablespace를 offline한다거나 hot backup수행시에 발생하게 됨
이 checkpoint가 발생하면 해당정보를 control file과 data file header부분에 기록

- mini checkpoint

drop table과 같이 특정한 DDL 발생시 특정 블록에만 발생
 
- recovery checkpoint

데이터파일에 장애가 발생했을 때 db buffer cache에 recovery 할 block을 가져와서 redo change vector를 적용시킴.
그 후 buffer cache에서 변경된 블록을 data file에 저장해야 하는데 이때 발생하는 checkpoint를 recovery checkpoint라고 함

오라클에서는 위와 같이 여러가지 checkpoint의 종류에 우선순위를 두어서 checkpoint를 관리하는데 우선순위가 높은 경우를 fast checkpoint로 분류하고 그 반대는 low checkpoint로 분류를 해서 두 가지가 동시에 발생할 경우 우선순위가 높은 fast checkpoint부터 진행하게 된다.

예) database shutdown, tablespace begin backup, alter system checkpoint 등의 명령어로 발생되는 checkpoint는 fast checkpoint로 분류되며 DB buffer cache내부에 있는 모든 저장안 된 dirty buffer들을 즉시 data file로 저장한다(=full checkpoint) full checkpoint가 발생하면 control file과 data file header에 해당 checkpoint정보를 기록하게 된다.

low checkpoint의 경우에는 checkpoint를 해야 할 block의 목록을 즉시 내려쓰지 못하므로(우선순위가 낮기 때문) queue에 내려쓰게 된다(=Incremental checkpoint)

Oracle7 까지는 저장영역의 목록을 LRUW list로 관리했지만 8버전 이후부터는 checkpoint queue 로 대체된다
checkpoint queue 는 FIFO구조를 가지고 있다

dirty buffer 목록의 길이를 관리하기 위해 Incremental checkpoint가 발생하는 간격을 조절할 수 있도록 Oracle8에서는 DB_BLOCK_MAX_DIRTY_TARGET을 제공했고 8i버전부터는  FAST_START_MRRT_TARGET이 제공되었다

Incremental checkpoint를 하게되면 checkpoint정보를 control file에만 기록하며 data file에는 기록하지 않는다

'ORACLE > Oracle DBMS' 카테고리의 다른 글

DBMS 기본 데이터 타입  (0) 2018.11.02
데이터베이스 객체의 종류  (0) 2018.11.02
SCN과 Checkpoint  (0) 2014.06.12
Redo Log  (0) 2014.06.12
Control File  (0) 2014.06.11
Oracle Character set 에 관하여  (0) 2014.06.10

티스토리 툴바