PL/SQLを書いていて最初にぶつかる壁の一つがコンパイルエラーとコンパイル警告の読み解きです。OracleのコンパイラはWarning: created with compilation errorsという味気ないメッセージを返すだけで、原因は別のビューから自分で引き出す必要があります。SHOW ERRORSとUSER_ERRORSを使い分けて正しく診断できるかは、PL/SQL開発の生産性を大きく左右する基礎スキルです。
さらに重要なのが、ほとんどの現場でオフのままになっているPLSQL_WARNINGSです。これを有効化すると「到達不能コード」「オーバーロードの曖昧な呼び出し」「非推奨APIの利用」「戻り値のないRETURN経路」などを本番で踏む前にコンパイラが警告してくれます。現場の多くはこの宝の山を活用できていません。
この記事ではSHOW ERRORS/USER_ERRORS/DBA_ERRORSの実践的な使い方から、PLSQL_WARNINGSの完全活用、頻出PLS-エラー対策早見表、CI/CDでコンパイル失敗を自動検出する設計、警告レベルの運用ポリシーまで、実務で本当に効く知識を2026年版で整理します。
この記事でわかること
- コンパイルエラーとランタイムエラーの違いと検出タイミング
- SHOW ERRORSの出力構造と「最後にコンパイルしたオブジェクト」の罠
- USER_ERRORS・DBA_ERRORSで複数オブジェクトのエラーを一覧診断する方法
- PLSQL_WARNINGSをALL/SEVERE/PERFORMANCE/INFORMATIONALで使い分ける戦略
- SEVERE警告で「確実に踏むバグ」を本番前に検出するテクニック
- 頻出PLS-エラー20種の原因と即解決パターン
- PRAGMA DEPRECATEで非推奨APIの使用を警告として可視化する方法
- CI/CDパイプラインでコンパイル失敗・警告を自動検出する設計
- 警告レベルのチーム運用ポリシー(何を許容し何を禁止するか)
30秒でわかるコンパイルエラー対処の結論
忙しい読者向けの結論先出しです。
| 結論 | 理由・効果 |
|---|---|
① 単体診断はSHOW ERRORS <type> <name> |
直前コンパイルだけのSHOW ERRORSは他セッション切替で見失う |
② 複数オブジェクト一覧はUSER_ERRORS |
INVALIDを一括スキャン+行番号でIDE連携可 |
| ③ PLSQL_WARNINGS=’ENABLE:ALL’は必須装備 | 到達不能・戻り値なしRETURN・非推奨APIなどを本番前に検出 |
④ 警告だけで失敗扱いしたい場合はPLSQL_WARNINGS='ERROR:...' |
CI/CDで特定カテゴリを厳格化してデプロイをブロック |
| ⑤ 非推奨APIはPRAGMA DEPRECATEで警告化 | 社内で廃止予定の関数呼び出し元を可視化できる |
| ⑥ CI/CDはUSER_ERRORSの件数チェックで失敗判定 | ‘Warning: …errors’の標準出力解析は不安定 |
| ⑦ PLS-00201(識別子不明)の原因は権限不足か綴り誤りがほぼ全て | まずはDBA_OBJECTS検索+GRANT確認 |
コンパイルエラーと警告の違いを正しく区別する
PL/SQLのコンパイルフィードバックは大きく3段階に分かれます。混同すると診断と優先順位付けを誤るので、まずこの分類を押さえます。
コンパイルエラー(ERROR)
オブジェクトをINVALID状態にする致命的な問題です。該当オブジェクトは実行できない状態になり、呼び出した時点でORA-04063やORA-06550で落ちます。典型例は構文エラー、型不一致、存在しない識別子、権限不足など。デプロイを止める唯一絶対のシグナルで、検出したら必ず修正してから次に進みます。
コンパイル警告(WARNING)
コンパイルは成功するが、コンパイラが「潜在的に危険・非効率・非推奨」と判断した項目です。オブジェクトはVALIDで実行可能ですが、警告の中には実行時にほぼ確実にバグとして顕在化する内容(到達不能コード・戻り値のないRETURN経路など)が含まれるため、PLSQL_WARNINGSを有効化していないと見逃しがちです。
ランタイムエラー(ORA-XXXXX)
コンパイル時には検出できない、実行時の異常です。NULL参照(ORA-06502)、一意制約違反(ORA-00001)、NO_DATA_FOUND(ORA-01403)など。これらはPL/SQLの例外処理(EXCEPTION句)で対応する範囲で、本記事のコンパイルエラー/警告とは扱いが異なります。
肝心なのは「警告は無視してもいいわけではない」こと。Oracleがデフォルトで警告をオフにしているのは後方互換のためで、新規開発では必ずPLSQL_WARNINGSをONにすべきです。警告を有効化するだけで検出できるバグ事例が次のセクション以降の核心です。
SHOW ERRORSの正しい使い方|直近コンパイルの落とし穴
SQL*Plus/SQLclで最も使われるエラー診断コマンドがSHOW ERRORSですが、引数なしで呼ぶと「同じセッション内で直前にコンパイルしたオブジェクト」のエラーしか出ません。別オブジェクトを触った瞬間に失われるので、明示的にSHOW ERRORS TYPE NAMEで指定するのが鉄則です。
-- ❌ 引数なし:直前コンパイルのみ表示、別オブジェクトを触ると失う CREATE OR REPLACE PROCEDURE p_broken AS BEGIN NULL; END; -- これは成功 SHOW ERRORS -- → No errors.(直前コンパイルのエラーを探すが何も出ない) -- ✅ 明示指定:いつでも特定オブジェクトのエラーを取得 SHOW ERRORS PROCEDURE p_broken SHOW ERRORS PACKAGE BODY pkg_order SHOW ERRORS FUNCTION f_calc_tax SHOW ERRORS TRIGGER trg_emp_upd -- 出力例 LINE/COL ERROR -------- --------------------------------------------------------- 7/5 PL/SQL: Statement ignored 7/5 PLS-00201: identifier 'PKG_ACCOUNT.UNKNOWN_PROC' must be declared 12/3 PL/SQL: Statement ignored 12/3 PLS-00302: component 'TOTAL_AMT' must be declared -- SHOW ERRORS の出力意味 -- 7/5 = 行7カラム5 -- PLS-00201 = 識別子が宣言されていない(権限なし or 綴り誤り) -- PLS-00302 = コンポーネントが宣言されていない(プロパティ誤り)
SHOW ERRORSはSQLPlus/SQLcl/SQL*Developerのクライアント機能で、アプリケーションからは呼べません(実体はUSER_ERRORSのSELECT)。Pythonやシェルスクリプトからコンパイルチェックする際は後述のUSER_ERRORSを直接クエリする必要があります。
USER_ERRORS / DBA_ERRORS|複数オブジェクトを一括診断
リリース作業で「INVALIDが10個残った、どこから直す?」という場面ではSHOW ERRORSの1本ずつ確認では日が暮れます。USER_ERRORSビュー(自スキーマ)またはDBA_ERRORS(全スキーマ・DBA権限)を直接クエリすれば一覧として診断できます。
主要カラム
NAME/TYPE:オブジェクト名と種別(PROCEDURE・PACKAGE BODY等)SEQUENCE:同一オブジェクト内のエラー順番LINE/POSITION:発生行とカラム(IDE連携で便利)TEXT:エラーメッセージ本体(PLS-00201など)ATTRIBUTE:ERROR/WARNINGの区別MESSAGE_NUMBER:PLS番号の数値部分(CIフィルタに便利)
-- 1. 自スキーマのINVALIDオブジェクトとエラーを一覧
SELECT name, type, line, position, attribute, text
FROM user_errors
ORDER BY name, sequence;
-- 2. エラーのみ(警告除外)→ デプロイ可否判定に使う
SELECT name, type, COUNT(*) AS err_cnt
FROM user_errors
WHERE attribute = 'ERROR'
GROUP BY name, type
ORDER BY err_cnt DESC;
-- 3. 警告だけ抽出 → コードレビュー前の自己診断
SELECT name, type, line, message_number, text
FROM user_errors
WHERE attribute = 'WARNING'
ORDER BY name, line;
-- 4. 特定のエラーコードで全オブジェクト横断検索(例: 権限不足)
SELECT name, type, line, text
FROM user_errors
WHERE message_number = 201 -- PLS-00201(識別子不明)
ORDER BY name, line;
-- 5. DBA権限で全スキーマのエラーを俯瞰
SELECT owner, name, type, line, attribute, text
FROM dba_errors
WHERE attribute = 'ERROR'
AND owner NOT IN ('SYS','SYSTEM','MDSYS','XDB')
ORDER BY owner, name, sequence;
USER_ERRORSはコンパイル時の永続的な結果を保持しているので、デプロイ後いつでも状態を調べられます。対してSHOW ERRORSはセッションローカルなので、「さっきコンパイルしたはずのエラーが見えない」と思ったらUSER_ERRORSを直接クエリしてください。
PLSQL_WARNINGS|本番前にバグを捕まえる最強装備
PL/SQLには「コンパイル時に検出できるが、デフォルトでは警告しない」落とし穴が多数あります。PLSQL_WARNINGSパラメータでこれらを強制的に表面化できます。警告は3カテゴリに分かれ、チームの厳格度に応じて組み合わせ可能です。
SEVERE(深刻)|実行時ほぼ確実に踏むバグ
「到達不能コード」「戻り値のないRETURN経路」「型の暗黙変換で精度を失う」など、本番で障害になる確率が極めて高い問題群です。新規開発では必ずONに、既存プロジェクトでもまずSEVEREだけでも有効化するとバグ検出が劇的に早まります。
PERFORMANCE(性能)|非効率な実装を指摘
NUMBER型同士の比較で暗黙変換が走る、OUTパラメータが未初期化のまま使われる、など。性能系は必ずしも即座にバグではないため、「リリース前に1回回してチェック」の位置づけで使うのが現実的です。
INFORMATIONAL(情報)|スタイル警告・宣言未使用など
「宣言したが未使用の変数」「IS/AS の揺れ」などコードの清潔さに関する警告。厳格化すると警告が大量に出るので、CI段階では無効化しIDEのlintレベルで運用するのが実務的です。
-- A. セッション単位で有効化(開発者が手動で検査) ALTER SESSION SET PLSQL_WARNINGS = 'ENABLE:ALL'; -- B. システム単位で恒久的に有効化(DBA権限) ALTER SYSTEM SET PLSQL_WARNINGS = 'ENABLE:SEVERE, ENABLE:PERFORMANCE' SCOPE=BOTH; -- C. 特定カテゴリを警告ではなくエラー扱いにする -- → コンパイル自体を失敗させてデプロイを止める ALTER SESSION SET PLSQL_WARNINGS = 'ENABLE:ALL, ERROR:PERFORMANCE, DISABLE:INFORMATIONAL'; -- D. 特定番号の警告だけ個別制御(例: PLW-06002を許容) ALTER SESSION SET PLSQL_WARNINGS = 'ENABLE:ALL, DISABLE:(06002)'; -- E. パッケージ単位で永続設定 ALTER PACKAGE my_pkg COMPILE PLSQL_WARNINGS='ENABLE:ALL' REUSE SETTINGS; -- 現在の設定を確認 SHOW PARAMETER plsql_warnings -- または SELECT name, value FROM v$parameter WHERE name = 'plsql_warnings';
SEVERE警告で捕まる典型バグ
実際にSEVEREを有効化すると、こんなバグが本番前に検出できます。いずれも実行時ほぼ確実に問題になる書き方で、警告オフだとすり抜けてしまうのが怖いポイントです。
-- ① PLW-06002: 到達不能コード CREATE OR REPLACE FUNCTION f_status(p NUMBER) RETURN VARCHAR2 AS BEGIN IF p > 0 THEN RETURN 'POS'; ELSIF p < 0 THEN RETURN 'NEG'; ELSE RETURN 'ZERO'; END IF; RETURN 'UNKNOWN'; -- ← ここに到達する道がない END; / -- ② PLW-05005: 戻り値のないRETURN経路 CREATE OR REPLACE FUNCTION f_grade(p NUMBER) RETURN VARCHAR2 AS BEGIN IF p >= 80 THEN RETURN 'A'; END IF; IF p >= 60 THEN RETURN 'B'; END IF; -- ← p<60のときRETURNせず関数を抜ける(実行時 ORA-06503) END; / -- ③ PLW-06009: 数値リテラルの暗黙切り捨て DECLARE v NUMBER(3) := 12345; -- ← 精度オーバー、実行時エラー BEGIN NULL; END; / -- ④ PLW-05004: IN OUT パラメータが実質未代入で戻る CREATE OR REPLACE PROCEDURE p_calc(p_out IN OUT NUMBER) AS BEGIN IF p_out > 0 THEN p_out := p_out * 2; END IF; -- ← p_out <=0 のときに値を更新しない可能性を警告 END; /
推奨運用:①ローカル開発=ENABLE:ALLで全警告を目視、②CI/CDステージング=ENABLE:SEVERE,ENABLE:PERFORMANCE,ERROR:SEVEREでSEVEREをエラー扱いにしてデプロイをブロック、③本番システムパラメータ=ENABLE:SEVEREで最低限のガード、という3層運用が現実的な落としどころです。
頻出PLS-エラー早見表|原因と即解決パターン
コンパイルエラーの8割は一握りの典型エラーに集約されます。最頻出の20種を原因と対策付きでまとめます。
| 番号 | メッセージ | 主原因と対策 |
|---|---|---|
| PLS-00103 | ‘X’を検出しました | 構文エラー。セミコロン抜け・終了キーワード違い。前後行を先に確認 |
| PLS-00201 | 識別子’X’を宣言してください | 綴り誤り・シノニム未作成・GRANT忘れ。DBA_OBJECTS+USER_TAB_PRIVS確認 |
| PLS-00302 | コンポーネント’X’を宣言してください | パッケージ/レコードのメンバー名誤り・SPECに未公開 |
| PLS-00306 | 呼出しで引数の数または型が誤り | オーバーロード解決失敗。引数型を明示キャスト |
| PLS-00323 | サブプログラムX はSPECで宣言されましたが本体なし | パッケージBODYの実装忘れ |
| PLS-00341 | カーソルX の宣言が不完全 | FROM句未記述・対象テーブル不在 |
| PLS-00363 | 式’X’は代入ターゲットとして使用できない | 定数・関数呼び出しの戻り値に代入している |
| PLS-00382 | 式の型が不正 | NUMBER↔VARCHAR2の暗黙変換の失敗・NULL比較 |
| PLS-00394 | INTO句の変数の数が不正 | SELECT列数とINTO変数の数不一致 |
| PLS-00410 | RECORD型の重複フィールド | レコード定義で同名フィールド定義重複 |
| PLS-00423 | 型の不正 | %TYPEの参照先が存在しない |
| PLS-00428 | INTO句がSELECT文に必要 | PL/SQL内のSELECTはINTO必須。不要なら暗黙カーソルに書き換え |
| PLS-00642 | ローカル・コレクション型はSQL文で使用不可 | PL/SQL局所型をSQL側で参照。CREATE TYPEでスキーマ型化 |
| PLS-00904 | オブジェクト’X’にアクセスする権限がない | GRANTの不足・ロール経由権限はパッケージ外で付与が必要 |
| PLS-00905 | オブジェクト’X.Y’は無効 | 依存先のINVALID。UTL_RECOMPで先に回復 |
| PLS-00907 | プログラム・ユニット’X’をロードできない | 依存するオブジェクトが壊れている・名前衝突 |
| PLS-00920 | 共有プールに空きメモリなし | SGA不足。DBA対応領域 |
| PLS-06550 | 実行が不可能 | ランタイム側で発生する総称エラー。USER_ERRORSで実原因確認 |
| PLW-05005 | 関数の一部経路で値が戻されない | すべての条件分岐でRETURN/ELSE必須 |
| PLW-06002 | 到達不能コード | IF/CASE/EXITの論理設計ミス。分岐条件を見直し |
PRAGMA DEPRECATE|非推奨APIの利用を警告として炙り出す
「このパッケージ関数は将来廃止するので使わないでほしい」をコードで宣言できるのがPRAGMA DEPRECATE(12.2以降)です。PLSQL_WARNINGSが有効な状態でDEPRECATEされた対象を呼ぶとPLW-06019が警告として出るため、社内ライブラリの移行計画を進める武器になります。
-- パッケージ仕様で非推奨宣言
CREATE OR REPLACE PACKAGE pkg_order AS
-- 旧関数(非推奨)
FUNCTION get_total_old(p_order_id NUMBER) RETURN NUMBER;
PRAGMA DEPRECATE(
get_total_old,
'get_total_old は廃止予定です。v2 の calc_total を使用してください'
);
-- 新関数
FUNCTION calc_total(p_order_id NUMBER) RETURN NUMBER;
END pkg_order;
/
-- 呼び出し側のコンパイル時に警告
CREATE OR REPLACE PROCEDURE p_invoice AS
v_amt NUMBER;
BEGIN
v_amt := pkg_order.get_total_old(:order_id); -- ← PLW-06019 が警告
END;
/
-- USER_ERRORSで呼び出し元を一覧化
SELECT name, type, line, text
FROM user_errors
WHERE message_number = 6019
AND attribute = 'WARNING';
DEPRECATE運用のコツ:①廃止予定関数にPRAGMAを付けPLSQL_WARNINGSで警告化、②USER_ERRORSで呼び出し元一覧を抽出、③呼び出し元を修正しながら数週間運用、④呼び出し元がゼロになったら実装削除、の4ステップ。「使われているかわからないから消せない」問題が構造的に解決します。
CI/CDでコンパイル失敗・警告を自動検出する
リリース作業で「USER_ERRORSを確認し忘れてINVALIDのままデプロイ」という事故を防ぐには、CI/CDにコンパイル結果チェックを組み込みます。SHOW ERRORSの標準出力解析はWarning: ...文字列の揺れで不安定なので、USER_ERRORSの件数を終了コードで判定するのが鉄則です。
-- compile_check.sql(SQL*Plus / SQLclで実行)
SET SERVEROUTPUT ON
SET FEEDBACK OFF
WHENEVER SQLERROR EXIT 2 -- SQL実行エラーで終了コード2
-- コンパイル警告を厳しく
ALTER SESSION SET PLSQL_WARNINGS = 'ENABLE:ALL, ERROR:SEVERE';
-- デプロイ対象ファイルを流す
@@packages/pkg_order.pks
@@packages/pkg_order.pkb
@@procedures/p_invoice.prc
-- USER_ERRORS チェック
DECLARE
v_err NUMBER;
v_warn NUMBER;
BEGIN
SELECT SUM(CASE WHEN attribute='ERROR' THEN 1 ELSE 0 END),
SUM(CASE WHEN attribute='WARNING' THEN 1 ELSE 0 END)
INTO v_err, v_warn
FROM user_errors;
DBMS_OUTPUT.PUT_LINE('Errors : ' || NVL(v_err,0));
DBMS_OUTPUT.PUT_LINE('Warnings: ' || NVL(v_warn,0));
IF NVL(v_err, 0) > 0 THEN
-- エラーが1件でもあれば明示的に失敗
RAISE_APPLICATION_ERROR(-20001,
'Compilation failed with ' || v_err || ' errors');
END IF;
END;
/
EXIT SUCCESS
name: PLSQL CI
on: [pull_request]
jobs:
compile-check:
runs-on: ubuntu-latest
services:
oracle:
image: gvenzl/oracle-free:latest-faststart
env:
ORACLE_PASSWORD: ${{ secrets.ORACLE_PASSWORD }}
ports: [1521:1521]
steps:
- uses: actions/checkout@v4
- name: Install SQLcl
run: |
wget -q https://download.oracle.com/otn_software/java/sqldeveloper/sqlcl-latest.zip
unzip -q sqlcl-latest.zip -d /opt
- name: Run compile check
run: |
/opt/sqlcl/bin/sql -s app/${ORACLE_PASSWORD}@localhost:1521/FREEPDB1 \
@compile_check.sql
# 失敗時に終了コード!=0 を返しCIが赤になる
Oracleの公式Docker(gvenzl/oracle-free)は軽量でGitHub Actionsでも扱いやすく、PRごとにクリーンな環境でPLSQL_WARNINGS=ERROR:SEVEREでコンパイルチェックできます。ローカル/ステージング/本番のすべてで同じチェックを回せばコンパイルエラー混入の事故がほぼゼロになります。
本番で踏むアンチパターン6選
① SHOW ERRORS引数なしで「他オブジェクトのエラーが見えない」と嘆く
引数なしはセッション内の直前コンパイルだけ。別のSQLや接続をまたいだ瞬間に失われます。必ず型+名を明示するかUSER_ERRORSを直接クエリしてください。
② PLSQL_WARNINGSがOFFのまま運用
到達不能コード・戻り値なしRETURNなど「警告にすれば即発見できた」バグを本番障害で踏むパターン。最低限ENABLE:SEVEREだけでもシステムパラメータでONにしておいてください。
③ Warning: … created with compilation errorsを無視してコミット
この警告文はオブジェクトがINVALIDである致命的サイン。Gitにpushしてしまうと他メンバーの環境でも壊れ、リリース時に大事故になります。コミット前に必ずUSER_ERRORSを空にする習慣を付けてください。
④ USER_ERRORSにWARNINGが残ったままリリース
コンパイル時点で分かっている潜在バグを本番に持ち込む行為です。「ERROR=0」だけでなく「WARNING=0(あるいは許容リスト内)」もリリース条件に含めてください。
⑤ PLS-00201の原因を「綴り誤り」と決め打ち
半分以上は権限不足が原因です。オブジェクトは存在するのにコンパイル時に見えないケースはUSER_TAB_PRIVS/ALL_OBJECTSで確認するのが先決。ロール経由の権限はパッケージ内から見えないのでダイレクトGRANTが必要な場面があります。
⑥ 非推奨関数を放置しPRAGMA DEPRECATEを使わない
コメントで「使わないで」と書くだけでは呼び出されるたびに気づけません。PRAGMAで警告化すればUSER_ERRORSで使用箇所を機械的に一覧化でき、「本当に消して大丈夫か」が判断できるようになります。
よくある質問
SHOW ERRORSが手軽です(SQL*Plus/SQLclで直接見える)。一方、複数オブジェクトの状態を俯瞰したい・自動化したい・別セッションで発生したエラーを調べたい場合はUSER_ERRORSを直接クエリします。大原則は人間が眺めるときはSHOW ERRORS、スクリプトで扱うときはUSER_ERRORSです。ENABLE:SEVEREだけに絞って有効化し、SEVEREのみ解消する段階的運用を推奨します。PERFORMANCEとINFORMATIONALは確かに大量に出るため一気にONにすると作業が止まります。SEVEREがゼロになったら次にPERFORMANCE、最後にINFORMATIONAL、という順で徐々に厳格化するのが現実解です。EXCEPTION句での処理が必要です。PL/SQL例外処理の詳細は別記事を参照してください。USER_ERRORSには出ない。v$diag_alert_extやアプリログでORA-XXXXXを確認。②依存先がINVALID→自身はVALIDだが依存先が壊れているため呼び出した瞬間にORA-04063が出る。USER_OBJECTSのSTATUS列で依存先を確認してください。ALTER PACKAGE X COMPILE PLSQL_WARNINGS='ENABLE:SEVERE' REUSE SETTINGSで既存コードは緩く、新規コードは厳しく、という段階的導入が可能です。CI/CDでも新規追加ファイルだけ厳格化してdiff対象外ファイルは緩くする方法も有効です。SELECT * FROM all_objects WHERE object_name = 'X';でオブジェクトの存在と所有者を確認。②SELECT * FROM user_tab_privs WHERE table_name = 'X';で自分に付与されている権限を確認。③パッケージからの呼び出しなら「ロール経由ではなく直接GRANT」が必要なのでSELECT * FROM session_privs;ではなくSET ROLE NONE; SELECT * FROM user_tab_privs;で無視されない権限を確認します。EDIT XでSQL*Plusのバッファを開いて再確認、②USER_ERRORSのLINE/POSITIONを原文と突合、③エラーの前行を疑う(セミコロン抜けは次行でPLS-00103になる)、④依存先のINVALIDをUTL_RECOMPで先に回復、⑤それでも解決しない場合はALL_SOURCEからコードを再取得して環境差異の可能性を探る。依存関係の再コンパイルについては依存オブジェクトとINVALID再コンパイルの制御の記事が詳しいです。DBMS_WARNING.ADD_WARNING_SETTING_CATで個別警告設定を管理する方法がありますが、機能範囲は限定的なのでバージョンアップが一番確実です。サポート終了済みの12.1以前を使っているなら、移行の良い動機にもなります。PLSQL_CODE_TYPE=NATIVEでコンパイルした場合のみ外部Cコンパイラのエラー(PLS-00801系)が追加で発生する可能性があります。これが出たらPLSQL_NATIVE_LIBRARY_DIRの設定を確認、それでも解決しなければPLSQL_CODE_TYPE=INTERPRETEDに戻すのが先決です。関連記事で知識を深める
PL/SQLの品質向上と運用安定化に効く関連記事です。
- 【PL/SQL】依存オブジェクトとINVALID再コンパイルの制御(UTL_RECOMP・コンパイル順序・依存グラフ)
- 【PL/SQL】例外処理の書き方と使い方(ランタイムエラーの扱い)
- 【Oracle】PL/SQL例外処理完全ガイド(例外設計の基礎)
- 【PL/SQL】ストアドプロシージャとファンクションの違いと作り方(関数設計の基礎)
- 【PL/SQL】MERGE文でUPSERTを高速・安全に実装(コンパイル時の典型エラー事例)
- 【PL/SQL】パイプライン関数で大量データ処理を勝たせる完全ガイド(戻り型の型定義でPLS-00341を踏まない)
- 【PL/SQL】DBMS_SCHEDULERでジョブ管理を極める(ジョブコンパイル時のエラー対策)
- 【Oracle】PL/SQL文字列関数完全ガイド(暗黙型変換警告の原因理解)
- 【Oracle】EXECUTE IMMEDIATE完全ガイド(動的SQLでコンパイルエラーをランタイムへ持ち越さない設計)
- 【Oracle】ORA-06502 PL/SQL数値・値エラー完全ガイド(暗黙変換で踏む典型ランタイム例外)
まとめ|コンパイル時にバグを潰しきる開発サイクル
PL/SQLの品質は「実行前にどれだけ問題を叩き出せるか」で決まります。SHOW ERRORSとUSER_ERRORSを使い分けて診断し、PLSQL_WARNINGSで潜在バグを表面化し、CI/CDで自動チェックに組み込む。この三層構造を確立すれば本番障害の7割は機械的に潰せます。本記事の要点を7項目で再確認します。
- 対話時はSHOW ERRORS+明示指定、自動化/俯瞰時はUSER_ERRORSを直接クエリ
- PLSQL_WARNINGSは最低でもENABLE:SEVEREを恒久化。新規開発はENABLE:ALL
- SEVEREで捕まるPLW-05005・PLW-06002・PLW-06019を本番前に撲滅
- 頻出PLS-エラー20種の原因パターンを覚えて対処を機械化
- PRAGMA DEPRECATEで非推奨APIの呼び出し元をコンパイル時に可視化
- CI/CDはUSER_ERRORS件数チェックで失敗判定(標準出力解析は不安定)
- リリース条件に「USER_ERRORSに行がない」を明示的に入れる
警告をOFFのまま「動くからOK」で回している現場ほど、PLSQL_WARNINGSをONにした瞬間に山のような潜在バグが見えて驚くはずです。これは悪いニュースではなく「今まで見えていなかった時限爆弾が可視化された」という良いニュース。本記事を手がかりに、警告ゼロを維持する開発文化を自プロジェクトで育てていってください。

