admin 18 - index

94-1
인덱스
 : 데이터의 로우아이디, 키값 연결해주는 주소록
 
B-tree 인덱스(일반적)
Bitmap 인덱스
 
 
 
 
94-2 B-Tree Index
Leaf : 실제 데이터가 들어 있는 곳
Branch : 적당한 Leaf 블락 찾기위해
Root : 적당한 Leaf 블락 찾기위해
 
 
 
 
94-3
bitmap indexes
(빗맵인덱스)
 
'어떤 데이터가 어디에 있다'를 알려주는것
 = bit로 map을 만든다.
 = map은 값의 종류 만큼 만들어 준다.
 
0과1로 만들어진 map
찾는 데이터만 : 1
나머지 데이터 : 0
 
 
ex) 학생테이블 학생 1000명 성별로 bitmap 만들면? : 남, 여 → 맵=2개 : 남자기준, 여자기준
학생테이블 1000건 주민등록기준으로 bitmap 인덱스 : bitmap은 1000개 → B-tree로 만든다.
 
 
bitmap → 값의 갯수가 적은 것(low-cardinality)에 만든다.
 
 
 
 
94-4
B-tree : High-cardinality
         데이터가 바뀌면 바뀌는 그 블락만 건드린다.
         OLTP
 
bitmap : 값의 갯수가 작아야 한다. low-cardinality
         단점 : 데이터가 바뀌면 모든 맵 다 건드려야 한다.
         OLAP(=data warehousing)
 
※ 참고
OLTP 데이타가 실시간으로 변경되는것 = 회원테이블, 판매테이블(우리가 아는 거의 대부분의 테이블)
↔
OLAP 통계분석 = 100년간 날씨정보, (CRM업체에서 많이함 - 1월엔 어느어느것이 많이 팔린다), 선거분석
                과거 데이터 왕창 집어넣고 통계 뽑을때.
(= DW = data warehousing) ← 엑사데이터(오라클에서 DW시장 잡기위해 만든프로그램)
 
 
 
 
 
 
95-1 인덱스 만드는 문법
 
SQL> create index hr.employees_last_name_idx
  2  on hr.employees (last_name)
  3  pctfree 30
  4  storage (initial 200k next 200k
  5  pctincrease 0 maxextents 50)
  6 tablespace indx;
 
※ PCTUSED 안 적은 이유.
테이블 - 데이터를 지우면 용량이 줄어든다.
인덱스 - 데이터를 지워도 용량이 안줄어 든다. 그래서 PCTUSED 줄 필요없음.
 
 
 
 
 
 
95-2
테이블과 인덱스는 다른 테이블스페이스로 분리해라.
 - 같은 테이블스페이스에 있으면 한쪽이 잡업하는 동안 대기 시간이 너무 길어진다.
 
리두로그에 기록해 두는 이유는 장애났을때 고치기 위해서이다.
인덱스 만들때 기본적으로 리두로그에 기록된다.
인덱스 만들때 장애가나면 지우고 다시만들면된다. 원본 테이블은 따로 있으니까..
인덱스 만들때 리두로그에 기록이 되면 시간 엄청 잡아먹는다.
그래서..
 
※ 인덱스 만들때 옵션 : NOLOGGING
   - redo 로그에 최소값만 적고 기록하지 않는다.
 
 
 
 
 
95-3
Bitmap 인덱스 만드는 문법
 
SQL> create bitmap index orders_region_id_idx
  2  on orders (region_id)
  3  pctfree 30
  4  storage (initial 200k next 200k
  5  pctincrease 0 maxextents 50
  6  nologging
  7  tablespace indx;
 
옵션 : TABLESPACE indx → 테이블스페이스 지정해주기. 안해주면 테이블과 같은 테이블스페이스에 저장되어 버림
 
 
 
96-1 별로안씀
인덱스도 EXTENT 할당가능
 
SQL> alter index orders_region_id_idx
  2  allocate extent (size 200k
  3  datafile '/disk6/indx01.dbf');
 
SQL> alter inex orders_id_idx
  2  deallocate unused;
 
 
 
96-2 Rebuilding Indexes
만들어진 인덱스가 문제가 있을때, 리모델링
 
SQL> alter index orders_region_id_idx rebuild
  2  tablespace indx02;
 
적게 고장 났을때 - 리빌드 사용
많이 고장 났을때 - 새로 만들기
 
 
 
 
 
96-3 별로안씀
리빌드 하는동안 인덱스 못쓴다.
 
SQL> alter index orders_id_idx rebuild online;
 
옵션 : REBUILD ONLINE 하면 리빌드 하는동안 인덱스 사용가능.
단점 : 리빌드 하는 속도가 매우 느려진다.
 
 
 
 
96-4
리빌드 안에 있는 작은 기능
빈공간이 있을때, 공간만 합쳐줌
 
Cf. 리빌드 = 공간합쳐줌 + 망가진것 고쳐줌
 
 
 
 
 
97-1
인덱스 검사 해서 문제 있는지 검사
 
SQL> analyze index 인덱스이름
     validate structure;
 
통상 15%이상 망가져 있으면 리빌드 함.
 
analyze = 힘든 명령어 : 이 명령어를 날리면, 인덱스를 처음부터 끝까지 하나하나 다 검사한다.
        = 의심스러운 인덱스에 사용 : 대량 업데이트된 것
 
※ 조심할 명령어 : ALTER, analyze 명령
 
중간에 컨트롤C누른다고 바로 회복되지 않는다.
 
※ 참고
analyze = 서버프로세스야 인덱스 이상없는지 검사해봐. 서버프로세스는 인덱스 테이블가서 모든 블락을 버퍼캐시로 끌어올린다.
          100억건이라 가정하면, 그것들 다 끌어올려놓고 검사한다. 문제는 버퍼캐시는 LRU알고리즘... 기존 올라와있던 테이블 다 날아간다.
          한번 잘못 날리면 서버 성능 확~ 떨어진다.
 
 
 
 
97-2
인덱스 드랍
 
SQL> drop index 인덱스이름;
 
 
97-3
사용여부 검사 - 믿지말기
 
감사 시작
SQL> ALTER INDEX 인덱스이름
     MONITORING USAGE
검사 끝
     NOMONITORING USAGE
 
Ex) 월요일 아침(시작) ~ 저녁(끝) 안써서 지웠음 → 토요일 사용 인덱스 : 주간현황
    이번주 일요일(시작) ~ 다음주 일요일(끝) : 안써서 지웠음 → 매월 말일 사용 인덱스 : 월말재고검사