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

1.  driving table 선정이 가장 중요함

ð  optimizer 가 가장 먼저 읽는 table 을 driving 이라함

ð  driving table 이 되기 위해서 driving table 의 key column 에 상수를 주어야함

ð  상수가 아닌 변수나, ||, not , substring , rtrim 등 변형을 가하면 driving 조건에서 배제됨

ð  driving table 에서 가능한 범위를 줄여주어야함

(예   실적->조직구조-> 조직  =>  조직구조->조직->실적 )

ð  driving table 의 조건이 동일하다면 ordered hint 지정

2.  join 의 횟수를 줄여야 함

ð  Detail 이 driving 되었을때 master 를 detail 건수 만큼 join 할 필요는 없음

ð  예) detail 이나, master table 로 조직을 join 하는 경우=> 한번만 join   

ð  예) 상위조직으로 조직별 제품별 실적을 조회하는데 매번 제품을 join 할 필요 없슴

ð  Inline view 이용

3.  outer join 은 꼭 필요한 경우가 아니면 쓰지 말며 가능한 inline view 로 처리

4.  nvl 함수 남발은 결국 performance 저하

ð  table layout 상에 Notnull 로 지정된 경우는 nvl 함수 사용금지

ð  수량,금액 fields 는 DB team 에서 default 0 로 변경할 예정임

5.  index column 에 변형을 가하면 index scan 하지 못함

6.  sort,group by,order by 는 부분범위처리를 하지 못하며 performance 를 저하시키니, 꼭 필요한 need 외에는 쓰지 않는 것이 유리함

7.  검증된 hint 외의 hint 사용은 DBA팀 CONFIRM 후에 사용할것

ð  INDEX DESC 는 예외

8.  MAX 함수는 INDEX DESC 로 대체

9.  PLAN 출력후 operation 이 sort merge나 hash join 이면 nested loop 로 hint 줘야 함

10. 실적을 조회하는 경우 data 를 최소로 read 할 수 있는 table 선정이 중요

ð  하위조직별로 실적 sum 을 요구하는 UI 에서 조직별,제품별을 GROUP BY 하는 것보다는 원장 TABLE 을 SUM 하는것이 빠름

11.UI 구조상 여러 조건에 따라 SQL 문이 달라지는경우 SQL 을 분리하거나, Dynamic sql 을 사용할것

12.     UI 를 보고 어떤 TABLE을 DRIVING 으로 쓸것인지 어떤 INDEX 를 쓸것인지 결정한후 설계->프로그램 작성하는 것이 좋

13.     동일 table 을 두번 select 하지 말아야 함

ð  예 UI 에서 월,분기,누계실적을 요구하는 경우 월로 Select, 분기 select,누계 select 를 따로 하는 것보다 누계로 한번만 select 후 분기,월을 계산하면 빨라질 수 있슴

14.     PLAN 출력후 PK 로 INDEX SCAN 된다면 ORDER BY 쓰지 말것

(이렇게하면 전체범위 처리를 함)

===========================================================================================================================================
-- 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