Oracle-to-PostgreSQL データベース マイグレーション

references/ フォルダに記載された既知の Oracle/PostgreSQL の動作差異に対してマイグレーション リスクを浮き彫りにし、マイグレーション作業を検証します。

使用時期

1. 計画段階 — プロシージャ、トリガー、クエリ、または refcursor クライアントのマイグレーション作業を開始する前。どのリファレンス情報が該当するかを特定し、リスクを事前に対処します。
2. 検証段階 — マイグレーション作業が完了した後、適用可能なすべてのリファレンス情報が対処され、統合テストが新しい PostgreSQL セマンティクスをカバーしていることを確認します。

ワークフロー

タスクの種類を判定します：

マイグレーションを計画中ですか？ リスク評価ワークフローに従ってください。 完了した作業を検証していますか？ 検証ワークフローに従ってください。

リスク評価ワークフロー（計画段階）

Risk Assessment:
- [ ] Step 1: マイグレーション スコープを特定する
- [ ] Step 2: 各リファレンス情報の適用可能性をスクリーニングする
- [ ] Step 3: リスクと推奨アクションをドキュメント化する

ステップ 1: マイグレーション スコープを特定する

影響を受けるデータベース オブジェクト（プロシージャ、トリガー、クエリ、ビュー）および呼び出すアプリケーション コードをリストアップします。

ステップ 2: 各リファレンス情報の適用可能性をスクリーニングする

references/REFERENCE.md のリファレンス インデックスを確認してください。各エントリについて、マイグレーション スコープがそのリファレンス情報の影響を受けるパターンを含んでいるかどうかを判定します。リファレンス情報が潜在的に関連している場合にのみ、完全なリファレンス ファイルを読んでください。

ステップ 3: リスクと推奨アクションをドキュメント化する

適用可能な各リファレンス情報について、具体的なリスクと参照ファイルから推奨される修正パターンをメモします。設計判断が必要なリファレンス情報をフラグします（例：Oracle の空文字列を NULL として扱うセマンティクスを保持するか、PostgreSQL の動作を採用するか）。

検証ワークフロー（マイグレーション後）

Validation:
- [ ] Step 1: マイグレーション成果物をマッピングする
- [ ] Step 2: 適用可能なリファレンス情報を相互チェックする
- [ ] Step 3: 統合テスト カバレッジを検証する
- [ ] Step 4: 結果をゲートする

ステップ 1: マイグレーション成果物をマッピングする

マイグレーション済みのオブジェクトを特定し、変更セットを要約します。

ステップ 2: 適用可能なリファレンス情報を相互チェックする

references/REFERENCE.md の各リファレンス情報について、その動作またはテスト要件がマイグレーション作業で認識および対処されていることを確認します。

ステップ 3: 統合テスト カバレッジを検証する

テストが happy path と、適用可能なリファレンス情報で強調されている失敗シナリオ（例外、ソート、refcursor の消費、並行トランザクション、タイムスタンプなど）の両方をカバーしていることを確認します。

ステップ 4: 結果をゲートする

各適用可能なリファレンス情報が対処された、マイグレーション スクリプトが実行された、統合テストが合格したことを述べるチェックリストを返します。