Oracle 하 드 해석 과 소프트 해석 의 차이 분석
Oracle 하 드 해석 과 소프트 해석 은 우리 가 자주 겪 는 문제 이기 때문에 언제 소프트 해석 이 발생 하고 언제 하 드 해석 이 발생 하 는 지,어떻게 판단 하 는 지 고려 해 야 합 니 다.
SQL 실행 과정
SQL 이나 PL/SQL 명령 을 발표 할 때 Oracle 은 이 명령 이 공유 탱크 에 존재 하 는 지 여 부 를 자동 으로 찾 아 현재 문 구 를 하 드 해석 이나 소프트 해석 으로 결정 합 니 다.
일반적인 상황 에서 SQL 문장의 실행 과정 은 다음 과 같다.
Step 1.SQL 코드 의 문법(문법 적 정확성)과 의미 검사(대상 의 존재 성과 권한).
Step 2.SQL 코드 의 텍스트 를 해시 값 으로 가 져 옵 니 다.
Step 3.공유 탱크 에 같은 해시 값 이 존재 한다 면 이 명령 에 대해 소프트 해석 여 부 를 판단 하고 그렇지 않 으 면 e 단계 로 갑 니 다.
Step 4.같은 해시 값 이 존재 하 는 새 명령 행 에 대해 서 는 존재 하 는 명령 행 의 텍스트 와 각각 비교 합 니 다.
이 비 교 는 대소 문자,문자열 일치 여부,빈 칸,주석 등 을 포함 하 며,일치 하면 부 드 러 운 해석 을 하고,단계 6 으로 넘 어가 서 다시 억지로 해석 할 필요 가 없다.
아니면 스텝 5 까지.
Step 5.하 드 해석,실행 계획 생 성.
Step 6.SQL 코드 를 실행 하고 결 과 를 되 돌려 줍 니 다.
소프트 해석
1.아래 세 개의 검색 어 는 같은 공유 SQL 구역 을 사용 할 수 없습니다.조 회 된 테이블 대상 이 대소 문 자 를 사 용 했 음 에 도 불구 하고 오 라 클 은 서로 다른 실행 계획 을 세 웠 다
select * from emp;
select * from Emp;
select * from EMP;
select * from emp where empno=7369
select * from emp where empno=7788
sys@ASMDB> select owner,table_name from dba_tables where table_name like 'TB_OBJ%';
OWNER TABLE_NAME
------------------------------ ------------------------------
USR1 TB_OBJ -- ，
SCOTT TB_OBJ
usr1@ASMDB> select * from tb_obj;
scott@ASMDB> select * from tb_obj; --
하 드 해석 은 전체 SQL 문장의 실행 에 완전한 해석 이 필요 하고 실행 계획 을 생 성 해 야 한 다 는 것 이다.하 드 분석,실행 계획 생 성 은 CPU 자원 과 SGA 자원 을 소모 해 야 합 니 다.라 이브 러 리 캐 시 에 빗장 을 걸 어야 합 니 다.빗장 은 자물쇠 의 세분 화로 경량급 직렬 화 장치 로 이해 할 수 있다.프로 세 스 가 빗장 을 신청 하면 공유 메모 리 를 보호 하 는 데 사용 되 는 빗장 은 같은 시간 에 두 개 이상 의 프로 세 스 에 의 해 수정 되 지 않 습 니 다.하 드 해석 시 빗장 사용 을 신청 해 야 하고 빗장 의 수량 은 제 한 된 상황 에서 기 다 려 야 한다.대량의 빗장 사용 으로 인해 빗장 을 사용 해 야 하 는 프로 세 스 가 줄 을 서 는 것 이 빈번 할 수록 성능 이 떨어진다.
1.위의 두 가지 상황 을 보 여 드 리 겠 습 니 다.
두 개의 서로 다른 session 에서 완성 되 었 습 니 다.하 나 는 sys 계 정 인 session 이 고 하 나 는 scott 계 정 인 session 입 니 다.다른 session 입 니 다.SQL 명령 행 은 서로 다른 계 정 이름 으로 시작 합 니 다.
예 를 들 어"sys@ASMDB" 사용 시 sys 계 정의 session,"scott@ASMDB>"scott 계 정의 session 을 표시 합 니 다.
sys@ASMDB> select name,class,value from v$sysstat where statistic#=331;
NAME CLASS VALUE
-------------------- ---------- ---------- -- 569
parse count (hard) 64 569
scott@ASMDB> select * from emp;
sys@ASMDB> select name,class,value from v$sysstat where statistic#=331;
NAME CLASS VALUE
-------------------- ---------- ---------- -- 570，
parse count (hard) 64 570
scott@ASMDB> select * from Emp;
sys@ASMDB> select name,class,value from v$sysstat where statistic#=331;
NAME CLASS VALUE
-------------------- ---------- ---------- -- 571
parse count (hard) 64 571
scott@ASMDB> select * from EMP;
sys@ASMDB> select name,class,value from v$sysstat where statistic#=331;
NAME CLASS VALUE
-------------------- ---------- ---------- -- 572
parse count (hard) 64 572
scott@ASMDB> select * from emp where empno=7369;
sys@ASMDB> select name,class,value from v$sysstat where statistic#=331;
NAME CLASS VALUE
-------------------- ---------- ---------- -- 573
parse count (hard) 64 573
scott@ASMDB> select * from emp where empno=7788; -- empno=7369， ， 7788@20130905
sys@ASMDB> select name,class,value from v$sysstat where statistic#=331;
NAME CLASS VALUE
-------------------- ---------- ---------- -- 574
parse count (hard) 64 574
4.하 드 해석 개선-동적 문장 사용
1.매개 변수 cursor 변경sharing
매개 변수 커서sharing 은 어떤 종류의 SQL 이 같은 SQL area 를 사용 할 수 있 는 지 결정 합 니 다.
CURSOR_SHARING = { SIMILAR | EXACT | FORCE }
EXACT --발 표 된 SQL 문장 이 캐 시 에 있 는 문장 과 완전히 같 을 때 만 기 존 실행 계획 을 사용 합 니 다.
FORCE --만약 에 SQL 문장 이 글자 의 양 이 라면 Optimizer 는 기 존의 실행 계획 을 계속 사용 하도록 합 니 다.기 존의 실행 계획 이 가장 좋 든 안 좋 든 간 에.
SIMILAR --SQL 문 구 는 글자 의 양 이 라면 기 존 실행 계획 이 가장 좋 을 때 만 사용 합 니 다.실행 계획 이 가장 좋 지 않 으 면 이 SQL 을 다시 사용 합 니 다.
--문 구 를 분석 하여 최 적 집행 계획 을 세우다.
ALTER SESSION,ALTER SYSTEM 과 같은 다양한 단 계 를 기반 으로 이 인 자 를 설정 할 수 있 습 니 다.
sys@ASMDB> show parameter cursor_shar -- cursor_sharing
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
cursor_sharing string EXACT
sys@ASMDB> alter system set cursor_sharing='similar'; -- cursor_sharing similar
sys@ASMDB> select name,class,value from v$sysstat where statistic#=331;
NAME CLASS VALUE
-------------------- ---------- ---------- -- 865
parse count (hard) 64 865
scott@ASMDB> select * from dept where deptno=10;
sys@ASMDB> select name,class,value from v$sysstat where statistic#=331;
NAME CLASS VALUE
-------------------- ---------- ---------- -- SQL ， 866
parse count (hard) 64 866
scott@ASMDB> select * from dept where deptno=20;
sys@ASMDB> select name,class,value from v$sysstat where statistic#=331;
NAME CLASS VALUE
-------------------- ---------- ---------- -- SQL ， 866
parse count (hard) 64 866
sys@ASMDB> select sql_text,child_number from v$sql -- SQL_TEXT :"SYS_B_0"
where sql_text like 'select * from dept where deptno%';
SQL_TEXT CHILD_NUMBE
-------------------------------------------------- ------------
select * from dept where deptno=:"SYS_B_0" 0
sys@ASMDB> alter system set cursor_sharing='exact'; -- cursor_sharing exact
-- scott session deptno=40 sql_text， cursor_sharing exact ，
-- v$sql
sys@ASMDB> select sql_text,child_number from v$sql
where sql_text like 'select * from dept where deptno%';
SQL_TEXT CHILD_NUMBER
-------------------------------------------------- ------------
select * from dept where deptno=50 0
select * from dept where deptno=40 0
select * from dept where deptno=:"SYS_B_0" 0
2.바 인 딩 변 수 를 사용 하 는 방식
바 인 딩 변 수 는 변수 이름,데이터 형식 과 길이 가 일치 해 야 합 니 다.그렇지 않 으 면 소프트 분석 을 사용 할 수 없습니다.
(1).바 인 딩 변수(bid variable)는 DML 구문 에서 대체 자 를 사용 하 는 것 을 말 합 니 다.즉,콜론 뒤에 변수 이름 을 바짝 따 르 는 형식 입 니 다.다음 과 같 습 니 다.
select * from emp where empno=7788 --바 인 딩 변수 사용 하지 않 음
select * from emp where empono=:eno --:eno 는 바 인 딩 변수 입 니 다.
두 번 째 조회 에서 변수 값 은 조회 가 실 행 될 때 제 공 됩 니 다.이 조 회 는 한 번 만 컴 파일 한 다음 에 이 조회 계획 을 나중에 가 져 오고 다시 사용 할 수 있 도록 공유 탱크(라 이브 러 리 캐 시)에 저장 합 니 다.
(2).아래 에 바 인 딩 변 수 를 사 용 했 지만 두 변 수 는 실질 적 으로 다 릅 니 다.이런 상황 에 대해 똑 같이 하 드 분석 을 사용 합 니 다.
select * from emp where empno=:eno;
select * from emp where empno=:emp_no
바 인 딩 변 수 를 사용 할 때 서로 다른 세 션 에 같은 답장 환경 과 유 틸 리 티 규칙 등 을 사용 하도록 요구 합 니 다.
scott@ASMDB> create table tb_test(col int); -- tb_test
scott@ASMDB> create or replace procedure proc1 -- proc1
as
begin
for i in 1..10000
loop
execute immediate 'insert into tb_test values(:n)' using i;
end loop;
end;
/
Procedure created.
scott@ASMDB> create or replace procedure proc2 -- proc2， ， SQL
as
begin
for i in 1..10000
loop
execute immediate 'insert into tb_test values('||i||')';
end loop;
end;
/
Procedure created.
scott@ASMDB> exec runstats_pkg.rs_start
PL/SQL procedure successfully completed.
scott@ASMDB> exec proc1;
PL/SQL procedure successfully completed.
scott@ASMDB> exec runstats_pkg.rs_middle;
PL/SQL procedure successfully completed.
scott@ASMDB> exec proc2;
PL/SQL procedure successfully completed.
scott@ASMDB> exec runstats_pkg.rs_stop(1000);
Run1 ran in 1769 hsecs
Run2 ran in 12243 hsecs --run2 run1 /1769≈
run 1 ran in 14.45% of the time
Name Run1 Run2 Diff
LATCH.SQL memory manager worka 410 2,694 2,284
LATCH.session allocation 532 8,912 8,380
LATCH.simulator lru latch 33 9,371 9,338
LATCH.simulator hash latch 51 9,398 9,347
STAT...enqueue requests 31 10,030 9,999
STAT...enqueue releases 29 10,030 10,001
STAT...parse count (hard) 4 10,011 10,007 -- ，
STAT...calls to get snapshot s 55 10,087 10,032
STAT...parse count (total) 33 10,067 10,034
STAT...consistent gets 247 10,353 10,106
STAT...consistent gets from ca 247 10,353 10,106
STAT...recursive calls 10,474 20,885 10,411
STAT...db block gets from cach 10,408 30,371 19,963
STAT...db block gets 10,408 30,371 19,963
LATCH.enqueues 322 21,820 21,498 --
LATCH.enqueue hash chains 351 21,904 21,553
STAT...session logical reads 10,655 40,724 30,069
LATCH.library cache pin 40,348 72,410 32,062 -- pin
LATCH.kks stats 8 40,061 40,053
LATCH.library cache lock 318 61,294 60,976
LATCH.cache buffers chains 51,851 118,340 66,489
LATCH.row cache objects 351 123,512 123,161
LATCH.library cache 40,710 234,653 193,943
LATCH.shared pool 20,357 243,376 223,019
Run1 latches total versus runs -- difference and pct
Run1 Run2 Diff Pct
157,159 974,086 816,927 16.13% --proc2 proc1， .13%
PL/SQL procedure successfully completed.
위의 예제 에서 알 수 있 듯 이 바 인 딩 변 수 를 사용 하지 않 은 경우 분석 횟수,빗장 사용 수량,대기 열,분 배 된 메모리,라 이브 러 리 캐 시,줄 캐 시 는 바 인 딩 보다 훨씬 높 습 니 다.
변수의 상황.따라서 가능 한 한 바 인 딩 변 수 를 사용 하여 하 드 분석 에 필요 한 추가 시스템 자원 을 만 들 지 않도록 합 니 다.
바 인 딩 변수의 장점
SQL 문장의 하 드 해석 을 줄 여 하 드 해석 으로 인 한 추가 비용(CPU,Shared pool,latch)을 줄 입 니 다.그 다음으로 프로 그래 밍 효율 을 높이 고 데이터 베 이 스 를 방문 하 는 횟수 를 줄인다.
바 인 딩 변수의 단점
최적화 기 는 직사 도 정 보 를 무시 하고 실행 계획 을 만 들 때 최적화 되 지 않 을 수 있 습 니 다.SQL 최적화 가 상대 적 으로 어렵 습 니 다.
총화
1.가능 한 한 하 드 해석 을 피하 십시오.하 드 해석 은 더 많은 CPU 자원,빗장 등 이 필요 하기 때 문 입 니 다.
2.cursor_sharing 매개 변 수 는 이해득실 을 따 져 야 하 며,similar 와 force 를 사용 하 는 데 미 치 는 영향 을 고려 해 야 합 니 다.
3.가능 한 한 바 인 딩 변 수 를 사용 하여 하 드 해석 을 피한다.
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
Oracle 생성 향후 3일간의 전체 시점 (단계 상세)수요: X 좌표축 시간은 모두 정시 시간으로 앞으로 3일 동안의 예측을 보여준다(x 축은 앞으로 3일 동안의 정시 시간을 보여준다), 3시간마다 한 눈금, 가로 좌표는 모두 24개의 눈금을 보여준다 1단계: 현재 시...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.
좋은 웹페이지 즐겨찾기
