コーソル「DBAの窓口」presents - CO-Solcosol.jp/techdb/dbts2018tky_cosol_rep.pdf · Oracle...

Copyright © 2018 CO-Sol Inc. All Rights Reserved. | 1Copyright © 2018 CO-Sol Inc. All Rights Reserved. |

コーソル「DBAの窓口」presentsロジカルレプリケーションの動作の仕組みから見るOracleレプリケーション3製品のイチオシポイント

2018年09月19日株式会社コーソル渡部亮太

Copyright © 2018 CO-Sol Inc. All Rights Reserved. | 2

本セッションの概要

• コーソル「DBAの窓口」は、ベンダ中立の立場でお客様に最適なデータベース関連製品をご提案し、購入および購入後の設計／導入／運用をサポートするサービスです。

• 本セッションでは、製品選定で悩まれるお客様が多いロジカルレプリケーション製品について、動作の仕組みとその仕組みからくる制約を解説したうえで、Oracle Databaseのレプリケーションに対応した3製品（Attunity Replicate、GoldenGate、SharePlex）が制約を打破するために凝らしている工夫とイチオシポイントをご説明します。


講師および所属企業紹介

• 渡部亮太（わたべりょうた）

– Oracle ACE (Oracle Database分野、日本に4名)

– 著書「オラクルマスター教科書 Gold Oracle Database 12c」、「Oracleの基本」、「プロとしてのOracleアーキテクチャ入門」

– JPOUG 共同創設者、ボードメンバー

– ORACLE MASTER Platinum 12c/11g/10gMySQL OCP 5.6、OSS-DB Gold(INACTIVE)

• 株式会社コーソル

– 「CO-Solutions＝共に解決する」の理念のもと、Oracle技術に特化した事業を展開中。心あるサービスの提供とデータベースエンジニアの育成に注力している

– 社員数: 137名 (2018年9月時点)

– ORACLE MASTER Platinum取得者数3年連続日本一11g 取得者数 50名 / 12c 取得者数 37名


DBAの窓口 - 中立の立場で製品選定から運用まで

コーソル紹介

• Oracle Databaseに関する豊富なノウハウを生かし、ベンダ中立の立場でお客様に最適な製品をご提案します。

• 購入後の設計／導入／運用も一気通貫でサポートします。• http://cosol.jp/business/service/license.shtml


3拠点体制 - 24x365/DR/グローバル化のニーズに対応

コーソル紹介

福岡

東京カナダトロント


Agenda

1. ロジカルレプリケーションとは

2. ロジカルレプリケーションのしくみ

3. Oracleレプリケーション3製品のイチオシポイント

– GoldenGate

– SharePlex

– Attunity Replicate


注意事項

• 資料内に記載した以下の出力／実行結果は、読みやすさのため適宜省略／修正しています

– REDOダンプ

– ロジカルレプリケーションにおいて内部的に実行されるSQL文字列

• 製品毎に内部動作が異なるため、セッション内での説明が必ずしも特定の製品に当てはまらない場合があります。とはいえ、基本的な考え方はロジカルレプリケーション一般に適用できると考えています。


ロジカルレプリケーションとは


ロジカルレプリケーションとは何か

• データベース間のデータ複製技術の1つ

• ソースDBで実行された更新SQLと「意味的に等価な」更新SQLをターゲットDBで実行することで、データを複製（同期）する

– ただし、ターゲットDBで実行されるSQLは、ソースDBで実行されたSQLと完全に同じではない（後述）

UPDATE …WHERE id IN (1,2)

ソースDB

更新SQL実行

UPDATE … WHERE id = 1UPDATE … WHERE id = 2

ターゲットDB

更新SQL実行

意味的に等価

データを同期


ロジカルレプリケーションの利点／適用可能領域

SQL実行により更新を伝搬するため、構成上の制約が少ない（ソースとターゲットが、いわゆる「疎結合」）

– ソースとターゲットのテーブル構成やファイル構成が違ってもOK

– ソースとターゲットの製品バージョンが違ってもOK

• バージョンアップを伴うデータベース移行にとても有効

– ソースとターゲットが異なるDBMS製品でもOKな場合も

• Oracle Database → MySQL／PostgreSQLなど

伝搬の元ネタがSQLなので、いろいろと細工をしやすい

– 更新を伝搬する対象を限定する

• 特定の条件を満たす更新のみ伝搬するなど

– あるテーブルのみ、あるスキーマのみ、など

– ターゲットのDBMS製品に合わせたSQLに書き換え


フィジカルレプリケーション方式との比較

ロジカルレプリケーション

フィジカルレプリケーション

更新の伝搬方式論理的な更新情報（更新SQL）の転送と適用

物理的な変更情報（REDOログ）の転送と適用

伝搬対象一部の変更のみを伝搬することも可能

原則的に全ての変更

ソースDBとターゲットDBの結合性

疎結合（ソースDBとターゲットDBは異なる構成、異なるバージョンでOK。異なる製品でもよい場合あり）

密結合（ソースDBとターゲットDBは原則的に同一構成、同一製品、同一バージョン）

主な用途異なる構成のDB間でデータ連携する用途に向く• DBバージョンアップ時の

ダウンタイム最小化• 異なる製品、異なるバー

ジョン間のDBデータ連携• （HA構成、DR構成）

全く同一の構成のDBを複数つくる用途に向く• HA構成• DR構成


ロジカルレプリケーションのしくみ


ロジカルレプリケーションのしくみ

コミット済み更新を読出

SQLの作成

SQLの抽出

SQLの加工・変換

SQLの転送

SQLの実行

ソースDB

ターゲットDB

更新SQL実行

更新処理を記録

10100101

UPDATE ...

REDOログファイル

UPDATE ...

更新伝搬用SQL実行


処理ステップの説明ロジカルレプリケーションのしくみ

処理ステップ説明

コミット済み更新の抽出 • REDOログファイルにはコミット済みの更新（確定した更新）と、未コミットの更新（未確定の更新）の両方の更新情報が記録されている

• 伝搬すべき更新はコミット済みの更新だけなので、これを抽出して更新伝搬用SQLを作成する

更新伝搬用SQLの作成 • REDOログファイルに記録された更新情報から更新伝搬用のSQLを作成する

SQLの抽出（オプション）

• 更新を伝搬する対象が限定したい場合は、条件に合致するSQLのみを抽出し、それ以外のSQLは更新を伝搬しない

SQLの加工／変換（オプション）

• ターゲットDBの要件に合う形にSQLを加工／変換する• 異なる製品間のロジカルレプリケーションで重要

SQLの転送 • 更新伝搬用SQLをソースDBからターゲットDBに転送する

SQLの実行 • 転送された更新伝搬用SQLをターゲットDBで実行する


REDOログファイルから更新伝搬用SQLを作成ロジカルレプリケーションのしくみ

10100101 UPDATE ...


• REDOログファイルにはバイナリ形式のブロックレベルの更新情報が格納されている（フィジオロジカルロギング）

• ただし、通常、REDOログファイルには、更新伝搬用SQLを作成するために十分な情報が含まれていない

• 付加情報（サプリメンタルロギングやディクショナリ情報）を活用して、意味的に等価な更新伝搬用SQLを作成する

• 一般に、作成されたSQLはアプリケーションが実行したSQLと同じSQLではない

SQLの作成


更新処理とフィジオロジカルロギングロジカルレプリケーションのしくみ

ソースDB

UPDATE t SET c2 = 'XXX' WHERE id=1;


10100101

DBA 0x00800380

CHANGE #1 ... DBA:0x00800381 OBJ:93287 SCN:0x0000.001a8a60 SEQ:8 OP:11.19 ...KTB Redo

:Array Update of 1 rows:tabn: 0 slot: 1(0x1) flag: 0x2c lock: 2 ckix: 0ncol: 3 nnew: 1 size: 0

:col 2: [16] 58 58 58 20 20 20 20 20 20 20 20 20 20 20 20 20

0x00800381 0x00800382

･･････

0x00800383

"XXX"

実行したSQL

行UPD

REDO dump


フィジオロジカルロギングとはロジカルレプリケーションのしくみ

• フィジカルロギングとロジカルロギングのいいとこどり

ロギング方式記録される情報特徴

ロジカルロギング実行されたSQLを記録ログサイズ：小復旧用途の使用：△

フィジカルロギング

更新前後のブロックのバイナリデータそのもの、または更新前後のバイナリ差分を記録

ログサイズ：大復旧用途の使用：◎

フィジオロジカルロギング

更新されたブロックの位置（物理的）＋そのブロックで実行された更新オペレーションを記録（論理的）

ログサイズ：小～中復旧用途の使用：◎

• ロギング方式の分類方法にはいくつかの考え方があることに注意。なお、書籍「トランザクション処理概念と技法」では上記とは少し異なる考え方で分類していた。

• 復旧用途の使用：本セッションでは説明を割愛しているが、ロギングされた更新処理は障害発生時の復旧に使用される。当然ながら、低レベルな情報（物理的な情報）が多いほうが復旧処理に活用しやすい。

Oracle


元のSQLと更新伝搬用SQLが異なる理由ロジカルレプリケーションのしくみ

ソースDB

UPDATE t SET c2 = 'XXX' WHERE id IN (1,2);


10100101

CHANGE #22 ... DBA:0x00800201 OBJ:93285 SCN:0x0000.001a8934 SEQ:7 OP:11.19 ...:

Array Update of 1 rows:tabn: 0 slot: 1(0x1) flag: 0x2c lock: 1 ckix: 0:

col 2: [16] 58 58 58 20 20 20 20 20 20 20 20 20 20 20 20 20

UPDATE t SET c2 = 'XXX' WHERE id = 1;


CHANGE #23 ... DBA:0x00800202 OBJ:93285 SCN:0x0000.001a8934 SEQ:5 OP:11.19 ...:

Array Update of 1 rows:tabn: 0 slot: 2(0x2) flag: 0x2c lock: 1 ckix: 0:

col 2: [16] 58 58 58 20 20 20 20 20 20 20 20 20 20 20 20 20

DBA 0x00800200 0x00800201 0x00800202

･･････

0x00800203

実行したSQL

REDOから作成したSQL


REDOに記録されるもの／されないものロジカルレプリケーションのしくみ

記録される情報

• 更新されたデータの位置情報（ブロック位置＝DBA、行の位置＝スロット、何番目の列か）

• 更新対象ブロックに適用された更新オペレーションの内容（オペレーションの種類、更新後の値）

記録されない情報

• 実行されたSQL文そのもの• 名前に類する情報（テーブル名、列

名）• SQLレベルの行の識別子（主キー値、

一意キーの値）


update "UNKNOWN"."OBJ# 93296"set "COL 3" = HEXTORAW('58585820202020202020202020202020') where ROWID = 'AAAWxwAACAAAAIBAAB';

→ 通常REDOに記録される情報だけでは更新伝搬用SQLを作成できない（≒更新SQLと意味的に等価なSQLを作成できない）


ディクショナリを用いた名前の解決ロジカルレプリケーションのしくみ

update "UNKNOWN"."OBJ# 93296"set "COL 3" = HEXTORAW('58585820202020202020202020202020') where "COL 1" = HEXTORAW('c103');

update tset c2 = 'XXX'where id = 2;

ディクショナリ未使用時

ディクショナリ使用時

• REDOにテーブル名や列名が含まれていないため、このままでは正しいテーブル名や列名を復元できない

• ディクショナリ（データベースの内部管理情報）を参照し、正しい名前を得て、正しい名前を含むSQLを作成する

UPDATE t SET c2 = 'XXX' WHERE id = 2; 実行したSQL



サプリメンタルロギングを用いた論理識別子の指定ロジカルレプリケーションのしくみ

update t set c2 = 'XXX'where ROWID = 'AAAWxwAACAAAAIBAAB';

update t set c2 = 'XXX' where id = 2;

サプリメンタルロギング未使用時

サプリメンタルロギング使用時

• REDOには論理的な識別子（いわゆるキー、論理的な位置情報）は含まれておらず、物理的な位置情報しか含まれていないため、ソースとターゲットの物理的な構成が異なる場合、同じ更新処理を実現できない• ROWIDはDBA（ブロックの物理位置）とスロット（ブロック内の行の

位置情報）を含む物理的な位置情報• ソースDBでサプリメンタルロギングを有効にすると、論理的な識別子（いわ

ゆるキー）がREDOに含まれるため、検索条件にキーを含めたSQLを作成できるようになる

UPDATE t SET c2 = 'XXX' WHERE id = 2; 実行したSQL


物理的な位置情報

論理的な識別子（キー）


[参考] サプリメンタルロギングの設定ロジカルレプリケーションのしくみ

• 最小レベルのサプリメンタルロギング＋識別キーロギング（主キー、一意キーなど）

の両方を有効にするのが基本

– どの識別キーロギングを有効にするかは適宜判断が必要

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

最小レベルのサプリメンタルロギング（データベースレベル）

-- 主キー

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;-- 一意キー

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (UNIQUE) COLUMNS;-- 外部キー

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (FOREIGN KEY) COLUMNS;-- すべての列

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;

識別キーロギング（データベースレベル）


DDLレプリケーションの困難さロジカルレプリケーションのしくみ

CREATE TABLE ...

• 実行したDDLは基本的にREDOログに記録されない→ 代わりにディクショナリ情報(内部管理情報)の更新が記録される

• ディクショナリ情報の更新から実行されたDDLを復元するのは大変・・・レプリケーション製品はこの大変な処理を実装している！（トリガーなどを駆使して実行されたDDLを別途記録する製品もあり）

• [補足] DDLレプリケーションには製品ごとに細かい制約があるため、使用時は十分な検討が必要

insert into "SYS"."COL$"("OBJ#", ... ,"SPARE8") values ('93298','1','1','22','0','N','2','22','0',NULL,NULL,'0',NULL,NULL,'1','0','0','0','0',NULL,NULL,'0','0','0',NULL,NULL,NULL,NULL,NULL);

insert into "SYS"."TAB$"("OBJ#", ... ,"SPARE6") values ('93298','93298','4','0','0',NULL,NULL,'1',NULL,'10','40','1','255','1073741825','--------------------------------------',NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,'1','1','17716740096','0','736',NULL,NULL,NULL,NULL,TO_DATE('01-8月 -2018 20:16:42', 'DD-MON-YYYY HH24:MI:SS'));

実行したSQL



ロジカルレプリケーションの一般的な注意点ロジカルレプリケーションのしくみ

• ソースDBへの影響

– レプリケーション処理で使用するOSリソース、ディスク領域

– サプリメンタルロギング有効化に伴うREDO生成量の増加

• テーブル設計／オブジェクト設計との相性

– 主キーがない表

– MVIEW、シーケンスに関する制限への対応

• 伝搬できない処理を実行していないかのチェック

– 伝搬できない処理はレプリケーション製品および設定により異なる

• 若干複雑な構成への対応

– クラスタ構成（RAC）など

ロジカルレプリケーションは非常にパワフルなソリューションですが、注意点が多いのも事実・・・是非コーソルにご相談ください！！


Oracleレプリケーション3製品のイチオシポイント


GoldenGateのイチオシポイント

オラクル製品ならではのOracle Databaseとの親和性の高さ

• 統合キャプチャモードという裏技

• より多くのデータ型、DDLの伝搬に対応

• クラスタ構成（RAC）との親和性

• Oracle Database新機能への追従

GoldenGate


統合キャプチャモードGoldenGateのイチオシポイント

ソースDB

更新SQL実行


10100101

UPDATE ...


コミット済み更新を読出

SQLの作成

ソースDB

GoldenGate統合キャプチャモード


10100101

UPDATE ...


GoldenGate

LCR(更新処理の内部表現)

ログマイニング

サーバ

･･･

･･･

通常のロジカルレプリケーション

Oracle Database自体にGoldenGateを支援する機能を実装！

• 適用プロセスについてもOracle Databaseを機能拡張した統合Replicat機能が存在するがここでは説明を割愛

更新SQL実行


SharePlexのイチオシポイント

コミット前伝搬による伝搬遅延の抑止

SharePlex

ソース

SharePlex その他レプリケーション製品

ターゲットソースターゲット

UPDATE ...UPDATE ...

:

COMMIT;

長時間トランザクション実行時の伝搬遅延発生を抑止


• RPM一発でインストール可能

• 導入後、GUIで即座に同期可能

• 既存環境（ソースDB、ターゲットDB)へ製品導入不要

– いわゆるエージェントレス

Attunityのイチオシポイント

圧倒的な使いやすさ、導入しやすさ

Attunity


導入後、GUIで即座に同期可能Attunityのイチオシポイント

Endpoint を登録したデータベースをDrag & Drop

伝搬対象を指定

ターゲットDBへの初期データ移入も自動的に実行！

Attunity


DB環境へ製品導入不要Attunityのイチオシポイント

Attunity

ソースDB

REDO

Attunity Replicateのシステム構成

その他レプリケーション製品のシステム構成

エージェント

ソースDB

REDO エージェント

ターゲットDB

ターゲットDB

AttunityServer

Oracle Net Oracle Net

レプリケート

転送

適用

読出

※: GoldenGateも外部サーバー構成をサポート


DBAの窓口 - コーソルサービス紹介

• Oracle Databaseに関する豊富なノウハウを生かし、中立の立場でお客様に最適な製品をご提案します。

• 購入後の設計／導入／運用も一気通貫でサポートします。• http://cosol.jp/business/service/license.shtml

コーソル「DBAの窓口」presents - CO-Solcosol.jp/techdb/dbts2018tky_cosol_rep.pdf · Oracle...

Documents

Transcript of コーソル「DBAの窓口」presents - CO-Solcosol.jp/techdb/dbts2018tky_cosol_rep.pdf · Oracle...