ORACLE Data Guard Architecture

출처 - http://h391106.tistory.com/231

ORACLE Data Guard Architecture v1.0

 

Date	Ver	Etc.
2011.04.15	1.0

  

 

1.    ORACLE Data Guard : Overview

A.     Overview

(*출처 A)

 

Data Guard 는 위와 같은 아키텍처를 가진다.

 

Primary Database 와 Standby Database 로 구성되며 하나의 Primary Database 에 최대 9개의 Standby Database 가 구성될 수 있다.

 

Primary 측의 변경사항은 Redo Logs 에 기록되는데 이는 백그라운드 프로세스 (LGWR 혹은 ARCn) 에 의해 Standby 측에 Oracle Net 을 통해 전파된다.

 

전파된 변경 내역은 Standby Redo Log 에 쓰였다가 Database 에 적용된다.

 

B.     Standby Database 의 종류

Standby Database 의 종류는 Physical / Logical Standby Database 로 나뉘어진다.

 

Physical Standby Database 는 Standby Database 가 Primary Database 와 block-level 로 동일하다. 이것이 의미하는 바는 특정 데이터의 rowed 가 동일하다는 것이며 Standby Database 의 백업본이 Primary Database 에 대해서도 사용될 수 있다는 것이다. Standby Database 의 동기화는 Primary Database 로부터 받는 Redo Data 를 이용해 이루어진다. (Redo Apply)

 

Logical Standby Database 는 Primary 와 Standby Database 가 Schema-level 로 동일하다. Schema-level 로 동일하다 함은 앞서 Physical Standby Database 와 달리 동일 데이터에 대한 rowid 가 동일하지 않을 수 있다는 걸 의미하며 Standby Database 의 백업본을 Primary 에서 사용할 수 없다는 것이다. Standby Database 의 동기화는 Primary 로부터 받은 redo 를 가공하여 SQL statements 를 추출하고 이를 실행하여 이루어진다. (SQL Apply)

 

C.     Oracle Data Guard Broker Framework

(*출처 B)

 

Data Guard Broker 를 사용함으로써 데이터 가드와 관련해 분산된 관리포인트를 중앙집중화 하여 관리적 편의와 모니터링 기능을 제공한다. 여기서 관리적 편의라 함은 SQL*PLUS 상에서 Fail Over 를 한다고 했을 때 수행해야 하는 명령어들과 파라미터 변경 (dynamic 하게 수정한다. 때문에 spfile 을 사용해야 한다.) 과 같은 여러 작업들이 GUI, CLI 상에서는 명령어 하나로 해결이 된다.

 

Data Guard Broker 를 사용하지 않는다는 것은 가드를 컨트롤할 GUI, CLI 도구를 사용하지 않겠다란 의미와 동일하다. GUI 도구에 해당하는 것은 Grid Control 에 해당되며 CLI 라 함은 DGMGRL 를 의미한다.

Data Guard Broker 를 사용하면 DMON Process 가 시작되고 Configuration File 이 생성된다.

 

위 그림에 대해 추가적인 부연설명을 하자면 GUI 를 사용하는 경우, 즉 Grid Control 을 이용하고자 할 때 각 서버에는 OMA 가 구성되어 있어야 한다.

 

D.     Role Transitions : Switchover and Failover

Role Transitions 은 Primary 와 Standby Database 의 Role 이 변경되는걸 의미한다.

Switchover 와 Failover 를 판가름하는 중요한 기준은 ‘계획된 상황’ 인가 여부이다.

 

Switchover 는 ‘계획된 상황’ 으로 role 변경을 위해, 혹은 OS 나 H/W 유지보수를 위해 진행된 경우이다.

Failover 는 ‘계획되지 않은 상황’ 으로 다시 말해 장애가 났음을 의미한다. 이 경우 data protection mode 에 따라 데이터 손실이 없을수도 있을수도 있다.

Fast start failover 에 대한 셋팅이 되어있는 경우 자동화 할 수 있다.

 

E.     Data Protection Modes

Data Guard 구성에 사용할 수 있는 Protection Mode 는 세가지가 있다.

 

<Maximum Protection>

해당 모드는 Primary Database Fail 과 관련해 no data loss 를 보장한다. 이를 지원하기 위해 각 트랜잭션에 대해 recover 할 수 있는 redo data 가 트랜잭션 commits 전에 반드시 local online redo 로그와 최소한 하나 이상의 standby redo log 에 쓰여져야 한다. Data loss 가 일어나지 않았음을 확신하기 위해 Primary Database 는 오류로 인해 최소한 하나 이상의 remote standby redo log 에 redo stream 을 쓰지 못한 경우 shutdown 된다.

 

<Maximum Availability>

Maximum Protection Mode 와 마찬가지로 redo data 는 최소 하나 이상의 remote standby redo log 와 local online redo 에 쓰여져야 commit 한다.

다른 점으로는 remote standby redo log 에 대한 redo stream 에 쓰기를 실패하더라도 Primary database 를 shutdown 하지 않는다. 대신에 Maximum Performance 로 동작을 하는데 문제가 문제가 해소되고 redo log gap 이 해소되면은 자동적으로 Maximum Availability 모드로 복귀한다.

 

<Maximum Performance>

이는 Primary Database 의 Performance 에 주는 영향을 최소화 한 Protection Mode 이다. 이 경우 commit 에 대해 online redo log 에 redo log 를 씀으로써 달성하며 최소한 하나이상의 standby database 에 대해 redo data stream 이 쓰여진다. 하지만 이 데이터는 redo data 를 만들어낸 트랜잭션의 커밋에 대해 비동기적으로 쓰여진다.

 

해당 모드는 Primary 와 Standby Database 간에 Network 상황이 좋지 않을 때 Primary Database 의 Performance 침해를 최소화 할 수 있다.

 

2.    ORACLE Data Guard Architecture

A.   Data Guard Operational Requirements

Primary - Standby 구성 간 하드웨어는 다를 수 있다.

Operating system (release 는 달라도 된다.)과 Platform Architecture 는 반드시 동일해야 한다.

동일한 Release 의 Database Enterprise Edition 이 설치되어야 한다.

각 Database 는 고유한 control file 을 가져야 한다.

Primary Database 는 반드시 ARCHIVELOG mode 이어야 한다.

Standby Database 구성을 위한 data file backup 이전에 Primary Database 에 FORCE LOGGING 이 수행되어야 한다.

 

B.   Oracle Data Guard : Architecture

<DATAGUARD USING ARCHIVER PROCESS>

 

Figure 5-3 Archiving to Local Destinations Before Archiving to Remote Destinations

(* 출처 C)

 

위 경우는 Redo Stream 에 redo log 를 writing 할 프로세스로 Archiver Process 를 택하였다.

Oracle Net 을 통해 Redo Log 가 전송되는 부분을 보면 LOG_ARCHIVE_DEST_2 라 되어 있는데 이는 REDO STREAM 을 쓸 Archiver 로 2번을 사용했을 뿐이고 번호는 상황에 따라 달라질 수 있다.

 

위 그림을 보면 ARC1 가 ARC0 이 만든 Archived Log 를 복사하여 Standby Database 에 전송한다. 전송된 redo data 는 Remote File Server Process 가 Standby Redo Log File 에 기록한다. 이와 같이 기록된 파일은 Real Time Apply 를 사용하느냐 여부에 따라 적용되는 시점이 달라진다.

 

이 설명에 앞서 Database 에 변경 내역을 적용하는 Process 로 MRP or LSP 가 있는데 MRP 는 Redo Apply 시 (Physical Standby Database), LSP 는 SQL Apply 시 (Logical Standby Database) 동작한다.

 

Real Time Apply 가 적용되지 않는 경우 Archiver 가 RFS 가 쌓은 Standby Redo Log Files 를 이용하여 Archived Redo Log File 을 생성한다. 이후 MRP 가 Redo Log 를 apply 한다.

 

결과적으로 Standby Database 가 Apply 되기 위해서는 Master 의 Redo Log File 이 Archived 되어야 한다. 이로 인해 Standby 는 Primary 의 Current Redo Log 만큼 (다른 Redo Log File 이 모두 Archived 되었고 이것이 Standby Database 에 모두 적용되었다는 가정하에) 차이가 날 수 있다.

 

Real Time Apply 를 사용하는 경우 Archiver 가 Archived Redo Log File 을 생성하기 전에 Standby Redo Log File 을 MRP 나 LSP 가 Standby Database 에 적용한다. 다시말해 Standby Redo Log 를 가지고 Archived 하는 시간 대기 없이 Database 에 바로 적용한다.

 

/*+ Logical Standby Database 에서의 Real Time Apply? */

 

<DATAGUARD USING ARCHIVER PROCESS : SYNC>

 

Figure 5-4 LGWR SYNC Archival to a Remote Destination with Standby Redo Log Files

(* 출처 C)

 

Sync Archival 과 관련된 파라미터는 LOG_ARCHIVE_DEST_n 이다. 해당 파라미터에 사용할 수 있는 value 로 sync 옵션이 있는데 이는 default 로 가지는 값이다. sync 를 사용하는 경우 net_timeout 도 같이 셋팅할 것을 추천한다. 해당 파라미터는 LGWR 가 Network Server Process 를 기다리는 시간(초) 으로 해당 초 안에 응답이 없는 경우 LGWR Process 는 error 를 반환한다.

 

Primary Database 에서는 LGWR 가 redo data 를 하나 이상의 network server (LNSn) processes 로 보낸다. 이 프로세스들은 multiple remote destinations 에 대해 network I/O 를 초기화 한다. Transaction (on Primary Database) 은 LGWR SYNC 로 셋팅된 모든 destinations 에 대해 Transaction recover 에 필요한 redo redo data 가 받아지기전까지 commit 하지 않는다.

 

Standby Database 에서는 Rewmote File Server (RFS) 가 네트워크를 이용해 LGWR 로부터 redo data 를 받는다. 그리고 그것을 standby redo log files 에 기록한다.

 

<DATAGUARD USING ARCHIVER PROCESS : ASYNC>

 

Figure 5-5 LGWR ASYNC Archival with Network Server (LNSn) Processes

(*출처 C)

 

LGWR ASYNC Archival 의 경우도 LGWR SYNC 모드와 동일하게 LNSn 이 Standby Database 의 RFS 에 Redo data 를 전달한다. 다만 LGWR 로부터 redo data 를 바로 받는게 아니라 Online Redo Log File 을 읽어들인다. 이후의 Standby Database 에서 일어나는 일은 LGWR SYNC 와 동일하다.

 

C.     Physical Standby Database / Logical Standby Database

Physical Standby Database 는 앞서 말한 것과 같이 REDO APPLY 를 의미한다. REDO 가 APPLY 되는 상황은 MRP (Managed Recovery Process) 가 Start 되었을 때 적용이 되며 이는 mount 상태에서 수행가능하다. 이를 다시 이야기 하면 mount 단계에서만 physical standby database 로써 동기화 작업을 수행한다는 것을 의미한다. Physical Standby Database 도 open 이 가능한데 read-only mode 로 가능하다. 또 open 되어 있는 동안에는 redo log 가 apply 되지 않는다. (11g 는 read-only 로 open 되어 있는 상황에서도 redo log 를 apply 한다. : active standby )

 

Logical Standby Database 는 SQL APPLY 를 의미한다. SQL 을 APPLY(execute) 하는 상황은 LSP Process 를 시작했을 때이다.

/*+ Logical Standby Database 의 OPEN Mode 에 따른 SQL APPLY 여부 */

 

D.     Standby Redo Logs

Standby Redo Logs 는 Database 가 Standby role 에 있을때만 사용된다. 이 공간은 Primary Database 로부터 redo data 를 받아 저장하는데 사용된다.

 

Standby Redo Logs 는 다음의 상황에 필요하다.

-      Data Protection Mode : Maximum Protection, Maximum availability

-      Real-time apply

-      Cascaded redo log destinations

 

Standby redo logs 는 Maximum performance data protection mode 에 대해서도 사용이 권장된다.

 

만약 real-time apply 를 사용하지 않는다면, data 가 standby database 에 적용되기 전에 standby redo logs 는 반드시archived 되어야 한다.

 

E.     Physical Standby Database : Redo Apply Architecture

production (primary) database 는 1 ~ 9 개의 standby database 를 가질 수 있다.

이와 연관된 파라미터로 log_archive_dest_n 이 있다. n 에 들어갈 수 있는 범주는 1 ~ 10 (10개) 로 하나는 local archive destination 으로 쓰이기 때문에 최대 9개의 standby database 를 가질 수 있다.

 

F.     Logical Standby Database : SQL Apply Architecture

Figure 9-1 SQL Apply Processing

(* 출처 D)

 

Logical Standby 역시 Physical Standby Database 와 동일하게 Primary 의 변경내역을 Standby 에 적용한다. 이 일을 하는 프로세스가 MRP -> LSP 로 바뀐 것을 말고는 아키텍처상 큰 차이는 없어보인다.

 

다만 변경사항을 적용하기 위한 방법이 REDO APPLY 가 아니라 SQL APPLY 라는 것이고 이것은 내부적으로 위의 아키텍처와 같이 동작한다.

 

Oracle Net 을 통해 전달된 Redo data 는

a.    Reader Process 는 archived redo log files 로부터 redo records 를 읽어들인다.

b.    Preparer Processes 는 block changes 를 table changes ( =logical change records=LCRs) 로 변환한다. 이 시점에는 트랜잭션에 아무 영향 없다.

c.    Builder Process 가  개개의 LCRs 로부터 완성된 트랜잭션을 만들어낸다.

d.    Analyzer Process 가 records 를 검사하고, 제거할 수 있는 트랜잭션을 제거하고 다른 트랜잭션 간의 dependencies 를 확인한다.

e.    Coordinator Process(=LSP) 는 다음의 행동을 한다.

-      트랜잭션을 할당

-      트랜잭션간의 의존성을 모니터링하며 스케쥴링한다.

-      Logical Standby Database 에 대한 변경에 대해 commit 을 승인한다.

f.      Applier Processes 는 다음의 행동을 한다.

-      LCRs 를 database 에 적용한다.

-      의존성 해결이 되지 않은 트랜잭션에 대해 coordinator process 에게 승인을 요청한다. (이 요구에 따라 LSP 는 Scheduling 을 하게 되며 이를 통해 의존성 문제가 해결이 된다.)

-      해당 트랜잭션을 commit 한다.

 

G.    Real-Time Apply

Real-Time Apply 는 Standby redo log files 를 archived 하기 전에 MRP 혹은 LSP 를 통해 Standby database 에 적용한다. 이를 통해 down time 의 최소화를 달성할 수 있다.

 

H.     Standby Redo Log Configuration

Standby Database 의 Standby Redo Logs 수는 최소한 Primary 의 Redo Logs 의 그룹수와 동일해야한다. 보통 그룹을 하나 더 두는 것을 추천한다. 추가적으로 파일 사이즈는 반드시 같거나 더 커야한다.

 

RFS process 가 archived redo log 를 쓰는 경우는 다음과 같다. (Standby redo logs 가 아닌)

-      Standby redo logs 가 없을 때

-      들어오는 online redo log file 에 대해 같은 사이즈의 standby redo log 를 찾지 못했을 때

-      모든 올바른 사이즈의 standby redo logs 가 아직 archived 되지 않았을 때

 

3.    References

A.     1 Introduction to Oracle Data Guard |

http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/concepts.htm

 

B.     3 Managing Broker Configurations |

http://download.oracle.com/docs/cd/B19306_01/server.102/b14230/configure.htm

 

C.     5 Redo Transport Services |

http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/log_transport.htm

 

D.     9 Managing a Logical Standby Database |

http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/manage_ls.htm#g1057004

 

E.     Oracle Database 10g : Data Guard Administration