<오라클 성능 고도화 원리와 해법1> Ch03-09 ASH(Active Session History)

오라클 성능 고도화 원리와 해법 1 - Ch03-09 ASH(Active Session History)

Ratio 기반 분석 방법론의 한계는 시스템에 문제가 있다고 진단됐을 때 그 원인을 찾아 실제 문제를 해결하기까지 많은 시간이 걸리는 데 있다고 했다. 이것은 대기 이벤트 기반 분석 방법론을 사용할 때도 마찬가지다. 대기 이벤트 발생량과 대기 시간을 통해 문제의 원인을 알 수는 있지만, 구체적으로 어떤 프로그램에서 문제를 일으켰고 어떤 세션에서 성능 문제를 겪었는지 확인할 필요가 있다. 물론 시스템 레벨에서 분석하고 해결할 수 있는 구조적인 문제들30)도 있기는 하다. 하지만 그런 구조적인 문제가 흔히 발생하는 것은 아니므로 대개는 세션 레벨의 분석을 요한다.

30) 예를 들어, 최근에 급하게 방문 요청을 받아 진단했던 모 보험 회사 시스템 분석 결과 'gc cr block lost'와 'gc current block lost' 이벤트에 의한 대기 시간이 가장 높게 나타나고 있었다. 이는 네트워크 설정이 잘못됐거나 물리적인 이상이 발생했을 때 생기는 현상이다.

그런데 오라클이 기존에 제공하는 세션 레벨 동적 성능 뷰만으로는 문제를 빨리 찾기 어렵거나 아예 불가능한 경우가 대부분이었다. SQL 트레이스를 통해 가장 상세한 세션 레벨 분석이 가능하지만 시스템에 주는 부하가 크고 파일 단위로 정보가 수집되기 때문에 통계적 접근이 어렵고 분석을 완료하는 데까지 시간이 오래 걸린다. 게다가 수동으로 활성화해야 하기 때문에 SQL 트레이스를 걸어 확인하려는 순간 이미 상황이 종료돼 버리는 경험을 DB 관리자라면 누구나 했을 것이다. 그리고 문제가 발생하기 직전 상황에 대한 분석은 아예 불가능하다.

이런 DB 성능 관리자들의 고충을 잘 이해한 오라클이 10g에서 ASH 기능을 탄생시켰다. 10g AWR은 데이터 수집을 아주 빠르게, 좀 더 많이 한다는 것 외에는 외형적으로 Statspack과 크게 달라진 것이 없다고 느낄 것이다. 하지만 ASH를 보는 순간 생각이 달라진다. 10g에서 개선되고 추가된 기능 중 가장 유용한 것을 하나 꼽으라면 단연 ASH를 들 수 있다.

이것은 별도의 Third Party 모니터링 도구 없이 오라클 내에서 세션 레벨 실시간 모니터링을 가능하게 하는 강력한 기능으로서, OWI의 활용성을 극대화해준다.

오브젝트 정보도 더할 나위 없이 유용하지만 현재 발생 중인 대기 이벤트의 Wait Class가 Application, Concurrency, Cluster, User I/O일 때만 의미 있는 값임을 알아야 한다.

문제가 되는 대기 이벤트는 일정 간격을 두고 지속적으로 발생하기 때문에 샘플링된 자료만으로도 원인을 찾는 데 큰 지장은 없다.

이처럼 부하를 최소화하면서, 세션 레벨의 상세한 분석이 가능하도록 오라클이 성능 자료를 수집해주므로 이제 AWR과 ASH를 잘 이용하면 전문 성능 관리 툴의 도움 없이도 효과적으로 성능 분석을 할 수 있게 되었다.