商用RDBをOSSへ

Oracle to Postgres

徹底解説 WorksApplications co., LTD.

Advanced Technology

& Engineering

市川 光

アジェンダ

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

本題の前に少しだけ…

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

OSSのRDB, NoSQLは注目されてます↓ Gartnerは、2018年までに新規に開発される

社内アプリケーションのうち70％以上に

オープンソースデータベースが使われるようになり、

既存の商用RDBMSインスタンスのうち50％は、

オープンソースに切り替えられるか、 切り替えのプロセスに入っていると予想している。

そもそも、WorksApplicationsって 脱RDB宣言して無かったっけ！？

現在進行中です。 全製品のDBを同時に移行できません。 そのため、一部のプロダクトや機能で Oracle ⇒ Postgres に移行したので 本日は、その際のノウハウを共有致します。

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

OracleからPostgresへ移行

★メリット ・ライセンスコストが不要(BSDライセンス) ・OSSだが、長い歴史がるため実績が豊富 ・扱い方が似ているため、知識が流用できる

★デメリット(商用DBに比べて) ・製品のサポートサービスが少ない ・BI等サードパーティー製品が少ない

データベースを構成する主なプロセス

PostgreSQL Oracle

プロセス名 役割 プロセス名 役割

マスタープロセス 各バックグラウンドプロセスの起動 各機能子プロセスの起動

リスナープロセス サーバープロセスの起動

バックエンドプロセス 接続毎に生成されたSQLを処理 サーバープロセス 接続毎に生成された

SQL要求を処理

Writerプロセス データベースキャッシュの情報を データファイルに書き出す

DBWRnプロセス SharedPoolの情報を ファイルに書き出す

Wal Writerプロセス WalバッファからWalファイルへ 書き出す

LGERnプロセス Redoバッファから redoログファイルに書き出す

Archiverプロセス Walファイルをコピーし、 アーカイブを生成する

ARCnプロセス Redoログファイルから アーカイブを生成する

Autovacuumプロセス Autovacuumを実行 SMONプロセス ロールバックセグメントの管理etc

移行の懸念点について

色々あると思いますが、、 多くの方は以下が気になるかと思います！

・移行にかかるコスト(工数)は！？ ・パフォーマンスは劣化しない！？

実際に移行するとなると、、 担当者が気になるのは(ハードルの高さ)

・Oracleの機能がPostgresにあるか!?

⇒ Postgresは、バージョンアップ毎に 様々な機能が追加されていますし 今後も充実していくと考えています

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

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

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

すべて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 ---------------------------------

弊社で実施した移行手順

移行手順(概要、、とてもザックリ)

① Postgesの環境構築 ② ora2pgでDatabase Object を出力 ③ orafceでOracle関数を追加 ④ OracleのデータをPostgresにロード この後は、アプリの接続先をPostgresに 変更してSQLのエラーを対応

移行対象製品のオブジェクトサマリー

一部の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

Ora2pg

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

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

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

問題点＆対応策

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

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

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

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

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

その他、よく問題になるエラーは、、

・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, ...)

弊社でのカラム対応表 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

Orafce

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

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

移行難易度の高い

プロシージャの注意点

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

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

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

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

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

PL/JAVA, SQLConverter

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

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

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

PPAS について

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%)

PPASの移行優位性(その他)

・DRITA： Oracleのstaspackに相当 ・Optimizer Hint： 実行計画制御のヒント文 ・SQL Profiler, Index Advisor： OracleのTurning Pack

まとめ

色々と問題がありますが、、、

Ora2pgがあれば、大抵のアプリケーションのDBを OracleからPostgresに移行できると考えてます。 ※弊社の場合、移行工数の８割は、テストになりそうです。

実施すること↓ ・PL/SQL⇒pl/pgsql (得意言語でOK) ・Postgresのマニュアルで調査(9.0はPDFあり) ・アプリケーションのQueryを修正(SQLconverter)

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

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