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

ORA-12638：資格証明の取出しに失敗しました。が起きる時の対処方法

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

Oracle接続時に発生するエラー 「ORA-12638：資格証明の取出しに失敗しました。」 は、
クライアント側の認証設定が原因で SQL*Plus やアプリケーション接続ができなくなるケースに多く見られます。
特に Windows環境で Oracle Client を利用している場合や、VPN経由の接続 で発生しやすいトラブルです。

本記事では、このエラーの原因と対処方法をわかりやすく整理します。

🔍 エラー内容

英語メッセージとしては以下です。

📌 原因の概要

主な原因として以下が考えられます。

原因	具体例
sqlnet.ora の認証設定が適合していない	SQLNET.AUTHENTICATION_SERVICES = (NTS) が原因
OS での NTS 認証（Windowsログオン）が利用できない状態	ドメイン外、VPN経由、ローカルアカウント使用
Oracle Client と Server の認証方式の不一致	NTS / TCPS / Kerberos
Oracle のネットワーク設定が壊れている	インストール不完全、dllロード失敗
パスワードファイルやWalletが関連するケース	外部認証・Wallet参照失敗

🛠️ 対処方法

① `sqlnet.ora` を編集し NTS を無効化する

最も一般的な解決手段です。

例：変更前

例：変更後

▼ 設定ファイルの場所（Oracle Client側）

設定変更後、接続をやり直します。

② VPN接続やネットワーク制限を確認する

以下に該当する場合、NTS認証が失敗することがあります。

会社ドメイン外からVPNで接続している
別セグメントのネットワークへ接続している
OSユーザーがローカルアカウント

VPN中だけ発生する場合は、ほぼ①の設定変更で解決します。

③ Oracle Client を再インストール / 別バージョンでテスト

インストール破損やバージョン相性で発生することもあるため、次の対処が有効です。

Instant Client に変更
同一バージョンでもクリーン再インストール
32bit / 64bit mismatch の解消

④ Wallet / TCPS を利用する環境の場合

Wallet使用環境であれば、以下も確認します。

Walletパス設定の誤り
ファイルアクセス権限
Listenerが TCPS 対応で起動しているか

🧪 チェックリストまとめ

チェック項目	対応
sqlnet.ora の認証設定確認	(NTS) → (NONE) へ変更
VPN/ネットワーク制限	VPN環境でのみ発生していないか
Oracle Client 再インストール	Instant Clientで接続確認
Wallet使用時	パスと権限

📦 再発防止のポイント

sqlnet.ora をプロジェクト共有設定として管理する
VPN利用者は (NONE) 設定を基本にする
クライアントとサーバのバージョン整合性を確保
企業ネットワーク設定変更後は接続検証を行う

✨ まとめ

ORA-12638 は多くの場合、認証方式（NTS）の不一致が原因です。
まずは sqlnet.ora の設定変更で改善するケースがほとんどです。

特に以下の変更が最も効果的です：

VPN経由環境や Windows クライアントで発生するトラブルとして覚えておくと便利です。

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

【Oracle】ORA-03113：通信チャネルEOFエラーの原因と解決手順をわかりやすく解説

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

■ ORA-03113とは？

ORA-03113: end-of-file on communication channel は、
Oracle クライアントとサーバ間の通信が異常終了したとき に表示される代表的なエラーです。

平たく言うと、

「通信中にいきなり回線が切れた / Oracle が応答しなくなった」
という状態。

接続断・セッション強制終了など、原因は幅広いため、
切り分けのポイントが非常に重要なエラーとなります。

■ ORA-03113 が発生する主な原因

1. Oracle インスタンスがクラッシュ / 強制停止した

もっとも多い原因です。

インスタンスが落ちた
PMON による強制終了
ORA-600 / ORA-7445 など内部エラーと連動
OS側のメモリ不足・カーネル不具合

▼確認ポイント

alert.log に異常が出ていないか
ORA-600 / ORA-7445 が直前に出ていないか
インスタンスが restart されていないか

2. ネットワークの不安定化・切断

クライアントと DB サーバの間のネットワークが瞬断すると発生。

VPN が切れた
ファイアウォールのタイムアウト
回線の瞬断／通信遅延
パケットロス

▼確認ポイント

サーバとの ping 値・遅延
FW・LB のセッションタイムアウト
SSH が同時に切れないか
スイッチ再起動などのネットワークイベント有無

3. タイムアウト設定（SQLNET.ORA / Firewall）の影響

長時間 SQL を実行するバッチで頻発する原因。

SQLNET.EXPIRE_TIME の影響
Firewall / Router のアイドルタイムアウト
Application Server のコネクションプール強制切断

▼対策例

SQLNET.EXPIRE_TIME = 10

1	SQLNET.EXPIRE_TIME = 10

（10分に1回 keepalive を送る設定）

4. クライアントアプリ側の異常終了

Java / Python / C++ などクライアントが強制終了
JDBC / ODP.NET の古いドライバ
途中でプロセスが kill される

▼確認ポイント

クライアントログにエラーがないか
ドライババージョン
JVM の GC が暴走していないか

5. SQL の実行中にサーバリソースが枯渇

大きなバッチ処理中に発生するケース。

PGA/UGA 枯渇
CPU / メモリ枯渇
TEMP 使用量が100%
I/O 遅延

▼確認ポイント

AWR / Statspack の負荷
v$session_wait の値
TEMP の使用量

■ ORA-03113 が出たときの切り分け手順（最速版）

迷ったら まずは Oracle サーバ側のログを先に確認 が鉄則！

【1】alert.log を確認

最初に必ず見る場所。

例：

何かしら痕跡が残っていることが多い。

【2】trace ファイル（*.trc）を確認する

内部エラーの場合はこちらに詳細。

スタックトレース
直前の SQL
ユーザセッション情報

【3】ネットワーク切断の有無を確認

FW のログ
ping のロス率
VPN 稼働状況
SSID や Wi-Fi の不安定性も対象

【4】同時刻に OS イベントが発生していないか

メモリ OOM
ディスクフル
OS 再起動
Kernel Panic

【5】クライアント側のログ確認（アプリ含む）

JVM ログ
アプリログ
ODP.NET / JDBC のエラー

■ よくあるパターン別の対策

● ケース1：長時間SQLで毎回切断される

これは Firewall / LB タイムアウトが犯人 の場合が多い。

▼対処

DBA：SQLNET.EXPIRE_TIME を設定
ネットワーク：タイムアウト延長
アプリ：コネクションプールの keepalive 有効化

● ケース2：大量データ処理バッチで発生

▼対処

TEMP 表領域増設
PGA を増やす
インデックス追加など SQL チューニング

● ケース3：インスタンスが落ちた

▼対処

alert.log の内部エラーを修正
パッチ適用
メモリ/OS リソースの見直し
Oracle Support に SR 起票

■ まとめ（結論）

ORA-03113 は 「通信が突然切れた」ことを示す汎用エラー で、
原因は広いですが、必ず次のどれかに分類できます。

Oracle インスタンスの異常
ネットワークの遮断
タイムアウト設定の問題
クライアントの異常終了
サーバリソース不足

迷ったら alert.log → ネットワーク → クライアント の順に切り分ければ最短で原因にたどり着けます。

PowerShell, トラブル対応, ブログ, プログラミング

PowerShellの構文エラー原因TOP3：全角引用符・NBSP・BOM

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

🧩 PowerShellの構文エラー原因TOP3：全角引用符・NBSP・BOM

PowerShellスクリプトを実行したときに、
「UnexpectedToken」や「文字列に終端記号がありません」という赤エラーが出て動かない——。
そんな経験はありませんか？

実はこれらの構文エラー、文法ミスではなく「文字の種類」 が原因で起きていることが非常に多いです。
特に日本語環境では、以下の3つがPowerShellを混乱させる典型的なトラブル要因です。

🥇 第1位：全角引用符（“ ”、” ”）

最も多いのがこれ。
WordやWebサイト、ブログなどからコードをコピーした際に、
「普通のダブルクォート（"）」が「全角のスマートクォート（“ や ”）」に変わってしまう現象です。

PowerShellはこれを文字列の区切りとして認識できません。
そのため以下のようなエラーが出ます。

🔧 対処法：

全角の “ ” を半角の ” ” に置換
コードエディタで「スマートクォート自動変換」をOFFにする

🥈 第2位：NBSP（ノーブレークスペース）

見た目は半角スペースですが、内部的には U+00A0 という別の文字です。
HTMLページやブログからコピーしたときに非常によく混入します。

PowerShell上では、
「半角スペースとして解釈されない」ため構文が崩れ、
UnexpectedToken などの不可解なエラーが出ます。

🔧 対処法：

サクラエディタやVS Codeで「不可視文字表示」をONにする
以下のコマンドでNBSPやゼロ幅文字を除去可能：

PowerShell

(Get-Content .\script.ps1 -Raw) ` -replace '[\u00A0\u200B-\u200D]', ' ' ` | Set-Content .\script.ps1 -Encoding UTF8

1
2
3

(Get-Content .\script.ps1 -Raw) `
-replace '[\u00A0\u200B-\u200D]', ' ' `
| Set-Content .\script.ps1 -Encoding UTF8

🥉 第3位：BOM付きUTF-8で保存されている

UTF-8自体はPowerShellでも推奨されていますが、
「BOM（Byte Order Mark）」付きUTF-8 で保存された .ps1 は
スクリプトの先頭に見えない U+FEFF が混入し、これが原因で構文エラーになる場合があります。

🔧 対処法：

ファイルを UTF-8（BOMなし） で保存
サクラエディタやVS Codeで「保存形式：UTF-8（BOMなし）」を明示的に選択

✅ エラーを防ぐためのおすすめ設定

PowerShellのスクリプトを書くときは、以下の設定を徹底すると安心です。

🧰 トラブルを一掃するワンライナー

既におかしな文字が混入している場合は、
次のPowerShellコマンドでクリーンアップできます。

これで、全角クォート・NBSP・BOMをすべて除去できます。

🚀 まとめ

PowerShellの構文エラーの多くは「コードが壊れている」のではなく、
文字の種類が混ざっているだけ です。

“全角クォート” → 半角 " " に直す
“NBSP” → 普通のスペースに置換
“BOM付きUTF-8” → BOMなしに保存

この3点を意識するだけで、
もう意味不明な赤いエラーに悩まされることはありません。

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

Oracle「ORA-02049: timeout: distributed transaction waiting for lock」エラーの原因と解決策まとめ

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

🧩 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秒 です。

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

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

-- ロックを保持しているオブジェクトを確認
SELECT * FROM v$locked_object;

-- ロック中セッションの詳細を確認
SELECT s.sid, s.serial#, s.username, s.program
FROM v$session s
WHERE s.sid IN (SELECT session_id FROM v$locked_object);

-- ロックを保持しているオブジェクトを確認

SELECT * FROM v$locked_object;

-- ロック中セッションの詳細を確認

SELECT s.sid, s.serial#, s.username, s.program

FROM v$session s

WHERE s.sid IN (SELECT session_id FROM v$locked_object);

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

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

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

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

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

💡 類似エラーとの違い

エラーコード	内容	特徴
ORA-00060	デッドロックが検出された	両者が互いに待機し合う状態
ORA-02049	分散トランザクションのロック待ちタイムアウト	リモートDBを跨ぐ処理で発生

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

✅ まとめ

項目	内容
エラー番号	ORA-02049
メッセージ	timeout: distributed transaction waiting for lock
主な原因	分散トランザクション中のロック待ち
対応策	ロック保持セッションの確認・解放、タイムアウト値調整
推奨設定	DISTRIBUTED_LOCK_TIMEOUT = 300（状況に応じて）

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

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

🔍 エラー内容

📌 原因の概要

🛠️ 対処方法

① sqlnet.ora を編集し NTS を無効化する

例：変更前

例：変更後

▼ 設定ファイルの場所（Oracle Client側）

② VPN接続やネットワーク制限を確認する

③ Oracle Client を再インストール / 別バージョンでテスト

④ Wallet / TCPS を利用する環境の場合

🧪 チェックリストまとめ

📦 再発防止のポイント

✨ まとめ

関連記事

■ ORA-03113とは？

■ ORA-03113 が発生する主な原因

1. Oracle インスタンスがクラッシュ / 強制停止した

▼確認ポイント

2. ネットワークの不安定化・切断

▼確認ポイント

3. タイムアウト設定（SQLNET.ORA / Firewall）の影響

▼対策例

4. クライアントアプリ側の異常終了

▼確認ポイント

5. SQL の実行中にサーバリソースが枯渇

▼確認ポイント

■ ORA-03113 が出たときの切り分け手順（最速版）

【1】alert.log を確認

【2】trace ファイル（*.trc）を確認する

【3】ネットワーク切断の有無を確認

【4】同時刻に OS イベントが発生していないか

【5】クライアント側のログ確認（アプリ含む）

■ よくあるパターン別の対策

● ケース1：長時間SQLで毎回切断される

▼対処

● ケース2：大量データ処理バッチで発生

▼対処

● ケース3：インスタンスが落ちた

▼対処

■ まとめ（結論）

関連記事

🧩 PowerShellの構文エラー原因TOP3：全角引用符・NBSP・BOM

🥇 第1位：全角引用符（“ ”、” ”）

🔧 対処法：

🥈 第2位：NBSP（ノーブレークスペース）

🔧 対処法：

🥉 第3位：BOM付きUTF-8で保存されている

🔧 対処法：

✅ エラーを防ぐためのおすすめ設定

🧰 トラブルを一掃するワンライナー

🚀 まとめ

関連記事

🧩 ORA-02049とは

🔍 主な発生原因

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

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

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

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

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

💡 類似エラーとの違い

✅ まとめ

関連記事

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

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

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

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

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

✅ 再現例（簡易デモ）

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

トレースファイル例

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

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

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

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

✅ 4. 排他制御の明確化

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

✅ まとめ

関連記事

🔍 エラー概要

🧠 原因と仕組み

① `sqlnet.ora` を編集し NTS を無効化する

　関連記事

　関連記事

　関連記事

　関連記事

　関連記事

　関連記事

　関連記事

　関連記事