Oracle Data Pumpによる移行方法（クラウドリフト時の移行ケースと注意点）

## はじめに
Oracle Data Pumpは、オンプレミスからクラウドへの移行時にもよく使用されるツールです。
今回は、Oracle Data Pumpによるクラウドリフト時の移行ケース注意点についてご紹介していきます。

また、本記事の内容は、

**第8回 Oracle DBaseCamp**
**【Oracle Data Pumpによるエクスポートとインポート】**

に登壇した際の内容になります。

詳細についてご覧になりたい方は、以下の録画や資料を参考にしてみてください。
* 録画

https://youtu.be/ysJdrpuwkNY

*資料

https://speakerdeck.com/oracle4engineer/oracle-dbasecamp-8

## Oracle Data Pumpによるデータ移行手順のおさらい
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3072173/b8fbc51a-3f8f-52b1-7fc6-5f8ee6cce5c3.png)
移行の流れについてですが、まずはソース・データベースから**ダンプ・ファイル**を**エクスポート**して、それをターゲット環境に**scpコマンド**で転送して、ターゲット環境で**インポート**を実行するといった流れになっています。

OCIチュートリアルの「[Data Pumpを利用してデータを移行しよう](https://oracle-japan.github.io/ocitutorials/adb/adb303-datapump/)」も参考になりますので合わせてご覧ください。

ここでは、他ではあまり紹介されていない各フェーズごとのTipsについて紹介していきます。

### 【事前設定】
#### 初期化パラメータSTREAMS_POOL_SIZE の設定
Oracle Data Pumpでは**Advanced Queuing**を使うため、メモリ領域である**STREAMS_POOL_SIZE**を使用します。
その領域を確保するため、STREAMS_POOL_SIZEを設定しますが、Oracleの推奨範囲としては<INS>**64 MBから256 MB**</INS>の範囲になるように設定していきます。

**STREAMS_POOL_SIZEの値を確認**
~~~SQL
SELECT CURRENT_SIZE/1024/1024 AS CURRENT_SIZA_MB
FROM v$SGA_DTNAMIC_COMPONENTS 
WHERE COMPONENT='STREAMS POOL';
~~~
**実行結果例**
~~~
CURRENT_SIZE_MB
---------------
            128
~~~
**（不足している場合）STREAMS_POOL_SIZEの値を指定するコマンド**
~~~SQL
ALTER SYSTEM SET STREAMS_POOL_SIZE=256M SCOPE=BOTH;
~~~

### 【エクスポート】
#### ダンプ・ファイルのサイズ見積もり
ESTIMATEパラメータを使用してダンプ・ファイルを生成せずとも見積もりが可能なため、出力されるダンプ・ファイルのサイズに対して準備した領域が十分かを確認することができます。
指定できる見積もりモードとしては、**BLOCKS**と**STATISTICS**があります。

:::note info
* **BLOCKS**：ブロックサイズにオブジェクトのブロック数をかけて見積もる
* **STATISTICS**：統計情報を元に見積もる

Oracle公式に精度が高いと言われているのはSTATISTICSになっています。
:::

**ESTIMATEパラメータの実行例**
~~~
expdp <ユーザー名>/<パスワード> FULL=Y 
DIRECTORY=<ディレクトリ名> ESTIMATE = STATISTICS
ESTIMATE_ONLY=Y;
~~~

### 【ダンプ・ファイルの転送】
ダンプ・ファイルの転送では、**scp**というファイル転送コマンドを使用してターゲット側に転送します。
LinuxやUNIX系のOSの場合、**nohup**というコマンドをscpの前につけて実行することで、転送中にセッションが切れても転送を継続させることが可能です。

**nohupを使用したscpコマンド例**
~~~
nohup scp -i /home/opc/.ssh/ssh-key-2024-02-20.key /tmp/datapump/dumpfile* opc@10.0.1.41:/tmp/datapump
~~~

### 【インポート】
#### 移行データの確認
インポート完了後にデータがしっかりと移行されているかの確認を行います。

**■ ソース・データベースとのデータ量を比較**
こちらはあくまでも例ですが、まずは、ソース側とターゲット側でデータ量を比較するために、データ容量を確認するコマンドを実行します。
* **実行コマンド例**
~~~SQL
SELECT SUM(bytes)/(1024*1024*1024)"SIZE[GB]"
FROM DBA_SEGMENTS WHERE OWNER = 'SCOTT';
~~~
* **実行結果例 (ソース側)**
~~~
   SIZE[GB]
----------
1021.92725 
~~~
* **実行結果例 (ターゲット側)**
~~~
   SIZE[GB]
----------
1017.89063
~~~
ソース・データベースとターゲット・データベースで比較すると、この例の場合、ターゲット側が4 GBほど少ない結果となっています。
ターゲット側のサイズが少なくなる理由としては、<INS>**インポート処理ではOracle Data Pumpプロセスがデータを空きスペースがないようにブロックにデータを入力していくため**</INS>です。
特に断片化されたデータベースの場合は、さらにデータの減少が大きく表れます。
また、Oracle Data Pumpの処理では、索引が再作成されるため、データが減少するといったこともあります。

**■ 移行したスキーマのテーブルの種類やオブジェクトの数が一致するか確認**
データとテーブルの一覧を表示して確認したり、そのテーブル内のそれぞれのレコード数を確認したり、オブジェクト一覧の確認などを実施することで、データの抜け漏れなく移行できていることを確認できます。

**テーブル一覧の確認 (例)**
~~~SQL
SELECT TABLE_NAME FROM DBA_TABLES
WHERE OWNER = 'SCOTT';
~~~
**テーブルそれぞれのレコード数の確認 (例)**
~~~SQL
SELECT COUNT(*) FROM SCOTT.CUSTOMERS;
~~~
**スキーマ所有のオブジェクト一覧の確認 (例)**
~~~SQL
SELECT OBJECT_NAME, OBJECT_TYPE FROM DBA_OBJECTS WHERE OWNER = 'SCOTT' ORDER BY OBJECT_NAME;
~~~

## Oracle Data Pumpを利用したオンプレミスからクラウドへの移行ケース
Oracle Data Pumpを利用したクラウドリフト時の移行ケースについて紹介します。
移行ケースとしては大きく以下の2種類があります。
* ダンプ・ファイルを利用したクラウドへの移行
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3072173/82a14856-3fc3-241b-b57c-12fdc4334628.png)
クラウド・ストレージを利用して、ダンプ・ファイルのエクスポートおよびインポートを行います。
　
* データベース・リンクを利用したクラウドへの移行
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3072173/eb051616-93d4-311a-f1b0-1b2d7f2ee021.png)
データベース・リンクを利用すると、オンプレミスからクラウドのデータベース上に直接データのインポートを行えるので、クラウド・ストレージの利用が必要ありません。
しかし、ネットワーク帯域やデータサイズなど、ボトルネックになりそうな箇所はあらかじめ考慮が必要となります。

## Oracle Data Pumpを利用したオンプレミスからクラウドへ移行する場合の注意点
今回はOracle Data Pumpを利用したクラウドリフト時の注意点について2点紹介します。

**■ 圧縮無効化による容量の肥大化**
大規模なデータをお使いになっているお客様では、**Hybrid Columnar Compression** (**HCC**)を使っている場合も多いと思います。
そういったお客様においては、移行時の<INS>**ダンプ・ファイルはHCCによる圧縮が無効**</INS>になり、容量が肥大化してしまうため、ネットワーク帯域幅によってはデータ転送に時間がかかる可能性があります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3072173/804ea91f-4182-0460-459a-7d36a01556ff.png)

**■ PaaS上でのファイルシステムの領域が小さい**
PaaSへの移行の場合、<INS>**OS上で割り当てられているファイルシステムの領域が小さい**</INS>ため、クラウド上でのストレージサービスの利用を推奨しています。
**Oracle Cloud Infrastructure** (**OCI**)のPaaSサービスである**Oracle Base Database Service**の場合、全体の容量に対して、ダンプ・ファイルなどの出力先の領域が小さいため、OCIのストレージサービスである**OCI Object Storage**などを利用することを推奨しています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3072173/35941112-9c71-7596-01e8-0f9157f07233.png)

## おわりに
今回は、Oracle Data Pumpによるクラウドリフトの移行ケースと注意点について解説しました。
Oracle Data Pumpについて、更に詳しく知りたい方は以下の記事もご参考にしてみてください。

:::note info
* [Oracle Data Pumpによるエクスポートとインポートの基礎](https://qiita.com/yunagash/items/15625a0b6010ee83de1a)
* [Oracel Data Pumpのアーキテクチャから理解する「PARALLELパラメータとワーカー・プロセスの関係」](https://qiita.com/yunagash/items/d9654d74257b19145619)
* [Oracle Data Pumpの機能紹介 ～Enterprise Editionおよびオプションで利用できる機能～](https://qiita.com/yunagash/items/57cb29729bfdad52da2d)
* [Oracle Data Pumpのベスト・プラクティスと代表的なパラメータ](https://qiita.com/yunagash/items/aa41b3a2d916761807dc)
* [Oracle Data Pumpのエクスポート時のジョブの中断、再開、強制終了の方法](https://qiita.com/yunagash/items/e06eb0fd4b1824bd09e0)
:::