「Oracle」タグアーカイブ

SQL, ブログ

Oracleで文字列操作を極める：SUBSTR・INSTR・REPLACEの活用術

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

Oracle SQLで文字列を自在に扱えるようになると、データ抽出や整形が格段に効率化します。
本記事では、文字列操作の3大関数「SUBSTR」「INSTR」「REPLACE」の使い方をわかりやすく解説します。

1️⃣ SUBSTR：文字列の一部を取り出す

SUBSTRは指定した位置から任意の長さの文字列を切り出す関数です。

🔸 使用例

結果：

📘 ポイント

開始位置は 1から数える
第3引数（文字数）を省略すると、開始位置以降をすべて取得
負の値を指定すると末尾からカウントされる

→ 結果：EF

2️⃣ INSTR：文字列の位置を検索する

INSTRは、指定した文字が出現する**位置（インデックス）**を返します。

🔸 使用例

結果：

→ 2つ目のカンマ「,」が4文字目にあることを示します。

📘 応用テクニック

INSTRとSUBSTRを組み合わせることで、区切り文字を含む文字列から特定部分を抜き出すことが可能です。

-- カンマ区切りの2番目の要素を取得
SELECT SUBSTR('A,B,C,D',
              INSTR('A,B,C,D', ',', 1, 1) + 1,
              INSTR('A,B,C,D', ',', 1, 2) - INSTR('A,B,C,D', ',', 1, 1) - 1)
FROM DUAL;

-- カンマ区切りの2番目の要素を取得

SELECT SUBSTR('A,B,C,D',

INSTR('A,B,C,D', ',', 1, 1) + 1,

INSTR('A,B,C,D', ',', 1, 2) - INSTR('A,B,C,D', ',', 1, 1) - 1)

FROM DUAL;

結果：

3️⃣ REPLACE：文字列の置換を行う

REPLACEは、指定した文字列を別の文字列に置き換える関数です。

🔸 使用例

結果：

📘 応用テクニック

REPLACEを使えば、不要な文字の削除も簡単に行えます。

結果：

4️⃣ 組み合わせテクニック：実用的な例

💡 メールドメインを抽出する例

SELECT SUBSTR(EMAIL, INSTR(EMAIL, '@') + 1) AS DOMAIN
FROM USERS;

1 2	SELECT SUBSTR(EMAIL, INSTR(EMAIL, '@') + 1) AS DOMAIN FROM USERS;

結果例：

EMAIL	DOMAIN
user@example.com	example.com

💡 ファイル名から拡張子を削除

結果例：

FILE_NAME	BASE_NAME
report.xlsx	report

5️⃣ まとめ

関数	用途	主な特徴
SUBSTR	部分文字列の取得	開始位置・文字数指定が可能
INSTR	指定文字の位置取得	出現回数も指定可能
REPLACE	文字列の置換	不要文字の削除にも利用可能

これらを組み合わせることで、Oracle SQLでの文字列処理は自由自在になります。
ログ解析、ファイル名分割、メールドメイン抽出など、日常的な業務で大活躍する関数です。

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

ORA-01722エラーが出たら？無効な数値エラーの原因と直し方

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

🔍 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句の評価順序によってエラーが出るか出ないかが変わることがあります。

-- NG例
SELECT * FROM sales WHERE TO_NUMBER(price_text) > 1000;

-- OK例（数値文字列だけ抽出）
SELECT * FROM sales
 WHERE REGEXP_LIKE(price_text, '^[0-9]+$')
   AND TO_NUMBER(price_text) > 1000;

-- NG例

SELECT * FROM sales WHERE TO_NUMBER(price_text) > 1000;

-- OK例（数値文字列だけ抽出）

SELECT * FROM sales

WHERE REGEXP_LIKE(price_text, '^[0-9]+$')

AND TO_NUMBER(price_text) > 1000;

🧪 実務でよくあるケース

状況	原因	対策
CSVインポートでORA-01722	数値列に「-」や空白文字が混入	データクレンジング処理を追加
JOIN条件で発生	両テーブルの型が不一致	CASTで明示的に変換
CASE式で一部の条件だけ文字列	条件式の型が揃っていない	TO_CHARまたはTO_NUMBERで統一

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

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

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

🧩 まとめ

ORA-01722は「文字列を数値に変換できない」時に発生するエラー
暗黙変換を避け、明示的なTO_NUMBER／TO_CHARを使用するのが安全
REGEXP_LIKEで事前にデータ検証することでエラーを未然に防げる

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（状況に応じて）

SQL, ブログ

サブクエリを使ったUPDATE文：別テーブルの値で更新する方法

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

■ 概要

SQLでデータを更新する際、別のテーブルの値を参照してUPDATEしたい場面は多くあります。
たとえば、マスタテーブルの最新情報でトランザクションテーブルを更新するケースなどです。

この記事では、Oracleデータベースを例に、サブクエリを使ったUPDATE文の書き方をわかりやすく解説します。

■ 基本構文

Oracleでサブクエリを用いたUPDATEを行う場合、基本的な構文は次の通りです。

UPDATE 更新対象テーブル A
   SET A.更新カラム = (
         SELECT B.参照カラム
           FROM 参照テーブル B
          WHERE B.条件カラム = A.条件カラム
       )
 WHERE EXISTS (
         SELECT 1
           FROM 参照テーブル B
          WHERE B.条件カラム = A.条件カラム
       );

UPDATE 更新対象テーブル A

SET A.更新カラム = (

SELECT B.参照カラム

FROM 参照テーブル B

WHERE B.条件カラム = A.条件カラム

)

WHERE EXISTS (

SELECT 1

FROM 参照テーブル B

WHERE B.条件カラム = A.条件カラム

);

ここで重要なのは、
SET句の中でサブクエリを使って値を取得し、
WHERE EXISTSで更新対象を限定する点です。

■ 実際の例：商品価格マスタをもとに在庫テーブルを更新

【例題】

PRODUCT_MASTER（商品マスタ）テーブル：
- PRODUCT_ID
- PRICE（最新の価格）
STOCK_INFO（在庫情報）テーブル：
- PRODUCT_ID
- PRICE（販売価格を更新したい）

【目的】

マスタの最新価格を在庫情報に反映する。

【SQL例】

UPDATE STOCK_INFO S
   SET S.PRICE = (
         SELECT M.PRICE
           FROM PRODUCT_MASTER M
          WHERE M.PRODUCT_ID = S.PRODUCT_ID
       )
 WHERE EXISTS (
         SELECT 1
           FROM PRODUCT_MASTER M
          WHERE M.PRODUCT_ID = S.PRODUCT_ID
       );

UPDATE STOCK_INFO S

SET S.PRICE = (

SELECT M.PRICE

FROM PRODUCT_MASTER M

WHERE M.PRODUCT_ID = S.PRODUCT_ID

)

WHERE EXISTS (

SELECT 1

FROM PRODUCT_MASTER M

WHERE M.PRODUCT_ID = S.PRODUCT_ID

);

■ ポイント解説

サブクエリは1行1列を返す必要がある
- サブクエリが複数行を返すと ORA-01427: single-row subquery returns more than one row エラーになります。
- PRODUCT_IDなどの条件で一意に絞り込みましょう。
WHERE EXISTSで更新対象を限定
- EXISTSを使わない場合、サブクエリが該当しないレコードは NULL で更新される可能性があります。
- 余計な更新を防ぐためにも、WHERE EXISTSを併用するのが安全です。
パフォーマンス最適化のためにインデックスを確認
- 結合条件に使う列（例：PRODUCT_ID）にはインデックスを付与すると高速化できます。

■ 別の書き方：MERGE文を使う方法

Oracleでは、サブクエリUPDATEの代わりにMERGE文を使っても同じことができます。

MERGE文は「更新または挿入」を同時に扱える構文で、
大量データ更新時にはこちらの方が効率的なこともあります。

■ まとめ

方法	特徴
サブクエリを使ったUPDATE	シンプルで分かりやすい。少量データ更新に最適。
MERGE文	更新＋挿入を同時に扱える。大量データ更新に向く。

■ この記事のポイント

Oracleでサブクエリを使ったUPDATEは「単一行サブクエリ＋EXISTS」で安全に実装する
一意性を保証できない場合は MERGE の利用を検討
インデックス設計で性能を最適化

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の問題と思われがちですが、多くはアプリ側のトランザクション管理が原因です。

SQL, ブログ

SQL：実行計画（EXPLAIN PLAN）の読み方とボトルネックの見つけ方

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

データベースチューニングにおいて「どのSQLが遅いのか」だけでなく、「どの処理がボトルネックなのか」を正しく把握することは非常に重要です。
そのための基本ツールが**実行計画（EXPLAIN PLAN）**です。

本記事では、Oracleを例に実行計画の見方とボトルネックの探し方を、初心者でも理解できるように解説します。

✅ EXPLAIN PLANとは？

SQLを実行する際、Oracleが内部的に考える**最適な実行手順（アクセス方法）**を表示する機能です。

実行計画を見ることで、次のようなことがわかります。

テーブルにアクセスする順番
インデックスを使っているかどうか
結合（JOIN）の方式
フルスキャンが走っているか
コスト（予測負荷）

✅ 実行計画の取得方法

▼ 方法1：EXPLAIN PLAN文を使う

▼ 方法2：SQL Developer で「実行計画」ボタン

GUI環境ではワンクリックで参照できます。

✅ Oracle実行計画の基本構造

実行計画は階層構造で、上から順に処理が行われます。
インデントが深いほど「その処理の中で実行される詳細処理」です。

例：

--------------------------------------------------------------------------------
| Id  | Operation                    | Name   | Rows  | Bytes | Cost (%CPU)|
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |        |     1 |    24 |     2   (0)|
|   1 |  TABLE ACCESS BY INDEX ROWID| EMP    |     1 |    24 |     2   (0)|
|   2 |   INDEX UNIQUE SCAN         | PK_EMP |     1 |       |     1   (0)|
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 24 | 2 (0)|

| 1 | TABLE ACCESS BY INDEX ROWID| EMP | 1 | 24 | 2 (0)|

| 2 | INDEX UNIQUE SCAN | PK_EMP | 1 | | 1 (0)|

--------------------------------------------------------------------------------

✅ よく出るOperationと解釈ポイント

Operation	説明	見どころ
TABLE ACCESS FULL	テーブルの全件スキャン	大量データで出たら要注意
TABLE ACCESS BY INDEX ROWID	インデックス参照後にROWIDアクセス	最適パターンの一つ
INDEX UNIQUE SCAN	主キー・ユニークインデックス検索	高速
INDEX RANGE SCAN	範囲検索	効率的だが条件次第
HASH JOIN	ハッシュ表でJOIN	大量データ向き、メモリ消費
NESTED LOOPS	小規模データに適したJOIN	結合相手の行数が多いと遅い
SORT ORDER BY	並び替え	必要ならOK、無駄がないか確認

✅ ボトルネックの探し方

① TABLE ACCESS FULL に注意

条件にインデックスが効いていない可能性
大規模テーブルで特に危険

対策：

WHERE句に使う列にインデックス追加
不必要なSELECT *を避ける
ファンクションインデックス

② JOIN方式を確認

JOIN方式	特徴	適したケース
NESTED LOOPS	小テーブル to 大テーブルに◎	OLTP向き
HASH JOIN	大量データ向き、高速	DWH向き
MERGE JOIN	並び替え前提、ソート負荷	ソート後結合

Nested Loops × 大量データ → 遅い可能性

③ コスト（COST）とROWSを確認

項目	意味
ROWS	見積もられる行数
COST	Oracleが見積もる負荷指数
BYTES	データ量

COSTが極端に高い行がボトルネック候補。

④ SORTが多い場合

ORDER BY や DISTINCTが多いと遅くなる

対策：

必要な場面以外でDISTINCT使用しない
ORDER BYの列にインデックス

✅ 実例：遅いSQLの典型パターン

問題点

UPPER(ENAME) → 関数でインデックス無効
LIKE ‘%〇〇’ → 前方ワイルドカードでインデックス無効
SELECT * → 不要な列読み込み

改善例

✅ チューニングの基本手順まとめ

ステップ	内容
1	実行計画を見る
2	TABLE FULL SCANをチェック
3	JOIN方法確認（Nested Loops vs Hash Join）
4	コスト高い箇所を特定
5	インデックス／SQL修正

✅ まとめ

EXPLAIN PLANはSQLの動作設計図
インデックス利用とJOIN方式を重視
FULL SCANと高コスト行は警戒
必要な列だけ取得し、関数利用に注意

SQLチューニングは**「まず実行計画を見る」**がスタートです。
慣れるほど読み解きが早くなり、効率的な分析ができるようになります。

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

Oracle「ORA-00942: 表またはビューが存在しません」エラー発生原因と解決策

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

Oracleデータベースを扱う中で、開発者や運用担当者が最も遭遇しやすいエラーのひとつが
「ORA-00942: 表またはビューが存在しません」 です。

本記事では、発生原因と具体的な解決策をわかりやすく解説します。

✅ ORA-00942とは？

SQLで参照したテーブルまたはビューが見つからないときに発生するエラーです。
主に DML（SELECT / INSERT / UPDATE / DELETE）実行時に発生します。

✅ 主な発生原因

原因	説明
テーブル名・ビュー名の誤字	タイプミス、大小文字の不一致
スキーマ名を指定していない	schema.table が必要なのに table だけ記述
オブジェクトが存在しない	作成前、削除済み、まだコミットされていない
権限不足	SELECT権限などが付与されていない
PUBLIC SYNONYMが無い/壊れている	シノニム経由アクセス失敗
参照先データベースリンクが不正	DBリンク先にオブジェクトが存在しない

✅ 代表的な発生例と解決策

① テーブル名の誤字

対策
スペルを確認し、USER_TABLES や ALL_TABLES で存在確認。

② スキーマ指定漏れ

本当は他スキーマのテーブル：

対策
必要に応じてスキーマ名を付けて記述。

③ 権限不足

権限が無い場合、テーブルが存在していても参照できません。

✅ 権限付与例（管理者実行）

④ シノニム問題

シノニム経由で参照する場合：

対策

壊れていれば再作成。

⑤ コミット忘れ

セッションAで作成 → セッションBから参照、未コミットの場合

対策
テーブル作成後は COMMIT;

✅ 原因の切り分け手順（チェックリスト）

チェック項目	コマンド / 方法
テーブルが存在するか	SELECT table_name FROM user_tables;
他スキーマか	SELECT owner, table_name FROM all_tables;
権限があるか	SELECT * FROM user_tab_privs;
シノニム確認	SELECT * FROM all_synonyms;
大文字小文字	SQL識別子は大文字扱い、""付きは注意

✅ よくある落とし穴

"テーブル名"（ダブルクォーテーション付き）で作成 → 大文字小文字が区別される
パーティションテーブルの参照ミス
DB移行後の権限不足
テスト環境と本番環境のスキーマ構成違い

✅ まとめ

要点	内容
エラー原因	オブジェクトなし・スキーマ指定漏れ・権限不足
解決方法	テーブル存在確認、権限確認、スキーマ明記
コツ	user_tables / all_tables で確認

Oracleはスキーマ管理と権限管理が厳密なため、
「テーブルが本当に存在するか」「アクセス権があるか」 が重要です。

✅ 例：実務での対応テンプレ

■ 発生時に実施する確認

SQLを確認（スペル・スキーマ）

ALL_TABLESで存在確認

権限を確認

必要に応じて GRANT 実施

この手順を覚えておけば、ほぼ解決できます。

💬 最後に

Oracleの権限周りは慣れるまで少し難しいですが、
このエラーは落ち着いて確認すれば必ず解決できます。

記事が役に立ったら、ぜひシェアやブックマークをお願いします！

SQL, ブログ

インデックスの仕組みを理解してSQLを劇的に高速化する方法

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

SQLの処理が遅いと感じたとき、多くの人が「サーバが遅いのでは？」と思いがちです。
しかし、実際の原因の多くは「インデックス（索引）」の使い方にあります。
この記事では、インデックスの基本構造から、実際のチューニング手法までを体系的に解説します。

1. インデックスとは？

インデックスとは、データベースが**検索を高速化するために作成する“索引”**のことです。
書籍の巻末索引のように、「この値はどこにあるか」を素早く見つけるための目次のような仕組みです。

🔹 例：インデックスなしの検索

このとき、インデックスが無ければ、データベースは全件を1件ずつ確認します（フルスキャン）。

🔹 例：インデックスありの検索

これにより、該当レコードを索引経由で一瞬で特定できるようになります。

2. インデックスの仕組みを理解する

🧩 B-treeインデックス

ほとんどのRDBMS（Oracle、MySQL、PostgreSQLなど）で採用されている構造です。
値が昇順に整理され、2分探索のように効率的に検索できます。

例えば「70」を探すとき、50より大きいので右に進み、次に70を発見します。
わずか2ステップで到達できるため、フルスキャンに比べて圧倒的に速いのです。

🧩 ビットマップインデックス（Oracleなど）

主に**値の種類が少ないカラム（性別、ステータスなど）**に有効です。
各値に対応するレコードのビットマップを管理することで、AND/OR検索が高速化します。

3. どんなカラムにインデックスを貼るべきか？

✅ 有効なケース

WHERE句で頻繁に検索される列
JOIN条件に使われる列
ORDER BYやGROUP BYの対象列
外部キー（FOREIGN KEY）列

🚫 不向きなケース

データ件数が極端に少ない列（例：性別など）
更新頻度が高い列（INSERT/UPDATEが多いと再構築コストが増大）
テーブル全件を常に取得するクエリ

4. 実行計画で確認する

SQLの速度改善は、**「インデックスが使われているか」**を確認することが第一歩です。

結果例（MySQLの場合）

type	key	rows	Extra
ref	idx_users_email	1	Using index

「Using index」と表示されていれば、インデックスが利用されています。
逆に「ALL」となっている場合はフルスキャンです。

5. インデックスを使った高速化テクニック

🌟 複合インデックス（複数列）

複数の列を組み合わせた検索で効果を発揮します。
ただし、先頭の列が条件に含まれないと使われない点に注意が必要です。

例：

🌟 カバリングインデックス（Covering Index）

インデックスに必要な列すべてを含めることで、テーブルアクセスをスキップできます。

テーブルを参照せずにインデックスだけで完結するため、極めて高速です。

🌟 LIKE検索の最適化

前方一致（Yui%）はインデックスが有効ですが、

のような部分一致はインデックス無効です。
対策としては、**全文検索エンジン（MySQLのFULLTEXT、PostgreSQLのGIN/GiST）**を使う方法があります。

6. 注意点：インデックスの弊害

インデックスは便利ですが、万能ではありません。
特に以下の点には注意が必要です。

リスク	説明
更新コスト増大	INSERTやUPDATE時にインデックスも更新されるため、処理が重くなる
ストレージ消費	大規模テーブルに多くのインデックスを張ると、容量が急増
メンテナンス負荷	不要なインデックスを放置すると、統計情報がずれて性能が劣化

🧹 定期的に ANALYZE TABLE や REBUILD INDEX を実施して、統計情報を更新しましょう。

7. 実践チューニング例

✏️ 例1：検索が遅いクエリ

🩹 改善策

✅ 実行計画の変化

変更前：type = ALL（フルスキャン）
変更後：type = ref（インデックス参照）

実行時間が数秒 → 数ミリ秒まで短縮されることもあります。

まとめ

ポイント	内容
インデックスとは	データ検索を高速化するための“索引”
構造	B-treeが主流。ビットマップは限定用途
効果的な付与	検索条件、JOIN、GROUP BY、ORDER BY列
落とし穴	更新負荷、容量増加、部分一致非対応
確認方法	EXPLAINで実行計画を必ずチェック

🚀 結論

インデックスを理解すれば、SQLの速度は10倍以上高速化することも珍しくありません。
なんとなく作るのではなく、「どう検索されるか」を意識して設計することが重要です。

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

Oracle「ORA-00904: 無効な識別子です」エラーの原因と修正ポイント

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

SQLを実行した際に、次のようなエラーが表示されたことはありませんか？

このエラーは、SQL内で指定したカラム名・テーブル名などの識別子（Identifier）が正しくない場合に発生します。特に、カラム名の誤字や存在しない列を参照すると頻発します。

この記事では、ORA-00904エラーの原因と修正ポイントをわかりやすく解説します。

ORA-00904エラーが発生する例

次のSQLを例として見てみましょう。

この場合、テーブルusersに user_nam というカラムが存在しないため、以下のエラーが出力されます。

ORA-00904が発生する主な原因と修正方法

✅ 1. カラム名の誤字・存在しない列を使用している

【誤った例】

【修正例】

👉 誤字・スペル間違いを最優先でチェックしましょう。

✅ 2. ダブルクォーテーションによる大文字・小文字の不一致

Oracleでは、識別子は通常大文字として認識されます。しかし、ダブルクォーテーションを使用すると厳密に区別されます。

【誤った例】

【修正例】

👉 ダブルクォーテーションは必要な場合のみ使用し、基本は使わない方が安全です。

✅ 3. 予約語をカラム名として使用している

以下のようにDATEやORDERなどOracleの予約語を識別子として使うとエラーになります。

【誤った例】

【修正例（識別子を避ける or ダブルクォートで囲む）】

✅ 4. テーブルやエイリアスの指定ミス

JOIN時などにエイリアスを間違えて参照するケースです。

【誤った例】

【修正例】

✅ 5. 関数や式の誤った使い方

【誤った例】

【修正例】

👉 構文ミスでエラーが識別子関連として認識されることもあります。

実務でよくあるケース3選

ケース	原因	対処
JOIN時の別テーブル誤参照	エイリアス忘れ	別名を正しく付ける
INSERT文に存在しないカラム名を記載	定義と不一致	DESCで定義確認
SELECT句とGROUP BY句の不一致	集約対象外カラム	GROUP BYに含める

発生を防ぐためのチェックポイント

✅ DESC テーブル名;で定義を確認
✅ カラム名はコピペでミス防止
✅ ダブルクォート識別子は極力使わない
✅ 予約語を避ける（Oracle公式リスト参照）
✅ JOIN時はエイリアスを必ず統一

まとめ

ポイント	内容
エラー原因	カラム名などの識別子の誤り
よくあるミス	誤字・予約語・エイリアスミス
対処法	テーブル定義確認＋構文見直し
予防策	DESC確認＋ダブルクォートに注意

ORA-00904は「識別子（カラム・テーブル名）のミスがある」というサインです。慌てず定義を見直しながら原因を特定しましょう。

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

Oracle「ORA-02292：整合性制約が違反しています」の原因と解決法

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

データ削除（DELETE）や更新（UPDATE）を行った際に、次のようなエラーが発生したことはありませんか？

このエラーは、「削除しようとしたデータが別のテーブルから参照されているため、勝手に消せません」という意味になります。本記事では、エラーの原因と解決方法を実例付きでわかりやすく解説します。

✅ ORA-02292とは？エラーの意味をわかりやすく解説

ORA-02292エラーは、外部キー（FOREIGN KEY）による整合性制約に違反したときに発生します。

つまり、

✅ 親テーブルのレコードを削除 or 更新しようとした
✅ でも、そのデータを参照している子テーブルのデータが存在している
✅ そのため削除・更新できず、エラーになる

という状況です。

✅ エラーが発生する典型的な例

📘 テーブル構成（例）

テーブル名	内容	備考
EMP	社員マスタ	親テーブル
SALARY	給与履歴	子テーブル（EMP_IDを参照）

このEMP_ID = ‘E001’ の社員が SALARY テーブルに登録されている場合、以下のエラーが発生します。

✅ 原因を確認する方法（参照関係を特定）

✅ どのテーブルから参照されているのかを確認

このSQLで、外部キー制約の一覧を確認できます。

✅ 解決方法4パターン（状況に応じて選択）

方法	解決内容	利用シーン	注意点
① 子テーブルを先に削除	手動で削除	一時的に消す場合	データ消失に注意
② 外部キーをNULL許可に	UPDATE対応可	柔軟な参照解除用	設計による
③ ON DELETE CASCADEを設定	親削除で自動削除	自動削除したい場合	子も消える
④ 制約を一時的に無効化	一時的に制約OFF	大量データ移行時	使い方注意

✅ 解決方法の実例SQL

✅ ① 子テーブルのデータを先に削除

✅ ② 外部キー制約をNULL許可に変更

✅ ③ 親削除時に子も自動削除（ON DELETE CASCADE）

✅ ④ 一時的に制約を無効化（※使用注意）

✅ よくある質問（FAQ）

❓ UPDATEでも発生する？

はい。親キーを変更して子テーブルとの整合性が崩れる場合にも発生します。

❓ 本当に削除して良いかわからない…

業務データでは「子テーブルに履歴が残っている＝重要なデータ」のケースも多いため、安易な削除は避けましょう。

✅ まとめ：削除順序と制約を理解することが鍵！

抑えるポイント	内容
エラー原因	子テーブルに参照されている
重要事項	削除順序「子→親」
推奨対策	ON DELETE CASCADEの活用も検討

1️⃣ SUBSTR：文字列の一部を取り出す

🔸 使用例

📘 ポイント

2️⃣ INSTR：文字列の位置を検索する

🔸 使用例

📘 応用テクニック

3️⃣ REPLACE：文字列の置換を行う

🔸 使用例

📘 応用テクニック

4️⃣ 組み合わせテクニック：実用的な例

💡 メールドメインを抽出する例

💡 ファイル名から拡張子を削除

5️⃣ まとめ

関連記事

🔍 ORA-01722とは？

💡 エラーの主な原因

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

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

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

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

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

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

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

🧪 実務でよくあるケース

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

🧩 まとめ

関連記事

🧩 ORA-02049とは

🔍 主な発生原因

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

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

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

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

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

💡 類似エラーとの違い

✅ まとめ

関連記事

■ 概要

■ 基本構文

■ 実際の例：商品価格マスタをもとに在庫テーブルを更新

【例題】

【目的】

【SQL例】

■ ポイント解説

■ 別の書き方：MERGE文を使う方法

■ まとめ

■ この記事のポイント

関連記事

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

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

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

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

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

✅ 再現例（簡易デモ）

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

トレースファイル例

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

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

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

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

✅ 4. 排他制御の明確化

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

✅ まとめ

関連記事

✅ EXPLAIN PLANとは？

✅ 実行計画の取得方法

▼ 方法1：EXPLAIN PLAN文を使う

▼ 方法2：SQL Developer で「実行計画」ボタン

✅ Oracle実行計画の基本構造

✅ よく出るOperationと解釈ポイント

✅ ボトルネックの探し方

① TABLE ACCESS FULL に注意

② JOIN方式を確認

③ コスト（COST）とROWSを確認

④ SORTが多い場合

✅ 実例：遅いSQLの典型パターン

問題点

改善例

✅ チューニングの基本手順まとめ

✅ まとめ

　関連記事

　関連記事

　関連記事

　関連記事

　関連記事

　関連記事

　関連記事

　関連記事

　関連記事