꾸러기

1.1. 테이블과 인덱스 분리형
- 빠른 저장 : 데이터의 값과 저장 위치와 무관함 - 무조건적으로 저장
- 인덱스를 통한 빠른 검색(rowid) : 값과 위치에 대한 정보 별도 저장

1.1.1. 분리형 테이블의 구조
- Free list : 블록의 사용 가능 여부를 저장한 목록
- PCTFREE : 블록 내에서 행 크기의 증가를 대비해 지정한 여유 공간

- MANUAL Segment Space Management (Free list)
 PCTFREE
 - 블록에 저장된 행에 변경이 발생할 경우 행의 크기가 증가하는 것에 대비해 지정하는 여유 공간
  기본값은 데이터 블록 크기의 10%
 PCTUSED
 - 데이터 블록 재사용 여부를 결정하기 위해 지정하는 데이터 블록 사용률
  데이터가 사용하는 공간이 해당 설정 값 이하일 경우 재사용
  기본값은 데이터 블록 크기의 40%

- AUTO Segment Space Management (Bitmap)
 ASSM

- Tablespace > Datafile > Segment / Partition > Extent > Block
 Segment에는 개별적인 Object(Table, Index)를 저장할 수 있음
 Partition이 발생한 Table, Index는 각각의 Partition이 개별 Object가 됨
 개별 Partiion 및 단일 테이블은 하나의 tablespace에 저장

- ROWID
 Datafile의 식별자를 Tablespace 내에서 상대적인 번호로 붙여도 하나의 Object 내에서 유일하게 식별 가능
 오브젝트번호+데이터파일번호(테이블스페이스 당 일련번호)+블록번호+슬롯번호 (논리적/상대적 주소)
 상대적인 주소로 인해 ROWID 길이가 짧아짐

- Fragmentation vs. Condensing

- Row Chaining vs. Row migration

1.1.2. 클러스터링 팩터
- 물리적 저장 방식에 따른 access 효율 차이
 메모리 vs. 디스크

- 분리형 테이블
 임의의 위치에 흩터져서 저장

- 클러스터링 팩터 계산 로직
 1. counter 변수 선언
 2. 인덱스 리프 블록을 full scan하여 rowid로부터 블록 번호 추출
 3. 순차적으로 읽어나가면서 인덱스 레코드의 블록 번호가 바뀔 때마다 conter 1 증가
 4. 최종 counter 값을 인덱스 통계에 저장

- 저장 순서와 생성 순서 불일치
 악화시 table reorganization 필요함

1.1.3. 분리형 테이블의 액세스 영향요소
가) 넓은 범위의 액세스 처리에 대한 대처방안

- 임의의 위치에 저장하는 방식
 대량 처리시 성능 문제 발생
 데이터 입력시 부담 저하 / 추가 조치 없이 자유롭게 저장

- Differed write
 메모리에 저장된 데이터를 일괄적으로 디스크에 기록

- 소형 테이블
 블록의 분산 비율 적음
 데이터 양이 적어 메모리 엑세스 확률 높음
 중요한 액세스 형태라면 IOT, Cluster table 구성 필요

- 중형 테이블
 다양한 액세스 형태를 모두 만족할 수 없음
 특정한 액세스만을 충족할 경우 그에 맞게 재구성 진행 (나머지 손해)
 액세스 형태 선정 -> 다른 컬럼들의 처리 범위 문제 해결
 분리형 구조는 필연적

- 대형 테이블
 로그 테이블의 경우 엑세스 형태가 제한적임
  - 분리형 구조가 적절, 필요에 따라 파티션 고려
 계정계 테이블의 경우 단순한 랜덤 엑세스와 단순한 데이터 증가
  - 분리형 적절,   특정 액세스 패턴이 없어서 파티션이나 클러스터링 혜택 없음
 정보계 테이블의 경우 다양한 액세스 형태와 지속적인 대량의 데이터 증가
  - 파티션 적용 고려, 다양한 액세스 패턴을 고려하여 인덱스 전략을 통해 SQL 최적화 필요

나) 클러스터링 팩터 향상 전략
- 액세스를 고려한 주기적인 테이블 재구성
 자주 범위처리하는 컬럼들로 정렬 저장
 병렬처리로 정렬하는 것도 대안이 됨

- 인덱스 재생성을 통해 branch depth 정리
 원하는 정렬의 인덱스를 사용하도록 유도
 테이블 재생성시 인덱스 비활성화, 작업 완료 후 활성화하여 인덱스 구조 개선