SQLP 튜닝 연습장

테마

T8 — 정기 점검 체크리스트 (일간 5칸 · 주간 4칸) (템플릿) ​

16화에서 제정했다. 티켓이 오기 전에 하는 일이다. 01~15화는 모두 누군가의 민원에서 시작했다. 하지만 튜너가 평소에 하는 일은 민원이 오기 전에 같은 숫자를 매일, 매주 들여다보는 것이다. 이 문서는 비교할 때만 쓴다. 오늘 숫자 하나만 봐서는 알 수 있는 것이 없다. 어제나 지난주의 같은 칸 옆에 놓아야 무엇이 움직였는지 보인다.

왜 이 문서가 있는가 ​

16화에서 "운영 전체가 느리다"는 민원에 답하려고 처음 AWR을 열었을 때는 비교할 어제가 없었다. 그래서 연습 DB에 같은 부하를 두 번 만들어 나란히 놓아야 했다. 하나는 보정 배치 rev00이 돌던 월요일(구간 A), 다른 하나는 rev01이 도는 월요일(구간 B)이다.

16화 실측 (구간 A → B · 같은 부하 · 9분씩)AB
DB Time1,685.0초1,691.0초그대로. 보정 배치를 고친 효과는 DB Time으로는 보이지 않는다
Executes / 초2,112.61,550.9−26.6%. 바뀐 것이 남긴 자국
Redo / 초773,747681,451−11.9%
Execute to Parse %73.0563.28고쳤더니 '효율'이 떨어졌다(07화 히트율과 같은 함정)

매주 같은 칸을 적어 두었다면 "전체가 느리다"는 민원에 "지난주와 무엇이 달라졌나"로 바로 답할 수 있다.

정기 점검에서 의미 있는 것은 오늘의 숫자가 아니라 지난번과의 차이다.

작성 규칙 ​

같은 시간대끼리 비교한다월요일 10시와 일요일 새벽을 견주지 않는다. 어제 같은 시각, 지난주 같은 요일과 비교한다
비율보다 절대량을 본다Instance Efficiency의 %는 옆 칸에 참고로만 적는다(07·16화)
움직인 칸만 원인을 묻는다모든 칸을 매일 해석하지 않는다. ±10%를 넘게 움직였거나 새로 들어온 줄만 본다
문서의 기한도 점검한다주간 ⑧ ⑨ 칸. 다른 리포트가 남긴 '다시 잴 조건'은 이 점검에서 다시 꺼낸다
30분 안에 끝낸다주 1회 30분(평시 레인). 그보다 오래 걸리면 칸이 너무 많은 것이다

양식 ​

┌──────────────────────────────────────────────────────────────────────────────┐
│ T8 정기 점검 — N호   기간 : ________ ~ ________   비교 기준 : ______________ │
└──────────────────────────────────────────────────────────────────────────────┘

일간 5칸 ​

#칸지난번이번움직임원인을 물을까
①Top 5 Foreground Events: 순위와 % DB time · 새로 들어온 이벤트
②DB Time 추세: 시간대별 평균 활성 세션(DB Time ÷ Elapsed)과 cpu_count 비교
③새로 들어온 Top SQL: Elapsed 상위 10개의 새 얼굴 · 사라진 얼굴
④배치 소요 시간과 마감 여유: 배치마다 시작 · 끝 · 여유(T3 1번 칸)
⑤세그먼트 · 저장소 증가: 큰 세그먼트의 블록 수 · SYSAUX에서 AWR이 차지하는 몫

주간 4칸 ​

#칸확인결과조치
⑥인덱스 사용: 새 인덱스 · 쓰이지 않는 인덱스(DBA_INDEX_USAGE · AWR 계획 DBA_HIST_SQL_PLAN)
⑦통계 신선도: LAST_ANALYZED · STALE_STATS · 히스토그램 변화(통계 수집 정책서)
⑧힌트 유효기간 대장 만기분: 각 행의 재검토 조건(규모 · 파라미터 · 기간)에 걸린 것(대장)
⑨리포트 재측정 기한 도래분: T1 · T2 · T3 · T4의 '재측정 · 재발방지' 칸 중 기한이 된 것

이번 점검에서 연 티켓 ​

#무엇근거 칸담당기한

금지어 ​

"특이사항 없음": 칸마다 지난번 값과 이번 값을 적은 뒤에만 쓴다. 값 없이 쓴 '특이사항 없음'은 점검을 하지 않은 것과 같다.

자매 문서

개정 이력: 16화에 제정했다(1호 = 6월 24일. 연습 DB의 구간 A와 B를 각각 지난주와 이번 주로 놓고 적었다).