차이

문서의 선택한 두 판 사이의 차이를 보여줍니다.

--- study:oracle:datadb:2week_1 [2010/05/13 02:09]
newys
+++ study:oracle:datadb:2week_1 [2010/05/13 10:20]
starlits
@@ 줄 1: / 줄 1: @@
+====== 제 3장 SQL의 실행계획 =======
-** 제 3장 SQL의 실행계획**
 -  실행계획의 중요성? 액세스 효율에 가장 결정적인 영향을 미침
-======3.1 SQL과 옵티마이져  ======
+===== 3.1 SQL과 옵티마이져  =====
      -  옵티마이져 목표 : SQL로 요구된 결과를 최소의 비용으로 처리할 수 있는 처리 경로를 결정
@@ 줄 13: / 줄 11: @@
- ==== 3.1.1 옵티마이져와 우리의 역할  ====
+==== 3.1.1 옵티마이져와 우리의 역할  ====
   - 숫자 목록 관계형 데이터베이스의 출현배경 : 데이터들 간에 물리적인 연결고리를 가지지 않아도 논리적인 연결고리만 있다면 원하는 데이터를 액세스 할 수 있다.    =>논리적인 방법만으로 데이터를 찾을 수 있는 장치가 필요
@@ 줄 29: / 줄 27: @@
-  ①  규칙기반 옵티마이져 (RBO : Rule_based Optimizer)
+  가. 규칙기반 옵티마이져 (RBO : Rule_based Optimizer)
-     -  인덱스 구조나 사용 연산자에 부여된 순위로써 최적경로 결정
+    -  인덱스 구조나 사용 연산자에 부여된 순위로써 최적경로 결정
       ① ROWID로 1로우 액세스
       ② 클러스터 조인에 의한 1로우 액세스
@@ 줄 47: / 줄 44: @@
       ⑭ 인덱스 컬럼의 ORDER BY
      ⑮ 전체 테이블 스캔
   * 단점
@@ 줄 54: / 줄 50: @@
-  EX> 1,000,000 로우를 가지는 TAB1테이블과 100로우를 가지는 TAB2테이블의 로우수를 알지 못하기 때문에
-       어느쪽이 전체 테이블 스캔 하는것이 유리한지 구별할 수 없다.
+ EX> 1,000,000 로우를 가지는 TAB1테이블과 100로우를 가지는 TAB2테이블의 로우수를 알지 못하기 때문에 어느쪽이 전체 테이블 스캔 하는것이 유리한지 구별할 수 없다.
-  EX> 2종류의 값만 가지고 있어 평균분포도가 50%인 컬럼 A로 구성된 인덱스와 10,000종류를 가지고 있어 0.01%의 평균 분포도를
-       가진 컬럼 B로 구성된 인덱스가 존재. A='10' AND B LIKE '123%'을 주었을때 무조건 ‘=’로 사용한
+ EX> 2종류의 값만 가지고 있어 평균분포도가 50%인 컬럼 A로 구성된 인덱스와 10,000종류를 가지고 있어 0.01%의 평균 분포도를   가진 컬럼 B로 구성된 인덱스가 존재. A='10' AND B LIKE '123%'을 주었을때 무조건 ‘=’로 사용한 컬럼A를 사용하는 것이 더 유리하다고 판단.
-       컬럼A를 사용하는 것이 더 유리하다고 판단.
@@ 줄 67: / 줄 62: @@
+  나. 비용기준 옵티마이져(Cost_based Optimizer)
+    ① 관계형 데이터베이스가 추구하는 이상형
+     ② 처리방법들에 대한 비용을 미리 산정해보고 그 중 가장 적은 비용이 들어가는 처리방법 선택
+     ③ 통계정보의 형태와 종류는 DBMS 제품이나 버전에 따라 차이     - 통계정보는 테이블의 로우 수와 블록 수, 블록당 평균 로우수, 로우의 평균길이, 컬럼별 상수값의 종류, 분포도, 컬럼 내 NULL값의 수, 클러스터링 팩터, 인덱스의 길이, 최대 최소값, 리프 블록수, 가동 시스템의 I/O나 CPU 사용정보 등
-------------
-  ② 비용기준 옵티마이져(Cost_based Optimizer)
-  - 관계형 데이터베이스가 추구하는 이상형
-  - 처리방법들에 대한 비용을 미리 산정해보고 그 중 가장 적은 비용이 들어가는 처리방법 선택
-  - 통계정보의 형태와 종류는 DBMS 제품이나 버전에 따라 차이
-     =>통계정보는 테이블의 로우 수와 블록 수, 블록당 평균 로우수, 로우의 평균길이, 컬럼별 상수값의 종류, 분포도, 컬럼 내 NULL값의 수, 클러스터링 팩터, 인덱스의 길이, 최대 최소값, 리프 블록수, 가동 시스템의 I/O나 CPU 사용정보 등
@@ 줄 85: / 줄 73: @@
   - 현실을 감안한 최적화
-    - 위의 예시에서 B인덱스 조건이 A조건보다 적은 범위를 처리하고 있다면 옵티마이져는 B인덱스를 처리주관 조건으로 선택
+     - 위의 예시에서 B인덱스 조건이 A조건보다 적은 범위를 처리하고 있다면 옵티마이져는 B인덱스를 처리주관 조건으로 선택
-    - 분포도 : 통계정보에서 가장 주용한 정보
+     - 분포도 : 통계정보에서 가장 주용한 정보
        * 분포도가 좋다-> 컬럼값의 종류가 많다 ->조건을 만족하는 처리범위가 좁다는 것을 의미하므로 일의 양을 결정하는 가장 중요한 요소
-    - 컬럼의 모든 값들에 대해 분포도를 가지면 정확하겠지만 불가능 =>컬럼값의 범위별로 분포도 보유하는 방법
+     - 컬럼의 모든 값들에 대해 분포도를 가지면 정확하겠지만 불가능 =>컬럼값의 범위별로 분포도 보유하는 방법
-    - 컬럼값에 저장할 분포도의 종류는 버켓(Bucker)의 개수에 따라 결정
+     - 컬럼값에 저장할 분포도의 종류는 버켓(Bucker)의 개수에 따라 결정
        * 넓이균형 히스토그램(Width_balanced Histogram) :버켓에 저장할 분포도는 컬럼값의 최소치와 최대치에 대해 균등한 범위로 분할하여 각 범위별로 보유한 로우의 수를 보관 (컬럼값의 종류가 적거나 분포도의 편차가 심하지 않는 경우)
-      * 높이균형 히스토그램(Height_balanced Histogram) : 총 로우 수를 버켓수만큼으로 나누어 각 버켓에 저장되는 값의 범위를 기록 (분포도나 컬럼값의 편차가 심한 경우)
+      * 높이균형 히스토그램(Height_balanced Histogram) : 총 로우 수를 버켓수만큼으로 나누어 각 버켓에 저장되는 값의 범위를 기록 (분포도나 컬럼값의 편차가 심한 경우)     => 두가지 방법은 사용자가 선택 할 수 없음. 단 버켓 수 지정 가능.	 그러나 DBMS의 패키지 dbms_stats 등의 프로시져를 활용하여 자동 결정
-     => 두가지 방법은 사용자가 선택 할 수 없음. 단 버켓 수 지정 가능
+   - 통계정보의 관리를 통한 제어
-	 그러나 DBMS의 패키지 dbms_stats 등의 프로시져를 활용하여 자동 결정
+     - 통계정보를 어떻게 관리할 것이냐을 고심
-  - 통계정보의 관리를 통한 제어
+     - 테이블마다 통계정보를 관리할 수 없음 => 테이블을 모니터링하는 기능 이용 ( USER_TAB_MODIFICATION와 같은 딕셔너리 뷰를 통해 확인)
-    - 통계정보를 어떻게 관리할 것이냐을 고심
+    - 만약 통계테이블을 수동으로 관리 하고자 한다면 수집방법, 수집 주기 결정       =>스크립트 작성, 작업스케줄링 할 수 있는 S/W활용, 제공된 프로시져(GRTHER_DATABASE_STAT 등)
-    - 테이블마다 통계정보를 관리할 수 없음 => 테이블을 모니터링하는 기능 이용 ( USER_TAB_MODIFICATION와 같은 딕셔너리 뷰를 통해 확인)
-    - 만약 통계테이블을 수동으로 관리 하고자 한다면 수집방법, 수집 주기 결정
-       =>스크립트 작성, 작업스케줄링 할 수 있는 S/W활용,
-	 제공된 프로시져(GRTHER_DATABASE_STAT 등)
   - 최악의 상황이 발생할 확률의 감소
     - 적절하지 못한 인덱스 구성, 고품질의 SQL을 사용하지 못해도 대부분 최소한의 수행 속도 보장
     - 사용자의 쿼리를 재해석하여 새로운 쿼리로 변형시킴
-        인덱스의 길이, 최대 최소값, 리프 블록수, 가동 시스템의 I/O나 CPU 사용정보 등
-① 실행계획 예측의 곤란
-    -사용자가 예측불가능하므로 애플리케이션을 작성할 때 미리 적절한 대응하기 어렵고,        종합적인 전략을 수립하기 곤란
-② 버전에 따른 변화
-③ 실행계획 제어가 곤란
--단점
+  * 단점
+   - 실행계획 예측의 곤란
+   - 사용자가 예측불가능하므로 애플리케이션을 작성할 때 미리 적절한 대응하기 어렵고, 종합적인 전략을 수립하기 곤란
+   - 버전에 따른 변화
+   - 실행계획 제어가 곤란
-- 옵티마이져의 발전 방향
+  다. 옵티마이져의 발전 방향
-   · 비용기준 옵티마이져로 발전해 나간다.
+   - 비용기준 옵티마이져로 발전해 나간다.
-   · 단위SQL 보다는 테이블이나 인덱스 단위로 관리
+   - 단위SQL 보다는 테이블이나 인덱스 단위로 관리
--통계정보 관리를 위한 제언
+   라.통계정보 관리를 위한 제언
-   · 통계정보의 수집과 관리를 위해 DBMS에서 제공하는 패키지들이 계속 보강되고 있음
+   - 통계정보의 수집과 관리를 위해 DBMS에서 제공하는 패키지들이 계속 보강되고 있음
-   · 과거에는 I/O에 비중. 최근에는 CPU의 수행정도와 사용량을 추가함
+   - 과거에는 I/O에 비중. 최근에는 CPU의 수행정도와 사용량을 추가함
-   · 통계정보의 보다 간편한 수집이나 관리를 위해 DBMS_STATS 패키지 이용하면 좋음
+  - 통계정보의 보다 간편한 수집이나 관리를 위해 DBMS_STATS 패키지 이용하면 좋음
-     => 테이블이나 인덱스와 같은 데이터베이스 오브젝트에 대한 통계정보 생성을 	용이하게 해줌. 테이블이나 인덱스와 관련된 통계정보를 생성할 수 있으며, 견본 	데이터를 추출하여 통계정보를 생성하는것도 가능. 대용량 테이블이라면 모든 	데이터를 대상으로 통계정보를 수집할 수 없으므로 좋은 방법
+     => 테이블이나 인덱스와 같은 데이터베이스 오브젝트에 대한 통계정보 생성을 용이하게 해줌. 테이블이나 인덱스와 관련된 통계정보를 생성할 수 있으며, 견본데이터를 추출하여 통계정보를 생성하는것도 가능. 대용량 테이블이라면 모든 데이터를 대상으로 통계정보를 수집할 수 없으므로 좋은 방법    => 견본데이터는 5% 이하로 선정하는게 바람직
-    => 견본데이터는 5% 이하로 선정하는게 바람직
         지정 파라메터 : ESTIMATE_PERCENT 로 직접 			DBMS_STATS.AUTO_SAMPLE_SIZE 로 자동으로 판단
     => 통계정보 수집시간을 단축하기 위해 병렬로 처리 가능

adminschool.net wiki

사용자 도구

사이트 도구

차이

문서 도구