체크포인트 튜닝과 문제 해결 방안 (문서 ID 1526181.1)
이 문서는 데이터베이스 관리자에게 증분 체크포인트와 체크포인트 튜닝에 관련된 네가지 초기화파라미터의 이해를 돕기 위해 작성되었습니다.
FAST_START_MTTR_TARGET
LOG_CHECKPOINT_INTERVAL
LOG_CHECKPOINT_TIMEOUT
LOG_CHECKPOINTS_TO_ALERT
또한 alertlog 에서 볼 수 있는, 몇 가지 체크포인트 관련 에러 ('Checkpoint not Complete' 와 'Cannot Allocate New Log') 에 대해서도 설명하도록 하겠습니다.
상세 내역
내용:
체크포인트란 무엇인가?
체크포인트와 성능
증분 체크포인트와 와 관련된 초기화 파라미터들
리두 로그와 체크포인트
체크포인트 에러의 이해 ("Cannot allocate new log" 와 "Checkpoint not complete")
오라클 출시 정보
체크포인트 문제를 확인하기 위한 Statspack 이용법
체크포인트 튜닝과 에러 관리
1. 체크포인트란 무엇인가?
체크포인트는 디스크의 데이터블럭과 메모리의 데이터블럭을 동기시키는 데이터베이스 작업이며, 트랜잭션에 의해 변경된 자료의 일관성을 보장하기 위해 사용됩니다. 관련 트랜잭션의 커밋이 있을 때마다, 디스크에 변경된 데이터블럭을 쓰는 것은 아닙니다.
체크포인트는 다음 두가지 목적을 위해 존재합니다. (1) 자료 일관성 유지 (2) 빠른 데이터베이스 복구
그렇다면 어떻게 복구가 빨리 진행될 수 있을까요? 체크포인트까지 데이터파일에 기록된 모든 내용은 복구 과정에서 redo apply 가 필요 없기 때문입니다. 체크포인트는 장애 (인스턴스 혹은 디스크 장애)로 인한 손실을 예방하기 위해 버퍼 캐시 상의 변경된 모든 내용이 디스크에 기록되는 것을 보장합니다.
Oracle 은 다음 몇가지 조건 하에서만, 더티 버퍼를 디스크에 쓰게됩니다.
- 서버프로세스가 DB_BLOCK_BUFFER 의 1/4 이상을 스캔할 때
- 매 3초 마다
-체크포인트가 발생할 때 마다
다음 조건이 만족할 때, 체크포인트가가 움직입니다.
- 리두 로그 파일의 스위치 시점
- LOG_CHECKPOINT_TIMEOUT 크기만큼 대기할 때
- (LOG_CHECKPOINT_INTERVAL* IO OS 블럭의 크기) 에 해당하는 내용이 현재 리두 로그 파일에 쓰여질 때
- ALTER SYSTEM SWITCH LOGFILE 명령어가 입력될 때
- ALTER SYSTEM CHECKPOINT 명령어가 입력될 때
Checkpoint 도중 다음과 같은 일이 일어납니다.
- database writer (DBWR) 프로세스가 버퍼 캐시 내부의 변경된 블럭을 모두 디스크에 씁니다.
- Checkpoint process (CKPT) 프로세스가 모든 데이터파일의 헤더에 최신 체크포인트의 SCN 을 기록합니다.
2. 체크포인트와 성능
체크포인트를 생각할 때 관리자는 튜닝 관점에서 딜레마에 빠질 수 밖에 없습니다. 잦은 체크포인트는 빠른 복구를 가능케 하겠지만, 한편 성능저하를 일으키기 때문입니다. 관리자로서 이 상황에 대한 해답은 무엇이 될까요?
데이터파일의 개수가 많은 데이터베이스의 경우라면, 체크포인트가 진행되는 동안 모든 데이터파일 헤더가 잠기게 되고 이는 매우 높은 리소스를 필요로 합니다. 체크포인트의 주기에 대해서는 이처럼 트레이드오프가 있습니다. 더 잦은 체크포인트를 하도록 설정하면, 장애가 발생했을 때에 필요한 복구작업을 더 빠르게 진행할 수 있습니다. 예상치 않은 장애가 발생했을 때, 매우 짧은 시간내에 복구를 완료해야 하는 고객의 경우 이 설정이 선택될 수 있습니다. 하지만 잦은 체크포인트가 대부분에 고객사에 적합하다고 볼 수는 없습니다. 예를 들어 하루 중 5% 시간만 다운타임으로 용납할 수 있는 환경을 상상해보면, 가상의 5% 보다 현실의 95% 에 해당하는 운영시간동안의 최대 성능에 집중하는 것 더 효율적일 수 있기 때문입니다.
이 문서는 독자의 최우선 관심사가 성능, 즉 체크포인트의 빈도를 줄이는데 있다는 가정하에 작성되었습니다.
체크포인트 튜닝에 있어, 다음 4가지의 초기화 파라미터가 관련되어 있습니다.
- FAST_START_MTTR_TARGET
- LOG_CHECKPOINT_INTERVAL
- LOG_CHECKPOINT_TIMEOUT
- LOG_CHECKPOINTS_TO_ALERT
이 파라미터들은 좀 더 뒤에 자세히 다루도록 하겠습니다.
리두 로그 혹은 체크포인트 튜닝의 필요성을 의미하는 메세지인, alertlog 의"checkpoint not complete" 를 어떻게 다룰 것인가에 대해서도 추후 언급하도록 하겠습니다.
3. 증분 체크포인트와 관련된 초기화 파라미터들
주의: 다음에 소개하는 초기화 파라미터에 의해 발생되는 체크포인트보다, 리두 로그 파일의 스위치가 항상 우선시됩니다.
FAST_START_MTTR_TARGET
Oracle 9i 이후 FAST_START_MTTR_TARGET 파라미터는 증분 체크포인트 튜닝에 있어 가장 선호되는 접근방법 중 하나입니다. 사용자는 싱글 인스턴스가 복구에 필요로 하는 시간을 초단위로 FAST_START_MTTR_TARGET 파라미터에 설정하고, Oracle 은 내부의 통계정보에 근거해 자동으로 체크포인트의 간격을 조정합니다.
V$INSTANCE_RECOVERY 뷰의 ESTIMATED_MTTR 컬럼을 통해 현재 계산된 mean time to recover (MTTR) 값을 조회할 수 있습니다. (사용자가 FAST_START_MTTR_TARGET 파라미터를 설정해두지 않았더라도, 이 값은 조회할 수 있습니다.) TARGET_MTTR 컬럼은 현재 시스템에 의해 가장 효율적인 MTTR 값을 의미합니다.
V$MTTR_TARGET_ADVICE 뷰는 현재 운영상태에서 ESTIMATED_MTTR 값으로 인해 초래되는 I/O 건수와 TARGET_MTTR 값으로 초래되는 I/O 의 건수를 나타냅니다. 사용자는 이 뷰를 통해 FAST_START_MTTR_TARGET 설정으로 얻을 있는 빠른 복구시간과 운영 중 성능사이의 트레이드오프를 확인할 수 있습니다.
LOG_CHECKPOINT_INTERVAL
LOG_CHECKPOINT_INTERVAL 파라미터는 증분 체크포인트가 일어나기 전에 필요한 리두 블럭의 개수를 지정합니다. FAST_START_MTTR_TARGET 가 설정된 경우라면, LOG_CHECKPOINT_INTERVAL 파라미터는 설정하지 않거나 0 으로만 설정되어야 합니다.
대부분의 UNIX 환경에서 OS 블럭의 크기는 512 바이트입니다. 따라서 LOG_CHECKPOINT_INTERVAL 의 값을 10,000 으로 설정했을 때, 5,120,000 (5M) 바이트가 될 때까지 증분 체크포인트는 일어나지 않습니다. 만약 리두 로그의 크기가 20M 인 경우라면, 각 리두 로그가 4번의 체크포인트를 필요로 하는 것을 의미합니다.
LOG_CHECKPOINT_INTERVAL 값은 언제 체크포인트가 일어날 것인가에 영향을 주는만큼 신중하게 설정되어야 하고, 리두 로그 파일의 크기가 바뀔 때에도 적절히 변경되어야 합니다. 체크포인트가 일어나는 간격은 예상치 않은 장애가 발생되었을 때 복구에 필요한 시간을 결정하는 중요한 요소입니다. 이 간격이 길수록 장애 발생 후 데이터베이스의 복구작업에 더 많은 시간이 소요되고, 이 간격을 줄이면 데이터베이스 복구는 더 빨리 진행되겠지만 운영시점의 체크포인트에 높은 리소스를 필요로 합니다.
이 파라미터는 또한 데이터베이스 복구 과정의 roll forward 에도 영향을 미치는데, 실제 복구시간은 바로 이 부분이 큰 비중을 차지하기 때문입니다. 기타 다른 고려 사항으로는 장애의 형태(인스턴스 크래쉬 혹은 시스템 크래쉬, 디스크 실패 등) 와 필요한 아카이브된 로그 의 개수 등이 있습니다.
LOG_CHECKPOINT_TIMEOUT
LOG_CHECKPOINT_INTERVAL 파라미터는 증분 체크포인트가 일어나기 전에 필요한 시간(초 단위)를 지정합니다. 다시 말해 버퍼 캐시 안의 더티 버퍼가 얼마나 오랫동안 보관될 것인가를 결정합니다.
체크포인트의 빈도는 예상치 않은 장애가 발생되었을 때 복구작업에 필요한 시간을 결정하는 중요한 인자입니다. 이 간격이 길수록, 장애 발생 후 데이터베이스의 복구가 완료되는데 더 많은 시간이 소요됩니다.
Oracle 은 트랜잭션량과 상관없이 매 지정된 시간에 체크포인트를 시작하는 LOG_CHECKPOINT_TIMEOUT 대신, LOG_CHECKPOINT_INTERVAL 의 사용을 권장합니다. 트랜잭션의 양이 일정하지 않은 환경에서 LOG_CHECKPOINT_TIMEOUT 파라미터를 설정하면 불필요한 체크포인트가 진행되므로, 이는 최적의 성능유지를 위해 반드시 피해야합니다.
혹시라도 LOG_CHECKPOINT_TIMEOUT 에 설정한 값이 리두 로그 스위치 간격을 의미하지는 않을까? 오해하는 경우가 비일비재하지만, 이는 잘못된 생각입니다. 로그 스위치가 체크포인트를 일으키기는 하지만, 그 반대는 성립하지 않기 때문입니다. 물론 ALTER SYSTEM SWITCH LOGFILE 명령어를 직접 입력하거나 리두 로그의 크기를 변경하는 것이 체크포인트를 발생시키지만, 이는 시간 간격으로 인한 것이 아닙니다.
참고로 사용중인 온라인 리두 로그 파일의 크기를 변경하는 것은 성능 및 복구작업에 있어 매우 중요합니다. 이에 대해서는 '리두 로그와 체크포인트' 항목을 참고해주시기 바랍니다.
LOG_CHECKPOINTS_TO_ALERT
LOG_CHECKPOINTS_TO_ALERT 파라미터는 사용자의 체크포인트 진행내역이 alert file 에 기록되도록 합니다. 이 정보를 통해 원하는 간격으로 체크포인트가 진행되었지 여부를 확인할 수 있습니다. Oracle9i 이전 버전에서는 STATIC 성격이었습니다. Oracle 은 이 파라미터의 값이 항상 TRUE 일 것을 권장하는데, 이로 인해 초래되는 부하는 무시해도 될 정도로 작습니다.
지금까지 언급된 파라미터에 대하 좀 더 자세한 정보가 필요한 경우, Note:76713.1 를 참고하십시오.
4. 리두 로그와 체크포인트
체크포인트는 리두 로그 스위치가 일어날 때마다 발생합니다. 만약 이전 체크포인트 가 아직 진행중이라면, 로그 스위치에 의한 체크포인트가 이미 진행 중인 것을 오버라이드합니다.
이렇게 잦은 로그 스위치로 인해 초래된 불필요한 체크포인트를 피하려면, 적절한 크기의 리두 로그 파일이 필요합니다. 증분 체크포인트의 목표값과 그 나머지의 차이는 대부분 너무 작은 크기의 온라인 리두 로그 파일에 기인하는데, 실제로 대부분의 로그 스위치가 체크포인트를 기다릴 필요가 없다는 것을 의미하기도 합니다. 따라서 리두 로그파일이 충분히 크도록, 최대 20 분마다 한번씩은 스위치되는 것이 바람직합니다. 너무 작은 리두 로그 파일은 성능저하의 요인이므로, Oracle 은 모든 온라인 리두 로그 파일을 같은 크기로 만들고, 각 인스턴스에 최소한 2개의 로그 그룹을 만들어 둘 것을 권장합니다. Alert log 는 로그 스위치와 체크포인트를 를 모니터링하는 데 있어, 매우 유용합니다.
다음은 alert log 상에서 볼 수 있는 빠른 로그 스위치의 예입니다.
Fri May 16 17:15:43 1997
Thread 1 advanced to log sequence 1272
Current log# 3 seq# 1272 mem# 0: /prod1/oradata/logs/redologs03.log
Thread 1 advanced to log sequence 1273
Current log# 1 seq# 1273 mem# 0: /prod1/oradata/logs/redologs01.log
Fri May 16 17:17:25 1997
Thread 1 advanced to log sequence 1274
Current log# 2 seq# 1274 mem# 0: /prod1/oradata/logs/redologs02.log
Thread 1 advanced to log sequence 1275
Current log# 3 seq# 1275 mem# 0: /prod1/oradata/logs/redologs03.log
Fri May 16 17:20:51 1997
Thread 1 advanced to log sequence 1276
Current log# 1 seq# 1276 mem# 0: /prod1/oradata/logs/redologs01.log
만약 리두 로그 스위치가 매 3분마다 발생한다고 가정해보면, 성능저하는 당연한 결과입니다. 이는 사용자의 업무량에 효과적으로 대응할 수 있도록 충분히 크지 않은 리두 로그임을 가르킵니다.
리두 로그 파일의 적절한 크기를 결정하는 데 필요한 자세한 정보는 Note:1038851.6 를 참고해주십시오. 그리고 실제 온라인 리두 로그 파일의 크기를 변경하는 방법은 Note:1035935.6 를 참고하시기 바랍니다.
5. 체크포인트 에러의 이해 ("Cannot allocate new log" 와 "Checkpoint not complete")
때때로 다음과 같은 메세지가 alert log 에 기록되는 것을 볼 수 있습니다.
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
이 메세지는 리두 로그 파일이 재사용되지 못하고, 체크포인트가 특정 로그에서 계속 정체된 상태를 의미합니다. 체크포인트가 다음 로그로 이동할 때까지 Oracle 은 대기할 수 밖에 없습니다. 이 현상은 DBWR 의 쓰기 동작이 매우 느리거나, 리두 로그 파일의 크기가 너무 작거나 혹은 너무 빠른 로그 스위치가 일어난 결과입니다. 데이터베이스가 체크포인트를 기다리는 상황에서는, 로그 스위치가 완료될 때까지 더 이상 리두가 생성되지 않습니다.
6. 오라클 출시 정보
8i 버전에서 FAST_START_IO_TARGET 파라미터를 설정해두면, Oracle 은 복구가 필요할 때 FAST_START_IO_TARGET 값 이상의 데이터 블럭이 사용되지 않도록 체크포인트 주기를 자동적으로 변경했습니다. 이 파라미터는 9i 버전에서 사라졌으며, 대신 FAST_START_MTTR_TARGET 파라미터를 사용할 수 있습니다.
7. 체크포인트 문제를 확인하기 위한 Statspack 이용법
15분 정도 간격으로 Statspack 스냅샷을 수집하도록 설정해두면, 체크포인트의 시작/완료시간은 물론 특성 시간동안 진행된 체크포인트로부터에서 얼마나 많은 데이터베이스 버퍼가 디스크에 써졌는지 알아볼 수 있습니다. 물론 리두 활동내역도 살펴볼 수 있는데, 서로 다른 시간대의 보고서를 비교함으로서 체크포인트 성능향상에 대한 힌트를 얻을 수 있습니다.
Statspack 보고서에서 관심가지고 봐야할 정보가 하나 더 있다면, 다음과 같은 대기 이벤트의 내역입니다. 이 대기 이벤트들의 상황에 따라 리두 로그와 체크포인트에 문제가 있는지 손쉽게 인지할 수 있습니다.:
log file switch (checkpoint incomplete)
log file switch (archiving needed)
log file switch/archive
log file switch (clearing log file)
log file switch completion
log switch/archive
log file sync
만약 위 대기 이벤트 중에서 비정상적으로 높은 값이 확인된다면, 온라인 리두 로그 파일의 개수와 크기를 늘리거나 체크포인트 관련 파라미터의 변경이 필요합니다.
Exadata Troubleshooting.pptx
