0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Oracle Golden Gate システム無停止での初期同期方法

Last updated at Posted at 2024-07-07

Oracle超初心者が仕事でOracle環境の構築を頑張っている様子をおおくりします。

前提構成

  • Oracle Database 19c(ソースDB/ターゲットDBの両方)
  • Oracle Golden Gate 19c
  • ソースとターゲットの両方にGolden Gateをインストール済。
  • 初期同期の方法として、Oracle Data Pumpユーティリティ(EXPDP/IMPDPコマンド)を使用する。

初期同期のときシステム停めなくても大丈夫なの…?

Oracle Golden Gateで同期をスタートするには、まず初期同期を行ってソースとターゲットの状態を同じ状態に揃えなくてはならないことまでは理解しました。

初めてGGの同期に成功して以来、数日間上手く稼働していたのに急にプロセスが停止し、初期同期をやり直すことが何度かありました。この時は本格稼働前でアプリケーションからのDBアクセスも無いので特に何事もなく復旧できましたが、本格稼働後に同じことが起こったらどうしよう?と不安がよぎりました。

GGが止まるたびに昼夜問わず日々動き続けるソースDBへの更新を止めてもらうなんてことは非現実的。どうすればシステムを停止させずに初期同期ができるのでしょうか?

システム無停止で初期同期する方法(ざっくり仕組み)

調べると、GGでは割と簡単にシステム無停止で初期同期できる機能を備えていることが分かりました。

ソース側とターゲット側のそれぞれに以下のような仕組みがあるようです。

ソース側

ソース側では、初期同期のためにEXPDBコマンドを使ってダンプデータを作成しますが、それがいつ時点の断面なのかをGGが判断できる情報「インスタンス化CSN」をダンプデータ内に含めるように、GGSCIで予め設定することができます。
なのでExtract(CaptureプロセスとPumpプロセス)を稼働させたままの状態で、変更を記録・転送しながらダンプデータを作成してOKです。

ターゲット側

ターゲット側では、Replicatプロセスを停止した状態でダンプデータをインポートし、その後Replicatプロセスを再起動させますが、この間にソース側で起こった変更情報がTrailファイルにたんまりと溜まっています。このうちいつ以降の変更を反映すればよいのかを、Replicatが「インスタンス化CSN」を見て判断するように設定することができます。Replicatプロセスのパラメータファイルに予めとあるオプションを記述しておきます。

雑にまとめると…

ダンプデータ
「俺はいついつ時点のデータだぜ、よろしくな!」
Replicat
「了解だぜ、その時点より前に起こった変更情報は無視して、それより後に起こった変更情報だけを反映させていくぜ!」

こういうわけで、システムを止めずに上手く同期ができる仕組みなんですね。

システム無停止で初期同期する方法(詳細)

仕組みが分かったところで、具体的にどんな設定をすればよいのかを書きます。
ソース側とターゲット側のそれぞれに、予め以下の設定をしておきます。

ソース側

インスタンス化CSNをダンプデータに含めるように設定します。
具体的には、GGSCIでサプリメンタルログを設定するときに以下のオプションを指定します。
[PREPARECSN {WAIT | LOCK | NOWAIT | NONE}]

ただしこのオプションを省略すると、PREPARECSN NOWAITがデフォルトで設定されます。つまりNOWAITでよいなら特に何も指定する必要がありません。
なので、

(A) テーブルレベルでサプリメンタルログを設定する場合
ADD TRANDATA {表名}

(B) スキーマレベルでサプリメンタルログを設定する場合
ADD SCHEMATRANDATA {スキーマ名}

を実行するだけでよいです。

現在の設定を確認する方法

SQL*PlusでCDB$rootに管理者権限でログインし、以下SQLを実行します。
select TABLE_NAME,TIMESTAMP from ALL_CAPTURE_PREPARED_TABLES where table_owner = '{スキーマ名大文字}';

これでEXPDPコマンドで作成するダンプファイルにインスタンス化CSNが記録されるように設定できました。

ターゲット側

Replicatプロセスを停止し、Replicatパラメータファイルに以下の1行を追記します。
DBOPTIONS ENABLE_INSTANTIATION_FILTERING

これでReplicatがインスタンス化CSNを見て変更適用範囲を判断するように設定できました。

(余談)SCNとCSNの違い

記事によって「インスタンス化CSN」だったり「インスタンス化SCN」だったりするのですが、正しくは「インスタンス化CSN」のようです。
どちらもいつの変更かを判断するためのタイムスタンプ的な番号という点では同じですが、
SCNはOracle Databaseの用語、CSNはOracle Golden Gateの用語だそうです。
DBかGGかで使われる場面は異なりますが、根本的な用途も同じのようですね。

SCN(System Change Number)
使用者…Oracle Database
性質…タイムスタンプ
用途…コミット時点を識別する

システム変更番号(SCN)は、Oracle Databaseで使用される論理的な内部タイムスタンプです。SCNを使用して、トランザクションのACIDプロパティに準拠する必要があるデータベース内で発生するイベントに順序を付けます。Oracle DatabaseではSCNを使用して、すべての変更がディスク上に存在することが認識される前のSCNをマークし、リカバリで不要なREDOが適用されないようにします。さらに、データの集合に対するREDOが存在しない時点のマークにもSCNを使用し、リカバリを停止できるようにします。

CSN(Commit Sequence Number)
使用者…Oracle Golden Gate
性質…タイムスタンプ
用途…コミット時点の判断

Oracle GoldenGateの操作時には、コミット順序番号(CSN)を参照する必要がある場合があります。CSNは、トランザクション一貫性とデータ整合性を維持する目的でトランザクションを識別するためにOracle GoldenGateが作成する識別子です。これにより、トランザクションがデータベースにコミットされた時点を一意に識別します。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?