이제 나의 인생에는 Ctrl+Z 란 없다.

===========================================================================================================================================
-- Ref 워크샵 1교재 9-4에서 9-15 발췌
-- Ref pdf파일 >> D45639 의 p272
===========================================================================================================================================
본문의 내용은 Oracle Database 10g : Administration WorkshopⅠ 공식교재에서 발췌
===========================================================================================================================================
데이터 조작(Managing Undo Data)
데이터 조작어(DML)는 다음 SQL 문으로 구성됩니다.
 - INSERT
 - UPDATE
 - DELETE
 - MERGE

DML은 항상 트랜잭션의 일부로 실행되며 다음과 같이 될 수 있습니다.
 - ROLLBACK 명령을 사용하여 롤백됨
 - COMMIT 명령을 사용하여 커밋됨

데이터는 DML 클래스에 속하는 SQL 문인 insert, update, delete 및 merge에 의해 
조작되거나 수정됩니다.이러한 명령문은 트랜잭션의 일부로 실행되며 성공한 첫번째 DML
문으로 시작되고 COMMIT 또는 ROLLBACK 명령으로 끝납니다. 트랜잭션은 전체적으로
커밋되거나 전체적으로 롤백됩니다.
롤백은 프로세스 또는 시스템 failure 시에 발생할 수도 있습니다.

===========================================================================================================================================
-- undo data
===========================================================================================================================================

- 언두 데이터는 다음의 특징을 갖습니다.
1. 수정되기 전 원래 데이터의 복사본입니다.
2. 데이터를 변경하는 모든 트랜잭션에 대해 캡처됩니다.
3. 적어도 트랜잭션이 종료될 때까지는 보존됩니다.
4. 지원하는 작업:
 - 롤백작업
 - 일기 일관성 및 Flashback Query
 - 실패한 트랙잭션 recovery

※ 복구

프로세스로 인해 데이터베이스의 데이터가 변경되는 경우 오라클 데이터베이스는 원본의 수정되기 이전값(undo data)을 저장합니다.
언두 데이터를 캡쳐하면 커밋되지 않은 데이터를 Rollback할 수 있습니다. 또한 언두는 읽기 일관성 및 Flashback Query를 지원합니다.

읽기 일관성 Query는 query가 시작된 시점의 데이터와 일치하는 결과를 제공합니다. 읽기 일관성 query가 성공하려면 원래 정보가
계속 언두 정보로 존재해야 합니다. 언두 정보를 보존하고 있는 동안 오라클 데이터베이스는 읽기 일관성 query가 충족되도록 데이터를
재구성할 수 있습니다.

Flashback Query는 어떤 목적을 가지고 과거 특정 시점의 데이터 버전을 요청하는 query입니다. 요청한 과거 특정 시점에 대한 언두 정보가
있는 경우 Flashback Query를 성공적으로 완료할 수 있습니다.

사용자가 트랜잭션의 커밋 또는 롤백을 결정하기 전에 네트워크 오류/클라이언트 컴퓨터 오류(장애)로 인한 사용자의 세션이 비정상적으로
종료되는 경우 트랜잭션이 실패하는데 언두데이터를 통한 트랜색션을 recovery할 수 있습니다. instance crash가 발생하는 경우에도 트랜잭션이
실패할 수 있습니다.

실패한 트랜잭션의 경우 가장 안전한 동작이 선택되며 오라클 데이터베이스는 유저가 수행한 모든 변경 사항을 보존하고 원본 데이터를 복원합니다.

언두 데이타 정보 보존
 - 사용자의 트랜잭션 언두(롤백)
 - 사용자의 트랜색션 종료(커밋)
 - 사용자 세션의 비정상적인 종료(롤백)
 - 종료 명령에 의한 사용자 세션의 정상적인 종료(커밋)
보존되는 언두 데이터의 양과 보존 기간은 데이터베이스 작업량과 데이터베이스 구성에 따라 다릅니다.

언두 세그먼트의 생성 시기와 크기 할당
When generating?
 -  DML 명령문이 수행 시  

※ Undo Segment - Transaction Table slot

트랙잭션을 시작하기 위해서는 UNDO 세그먼트의 트랜잭션 테이블로부터 슬롯을 할당받아야 함을 앞에서 살펴 보았다.
그럼, 트랜잭션이 시작되고 실제 데이타를 갱신하기 위해서는 어떻게 될까?
역시, 비슷한 원리로, 특정블록에 있는 레코를 갱신할때는 그 블록헤더로부터 슬롯(ITL슬롯)을 확보해야 한다.
만약, 어떤 트랙잭션에 의해 이 블록의 데이터가 갱신중이라면, 그 트랜잭션이 종결(커밋 또는 롤백)될 때까지 기다려야 된다.
(블로킹상태)

해당 트랜잭션이 종결(커밋or롤백)된 후 비로소, 해당 블록으로 부터 ITL슬롯을 할당 받아 자신의 트랜잭션을 계속 진행할수 있게 된다.
오라클은 ITL슬롯 부족으로 인한 트랜잭션 블로킹을 최소화하고자 다음과 같은 옵션을 제공한다.

1. initrans : 최초 포맷시에 각 블록에 할당할 ITL슬롯 개수
2. maxtrans : 확장시 할당할수 있는 최대 ITL슬롯 개수
3. pctfree : ITL슬롯 할당용 예약 공간 (이 공간이 다 사용되면 락경합이 발생한다.)

ITL(Interested Transaction List)슬롯에 기록되는 내용은 다음과 같다.
 
 1. ITL슬롯 번호
 2. 트랜잭션ID
 3. UBA(Undo Block Address)
 4. 커밋플래그
 5. Locking 정보
 6. 커밋SCN

Lock Byte
블록내에 존재하는 Lock Byte에 대해 알아보기로 하자.
오라클은 저장되는 로우단위로 그 헤더에 Lock Byte를 할당하여 갱신중인 ITL슬롯 번호를 기록한다.
이것으로 해당 로우가 갱신중이라는 사실을 알릴수 있다.
이것이, 로우단위Lock이다.
이와 같이 오라클은 로우단위의 Lock을 속성으로 갖고 있어 Lock 에스컬레이션 메커니즘이 전혀 불필요.

다른 DBMS의 Lock메카니즘.
1. 다른 DBMS는 Lock매니져를 두고 관리.
2. Lock매니져 또한 리소스를 소비하게 된다.
3. 대용량의 갱신이 발생하면 블록단위 혹은 테이블 단위로 Lock 에스컬레이션이 발생.
4. 그 순간은 동시성이 현저히 저하.

===========================================================================================================================================
출처 : http://www.gurubee.net/display/DBSTUDY/Undo?
===========================================================================================================================================
1. Undo
 - 트랜색션이 발생시킨 테이블과 인덱스에 대한 변경사랑들이 Undo 레코드 단위로 Undo 세그먼트(블록)에 기록
 - 트랜잭션 : Undo 세그먼트 → N : 1
   9i부터는 AUM에 의해 1:1을 목표로 자동 관리

2. Undo의 목적

3. Undo 세그먼트
 - Undo 세그먼트는 일반 테이블 세그먼트와 다르지 않다.
 - Undo 세그먼트의 블록도 버퍼캐시에 캐싱

4. 버전별 Undo 기능 

undo_retention (파라미터)
 - 트랜젝션이 완료 되었어도 지정된 시간(초) 동안은 가급적 Undo 세그먼트를 재사용하지 않도록 함
   (active → unexpired → expired)

dba_tablespaces.retention (테이블스페이스 속성)
 - alter tablespace undotbs1 retention (guarantee, noguarantee);

Automatic Undo Retention Tuning (tuned_undo_retention)
 - 10gR1 - undo_retention 을 0 으로 설정
 - 10gR2 - Undo 테이블스페이스의 retention 속성을 noguarantee 로 설정

5. Undo 세그먼트

 Undo 헤더(Initial Extent)
 - Transaction Table 슬롯

 - 트랜잭션의 시작/종료  

Undo 레코드

Undo 레코드 체인
 - Last UBA 로 구성

6. v$transaction

   레코드를 갱신 하기 위해서는, 해당 블록 헤더 ITL 슬롯 확보
    - ITL 슬롯 확보 될때까지 enq: TX - allocate ITL entry (대기이벤트) 와 함께 트랜잭션이 블로킹됨
    - ITL 슬롯 부족을 극복하기 위해, INITTRANS, MAXTRANS, PCTFREE 파라미터 활용
       → 10g 부터 INITTRANS 는 최소2, MAXTRANS 는 255 고정
       → 블록에 여유공간이 없는경우 추가 슬롯 생성이 불가능 (PCTFREE)

8. Lock Byte
레코드가 저장되는 ROW마다, 헤더에 Lock Byte를 할당해, 트랜잭션의 ITL 슬롯 번호를 기록해 둔다. (Row-level Lock)

레코드 갱신 시도시

※ 참조문서
블로그(오라클 성능 문제에 대한 통찰) : http://ukja.tistory.com/252
위키(오라클클럽) : http://wiki.oracleclub.com/pages/viewpage.action?pageId=3900637
서적(오라클 성능 고도화 원리와해법 I) : http://book.daum.net/detail/book.do?bookid=KOR9788996246015

===========================================================================================================================================
※ 사용중인 Undo Block 수/Undo record 양
SQL> select s.sid, s.serial#, t.xidusn, t.used_ublck, t.used_urec
     from v$session s, v$transaction t
     where t.addr=s.taddr;

※ DML별 Undo 레코드 기록 내용
 - Insert: 추가된 레코드의 rowid
 - Update: 변경되는 컬럼에 대한 before imgae
 - Delete: 지워지는 모든 로우의 모든 컬럼에 대한 before image

※ Undo 관련 Parameter
 - UNDO_MANAGEMENT(default Auto)
 - UNDO_RETENTION (default 900)

언두 세그먼트의 자동 확장 /축소

 - undo tablespace는 instance당 하나만을 가진다.
 - undo tablespace는 (1-10)개로 이루어져 있으며, 이중 하나는 system사용 공간이다.
 - undo segment는 최소 2개의 extend를 할당받는다.

 - session에 따른 segment space의 할당 방식
 - 하나의 undo segment는 여러개의 TX(session A, session B)를 보유할 수 있다.
 - 하나의 TX는 하나의 undo segment만을 이용할 수 있다.

언두 세그먼트의 축소
 - 언두 세그먼트를 절단(Truncate)했을 경우
 - 언두 세그먼트에 Shrink를 수행했을 경우(수동으로 언두 세그먼트 축소시키는 옵션)
 - 언두 세그먼트에 Optimal 크기를 할당했을 경우(12시간 마다 자동으로 비사용 EXTENT 반납)

===========================================================================================================================================
트랜잭션 및 언두 데이터
 - 각 트랜색션은 하나의 언두 세그먼트에만 할당.
 - 하나의 언두 세그먼트는 한 번에 여러개의 트랜잭션을 처리할 수 있습니다.

트랜색션이 시작되면 해당 트랜잭션은 언두 세그먼트에 할당되며, 트랜잭션이 진행되는 동안 데이터가 변경되면 변경되기 전 원래의 값이
언두 세그먼트에 복사됩니다.

Dynamic Performance View → v$transaction을 확인하여 어느 트랜잭션이 어느 언두 세그먼트에 할당되었는지 알 수 있습니다.
언두 세그먼트는 데이터 블록으로 구성된 Extent로 구성, 필요한 경우 자동으로 확장/축소(shrink)되며 활당된 트랜잭션에 대해
순환 저장 버퍼처럼사용 됩니다. 모든 Extent가 사용된 후에 트랜잭션은 첫번째 Extent로 다시래핑(wraps around back)하거나
언두 세그먼트에 새 Extent를 할당할 것을 요청합니다.

Note: Parallel DML 작업으로 인해 실제로 트랜잭션이 두 개 이상의 세그먼트를 사용할 수 있습니다.
Parallel DML 실행에 대한 자세한 내용은 Oracle Database Administrator’s Guide 10g를 참조하십시오

===========================================================================================================================================언두 정보 저장
언두 정보는 언두 세그먼트에 저장되며 언두 세그먼트는 하나의 언두 테이블스페이스에 저장됩니다.
언두 테이블스페이스의 특징은 다음과 같습니다.
 - 언두 세그먼트에만 사용됩니다.
   언두 세그먼트는 항상 SYS가 소유하며, 세그먼트는 순환 버퍼처럼 사용되므로 각 세그먼트는 최소 두 개의 Extent를 갖는다.
   최대 Extent 수의 기본값은 데이터베이스 블록 크기에 따라 다르지만 매우 큽니다.(블록 크기가 8KB인 경우 32,765개)
 
 - recovery 시 특별한 고려 사항이 있습니다.
   instance crash 등으로 인해 실패한 트랜색션을 recovery하는 경우에는 언두 데이터가 필요하므로 언두 테이블스페이스는 instance가 MOUNT 상태
   일 때만 recovery할 수 있습니다.

 - 단일 instance와만 연관됩니다.

 - 여러 언두 테이블스페이스 중 하나만 주어진 시간에 주어진 instance에 대해 현재 쓰기가 가능해야 합니다.
   데이터베이스에는 여러 언두 테이블스페이스가 있을 수 있지만 특정 시점에서 그 중 하나만 언두 데이터가 기록되는
   현재 언두 테이블스페이스로 지정될 수 있습니다.

언두 테이블스페이스는 자동 Extent 할당을 사용하는 영구적인 로컬관리방식의 테이블스페이스로, recovery 방법을 제외하고 다른 테이블스페이스와
같은 방법으로 관리됩니다.

===========================================================================================================================================언두 데이터와 리두 데이터 비교

언두 데이터는 변경사항을 언두해야 하는 경우에 필요하며 읽기 일관성 및 롤백에 대해 발생합니다.
리두 데이터는 데이터를 분실하여 변경 사항을 다시 수행해야 하는 경우에 필요합니다.

커밋 프로세스는 트랜잭션의 변경 사항을 디스크에 영구 저장되는 리두 로그 파일에 기록되는지 검증합니다.
변경 사항(테이블의 블록)이 실제로 저장되는 데이터 파일(*.dbf)에 기록되지 않아도 변경 사항이 리두 로그 파일에 기록됩니다.
(참고: Before DBWn writes → LWRn는 redo log buffer에 변경 트랜잭션 정보인 redo entry를 리두 로그 파일에 기록합니다.)

커밋된 변경 사항이 데이터 파일에 반영되기 직전에 정전이 발생해도 트랜잭션이 커밋된 상태(리두로그파일 기록)이기 때문에 instance를
다시 시작하면 SMON(Background Process) 프로세스는 리두 로그 파일로 Roll forward를 하며, 언두 데이타로 Roll back을 하고,
Control file의 SCN과 Data file의 SCN을 맞춰 동기화를 시킨다.(instance recovery)

===========================================================================================================================================언두 모니터
일반적으로 언두는 관리가 거의 필요 없으며 다음과 같은 영역을 모니터합니다.
 - 언두 테이블스페이스의 사용 가능한 공간
 - "Snapshot too old" 오류

언두 정보는 항상 트랜잭션이 종료될 때까지 보존됩니다. 그러므로 매우 큰 데이터를 커밋하지 않고 삭제 또는 갱신
(삽인된 데이터는 원래 이미지가 NULL 값이므로 삽입 작업은 undo space를 거의 사용하지 않음)
하는 경우에는 언두 테이블스페이스가 원본 데이터를 포함할 만큼 커야 합니다.

다음 명령으로 50GB의 테이블에 있는 모든 행을 삭제한다고 가정해 보자.
SQL> delete from reallybigtable;

이 명령문을 실행한 사용자는 롤백을 하려면 언두 테이블스페이스의 공간을 원본(변경전 데이타의 크기) 정보에 대한 공간을 확보해야 합니다.
언두 테이블스페이스에 대한 공간 부족시 오라클은 사용자에게 'ORA-01650: unable to extend rollback segment' 오류 메시지를 수신합니다.

사전 모니터(Proactive Monitoring)를 통해 언두 테이블스페이스의 공간 문제가 유저에게 영향을 주기 전에 감지할 수 있습니다.

관리자가 언두 정보와 관련하여 직면할 수 있는 또 다른 문제는 query가 이미 겹쳐쓴 언두 정보에 액세스해야 하는 경우입니다.
이 문제는 장기 실행되는 query 또는 Flashback Query에서 발생할 수 있습니다. query에 과거 특정 시점의 데이터 "스냅샷"이 필요하고
이 스냅샷을 재구성하는데 더 이상 존재하지 않는 언두 데이터가 필요한 경우 query는 다음 오류를 반환합니다.
ORA-01555: snapshot too old

read consistency가 깨지는 경우라고 할 수 있습니다. 따라서 언두 retention은 장기 실행 query를 수용하도록 구성되어야 합니다.

===========================================================================================================================================언두 관리

언두 관리를 통해 다음 오류를 방지해야 합니다.
 - 언두 테이블스페이스의 공간 오류 (ORA-01650: unable to extend rollback segment)
   ① 언두 테이블스페이스 크기를 적절히 조정
   ② 대형 트랜잭션을 주기적으로 커밋

 - "Snapshot too old" 오류 (ORA-01555: snapshot too old)
   ① 적절한 언두 retention 간격 구성
   ② 언두 테이블스페이스의 크기를 적절히 조정
   ③ 언두 retention 보장을 고려

자동 언두 관리 사용
 - UNDO_MANAGEMENT=AUTO (권장)
 - UNDO_TABLESPACE=UNDOTBS1

DBA는 자동 언두 관리를 사용하여 테이블스페이스 레벨에서 언두를 관리하고 instance가 사용하는 테이블스페이스를 언두하는
UNDO_TABLESPACE 초기화 파라미터를 사용하여제어합니다.
언두 테이블스페이스를 선택한 경우 관리자는 충분한 공간을 제공하고 언두 retention 간격을 구성하는 데만 신경쓰면 됩니다.
수동 관리를 사용하는 경우 DBA는 다음 사항도 고려해야 합니다.
 ① 최대 Extent 수 및 Extent 크기 조정을 포함한 세그먼트 크기 조정
 ② 차단 중인 트랜잭션 식별 및 제거
 ③ 트랜잭션 처리에 충분한 롤백 세그먼트 생성 (수동 모드에서는 언두 세그먼트를 롤백 세그먼트라고 함)
 ④ 롤백 세그먼트를 포함할 테이블스페이스 선택 (언두 테이블스페이스는 자동 언두 관리와함께 사용할 때만 지원됨)

===========================================================================================================================================언두 세그먼트의 종류 및 관리 방식
언두 세그먼트의 종류
 - 시스템 언두 세그먼트
   시스템 테이블스페이스에 존재하는 오브젝트가 변경될 경우 사용되는
   언두 세그먼트 데이터베이스 생성시 시스템테이블스페이스에 자동으로 생성된다.

 - 비 시스템 언두 세그먼트
   일반 유저의 DML 작업시 언두 데이터를 저장하기 위해 사용

 - 지연 언두 세그먼트
   오프라인, 임시 For Recovery상태 진행중인 작업에 대해 복구를 수행하기 위해
   해당 테이블스페이스에 대한 언두 세그먼트를 생성

언두 세그먼트 관리 방식 

===========================================================================================================================================언두 테이블스페이스 관리
언두 테이블스페이스 변경
 - 데이터베이스 생성 시 언두 테이블스페이스 생성
 - 데이터베이스 생성 후 언두 테이블스페이스 생성

언두 테이블스페이스 제거
 - 데이터 파일 추가
 - 데이터 파일 이름 변경
 - 데이터 파일 상태 변경(온라인에서 오프라인으로 변경 시)

언두 테이블스페이스 교체
언두 테이블스페이스 생성(데이터베이스 생성 시)
SQL> create database test
     ...[생략]
     undo tablespace undoo_tbs
     datafile '/경로/xxx.dbf' size 100m;

언두 테이블스페이스 생성(테이터베이스 생성과 별도로 생성 시)
SQL> create undo tablespace undo_tbs
     datafile '/경로/xxx.dbf' size 100m;

언두 테이블스페이스 변경
SQL> alter tablespace undo_tbs
     add datafile '/경로/xxx.dbf' size 100m;

언두 테이블스페이스 삭제
SQL> drop tablespace undo_tbs;

언두 테이블스페이스 교체
SQL> alter system set UNDO_TABLESPACE=undo_tbs; 

===========================================================================================================================================언두 세그먼트 확인
언두 관련 내용을 확인 할수 있는 데이터 딕셔너리 뷰 및 동적 성능 뷰
 - DBA_ROLLBACK_SEGS
   현재 데이터베이스에 존재하는 모든 언두 세그먼트에 대한 내용 조회
 
 - V$ROLLSTAT
   현재 데이터베이스에 존재하는 언두 세그먼트 중 온라인 상태인 언두 세그먼트에
   대한 내용 조회가 가능
 
 - V$ROLLNAME
   모든 언두 세그먼트의이름을 확인

 - V$UNDOSTAT
   언두 테이블스페이스에 대한 모니터링 및 튜닝을 위한 정보를 조회

===========================================================================================================================================언두 Retention 구성

UNDO_RETENTION은 이미 커밋된 언두 정보의 보관 기간을 초 단위로 지정합니다.
UNDO_RETENTION 파라미터는 다음과 같은 경우에만 설정합니다.
 - 언두 테이블스페이스에서 AUTOEXTEND 옵션이 활성화된 경우
 - LOB에 대해 언두 retetion을 설정할 경우
 - retetion을 보장하려는 경우

AUTOEXTEND 언두 테이블스페이스의 경우 시스템은 최소한 이 파라미터에 지정된 시간 언두를 보관하고
query의 언두 요구 사항을 충족하도록 언두 retention 기간을 자동으로 튜닝합니다.

고정 길이 언두 테이블스페이스의 경우 시스템은 언두 테이블스페이스 크기 및 과거 사용 기록에 따라
가능한 최대 언두 retention 기간을 자동으로 튜닝하고 retenton 보장이 활성화되 않을 경우

UNDO_RETENTION을 무시합니다. 따라서 자동 언두 관리에서는 나열된 세 가지 경우에 UNDO_RETENTION 설정이 사용됩니다.
이러한 세 가지 경우가 아니면 이 파라미터는 무시됩니다.
언두 정보는 다음의 세 가지 범주로 나뉩니다.

 - 커밋되지 않은 언두 정보: 현재 실행 중인 트랜잭션을 지원하며 유저가 롤백하려는 경우나
   트랜잭션이 실패한 경우에 필요합니다. 커밋되지 않은 언두 정보는 겹쳐쓰이지 않습니다.

 - 커밋된 언두 정보: 실행 중인 트랜잭션을 지원하는 데는 더 이상 필요하지 않지만 언두
   retention 간격을 만족시키는 데에는 여전히 필요합니다. "만료되지 않은" 언두 정보라고도 합니다.
   커밋된 언두 정보는 활성 트랜잭션이 공간 부족(ORA-01650)으로 인해 실패하는 일이 없도록
   하는 한도 내에서 보존됩니다.

 - 만료된 언두 정보: 실행 중인 트랜잭션을 지원하는 데 더 이상 필요하지 않습니다.
   만료된언두 트랜잭션은 활성 트랜잭션에서 공간이 필요하면 겹쳐쓰입니다.

기본적으로 언두 작업은 undo space 부족으로 인해 활성 트랜잭션이 실패하지 않도록 아직 만료되지 않은 커밋된 트랜잭션을 겹쳐씁니다.
이 작업은 retention을 보장하여 변경할 수 있습니다. retention을 보장하면 언두 retention 설정으로 인해 트랜잭션이 실패하더라도
언두 retention 설정을 시행합니다.

RETENTION GUARANTEE는 초기화 파라미터라기보다는 테이블스페이스 속성입니다. 이 속성은 SQL 명령행 문을 통해서만 변경할 수 있습니다.
retention을 보장하도록 언두 테이블스페이스를 변경하는 구문은 다음과 같습니다.
SQL> ALTER TABLESPACE undotbs1 RETENTION GUARANTEE;

보장된 언두 테이블스페이스를 일반 설정으로 되돌리려면 다음 명령을 사용하십시오.
SQL> ALTER TABLESPACE undotbs1 RETENTION NOGUARANTEE;

retention 보장은 언두 테이블스페이스에만 적용됩니다. 비언두 테이블스페이스에 retention 보장을
설정하려고 하면 다음 오류가 발생합니다.
SQL> ALTER TABLESPACE example RETENTION GUARANTEE;
ERROR at line 1:
ORA-30044: 'Retention' can only specified for undo tablespace

※ GUARANTEE 설정 확인
SQL> select tablespace_name, retention
     from dba_tablespaces
     where tablespace_name='UNDOTBS1';

===========================================================================================================================================

언두 테이블스페이스의 크기 조정
언두 테이블스페이스에 모든 트랜잭션의 원래 정보가 포함될 수 있도록 언두 테이블스페이스 크기를 조정해야 합니다.
Enterprise Manager의 Administration 페이지에서 Undo Management 링크를 누르면 현재 설정,
분당 언두 사용량 및 지정한 기간 동안 발견된 가장 오래 실행 중인 query를 포함하여 시스템 언두의 개요를 확인할 수 있습니다.

언두 테이블스페이스에 속한 데이터 파일에 공간이 부족하면 데이터 파일이 자동으로 확장될 수 있습니다.
다른 테이블스페이스와 달리 언두 테이블스페이스에서는 연관된 데이터 파일의 자동 확장을 활성화하지 않을 것이 좋습니다.

undo space 데이터 파일 자동 확장 기능을 활성화할 수 있지만 테이블스페이스의 크기를 적절하게 조장한 다음에는 데이터 파일 자동 확장
기능을 비활성화해야 합니다. 비활성화하면 단일 사용자가 트랜잭션을 커밋하지 않아 실수로 디스크 공간을 많이 사용하는 것을 방지할 수 있습니다.

===========================================================================================================================================

Undo Advisor 사용
Undo Management 속성 페이지를 통해 Undo Advisor에 액세스할 수 있습니다. 또한 지정된 언두
retention을 만족시키는 데 필요한 언두 테이블스페이스 크기를 예측하여 제공합니다.
원하는 retention 기간을 입력하면 Advisor의 분석 영역에 retention 기간을 지원하는 데 필요한
테이블스페이스 크기가 표시됩니다. 또한 그래프의 한 지점을 눌러 선택한 기간을 지원하는 데
필요한 테이블스페이스 크기를 확인할 수 있습니다.
언두 retention 기간을 선택한 후에는 OK를 눌러 새 retention 기간을 구현합니다.

Oracle9i Dataguard 구성 방법
출처: 민연홍│DBA LG카드 중형서버운영파트  

미국의 911테러 이후 전세계 IT시스템의 화두는, 자연재해 또는 테러로 인해 서비스 손실을 입게 될 경우에도 이를 복구할 수 있는 Standby 시스템을 구축하는 것이 되었다. 서버뿐만 아니라 디스크 및 백업장비까지 손실되었을 경우에도 다른 지역에서 서비스를 기동할 수 있는 시스템 구성이 각광받게 된 것이다. 이러한 Standby시스템에서 오라클의 dataguard는 데이터 무손실을 구현할 수 있는 방법으로, 한국에서는 여러 금융기관에서도 사용하고 있다. 여기서는 dataguard에 대한 간단한 소개와 그 구성방법에 대해서 알아본다. 

PartⅠ. dataguard 개요 및 아키텍처  

1) dataguard 란 무엇인가?

- primary DB와 standby DB를 동기화시켜, primary DB가 하드웨어 장애 등의 문제가 생겼을 경우 standby DB로 failover 또는 switchover 시킬 수 있는 시스템 구성을 말한다.
- Oracle Net을 통해서 primary DB의 변경정보를 standby DB로 적용시켜 운영된다.

 2) switchover and failover 
① 자동실행이 아니라 DBA가 action을 취해야 한다. 

② switchover
- OS 작업 또는 서버 PM작업 시 사용(primary -> standby , standby -> primary)

③ failover
- 디스크 fail 등 긴급상황에서 사용, dataguard 재구성 필요

3) standby DB의 종류
① Physical standby database
- block 대 block 기반으로 primary DB의 redo log를 적용시켜 standby DB를 동기화

② Logical standby database
- 같은 schema 정의로 공유
- primary DB의 sql 문장을 standby DB에 적용

4) dataguard의 서비스 종류
① Log transport Services
- primary DB에서 standby DB로 redo log 정보를 자동으로 전송

② Log Apply Services
- redo log를 standby DB에 적용

③ Role Management Service
- 데이터베이스는 primary/standby로 두 가지의 상대적으로 배타적인 role을 가진다.
Role Management Service는 log transport service와 log apply service를 failover 또는 switchover의 상황에 동적으로 변경할 수 있다.

5) protection mode
① Maximum Protection - primary DB와 standby DB의 redo log를 동기화 시킨다.
standby DB가 네트워크 이상 등의 이유로 standby로의 전송이 안될 경우 primary DB를 halt시킨다.
데이터는 서로 동기화되어 primary DB에서 commit을 하게 되면 standby DB에서 commit이 완료될 때까지 primary DB에서 commit 완료를 하지 않는다.
성능에는 문제를 줄 소지가 있으나 failover 상황이 오더라도 데이터 손실은 없다. physical standby DB에만 가능하다.

② Maximum availability - Maximum Protection과 마찬가지로 primary DB와 standby DB를 동기화시킨다.
단, standby DB가 네트워크 문제 등의 이유로 전송이 안될지라도 halt되지는 않는다.
데이터는 maximum protection과 마찬가지로 primary DB에서 commit을 하게 되면 standby DB에서 commit이 완료될 때까지 primary DB에서 commit 완료를 하지 않는다. 만약 standby DB가 unavailable상태일 경우 임시로 불일치 시킨다.
또 다시 standby DB가 available하면 자동으로 동기화 시킨다. 성능에는 문제를 줄 소지가 있으나 failover 상황이 오더라도 데이터 손실은 거의없다. physical standby, logical standby DB 모두 가능하다.

③ Maximum Performance - default protection mode이다. primary data에 대한 protection이 가장 낮다.
primary database에 transaction이 수행되면 이것을 asynchronous 하게 standby DB에 적용한다.
즉, maximum protection, maximum availability의 경우에는 standby DB에 적용(commit) 될 때까지 primary db의 transaction 이 적용(commit)되지 않았으나, Maximum Performance 모드에서는 비 동기화 시키므로 primary DB에서 standby DB가 transaction 적용이 끝날 때까지 기다리지 않는다. 즉 standby db의 문제로 인해서 primary DB에 성능영향이 가지 않는다.
단, failover시에는 약간의 데이터 손실을 가져올 수 있다.

6) dataguard의 시스템 구성(2가지 종류)
① physical standby database 구성 (LGWR process를 사용한 Physical standby DB)
Archiving to a Physical standby Destination Using the Logwriter Process

- primary db의 LGWR 프로세스가 standby DB로 redo log를 보내고, standby DB의 RFS 프로세스가 redo log를 standby redo log에 적용시킨다. archiving되면 archived redo logs가 되고 이것을 MRP process가 standby DB에 적용시킨다.

② logical standby DB 구성
Archiving to a Logical standby Destination Using the Logwriter Process

- logical standby DB는 primary DB에서 수행된 SQL문장을 LGWR프로세스가 standby DB로 보내고 RFS 프로세스가 받아서 Archived redo logs에 쓴다. LSP (Logical standby process)가 standby DB에 적용시킨다.

- primary DB에서 log switch가 일어나게 되면 standby DB의 RFS 프로세스에 이를 알려주어 log switch가 되도록 한다.

PartⅡ. standby DB 기동방법

- 주의 standby db의 startup 방식을 보면 아래와 같다. 아래 그림을 기억해두면 편하다.

① standby DB를 read only mode에서 managed recovery mode로 변경
- 그대로 명령 또는 shutdown immediate 이후 재기동

- 첫번째 방법
SQL> alter database open read only;
SQL> recover managed standby database disconnect;

- 두번째 방법
SQL> shutdown immediate
SQL> startup nomount
SQL> alter database mount standby database;
SQL> recover managed standby database disconnect;

② shutdown 에서 managed recovery mode 로 변경
SQL> startup nomount
SQL> alter database mount standby database;
SQL> recover managed standby database disconnect;

③ managed recovery mode 에서 read only mode 로 변경
SQL> recover managed standby database cancel;
SQL> alter database open read only;

④ read only standby DB 에서 managed recovery mode로 변경
(먼저 standby DB에 연결된 모든 세션을 종료)
SQL> recover managed standby database disconnect;

- 만약 유저의 세션 때문에 실패할 경우
SQL> shutdown immediate
SQL> startup nomount
SQL> alter database mount standby database;
SQL> recover managed standby database disconnect; TOP

PartⅢ. 시스템 구축 (실습)

- 실습에서 사용 할 primary DB 이름은 MIN 이고, standby DB 이름은 STBY 이다.
- 여기서는 하나의 서버에서 2개 DB를 구성하는 방법으로 수행한다.
- 서로 다른 두 대의 서버에서도 같은 방법으로 구성 할 수 있다.
- primary DB는 /data1/oradata/MIN에 구성되어 있다.
- standby DB는 /data1/oradata/STBY에 구성되어 있다.

1) 리스너 설정 및 기동

아래와 같은 네트워크 설정을 해준다. 각 서버마다 설정해준다.
- MIN DB에서 설정(primary DB)

vi $ORACLE_HOME/network/admin/listener.ora
smsvr1_MIN =
   (ADDRESS_LIST =
         (ADDRESS= (PROTOCOL= TCP)(Host= smsvr1)(Port=2001))
   )
SID_LIST_smsvr1_MIN =
 (SID_LIST =
   (SID_DESC =
     (ORACLE_HOME= /u/pkg/oracle/product/9.2.0)
     (SID_NAME = MIN)
   )
 )

-STBY DB 에서 설정(physical standby DB)

vi $ORACLE_HOME/network/admin/listener.ora
smsvr1_STBY =
   (ADDRESS_LIST =
         (ADDRESS= (PROTOCOL= TCP)(Host= smsvr1)(Port=2002))
   )
SID_LIST_smsvr1_STBY =
   (SID_LIST =
    (SID_DESC =
     (ORACLE_HOME= /u/pkg/oracle/product/9.2.0)
    (SID_NAME= STBY)
   )
  )

2) tnsnames.ora 설정

tnsnames.ora 파일을 설정한다. 서로 네트워크가 가능하도록 하는데 이름을 재대로 써야 한다.
초기화 파라미터에서 log_archvie_dest_2='service=STBY LGWR SYNC AFFIRM' 일 경우 STBY는 tnsnames.ora 에서의 접속이름을 말한다.

- MIN DB 설정 primary DB에서 설정 ( standby DB로 가는 네트워크 구성)

vi $ORACLE_HOME/network/admin/tnsnames.ora
STBY =
  (DESCRIPTION =
     (ADDRESS = (PROTOCOL= TCP)(Host= smsvr1)(Port= 2002))
     (CONNECT_DATA = (SID = STBY))
  ) 

- STBY DB 설정, standby DB에서 설정 (primary DB로 가는 네트워크 구성)

vi $ORACLE_HOME/network/admin/tnsnames.ora
MIN=
  (DESCRIPTION =
     (ADDRESS = (PROTOCOL= TCP)(Host= smsvr1)(Port= 2001))
     (CONNECT_DATA = (SID = MIN))
  ) 

3) 오라클 초기화 파라미터 설정

- MIN DB (primary DB)

vi $ORACLE_HOME/dbs/initMIN.ora
db_name=MIN
compatible=9.2.0
control_files=('/data1/oradata/MIN/control01.ctl','/data1/oradata/MIN/control02.ctl')
shared_pool_size=64M
db_cache_size=16M
undo_management=auto
background_dump_dest=/data1/oradata/MIN/bdump
user_dump_dest=/data1/oradata/MIN/udump
core_dump_dest=/data1/oradata/MIN/cdump
log_archive_start=true
log_archive_dest_1="location=/data1/oradata/MIN/archive1"
log_archive_format=%t_%s.arc
#### 데이터가드를 위해서 변경하지 말 것
remote_archive_enable=true
dg_broker_start=true
log_archive_dest_state_1=enable
log_archive_max_processes=3
standby_file_management=auto
db_file_name_convert='/data1/oradata/STBY','/data1/oradata/MIN'
log_file_name_convert='/data1/oradata/STBY','/data1/oradata/MIN'
standby_archive_dest='/data1/oradata/MIN/archive2'
##### standby DB이면 열고, primary DB이면 닫는다.
#fal_server=STBY
#fal_client=MIN
#lock_name_space=STBY
## primary DB이면 열고, standby DB이면 닫는다.
log_archive_dest_2='SERVICE=STBY LGWR SYNC'

- STBY DB (standby DB) -주의할 것은 DB이름은 MIN 이며 instance 이름과 SID는 STBY 이다.
즉, 기동을 할 때에도 ORACLE_SID=STBY 로 설정하여 기동한다.

vi $ORACLE_HOME/dbs/initSTBY.ora
db_name=MIN
compatible=9.2.0
control_files=('/data1/oradata/STBY/control01.ctl','/data1/oradata/STBY/control02.ctl')
shared_pool_size=64M
db_cache_size=16M
undo_management=auto
background_dump_dest=/data1/oradata/STBY/bdump
user_dump_dest=/data1/oradata/STBY/udump
core_dump_dest=/data1/oradata/STBY/cdump
log_archive_start=true
log_archive_dest_1="location=/data1/oradata/STBY/archive1"
log_archive_format=%t_%s.arc
### 데이터가드를 위해서 변경하지 말 것
remote_archive_enable=true
dg_broker_start=true
log_archive_dest_state_1=enable
log_archive_max_processes=3
standby_file_management=auto
db_file_name_convert='/data1/oradata/MIN','/data1/oradata/STBY'
log_file_name_convert='/data1/oradata/MIN','/data1/oradata/STBY'
standby_archive_dest='/data1/oradata/STBY/archive2'
## standby DB일 경우 아래를 열기, primary DB일 경우 닫기
fal_server=MIN
fal_client=STBY
lock_name_space=STBY
##primary DB이면 열고, standby DB이면 닫는다.
#log_archive_dest_2='SERVICE=MIN LGWR SYNC'
 

-초기화 파라미터 설정에서 주의해야 할 것을 먼저 보면,
standby_file_management=auto 로 되어 있어야 primary DB에서 물리적인 테이블스페이스 및 데이터파일 추가할 경우 standby DB에 자동으로 생성된다.

standby_file_management=auto로 되어 있을 경우
db_file_name_convert='/data1/oradata/STBY','/data1/oradata/MIN'

log_file_name_convert='/data1/oradata/STBY','/data1/oradata/MIN'
의 파라미터에서 ' A 부분','B 부분'에서 B부분이 자신의 primary DB의 경로를 말하고 A부분이 변환할 standby DB의 경로를 말한다. 파라미터를 확인해보자.

fal_server, fal_client 는 standby DB에서만 사용한다. fal_server는 primary DB를 설정하고 fal_client는 standby DB를 설정해둔다. 이것을 설정할 경우 primary DB와 standby DB에 redo log의 gap이 발생했을 경우 자동으로 맞추어주는 역할을 한다.

fal_server=MIN
fal_client=STBY

lock_name_space는 한 대의 서버에서 primary, standby DB를 운영할 경우 사 용한다. 앞에서 말한 바와 같이 primary , standby DB db_name은 같으며 instance_name(SID)만 다를 뿐이다. 같은 DB이름을 가진 instance를 한 대의 서버에서 기동하기 위해서는 lock_name_space를 지정해 주어야 한다. 만약 두 대의 서버에서 구성한다면 lock_name_space파라미터는 지정할 필요가 없다.
이것은 standby DB에서만 지정한다.

lock_name_space=STBY

4) primary DB를 online backup으로 standby DB 위치로 restore

<MIN DB primary DB>

- primary DB를 24시간 서비스 이므로 shutdown이 불가능한 것을 가정하에 구성한다.
- primary DB를 online backup으로 복사한다.
- online backup을 하는 것이므로 primary DB의 redo log는 standby DB로 전송하지 않는다. standby DB구성 시 자동으로 standby DB에서 redo log가 생성된다.

SQL> select tablespace_name, file_name, bytes/1024/1024 mega from dba_data_files;
 
TABLESPACE_NAME         FILE_NAME                           MEGA
------------------------------------------------------------------
SYSTEM                  /data1/oradata/MIN/system01.dbf     250
UNDOTBS                 /data1/oradata/MIN/undotbs.dbf      100
USERS                   /data1/oradata/MIN/users01.dbf      100
SQL> select name , bytes/1024/1024 mega from v$tempfile; 
NAME                                  MEGA
----------------------------------------------
/data1/oradata/MIN/temp01.dbf         100
- 여기서는 cp 명령이 standby DB로 전송하는 것을 뜻한다. ftp로 primary db의 백업을 전송한다.
   SQL> alter tablespace system begin backup;
   SQL> !cp /data1/oradata/MIN/system01.dbf /data1/oradata/STBY/system01.dbf
   SQL> alter tablespace system end backup;
   SQL> alter tablespace undotbs begin backup;
   SQL> !cp /data1/oradata/MIN/undotbs.dbf /data1/oradata/STBY/undotbs.dbf
   SQL> alter tablespace undotbs end backup;
   SQL> alter tablespace users begin backup;
   SQL> !cp /data1/oradata/MIN/users01.dbf /data1/oradata/STBY/users01.dbf
   SQL> alter tablespace users end backup;
  
  
- tempfile은 그대로 복사를 한다. begin backup, end backup 이 필요 없다. 단 tempfile 이어야 한다.
   SQL> !cp /data1/oradata/MIN/temp01.dbf /data1/oradata/STBY/temp01.dbf 

5) primary DB에서 standby control file을 생성해서 standby DB로 전송

<MIN DB primary DB>

- primary DB에서 standby control file을 생성해서 standby DB로 전송한다

SQL> alter database create standby controlfile as '/data1/oradata/STBY/stbyctl.ctl';

6) standby DB에서 사용할 control file을 배치

<STBY DB standby DB의 control file>

- standby DB에서 사용할 control file을, standby DB의 초기화 퍼라미터(initSTBY.ora)파일에 있는 control file 위치에 배치한다.

SQL> !cp /data1/oradata/STBY/stbyctl.ctl /data1/oradata/STBY/control01.ctl
SQL> !cp /data1/oradata/STBY/stbyctl.ctl /data1/oradata/STBY/control02.ctl

7) standby DB 기동

<STBY DB standby DB 에서 수행>

- standby DB를 기동시킨다. startup mount standby database 라는 명령은 없다. nomount까지 기동한 후 standby DB로 mount를 한다.

SQL> startup nomount
SQL> alter database mount standby database;

8) standby DB에 standby redo log file 생성

<STBY DB standby DB에서 수행>

우리는 처음으로 standby DB를 구성하였으므로 standby redo log를 추가해 주어야 한다.
여기서 중요한 것은 primary redo log와 standby redo log가 같은 크기를 가지고 있어야 한다.
만약 다를 경우에는 차후에 ORA-16139 media recovery required 에러가 발생하면서 takeover나 failover가 정상적으로 수행되지 않을 수 있다.

SQL> select * from v$logfile;
   GROUP#STATUS     TYPE       MEMBER
------------------------------------------------------------------
     1             ONLINE     /data1/oradata/STBY/log01a.log
     2             ONLINE     /data1/oradata/STBY/log02a.log
     3                        /data1/oradata/STBY/log03a.log
 
SQL> alter database add standby logfile
           '/data1/oradata/STBY/stbylog01a.log' size 10M;
SQL> alter database add standby logfile
           '/data1/oradata/STBY/stbylog02a.log' size 10M;
SQL> alter database add standby logfile
           '/data1/oradata/STBY/stbylog03a.log' size 10M;
SQL> select * from v$logfile;
 GROUP#STATUS    TYPE         MEMBER
------------------------------------------------------------------------
     1           ONLINE       /data1/oradata/STBY/log01a.log
     2           ONLINE       /data1/oradata/STBY/log02a.log
     3           ONLINE       /data1/oradata/STBY/log03a.log
     4           STANDBY      /data1/oradata/STBY/stbylog01a.log
     5           STANDBY      /data1/oradata/STBY/stbylog02a.log
     6           STANDBY     /data1/oradata/STBY/stbylog03a.log 

9) primary DB에 standby redo log file 생성

<MIN DB primary DB 에서 수행>
서버문제가 발생했을 경우 takeover를 해야 하므로 primary DB도 standby DB가 될 수 있기 때문에 미리 standby redo log를 만든다.

SQL> select * from v$logfile;
GROUP#>        STATUS TYPE         MEMBER
-------------------------------------------------------------------
  1             ONLINE             /data1/oradata/MIN/log01a.log
  2             ONLINE             /data1/oradata/MIN/log02a.log
  3             ONLINE             /data1/oradata/MIN/log03a.log
SQL> alter database add standby logfile
          '/data1/oradata/MIN/stbylog01a.log' size 10M;
SQL> alter database add standby logfile
          '/data1/oradata/MIN/stbylog02a.log' size 10M;
SQL> alter database add standby logfile
          '/data1/oradata/MIN/stbylog03a.log' size 10M;
SQL> select * from v$logfile;
 GROUP#    STATUS TYPE         MEMBER
------------------------------------------------------------ -----
   1         ONLINE           /data1/oradata/MIN/log01a.log
   2         ONLINE           /data1/oradata/MIN/log02a.log
   3         ONLINE           /data1/oradata/MIN/log03a.log
   4         STANDBY          /data1/oradata/MIN/stbylog01a.log
   5         STANDBY          /data1/oradata/MIN/stbylog02a.log
   6         STANDBY          /data1/oradata/MIN/stbylog03a.log

10) standby DB를 recovery managed mode로 기동

<STBY DB standby DB 에서 수행>

standby DB를 recovery managed mode로 변경한다.
standby DB서버에서 MRP 프로세스가 생긴다.

SQL> recover managed standby database disconnect;

11) log switch 적용

<MIN DB primary DB 에서 수행>

standby DB를 구성하는 동안 primary DB와 gap이 생겼을 것이다.
current redo log를 적용시킨다.

SQL> alter system archive log current;

12) primary DB 점검

PROCESS         STATUS
------------- ---------------
ARCH            CLOSING
ARCH            CLOSING
LGWR            WRITING
SQL> select dest_id "ID",destination,status,target,
     schedule,process,mountid mid
     from v$archive_dest order by dest_id;

=> destination 2번에 우리는 service=STBY로 설정하였다. STBY는 tnsnames.ora에 나오는 접속이름이었다. STATUS=VALID 상태이고 STANDBY 이어야 한다.

=> 아무런 에러도 나와서는 안된다. 여기에서 에러가 났다면 primary DB를 먼저 기동하고 standby DB를 기동했을 경우 발생할 수도 있으나, standby로 전송이 안된 것일 수도 있으므로 다른 것도 확인을 해보아야 한다. 만약 standby DB를 먼저 기동하고 recovery managed mode에서 MRP 프로세스를 띄우고 그리고 나서야 primary DB를 기동시켰다면 아래에서는 아무런 메세지도 나와서는 안된다. 예제에서는 primary DB를 먼저 기동했으므로 메세지가 발생했을 것이다.

MESSAGE         TIMESTAMP
--------------------------
---------------------------

SQL> select dest_id id,database_mode db_mode,recovery_mode,
     protection_mode,standby_logfile_count "SRLs",
     standby_logfile_active ACTIVE, archived_seq#
     from v$archive_dest_status;

==> db_mode가 MOUNTED_STANDBY 이어야 한다. recovery_mode 가 managed가 되어 있어야 primary DB에서 전송된 redo log정보를 standby DB에 적용시킬 수 있다.

ID DB_MODE         RECOVER PROTECTION_MODE      SRLs ACTIVE ARCHIVED_SEQ#
--- --------------- ------- -------------------- ---- ------ -------------
 1 OPEN            IDLE    MAXIMUM PERFORMANCE     0      0        45
 2 MOUNTED-STANDBY MANAGED MAXIMUM AVAILABILITY    2      0        45
 3 OPEN            IDLE    MAXIMUM PERFORMANCE     0      0         0

13) standby DB 점검

14) primary DB 테이블스페이스 생성 및 데이터 입력

<MIN DB primary DB>

test 테이블스페이스를 만들고 테이블을 만들고 데이터를 넣어본다.
주의할 것은 db_file_name_convert 에서 나오는 것처럼 /data1/oradata/MIN 안에만 생성을 해야 한다. 그래야 standby DB에 데이터파일이 자동으로 생기게 된다.
또한 파라미터에서 standby_file_management=auto로 되어 있어야 standby DB에 테이블스페이스의 데이터파일이 생긴다.

SQL> create tablespace test
     datafile '/data1/oradata/MIN/test01.dbf' size 10M;
SQL> select tablespace_name, file_name, bytes/1024/1024 mega from dba_data_files;

15) standby DB예 데이터 입력 여부 확인

<STBY DB standby DB>

- primary DB에서 만든 테이블스페이스가 있는지 데이터는 들어갔는지 확인한다. recovery managed mode를 해제하고 read only로 open한다.

SQL> recover managed standby database cancel;
SQL> alter database open read only;

==> 정상적으로 primary DB에서 만든 테이블스페이스가 적용되었으며, test 라는 테이블에 데이터 insert가 정상적으로 된 것을 확인할 수 있다.

- 다시 recovery managed mode로 만들어서 primary 에서 전송된 redo log 정보가 standby DB에 적용되도록 한다. fal_server, fal_client 파라미터가 설정되어 있으므로 자동으로 gap이 생긴 부분을 맞추어 준다. DB를 open 상태에서도 recovery managed mode로 변경이 가능하다.

SQL> recover managed standby database disconnect;

16) takeover

시스템 문제가 발생하였다. takeover를 수행한다.

① <MIN DB primary DB>
가장 먼저 primary DB를 standby로 변경을 한 후 standby DB를 primary DB로 변경 해야한다.
standby DB를 primary로 먼저 변경하면 primary DB가 standby DB로될 때까지 기다리게 된다. 이제 primary DB를 standby DB로 변경한 후 기존의 primary DB를shutdown 한다.

SQL> alter database commit to switchover to physical standby with session shutdown wait;
SQL> shutdown immediate

② <STBY DB standby DB>
standby DB를 primary DB로 바꾸고 shutdown 한다.
유저접속은 없으므로 with session shutdown 절은 안 들어가도 된다.

 SQL> alter database commit to switchover to primary;
 SQL> shutdown immediate

③ 파라미터를 변경한다. # 을 붙인 것을 빼거나 추가해서 설정해준다.

<MIN DB primary DB>

vi $ORACLE_HOME/dbs/initMIN.ora
<변경전>
#####standby DB이면 열고, primary DB이면 닫는다.
#fal_server=STBY
#fal_client=MIN
#lock_name_space=STBY

##primary DB이면 열고, standby DB이면 닫는다.
log_archive_dest_2='SERVICE=STBY LGWR SYNC'
<변경후>
#####standby DB이면 열고, primary DB이면 닫는다.
fal_server=STBY
fal_client=MIN
lock_name_space=STBY
##primary DB이면 열고, standby DB이면 닫는다.
#log_archive_dest_2='SERVICE=STBY LGWR SYNC' 

<STBY DB standby DB>

 >>vi $ORACLE_HOME/dbs/initSTBY.ora <변경전> ##standby 이면
 열고, primary DB이면 닫는다. fal_server=MIN fal_client=STBY lock_name_space=STBY
 ##primary DB이면 열고, standby DB이면 닫는다.
 #log_archive_dest_2='SERVICE=MIN LGWR SYNC'
 
 <변경후>##standby 이면 열고, primary DB이면 닫는다.
 #fal_server=MIN #fal_client=STBY
 
 #lock_name_space=STBY##primary DB이면 열고, standby DB이면 닫는다.
 #log_archive_dest_2='SERVICE=MIN LGWR SYNC'

④ <MIN DB , new standby DB>

- 새롭게 standby DB가 된 MIN DB를 recovery managed mode로 변경한다.
SQL> startup nomount
SQL> alter database mount standby database;
SQL> recover managed standby database disconnect;
SQL> select process, status from v$managed_standby;
==> MRP 프로세스 기동 확인
    PROCESS          STATUS
  ---------------- ------------
    ARCH             CONNECTED
    ARCH             CONNECTED
    MRP0             WAIT_FOR_LOG
    RFS              WRITING
    RFS              ATTACHED

⑤ <STBY DB, new primary DB>

- new primary DB를 기동한다.
SQL> startup

- 확인하기
SQL> select i.instance_name, i.status instance_status, d.name dbname, d.database_role db_role,
d.switchover_status switchover_status , d.protection_mode
from v$database d, v$instance i;

=> 중요한 점검포인트 이다. TO_STANDBY 인지 확인한다.

17) 서비스 원복(takeover)

다시 원복을 시킨다. STBY DB를 standby DB로 변경한 후 MIN DB를primary DB로 변경한다.

<STBY DB, new primary DB>

- primary DB를 standby DB로 만들고 나서 standby DB를 primary DB로 만든다. 순서를 잊지 말자.
SQL> alter database commit to switchover to physical standby with session shutdown wait;
SQL> shutdown immediate

<MIN DB new standby DB>

- MIN DB를 primary DB로 변경한다.
SQL> alter database commit to switchover to primary ;
SQL> shutdown immediate

<MIN DB primary DB>

- 초기화 파라미터를 변경한다.

vi $ORACLE_HOME/dbs/initMIN.ora
<원복시킨다>#####standby DB이면 열고, primary DB이면 닫는다.
#fal_server=STBY
#fal_client=MIN
#lock_name_space=STBY
##primary DB이면 열고, standby DB이면 닫는다.
log_archive_dest_2='SERVICE=STBY LGWR SYNC'

<STBY DB standby DB>

vi $ORACLE_HOME/dbs/initSTBY.ora
  <원복시킨다>
  ##standby 이면 열고,  primary DB이면 닫는다.
  fal_server=MIN
  fal_client=STBY
  lock_name_space=STBY
  ##primary DB이면 열고, standby DB이면 닫는다.   #log_archive_dest_2='SERVICE=MIN LGWR SYNC'

18) failover

- primary DB가 있는 건물이 무너지고 디스크 이상으로 인해서 DB 데이터파일이 손상되었다. standby DB를 긴급하게 기동시켜야 한다. MIN DB를 shutdown abort로 Down시키고(디스크 fail 장애), standby DB를 primary DB로 기동시킨다.

- failover을 한 후에 시스템을 복구해서 MIN DB를 primary DB, STBY DB를 standby DB로 원래대로 구성하려면 Dataguard를 재구성 해야 한다.
즉, failover을 했다면 failover이후에 new primary DB인 STBY DB를 통해서 MIN DB를 standby DB로 구성하고 takeover 시키면 된다.

<MIN DB primary DB>

- 디스크장애상황
SQL> shutdown abort

<STBY DB standby DB>

- recovery managed mode를 해제(cancel)가 아닌 끝내도록(finish) 한다. primary DB로 변경한다.
SQL> recover managed standby database finish;
SQL> alter database commit to switchover to primary;
$ORACLE_HOME/dbs/initSTBY.ora 파일에서 primary DB로 파라미터를 설정하고 기동한다.
SQL> startup

주의> 만약 standby DB인 STBY DB를 primary DB로 failover하던 도중 ORA-16139 media recovery required 에러가 나면서 recovery 하라고 나온다면?

이럴 경우엔 아래와 같은 명령을 사용하도록 한다.
Log stream을 standby DB에 적용하지 못한 경우에 발생할 수 있다.
이러한 사항은 여러 문제로 인해서 발생할 수 있으므로 발생했다면 오라클에 공식적으로 문의 해야한다.
아래와 같이 skip하면 skip하는 만큼의 gap을 DB에 적용하지 못할 수 있으니 주의해야 한다.

SQL> alter database recover managed standby database finish skip wait;
SQL> alter database commit to switchover to primary;
$ORACLE_HOME/dbs/initSTBY.ora 파일에서 primary DB로 파라미터를설정하고 기동한다.
SQL> startup

Ref: http://blog.naver.com/gwgwg/60068173497 
제공 : DB포탈사이트 DBguide.net 

출처: http://cafe.naver.com/ocmkorea/2770
1. 오라클 10g 의 신기능 Data Pump 의 소개

1) 개요
DB에 있는 데이터를 운영체제의 파일시스템으로 내보내는 과정을 export 라 하고, 반대로 파일 시스템을 DataBase로 들여오는 것을 Import 라고 한다. 기존의 방식을 Export/Import 라고 하고오라클 10g에서는 이를 Data Pump 라고 통칭한다. 

오라클 Data Pump는 export/import에 대한 강력한 기능들을 추가한 Utility 이다.

[ Data Pump 사용시  주의사항]
export/import 와 Data Pump는 서로 호화되지 않습니다.
즉 Export 유틸리티를 이용하여 백업 받은 파일은 Data Pump를 통해 Import 할 수 없으며, 마찬가지로 Data Pump 를 통해 export 된 데이터는 Import 유틸리티를 통해 Import 할 수 없습니다.

 2) Data Pump export/Import 의 이점
■ JOB 콘트롤 기능 : Interactive mode를 통하여 Data Pump작업을 통제 할 수 있습니다. 작업을

                                중단시키고 재 시작할 수 있으며 동적으로 dump file을 할당 할 수 있습니다.

                                에러가 나더라도 작업이 중지될 뿐 언제든지 원인을 수정하고 재수행 할 수

                                있습니다.

■ 병렬수행지원 : Parallel 파라미터를 이용하여 프로세스의 Data Pump 작업의 프로세스를 병렬화

                          할 수 있습니다. 병렬화 된 프로세스는 여러개의 데이터 파일에 각각 데이터를

                          쓰거나 여러개의 데이터 파일로 부터 데이터를 읽어 데이터베이스에 저장합니다.

                          병렬수행이 가능함으로 이전 보다 훨씬 강력한 기능을 제공합니다.

■ 작업에 필요한 디스크 공간을 미리 예상 : Estimate 파라미터를 이용하여 작업 시작전에 필요한

                          물리적인 공간을 미리 예측 할 수 있다.

■ 원격지 수행 : DB Link 를 통하여 원격지 데이터에 대한 Data Pump export/import 를 수행 할 수

                      있다

■ Remapping 지원 : 유저 스키마, 테이블스페이스, 데이터파일 등과 같은 정보들이 Data Pump

                                export/import 시에 변경 할 수 있습니다. 이러한 기능은 데이터 마이그레이션

                                시에 보다 많은 유연성을 제공하는데 큰 역활을 합니다

3) Data Access 방법

■ Direct-path : Direct I/O를 사용하여 OS영역의 메모리를 사용하지 않고 데이터 파일에 direct로

                        쓰게 되는 방법입니다. 메모리 사용이 적고 속도가 빠르며, 데이터 컨버전에 시간이

                        걸리지 않습니다.

[ Direct-path 가 되지 않는 경우 ]

- 클러스터 테이블인 경우

- 테이블에 활성화된 트리거가 존재할 경우

- 글로벌 인덱스를 가진 테이블이 하나의 파티션에 존재 할 경우

- LOB컬럼에 있는 도메인 인덱스

- insert 모드에서 fine_grained access control 이 enable인 경우

- BFILE을 가진 테이블인 경우

■ External Tables : 메타 데이터를 데이터베이스 내에 저장하고 데이터는 파일시스템 존재하게

                       만들어 데이터를 저장하는 방법이며 대용량 데이터를 export/import 할때

                       사용합니다.

[ External Table이란? ]

- Create TABLE ~~ ORGANIZATION EXTERNAL 문을 통해 만들어진 테이블

- 실질적인 데이터베이스 내에 존재하는 것이 아니라 물리적 디스크 공간에 논리적 공간을 할당 받아 데이터를 저장하며, 파일 형태로 존재합니다.

- 저장되는 데이터는 READ ONLY 데이터이며 인덱스를 생성할 수 없습니다.

- DML 작업을 수행 할 수 없습니다.

- META-DATA in DATABASE, DATA in OS라고 압축 설명 할 수있습니다.

3) Data Pump 의 권한설정

- 시스템에 설정된 EXP_FULL_DATABASE, IMP_FULL_DATABASE 롤을 부여함으로써 가능함

   (1) 사용자 생성 : create 문을 사용하여 사용자를 생성합니다. 패스워드는 imsi00 으로 하며,

        default tablespace는 USERS 테이블스페이스로 합니다.

        create user zoom identified by imsi00

        default tablespace users

        temporary tablespace temp

        /

   (2) 권한부여 : grant 문을 이용하여 zoom 유저에 접속(connect) 과 자원사용(resource) 에

        대한 권한을 부여한다

        grant connect, resource to zoom;

   (3) 모든 테이블에 대한 select 권한부여

        grant select any table to zoom;

   (4) zoom유저에 EXP_FULL_DATABASE, IMP_FULL_DATABASE 권한 부여

        grant EXP_FULL_DATABASE, IMP_FULL_DATABASE to zoom;

4) Data Pump 파일 오브젝트

4-1) Data Pump 가 사용하는 파일의 종류

■ Dump File : 테이블로 부터 데이터 또는 메터 데이터를 로드하여 저장된 파일

■ Log File : Data Pump 작업 중에 발생하는 메시지나 결과를 기록하는 파일

■ SQL File : Data Pump는 SQLFILE 이라는 옵션을 사용합니다. 이옵션을 사용 할 경우

                  Data Pump Import 작업이 수행되는 동안 DDL문을 수행 할 수있게 해줍니다

4-2) Data Pump 디렉토리 오브젝트

Data Pump는 사용자별 디렉토리 접근 권한을 설정할 수 있다

디렉토리 권한설정

(1) 사용중인 디렉토리 오브젝토 조회

      SQL> select * from dba_directories;

(2) 디렉토리 오브젝트 추가

      SQL> create directory datapump_dir1 as '/temporary/ora_tmp';

(3) 디렉토리 오브젝트 권한추가(zoom 유저에게 datapump_dir1 디렉토리 read, write 권한부여)

      SQL> grant read, write on directory datapump_dir1 to zoom;

(4) Export Pump 실행

     $expdp zoom/imsi00 directory=datapump_dir1 Tables=EMP dumpfile=zoom_dump01.dmp

* Data Dump 시 마다 디렉토리 오브젝트를 추가하지 않고 묵시적으로 추가

$DATA_DUMP_DIR=datapump_dir1;

$export DATA_DUMP_DIR;

2. Data Pump Export

1) Data Pump Export 사용하기

■ Command-line 이용하기

   $expdp zoom/imsi00 directory=datapump_dir1 Tables=EMP dumpfile=zoom_dump01.dmp

    - 비교적 작은 수의 옵션들이 사용되거나 간단한 구문일 때 사용합니다

    - 복잡하고 옵션이 많게 되면 수정하거나 잘못 타이핑 할때 시간이 많이 걸리게 됩니다

■ 파라미터 파일 이용하기

    zoom.par 파일을 생성하여 다음과 같이 설정합니다

    SCHEMAS = SCOTT

    DIRECTORY=datapump_dir

    DUMPFILE=zoom01.dmp

    LOGFILE=zoom_dump.log

    $expdp zoom/imsi00 PARFILE=zoom.par

2) Data Pump Export 모드

■ Full Export 모드 : Full 파라미터를 사용합니다. 데이터베이스 전체를 export 받을 수 있습니다.

                            한가지 주의 할 점은 EXPORT_FULL_DATABASE 롤이 Full Export 받고자 하는

                            사용자에게 부여되어 있어야 한다는 점입니다

■ 스키마 모드 : Schemas 파라미터를 사용합니다.

                           하나의 유저가 소유하고 있는 데이터 및 오브젝트 전체를 export 받고자 할때

                          사용할 수있는 모드입니다.

■ 테이블스페이스 모드 : TableSpace 파라메터를 사용합니다. 하나 이상의 테이블스페이스에

                           대해 해당 테이블스페이스에 속한 모든 테이블을 받을 수 있습니다.

                           만약 TRANSPORT_TABLESPACES 파라미터를 이용한다면, 테이블 뿐 아니라

                           테이블스페이스의 메터데이터 까지 export 받게 되어 다른 서버에 dump 파일을

                           카피 한 후 import 하게 되면 테이블스페이스 및 테이블이 자동으로 생성됩니다.

■ 테이블 모드 : TABLES 파라미터를 사용합니다.

                       하나 이상의 테이블을 export 받을 때 사용합니다
 

3) Data Pump Export 파라미터

■ 파일 및 디렉토리 관련 파라미터

- DIRECTORY : 디렉토리 오브젝트를 참조하는 DIRECTORY 파라미터를 이용하여 덤프파일의

                      위치 및 로그파일의 위치를 지정 할 수 있습니다.

                      DIRECTORY=directory_object_name 형식으로 사용 할 수있습니다.

- DUMPFILE : Export를 받아 파일시스템에 저장될 덤프파일의 이름을 지정하는 파라미터이빈다.

                    파라메터를 사용할때 다음을 기억하시고 사용하시면 됩니다.

                    + %U 를 사용하여  여러개의 덤프 파일을 구분 할 수 있습니다

                       DUMPFILE=ZOOM_DUMO_%U.DMP라고 파라메터를 정의합니다.  만약 덤프

                       파일이 10개가 생성된다고 가정하면 ZOOM_DUMO_01.dmp 부터

                       ZOOM_DUMO_10.dmp 까지 %U 부분이 자동 증가하여 파일을 구분하여 줍니다.

                       %U의 범위는 01 ~ 99 까지 입니다

                   + ',' 를 이용하여 여러개의 파일명을 구분할 수 있습니다.

                      예를들어 다음과 같이

                      DUMPFILE=ZOOM_DUMO_01.dmp, ZOOM_DUMO_02.dmp,ZOOM_DUMO_03.dmp

                   + 만약 DUMPFILE 파라메터를 지정하지 않는다면 expdat.dmp 라는 파일명으로

                      오라클이 자동 선언하게 됩니다.                 

- FILESIZE  : export 받는 1개 파일의 최대크기를 지정하는 파라미터 입니다.

                   만약 export 받을 총 데이터량이 10GB이고 FILESIZE를 1GB로 지정하였다면 1GB

                   크기의 dump file이 10개 만들어 지게 됩니다.

                   FILESIZE=N [ BYTES | KILOBYTES | MEGABYTES | GIGABYTES ] 입니다.

- PARFILE : 파일에 파라메터들을 저장해 두고 Data Pump를 이용할때 마다 참조하여 작업을

                 수행하고 싶을때 PARFILE 파라메터를 사용할 수 있습니다

                  PARFILE=filename.par 형식으로 사용할 수 있으며, 파일 확장자는 아무런 영향을

                  미치지 않습니다

- LOGFILE & NOLOGFILE : 로그 파일명을 지정하는 파라메터 입니다

                  LOGFILE=logfile_name 형식으로 사용 하시면 됩니다. 파라미터를 설정하지 않는다면

                  export.log 라는 파일명으로 로그가 자동으로 실행한 위치의 디렉토리에 남게 됩니다.

                  로그파일을 남기고 싶지 않을때는 NOLOGFILE 파라미터를 사용하시면 됩니다.

- COMPRESSION : 오라클에서 EXPORT 시에 메타데이터는 압축을 하여 파일에 저장하게 됩니다.

                  COMPRESSION 파라메터를 사용하지 않을 경우에는 덤프파일 내에 메타데이터가

                  압축되어 보관됩니다.

                  COMPRESSION 파라메터에는 METADATA_ONLY, NONE 두개의 옵션이 있으며,

                  METADATA_ONLY는 파라메터를 사용하지 않으면 디폴트로 인식되는 옵션입니다.

                  COMPRESSION=option_name 으로 사용하면 됩니다.

                  #expdp zoom/imsi00 DIRECTORY=/oracle/expdir DUMPFILE=dump.dmp

                                                COMPRESSION=NONE

■ Export 모드 관련 파라미터

- FULL

- SCHEMAS

- TABLES

- TABLESPACES

- TRANSPORT_FULL_CHECK : TRANSPORT_FULL_CHECK 파라메터는 export 작업 시에

                          테이블스페이스 내에 존재하는 테이블과 인덱스의 의존선을 검사 할 것인지

                          하지 않을 것인지를 설정하는 파라미터로 'Y' 또는 'N' 두개이 값만을 허용하는

                          파라메터 입니다.

(1) 'Y' 일 경우, TABLESPACE 내에 테이블만 있고, 인덱스가 없다면 작업은 실패한다.

      반드시 INDEX도 같은 테이블스페이스내에 존재 해야 합니다.

(2) 'Y' 일 경우, TABLESPACE내에 인덱스만 존재하고 테이블이 없다면 작업은 실패합니다.

       반드시 TABLE 또한 존재해야 합니다

(3) 'N' 일 경우, TABLESPACE내에 테이블만 있고 인덱스가 없다면 작업은 성공합니다.

(4) 'N' 일 경우, TABLESPACE내에 인덱스만 있고 테이블이 없다면 작업은 성공합니다.

■ Export 필터링 관련 파라미터

- CONTENT : 3개의 옵션을 가질 수 있으며 옵션들은 다음과 같습니다 

   + ALL : 테이블과 메터데이터를 포함한 모든것을 포함시키겠다는 옵션

      # expdp zoom/imsi00 DUMPFILE=datadump.dmp CONTENT=ALL

   + DATA_ONLY : 테이블 데이터만 포함 시키겠다는 옵션

     #  expdp zoom/imsi00 DUMPFILE=datadump.dmp CONTENT=DATA_ONLY

   + METADATA_ONLY : 메타데이터 만을 포함하겠다는 옵션

     #  expdp zoom/imsi00 DUMPFILE=datadump.dmp CONTENT=METADATA_ONLY

- EXCLUDE & INCLUDE : 원하는 오브젝트를 선택하여 받을 수 있습니다.

                                     오라클에서 오브젝트란 유저스키마, 테이블, 인덱스, 프로시져 등을

                                     통칭해서 오브젝트라고 부릅니다.

                                     [exclude | include]=object_name 조건 형식으로 사용 할 수 있음

                                     파라미터 사용방법은 아래와 같습니다.

        + SCOTT 유저와 관련된 모든것을 export 받고 싶은데, BONUS 테이블은 제외하고 받고

          싶은 경우

          #expdp zoom/imsi00 dumfile=ex_dump.dmp schemas=scott exclude=TABLE:"='BONUS'"

        + SCOTT 유저와 관련된 모든것을 export 받고 싶은데 EMP 테이블의 인덱스는 받고

          싶지 않은경우

         #expdp zoom/imsi00 dumfile=ex_dump.dmp schemas=scott exclude=INDEX:\"='EMP%'\"

- QUERY : 테이블 내에 있는 데이터 중 특정 조건에 만족하는 데이터만을 export 받고자 할때

                사용하는 파라메터 입니다.

                사용방법은 다음과 같습니다

                QUERY=SCHEMA.TABLE:"조건" 이며 다음과  같은 예입니다.

                # expdp zoom/imsi00 dumpfile=ex_dump.dmp table=emp

                                               QUERY=SCOTT.EMP:'where sal > 1200'

- SAMPLE : 오라클 10g에서 새롭게 지원하는 기능 중 하나로써 테이블의 데이터를 export 할때

                  퍼센트를 정하여 지정된 퍼센트 만큼의 데이터를 샘플링해서 뽑을때 사용하는

                  옵션입니다

               # expdp zoom/imsi00 DIRECTORY=datadump_dir1 DUMPFILE=ex_dump.dmp

                                              SAMPLE=scott.emp:20

                  //scott 유저의 EMP테이블의 데이터중 20%만을 export 하게 됩니다

                     입력 가능한 퍼센트의 범위는 0.000001 ~ 100 까지 입니다.

■ 네트워크 링크 파라미터

- 원격지 데이터베이스에 있는 데이터에 접근하여 로컬 데이터베이스 머신에 export 된 덤프파일을

   저장하고자 할때 사용하는 파라메터

- 먼저, 원격지 데이터베이스의 테이블에 대한 DB_LINK 를 만들어 놓아야 함

  # expdp zoom/imsi00 DIRECTORY=datadump_dir1 DUMPFILE=ex_dump.dmp

                                 NETWORK_LINK=EMP@link_b_scott LOGFILE=datapump.log

■ 암호화 관련 파라미터

- export 되는 데이터 중 일부 컬럼이 암호화 되어 있고, 중요한 데이터 일 경우 사용하는 파라미터

- export 시에 암호를 설정하여 export된 데이터가 위변조 되지 못하게 설정할 수 있음

  # expdp zoom/imsi00 TABLES=EMP DUMPFILE=ex_dump.dmp

                                 ENCRYPTION_PASSWORD=******

■ JOB관련 파라미터

- JOB : JOB파라미터를 설정하면 Data Dump 작업을 오라클에서 자동 할당하지 않고

           JOB파라메터에서 주어진 이름으로 등록 되게 됩니다. 작업 마스터 테이블에 작업명이

           등록되어 작업에 대한 정보들을 JOB 파라미터에 등록된 이름으로 조회 할 수있습니다.

- STATUS : STATUS파라미터는 Data Pump Export 시에 작업의 갱신 된 내용을 STATUS에

                 설정된 크기의 시간 간격으로 진행상태를 보고 받고자 할때 사용하는 파라메터 입니다.

                 STATUS = 30 이면 30초 간격으로 작업결과를 갱신하여 보여주게 됩니다.

                 만약 이 파라미터를 설정하지 않으면 디폴트는 0입니다. 디폴트로 설정하게 되면

                 거의 실시간으로 작업정보를 보여주게 됩니다.

- FLASHBACK_SCN : System Change Number(SCN) 은 시스템의 테이블이나 오브젝트가

                변경되었을때 변경되는 SCN값을 가집니다. FLASHBACK_SCN 파라메터를 이용하여

                SCN 값을 지정할 경우에 파라미터에서 설정한 SCN 기준 이전까지의상태를 받게 됩니다

                # expdp zoom/imsi00 DIRECTORY=datadump_dir DUMPFILE=ex_dump.dmp

                                               FLASHBACK_SCN=120001

- FLASHBACK_TIME : FLASHBACK_TIME은 번호 대신 시간값을 가집니다.

                FLASHBACK_TIME 파라미터를 사용하면 파라미터에 지정된 시간까지의 변경

                사항만을 Export 합니다.FLASHBACK_TIME 의 값은 TIMESTAMP 형식의 값을 가지며

                TO_TIMESTAMP 함수를 사용하여 설정 할 수 있습니다.

- PARALLEL : PARALLEL 파라메터를 사용할 경우 export 작업 시에 프로세스를 설정된

                숫자만큼 만들어 수행함으로써 작업의 속도를 향상 시킬 수 있습니다. 디폴트 값은 1로

                설정되어 있으며 주의할점은 parallel 이 지정된 갯수 만틈의 dumpfile 을 지정해 주어야

                한다. 앞서 본 %U를 사용하면 지정된 갯수만큼 자동으로 파일을 만들어 줍니다

                # expdp zoom/imsi00 DIRECTORY=datadump_dir DUMPFILE=ex_dump%U.dmp

                                               PARALLEL=3

                위와 같이 설정하게되면 ex_dump01.dmp, ex_dump02.dmp, ex_dump03.dmp 3개의

                덤프파일이 생성됩니다.

                # expdp zoom/imsi00 DIRECTORY=datadump_dir

                  DUMPFILE=(ex_dump01.dmp, ex_dump02.dmp, ex_dump03.dmp) PARALLEL=3

                 위와 같이 %U를 사용하지 않고, 사용자가 직접 3개의 파일명을 ',' 구분하여 입력해도

                 상관 없습니다.

- ATTACH : ATTACH 파라미터를 이용하여 interactive mode 로 들어 갈 수 있습니다.

                 오라클에서는 작업을 제어하고 모니터링 하기 위해 interactive mode를 제공합니다.

                 interactive mode로 들어가는 방법은 두가지가 있으며 다음과 같습니다.

                 + Crtl + C 를 누름으로써 들어가는 방법

                   # expdp zoom/imsi00 directory=datadump_dir  table=scott.emp

                                                 dumpfile=datadump.dmp logfile=datapump.log

                                                 jobname=myjob            

                                                작업로그.....

                                                .................==> 작업에 대한 로그가 떨어졌을때 Crtl + C

                   export>                  ==> 이와 같이 프롬프트 상태로 떨어지게 됩니다.

                   로그가 멈춘다고 해서 작업이 중단된게 아니라 이상태에서 interactive mode 명령을

                   사용하여 작업을 모니터링 하고 제어 할 수 있습니다

                   # expdp zoom/imsi00 attach=schema.jobname 형식으로 원하는 작업의

                   interactive mode로 들어갈 수 있습니다.

 < InterActive Mode 명령어 >        

 
3. Data Pump Import

■ 파일 및 디렉토리 관련 파라미터

    #impdp zoom/imsi00 directory=datapump_dir dumpfile=datapump.dmp schemas=scott

     - directory : 디렉토리 오브젝트를 받는 파라미터

     - dumpfile : imprt 될 파일명

     - schemas : 작업 수행동안 수행될 DDL문을 저장하는 파일이름

■ 필터링 관련 파라미터

- CONTENT : CONTENT 파라미터는 DATA_ONLY, METADATA_ONLY, ALL 3개의 값을 가짐

   #impdp zoom/imsi00 directory=datapump_dir dumpfile=datapump.dmp schemas=scott

                                CONTENT=DATA_ONLY

- INCLUDE : INCLUDE=OBJECT_NAME:"='조건'" 형식으로 사용할 수 있으며 오브젝트의

                  종류에는 앞서 본것처럼 TABLE, INDEX, PROCEDURE, FUNCTION 등이 있습니다.

   #impdp zoom/imsi00 directory=datapump_dir dumpfile=datapump.dmp schemas=scott

                                INCLUDE=TABLE:"='SAL'"

     ==>SCOTT 유저의 테이블을 import 하되 SAL테이블 만 포함 시키라는 옵션명령이 됩니다.

- EXCLUDE : EXCLUDE=OBJECT_NAME:"='조건'" 형식으로 사용할 수 있으며 오브젝트의

                  종류에는 앞서 본것처럼 TABLE, INDEX, PROCEDURE, FUNCTION 등이 있습니다.

   #impdp zoom/imsi00 directory=datapump_dir dumpfile=datapump.dmp schemas=scott

                                 EXCLUDE=TABLE:"='SAL'"

     ==> SCOTT 유저의 테이블을 import 하되 SAL테이블을 제외한 나머지 테이블을 import 하라는

           명령

- TABLE_EXISTS_ACTION : imprt 시에 중요한 명령입니다

                                       우리가 Data Pump를 통해 작업하게 될 경우 같은 이름의 테이블이

                                       존재할 때가 있습니다. 만약 테이블이 존재 하더라도 import 하고자 하는

                                       데이터의 row수가 다를수도 있고 같을 수도있습니다. 즉 테이블은 존재

                                       하더라고 데이터의 내용은 차이가 나는거죠.

                                       이러한 경우 사용할 수 있는 유용한 파라메터가

                                       TABLE_EXISTES_ACTION 입니다. TABLE_EXISTES_ACTION파라메터

                                       는 SKIP, APPEND, TRUNCATE, REPLACE 의 값을 가질 수 있으며

                                       각값의 의미는 다음과 같습니다.

                                       + SKIP : 같은 테이블을 만나면 지나치고, 다음 테이블을 import 합니다

                                       + APPEND : 같은 테이블을 만나면 기존테이블에 추가하여 import

                                       + TRUNCATE : 같은 테이블을 만나면 기존테이블을 truncate하고

                                                             새로운 데이터를 import

                                       + REPLACE : 같은 테이블을 만날 경우 기존 테이블을 drop 하고

                                                           테이블을 재생성 한 후 import 합니다

   #impdp zoom/imsi00 directory=datapump_dir dumpfile=datapump.dmp schemas=scott

                                 TABLE_EXISTS_ACTION=SKIP

■ JOB 관련 파라미터

- JOB_NAME, STATUS, PARALLEL 파라메터를 export와 같은 방법으로 사용

- PARALLEL 작업시에 dumpfile 갯수를 %U 사용하여 지정하여 주거나 명시적으로 ','를 사용하여

   PARALLEL 갯수만큼 파일을 지정해야 함

■ 리맵핑 관련 파라미터

- REMAP_SCHEMA : A 유저 스키마로 export 받은 데이터를 B 유저 스키마로 import 하고자 할때

                              사용합니다.

   #impdp zoom/imsi00 directory=datapump_dir dumpfile=datapump.dmp schemas=scott

                                REMAP_SCHEMA=SCOTT:ZOOM

    ==> 위와 같이 수행한후 TABLE 의 OWNER 를 조회한다면 ZOOM 유저의 소유로 테이블이

          등록되었음을 확인 할 수 있다.

- REMAP_DATAFILE : 전체 데이터베이스 시스템을 Data Pump를 통하여 옮기고자 할때

                               Export 된 dumpfile에는 DataFile 정보까지 포함하게 됩니다. 하지만 서로다른

                              시스템 경로상에 존재하지 않는 경로이기 때문에 Import 에 실패하게 됩니다.

                              이러한 경우 사용할 수 있는 파라미터가 REMAP_DATAFILE 입니다. export 된

                              dumpfile이 datafile 정보를 포함할 경우에만 해당합니다.

   #impdp zoom/imsi00 directory=datapump_dir dumpfile=datapump.dmp schemas=scott

                              REMAP_DATAFILE='/db1/data/lvol01':'/db2/data/lvol01',

                                                          '/db1/data/lvol02':'/db2/data/lvol02'

- REMAP_TABLESPACE : export 받은 데이터 속한 tablespace 에서 다른 tablespace로

                                     remapping하고자 하는 경우 사용할 수 있는 파라메터 입니다.

   #impdp zoom/imsi00 directory=datapump_dir dumpfile=datapump.dmp schemas=scott

                              REMAP_TABLESPACE='SCOTT_TSB':'ZOOM_TSB'

■ 네트워크 링크 파라미터

export 와 마찬가지로 DBLINK를 이용하여 원격지 데이터베이스에 대해 import 작업을 수행 할 수있습니다.

■ InterActive Mode 파라미터

export 와 마찬가지로 Ctrl+C를 통해 interActive Mode로 진입 할 수 있으며 작업을 통제 할 수있습니다

4. Data Pump 모니터링 하기

1) Data Pump 모니터링 하기 관련조회 테이블 및 VIEW

■ DBA_DATAPUMP_JOBS 현재 실행중인 작업의 속성들

   SQL> SELECT * FROM DBA_DATAPUMP_JODS;

            OWNER_NAME = DB작업계정

            JOB_NAME = 작업의 명칭

            JOB_MODE = FULL, TABLE, INDEX, TABLESPACE 등이 있음

            STATE = EXECUTING(수행중), DEFINING, UNDEFINING, NOT RUNNING 의 값을 가짐

■ PUMP Session 확인

■ Data Pump의 모니터링

    SQL> SELECT OPNAME, TARGET_DESC, SOFAR, TOTALWORK,

             (SOFAR/TOTALWORK*100) PER

              FROM V$SESSION_LONGOPS; 로 조회하면 Data Pump 의 모니터링을 할 수 있습니다

              OPNAME = JOBNAME 과 같음

              TOTALWORK = 총 수행하여야 할 용량을 가리키며, 단위는 Megabytes

              SOFAR = 현재 수행한 용량을 가리키며 단위는 Megabytes

              TARGET_DESC = 작업의 종류를 말함

                                       import/export  값이 될 수 있음

-- datapump 참고자료
1. http://m.dbguide.net/dbguide.db?cmd=view&boardUid=12923&boardConfigUid=9&categoryUid=216&boardIdx=51&boardStep=1
2. https://docs.google.com/viewer?a=v&q=cache:qLfaukYDzcMJ:web-dev.tistory.com/attachment/cfile8.uf%40155242114C2AA8FE5626EC.pdf+&hl=ko&gl=kr&pid=bl&srcid=ADGEEShbbQYI9MWHfAHy6q90tPOPXJcr3bl4vwqrRci4R_XMh5FlTp45Z4a6mg5_iUOBZ4rYltYtF5ahzyiXIWZWpYqYXmipuklojZ6KPvh5lTIVLNpvfluJuNHO1XPpXVn1KX1hwVdi&sig=AHIEtbRWXbdEEm_amWyg8T1tDw2o3srgGw
3. http://www.dbguide.net/knowledge.db?cmd=view&boardUid=128192&boardConfigUid=20

-- datapump 실습
1. http://thankyeon.tistory.com/19