출처 : 네이버지식인 노하우
http://kin.naver.com/knowhow/detail.nhn?d1id=8&dirId=8&docId=552905&qb=U1FM6rOg7IiY65CY6riw&enc=utf8§ion=kin&rank=3&search_sort=0&spq=0
지난 이야기에서 생성한 테이블 정보들입니다.
1.아르바이트생 정보
CREATE TABLE EMP_INF
(
EMP_NO CHAR (8 ), /* 사번:년(2)+월(2)+일번(4) */
SNAME VARCHAR2(50), /* 이름 */
PHONE VARCHAR2(20), /* 핸드폰 */
...
...
CONSTRAINT EMP_INF_PK PRIMARY KEY (EMP_NO)
USING INDEX TABLESPACE TS00 PCTFREE 10
STORAGE ( INITIAL 5M )
)
TABLESPACE TS01
PCTUSED 40
PCTFREE 10
INITRANS 1
MAXTRANS 255
STORAGE (
INITIAL 20M
NEXT 20M
MINEXTENTS 1
MAXEXTENTS 2147483645
PCTINCREASE 0
FREELISTS 1
FREELIST GROUPS 1
BUFFER_POOL DEFAULT
)
NOLOGGING
NOCACHE
PARALLEL ( DEGREE DEFAULT INSTANCES DEFAULT )
NOMONITORING;
2.일별 출퇴근 정보
CREATE TABLE WORK_INF
(
ATTN_YMD CHAR(8 ), /* 출근일자:년월일 */
EMP_NO CHAR(8 ), /* 사번:년(2)+월(2)+일번(4) */
CHECK_IN DATE, /* 출근일시 */
CHECK_OUT DATE, /* 퇴근일시 */
...
CONSTRAINT WORK_INF_PK PRIMARY KEY (ATTN_YMD,EMP_NO,CHECK_IN)
USING INDEX TABLESPACE TS00 PCTFREE 10
STORAGE ( INITIAL 10M )
)
TABLESPACE TS01
PCTUSED 40
PCTFREE 20
INITRANS 1
MAXTRANS 255
STORAGE (
INITIAL 20M
NEXT 20M
MINEXTENTS 1
MAXEXTENTS 2147483645
PCTINCREASE 0
FREELISTS 1
FREELIST GROUPS 1
BUFFER_POOL DEFAULT
)
NOLOGGING
NOCACHE
PARALLEL ( DEGREE DEFAULT INSTANCES DEFAULT )
NOMONITORING;
3.월별 시급 정보
CREATE TABLE PAY_INF
(
PAY_YM CHAR (8 ), /* 출근일자:년(4)+월(2)+구분(MM/YY) */
EMP_NO CHAR (8 ), /* 사번:년(2)+월(2)+일번(4) */
SALARY NUMBER(12), /* 실급여액 */
...
CONSTRAINT PAY_INF_PK PRIMARY KEY (PAY_YM,EMP_NO)
USING INDEX TABLESPACE TS00 PCTFREE 10
STORAGE ( INITIAL 10M )
)
TABLESPACE TS01
PCTUSED 80
PCTFREE 10
INITRANS 1
MAXTRANS 255
STORAGE (
INITIAL 20M
NEXT 20M
MINEXTENTS 1
MAXEXTENTS 2147483645
PCTINCREASE 0
FREELISTS 1
FREELIST GROUPS 1
BUFFER_POOL DEFAULT
)
NOLOGGING
NOCACHE
PARALLEL ( DEGREE DEFAULT INSTANCES DEFAULT )
NOMONITORING;
여러분들이 생각하셨던 내용과 비슷할껍니다. 그러나 운영하다보면 어려움이 많이 것은 사실입니다. 당장 1~2년은 가능하지만 10년을 바라본다면 걱정이되는 것은 당연할것입니다. 그러나 애석한 점은 모든 개발자,관리자가 그점을 생각하지 않는다는데 큰 문제가 있습니다. 똑 일이 닥치고 나면 전전긍긍 대응하려하지만 참으로 어려운 일입니다. 저또한 그랬으니깐 말이죠.^^
한 예로 집계성 통계정보가 몇년이 지나면서 검색에 어려움이 발생하였습니다. 테이블 크기가 몇기가바이트에 다다르면서 한계에 봉착한 것입니다. 더더군다나 아주 잘 된 설계이지만 수수로 발생되는 재생성건에다 불특정 유저의 수정사항이 연속해서 발생하면서 주/월단위 추이 조회시 많은 어려움이 있었습니다. 간단하지만 먼저 수행한 행동이 일일 Analyze 실행이였습니다. Oracle에서 제공하는 DBMS_UTIL.ANALYZE라는 기능을 사용하여 수행되도록 하였습니다. 또 이와 더부러 관리상의 어려움은 있지만 INDEX ~ REBUILD 기능을 특정 주기마다 수행하여 Table을 최적화 시켰습니다. 몇몇은 안정화 되었지만 일일 집계되는 테이블에 대해서는 해결이 되지 않아 Partition Table 기법과 무리가되더라도 집계성 테이블이기에 IOT INDEX Table기법을 활용하여 새로 도입하여 해결했던 적이 있습니다.
이처럼 그냥 생성만 하고 SELECT하면 되겠지 하는 생각에 앞얘기는 경험해 나가면서 해결하려는 생각이 많은듯 합니다. 또 그렇게 교육도 받고요. 이게 어쩔수 없는 상황이지만 그래도 Table생성 할 때 한번이라도 고민해서 생성하게되면 조금은 도움이 되지 않을까 생각이듭니다. 위에 테이블 생성기법중 Partition이나 IOT 기법은 예산도 많이 들어갈 수 있고 잘못 관리되면 서버 부하도 일으킬수 있습니다. 따라서 아주 신중히 고려해야 수행해야 하고 경헙이 있는 사람의 의견을 듣는게 좋을듯합니다. 왜냐면 이 기법들은 대부분 크게 활용되는 경우는 없기 때문입니다. 통신회사나 금융권에서 사내시스템으로 아주 큰 대용량 처리시에만 필요한 부분이 대부분일 것이기 때문입니다. 그러나 ANALYZE나 INDEX REBUILD는 매일은 아니더라도 실행계획은 수립하셔서 사용하시면 좋을듯 합니다.
마지막으로 TABLE 생성 쿼리 하단에 NOLOGGING 옵션이 있습니다. 쉽게 말해서 Table 나아가서 Database에 영향을 미치는 변경에 대해 Redo Log관리를 하게되는 데 이를 안하겠다는 뜻입니다. 과연 안될까요? 그냥 조금만 관리(Log남기기)해 달라는 뜻으로 보시면 됩니다. 간혹 이놈의 로그가 너무 많이 싸여서 짜증날 수도 있음.
오늘은 여기까지만 이야기하겠습니다. 머리아프시죠? 헉 나마 그런가.. ^^ 으악! 내일 월요일이네요. 오늘 마무리들 잘하시고요 안녕히들 주므세요. 다음 이야기부턴 인제 SQL(Query) 잘짜는 법에대해 특정 상황과 주제별로 실제 활용되는 기법을 예로들어 이야기 할겁니다. 그전 제가 이야기 했던 1~5번 이야기를 조금 이해하시면 큰 도움이 되리라 생각듭니다.
아자~ 화이팅
'04번. IT 힌트얻기 > ▶ DB/ SQL ' 카테고리의 다른 글
[SQL고수되기] 일곱번째 이야기 (0) | 2011.10.05 |
---|---|
[SQL고수되기] 여섯번째 이야기 (0) | 2011.09.30 |
[SQL고수되기] 네번째 이야기 (0) | 2011.09.30 |
[SQL고수되기] 세번째 이야기 (0) | 2011.09.30 |
[SQL고수되기] 두번째 이야기 (0) | 2011.09.29 |