3._Single_Block_vs._Multiblock_IO
2012.05.22 20:55
1. 읽고자 하는 볼륨을 버퍼 캐시에서 찾지 못했을때, I/O Call을 통해 데이터파일로부터
버퍼 캐시에 적재하는 방식에는 크게 두가지가 있다.
o. Single Block I/O
한번의 I/O Call에 하나의 데이터 블록만 읽어 메모리에 적재
인덱스를 통해 테이블을 엑세스할때는, 기본적으로 인덱스와 테이블 블록 모두 이 방식을 사용한다.
o. Multiblock I/O
I/O Call이 필요한 시점에 인접한 블록들을 같이 읽어 메모리에 적재
보통 오라클 블록 사이즈와 상관없이 OS상에서 보통 1MB단위로 I/O를 수행한다.
이 방벙은 인접한 블록들을 같이 읽는 것이 유리하다. 인접한 블록이란 한 익스텐트 내에 속한 블록들이다.
즉, 이 방식으로도 익스텐트 범위를 넘지 못한다는 의미이기도 하다.
Multiblock I/O 단위: db_file_multiblock_read_count
만약 이 값이 16이면 한번에 최대 16개 블록을 버퍼 캐시에 적재한다. MAX치는 결국 OS가 허용하는 I/O단위가 된다.
2. 디스크 I/O는 I/O Call 한번에 여러 블록을 읽는게 성능 향상에 도움이 되나 인덱스 스캔할때는 왜 한 블록씩 읽을가?
- 인덱스 블록간 논리적 순서는 물리적 데이터파일에 저장된 순서와 다르다.
인덱스 리프 블록끼리 이중 연결 리스트 구조로 되어 있으며 물리적으로 한 익스텐트에 속한 블록들을 I/O Call 발생시
적재해 올렸어도 논리적 순서로는 멀리 떨어져 있을 수 있다. 그렇게 되면 올렸던 블록들은 실제 사용되지 못한 채 버퍼 상에서
밀려버리게 되고 이런 현상이 자주 발생한다면 버퍼 캐시 효율만 떨어지게 된다.
- Index Full Scan역시 Single Block I/O 방식으로 읽는다. 하지만 인덱스의 논리적 순서를 무시하고 물리적인 순서에 따라
읽는 스캔 방식이 있는데 이것을 'Index Fast Full Scan"이라고 한다. (Multiblock I/O 사용)
3. 서버 프로세스는 디스크에서 블록을 읽어야 하는 시점마다 I/O 서브시스템에 I/O 요청을 하고 대기 상태에 빠진다.
(1) db file sequential read : Single Block I/O
(2) db file scatterd read : Multiblock I/O
대량의 데이터를 Multiblock I/O 방식으로 읽을때 성능이 좋은 것은 I/O Call 발생횟수를 그만큼 줄여주기 때문이다.
논리적으로 65개 블록을 읽는 동안 64개의 디스크 블록을 읽었다.
또한 이벤트를 보면 db file sequential read 대기 이벤트가 64번 발생했다.
즉, 64개 인덱스 블록을 Disk에서 읽으면서 64번의 I/O Call이 발생한 것이다.
이제 Multiblock I/O방식으로 읽는 경우를 보기 전 파라미터 파일을 확인한다.
- 위 Single block I/O와 동일한 개수의 64개 블록을 읽는다고 예상했을때 4회로 추정된다 (64/16)
- index fast full scan 방식으로 유도하기 위해 힌트를 사용한다.
아래는 Multiblock I/O로 데이터를 읽은 것이다.
- 똑같이 64개 블록을 디스크에서 읽었는데 I/O Call이 9번에 그쳤다. 그런데 예상과는 달리 왜 9번인가?
- 그 이유는 해당 테이블스페이스의 익스텐트 크기로 알수 있다.
모든 익스텐트가 8개 블록으로 구성되어 있었기 때문이다.
- 10g부터는 Index Range Scan과 Index Full Scan 시에 Multiblock I/O 방식으로 읽는 경우가 있는데
위처럼 테이블 엑세스 없이 인덱스만 읽고 처리할 때가 그렇다. 테이블을 Random 엑세스 할때는 모두 Single Block I/O로 처리
- Single block I/O -> LRU리스트상 MRU쪽으로 연결되어 버퍼 캐시에 비교적 오래 머문다.
반면, Multiblock I/O는 LRU쪽에 연결되어 얼마 지나지 않아 버퍼에서 밀린다.
따라서 대량의 데이터를 Full Scan했다해도 사용빈도가 높은 블록들이 버퍼 캐시에서 모두 밀려날거란 걱정은 하지 않아도 된다.
댓글 0
번호 | 제목 | 글쓴이 | 날짜 | 조회 수 |
---|---|---|---|---|
66 | 부록 | 남송휘 | 2012.06.05 | 2708 |
65 | 8._IO_효율화_원리 | 운영자 | 2012.06.05 | 4426 |
64 |
3._Deterministic_함수_사용_시_주의사항
![]() | 정찬호 | 2012.05.29 | 4351 |
63 | 2._Cursor_Sharing | 운영자 | 2012.05.28 | 6276 |
62 | 7._Result_캐시 | 운영자 | 2012.05.27 | 4426 |
» |
3._Single_Block_vs._Multiblock_IO
![]() | 정찬호 | 2012.05.22 | 4229 |
60 |
2._Memory_vs._Disk_IO
![]() | 정찬호 | 2012.05.22 | 4446 |
59 |
1._블록_단위_IO
![]() | 정찬호 | 2012.05.22 | 4209 |
58 |
6장._IO_효율화_원리
![]() | 정찬호 | 2012.05.22 | 4085 |
57 |
1._Library_Cache_Lock_Pin
![]() | 남송휘 | 2012.05.21 | 4290 |
56 |
6._RAC_캐시_퓨전
![]() | 남송휘 | 2012.05.21 | 17797 |
55 | 5._Direct_Path_IO | 남송휘 | 2012.05.21 | 7932 |
54 |
4._Prefetch
![]() | 남송휘 | 2012.05.21 | 3889 |
53 | 8._PLSQL_함수_호출_부하_해소_방안 | 남송휘 | 2012.05.21 | 3773 |
52 | 5._Fetch_Call_최소화 [1] | 박영창 | 2012.05.15 | 6065 |
51 |
7._PLSQL_함수의_특징과_성능_부하
![]() | 남송휘 | 2012.05.14 | 6935 |
50 | 6._페이지_처리의_중요성 | 남송휘 | 2012.05.14 | 3379 |
49 | 4._Array_Processing_활용 | 시와처 | 2012.05.13 | 4042 |
48 |
3._데이터베이스_Call이_성능에_미치는_영향
![]() | 시와처 | 2012.05.13 | 3645 |
47 |
10._Dynamic_SQL_사용_기준
![]() | 남송휘 | 2012.05.07 | 4556 |