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)が制約を打破するために凝らしている工夫とイチオシポイントをご説明します。
Copyright © 2018 CO-Sol Inc. All Rights Reserved. | 3
講師および所属企業紹介
• 渡部 亮太(わたべ りょうた)
– 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名
Copyright © 2018 CO-Sol Inc. All Rights Reserved. | 4
DBAの窓口 - 中立の立場で製品選定から運用まで
コーソル紹介
• Oracle Databaseに関する豊富なノウハウを生かし、ベンダ中立の立場でお客様に最適な製品をご提案します。
• 購入後の設計/導入/運用も一気通貫でサポートします。• http://cosol.jp/business/service/license.shtml
Copyright © 2018 CO-Sol Inc. All Rights Reserved. | 5
3拠点体制 - 24x365/DR/グローバル化のニーズに対応
コーソル紹介
福岡
東京 カナダトロント
Copyright © 2018 CO-Sol Inc. All Rights Reserved. | 6
Agenda
1. ロジカルレプリケーションとは
2. ロジカルレプリケーションのしくみ
3. Oracleレプリケーション3製品のイチオシポイント
– GoldenGate
– SharePlex
– Attunity Replicate
Copyright © 2018 CO-Sol Inc. All Rights Reserved. | 7
注意事項
• 資料内に記載した以下の出力/実行結果は、読みやすさのため適宜 省略/修正しています
– REDOダンプ
– ロジカルレプリケーションにおいて内部的に実行されるSQL文字列
• 製品毎に内部動作が異なるため、セッション内での説明が必ずしも 特定の製品に当てはまらない場合があります。とはいえ、基本的な考え方はロジカルレプリケーション一般に適用できると考えています。
Copyright © 2018 CO-Sol Inc. All Rights Reserved. | 8Copyright © 2018 CO-Sol Inc. All Rights Reserved. |
ロジカルレプリケーションとは
Copyright © 2018 CO-Sol Inc. All Rights Reserved. | 9
ロジカルレプリケーションとは何か
• データベース間のデータ複製技術の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実行
意味的に等価
データを同期
Copyright © 2018 CO-Sol Inc. All Rights Reserved. | 10
ロジカルレプリケーションの利点/適用可能領域
SQL実行により更新を伝搬するため、構成上の制約が少ない(ソースとターゲットが、いわゆる「疎結合」)
– ソースとターゲットのテーブル構成やファイル構成が違ってもOK
– ソースとターゲットの製品バージョンが違ってもOK
• バージョンアップを伴うデータベース移行にとても有効
– ソースとターゲットが異なるDBMS製品でもOKな場合も
• Oracle Database → MySQL/PostgreSQLなど
伝搬の元ネタがSQLなので、いろいろと細工をしやすい
– 更新を伝搬する対象を限定する
• 特定の条件を満たす更新のみ伝搬するなど
– あるテーブルのみ、あるスキーマのみ、など
– ターゲットのDBMS製品に合わせたSQLに書き換え
Copyright © 2018 CO-Sol Inc. All Rights Reserved. | 11
フィジカルレプリケーション方式との比較
ロジカルレプリケーション
フィジカルレプリケーション
更新の伝搬方式 論理的な更新情報(更新SQL)の転送と適用
物理的な変更情報(REDOログ)の転送と適用
伝搬対象 一部の変更のみを伝搬することも可能
原則的に全ての変更
ソースDBとターゲットDBの結合性
疎結合(ソースDBとターゲットDBは異なる構成、異なるバージョンでOK。異なる製品でもよい場合あり)
密結合(ソースDBとターゲットDBは原則的に同一構成、同一製品、同一バージョン)
主な用途 異なる構成のDB間でデータ連携する用途に向く• DBバージョンアップ時の
ダウンタイム最小化• 異なる製品、異なるバー
ジョン間のDBデータ連携• (HA構成、DR構成)
全く同一の構成のDBを複数つくる用途に向く• HA構成• DR構成
Copyright © 2018 CO-Sol Inc. All Rights Reserved. | 12Copyright © 2018 CO-Sol Inc. All Rights Reserved. |
ロジカルレプリケーションのしくみ
Copyright © 2018 CO-Sol Inc. All Rights Reserved. | 13
ロジカルレプリケーションのしくみ
コミット済み更新を読出
SQLの作成
SQLの抽出
SQLの加工・変換
SQLの転送
SQLの実行
ソースDB
ターゲットDB
更新SQL実行
更新処理を記録
10100101
UPDATE ...
REDOログファイル
UPDATE ...
更新伝搬用SQL実行
Copyright © 2018 CO-Sol Inc. All Rights Reserved. | 14
処理ステップの説明ロジカルレプリケーションのしくみ
処理ステップ 説明
コミット済み更新の抽出 • REDOログファイルにはコミット済みの更新(確定した更新)と、未コミットの更新(未確定の更新)の両方の更新情報が記録されている
• 伝搬すべき更新はコミット済みの更新だけなので、これを抽出して更新伝搬用SQLを作成する
更新伝搬用SQLの作成 • REDOログファイルに記録された更新情報から更新伝搬用のSQLを作成する
SQLの抽出(オプション)
• 更新を伝搬する対象が限定したい場合は、条件に合致するSQLのみを抽出し、それ以外のSQLは更新を伝搬しない
SQLの加工/変換(オプション)
• ターゲットDBの要件に合う形にSQLを加工/変換する• 異なる製品間のロジカルレプリケーションで重要
SQLの転送 • 更新伝搬用SQLをソースDBからターゲットDBに転送する
SQLの実行 • 転送された更新伝搬用SQLをターゲットDBで実行する
Copyright © 2018 CO-Sol Inc. All Rights Reserved. | 15
REDOログファイルから更新伝搬用SQLを作成ロジカルレプリケーションのしくみ
10100101 UPDATE ...
REDOログファイル
• REDOログファイルにはバイナリ形式のブロックレベルの更新情報が格納されている(フィジオロジカルロギング)
• ただし、通常、REDOログファイルには、更新伝搬用SQLを作成するために十分な情報が含まれていない
• 付加情報(サプリメンタルロギングやディクショナリ情報)を活用して、意味的に等価な更新伝搬用SQLを作成する
• 一般に、作成されたSQLはアプリケーションが実行したSQLと同じSQLではない
SQLの作成
Copyright © 2018 CO-Sol Inc. All Rights Reserved. | 16
更新処理とフィジオロジカルロギングロジカルレプリケーションのしくみ
ソースDB
UPDATE t SET c2 = 'XXX' WHERE id=1;
REDOログファイル
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
Copyright © 2018 CO-Sol Inc. All Rights Reserved. | 17
フィジオロジカルロギングとはロジカルレプリケーションのしくみ
• フィジカルロギングとロジカルロギングのいいとこどり
ロギング方式 記録される情報 特徴
ロジカルロギング 実行されたSQLを記録 ログサイズ:小復旧用途の使用:△
フィジカルロギング
更新前後のブロックのバイナリデータそのもの、または更新前後のバイナリ差分を記録
ログサイズ:大復旧用途の使用:◎
フィジオロジカルロギング
更新されたブロックの位置(物理的)+そのブロックで実行された更新オペレーションを記録(論理的)
ログサイズ:小~中復旧用途の使用:◎
• ロギング方式の分類方法にはいくつかの考え方があることに注意。なお、書籍「トランザクション処理 概念と技法」では上記とは少し異なる考え方で分類していた。
• 復旧用途の使用:本セッションでは説明を割愛しているが、ロギングされた更新処理は障害発生時の復旧に使用される。当然ながら、低レベルな情報(物理的な情報)が多いほうが復旧処理に活用しやすい。
Oracle
Copyright © 2018 CO-Sol Inc. All Rights Reserved. | 18
元のSQLと更新伝搬用SQLが異なる理由ロジカルレプリケーションのしくみ
ソースDB
UPDATE t SET c2 = 'XXX' WHERE id IN (1,2);
REDOログファイル
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;
UPDATE t SET c2 = 'XXX' WHERE id = 2;
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
Copyright © 2018 CO-Sol Inc. All Rights Reserved. | 19
REDOに記録されるもの/されないものロジカルレプリケーションのしくみ
記録される情報
• 更新されたデータの位置情報(ブロック位置=DBA、行の位置=スロット、何番目の列か)
• 更新対象ブロックに適用された更新オペレーションの内容(オペレーションの種類、更新後の値)
記録されない情報
• 実行されたSQL文そのもの• 名前に類する情報(テーブル名、列
名)• SQLレベルの行の識別子(主キー値、
一意キーの値)
UPDATE t SET c2 = 'XXX' WHERE id = 2;
update "UNKNOWN"."OBJ# 93296"set "COL 3" = HEXTORAW('58585820202020202020202020202020') where ROWID = 'AAAWxwAACAAAAIBAAB';
→ 通常REDOに記録される情報だけでは更新伝搬用SQLを作成できない(≒更新SQLと意味的に等価なSQLを作成できない)
Copyright © 2018 CO-Sol Inc. All Rights Reserved. | 20
ディクショナリを用いた名前の解決ロジカルレプリケーションのしくみ
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
REDOから作成したSQL
Copyright © 2018 CO-Sol Inc. All Rights Reserved. | 21
サプリメンタルロギングを用いた論理識別子の指定ロジカルレプリケーションのしくみ
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
REDOから作成したSQL
物理的な位置情報
論理的な識別子(キー)
Copyright © 2018 CO-Sol Inc. All Rights Reserved. | 22
[参考] サプリメンタルロギングの設定ロジカルレプリケーションのしくみ
• 最小レベルのサプリメンタルロギング+ 識別キーロギング(主キー、一意キーなど)
の両方を有効にするのが基本
– どの識別キーロギングを有効にするかは適宜判断が必要
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;
識別キーロギング(データベースレベル)
Copyright © 2018 CO-Sol Inc. All Rights Reserved. | 23
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
REDOから作成したSQL
Copyright © 2018 CO-Sol Inc. All Rights Reserved. | 24
ロジカルレプリケーションの一般的な注意点ロジカルレプリケーションのしくみ
• ソースDBへの影響
– レプリケーション処理で使用するOSリソース、ディスク領域
– サプリメンタルロギング有効化に伴うREDO生成量の増加
• テーブル設計/オブジェクト設計との相性
– 主キーがない表
– MVIEW、シーケンスに関する制限への対応
• 伝搬できない処理を実行していないかのチェック
– 伝搬できない処理はレプリケーション製品および設定により異なる
• 若干複雑な構成への対応
– クラスタ構成(RAC)など
ロジカルレプリケーションは非常にパワフルなソリューションですが、注意点が多いのも事実・・・ 是非コーソルにご相談ください!!
Copyright © 2018 CO-Sol Inc. All Rights Reserved. | 25Copyright © 2018 CO-Sol Inc. All Rights Reserved. |
Oracleレプリケーション3製品のイチオシポイント
Copyright © 2018 CO-Sol Inc. All Rights Reserved. | 26
GoldenGateのイチオシポイント
オラクル製品ならではのOracle Databaseとの親和性の高さ
• 統合キャプチャモードという裏技
• より多くのデータ型、DDLの伝搬に対応
• クラスタ構成(RAC)との親和性
• Oracle Database新機能への追従
GoldenGate
Copyright © 2018 CO-Sol Inc. All Rights Reserved. | 27
統合キャプチャモードGoldenGateのイチオシポイント
ソースDB
更新SQL実行
更新処理を記録
10100101
UPDATE ...
REDOログファイル
コミット済み更新を読出
SQLの作成
ソースDB
GoldenGate統合キャプチャモード
更新処理を記録
10100101
UPDATE ...
REDOログファイル
GoldenGate
LCR(更新処理の内部表現)
ログマイニング
サーバ
・・・
・・・
通常のロジカルレプリケーション
Oracle Database自体にGoldenGateを支援する機能を実装!
• 適用プロセスについてもOracle Databaseを機能拡張した統合Replicat機能が存在するがここでは説明を割愛
更新SQL実行
Copyright © 2018 CO-Sol Inc. All Rights Reserved. | 28
SharePlexのイチオシポイント
コミット前伝搬による伝搬遅延の抑止
SharePlex
ソース
SharePlex その他レプリケーション製品
ターゲット ソース ターゲット
UPDATE ...UPDATE ...
:
COMMIT;
長時間トランザクション実行時の伝搬遅延 発生を抑止
Copyright © 2018 CO-Sol Inc. All Rights Reserved. | 29
• RPM一発でインストール可能
• 導入後、GUIで即座に同期可能
• 既存環境(ソースDB、ターゲットDB)へ製品導入不要
– いわゆるエージェントレス
Attunityのイチオシポイント
圧倒的な使いやすさ、導入しやすさ
Attunity
Copyright © 2018 CO-Sol Inc. All Rights Reserved. | 30
導入後、GUIで即座に同期可能Attunityのイチオシポイント
Endpoint を登録したデータベースをDrag & Drop
伝搬対象を指定
ターゲットDBへの初期データ移入も自動的に実行!
Attunity
Copyright © 2018 CO-Sol Inc. All Rights Reserved. | 31
DB環境へ製品導入不要Attunityのイチオシポイント
Attunity
ソースDB
REDO
Attunity Replicateのシステム構成
その他レプリケーション製品のシステム構成
エージェント
ソースDB
REDO エージェント
ターゲットDB
ターゲットDB
AttunityServer
Oracle Net Oracle Net
レプリケート
転送
適用
読出
※: GoldenGateも外部サーバー構成をサポート
Copyright © 2018 CO-Sol Inc. All Rights Reserved. | 32
DBAの窓口 - コーソル サービス紹介
• Oracle Databaseに関する豊富なノウハウを生かし、中立の立場でお客様に最適な製品をご提案します。
• 購入後の設計/導入/運用も一気通貫でサポートします。• http://cosol.jp/business/service/license.shtml
Copyright © 2018 CO-Sol Inc. All Rights Reserved. | 33