Oracle/Admin2009. 11. 22. 21:40

'Oracle > Admin' 카테고리의 다른 글

2009년 11월 23일 수업내용  (0) 2009.11.23
Explain Plan과 Execution Plan의 차이  (0) 2009.11.22
grid computing  (0) 2009.11.20
Query 실행순서(update)  (0) 2009.11.19
Query 실행순서(select)  (0) 2009.11.19
Posted by 자수성가한 부자
Oracle/Admin2009. 11. 20. 15:00
오라클이 grid computing을 지원하는 최초의 데이터베이스라고 하는 근거는 무엇일까?

아래의 3가지 측면의 서비스를 제공해야 Grid computing이라고 할 수 있다.
오라클은 ASM, RAC, oracle streams 등의 소프트웨어를 제공함으로써 3가지 서비스를 제공한다고 할 수 있다.

   storage  database  application
 pooling
여러 소집단을 묶는 것
 ASM  RAC  oracle streams, AS
 virtualization
가상화
 ASM  RAC  oracle streams, AS
 provisioning
필요한 쪽에 공급할 수 있는 능력
 ASM  RAC  oracle streams, AS

아래의 설명을 보면 각 서비스의 내용을 이해할 수 있다.

작은 디스크를 모아서 디스크 그룹을 생성한다. (pooling)

create diskgroup dg1
normal redundancy
failgroup c1 disk
             '/devices/diska1' ,
             '/devices/diska2' ,
             '/devices/diska3' ,
             '/devices/diska4' ,
failgroup c2 disk
             '/devices/diska1' ,
             '/devices/diska2' ,
             '/devices/diska3' ,
             '/devices/diska4' ;


4개의 디스크에 25m씩 저장.(virtualization)

create tablespace ts1
datafile '+dg1' size 100m;


디스크 추가(추가되는 곳에 1/n이 넘어감)
각 디스크에서 5m씩 복사해서 새로운 디스크로 복사후 기존 데이터 5m지움.
각 디스크에는 20m씩 데이터가 들어가 있음

alter diskgroup dg1
add disk '/devices/diska5' name diska5,
             '/devices/diska6' name diska6;


dg2의 diska5를 drop시킨다.
dg2의 diska5 내에 있는 데이터를 dg2의 diska1~diska4로 옮기고
diska5를 dg1으로 옮긴다.(provisioning)

alter diskgroup dg2 drop disk diska5;

'Oracle > Admin' 카테고리의 다른 글

Explain Plan과 Execution Plan의 차이  (0) 2009.11.22
linux4에 oracle10gR2 or oracle11gR2 설치  (0) 2009.11.22
Query 실행순서(update)  (0) 2009.11.19
Query 실행순서(select)  (0) 2009.11.19
Oracle Architecture  (0) 2009.11.18
Posted by 자수성가한 부자
Oracle/Admin2009. 11. 19. 16:00
다음의 Query의 실행순서는 어떻게 될까요?

update emp
set sal = sal + 100
where empno = 7788


parsing

select 문의 parsing과 같다. (참조)


execute

1. data block 및 undo block을 읽어서 database buffer cache에 올려놓는다.(undo의 공간이 부족하면 에러남)

2. database buffer cache에 row level lock을 건다.

3. redo log buffer에 redo entry를 생성한다.(내가 무슨 짓을 한다.를 기록)

4. undo data 생성
   - 변경전 데이터를 undo segment에 기록

5. user data 수정


rollback; 의 경우
undo data로 user data를 덮어씀

commit; 의 경우
Buffer cache 정리(lock 해제, 메모리의 변경 확정)
redo log buffer의 내용을 redo log file로 내려쓴다.


fast commit
database buffer cache의 내용을 정리.
그것과 관련된 redo log buffer의 내용 redo log file로 내려씀
dirty buffer들은 여전함(데이터파일과 버퍼의 내용이 다름)

instance recovery:
문제가 생겼을 경우 startup시에 복구
리두로그파일을 읽어서 복구
인스턴스가 죽기 직전의 상황으로.. 
ORACLE_SID -> spfileSID.ora -> Instance 구성 -> Control file read -> data file, redo log file read
   -> INSTANCE Recovery

기타 참고사항
- undo 영역 관련 쿼리
   select * from dba_rollback_segs;

- undo를 남길 여지가 없을 경우 DML에러가 남.

- undo 전문적으로 예전의 데이터를 보관하는 공간.

- redo는 복구시에만 필요함.

- 블럭 : datafile의 블럭
   버퍼 : database buffer cache의 블럭
            종류
          - free : start up이래로 한번도 바뀐적이 없는 버퍼
          - pinned : 지금 보고있거나 바꾸고 있는 버퍼(일종의 lock). 재이용 불가능
          - dirty : 원본과 내용이 다른 버퍼. pinned에서 수정이 완료된 버퍼. 재이용 불가능.
          - clean : 재이용 가능 버퍼.


- DBWn : 데이터베이스로 모아서 내려쓰는 역할
- LGWR : 데이터베이스로 모아서 내려쓰는 역할

- DBWn, LGWR의 사명
   : 사용 가능 메모리(Database buffer cache, redo log buffer)가 많아지도록 항상 내려씀.
     왜? user process, server process가 원활하게 작업할 수 있도록. 3초마다(파라미터 값에 따라 조정가능 함)


- 시스템 테이블 스페이스
- 유저 테이블 스페이스
- undo 테이블 스페이스
   - undo segment

- DBWn, CKPT
  빈집털이 공범
  DBWn가
  CKPT가 신호를 보내고, 끝나고 검사.(Control file과 Data file에 씀)


SCN(system change number)
  참고 : http://aozjffl.tistory.com/165

'Oracle > Admin' 카테고리의 다른 글

linux4에 oracle10gR2 or oracle11gR2 설치  (0) 2009.11.22
grid computing  (0) 2009.11.20
Query 실행순서(select)  (0) 2009.11.19
Oracle Architecture  (0) 2009.11.18
isql*plus에서 dba유저 로그인 설정  (0) 2009.11.16
Posted by 자수성가한 부자
Oracle/Admin2009. 11. 19. 15:58

아래의 QUERY가 실행되는 순서를 알아보자.

select * from emp
where deptno = 10
          and sal >= 2500
order by empno;


- 사용자가 QUERY를 날린다.


parse

1. 동일 문장을 찾는다.
   ascii값으로 바꾼다. -> 바꾼 ascii값으로 hashing 함수를 통과시킨다. 
      -> hash key 값이 나옴 
          (Shared Pool의 Library Cache에서 hash chain을 찾는다.
           Library Cache에는 이전에 실행했던 SQL의 hash chain이 있다.)
   hashing된 결과를 볼 수 있는 query는 다음과 같다.(관련 column : hash_value)

select * from v$sqlarea

2. syntax 검사
    : 키워드의 오타 검사

3. semantics 검사
    : 단어를 놓고 관계를 검사.(권한, 객체 유무 등) -> recursive SQL(재귀적 SQL) 
       system 파일에 저장되어 있음 -> database buffer cache로 가져옴(block 단위)

4. Execution plan
    : 실행계획을 선택한다. (SQL> set autot on : 실행계획을 볼 수 있다.)


execute

:메모리에 있는 것을 읽음 - logical read 또는 cache hit라고 부른다.
 파일에 있는 것을 읽음 - physical read 또는 cache miss라고 부른다.


fetch

:가서 가져 오다.라는 뜻으로 select에서만 일어난다. 필요할 경우 sort가 됨
database buffer cache의 정렬이 안된 데이터를 PGA로 가져와서 정렬해서 리턴


기타 참고 사항

- DBA는 코딩규약을 만들어 개발자들이 지키도록 해야한다.
  같은 쿼리를 또다시 parsing과정을 거치지 않게 하기 위해서.
  메모리의 크기, 속도에 연관이 있다.

- select * from v$bh 로 database buffer cache의 내용을 볼 수 있다.
   bh는 block header의 약자

- 오라클은 디스크 기반 DBMS이다.

- 메인 메모리 DB도 있다. (응답속도가 매우 빠른 증권시스템에서 쓰임)

각 부분이 존재하는 이유
- library cache  : 동일 문장의 reparsing을 줄이기 위해
- row cache(data dictionary cache) : meta data disk i/o를 줄이는 위해
- database buffer cache : user data disk i/o 를 줄이기 위해

- 메타데이터 : 데이터 관리용 데이터
- 유저데이터 : 유저가 만든 데이터
- 서버튜닝(조정) : 상황에 따라 각 부분(library cache, row cache, database buffer cache)의 크기를 조정하는 것.

'Oracle > Admin' 카테고리의 다른 글

grid computing  (0) 2009.11.20
Query 실행순서(update)  (0) 2009.11.19
Oracle Architecture  (0) 2009.11.18
isql*plus에서 dba유저 로그인 설정  (0) 2009.11.16
SQL문의 처리 단계  (0) 2009.11.14
Posted by 자수성가한 부자
Oracle/Admin2009. 11. 18. 18:42


- oracle architecture -


Oracle Server : Database와 Instance를 합쳐서 일컫는다.
                      기계전체(드물게, 또는 모르는 사람들)
                      소프트웨어 자체

Database의 구성요소


data file : 실제 데이터가 저장되는 파일, block 단위로 구성.

control file : DB의 구조를 포함하는 조그만 바이너리 파일(data file, redo log file의 위치와 이름이 저장되어 있음)
                        사라질 경우 복구하기 어렵기 때문에 다중화 2벌이상 만든다.
                        

redo log file : 모든 스텝의 기록을 다 남기는 파일
                    최소한 2벌 이상으로 만든다. 
                    online redo log file과 offline redo log file(archived redo log file)로 나뉜다.

  

Instance의 구성요소

  1. SGA(메모리) : 같이 쓰는 공간
     1) Shared Pool : SQL파싱의 결과를 저장. 600가지가 넘는 공간을 차지
         ① library cache :
         ② data dictionary cache :
     2) Database Buffer Cache : 최근에 사용된 유저 데이터를 복사해 놓는 곳
     3) Redo log Buffer

  2. BGP(백그라운드 프로세스) : 모든 손님들을 위한 프로세스
     1) DBWn(20개까지 가능) : data buffer cache의 내용을 data file로 내려쓰는 역할
     2) LGWR  : redo log buffer의 내용을 redo log file로 내려쓰는 역할
     3) ARCn(10개까지 가능, archiver) : online redo log file을 offline redo log file로 쓰는 것
     4) PMON : 프로세스 모니터. 클라이언트가 갑자기 죽으면 lock등을 정리. 시체처리반
                     유저의 장애를 해결
     5) SMON : 서버의 자체 복구를 위해 존재



기타 구성요소

1. listener(교환수) : user process의 요청을 받아들여 server process에 연결하는 역할. 교환수의 역할
2. foreground process(=shadow process) : 한 손님을 위한 프로세스
    1) server process : 서버가 있는 머신에서 돌아야 한다. 웨이터
    2) PGA : 단일 프로세스(서버나 백그라운드)에 대한 데이타와 제어 정보를 저장하는 메모리 영역. 독자적인 공간
3. parameter file : pfile(initSID.ora), spfile(spfileSID.ora)
4. password file
5. diagnostic file


참고사항

- DBA가 해야 하는 일
    성능이나, 문제 발생을 고려하여 필수 공용 공간을 마련해야한다.(Spread!!)
    data file , online redo log file, offline redo log file -> 2벌씩 해 놓아야 한다.(다중화)
                                
- backup : 복사
  recovery : 복구
  restore : 복원

- online redo log file : database내의 redo log file
   offline redo log file(= archived log file : 쌓아둔 로그 파일)
            : 데이터베이스 밖의 redo log file로 archiver에 의해 복사되는 곳의 파일도 redo log file

- offline redo log file을 만드냐 안만드냐에 따라서 모드가 다름
   no archive log모드
   파일 하나를 채우면 그 다음 파일에 채운다. 1, 2, 3개가 있다면 1이 차면 다음으로 2를 채우고, 2가 다 차면 3을 채우고,
   그 다음은 1에 덮어쓴다.(log switch라고 함)

   archive모드
   첫번째, 두번째, 세번째 redo log file이 모두 쓰였다고 하면, 첫번째 파일에 덮어쓰기 전에 redo log file을 복사 후 
   offline redo log file쪽으로 가져다 놓고. 첫번째 redo log file에 덮어씀
   그 이후도 같은 형식으로 함.

- archived data file : 백업한 데이터 파일을 일컫는다.

- archived log file의 삭제에 대한 기준 시간을 정하고 그 전 데이터들은 완전히 삭제한다.(복구 불가능)

- 데이터 파일은 다중화 하지 않는다.


참고 : http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/intro.htm#i62345

'Oracle > Admin' 카테고리의 다른 글

Query 실행순서(update)  (0) 2009.11.19
Query 실행순서(select)  (0) 2009.11.19
isql*plus에서 dba유저 로그인 설정  (0) 2009.11.16
SQL문의 처리 단계  (0) 2009.11.14
SGA  (0) 2009.11.10
Posted by 자수성가한 부자
Oracle/PL_SQL2009. 11. 18. 15:42
instead of trigger는 뷰에 대한 문장으로 변경 수행되는 것을 가능하게 한다.

다음의 예제는 뷰에 대하여 insert 문장을 수행할 경우
그 문장이 테이블에 대한 insert 문장으로 변경되도록 하는 예제이다.


실습용 테이블을 테이블을 만든다.
기존에 테이블이 있을 경우를 대비해 삭제 명령어도 넣었다.

SQL> drop table t1 purge;
SQL> create table t1
         (col1 varchar2(4),
          col2 varchar2(2),
          col3 varchar2(2),
          col4 varchar2(10));


다음으로 뷰를 생성한다.

create or replace view v1
as
select col4
from t1;


트리거를 생성한다.
8개의 문자가 뷰에 insert가 되면 테이블에 나눠서 입력되는 트리거이다.

SQL>create or replace trigger t1_v1_tri
         instead of insert on v1
        begin
            insert into t1 (col1, col2, co3)
        values(substr(:new.col4,1,4),substr(:new.col4,5,2),substr(:new.col4,6,2));
        end;
        /


뷰에 insert를 해본다.

SQL> insert into v1 values ('20091126');


결과를 확인해본다.

SQL> select * from t1;


결과가 잘 들어간 것을 확인할 수 있다.

COL1 COL2 COL3 COL4
2009 11 12  


출처 : http://blog.naver.com/gseducation?Redirect=Log&logNo=20092680151

'Oracle > PL_SQL' 카테고리의 다른 글

trigger(primary key & foreign key 관련)  (0) 2009.11.28
print_table프로시져 만들기  (0) 2009.11.18
trigger  (0) 2009.11.17
package의 overloading  (0) 2009.11.17
테이블 변경시 관련 procedure, function, package 확인  (0) 2009.11.16
Posted by 자수성가한 부자
Oracle/PL_SQL2009. 11. 18. 14:39


create or replace procedure print_table( p_query in varchar2 )
AUTHID CURRENT_USER
is
    l_theCursor     integer default dbms_sql.open_cursor;
    l_columnValue   varchar2(4000);
    l_status        integer;
    l_descTbl       dbms_sql.desc_tab;
    l_colCnt        number;
begin
    execute immediate
    'alter session set
        nls_date_format=''dd-mon-yyyy hh24:mi:ss'' ';

    dbms_sql.parse(  l_theCursor,  p_query, dbms_sql.native );
    dbms_sql.describe_columns
    ( l_theCursor, l_colCnt, l_descTbl );

    for i in 1 .. l_colCnt loop
        dbms_sql.define_column
        (l_theCursor, i, l_columnValue, 4000);
    end loop;

    l_status := dbms_sql.execute(l_theCursor);

    dbms_output.put_line( '-----------------' );
    while ( dbms_sql.fetch_rows(l_theCursor) > 0 ) loop
        for i in 1 .. l_colCnt loop
            dbms_sql.column_value
            ( l_theCursor, i, l_columnValue );
            dbms_output.put_line
            ( rpad( l_descTbl(i).col_name, 30 )
              || ': ' ||
              l_columnValue );
        end loop;
        dbms_output.put_line( '-----------------' );
    end loop;
    execute immediate
        'alter session set nls_date_format=''dd-MON-rr'' ';
exception
    when others then
      execute immediate
          'alter session set nls_date_format=''dd-MON-rr'' ';
      raise;
end;
/

출처 : http://blog.naver.com/orapybubu?Redirect=Log&logNo=40021496289

'Oracle > PL_SQL' 카테고리의 다른 글

trigger(primary key & foreign key 관련)  (0) 2009.11.28
instead of trigger  (0) 2009.11.18
trigger  (0) 2009.11.17
package의 overloading  (0) 2009.11.17
테이블 변경시 관련 procedure, function, package 확인  (0) 2009.11.16
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/PL_SQL2009. 11. 17. 18:50

trigger(이하 트리거)를 한국어로 번역하면 방아쇠다.
특정 이벤트가 발생하면 자동으로 돌아가는 블럭이라고 한다.

쓰는 형식은 다음과 같다.

create or replace trigger 트리거명
before insert or update of 컬럼명 on 테이블명
for each row
begin
    :new.ename := upper(:new.ename);
end;
/

before         이벤트가 일어나기 전에 실행
after            이벤트가 일어난 후에

for each row ->row trigger(행트리거)
                      없으면 statement trigger(문장 트리거)


그럼 trigger(이하 트리거)를 만들어 보자

트리거를 생성하고, 실습하기 위해 t1테이블을 생성해보자

drop table t1 purge;
create table t1
    (empno number primary key, 
     ename varchar2(10));

트리거를 생성하자. 아래의 트리거는 이름은 t1_ename_tri이고
t1테이블의 ename컬럼에 insert나 update가 row단위로 되면 실행되는 트리거이다.

create or replace trigger t1_ename_tri
before insert or update of ename on t1
for each row
begin
    :new.ename := upper(:new.ename);
end;
/


t1테이블에 데이터를 입력해본다.

insert into t1 values (1, 'aaa');
insert into t1 values (2, 'bbb');
commit;

들어간 데이터를 확인한다.

select *
from t1;

EMPNO ENAME
1 AAA
2 BBB


만약 t1테이블에 ename의 컬럼을 전부 대문자가 아닌, 첫 글자만 대문자로 입력하고 싶을 경우
아래와 같이 트리거를 수정한다.

create or replace trigger t1_ename_tri
before insert or update of ename on t1
for each row
begin
    :new.ename := initcap(:new.ename);
end;
/

데이터를 입력한다.

insert into t1 values (3, 'GGG');
commit;

트리거에 의해 데이터가 제대로 입력되었는지 확인한다.

select *
from t1;


EMPNO ENAME
1 AAA
2 BBB
3 Ggg


트리거 내부에서 에러가 나면 트리거를 유발한 작업이 실패한다.
절대로 안바뀌는 것은 프로그램단에 바뀔 여지가 있는 것은 서버단에 구현.
너무 트리거를 많이 만들지 말 것. 하나의 트리거가 수정되는 경우 연관된 트리거를 찾기가 쉽지 않다.


관련 예제) http://blog.naver.com/orapybubu?Redirect=Log&logNo=40025296984

'Oracle > PL_SQL' 카테고리의 다른 글

instead of trigger  (0) 2009.11.18
print_table프로시져 만들기  (0) 2009.11.18
package의 overloading  (0) 2009.11.17
테이블 변경시 관련 procedure, function, package 확인  (0) 2009.11.16
wrap pld  (0) 2009.11.16
Posted by 자수성가한 부자