「データベース」タグアーカイブ

SQL：重複データを安全に削除する方法（DELETE＋ROW_NUMBER）

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

データベースを長く運用していると、アプリのバグやテストデータの混入、複数サーバ間複製のトラブルなどが原因で、重複データが発生することがあります。
しかし、安易に DELETE を実行すると必要なデータまで消えてしまう危険があります。

そこで本記事では、ROW_NUMBER() を使って重複行を安全に削除する方法をわかりやすく解説します。

🎯 本記事のゴール

重複データを判定する方法が理解できる
削除対象を事前に確認できる
ROW_NUMBER() と DELETE の実践手順がわかる

重複データとは？

以下のように、ユニークであるべき項目（メールアドレス、社員番号、商品コードなど）が複数存在する状態です。

id	email	name
1	aaa@test.com
	Tanaka
2	aaa@test.com
	Tanaka
3	bbb@test.com
	Suzuki

この場合、aaa@test.com が重複行となります。

手順①：重複データの行番号を振る

まずは削除対象となる行を特定します。
ROW_NUMBER() OVER (PARTITION BY ...) で同じキーを持つ行に番号を付与します。

実行結果例

id	email	rn
1	aaa@test.com
	1
2	aaa@test.com
	2
3	bbb@test.com
	1

rn = 1 を残して rn > 1 を削除対象とします。

手順②：削除対象のみを事前確認

※ 実務では必ずこのチェックを推奨

手順③：重複行を削除

DELETE
FROM users
WHERE id IN (
    SELECT id
    FROM (
        SELECT
            id,
            ROW_NUMBER() OVER (PARTITION BY email ORDER BY id) AS rn
        FROM users
    ) AS x
    WHERE x.rn > 1
);

DELETE

FROM users

WHERE id IN (

SELECT id

FROM (

SELECT

id,

ROW_NUMBER() OVER (PARTITION BY email ORDER BY id) AS rn

FROM users

) AS x

WHERE x.rn > 1

);

🔒 サブクエリが必要な理由

一部DBでは DELETE ... FROM 内で ROW_NUMBER() を直接参照できないため
サブクエリ（派生テーブル）を挟む必要があります。

💡 Delete 実行前の注意点

注意点	内容
バックアップ取得	DELETE後は戻せない
トランザクション内で実行	BEGIN / ROLLBACK の利用
WHERE句のチェック	WHERE間違いは致命傷
ORDER BYの基準を決める	新しいデータを残す/古いデータを残すなど

例：最新データを残したい場合

DBごとの対応表

DB	使用可否
PostgreSQL	◎
SQL Server	◎
Oracle	◎
MySQL 8.0 以降	◎
MySQL 5.x	× → サブクエリ＋JOINで対応
MariaDB	△

※ MySQL 5系の場合は別途記事で解説予定

まとめ

結論	内容
ROW_NUMBER()は重複削除に最適	削除対象を明確化できる
いきなりDELETEしない	SELECTで必ず事前確認
ORDER基準を明確にする	残すデータのルール決め

安全に確実に重複を削除するには
「削除対象の可視化」→「確認」→「DELETE」
という流れがとても重要です。

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 → ネットワーク → クライアント の順に切り分ければ最短で原因にたどり着けます。

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

ORA-12541の原因と対処法｜「TNS: リスナーがありません。」エラーを最速で解決する方法

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

Oracle接続時に突然出る ORA-12541: TNS: リスナーがありません。
現場でも頻出するエラーの1つで、接続テストが通らない・アプリがDBに繋がらないなどのトラブルを引き起こします。

この記事では、最速で復旧するためのチェック手順 → 原因の深掘り → 正しい対処法をわかりやすくまとめます。

結論：ほとんどは「リスナーが動いていない or 設定が不一致」

ORA-12541 は、Oracle に接続する際の窓口である Listener（リスナー） が見つからない時に発生します。

主な原因は以下のどれかです。

リスナーサービスが停止している
listener.ora のホスト名／ポート構成が間違っている
tnsnames.ora のHOST/IPが一致していない
ファイアウォールで1521ポートが遮断
サーバIPの変更後に設定未修正（Windows/VM/クラウドで多い）

では最速で治すチェック順を紹介します。

1. 最速で直す！ORA-12541のチェック手順（5ステップ）

① リスナーサービスが停止していないか確認

Windows

サービス → OracleOraDB…TNSListener を確認
停止していたら「開始」を押す。

で状態が確認できます。

Linux

TNS-12541: TNS:no listener が返った場合はリスナーが死んでいます。

② リスナーを再起動する

Windows / Linux 共通

成功すればほとんどのケースはこれで復旧します。

③ listener.ora のHOST/IPが本当に正しいか確認

リスナーが動いていても、設定されているホスト名が正しくないとリスナーは動作しません。

例：ホスト名変更後に listener.ora を更新していないケース

が myserver01 なのに一致していない → ORA-12541

IPアドレス変更後に放置している場合も同じです。

④ tnsnames.ora の接続先HOST/IPが一致しているか

クライアント側の設定が間違っていると当然繋がりません。

→ listener.ora 側と一致しているか要確認。

⑤ ポート（1521）がファイアウォールで塞がれていないか

Windows Firewall
Linux firewalld
クラウド（AWS SecurityGroup、Azure NSG など）

で 1521 が閉じていると ORA-12541 になります。

2. ORA-12541 が発生する代表的な原因まとめ

✔ リスナーが起動していない（最も多い）

DBサーバの再起動後に自動で上がっていない、手動停止したなど。

✔ listener.ora と tnsnames.ora の不整合

HOST名が一致していない
PORTが違う
サービス名（SERVICE_NAME）が間違い

設定変更後の再起動忘れもよくあります。

✔ DNS・ホスト名解決の問題

ホスト名を指定しているが DNS で解決できないケース。
→ IPアドレス直書きで繋がれば DNS が原因。

✔ VM・クラウドのIP変更

Oracle XE や開発環境で特に多い事例。
IPが変わったのに listener.ora を更新していないパターン。

3. 対処法まとめ（状況別）

🔧 ① リスナー停止が原因 → 再起動でOK

🔧 ② listener.ora の設定ミス → 修正 → リスナー再起動

ファイル場所

Windows: C:\oracle\product\...\network\admin\listener.ora
Linux: $ORACLE_HOME/network/admin/listener.ora

🔧 ③ tnsnames.oraが間違い → 修正

接続文字列を見直して、listener.ora と整合性を取る。

🔧 ④ ポート塞ぎ → FWで1521を許可

クラウド環境では SecurityGroup / NSG も要確認。

🔧 ⑤ DNS問題 → HOST をIPに変更する

接続先を一時的にIPにすると原因切り分けになる。

4. 再発防止のためのポイント

サーバ再起動後の リスナー自動起動設定を確認
listener.ora／tnsnames.ora の バックアップ運用
接続情報を IP指定 に統一する（開発環境向け）
FW設定変更の履歴をチームで共有

5. まとめ

ORA-12541「TNS:リスナーがありません。」 は、
リスナーが動いていない or 設定不一致が原因の9割です。

✔ 最速で確認すべきは以下の5つ

lsnrctl status
リスナーサービスの起動確認
listener.ora のHOST/IP
tnsnames.ora の整合性
ポート1521の開放

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, ブログ

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倍以上高速化することも珍しくありません。
なんとなく作るのではなく、「どう検索されるか」を意識して設計することが重要です。

SQL, ブログ

SQL：MERGE文でINSERTとUPDATEを一度に行う効率的な方法

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

MERGE文とは？

SQLのMERGE文は、対象テーブルにデータが存在する場合はUPDATE、存在しない場合はINSERTを1回の処理でまとめて行える便利な構文です。
従来は「UPDATE → 該当しなければINSERT」といった2回の処理が必要でしたが、MERGEを使うことで1回のSQLで済むため、処理効率やパフォーマンスが向上します。

本記事ではOracleをベースに解説しつつ、他DBでの対応についても補足します。

MERGE文の基本構文（Oracleの場合）

MERGE INTO 対象テーブル T
USING 参照元テーブル S
ON (T.キー = S.キー)
WHEN MATCHED THEN
    UPDATE SET T.カラムA = S.カラムA,
               T.カラムB = S.カラムB
WHEN NOT MATCHED THEN
    INSERT (カラムA, カラムB, カラムC)
    VALUES (S.カラムA, S.カラムB, S.カラムC);

MERGE INTO 対象テーブル T

USING 参照元テーブル S

ON (T.キー = S.キー)

WHEN MATCHED THEN

UPDATE SET T.カラムA = S.カラムA,

T.カラムB = S.カラムB

WHEN NOT MATCHED THEN

INSERT (カラムA, カラムB, カラムC)

VALUES (S.カラムA, S.カラムB, S.カラムC);

実用例①：顧客マスタの更新 or 追加

MERGE INTO CUSTOMER T
USING (SELECT 'C001' AS ID, '山田太郎' AS NAME, 'TOKYO' AS ADDRESS FROM DUAL) S
ON (T.ID = S.ID)
WHEN MATCHED THEN
    UPDATE SET T.NAME = S.NAME,
               T.ADDRESS = S.ADDRESS
WHEN NOT MATCHED THEN
    INSERT (ID, NAME, ADDRESS)
    VALUES (S.ID, S.NAME, S.ADDRESS);

MERGE INTO CUSTOMER T

USING (SELECT 'C001' AS ID, '山田太郎' AS NAME, 'TOKYO' AS ADDRESS FROM DUAL) S

ON (T.ID = S.ID)

WHEN MATCHED THEN

UPDATE SET T.NAME = S.NAME,

T.ADDRESS = S.ADDRESS

WHEN NOT MATCHED THEN

INSERT (ID, NAME, ADDRESS)

VALUES (S.ID, S.NAME, S.ADDRESS);

✅ ID=C001 が存在すれば更新
✅ 存在しなければ新規追加

処理の流れ（フロー図で理解）

          +----------------------+
          | 対象テーブルに該当   |
          | レコードは存在する？ |
          +----------+-----------+
                     |
          YES ←------+→ NO
           |                 |
UPDATE処理        INSERT処理

+----------------------+

| 対象テーブルに該当 |

| レコードは存在する？ |

+----------+-----------+

YES ←------+→ NO

| |

UPDATE処理 INSERT処理

応用例②：条件によってDELETEも行う（Oracle/SQL Server対応）

MERGE INTO ORDER_TABLE T
USING NEW_ORDER_DATA S
ON (T.ORDER_ID = S.ORDER_ID)
WHEN MATCHED AND S.STATUS = 'CANCEL' THEN
    DELETE
WHEN MATCHED THEN
    UPDATE SET T.AMOUNT = S.AMOUNT,
               T.STATUS = S.STATUS
WHEN NOT MATCHED THEN
    INSERT (ORDER_ID, AMOUNT, STATUS)
    VALUES (S.ORDER_ID, S.AMOUNT, S.STATUS);

MERGE INTO ORDER_TABLE T

USING NEW_ORDER_DATA S

ON (T.ORDER_ID = S.ORDER_ID)

WHEN MATCHED AND S.STATUS = 'CANCEL' THEN

DELETE

WHEN MATCHED THEN

UPDATE SET T.AMOUNT = S.AMOUNT,

T.STATUS = S.STATUS

WHEN NOT MATCHED THEN

INSERT (ORDER_ID, AMOUNT, STATUS)

VALUES (S.ORDER_ID, S.AMOUNT, S.STATUS);

✅ ステータスがCANCELなら削除
✅ そうでなければ更新
✅ 該当なしならINSERT

MERGE文のメリット

項目	従来方法	MERGE文
SQL実行回数	UPDATEとINSERTの2回	1回
パフォーマンス	やや低い	高い
ロジックの明確さ	分岐が必要	条件分が整理されやすい
メンテナンス性	低め	高い

注意点

注意点	内容
ロックの影響	大量データの場合、テーブルロックが発生しやすい
複雑な条件	WHEN句が増えると可読性が下がる
DB依存性	MySQLは8.0.19以降、PostgreSQLはINSERT ... ON CONFLICTで代替

他DBでの補足

DB	MERGE対応	備考
Oracle	対応	本記事基準
SQL Server	対応	ほぼ同構文
MySQL	8.0.19～対応	REPLACE/INSERT ON DUPLICATEも可
PostgreSQL	15～対応	それ以前はINSERT ON CONFLICT

まとめ

✅ MERGE文はINSERTとUPDATEを1回の処理にまとめる強力なSQL構文
✅ DELETEも組み合わせれば高度なロジックも実現可能
✅ Oracle・SQL Serverでは標準的に使用される
✅ MySQL/PostgreSQLではバージョン確認が必要

「同じキーのデータを更新 or 追加したい」場面で積極的に使いましょう！

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

Oracle DBでORA-12170「接続タイムアウト」が出る場合の調査方法

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

Oracleデータベースに接続しようとした際に、ORA-12170: TNS: 接続タイムアウトが発生しました というエラーが出ることがあります。
このエラーは、クライアントからデータベースへの接続要求がタイムアウトした場合に発生します。ネットワーク障害や設定不備、ファイアウォールの影響など原因は多岐にわたります。この記事では、調査のポイントをステップごとに解説します。

1. エラーメッセージの確認

まずは実際のエラーメッセージを確認しましょう。例えば以下のように出力されます。

sqlplus やアプリケーションログに記録されることが多いので、詳細をログからもチェックしておきます。

2. ネットワークレベルの確認

接続タイムアウトの多くはネットワーク経路に起因します。以下を確認しましょう。

ping でホストに疎通できるか
tnsping でOracleリスナーの応答があるか
ファイアウォールやセキュリティグループで 1521/TCP（デフォルトポート）がブロックされていないか
VPNやプロキシ経由の場合、経路に問題がないか

3. Oracle Listenerの確認

データベース側でリスナーが正常に動作しているか確認します。

状態が READY になっているか
正しいホスト名・ポートで待ち受けているか
リスナーログにエラーが出ていないか

4. SQL*Net / TNS設定の確認

クライアント側の tnsnames.ora や接続文字列の設定を見直します。

HOST名/IPアドレス が正しいか
SERVICE_NAME / SID が一致しているか
環境変数 ORACLE_HOME や TNS_ADMIN の設定が適切か

また、サーバ側の sqlnet.ora にて SQLNET.INBOUND_CONNECT_TIMEOUT や SQLNET.OUTBOUND_CONNECT_TIMEOUT が過剰に短く設定されていないかも確認します。

5. ファイアウォール / OS設定の確認

サーバOS側の設定も見直す必要があります。

OSファイアウォール（iptables / firewalld / Windows Defender Firewall）がポート1521を許可しているか
クラウド環境の場合、セキュリティグループやネットワークACL が接続をブロックしていないか
複数NICやロードバランサーを経由している場合に経路の設定が正しいか

6. タイムアウト値の調整

原因が不明な場合、タイムアウト値の調整も検討できます。

クライアント側: sqlnet.ora の SQLNET.OUTBOUND_CONNECT_TIMEOUT
サーバ側: sqlnet.ora の SQLNET.INBOUND_CONNECT_TIMEOUT
Listener側: listener.ora の INBOUND_CONNECT_TIMEOUT_LISTENER

ただし、根本原因がネットワークや設定不備である場合は、単なる延命策になってしまう点に注意が必要です。

まとめ

ORA-12170 が発生した場合の調査手順は以下の流れで進めると効率的です。

ネットワーク疎通確認（ping / tnsping）
リスナー稼働状況確認（lsnrctl status）
接続設定（tnsnames.ora / 接続文字列）の確認
サーバ側ファイアウォールやクラウドセキュリティ設定の確認
タイムアウト設定の調整

多くの場合、ネットワーク経路やファイアウォールが原因となるケースが多いため、まずは通信経路の確認から着手するのがポイントです。

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

Oracle「ORA-06502: PL/SQL 数値または値エラー」エラーが出た時の解決方法

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

Oracle データベースを利用していると、**「ORA-06502: PL/SQL: 数値または値エラー」**というエラーに遭遇することがあります。これは比較的よく見られるエラーの一つで、主に「データ型の不一致」や「文字列長の超過」が原因です。この記事では、このエラーの代表的な原因と解決方法を解説します。

ORA-06502 エラーの意味

エラーメッセージ全文は以下のようになります。

このエラーは、PL/SQL 実行時に「値が期待されるデータ型に収まらない」場合に発生します。例えば以下のケースです。

数値型の変数に、文字列を代入しようとした場合
VARCHAR2 の長さ制限を超える文字列を代入した場合
型変換関数（TO_NUMBER, TO_DATE など）が失敗した場合

よくある原因と解決方法

1. 文字列長の超過

解決方法: 変数の長さを見直す、あるいは SUBSTR を利用して長さを調整する。

2. 数値変換エラー

解決方法: 入力値が数値かどうかを事前にチェックする。正規表現を利用するのも有効です。

3. 不正な日付変換

原因: 存在しない日付を変換しようとした。
解決方法: 入力フォーマットをチェックし、妥当な値のみ渡す。

4. 数値桁数のオーバーフロー

解決方法: NUMBER の定義を見直す、または値を丸める。

トラブルシューティングのポイント

エラー発生時の 変数定義 を確認する
DBMS_OUTPUT.PUT_LINE で 代入しようとしている値 を出力する
データベースの カラム定義と変数定義の不一致 を確認する
外部入力（CSV など）を扱う場合は 入力データの妥当性チェック を行う

まとめ

「ORA-06502」エラーは、ほとんどの場合 データ型の不一致 や 値の範囲超過 が原因です。
再発防止のためには以下が重要です。

変数やカラムの定義を余裕を持たせて設計する
入力値チェックを徹底する
デバッグ時に DBMS_OUTPUT を活用して値を追跡する

これらを意識することで、エラーを効率的に解消できるはずです。

🎯 本記事のゴール

重複データとは？

手順①：重複データの行番号を振る

実行結果例

手順②：削除対象のみを事前確認

※ 実務では必ずこのチェックを推奨

手順③：重複行を削除

🔒 サブクエリが必要な理由

💡 Delete 実行前の注意点

DBごとの対応表

まとめ

関連記事

■ 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：インスタンスが落ちた

▼対処

■ まとめ（結論）

関連記事

結論：ほとんどは「リスナーが動いていない or 設定が不一致」

1. 最速で直す！ORA-12541のチェック手順（5ステップ）

① リスナーサービスが停止していないか確認

Windows

Linux

② リスナーを再起動する

Windows / Linux 共通

③ listener.ora のHOST/IPが本当に正しいか確認

④ tnsnames.ora の接続先HOST/IPが一致しているか

⑤ ポート（1521）がファイアウォールで塞がれていないか

2. ORA-12541 が発生する代表的な原因まとめ

✔ リスナーが起動していない（最も多い）

✔ listener.ora と tnsnames.ora の不整合

✔ DNS・ホスト名解決の問題

✔ VM・クラウドのIP変更

3. 対処法まとめ（状況別）

🔧 ① リスナー停止が原因 → 再起動でOK

🔧 ② listener.ora の設定ミス → 修正 → リスナー再起動

ファイル場所

🔧 ③ tnsnames.oraが間違い → 修正

🔧 ④ ポート塞ぎ → FWで1521を許可

🔧 ⑤ DNS問題 → HOST をIPに変更する

4. 再発防止のためのポイント

5. まとめ

✔ 最速で確認すべきは以下の5つ

関連記事

🧩 ORA-02049とは

🔍 主な発生原因

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

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

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

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

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

💡 類似エラーとの違い

✅ まとめ

関連記事

✅ EXPLAIN PLANとは？

✅ 実行計画の取得方法

▼ 方法1：EXPLAIN PLAN文を使う

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

✅ Oracle実行計画の基本構造

　関連記事

　関連記事

　関連記事

　関連記事

　関連記事

　関連記事

　関連記事

　関連記事