目的

以下のような Oracle Golden Gate 環境をローカルに作っていきます。

STEP１．Oracle Database CUI インストール
 STEP２．Oracle Golden Gate インストール
 STEP３．Oracle Golden Gate セットアップ

STEP４．Oracle Golden Gate を使ってみる (この記事)

Oracle Golden Gate を使ってみる手順

１．サービスの起動など
２．Golden Gate プロセス起動
３．テスト用テーブルの作成
４．実行テスト

１．サービスの起動など（ソース側、ターゲット側両方で実行する）

Listener や Oracleインスタンスが仮想環境の起動時にスタートアップする設定になっていない場合、仮想環境を起動する度にスタートしてあげる必要があります。
この作業はソース、ターゲット両方の仮想環境で実行します。

仮想環境へログイン

# ソース側
vagrant ssh myora1
# ターゲット側
vagrant ssh myora2

ソース、ターゲット両方の仮想環境で実行

# ユーザ変更
$ sudo su - oracle

# Listener起動
$ lsnrctl start LISTENER

# Oracleインスタンス 起動
$ sql / as sysdba
SQL> startup

# PDB open
SQL> alter pluggable database all open;
SQL> exit

２．Golden Gate プロセス起動

ターゲット側(myora2)のプロセスを先に起動します。
そうしないと、ソース側のPumpプロセス起動時に接続失敗してしまいます。

ターゲット側(myora2)

# ggsci 起動
$ /gg/ggsci

# Manager 起動
GGSCI (myora2) x> start manager
Manager started.

# Replicat 起動
GGSCI (myora2) x> start repli2

Sending START request to MANAGER ...
REPLICAT REPLI2 starting

# 起動プロセス確認
GGSCI (myora2) x> info all
Program     Status      Group       Lag at Chkpt  Time Since Chkpt

MANAGER     RUNNING
REPLICAT    RUNNING     REPLI2      00:00:00      00:00:06

# 終了
GGSCI (myora1) x> exit

次にソース側(myora1)のプロセスを起動していきます。

ソース側(myora1)

# ggsci 起動
$ /gg/ggsci

# Manager 起動
GGSCI (myora1) x> start manager
Manager started.

# Capture 起動
GGSCI (myora1) x> start capture1

Sending START request to MANAGER ...
EXTRACT CAPTURE1 starting

# Pump 起動
GGSCI (myora1) x> start pump1

Sending START request to MANAGER ...
EXTRACT PUMP1 starting

# 起動プロセス確認
GGSCI (myora1) x> info all
Program     Status      Group       Lag at Chkpt  Time Since Chkpt

MANAGER     RUNNING
EXTRACT     RUNNING     CAPTURE1    00:00:00      00:00:02
EXTRACT     RUNNING     PUMP1       00:00:00      00:00:00

# 終了
GGSCI (myora1) x> exit

３．テスト用テーブルの作成

テスト用のテーブルをソース側(myora1)とターゲット側(myora2)に作成します。

ソース側(myora1)とターゲット側(myora2)両方

# Oracle PDB ログイン
$ sql c##gguser/oracle@//localhost:1521/ORCLPDB1

SQL> CREATE TABLE TABLE_X (COL_A NUMBER, COL_B VARCHAR(382), COL_C NUMBER, COL_D DATE);

Table created.

SQL> DESC TABLE_X;

Name                                      Null?    Type
----------------------------------------- -------- ----------------------------
COL_A                                              NUMBER
COL_B                                              VARCHAR2(382)
COL_C                                              NUMBER
COL_D                                              DATE

SQL> exit

４．実行テスト

ソース側のテーブルにレコードを挿入してみます。

ソース側(myora1)

# Oracle PDB ログイン
$ sql c##gguser/oracle@//localhost:1521/ORCLPDB1

SQL> INSERT INTO TABLE_X (COL_A, COL_B, COL_C, COL_D) VALUES (10000, '10000-abc-1', 1, sysdate);

SQL> commit;

SQL> SELECT * from TABLE_X;
  COL_A COL_B           COL_C COL_D
  10000 10000-abc-1         1 xx-SEP-21

ソース側にレコードが挿入されました。
それでは、ターゲット側を確認してみます。

ターゲット側(myora2)

# Oracle PDB ログイン
$ sql c##gguser/oracle@//localhost:1521/ORCLPDB1

SQL> SELECT * from TABLE_X;
  COL_A COL_B           COL_C COL_D
  10000 10000-abc-1         1 xx-SEP-21

同じレコードが伝搬されていることが確認できました。
1台のローカル環境上で起動している2台の仮想環境の間での同期処理になりますが、10秒程度で伝搬されました。

次にそのレコードを削除してみます。

ソース側(myora1)

SQL> DELETE FROM TABLE_X WHERE COL_A = 10000;

1 row deleted.

SQL> commit;

Commit complete.


SQL> SELECT * from TABLE_X;

no rows selected

ターゲット側を確認してみます。

ターゲット側(myora2)

SQL> select * from table_x;

no rows selected

削除されています。
レコードの挿入・削除処理について、ソース側⇒ターゲット側に伝搬されていることが確認できました。

以上、ここまででローカル環境に Oracle DB と Oracle Golden Gate をインストールし、実際にデータ更新が伝搬されることを確認してきました。
ローカル環境ではありますが、基本的な設定や動作について理解することが出来ました。
Oracle Golden Gate は（ライセンス料が高いですが・・・）バックアップ用のDBなど、リアルタイムにレプリケーションしたいというような要件に対しては、有力な候補になると思われます。