Direct path read/write(lob)

EXEM Knowledge Base

(Direct path read(lob)에서 넘어옴)
Jump to: navigation, 찾기

목차

[편집] Basic Info

LOB 컬럼을 생성할 때 NOCACHE 옵션을 사용하면 LOB 세그먼트를 읽고 쓰는 작업은 direct path I/O를 사용하며 이 경우 direct path read(lob), direct path write(lob) 이벤트를 대기하게 된다. CACHE 옵션을 사용해서 LOB 컬럼을 생성하면 버퍼 캐시를 경유하게 되므로 일반 데이터와 동일한 메커니즘을 따르게 된다.

LOB을 생성할 때 CACHE와 NOCACHE 중 어떤 옵션을 사용해야 하는지는 시스템의 특성과 데이터의 특성에 따라 다르다. 만일 SGA의 크기가 여유가 없거나 LOB 데이터의 크기가 크다면 NOCACHE를 사용하는 것이 유리하다. LOB 데이터가 크지 않고, 자주 액세스되는 범위가 정해져 있다면 CACHE 옵션을 사용함으로써 성능 개선 효과를 얻을 수 있다.

[편집] Parameter & Wait Time

[편집] Wait Parameters

direct path read/write(lob) 대기이벤트의 대기파라미터는 다음과 같다.

  • P1 : Absolute File#
  • P2 : Starting Block#
  • P3 : 블록수

[편집] Wait Time

I/O관련 이벤트이므로 타임아웃이 발생하지 않으며, I/O 가 완료될 때까지 소요된 시간을 나타낸다.


[편집] Check Point & Solution

[편집] Event Tip

[편집] LOB 생성시 주의사항

LOB은 데이터의 속성상, 다른 데이터타입에는 없는 다양한 옵션들이 존재한다. 부주의하게 사용할 경우 많은 성능문제를 야기할 수 있다. LOB 생성시 다음과 같은 사항들에 주의해야 한다.

  1. enable storage in row 옵션을 사용하는 경우 4000 bytes 보다 작은 LOB 데이터는 로우와 같은 블록에 저장된다. 따라서 Row chaining을 유발할 가능성이 높다. 4000 bytes보다 큰 LOB 데이터는 disable storage in row 옵션을 사용한 것과 같은 효과가 있다. LOB 데이터의 크기를 고려하여 만일 Row chaining이 발생할 가능성이 높다고 판단되면 disable storage in row 옵션을 사용하는 것이 좋다. 로우와 같은 블록에 저장되는 LOB 데이터를 In-line LOB이라고 부르며, LOB 세그먼트에 저장되는 경우에는 Out-of-line LOB이라고 부른다.
  2. disable storage in row 옵션을 사용하는 경우 LOB 데이터는 별도의 LOB 세그먼트에 저장되며 Row 내에는 20 bytes의 LOB Locator 정보만 저장된다. 이 경우 언두 데이터는 LOB Locator에 대해서만 생성된다. LOB 데이터에 대한 실제적인 언두 정보는 언두 테이블스페이스에 저장되지 않고 같은 LOB 세그먼트 내에 저장됨에 유의해야 한다. LOB 세그먼트의 언두는 PCTVERSION 옵션에 의해 제어되는데, 가령 PCTVERSION이 50이면 LOB Segment의 공간 중 50%가 언두 정보를 저장하는데 사용된다. 따라서 PCTVERSION을 낮게 주는 경우 예기치 않은 ORA-01555 : snapshot too old 에러가 생길 수 있다. LOB 세그먼트의 언두 영역 부족에 따른 snapshot too old 에러의 경우 rollback segment name이 공백으로 나온다. PCTVERSION이 너무 작으면 ORA-01555 에러가 발생할 확률이 높아지고, PCTVERSION이 너무 높으면 공간의 낭비가 심해진다. 이 문제를 해결하는 방법은 일반 롤백 세그먼트에서의 ORA-01555 에러의 경우와 동일하다. PCTVERSION을 적절히 유지하고 불필요한 커밋을 줄인다. LOB 세그먼트의 확장공간을 적절히 확보해주는 것도 중요하다.
  3. CACHE / NOCACHE, LOGGING / NOLOGGING : 만일 LOB 데이터의 크기가 크고 자주 액세스되지 않거나, 무작위적으로 액세스된다면 NOCACHE 옵션을 사용하는 것이 바람직하다. NOCACHE 옵션을 사용하는 경우 리두를 생성할 지의 여부도 지정할 수 있다. 만일 반드시 복구가 될 필요가 없는 데이터라면 Nologging 옵션을 사용함으로써 성능개선효과를 얻을 수 있다. CACHE 옵션을 사용하는 경우에는 반드시 Logging 속성을 지니게 된다. NOCACHE 옵션을 사용하는 경우 버퍼 캐시를 경유하지 않기 때문에 direct path read(lob), direct path write(lob) 이벤트를 대기하게 된다. 하지만 CACHE 옵션을 사용하는 경우에는 버퍼 캐시를 경유하기 때문에 db file sequential readlatch: cache buffers chains 대기를 유발할 수 있다.
  4. 청크(chunk)의 크기 : Out-of-line LOB인 경우 청크 단위로 LOB 데이터를 저장하게 된다. 큰 청크 사이즈의 문제는 공간이 낭비될 가능성이 높다는 것이다. 만일 청크가 8K로 되어있는데, 1K 크기의 LOB 데이터가 삽입된다면 나머지 7K의 공간은 사용할 수 없게 된다. 따라서 청크 사이즈를 결정할 때는 대상이 되는 LOB 데이터의 크기를 고려해서 결정해야 한다. 청크의 크기 단위는 기본적으로 블록 사이즈의 배수가 된다. 만일 블록 사이즈가 8K인 경우 청크의 크기를 5000 bytes로 주면 오라클은 암묵적으로 8192 bytes로 변환한다. 청크의 크기를 지나치게 작게 하는 경우에는 연속적으로 청크를 할당받는 과정에서 오버헤드가 발생하게 된다.

[편집] Analysis Case