SUPPLEMENTAL LOGGINGって何？
実は、レプリケーションソフトで異種データベースへデータ連携を行う場合には、追加のサプリメンタル・ロギングが必要になります。以下のように追加のサプリメンタル・ロギング設定が必要な理由がマニュアルにも記述されています。
再構築されたSQL文を別のデータベースに適用するアプリケーションでは、行を一意に識別する列(主キーなど)で更新文を識別する必要があります。
ROWID はデータベースごとに異なり、他のデータベースでは意味を持たないためV$LOGMNR_CONTENTS ビューによって返される再構築されたSQL に示されるROWID では識別できません。
やはり、ROWIDでは、他のデータベースへの連携が難しいとあります。
そこで必要になるのが追加サプリメンタル・ロギングです。この追加サプリメンタル・ロギングは、異種データベース間で一意にデータを特定して更新情報を連携するためにプライマリキーが存在すれば、プライマリキーを指定して一意にデータを特定出来るようにトランザクションログにプライマリキー情報を追加します。プライマリキーが無い場合には、全カラムの条件を付加するように設定を行います。ただし、SQL文でデータ連携している以上、ロジカルレプリケーション対象テーブルでは、プライマリキーは「必須」と考えた方が良いと思います。なぜなら、プライマリキーがあれば、直ぐにデータを見つけて更新処理を実行することが出来ますが、プライマリキーが無い状態だとインデックス検索、さらにインデックスも無い場合には、フルスキャンになってターゲットデータベースへの反映に時間がかかり過ぎて同期処理が追いつかない可能性があるからです。
４． サプリメンタル・ロギングの設定
A. 現在の設定状態を確認
SQL> SELECT LOG_GROUP_NAME, TABLE_NAME, ALWAYS,
LOG_GROUP_TYPE FROM USER_LOG_GROUPS;
レコードが選択されませんでした。B. デフォルトでは設定されていないので有効化
SQL> ALTER TABLE EMP ADD SUPPLEMENTAL LOG DATA(PRIMARY KEY) COLUMNS;
表が変更されました。
SQL> ALTER TABLE DEPT ADD SUPPLEMENTAL LOG DATA(PRIMARY KEY) COLUMNS;
表が変更されました。
SQL> ALTER TABLE SALGRADE ADD SUPPLEMENTAL LOG DATA(ALL) COLUMNS;
表が変更されました。C. 実際に変更されたか確認
SQL> SELECT LOG_GROUP_NAME, TABLE_NAME, ALWAYS, LOG_GROUP_TYPE FROM USER_LOG_GROUPS;
LOG_GROUP_NAME TABLE_NAME ALWAYS LOG_GROUP_TYPE
-------------------- -------------------- -------------------- -----------------
SYS_C004204 EMP ALWAYS PRIMARY KEY LOGGING
SYS_C004205 DEPT ALWAYS PRIMARY KEY LOGGING
SYS_C004206 SALGRAD ALWAYS ALL COLUMN LOGGINGV$LOGMNR_CONTENTSを参照すると(追加設定後)
追加サプリメンタル・ロギング設定後、V$LOGMNR_CONTENTSビューのSQL_REDO列を見てみると、プライマリキー指定したものはプライマリキー、全カラム指定したものは全カラムの条件が付加されて生成されていることがわかります。
もう少し単純化してみます。
追加サプリメンタル・ロギングの設定によるトランザクションログへの出力情報の変化は、以下のようになります。
追加サプリメンタル・ロギングは、異種データベース間でも更新されたデータを特定するために必要ということですね。ここまでトランザクションログに情報が出力されていれば、あとは、不要なROWIDの条件などを取り除いて連携先のデータベース上でSQLを実行するだけです。
Oracle以外でも同じ？
今回は、LogMinerという便利な機能があるのでOracleで確認してみましたが、レプリケーションソフトはOracleだけで使用するものではありません。それでは、その他のデータベースでは、どうでしょうか？
Microsoft SQL Server
PKなしテーブルに対して、変更データキャプチャを構成
■データベースレベルのCDC有効化
EXEC sys.sp_cdc_enable_db■テーブル毎のCDC有効化(プライマリキー無しの場合)
EXEC sys.sp_cdc_enable_table
@source_schema = N'[SCHEMAname]',
@source_name = N'[TABLEname]',
@role_name = NULLIBM Db2
データ複製に関する追加情報をログに記録することを有効化
■テーブル毎の変更データキャプチャの有効化
ALTER TABLE < name> DATA CAPTURE CHANGESこのように呼び方は、異なるものの同じようにトランザクションログに追加情報を設定する機能は、各RDBMSで備えています。しかし、DWH向けのデータベースであるTeradataやNeteezaなど、この機能を持っていないデータベースもあり、この場合には、変更情報の同期は難しいということになります。まあこれらは、データ同期先になることはありますがデータ同期元になる可能性は少ないデータベースですね。
良くお客様からこのトランザクションログに追加情報(SUPPLEMENTAL LOGGING)を付加したときには、負荷はどうなのか？と聞かれることも多くありますが、今回の検証でもわかりますようにトランザクションログへ出力する情報が増える＝トランザクションログのサイズが大きくなることはあります。あとは、情報を付加しますのでCPUの負荷もあります。ただし、実際に弊社で検証したところでは、数％以下の負荷でトランザクションログの増大も10%以下といったところで大きな問題になるケースはありませんでした。
Attunity Replicate
最後に弊社取り扱いレプリケーション製品Attunity Replicateですが、LogMinerを使用してレプリケーションすることもできるのですが、LogMinerは非常に負荷が高く遅いので、REDOログを直接読み込んで解析するレプリケーション方式を採用し、これにより低負荷で高速なレプリケーションを実現することも可能です。
最近では、異種やバージョンの異なるデータベースのミニマムダウンタイム移行や、データ分析基盤へのリアルタイムデータ連携の事例も多くなってきました。以前とは、データベースが担う役割も処理内容も変わってきました。様々なデータ処理基盤を活用するためにデータレプリケーションというテクノロジーを検討してみてはいかがでしょうか？
【異なるデータベース間のデータ同期が出来るわけ】連載一覧
- どんなデータベースがあるの
- データレプリケーションツール「Attunity Replicate」
- ロジカルレプリケーションの仕組み
- Oracleのトランザクションログに含まれる情報
- LogMinerを使用してトランザクションログを覗く
- LogMiner検証手順
- V$LOGMNR_CONTENTSを参照する
- SUPPLEMENTAL LOGGING
- V$LOGMNR_CONTENTSを参照する(追加設定後)
- Oracle以外でも同じか？
