oracle SPM

Oacle 9i, 10g, 11g 실행 계획 의 고정 은 Oacle 의 마음의 병 중 하나 입 니 다. CBO 가 강하 지만 10g 에서 우 리 는 아 울 렛 으로 sql 을 도입 합 니 다.profile, 11g 에 sqlprofile, sql 도입plan_baseline 1 관련 매개 변수 optimizercapture_sql_plan_baselines 기본 값 false, 즉 자동 포획 optimizer 를 사용 하지 않 습 니 다.use_sql_plan_baselines 기본 값 true, 즉 dba 우선 사용sql_plan_baselines 의 실행 계획;2 기본 매개 변수 테스트 는 SQL 이 간단 합 니 다: select * from hr. emp where EMPLOYEEID=206; 이 표 는 색인 이 없고 메 인 키 가 없 으 며 가장 일반적인 시계 실행 계획 입 니 다. 걱정 이 없습니다. 전체 시계 스 캔:

  SQL> select* from table(dbms_xplan.display_cursor('76rrg3a06j24n',0)); 
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
SQL_ID  76rrg3a06j24n, child number 0
-------------------------------------
select * from hr.emp where EMPLOYEE_ID=206
Plan hash value: 3956160932
--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |       |       |     2 (100)|          |
|*  1 |  TABLE ACCESS FULL| EMP  |     1 |   133 |     2   (0)| 00:00:01 |
--------------------------------------------------------------------------

기본 라인 만 들 기:

declare
v_ret  varchar2(100);
begin
v_ret := dbms_spm.load_plans_from_cursor_cache(sql_id=>'76rrg3a06j24n');
end;

검사 기준:

select sql_handle,sql_text,origin,version,enabled,accepted,fixed from dba_sql_plan_baselines
SQL_HANDLE  SQL_TEXT           ORIGIN                   VERSION  ENABLED    ACCEPTED    FIXED
SQL_4313a2ffff308f08      MANUAL-LOAD 11.2.0.4.0      YES      YES            NO

색인 만 들 기: create index i_employee_id on hr.emp(employee_Id); 다시 실행, child 검사number:

select sql_id,child_number,sql_text ,child_Number from v$sql where sql_text like 'select %hr.emp%';
SQL_ID  CHILD_NUMBER    SQL_TEXT    CHILD_NUMBER
76rrg3a06j24n   1   select * from hr.emp where EMPLOYEE_ID=206  1

실행 계획 보기:

Plan hash value: 3956160932 
--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     2 |   266 |     2   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| EMP  |     2 |   266 |     2   (0)| 00:00:01 |
-------------------------------------------------------------------------- 
Predicate Information (identified by operation id):
--------------------------------------------------- 
   1 - filter("EMPLOYEE_ID"=206) 
Note
-----
   - SQL plan baseline "SQL_PLAN_464x2zzzm13s8d8a279cc" used for this statement

여전히 전체 표 스 캔, 이것 은 비 과학적 이 고 이론 적 으로 색인 을 걷 는 것 입 니 다. 그 는 설명 을 했 습 니 다. 가 는 것 은 SQL 입 니 다.PLAN_464 x2zzzm13s8d8a279cc, 검사 dbasql_plan_baselines

                 SQL_HANDLE SQL_TEXT    ORIGIN             VERSION  ENABLED ACCEPTED    FIXED   PLAN_NAME
SQL_4313a2ffff308f08      MANUAL-LOAD 11.2.0.4.0  YES YES NO  SQL_PLAN_464x2zzzm13s8d8a279cc
SQL_4313a2ffff308f08      AUTO-CAPTURE    11.2.0.4.0  YES NO  NO  SQL_PLAN_464x2zzzm13s8f5e7e8ee

여기 서 사실 그 는 다른 실행 계획 을 포착 했다. 그러나 사용 하지 않 았 기 때문에 전체 표 스 캔 을 통 해 새로운 실행 계획 을 사용 했다.

declare
tp clob;
begin
tp:=dbms_spm.evolve_sql_plan_baseline(sql_handle=>'SQL_4313a2ffff308f08',plan_name=>'SQL_PLAN_464x2zzzm13s8f5e7e8ee');
end;

다시 실행:

Plan hash value: 1162342648

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

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("EMPLOYEE_ID"=206)

Note
-----
   - dynamic sampling used for this statement (level=2)
   - SQL plan baseline "SQL_PLAN_464x2zzzm13s8f5e7e8ee" used for this statement

자, 정상 적 인 실행 계획 을 세 웠 습 니 다. 좋 은 base 를 다시 삭제 하 겠 습 니 다.line:

declare v_ret  varchar2(100);
begin
  v_ret:= dbms_spm.drop_sql_plan_baseline(sql_handle=>'SQL_4313a2ffff308f08',plan_name=>'SQL_PLAN_464x2zzzm13s8f5e7e8ee');
  end  ;

의심 할 여지없이, 또 시계 전 체 를 스 캔 했 지만, dbahist_sql_plan_baselines 에 서 는 여전히 생 성 되 어 있 습 니 다. 사용 하지 않 았 을 뿐 입 니 다.상태 수정:

declare
v_ret  varchar2(100);
begin
v_ret := dbms_spm.alter_sql_plan_baseline(
sql_handle=>'SQL_4313a2ffff308f08',
plan_name=>'SQL_PLAN_464x2zzzm13s8d8a279cc',
attribute_name=>'enabled',
attribute_value=>'NO'
);
end;

실행 계획 을 보 려 면 둘 다 사용 하지 않 았 습 니 다. 이것 은 변 경 된 인자 (optimizer use sql plan baselines = false) 와 같 습 니 다: Execution Plan

----------------------------------------------------------
Plan hash value: 1162342648 
---------------------------------------------------------------------------------------------
| Id  | Operation                   | Name          | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |               |     1 |   133 |     2   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| EMP           |     1 |   133 |     2   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | I_EMPLOYEE_ID |     1 |       |     1   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------- 
Predicate Information (identified by operation id):
--------------------------------------------------- 
   2 - access("EMPLOYEE_ID"=206) 
Note
-----
   - dynamic sampling used for this statement (level=2)