🔍 ORA-01722とは？

Oracleで次のようなエラーが発生した経験はありませんか？

このエラーは日本語では「無効な数値」という意味で、数値型に変換できない文字列を数値として扱おうとしたときに発生します。
Oracle初心者だけでなく、業務システム開発やデータ移行でも頻繁に遭遇する定番エラーのひとつです。

💡 エラーの主な原因

ORA-01722が発生する代表的なパターンを3つに整理します。

① 数値型カラムに文字列データをINSERT

② 文字列を数値比較している

Oracleは自動的に型変換（暗黙変換）を試みますが、変換不可能な文字が含まれているとエラーになります。

③ TO_NUMBERで変換できない文字列を指定

⚙️ 対処法・修正ポイント

✅ 1. カラムのデータ型を確認する

対象カラムがNUMBERかVARCHAR2かを事前にチェックしましょう。

型の不一致があれば、INSERT/UPDATE側を修正するか、変換処理を明示的に記述します。

✅ 2. 明示的な変換を行う（TO_NUMBER / TO_CHAR）

暗黙変換に頼らず、意図的に変換処理を書くのが安全です。

または

ただし、TO_NUMBERに文字列が含まれる場合はNULLまたはエラーになるため、CASE式やREGEXP_LIKEで検査してから変換するのがおすすめです。

✅ 3. WHERE句の条件順序に注意

Oracleでは、WHERE句の評価順序によってエラーが出るか出ないかが変わることがあります。

🧪 実務でよくあるケース

🧰 エラー行を特定するテクニック

大量データのINSERTやUPDATEでORA-01722が出ると、どの行が原因か分からないことが多いです。
そんなときは以下のように確認します。

このSQLで、数値以外の文字を含む行を特定できます。
特にCSVや外部システム連携時には有効です。

🧩 まとめ

• ORA-01722は「文字列を数値に変換できない」時に発生するエラー

• 暗黙変換を避け、明示的なTO_NUMBER／TO_CHARを使用するのが安全

• REGEXP_LIKEで事前にデータ検証することでエラーを未然に防げる

🧩 ORA-02049とは

ORA-02049: timeout: distributed transaction waiting for lock は、Oracleデータベースの分散トランザクション（Distributed Transaction）で、ロック待ち状態が一定時間続いた結果、タイムアウトが発生したことを示すエラーです。
通常のローカルトランザクションではなく、DBリンクを跨いだ処理を行っている際に発生する点が特徴です。

🔍 主な発生原因

このエラーの原因は大きく分けて以下の3つです。

① 他セッションがロックを保持している

別のトランザクションがまだコミットまたはロールバックされておらず、対象の行・表をロック中。
そのため、他ノードや他セッションからの更新がブロックされ、一定時間後にタイムアウトします。

② 分散トランザクション中のロック競合

UPDATE table@remote_db ... のように DBリンクを通じてリモートDBを更新 している場合、リモート側でロックが競合すると、ローカル側から見ると「ロック待ち」となり、このエラーが発生します。

③ タイムアウト値が短すぎる

システムパラメータ DISTRIBUTED_LOCK_TIMEOUT の値が短く設定されていると、ロック解放前にタイムアウトしてしまうことがあります。
デフォルトは 60秒 です。

⚙️ ロック状況の確認方法

発生原因を特定するには、まずどのセッションがロックを保持しているかを確認します。

ロックを保持しているセッションが特定できたら、以下のように解放することも可能です。

※運用環境では慎重に実施してください。未コミットデータが失われる可能性があります。

⏱️ タイムアウト設定の調整

ロックが頻繁に発生する分散環境では、待機時間を長めに設定することで回避できる場合があります。

この例では、待機時間を 300秒（5分） に延長しています。

💡 類似エラーとの違い

ORA-02049 は デッドロックではなく、単純なロック待ちタイムアウト である点に注意してください。

✅ まとめ

ORA-00060: deadlock detected while waiting for resource は、Oracleデータベースが相互にロックし合う処理を検出し、処理を強制終了した際に発生するエラーです。トランザクション同士が互いに待ち状態に陥る**デッドロック（Deadlock）**が原因です。

本記事では、ORA-00060 の発生条件、よくある原因、デバッグ方法、実践的な対処策を詳しく解説します。

✅ ORA-00060とは？エラー概要

Oracleはデッドロックを検知すると一方のトランザクションを自動的にロールバックし、システム全体の停止を防ぎます。

✅ デッドロックが起こる典型例

パターン1：同じテーブルの行を別順にロック

片方が row1、もう片方が row2 を先にロックし、互いに次のリソースを待つ状態になる例です。

パターン2：未コミットの長時間処理

• 更新処理をコミットせず放置

• バッチ処理中に他の処理が割り込む

パターン3：アプリ側でロック順序の不一致

• 更新対象リストをソートせず更新

• 並列処理スレッドで異なる順番で更新

✅ 再現例（簡易デモ）

セッションA

セッションB

この状態でお互いのロックを待ち合うとデッドロック発生。

✅ デッドロック解析：trace file の場所と見方

Oracleはデッドロック検出時にアラートログとトレースファイルを出力します。

トレースファイル例

パス例：

内容には以下が記録：

• SQL文

• セッション情報

• ロック対象オブジェクト

• 相手セッション情報

デバッグポイント：

• 同じ行/テーブルを複数処理が更新していないか

• 並列バッチやトランザクション処理の順序

✅ 対策：アプリ側 & DB側のアプローチ

✅ 1. ロック順序を統一する（最重要）

複数行更新する場合はIDソートして更新するなど、順序を固定。

✅ 2. こまめに COMMIT / ロック保持時間を短縮

• 不要なトランザクションを開きっぱなしにしない

• 大量更新は小分け

✅ 3. 再試行ロジック（リトライ処理）

アプリ側で例外時にリトライする仕組み

✅ 4. 排他制御の明確化

• SELECT … FOR UPDATE の利用

• アプリの排他設計見直し

✅ 5. 監視・ログ出力の強化

• SQLログ

• ロック監視ビュー（v$lock,v$session,v$transaction）

✅ まとめ

デッドロックはアプリ設計と運用改善で防げます。
DBの問題と思われがちですが、多くはアプリ側のトランザクション管理が原因です。