인덱스 구조 테이블

• 데이터를 인덱스 구조로 저장하는 것을 테이블을 말한다.
• Primary key의 순서에 따라 정렬하여 데이터를 저장한다.
• 사용자 입장에서는 일반 테이블과 사용 방법이 다르지 않다.

특징

• Primary Key에 대한 인덱스 공간의 오버헤드가 줄어든다.
• 인덱스를 유지,관리 하는데에 많은 작업이 필요한 복잡한 구조이다.

테스트

create table emp
as 
select object_id empno,
object_name ename,
created hiredate,
owner job
from all_objects
/

alter table emp add constraint emp_pk primary key(empno)/

begin dbms_stats.gather_table_stats(user, 'EMP', cascade=> true);
end;
/

create table heap_addresses
(empno references emp(empno) on delete cascade,
addr_type varchar2(10) ,
street varchar2(20) ,
city varchar2(20) ,
state varchar2(2) ,
zip number,
primary key (empno ,addr_type)
)
/

create table iot_addresses
(empno references emp(empno) on delete cascade,
addr_type varchar2(10) ,
street varchar2(20) ,
city varchar2(20) ,
state varchar2(2) ,
zip number,
primary key (empno ,addr_type)
)
ORGANlZATION INDEX
/

## 데이터 저장
ops$tkyte%ORA11GR2> insert into heap_addresses
2 select empno, 'WORK'， '123 main street' , 'Washington ', 'DC' , 20123
3 from empi
72075 rows created.
ops$tkyte없RA11GR2> insert into iot_addresses
2 select empno , 'WORK', '123 main street ' , 'Washington ' ' 'DC' , 20123
3 from empi
72075 rows created.

## 통계정보 수집
exec dbms_stats.gather_table_stats( user , 'HEAP_ADDRESSES');
exec dbms_stats.gather_table_stats( user, 'IOT_ADDRESSES' );

## HEAP 결과 
....
....

Statistics
o recursive calls
o db block gets
*11* consistent gets
o physical reads
o redo size
1153 bytes sent via SQL*Net to client
419 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
o sorts (memory)
o sorts (disk)
4 rows processed

## IOT 결과 
...
...
Statistics
o recursive calls
o db block gets
*7* consistent gets
o physical reads
o redo size
1153 bytes sent via SQL*Net to client
419 bytes received via SQL*Net from client
2 SQL*Net roundtrips to /from client
o sorts (memory)
o sorts (disk)
4 rows processed

-- 물리적 읽기 수행만 있었지만, 이것도 비용이 드는 작업 이기 때문에 비용이 적게 든다고 말하기는 힘들다. 
-- 논리적인 읽기가 줄어들면서 내부적으로 메모리 구조를 관리하는 래치가 줄어든것을 확인할 수 있다. 

위와 같은 테스트 경우 IOT는 다음과 같은 장점을 얻을 수 있다.

• 캐시에서 더 적은 블럭으로 쿼리가 수행되어 버퍼 캐시 효과가 증가
• 감소한 버퍼 캐시 접근을 통해 사용자 수의 증가에 유연하게 대처할 수 있는 확장성 증가
• 더 빠르게 수행되기 때문에 데이터 추출에 수행되는 전체 일양이 감소
• 각 쿼리에서 수행되는 물리적인 I/O 감소.

create table stocks
( ticker varchar2(10) ,
day date,
value number,
change number,
high number,
low number,
vol number,
primary key( t icker,day)
)
organizati on index
/
-- 힙구조 테이블을 사용했다면, 동일한 데이터베이스 블록에 같은 주식의 로우 2개가 함께 있을 가능성은 거의 없다. 
-- 왜냐하면, 전체 주식에 대한 일자별 기록이 매일 밤에 입력되기 때문이다. 

OVERFLOW 절

• IOT의 데이터가 너무 클때 오버플로 영역을 다른 세그먼트에 저장하도록 하는 것
• 자주 사용하는 데이터와 자주 사용하지 않는 데이터를 나누어서 효과적으로 데이터에 접근하게 할 수 있다.
• 이 절을 사용하기 위한 조건은 다음 2가지중 하나이다.
  • PCTTHRESHOLD : 로우의 데이터 크기가 블록의 PCTTHRESHOLD 비율을 초과하는 경우, 로우의 남겨진 컬럼을 OVERFLOW 영역에 저장한다.
  • INCLUDING : 이 절에 기술된 컬럼까지의 모든 컬럼은 인덱스 블록에 저장하고, 나머지는 오버플로우 영역에 저장한다.

create table iot
( x int,
y date,
z varchar2(2000),
constraint iot_pk primary key (x)
)
organization index
pctthreshold 10
overflow
/

create table iot
( x int,
y date,
z varchar2(2000),
constraint iot_pk primary key (x)
)
organization index
including y
overflow
/

IOT 인덱싱

• IOT에 또다른 인덱스를 추가할 수 있으며 이것을 secondary index라고 부른다.
• IOT의 secondary index는 일반적인 인덱스와 다르게 데이터를 가르키는 값을 logical rowid를 저장하여 관리한다.

h4.logical rowid

• IOT의 primary key에 값을 기초한다.
• 로우의 현재 위치에 대한 추축을 포함할 수 있다.
• IOT 로우들이 다른 블록으로 움직여야 한다변 secondary 인텍스의 추측은 틀리게 된다. 그래서 일반적인 인덱스에 비해 그리 효과적이지 않다.

IOT를 사용하면 일반적으로 2개의 스캔을 진행한다.

1. secondary index 구조 스캔
2. IOT 자체 스캔