ORA-01013（user requested cancel of current operation） は、
OracleでSQL実行中に処理が強制的に中断された場合に発生するエラーです。
エラーメッセージだけ見ると「ユーザーがキャンセルした」と書かれているため、
本当にユーザー操作なのか？アプリ側なのか？タイムアウトなのか？
原因切り分けで迷うケースが非常に多いエラーの一つです。
この記事では、実務でよく遭遇する原因から、確実に再発防止するための対処法までをわかりやすくまとめます。
ORA-01013とは何か？
Oracleの公式エラーメッセージは以下の通りです。
直訳すると「ユーザーが現在の処理をキャンセルした」という意味ですが、
実際にはユーザー自身がキャンセル操作をしていない場合も多く、
アプリケーションのタイムアウトやセッション切断などでも発生します。
✔ よくある原因まとめ（実務で多い順）
1. アプリケーション側のタイムアウト（最も多い）
-
Webアプリ・バッチ・APIがタイムアウトを設定しており、SQLが完了前に切られる
-
Javaなら JDBCのQueryTimeout、Webアプリなら APサーバのタイムアウト
-
接続プール（HikariCP / UCP など）のタイムアウト設定
→ アプリが先に処理を中断 → Oracle側がORA-01013を返す
2. ツール側操作による中断（DBeaver / SQL Developer など）
-
ユーザーが「停止」ボタンを押す
-
SQLの実行画面を閉じる
-
ツール側で内部的にキャンセルが走る場合もある
3. ネットワーク切断・セッション切れ
-
VPNの瞬断
-
APサーバ〜DB間のコネクションが短時間切断
-
F/W・LB のアイドルタイムアウト
→ セッションが切れる → Oracleがユーザーキャンセル扱いになる
4. プロファイルでのリソース制限（CPU_PER_CALLなど）
DB側のプロファイル設定で
-
CPU時間の上限(CPU_PER_CALL)
-
IDLE_TIME（アイドル時間）
などが上限を超えると、Oracleがセッションを終了しORA-01013となる場合があります。
5. 長時間処理の実行中にバッチが落ちた・APが強制終了した
アプリ側が異常終了することで、結果的にキャンセルが発生します。
✔ 原因別の対処法まとめ
▼ 1. アプリ側タイムアウトが原因の場合
アプリ設定を確認します。
Java（JDBC）の例：
HikariCP:
対処ポイント
-
タイムアウト値を適切に引き上げる
-
重いSQLを見直す（インデックス・実行計画）
-
バッチ処理なら分割実行を検討
▼ 2. SQLツールが原因の場合
-
停止ボタンを誤って押してないか
-
大量データを返すクエリを実行してないか
-
ツールのメモリ不足・内部エラーを疑う
DBeaverの設定でフェッチ行数制限を緩和すると改善されることもあります。
▼ 3. ネットワーク切断が原因の場合
-
APサーバとDBの間にVPNやFWが挟まっていないか
-
アイデルタイムアウト設定の見直し
-
回線品質のログを確認（Ping監視など）
ネットワークの瞬断は意外と多く、企業ネットワークだと特に発生しやすいポイントです。
▼ 4. プロファイル（リソース制限）が原因の場合
以下のプロファイルを確認します。
制限が厳しすぎる場合は緩和します。
▼ 5. 長時間SQLが原因の場合（インデックス・実行計画の見直し）
-
インデックス劣化
-
統計情報の古さ
-
不必要な全表走査
-
JOIN順序
SQLが遅すぎてアプリタイムアウト → ORA-01013 に繋がる典型パターンです。
✔ 再発を確実に防ぐためのチェックリスト
-
アプリのタイムアウト設定は妥当か？
-
ネットワークに瞬断がないか？
-
バッチ・ETL処理が重すぎないか？
-
実行計画を確認したか？索引は効いているか？
-
プロファイル制限が厳しすぎないか？
-
SQLツールの操作ミスはないか？
まとめ
ORA-01013は「ユーザーがキャンセルした」だけではなく、
アプリ側のタイムアウトやネットワークの瞬断など、多くの原因で発生します。
特に実務では
① SQLが重すぎてアプリ側タイムアウト → ORA-01013
というパターンが多いため、
SQL改善＋アプリ設定の見直しが最も効果的です。