1 / 145

성 능 관 리

성 능 관 리. 2005. 8. 김무영. 목 차. 성능관리에 대하여 ----------- 3 개발측면에서의 성능관리 단계 ------- 5 성능확보를 위한 설계 가이드 라인 ---- 14 SQL 튜닝 ------------------- 36 데이타베이스 튜닝 --------------- 70 시스템에서 주로 발생하는 문제들 ----- 97 성능관리 예제 1, 2 -------------- 103. 퍼포먼스. 무장애. 성능보장. 최적의 자원사용.

lacy
Download Presentation

성 능 관 리

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 성 능 관 리 2005. 8. 김무영

  2. 목 차 • 성능관리에 대하여 ----------- 3 • 개발측면에서의 성능관리 단계 ------- 5 • 성능확보를 위한 설계 가이드 라인 ---- 14 • SQL 튜닝 ------------------- 36 • 데이타베이스 튜닝 --------------- 70 • 시스템에서 주로 발생하는 문제들 ----- 97 • 성능관리 예제 1, 2 -------------- 103

  3. 퍼포먼스 무장애 성능보장 최적의 자원사용 성능관리란? O 성능관리자의 역할은? O 성능관리의 책임은 누구한테 있는가?

  4. 성능상의 주요요소 DB Tuning APP’ (SQL) DBA Performance Management 프로그래머 모델러 DB Modeling etc : OS, Web서버, WAS, H/W…

  5. 성능관리 단계

  6. 응용 설계자(Application Designer) 응용 개발자(Application Developer) DBA(Database Administrator) Hardware/Software 관리자 누가 성능관리를 하는가 * 성능관리의 책임자는???

  7. 언제 성능관리를 하는가 - 계획단계 • 전문성능관리 인력 및 비용 확보 • 하드웨어 및 소프트웨어 구성 선택 • 시스템 확장을 감안한 용량계획 수립 • 시스템 분석 및 설계표준 정립 • 시스템별 성능기대치 결정 • 성능목표 설정과 우선순위 결정은 분명하고 일관성 있게 계획 분석/ 설계 개발 검수 운영

  8. 계획 언제 성능관리를 하는가 - 분석/설계단계 • 성능을 감안한 데이터모델링 및 데이터베이스 설계 • Table간의 자동화 규칙(제한조건)의 적절한 설계 • 성능을 감안한 프로그램 설계 및 Table 구조 변경, 추가 • 데이터요구에 적합한 인덱스 정책수립 및 정의 • 데이터 모델과 User Interface 간의 적합성 검증 분석/ 설계 개발 검수 운영

  9. 계획 언제 성능관리를 하는가 - 개발단계 • 옵티마이저에 대한 이해와 실행계획 조정 • 고급SQL 사용 및 최적화 • 적용업무 프로그램에 적합한 Locking 범위 결정 • 재사용 Library의 정립 및 적극적 활용 • 프로그램 코딩 표준의 엄격한 준수 분석/ 설계 개발 검수 운영

  10. 계획 언제 성능관리를 하는가 –검수(시험평가)단계 • 실제 운영상황에 견줄만한 테스트용 데이터량의 확보 • 실제 운영환경과 동일한 시스템 구성(Configuration) • 전문 튜너에 의한 성능시험 및 보증 • 성능관리 전문툴 활용 • 테스트 및 품질보증을 통과한 프로그램만을 현업에 적용 분석/ 설계 개발 검수 운영

  11. 계획 언제 성능관리를 하는가 - 운영단계 분석/ 설계 • 시스템성능에 대한 지속적인 감시 • 시스템 및 RDBMS 에서 제공하는 모든 성능감시도구 활용 • O/S 와 RDBMS 튜닝간의 적합성 검증 • LIVE SYSTEM과 TEST용 SYSTEM의 별도 사용 개발 검수 운영

  12. 비즈니스 분석 데이터 분석 논리 모델 물리 모델 DB 구현 시험 언제 성능관리를 하는가 – DB 구축과정

  13. 따라서 성능관리의 가장 효과적인 시점은 디자인 단계=> 최소의 비용으로 최대의 효과 기대 언제 성능관리를 하는가 - 최적의 시점

  14. OLTP DB의 경우 : A DW DB의 경우 : B SYSTEM TUNNIG 비율 B. A. Database Program(SQL) DB Modeling Database 15% 20% 15% System 17.5% System 2.5% 5% DB Modeling Program(SQL) 60% 65%

  15. 성능확보를 위한 설계 가이드라인

  16. DB 튜닝측면 : 옵티마이저 정책 수립 실천, 자원소모 최소화 및 병목현상 제거, 적절한 DB 환경조절 SQL 사용측면 : 코딩표준, Sql사용형태, 실행계획 조절, 최적성/처리횟수 고려 DB 모델링 측면 - 최적의 논리 모델링 수행, 인덱스 정책 수립 실천 - DB 벤더 Master에 의한 물리설계 - 적절한 DB Constraints의 사용으로 SQL수량 제한 운영 및 향후 개선을 염두에 둔 설계 시스템 전체 측면에서의 과부하 제거 - 불필요한 네트워크 트래픽 제거 - 서버, OS측면에서의 부하제거 예상되는 문제점 제거 설계 가이드 라인

  17. 사전 준비사항 데이터모델의 세부 다이아그램 테이블의 평균 로우 수, 한 로우의 평균크기등 데이터 증가율, 평균 사용자수 등 최대집중시(Peak Time) 초당 수행되는 트랜잭션 개수 및 크기등 기타 데이터에 대한 문서 튜닝되지 않은 데이터모델 일대일 관계, 다대다 관계, 원형함정모델등 온라인 트랜잭션 처리에 적절하지 않은 모델 과도한 조인 및 Full Table Scan 을 유발하는 데이터모델 단순 명료 하지않고 복잡한 형태의 모델 데이터 모델 측면(간략히)

  18. Database Buffer Cache Database Buffer Cache Shared Pool Shared Pool Redo Log Buffer Redo Log Buffer … 김무영 7803** …….. 김무영 78030** … 서홍교 79030** … 임성열 68030** … 조광원 88030** … 윤송이 88030** … … ㅇ DB_BLOCK_SIZE & 모델링 - 평균레코드 길이가 적당 - 평균레코드 길이가 과도(과도한 디노말제이션) SGA SGA Oracle block Oracle block DB block IO (2k ~ 64k) Disk IO (2k ~ 4k)

  19. EMP_idx1 EMP Table iNDEX VALUE ROWID/Address 사원번호 성명 직위 2812 0000089D.0000.0001 2854 김준억 부장 2840 0000089D.0001.0001 2858 허성욱 부장 2843 0000089D.0002.0001 2812 진종건 사원 2854 0000089D.0003.0001 2855 김종훈 차장 2855 0000089D.0004.0001 2863 이정호 차장 2856 0000089D.000A.0001 2840 김무용 사원 2863 0000089D.0003B.0001 2843 이재민 사원 인덱스정책 측면 SELECT 사원번호,성명,직위 FROM EMP WHERE 사원번호 BETWEEN ‘2843’ AND ‘2856’ ORDER BY 1; Sort 된 결과 ㅇ 인덱스란? ㅇ 인덱스의 종류는 어떤것이 있으며 본 개발사업에서 사용할 인덱스종류는? B*Tree, Bitmap, F.B.I, Hash, Cluster, Domain, spatial, IOT, Functional, Reverse, compressed …

  20. 인덱스 대상 테이블 선정 테이블의 크기가 5~6블럭 이상 무작위접근(Random Access)이 빈번한 경우 특정범위/순서의 데이터조회가 필요한 경우 Join의 연결고리가 되는 칼럼 참조무결성을 지정한 경우 연결고리 되는 칼럼 Nested Join이 일어나는 테이블 인덱스 대상 칼럼 선정 분포도와 손익분기점 : 분포도는 10~15%를 넘지 않아야 한다. 인덱스 머지(Index Merge) 결합인덱스(Composite Index) : 결합되는 순서에 따라 영향이 크므로 주의 * F.B.I : Oracle 8.0 DB이상 * Index skip 알고리즘 : 9i DB이상 칼럼 2 칼럼 1 칼럼 4 칼럼 3 1. 인덱스 선정기준 참고자료 : 대용량DB솔류션

  21. 해당 테이블의 가능한 모든 접근형태 수집 대상칼럼 선정 및 분포도 조사 반복 수행(Looping)되는 Critical Access Path의 해결 클러스터링 검토 인덱스 칼럼의 조합 및 순서의 결정 시험생성 및 테스트 수정이 필요한 Application 조사 및 수정 일괄적용 2. 인덱스 선정절차

  22. 인덱스와 데이터 테이블은 각기 다른 디스크에 배치 인덱스에 대한 적절한 공간 할당 테이블 접근없이 인덱스만으로 데이터 요구 해결 인덱스 생성 및 삭제 시점의 효율적 운용 검토 데이터 로드나 일시에 많은 데이터를 입력할 경우 인덱스에 대한 부하를 줄이기 위해 인덱스를 삭제, 입력 및 로드가 끝난 이후 재생성 인덱스의 명명은 생성목적과 의미를 내포 Ex) Sys_30002(?), IX_dept2 인덱스 관리측면 감안 - ANALYZE, REBUILD, 생성 및 삭제 인덱스의 종류 및 특징을 감안하여 사용 : B*Tree, Bitmap, F.B.I, Hash, Cluster, Domain, spatial, Functional, Reverse, compressed … 3. 인덱스의 효율적 관리

  23. “다음의 경우에는 인덱스가 사용되지 않는다.” 복합 인덱스에서 Leading Column이 제한 조건에 사용되지 못한 경우 인덱스칼럼의 변형 부정형 비교 널을 사용한 비교 LIKE문의 ‘%’가 맨 처음에 위치한 경우 Optimizer에 의한 취사선택 4. 인덱스의 활용 Select * From emp Where 주민번호 like ’68%’ and 성별 != ‘남자’ and 이전주소 is null and substr(주민번호,3,2) != ’03’ Pk : 주민번호 * Where조건에서 인덱스를 사용하는 드라이빙 칼럼은 반드시 위의 조건을 지켜야하며 나머지 체크 칼럼은 부정형으로 사용하여도 무방하다.

  24. SELECT * FROM DEPT WHERE SUBSTR(DNAME,1,3) = 'ABC' 부정형 비교 인덱스 칼럼 변형 NULL, NOT NULL Optimizer 의 취사선택 5. 인덱스가 사용되지 않을경우 SELECT * FROM EMP WHERE JOB <> 'SALES' SELECT * FROM EMP WHERE ENAME IS NOT NULL SELECT * FROM EMP WHERE JOB LIKE 'AB%' AND EMPNO = '7890' 참고자료 : 대용량DB솔류션

  25. 6. 인덱스칼럼의 변형(external) SELECT * FROM EMP WHERE SUBSTR(DNAME,1,3) = 'ABC' SELECT * FROM EMP WHERE DNAME LIKE 'ABC%' SELECT * FROM EMP WHERE SAL * 12 = 12000000 SELECT * FROM EMP WHERE SAL = 12000000 / 12 SELECT * FROM EMP WHERE TO_CHAR(HIREDATE,'YYMMDD') = '940101' SELECT * FROM EMP WHERE HIREDATE = TO_DATE('940101','YYMMDD')

  26. 7. 인덱스 칼럼의 변형(external) SELECT * FROM EMP WHERE EMPNO BETWEEN 100 AND 200 AND NVL(JOB,'X') = 'CLERK' SELECT * FROM EMP WHERE EMPNO BETWEEN 100 AND 200 AND JOB = 'CLERK' SELECT * FROM EMP WHERE DEPTNO = '10' AND JOB = 'SALSMAN' SELECT * FROM EMP WHERE DEPTNO || JOB = '10SALESMAN' 의도적인 SUPPRESSING SELECT * FROM EMP WHERE RTRIM(JOB) = 'MANAGER' SELECT * FROM EMP WHERE JOB = 'MANAGER' SELECT * FROM EMP WHERE RTRIM(EMPNO) = 8978 SELECT * FROM EMP WHERE EMPNO = 8978

  27. 8. 인덱스 칼럼의 변형(internal) CREATE TABLE SAMPLET ( CHR CHAR(10), NUM NUMBER (12,3), VAR VARCHAR2(20), DAT DATE) SELECT * FROM SAMPLET WHERECHA = 10 SELECT * FROM SAMPLET WHERETO_NUMBER(CHA)= 10 SELECT * FROM SAMPLET WHERENUM LIKE '9410%' SELECT * FROM SAMPLET WHERETO_CHAR(NUM)LIKE '9410%'

  28. INDEX COLUMN의 변형 (internal) 예제 TABLE ACCESS FULL CHULGOT SQL> SELECT SUM(UNCOST) FROM CHULGOT WHERE STATUS = 90 1 row, 28.5 sec SQL> SELECT SUM(UNCOST) FROM CHULGOT WHERE STATUS = '90' SORT AGGREGATE TABLE ACCESS BY ROWID CHULGOT INDEX RANGE SCAN CH_STATUS 1 row, 0.15 sec SQL> SELECT CHULNO, CUSTNO, UNCOST FROM CHULGOT WHERE CFMDEPT LIKE '71%' TABLE ACCESS FULL CHULGOT rows, sec NUMBER type SQL> SELECT ORDNO, CHULNO, STATUS FROM ORDER1T X, CHULGOT Y WHERE X.CUSTNO = Y.CUSTNO AND X.ORDDEPT = Y.CFMDEPT AND y.CHULDATE LIKE '9711%' NESTED LOOPS TABLE ACCESS FULL ORDER1T TABLE ACCESS BY ROWID CHULGOT INDEX RANGE SCAN CH_CFMDEPT rows, 71 sec

  29. 9. NULL, NOT NULL SELECT * FROM EMP WHERE ENAME > ' ' SELECT * FROM EMP WHERE ENAME IS NOT NULL SELECT * FROM EMP WHERE COMM > 0 SELECT * FROM EMP WHERE COMM IS NOT NULL SELECT * FROM EMP WHERE COMM IS NULL

  30. NOT Operator SELECT 'Not fornd !' INTO :COL1 FROM EMP WHERE EMPNO <> '1234' SELECT 'OK' INTO :COL1 FROM DUAL WHERE NOT EXISTS ( SELECT '' FROM EMP WHERE EMPNO = '1234') SELECT * FROM EMP WHERE ENAME LIKE '김%' AND JOB <> 'SALES' SELECT * FROM EMP a WHERE a.ENAME LIKE '김%' AND NOT EXISTS( SELECT '' FROM EMP b WHERE a.ENAME = b.ENAME AND b.JOB = 'SALES') SELECT * FROM EMP WHERE ENAME LIKE '김%' MINUS SELECT * FROM EMP b WHERE b.JOB = 'SALES'

  31. 참고자료 Modified Column Values Prevent Use of Index ㅇ where sal * 1.1 > 50 => where sal > 50 / 1.1 ㅇ where to_char(hiredate, ‘YYMMDD’) = ’040223’ => where hiredate = to_date(‘040223’,’YYMMDD’) ㅇ where substr(job,1,4) = ‘DATA’ => where job like ‘DATA%’ ㅇ where col1||col2 = :FLD => where col1 = substr(:FLD,1,3) and col2 = substr(:FLD,4,2) ㅇ where ename is not null => where ename >= 0 ㅇ where deptno != 30 => where deptno > 30 or deptno < 30 ㅇ number와 char의 비교: where empno = ‘5224’Index(X) ㅇ number와 varchar2의 비교: where empno = ‘5225’Index(X) ㅇ char와 varchar2의 비교: where a.dept = b.dept Index(X) ㅇ Composite Indexes (prjno, empno) - where prjno = 100 and empno = 100 Index(O) - where prjno = 100 Index(O) - where empno = 100 Index(X)

  32. ㅇ Optimizer : 모든 관계형 DBMS에서 SQL문장을 처리하는 질의 최적화기로 30년 이상 축적된 기술을 포함 하고 있는, 인간의 지능이 가장 많이 녹아 있는 복잡한 소프트웨어이다 ㅇ 구성요소 : 질의 변환(Query Rewriter) + 실행 계획 생성(Plan Generator) + 비용 산정(Estimator)모듈 ㅇ 종 류 : RBO(Rule based optimizer), CBO(Cost based optimizer) ㅇ 오라클 Optimizer_mode - CHOOSE : Analyze 수행시 All_Rows로 동작하고, 미수행시 Rule로 동작된다. - RULE : 테이블과 인덱스의 통계존재 여부에 상관없이 RBO를 호출함. 규칙위주의 실행계획을 만듬. - FIRST_ROWS(CBO) : 하나의 ROW를 가장 빨리 가져올수 있도록 최적화됨. 주로 NESTED LOOP 방식을 선호함. - ALL_ROWS (CBO) : 전체 ROW를 가장 빨리 가져올수 있도록 최적화함. * 힌트 사용시 RULE Hint를 제외하고 나머지는 CBO를 호출한다. select /*+ ordered use_nl(d) */ ename, sal from emp e, dept d where e.deptno = d.deptno and d.loc = 'SEOUL' ㅇ ANALYZE수행여부 ㅇ Optimizer 정책은? OPTIMIZER

  33. SQL해석 실행 계획 작성 실행 참조 참조 추출 OBJ$ t r a n s a c t i o n COL$ c u s t o m e r IND$ TAB$ account VIEW$ DATA DATA Dictionary 1. RDB, 왜 쉽고도 어려운가? OPTIMIZER select col1, col2*10, . . from account x, custommer y, transection z where x.acct = z.acct and y.cust = z.cust and jdate = ‘970609’; SQL • 사용자는 요구만 하고 OPTIMIZER가 실행계획 수립 • 수립된 실행계획에 따라 엄청난 수행속도 차이 발생 • 실행계획 제어가 어렵다. • OPTIMIZER가 좋은 실행계획을 수립할 수 있도록 종합적이고 전략적인 FACTOR를 부여 • 비절차형, 집합적으로 접근해야 함 • SQL이 어떤 역할을 담당하도록 구현할 것인가? • 시스템에 과부하 발생량을 최소화하는 SQL구사 참고자료 : 대용량DB솔류션

  34. 규칙기반 최적화(Rule-Based Optimizer) 비용기반 최적화(Cost-Based Optimizer) 2. OPTIMIZER 종류

  35. Nested Loops ? • Sort Merge ? • Hash ? • . . . . . . . ? 처리방법 결정 무자격 배제 Driving 결정 처리순서 결정 COL$ 사용 가능한 액세스형태 선별 IND$ 경선 (Rule, Cost) • tab1 - tab2 - tab3 ? • tab2 - tab1 - tab3 ? • tab3 - tab2 - tab1 ? Driving 선택 (나머지는 야당) • . . . . . . . ? 3. OPTIMIZER의 역활 select * from tab1x, tab2 y, tab3 z where x.key = y.key and z.key = x.key and x.col1 = ‘10’ and x.col2 <> 111 and x.col3 like ‘ABC%’ and y.col4 between ‘10’ and ‘50’ OPTIMIZER Row SOURSE 생성 실행계획 작성 참조 OBJ$ TAB$ VIEW$ DATA Dictionary

  36. Index, Clustering SQL 형태 B CB A JOIN OPERATOR SCALAR SUB QUERY FUNCTION Analytic information 연산자 형태 로우 수 =, LIKE, … A = ‘상수’, A = :변수… 분포도 최대값 ... OPTIMIZER SQL Hints Optimizer Mode SELECT /*+ Use_nl(a b) */ … FROM ... DBMS, Version, H/W, DB Parameter Distributed DB RULE ALL_rows First_rows Oracle DB LINK Sort, hash V7, 8i, 9i... 4. Optimizer에 영향을 미치는 요소 * 개발뿐만 아니라 운영시 에도 지속적인 정책 필요 참고자료 : 대용량DB솔류션

  37. 5. RULE Based Optimizer Rank Access Path 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Single row by ROWID Single row by cluster join Single row by hash cluster with unique or primary key Single row by unique or primary key Cluster join Hash cluster key Indexed cluster key Composite key Single column indexes Bounded range search on indexed columns Unbounded range search on indexed columns Sort merge join MAX or MIN of indexed columns ORDER BY on indexed columns Full table scan

  38. 비용 기반 접근 방식에서의 접근 경로의 선택 문장에 대해 사용 가능한 접근 경로 각 접근 경로와 그 접근 경로들간의 상호관계에 따른 실행에 필요한 비용 접근 경로의 선택을 위하여 고려하는 것 : Selectivity Selectivity를 위한 정보 WHERE 절에 사용되는 연산자 WHERE 절에 사용되는 UNIQUE나 PRIMARY KEY를 가지는 칼럼들 그 테이블에 대한 통계치 각종 설정값 : Sort, hash영역 등 6. Cost Based Optimizer

  39. 7. OPTIMIZER의 취사 선택 EMPNO Index만 사용 SELECT * FROM EMP WHERE ENAME LIKE 'AB%' AND EMPNO = '7890' RANKING 의 차이 ENAME or JOB index중 하나만 사용 , 혹은 Full scan SELECT * FROM EMP WHERE ENAME LIKE 'AB%' AND JOB LIKE 'SA%' INDEX Merge 회피 FULL Table Scan SELECT * FROM EMP WHERE EMPNO > '10' Low COST 의 선택 JOB Index만 사용 SELECT /*+ INDEX(EMP JOB_IDX) */ * FROM EMP WHERE ENAME LIKE 'AB%' AND JOB LIKE 'SA%' HINT 에 의한 선택

  40. 8. COST_based vs RULE_based SELECT * FROM EMP WHERE JOB = 'SALESMAN' AND EMPNO = '7890' INDEX merge (and_equel) Rule based SELECT * FROM EMP WHERE ENAME LIKE 'AB%' AND EMPNO = '7890' 항상 EMPNO Index만 사용 SELECT * FROM EMP WHERE ENAME BETWEEN '1101' AND '1210' AND JOB LIKE 'SA%' 항상 나중에 생성된 Index만 사용 SELECT * FROM EMP WHERE JOB = 'SALESMAN' AND EMPNO = '7890' INDEX merge (and_equel), 특정 iNDEX Cost based SELECT * FROM EMP WHERE ENAME LIKE 'AB%' AND EMPNO = '7890' 분포도에 따라 ENAME index 도 사용 분포도에 따라 index 사용, 혹은 full scan SELECT * FROM EMP WHERE ENAME LIKE 'AB%' AND JOB LIKE 'SA%'

  41. SQL TUNNIG

  42. SQL튜닝이란? 유연한 언어 서로 다른 여러 개의 SQL문이 똑같은 결과를 가져올 수 있다. 최선의 선택 그러나, 주어진 환경이 똑같다면 오직 하나의 SQL만이 최상의 성능을 낼 수 있다. 데이터량, WHERE절, 인덱스사용, 최적화 등을 통해 SQL문의 성능을 판단하는 작업이 SQL 튜닝이다. SQL 튜닝 개요

  43. SQL의 공유(표준화) ㅇ 이미 수립된 실행 계획을 공유해서 재 사용 - 구문 분석 비용 감소(Hard Parse) - 메모리 사용 개선(Literal SQL에 의한 단편화현상) ㅇ 동일한 SQL 문장 이란? –텍스트 동일(대소문자 구분, 빈 칸, 주석 포함) –사용자 및 참조 객체 동일 –바인드 변수의 데이터 형식 동일 ㅇ SQL 형식 표준을 정하여 코딩 –대소문자, 빈 칸, 주석 사용 규칙 아예 SQL에 주석 사용 금지 등 – SQL 문장을 동일한 위치에 따로 관리 –자주 쓰는 것은 PL/SQL로 대치

  44. ㅇ 부하의 감소 – 동일한 부하를 보다 효율적인 방법으로 수행 – 일반적인 SQL Tuning(DB모델링 & SQL형태 조정, 실행계획 조정, 자원소모 및 경합감소등) ㅇ 부하의 조정 – 부하 정도에 따라 업무 조정 - 배치, 리포트 업무 등과 일반 업무(OLTP)를 분리 ㅇ 응용 프로그램별, 시간대별 부하의 병렬 수행 – 병렬로 수행하여 응답 시간을 크게 단축 – 과도한 사용은 일반 사용자에게 악 영향 가능성 – 주로 배치 업무에 많이 사용됨 SQL 튜닝의 3가지 접근방법

  45. Optimization Hints /*+ ALL_ROWS */ /*+ FIRST_ROWS */ /*+ AND_EQUAL */ /*+ CLUSTER */ /*+ COST */ /*+ FULL */ /*+ USE_HASH */ /*+ HASH_AJ */ /*+ INDEX(TAB) */ /*+ INDEX_ASC */ /*+ INDEX_DESC */ 가장 적합한 Hint를 선정하여 해당 SQL문에 기술 /*+ CHOOSE */ /*+ RULE */ /*+ STAR */ /*+ PARALLEL */ /*+ USE_HASH */ /*+ USE_CONCAT */ /*+ USE_MERGE */ /*+ USE_NL */ /*+ ORDERED */ /*+ ROWID */ Hints * Instance 레벨 : Optimizer_Mode = All_Rows * Session 레벨 : Alter Session Set Optimizer_Mode = Rule * Sql 레벨 : Hints 사용

  46. Select /*+ Ordered use_hash(a b) */ a.주민번호, a.이름, (select ….from.. Where…) 계급, b.주소, fun_idc(xxx), sum(xx) From 인원 a, (Select /*+use_nl(x y)*/…. -- In Line View From … Where…) b Where a.주민번호 = b.주민번호 and a.이름 in (Select …. From… Where….) Group by …. Union all (Minus, Intersect….) Select /*+ rule */ c.주민번호, c.이름, (Select ….From… Where….)계급, d.주소, fun_idc(xxx), sum(xx) From 인원 c, (Select /*+all_rows*/…. From … Where…) d Where c.주민번호 = d.주민번호 and c.이름 in (Select …. From… Where….) Group by …. 데이터 연결방법 ㅇ JOIN - Nested Loop - Sort Merge - Hash - Cartesian - Star ….. - Out - Etc(natural, self join) ㅇ OPERATOR - Union All…..Group by - Union…..Group by - Intersect - Minus ㅇ SCALAR QUERY ㅇ SUB QUERY ㅇ FUNCTION SQL TECH’

  47. 데이터 연결방법 1 : JOIN SELECT 고객명, 상품구매일시, 금액 ……… FROM 고객 X, 상품구매내역 Y WHERE X.고객번호 =Y.고객번호 AND X. 고객번호 =’1235’; 참고자료 : 대용량DB솔류션

  48. 가. NESTED LOOP JOIN SELECT a.FLD1, ..., b.FLD1,... FROM TAB1 a, TAB2 b WHERE a.KEY1 = b.KEY2 AND a.FLD1 = 'AB' AND b.FLD2 = '10' TABLE ACCESS BY ROWID TABLE ACCESS BY ROWID KEY2= KEY1 FLD1='AB' o o o • 순차적 (부분범위처리 가능) • 종속적 (먼저 처리되는 테이블의 처리범위에 따라 처리량 결정) • 랜덤(Random) 액세스 위주 • 연결고리 상태에 따라 영향이 큼 • 주로 좁은 범위 처리에 유리 운반 단위 FLD2 ='10' check x TAB1 TAB2 INDEX (FLD1) INDEX (KEY2) 97 : 3

  49. TABLE ACCESS BY ROWID TABLE ACCESS BY ROWID FLD1='AB' FLD2='10' a.KEY1= b.KEY2 를 조건으로 Merge S O R T S O R T . . . . . . . . . . . . . . . . . . . . . . . . 운반단위 TAB1 TAB2 INDEX (FLD1) INDEX (FLD2) 나. SORT MERGE JOIN SELECT /*+ use_merge(a b) */ a.FLD1, ..., b.FLD2,... FROM TAB1 a, TAB2 b WHERE a.KEY1 = b.KEY2 AND a.FLD1 = 'AB' AND b.FLD2 = '10' • 동시적(무조건 전체범위처리) • 독립적(자기의 처리범위만으로 처리량 결정) • 스캔(Scan) 액세스 위주 • 연결고리상태에 영향이 없음 • 주로 넓은범위처리에 유리 * DB LINK

  50. ㅇ 작은 table과 큰 table의 Join시에 유리. ㅇ Equi Join에서만 가능. ㅇ Driving Table에 Index를 필요로 하지 않는다. ㅇ 각 table에 대하여 1번만 읽는다. Customer Partition Hash Table CustId CustId CustId Hash Hash Name HASH HASH a001 AA a001 A1 a001 ..... b001 BB b001 B1 b001 ..... b002 BB b002 B2 .... c001 CC c001 C1 c001 b002 ..... c002 CC c001 C2 c002 .... Order Partition Hash Table Ord Id CustId Cust Id CustId Amt Hash Hash HASH Seoul r01 b001 a001 AA a001 A1 a001 AA a001 A2 r02 a001 .... b001 BB b001 B1 New r03 c001 b002 BB b002 B2 .... r04 a001 b002 BB b002 B2 Seoul r05 b002 CC c001 Seoul C1 r06 b002 c001 다. Hash Join SELECT B..Customer_Name, A.Order_amtFROM CUSTOMER B, ORDER A WHERE B.Customer_Id = A.Customer_Id 서로 매칭되는 Partition별로 Hash Key를 이용하여 조인

More Related