Oracle 멀 티 테이블 연결,효율 향상,성능 최적화 작업
이 는 ORACLE 가 간단 한 표 에 만 고속 버퍼 링(cache buffering)을 제공 하기 때 문 입 니 다.이 기능 은 다 중 표 연결 조회 에 적용 되 지 않 습 니 다.데이터베이스 관리 자 는 init.ora 에서 이 지역 에 적합 한 파 라 메 터 를 설정 해 야 합 니 다.이 메모리 영역 이 클 수록 더 많은 문 구 를 유지 할 수 있 습 니 다.물론 공 유 될 가능성 도 큽 니 다.
ORACLE 에 SQL 문 구 를 제출 하면 ORACLE 는 먼저 이 메모리 에서 같은 문 구 를 찾 습 니 다.
여기 서 밝 혀 야 할 것 은 ORACLE 가 이들 에 대해 엄격 한 매 칭 을 취 하 는 것 이다.공 유 를 달성 하려 면 SQL 문 구 는 반드시
완전히 같다.
공 유 된 문 구 는 세 가지 조건 을 만족 시 켜 야 합 니 다.
A.문자 급 비교:
현재 실 행 된 문장 과 공유 탱크 의 문장 은 완전히 같 아야 합 니 다.
예 를 들 면:
SELECT * FROM EMP;
아래 와 각각 다르다
SELECT * from EMP;
Select * From Emp;
SELECT * FROM EMP;
B.두 문장 이 가리 키 는 대상 은 반드시 똑 같 아야 한다.사용자 대상 이름 접근 방법
Jack sal_limit private synonym
Work_city public synonym
Plant_detail public synonym
Jill sal_limit private synonym
Work_city public synonym
Plant_detail table owner
다음 SQL 문 구 를 이 두 사용자 사이 에서 공유 할 수 있 는 지 고려 해 보 세 요.
SQL 이 원인 을 공유 할 수 있 습 니까?
select max(sal_cap) from sal_limit; 사용자 마다 private synonym 이 있 으 면 안 돼 요.-sallimit,다른 대상 입 니 다.
select count(*) from work_city where sdesc like 'NEW%'; 두 사용자 가 같은 대상 에 접근 할 수 있 는 Public synonym-workcity
select a.sdesc,b.location from work_city a , plant_detail b where a.city_id = b.city_id 불가
사용자 jack private synonym 을 통 해 plant 방문detail 과 jill 은 표 의 소유자 이 고 대상 이 다 릅 니 다.
C.두 SQL 문 구 는 같은 이름 의 바 인 딩 변 수 를 사용 해 야 합 니 다(bid variables).
예 를 들 어 첫 번 째 그룹의 두 SQL 문 구 는 같 고(공유 할 수 있 음)두 번 째 그룹의 두 문 구 는 다르다(실행 할 때 도 서로 다른 바 인 딩 변수 와 같은 값 을 부여 한다).
a.
select pin , name from people where pin = :blk1.pin;
select pin , name from people where pin = :blk1.pin;
b.
select pin , name from people where pin = :blk1.ot_ind;
select pin , name from people where pin = :blk1.ov_ind;
중점 관심 1:가장 효율 적 인 표 이름 순서 선택(규칙 기반 최적화 기 에서 만 유효)중점 관심
ORACLE 의 해석 기 는 FROM 자구 의 표 이름 을 오른쪽 에서 왼쪽으로 처리 하기 때문에 FROM 자구 에 마지막 표(기초 표 driving table)에 적 힌 표 가 가장 먼저 처 리 됩 니 다.FROM 자구 에 여러 표 가 포 함 된 경우 기록 항목 이 가장 적은 표를 기본 표 로 선택해 야 합 니 다.ORACLE 가 여러 표를 처리 할 때 정렬 및 병합 방식 으로 연결 합 니 다.
먼저,첫 번 째 표(FROM 자구 의 마지막 표)를 스 캔 하고 기록 을 파 순 한 다음 에 두 번 째 표(FROM 자구 의 마지막 두 번 째 표)를 스 캔 한 다음 에 두 번 째 표 에서 검색 한 모든 기록 을 첫 번 째 표 에서 적당 한 기록 과 합 친다.
예 를 들 면:
표 TAB 1 16,384 개 기록
표 TAB 2 1 개 기록
TAB 2 를 기본 표 로 선택(가장 좋 은 방법)
select count(*)from tab 1,tab 2 실행 시간 0.96 초
TAB 2 를 기본 표 로 선택(좋 지 않 은 방법)
select count(*)from tab 2,tab 1 실행 시간 26.09 초
3 개 이상 의 표 연결 조회 가 있 으 면 교차 표(intesection table)를 기본 표 로 선택해 야 합 니 다.교차 표 는 다른 표 에 의 해 인 용 된 표를 말 합 니 다.
예 를 들 어 EMP 표 는 LOCATION 표 와 CATEGORY 표 의 교 집합 을 묘사 했다.
SELECT *
FROM LOCATION L ,
CATEGORY C,
EMP E
WHERE E.EMP_NO BETWEEN 1000 AND 2000
AND E.CAT_NO = C.CAT_NO
AND E.LOCN = L.LOCN
다음 SQL 보다 더 효율 적 입 니 다.
SELECT *
FROM EMP E ,
LOCATION L ,
CATEGORY C
WHERE E.CAT_NO = C.CAT_NO
AND E.LOCN = L.LOCN
AND E.EMP_NO BETWEEN 1000 AND 2000
중점 관심 2:WHERE 자구 의 연결 순서.중점 관심ORACLE 는 아래 에서 위로 WHERE 자 구 를 해석 합 니 다.이 원리 에 따라 표 간 의 연결 은 다른 WHERE 조건 에 써 야 합 니 다.최대 수량 기록 을 걸 러 낼 수 있 는 조건 은 WHERE 자구 의 끝 에 써 야 합 니 다.
예 를 들 면:
(저 효과,실행 시간 156.3 초)
SELECT …
FROM EMP E
WHERE SAL >; 50000
AND JOB = ‘MANAGER'
AND 25 < (SELECT COUNT(*) FROM EMP
WHERE MGR=E.EMPNO);
(고 효율,실행 시간 10.6 초)
SELECT …
FROM EMP E
WHERE 25 < (SELECT COUNT(*) FROM EMP
WHERE MGR=E.EMPNO)
AND SAL >; 50000
AND JOB = ‘MANAGER';
중점 관심 3:SELECT 자구 에서'*'를 사용 하지 마 세 요.중점 관심SELECT 자구 에 모든 COLUMN 을 열거 하고 싶 을 때 동적 SQL 열 을 사용 하여'*'를 인용 하 는 것 은 편리 한 방법 입 니 다.불행 하 게 도 이것 은 매우 비효 율 적 인 방법 입 니 다.실제로 ORACLE 는 해석 하 는 과정 에서'*'를 순서대로 모든 열 이름 으로 바 꿉 니 다.이 작업 은 데이터 사전 을 조회 하여 이 루어 집 니 다.이것 은 더 많은 시간 을 소모 한 다 는 것 을 의미 합 니 다.
7.데이터 베 이 스 를 방문 하 는 횟수 감소
모든 SQL 문 구 를 실행 할 때 ORACLE 는 내부 에서 많은 작업 을 실 행 했 습 니 다.SQL 문 구 를 분석 하고 색인 의 이 용 률,바 인 딩 변수,데이터 블록 읽 기 등 을 추산 합 니 다.이 를 통 해 알 수 있 듯 이 데이터 베 이 스 를 방문 하 는 횟수 를 줄 이면 실제 적 으로 ORACLE 의 작업량 을 줄 일 수 있 습 니 다.
예컨대
다음은 세 가지 방법 으로 직원 번호 가 0342 또는 0291 인 직원 을 검색 할 수 있다.
방법 1(최저 효과)
SELECT EMP_NAME , SALARY , GRADE
FROM EMP
WHERE EMP_NO = 342;
SELECT EMP_NAME , SALARY , GRADE
FROM EMP
WHERE EMP_NO = 291;
방법 2(차 저 효과)
DECLARE
CURSOR C1 (E_NO NUMBER) IS
SELECT EMP_NAME,SALARY,GRADE
FROM EMP
WHERE EMP_NO = E_NO;
BEGIN
OPEN C1(342);
FETCH C1 INTO …,..,.. ;
OPEN C1(291);
FETCH C1 INTO …,..,.. ;
CLOSE C1;
END;
방법 3(효율 적)
SELECT A.EMP_NAME , A.SALARY , A.GRADE,
B.EMP_NAME , B.SALARY , B.GRADE
FROM EMP A,EMP B
WHERE A.EMP_NO = 342
AND B.EMP_NO = 291;
주의:SQL*Plus,SQL*Forms 와 Pro*C 에 ARRAYSIZE 인 자 를 재 설정 하면 데이터베이스 에 접근 할 때마다 검색 데 이 터 량 을 늘 릴 수 있 으 며 권장 값 은 200 입 니 다.
중점 관심 4:DECODE 함 수 를 사용 하여 처리 시간 을 줄 입 니 다.중점 관심
DECODE 함 수 를 사용 하면 같은 기록 을 중복 검색 하거나 같은 표를 중복 연결 하 는 것 을 피 할 수 있 습 니 다.
예 를 들 면:
SELECT COUNT(*),SUM(SAL)
FROM EMP
WHERE DEPT_NO = 0020
AND ENAME LIKE ‘SMITH%';
SELECT COUNT(*),SUM(SAL)
FROM EMP
WHERE DEPT_NO = 0030
AND ENAME LIKE ‘SMITH%';
너 는 DECODE 함수 로 같은 결 과 를 효율적으로 얻 을 수 있다.
SELECT COUNT(DECODE(DEPT_NO,0020,'X',NULL)) D0020_COUNT,
COUNT(DECODE(DEPT_NO,0030,'X',NULL)) D0030_COUNT,
SUM(DECODE(DEPT_NO,0020,SAL,NULL)) D0020_SAL,
SUM(DECODE(DEPT_NO,0030,SAL,NULL)) D0030_SAL
FROM EMP WHERE ENAME LIKE ‘SMITH%';
유사 한 것 은 DECODE 함수 도 GROUP BY 와 ORDER BY 자구 에 사용 할 수 있 습 니 다.중점 관심 5:중복 기록 삭제.중점 관심
가장 효율 적 인 중복 기록 삭제 방법(ROWID 를 사 용 했 기 때 문)
DELETE FROM EMP E
WHERE E.ROWID >; (SELECT MIN(X.ROWID)
FROM EMP X
WHERE X.EMP_NO = E.EMP_NO);
중점 관심 6:DELETE 대신 TRUNCATE.중점 관심표 의 기록 을 삭제 할 때,일반적으로 스크롤 백 세그먼트(rollback segments)는 복구 할 수 있 는 정 보 를 저장 합 니 다.COMMIT 업무 가 없 으 면,ORACLE 는 데 이 터 를 삭제 하기 전 상태 로 복원 합 니 다.(정확히 말 하면 삭제 명령 을 실행 하기 전 상태 로 복원 합 니 다)
TRUNCATE 를 사용 할 때 스크롤 백 은 복구 가능 한 정 보 를 저장 하지 않 습 니 다.명령 이 실 행 된 후 데 이 터 를 복구 할 수 없습니다.따라서 자원 이 호출 되 지 않 고 실행 시간 도 짧 습 니 다.
(번역자:TRUNCATE 는 전체 표 만 삭제 하고 적용 되 며 TRUNCATE 는 DDL 이지 DML 이 아 닙 니 다)
포 인 트 는 7:최대한 COMMIT 를 많이 사용 하 세 요.포 인 트 는 요.
가능 하 다 면 프로그램 에서 COMMIT 를 최대한 많이 사용 하면 프로그램의 성능 이 향상 되 고 수요 도 COMMIT 가 방출 하 는 자원 으로 인해 줄어든다.
COMMIT 에서 사용 하 는 자원:
a.스크롤 백 세그먼트 에서 데 이 터 를 복구 하 는 데 사용 되 는 정보.
b.프로그램 문 에서 얻 은 자물쇠
c.redo log buffer 의 공간
d.ORACLE 는 상기 3 가지 자원 중의 내부 비용 을 관리 하기 위해
(번역자 의 말:COMMIT 를 사용 할 때 반드시 업무 의 완전 성 을 주의해 야 한다.현실 에서 효율 과 업무 의 완전 성 은 흔히 물고기 와 곰 발바닥 을 겸 할 수 없다)
중점 관심 8:표 에 대한 조 회 를 줄 이 고 중점 관심 을 가진다.
하위 조 회 를 포함 하 는 SQL 구문 에 서 는 표 에 대한 조 회 를 줄 이 는 데 특히 주의해 야 한다.
예 를 들 면:
저 효과
SELECT TAB_NAME
FROM TABLES
WHERE TAB_NAME = ( SELECT TAB_NAME
FROM TAB_COLUMNS
WHERE VERSION = 604)
AND DB_VER= ( SELECT DB_VER
FROM TAB_COLUMNS
WHERE VERSION = 604)
고 효율
SELECT TAB_NAME
FROM TABLES
WHERE (TAB_NAME,DB_VER)
= ( SELECT TAB_NAME,DB_VER)
FROM TAB_COLUMNS
WHERE VERSION = 604)
여러 개의 Column 예 업데이트:저 효과:
UPDATE EMP
SET EMP_CAT = (SELECT MAX(CATEGORY) FROM EMP_CATEGORIES),
SAL_RANGE = (SELECT MAX(SAL_RANGE) FROM EMP_CATEGORIES)
WHERE EMP_DEPT = 0020;
효율 성:
UPDATE EMP
SET (EMP_CAT, SAL_RANGE)
= (SELECT MAX(CATEGORY) , MAX(SAL_RANGE)
FROM EMP_CATEGORIES)
WHERE EMP_DEPT = 0020;
중점 관심 9:IN 대신 EXISTS.중점 관심많은 기초 표를 바탕 으로 하 는 조회 에서 하나의 조건 을 만족 시 키 기 위해 서 는 종종 다른 표를 연결 해 야 한다.이런 상황 에서 EXISTS(또는 NOT EXISTS)를 사용 하면 조회 의 효율 을 높 일 수 있다.
저 효과:
SELECT *
FROM EMP ( )
WHERE EMPNO >; 0
AND DEPTNO IN (SELECT DEPTNO
FROM DEPT
WHERE LOC = ‘MELB')
효율 성:
SELECT *
FROM EMP ( )
WHERE EMPNO >; 0
AND EXISTS (SELECT ‘X'
FROM DEPT
WHERE DEPT.DEPTNO = EMP.DEPTNO
AND LOC = ‘MELB')
(번역 자 는 상대 적 으로 NOT EXISTS 로 NOT IN 을 교체 하면 효율 이 더욱 현저하게 향상 되 고 다음 절 에서 지적 할 것 이다)주목 10:NOT EXISTS 로 NOT IN 을 대체 합 니 다.
하위 검색 에서 NOT IN 자 구 는 내부 정렬 과 통합 을 수행 합 니 다.어떤 경우 에 도 NOT IN 은 가장 비효 율 적 입 니 다.(하위 검색 에 있 는 시 계 를 옮 겨 다 니 기 때 문 입 니 다)NOT IN 을 사용 하지 않도록 외부 연결(Outer Joins)이나 NOT EXISTS 로 바 꿀 수 있 습 니 다.
예 를 들 면:
SELECT …
FROM EMP
WHERE DEPT_NO NOT IN (SELECT DEPT_NO
FROM DEPT
WHERE DEPT_CAT='A');
효율 성 을 높이 기 위해(방법 1:효율 성)
SELECT ….
FROM EMP A,DEPT B
WHERE A.DEPT_NO = B.DEPT(+)
AND B.DEPT_NO IS NULL
AND B.DEPT_CAT(+) = ‘A'
(방법 2:가장 효율 적)
SELECT ….
FROM EMP E
WHERE NOT EXISTS (SELECT ‘X'
FROM DEPT D
WHERE D.DEPT_NO = E.DEPT_NO
AND DEPT_CAT = ‘A');
물론 가장 효율 적 인 방법 은 표 와 관련 이 있 습 니 다.직접 두 표 의 관 계 를 연결 하 는 속도 가 가장 빠 릅 니 다!중점 관심 11:'저 효과 실행'을 식별 하 는 SQL 문장.중점 관심
다음 SQL 도구 로 저 효과 SQL 찾기:
SELECT EXECUTIONS , DISK_READS, BUFFER_GETS,
ROUND((BUFFER_GETS-DISK_READS)/BUFFER_GETS,2) Hit_radio,
ROUND(DISK_READS/EXECUTIONS,2) Reads_per_run,
SQL_TEXT
FROM V$SQLAREA
WHERE EXECUTIONS>;0
AND BUFFER_GETS >; 0
AND (BUFFER_GETS-DISK_READS)/BUFFER_GETS < 0.8
ORDER BY 4 DESC;
이상 의 이 오 라 클 다 중 표 연결 에 관 한 효율 성 을 향상 시 키 고 성능 최적화 작업 은 바로 작은 편집 이 여러분 에 게 공유 하 는 모든 내용 입 니 다.여러분 께 참고 가 되 고 저 희 를 많이 사랑 해 주 셨 으 면 좋 겠 습 니 다.
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 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에 따라 라이센스가 부여됩니다.