2021年2月1日 / 最終更新日時 : 2021年2月2日テクバンOracle Cloud Infrastructure(OCI) 担当 Oracle Cloud Infrastructure(OCI)

GoldenGateによるOCI-C⇒OCI移行

こんにちは。Oracle Cloud Infrastructure(OCI)特集編集部です。

Oracle Cloud Marketplace の Oracle GoldenGate Microservices を利用して
Oracle Cloud Infrastructure Classic(OCI-C) ⇒ Oracle Cloud Infrastructure(OCI)
への移行を行いましたので、ご紹介します。

１．GoldenGateの仕組み

　Oracle GoldenGateには、Classic、Microservices の2つのアーキテクチャが存在します。
　各アーキテクチャについては、以下を参照ください。

　Oracle GoldenGateの理解 – Oracle GoldenGateのスタート・ガイド

　┗ Oracle GoldenGateアーキテクチャの概要
　┗ Oracle GoldenGate Microservices Architectureのコンポーネント
　┗ Oracle GoldenGate Classic Architectureのコンポーネント
　┗ 共通データ・レプリケーション・プロセス

２．移行手段の選択

　DB移行の要件は以下の通りでした。
　・OCI-C環境からOCI環境への移行
　・DBCSを使用（SE 18c）
　・移行対象はDBインスタンス３つ（PDB）
　・合計スキーマ数は約43000
　・ダウンタイムは１日程度で切り換えたい
　・前回移行はDataPumpで順次移行し、数か月かかったが、今回は1発切替を希望

　2020年12月末迄、OCI Cloud Database環境へのレプリケーション用途に限り、
　Oracle GodenGate部分が無償で利用できたので、Oracle GodenGate Microservices
　（以降、GG）を使用することにしました。

　システム構成イメージを下記します。

　■システム構成イメージ

３．事前調査

　１）差分同期が不可能なオブジェクトやDDL・DMLの確認

　　Oracle DatabaseのためのOracle GoldenGateの使用 – 1 サポート対象の理解

　　┗ 1.1 サポートされるOracleデータ型およびオブジェクトの詳細
　　┗ 1.2 Oracle DMLのオブジェクトと操作のサポートの詳細
　　┗ 1.3 Oracle DDLのオブジェクトと操作のサポートの詳細

　　上記ドキュメントに記載のある、GGによる差分同期が不可能なオブジェクトやDDL・DMLが
　　移行元DBに存在・発行されるかどうか、データディクショナリ情報の取得及び業務アプリ
　　担当者とのヒアリングにより確認しました。

　　確認の結果、キャッシュを利用したSequenceオブジェクトが存在しました。
　　これは、「1.2.3 順序およびIDENTITY列」の「Oracle GoldenGateによって、ターゲットの
　　順序値が常にソースの順序値よりも大きくなります(または、キャッシュがゼロの場合、
　　それらに等しくなります)。」の部分に関係します。Sequenceオブジェクトがキャッシュを
　　利用している場合、GGではSequence値の一致は保証されません。

　　キャッシュを利用している場合、Sequence値はDBサーバのSGAメモリ上に存在しています。
　　GGではメモリ上の情報は伝播できません。GGで伝播させる設定にした場合、キャッシュを取得
　　する時にSequence値が伝播されます。従って、Sequence値を一致させたい、又は移行元DB側
　　に設定を加えたくない場合は、GGで伝播させない方が良いです。

　　上記により、SequenceオブジェクトはGGでの差分同期対象外としました。

　　参考迄に、SequenceをGGで伝播する場合の設定を下記します。

　　Oracle DatabaseのためのOracle GoldenGateの使用 – Oracle順序のサポートのインストール

　２）キャプチャ及び適用モードの選択

　　Oracle DatabaseのためのOracle GoldenGateの使用 – 4 キャプチャおよび適用モードの選択

　　┗ 4.2 使用するキャプチャ方法の決定
　　┗ 4.3 使用する適用方法の決定

　　上記ドキュメントを参考に、キャプチャ及び適用モードを決定しました。

　　■キャプチャモード（Extract）

　　　「統合キャプチャ」には以下の利点があるため、このモードを選択しました。
　　　　・マルチテナント・コンテナ・データベースらのキャプチャをサポートする唯一のモード
　　　　・統合ログ管理機能により、RMANでExtractに必要なアーカイブ・ログを自動保持
　　　　・表のCSNフィルタリングが高速

　　　「4.2.1.1 統合キャプチャ・デプロイ・オプション」についてですが、ダウンストリーム・
　　　デプロイ方式で必須のREDO自動転送機能は「Enterprise Edition」でのみ使用可能です。
　　　従って、「Standard Edition」ではダウンストリーム・デプロイ方式は使用不可のため、
　　　「ローカル・デプロイ方式」を選択しました。

　　■適用モード（Replicat）

　　　非統合Replicatの場合、移行先DBにトリガーや制約が反映されたタイミングで無効化する
　　　必要があります。無効化する必要のない「統合Replicat」を選択しました。

　３）その他

　　本GG製品には、移行元DBが「Standard Edition」の場合にGGプロセスが起動しない
　　不具合があり、移行元DBに個別パッチ「29374604」を手動で適用しました。

　　　Bug 29374604 – IE not starting against 18c Oracle RDBMS Standard Edition.

４．Oracle Cloud Marketplace上でのGoldenGateの使用

　Oracle GoldenGate Marketplaceユーザーガイドの指示に従って、GGのデプロイ及び構成を
　行いました。本ガイドの入手手順を下記します。

　１．Oracle Cloud にログインし、「マーケットプレイス」→「アプリケーション」を選択します。

２．検索ボックスを使用して「Oracle GoldenGate for Oracle」を探し、選択します。

３．「使用手順」タブを選択して表示される「Oracle GoldenGate Marketplace User Guide」の
　　リンク先がガイドになります。

GGのデプロイ及び構成手順は、全てガイドに記載がありますので、ご参考ください。

尚、日本語版も存在しますので、リンクを下記します。

Oracle Cloud Marketplace上でのOracle GoldenGateの使用

５．移行計画

　以下の移行工程、移行期間で実施しました。

　１）初期移行
　　DataPumpを使用して、スキーマのSequenceオブジェクト以外を移行。
　　各DBインスタンスで、1日1000スキーマ（100スキーマ単位）を移行。
　　切替日の６週間前～切替日の２週間前に実施。

　２）差分同期
　　GGを使用した差分同期。
　　日次で差分同期状況確認。
　　切替日の２週間前～切替当日まで実施。

　３）最終移行
　　移行元DBの更新を停止し、DataPumpを使用して、スキーマのSequenceオブジェクトを移行。
　　GGでの同期の差分がなくなったことを確認後に実施。（切替当日）

６．移行作業

　移行イメージと移行概要を下記します。

　■移行イメージ

　■移行概要

　　①GGプロセス（Extract、Replicat）作成

　　　GGプロセスは、DBインスタンス毎に作成します。
　　　前述の通り、Extractは「統合キャプチャ」、Replicatは「統合Replicat」で作成します。
　　　※Microservicesを使用しているため、Webページから作成可能です。
　　　※Extractプロセス作成時、一時的にソースDBサーバにバックグラウンドプロセスが増加
　　　　します。（本移行では600程度増加）

　　　設定したExtract、Replicatのパラメータ（例）と説明を下記します。

　　②サプリメンタルロギング有効化
　　　スキーマ単位で表レベルのサプリメンタル・ロギングを一括して有効化します。
　　　※Webページから１スキーマずつ設定可能ですが、スキーマ数が多いためスクリプトを作成
　　　　して設定します。

　　③Extract起動
　　　起動により、データベース・ログマイニング・サーバーと直接対話し、論理変更レコード
　　　(LCR)形式でデータの変更を受け取り、ローカルTrailファイル⇒リモートTrailファイル
　　　に書き出されます。
　　　※Extract作成後に開始したトランザクションが抽出されます。
　　　※Microservicesを使用しているため、Webページから起動可能です。

　　④Expdp（Sequence以外）
　　　各DBインスタンス、1日1,000スキーマずつエクスポートします。Sequenceは除外します。
　　　UNDO表領域の制限で、100スキーマ単位で1日10回実行します。（CRONで2時間間隔）
　　　※②の設定により、テーブル毎のSCN断面が記録されながらエクスポートされます。
　　　エクスポートしたDMPは、OCI-DBCS側にSCP転送します。
　　　転送速度は、30MB/s程度を実測しました。

　　⑤Impdp（Sequence以外）
　　　各DBインスタンス、1日1,000スキーマずつインポートします。
　　　※④のDMPに設定されたテーブル毎のSCNが、CSN（コミット順序番号）としてシステム表や
　　　　ビューに展開されます。移行元がOracleDBの場合、SCNとCSNは同値になります。
　　　※統合Replicatでは、移行されたDBトリガーが動作しない仕組みになっており、インポート後
　　　　にDBトリガーを無効化する必要はありません。

　　⑥Replicat起動
　　　起動により、リモートTrailファイルから変更を抽出し、DBに適用します。
　　　※①で設定した「dboptions enable_instantiation_filtering」により、⑤で展開されたCSN値
　　　　より大きいトランザクションだけが適用されます。
　　　※Microservicesを使用しているため、Webページから起動可能です。

　　⑦Expdp（Sequenceのみ）
　　　各DBインスタンス、全スキーマのSequenceをエクスポートします。

　　⑧Impdp（Sequenceのみ）
　　　各DBインスタンス、全スキーマのSequenceを削除した後、インポートします。

７．DBデータ整合性確認

　差分同期、最終移行後に以下の整合性確認スクリプトをGGサーバに配置して実行しました。
　差分同期期間中は、DB更新の少ない時間帯にCRON実行しました。

　１）スキーマの差分有無（対象：全スキーマ）
　　移行元・先のスキーマ名の突合。
　　最終移行後のみ、スキーマ毎の各オブジェクト数・ステータスの突合せを実施。
　　対象スキーマ数は約43000、処理時間は約1分。

　２）テーブル件数（対象：全スキーマ）
　　移行元・先のスキーマテーブル件数の突合。
　　処理時間短縮のため、スキーマ接頭辞毎に処理を19分割して実行。
　　対象スキーマ数は約43000、処理時間は約90分。

　３）テーブル行データ全体（対象：数スキーマ）
　　LOBデータ型以外の列は、移行元・先のテーブル列を select minus で突合。
　　（移行元データは、移行先からDBリンク経由で取得）
　　対象スキーマ数は45、処理時間は約60分。

　　LOBデータ型の列は、PL/SQL処理でファイル出力して突合。
　　対象スキーマ数は45、処理時間は約3分。

　尚、差分発生時の原因調査を目的に、GG情報取得スクリプトを上記スクリプト実行前にCRON実行
　しました。GG情報スクリプトで実行したGGコマンドは下記になります。

　　info extract [Extractプロセス名] detail
　　info extract [Extractプロセス名] showch
　　lag extract [Extractプロセス名]
　　stats extract [Extractプロセス名]
　　view discard [Extractプロセス名]

　　info replicat [Replicatプロセス名] detail
　　info replicat [Replicatプロセス名] showch
　　lag replicat [Replicatプロセス名]
　　stats replicat [Replicatプロセス名]
　　view discard [Replicatプロセス名]

　又、処理遅延の原因調査目的で、以下を追加で実行しました。

　　send extract [Extractプロセス名] showtrans
　　send extract [Extractプロセス名] logstats
　　send extract [Extractプロセス名] cachemgr cachestats
　　send extract [Extractプロセス名] cachemgr cachequeues
　　send extract [Extractプロセス名] getlag
　　send extract [Extractプロセス名] gettcpstats
　　send extract [Extractプロセス名] report
　　view report [Extractプロセス名]

　　send replicat [Replicatプロセス名] getlag
　　send replicat [Replicatプロセス名] report
　　view report [Replicatプロセス名]

８．移行結果

　移行経過中に発生した問題、解決のために取った対処法を下記します。

　１）差分同期が遅延

　　問題：スキーマ数の多いDBインスタンスの差分同期の追いつきが切替日に間に合わない。
　　対処：更新量の多い3000スキーマのみ処理させる別GGプロセスを作成して初期移行⇒差分同期
　　　　　を実施。既存プロセスからは、当該スキーマを除外。

　２）ReplicatプロセスがABEND

　　問題：Replicatプロセスの起動停止を繰り返すと以下のエラーが発生してReplicatプロセスが
　　　　　ABENDする。
　　　　　・Update対象のレコードが移行先DBに存在しない
　　　　　・Insert時にプライマリキーが重複
　　　　　・Update対象のオブジェクトが移行先DBに存在しない

　　対処：ABEND対象スキーマのみ処理させる別GGプロセスを作成して初期移行⇒差分同期
　　　　　を実施。既存プロセスからは、当該スキーマを除外。

　上記対処により、切替日に間に合わせることが出来ました。

　移行結果の正常性確認（DBデータ整合性確認）結果を下記します。

　１）スキーマの差分有無（対象：42950スキーマ）　⇒差分あり

　　差分：スキーマ毎の各オブジェクト数・ステータスの突合せで、
　　　　　1DBインスタンスの2スキーマでDBトリガーが2つ移行先に存在しない。

　　対処：当該スキーマをDataPumpでスキーマ指定のExpdp⇒Impdpを実施。

　２）テーブル件数（対象：42950スキーマ）　⇒差分なし

　３）テーブル行データ全体（対象：135スキーマ）　⇒差分なし

　上記対処により、移行結果の正常性確認を完了としました。

９．考察

　今回の移行で直面した以下３つの問題について、少し考察します。

　１）差分同期のDB適用パフォーマンスが向上できない

　　GGプロセスを並列実行できれば、パフォーマンスは容易に向上できますが、
　　移行対象のOracle Databaseが「Standard Edition」のため、並列実行はできません。

　　GoldenGate Integrated Capture and Integrated Replicat Healthcheck Script
　　( Doc ID 1448324.1 )

　　上記MOSドキュメント記載のヘルスチェックレポートを出力し、レポート結果を基に
　　GGパラメータレベルのチューニングをしましたが、効果は出ませんでした。

　　レポートファイル（*.rpt）から、スキーマのマッチング処理（MAP *.*, TARGET *.*;）
　　がボトルネックだと判り、3000スキーマを別GGプロセスで処理させ、元のGGプロセスから
　　スキーマを変更の適用から除外させた結果、パフォーマンスは向上しました。
　　差分適用が進むに連れ、効率的な索引スキャンが行われるようになったことも関係したと考え
　　られます。（ヘルスチェックレポートで索引アクセスに関係する待機イベントの減少を確認）

　２）Replicatプロセスの起動停止を繰り返すとReplicatプロセスがABENDする

　　OGG Replicat Abends With Database Errors Such as Oracle DB Errors
　　ORA-01403, ORA-00001, etc. (ドキュメントID 1371410.1)

　　上記MOSドキュメント記載の内容を確認しましたが、全て該当しませんでした。
　　処理済みCSNをキーに、TrailファイルをOracle GoldenGate Logdumpで分析しての
　　トランザクション特定が良策でしたが、ABEND発生時、Logdumpが利用不可な状況でした。
　　（ターミナルからGGサーバにアクセスできず）
　　Webページはアクセス可能だったので、GGプロセスから対象スキーマを除外して
　　プロセス起動し、DB適用を進めることを選択しました。
　　原因は不明ですが、GG不具合の可能性も疑えます。

　３）一部のDDLレプリケーションが反映されなかった（？）

　　差分同期中のDBトリガー作成（create trigger）のDDLレプリケーションが失敗した（？）
　　と考え、現存する破棄ファイル（*.dsc）、レポートファイル（*.rpt）を確認しましたが、
　　手掛かりとなり得る情報は出力されていませんでした。

　　①移行元DB又は移行先DBのアーカイブREDOログをOracle LogMinerで分析
　　②TrailファイルをOracle GoldenGate Logdumpで分析

　　上記①②実施により、当該DDLが存在するかどうか確認可能でしたが、
　　①は、差分判明した最終移行後には、アーカイブREDOログが日次バックアップで削除済み、
　　実施できませんでした。
　　②は、GGプロセスの「PURGEOLDEXTRACTS」指定により、Trailファイルはパージ済み、
　　こちらも実施できませんでした。

　　結局、原因は不明ですが、TrailファイルのサイズがREDO生成量の20%以下（今回の実測値）
　　と想定値33%より大分小さくなったこともあり、パージしない設定にすれば良かったと
　　後悔しています。又、各オブジェクト数の突合せも差分同期中に実施するべきでした。