オンプレからADBへのデータ移行。正月休みを獲得した方法 [Oracle]

JPOUG#11で発表した内容です。

Transcript

1. Oracle Cloud 失注への軌跡 ～ 努力は無駄にならない ～ しゃちほこオラクル倶楽部 第７回 西尾 孝之 オンプレからADBへのデータ移行 ～ 正月休みを獲得した方法 ～ 2025年1月24日 【JPOUG Teck Talk Night #11】 - Takayuki Nishio -
2. オーガナイザー紹介 | 西尾 孝之 / Takayuki Nishio 資格 ・ORACLE MASTER : Platinum DBA 2019, 12c , 11c , 10g , 9i , 8i ・AWS : Database Speciality , Data Analytics 認定証 ・マッターホルン登頂…4478m ・モンブラン登頂………4810m ・キリマンジャロ登頂…..5895m Oracleと山を愛するエンジニア(21年目)
3. 本日アジェンダ｜ オンプレからADWへのデータ移行 目指せ 正月休みの獲得！ 56時間かかるデータ移行を土日におさめる！ 予想される未来 理想 ODA (19c EE-RAC) Oracle Autonomous Data Warehouse ( 19c EE )
4. システム構成 ｜ 移行前後のシステム構成 オンプレ(ODA)からOCI上のADWへデータ移行 以下の工程で行うことがきまっていた。 OCI（Tokyo-Region） オンプレ Object Storage Oracle Autonomous Data Warehouse ( 19c EE ) ODA (19c EE-RAC) ①エクスポート ②クラウドへ転送 ③インポート ④事後処理 （統計取得・圧縮） DMP ファイル DMP ファイル Compute ＜データベース情報＞ サイズ 6 TB テーブル数 1 万 パーティション数 4 万 データ件数 380 億件
5. 本セッションでの着目ポイント ｜ 知っていると得をするかもしれないことを紹介 ＜セッションで扱う範囲＞ クラウドへの移行をチューニング 知っていればあたりまえ。でも知らないとはまってしまう。 そんな、すぐに効果がでそうなものを紹介します。 ＜扱わない範囲＞ オンプレでも同様に使用できる一般的な移行チューニング ・事前移行（本番移行当日より前に移行できるデータの整理） ・移行先をNOARCHIVELOGモードにしておく ・索引を一時的に無効にする（削除する） ・GoldenGate等、ツールの利用
6. 免責事項 DBによっては効果が異なることもあります。 1つの検討ポイントとしてご覧ください。 次ページ以降は、実案件の経験をもとに以下の環境で検証した結果です。 ＜OCI環境＞ Autonomous Database (ADW) ECPU = 4 ストレージ 6TB ＜データベース情報＞ サイズ 1.2 TB テーブル数 3000 データ件数 13 億件
7. ①エクスポートとクラウド転送時間の短縮 ｜ 圧縮 オンプレ環境でエクスポートすると、4時間37分。 DMPファイルサイズが 1036 GB。 クラウドへの転送速度が 20MB/秒のため、転送だけで14時間かかった。 4時間37分 14時間45分 サイズ 1TB
8. ①エクスポートとクラウド転送時間の短縮 ｜ 圧縮 expdpのCOMPRESSIONオプションが効果的だった。 エクスポートでCOMPRESSIONオプションを指定すると、エクスポート時間は 長くなるが、ファイルサイズが小さくなる。クラウド転送時間を考慮すると トータルでは圧縮したほうが早かった。 COMPRESSION DMPファイルサイズ EXPORT時間 転送時間 合計時間 圧縮無し 1036 GB 4時間 37分 14時間 45分 18時間 22分 ALL（圧縮あり） 232 GB 6時間 8分 3時間 17分 9時間 25分 expdp system/xxx dumpfile=xxx logfile=xxx SCHEMAS=USER1 COMPRESSION=ALL ※EnterpriseEdition＋AdvancedCompressionが必要
9. ②インポート時の接続サービス ｜ HIGH / MEDIUM / LOW 接続サービスでけっこう差が出た。他作業なければHIGH！ ADWでは接続サービスが3つ用意される。 用途によって使い分けるがインポート時はHIGH。 impdp ADMIN/xxx@HIGH dumpfile=xxx logfile=xxx SCHEMAS=USER1 ECPU数 接続サービス インポート時間 4 HIGH 9 時間 18分 4 MEDIUM 9 時間 47分 4 LOW 18 時間 19分
10. インポート時の気づき ｜ リソースに余裕があるぞ HIGHにしても、リソースに余裕があるような気がする。。。なら！ インポート実行時間
11. ECPU数 接続サービス Parallel オプション インポート時間 4 HIGH （指定なし） 9時間 18分 4 HIGH 2 9時間 12分 4 HIGH 4 5時間 23分 ③インポートのPARALLELオプション ｜ 並列化 PARALLELオプションをECPU数と同じにする ADWはパラレル処理に強いはず。 PARALLELオプションを付与することで高速化できた！ スキーマやテーブルごとにdmpをわけて、impdp自体を複数流すのもアリ。 impdp ADMIN/xxx@HIGH dumpfile=xxx logfile=xxx SCHEMAS=USER1 parallel=4
12. ④移行時のみECPU数を増やす ｜ リソース変更 移行時のみECPU数を増やす オンプレではできない手法。移行時のみECPU数を増やす。 しかもADWはオンラインでECPU数を変更可能なため、普段の業務処理に も活用しやすい。 impdp ADMIN/xxx@HIGH dumpfile=xxx logfile=xxx SCHEMAS=USER1 parallel=4 ECPU数 接続サービス Parallel オプション インポート時間 4 HIGH （指定なし） 9時間 18分 4 HIGH 4 5時間 23分 8 HIGH 8 3時間 39分 32 HIGH 32 3時間 8分 64 HIGH 64 1時間 17分
13. テーブルの圧縮に関する話 ｜ ADWでのデフォルトはCOMPRESSあり ADWの強力なテーブル圧縮機能HCC ADWでは 「create table xx (id number)」 で表を作るとデフォル トで圧縮（compressオプション）が有効となる。 オンプレから移行してくる場合、オンプレで圧縮されていなければインポー ト時に圧縮されない状態となるため、有効にしたいという要望があった。 インポート後に全テーブルを圧縮してみたところ、圧縮に5時間かかった。 ※マニュアルによると、後からでもバックグラウンドで可能とあるため あとからでもよかったかもしれない 効果は 1.2 TB の セグメントサイズが、500GB になった。
14. ⑤ADW上でのテーブル圧縮する順番 ｜ 圧縮⇒インポート テーブルの圧縮オプションを有効にしてから、インポートする インポートを2回に分ける。 1回目のインポートでCONTENT=metadata_onlyを指定。 圧縮後、2回目のインポートでCONTENT=data_onlyを指定。 先に圧縮するとデータのインポートに時間はかかるようになったが、 トータルでは早くなった。 移行順序 インポート 圧縮 インポート 合計時間 ①インポート（Meta,Data） ②圧縮 5時間 23分 (Meta,Data) 5時間 46分 - 11時間 9分 ①インポート（Meta） ②圧縮 ③インポート（Data） 4分 (Meta) 3分 7時間 53分 (Data) 8時間
15. まとめ エクスポートで圧縮オプション指定 インポートでPARALLELオプション指定 インポート時にECPU数を増やす 先にテーブルを作成し圧縮してからインポート
16. 【Appendix】 ADWへの移行 ｜ 危険時間帯 ADW移行の危険時間 土曜日20時！ ※時間は環境によって異なる ADWは土曜日にメンテナンスが発生。基本的にメンテナンスはオンラインで行わ れるがセッションが瞬断する可能性あり。インポートもORA-エラーで停止した。 この時間帯は避けて実行できるよう手順を検討
17. ありがとうございました Thank you