OracleからSnowflake移行のSQL非互換対応まとめ
記事の目的
Oracleからsnowflakeへの移行事例はそれなりにあると思いますが、
その技術的な課題や対処についてのノウハウはなかなか世に出る事はないと思います。
そこで皆様の一助になればよいと思い、
弊社が2022年にOracleからSnowflakeへ移行PoCをする中で検出した、
主にSQL非互換とそれに対する対応方法についてまとめたものを公開いたします。
また現在はSnowflakeより、マイグレーションツールであるSnowConvertが提供されています。
こちらで要件を満たせる場合は、ツールを活用した移行の実施が良いと思います。
ただ諸々の環境面やプログラム構造的な課題でツールによる置き換えが困難であれば、
この記事が参考になると思います。
なお、弊社のOracleからの移行含めた全体像は、以下の記事を参考にしてください。
注意
弊社で移行PoC時に存在したプログラムやDDL/DMLベースでの検証となり、
PoC後の本番移行でのプログラム動作確認で新種が見つかったケースもあります笑
（クリティカルなものはありませんでしたが）
そのため、対応方法の網羅性や妥当性を保証するものではないため、
どのような対応が必要なのかを大まかに捉える、規模感の参考としてください。
性能面の評価
そもそも取り扱うクエリのパターンや既存システムの規模とsnowflakeの適用サイズで大きく変わるので、自社内でしっかりと評価いただくのが何よりも重要です。
ただ弊社ではExadataで割り当てているCPUを元にLサイズをターゲットにした結果としては
現行システムを比べ、ほぼ半分の処理時間＝性能2倍に向上と判断しました。
とはいえ、ショートクエリ（処理時間が短いクエリ）では、Oracleの方が早いケースもあり、
ショートクエリというかトランザクション的な処理はOracleが強いと判断し、
その上で許容範囲と判断しました。
※オレンジが性能悪化したクエリ。
後半は遅くなっているじゃん？ですが、処理時間の大きい順で、下に行くほど元々のクエリ時間が短いです。
snowflakeの場合、ウエアハウス上げたり、ワークロード別に分割したり、クラスタリング貼ったり、Search Optimizationなど、色々工夫出来る手段があるので個人的にはよほど予算をケチらなければ性能問題はないと考えています！
非互換の精査方法
2022年にOracle Exadataからのクエリパターン別のPoCを実施し、
SQL変換時に構文エラーや出力結果に差異が生じたものに対する移行方針を精査しました。
※この時点ではSnowconvertが適用出来ず、自力でやらざるを得なかった次第です。。
このパターン精査は、Snowflakeのドキュメントをベースにしつつ、
Oracleの各プログラムを単純処理から複雑処理、特にPL/SQLの処理パターンなど、
怪しそうな関数をピックしたり、ソースを何度もGrepしたりと洗い出しをひたすらしていきました。
※調査時点の結果のため、現在は解消しているものや対応方針が変わっている可能性があります
非互換一覧
弊社のPoCでは全部で54種ありました。
当然プログラム改修もかなりの規模です。
PoCも性能面はあまり心配しておらず、移行コストを試算するために互換性評価が要点でした。
さて、以下にその詳細をまとめています。
構文系①（DDL）
Oracleのみに存在するDDL上の構文や制御に関する非互換のため、該当部分の削除（使えない）
構文系②（DML）
OracleのSQL記述式の差異による非互換のため、該当部分の置き換えや構文修正で対応する
構文系③（PL/SQL）
OracleのSQL記述式の差異による非互換のため、該当部分の置き換えや構文修正で対応する
関数差異
関数名は同じだが、振る舞いや仕様の差異があるもの。適切な関数への置換や記述の調整が必要
データ型、NULLの取り扱い
Snowflakeは文字型が集約されており、運用しやすいのだが、
レガシーから移行の場合、Charなどの固定桁数を埋めるような振る舞いは個別に入力値の確認が必要
またOracle特有の、”よしなにやってくれる”が、NULL周りでは鬼門となる
その他のケース
上記に該当しないような個別にケースや特定パターンで生じる対応
※PoC時点での検出内容ですが、本番移行対象のプログラムの中でも新種が生まれています。。
元々PoC時に課題管理していたEXCELベースですので、
見づらいなーとかこうして欲しいなど要望あれば、Xのアカウント宛にご相談ください。
かなり細かい内容なので、役に立たないかもしれませんが、
お役に立つようでしたら、いいね❤を付けていただければ、
モチベーション上がってまた何か書き始めるかもしれません笑
皆さんのモダンデータスタックに向けたレガシー脱出の一助になれば幸いです。
（弊社も頑張ります！）
Discussion