태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

[Oracle Forum] db file sequential read 대기와 Oracle I/O 성능에 대한 통찰...

오라클 2007.10.29 22:31
요즘 Oracle Forum(forums.oracle.com)에 가끔 방문해서 외국놈들과 영어로 토의를 즐기고 있다.
영어 공부도 되거니와, Oracle의 본토인 미국에서는 어떤 기술적인 주제들로 주로 논의가 이루어지는 그 트렌드를 놓치지 않을 목적도 있다.
내가 실제로 참여한 Thread 중에서 기술적으로 의미가 있는 것들을 블로그를 통해서 소개할려고 한다.

오늘의 소개 Thread은 아래와 같다. 길지만 꼭 읽어보기 바란다.

http://forums.oracle.com/forums/thread.jspa?threadID=579611&start=0&tstart=0

이 Thread의 발단은 이렇다.

"AWRReport를 보니까, db file sequential read 이벤트 대기 시간이 높게 나온다. 그래서 이것 저것 검색해본결과 Block Size가 큰 Tablespace를 만들고 여기다가 데이터를 옮기면 읽기 성능이 개선되지 않을까 한다...
님들은 어떻게 생각하나?"

즉, 읽기 I/O 성능을 높이기 위해 Large Block Size(가령 16K)를 사용하는 것을 어떻게 생각하느냐이다.
이 방법의 합리성을 두고 설왕설래가 이루어진다.

어떻게 생각하는가? Large Block Size 만으로만 보면 결론이 이렇다.

- I/O 성능을 위해서 Block Size를 키운다고? 꿈깨라...
- Multiple Block Size는 기본적으로 성능을 위해서 쓰라는 목적이 아니라, Tablespace 이동(Transportable Tablespace)을 위한 것이다.(자세한 내용은 구글 검색...)

BlockSize의 표준 크기인 8K는 사실상의 업계 표준이다. 이를테면 SQL Server 같은 경우는 Block(Page) 크기로8K외에는 사용할 수 없다. 읽기에서도 쓰기에서도 어느 한쪽으로 치우치지 않은 가장 균형을 이룬 그래서 업계에서 사실상의표준으로 인정한 크기가 8K인 셈이다.

오라클 I/O 성능과 관련해서는 많은 오해와 미신들이 있다. 가령 이런 주장들을 많이 봤을 것이다.

- 테이블과 인덱스의 테이블 스페이스를 분리하면 성능이 개선된다.
- 테이블 스페이스를 여러 개의 데이터 파일에 분산하면 성능이 개선된다.

진짜로? 개뿔 헛소리(^^)다. 일단 테이블 스페이스는 논리적인 데이터 저장소로 물리적인 성능과는 전혀, 100%, Never 무관하다. 데이터 파일 또한 OS의논리적인 저장소로 이 역시 물리적인 성능과는 아무런 관계가 없다. 실제로 Physical I/O의 성능 여부를 결정하는 것은오직 독립적인 디스크, 혹은 디바이스, 그리고 그와 연동되는 채널뿐이다.

즉, 하나의 테이블이 여러 개의독립적인 디바이스에 분산되어 있다면 I/O 병목 현상을 피할 수 있다. RAID가 이런 효과를 노리는 것이다. RAID로 구성된여러 개의 독립적인 디바이스에 데이터 파일을 분산시킨다면 그 효과는 더욱 커진다. 반면 하나의 테이블을 아무리 여러 개의 데이터파일에 분산시켜도 이들 데이터 파일들이 소수의 디바이스에 분산되어 있다면 I/O 병목 현상을 피할 수 없다.

이런 이유로 오라클의 권고안은 이렇다.
"데이터 파일을 되도록이면 여러 개의 디바이스에 랜덤하게 분산시켜라!!!"
이를 줄여서 흔히 SAME(Striper and Mirror Everywhere)라고 한다.

SAN과 같은 엔터프라이즈급의 스토리지에서는 수십개의 독립적인 디바이스를 논리적으로 하나의 파티션으로 구성할 수 있고, 따라서 디바이스 경합에 의한 I/O 병목 현상을 방지한다. 비싼 값을 하는 셈이다.

이 문장을 명심해서 기억하자.
"Independent device rules everything"

---------------------------------------------------------------
이 글은 티스토리 블로그(http://ukja.tistory.com)에도 동일하게 등록됩니다.
Trackback 0 : Comments 8
  1. 쏘심이 2007.10.30 15:11 신고 Modify/Delete Reply

    테이블과 인덱스의 테이블 스페이스를 분리하면 성능이 개선된다. <--- 이건 맞는 소리 아닌가요??

  2. 욱짜 2007.10.30 15:30 신고 Modify/Delete Reply

    그게 맞는 소리가 아니라는게 실제로는 정설입니다. 테이블스페이스는 성능과는 무관합니다. 논리적인 관리를 위한 개념이며, 물리적인 성능과는 무관하다는 의미입니다. 물리적인 성능은 오로지 물리적인 매체, 즉 디바이스(디스크)와 채널에 따라 결정됩니다. 한때 오라클에서 전설적이었다는 엔지니어 분이 적(소속)을 스토리지 쪽으로 옮기신 바가 있습니다. 그 분이 스토리지쪽 개념을 알게 되고서는 "오라클 있을 때 테이블/인덱스 테이블스페이스 구분하라고 권장했었는데 모두 엉터리였다..." 구글에서 관련된 글을 꼭 검색해보세요.

  3. 쏘심이 2007.10.30 15:32 신고 Modify/Delete Reply

    아.. 흥미롭습니다. 감사합니다^^

  4. 멀더엄마 2007.11.02 13:46 신고 Modify/Delete Reply

    우리도 데이터랑 인덱스랑 분리해서 쓰는데... (인덱스 만들때마다 귀찮은 면이 있음.)
    두개의 테이블 스페이스를 분리하는것 자체가 왜 성능에 영향을 주는지 이해가 안가고 있었음.

  5. 맨땅헤딩 2007.11.16 01:40 신고 Modify/Delete Reply

    제 짧은 소견이지만 저도 예전에 많이 고민했던 내용이어서, 제 블로그에 엮인글을 적어보았습니다. 괜챦겠죠?

  6. 고구마 2009.01.15 11:32 신고 Modify/Delete Reply

    안녕하세요.
    욱짜님의 글을 지면으로 화면으로 자주 접하고 있습니다.
    이 글을 읽고 Advanced OWI in Oracle10g의 내용중 다음과 같은 내용이 있었습니다.(Page 323)

    큰 크기의 블록을 사용하는 것 또한 FTS의 성능을 향상시키는 방법이다. ... 같은 크기의 테이블을 구성하는데 적은 수의 블록을 사용하게 된다. 따라서 그 만큼 멀티 블록I/O가 줄어든다....블럭사이즈가 크면 로우체이닝이나 로우마이그레이션이 발생될 확률이 낮아진다...따라서 부가적인 I/O가 줄어들게된다....

    Large Block Size에 대하여 위 글과 책의 내용이 조금 상반되는것으로 이해되는데요.
    욱짜님께서 이 부분에 대해서 정리를 해주시면 감사하겠습니다.

  7. 욱짜 2009.01.15 12:37 신고 Modify/Delete Reply

    사실 그 자체만 보면 큰 크기의 블록이 FTS의 성능을 향상시킬 *가능성*이 있는 것은 사실입니다. 문제는 어느 정도 향상되는지는 액세스 패턴과, 스토리지와 환경 설정의 영향을 받기 때문에 실제로 검증해보지 않으면 알 수없다는 것입니다. 블록 크기에따라 성능 차이가 거의 나타나지 않을 가능성도 큽니다.

    더 중요한 문제는 이런 대량의 FTS는 OLTP에서는 잘 발생하지 않는다는 것입니다.
    만일 DW환경처럼 대량의 FTS가 빈번하다면 의미가 있겠죠.

    그래서 잠정적인 결론은 특별한 이유가 없는 한 표준 블록 크기(8K)를 사용하는 것이 최선이고 실제로 대부분의 시스템이 그렇게 운영되고 있습니다. OLTP 환경이라면 특히 그렇고, DW 환경이라면 테스트를 통한 성능 개선 확인 후에 좀 더 큰 크기의 블록 크기를 사용하면 됩니다.

    블록 크기에서 또 하나의 중요한 이슈는 하나의 데이터베이스에서 여러 개의 블록 크기(Tablespace A는 8K, Tablespace B는 16K, ...)를 사용할 필요가 있느냐입니다. 이것 역시 아주 특별한 경우를 제외하면 "없다"입니다.

    그렇다면 왜 오라클은 하나의 Database내에서 다중 블록 크기(Multiple Block Size)를 지원하는가? 그 이유는 Transportable Tablespace 때문입니다. Database A가 8K 블록 크기를, Database B는 16K 블록 크기를 사용하고 있습니다. 어떤 이유때문에 Database B의 Tablespace를 Database B로 Transport하고 싶습니다. 이것을 가능하게 하기 위해 다중 블록 크기를 지원하는 것입니다. 절대로 사용자가 마음대로 블록 크기를 조정하게 하겠다는 의도가 아니라는 것입니다.

  8. 고구마 2009.01.15 13:22 신고 Modify/Delete Reply

    역시 명확하게 정리를 해주시는군요.
    감사합니다.

Write a comment