태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

Oracle Redo Log 기록을 제어하는 세가지 파라미터

오라클 2007.10.11 17:23
오라클 10g R2에서 COMMIT_WRITE 파라미터가 추가됨으로써 이제 사용자가 오라클의 Redo 기록을 제어할 수 있는 길이 생겼다. 이전에는 일부 히든 파라미터로만 가능했던 일이다.

잘 사용하면 앉아서 코풀기... 손쉽게 성능을 개선할 수 있다. 하지만 그만큼 위험이 따른다.

역시 최고봉은 COMMIT_WRITE 파라미터이다. 아래 정보를 보자.

기본 정보

Parameter 정보


Syntax{IMMEDIATE|BATCH},{WAIT |NOWAIT}
DefaultIMMEDIATE, WAIT
설정방법
  • Parameter File
  • ALTER SYSTEM SET COMMIT_WRITE = BATCH, NOWAIT
  • ALTER SESSION SET COMMIT_WRITE = BATCH, NOWAIT
  • COMMIT WRITE BATCH NOWAIT
지원 10gR2


설명

Transaction에 대한 Commit 수행시 Redo Write를 실행하는 방식을 결정한다. 사용자가 Commit을 수행하면 오라클은 Redo Buffer의 변경 내역을 Redo Log에 즉각(IMMEDIATE) 기록하며, 실제 Redo Log에 기록될 때까지 기다린다(WAIT). 이러한 수행 방식은 사용자에 의한 데이터 변경 내역이 Redo Log에 기록되어 사후 Recovery에 사용될 수 있다는 것을 100% 보장하기 위해서이다. COMMIT_WRITE 파라미터를 이용하면 이러한 Redo Log 기록 방식을 변경할 수 있다. 가능한 조합은 다음과 같다.

  • IMMEDIATE + WAIT: 기본 방식으로 Redo Write를 즉각 요청하고 기록이 끝날 때까지 기다린다.
  • IMMEDIATE + NOWAIT: 요청은 즉시 보내되, 기록이 끝나기를 기다리지 않고 사용자에게 제어권을 넘겨준다.
  • BATCH + WAIT: 여러 개의 Redo Write 요청을 모아서 한번에 요청하며, 기록이 끝날 때까지 기다린다.
  • BATCH + NOWAIT: 여러 개의 Redo Write 요청을 모아서 한번에 요청하며, 기록이 끝나기를 기다리지 않고 사용자에게 제어권을 넘겨준다.


참고 사항

COMMIT_WRITE와 OLTP/DSS

OLTP 환경에서는 COMMIT_WRITE 파라미터를 변경해서는 안된다. BATCH나 NOWAIT 모드의 Commit에서는 Redo Log에 데이터가 정확하게 저장된다는 보장이 없기 때문에 비정상적인 종료시 데이터의 정합성을 보장할 수 없다.
DSS 환경에서는 데이터의 세밀한 정합성이 불필요한 경우가 많기 때문에 성능 개선을 위해서 이 파라미터를 적극적으로 활용할 수 있다.

PL/SQL의 Asynchronous Commit

PL/SQL 블록 내의 Commit 요청은 마치 BATCH, NOWAIT 모드의 COMMIT_WRITE 파라미터를 사용하는 것과 같은 효과가 있다. 이를 Asynchronous Commit이라고 부른다. 따라서 배치 작업을 처리할 경우에는 PL/SQL을 사용하는 것이 성능면에서 유리하다.

관련된 정보들

  1. _WAIT_FOR_SYNC 파라미터
  2. _DISABLE_LOGGING 파라미터
  3. log file sync 대기이벤트

대용량의 데이터를 처리하는 경우(DSS/DW)에는 COMMIT_WRITE = BATCH, NOWAIT 를 지정함으로써 Commit에 의한 지연을 최소화할 수 있다.

또 하나의 재미있는 파라미터는 _WAIT_FOR_SYNC 이벤트이다. 이 파라미터를 FALSE로 지정하면 Commit 요청시 기록이 끝나기를 기다리지 않고 즉각 사용자에게 제어권을 넘겨준다. COMMIT_WRITE = NOWAIT 와 동일한 역할을 한다. COMMIT_WRITE의 등장과 함께 사라질 파라미터가 된 셈이다.
COMMIT_WRITE는 시스템 레벨, 세션 레벨, 트랜잭션 레벨에서 제어할 수 있다는 점이 특히 돋보인다.

또 하나의 있어서는 안될 것 같은 파라미터가 바로 _DISABLE_LOGGING 파라미터이다. 파라미터 정보는 다음과 같다.

기본 정보

Parameter 정보


Syntax_DISABLE_LOGGING
DefaultFALSE
설정방법
  • Parameter File
  • ALTER SYSTEM SET "_DISABLE_LOGGING" = FALSE
지원 대부분의 버전


설명

Redo Buffer의 내용을 Redo Log에 기록할 지의 여부를 지정한다. 만일 FALSE로 값을 지정하면 기록이 이루어지지 않는다. Import 작업이 Direct Load 작업의 성능을 높이기 위해 사용되는 경우가 있다. 하지만 데이터 정합성과 복구(Recovery)에 영향을 줄 수 있기 때문에 권장되지 않는다.

참고 사항

파라미터의 한계

_DISABLE_LOGGING 파라미터는 Redo Log에 기록되는 작업만을 제어한다. 값을 FALSE로 지정하더라도 다음과 같은 작업들은 여전히 이루어진다.

즉, Redo Log에 기록하는 실제 I/O 작업만이 이루어지지 않을 뿐 그 외의 Redo와 관련된 모든 작업은 다 이루어진다. 따라서 Redo Buffer의 크기가 큰 경우에 특히 유리하다. Redo Buffer의 크기가 크면 그 만큼 Log Switch가 덜 발생하고 Checkpoint 또한 이루어지지 않기 때문이다.

Import/Direct Load와의 관계

대량의 데이터를 로딩하는 경우 _DISABLE_LOGGING 파라미터를 사용하는 것보다는 Direct Load를 사용하는 것이 바람직하다. Direct Load를 사용하는 경우 Redo 데이터 기록을 하지 않기 때문에 성능을 극적으로 개선시킬 수 있다.

Direct Load를 사용할 수 없는 일반 Import의 경우에는 _DISABLE_LOGGING 파라미터가 도움이 될 수 있다. 그러나 이 경우에도 최후의 방법으로 남겨두는 것이 좋다. 사용 가능한 방법들은 다음과 같다.

  • Commit 빈도를 줄인다. 즉 가능한 여러 단위를 묶어서 Commit을 수행한다.
  • Index를 삭제한 상태에서 Loading한다. Loading이 종료되면 인덱스를 Nologging 모드로 재생성한다.
  • COMMIT_WRITE 파라미터를 사용한다.

관련된 정보들

  1. COMMIT_WRITE 파라미터
  2. _WAIT_FOR_SYNC 파라미터

이 파라미터는 정확하게 말하면 Commit이 아니라 Redo Log에의 기록 자체를 제어한다. 즉 Redo Buffer의 데이터를 Redo Log에 기록할 것인가 말것인가를 결정한다. FALSE로 지정하면 Redo 기록에 의한 Disk I/O가 사라지므로 그만큼 성능에 유리하다.

말 그대로 있어서는 안되는 파라미터이지만, 까다로운 고객을 만족시키기 위해 히든 파라미터로 추가된 셈이다. Direct Path Load를 사용할 수 없는 상황에서 대량 DML을 성능을 높이고자 할 경우 임시로 사용하는 목적으로 활용된다. 단, 인스턴스 크래시가 발생했을 때 복구가 이루어지거나 데이터 정합성이 맞을 것이라고 절대로 상상해서는 안된다.

COMMT_WRITE, _WAIT_FOR_SYNC, _DISABLE_LOGGING 이 세개의 파라미터를 비상 실탄처럼 가지고 있다가 다른 어떤 수단으로도 성능 개선이 어려울 때 사용하는 목적으로 활용해보기 바란다.


신고
tags : , ,
Trackback 0 : Comment 1
  1. oraking 2011.02.02 14:19 Modify/Delete Reply

    관리자의 승인을 기다리고 있는 댓글입니다

Write a comment

티스토리 툴바