1. latch: redo writing,
latch: redo allocation,
latch: redo copy
1) redo writing 래치: Redo Buffer 내의 공간을 확보하기 위해 LGWR 에게 쓰기 요청을 하려는 프로세스는 redo writing 래치를 획득해야 한다.
Willing-to-wait 모드로 획득
2) redo copy 래치: PGA 내의 Change Vector 를 Redo Buffer 로 복사하려는 프로세스는 작업의 전체 과정 동안 redo copy 래치를 보유해야 한다.
No-wait 모드로 획득
3) redo allocation 래치: Change Vector 를 Redo Buffer 에 복사하기 위해 Redo Buffer 내에 공간을 확보하고자 하는 과정에서 획득해야 한다.
9i 부터는 전체 Redo Buffer 를 복수개의 Redo strands 라는 공간으로 분할해서 사용할 수 잇으며,
하나의 redo allocation 래치가 하나의 redo strand 를 관리한다.
2. log file sync
서버 프로세스는 커밋 명령을 내린 후 LGWR 가 성공적으로 기록을 할 때까지 기다리게 되는데, 이 때 log file sync 이벤트를 대기하게 된다.
log file sync 대기가 광범위하게 나타난다면 다음과 같은 사실을 의심해보아야 한다.
- 커밋 회수가 지나치게 많지 않은가?
- I/O 시스템이 느리지 않은가?
- 리두 데이터가 불필요하게 생성되지 않는가?
- 리두 버퍼가 지나치게 크지 않은가?
1) 커밋 회수와 log file sync
지나치게 잦은 커밋은 log file sync 대기의 결정적인 주범이다.
가능하면 트랜잭션 단위를 합리적으로 묶어서 커밋이 이루어지게끔하며, PL/SQL 을 활용하는 것이 바람직하다.
2) I/O 시스템의 성능과 log file sync
리두 로그 파일이 위치한 I/O 시스템의 성능이 느린 경우에는 LGWR 의 sync write 를 수행하는 시간이 늘어나고
이로 인해 log file sync 대기시간이 증가할 수 있다.
이 경우, 서버 프로세스가 log file sync 이벤트를 대기하는 동안 LGWR 는 log file parallel write 이벤트를 대기하게 된다.
일반적인 가이드는 redo log file 을 가장 빠른 디바이스에 위치시키라는 것이다.
그리고 디스크 경합을 피하기 위해 서로 다른 그룹의 리두 로그 파일은 서로 다른 디스크에 분산시켜야 한다.
리두 로그 파일을 데이터파일이나 컨트롤 파일과 다른 디스크에 배치시키는 것 또한 필요하다.
3) 리두 데이터의 양과 log file sync
커밋 수행시 리두 로그 파일에 기록해야 할 데이터 양을 줄이면 log file sync 대기시간 또한 줄일 수 있다.
특히 크고 긴 트랜잭션에서 리두 데이터양을 줄이게 되면 LGWR 의 백그라운드 기록 (Background writes) 작업이 줄게 되고
자연스럽게 리두와 관련된 경합이 해소될 수 있다.
대량의 데이터를 생서앟는 작업에서는 항상 다음과 같은 기법을 활용할 수 있는지 검토해 보아야 한다.
- Nologging 옵션을 사용할 수 있는가?
- SQL*Loader 로 대량의 데이터를 적재할 때는 Direct load option 을 사용한다.
- 임시 작업이 필요할 때는 가능하면 임시 테이블을 사용한다.
- 인덱스가 있는 테이블에 대해 Direct load 작업을 수행할 때는 1) 인덱스를 Unusable 상태로 변경 2) 데이터 생성 3) 인덱스를 Nologging 모드로 재구성 과 같은 절차를 사용해서 인덱스에 의해 리두가 생성되는 것을 방지한다.
- LOB 데이터의 경우 데이터의 크기가 크다면 가급적 Nologging 속성을 부여한다.
4) 리두 버퍼의 크기와 log file sync
일반적으로 리두 버퍼의 크기가 지나치게 큰 경우에 log file sync 대기가 증가하는 경향이 있다.
3. log file parallel write
log file parallel write 이벤트는 LGWR 프로세스에서만 발생하는 대기이벤트이다.
log file parallel write 대기를 해결하는 방법은 일반적으로 log file sync 대기에서와 비슷하다.
- 불필요한 커밋을 줄인다.
- Nologging 옵션을 활용하여 리두 데이터의 양을 줄인다.
- 리두 로그 파일이 위치한 I/O 시스템의 성능을 높인다.
- 또 한가지 주의할 것은 핫백업 (Hot backup) 을 너무 자주 수행하지 말고, 특히 트랜잭션이 이 왕성한 시점에는 수행하지 말라는 것이다.
핫백업 모드에서는 리두 데이터가 로우 레벨이 아닌 블록 레벨로 생성되기 때문이다.
4. log buffer space
리두 버퍼에 리두 레코드를 기록하려는 프로세스는 리두 버퍼내에 필요한 공간을 확보하기 위해 redo allocation 래치를 획득해야 한다.
free buffer waits 대기를 줄이는 한 가지 방법이 DBWR 의 성능개선인 것처럼
log buffer space 대기를 줄이는 방법 중 하나도 LGWR 의 성능을 개선시키는 것이다.
더 빠르고 효율적인 I/O 시스템을 리두 로그 파일에 사용함으로써 LGWR 의 쓰기 성능을 개선시킬 수 있다.
5. log file switch completion,
log file switch (checkpoint incomplete),
log file switch (archiving needed),
log file switch (private strand flush incomplete)
이름이 비슷해서 관리자들에게 상당한 혼란을 주는 이 네개의 대기현상의 발생원인과 해결책은 모두 동일하다.
발생 원인은 트랜잭션이 생성하는 리두 데이터의 양에 비해 리두 로그 파일의 크기가 지나치게 작다는 것이다.
따라서 해결책은 리두 로그 파일의 크기를 충분히 키워주는 것이다.
더불어 Direct load operation 이나 Nologging 옵션을 사용하여 리두 데이터의 양을 줄이는 것도 도움이 된다.