SCN 과 CHECK POINT

SCN 과 체크 포인트

사용자가 Commit을 하게 되면 Oracle 내부적으로 SCN 번호를 생성해서 트랜잭션을 관리

SCN(System Change Number, System Commit Number)

SCN 이란?

Commit 할 때 생성되는 번호, 트랜잭션을 관리하며 장애 발생 시 복구도 함
Commit이 발생 할 때마다 모든 트랜잭션에 고유한 SCN 번호가 부여됨 (트랜잭션 단위로 할당)
SCN = SCN base(4bytes) + SCN Wrap(2bytes)
SCN base 값이 전부 다 사용되면 SCN Wrap 값이 하나씩 증가되어 사용하게 됨
만약 이 SCN이 모두 다 사용되면 다시 0으로 reset 된 후 새로운 Incarnation으로 할당되어 다시 시작
SCN은 Sequence에서 발생시키는 것이 아니라 Steve adams가 개발한 ‘Kcmgas’라는 Function으로 구현

오라클 기동시 SCN 동기화

SCN은 datafile, redolog file, control file간의 동기화 정보를 맞추는 용도로써 사용 됨
SCN이 다르면 DB가 기동 되지 않음.
1. 오라클은 Startup 후 mount 에서 open 시점에 컨트롤 파일의 SCN과 데이터파일의 SCN을 비교한다.
2. 만약 다르다면 Redolog file이나 archive log file에서 찾아, 낮은 번호의 SCN부터 차례대로 복구를 수행함.

예시) 컨트롤 파일 재생성 후 SCN비교

SQL> select checkpoint_change# from v$database; 

CHECKPOINT_CHANGE#
------------------
                 0
                 
                 
SQL> select name,checkpoint_change# from v$datafile;   

NAME                                                CHECKPOINT_CHANGE#
--------------------------------------------------- -------------------
/app/oracle/cfgtoollogs/orcl/system01.dbf                      5647538
/app/oradata/dbms_data001.dbf                                  5647538
/app/oracle/cfgtoollogs/orcl/sysaux01.dbf                      5647538
/app/oracle/cfgtoollogs/orcl/undotbs01.dbf                     5647538
/app/oracle/cfgtoollogs/orcl/example01.dbf                     5647538
/app/oracle/cfgtoollogs/orcl/users01.dbf                       5647538

SCN 종류

여러 종류의 SCN이 존재함

SCN 종류	설 명
current SCN	시스템의 현재 SCN
system checkpoint SCN	마지막 checkpoint 시점의 SCN
controlfile checkpoint SCN	컨트롤파일에 있는 데이터파일의 SCN
datafile checkpoint SCN	데이터파파일에 있는 SCN
start SCN	checkpoint가 종료될 때 데이터파일의 헤더 부분에 기록되는 SCN
stop SCN	DB가 운영 중이면 stop SCN 값은 null임. DB를 정상 종료할 경우 .stop SCN은 start SCN과 같은 값을 가짐. 만약 abort 옵션으로 DB를 내리게 된다면 stop SCN 값은 무한대를 가짐.

SCN이 저장 되는 곳

Control File Header
```
select checkpoint_change# from v$database; -- #컨트롤파일에 저장된 SCN 조회
```
- Checkpoint 발생 할 때

- Resetlogs 발생 할 때

- Incomplete Recovery 수행 할 때
Data Blocks(Cache Layer)
- Block Cleanout 시 마지막 SCN을 각 Block에 기록
Data Blocks(ITL Entries)
- Data Block의 Transaction Layer 안에 있는 ITL(Interested Transaction List) Entries 안에 Commit 된 SCN 정보를 기록(Delayed Block Cleanout).
Data File Headers(모든 데이터 파일 헤더에 기록)
```
select name,checkpoint_change# from v$datafile;
```
- 마지막 Checkpoint 발생 때
- Begin Backup 수행 때
- 복구가 되었다면 사용된 마지막 SCN을 기록
Redo Records / Log Buffer
– Commit이 수행되면 Commit Records에 SCN을 포함하여 저장
그 외 Rollback Segment(Undo Segment)와 Tablespace Headers에도 기록

틀:고지상자2

Commit 관련된 파라미터 (11g)

SQL> show parameter commit;

                   NAME                                 TYPE                     VALUE
------------------------------------ ----------- ------------------------------
commit_logging                                      string
commit_point_strength                             integer                         1
commit_wait                                           string
commit_write                                          string

SQL> alter system set commit_logging = immediate ;
System altered.

SQL> alter system set commit_wait = nowait ;
System altered.

SQL> alter system set commit_write = immediate, nowait;
System altered.

SQL>  show parameter commit ;

                   NAME                                 TYPE                     VALUE
------------------------------------ ----------- ------------------------------
commit_logging                                      string              IMMEDIATE
commit_point_strength                             integer            1
commit_wait                                           string             NOWAIT
commit_write                                          string             IMMEDIATE, NOWAIT

- max_commit_propagation_delay : (RAC 환경으로 가정하고 설명)

만약 홍길동이라는 데이터를 양쪽 노드에서 다 호출한 후 node 1에서 일지매로 업데이트 한 후에 commit 하고

commit과 거의 동시에 node2에서 누군가 홍길동 정보를 조회했다고 가정하면 분명히 node 1에서 홍길동 정보를

일지매로 변경 후에 Commit 했기 때문에 node 2에서는 홍길동이 아닌 일지매로 보여야 할 것이다.

그러나 아직 node 1에서 commit 된 정보가 node 2에 도달하지 않으면 node 2에서는 잘못된 정보를 볼 수 있는

문제가 발생

⇒ Oracle 에서는 node 1에서 발생한 정보를 node 2에 전송할 때 Piggyback이란 방식으로 전송

- Piggyback : Commit이 발생하면 즉시 보내는 것이 아니라 다른 메시지가 갈 때 함께 업혀서 가는 방식

⇒ 메시지 발생양은 작고 트래픽 양은 작은 장점이 있으나 틀린 내용을 조회할 수 있다는 단점

→ max_commit_propagation_delay 파라미터를 사용해서 전송시간을 제어 함

※ 10g부터는 이 파라미터의 기본 값이 0으로 설정되어 무조건 commit을 하자마자 전송을 하도록 설정

       (이러한 방식을 Broadcast On Commit, BOC 방식이라고 함)

체크포인트 (CheckPoint)

CheckPoint란 ?

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

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

DB Buffer Cache의 변경된 Dirty Buffer들을 Data File로 저장하는 것을 Checkpoint라고 함
Control File 과 Data File의 Checkpoint 정보를 비교하여 서로 정보가 다르면 다른 부분을 Online Redo Log 나 Archived Redo Log를 참조해서 복구

Database / Global Checkpoint

Checkpoint가 발생하면 Buffer Cache에 있는 모든 저장 안 된 Drity Buffer들의 내용을 전부 데이터 파일로 저장,
저장된 SCN 중 가장 번호가 큰 SCN 번호(Checkpoint SCN)를 Control File과 Data File Header 부분에 기록

Thread Checkpoint / Logical Checkpoint

해당 Thread 내의 저장되 않은 모든 Dirty Buffer들을 Data File로 전부 내려 씀.
이 Checkpoint는 Log Switch가 발생하면 생김, RAC 환경일 경우 각 노드별로 다르게 발생
Single Instance 일 경우 Database Checkpoint와 같은 역할

Data File Checkpoint

특정 데이터 파일에만 발생하는 Checkpoint
해당 Tablespace를 Offline 한다거나, Begin Backup 수행 시 발생
이 Checkpoint가 발생하면 해당 정보를 Control File과 Data File Header 부분에 기록

Mini Checkpoint

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

Recovery Checkpoint

데이터 파일에 장애가 발생했을 때 백업된 데이터 파일 복원 후 Redo Change Vector를 적용시키게 됨,
그 후 Recovery된 블록을 데이터 파일에 저장해야 하는데 이때 발생하는 Checkpoint를 말함

Oracle은 우선순위를 두어서 Checkpoint를 관리 함
- 우선 순위가 높을 경우 Fast Checkpoint,
- 우선 순위가 낮을 경우 Low Checkpoint로 분류
- 두 가지가 동시에 발생 할 경우 Fast Checkpoint부터 진행

틀:고지상자2