6. Redo Log 관리하기 - SCN과 Checkpoint

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

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

1. System Commit Number(SCN)

- Instance Recovery 때나 사용자가 Recover 명령을 수행할 때 Oracle은 SCN 정보를 사용하여 데이터베이스에 문제가 있는지 판별하고, 문제가 있다고 판단되는 경우 복구를 수행한다.

- Commit을 수행할 때마다 모든 트랜잭션에 고유한 SCN 번호가 부여된다.

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

- SCN은 SCN Base + SCN Wrap으로 구성되어있다. SCN Base 값이 전부 다 사용되면, SCN Wrap 값이 하나씩 증가되게된다.

- SCN은 Sequence에서 발생시키는게 아니라, kcmgas라는 Function으로 생성된다.

1-1.SCN 기록되는곳.

1) Control File

- Check point 발생했을 때

- Reset Log 발생했을 때

- Incomplete Recovery 수행 때

2) Data blocks(Cache Layer)

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

3) Data Blocks(ITL Entries)

- Data block의 Transaction Layer 안에 있는 ITL Entries(Interested Transaction List Entries)에 Commit된 SCN 정보를 기록한다(Block Clean Out).

4) Data File Headers

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

 * 마지막 Check Point 발생 시

 * Begin Backup 수행 때

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

5) Redo Records, Log Buffer

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

6) Rollback Segment(Undo Segement)와 Tablespace Headers에도 기록이 된다.

1-2. Commit 관련 파라미터 
1)10g R2

 

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에 기록하게되는데,  4가지 방식이 있다.

 1. Wait :변경된 트랜잭션이 Redo Log File에 기록될 때까지 기다린다.

 2. Nowait : Wait과 반대로 Redo Log File에 기록될 때 까지 기다리지 않는다. 

 3. Immediate : Commit 요청이 들어오면 즉시 Redo Log file에 기록을 시작한다.

 4. BATCH :  Commit 요청이 들어오더라도 일정 시간 동안 모아서 한꺼번에 기록한다.

4가지 방식 중 두개씩 조합해서 사용한다.

* IMMEDIATE+WAIT: COMMIT이 수행되면 즉시 redo log file에 기록을 요청하고, redo log file에 기록되기를 기다린다.

* IMMEDIATE+NOWAIT : Commit이 수행되면, 즉시 Redo Log File에 기록을 요청만하고 사용자에게 제어권을 넘겨 다른작업을 진행할 수 있도록한다.

BATCH나 NOWAIT같이 Redo Log Buffer의 내용이 아직 Redo Log File에 기록이 완료되지 않아도 다른 작업을 할 수 있도록 성능을 높이는 방식을 비동기식 커밋 이라고하며, 10g R2버전의 new feature이다.

* 동기식 커밋: Server Process가 Commit 요청을 수행할 때, LGWR이 Redo Log Buffer의 내용을 Redo Log File에 기록을 완료 후 후속작업을 지할 수 있는 방식.

 이 방식은 LGWR의 작업이 완료된 후 후속작업을 진행하기 때문에 안정성은 비동기식 커밋보다 좋지만, 성능면에서는 떨어지는 단점이 있다.

* Batch나 NOWAIT 방식 Commit이 수해되어도 즉시 Redo Log File에 기록을 하지 않음으로 성능은 빠르겠으나, 데이터가 안전하게 지켜지는것은 보장하지 못한다.

2)11g R2

* 초기상태.  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> show parameter commit   NAME     TYPE VALUE ------------------------------------ ----------- ------------------------------ commit_logging     string IMMEDIATE commit_point_strength     integer 1 commit_wait     string commit_write     string 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환경에서 홍길동이라는 데이터가 양쪽 인스턴스에 호출된 경우

노드 1: 홍길동 -> 일지매로 변경 후 Commit

노드 2: Commit과 동시에 홍길동의 정보를 조회하면 홍길동이 아닌 일지매로 보여야한다.

하지만, node1에서 Commit된 정보가 node2 에 도달하지 않으면 node2에서는 잘못된 정보를 볼 수 있는 문제가 발생한다.

Oracle에서는 node1에서 발생한 정보를 node 2에 전송할 때 piggyback이라는 방식으로 전송하는데, 이 방식은 Commit 발생 시 즉시 보내는 것이 아니라, 다른메세지가 갈때 함께 업혀가는 방식. 그러므로 메세지 발생양은 작고 트래픽 양은 작은 장점이 있을 수 있으나 틀린 내용을 조회할 수 있다는 단점이 있다.

그래서 max_commit_propagation_delay 파라미터를 사용하여 전송시간을 제어한다. 10g 부터 이 파라미터의 기본값은 0으로 설정되어 무조건 commit 하지마자 전송하도록 설정되어있다.

이런 방식을 Broadcast on commit(BOC) 방식이라고 한다.

 

2. System Change Number(SCN)

- SCN의 다른 이름으로 System Change Number가 있다.

- Data File, Redo Log File, Control File 간의 동기화 정보를 맞추기 위해 사용된다

- SCN_Base + SCN_Wrap + SCN_Sequence 로 구성되어있다.

- SCN_Sequence는 동일한 SCN Block을 여러개의 서버프로세스가 동시에 변경할 경우 이를 구분하기위해 사용하게된다.

- 이 SCN은 Datablock Header, Redo Records, Segment Header에 기록하게된다.

- Commit을 하면 DB Buffer Cache에서 데이터를 안내려쓰고 Redo log를 내려쓰는것이 시간도 더 빠르다고하여 Fast commit이라고 한다.

- 변경된 블록이 많을 경우 일일이 찾아다니면서 작업하기엔 시간이 많이 걸리므로, 오라클은 걸려있던 Lock정보들은 Commit 후 해당 블록을 처음 엑세스 하는 시점에 해제를 하는 Delayed block cleanout 이나 commit cleanout 같은 여러가지 기법을 동원해서 commit을 최대한 빨리 수행하고 데이터를 안전하게 지키려고 하는것이다.

3. Checkpoint

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

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

- Datafile의 복구를 결정하는 기초적인 정보로써 Control File과 Data File의 Check Point 정보를 비교하고 서로 정보가 다르면 틀린부분을 Online Redo나 Archived Redo Log를 참조해서 복구한다.

1) Database / Global Checkpoint

* 이 체크포인트가 발생하게되면 DB Buffer Cache내에 있는 모든 저장 안된 Dirty Buffer들의 내용을 전부 데이터파일로 저장하게 된다.

* 저장된 SCN 중 가장 큰 SCN번호를( CheckPoint SCN이라고 함) Control File과 Data File Header부분에 기록한다.

2)Thread Checkpoint / Logical Checkpoint

- 해당 Thread 내의 저장되지 않은 모든 Dirty Buffer들을 Datafile로 내려쓰게된다. 이 Checkpoint는 Log Switch가 발생하면 생긴다.

- RAC환경일 경우 각 노드별로 다르게 발생하며, Single Instance일 경우 Database Check Point와 같은역할.

3)Datafile Checkpoint

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

- 해당 테이블스페이스를 오프라인 한다거나 비긴백업 수행 시 발생하게된다.

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

4)Mini Checkpoint

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

5)Recovery Checkpoint

- 데이터 파일에 장애가 발생 했을 때 백업된 데이터파일 복원 후 Redo Change Vector를 적용시키게 된다. 그 후 Recovery된 블록을 데이터 파일에 저장해야하는데 이때 발생하는 CheckPoint를 Recovery Check Point라고 한다.

**

DB Buffer Cache의 변경된 Dirty bufer들을 Data File로 저장하는 것을 Check Point라고하며, 여러가지 경우가 있을 수 있다.

오라클에서는 여러가지 Checkpoint종류 중 우선순위를 두어서 Check Point를 관리하는데, 우선 순위가 높은 경우 Fast Checkpoint 분류하고 낮을경우 Low Checkpoint로 분류해서 두 가지가 동시에 발생할 경우 우선순위가 높은 Fast Check Point부터 진행하게된다.

 예를들어 Database Shutdown, Tablespace Begin backup, alter system checkpoint등의 명령어로 발생하는 Checkpoint는 Fast checkpoint로 분류되어 DB Buffer Cache 내부에 있는 모든 저장안된 Dirty Buffer들을 즉시 데이터 파일로 저장하게된다. 이를 Full Checkpoint라고한다.

 Full Checkpoint가 발생하면 Control File과 Data File Header에 해당 Checkpoint 정보를 기록하게된다.

** Checkpoint 우선순위가 낮을경우 Checkpoint를 할 Block의 목록을 즉시 데이터파일로 내려쓰지 않고, 어딘가에 기록 후 Background로 내려쓴다. 이를 Incremental Checkpoint라고도 한다.

** ITL Entries?

** Block Clean Out?

- Commit이 완벽하게 수행되려면 Data Block에 걸려있던 Lock까지 해제가 되어야 한다. 이 과정을 Block Clean Out 이라고한다.