꾸러기

1.3. 클러스터링 테이블
- 분리형 : Random Access 발생

- 일체형 : 다양한 Access 지원에 대한 부담

- 처리할 절대 범위가 넓을 경우 인덱스만으로 해결 불가


1.3.1. 클러스터링 테이블의 개념
- 저장 공간을 지닌 Object로 Table의 상위 개념

- Multi Table Clustering (공단의 비유)

- Single Table Clustering (창고의 비유)

- 정해진 컬럼값을 기준으로 동일한 값을 가진 하나 이상의 테이블의 로우를 같은 장소에 저장하는 물리적 기법

- Clustering Factor : 액세스하려는 데이터들의 모여있는 정도로 물리적 액세스 양을 결정


1.3.2. 단일테이블 클러스터링
- 단위 클러스터에 하나의 테이블만 생성

- 클러스터 인덱스는 클러스터키 컬럼값에 단 하나만 존재하며 클러스터 스캔에 사용

- 클러스터키 값 : 동일한 클러스터키 값은 단 한번만 저장됨
 로우에는 클러스터 키 ID만 저장
 블록 헤더에 클러스터기 ID와 클러스터키 값 저장 (다중테이블 클러스터링과 동일)

- 클러스터키 변경시 row migration과 동일하게 row 위치만 이동하고 이주한 rowid를 기존 위치에 남김
 row 길이 증가나 새로운 row의 입력으로 여러 블록에 걸쳐 데이터를 저장하는 row chaining 발생

- 클러스터 인덱스를 한번 액세스하여 여러 건의 테이블 row를 한번에 스캔하므로 random access 감소

- 분포도
 분포도가 좁은 컬럼을 클러스터링하면 단위 클러스터의 row 수가 적어 일반 인덱스 스캔과 차이 없음
 분포도가 넓어야 한번의 클러스터 인덱스 스캔으로 액세스하는 row의 수가 많아지게 되어 더 효율적임

- 지정된 위치를 찾아 저장해야하므로 추가적인 부하 발생


1.3.3. 다중테이블 클러스터링
- 단위 클러스터에 두개 이상의 테이블을 함께 저장 (조인 속도 향상)

- 단위 클러스터에는 동일한 클러스터키 값을 저장할 필요 없음
 각 row에 클러스터키 ID만 저장 / 블록 헤더에 클러스터키 정보 저장

- 지역적 투명성
 같은 클러스터 내에서도 테이블 간의 독립성 보장
 각각의 테이블을 별도 액세스 가능 / 테이블의 고유 인덱스 생성 가능

- 효율적인 테이블 간의 조인
 제1 정규화에 의해 분할된 테이블을 하나의 테이블처럼 연결시켜줌
 random access 감소 : join 값을 클러스터키로 지정하여 여러 개의 테이블을 같은 블록에 저장

- 클러스터링 도입으로 테이블의 유연성은 훼손됨
 효율적으로 조인할 수 있는 방법을 찾아볼 것!


1.3.4. 클러스터링 테이블의 비용
- 클러스터링의 역할
 액세스 형태를 모두 수집, 분석하여 적은 비용이 드는 인덱스로 해결하도록 노력

- 입력시의 부하
 클러스터키 값에 따라 저장 위치가 달라짐
 키 값이 다를 경우 여러개의 블록에 따로 저장될 수 있음
 일반 테이블의 경우, 값이 다르더라도 같은 블록에 한꺼번에 저장되는 것과 비교됨
 일반 테이블이라도 여러개의 인덱스가 존재할 경우 위치 선정에 따른 부하가 발생
 클러스터링 도입으로 인덱스의 개수가 줄어든다면 부하 증가의 염려를 줄일 수 있음

- 수정시의 부하
 클러스터키 컬럼값의 수정시 row migration 발생하여 clustering factor 저하
 클러스터키 컬럼이 아닌 데이터의 수정은 일반 테이블의 수정과 동일하여 추가적인 부하가 없음
 수정이 빈번한 컬럼을 클러스터키 컬럼으로 지정하지 않도록 할 것

- 삭제시의 부하
 클러스터링 테이블의 모든 row를 삭제하더라도 인덱스는 그대로 존재함
 테이블 drop의 경우 row를 제거하는 것이지 단위 클러스터를 제거하는 것이 아님
 따라서, delete를 수행하게 되어 많은 부하가 발생하게 됨
 새로운 클러스터에 데이터를 생성하고 rename하는 방법이 바람직함

- DROP CLUSTER cluster_name
  INCLUDING TABLES
  CASCADE CONSTRAINTS;
 제약조건, 테이블, 사전 정보 모두 삭제

- TRUNCATE CLUSTER cluster_name REUSE STORAGE;
 현재 저장공간과 사전 정보를 유지하고자 할 때 유용함


1.3.5. 해쉬 클러스터링
- 해쉬 클러스터링의 특징
 SIZE, HASHKEY, HASH IS 파라미터는 변경 불가
 = 조건의 액세스만 가능
 클러스터 생성시 저장공간이 미리 할당됨
 단위 클러스터보다 많은 row가 입력시 overflow 영역에 저장
 컬럼값이 고르게 분포되지 않을 경우 해쉬키 값의 충돌 발생
 해쉬 함수로 계산된 값으로 직접 테이블 액세스 (인덱스보다 효율적)

- 활용 범위
 데이터의 증가가 없는 테이블에 적용 (해쉬키의 개수는 변경 불가)
 = 조건을 사용하는 경우에만 적용
 클러스터키 컬럼의 값이 균등한 경우에만 사용 (overflow, 키 값 충돌 방지)
 코드 관리 테이블, 우편번호, 사용자 정보 관리 테이블에 활용 가능
 해쉬 파티션 : 해쉬 클러스터링의 발전된 개념으로 대량의 데이터 저장시에 적합함

- HASHKEYS : 해쉬키 값의 개수로 지정한 값보다 큰 소수가 적용됨
 초기 저장공간을 할당하는데 적용됨

- HASH IS : 해쉬함수를 지정함
 클러스터키 값이 다르면 해쉬값도 최대한 달라지도록 할 것! (overflow 방지)
 해쉬 함수를 적용한 결과는 양수여야 함
 적용할 때마다 결과값이 변하는 것(SYSDATE,ROWNUM 등)을 제외한 SQL 수식 사용
 사용자 정의 함수를 해쉬 함수의 일부로 사용할 수 없음

- SIZE : 단위 클러스터의 크기 지정
 DB_BLOCK_SIZE 보다 클 경우 O/S의 블록 크기를 사용
 미지정시 하나의 데이터 블록을 단위 클러스터에 할당
 USER_CLUSTERS에 있는 KEY_SIZE 컬럼을 참조할 것

- Overflow 방지를 위해 SIZE 값은 약간 여유있게 지정할 것

- 단일테이블 해쉬 클러스터
 단 하나의 테이블만 클러스터에 저장 => 효율적인 액세스 가능

1.2. 인덱스 일체형 테이블
- 기본키 위주의 질의, 기본키 길이가 로우에서 높은 비율 차지
- 분리형 구조의 랜덤 액세스 제거

1.2.1. 분리형과 일체형의 비교
- 표 참조

1.2.2. 일체형 테이블의 구조 및 특징
- 인덱스 -> 테이블의 논리적 액세스 감소
 대량의 random access 제거로 넓은 범위 처리에 탁월한 효과

- equal 조건 검색시 해쉬 클러스터링이 보다 유리함
 IOT의 경우 데이터가 넓은 블록에 분포함 > 인덱스만 스캔하는 경우보다 불리함

- ROWID가 아닌 기본키로 액세스됨

- Overflow 영역 지정
 row 길이의 변화를 대비해 기본키 이외의 영역을 별도의 공간에 저장

1.2.2. 논리적 ROWID와 물리적 주소
- Pruning에 따른 leaf node의 분할, 변경으로 rowid가 달라짐
 추가적인 인덱스 생성시 rowid로 식별이 어려운 현상 발생

- 논리적 rowid 개념 도입
 인덱스 로우가 생성될 때 만들어짐
 키 분할에 의한 데이터 블록의 위치 변경은 반영하지 않음
 로우가 존재할 가능성이 높은 주소를 담고 있어 Physical Guess라고 표현

- 일체형 구조 권장 테이블
 전자 카탈로그나 키워드 검색용 테이블
 코드성 테이블
 색인 테이블
 공간(Spatial) 정보 관리용 테이블
 대부분 기본키로 검색되는 테이블
 OLAP의 디멘션 테이블
 로우의 길이가 짧고, 트랜젝션이 적은 테이블

- 액세스 수행절차
 1. 추가적인 인덱스를 액세스하여 물리적 위치정보를 참조한다.
 2. 참조한 물리적 위치정보를 이용하여 데이터 블록을 액세스한 후에 비교한다.
   이때 기본키 값이 같으연 물리적 위치정보가 유효한 것으로 간주하여 액세스를 종료한다.
 3. 만약 유효하지 않다면 다시 기본키로 액세스하여 데이터 블록을 가져온다.

- 추가 인덱스의 물리적 위치 정보를 유지하기 위한 방법
 인덱스 재생성
 재생성이 부담될 경우 통계정보를 생성하여 옵티마이저가 물리적 위치정보의 사용 여부를 선택하도록 유도

1.2.4. 오버플로우 영역
- 공간 분할 최소화 및 저장 밀도 향상
 액세스 빈도가 낮은 컬럼을 오버플로우 영역에 저장

- INCLUDING 이후의 컬럼을 대상
 컬럼 순서를 고려하여 테이블을 생성해야 함
 본체는 인덱스 세그먼트, 오버플로우 영역은 테이블 세그먼트에 저장
 별도의 테이블스페이스 지정 가능

1.2.5. 일체형 테이블의 생성
- ORGANIZATION INDEX : 일체형 테이블 생성을 정의

- TABLESPACE : 인덱스 영역 지정 / STORAGE 파라미터 사용 가능

- PCTTHRESHOLD : 인덱스 블록 내의 예약된 공간을 백분율로 지정
 범위를 초과할 경우 INCLUDING 이후의 컬럼은 오버플로우 영역에 저장
 OVERFLOW를 지정하지 않을 경우 임계값을 초과한 row들은 거부됨
 0~50 사이의 값으로 지정

- INCLUDING : 지정된 컬럼 이후의 컬럼은 오버플로우 영역에 저장
 NULL일 경우 모든 데이터는 인덱스 영역에 적재
 임계값에 도달하기 전까지는 row 분리 발생하지 않음
 row가 최초로 입력될 때 INCLUDING이 적용되며 이후는 PCTTHRESHOLD에 의해 분할

- OVERFLOW TABLESPACE : 임계값을 초과한 row가 저장될 테이블 스페이스
 지정하지 않은 상태에서 임계값을 초과할 경우 입력 거부

- 사용자가 INCLUDING을 사용하여 row chain을 결정할 수 있음
 leaf node의 저장밀도를 높이기 위한 전략
 액세스 패턴을 분석하여 분할 영역을 검토해야 함

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 정리
 원하는 정렬의 인덱스를 사용하도록 유도
 테이블 재생성시 인덱스 비활성화, 작업 완료 후 활성화하여 인덱스 구조 개선