こんにちは。utsugiです。今回は、オンプレミスのOracleのデータを、マテリアライズド・ビューを利用してRDS for Oracleに移行する方法について考えていきたいと思います。
データ移行というよりも、データ連携やパフォーマンス向上のために用いられるケースが多いと思いますが、データ移行にも利用することができます。
目次
∗ マテリアライズド・ビューについて ∗ OracleからRDSへのマテリアライズド・ビューを利用したデータ移行の流れ ∗ マテリアライズド・ビューを利用した移行のメリット ∗∗ダウンタイムが短くなる ∗ マテリアライズド・ビューを利用した移行のデメリット ∗∗ 移行元にログを作成する必要がある ** オンプレミス環境と直接繋ぐ必要がある ∗ まとめ
マテリアライズド・ビューについて
マテリアライズド・ビューはOracleに搭載された機能の1つです。普通のビューは実際にデータを保持することはありませんが、マテリアライズド・ビューは、データを保持するという点が、最も大きなビューとの違いです。
【マテリアライズド・ビューの特徴】 ・差分を取得したい場合はマスターとなるテーブルに対応するログを作成する必要がある ・データを保持する ・マスターからデータを直接的に取得する ・移行元/先のオンプレミス/クラウド環境の組み合わせに制限はない ・異種間のデータベースの移行に対応していない ・対象データの一括移行に対応している ・更新差分のレプリケーションに対応している ・定義情報の移行に対応していない
マテリアライズド・ビューは更新差分のレプリケーションにも対応しています。これが、データ移行という観点で見た場合の、マテリアライズド・ビューの特筆すべき点かと思われます。
ただし、更新差分を取得するためには、マテリアライズド・ビューだけでなく、データ取得元に「こういう更新がありました」という情報を保持するログを作成する必要も出てきます。
若干手間がかかったり、移行元環境の変更を行ったりする必要がありますが、レプリケーションにも対応している、優秀な機能です。
OracleからRDSへのマテリアライズド・ビューを利用したデータ移行の流れ
それでは、おおよその流れについて見ていきます。
図: マテリアライズド・ビューを利用してデータを移行する
①データベースリンク作成 マスター・テーブルがリモートにある場合、データをSQL*Net経由で取得する必要があるため、移行元に対するデータベース・リンクを移行先に作成します。 作成のDDLはCREATE DATABASE LINKをご参照いただければと存じますが、サンプルを下記に記載致します。
CREATE DATABASE LINK <データベースリンク名> CONNECT TO <移行元に接続するユーザ名> IDENTIFIED BY <移行元に接続するユーザパスワード> USING '<接続記述子>’ ;
②マテリアライズド・ビュー・ログ作成 今回の例では、ダウンタイムを短くするために更新データもレプリケーションします。この場合、「こういう更新があった」という情報を保持しておく必要があり、それに利用するのが、マテリアライズド・ビュー・ログです。これは、マスター側、つまり、移行元に作成します。 作成のDDLはCREATE MATERIALIZE DVIEW LOGをご参照いただければと存じますが、サンプルを下記に記載致します。 [shell] CREATE MATERIALIZED VIEW LOG ON <マスターテーブルのスキーマ>.<マスターテーブル> ; [/shell]
③マテリアライズド・ビュー作成 移行元からデータを取得するために、マテリアライズド・ビューを作成します。マテリアライズド・ビューでは、以下のように、3種類のリフレッシュの方式(マスターのデータ取得方式)と、4種類のリフレッシュのタイミングを選択できます。 基本的に設定は自由ではありますが、方式は「FORCE」で、タイミングを「ON DEMAND」にすると、「任意のタイミングで、差分のみ適用可能ならば差分だけを、不可能ならば全量を取得する」と設定ができます。
表: マテリアライズド・ビューのリフレッシュの方式
| 方式 | 内容 |
|---|---|
| FAST | 高速リフレッシュ(差分)の方式が適用されます。 |
| COMPLETE | 完全リフレッシュ(全量)の方式が適用されます。 |
| FORCE | 高速リフレッシュ(差分)が利用可能な場合は高速リフレッシュを、利用不可能な場合は完全リフレッシュ(全量)の方式が適用されます。 |
表: マテリアライズド・ビューのリフレッシュのタイミング
| 方式 | 内容 |
|---|---|
| ON COMMIT | マスターに対するトランザクションがCOMMITされる度に、リフレッシュが実施されます。 |
| ON DEMAND | 明示的に手動でリフレッシュを実行しない限り、リフレッシュされることがなくなります。 |
| ON STATEMENT | マスターに対してDMLが実行される度に、リフレッシュが実施されます。 |
| START WITH・NEXT | 指定した時刻にリフレッシュが実施されます。 |
作成のDDLはCREATE MATERIALIZED VIEWをご参照いただければと存じますが、サンプルを下記に記載致します。
CREATE MATERIALIZED VIEW
<スキーマ>.<マテリアライズド・ビュー>
REFRESH FORCE
ON DEMAND
AS
SELECT
*
FROM
<スキーマ>.<テーブル>@<データベース・リンク>
;
④完全リフレッシュ まずは、完全リフレッシュを行います。リフレッシュはREFRESHプロシージャを利用するのが簡単だと思われます。
EXEC DBMS_MVIEW.REFRESH('<マテリアライズド・ビュー>');
⑤更新停止 マテリアライズド・ビューをリフレッシュするたびに差分データもレプリケーションできますが、アプリケーションの向き先を変更するためにも、停止時間は必要です。
⑥高速リフレッシュ 高速リフレッシュを行います。こうすることで、④で実施した完全リフレッシュの後に更新されたデータを移行先に反映することができます。
⑦整合性確認 高速リフレッシュが正常に終了した時点で、データ的には移行元テーブルと移行先マテリアライズド・ビューで同期がとれた状態になりますが、欠落やロジックエラー等が発生していないか、データの整合性を確認します。
⑧マテリアライズド・ビュー削除 マテリアライズド・ビューを削除し、テーブルに戻します。この操作により、これ以降、リフレッシュを行うことはできなくなりますが(マテリアライズド・ビューではなくなったため)、この時点まででリフレッシュによって取得したデータは保持されたままとなります。
DROP MATERIALIZED VIEW <スキーマ>.<マテリアライズド・ビュー> PRESERVE TABLE ;
⑨更新再開 データの整合性まで確認出来たら、アプリケーションの更新先を移行先に変更します。
マテリアライズド・ビューを利用した移行のメリット
ダウンタイムが短くなる
マテリアライズド・ビュー・ログによりデータの更新情報が保持できているので、移行元DBに対する更新を停止した後のリフレッシュが終われば、完全に同期がとれた状態となります。また、事前に完全リフレッシュを行っておけば、高速リフレッシュの時間は通常の全量移行よりも圧倒的に短くすることができます。
また、全量の移行(初回の完全リフレッシュ)は事前作業としてダウンタイムなしで行うことができるため、極力ダウンタイムを短くしなければならないという要件がある場合、これは極めて大きなメリットとなります。
マテリアライズド・ビューを利用した移行のデメリット
移行元にログを作成する必要がある
マテリアライズド・ビューの高速リフレッシュを利用するには、マテリアライズド・ビュー・ログを移行元に作成する必要があります。つまり、ログを保持可能な分だけの容量を移行元に確保しておく必要があるということです。
移行時点で既に移行元の容量に余裕がない場合、ディスクがあふれてしまう危険性もあるため、事前に更新量とディスク領域の余裕についての検討が必要です。
オンプレミス環境と直接繋ぐ必要がある
マテリアライズド・ビューは移行元DBのデータを参照する必要があるため、必然的に、クラウド環境に存在するRDSからオンプレミス環境に存在するOracleにアクセスできるようにしないといけません。
Direct ConnectやVPNを利用することで安全性は高まりますが、現状、完全に閉じたネットワーク上に存在しているDBの場合、セキュリティ要件を満たすのが難しくなるかもしれません。
まとめ
今回は、少し例を挙げつつマテリアライズド・ビューでのデータ移行について見てきました。
ネットワーク的に移行元と移行先を直接繋ぐことが必要であったり、マテリアライズド・ビュー・ログを作成する必要があったりと、万能というわけではありませんが、Oracleの機能を使いつつもダウンタイムを短くしたいというケースでは、有力候補となり得るのではないでしょうか。
