•Oracle Database 10g Release 2
<Insert Picture Here>
•EM 을 이용한
Oracle Data Guard 구성방안
EM 을 이용한 오라클 DataGuard
구성방안 (RAC + EM + DataGuard)
Oracle Korea
Agenda
• 1. 제안 개요
• 2. 제안 솔루션 소개
• 가용성 보장을 위한 Oracle RAC
• 재난복구(DR) 복제 솔루션
• 3. 구축 및 운영 방안
• EM을 이용한 DataGuard 구축방안
• 4. 관리방안
• EM을 이용한 RAC 모니터링방안
• 5. 시스템 구성도
EM 을 이용한 DataGuard 시스템 구성도
• 6. 참조고객
2/67
<Insert Picture Here>
1. 제안 개요
3/67
제안 개요
• 개요
• 글로벌 기업으로서 경제의 유동성과 시장의 빠른 변화에 적응하면서 예측할 수 없는
비즈니스 장애요소에 대처하기 위함
• 일반적인 장애요소로 부터 글로벌 기업의 IT 인프라를 보호하기 위함
• 예측할 수 없는 Unplanned System down 및 예측 가능한 Planned system
down( ex: Database patch 및 Upgrade ) 상황으로부터 비즈니스의 연속성을 유지
하기 위함.
• 고객 요구사항 :
• 장애 발생시 시스템 가용성 보장을 위한 안정적인 운영 솔루션
• 두 시스템간의 Data 동기화 및 장애복구 솔루션
4/67
<Insert Picture Here>
2. 제안 솔루션 소개
5/67
제안 솔루션 소개
• 고객 요구사항 :
• 장애 발생시 시스템 가용성 보장을 위한 안정적인 운영 솔루션
• 두 시스템간의 Data 동기화 및 장애복구 솔루션
• 가용 솔루션
• Oracle RAC 솔루션
• Oracle Data Guard ( Database 복제 솔루션 )
• 오라클에서 제안하는 보광휘닉스파크 제안솔루션
• 무정지 서비스 가용성 향상을 위한 Oracle RAC
• 재난대비 복제 솔루션 Oracle DataGuard
• 관리 및 통제를 위한 Enterprise Manager Console
6/67
<Insert Picture Here>
24*365 무정지 가용성 및 확장성
보장을 위한 이중화 솔루션
- Oracle RAC
7/67
고가용성의 클러스터링기술 및 장애복구 기능:RAC
• 오라클은 고가용성 지원을 위한 틀러스터링 기술로써 오라클 클러스터
데이터베이스인 Real Application Clusters ( RAC )를 제공합니다.
• 클러스터링 기술 개요
• 오라클 RAC을 사용하면 한 노드에 장애가 발생하더라도 서비스는 지속됩니다.
• 다른 벤더의 데이타베이스를 사용하면서 프로세서의 장애와 같은 상황에 의한 서비스 다운 현상을
막기 위해서는, 별도의 SMP 서버를 구매해서 대기 상태로 두어야 할 것입니다. 이러한 구성을 cold
standby 혹은 active/passive 구성이라고 합니다. 이 구성은 단점은 장애 복구의 시간이 오래
걸린다는 것과 비용이 많이 든다는 것입니다. 그러나 오라클 RAC는 디스크를 공유하는 active/active
구성되기 때문에 서비스 다운 현상을 막을 수 있습니다.
•
장애 복구 시간
• 오라클 RAC을 사용하면 장애 복구 시간이 5~30초 혹은 수초면 됩니다.
• 오라클 RAC은 위의 복구 단계가 필요없습니다.
• 살아 있는 노드에 접속되어 있는 사용자는 그대로 해당 노드들을 사용하면 되고, 단지 장애가 발생된
노드에 접속되어 있던 사용자만 자동으로 재접속 됩니다. 이 부분에 있어서, 오라클은 사용자들을 백업
노드에 미리 접속을 시키는 기술을 제공하는데, 이 경우 재접속의 지연 시간도 제거할 수 있습니다.
마지막으로 살아 있는 노드들의 버퍼 캐쉬는 자주 액세스되는 데이터를 캐슁하고 있으므로, 곧바로
고성능에 도달하게 되는 것입니다.
8/67
고가용성의 RAC 의 가용성
• 가용성
• 물리적인 노드가 독립적으로 운영되기 때문에 하나 이상의 노드에 장애가 발생하더라도 클러스터의
여타 노드에 영향을 미치지 않습니다. (폴트 톨러런스)
• 클러스터 시스템은 단 하나의 노드만이 생존하더라도 서비스가 가능합니다. (고도의 가용성을 실현)
• 유지보수를 위해 노드 그룹이 오프라인으로 되어 있는 동안 나머지 클러스터가 서비스를 할 수
있습니다.
No Single point of Failure
Node
A
9/67
Node
B
Node A in
an RAC
cluster fails,
users are
migrated
Node
A
Node
B
고가용성의 RAC (정상운영)
 Availability 부문 – Failover 원리
• 정상 운영 환경 – Active/Active의 서비스 지원
노드 1
인스턴스 ‘A’
Active
노드 2
인스턴스 ‘B’
Active
Database
(공유 디스크)
10/67
•
•
•
•
•
모든 노드가 Active
클라이언트의 부하 분산(Load Balancing)
동일한 데이터 환경 제공 (Share Disk)
Server Failure 자동 감지
Node간의 Resource Pooling
고가용성의 RAC (장애발생)
 Availability 부문 – Failover 원리(계속)
• Server Failure 발생시 – 지속적으로 투명한 서비스 기능
TAF
노드 1
인스턴스 ‘A’
Failure
장애발생
노드 2
인스턴스 ‘B’
Still Active
•
•
인스턴스 ‘A’ 대한
Recovery를 ‘B’에서
수행(무결성 보장)
•
Database
(공유 디스크)
•
•
11/67
장애를 대비한 운영모드
1. TAF (Transparent Application Fail-Over) 를 통한 DB
세션을 자동으로 복구. Application은 Node의 장애를 감지 못함
나머지 노드가 대신 실패한 노드의 모든 작업을 분담하여 작업
지속
2. FCF(Fast Connection Failover), FAN(Fast Application
Notification)으로 5 ~ 30초 내에 모든 작업 을 정상화
모든 작업 자동 진행
RAC를 이용한 물리적 H/A 효과 – RAC
 High Availability 측면 - 물리적 구조 ( 2노드 예시)
Fast Ethernet Switch
Primary line or Active line
Fast Ethernet Switch
Second line
NIC2
NIC2
NIC0
NIC0
NIC1
NIC1
NIC5
NIC5
NIC3
NIC3
NIC4
NIC4
interconnect
interconnect
 Shared Disk Type
1. RAW device
2. Shared CFS
3. Oracle ASM
12/67
서버 뿐만 아닌 모든
H/W 장비가 고가용성을
위해 이중화 구조 권장
Gigabit
Switch
Gigabit
Switch
SAN Switch
SAN Switch
OCR
Voting Disk
노드간의 DB Buffer Cache 데이터 처리를
빠르게 하기위해 클러스터 Interconnect는
Gigabit 이상의 대역의 Switch 장비 필요
데이터베이스 시스템 데이터 및 각종 고객 데이터가
공유 디스크에 저장됨. 공유 디스크 구조로는 볼륨
매니저에 의해 관리되는 Raw device, 3th벤더의 공
유 클러스터 파일 시스템, 오라클 제공 ASM
(Automatic Storage Management)의 세가지 유형
중 선택 적용 가능
RAC를 이용한 Instance H/A 효과 – RAC
 신속한 Failover 및 Instance복구측면 - HW적 HA 절차 비교
HW적 HA 적용 시
Oracle RAC 기반의 자동 Failover
Giga bit Switch
ACTIVE
STANDBY
ACTIVE
ACTIVE
노드-2
Oracle10g
노드-3
Oracle 10g RAC
SAN Switch
1) Active시스템에서만 서비스 처리 수행
2) Active시스템 장애시 백업용(Standby)시스템으로
Failover 수행
- 백업시스템으로 복구 및 처리 절차
①
운영시스템 Disk 절체
②
Standby시스템으로 Disk Mount
③
Mount된 Disk의 File시스템 Check
④
DB Startup시 Instance Recovery 수행
⑤
DB 정상화 후 Application Start
3) Standby시스템이 Active 되어 서비스 처리 수행
최소 5분 ~ 30 분 이상 소요
13/67
1) Active-Active 시스템에서 모두 서비스 처리 수행
2) 한쪽 운영시스템 장애시 백업용(Standby)시스템으로
Failover 수행
- 장애시 복구 및 처리 절차
①
다른 Active시스템에서 장애난 Instance의
Recovery 즉시 수행
( 데이터 무결성 보장을 위해 장애난 시스템
의 미 반영된 Log 및 Undo 데이터 처리)
3) 다른 Active시스템에서 서비스 즉시 처리 수행
최소 20초 ~ 60 초 전후 소요
<Insert Picture Here>
재난복구(DR) 복제 솔루션
- Oracle DataGuard
14/67
Database 관리자의 도전과제
• Site 전체에 정전, 지진 과 같은 천재지변으로 장애가 발생했다면 대응방안은 ?
• 만일 사용자가 실수 로 Data 를 일부 또는 모두 삭제 또는 전체 Update 했다면 ?
• 노후된 disk 또는 갑작스런 instance down으로 블록 corruption이 발생했다면 ?
• 다른 복제 솔루션을 사용했더라도 Online 상의 Transaction 마지막 Data 까지
안전하게 보장 할 수 있을까 ?
• 만약 장애 발생시 복구 시도가 실패 했다면 또 다른 백업SET 은 ?
• 장애 발생시 복구수행전 장애시점의 DATA 를 백업 후 복구를 시도 하라고
권장합니다. 긴급한 장애발생시 관리자는 백업을 받아 놓고 복구를 시도 할
시간적 여유가 있을까 ?
• 장애복구 실패 시 최후의 보류는 ?
• 만약 대용량 Data 장애에 대해 복원시도가 오래걸린다면 복원한다고 의미가
있는가?
• 장애 복구시 Index 와 같은 다른 Object 에 대해서는 ?
15/67
Oracle Data Guard 개요
• 개요
• Standby 데이터베이스를 생성하여 운영 데이터베이스의 재난 상황에 대비할 수 있으며,
오라클 엔터프라이즈 서버에 구현되어 있는 기능을 이용하는 소프트웨어 솔루션이다
• Redo 데이터를 전달하고 적용하는 방식으로, 운영과 Standby 데이터베이스의 일관성을
유지한다
• 운영과 Standby 데이터베이스의 거리 제약이 적다
• 오라클 데이터베이스 내의 데이터만을 보호대상으로 한다
• 계획된 유지보수를 위한 switch over와 불시의 장애발생에 대한 failover를 지원한다
• GUI를 통한 손쉬운 구성과 제어
• 동기적 Log 전송에의한 데이터 무손실 보장
• 실수및 corruption으로 인한 전파 방지
16/67
Data Guard 이점
• Data Guard 기능
•
•
•
•
•
•
•
Site Failures 에 대한 DR Solution
물리적, 논리적, Online Data 에 대한 이중화
사용자 실수로 인한 즉각적인 Data 손상방지
대용량( TB) Data 에 대한 빠른 복구
Rolling Upgrades
장애 복구 실패 시 할 수 있는 최후의 보류
사용자 실수 및 블럭corruption으로 인한 전파 방지
• 대기 시스템의 활용
• 필요시 동일한 테스트 시스템 환경제공
• 운영Database 대신 Standby database에서 백업 함으로써 운영부담 절감
• 레포트 시스템, Summary 시스템으로 활용
• Data Guard 구성시 고려사항
•
•
•
•
17/67
근거리 또는 원거리 Data 복제
Physical or Logical Standby DB
Synchronous or asynchronous redo shipping
SQL> Alter Database Force LOGGING;
Oracle Data Guard 활용
• Oracle Maximum Availability Architecture(MAA)
• Oracle RAC로써 H/W적인 장애에 대비하고, Data Guard로써 디스크 장애나
재난 상황에 대비한다
18/67
무장애/무정지 시스템을 위한 Oracle솔루션
 최대 가용성 Solution : MAA(Maximum Availability Architecture) 기반의 24X365
고가용성을 위한 DB 구성 ( RAC + DataGuard )
RAC
Primary Site (평창)
Broker
Primary
Database
•
•
•
•
Standby Site (제주)
Data Guard
Primary Site 는 시스템 장애 대비 RAC 로 구성 운영
재해 및 디스크 장애 대비 Standby Site는 Data Guard 로 구성
end-to-end Data Protection and HA
Single 구성환경처럼 관리 가능
19/67
Standby
Database
무장애/무정지 시스템을 위한Oracle솔루션
• 모든 경우의 데이터 장애 대처 방안
Dramatic
Advances in Ease
of Use
Data Guard
Flash
Recovery
Area
Flashback
Human
Error
ASM Mirroring Protection
Storage Failure
Protection
20/67
Corruption
Protection
Site Failure
Protection
Combine the
Features to
Achieve Any
Level of Data
Protection
Oracle Database 10g 가용성
• 데이터 장애 대처 방안 – Site장애(DR) 대처 (Data Guard)
• Oracle Database 10g에서 제공하는 Data Guard는 서버 머신의 다운 또는 자연 재해와
같은 사고 때문에 데이터베이스의 데이터를 접근 하지 못하는 경우 대비하여
데이터베이스의 계속적인 서비스를 가능하게 하는 환경을 지원하기 위한 기능으로
데이터베이스의 고가용성과 장애 극복을 위해 다음과 같은 기능을 제공합니다.
• 일관성 있는 관리 인터페이스
Physical Standby
Database
• 물리적 스탠바이 데이터베이스를 자동으로 생성
• Failover와 Switchover 기능
• 물리적 결함에 대한 보호망
Sync or Async
Redo Shipping
Production
Database
• 로그 전송 서비스에 대한 설정
Backup
Redo Apply
DIGITAL DATA STORAGE
DIGITAL DATA STORAGE
Networ
k
Broker
Optional
Delay
• 로그 적용 서비스에 대한 설정
• 모니터링, 경고와 제어 메커니즘
Logical Standby
Database
Transform
Redo to SQL
• 논리적 스탠바이 데이터베이스 지원
Open for
Reports
• Auto Failover 지원(10g Release 2)
Optional
Delay
21/67
SQL
Apply
Additional
Indexes & MVs
Oracle Data Guard Architecture
Physical Standby
Database
Sync or Async
Redo data 동기화
Backup
현재운영
Database
Redo Apply
Network
DIGITAL DAT A ST ORAGE
Broker
Transform
Redo to SQL
Logical Standby
Database
SQL
Apply
22/67
DIGITAL DAT A ST ORAGE
Open for
Reports
Additional
Indexes & MVs
Oracle Database 10g 가용성
• 데이터 장애 대처 방안 – Site장애(DR) 대처 (Data Guard)
• 데이터 가드 REDO 적용 (Physical Standby Database)
• Production Database 에서 생성된 Redo 데이터를 Standby Database에 전송하고
전송된 데이터를 복구 모드에 있는 대기 데이터베이스에 적용합니다.
• 물리적 대기 데이터베이스는 읽기/쓰기로 Open하여 리포트용도 또는 Batch Job실행,
Backup, TEST용도 등으로 적극 활용할 수 있습니다. 쓰기로 Open후 되돌리기는 10g
Release 2의 새로운 기능입니다.
Data Guard Broker
Physical Standby
Database
Primary
Database
Optional
Delay
Backup
Network
Sync or Async
Redo Shipping
23/67
DIGITAL DATA STORAGE
Redo Apply
Oracle Database 10g 가용성
• 데이터 장애 대처 방안 – Site장애(DR) 대처 (Data Guard)
• 데이터 가드 SQL 적용(Logical Standby Database)
• SQL 적용 모드에서의 데이터 가드는 아카이브 로그로 부터 변경된 내용을 SQL
트랜잭션으로 생성하여 이를 대기 데이터베이스에 적용합니다. SQL을 적용하기
때문에 대기 데이터베이스는 정성적인 Open해서 사용이 가능하며 Production
데이터베이스와 다른 물리적인 구조를 가질 수 있다. 이를 논리적 대기 데이터베이스라
부릅니다.
• Primary 사이트의 정지 없이 논리적 스탠바이의 인스턴트를 지원합니다.
Additional
Indexes &
Materialized Views
Data Guard Broker
Primary
Database
Optional
Delay
Logical Standby
Database
Continuously
Open for Reports
Network
Sync or Async
Redo Shipping
24/67
Transform Redo
to SQL and Apply
Oracle Database 10g 가용성
• 데이터 장애 대처 방안 – Site장애(DR) 대처 (Data Guard)
• REAL TIME APPLY AND FLASHBACK DATABASE
• Oracle Database 10g의 데이터 카드에서는 FLASHBACK 데이터베이스를 이용하여
실시간 적용과 통합을 지원합니다.
• 실시간 (Real Time) 기능은 로그 적용 서비스(Log Apply Services)가 Primary
데이터베이스로 부터 리두 데이터를 받자 마자 Standby 데이터베이스의 Current 로그의
아카이브 로그 생성의 기다림 없이 바로 적용을 할 수 있습니다.
• 이러한 기능은 빠른 역할 변경 (switchover, failover)을 가능하게 하여 비계획/계획된
다운타임을 최소화 시켜줍니다.
Reporting
Production
Database
Transaction
Shipping
(Real Time Apply)
Standby
Database
On Real Time
Data
Some
Nodes
Used for
Other
Computing
No
Delay
25/67
Flashback
Log
Flashback
Log
Oracle Database 10g 가용성
• 데이터 변경 대처 방안 – Online상의 여러 Operation (Online Reorganization)
• 인터넷 비즈니스는 항상 응용 시스템이 항상 가용해야 되며, 계획된 유지보수를
할 경우라도 데이터베이스에 대한 접근은 계속되어야 합니다. 또한, 데이터가
데이터베이스에 삽입과 삭제됨에 따라 객체는 조각나게 되므로 때때로 객체 저장
속성은 대용량 데이터를 처리하기 위해서 변경되어야 할 필요가 있습니다.
• 온라인 스키마 재정의 ( add, modify, drop column)
• 온라인 인덱스 재구성 ( create, recreate, replace
• 온라인 테이블 재구성 (온라인 재구성 시, Update 및 Query 지속)
Source
Table
Copy
Table
Transfor
m
Result
Table
GUI
interface
to make
it Simple
Update
Tracking
26/67
Store
Updates
Transfor
m
Updates
Data Guard: 동기화/서비스 전환
Automatic Failover
운영 (Primary)
데이터베이스
Data 동기화
Data Guard
• Synchronous or asynchronous redo shipping
• Corruptions don’t propagate
• Thousands of production customers
27/67
물리적/논리적
Standby DB
최장거리 Data복제 솔루션
Data Guard DR Sweet Spot
• Far enough to avoid regional disaster
• Close enough for zero data loss
1mile = 1609.34m
100 miles
200 miles
Data Guard: Synchronous Redo Shipping
Synchronous Disk
Mirroring
• Data Guard redo transport uses order of
magnitude less network messaging than
disk-based remote mirroring
• Enables zero data loss at hundreds of miles
28/67
300+ miles
Down Time 최소화 방안
방안1. RAC를 통한 Oracle Instance의 이원화를 통한 Down Time 최소화
DBMS 환경
A Server
B Server
A Instance
B Instance
Live DB
 Patch Set 및 Upgrade의 경우, 2시간 이상의 서비스 정지 발생
 Single 패치 적용 시 다운 타임을 최소화 시킬 수 있다.
 패치의 적용을 각 인스턴스 별로 수행하고, 나머지 서버를 통해 서비스를 계속 진행한다.
29/67
Down Time 최소화 방안
방안2. 이원화된 서버 및 Logical Standby DB를 통한 Down Time 최소화
DBMS 환경
A Server
B Server
New SVR1
New SVR2
B’ Instance
A’ Instance
Oracle DataGuard
A Instance
B Instance
Live DB
Flashback
Standby DB
Flashback
 Live DB와 Standby DB간을 Oracle Data Gurard에 의해 Logical Standby DB로 구성하며 Data를 동기화 한다.
 Oracle DataGuard를 사용할 경우 Automatic Archive apply 및 Manual Archive apply가 가능하며 시스템
Failover 및 switchover 기능을 이용하여 switchover 및 takeover가 가능하다
 먼저, Standby DB로의 Redo SQL Apply를 중지하고, Standby DB의 인스턴스 A’, B’를 Down한 후, Patch Set을
적용한다.
 Standby DB의 패치 작업 후, A’, B’를 기동하여, Primary로부터 지금까지 적용된 내용을 동기화 한다.
 Live DB로의 Patch Set적용은, Standby DB로 switchover한 후 Standby DB에서 사용자 서비스를 수행하고
Live DB의 Oracle A,B Instance를 Down 한 후 Oracle Patch 및 변경 작업을 수행 한다.
 Live DB Oracle Patch Set작업 완료시, Standby DB에서 Live DB로 takeover 한 후 Liver DB에서 사용자 서비
스를 수행하면 된다.
30/67
Down Time 최소화 방안
방안3. 동일 서버 상에 이원화된 Logical Standby DB를 통한 Down Time 최소화
DBMS 환경
A Server
B Server
A Instance
A’ Instance
Live DB
B Instance
B’ Instance
Oracle DataGuard
Standby DB
 “이원화된 서버 및 Logical Standby DB를 통한 Down Time 최소화” 방안과 운영 방안은 동일함
 별도의 서버가 필요하지 않으며 기존 시스템에 메모리 및 Live DB 와 동일한 Size의 Disk가 필요하다
 시스템 Down Time의 경우 방법 1과 비슷하지만 Standby DB 재구성 및 Data Guard 반영 시간이 방법 1에 비해
편리하다
 별도의 서버 구성이 필요하지 않기 때문에 2안 보다 투자 비용이 적게 든다
 시스템 Down time 은 방법 2안과 동일하다.
 Cluster 와 관련된 작업이 발생할 경우 (Crs Patch) 모든 Instance를 Down해야 한다.
31/67
<Insert Picture Here>
DataGuard
- Physical Standby (Redo Apply)
32/67
Standby Database 운영모드
• Managed Recovery Mode
• 운영 데이터베이스에서 발생한 Redo Log를 Standby 데이터베이스에
전달하고, Standby 데이터베이스는 이를 적용한다
• Standby 데이터베이스를 오픈할 수 없다.
• Read-Only Mode
• 운영 데이터베이스가 보내는 Redo Log는 계속해서 받아둔다
• Redo Log의 적용을 멈추고, Standby 데이터베이스를 읽기 전용으로
오픈한다
• Standby 데이터베이스에 질의문을 수행하여, 필요한 리포팅을 할 수 있다
33/67
Oracle Data Guard 설정 모드
• Data Guard 설정 모드
• 보호 모드(Maximum Protection)
• 최소한 하나의 Standby 서버에 트랜젝션 데이터가 Commit 처리 됨을 확인하기 전까지
운영머신의 트랜젝션은 commit 되지 않습니다.
2개 이상의 Standby database 운영 권장
• 가용 모드(Maximum Availability)
• 최소한 하나의 Standby 서버에 트랜젝션 데이터가 Commit 처리 됨을 확인하고 운영머신의
트랜젝션은 commit 처리 함.
• Maximum Protection 모드로 운영되다가, Standby쪽에 Redo Log가 기록될 수 없는 상황이
발생하면, Maximum Performance 모드로 전환된다.
• 연결 재개시 즉시 운영머신의 누적된 Archive log 를 이용하여 데이터베이스간 동기화를
자동으로 수행됨.
• 운영과 Standby에서의 Redo Log 의 적용 차이가 복구되면 다시 Maximum Protection 모드로
운영됩니다.
• 성능 모드(Maximum Performance)
• 기본 모드이다
• Standby쪽에 Redo Log가 기록되는 것은, 운영쪽 트랜잭션의 commit과는 상관없다.
• Redo Log의 변경내용이 비동기식으로 전달된다
34/67
Flexible Data Protection Modes
Protection Mode
재해 발생시 데이터
손실의 위험
Redo Shipment
Maximum Protection
손실 전혀 없음
Double Failure Protection
LGWR, SYNC
Synchronous redo
shipping to 2 sites
Maximum Availability
손실 전혀 없음
Single Failure Protection
LGWR, SYNC
Synchronous redo
shipping
Maximum Performance
Minimal data loss – usually 0
to few seconds
LGWR ASYNC/ARCH
Asynchronous redo
shipping
Balance cost, availability, performance, and transaction protection
35/67
고가용성 지원을 위한 장애복구 솔루션
• 오라클은 고가용성 지원을 위한 장애복구 기능으로써 Oracle만의 강력한
Flashback 및 다양한 복구기능을 아래와 같이 제공합니다.
•
•
•
•
•
데이터 장애 대처 방안 – Flashback Database
• Oracle Database 10g 이전까지는 transactional point-in-time recovery를 위해서는 backup용 file과 redo log file을
이용하여 원하는 시간까지의 복구를 하였었습니다. 그러나 이 방법은 backup용 file이 오래된 것이며, archive log가
많이 쌓여 있을 때는 많은 시간이 소요된다. Oracle 10g부터는 flashback database를 이용하여 윈하는 시점으로
수초~수분내의 recovery가 가능하게 되었습니다.
Flashback Drop & Flashback Table
• Oracle 10g부터는 recycle bin(휴지통)이 있어서 어떤 table을 drop하면, drop된 table과 해당 table과 관계되는
object들을 되살릴 수 있게 되었습니다.
Flashback Version Query
• Flashback Versions Query는 Select시 versions between명령을 넣으면 해당 정보의 history 정보를 확인하고 보구할
수 있는 기능입니다.
Flashback Transaction Query
• Flashback Transaction Query는 아래의 그림과 같이 user의 실수로 잘못된 query를 수행하였을 경우, 해당 query를
undo할 수 있기 때문에 human error에 대한 복구를 더욱 손쉽게 할 수 있습니다.
로그마이너(Logminor)
•
•
리두 로그의 정보를 해석하고 분석할 수 있는 툴로서 데이터베이스의 논리적 결함을 진단하고, 상세한 복구를
수행할 수 있는 기능을 제공합니다.
Data Guard
• Oracle Database 10g에서 제공하는 Data Guard는 서버 머신의 다운 또는 자연 재해와 같은 사고 때문에
데이터베이스의 데이터를 접근 하지 못하는 경우 대비하여 데이터베이스의 계속적인 서비스를 가능하게 하는
환경을 지원하기 위한 기능으로 데이터베이스의 고가용성과 장애 극복(DR)의 기능을 제공합니다.
36/67
<Insert Picture Here>
Data Guard 의 주요 기능
37/67
Switchover
•
•
•
•
운영시스템/하드웨어 업그레이드
오라클데이터베이스에 대한 패치 셋 롤링 업그레이드
재해 복구 환경 점검
테스트를 위해서는 운영 데이터베이스에 대한 모든
사용자 세션을 해제 한 후 테스트를 진행함
• DGMGRL> SWITCHOVER TO Standby_Chicago;
38/67
Role Change – 역활전환 이벤트
• 현재의 운영중인 데이터 베이스가 더 이상 운영모드로
전환 하지 않음을 어플리케이션에 통보하기 위한
이벤트 기능 추가
• DB_ROLE_CHANGE 시스템 이벤트
• DB_DOWN FAN (Fast Applicaion Notification) 이벤트
• FAN 이벤트 수신 하도록 설정 => OCI Client 로 통보
• Data Guard + RAC
• 데이터베이스 레벨의 가용성과 시스템 레벨의
가용성을 동시에 구현
39/67
Manual Failover
• 관리자가 EM GUI, DGMGRL, SQL*Plus 이용하여 페일오버
과정에서 타겟 스텐바이 데이터베이스를 선택하여 전환함
• DGMGRL> FAILOVER TO Standby_Chicago;
40/67
Fast-Start Failover
Primary Site
Standby Site
Observer
4. Observer <=> primary connection times out (timeout threshold configurable)
5. Observer asks target standby if it is ready to fail over
6. Observer begins Fast-Start Failover
41/67
운영방안1 – 읽기 전용 OPEN
• Physical Standby 데이터베이스를 읽기 전용으로
open 하고 레포트 및 기타 Summary 작업 수행
읽기 전용 모드에서는 복구작업을 수행할 수 없기에
잠시 복구 작업을 중지 시킵니다.
SQL> ALTER DATABASE RECOVER MANAGED
STANDBY DATABASE CANCEL;
아래 명령어로 읽기 전용 모드로 Open 됩니다.
SQL> ALTER DATABASE OPEN;
42/67
운영방안2 – 테스트 DB 로 읽기 쓰기
(FLASHBACK 전환)
• DATA GUARD 와 FLASHBACK 기능 조합으로
• 임시로 읽기/쓰기 모드로 전환 후 테스트작업 수행
• 다시 과거시점으로 Flashback 작업진행 후 Data Guard 가 다시
자동으로 Standby database 로 재동기화 됨으로써 본연의 DR 역활 수행
• Physical Standby 데이터베이스를 다시 재생성 하실 필요가 없습니다.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL> CREATE RESTORE POINT t1 GUARANTEE FLASHBACK DATABASE;
SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;
일기 / 쓰기 작업 진행하면서 레포팅 작업 수행수
SQL> FLASHBACK DATABASE TO RESTORE POINT t1;
SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
43/67
<Insert Picture Here>
3. 구축 및 운영방안
EM을 이용한 DataGuard 구축방안
44/67
Oracle Enterprise Manager를 이용한
Data Guard의 초기화면
45/67
Oracle Enterprise Manager를 이용한
Data Guard의 추가
46/67
Oracle Enterprise Manager를 이용한
Data Guard의 생성
47/67
Oracle Enterprise Manager를 이용한
Data Guard의 Add Standby Database
48/67
Oracle Enterprise Manager를 이용한
Data Guard의 Log Apply
49/67
Oracle Enterprise Manager를 이용한
Data Guard의 Protection Mode
50/67
Oracle Enterprise Manager를 이용한
Data Guard의 Switchover
51/67
Oracle Enterprise Manager를 이용한
Data Guard의 Failover
52/67
<Insert Picture Here>
4. 관리방안
EM을 이용한 RAC 모니터링방안
53/67
Oracle Enterprise Manager를 이용한
Data Guard의 Performance view
54/67
EM10g – 편리해진 RAC 환경 모니터링
• Monitor inter-instances
communication
55/67
• Identify performance problems
due to object contention
EM10g – 편리해진 RAC 환경 모니터링
• Monitor & Alert private
and public interconnects
56/67
• RAC –Topology management
EM10g – 편리해진 RAC 환경 모니터링
성능 분석 및 튜닝
Pack
• 튜닝 방안 권장 제시
• 다각적 방법의 문제 분석
• SQL 추출/튜닝/비교 기능
<과거/현재 실행 선택 후 비교 기능 제공>
57/67
<ADDM 성능분석 결과>
장애예방 및 모니터링
Performance
• DB Performance Page에 호스트와 DB의 실시간 정보를 직관적으로 보여줌
• DB Performance Page로 부터 드릴다운 메튜를 통해 신속환 원인분석이 가능함
• DB Performance Page에 제공하는 다양한 링크를 통해 다양한 기준( Top Activity,
Top Consumers)으로 모니터링 할 수 있음
• Host Performance Page는 CPU, 메모리, 디스크 사용률 등을 한 눈에 확인할 수
있음.
Active Sessions는 크게 “CPU Used”(녹색) ,
“Application”(갈색), “Concurrency”(진갈색) 세
부분으로 이루어져 있음을 직관적으로 알 수 있다.
Other
Network
Administrative
Configuration
Commit
Application
Concurrency
System I/O
User I/O
Scheduler
CPU Used
58/67
RAC DB Topology
• RAC 구성 Topology Overview
• 구성 Component 별 상세정보 Display
• A Cluster database, Database Instances, ASM Instances, Listeners, Interfaces
59/67
CRS Topology
RAC를 구성하는 Component의 Topology 및 상세설명 및 Status Summary
60/67
RAC DB Performance
• Average Current/CR Block Receive Time에 대한 실시간 모니터링
• Cluster Cache Coherency 모니터링
61/67
Oracle Enterprise Manager의 기대효과
Oracle Enterprise Manager는 모든 Oracle 제품과 3rd vendor 제품을 관리하기 위한 전문
Enterprise Management Solution입니다. 특히 Oracle Database 서버에 대해서 모니터링,
성능분석,튜닝, Configuration 등의 종합적인 관리를 통해 장애를 예방하고 최적의 운영상
태를 유지함으로써 귀사의 IT서비스의 가용성과 품질를 향상시키고 시스템 관리비용을 절
감하여 귀사의 ROA(Return of Assets)를 극대화 시켜줄 것입니다.
IT서비스 가용성과 품질향상 + 시스템 관리비용 절감
장애예방 &
모니터링
62/67
자동성능분석
& 튜닝
DB
Administration
RAC & CRS
Adminstration
Configuration
& Change 관리
오라클제품
및 타사제품
지원
<Insert Picture Here>
5. 시스템 구성도
EM 을 통한 오라클 DR 솔루션 구성도
( RAC + EM + DataGuard )
63/67
EM 을 통한 오라클 DR 솔루션 구성도
EM Server
RAC Primary
Host : grid4.us.oracle.com
Host : ora10gr2n1.us.oracle.com
GridControl R4 (EM server)설치
Primary DB : ORCL2
Disk Device : File system
Disk Device :
Repository DB : Oracle 10.2.0.4
- raw device 또는
- ASM 또는
agent
agent GC Agent : 10.2.0.4
Standby
- Veritas Volume Manager file system
Oracle 10.2.0.3
agent
EM
GC Agent : 10.2.0.4
Data Guard
(Physical Standby)
Data 동기화
switch over
전환가능
Host : ora10gr2n2.us.oracle.com
Standby DB : ORCL2DG2
Disk Device : File system
Oracle 10.2.0.3
GC Agent : 10.2.0.4
64/67
<Insert Picture Here>
6. 참조고객
65/67
Reference : Oracle Data Guard 아산 병원
•
•
•
•
Oracle 10g RAC로 구성
Oracle Data Guard가 DR 센터에 구축
RAC로 구성된 병원 종합시스템의 한쪽 노드에 Standby DB를 구성하여 Read Only 모드로
오픈하여 사용.
Read Only 모드로 사용되는 Standby DB는 야간에 히다찌 투루카피 솔루션으로
데이타파일 복제를 통해 Consistency를 유지.
병원 종합시스템/인트라넷
병원 종합시스템/인트라넷
IBM AIX 5.2 P690
P4 16 CPU
48G RAM
Oracle Database
10.1.0.3
IBM AIX 5.2 P690
P4 16 CPU
48G RAM
Oracle Database
10.1.0.3
Oracle
Database
10g RAC
Standby Instance 구성
(10.1.0.3)
Data 용량 : 2.4 TB
66/67
히다찌
트루카피 이용
DR 센터 Physical Standby
IBM AIX 5.2 P590
P4 8 CPU
Data Guard
24G RAM
Log Shipping Oracle Database
10.1.0.3
References :
• 국내외 다수의 기업에서 사용
• 대부분이 업무의 특성을 고려한 고 가용성의 Oracle Database RAC 와 Oracle
Standby Database로 운영.
• 아래에 기술한 고객들은 Physical Standby DB를 오픈하여 분석용 등의 용도로
데이타베이스를 활용하고 디스크 복제 솔루션을 활용하여 백업용도 및 다른 용도의
업무로 활용.
회사명
Standby DB 적용 업
무
Protection 모드
Maximum
Performance
DB 버전
삼성 서울 병원
의료 정보 검색 엔진용
서울 아산병원
병원 OCS 업무 분석용
서울대 병원
병원 OCS 업무 분석용
하나생명
보험 기간계
Maximum
Performance
9.2.0.7
하이닉스
공장 자동화
Maximum
Performance
9.2.0.4
청주 하이닉스 반도체
공장 자동화
Maximum
Performance
9.2.0.4
청주 매그나칩 반도체
공장 자동화
Maximum
Performance
10.2.0.3
67/67
Maximum
Performance
Maximum
Performance
10.1.0.5
10.2.0.1
9.2.0.4