PostgreSQL適用するための検討ポイントについて～異種DBMSからの移行を考える～
2012年度活動成果報告
PostgreSQLエンタープライズ・コンソーシアム
WG2(設計運用WG)
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

Agenda WG2（設計運用WG）の活動概要
 成果紹介 PostgreSQL移行成否を分けるポイントとは？
 WG2の活動を振り返って

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

2

WG2（設計運用WG）
活動の概要

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

3

WG2（設計運用WG）の概要
 活動方針 PostgreSQL利用促進を目的とし、PostgreSQL経験の少ないDB技術者に向けた情報発信を行う。
 他DBMSと比べた際のPostgreSQLの優位点や注意事項を明確化する。
 実システムを更改する場合の検討項目・手順を作成する。
（例）
 SQL文やストアドプロシージャなどのアプリケーション側の注意点
 データ定義変更の有無を判定する基準や方法
 PostgreSQL活用時にかかるコスト要因の分析

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

4

WG2 活動計画策定の経緯
 エンタープライズ領域へのPostgreSQLの普及を推進するために
 PostgreSQLを普及していく上で課題となるポイントを

PGECons設立準備期間に活動テーマ候補としてリストアップ
 リストアップされた課題の中から、設計運用分野の課題かつ要望および重要度を考慮して、活動テーマを選定

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

5

（参考） 活動テーマ候補抜粋
大項目
保守性
運用性
セキュリティ

移行性

小項目

概要

保守サポート

保守サポート事例紹介

トレーサビリティ

障害解析情報の取得方法の整備

監視運用

目的別の監視手法の整備

バックアップ運用 目的別のバックアップ手法の整備
目的別の監査への対応方法（アクセスログの取得など）
監査の整備
データベース
データ・スキーマの連携・移行手順の整備 ※アプリケーション
プログラム

移行コスト

SQLなどの互換性検証 ※ストアドプロシージャに対する移行ノウハウの整備 ※
移行コストの見積の考え方の整備 ※他ソフトウェアとの接続性検証

接続性他ソフトウェアとの連携他ソフトウェアとの連携手法の整備組合せ（スタック）モデルの整備※ 本年度着手のテーマ

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

6

エンタープライズ領域で使われている異種DBMSシステムへの対応を図る（参考）PGECons発足セミナー(2012年7月6日)アンケートより
Q: 現在お客様はどんなリレーショナルデータベースをお使いですか？（複数回答可)

45403530
2520
15
1050

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

7

WG2の2012年度活動テーマ
 「異種DBMSからPostgreSQLへの移行」 と設定
 課題認識 異種DBMSシステムをPostgreSQLへ移行するプロセスが確立していないことが、普及を妨げる大きな障壁と認識
 移行作業をどのように進めればよいかがわからない。
 初期段階で移行に必要なトータルコストを算出できない。
 過去の経験則や点在するノウハウに依存しているのが現状 活動目標 異種DBMSからPostgreSQLへの移行を検討する際に留意すべき事項や、難易度判断、調査方法といったガイドラインを本WGから提唱する。

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

8

2012年度の活動スケジュール
中間発表（12月）まで
 全体計画策定 調査項目洗い出し、決定

年度末（3月）まで
 各項目の調査の実施
 移行トライアルの実施

項目

8月

9月

10月

11月

12月

1月

2月

3月

4月～

計画策定
調査項目決定

中間発表

成果発表

調査
成果まとめトライアル

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

9

実施体制
 参加企業 （企業名順）
 日本電気株式会社
 NECソフト株式会社

 日本電信電話株式会社
 NTTソフトウェア株式会社
 SRA OSS, Inc. 日本支社

 TIS株式会社
 株式会社アシスト
 クオリカ株式会社

 サイオステクノロジー株式会社
 株式会社日立製作所
 株式会社日立ソリューションズ
 株式会社富士通ソーシアルサイエンスラボラトリ
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

10検討会の様子 隔週でWG2参加各社による検討会を開催

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

11今年度の成果物
 「2012年度WG2活動成果報告書」として、PGEConsサイトに公開しました。
 移行作業の調査ドキュメントとともに、検証時に実際に移行を行ったアプリケーションのソースコードも公開しています。

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

12作成文書と担当会社
作成文書

担当会社

DB移行フレームワーク編

NECソフト㈱、日本電信電話㈱システム構成調査編

日本電気㈱異種DB間連携調査編

サイオステクノロジー㈱スキーマ移行調査編

TIS㈱SQL移行調査編SRA OSS, Inc. 日本支社

ストアドプロシージャ移行調査編

クオリカ㈱組み込み関数移行調査編

TIS㈱データ移行調査および実践編㈱富士通ソーシアルサイエンスラボラトリ、㈱アシスト

アプリケーション移行調査編

TIS㈱アプリケーション移行実践編

NTTソフトウェア㈱運用設計（今期実施せず）

試験項目（今期実施せず）

チューニング（今期実施せず）

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

13

成果紹介

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

14

作業文書の構成
 移行作業の全体像を解説
 DB移行フレームワーク編

 移行作業に含まれる作業内容、手順の調査
 システム構成調査編
 異種DB間連携調査編
 スキーマ移行調査編

 SQL移行調査編
 ストアドプロシージャ移行調査編 組み込み関数移行調査編

 アプリケーション移行調査編

 移行作業を試行する検証
 データ移行調査および実践編

 アプリケーション移行実践編
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

15

作業文書の構成
 移行作業の全体像を解説
 DB移行フレームワーク編

 移行作業に含まれる作業内容、手順の調査
 システム構成調査編
 異種DB間連携調査編
 スキーマ移行調査編

 SQL移行調査編
 ストアドプロシージャ移行調査編
 組み込み関数移行調査編

 アプリケーション移行調査編

 移行作業を試行する検証
 データ移行調査および実践編

 アプリケーション移行実践編
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

16

DB移行フレームワーク編 （1/2）
 PostgreSQLに移行するにはどんな作業が必要か？
 「移行プロセスに対する認識を共有する」 のが目的
 DB移行作業の主な流れ （一部抜粋）
PostgreSQL

アセスメント

異種DBMS

移行判定

システム構成移行中断

異種DB連携検討

定義移行
データ移行

アプリケーション移行

運用移行

移行評価

チューニング

システム切り替え

データ移行
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

17

DB移行フレームワーク編 （2/2）
 アセスメントの作業内容について検討
 簡易アセスメントリスト （一部抜粋）
確認事項

確認内容

判定

可用性要件

障害による一時的なサービス停止や操作の再実行が許容できる。
•障害発生時にノード切り替えによる分単位のサービス停止が許容できる•障害による影響範囲を制限するシステムの閉塞が可能○／×

スキーマ移行 移行元DBMSやオプション製品による固有な属性を使用しない。
上の制約•固有な属性（ROWIDやBFILEなど）を使用しない•オプション製品が追加する非標準属性を使用しない○／×

パーティション パーティションの利用を前提とした大容量データ処理および運用を行わない。
•100以上に分割するパーティションは存在しない•複雑なパーティション分割を行わない•構成変更によるリバランス等は必要ない○／×

移行作業自体が難しいプロシージャや存在しない○／×
ストアドプロシージャの移 •PACKAGE定義やグローバル変数を使用しない
行困難性•移行元DBMSに固有なユーティリティパッケージを使用していない•ソースの更新権限を持たないプロシージャや難読化したプロシージャは存在しない
組み込み関数 PostgreSQL, Orafceの何れも対応していない関数を利用していない。

○／×・・・
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

18

作業文書の構成
 移行作業の全体像を解説
 DB移行フレームワーク編

 移行作業に含まれる作業内容、手順の調査
 システム構成調査編
 異種DB間連携調査編
 スキーマ移行調査編

 SQL移行調査編
 ストアドプロシージャ移行調査編
 組み込み関数移行調査編

 アプリケーション移行調査編

 移行作業を試行する検証
 データ移行調査および実践編

 アプリケーション移行実践編
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

19

システム構成調査編 （1/2）
DBMSの主なシステム構成とその特徴について調査し、PostgreSQLに移行時の構成検討の参考となる資料を作成
 一般的なシステム構成の特性を紹介
 シングルサーバ
 HAクラスタ
 データベースレプリケーション

今は”XXXX”DBMSでActive-Standby構成
だけど、PostgreSQLで同じ構成でよいのか？

可用性？

 マルチマスタ負荷分散クラスタ
性能？

コスト？

 主に検討のポイントは以下

 可用性
 性能

（参照・更新） 拡張性
 設計・運用面
 初期導入コスト
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

20

システム構成調査編 （2/2）
 HAクラスタ構成の比較内容 （一部抜粋）
共有ディスク

可用性 サービス継続性 取れる

性能

ディザスタ
リカバリ
参照系
更新系

拡張性
運用・設計面

初期導入コスト

ディスクミラーリング

ストリーミングレプリケーション

取れる

取れる

ストレージレイヤーでレプリケーションをすれば可能

取れる

取れる

オーバヘッドはなし

オーバヘッドはなし

スケールアウトが可能

オーバヘッドはなし
オーバヘッドありオーバヘッドあり
HA構成の中では一元化されてい 同期・非同期の設定もあるが、 同期・非同期の設定で性能とトランるメリットが出る
ストレージレベルの非同期では ザクション反映の信頼性のトレード
DBの論理破壊の可能性がある オフになる
スケールアップで対応
スケールアップで対応
カスケードレプリケーションによってデータ容量追加は行いやすい
参照系のスケールアウトが可能
障害時の切替は比較的早い可能性
ストレージ全体を一括管理できる
メリットあり特徴的な検討項目
特徴的な検討項目
特徴的な検討項目
・クラスタ設計・クラスタ設計・クラスタ設計
・ストレージ層の同期設計・レプリケーションの同期や・ストレージの設計・フェイルバック時のデータ同期 PostgreSQLの切替動作の設計
設計
・フェイルバック時のデータ同期設計
共有ディスクが必要となり比較的 汎用のサーバのみで構成を組 汎用のサーバのみで構成を組み事
高価み事が可能が可能

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

21

異種DB間連携調査編 （1/2）
 異種DBMSとPostgreSQLをどう連携させるか？
 異種DBMSとPostgreSQLを連携させる目的
 データベースの段階移行時における並行稼動
 マスターDBの負荷分散
 災害対策 DWH 構築 異種DBMS間レプリケーションを実現するソフトウェアを調査
 InfoFrame DataCoordinator（NEC） DBMoto（クライム）
 DataSpider Servista （アプレッソ）
 xDB Replication Server （EnterpriseDB）

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

22

異種DB間連携調査編 （2/2）
 異種DBMS間連携トライアル
 xDB Replication を使用した異種DBMS間連携を実施し、連携時の制限事項や注意点を調査

OraclexDB Replication Consoleによるデータ連携

PostgreSQL

 実施結果 異種DBMSとPostgreSQLのデータ連携を容易に実現
 柔軟なレプリケーション設定が可能であることを確認Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

23

スキーマ移行調査編(1/2)
 異種DBMSとPostgreSQLのスキーマの違いは？
 Oracle, PostgreSQLのDDL互換性を調査
 各種DDLの相違点をもとにした移行方針を解説
 組み込みデータ型対応表 （一部抜粋）

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

24

スキーマ移行調査編(2/2)
 Ora2Pgを使った移行で手作業が必要な部分を解説
CREATE TABLE DATA_TYPE_TEST1 (ID
VARCHAR2(5) NOT NULL,
CHAR_VARCHAR2_BYTE VARCHAR2(20),
CHAR_VARCHAR2_CHAR VARCHAR2(20 CHAR),
CHAR_NVARCHAR2
NVARCHAR2(20),
CHAR_CHAR_BYTE
CHAR(10),
CHAR_CHAR_CHAR
CHAR(10 CHAR),
CHAR_NCHAR
NCHAR(10),CHAR_LONG
LONG,
CHAR_CLOB
CLOB,
CHAR_NCLOBNCLOB,
NUM_NUMBER1
NUMBER(5),NUM_NUMBER2
NUMBER(10),NUM_NUMBER3
NUMBER(11),NUM_NUMBER4
NUMBER(10,2),
NUM_NUMBER5NUMBER(15,5),
DATE_DATE
DATE,
DATE_TIMESTAMPTIMESTAMP(6),DATE_TIMESTAMP_TIMEZONE TIMESTAMP(6) WITH TIME ZONE,DATE_TIMESTAMP_LOCALTIMESTAMP(6) WITH LOCAL TIME ZONE)

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

25

スキーマ移行調査編(2/2)
 Ora2Pgを使った移行で手作業が必要な部分を解説
CREATE TABLE DATA_TYPE_TEST1 (ID
VARCHAR2(5) NOT NULL,CREATE TABLE "data_type_test1" (CHAR_VARCHAR2_BYTE VARCHAR2(20),"id"varchar(5) NOT NULL,
CHAR_VARCHAR2_CHAR VARCHAR2(20 CHAR),“char_varchar2_byte”
varchar(20),
CHAR_NVARCHAR2
NVARCHAR2(20),“char_varchar2_char”
varchar(20),
CHAR_CHAR_BYTE
CHAR(10),“char_nvarchar2”
varchar(20),
CHAR_CHAR_CHAR
CHAR(10 CHAR),“char_char_byte”
char(10),
CHAR_NCHAR
NCHAR(10),“char_char_char”
char(10),
CHAR_LONG
LONG,“char_nchar”
char, → 手作業で char(10) に書き換える
CHAR_CLOB
CLOB,“char_long”
text,
CHAR_NCLOBNCLOB,“char_clob”
text,
NUM_NUMBER1
NUMBER(5),“char_nclob”
text,
NUM_NUMBER2
NUMBER(10),“num_number1”
numeric(5), → 手作業で int に書き換える
NUM_NUMBER3
NUMBER(11),"num_number2"
numeric(10), → 手作業で bigint に書き換える
NUM_NUMBER4
NUMBER(10,2),"num_number3"
numeric(11), → 手作業で bigint に書き換える
NUM_NUMBER5NUMBER(15,5),"num_number4"
decimal(10,2),
DATE_DATE
DATE,"num_number5"
decimal(15,5),
DATE_TIMESTAMPTIMESTAMP(6),"date_date"timestamp,
DATE_TIMESTAMP_TIMEZONE TIMESTAMP(6) WITH TIME ZONE,"date_timestamp"
timestamp, → 手作業で timestamp(6) に書き換える
DATE_TIMESTAMP_LOCALTIMESTAMP(6) WITH LOCAL TIME ZONE
"date_timestamp_timezone" timestamp, → 手作業で timestamp(6) with time zone に書き換える)"date_timestamp_local"
timestamp → 手作業で timestamp(6) に書き換える);
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

26

SQL移行調査編 (1/2)
 異種DBMSのSQLはPostgreSQLでも動くのか？
 Oracle, SQL Server, PostgreSQLのSQL互換性を調査
 互換性がないSQLの書き換え方針を調査
 SQL差異表 （一部抜粋）

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

27

SQL移行調査編 (2/2)
 代表的な書き換え例
 SELECT結果の行数を制限するSQLはDBMS毎に異なる。
OracleSQL ServerSELECT * FROMSELECT TOP 10 *(SELECT * FROM tbl
FROM tbl
ORDER BY id)
ORDER BY id
WHERE ROWNUM <= 10PostgreSQLSELECT * FROM tbl
ORDER BY id
LIMIT 10 OFFSET 0※PostgreSQL(8.4以降)は標準SQLの構文に対応
SELECT * FROM tbl OFFSET 0 ROW FETCH FIRST 10 ROWS ONLY MERGE PostgreSQLでは未実装。WITH句を使った書き換え方法を紹介。

 CONNECT BY
 Oracle独自の階層問い合わせ 再帰SQL（標準SQL準拠）を使った書き換え方法を紹介
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

28

ストアドプロシージャ移行調査編
 異種DBMSのストアドプロシージャをどのようにPostgreSQLに移行すればよいか？
 PL/SQLのストアドプロシージャをPostgreSQLへ移行する際に注意すべき点について調査
 手続き言語の文法的な違いを明確にすることを目的とした。
 調査結果 SQLや手続き言語の差は機械的に変換可能と思われる。
 DBMSのアーキテクチャにかかわる部分（トランザクション制御など）が存在すると移行の難易度が高くなる。
 無理にプロシージャに移行せず、アプリケーションとして書き換えた方が良いパターンもある。
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

29

組み込み関数移行調査編 (1/2)
 異種DBMSの関数はPostgreSQLでも動くのか？
 Oracle, PostgreSQLの組み込み関数互換性を調査
 組み込み関数対応表 （一部抜粋）

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

30

組み込み関数移行調査編 (2/2)
 代表的な書き換え例
 ADD_MONTHS ： 月を演算する関数
SQL> SELECT ADD_MONTHS(‘2013/3/22’,1) FROM DUAL;
ADD_MONT-------13-04-22

 PostgreSQL に ADD_MONTHS 関数は存在しない。
 算術演算子を使った書き換え
postgres=# SELECT date ‘ 2013-03-22’ + interval ‘1 months’;?column?
--------------------2013-04-22 00:00:00(1 行)

 Oracle互換関数ライブラリ（Orafce）を利用する方法もCopyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

31

作業文書の構成
 移行作業の全体像を解説
 DB移行フレームワーク編

 移行作業に含まれる作業内容、手順の調査
 システム構成調査編
 異種DB間連携調査編
 スキーマ移行調査編

 SQL移行調査編
 ストアドプロシージャ移行調査編
 組み込み関数移行調査編

 アプリケーション移行調査編

 移行作業を試行する検証
 データ移行調査および実践編

 アプリケーション移行実践編
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

32データ移行調査および実践編 （1/3）
 異種DBMSのデータをPostgreSQLに持ってくるにはどうすればいい？
 異種DBMSからPostgreSQLへデータ移行を行う場合に発生する作業や注意点について調査
 実際にデータ移行を試行し、調査結果の妥当性を検証
Extract

CSVファイルなど文字コード、外字はどうする？

異種DBMSTransform
使用するツール、コマンドは？

PostgreSQL
投入可能形式

Load

どのくらい時間がかかる？
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

PostgreSQL

33

データ移行調査および実践編 （2/3）
 移行調査編
 Oracle, SQLServerからPostgreSQLへのデータ移行
 データ移行作業の手順と注意点を解説
 データの抽出(Extract)
 CSVへ出力する際の表現形式
 中間データへ出力するツール（SPOOL, Ora2Pg, bcpユーティリティ） データの変換(Transform) 中間データの文字エンコーディングの変換

 データの投入(Load) データをロードするツール （COPY, psql, pg_bulkload）

 データ移行後の作業
 データロード後に確認すべき点 （エラー有無、投入行数）

 VACUUM, ANALYZE の実施
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

34データ移行調査および実践編 （3/3）
 移行実践編
 OracleからPostgreSQLへのデータ移行を実践 移行元DBはJdbcRunner同梱の「TinyTPC-C」で作成
Extract, Transform

OracleOra2Pg

データ投入
DML

SPOOL

CSVLoadpsql
COPY

PostgreSQL

pg_bulkload 実施結果 各種ツールで正常に移行でき、ツールの利便性を確認

 用途によっては使いづらいケースもあった。
 ツール利用時は操作方法及びフィジビリティの確認が重要
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

35

アプリケーション移行実践編 （1/5）
 実際に異種DBMSからPostgreSQLへアプリケーション移行を行ったら、どういう問題が発生するか？
 異種DBMSで稼動するアプリケーションをPostgreSQL(9.2.2)上に移行して評価を行った。
 移行対象アプリケーション
 Commander4J バーコードラベルを作成するJavaのOSSアプリケーション
 対応DB：Oracle, SQLServer, MySQL ステップ数：71Ks
 テーブル数：39
 SQL数：3390
 ストアドプロシージャ：なし

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

36

アプリケーション移行実践編 （2/5）
 SQL変更箇所の抽出に db_syntax_diff を使用

 db_syntax_diff
 Oracle DatabaseからPostgreSQLへアプリケーションを移行する際に修正が必要となる箇所を報告するツール
 NTT OSSセンタで開発されたOSS ライセンスは The PostgreSQL License https://github.com/db-syntax-diff より取得可能 アプリケーションのソースコードを指定して実行すると、修正が必要なSQLのパターンとマッチングして報告。
 修正が必要なSQLのパターンはXML形式で定義するため、必要に応じてチェックパターンのカスタマイズが可能
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

37アプリケーション移行実践編 （3/5）
 db_syntax_diff の出力例 （一部抜粋）

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

38

アプリケーション移行実践編 （4/5）
 移行実施の手順
 db_syntax_diffをJavaソースコードと環境構築用のSQLファイル（スキーマ定義DDL、データ投入DML）に対して実行 OracleのJDBCドライバクラスを呼び出す部分を修正
 db_syntax_diffの実行結果をもとに、SQL文を修正
 修正後アプリケーションの動作確認
 Commander4j の基本機能が正常動作するか？

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

39

アプリケーション移行実践編 （5/5）
 移行実施結果
テスト工程が全工程の90%以上を占めた
 ツールでSQL修正箇所を自動検出し、修正作業が短く済んだ。
 修正有無に関わらず、関連するSQLはすべてテストを実施した。

 db_syntax_diff で検出できなかった箇所はテスト工程で対応した。
項番

作業項目所要時間比率#1

AP修正（PostgreSQLへの接続）

2.8%

#2

AP修正（db_syntax_diffに基づく修正）

5.8%

#3

テスト・およびエラー修正

91.4%

#1
#2
#3

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

40

PostgreSQL移行の成否を分けるポイントとは？

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

41

PostgreSQL移行の成否とは？
 そもそもどういう形で終われば移行に成功した、と言えるのでしょう？
 莫大な費用をかけて移行できても、それは成功と言えるのでしょうか？
 移行の成功とは、

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

42

PostgreSQL移行の成否とは？
 そもそもどういう形で終われば移行に成功した、と言えるのでしょう？
 莫大な費用をかけて移行できても、それは成功と言えるのでしょうか？
 移行の成功とは、当初見積りと実作業量の差が小さい

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

43

PostgreSQL移行の成否を分けるポイント
 アセスメントの精度を高める
 当初見積りを正確にする
 移行元、移行先システムの要件を正しく把握する 移行元DBMSとPostgreSQLの機能差異を理解しておく 移行ツールをうまく活用する 動作検証、テストの時間を十分に確保する
 結局実作業量は増えることを見越しておく アプリケーション移行実践編では、テスト工程が全体の9割以上という結果に
 移行ツールの利用で修正の実作業量は縮小
 移行ツールで吸収できないケースへの対応は必ず発生
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

44

参加各社からの声「WG2の活動を振り返って」

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

45

WG2の活動で苦労したこと
作業時間の捻出 ミーティング、調査時間を確保するのが大変だった。
（NECソフト、クオリカ）
 WG1とWG2を兼務しており作業も多く大変だった。
社内リソースも含め作業分担をしっかりすると、より参加しやすくなると思う。(NEC) 通常業務をこなしながら、2週に1度の検討会に向けた活動を実施していくのは大変だった。
（NTT SOFT）
1.

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

46

WG2の活動で得られたこと
1.

技術者交流の機会
 PostgreSQLをはじめとするDBMSに造詣の深い、他社の技術者と議論する場が得られた。
（NECソフト、SRA OSS、富士通SSL、サイオス、NTT SOFT）
2.

実用性の高い技術情報 これまで知らなかったツールの知識やノウハウを得た。

（NECソフト、NTT SOFT）
 db_syntax_diff 等のツールについて知ることが出来、実際のシステム移行案件にも役立てることができた。（クオリカ）
 他社が持つ成果物を参照する機会があり、参考になった。
（NTT SOFT）
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

47

WG2の活動で得られたこと
3.

PostgreSQLに対する理解度の向上
 成果物としてまとめることで、PostgreSQLに対する理解が深まった。(NEC) 自身の理解が不足している点を、他社のDB技術者と交流することで気づくことができた。(NEC) 参加企業で作業を分担することで、1社では調査できない範囲のノウハウを得られた。(アシスト)
4.

ドキュメンテーション技術の向上
 成果物作成を通じ技術文書のまとめ方が参考になった。

(アシスト)
 書籍を出されている方も少なくなかった為、ドキュメンテーションのテクニックや、レビューのコメントなどが大変勉強になった。(サイオス)
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

48

PGEConsで一緒に活動しませんか？
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

49

Javaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。
Microsoft、Windows Server、SQL Server、米国 Microsoft Corporationの米国及びその他の国における登録商標または商標です。
MySQLは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。
Oracleは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。
PostgreSQLは、PostgreSQL Community Association of Canadaのカナダにおける登録商標およびその他の国における商標です。
TPC, TPC Benchmark,TPC-C, TPC-E, tpmC, TPC-H, QphHは米国Transaction Processing
Performance Councilの商標ですその他、本資料に記載されている社名及び商品名はそれぞれ各社が商標または登録商標として使用している場合があります 。
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

50