Oracle移行、最初の分岐と権限の罠 — RDS for Oracleで最初につまずくところ

Oracle移行の相談で最初に確認するのは、テーブル定義でもデータ量でもなく「SYSやDBA権限で何をしているか」です。Oracleは強力な権限モデルを持つぶん、それに寄りかかった運用がクラウドの制約とぶつかります。この記事では、移行方式の最初の分岐と、権限まわりで実際につまずく点を順に見ていきます。

01まず最初の分岐 — 同一エンジンか、作り替えか

Oracle移行は、この判断で難易度が数倍変わります。先に決めないと、後の全工程が揺れます。

• RDS for Oracle — マネージド。パッチ・バックアップ・冗長化をAWSが持つ。運用は最も楽だが、後述のとおりSYSDBA権限がないなど制約がある
• EC2上のOracle — 従来どおりのフルコントロール。SYSDBAも使える。制約に縛られたくない・特殊構成があるならこれ。ただし運用は全部自前
• Aurora PostgreSQL等への作り替え（re-engine） — ライセンス費が消えるリターンは大きいが、PL/SQLの書き換えと全ロジックの再テストが必要。ストアド中心バッチの記事で触れたとおり「移行のついで」の規模ではない

02RDS for Oracle 最大の制約 — SYSDBAがない

RDS for Oracleを選んだとき、オンプレのDBAが最初に戸惑うのがこれです。マネージドサービスなので、SYSやSYSTEMでの直接ログイン（SYSDBA接続）ができません。マスターユーザーという専用の管理アカウントが与えられ、管理操作はAWSが用意したパッケージ経由で行います。

この前提で見直しが必要になる典型は次のとおりです。

• SYS所有オブジェクトを直接いじる運用スクリプト → 使えない。標準のパッケージ手続きに置き換え
• UTL_FILEでサーバのローカルディレクトリにファイル出力 → RDSはOS層に触れないため、DIRECTORYオブジェクト＋RDS管理領域、またはS3連携に置き換え
• OSコマンド実行・外部プロシージャ → 呼び出し側（EC2/Lambda）に処理を移す
• 特定の管理系パッケージ・機能で制限があるものがある → 事前に利用機能の棚卸しを

03権限の罠① — ロール経由の権限はストアド内で効かない

これはOracleに不慣れな移行担当が最もハマる点です。Oracleでは、ロールで付与した権限は、定義者権限（definer's rights）のPL/SQL内では有効になりません。オンプレで「開発ロールに一括で権限を付けて、みんなそれで動いている」環境をそのまま移行すると、ユーザーが直接叩くSQLは動くのに、ストアドプロシージャ経由だと権限不足で落ちる、という現象が起きます。

正確には移行で新たに壊れるというより、オンプレでは「たまたま直接grantも入っていて動いていた」ケースが、権限を整理して移行した瞬間に露見します。対策は、ストアドが必要とするオブジェクト権限は、ロールではなく所有ユーザーに直接grantすること。移行を機に権限の依存関係を棚卸しするのが正道です。

04権限の罠② — PUBLICシノニム・共有スキーマ・DBA依存ジョブ

• PUBLICシノニム — アプリが「スキーマ名なしのオブジェクト名」で動いている場合、裏でPUBLICシノニムに依存していることが多い。移行時に作られていないと、アプリ全体が「表が見つからない」で沈黙する。エクスポート対象に含まれているか必ず確認
• SYSTEM/SYSスキーマにアプリのオブジェクトを置いている — 行儀の悪い構成だが現場には実在する。これらはスキーマ単位の移行から漏れやすいので、事前の棚卸しで拾う
• DBMS_SCHEDULER/DBMS_JOBの定期ジョブ — DB内で回っているジョブは、テーブルと一緒には移行されないことがある。ジョブ定義を別途エクスポートし、移行先で再作成。ジョブ管理の記事の考え方と同じで、「DBの中のバッチ」も棚卸し対象です

05表領域（tablespace）の罠

オンプレのデータファイルは特定パス・特定の表領域構成に紐づいています。移行先で同じ表領域が存在しないと、インポートが失敗するか、意図しない場所にオブジェクトが作られます。

• 移行先で表領域を事前に作成しておく、またはData PumpのREMAP_TABLESPACEで移行先の表領域名に読み替える
• RDS for Oracleでは表領域のデータファイルパスはAWS管理下なので、オンプレのパス前提の運用は手放す
• USERSやSYSTEM表領域にアプリデータが同居していないか（これも行儀の悪い構成の定番）を確認

06手番としての権限移行 — 「先に流して、検証する」

権限まわりは、データより先に整理・移行するのが安全です。おおまかな手番は次のとおりです。

• ① ユーザー・ロール・権限・シノニム・表領域を棚卸し（何がロール経由で、何が直接grantか）
• ② 移行先に表領域とユーザー、ロールと直接grantを再現（ストアド用は直接grantを忘れずに）
• ③ Data Pumpでスキーマ単位に移行（INCLUDE/EXCLUDEで対象を制御）
• ④ 検証：直接SQLだけでなくストアド経由・PUBLICシノニム経由・定期ジョブまで動かして確認

「テーブルとデータは移ったが、権限とシノニムで数日溶かす」——これがOracle移行で最も多い遅延パターンです。権限を移行の後回しにせず、設計フェーズの主役の1つとして扱ってください。

—まとめ

Oracle移行は、まず「同一エンジンか作り替えか」を決め、RDSなら「SYSDBAがない前提」で運用を見直す。そして権限——ロールとストアドの関係、PUBLICシノニム、DB内ジョブ、表領域——を、データより先に棚卸しして移行する。テーブル定義は自動で運べても、権限の依存関係だけは人が読み解くしかありません。ここに時間を使うことが、Oracle移行を予定どおり終わらせる最大のコツです。次は古いOracleからの移行手番と文字コード変換を。