스토리지의 Physical I/O 속도는 DBMS의 전반적인 성능에 아주 많은 영향을 미친다. 서버의 랙에 구성된 하드웨어를 아무리 품질이 좋은 하드웨어로 구성하더라도 결국 Physical I/O 속도에 의해 병목현상이 발생하게 된다.

Physical I/O 속도가 뛰어난 고가의 스토리지 제품을 쓰고 RAID 구성을 하며 데이터를 분산시켜도 결국 제품이 가진 Physical I/O 속도의 한계에 봉착하게 된다.

렇기 때문에 DBMS의 전반적인 성능을 관찰할 때 많은 wait event들이 Physical I/O와 연관되게 되며, 이는 DBMS의 아주 단순한 두 가지 기능인 데이터의 Read/Write 성능에 영향을 준다. 이는 곧 애플리케이션의 응답속도와 동시 처리량의 한계에 지대한 영향을 끼치게 된다.

Read 성능의 한계에 대해선 SQL을 튜닝하고 메모리/CPU를 증설해 최소한의 block(Oracle은 block 단위로 I/O가 발생함)을 읽고 최대한으로 메모리에서 재활용될 수 있도록 하여 최대한 빠른 처리를 할 수 있도록 극복해오고 있으나 Write 속도의 한계에 대해서는 얼마나 많은 양의 트랜잭션이 동시에 발생하느냐에 따라 그 한계치가 명확하게 구분되게 된다.

Oracle은 데이터의 일관성과 영속성을 유지하기 위해 발생할 수밖에 없는 Write I/O를 최대한 효율적으로 처리하기 위해 복잡하고 효율적인 Write 메커니즘을 가지고 있다.

하지만 새롭게 생성되거나 갱신된 데이터를 물리적으로 영구히 저장하는 Commit 명령은 필수적으로 Physical I/O를 동반하게 되어 로그 데이터처럼 데이터가 건건이 입력·변경되고 동시 다발적으로 발생할 경우 log file sync 대기로 인한 Commit 성능 저하를 겪게 될 수 있다.

Sync Commit(Synchronous Commit)

log file sync 대기 자체는 Oracle의 기본적인 Sync Commit 메커니즘으로 인한 매우 자연스러운 대기 현상으로 사용자가 Commit 수행 시 server process는 LGWR에게 요청을 전달하고 LGWR은 Redo Buffer의 변경 내용을 Redo Log File에 즉각 sync write하게 된다. server process는 이때 기록이 완료될 때까지 log file sync를 대기하며 이것이 Oracle의 기본적인 Sync Commit 방식이다.

이때 발생되는 Write I/O는 매우 순간적이지만 대량으로 발생된다. 따라서 이것이 성능에 지장을 줄 정도가 되면 지금까지는 애플리케이션을 변경해 기본적인 Commit 횟수를 줄이거나 I/O 성능이 더 뛰어난 스토리지 제품으로 교체하거나 심지어는 RAC 노드를 추가해 트랜잭션을 분산시켜야만 했다.

ASync Commit(Asynchronous Commit)

Oracle 10g부터 기존의 LGWR이 Redo Buffer의 변경 내용을 Redo Log File에 기록할 때 까지 server process가 대기해야만 했던 Sync Commit 방식의 Redo write 한계를 극복할 수 있는 파라미터를 제공해 server process가 더 이상 LGWR이 Redo Log File에 Redo Buffer를 내려쓸 때까지 log file sync 대기를 하지 않고 다음 트랜잭션을 바로 처리할 수 있는 ASync Commit 방식의 Redo write 기능으로 손쉽게 변경 가능하게 되어 log file sync 대기로 인한 Commit 성능 저하를 극복할 수 있는 기능을 제공하게 됐다.

즉 [표 1]의 두 가지 파라미터를 통해 Redo write 방식을 손쉽게 변경할 수 있도록 한 것이다.

• [표 1] 11g에서 제공되는 파라미터(10g에서는 COMMIT_WRITE 파라미터를 사용했으나 11g부터는 이 2개의 파라미터로 변경돼 더 이상 사용되지 않음)

• PARAMETER NAME	OPTION	설명
  COMMIT_WAIT	WAIT	server process는 LGWR이 Log Buffer를 파일에 기록할 때까지 log file sync 대기한다.
  	NOWAIT	server process는 LGWR이 Log Buffer를 파일에 기록할 때까지 대기하지 않고 다음 트랜잭션을 진행한다.
  COMMIT_LOGGING	IMMEDIATE	Commit 명령을 받을 때마다 LGWR0I Log Buffer를 파일에 기록한다.
  	BATCH	Commit 명령을 받았더라도 세션 내부 의 트랜잭션 데이터를 일정량 버퍼링한 후 LGWR이 Log Buffer를 파일에 기록 한다.

11g에서 COMMIT_WAIT, COMMIT_LOGGING 파라미터의 조합으로 [표 2]의 네 가지의 파라미터 조합을 선택할 수 있다.

• [표 2] COMMIT_WAIT, COMMIT_LOGGING의 조합 (이 파라미터는 Database/Session/Transaction별로 사용이 가능)

• COMMIT_LOGGING	COMMIT_WAIT	작동 방식
  IMMEDIATE	WAIT	Commit 후 server process는 LGWR에게 Log Buffer의 변경 내용 을 Redo Log File에 즉시 Write 요청 하고 완료될 때까지 log file sync를 대기한다. (기본적인 작동방식).
  IMMEDIATE	NOWAIT	Commit 후 server process는 LGWR에게 Log Buffer의 변경 내용 을 Redo Log File에 즉시 Write 요청 하나 server process는 완료될 때까 지 대기하지 않고 다음 트랜잭션을 진 행한다.
  BATCH	WAIT	세션 내부의 트랜잭션 데이터를 일정량 버퍼링하고 Commit 후 server process는 LGWR에게 Log Buffer의 변경 내용을 Redo Log File에 즉시 Write 요청하지 않고 세션 내부의 트 랜잭션 데이터를 일정량 버퍼링한 후 Write 요청하며 완료될 때까지 log file sync를 대기한다.
  BATCH	NOWAIT	세션 내부의 트랜잭션 데이터를 일정 량 버퍼링하고 Commit 후 server process는 LGWR에게 Log Buffer의 변경 내용을 Redo Log File에 즉시 Write 요청하지 않고 세션 내부의 트 랜잭션 데이터를 일정량 버퍼링한 후 Write 요청하며 server process는 완료될 때까지 대기하지 않고 다음 트랜잭션을 진행한다.

[표 3]은 3만 건의 데이터를 1건씩 입력하며 Commit을 반복적으로 수행했을 때 log file sync 발생 횟수, 대기시간, 총 수행 시간 등을 테스트한 결과다.

• [표 3] Commit 반복 수행 테스트 결과

• COMMIT_LOGGING	COMMIT_WAIT	log file sync 발생횟수	log file sync 대기시간	총 수행시간
  IMMEDIATE	WAIT	29996회	2148초	29초
  IMMEDIATE	NOWAIT	0회	0초	5초
  BATCH	WAIT	29994회	18.65초	26초
  BATCH	NOWAIT	0회	0초	4초

실제 log file sync 대기로 인한 성능 저하를 Async Commit 방식으로 처리해 log file sync 대기를 해결할 수 있는 것은 COMMIT_WAIT 파라미터라고 볼 수 있으며 Nowait으로 설정할 경우 효과는 파격적이다.

하지만 이렇게 파격적인 성능 개선이 가능한 기능이 흔히 쓰이지 않는 이유는 바로 Commit되었지만 Async Commit으로 인해 아직 Redo Log File에 Write되지 못한 log buffer들이 DB가 비정상적으로 종료됐을 경우 Commit됐음에도 데이터가 유실될 수 있기 때문이다.

이러한 이유로 OLTP 시스템에서 Database level로 적용하는 것은 권장하지 않으며 로그성 데이터만을 대량으로 적재 처리하는 배치(Batch) 시스템이나 OLTP 내에서 데이터 유실에 크게 영향을 받지 않는 특정 Session level 혹은 Transaction 단위로 사용하길 권장한다.

이 글에서 꼭 기억해야 할 것은 log file sync 대기 이벤트 자체는 아주 일반적으로 발생하는 정상적인 대기이며 log file sync로 인해 애플리케이션의 큐가 해소되지 못하고 적재가 늘어 실시간 처리에 문제가 생기는 경우 일반적으로 제시하는 log file sync 대기에 대한 해결책을 먼저 고려한 후 기존에 없었던 마지막 카드로서 Async Commit을 고려하되 그 위험성을 충분히 숙지하고 사용해야 한다는 점이다.