[SQL튜닝]23.11.14_no_merge

망구씨·2023년 11월 14일

SQL 튜닝

목록 보기

4/9

✏️ 정규화

💡 정규화를 기본으로 하되 최후의 수단으로 반정규화 합니다.

✅ 정규화란

중복된 데이터가 테이블에 연속해서 발생하지 않도록 emp, dept를 분리하여 테이블로 구성했듯이 테이블을 성격에 맞춰서 분리하는 것을 말한다. emp테이블에는 사원에 대한 정보만 있고 dept에는 부서에 대한 정보만 있다. 데이터 중복이 안되게 하려고 분리를 했다.

분리를 하다보니 조인이 불가피해졌다!

✔️ select 문의 수행 단계(과정)
1. 파싱 ----------> SQL을 기계어로 변환하고 실행계획을 생성하는 것
2. 익스큐트
3. 패치

select e.ename, d.loc
  from e, dept d
  where e.deptno = d.deptno;
❓ 테이블 2개 조인을 하면 만들 수 있는 실행계획이 몇개가 될까?
1. 조인 순서 : 2가지
* emp -> dept
* dept -> emp
조인 방법 : 3가지
* nested loop 조인
* hash 조인
* sort merge 조인
❓ 총 6개의 실행계획을 옵티마이저를 만들고 가장 비용이 적게 드는 계획을 선택

테이블이 3개면?
조인 순서 : 3 ! = 3*2*1=6
조인 방법 : 3개
총 18개의 실행계획을 생성 / 테이블 4개면 72개, 5개면 360개.....
이중에서 제일 싼(?) 실행계획 하나만 선택하니까 파싱이 너무 느리다.

➡️ 너무 조인되는 SQL이 느리다고 한다면, 반정규화를 고려해보아야 한다.

✔️ 실행 계획의 종류 2가지

1. 예상 실행계획

explain plan for 
select ename, sal
  from emp
  where ename='SCOTT';
  
select * from table(dbms_xplan.display);

2. 실제 실행계획
: buffers의 갯수를 볼 수 있다. 튜닝 전/후를 이것으로 구분할 것임!

select /*+ gather_plan_statistics */ ename, sal
  from emp
  where ename='SCOTT';
  
SELECT * 
FROM TABLE(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST'));

✅ 반정규화란

다른 엔티티(테이블)에 있는 속성(컬럼)을 자신의 것으로 정의하는 것을 말한다.
ex) emp 테이블에 loc와 dname을 포함시키는 것이다.

실습1. 아래의 2가지 상황의 실제 실행계획을 보고 비교하기

1. 정규화 했을 때

select /*+ gather_plan_statistics */ e.ename, d.loc
  from emp e, dept d
  where e.deptno = d.deptno;

SELECT * 
FROM TABLE(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST')); 

----------------------------------------------------------------------------------------------------------------
| Id  | Operation          | Name | Starts | E-Rows | A-Rows |   A-Time   | Buffers |  OMem |  1Mem | Used-Mem |
----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |      1 |        |     14 |00:00:00.01 |       6 |       |       |          |
|*  1 |  HASH JOIN         |      |      1 |     14 |     14 |00:00:00.01 |       6 |   909K|   909K|  716K (0)|
|   2 |   TABLE ACCESS FULL| DEPT |      1 |      4 |      4 |00:00:00.01 |       3 |       |       |          |
|   3 |   TABLE ACCESS FULL| EMP  |      1 |     14 |     14 |00:00:00.01 |       3 |       |       |          |
----------------------------------------------------------------------------------------------------------------

2. 반정규화 했을 때
2-1 emp 테이블에 loc컬럼을 추가

alter table emp
 add loc varchar2(13);

2-2 emp 테이블에 추가한 loc컬럼의 값을 해당부서번호의 부서위치로 갱신
merge문 참고

merge into emp e
using dept d
on (e.deptno=d.deptno)
when matched then 
  update set e.loc=d.loc;
 
-- 반정규화를 했으므로 조인을 안해도 되고 아래와 같이 쿼리해도 된다.
select /*+ gather_plan_statistics */ ename, loc
  from emp ;

SELECT * 
FROM TABLE(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST')); 

------------------------------------------------------------------------------------
| Id  | Operation         | Name | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |      1 |        |     14 |00:00:00.01 |       3 |
|   1 |  TABLE ACCESS FULL| EMP  |      1 |     14 |     14 |00:00:00.01 |       3 |
------------------------------------------------------------------------------------

➡️ 버퍼의 갯수가 6개에서 3개로 줄어들었다!

문제 (반정규화) emp 테이블에 dname컬럼을 추가하고 merge문으로 해당 사원의 부서명으로 값을 갱신하기

desc dept;
-- dname 추가하기
alter table emp
 add dname varchar2(14);

-- merge문으로 값 갱신
merge into emp e
using dept d
on (e.deptno=d.deptno)
when matched then 
  update set e.dname=d.dname;

-- 반정규화를 했으므로 조인을 안해도 되고 아래와 같이 쿼리해도 된다.
select /*+ gather_plan_statistics */ ename, dname
  from emp ;

SELECT * 
FROM TABLE(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST'));

------------------------------------------------------------------------------------
| Id  | Operation         | Name | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |      1 |        |     14 |00:00:00.01 |       3 |
|   1 |  TABLE ACCESS FULL| EMP  |      1 |     14 |     14 |00:00:00.01 |       3 |
------------------------------------------------------------------------------------

✏️ 인덱스 설계

💡 primary제약과 unique 제약을 걸면 자동으로 인덱스가 생성이된다.

alter table emp
  add constraint emp_empno_pk primary key(empno);
✔️ 제약이 잘 생성되었는지 확인
select table_name, constraint_name
  from user_constraints
  where table_name='EMP';
✔️ 인덱스가 잘 생성되었는지 확인
select index_name, uniqueness
  from user_indexes
  where table_name='EMP';
➡️ 인덱스 이름이 제약 이름으로 생성이 된다.

✅ 회사에 DB의 오브젝트 들의 이름을 결정할 때 규칙이 있다. 이 규칙들을 따라야함

예) 테이블명은 8글자를 넘으면 안되고 이름마다 의미가 있어야함.
UEHBLDMT --->      UE        HB        LD        MT
                 전자금융   회사약어    회사약어   마스터테이블

✅ 인덱스 이름도 규칙이 있다!

UEHBLDIDX1 --->      UE        HB        LD        IDX번호

그런데 PK와 유니크 제약 같은 경우는 인덱스가 자동으로 생성되는데 인덱스 이름이 제약이름으로 생성되니까 메타 규칙에 맞지 않아서 감사때 지적이 될 수 있다. DBA가 제약 이름과 인덱스 이름을 서로 다르게 할 필요가 있음!!

제약 이름과 자동으로 생성되는 인덱스 이름을 다르게 설정해서 만들기

alter table emp
  add constraint emp_empno_pk primary key(empno);

alter table emp
  drop constraint emp_empno_pk;

alter table emp
  add constraint emp_empno_pk primary key(empno)
  using index (create unique index emp_idx1 on emp(empno));

문제 dept 테이블에 deptno에 primary key에 제약을 거는데, 자동으로 생성되는 인덱스 이름은 dept_idx1 라고 해서 생성되게 만들기

alter table dept
  add constraint dept_deptno_pk primary key(deptno)
  using index (create unique index dept_idx1 on dept(deptno));

-- 제약이름 확인
select table_name, constraint_name
from user_constraints
where table_name='DEPT';

# DEPT   DEPT_DEPTNO_PK

-- 인덱스 이름 확인
select index_name, uniqueness
from user_indexes
where table_name='DEPT';

# DEPT_IDX1	  UNIQUE

✏️ 뷰 사용시 장점과 단점

✔️ 장점

1. view 사용시 장점은 SQL 코드가 심플해진다.

-- salesman인 사원들만 모아 view를 생성
create view emp_salesman
as
  select empno, ename, job, mgr, hiredate, sal, comm, deptno
    from emp
    where job='SALESMAN';

-- 뷰를 사용 했을 때
select * 
 from emp_salesman
 where sal >= 1200;

-- 뷰를 사용 안했을 때
select empno, ename, job, mgr, hiredate, sal, comm, deptno
  from emp
  where job = 'SALESMAN' and sal >= 1200;

🚨 VEIW를 사용했을 때의 주의사항!
: 잘못된 실행계획을 유발할 수 있다.

✅ 아래의 조인문장을 작성하고 실행계획을 확인해보기

select /*+ gather_plan_statistics leading(d e) */ 
         e.empno, e.ename, e.job, e.mgr, e.sal, d.loc
  from emp_salesman e, dept d
  where e.deptno = d.deptno and e.sal >= 1500;

SELECT * 
FROM TABLE(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST'));

----------------------------------------------------------------------------------------------------------------
| Id  | Operation          | Name | Starts | E-Rows | A-Rows |   A-Time   | Buffers |  OMem |  1Mem | Used-Mem |
----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |      1 |        |      2 |00:00:00.01 |       6 |       |       |          |
|*  1 |  HASH JOIN         |      |      1 |      2 |      2 |00:00:00.01 |       6 |   909K|   909K|  712K (0)|
|   2 |   TABLE ACCESS FULL| DEPT |      1 |      4 |      4 |00:00:00.01 |       3 |       |       |          |
|*  3 |   TABLE ACCESS FULL| EMP  |      1 |      2 |      2 |00:00:00.01 |       3 |       |       |          |
----------------------------------------------------------------------------------------------------------------

➡️ leading(d e)라고 힌트를 주면 dept 먼저 드라이빙 하고 view를 드라이빙 해라 ! 라는 것이다. 그런데 지금 실행계획에는 emp_salesman 자체가 없고 emp만 보인다. 왜 안보이냐면 옵티마이저가 view를 해체하고 아래처럼 실행했다.

select /*+ gather_plan_statistics leading(d e) */ 
         e.empno, e.ename, e.job, e.mgr, e.sal, d.loc
  from emp e, dept d 
  where e.deptno = d.deptno and job = 'SALESMAN' and e.sal >= 1500;

💡 이렇게 잘못된 실행계획이 나올 수 있으므로 view를 해체하지 말라고 힌트를 주어야 한다.

select /*+ gather_plan_statistics no_merge(e) leading(d e) */ 
         e.empno, e.ename, e.job, e.mgr, e.sal, d.loc
  from emp_salesman e, dept d
  where e.deptno = d.deptno and e.sal >= 1500;

-------------------------------------------------------------------------------------------------------------------------
| Id  | Operation           | Name         | Starts | E-Rows | A-Rows |   A-Time   | Buffers |  OMem |  1Mem | Used-Mem |
-------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |              |      1 |        |      2 |00:00:00.01 |       6 |       |       |          |
|*  1 |  HASH JOIN          |              |      1 |      2 |      2 |00:00:00.01 |       6 |   909K|   909K|  721K (0)|
|   2 |   TABLE ACCESS FULL | DEPT         |      1 |      4 |      4 |00:00:00.01 |       3 |       |       |          |
|   3 |   VIEW              | EMP_SALESMAN |      1 |      2 |      2 |00:00:00.01 |       3 |       |       |          |
|*  4 |    TABLE ACCESS FULL| EMP          |      1 |      2 |      2 |00:00:00.01 |       3 |       |       |          |
-------------------------------------------------------------------------------------------------------------------------

➡️ no_merge 힌트는 뷰를 해체하지 말아라 라는 힌트이다!

✏️ SQL 실행 효율성

💡 평상시에 DBA는 DB에 성능이 느린지 확인을 해야한다. 확인할 때 주로 Active session (대기하는 세션)들이 무슨 이유로 대기하는지 그 대기 이벤트를 확인해야한다.
그 대기 이벤트 중에서 아래의 대기 이벤트가 출현하면 shared pool의 SQL이 공유되지 못하고 있다는 증거입니다.

latch : shared pool
latch : libary cache

➡️ 해결 방법 : SQL을 PL/SQL로 코딩하는 것을 권고하거나 PL/SQL 내에 리터럴 SQL 코딩이 있다면 바인드 변수로 변경하기를 강력하게 권고해야한다.

실습 owi.zip 을 모바텀으로 /home/oracle밑에 올리고 unzip으로 압축 풀기

✔️ 압축 풀기

$ unzip owi.zip
SYS>  @install
Elapsed: 00:00:00.00
Input data file name(for default tablespace  ex. c:\owi\owi01.dbf): /home/oracle/owi01.dbf
Package body created.

Elapsed: 00:00:00.01
11:55:53 PROD > show user
USER is "OWI"

✔️ 액티브 세션 보는 스크립트

SET LINESIZE 200
SET PAGESIZE 1000

COLUMN username FORMAT A20
COLUMN event FORMAT A30
COLUMN wait_class FORMAT A15

SELECT NVL(s.username, '(oracle)') AS username,
      s.sid,
      s.serial#,
      sw.event,
      sw.wait_class,
      sw.wait_time,
      sw.seconds_in_wait,
      sw.state
FROM   v$session_wait sw,
      v$session s
WHERE  s.sid = sw.sid
ORDER BY sw.seconds_in_wait DESC;

✔️ 스크립트 준비가 되면 돌려보기 shared_pool_latch

OWI> @exec
11:58:27 PROD > accept event_name char prompt 'Event name to simulate: '
Event name to simulate: shared_pool_latch

11:59:03 PROD > accept session_num number default 10 prompt 'Session count [10]: '
Session count [10]: 10
11:59:06 PROD > accept expired_type number default 1 prompt 'Expired by time(1) or looping count(2) [1]: '
Expired by time(1) or looping count(2) [1]: 1
11:59:08 PROD > accept interval number default 30 prompt 'Execution internval(sec or count) [30]: '
Execution internval(sec or count) [30]: 60
11:59:13 PROD > accept enable_trace number default 0 prompt 'Enable_trace (1=TRUE, 0=FALSE) [0]: '
Enable_trace (1=TRUE, 0=FALSE) [0]: 1
11:59:18 PROD > ACCEPT exec_method NUMBER DEFAULT 0 prompt 'Exec method(0=Oracle Job, 1=Unix Shell) [0]: '
Exec method(0=Oracle Job, 1=Unix Shell) [0]: 0
11:59:23 PROD > accept init_on_creation number default 1 prompt 'Init data(1=TRUE, 0=FALSE) [1]: '
Init data(1=TRUE, 0=FALSE) [1]: 1

문제 ADDM 레포트를 떠서 현재 db가 느린 이유와 해결책을 살펴보기

OWI> exec dbms_workload_repository.create_snapshot;
OWI> @?/rdbms/admin/addmrpt.sql

Summary of Findings
-------------------
   Description                      Active Sessions      Recommendations
                                    Percent of Activity
   -------------------------------  -------------------  ---------------
1  PL/SQL Execution                 .27 | 42.86          1
2  Soft Parse                       .24 | 38.27          2
3  Hard Parse Due to Literal Usage  .11 | 17.15          1
4  Latch Free Waits                 .03 | 4.79           0
5  CPU Usage                        .02 | 3.49           1

Finding 3: Hard Parse Due to Literal Usage
Impact is .11 active sessions, 17.15% of total activity.
--------------------------------------------------------
SQL statements were not shared due to the usage of literals. This resulted in
additional hard parses which were consuming significant database time.

   Recommendation 1: Application Analysis
   Estimated benefit is .11 active sessions, 17.15% of total activity.
   -------------------------------------------------------------------
   Action
      Investigate application logic for possible use of bind variables instead
      of literals. ★ 리터럴 변수 대신 바인드 변수를 써라.
   Action
      Alternatively, you may set the parameter "cursor_sharing" to "force".
      ★ cursor_sharing를 force로 바꿔라
   Rationale
      At least 27 SQL statements with FORCE_MATCHING_SIGNATURE
      17109837705936771014 and PLAN_HASH_VALUE 3909286317 were found to be
      using literals. Look in V$SQL for examples of such SQL statements.

   Symptoms That Led to the Finding:
   ---------------------------------
      Hard parsing of SQL statements was consuming significant database time.
      Impact is .11 active sessions, 17.16% of total activity.
         Contention for latches related to the shared pool was consuming
         significant database time.
         Impact is .09 active sessions, 14.36% of total activity.
            Wait class "Concurrency" was consuming significant database time.
            Impact is .09 active sessions, 14.36% of total activity.

점심시간 문제 cursor_sharing를 force로 바꾸기

12:10:09 PROD > alter system set cursor_sharing=force
12:10:37 PROD > show parameter cursor_sharing

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
cursor_sharing                       string      FORCE

✏️ 커서 공유를 위한 SQL 작성

💡 Shared pool에서 공유가 되는 똑같은 SQL이란 무엇인가?

대소문자 구분
select ename, sal from emp where empno = 7788;
SELECT ENAME, SAL FROM EMP WHRER EMPNO = 7788;
공백과 들여쓰기도 구분
select ename, sal from emp where empno = 7788;
select    ename,      sal   from   emp  where empno = 7788;
리터럴 SQL을 구분
: 가급적 SQL을 PL/SQL로 코딩을하고 리터럴 SQL은 바인드 변수로 변경해서 코딩을 하게끔 해야 latch : shared pool이 발생하지 않는다.
select ename, sal from emp where empno = 7788;
select ename, sal from emp where empno = 7902;
sql문장

실행계획

파스트리
이렇게 3개가 파싱 결과물인데 이것을 shared pool에 올린다.

✅ 소프트 파싱과 하드 파싱의 차이?
소프트 파싱은 수행하는 SQL과 똑같은 SQL을 공유풀에서 찾아서 파싱과정을 생략하는 것이고 하드파싱은 찾지 못해서 다시 파싱하는 것을 말한다.

📖 3장. 옵티마이저 소개

💡 오라클 옵티마이저가 어떤 역할?
💡 오라클 옵티마이저저가 실행계획을 만드는 단계

✏️ SQL문

⭐ 오라클 인스턴스의 메모리는 SGA, PGA로 구성되어 있다.

SQL문의 처리과정

select empno, ename
 from emp
 where empn=7788;

1. parsing :
구문 분석 : SQL 문법이 오류가 없는지 검사
의미 확인 : emp테이블에  db가 존재하는테이블임
권한 확인 : emp테이블을 select 할 수 있는 권한이 있는지 확인
★ 이 SQL을 위해 PGA영역 공간 확보를 한다.
➡️ 똑같은 SQL이 공유풀에 있으면 바로 실행(소프트파싱)하고 없으면 파싱을 해서 공유풀에 올린다. (하드파싱) 이때 latch를 잡는데, latch는 shared pool latch이다. 잡아야 파싱한 결과물 3가지를 올릴 수 있다.
2. execute :
데이터를 buffer cache에서 찾고 없으면 datafile에서 찾아서 복사본을 버퍼캐시에 올린다.
3. fetch :
찾은 data를 서버프로세서가 유저프로세서에게 전달하는 것이다.

✏️ 옵티마이저가 필요한 이유

💡 계획을 도출하는 것이 옵티마이저이다. 인덱스 스캔과 풀테이블 스캔 중에 더 빠른것을 결정하는것이 옵티마이저의 역할이다!

select * from emp where job = 'MANAGER';

➡️ job에 인덱스가 있다면 full table scan,index range scan 를 할 수 있는데 2개의 실행계획중에 어떤것을 선택하냐면, 가장 비용이 적게 드는 것을 선택한다. 에를들어 job이 manager인 사원이 전체 사원수의 1명이다 라고 한다면 full table scan보다 index range scan이 비용이 적게 들고, job이 manager인 사원이 14명중에 13명이다 라고 하면 인덱스 스캔 보다 풀테이블 스캔이 비용이 더 적게 든다!

job이 manager인 사원이 몇명있는지 알아야하는데 그것을 알아내기 위해 옵티마이저가 테이블 통계정보를 봅니다. 그래서 DBA가 테이블 통계정보를 수집해줘야 한다!!!

실습1.

@demobld

위 스크립트 돌리고 job이 PRESIDNT 가 아닌 사원들은 전부 직업을 매니저로 업데이트 한다.

16:24:30 PROD > update emp
16:24:35   2  set job='MANAGER'
16:24:43   3  where job!='PRESIDENT';
commit;

job에 익덱스를 생성

create index emp_job on emp(job);

emp 테이블의 테이블 통계정보를 수집한다.

exec dbms_stats.gather_table_stats('SCOTT', 'EMP');

아래의 2개의 SQL을 실행계획을 확인하고 실행계획이 책처럼 정말 각각 나르게 나오는지 확인

explian plan for
select * from emp where job='PRESIDENT';
select * from table(dbms_xplan.display); 

explian plan for
select * from emp where job='MANAGER';
select * from table(dbms_xplan.display);

실제 실행 계획

select /*+ gather_plan_statistics */ *
 from emp
 where job='MANAGER';

SELECT * 
FROM TABLE(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST'));

------------------------------------------------------------------------------------
| Id  | Operation         | Name | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |      1 |        |     13 |00:00:00.01 |       3 |
|*  1 |  TABLE ACCESS FULL| EMP  |      1 |     13 |     13 |00:00:00.01 |       3 |
------------------------------------------------------------------------------------

select /*+ gather_plan_statistics */ *
 from emp
 where job='PRESIDENT';

 SELECT * 
FROM TABLE(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST'));

오늘의 마지막 문제 emp 테이블의 건수를 10000건 이상 강제로 늘리고, job이 PRESIDENT는 1명만 두고 나머지는 전부 MANAGER로 변경하기. 그리고 위 테스트 다시 하기

emp 테이블 건수를 10000건이상 늘리기

insert into emp
 select *  
  from emp;

PROD > select rowid from emp
        where rownum < 2;

ROWID
------------------
AAADM4AABAAAHcpAAA

1건빼고 모두 MANAGER로 변경

update emp
 set job='MANAGER';

update emp
 set job='PRESIDENT'
 where rowid='AAADM4AABAAAHcpAAA';

commit;

➡️ 이런 극단적인 데이터의 경우는 그냥 통계정보를 수집하면 안되고, 히스토그램 통계정보를 수집해주어야 한다.

--아까 수업때 바꿔놓은 force 원래대로 되돌림
alter system set cursor_sharing=exact;

-- 통계정보 수집
exec dbms_stats.gather_table_stats('SCOTT','EMP', method_opt => 'for all columns size skewonly');
or
analyze table emp compute statistics for columns job;

실제 실행 계획

select /*+ gather_plan_statistics */ count(*) 
 from emp
 where job='MANAGER';

SELECT * 
FROM TABLE(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST'));

-------------------------------------------------------------------------------------------
| Id  | Operation             | Name    | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
-------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT      |         |      1 |        |      1 |00:00:00.01 |    1052 |
|   1 |  SORT AGGREGATE       |         |      1 |      1 |      1 |00:00:00.01 |    1052 |
|*  2 |   INDEX FAST FULL SCAN| EMP_JOB |      1 |  28671 |  28671 |00:00:00.06 |    1052 |
-------------------------------------------------------------------------------------------

select /*+ gather_plan_statistics */ count(*)
 from emp
 where job='PRESIDENT';

 SELECT * 
FROM TABLE(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST'));
---------------------------------------------------------------------------------------
| Id  | Operation         | Name    | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |         |      1 |        |      1 |00:00:00.01 |      47 |
|   1 |  SORT AGGREGATE   |         |      1 |      1 |      1 |00:00:00.01 |      47 |
|*  2 |   INDEX RANGE SCAN| EMP_JOB |      1 |      1 |      1 |00:00:00.01 |      47 |
---------------------------------------------------------------------------------------

다시실습

t table 생성

create table t
           as
           select decode(rownum,1,1,99) ID,
                  all_objects.*
             from all_objects;

인덱스 생성

create index t_idx on t (id);

통계정보 확인

set autotrace traceonly explain
select * from t where id= 1;

-------------------------------------------------------------------------------
| Id  | Operation                   | Name  | Rows | Bytes | Cost (%CPU)| Time
-------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |       |    1 |   171 |     2   (0)| 00:00
:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T     |    1 |   171 |     2   (0)| 00:00
:01 |
|*  2 |   INDEX RANGE SCAN          | T_IDX |    1 |       |     1   (0)| 00:00
:01 |
-------------------------------------------------------------------------------

PROD > select * from t where id=99;

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      | 13447 |  2245K|    47   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| T    | 13447 |  2245K|    47   (0)| 00:00:01 |
--------------------------------------------------------------------------

망구씨

Slow and steady wins the race.

이전 포스트

[SQL튜닝]23.11.13_튜닝 툴,MVIEW,SQL trace

다음 포스트