holog

이관 쿼리를 작성하던 중 시스템컬럼(감사컬럼)에 사용되는 등록자번호가 tobe 기준에 맞춰 변환한 후 이관해야 하는 경우가 있었다. 따라서 이관 대상인 A 테이블의 등록자번호, 변경자번호, 삭제자번호 등을 tobe에 맞게 신규 채번되어있는 매핑테이블 B와 조인하여 B의 테이블의 신규 번호를 가져와야 하는 상황이었다. 단순히 A 테이블의 등록자번호, 변경자번호, 삭제자번호 3개를 B테이블과 조인해 보았다. A 테이블의 데이터 정합성을 위해 LEFT JOIN 이었으며, 매핑테이블 B에는 조인 대상 컬럼에 INDEX가 생성해 놓은 상태였다. 먼저 조인을 해 보았다. SELECT ... FROM TABLE_A asis LEFT JOIN TABLE_B tobe ON A.COL = B.COL 결과 : id|sele..

1. 모든 서브쿼리는 메인 쿼리보다 먼저 실행된다? X : Correlated subquery의 경우에는 메인 쿼리가 먼저 실행된다. 2. 스칼라(Scalar) 서브쿼리는 한번에 리턴 할 수 있는 최대 row 수가 1건이다? O : 스칼라 서브쿼리는 최대 1건 리턴이며, 없는 경우에는 null을 리턴한다. group by절 제외하고 다 가능! NESTED SUBQUERY SELECT A, B FROM TABLE WHERE C = (SELECT C FROM TABLE2 WHERE A = 1) 여기서의 서브쿼리임! 메인보다 먼저 실행됨! Correlated SUBQUERY 메인보다 나중에 실행됨. EXISTS네!! Exists는 메인을 먼저 읽고 그 row를 가져와야 비교가 가능하니까! Scalar SUBQ..

사전문제 1. Cartesian product는 조인하려는 두 테이블에 대해 where절이 없거나 조인 조건 없이 조인을 수행할 때 발생한다? O : 조인하려는 테이블 사이에 Where 절이 없거나 조인 조건 없이 조인을 수행할 때 Cartesian product가 발생되면 의도적인 Cartesian product가 아니라면 항상 정확한 조인 조건을 사용해야 한다. 2. Cartesian product는 어떤경우에도 사용해선 안되나? X : Cartesian product는 데이터 복제의 개념을 이용한 반복된 처리로 인해 불리적인 I/O를 상당 부분 개선시킬 수 있으므로 경우에 따라 사용하는 것이 좋다. Cartesian product? 1. where 절이 없는 조인 수행할 경우 2. 조인을 위한 조건..

드디어.. 아는 문제가 나온거 같다.. 한쪽 table만 row 수가 거의 500배가 차이난다! 이러면 Merge Join은 Sort를 해야하는데.. 한쪽 Sort 까지 대기해버리게 되어 손해다! Hash_JOIN으로 변경하는게 맞을 듯 하다. Driving 테이블은 건수가 적은 A로, 그리고 조인 방식은 Hash로 하기 위해 /*+ ORDERED USE_HASH(A B) */로 힌트를 변경해야 겠다.

사전문제 1. 소트머지(Sort Merge) 조인은 조인 순서 제어가 중요한 튜닝 포인트 중 하나인가? X : Sort Merge 조인에서는 Driving Table이 없이 각 테이블로부터 동시에 데이터를 처리하기 때문에 조인순서 상관없다! 2. 해시(Hash) 조인은 Driving Table이 없다. X : 해시(Hash) 조인은 Driving Table로부터 생성한 Hash Table의 데이터와 Inner Table 데이터의 해시 값을 조인하는 방식으로, Driving Table이 있다. 1. Sort/Merge Join 1. 연결 고리에 인덱스가 전혀 없는 경우 2. 대용량의 자료를 조인해야 함으로써 인덱스 사용에 따른 랜덤 엑세세의 오버헤드가 많은 경우! - 조인 되는 순서! 1. Driving ..

흠.. C.COURSE_CODE = 14라는 부분이 있으니 C가 DRIVING 테이블이 되고나서 B, A순으로 가야 회수가 가장 적지 않을까? 답을 보니 또 틀렸다.. 기본적으로 A가 과정이니 가장 적을것이고.. B, C순서대로 데이터가 많을 테니 A,B,C 순서로 조인하는데.. 대신 A.COURSE_CODE = C.COURSE_CODE가 아니라.. A. = B. AND B. = C. 으로 하란다.. 또한 C.COURSE_CODE = 14; 부분도 A.COURSE_CODE = 14;로 바꾸면 된단다.. 그림의 순서대로 조인 순서를 확인할 수 있다.

1. 연결고리 칼럼에 인덱스가 전혀 없는 경우에는 Nested Loops 조인은 좋은 성능을 내는가? X : 연결고리 컬럼에 인덱스가 전혀 없으면 좋은 성능 불가능 2. Nested Loops 조인에서는 조인하는 테이블로부터 데이터를 동시에 각각 읽어 들이는가? X : 드라이빙(Driving) 테이블로부터 데이터를 읽어 들일 때마다 드리븐(Driven) 테이블에 조인을 하여 데이터를 읽는다. NESTED LOOPS JOIN은 두 테이블의 조인 횟수를 최소화 하는 것이 가장 큰 영향이 있음! /*+ ORDERED USE_NL(a b) */

이건 진짜 몰랐다. 바로 답안을 확인했다. WHERE 절에 기술된 조건에 의해 PK가 인덱스로 사용되고 있는데 처리한 데이터가 전체 데이터 중에서 15%를 초과해서 인덱스를 사용하는 것 자체가 속도가 저하된다 한다. .. 15%를 초과하는지 어떻게 알았던 걸까.. 그냥 모를수밖에 없는 거 였는듯.. ..바로 정답을 봤다.. GROUP BY COURSE_CODE, YEAR를 추가하는 서브쿼리를 넣었다. /*+ NO_USE_HASH_AGGREGATION */.. aggreation시 해싱대신 소팅을 하게끔 할려면 쓴다고 한다.. 아직 잘 모르겠다. 답은 다음과 같았다. SELECT /*+ FULL(EC_APPLY) */ COURSE_CODE, YEAR, SUM(DEPOSIT_AMOUNT) DEPOSIT_AM..

사전 퀴즈 1. 모든 쿼리문은 인덱스를 사용해야만 빠른 조회가 가능한가? X : 많은 양의 데이터를 가지는 테이블이면 전체의 15%이하를 처리할때만 인덱스가 의미있음 2. 인덱스로 구성된 컬럼에 변형을 가했을 때에도 해당 인덱스를 사용할 수 있나? X : 인덱스로 구성된 컬럼에 변형을 가하게 되면 옵테마이저는 인덱스를 사용 못하게 된다. 인덱스 사용이 불가능한 경우 1. NOT 연산자 사용 2. IS NULL, IS NOT NULL 사용 3. 옵티마이저의 취사 선택 4. External suppresing 5. Internal suppressing 1. NOT 연산자 사용 WHERE A != 1; WHERE A 1; 이면 A가 1이 아닐때, 즉 1이 아닌 모든 데이터를 찾게 되므로 15%이상의 데이터를 ..

하.. 수업을 듣고 문제를 봤는데 항상 모르겠다.. 그냥 봐서는.. COURSE_CODE < 1000 이게 EQUAL 비교가 아니라서 인덱스매칭률이 떨어져서 그런거 아닌가 싶은데.. 어떻게 해결해야 하는지 잘 모르겠네.. 정답은.. 인덱스의 첫 번째 칼럼이 COURSE_CODE에 대한 조건때문에 두 번째 칼럼인 YEAR에 대한 = 조건이 체크 조건으로 사용된다는 거였다.. 흠... 그럼 어떻게 해결하지? 문제다.. 뭔가 조인이 하나 더 생겼다.. EC_COURSE 테이블로 조인을 진행한 것 같은데.. 흠.. 이건 EC_COURSE가 어떻게 생겨먹은지 알아야 푸는 것 아닌가.. Execution Plan만 봐서는 pk가 UNIQUE 이니.. 뭔가 조인이 되는 것 같은데.. 맥락상 COURSE_CODE로 조..