오라클에서 AP/WAS 접속 서비스 식별

오라클에서 AP/WAS 접속 서비스 식별하는 방법

데이터베이스에 붙는 AP/WAS(애플리케이션 서버)나 배치, 도구 접속을 구분하려면 세션 메타데이터를 보는 게 가장 빠릅니다.
핵심은 “DB가 아는 정보(서버/프로그램/앱이 넘겨준 모듈)”를 조합해서 어떤 서비스가 붙었는지 실무적으로 식별하는 것입니다.

개요

오라클 DB는 기본적으로 “정확히 어떤 WAS 서비스인지”를 100% 자동 판별하진 못합니다.
대신 아래 컬럼 조합으로 거의 실무 수준의 식별이 가능합니다.

MACHINE 접속 서버명/호스트 PROGRAM 클라이언트 프로그램 MODULE 애플리케이션 모듈명 ACTION 세부 기능명 CLIENT_IDENTIFIER 사용자/시스템 식별값 SERVICE_NAME DB 서비스명

실무 기준으로 보면
MODULE/ACTION/CLIENT_IDENTIFIER가 찍히는 환경이 가장 분석이 쉽습니다.
반대로 앱이 값을 넣지 않으면 PROGRAM이 “JDBC” 계열로만 보여서 서비스 식별이 어려워질 수 있습니다.

환경

• 대상 DB: Oracle Database
• 주요 뷰: V$SESSION, V$PROCESS, V$SESSION_CONNECT_INFO, (필요 시) V$SQL
• 권한: 해당 뷰 조회 권한 필요(운영 환경에서는 계정/권한 정책에 따라 제한될 수 있음)

증상

• DB에 연결된 외부 서비스(AP/WAS/배치/툴)가 무엇인지 확인이 필요함
• 특정 DB 계정(APP 계정 등)이 “어느 서버에서 어떤 형태로” 사용되는지 추적해야 함
• 접속이 급증했는데, 어떤 서버/모듈 조합이 원인인지 빠르게 집계해야 함

1차 점검

1) 현재 접속 중인 사용자 세션 확인

SELECT
    s.sid,
    s.serial#,
    s.username,
    s.osuser,
    s.machine,
    s.program,
    s.module,
    s.action,
    s.client_identifier,
    s.status,
    s.logon_time,
    s.service_name
FROM
    v$session s
WHERE
    s.type = 'USER'
    AND s.username IS NOT NULL
ORDER BY
    s.logon_time DESC;

해석 포인트
MACHINE: “어느 서버/호스트에서 왔는지” 후보를 잡는 1순위
PROGRAM: JDBC/OCI/툴 접속(예: SQL*Plus, DBeaver 등) 구분
MODULE/ACTION: 앱이 넣어준 값이면 서비스 식별에 가장 유용

2) JDBC/모듈 기반으로 AP/WAS 세션만 추리기

SELECT
    s.sid,
    s.serial#,
    s.username,
    s.machine,
    s.program,
    s.module,
    s.action,
    s.service_name,
    s.logon_time
FROM
    v$session s
WHERE
    s.type = 'USER'
    AND s.username IS NOT NULL
    AND (
        s.program LIKE '%JDBC%'
        OR s.module IS NOT NULL
    )
ORDER BY
    s.machine, s.logon_time;

운영 환경에서는 “툴 접속”과 “서버 풀링 접속”을 분리하는 것만으로도 원인 후보가 크게 줄어듭니다.

심화 분석

3) 어떤 서버/프로그램/모듈 조합이 많은지 집계

SELECT
    s.machine,
    s.program,
    s.module,
    COUNT(*) AS session_count
FROM
    v$session s
WHERE
    s.type = 'USER'
    AND s.username IS NOT NULL
GROUP BY
    s.machine,
    s.program,
    s.module
ORDER BY
    session_count DESC;

4) 세션(SID)과 DB 서버 OS 프로세스(SPID) 매핑

SELECT
    s.sid,
    s.serial#,
    s.username,
    s.machine,
    s.program,
    s.module,
    p.spid AS os_pid,
    s.status,
    s.logon_time
FROM
    v$session s,
    v$process p
WHERE
    s.paddr = p.addr
    AND s.type = 'USER'
    AND s.username IS NOT NULL
ORDER BY
    s.logon_time DESC;

5) 드라이버/접속 배너로 JDBC/OCI 등 접속 방식 확인

SELECT
    s.sid,
    s.serial#,
    s.username,
    s.machine,
    s.program,
    ci.network_service_banner
FROM
    v$session s
JOIN
    v$session_connect_info ci
    ON s.sid = ci.sid
WHERE
    s.type = 'USER'
    AND s.username IS NOT NULL
ORDER BY
    s.sid;

중요
일부 환경에서는 V$SESSION의 MACHINE이 IP가 아니라 호스트명/DNS/중계 서버명으로 찍힙니다.
“특정 IP”를 기준으로 찾고 싶다면, DB 뷰만으로 안 보이는 케이스가 있어 리스너 로그/네트워크 로그가 더 정확할 수 있습니다.

6) 특정 DB 계정이 어떤 AP/WAS에서 쓰이는지 확인

SELECT
    s.sid,
    s.serial#,
    s.username,
    s.machine,
    s.program,
    s.module,
    s.action,
    s.client_identifier,
    s.status,
    s.logon_time
FROM
    v$session s
WHERE
    s.username = 'APPUSER'
ORDER BY
    s.logon_time DESC;

7) 실행 중인 SQL까지 같이 보기(필요 시)

SELECT
    s.sid,
    s.serial#,
    s.username,
    s.machine,
    s.program,
    s.module,
    s.action,
    s.sql_id,
    q.sql_text
FROM
    v$session s
LEFT JOIN
    v$sql q
    ON s.sql_id = q.sql_id
WHERE
    s.type = 'USER'
    AND s.username IS NOT NULL;

복구

여기서 말하는 “복구”는 장애 조치라기보다, 원인 서비스(서버/모듈) 특정 후 즉시 통제에 초점을 둡니다.

1) 현재 서비스 성격을 한 번에 파악하는 집계 쿼리

SELECT
    s.username,
    s.machine,
    s.program,
    s.module,
    s.action,
    s.client_identifier,
    s.service_name,
    COUNT(*) AS cnt
FROM
    v$session s
WHERE
    s.type = 'USER'
    AND s.username IS NOT NULL
GROUP BY
    s.username,
    s.machine,
    s.program,
    s.module,
    s.action,
    s.client_identifier,
    s.service_name
ORDER BY
    cnt DESC;

즉시 조치 예시(운영 정책에 따름)
특정 MACHINE/MODULE 조합이 폭증했다면
1) 해당 AP/WAS 풀 상태 확인
2) 배치/스케줄러 중복 실행 여부 확인
3) 연결 풀(Connection Pool) 누수/재시도 폭주 여부 점검
4) 필요 시 해당 서비스의 접속 정책(방화벽/리스너/계정)으로 임시 차단

재발 방지

1) 애플리케이션에서 MODULE/ACTION을 넣도록 표준화

권장 방향
애플리케이션에서 DB 접속 후 모듈/액션을 세팅하면, DB에서 서비스 식별이 압도적으로 쉬워집니다.
예: DBMS_APPLICATION_INFO.SET_MODULE / SET_ACTION 활용
(적용 방식은 프레임워크/드라이버에 따라 달라질 수 있으므로 개발 표준에 포함시키는 방식이 안전합니다.)

2) MACHINE이 IP로 안 찍히는 환경 대비

• NAT/프록시/게이트웨이/커넥션 풀링 구조에서는 “최종 사용자 IP”가 DB에 그대로 보이지 않을 수 있음
• 이 경우 “리스너 로그 + 앱 로그 + 네트워크 장비 로그”를 함께 보는 절차가 필요
• 관리자 입장에서는, DB 단에서 식별 가능한 값(MODULE/CLIENT_IDENTIFIER)을 강화하는 편이 유지보수 비용이 낮음

3) 점검 체크리스트(짧게)

• 접속 급증 시: machine + program + module 집계로 1차 원인 후보 압축
• 특정 계정 이슈: username = 'APPUSER' 형태로 세션을 먼저 고정
• 툴 접속 구분: PROGRAM 기준(예: SQL*Plus/GUI툴/JDBC 등)으로 분리
• 식별력 강화: 앱 표준으로 MODULE/ACTION/CLIENT_IDENTIFIER 세팅