일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
Tags
- Linux
- db
- implicit
- Python
- terraform
- golang
- 프로그래머스
- vm
- VMware
- 티베로
- python3.7
- 묵시적 커서
- 리눅스
- tas tac
- 파이썬
- vm tac 구성
- tibero
- tac
- Tuple
- tablespace
- 코딩테스트
- OPEN CURSOR
- CentOS
- DDL 추출
- VM 설정
- X11
- oracle
- 코테
- 암시적 커서
- X11 forwarding
Archives
- Today
- Total
줄기세포
[Tibero] Physical IO / Logical IO 본문
개념
- Logical I/O: Data Buffer Cache에서 읽고 쓰는 것을 말함
- Phygical I/O: Data Buffer Cache에 찾으려는 Block이 존재하지 않을 때, Disk에서 읽어 Buffer로 올리는 것을 말함
Disk에서 읽고 쓰는 것이 Cost가 크기 때문에 PIO를 줄이는 것이 쿼리 튜닝에 핵심일 수 있다.
하지만, PIO만큼 LIO를 줄이는 것도 중요하다고 주장하는 글이 있어서 요약해보려고 한다.
캐리 밀샙(Cary Millsap) 의 글
Oracle LIO은 생각보다 많은 비용을 발생시킨다.
LIO는 비지니스 프로세스에서 가장 많은 바틀넥을 발생시킨다. Buffer Cache Hit Ratio가 아무리 높다고 해도
LIO Call은 가장 Cost가 높은자원인 CPU와 Latch를 사용하고 이는 속도에 큰 장애가 된다.
Memory가 충분하며 Buffer Cache Hit Ratio가 100%라고 해도, LIO가 많으면 비효율적이다.
DB 통계를 보면, PIO가 Bottleneck인 것 처럼 나온다. 그렇다고 해도, PIO가 end-user의 reponse time에 영향을 확인하기 까지 disk나 memory capa를 늘리지마라.
대신, 쿼리 최적화의 초기부터 LIO를 줄이는 것에 집중한다면, PIO는 같이 줄어들 것이다. 이유는 PIO는 LIO Call에 의해 일어나기 때문이다.
'DB > Tibero' 카테고리의 다른 글
[Tibero] Client 설치 - Centos7 (0) | 2023.05.04 |
---|---|
[TIBERO] Python <=> Tibero-JDBC 연동 (0) | 2023.02.20 |
[Tibero] PLUSTRACE ROLE 생성 (0) | 2022.03.15 |
[Tibero] 티베로 필수 설치 패키지 (0) | 2022.02.21 |
[Tibero] SQL 플랜 (0) | 2022.02.21 |
Comments