EM 을 이용한 오라클 DataGuard 구성방안 (RAC + EM + DataGuard)

EM 을 이용한 오라클 DataGuard 구성방안 (RAC + EM + DataGuard)
Oracle Database 10g Release 2 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. 참조고객

<Insert Picture Here>
1. 제안 개요

제안 개요 개요 고객 요구사항 : 장애 발생시 시스템 가용성 보장을 위한 안정적인 운영 솔루션
글로벌 기업으로서 경제의 유동성과 시장의 빠른 변화에 적응하면서 예측할 수 없는 비즈니스 장애요소에 대처하기 위함 일반적인 장애요소로 부터 글로벌 기업의 IT 인프라를 보호하기 위함 예측할 수 없는 Unplanned System down 및 예측 가능한 Planned system down( ex: Database patch 및 Upgrade ) 상황으로부터 비즈니스의 연속성을 유지 하기 위함. 고객 요구사항 : 장애 발생시 시스템 가용성 보장을 위한 안정적인 운영 솔루션 두 시스템간의 Data 동기화 및 장애복구 솔루션

2. 제안 솔루션 소개

제안 솔루션 소개 고객 요구사항 : 가용 솔루션 장애 발생시 시스템 가용성 보장을 위한 안정적인 운영 솔루션
두 시스템간의 Data 동기화 및 장애복구 솔루션 가용 솔루션 Oracle RAC 솔루션 Oracle Data Guard ( Database 복제 솔루션 ) 오라클에서 제안하는 보광휘닉스파크 제안솔루션 무정지 서비스 가용성 향상을 위한 Oracle RAC 재난대비 복제 솔루션 Oracle DataGuard 관리 및 통제를 위한 Enterprise Manager Console

24*365 무정지 가용성 및 확장성 보장을 위한 이중화 솔루션 - Oracle RAC

고가용성의 클러스터링기술 및 장애복구 기능:RAC
오라클은 고가용성 지원을 위한 틀러스터링 기술로써 오라클 클러스터 데이터베이스인 Real Application Clusters ( RAC )를 제공합니다. 클러스터링 기술 개요 오라클 RAC을 사용하면 한 노드에 장애가 발생하더라도 서비스는 지속됩니다. 다른 벤더의 데이타베이스를 사용하면서 프로세서의 장애와 같은 상황에 의한 서비스 다운 현상을 막기 위해서는, 별도의 SMP 서버를 구매해서 대기 상태로 두어야 할 것입니다. 이러한 구성을 cold standby 혹은 active/passive 구성이라고 합니다. 이 구성은 단점은 장애 복구의 시간이 오래 걸린다는 것과 비용이 많이 든다는 것입니다. 그러나 오라클 RAC는 디스크를 공유하는 active/active 구성되기 때문에 서비스 다운 현상을 막을 수 있습니다. 장애 복구 시간 오라클 RAC을 사용하면 장애 복구 시간이 5~30초 혹은 수초면 됩니다. 오라클 RAC은 위의 복구 단계가 필요없습니다. 살아 있는 노드에 접속되어 있는 사용자는 그대로 해당 노드들을 사용하면 되고, 단지 장애가 발생된 노드에 접속되어 있던 사용자만 자동으로 재접속 됩니다. 이 부분에 있어서, 오라클은 사용자들을 백업 노드에 미리 접속을 시키는 기술을 제공하는데, 이 경우 재접속의 지연 시간도 제거할 수 있습니다. 마지막으로 살아 있는 노드들의 버퍼 캐쉬는 자주 액세스되는 데이터를 캐슁하고 있으므로, 곧바로 고성능에 도달하게 되는 것입니다.

Node A in an RAC cluster fails, users are migrated
가용성 물리적인 노드가 독립적으로 운영되기 때문에 하나 이상의 노드에 장애가 발생하더라도 클러스터의 여타 노드에 영향을 미치지 않습니다. (폴트 톨러런스) 클러스터 시스템은 단 하나의 노드만이 생존하더라도 서비스가 가능합니다. (고도의 가용성을 실현) 유지보수를 위해 노드 그룹이 오프라인으로 되어 있는 동안 나머지 클러스터가 서비스를 할 수 있습니다. No Single point of Failure C a c h e F u s i o n Node A B Node A in an RAC cluster fails, users are migrated

고가용성의 RAC (정상운영) Availability 부문 – Failover 원리 노드 1 인스턴스 ‘A’ Active
정상 운영 환경 – Active/Active의 서비스 지원 노드 1 인스턴스 ‘A’ Active 노드 2 인스턴스 ‘B’ Active 모든 노드가 Active 클라이언트의 부하 분산(Load Balancing) 동일한 데이터 환경 제공 (Share Disk) Server Failure 자동 감지 Node간의 Resource Pooling Database (공유 디스크)

고가용성의 RAC (장애발생) TAF Availability 부문 – Failover 원리(계속)
Server Failure 발생시 – 지속적으로 투명한 서비스 기능 TAF 장애발생 노드 1 인스턴스 ‘A’ Failure 노드 2 인스턴스 ‘B’ Still Active 장애를 대비한 운영모드 1. TAF (Transparent Application Fail-Over) 를 통한 DB 세션을 자동으로 복구. Application은 Node의 장애를 감지 못함 나머지 노드가 대신 실패한 노드의 모든 작업을 분담하여 작업 지속 2. FCF(Fast Connection Failover), FAN(Fast Application Notification)으로 5 ~ 30초 내에 모든 작업 을 정상화 모든 작업 자동 진행 인스턴스 ‘A’ 대한 Recovery를 ‘B’에서 수행(무결성 보장) Database (공유 디스크)

RAC를 이용한 물리적 H/A 효과 – RAC High Availability 측면 - 물리적 구조 ( 2노드 예시)
Fast Ethernet Switch Fast Ethernet Switch Primary line or Active line Second line NIC0 NIC1 NIC2 NIC0 NIC1 NIC2 서버 뿐만 아닌 모든 H/W 장비가 고가용성을 위해 이중화 구조 권장 NIC3 NIC4 NIC5 NIC3 NIC4 NIC5 interconnect interconnect Gigabit Switch Gigabit Switch 노드간의 DB Buffer Cache 데이터 처리를 빠르게 하기위해 클러스터 Interconnect는 Gigabit 이상의 대역의 Switch 장비 필요 SAN Switch SAN Switch 데이터베이스 시스템 데이터 및 각종 고객 데이터가 공유 디스크에 저장됨. 공유 디스크 구조로는 볼륨 매니저에 의해 관리되는 Raw device, 3th벤더의 공유 클러스터 파일 시스템, 오라클 제공 ASM (Automatic Storage Management)의 세가지 유형 중 선택 적용 가능 Shared Disk Type 1. RAW device 2. Shared CFS 3. Oracle ASM OCR Voting Disk

Oracle RAC 기반의 자동 Failover
RAC를 이용한 Instance H/A 효과 – RAC 신속한 Failover 및 Instance복구측면 - HW적 HA 절차 비교 HW적 HA 적용 시 Oracle RAC 기반의 자동 Failover Giga bit Switch ACTIVE STANDBY ACTIVE ACTIVE 노드-2 노드-3 Oracle10g 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 되어 서비스 처리 수행 1) Active-Active 시스템에서 모두 서비스 처리 수행 2) 한쪽 운영시스템 장애시 백업용(Standby)시스템으로 Failover 수행 - 장애시 복구 및 처리 절차 다른 Active시스템에서 장애난 Instance의 Recovery 즉시 수행 ( 데이터 무결성 보장을 위해 장애난 시스템 의 미 반영된 Log 및 Undo 데이터 처리) 3) 다른 Active시스템에서 서비스 즉시 처리 수행 최소 5분 ~ 30 분 이상 소요 최소 20초 ~ 60 초 전후 소요

재난복구(DR) 복제 솔루션 - Oracle DataGuard

Database 관리자의 도전과제 Site 전체에 정전, 지진 과 같은 천재지변으로 장애가 발생했다면 대응방안은 ?
만일 사용자가 실수 로 Data 를 일부 또는 모두 삭제 또는 전체 Update 했다면 ? 노후된 disk 또는 갑작스런 instance down으로 블록 corruption이 발생했다면 ? 다른 복제 솔루션을 사용했더라도 Online 상의 Transaction 마지막 Data 까지 안전하게 보장 할 수 있을까 ? 만약 장애 발생시 복구 시도가 실패 했다면 또 다른 백업SET 은 ? 장애 발생시 복구수행전 장애시점의 DATA 를 백업 후 복구를 시도 하라고 권장합니다. 긴급한 장애발생시 관리자는 백업을 받아 놓고 복구를 시도 할 시간적 여유가 있을까 ? 장애복구 실패 시 최후의 보류는 ? 만약 대용량 Data 장애에 대해 복원시도가 오래걸린다면 복원한다고 의미가 있는가? 장애 복구시 Index 와 같은 다른 Object 에 대해서는 ?

Oracle Data Guard 개요 개요 Standby 데이터베이스를 생성하여 운영 데이터베이스의 재난 상황에 대비할 수 있으며, 오라클 엔터프라이즈 서버에 구현되어 있는 기능을 이용하는 소프트웨어 솔루션이다 Redo 데이터를 전달하고 적용하는 방식으로, 운영과 Standby 데이터베이스의 일관성을 유지한다 운영과 Standby 데이터베이스의 거리 제약이 적다 오라클 데이터베이스 내의 데이터만을 보호대상으로 한다 계획된 유지보수를 위한 switch over와 불시의 장애발생에 대한 failover를 지원한다 GUI를 통한 손쉬운 구성과 제어 동기적 Log 전송에의한 데이터 무손실 보장 실수및 corruption으로 인한 전파 방지

Data Guard 이점 Data Guard 기능 대기 시스템의 활용 Data Guard 구성시 고려사항
Site Failures 에 대한 DR Solution 물리적, 논리적, Online Data 에 대한 이중화 사용자 실수로 인한 즉각적인 Data 손상방지 대용량( TB) Data 에 대한 빠른 복구 Rolling Upgrades 장애 복구 실패 시 할 수 있는 최후의 보류 사용자 실수 및 블럭corruption으로 인한 전파 방지 대기 시스템의 활용 필요시 동일한 테스트 시스템 환경제공 운영Database 대신 Standby database에서 백업 함으로써 운영부담 절감 레포트 시스템, Summary 시스템으로 활용 Data Guard 구성시 고려사항 근거리 또는 원거리 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로써 디스크 장애나 재난 상황에 대비한다

무장애/무정지 시스템을 위한 Oracle솔루션
최대 가용성 Solution : MAA(Maximum Availability Architecture) 기반의 24X365 고가용성을 위한 DB 구성 ( RAC + DataGuard ) Primary Site (평창) Standby Site (제주) RAC Broker Data Guard Primary Database Standby Database Primary Site 는 시스템 장애 대비 RAC 로 구성 운영 재해 및 디스크 장애 대비 Standby Site는 Data Guard 로 구성 end-to-end Data Protection and HA Single 구성환경처럼 관리 가능

Site Failure Protection
무장애/무정지 시스템을 위한Oracle솔루션 모든 경우의 데이터 장애 대처 방안 Dramatic Advances in Ease of Use Data Guard Site Failure Protection Flash Recovery Area Corruption Protection Combine the Features to Achieve Any Level of Data Protection Flashback Human Error Protection ASM Mirroring Storage Failure Protection

Oracle Database 10g 가용성 데이터 장애 대처 방안 – Site장애(DR) 대처 (Data Guard)
Oracle Database 10g에서 제공하는 Data Guard는 서버 머신의 다운 또는 자연 재해와 같은 사고 때문에 데이터베이스의 데이터를 접근 하지 못하는 경우 대비하여 데이터베이스의 계속적인 서비스를 가능하게 하는 환경을 지원하기 위한 기능으로 데이터베이스의 고가용성과 장애 극복을 위해 다음과 같은 기능을 제공합니다. 일관성 있는 관리 인터페이스 물리적 스탠바이 데이터베이스를 자동으로 생성 Failover와 Switchover 기능 물리적 결함에 대한 보호망 로그 전송 서비스에 대한 설정 로그 적용 서비스에 대한 설정 모니터링, 경고와 제어 메커니즘 논리적 스탠바이 데이터베이스 지원 Auto Failover 지원(10g Release 2) Network Broker Production Database Logical Standby Open for Reports SQL Apply Optional Delay Transform Redo to SQL Additional Indexes & MVs Physical Standby Backup Redo Apply Sync or Async Redo Shipping

Oracle Data Guard Architecture
Physical Standby Database Sync or Async Redo data 동기화 Backup 현재운영 Database Redo Apply Network Broker Logical Standby Database Transform Redo to SQL Open for Reports SQL Apply 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 Redo Apply Sync or Async Redo Shipping

Continuously Open for Reports
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 Logical Standby Database Optional Delay Continuously Open for Reports Network Sync or Async Redo Shipping Transform Redo to SQL and Apply

Some Nodes Used for Other Computing
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)을 가능하게 하여 비계획/계획된 다운타임을 최소화 시켜줍니다. Production Database Standby Reporting On Real Time Data Some Nodes Used for Other Computing Flashback Log Transaction Shipping (Real Time Apply) No Delay

GUI interface to make it Simple
Oracle Database 10g 가용성 데이터 변경 대처 방안 – Online상의 여러 Operation (Online Reorganization) 인터넷 비즈니스는 항상 응용 시스템이 항상 가용해야 되며, 계획된 유지보수를 할 경우라도 데이터베이스에 대한 접근은 계속되어야 합니다. 또한, 데이터가 데이터베이스에 삽입과 삭제됨에 따라 객체는 조각나게 되므로 때때로 객체 저장 속성은 대용량 데이터를 처리하기 위해서 변경되어야 할 필요가 있습니다. 온라인 스키마 재정의 ( add, modify, drop column) 온라인 인덱스 재구성 ( create, recreate, replace 온라인 테이블 재구성 (온라인 재구성 시, Update 및 Query 지속) Copy Table Transform Source Table Result Table GUI interface to make it Simple Store Updates Update Tracking Transform Updates

Data Guard: 동기화/서비스 전환 Data Guard Automatic Failover
물리적/논리적 Standby DB 운영 (Primary) 데이터베이스 Data 동기화 Data Guard 동기 또는 비동기의 Redo 를 전송할수 있으며 Production 의 Curruption 을 그대로 전달하지 않기에 더욱 안전하며 저비용의 서버와 스토리지로 저렴하게 구성할 수 있다는것이 장점이라 할 수 있겠습니다. Synchronous or asynchronous redo shipping Corruptions don’t propagate Thousands of production customers

최장거리 Data복제 솔루션 Data Guard DR Sweet Spot
Far enough to avoid regional disaster Close enough for zero data loss 1mile = m 100 miles 200 miles 300+ miles Data Guard: Synchronous Redo Shipping Data Guard redo transport uses order of magnitude less network messaging than disk-based remote mirroring Enables zero data loss at hundreds of miles 또한 아주 먼거리 로 구성을 한다 하여도 데이터 Loss 가 발생 하지 않습니다. Synchronous Disk Mirroring

Down Time 최소화 방안 방안1. RAC를 통한 Oracle Instance의 이원화를 통한 Down Time 최소화 DBMS 환경 A Server B Server A Instance B Instance Live DB Patch Set 및 Upgrade의 경우, 2시간 이상의 서비스 정지 발생 Single 패치 적용 시 다운 타임을 최소화 시킬 수 있다. 패치의 적용을 각 인스턴스 별로 수행하고, 나머지 서버를 통해 서비스를 계속 진행한다.

Down Time 최소화 방안 방안2. 이원화된 서버 및 Logical Standby DB를 통한 Down Time 최소화 DBMS 환경 A Server B Server New SVR1 New SVR2 A’ Instance B’ Instance Oracle DataGuard A Instance B Instance Live DB Standby DB Flashback 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에서 사용자 서비스를 수행하면 된다.

Down Time 최소화 방안 방안3. 동일 서버 상에 이원화된 Logical Standby DB를 통한 Down Time 최소화 DBMS 환경 A Server B Server A Instance B Instance A’ Instance B’ Instance Live DB 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해야 한다.

DataGuard Physical Standby (Redo Apply)

Standby Database 운영모드 Managed Recovery Mode
운영 데이터베이스에서 발생한 Redo Log를 Standby 데이터베이스에 전달하고, Standby 데이터베이스는 이를 적용한다 Standby 데이터베이스를 오픈할 수 없다. Read-Only Mode 운영 데이터베이스가 보내는 Redo Log는 계속해서 받아둔다 Redo Log의 적용을 멈추고, Standby 데이터베이스를 읽기 전용으로 오픈한다 Standby 데이터베이스에 질의문을 수행하여, 필요한 리포팅을 할 수 있다

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의 변경내용이 비동기식으로 전달된다

Flexible Data Protection Modes
재해 발생시 데이터 손실의 위험 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

고가용성 지원을 위한 장애복구 솔루션 오라클은 고가용성 지원을 위한 장애복구 기능으로써 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)의 기능을 제공합니다.

Data Guard 의 주요 기능

Switchover 운영시스템/하드웨어 업그레이드 오라클데이터베이스에 대한 패치 셋 롤링 업그레이드 재해 복구 환경 점검
테스트를 위해서는 운영 데이터베이스에 대한 모든 사용자 세션을 해제 한 후 테스트를 진행함 DGMGRL> SWITCHOVER TO Standby_Chicago;

Role Change – 역활전환 이벤트 현재의 운영중인 데이터 베이스가 더 이상 운영모드로 전환 하지 않음을 어플리케이션에 통보하기 위한 이벤트 기능 추가 DB_ROLE_CHANGE 시스템 이벤트 DB_DOWN FAN (Fast Applicaion Notification) 이벤트 FAN 이벤트 수신 하도록 설정 => OCI Client 로 통보 Data Guard + RAC 데이터베이스 레벨의 가용성과 시스템 레벨의 가용성을 동시에 구현

Manual Failover 관리자가 EM GUI, DGMGRL, SQL*Plus 이용하여 페일오버 과정에서 타겟 스텐바이 데이터베이스를 선택하여 전환함 DGMGRL> FAILOVER TO Standby_Chicago;

Fast-Start Failover Primary Site Standby Site Observer Examples of why standby may answer 'no' when asked if ready to failover: - if not synchronized with primary - standby has contacted the primary within last threshold seconds - primary (or standby) was intentionally shutdown (normal, immediate, transactional) Observer <=> primary connection times out (timeout threshold configurable) Observer asks target standby if it is ready to fail over Observer begins Fast-Start Failover

운영방안1 – 읽기 전용 OPEN Physical Standby 데이터베이스를 읽기 전용으로 open 하고 레포트 및 기타 Summary 작업 수행 읽기 전용 모드에서는 복구작업을 수행할 수 없기에 잠시 복구 작업을 중지 시킵니다. SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; 아래 명령어로 읽기 전용 모드로 Open 됩니다. SQL> ALTER DATABASE OPEN;

운영방안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;

3. 구축 및 운영방안 EM을 이용한 DataGuard 구축방안

Oracle Enterprise Manager를 이용한 Data Guard의 초기화면

Oracle Enterprise Manager를 이용한 Data Guard의 추가

Oracle Enterprise Manager를 이용한 Data Guard의 생성

Oracle Enterprise Manager를 이용한 Data Guard의 Add Standby Database

Oracle Enterprise Manager를 이용한 Data Guard의 Log Apply

Oracle Enterprise Manager를 이용한 Data Guard의 Protection Mode

Oracle Enterprise Manager를 이용한 Data Guard의 Switchover

Oracle Enterprise Manager를 이용한 Data Guard의 Failover

4. 관리방안 EM을 이용한 RAC 모니터링방안

Oracle Enterprise Manager를 이용한 Data Guard의 Performance view

EM10g – 편리해진 RAC 환경 모니터링 Monitor inter-instances communication
Identify performance problems due to object contention

EM10g – 편리해진 RAC 환경 모니터링 Monitor & Alert private and public interconnects RAC –Topology management

EM10g – 편리해진 RAC 환경 모니터링 성능 분석 및 튜닝 Pack 튜닝 방안 권장 제시 다각적 방법의 문제 분석
<ADDM 성능분석 결과> 성능 분석 및 튜닝 Pack 튜닝 방안 권장 제시 다각적 방법의 문제 분석 SQL 추출/튜닝/비교 기능 <과거/현재 실행 선택 후 비교 기능 제공>

장애예방 및 모니터링 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

RAC DB Topology RAC 구성 Topology Overview 구성 Component 별 상세정보 Display
A Cluster database, Database Instances, ASM Instances, Listeners, Interfaces

CRS Topology RAC를 구성하는 Component의 Topology 및 상세설명 및 Status Summary

RAC DB Performance Average Current/CR Block Receive Time에 대한 실시간 모니터링
Cluster Cache Coherency 모니터링

Oracle Enterprise Manager의 기대효과
Oracle Enterprise Manager는 모든 Oracle 제품과 3rd vendor 제품을 관리하기 위한 전문Enterprise Management Solution입니다. 특히 Oracle Database 서버에 대해서 모니터링, 성능분석,튜닝, Configuration 등의 종합적인 관리를 통해 장애를 예방하고 최적의 운영상태를 유지함으로써 귀사의 IT서비스의 가용성과 품질를 향상시키고 시스템 관리비용을 절감하여 귀사의 ROA(Return of Assets)를 극대화 시켜줄 것입니다. IT서비스 가용성과 품질향상 + 시스템 관리비용 절감 RAC & CRS Adminstration 장애예방 & 모니터링 자동성능분석 & 튜닝 오라클제품 및 타사제품지원 DB Administration Configuration & Change 관리

5. 시스템 구성도 EM 을 통한 오라클 DR 솔루션 구성도 ( RAC + EM + DataGuard )

EM 을 통한 오라클 DR 솔루션 구성도 EM Server RAC Primary Standby EM Data 동기화
Host : grid4.us.oracle.com GridControl R4 (EM server)설치 Disk Device : File system Repository DB : Oracle GC Agent : Host : ora10gr2n1.us.oracle.com Primary DB : ORCL2 Disk Device : - raw device 또는 - ASM 또는 - Veritas Volume Manager file system Oracle GC Agent : agent Standby agent EM agent Data Guard (Physical Standby) Data 동기화 switch over 전환가능 Host : ora10gr2n2.us.oracle.com Standby DB : ORCL2DG2 Disk Device : File system Oracle GC Agent :

6. 참조고객

Reference : Oracle Data Guard 아산 병원
Oracle 10g RAC로 구성 Oracle Data Guard가 DR 센터에 구축 RAC로 구성된 병원 종합시스템의 한쪽 노드에 Standby DB를 구성하여 Read Only 모드로 오픈하여 사용. Read Only 모드로 사용되는 Standby DB는 야간에 히다찌 투루카피 솔루션으로 데이타파일 복제를 통해 Consistency를 유지. 병원 종합시스템/인트라넷 병원 종합시스템/인트라넷 DR 센터 Physical Standby Oracle Database 10g RAC IBM AIX 5.2 P690 P4 16 CPU 48G RAM Oracle Database IBM AIX 5.2 P690 P4 16 CPU 48G RAM Oracle Database IBM AIX 5.2 P590 P4 8 CPU 24G RAM Oracle Database Data Guard Log Shipping Standby Instance 구성 ( ) Data 용량 : 2.4 TB 히다찌 트루카피 이용

References : 국내외 다수의 기업에서 사용
대부분이 업무의 특성을 고려한 고 가용성의 Oracle Database RAC 와 Oracle Standby Database로 운영. 아래에 기술한 고객들은 Physical Standby DB를 오픈하여 분석용 등의 용도로 데이타베이스를 활용하고 디스크 복제 솔루션을 활용하여 백업용도 및 다른 용도의 업무로 활용. 회사명 Standby DB 적용 업무 Protection 모드 DB 버전 삼성 서울 병원 의료 정보 검색 엔진용 Maximum Performance 서울 아산병원 병원 OCS 업무 분석용 Maximum Performance 서울대 병원 병원 OCS 업무 분석용 Maximum Performance 하나생명 보험 기간계 Maximum Performance 하이닉스 공장 자동화 Maximum Performance 청주 하이닉스 반도체 공장 자동화 Maximum Performance 청주 매그나칩 반도체 공장 자동화 Maximum Performance

EM 을 이용한 오라클 DataGuard 구성방안 (RAC + EM + DataGuard)

Similar presentations

Presentation on theme: "EM 을 이용한 오라클 DataGuard 구성방안 (RAC + EM + DataGuard)"— Presentation transcript:

Similar presentations

About project

지원

로그인

Auth with social network:

EM 을 이용한 오라클 DataGuard 구성방안 (RAC + EM + DataGuard)

Similar presentations

Presentation on theme: "EM 을 이용한 오라클 DataGuard 구성방안 (RAC + EM + DataGuard)"— Presentation transcript:

Similar presentations

About project

지원