1. 1.1. 테이블과 인덱스의 분리형
   1. 테이블과 인덱스가 별도로 분리되어 있는 구조는 관계형 데이터 베이스의 가장 일반적 저장형식
   2. 1.1.1 분리형 테이블의 구조
   3. 1.1.2 클러스터링 팩터*(clustering factor)
   4. 1.1.3 분리형 테이블의 액세스 영향요소

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

• 관계형 데이터베이스 이전에는 대부분 key와 데이터가 매우 밀접한 관련이 있었음
• Key를 찾기만 하면 원하는 데이터를 찾을 수 있어야 하기 때문에 Key = Data 로 인식
• Key는 데이터를 항상 옆에 두어야 하는 불편함이 있었음

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

• 데이터를 저장할 때 인덱스 영향을 받지 않음으로 인한 부담이 감소
• 데이터에 들어있는 값이 저장과는 무관함(무조건적인 저장 가능)
• 저장 위치를 기록해 두어야 하는 번거로움이 있음
• 무조건 저장으로 인한 저장시의 부담이 감소함

1.1.1 분리형 테이블의 구조

• 한번도 사용되지 않은 블록(10, 13번)
• 일정량 이상의 재사용이 허용된 블록(11번)
• 재사용으로 허용되지 않은 블록(12,14,15번)
• 활용이 가능한 블록들은 사용목록(Free List)에 기록 후 데이터 저장시 사용할 블록으로 제공됨

• [그림 1-1-1] 의 Insert데이터 저장된 모습을 보면 데이터에 들어있는 값과는 전혀 무관하게 저장됨을 알 수 있음.
• 저장할 블록이 재활용 블록(11번) 이었다면, 비어있는 공간에 채웠을 것임.
• 이어진 공간이 없다면 전체블록의 로우 위치를 재배치(Condensing)하는 작업이 발생.
• 블록 하단의 FREE SPACE는 새로운 로우가 들어올 때 사용하는 공간이 아니라, 이미 들어가 있는 로우의 길이에 변화가 생겼을 때 사용하는 공간으로 테이블 정의시 파라메터(PCTFREE)로 지정 가능함.

테이블 스페이스*(Table Space) 란

• 논리적인 저장공간을 말함 (ex. 내 소유의 토지 or 부지)
• 테이블 스페이스는 물리적인 데이터파일(Datafile)로 구성되고 용도별로 나눌 수 있음

세그먼트*(Segment)란

• 테이블 스페이스를 용도별로 나눌 수 있는데 이것을 세그먼트라고 함.
• 이 안에는 Object가 들어올 수 있음.

ROWID의 구성

• Object No. + Datafile No.(Table space당 SeqNo.) + BlockNo. + SlotNo.
• AAARJGAAeAAACBmAAA
• 6 자리 : 데이터오브젝트번호 = DB Segment 식별정보(해당 로우가 속해있는 오브젝트번호)
• 3 자리: Relative file = Tablespace의 상대적 Datafile번호(해당 로우가 속해있는 데이터파일번호)
• 6 자리: Block number = Row를 포함하는DataBlock번호(해당 로우가 속해있는 데이터파일의 데이터 블록 주소값)
• 3 자리: Row number = Block에서의 Row의 Slot : 데이터 블록 내에서 해당 로우의 주소값

• ROWID는 테이블에 존재하는것이 아니라 인덱스에 존재함.
• ROWID에는 로우의 구체적인 위치정보가 들어있는 것이 아니라 방(슬록)번호가 존재

• 이 슬롯 번호속에 로우의 위치 정보가 들어 있다. 이는 블록내의 로우의 위치가 이동 하더라도 ROWID는 결코 변하지 않음.
  
  

응축*(Condensing)

• 블럭 내에 저장될 로우가 한조각(one piece)이 되도록 하기 위한 공간은 있지만 이어진 조각이 없어 저장이 불가능하게 될 때 자동으로 블록의 로우들을 재구성하는 작업이 일어나는데 이를 응축이라 함.
  

이주*(RowMigration)

• 발생한 로우들의 길이가 너무 많이 커져 응축을 하더라도 로우의 길이가 늘어날 때 사용할 여유공간이 부족하게 되면, 이는 결국 다른 블록을 사용할 수 밖에 없게 됨.
• 로우가 다른 블록으로 이동하면 ROWID의 변경을 의미하여 이를 변경시키지 않고 여러 블록을 Access 하는 오버헤드를 감수하는 상태를 로우의 이주(Migration)이라 함.
• 이는 로우나 테이블을 삭제하고 다시 생성해야만 치유할 수 있음

체인*(Chain)

• 여러 블록에 걸쳐 데이터가 존재하는 점에서는 이주와 유사하나 어떤 {+}로우의 길이가 한 블록을 넘는 다{+}면 어떤 방법을 사용하더라도 하나의 블록 내에는 존재할 수 없기 때문,
• 필요한 공간만큼 블록을 연결해서 저장해야 하는데 이것을 체인이 발생했다고 함.
• 이는 본질적으로 이주와는 다름을 유념해야 함.

1.1.2 클러스터링 팩터*(clustering factor)

• 분리형 테이블의 특징인 '임의의 위치'에 저장으로 인해 원하는 값을 찾기위해 필연적으로 여러 블럭을 찾아 보아야 함.
• 이미 액세스해 두었던 블록에서 원하는 로우를 찾을 확률이 높다면 물리적으로 액세스할 블럭의 량은 분명히 줄어듬.
• 임의의 위치에 흩어져 있더라도 얼마나 주변에 모여 있느냐에 따라 액세스 효율은 커다란 영향을 받게 됨

• 인덱스의 컬럼값으로 정렬되어 있는 인덱스 로우의 순서와 테이블에 저장되어 있는 데이터 로우의 위치가 얼마나 비슷한 순서로 저장되어 있는지의 정도를 나타낸 것을 '클러스터링 팩터'라고 표현.

분리형 테이블 구조가 가지는 최대 특징

• 임의의 위치에 저장 = 원하는 값을 찾기 위해 여러 곳을 Access
• 아무 곳에나 저장됨 = 다양한 블록에 흩어져 있을 수 있음

• 관계형 데이터 베이스는 최소한 하나의 블록은 Access 되어야 함
• 1 Row Access = n Block Access

클러스터링 팩터

• 인덱스의 컬럼값으로 정렬되어 있는 인덱스 로우의 순서와 테이블에 저장된 데이터 로우의 위치가 얼마나 비슷한 순서로 저장되어 있는 정도
• 클러스터링 팩터를 향상시키는 것은 엑세스 효율에 직접적인 영향을 줌
• 임의의 위치에 저장이 되는 분리형 테이블은 클러스터링 팩터의 문제가 매우 중요함.
• 클러스터링 팩터가 좋은 인덱스로 엑세스를 하면 많은 로우를 엑세스 하더라도 적은 블록을 엑세스 하게 되어 효율적일 수 있음

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

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

• 대부분의RDBMS에서는 사용자의 요청 데이터를 메모리 내에서만 처리하고 디스크에서는 여유가 있을 때 옮겨다 두는 지연기록(Differed write)방식을 취함
• DISK I/O최적화를 위하여 디스크로의 저장(Write)시간을 실제 작업의 시간과 다르게 유지(Differed Write)하는 기법을 사용한다

1) 소형테이블

• 소량의 데이터라면 그리 많지 않은 블록에 흩어져 있을 것이고, 앞서 발생한 엑세스에 의해 이미 메모리 내에 존재할 가능성이 높음
• 메모리 내의 엑세스라면 그것이 비록 랜덤 엑세스라 하더라도 부하의 부담이 그리 크지 않음으로 충분이 수용 가능
• 중대한 엑세스(Critical Access Path)라면 더 적극적인 방법을 적용
• 특별한 경우가 아니라면 이러한 조치를 하지 않아도 무방함.

2) 중형 테이블

• 등록시에는 부담이 되더라도 좋은 엑세스를 위해서는 찾기 좋은 형태로 저장해 두는 것이 바람직함.
• 가장 중요한 엑세스 형태를 선정
• 특정한 저장위치를 어느 컬럼(들)에 맞추어 줄 것인지 결정
• 데이터 등록시 부하 부담을 무시할 수 없다면 특정 위치에 저장을 하는 것을 재검토

3) 대형테이블

• 첫째 : 단순 저장 형 개념으로 사용시
  • 로그 정보를 관리하는 테이블을 예로 들 수 있음
  • 신속한 저장을 요구함.
  • 분리형이 가장 적적한 형태
  • 파티션과 같은 조치가 필요

• 둘째 : 대량의 데이터 수집*, 랜덤 엑세스 주로 발생
  • 고객 테이블을 예로 들 수 있음
  • 대량의 데이터가 급속히 들어오는 경우는 적음.
  • 범위 처리를 자주 하지 않는 편임
  • 분리형 구조가 가장 적적한 형태
  • 파티션이나 클러스터링을 하더라도 큰 혜택이 없는 경우임

• 셋째 : 대량의 데이터 지속적 증가*, 매우 다양한 엑세스
  • 매출 테이블을 예로 들 수 있음
  • 시스템에 지대한 영향을 미침
  • 데이터 관리 및 엑세스에 대한 부담이 큼
  • 증가하는 데이터에 대한 관리적인 부담이 크면, 파티션을 적용.
  • 최소한의 필요부분 엑세스를 위해 인덱스를 전략적으로 구성
  • SQL의 실행계획을 최적화 하는 방법이 가장 중요

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

• 자주 엑세스 하는 것들이 유사한 위치에 모여 있도록 하는 것을 응집이라고 함. 즉 클러스터링 팩터를 좋게 하는 것을 말함.
• 분리형 구조는 저장 시에 우리가 강제로 제어할 수 없음.
• 이는 주기적인 테이블 재생성으로 응집도를 높여주어야 함.
• 현실적으로는 체인(Chain)을 감소시키고 블록 내 데이터의 저장율을 높여 불필요한 I/O를 줄이기 위해 사용함.
• 이로 인한 효율이 높아지는 이유는 테이블을 재생성 하면 당연히 인덱스도 다시 생성 되야 함. 이는 인덱스의 가지 깊이(Branch depth)가 정리되는 효과를 줌
• 원하는 정렬로 생성된 인덱스가 있다면 약간의 부하가 증가하지만 힌트를 적용해서라도 인덱스를 경유하여 저장하는 것이 좋음.
• 병렬처리로 정렬을 하는 것도 하나의 대안임

테이블 재생성시 주의

• 인덱스를 모두 제거하거나 비활성(Disable)시키는 것이 좋음
• 인덱스 생성한 채로 데이터 저장 시 저장속도 저하를 가져옴
• 인덱스 분할이 발생하여 인덱스 저장 밀도도 나빠짐
• 인덱스 효율을 떨어뜨림