|
|
 리두로그 파일과 아카이브 파일의 I/O 튜닝 |
|
|
사용자들이 UPDATE, INSERT, DELETE문을 실행하면 모든 변경 데이터는 리두로그 버퍼에 저장된 후 일정시점이 되면 LGWR 백그라운드 프로세스에 의해 리두로그 파일에 저장됩니다.
그리고, 아카이브 모드에서는 리두로그 시스템에 로그 스위치가 발생하면 ARCH 백그라운드 프로세스에 의해 리두로그 파일을 미리 지정된 경로로 복사 합니다.
이 메커니즘이 바로 오라클 데이터베이스의 백업 메커니즘입니다. 하지만, 이 메커니즘이 정상적으로 운영 되었을 경우에는 별 문제가 발생하지 않겠지만, 서로 연속적으로 발생하는 읽기,쓰기 작업이 순차적으로 진행되지 않으면 성능저하 현상이 발생하게 됩니다.
자, 그럼 보다 자세히 성능문제를 알아 봅시다. |
|
|
|
|
|
 |
리두로그 파일과 성능문제 |
|
|
만약, 여러 개의 리두로그 그룹들이 같은 디스크에 생성되어 있다면, 많은 변경 데이터를 저장할 때 연속적으로 여러 개의 리두로그 파일에 저장할 수 없는 문제가 발생합니다. 이유는 물리적 디스크 장치는 한번에 하나의 I/O 만을 유발시킬 수 있기 때문에 하나의 리두로그 파일에 변경 데이터를 저장한 후 다음 리두로그 파일에 저장하려고 할 때 다른 사용자들의 읽기,쓰기 작업으로 인해 연속적으로 쓰기 작업을 진행하지 못하고 일시적으로 대기해야 하는 문제가 발생하게 됩니다. 이러한 대기상태가 빈번하게 발생하면 데이터베이스 전체적인 성능저하 현상이 나타나게 됩니다.
< 해결방법-1 >
여러 개의 리두로그 파일들을 물리적으로 다른 여러 개의 디스크로 나누어 배치하게 되면 하나의 디스크에서 발생하는 집중현상을 여러 개의 디스크로 분산할 수 있습니다.
< 해결방법-2 >
리두로그 파일의 크기를 보다 크게 늘려 줍니다. 리두로그 파일의 크기가 너무 작으면 많은 변경 데이터를 여러 리두로그 파일에 나누어 저장해야 하기 때문에 불필요한 로그 스위치가 발생하기 때문입니다.
< 해결방법-3 >
리두로그 그룹의 수를 늘려 줍니다. 하나의 리두로그 파일의 크기를 너무 크게 설정해 두면 로그 스위치가 발생할 때 ARCH 프로세스에 의해 아카이브 되는데 소요되는 시간이 너무 길어질 수도 있습니다. 즉, 아카이브가 완료되지 않으면 로그 스위치에 의해 다음 리두로그 파일에 변경 데이터가 저장되지 못하고 일시적으로 대기해야 하는 문제가 발생하게 됩니다.
이런 경우를 최소화 하기 위해서는 리두로그 그룹 수를 적절히 늘려 주어야 합니다.
$HOME/ADMIN/BDUMP/alert_<SID>.ora 파일에 다음과 같은 메시지가 나타나면 LGWR 프로세스에 대기상태가 발생한 것 입니다.
|
"checkpoint not complete ; unable to allocate file" | |
|
|
 |
아카이브 파일과 성능문제 |
|
|
메모리 영역인 리두로그 버퍼의 정보는 LGWR 프로세스에 의해 리두로그 파일에 저장됩니다. 하나의 리두로그 파일이 모두 쓰여지면 ARCH 프로세스에 의해 오프라인 또는 온라인 저장구조에 저장됩니다. 문제점은, ARCH 프로세스가 다른 저장구조에 저장하는데 소요되는 시간보다 LGWR 프로세스가 메모리 영역으로부터 리두로그 파일에 저장하는데 소요되는 시간이 훨씬 빠르다는 점입니다. 즉, 많은 변경 데이터가 보다 빠르게 리두로그 파일에 저장되려면 아카이브 작업이 빠르게 완료되어야 하는데, 시간이 많이 소요되게 되면 연속적인 쓰기 작업을 하지 못한다는 점입니다.
< 해결방법-1 >
log_archive_max_processes 파라메터의 값을 보다 높게 설정해 줍니다. ARCHIVE 모드로 데이터베이스 환경을 설정하게 되면 기본적으로 하나의 ARCH 프로세스가 활성화 됩니다. 동시에 많은 변경작업이 발생하는 경우 하나의 ARCH 프로세스로 아카이브를 하는 것 보다 여러 개의 ARCH 프로세스를 활성화하게 되면 보다 빠르게 아카이브 작업을 완료할 수 있습니다.
< 해결방법-2 >
아카이브 파일은 결국 리두로그 파일의 백업 정보이므로 리두로그 파일의 크기와 개수를 적절하게 조정하는 것이 아카이브 파일의 개수와 크기를 조절할 수 있는 방법입니다.
< 해결방법-3 >
아카이브 파일들이 저장되는 저장구조를 충분하게 확보하십시오. 아카이브 모드에서 파일들이 저장되는 저장구조에 여유공간이 없으면 아카이브 작업은 더 이상 진행되지 않습니다. 즉, LGWR 프로세스는 리두로그 영역의 데이터를 리두로그 파일에 저장하지 못하게 되고 궁극적으로 데이터베이스 전체적인 대기상태가 발생하게 됩니다. |
|
|
 |
|
|
| 체크포인트 |
|
|
오라클 데이터베이스의 백그라운드 프로세스 중 CKPT의 역할은 LGWR 프로세스가 리두로그 버퍼의 내용을 리두로그 파일에 저장하는 시점의 정보와 DBWR 프로세스가 데이터 버퍼 캐시영역의 내용을 데이터 파일에 저장하는 시점의 정보를 동기화 시켜주는 역할을 하게 됩니다.
하지만, 이러한 체크포인트가 너무 자주 실행되면 불필요한 읽기,쓰기 작업이 빈번하게 발생되기 때문에 데이터베이스의 전체적인 성능이 저하될 수 있습니다. 반대로, 자주 실행되면 인스턴스 문제로 인한 데이터베이스의 장애가 발생한 경우 빠르게 복구할 수 있는 장점을 가지고 있기도 합니다.
다음은 체크포인트가 발생하는 시점입니다. |
|
- 로그 스위치가 발생할 때
- 데이터베이스가 정상적으로 종료될 때
- ALTER SYSTEM CHECKPOINT 명령어가 실행될 때
- ALTER SYSTEM SWITCH LOGFILE 명령어가 실행될 때
- 테이블스페이스가 ONLINE 상태에서 OFFLINE 상태로 변경될 때 | |
|
|
다음은 체트포인트를 유발시키는 파라메터 들입니다. |
|
|
1) LOG_CHECKPOINT_INTERVAL : 체크포인트가 발생하는 간격을 지정된 블록수로 결정합니다.리두로그 파일에 지정된 변경 데이터가 저장될 때 마다 체크포인트가 발생합니다.
2) LOG_CHECKPOINT_TIMEOUT : 체크포인트가 발생하는 간격을 지정된 시간으로 결정합니다. 이 시간이 지날 때 마다 LGWR과 DBWR 프로세스는 각 파일에 정보를 저장합니다.
3) FAST_START_IO_TARGET : 인스턴스를 복구할 때 복구해야 할 블록 수를 지정할 수 있습니다. 항상 지정된 크기의 정보가 메모리에 남게 되면 체크포인트가 발생합니다.
4) DB_BLOCK_DIRTY_TARGET : DBWR 프로세스는 지정된 블록수가 데이터 버퍼 캐시영역에서 확보되면 데이터 파일에 저장합니다.
5) FAST_START_MTTR_TARGET : 인스턴스를 복구할 때 복구시간을 지정할 수 있습니다. 지정된 복구 대상시간 만큼의 정보가 메모리에 남게 되면 체크포인트가 발생합니다. | |
|
|
결론적으로, 오라클 데이터베이스의 성능 튜닝을 할 때는 체크포인트가 자주 발생하지 않도록 다음과 같이 환경설정을 해야 합니다. |
|
|
1) 체크포인트의 빈도를 줄인다는 말은 로그 스위치가 발생하는 빈도를 줄인다는 것과 같은 의미를 가지고 있으므로 리두로그 파일의 크기를 보다 크게 설정해야 합니다.
2) 빈번한 변경작업이 발생하는 데이터베이스 환경에서는 LOG_CHECKPOINT_INTERVAL 또는 LOG_CHECKPOINT_TIMEOUT과 같은 파라메터를 통해 체크포인트의 발생빈도를 줄일 수 있습니다. | |
