「エラー対処」タグアーカイブ

Oracle「ORA-00060: デッドロックが検出されました」発生原因と解決策

2025年11月4日管理者コメントする

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

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

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

項目	内容
エラーコード	ORA-00060
意味	デッドロックが検出された
発生タイミング	ロック競合により処理が行き詰まった時
対応	片方のSQLを強制ロールバック、アプリ側は例外処理

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）

✅ まとめ

ポイント	内容
原因	トランザクション同士が相互待ち状態
検出後	Oracleが一方をロールバック
対策	ロック順序統一、リトライ処理、短いトランザクション
調査	トレースファイル + v$session等

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

Oracle, データベース, トラブル対応, ブログ

🧩 Oracle「ORA-01000: 最大オープン・カーソル数を超えました」対処手順

2025年10月12日管理者コメントする

🔍 エラー概要

項目	内容
エラーコード	ORA-01000
メッセージ	最大オープン・カーソル数を超えました
発生原因	開いたカーソルをクローズせずに処理を繰り返した結果、open_cursors の上限に達した
対応優先度	高（アプリケーション修正・設定見直しが必要）

🧠 原因と仕組み

Oracle では、SQL 実行時に「カーソル」という内部ハンドルを使用して SQL 文を管理します。
アプリケーションが PreparedStatement や ResultSet を閉じずに再利用し続けると、未解放のカーソルが蓄積し、open_cursors パラメータで設定された上限値を超えた時点で ORA-01000 が発生します。

🧩 よくある原因パターン

原因	詳細
JDBCのクローズ漏れ	ResultSet や Statement を close() していない
ループ内で毎回 SQL を prepare	PreparedStatement を都度生成して再利用していない
コネクションプールの設定ミス	コネクションが正しく解放されず、カーソルが残存
長時間実行バッチ	同一セッションで大量SQLを連続実行してカーソルが累積
外部ライブラリのバグ	ORM（MyBatis、Hibernate等）でのカーソル管理不具合

🧭 対処法（順序付き）

手順	対処内容
①	アプリケーションコードを点検（ResultSet, Statement, Connection を確実に close）
②	try-with-resources 構文を使用して自動クローズ化（Java7以降推奨）
③	open_cursors パラメータ値を確認（show parameter open_cursors;）
④	必要に応じて上限を引き上げ（例：ALTER SYSTEM SET open_cursors = 1000 SCOPE=BOTH;）
⑤	v$open_cursor ビューで調査（どのSQLが残っているか確認）

🔧 調査SQL例

-- 現在のopen_cursors設定値を確認
SHOW PARAMETER open_cursors;

-- 現在開いているカーソルの状況を確認
SELECT
    s.sid,
    s.serial#,
    a.value AS open_cursor_count,
    s.username,
    s.program
FROM v$sesstat a
JOIN v$statname b ON a.statistic# = b.statistic#
JOIN v$session s  ON s.sid = a.sid
WHERE b.name = 'opened cursors current'
ORDER BY a.value DESC;

-- どのSQLが開きっぱなしになっているかを確認
SELECT sid, sql_id, sql_text
FROM v$open_cursor
WHERE sid = <問題セッションSID>;

-- 現在のopen_cursors設定値を確認

SHOW PARAMETER open_cursors;

-- 現在開いているカーソルの状況を確認

SELECT

s.sid,

s.serial#,

a.value AS open_cursor_count,

s.username,

s.program

FROM v$sesstat a

JOIN v$statname b ON a.statistic# = b.statistic#

JOIN v$session s ON s.sid = a.sid

WHERE b.name = 'opened cursors current'

ORDER BY a.value DESC;

-- どのSQLが開きっぱなしになっているかを確認

SELECT sid, sql_id, sql_text

FROM v$open_cursor

WHERE sid = <問題セッションSID>;

💡 Javaでの修正例（try-with-resources構文）

String sql = "SELECT * FROM EMPLOYEES WHERE DEPT_ID = ?";
try (Connection conn = dataSource.getConnection();
     PreparedStatement ps = conn.prepareStatement(sql)) {
    ps.setInt(1, 10);
    try (ResultSet rs = ps.executeQuery()) {
        while (rs.next()) {
            System.out.println(rs.getString("EMP_NAME"));
        }
    }
} catch (SQLException e) {
    e.printStackTrace();
}

String sql = "SELECT * FROM EMPLOYEES WHERE DEPT_ID = ?";

try (Connection conn = dataSource.getConnection();

PreparedStatement ps = conn.prepareStatement(sql)) {

ps.setInt(1, 10);

try (ResultSet rs = ps.executeQuery()) {

while (rs.next()) {

System.out.println(rs.getString("EMP_NAME"));

}

} catch (SQLException e) {

e.printStackTrace();

}

✅ これにより、ResultSet・PreparedStatement・Connection が自動的にクローズされます。

⚙️ open_cursors の推奨設定値

システム規模	推奨値	備考
開発・検証環境	300〜500	検証負荷に応じて柔軟に設定
小〜中規模業務システム	500〜1000	通常アプリでは十分
大規模バッチ・Webサービス	1000〜2000	コネクションプール利用時に余裕をもたせる

🚨 注意点

open_cursors の値を単純に上げるだけでは根本解決になりません。
→ アプリケーションでのクローズ処理修正が最優先。
定期的に v$open_cursor を監視することで、リークを早期発見できます。

✅ まとめ

観点	内容
発生原因	カーソルの未クローズや過剰生成
一時対応	open_cursors の増加
根本対応	コード修正（try-with-resources等）
チェック方法	v$open_cursor / v$sesstat ビュー
再発防止	コーディング規約・静的解析の導入

AI, ChatGPT, その他, トラブル対応, ブログ

ChatGPTが動かない？過去の会話が再表示できないときのチェックポイントまとめ

2025年9月20日管理者コメントする

ChatGPTを使っていると、突然反応がなくなったり、過去の会話が再表示できなくなることがあります。
「自分の環境だけの不具合なのか」「サービス全体の障害なのか」気になる方も多いはず。

この記事では、ChatGPTが動かないときの原因・対処法・公式アナウンスの確認方法をまとめます。

よくある原因

1. セッション切れ

長時間操作しないとセッションが切れ、反応が止まることがあります。
一度ログアウトして再ログインすると改善する場合があります。

2. サーバ側の不安定さ

OpenAIのサーバーが混雑していると、一時的にレスポンスが返らないことがあります。
新機能リリース直後やアクセスが集中する時間帯に起こりやすいです。

3. ブラウザのキャッシュやCookieの問題

キャッシュやCookieが壊れていると、過去チャットが読み込めないことがあります。
ブラウザのキャッシュクリアやCookie削除で解決することがあります。

4. アプリやブラウザ固有の不具合

Web版は不安定でも、モバイルアプリ版では正常動作することがあります。
逆にアプリで不具合が出てもブラウザでは動く場合もあるため、両方試すのがおすすめです。

すぐに試せる対処法

ページを再読み込みする（F5 / Ctrl+R）
ログアウト → 再ログイン
別のブラウザやアプリで開く
ブラウザのキャッシュ・Cookieを削除する
時間を置いて再度アクセスしてみる

公式の障害アナウンス確認先

ChatGPTが全体的に不調なのか、自分の環境だけの問題なのかを確認するには、以下の情報源が役立ちます。

OpenAI Statusページ
https://status.openai.com/
- サービス全体の稼働状況がリアルタイムで更新されます。
- 「障害発生」や「性能低下」が表示されていれば全体的な問題です。
OpenAI公式X（旧Twitter）
@OpenAI
- 大規模障害や世界的な影響がある不具合はここで告知されることがあります。
ChatGPTの画面内お知らせ
- 重大障害の場合は、画面上部に黄色や赤い帯で通知が出ることもあります。

過去チャットが再表示できないときのポイント

多くの場合「履歴が消えたわけではなく、一時的に表示できないだけ」です。
履歴一覧から直接クリックしたり、別ブラウザでアクセスすると復活するケースがあります。

まとめ

ChatGPTが動かない・過去の会話が再表示できないときは、

セッション切れやキャッシュ破損など自分の環境を確認
公式のステータスページやSNSで障害情報を確認
別のブラウザやアプリでも試してみる

この流れで原因を切り分けるのがおすすめです。

特に status.openai.com をブックマークしておくと、すぐに障害状況をチェックできるので便利です。

Oracle, SQL, データベース, トラブル対応, ブログ

Oracle：ユーザー作成時に「ORA-65096」エラーが出た場合の原因と対応方法

2022年6月25日管理者コメントする

Oracleのインストール後にSQL*Plusなどでユーザー作成しようとした際、「ORA-65096」エラーが発生した場合の原因と対応方法についてメモしておきます。

「ORA-65096：共通ユーザーまたはロール名が無効です」の原因

ルートコンテナにローカルユーザーを作成しようとした場合に発生するエラーとなります。
ルートコンテナには共有ユーザー(common user) と呼ばれる特殊なユーザーしか作成することはできません。
Oracle 11gまでと違いOracle 12c以降からは一つのインスタンスには一つのコンテナ・データベース(CDB)と、プラガブル・データベース(PDB)と呼ばれる子DBが存在しています。sysなどのユーザーでログイン直後はコンテナ・データベース(CDB)に接続されている状態となっているため、そのままローカルユーザーを作成しようとしてもエラーが発生してしまうということになります。

「ORA-65096：共通ユーザーまたはロール名が無効です」の対処方法

原因が分かってしまえば対応はシンプルです。接続先がコンテナ・データベース(CDB)であるのがまずいのであればプラガブル・データベース(PDB)に変更してしまえばいいだけです。

まずは「show con_name;」で現在接続されているデータベースを確認します。
次に「select name, open_mode from v$pdbs;」でPDBの名前と現在のOPEN_MODEを確認します。
PDBの名前が「ORCLPDB」というのがわかったのでデータベースの接続先を「ORCLPDB」へ変更します。
もう一度「show con_name;」を実行して接続先が変更されていることを確認します。
接続先がPDBへ変更されたのでもう一度ユーザー作成を実行すると正常に実行されます。

🔍補足：ORA-65096エラーの仕組みと注意点

ORA-65096: invalid common user or role name は、マルチテナント構成の Oracle Database（12c以降） において、
ルートコンテナ（CDB$ROOT）上でローカルユーザーを作成しようとした場合に発生するエラーです。
以下のポイントを押さえておくと、再発を防ぎやすくなります。

観点	内容
エラーの本質	共通ユーザーとローカルユーザーの区別を誤ったことによる構文エラー
共通ユーザー名の規則	`C##` または `c##` のプレフィックスが必須（`COMMON_USER_PREFIX`パラメータで変更可）
発生条件	`CDB$ROOT` に接続したままユーザーを作成／命名規則を満たさない場合
解決策	`ALTER SESSION SET CONTAINER = <PDB名>` でPDBに切り替えてから `CREATE USER` を実行する
参考	`SHOW CON_NAME;` で現在の接続先（コンテナ）を確認可能

✅ 具体例：安全なユーザー作成手順

-- 現在のコンテナを確認
SHOW CON_NAME;

-- PDBに切り替え
ALTER SESSION SET CONTAINER = ORCLPDB;

-- PDB内でユーザー作成
CREATE USER myuser IDENTIFIED BY mypassword;
GRANT CONNECT, RESOURCE TO myuser;

-- 現在のコンテナを確認

SHOW CON_NAME;

-- PDBに切り替え

ALTER SESSION SET CONTAINER = ORCLPDB;

-- PDB内でユーザー作成

CREATE USER myuser IDENTIFIED BY mypassword;

GRANT CONNECT, RESOURCE TO myuser;

もしルートコンテナ側で共通ユーザーを作成したい場合は、以下のようにします。

💡補足メモ

SHOW PDBS; で現在のPDB一覧を確認可能。OPEN_MODE が READ WRITE でなければユーザー作成はできません。
バージョン19c以降では、CDB構成がデフォルトのため、PDB接続の意識が必須 です。
TNS接続文字列（SERVICE_NAME）が CDB を指していると、意図せずルート側に接続してしまうことがあります。

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

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

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

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

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

✅ 再現例（簡易デモ）

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

トレースファイル例

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

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

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

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

✅ 4. 排他制御の明確化

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

✅ まとめ

関連記事

🔍 エラー概要

🧠 原因と仕組み

🧩 よくある原因パターン

🧭 対処法（順序付き）

🔧 調査SQL例

💡 Javaでの修正例（try-with-resources構文）

⚙️ open_cursors の推奨設定値

🚨 注意点

✅ まとめ

関連記事

よくある原因

1. セッション切れ

2. サーバ側の不安定さ

3. ブラウザのキャッシュやCookieの問題

4. アプリやブラウザ固有の不具合

すぐに試せる対処法

公式の障害アナウンス確認先

過去チャットが再表示できないときのポイント

まとめ

関連記事

「ORA-65096：共通ユーザーまたはロール名が無効です」の原因

「ORA-65096：共通ユーザーまたはロール名が無効です」の対処方法

🔍補足：ORA-65096エラーの仕組みと注意点

✅ 具体例：安全なユーザー作成手順

💡補足メモ

関連記事

「駑馬十駕」を信念に IT系情報を中心に調べた事をコツコツ綴っています。

　関連記事

　関連記事

　関連記事

　関連記事