Oracle® Enterprise Manager(OEM) 12c와 13c는 다양한 성능 분석 도구를 제공합니다. 그중에서도 OEM Real-Time ADDM(Automatic Database Diagnostic Monitor)은 Oracle DBA가 실시간으로 진행 중인 성능 문제를 진단하고 튜닝할 때 활용할 수 있는 강력한 지원 도구입니다. 이 글에서는 세션 100% 점유, 프로세스 사용률 포화, 또는 I/O·메모리·인터커넥트에 설정된 임계치 초과 같은 데이터베이스 건강 문제로 인한 비상 상황을 Real-Time ADDM으로 식별하고 극복하는 실전 노하우를 공유합니다. 이런 상황에서 Real-Time ADDM은 매우 유용하며, 데이터베이스 상태에 대해 더 깊이 있는 실시간 ADDM 분석을 수행할 수 있게 해줍니다. 그럼 RADDM과 ADDM을 비교해 보겠습니다.
ADDM이란 무엇인가?
ADDM은 Oracle Database 10g부터 제공되는 도구로, AWR(Automatic Workload Repository)의 데이터를 분석하여 잠재적인 성능 병목 지점을 찾아냅니다. 식별된 각 문제에 대해 근본 원인을 파악하고, 이를 해결하기 위한 권장 조치를 제시합니다.
Real-Time ADDM이란 무엇인가?
Oracle Enterprise Manager(OEM) Cloud Control 12c에서 Oracle은 Real-Time ADDM 도구를 선보였습니다. 이 도구는 기존에는 데이터베이스를 재시작해야만 해결할 수 있었던 응답 없는(hung) 데이터베이스의 문제를 분석하고 해결하는 데 도움을 줍니다. Real-Time ADDM은 사전에 정의된 일련의 기준을 바탕으로 현재 데이터베이스 성능을 분석하며, 기준에 부합하는 문제가 발견되면 데이터베이스를 재시작하지 않고도 교착 상태(deadlock), hang, 공유 풀 경합 등의 예외 상황을 해결할 수 있도록 지원합니다.
DBA는 Real-Time ADDM을 사용해 데이터베이스 성능을 자동으로 분석할 수 있습니다. 예를 들어, 성능 문제로 데이터베이스가 멈추거나 현저히 느려져 로그인조차 불가능한 상황에서 Real-Time ADDM은 전역 리소스에서 발생하는 SQL 경합의 원인을 찾아냅니다.
또한 Real-Time ADDM은 ADDM과 마찬가지로 실질적인 데이터베이스 시간(DB Time) 분석을 수행합니다. 비정상적으로 높은 활동이 감지되는 데이터베이스에서 Real-Time ADDM을 실행하면 현재 데이터베이스에 영향을 주는 최상위 성능 문제를 탐지하고, SQL 세션이나 애플리케이션 연결처럼 DB Time을 가장 많이 소비하는 요인을 식별할 수 있습니다.
ADDM과 Real-Time ADDM의 차이
ADDM은 데이터베이스 레벨의 성능 진단 도구로 제공되며, Real-Time ADDM은 OEM 12c 이상 버전에서 제공되는 도구입니다. Real-Time ADDM을 사용하려면 데이터베이스에 연결된 OEM 환경이 먼저 준비되어 있어야 합니다.
두 도구의 가장 큰 차이는 Real-Time ADDM이 진단 모드(diagnostic mode) 연결을 사용해 데이터베이스 인스턴스의 SGA(System Global Area)에 있는 ASH(Active Session History) 데이터에 직접 접근한다는 점입니다. 이 과정에서 일반 모드 연결을 우회하며, 래치(latch)나 큐(queue) 같은 전역 리소스나 과도한 호스트 리소스를 소모하지 않습니다.
Real-Time ADDM을 사용해야 하는 이유
다음은 Real-Time ADDM을 활용해야 하는 주요 이유입니다.
- 데이터베이스가 멈추거나 느려졌을 때 현재 성능을 분석
- 심각한 경합(contention)의 원인 파악
- DB Time 분석을 통해 최상위 성능 문제 탐지
- SGA로 직접 진단 연결 수립
- 대용량 트레이스 파일을 읽고 분석하기 위한 HANGANALYZE나 ORADEBUG(Oracle Database의 기본 트레이스 유틸리티) 사용 불필요
HANGANALYZE란?
HANGANALYZE는 ORADEBUG 내에 포함된 옵션으로, 멈춘(hang) 세션이나 블로킹 세션에 대한 상세 정보를 확인하는 데 사용됩니다. HANGANALYZE 옵션을 활용하면 DBA가 멈춘 데이터베이스에 접속해 트레이스 파일을 생성할 수 있으며, 이 파일을 직접 읽거나 트레이스 분석 도구와 함께 사용해 hang 문제의 원인을 파악할 수 있습니다.
Real-Time ADDM을 활용한 문제 해결 데모
OEM 12c가 대상 데이터베이스와 연결된 상태로 구성되어 있다고 가정하고, 데이터베이스 인스턴스가 멈춘 상태일 때 Real-Time ADDM 분석을 수행하는 절차를 살펴보겠습니다.
터미널 세션을 열어 데이터베이스에 접속을 시도합니다. 세션이 시작되지 않는 것을 확인할 수 있습니다. 아래 이미지처럼 hang 상태 때문에 연결이 수립되지 않아 데이터베이스에 로그인할 수 없습니다.
이제 OEM으로 이동하여 대상(Target) 메뉴에서 Databases for Troubleshooting을 선택하고 데이터베이스 이름을 검색합니다. 아래 이미지에서는 CAC****1P를 검색하고 있습니다.
데이터베이스 이름을 클릭합니다. 시간이 다소 걸릴 수 있으니 새로고침될 때까지 기다립니다. 잠시 후 아래 이미지에 강조된 오류 메시지가 표시됩니다.
바로 이런 상황에서 Real-Time ADDM이 DBA에게 큰 힘이 됩니다. 해당 인스턴스에서 Real-Time ADDM을 시작해 보겠습니다. 데이터베이스 페이지에서 성능(Performance) 메뉴로 이동해 Real-Time ADDM을 선택하면 아래 화면으로 이동합니다. 인스턴스가 hang 상태이기 때문에 Real-Time ADDM은 직접 연결(direct connection) 방식을 사용합니다.
hang 상황에서 Real-Time ADDM 연결에는 SYSDBA 권한의 자격 증명을 사용해야 합니다(아래 이미지 참조).
진단 모드 연결이 수립되면 메모리에서 ASH 데이터를 직접 읽을 수 있으며, 조회 범위는 지난 1시간부터 시작됩니다. 로그인 후에는 아래 이미지처럼 활동 화면 상단에서 최상위 활동(Top Activity)을 확인할 수 있습니다.
여기서 데이터베이스가 멈추게 만든 원인을 확인할 수 있습니다. 이 예제에서는 애플리케이션 워크로드 클래스와 관련된 문제였습니다. 이를 분석하려면 진단을 시작해 더 많은 통찰을 얻어야 합니다. START를 클릭해 분석을 시작합니다. Real-Time ADDM은 최근 10분간의 ASH 샘플을 검토해 문제를 판단합니다. 10분 후에는 STOP을 클릭해 분석을 종료합니다. 분석이 완료되면 Real-Time ADDM은 우선순위에 따라 결과를 표시합니다. 아래 이미지는 Findings 탭에서 확인한 분석 결과입니다.
이 예제에서는 해소되지 않은 세션 대기 체인(wait chain)이 데이터베이스 hang의 원인으로 나타났습니다. 문제 해결을 위한 권장 조치는 아래 이미지와 같습니다.
이 예제에서 Real-Time ADDM은 특정 세션을 종료(kill)할 것을 권장했습니다(위 이미지 참조). 종료해야 할 프로세스에 대한 자세한 정보를 확인하려면 Hang Data 탭으로 이동합니다(아래 이미지 참조).
Final Blockers를 클릭하면 블로커 세션 요약을 볼 수 있습니다. 권장된 대로 세션 ID(SID), 시리얼 번호(Serial #), OS 프로세스 ID 등 세션 정보를 확인한 후 데이터베이스 레벨에서 해당 세션을 종료합니다. 여전히 데이터베이스에 로그인할 수 없다면 OS 프로세스 ID를 종료하는 것이 유일한 방법입니다. 이 경우 터미널을 열어 문제를 일으키는 세션을 종료합니다(아래 이미지 참조).
그 후 Real-Time ADDM 분석 창에서 차단되었던 세션이 정상적으로 진행되는 것을 확인할 수 있습니다. 이제 터미널에서 SQL*Plus로 다시 접속을 시도하면, 이번에는 아래 이미지처럼 연결에 성공합니다.
결론
OEM Cloud Control 12c의 Real-Time ADDM은 중요한 데이터베이스 건강 상태를 진단하는 Oracle의 가장 빠르고 강력한 도구 중 하나입니다. 데이터베이스가 멈춘 상황에서 Real-Time ADDM은 용도가 제한적인 ADDM이나 ORADEBUG의 HANGANALYZE 트레이스 유틸리티에 비해 DBA에게 확실하고 효과적인 지원책이 됩니다. 위에서 안내한 단계를 활용하면 데이터베이스나 세션 hang 문제를 극복하고 데이터베이스를 신속하게 정상 운영 상태로 되돌릴 수 있습니다.
피드백 탭을 통해 의견을 남기거나 질문해 주세요.