작성
·
80
·
수정됨
0
안녕하십니까. 강의 너무 잘 듣고 있습니다.
질문이 생겨서 글을 남겨 봅니다.
질문 1.
index scan 시 buffer cache에 해당 블록이 없으면 디스크에 접근해야하는 random i/o가 발생하니까 sar 명령어로 보면 i/o wait 값이 20% 이상 올라가는건 이해가 됩니다.
궁금점은 용량이 큰 테이블을 full scan 시, direct path read가 발생할 것이고, 이는 디스크에서 바로 서버프로세스로 블록을 로드 하잖습니까. 근데 이떄도 분명히 i/o가 발생할텐데 왜 sar 명령어에서 i/o wait 값이 많이 올라가지 않을까요?? full scan은 multi block 으로 i/o를 읽기 때문에 그런건가요??
질문 2.
그리고 강의에서 말씀해주셨던 것 처럼 full scan시 테이블 용량이 1M(default)가 넘으면 direct path read가 발생한다고 하셨는데, 사실 요즘 시스템의 테이블은 거의다 1M이 넘을 것 같습니다. 그런데도 db file scattered 이벤트는 잘뜨던데 왜 그런걸까요?
감사합니다
답변 1
0
안녕하십니까,
IO Wait는 CPU가 Storage등에 I/O Request 를 요청하고, 처리가 완료되었다는 Response를 받기까지 대기하는 시간입니다. 그런데 Storage가 Random I/O의 처리 용량이 생각보다 낮습니다. 그리고 Sequential I/O(Full scan)의 용량이 생각보다 큽니다. 때문에 Random I/O 시 I/O Wait 가 훨씬 더 많이 발생합니다. 그리고 Sequential I/O 시에도 Storage의 Throughput을 초과하는 대용량의 Full Scan 시에는 I/O Wait가 크게 발생합니다.
11g 부터는 full scan 시 direct path read 를 수행할 수 있도록 개선이 되었으며, 강의에서 말씀드린대로 작은 테이블의 full scan 일 경우는 buffer cache에도 올라 갈 수 있지만(db file scattered read 이벤트) 일정 용량이 넘는 테이블은 direct path read로 처리하여 buffer cache에 못 올라가도록 되어 있습니다.
그리고 Wait Event 강의에서 말씀드린 대로 이런 방식으로 동작하려면 "_serial_direct_read" 가 True로 설정되어야 하고(Default로 True임), "_small_table_threshold" 값에 따라 small 테이블 크기가 설정되는데, 보통은 buffer cache의 2% 정도입니다. "_small_table_threshold" 값이 크면 해당 사이즈 이하의 테이블들은 db file scattered read 이벤트가 발생합니다.
감사합니다.