서론 오후에 개발팀에서 특정 SQL의 실행 시간이 1초에서 16초로 급격히 증가해 시스템 운영에 영향을 미쳤다는 피드백을 받았습니다. 분석 및 최적화 후 SQL의 성능이 회복되고, 데이터베이스 전체 성능이 99.99% 향상되었습니다.

문제 진단 데이터베이스 환경은 Oracle 19C RAC CDB 구조로 구성되어 있으며, 6개의 PDB가 운영 중이었습니다. 문제 발생 시각은 2025년 11월 27일 13시 11분 09.227초입니다.

SQL 분석 개발자가 로그에서 특정 SQL의 실행 시간 증가를 확인했으며, 이로 인해 인터페이스 타임아웃이 발생했습니다. 먼저 SQLID 3jm7s0g3w2px0를 사용하여 AWR SQL 보고서를 확인하고, 실행 계획을 분석했습니다:

SELECT * FROM TABLE(dbms_xplan.display_cursor('3jm7s0g3w2px0', NULL));

AWR 보고서에서 두 가지 실행 계획이 나타났습니다. 느린 실행 계획은 전체 테이블 스캔을 사용하며, I/O 대기 시간이 주요 원인이었습니다. 반면 빠른 실행 계획은 인덱스 접근을 사용하고 I/O 대기를 줄였습니다.

실행 계획 고정 최적 실행 계획을 강제하기 위해 coe_xfr_sql_profile 스크립트를 사용했습니다:

@coe_xfr_sql_profile SQL_ID_123456 EXEC_PLAN_HASH_789012

생성된 스크립트를 실행하여 실행 계획을 적용한 후, 다음 명령어로 결과를 확인했습니다:

SELECT name, status, created, type FROM dba_sql_profiles;

결과적으로 SQL 실행 속도가 정상화되었고, 시스템 운영이 회복되었습니다.

AWR 분석 초기 문제는 해결되었지만, AWR 보고서를 통해 더 심각한 성능 문제를 발견했습니다. 60분간 수집된 데이터에서 DB Time이 1,592.57분으로 매우 높았으며, 평균 활성 세션 수가 23.6이었습니다. Direct Reads 비중이 96%에 달하는 등 I/O 부하가 심각했습니다.

sqlhc 분석 sqlhc 도구를 사용해 SQL 실행 계획을 분석한 결과, 특정 시점부터 I/O 대기 시간이 급증했다는 사실을 확인했습니다. 이는 시스템 전체 I/O 부하와 관련된 문제로 판단되었습니다.

개발자 의견 개발팀은 최적화된 인덱스 생성을 제안했으나, 다음과 같은 질문을 제기했습니다:

1. 이미 인덱스가 생성된 상태인데 왜 전체 테이블 스캔이 선택되었는가?
2. 해당 SQL만 문제가 되는지 다른 SQL과의 관계는 없는가?
3. SPC 데이터베이스의 SQL이 MES 데이터베이스에 영향을 미친다는데 이유는 무엇인가?

해결 방안으로 통계 정보 정확도, 인덱스 선택성, RAC CDB 환경의 공유 리소스 특성을 설명하며 이해를 이끌었습니다.

문제 해결 공동 인덱스 생성 후 AWR 보고서를 확인한 결과, 시스템 성능이 크게 개선되었고, 문제가 된 SQL은 Top SQL 목록에서 사라졌습니다. 이는 단일 SQL이 시스템 전체에 영향을 줄 수 있음을 보여주는 사례입니다.

결론 이번 사례는 단순한 실행 계획 오류가 아닌 시스템 전체 I/O 부하를 유발할 수 있음을 보여줍니다. 데이터베이스 성능 최적화는 단순한 SQL 조정을 넘어 체계적인 접근이 필요합니다.