테마
W01 — 베이스라인 원장 (01화 제출본)
| 항목 | 값 |
|---|---|
| 측정일 | 3월 4일 (01화) · 설치 후 두 번째 실행 |
| 측정자 | (초보 튜너) |
| 환경 | 컨테이너 ora-hanorder · Oracle AI Database 26ai Free 23.26.2.0.0 · cpu_count 2 · sga_target 1.5G · pga_aggregate_target 512M |
| 스키마 | sqlp@FREEPDB1 (스키마 A + B) |
| 데이터 | T_ORD_BIG 1,000,000 / T_ORD 100,000 / T_ORD_DET 200,000 / M_CUS 2,000 |
| 인덱스 상태 | T_ORD_BIG 인덱스 0개 ← 이 원장의 전제 |
| 부하 조건 | 단일 세션 · 워크로드 프로파일 없음(다세션 측정은 16화) |
| 통계 | GATHER_SCHEMA_STATS 직후 |
| 측정 도구 | STATISTICS_LEVEL=ALL + V$SQL 태그 조회 |
6조각 측정값
| 조각 | 설명 | SQL_ID | Buffers | Reads | ms | 결과행 | 계획해시 |
|---|---|---|---|---|---|---|---|
| Q1 | 기간별 주문 조회 | gcn22v46wnzy3 | 5,827 | 0 | 112 | 1 | 914281838 |
| Q2 | 고객등급별 매출 집계 | 5agpn6jmgm8rf | 1,026,849 | 0 | 774 | 3 | 2289018667 |
| Q3 | 상품평가 조인 | ff93fhdf13hwz | 841 | 0 | 14 | 5 | 119122671 |
| Q4 | 정산 목록 페이징 | 9dhfhrd7cqvsf | 5,826 | 0 | 42 | 10 | 513693594 |
| Q4c | 총건수 재조회 | 8zwr294pmr8zn | 5,826 | 0 | 9 | 1 | 914281838 |
| P1 | 정산 적재 배치(10만) | (PL/SQL) | — | 0 | 2,480 | 100,000 적재 | — |
| N1 | 채번 100회 | (PL/SQL) | — | 0 | 440 | 100 | — |
- 총 일량(Q1~Q4c): 1,045,169 blocks
- 최대 기여: Q2 1,026,849(98.2%)
- 참고:
T_ORD_BIG전체 스캔 1회 ≈ 5,826 blocks
판정 (T9 적용)
| 순위 | 조각 | 근거 |
|---|---|---|
| 1 | Q2 | 일량 98.2% + 화면 지연 직결 + 선형 증가 |
| 2 | Q4+Q4c / P1 | 화면 1회 11,652 blocks / 배치 마감 위반 |
| 3 | Q1 | 간접 영향 |
| 4 | N1 | 동시성에서 발현(잠재) |
| 별도 | Q3 | 정합성 오류. 성능 순위 밖의 최우선 트랙 |
기각한 대안
| 대안 | 기각 사유 |
|---|---|
즉시 USE_NL 힌트 제거 | 개선 전 수치가 없으면 효과 증명·부작용 판별 불가 |
| 인덱스 일괄 생성 | 원인이 "크기"가 아니라 "접근 횟수"임이 Q3(841)로 드러남 |
| 서버 증설 | 일량이 줄지 않으므로 동시 사용자 증가 시 동일 문제 재발 |
18화 재측정 예정
이 표의 6조각을 동일 조건에서 재측정해 (01화값 → 18화값) 2열을 추가한다.
(18화 주) 위의 01화 기록은 한 글자도 고치지 않았다. '동일 조건'은 아래 18화 절에서 같은 규약 · 지금 상태로 바꿔 적었다. 왜 바꿨는지도 거기에 적어 두었다.
18화 재측정 (7월 8일 · 졸업 판정)
| 항목 | 01화 (3월 4일) | 18화 (7월 8일) |
|---|---|---|
| 측정자 | (초보 튜너) | (튜너) · 리뷰 정하은 |
| 환경 | ora-hanorder · 26ai Free 23.26.2 · cpu_count 2 · SGA 1.5G · PGA 512M | 같다 · NOARCHIVELOG · 팩 DIAGNOSTIC+TUNING |
| 데이터 | T_ORD_BIG 1,000,000 / T_ORD 100,000 / T_ORD_DET 200,000 / M_CUS 2,000 | 같다(원본 지문 V_LD_FINGERPRINT 처음 = 끝) |
| 인덱스 상태 | T_ORD_BIG 인덱스 0개 | 3개: IX_ORD_BIG_DT · IX_ORD_BIG_DT_AMT(02화) · IX_ORD_BIG_DT_SEQ(09화) ← 이 열의 전제 |
| 통계 | GATHER_SCHEMA_STATS 직후 | 10화 정책서: ORD_ST FREQUENCY · METHOD_OPT 선호값 FOR ALL COLUMNS SIZE 1 FOR COLUMNS SIZE 254 ORD_ST |
| 부하 조건 | 단일 세션 · 프로파일 없음 · 설치 후 두 번째 실행 | 같다(단일 세션 · 스크립트 두 번째 판. 두 판의 Buffers는 같았다) |
| 측정 도구 | STATISTICS_LEVEL=ALL + V$SQL 태그 | 같다 · Buffers = V$SQL_PLAN_STATISTICS_ALL에서 가장 큰 줄 · 18화 실습/02(두 번) |
'동일 조건'을 무엇으로 바꿨나: 인덱스 세 개를 지우고 통계를 3월로 되돌리면 3월의 숫자가 다시 나올 뿐이다. 그래서 같은 규약(T0)으로, 지금 상태에서 두 가지를 잰다. 하나는 3월의 SQL 그대로(rev00)이고, 다른 하나는 지금 운영에 나가 있는 판(최신 rev)이다. 앞의 것이 '바닥이 바뀐 몫'이고, 뒤의 것이 '판을 바꾼 몫'이다.
6조각 — 01화값 → 18화값
| 조각 | 설명 | 01화 Buffers | 18화 · rev00 그대로 | 18화 · 최신판 | 최신판 · 계획 해시 | 그때는 왜 옳았고 지금은 왜 다른가 |
|---|---|---|---|---|---|---|
| Q1 | 기간별 주문 조회 | 5,827 | 5,826 (914281838 · 같다) | 91 (rev03) | 92368507 | 그때도 지금도 가공한 컬럼으로는 인덱스를 못 쓴다. 바뀐 것은 SQL이다(02·03화) |
| Q2 | 고객등급별 매출 집계 | 1,026,849 | 1,026,849 (2289018667 · 같다) | 5,868 (rev01 · 18화에 rev02: 같은 Buffers · CPU 115 → 33cs) | 2292855265 → 653275336 | 회의록의 3초 → 0.4초는 그 서버에서는 사실이었다. 2만 건에서도 해시가 138배 이겼지만 손해가 10ms뿐이라 보이지 않았다(06화) |
| Q3 | 상품평가 조인 | 841 | 840 (119122671 · 같다) | 839 (rev01) | 2231864090 | 블록은 그대로지만 답이 50배 → 1배가 됐다(08화). 이 원장의 Buffers로는 보이지 않는 줄이다 |
| Q4 | 정산 목록 페이징 (100페이지) | 5,826 | 1,007 (3040227993 · 다르다) | 14 (rev03) | 3610158121 | rev00이 빨라진 것은 09화 인덱스 덕분이다. SQL이 아니라 바닥이 바뀌었다 |
| Q4c | 총건수 재조회 | 5,826 | 3,365 (97409517 · 다르다) | 없음 | — | 총건수 요구를 화면 주인과 다시 정해서 사라졌다(09화 재협상서) |
| P1 | 정산 적재 배치(10만) | 2,480ms | 850~1,010ms · 논리 읽기 110,1xx~110,4xx · redo 28.6MB · 커밋 101 | 100~110ms · 2,869~2,961 · 0.08~0.10MB · 커밋 2 (rev02) | — | 1,000건 커밋은 2020.07 언두 장애 뒤에는 옳은 처방이었다. 한 문장 + 직접 경로로 바꿔 언두를 쓰지 않게 됐다(13·14화) |
| N1 | 채번 100회 | 440ms | 80~90ms · 논리 읽기 56,800 | 0ms · 0~23 (rev01) | — | MAX+1은 동시에 번호를 받는 사람이 없을 때는 옳았다. 시퀀스로 떼어 냈다(12화) |
- 총 일량(Q1~Q4c): 01화 1,045,169 → 18화 rev00 그대로 1,037,887(−0.7%) → 18화 최신판 6,812(−99.3%)
- 최대 기여: 01화 Q2 98.2% → 18화 최신판 Q2 86.1%(5,868 / 6,812). 남은 일의 대부분은 여전히 Q2이고, 그 5,868은
T_ORD_BIG을 한 번 읽는 양(5,826)이다(07화 · 바닥) - P1 · N1의 ms: 01화의 2,480ms와 440ms는 '설치 후 두 번째 실행'의 값이다. 같은 rev00이 오늘은 1,000ms, 90ms가 나온 이유를 이 원장만으로는 가려낼 수 없다. 그래서 18화 열에는 일의 양을 함께 적었다. 다음 재측정에서는 그 칸으로 비교한다.
- Q1 rev00의 두 번째 실행: 자식 커서가 하나 더 생긴다(statistics feedback: E-Rows 2,500 → 27,390). 계획과 Buffers는 같다.
정합성 (08화 체크리스트 · 졸업 판정 — "불일치가 하나라도 남아 있으면 미완성")
| 조각 | 원장 대조 | 결과 |
|---|---|---|
| Q1 rev03 | 27,390건 · 6,982,065,200 | 원장과 같다 |
| Q2 rev01 · rev02 | 3행 · 255,398,623,700 · MINUS 0 / 0 (rev01 vs rev02) | 같다 |
| Q3 rev01 | 상품별 합계(평가 조인 없음): ITM00071 444,332,400 · 2,000 | 같다(rev00은 ×50) |
| Q4 rev03 | 100페이지(포스트잇 = 991번째 행) vs rev00의 991~1000번째: 10 = 10 · 2,627,200 = 2,627,200 · MINUS 0 / 0 | 같다 |
| P1 rev02 | 100,000 · 25,519,833,100 = T_ORD_STLM | 같다 |
| 불일치 | 0 |
판정 (T9 · 18화)
| 순위 | 조각 | 근거 |
|---|---|---|
| — | 6조각 | 모두 01화 판정의 원인을 없앴다 · 정합성 불일치 0 |
| 감시 | Q2 | 남은 일의 86% · 바닥(테이블 한 번 읽기)에 닿았다. 더 줄이려면 SQL이 아니라 요구(새로 고침 주기 · 16화)를 다시 물어야 한다 |
| 감시 | 시스템 | 일이 줄자 한계가 CPU 둘로 옮겨 갔다(18화 T5-003 · resmgr:cpu quantum 23%) |
다음 재측정
1월 첫 주(6개월 뒤), 또는 T_ORD_BIG이 1,000만 건이 되거나 고객이 2만 명이 될 때, 또는 인덱스나 통계 정책이 바뀔 때 다시 잰다. 그날 이 표의 오른쪽에 열을 하나 더 붙인다. 01화 열과 18화 열은 고치지 않는다.