Oracle GoldenGate: 初期ロードを使用したOracle Databaseインスタンス化へのMySQL (2025/09/09)
Oracle GoldenGate: 初期ロードを使用したOracle Databaseインスタンス化へのMySQL (2025/09/09)
投稿者：Loren Penton | Principal Solutions Architect, Oracle GoldenGate A-Team
多くの組織では、Oracle Databaseが注文管理、請求、顧客プロファイルといった重要なシステムを支え、MySQLはeコマース、コンテンツ管理、Webベース、あるいは医療アプリケーションを支えています。この2つのデータベースを連携させるには、静的データとリアルタイムで変化するデータを移行する必要があり、これはOracle GoldenGateの最適なユースケースとなります。
ここで Oracle GoldenGate が役立ちます。
MySQL と Oracle 間のレプリケーションの設定は、インスタンス化から始まり、MySQL データの一貫したスナップショットをキャプチャして、Oracle Databaseに静的データをすばやく入力するとともに、リアルタイム同期の準備をします。
ヘルスケア情報をデータ ウェアハウスに複製する場合でも、地域間で電子商取引データを同期する場合でも、レガシー アプリを移行する場合でも、インスタンス化は最初の重要なステップです。
この記事では、複数の Oracle GoldenGate 初期ロード プロセスを使用して、MySQL データベースから Oracle Databaseをインスタンス化し、アプリケーションを停止せずに異機種間 (MySQL から Oracle Database) レプリケーション実装を作成する方法を説明します。
前提条件
インスタンス化プロセスを開始する前に、ソースおよびターゲットのOracle GoldenGate Hubマシン、およびソースおよびターゲットのデータベース環境をレプリケーションを有効にするように構成する必要があります。これらの手順をすべて完全に完了することが重要です。完了しないと、セットアップの失敗、データの不整合、またはサポートされていない構成エラーが発生します。
- Oracle GoldenGate用のMySQLソースデータベースを準備します。MySQLの詳細については、 Oracle GoldenGateのドキュメントを参照してください。
- Oracle GoldenGate 用にターゲット Oracle Databaseを準備します。Oracle固有の情報については、 Oracle GoldenGate のドキュメントを参照してください。
インスタンス化前の手順
Oracle GoldenGate をレプリケーション用に設定する場合、テーブル メタデータを理解するために時間をかけることは、単に良い習慣であるだけでなく、パフォーマンスと信頼性にとって不可欠です。
Oracle GoldenGateの初期ロード抽出プロセスはシングルスレッドで、各テーブルから（アルファベット順に）フェッチを実行します。このアプローチはシンプルですが、大規模なテーブルやテーブル数が多い環境では非効率になる可能性があります。すべての行が選択され、ターゲットにストリーミングされるため、適切な準備がなければすぐに時間がかかるようになります。
これを最適化するには、次のことが重要です。
- 複製される各ソース テーブルの行数とサイズを取得します。
- 移動する必要があるデータの量を把握しておくと、インスタンス化に必要な時間とリソースを見積もるのに役立ちます。
- ソース テーブルでラージ オブジェクト データ型を確認します。
- データベースから大きなオブジェクトを取得すると、多くのリソースが消費され、初期ロード抽出のパフォーマンスに影響します。
- ターゲット テーブルのキー制約を確認します。
- 主キー、一意キー、および外部キーは、Oracle GoldenGate が変更を正確かつ効率的に複製する機能に影響します。
- キーのないテーブルでは、変更データのレプリケーションと初期ロードの完了に特別な処理が必要になります。
- データ適用エラーを防ぐために、インスタンス化では外部キーを無効にする必要があります。
このメタデータを事前に理解しておくことで、情報に基づいた意思決定を行い、潜在的なボトルネックを特定し、環境の規模と複雑さに合わせてインスタンス化戦略を調整することができます。
ソーステーブルの行数とサイズ
テーブル統計を更新した後、次の SQL クエリを使用してソース テーブルのサイズを取得しました。
LEFT(TABLE_NAME,10) AS `Table`,
LEFT(TABLE_ROWS,10) AS `Rows`,
LEFT(ROUND(((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024), 2),10) AS `Size (MB)`
FROM
information_schema.tables
WHERE
TABLE_SCHEMA = '[データベース名]'
ORDER BY
(DATA_LENGTH + INDEX_LENGTH) DESC;
上記の出力では、table_17 を除き、ソース テーブルのサイズは非常に小さいため、単一の Oracle GoldenGate 初期ロード抽出によって効率的に処理される必要があります。
Oracle GoldenGateの@RANGE関数を使用して、table_17のデータフェッチを複数の初期ロード抽出プロセスに分割することで、並列処理を実現できます。この関数の詳細については、Oracle GoldenGateのドキュメントを参照してください。このデモでは2つの初期ロード抽出プロセスを使用しますが、さらに並列化することで、ワークロードを3つ、4つ、あるいは任意の数の初期ロード抽出プロセスに分割することも可能です。
@RANGE を使用する場合、データのハッシュ化とフィルタリングはデータベースではなく、初期ロード抽出で行われます。テーブルのデータを取得するように構成された各初期ロード抽出は、取得する値の正しいデータ範囲を決定するために、テーブル全体の初期読み取りを実行する必要があります。テーブルのサイズによっては、この初期読み取りにかなりの時間がかかる場合があります。
ラージオブジェクトのクエリソース
以下は、ラージ オブジェクト データ型の MySQL テーブルを見つけるために使用したクエリです。
LEFT(tab.table_name,10) as `TABLE`,
LEFT(col.column_name,10) as `COLUMN`,
LEFT(col.data_type, 10) as `Data Type`
from information_schema.tables as tab
inner join information_schema.columns as col
on col.table_schema = tab.table_schema
and col.table_name = tab.table_name
where tab.table_schema = '[データベース名]'
and tab.table_type = 'BASE TABLE'
and col.data_type in ('blob', 'mediumblob', 'longblob',
'text','mediumtext','longtext')
order by tab.table_name,
col.column_name;
mylobテーブルは、MySQLからOracleへの実装には含まれません。ただし、ラージオブジェクトを含むテーブルは、初期ロード抽出のパフォーマンスに悪影響を及ぼします。
制約のないターゲットテーブルを識別する
次のクエリは、主キーまたは一意キー制約を持たない Oracle スキーマ内のすべてのテーブルを一覧表示します。
FROM (SELECT t.TABLE_NAME
FROM USER_TABLES t
WHERE t.TABLE_NAME NOT IN (SELECT DISTINCT u.TABLE_NAME
FROM USER_CONSTRAINTS u
WHERE u.CONSTRAINT_TYPE IN ('U', 'P')) AND
t.TABLE_NAME NOT IN (SELECT i.TABLE_NAME
FROM USER_INDEXES i
WHERE i.UNIQUENESS = 'UNIQUE'))
ORDER BY TABLE_NAME;
主キー制約または一意キー制約のないテーブルの場合は、追加の調査が必要となり、インスタンス化の際に特別な処理が必要になる場合があります。上記のデモテーブルを使用して、これらの追加手順を順に見ていきましょう。
1. ソーステーブルには主キーまたは一意キーがありますか？次のMySQLクエリは、テーブルのすべての制約を一覧表示します。
CONSTRAINT_NAME,
CONSTRAINT_TYPE
FROM
INFORMATION_SCHEMA.TABLE_CONSTRAINTS
WHERE
TABLE_SCHEMA = '[データベース名]' AND TABLE_NAME = '[テーブル名]';
ソース MySQL テーブルには主キーまたは一意キーがありません。
2. 一意の疑似キーを作成するために使用できる数値列またはタイムスタンプ列はありますか?
ソースMySQLテーブルに制約がない場合、疑似キーの作成に使用できる列がテーブルメタデータにあるか確認してください。数値型とタイムスタンプ型が最適です。以下のクエリは、これらのデータ型の列を返します。
COLUMN_NAME,
DATA_TYPE
FROM
INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = '[データベース名]'
AND TABLE_NAME = '[テーブル名]'
AND DATA_TYPE in ('int', 'decimal', 'datetime');
3. 疑似キー列の候補に重複データが含まれていますか？
返された列ごとに、次のクエリを実行して重複データが含まれているかどうかを確認します。
[列名],
COUNT([列名]) AS duplicate_count
FROM
[テーブル名]
GROUP BY [列名]
HAVING COUNT([列名]) > 1;
4. 選択した疑似キー列に NULL データが含まれていますか?
重複データが含まれていない列については、NULL が含まれているかどうかを確認します。
count(*)
from
[テーブル名]
where
[列名] IS NULL;
この調査では、デモ テーブル table_25 について、INT データ型の列「id」が擬似キーとして使用するための基準 (一意性と NULL データなし) を満たしていることが確認されました。
疑似キーの作成に使用できる列を識別できない場合は、Oracle GoldenGate 初期ロードを使用してテーブルをインスタンス化できません。
ターゲットテーブルの制約を特定する
次のクエリは、Oracle スキーマ内の各テーブルの制約の種類とそのステータスを識別します。
acc.table_name、
acc.column_name、
ac.constraint_type、
ac.validated、
ac.status
FROM
all_cons_columns acc
JOIN
all_constraints ac ON acc.owner = ac.owner
AND acc.constraint_name = ac.constraint_name
AND acc.table_name = ac.table_name
WHERE
ac.constraint_type in ('P','U','R')
and acc.owner = '[schema]'
order by table_name;
Oracle GoldenGate for Oracle Database では、制約列の一意性が保証されないため、有効化されていない、または NOVALIDATE として作成された主キー制約または一意キー制約は使用されないことに注意してください。
データ整合性の障害を防ぐため、初期ロード適用プロセスを開始する前に、参照整合性（外部キー）制約をすべて無効化する必要があります。これらの制約は、初期ロードが完了した後に有効化できます。
ソースGoldenGateプロセス
前提条件と調査が完了したら、変更データ キャプチャ (CDC) と初期ロード抽出のための Oracle GoldenGate for MySQL ソース デプロイメントのセットアップに進むことができます。
重要: 抽出のみを作成するため、「作成して実行」は選択しないでください。
チェンジデータキャプチャ抽出
Oracle GoldenGate for MySQL Hub サーバーの管理サービスにログインし、Change Data Capture Extract を作成します。
使用したパラメータ設定は次のとおりです。
EXTRACT edemo
USERIDALIAS [extract database alias] DOMAIN OracleGoldenGate
TRANLOGOPTIONS ALTLOGDEST REMOTE
EXTTRAIL dm
-- Every 60 minutes, report the count of records
-- processed since Extract start to the process
-- report file.
-- Rate reports the number of operations per second
-- The report file also contains DELTA throughput which is
-- the number of records since the last report divided by
-- the time since the last report
REPORTCOUNT EVERY 60 MINUTES, RATE
-- These two parameters are required because table_25
-- does not have “not null” constraints enabled.
-- Capture all table columns for update operations
NOCOMPRESSUPDATES
-- Capture all table columns for delete operations
NOCOMPRESSDELETES
-- "table_25" does not have a PK or UK, use the "id"
-- column as the pseudo-key
TABLE demodb.table_25, KEYCOLS (id);
TABLE demodb.*;
初期ロード抽出
Oracle GoldenGate for MySQL Hub サーバーの管理サービスにログインし、初期ロード抽出を 3 つ作成します。2 つは大きなテーブル table_17 に関連するワークロードを分割するためのもので、もう 1 つは他のすべてのテーブル用です。
以下は、table_17 を除くすべてのテーブルのパラメータ ファイルです。
USERIDALIAS [extract database alias] DOMAIN OracleGoldenGate
EXTFILE L1, MEGABYTES 2000, PURGE
-- Every 5 minutes, report the count of records
-- processed since Extract start to the process
-- report file.
-- Rate reports the number of operations per second
-- The report file also contains DELTA throughput which is
-- the number of records since the last report divided by
-- the time since the last report
REPORTCOUNT EVERY 5 MINUTES, RATE
-- Exclude table_17
TABLEEXCLUDE demodb.table_17
TABLE demodb.*;
以下はtable_17のパラメータ ファイルです。
EXTRACT L2DEMO
USERIDALIAS [extract database alias] DOMAIN OracleGoldenGate
EXTFILE L2, MEGABYTES 2000, PURGE
-- Every 5 minutes, report the count of records
-- processed since Extract start to the process
-- report file.
-- Rate reports the number of operations per second
-- The report file also contains DELTA throughput which is
-- the number of records since the last report divided by
-- the time since the last report
REPORTCOUNT EVERY 5 MINUTES, RATE
-- Split table_17 over 2 Extracts using the
-- column "id" to create the hash split
TABLE demodb.table_17, FILTER (@RANGE (1,2,id));
EXTRACT L3DEMO
USERIDALIAS [extract database alias] DOMAIN OracleGoldenGate
EXTFILE L3, MEGABYTES 2000, PURGE
-- Every 5 minutes, report the count of records
-- processed since Extract start to the process
-- report file.
-- Rate reports the number of operations per second
-- The report file also contains DELTA throughput which is
-- the number of records since the last report divided by
-- the time since the last report
REPORTCOUNT EVERY 5 MINUTES, RATE
-- Split table_17 over 2 Extracts using the
-- column "id" to create the hash split
TABLE demodb.table_17, FILTER (@RANGE (2,2,id));
ディストリビューションパス
Oracle GoldenGateドキュメントの指定に従って、ソースOracle GoldenGate HubサーバーからターゲットOracle GoldenGate Hubサーバーへの分散パスを作成します。分散パスは4つ必要になります。1つはチェンジデータキャプチャ抽出用、もう1つは初期ロード抽出用です。
GoldenGateプロセスをターゲットとする
Replicat の作成方法がわからない場合は、Oracle GoldenGate のドキュメントを参照してください。
重要: Replicat のみを作成するので、「作成して実行」は選択しないでください。
初期ロードレプリケートを作成する
先に進む前に、Oracle GoldenGate が初期ロード証跡データをどのように処理し、それが下流の処理にどのように影響するかを理解することが重要です。
初期ロード抽出はソース表から直接データを読み取ります。つまり、トランザクションメタデータ（BEGIN/COMMITレコードなど）は初期ロード証跡ファイルに書き込まれません。Oracle GoldenGateは専用の初期ロードレプリカを使用しません。代わりに、変更データレプリカが初期ロード中に取得されたデータを適用します。変更データレプリカは、証跡ファイル内のトランザクション境界に基づいて操作をトランザクションにグループ化するため、Oracle GoldenGateは初期ロードデータに対して合成（偽の）トランザクションIDを生成します。このIDは、証跡ファイルのシーケンス番号、相対バイトアドレス（RBA）、および証跡の最初のレコードのタイムスタンプから導出されます。
合成トランザクションは、次のいずれかの条件を満たすと完了したとみなされます。
- 処理中の各トレイルでファイルの終わり（EOF）に達した場合、または
- Replicatによって読み取られたレコード数が、MAXTRANSOPSパラメータで設定された値に達した（デフォルト：10,000,000レコード）
初期ロードデータ全体が単一の大規模トランザクションとして扱われる可能性があるため、特にParallel Replicatを使用する場合は、Replicat設定の調整が不可欠です。適切に調整されていない場合、次のような問題が発生します。
- Replicat がハングまたは停止しているように見える場合があります。
- 統計は報告されません。
- 合成トランザクションがコミットされるまで、チェックポイントは記録されません。
これらの問題を回避するには、Parallel Replicat で SPLIT_TRANS_RECS 設定を有効にする必要があります。
- SPLIT_TRANS_RECS は Parallel Replicat に固有のもので、大規模なトランザクションを小さな同時チャンクに分割して、チェックポイントとパフォーマンスを向上させるために使用されます。
初期ロードデータを適用するためのParallel Replicatを作成します。ソースの初期ロードExtractごとに1つのParallel Replicatが必要です。このデモでは、P1LD、P2LD、P3LDの3つのReplicatを作成します。これらはすべて同じパラメータ設定です。
REPLICAT P1LD
USERIDALIAS [replicat database alias] DOMAIN OracleGoldenGate
-- Set minimum number of Appliers to 1 and
-- spawn up to 6 to improve initial load
-- performance.
-- When everything has been applied, only 1
-- Applier will be running, signalling
-- initial load is complete.
MIN_APPLY_PARALLELISM 1
MAX_APPLY_PARALLELISM 6
-- Every 60 seconds, report the count of
-- records processed since Replicat starts
-- to the process report file.
-- Rate reports the number of operations per
-- second.
-- The report file also contains DELTA
-- throughput which is the number of records
-- since the last report divided by the time
-- since the last report.
REPORTCOUNT EVERY 60 SECONDS, RATE
-- Large transactions should be broken into
-- pieces of specified size and applied
-- concurrently.
SPLIT_TRANS_RECS 10000
MAP demodb.*, TARGET pdb_east.demo.*;
変更データの作成、Replicatの適用
キューに入れられた変更データとリアルタイムの変更データの両方を適用するには、Parallel Replicat を作成します。
Oracle GoldenGateの初期ロードを使用しているため、特別なパラメータ設定であるHANDLECOLLISIONSを指定する必要があります。HANDLECOLLISIONSはOracle GoldenGateの初期ロードにのみ使用され、本番環境へのデータ適用を継続するには無効にする必要があります。詳細については、Oracle GoldenGateのドキュメントを参照してください。
ターゲット テーブル table_25 には主キーまたは一意キーがないため、ソースの変更データ キャプチャ抽出の設定と一致するように疑似キーを設定する必要があります。
REPLICAT PDEMO
USERIDALIAS [replicat database alias] DOMAIN OracleGoldenGate
-- Every 60 minutes, report the count of
-- records processed since Replicat starts
-- to the process report file.
-- Rate reports the number of operations per second.
-- The report file also contains DELTA
-- throughput which is the number of records
-- since the last report divided by the time
-- since the last report.
REPORTCOUNT EVERY 60 MINUTES, RATE
-- Enabled for initial load to handle duplicate and
-- missing data fir a brief period. Must be disabled
-- after initial load completes.
HANDLECOLLISIONS
-- table_25 does not have a PK or UK, KEYCOLS specifies
-- a pseudo-key for update and delete operation efficiency.
MAP demodb.table_25, TARGET pdb_east.tpcc.table_25, KEYCOLS (id);
MAP demodb.*, TARGET pdb_east.demodb.*;
初期ロードを実行する
すべての設定が完了したら、初期ロードを実行する準備が整います。
インスタンス化後のアクティビティ
インスタンス化後に実行する必要があるアクティビティがいくつかあります。
まとめ
この記事では、複数のOracle GoldenGate初期ロードプロセスを使用して、ソースMySQLデータベースからOracleターゲットデータベースへのOracle GoldenGate初期ロードを実行する詳細な手順を説明し、アプリケーションを停止することなくリアルタイムレプリケーションを実現しました。Oracle GoldenGateの機能の詳細については、以下を参照してください。
コメント
コメントを投稿