[스크랩] Checkpoint not complete 관련

http://jemitnya.blogspot.kr/2012/02/checkpoint-not-complete.html

/u01/app/oracle/diag/rdbms/jsrdb/jsrdb/alert/log.xml 에서 'Checkpoint not complete' 메시지를 뿌리면서, DB hang 현상이 나타나는 경우가 있다.
이 현상은 LGWR가 online redo log 파일을 사용하려고 할 때, 사용할 online redo log 파일이 없을 경우 나타나게 되고 이 때 DB의 모든 변경작업은 대기하게 된다.

'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를 완전히 다시 만드는 작업이지만, 문제가 자주 발생하여 심각한 영향을 미치는 경우 고려해 볼 수 있다.)
추가 설명
- Checkpoint : DBWR 가 메모리상의 수정된 내용을 해당 datafile에 기록하는 것이다.
                      이 때 LGWR 또는 CKPT가 SCN을 datafile과 controlfile 헤더에 기록한다.
                      (LGWR, CKPT는 Oracle Version, checkpoint_process 파라미터에 의해 결정된다.)
                     : log switch 시 발생
                     : log_checkpoint_interval 간격(os block) 마다 발생
                     : log_checkpoint_timeout 간격(초) 마다 발생
                     : alter system checkpoint 명령 시 발생
- Log switch : LGWR 가 online redo log에 기록하는 걸 중지 하고 다른 그룹에 쓰게하는 event 다.

log switch가 너무 자주 발생하게 되면, 성능에 영향을 준다. (1시간에 1번 정도?)
log file의 status가 ACTIVE 상태로 오래 지속되게 되고, 이 때  'Checkpoint not complete'  현상이 나타난다.
또한 checkpoint중인 datafile 헤더는 block되기 때문에 checkpoint 가 오래지속되는건 바람직 하지 않으며, redo log file의 크기와 수가 중요하다.

- redo log status
  CURRENT  : 현재 사용 중 (이 경우 삭제할 수 없다.)
  ACTIVE      : 메모리의 내용이 datafile에 기록 중
  INACTIVE  : 사용 가능 (삭제도 가능)

- 관련 SQL
  조회
  SQL> select  a.group#,
                       a.member,
                       b.bytes/1024/1024 MB,
                       b.archived,
                       b.status
            from    v$logfile a,
                       v$log b
           where   a.group#=b.group#
           order by 1,2;
  신규 그룹 생성
  SQL> alter database add logfile group 4 '/u01/app/oracle/oradata/orcl/redo04_a.log' size 50M;
  멤버 추가
  SQL> alter database add logfile member '/u01/app/oracle/oradata/orcl/redo04_b.log' to group 4;
  멤버 삭제
  SQL> alter database drop logfile member '/u01/app/oracle/oradata/orcl/redo04_b.log';
  그룹 삭제
  SQL> alter database drop logfile group 4;
  log switch 발생
  SQL> alter system switch logfile;
  checkpoint 발생
  SQL> alter system checkpoint;

----------------------------------------------------------------------------------------------------------------

http://cafe.daum.net/_c21_/bbs_search_read?grpid=45dh&fldid=2me2&datanum=10

archive log list - 로그 시퀀스 넘버 확인하기 = SCN

 

로그스위치가 발생하면 checkpoint가 발생한다.

 

 

ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

 -> udump 가서 확인한다.

 

 

여기에서 컨트롤 파일의 정보를 볼수가 있다.

v$controlfile

v#parameter

v#controlfile_record_section

show parameter control_files

 

 

Online Redo Log파일이 꽉 차서 LGWR 에 의해 다음 LOG그룹으로 옮겨가는것을 logswitch라 부르며,

이때 체크포인트가 일어나고, 컨트롤 파일에 동기화 정보가 기록된다.

 

LGWR 프로세스가 동작되는 경우.

 - COMMIT 되었을 때.
 - 1/3 찼을때
 - 1MB 이상의 Redo Log가 있을때
 - 매 3초마다
 - DBWR이 기록하기 전에

 

DBWR 프로세스가 동작되는 경우.

 - Checkpoint 가 발생한경우
 - Dirty buffer가 임계값에 도달했을때
 - 사용가능한 버퍼가 없을때
 - 시간초과가 발생한경우(3초)
 - RAC 핑 요청이 생성된 경우
 - 테이블스페이스가 오프라인 되었을때
 - 테이블스페이스가 READ-ONLY 되었을때
 - 테이블이 DROP 또는 TRUNCATE인 경우
 - 테이블이 BEGIN BACKUP 될때.

 

체크포인트의 term이 너무 적으면 Disk I/O가 높아지게되고, term이 커질수록 더 많은 데이터 유실의 위험이 있다.

Checkpoint 의 시간을 결정하는 파라메터

FAST_START_MTTR_TARGET

8i에서는 아래의 두개 파라메터를 사용한다.

(log_checkpoiint_timeout - 초 단위 ,  log_checkpoint_interval - 블록 갯수)

9i 에서는 모두 사용할 수 있지만,

FAST_START_MTTR_TARGET 파라메터를 사용하면 두개파라메터를 사용할 수 없고, 반대의 경우도 마찬가지이다.

 

체크포인트가 발생하는 경우.

 -모든 로그 스위치 발생 시
인스턴스가 노멀, 트랜잭셔널, 이미디에이트 옵션으로 종료된경우
초기화 매개변수 FAST_START_MTTR_TARGET을 설정하여 시행하는 경우
데이터베이스 관리자가 수동으로 요청한 경우
ALTER TABLESPACE [OFFLINE NORMAL|READ onLY|BEGIN BACKUP] 명령으로 인해
특정 데이터파일에서 체크포인트가 발생한경우.

 

 

 

강제로 체크포인트 발생

select group#, status from v$log;

alter system switch logfile;

select group#, status from v$log;

 

 

 

한 그룹내의 멤버의 크기는 반드시 동일하게 해준다.

각 그룹의 크기는 동일하게 해준다.

 

 

그룹 삭제시 적어도 두개의 그룹은 남겨야 한다.

액티브나 커런트한 그룹은 드롭할수 없으므로 언유즈드 상태로 만든다.

그룹 드롭시 파일은 삭제되지 않으므로, 따로 삭제해 주어야 한다.

 

 

 

 

 

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가 발생한다. 일반적 으로, og_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를 완전히 다시 만드는 작업이어서 쉽게 조치하기는 어려우나 이 문제가 자주 발생하여 심각한 영향을 미치는 경우 고려해 볼 수 있다.

-----------------------------------------------------------------------------------------------------------------------

http://okky.kr/article/9534

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를 완전히 다시 만드는 작업이어서 쉽게 조치하기는
어려우나 이 문제가 자주 발생하여 심각한 영향을 미치는 경우 고려해
볼 수 있다.