개발은 너무해

CHECKPOINT NOT COMPLETE에 대해서
================================

database가 전체적으로 멈춘것처럼 어떠한 새로운 작업도 진행이 안되는 경우,
alertSID.log file를 확인해 보면 아래와 같은 message가 적힌 경우가 있다.

Checkpoint not complete

이러한 message가 의미하는 것은 무엇이며, 왜 발생하는지, 그리고 어떠한 조치가
가능한지 자세히 살펴본다.

1. checkpoint란 무엇인가?
~~~~~~~~~~~~~~~~~~~~~~~~~
checkpoint는 memory내의 block buffer의 내용과 disk상의 data block간의 내용을
맞추는 database event라고 할 수 있다.
checkpoint가 발생하면, 그때까지 memory내의 block에 가해진 모든 변경 사항을
disk상의 datafile내에 반영하게 된다. database crash에 의해 recovery가 필요
하게 되면 이 checkpoint이후의 변경사항에 대해서만 recovery를 시도하면 되므로,
recovery를 쉽고 효율적으로 수행할 수 있다.

checkpoint중에 수행되는 작업은 다음 두 가지로 정리할 수 있다.
- DBWR가 buffer cache내의 모든 변경된 block을 datafile에 기록한다.
- LGWR(혹은 CKPT)가 현재 발생한 checkpoint의 SCN값을 datafile과 controlfile
에 기록한다.

여기에서 중요한 것은 checkpoint event가 발생하여 block buffer에 어느 block이
disk로 씌여져야 하는가를 표시하면 dbwr는 이렇게 표시된 buffer를 순서와 관계없이
disk로 write하게 된다. 즉 redo log group1에 대한 buffer를 checkpoint하고 있는
중에 redo log group2에 대한 checkpoint요청이 들어오면 redo log group1에 대한
checkpoint를 끝내고 group 2에 대한 처리를 하는 것이 아니고, redo log group1에
대한 checkpoint가 진행 중에 redo log group2에 해당하는 buffer도 buffer cache
내에 모두 표시한 후 이것도 모두 group 1과 group 2의 구별이나 순서는 유지하지
못한채 같이 checkpoint가 이루어지는 것이다.
이것은 이후에 설명할 Checkpoint not complete가 발생하는 원인을 밝혀주는
중요한 근거가 된다.

checkpoint가 발생되는 경우는 다음 4가지 경우이다.
(1) log switch
(2) log_checkpoint_interval 만큼의 os block 간격
(3) log_checkpoint_timeout 초 간격
(4) alter system checkpoint명령문 수행시
앞의 세가지 경우에 대해서는 아래 별도의 section으로 자세히 설명하였다.

2. checkpoint와 성능 
~~~~~~~~~~~~~~~~~~~~ 

checkpoint를 자주하면 db crash후 recovery시간을 줄일 수 있는 대신에, 운영
중에서는 속도를 저하시킨다. checkpoint중에는 해당 datafile의 header내용이
고정되어 datafile header에 대한 다른 작업이 진행되지 못한다. 또한 
checkpoint간격이 너무 짧으면 뒤에서 설명할 'checkpoint not complete'
현상이 발생할 가능성도 커지게 되어 checkpoint에 대한 tuning이 필요하게 
되는 것이다. 

3. CKPT process 
~~~~~~~~~~~~ 

checkpoint 수행 중 checkpoint SCN의 값을 controlfile과 datafile header에 
반영시키는 작업을 수행하는 background process는 LGWR 혹은 CKPT process이다.
LGWR와 CKPT중 어느 process가 작업하는지는 Oracle version과 checkpoint_process
라는 parameter에 의해 결정된다. CKTP process를 사용하여 LGWR process의
작업을 줄이는 것이 성능 향상에 상당한 도움이 되기 때문에 oracle version이
증가할수록 CKPT process의 사용이 자동으로 유도된다.

(1) Oracle 7.0 - 7.3.2
initSID.ora file에 CHECKPOINT_PROCESS=TRUE 로 지정되어 있는 경우만,
CKPT process가 구동된다.

(2) Oracle 7.3.3, 7.3.4
db_files가 50이상이거나, 혹은 db_block_buffers값이 10,000 이상이면,
CHECKPOINT_PROCESS parameter에 관계없이 항상 CKPT process가 구동된다. 
CHECKPOINT_PROCESS를 TRUE로 지정하면 db_files나 db_block_buffers값과
무관하게 CKPT process가 기동된다.

(3) Oracle8 8.0.3이상
CKPT process 는 항상 기동되어, CHECKPOINT_PROCESS를 지정하면, 다음과
같은 오류가 발생한다.

LM-101 "unknown parameter name checkpoint_process" 

4. checkpoint가 발생되는 시점
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
checkpoint가 발생하는 시점은 아래와 같이 4가지 경우가 있다.

(1) log switch
log switch가 발생하면 항상 checkpoint가 발생한다. 단, checkpoint가
발생한다고 하여 log switch가 되는 것은 아니다. log swtich가 되는 경우는
사용 중인 log file이 모두 씌여졌거나, 명시적으로 
'alter system switch logfile' 문장을 수행한 경우이다.

online redo log file의 크기는 성능과 복구에 중요한 영향을 미친다.

(2) LOG_CHECKPOINT_INTERVAL 
이 parameter의 단위는 OS block size로, 이 크기만큼의 redo log file에 
기록한 후에 checkpoint가 발생하는 것이다.
예를 들어 log_checkpoint_interval로 10,000이 지정되어 있고, 대부분의 
Unix의 경우처럼 한 os block size가 512 bytes이면, 10,000 * 512 bytes = 
5m가 된다.
redo log file의 크기가 20m라고 가정할 때, 5m마다 checkpoint가 발생하므로,
redo log file하나를 기록하는 동안 4번의 checkpoint가 발생하는 것이다.

그러나 반대로 log file이 이 크기보다 작은 3m라면 log_checkpoint_interval
parameter는 무시되고 log swtich발생마다, 즉 log file에 3m만큼 기록한 
후에는 항상 checkpoint가 발생하게 된다.

(3) LOG_CHECKPOINT_TIMEOUT 

이 parameter의 단위는 초(second)이며, 이 시간 간격으로 checkpoint가 발생
하게 된다. log swtich전에 checkpoint가 발생하길 원한다면
log_checkpoint_timeout보다는 log_checkpoint_interval을 사용하도록 권장한다.
log_checkpoint_timeout은 transaction이 발생하지 않아도 일정 시간이 지나면,
무조건 checkpoint를 발생하게 하여 불필요한 checkpoint를 발생시키기 때문이다.

5. 그 외의 checkpoint관련 parameter
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(1) DB_BLOCK_CHECKPOINT_BATCH

이 parameter는 Oracle7과 Oracle8.0까지만 사용되는 것으로 checkpoint시에
DBWR가 한번에 disk에 write하는 block buffer의 갯수를 지정한다.
이것을 32정도의 큰 값으로 지정하면 checkpoint속도를 향상시킬 수 있다.

(2) LOG_CHECKPOINTS_TO_ALERT 

log swtich는 항상 alert.log에 기록이 남는다. log switch보다 자주
checkpoint가 발생하도록 한 경우 checkpoint발생 시간과 간격을 확인하려면
log_checkoiint_to_alert=true로 init.ora file에 지정하면 확인이 가능하다.

6. redo log file과 checkpoint 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

앞에서 언급한 바와 같이 log switch시에는 항상 checkpoint가 발생한다. 일반적
으로, log_checkpoint_interval이나 log_checkpoint_timeout을 log swtich보다 
간격을 크게 하여 checkpoint가 log swtich시에만 발생하도록 사용한다.

redo log file의 크기가 너무 작으면 불필요한 checkpoint작업이 자주 발생할 수 
있다. alert.log를 보면 아래와 같은 형태의 log switch에 대한 기록이 남게 
되는데, 이것을 통해 log switch 발생 간격을 확인할 수 있다.

Thread 1 advanced to log sequence 248 
Current log# 2 seq# 248 mem# 0: /prod1/oradata/logs/redologs02.log

log switch가 자주 발생하게 되면 성능 저하를 가져올 수 있으며, 일반적으로 
oracle에서는 한시간에 한번 정도의 log swtich를 권장하고 있다.
오라클 사용자의 경우 log file을 작게 유지하는 이유 중 current redo log file의
corruption시 잃게되는 정보의 양이 log file이 클 수록 비례적으로 큰것을
염려하는 경우가 많은데 이러한 경우는 redo log file에 member를 두고,
그 member를 다른 disk에 위치시킴으로써 위험을 줄일 수 있다.

log file의 크기가 너무 작아 log switch가 자주 발생하게 되는 경우의 또 다른
문제점은 log file의 status가 ACTIVE인 상태로 오래 지속되는 것이다. 이것은 아래 
설명할 checkpoint not complete같은 현상에도 직접적인 영향을 미친다.

redo log file은 log swtcih가 발생하고 checkpoint가 진행되는 동안 status가 
ACTIVE 상태가 된다. 이것은 해당 redo log에 대한 checkpoint가 완전히 끝나면,
INACTIVE 상태로 변경된다. 
그런데 log switch에 의해 checkpoint event가 발생된 경우 아직 이전 redo log
file에 대한 checkpoint가 끝나지 않았다면 이전 checkpoint와 새로운 
checkpoint가 구별되어 수행되는 것이 아니고 이전 checkpoint와 새로운 
checkpoint가 하나로 묶여 새로운 checkpoint까지 끝나야만 이전 redo log
file도 같이 INACTIVE 상태로 변경이 된다. 이미 1번 checkpoint란 무엇인가
에서 이미 언급한 내용이다.

실제 운영중에 redo log file의 대부분이 ACTIVE인 상태로 유지되다가 batch작업이 
끝날때쯤 한꺼번에 모두 INACTIVE로 되는 현상이 바로 이러한 원인때문이다. 
즉, 이것은 맨 처음 redo log file에 대한 내용도 여전히 checkpoint가 끝나지 않아,
나머지 redo log 들이 모두 기다리고 있는 현상이 아니라, 빈번한 log switch로
인해 바로 직접의 log에 대한 checkpoint가 끝나기 전에 다음 checkpoint가 요청
되고 이러한 일들이 계속 이어짐에 따라 checkpoint작업이 연속적으로 묶여
발생하는 것이다. 이러한 이유로 실제로는 redo log file의 내용의 대부분이 
checkpoint가 이루어졌지만, 다수가 ACTIVE인 상태로 존재하는 현상이 
발생하는 것이다.

checkpoint중인 datafile header는 다른 작업이 blocking되기 때문에 checkpoint
중인 상태로 오래 지속되는 것은 바람직하지 않으며, 그래서 적정한 redo 
log file의 크기와 갯수가 중요하게 된다.

7. CHECKPOINT NOT COMPLETE 
~~~~~~~~~~~~~~~~~~~~~~~~~
다량의 data를 import하거나 load하는 경우 혹은 batch 작업을 진행하는 경우,
database작업이 중간 중간 멈추는 hang현상이 발생하면서, alert.log file에
다음과 같이 'Checkpoint not complete'라는 message가 여러번 적힌 것을 발견
하게 되는 경우가 있다. 

Thread 1 advanced to log sequence 248 
Current log# 2 seq# 248 mem# 0: /prod1/oradata/logs/redologs02.log 
Thread 1 cannot allocate new log, sequence 249 
Checkpoint not complete 

이 message가 나타내는 것은 LGWR가 redo log를 재사용하려고 하는데, 아직 그
redo log file이 checkpoint가 끝나지 않은 상태임을 나타낸다. 예를 들어,
LGWR가 1번 redo log group에 내용을 기록하고, 2번으로 switch하면서 1번에 
대한 checkpoint가 진행중인 상태에서 2번 3번 redo log도 모두 사용하고 다시
1번을 사용하려고 하면 이러한 메시지가 alert.log에 적히게 되고, 1번을 다시
사용할 수 있을 때까지 db의 모든 변경 작업은 waiting상태가 된다.

이러한 현상은 database에 변경을 가하는 dml이 한꺼번에 빠르게 수행되는 경우
LGWR가 redo log file에 빠른 속도로 많은 내용을 기록하는 경우 발생한다.

redo log file의 크기나 갯수가 작아 log switch가 빈번히 발생하는 경우,
LGWR가 redo log에 redo정보를 적으면서 한바퀴 cycle을 도는 시간이 너무
빠르면 이러한 현상은 쉽게 발생 가능하다. 
앞 section에서 언급했듯이 oracle에서는 한시간에 한번 정도의 log switch와
log switch시에만 checkpoint가 발생하는 것을 기본적으로 권장한다.

그런데 redo log file의 갯수를 몇개 더 추가하고 size를 증가하였는데도,
마찬가지로 이러한 현상이 발생하는 경우가 있다. redo log group을 추가하여도,
redo log group을 추가할때만 사용이 되다가 다시 추가한 redo log group까지
모두 status가 ACTIVE이다가 어느 정도 시간이 지나거나 작업이 끝나면 동시에
모든 redo log group이 INACTIVE상태로 변경되는 것을 볼 수 있다.

이것은 이미 앞에서 여러차례 설명했듯이 이미 수행중인 checkpoint가 끝나지
않은 경우 다음 checkpoint가 들어오면 이것이 하나로 묶이게 되기 때문이며,
아래에 정리한 방법을 이용하여 tuning하여야 한다.

Checkpoint not complete현상을 해결하기 위한 방법을 정리해 보면 다음과 같다.

(1) LGWR가 redo log file을 한바퀴 도는 cycle을 지연시킨다. 
- redo log group을 추가시킨다.
- redo log file의 크기를 증가시킨다.

(2) checkpoint를 자주 발생하지 않도록 한다.
- LOG_CHECKPOINT_INTERVAL의 값을 증가시킨다.
- online redo log file의 크기를 증가시킨다.

(3) checkpoint 작업의 효율성을 증가시킨다.
- CHECKPOINT_PROCESS=TRUE 로 지정하여 CKPT process를 기동시킨다 (Oracle7)
- db_block_checkpoint_batch의 값을 증가시킨다 (7.X ~ 8.0)
- db_block_size를 증가시켜 dbwr가 checkpoint시 disk에 write하는 속도를 
향상시킨다.
이것은 database를 완전히 다시 만드는 작업이어서 쉽게 조치하기는
어려우나 이 문제가 자주 발생하여 심각한 영향을 미치는 경우 고려해
볼 수 있다.

Reference Documents

<Note:147468.1> Checkpoint Tuning and Troubleshooting Guide