TOP
＞
業務システム
＞ 移行スケジュール上の問題（移行速度）
勝ち組に学ぶシステム導入事例
第３回:大手ブログ検索サイトがPostgreSQLからOracleへ移行を決断した理由（後編）
著者：
ミラクル・リナックス 高橋 強
2006/4/13
前のページ
1
2
3
移行スケジュール上の問題（移行速度）
データ量が非常に大きい場合、データを移行する速度とサーバで作業を実施できる「停止可能時間」との兼ね合いを判断する必要があります。アクセラテクノロジの場合、アプリケーションの停止可能期間はせいぜい数日であり、その間に1億件以上のデータを移行せねばならないというかなり難しい条件です。当初、SQL*Loaderのダイレクトモードでなければ実現不可能と考えたのもこの処理時間を想定してのことだったのです。
移行方法を検討する段階で、SQL*Loaderの使用を諦めざるを得なかったため、その移行速度が問題となりました。結果的にPerlスクリプトを採用できたのは、環境を独立し、PostgreSQLとOracleを並行稼働する目処がついて、移行速度に許容する幅が増えたことが最大の理由です。
最終的にはアプリケーションは停止せず（極小の停止はありえるが、ユーザには影響しない程度にとどめる）、PostgreSQLとOracleを同時に稼動させてデータを移行しつつ、アプリケーションの動作結果が変わらない方法を選択するに至りました（ここでも重要な役割を果たしたのは移行処理で生まれる差分をアプリケーションが吸収するという点）。
新旧の環境が物理的に独立したハード構成であること、アプリケーションの変更が短時間で柔軟に行える状況にあったことがこの選択を可能にしたのです。
最初に社内に擬似環境を作ってデータ移行の速度をシミュレートした時、処理時間の長さ（遅さ）に閉口しました。ネックとなっていたPostgreSQLのインデックス検索速度を大きく上げることは基本的に不可能なため、対処として以下の点を行いました。
稼働プロセスの並列化
移行処理の別サーバ稼働（DBサーバの負荷軽減）
表6：対処法
実際の移行環境でのネットワーク速度などを加味し、上記対策によってなんとか許容範囲内の移行速度を得られることが確認できました。
このように移行方法の決定までに
実環境に近い状態でテストを行い、その処理速度を見積もることが重要
です。
移行を終えるまで
実際の移行速度はテスト以上に良好で同時に稼働する運用中のアプリケーションの動作を妨げることなく、着実に進めることができました。アプリケーションを同時稼働する必要からOracle側ではデータが揃う前からインデックスを作成してありました。
そのため、後半ペースは多少落ちたものの、全体としては予想以上のペースだったといえます。データ移行終了後にはアプリケーションをOracleのみにし、PostgreSQLを切り離す処理を行って移行作業を締めくくっています。現在は安定して稼働を続けており、PostgreSQLでは実現できなかった新たなビジネス展開への着手をはじめています。
データ件数が1億件以上というかなり大規模なPostgreSQLをOracleに移行した今回の例ですが、成功に導いた最大のポイントは
「アプリケーションの柔軟な対応」
であったように感じています。
その他の注意点
その他の注意点としては以下の2点を紹介します。
PostgeSQL、Oracleのデータサイズ
移行方法の注意
表7：その他の注意点
PostgeSQLとOracleのデータサイズ
PostgreSQLでのデータベース（クラスタ）の占めるサイズとOracleのデータファイルなどが占める領域の違いを理解しておくことが重要です。
Oracle
表領域は対応するデータファイルを「入れ物」として先に領域を占有します。自動拡張の機能があるので厳密ではないにしろ、先にある程度の領域を見積もることが必要です。
PostgeSQLでは、存在しない管理用の表領域なども複数存在することも忘れてはなりません。この領域も最初から見積もりに含めることが必要です。
PostgreSQL
1つの表サイズは外部からでは判断できないことを理解する必要があります。TEXT型などは圧縮がかかるので移行すると元ファイルの見た目以上のサイズとなることがあります。さらには、VACUUM（FULL）を実行していない場合には、不要な領域を抱え込んでいる可能性もあるため、逆に思った以上にデータサイズが小さいこともあり得るのです。
見た目にだまされないようにしましょう。
表8：データサイズの注意点
移行方法の注意
Perl、DBI+DBDといった方法に限らず、スクリプトなどを用いてデータを移行する場合も、一度テキストファイルに出力するときやクライアントに当たる部分の文字コードには十分注意しましょう。文字化け発生の原因となります。
本題では並行稼働可能な環境が使用できたのですが、サーバが2台ないと移行できないわけではないのはご承知の通りです。サーバ1台で環境を構築し直す場合、
バックアップ取得、トラブル時の復旧時間を見越したスケジュールと現場の判断が重要
となります。
前のページ
1
2
3
著者プロフィール
ミラクル・リナックス株式会社 高橋 強
1993年某SIベンダへ入社後、Oracle、DB関連のコンサルティング、チューニング、社内案件の技術支援などを10年ほど担当。2004年ミラクル・リナックス株式会社へ入社。
INDEX
第3回:大手ブログ検索サイトがPostgreSQLからOracleへ移行を決断した理由（後編）
はじめに
データ型とそのサイズの問題
移行スケジュール上の問題（移行速度）
