 |
||||||||||
|
||||||||||
| 前のページ 1 2 3 | ||||||||||
|
||||||||||
| 移行スケジュール上の問題（移行速度） | ||||||||||
|
データ量が非常に大きい場合、データを移行する速度とサーバで作業を実施できる「停止可能時間」との兼ね合いを判断する必要があります。アクセラテクノロジの場合、アプリケーションの停止可能期間はせいぜい数日であり、その間に1億件以上のデータを移行せねばならないというかなり難しい条件です。当初、SQL*Loaderのダイレクトモードでなければ実現不可能と考えたのもこの処理時間を想定してのことだったのです。 移行方法を検討する段階で、SQL*Loaderの使用を諦めざるを得なかったため、その移行速度が問題となりました。結果的にPerlスクリプトを採用できたのは、環境を独立し、PostgreSQLとOracleを並行稼働する目処がついて、移行速度に許容する幅が増えたことが最大の理由です。 最終的にはアプリケーションは停止せず（極小の停止はありえるが、ユーザには影響しない程度にとどめる）、PostgreSQLとOracleを同時に稼動させてデータを移行しつつ、アプリケーションの動作結果が変わらない方法を選択するに至りました（ここでも重要な役割を果たしたのは移行処理で生まれる差分をアプリケーションが吸収するという点）。 新旧の環境が物理的に独立したハード構成であること、アプリケーションの変更が短時間で柔軟に行える状況にあったことがこの選択を可能にしたのです。 最初に社内に擬似環境を作ってデータ移行の速度をシミュレートした時、処理時間の長さ（遅さ）に閉口しました。ネックとなっていたPostgreSQLのインデックス検索速度を大きく上げることは基本的に不可能なため、対処として以下の点を行いました。
表6：対処法
実際の移行環境でのネットワーク速度などを加味し、上記対策によってなんとか許容範囲内の移行速度を得られることが確認できました。 このように移行方法の決定までに実環境に近い状態でテストを行い、その処理速度を見積もることが重要です。 |
||||||||||
| 移行を終えるまで | ||||||||||
|
実際の移行速度はテスト以上に良好で同時に稼働する運用中のアプリケーションの動作を妨げることなく、着実に進めることができました。アプリケーションを同時稼働する必要からOracle側ではデータが揃う前からインデックスを作成してありました。 そのため、後半ペースは多少落ちたものの、全体としては予想以上のペースだったといえます。データ移行終了後にはアプリケーションをOracleのみにし、PostgreSQLを切り離す処理を行って移行作業を締めくくっています。現在は安定して稼働を続けており、PostgreSQLでは実現できなかった新たなビジネス展開への着手をはじめています。 データ件数が1億件以上というかなり大規模なPostgreSQLをOracleに移行した今回の例ですが、成功に導いた最大のポイントは「アプリケーションの柔軟な対応」であったように感じています。 |
||||||||||
| その他の注意点 | ||||||||||
|
その他の注意点としては以下の2点を紹介します。
表7：その他の注意点
|
||||||||||
| PostgeSQLとOracleのデータサイズ | ||||||||||
|
PostgreSQLでのデータベース（クラスタ）の占めるサイズとOracleのデータファイルなどが占める領域の違いを理解しておくことが重要です。
表8：データサイズの注意点 |
||||||||||
| 移行方法の注意 | ||||||||||
|
Perl、DBI+DBDといった方法に限らず、スクリプトなどを用いてデータを移行する場合も、一度テキストファイルに出力するときやクライアントに当たる部分の文字コードには十分注意しましょう。文字化け発生の原因となります。 本題では並行稼働可能な環境が使用できたのですが、サーバが2台ないと移行できないわけではないのはご承知の通りです。サーバ1台で環境を構築し直す場合、バックアップ取得、トラブル時の復旧時間を見越したスケジュールと現場の判断が重要となります。 |
||||||||||
|
前のページ 1 2 3 |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
-
-
連載
