1) Oracle DB I/O 방식 : Conventional Path I/O 과 Direct Path I/O ( DB Buffer Cache 경유 여부 )
2) File System I/O 방식 : File System's Buffer 와 Direct I/O ( File System Buffer 경유 여부 )
3) Sync 방식 : Async / Aync 방식
#2,3 에 대한 파라미터
disk_async_io - Raw , Filesystem 의 Async 방식 제어
filesystemio_options - 일반 Filesystem 에서의 DB file 의 I/O 제어
asynch - Buffer I/O + Async I/O
directIo - Direct I/O Only
setall - Direct I/O + Async I/O
none - disable ( Async I/O + Direct /O )

Physical I/O 분류
1. Conventional Path I/O
: Oracle 의 Cache Buffer 를 경유한 I/O 작업
Server Process 에 의한 BLOCK 읽기 작업
DBWR 에 의한 Block 쓰기 작업
관련 통계값

1. physical reads/writes : 모든 Physical I/O Block 수
2. physical reads cache(10g) ; Cache Buffer 를 경유한 Physical I/O Block 수
3. physical reads/writes direct : Cache Buffer 를 경유하지 않은 Physical I/O Block 수
4. physical reads/writes direct(lob) : LOB에 대한 Physical I/O Block 수
   Physical reads cache = physical reads - physical reads direct - physical reads direct(lob)
5. 전통적인 insert operation 은 table 내의 free space 를 재사용합니다.
   기존의 데이터와 새로 insert 된 데이터가 같이 저장되며, 참조 constraint 도 자동으로 관리 됩니다.

2. Direct Path I/O
: Oracle 의 Cache Buffer 를 경유하지 않는 I/O 작업
데이타 블록을 PGA로 올리는 것으로, I/O 작업이 발생되기 전에 체크포인트가 발생되어 더티버퍼를 데이타파일에
쓰게 되어 데이터화일과 버퍼캐쉬의 내용에 대해서 동기화를 한 후 Direct Path I/O가 발생하게 된다.

1. Direct-path insert operation 은 새로 입력되는 데이터를 기존의 table 내에 존재하는 데이터 이후에
   저장합니다. buffer cache 를 거치지 않고 바로 datafile 에 저장되며, table 내의 free space를
   사용하지 않습니다. 또한 참고 constraint 도 무시 됩니다. 이러한 일련의 procedure로 인해
   performance 가 향상 됩니다.
2. Locking considertation with Direct-Path Insert
   Direct-path Insert 시 해당 table 에 대한 Exclusive Lock이 요구 된다.
   따라서 다른 User 들은 해당 table 에 대해 Insert, Update, Delete, Index Create build operation 이
   제한 된다. 데이터에 대한 Query 는 지원되며, Direct-insert 이전의 데이터만 보여진다.

Direct Path I/O 발생하는 예
2.1 정렬작업을 위해 정렬 세그먼트(Sort segment)를 읽고 쓰는 경우
( 관련 대기 이벤트 - direct path read temp , direct path write temp )
2.2 Parallel Query 를 위해 데이터 파일을 읽는 경우
( 관련 대기 이벤트 - direct path read )
2.3 PDML(Parallel DML), CTAS를 위해 데이터 파일을 쓰는 경우
( 관련 대기 이벤트 - direct path write )
2.4 nocache 속성으로 생성된 LOB 세그먼트를 읽고 쓰는 경우
( 관련 대기 이벤트 - direct path read(lob), direct path write(lob) )
2.5 I/O 시스템이 데이터를 읽어서 오라클에 반환하는 속도보다 훨씬 빠른 속도로 버퍼를 요구할 때
( 관련 대기 이벤트 - direct path read )
2.6 Insert /*+ Append */ 나 sqlldr direct=true

SQL> select * from v$version ;
BANNER

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE 10.2.0.4.0 Production
TNS for HPUX: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production

SQL> desc v$statname
Name Null? Type

---

---

---

---

---

---

---

---

---

---

-

---

---

---

---

---

---

---

---

---

STATISTIC# NUMBER
NAME VARCHAR2(64)
CLASS NUMBER
STAT_ID NUMBER

SQL> select count(*) from v$statname ;

COUNT(*)

---

---

--
381

SQL> desc v$sysstat
Name Null? Type

---

---

---

---

---

---

---

---

---

---

-

---

---

---

---

---

---

---

---

---

STATISTIC# NUMBER
NAME VARCHAR2(64)
CLASS NUMBER
VALUE NUMBER
STAT_ID NUMBER

SQL> desc v$sesstat
Name Null? Type

---

---

---

---

---

---

---

---

---

---

-

---

---

---

---

---

---

---

---

---

SID NUMBER
STATISTIC# NUMBER
VALUE NUMBER

SQL> select * from v$sysstat
where name in ('physical reads','physical writes','physical reads cache','physical reads direct',
'physical writes direct','physical reads direct (lob)','physical writes direct (lob)') ;

Conventional Path I/O 분류
Multi Block I/O

1. 한 번에 여러 개의 연속된 Block을 읽어 들이는 I/O 작업
2. FTS(Full Table Scan), IFFS(Index Fast Full Scan) 등에서 발생
   Single Block I/O
3. 한번에 하나의 Block 만을 읽어 들이는 I/O 작업
4. Index Range Scan, Index Full Scan 등에서 발생
   Conventional Path Read = Multi Block I/O(DB_FILE_MULTIBLOCK_READ_COUNT) + Single Block I/O

Multi Block I/O

1. 한번에 최대 MBRC(DB_FILE_MULTIBLOCK_READ_COUNT) 만큼 Block 읽음
2. Full Table Scan, Index Fast Full Scan 에서 사용
3. Full Scan = Segment 의 처음부터 끝(HMW)까지 Multi Block I/O 로 읽어 들이는 작업

1. 블록헤더(Block Header)싱글블록 I/O 발생
2. #1 ~ #8 블록에 대한 DB_FILE_MULTIBLOCK_READ_COUNT 값만큼 멀티블록 I/O 발생
3. #9,#10,#11,#12 블록들에 대한 멀티블록 I/O 발생

#Multi Block I/O 에서 한꺼번에 읽는 Block 수는 ?
최대값은 MBRC, 최소값은 2

Index Full Scan VS Index Fast Full Scan

1. Index Full Scan = Single Block I/O
2. Index Full Scan 은 정렬 보장 - Leaf Node 를 순차적으로 읽어 나가기 때문
3. Index Fast Full Scan = Multi Block I/O
4. Index Fast Full Scan 은 정렬 보장 안됨 - Segment 시작부터 끝(HWM)까지 물리적으로 읽기 때문
5. 순서 보장이 불필요하다면, IFFS 를 사용하는 것이 성능 면에서 유리
   

1. Index fast full scan 을 제어하는 파라미터 - "_FAST_FULL_SCAN_ENABLED=TRUE"
2. Index fast full scan 유도하는 힌트는 /*+ index_ffs(table_alias index_name) */ 이다.

1. 참고 . Multiple Buffer Pool

1. 8i 에 처음 소개된 기능
2. KEEP, RECYCLE, DEFAULT 3가지 Type 의 Buffer Pool 이 존재함
3. 모두 동일한 LRU 알고리즘에 의해 관리됨
4. KEEP Buffer을 사용하여 대상이(Table / Index / Partition ) 가능한 오랫동안 Cache 에 유지함
5. RECYCLE buffer 는 대상이 Cache 상에서 가능한 빨리 Againg Out 하게 함
6. KEEP 대상 집합이 KEEP Buffer Size보다 클 경우 Keep Buffer 의 Object 도 Disk 로 Flush 된다.
7. 특별히 지정하지 않은 대상은 모두, DEFAULT buffer pool 에서 관리 된다. ( DBA_TABLES.BUFFER_POOL )
8. CREATE/ALTER TABLE, CREATE/ALTER CLUSTER, CREATE/ALTER INDEX 문장의 Storage 절을 통해서
   Buffer Pool 지정이 가능하다.
9. Multiple Buffer Pool 기능을 통해서, 불필요한 I/O 의 최소화가 가능하다.
10. CREATE/ALTER TABLE Cache Option 은 대상이 Full Scan 수행 시에,
    LRU(Least Recently Used) End 에 위치 하게 하지 않고(빠르게 Aging Out 함 )
11. MRU(Most Recently Used) End 에 위치 하게 함 ( 가능한 오랫동안 Cache 유지도록 함 )

1. KEEP Buffer 대상은, Table 보다는 특정 Partition, PK Index, PK 구성 칼럼 + 주요 칼럼으로 구성된 Index 로 선정하여,
   KEEP Buffer Size 를 Over 하지 않도록 설정 한다.

1. Multiple Buffer Pool 사용 예제
   가) db_keep_cache_size 지정 하기( 즉시 반영됨 )
   SQL> alter system set db_keep_cache_size=100M scope=both ;
   나) db_keep_cache_size 확인 하기
   SQL> select NAME, CURRENT_SIZE, SET_COUNT from v$buffer_pool ;
   다) 특정 테이블 KEEP POOL 에 지정 하기
   SQL> ALTER TABLE SH.CUSTOMERS STORAGE ( buffer_pool keep ) ;
   라) 특정 인덱스 Keep Pool 에 지정 하기
   SQL> ALTER index SH.CUSTOMERS_PK storage ( buffer_pool keep )
   마) 특정 테이블 Keep Pool 해제 하기
   SQL> ALTER TABLE SH.CUSTOMERS STORAGE ( buffer_pool DEFAULT ) ;
   바 ) 특정 인덱스 KEEP POOL 해제 하기
   SQL> ALTER index sh.CUSTOMERS_PK storage ( buffer_pool DEFAULT ) ;
   사 ) db_keep_cache_size 해제 하기 ( DB Restart 필요 )
   SQL> alter system reset db_keep_cache_size scope=spfile sid='*' ;
   ※ 주의 사항 : db_keep_cache_size는 db_cache_size 로 부터 할당 된다.

Single Block I/O

1. 한번에 하나의 Block 만을 읽어 들임
2. Index Scan(IFFS 제외), ROWID 에 의한 Table Scan
   

1. Root block read : 1 logical read
2. Branch block read : 1 logical read
3. Leaf block read : 1 logical read
4. Data block read : 1 logical read

1. 인덱스 스캔 시 고려 사항
   1. 인덱스 BLEVEL
   2. Index Clustering Factor
   Index Clustering Factor 산정방법
   2.1 인덱스를 정렬하여 스캔한다.
   2.2 현재 인덱스 값의 ROWID에서 가리키는 블록값을 바로 전 인덱스값의 ROWID 에서 가리키는 블로값과 비교한다.
   2.3 위의 ROWID 의 블록이 서로 다른 블록이라면 COUNT 1을 증가시킨다.
   2.4 전체 인덱스를 모두 스캔한다.
   2.5 결과 COUNT 의 값이 CLUSTERING FACTOR 가 된다.
   Blocks(Table) <= Clustering Factor <= Num_rows(Table)
   (distinct_key/num_rows) * 100 < 10 이면,
   Clustering Factor 가 좋더라도 인덱스의 효율이 떨어지기 때문에 해당 인덱스를 사용하는 것은 효과적이지 못하다.
   ==> Index Selectivity(인덱스 선택도)가 좋지 않으면 Clustering Factor 가 의미 없다.

1. 기타 Single Block I/O 발생 이유
   Chainged/Migrated Row Scan
   Multi Block I/O 수행 도중 하나의 Block 만을 읽을 경우에도 발생
2. Multi Block I/O 도중 Single Block I/O 발생

Extent 경계에 닿은 경우

1. Chained / Migrated Row Scan
   

1. Root Block read : 1 번 logical read
2. Branch block read : 1 번 logical read
3. Leaf Block read : 1 번 logical read
4. Data Block read : 1 번 logical read
5. Chained row read : 1 번 logical read

1. Chained Row vs Migrated Row
   Chained Row : Row 의 크기가 Block 보다 큰 경우에 발생
   Migrated Row : Block 이 꽉 찬 상태에서 Update 로 인해 Row 를 이동시키는 경우에 발생

Chained Row

1. Row 의 크기가 Block 을 초과해서 여러 개의 Block 에 걸쳐 있는 현상
2. Multi Block I/O 수행 시 부가적인 Single Block I/O 발생 가능
3. Index 를 경유한 Table Scan 시 부가적인 Single Block I/O 발생
4. 해결책
   1. 1:1 Table 분할
   2. Lob Type 활용
   3. Table Move ( Block Size 가 큰 Tablespace 로의 )

Migrated Row

1. 여유 공간이 없는 Block 에서 Update 로 인해 Row 크기가 늘어나서 해당 Row 를 다른 Block 으로 이동(Migrate) 시킨 현항
2. Multi Block I/O 수행 시에는 부가적인 Single Block I/O 발생 하지 않음
3. Index 를 경유한 Table Scan 시 부가적인 Single Block I/O 발생
4. 해결책
   해당 Data 재생성( 삭제 후 재 삽입 )

Direct Path I/O

1. Server Process 에 의한 직접 읽기/쓰기 작업
2. 발생 상황
3. 정렬 작업을 위한 Sort Segment 읽고 쓰기
4. Parallel Query 를 위한 Data File 읽기
5. PDML 이나 CTAS 를 위한 Data File 쓰기
6. Insert /*+ APPEND */ 나 sqlldr direct=true
7. NOCACHE 속성의 LOB 읽고 쓰기

참고 ) CACHE / NOCACHE / CACHE READS: LOB Values and Buffer Cache
CACHE: Oracle places LOB pages in the buffer cache for faster access.
NOCACHE: As a parameter in the STORE AS clause,
NOCACHE specifies that LOB values are not brought into the buffer cache.
CACHE READS: LOB values are brought into the buffer cache only during read and not during write operations.

Parallel Execution 과 Direct Path I/O

Sort 와 Direct Path I/O

1. Sort segment 에서의 Direct Path I/O 는 SORT 해야 할 데이터가 SORT 를 위해 할당된 PGA 메모리 영역보다 큰 경우에
   발생된다.
   

1. PGA = 튜닝 가능(Tunable : 실제 SQl 실행 시 사용 메모리 ) + 튜닝 불가능 ( untunable : 세션 메모리, 커서 실행 메모리 ) 메모리

Dynamic Performance Views

V$SESSTAT 와 V$SYSSTAT 뷰에 다름 네 가지 STATISTICS 가 추가되었다.

1. workarea memory allocated
: 특정 세션이나 시스템에 할당된 전체 PGA 메모리 크기
2. workarea execution - optimal
: SQL 실행 메모리가 최적의 크기를 가졌던 누적 횟수, 여기서 메모리가 최적의 크기를 갖는다는 것은
예를 들어, DISK 에 Write 하지 않고 Sort 작업을 수행하는 경우를 의미 한다.
3. workarea execution - onepass
: SQL 실행 메모리가 1 Pass 크기를 가졌던 누적 횟수
여기서 메모리가 1 Pass 의 크기를 갖는다는 의미는,
예를 들어 Sort 의 경우 disk 에 임시 결과를 한번 저장하고 결과를 merge 해서 sort 작업을 마치는 경우를 의미 한다.
4. workarea execution - multipass
: SQL 실행 메모리가 2 Pass 이상의 크기를 가졌던 누적 횟수

I/O

1. I/O 작업은 다단계의 작업
2. 각 단계별로 여러 가지의 Option 가능
3. Oracle Process : Conventional VS Direct. Multi Block vs Single Block
4. OS file Cache 사용 ?
5. RAW Device 사용 ?
6. Asyncronous I/O 사용 ?
7. Quick I/O( Direct I/O ) 사용?
8. JFS 사용? GPFS 사용? Cluster File System 사용 ?
9. Volumne Manager 사용 ?
10. Storage Cache 사용 ?
11. RAID 사용 ? RAID 레벨은 /
12. ASM 사용 ?
13. Stripe 크기는 ?
14. I/O 분산은 ? Disk Level VS Volumn Level

Big Picture

Application I/O

1. Cache Buffer 를 효율적으로 사용
2. SQL 최적화
3. INDEX 최적화
4. Multi Buffer Pool

1. 대량의 Data 처리 작업시 Direct Path I/O 사용
2. Insert /*+ Append */ Select...
3. sqlldr direct=true
4. Parallel Query

File System Level

1. 일반 File System : OS File Cache 를 통해 I/O 작업 수행
2. Direct I/O + File System : OS File Cache 를 사용하지 않음
3. Raw Device : File System 를 사용하지 않음
   

1. File Cache 의 크기도 Tuning 대상이 됨
2. 비동기(Async) I/O : 대부분의 OS 에서 보편적으로 사용
3. Direct I/O
4. OS 의 File Cache 를 거치지 않는 I/O
5. 일반적으로 권장, 하지만 Test 를 통한 검증 필요
6. 예) Direct I/O , Quick I/O, Concurrent I/O
7. Raw Device
8. 쓰기가 왕성한 Data 에 대해서 권장됨 Ex) Redo Log
9. RAC 에서 보편적으로 사용

Volume Level

1. Virtual Partitioning, Stripping, Mirroring 등의 역할
2. LVM ( Logical Volumn Manager)이 보편적으로 사용됨
3. ASM(Automatic Storage Management) 은 File System + Volumn Manager 의 기능을 대신
   

1. Striping
2. Striping 크기
3. 32K, 63K, 128K, 1M, Vendor 마다 조금씩 다른 기본값 추천
4. ASM 을 사용할 경우에는 1M가 기본값으로 사용
5. 모든 DISK 에 골고루 Striping 적용을 권고
6. 특정 DISK 가 Hot Spot 이 되는 것을 방지
7. Sequential Access 에서는 병렬 읽기/쓰기로 성능 향상 가능
8. Random Access 에서는 Hot Spot 방지로 성능 향상 가능
   

RAID 0 ( Striping )

1. 빠른 입출력이 가능하도록 여러 Disk 에 동시에 분산 저장
2. 한 개의 Disk 의 장애시에도 전체 데이터의 손실 발생 가능
   

RAID 1 ( Mirroing & Duplexing )

1. 동일한 데이터를 동시에 다른 DISK 에도 저장
2. DISK 장애시 복구 가능
3. DISK의 사용률이 낮아짐
   

RAID 5

1. 페리티가 여러 DISK 에 분산되어 저장
2. DISK 장애시 복구 가능
3. 쓰기 속도가 느림
   

RAID 1+0 vs RAID 5

1. RAID 1+0 = Striping + Mirroring ( 디스크의 1/2 만 사용 가능 )
2. RAID 5 = Parity Block ( Write Penalty 로 인항 성능 저하 가능 )

ASM
ASM 은 RDBMS 의 File Storage 관리 도구
ASM 이 RDBMS 는 위한 I/O 를 수행 하지 않는다.
ASM 에게 Disk 는 Raw Device 이다. ( RAW I/O )
Data files, control files, redologs, archivelogs, flashback logs, spfiles,
RMAN Backups, Datapump Dumpsets 저장 가능
높은 Storage 자원 사용율 제공
SQL과 유사한 명령어를 통해서 손쉬운 관리 가능
ASMCMD, RMAN(Backup), XML ASM Virtual Folder를 통해서만 관리 가능
DG(Disk Group) 내에 고른 I/O 분포 제공(Hot Spot 방지)
편리한 Disk 추가/삭제 ( Online 중)

ASM Rebalancing

==>