테마
05 — Free와 EE, 그리고 트랙 G
누군가 "AWR을 하려면 EE가 필요하다"고 말할 때 펴 보는 문서다. 14·16·17화에서 병렬 실행이나 대규모 부하가 필요해졌을 때도 이 문서를 본다. 결론부터 말하면 로컬 Docker Free(트랙 L)가 이 교재의 유일한 트랙이다. 01~18화 전부를 Free에서 실측한다. AWR, ASH, ADDM까지 Free에서 된다. 클라우드 EE(트랙 G)는 병렬 실행이나 대규모 부하, 설치 실습에 쓸모가 있지만 본편 범위 밖이다. 본편을 완주한 뒤 필요성이 확인되면 별권으로 낸다. 그래서 G 없이는 진행할 수 없는 화를 하나도 두지 않았다.
1. 실측 비교
| 트랙 L: 26ai Free (로컬 Docker) | 트랙 G: 19c EE (GCP) | |
|---|---|---|
| 사용자 데이터 | 12GB / DB (엔진 레벨 하드 한도) | 무제한 |
| CPU | 2 | VM 사양대로 (권장 4 vCPU) |
| 메모리 | 컨테이너 할당 (SGA 1.5G · PGA 512M 실측 기본값) | 16GB VM 기준 넉넉 |
| 비용 | 무료 | $300 크레딧, 서울 리전 약 $0.172/시간 |
| 라이선스 | Oracle Free Use Terms: 개인 학습 허용 | OTN: 개발·테스트·데모만. 업무 데이터 반입 금지 |
2. 기능 가용성 (실측 + 공식 매뉴얼)
| 기능 | Free | EE | 비고 |
|---|---|---|---|
| Partitioning | ✅ | ✅ | Free에서도 된다. 파티션 실습(14화 전반)은 로컬에서 한다 |
| Diagnostics Pack (AWR·ASH·ADDM) | ✅ | 💰 유상 옵션 | 역전 주의: Free는 포함, EE는 별도 구매 |
| Tuning Pack (SQL Monitor·SQL Tuning Advisor) | ✅ | 💰 유상 옵션 | 〃 |
| Database In-Memory | ✅ | 💰 | |
| Advanced Compression | ⚠️ | 💰 | V$OPTION은 TRUE인데 Data Pump 압축은 막혀 있다 (ORA-00439 실측) |
| Parallel query / DML | ❌ | ✅ | 트랙 G가 필요한 첫 번째 이유 |
| Real Application Clusters | ❌ | 💰 | 개념만 다룬다 |
| Real Application Testing | ❌ | 💰 | 다루지 않는다 |
🔑 가장 흔한 오해를 먼저 깬다
"AWR을 하려면 EE가 필요하다"는 말은 틀렸다. 로컬 Free에서는 이미 AWR이 돌고 있다. 실측해 보면
dba_hist_snapshot이 68건이고v$active_session_history도 살아 있다. 파라미터도control_management_pack_access = DIAGNOSTIC+TUNING(기본값),awr_pdb_autoflush_enabled = TRUE(26ai 기본값)이다.$ORACLE_HOME/rdbms/admin에는awrrpt,awrddrpt,ashrpt,addmrpt,spcreate,spauto,spreport,dbmshptab8종이 모두 있고, slim 이미지에도tkprof,sqlldr,expdp/impdp가 들어 있다. 오히려 EE 쪽이 진단팩을 따로 사야 한다. 계약 없이 EE 운영계에서awrrpt를 돌리면 라이선스 위반이다.옛 자료에서 "XE에선 AWR을 못 쓴다"고 하는 것은 구 XE(18c/21c) 이야기다. 그때는 사실이었지만 26ai Free는 다르다.
⚠️ 그리고
V$OPTION은 라이선스 판정 도구가 아니다. "바이너리에 링크되어 있는가"에만 답한다. 실제로Advanced Compression = TRUE인데도expdp compression=ALL은ORA-00439로 막혔다. 기능을 쓸 수 있는지는 선언된 값이 아니라 직접 실행해 봐야 안다. 이 교재의 제1원칙("측정으로 말한다")이 저자 자신에게 적용된 첫 사례다.
직접 확인하려면 SYS로 CDB$ROOT에서 다음을 실행한다.
sql
SELECT banner_full FROM v$version;
SELECT name, value FROM v$parameter
WHERE name IN ('control_management_pack_access','awr_pdb_autoflush_enabled','cpu_count','sga_target','pga_aggregate_target');
SELECT parameter, value FROM v$option
WHERE parameter IN ('Partitioning','Parallel execution','Real Application Clusters','In-Memory Column Store','Advanced Compression');
SELECT COUNT(*) FROM dba_hist_snapshot;실측 (2026-09-01)
Oracle AI Database 26ai Free Release 23.26.2.0.0
control_management_pack_access = DIAGNOSTIC+TUNING · awr_pdb_autoflush_enabled = TRUE
cpu_count = 2 · sga_target = 1.5G · pga_aggregate_target = 512M
Partitioning TRUE | In-Memory Column Store TRUE | Advanced Compression TRUE | Parallel execution FALSE | RAC FALSE
dba_hist_snapshot = 683. EE에서만 되는 것 — 본편이 다루지 않고 별권으로 넘기는 것
| # | EE에서만 되는 것 | 어느 화 | 왜 로컬로는 안 되나 |
|---|---|---|---|
| 1 | 병렬 실행 내부: QC·Granule·Table Queue·PQ_DISTRIBUTE·Downgrade, V$PQ_TQSTAT·V$PX_SESSION | 14 | Free는 Parallel execution = FALSE다. 힌트를 줘도 에러 없이 직렬로 강등되므로 V$PQ_TQSTAT가 0행이다 |
| 2 | work area 등급 전환 대조: 같은 조인을 PGA 2GB와 16GB에서 돌려 optimal → onepass → multipass가 뒤집히는 것을 본다 | 06·09 | 로컬은 메모리가 고정이라 한쪽만 볼 수 있다 |
| 3 | 현실적인 경합 프로파일: 수십 세션 동시 부하에서의 대기이벤트 분포 | 16·17 | 2 CPU에서는 모두 CPU 대기로 뭉개져 프로파일이 왜곡된다 |
| 4 | 팩 없는 현장 재현 → Statspack: CMPA=NONE으로 내려 SE2/무팩 EE 환경을 흉내 내고 spcreate.sql로 진단 | 17 | Free는 팩이 기본으로 켜져 있어서 "없는 상태"를 만들 수 없다 |
| 5 | 대용량 배치: 12GB 한도 없이 수천만 행 적재·삭제 | 14 | 한도에 걸린다 |
| 6 | 설치와 구성 그 자체: runInstaller · dbca · netca · 리스너 · CDB/PDB 생성 | 트랙 G 전용 | 컨테이너는 이미 다 만들어진 상태로 온다 |
본편은 이 표의 어느 것에도 의존하지 않는다. 해당 화는 Free에서 할 수 있는 데까지 실측하고, 나머지는 본문에 "Free에서는 이것이 안 되고, 그래서 이렇게 대신한다"고 밝힌 뒤 별권으로 봉인한다. 예를 들어 14화의 통과 조건은 파티션 Pruning(Pstart/Pstop) 실측이다. 병렬은 Free에서 힌트를 줘도 직렬로 강등되므로, 강등되는 모습을 확인하는 데서 멈추고 원리는 판독으로 다룬다.
4. 왜 본편에서 뺐나
- 본편은 로컬만으로 성립한다. 인덱스, 조인, 옵티마이저, 통계, Lock, Redo, PL/SQL, AWR은 모두 Free에서 측정할 수 있다.
- 크레딧 시계가 돈다. 크레딧은 $300 / 90일이고, 서울 리전에서 상시 가동하면 약 2.4개월이면 바닥난다. 실습 준비가 안 된 상태로 켜 두면 정작 필요할 때 크레딧이 없다.
- 부하를 걸려면 부하 드라이버부터 있어야 한다. 드라이버는 15화에서 PL/SQL로 직접 만든다. 도구 없이 EE를 띄워 봐야 볼 것이 없다.
- 설치 학습은 기초가 있어야 의미가 있다. SGA, PGA, 리스너, CDB를 모르는 상태에서
dbca를 돌리면 그냥 클릭일 뿐이다.
정리: 트랙 L은 "고객사 DB를 받아 와 내 노트북에서 뜯어보는" 자리이고, 트랙 G는 "고객사 운영 환경에 실제로 들어가 보는" 자리다. 순서가 뒤바뀌면 둘 다 남는 게 없다.
트랙 G는 본편에서 다루지 않는다(2026-10-18 결정). 본편을 Free로 완결한 뒤, "고객사 운영 EE 환경에 실제로 들어가 보는" 경험이 독자에게 필요하다고 판단되면 별권으로 분리한다. 설계 초안(
G00~G06)은_개정안/00_개정계획_v1.0.md(공개 사이트에는 없음) §7.3에 남겨 두었다.
부록 — 왜 한 대에 몰아넣지 않는가 (실측 사고 기록)
이전 구성에서는 Docker 한 대에 데이터셋 5종을 모두 올렸다. 그 결과는 이랬다.
ORA-12954: The request exceeds the maximum allowed database size of 12 GB.| 항목 | 실측 |
|---|---|
USERS 테이블스페이스 | 12.33GB (한도 초과) |
| 여유 | 634MB |
DEV 스키마 하나 | 11.53GB |
PUP / SQLP | 0.16 / 0.03GB |
DEV의 파티션 테이블 두 개가 각각 3GB씩 차지해 나머지를 굶겼고, 본편 무대(스키마 B)를 올릴 공간조차 없었다. 게다가 한도가 찬 Free DB에서는 expdp 백업조차 실패한다(Data Pump 마스터 테이블을 만들지 못한다).
나눈 뒤 본편 무대는 95MB로, 자기 컨테이너의 12GB 예산 중 1%도 쓰지 않는다. 이것이 고객사/에 컨테이너가 4대인 이유다.