Oracle/기타2009. 12. 15. 11:38

set linesize 200
set pagesize 40
set sqlprompt "_user'@'_connect_identifier _privilege>"

'Oracle > 기타' 카테고리의 다른 글

Read the alert log with SQL  (0) 2010.01.13
[펌]오라클의 뷰가 만들어지는 과정  (0) 2009.12.23
DBMS_STATS package  (0) 2009.12.08
index의 크기 문제  (0) 2009.12.02
SQL*PLUS에서 HTML, EXCEL 출력물 만들기  (0) 2009.11.18
Posted by 자수성가한 부자
Oracle/기타2009. 12. 8. 10:29

DBMS_STATS 패키지란?

data dictionary에 저장되거나 사용자 지정 테이블에 저장된 최적화된 통계를 보거나 수정할 수 있는 기능을 제공하는
패키지이다. data dictionary에 있는 이러한 통계만이 비용에 근거한 최적화에 의해 사용되었다.
8i부터 이용가능하다.


주요 프로시져

Procedure Collects

GATHER_INDEX_STATS

Index statistics

GATHER_TABLE_STATS

Table, column, and index statistics

GATHER_SCHEMA_STATS

Statistics for all objects in a schema

GATHER_DICTIONARY_STATS

Statistics for all dictionary objects

GATHER_DATABASE_STATS

Statistics for all objects in a database




참조 : ORACLE 9i PL/SQL Programming (scott urman저)
         http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/stats.htm#i41448

'Oracle > 기타' 카테고리의 다른 글

[펌]오라클의 뷰가 만들어지는 과정  (0) 2009.12.23
login.sql셋팅  (0) 2009.12.15
index의 크기 문제  (0) 2009.12.02
SQL*PLUS에서 HTML, EXCEL 출력물 만들기  (0) 2009.11.18
Oracle hint  (0) 2009.11.18
Posted by 자수성가한 부자
Oracle/기타2009. 12. 2. 10:28
● 인덱스의 특성

   1. 삭제된 key공간은 다음번 insert에 재활용

   2. delete된 공간은 다음번 split시에 재활용


● 인덱스의 크기가 문제되는 상황

   1. 여유 공간은 있지만 내 공간은 없다.

   2. 동일 transaction내에서는 삭제된 공간을 재활용하지 못한다.

   3. 한번 늘어난 공간은 절대로 저절로 늘어나지 않는다.

   4. transaction이 rollback되어도 늘어난 공간은 줄어들지 않는다.
     - 테이블과 index공간 둘 다
     - 다음번 insert시에는 재활용된다.

   5. 여유공간은 많지만 dead block이 없는 경우(fragmentation)
      - index rebuild : alive block만 모아서 새롭게 index를 생성하고 기존의 index삭제

   6. 삭제 후의 dead block이 즉각 재활용되지 못하기도 한다.
      - index coalesce : 키 병합 -> leaf node의 chain 정리(주소값이 바뀜), 공간의 회수

※ 위의 상황들을 어떻게 검증할까??


● 인덱스 SPLIT

   ◎ 의미
      : 인덱스가 자란다.
        리프블럭이 꽉차면 새로운 리프 블럭을 추가하고 key를 옮긴다.(50:50 또는 90:10)

   ◎ 특징
      - 고비용의 작업
      - 많은 양의 redo유발
      - physical i/o유발
      - tx lock경합
      - 50:50 스플릿, 90:10 스플릿이 존재
      - 관련 뷰 : v$sysstat

   ◎ 인덱스 SPLIT을 줄이기 위한 대책(대체로 큰 효과없고, 부작용 발생 가능)
      - 동시 session수를 줄인다.
      - 불필요한 index삭제
      - index생성시에 높은 pctfree 부여
      - reverse index 생성

참조 : index 크기문제 part1
         index 크기문제 part2
         index 크기문제 part3


'Oracle > 기타' 카테고리의 다른 글

login.sql셋팅  (0) 2009.12.15
DBMS_STATS package  (0) 2009.12.08
SQL*PLUS에서 HTML, EXCEL 출력물 만들기  (0) 2009.11.18
Oracle hint  (0) 2009.11.18
ROWNUM  (2) 2009.11.17
Posted by 자수성가한 부자
Oracle/기타2009. 11. 18. 10:44
SQL*PLUS는 결과물을 얻어서 편집하기가 힘들다고 합니다.
하지만, markup html on 이란 명령어를 통해 html이나 excel 파일에 간단하게 만들 수 있다고 합니다.
어떻게 하는지 아래에 나온 순서대로 따라해볼까요?


SQL*PLUS에서는 아래와 같이 명령어를 입력합니다.

SQL> set markup html on


spool on 명령어를 입력하여 화면의 내용을 파일에 저장하기 시작합니다.

SQL> spool 파일명.html (excel 파일인 경우에는 파일 확장자를 파일.xls로 입력)


파일에 담고자 하는 내용의 쿼리를 입력합니다.

SQL> select * from emp;


spool off 명령어를 입력하여 화면의 내용을 여기까지만 파일에 담도록 하겠습니다.

SQL> spool off


실제로 파일이 생겼는지 확인합니다.



잘 만들어졌군요.


참조 : http://theone79.tistory.com/485
        

'Oracle > 기타' 카테고리의 다른 글

DBMS_STATS package  (0) 2009.12.08
index의 크기 문제  (0) 2009.12.02
Oracle hint  (0) 2009.11.18
ROWNUM  (2) 2009.11.17
Query의 성능 측정의 기준  (0) 2009.11.16
Posted by 자수성가한 부자
Oracle/기타2009. 11. 18. 01:04
힌트란 무엇인가?

오라클 optimizer 가 계획을 수립하는데 도움을 주는 항목이다.
하지만 꼭 optimizer가 이 힌트대로 실행계획을 수립하지는 않는다. 말 그대로 힌트를 줄 뿐인거다. 최종 결정을 optimizer가 알아서 한다.

힌트의 사용법
 
{SELECT | INSERT | UPDATE | DELETE} /*+ hint [text] [hint [text]] ... */
혹은
{SELECT | INSERT | UPDATE | DELETE} --+ hint [text] [hint [text]] ...
 
-         이러한 힌트의 사용은 SQL 전체가 아닌 쓰여진 SQL 블럭에만 적용됩니다.
그리고 힌트의 위치는 반드시 {SELECT | INSERT | DELETE}의 뒤에 있어야 한다.

 
 
힌트의 종류 별 분류
Optimization Goals and Approaches
             ALL_ROWS 혹은 FIRST_ROWS
             CHOOSE
             RULE
 
Acess Method Hints
             AND_EQUAL
             CLUSTER
             FULL
             HASH
             INDEX 혹은 NO_INDEX
             INDEX_ASC 혹은 INDEX_DESC
             INDEX_COMBINE
             INDEX_FFS
             ROWID
 
Join Order Hints
             ORDERED
             STAR
 
Join Operation Hints
             DRIVING_SITE
             HASH_SJ, MERGE_SJ 혹은 NL_SJ
             LEADING
             USE_HASH 혹은 USE_MERGE
             USE_NL
Parallel Execution Hints
             PARALLEL 혹은 NOPARALLEL
             PARALLEL_INDEX
             PQ_DISTRIBUTE
             NOPARALLEL_INDEX
 
Query Transformation Hints
             EXPAND_GSET_TO_UNION
             FACT 혹은 NOFACT
             MERGE
             NO_EXPAND
             NO_MERGE
             REWIRTE 혹은 NOREWRITE
             STAR_TRANSFORMATION
             USE_CONCAT
 
Other Hints
             APPEND 혹은 NOAPPEND
             CACHE 혹은 NOCACHE
             CURSOR_SHARED_EXACT
             DYNAMIC_SAMPLING
             NESTED_TABLE_GET_REFS
             UNNEST 혹은 NO_UNNEST
             ORDERED_PREDICATES
  
힌트의 설명 및 사용법
 
ALL_ROWS
             /*+ ALL_ROWS */
-         최소한의 자원을 사용하여 결과값의 전체를 추출하게 합니다.
 
AND_EQUAL
             /*+ AND_EQUAL (table index index [index] [index] [index] ) */
-         복수의 단일 컬럼을 스캔하여 머지 방식으로 처리하게 합니다.
 
APPEND_HINT
             /*+ APPEND */
-         직렬 모드 데이터베이스에서 Direct INSERT를 실행하게 합니다.
-         Enterprise Edition 이 아닌 데이터베이스의 기본 모드는 직렬 모드입니다. 이러한 직렬 모드 데이터 베이스에서의 INSERT 작업은 Conventional를 기본값으로 하고 병렬 처리 시에는 Direct INSERT를 기본값으로 합니다.
 
CACHE_HINT
             /*+ CACHE (table) +/
-         풀 테이블 스캔의 사용 시, 테이블에서 읽어온 블럭을 버퍼의 LRU 리스트 의 MRU 쪽에 위치시킵니다. 작은 테이블의 사용 시 유용합니다.
 
CHOOSE_HINT
             /*+ CHOOSE +/
-         Rule-Based 와 Cost-Based 방식 간의 선택을 유도합니다. 선택 기준은 사용 객체의 분석 정보 존재 여부이며, 사용되는 객체들중 하나라도 분석 정보가 존재한다면 Cost-Based 방식을 사용하게 됩니다.
 
CLUSTER_HINT
             /*+ CLUSTER (table) +/
-         지정 테이블의 클러스터 스캔을 유도합니다. 클러스터된 객체에만 사용할 수 있습니다.
 
CURSOR_SHARING_EXACT
             /*+ CURSOR_SHARING_EXACT +/
-         바인드 변수 값의 교체를 불가능하게 합니다.
-         기본적으로 CURSOR_SHARING 파라미터를 사용하여, 안전하다고 판단될 시 SQL 내의 바인드 변수 값을 교체할 수 있게 되어 있습니다.
 
DRIVING_SITE
             /*+ DRIVING_SITE (table) +/
-         오라클이 선택한 SITE 대신, 지정한 SITE를 사용하여 쿼리를 실행합니다. Rule-Based 와 Cost-Based, 두 모드 다 사용 가능합니다.
 
DYNAMIC_SAMPLING
             /*+ DYNAMIC_SAMPLING ( [table] n ) +/
-         해당 객체의 Selectivity 와 Cardinality 에 대한 보다 자세한 정보를 자동으로 생성시켜 실행합니다.
-         값은 0 부터 10 까지 지정할 수 있으며, 높을 수록 보다 자세한 정보를 생성하게 됩니다. 테이블에 해당 값을 지정하지 않았을 경우, 기본 값은 CURSOR 레벨의 값이 쓰여집니다.
 
EXPAND_GSET_TO_UNION
             /*+ EXPAND_GSET_TO_UNION +/
-         GROUP BY GROUPING SET 혹은 GROUP BY ROLLUP 등과 같은 구문을 포함하는 쿼리에 사용할 수 있습니다.
-         이 힌트는 기존의 쿼리를 개별적인 그룹 생성 후, UNION ALL 방식으로 실행되게 유도합니다.
 
FACT_HINT
             /*+ FACT (table) +/
-         스타 변형 구문에서 사용되며 해당 테이블이 FACT 테이블로 사용되게 유도합니다.
 
FIRST_ROWS
             /*+ FIRST_ROWS (n) +/
-         전체 결과값의 반환 대신 지정한 숫자만큼 로우의 결과값을 반환하는데 집중하게 유도합니다.
 
FULL_HINT
             /*+ FULL (table) */
-         지정한 테이블에 대해 풀 테이블 스캔을 유도합니다.
 
HASH_HINT
             /*+ HASH (table) */
-         지정한 테이블에 대해 hash 스캔을 수행하도록 유도합니다.
-         클러스터 테이블 만을 대상으로 합니다.
 
HASH_AJ
             /*+ HASH_AJ */
-         EXISTS 구문 뒤에 오는 서브 쿼리에 사용되며 HASH_SJ, MERGE_SJ 혹은 NL_SJ 등을 사용할 수 있습니다.
-         HASH_SJ 은 hash semi-join 이고, MERGE_SJ 은 sort merge semi-join 이며 NL_SJ 은 nested loop semi-join 입니다.
 
INDEX
             /*+ INDEX (table index [index] [index] ... ) */
-         지정한 테이블의 인덱스 스캔을 실행하도록 유도합니다.
-         Domain, B-tree, bitmap, bitmap join 인덱스 등이 사용될 수 있으나, bitmap 인덱스 들의 사용 시, INDEX 힌트보다는 INDEX_COMBINE 힌트 사용이 추천됩니다.
 
INDEX_ASC
             /*+ INDEX-ASC (table [index] [index] ... ) +/
-         해당 테이블의 인덱스를 순차적 방식으로 스캔하게 합니다.
-         해당 쿼리가 인덱스 범위 스캔의 사용 시, 인덱스 값의 순차적 방식으로 읽게 됩니다.
 
INDEX_COMBINE
             /*+ INDEX_COMBINE (table [index] [index] ... ) +/
-         해당 테이블에 Bitmap 인덱스의 존재 시, Bitmap 인덱스를 통한 액세스를 유도합니다.
-         힌트 내에 인덱스의 이름이 쓰여지지 않을 시, 해당 인덱스의 Boolean 값을 사용하여 최적의 Cost를 산출하여 실행하게 됩니다.
 
INDEX_DESC
             /*+ INDEX_DESC (table [index] [index] ... ) +/
-         지정한 인덱스에 대해 인덱스 스캔을 역순으로 실행합니다.
-         해당 쿼리가 인덱스 범위 스캔의 사용 시, 인덱스 컬럼의 값을 사용하여 역순으로 실행합니다.
-         파티션 인덱스에서는 파티션 별 개별적인 실행이 이루어집니다.
 
INDEX_FFS
/*+ INDEX_FFS (table [index] [index] ... ) +/
-         풀 테이블 스캔 대신에 빠른 풀 테이블 스캔의 실행을 유도합니다.
 
LEADING_HINT
             /*+ LEADING (table) +/
-         테이블 간의 조인 시에 지정한 테이블을 먼저 수행하도록 유도합니다.
-         두 개 이상의 LEADING 힌트의 사용 시, 힌트 자체가 사용되어 지지 않습니다.
-         ORDERED 힌트와 더불어 사용시, LEADING 힌트는 사용되지 않습니다.
 
MERGE
             /*+ MERGE (table) +/
-         각 쿼리의 결과값을 머지합니다.
-         해당 쿼리 내에 GROUP BY 절의 사용 이나 SELECT 구문에 DISTINCT 가 사용되었을 시, 머지의 실행이 가능할 경우에만 힌트가 실행됩니다.
-         IN 과 서브 쿼리의 사용 시, 서브 쿼리와 상위 쿼리 간의 상호 관계가 없을 때에만 머지의 실행이 가능합니다.
-         이 힌트는 Cost-based 가 아닙니다. 따라서 액세스하는 실행 쿼리 블럭에 MERGE 힌트가 반드시 명시되어야만 합니다. 그렇지 않을 경우 옵티마이저는 다른 실행 계획을 수립합니다.
 
MERGE_AJ
             HASH_AJ 를 참조하십시요.
 
MERGE_SJ
             HASH_AJ 를 참조하십시요.
 
NL_AJ
             HASH_AJ 를 참조하십시요.
 
NL_SJ
             HASH_AJ 를 참조하십시요.
 
NOAPPEND
             /*+ NOAPPEND +/
-         병럴 모드에서의 INSERT 작업을 Conventional 방식으로 수행합니다.
-         병렬 모드에서는 Direct-path INSERT 가, 직렬 모드에서는 Conventional INSERT가 기본값입니다.
 
NOCACHE
             /*+ NOCACHE (table) +/
-         풀 테이블 스캔의 사용 시, 테이블에서 읽어온 블럭을 버퍼의 LRU 리스트 의 LRU 쪽에 위치시킵니다. 기본 모드입니다.
 
NO_EXPAND
             /*+ NO_EXPAND +/
-         실행 쿼리 내에 OR 나 WHERE 절의 IN 이 사용되었을 시, Cost-Based 옵티마이저가 쿼리 처리를위해 OR 를 사용한 확장을 사용하는 것을 방지합니다.
-         일반적으로 옵티마이저는 위와 같은 경우 OR – 확장의 가격이 확장을 사용하지 않는 것보다 적을 시, 확장 방식으로 수행합니다.
 
NO_FACT
             /*+ NO_FACT (table) +/
-         Star 변형 시, 해당 테이블의 FACT 테이블로서의 사용을 방지합니다.
 
NO_INDEX
             /*+ NO_INDEX (table [index] [index] ... ) +/
-         지정 테이블의 인덱스 사용을 방지합니다.
 
NO_MERGE
             /*+ NO_MERGE (table) +/
-         머지 처리 방식의 사용을 방지합니다.
 
NOPARALLEL
             /*+ NOPARALLEL (table) +/
-         지정한 테이블의 병렬 처리를 방지합니다.
-         테이블의 지정된 PARALLEL 값에 대해서 우선권을 가집니다.
-         중첩 테이블에 대해서는 병렬 처리를 할 수 없습니다.
 
NOPARALLEL_INDEX
             /*+ NOPARALLEL_INDEX (table [index] [index] ... ) +/
-         인덱스 스캔 작업의 병렬 처리를 방지합니다.
-         인덱스에 지정된 PARALLEL 값에 우선권을 가집니다.
 
NO_PUSH_PRED
             /*+ NO_PUSH_PRED (table) +/
-         결과값에 대한 조인 방식 서술의 강제적 수행을 방지합니다.
 
NO_PUSH_SUBQ
             /*+ NO_PUSH_SUBQ +/
-         서브 쿼리의 결과값을 머지하지 않는 실행 계획이 실행 계획 설립 단계에서 제일 마지막으로 참조되는 것을 방지합니다.
-         일반적으로 서브 쿼리의 Cost 가 높거나, 처리 로우의 갯수를 크게 줄여주지 못할 때에는 서브 쿼리를 마지막에 참조하는 것이 성능 향상에 도움이 됩니다.
 
NOREWRITE
             /*+ NOREWRITE +/
-         해당 쿼리 블럭의 쿼리 재생성의 실행을 방지합니다.
-         QUERY_REWRITE_ENALBE 파라미터에 대해 우선권을 가집니다.
-         NOREWRITE 힌트의 사용 시, Function-Based 인덱스의 사용이 금지됩니다.
 
NO_UNNEST
             /*+ NO_UNNEST +/
-         해당 서브 쿼리 블럭의 UNNESTING 설정의 사용을 방지합니다.
 
ORDERED
             /*+ ORDERED +/
-         FROM 절에 나열된 테이블의 순서대로 조인 작업을 실행합니다.
 
ORDERED_PREDICATE
             /*+ ORDERED_PREDICATE +/
-         옵티마이저에 의한 조인 관계의 Cost를 산출하기 위해 미리 정해둔 조인 관계 별 실행 순서의 사용을 방지합니다.
n         인덱스 키를 사용한 조인 관계들은 제외됩니다.
-         이 힌트는 쿼리의 WHERE 절에 사용하십시요.
 
PARALLEL
             /*+ PARALLEL (table [ [, n |, DEFAULT |, ] [, n | DEFAULT ] ] ) +/
-         병렬 처리에 사용될 서버 프로세스의 갯수를 설정합니다.
-         병렬 처리 조건에 위배될 시, 힌트는 사용되지 않습니다.
-         임시 테이블에 대한 PARALLEL_HINT 사용 시, 힌트는 사용되지 않습니다.
 
PARALLEL_INDEX
             /*+ PARALLEL_INDEX (table [ [index] [, index]...]
[ [, n |, DEFAULT |, ] [, n | DEFAULT ] ] ) +/
-         파티션 인덱스의 인덱스 범위 스캔 작업의 병렬 처리에 할당될 서버 프로세스의 갯수를 지정합니다.
 
PQ_DISTRIBUTE
             /*+ PQ_DISTRIBUTE (table [,] outer_distribution, inner_distribution) +/
-         병렬 조인 시, Producer 프로세스와 Consumer 프로세스 간의 데이터 전달 방식을 지정합니다.
 
PUSH_PRED
             /*+ PUSH_PRED (table) +/
-         결과값에 대한 조인 방식 서술의 강제적 수행을 실행합니다.
 
PUSH_SUBQ
             /*+ PUSH_SUBQ +/
-         머지가 불가능한 서브 쿼리들의 우선 실행 계획을 실행 계획 수립시 먼저 참조하도록 합니다.
-         서브 쿼리의 사용 객체가 Remote 테이블이거나, 머지 조인의 사용 시 힌트는 실행되지 않습니다.
 
REWRITE
             /*+ REWRITE [ ( [materialized_view] [materialized_view]...) ] +/
-         실행 계획의 가격에 상관없이 Materialized View 를 사용하여 쿼리 재생성을 하도록 합니다.
-         Materialized View 를 지정할 시, 지정한 Materialized View 의 가격에 상관없이 무조건 쿼리 재생성을 실행합니다.
-         Materialized View 를 지정하지 않을 시, 오라클은 사용 가능한 모든 Materialized View 를 참조하여 그 중 가장 가격이 낮은 Materialized View 를 사용하여 쿼리 재생성을 합니다.
-         Materialized View 를 지정하지 않는 힌트의 사용이 권장됩니다.
 
ROW_ID
             /*+ ROWID (table) +/
-         지정한 테이블의 스캔을 ROWID 방식으로 수행하게 합니다.
 
RULE
             /*+ RULE +/
-         실행 계획을 Rule-Based 방식으로 실행하게 합니다.
-         해당 쿼리 블럭에 다른 힌트 또한 사용되었을 경우, 다른 힌트들은 사용되지 않습니다.
 
STAR
             /*+ STAR +/
-         Star 쿼리 계획이 사용 가능하다면, 실행하게 합니다.
-         Star 쿼리 계획이란 가장 큰 테이블이 마지막 순서로 조인되며, 조인될 시 가장 큰 테이블 내의 Concatenated 인덱스에 대해 Nested Loop 조인 방식으로 실행되는 것을 말합니다.
-         최소한 세개 이상의 테이블이 사용되며, 제일 큰 테이블의 Concatenated 인덱스의 생성에 최소한 세 개 이상의 컬럼이 사용되어야 하며, 액세스나 조인 방식에 충돌이 없어야만 이 힌트는 사용됩니다.
 
STAR_TRANSFORMATION
             /*+ STAR_TRANSFORMATION +/
-         옵티마이저가 Star 변형 작업에 최적화된 실행 계획을 수립, 실행하도록 합니다.
-         힌트를 사용하지 않을 시, 옵티마이저는 일반적인 작업에 최적화된 실행 계획을 수행합니다.
-         힌트를 사용하였어도 변형 작업에 맞추어진 실행 계획을 실행한다는 보장은 없습니다. 다른 일반적인 힌트의 사용과 마찬가지로 비교 분석 후, 오라클의 판단에 따라 다른 실행 계획이 실행될 수 있습니다.
 
UNNEST
             /*+ UNNEST +/
-         서브 쿼리 블럭에 대해 인증성 만을 검사하게 합니다.
-         인증이 되었다면 그 이상의 검증 작업없이 서브쿼리에 대한 UNNESTING 의 설정을 가능하게 합니다.
 
USE_CONCAT
             /*+ USE_CONCAT +/
-         WHERE 절의 OR 조인 을 UNION ALL 로 변경하여 수행하게 합니다.
-         일반적으로 이러한 변경은 결과값의 병합 수행의 가격이 수행하지 않을 시의 가격 보다 낮을 때에만 실행됩니다.
 
USE_HASH
             /*+ USE_HASH (table [table]...) +/
-         Hash 조인 방식으로 각 테이블을 조인하게 합니다.
 
USE_MERGE
             /*+ USE_MERGE (table [table]...) +/
-         Sort-Merge 방식으로 각 테이블을 조인하게 합니다.
 
USE_NL
             /*+ USE_NL (table [table]...) +/
- Nested-Loop 방식으로 각 테이블을 조인하게 합니다.

출처 : http://luckys.tistory.com/tag/%EC%98%A4%EB%9D%BC%ED%81%B4%20%ED%9E%8C%ED%8A%B8

'Oracle > 기타' 카테고리의 다른 글

index의 크기 문제  (0) 2009.12.02
SQL*PLUS에서 HTML, EXCEL 출력물 만들기  (0) 2009.11.18
ROWNUM  (2) 2009.11.17
Query의 성능 측정의 기준  (0) 2009.11.16
[펌]오라클 성능에 대한 짧은 생각 #12  (0) 2009.11.15
Posted by 자수성가한 부자
Oracle/기타2009. 11. 17. 14:12
● ROWNUM의 동작 원리
   - 쿼리내에서 사용 가능한 가상컬럼(pesudocolumn)이다.
   - 1,2,3, ... , N의 값이 할당된다.
   - ROWNUM 값은 쿼리의 조건절이 처리되고 난 이후, 그리고 sort, aggregation이 수행되기 이전에 할당된다.

가능하지 않은 쿼리

select rownum as no, emp.*
from emp
where rownum = 2;

가능한 쿼리

select *
from (select rownum as no, emp.*
        from emp)
where no = 1;


참고 : http://www.oracle.com/technology/global/kr/oramag/oracle/06-sep/o56asktom.html
Posted by 자수성가한 부자
Oracle/기타2009. 11. 16. 22:05

Query의 성능 측정의 기준이 되는 값은 객관적으로 비교 가능한 값으로 해야 한다.
아래의 값들이 성능 측정의 기준이 되는 값이다.


Logical I/O

Physical I/O

Memory Usage


그 후에 시간이 얼마나 걸리느냐가 문제다.
절대 시간이 적게 걸린다고 해서 좋은 Query가 아니라는 것이다.
Posted by 자수성가한 부자
Oracle/기타2009. 11. 15. 00:51

성능 문제에 대한 정확한 이해는 용어에 대한 정확한 이해에서부터 온다

인간의 생각하는 능력이 언어라는 것을 만들었지만, 거꾸로 언어가 인간의 사고 능력을 지배하게 되죠.

오라클 성능 세계에서도 마찬가지입니다. 용어에 대한 정확한 이해가 없으면 문제를 100% 이해할 수도 없을뿐더러 잘못된 지식을 믿게 됩니다. 예를 들어 볼까요?

  • Explain Plan과 Execution Plan의 차이를 설명할 수 있습니까?
  • Scan과 Lookup의 차이는 무엇입니까?
  • Histogram의 의미는 무엇입니까?
  • Lock과 Enqueue의 의미를 구분할 수 있습니까?
  • SQL문과 Cursor의 차이를 설명할 수 있습니까?
  • Event라는 용어가 언제 쓰이는지 설명할 수 있습니까?
용어을 100% 정확하게 설명할 수 있다면 그 자체로도 성능 문제에 대한 상당한 통찰력을 가지고 있다고 볼 수 있습니다.





출처 : http://ukja.tistory.com/282

'Oracle > 기타' 카테고리의 다른 글

ROWNUM  (2) 2009.11.17
Query의 성능 측정의 기준  (0) 2009.11.16
DBA와 개발자가 알고 있어야 하는 오라클의 새로운 기능(oracle database 11g)  (0) 2009.11.15
Binding 변수 확인하기  (0) 2009.11.13
metadata  (0) 2009.11.11
Posted by 자수성가한 부자
Oracle/기타2009. 11. 15. 00:10

'Oracle > 기타' 카테고리의 다른 글

Query의 성능 측정의 기준  (0) 2009.11.16
[펌]오라클 성능에 대한 짧은 생각 #12  (0) 2009.11.15
Binding 변수 확인하기  (0) 2009.11.13
metadata  (0) 2009.11.11
난수 발생(dbms_random package)  (0) 2009.11.09
Posted by 자수성가한 부자
Oracle/기타2009. 11. 13. 17:25

시스템 유저로 접속

conn / as sysdba

V$SQL_BIND_DATA뷰를 확인(데이터가 많으므로 isqlplus에서 확인할 것)

참고 : http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/dynviews_2115.htm#i1417482

Posted by 자수성가한 부자