Oracle Database 11g Release 2 기반의 Oracle Data Guard 기술 백서 - Oracle Database 11g Release 2 기반의 Oracle Data Guard 4 "현재 Direct SAN-to-SAN replication 대신 Oracle

오라클 기술 백서

2009년 9월

Oracle Database 11g Release 2

기반의 Oracle Data Guard

Oracle 기술 백서 - Oracle Database 11g Release 2 기반의 Oracle Data Guard

들어가는 글.......................................................................................... 1

Oracle Data Guard 11g - 개요 ................................................................. 2

Data Guard 운영 방법 – 기술 세부 사항...................................................... 4

Data Guard Transport Services ............................................................. 4

보호 모드......................................................................................... 5

Data Guard Apply Services .................................................................. 6

Automatic Gap Resolution................................................................... 8

Oracle Data Validation........................................................................ 9

Data Guard 구성 관리 ........................................................................ 9

Role Management Services ................................................................10

계획된 유지 보수 처리........................................................................12

Data Guard와 원격 미러링의 비교.............................................................13

Data Guard와 Exadata ..........................................................................14

Data Guard 및 Oracle Real Application Clusters ..........................................14

Maximum Availability Architecture.............................................................14

Data Guard 고객 ..................................................................................15

결론 ..................................................................................................15

부록: Data Guard 11g의 새로운 기능 요약 ..................................................16


1

들어가는 글

효율적인 비즈니스 운영, 우수한 고객 서비스, 정부 규제 준수 그리고 기업 정보 자산의 보호를

위해서는 무엇보다도 최고 수준의 데이터 보호와 가용성이 필수적입니다. 따라서, 모든 규모 및

업종의 기업들이 데이터 보호와 데이터 가용성을 최우선 순위로 고려하는 것은 당연하다고 할

수 있습니다.

테이프의 백업과 복구, 스토리지 원격 미러링 또는 데이터베이스 로그 전송(log shipping) 등은

전통적인 데이터 보호 및 DR(Disaster Recovery) 솔루션입니다. 불행히도 이들 솔루션으로는

공격적인 RPO(Recovery Point – 데이터 보호) 및 RTO(Recovery Time – 데이터 가용성)

목표를 수립할 수 없습니다. 이들 솔루션은 또한 높은 구입 비용과 운영 시스템의 역할이

요청될 때까지 운휴 상태로 남아 있는 스탠바이 시스템의 낮은 활용도로 인해 적절한 수준의

ROI를 달성하는 데 실패하고 있습니다.

이와 달리, Oracle Data Guard 11g Release 2는 이와 같은 솔루션에 대한 사용자들의 기대치를

새롭게 정의합니다. Data Guard는 Oracle Database Enterprise Edition에 포함되어 있으며 관리,

모니터링 및 자동화 소프트웨어를 제공하여 데이터 장애, 재난, 오류 및 훼손을 방지하는 1개

이상의 동기화된 스탠바이 데이터베이스를 생성 및 유지합니다. 이는 고가용성과 재해 복구

요구 사항을 모두 해결할 수 있으며 Oracle Real Application Clusters(Oracle RAC)를 보완하는

데 이상적입니다.

Data Guard는 Oracle 데이터베이스에 대한 필수 정보를 보유하고 있어 Oracle 데이터에 대한

최고 수준의 보호를 제공하며, 매우 간단히 구현 및 관리할 수 있습니다. 운영자는 항상

스탠바이 데이터베이스가 운영 데이터베이스의 역할을 수행할 수 있으며, 자동 전환 시

비즈니스 위험이 발생하지 않는다는 것을 확신할 수 있습니다. 마지막으로, 모든 기업들이

지출을 줄여야 하는 오늘날과 같은 경제 환경에서는 Data Guard 스탠바이 데이터베이스를 쿼리,

백업, 테스팅 또는 롤링 데이터베이스 업그레이드 및 기타 유지 보수에 활용하면, 높은 ROI를

달성하는 것은 물론, 재난 보호 환경을 구현할 수 있습니다.


2

"Active Data Guard 11g는 빠른 성과를 거두고 있습니다! 우리는 공개 전자상거래 애플리케이션에서 10 TB의 스탠바이

데이터베이스를 재난 보호와 안전한 읽기 전용 접근 등 두 가지 목적으로 손쉽게 사용할 수 있었습니다. 또한 많은 노력을 기울여

다른 대안들을 평가한 결과, 기존의 Data Guard 스탠바이 데이터베이스를 활용하는 방법이야말로 고객이 실시간 정보를 지속적으로

접근할 수 있도록 지원할 수 있는 지름길이라는 사실을 알게 되었습니다."

Sue Merrigan, Intermap Technologies

Oracle Data Guard 11g - 개요

Data Guard는 관리, 모니터링, 자동화 소프트웨어 인프라를 제공하여 하나 이상의 스탠바이

데이터베이스를 작성, 유지보수, 모니터링함으로써 장애, 고장, 오류, 데이터 훼손으로부터

기업의 데이터를 보호합니다. 스탠바이 데이터베이스는 2가지 유형으로 제공됩니다. 물리적

스탠바이 데이터베이스는 Redo Apply를 사용하여 블록 기반으로 운영 데이터베이스와 동일한

복사본을 유지합니다. 논리적 스탠바이는 SQL Apply를 사용하며 물리적 구성과 데이터 구조에

차이가 있을 수 있지만 운영 데이터베이스와 동일한 논리적 정보를 가지고 있습니다.

운영자는 기본 데이터베이스가 장애가 발생한 경우, 미션 크리티컬 애플리케이션의 고가용성을

유지하기 위해 수동 또는 자동 모드로 스탠바이 시스템을 운영 시스템으로 전환할 수 있습니다.

Data Guard 아키텍처는 그림 1에서 보여주고 있습니다.

Data Guard는 그림 2에서 볼 수 있듯이 통합 Oracle 데이터베이스 고가용성(HA) 기능 중

하나로서 계획에 따른 다운타임은 물론, 예기치 못한 다운타임의 영향을 최소화하여 비즈니스

영속성을 보장합니다.


3

Data Guard 스탠바이 데이터베이스는 특별 쿼리, 리포팅, 백업 또는 테스트 활동을 지원하는

것은 물론, 재난 보호를 제공하여 높은 ROI를 실현합니다. 특히:

Active Data Guard 옵션은 Oracle Database 11g에서 처음으로 지원되는 기능으로서

물리적 스탠바이 데이터베이스가 읽기 전용 애플리케이션으로 사용될 수 있도록 하는

동시에 운영 데이터베이스에서 업데이트를 수신합니다. 액티브 스탠바이

데이터베이스상에서 실행된 쿼리는 업데이트된 결과를 수신합니다.

Snapshot Standby는 운영 데이터의 읽기-쓰기 복제가 필요한 테스트 등의 모든

활동을 위해 물리적 스탠바이 데이터베이스를 읽기-쓰기 모드로 열 수 있습니다.

Snapshot Standby는 주 데이터베이스가 생성한 redo를 계속해 수신하기는 하지만

적용하지는 않습니다. Snapshot Standby가 물리적 스탠바이 데이터베이스로 다시

변환될 때 이들 업데이트가 적용됩니다. 운영 데이터는 항시 보호됩니다.

논리적 스탠바이 데이터베이스는 읽기-쓰기 모드로 열 수 있는 등 한층 유연성이

향상되었습니다. SQL Apply에 의해 유지되고 있는 데이터는 수정할 수 없지만

데이터베이스에 추가 로컬 테이블을 추가할 수 있으며 로컬 색인 구조를 만들어

리포팅을 최적화하거나 스탠바이 데이터베이스를 데이터웨어하우스로 이용하거나

데이터 마트를 로드하는 데 사용된 정보를 변환할 수 있습니다.

스탠바이 데이터베이스를 사용해 롤링 방식으로 계획된 유지 보수 작업을 수행할 수

있습니다. 유지 보수는 스탠바이 데이터베이스에서 먼저 수행됩니다. 이 유지 보수

작업이 완료되면 스탠바이 데이터베이스가 운영 데이터베이스로 변경됩니다.

switchover 운영에 대한 영향이 불가피한 경우에만 다운타임이 발생합니다. 이는

하드웨어 또는 OS 유지 보수나 사이트 유지 보수를 수행할 때, 새로운 데이터베이스

패치 세트나 전체 데이터베이스 릴리즈를 업그레이드를 할 때, 기타 중요한

데이터베이스 변경을 실행할 때 가용성은 높이는 한편, 위험을 줄일 수 있습니다.


4

"현재 Direct SAN-to-SAN replication 대신 Oracle Data Guard를 사용하고 있습니다. 그 이유는 통신 비용을 낮추고 네트워크

하드웨어의 로드도 줄일 수 있기 때문입니다."

Craig Gibbons, NRMA Motoring & Services

운영 데이터베이스의 동일한 사본이기 때문에 물리적 스탠바이 데이터베이스는 운영

데이터베이스의 백업 오버헤드를 분산시키는 데 사용될 수 있습니다.

Data Guard 운영 방법 – 기술 세부 사항

Data Guard 구성은 기본 데이터베이스라고도 하는 운영 데이터베이스와 최대 9개의 스탠바이

데이터베이스를 포함합니다. 운영 및 스탠바이 데이터베이스는 Oracle Net Services를 이용하여

TCP/IP으로 연결됩니다. 서로 통신할 수 있다면, 데이터베이스가 위치한 장소에 대한 제약이

없습니다. 스탠바이 데이터베이스는 1차적으로 운영 데이터베이스의 백업 사본에서

만들어집니다. Data Guard는 운영 데이터베이스 redo - 트랜잭션을 복구하기 위해 Oracle에서

사용하는 정보 - 를 전송하고 이를 스탠바이 데이터베이스에 적용하여 자동으로 운영

데이터베이스와 모든 스탠바이 데이터베이스를 동기화합니다.

Data Guard Transport Services

사용자가 운영 데이터베이스에서 트랜잭션을 커밋하면, Oracle은 redo 레코드를 생성하고 이를

로컬 온라인 로그 파일에 기록합니다. Data Guard 트랜잭션 서비스는 redo를 스탠바이

데이터베이스로 동기식 또는 비동기식으로 전송하며 이는 스탠바이 redo 로그 파일에

기록됩니다(그림 3의 1단계). Oracle Advanced Compression 옵션을 사용하여 redo 파일을

압축된 포맷으로 전송할 수 있습니다.

Synchronous Redo transport (SYNC)는 운영 데이터베이스가 애플리케이션으로 커밋

성공에 대한 확인 응답을 전송할 때까지 redo가 디스크에 기록된 스탠바이 데이터베이스의

확인을 대기하도록 하기 때문에 제로 데이터 손실 보호를 실현할 수 있습니다. 운영

데이터베이스 성능은 스탠바이 redo 로그 파일 I/O을 완료하는 데 필요한 총 시간과 네트워크

라운드 트립 시간에 의해 영향을 받습니다.

Data Guard 11g Release 2은 동기식 전송이 운영 데이터베이스의 성능에 미치는 영향을 줄일

수 있도록 설계되었습니다. Redo는 이제 운영 데이터베이스의 로컬 온라인 로그 파일 I/O와

병렬로 원격 스탠바이 데이터베이스로 전송되어 스탠바이 I/O가 총 라운드 트립 시간에 미치는

영향을 효과적으로 제거할 수 있습니다. 이를 통해 동기식 제로 데이터 손실 구성의 기본

데이터베이스와 스탠바이 데이터베이스 간의 거리를 더욱 확대할 수 있습니다. 낮은 대기시간의

네트워크에서는 기본 데이터베이스의 SYNC 복제에 따른 영향을 거의 제로로 줄일 수 있기

때문에 구성 요소 및 데이터베이스 장애 발생시(예를 들어. SAN 장애) 제로 데이터 손실 HA


5

보호를 위해 로컬 SYNC 스탠바이를 이용하여 원격 ASYNC 스탠바이를 보완하는 데

효과적입니다.

Asynchronous redo transport (ASYNC)는 스탠바이 데이터베이스가 redo를 수신했다는

확인 응답을 보낼 때까지 대기하지 않고 운영 데이터베이스가 애플리케이션에 커밋이

성공했다는 확인 응답을 보내도록 함으로써 운영 데이터베이스의 성능에 미치는 영향을 방지할

수 있습니다. Data Guard 11g의 개선 기능을 통해 온라인 로그 파일에서 가져오는 것이 아니라

운영 로그 버퍼에서 직접 전달하는 것은 물론, 높은 대기시간을 발생시키는 WAN(Wide Area

Network)상의 네트워크 쓰루풋을 향상시킴으로써 기본 데이터베이스의 성능에 대한 모든

영향이 완벽하게 제거됩니다. 그러나, ASYNC를 통한 성능 향상은 모든 redo가 스탠바이

데이터베이스에 의해 수신된다는 것을 보장하지 않기 때문에 약간의 데이터 손실이 발생할

가능성이 수반됩니다.

보호 모드

Data Guard는 비용, 가용성, 성능 및 데이터 보호의 균형을 맞추기 위해 3 가지 데이터 보호

모드를 제공합니다. 각 모드는 특정 redo 전송 모드를 사용하며 기본 데이터베이스가 스탠바이

데이터베이스와의 연결이 끊어지는 경우 Data Guard 구성의 실행을 제어하는 규칙을 지정하고

있습니다. 아래 표는 각 모드의 특성을 간략하게 설명하고 있습니다.


6

DATA GUARD 보호 모드

모드 데이터 손실 위험 전송 스탠바이 데이터베이스가 확인 응답을 보내지 않는 경우:

Maximum Protection 제로 데이터 손실, 이중

장애 방지 장치

SYNC 스탠바이 데이터베이스로부터 확인 응답을 수신할 때까지

데이터베이스 대기

Maximum Availability 제로 데이터 손실 단일

장애 방지 장치

SYNC 확인 응답을 수신하거나 NET_TIMEOUT 임계 기간(threshold

period) 만료 시까지 운영 데이터베이스 대기 - 이후 처리

재개

Maximum Performance 최소한의 데이터 손실이

발생할 가능성이 있음

ASYNC 운영 데이터베이스는 결코 스탠바이 데이터베이스의 확인

응답을 대기하지 않음

Data Guard Apply Services

Apply Services는 스탠바이 redo 로그 파일에서 redo를 읽은 다음, Redo Apply (물리적

스탠바이) 또는 SQL Apply (논리적 스탠바이)를 이용해 이를 스탠바이 데이터베이스에

적용합니다(그림 3의 2단계). 서비스 전송과 적용은 완전히 독립적으로 이루어진다는 점을

유념해야 합니다. 스탠바이 적용 상태 또는 성능은 redo 전송 또는 운영 데이터베이스 성능에

그 어떤 영향도 미치지 않습니다. 이와 같은 분리는 매우 중요합니다. redo 전송은 복구 시점의

결정에 가장 큰 영향을 미치며 데이터 손실이 발생할 가능성이 있습니다. 전송에 부정적인

영향을 미치는 모든 요인들은 데이터 손실이 발생할 가능성을 높이게 될 것입니다. 동기식

구성에서도 redo 전송은 운영 데이터베이스 응답 시간과 쓰루풋을 결정짓는 중요한 요인입니다.

동기식 구성에서 전송에 부정적인 영향을 미치는 모든 요인들은 운영 데이터베이스의 쓰루풋을

저하시키고 응답 시간을 증가시킬 것입니다. 전송 및 적용 간의 분리는 데이터베이스 성능, 응답

시간 및 데이터 보호를 최적화하는 데 목표를 두고 있습니다.

Redo Apply - 물리적 스탠바이 데이터베이스

물리적 스탠바이 데이터베이스는 모든 Oracle 데이터베이스 사용되는 표준 Oracle media

recovery의 Data Guard 인식 확장 프로세스인 Managed Recovery Process(MRP)를

이용하여 기본 데이터베이스에서 수신한 redo를 적용합니다. 블록 기반으로 운영

데이터베이스와 물리적으로 동일하므로 색인을 포함한 데이터베이스 스키마도 동일합니다. MRP

프로세스는 최대 성능을 위해 고도의 병렬 처리 기능을 지원합니다. 오라클이 수행한 Data

Guard 11g 성능 테스트에서 OLTP형 워크로드에 대해 50MB/sec 이상 그리고, direct path

로드에 대해 100MB/sec 이상의 복구 속도를 달성했습니다(본 백서 후반 부의 Exadata

스토리지 성능 데이터 참조). Redo Apply는 운영 데이터베이스의 동기화된 사본을 유지하는

가장 단순하고, 가장 빠르며, 가장 안정적인 방법입니다.


7

"Active Data Guard를 통해 Morpho Track은 대형 미션 크리티컬 시스템에서 최고 10만 달러의 비용을 절감하게 될 것입니다."

이는 디스크 미러링이나 복사 방식보다 훨씬 간단합니다. Active Data Guard 11g Release 2의 새로운 기능은 보고 정확성에 대한

SLA(Service Level Agreements)를 충족할 수 있도록 보장합니다."

Aris Prassinos, MorphoTrak

Redo Apply 및 Active Data Guard

Active Data Guard 옵션에는 Redo Apply의 기능과 물리적 스탠바이 데이터베이스의 기능을

확장하는 다음과 같은 많은 기능들을 포함하고 있습니다.

Real-time Query는 쿼리, 정렬, 보고, 웹 기반 액세스를 위해 하나 이상의 물리적

스탠바이 데이터베이스에 대한 읽기 적용 액세스를 수행할 수 있도록 합니다. 읽기

전용 워크로드가 읽기-쓰기 트랜잭션에서 분리될 수 있는 경우, Active Data Guard는

과거 스탠바이 역할을 수행하면서 운휴 상태에 있던 기존 물리적 스탠바이

데이터베이스를 활용하여 운영 용량을 배가시킬 수 있습니다(추가 액티브 스탠바이

데이터베이스를 구성에 추가함으로써 쓰기-읽기 트랜잭션에 영향을 미치지 않으면서

읽기-전용 용량을 확대할 수 있습니다). Active Data Guard는 탁월한 성능을

제공합니다. 이는 여타 리플리케이션 방식으로는 소스 데이터베이스에서 생성하는

트랜잭션 볼륨을 따라잡을 수 없는 높은 쓰루풋의 애플리케이션이 이용될 수 있습니다.

Active Data Guard Service Level Agreements(SLA)는 세션 매개변수

STANDBY_MAX_DATA_DELAY를 이용하여 구현될 수 있습니다. 이 매개변수 값은

변경이 기본 데이터베이스에서 커밋된 후 액티브 스탠바이 데이터베이스상에서 쿼리될

수 있는 데까지 허용되는 시간 한도(초 단위)를 기술한 것입니다 (Data Guard 11g

Release 2에서 새롭게 선 보이 기능). 액티브 스탠바이는 시간이 초과하면 ORA-3172

오류 코드를 반환합니다. 애플리케이션은 연결 중단과 유사한 이러한 오류에 대응하고

다른 액티브 스탠바이 데이터베이스 또는 기본 데이터베이스로 쿼리를 재전송해

요구되는 SLA을 달성할 수 있습니다.

Active Data Guard 11g Release 2는 훼손된 블록의 자동 복구를 실행합니다. 블록

레벨 데이터 손실은 일반적으로 가끔 발생하는 임의 I/O 오류는 물론, 디스크에

기록되는 메모리 변조 오류로 인해 발생합니다. Oracle이 메모리 변조를 발견하면,

블록에 미디어가 훼손되었음을 표시하고 디스크에 이를 기록하며 일반적으로

애플리케이션에 ORA-1578 오류를 반환합니다. 사람이 개입하여 블록이 복구될 때까지

이후 그 어떤 모든 블록 읽기 작업도 성공하지 못할 것입니다. 그러나, Active Data

Guard 스탠바이 데이터베이스를 보유하고 있는 기본 데이터베이스에서 훼손이

발생하면, 스탠바이 데이터베이스에서 가져온 블록의 정상 사본을 이용하여

애플리케이션에 투명하게 자동으로 블록 미디어 복구가 수행됩니다. 반대로, 스탠바이

데이터베이스상의 불량 블록은 운영 데이터베이스의 정상 버전을 이용하여 자동으로

복구됩니다.


8

"Data Guard Logical Standby는 사용자를 위한 용량과 확장성을 다이내믹하게 확장하는 장기적인 전략적 하드웨어와 소프트웨어

플랫폼의 중요한 구성 요소입니다. 전체 솔루션을 구현한 이후 대부분의 배치 처리 작업에서 50-95%의 성능 향상을 달성했습니다."

David Sink, e-Rewards Market Research

SQL Apply - 논리적 스탠바이 데이터베이스

물리적 조직과 데이터 구조는 다를 수 있지만 논리적 스탠바이 데이터베이스에는 운영

데이터베이스와 같은 논리적 정보가 포함되어 있습니다. SQL Apply는 기본 데이터베이스에서

수신한 rero를 SQL 문으로 전송하여 논리적 스탠바이 데이터베이스의 동기화를 유지하고

읽기-쓰기 모드로 열린 스탠바이 데이터베이스상에서 SQL 문을 실행합니다. SQL Apply는

데이터타입, 테이블 유형, DDL 및 DML 처리 유형 등에서 약간의 제약을 가지고

있습니다(지원되지 않는 데이터타입 및 스토리지 속성에 대한 문서 참조).

그 전제 조건을 충족하고 다음을 필요로 한다면, SQL Apply를 사용합니다.

스탠바이 데이터베이스에 대한 읽기-쓰기 액세스를 필요로 하는 포팅 애플리케이션을

실행하기를 원하는 경우. 단, SQL Apply에 의해 유지되는 데이터는 수정될 수 없음

운영 데이터베이스상에 없는 테이블, 추가 스키마, 인덱스 및 materialized를 스탠바이

데이터베이스에 추가하기를 원하는 경우

현재 Oracle Database 10g release상에 있는 데이터베이스에서 데이터베이스 롤링

업그레이드를 실행하거나 롤링 방식으로 여타 데이터베이스 유지 보수를 실행하여

위험 및 다운타임을 단축하려는 경우. 데이터베이스의 버전이 Oracle Database 11g

이상이면, 물리적 스탠바이 및 임시 논리적 스탠바이 롤링 업그레이드 프로세스를

이용하는 방안을 생각할 수 있습니다. 보다 자세한 정보는 계획된 유지 보수 처리

섹션 참조

Automatic Gap Resolution

운영 및 스탠바이 데이터베이스와의 연결이 끊어지는 경우(네트워크 장애 또는 스탠바이 서버

장애), 그리고 적용된 보호 모드에 따라, 운영 데이터베이스가 계속해서 트랜잭션을 처리하고

새로운 네트워크 연결이 이루어질 때까지 스탠바이로 전송되지 못한 redo 백로그를 쌓아

둡니다. 이러한 상태에서, Data Guard는 스탠바이 데이터베이스의 상태를 지속적으로

모니터링하고, 연결이 재개되면 이를 참지하고 자동으로 스탠바이 데이터베이스와 운영

데이터베이스를 재동기화합니다(그림 3의 4단계). 스탠바이 데이터베이스를 재동기화하는 데

필요한 아카이브 로그가 운영 데이터베이스의 디스크상에 있다면, 운영자가 개입할 필요가 전혀

없습니다. 장애가 장기화되어 필수 아카이브 로그를 유지하는 것이 실용적이지 않은 경우,

물리적 스탠바이는 운영 데이터베이스의 RMAN 고속 증분 백업을 이용하여 재동기화될 수

있습니다.


9

Oracle Data Validation

Data Guard의 중요한 장점 중 하나는 스탠바이 데이터베이스에 적용하기 전에 Oracle

프로세스를 사용하여 redo 데이터를 검증하는 기능입니다. Data Guard는 스탠바이

데이터베이스가 redo 블록을 적용하여 동기화 상태를 유지하는 느슨하게 결합된 아키텍처이며

운영 데이터베이스에서 발생할 수 있는 가능한 데이터 파일 훼손으로부터 완전히 격리됩니다.

Redo는 또한 메모리에서 직접 전송되며(System Global Area) 따라서 운영 데이터베이스의

I/O 훼손에서 완벽하게 격리됩니다. redo 전송 및 적용이 이루어지는 동안, 많은 주요

인터베이스에서 훼손 탐지 확인이 이루어집니다. 스탠바이 데이터베이스에서 실행된 소프트웨어

코드 경로는 운영 데이터베이스의 경로와 기본적으로 다르며 운영 데이터베이스에 영향을 미칠

수 있는 펌웨어 및 소프트웨어 오류로부터 스탠바이 데이터베이스를 효과적으로 차단합니다.

물리적 스탠바이는 또한 Oracle Database 11g Release 1에서 지원되는 매개변수:

DB_LOST_WRITE_PROTECT를 이용합니다. 실제로 쓰기 작업이 장기 보존 스토리지에서

발생하지 않은 상황에서 I/O 서브시스템이 쓰기 작업 완료에 대한 확인 응답을 보내면, 쓰기

작업이 손실되는 상황이 발생합니다. 이후 블록 읽기에서 I/O 서브시스템이 다른 데이터베이스

블록을 업데이트하는 데 사용할 수 있는 데이터 블록의 이전 버전을 반환하면, 훼손이 발생하게

됩니다. DB_LOST_WRITE_PROTECT 초기화 매개변수가 설정되면, 데이터베이스는 reod 로그

파일의 버퍼 캐시 블록 읽기를 기록하고 이 정보는 Redo Apply에 의해 사용되어 유실된 쓰기가

있는지 여부를 파악함으로써 다운타임과 데이터 손실을 방지합니다.

Data Guard 구성 관리

운영 및 스탠바이 데이터베이스, 그리고 그 다양한 양방향 기능들은 SQL*Plus를 이용하여

관리될 수 있습니다. 또한 Data Guard는 Guard Broker라는 분산 관리 프레임워크를 제공하여

Data Guard 구성 생성, 유지 보수 및 모니터링을 중앙 집중화하고 자동화합니다. 관리자는

Enterprise Manager Grid Control 또는 Broker의 명령행 인터페이스(DGMGRL)를 사용하여

Broker와 상호 작용하게 됩니다.

Enterprise Manager Grid Control은 Data Guard 구성 개발 작업을 한층 단순화할 수 있는

마법사를 포함하고 있습니다. apply lag, transport lag, redo 속도 및 구성 상태 등과 같은 주요

Data Guard 측정 지표는 새로운 통합 HA Console에 포함되어 있습니다(그림 4 참조).

Enterprise Manager를 사용하면 메트릭스 성능이 지난 24시간 또는 지난 5일 동안 어땠는지

등 모니터링하는 Data Guard 메트릭스에 대한 과거 추세 분석을 수행할 수 있습니다. 또한

Enterprise Manager를 통해 메트릭스가 구성된 임계값을 통과하는 경우 관리자에게 통보할 수

있도록 통보-경보를 설정할 수 있습니다.


10

"Fast-Start Failover는 PPL이 하루 24시간, 특히 비상시에 중요한 고객 서비스를 제공하기 위해 이용하는 장애 관리(outage

management) 시스템에 단순하면서 신속한 자동 페일오버 기능을 제공합니다. Oracle9i부터 재해 복구(DR)에 Data Guard를

사용했지만 Fast-Start Failover는 고가용성과 DR 간의 경계선을 모호하게 만들어 단일 솔루션으로 2가지 요구 사항을 모두 해결할

수 있도록 했습니다."

Chris Carter, PPL Services Corporation

Role Management Services

Data Guard Role Management Services는 지정된 스탠바이 데이터베이스를 운영

데이터베이스의 역할로 신속하게 전환할 수 있도록 합니다. switchover는 OS 또는 하드웨어

업그레이드, Oracle 데이터베이스의 롤링 업그레이드 기타 데이터베이스 유지 보수 등을 비롯해

정기적인 유지보수가 진행되는 동안 다운타임을 줄이는 데 사용되는 계획된 운영입니다. 사용된

전송 서비스(SYNC or ASYNC) 또는 보호 모드에 관계 없이 switchover는 항상 제로 데이터

손실을 보장합니다.

자동 전환은 예기치 못한 운영 데이터베이스의 장애가 발생했을 때 스탠바이 데이터베이스를

새로운 운영 데이터베이스로서 온라인에 연결합니다. 자동 전환 작업은 스탠바이

데이터베이스가 운영 데이터베이스 역할을 맡기 위해 재시동할 필요가 없도록 합니다. 또한

원본 운영 데이터베이스의 데이터베이스 파일이 그대로이고 데이터베이스를 다시 시작할 수

있는 경우 Flashback Database를 사용하여 원본 운영 데이터베이스를 새로운 운영

데이터베이스에 대한 스탠바이 데이터베이스로 복귀시키고 다시 동기화할 수 있습니다.


11

switchover는 Oracle Enterprise Manager GUI 인터페이스, Data Guard Broker의 명령행

인터페이스 또는 직접 SQL을 사용하여 관리자가 시작합니다. Data Guard 옵션을 이용하면

Fast-Start Failover를 이용하여 매우 철저한 제어 하에 자동 전환을 실행할 수 있습니다.

Fast-Start Failover

Fast-Start Failover를 이용해 Data Guard에서 페일오버를 호출하는 수동 단계를 수행할 필요

없이 이전에 선택한 스탠바이 데이터베이스로 자동 전환할 수 있습니다. Data Guard Observer

프로세스는 Fast-Start Failover 구성 상태를 지속적으로 모니터링합니다. Observer와

스탠바이 데이터베이스가 모두 운영 데이터베이스와 연결이 끊어지는 경우 Observer는 Fast-

Start Failover를 시작하기 전에 구성 가능한 시간 동안 운영 데이터베이스에 다시 연결을

시도합니다. Fast-start failover는 3개 Fast-Start Failover 요소 – 운영, 스탠바이 및

Observer – 중 최소한 2개 요소를 주요 상태 전환과 일치시켜 split-brain 시나리오가

발생하는 것을 방지할 수 있도록 보장하는 데 그 목적을 두고 있습니다. 일단 장애가 발생한

운영 데이터베이스가 수정되고 설치되면 실행 전에 Observer 프로세스와 연결해야 합니다. 이

경우, 자동 전환이 이미 발생했으며 원래의 운영 데이터베이스는 새로운 운영 데이터베이스로서

자동으로 스탠바이 데이터베이스를 대체하게 된다는 사실을 통지 받게 됩니다. Fast-Start

Failover의 단순하면서도 정교한 아키텍처는 고가용성 및 데이터 보호 모두를 필요로 하는

환경에 가장 이상적입니다.

Automating Client Failover

신속하게 데이터베이스 자동 전환을 실행하는 기능은 고가용성을 위한 첫번째 요구 사항에

불과합니다. 애플리케이션은 장애가 발생한 운영 데이터베이스와의 연결을 신속하게 드롭시키고

새로운 운영 데이터베이스와 신속하게 다시 연결해야 합니다.

Data Guard 컨텍스트의 효과적인 클라이언트 자동 전환은 다음과 같은 3개 구성 요소로

이루어져 있습니다.

고속 데이터베이스 자동 전환

새 운영 데이터베이스상의 고속 데이터베이스 서비스 개시

고속 클라이언트 통지 및 새 운영 데이터베이스에 대한 고속 재연결

이전 Oracle 릴리스에서는 구성에 따라 클라이언트 자동 전환을 위해 1개 이상의 사용자가

작성한 데이터베이스 트리거가 필요했습니다. Data Guard 11g Release 2는 사용자가 작성한

트리거를 사용할 필요 없이 클라이언트 자동 전환을 실행할 수 있도록 함으로써 구성을 대폭

단순화했습니다. Data Guard 브로커를 통해 관리되는 역할 전환으로 데이터베이스를 자동

전환하고 새 운영 데이터베이스에서 적절한 서비스를 시작하며 장애가 발생한 데이터베이스와

클라이언트의 연결을 종료하고 이를 새 데이터베이스로 재연결할 수 있으며 그 어떤 사람의

개입도 필요로 하지 않습니다.


12

"임시 논리적 스탠바이 작업을 이용하여 데이터베이스 롤링 업그레이드를 시범적으로 수행했습니다. 새로운 Oracle 릴리스로 이전할

때 발생하는 애플리케이션 다운타임은 단 4분으로 단축했습니다. Data Guar 롤링 업그레이드로 여유 있게 SLA을 달성할 수 있게

되었습니다."

Kenny Snell, United Parcel Service

계획된 유지 보수 처리

Data Guard 스탠바이 데이터베이스는 많은 유형의 계획된 유지 보수 작업에 따른 다운타임과

위험을 줄이는 데 사용될 수 있습니다. 일반적인 접근 방식은 스탠바이 데이터베이스에 대한

변경을 적용하고 테스트한 다음, switchover를 수행하는 것입니다. Oracle 버전 간의 차이가

없는 유지 보수 작업이나 데이터베이스의 논리적 구조에 대한 변경은 Redo Apply를 이용할 수

있습니다. 새로운 Oracle Database 릴리스 또는 패치로 업그레이드하거나 데이터베이스의

논리적 구조를 변경하는 작업은 임시 논리적 스탠바이를 이용하는 물리적 스탠바이

데이터베이스 또는 논리적 스탠바이 데이터베이스 중 하나에서 SQL Apply를 활용해 롤링

방식으로 수행될 수 있습니다.

이와 같은 유지 보수로 인해 발생하는 유일한 다운타임은 스위치오버를 완료하는 데 소요되는

시간입니다. Redo Apply를 이용한 switchover는 60초 미만의 시간 내에 완료될 수 있습니다.

보다 자세한 정보는 MAA 베스트 프랙티스 백서 Data Guard Switchover and Failover Best

Practices를 참조하십시오. SQL Apply를 이용한 switchover는 논리적 스탠바이가 이미 읽기-

쓰기를 위해 열려진 상태에서 훨씬 빠르게 실행됩니다. SQL Apply는 스탠바이 데이터베이스의

역할을 수행하는 동안 기본 데이터베이스에서 복제된 데이터에 그 어떤 변경도 이루어지지

않도록 방지하는 "GUARD" 설정을 가지고 있습니다. SQL Apply switchover는 GUARD 설정을

간단히 변경하여 공식적으로 스탠바이 데이터베이스를 기본 데이터베이스로 전환합니다. 각

환경마다 소요되는 시간은 다르지만, SQL Apply를 이용한 데이터베이스 switchover는 10

이내에 완료될 수 있습니다. 보다 자세한 정보는 Oracle Japan GRID Center Performance

Validation: Data Guard SQL Apply on IBM Power Systems를 확인해 보십시오.

Data Guard 스탠바이 데이터베이스를 이용하여 수행할 수 있는 계획된 다양한 유형의 유지

보수 작업에 대한 자세한 내용은 다음 섹션에 기술되어 있습니다.

시스템 유지보수, 기술 업그레이드, 선택 마이그레이션

Redo Apply의 유연성을 바탕으로 MetaLink Note 413484.1에 정의된 제약 조건에 따라 운영

및 스탠바이 시스템이 서로 다른 CUP 아키텍처 OS(예를 들어, Windows와 Linux), OS

바이너리(32비트/64비트), 및 Oracle 데이터베이스 바이너리(32비터/64비트)를 가지고 있는

구성을 지원함으로써 특정 플랫폼을 마이그레이션하는 데 따른 다운타임과 위험을 최소화할 수

있습니다.

Redo Apply는 또한 Automatic Storage Management(ASM)로, 단일 인스턴스의 Oracle

데이터베이스를 Oracle RAC로, 기술 업그레이드 시 구형 시스템을 신규 시스템으로 또는 한

데이터센터에서 다음 데이터센터로 이전하는 데 사용될 수 있습니다.


13

"우리는 SAN 스토리지를 이용하고 대역폭을 확보하고 있기 때문에 원격 모니터링과 같은 솔루션을 사용할 수 있었지만. 이 중요한

데이터베이스 시스템을 위해 Data Guard를 선택했습니다. 데이터 정합성과 무결성이 무엇보다도 중요한 요구 사항이었습니다."

David Willen, BarnesandNoble.com

데이터베이스 롤링 업그레이드

주요 릴리스 및 패치 (10.1.0.3 이상)를 위한 Oracle 데이터베이스 소프트웨어 업그레이드는

SQL Apply를 이용하여 롤링 방식으로 수행될 수 있으며 거의 제로 데이터베이스 다운타임을

실현합니다. 또는, Data Guard 11g 물리적 스탠바이 데이터베이스는 일시적으로 임시 논리적

스탠바이 데이터베이스로 변환하여 새 데이터베이스를 롤링 방식으로 업그레이드하는 데 사용될

수 있습니다. 임시 논리적 프로세스는 단일 카탈로그 업그레이드만으로 새 Oracle 릴리스로

기본 및 스탠바이 데이터베이스 모두를 이전할 수 있다는 장점을 가지고 있습니다. 업그레이드

프로세스가 완료되면, 구성은 기본 데이터베이스와 함께 물리적 스탠바이 데이터베이스로

이루어진 원래의 상태로 되돌아갑니다.

Data Guard 11g Release 2 SQL Apply는 보다 다양한 데이터 유형을 지원하는 기능이

포함되어 있기 때문에 이전 및 롤링 데이터베이스 업그레이드를 위해 SQL Apply를 이용하면

컬럼 객체의 복제(단순 또는 중첩 사용자 지정 유형), Varrays 및 오라클이 제공하는 Spatial

유형 SDO_GEOMETRY 등을 지원할 수 있습니다.

데이터베이스 유지 보수

Data Guard 11g Release 2 SQL Apply는 Oracle Advanced Compression (OLTP Table

Compression), Oracle Secure Files 및 Online Redefinition에 대한 지원을 추가했습니다.

논리적 스탠바이 데이터베이스는 이제 운영 환경에 그 어떤 위험도 야기하지 않으면서 이들

기능을 구현하거나 여타 유형의 데이터베이스 유지보수를 수행하는 데 이용될 수 있습니다.

Data Guard와 원격 미러링의 비교

현재 많은 데이터베이스 프로세스가 액티브 Oracle 데이터베이스상에서 I/O를 생성하고

있습니다. Database Writer Process가 지속적으로 데이터 파일을 업데이트하는 동안, 온라인

redo 파일의 로컬 아카이브와 컨트롤 파일 업데이트는 추가 I/O를 발생시키고 있습니다. 각

프로세스는 최적의 성능과 복구 기능을 위해 설계되었지만, 호스트 또는 어레이 기반 원격

미러링 솔루션에 문제를 야기할 수 있습니다. 이를 해결할 수 있는 대안이 바로 Data

Guard입니다. 이들 솔루션은 모든 파일에 이루어진 쓰기 작업을 복제해야 하며 원격

리플리카의 실시간 동기화를 유지하기 위해 쓰기 순서대로 작업을 수행하고 있습니다. Data

Guard는 온라인 redo 로그 파일에 이루어진 쓰기 작업만 복제하는 Oracle 인식

프로세스입니다. 내부 테스트를 통해 어레이 기반 원격 미러링은 Data Guard보다 최고 2.7배

많은 볼륨을 전소하고 27배 많은 네트워크 I/O 연산을 수행해야 하는 것으로 나타났습니다.

보다 자세한 정보는 Data Guard Compared to Remote-Mirroring 참조.


14

Oracle High Availability 기능을 활용하고 Oracle Maximum Availability Architecture(MAA) 베스트 프랙티스를 이용하여 이를

구현함으로써 Fidelity Information Services는 최소한의 비용으로 SLA(Service Level Agreement)를 준수할 수 있었습니다."

Charles Kim, Fidelity Information Services

Data Guard는 또한 완벽한 오라클 데이터 검증 기능과 신속하게 운영 데이터베이스의 역할을

넘겨 받을 수 있는 개방형 스탠바이 데이터베이스의 강점을 제공했습니다. 어레이 미러링이

활성 상태에 있는 동안에는 스탠바이 데이터베이스에 Oracle을 설치할 수 없다는 사실을 감안할

때 원격 미러링에서는 이와 같은 기능을 수행하는 것이 불가능합니다.

Data Guard와 Exadata

Data Guard는 Exadata 스토리지에 상주하는 Oracle 데이터베이스의 완벽하게 독립적인 물리적

리플리카를 유지함으로써 데이터베이스 또는 사이트 장애를 방지할 수 있는 업계 유일의

기술입니다. 뿐만 아니라, Data Guard 물리적 스탠바이는 Oracle 데이터베이스의 동기화된 독립

사본을 유지하는 가장 쉽고, 가장 강력한 성능의 솔루션이기 때문에, Oracle Database Machine

기반의 대용량 데이터베이스를 지원할 수 있는 유일한 기술이기도 합니다. Oracle Database

Machine상에서 이루어진 내부 Oracle Database 11g Release 2 테스트에서 Redo Apply는

500MB/sec 이상의 지속 전송률로 스탠바이 데이터베이스에 변경을 적용할 수 있는 것으로

나타났습니다. 보다 자세한 정보는 MAA 홈페이지를 참조해 주십시오.

Data Guard 및 Oracle Real Application Clusters

Data Guard 및 Oracle RAC는 가능한 최고 수준의 확장성, 가용성 및 데이터 보호를 제공하는

보완 기술입니다. Oracle RAC와 단일 노드 데이터베이스의 조합은 Data Guard 구성에서 모든

역할에 참가하고 역할을 맡을 수 있습니다. Oracle RAC는 워크로드 관리 및 확장성을 위한

업계 고유의 기능을 제공하는 것과 동시에 서버 장애로부터 보호하기 위해 이상적인 HA

솔루션을 제공합니다. Data Guard는 완벽한 이중화를 통해 한층 강력한 데이터 가용성과 보호

기능을 제공하여 스토리지 어레이 장애, 운영자의 실수, Oracle RAC 노드 전반에 걸쳐 롤링

방식으로 수행할 수 없는 계획에 따른 유지 보수 또는 데이터베이스(예: SAN 어레이 장애)

또는 사이트 장애(화재, 홍수, 태풍 또는 지진)를 야기할 수 있는 여러 상호 연관된 오류 등으로

인한 다운타임을 최소화합니다.

Maximum Availability Architecture

Oracle Maximum Availability Architecture(MAA)는 Oracle 고가용성 기술을 구축하기 위해

오라클이 완벽하게 테스트하고 고객 사이트에서 검증된 베스트 프랙티스 청사진입니다. MAA의

목표는 최적의 고가용성 아키텍처를 설계하고 운영하는 데 따른 복잡성을 제거하고 고객이 보다

신속하게 그 사용법을 습득할 수 있도록 한다는 것입니다.


15

"항상 테이프 백업 중심의 복구 전략을 견지해왔습니다. 또한, Oracle Data Guard를 "있으면 좋은" 옵션으로 설치했습니다. 당시,

정전으로 인한 간접적인 결과로서 전체 SAN 장애, 그리고 두어 달 이후 다른 SAN상의 주요 디스크 훼손이 발생하는

상황이었습니다. 이러한 상황이 발생했을 때, Data Guard는 손실 없이 데이터를 복구할 수 있도록 했습니다. 이제 Oracle Data

Guard가 단순히 "있으면 좋은" 기술이 아니라, –필수 불가결한 요소라는 사실을 깨닫게 되었습니다!"

Rachel Slade, Oxford Brookes University

MAA 베스트 프랙티스는 Oracle RAC와 함께 구성하기, redo 전송 최적화, switchover/failover

운영, client failover, Redo Apply 성능, SQL Apply 구성 및 튜닝, Exadata 스로티지 및

Oracle Database Machine과 함께 활용 등과 같은 Data Guard의 다양한 측면에 대한 권장

사항을 포함하고 있습니다.

Data Guard 고객

Data Guard 기능은 Oracle 버전 7에서 처음 사용할 수 있었고 새로운 기능을 계속 추가했으며

각 후속 Oracle 릴리즈를 사용하여 보다 성숙한 기술이 되었습니다. 전세계 고객 사이트에서

미션 크리티컬 애플리케이션을 위해 구축됩니다. 많은 상세한 구현 사례 연구가 OTN(Oracle

Technology Network)에서 제공되고 있습니다.

결론

Oracle Data Guard 11g는 탁월한 데이터 보호 기능과 통합된 HA/DR 솔루션을 제공하여

스탠바이 시스템이 스탠바이 데이터베이스의 역할을 수행하는 동시에 운영 및 QA 기능을

지원하도록 함으로써 전통적인 재해 복구의 패러다임을 완전히 변화시키고 있습니다.

Data Guard는 Oracle 데이터베이스를 위한 포괄적인 데이터 보호, 데이터 가용성 및 재난 복구

솔루션입니다. 이는 계획한 중단 및 예기치 못한 중단을 해결하는 유연하고 관리하기 쉬운

프레임워크를 제공합니다. 물리적 및 논리적 스탠바이 데이터베이스는 운영 데이터베이스에서

오버헤드를 분산하는 동시에 중요한 데이터 보호를 실행할 수 있습니다. 다양한 데이터 보호는

여러 가지 수준의 보호, 성능 및 인프라 요구를 수용하는 유연성을 제공합니다. Oracle

Enterprise Manager와 결합된 Data Guard Broker는 사용하기 쉬운 구성과 관리 프레임워크를

제공합니다.

과거 클러스터, 디스크 미러링 및 다양한 백업과 복구 전략을 사용하여 IT 인프라에 어느 정도

고가용성이 구현되었는지에 관계 없이, IT 아키텍처에 Data Guard를 적용함으로써 데이터 보호,

가용성 및 기업 IT 투자에 대한 ROI 등이 전반적으로 향상된 것은 분명한 사실입니다.


16

부록: Data Guard 11g의 새로운 기능 요약

DATA GUARD 11G RELEASE 1

영역 기능

Oracle Active Data

Guard

Apply가 활성 상태일 때 물리적 스탠바이 데이터베이스는 읽기 전용으로 열림 스탠바이 쿼리를 통해 최신

결과를 입수할 수 있음

Active Data Guard 물리적 스탠바이 데이터베이스의 고속 증분 백업을 위해 RMAN 블록 변경 추적

스냅샷 스탠바이 재난 보호 기능을 지속적으로 제공하면서, 임시로 스탠바이 데이터베이스 읽기-쓰기 기능 지원

Oracle Real Application를 위한 최적의 보완 기술

Fast-Start Failover 비동기식 전송 및 Maximum Performance - 원하는 RPO를 달성할 수 있도록 임계치 구성 가능

이전에 지정된 상태 확인 조건 또는 애플리케이션 요청 시 자동 전환 실행

Fast-Start Failover를 위한 Fault-tolerant observer - 대기 호스트상에서 자동으로 오류가 발생한 observer

재시동

Redo Transport 한층 향상된 동기식 redo 전송으로 높은 대기시간의 WAN(Wide Area Networks)상에서 보다 높은 쓰루풋 달성

아카이브 로그 갭 조정 시 Redo transport compression

Apply Performance Redo Apply Performance 향상 - Data Guard 10g의 성능 2배 증대

다양한 SQL Apply 성능 향상으로 스탠바이상에서 병렬로 병렬 DDL 적용 가능

계획된 다운타임 물리적 스탠바이 데이터베이스를 이용한 데이터베이스 롤링 업그레이드(임시 논리적 스탠바이)

한층 향상된 유연성을 통해 운영 /스탠바이 복합 구성을 지원함으로써 원하는 마이그레이션을 용이하게 수행할

수 있도록 함

보호 물리적 스탠바이 데이터베이스

보안 SSL 인증을 암호 파일 대신 사용해 redo 전송을 인증할 수 있음

역할 전환 DBMS_SCHEDULER를 이용한 논리적 스탠바이 데이터베이스상의 역할별 스케줄러 작업

SQL Apply switchover를 위해 먼저 전체 시스템의 전원을 내려야 할 필요는 없지만, Oracle RAC 클러스터

내 운영 또는 스탠바이 데이터베이스 모두의 첫 번째 인스턴스는 종료해야 함

역할 전환에 따라 Enterprise Manager 작업 및 측정 지표 임계치가 새 기본 데이터베이스로 전달됨

Data Guard Broker는 Oracle Clusterware에 의해 제어되는 cold cluster failover와 원활하게 연동됨

SQL Apply 데이터 유형 SQL Apply는 XMLType (CLOB로 저장된 경우), Transparent Data Encryption (TDE), DBMS_FGA (Fine

Grained Auditing), DBMS_RLS (Virtual Private Database) 등을 지원함

관리 용이성 Active Data Guard 스탠바이상의 Standby Statspack for tuning apply performanc

NET_TIMEOUT에 대한 적절한 가치를 평가하는 데 사용되는 redo 전송 응답 시간 막대그래프

DBMS_LOGSTDBY.APPLY_SET를 이용하여 동적으로 설정되는 Data Guard SQL Apply 매개변수

중간 스토리지 없이 RMAN을 이용하여 운영 데이터베이스에서 직업 스탠바이 데이터베이스 생성

Enterprise Manager 마법사를 이용하여 단일 인스턴스 스탠바이 데이터베이스를 Oracle RAC로 변환


17

DATA GUARD 11G RELEASE 2

영역 기능

Oracle Active Data

Guard

액티브 스탠바이에 쿼리 실행 시 최대 데이터 대기시간에 대한 서비스 레벨 목표를 자동으로 적용

액티브 스탠바이를 이용하여 훼손된 블록을 온라인으로 자동 수정

Redo Transport Synchronous Redo Transport의 기능 향상을 통해 운영 데이터베이스의 오버헤드 감소

동기식 및 비동기식 redo 전송을 위한 Redo transport compression

단일 기본 데이터베이스를 위해 최고 30개 스탠바이 데이터베이스 지원(과거에는 9개로 제한됨)

Apply Performance Redo Apply의 기능 향상을 통해 Oracle Database Machine과 Exadata 스토리지가 결합된 구성에서 최고

지속 적용 속도 500MB/sec 달성

계획된 다운타임 Redo 및 SQL Apply 모두에서 Oracle Edition-based Redefinition을 투명하게 지원

Oracle SecureFiles, Warehouse 압축, OLTP 테이블 압축 또는 온라인 redefinition 구현 시 위험 없는

최소한의 다운타임 마이그레이션을 위해 SQL Apply를 이용할 수 있음

보호 Maximum Performance을 이용하는 비동기식 구성의 전송되지 않은 redo들은 자동 전환을 수행하기 전에

스탠바이 데이터베이스로 플러싀(flush)되기 때문에 제로 데이터 손실 실현(오류가 발생한 기본 데이터베이스를

설치 상태로 전환할 수 있다고 가정)

역할 전환 Redo Apply switchover를 위해 그 어떤 스탠바이 인스턴스도 종료할 필요가 없음

Data Guard Broker는 사용자 기반 데이터베이스 서비스를 이용하여 클라이언 자동 전환을 실행함

Data Guard Broker로 관리되는 역할 전환은 Oracle Restart를 이용하여 투명하게 수행됨

SQL Apply 데이터 유형 Oracle SecureFiles, Warehouse compression, OLTP table compression

컬럼 객체의 복제를 위해 SQL Apply에 한층 다양한 데이터 유형 지원 (단순 또는 중첩 사용자 지정 유형),

Varrays 및 오라클이 제공한 Spatial 유형 SDO_GEOMETRY

관리 용이성 SQL Apply 이용시 초대용량 트랜잭션(8백만 개 행 이상)에 대한 성능 향상

논리적 스탠바이 데이터베이스는 Oracle Streams 구성을 위한 소스 데이터베이스가 될 수 있음

트리거는 논리적 스탠바이 데이터베이스상에서 정의되어 기본 데이터베이스에 독립적인 로컬 프로세싱을

수행할 수 있음

Data Guard Broker는 상태 및 오류 보고 기능을 향상시킴

Data Recovery Advisor는 Intelligent Data Repair를 위한 가용 스탠바이 데이터베이스를 활용할 것임

Documents

Oracle Database 11g Release 2 기반의 Oracle Data Guard 기술 백서 - Oracle Database 11g Release 2 기반의 Oracle Data Guard 4 "현재 Direct SAN-to-SAN replication 대신 Oracle