SQL Viewer
느린 트랜잭션의 원인,
그 안의 SQL 몇 건일 수 있습니다.
트랜잭션 하나에서는 여러 건의 SQL이 실행됩니다. 응답시간을 구간별로 나눠도 'DB에서 시간이 소요됐다'는 것까지만 알 수 있을 뿐, 그 시간이 실제로 어떤 SQL에 사용되었는지는 알 수 없습니다.
OWLens SQL Viewer는 DB 구간을 개별 SQL 단위로 분해해, 원인이 된 SQL과 그 실행 파라미터 값, 호출 방식까지 확인합니다.
수십 개의 SQL 중,
시간을 잡아먹은 SQL은 단 두 건입니다.
현업에서 특정 화면의 응답이 30초씩 걸린다는 문의가 들어옵니다. 응답시간을 구간별로 나눠 보면 대부분 DB 시간이라는 것까지는 확인할 수 있습니다. 하지만 해당 트랜잭션이 실행되는 SQL은 수십 건에 이르고, 그중 어떤 SQL이 실제 DB 시간을 차지했는지는 그 안을 열어보기 전까지 알 수 없습니다. 대부분은 0.1초짜리이고, 문제는 그 사이에 섞여 있는 단 두 건입니다.
응답시간 30초 — 구간으로 나누면 여기까지
그 25초를 SQL 단위로 열어보면 — 20종 중 두 건이 대부분을 차지합니다
… 나머지 15종 · 합계 0.9초 (예시)
응답시간을 구간별로 분해하면 'DB에서 시간을 썼다'까지는 확인할 수 있습니다. 하지만 그 시간을 만든 SQL이 한 건인지 여러 건인지, 그중 어떤 SQL이 시간을 썼는지는 구간 정보만으로 알 수 없습니다.
DB 레벨의 고부하 SQL 목록은 시스템 전체를 기준으로 누적 집계되기 때문에, 실행 빈도가 낮은 SQL은 목록에 나타나지 않을 수 있습니다. 현업에서는 해당 화면이 매번 30초씩 걸리더라도, 전체 누적 집계에서는 보이지 않을 수 있습니다.
실제 SQL과 실행 값을 확인하려면 트레이스를 켜고 동일한 상황을 재현하거나, DB 관리자 권한으로 별도의 전용 뷰를 조회해야 합니다. 하지만 민원이 발생한 뒤 상황을 재현하더라도, 문제가 발생했던 그 시점의 SQL 실행을 그대로 되살릴 수는 없습니다.
OWLens는 이렇게 해결합니다.
현업이 지목한 화면, 즉 해당 T-code·리포트의 실행 건에서 시작합니다. 시스템 전체의 고부하 SQL에서 찾아 내려오는 방식이 아니라, 문제가 발생한 해당 업무의 트랜잭션에서부터 시작합니다.
해당 트랜잭션에서 실행된 SQL을 목록으로 펼치고, 각 SQL의 소요 시간과 호출 지점(Source Module)을 함께 표시합니다. 수십 건의 SQL 가운데 실제로 DB 시간을 차지한 SQL이 바로 드러납니다.
▲ 트랜잭션이 실행한 SQL 목록과 각 건의 소요 시간
분해가 알려주는 두 가지 답 자세히 보기목록에서 해당 SQL을 선택하면 문장 전문과 함께 상세가 열립니다. 실행에 사용된 파라미터 값, 호출된 코드 위치(컴포넌트·소스 라인), 소모한 CPU·메모리, 그리고 데이터베이스를 어떤 방식으로 읽었는지까지 확인해 원인을 규명합니다.
▲ 선택한 SQL의 상세 탭 — SQL 문맥(좌) · SQL 페러미터(우)
SQL Viewer 화면 자세히 보기문제가 SQL 자체인지 코드 구조인지에 따라 개발·DBA로 대상을 구분해 전달합니다. 실행된 SQL 전부를 검토하는 대신, 문제가 확인된 소수의 SQL에만 집중할 수 있습니다.
같은 DB 시간이라도, 분해해 보면 처방이 정반대입니다.
소수의 SQL이 DB 시간 대부분을 차지합니다.
해당 SQL 자체가 대량의 데이터를 읽고 있습니다.
→ SQL·인덱스·조건 튜닝 (DBA·개발)
개별로는 짧은 SQL이 수십·수백 회 반복됩니다.
루프 안에서 SELECT가 호출되는 코드 구조입니다.
→ 코드 구조 개선 (개발)
DB 시간의 총합만 보면 두 경우가 구분되지 않습니다. 분해해야 무엇을 고쳐야 하는지 정해집니다.
담당 업무별 활용 효과
성능 개선의 대상을 데이터로 확정해, 원인이 확인되지 않은 상태에서 불필요한 인프라를 증설하는 과투자를 방지할 수 있습니다.
현업이 지목한 화면이 왜 느린지 확인해 업무 영향을 판단하고, 개선이 필요한 지점을 근거와 함께 정확히 전달할 수 있습니다.
시간을 차지한 SQL과 실행 값·호출 방식을 확인해, 코드 문제는 개발팀으로, DB 문제는 DBA로 정확히 인계할 수 있습니다.
SAP 표준 도구와 OWLens 비교
구간 분해는 'DB에서 시간을 썼다'고 알려줍니다. 그 시간이 무엇이었는지는 열어봐야 알 수 있습니다. OWLens는 문제의 그 시간, 실행된 SQL까지 보여줍니다.
느린 트랜잭션의 SQL 내역을 확인하십시오.
3개월 무료 데모와 설치·교육을 무상으로 제공합니다. 지금 바로 경험해 보세요.
SQL을 목록에서 고르고, 그 한 건을 상세히 확인합니다.
SQL Command 목록 → 선택 → 문장 · 문맥 · 파라미터 · DB 호출 상세
▲ HANA DB 환경의 SQL Viewer 화면
응답시간과 그중 데이터베이스 소요 시간이 함께 표시되어, 분해할 대상의 규모를 먼저 확인합니다.
DB Time이 10,216ms인 트랜잭션에서 한 건의 SQL Time이 10,078ms라면, 그 한 건이 사실상 전부입니다. 목록에서 그 행을 선택해 상세로 들어갑니다.
선택한 행의 SQL 문장이 그대로 표시됩니다. 파라미터 자리는 ?로 표기되며, 실제 값은 아래 SQL 페러미터 탭에서 확인합니다.
동일한 SQL이라도 전달된 조건 값에 따라 읽는 범위가 달라집니다. 값이 있어야 그 실행이 왜 무거웠는지 판단하고 재현할 수 있습니다.
Sequential read의 rows가 크면 조건 없는 대량 조회를, Requests 횟수가 크면 반복 호출을, Requests to buffer 비중이 낮으면 버퍼 활용도를 점검합니다. 앞서 본 두 패턴이 여기서 수치로 확정됩니다.
ECC 등 Oracle 데이터베이스 환경에서도 동일하게 목록에서 SQL을 선택해 상세를 확인합니다. 데이터베이스가 제공하는 정보 체계가 달라 항목 구성에 차이가 있으며, Oracle 환경에서는 바인드 변수 목록과 실행 계획을 함께 제공합니다.
▲ Oracle DB 환경의 SQL Viewer 화면
Oracle 환경에서는 SQL ID·Child Number 체계로 SQL을 식별하며, 실행 계획에서 처리 경로와 비용을 단계별로 확인할 수 있습니다.
목록에서 시간을 가져간 SQL을 고르고, 그 한 건을 어떤 값으로 · 어느 코드에서 · 어떤 방식으로 실행했는지까지 확인해 개선 대상을 확정합니다.
