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가지 방식 중 어떤 조합으로 이용할 지를 결정하는 파라미터
-
- WAIT: 변경된 트랜잭션이 redo log file에 기록될때까지 기다림
- NOWAIT: redo log file에 기록될때까지 기다리지 않음
- IMMEDIATE: commit요청이 들어오면 즉시 redo log file에 기록
- 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된 데이터를 어디까지 저장했는지 확인하기 위해서 만들어 놓은 개념입니다.
그리고 datafile의 복구를 결정하는 기초적인 정보입니다. 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가 발생하는 간격을 조절 할 수 있도록 Oracle 8에서는 DB_BLOCK_MAX_DIRTY_TARGET을 제공했고 8i버전부터는 FAST_START_MRRT_TARGET이 제공 되었습니다.
Incremental checkpoint를 하게되면 checkpoint정보를 control file에만 기록하며 data file에는 기록하지 않습니다.
최신 댓글