태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

Oracle 10gR2의 Autotuned MBRC

오라클 2008.02.11 17:34
Oracle에서 MBRC(Multi Block Read Count) 만큼 간단 명료한 개념이 있을까? 말 그대로 Multi Block I/O(Full Table Scan, Index Fast Full Scan 등)를 수행할 때 한번에 읽어 들일 블록수를 결정한다.

하지만, 역사적인 이유 때문에 지금은 가장 헷갈리는 개념이 되어 버렸다. 지금 이렇게 정리를 하고 있는 나 스스로도 좀 짜증이 날 정도로 개념이 혼용되고 있다. 역사적인 이유라고 하니, Oracle이 어떤 역사에 의해 MBRC의 개념을 복잡하게 만들었는지 확인해 보자.

1. 9i 이전까지는 오직 하나의 MBRC만이 있었다. db_file_multiblock_read_count라는 이름의 파라미터에 의해 결정되었으며, Optimizer의 비용 계산과 실행 시의 Mullti Block I/O 모두에 이 값이 사용되었다. 여기서 비극이 잉태된 것인데, Multi Block I/O 성능을 높이려고 하면 Optimizer의 비용 계산에 영향을 주는 아이러니한 상황이 생기는 것이다.

2. 9i에서 System Statisitics가 소개되면서 System MBRC라는 개념이 탄생했다. System Statistics를 수집하면 v$filestat과 v$sysstat을 참조해서 현재 시스템에서 보편적으로 사용되는 MBRC 값을 추출한다. 이 값은 Optimizer의 비용 계산에만 사용된다. 반면 db_file_multiblock_read_count 값은 Multi Block I/O 수행시에만 사용된다. 비로소 Optimizer 용과 실행용, 두 가지의 MBRC가 생긴 것이다.
하지만, 9i에서 System Statistics가 잘 사용되지 않아서 이 사실이 널리 공유되지 못했다.

3. 위의 개념은 10gR1까지 그대로 계승된다.

4. 10gR2에서 Oracle은 또 한번 개념을 흔들었다.
우선, System Statistics의 사용 방식은 이전 버전과 동일하다. 하지만 다음과 같은 두 개의 히든 파라미터가 소개되었다. _db_file_optimizer_read_count_db_file_exec_read_count. 전자는 Optimizer의 비용 계산에 사용되는 MBRC이고 후자는 Multi Block I/O 실행시에 사용되는 MBRC이다. 따라서 System Statistics가 없다고 하더라도 우리는 이 두 개의 히든 파라미터를 이용해서 이전보다 더 디테일한 제어가 가능해졌다.
또 다른 변화는 db_file_multiblock_read_count 파라미터 초기값의 변화이다. 10gR1까지는 항상 "8"이 기본값이다. 하지만 10gR2부터는 오라클이 판단하기에 사용가능한 최적값이 기본값이 된다. 따라서 이 값은 시스템마다 다르며 보통 50 ~ 128 사이의 값이다. 이 경우 _db_file_exec_read_count 값은 최적값(=db_file_multiblock_read_count)로, _db_file_optimizer_read_count 값은 8로 설정되어 큰 값의 MBRC가 Optimizer의 비용 계산에 영향을 주는 것을 방지한다. 이러한 기능을 흔히 Autotuned MBRC라고 부른다. 즉, 10gR2에서는 MBRC 값이 시스템에 최적화되어 기본 설정된다. 이 값은 Multi Block I/O를 실행하는데만 사용되므로 System Statistics에 의한 MBRC는 여전히 중요한 의미를 지닌다.

위의 스토리가 다 이해가 되는가? 너무나 구구 절절해서 적으면서도 약간 짜증이 날 정도이다. 긍정적인 점은 Oracle이 최적의 MBRC를 스스로 찾을 수 있도록 개선되고 있다는 것이다. DBA가 신경쓸 것은 System Statistics를 수집할 지 말지만을 결정하는 것이라고 보면 정확할 것이다. 물론 버전마다 기본 행동 방식이 이렇게 흔들리는 것은 DBA나 성능 전문가로서는 여간 성가신 일이 아니다. 하지만 결국 Oracle의 성능을 보다 합리적으로 관리하자는 목적을 가지고 있는 것이니 잘 활용하자는 것만이 우리에게 남겨진 몫일 것이다.

Autotuned MBRC에 대한 자세한 내용은 아래 글을 참조한다.

http://wiki.ex-em.com/index.php/DB_FILE_MULTIBLOCK_READ_COUNT

PS1) Oracle 10gR2 Reference Manual에 위의 내용이 아래와 같이 잘 설명되어 있다.

As of Oracle Database 10g release 2, the default value of this parameter is a value that corresponds to the maximum I/O size that can be performed efficiently. This value is platform-dependent and is 1MB for most platforms.
Because the parameter is expressed in blocks, it will be set to a value that is equal to the maximum I/O size that can be performed efficiently divided by the standard block size. Note that if the number of sessions is extremely large the multiblock read count value is decreased to avoid the buffer cache getting flooded with too many table scan buffers.

Even though the default value may be a large value, the optimizer will not favor large
plans if you do not set this parameter. It would do so only if you explicitly set this parameter to a large value.

PS2) 만일 10gR2에서 db_file_multiblock_read_count 값이 의외로 작게 설정되어 있다면 Parameter File에서 강제로 이 파라미터 항목을 삭제하고 Oracle을 재시작하면 Autotuned MBRC 값으로 지정된다.
신고
Trackback 0 : Comments 2
  1. adenkang 2009.08.03 20:00 신고 Modify/Delete Reply

    안녕하세요?

    블로그를 통해서 좋은 정보를 많이 얻고 있습니다. system statistics에 대해서 조금 혼동스러운 부분이 있어서 질문을 합니다. 블로그에서는 system statistics에 대해서 수집하는 것을 권장하고 있습니다. Oracle에서 생기는 변화를 봐도 이 기능을 수집해서 사용하는 것이 저도 좋을 것으로 판단이 됩니다. (물론 실무에서 적용해보지 않았기 때문에 100% 확신은 없습니다.)
    Optimizing Oracle Optimizer 책에 이 부분에 대해서 high-end storage에서 disk cache로 인해서 실행가능한 값이 설정되지 않는다는 언급이 있어서 그렇다면 결국 system statistics를 수집해도 인위적으로 조절을 해줘야 하는 것인데 그렇다면 어떻게 조절을 하는 것이 좋을지??
    실무 경험 사례가 있다면 조언 부탁드립니다.

  2. 욱짜 2009.08.03 21:17 신고 Modify/Delete Reply

    adenkang님 반갑습니다.

    System Statistics를 바라보는 제 정확한 관점은 "Index Scan과 Full Table Scan의 비용을 결정하는 각종 파라미터들(db_file_multiblock_read_count와 optimizer_index_cost_adj, optimizer_index_caching 등)의 자동화 버전"으로 요약할 수 있습니다. 즉 파라미터를 통해서 매뉴얼하게 관리해주어야 했던 것을 조금 더 자동화시킨 것에 불과합니다.

    자동화했기 때문에 더 편리하죠. 수동보다는 오토가 편한 것과 같은 원리입니다. 하지만 문제는 아직 Oracle이라는 소프트웨어가 자동차의 오토기어만큼 진화하지 못했다는 것입니다. 따라서 아직 많이 부족합니다. 또는 자동차라는 단순한 모델에 비해 소프트웨어가 지니는 복잡성 때문에 자동화하는 것이 아직은 어렵다고 봐도 좋습니다. 지금의 System Statistics 모델은 과도기적인 위치에 있다고 봅니다. 따라서 과감하게 사용해보는 경우도 있고, 적용을 꺼리는 경우도 아주 많습니다.

    어떤 사이트에 갔더니 Oracle 엔지니어가 System Statistics는 문제가 많으니 쓰지 말라고 했다는군요. 이것을 말 그대로 받아들이면 정말 웃지못할 희극적인 상황입니다. 실제 상황은 더 복잡했을 것이고 그렇게 말할 수 밖에 없었던 어떤 사유가 있을 것이라고 믿고 있습니다만...

    System Statistics를 완전히 자동으로 맡길 수가 없어서 어쩔 수 없이 수동으로 값을 바꾼다는 사실은 원래 목적에 완전히 위배되는 것입니다. 그래서 개인적으로 추천하지 않습니다. 하지만 현실은 훨씬 복잡하죠. 여기에 대한 상세한 논의가 이미 공론화된 바가 있습니다. 아래 URL을 읽어 보시고 추가적인 논의를 하시면 좋겠습니다.

    http://jonathanlewis.wordpress.com/2007/04/30/system-statistics/
    http://jonathanlewis.wordpress.com/2007/05/20/system-stats-strategy/
    http://jonathanlewis.wordpress.com/2007/10/17/system-statistics-3/

Write a comment

티스토리 툴바