Oracle ORA-01013 오류 원인과 해결 방법 완벽 가이드

ORA-01013
2026년 06월 27일 | DBMS Error 가이드

이 글에서 다루는 내용

ORA-01013 에러의 원인 분석, 해결 SQL, 예방 방법을 실무 관점에서 정리합니다.

ORA-01013 user requested cancel of current operation 는?

ORA-01013은 사용자 또는 애플리케이션이 현재 실행 중인 데이터베이스 작업을 명시적으로 취소했을 때 발생하는 Oracle 에러입니다. 주로 쿼리 실행 시간이 너무 길어 사용자가 강제로 중단하거나, 애플리케이션 레벨에서 타임아웃 설정에 의해 자동으로 취소 요청이 발생할 때 나타납니다. 이 에러 자체는 데이터베이스의 결함이 아니라 외부적인 취소 신호에 의한 것이므로, 근본 원인을 파악하여 쿼리 최적화 또는 타임아웃 설정 조정이 필요합니다.

주요 발생 원인

1. 애플리케이션 타임아웃(Query Timeout) 설정

JDBC, ODBC, OCI 등의 드라이버나 미들웨어(WAS)에서 쿼리 실행 시간 제한을 설정해 두었을 때, 해당 시간을 초과하면 드라이버가 자동으로 취소 요청을 Oracle 서버에 전송합니다. 예를 들어 Java 애플리케이션에서 Statement.setQueryTimeout(30)으로 30초 제한을 걸어 두었는데 쿼리가 30초를 넘기면 ORA-01013이 발생합니다. 실무에서 가장 빈번하게 발생하는 케이스로, 애플리케이션 로그와 Oracle Alert 로그를 함께 확인해야 정확한 원인 파악이 가능합니다.

2. 비효율적인 SQL 쿼리 및 인덱스 미사용

대용량 테이블에 대해 Full Table Scan이 발생하거나, 잘못된 조인 조건, 적절하지 않은 인덱스 사용으로 인해 쿼리 실행 시간이 비정상적으로 길어지는 경우입니다. 이처럼 실행 시간이 길어지면 사용자가 직접 Ctrl+C를 누르거나 DBA가 세션을 강제 종료하거나, 혹은 모니터링 도구가 자동으로 취소 신호를 보내 ORA-01013이 발생합니다. 따라서 실행 계획(Execution Plan)을 분석하여 쿼리 튜닝이 선행되어야 합니다.

3. OCI/JDBC 클라이언트에서 사용자 인터럽트 또는 프로세스 강제 종료

SQL*Plus나 기타 툴에서 사용자가 쿼리 실행 중 Ctrl+C를 입력하거나, 운영체제 레벨에서 클라이언트 프로세스가 종료(kill)되는 경우에도 Oracle 서버 측에서 ORA-01013을 반환합니다. 배치 작업이나 야간 ETL 작업에서 특정 조건에 의해 외부 스크립트가 프로세스를 강제 종료할 때도 발생할 수 있습니다. 이 경우 V$SESSION 뷰를 통해 해당 세션의 상태를 확인하는 것이 중요합니다.

해결 방법

원인 1: 타임아웃 설정 조정

먼저 현재 실행 중인 장시간 쿼리와 세션 정보를 확인합니다.

-- 현재 실행 시간이 긴 SQL 세션 확인
SELECT s.sid,
       s.serial#,
       s.username,
       s.status,
       s.sql_id,
       s.last_call_et AS elapsed_seconds,
       q.sql_text
FROM   v$session s
JOIN   v$sql q ON s.sql_id = q.sql_id
WHERE  s.status = 'ACTIVE'
  AND  s.last_call_et > 30   -- 30초 이상 실행 중인 세션
ORDER BY s.last_call_et DESC;

애플리케이션의 타임아웃 값을 늘리거나, Oracle 프로파일을 통해 세션별 타임아웃을 관리할 수 있습니다.

-- Oracle Profile을 이용한 세션 유휴 시간 설정 (필요 시 조정)
CREATE PROFILE app_user_profile LIMIT
    IDLE_TIME          30       -- 유휴 상태 허용 시간(분)
    CONNECT_TIME       480;     -- 최대 접속 유지 시간(분)

-- 프로파일 사용자에게 적용
ALTER USER app_user PROFILE app_user_profile;

-- 현재 프로파일 설정 확인
SELECT resource_name, limit
FROM   dba_profiles
WHERE  profile = 'APP_USER_PROFILE';

원인 2: SQL 쿼리 튜닝

실행 계획을 확인하여 Full Table Scan 여부와 인덱스 사용 현황을 분석합니다.

-- 실행 계획 확인 (EXPLAIN PLAN)
EXPLAIN PLAN FOR
SELECT /*+ GATHER_PLAN_STATISTICS */
       o.order_id,
       c.customer_name,
       o.order_date,
       o.total_amount
FROM   orders o
JOIN   customers c ON o.customer_id = c.customer_id
WHERE  o.order_date >= TRUNC(SYSDATE) - 90
  AND  o.status = 'PENDING';

-- 실행 계획 출력
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY(FORMAT => 'ALLSTATS LAST'));

-- 인덱스 생성으로 Full Table Scan 제거
CREATE INDEX idx_orders_date_status
    ON orders (order_date, status);

-- 힌트를 사용하여 특정 인덱스 강제 사용 (테스트 목적)
SELECT /*+ INDEX(o idx_orders_date_status) */
       o.order_id,
       c.customer_name,
       o.order_date,
       o.total_amount
FROM   orders o
JOIN   customers c ON o.customer_id = c.customer_id
WHERE  o.order_date >= TRUNC(SYSDATE) - 90
  AND  o.status = 'PENDING';

-- AWR을 통한 고비용 SQL 식별 (DBA 권한 필요)
SELECT sql_id,
       elapsed_time / executions AS avg_elapsed_time,
       disk_reads / executions   AS avg_disk_reads,
       buffer_gets / executions  AS avg_buffer_gets,
       executions,
       sql_text
FROM   v$sql
WHERE  executions > 0
  AND  elapsed_time / executions > 5000000   -- 평균 5초 이상 소요
ORDER BY avg_elapsed_time DESC
FETCH FIRST 10 ROWS ONLY;

원인 3: 세션 및 프로세스 확인 후 정리

강제 종료된 세션이 남아 있는지 확인하고, 필요시 정리합니다.

-- 비정상 상태 세션 확인
SELECT sid,
       serial#,
       username,
       status,
       osuser,
       machine,
       program,
       last_call_et
FROM   v$session
WHERE  status IN ('KILLED', 'SNIPED')
ORDER BY last_call_et DESC;

-- 문제 세션 강제 종료 (DBA 권한 필요)
ALTER SYSTEM KILL SESSION '145,3821' IMMEDIATE;

-- 세션 종료 후 OS 프로세스 확인 (Unix/Linux)
-- shadow 프로세스가 남아 있을 경우 OS 레벨에서 처리 필요
SELECT spid, pid, s.sid, s.serial#, s.username
FROM   v$process p
JOIN   v$session s ON p.addr = s.paddr
WHERE  s.sid = 145;
-- 이후 OS에서: kill -9 <spid>

예방 방법

1. 리소스 관리자(Database Resource Manager) 활용

Oracle Database Resource Manager를 사용하면 특정 사용자 그룹 또는 소비자 그룹에 대해 CPU, I/O, 병렬 쿼리 사용량을 제어하고, 실행 시간이 지나치게 긴 쿼리를 자동으로 종료하거나 하위 우선순위로 전환할 수 있습니다. 이를 통해 갑작스러운 장시간 쿼리로 인한 애플리케이션 타임아웃과 ORA-01013 에러를 사전에 예방할 수 있습니다.

-- Resource Manager Plan 생성 예시
BEGIN
    DBMS_RESOURCE_MANAGER.CREATE_PLAN(
        plan        => 'MIXED_WORKLOAD_PLAN',
        comment     => 'OLTP and Batch mixed workload plan'
    );

    DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
        plan                  => 'MIXED_WORKLOAD_PLAN',
        group_or_subplan      => 'OLTP_GROUP',
        comment               => 'OLTP sessions - high priority',
        mgmt_p1               => 80,
        switch_time           => 60,          -- 60초 초과 시 하위 그룹으로 전환
        switch_group          => 'LOW_GROUP'
    );
END;
/

2. 정기적인 SQL 모니터링 및 실행 계획 고정(SQL Plan Baseline)

신규 SQL이 배포될 때 실행 계획이 예상치 못하게 변경되어 갑작스럽게 성능이 저하되는 경우가 많습니다. SQL Plan Baseline(SPM)을 활용하여 검증된 실행 계획을 고정하고, AWR 또는 ASH 보고서를 주기적으로 분석하여 장시간 수행 SQL을 사전에 탐지하고 튜닝하는 습관을 가져야 합니다.

-- SQL Plan Baseline 캡처 및 고정
BEGIN
    DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE(
        sql_id          => 'abcde12345fgh',
        plan_hash_value => 1234567890
    );
END;
/

-- 등록된 SQL Plan Baseline 확인
SELECT sql_handle,
       plan_name,
       enabled,
       accepted,
       fixed,
       created
FROM   dba_sql_plan_baselines
WHERE  sql_text LIKE '%orders%'
ORDER BY created DESC;