【PL/SQL】コンパイル時エラーと警告の完全対処ガイド|SHOW ERRORS・USER_ERRORS・PLSQL_WARNINGS・CI/CD検出

【PL/SQL】コンパイル時エラーと警告の対処法|SHOW ERRORS・USER_ERRORSの使い方 PL/SQL

PL/SQLを書いていて最初にぶつかる壁の一つがコンパイルエラーコンパイル警告の読み解きです。OracleのコンパイラはWarning: created with compilation errorsという味気ないメッセージを返すだけで、原因は別のビューから自分で引き出す必要があります。SHOW ERRORSUSER_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-04063ORA-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で指定するのが鉄則です。

SHOW ERRORSの実践的な使い方
-- ❌ 引数なし:直前コンパイルのみ表示、別オブジェクトを触ると失う
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権限)を直接クエリすれば一覧として診断できます。

主要カラム

  • NAMETYPE:オブジェクト名と種別(PROCEDURE・PACKAGE BODY等)
  • SEQUENCE:同一オブジェクト内のエラー順番
  • LINEPOSITION:発生行とカラム(IDE連携で便利)
  • TEXT:エラーメッセージ本体(PLS-00201など)
  • ATTRIBUTEERRORWARNINGの区別
  • MESSAGE_NUMBER:PLS番号の数値部分(CIフィルタに便利)
USER_ERRORSの実務クエリ集
-- 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レベルで運用するのが実務的です。

PLSQL_WARNINGSの設定パターン
-- 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を有効化すると、こんなバグが本番前に検出できます。いずれも実行時ほぼ確実に問題になる書き方で、警告オフだとすり抜けてしまうのが怖いポイントです。

SEVEREで捕まる実例
-- ① PLW-06002: 到達不能コード
CREATE OR REPLACE FUNCTION f_status(p NUMBER) RETURN VARCHAR2 AS
BEGIN
  IF p > 0 THEN RETURN 'POS';
  ELSIF p &lt; 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&lt;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 &lt;=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が警告として出るため、社内ライブラリの移行計画を進める武器になります。

PRAGMA DEPRECATEで旧関数への呼び出しを警告化
-- パッケージ仕様で非推奨宣言
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の件数を終了コードで判定するのが鉄則です。

CI/CDで使えるコンパイルチェックスクリプト例
-- 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
GitHub Actionsに組み込む例
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_PRIVSALL_OBJECTSで確認するのが先決。ロール経由の権限はパッケージ内から見えないのでダイレクトGRANTが必要な場面があります。

⑥ 非推奨関数を放置しPRAGMA DEPRECATEを使わない

コメントで「使わないで」と書くだけでは呼び出されるたびに気づけません。PRAGMAで警告化すればUSER_ERRORSで使用箇所を機械的に一覧化でき、「本当に消して大丈夫か」が判断できるようになります。

よくある質問

QSHOW ERRORSとUSER_ERRORSはどちらを使うべき?
A用途で使い分けます。対話的にコードを書いている最中はSHOW ERRORSが手軽です(SQL*Plus/SQLclで直接見える)。一方、複数オブジェクトの状態を俯瞰したい・自動化したい・別セッションで発生したエラーを調べたい場合はUSER_ERRORSを直接クエリします。大原則は人間が眺めるときはSHOW ERRORS、スクリプトで扱うときはUSER_ERRORSです。
QPLSQL_WARNINGSを既存プロジェクトで有効化したら警告が大量に出ます
AまずはENABLE:SEVEREだけに絞って有効化し、SEVEREのみ解消する段階的運用を推奨します。PERFORMANCEとINFORMATIONALは確かに大量に出るため一気にONにすると作業が止まります。SEVEREがゼロになったら次にPERFORMANCE、最後にINFORMATIONAL、という順で徐々に厳格化するのが現実解です。
Qコンパイル時の警告とランタイム例外はどう違いますか?
A警告はコンパイラが静的解析で検出する潜在問題、ランタイム例外は実行時に動的に発生するエラーです。警告は実行しなくても検出できるため「リリース前の保険」として活用、ランタイム例外はEXCEPTION句での処理が必要です。PL/SQL例外処理の詳細は別記事を参照してください。
QUSER_ERRORSが空なのにパッケージが動かない
A可能性は2つ。①実行時エラー(ランタイム例外)→USER_ERRORSには出ない。v$diag_alert_extやアプリログでORA-XXXXXを確認。②依存先がINVALID→自身はVALIDだが依存先が壊れているため呼び出した瞬間にORA-04063が出る。USER_OBJECTSSTATUS列で依存先を確認してください。
Q警告をエラー扱いにしたら既存コードが全滅します
Aパッケージ単位で警告設定を分離できます。ALTER PACKAGE X COMPILE PLSQL_WARNINGS='ENABLE:SEVERE' REUSE SETTINGSで既存コードは緩く、新規コードは厳しく、という段階的導入が可能です。CI/CDでも新規追加ファイルだけ厳格化してdiff対象外ファイルは緩くする方法も有効です。
QPLS-00201が権限不足かどうやって確認しますか?
A次の順で調べます。①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;で無視されない権限を確認します。
Qコンパイル時エラーが修正できず詰みました
AEDIT XでSQL*Plusのバッファを開いて再確認、②USER_ERRORSLINE/POSITIONを原文と突合、③エラーの前行を疑う(セミコロン抜けは次行でPLS-00103になる)、④依存先のINVALIDUTL_RECOMPで先に回復、⑤それでも解決しない場合はALL_SOURCEからコードを再取得して環境差異の可能性を探る。依存関係の再コンパイルについては依存オブジェクトとINVALID再コンパイルの制御の記事が詳しいです。
QPRAGMA DEPRECATEのサポートバージョンは?
AOracle 12.2以降で使えます。12.1以前では代替としてDBMS_WARNING.ADD_WARNING_SETTING_CATで個別警告設定を管理する方法がありますが、機能範囲は限定的なのでバージョンアップが一番確実です。サポート終了済みの12.1以前を使っているなら、移行の良い動機にもなります。
QPL/SQLネイティブコンパイル時のエラー対処は違いますか?
A基本は同じでUSER_ERRORSに出ます。PLSQL_CODE_TYPE=NATIVEでコンパイルした場合のみ外部Cコンパイラのエラー(PLS-00801系)が追加で発生する可能性があります。これが出たらPLSQL_NATIVE_LIBRARY_DIRの設定を確認、それでも解決しなければPLSQL_CODE_TYPE=INTERPRETEDに戻すのが先決です。
Q警告番号(PLW-XXXXX)と動作の対応表はどこにありますか?
AOracle公式の「Database Error Messages」ドキュメントにPLW-で始まる全メッセージの説明があります。主要な警告だけ押さえるなら本記事の「頻出PLS-エラー早見表」のPLW-05005/PLW-06002/PLW-06019の3つと、PLW-07203(暗黙型変換)、PLW-07204(NULL比較)を覚えれば実務の8割をカバーできます。

関連記事で知識を深める

PL/SQLの品質向上と運用安定化に効く関連記事です。

まとめ|コンパイル時にバグを潰しきる開発サイクル

PL/SQLの品質は「実行前にどれだけ問題を叩き出せるか」で決まります。SHOW ERRORSとUSER_ERRORSを使い分けて診断し、PLSQL_WARNINGSで潜在バグを表面化し、CI/CDで自動チェックに組み込む。この三層構造を確立すれば本番障害の7割は機械的に潰せます。本記事の要点を7項目で再確認します。

  1. 対話時はSHOW ERRORS+明示指定、自動化/俯瞰時はUSER_ERRORSを直接クエリ
  2. PLSQL_WARNINGSは最低でもENABLE:SEVEREを恒久化。新規開発はENABLE:ALL
  3. SEVEREで捕まるPLW-05005・PLW-06002・PLW-06019を本番前に撲滅
  4. 頻出PLS-エラー20種の原因パターンを覚えて対処を機械化
  5. PRAGMA DEPRECATEで非推奨APIの呼び出し元をコンパイル時に可視化
  6. CI/CDはUSER_ERRORS件数チェックで失敗判定(標準出力解析は不安定)
  7. リリース条件に「USER_ERRORSに行がない」を明示的に入れる

警告をOFFのまま「動くからOK」で回している現場ほど、PLSQL_WARNINGSをONにした瞬間に山のような潜在バグが見えて驚くはずです。これは悪いニュースではなく「今まで見えていなかった時限爆弾が可視化された」という良いニュース。本記事を手がかりに、警告ゼロを維持する開発文化を自プロジェクトで育てていってください。