背景・目的
以前、DMSについて整理しました。今回は、Oracleをデータソースにする場合の前提を整理します。
まとめ
下記に特徴をまとめます。
| 特徴 | 説明 |
|---|---|
| サポートしているOracleエディション | ・Oracle Enterprise Edition ・Oracle Standard Edition ・Oracle Express Edition ・Oracle Personal Edition |
| 暗号化 | SSL/TLS1.2以降、TDE |
| Oracle ソースエンドポイント設定手順 | 1. ユーザー作成 2. エンドポイント作成 3. CDC設定（変更データキャプチャ） |
| REDOログを読む方法 | ・OracleLogMiner ・DMS Binary Reader |
| REDOログとは | 障害時のデータベースリカバリとバックアップ後の最新変更を復元に使用される |
| LGWR | REDOログの循環書き込みする |
概要
下記を基に整理します。
下記のOracleデータベースエディションをサポートしている。
- Oracle Enterprise Edition
- Oracle Standard Edition
- Oracle Express Edition
- Oracle Personal Edition
暗号化
- SSL/TLS 1.2以降対応（TLS 1.3推奨）を使用して、Oracle エンドポイントとレプリケーションインスタンスとの接続を暗号化できる
- DMSでは、Oracle TDE（透過的データ暗号化）を使用して、ソースデータベースに保管中のデータを暗号化できる
Oracle ソースエンドポイント設定手順
-
ユーザー作成
- 適切な権限を持つOracleユーザーを作成する
-
エンドポイント作成
- Oracle設定に準拠したソースエンドポイントを作成する
- 全ロードのみであればここで終了
-
CDC設定（変更データキャプチャ）
- CDC使用時は以下から選択する
- Oracle LogMiner
- AWS DMS Binary Reader
- CDC使用時は以下から選択する
CDC での Oracle LogMiner または AWS DMS Binary Reader の使用
- OracleでCDCをソースとして実行する場合に、REDOログを読むには、OracleLogMinerとDMS Binary Readerの２つがある
- どちらもREDOログから変更データをキャプチャする
- AWS DMSはCDCにOracle LogMinerをデフォルトで使用する
| LogMiner | Binary Reader |
|---|---|
| オンラインREDOログとアーカイブREDOログを読み取り Oracle標準API使用 |
RAW REDOログファイルを直接読み取り・解析 AWS DMS独自メソッド |
| ほとんどのOracleオプション対応されている 設定がシンプル DMSで使用するテーブルクラスターに対応している |
I/O・CPU負荷が低い（直接マイニング） 大量変更時のCDCパフォーマンスが高い Oracle 12c LOBのCDC対応 |
REDOログ
そもそもREDOログとは、何かまとめます。
すべてのOracle Databaseには2つ以上のオンラインREDOログ・ファイルのセットがあります。オンラインREDOログ・ファイルのセットは、総称してデータベースのREDOログと呼ばれます。REDOログは、REDOレコードとも呼ばれるREDOエントリで構成されています。
オンラインREDOログには、データの変更内容のコピーが格納されます。障害により、バックアップからデータファイルをリストアする必要がある場合、リストアされたデータファイルにはない最新のデータ変更はオンラインREDOログ・ファイルから取得できるため、作業が失われることはありません。オンラインREDOログ・ファイルは、ハードウェア障害、ソフトウェア障害またはメディア障害の発生後、データベースのリカバリに使用されます。オンラインREDOログ・ファイル自体を含む障害に対して保護を行うために、Oracle Databaseでは、2つ以上のオンラインREDOログ・ファイルの同一のコピーを異なるディスクに保持できるように、オンラインREDOログ・ファイルを多重化できます。
データベースのオンラインREDOログは、オンラインREDOログ・ファイルのグループで構成されます。1つのグループは、オンラインREDOログ・ファイルとその多重コピーで構成されます。個別のコピーはそれぞれグループのメンバーとみなされます。各グループは「グループ1」のように番号で定義されます。
-
全Oracleデータベースに2つ以上のREDOログファイルがある
-
REDOエントリ（REDOレコード）で構成
-
データ変更内容のコピーを格納
-
下記の用途で使用される
- 障害時のデータベースリカバリ
- バックアップ後の最新変更を復元
-
障害に対して保護するために、2つ以上のオンラインREDOログ・ファイルの同一コピーを異なるディスクに保持する
データベース・ログ・ライター・プロセス(LGWR)は、そのグループのログ・ファイルが記憶域サイズの制限に達するまで、またはログ・スイッチ操作が要求されるまで、メモリー・バッファのREDOレコードをREDOログ・グループに書き込みます。次に、LGWRプロセスでは次のログ・グループに対して書込みを行います。最も古いグループが最新のREDOレコードによって上書きされるように、このアクションはLGWRプロセスにより循環方式で実行されます。
LGWR
REDOログの循環書き込みする
- メモリバッファのREDOレコードを現在のREDOロググループに書き込み
- 以下のいずれかで次のグループに切り替え（ログスイッチ）:
- ログファイルが容量上限に達した
- ログスイッチ操作が要求された
- 次のグループに書き込み開始
- 全グループを使い切ったら最初のグループに戻る
- 最も古いグループが最新のREDOレコードで上書きされる
アーカイブREDOログ
-
概要
- 書き込み済REDOログファイルをオフライン保存先にコピー
- ARCHIVELOGモードでのみ有効
- 自動または手動アーカイブ選択可能
-
用途
- データベースリカバリ
- スタンバイデータベース更新
- LogMinerによる履歴情報取得
-
仕組み
- ARCnプロセス（アーカイバ）が自動実行
- REDOログの多重化メンバーのいずれか1つをコピー
- 一意のログ順序番号を保持
-
制約
- アーカイブ完了まで、LGWRはそのグループを再利用（上書き）できない
- アーカイブが遅れるとREDOログが満杯で書き込み停止の可能性
サプリメンタルロギングの設定
- DMSでは進行中の変更をキャプチャするには、Oracleデータベースで最小限のサプリメンタルロギングを有効にする必要がある
- さらに、データベース内のレプリケーションされた各テーブルでサプリメンタルロギングを有効にする
サプリメンタルロギング
サプリメンタルロギングとは、何かまとめます。
-
REDOログに追加の列情報を記録する仕組み。デフォルトではOFF
-
デフォルトのREDOログの問題
- インスタンス/メディアリカバリ用の最小限の情報のみ
- プライマリキーなどの識別情報が不足
- LogMinerでは使えない（つまりLogMinerを使うDMSでも使えない。）
-
必要な理由
- 行の一意識別: 他のDBに変更を適用する際、ROWIDは使えない（DB固有）→ プライマリキーが必要
- 変更追跡: 変更された列だけでなく、行全体のビフォア・イメージが必要な場合
-
サプリメンタル・ログ・グループは、サプリメンタル・ロギングが有効な場合に記録される追加の列
-
サプリメンタル・ログ・グループは2種類ある
- 無条件のサプリメンタル・ログ・グループ
- 指定した列に更新が影響したかどうかに関係なく、行が更新されるたびに指定した列のビフォア・イメージが記録される
- 条件付きのサプリメンタル・ログ・グループ
- ログ・グループの1つ以上の列が更新された場合にのみ、指定したすべての列のビフォア・イメージが記録される
- 無条件のサプリメンタル・ログ・グループ
考察
今回、DMSのソースとしての Oracle データベースを整理しました。
次回は、実際に手を動かして確認します。
参考