Data Guard 구성 전제조건
Data Guard의 로깅, 인증, SRL, 파일 전제이며 실습의 종료 대상, 경로, 설정 순서 일부는 확인 불가
#핵심 요약
실습 구축 입구는 12c File System이며 파라미터와 설치 경로에는 12.2가 사용됨
DB_NAME의 일치, 서로 다른 DB_UNIQUE_NAME, 양쪽 접속 설정과 패스워드 파일 준비가 포함됨
Standby에는 파일 경로 변환, 자동 파일 관리, 아카이브 위치와 FAL 설정이 제시됨
구축 순서는 Primary 생성과 Net 설정 → Standby 디렉터리, 파라미터 → Primary 파일 복사, Standby 제어 파일, SRL, ARCHIVELOG, 전송 설정 → Standby MOUNT, SRL, MRP 기동 → 로그 스위치로 동기화 확인임
#개념과 동작 원리
| 준비 대상 | 실습의 주요 설정, 작업 |
|---|---|
| DB 식별 | 같은 DB_NAME, 다른 DB_UNIQUE_NAME, 각 OS 환경의 ORACLE_SID 지정 |
| Oracle Net | 각 DB의 listener.ora 정적 등록과 양쪽 별칭을 담은 tnsnames.ora, 양쪽 TNSPING 확인 |
| 인증 | REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE, Primary의 패스워드 파일 생성, 복사, 전송 |
| 파일 준비 | 데이터, 제어, 리두 파일 복사, 별도 Standby 제어 파일을 생성해 Standby 제어 파일 위치에 배치 |
| Standby 저장 위치 | 제어 파일, 아카이브, 복구 영역, 데이터, 로그 경로 변환 지정 |
| 로그 | 양쪽 ARCHIVELOG 설정과 SRL 추가, Standby에서 MRP 기동 |
| 전송 | LOG_ARCHIVE_CONFIG, LOG_ARCHIVE_DEST_2, LOG_ARCHIVE_DEST_STATE_2, FAL_SERVER 설정 |
실습에서는 Standby의 STANDBY_FILE_MANAGEMENT=AUTO를 Primary 데이터 파일 추가의 자동 반영 설정으로 설명함 실습에서는 파일 복사 앞에 SHUTDOWN, Standby 제어 파일 생성 앞에 STARTUP MOUNT를 적지만 원격 SSH 이후 종료 명령의 대상 DB가 명확하지 않음
#주요 용어와 구성 요소
| 구문 | 의미 |
|---|---|
| FORCE LOGGING | 비로깅 적재로 Standby에 데이터가 누락되는 문제를 막기 위한 로깅 모드임 |
| SRL | 다른 DB에서 수신한 리두를 기록하며 리두 스레드별로 준비함 |
| 인증 경로 | Oracle Net 전송 인증과 파일시스템 복사에 사용하는 OS 접속은 별개임 |
#필수 명령어 또는 SQL
| 항목 | 실행 조건 |
|---|---|
| 작업 대상 | 소스, Standby의 이름, 파일, 로그, 아카이브 전송과 적용 |
| 필요 권한 | SQL*Plus SYSDBA, OS 파일 복사, 설정 편집은 DB 소프트웨어 소유자와 대상 경로 권한 필요 |
| 바꿀 입력값 | <DB_NAME>, 양쪽 <UNIQUE_NAME>, 접속 별칭, 실제 데이터, 로그, 제어 파일 경로 |
| 결과 해석 | 기존 실습 MRP, RFS 기록을 유지하며 누락된 로깅 설정 적용 여부와 전체 재실행 결과는 확인 불가 |
#Standby 파라미터의 주요 항목
compatible=12.2.0.0
db_name=<DB_NAME>
db_unique_name=<STANDBY_UNIQUE_NAME>
service_names=<SERVICE_NAME>
remote_login_passwordfile='EXCLUSIVE'
standby_file_management=auto
db_file_name_convert='<PRIMARY_DATA_DIR>','<STANDBY_DATA_DIR>'
log_file_name_convert='<PRIMARY_DATA_DIR>','<STANDBY_DATA_DIR>'
log_archive_dest_1='location=<ARCHIVE_DIR> valid_for=(all_logfiles, all_roles)'
log_archive_dest_2='service=<PRIMARY_CONNECT_ID> LGWR SYNC AFFIRM valid_for=(online_logfiles, primary_role)'
fal_server=<PRIMARY_CONNECT_ID>
fal_client=<STANDBY_CONNECT_ID>결과 해석: 실습에서는 DB_NAME을 Primary와 같게 두고 고유 이름과 파일 경로를 구분하며 FAL_SERVER를 Primary 쪽으로 지정함 설정 전체에 대한 적용 완료 출력은 기재 없음
#Primary 전송 설정과 조회
alter system set log_archive_config='dg_config=(<PRIMARY_UNIQUE_NAME>,<STANDBY_UNIQUE_NAME>)' scope=both;
alter system set log_archive_dest_2='service=<STANDBY_CONNECT_ID> LGWR SYNC AFFIRM valid_for=(online_logfiles,primary_role) db_unique_name=<STANDBY_UNIQUE_NAME>' scope=both;
alter system set log_archive_dest_state_2=enable scope=both;
alter system set fal_server=<STANDBY_CONNECT_ID> scope=both;alter system set log_archive_config='dg_config=(<PRIMARY_UNIQUE_NAME>,<STANDBY_UNIQUE_NAME>)' scope=both;select dest_id, status, error from v$archive_dest where dest_id=2;결과 해석: 실습 Primary의 확인 값은 DEST_ID 2의 VALID이며 Standby에 LOG_ARCHIVE_CONFIG가 없으면 RFS 접속 거부와 ORA-16057이 발생한다고 적음
#SRL 수와 크기 확인
select group#, thread#, bytes/1024/1024 mb from v$log;
select group#, thread#, bytes/1024/1024 mb, status
from v$standby_log;결과 해석: 구축 본문은 온라인 리두 5그룹, 각 100M과 SRL 6그룹, 각 100M을 사용하지만 ADG 보충 페이지는 온라인 리두 3그룹, 각 200M과 SRL 4그룹, 각 200M을 제시함 ADG 보충 페이지는 SRL을 온라인 그룹 수보다 하나 더 준비하고 크기를 맞추며, 역할 전환에 대비해 양쪽에 생성하라고 적음 구축 본문의 SRL 추가 명령은 아래 구축 순서에 있음
#실습 구축 순서 (12c 파일 시스템)
- Primary(실습
PROD):ORACLE_SID를 맞추고disk1~disk5디렉터리,initPROD.ora(db_name,db_unique_name,remote_login_passwordfile=EXCLUSIVE, 제어 파일 세 개)를 만든 뒤STARTUP NOMOUNT,CREATE DATABASE(리두 5그룹 각 100M, 멤버 2개),catalog.sql,catproc.sql,pupbld.sql로 수동 생성함(수동 DB 생성) - 양쪽: listener.ora를 정적 등록(
SID_LIST_LISTENER)으로 바꾸고, tnsnames.ora에 두 DB 별칭을 둔 뒤 양쪽에서tnsping함
방화벽은firewall-cmd --permanent --add-port=1521/tcp,firewall-cmd --reload로 1521만 엶 - Primary에서
orapwd file=orapw<PRIMARY_SID> format=12 force=y로 패스워드 파일을 만들고, Standby 이름(orapw<STANDBY_SID>)으로 복사해 Standby 서버$ORACLE_HOME/dbs로 보냄 - Standby: 데이터,
arch,flash디렉터리를 만들고initSBDB.ora를 준비함(아래 Standby 파라미터의 주요 항목, 실습은db_recovery_file_dest_size=4G) - Primary: 데이터, 제어, 리두 파일 위치를 저장해 두고(
dba_data_files,v$controlfile,v$logfile)SHUTDOWN IMMEDIATE뒤 파일을 Standby로 복사함 - Primary:
STARTUP MOUNT뒤 Standby 제어 파일을 만들어 Standby의 제어 파일 세 위치에 같은 파일로 둠 - Primary: MOUNT 상태에서 SRL을 추가하고(
V$STANDBY_LOG확인),ALTER DATABASE ARCHIVELOG,OPEN,CREATE SPFILE FROM PFILE뒤 전송 파라미터(LOG_ARCHIVE_CONFIG,LOG_ARCHIVE_DEST_2,LOG_ARCHIVE_DEST_STATE_2,FAL_SERVER)를 설정하고V$ARCHIVE_DEST의 DEST_ID 2가 VALID인지 봄 - Standby: PFILE로
STARTUP MOUNT, SRL 추가, SPFILE 생성 뒤 다시 MOUNT,LOG_ARCHIVE_CONFIG설정, MRP를 실시간 적용으로 기동함 - Primary에서 테이블스페이스를 만들고 로그 스위치를 세 번 한 뒤, Standby의
V$MANAGED_STANDBY에서 MRP0이APPLYING_LOG이고 RFS가 시퀀스를 받는지 확인함
ALTER DATABASE CREATE STANDBY CONTROLFILE AS '$HOME/physical.ctl' REUSE;
ALTER DATABASE ADD STANDBY LOGFILE
GROUP 10 ('<DATA_DIR>/disk4/redoG10M1.rdo', '<DATA_DIR>/disk5/redoG10M2.rdo') SIZE 100M,
GROUP 11 ('<DATA_DIR>/disk4/redoG11M1.rdo', '<DATA_DIR>/disk5/redoG11M2.rdo') SIZE 100M;
-- 실습은 그룹 10~15, 각 100M
SELECT group#, bytes/1024/1024 FROM v$standby_log;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;scp -rp <DATA_DIR>/* oracle@<STANDBY_HOST>:<STANDBY_DATA_DIR>/
scp $HOME/physical.ctl oracle@<STANDBY_HOST>:<STANDBY_DATA_DIR>/disk1/ctrl1.ctl
scp $HOME/physical.ctl oracle@<STANDBY_HOST>:<STANDBY_DATA_DIR>/disk2/ctrl2.ctl
scp $HOME/physical.ctl oracle@<STANDBY_HOST>:<STANDBY_DATA_DIR>/disk3/ctrl3.ctlSTARTUP MOUNT PFILE = '$ORACLE_HOME/dbs/initSBDB.ora'
ALTER DATABASE ADD STANDBY LOGFILE
GROUP 10 ('<STANDBY_LOG_DIR>/stby_redo10.log') SIZE 100M,
GROUP 11 ('<STANDBY_LOG_DIR>/stby_redo11.log') SIZE 100M;
-- 실습은 그룹 10~15, 각 100M
CREATE SPFILE FROM PFILE = '$ORACLE_HOME/dbs/initSBDB.ora';
SHUTDOWN IMMEDIATE
STARTUP MOUNT
ALTER SYSTEM SET log_archive_config = 'dg_config=(<PRIMARY_UNIQUE_NAME>,<STANDBY_UNIQUE_NAME>)' SCOPE = BOTH;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
SELECT process, status, sequence# FROM v$managed_standby;CREATE TABLESPACE ts01 DATAFILE '<DATA_DIR>/disk4/ts01.dbf' SIZE 10m;
ALTER SYSTEM SWITCH LOGFILE;
ALTER SYSTEM SWITCH LOGFILE;
ALTER SYSTEM SWITCH LOGFILE;결과 해석:
실습 기록: Standby의 V$STANDBY_LOG는 그룹 10~15 각 100M였고, MRP 기동 직후 V$MANAGED_STANDBY에 ARCH CLOSING, RFS IDLE, MRP0 Wait_for_log가 보였으며, Primary에서 로그 스위치 뒤에는 MRP0 APPLYING_LOG, RFS가 시퀀스 24를 받는 것으로 나왔음
Primary의 SRL은 역할 전환 뒤 Standby가 됐을 때를 대비한 것임
STANDBY_FILE_MANAGEMENT=AUTO와 DB_FILE_NAME_CONVERT 덕분에 Primary에서 만든 ts01 데이터 파일이 Standby 경로로 바뀌어 자동으로 만들어짐
수업 자료의 Standby 절차에는 MOUNT 뒤 ALTER DATABASE ARCHIVELOG, ALTER DATABASE OPEN 단계가 있으나, Standby 제어 파일로 MOUNT한 물리 Standby를 일반 OPEN하는 것은 아래 MRP 운영 단계와 맞지 않아 이 순서에는 넣지 않음(Active Data Guard의 READ ONLY 열기는 Active Data Guard)
#구문과 옵션 설명
12.2의 수동 구성 전제에는 Primary의 FORCE LOGGING과 ARCHIVELOG가 포함됨
compatible=12.2.0.0은 해당 실습의 설정값임
19c에는 별도의 Standby용 비로깅 모드도 있음
SRL은 소스의 각 리두 스레드마다 온라인 로그 그룹 수보다 최소 한 그룹 더 필요하며, 크기는 소스의 가장 큰 리두 로그 이상이어야 함
#사용 조건과 주의사항
Primary 본문에는 종료 직후 재기동 없이 OPEN하는 구간과 미완성 ALTER SESSION 문장이 있고 리스너 주석의 홈 버전도 설정 본문과 다름
Standby의 ARCHIVELOG, OPEN, SPFILE 작업과 이후 MOUNT 운영은 서로 다른 단계이며 이를 하나의 재실행 스크립트로 구성할 근거는 부족함
실습 방화벽 설정에는 실습용 전체 중지와 포트 허용이 함께 등장함
SRL 추가는 MRP 정지 상태에서 수행하라는 실습 주의가 있으며 적용 중 추가 시 ORA-01156을 적음
패스워드 파일 인증이면 Physical Standby에 Primary의 유효한 패스워드 파일 복사본이 필요함
파일 경로 변환과 AUTO 설정은 기존 파일을 덮어쓰지 않는지까지 확인해야 하며 본문의 경로, 파일명 자리표시는 셸 변수 자동 확장 보장이 아님