8.(12c 의 뉴피쳐 ) 오라클 heatmap 과 ADO

▩ 예제8. (12c 의 뉴피쳐 ) 오라클  heatmap 과 ADO

 데이터에는 "정보 생애 주기" 가 있습니다. 
 처음에 데이터가 create 되고 insert 될 때는 활발하게 조회되다가
 시간이 점점 흐르면서 가뭄에 콩나듯이 1년에 한두번 조회됩니다. 
 이것을 데이터의 생애주기 라고 합니다.  

 그래서 오라클도 이 생애주기에 맞춰서 데이터를 관리하겠다는것입니다.

 여기서 관리라는것은 더이상 안쓰는 오래된 데이터는 좀 저렴한 스토리지로 
 이동시키거나 데이터를 압축해서 저렴하게 시스템을 운영하겠다는 의미입니다.

 그냥 삭제하기에는 뭔가 찝찝하고 남겨두기에는 잘 검색안되는 데이터들을
 별도로 관리하겠다는 것입니다.  그러면 어떤 데이터가 활발하게 검색되는지를
 알아햐는데 그게 바로 heat map  입니다.

 아래의 그림의 네모 하나가 세그먼트(테이블,인덱스)인데 빨간색이 활발하게 검색되는
 테이블인것이고 파란색은 거의 검색되지 않는 테이블인것입니다. 

 그림: https://cafe.daum.net/oracleoracle/SoYx/53

 쿼리로도 확인할 수 있습니다.

set lines 150
col owner              format a10;
col object_name        format a20;
col subobject_name     format a15;
col segment_read_time  format a20;
col segment_write_time format a20;
col full_scan          format a20;
col lookup_scan        format a20;
 
select owner, object_name, subobject_name, 
       segment_read_time, segment_write_time, full_scan, lookup_scan
from dba_heat_map_segment;


위의 쿼리로 확인을 하려면 oracle heatmap 기능을 켜야합니다.

alter  system  set  heat_map = on;

connect scott/tiger

select * from emp;
select * from dept;

connect /  as sysdba

select owner, object_name, subobject_name, 
       segment_read_time, segment_write_time, full_scan, lookup_scan
from dba_heat_map_segment;

좀더 상세한 정보를 보려면 다음의 쿼리를 이용합니다. 

select
  owner,
  object_name,
  subobject_name,
  to_char(track_time,'yyyy/mm/dd hh24:mi:ss') track_time,
  segment_write,
  segment_read,
  full_scan,
  lookup_scan,
  n_write,
  n_fts,
  n_lookup
from
  sys."_SYS_HEAT_MAP_SEG_HISTOGRAM" h,
  dba_objects o
where o.object_id = h.obj#
order by owner, object_name, subobject_name, track_time;

데이터의 라이프 싸이클의 뒷부분에 해당 되는 테이블들은 
다른 저렴한 스토리지로 옮기거나 또는 압축을 하면 됩니다. 

압축과 옮기는 2가지 동작을 다음의 용어로 부릅니다.

1. compression tiering  :  오라클이 데이터의 라이프 싸이클을 보고 시기가 되면
                                  알아서 압축해주겟다는것입니다. 

2. storage  tiering :  테이블 스페이스가 얼마나 꽉찼는지를 기준으로 자동으로
                           잘 조회되지 않는 테이블을 move  시킵니다. 

 dba는 다음의 명령어만 수행하면 알아서 오라클이 관리해줍니다.

■ 실습

#1. emp 테이블에 compression tiering의 대상이 되도록 하시오 !

 "4일동안 아무 변경이 없으면 emp 테이블을 압축해라 !"

alter  table  emp  ilm  add  policy  row  store  compress  advanced  segment
 after  4 days  of  no modification;

※  옵션:  1. no modification : 일정 기간동안 변경이 없으면 압축을 실행
             2. no access :  일정 기간동안 접근이 없으면 압축을 실행
             3. creation time :  생성한지 일정기간이 지나면 압축을 실행 

문제1.  dept 테이블에 대해서 30일 동안 아무런 엑세스가 없으면 자동으로 압축이
          되도록 하시오 !

alter  table  dept  ilm  add  policy  row  store  compress  advanced  segment
 after  30 days  of  no access;

#2.  이번에는 salgrade 테이블에 대해서 salgrade 테이블이 있는 테이블 스페이스의
       사용율이 85%  를 넘어가면 salgrade 테이블을 다른 테이블 스페이스로
       자동으로 이동시켜라! 중요도가 낮은 테이블들을 더 저렴한 스토리지로
        옮기는것입니다. 

설명그림:  https://cafe.daum.net/oracleoracle/SoYx/55

문제1. ts01 이라는 테이블 스페이스를 생성하세요.

SQL> create  tablespace  ts01
         datafile  '/home/oracle/ts01.dbf'  size  100m;

문제2. 현재 salgrade 테이블이 어느 테이블 스페이스에 있는지 확인하시오!

drop  table  salgrade;
 
create table salgrade
( grade   number(10),
  losal   number(10),
  hisal   number(10) )
  tablespace  users;
 
insert into salgrade  values(1,700,1200);
insert into salgrade  values(2,1201,1400);
insert into salgrade  values(3,1401,2000);
insert into salgrade  values(4,2001,3000);
insert into salgrade  values(5,3001,9999);
 
commit;

select table_name, tablespace_name
   from user_tables
   where  table_name='SALGRADE';

USERS 테이블 스페이스에 있습니다.

문제2.  USERS 테이블 스페이스가 85% 이상 차면 자동으로 TS01 테이블 스페이스로
          salgrade 테이블이 move  되게 하시오!

begin
  dbms_ilm_admin.customize_ilm( dbms_ilm_admin.tbs_percent_used, 85);
  dbms_ilm_admin.customize_ilm( dbms_ilm_admin.tbs_percent_free, 25);
end;
/

alter   table  scott.salgrade   ilm  add  policy  tier  to  ts01;