1.1. 테이블과 인덱스의 분리형

1.1.1. 분리형 테이블의 구조

• 테이블과 인덱스가 별도로 분리되어 있는 구조로 관계형 데이터베이스의 가장 일반적인 데이터 저장형식
  분리형 테이블의 구조

• 자료가 입력되면 DBMS는 FREE LIST에서 DB의 여러 블록중 저장가능한 블록을 확인후 저장
  저장시 블록내  이어진 공간이 없다면 전체 블록의 로우 위치를 재배치(Condensing)후 저장(반드시 한조각이되어야함)
  'FREE SPACE'는 이미 들어가 있는 로우들의 길이에 변화가 생겼을대 사용하는 여유 공간(UPDATE등) - pctfree로 지정 

• 테이블스페이스(Tablespace)
  데이터가 저장되는 논리적인 저장공간
  물리적인 데이터 파일(Datafile)로 구성
• 세그먼트(Segment)
  테이블스페이스를 용도별로 나눔(데이터 오브젝트(Object))
  파티션(Partition)이 발생한 테이블이나 인덱스는 각각의 파티션이 단위오브젝트가 됨
  파티션된 테이블의 각 파티션이 서로 다른 테이블스페이스에 존재하는 경우는 여러 테이블스페이스에 걸쳐 저장
  개별 파티션이나 파티션되지 않는 테이블들은 반드시 하나의 테이블스페이스에 존재
• ROWID
  '오브젝트번호+데이터파일번호(테이블스페이스당 일련번호)+블록번호+슬롯번호'로 구성
  인덱스에 존재( 테이블에 존재하지 않음)
  * ROWID의 오브젝트 번호와 데이터파일 번호를 통해물리적인 저장위치를 찾아서 거기에 있는 블록번호를 찾아가면 슬롯
  * 블록내에서 로우의 위치가 이동하더라고 rowid는 결코 변하는 않음(슬롯은 로우(자료)의 위치를 가지고있음)
  로우가 한조각으로 저장될수있는 위치로 이동했을때 해당 슬롯에 있는 위치 값은 새로운 위치값으로 변경
• Oracle Physical Rowid
  000000  + FFF +  BBBBBB +  RRR
  (Data obect(6) + Relative file(3) + Block(6) + Row(3)): 16자리 (저장시 10자리)
  Data Object number: DATABASE SEGMENT 식별정보
  Relative File number: Tablespace에 성대적 Datafile 번호
  Bolck Number : Row 를 포함하는 Data Bolck 번호
  Row number: Block 에서 row 의 Slot
• SQL Server 의 Rid
  8바이트 = Page Address(4)+File ID(2) + slot number(2)
• 응축(Condensing)작업
  이동이 계속적으로 발생하면 결국에는 사용할 수 없는 수많은 작은 조각(Fragmentation)들이 발생
  이어진 조각이 없어 저장이 불가능하게 될때 자동으로 블록의 로우들을 재구성작업
  만약 여유공간(FREESPACE(PCTFREE값)) 이 너무 적게 지정되었다면 지나치게 빈번한 응축자업이 발생하여 부하의 원인이 될수있음
  수정이 빈번하게 발생할 가능성이 높다면 다수 충분하게 여유공간(PCTFREE) 를 지정해주는 것이 유리
• 로우의 이주(Migration)
  로우의 블록이동 발생시 기존 ROWID에 새로운 ROWID를 넣어 ROWID를 찾을수 있게함
  인덱스의 ROWID를 변경시키지 않는 대신에 액세스를 할때 여러 블록을 읽어야 하는 오버헤드발생
  이주현상은 로우나 테이블을 삭제하고 테이블을 재생성 해야만 치유( delete and insert )
  체인(chain)
  여러 블록에 걸쳐 데이타가 존재한다는 점에서 이주와 유사
  어떤로우의 길이가 한블록의 크기를 넘을때 필요한 공간만큼 블록을 연결해서 저장하는것
  일반적으로 블록 내에 존재하는 로우는 가변길이로 존재

1.1.2. 클러스터링 팩터(Clustering Factor)

클러스터링 팩터(Clustering Factor)

• 인덱스의 컬럼값으로 정렬되어 있는 인덱스 로우의 순서와 테이블에 저장되어있는 데이터 로우가 얼마나 비슷한 순서로 저장되어 있느냐에 대한 정도를 나타내는 것
  INDEX1: 5ROW를 불러오는데 2블럭을 읽었음 - 클러스터링 팩터가 좋음
  INDEX2: 3ROW를 불러오는데 3블럭을 읽었음 - INDEX1에 비해 클러스터링 팩터가 나쁨
  분리형 테이블의 구조의 최대의 특징인 데이터의 값에 전혀 무관하게 '임의의 위치' 에 저장할 경우
  데이터 작업을 할 경우  최소한 한개 이상의 블록은 엑세스 할수 밖에 없음 (로우를 액세스하지만 실제 DBMS는 블록을 액세스 후 로우를 찾음)
• 인덱스는 인덱스 컬럼과 ROWID 로 정렬
  ROWID로 정렬되었다는것은 물리적인 데이터파일의 블록으로 정렬되고, 거기에서 다시 슬롯번호로 정렬되었다는 것을 뜻
  클러스터링 팩터가 좋은 인덱스로 액세스하면 많은 로우를 액세스 하더라도 보다 적은 블록을 액세스하게 되어 효율적임
• 클러스터링 팩터를 높이는 방법
  원하는 형태로 저장(저장 시 과도한 비용을 발생할수 있음)
  주기적 테이블을 재생성
  저장할 컬럼 순서를 전략차원에서 판단하여 결정

1.1.3. 분리형 테이블의 액세스 영향 요소

가) 넓은 범위의 액세스 처리에 대한 대처방안

• 먼저 가장 중요한 액세스 형태를 선정
  컬럼이 가진 처리범위에 대한 문제를 해결할 수있는 방법을 찾아야 함
• 특정한 모양으로 저장
  특정 액세스 형태에서만 효율을 얻을수 있을뿐
  데이터 등록시의 부하 부담을 무시할수없다면 특정 위치에 저장을 하는 것은 다시 한번 검토
• 지속적으로 증가하는 데이터
  관리적인 측면의 부담이 크다면 파티션을 적용
  인덱스를 전략적으로 구성하고 SQL의 실행계획을 최적화

나) 클러스터링 팩터 향상전략

• 분리형 구조는 아무렇게나 저장해도 괞찮다는 의미이지만 반대로  의도적으로 우리에게 유리한 형태로 저장하는 것도 가능하다는 뜻
• 테이블을 재생성
  주기적으로 재생성하여 이미 저장되어있는 데이터의 응집도를 높여 주는것
  체인을 감소시키고 블록 내 데이터의 저장율을 높여 불필요한 I/O를 줄이기 위해 사용
  가지 깊이(BRANCH DEPTH)가 정리되는 효과
• 테이블에 데이터를 저장할 때 관련된 인덱스를 모두 제거하거나 비활성
• 인덱스를 생성한 채로 대량의 데이터를 저장하면 테이블의 저장 속도가 크게 저하될 뿐만 아니라 인덱스에 많은 분할이 발생하여 인덱스 저장 밀도가 매우 나빠짐
• 테이블을 생성하는 구문에 기본키 제약조건을 지정해 두었다면 테이블을 생성하면서 기본키가 같이 생성되어 버려 비효율(인덱스 저장밀도가 나빠짐)

기타

각 DBMS별, 버젼별 옵션등 다양 - 9I이후 ASSM  도입 (PCTUSED,FREELIST를 명시적으로 지정하지 않고 자동관리 )
DBMS별 테이블 생성시 옵션들이 다양하며 그 옵션은 테이블의 용도(업무형태)에 따라 다양하게 구성될수 있다.