의 
블로그
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 값으로 지정된다.
하지만, 역사적인 이유 때문에 지금은 가장 헷갈리는 개념이 되어 버렸다. 지금 이렇게 정리를 하고 있는 나 스스로도 좀 짜증이 날 정도로 개념이 혼용되고 있다. 역사적인 이유라고 하니, 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 값으로 지정된다.
'오라클' 카테고리의 다른 글
| RTFM and BAAG - Oracle 사용자의 명제들 (1) | 2008.02.17 |
|---|---|
| Query Transformation의 재미있는 사례 - Oracle의 버그일까, 아니면... (0) | 2008.02.14 |
| Oracle 10gR2의 Autotuned MBRC (2) | 2008.02.11 |
| Must Read Oracle Books Before You Retire (0) | 2008.02.10 |
| Oracle 11g Interval Partition의 버그 (3) | 2008.02.09 |