12.1 성능 문제 접근 순서

성능 문제는 재현 조건과 기준값을 확보한 뒤 병목을 좁혀야 합니다. 근거 없이 설정 속성이나 인덱스를 여러 개 동시에 바꾸면 원인과 효과를 구분할 수 없습니다.

1. 재현 조건 기록

• 느려진 SQL 또는 입력 경로
• 시작·종료 시각과 데이터베이스·사용자
• 대상 테이블, 시간 범위, 행 수와 결과 건수
• 동시 세션·쿼리·Appender 수
• 정상 시점과 문제 시점의 지연·처리량
• 직전 배포, 스키마, 설정 속성, 데이터 분포 변화

2. 자원 병목 확인

iostat -x 1 5
top -b -n 1
free -h

CPU·I/O·메모리 수치는 고정 임계값보다 정상 시점 기준값과 비교합니다. 짧은 일시적 급증과 지속적인 포화를 구분하고, OS 지표 시각을 서버 trace·쿼리 시각과 맞춥니다.

3. 실행 중 작업 확인

SELECT sess_id, id AS stmt_id, state, record_size, query
FROM V$STMT
ORDER BY sess_id, id;

SELECT id, user_name, user_ip, login_time, client_type
FROM V$SESSION
ORDER BY login_time DESC;

장시간 문장, 비정상적으로 늘어난 세션, 같은 쿼리의 동시 실행을 찾습니다. system view 컬럼은 배포 버전에서 DESC로 확인합니다.

4. 실행 계획과 범위 확인

느린 SELECT는 EXPLAIN으로 테이블, 스캔 종류, 키 범위, 필터, 조인을 확인합니다. TAG·LOG 쿼리에 시간 범위가 있는지, 조건이 함수나 형변환 때문에 인덱스 범위에서 제외되는지 점검합니다.

상세 절차는 조회와 분석 성능 튜닝을 참고합니다.

5. 한 가지 변경 후 재측정

변경 후보는 쿼리, 인덱스, 배치, 동시성, 캐시·설정 속성 순서로 좁힙니다. 한 번에 하나만 바꾸고 같은 재현 조건에서 다음을 비교합니다.

효과가 없거나 부작용이 크면 기록한 이전 값으로 되돌립니다. 스키마나 스토리지 구조 변경은 마지막 수단으로 검토하고, 검증 환경과 복구 절차를 먼저 준비합니다.

최종 진단 체크리스트

• 현재 작업과 세션을 정상 기준값과 비교했는가
• 실제 SQL과 시간 범위로 실행 계획을 확인했는가
• 인덱스·ROLLUP 변경이 입력 비용에 미치는 영향을 확인했는가
• OS와 서버 지표의 시각을 같은 작업과 맞췄는가
• 설정 속성·스키마 변경을 한 번에 하나씩 적용했는가
• 원복 값과 재측정 결과를 기록했는가