Primary와 Standby 기동, 종료
Primary, Standby 기동, 종료와 Broker, ADG 조건을 구분하며 종료 전 최종 동기화와 전체 종료 결과는 확인 불가
#핵심 요약
실습 수동 구성은 전송 DEFER 후 Standby의 MRP와 DB를 내리고 Primary를 종료함
Broker, ADG 종료 실습에서는 적용 중지 후 Primary 아카이브, Primary 종료, Standby 종료 순서를 적음
기동은 Standby가 먼저지만 일반 Standby는 MOUNT, ADG 실습에서는 OPEN을 사용함
종료 전 리두 적용이 완료됐는지는 확인 불가
#개념과 동작 원리
| 실습 조건 | 종료 순서 | 기동 순서 |
|---|---|---|
| 수동 LGWR SYNC AFFIRM 구성 | Primary 전송 DEFER → Standby MRP 정지, DB 종료, 리스너 종료 → Primary DB, 리스너 종료 → OS 종료 | 양쪽 리스너, TNSPING → Standby MOUNT, MRP 수동 기동 → Primary OPEN → 전송 ENABLE, 로그 스위치, 상태 확인 |
| Broker, 일반 Physical Standby | 역할, SUCCESS, 지연 0 확인 → Standby 적용 중지 → Primary 아카이브 → Primary DB, 리스너 종료 → Standby DB, 리스너 종료 → OS 종료 | Standby 리스너, MOUNT → Primary 리스너, OPEN → Broker 구성 확인 |
| Broker, ADG 구성 후 | Broker 일반 종료와 같은 순서 | Standby 리스너, STARTUP → Primary 리스너, STARTUP |
수동 구성과 Broker 구성은 전송 중지 여부와 DB 종료 순서가 다르므로 조건을 생략한 단일 순서로 합치지 않았음 Broker 실습에서는 DG_BROKER_START=TRUE와 기존 구성을 유지한 상태에서 DMON이 MRP를 자동으로 올린다고 설명함 TRUE 값만으로 의도한 적용 상태와 자동 복구가 확인되는지는 수업 자료에서 별도로 검증하지 않았음
#주요 용어와 구성 요소
| 구문 | 의미 |
|---|---|
| MOUNT | Physical Standby를 열지 않고 Redo Apply하는 상태임 |
| READ ONLY와 적용 | 기본 STARTUP은 읽기 전용으로 열며, 열린 상태의 Redo Apply는 Active Data Guard 사용 조건을 충족해야 함 |
| APPLY-ON / APPLY-OFF | Broker의 적용 실행, 중지 의도 상태이며 DG_BROKER_START=TRUE와 별도임 |
#필수 명령어 또는 SQL
| 항목 | 실행 조건 |
|---|---|
| 작업 대상 | 현재 역할, Broker 상태, 전송 목적지 2, MRP, RFS, 기동 모드 |
| 필요 권한 | 본문 SQL은 SYSDBA, DGMGRL은 SYSDBA 또는 SYSDG, 리스너는 해당 소프트웨어 소유자 |
| 바꿀 입력값 | <STANDBY_UNIQUE_NAME>, 양쪽 접속 별칭과 전송 목적지 번호 |
| 결과 해석 | 전송, 적용의 상태 조회와 종료 전 최종 동기화 완료는 별개이며 마지막 리두 적용 완료 출력은 기재 없음 |
#종료 전 역할과 상태 확인
show configuration;
show database '<STANDBY_UNIQUE_NAME>';결과 해석: 실습에서는 원래 DB가 Primary인지, Configuration Status가 SUCCESS인지, Transport Lag와 Apply Lag가 0인지 먼저 확인함 역할이 바뀌어 있으면 실습에서는 Switchback을 적으며 그 절차는 역할 전환과 오류 상태에 구분했음
#수동 구성의 전송 중지와 재활성화
alter system set log_archive_dest_state_2=defer scope=both;select dest_id, status from v$archive_dest where dest_id=2;결과 해석: 실습에서는 STATUS가 DEFERRED인지 확인한 뒤 Standby 종료를 진행함
실습 수동 기동은 양쪽 리스너 시작과 양쪽 접속 별칭의 TNSPING 확인 다음에 아래 Standby 기동을 수행함
lsnrctl starttnsping <PRIMARY_CONNECT_ID>
tnsping <STANDBY_CONNECT_ID>결과 해석: 실습에서는 양쪽 별칭에서 OK를 확인한 후 DB 기동으로 넘어가며 실제 접속 시간 수치는 기재 없음
startup mountalter database recover managed standby database
using current logfile disconnect from session;결과 해석: 실습 수동 운영은 Standby를 OPEN하지 않고 MOUNT 상태에서 MRP를 시작함
startupalter system set log_archive_dest_state_2=enable scope=both;
alter system switch logfile;
alter system switch logfile;select dest_id, status, error from v$archive_dest where dest_id=2;select process, status, sequence# from v$managed_standby;결과 해석: 실습에서는 목적지 2의 VALID와 Standby의 RFS, MRP0 적용 상태를 확인함
#Broker와 ADG 기동 상태의 차이
| 구분 | 실습 Standby 기동 | 실습 확인 내용 |
|---|---|---|
| Broker 일반 구성 | STARTUP MOUNT | DMON 프로세스와 Broker 구성 SUCCESS |
| ADG 구성 후 | STARTUP | OPEN_MODE가 READ ONLY WITH APPLY라는 예시 출력 |
ADG 전환은 Active Data Guard의 APPLY-OFF, OPEN, APPLY-ON 단계임
일반 MOUNT 기동과는 절차가 다름
#구문과 옵션 설명
| 구문 | 의미 |
|---|---|
| DISABLE CONFIGURATION | Broker 관리를 중지하며 구성 파일의 구성 정의를 지우지 않음 |
| REMOVE CONFIGURATION | Broker 구성 정의와 관리를 제거하며 기본적으로 관련 전송 설정도 제거함 DB 자체나 데이터 파일을 삭제하는 명령은 아님 |
| V$ARCHIVED_LOG.APPLIED | 로컬 목적지는 항상 NO이며 Physical Standby에서 REGISTRAR=RFS인 행을 대상으로 의미를 읽음 |
#사용 조건과 주의사항
Broker, ADG 종료 실습에서는 MRP를 멈춘 뒤 아카이브하면 이후 갭이 없다고 적지만 마지막 전송, 적용 완료를 다시 조회하는 단계는 없음
실습에서는 DISABLE CONFIGURATION과 REMOVE CONFIGURATION을 모두 구성이 사라지는 명령으로 묶어 설명하며 두 동작의 차이를 확인한 근거가 없음
기존 Broker 구성을 유지하는 운영 조건임
위 두 명령의 효과가 같다는 실습 설명은 따르지 않음
Oracle Database 19c 기준으로 DISABLE은 구성 정의를 보존하며 REMOVE는 구성 정의와 관리를 제거함
REMOVE에서 관련 전송 설정을 유지하려면 PRESERVE DESTINATIONS 조건을 별도로 구분해야 함
이 차이는 Broker 명령의 효과이며 전체 종료 순서나 최종 동기화 완료를 보장하는 근거는 아님
Broker 기동 문서는 양쪽 V$ARCHIVED_LOG의 APPLIED='YES' 최대 번호 일치를 정상 기준으로 적지만 양쪽에서의 조회 의미와 비교 조건은 설명하지 않음
실습의 SHUTDOWN ABORT, VM 강제 종료 금지 주의는 유지하며 전체 DB, 리스너, OS 종료는 서비스 중단을 수반함
양쪽 DB에서 APPLIED=YES의 최대 시퀀스만 비교하는 방식으로 동기화를 판정하지 않음
Standby의 RFS 수신 행에서 YES는 데이터 파일까지 적용, IN-MEMORY는 메모리 적용 상태임
Primary가 계속 실행 중인 Standby 종료는 Primary의 해당 전송 목적지를 먼저 지연시키고 로그 스위치를 수행하는 운영 조건과 구분함