月曜日 6 11, 2012

構築事例:PostgreSQLからOracle RACへの移行

他社のシステム構成や設計時の考え方、利用した技術などは、なかなか目にする機会は無いかと思います。
そこで今回は、株式会社アクアシステムズ 篠田 靖 様より、実際に関わったシステムの構築事例をご紹介いただきました。
*   *   *
 スモールスタートしたシステムが成長するなどした場合に、それまで利用していたDBMSが最適ではなくなることがあります。今回は、ある大手流通業でのDBMS移行を題材に、データベース移行でどのような作業が必要になるかを紹介していきたいと思います。

1. 事例紹介
 事例として紹介するシステムは、大手流通業者の営業支援システムです。元々は、一店舗内で試行的に開発されたものでしたが、好評を博して、試行経過1年後、全店舗展開を計画するが立案されました。

 開発当初、全店舗展開は考慮されておりませんでした。そのためDBは簡単に使えるOSSのPostgreSQLを採用し、APサーバーもDBサーバーも同じ筐体にインストールした簡単な構成でした。
aqua_asm1
 ユーザーは10名程度、データサイズは数十GB程度、サービス時間も限定されており、バックアップも夜間にDBを停止し、コールドバックアップするという運用でした。

 新システムはユーザー数が約3,500名、サービス時間も24時間となるため、高いスケーラビリティと可用性が求められることになりました。

 まずAPサーバーを分離し、並列化することによってスケーラビリティ向上を図ることにしました。DBは、PostgreSQLをリプレイスする方向で検討しました。PostgreSQL は追記型ファイル構造を持つために定期的なVacuumというメンテナンス処理が必要になります。高トランザクションにさらされるようになった場合に、ボトルネックにな る可能性が高いと判断しました。また、PostgreSQLはOSSでしたので、全店舗展開するにあたってはサポート体制に不安がありました。非機能要件を満たすことができるDB MS製品として、Oracle Database 11gR2を採用することになりました。初期データサイズが500GB程度と比較的大きく、年々成長することが予想されたため、Partitioning 機能を利用できる Oracle Database Enterprise Editionが最適と判断されたことと、他システムでの実績でサポートの対応がよかったことがポイントでした。

 可用性はRAC構成として確保することにしました。
aqua_asm1
2. 技術的課題
2.1. データ型
 PostgreSQLのデータ型はOracleで対応するデータ型が存在するものがほとんどですので、機械的な変換で対応できることが多いです。ただし、可変長のTEXT型について は実際に入っているデータの桁数を意識してOracleのデータ型を定義する必要があります。データの移行は、PostgreSQLからcsv形式で出力し、Oracle DatabaseのSQL*Loaderで投入することにしました。

 この事例では問題ありませんでしたが、テキスト形式にする場合、DBサーバーのプラットフォームがWindowsとLiunxでは改行コードが違いますので注意が必要です。ま た、両データベース間で使われているキャラクターセットの違う場合、移行の際に変換する必要があります。 データ型ではありませんが、PostgreSQLはNULLと空文字「''」は別物として扱います。Oracle Databaseでは同じものとして扱いますので、注意が必要です。

主なデータ型の変換表
カテゴリ PostgreSQL Oracle Database
文字型 CHAR(n) CHAR(n),CLOB
VARCHAR(n) VARCHAR2(n),CLOB
TEXT CLOB
数値型 NUMERIC NUMBER
INTEGER NUMBER
SMALLINT NUMBER
BIGINT NUMBER
REAL NUMBER
DOUBLE PRECISION NUMBER
日付型 DATE DATE
TIMESTAMP TIMESTAMP
バイナリ型 Bytea BLOB
LOB BFILE/SecureFiles
その他 OID ROWID

2.2. プログラム
   最も大きな課題になったのはPostgreSQLとOracle Databaseの文法の違いでした。 SQL等のソースは機械的な一斉置換は難しく、人手で見直しています。例えば、PostgreSQLのLIMIT、OFFSET句はOracle Databaseにはありませんので書き換えが必要になります。

LIMIT,OFFSETのあるSELECT文の書き換え
/* PostgreSQL LIMIT,OFFSET */
SELECT 商品名
FROM 商品マスタ
ORDER BY 商品番号
LIMIT 2 OFFSET 5;

/* Oracle Databaseへ書き換え */
SELECT 商品名
FROM (SELECT 商品名,
ROWNUM line_no
FROM (SELECT商品名
FROM 商品マスタ
   OREDR BY 商品番号
   )
)
WHERE line_no BETWEEN 6 AND 7;

 組み込み関数が使われている場合も、対応する関数へ変換しなくてはなりません。関数名を変換するだけでなく、引数を変更しなくてはいけないものや返り値のデータ 型が違う場合もあり、注意が必要です。

 見落としがちなのがエラーハンドリング処理です。エラーメッセージ、コード体系が全く異なりますので、Oracle Database用に書き換えた上でテストする必要があります。Oracle Databaseの場合、WHERE句の左辺と右辺のデータ型が異なるとインデックスが使われないなど、オプティマイザの動作が変わることがあります。WHERE句に関数が使われている場合は注意が必要です。

3. 移行計画
 システム移行関連の工数は、プロジェクト全工数の30%~40%を占めるという調査結果があります。また、80%以上が移行作業でトラブルを経験しています。

【ITpro】記事:移行は全工数の4割を費やす

特にデータ移行は次の理由からクリティカルなミッションと言えるでしょう。
・データ損失・不整合が発生すると企業に重大な損害を与える危険性がある
・作業時間が制限されているためやり直しが難しく、原則一発勝負

移行するにあたっては、入念に移行計画を策定してリハーサルを繰り返す必要があります。

3.1. 移行方式の検討
 弊社が関わったデータベースを移行では、殆どの場合、なんらかのアプリケーション改修・データベース設計変更が発生しています。今回の事例でも、全店舗展開するに あたり、アプリケーションの機能追加と対応するデータベースの設計変更を行っています。従ってデータ移行の際には加工・変換するステップが必要になりました。

 さて、データ移行方式には、次のような方法が考えられます。
(1)サブシステムに分けて段階的に移行する方式
(2)新旧システムのデータを同期させる機構を作り込み、一定期間新旧システムを並行稼働させる方式
(3)ある時点で一斉に切り替える方式
(4)更新がないデータを予め移行しておき、移行当日差分だけ移行する方式

 各方式にはそれぞれ長所・短所があります。システムの特性を考慮し、最善の方式を選んでください。どの方式を選んだとしても、移行に失敗した場合にどの時点で切戻 すかを決めておくことは重要な検討事項です。

各移行方式の長所・短所
方式 長所 短所
(1) 最もリスクが少ない。 サブシステムごとにデータ・アプリケーションが独立していないと実現できない。
(2) 移行に失敗しても旧システムへ戻しやすい。 新旧システムのデータを同期させる仕組みを作り込む必要がある。
(3) 作業内容が4つの方式の中で最もシンプルになる。 移行作業当日の作業に負荷が高くなる。特に大規模DBではリスクが高い。
(4) 移行作業当日の時間が(3)より短くて済む。 移行当日、データの差分を取る仕組みが必要になる。

 今回の事例では、移行元のデータサイズが数十GBで比較的小さいこと、一店舗で試行している限り、夜間はサービスを停止できるという理由で、(3)一斉に移行する方式を 選択しました。

 移行当日は、サービスタイムが終了したら、データベースをユーザーからアクセス禁止にしてデータをcsv形式でアンロードし、SQL*LoaderでOracle Databaseへロードしました。加工が必要なデータは一度Oracle Databaseの作業テーブルへロードし、加工した後、新しいテーブルへINSERTすることで対応しています。 通常は、移行失敗のことを考え、旧システムへ切り戻すポイントを考えますが、事例では、全店舗については戻るべき旧システムがありませんので、リリース日程を再ス ケジュールすることで対応することとしました。

3.2. リハーサル
 移行のリハーサルは何度も行って、移行作業当日トラブルが発生しないように熟練しておくとよいでしょう。ポイントは前工程と後工程の順番をきちんと結びつけ、並行 作業できる作業の割り出しと作業分担です。一人に並行して作業させるのはトラブルの元になりますので、避けましょう。また、各作業単位で時間を計測しておいて、スケジュールの精度を上げておきます。

 リハーサルのためにリハーサル環境や本番と同等の件数をもったデータを準備することも計画時に盛り込んでおかなくてはなりません。データは件数を同じにするだけでなく、内容もできるだけ同じにしておきます。文字化けなどのエラーが発生するかも知れないからです。なお、本物のデータを扱うときは、データが流出しないように取り扱いは十分に注意しなくてはなりません。移行に限らず、テストの機会は、多数の人間が介在することが多くなりますので、データが流出するリスクが高くなります。

3.3. テスト計画
 テスト計画は、特に入念に検討します。移行する際にアプリケーションの動作テストは勿論のこと、ユーザー数も増えますので、レスポンスタイムと高負荷時のスループットといった性能試験は特に重視しました。

 DBMS製品が変われば、当然オプティマイザも変わり、同じSQLでも実行計画が変わる可能性があります。従って、パフォーマンスも全然違ったものになる可能性があります。PostgreSQLとOracle Databaseでは共に行ベルロックとMVCCを実装し、デフォルトのトランザクション分離レベルはRead Committedです。しかし、実装方式が異なるため、高負荷時の動作に違いが出る可能性があります。従って、高負荷テストでは、デッドロック、ロックウエイトタイムアウトの確認も行いました。

 運用系のテストも必要になります。DBMS製品が別製品になるということはそれまで使っていた運用スクリプト、ツール類も原則総入れ替えになります。障害テストも含めて運用系のテストも十分に実施しましょう。今回の事例では運用の要件が変わりましたので、バックアップ方式や死活監視方式など、ツールの導入や運用スクリプトが大きく変更になり、運用テストの工程も設けています。

4. まとめ
 PostgreSQLからOracle Databaseへの事例を挙げながら、データ移行の注意点を説明してきました。
移行するきっかけは、要件・環境が大きく変化し、より高いスケーラビリティと可用性が求められたためです。

 移行方式は、4種類挙げましたが、システムの特性や各方式の長所・短所を考えて最適な方式を選びましょう。
データ型変換は比較的容易ですが、キャラクターセットや改行コードの変換も忘れないようにしましょう。
アプリケーションは、移行が最も難しい部分です。基本的には人手で修正していくことになります。DBMS間のポータビリティを持たせたい場合は、DBMS製品の固有機能は 使わないでSQL規格に沿った文法を厳守すると移行が楽になります。あるいは、DBサーバーにストアドプログラムを作り込まないのも一手です。

 テストは、単に動作確認するだけでは十分ではありません。DBMS製品が変われば、オプティマイザやロック制御機構も変わります。従って、高負荷テストも移行前に実施してください。
 そしてリハーサルを十分に行うことが移行成功への鍵になります。

*   *   *
 株式会社アクアシステムズ様では、データベース移行ツール「SQL Ways」を活用して、Oracleデータベースへの移行を短期間、低コストで実施するサービスを提供しています。

 【アクアシステムズ】データベース移行支援サービス  
aqua_asm3

日曜日 1 01, 2012

【技術資料】データベース導入における所要時間と容易性の比較調査 - Oracle Database Appliance VS Microsoft SQL Server -

資料の概要

  • 日付:2012/01/01
  • 種別:技術資料

この調査の目的は、Oracle Database Appliance と Microsoft SQL Server の比較テストを実施することで、これら2つのソリューションの生産性における違いを特定することでした。DBMS所有コストの大半は、日々の管理作業を実行するための時間と費用にかかっています。この調査は、このような問題に対するオラクルの回答として、最近エンジニアド・システム・ファミリーに追加された Oracle Database Appliance に焦点を合わせて実施されました。

  • エグゼクティブ・サマリー
  • 調査の背景
  • テストの方法
  • 比較テスト
    / インストールおよび初期導入、保守、サポート
  • 結論

資料のダウンロード

こちらより、資料をご覧いただけます
http://www.oracle.com/jp/products/database/database-appliance/database-appliance-vs-sql-server-1434947-ja.pdf

月曜日 11 28, 2011

【技術資料】Oracle SQL Developerの移行機能を使用したOracle Databaseへの移行

[Read More]

金曜日 4 30, 2010

【技術資料】Oracle SQL Developerの移行機能

[Read More]

火曜日 6 30, 2009

【比較資料】管理コスト比較調査:Oracle Database 11g 対 Microsoft SQL Server 2008

[Read More]

土曜日 2 28, 2009

【マニュアル】Microsoft Accessからの移行のための追加情報

[Read More]

【マニュアル】Microsoft SQL ServerおよびSybase Adaptive Serverからの移行のための追加情報

[Read More]

【マニュアル】MySQLからの移行のための追加情報

[Read More]
About

Oracleエンジニアの方がスキルアップしていただくために、厳選した情報をお届けしています

Search

Archives
« 3月 2015
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
    
       
Today
Bookmarks
関連サイト
ランキング:カテゴリ
ランキング:技術資料
ランキング:技術コラム