64
3
sum 함수에서, 레코드 안에서 칼럼끼리 합하는데 하나가 Null이면 Null이 나온다. 근데 각 레코드의 합 결과끼리 합할테는 결과가 Null이 나온 레코드를 무시하고 합한다.
1 - (20 + 70)으로 90이다.
2 - 첫째 둘째 레코드는 무시되고 세번째 레코드의 결과인 140만 반환된다.
3 - 첫째 둘째 레코드가 무시되고 세번째의 합인 90만 반환된다.
4 - 90 + 20 으로 110이다.
65
4
1 - sort order by
2 - sort unique
3 - sort aggregate, sort group by
4 - window 가 없다.
66
2
1 - sort order by
2 - union all은 정렬을 안 한다.
3 - window sort
4 - sort merge join
67
4
union all을 쓰려면 위 아래에 중복이 없어야 union이랑 결과가 똑같아진다.
안 그러면 중간에 중복 생긴다.
unique index라는 얘기도 없고, 중복 없는 걸 보장할 수 있는 건 pk인 empno 뿐인데 이를 포함하는 건 4번 뿐이다.
68
1
1 - 정렬해서 top100을 뽑는 쿼리이다. 밖에 있어야 한다. 안에 있으면 정렬 이전에 위에서 100개를 뽑아버린다.
2 - 그렇게 인덱스를 변경하면 sort order 가 생략될 수도 있다.
3 - 그렇게 하면 소트 대상의 범위가 크게 줄어들 수도 있다.
4 - 작성자명으로 정렬을 안 하면 기존 인덱스로도 소트 연산이 생략된다.
69
4
4 - window 함수에서 rank를 썼기 때문에 topN 알고리즘이 작동해서 sort 부하가 적다.
70
3
/*+ append */ 힌트를 써서 direct path insert를 썼기 때문에 테이블 전체에 락이 걸린다.
71
1
1 - 테이블 전체에 락 걸린다.
72
2 - nologging은 insert 때만 가능하다.
73
3
B는 대상 레코드를 한번만 본다.
74
3
3 - nologging은 insert에서 동작한다.
75
2
1 - 디스크 장애 시 해당 파티션만 영향을 받으므로 데이터의 훼손 가능성이 감소하고 가용성이 향상된다.
2 - 인덱스 파티션을 나누면 오히려 저장공간이 늘어난다.
3 - full scan 안 해도 된다.
4 - 서로 다른 파티션에 접근한다면 동시성이 증가한다.
76
3
3 - 변수로 해도 동적 프루닝된다.
77
1, 2
1 - 정적 프루닝이 일어나서 1월 2월 3월 파티션을 각각 볼 것이다.
2 - 1번 쿼리를 자체적으로 프루닝한 것이다.
3 - 주문일자를 가공해서 파티션 이용 못한다.
4 - 주문일자가 아니라 일자를 사용하고 있다. 1월 1일부터 3월 31일이 89일이 있는데 그만큼 파티션에 각각 접근할 것이다.
78
1
prefixed 파티션 인덱스는 파티션 키가 인덱스 선두 칼럼인 경우를 말한다.
거래일시가 인덱스 선두 칼럼인 건 1번 밖에 없다.
79
1, 4
거래_idx1은 global prefixed, 거래_idx2는 local nonprefixed이다.
80
1
사람들 사용 안 할 때 배치를 돌리는 건 좋은데, 배치를 집중적으로 수행하면 경합 일어날 수도 있다.
81
4
update 할 때는 무조건 로그를 남긴다.
82
3
outer table은 고객, Inner table은 주문이다.
주문 테이블은 파티셔닝이 되어 있기 때문에, outer 테이블을 inner table 기준으로 파티셔닝하려면
pq_distribute(o partition none) 힌트를 사용해야 한다.
