[Oracle] Oracle Data Guard 설치(4)

🧭 전체 로드맵 (끝까지 이 순서대로)

1️⃣ VirtualBox 설치
2️⃣ VirtualBox 네트워크 구성
3️⃣ Oracle Linux VM 2대 생성
4️⃣ OS 기본 설정
5️⃣ Oracle 19c 설치 (Primary)
6️⃣ ARCHIVELOG / FORCE LOGGING
7️⃣ Standby 준비
8️⃣ RMAN DUPLICATE
9️⃣ Data Guard 동작 확인
🔟 Switchover / Failover 테스트

 

이전 단계는 이전 글에서 이미 진행했으므로, 진행하지 않았다면 먼저 이전 글을 참고해 주세요.

[Oracle] Oracle Data Guard 설치(3)

---

Swithchover / Failover 테스트 전 Data Guard Broker 설정

🧭 Data Guard Broker 구성 로드맵

1️⃣ Primary / Standby에서 Broker 사용 설정
2️⃣ dgmgrl로 구성 생성
3️⃣ Primary/Standby 등록
4️⃣ 상태 검증
5️⃣ Switchover / Failover

 

---

1️⃣ Primary / Standby에서 Broker 활성화

양쪽 DB 모두에서 실행

ALTER SYSTEM SET DG_BROKER_START=TRUE SCOPE=BOTH;

확인:

SHOW PARAMETER dg_broker_start;

TRUE면 완료

 

---

2️⃣ Primary 서버에서 dgmgrl 접속

Primary에서 oracle 계정

dgmgrl sys/oracle@DGDB_PRI

접속되면 이런 프롬프트가 나옴

DGMGRL>

---

3️⃣ Broker 구성 생성 (Primary 기준)

 

CREATE CONFIGURATION dg_config
	AS PRIMARY DATABASE IS DGPRI
	CONNECT IDENTIFIER IS DGDB_PRI;

• dg_config : Broker 구성 이름(아무 이름이나 OK)
• DGPRI : Primary의 db_unique_name
• DGDB_PRI : tnsnames.ora에 정의한 서비스명

성공 메시지:

Configuration "dg_config" created.

 

---

4️⃣ Standby DB를 Broker에 추가(Primary)

ADD DATABASE DGSTBY AS CONNECT IDENTIFIER IS DGDB_STBY MAINTAINED AS PHYSICAL;

성공 메시지:

Database "DGSTBY" added.

 

만약 아래와 같은 에러가 나타난다면 참고

Error: ORA-16698: member has a LOG_ARCHIVE_DEST_n parameter with SERVICE attribute set Failed.

Broker는 redo 전송 경로를 자기가 관리하려고 하는데, DB 쪽에 이미 log_archive_dest_n = 'SERVICE=…'가 박혀 있어서 충돌남 

장애 해결 후 Broker 활성화부터 재진행

[Oracle] ORA-16698: member has a LOG_ARCHIVE_DEST_n parameter with SERVICE attribute set Failed.

 

 

Database - dgstby

  Role:               PHYSICAL STANDBY
  Intended State:     APPLY-ON
  Transport Lag:      12 minutes 8 seconds (computed 16 seconds ago)
  Apply Lag:          12 minutes 8 seconds (computed 16 seconds ago)
  Average Apply Rate: 863.00 KByte/s
  Real Time Query:    OFF
  Instance(s):
    DGDB

  Database Warning(s):
    ORA-16853: apply lag has exceeded specified threshold
    ORA-16855: transport lag has exceeded specified threshold
    ORA-16826: apply service state is inconsistent with the DelayMins property
    ORA-16789: standby redo logs configured incorrectly

Duplicate 시 경로 및 구성이 꼬여서 지연 및 경고 발생

장애 해결 후 Broker 활성화부터 재진행

[Oracle] Data Gurad Duplicate 재구성

 

 

---

5️⃣ Broker 구성 활성화(DGMGRL)

ENABLE CONFIGURATION;

이제 Broker가 Primary/Standby 상태를 관리하기 시작함.

---

6️⃣ 상태 점검 (중요)

전체 구성 상태(DGMGRL)

SHOW CONFIGURATION;

 

정상 예:

Configuration - dg_config

  Protection Mode: MaxPerformance
  Members:
  dgpri  - Primary database
    dgstby - Physical standby database

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated 9 second ago)

 

개별 DB 상태

SHOW DATABASE DGPRI;
SHOW DATABASE DGSTBY;

 

Standby 쪽에:

Transport Lag: 0 seconds Apply Lag: 0 seconds

이면 완벽.

---

7️⃣ 흔한 에러 & 체크 포인트

❌ ORA-16810 / ORA-16826

→ Redo Apply 미기동
→ Standby에서:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;

 

❌ ORA-12514 / ORA-12154

→ TNS 문제
→ tnsping DGDB_PRI / DGDB_STBY 재확인

 

---

✅ Data Guard Broker 구성 완료 후 테스트

1️⃣ Primary에서 로그 강제 증가시키기 (가장 빠른 방법)

🔹 로그 스위치 강제 실행

Primary DB에서 실행

ALTER SYSTEM SWITCH LOGFILE;

👉 실행할 때마다 sequence 번호 +1

 

여러 번 실행해도 됨:

ALTER SYSTEM SWITCH LOGFILE;
ALTER SYSTEM SWITCH LOGFILE;
ALTER SYSTEM SWITCH LOGFILE;

 

---

 

2️⃣ 실제 트랜잭션으로 로그 발생시키기 

① 테스트 테이블 생성 (Primary)

CREATE TABLE dg_test (id NUMBER, msg VARCHAR2(100));

---

② 데이터 INSERT + COMMIT

INSERT INTO dg_test VALUES (1, 'dataguard test 1');
COMMIT;
INSERT INTO dg_test VALUES (2, 'dataguard test 2'); 
COMMIT;

👉 COMMIT이 Archive Log를 발생시킴

---

③ 로그 스위치까지 같이 하면 더 확실

ALTER SYSTEM SWITCH LOGFILE;

---

3️⃣ Standby에서 증가 여부 확인 (⭐ 핵심)

Standby DB에서 실행

SELECT thread#, sequence#, applied FROM v$archived_log ORDER BY sequence# DESC;

 

정상 예시:

   THREAD#  SEQUENCE# APPLIED
---------- ---------- ---------
         1         40 YES
         1         41 YES
         1         42 YES
         1         43 YES
         1         44 YES
         1         49 YES
         1         50 YES
         1         51 YES
         1         52 YES
         1         53 YES

👉 SEQUENCE#가 계속 증가
👉 APPLIED = YES → Apply 정상

---

✅ 4️⃣ Apply가 실시간으로 도는지 확인

SELECT process, status, sequence# FROM v$managed_standby;

정상:

PROCESS      THREAD#  SEQUENCE#
--------- ---------- ----------
ARCH               0          0
DGRD               0          0
DGRD               0          0
ARCH               0          0
ARCH               0          0
ARCH               0          0
RFS                1         55
RFS                1          0
RFS                0          0
RFS                0          0
MRP0               1         55

• MRP0 → APPLYING_LOG
• sequence 값이 계속 변함

---

✅ 이제 실무 꽃🌸

👉 다음으로 할 것:
1️⃣ Switchover 실습 (무중단 역할 교체)
2️⃣ Failover 실습 (장애 상황 가정)
3️⃣ 장애 후 재구성(Reinstate)