[Exadata day4] 통합운영 아키텍처, 마이그레이션, 대용량 데이터 로딩, 모니터링

카테고리 없음 2025. 10. 23. 16:44

🧰 10~12장: 운영 및 데이터 로딩

10장: Consolidation 전략 및 권장 아키텍처
11장: 데이터베이스 마이그레이션 방법(논리/물리적)
12장: 대용량 데이터 로딩(DBFS, ACFS, 외부 파일 시스템)

🖥️ 13~16장: 모니터링

13장: Exadata Database Machine Platform Monitoring :: 엑사데이터머신
14장: Monitoring Exadata System Software Components :: 엑사 시스템 소프트웨어 구성요소
15장: Configuring Enterprise Manager Cloud Control to Monitor Exadata Database Machine ::
16장: Monitoring Exadata Storage Servers

오늘 배운 내용 요약정리

10장: Consolidation 전략 및 권장 아키텍처

=

1. Consolidation(통합)의 목적

비용 절감: 하드웨어, 라이선스, 운영 인력 효율화
자원 효율 극대화: CPU, 메모리, I/O 활용도 향상
관리 표준화: 패치·백업·보안 정책 단일화

2. 권장 아키텍처 유형

방식설명특징

멀티테넌트(CDB/PDB)	한 인스턴스에 여러 PDB 운영	경량·패치 일원화·신속 마이그레이션
스키마 통합	하나의 DB 인스턴스에 여러 스키마	단순하지만 격리성 약함
VM 기반 통합	KVM 가상화 활용	격리성↑, 자원 분리 명확
Bare Metal	전통적 단일 DB 인스턴스 통합	단순하나 유연성↓

👉 Exadata 권장 통합 방식: 멀티테넌트 + Instance Caging + IORM

3. CPU 및 메모리 통합 전략

CPU_COUNT로 Instance Caging 설정 → 자원 분배/보장
오버프로비저닝 vs 파티셔닝
- 오버프로비저닝: 자원 공유(성능 민감도 낮은 DB에 적합)
- 파티셔닝: 자원 보장(핵심 업무 DB에 적합)
메모리는 전체 물리 메모리의 75~85% 이내만 사용 권장

4. I/O Resource Management (IORM)

여러 DB가 공존할 때 디스크 I/O 자원 보장을 위한 핵심 기능
DB별·PDB별 IORM plan 설정 → 특정 DB의 과도한 I/O 점유 방지

program -> process (자원(cpu, memory)할당받은 상태)->thread

프로세스할당상태 : program -> mainmemory (RAM) <- cpu

자원 부족하면 LRU 기반으로 관리. 내보내는 작업 swap(HDD, SDD) swapping 잦으면 성능 down

11장: 데이터베이스 마이그레이션 방법(논리/물리적)

1. 마이그레이션 설계 순서

소스 DB 아키텍처 파악 (CDB or Non-CDB, OS/Endian, 캐릭터셋)
타깃 Exadata 용량 계획
Downtime 허용 여부 판단
마이그레이션 방식 결정
테스트 후 실제 이관

2. 물리적 마이그레이션 (Physical)

특징: 구조 변경 없음, 빠르고 안정적, 다운타임 짧음

방식설명장점제약

RMAN	백업/복구 또는 Duplicate 활용	안정성 높음	OS/Endian 호환 필수
Data Guard	Physical Standby 구성 후 switchover	실시간, 다운타임 최소	라이선스 필요, 구성 복잡
TTS/TTDB	테이블스페이스 단위 또는 전체 DB 이관	가장 빠른 방법	TTDB는 Endian 동일 필요, TTS는 RMAN CONVERT로 엔디언 변환 가능

👉 실무에서 가장 많이 쓰는 조합

TTS로 bulk 이관 + GoldenGate로 동기화 + Cutover

3. 논리적 마이그레이션 (Logical)

특징: 구조 변경 가능, 유연하지만 느림

방식설명장점제약

Data Pump (expdp/impdp)	구조·데이터 논리적 덤프	버전 호환 유연	대용량 시 느림
Insert as Select (DB Link)	네트워크 통해 직접 적재	별도 파일 불필요	다운타임 발생 가능
Logical Standby	SQL apply 기반 실시간 복제	다운타임 최소	제약 많고 구성 복잡
GoldenGate	실시간 복제	다운타임 최소	추가 라이선스 필요

4. 멀티테넌트 환경 이관

Non-CDB → CDB 이관:
- Unplug/Plug + Non-CDB to PDB 변환
CDB → CDB 간:
- Unplug/Plug PDB
- 다운타임 최소, 가장 빠른 방식 중 하나

👉 멀티테넌트 구조에서는 마이그레이션 절차가 단순화되는 것이 큰 장점입니다.

12장: 대용량 데이터 로딩(DBFS, ACFS, 외부 파일 시스템)

1. Exadata에서 대용량 적재 시 고려 사항

병렬성 확보 (Granule 단위 병렬 처리)
압축 파일은 병렬 granule 불가 → 미리 압축 해제 권장
I/O 대역폭 최대로 활용하기 위해 Direct Path Load 적극 활용

2. DBFS / ACFS / 외부 파일 시스템 차이

파일시스템설명특징사용 예

DBFS	DB 테이블에 저장된 파일을 파일처럼 접근	안정성, 백업 용이, 성능은 다소 낮음	소규모 파일, 안정성 중요
ACFS	ASM 기반 범용 파일시스템	Exadata에서 가장 권장되는 파일 시스템	대용량 CSV, 데이터 적재
외부 FS(NFS 등)	외부 스토리지 마운트	간편, 병렬 처리는 가능하지만 네트워크 병목 주의	임시 적재/ETL

👉 실무에서는 ACFS가 대용량 로딩 표준

3. 외부 테이블 & 병렬 Granule

Granule 크기: 기본 10MB
Granule 생성 불가: 압축 파일, 시리얼 디바이스
병렬도는 granule 수 or 파일 개수로 결정됨
여러 파일로 나누는 것이 병렬 처리에 유리

CREATE TABLE ext_data ( id NUMBER, name VARCHAR2(50) ) ORGANIZATION EXTERNAL ( TYPE ORACLE_LOADER DEFAULT DIRECTORY acfs_dir ACCESS PARAMETERS ( RECORDS DELIMITED BY NEWLINE FIELDS TERMINATED BY ',' ) LOCATION ('file1.csv', 'file2.csv', 'file3.csv') ) PARALLEL 8;

4. 로딩 성능 향상 팁

Direct Path Load (INSERT /*+ APPEND PARALLEL */)
ACFS + 여러 파일 + Granule 기반 병렬 적재
로딩 후 NOLOGGING 옵션 사용 시 redo 감소
임시 인덱스 생성 지연 (로딩 후 생성)
압축 사용 지양 (병렬 granule 분할 불가)

📌 최종 핵심 포인트 요약

구분핵심 개념키워드

10장	통합 전략	멀티테넌트, Instance Caging, IORM, 자원 보장
11장	마이그레이션	TTS, RMAN, Data Pump, GoldenGate, 논리 vs 물리
12장	대용량 적재	Granule 10MB, ACFS 권장, 병렬 적재, Direct Path Load

👉 실무 TIP

Consolidation 설계 단계에서 자원(CPU/메모리/I/O) 분배를 확정해두면 나중에 마이그레이션, 로딩 작업이 훨씬 수월합니다.
Exadata의 병렬성과 Smart Scan은 “파일 준비” 단계에서 대부분 성능이 결정됩니다

10장 Consolidation Options and Recommendations

Exadata 운영·통합 핵심 정리

1) 메모리 운영 원칙

전체 서버 기준 여유 메모리: 항상 **최소 5%**는 남겨두기
DB들이 합쳐 쓰는 상한: RAM의 75~85% 이내 (권장 상한 = 85%)
초기 배분 감각: 통합 환경이면 주요 DB 1개당 ~40~45% 수준에서 시작해 점증(다른 작업/OS 여유 고려)

HugePages(=대페이지) 필수

기본 4KB 대신 2MB 페이지로 메모리 할당 → TLB 미스↓, 스왑 방지
DB 파라미터:
- USE_LARGE_PAGES=ONLY (권장; HugePages 없으면 기동 실패해서 설정 누락 방지)
- 주의: HugePages 사용 시 AMM(Automatic Memory Management) 미지원 → ASMM(SGA_TARGET/ PGA_AGG…)으로 운용

메모리 계산(러프 가이드)

OLTP: 총 메모리 ≈ SGA + PGA + (PROCESSES × 4MB 오버헤드)
DW: 병렬·해시/정렬 많아 PGA 3배 가중
- 총 메모리 ≈ SGA + (PGA × 3) + (PROCESSES × 4MB)
PGA 관련
- 목표치: PGA_AGGREGATE_TARGET
- 하드 상한: PGA_AGGREGATE_LIMIT

2) OS 커널 파라미터(리눅스) 요령

공유메모리 식별자 수: kernel.shmmni > DB 개수
최대 공유메모리 세그먼트 크기: kernel.shmmax ≈ RAM의 85%
세마포어 (kernel.sem = SEMMSL SEMMNS SEMOPM SEMMNI)
- SEMMNS(시스템 총 세마포) ≥ 모든 DB의 PROCESSES 합
- SEMMSL(집합당 최대 세마포) ≥ 가장 큰 DB의 PROCESSES
요지는: OS 세마포 한도 ≥ DB 프로세스 수요

3) 프로세스/세션·병렬 관리 베스트프랙티스

PROCESSES(동시 접속 한도; DB 파라미터)

2~10개 DB 통합: 50 + (50 × DB개수)
11개 이상: 450 + (10 × DB개수)

병렬 서버 상한

2소켓 서버: 모든 DB의 PARALLEL_MAX_SERVERS 합 ≤ 240
8소켓 서버: 합 ≤ 1280
Data Guard redo apply 병렬 ≤ 16

활성 세션(프로세스) 밀도

일반 워크로드: Active ≤ 5 × CPU_COUNT
매우 CPU집약: Active ≤ 1 × CPU_COUNT

연결 관리

커넥션 풀(UCP/Hikari 등) 사용
필요 시 Shared Server(공유 서버) 로 프로세스 감소
연결 폭주(rate limit) 방지(미들웨어/리스너/Firewall 레벨)

4) CPU 자원 분배: Instance Caging

DB별 CPU_COUNT로 코어 할당 (DB 리소스 매니지먼트의 핵심)
두 방식
- 파티션(보장): 총합 ≤ 물리 코어 → 항상 보장(미션 크리티컬)
- 오버프로비저닝: 총합이 물리 코어 초과 가능 → 유휴 코어 공유(비크리티컬)
권장
- DB별 CPU_COUNT 최소 2 이상
- 중요 DB의 합계 ≤ 물리 코어
- 덜 중요한 DB는 최대 3배수 내에서 오버프로비저닝 가능
- 하드 캡 필요 시 Resource Manager의 MAX_UTILIZATION_LIMIT로 상한

5) HugePages & 스와핑 이야기 (이해 포인트)

프로세스가 많아지고 메모리가 부족하면 swap-out/swap-in 발생 → 지연↑
HugePages(2MB) 사용 + USE_LARGE_PAGES=ONLY →
- 스왑 사실상 차단, 메모리 파편화↓, 대용량 SGA 안정화

6) 스토리지·보안·역할 분리

DB(oracle) vs ASM(grid) OS 계정/그룹 분리(권한·보안·책임 분리)
백업/FRA 용량 사전 확보, IORM 정책 검토(우선순위)
인덱스 전략 재검토(Exadata Smart Scan과 병행)

7) 가상화(KVM) 통합 포인트

Exadata X8M+는 KVM 권장, SR-IOV로 RoCE 성능 근접
VM 단위로 CPU/메모리 지정, 라이선스도 VM 단위
DB마다 VM 1개씩은 오버헤드↑ → 업무/조직 단위로 적절히 통합

8) 멀티테넌트(PDB) 마이그레이션이 쉬운 이유

Unplug/Plug 으로 PDB 단위 이동 → 속도↑, 다운타임↓
여러 PDB 병렬 이관 가능, 패치/업그레이드 일괄 관리 용이

9) 마이그레이션 옵션 단기 비교표

유형예장점유의점

물리계열	RMAN(Backup/Duplicate), Data Guard Physical, TTS/TTDB	다운타임 최소(특히 DG), TTS 가장 빠름	TTDB는 엔디언 불가, TTS는 RMAN으로 엔디언 변환 필요 시 처리
논리계열	Data Pump, Logical Standby, INSERT…SELECT, GoldenGate	구조 재구성/버전 간 유연	변환/적재 시간, 논리 변환 이슈

실무 상: 초기 대량은 TTS/파일적재(External/SQL*Loader), 변경분 동기화는 GoldenGate로 혼합이 가장 흔함.

10) 파일 적재(External Table) 성능 팁

10MB granule 자동 분할로 병렬 읽기
압축 파일은 granule 불가 → 풀고 적재
여러 파일, 비슷한 크기, External LOCATION은 큰 파일→작은 파일 순
Direct Path / APPEND / 병렬 옵션 적극 활용

📘 13장: Exadata Database Machine Platform Monitoring (플랫폼 모니터링)

1. 모니터링 목적

하드웨어 + 소프트웨어 스택을 엔드 투 엔드(End-to-End) 로 감시
(DB ↔ Storage ↔ Infiniband ↔ Cell ↔ OS ↔ Network)
장애 징후 조기 발견 및 가용성 확보

2. 주요 모니터링 계층

계층대상도구

데이터베이스	인스턴스, PDB, SQL, I/O 대기	AWR, ASH, OEM
스토리지	셀 서버, 디스크, 플래시	CellCLI, OEM
네트워크	InfiniBand, RoCE, 이더넷	ibstat, nm2env, OEM
플랫폼	노드 상태, 하드웨어 센서	ILOM, dcli, ipmitool

3. 표준 모니터링 방법

AWR / ADDM: DB 성능 및 리소스 병목
dcli: 여러 노드에 명령 병렬 실행 (Exadata 표준 툴)
ILOM (Integrated Lights Out Manager): HW 상태 및 장애 알람
OS Watcher: CPU/Memory/Network I/O 추적

👉 모니터링을 계층별로 나눠서 보는 게 핵심입니다. (DB → Storage → Network → HW)

📙 14장: Monitoring Exadata System Software Components

1. 구성요소

구성 요소역할

Cell Server (CELLSRV)	Smart Scan, I/O 요청 처리
Management Server (MS)	모니터링·알림·상태 정보 수집
RS (Restart Server)	프로세스 감시·자동 재시작
ibsw / RoCE	InfiniBand 또는 RoCE 네트워크 계층

2. 주요 모니터링 명령어

cellcli -e "LIST ALERTHISTORY" : 알람 이력 확인
cellcli -e "LIST METRICCURRENT" : 실시간 메트릭
cellcli -e "LIST METRICHISTORY" : 히스토리 메트릭
cellcli -e "LIST THRESHOLD" : 임계치 설정 조회
cellcli -e "ALTER THRESHOLD" : 경보 조건 조정

👉 Storage Cell 단의 메트릭 기반 알람 시스템을 정확히 이해하는 게 중요합니다.

3. 모니터링 포인트

CELLSRV 상태 및 재시작 이력
플래시 캐시 Hit Ratio
디스크 리빌드 상태
네트워크 연결 이상
SMART 알람(디스크 HW 이슈)

👉 Exadata의 고가용성은 RS + MS + Threshold 알람에 크게 의존합니다.

📗 15장: Configuring Oracle Enterprise Manager Cloud Control to Monitor Exadata

1. OEM(Cloud Control) 통합 모니터링 목적

DB + Storage + Network + HW를 한 눈에
알람 통합 관리 (Threshold & Notification)
Capacity Planning 및 성능 분석 지원

2. 구성 요소

구성 요소역할

OEM Server	중앙 관리 서버
OMS Agent	각 노드/스토리지에서 데이터 수집
Plug-in for Exadata	Exadata 전용 메트릭 및 상태 수집
Notification Rules	경보 알림 설정

3. 설정 절차

OMS Agent를 모든 DB Node 및 Storage Cell에 배포
Exadata Plug-in 설치 및 등록
DB, Storage, Network 컴포넌트를 OEM에 등록
경보 정책(Notification Rule) 설정
대시보드 / Capacity Planning 활성화

👉 실무에서는 OEM을 통해 알람 자동화 + 통합 모니터링하는 환경이 표준입니다.

4. OEM에서 주로 보는 지표

DB 성능 (AWR 기반)
Storage Server 메트릭 (IOPS, Flash Cache)
Infiniband 상태
HW 센서(온도/팬/전원)
알람 이벤트

📙 16장: Monitoring Exadata Storage Servers

1. Storage Server 주요 컴포넌트

CELLSRV (I/O 처리)
MS (상태 관리/메트릭)
RS (Restart)
디스크 / 플래시 / IB 인터페이스

2. 주요 모니터링 툴

도구특징

CellCLI	Storage Cell 관리 기본 툴
dcli	다중 노드 명령 병렬 실행
ExaCLI	OEM Agent 없이 로컬 CLI
Metric/Threshold	자동 경보 시스템

# 알람 조회 cellcli -e "LIST ALERTHISTORY" # 현재 메트릭 cellcli -e "LIST METRICCURRENT" # 임계치 cellcli -e "LIST THRESHOLD"

3. Storage Server에서 중요한 지표

I/O 지표
- IOPS / MBPS / Latency
- Flash Cache Hit Ratio
디스크 상태
- Predictive Failures, Rebuild Progress
네트워크 상태
- IB/RoCE 장애 여부
알람 이력
- Threshold, 디스크 SMART 경보

👉 특히 “Flash Cache Hit Ratio”는 Exadata 성능을 좌우하는 대표 지표입니다.

4. 알람 및 장애 대응

임계치(Threshold)는 Cell 수준에서 설정 가능
알람 발생 시 OEM / CLI에서 바로 확인 가능
RS 프로세스가 CELLSRV 자동 재시작 → 가용성 유지
디스크 실패 시 ASM redundancy로 서비스 지속

📌 최종 핵심 포인트 요약

장주제핵심 키워드

13장	플랫폼 모니터링	End-to-End 모니터링, ILOM, dcli, OS Watcher
14장	SW 컴포넌트	CELLSRV / MS / RS / Threshold Alerts
15장	OEM 연동	Plug-in, 알람 자동화, Capacity Dashboard
16장	스토리지 모니터링	CellCLI, dcli, Flash Cache Hit Ratio, IOPS, Threshold

👉 실무 TIP

운영팀은 대부분 ① CLI + ② OEM + ③ 알람 메일 조합으로 운영합니다.
특히 Storage Cell의 Alert/Metric은 장애 사전 방지의 핵심입니다.
Exadata 성능 이슈 대부분은 DB가 아니라 Storage Layer에서 시작됩니다.

11장 Migrating Databases to Exadata Database Machine

Oracle Exadata 도입 시 가장 헷갈리기 쉬운 부분 중 하나가 바로 👉 “기존 스토리지 용량/성능”과 “Exadata 스토리지 용량/성능”의 차이를 제대로 이해하고 용량 계획(capacity planning) 을 세우는 것입니다.

아래는 이 내용을 쉽고 실무적으로 정리한 가이드입니다👇

🧭 1. 왜 용량 계획(capacity planning)이 중요한가?

Exadata는 단순히 디스크 용량만 보고 설계하는 장비가 아닙니다.
✅ I/O 성능(IOPS, MBPS)
✅ Smart Flash Cache / PMEM 등 가속 기능
✅ 장애 상황 시 리던던시(ASM redundancy) 용량까지
→ 모두 고려해야만 안정적인 성능과 가용성을 보장할 수 있어요.

📌 “단순 디스크 크기만 보고 마이그레이션하면 성능이 안 나올 수 있다” 는 게 핵심 경고입니다.

🧮 2. 현재 시스템 I/O 특성 파악이 첫 단계

수집해야 할 핵심 지표

지표설명수집 방법

IOPS (I/Os per second)	초당 읽기/쓰기 횟수	AWR에서 physical reads, physical writes
MBPS (MB per second)	초당 처리되는 데이터 양	AWR에서 physical I/O disk bytes
데이터 총량	디스크 실제 사용 용량	OS, DB 또는 스토리지 툴
Peak 시점 I/O 부하	평균이 아닌 피크 구간 기준	AWR Top Activity / peak 시간대 기준

📊 AWR 예시 쿼리

SELECT (physical_read_bytes + physical_write_bytes) / (1024*1024) AS MBPS, (physical_reads + physical_writes) AS IOPS FROM v$sysstat WHERE name IN ('physical reads','physical writes','physical write total bytes','physical read total bytes');

또는 AWR Report → “Instance Activity Stats” 섹션에서도 직접 확인 가능.

⚡ 3. Exadata 스토리지의 특성 이해

항목기존 스토리지Exadata

구조	일반 SAN/NAS	Smart Flash + Disk + PMEM
IOPS/MBPS	디스크 성능에 종속	Flash Cache, PMEM, RoCE로 대폭 향상
데이터 압축	제한적	Hybrid Columnar Compression 지원
장애 허용	보통 RAID	ASM Redundancy + Cell Failover
네트워크	TCP/IP	RoCE (RDMA over Converged Ethernet) 초저지연

👉 Exadata는 같은 물리 디스크 용량이라도 실제로는 더 높은 처리량(Throughput) 을 낼 수 있습니다.
예: 기존 SAN 20TB = Exadata 20TB보다 I/O 성능이 훨씬 낮을 가능성 큼.

📐 4. Exadata 용량 산정 단계별 가이드

Step 1. 📊 현재 시스템 파악

AWR에서 Peak IOPS, MBPS, 총 데이터 사이즈 추출

Step 2. 🧮 Exadata 모델 스펙 확인

공식 스펙: oracle.com/exadata
노드 수, Flash 용량, 디스크 용량, I/O 처리 성능(I/O bandwidth, IOPS)

Step 3. ✨ 성능 최적화 요소 반영

Smart Flash Cache → 디스크 부하 감소
Hybrid Columnar Compression → 용량 절감 (최대 10배 이상 가능)
PMEM / RoCE → 읽기 지연시간 대폭 감소

👉 예: 현재 100TB 데이터를 압축해 Exadata에서는 30~40TB만 필요할 수도 있음.

Step 4. 🧱 장애 상황 고려 (Redundancy)

ASM NORMAL 또는 HIGH Redundancy 적용 시
→ 실사용 가능한 스토리지가 줄어듭니다

ASM 모드사용 가능 용량 비율설명

NORMAL	약 50%	2중 미러
HIGH	약 33%	3중 미러

👉 예: 100TB RAW 용량 → NORMAL redundancy 사용 시 실사용 약 50TB

Step 5. ⚠️ 장애 후 I/O 성능 여유 확보

Cell 1~2대 장애 상황에서도 요구 IOPS/MBPS를 충족해야 함
Peak 기준 I/O에 여유 버퍼(보통 20~30%)를 더해 산정

🧠 5. Smart Flash Cache / Compression 고려 예시

항목기존Exadata 적용 후 (예시)

원본 데이터	100TB	100TB
Hybrid Compression 적용	-	40TB
Smart Flash Cache Hit	-	70~80% 디스크 오프로드
필요 디스크 용량	100TB	약 50TB (Redundancy 포함)
Peak MBPS	4GB/s	Flash+RoCE로 더 적은 디스크 부하

👉 같은 데이터를 훨씬 작은 물리 용량과 더 적은 디스크 I/O로 처리 가능하게 됨.

📌 6. 핵심 체크리스트

AWR에서 현재 Peak IOPS / MBPS 확보했는가?
실제 데이터 용량과 성장률을 반영했는가?
Exadata의 Flash / PMEM / Compression 효과를 반영했는가?
Redundancy 적용 후 실사용 용량을 계산했는가?
장애 상황에서도 SLA를 충족할 수 있는 I/O 여유를 뒀는가?

✅ 요약 정리

포인트설명

📊 현황 파악	AWR로 IOPS·MBPS·용량을 정확히 수집
📐 Exadata sizing	성능 + 용량 + 장애 대비까지 고려해야 함
✨ 최적화 기능 반영	Flash Cache, PMEM, HCC 압축으로 실제 요구 용량 줄이기
⚠️ Redundancy 감안	NORMAL/HIGH 모드에 따라 실사용 용량이 줄어듦
🧮 여유 확보	장애 후에도 SLA 충족할 여유 성능 확보 필수

👉 정리하자면, Exadata는 단순 디스크 용량 비교가 아니라,
✅ IOPS·MBPS·압축 효과·Flash 활용도·장애 허용력까지 함께 계산해야 올바른 용량 계획이 가능합니다.

TTS (Transportable Tablespace)
한 데이터베이스의 테이블스페이스를 통째로 다른 데이터베이스로 이관하는 기능

🧱 개념

테이블스페이스를 익스포트(export) 해서
다른 DB에서 임포트(import) 하는 방식으로 빠른 데이터 마이그레이션이 가능.
데이터 파일 그대로 복사하기 때문에 Data Pump만 쓰는 것보다 훨씬 빠름.

🧰 TTS 특징

항목설명

대상	테이블스페이스 단위
방식	메타데이터 Export + 데이터파일 복사
속도	빠름 (파일 직접 이동)
주 용도	마이그레이션 / 클론 / 아카이브
조건	플랫폼 엔디언(Endian) 확인 필요 (다르면 변환 필요)

👉 예: 운영 DB의 특정 테이블스페이스만 다른 DW 서버로 옮길 때 자주 사용합니다.

Exadata Migration Considerations

Oracle Exadata 로 마이그레이션할 때는 단순히 DB만 옮기면 되는 게 아니라, Exadata 전용 성능 최적화 설정 및 호환성 조건을 충족해야 합니다. 아래에 핵심 요구사항과 추천 설정을 이유와 함께 정리해드릴게요👇

🧭 1. 플랫폼 및 아키텍처 기본 사항

항목설명의미

플랫폼	64비트 Intel 기반	32비트 OS나 DB는 Exadata에서 지원되지 않음
엔디언(Endian)	Little Endian	기존 플랫폼이 Big Endian이면 마이그레이션 시 endian 변환 필요

👉 예: 기존이 SPARC(Solaris) Big Endian 환경이라면 RMAN CONVERT나 Data Pump 방식 등 endian 변환 작업이 필요합니다.

🧩 2. 소프트웨어 호환성 요구사항

Exadata Storage Server, ASM(Automatic Storage Management), 그리고 DB 소프트웨어 버전은 반드시 서로 호환되는 버전이어야 합니다.
예: Oracle Exadata X8M 의 경우 [Doc ID 2724126.1]에 권장 버전이 명시되어 있음.

✅ 팁: 마이그레이션 전 버전 정합성 점검이 필수입니다.
특히 PDB/CDB 환경을 쓰는 경우 ASM/Storage Server 버전도 꼼꼼히 확인해야 합니다.

⚙️ 3. ASM Disk Group 권장 설정

Exadata에서 ASM Disk Group을 구성할 때는 다음과 같은 설정을 강력 권장합니다👇

속성권장 값설명

AU_SIZE	4 MB	Smart Scan 최적화 (4MB 단위로 효율적 읽기)
COMPATIBLE.ASM	DB 버전과 동일 이상	Exadata 기능 활성화
COMPATIBLE.RDBMS	DB 버전과 동일 이상	Smart Scan 등 고급 기능 활성화 가능
cell.smart_scan_capable	TRUE	Smart Scan 가능 여부 지정

👉 AU_SIZE를 4MB로 하면 Exadata의 Smart Scan이 대용량 연속 스캔(>=4MB) 을 효율적으로 처리할 수 있어 Flash Cache 및 I/O 성능이 극대화됩니다.

🧠 4. DB 초기화 파라미터 설정 (필수)

파라미터권장값설명

COMPATIBLE	11.2.0.1 이상	Exadata 기능 전체 사용을 위해 필수
DB_BLOCK_CHECKSUM	TYPICAL 또는 FULL	Exadata HARD(하드웨어 체크섬) 기능 활용
DB_BLOCK_SIZE	8 KB (기본값)	일반적으로 그대로 사용
DB_CREATE_FILE_DEST	ASM 경로 사용	Exadata 환경 표준

👉 DB_BLOCK_CHECKSUM을 켜두면 블록 손상 여부를 하드웨어 차원에서 빠르게 탐지할 수 있어 안정성이 높아집니다.

📊 5. Extent Size 및 I/O 최적화

Exadata는 최소 4MB 이상의 연속적인 스캔에서 최고의 성능을 냅니다.
따라서:
- ASM AU_SIZE = 4MB
- DB Extent Size는 AU_SIZE의 배수(8MB, 16MB 등)로 설정 권장
- 대용량 테이블스페이스는 Extent 크기를 키워 Smart Scan 효율 증가

👉 예: DW 환경에서 8MB Extent로 설정하면 디스크 I/O 오버헤드를 줄이고 Smart Scan 처리량을 극대화할 수 있습니다.

🧯 6. 추가 고려사항

항목설명

버전 호환성	ASM, Storage Server, DB 모두 권장 버전으로 업그레이드
데이터 변환	Big Endian → Little Endian 마이그레이션 시 사전 변환 필수
압축	Hybrid Columnar Compression 활성화 가능 (특히 DW 환경에서 효과 큼)
Redundancy	ASM NORMAL 또는 HIGH 모드 적용 (장애 대비)
Smart Scan	테이블/쿼리 구조가 연속 스캔에 유리해야 최대 성능 발휘

✅ 요약 정리

항목권장 설정 / 요구 사항이유

플랫폼	64bit, Little Endian	호환성 필수
소프트웨어	ASM / Storage Server / DB 버전 일치	Smart Scan 및 Flash 기능 활성화
ASM AU_SIZE	4MB	대용량 스캔 성능 극대화
COMPATIBLE	11.2.0.1 이상	Exadata 기능 활성화
DB_BLOCK_CHECKSUM	TYPICAL 또는 FULL	블록 무결성 검사
Extent Size	4MB의 배수	Smart Scan I/O 효율 증가

👉 정리하자면, Exadata로 마이그레이션할 때는 단순 DB 마이그레이션이 아니라,
✅ 64bit 호환성,
✅ ASM/DB 설정 최적화,
✅ AU/Extent Size 조정,
✅ COMPATIBLE 파라미터 설정,
✅ Smart Scan 환경 구성
이 모두 맞아야 최대 성능을 낼 수 있습니다.

Primary, Standby, Redo Log

Primary, Standby, Redo Log 이 세 가지는 Oracle Data Guard 의 핵심 구조를 이해하는 데 아주 중요합니다.
쉽게 말해서 이 관계는 👉 “Primary DB에서 발생한 변경을 Standby DB로 실시간(or 거의 실시간) 복제하기 위한 메커니즘” 입니다.

아래에 그림 없이 개념을 단계별로 설명해볼게요 👇

🧭 1. 기본 개념

용어역할설명

🟦 Primary Database	주(主) DB	실제 서비스가 동작하는 운영 DB
🟩 Standby Database	대기(備) DB	Primary와 동일한 데이터를 복제해둔 백업 DB (DR용)
🟥 Redo Log	변경 기록	Primary에서 발생한 모든 트랜잭션 변경 내용을 기록하는 로그 파일

👉 즉, Primary에서 INSERT / UPDATE / DELETE / COMMIT 같은 변경이 일어나면,
이 내용이 먼저 Redo Log에 기록되고,
이 로그를 Standby로 전달하여 동기화합니다.

🧾 2. Redo Log가 하는 일

Primary DB에서 트랜잭션 발생
해당 변경이 Redo Log Buffer에 먼저 기록됨
일정 시점(또는 commit 시) → Online Redo Log 파일에 기록됨
Data Guard가 이 Redo 데이터를 전송 (Redo Transport)
Standby에서 Redo Apply가 이를 읽어 DB에 적용함 (Redo Apply)

👉 결과적으로 Standby DB는 Primary DB와 거의 실시간으로 데이터가 동일해집니다.

🔁 3. 동작 흐름 정리 (단계별)

[Primary DB] | ├─ 1. 사용자 변경 발생 ├─ 2. Redo Log에 기록 (Redo Log Buffer → Online Redo Log) ├─ 3. LNS(Log Network Service) 프로세스가 Redo 전송 ▼ [Standby DB] ├─ 4. RFS(Remote File Server)가 Redo 수신 ├─ 5. Standby Redo Log에 기록 ├─ 6. MRP(Media Recovery Process)가 Redo 적용 ▼ [데이터 동기화 완료 ✅]

🧭 4. Standby Redo Log의 역할

Standby DB도 Redo를 받기 위한 전용 Redo Log(Standby Redo Log, SRL)를 갖고 있어야 합니다.
Primary에서 전송된 Redo가 SRL에 실시간으로 저장되고,
MRP 프로세스가 이 로그를 적용해 데이터 반영합니다.

👉 Standby Redo Log가 없다면 Archive Log 전송을 기다려야 해서 실시간성이 떨어집니다. (최신 DR 환경에서는 거의 필수로 구성)

⚡ 5. Redo 전송 방식

모드특징설명

SYNC 모드	실시간 전송	Primary의 트랜잭션 COMMIT 시점에 Standby 반영까지 확인
ASYNC 모드	비동기 전송	Primary COMMIT 후 Standby로 전송 (약간의 지연 발생)

👉 금융, 중요 서비스는 SYNC, 일반 서비스나 원거리 DR은 ASYNC를 많이 씁니다.

📌 6. 로그 파일 종류 정리

로그 유형위치역할

Online Redo Log	Primary	변경 내역을 실시간 기록
Archive Log	Primary	Online Redo Log가 다 차면 보관용으로 아카이브
Standby Redo Log	Standby	Primary로부터 전송받은 Redo 데이터를 실시간 저장
Archived Redo (from Primary)	Standby	필요 시 Archive Log를 전송받아 복구에 사용

🧯 7. Redo & Failover 시나리오

Primary 장애 발생 시 → Standby가 Redo를 모두 적용 완료 상태라면
👉 즉시 Standby를 Primary로 승격 가능 (Failover / Switchover)
Redo가 잘 동기화돼 있어야 RPO(복구 시점 손실)가 0에 가까워집니다.

✅ 요약 정리

구성 요소역할설명

Primary DB	운영	변경 발생 주체
Redo Log	변경 기록	Primary에서 발생한 모든 트랜잭션 기록
Standby DB	복제 대상	Primary의 변경을 Redo Log 기반으로 실시간 반영
Standby Redo Log	중간 저장소	Primary의 Redo를 받아 Standby에서 적용
SYNC/ASYNC	전송 방식	동기 vs 비동기 Redo 전달

👉 핵심 포인트:

Redo Log는 단순한 로그 파일이 아니라 Standby 동기화의 핵심 매개체입니다.
Standby는 Redo를 기반으로 Primary와 똑같은 상태를 유지합니다.
이 구조 덕분에 장애 시 빠르게 DR로 전환할 수 있습니다.

Physical Standby 와 Logical Standby

Oracle Data Guard 환경에서 Standby Database는 크게 두 가지 유형이 있습니다.

👉 Physical Standby 와 Logical Standby

이 둘은 Primary DB로부터 Redo를 어떻게 적용하느냐 방식이 완전히 다릅니다.
아래에서 쉽게 정리해볼게요👇

🧭 1. 개념 요약

구분Physical StandbyLogical Standby

데이터 복제 방식	Redo 블록 단위 그대로 적용	Redo를 SQL로 변환해서 재실행
데이터 구조	Primary와 완전히 동일	Primary와 논리적으로 동일(구조는 약간 다를 수 있음)
적용 방식	Redo Apply	SQL Apply
활용 목적	고가용성(HA), DR	DR + 리포팅/ETL 등 읽기 부하 분산
변경 허용	읽기 전용(일반적으로)	일부 객체 수정 및 추가 가능
복구 속도	빠름	느림(변환 및 적용 오버헤드)

🏗️ 2. Physical Standby (물리적 스탠바이)

🧠 정의

Primary DB의 Redo 데이터를 Block 단위 그대로 Standby에 적용하는 방식.
Primary와 물리적으로 완전히 동일한 복제본을 유지.

⚡ 동작 방식

Primary에서 트랜잭션 발생 → Redo 생성
Redo가 Standby로 전송됨
Standby의 MRP(Media Recovery Process)가 Redo를 그대로 적용 (Redo Apply)
Standby는 Primary와 데이터가 완전히 동일한 상태로 유지됨

Primary ──Redo(블록단위)──▶ Physical Standby

🧰 특징

✅ 구조 및 데이터가 Primary와 100% 동일
✅ Redo 적용이 빠르고 안정적
✅ 장애 발생 시 빠른 Failover 가능
⚠️ 읽기 전용 모드(기본) — 단, Active Data Guard 라이선스로 읽기 가능

👉 일반적인 DR(재해 복구) 구성에서 가장 널리 쓰이는 방식입니다.

🧮 3. Logical Standby (논리적 스탠바이)

🧠 정의

Primary DB의 Redo 데이터를 받아 SQL 문장으로 변환 후 Standby에 재적용하는 방식.
데이터 결과는 동일하지만, 물리적 구조는 조금 달라도 됨.

⚡ 동작 방식

Primary에서 트랜잭션 발생 → Redo 생성
Redo가 Standby로 전송됨
Standby의 LSP(Logical Standby Process)가 Redo → SQL 변환
SQL Apply로 데이터를 재적용

Primary ──Redo→SQL 변환──▶ Logical Standby

🧰 특징

✅ Standby에서도 DML, DDL 가능 (일부 테이블 제외)
✅ 리포팅/ETL/분석용으로 병행 활용 가능
⚠️ SQL 변환 오버헤드 → 적용 속도가 느림
⚠️ 모든 데이터 타입이 지원되는 건 아님
⚠️ 특정 기능/객체는 변환 불가 (e.g. SecureFile LOB, 일부 XML 타입 등)

👉 주로 운영 + 분석 분리 목적으로 사용됩니다.

📊 4. Physical vs Logical 비교 정리

항목Physical StandbyLogical Standby

적용 방식	Redo Apply (블록 단위)	SQL Apply (SQL 재실행)
동기화 속도	빠름	상대적으로 느림
데이터 구조	Primary와 완전 동일	논리적으로 동일, 일부 구조 변경 가능
활용	DR, 고가용성	DR + 리포팅/분석
변경 허용	읽기 전용 (Active Data Guard로 읽기 가능)	읽기 + 제한적 쓰기 가능
Failover 속도	빠름	느림 (SQL 변환 및 적용 상태에 따라 다름)
지원 객체	대부분	일부 객체 제외됨
유지 관리	단순	변환/적용 이슈로 복잡할 수 있음

🧪 5. 실무에서의 활용 시나리오

시나리오추천 유형

단순 DR(재해 복구), 고가용성	✅ Physical Standby
DR + 리포팅 서버 병행 사용	✅ Logical Standby (또는 Active Physical + 리포팅)
Failover/Switchover 빠른 전환	✅ Physical Standby
DW/ETL/분석 작업 분리	Logical Standby (단, 변환 호환성 확인 필요)

👉 대부분의 기업은 운영 DR은 Physical Standby로 구성하고,
리포팅이 필요한 경우 Logical Standby 또는 Active Data Guard를 추가로 씁니다.

🧭 6. 관련 주요 프로세스

프로세스Standby 유형역할

LNS	Primary	Redo 전송
RFS	Standby	Redo 수신
MRP	Physical Standby	Redo Apply
LSP	Logical Standby	Redo → SQL 변환 및 적용

✅ 요약 정리

구분Physical StandbyLogical Standby

Redo 처리	Block 단위	SQL 변환
속도	빠름	느림
구조	동일	논리적 동등
용도	DR/HA	DR + 리포팅
복잡도	단순	복잡
Failover	빠름	느림

👉 대부분의 DR 설계는 Physical Standby를 기본으로 하고,
특수한 분석 용도나 부하 분산이 필요할 때만 Logical Standby를 씁니다.

12장 Bulk Data Loading

extraction traslation staging area loading

star shema

sorce로부터 data불러올 때 file로 끌어온다

exa는 file로 소스 불러오지 않고 asm storage에서 불러옴

File 기반 적재 (Staging Area 활용)

staging area영역을 어디로 구성할거냐?

엑사머신 바깥쪽에 둘건지 external. 별도 스토리지 사용. SAN, NAS

엑사머신 안쪽에 둘건지 internal. DBFS(db관리 파일시스템), ACFS(asm관리 파일시스템)

엑사머신 바깥쪽에 둔다는 것은 별도 서버 사용. SAN, NAS

🧠 개념

소스 시스템의 데이터를 파일(CSV, Flat File, Parquet 등)로 떨궈서
Staging Area(중간 저장소)에 옮긴 뒤
Exadata로 로드하는 방식입니다.

📦 Staging Area 구성 옵션

위치설명

ACFS / DBFS (Exadata 내부)	Exadata의 파일 시스템에 staging 가능
NAS / SAN (외부)	별도의 스토리지에 staging 후 Exadata에서 접근
외장 디스크 / 테이프 등	물리적 매체로 전송 후 적재

⚠️ 주의: Exadata 내부 서버 디스크(로컬 HDD)에 staging 파일을 두는 건 권장되지 않습니다.

DBFS?

🧭 1. DBFS란 무엇인가?

Oracle Database File System(DBFS)는
👉 데이터베이스를 파일 시스템처럼 사용하는 기능입니다.

내부적으로는 DB 테이블에 데이터를 저장하지만,
외부에서는 일반 POSIX 파일 시스템(리눅스 파일 시스템)처럼 접근할 수 있게 해줍니다.

[Application / Loader] │

▼

[ DBFS Mount (POSIX FS) ] │

▼

[ Oracle Database (SecureFiles LOB) ] │

▼

[ Exadata Storage ]

🧾 2. DBFS Staging의 동작 방식

Staging 파일 업로드
- CSV, TXT, Parquet 등 대용량 데이터를 DBFS 마운트 지점에 업로드
DBFS 내부 저장
- 파일은 DB 내부의 SecureFile LOB 컬럼에 저장됨
- 실제 물리적 저장소는 Exadata의 ASM 디스크 그룹
POSIX 파일 인터페이스 제공
- OS에서 ls, cp, rm 같은 명령으로 접근 가능
- SQL*Loader, External Table 등에서 파일 경로로 바로 로딩 가능
DB 기능 활용 가능
- DBFS에 저장된 파일도 RMAN 백업, Flashback, Data Guard 동기화 가능

🧠 3. DBFS의 특징 및 장점

항목설명

📂 파일 시스템처럼 사용 가능	OS에서 mount 후 일반 파일처럼 접근
🧮 SecureFile LOB에 저장	DB 내부에 안전하게 저장됨
⚡ 트랜잭션 일관성 보장	DB 데이터와 동기적으로 관리됨
🛡 고가용성 기능 연계 가능	ASM, RMAN, Flashback, Data Guard 등
🔐 보안 및 권한 관리 용이	DB 계정 및 권한 관리 기반
🧰 Exadata 최적화	로딩 시 내부 경로 사용 → 빠른 적재 속도

👉 즉, 단순한 “파일 폴더”가 아니라
✅ DB의 고가용성과 보안을 그대로 적용할 수 있는 스테이징 스토리지입니다.

⚡ 4. DBFS를 이용한 스테이징 예시

① DBFS 마운트

# 예: 리눅스에서 DBFS를 마운트 dbfs_client username@TNS_ALIAS /mnt/dbfs

② 파일 업로드

cp /data/bulk/orders_202510.csv /mnt/dbfs/

③ External Table로 로딩

CREATE TABLE ext_orders ( order_id NUMBER, order_date DATE, amount NUMBER )

ORGANIZATION EXTERNAL ( TYPE ORACLE_LOADER DEFAULT DIRECTORY dbfs_dir ACCESS

PARAMETERS ( RECORDS DELIMITED BY NEWLINE FIELDS TERMINATED BY ',' )

LOCATION ('orders_202510.csv') )

REJECT LIMIT UNLIMITED;

👉 DBFS 경로에 올린 파일을 바로 External Table로 읽어 들임.

예시2 ) 실습 예시

🧰 5. DBFS vs 외부 NAS/SAN 스테이징 비교

항목DBFSNAS/SAN 등 외부 스토리지

설치 위치	DB 내부 (Exadata)	외부
성능	Exadata 내부 경로 → 빠름	네트워크 I/O 경유
가용성	ASM, RMAN, Data Guard 등 연계	외부 스토리지 별도 관리
권한 관리	DB 권한 체계로 통합	OS/NAS 별도 관리 필요
백업	RMAN 등으로 통합 백업 가능	별도 백업 필요
마운트 편의성	POSIX 파일 인터페이스 제공	일반 파일 공유 방식 사용

👉 Exadata 환경에서는 NAS보다 DBFS가 성능·관리성 면에서 우수한 경우가 많습니다.

⚠️ 6. DBFS 사용 시 주의점

🧮 DB 내부에 파일이 저장되므로 DB 저장소 용량 관리가 중요
⚡ 대량 병렬 적재 시 IOPS 부하를 고려해야 함
🔐 DB 사용자 권한 체계와 잘 맞춰야 함 (파일 접근 = DB 권한)

✅ 요약 정리

항목내용

🧭 DBFS란	DB를 파일 시스템처럼 활용하는 기능
📂 저장 방식	SecureFile LOB으로 DB 내부에 저장
⚡ 장점	고성능, 고가용성, 트랜잭션 일관성
🧰 활용	External Table, SQL*Loader 스테이징 경로
🛡 관리	ASM, RMAN, Data Guard 등과 연계 가능

👉 즉, DBFS를 사용하면 Exadata 내부에서 파일 적재를 보안성·안정성·속도 모두 확보하면서 처리할 수 있습니다.

저작자표시 비영리 변경금지 (새창열림)

ABOUT ME

🧰 10~12장: 운영 및 데이터 로딩

🖥️ 13~16장: 모니터링

1. Consolidation(통합)의 목적

2. 권장 아키텍처 유형

3. CPU 및 메모리 통합 전략

4. I/O Resource Management (IORM)

1. 마이그레이션 설계 순서

2. 물리적 마이그레이션 (Physical)

3. 논리적 마이그레이션 (Logical)

4. 멀티테넌트 환경 이관

1. Exadata에서 대용량 적재 시 고려 사항

2. DBFS / ACFS / 외부 파일 시스템 차이

3. 외부 테이블 & 병렬 Granule

4. 로딩 성능 향상 팁

📌 최종 핵심 포인트 요약

Exadata 운영·통합 핵심 정리

1) 메모리 운영 원칙

HugePages(=대페이지) 필수

메모리 계산(러프 가이드)

2) OS 커널 파라미터(리눅스) 요령

3) 프로세스/세션·병렬 관리 베스트프랙티스

PROCESSES(동시 접속 한도; DB 파라미터)

병렬 서버 상한

활성 세션(프로세스) 밀도

연결 관리

4) CPU 자원 분배: Instance Caging

5) HugePages & 스와핑 이야기 (이해 포인트)

6) 스토리지·보안·역할 분리

7) 가상화(KVM) 통합 포인트

8) 멀티테넌트(PDB) 마이그레이션이 쉬운 이유

9) 마이그레이션 옵션 단기 비교표

10) 파일 적재(External Table) 성능 팁

📘 13장: Exadata Database Machine Platform Monitoring (플랫폼 모니터링)

1. 모니터링 목적

2. 주요 모니터링 계층

3. 표준 모니터링 방법

📙 14장: Monitoring Exadata System Software Components

1. 구성요소

2. 주요 모니터링 명령어

3. 모니터링 포인트

📗 15장: Configuring Oracle Enterprise Manager Cloud Control to Monitor Exadata

1. OEM(Cloud Control) 통합 모니터링 목적

2. 구성 요소

3. 설정 절차

4. OEM에서 주로 보는 지표

📙 16장: Monitoring Exadata Storage Servers

1. Storage Server 주요 컴포넌트

2. 주요 모니터링 툴

3. Storage Server에서 중요한 지표

4. 알람 및 장애 대응

📌 최종 핵심 포인트 요약

🧭 1. 왜 용량 계획(capacity planning)이 중요한가?

🧮 2. 현재 시스템 I/O 특성 파악이 첫 단계

수집해야 할 핵심 지표

⚡ 3. Exadata 스토리지의 특성 이해

📐 4. Exadata 용량 산정 단계별 가이드

Step 1. 📊 현재 시스템 파악

Step 2. 🧮 Exadata 모델 스펙 확인

Step 3. ✨ 성능 최적화 요소 반영

Step 4. 🧱 장애 상황 고려 (Redundancy)

Step 5. ⚠️ 장애 후 I/O 성능 여유 확보

🧠 5. Smart Flash Cache / Compression 고려 예시

📌 6. 핵심 체크리스트

✅ 요약 정리

🧱 개념

🧰 TTS 특징

🧭 1. 플랫폼 및 아키텍처 기본 사항

🧩 2. 소프트웨어 호환성 요구사항

⚙️ 3. ASM Disk Group 권장 설정

🧠 4. DB 초기화 파라미터 설정 (필수)

📊 5. Extent Size 및 I/O 최적화

🧯 6. 추가 고려사항

✅ 요약 정리

🧭 1. 기본 개념

🧾 2. Redo Log가 하는 일

🔁 3. 동작 흐름 정리 (단계별)

🧭 4. Standby Redo Log의 역할

⚡ 5. Redo 전송 방식

📌 6. 로그 파일 종류 정리