【要約】Oracle2PostgreSQL — Oracle→PostgreSQL 移行前の SQL / PLSQL 資産を診断・変換 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
DB移行を検討するエンジニアやSIベンダーは、膨大なSQL資産の棚卸しに苦慮している。手作業での調査は時間を要し、見積もりの精度も低いことが課題だ。
- ・大量のDDL/DML/PL/SQLの変換可否判断に多大な労力を要する。
- ・AWS SCT等の既存ツールは変換に特化しており、移行リスクの可視化が不十分である。
- ・手作業によるアセスメントは、数週間単位の工数を消費する。
// Approach
本ツールは、構文解析に基づいた構造的な変換アプローチを採用している。正規表現ではなく、SQLの構造を把握して変換を行う。
- ・AST（抽象構文木）ベースの解析を行い、文字列内の誤置換を防止する。
- ・80以上の変換ルールを用いて、データ型や関数、PL/SQLを変換する。
- ・変換結果を「AUTO/REVIEW/MANUAL」の3段階で分類し、レポート化する。
- ・GUI、CLI、Dockerの3つの実行モードを提供している。
// Result
移行プロジェクトの初期調査における工数を劇的に削減する。これにより、計画立案が迅速化される。
- ・2週間を要した手作業のアセスメントを、数時間の自動レポート生成に短縮する。
- ・未対応構文や手修正箇所を可視化し、見積もり精度を向上させる。
- ・移行リスクをHTML/CSVで示せるため、稟議や提案資料として活用できる。
Senior Engineer Insight
> 「変換」ではなく「診断」に主眼を置いた設計が実戦的だ。大規模移行では、変換の成否よりも「どこが困難か」の把握が重要となる。AST採用により、正規表現ベースのツールにありがちな誤置換リスクを低減している点も評価できる。ただし、動的SQLや複雑な階層クエリは対象外だ。これらを扱う現場では、本ツールのレポートを鵜呑みにせず、DBAによる二次検証をワークフローに組み込む必要がある。