弊社で開発しているERPパッケージのバックエンドのデータベースをOracleからPostgresに移行した際の方法を詳しくお話します。各種移行ツールの検証結果や、単純なオブジェクト移行だけでなく難度の高いストアドプロシージャの注意点なども。移行って具体的に何すればいいの？って方に、具体的な移行手順をこのセッションで理解してもらえればと思います。

1. 商用RDBをOSSへ
Oracle to Postgres
徹底解説 WorksApplications co., LTD.
Advanced Technology
& Engineering
市川 光

2. アジェンダ
・移行のメリット＆デメリット
・各種移行ツールの特長比較
・弊社で実施した移行手順
・ora2pg, orafce (問題点 & 対応法)
・移行難度の高いプロシージャの注意点
・アプリケーション移行の注意点
・PL/Java, SQLCoverter
・PPASについて(移行優位性)
・まとめ

3. 本題の前に少しだけ…

4. 弊社で取り扱ってるDBは以下の通り

5. OSSのRDB, NoSQLは注目されてます↓
Gartnerは、2018年までに新規に開発される
社内アプリケーションのうち70％以上に
オープンソースデータベースが使われるようになり、
既存の商用RDBMSインスタンスのうち50％は、
オープンソースに切り替えられるか、
切り替えのプロセスに入っていると予想している。

6. そもそも、WorksApplicationsって
脱RDB宣言して無かったっけ！？
現在進行中です。
全製品のDBを同時に移行できません。
そのため、一部のプロダクトや機能で
Oracle ⇒ Postgres に移行したので
本日は、その際のノウハウを共有致します。

7. 移行のメリット＆デメリット

8. OracleからPostgresへ移行
★メリット
・ライセンスコストが不要(BSDライセンス)
・OSSだが、長い歴史がるため実績が豊富
・扱い方が似ているため、知識が流用できる
★デメリット(商用DBに比べて)
・製品のサポートサービスが少ない
・BI等サードパーティー製品が少ない

9. データベースを構成する主なプロセス
PostgreSQL Oracle
プロセス名 役割 プロセス名 役割
マスタープロセス 各バックグラウンドプロセスの起動
各機能子プロセスの起動
リスナープロセス サーバープロセスの起動
バックエンドプロセス 接続毎に生成されたSQLを処理 サーバープロセス 接続毎に生成された
SQL要求を処理
Writerプロセス データベースキャッシュの情報を
データファイルに書き出す
DBWRnプロセス SharedPoolの情報を
ファイルに書き出す
Wal Writerプロセス WalバッファからWalファイルへ
書き出す
LGERnプロセス Redoバッファから
redoログファイルに書き出す
Archiverプロセス Walファイルをコピーし、
アーカイブを生成する
ARCnプロセス Redoログファイルから
アーカイブを生成する
Autovacuumプロセス Autovacuumを実行 SMONプロセス ロールバックセグメントの管理etc

10. 移行の懸念点について
色々あると思いますが、、
多くの方は以下が気になるかと思います！
・移行にかかるコスト(工数)は！？
・パフォーマンスは劣化しない！？

11. 実際に移行するとなると、、
担当者が気になるのは(ハードルの高さ)
・Oracleの機能がPostgresにあるか!?
⇒ Postgresは、バージョンアップ毎に
様々な機能が追加されていますし
今後も充実していくと考えています

12. 現在：Postgresの機能追加について
・全文検索(拡張機能:pg_bigm, pgroonga)
・hstore(NoSQL KVS)
・外部テーブル(Data Link 後に 9.3でFDW)
・MADlib(SQLでデータマイニング)
・View更新可 & マテビューも
※自動リフレッシュは9.4～
・その他、マルチCPUのスケーラビリティ(9.2～)

13. 未来：Postgresの機能追加について
・UPSERT機能(OracleでいうMarge文)
※Insert文にON Conflict句を指定できる
・9.5では見送られそうですが、Sequential Readの
並列化機能(OracleでいうParallel Query)
・9.6ではカラムストアも実装されるらしいです

14. 各種移行ツールの特長比較

15. すべてFreeで使えるツール
移行ツール
移行可能
オブジェクト
問題点
EXdump Editor Table, Index
Dataは、timestampを含む場合にERROR
移行できないものが多い
Migration Toolkit
(EDB製品)
Data, Table, View,
Sequence
移行時にError(MTK-13010)
トリガ、プロシージャ、関数、パッケージ、同義語、
データベースリンクは移行できません。
上記以外だと、索引も出来ない(制約はPKのみ)
Ora2pg 全て エラーは多いが、比較的修正工数は少ない
SQLWays
全て(制限あり)
※問題点参照
以下の制限事項がある(有料版は制限無)
オブジェクト 数 サイズ/コード行
---------------------------------
テーブル 100 2 GB
その他 1 100
---------------------------------

16. 弊社で実施した移行手順

17. 移行手順(概要、、とてもザックリ)
① Postgesの環境構築
② ora2pgでDatabase Object を出力
③ orafceでOracle関数を追加
④ OracleのデータをPostgresにロード
この後は、アプリの接続先をPostgresに
変更してSQLのエラーを対応

18. 移行対象製品のオブジェクトサマリー
一部のProcedure, function,
package は、DB2対応時の
Conversionをそのまま流用
そこそこ大規模な移行かと
思ってます。
オブジェクト種類 対象数
Table 約25,000
Index 約30,000
Consttaint(PK) 約25,000
Sequence 約1,000
view 約2,000
Trigger 約1,000
Procedure 約200
Function 約200
Package 約30

19. Ora2pg

20. Ora2pgとは、、
・OracleのオブジェクトをPostgresの
オブジェクトに変換できます
http://ora2pg.darold.net/
※DDLを出力せずに直接Postgresに
オブジェクトを作成することも出来ます
・このツールでデータ移行もできますが、
お勧めしません。(理由は後述)

21. Ora2pgを実行するためにやること
ora2pg_dist.conf (設定ファイルの雛形)に
必要な情報を設定する
・Oracle接続情報
・出力タイプ(table, insert, copy etc)
・出力先(ファイル名, ディレクトリ)
・エンコード指定(sjis, utf8 etc)
※Perlの実行環境が必要になります

22. その他に設定しておいた方が良いもの
- コメント出力抑制するしない
DISABLE_COMMENT
- プライマリキー名を移行するしない
KEEP_PKEY_NAMES
- NUMBER(X)を、Postgres対応の整数に変換
PG_INTEGER_TYPE
- NUMBER(9,6)を、doubleに変換(0はnumeric)
PG_NUMERIC_TYPE

23. 問題点＆対応策

24. 問題点①
テーブル定義は特に問題なく変換できますが、
ビューの変換率はイマイチ。
⇒ 外部結合(+) Oracle特有を変換できない
DECODEの変換もできない。
対応策
外部結合は、WHERE句を確認しOUTER JOINに
DECODEは、CASE文にすることで対応

25. 問題点②
OracleとPostgresで予約語が違う
⇒ 弊社ではカラム名(left, right)がNG。
他にもデータ型を合わせる必要もあります
対応策
Postgresの予約語を確認し、リネームして対応
※データ型の変換については後述します

26. 問題点③
OracleとPostgresで用意されている関数が違う
⇒ procedure, function, package でNG多発
対応策
orafceで関数追加し、無いものは同じ関数名で
実装したり、Postgresの関数で代用できる場合
には、その関数をWrapして対応しました。

27. 問題点④
データ移行ツールとしては使えない
⇒ Oracleからのデータ出力が遅い
他にも、改行コード等に問題がありました
対応策
出力ツールはJavaで実装し、速度改善。
改行問題等は、テキスト形式でCopy処理
することで対応しました。
https://www.postgresql.jp/document/9.4/html/
sql-copy.html

28. 問題点⑤
STEP数の多いのストアドプロシージャは
変換されず、出力されない
⇒ ora2pgの仕様で、変換対象のサイズに
制限があるようです
対応策
既存Oracleのストアドプロシージャを確認。
この場合、担当者がコーディングするが、
特に規約がなければ、pl/pgsqlでなくてもよい。

29. その他、よく問題になるエラーは、、
・OracleのROWIDの対応
・SQLのヒント句(pg_hint_plan 拡張機能)
http://pghintplan.osdn.jp/pg_hint_plan-ja.html
・USERENV(セッション情報取得)
pg_backend_pid()でユニークなセッションIDは取得可
・DBMS_OBFUSCATION(データ暗号化)
Pg_crypto で対応できるか検討
(Blowfish, md5, DES, ...)

30. 弊社でのカラム対応表
Category Oracle Type Postgres Type
String
CHAR CHAR
VARCHAR2 VARCHAR
NVARCHAR2 VARCHAR
LONG TEXT
CLOB TEXT
NCLOB TEXT
Number
NUMBER NUMERIC
NUMBER(1)-(4) SMALLINT
NUMBER(5)-(9) INTEGER
NUMBER(10)-(18) BIGINT
NUMBER(5,2) NUMERIC(5,2)
FLOAT NUMERIC
Date
DATE TIMESTAMP(0)
TIMESTAMP(6) TIMESTAMP(6)
Binary
RAW BYTEA
LONG RAW BYTEA
BLOB BYTEA
Other ROWID SERIAL
・Postgresは1GBまで。
それ以上はラージオブジェクト。
・Postgresのnumericは
1000桁(oracleは38桁)
・OracleのDATEは秒まで保持
PostgresのDATEは切捨て
・ROWID対応は
SERIAL+INDEX

31. Orafce

32. Orafceとは、、
・Oracle特有の関数、演算子を自動生成する
Postgresの追加モジュール
http://pgfoundry.org/projects/orafce/
DBMS_ALERT, UTL_FILE, NVL, DECODE
日付関数(add_months, next_day, trunc, round),
文字列関数(instr, substr etc)

33. 問題点
Postgresでは、引数のデータ型が暗黙的に
キャストされないため実行時にエラーが多発
対応策
必要に応じて異なる型を引数とした関数の追加や、
キャストの追加等の対応が必要。
※Create Castの詳細はManualを参照
https://www.postgresql.jp/document/9.4/html/
sql-createcast.html

34. 移行難易度の高い
プロシージャの注意点

35. プロシージャを修正する際に考えること
・Postgresは、functionのみ
・packageが無く、セッションで有効なgrobal変数NG
・private function もNG
・pl/sqlとpl/pgsqlだとそもそも構文が違う
・戻り値がrecord型のみ
・pl/sqlのようにinoutが使えない
・引数の型に%ROWTYPEが使えない
・レコード配列のような変数がない

36. アプリケーション移行の注意点

37. アプリケーション移行で考えること
・トランザクション動作(Postgresはauto commit)
⇒ 任意で行うには(begin or start transaction)
・Postgresでerrorが発生したら、明示的にrollbackする
⇒ 後続処理も全てerrorになる(savepointも有効)
・PostgresのDDLは暗黙commitされない
⇒ バッチ内でのワークテーブル作成時は注意
・delete – insert を複数実行時、動作が異なる
⇒ postgresだと、deleteでwaitし、commit後error ....

38. アプリケーション実行時の問題点
・関数, 演算子, キャストの追加
特に演算子、キャストの追加が多い、、
Postgresは、データ型のチェックが厳密
ex) 以下のような SQL は通りません。
select a(integer型) + b(text型) from hoge;

39. SQLチェックツール(db_syntax_diff)
・NTT OSSセンタ開発ツール
SQLファイルやjavaファイルに対して、SQLを
チェックして、警告をしてくれる。
弊社の場合、動的にQueryを作成することも多く
使用してません。(対処法を教えてくれる事はない)
https://github.com/db-syntax-diff より取得可能

40. PL/JAVA, SQLConverter

41. PL/Javaとは、、
・Postgresでは、SQLやC言語以外でUDFを
作成でき、Javaで実装したものです。
(Tcl, Perl, Python)
http://pgfoundry.org/projects/pljava
※あまり、メンテナンスされてない!?(gitは最新)
最近では、PostgresのJSON対応により
PL/v8 (JavaScript)でも記述できます

42. SQLConverterとは、、
・弊社で作ったツールです！
簡単に言うと、接続先DBに応じてSQLを修正し
発行するツールです。(Oracle, DB2, Postgres)
JDBC wrapper に組み込んで実行してます。
※いずれ、公開するかもしれません!?

43. SQLConverterの機能
・外部結合(+) ⇒ OUTER JOIN 変換
・SYSDATE 変換(current_date)
・DECODE 変換(orafce対応できないもの)
・ROWNUM 変換(offset limit)
・IS NULL / IS NOT NULL 変換(‘’=nullではない)
等々、変換機能を多数実装しています。

44. PPAS について

45. PPASの移行優位性(互換性)
・一般的なSQL互換率(P：Postgres, PP：PostgresPlus)
P：約10%(他社アプリケーションでは65%)、PP：90%
・PL/SQLプログラムの互換率
Package：70%、UDF：85%
※以下、他社実績(package, procedure, function)
・1400本中、修正必要なものは46本(互換性97%)
・1650本中、修正必要なものは110本(互換性93%)

46. PPASの移行優位性(その他)
・DRITA：
Oracleのstaspackに相当
・Optimizer Hint：
実行計画制御のヒント文
・SQL Profiler, Index Advisor：
OracleのTurning Pack

47. まとめ

48. 色々と問題がありますが、、、
Ora2pgがあれば、大抵のアプリケーションのDBを
OracleからPostgresに移行できると考えてます。
※弊社の場合、移行工数の８割は、テストになりそうです。
実施すること↓
・PL/SQL⇒pl/pgsql (得意言語でOK)
・Postgresのマニュアルで調査(9.0はPDFあり)
・アプリケーションのQueryを修正(SQLconverter)

49. 現在は、バッチ処理の性能検証や
アプリケーションの改修＆機能テストを実施
テストが無事終了した際には
何らかの手段でお伝えしたいと考えてます

50. ご清聴ありがとうございました。