4. 데이터 손실과 다운타임
유통 업체에서 생긴 실제 문제
• 운영 데이터베이스의 alert.log 에 나타난 에러:
– Errors in file /opt/app/oracle/admin/dg/bdump/dg1.trc:
– ORA-01186 : file 93 failed verification tests
– ORA-01251 : Unknown File Header Version read for file
number 93
ORA-01251 - Corrupted file header. This could be caused
due to missed read or write or hardware problem or
process external to oracle overwriting the information
in file header.
• 데이터베이스 비정상 종료 및 어플리케이션 종료
5. <Insert Picture Here>
Active Data Guard의 특장점
-Remote Mirroring
-Data Guard 특징
-Data Guard Advantages
-Active Data Guard Benefits
6. 비교 – 스토리지 원격 복제
”Mirror Everything” InActive
장애 발생 시
매뉴얼 하게 기동
Production DB Standby DB
Network I/O
Control Control
Files
fil
Files
fil
Online Online
Logs Logs
Archive Archive
Logs Logs
Updates Flashback Flashback
Logs Logs
Data Data
Files Files
SYSTEM SYSTEM
USER USER
TEMP TEMP
UNDO UNDO
7. 비교 – Oracle Data Guard
”Recovery Data Only”
Production DBMS Standby DBMS
Control
Oracle apply
Filesfil
Network I/O Oracle validation
Online
Logs
Archive 27X fewer
Logs network
Updates Flashback I/Os*
Logs
Data
Files
SYSTEM
USER
TEMP
UNDO
*www.oracle.com/technology/deploy/availability/htdocs/DataGuardRemoteMirroring.html
8. Data Guard vs Remote Mirror
Zero Data Loss Over Long Distance & Delayed apply기능
• 국지적인 재난도 피할 수 있을 만큼의
충분한 거리를 두고 구성 가능
• Zero data loss mode로 구현
100 miles 200 miles 300+ miles
Data Guard: Synchronous Redo Shipping
Delayed Apply기능 지원(optional):
Redo data를 일정시간이 지난다음 반영하도록 설정
Synchronous Disk 가능 - Operational Error를 감지 후 standby site를
Mirroring 이용해 복구가능: flash back기능으로 대체 가능
9. Data Protection
Protection from data corruptions
어떤 시스템이라도 장애가 발생할 가능성이 있고 이로 인한 data
corruptions 이 발생할 수 있다 : NIC, Memory, Volume Manager, File
System, OS, HBA, SAN Switch, Disk Controller, RAID, Storage
Array등등 – DR solution의 이중화된 데이터에는 이러한 data
corruptions이 반영되어서는 안 된다.
– Data Guard: database간의 – Remote Mirroring & Stretch
의존성이 약한 Architecture로 disk Clusters : storage stack /
block을 직접 copy하는 것이 아니라 corrupted bits에서 발생한
전달된 Redo를 검증하면서 DR 에러가 DR로 전달되어 영향을
site에 반영하므로 data 미친다
corruptions이 전달되지 않도록
보호할 수 있다.
10. Data Guard Advantages
1. Network Efficiency 3. Better Data Protection
• Data Guard:Redo data만 전송 • logical and physical
• Remote mirroring solutions: datafiles, corruption들로 부터 보호 가능
archivelog files, redolog file들 모두
복제 4. Functionality
• DBA가 이해하기 쉬운 DR
solution
:backup/recovery와 유사
7x 27x Redo Apply/SQL Apply
Remote Mirroring
5. Flexibility
Data Guard • storage vendor 종속적이지 않음
Network Bandwidth Network I/Os
6. Maximum ROI
2. Better suited for WANs • DR투자 효과 증대
• Standard TCP/IP 이용- no protocol reporting/query용으로 활용
converters needed
11. Active Data Guard Benefits
• Primary DB의 부하 감소 및 성능 향상
• Primary 의 Workload(Reporting, Backup)를 Standby DB로 분산
• DR + Up-to-Date Reporting
• 3rd Party Solution 은 구현 불가
• Replication 솔루션
• 기존 Replication Solution 에 비해 부하가 매우 적고 관리가 단순
• 비용 절감
• 하나 또는 복수개의 Physical Standby DB로 HA, Backup 수행,
Reporting, Test 서버 구현
12. 적용전 - Active Data Guard
운영 서버에서 모든 워크로드를 수용
2000
Read-write service
1500
480 tps
1000 Read-only service
640 tps
500
Primary server at
0
100% of capacity
Production Data Guard
Database Standby
13. Active Data Guard 11g
운영 서버의 성능을 최적화
2000
1500 read-write service
1,680 tps
1000
+250%
read-only service
500 1,350 tps
+110%
0
Production Active Data Primary server at
Database Guard Standby 60% of capacity
14. Active Data Guard Use Examples
• Education – 학교성적 보고서, 교칙, 과목소개 …
• Financial - transaction 조회, 시장가격, 거래내역 …
• Healthcare – 의료 정보 조회, 의사/간호사조회, 의료시설 조회 …
• Legal – 법률 보고서, 재판 내역, 배심원 평결내역 …
• Telecommunications – 사용 내역, 미사용 시간, 과금 요율 …
• Transportation – 배송사태 추적, 운송 요율 조회 …
• Web-business – 카탈로그 조회, 가격비교, 주문 현황 …
Bottom Line …
• Active Data Guard를 사용하면:
• 실시간 Read-only성 작업을 physical standby에서 수행가능하고
• production database의 부하를 덜어 줄 수 있음.
15. 테스트 환경으로 활용
With Snapshot Standby
Physical Standby • Standby Database 를 Test나
Apply Redo 개발 환경으로 사용
• DR구축 비용을 줄일 수 있음
Open Back out • DR환경에서 전반적 test가 가능
Database Changes • Data loss가 없도록 유지
• 그러나 Snapshot mode로 전환 후
에는 redo적용이 잠시 보류되어
Snapshot Standby 실시간 조회는 제한됨
Perform Testing • Storage snapshots과 유사하지만:
• 동시에 DR기능 유지하고
Continuous Redo Shipping • 하나의 storage 복사본만 사용
16. <Insert Picture Here>
Active Data Guard 구성 및
동작 원리
- Active Data Guard Deployment
- Active Data Guard Transport Services
- Active Data Guard Apply Services
- Active Data Protection Mode
17. Active Data Guard Reader Farm
쿼리 성능에 대한 Scale-out
queries
Active Data Guard
queries
Reader Farm
updates queries
queries
queries
Production Standby
Database Databases
Reporting, web content browsing (including DR)
18. Active Data Guard Transport Services
Transactions
Production Standby
Synchronous
LGWR LNS RFS
Production Standby
Database Redo
Logs
Online Asynchronous
Redo LNS RFS
Logs
ARCH
Gap Resolution
ARCH RFS
Archived Archived
Redo Logs Redo
Logs
19. Active Data Guard Apply Services
Standby
Standby (Redo Apply MRP)
Redo Redo Logs
Data RFS
From Apply
Site A
Standby
ARCH
Database
Archived
Redo
Logs
20. Redo 전송 vs. 보호 모드
보호 모드 – 장애 발생 시에 대한 대응 방식
Primary 장애 시
보호 모드 데이터 손실 위험 Redo 전송 Standby로부터 응답이 없는 경우
Maximum 무 손실
SYNC Primary DB를 shutdown
Protection 이중 장애 보호
Maximum 무 손실 Timeout 임계 값 초과 시 Maximum
SYNC Performance 모드로 자동 전환
Availability 단일 장애 보호
Maximum 소량의 데이터 손실 Primary DB는 standby로부터의 응답을 결코
Performance 가능
ASYNC 기다리지 않음.
LOG_ARCHIVE_DEST_n parameter의 NET_TIMEOUT 속성
Data Guard 11g 기본값 = 30 seconds
21. 자동 Gap 해소
Standby
Transactions Oracle Net 데이터베이스
Redo
Buffer
SYNC NSA MRP
SGA RFS
ASYNC NSS LSP
LGWR Standby
Primary Online Redo
Redo Logs
데이터베이스 Logs
조회리
poll ARCH 포트
ARCH RFS Testing
백업
Archived
Redo Logs
22. 전송 압축
Advanced Compression Option
대역폭에 제한이 있는 환경에 이상적
11gR1: ASYNC 모드 및 gap 해소, 11gR2: SYNC 모드
2500 압축 비적용
22 MB/sec
2000
압축 적용
1500 12 MB/sec
전송 지연
테스트 세부 사항
- MB 1000
• ASYNC 방식
500 • 12.5 MB/sec 대역폭
• 22 MB/sec redo 생성
0 비율
시간 - 분 • 50% 압축 비율
23. Redo 적용 최적화
병렬 처리 기법 적용
• Media Recovery Coordinator 프로세스 (MRP0)
• 복구 세션들에 대한 관리 수행
• 복수 instance로부터 받은 redo를 병합
• Redo 데이터를 parse하여 Apply 프로세스들 사이에 적절히 분배
• Apply 프로세스
• 데이터 블록을 읽어서 redo 변경 사항을 적용
Parallel Media Recovery - 4 CPU server
apply process (pr00)
Media Recovery Coordinator (MRP0)
apply process (pr01)
coordinator & thread merger
apply process (pr02)
• Apply 프로세스의 개수 자동 설정 = # CPUs - 1
24. 데이터 손상의 Online 복구
• 자동 블록 복구
• Primary 데이터베이스에서 블록 손상이 발견되면, active standby 데이터
베이스에 존재하는 정상 블록 이미지가 자동으로 copy되어 online으로
복구 (역으로 standby에서 블록 손상이 발견되는 경우에도 마찬가지 방
식으로 동작)
• 사용자 및 어플리케이션에 투명하게 동작
Read/Write 실시간
Workload 리포트
지속적인 redo
전송, 검증 & 적용
Primary Active Standby
데이터베이스 데이터베이스
Oracle Database 11g Release 2
28. Switchover 및 Failover
Switchover
• 계획된 역할 전환
• 데이터 손실은 없음
• 데이터베이스의 re-instantiation 불필요
• 데이터베이스 업그레이드, 시스템 refresh, 데이터 센터 이동, OS 또는
하드웨어 유지보수 등에 활용
Failover
• Primary의 예기치 못한 장애
• Flashback Database 기능을 이용하여 원래의 primary 데이터베이스를
reinstate
• SQL 또는 Enterprise Manager GUI를 통해 수동으로 수행하거나
• Data Guard Fast-Start Failover 기능을 통해 자동화 가능
29. 장애에 의한 Downtime의 감소
Fast-Start Failover
• 자동화된 데이터베이스 failover
• 데이터베이스 down
• 지정된 health-check 조건 만족 시
Data • 또는 어플리케이션 요청에 의해
Guard
Observer • 지원되는 보호 모드
• Maximum Availability 모드
SYNC / /ASYNC
SYNC ASYNC (10gR2)
• Maximum Performance 모드
(11gR1)
• 역할 기반 서비스와의 통합 (11gR2)
Site A Site B • 서비스의 자동 재배치
Standby
Primary Primary
Standby
• 클라이언트 알림 & 자동 재 접속
30. 어플리케이션 Failover
어플리케이션 tier가 살아 있는 경우
Primary 사이트 Standby 사이트
3 FAN에 의한 클라이언트
어플리케이션 Tier - Oracle 알림, TAF/FCF에 의해
Application Server Clusters 어플리케이션은 새로운
primary로 자동 재 접속
2 역할 기반의
데이터베이스
서비스가
데이터베이스 Tier- Oracle 자동으로 시작
Real Application Clusters (11.2)
Data Guard
데이터베이스 1Data Guard
자동
서비스 Redo Transport Standby가
Standby
Failover
primary 역할
Database
Primary takeover
데이터베이스
31. 어플리케이션 Failover
완전한 사이트 Failover
Primary 사이트 Primary 사이트
Standby Site
WAN traffic
3 WAN traffic
DNS failover에
manager 의해 사용자들이
manager
새 primary로
Firewall
Firewall
route
어플리케이션 Tier - Oracle
mid-tier
Application Server Clusters 2
시작
Firewall Firewall
데이터베이스 Tier- Oracle Standby가
Real Application Clusters primary의
역할 takeover
1 Data Guard
Data Guard
자동 Failover
Redo Transport
33. 고객 적용 사례
"건강보험심사평가원은 전국 6 만 7 천여 곳 요양기관의
의약품 처방과 조제 단계에서 실시간으로 중복 처방 여부를
확인하는 DUR(Drug Utilization Review) 시스템을 Oracle
MAA 솔루션을 기반으로 구축해 기존 3-4 시간에 육박하던
시스템 장애 복구시간을 무려 2 분내로 단축하고, 수시로
비상대기 시스템을 모니터링해 하루 1300 만 건에 달하는
데이터점검 과정에서의 예상치 못한 다운 타임을 최소화
했다.”