'대용량 데이터베이스 솔루션'에 해당되는 글 8건

  1. 2014.11.21 3-3강
  2. 2014.11.21 3-2강
  3. 2014.11.13 3-1강
  4. 2014.11.12 2-4강
  5. 2014.10.20 2-2강
  6. 2014.10.15 1-3강
  7. 2014.10.14 1-2강
  8. 2014.10.07 1-1강

 

  • 액세스경로의 결정

Select A1, A2, …, B1, B2, …, C1, C2, …
FROM TAB1 x, TAB2 y, TAB3 z
WHERE x.A1 = y.B1
AND z.C1 = y.B2
AND x.A2 = '10'
AND y.B2 LIKE 'B%'

   

구분

Access 순서

인덱스 전략

1

TAB1->TAB2->TAB3

A2
B1, B2

C1

2

TAB2->TAB3->TAB1

B2
C1
A1, A2

3

TAB3->TAB2->TAB1

B2 -> C1, Full Table scan
B2
A1, A2

   

  • JOIN과 LOOP-QUERY
    - LOOP-QUERY는 DBMS 콜이 많다. DBMS 콜도 부하의 원인이 된다.

    - 한쪽만 가지고 집합을 줄일 수 있으면 절대 먼저 조인을 하지 말라.

       

  • Nested Loop JOIN

    - 순차적(부분범위처리 가능)

    - 종속적(먼저 처리되는 테이블의 처리 범위에 따라 처리량 결정)

    - 랜덤(Random) 액세스 위주

    - 연결고리 상태에 따라 영향이 큼

    - 주로 좁은 범위 처리에 유리

       

  • SORT MERGE JOIN

    - 동시적(무조건 전체범위 처리)

    - 독립적(자기의 처리범위만으로 처리량 결정)

    - 스캔 액세스 위주

    - 연결고리 상태에 영향이 없음

    - 주로 넓은 범위 처리에 유리

       

  • Join 방법의 결정

 

신고

'대용량 데이터베이스 솔루션' 카테고리의 다른 글

3-3강  (0) 2014.11.21
3-2강  (0) 2014.11.21
3-1강  (0) 2014.11.13
2-4강  (0) 2014.11.12
2-3강  (0) 2014.11.04
2-2강  (0) 2014.10.20
Posted by TM ~ing

 

  • 추가된 INDEX가 미치는 영향(예제)

    - 인덱스: CHULNO+ORDNO+ITEM
    - 해석: PK를 사용함

SELECT CULNO, ORDNO, ITEM, CHULQTY FROM CULITEM
WHERE CHULNO = '2565' AND ORDNO = '8584' AND LOT = 'P0009'

TABLE ACCESS BY ROWID CHULITEM
INDEX RANGE SCAN PK_CHULITEM

- 인덱스: CHULNO+ORDNO+ITEM, LOT

- 해석: Fully equal이 되는 LOT 인덱스를 사용함

, CHULQTY FROM CULITEM
WHERE CHULNO = '2565' AND ORDNO = '8584' AND LOT = 'P0009'

TABLE ACCESS BY ROWID CHULITEM
INDEX RANGE SCAN CI_LOT

- 인덱스: CHULNO+ORDNO+ITEM, LOT+ITEM

- 해석: 다시 PK를 사용함.

SELECT CULNO, ORDNO, ITEM, CHULQTY FROM CULITEM
WHERE CHULNO = '2565' AND ORDNO = '8584' AND LOT = 'P0009'

TABLE ACCESS BY ROWID CHULITEM
INDEX RANGE SCAN PK_CHULITEM

   

  • 분포도 차이가 심한 경우의 인덱스

    - COL1의 분포도

A

B

C

D

E

78%

4%

6%

7%

5%

-> 이럴 경우는 A를 Null로 해서, 인덱스 사이즈도 줄어 들고, 속도도 빠르게 할 수 있다.

   

  • INDEX 재생성

ALTER INDEX index_name REBUILD
UNRECOVERABLE
PARALLEL 10;

- 현존하는 INDEX를 읽어 재생성
- DDL Lock을 발생시키지 않음

- 병렬처리 가능

- Direct database reads and writes

- 멀티블럭을 비동기적으로 I/O
- REDO LOG에 쓰지 않도록 할 수 있음

   

  • 비트맵 인덱스

    - 다량의 데이터를 가지고, 분포도가 안 좋은 컬럼에 적합한 인덱스(ex: 옷 색깔, 옷 사이즈 등)

    - or, not, null 을 판단할 수 있다.

    - 블럭레벨 Locking

    - 데이터웨어하우징에 적당

       

  • 조인 수행속도 결정 요소

    - 드라이빙 테이블의 크기에 따라서 수행 속도가 결정 된다. (작을 수록 빠르다.)

    - 1:M 조인시 1부터 Driving 시킨다.

    - 연결에 성공한 양은 다음 연결할 일 양에 영향을 미친다.

       

  • 조인 수행 속도 결정 요소

    - 연결고리에 해당하는 컬럼에는 양쪽 다 인덱스가 있어야 한다.

    - 테이블 조인시, 후행 테이블에는 키 값에 대한 인덱스가 있어야 한다.

    - 양쪽 모두 index가 없으면 SORT MERGE 방법으로 처리

       

  • 실행계획에 따른 ACCESS량

SELECT a.FLD1, …, b.FLD1,… FROM TAB2 b, TAB1 a
WHERE a.KEY1 = b.KEY2
AND b.FLD2 like 'A%'
AND a.FLD1 = '10'

- FLD1 = '10'은 5000개가 있고, b.FLD2 like 'A%'는 100개가 있다. 이런 상황에서는 B가 드라이빙 되는 것이 더 좋다.

   

  • 처리 범위에 따른 ACCESS량

SELECT a.FLD1, …, b.FLD1,… FROM TAB2 b, TAB1 a
WHERE a.KEY1 = b.KEY2
AND b.FLD2 = 'ABC'
AND a.FLD1 = '10'

- FLD1 = '10'은 500ROW가 있고, FLD2 = 'ABC'는 10 Row가 있다. 이런 상황이라면 FLD2를 드라이빙 테이블로 사용하는 것이 효과적이다.

- TAB2를 드라이빙 하기 위해서, ANALZE table, HINT, RTRIM(a.FLD1) 방법을 사용할 수 있다.

   

  • JOIN의 순서에 따른 속도차이

SELECT /*+ ORDERED */ CHULNO, CHULDATE, CUSTNAME
FROM CUSTOMER Y, CHULGOT X
WHERE X.CUSTNO = Y.CUSTNO
AND X.CHULDATE = '941003'
AND T.NATION = 'KOR'

1 rows
0.15 sec
 

NESTED LOOPS
TABLE ACCESS BY ROWID CUSTOMER
INDEX RANGE SCAN CU_NATION
TABLE ACCESS BY ROWID CHULGOT
AND
INDEX RANGE SCAN CH_CUSTNO

INDEX RANGE

SELECT CHULNO, CHULDATE, CUSTNAME
FROM CUSTOMER Y, CHULGOT X
WHERE X.CUSTNO = Y.CUSTNO
AND X.CHULDATE = '941003'
AND T.NATION = 'KOR'

1 rows
0.04 Sec
 

NESTED LOOPS
TABLE ACCESS BY ROWID CHULGOT
INDEX RANGE SCAN CH_CHULDATE
TABLE ACCESS BY ROWID CUSTOMER
INDEX UNIQUE SCAN PK_CUSTNO

   

 

  • JOIN시 INDEX의 영향

    - 조인 연결 고리에서 인덱스 없는 테이블을 드라이빙 한다.

    - 만약 연결 고리에 둘다 이상이 생기면 MERGE JOIN 으로 풀린다.

신고

'대용량 데이터베이스 솔루션' 카테고리의 다른 글

3-3강  (0) 2014.11.21
3-2강  (0) 2014.11.21
3-1강  (0) 2014.11.13
2-4강  (0) 2014.11.12
2-3강  (0) 2014.11.04
2-2강  (0) 2014.10.20
Posted by TM ~ing

 

  • 추가된 인덱스 컬럼의 역할

Select A, B from tab1 where A='2' AND C=51;

- INDEX (A+B) : C의 값을 확인하기 위해 A가 2인 값은 모두 Table Access를 한다.

- INDEX (A+B+C) : A값이 2이고, C 값이 51인 로우에 대해서만 Table Access를 하여 불필요한 Random IO 제거 가능.

   

  • 결합인덱스 컬럼순서결정

    1. 항상 사용하는가?

    - 여러 SQL문의 조건절에서 사용되는지 확인.

    2. 항상 '='로 사용되는가?

    - BETWEEN이나, LIKE를 =로 바꿀수 있는 것 까지 확인 해야함.

    3. 분포도가 좋은 순서 대로

    4. Sort 순서 대로

    5. 어떤 컬럼을 추가?

    - 2개의 인덱스를 두고, 애매한 상황에서 한쪽에 추가 컬럼을 두어 명확하게 한쪽 인덱스를 사용하게 할 수 있음.

       

  • 인덱스 선정 절차

    - 해당 테이블의 액세스 유형 조사

    - 대상 컬럼의 선정 및 분포도 분석

    - 반복 수행되는 액세스

    - 클러스터링 검토

    - 인덱스 컬럼의 조합 및 순서의 결정

    - 시험생성 및 테스트

    - 수정이 필요한 애플리케이션 조사 및 수정

    - 일괄 적용

       

  • INDEX의 활용(선정기준)

    - 분포도가 좋은 컬럼은 단독적으로 생성한다.

    - 자주 조합되어 사용되는 경우는 결합인덱스 생성

    - 각종 액세스 경우의 수를 만족할 수 있는 인덱스간의 역할 분담

    - 가능한 수정이 빈번하지 않는 컬럼

    - 기본키 및 외부키

    - 결합 인덱스의 컬럼순서 선정에 주의

    - 반복 수행 되는 조건은 가장 빠른 수행속도를 내게 할 것

    - 실제 조사된 액세스 종류를 토대로 선정 및 검증

       

  • Index의 활용

    - 새로 추가된 인덱스는 기존 엑세스 경로에 영향을 미칠 수 있음

    - 지나치게 많은 인덱스는 오버헤드를 발생

    - 넓은 범위를 인덱스로 처리시 많은 오버헤드 발생(random io)

    - 옵티마이저를 위한 통계데이타를 주기적으로 갱신

    - 인덱스 개수는 테이블의 사용형태에 따라 적절히 생성

    - 분포도가 양호한 컬럼도 처리범위에 따라 분포도가 나빠질 수 있음

    - 인덱스 사용원칙을 준수해야 인덱스가 사용되어짐

    - 조인시에 인덱스가 사용여부에 주의

       

  • 추가된 인덱스가 미치는 영향

SELECT * FROM TAB1 WHERE A = '10' AND B = '941005' AND C = '123'

- INDEX1(A,B), INDEX2(C)가 존재할 때는 INDEX1을 사용한다.

- INDEX1(A,B,D), INDEX2(C)가 존재할 때는 INDEX2를 사용한다.

-> 이유는 Fully equal이 우선 순위가 높기 때문이다.

 

신고

'대용량 데이터베이스 솔루션' 카테고리의 다른 글

3-3강  (0) 2014.11.21
3-2강  (0) 2014.11.21
3-1강  (0) 2014.11.13
2-4강  (0) 2014.11.12
2-3강  (0) 2014.11.04
2-2강  (0) 2014.10.20
Posted by TM ~ing

 

 

  • OPTIMIZER의 취사 선택

    1. Ranking의 차이

    - '='이 Like 보다 우선 순위가 높아서 '='에 해당하는 EMPNO 인덱스 사용

SELECT * FROM EMP WHERE ENAME LIKE 'AB%' AND EMPNO = '7890'

2. INDEX Merge 회피

- ENAME, JOB 둘 중에 한가지 인덱스만 사용(인덱스 생성 진 시기, 뒤에서 부터 사용)

SELECT * FROM EMP WHERE ENAME LIKE 'AB%' AND JOB LIKE 'SA%'

3. Low COST의 선택

- CBO에 의해 Full Table SCAN

SELECT * FROM EMP WHERE EMPNO >'10'

4. HINT에 의한 선택
- 힌트로 인하여 JON Index만 사용함.

SELECT /*+ INDEX(EMP JOB_IDX) */ *
FROM EMP
WHERE ENAME LIKE 'AB%'
AND JOB LIKE 'SA%'

※ CBO는 통계 정보를 바탕으로 하기 때문에, 어디로 튈지 모른다.

   

  • INDEX의 활용

    - 6 블록 이상의 테이블에 적용(이하는 연결고리만)

    - 컬럼의 분포가 10~15%(약 3천건)에 적용

    - 분포도가 범위 이내이고 절대량이 많은 경우 단일 테이블 클러스터링을 검토

    - 분포도가 범위 이상이고 부분범위 처리를 목적으로 하는 경우에는 적용

       

  • INDEX Merge 방식

SELECT COL1, COL2, … FROM TAB1 WHERE COL1 = 'ABC' AND COL2 = '123' ;

- COL1과 COL2 인덱스의 Rowid를 비교해 가면서 읽고, 같은 rowid인것에 table access를 하여 값을 가져온다.

   

  • INDEX MERGE와 결합인덱스 비교

    - INDEX MERGE는 해당하는 각 인덱스의 값에 대하여 RANGE SCAN을 전부 해야하지만, 결합 인덱스로 구성하면 해당하는 값만 바로 가져올 수 있다.

       

  • INDEX MERGE 불리한 경우

    - MERGE 되는 INDEX들의 분포도 차이가 많이 날 경우는 똑똑한 조건으로 INDEX를 사용하고, 멍청한 조건을 체크조건으로 사용하는 것이 더욱 효과적이다.

       

  • INDEX MERGE 유리한 경우

    - MERGE 되는 INDEX들의 분포도 차이가 적고 MERGE 된 ROW의 수가 아주 적은 경우

    - MERGE 되는 비율이 높고 부분범위 처리를 하는 경우

       

  • INDEX MERGE와 결합 INDEX 비교 예제

    - INDEX 별도 생성(culdate, status)

쿼리

결과

SELECT /*+ AND_EQUAL(A ch_culdate ch_status) */ custno, culdate
FROM CHULGOT A
WHERE CULDATE ='941003'
AND STATUS = '90'

13 rows, 0.21sec

- 결합 INDEX 생성(chuldate+status)

쿼리

결과

SELECT CUSTNO, CHULDATE FROM CULGOT A
WHERE CHULDATE = '980120'
AND STATUS = '90'

13 rows, 0.01 sec

   

  • EQUAL이 결합 인덱스에 미치는 영향

    - 결합 인덱스의 앞에 조건은 '=' 조건으로 해야 ACCESS 효율을 향상 시킬 수 있다.

    - RANGE 조건은 '='로 바꿀 수 있는지 확인

 

 

신고

'대용량 데이터베이스 솔루션' 카테고리의 다른 글

3-2강  (0) 2014.11.21
3-1강  (0) 2014.11.13
2-4강  (0) 2014.11.12
2-3강  (0) 2014.11.04
2-2강  (0) 2014.10.20
2-1강  (0) 2014.10.17
Posted by TM ~ing
  • 부분 범위 처리
    • 전체 범위 처리: Full Range Scan 후, 가공하여 Array Size 만큼 추출
    • 부분 범위 처리: 조건을 만족하는 Row 수가 Array Size에 도달되면 추출
      • INDEX나 Cluster를 적절히 활용한 SORT의 대체
      • MAX 처리
      • TABLE은 ACCESS하지 않고 INDEX만 사용하도록 유도
      • EXISTS의 활용
      • ROWNUM의 활용
      • QUERY의 이원화하여 일부분씩 SCAN하도록 유도
      • Stored Function을 이용

           

  • SORT를 대신하는 INDEX

1-1. 전체 범위 처리(인덱스:YMD)

1-2. 부분 범위 처리(인덱스:YMD+ITEM)

SELECT * FROM PRODUCT WHERE YMD = '951023'

AND ITEM LIKE 'AB%' ORDER BY YMD, ITEM

SELECT * FROM PRODUCT WHERE YMD = '951023'

AND ITEM LIKE 'AB%';

2-1. 전체 범위 처리(인덱스:ORDDATE)

2-2. 부분 범위 처리(인덱스 Desc 옵션)

SELECT ORDERDATE, CUSTNO FROM ORDER1T WHERE ORDDATE BETWEEN '940101' AND '941130' ORDER BY ORDERDATE DESC

SELECT /*+ INDEX_DESC(A orderdate) */

ORDERDATE, CUSTNO

FROM ORDER1T A

BETWEEN '940101' AND '941130'

3-1. 전체 범위 처리(인덱스:ORDERDATE)

3-2. 부분 범위 처리(인덱스 Desc 옵션)

SELECT ORDERDATE, CUSTNO FROM ORDER1T WHERE ORDERDEPT LIKE '7%'

ORDER BY ODERDDATE DESC

SELECT /*+ INDEX_DESC(A orderdate)*/ ORDERDATE, CUSTNO
FROM ORDER1T A
WHERE ORDERDEPT LIKE '7%' AND ORDERDATE <= '991231'

   

  • INDEX로만 처리

1-1. 전체 범위 처리(인덱스: DEPT)

1-2. 부분 범위 처리(인덱스: DEPT+QTY)

SELECT DEPT, SUM(QTY) FROM PRODUCT WHERE DEPT LIKE '12%' GROUP BY DEPT;

SELECT DEPT, SUM(QTY) FROM PRODUCT WHERE DEPT LIKE '12%' GROUP BY DEPT;

   

  • MAX 처리

1-1. 전체 범위 처리(인덱스: DEPT)

1-2. 부분 범위 처리(인덱스: DEPT+SEQ, DESC 옵션)

SELECT MAX(SEQ) + 1

FROM PRODUCT WHERE DEPT='12399';

SELECT /*+ INDEX_DESC(A INDEX) */ SEQ + 1 FROM PRODUCT WHERE DEPT = '12300' AND ROWNUM = 1;

2-1. 전체 범위 처리(인덱스: ORDERDEPT+ORDDATE)

2-2. 부분 범위 처리(인덱스 DESC 옵션)

SELECT MAX(ORDDATE) FROM ORDER1T WHERE ORDDEPT = '430'

AND STATUS = '30'

SELECT /*+ INDEX_DESC(A dept_date) */ ORDERDATE FROM ORDER1T
WHERE ORDDEPT = '430' AND STATUS ='30' AND ROWNUM = 1;

   

  • EXISTS

1-1. 전체 범위 처리(인덱스: DEPT)

1-2. 부분 범위 처리(서브 쿼리)

SELECT COUNT(*) INTO :CNT

FROM ITEM_TAB

WHERE DEPT='101' AND SEQ > 100

IF CNT > 0

...

SELECT 1 INTO :CNT
FROM DUAL
WHERE EXISTS ( SELECT 'X'
FROM ITEM_TAB
WHERE DEPT = '101'
AND SEQ > 100)
. ….
IF CNT >0
....

   

  • ROWNUM

1-1. 전체 범위 처리(인덱스: DEPT)

1-2. 부분 범위 처리(서브 쿼리)

SELECT COUNT(*) INTO :CNT

FROM ITEM_TAB

WHERE DEPT='101' AND SEQ > 100

IF CNT > 0

...

SELECT COUNT(*) INTO :CNT

FROM ITEM_TAB

WHERE DEPT='101' AND SEQ > 100
AND ROWNUM=1
...
IF CNT > 0
...

   

  • 1:M JOIN의 부분 범위 유도1

1-1. 전체 범위 처리

1-2. 부분 범위 처리

SELECT x.CUST_NO, x.ADDR, x.Name,…
FROM CUST x, REQT y
WHERE x.CUST_NO = y.CUST_NO
AND x.CUST_STAT IN('A','C','F')
AND y.UN_PAY > 0
GROUP BY x.CUST_NO
HAVING SUM(y.UN_PAY) between : VAL1 AND VAL2;

SELECT x.CUST_NO, x.ADDR, x.Name,…
FROM CUST x
WHERE x.CUST_STAT IN('A','C','F')

AND EXISTS (SELECT 'X' FROM REQT y
WHERE x.CUST_NO = y.CUST_NO
AND y.UN_PAY > 0
GROUP BY x.CUST_NO
HAVING SUM(y.UN_PAY) between : VAL1
AND :VAL2)

   

  • 1:M JOIN의 부분 범위 유도2(Function)

1-1. 전체 범위 처리

1-2. 부분 범위 처리

SELECT x.CUST_NO, x.ADDR, x.Name,…
FROM CUST x, REQT y
WHERE x.CUST_NO = y.CUST_NO
AND x.CUST_STAT IN('A','C','F')
AND y.UN_PAY > 0
GROUP BY x.CUST_NO
HAVING SUM(y.UN_PAY) between : VAL1 AND VAL2;

CREA Function unpay_sum(v_custno in in

varchar2)

Return number is
sum_unpay number;
begin
. …
return sum_unpay;
end unpay_sum;


SELECT x.CUST_NO, x.ADDR, x.Name,…
FROM (select cust_no, addr, unpay_sum(cust_no) as un_pay,

from cust
whre cust_stat in('A','C','F')) where unpay_sum between : VAL1

AND VAL2)

   

  • QUERY 이원화를 이용한 부분범위 처리

전체 범위 처리

부분 범위 처리(Sort하는 범위가 줄어든다.)

SELECT 부서코드, 사번, min(직책), sum(본봉), sum(수당)… FROM 급여T x, 사원T y

WHERE x.사번 = y.사번
AND x.부서코드 LIKE '11%'
AND x.급여일 between '970101' and '971231'
GROUP BY 부서코드, X.사번

SELECT 부서코드 INTO :DEPTNO
FROM 부서테이블
WHERE 부서코드 LIKE '11%';

SELECT :DEPTNO, 사번, min(직책), sum(본봉), sum(수당)..
FROM x.사번 =y.사번
AND x.부서코드 =:DEPTNO
AND x.급여일 between '970101' and '971231'
GROUP BY X.사번

 

신고

'대용량 데이터베이스 솔루션' 카테고리의 다른 글

2-4강  (0) 2014.11.12
2-3강  (0) 2014.11.04
2-2강  (0) 2014.10.20
2-1강  (0) 2014.10.17
1-4강  (0) 2014.10.15
1-3강  (0) 2014.10.15
Posted by TM ~ing

 

  • 단순 명료한 설계

변경 전

변경 후

  

   

  

  1. 무엇을 어떻게 이용할 것인가?
  2. 정보의 단절을 어떻게 막을 것인가?
  3. 융통성과 통합성을 어떻게 유지할 것인가?
  4. 관계형 데이터베이스 특성을 어떻게 반영할 것인가?
  5. 단순 명료하면서도 원하는 수행속도를 보장받을 수 있는가?

       

  • 요소 기술 리더의 역할
  1. 이상적인 DBA: 모든 요소 기술에 대한 자문, 시스템 관리, 신기술 연구 전파
  2. 현실의 DBA: 시스템 개발 경험 부족, 낮은 경력, SP 출신 위주, 시스템 자원을 관리, 통제하는 정도의 역할

       

  • 개발자의 인식 전환

잘못된 인식

인식의 전환

  1. 절차형 처리 방식
  2. 설계는 대충, 프로그램에서 처리
  3. 모든 처리과정은 내가 작성
  4. 로직 구사를 잘하는 사람이 우수한 인재
  5. 데이터는 한건씩 처리해야만 한다.
  6. 데이터는 출력해서 보는 것이다.
  7. 100만건은 많은 데이터이다.
  8. 같은 데이터를 동시에 사용하면 경합이 생긴다.
  9. 경력이 많아지면, 관리자가 되야 한다.
  1. 집합 개념이 필요
  2. 잘못된 설계는 시스템에 큰 영향을 미침
  3. 요구만 잘하면 좋은 처리과정은 저절로 생성됨
  4. DBMS가 좋은 역할을 하도록 전략적인 FACTOR 부여
  5. 데이터는 여러 건을 동시에 처리할 수 있다.
  6. 가능한 온라인 프로그램이 되도록 한다.
  7. 1000만건 이하라면 많은 데이터가 아니다.
  8. 같은 데이터를 동시에 사용하면 효율이 더 좋아진다.
  9. 우수한 전문가는 훨씬 밝은 미래가 보장된다.

       

    • 쿼리 수행 과정
    1. SQL 실행
    2. SQL 해석
      1. COL$, OBJ$, IND$, TAB$, VIEW$ 참조
    3. 3. 실행 계획 작성
      1. COL$, OBJ$, IND$, TAB$, VIEW$ 참조
    4. 4.  실행
    5. 5. 결과

     

    • RDB는 왜 어려운가
    1. 실행 계획 제어가 어렵다.
    2. 좋은 실행계획을 수립할 수 있도록, 전략적인 FACTOR를 부여
    3. 비 절차형으로 기술
    4. 집합적 접근

     

     

    신고

    '대용량 데이터베이스 솔루션' 카테고리의 다른 글

    2-2강  (0) 2014.10.20
    2-1강  (0) 2014.10.17
    1-4강  (0) 2014.10.15
    1-3강  (0) 2014.10.15
    1-2강  (0) 2014.10.14
    1-1강  (0) 2014.10.07
    Posted by TM ~ing
    • 수행 속도 향상을 위한 필수 항목
      1. 병렬처리
      2. 멀티쓰레드, 멀티 서버
      3. 메모리의 최적활용
      4. 멀티블럭 처리
      5. 경합의 감소
      6. Locking의 해소
      7. 저장 프로시져의 활용
      8. 시스템 진단 툴의 활용
      9. 부분범위 처리
      10. 인덱스의 활용
      11. 액세스 효율의 향상
      12. 조인의 최적화
      13. 클러스터링
      14. 뷰의 최적 활용
      15. ARRAY PROCESSING
      16. I/O의 분산
      17. SORT의 튜닝
      18. 적절한 데이터 타입의 사용
      19. SQL의 활용
      20. 반 정규화

           

    • 프로젝트 성공 3 요소
      1. 관계형 데이터베이스에 맞는 단순 명료한 시스템 설계
      2. 시행착오를 줄이고 생산성을 향상시키며, 핵심 문제를 해결할 수 있는 리더
      3. 기존의 개념을 버리고 새로운 개념으로 무장된 개발 요원(집합적인 사고)

           

    • Outer Join의 잘못된 예

      SELECT B.custname, A.ordno

      FROM 주문 A, 고객 b (+)

      Where A.custno = B.custno

      And B.zip_code = :v1

      And A.orderdate like '201410%'

         

      -> 이상적인 실행 계획은 고객테이블을 드라이빙 테이블로 하여, zip_code 인덱스를 타고 JOIN을 하고 orderdate 조건으로 Filter를 하는 것이다.

         

      -> 그러나, 현실은 수많은 주문 테이블을 Full table Scan을 하여 201410한달 데이터를 뽑은 후, 조인을 하고 zip_code를 Filter 하는 방식으로 실행 계획이 풀린다. 이유는 바로 (+) Outer Join 때문이다. OUTER 싸인은 OUTER 싸인이 아닌쪽이 드라이빙 되게 만든다. 하지만 위에 디자인에서 보듯이 주문은 고객에게 모두 속해 있기 때문에 예상한 실행계획과 실제 실행계획의 결과는 같지만 수행 시간은 엄청난 차이를 가져온다.

     

    신고

    '대용량 데이터베이스 솔루션' 카테고리의 다른 글

    2-2강  (0) 2014.10.20
    2-1강  (0) 2014.10.17
    1-4강  (0) 2014.10.15
    1-3강  (0) 2014.10.15
    1-2강  (0) 2014.10.14
    1-1강  (0) 2014.10.07
    Posted by TM ~ing

     

    Q1) 다음 ERD 구조에서 아래 쿼리를 실행 시, Optimizer의 실행 방향은?

    DeptID

    DeptName

    UnitID

    StartDate

    ACC

    회계

    B

    2006-04-01

    ADV

    홍보

    C

    2009-06-01

    GEN

    총무

    B

    2007-03-01

    HRD

    인사

    B

    2006-05-01

    MKT

    영업

    C

    2006-05-01

    STG

    전략기획

    NULL

    2009-06-01

    SYS

    정보시스템

    A

    2007-01-01

       

    EmpID

    EmpName

    Gender

    HireDate

    RetireDate

    DeptID

    EMail

    Salary

    S0001

    홍길동

    M

    2006-01-01

    NULL

    SYS

    hong@itforum.co.kr

    8500

    S0002

    일지매

    M

    2006-01-12

    NULL

    GEN

    jimae@itforum.co.kr

    8200

    S0003

    강우동

    M

    2006-04-01

    NULL

    SYS

    hodong@itforum.co.kr

    6500

    S0004

    김삼순

    F

    2006-08-01

    NULL

    MKT

    samsoon@itforum.co.kr

    7000

    S0005

    오삼식

    M

    2007-01-01

    2009-01-31

    MKT

    samsik@itforum.co.kr

    6400

    S0006

    김치국

    M

    2007-03-01

    NULL

    HRD

    chikook@itforum.co.kr

    6000

    S0007

    안경태

    M

    2007-05-01

    NULL

    ACC

    ahn@itforum.co.kr

    6000

    S0008

    박여사

    F

    2007-08-01

    2007-09-30

    HRD

    yeosa@itforum.co.kr

    6300

    S0009

    최사모

    F

    2007-10-01

    NULL

    SYS

    samo@itforum.co.kr

    5800

    S0010

    정효리

    F

    2008-01-01

    NULL

    MKT

    hyori@itforum.co.kr

    5000

    S0011

    오감자

    M

    2008-02-01

    NULL

    SYS

    gamja@itforum.co.kr

    4700

    S0012

    최일국

    M

    2008-02-01

    NULL

    GEN

    ilkook@itforum.co.kr

    6500

    S0013

    한국인

    M

    2008-04-01

    NULL

    SYS

    hankook@itforum.co.kr

    4500

    S0014

    이최고

    M

    2008-04-01

    NULL

    MKT

    one@itforum.co.kr

    5000

    S0015

    박치기

    M

    2008-06-01

    2009-05-31

    MKT

    chichi@itforum.co.kr

    4700

    S0016

    한사랑

    F

    2008-06-01

    NULL

    HRD

    love@itforum.co.kr

    7200

    S0017

    나도야

    M

    2008-12-01

    NULL

    ACC

    yaya@itforum.co.kr

    4000

    S0018

    이리와

    M

    2009-01-01

    2009-06-30

    HRD

    comeon@itforum.co.kr

    5300

    S0019

    정주고

    M

    2009-01-01

    NULL

    SYS

    give@itforum.co.kr

    6000

    S0020

    고소해

    F

    2009-04-01

    NULL

    STG

    haha@itforum.co.kr

    5000

       

    쿼리) select a.EmpName, a.Salary, b.DeptName

    from employee a inner join department b

    on(a.DeptID=b.DeptID)

       

    정답)

    ※ 옵티마이저는 연결 조건에 인덱스 없는 쪽의 테이블을 드라이빙 테이블로 선택하고, 연결 조건에 인덱스가 있는 쪽의 테이블을 내측 테이블로 한다.

       

    Q2) 조인에 대한 부하 때문에, 조인을 없애고 하나의 테이블로 만드는 것이 타당한가?

    가정: Department는 100개, Employee는 10만개의 Row가 존재하며, Row당 크기는 Department: 50Byte, Employee: 80Byte 이다.

       A) 조인을 할 경우, 전체 데이터를 보기 위한 IO 크기는 Employee Full Scan(80Byte * 10만) + Department Full     Scan(50Byte*100) = 8,005,000 Byte가 된다. 하지만 한 개의 테이블로 만들고, 전체 데이터를 보기 위한 IO 크기는     Employee Full Scan((80Byte + 50Byte) * 10만) = 13,000,000 Byte가 된다.

    Performance에 가장 중요한 IO 크기가 차이만 해도 엄청난 크기가 되며, 행수가 많아 질수록 그 차이는 더욱 커질 것이다. 조인을 두려워 하지 말라.   

       

    정규화 정리

    1. 제 1정규형(1NF)

    • 개별 테이블에서 반복되는 그룹을 제거한다.
    • 관련 데이터의 각 집합에 대해 별도의 테이블을 만든다.

         

    2. 제 2 정규형(2NF)

    • 키가 아닌 컬럼은 기본키 일부분에 의존적이어서는 안된다.

         

    3. 제 3 정규형(3NF)

    • 키가 아닌 컬럼은 기본키에만 종속 되어야 한다.(키가 아닌 컬럼끼리 종속을 만들면 안된다.)
    • 이행 종속이 있으면 안됨. 단, 키가 아닌 어느 속성이 키의 일부를 결정지을 수 있다면 3NF 만족

         

    4. BCNF

    • 결정자는 반드시 키어야 하며 키가 아닌 결정자는 있을 수 없다.(BCNF는 3NF를 만족하나 3NF가 반드시 BCNF는 아님)

       

    정규화 과정

    학교

    학번

    학생이름

    학년

    학과

    수강과목

    학점

    교수

    개설학과

    조건 : 전공은 하나. 교양 및 다른과 수업 수강 가능

       

    1NF 정규화

    * 1NF : 각 속성은 반드시 원자값을 가지므로 1NF 만족

       

    2NF 정규화

    Key는 {학번, 수강과목) : 이 두가지 속성으로 하나의 레코드를 결정할 수 있음

       

    학번->이름, 학년, 학과

    과목->학점, 교수, 개설학과

    (교수->개설학과)

       

    학번은 이름, 학년, 학과를 결정

    과목은 학점, 교수, 개설학과를 결정

       

    따라서 Key의 일부 속성에 의해 결정되는 속성들이 존재하므로 2NF 불만족

       

    => Key에만 종속되도록 분리

       

    학생(학번, 이름, 학년, 학과)

    학번

    이름

    학년

    학과

       

    수강과목(과목, 학점, 교수, 개설학과)

    과목

    학점

    교수

    개설학과

       

    수강(학번,과목) : 이 테이블은 테이블 분리로 인한 두 테이블간의 관계를 표현하기 위해 생성됨 (N:M 관계)

    학번

    과목

       

    * 이제 모든 속성들이 Key에만 종속됨. 2NF 만족

       

    3NF 정규화

    수강과목(과목, 학점, 교수, 개설학과) 에서 교수가 개설학과를 결정지음 (이행 종속)

    (교수는 개설학과에 소속되어 있으므로)

       

    => 이행종속을 제거

       

    수강과목(과목, 학점, 교수)

    과목

    학점

    교수

       

    교수(교수, 개설학과)

    교수

    개설학과

       

    모든 테이블을 모으면,

    학생(학번, 이름, 학년, 학과)

    학번

    이름

    학년

    학과

       

    수강과목(과목, 학점, 교수)

    과목

    학점

    교수

       

    교수(교수, 개설학과)

    교수

    개설학과

       

    수강(학번,과목)

    학번

    과목

       

    * 이행 종속이 없으므로 3NF 만족

       

    1NF에서 곧바로 BCNF 정규화

    모든 결정자는 Key이어야 함.

       

    학번->이름, 학년, 학과

    과목->학점, 교수

    교수->개설학과

       

    따라서 결정자를 기준으로 테이블 분리

       

    학생(학번, 이름, 학년, 학과)

    수강과목(과목, 학점, 교수)

    교수(교수, 개설학과)

    수강(학번,과목)

       

    이 예는 3NF이면서 BCNF를 만족

       

    원본 위치 <http://brown.ezphp.net/125>

      

       

    신고

    '대용량 데이터베이스 솔루션' 카테고리의 다른 글

    2-2강  (0) 2014.10.20
    2-1강  (0) 2014.10.17
    1-4강  (0) 2014.10.15
    1-3강  (0) 2014.10.15
    1-2강  (0) 2014.10.14
    1-1강  (0) 2014.10.07
    Posted by TM ~ing