Standby Database와 Physical Data Guard - dbguide.net · Oracle9i Data Guard Standby database and Physical Data Guard 기술적인질문은채팅으로 이희열, 이은지, 문상준

Oracle9i Data Guard

Standby database and Physical Data Guard 기술적인 질문은 채팅으로

이희열, 이은지, 문상준

한국오라클 (주) 제품지원실

Getting the most out of MetaLink

Standby Database와Physical Data Guard

오라클은 Oracle9i부터 Data Protection과 Disaster Recovery 솔루션으로서 Data Guard를

제공합니다.

이는 기존의 Standby db를 계승하고 있 지만 기능에 있어서는 매우 많은 혁신과 변경이

이루어졌습니다.

본 세미나는 이러한 Data Guard의 핵심적인 주요변경 사항과 이를 통해 어떻게 하면 data의 손실을

최소화 할 수 있는지에 대하여 설명합니다.

그럼 “Standby database와 Physical Data Guard" 세미나를 시작 하겠습니다.

Oracle9i Data Guard


1. Data Guard Overview2. Data Guard Architecture3. Data Guard New Features4. Log Transport Services5. Log Apply Services6. Role Management Services7. Miscellaneousness

Contents

본 세미나는 다음과 같이 구성되었습니다.

먼저 Data Guard 란 무엇인가에 대해 알아 보고 Data Guard안에 포함된 새로운 New feature들에 대해서

설명합니다.

그리고 Data Guard의 핵심 서비스인 아래의 내용에 대하여 자세히 알아 봅니다.

- Log Transprt Services

- Log Apply Services

- Role Management Services

또한 마지막으로 Data Guard를 구성하고 운영함에 있어 고려해야 할 사항들에 대해서 알아 봅니다.

이 Seminar의 모든 내용은 Oracle 9i Release 2를 기반으로 합니다.

Oracle9i Data Guard


Enhances high availability and disaster protection Provides a single uniform management interfaceAutomates the creation and configuration of physical standby databasesSupports failover and graceful switchoverSafeguards against physical corruptionProvides configurable log transport servicesProvides configurable log apply servicesProvides monitoring, alert and control mechanisms

Data Gurard Overview

Oracle 9i Data Guard는 다음과 같은 요소들을 제공합니다.

1. 분산 처리 구성(distributed computing configuration)을 통한 가용성(availability)과 데이터 보호성

(disaster protection)을 더욱 향상시켰습니다.

- Oracle9i Data Guard는 disaster recovery solution으로서 primary database와 physical standby

database를 하나로 묶어 구성하였으며 쉽게 관리되도록 디자인 되었습니다.

또한 하나의 Data Guard 안에 포함된 Primary database 와 standby database들은 종종 지리적으로

분산되도록 구성되어지는데 이들은 Oracle Net에 의하여 연결됩니다.

2. 단일 관리 인터페이스를 제공합니다.

- Data Guard broker를 통해서 Database resource와 application resource를 관리하고 통제합니다.

- Data Guard broker는 graphical user interface(Oracle9i Data Guard Manager )와

command-line interface를 제공합니다.

3. 자동으로 Physical standby database를 생성하고 설정하는 기능을 제공합니다.

- Data Guard broker는 physical standby database를 자동으로 생성하고 설정하는 기능을 제공합니다

4. Switchover와 Failover 기능을 제공합니다

- Switchover는 patch적용과 같은 전형적인 관리 작업 수행 시 database의 downtime 시간을 줄이는데

큰 도움을 줍니다.

Oracle9i Data Guard


Data Guard Architecture

StandbyDatabase

Standby RedoLogs

OracleData Guard

Broker

Log Apply

Services

ArchivedLogs

StandbyDatabase

Standby RedoLogs

OracleData Guard

Broker

Log Apply

Services

ArchivedLogs

ArchivedLogs

Primary Database

Online RedoLogs

OracleData Guard

Broker

Log TransportServices

StandbyDatabase

Standby RedoLogs

OracleData Guard

Broker

Log Apply

Services

ArchivedLogs

Standby Site 1

Standby Site 2

Standby Site n

Oracle Net

Oracle9i Data Guard ManagerGraphical User Interface

orCommand-Line Interface

Data Guard는 하나의 Primary database와 최대 9개까지의 Standby database로 구성 될 수 있습니다.

그리고 Standby database에는 Physical Standby database와 Logical Standby database 두 가지 형태가

있습니다.

Physical Standby database는 primary database의 redo log를 standby database에 직접 적용하는 형태이고,

Logical Standby database는 LogMiner Technology를 사용하여 redo log의 내용을 SQL statement 형태로

전환하여 이를 적용하는 방식 입니다.

이 세미나에서는 오직 Physical standby database와 함께 구성되는 Data Guard만을 언급하겠습니다.

위 Architecture를 살펴 보면 Data Guard는 다음과 같은 구성요소로 이루어져 있습니다.

1. Data Guard Broker

- 이것은 Data Guard를 통합 관리하는데 있어 편리성을 제공하기 위해 제공되는 구성요소 입니다.

그러나 이것은 Data Guard를 구성하기 위한 필수 요소는 아닙니다.

2. Log Transport Services

- Log transport services는 Primary database의 Redo log를 Standby database에 전송하여 archived

redo log file또는 standby redo log file의 형태로 저장함으로써 standby database가 이를 사용

가능하도록 만들어 줍니다.

3. Log Apply Services

- Log apply services는 Log transport services에 의해 전송된 archived redo log나, Standby Redo Log를

switching 함으로써 발생된 archived redo log을 Media Recovery방법을 이용하여 Standby database에

적용합니다.

4. Standby Redo Log

- Log transport services가 archived redo log보다 더 작은 단위로 online redo log를 전송하도록 해 줍니다.

Oracle9i Data Guard


Physical Standby DatabaseA physical standby is physically identical to the primaryThe log transport and log apply functionality that used to be part of Automated Standby Databases, is now contained in separate layers named Log Transport Services and Log ApplyServicesDatabase role reversal is now supported, and is implementedin the Role Management Services layerData Guard is the term used to collectively refer to all of thecomponents described above

Physical standby database는 물리적으로 primary database와 동일합니다.

그래서 primary database의 변동 사항을 redo log를 사용하여 Standby database에 적용할 때 physical

ROWID를 사용하는 BLOCK-FOR-BLOCK 방식을 사용합니다. 그러므로 Physical standby database는 managed

recovery mode 동안에는 READ/WRITE 방식으로 open될 수 없습니다.

기존의 Standby database(8.0, 8i)에서도 Log transport 기능과 log apply 기능을 내재하고 있었습니다.

그러나 Oracle9i Data Guard부터는 이러한 기능을 Log Transport Services와 Log Apply Services라는 이름의

별도의 layer로 독립시켜 더욱 그 기능을 강화하고 향상시켰습니다.

또한 기존의 Standby database(8.0, 8i)는 Primary database와 Standby database가 그 Role을 서로 자유롭게

바꿀 수 없었습니다. 오직 Primary database 복구 불능 시에 Standby database를 Primary database Role로

전환하는 1 가지 방법(Failover)만을 제공하였습니다.

그러나 Oracle9i Data Guard는 이제 Data손실 없이 Primary와 Standby의 Role의 전환(Switchover)을 자유롭게

해줍니다. 이러한 기능을 Role Management Services라 부릅니다.

Oracle9i Data Guard


Physical Standby Database New Features

2) Database switchover 3) Archive gaps are automatically detected and transmitted4) Adding new datafiles(STANDBY_FILE_MANAGEMENT)

1) Database protection modes

Oracle9I R1(9.0.1) Oracle9I R2(9.2)

Guaranteed protectionInstant protectionRapid protectionDelayed protection

Maximum ProtectionMaximum AvailabilityMaximum Performance

Oracle9i Physical Standby database의 New Feature들을 살펴 보도록 하겠습니다.

1. Database protection modes

- Primary database와 Standby db사이의 Data Loss를 어느 정도까지 허용할 것인가에 따라 몇 가지

mode로 Data Guard를 설정할 수 있습니다.

protection mode는 Oracle9i R1(9.0.1.x)과 Oracle9i R2(9.2.0.x) 사이에 큰 차이가 있습니다.

위 표에서 보시는 바와 같이 R1에서는 Guaranteed, Instant, Rapid, Delayed 4가지 Mode로 구분하였으나

R2에서는 크게 Maximum Protection, Maximum Availability, Maximum Performance 3 가지 Mode로 구분

합니다. 이는 좀더 간단하고 편리하게 그리고 명확하게 관리할 수 있도록 하기 위해서 이와 같이 data

protection mode를 변경한 것입니다. 굳이 둘 사이를 Mapping해 본다면 Guaranteed는 Maximum

Protection과 Instant 는 Maximum Availability과, 그리고 Rapid와 Delayed는 Maximum Performance과

동일하다고 볼 수 있습니다.

2. Database Switchover

- Primary database는 Standby database중 하나와 그 Role을 바꿀 수 있습니다. 즉 Primary db는 Standby

db가 되고 해당 선택된 Standby db는 Primary db가 되는 것입니다. 이때 Data의 손실은 전혀 발생하지

않습니다. 필요하다면 처음 상태로 다시 되돌릴 수도 있습니다.

3. Archive gaps are automatically detected and transmitted

- Archive gap들은 자동으로 탐지되고 전송됩니다. 이 기능은 Log transport services와 Log apply services

양쪽 모두에 구현되어 있습니다. FAL_CLIENT 와 FAL_SERVER parameter를 설정함으로써 이 기능을

활성화시킬 수 있습니다.

4. Adding new datafiles

- DBA가 STANDBY_FILE_MANAGEMENT 와 DB_FILE_NAME_CONVERT initialization parameter를

설정해 놓기만 한다면 Primary db에 새로운 datafile을 추가했을 때 Standby db에서도 자동으로 새로운

Datafile이 추가됩니다. 기존 Standby db(8.0, 8i)는 Primary db에 새로운 datafile을 추가하였을 때 반드시

이에 상응하는 datafile인 standby db에도 manual하게 생성시켜 주어야만 했습니다.

Oracle9i Data Guard


5) Background managed recovery mode6) Parallel recovery7) Standby redo logs are introduced8) Archiver process(ARCn) is available on standby db9) Cascading standby database( 9iR2)

Physical Standby Database New Featurescontinued

5. Background managed recovery mode

- Physical Standby database는 Managed recovery를 수행하기 위해서 background process(MRP)를

제공합니다.

이 Process는 managed recovery 명령을 수행한 foreground process에게 control을 넘겨주어 다른 작업을

수행할 수 있도록 합니다.

6. Parallel recovery

- Log apply services에서 managed recovery시 parallel로 수행하여 좀 더 빠르게 recovery를 수행할 수 있도록

해 줍니다. Parallel recovery를 수행하기 위해서는 다음과 같은 명령을 수행합니다.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE PARALLEL 8;

7. Standby redo logs are introduced

- Primary database에서 전송된 redo data는 standby redo log또는 archived redo log 형태로

standby db쪽에 저장 될 수 있습니다.

8. Archiver process(ARCn) is available on standby database

- Standby database에서 standby redo log를 archiving하기 위해서 archiver process(ARCn )가 필요합니다.

ARCn은 해당 LOG_ARCHIVE_DEST_n 에 지정된 위치에 archive redo log를 생성시키며

이 위치는 local directory일 수도 있고 remote standby database의 directory일 수도 있습니다.

9. Cascading standby database( 9iR2)

- cascading standby database는 primary database가 아닌 다른 standby database에서 redo information을

받는 standby database입니다. Primary system에서의 부하를 감소시키기 위해서 cascading standby

database를 구현할 수 있습니다.

============ redo ============ redo ============

PRIMARY db ------------- Standby db A ---------------- Standby db B

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

cascading standby db

Oracle9i Data Guard


Log Transport Services

In Oracle9i, the log transport services have become a separate component

The new log transport services Offer different log transport mechanismsHandle and report log transport errorsRetrieve lost logs after system failure

The main benefits of the new services are greater flexibility and resilience to data loss

Log transport services는 primary database의 data가 standby database에서 사용 가능하도록 자동으로

primary database의 online redo log를 standby database에 복사합니다.

Log transport services는 redo log가 전송될 destination과 각 destination에 대해 반드시 archiving이

필요한지에 대한 정의를 하는데 있어 융통성을 제공합니다.

이 서비스는 또한 I/O failure handling과 transmission restart 기능을 제공합니다.

Archiver process(ARCn) 또는 Log writer process(LGWR)가 online redo log를 각 Destination에 전송하며

총 10개의 destination까지 설정할 수 있습니다.

Destination은 initialization parameter(LOG_ARCHIVE_DEST_n)를 통해 설정되며 적어도 1개의 destination은

반드시 local directory에 설정되어야 합니다.

Remote destination은 network services configuration file(tnsnames.ora)안에 정의된 Oracle Net service

name 을 사용하여 설정 됩니다.

Remote destination이 standby database라면 standby database는 반드시 mount 상태나 Read-only mode로

Open되어 있어야 합니다.

Standby database에 대한 Network connection이 끊기면 network connection을 재설정하여 log archiving을

계속하도록 해 줍니다. Oracle9i에서는 많은 network failure를 자동으로 처리해 줍니다.

Note: Standby database 상의 Remote File Services(RFS) process는 primary database의 LGWR 또는

ARCn로부터 Redo log 전송 받아 local disk상에 기록합니다.

Oracle9i Data Guard


Log Transport Services Architecture

PrimaryDatabase

Physical/Logical Standby

DatabaseTransactions

Backup /Reports

LGWR(Synchronous/Asynchronous) MRP/ LSP

Online Redo Logs

ARCH(Synchronous)

RFS

StandbyRedo Logs

Affirm/NoAffirm

ARCH

FAL

Archived Redo Logs Archived Redo Logs

Oracle Net

Transform Redo to SQLfor SQL Apply

Log Transport Services를 수행하는 구성 요소들은 다음과 같습니다.

1. Log Writer Process(LGWR)

- LGWR은 Primary database의 transaction redo log를 Local online redo logfile에 Write 합니다.

또 한편 Oracle Net을 통하여 online redo의 내용을 Standby database에 전송하기도 합니다.

2. Archiver Process(ARCn)

- Primary database의 ARCn은 Local online redo log를 archiving하는 역할을 합니다.

또 한편 Oracle Net을 통하여 Remote에 있는 Standby database에 Archived redo log를 전송하기도 합니다.

3. Remote File Services Process(RFS)

- RFS는 standby database에서 동작하는 process로서 Primary database의 LGWR또는 ARCn에서 전송한

Redo log를 받아 Local disk에 저장하는 역할을 수행합니다. 이때 RFS는 LGWR로부터 받은 redo log는

Standby redo log에 ARCn으로부터 받는 redo log는 Archived redo log의 형태로 저장하게 됩니다.

4. Standby Redo Log

- Standby redo log는 Primary database의 LGWR로부터 전송된 redo log만을 저장하기 위한 저장소이다.

LGWR은 ARCH와는 달리 primary database에서 발생한 Transaction단위(commit)의 redo log들을 전송하기

때문에 Standby database에서는 이러한 redo log들을 모아 저장하기 위한 저장소가 필요했고 이를 위해

고안 된 것이 Standby Redo log이다.

Note : Physical standby database가 managed recovery mode일 경우 Log transport services는 Dedicated

server process를 사용하여 해당 physical standby db에 접속해야 합니다.

Oracle9i Data Guard


Data Protection Modes

Maximum Protection

Maximum Availability

Maximum Performance

Oracle9i Data Guard는 다음 3 가지 protection mode중 하나로 운영됩니다.

즉 maximum protection mode, maximum availability mode 그리고 maximum performance mode 입니다.

이 3가지는 각각 data protection과 data availability, 그리고 primary database의 performance 사이의

서로 다른 균형점을 제공합니다.

Oracle9i Data Guard



Maximum Protection

The highest level of data protectionNo data lossNo data divergenceThe highest potential impact on the performance and availability of the primary database.

Maximum Protection mode는 가장 높은 레벨의 data protection을 제공합니다.

Primary database transaction은 redo data가 standby database중 적어도 하나에 쓰여질 때까지

commit되지 않습니다. 만약에 Primary database가 standby database중 어느 하나에도 redo data를

write하지 못하면 primary database를 강제로 shutdown함으로서 standby database에 반영되지 못한

data가 발생하지 않도록 합니다.

이 mode는 데이터 손실을 조금이라도 용납하지 않습니다. 대신 primary database의 performance와

availability에 지대한 영향을 미칠 수 있습니다.

Oracle9i Data Guard



Maximum availabilityThe next highest level of data protection.A primary database transaction will not commit until the redo data needed torecover that transaction is written to at least one standby databaseThe primary database will not shut down if it is unable to write the redo datato at least one such standby database.Instead, the protection mode will be temporarily lowered to maximumperformance mode

This mode guarantees no data loss unless the primary database fails while it isin maximum performance mode.The highest level of data protection that is possible without affecting theavailability of the primary database.

Maximum Availability mode는 Maximum Protection mode 다음으로 가장 높은 레벨의 data protection mode

입니다.

이 Mode 역시 primary database에서 발생된 transaction redo data가 standby database중 적어도 하나에

Write될 때까지 Commit되지 않습니다. 그러나 이 mode는 maximum protection mode와는 달리 primary

database에서 발생된 redo data가 Standby database중 어느 하나에도 write되지 못하였을 경우 primary

database가 shutdown 되지 않습니다.

대신에 fault가 모두 수정되어 정상적인 상태가 될 때까지 일시적으로 protection mode가 Maximum

Performance mode로 낮춰집니다.

Maximum availability mode는 일시적으로 maximum performance mode로 전환된 동안에 primary database가

fail되지만 않는다면 no-data-loss를 보장합니다.

이 mode는 primary database의 availability에 영향을 주지 않으면서 가장 높은 data protection을 구현할 수

있습니다.

Oracle9i Data Guard



Maximum performanceThe default protection mode.A primary database transaction will not wait to commit until the redo data needed to recover that transaction is written to a standby database.some data might be lost if the primary database fails and the redo data needed to recover committed transactions is not available at any standby database.The highest level of data protection that is possible without affecting the performance or availability of the primary database.

Maximum Performance mode는 Data Guard의 default protection mode 입니다.

이 mode는 redo data가 standby database중 어느 하나에 write될 까지 commit을 기다리지 않습니다.

그래서 Primary database가 fail된 동시에 standby database중 어느 것도 redo data를 가지고 있지 않게 되면

데이터가 손실될 수 있습니다.

Maximum Performance mode는 Primary database의 availability와 performance에 영향을 주지 않고

운영 가능한 data protection mode입니다.

Oracle9i Data Guard


Log Transport Services Capabilities

Permission

Destination

Transmission

Reception

Failure Resolution

이제 Log Transport Services 를 좀 더 세분화 하여 알아 보도록 하겠습니다.

Log Transport Services는 다음 5가지의 Category로 분류됩니다.

1. Permission

2. Destination

3. Transmission

4. Reception

5. Failure Resolution

Oracle9i Data Guard


Log Transport Services Capabilities: Permission

Setting Permission to Archive Redo Logs

REMOTE_ARCHIVE_ENABLE

TRUE : bothFALSE : bothSEND : primaryRECEIVE : standby

Remote destination 에 online redo log를 archiving하기 위한 Permission 설정은 REMOTE_ARCHIVE_ENABLE

parameter를 사용하여 기술 될 수 있다.

일반적으로 Data Guard환경에서 primary database와 standby database 모두 True로 설정한다.

그러나 각각 독립적으로 remote archive redo log의 sending과 receiving을 관리하려면 SEND와 RECEIVE

option을 사용할 수 있다.

1. REMOTE_ARCHIVE_ENABLE=TRUE 는 primary database와 standby database 양쪽 모두에 설정되며

Primary database에서 redo log를 standby database에 sending하는 것을 허용하고 Standby

database에서는 Primary database로부터의 archiving을 위해서 redo log를 receving하는 것을 허용합니다.

2. REMOTE_ARCHIVE_ENABLE=FALSE 는 primary database와 standby database 양쪽 모두에 설정되며

redo log의 sending과 receiving 모두를 허용하지 않습니다.

3. REMOTE_ARCHIVE_ENABLE=SEND는 Primary database에 설정되어 Primary database가 redo log를

standby database로 sending하는 것을 허용합니다.

4. REMOTE_ARCHIVE_ENABLE=RECEIVE 는 Standby database에 설정되어 Standby database가 redo log를

primary database로부터 receiving하는 것을 허용합니다.

Oracle9i Data Guard


Log Transport Services Capabilities: Destination

LocalA local file system location.

Remote Physical standby databaseLogical standby databaseArchive log repositoryCross-instance archival database

Log Transport Services의 Destination은 Local host 상에 위치할 수도 있고 Remote host 상에 위치할 수도

있습니다.

Local destination

- Local file system 상에 있는 Destination 입니다.

LOG_ARCHIVE_DEST_1=’LOCATION=/arc_dest’

Remote destination

- Oracle Net service name을 사용하여 접근할 수 있는 remote host 상에 있는 Destination입니다

LOG_ARCHIVE_DEST_2 = ’SERVICE=standby1’

- Remote destination은 다음과 같은 몇 가지 형태들이 있습니다.

1) Physical standby database

- 재난을 대비한 primary database와 동일한 복사본 database

2) Logical standby database

- Archived redo log를 받아 SQL transaction으로 변환 뒤 이를 적용하는 방식의 standby database.

3) Archive log repository

- 단순히 archived redo log만을 저장하기 위한 off-site destination 입니다.

오직 controlfile로만 구성되어 있습니다.

4) Cross-instance archival database

- RAC 환경에서 primary database의 다른 한 node를 Destination으로 사용하는 것입니다.

Oracle9i Data Guard


Log Transport Services Capabilities: Transmission

The Process that Transmits Redo Data

Network Transmission ModeSYNC network transmission methodASYNC network transmission method

Attribute Example Default

{ARCH|LGWR } LOG_ARCHIVE_DEST_3=’SERVICE=stby1 LGWR’

ARCH

Attribute Example Default

{SYNC[=NOPARALLEL|PARALLEL]| ASYNC [=blocks] }

LOG_ARCHIVE_DEST_3=‘SERVICE=stdby1 LGWR SYNC’

SYNC

다음과 같은 요소를 통하여 Primary database에서 standby database로 전송되는 redo log의 형태와

전송방식을 선택할 수 있습니다.

1. The process that will perform the log transmission operation

- Redo log를 전송하기 위해서 Log Writer process(LGWR)나 Archiver process(ARCn)을 사용할 수

있습니다.

2. The method of transmitting redo logs over the network

- Log Writer process(LGWR)를 사용할 때는 synchronous 또는 asynchronous network transmission

방식을 사용할 수 있습니다.

LGWR는 “online redo logs”의 형태로 red log를 standby database에 전송합니다.

- Archiver process(ARCn)를 사용할 때는 오직 synchronous transmission 방식만을 사용할 수 있습니다.

ARCn는 redo log를 “archived redo logs” 형태로 전송합니다.

Oracle9i Data Guard


Log Transport Services Capabilities: Reception

Reception 은 primary database에서 전송된 redo log가 Standby database 내의 어느 곳에 저장될 것인가를

결정하게 해 줍니다.

위 그림에서 보시는 바와 같이 Primary database에서 전송된 redo log를 Standby database내의 RFS process가

받아서 Standby redo log또는 archived redo log 형태로 standby database 내에 저장하게 됩니다.

Standby redo log는 Primary database의 LGWR이 전송한 redo log를 저장하기 위해서 사용됩니다.

standby redo log는 별도의 redo log file group으로서 physical standby database role일 경우에만

사용됩니다.

Oracle9i Data Guard


Log Transport Services Capabilities: Reception continued

Standby Redo LogsMaximum protection mode and maximum availability modeRemote file server process (RFS)- Receive the Redo data and write it to the standby redo logsStandby redo logs must be archived before the data can be applied to the standby databaseThe size of a standby redo log must exactly match the primary database online redo logs.Number of a standby redo log groups: minimally one more standby redo log group than the primary database

Standby Redo Log에 대해서 좀 더 자세히 알아보도록 하겠습니다.

Data Guard가 maximum protection mode나 maximum availability mode일 경우는 반드시 standby redo log를

사용합니다.

-Primary database의 Log Writer process(LGWR)가 전송한 redo log를 Standby database의 Remote File

Service process(RFS)가 받아서 standby redo log에 저장합니다.

-변경 data들이 standby database에 적용되기 위해서는 먼저 standby redo log를 archiving하여야 합니다.

즉 standby redo 안의 내용은 archived redo log의 형태를 거쳐서 standby database에 적용되게 된다는

의미입니다. 그러므로 standby database는 반드시 Archiver process가 활성화 되어 있어야 합니다.

이를 위해서 LOG_ARCHIVE_START=TRUE를 항상 설정해 주시길 권장합니다.

또한 Standby database의 ARCn 에 의해서 생성되는 archived redo log는 LOG_ARCHIVE_DEST_n 에 정의되어

있는 destination에 생성되며 file name은 LOG_ARCHIVE_FORMAT의 설정에 따릅니다.

-Standby redo log의 크기는 는 primary database의 online redo log 크기와 정확히 일치해야 합니다.

- 그러나 standby redo log group의 개수는 최소한 primary database의 online redo log group보다 1개 더

많도록 설정합니다. 경우에 따라서는 1개 이상 더 추가할 수도 있습니다.

- Creating Standby Redo Log Groups

SQL> ALTER DATABASE ADD STANDBY LOGFILE

2> (’/oracle/dbs/log1c.rdo’,’/oracle/dbs/log2c.rdo’) SIZE 500K;

SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 10

2> (’/oracle/dbs/log1c.rdo’,’/oracle/dbs/log2c.rdo’) SIZE 500K;

- Adding Standby Redo Log Members to an Existing Group

SQL> ALTER DATABASE ADD STANDBY LOGFILE MEMBER ’/oracle/dbs/log2b.rdo’ TO GROUP 2;

- Standby Redo log 생성시 고려해야 할 것

-MAXLOGFILES

-LOG_FILES

-MAXLOGMEMBERS

Oracle9i Data Guard


Log Transport Services Capabilities: Reception continued

Storage Locations for Archived Redo LogsSTANDBY_ARCHIVE_DEST(RFS)LOG_ARCHIVE_FORMAT

Storage Locations for Standby Redo LogsLOG_ARCHIVE_DEST_n ( ARCn)LOG_ARCHIVE_FORMAT

Writing Redo Data to DiskLog archiving disk write I/O operations: Sync or Async[NO]AFFIRM

Primary database에서 ARCn 가 redo를 전송하면 Standby database에서 RFS process가 이를 받아

Archived redo log의 형태로 Archive destination 에 저장하게 됩니다. 이때 저장될 archive destination은STANDBY_ARCHIVE_DEST을 통해서 설정됩니다.

Standby redo log의 내용은 ARCn 을 통해서 archiving되어지며 이때 LOG_ARCHIVE_DEST_n 에 설정된

Destination에 Archived redo log가 생성됩니다.

Log archiving disk write I/O operation은 Synchronous 하게 또는 Asynchronous하게 수행될 수 있습니다.

즉 Primary database에서 전송한 redo data가 Standby database쪽의 network buffer에 까지 도달 후에

이것이 synchronous 방식으로 disk에 write 되거나 또는 asynchronous 방식으로 disk에 write 될 수 있습니다.

Primary database의 LOG_ARCHIVE_DEST_n 안에 AFFIRM 또는 NOAFFIRM attribute를 사용하여 이와 같은

사항을 설정할 수 있습니다.

LOG_ARCHIVE_DEST_2=’SERVICE=stby MANDATORY LGWR SYNC AFFIRM’

Oracle9i Data Guard


Log Transport Services Capabilities: Failure Resolution

Retrying the archiving operation to a failed destination after a specified period of time, up to a limited number of times

REOPEN attributeMAX_FAILURE attribute

Using an alternate or substitute destinationALTERNATE attribute

Primary database로부터 Standby database로의 log archiving이 실패하는 경우 Primary database에서 어떠한

Action들이 취해져야 하는지를 기술합니다.

Primary database로부터 취해질 수 있는 action들은 다음과 같습니다.

1) 실패한 Destination에 대하여 일정 주기로 archiving operation을 재시도 합니다.

이때 재시도의 최대 횟수를 지정할 수 있습니다.

- REOPEN : remote destination에 대한 archiving이 실패 후에 재시도하기 위해 기다려야 하는

최소한의 Interval. Default값은 300초 이다.

- MAX_FAILURE : 한 Destination에 대하여 실패할 수 있는 최대 archiving operation의 횟수

LOG_ARCHIVE_DEST_1=’LOCATION=/arc_dest REOPEN=5 MAX_FAILURE=3’

2) 다른 Destination으로 대체하여 archiving을 하도록 합니다.

- ALTERNATE : archiving 실패 시에 alternate destination에 archiving하도록 합니다.

LOG_ARCHIVE_DEST_1=’LOCATION=/disk1 MANDATORY ALTERNATE=LOG_ARCHIVE_DEST_2’

LOG_ARCHIVE_DEST_STATE_1=ENABLE

LOG_ARCHIVE_DEST_2=’LOCATION=/disk2 MANDATORY’


LOG_ARCHIVE_DEST_STATE_2=ALTERNATE

Oracle9i Data Guard


Log Transport Services Interfaces

Database Initialization ParametersLOG_ARCHIVE_DEST_n

SQL InterfaceALTER SYSTEM[SESSION] SET ….

Log Transport Services 에 대한 설정은 LOG_ARCHIVE_DEST_n 을 사용하여 이루어 집니다.

이 Parameter는 Initialization prarameter로 설정되어 database restartup시에 수행될 수도 있고

‘ALTER SYSTEM SET’ 과 같은 SQL command로 dynamic하게 설정될 수도 있습니다.

LOG_ARCHIVE_DEST_n 안에 기술될 수 있는 많은 attribute들은

‘Oracle9i R2 Data Guard Concept and Administration” document, Chapter 12를 참조 하시기 바랍니다.

Example Modifying Destination Parameters at the System and Session Level

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_6=’SERVICE=stby REOPEN=8’;

SQL> ALTER SESSION SET LOG_ARCHIVE_DEST_6=’SERVICE=stby2 REOPEN=10’;

Example Adding Destination Attributes Incrementally

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_6=’SERVICE=stby1 REOPEN=8’;

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_7=’SERVICE=stby2 NOREOPEN’;

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_6=’MANDATORY LGWR DELAY’;

Example Clearing a Destination Specification

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_6=’SERVICE=stby1 REOPEN=8’;

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_7=’SERVICE=stby2 NOREOPEN’;

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_6=’’;

Oracle9i Data Guard


Configuring Log Transport Services & Protection Modes

Physical and logicalPhysical and logicalPhysicalDatabase type

Required for hysicalstandby databases using the LGWR process

Required for physical standbydatabases only

YesStandby redo logsrequired?

NOAFFIRMAFFIRMAFFIRMDisk write option

ASYNC when using LGWR process. Not applicable when using ARCH process

SYNCSYNCNetwork transmissionmode

LGWR or ARCHLGWRLGWRRedo archival process

Maximum Performance

Maximum Availability

Maximum Protection

1) Maximum Protection mode

LOG_ARCHIVE_DEST_3=’SERVICE=stby1 LGWR SYNC AFFIRM’


SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTEXTION;

2) Maximum Availability mode

LOG_ARCHIVE_DEST_3=’SERVICE=stby1 LGWR SYNC AFFIRM’


SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY;

3) Maximum Performance mode

LOG_ARCHIVE_DEST_3=’SERVICE=stby1 LGWR ASYNC NOAFFIRM’


or

LOG_ARCHIVE_DEST_3=’SERVICE=stby1’


SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;

Oracle9i Data Guard


Log Transport Services MonitoringGathering Redo Log Archival Information

Step 1 Determine the current redo log sequence numbers.

Step 2 Determine the most recently archived redo log.

Step 3 Determine the most recently archived redo log file at each destination.

Step 4 Find out if logs have been received at a particular site.

Step 5 Trace the progression of archived redo logs on thestandby site.

Step 1 Current Redo Sequence를 얻기 위해 Primary database에서 다음 Query 수행

SQL> SELECT THREAD#, SEQUENCE#, ARCHIVED, STATUS FROM V$LOG;

THREAD# SEQUENCE# ARC STATUS

--------------- --------------------- ------- ------------

1 947 YES ACTIVE

1 948 NO CURRENT

Step 2 Primary database에서 가장 최근의 Archived redo log를 찾는다

SQL> SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG;

MAX(SEQUENCE#)

-----------------------------

947

Step 3 Primary database에서 다음과 같은 Query를 수행하여 각 Destination 별로 가장 최근의

Archived redo log를 찾습니다.

SQL> SELECT DESTINATION, STATUS, ARCHIVED_THREAD#, ARCHIVED_SEQ#

2> FROM V$ARCHIVE_DEST_STATUS

3> WHERE STATUS <> ’DEFERRED’ AND STATUS <> ’INACTIVE’;

DESTINATION STATUS ARCHIVED_THREAD# ARCHIVED_SEQ#

----------- --------- ------------------ ----------------

/private1/prmy/lad VALID 1 947

standby1 VALID 1 947

Note: STATUS의 값이 ‘VALID’가 아닌 경우는 해당 Destination에 archiving이 실패했다는 것을 의미

Oracle9i Data Guard

Step 4 특정 Destination 에서 전송 받지 못한 log가 있는 지를 찾는다.

Local Destination ID를 1 Remote Destination ID를 2라고 가정한다

SQL> SELECT LOCAL.THREAD#, LOCAL.SEQUENCE#

FROM (SELECT THREAD#, SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=1)

LOCAL

WHERE LOCAL.SEQUENCE# NOT IN (SELECT SEQUENCE#

FROM V$ARCHIVED_LOG

WHERE DEST_ID=2 AND THREAD# = LOCAL.THREAD#);

THREAD# SEQUENCE#

---------------- ---------------------1 121 131 14

Step 5 Standby database쪽으로의 redo archiving 진행 과정을 살펴 보려면 LOG_ARCH_TRACE parameter를

Primary와 Standby database 양쪽에 설정해야 합니다.

Oracle9i Data Guard


Log Apply Services:Standby database mode

Managed recovery modeIn this mode, log transport services archive logs to the standby site, and log apply services automatically apply these logs

Read-only modeIf you want to use the standby database for reportingpurposes, then open it in read-only mode in a Data Guard environment.

Physical Standby database는 managed recovery mode와 read-only mode 두 가지로 운영될 수 있습니다.

Managed recovery mode상에서 Log Transport Services는 redo log를 standby site에

archiving하고 Log Apply Services는 자동으로 이 log들을 standby database에 적용합니다.

Reporting 목적으로 Standby database를 사용하기 원하는 경우는 standby database를 Read-Only mode로

Open할 수 있습니다. Read-only mode로 open되면 Read-only mode가 유지되는 동안에는

Log Apply Services가 archived redo log를 standby database에 적용할 수 없습니다.

Read-only mode로 open되어 있는 동안에도 Standby database는 계속해서

Primary database로부터 Archived redo log를 받습니다.

Oracle9i Data Guard


Log Apply Services:Architecture

PrimaryDatabase

Physical/Logical Standby

DatabaseTransactions

Backup /Reports

LGWR(Synchronous/Asynchronous) MRP/ LSP

Online Redo Logs

ARCH(Synchronous)

RFS

StandbyRedo Logs

Affirm/NoAffirm

ARCH

FAL

Archived Redo Logs Archived Redo Logs

Oracle Net

Transform Redo to SQLfor SQL Apply

Log Apply Services는 자동으로 archived redo log를 적용함으로써 Primary database와 Standby database를

동기화 시킵니다.

Log Transport Services를 통하여 전송된 redo data는 Archived redo log 또는 standby redo log 형태로

저장됩니다. 그리고 Log Apply Services는 이렇게 저장된 redo data를 Standby database에 적용합니다.

Archived redo log 형태로 저장된 redo log는 Managed Recovery Process(MRP)에 의하여 Read되어

Standby database에 바로 적용됩니다.

그러나 Standby redo log 형태로 저장된 redo log는 Archiver process에 의하여 archiving된 후에 Managed

Recovery Process에 의해 read되어 standby database에 적용됩니다.

그러므로 standby redo log를 사용하는 경우 standby database는 반드시 archiver process를 start시켜야

합니다.

이를 위해서 LOG_ARCHIVE_START=TRUE를 설정 하십시요

FAL Client와 FAL Server는 primary database와 standby database사이의 archive gap을 자동으로 detect하여

해결해 줍니다.

Oracle9i Data Guard


Log Apply Services:Processes

Archiver process(ARCn)If standby redo logs are being used, the ARCn process archives the standby redo logs that are to be applied by the managed recovery process.

Managed recovery process (MRP)The managed recovery process (MRP) applies information from the archived redo logs or standby redo logs to the standby database.

Standby redo log가 사용되면 Standby database의 ARCn process가 standby redo log를 archiving하는

역할을 담당하며 이때 생성된 archived redo log는 Managed Recovery process(MRP)에 의해 Read되어

Standby database에 적용되게 됩니다.

Managed recovery process(MRP)는 Primary database에서 Log Transport Services를 통하여 전송된

Redo data를 Standby database에 적용하는 역할을 합니다. Log Transport Services를 통하여 전송된

Redo data의 형태가 archived redo log 또는 standby redo log 이지만 MRP는 오직 archived redo log 형태의

Redo data만을 read하여 standby database에 적용합니다. 그러므로 standby redo log 안의 내용이 standby

database에 적용되기 위해서는 반드시 archiving 작업이 선행되어야 합니다.

Oracle9i Data Guard


Log Apply Services:Starting Managed Recovery

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE;

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

Log Apply Services는 Foreground session으로서 수행될 수도 있고 background process로 수행될 수도

있습니다.

1) Foreground session 을 시작하기 위해서는 다음과 같은 명령을 수행해야 합니다.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE;

Foreground session을 시작하면 기본적으로 control이 command prompt 상으로 되돌아 오지 않습니다.

2) Background process를 시작하기 위해서는 ‘DISCONNECT’ keyword를 사용해야 합니다.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

이 명령은 분리된 서버 프로세스를 시작하여 즉시 control을 사용자에게 반환합니다.

Managed recovery process가 background로 recovery를 수행하는 동안 RECOVER 명령을

수행시켰던 foreground process는 다른 작업을 수행할 수 있습니다. 이것은 current SQL session을

disconnect시키지 않습니다.

3) 만약 분리된 서버 프로세스(detached server process)로 log apply services를 시작하지 않았다면 다음과 같은

명령으로 log apply services를 정지시킬 수 있습니다.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

Oracle9i Data Guard


Log Apply Services:Monitor the recovery process.

V$MANAGED_STANDBY

SQL> SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS2> FROM V$MANAGED_STANDBY;

PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS---------------- ----------------- ---------------- --------------------- ------------- ------------

RFS ATTACHED 1 947 72 72MRP0 APPLYING_LOG 1 946 10 72

Physical Standby database에서 log apply services와 log transport services를 monitoring하기 위해서

V$MANAGED_STANDBY 를 Query합니다.

SQL> SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS

2> FROM V$MANAGED_STANDBY;

PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS

-------- ------------ -------- ---------- ------- --------

RFS ATTACHED 1 947 72 72

MRP0 APPLYING_LOG 1 946 10 72

RFS process가 redo log file sequence number 947에 대한 archiving을 완료했음을 알 수 있습니다.

Archived된 redo log sequence number 946이 Managed recovery operation에 의해 현재 적용되고 있음을

알 수 있습니다. Recovery operation은 72 block의 archived redo log중 10번 block을 현재 recovering하고

있습니다.

Log apply services가 올바르게 시작되었는지를 검증하기 위해서 Standby database에 있는

V$MANAGED_STANDBY fixed view를 Query 하십시요. 이 view는 managed recovery mode에 있는 Standby

database의 recovery process를 monitoring합니다.

SQL> SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS

2> FROM V$MANAGED_STANDBY;

PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS

-------- ------------ --------- ----------- -------- ----------

MRP0 APPLYING_LOG 1 946 10 1001

Oracle9i Data Guard


Log Apply Services:Datafile Management

When set to auto, this parameter automates the creation and deletion of datafile filenames on the standby site using the same filenames as the primary site.

STANDBY_FILE_MANAGEMENT

Converts primary database redo log filenames to standby database redo log filenames, for example, from log_* to standbylog_*.

LOG_FILE_NAME_CONVERT

Converts primary database datafilefilenames to standby datafile filenames, for example, from tbs_* to standbytbs_*.

DB_FILE_NAME_CONVERT

FUNCTIONPARAMETER

Primary database에서 datafile이 생성될 경우 physical standby database에서 자동으로 new datafile이

생성되도록 하기 위해서는 STANDBY_FILE_MANAGEMENT=AUTO가 설정되어야 합니다.

만약에 primary와 standby database의 directory 구조가 다르면 DB_FILE_NAME_CONVERT parameter를

사용하여 convert시킬 수 있습니다.

DB_FILE_NAME_CONVERT= "/disk1/oracle/oradata/payroll/df1", ₩

"/disk1/oracle/oradata/payroll/standby/df1", ₩

"/disk1/oracle/oradata/payroll", "/disk1/oracle/oradata/payroll/standby/"

STANDBY_FILE_MANAGEMENT=AUTO

Physical standby database에서 STANDBY_FILE_MANAGEMENT의 값이 AUTO로 설정되어 있으면

다음과 같은 명령문은 허용되지 않습니다.

ALTER DATABASE RENAME

ALTER DATABASE ADD/DROP LOGFILE

ALTER DATABASE ADD/DROP STANDBY LOGFILE MEMBER

ALTER DATABASE CREATE DATAFILE AS

Oracle9i Data Guard


Data Guard Gap Detection and Resolution

What Is an Archive Gap?

Methods of Gap Resolution:

Automatic Gap Resolution

FAL (Fetch Archive Log) Gap Resolution

Archive Gap이란 Standby database가 primary database에서 생성된 archived redo log를 전송 받지

못했을 경우 발생하게 되는 missing archived redo log들을 의미합니다.

Data Guard는 Automatic 과 FAL(Fetch Archive Log), 두 가지의 Gap Resolution 을 제공합니다.

Automatic 방식은 별다른 설정(configuration)이 필요 없습니다. 그러나 FAL의 경우는 init.ora 안에

FAL_CLIENT와 FAL_SERVER를 설정을 해 주어야만 합니다.

이제 이 두 가지 Gap resolution에 대해서 자세히 알아 보도록 하겠습니다.

Oracle9i Data Guard


Automatic Gap Resolution

Implemented during log transport processing

The sequence number of the log being archived is compared tothe last sequence received by the RFS process on the standby

The ARCH process on the primary sends the missing logs tothe standby and notifies the LGWR that the gaps have beenresolved

The ARCH process on the primary database polls all standbydatabases every minute ( Enhanced in oracle9i R2)

Automatic Gap Resolution은 Log transport processing 동안 구현되어 집니다.(9.0.1 and 9.2.0) Primary

database의 LGWR 또는 ARCH가 redo data를 standby database에 전송하고 이를 Standby database의 RFS가

받게 되는데 받는 동안 RFS는 현재 받고 있는 log의 sequence번호와 이미 받은 마지막 log sequence 번호를

비교합니다.

만약에 RFS가 현재 받고 있는 log sequence 번호가 last log sequence +1 보다 크다는 것을 발견하면

Primary에게 missing archive log를 전송해 줄 것을 요청(piggyback) 합니다.

Missing archive log를 요청하는 standby destination은 이미 primay database의 LOG_ARCHIVE_DEST_n

에 정의 되어 있기 때문에 primary database의 ARCH process가 standby에 log를 전송하고 Gap이 해결되었다는

것을 LGWR에게 알립니다.

Data Guard 9.2부터 Automatic Gap Resolution이 좀더 향상되었습니다 .

위에 이미 기술된 것 외에 primary database상의 ARCH process는 모든 standby database 상에 archive gap이

있는지를 check하기 위해서 매 분마다 polling합니다.

만약 Gap이 발견되면 ARCH process가 missing archived redo log를 전송 합니다.

Gap이 해결되면 해당 site가 최신으로 update되었음을 LGWR에게 알립니다.

Oracle9i Data Guard


FAL Gap Resolution

MRP sees the update to the controlfile, it attempts to recover that fileIf the MRP process finds that the archived log is missing or iscorrupt, FAL is called to resolve the gap or obtain a new copySince MRP has no direct communications link with the primary, it must use the FAL_SERVER and FAL_CLIENT to resolve thegapBoth of these parameters must be set in the standby init.ora.

FAL_SERVERFAL_CLIENT

Standby database의 RFS가 archived log를 받으면 archived log file name과 location을 standby controlfile

안에 update합니다.

MRP는 controlfile 상의 update를 보고 recovery를 시도합니다.

만약에 MRP가 archived log가 missing이거나 corrupt되었다는 것을 발견하면 Gap 을 해결하거나 new copy를

얻기 위해서 FAL이 호출됩니다.

MRP는 primary와 direct communication link를 가지고 있지 않기 때문에 반드시 FAL_SERVER 와

FAL_CLIENT parameter를 init.ora안에 설정해야 합니다.

이 두 parameter 모두 standby의 init.ora 안에 설정되어야 합니다.

이 두 parameter에 대한 정의는 다음과 같습니다.

- FAL_SERVER : primary database listener를 가리키고 있는 OracleNet service name으로서

standby tnsnames.ora 안에 존재한다.

또한 comma로 구분하여 여러 개의 OracleNet service name을 기술할 수 있다.

- FAL_CLIENT : standby database listener를 가리키고 있는 OracleNet service name으로서

primary tnsnames.ora 안에 존재한다.

MRP 가 gap을 발견하면 Primary database를 call하기 위해서 FAL_SERVER에 정의되어 있는 Value를 사용한다.

일단 Primary와의 communication이 확립되면 MRP process는 FAL_CLIENT value를 Primary ARCH

process에게 전달한다. Primary ARCH process는 해당 remote archive destination을 찾아서 Missing archived

redo log를 전송한다. 만약 FAL_SERVER에 나열된 first destination에서 gap을 해결할 수 없다면 다음

destination이 시도된다.

9.2.0 현재까지 FAL Gap Resolution은 오직 Physical Standby database에서만 유효하다.

Oracle9i Data Guard


Manually Resolving a Gap

Query the V$ARCHIVE_GAP view

After you identify the gap, query the V$ARCHIVED_LOG on the primary database to locate the archived redo logs onyour primary database:

Copy the logs returned by the query to your physicalstandby database and register using the ALTER DATABASE REGISTER LOGFILE command

Restart the MRP process.

앞에서 언급한 바와 같은 두 가지 Gap resolution에 의해 대부분은 자동으로 Gap을 해결하게 됩니다.

그러나 부득이하게 manual하게 gap을 해결해야 하는 경우는 다음과 같은 절차를 수행합니다.

1) V$ARCHIVE_GAP view를 query합니다.

SQL> SELECT * FROM V$ARCHIVE_GAP;

THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#

--------------- ----------------------------- -----------------------------

1 443 446

위 Query 결과는 Thread 1에 대해서 Sequence 443에서 446까지 missing archive file들 존재하고 있음을

의미하고 있습니다.

2) Gap을 확인한 후에는 missing archive file들이 primary database의 어디에 위치하고 있는지를 찾기 위해서

다음과 같은 SQL문을 수행합니다.

SQL> SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1 AND DEST_ID=1 AND

2> SEQUENCE# BETWEEN 443 AND 446;

NAME

-----------------------------------------------------------------

/u01/oradata/arch/arch_1_443.arc



Oracle9i Data Guard

3) 위 Query에 나타난 archive file들을 모두 primary에서 standby로 copy한 후에

ALTER DATABASE REGISTER LOGFILE 명령을 사용하여 등록합니다.

SQL> ALTER DATABASE REGISTER LOGFILE '/u01/oradata/stby/arch/arch_1_443.arc';



4) Missing archive file들이 모두 standby controlfile안에 등록 되면 MRP process를 다시 시작합니다.

Oracle9i Data Guard


Role Management Services

Database Roles and Role Transitions

Database Switchover

Database Failover

Database는 상호 배제적인 ‘PRIMARY’ 또는 ‘STANDBY’ Role중 하나로 운영됩니다.

Data Guard는 SQL 명령을 통하여 동적으로 이 Role들을 변경하는 것을 허용합니다.

Oracle Data Guard 는 다음 두 가지 Role transition operation을 지원합니다.

- Switchover

primary database와 standby database중 하나 사이에 role을 서로 교환하는 operation

- Failover

primary database의 failure로 인해 standby database를 primary role로 변경하는 operation.

Oracle9i Data Guard



Failover Operation

1. Previously, this was the only way to move the primary processing role to the standby

2. Failover was often only performed as a result of an unplanned outage of the primary

3. The primary had to be discarded and could not be used as the new standby

4. The system was at risk during the time taken to create a new standby

Failover에 대해서 알아보도록 하겠습니다

1. Oracle9i 이전 버전에서는 standby database의 role을 primary로 바꿀 수 있는 유일한 방법이었습니다.

2. Primary database의 예측치 못한 사용 불능의 결과로서 종종 수행되었습니다.

3. Failover 수행 후에는 기존의 Primary database는 필요 없으므로 반드시 삭제해야 합니다.

4. 새로운 standby database를 구성하는 동안 primary database는 잠시 risk 상황에 머물게 됩니다.

Oracle9i Data Guard



Switchover Operation

In Oracle9i, primary and standby database can continueto alternate rolesThis is a planned operation unlike failoverNo need to recreate a new standby every time theswitch is performedSwitchover is possible if all these conditions are met:

The primary performs a graceful shutdownThe archive logs are availableThe primary’s online logs are available

Switchover에 대해서 알아보도록 하겠습니다.

1) Oracle9i Data Guard에서는 primary와 standby database가 서로 role을 바꿀 수 있습니다.

2) Switchover는 planned operation을 위해 사용되어 질 수 있습니다.

3) Switching이 발생할 때마다 새로운 standby database를 생성할 필요가 없습니다.

4) 다음과 같은 조건을 만족할 때 switchover를 수행할 수 있습니다.

- Primary가 graceful shutdown을 하였을 경우

- Archive log가 모두 사용 가능한 경우

- primary database의 online redo log가 모두 사용 가능한 경우

Oracle9i Data Guard


Role Management Services:Switchover Steps(1)

On the current primary database

Step 1 Verify that it is possible to perform a switchover operation.

Step 2 Initiate the switchover operation on theprimary database.

Step 3 Shut down and restart the formerprimary instance.

Switchover operation을 수행하는 과정은 다음과 같습니다.

1단계) Switchover operation이 수행 가능한 상태인지를 살펴 본다.

Primary database에서 V$DATABASE fixed view의 SWITCHOVER_STATUS의 값이

‘TO STANDBY’이면 이 primary database은 standby database로 switchover가능함을

의미합니다.

2단계) primary database에서 switchover operation 명령문을 수행합니다.

Primary database를 primary role에서 standby role로 변경하기 위해서 아래 명령문을

실행합니다.

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;

위 명령문의 수행이 완료되면 primary database는 standby database로 전환됩니다.

그리고 switchover operation전에 current control file이 SQL session trace file 형태로 backup 됩니다.

3단계) Standby role로 변경된 primary database를 shutdown 하고 restart 합니다.

SQL> SHUTDOWN IMMEDIATE;

SQL> STARTUP NOMOUNT;

SQL> ALTER DATABASE MOUNT STANDBY DATABASE;

Switchover 과정 중 이 시점에서는 모든 database가 physical standby database가 됩니다.

Oracle9i Data Guard


Role Management Services:Switchover Steps (2)

On the target physical standby database

Step 4 Verify the switchover status in theV$DATABASE view.

Step 5 Switch the physical standby database roleto the primary role.

Step 6 Shut down and restart the newprimary database.

Switchover operation 수행 과정에서 Standby database에서 수행되는 과정을 살펴 봅니다.

단계 4) V$DATABASE에서 standby database의 switchover status를 살펴 봅니다.

Primary database가 standby database로 switchover 되면 이에 대한 변경이 Target standby

database에게 통보되어지게 됩니다.

그리고 이때 standby database의 SWITCHOVER_STATUS의 값은 ‘SWITCHOVER PENDING’

으로 바뀝니다.

‘SWITCHOVER PENDING’은 standby database가 standby role에서 primary role로 이제 막

switching되기 시작했다는 의미입니다.

단계 5) Physical standby database role을 primary role로 전환 합니다.

Physical standby database를 standby role에서 primary role로 전환하기 위해서는

manged recovery mode로 mount되어 있거나 read-only mode로 open되어 있어야 합니다.

다음은 이를 수행하는 명령문입니다.

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

위 명령문 수행시에 online redo log가 존재하지 않는다면 자동으로 online redo log를

생성시켜 줍니다. 그러나 oracle은 이보다는 미리 manual 하게 online redo log를

추가시켜 주실 것을 권장합니다.

6단계) Target standby database를 적절한 initialization parameter들과 함께 restartup 합니다.

SQL> SHUTDOWN;

SQL> STARTUP;

Physical standby database는 이제 primary database role로 전환됩니다.

Oracle9i Data Guard


Role Management Services:Switchover Steps(3)

On the new physical standby database

Step 7 Start managed recovery operations and log apply services.

On the new primary database

Step 8 Begin sending redo data to the standbydatabases.

7단계) 이제 새로운 physical standby database에서는 managed recovery operation과 log apply services를

시작합니다.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

8단계) 이제 새로운 primary database에서는 standby database로 redo data를 전송하기 시작합니다.

SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;

Oracle9i Data Guard


Role Management Services :Failover Steps(1)

Step 1 Identify and resolve any archived redo log gaps.

Step 2 Copy any other missing archivedredo logs.

Step 3 Repeat steps 1 and 2.Step 4 Initiate the failover operation on the

target physical standby database.Step 5 Convert the physical standby

database to the primary role.

Primary database의 장애로 인해 primary database를 더 이상 사용할 수 없게 된 경우에는 Failover를 통해

서비스를 계속할 수 있습니다.

다음은 Failover를 수행하는 과정입니다

단계1) Archived redo log gap을 찾아 이를 해결합니다.

다음 SQL문을 통하여 archived redo log gap을 확인합니다.

SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;

THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#

---------------- ------------------------------ ---------------------

1 90 92

위 Query 결과를 보면 Gap은 archive log 90, 91, 92로 이루어짐을 알 수 있습니다.

가능한 한 이 모든 archived redo log file을 target standby database에 복사하고

이를 등록(register)해야 합니다. 이 모든 것은 각 Thread 단위로 수행되어야 합니다.

SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE ’filespec1’;

Oracle9i Data Guard

2단계 ) 다른 missing archived redo log가 있는지를 점검하고 가능한 한 이를 target standby database에

복사하여 등록합니다.

SQL> SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#)

2> OVER (PARTITION BY thread#) AS LAST from V$ARCHIVED_LOG;

THREAD LAST

------------- ----------

1 100

현재 사용 가능한 모든 database에서 target standby database보다 더 큰 sequence 번호를

가진 archived redo log가 있다면 이를 모두 target standby database에 복사하여 등록 합니다.

SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE ’filespec1’;

3단계) Gap이 없어질 때까지 가능한 한 1단계와 2단계를 반복적으로 수행한다.

4단계) Target physical standby database 상에서 failover operation을 수행합니다.

target standby database가 standby redo log로 구성되어 있고 아직 partial archived redo log 를

manual하게 등록하지 않았다면 다음과 같은 명령문을 수행합니다.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;

standby redo log 안의 paritial archived redo log를 skip한다면 아래와 같은 명령문을 사용합니다.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH

2> SKIP STANDBY LOGFILE;

5단계) Physical standby database를 primary role로 변경합니다.

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

이 명령문 수행 후에는 이 database는 더 이상 standby database로서 사용할 수 없습니다.

original primary database의 redo log도 더 이상 적용될 수 없습니다.

standby redo log는 archived되어 나머지 standby database로 copy되어야 합니다.

copy된 후에는 register를 거쳐 recovery가 수행되어야 합니다.

original primary database 제거되어야 합니다. 그리고 new primary database의 backup을

사용하여 physical standby database를 새로 만들어야 합니다.

Oracle9i Data Guard


Role Management Services :Failover Steps(2)

On the primary database and all remaining standby databasesStep 6 Prepare to receive redo logs

from the new primary database.On the new primary databaseStep 7 Shut down and restart the

new primary database.Step 8 Optionally, back up the new

primary database.

6단계) 다른 standby database는 new primary database로부터 redo log를 받기 위해 준비합니다.

Archived standby redo log가 다른 모든 standby database에 적용되면 이제 이 standby database들은

new primay database로부터 redo log를 받아들일 준비를 합니다.

7단계) New primary database를 restartup합니다.

failover operation을 완료하기 위해서 new primary database를 read/write mode로

restartup 합니다. 이때 적절한

SQL> SHUTDOWN IMMEDIATE;

SQL> STARTUP;

8단계) New primary database를 backup합니다.

Oracle9i Data Guard


Miscellaneousness

1. Managing Primary Database Events That Affect the Standby Database

2. Recovering After the NOLOGGING Clause Is Specified

3. Standby Database Real Application Clusters Support

Oracle9i Data Guard


Managing Primary Database Events That Affect the Standby Database

Change Made on Primary DatabaseAdd a datafile or create a tablespaceDrop or delete a tablespace or datafileRename a datafile Add or drop online redo logsAlter the primary database control file (using the SQLALTER DATABASE CREATE CONTROLFILE statement)Perform a DML or DDL operation using the NOLOGGING or UNRECOVERABLE clauseChange initialization parameter

Oracle9i Data Guard


Change Made on Primary Database Action Required on Standby Database

Add a datafile or create a tablespace If you did not set the STANDBY_FILE_MANAGEMENTinitialization parameter to AUTO, you must copy the new datafile to the standby database.

Drop or delete a tablespace or datafile Delete the corresponding datafile after the archived redo log was applied.

Rename a datafile Rename the datafile on the standby database.

Add or drop online redo logs Synchronize changes on the standby database.

Alter the primary database control file (using the SQL ALTER DATABASE CREATE CONTROLFILE statement)

Re-create the standby control file or re-create the standby database, depending on the alteration made.

Perform a DML or DDL operation using the NOLOGGING or UNRECOVERABLE clause

Send the datafile containing the unlogged changes to the standby database.

Change initialization parameter Dynamically change the standby parameter or shut down the standby database and update the initialization parameter file.

위 내용은 Standby database에 영향을 미치는 Primary database Event들과 이 각 event들에 대해서 취해 주어야

할 Action들을 도식화 한 것입니다.

Oracle9i Data Guard


Recovering After the NOLOGGING Clause Is Specified

Step 1 Determine which datafiles should be copied.

Step 2 On the primary site, back up the datafile that you need to copy to the standby site

Step 3 On the standby database, restart managedrecovery.

Primary database에서 NOLOGGING option이 사용되었을 경우 NOLOGGING 사용시 발생한 redo log가 standby

database에 적용되었을 때 Standby database의 일부 파일들이 사용할 수 없게 되고 ‘UNRECOVERABLE’ 로

표시되게 됩니다.

Failover를 시도하거나 read-only 로 open하였을 때 ‘UNRECOVERABLE’로 marked된 block들을

Access하게 되면 다음과 비슷한 Error를 만나게 됩니다.

ORA-01578: ORACLE data block corrupted (file # 1, block # 2521)

ORA-01110: data file 1: '/oracle/dbs/stdby/tbs_1.dbf'

ORA-26040: Data block was loaded using the NOLOGGING option

Primary database에서 NOLOGGING option을 사용하여 작업하였을 경우 Standby database에서 이를

recovery하기 위해서는 해당 datafile을 copy해야만 합니다.

Recovery 과정은 다음과 같습니다.

Oracle9i Data Guard

1단계) Primary database로부터 어떠한 datafile이 copy되어야 하는지를 결정합니다.

a. Primary database에서 아래의 SQL문을 실행 합니다.

SQL> SELECT NAME, UNRECOVERABLE_CHANGE# FROM V$DATAFILE;

NAME UNRECOVERABLE

---------------------------- ------------------------------

/oracle/dbs/tbs_1.dbf 5216




b. Standby database에서 아래의 SQL문을 실행합니다.

SQL> SELECT NAME, UNRECOVERABLE_CHANGE# FROM V$DATAFILE;

NAME UNRECOVERABLE

--------------------------- -----------------------------





c. UNRECOVERABLE_CHANGE# 의 값을 비교하여 primary database의 값이 더 큰 datafile들을

copy하면 된다.

2단계) Primary database에서 해당 datafile을 backup하여 standby database로 copy한다

SQL> ALTER TABLESPACE system BEGIN BACKUP;

SQL> EXIT;

% cp tbs_1.dbf /backup

SQL> ALTER TABLESPACE system END BACKUP;

3단계) Standby database에서 managed recovery를 재 수행한다.

managed recovery 수행시 ORA-00308: cannot open archived log ’ ’ Error를 만날 수 있는데

이것은 archive log gap으로 인해 발생한 것입니다. Manual 하게 archive gap을 해결하면

이 문제는 자동으로 해결됩니다.

Oracle9i Data Guard


Standby Database Real Application Clusters Support

Configuring Standby Databases in a RAC

Instance Combinations

Single-Instance StandbyDatabase

Multi-Instance Standby Database

Single-Instance PrimaryDatabase

Yes Yes( for read-only queries)

Multi-Instance PrimaryDatabase

Yes Yes

Real Application Cluser(RAC)로 구성되어 있는 Primary database에 대해 standby database를 구성하고자

할 때 Single-instance standby database 와 multiple-instance standby database 모두 구성될 수 있습니다.

Oracle9i Data Guard


Multi-Instance Primary Database with a Single-Instance Standby DB

위의 경우는 2개의 primary database instance를 가진 RAC가 single-instance standby database에

Redo log를 archiving하는 경우 입니다.

이 경우 primary database의 instnace 1이 log 1,2,3,4,5를 전송하고 반면에 instance 2는 Log 32, 33, 34,35,36

을 전송합니다.

Standby database가 managed recovery mode 이면 양 primary instance에서 전송된 archived redo log들에

대해서 적용할 올바른 순서를 자동으로 결정합니다.

Oracle9i Data Guard


Multi-Instance Primary Database with a Multi-Instance Standby DB

RAC 상에 있는 Standby database는 다음 두 가지 형태의 instance를 가지게 됩니다.

- Receiving instance

: Primary database로부터 archived log를 받을 수 있는 instance

- Recovery instance

: managed recovery operation을 수행하는 node의 instance

이 node에 의하여 모든 archived log들 access 가능하여야 합니다.

Receiving instance에서 Recovery instance로 standby database archived log를 전송하기 위해

Cross-instance archival operation을 사용합니다.

Standby database cross-instance archival operation은 primary database archived log의 임시 저장소로서

Standby redo log를 사용합니다.

Oracle9i Data Guard


Standby Database Real ApplicationClusters Support

To set up a standby database in a RAC Create the standby redo logs.On the recovery instance where the managed recovery process (MRP) is to operate, define the archived log destination to archive locally, because cross-instancearchiving is not necessary.

On the receiving instance, define the archived log destination to archive to the node where the MRP is to operate.Start the ARCn process on all standby database instances.Start the MRP on the recovery instance.

RAC 환경 상에서 standby database를 구성하고자 한다면 다음과 같은 과정을 수행해야 합니다.

1. Standby redo log를 생성합니다.

standby redo log는 RAC의 모든 instance에서 access가능한 disk device 상에 위치해야 합니다.

2. Recovery instance 상에서는 archived log destination을 Local directory로 지정합니다

Recovery instance는 managed recovery process가 redo log는 적용하는 instance입니다.

이 경우는 cross-instance archiving이 필요 없습니다.

LOG_ARCHIVE_DEST_1=‘LOCATION=/home/oracle’

3. Receiving instance에서는 archived log destination을 MRP가 동작하는 node로 지정합니다.

이때에 cross-instance archiving이 필요합니다.

LOG_ARCHIVE_DEST_1=‘SERVICE=stanby1’

4. 모든 standby database instance상에서 ARCn 를 시작합니다.

5. Recovery instance에서 MRP 를 시작합니다.

Oracle9i Data Guard


Standby Database Real ApplicationClusters Support

To set up a primary database in a RAC

On all instances, designate the LGWR process to perform the archival operation.

Designate the standby database as the receiving node.

RAC 환경 상에서 primary database의 설정은 다음과 같습니다.

1. Primary database의 모든 instance에서 LGWR이 archival operation을 수행하도록 설정합니다.

LGWR을 설정해야 standby database에서 standby redo log에 redo를 저장하게 되고

그럼으로서 cross-instance archiving을 수행할 수 있게 된다.

2. Standby database를 receiving node로 설정합니다.

Documents

Standby Database와 Physical Data Guard - dbguide.net · Oracle9i Data Guard Standby database and Physical Data Guard 기술적인질문은채팅으로 이희열, 이은지, 문상준