OracleをAWSへ移行する方法と、移行先の選び方
Oracleの移行は「どこへ移すか」で難易度が変わります。Oracleのまま移すのか、別のデータベースへ移すのかで、確認すべき項目がまったく異なります。
このページは、オンプレミスのOracleをAWSへ移したいが、移行先の選択肢を整理できていない方に向けたものです。GIIPは約12万テーブルを持つオンプレミスOracle環境のAWS移行を経験しており、オブジェクト数が極端に多い環境の扱いにも対応します。
移行先の選択肢が多すぎる
Oracleのまま動かすのか、別のデータベースへ移すのか。どちらが自社に合うのかを判断する材料がありません。
PL/SQLの量が読めない
ストアドプロシージャやパッケージが業務ロジックを抱えており、どこまで移せるのかが見えません。
オブジェクトが多すぎて棚卸しが終わらない
テーブル、ビュー、シノニム、トリガーの数が多く、移行対象の一覧を作る作業自体が終わりません。
移行先ごとに前提が違う
Oracleのまま動かす場合はライセンスと構成が論点になり、別のデータベースへ移す場合はSQLとPL/SQLの書き換えが論点になります。同じ「AWS移行」でも作業内容が別物です。
依存関係が業務ロジックに埋まっている
長く使われた環境ほど、トリガーやパッケージに業務判断が入り込んでいます。移すか、外に出すかの判断が必要です。
数えないと見積もれない
オブジェクト数が多い環境では、機械的な抽出をしない限り工数の当たりすらつきません。
選択肢を並べる前に、現行環境の規模と依存関係を機械的に確定させます。
オブジェクトの機械的な棚卸し
スキーマ単位でテーブル・ビュー・シノニム・ストアド・トリガーを抽出し、移行対象の一覧と、その一覧が正しいことの根拠を作ります。
移行先の選択肢の整理
PL/SQLの量、ライセンス条件、外部連携、必要な可用性から、現実的な選択肢とそれぞれのトレードオフを提示します。
検証手順の設計
移行前後の件数・定義・依存関係の突合を、目視ではなく機械的に回せる形にします。
ご自身で先に確認できること
- Oracleのバージョンとエディション
- スキーマ数と、おおよそのテーブル数
- ストアドプロシージャ・パッケージのおおよその規模
- DBリンクや外部システムとの連携の有無
- バッチ処理の本数と実行タイミング
- 現在のライセンス契約の条件
- 業務上、何時間まで停止できるか
実績で示せること
本事例における移行先の具体的なAWSサービス構成は確認された範囲を超えるため公開していません。顧客名・業務データも公開していません。
よくあるご質問
OracleをそのままAWSへ持っていくべきですか。
PL/SQLに業務ロジックが多く入っている環境ほど、Oracleのまま動かす方が移行リスクは低くなります。一方でライセンス費用は残ります。どちらを選ぶかは技術判断だけでなく契約条件の判断でもあります。
テーブル数が多いと何が問題になりますか。
移行そのものより、移行対象を網羅的に把握し、漏れがないことを証明する工程が重くなります。目視の棚卸しでは終わらないため、抽出と突合の自動化が前提になります。
12万テーブルというのはレコード数ですか。
いいえ。テーブルの数です。レコード数でもデータベース数でもありません。
費用はどのくらいかかりますか。
規模と依存関係の広さで変わります。確認されていない金額をお伝えすることはしていません。費用を決める要素は別ページに整理しています。
自社のOracle環境の移行可否を確認する
バージョン、スキーマ数、おおよそのテーブル数、外部連携の有無をお知らせください。