Db file parallel write

EXEM Knowledge Base

Jump to: navigation, 찾기

목차

[편집] Basic Info

이름이 암시하는 것과 달리, db file parallel write 대기이벤트는 병렬 처리(parallel DML)와 연관은 없다. 버퍼 캐시를 경유하는 모든 데이터는 DBWR에 의해 디스크에 기록이 된다. DBWR이 더티 블록를 기록하기 위한 I/O 요청을 보낸 후 요청이 끝나기를 기다리는 동안 db file parallel write 이벤트를 대기하게 된다. DBWR는 한번의 I/O 요청을 통해 하나의 더티 블록을 디스크에 기록하는 방식으로 동작하지 않는다. 한번의 I/O 요청에 여러 개의 더티 블록을 디스크에 기록하는 방식으로 동작하는데, 이것을 write batch라고 한다. DBWR가 write batch 를 수행한 후 I/O 요청이 완료되기를 대기할 때 해당 이벤트가 발생된다. 하지만 비동기식(asynchronous) I/O를 사용할 경우 DBWR는 I/O 요청이 완료되기를 대기하지 않는다. 단지 write batch 를 통해 디스크로 기록되어야 할 더티 블록들의 일부분이 디스크로 기록되고, 프리 버퍼(free buffer)로 변경된 후 LRU 리스트에 등록 되어질 때까지만 대기한다. 이것은 더 많은 쓰기 요청을 발생시킨다.

db file parallel write 대기는 기본적으로 I/O 이슈라고 보면 된다. 만일 DBWR 프로세스에서 이 대기가 광범위하게 나타난다면 데이터 파일과 관련된 I/O 시스템에 심각한 성능저하현상이 발생하는 것으로 판단할 수 있다. 만일 I/O 시스템의 성능에 문제가 없는데도 db file paralle write 대기가 사라지지 않는다면 그 때는 I/O 시스템이 감당할 수 없을 정도의 많은 쓰기 요청이 발생하는 것으로 간주할 수 있다.

[편집] Parameter & Wait Time

[편집] Wait Parameters

db file parallel write 대기이벤트의 대기 파라미터는 다음과 같다.

  • P1 : write batch 방식으로 동시에 쓰고 있는 파일 수
  • P2 : write batch 방식으로 동시에 쓰고 있는 총 블록 수
  • P3 : 오라클 9.2부터는 I/O 완료를 위해 대기한 시간을 1/100초 단위로 보여준다. 이전 버전에서는 총 I/O 요청 횟수를 나타낸다.

[편집] Wait Time

I/O관련 이벤트이므로 타임아웃이 발생하지 않으며, 세션은 I/O가 완료될 때까지 대기한다

[편집] Check Point & Solution

[편집] I/O 시스템의 성능이 느린 경우

만일 DBWR 프로세스에서 db file parallel write 대기시간이 길게 나타난다면 I/O 시스템에 문제가 있다고 판단할 수 있다. DBWR에서 db file parallel write 대기시간이 길어지면, 서버 프로세스는 연쇄적으로 free buffer waits 이벤트나 write complete waits 이벤트에 대한 대기를 겪게 된다. 이 문제는 I/O 시스템의 성능을 개선시킴으로써 해결가능하다. I/O의 성능을 개선시키는 것에는 다음과 같은 방법들이 알려져 있다.

  • 로 디바이스(Raw device)와 비동기 IO(Asychronous IO)를 조합해서 사용하는 것이 지금까지 알려진 최선의 방법이다.
  • OS 차원에서 Direct I/O를 사용한다. CPU 개수가 충분하다면, DB_WRITER_PROCESSES 파라미터 값을 조정해서 DBWR의 개수를 증가시키는 것을 병행할 수 있다. 복수개의 DBWR은 비동기를 흉내내는 효과를 갖는다. 오라클이 권고하는 DBWR 프로세스는 CPU_COUNT / 8 이다. V$FILESTAT 뷰를 이용하면 어떤 파일에서 주로 성능문제가 발생하고 있는지를 간접적으로 추론할 수 있다.

[편집] I/O 작업이 너무 많은 경우

잦은 체크포인트가 발생하는 경우 DBWR의 활동량이 지나치게 많아지고 이로 인해 DBWR의 성능이 저하될 수 있다. DBWR의 성능저하는 시스템의 전체적인 성능저하로 직결된다. FAST_START_MTTR_TARGET 파라미터 값을 지나치게 작게 주는 경우 빈번하게 증분 체크포인트(Incremental Checkpoint) 작업이 발생하게 된다. 로그 파일의 크기가 지나치게 작은 경우 잦은 로그 파일 스위치가 발생하게 되고 이로 인해 체크포인트 작업이 늘어난다. Parallel Query로 인해 direct path read가 발생하는 경우, truncate, drop, hot backup시에도 체크포인트가 발생한다. 만일 I/O 시스템의 성능 문제가 없는데도 db file parallel write 대기가 광범위하게 나타난다면 DBWR에게 불필요한 부하를 주는 요소는 없는지 살펴볼 필요가 있다.

[편집] 버퍼 캐시를 비효율적으로 사용하는 경우

DBWR의 성능을 간접적으로 개선시키는 또 한가지 방법으로 다중 버퍼 풀(Default, Keep, Recycle)을 적절히 사용하는 것이다.이 방법은 I/O 시스템의 성능을 개선한다기보다 불필요한 쓰기 작업을 줄여서 DBWR의 부담을 줄여 준다는데 의의가 있다.

[편집] Event Tip

[편집] 다중 버퍼풀과 LRU

다중 버퍼풀과 LRU을 참조하도록 한다.

[편집] Analysis Case