PostgreSQL Conference Japan 2021

【B4】OracleからPostgreSQLへのDB移行の実際
2021年11月12日
株式会社NTTデータ© 2021 NTT DATA Corporation薄 浩之
1© 2021 NTT DATA Corporation自己紹介薄 浩之（うすき ひろゆき）• 株式会社NTTデータ 勤務• 2019年より、DB移行案件への技術支援を中心に活動中関わった案件： 70案件以上© 2021 NTT DATA Corporation2

概略
Oracle→PostgreSQLにDB移行する際の課題、解決方法
1. なぜPostgreSQLに移行するのか
2. 移行ツールで移行コストは下がるのか
3. 移行しやすいシステム、移行しにくいシステム
4. 技術的な課題とその対処– 数値演算結果の差異– 一時ファイル用領域をどうすべきか– 思わぬOut Of Memory– NULL/空文字問題– 拡張機能の選択© 2021 NTT DATA Corporation

3

なぜPostgreSQLに移行するのか© 2021 NTT DATA Corporation

4

なぜPostgreSQLに移行するのか

結局、「コスト削減」
ほとんどのお客様は、OSS-DBに移行することで単純にシステム維持コストが下がることを期待している。つまり、、

DB移行でコスト負担が増える
なら、移行などしない© 2021 NTT DATA Corporation

5

DB移行是非の判断

ライセンス＋保守費用が下がる。
その浮いたお金でDB移行を実施

商用DB

postgres

商用DBからOSS-DBに乗り換えることで、新規ライセンスの購入コスト、保守コストが節約できるが、その 「節約分のコスト内でDB移行を実現」 できなければGＯは出ない【判断基準】
商用DBをあと５年使い続けるコスト ＞ OSS-DBに乗り換え＋５年運用するコスト© 2021 NTT DATA Corporation

6

DB移行是非の判断【判断基準】
商用DBをあと５年使い続けるコスト ＞ OSS-DBに乗り換え＋５年運用するコスト
しかし、これはなかなか難しい・・・
まず、この試算を行い、DB移行にかけられるコスト枠を見極めることが必要
商用DB継続OSS-DB乗り換え ハード増強等をしなければ新規ライセンス購入は不要
 商用DB継続の場合もバージョンアップ対応の工数等はかかる クラウド移行する場合のライセンス料
変化 OSS-DBでも保守サポート契約は必要
 OSS-DBのEOLにより運用中のバージョンアップは発生する
 プラス、DB移行のコスト© 2021 NTT DATA Corporation

7

DB移行是非の判断【判断基準】
商用DBをあと５年使い続けるコスト ＞ OSS-DBに乗り換え＋５年運用するコスト
しかし、これはなかなか難しい・・・
まず、この試算を行い、DB移行にかけられるコスト枠を見極めることが必要
商用DB継続OSS-DB乗り換え

 ハード増強等をしなければ新規ライセンス購入は不要
 商用DB継続の場合もバージョンアップ対応の工数等はかかる クラウド移行する場合のライセンス料
変化 OSS-DBでも保守サポート契約は必要
 OSS-DBのEOLにより運用中のバージョンアップは発生する
 プラス、DB移行のコスト

DB移行コストの見積りは難しいため、他を見積り、まずはDB移行コストの枠を明らかにすべし© 2021 NTT DATA Corporation

8

PostgreSQLへの移行コストは何で決まる？
DB移行案件のタスクとはこのそれぞれのタスクの工数によりコストが決まる
DB基盤設計・構築
システム
アセスメント

定義移行

データ移行

切替

データ
移行

AP移行

© 2021 NTT DATA Corporation

試験9

PostgreSQLへの移行コストは何で決まる？
DB移行案件のタスクとはこのそれぞれのタスクの工数によりコストが決まる
DB基盤設計・構築
システム
アセスメント

定義移行

データ移行

切替

データ
移行

AP移行

システムにより大きく変動しやすいのは「AP移行」のコスト
 AP規模 使用している言語
 PostgreSQLに移行困難な機能の使用状況
 AP移行ノウハウを保有しているか© 2021 NTT DATA Corporation

試験10

PostgreSQLへの移行コストは何で決まる？
DB移行案件のタスクとは
このそれぞれのタスクの工数によりコストが決まる
DB基盤設計・構築
システム
アセスメント

定義移行

データ移行

試験

切替

データ
移行

AP移行

システムにより大きく変動しやすいのは「AP移行」のコストコストを下げるには？

 AP規模効率的なAP移行作業

 使用している言語

言語別の移行ノウハウ

 PostgreSQLに移行困難な機能の使用状況

代替機能のノウハウ AP・SQL移行ノウハウを保有しているか

AP・SQL移行ノウハウ© 2021 NTT DATA Corporation

11

DB移行を考えるその他の動機
コスト以外には下記のような理由が挙がる
1. ベンダロックインの回避
2. システムアジリティの向上（クラウド移行とセットで考えることが多い）
3. よりシステム用途に合った適切なDBの選択© 2021 NTT DATA Corporation

12

DB移行を考えるその他の動機
コスト以外には下記のような理由が挙がる
1. ベンダロックインの回避
2. システムアジリティの向上（クラウド移行とセットで考えることが多い）
3. よりシステム用途に合った適切なDBの選択

その点、PostgreSQLは移行先のOSS-DBとして非常に良い候補
開発コミュニティの独立性
活発な開発が続いている
大手クラウドサービスでマネジメントサービスとして提供
様々な拡張機能、カスタマイズ版PostgreSQLで特殊用途にも対応© 2021 NTT DATA Corporation13

移行ツールで移行コストは下がるのか© 2021 NTT DATA Corporation

14

移行ツールで移行コストを削減？
そもそも移行ツールが“効く”タスクは？
DB基盤設計・構築
システム
アセスメント

定義移行

データ移行

切替

データ
移行

AP移行

© 2021 NTT DATA Corporation

試験15

移行ツールで移行コストを削減？
そもそも移行ツールが“効く”タスクは？
DB基盤設計・構築
システム
アセスメント

定義移行

データ移行

切替

データ
移行

AP移行

この範囲

© 2021 NTT DATA Corporation

試験16

移行ツールで移行コストを削減？
主な移行ツール
DB基盤設計・構築
アセスメン
ト

定義移行

システ
ム

データ移行

試験

切替
データ
移行

AP移行

ツール

Ora2pgMnMTKDMS（SCT）

EDB Migration
Toolkit

開発元

OSS

Ispirer

AWSEnterpriseDB

定義移行

●

●

●

●

データ移行

●

●

●

●

●

●

●

●

PL/SQLAP
移行

java内
SQL埋め込み●C内SQL埋め込み●

Pro*C
AWSへの移行時のみ使用可

備考© 2021 NTT DATA Corporation

17EDBへの移行時のみ使用可

移行ツールで移行コストを削減？
移行ツールに過度な期待をしてはいけない
 AP資産が移行ツールで移行可能かどうか
まずはそもそもツールが移行対象としている言語であること。さらに、SQLの記述方法や使用しているDB機能によって変換精度が変わる。ほとんど変換できない場合もあるため、案件計画時に試すのが必須。

 移行ツールが生成したコードの試験移行ツールは書き換えの理由を説明しない。書き換えが正しいことを確認するブラックボックス
試験が必要であり、移行前DBと結果が同じになることを試験することになる。
 移行ツールが生成したコードのメンテナンス
システム運用中の機能追加など、コードに修正が入る場合がある。その際、自動生成されたコードのメンテナンス性は決して高くないことを理解する。
© 2021 NTT DATA Corporation

18

移行しやすいシステム
移行しにくいシステム© 2021 NTT DATA Corporation

19

（素の）PostgreSQLに移行しやすいシステム【コストが見合う】
DBサーバスペックが高い（コア数が多い）
AP規模が小さい【PostgreSQLの特性に向いている】
OLTP系であるシステムにDBが一つだけ© 2021 NTT DATA Corporation

20

（素の）PostgreSQLに移行しやすいシステム【コストが見合う】

DBサーバスペックが高い

DBサーバスペックが高い（コア数が多い）（コア数が多い）||

AP規模が小さい

維持コストが高い【PostgreSQLの特性に向いている】

すなわち、OSS-DB移行によるコストメ

OLTP系である

リットが生じやすいシステムにDBが一つだけ© 2021 NTT DATA Corporation

21

（素の）PostgreSQLに移行しやすいシステム【コストが見合う】

AP規模が小さい

DBサーバスペックが高い（コア数が多い）

AP移行コストが抑えられる

AP規模が小さい

これも、OSS-DB移行によるコストメリッ【PostgreSQLの特性に向いている】

トが生じやすいOLTP系であるシステムにDBが一つだけ© 2021 NTT DATA Corporation||22

（素の）PostgreSQLに移行しやすいシステム【コストが見合う】

基本的なSQLについてはOracleと同等

DBサーバスペックが高い（コア数が多い）程度のレベルであり、OLTP系システムでAP規模が小さいは移行後の性能担保が比較的容易。

一方、大量データ処理が得意ではなく、【PostgreSQLの特性に向いている】

DWHなど分析系システムの移行には工OLTP系である夫が必要。

システムにDBが一つだけ・大量データロード・大量データ集計
 PG_StromやCitusなどの拡張機能を検討© 2021 NTT DATA Corporation

23

（素の）PostgreSQLに移行しやすいシステム【コストが見合う】

Oracleに比べDBリンク機能が使いづらく、DBサーバスペックが高い（コア数が多い）

分散DB構成のシステムのAP移行は大きAP規模が小さいな変更が必要になることが多い。
 postgreSQLのDBリンク機能はdblink、dblink_plus、postgres_fdwといった【PostgreSQLの特性に向いている】

もの

OLTP系であるシステムにDBが一つだけ

例えば、「複数のOracle DBがDBリンクで強連携して稼働しているシステムについて、そのひとつをPostgreSQLに移行する」 というのは移行が困難。

© 2021 NTT DATA Corporation24技術的な課題とその対処※ 特にOracle → PostgreSQLの移行における© 2021 NTT DATA Corporation

25

DB移行のノウハウ
DB移行の各種ノウハウは、大量の公開リソースが存在。
 PGECons成果物

https://www.pgecons.org/works_index/「データベース移行」（WG2）の各種ドキュメント

 AWSのMigration Playbook

https://aws.amazon.com/jp/dms/resources/?nc=sn&loc=5「Oracle から Amazon Aurora PostgreSQL に移行する」 のリンクで「Oracle Database 19c To Amazon Aurora with PostgreSQL
Compatibility (12.4)」 が公開中

© 2021 NTT DATA Corporation26数値演算結果の差異
 精度指定なしのnumber、numericoracle

postgreSQL
numeric : 1

number : 1

numeric : 3

number : 3

select ( num1 / num2 ) * num2
from ～

select ( num1 / num2 ) * num2
from ～

結果 ⇒ 1

結果 ⇒ 0.99999999999999999999

精度指定なしのnumber型は浮動小数点型。postgreSQLではfloatにキャストする
ことで、ほとんど一致させられる。
postgreSQL
select ( num1::float / num2::float ) * num2::float from ～結果 ⇒ 1© 2021 NTT DATA Corporation27数値演算結果の差異
 整数リテラル
oraclepostgreSQL

select 1 / 3 from dual;

select 1 / 3 ;結果 ⇒ 0.3333333333

結果 ⇒ 0select ( 1 / 3 ) * 3 from dual;

select ( 1 / 3 ) * 3 ;結果 ⇒ 1

結果 ⇒ 0

postgreSQLは整数リテラルの演算は結果も整数となるように計算される。これもfloatにキャストすることで、ほとんど一致させられる。
postgreSQL
select 1::float / 3::float ;select ( 1::float / 3::float ) * 3::float ;結果 ⇒ 0.333333333333333

結果 ⇒ 1© 2021 NTT DATA Corporation28数値演算結果の差異
 精度指定ありのNUMBER／NUMERIC型を使用していれば、基本的に結果は合う。

 結果がずれる場合はとりあえずfloatにキャストしてみる

差異が出るとはいえ、どちらも計算結果が間違っているというわけではない。
しかし、DB移行前後で結果が変わるというのは受け入れられないことが多い。

© 2021 NTT DATA Corporation29

一時ファイル用領域をどうすべきか 一時ファイル
PostgreSQLは次の場合に一時的な作業ファイルを作る。
 work_memに収まらないソート（ディスクソート） work_memに収まらないハッシュ操作 一時テーブル（Temporary Table）利用時
つまり、Oracleの一時セグメントと同様の役割。
デフォルトの場所は PGDATA/base/pgsql_tmp

普通にPostgreSQLの基盤設計をすると、この一時ファイル用の領域はデフォルトのテーブル空間（業務データなどを格納）と同じストレージパーティションになる。つまり、、うっかり巨大なソート発生時などに、業務データ用のストレージFULLを引き起こし、DBが更新できない事態に！
© 2021 NTT DATA Corporation30

一時ファイル用領域をどうすべきか
うっかり巨大なソート発生時などに、業務データ用のストレージFULLを引き起こし、DBが更新できない事態
 対処
一時ファイル用のストレージパーティションを独立させる。
 一時ファイル用ストレージ容量＝全セッション合計の一時ファイル容量制限となる
 合計の一時ファイル容量オーバー時には、当該SQLだけがエラーとなる（そしてそのSQLが確保していた一時ファイル領域は解放される） 業務データのストレージを圧迫しない
つまり、Oracleの一時セグメントと同様の動作となる※ 後工程でストレージの切り直しをするのはハードルが高くなるため、DB基盤設計時に考慮しておくことが大事。

※ ちなみにtemp_file_limit（セッションあたりの一時ファイル最大容量）の設定で対処しようとするのは悪手© 2021 NTT DATA Corporation31思わぬOut Of Memory

このケースですが、会場でご指摘があった通り、psqlがいったん結果セットを保持するために起きているOOMでした。
DB側で大量メモリを獲得してしまう再現ケース 1万件程度のテーブルを作り、自分同士を直積結合させてみるを用意できなかったため、このケースについて取り下げさせてください。
create table test (id integer);

insert into test select generate_series(1, 10000);
select * from test a, test b;--10000件挿入-- 結合条件なしで直積結合

結果

このテスト環境はメモリ4GB程度だったが、簡単にメモリを食いつぶし、Out Of Memory 。
※Oracleではこのようなことはほぼ起きない

SQL実行で消費するメモリ量上限は設定できない。
テスト済みの業務機能が発行するSQLでは、異常なメモリ消費が起こるリスクは限りなく小さい。
しかし、例えばBI系システムのユーザ自由検索などで想定しないSQLが組み立てられ実行されることがあり、これによるOOMリスクがある。
© 2021 NTT DATA Corporation32

思わぬOut Of Memory

このケースですが、会場でご指摘があった通り、psqlがいったん結果セットを保持するために起きているOOMでした。
DB側で大量メモリを獲得してしまう再現パタンを用意できなかったため、このケースについて取り下げさせてください。

BI系システムのユーザ自由検索などで想定しないSQLが組み立てられて実行されることがあり、これによるOOMリスクがある。

 OOMは他セッションに大きな影響を及ぼす。DBが落ちる場合もあり、商用サービス提供しているDBでは起こしてはならない障害。
 直積結合だけではなく、大量件数のテーブルを多数結合する場合なども危ない
十分テスト済みのSQLしか実行されないのであれば問題ないが・・・
自由検索インターフェースをユーザに提供し、任意のテーブル結合が行われるシステムでは・・・【対処】自由検索をレプリカ側で実行し、最悪落ちてもいいDBとする※ なお、Aurora等マネジメントサービスのPostgreSQLでも起こります。
（メモリ使用量を直接観測できないため、よりやっかい）© 2021 NTT DATA Corporation

33

NULL/空文字 問題
 OracleはNULLと空文字を区別しない

OraclePostgreSQL‘’(空文字)は・NULL
・長さ０の文字列
場合に応じて両方の意味で扱われる‘’（空文字）は長さ０の文字列
NULLも格納可能で、’’ とは別物

OraclePostgreSQL‘’ （＝ NULL）‘’（空文字）NULL

WHERE str IS NULL

TRUE

FALSE

TRUE

length(str)

NULL

0

NULL

str || ’abc’

‘abc’

‘abc’

NULL

定型的なうまい移行方法が確立されていない© 2021 NTT DATA Corporation

34

NULL/空文字 問題
 対処

まずはOracleのNULL（=空文字）を、NULLか空文字か、どちらで移行するかを決める。
そして、対処方針に合わせて、データ移行やAP改修を行う。

© 2021 NTT DATA Corporation

35

NULL/空文字 問題
Oracleの ‘’（＝NULL）を・・・

str IS NULL
str || ‘abc’

NULLとして移行‘’ (空文字) として移行

 データ移行時にNULLとして移行する
 insert/updateしようとしている値が空文字だった場合、NULLに変換する。

 データ移行時に ’’ として移行する
 insert/updateしようとしている値がNULLだった場合、空文字に変換する カラム追加等のテーブル定義変更時には暗黙的にNULLが入ってしまうので、それも’’に直す

結果の違い

結果の違い

対策例

結果がFALSEになる

str IS NULL OR str = ''対策例－
NULLとなる

CONCAT(str,’abc’)－－

colA ＝ colB の両方が colA = colB
空文字だった場合に結 and colA != ''and colB != ''合できてしまう。

結合－
文字列操作
関数

trimやlength等の関数 TRIM(COALESCE(col,‘’))の結果がNULLになる。LENGTH(COALESCE(col,''))

javaで値を取得する

string型の内容がNULLとなる© 2021 NTT DATA Corporation

NULLを受け入れるようにAP修正。
36

－－－－－

拡張機能の選択
 拡張機能PostgreSQLと言えば拡張機能。
ワールドワイドで魅力的な拡張機能の開発が盛んで、開発中システムで大いに役立ちそうなものも見つかるはず。

しかし、マイナーな拡張機能はそのメンテナンスが中止されることも多く、次回のPostgreSQLアップグレード時に新バージョン対応版が無いなど、詰んでしまう事態に【対処】
基本的には本体機能！
拡張機能は、数年後もメンテナンスが継続していそうな、メジャーなものを採用する© 2021 NTT DATA Corporation37さいごにDXケーススタディの発信サイト「デジタルテクノロジーディレクター®」
https://ndigi.tech/新着記事
 デジタル時代におけるデータベース移行戦略
https://ndigi.tech/all_post/14038
 データベース移行で「攻める」ビジネスを
https://ndigi.tech/all_post/12987
 企業のDXをさまたげるレガシー資産
https://ndigi.tech/all_post/11967

デジタルテクノロジーディレクター

記載されている会社名、商品名、又はサービス名は、各社の登録商標、又は商標です。
© 2021 NTT DATA Corporation38