테마
03 — 다른 고객사 세 곳 (해당 화에 도달했을 때)
01~13화는
ora-hanorder하나로 충분하다. 이 문서는 03화, 04화, 12화, 18화 직전에 한 번씩 펴 보는 문서다. 만드는 방법은 첫 고객사와 똑같다. 이름과 포트, 계정만 바꾸고 적재 스크립트가 다를 뿐이다.
언제 무엇을 만드나
| 시점 | 컨테이너 | 회사 | 왜 그 화에 필요한가 | 카드 |
|---|---|---|---|---|
| 03화 전 | ora-dist :1523 pup | 본사 레거시 유통 마스터 | 날짜가 VARCHAR2(8) 문자열이다. "문자로 박힌 날짜가 인덱스를 원천 봉쇄한다"는 현상은 한빛유통의 DATE 컬럼으로는 재현되지 않는다 | L3_ora-dist |
| 04화 전 | ora-burger :1522 dev | 인수한 버거 프랜차이즈 POS | ORD와 ORD_RANDOM은 정의·행수·인덱스가 같은데 CF만 45배 다른 대조군이다 | L2_ora-burger |
| 12화 전 | ora-newshop :1524 (ORA_SQL_TEST) | 신규 이커머스 (FK 원본) | FK 7개가 실제로 걸려 있어야 무인덱스 FK 락이 재현된다 | L4_ora-newshop |
| 18화 직전 | ora-newshop (ECOMMERCE 추가) | 졸업 과제 | 처음 보는 스키마(테이블 30개 · 445,422행 · 인덱스 0개). 그때까지 봉인해 둔다 | 〃 |
03(dist) → 04(burger) → 12·18(newshop) 순서는 이야기 전개를 따른 것일 뿐, 기술적인 의존 관계는 없다. 셋은 서로 독립이다.
만드는 절차 — 세 곳 공통
1. 기동
01_첫_고객사_ora-hanorder.md §3-1의 launch_ora와 wait_ora를 셸에 붙여 넣은 뒤 실행한다.
bash
launch_ora ora-dist 1523 pup ; wait_ora ora-dist # 03화 전
launch_ora ora-burger 1522 dev ; wait_ora ora-burger # 04화 전
launch_ora ora-newshop 1524 shop ; wait_ora ora-newshop # 12화 전첫 기동은 각각 1~5분 걸린다. DATABASE IS READY TO USE!가 찍힐 때까지 wait_ora가 기다린다.
2. 권한
첫 고객사에서는 00_측정권한_부여.sql을 돌렸다. 나머지 세 곳은 사정이 조금씩 다르므로 카드에 적힌 대로 한다.
| 컨테이너 | 권한 |
|---|---|
ora-burger | dev는 launch_ora가 만들었다. 카드의 GRANT 블록(측정 권한 + CREATE PROCEDURE)을 SYS로 한 번 실행한다 |
ora-dist | 따로 없다. 01_pup_계정생성.sql이 pup을 지우고 다시 만들면서 측정 권한까지 준다 |
ora-newshop | 따로 없다. ORA_SQL_TEST와 ECOMMERCE는 각자의 스크립트가 계정과 권한을 만든다 |
3. 적재 — 각 카드의 "만들기" 절
데이터 생성기 원본 README들은 단일 컨테이너 시절(oracle-free)에 쓰였다. 카드에 치환표가 있으니 컨테이너 이름만 바꿔 읽으면 나머지는 그대로 쓸 수 있다.
| 컨테이너 | 원본 | 방식 | 실측 크기 |
|---|---|---|---|
ora-burger | 00_적재_한번에.sh | 저자가 배포한 PL/SQL 생성기(2.sql~5.sql)를 100만 건 · 난수 시드 고정 조건으로 흘려 넣는다(PowerShell 판은 카드에 있다) | 04화까지 ~2.6GB (14화 파티션 복사본까지 ~11.5GB) |
ora-dist | 오라클SQL파워업/ | CSV 18개 → docker cp → sqlldr | ~1GB |
ora-newshop | SQL_BOOSTER/ C1 · 이커머스/ | 책 원본 SQL / Python 생성 → sqlldr | ~2GB |
4. 검증 — 각 카드의 기대값
이 값들이 이 교재의 교보재다. 맞지 않으면 그 화의 실습이 성립하지 않는다.
| 컨테이너 | 확인할 것 | 기대 |
|---|---|---|
ora-burger | dev.ord 행수 · ORD_X01 / ORD_RANDOM_X01의 clustering_factor | 1,000,000 · 22,223 / 999,958 (시드를 고정했으므로 끝자리까지 같다) |
ora-dist | pup.cf11 행수 · 날짜 컬럼 타입 · 보조 인덱스 수 | 1,096,708 · VARCHAR2 · 0 |
ora-newshop | ORA_SQL_TEST의 FK 수 | 7 |
공간과 메모리 — 넷을 다 만들면
| 컨테이너 | 크기 | 상시 기동? |
|---|---|---|
ora-hanorder | ~95MB | 거의 항상 |
ora-burger | 04화까지 ~2.6GB → 14화 ~11.5GB | 04·14화만 |
ora-dist | ~1GB | 03·09화만 |
ora-newshop | ~2GB | 12·18화만 |
ora-burger는 12GB 한도에 육박한다.ORD_LIST_HASH하나가 3GB를 차지하는데, 거의 비어 있는 서브파티션 200개가 각각 최소 익스텐트를 잡기 때문이다. 버그가 아니라 14화에서 잴 현상 그 자체다. 여유 공간이 필요하면 적재용 스테이징 테이블을 지운다(2~4.sql로 언제든 다시 만들 수 있다).sqlDROP TABLE DEV.ORD_TEMP PURGE; DROP TABLE DEV.ORD_TEMP2 PURGE;컨테이너 한 대가 메모리를 1~1.5GB 쓴다. 오늘 볼 고객사만 켠다. 화별로 어느 컨테이너를 켜는지는
04_일상_운용과_문제해결.md§2에 정리해 두었다.