古いOracleをAWSへ — バージョン飛び越しの手番と文字コード変換の罠

「10年動いているOracle 11g（あるいはもっと古い版）をAWSに」——これはただのデータ移行ではなく、バージョンアップと文字コード変換が同時に絡む複合作業です。順番を間違えると、テスト移行で初めて文字化けや桁あふれが発覚し、計画が総崩れになります。古いOracle特有の手番を、罠とセットで示します。

01古いOracleは「直接は上がれない」

まず知っておくべき前提です。Oracleには直接アップグレードできる最小バージョンの条件があり、非常に古い版（例：9i・10g）から最新版へは一足飛びにできません。途中のバージョンを経由する「踏み石アップグレード」が必要になります。

022つの道 — In-placeアップグレードか、Data Pumpか

古いOracleをAWSへ運ぶ道は大きく2つです。

• 踏み石アップグレード（In-place） — 現行DBを段階的に新バージョンへ上げてから移す。既存の構成をそのまま保てるが、踏み石の数だけ手間とリスクが増える
• Data Pump（expdp/impdp）でエクスポート＆インポート — 古い版でエクスポートし、新しい版にインポートする論理移行。バージョンをまたぐ柔軟性が高く、古いOracleからの移行では実質こちらが主役になることが多い

Data Pumpにはバージョン互換の考え方があり、エクスポート時にVERSIONパラメータで出力の互換レベルを指定できます。ただし版が離れすぎると直接は渡せず、中間バージョンを経由する必要があるため、ここでも現行版と目標版の組み合わせ確認が先です。

03さらに古い版はexp/imp — Data Pump以前の世界

Data Pump（expdp/impdp）はOracleのある世代以降の機能です。それより前の非常に古いOracleでは、旧来のexp/imp（クラシックエクスポート）を使うことになります。ここで注意なのが、exp/impとData Pumpは別物で互換がないこと、そして「古い版でexpしたダンプを、新しい版のimpで取り込めるか」には版の組み合わせ制約があることです。

実務では、非常に古い版はまず「exp/impやアップグレードで扱える中間バージョンまで持ち上げ、そこからData Pumpで目標版へ」という多段の手番になります。この段数を最初に確定させることが、古いOracle移行の計画づくりの肝です。

04最大の罠 — 文字コード（JA16SJIS → AL32UTF8）

日本の古いOracleは、データベースキャラクタセットがJA16SJISやJA16SJISTILDEであることが少なくありません。移行を機にAL32UTF8（Unicode）へ変換するのが今日の標準ですが、この変換には日本語特有の地雷があります。

• 波ダッシュ／全角チルダ問題 — 「〜」の文字が、Shift-JIS系とUnicodeでコードポイントの対応が食い違い、変換方式によって別の文字に化ける。JA16SJIS と JA16SJISTILDE のどちらだったかで挙動が変わる
• 機種依存文字・外字 — 丸数字やローマ数字、業務で登録された外字が、変換先で欠落・化けする
• そもそも不正なデータ — 長年の運用で、宣言と違う文字コードのバイト列が紛れ込んでいることがある。これは変換時に初めて露見する

05桁あふれの罠 — ORA-12899

文字コード変換とセットで必ず来るのが、これです。多くの古いOracleは列長をバイトで数えています（VARCHAR2(10)＝10バイト）。日本語1文字はShift-JISで2バイト、UTF-8では3バイトになるため、AL32UTF8へ変換するとデータのバイト長が膨らみ、「value too large for column（ORA-12899）」でインポートが弾かれる行が出ます。

• 事前に「変換後のバイト長が列定義を超えるデータ」を洗い出す（Oracleの文字コード診断ツール等で事前アセスメント可能）
• 列定義を文字数セマンティクス（CHAR単位）に変える、または列長を広げる
• どちらを採るかは影響範囲で決める。アプリ側が桁数を前提にしている場合もあるので、DBだけで完結しないことがある

この桁あふれの洗い出しを飛ばすと、テスト移行のインポートが大量のエラーで止まり、そこから列定義修正→再テストの往復で日程が崩れます。文字コード変換を決めた瞬間に、桁あふれ調査は必須タスクだと考えてください。

06古いOracle移行の手番まとめ

ここまでを、実行順に並べます。この順番自体が古いOracle移行の設計です。

• ① アセスメント — 現行版・パッチレベル・キャラクタセット・廃止機能・DB内ジョブ・そして桁あふれ候補を洗い出す
• ② 目標構成の決定 — RDS for Oracle / EC2 Oracle / 作り替えのどれか（分岐と権限の記事）、目標版、キャラクタセットはAL32UTF8
• ③ 移行経路の確定 — 直接上がれるか、踏み石が何段要るか、Data Pumpかexp/impか。ここを公式マトリクスで確定
• ④ 事前修正 — 桁あふれデータの手当て、不正文字の是正、廃止機能への依存の解消
• ⑤ テスト移行と検証 — 件数照合、チェックサム、そして文字化けの目視確認まで。権限・シノニム・ジョブの動作確認も
• ⑥ 本番移行 — 停止許容時間から逆算した切替（移行の5決定）。ツールはDMS/Data Pump等の使い分けを。データ量が大きければ初回転送は転送時間ツールで試算

—まとめ

古いOracleの移行は、バージョンアップ・文字コード変換・桁あふれという3つの罠が同時に来る複合作業です。だからこそ手番が全てで、アセスメントで版・文字コード・桁あふれを先に確定させ、経路（踏み石の段数とData Pump/exp）を公式マトリクスで決め、事前修正を済ませてからテスト移行に入る。この順番を守れば、古いOracleでも移行は計画どおり終わります。逆に、いきなりテスト移行から始めると、文字化けと桁あふれで必ず出戻ります。全体の位置づけは移行の全体フローのPhaseやDB方式決定の中で捉えてください。