깨비네 마을 ~ 'ㅁ'/

select nvl(sum(a.dr_amt),0), nvl(sum(a.cr_amt),0) from TB_SW23263 a, TB_SW23005 b where a.comp_cd = b.comp_cd and a.comp_cd = '11' and a.yymm >= '200401' and a.yymm tb_sw23263테이블의 인덱스를 살펴보면 우선 PK, 01, 03 인덱스가 모두 다 중복된 인덱스라고 보여집니다. 03 인덱스는 불필요해 보이고, 또한, PK 인덱스 칼럼의 순서를 COMP_CD+YYMM+ACC_CD+DESC_CD1+DESC1+DESC_CD2+DESC2+BUSI_JUMIN_NO+DEPT_CD 로 조정하고 01 인덱스를 삭제해도 무방해 보입니다. 단, 삭제하기 전에 여타 SQL문에서 DEPT_CD..

1. SQL문의 "인스턴스화" 2. 비용이 많이 드는 복잡한 조인에 유용 3. 데이터 요약 및 집계에 유용 4. Materialized View 생성 구문옵션 CREATE MATERIALIZED VIEW mview_name [TABLESPACE ts_name] [PARALLEL (DEGREE n)] [BUILD ] [{ REFRESH [ ON COMMIT | ON DEMAND}] | NEVER RFRESH } ] [ QUERY REWRITE] AS SELECT ... FROM ... . BUILD IMMEDIATE옵션 선택 : CREATE명령이 실행될때 MVIEW가 채워집니다(기본동작) . BUILD DEFERRED옵션 선택 : 구조를 생성하지만 첫번째 REFRESH가 발생 할 때까지 MVIEW를 채우지..

AIX Version 5 Copyright IBM Corporation, 1982, 2007. login: root -----> ① root 계정으로 들어가기 root's Password: ******************************************************************************* * * * * * Welcome to AIX Version 5.3! * * * * * * Please see the README file in /usr/lpp/bos for information pertinent to * * this release of the AIX Operating System. * * * * * **********************************..

SYSTEM계정 1) LOCK을 확인한다 Select * From v$locked_object ; 2) LOCK 걸린 세션의 SERIAL#을 확인한다. Select * From v$session Where sid = '94' Alter system kill session 'SID, SERIAL#'; ' ' 안에 KILL할 SID와 SERIAL#을 입력한다.

Performance Tuning 실무 1. 현실적 저성능 시스템 요인 - 대부분의 주요인은 DB관련 비효율이며 cpu/memory부하가 아닌 비효율적인 I/O 2. 개선 - RDB에 적합한 최적화와 DB Design, Optimizer가 최고의 효율을 낼수 있는 옵티마이징 전략과 집합개념의 고성능 SQL이 성공의 열쇠 1) 100만건 2) 2만건 100 byte 10,000byte 1) 이 두배 빠름, 양으로 I/O는 block단위로 한다(row단위 x) oracle block은 8k 3. batch프로그램의 성능 개선 1) 절차형 -> 비절차형(SQL)로 바꾸는 것이 효율적이다 2) 절차형 TUNING에는 한계가 있다 cursor select ~ -> 개선(8시간 -> 4시간) : index조정 fe..

URPOSE 마지막 건을 찾기 위해 SUB-QUERY에 MAX를 취해 마지막건을 추출함으로써 동일한 테이블의 데이터를 두 번 ACCESS 함으로 비효율이 발생됨. 이것을 INDEX_DESC의 HINT를 사용하여 한번만 데이터를 ACCESS하도록 개선한 사례이다. - 대용량 데이터베이스 솔류션I의 부분 범위 처리 활용 방법 참조 - 해당 내용은 실무의 모든 시스템에 비슷한 사례가 반드시 존재하고 있음. TUNING 전 SQL select MEM.rowid ,MEM.MEMO_BAN ,MEM.MEMO_ID, TO_CHAR(MEM.SYS_CREATION_DATE, 'YYYYMMDDHH24MISS') TO_CHAR(MEM.MEMO_DATE,'YYYYMMDDHH24MISS') , MEM.MEMO_TYPE ,MEM...

논리합 연산자를 사용하는 것은 득보다는 실이 많은 것이 사실이다. 여기에서는 논리합 연산자를 사용할 수 밖에 없는 상황에서 약간의 아이디어를 통해 논리합 연산자를 사용하지 않고 또는 단순 논리합 연산자로 처리하는 방법에 대해서 알아본다. (KEY WORD : 논리합 연산자, IN, OR ) 어느 보험회사의 보험 인수실적을 관리하는 테이블에는 '개포준구분'이라는 컬럼이 있으며, 개별(10), 포괄(20), 준포괄(30) 등의 값을 가지고 있다. 사용자가 화면에서 선택한 구분값에 따라 '개별'일 경우와 '포괄' 또는 '준포괄'등을 포함한 '포괄외'의 두가지 경우로 조회하고자 한다. 여기서는 이 사례 설명의 목적상 성능 및 인덱스와 관련한 설명은 설명한다. 다음의 SQL을 보자. SELECT ………………………..

테이블을 생성할 때 NULL 컬럼의 적용에 대해서 알아본다. (KEY WORD : INDEX 활용, 인덱스, NULL ) 테이블의 컬럼을 설계할 때 기본값(Default Value)을 ‘NULL’로 할 것인가 아니면 임의의 값(예: X, 0, A등)으로 할 것인가는 인덱스 처리와 밀접한 관계를 가진다. 만약 분포도가 양호한 컬럼이 ‘NULL’로 정의되어 있다면 우리는 어쩔수 없이 전체 테이블을 엑세스하거나 다른 조건의 도운을 받을 수 밖에 없다. 또한 너무 많은 로우를 가진 경우에 컬럼을 ‘NULL’로 지정하지 않고 인덱스를 가지고 있다면 넓은 범위를 인덱스로 처리하게 됨으로써 오히려 불리하게 된다. 다음의 SQL을 보자 SELECT ORD_NO, ORD_DATE, ITEM, ORD_QTY FROM OR..

ORACLE8i에서는 FUNCTION BASED INDEX라는 확장된 INDEX의 개념이 도입되었다. 이것은 이전에 모든 사용자가 원했던 B*Tree 인덱스의 제한사항을 다소 완화시켰다. 그러면 이러한 확장 인덱스가 가지는 의미는 무엇이고, 어떤 매카니즘으로 동작하며, B*Tree 인덱스의 어떤 단점을 보완할 수 있는지 알아보자 SCOPE & APPLICATION FUNCTION BASED INDEX의 기본적인 개념과 활용방안 KEY IDEA Function based index, Index SUPPOSITION DESCRIPTION B*Tree INDEX는 정해진 규칙을 준수해야만 INDEX를 사용할 있어 INDEX 컬럼을 가공해야 하는 경우나 계산된 값으로 driving을 해야 하는 경우에 많은 비효..