| https://cafe.naver.com/sqlpd/71143?tc=shared_link https://bae9086.tistory.com/561 |
실기1
2번
실행계획 순서
인덱스스캔 t1_x1 (A-row 10000)
->테이블액세스 t1 (A-row 1000)
답
인덱스 컬럼 추가
3번
조건(인덱스는 단편화X)
버퍼1000건, 테이블 액세스후 버퍼 1010건
답
인덱스 컬럼 순서 변경
4번
인덱스스캔->테이블액세스 방향이었음
버퍼10 테이블액세스후 버퍼1000
답
테이블 재구성(클러스터링 팩터 초기화)
5번
실행계획 순서 (로컬인덱스 사용 -> 테이블 액세스 -> partirion range all 범위(1~1000) )
partirion range all 범위(1~1000)
테이블 액세스
로컬 인덱스 t1_x1 사용
답
로컬인덱스 엑세스 했으나 전체 파티션을 엑세스하므로, 조건절에는 파티션키가 없음을 유추할 수 있습니다.
(조건절에 파티션키가 있었다면 파티션 레인지 싱글 혹은 이터레이터가 뜹니다.)
인덱스에 파티션키 추가보단 논파티션인덱스가 맞지 않나 싶습니다.
Execution Plan
--------------------------------------------------------------------------------
0 SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=11 Card=22 Bytes=304K)
1 0 UNION-ALL
2 1 PARTITION RANGE (ITERATOR) (Cost=4 Card=11 Bytes=506)
3 2 TABLE ACCESS (BY LOCAL INDEX ROWID BATCHED) OF T1 (TABLE) (Cost=4 Card=11 Bytes=506)
4 3 INDEX (RANGE SCAN) OF IDX1 (INDEX) (Cost=1 Card=1K)
5 1 PARTITION RANGE (ALL) (Cost=7 Card=11 Bytes=506)
6 5 TABLE ACCESS (BY LOCAL INDEX ROWID BATCHED) OF T1 (TABLE) (Cost=7 Card=11 Bytes=506)
7 6 INDEX (RANGE SCAN) OF IDX1 (INDEX) (Cost=7 Card=6K)
위가 파티션키가 있을 때, 아래가 파티션키가 없을 때 이며 둘 다 인덱스에 파티션키 미포함입니다.
조건절에 파티션키가 있다면 인덱스에 파티션키 포함여부와 관계없이 플랜에 파티션 레인지 올이 뜨지 않습니다.
위에 플랜 확인하면 답 나오고요.
프리픽스나 논프리픽스 관계없이, 해당 플랜의 쿼리는 조건절에 파티션키가 없음을 유추할 수 잇고,
그래서 인덱스를 논파티션으로 바꿔야한다는겁니다.
==================================================================================
1번
5문제가 안에 있었고 실행계획을 보고 문제점과 개선점을 각각 적으시오 스타일의 문제
실행계획은 기본적으로는 실제 쿼리를 돌려서 뽑았지만, 문제를 복기하면서 좀 숫자들을 수정한거라 잘 안맞을 수도 있습니다. 문제가 요구하는 것은 수정되어있으니 참고하세요.
1)
--------------------------------------------------
| Id | Operation | Name | Rows | Bytes |
--------------------------------------------------
| 0 | SELECT STATEMENT | | 14 | 100k
| 1 | TABLE ACCESS FULL| EMP | 14 | 100k
--------------------------------------------------문제점 :
Table Full Scan 으로 14 Rows 결과조회 100k 사용으로 비효율
개선점
EMP의 인덱스를 생성해주어 index scan이 발생되게 하자
답
인덱스 스캔을 유도하기 위한 신규 인덱스 생성
2)
-----------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |
-----------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 100 | 532
| 1 | TABLE ACCESS BY INDEX ROWID BATCHED| EMP | 100 | 532
|* 2 | INDEX RANGE SCAN | EMP_X01 | 1000 |
-----------------------------------------------------------------------인덱스가 있지만 효율이 안좋음. (1000건 탐색 후 결국엔 테이블에서 100건만 읽음)
개선점 :
조건절 컬럼을 인덱스에 추가를 하여 인덱스효율 높이기
3)
-----------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |
-----------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 2k | 1010
| 1 | TABLE ACCESS BY INDEX ROWID BATCHED| EMP | 2k | 1010
|* 2 | INDEX RANGE SCAN | EMP_X03 | 2k | 1000
-----------------------------------------------------------------------
문제점 :
인덱스는 효율이 좋음 (2k 건 중에 2k건 다 읽음)
but bytes수가 높음.
개선점 : 더 조사 하자
컬럼 순서 조정
4)
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 2k | 1000 |
| 1 | TABLE ACCESS BY INDEX ROWID BATCHED| EMP | 2k | 1000 |
|* 2 | INDEX RANGE SCAN | EMP_X03 | 2k | 10 |
--------------------------------------------------------------------------인덱스는 효율 좋음. 컬럼순서도 좋음. but 램덤 액세스로 테이블을 찾아가는데 990bytes 소요됨.
테이블 블록의 클러스터링 팩터가 좋지않음을 알 수있으며(이부분을 도출해내고 생각해내는게 개인적으로 까다로웠음)
개선점 :
테이블 리오그를 통한 재구축
5)
EMP_PART_X2는 local partition index
--------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Pstart| Pstop |
--------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 87 | | |
| 1 | PARTITION RANGE ALL | | 1 | 87 | 1 | 10 |
| 2 | TABLE ACCESS BY LOCAL INDEX ROWID BATCHED| EMP_PART | 1 | 87 | 1 | 10 |
|* 3 | INDEX RANGE SCAN | EMP_PART_X2 | 1 | | 1 | 10 |
--------------------------------------------------------------------------------------------------문제점 :
local partition index를 사용하였으나 효율이 좋지 못함. (partition range all)
위의 실행계획만 보았을때는
1) 조건절에 파티션키 컬럼 없이 로컬파티션 인덱스를 사용하였을수도 있고,
2) 조건절에 파티션키 컬럼이 있으나 조건이 single이나 iterator를 사용할 수 없게 되어 있을수도 있습니다.
개선점 :
무엇이든 간에 로컬파티션인덱스의 효율이 현재 쿼리에서는 좋지않은것으로 보이고 쿼리수정으로 풀이하는 문제가 아니기 때문에 해당 인덱스 drop 후 비파티션 인덱스를 사용하기가 적절한것으로 보입니다.
--------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
--------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 87 | 0 (0)| 00:00:01 | | |
| 1 | TABLE ACCESS BY GLOBAL INDEX ROWID BATCHED| EMP_PART | 1 | 87 | 0 (0)| 00:00:01 | ROWID | ROWID |
|* 2 | INDEX RANGE SCAN | EMP_PART_X4 | 1 | | 0 (0)| 00:00:01 | | |
--------------------------------------------------------------------------------------------------------------------------
'02. SQLP 스터디 > 03. 기출' 카테고리의 다른 글
| SQLP 49-1 (0) | 2025.04.06 |
|---|---|
| SQLP 50회 -2 (0) | 2025.04.06 |
| SQLP -51회 (0) | 2025.04.02 |
| SQLP -51회 (0) | 2025.03.31 |
| SQLP 52회 -2 (0) | 2025.03.28 |
