RAC DB 생성과 검증

#핵심 요약

DBCA는 패치된 DB Home에서 한 번 실행해 세 노드를 선택하며 노드마다 독립 DB를 생성하지 않음

생성 후 인스턴스, PDB 상태, thread, UNDO, 공유 파일과 SQL 패치를 확인하는 계획임

장애 시험의 기대 결과와 복구 시간 목표는 측정 결과가 아님

#개념과 동작 원리

DBCA Summary에서 노드, 인스턴스 매핑과 메모리, 저장소, Recovery 옵션을 대조한 뒤 생성 결과를 확인함 실제 thread, UNDO, redo group을 조회한 뒤 계획과 비교하며 실행 중 리두 그룹을 삭제하지 않음

#필수 명령어 또는 SQL

dbca -executePrereqs -databaseConfigType RAC -nodelist <HOST_1>,<HOST_2>,<HOST_3>

결과 해석: DBCA 사전 검사 단계이며 성공 출력은 기재 없음

SELECT inst_id, instance_name, host_name, status FROM gv$instance ORDER BY inst_id;
SELECT thread#, status, enabled FROM v$thread ORDER BY thread#;
SELECT thread#, COUNT(*) groups_count FROM v$log GROUP BY thread# ORDER BY thread#;
SELECT name, log_mode FROM v$database;
SELECT inst_id, name, open_mode FROM gv$pdbs
 WHERE name='<PDB_NAME>' ORDER BY inst_id;
SELECT con_id, patch_id, action, status, action_time
FROM cdb_registry_sqlpatch
ORDER BY con_id, action_time;

결과 해석: 실습의 목표는 세 인스턴스 OPEN, 필요한 노드의 PDB READ WRITE, thread 대응, ARCHIVELOG와 SQL 패치 SUCCESS이며 실제 결과로 확인된 값은 아님

#수업 2노드 실습: DBCA로 RAC CDB 만들기

srvctl config database -db <DB_UNIQUE_NAME>
srvctl status database -db <DB_UNIQUE_NAME> -verbose
"$GRID_HOME/bin/asmcmd" lsdg

SELECT inst_id, instance_name, host_name, status FROM gv$instance ORDER BY inst_id;
SELECT name, open_mode FROM v$pdbs ORDER BY con_id;
SELECT thread#, group#, bytes / 1024 / 1024 AS size_mb, status FROM v$log ORDER BY thread#, group#;
ARCHIVE LOG LIST

mem_bytes=$(awk '/MemTotal/ {printf "%.0f", $2 * 1024}' /proc/meminfo)
printf 'physical_bytes=%s\nminimum_shmmax=%s\n' "$mem_bytes" "$((mem_bytes / 2))"
sysctl kernel.shmmax

결과 해석:

각 RAC 인스턴스는 자기 리두 thread를 쓰고 thread마다 최소 두 그룹이 필요함

사전 요구사항 검사의 DNS, SCAN 실패는 이름과 등록값을 고친 뒤, 메모리 부족은 가용 메모리와 두 인스턴스 설정을 줄인 뒤 다시 검사함

수업 자료는 kernel.shmmax가 물리 메모리 절반 이상인지 두 노드에서 확인하라고 하며, 4294967296은 물리 메모리 8GB일 때의 예임

생성 스크립트를 저장하면 민감한 값이 들어갈 수 있어 권한과 보관 위치를 확인함
진행 중 오류는 DBCA 로그의 첫 오류 코드부터 봄

정상 기준: 두 인스턴스 OPEN, PDB가 기대 모드, DATA, FRA 마운트, thread별 리두 그룹, ARCHIVELOG를 켰다면 ARCHIVE LOG LIST가 Archive Mode

생성 뒤 각 노드 .bash_profile에 ORACLE_SID(1번 <INSTANCE1>, 2번 <INSTANCE2>), GRID_HOME, GRID_SID(+ASM1, +ASM2)와 Grid, DB 환경을 바꾸는 alias를 둠

#3노드 런북의 운영 점검

olsnodes -n -s
crsctl check cluster -all
crsctl stat res -t
srvctl config scan
srvctl status scan
srvctl status scan_listener
srvctl status listener
srvctl status asm -detail
asmcmd lsdg
cluvfy stage -post crsinst -n <NODE1>,<NODE2>,<NODE3> -verbose

ocrcheck
ocrconfig -showbackup
crsctl query css votedisk

SELECT inst_id, instance_name, host_name, status FROM gv$instance ORDER BY inst_id;
SELECT inst_id, name, open_mode FROM gv$pdbs WHERE name = '<PDB_NAME>' ORDER BY inst_id;
SELECT inst_id, name, ip_address FROM gv$cluster_interconnects ORDER BY inst_id;
SELECT name, log_mode FROM v$database;

결과 해석:

Grid 명령은 Grid Home의 bin, srvctl config/status database는 DB Home의 srvctl로 실행함

crsctl stat res -t의 OFFLINE은 TARGET OFFLINE인 선택 자원인지, TARGET ONLINE / STATE OFFLINE인 장애인지 나눠 봄
출력이 길면 파일로 저장해 노드별 TARGET, STATE를 비교함

OCR, Voting 확인 결과는 날짜와 함께 보관함

GV$CLUSTER_INTERCONNECTS에 NAT나 Public 주소가 interconnect로 나오면 네트워크 구성을 다시 봄

#3노드 런북의 서비스 등록과 접속

srvctl add service -db <DB_NAME> -service <SERVICE_ALL> -pdb <PDB_NAME> -preferred <INSTANCE1>,<INSTANCE2>,<INSTANCE3> -policy AUTOMATIC
srvctl add service -db <DB_NAME> -service <SERVICE_FAILOVER> -pdb <PDB_NAME> -preferred <INSTANCE1> -available <INSTANCE2>,<INSTANCE3> -policy AUTOMATIC
srvctl start service -db <DB_NAME> -service <SERVICE_ALL>
srvctl start service -db <DB_NAME> -service <SERVICE_FAILOVER>
srvctl status service -db <DB_NAME>

Resolve-DnsName <SCAN_NAME> -Type A -Server <DNS_IP>
Add-DnsClientNrptRule -Namespace '.<DOMAIN>' -NameServers '<DNS_IP>'
Resolve-DnsName <SCAN_NAME> -Type A

결과 해석:

DBCA 기본 서비스만 시험하지 않고 PDB에 전체 인스턴스용 서비스와 1번 우선, 2~3번 대기 서비스를 따로 등록함
등록 전 DB와 PDB가 열렸는지 먼저 확인함

Resolve-DnsName -Server가 성공해도 SQL 클라이언트가 쓰는 실제 DNS 경로는 다를 수 있어 클라이언트에서 따로 접속해 봄
NRPT 규칙은 해당 도메인만 실습 DNS로 보내며, 회사 VPN의 기존 NRPT 규칙과 충돌하면 덮어쓰지 않고 호스트 DNS 구성을 조정함

접속 확인은 PDB에 시험 계정, 테이블을 만들고 //<SCAN_NAME>:1521/<SERVICE_ALL>로 여러 번 새로 붙어, 다른 인스턴스에서 같은 커밋 행이 보이는지 봄
접속 분산이 늘 33%씩일 필요는 없음

정상 기준: DB 인스턴스 셋 OPEN, OCR, DATA, FRA 디스크 그룹 MOUNTED, SCAN VIP, 리스너 셋, Voting File 셋, 두 서비스 등록과 신규 접속
세 노드 OS를 재기동한 뒤에도 같은 기준을 반복함

#3노드 런북의 장애 시험 계획

srvctl relocate service -db <DB_NAME> -service <SERVICE_NAME> -oldinst <INSTANCE1> -newinst <INSTANCE2>
srvctl status service -db <DB_NAME> -service <SERVICE_NAME>
srvctl relocate service -db <DB_NAME> -service <SERVICE_NAME> -oldinst <INSTANCE2> -newinst <INSTANCE1>

# 1번 노드 VM 강제 종료 뒤 생존 노드에서 반복 확인
crsctl stat res -t
srvctl status database -db <DB_NAME>
srvctl status service -db <DB_NAME>

결과 해석:

시작 조건은 세 DB 인스턴스, 세 SCAN, 세 Voting Disk가 정상인 상태이고, 한 번에 장애 하나만 주입하며 커밋된 시험 행 ID와 시각을 함께 기록함

먼저 서비스를 계획 이동(relocate)해 신규 접속이 옮긴 인스턴스로 가는지 본 뒤 원래대로 돌리고, 그다음 1번 노드 VM만 강제 종료함
기존 TCP 세션과 미커밋 트랜잭션이 자동으로 보존된다고 가정하지 않음

1번 노드를 다시 띄운 뒤 노드, 인스턴스, ASM, 서비스, SCAN을 같은 기준으로 다시 확인하며, 서비스가 자동으로 원래 자리로 돌아온다고 가정하지 않음

NIC 장애는 Public 또는 Private NIC 하나만 따로 떼어 시험하고, 모든 노드가 쓰는 host-only 네트워크 자체를 끄는 시험은 하지 않음

RMAN 백업(CONFIGURE CONTROLFILE AUTOBACKUP ON, BACKUP DATABASE PLUS ARCHIVELOG)은 선택이며, 같은 호스트의 +FRA에만 있는 백업은 호스트 디스크 장애의 복구 수단이 아님
전체 환경 백업은 세 노드 VM, shareable VDI 전부, DNS 서버 디스크를 같은 시점에 정상 종료 상태로 복사해야 하고, 공유 VDI는 VM 스냅샷으로 복원되지 않음

이 표와 절차는 런북의 계획이며 실제 측정 시각과 결과는 기재 없음

#사용 조건과 주의사항

#설치 후 점검 범위

Clusterware의 TARGET과 STATE를 비교하며 미사용 선택 자원의 OFFLINE과 필요한 자원의 실패를 구분함

OCR, Voting, ASM, SCAN, 리스너, DB, PDB를 각각 점검하고 재기동 후 서비스 복귀까지 확인함

접속 분포가 반드시 노드별 동일 비율일 필요는 없으며 하나의 공유 DB인지 확인함

계획 정지, 서비스 재배치, 노드 전원 장애, Public, Private 통신 장애와 DNS 장애를 서로 구분함 실습의 180초 신규 접속 복구는 실습 목표 예시이며 보장 시간이나 측정값이 아님 서비스 복구가 기존 TCP 세션과 미완료 트랜잭션의 자동 복원을 뜻하지 않으며 장애 노드의 인스턴스가 다른 노드에 추가 생성된다고 설명하지 않음