insert /*+ append parallel(a, 4) */ into t a (a1, a2, a10)
select /*+ parallel(b, 4) */ a, b, c
from (
select lpad(ceil((level + ((level+level) / 7)) / 5), 10, '0') a, '0'||(mod(level, 5) + 1) b, rpad('-',5,'-') c
from dual
connect by level <= 5000000
) b;
commit;
insert /*+ append parallel(a, 4) */ into t1 a (a1, a2, a10)
select /*+ parallel(b, 4) */ a, b, c
from (
select lpad(ceil((level + ((level+level) / 7)) / 5), 10, '0') a, '0'||(mod(level, 5) + 1) b, rpad('-',5,'-') c
from dual
connect by level <= 5000000
) b;
commit;
select SEGMENT_NAME, HEADER_BLOCK, BYTES, BLOCKS, EXTENTS
from dba_segments
where segment_name in ('T', 'T1')
SEGMENT_NAME
HEADER_BLOCK
BYTES
BLOCKS
EXTENTS
T
97,036
183,500,800
22,400
175
T1(null 허용)
98,188
183,500,800
22,400
175
용량에는 차이가 없고 Header_block에만 차이가 있당..
Header쪽에 Null의 메타정보를 관리를 하는것
혹시 인덱스 관련 변경사항이 있을까
create unique index idx_t on t(a1, a2, a10);
create unique index idx_t1 on t1(a1, a2, a10);
select SEGMENT_NAME, HEADER_BLOCK, BYTES, BLOCKS, EXTENTS
from dba_segments
where segment_name in ('IDX_T', 'IDX_T1')
튜닝 관점에서 날짜 컬럼을 varchar2 보다는 date로 했을때 옵티마이져가 비용 계산을 제대로(?) 한다
1. 날짜 계산
- 옵티마이져가 2010년 2월 28일, 2010년 3월 1일의 간격을 date 타입으로 할 경우는 1일로 계산하지만 varchar2인 경우 73일로 계산
- 2009년 12월 31일과 2010년 1월 1일의 차이는 옵티마이져가 8870 차이로 인식함
2. 날짜데이터의 정합성
- date로 지정했을 경우 2010년 2월 31일을 입력했을때 에러가 발생
3. 물리적인 데이터 사이즈
- varchar2로 했을 경우 적게는 8byte에서 많게는 14byte까지 사용하지만 date 타입인 경우는 7byte로 사용
- 요즘에는 디스크 비용이 많이 저렴해서 디스크를 적게 먹는 이점보다는 한블럭에 좀더 많이 담을수 있다는 이점으로 생각됨
4. 확장성
- 초기에는 날짜 값만 관리하려고 했는데 차후 업무가 변경해서 시분초까지 관리를 해야 된다
- varchar2라면 별도의 컬럼사이즈의 확장혹은 상황에 따라서는 컬럼추가를 해야 되는 경우도 발생
그런데 date 타입의 단점은 어떤점이 있을까에 대해서 생각을 해봤는데 사용의 불편함에 대한 단점이 있기는 한데..
사용자가 잘 사용을 하면은 문제가 없을것 같다는 생각인데 실제로는 그렇지 않다는 의견이 있다
사용자(개발자)가 모든 날짜 계산 함수에 대해서 잘 모른다는 것이다.
교육을 시키면 되지 않을까라고 생각을 하지만 교육장에서 보면은 알겠지만 듣는 사람만 듣는다라는 의견이다..
SI 개발자는 지극히 수동적이고 기술보다는 업무프로세스에 더 관심을 가진다 라고 한다.
더더욱 오픈이 임박한다면
오늘날짜를 가지고 오는 경우 yyyymmdd 컬럼이 date 타입이면
아래와 같이 사용하는게 아니고
yyyymmdd between trunc(sysdate) and trunc(sysdate) + 0.999999
아래와 좌변을 가공을 해서 사용을 한다고 한다..
to_char(yyyymmdd, 'yyyymmdd') = to_char(sysdate, 'yyyymmdd')
정말 보지 않으면 믿지 못할일이..
특별한 성능이슈가 없다면 varchar2을 사용한다는 의견도 있다
툴이 아니 sqlplus로만 이용할 경우 NLS을 맞쳐야 한다는 불편함도 호소했다.
역시 이것도 모든 날짜가 Date타입으로 하는것 보다는 상황에 맞게 varchar2, date 타입을 사용하는것에 대해서 고려후 사용하는게 좋을것 같다.
관련해서 사례에 대해서 정리가 필요할것 같음
new_treeview.zip
