oracle 11gから19cに行こうする場合、sqlの修正調査と移行の手順は？

oracle 11gから19cに行こうする場合、sqlの修正調査と移行の手順は？

いいテーマですね。11g→19cは単なる「バージョンアップ」じゃなくて、SQLの挙動も含めて結構世界が変わります。ざっくり「SQLの修正調査」と「移行手順」に分けて整理します。

---

SQL修正調査のポイント

1. 非推奨・廃止機能の洗い出し

• ドキュメント確認:
  Deprecated and Desupported Features for Oracle Database 19c を必ず一度通読しておくと、「そもそも使えなくなるもの」が見えます。 docs.oracle.com

  • 廃止された初期化パラメータ
  • 使えなくなったオプション・コンポーネント
  • 変更された構文や機能

• 対象になりやすいものの例:

  • 古いジョイン構文（(+)）を多用しているアプリ
  • RULEヒントなど、既に非推奨のオプティマイザヒント
  • 古い暗号化/認証方式、ネットワーク関連設定

2. 互換性レベルとCOMPATIBLEパラメータ

• COMPATIBLEの確認:

  • 11g側で show parameter compatible; で現在値を確認。
  • 19cにアップグレード後も、テスト完了まではCOMPATIBLEをすぐに19に上げない、というのがOracle推奨です。 docs.oracle.com

• 意味合い:

  • COMPATIBLEを上げると「元に戻せない」形式変更が有効になることがあるので、SQLやアプリのテストが終わるまで待つのが安全です。

3. SQLの挙動変化（オプティマイザ・プラン）

• オプティマイザの世代差:

  • 11gと19cではコストベースオプティマイザのアルゴリズムや統計の扱いがかなり変わっています。
  • 同じSQLでも実行計画が変わり、性能劣化が起きる可能性があります。

• やるべきこと:

  • 代表的なバッチ・重いSQLのリストアップ（AWR/ASH、SQLトレースなどから）
  • テスト環境で19cに移行し、実行計画の比較（DBMS_XPLAN.DISPLAY_CURSORなど）
  • 必要に応じて
    • SQL Plan Baseline
    • ヒントの見直し
    • 統計の取り方（DBMS_STATS）の調整

4. 予約語・構文変更のチェック

• 予約語の追加:

  • 12c以降で追加されたキーワードが、アプリのカラム名・テーブル名と衝突していないかを確認。
  • 例：CONTAINER, PDB, OFFSET など、SQLで普通に使いそうな単語が予約語化していることがあります。

• チェック方法:

  • スキーマ定義を抽出して、予約語リストと突き合わせる（スクリプトで半自動化することが多い）。
  • コンパイルエラー（PL/SQL）を19cテスト環境で一括コンパイルして洗い出す。

5. PL/SQL・パッケージの互換性

• 標準パッケージの仕様変更:
  • UTL_FILE, DBMS_JOB（→DBMS_SCHEDULER推奨）など、仕様や推奨パスが変わっているものを確認。
• 対応:
  • 19c環境で全オブジェクトを UTL_RECOMP や @utlrp.sql で再コンパイルし、エラーを一覧化して修正。

---

11g→19c 移行の全体手順イメージ

ここでは「典型的なオンプレ11g非CDB → 19c非CDB or CDB」の流れをイメージとして書きます。実際にはOSや構成で細かく変わるので、Oracle Database 19c データベース・アップグレード・ガイドを必ず参照してください。 docs.oracle.com ORACLE-BASE

1. 事前計画・調査

• バージョン・パスの確認:
  • 11gのマイナーバージョンから19cまで、直接アップグレード可能かを確認（必要なら中間バージョンを挟む）。
• 方式の選定:
  • インプレースアップグレード（同じDBをそのまま19cに上げる）
  • データ移行型（Data Pump (expdp/impdp), Transportable Tablespace, GoldenGateなど） Oracle
  • ダウンタイム許容度・データ量・再構築のしやすさで決める。

2. 19cソフトウェアのインストール

• 新ORACLE_HOMEの用意:
  • 既存11gとは別ディレクトリに19cをインストール。
  • パッチ適用（RU/RUR）もこのタイミングで。

3. 事前チェック（preupgrade）

• preupgrade.jarの実行:
  • Oracle提供の preupgrade.jar を11g側で実行し、
    • 必要な初期化パラメータ変更
    • 無効オブジェクト
    • 互換性上の注意点
      をレポートさせる。 ORACLE-BASE
• 指摘事項の対応:
  • 表領域サイズ不足の解消
  • 不要コンポーネントの削除
  • 統計の収集など

4. アップグレード or 移行の実行

パターンA：インプレースアップグレード（DBUA or 手動）

• 手順イメージ:
  1. DBをクローズ・バックアップ取得
  2. 19c ORACLE_HOMEから DBUA を起動するか、手動で STARTUP UPGRADE → catctl.pl 等でアップグレード実行
  3. アップグレードログの確認

パターンB：Data Pumpによる移行

• 手順イメージ:

  1. 11g側で expdp（スキーマ単位 or フル）
  2. 19c側で空DBを作成（CDB/PDB構成をどうするかもここで決める）
  3. 19c側で impdp 実行
  4. インポート後に統計収集・インデックス再構築など

• メリット:

  • オブジェクトを「きれいに」作り直せる
  • 不要スキーマ・オブジェクトを整理しやすい

5. ポストアップグレード作業

• 再コンパイル:
  • @utlrp.sql でPL/SQL等を一括再コンパイル。
• 統計の再収集:
  • DBMS_STATS.GATHER_DATABASE_STATS などで最新統計を取得。
• 機能確認:
  • バッチ、オンライン処理、レポートなど、代表的な業務フローを実行して性能・機能を確認。
• COMPATIBLEの最終設定:
  • テストが問題なければ、COMPATIBLE を19c推奨値に引き上げる（再起動が必要）。

---

SQL修正調査の進め方（現実的なステップ）

1. 重要SQLの棚卸し:

   • AWR/Statspackなどから「よく実行される」「重い」SQLを抽出してリスト化。

2. テスト環境で19cにアップグレード or 移行:

   • 本番と同じデータ量に近づけると、プラン変化が見えやすいです。

3. 実行計画と性能比較:

   • 11gと19cで同じSQLの実行計画・実行時間を比較。
   • 劣化したものだけを重点的にチューニング（ヒント、インデックス、統計、SQL Plan Baselineなど）。

4. コンパイルエラー・予約語衝突の洗い出し:

   • 全オブジェクト再コンパイル → エラー一覧化 → 修正。
   • スキーマ定義と予約語リストの突き合わせ。

---

もし、今の環境（11gのバージョン、OS、CDB/PDBの希望、ダウンタイム制約など）が分かれば、「あなたのケース向けの現実的なパターン」をもう少し具体的な手順書っぽく落とし込めますが、まずはこの全体像をベースに計画を組むのが良いと思います。