SCN 과 CHECK POINT

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

1.3 오라클 기동시 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

1.4 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 값은 무한대를 가짐.

1.5 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에도 기록

Commit과 관련된 파라미터(10g 기준)

SQL> show parameter commit;

                       NAME                             TYPE           VALUE
------------------------------------- ----------- -----------------
commit_point_strength                               integer           1
commit_write                                           string
max_commit_propagation_delay                  integer           0

commit_point_strength : 분산 데이터베이스 환경에서 2-Phase Commit에 사용
commit_write : 사용자가 commit을 하게 되면 LGWR이 해당 트랜잭션을 Redo Log File에 기록

오라클 커밋(commit) 방법

WAIT(Default) : LGWR가 로그버퍼를 파일에 기록했다는 완료 메시지를 받을 때까지 대기하며, 그 동안 log_file_sync 대기 이벤트가 발생한다(동기식 커밋).
NOWAIT : LGWR의 완료 메시지를 기다리지 않고 바로 다음 트랜잭션을 진행하므로,log file sync 대기 이벤트가 발생하지 않음(비동기식 커밋).
IMMEDIATE(Default) : 커밋 명령을 수행 즉시 LGWR가 로그 버퍼를 파일에 기록 한다 .
BATCH : 세션 내부에 트랜잭션 데이터를 일정량 버퍼링했다가 일괄 처리한다.

SQL> COMMIT WRITE IMMEDIATE WAIT ;   -- 1)
SQL> COMMIT WRITE IMMEDIATE NOWAIT ; -- 2)
SQL> COMMIT WRITE BATCH WAIT ;       -- 3)
SQL> COMMIT WRITE BATCH NOWAIT ;     -- 4)

"2)" 방법이 "1)" 방법에 비해 약 7배 정도 성능 향상 됨.
주의) 지금까지 사용해 오던 커밋(immediate wait)은 트랜잭션 데이터가 데이터베이스에 안전하게 저장됨을 보장함.
하지만 비동기식 커밋 옵션을 사용하면， 트랜잭션 커밋 직후 인스턴스에 문제가 생기거나 Redo 로그가 위치한 파일 시스템에 문제가 생겨 쓰기 작업을 진행할수 없게 되면 커밋이 정상적으로 완료되지 못할수도 있음

트랜잭션에 의해 생성되는 데이터 중요도에 따라 활용 여부를 결정해야 함.
commit_write 파라미터를 이용해 시스템 또는 세션레벨에서 기본 설정 변경 가능.

1.6 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 방식이라고 함)

2 체크포인트 (CheckPoint)[편집]

2.1 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를 참조해서 복구

2.1.1 Database / Global Checkpoint[편집]

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

2.1.2 Thread Checkpoint / Logical Checkpoint[편집]

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

2.1.3 Data File Checkpoint[편집]

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

2.1.4 Mini Checkpoint[편집]

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

2.1.5 Recovery Checkpoint[편집]

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

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

패스트 체크포인트 란?

Database Shutdown, Tablespace Begin Backup, Alter System Checkpoint 등의 명령어로 발생되는 Checkpoint는 Fast Checkpoint로 분류되어
DB Buffer Cache 내부에 잇는 Dirty Buffer들을 즉시 데이터 파일로 저장(=Full Checkpoint), Control File / Data File Header에 기록 함
우선 순위가 낮은 경우는 Checkpoint를 해야 할 Block의 목록을 즉시 데이터 파일로 내려 쓰지 않고 어딘가 기록해 둔 후 Background로 내려씀(=Incremental Checkpoint, 증분 체크포인트)