꿈꾸는 개발자, DBA 커뮤니티 구루비

1. 개요

Data Guard 11g의 주요 내용은 다음과 같다.

데이터 보호에 전혀 손상을 일으키지 않고 테스트나 다른 목적으로 공개 쓰기 읽기가 가능한 물리적 스탠바이 데이터베이스 - Snapshot Standby
Async 전송 강화로 네트워크 작업량 증가로 인한 영향 제거
Automatic failover for Maximum Performance
지정 이벤트나 오류에 대한 즉각적인 반응을 위한 자동 failover 구성
스토리지 층의 쓰기 손실로 인한 손상을 신속하게 감지
구성의 유연성 증가(Windows 기본, Linux Standby 등)
XML 데이터 유형을 지원하는 SQL 적용(CLOB)
다양한 성능, 관리, 보안 강화
새로운 Oracle Database 11g 옵션
- Oracle Active Data Guard
- Oracle Advanced Compression

1.1 Data Guard Redo Transport Services

Data Guard 구성은 Primary Database라고 하는 데이터베이스에 최대 9개의 Standby Database까지 구성할 수 있다. 이때 redo data를 사용하여 동기화를 유지한다.

1.2 Data Guard Apply Services

Data Guard는 2가지 방법으로 동기화를 한다.

Redo Apply
SQL Apply

[Redo Apply]

Pysical Data Guard를 구성할 때 사용하는 방법으로 블록 기반으로 Primary Database와 동일한 on-Disk 데이터베이스 구조를 갖추고 있으며, 오라클 미디어 복구를 사용해 업데이트 된다.

[SQL Apply]

Logical Data Guard를 구성할 때 사용하는 방법으로 SQL Statement를 사용해 업데이트된다.

1.3 Data Guard Role Management Services

예상 또는 예상하지 않은 작동 중지로 인해 Primary DB가 사용없게 되는 경우 Data Guard Role Management Services가 신속하게 선택된 Standby DB를 사용할 수 있게 전환하기 때문에 다운타임을 최소화하고 데이터 손실을 방지할 수 있다.

1.4 기타 서비스 기능

11g에서는 다음과 같은 기능들을 제공해 준다.

DG Broker Configuration
Active Data Guard
RMAN Online Backup을 지원
Snapshot Standby
Logical Standby Database
Transient Logical Standby 롤링업그레이드 지원

1.4.1 DG Broker Configuration

DG Broker 기능이 추가되었다.

[Data Guard 구성 생성 및 관리]

다음과 같은 기능이 추가되었다.

Primary DB와 Standby DB의 다양한 내부 작업을 SQL Plus를 사용해 관리할 수 있다.
Data Guard는 Data Guard Broker라고 불리는 분산 관리 프레임워크를 제공하여 Data Guard 구성의 생성, 유지, 모니터링을 자동화하고 중앙화한다.
관리자들은 Enterprise Manager Grid Control이나 Broker의 명령어 라인 인터페이스를 사용해 Broker와 내부 작업을 할 수 있다. (DGMGRL)

1.4.2 Active Data Guard

11g 부터는 Physical standby DB를 다양하게 활용 할 수 있다. 심지어 redo 가 physical standby DB에 적용되는 동안에도 query를 실행할 수 있다. 즉, Primary DB를 사용하면서 Physical Standby DB에서 읽기 전용 접속 모드와 같이 실행할 수 있다.

1.4.3 RMAN Online Backup 지원

모든 Data Guard Standby DB는 RMAN을 사용해 온라인 백업을 지원한다.

1.4.4 Snapshot Standby

Physical Standby DB (Redo Apply)를 Snapshot Standby로 전환하여 실 서비스 데이터의 정확한 읽기-쓰기를 통해 핫 패치와 다른 테스트가 가능하다. 다음과 같은 기능이 제공된다.

읽기-쓰기 모두 지원
테스트와 다른 용도를 위해 Primary Database와 독립적인 트랜잭션을 처리할 수 있다.
특징은 다음과 같다.
Physical Standby Database가 Snapshot Standby Database 로 변환된 것에 의해 생성된 모든 업데이트가 가능하다.
primary database 에서 redo data 를 받고 archive 하지만 apply 는 하지않는다.
snapshot standby database 는 EM 에서 나 Data Guard Broker command line 인 DGMGRL 그리고 SQL*Plus를 통해서 생성 할 수 있다.
운영 프로세스는 다음과 같다.

Primary Database 로부터 계속해서 업데이트를 받고 아카이빙을 수행하지만 Primary Database 에서 받는 redo 데이터는 스냅샷 스탠바이가 다시 Physical Standby Database로 전환되고 SnapShot Standby Mode 중에 이루어졌던 모든 업데이트가 버려질 때까지 적용되지 않는다.
Snapshot Standby database 에서 발생된 모든 local update 를 버린 이후에 일단 Snapshot Standby database는 Physical Standby Database 로 전환된 후 Primary Database 에서 받은 redo data 가 적용됩니다.

1.4.5 Logical Standby Database

Logical Standby (SQL Apply) DB는 공개 읽기-쓰기라는 새로운 유연성을 제공한다. SQL Apply에 의해 유지되는 데이터를 변경할 수 없으면서 추가 로컬 테이블이 데이터베이스에 더해지고, 로컬 인덱스 구조를 생성해 리포팅을 최적화하거나 Standby DB를 데이터 웨어하우스로 활용하거나 데이터 마트를 로딩하는데 사용하는 정보를 처리할 수 있다.

1.4.6 Transient Logical Standby 롤링업그레이드 지원

Logical Standby DB를 롤링 데이터베이스 업그레이드를 수행하는데 사용해, 새로운 데이터베이스 패치 세트나 전체 데이터베이스 출시로 인한 업그레이드를 수행할 때 다운타임을 최소화할 수 있다. 뿐만 아니라 Physical Standby DB를 Logical Standby DB로 전환해, 롤링 데이터베이스 업그레이드를 실행한 후 다시 정상적인 Physical Standby DB 운영 상태로 복귀할 수 있습니다.

2. Data Guard 11g의 New Feature

11g New Feature는 다음과 같다.

Physical Standby를 사용해 모든 작업 프로파일에 있어서 Physical Standby 적용 성능을 크게 강화한다.
Logical Standby를 사용하면, 구획이 구분이 되지 않고 LOB, LONG, XML유형의 컬럼을 포함하지 않는 테이블의 insert, update 적용 성능을 증대할 수 있다.
Async Redo 전송 강화로 네트워크 지연이 제거되면서 네트워크 작업량이 증대하고, WAN 구축시 효과가 좋다.
Fast Start Fail Over 사용 시 Fail Over 시간이 추가로 감소한다.

2.1 11g의 새로운 기능

새롭게 제공되는 기능으로 다음과 같은 성능 강화를 제공한다.

2.1.1 Snapshot Standby

Physical Standby DB로부터 생성되는 새로운 유형의 Standby DB이다.

Read-Write 지원
독립적인 트랜잭션 처리 가능
프로세스는 다음과 같다.
#. Primary DB로부터 계속해서 update받고 archiving 수행
#. Snapshot Standby 시 하려고 했던 트랜잭션 수행, 이때 Primary DB로부터 받은 내용은 적용하지 않는다.
#. Physical Standby DB로 전환한다. 이때, 2번에서 했던 작업을 모두 버린다.
#. Snapshot Standby시 archiving되었던 것을 모두 다시 적용한다.

2.1.2 SYNC 와 ASYNC redo 전송의 Auto FailOver

Data Guard 11g 은 Fast Start FailOver 를 확장해 Auto Fail-Over로 인해 원하는 RPO (Recovery Point Objective)를 초과하는 데이터 손실로 이어지지 않도록 하는 사용자 구성 데이터 손실 한계를 추가하는 방식으로 최대 성능 모드 (ASYNC)를 지원한다.
사용자는 FailOver가 Fast Start FailOver 한계 시간이 지정하여, 점검 상태나 원하는 ORA 오류에 기초해 기다릴 필요 없이 즉시 발생하도록 Auto FailOver를 구성할 수 있다. 새로운 DBMS_DG PL/SQL Package를 사용해 애플리케이션이 패스트 스타트 페일오버 옵저버 프로세스를 통보해 Auto FailOver를 시작할 수 있다.

2.1.3 Transient Logical Standby 롤링업그레이드 지원

사용자들은 Physical Standby를 일시 Logical Standby DB로 전환해 롤링 데이터베이스 업그레이드에 영향을 미치고, 업그레이드가 완료된 후에 Physical Standby로 다시 전환할 수 있다. (KEEP IDENTITY절 사용). 따라서 Logical Standby DB를 생성하는데 필요한 중복 스토리지 투자를 하지 않고 롤링 데이터베이스 업그레이드를 실행하고자 하는 Physical Standby 사용자들에게 혜택을 제공한다.

2.1.4 데이터 보호 강화

Physical Standby인 경우 다음과 같은 기능으로 데이터 보호를 한다.

데이터 손상을 가져올 수 있는 결함이 있는 스토리지 하드웨어와 펌웨어로 인해 발생하는 손실 데이터 파일 쓰기를 감지한다.
Standby 적용시 블록 버전을 확인하여 버전의 차이가 있을 경우, 쓰기 손실을 표시한다.

2.1.5 보안강화 (SSL 인증 redo 전송)

SSL 인증을 비밀번호 파일과 함께 사용하여 redo 전송을 인증할 수 있다.

2.1.6 추가 SQL Apply 데이터 유형 지원

Logical Standby 시 다음의 추가 데이터 유형 및 기타 오라클 기능, PL/SQL을 지원한다.

XMLType 데이터 유형 (CLOB로 저장되는 경우)
Logical Standby DB에서 병렬로 DDL을 실행하는 기능
TDE (Transparent Data Encryption)
DBMS_FGA (Fine Grained Auditing)
DBMS_RLS (Virtual Private Database: 가상 개인 데이터베이스)

2.1.7 Logical Standby 관리 강화

다음과 같은 기능이 가능하다.

DBMS_SCHEDULER Package를 사용해 Standby DB에서 Scheduler Job을 생성하고 의도된 대로 작동할 수 있도록 적합한 데이터베이스 역할과 연관시킬 수 있다.
Oracle RAC DB와 함께 SQL Apply를 사용하면 각 Oracle RAC 클러스터의 최초 인스턴스를 제외한 모든 인스턴스의 사전 중지 필요성이 더 이상 없다.
SQL Apply를 다시 시작할 필요 없이 Data Guard SQL Apply 파라미터를 동적으로 설정할 수도 있다.
DBMS_LOGSTDBY.APPLY_SET 패키지를 사용해 초기화 파라미터를 동적으로 설정함으로써 Logical Standby DB 구성의 관리, 업타임, 자동화를 개선할 수 있다.

2.1.8 Data Guard Broker 강화

다음과 같은 기능 강화로 Data Guard Broker를 사용할 때 관리가 더욱 간편해 진다.

redo 전송 옵션 지원을 개선해 관리자가 redo 전송 서비스를 위한 연결 설명을 구체화
보호 모드와 MAXIMUM AVAILABLE/MAXIMUM PERFORMANCE 사이의 변경 시 데이터베이스 downtime을 제거
Oracle Clusterware를 Cold FailOver Cluster로 사용해 고가용성 구성을 위한 단일 인스턴스 데이터베이스 지원

2.1.9 Enterprise Manager Grid Control 11g 기능 개선

다음과 같은 기능이 개선되었다.

기존 RMAN 백업에서 Standby DB 생성
Oracle RAC Primary Database에서 Oracle RAC Standby DB 생성
리포팅, 개발, 테스트를 위한 자동 재기 복사
SwitchOver나 Fail-Over 시 Enterprise Manager 업무와 성능 한계를 새로운 Primary Database로 자동 전파
Fast Start Fail-Over를 위한 작동 대체 옵저버 (Fault-tolerant observer)
Enterprise Manager Data Recovery Advisor가 IDR (Intelligent Data Repair)를 권장을 할 때 사용 가능한 Standby DB 활용

2.2 새로운 Oracle Database 11g 데이터베이스 옵션

Oracle Database 11g Enterprise Edition에서 제공하는 새로운 데이터베이스 옵션을 사용해 Data Guard 구성을 강화할 수 있습니다. 데이터베이스 옵션은 오라클 데이터베이스의 사용과 성능을 확장하기 위해 별도 라이선스 제품으로 제공되고 있다.

2.2.1 Oracle Active Data Guard

실서비스를 위한 DB에서 한 개 이상의 동기화된 데이터베이스로 자원 집중 활동을 오프 로딩하는 방식으로 QoS를 강화하는 Oracle Database 11g Enterprise Edition을 위한 옵션이다. Active Data Guard 옵션과 함께 제공되는 실시간 쿼리 기능을 사용해 계속해서 서비스용 데이터베이스에서 받은 변경내용을 Apply하면서, 쿼리, 소팅, 리포팅, 웹 기반 접속 등을 위한 Physical Standby DB에 읽기 전용 접속을 실행할 수 있다.
또한 Physical Standby DB 상에서 RMAN 블록 변경 추적을 실행해 Physical Standby DB에서 신속한 증가 백업을 실시할 수 있다.

2.2.2 Oracle Advanced Compression

늘어나는 데이터 양을 비용 효율적으로 관리하도록 하는 Oracle Database 11g Enterprise Edition의 옵션이다.
Advanced Compression은 네트워크 트래픽과 백업 프로세스 중의 데이터뿐만 아니라 문서, 이미지, 멀티미디어와 같은 다양한 체계/비체계화 된 데이터를 비롯한 모든 유형의 데이터를 압축한다.
Advanced Compression 옵션은 Standby DB에서 아카이브 로그 갭의 Data Guard 11g 해결 중에 redo 데이터의 네트워크 압축을 수행합니다. 따라서 네트워크나 Standby DB 작동 중지 후에 Standby DB의 재동기화를 가속화하고 네트워크 대역폭을 좀더 효율적으로 활용할 수 있다.

3. Data Guard Process Architecture

전체 구조는 다음 그림과 같다.

진행 순서는 다음과 같다.

LNS(LogWriter Network Server)라는 특수 BackGround프로세스를 사용하여 Log Writer가 작성하는 redo 데이터를 캡쳐해 동기 또는 비동기로 데이터를 Standby DB에 전송한다. (SYNC와 ASYNC에 따라 동작 방법이 조금 다르다.)
--> LNS 프로세스는 Log Writer와 분리되어 전송 오버헤드와 네트워크 방해로부터 분리한다.
한 개 이상의 Remote File Server (RFS)프로세스를 스탠바이 데이터베이스에서 사용해 redo 데이터를 수신하고 Standby Redo Log (SRL) 파일에 데이터를 작성한다.
Managed Recovery Process (MRP)는 redo 데이터의 애플리케이션을 물리적 스탠바이 데이터베이스에 조정하는데 사용하며, Logical Standby Process (LSP)는 SQL 번역 redo 데이터를 논리적 스탠바이 데이터베이스에 조정하는데 사용한다.
Data Guard Broker가 활성화되면 Data Guard 역시 Data Guard Broker Monitor (DMON)과 다른 프로세스를 사용해 기본과 스탠바이 데이터베이스를 통일된 구성으로 관리하고 모니터링 한다.

SYNC의 특징은 다음과 같다.

Sync 시 동기화를 위해 Primary Database에 있는 Log Writer가 LNS로부터 Standby DB가 redo 데이터를 받았으며 기다렸다가 클라이언트 애플리케이션에 실행을 확인하기 전에 스탠바이 redo 로그에 데이터를 작성했다는 확인을 기다린다.
확인 후 다음 작업을 진행한다.
ASYNC 프로세스는 다음과 같은 특징을 가진다.
Primary에 있는 Log Writer가 Standby 데이터 모드로부터 redo가 디스크에 작성되었으며 redo 전송과 비동기인 클라이언트 애플리케이션에 실행이 확인되었다는 확인을 기다릴 필요가 없다.
매우 효율적으로 redo를 Standby DB에 전송해 네트워크 확인으로 인해 야기되는 네트워크 작업량 감소의 원인이 되는 오버헤드를 제거한다
Primary와 Standby가 분리되는 경우 다음과 같이 동작한다.
Primary와 분리된 경우 선택된 보호 모드에 따라 Primary DB가 트랜잭션을 계속해서 프로세스하고 새로운 네트워크 연결이 이루어질 때까지 Standby에 전달할 수 없는 redo 데이터를 축적한다. (Archive log gap)
위와 같은 상태에서 Data Guard가 Standby 를 모니터링하여, 쉽게 재동기화 할 수 있게 해준다.
갭을 해결하는데 필요한 로그 파일은 Archive Process를 이용해서 전달한다.
마지막으로 스탠바이 적용 프로세스가 수신한 아카이브 로그에서 사라진 로그 파일을 감지하거나 결함이나 손상을 감지하는 경우에 Data Guard 스탠바이 데이터베이스가 아카이브 로그의 새로운 카피를 요청한다. ARCn 프로세스를 사용해 이와 같은 요청을 수행한다.

Gap 해결을 가속하하는데 사용하는 몇가지 옵션
다음의 옵션을 사용하여 Gap 문제를 해결 할 수 있다.

Advanced Compression 옵션을 사용해 전송되는 아카이브 로그에서 네트워크 컴프레션을 실행해 전송 시간을 줄이고 가용 대역폭을 최대한 활용할 수 있다.
전송되어야 하는 아카이브 로그가 많은 경우에는 최대 30개의 ARCn 프로세스를 활성화할 수 있다. 이들 ARCn 프로세스 중 29개는 원격 위치에 발송될 수 있으며 한 개는 항상 로컬 아카이브에 지정되어 있다.
아카이브 로그 수는 적은데 크기가 커서 백로그가 있는 경우에는 최대 다섯 개 ARCn 프로세스를 한 개의 로그 파일로 병렬 발송하도록 구성한다.

4. 주요 기술 구성요소

4.1 Data Guard 구성 유연성 증가

Data Guard 11g은 기본과 스탠바이 시스템에서 O.S. 바이너리와 오라클 데이터베이스 바이너리와 같이 다양한 CPU 아키텍처 구축 옵션을 제공한다. 예를 들어, Primary Database가 Windows 상에 위치하고 스탠바이 데이터베이스는 Linux 상에 위치할 수 있다.
즉, Data Guard 11g 은 기본과 스탠바이 시스템이 다른 CPU 아키텍처와 운영시스템 (Windows와 Linux 등), 운영시스템 바이너리 (32/64-bit), 오라클 데이터베이스 바이너리 (32/64-bit)를 가진 경우에 Data Guard 구성 유연성을 증대한다.
하지만, MetaLink Note 413484.1.에서 설명하는 제약에 적용을 받음.

참고
Primary DB와 Standby DB의 두 개의 상시 요건은 논리적 스탠바이 데이터베이스를 사용하는 롤링 데이터베이스 업그레이드 중을 제외하고 endian 포맷이 항상 동일해야 하며 오라클 데이터베이스 출시가 동일해야 한다는 점이다.

4.2 보호 모드

데이터 가드는 비용, 가용성, 성능, 데이터 보호 사이의 균형을 위해 세가지 모드의 데이터 보호를 제공한다. 이들 모드는 Data Guard 구성 행동을 관장하는 규칙을 정의하며 사용 가능한 관리 인터페이스를 사용해 쉽게 설정할 수 있다.
다음과 같은 구문을 사용하여 보호 모드를 설정한다.


SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY | PERFORMANCE};

보호 모드에 따른 특성은 다음과 같다.

4.2.1 Maximum Protection

Maximum Protection은 최고 수준의 데이터 보호를 제공한다.

최대 보호는 SYNC redo 전송을 사용해 redo 기록을 Standby DB에 동기 전송한다.
Primary DB의 Log Writer 프로세스는 Data Guard가 트랜잭션 데이터가 적어도 한 개의 Standby DB에서 디스크가 안전하게 있다는 확인을 할 때까지 클라이언트 Application에 실행을 확인하지 않는다.
Redo 전송의 동기적 성격으로 인해 최대 보호가 Primary DB 응답 시간에 영향을 미칠 수 있다.
--> 최대 보호를 최소 두 개의 Standby DB로 구성해서 한 개 Standby 수신지에서 장애가 발생하면 나머지 위치에서 여전히 Primary DB를 확인하고 서비스가 계속해서 방해를 받지 않도록 할 것을 권장한다.

4.2.2 Maximum Availability

Maximum Availability는 Primary DB의 가용성을 유지하면서 다음으로 높은 수준의 데이터 보호를 제공한다.

Maximum Protection과 마찬가지로 SYNC redo 전송 서비스를 사용해 redo 데이터를 Standby DB에 동기 전송한다.
Log Writer는 Data Guard가 트랜잭션 데이터가 최소 한 개 Standby DB의 디스크에서 사용할 수 있다고 확인할 때까지 Primary Database에 의한 트랜잭션 실행을 확인한지 않는다.
Maximum Protection과는 달리 마지막 참여 데이터베이스가 사용할 수 없게 되면 (네트워크 연결 문제나 스탠바이 장애 등) Primary Database 프로세싱이 계속된다.
연결이 다시 이루어지면 Data Guard가 자동으로 Standby DB를 Primary Database와 재동기화한다.
-->동기 redo 전송 때문에 이와 같은 보호 모드가 응답 시간과 작업량에 영향을 미칠 수 있다. 초기 네트워크나 스탠바이 장애가 해결되고 구성이 재동기화 되기 전에 두 번째 장애로 인해 생산 데이터베이스에 영향이 미치는 경우에 데이터 손실 가능성이 있음을 수용해야 한다.

4.2.3 Maximum Performance

Maximum Performance는 default 보호 모드이다. Maximum Availability 보다 Primary DB 성능이 높을 수 있지만 데이터 보호는 약간 낮은 편이다.

이 모드에서는 Primary Database가 트랜잭션을 프로세스하면서 redo 데이터가 ASYNC redo 전송을 사용해 스탠바이 데이터베이스에 비동기 전송된다.
Primary Database 상의 Log Writer는 클라이언트 애플리케이션에 실행을 확인하지 전에 스탠바이 확인을 기다리지 않는다.
--> 정상 작동 중에는 데이터 손실 노출이 기본과 Standby DB 사이의 in-flight에 해당되는 데이터 분량으로 제한된다. 이 분량은 Primary Database가 생성하는 redo 데이터 분량을 처리할 수 있는 네트워크 용량의 기능을 표시한다. 적합한 대역폭이 제공되는 경우에 전체 데이터 손실 노출은 매우 낮거나 없다.

4.3 Auto Gap 해결 - 통신 장애 처리

Data Guard는 Primary Database에서 Standby DB를 일시 분리하는 네트워크 연결성 문제를 원활하게 처리한다. 정확한 행동은 선택된 Data Guard 보호 모드의 규칙에 의해 정해진다.
최종 Standby DB를 사용할 수 없는 경우에 Maximum Availability와 Maximum Performance 모두 Primary Database가 프로세싱 트랜잭션을 계속할 수 있도록 합니다. Standby 연결이 다시 이루어지면 Standby가 기본과 신속하게 재동기화 되면서, 축적된 아카이브 로그가 자동으로 Standby DB에 전송되어 적용됩니다.

4.4 Apply Services - Redo Apply 와 SQL Apply

Data Guard는 redo 데이터를 Primary DB에 적용하는 두 가지 방법을 제공하며, 이들 방법은 Data Guard가 지원하는 두가지 유형의 Standby DB에 상응한다.

Redo 사용 : Physical Standby DB 사용
SQL 사용 : Logical Standby DB 사용

4.4.1 Physical Standby DB - Redo Apply

Physical Standby DB는 오라클 미디어 복구를 사용해 기본에서 수신한 redo 데이터를 적용한다. 블록 대 블록 기반으로 Primary Database와 물리적으로 동일하기 때문에 인덱스를 비롯한 데이터베이스 스키마가 동일하다.

Redo 적용 작동 방법

Data Guard Redo 적용은 Managed Recovery Process (MRP)라는 특별한 프로세스를 사용합니다. RFS프로세스가 redo 데이터를 Standby Redo Logs (SRLs)에 작성할 때 MRP가 redo 데이터를 읽고 데이터를 Physical Standby DB에 적용합니다.
MRP는 데이터베이스를 mounting한 후 다음과 같은 명령어를 사용해 Physical Standby DB에서 시작됩니다.


SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

MRP가 SRL 읽기를 완료하기 전에 SRL이 아카이브 되는 경우 MRP가 스탠바이 아카이브된 로그에서 읽기로 전환될 수 있다 (Primary Database의 redo 생성 속도가 매우 빠른 경우에 발생할 수 있는 상황). Data Guard Redo 적용의 최고 성능을 위해 MRP를 병행해서 작동할 수 있다. MRP가 가동 시에 병렬 복구 프로세스의 최적 숫자를 자동으로 결정한다.

Redo의 Standby DB 적용 전 데이터 검증

Data Guard의 가장 큰 장점 중 하나가 오라클 프로세스를 사용해 redo 데이터를 Standby DB에 적용하기 전에 이들 데이터를 검증하는 기능이다.
Data Guard는 Standby DB를 redo 블록을 적용하는 방식으로 Primary DB에서 발생할 수 있는 데이터 파일 손상과 완전히 분리해서 동기화하는 아키텍처입니다. SYNC redo 전송의 경우, redo가 기본 SGA에서 전송되기 때문에 Primary Database 상의 물리적 입출력 손상과 완전히 분리됩니다. Standby DB에서 실행되는 소프트웨어 코드 경로 역시 Primary Database의 경로와 근본적으로 다르기 때문에, Primary Database에 영향을 주는 소프트웨어 오류로부터 Standby DB를 효과적으로 보호할 수 있습니다. 손상 감지 확인은 다음의 주요 인터페이스 발생합니다.

Redo 전송 중 Primary DB : LGWR, LNS, ARCH
Redo 적용 중 Standby DB: RFS, ARCH, MRP, DBWR
Standby DB에서 Redo 적용이 redo 손상을 감지하는 경우에 Data Guard가 원래 아카이브 로그가 손상되지 않았다는 가정하에서 유효 로그를 아카이브 로그 갭의 일부로 다시 패치합니다.

[DB_LOST_WRITE_PROTECT]

Redo 쓰기 손실 감지

사실상 읽기가 스토리지에서 발생하지 않았는데 입출력 서브 시스템이 쓰기 완료를 확인하는 경우에 쓰기 손실이 발생한다. 이어지는 블록 읽기에서 입출력 서브 시스템이 데이터 블록의 스테일 (stale) 버전을 되돌려 데이터베이스의 다른 블록을 업데이트하는데 사용할 수 있으며, 이로 인해 데이터가 손상된다.
DB_LOST_WRITE_PROTECT 초기 파라미터가 설정되면 데이터베이스가 redo 로그에 버퍼 캐시 블록 읽기를 기록하며, 이 정보를 손실된 쓰기를 감지하는데 사용한다.
쓰기 손실 감지는 Data Guard와 사용할 때 가장 효과적이다. 이 경우에 기본과 Standby DB 모두에서 DB_LOST_WRITE_PROTECT를 설정한다. Standby DB가 관리된 복구 중에 redo를 적용하는 경우에 상응하는 블록을 읽고 redo 로그에 있는 SCN과 비교한다.

Primary DB의 블록 SCN이 Standby DB 보다 낮은 경우에는 Primary DB에서 손실된 쓰기를 감지한 후 외부 오류를 제거한다 (ORA-752). Primary DB에서 손실된 쓰기를 수리하는 바람직한 절차는 Physical Standby에 Fail-Over하고 기본을 재생성하는 것이다.
SCN이 높은 경우에는 Standby DB에서 손실된 쓰기를 감지한 후 내부 오류를 제거한다 (ORA-600 3020). Standby DB에서 손실된 쓰기를 수리하기 위해서는 Standby DB나 영향을 받은 파일을 반드시 재생성해야 한다.
두 개 경우 모두에서 Standby DB가 경보 로그와 추적 파일에 장애 이유를 작성한다.
위의 기능은 모두 Primary Database에서 발생하는 손상이 Standby DB의 완전성에 영향을 주어서는 안 된다는 Data Guard의 근본적인 원칙을 실현합니다.

Redo 적용 및 실시간 쿼리

액티브 Data Guard 옵션의 실시간 쿼리를 사용해 redo 적용이 켜져 있는 상태에서 (복구가 활성화 된 상태)Physical Standby DB를 읽기 전용으로 공개함으로써 쿼리가 Primary Database의 최신 복제에 대해 작동할 수 있도록 합니다. 이러한 기능은 Enterprise Manager Grid Control 11g를 사용하거나 다음과 같은 방식으로 명령어 라인에서 수동으로 활성화 할 수 있습니다.

Redo 적용이 활성화 된 경우에 읽기 전용 접속을 위해 Standby DB를 공개하기 위해서는 먼저 다음과 같은 구문을 사용해 redo 적용을 취소한다.


SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

다음과 같은 구문을 사용해 읽기 전용 접속을 위해 DB를 Open한다.


SQL> ALTER DATABASE OPEN;

Standby DB가 공개되면 다음과 같은 구문을 사용하여 redo 적용을 다시 한다.


SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE

SnapShot Standby

SnapShot Standby DB는 Physical Standby DB를 Snapshot Standby DB로 전환해서 생성하는 완전한 업데이트가 가능한 Standby DB이다.

SnapShot Standby DB는 Primary Database로부터 redo 데이터를 받고 아카이브하지만 바로 Apply 하지는 않는다.
Primary Database에서 받은 redo 데이터는 SnapShot Standby DB가 그동안 SnapShot Standby DB에 모두 로컬 업데이트된 내용을 버린 후에 다시 Physical Standby DB로 전환되면 적용된다.
SnapShot Standby는 Enterprise Manager, Data Guard Broker 명령어 라인 인터페이스(DGMGRL), SQL*Plus에서부터 생성될 수 있습니다.
SQL*Plus에서 SnapShot Standby DB를 생성하기 위해서는 단순히 다음의 명령어를 Physical Standby DB에서 실행한다.


SQL> ALTER DATABASE CONVERT TO SNAPSHOT STANDBY;

Standby DB가 SnapShot Standby로 전환되는 경우에 간접적으로 보장되는 복구 지점이 생성되고 플래시백 데이터베이스가 활성화된다. SnapShot Standby를 사용 후 마친 후에는 Physical Standby DB로 다시 전환되어 다음을 명령어를 통해 Primary Database와 재동기화된다.


SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY DATABASE;

Data Guard는 DB를 보장된 복구 지점으로 간접적으로 플래시하며, SnapShot이 생성된 후부터 Standby에서 아카이브 된 Primary Database Redo를 자동으로 적용한다. 이 프로세스가 완료되면 보장된 복구 지점도 Drop된다.
SnapShot Standby DB를 ReadOnly로 열어서 테스트나 기타 용도로 사용할 수 있다. Primary Database가 계속해서 redo 데이터를 SnapShot Standby DB에 전송해 데이터가 원격 위치에서 보호받을 수 있도록 한다. SnapShot Standby DB는 redo를 안전하게 유지 하기 위해 아카이브한다. 테스트 활동이 완료되면 SnapShot Standby DB를 Physical Standby DB로 전환하여 SnapShot Standby DB로 작동하는 중에 Primary에서 받은 로그 파일을 적용하는 방식으로 SnapShot Standby DB를 재동기화한다.

4.4.2 Logical Standby DB - SQL Apply

데이터의 물리적 조직과 구조가 다를 수 있지만 Logical Standby DB에는 Primary Database와 동일한 논리적 정보가 포함되어 있다. SQL 적용 기술은 Primary Database에서 받은 redo 데이터를 SQL 구문으로 변형한 후에 Standby DB 상에서 SQL 구문을 실행하는 방식으로 Logical Standby DB를 Primary Database와 동기화해 유지한다. Physical Standby DB와 유사하게, 이를 통해 적용이 활성화된 상태에서 쿼리나 리포팅 목적으로 Logical Standby DB에 접속할 수 있다.
Logical Standby DB는 SQL 구문을 사용해 업데이트되기 때문에 Physical Standby DB보다 유연성이 높다. 따라서 Logical Standby DB는 읽기-쓰기 모드에서 열수 있고 데이터베이스에 읽기-쓰기 접속을 필요로 하는 다른 업무를 수행할 수 있다 (Standby DB에만 존재하는 로컬 테이블 추가나 읽기-쓰기 접속을 필요로 하는 리포팅이나 합산 수행 등). SQL 적용에 의해 유지되는 테이블 상에 추가 인덱스와 Materialized뷰를 생성함으로써 이들 업무를 최적화 할 수 있다 (데이터베이스가 공개 읽기-쓰기이지만 SQL 적용이 Primary Database와 동기화를 책임지는 데이터에는 변경을 허용하지 않는다는 사실에 주의해야 한다.)
Logical Standby DB는 여러 데이터베이스 스키마를 호스팅하고, 사용자는 Primary Database에서 업데이트되지 않는 스키마에 있는 테이블 에서 정상적인 데이터 조작을 할 수 있다. Logical Standby DB는 데이터 유형, 테이블 유형, DDL-DML 작동 유형에 다소의 제약이 있다.
지원이 되지 않는 데이터 유형과 스토리지 특성 목록은 아래 문서를 참조한다.
http://download.oracle.com/docs/cd/B28359_01/server.111/b28294/toc.htm

SQL 적용 작동 방법

SQL 적용은 Primary Database에서부터 Logical Standby DB로 변경 적용 업무를 수행하는 Background 프로세스 컬렉션을 사용한다. 다음 그림에서 각 프로세스가 수행하는 정보 흐름과 역할을 표시하고 있다.

[ SQL 적용 프로세스 ]

각 프로세스의 기능은 다음과 같다.

Reader 프로세스는 스탠바이 redo 로그에서 나온 유입 redo 기록을 읽는다.
Preparer 프로세스는 블록 변화를 테이블 변화나 논리적 변화 기록 (LCR)로 전환시킨다.
Builder 프로세스는 개별 LCR로부터 완전한 트랜잭션을 어셈블링한다.
Analyzer 프로세스는 다양한 트랜잭션 사이의 차이를 확인해 완전한 트랜잭션을 검토한다.
Coordinator 프로세스는 (논리적 스탠바이 프로세스 (LSP)라고 하기도 함) 적용 프로세스에 트랜잭션을 할당하고, 트랜잭션 사이의 차이를 모니터링하고, 스탠바이 데이터베이스에 변화 실행을 논리적 수락한다.
Applier 프로세스는 할당된 트랜잭션에 대한 LCR을 데이터베이스에 적용하고 코디네이터가 지시하는 경우에 트랜잭션을 실행한다.

다음의 SQL 명령어를 입력하면 이들 SQL 적용 프로세스가 시작된다.


SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

추가된 SQL 적용 새로운 기능

다음의 사항에 대해 적용이 가능해 졌다.

XMLType 데이터 유형 (CLOB)
구획으로 나누어지지 않고 LOB, LONG, XML 유형 컬럼을 포함하지 않은 테이블에 대한 삽입과 업데이트에 의해 특징지어지는 작업을 위해 SQL Apply 성능이 강화되었다.
DDL 병렬 실행
병렬 DDL 역시 SQL 적용에 의해 병렬로 적용되어 SQL Apply 성능이 강화되었다.
Transparent Data Encryption (TDE)

4.5 Data Guard 구성 관리

4.5.1 System View

Data Guard는 구성의 런타임 성능을 자세하게 살펴보는 다양한 view를 제공한다.

[V$REDO_DEST_RESP_HISTOGRAM]

SYNC redo 전송 수신지를 위한 응답 시간 히스토그램을 포함하는 고정 View이다.

4.5.2 Data Guard Broker

Data Guard Broker는 Data Guard 구성의 생성, 유지, 모니터링을 자동화하고 중앙화하는 분산 관리 프레임워크이다.
Data Guard Broker의 기능은 간단히 다음과 같다.

Data Guard 구성을 생성하고 활성화
구성의 어느 위치에서나 전체 Data Guard 구성을 관리
구성의 모든 시스템에 걸쳐 복잡한 역할 변화와 관련된 스위치오버나 페일오버 작동 (패스트 스타트 페일오버 포함)을 불러 옴.
중앙화된 모니터링과 이벤트 통보로 신속하게 적용 속도를 모니터링하고 진단 정보를 캡처하고 문제를 감지

4.6 역할 관리 서비스 (Role Management Services)

4.6.1 SwitchOver

SwitchOver는 운영 시스템이나 하드웨어 업그레이드나 오라클 데이터베이스 소프트웨어와 패치 세트의 롤링 업그레이드와 같은 예상된 작동 중지 시에 Primary Database 다운타임을 줄이는데 사용한다.
SwitchOver 운영을 위해서는 모든 사용자 세션이 Primary Database에서 분리되어야 한다. 그 다음, Primary Database를 Standby 역할로 전환한 후 Standby DB를 기본 역할로 전환한다.SwitchOver는 Oracle Enterprise Manager GUI 인터페이스나 Data Guard Broker의 명령어 라인 인터페이스를 사용하는 관리자가 또는 SQL을 통해서 직접 시작할 수 있다.
예를 들어, 다음의 단일 Data Guard Broker CLI (DGMGRL) 명령어가 "Chicago" Standby DB로 SwitchOver를 시작하고 완료한다.


DGMGRL> SWITCHOVER TO Chicago;

일단 시작되면, Data Guard가 실제 역할 전환 프로세스를 자동화한다. 프로세스 중에 데이터 손실이 없다.

4.6.2 FailOver

FailOver는 예상하지 못한 장애가 Primary Database에 발생할 때 온라인으로 Standby DB 중 하나를 가져오는 동작이다. 따라서 Primary Database에 영향을 주는 이벤트를 진단하고 해결하는 동안에 DownTime이 발생하는 대신에 Standby를 기본 역할로 신속하게 올려서 재해 시간 목표를 달성할 수 있다. FailOver 동작을 위해서 Standby DB를 다시 시작할 필요가 없다. 데이터베이스 파일이 원래 Primary Database에서 영향을 받지 않고 유지되는 한 데이터베이스를 다시 시작하면 원래 Primary Database가 복귀되어 플래시백 데이터베이스를 사용해 새로운 기본을 위한 Standby DB로 재동기된다. 이때 백업에서 복구할 필요가 없다.
수동 FailOver는 Oracle Enterprise Manager GUI 인터페이스나 Data Guard Broker의 명령어 라인 인터페이스를 사용하는 관리자나 SQL*Plus을 통해 직접 시작된다. 예를 들어 다음의 단일 Data Guard Broker CLI (DGMGRL) 명령어가 "Chicago" Standby DB에 FailOver를 시작하고 완료한다.


DGMGRL> FAILOVER TO Chicago;

Data Guard가 Maximum Protection이나 Maximum Availability에서 작동되고 있고 대상 Standby DB가 FailOver 시에 동기화되는 경우에 데이터 손실이 전혀 없다. Maximum Performance 모드에서는 FailOver 당시에 Standby DB로 보내지지 않은 Primary Database의 redo 데이터가 여전히 있는 경우에 데이터 손실이 일어날 수도 있다. 수동 FailOver에 더해 고객은 Data Guard가 철저하게 통제되는 방식으로 자동 FailOver를 수행하도록 구성하는 옵션을 사용할 수도 있다. 이 내용은 뒷부분에서 설명할 것이다.

4.6.3 Fast-Start FailOver

Fast-Start FailOver를 사용해 Data Guard가 FailOver를 불러 일으키기 위해 수동 단계를 거치리 안하고 미리 선택한 Standby DB에 자동으로 FailOver할 수 있도록 한다. 뿐만 아니라 장애 Primary Database가 복귀할 때 자동으로 새로운 Primary Database의 Standby로 구성되어 복귀된다. Fast-Start FailOver는 Data Guard Broker 구성에서만 사용할 수 있으며 DGMGRL나 Enterprise Manager를 통해서만 구성이 가능하다.
Fast-Start FailOver 구성은 DGMGRL 클라이언트 사이드 구성요소에 통합되는 가벼운 프로세스인 별도의 옵저버 프로세스로 모니터링 한다. 계속해서 Fast-Start FailOver 환경을 모니터링 해서 Primary Database가 사용 가능하도록 확인한다. 옵저버와 Standby DB 모두 Primary Database와 연결을 해제되는 경우에 옵저버가 Fast-Start FailOver를 시작하기 전의 구성 시간 동안 Primary Database에 연결을 시도한다.
Fast-Start FailOver는 세 개의 Fast-Start FailOver, 즉 기본, 스탠바이, 옵저버 중, 최소 두 개에서 주요 상태 전환에 동의하도록 고안되었으며, 따라서 프로덕션 작업을 담당하는 두 개의 나뉘어진 Primary Database가 있을 수 있는 split-brain 시나리오와 같은 상황을 방지할 수 있다. Fast-Start FailOver의 간단하지만 세련된 아키텍처로 데이터 보호 역시 중요한 고가용성 상황에서 사용할 수 있다.
Enterprise Manager의 장점은 Data Guard Fast-Start FailOver 구성에서 옵저버를 위한 고가용성을 활성화한다는 점이다. Enterprise Manager는 옵저버의 상태를 모니터링 하고, 옵저버 장애를 감지하고, 옵저버를 원래 호스트에서 다시 시작하려 시도하고, 이러한 시도가 실패하는 경우에는 옵저버를 사전에 지정된 두 번째 호스트에서 다시 시작한다. 옵저버의 고가용성을 보장하는 Enterprise Manager 기능은 Data Guard Fast-Start FailOver를 활용하는 HA 전략의 중요한 요소입니다.

4.6.4 유연한 구성 옵션

Fast-Start FailOver의 행동을 통제하기 위해 제공되는 특징 중 일부이다.

FastStartFailoverThreshold
옵저버와 대상 Standby DB가 failover 후 시작 전에 기다려야 하는 초 단위
FastStartFailoverLagLimit
적용하려는 시점이 이 값으로 지정된 초보다 뒤쳐지는 경우에 Fast-Start Failover가 허용되지 않는다. 이 특징은 Maximum Performace만 적용되며, 구성이 최대 Maximum Availability모드에서 작동하고 있을 때는 사용할 수 없다.
FastStartFailoverAutoReinstate
장애가 일어난 Standby의 자동 복귀를 방지하기 위해 FALSE로 설정한다.

DGMGRL ENABLE FAST_START FAILOVER CONDITION 명령을 사용해 Fail-Over 한계 시간이 경과하기를 기다릴 필요없이 Fast-Start Fail-Over발생해야 하는 조건을 명시하기도 한다. 다음과 같은 경우를 명시할 수 있다.

Datafile Offline 쓰기 오류로 인한 데이터 파일 오프라인
Corrupted Controlfile 손상 컨트롤 파일
Corrupted Dictionary 크리티컬 데이터베이스 대상의 사전적 (Dictionary) 손상
Inaccessible Logfile 입출력 오류로 인해 Log Writer가 로그 그룹에 전혀 쓰기를 할 수 없음.
Stuck Archiver 장치가 다 찼거나 사용 가능하지 않아 Archiver가 redo 로그를 달성할 수 없음.

DBMS_DG PL/SQL 패키지를 사용하여 Application이 특정 조건과 마주치는 경우에 Fast-Start FailOver를 요청하도록 할 수 있다.

4.6.5 구 Primary DB를 새로운 Standby DB로 복구

장애 후에 새로운 기본의 백업으로부터 Standby DB를 재구성할 필요가 없는 경우 복구 시킬 수가 있는다. 이때 장애 이벤트가 발생하기 전에 플래시백 DB를 활성화시켜야 한다.) 이때, Fast-Start FailOver를 사용해 자동으로 이루어 진다.
수동으로도 처리는 가능하다.


DGMGRL> REINSTATE DATABASE 'database';

4.7 자동 Client FailOver

다음과 같이 구분이 가능하다.
Complate-site FailOver
Data Guard Standby DB와 완전히 중복되는 중간층 애플리케이션 세트를 호스팅하는 2차 사이트를 활용한다. 2차 사이트로 Fail-OVer 할 때 중간층 서버가 시작되고 네트워크 로드 밸런서가 새로운 기본 사이트로 다시 경로 설정된다. Data Guard Fail-Over가 2차 지점에 있는 Standby DB를 Primary 역할로 전환한다. Oracle MAA 문서인 오라클 데이터베이스 가용성 베스트 프랙티스 (Oracle Database High Availability Best Practices) 5에서 컴플릿 사이트 페일오버 실행 안내를 제공한다.
Oracle RAC 내 노드 장애가 발생한 경우
장애 노드에 연결된 클라이언트에게 장애가 발생했음을 신속하게 알리고 클러스터의 살아남은 노드에 다시 연결하여 프로세싱을 계속해야 한다. 기술 백서인 Oracle Real Application Clusters를 사용한 작업부하 관리 (Workload Management with Oracle Real Application Clusters) 6에서 Oracle RAX 내의 노드 장애 처리를 위한 안내를 제공한다.
Partial-site FailOver
Primary Database를 사용할 수 없게 되었지만 Data Guard Fail-Over 이후에 Primary DB가 손상을 받지 않고 남아 있으며 영향을 받은 클라이언트를 2차 위치의 새로운 Primary Database로 다시 경로 설정해야 하는 경우에 발생한다. 파셜 사이트 장애에 대한 Client Fail-Over 실행 개요는 아래와 같다. 자세한 내용은 고가용성 오라클 데이터베이스의 클라이언트 페일오버 베스트 프랙티스 (Client Failover Best Practices for Highly Available Oracle Databases) 7를 참조한다.
참고
높은 수준에서 Data Guard 구성의 Client Fail-Over 자동화에는 클라이언트에게 장애가 발생한 사실을 통보하고 TCP 타임아웃에서 해제한 후 클라이언트를 새로운 Primary Database에 다시 경로 설정해 Data Guard 페일오버의 일환으로 데이터베이스 서비스를 새로운 Primary Database로 재위치시키는 것이 포함된다.

4.7.1 서비스 이동

Oracle Database 10g은 데이터베이스 서비스라고 불리는 Oracle RAC의 자동 작업부하 관리 기능과 단일 인스턴스 (non-RAC) 데이터베이스를 도입해 데이터베이스 작업부하를 그룹으로 하고 컴퓨팅 자원을 이들 부하에 지정한다. 특정 아래 예에서 사용되는 "판매" 애플리케이션과 같이 애플리케이션에 대한 데이터베이스 서비스를 정의할 수 있으며, Primary Database에서 서비스 장애가 일어나는 경우에 이 서비스가 Data Guard FailOver의 일환으로 자동으로 새로운 Primary Database로 이동한다.
Oracle RAC 클러스터 사용자가 listener 등록을 사용하면 클러스터에 있는 모든 listener가 어떤 인스턴스가 현재 데이터베이스 서비스를 제공 중인지 연결 요청이 수신되면 알 수 있기 때문에 서비스를 제공하는 인스턴스에서 독립된 서비스에 접속할 수 있다. 서비스를 제공하는 인스턴스에 장애가 발생하면 Oracle RAC가 서비스를 클러스터 내에서 살아남은 인스턴스로 이동시킨다.
동일한 서비스 이동 개념이 Data Guard 구성에도 적용된다. 어떻게 발생하는지 알아보기 위해서는 단일 노드 기본과 Standbby DB를 이용해 간단한 Data Guard 구성에 착수한다. "판매" 라는 데이터베이스 서비스가 모든 적용 가용성 설정을 사용해 생성되고 구성된다. 클라이언트 애플리케이션이 구성에서 Primary와 Standby의 모든 호스트를 포함하는 Oracle Net 별칭을 사용해 "판매" 서비스에 연결된다. Oracle Net 별칭으로 사용한 서비스 명칭이 Primary Database를 위한 인스턴스 상에서만 작동하기 때문에 원하지 않는 스탠바이 데이터베이스에 대한 연결 시도를 방지할 수 있다. Primary Database로 서비스 이동은 Data Guard 역할 변경이 스탠바이 데이터베이스를 기본 역할로 전환할 때 시작되는 트리거가 사용되고 새로운 Primary Database에서 서비스가 시작되면서 자동화된다. 예는 다음과 같습니다.


CREATE OR REPLACE TRIGGER manage_service AFTER STARTUP ON database
DECLARE
role VARCHAR(30);
BEGIN
SELECT DATABASE_ROLE INTO role FROM V$DATABASE;
IF role = 'PRIMARY' THEN
DBMS_SERVICE.START_SERVICE('sales');
ELSE
DBMS_SERVICE.STOP_SERVICE('sales');
END IF;
END;

4.7.2 클라이언트 통보 및 재연결

상기 예에 이어서 클라이언트 통보와 재연결을 사용해 장애 시에 원래 Primary Database에 연결된 클라이언트들이 긴 TCP 타임아웃이 경과되기를 기다리는 hung-state 스탠바이에 들어가지 않도록 방지해 준다. 오라클은 이들 클라이언트에게 장애가 발생했다는 사실을 알리고, TCP 타임아웃에서 해제하고, 새로운 연결과 기존 연결이 살아남은 RAC 노드나 Data Guard 페일오버 후에 새로운 기본 스탠바이로 설정되도록 한다.
Fast Application Notification (FAN)을 사용하는 OCI 클라이언트를 위한 기능이다. 새로운 Primary Database가 어떤 클라이언트가 장애 인스턴스에 연결되어 있었는지 알고, FailOver Process의 일환으로 위의예에서 사용한 "판매" 서비스에 재연결하도록 통보한다. Data Guard 구성의 JDBC 클라이언트가 Fast Connection Failover와 Standby DB가 기본 역할로 전환할 때 DB_ROLE_CHANGE 시스템 이벤트에서 시작되는 Standby DB 상에서 생성되는 Trigger를 통해 통보를 받는다. Trigger는 오라클이 제공하는 퍼블리셔 프로그램을 호출해 클라이언트를 TCP 타임아웃에서 해제하고 JDBC 클라이언트에게 데이터베이스 서비스가 새로운 기본에서 사용 가능하다고 알린다.
최종 작업은 일단 클라이언트에게 장애를 통보한 후에 장애 호스트에 재연결을 시도할 때 이들 클라이언트들이 TCP 타임아웃에 적용되지 않도록 하는 것이다. 이는 SQLNET 아웃바운드 연결 타임아웃을 사용해 처음 호스트를 사용할 수 없는 경우 클라이언트가 신속하게 어드레스 목록의 다음 호스트에 연결을 시도할 수 있도록 한다
JDBC 클라이언트를 위한 데이터베이스 서비스 이동과 HA 이벤트 발행에 사용하는 트리거 예와 함께 OCI, OLE, DB, JDBC의 자세한 추가 구성 내용은 MAA 문서 가용성 오라클 데이터베이스의 클라이언트 페일오버 베스트 프랙티스 (Client Failover Best Practices for Highly Available Oracle Databases)에서 설명하고 있다.

4.7.3 역할 전환 이벤트

데이터베이스 전환이 하나에서 다른 하나로 전환될 때마다 Data Guard DB_ROLE_CHANGE 시스템 이벤트가 발사된다. 이는 ON STARTUP 시스템 이벤트와 매우 유사하며, 다만 역할 변경 후에 발사된다는 점이 다르다. 관리자는 이러한 이벤트가 발생할 때 역할 변경 이후 업무 관리의 한 방법으로 이를 실행하는 트리거를 개발할 수 있다. 새로운 역할에 상관없이 역할 전환 이후에 처음으로 데이터베이스가 공개되면 이벤트가 발사된다
DB_ROLE_CHANGE 시스템 이벤트는 역할 변경 이후 과제를 관리하고 자동화하는데 사용할 수 있으며, 자동 클라이언트 페일오버를 용이하게 하는 한 가지 방법이다. 이러한 과제들로는 새로운 프로덕션 데이터베이스 상에서 서비스를 시작하는 것, 클라이언트가 새로운 프로덕션 데이터베이스에 다시 연결할 수 있도록 명칭 해결 (name resolution) 서비스나 연결 기술어 (descriptor)를 변경하는 것, 3자 애플리케이션을 시작하는 것, 일시 테이블 스페이스를 추가하는 것 등이 있다. DB_ROLE_CHANGE는 관리자가 데이터베이스 트리거를 통해 달성하는 활동을 자동화할 수 있도록 하는 유연한 메카니즘이다.

4.8 Rolling Database Upgrades

주요 출시나 패치세트 업그레이드를 위한 (10.1.0.3) Oracle Database Software Upgrade는 Data Guard SQL Apply를 사용해 롤링 방식으로 실시할 수 있으며, 다음과 같다.

롤링 업그레이드 프로세스 단계는 다음과 같이 진행된다.

다음 출시 제품으로 논리적 스탠바이 데이터베이스를 업그레이드 하는 것,
업그레이드를 테스트하고 검증하기 위해 혼합 모드에서 작동하는 것,
업그레이드된 데이터베이스에 스위치오버를 통해 역할 전환하는 것,
최종적으로 구 Primary Database를 업그레이드 하는 것
다시 SwitchOver 해서 Primary DB로 서비스 하기

테스트 목적으로 혼합 모드에서 작동하는 경우, 업그레이드가 실패하면서 데이터 손실은 없지만 소프트웨어가 다운그레이드 될 수 있다. 이들 단계에서 추가 데이터 보호를 위해서는 두 번째 스탠바이 데이터베이스를 사용할 수도 있다.
Oracle Database 11g부터 시작해, Physical Standby DB가 Logical Standby DB가 제공하는 Rolling Upgrade DB을 활용할 수 있다. 새로운 SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY 구문에 대한 KEEP IDENTITY 절 옵션을 사용해 Physical Standby DB를 Rolling Upgrade 위해 일시적으로 Logical Standby DB로 전환한 후 업그레이드 완료 후 다시 Primary Database와 Physical Standby DB의 원래 구성으로 돌릴 수 있다.

4.9 Cascaded Destinations

Data Guard는 다양한 유연한 구성 옵션을 제공한다. Cascaded Destinations을 사용해 Physical Standby DB를 Standby DB에서 받은 redo를 다른 Standby DB로 전송할 수 있다. Standby DB가 redo 데이터를 첫 번째 Standby DB에 전송하기 때문에 이 기능을 사용해 기본 시스템 상에서 로드를 줄이고, 여러 개의 스탠바이 데이터베이스가 필요한 경우에 기본 사이트에서 네트워크 트래픽과 네트워크 자원 사용을 줄일 수 있다. Cascaded Destinations을 포함하는 Data Guard 구성에서는 Oracle RAC와 Data Guard Broker가 지원되지 않다.

4.10 Data Guard와 Oracle RAC(Real Application Clusters)

Data Guard와 Oracle RAC는 가장 높은 수준의 확장성, 가용성, 데이터 보호를 제공하는 상호보완적인 기술이다. Cascaded Destinations 사용에 적용되는 제약을 제외하고 (위에서 설명) Oracle RAC와 Data Guard 사이의 통합은 원활하게 이루어진다. Oracle RAC와 단일 노드 데이터베이스를 결합해 Data Guard 구성 참여하고 역할을 맡을 수 있다. Oracle RAC는 업계 유일의 작업부하 관리와 확장성 기능을 제공하는 동시에 서버 장애에 대비해 보호하는 이상적인 HA 솔루션을 제공한다. Data Guard는 완전한 스토리지 어레이 장애, 운영자 실수, Oracle RAC 노드에 걸쳐 롤링 방식으로 실시될 수 없는 예상된 유지, 사이트 장애를 가져오는 여러 개의 연관된 장애로 인한 다운타임을 최소화하는 완전한 중복성 (redundancy)을 갖추고 데이터 가용성과 보호의 수순을 다시 한 차원 높인다.

4.11 최대 가용성 아키텍쳐

Oracle Maximum Availability Architecture (MAA) 9는 오라클이 테스트하고 고객 사용을 통해 검증된 오라클 가용성 기술 구축을 위한 베스트 프랙티스를 보여주는 청사진이다. MAA의 목적은 최적의 가용성 아키텍처를 설계하는데 있어서 복잡성을 해결하는데 있다.
MAA 베스트 프랙티스에는 Oracle RAC를 사용한 구성, redo 전송 최적화, 스위치오버/페일오버 작동, 클라이언트 페일오버, Redo 적용성능, SQL 적용 구성, 튜닝 등과 같은 다양한 Data Guard 구성 측면에 대한 권장사항을 포함하고 있다.

19. DATA GUARD 11G (by joanney) [2011.11.10]