RAC, Data Guard, Stream는 Oracle의 고가용성 시스템에 있는 세 가지 도구입니다. 각각의 도구는 독립적으로 혹은 조합하여 사용할 수 있습니다. 이들은 초점이 다르며 다양한 시나리오에 적용됩니다.
RAC는 단일 장애 지점 해결과 로드 밸런싱에 탁월합니다. 따라서 RAC는 24시간 가동이 필요한 핵심 시스템에서 일반적으로 사용됩니다. 그러나 RAC 솔루션에서는 데이터가 단 하나의 복사본만 존재합니다. 저장소 오류는 RAID와 같은 메커니즘을 통해 방지할 수 있지만, 데이터 자체에는 중복성이 없어 단일 장애 지점에 취약할 수 있습니다.
Data Guard는 중복 데이터를 통해 데이터 보호를 제공합니다. 로그 동기화 메커니즘을 활용함으로써 Data Guard는 중복 데이터와 기본 데이터 간의 동기화를 보장합니다. 이러한 동기화는 실시간, 지연, 동기 또는 비동기와 같은 다양한 형태로 이루어질 수 있습니다. Data Guard는 소규모 기업의 원격 재해 복구 및 고가용성 솔루션에서 일반적으로 사용됩니다. 대기 시스템에서 읽기 전용 쿼리를 수행하여 기본 데이터베이스의 성능 부담을 줄일 수 있지만, Data Guard는 주로 성능 향상을 위한 솔루션은 아닙니다.
Streams는 Oracle Advanced Queue를 기반으로 하여 데이터 동기화를 가능하게 하고 여러 레벨에서 유연한 설정을 제공합니다. Oracle은 풍부한 API를 포함한 광범위한 개발 지원을 제공하기 때문에 Streams는 애플리케이션 레벨에서의 데이터 공유에 더욱 적합합니다.
Data Guard란 무엇입니까?
Data Guard 환경에서는 최소 두 개의 데이터베이스가 존재합니다: 하나는 외부에 서비스를 제공하는 개방 상태의 데이터베이스로, 기본 데이터베이스(Primary Database)라고 불리며, 다른 하나는 복구 상태에 있는 대기 데이터베이스(Standby Database)입니다. 실행 중인 동안 기본 데이터베이스는 클라이언트를 지원하고, 사용자 작업은 온라인 및 아카이브 로그에 기록되며, 이 로그들은 네트워크를 통해 대기 데이터베이스로 전송됩니다. 이러한 로그는 대기 데이터베이스에서 재생되어 두 데이터베이스 간의 데이터 동기화를 달성합니다.
Oracle Data Guard는 이 프로세스를 더욱 최적화하여 로그 전송 및 복구 작업을 자동화하고 간소화할 뿐만 아니라 다양한 매개변수와 명령을 제공하여 데이터베이스 관리자(DBA)의 업무를 간편하게 만듭니다.
소프트웨어 또는 하드웨어 업그레이드와 같이 기본 데이터베이스를 종료해야 하는 예상 요인이 있는 경우, 보조 데이터베이스를 기본 데이터베이스로 전환하여 클라이언트 서비스를 지속할 수 있습니다. 이를 통해 서비스 중단 시간을 최소화하고 데이터 무결성을 보장할 수 있습니다. 예기치 못한 문제로 인해 기본 데이터베이스를 사용할 수 없는 경우, 보조 데이터베이스를 강제로 기본 데이터베이스로 전환하여 클라이언트 서비스를 계속할 수 있습니다. 이러한 경우의 데이터 손실 수준은 구성된 데이터 보호 수준에 따라 다릅니다. 따라서 기본 데이터베이스와 보조 데이터베이스는 특정 데이터베이스에 고정되지 않은 개념적 역할입니다.
Data Guard 아키텍처
Data Guard 아키텍처는 세 가지 기능별 부분으로 나눌 수 있습니다:
1) 리두 전송:
기본 데이터베이스가 가동 중일 때 리두 로그는 지속적으로 생성되며, 이 로그를 대기 데이터베이스로 전송해야 한다. 이 전송 작업은 기본 데이터베이스의 LGWR 또는 ARCH 프로세스를 통해 수행될 수 있다. 아카이빙할 목적지에 따라 서로 다른 방법을 사용할 수 있지만, 특정 목적지에 대해서는 한 가지 방법만 선택할 수 있다. 해당 프로세스 선택은 데이터 보호 능력과 시스템 가용성에 상당한 영향을 미친다.
2) 재수신(Redo Receive):
대기 데이터베이스(Standby Database) 내의 RFS(Remote File Server) 프로세스는 로그를 수신하여 대기 리두 로그(Standby Redo Log) 또는 아카이브 로그(Archived Log) 파일에 기록하는데, 이는 기본 데이터베이스(Primary Database)의 로그 전송 방식과 대기 데이터베이스의 위치에 따라 달라집니다. 만약 로그가 대기 리두 로그 파일에 기록되는 경우, 기본 데이터베이스에서 로그 스위치(log switch)가 발생하면 대기 데이터베이스의 대기 리두 로그에서도 로그 스위치를 유발하며 해당 대기 리두 로그를 아카이브 처리합니다. 만약 로그가 아카이브 로그에 기록되는 경우, 이 작업 자체가 아카이빙 동작으로 간주될 수 있습니다.
3) Redo Apply:
Redo Apply 서비스는 보조 데이터베이스에서 주 데이터베이스의 로그를 재생하여 두 데이터베이스 간의 데이터 동기화를 달성하는 역할을 합니다.
Stanby 데이터베이스가 로그를 재생하는 방식에 따라 두 가지 유형이 있습니다: Physical Standby 및 Logical Standby.
Redo Apply이 발생하는 시점에 따라 두 가지 유형도 있습니다:
a) 실시간 적용: 이 방법은 대기 중인 리도 로그(Standby Redo Log)를 사용해야 합니다. 대기 중인 리도 로그에 로그가 작성될 때마다 복구가 실행됩니다. 이 방법의 장점은 남아 있는 로그들이 실시간으로 이미 복구되어 있기 때문에 데이터베이스 전환 시간을 단축할 수 있다는 것입니다.
나) 아카이브 시 적용: 이 방법은 기본 데이터베이스에서 로그 스위치오버가 발생할 때 로그를 적용하며, 대기 데이터베이스에서 아카이빙을 트리거합니다. 아카이빙 프로세스가 완료된 후 복구가 시작됩니다. 이는 기본 복구 모드이기도 합니다.
물리적 대기 vs. 논리적 대기
대기 데이터베이스는 두 가지 유형이 있습니다: 물리적 대기와 논리적 대기입니다.
1. 물리적 대기:
물리적 대기 데이터베이스는 기본 데이터베이스와 동일합니다. Data Guard는 REDO 적용을 통해 물리적 대기 데이터베이스를 유지합니다. 일반적으로 물리적 대기가 REDO를 적용하고 있지 않을 때에는 읽기 전용 모드로 열 수 있습니다. 만약 데이터베이스에 플래시백 영역이 지정되어 있다면, 일시적으로 읽기-쓰기 모드로 전환하여 작업할 수도 있습니다. 필요한 작업을 완료한 후에는 플래시백 데이터베이스 기능을 사용하여 읽기-쓰기 모드 이전의 상태로 다시 복원할 수 있으며, 이후 기본 데이터베이스로부터 REDO 데이터 적용을 계속할 수 있습니다.
참고: Oracle 11g에서 물리적 대기(Physical Standby)의 애플리케이션 기능이 향상되었습니다. 이 버전에서는 물리적 대기가 OPEN READ ONLY 모드일 때도 REDO 데이터 적용을 계속할 수 있어, 물리적 대기 데이터베이스의 사용 편의성이 크게 향상되었습니다.
물리적 대기의 기능:
1) 디지털 재해 복구 및 고가용성: 물리적 스탠바이(Physical Standby)는 재해 복구 및 고가용성을 위한 강력하고 효율적인 솔루션을 제공합니다. 스위치오버/장애 조치(failover) 관리를 간소화하고 계획적 또는 비계획적 다운타임을 줄입니다.
2) 데이터 보호: 물리적 스탠바이 데이터베이스를 통해 데이터 가드는 예기치 못한 재해 상황에서도 데이터 손실이 최소화되도록 보장합니다.
3) 기본 데이터베이스 작업 부하 분산: 백업 및 읽기 전용 쿼리와 같은 특정 작업을 물리적 대기 데이터베이스로 분산함으로써 기본 데이터베이스의 CPU 및 I/O 리소스를 절약할 수 있습니다.
4) 향상된 성능: 물리적 대기 데이터베이스에서 사용되는 REDO 적용 메커니즘은 SQL 코드 실행을 우회하면서 복구의 가장 낮은 수준에서 작동합니다. 이는 최고의 효율성과 성능을 제공합니다.
2. 논리 스탠바이:
논리 스탠바이 데이터베이스는 기본 데이터베이스(또는 그 백업본이나 복제본, 예를 들어 물리 스탠바이)를 기반으로 생성됩니다. 따라서 초기에는 물리 스탠바이 데이터베이스와 비슷합니다. 하지만 논리 스탠바이는 REDO 데이터를 SQL 실행을 통해 적용하기 때문에 물리 파일 구조 뿐만 아니라 데이터의 논리적 구조 역시 기본 데이터베이스와 다를 수 있습니다.
물리적 대기(Physical Standby)와 달리 논리적 대기(Logical Standby)는 일반적으로 읽기/쓰기(READ WRITE) 모드로 열려 사용자가 언제든지 접근할 수 있습니다. 즉, 논리적 대기 상태가 열려 있는 동안 SQL 실행이 이루어집니다. 이는 장단점이 모두 존재합니다. SQL 실행의 특성상 논리적 대기에서는 특정 데이터 유형과 일부 DDL/DML 문장에 대해 운영상의 제한이 있습니다. 지원되지 않는 데이터 유형은 DBA_LOGSTDBY_UNSUPPORTED 뷰에서 확인할 수 있습니다. 이러한 데이터 유형이 사용될 경우 데이터베이스 내의 완전한 일관성을 보장할 수 없습니다.
논리 스탠바이의 READ WRITE 모드를 활성화하면 보고 시스템으로 활용할 수 있어 시스템의 작업 부하를 줄일 수 있습니다.
논리적 스탠바이의 기능:
물리적 스탠바이의 이전에 언급된 특징들인 디자스터 리커버리, 고가용성, 데이터 보호 외에도 논리적 스탠바이는 다음과 같은 기능을 갖습니다:
1) 대기 서버에서 하드웨어 리소스를 효율적으로 활용: 논리적 대기 데이터베이스는 추가 인덱스 및/materialized 뷰를 생성하고 특정한 업무 요구를 충족시킬 수 있습니다. 또한 기본 데이터베이스에 존재하지 않는 새로운 스키마를 생성하고, 기본 데이터베이스에서는 적절하지 않은 DDL 및 DML 작업을 수행할 수도 있습니다.
2) 기본 데이터베이스 작업 부하 분산: 논리 스탠바이 데이터베이스가 기본 데이터베이스와 동기화 상태를 유지하면서도 열린 상태로 남아 있으면, 데이터 보호 및 보고 작업을 동시에 수행할 수 있습니다. 이는 기본 데이터베이스에서 보고 및 쿼리 작업 부담을 줄여주어 귀중한 CPU 및 I/O 자원을 절약할 수 있습니다.
3) 원활한 업그레이드: 논리적 대기(Standby)는 데이터베이스의 버전 간 업그레이드 및 패치 적용과 같은 작업에 활용될 수 있습니다.
데이터 보호 모드
데이터 가드는 최대 보호(Maximum Protection), 최대 가용성(Maximum Availability), 최대 성능(Maximum Performance)의 세 가지 데이터 보호 모드를 제공합니다.
1. 최대 보호:
이 모드는 데이터 손실이 전혀 없도록 보장합니다. 이를 달성하기 위해 모든 트랜잭션은 커밋하기 전에 로컬 온라인 리도 로그에 기록되는 것뿐만 아니라 대기 데이터베이스의 스탠바이 리도 로그에도 동시에 기록되어야 합니다. 기본 데이터베이스에서 커밋이 허용되기 위해서는 최소한 하나의 스탠바이 데이터베이스(여러 개가 존재하는 경우)에서 리도(REDO) 데이터를 사용할 수 있어야 합니다. 네트워크 단절과 같은 장애로 인해 스탠바이 데이터베이스를 사용할 수 없게 되면, 데이터 손실을 방지하기 위해 기본 데이터베이스가 종료됩니다.
이 모드를 활성화하려면 대기 데이터베이스를 대기 Redo 로그와 함께 구성하고, 기본 데이터베이스가 대기 데이터베이스로 아카이빙할 때 LGWR, SYNC, AFFIRM 모드를 사용하도록 설정해야 합니다.
2. 최대 가용성:
이 모드는 기본 데이터베이스의 가용성에 영향을 주지 않으면서 최고 수준의 데이터 보호 전략을 제공합니다. 로컬 트랜잭션을 커밋하기 전에 최소한 하나의 대기 데이터베이스(Standby database)의 대기 리도 로그(Standby Redo Logs)에 기록되도록 하는 점에서 최대 보호(Maximum Protection)와 비슷한 방식을 따릅니다. 그러나 차이점은 대기 데이터베이스에 접근할 수 없는 장애가 발생할 경우, 기본 데이터베이스가 종료되는 대신 자동으로 최대 성능 모드(Maximum Performance mode)로 전환된다는 점입니다. 대기 데이터베이스가 복구되면 기본 데이터베이스는 자동으로 다시 최대 가용성 모드로 전환됩니다.
이 모드는 데이터 손실을 최소화하는 것을 목표로 하지만, 완전한 데이터 일관성을 보장할 수는 없습니다. 최대 보호 모드와 마찬가지로 이 모드에서는 대기 데이터베이스가 대기 리도 로그(Standby Redo Logs)로 구성되어야 하며, 주 데이터베이스가 대기 데이터베이스로 아카이빙할 때 LGWR, SYNC, AFFIRM 모드를 사용해야 합니다.
3. 최대 성능:
이 모드는 프라이머리 데이터베이스의 성능에 영향을 주지 않으면서 최고 수준의 데이터 보호 전략을 제공합니다. 트랜잭션은 언제든지 커밋할 수 있으며, 현재 프라이머리 데이터베이스의 REDO 데이터는 하나 이상의 스탠바이 데이터베이스에 기록되어야 하지만 이는 비동기 방식으로도 가능합니다. 이상적인 네트워크 조건에서는 이 모드가 프라이머리 데이터베이스의 성능에 극히 미미한 영향을 주면서도 최대 가용성 모드와 유사한 수준의 데이터 보호를 제공할 수 있습니다. 이 모드는 스탠바이 데이터베이스를 생성할 때 기본으로 설정되는 보호 모드입니다. LGWR ASYNC 또는 ARCH 프로세스 중 하나를 사용하여 구현할 수 있으며, 스탠바이 데이터베이스에 스탠바이 REDO 로그가 필수적이지 않습니다.
데이터 보호 모드를 변경하는 단계:
1. 데이터베이스를 종료하고 Mount 상태에서 다시 시작하십시오. 만약 RAC 설정이라면 모든 인스턴스를 종료하고 Mount 상태에서 하나의 인스턴스만 시작하십시오.
2. 다음 구문을 사용하여 모드를 수정하십시오:
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY | PERFORMANCE};
예를 들어: SQL>ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION;
3. 데이터베이스 열기: ALTER DATABASE OPEN;
4. 수정된 데이터 보호 모드를 확인하십시오:
SQL>select protection_mode,protection_level from v$database;
로그 적용 서비스
Data Guard는 REDO를 적용하여 기본 데이터베이스와 대기 데이터베이스 간의 일관성을 보장합니다. 이러한 과정을 이면에서 조용히 지원해주는 것이 바로 유명한 로그 적용 서비스(Log Apply Services)입니다. 로그 적용 서비스에는 두 가지 유형이 있습니다:
1. REDO 적용: 물리적 대기 데이터베이스만 해당되며, 미디어 복구를 통해 기본 데이터베이스와 동기화 상태를 유지합니다.
2. SQL 적용: 논리적 대기 데이터베이스만 해당되며, 주요 기능은 LogMiner를 통해 SQL 문장을 분석하고 대기 측에서 이를 실행하는 것이다.
따라서 REDO 데이터를 적용할 때에는 물리적 대기 데이터베이스가 MOUNT 상태여야 하며, 논리적 대기 데이터베이스는 REDO 데이터 적용을 위해 READ WRITE 모드로 열립니다. 그러나 유지 관리 중인 객체는 기본적으로 읽기 전용으로 설정되어 있으며 논리적 대기 측에서 직접 수정할 수 없습니다.
프로페셔널한 솔루션으로 Oracle 데이터베이스 보호하기
Oracle Data Guard는 고가용성, 데이터 보호 및 재해 복구를 위한 강력한 솔루션입니다. 대규모 다운타임이나 데이터 손실을 감수할 수 없는 기업에게 필수적인 도구입니다. 그러나 데이터베이스 환경을 한층 더 보호하기 위해 프로페셔널한 백업 및 재해 복구 솔루션을 활용해 Oracle 데이터베이스를 백업하는 것이 권장됩니다.
Vinchin Backup & Recovery 는 가상 머신과 물리 서버 모두에서 데이터베이스를 보호할 수 있는 강력한 기능을 제공하며, 자동화, 유연성, 효율성이 뛰어납니다. Oracle DB, MySQL, SQL Server, Postgres Pro 및 MariaDB 등 다양한 유형의 데이터베이스 보호를 제공하며, 데이터베이스 압축, 중앙 집중식 작업 관리, 스마트 백업 전략, 핫 데이터베이스 백업 및 고급 SQL Server/Oracle 지원을 포함합니다. 또한 강력한 랜섬웨어 보호 기능과 10개 이상의 가상 플랫폼 간에 이뤄지는 V2V 마이그레이션 기능도 지원합니다.
Vinchin Backup & Recovery는 수천 개의 기업에서 선택한 솔루션입니다. 여러분도 60일간의 풀기능 체험판으로 강력한 시스템을 바로 사용해 보실 수 있습니다! 또한, 문의하기 페이지에서 요구사항을 남겨 주시면贵사의 IT 환경에 맞춘 솔루션을 제공받을 수 있습니다.
결론
Oracle Data Guard는 재해 복구, 고가용성, 데이터 보호 및 워크로드 분산을 위한 종합적인 솔루션을 제공하는 기업용 Oracle 데이터베이스 배포의 핵심 구성 요소입니다. 유연한 아키텍처와 다양한 운영 모드를 지원하여 다양한 업무 요구와 운영 조건에 맞게 적응할 수 있습니다.
Vinchin Backup & Recovery를 선택하여 Oracle 데이터베이스를 간편하게 백업 및 복구할 수 있습니다. 무료 체험 기회를 놓치지 마세요!
