db file Sequentail read VS db file Scattered read
!IO_30.jpg!
db file Sequentail read
Event 정의
# I/O System 에 Single Block I/O 를 요청 하고 응답이 오기를 기다리는 Event
# P1 = file#
# P2 = Block#
# P3 = 1
# 이 이벤트는 인덱스 스캔, 롤백 또는 언두 세그먼트 읽기, ROWID 에 대한 테이블 액세스,
컨트롤 파일 재구성(rebuild), 데이타 화일 헤더 덤프(dump) 또는 데이터파일 헤더를 읽을 때 발생된다.
SQL > select * from v$bh WHERE file# =<P1> and block# = <P2>
Or
SQL > ALTER SYSTEM DUMP DATAFILE <P1> BLOCK <P2>
# db file sequential read 가 비정상적으로 높다면 아래 부분은 점검 한다.
# OS 의 Disk 구성(Raid, file system or raw device 등등)
# OS I/O 처리방식
# Disk read/write I/O 처리 성능
# Active Session 간의 경합
# DB server 의 I/O 발생량
db file sequential read 발생 사유
# Single Block I/O
# index 를 경유한 Scan : Index Range Scan , Index Unique Scan , Index full Scan
# Chained Row / Migrated Row ( Single Block I/O 시 )
# Multi Block I/O 도중에도 발생 가능
db file sequential read 대기 과다 원인
# 비효율적인 Index Scan
# SQL Tuning
# index 변경
# 지나치게 높은 Clustering Factor
# Table Reorg 를 통해 해결
# 지나치게 깊은 Index 깊이
# Index Rebuild 를 통해 해결
# I/O System 성능 저하
# Disk I/O 성능 개선
# Hot Spot 해소 : Logical Volumn Level Striping, ASM 등
Clustering Factor ( CF )
# 군집도, Table 이 얼마나 Index 와 잘 뭉쳐 있는가를 판단하는 값
# Index Scan 에 따른 Table Block I/O 회수
# DBA_INDEXES.CLUSTERING_FACTOR
!Re_IO_27.jpg!
[ 산정방법 ]
1. 인덱스를 정렬하여 스캔한다.
2. 현재 인덱스 값의 rowid 에서 가리키는 블록값을 바로 전 인덱스 값의 rowid 에서 가리키는 블록값과 비교한다.
3. 위의 rowid 의 블록이 서로 다른 블록이라면 count 를 1 증가시킨다.
4. 전체 인덱스를 모두 스캔한다.
5. 결과 count 의 값이 Clustering Factor 가 된다.
# Table Block 수 <= CF <= Table Row 수
# 값이 작을 수록
# 군집도가 뛰어남
# Disk I/O 가 줄어듦
# Cache Buffer 가 효율적으로 사용됨
# 넓은 범위의 Index Scan 시에 대한히 중요
# 좁은 범위의 Index Scan 에서는 큰 영향 없음
# 높은 CF 문제의 해결 방법
# Table Reorg : Table 을 Index 와 같은 순서로 변경
# IOT 사용 고려
# IOT : Index Organized Table
# B*Tree 형태로 관리되는 Table
# 항상 Index key 키와 동일한 물리적인 순서 보장
# SQL Server 나 DB2의 Clustered Index 와 비슷한 개념
# 일반적으로 잘 사용되지 않음
# Hot Spot 과 Logical Volumn Striping
!Re_IO_28.jpg!
!IO_30.jpg!
db file Sequentail read
Event 정의
# I/O System 에 Single Block I/O 를 요청 하고 응답이 오기를 기다리는 Event
# P1 = file#
# P2 = Block#
# P3 = 1
# 이 이벤트는 인덱스 스캔, 롤백 또는 언두 세그먼트 읽기, ROWID 에 대한 테이블 액세스,
컨트롤 파일 재구성(rebuild), 데이타 화일 헤더 덤프(dump) 또는 데이터파일 헤더를 읽을 때 발생된다.
SQL > select * from v$bh WHERE file# =<P1> and block# = <P2>
Or
SQL > ALTER SYSTEM DUMP DATAFILE <P1> BLOCK <P2>
# db file sequential read 가 비정상적으로 높다면 아래 부분은 점검 한다.
# OS 의 Disk 구성(Raid, file system or raw device 등등)
# OS I/O 처리방식
# Disk read/write I/O 처리 성능
# Active Session 간의 경합
# DB server 의 I/O 발생량
db file sequential read 발생 사유
# Single Block I/O
# index 를 경유한 Scan : Index Range Scan , Index Unique Scan , Index full Scan
# Chained Row / Migrated Row ( Single Block I/O 시 )
# Multi Block I/O 도중에도 발생 가능
db file sequential read 대기 과다 원인
# 비효율적인 Index Scan
# SQL Tuning
# index 변경
# 지나치게 높은 Clustering Factor
# Table Reorg 를 통해 해결
# 지나치게 깊은 Index 깊이
# Index Rebuild 를 통해 해결
# I/O System 성능 저하
# Disk I/O 성능 개선
# Hot Spot 해소 : Logical Volumn Level Striping, ASM 등
Clustering Factor ( CF )
# 군집도, Table 이 얼마나 Index 와 잘 뭉쳐 있는가를 판단하는 값
# Index Scan 에 따른 Table Block I/O 회수
# DBA_INDEXES.CLUSTERING_FACTOR
!Re_IO_27.jpg!
[ 산정방법 ]
1. 인덱스를 정렬하여 스캔한다.
2. 현재 인덱스 값의 rowid 에서 가리키는 블록값을 바로 전 인덱스 값의 rowid 에서 가리키는 블록값과 비교한다.
3. 위의 rowid 의 블록이 서로 다른 블록이라면 count 를 1 증가시킨다.
4. 전체 인덱스를 모두 스캔한다.
5. 결과 count 의 값이 Clustering Factor 가 된다.
# Table Block 수 <= CF <= Table Row 수
# 값이 작을 수록
# 군집도가 뛰어남
# Disk I/O 가 줄어듦
# Cache Buffer 가 효율적으로 사용됨
# 넓은 범위의 Index Scan 시에 대한히 중요
# 좁은 범위의 Index Scan 에서는 큰 영향 없음
# 높은 CF 문제의 해결 방법
# Table Reorg : Table 을 Index 와 같은 순서로 변경
# IOT 사용 고려
# IOT : Index Organized Table
# B*Tree 형태로 관리되는 Table
# 항상 Index key 키와 동일한 물리적인 순서 보장
# SQL Server 나 DB2의 Clustered Index 와 비슷한 개념
# 일반적으로 잘 사용되지 않음
# Hot Spot 과 Logical Volumn Striping
!Re_IO_28.jpg!