현대카드 ZERO를 신청했다.
돈관리에 있어 와이프와 합의한 기본내용은 신용카드를 모두 없에고 체크카드 만을 쓰자. 였다.
모든 일이 그렇듯 이것도 계획한 대로 잘 되지는 않았다.
일단 둘 모두 체크카드에 매달 넣어두는 금액이 적었다.
가끔 월말에 결산을 하면서 넣어두는 돈을 조정하기는 했지만 그래도 부족한 경우가 많았다.
그때마다 신용카드를 쓰다보니 해지되지 않고 남아있는 신용카드가 몇 장 있어 이번에 결산을 하면서 큰맘먹고 모두 해지 신청을 했다.
그러다보니 해외구매를 할 때 사용하던 신용카드는 해지대상이었고 평소에 종종 사용하던 현대M카드는 국내 전용이어서 새로운 카드를 신청할 필요가 생겼다.
현대카드 홈페이지에 들어가 신용카드를 주욱 둘러보니, 일단 대부분의 신용카드가 연회비가 매우 비쌌다.
내가 꼼꼼하지 못해 신용카드 혜택을 잘 못챙기기 때문에 일단 연회비가 비싼 카드는 모두 제외하다보니 결국 남는건 ZERO 카드였다.
ZERO 카드의 장점은 일단 전월실적조건 ZERO.
대부분의 카드가 전월실적이 30~40만원이 되야 혜택이 유지되는 조건이라 전월실적조건이 없는 부분이 마음에 들었다.
물론 연회비가 낮고(해외구매 가능할 경우 만원), 전월실적조건이 없기에 혜택도 다른 카드에 비해 낮은 듯 하다.
하지만 위에서 얘기했듯이 난 신용카드 혜택을 꼼꼼히 챙기지 못하는 사람이다.
그리고 신용카드 사용은 최대한 자제하려고 한다.
그러기에 ZERO 카드가 나에게는 딱 맞게 느껴졌다.
하나 더, 신용카드 사용금액을 선결제 할 경우 추가 할인이 있다고 하니 잘 활용해야겠다.
음... 교통카드 기능이 있는지는 잘 모르겠다.
나중에 전화로 확인해보자.
온라인으로 신청했는데 신청단계 마지막에 리볼빙 서비스를 신청하는 단계가 있었던 것 같기도 하고 아닌것 같기도 하고... 애매하게 처리가 되어 있었다.
현대카드는 홈페이지나 온라인도 깔끔하게 잘 관리하는 듯한데 리볼빙 신청이 애매하게 되어 있었던 부분은 고의적인 것 같다.
잊어버리지 않기 위해 ZERO 카드 혜택을 간단히 기록해 둔다.
횟수제한, 전월실적조건, 할인한도 ZERO
모든 가맹점 이용금액의 0.7% 할인 - 1000원을 쓰면 7원 할인이다-_-; 10만원을 쓰면 700월 할인. 이건 뭐-_-;
생활필수 영역 이용금액의 0.5% 추가할인
이용일 5일 이내 선결제 시 0.3% 추가할인
모든 가맹점에서 2~3개월 할부 결제 시 무이자
카드 이름처럼 심플한 혜택-_-;
2012년 10월 30일 화요일
일요일, 일주일을 정리하는 방법
일요일에 일주일을 정리하는 방법에 대해 글을 쓰려고 했는데 참신한 아이디어가 떠오르지 않았다.
몇일을 미루다가 결국 그냥 써보기로 했다.
생각나는 대로, 생각의 흐름을 적어봐야겠다.
매일 하루를 반성하는 시간이 필요하다고 생각한다.
한 10분이라도 오늘의 나는 하루에 충실했는가를 돌아봐야 한다.
또한, 오늘 해야 했던 일들을 왜 못했는가, 오늘 못한 일들을 언제 해야 하는가도 매일 점검해야 한다.
이렇게 하루의 정리가 필요하듯이 일주일의 정리도 필요하다.
물론 일주일 뿐만 아니라, 한달, 분기, 반기, 그리고 일년의 반성도 필요할 것이다.
이런 일련의 반성의 토대가 되는 것이 하루, 그리고 일주일의 반성이다.
자, 이제 생각해보자. 일주일의 반성에는 어떤 항목이 포함되어야 할까?
일주일의 느낌을 자유롭게 적는 것도 좋겠지만, 일정한 틀이 필요하다고 생각된다.
업무일지를 쓰듯, 특정한 포멧이 필요하다.
예전에 자신을 표현하는 지표를 정해놓고 매달 점수를 매겨 스스로를 평가하는 것도 보았지만 현재 나에게 적용하기는 어려울 듯 하다.
음...
생각나는 대로 적어보자면,
월요일 부터 일요일까지 매일에 점수를 매기자.
각 요일마다 해야 할 일(일감)들이 있을테니 일감을 계획할때 각 일마다 10점 만점의 점수를 부여하고 모든 일들의 개수로 평균을 내자.
모든 일감이 10점이면 평균도 10점일 것이다.
이런 방식으로 점수를 매기려면 일감을 계획할 때 구체적으로 기록해야 한다.
그리고 생각만이라도 이런 기준을 만족하면 10점, 이런 부분이 부족할 경우 9점, 이런식으로 차등을 둘 수 있어야 할 것 같다.
괜찮은 방법 같다.
일을 계획할때 to-do list에 일의 제목만을 적는 것이 아니라 한번 더 생각해서 세분화하여 적고 점수도 생각해보자.
그리고 하루에 할 일을 너무 많이 계획하지 말자.
계획한 그날 해야 할 일을 모두 처리하지 못하면 평균값에서 처리하지 못한 일감 하나 당 1점씩 차감하자.
계획을 했으니 산으로 가더라도 일단 실행으로 옮겨보자.
오늘 반성 후 내일 계획부터 시작이다.
ps. 고민만 하지 말고 일단 글을 쓰자.
덧. 감점요일
그날 할일을 못하면 평균에서 1점 감점
일기를 쓰지 않으면 평균에서 1점 감점
내일 계획을 세우지 않으면 평균에서 1점 감점
시간이 어긋나면 개별 점수에서 1점 감점
몇일을 미루다가 결국 그냥 써보기로 했다.
생각나는 대로, 생각의 흐름을 적어봐야겠다.
매일 하루를 반성하는 시간이 필요하다고 생각한다.
한 10분이라도 오늘의 나는 하루에 충실했는가를 돌아봐야 한다.
또한, 오늘 해야 했던 일들을 왜 못했는가, 오늘 못한 일들을 언제 해야 하는가도 매일 점검해야 한다.
이렇게 하루의 정리가 필요하듯이 일주일의 정리도 필요하다.
물론 일주일 뿐만 아니라, 한달, 분기, 반기, 그리고 일년의 반성도 필요할 것이다.
이런 일련의 반성의 토대가 되는 것이 하루, 그리고 일주일의 반성이다.
자, 이제 생각해보자. 일주일의 반성에는 어떤 항목이 포함되어야 할까?
일주일의 느낌을 자유롭게 적는 것도 좋겠지만, 일정한 틀이 필요하다고 생각된다.
업무일지를 쓰듯, 특정한 포멧이 필요하다.
예전에 자신을 표현하는 지표를 정해놓고 매달 점수를 매겨 스스로를 평가하는 것도 보았지만 현재 나에게 적용하기는 어려울 듯 하다.
음...
생각나는 대로 적어보자면,
월요일 부터 일요일까지 매일에 점수를 매기자.
각 요일마다 해야 할 일(일감)들이 있을테니 일감을 계획할때 각 일마다 10점 만점의 점수를 부여하고 모든 일들의 개수로 평균을 내자.
모든 일감이 10점이면 평균도 10점일 것이다.
이런 방식으로 점수를 매기려면 일감을 계획할 때 구체적으로 기록해야 한다.
그리고 생각만이라도 이런 기준을 만족하면 10점, 이런 부분이 부족할 경우 9점, 이런식으로 차등을 둘 수 있어야 할 것 같다.
괜찮은 방법 같다.
일을 계획할때 to-do list에 일의 제목만을 적는 것이 아니라 한번 더 생각해서 세분화하여 적고 점수도 생각해보자.
그리고 하루에 할 일을 너무 많이 계획하지 말자.
계획한 그날 해야 할 일을 모두 처리하지 못하면 평균값에서 처리하지 못한 일감 하나 당 1점씩 차감하자.
계획을 했으니 산으로 가더라도 일단 실행으로 옮겨보자.
오늘 반성 후 내일 계획부터 시작이다.
ps. 고민만 하지 말고 일단 글을 쓰자.
덧. 감점요일
그날 할일을 못하면 평균에서 1점 감점
일기를 쓰지 않으면 평균에서 1점 감점
내일 계획을 세우지 않으면 평균에서 1점 감점
시간이 어긋나면 개별 점수에서 1점 감점
2012년 10월 29일 월요일
20121029 운동
계획한 대로 운동!
운동하러 가기 전에 약간 미적거리다가 항상 9시 반이 되야 출발하게된다.
오늘도 9시 반에 출발했고 결과적으로 시간이 매우 빠듯했다.
9시 정각에 출발할 수 있도록 하자!
스트레칭
- 목
- 팔 스트레칭
- 다리
- 반달 자세
- 다리 자세
- 물고기 자세
- 코브라 자세
- 고양이 자세
- 낙타 자세
맨손운동
- 복근운동 상체들기 - 다리들기 각 10회 4 set
- 브릿지 45초, 45초, 45초
- 팔굽혀펴기 6회
복근운동 횟수가 조금 늘었다. 앞으로 한동안 4set을 유지하고 횟수를 점차 늘리자.
팔굽혀펴기는 브릿지 다음에 해서 그런지 겨우 여섯 번 했는데 너무 힘들다-_-;
트레드밀
- 6 - 5분
- 8 - 10분
- 5 - 5분
달리기 강도는 이쁘게 올라가고 있는 것 같다. 시간을 더 늘리고 한동안 8 속도를 유지하자.
트레드밀 후 다리 스트레칭
근력운동
sap 사이트 보고 공부 좀 더하자.
- 벽 밀기
- 서서 몸통 굽히기
근력운동
얼마나 근력이 약하면 내 팔로 내 몸을 이렇게 지탱하게 힘들까-_-;
대체 할만한 운동을 찾아봐야겠다.
벤치 프레스는 지난 번 운동과 동일. set를 늘리려고 했는데 시간이 너무 촉박했다.
다음 운동은 20121101
- 딥 작게 5회 2set
- 계속 어색한 자세 ㅠㅠ
- 벤치 프레스 - empty bar 10회 3set
얼마나 근력이 약하면 내 팔로 내 몸을 이렇게 지탱하게 힘들까-_-;
대체 할만한 운동을 찾아봐야겠다.
벤치 프레스는 지난 번 운동과 동일. set를 늘리려고 했는데 시간이 너무 촉박했다.
다음 운동은 20121101
맨손운동
- 복근운동 상체들기 - 다리들기 각 11회 4 set
- 브릿지 45초, 45초, 45초
- 팔굽혀펴기 8회
트레드밀
- 6 - 5분
- 8 - 15분
- 5 - 5분
근력운동
- 딥 작게 5회 2set
- 벤치 프레스 - empty bar 10회 4set
20121101에는 딥 어시스트 머신을 이용해봐야겠다.
sap 사이트 보고 공부 좀 더하자.
ps. 운동카드 반납 완료.
실행계획 데이터베이스 튜닝 - 실행계획분석 13
103
결합 컬럼 인덱스를 구성하는 컬럼의 순서
1순위 - 점 조건으로 사용된 컬럼
2순위 - 랜덤 엑세스 감소
3순위 - 정렬 제거
4순위 - 단일 컬럼의 분포도
WHERE 조건에 사용할 수 있는 연산자는 점 조건과 선분 조건으로 나뉜다.
SQL에서 최적의 인덱스는 처리 범위를 최소로 감소시키는 인덱스.
분포도가 좋다는 의미는 각 데이터가 중복되지 않고 고르게 퍼져 있는 것.
컬럼의 분포도가 좋으려면 동일 연산자(=)와 같은 점 조건으로 조회해야 한다.
따라서 선분 조건보다 점 조건이 있는 컬럼이 앞에 있어야만 처리 범위를 감소시킬 수 있다.
점 조건+선분 조건으로 인덱스를 생성하면 엑세스한 데이터에 대해 버려지는 데이터는 없다.
선분 조건 + 점 조건으로 인덱스를 생성하면 인덱스에 엑세스한 후 버려지는 데이터가 생긴다.
점 조건 + 점 조건으로 인덱스를 생성한다면 두 조건에 의해 처리 범위는 동시에 감소한다.
처리 범위만을 본다면 점 조건들의 순서가 변경되어도 처리 범위는 변하지 않게 된다.
선분 조건 + 선분 조건 인덱스를 생성하면 앞에 있는 선분 조건에 의해서만 처리 범위가 감소한다.
-----------------
결론
점 조건 + 점 조건 : 두 개의 점 조건에 의해 처리 범위 감소
선분 조건 + 선분 조건 : 앞의 선분 조건에 의해 처리 범위 감소
점 조건 + 선분 조건 두 개의 조건에 의해 처리 범위 감소
선분 조건 + 점 조건 : 앞의 선분 조건에 의해 처리 범위 감소
WHERE 절에 많은 조건이 있다면 점 조건들을 앞에 위치시키고 선분 조건을 뒤에 위치시켜 인덱스를 생성해야 처리 범위를 최소화할 수 있다.
* 결합 컬럼 인덱스의 처리 범위 최소화 규칙
----
두 개의 선분 조건은 연산자에 의해 추출되는 데이터의 양을 비교하여 연산자에 의한 분포도가 더 좋은 걸럼이 앞에 있어야 처리 범위를 더 감소시킬 수 있다.
----
인덱스를 이용하여 랜덤 엑세스를 제거하기 위해서는 랜덤 엑세스가 왜 발생하는지, 어떤 종류의 랜덤 엑세스가 있는지 이해해야 한다.
랜덤 엑세스의 종류는 3가지
1. 확인 랜덤 엑세스 - WHERE 조건을 인덱스에서 확인할 수 없을 경우 테이블에 엑세스해서 확인하는 랜덤 엑세스
2. 추출 랜덤 엑세스 - SELECT 절의 컬럼 값을 추출하기 위해 테이블에 엑세스하는 랜덤 엑세스
3. 정렬 랜덤 엑세스 - 정렬을 수행하는 ORDER BY 및 GROUP BY를 수행하기 위해 테이블에 엑세스하는 랜덤 엑세스
확인, 추출, 정렬 랜덤 엑세스의 제거는 처리 범위의 감소 다음으로 SQL의 성능에 있어 매우 중요하다.
----
결합 인덱스를 생성할 경우 단일 컬럼의 분포도
컬럼의 분포도가 아무리 좋아도 연산자를 선분 조건으로 사용하야 한다면 분포도는 나빠진다.
분포도가 나쁜 컬럼이라도 점 조건을 사용하여 여러 컬럼을 결합한다면 분포도가 좋아질 수 있다.
점 조건들, 선분 조건들의 순서를 정하기 위한 우선 순위를 선정할 경우에 단일 컬럼의 분포도를 고려해야 한다.
선분 조건에서는 단일 컬럼 자체의 분포도가 아니라 단일 컬럼의 분포도와 연산자에 의해 추출되는 데이터의 양을 업무에 적용하여 비교.
점 조건에는 해당 컬럼의 분포도를 그대로 적용.
----
데이블에 엑세스하는 대부분의 SQL을 함께 고려하여 최적의 인덱스를 선정
결합 컬럼 인덱스를 구성하는 컬럼의 순서
1순위 - 점 조건으로 사용된 컬럼
2순위 - 랜덤 엑세스 감소
3순위 - 정렬 제거
4순위 - 단일 컬럼의 분포도
WHERE 조건에 사용할 수 있는 연산자는 점 조건과 선분 조건으로 나뉜다.
SQL에서 최적의 인덱스는 처리 범위를 최소로 감소시키는 인덱스.
분포도가 좋다는 의미는 각 데이터가 중복되지 않고 고르게 퍼져 있는 것.
컬럼의 분포도가 좋으려면 동일 연산자(=)와 같은 점 조건으로 조회해야 한다.
따라서 선분 조건보다 점 조건이 있는 컬럼이 앞에 있어야만 처리 범위를 감소시킬 수 있다.
점 조건+선분 조건으로 인덱스를 생성하면 엑세스한 데이터에 대해 버려지는 데이터는 없다.
선분 조건 + 점 조건으로 인덱스를 생성하면 인덱스에 엑세스한 후 버려지는 데이터가 생긴다.
점 조건 + 점 조건으로 인덱스를 생성한다면 두 조건에 의해 처리 범위는 동시에 감소한다.
처리 범위만을 본다면 점 조건들의 순서가 변경되어도 처리 범위는 변하지 않게 된다.
선분 조건 + 선분 조건 인덱스를 생성하면 앞에 있는 선분 조건에 의해서만 처리 범위가 감소한다.
-----------------
결론
점 조건 + 점 조건 : 두 개의 점 조건에 의해 처리 범위 감소
선분 조건 + 선분 조건 : 앞의 선분 조건에 의해 처리 범위 감소
점 조건 + 선분 조건 두 개의 조건에 의해 처리 범위 감소
선분 조건 + 점 조건 : 앞의 선분 조건에 의해 처리 범위 감소
WHERE 절에 많은 조건이 있다면 점 조건들을 앞에 위치시키고 선분 조건을 뒤에 위치시켜 인덱스를 생성해야 처리 범위를 최소화할 수 있다.
* 결합 컬럼 인덱스의 처리 범위 최소화 규칙
----
두 개의 선분 조건은 연산자에 의해 추출되는 데이터의 양을 비교하여 연산자에 의한 분포도가 더 좋은 걸럼이 앞에 있어야 처리 범위를 더 감소시킬 수 있다.
----
인덱스를 이용하여 랜덤 엑세스를 제거하기 위해서는 랜덤 엑세스가 왜 발생하는지, 어떤 종류의 랜덤 엑세스가 있는지 이해해야 한다.
랜덤 엑세스의 종류는 3가지
1. 확인 랜덤 엑세스 - WHERE 조건을 인덱스에서 확인할 수 없을 경우 테이블에 엑세스해서 확인하는 랜덤 엑세스
2. 추출 랜덤 엑세스 - SELECT 절의 컬럼 값을 추출하기 위해 테이블에 엑세스하는 랜덤 엑세스
3. 정렬 랜덤 엑세스 - 정렬을 수행하는 ORDER BY 및 GROUP BY를 수행하기 위해 테이블에 엑세스하는 랜덤 엑세스
확인, 추출, 정렬 랜덤 엑세스의 제거는 처리 범위의 감소 다음으로 SQL의 성능에 있어 매우 중요하다.
----
결합 인덱스를 생성할 경우 단일 컬럼의 분포도
컬럼의 분포도가 아무리 좋아도 연산자를 선분 조건으로 사용하야 한다면 분포도는 나빠진다.
분포도가 나쁜 컬럼이라도 점 조건을 사용하여 여러 컬럼을 결합한다면 분포도가 좋아질 수 있다.
점 조건들, 선분 조건들의 순서를 정하기 위한 우선 순위를 선정할 경우에 단일 컬럼의 분포도를 고려해야 한다.
선분 조건에서는 단일 컬럼 자체의 분포도가 아니라 단일 컬럼의 분포도와 연산자에 의해 추출되는 데이터의 양을 업무에 적용하여 비교.
점 조건에는 해당 컬럼의 분포도를 그대로 적용.
----
데이블에 엑세스하는 대부분의 SQL을 함께 고려하여 최적의 인덱스를 선정
실행계획 데이터베이스 튜닝 - 실행계획분석 12
97
한 테이블에 인덱스의 개수가 많다면?
단점
1. DML 성능 저하
2. 디스크 공간 낭비
3. 인덱스 관리의 어려움
4. 인덱스 본연의 역할에 문제 발생
데이터가 테이블에 저장되면 인덱스에도 해당 값을 저장해야 한다.
인덱스의 경우에 여유 공간이 있는 블록에 데이터의 인덱스 값을 저장하는 것이 아니다.
인덱스는 저장되는 데이터 값에 의해 정렬되므로 정렬된 순서에 의해 추가되는 데이터를 저장해야 한다.
데이터가 인덱스에 저장되는 순간 값의 저장 위치가 정해진다.
그러므로 데이터가 테이블에 저장될 때보다 인덱스에 저장될 때 더 큰 부하가 발생한다.
100
유연성이 없는 단일 컬럼 인덱스를 사용하기 보다는 유연성이 높은 결합 컬럼 인덱스를 이용한다면 테이블의 인덱스 개수를 줄일 수 있다.
조회 성능을 최적화하면서 인덱스 개수를 최소화.
한 테이블에 인덱스의 개수가 많다면?
단점
1. DML 성능 저하
2. 디스크 공간 낭비
3. 인덱스 관리의 어려움
4. 인덱스 본연의 역할에 문제 발생
데이터가 테이블에 저장되면 인덱스에도 해당 값을 저장해야 한다.
인덱스의 경우에 여유 공간이 있는 블록에 데이터의 인덱스 값을 저장하는 것이 아니다.
인덱스는 저장되는 데이터 값에 의해 정렬되므로 정렬된 순서에 의해 추가되는 데이터를 저장해야 한다.
데이터가 인덱스에 저장되는 순간 값의 저장 위치가 정해진다.
그러므로 데이터가 테이블에 저장될 때보다 인덱스에 저장될 때 더 큰 부하가 발생한다.
100
유연성이 없는 단일 컬럼 인덱스를 사용하기 보다는 유연성이 높은 결합 컬럼 인덱스를 이용한다면 테이블의 인덱스 개수를 줄일 수 있다.
조회 성능을 최적화하면서 인덱스 개수를 최소화.
2012년 10월 28일 일요일
20121028 어항일지 1
어항의 물을 반 가까이 갈았다.
수족관을 산 곳에서는 일주일에 한번 4분의 1정도의 물을 갈아주라고 했는데 한동안 물관리에 신경을 쓰지 않은듯해서 한번에 많이 갈았다.
그리고 수족관 벽에 짙은 녹조가 끼어 있어서 수위를 낮추고 벽을 닦아야만 했기에 더더욱 물을 많이 버릴 수 밖에 없었다.
물을 갈고 스펀지와 산소 발생기를 청소했다.
스펀지는 매일 청소하라고 했는데 일주일에 한번 밖에 안해주는 듯하다-_-;
음... 수초들의 상태는 그리 좋아 보이지 않는다.
물고기들의 상태는 양호한 것 처럼 보인다.
현재 주황색 줄무늬 열대어 3마리, 노란색 지느러미 물고기 4마리, 청소물고기라 불리는 녀석이 한마리, 그리고 새우 비슷하게 생긴 녀석 한마리 총 9마리가 살고 있다.
얘들아 앞으로 잘 지내보자!
수족관을 산 곳에서는 일주일에 한번 4분의 1정도의 물을 갈아주라고 했는데 한동안 물관리에 신경을 쓰지 않은듯해서 한번에 많이 갈았다.
그리고 수족관 벽에 짙은 녹조가 끼어 있어서 수위를 낮추고 벽을 닦아야만 했기에 더더욱 물을 많이 버릴 수 밖에 없었다.
물을 갈고 스펀지와 산소 발생기를 청소했다.
스펀지는 매일 청소하라고 했는데 일주일에 한번 밖에 안해주는 듯하다-_-;
음... 수초들의 상태는 그리 좋아 보이지 않는다.
물고기들의 상태는 양호한 것 처럼 보인다.
현재 주황색 줄무늬 열대어 3마리, 노란색 지느러미 물고기 4마리, 청소물고기라 불리는 녀석이 한마리, 그리고 새우 비슷하게 생긴 녀석 한마리 총 9마리가 살고 있다.
얘들아 앞으로 잘 지내보자!
2012년 10월 26일 금요일
20121026 운동
계획은 25일 운동이었는데 수요일에 술을 먹어서 수요일 정시퇴근을 목요일로 미루고 목요일 정시퇴근을 금요일로 미뤘다.
앞으로는 빼먹지 말자.
스트레칭
앞으로는 빼먹지 말자.
스트레칭
- 목
- 팔 스트레칭
- 다리
- 반달 자세
- 다리 자세
- 물고기 자세
- 코브라 자세
- 고양이 자세
- 낙타 자세
맨손운동
- 복근운동 상체들기 - 다리들기 각 10회 3 set
- 브릿지 45초, 45초, 45초
- 팔굽혀펴기 4회
트레드밀
- 6 - 5분
- 7.5 - 15분
- 5 - 4분
트레드밀 후 다리 스트레칭
추가할 운동
?
sap 사이트 보고 공부 좀 더하자.
- 벽 밀기
- 서서 몸통 굽히기
근력운동
다음 운동은 20121029- 딥 작게 5회 2set
- 계속 어색한 자세 ㅠㅠ
- 벤치 프레스 - empty bar 10회 3set
추가할 운동
?
sap 사이트 보고 공부 좀 더하자.
ps. 운동카드 반납 완료.
java - 상속과 다형성
하위 클래스가 상위 클래스로부터 상속 받는다.
자바에서는 하위 클래스가 상위 클래스를 확장(extend)한다고 얘기한다.
하위 클래스는 상위 클래스의 인스턴스 변수와 메소드를 자동으로 상속받는다.
하위 클래스에서 별도의 메소드와 인스턴스 변수를 추가할 수도 있고, 상위 클래스에서 상속받은 메소드를 오버라이드 할 수도 있다.
자바에서는 하위 클래스가 상위 클래스를 확장(extend)한다고 얘기한다.
하위 클래스는 상위 클래스의 인스턴스 변수와 메소드를 자동으로 상속받는다.
하위 클래스에서 별도의 메소드와 인스턴스 변수를 추가할 수도 있고, 상위 클래스에서 상속받은 메소드를 오버라이드 할 수도 있다.
2012년 10월 25일 목요일
실행계획 데이터베이스 튜닝 - 실행계획분석 11
90
랜덤 엑세스는 말 그대로 무작위 데이터 추출을 의미한다.
테이블의 전체 데이터 중에서 어느 정도 엑세스해야 많은 데이터이며 어느 정도 엑세스해야 적은 데이터인지에 대한 기준을 제시하는 한 요소가 랜덤 엑세스
----
인덱스에는 키 컬럼의 값과 ROWID 값이 저장되어 있다.
ROWID는 테이블에 저장되어 있는 각 데이터에 할당된 주소와 같다.
그러므로 데이터 베이스에 있는 모든 데이터는 서로 다른 ROWID 값을 갖는다.
인덱스를 생성할 경우 인덱스 컬럼의 값과 함께 해당 데이터의 ROWID가 함께 저장된다.
따라서 인덱스에 엑세스하면 조건을 만족하는 값에 대해 ROWID를 제공받고 해당 ROWID 값으로 테이블에 엑세스한다.
인덱스를 이용한 테이블 엑세스는 인덱스에서 ROWID 값을 확인하고, 해당 ROWID 값을 이용하여 테이블에서 해당 데이터 만을 추출하는 것을 의미한다.
ROWID 값으로 테이블에 엑세스하는 방식을 랜덤 엑세스라고 한다.
----
SQL 수행 시 랜덤 엑세스가 증가하면 SQL의 성능이 저하되며 어느 시점부터는 테이블 전체 스캔보다 성능이 저하된다.
테이블 전체 스캔은 인덱스 스캔 후 테이블에 엑세스하는 방식처럼 ROWID 값으로 테이블에 엑세스하여 원하는 데이터를 추출하는 방식이 아니다.
테이블의 처음부터 끝까지 차례대로 엑세스하기 때문에 ROWID 값을 이용하지 않게 되며, 그러므로 랜덤 엑세스가 발생하지 않는다.
----
BY INDEX ROWID 실행 계획은 랜덤 엑세스를 의미한다.
실행 계획에서 BY INDEX ROWID나 BY LOCAL INDEX ROWID와 같은 형태는 반드시 랜덤 엑세스를 발생시킨다.
----
인덱스에 엑세스하는 방식을 이용할 것인지 아니면 테이블을 전체 스캔하는 방식을 선택할 것인지는 추출하려는 데이터의 양에 의해 결정될 것이다.
----
랜덤 엑세스에 의한 성능 저하는 I/O와 밀접한 관련이 있다.
인덱스에 엑세스하면 ROWID를 제공받는다.
100,000개의 블록으로 구성된 테이블이 있다고 가정하자.
인덱스로부터 100,000개의 ROWID를 제공받았다면 테이블에 대해 100,000번의 랜덤 엑세스를 수행해야하며, 해당 데이터들이 동일 블록에 존재할 가능성을 배제한다면 100,000번의 디스크 I/O를 발생시켜야 한다.
모든 데이터가 동일 블록에 있다면 메모리에서 엑세스가 발생할 것이다.
결국, 100,000건의 데이터에 대해서 인덱스 엑세스 후 ROWID 값으로 테이블에 엑세스한다면 디스크나 메모리에서 100,000번의 I/O가 발생한다.
테이블 전체 스캔은 테이블의 처음부터 끝까지 모든 데이터를 엑세스하는 실행 방식이다.
물론, 엑세스한 후에 필요없는 데이터에 대해서는 버리는 작업을 별도로 수행해야 한다.
하지만, 랜덤 엑세스처럼 ROWID 값에 의해 테이블에 엑세스하는 것이 아니므로 블록을 하나 하나 엑세스할 필요는 없다.
한 번의 I/O에서 여러 블록을 동시에 엑세스하기 위한 오라클 파라메터로 DB_FILE_MULTIBLOCK_READ_COUNT가 있다.
이 파라메터는 테이블 전체 스캔에서 한 번의 I/O 수행 시 동시에 엑세스하는 블록의 개수를 의미한다.
이 파라메터는 8, 16, 32, 64, 128로 설정된다.
128로 설정되어 있다면 전체 테이블 스캔 시 100,000개의 블록에 엑세스 하기 위해서 790번의 I/O가 발생한다.
----
많은 데이터에 대해 인덱스를 이용하며 엑세스하면 많은 양의 랜덤 엑세스가 발생하며, 랜덤 엑세스는 단일 블록 I/O를 수행하므로 엑세스하는 데이터 블록의 개수가 많다면 성능은 저하된다.
반면에 테이블을 전체 스캔한다면 다중 블록 I/O를 수행하므로 더 적은 I/O로 많은 데이터를 추출할 수 있다.
----
보통의 경우, 테이블의 3%~5% 미만에 대해서만 인덱스를 이용하는 것이 효과적이라고 말을 한다.
대용량의 테이블에 대해서는 1% 정도만 랜덤 엑세스해도 성능을 보장받기 힘들 수 있다.
인덱스 스캔 후 테이블에 엑세스하는 랜덤 엑세스가 증가한다면 어느 시점부터 테이블 전체 스캔 보다 성능이 저하된다.
랜덤 엑세스는 말 그대로 무작위 데이터 추출을 의미한다.
테이블의 전체 데이터 중에서 어느 정도 엑세스해야 많은 데이터이며 어느 정도 엑세스해야 적은 데이터인지에 대한 기준을 제시하는 한 요소가 랜덤 엑세스
----
인덱스에는 키 컬럼의 값과 ROWID 값이 저장되어 있다.
ROWID는 테이블에 저장되어 있는 각 데이터에 할당된 주소와 같다.
그러므로 데이터 베이스에 있는 모든 데이터는 서로 다른 ROWID 값을 갖는다.
인덱스를 생성할 경우 인덱스 컬럼의 값과 함께 해당 데이터의 ROWID가 함께 저장된다.
따라서 인덱스에 엑세스하면 조건을 만족하는 값에 대해 ROWID를 제공받고 해당 ROWID 값으로 테이블에 엑세스한다.
인덱스를 이용한 테이블 엑세스는 인덱스에서 ROWID 값을 확인하고, 해당 ROWID 값을 이용하여 테이블에서 해당 데이터 만을 추출하는 것을 의미한다.
ROWID 값으로 테이블에 엑세스하는 방식을 랜덤 엑세스라고 한다.
----
SQL 수행 시 랜덤 엑세스가 증가하면 SQL의 성능이 저하되며 어느 시점부터는 테이블 전체 스캔보다 성능이 저하된다.
테이블 전체 스캔은 인덱스 스캔 후 테이블에 엑세스하는 방식처럼 ROWID 값으로 테이블에 엑세스하여 원하는 데이터를 추출하는 방식이 아니다.
테이블의 처음부터 끝까지 차례대로 엑세스하기 때문에 ROWID 값을 이용하지 않게 되며, 그러므로 랜덤 엑세스가 발생하지 않는다.
----
BY INDEX ROWID 실행 계획은 랜덤 엑세스를 의미한다.
실행 계획에서 BY INDEX ROWID나 BY LOCAL INDEX ROWID와 같은 형태는 반드시 랜덤 엑세스를 발생시킨다.
----
인덱스에 엑세스하는 방식을 이용할 것인지 아니면 테이블을 전체 스캔하는 방식을 선택할 것인지는 추출하려는 데이터의 양에 의해 결정될 것이다.
----
랜덤 엑세스에 의한 성능 저하는 I/O와 밀접한 관련이 있다.
인덱스에 엑세스하면 ROWID를 제공받는다.
100,000개의 블록으로 구성된 테이블이 있다고 가정하자.
인덱스로부터 100,000개의 ROWID를 제공받았다면 테이블에 대해 100,000번의 랜덤 엑세스를 수행해야하며, 해당 데이터들이 동일 블록에 존재할 가능성을 배제한다면 100,000번의 디스크 I/O를 발생시켜야 한다.
모든 데이터가 동일 블록에 있다면 메모리에서 엑세스가 발생할 것이다.
결국, 100,000건의 데이터에 대해서 인덱스 엑세스 후 ROWID 값으로 테이블에 엑세스한다면 디스크나 메모리에서 100,000번의 I/O가 발생한다.
테이블 전체 스캔은 테이블의 처음부터 끝까지 모든 데이터를 엑세스하는 실행 방식이다.
물론, 엑세스한 후에 필요없는 데이터에 대해서는 버리는 작업을 별도로 수행해야 한다.
하지만, 랜덤 엑세스처럼 ROWID 값에 의해 테이블에 엑세스하는 것이 아니므로 블록을 하나 하나 엑세스할 필요는 없다.
한 번의 I/O에서 여러 블록을 동시에 엑세스하기 위한 오라클 파라메터로 DB_FILE_MULTIBLOCK_READ_COUNT가 있다.
이 파라메터는 테이블 전체 스캔에서 한 번의 I/O 수행 시 동시에 엑세스하는 블록의 개수를 의미한다.
이 파라메터는 8, 16, 32, 64, 128로 설정된다.
128로 설정되어 있다면 전체 테이블 스캔 시 100,000개의 블록에 엑세스 하기 위해서 790번의 I/O가 발생한다.
----
많은 데이터에 대해 인덱스를 이용하며 엑세스하면 많은 양의 랜덤 엑세스가 발생하며, 랜덤 엑세스는 단일 블록 I/O를 수행하므로 엑세스하는 데이터 블록의 개수가 많다면 성능은 저하된다.
반면에 테이블을 전체 스캔한다면 다중 블록 I/O를 수행하므로 더 적은 I/O로 많은 데이터를 추출할 수 있다.
----
보통의 경우, 테이블의 3%~5% 미만에 대해서만 인덱스를 이용하는 것이 효과적이라고 말을 한다.
대용량의 테이블에 대해서는 1% 정도만 랜덤 엑세스해도 성능을 보장받기 힘들 수 있다.
인덱스 스캔 후 테이블에 엑세스하는 랜덤 엑세스가 증가한다면 어느 시점부터 테이블 전체 스캔 보다 성능이 저하된다.
2012년 10월 23일 화요일
실행계획 데이터베이스 튜닝 - 실행계획분석 10
힌트 주의점
1. 띄어쓰기, 대소문자 구별
2. 다중 힌트를 사용할 경우 의미상 모순
3. 테이블 명에 대한 별명(Alias)
하나의 힌트 절에 여러 개의 힌트를 동시에 설정할 수 있다.
힌트는 대소문자를 구별하지 않지만 각 힌트에 설정해야 하는 값들 중 테이블 이름은 대소문자를 구별한다.
FROM 절에 소문자로 테이블 이름을 정했다면 힌트에도 해당 태이블을 소문자로 설정해야한다.
모든 힌트 사이에는 반드시 한 칸씩 띄어쓰기가 들어가야 한다.
힌트를 사용할 때 테이블 별명을 사용하면 힌트 적용이 더 수월해진다.
----
실행 계획 확인 방법
EXPLAIN PLAN FOR
AUTOTRACE
TKPROF TRACE
----
AUTOTRACE
1. SET AUTOT ON - SQL을 실제로 실행한 후에 실행 계획 및 실행 중에 해당 SQL이 사용한 자원 등을 추출한다.
2. SET AUTOT TRACEONLY EXP - SQL을 실행하지 않으면 실행 계획 위주로 결과를 추출한다.
...
1. 띄어쓰기, 대소문자 구별
2. 다중 힌트를 사용할 경우 의미상 모순
3. 테이블 명에 대한 별명(Alias)
하나의 힌트 절에 여러 개의 힌트를 동시에 설정할 수 있다.
힌트는 대소문자를 구별하지 않지만 각 힌트에 설정해야 하는 값들 중 테이블 이름은 대소문자를 구별한다.
FROM 절에 소문자로 테이블 이름을 정했다면 힌트에도 해당 태이블을 소문자로 설정해야한다.
모든 힌트 사이에는 반드시 한 칸씩 띄어쓰기가 들어가야 한다.
힌트를 사용할 때 테이블 별명을 사용하면 힌트 적용이 더 수월해진다.
----
실행 계획 확인 방법
EXPLAIN PLAN FOR
AUTOTRACE
TKPROF TRACE
----
AUTOTRACE
1. SET AUTOT ON - SQL을 실제로 실행한 후에 실행 계획 및 실행 중에 해당 SQL이 사용한 자원 등을 추출한다.
2. SET AUTOT TRACEONLY EXP - SQL을 실행하지 않으면 실행 계획 위주로 결과를 추출한다.
...
실행계획 데이터베이스 튜닝 - 실행계획분석 09
힌트로 실행 계획을 제어
문법이 틀려도 힌트가 SQL의 실행에 영향을 미치지는 않는다. 무시된다.
----
힌트 분류
1. 인덱스 엑세스 관련 힌트
2. 테이블 엑세스 관련 힌트
3. 조인 관련 힌트
4. 기타 힌트
5. SQL 변형 제어 관련 힌트
6. REMOTE 실행 계획 관련 힌트
----
인덱스 관련 힌트
INDEX
SQL이 엑세스 할 인덱스를 설정하는 힌트
INDEX(테이블이름, 인덱스이름) 형태로 사용
해당 테이블에 있는 인덱스 중에서 원하는 인덱스를 이용할 수 있게 해준다.
인덱스의 위에서부터 아래로 엑세스를 수행한다는 점에서 INDEX_ASC 힌트와 동일
오라클 10g에서는 INDEX(테이블이름, (컬럼이름, ..., 컬럼이름))으로도 설정 가능하다.
특정 인덱스를 설정하는 것이 아니라 해당 컬럼들로 구성된 인덱스를 유연하게 이용할 수 있게 해준다.
----
INDEX_DESC
인덱스를 구성하는 첫 번째 컬럼에 의해 내림차순으로 데이터가 추출
최근 데이터 순으로 추출하믄 목록 쿼리 또는 최대 값 및 최소 값을 추출하는 SQL에서 사용됨
----
INDEX_FFS
FAST INDEX FULL SCAN
일반 INDEX FULL SCAN과의 차이는 디스크 I/O 단위
INDEX_FFS(테이블이름, 인덱스이름)
NO_INDEX_FFS 사용 가능
----
PARALLEL_INDEX
INDEX_FFS 힌트와 동일, 여러 개의 프로세스로 인덱스 FULL SCAN
PARALLEL_INDEX(테이블이름, 인덱스이름, 프로세스개수)
NOPARALLEL_INDEX 사용 가능
----
INDEX_JOIN
2개 이상의 인덱스를 엑세스하여 테이블에 대한 랜덤 엑세스 없이 원하는 결과 데이터를 추출
하나의 테이블에서 데이터에 엑세스 하는 경우이므로 두 인덱스에 대한 조인 조건이 ROWID만 존재하므로 중첩 루프 조인을 사용한다면 성능이 저하된다. 그래서 오라클에서는 인덱스 조인 시에 해쥐 조인만 제공한다.
INDEX_JOIN(테이블이름, 인덱스이름)
----
INDEX_SS
INDEX_SS(테이블이름, 인덱스이름)
NO_INDEX_SS 사용 가능
INDEX_SS_DESC, INDEX_SS_ASC 사용 가능
인덱스의 철 번째 컬럼이 WHERE 조건 절에 설정되지 않고 첫 번째 컬럼의 분포도가 좋지 않아 몇가지 종류의 데이터만 저장될 경우 성능 향상 가능.
----
테이블 엑세스에 대한 힌트
분포도가 나쁘다는 것은 해당 컬럼에 동일한 값을 갖는 데이터가 많다는 의미다.
분포도가 나쁠 경우 해당 인덱스를 이용하는 순간 처리 범위가 증가하기 때문에 테이블의 많은 부분에 엑세스 해야 한다. 이로인해 증가하는 랜덤 엑세스는 엄청난 성능 저하를 발생한다. 따라서 분포도가 좋지 않은 인덱스를 이용하지 못하게 하고 테이블을 전체 스캔하는 것이 성능적인 면에서 더욱 유리하다.
인덱스를 이용하지 못하게 하는 방법에는 여러가지가 있으며, 그 중 하나가 FULL 힌트
FULL(테이블이름)
----
조인 관련 힌트
USE_NL
중첩 루프 조인을 수행
USE_NL(테이블이름, 테이블이름)
앞에 설정한 테이블에 먼저 엑세스, 뒤에 설정한 테이블은 뒤에 엑세스하여 중첩 루프 조인 수행
----
USE_HASH
해쉬 조인 수행, USE_NL 과 동일
----
USE_MERGE
소트 머지 조인, USE_NL 과 동일
----
NL_SJ - 중첩 루프 조인, 세미 조인
NL_AJ - 중첩 루프 조인, 안티 조인
HASH_SJ - 해쉬 조인, 세미 조인
HASH_AJ - 해쉬 조인, 안티 조인
MERGE_SJ - 소트 머지 조인, 세미 조인
MERGE_AJ - 소트 머지 조인, 안티 조인
----
조인 순서에 대한 힌트
ORDERED
두 개 이상의 테이블을 조인할 경우 어느 테이블이 먼저 엑세스 될지는 여러 개의 우선 순위를 확인하여 결정
모든 우선 순위가 동일하다면 FROM 절의 테이블의 역순
FROM 절에 설정한 순서로 테이블에 엑세스하여 조인하고 싶으면 ORDERED 힌트
매우 강력한 힌트로 옵티마이져는 이 힌트를 거의 무시하지 않는다.
----
LEADING
해당 힌트에 설정하는 테이블 순서에 의해 조인 순서가 결정
ORDERED 힌트와 함께 사용한다면 ORDERED 힌트가 우선시 된다.
/*+ LEADING(B, A) */
....
기타 힌트 생략 ...
문법이 틀려도 힌트가 SQL의 실행에 영향을 미치지는 않는다. 무시된다.
----
힌트 분류
1. 인덱스 엑세스 관련 힌트
2. 테이블 엑세스 관련 힌트
3. 조인 관련 힌트
4. 기타 힌트
5. SQL 변형 제어 관련 힌트
6. REMOTE 실행 계획 관련 힌트
----
인덱스 관련 힌트
INDEX
SQL이 엑세스 할 인덱스를 설정하는 힌트
INDEX(테이블이름, 인덱스이름) 형태로 사용
해당 테이블에 있는 인덱스 중에서 원하는 인덱스를 이용할 수 있게 해준다.
인덱스의 위에서부터 아래로 엑세스를 수행한다는 점에서 INDEX_ASC 힌트와 동일
오라클 10g에서는 INDEX(테이블이름, (컬럼이름, ..., 컬럼이름))으로도 설정 가능하다.
특정 인덱스를 설정하는 것이 아니라 해당 컬럼들로 구성된 인덱스를 유연하게 이용할 수 있게 해준다.
----
INDEX_DESC
인덱스를 구성하는 첫 번째 컬럼에 의해 내림차순으로 데이터가 추출
최근 데이터 순으로 추출하믄 목록 쿼리 또는 최대 값 및 최소 값을 추출하는 SQL에서 사용됨
----
INDEX_FFS
FAST INDEX FULL SCAN
일반 INDEX FULL SCAN과의 차이는 디스크 I/O 단위
INDEX_FFS(테이블이름, 인덱스이름)
NO_INDEX_FFS 사용 가능
----
PARALLEL_INDEX
INDEX_FFS 힌트와 동일, 여러 개의 프로세스로 인덱스 FULL SCAN
PARALLEL_INDEX(테이블이름, 인덱스이름, 프로세스개수)
NOPARALLEL_INDEX 사용 가능
----
INDEX_JOIN
2개 이상의 인덱스를 엑세스하여 테이블에 대한 랜덤 엑세스 없이 원하는 결과 데이터를 추출
하나의 테이블에서 데이터에 엑세스 하는 경우이므로 두 인덱스에 대한 조인 조건이 ROWID만 존재하므로 중첩 루프 조인을 사용한다면 성능이 저하된다. 그래서 오라클에서는 인덱스 조인 시에 해쥐 조인만 제공한다.
INDEX_JOIN(테이블이름, 인덱스이름)
----
INDEX_SS
INDEX_SS(테이블이름, 인덱스이름)
NO_INDEX_SS 사용 가능
INDEX_SS_DESC, INDEX_SS_ASC 사용 가능
인덱스의 철 번째 컬럼이 WHERE 조건 절에 설정되지 않고 첫 번째 컬럼의 분포도가 좋지 않아 몇가지 종류의 데이터만 저장될 경우 성능 향상 가능.
----
테이블 엑세스에 대한 힌트
분포도가 나쁘다는 것은 해당 컬럼에 동일한 값을 갖는 데이터가 많다는 의미다.
분포도가 나쁠 경우 해당 인덱스를 이용하는 순간 처리 범위가 증가하기 때문에 테이블의 많은 부분에 엑세스 해야 한다. 이로인해 증가하는 랜덤 엑세스는 엄청난 성능 저하를 발생한다. 따라서 분포도가 좋지 않은 인덱스를 이용하지 못하게 하고 테이블을 전체 스캔하는 것이 성능적인 면에서 더욱 유리하다.
인덱스를 이용하지 못하게 하는 방법에는 여러가지가 있으며, 그 중 하나가 FULL 힌트
FULL(테이블이름)
----
조인 관련 힌트
USE_NL
중첩 루프 조인을 수행
USE_NL(테이블이름, 테이블이름)
앞에 설정한 테이블에 먼저 엑세스, 뒤에 설정한 테이블은 뒤에 엑세스하여 중첩 루프 조인 수행
----
USE_HASH
해쉬 조인 수행, USE_NL 과 동일
----
USE_MERGE
소트 머지 조인, USE_NL 과 동일
----
NL_SJ - 중첩 루프 조인, 세미 조인
NL_AJ - 중첩 루프 조인, 안티 조인
HASH_SJ - 해쉬 조인, 세미 조인
HASH_AJ - 해쉬 조인, 안티 조인
MERGE_SJ - 소트 머지 조인, 세미 조인
MERGE_AJ - 소트 머지 조인, 안티 조인
----
조인 순서에 대한 힌트
ORDERED
두 개 이상의 테이블을 조인할 경우 어느 테이블이 먼저 엑세스 될지는 여러 개의 우선 순위를 확인하여 결정
모든 우선 순위가 동일하다면 FROM 절의 테이블의 역순
FROM 절에 설정한 순서로 테이블에 엑세스하여 조인하고 싶으면 ORDERED 힌트
매우 강력한 힌트로 옵티마이져는 이 힌트를 거의 무시하지 않는다.
----
LEADING
해당 힌트에 설정하는 테이블 순서에 의해 조인 순서가 결정
ORDERED 힌트와 함께 사용한다면 ORDERED 힌트가 우선시 된다.
/*+ LEADING(B, A) */
....
기타 힌트 생략 ...
실행계획 데이터베이스 튜닝 - 실행계획분석 08
데이터 연결 실행 계획
조인 실행 계획
1. 중첩 루프 조인 (NESTED LOOP JOIN)
2. 해쉬 조인 (HASH JOIN)
3. 소트 머지 조인 (SORT MERGE JOIN)
조인 실행 계획에서 조금씩 변형된 FILTER, SEMI, 카테시안, ANTI 조인 등이 존재한다.
순환 전개 실행 계획
CONNECT BY ... START WITH 구문으로 작성한 SQL 등에서 수행된다.
이외에도 데이터를 연결하는 방법에는 서브쿼리, 스칼라 서브쿼리, 인라인 뷰 등이 있다.
----
복합 실행 계획
실행 계획을 해석하는 방법
1. 가장 안쪽에 들여쓰기가 된 실행 계획부터 해석
2. 동일하게 들여쓰기가 된 실행 계획은 위에서부터 해석
3. 연관된 실행 계획은 함께 해석
4. 조인의 경우는 조인의 수행 방식으로 해석
조인 실행 계획
1. 중첩 루프 조인 (NESTED LOOP JOIN)
2. 해쉬 조인 (HASH JOIN)
3. 소트 머지 조인 (SORT MERGE JOIN)
조인 실행 계획에서 조금씩 변형된 FILTER, SEMI, 카테시안, ANTI 조인 등이 존재한다.
순환 전개 실행 계획
CONNECT BY ... START WITH 구문으로 작성한 SQL 등에서 수행된다.
이외에도 데이터를 연결하는 방법에는 서브쿼리, 스칼라 서브쿼리, 인라인 뷰 등이 있다.
----
복합 실행 계획
실행 계획을 해석하는 방법
1. 가장 안쪽에 들여쓰기가 된 실행 계획부터 해석
2. 동일하게 들여쓰기가 된 실행 계획은 위에서부터 해석
3. 연관된 실행 계획은 함께 해석
4. 조인의 경우는 조인의 수행 방식으로 해석
실행계획 데이터베이스 튜닝 - 실행계획분석 07
STOPKEY 실행 계획
STOPKEY 실행 계획은 ROWNUM 연산자를 사용했을 경우 생성되는 실행 계획.
다른 실행 계획보다 우선 순위가 높다.
실행 계획에 테이블 전체 스캔이 생성되었다고 하더라도 ROWNUM 연산자가 있는 경우 STOPKEY 실행 계획이 수행되어 ROWNUM 조건을 만족하면 테이블의 스캔을 종료한다.
ROWNUM 연산자를 사용할 경우 인덱스의 이용이 매우 중요하다.
인덱스를 이용한 실행 계획이 아니면 얼마만큼의 데이터에 엑세스해야 하는지 정확히 알 수 없다.
인덱스를 이용한 실행 계획이라면 무조건 ROWNUM 이하의 데이터만 엑세스하게 되어 확실한 성능을 보장받을 수 있다.
ROWNUM 연산자가 SELECT 절에 사용된다면 실행 계획에슨 COUNT 실행 계획이 생성된다.
하지만, ROWNUM 연산자가 WHERE 절에 사용되었다면 COUNT(STOPKEY) 실행 계획이 생성된다.
----
파티션 실행 계획 - 생략
----
REMOTE 실행 계획 - 생략
STOPKEY 실행 계획은 ROWNUM 연산자를 사용했을 경우 생성되는 실행 계획.
다른 실행 계획보다 우선 순위가 높다.
실행 계획에 테이블 전체 스캔이 생성되었다고 하더라도 ROWNUM 연산자가 있는 경우 STOPKEY 실행 계획이 수행되어 ROWNUM 조건을 만족하면 테이블의 스캔을 종료한다.
ROWNUM 연산자를 사용할 경우 인덱스의 이용이 매우 중요하다.
인덱스를 이용한 실행 계획이 아니면 얼마만큼의 데이터에 엑세스해야 하는지 정확히 알 수 없다.
인덱스를 이용한 실행 계획이라면 무조건 ROWNUM 이하의 데이터만 엑세스하게 되어 확실한 성능을 보장받을 수 있다.
ROWNUM 연산자가 SELECT 절에 사용된다면 실행 계획에슨 COUNT 실행 계획이 생성된다.
하지만, ROWNUM 연산자가 WHERE 절에 사용되었다면 COUNT(STOPKEY) 실행 계획이 생성된다.
----
파티션 실행 계획 - 생략
----
REMOTE 실행 계획 - 생략
실행계획 데이터베이스 튜닝 - 실행계획분석 06
집합 연산자에 의해 생성되는 실행 계획
UNION ALL - (A 합집합 B) + (A 교집합 B)
UNION - (A 합집합 B)
MINUS - (A 차집합 B)
UNION ALL을 제외한 모든 집합 연산자는 항상 UNIQUE 값을 추출한다.
UNIQUE 한 값을 추출하기 위해서는 SORT(UNIQUE) 실행 계획을 이용한다. - 대용량의 정렬은 성능이 저하될 수 있다.
-----
UNION ALL 집합 연산자는 UNION ALL 실행 계획이 생성되며 CONCATENATION 실행 계획과 동일하다.
다른 집합 연산자와 달리 SORT(UNIQUE) 실행 계획이 생성되지 않는다.
----
UNION 집합 연산자
UNION ALL 집합 연산자와의 차이는 SORT(UNIQUE) 실행 계획의 유무 - 즉, 중복 데이터를 제거한다.
대용량의 데이터에 UNION ALL 집합 연산자와 UNION 집합 연산자를 사용한 것의 데이터가 동일하다면 반드시 UNION ALL 집합 연산자를 사용해야 한다.
----
MINUS 연산자는 두 집합에 대해 각각 UNIQUE 정렬을 수행한다. 각각 UNIQUE 정렬을 수행한 후에 동일한 데이터를 제외한다.
안티 조인과 MINUS 연산자는 데이터의 속성에 따라 동일한 결과를 추출할 수도 있고 아닐 수도 있다.
두 개의 집합이 UNIQUE 한 값이라면 안티 조인과 동일한 결과가 추출될 것이다. 이러한 경우에는 안티 조인이 유리한 경우가 많다.
MINUS 연산자는 SORT(UNIQUE) 실행 계획에 의해 정렬을 수행하므로 시스템 자체의 자원을 많이 사용한다. 특히, 디스크 I/O와 관련해서 많은 자원을 사용할 것이다.
----
VIEW 실행 계획
VIEW 실행 계획은 VIEW 실행 계획 밑에 있는 테이블이나 인덱스에 엑세스하여 메모리에 임시 집합을 생성한다.
데이터에 한 번 엑세스한 후에 해당 데이터를 가공하는 부분에서는 VIEW 실행 계획이 생성된다.
FROM 절 안에 있는 완전한 SQL에 의해 VIEW 실행 계획이 생성될 수 있다.
하지만 FROM 절의 SQL이 별도로 수행되는 것이 아니라 해당 SQL이 하나로 합쳐져서 수행될 수 있다. 이렇게 수행된다면 VIEW 실행 계획은 생성되지 않는다.
VIEW 실행 계획에서 추출된 데이터는 메모리에 저장되며, 그러므로 인덱스가 존재할 수 없다. 그렇기 때문에 VIEW 실행 계획으로 만들어진 집합과 다른 집합이 조인을 수행하게 되면 VIEW 실행 계획에서 만들어진 집합에 전체 스캔이 수행될 수도 있다. 이러한 현상은 SQL의 성능을 좌우한다.
UNION ALL - (A 합집합 B) + (A 교집합 B)
UNION - (A 합집합 B)
MINUS - (A 차집합 B)
UNION ALL을 제외한 모든 집합 연산자는 항상 UNIQUE 값을 추출한다.
UNIQUE 한 값을 추출하기 위해서는 SORT(UNIQUE) 실행 계획을 이용한다. - 대용량의 정렬은 성능이 저하될 수 있다.
-----
UNION ALL 집합 연산자는 UNION ALL 실행 계획이 생성되며 CONCATENATION 실행 계획과 동일하다.
다른 집합 연산자와 달리 SORT(UNIQUE) 실행 계획이 생성되지 않는다.
----
UNION 집합 연산자
UNION ALL 집합 연산자와의 차이는 SORT(UNIQUE) 실행 계획의 유무 - 즉, 중복 데이터를 제거한다.
대용량의 데이터에 UNION ALL 집합 연산자와 UNION 집합 연산자를 사용한 것의 데이터가 동일하다면 반드시 UNION ALL 집합 연산자를 사용해야 한다.
----
MINUS 연산자는 두 집합에 대해 각각 UNIQUE 정렬을 수행한다. 각각 UNIQUE 정렬을 수행한 후에 동일한 데이터를 제외한다.
안티 조인과 MINUS 연산자는 데이터의 속성에 따라 동일한 결과를 추출할 수도 있고 아닐 수도 있다.
두 개의 집합이 UNIQUE 한 값이라면 안티 조인과 동일한 결과가 추출될 것이다. 이러한 경우에는 안티 조인이 유리한 경우가 많다.
MINUS 연산자는 SORT(UNIQUE) 실행 계획에 의해 정렬을 수행하므로 시스템 자체의 자원을 많이 사용한다. 특히, 디스크 I/O와 관련해서 많은 자원을 사용할 것이다.
----
VIEW 실행 계획
VIEW 실행 계획은 VIEW 실행 계획 밑에 있는 테이블이나 인덱스에 엑세스하여 메모리에 임시 집합을 생성한다.
데이터에 한 번 엑세스한 후에 해당 데이터를 가공하는 부분에서는 VIEW 실행 계획이 생성된다.
FROM 절 안에 있는 완전한 SQL에 의해 VIEW 실행 계획이 생성될 수 있다.
하지만 FROM 절의 SQL이 별도로 수행되는 것이 아니라 해당 SQL이 하나로 합쳐져서 수행될 수 있다. 이렇게 수행된다면 VIEW 실행 계획은 생성되지 않는다.
VIEW 실행 계획에서 추출된 데이터는 메모리에 저장되며, 그러므로 인덱스가 존재할 수 없다. 그렇기 때문에 VIEW 실행 계획으로 만들어진 집합과 다른 집합이 조인을 수행하게 되면 VIEW 실행 계획에서 만들어진 집합에 전체 스캔이 수행될 수도 있다. 이러한 현상은 SQL의 성능을 좌우한다.
실행계획 데이터베이스 튜닝 - 실행계획분석 05
IN 연산자는 2가지 형태로 실행 계획이 생성될 수 있다.
우선 IN 연산자에 상수가 사용되는 경우만 살펴본다.
CONCATENATION
INLIST
--------------------------------------
CONCATENATION 실행계획
UNION ALL 집합 연산자와 동일한 개념의 실행 계획
SELECT /*+ RULE*/
*
FROM SEND_FILE
WHERE BASE_DATE IN ('20121022', '20120102')
;
SELECT STATEMENT Cost =
CONCATENATION
TABLE ACCESS BY INDEX ROWID SEND_FILE
INDEX RANGE SCAN SEND_FILE
TABLE ACCESS BY INDEX ROWID SEND_FILE
INDEX RANGE SCAN SEND_FILE
위의 실행 계획은 테이블에 엑세스를 두번하여 데이터의 합집합을 추출
IN 절에 인덱스가 이용되면 뒤에서부터 데이터가 추출된다.
---------------------------------------
INLIST 실행계획
SELECT
우선 IN 연산자에 상수가 사용되는 경우만 살펴본다.
CONCATENATION
INLIST
--------------------------------------
CONCATENATION 실행계획
UNION ALL 집합 연산자와 동일한 개념의 실행 계획
SELECT /*+ RULE*/
*
FROM SEND_FILE
WHERE BASE_DATE IN ('20121022', '20120102')
;
SELECT STATEMENT Cost =
CONCATENATION
TABLE ACCESS BY INDEX ROWID SEND_FILE
INDEX RANGE SCAN SEND_FILE
TABLE ACCESS BY INDEX ROWID SEND_FILE
INDEX RANGE SCAN SEND_FILE
위의 실행 계획은 테이블에 엑세스를 두번하여 데이터의 합집합을 추출
IN 절에 인덱스가 이용되면 뒤에서부터 데이터가 추출된다.
---------------------------------------
INLIST 실행계획
SELECT
*
FROM SEND_FILE
WHERE BASE_DATE IN ('20121022', '20120102')
;
FROM SEND_FILE
WHERE BASE_DATE IN ('20121022', '20120102')
;
SELECT STATEMENT Cost = 590
INLIST ITERATOR
TABLE ACCESS BY INDEX ROWID SEND_FILE
INDEX RANGE SCAN SEND_FILE
INLIST 실행 계획은 IN 절에 상수가 몇 개일지라도 테이블에 한 번만 엑세스한다.
------------------------------------------
IN 절이 인덱스를 이용할 경우
INLIST 실행계획은 IN 절의 앞에서부터 데이터를 엑세스하고 추출
CONCATENATION 실행계획은 IN 절의 뒤에서부터 데이터를 엑세스하고 추출
ROWNUM 연산자가 사용될 경우 ROWNUM <= 1
INLIST 실행 계획으로 생성될 경우 1건만 추출
CONCATENATION 실행 계획으로 생성될 경우 만족하는 모든 데이터를 추출한 후에 1건의 데이터만 추출하므로 성능이 저하됨
/*+ NO_EXPAND */ 힌트를 이용하면 CONCATENATION 실행 계획이 생성되지 않는다.
/*+ USE_CONCATE */ 힌트를 이용하면 CONCATENATION 실행 계획이 생성된다.
-------------------------------------
인덱스를 이용하지 못할 경우 IN 연산자는 테이블 전체 스캔
2012년 10월 22일 월요일
20121022 운동
스트레칭
- 목
- 팔 스트레칭
- 코브라 자세
- 다리 자세
- 물고기 자세
- 고양이 자세
- 낙타 자세
- 반달 자세
맨손운동
- 복근운동 상체들기 - 다리들기 각 10회 3 set
- 브릿지 40초, 40초, 40초
트레드밀
- 6 - 5분
- 7.5 - 10분
- 4 - 5분
트레드밀 후 다리 스트레칭
벽 밀기
서서 몸통 굽히기
딥 작게 5회 2set
- 팔, 어께 힘이 너무 약해 제대로 자세가 안나온다.
- 꾸준히 해보자.
딥 작게 5회 2set
- 팔, 어께 힘이 너무 약해 제대로 자세가 안나온다.
- 꾸준히 해보자.
다음 운동은 20121025
추가할 운동
허리운동
팔굽혀펴기
ps. 운동카드 반납 완료.
실행계획 데이터베이스 튜닝 - 실행계획분석 04
정렬 관련 실행 계획
1. SORT(AGGREGATE)
2. SORT(UNIQUE)
3. SORT(GROUP BY)
4. SORT(ORDER BY)
--------------
1. SORT(AGGREGATE)
SUM, MIN, MAX, COUNT 같은 집할 함수를 사용할 경우 생성.
----------------
2. SORT(UNIQUE)
IN 절을 사용할 경우 우일한 데이터를 만드는 정렬 작업이 내부적으로 발생할 수 있다.
IN 절이 먼저 수행되어 주 쿼리로 값을 제공할 경우에만 IN 절에서 SORT(UNIQUE)실행 계획이 생성된다.
IN 절이 뒤에 수행되어 데이터를 확인하는 경우에는 SORT(UNIQUE) 실행 계획이 생성되지 않는다.
DISTINCT 옵션을 사용할 경우에도 UNIQUE 정렬을 수행한다.
...
실행계획 데이터베이스 튜닝 - 실행계획분석 03
INDEX SKIP SCAN과 MIN/MAX SCAN은 오라클 9i 부터 도입된 실행계획
INDEX SKIP SCAN
MIN/MAX 실행계획
최소값 최대값을 추출하기 위한 SQL
보통 조건을 만족하는 모든 집한에 엑세스하여 정렬을 수행한 후에 최대 값이나 최소 값을 추출
아니면 INDEX RANGE SCAN DESCENDING 실행 계획을 이용하여 추출
SELECT
MAX(DURATION)
FROM CDCP_ORG_PRICE A
WHERE REVAL_DATE = '20121018'
;
SELECT STATEMENT Cost = 1734
SORT AGGREGATE
TABLE ACCESS BY INDEX ROWID CDCP_ORG_PRICE
INDEX RANGE SCAN CDCP_ORG_PRICE_PK
SELECT
/*+ INDEX_DESC(A, CDCP_ORG_PRICE_PK) */
MAX(DURATION)
FROM CDCP_ORG_PRICE A
WHERE REVAL_DATE = '20121018'
AND ROWNUM <= 1
;
SELECT STATEMENT Cost = 1734
SORT AGGREGATE
COUNT STOPKEY
TABLE ACCESS BY INDEX ROWID CDCP_ORG_PRICE
INDEX RANGE SCAN DESCENDING CDCP_ORG_PRICE_PK
-----------------
INDEX JOIN도 인덱스 스탠의 한 종륲다.
1+3 인덱스와 2+4 인덱스가 있을 때, 1, 2가 WHERE 절에 포함되고, 3, 4가 SELECT 절에 포함되면 테이블에 대해 랜덤 엑세스 없이 원하는 모든 값을 추출할 수 있다.
인덱스 조인은 반드시 해쉬 조인으로만 수행된다.
1+3, 4+2 인덱스가 있는 경우 WHERE절에서 1, 2 조건, SELECT 절에서 3, 4 조회일 경우 인덱스 조인으로 수행
INDEX SKIP SCAN
MIN/MAX 실행계획
최소값 최대값을 추출하기 위한 SQL
보통 조건을 만족하는 모든 집한에 엑세스하여 정렬을 수행한 후에 최대 값이나 최소 값을 추출
아니면 INDEX RANGE SCAN DESCENDING 실행 계획을 이용하여 추출
SELECT
MAX(DURATION)
FROM CDCP_ORG_PRICE A
WHERE REVAL_DATE = '20121018'
;
SELECT STATEMENT Cost = 1734
SORT AGGREGATE
TABLE ACCESS BY INDEX ROWID CDCP_ORG_PRICE
INDEX RANGE SCAN CDCP_ORG_PRICE_PK
SELECT
/*+ INDEX_DESC(A, CDCP_ORG_PRICE_PK) */
MAX(DURATION)
FROM CDCP_ORG_PRICE A
WHERE REVAL_DATE = '20121018'
AND ROWNUM <= 1
;
SELECT STATEMENT Cost = 1734
SORT AGGREGATE
COUNT STOPKEY
TABLE ACCESS BY INDEX ROWID CDCP_ORG_PRICE
INDEX RANGE SCAN DESCENDING CDCP_ORG_PRICE_PK
INDEX RANGE SCAN DESCENDING 실행 계획은 인덱스 스캔에서 발생하는 실행계획
인덱스 범위 스캔을 수행하는 과정에서 인덱스의 밑에서부터 엑세스하는 실행 계획
인덱스의 밑에서부터 엑세스하므로 해당 인덱스의 첫 번째 컬럼이 최대 값이 된다.
-----------------
INDEX JOIN도 인덱스 스탠의 한 종륲다.
1+3 인덱스와 2+4 인덱스가 있을 때, 1, 2가 WHERE 절에 포함되고, 3, 4가 SELECT 절에 포함되면 테이블에 대해 랜덤 엑세스 없이 원하는 모든 값을 추출할 수 있다.
인덱스 조인은 반드시 해쉬 조인으로만 수행된다.
1+3, 4+2 인덱스가 있는 경우 WHERE절에서 1, 2 조건, SELECT 절에서 3, 4 조회일 경우 인덱스 조인으로 수행
2012년 10월 16일 화요일
20121016 운동
스트레칭
ps. 운동카드 반납 완료.
- 목
- 팔 스트레칭
- 코브라 자세
- 고양이 자세
- 낙타 자세
맨손운동
- 복근운동 상체들기 - 다리들기 각 10회 3 set
- 브릿지 30초, 40초
- 팔굽혀 펴기 5회
트레드밀
- 6 - 5분
- 7.5 - 10분
다음 운동은 20121018
추가할 운동
다리 자세
물고기 자세
반달 자세
트레드밀 후 다리 스트레칭
벽 밀기
서서 몸통 굽히기
딥
운동도 공부해야한다. 공부하자!
ps. 운동카드 반납 완료.
20121015 운동
10분 스트레칭
누워서 허리 운동
무릅 굽히고 복근운동 - 다리 들기 10회 2 set
25분 트레드밀
5분 5
20분 6.5
5분 4
다리 스트레칭
허리들기 10회
sap 사이트를 뒤지고 읽고 정리하자.
누워서 허리 운동
무릅 굽히고 복근운동 - 다리 들기 10회 2 set
25분 트레드밀
5분 5
20분 6.5
5분 4
다리 스트레칭
허리들기 10회
sap 사이트를 뒤지고 읽고 정리하자.
실행계획 데이터베이스 튜닝 - 실행계획분석 01
계획
20121022 ~ 20121026 ch1
20121029 ~ 20121102 ch2
20121105 ~ 20121109 ch3
20121112 ~ 20121116 ch4
20121119 ~ 20121123 ch5, ch6
20121126 ~ 20121130 ch7
SQL을 통해 결과를 추출하는 과정에서 여섯 가지 방법을 함께 이용할 수 있다.
실행계획 6가지
1. 테이블 관련 실행 계획
2. 인덱스 관련 실행 계획
3. 정렬 관련 실행 계획
4. 연산자 관련 실행 계획
5. 데이터 연결 관련 실행 계획
6. 파티션 관련 실행 계획
-----------------------------
테이블 관련 실행 계획
1. BY INDEX ROWID - 인덱스 스캔을 통한 테이블 엑세스
2. FULL SCAN - 테이블 전체 스캔
3. BY USER ROWID - 정의된 ROWID에 의한 테이블 엑세스
4. SAMPLE - 표본 데이터 추출
테이블의 컬럼에 인덱스가 존재한다면 해당 인덱스에 엑세스하는 순간 인덱스로부터 ROWID가 제공된다.
ROWID는 하나의 데이터를 찾아가는 유일한 주소
인덱스를 이용하지 않고 테이블에 바로 엑세스한다면 FULL SCAN
CONNECT BY 절을 사용하면 BY USER ROWID 실행 계획
BY INDEX ROWID와 FULL SCAN이 주로 사용됨
-----------------------------
인덱스를 이용한 후에 테이블에 엑세스하면 BY INDEX ROWID 실행 계획이 생성된다.
인덱스에서 생성되는 실행 계획은 9가지
1. INDEX RANGE SCAN
2. INDEX UNIQUE SCAN
3. INDEX AND-EQUALS
4. INDEX FULL SCAN
5. INDEX FAST FULL SCAN
6. INDEX PARALLEL SCAN
7. INDEX SKIP SCAN
8. INDEX MIN/MAX SCAN
9. INDEX JOIN
-------------------------------
선분조건 LINE CONDITION 이 사용된 WHERE 조건의 컬럼이 인덱스를 이용할 경우 INDEX RANGE SCAN이 발생
점조건 POINT CONDITION 일지라도 인덱스를 UNIQUE 인덱스로 생성하지 않았다면 INDEX RANGE SCAN
값을 만족하는 데이터가 세 건이라면 실제 데이터 엑세스는 네 번 이루어진다.
-------------------------------
점 조건 중에서 = 조건을 사용하며 해당 조건에서 UNIQUE 인덱스를 이용하면 INDEX UNIQUE SCAN
UNIQUE 인덱스이더라도 점 조건이 아닌 선분 조건으로 조회된다면 INDEX RANGE SCAN
-------------------------------
보통의 경우 INDEX AND-EQUALS 실행 계획은 성능 최적화 대상이 될 수 있다.
8i에서 도입 10g 부터 폐기
INDEX AND-EQUALS 실행 계획은 두 개의 인덱스를 이용하여 원하는 데이터를 추출
두 컬럼의 인덱스를 추출하여 인덱스 머지를 수행
인덱스 머지
각 인덱스에서 조건을 만족하는 데이터의 ROWID를 확인한 후 1번 인덱스에서 조건을 만족하는 값을 찾으면 확인한 ROWID를 2번 인덱스에서 동일한 ROWID가 확인될때까지 찾는다. 2번 인덱스에서 값을 다 확인한 후 다시 1번 인덱스로 돌아가 다음 값이 조건을 만족하는지 확인한다. 그리고 반복한다.
결합 인덱스를 이용한다면 처리 범위가 감소할 수 있다.
INDEX AND-EQUALS 실행 계획이 빈번히 발생한다면 인덱스 선정을 다시 검토해야 한다.
--------------------------------
DB 실행계획에 대해 공부중이다.
공부한 내용을 요약하면서 다시 한번 상기중인데 양이 많다. 정말 많다.
아무든 계속.
20121022 ~ 20121026 ch1
20121029 ~ 20121102 ch2
20121105 ~ 20121109 ch3
20121112 ~ 20121116 ch4
20121119 ~ 20121123 ch5, ch6
20121126 ~ 20121130 ch7
SQL을 통해 결과를 추출하는 과정에서 여섯 가지 방법을 함께 이용할 수 있다.
실행계획 6가지
1. 테이블 관련 실행 계획
2. 인덱스 관련 실행 계획
3. 정렬 관련 실행 계획
4. 연산자 관련 실행 계획
5. 데이터 연결 관련 실행 계획
6. 파티션 관련 실행 계획
-----------------------------
테이블 관련 실행 계획
1. BY INDEX ROWID - 인덱스 스캔을 통한 테이블 엑세스
2. FULL SCAN - 테이블 전체 스캔
3. BY USER ROWID - 정의된 ROWID에 의한 테이블 엑세스
4. SAMPLE - 표본 데이터 추출
테이블의 컬럼에 인덱스가 존재한다면 해당 인덱스에 엑세스하는 순간 인덱스로부터 ROWID가 제공된다.
ROWID는 하나의 데이터를 찾아가는 유일한 주소
인덱스를 이용하지 않고 테이블에 바로 엑세스한다면 FULL SCAN
CONNECT BY 절을 사용하면 BY USER ROWID 실행 계획
BY INDEX ROWID와 FULL SCAN이 주로 사용됨
-----------------------------
인덱스를 이용한 후에 테이블에 엑세스하면 BY INDEX ROWID 실행 계획이 생성된다.
인덱스에서 생성되는 실행 계획은 9가지
1. INDEX RANGE SCAN
2. INDEX UNIQUE SCAN
3. INDEX AND-EQUALS
4. INDEX FULL SCAN
5. INDEX FAST FULL SCAN
6. INDEX PARALLEL SCAN
7. INDEX SKIP SCAN
8. INDEX MIN/MAX SCAN
9. INDEX JOIN
-------------------------------
선분조건 LINE CONDITION 이 사용된 WHERE 조건의 컬럼이 인덱스를 이용할 경우 INDEX RANGE SCAN이 발생
점조건 POINT CONDITION 일지라도 인덱스를 UNIQUE 인덱스로 생성하지 않았다면 INDEX RANGE SCAN
값을 만족하는 데이터가 세 건이라면 실제 데이터 엑세스는 네 번 이루어진다.
-------------------------------
점 조건 중에서 = 조건을 사용하며 해당 조건에서 UNIQUE 인덱스를 이용하면 INDEX UNIQUE SCAN
UNIQUE 인덱스이더라도 점 조건이 아닌 선분 조건으로 조회된다면 INDEX RANGE SCAN
-------------------------------
보통의 경우 INDEX AND-EQUALS 실행 계획은 성능 최적화 대상이 될 수 있다.
8i에서 도입 10g 부터 폐기
INDEX AND-EQUALS 실행 계획은 두 개의 인덱스를 이용하여 원하는 데이터를 추출
두 컬럼의 인덱스를 추출하여 인덱스 머지를 수행
인덱스 머지
각 인덱스에서 조건을 만족하는 데이터의 ROWID를 확인한 후 1번 인덱스에서 조건을 만족하는 값을 찾으면 확인한 ROWID를 2번 인덱스에서 동일한 ROWID가 확인될때까지 찾는다. 2번 인덱스에서 값을 다 확인한 후 다시 1번 인덱스로 돌아가 다음 값이 조건을 만족하는지 확인한다. 그리고 반복한다.
결합 인덱스를 이용한다면 처리 범위가 감소할 수 있다.
INDEX AND-EQUALS 실행 계획이 빈번히 발생한다면 인덱스 선정을 다시 검토해야 한다.
--------------------------------
DB 실행계획에 대해 공부중이다.
공부한 내용을 요약하면서 다시 한번 상기중인데 양이 많다. 정말 많다.
아무든 계속.
덴마 1. 파마나의 개
DENMA THE QUANX
네이버에 연재되고 있는 웹툰이다.
연재된지는 꽤나 오래된 것 같은데 손이 잘 가지않아 안보고 있었다.
작가는 양영순 님이다.
누들누들부터 시작해 인기작품을 꽤나 많이 그리셨던 작가로 기억한다.
천일야화도 정말 재밌게 보았었다.
서론은 여기까지 하고.
QUANX, 퀑이라고 작품상에서 발음된다.
기존에 있던 단어인지 작가의 조어인지는 모르겠으나 작품상에서는 특이한 능력, 즉 초능력을 가지고 있는 사람은 퀑이라고 부른다.
사람이라고 단정짓기는 어렵겠다. 사람뿐만 아니라 여러 생명체가 나오고 이 중 초능력이 있는 자들의 통칭으로 퀑이라고 한다.
덴마도 역시 퀑이다. 덴마의 능력은 질량등가치환.
공간좌표만 확인되면 무엇이든 손에 들고있는 것의 질량만큼 맞바꿀 수 있다.
(얼핏봐도 정말 사기캐다;; 무궁무진하게 활용할 수 있는 능력인듯.)
덴마는 이 능력을 가지고 실버퀵이라는 택배회사(ㅋㅋ)에 직원으로 일하고 있다.
물론 본인이 택배회사를 선택한 것은 아니고 사기, 납치를 당해 본인의 몸이 아닌 다른 몸에 정신이 옮겨져 있다.
영혼이 옮겨진 것인지, 전뇌? 같은 설정으로 다른 육체를 사용하고 있는지는 잘 모르겠다.
아직 초반이라 전개된 내용은 잘 모르겠지만 에피소드 형식으로 진행되고 모든 에피소드를 관통하는 하나의 큰 흐름이 있는 듯 하다.
탄탄한 세계관이 구축되어 있고 2개정도의 에피소드만 봤지만 앞으로의 내용이 정말 흥미진진할 것 같다.
기대되는 웹툰.
에피소드 1. 파나마의 개의 명장면
이런 전개 완전 좋다.
아버지의 얼굴 표정의 흐름이 한눈에 보이면서 인생의 후회가 단 몇 마디에 압축되어있는 화면.
무뚝뚝했던 우리의 아버지들이 연상되는 그런 구도.
중언부언 길게 말할 수도 있겠지만 " 미안하다. 더... 더 행복해지려고 했는데... 잘 안됐어."
이 짧은 말이 진한 여운을 남긴다.
좋구나! 덴마. 앞으로 꾸준히 감상글을 남겨보겠다.
네이버에 연재되고 있는 웹툰이다.
연재된지는 꽤나 오래된 것 같은데 손이 잘 가지않아 안보고 있었다.
작가는 양영순 님이다.
누들누들부터 시작해 인기작품을 꽤나 많이 그리셨던 작가로 기억한다.
천일야화도 정말 재밌게 보았었다.
서론은 여기까지 하고.
QUANX, 퀑이라고 작품상에서 발음된다.
기존에 있던 단어인지 작가의 조어인지는 모르겠으나 작품상에서는 특이한 능력, 즉 초능력을 가지고 있는 사람은 퀑이라고 부른다.
사람이라고 단정짓기는 어렵겠다. 사람뿐만 아니라 여러 생명체가 나오고 이 중 초능력이 있는 자들의 통칭으로 퀑이라고 한다.
덴마도 역시 퀑이다. 덴마의 능력은 질량등가치환.
공간좌표만 확인되면 무엇이든 손에 들고있는 것의 질량만큼 맞바꿀 수 있다.
(얼핏봐도 정말 사기캐다;; 무궁무진하게 활용할 수 있는 능력인듯.)
덴마는 이 능력을 가지고 실버퀵이라는 택배회사(ㅋㅋ)에 직원으로 일하고 있다.
물론 본인이 택배회사를 선택한 것은 아니고 사기, 납치를 당해 본인의 몸이 아닌 다른 몸에 정신이 옮겨져 있다.
영혼이 옮겨진 것인지, 전뇌? 같은 설정으로 다른 육체를 사용하고 있는지는 잘 모르겠다.
아직 초반이라 전개된 내용은 잘 모르겠지만 에피소드 형식으로 진행되고 모든 에피소드를 관통하는 하나의 큰 흐름이 있는 듯 하다.
탄탄한 세계관이 구축되어 있고 2개정도의 에피소드만 봤지만 앞으로의 내용이 정말 흥미진진할 것 같다.
기대되는 웹툰.
에피소드 1. 파나마의 개의 명장면
이런 전개 완전 좋다.
아버지의 얼굴 표정의 흐름이 한눈에 보이면서 인생의 후회가 단 몇 마디에 압축되어있는 화면.
무뚝뚝했던 우리의 아버지들이 연상되는 그런 구도.
중언부언 길게 말할 수도 있겠지만 " 미안하다. 더... 더 행복해지려고 했는데... 잘 안됐어."
이 짧은 말이 진한 여운을 남긴다.
좋구나! 덴마. 앞으로 꾸준히 감상글을 남겨보겠다.
피드 구독하기:
글 (Atom)