Oracle® Streams

レプリケーション管理者ガイド

11g リリース2(11.2)

B61352-03(原本部品番号:E10705-10)

2013年6月

Oracle Streamsレプリケーション管理者ガイド 11g リリース2(11.2)

B61352-03

Copyright © 2003, 2013, Oracle and/or its affiliates.All rights reserved.

原本著者: Randy Urbano

協力者:  Nimar Arora、Lance Ashdown、Ram Avudaiappan、Neerja Bhatt、Ragamayi Bhyravabhotla、Alan Downing、Curt Elsbernd、Yong Feng、Jairaj Galagali、Lei Gao、Thuvan Hoang、Lewis Kaplan、Tianshu Li、Jing Liu、Edwina Lu、Raghu Mani、Rui Mao、Pat McElroy、Shailendra Mishra、Valarie Moore、Bhagat Nainani、Maria Pratt、Arvind Rajaram、Viv Schupmann、Vipul Shah、Neeraj Shodhan、Wayne Smith、Jim Stamos、Janet Stern、Mahesh Subramaniam、Bob Thome、Byron Wang、Wei Wang、James M.Wilson、Lik Wong、Jingwei Wu、Haobo Xu、Jun Yuan、David Zhang

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

第I部 Oracle Streamsレプリケーションの構成

1 Oracle Streamsレプリケーションの準備

- Oracle Streamsレプリケーションの概要

- Oracle Streamsレプリケーションを使用する一般的な理由

- Oracle Streamsレプリケーション環境のルール

- Oracle Streamsレプリケーションを構成する前に行う決定

- どのタイプのレプリケーション環境を構成するかの決定

- ソース・データベースに対してローカル取得またはダウンストリーム取得を構成するかどうかの決定

- 1つのデータベースまたは複数のデータベースで変更を許可するかどうかの決定

- レプリケーション環境に異なるレプリカを含めるかどうかの決定

- レプリケーション環境で適用ハンドラを使用するかどうかの決定

- DDL変更をメンテナンスするかどうかの決定

- レプリケーション環境の構成方法の決定

- Oracle Streamsレプリケーションを構成する前に実行するタスク

- すべてのデータベースでのOracle Streams管理者の構成

- ネットワーク接続性とデータベース・リンクの構成

- 各ソース・データベースがARCHIVELOGモードであることの確認

- Oracle Streamsに関連する初期化パラメータの設定

- Oracle Streamsプールの構成

- 自動メモリー管理を使用したOracle Streamsプールのサイズの設定

- 自動共有メモリー管理を使用したOracle Streamsプールのサイズの設定

- Oracle Streamsプール・サイズの手動による設定

- Oracle Streamsプール・サイズのデフォルト設定の使用

- サプリメンタル・ロギングの指定

- Oracle Streamsレプリケーション環境内の必要なサプリメンタル・ロギング

- 無条件ログ・グループを使用した表サプリメンタル・ロギングの指定

- 条件付きログ・グループを使用した表サプリメンタル・ロギングの指定

- サプリメンタル・ログ・グループの削除

- キー列のデータベース・サプリメンタル・ロギングの指定

- キー列のデータベース・サプリメンタル・ロギングの削除

- サプリメンタル・ロギングを自動的に指定するプロシージャ

- ダウンストリーム取得データベースへのログ・ファイルの転送の構成

- リアルタイム・ダウンストリーム取得のためのスタンバイREDOログの追加

2 Oracle Streamsレプリケーションの簡単な構成

- Streamsレプリケーションの設定ウィザードを使用したレプリケーションの構成

- DBMS_STREAMS_ADMパッケージを使用したレプリケーションの構成

- Oracle Streamsレプリケーション構成プロシージャ

- 構成プロシージャに関する重要な考慮事項

- ソース・データベースに対するローカル取得またはダウンストリーム取得

- 構成アクションの直接実行またはスクリプトを使用した実行

- これらのプロシージャによって構成されたOracle Streamsコンポーネント

- 一方向または双方向のレプリケーション

- データ定義言語(DDL)変更

- インスタンス化

- 必要なディレクトリ・オブジェクトの作成

- ローカル取得を使用した2データベース・レプリケーションを構成する場合の例

- ローカル取得を使用した2データベース・グローバル・レプリケーションの構成

- ローカル取得を使用した2データベース・スキーマ・レプリケーションの構成

- ローカル取得を使用した2データベース表レプリケーションの構成

- ダウンストリーム取得を使用した2データベース・レプリケーションを構成する場合の例

- 宛先でダウンストリーム取得を使用した表領域レプリケーションの構成

- 宛先でダウンストリーム取得を使用したスキーマ・レプリケーションの構成

- 第3のデータベースでダウンストリーム取得を使用したスキーマ・レプリケーションの構成

- ハブ・アンド・スポーク・レプリケーションを構成する場合の例

- Oracle Streams構成の進捗の監視

3 Oracle Streamsレプリケーションの柔軟な構成

- 新規の単一ソースOracle Streams環境の作成

- 新規の複数ソースOracle Streams環境の作成

- 複数ソース環境の作成時の実装済データベースの構成

- 新規環境作成時のインポート・データベースへのレプリケート・オブジェクトの追加

- 複数ソース環境の構成完了

4 Oracle Streamsレプリケーション環境への追加

- Oracle Streamsレプリケーション環境への追加について

- Streamsレプリケーションの設定ウィザードまたは単一の構成プロシージャの使用について

- 複数の手順でのOracle Streamsコンポーネントの個別追加について

- 単一のプロシージャを使用した複数のコンポーネントの追加

- 単一のプロシージャを使用したレプリケーション環境へのデータベース・オブジェクトの追加

- 単一のプロシージャを使用したレプリケーション環境へのデータベースの追加

- 複数の手順でのコンポーネントの個別追加

- 既存の単一ソース環境へのレプリケート・オブジェクトの追加

- 単一ソース環境への新規宛先データベースの追加

- 既存の複数ソース環境へのレプリケート・オブジェクトの追加

- レプリケート・オブジェクト追加時の実装済データベースの構成

- 既存の環境におけるインポート・データベースへのレプリケート・オブジェクトの追加

- 複数ソース環境構成へのオブジェクトの追加の完了

- 既存の複数ソース環境への新規データベースの追加

- レプリケート・オブジェクトが新規データベースに存在する場合のデータベースの構成

- 新規データベースへのレプリケート・オブジェクトの追加

5 暗黙的取得の構成

- 取得プロセスの構成

- 取得プロセスの構成の準備

- ローカルの取得プロセスの構成

- DBMS_STREAMS_ADMを使用したローカルの取得プロセスの構成

- DBMS_CAPTURE_ADMを使用したローカルの取得プロセスの構成

- NULL以外の開始SCNを使用したローカルの取得プロセスの構成

- ダウンストリーム取得プロセスの構成

- リアルタイム・ダウンストリーム取得プロセスの構成

- アーカイブ・ログ・ダウンストリーム取得プロセスの構成

- 取得プロセスの構成後

- 同期取得の構成

- 同期取得の構成の準備

- DBMS_STREAMS_ADMパッケージを使用した同期取得の構成

- DBMS_CAPTURE_ADMパッケージを使用した同期取得の構成

- 同期取得の構成後

6 キューと伝播の構成

- ANYDATAキューの作成

- ANYDATAキュー間のOracle Streamsの伝播の作成

- 伝播の作成の準備

- DBMS_STREAMS_ADMを使用した伝播の作成

- DBMS_PROPAGATION_ADMを使用した伝播の作成

7 暗黙的適用の構成

- 適用プロセスの作成の概要

- 適用プロセスの作成の準備

- DBMS_STREAMS_ADMを使用した取得LCRの適用プロセスの作成

- DBMS_APPLY_ADMを使用した適用プロセスの作成

- DBMS_APPLY_ADMを使用した取得LCRの適用プロセスの作成

- DBMS_APPLY_ADMを使用した永続LCRの適用プロセスの作成

8 インスタンス化とOracle Streamsレプリケーション

- インスタンス化とOracle Streamsレプリケーションの概要

- 取得のルールとインスタンス化の準備

- 自動的にオブジェクトを準備するDBMS_STREAMS_ADMパッケージのプロシージャ

- インスタンス化の準備が必要な場合

- インスタンス化の準備中のサプリメンタル・ロギング・オプション

- ソース・データベースでインスタンス化を行うためのデータベース・オブジェクトの準備

- インスタンス化のための表の準備

- インスタンス化のためのスキーマ内のデータベース・オブジェクトの準備

- インスタンス化のためのデータベース内のすべてのデータベース・オブジェクトの準備

- ソース・データベースでのインスタンス化の準備の強制終了

- Oracle Data PumpとOracle Streamsのインスタンス化

- データ・ポンプ・エクスポートとオブジェクトの一貫性

- Oracle Data Pump ImportとOracle Streamsのインスタンス化

- インスタンス化SCNとデータ・ポンプ・インポート

- インスタンス化SCNとデータ・ポンプ・インポートによるOracle Streamsタグ

- STREAMS_CONFIGURATIONデータ・ポンプ・インポート・ユーティリティ・パラメータ

- データ・ポンプ・エクスポート/インポートを使用したオブジェクトのインスタンス化

- Recovery Manager(RMAN)とOracle Streamsのインスタンス化

- トランスポータブル表領域またはRMANを使用した表領域内のオブジェクトのインスタンス化

- トランスポータブル表領域を使用したオブジェクトのインスタンス化

- バックアップからのトランスポータブル表領域とRMANを使用したオブジェクトのインスタンス化

- RMANを使用したデータベース全体のインスタンス化

- RMANを使用した同じプラットフォーム上のデータベース全体のインスタンス化

- RMANを使用した異なるプラットフォーム上のデータベース全体のインスタンス化

- 宛先データベースでのインスタンス化SCNの設定

- エクスポート/インポートを使用したインスタンス化SCNの設定

- 全データベースのエクスポートと全データベースのインポート

- 全データベースまたはユーザー・エクスポートおよびユーザー・インポート

- 全データベース、ユーザーまたは表エクスポートおよび表インポート

- DBMS_APPLY_ADMパッケージを使用したインスタンス化SCNの設定

- ソース・データベースへの接続中のインスタンス化SCNの設定

- 宛先データベースへの接続中のインスタンス化SCNの設定

- インスタンス化の監視

- どのデータベース・オブジェクトがインスタンス化のために準備済であるかの判断

- インスタンス化SCNが設定されている表の判断

9 Oracle Streamsの競合解消

- Oracle Streams環境内のDMLの競合

- Oracle Streams環境内の競合のタイプ

- Oracle Streams環境内の更新の競合

- Oracle Streams環境内の一意性競合

- Oracle Streams環境内の削除の競合

- Oracle Streams環境内の外部キーの競合

- Oracle Streams環境内の競合とトランザクションの順序付け

- Oracle Streams環境内の競合検出

- 非キー列の競合検出の制御

- Oracle Streams環境内の競合検出中の行の識別

- Oracle Streams環境内の競合防止

- プライマリ・データベース所有権モデルの使用

- 特定タイプの競合の防止

- Oracle Streams環境内の一意性競合の防止

- Oracle Streams環境内の削除の競合の防止

- Oracle Streams環境内の更新の競合の防止

- Oracle Streams環境内の競合解消

- ビルトインの更新の競合ハンドラ

- ビルトインの更新の競合ハンドラのタイプ

- 列リスト

- 解消列

- データ収束

- カスタム競合ハンドラ

- Oracle Streamsの競合検出および解消の管理

- 更新の競合ハンドラの設定

- 既存の更新の競合ハンドラの変更

- 既存の更新の競合ハンドラの削除

- 非キー列の競合検出の停止

- 競合検出および更新の競合ハンドラの監視

- 競合検出に関する情報の表示

- 更新の競合ハンドラに関する情報の表示

10 Oracle Streamsタグ

- タグの概要

- DBMS_STREAMS_ADMパッケージによって作成されるタグとルール

- タグとオンライン・バックアップ文

- タグと適用プロセス

- レプリケーション環境のOracle Streamsタグ

- n-wayレプリケーション環境

- ハブ・アンド・スポーク・レプリケーション環境

- 複数の拡張セカンダリ・データベースを含むハブ・アンド・スポーク・レプリケーション環境

- Oracle Streamsタグの管理

- 現行セッションのOracle Streamsタグの管理

- 現行セッションで生成されるタグ値の設定

- 現行セッションのタグ値の取得

- 適用プロセス用のOracle Streamsタグの管理

- 適用プロセスで生成されるタグ値の設定

- 適用プロセス用の適用タグの削除

- Oracle Streamsタグの監視

- 現行セッション用のタグ値の表示

- 各適用プロセス用のデフォルトのタグ値の表示

11 Oracle Streamsの異機種間での情報の共有

- Oracle Streamsを使用したOracleからOracle以外のデータベースへのデータの共有

- OracleからOracle以外への環境での変更の取得とステージング

- OracleからOracle以外への環境での変更の適用

- OracleからOracle以外への環境での適用プロセスの構成

- Oracle以外のデータベースで適用されるデータ型

- Oracle以外のデータベースで適用されるDML変更のタイプ

- OracleからOracle以外への環境でのインスタンス化

- OracleからOracle以外への環境での変換

- メッセージ・ゲートウェイとOracle Streams

- OracleからOracle以外への環境でのエラー処理

- OracleからOracle以外へのStreams環境の例

- Oracle Streamsを使用したOracle以外のデータベースからOracle Databaseへのデータの共有

- Oracle以外からOracleへの環境での変更の取得

- Oracle以外からOracleへの環境でのステージング

- Oracle以外からOracleへの環境での変更の適用

- Oracle以外のデータベースからOracle Databaseへのインスタンス化

- Oracle Streamsを使用したOracle以外のデータベース間でのデータの共有

第II部 Oracle Streamsレプリケーションの管理

12 Oracle Streamsレプリケーションの管理

- Oracle Streamsの管理

- ストリームでのLCRの追跡

- Oracle Streamsの接続先の分割およびマージ

- Oracle Streamsの分割およびマージ

- 分割およびマージのオプション

- 自動の分割およびマージ

- 手動の分割および自動のマージ

- 手動の分割および生成されたスクリプトによるマージ

- Oracle Streamsの分割およびマージの例

- Oracle Streamsの宛先の自動的な分割およびマージ

- Oracle Streamsの宛先の手動での分割および自動的なマージ

- Oracle Streamsの接続先のスクリプトによる手動の分割およびマージ

- ソース・データベースのDBIDまたはグローバル名の変更

- 複数ソース環境でのソース・データベースの再同期化

- Oracle Streams環境におけるデータベースのPoint-in-Timeリカバリの実行

- 単一ソース環境のソースにおけるPoint-in-Timeリカバリの実行

- 複数ソース環境におけるPoint-in-Timeリカバリの実行

- 宛先データベースにおけるPoint-in-Timeリカバリの実行

- リカバリを実行するための既存の取得プロセスの開始SCNのリセット

- リカバリを実行するための新規の取得プロセスの作成

- Oracle Streamsレプリケーション環境でのフラッシュバック問合せの実行

- 操作エラーからのリカバリ

- リカバリの例

13 データの比較および収束

- データの比較および収束

- スキャン

- バケット

- 親スキャンおよびルート・スキャン

- スキャンおよびバケットでの違いの識別方法

- DBMS_COMPARISONパッケージに関する他のマニュアル

- 共有データベース・オブジェクトの比較および収束の準備

- 2つのデータベースのデータベース・オブジェクトの拡散の例

- 2つのデータベースの共有データベース・オブジェクトの比較

- 共有データベース・オブジェクトの列のサブセットの比較

- 行の違いを識別しない共有データベース・オブジェクトの比較

- 共有データベース・オブジェクトのランダム部分の比較

- 共有データベース・オブジェクトの循環比較

- 共有データベース・オブジェクトのカスタム部分の比較

- CLOB列またはBLOB列を含む共有データベース・オブジェクトの比較

- 比較および比較結果に関する情報の表示

- データベース内の比較に関する一般的な情報の表示

- ランダム比較および循環比較固有の情報の表示

- データベース内の各比較によって比較された列の表示

- データベース内の各スキャンに関する一般的な情報の表示

- データベース内の各スキャンの親スキャンIDおよびルート・スキャンIDの表示

- スキャンで検出された行の違いの詳細の表示

- 特定のスキャンで比較された行に関する情報の表示

- 共有データベース・オブジェクトの収束

- ローカル・オブジェクトとの一貫性を保持するための共有データベース・オブジェクトの収束

- リモート・オブジェクトとの一貫性を保持するための共有データベース・オブジェクトの収束

- セッション・タグ・セットによる共有データベース・オブジェクトの収束

- 比較の比較結果の再確認

- 比較結果のパージ

- 比較のすべての比較結果のパージ

- 比較の特定のスキャンIDの比較結果のパージ

- 指定した時間より前の比較の比較結果のパージ

- 比較の削除

- Oracle Streamsレプリケーション環境でのDBMS_COMPARISONの使用

- インスタンス化の後の一貫性の確認

- 稼働中のOracle Streamsレプリケーション環境での一貫性の確認

14 論理変更レコード(LCR)の管理

- LCRを管理するための要件

- LCRの構成とエンキュー

- LCRの実行

- 行LCRの実行

- 行LCRの構成および実行の例

- DDL LCRの実行

- LOB列を含むLCRの管理

- LOBを含むLCRの直接適用に対する適用プロセスの動作

- LOBアセンブリとLOB列を含むLCRのカスタム適用

- LOBアセンブリに関する考慮事項

- LOBアセンブリの例

- LOB列を含むLCRを構成および処理するための要件

- LOBアセンブリを使用せずにLCRを構成および処理するための要件

- LOBアセンブリを使用してLCRを適用ハンドラで処理するための要件

- LOBを含むLCRをルールベースの変換で処理するための要件

- LONGまたはLONG RAW列を含むLCRの管理

第III部 Oracle Streamsレプリケーションのベスト・プラクティス

15 Oracle Streamsレプリケーション・データベースのベスト・プラクティス

- Oracle Streamsデータベース構成のベスト・プラクティス

- Oracle Streamsクライアント(取得および適用プロセス)用の個別のキューの使用

- Oracle Streamsレプリケーション構成の自動化

- Oracle Streamsデータベースの操作のベスト・プラクティス

- Oracle Streamsデータベースのグローバル名のベスト・プラクティスへの準拠

- パフォーマンスの監視と必要に応じた調整

- サイズに対する取得プロセスのキューおよび同期取得のキューの監視

- バックアップのOracle Streamsのベスト・プラクティスへの準拠

- Oracle Streamsソース・データベースのバックアップのベスト・プラクティス

- Oracle Streams宛先データベースのバックアップのベスト・プラクティス

- オプティマイザ統計の自動収集の調整

- Oracle Streams情報のアラート・ログの確認

- データベースでOracle Streams構成を削除するベスト・プラクティスへの準拠

- Oracle Real Application ClustersおよびOracle Streamsのベスト・プラクティス

- すべてのスレッドのアーカイブ・ログ・ファイルの取得プロセスでの使用可能化

- Oracle RACデータベースのグローバル名のベスト・プラクティスへの準拠

- 伝播を構成および管理するベスト・プラクティスへの準拠

- キュー所有権のベスト・プラクティスへの準拠

16 取得のベスト・プラクティス

- 取得プロセスの構成のベスト・プラクティス

- 取得ユーザーへの必要な権限の付与

- 取得プロセスの並列性の設定

- チェックポイント保存時間の設定

- 取得プロセスの操作のベスト・プラクティス

- Oracle Streams環境内の各ソース・データベースでのハートビート表の構成

- 定期的なディクショナリ構築およびインスタンス化のためのデータベース・オブジェクトの定期的な準備

- バッチ処理のパフォーマンスへの影響の最小化

- 同期取得の構成のベスト・プラクティス

17 伝播のベスト・プラクティス

- 伝播の構成のベスト・プラクティス

- キュー・ツー・キュー伝播の使用

- 各伝播の伝播待機時間の設定

- ネットワーク・パフォーマンス向上のためのWide Area NetworkにおけるSDUの増加

- 伝播の操作のベスト・プラクティス

- 故障した伝播の再起動

18 適用のベスト・プラクティス

- 宛先データベース構成のベスト・プラクティス

- 適用ユーザーへの必要な権限の付与

- インスタンス化SCNの値の設定

- 競合解消の構成

- 適用プロセスの構成のベスト・プラクティス

- 適用プロセスの並列性の設定

- エラー発生時の適用プロセスの続行の検討

- 適用プロセスの操作のベスト・プラクティス

- 適用エラーの管理

第IV部 付録

A Oracle Streamsへのアドバンスト・レプリケーションの移行

- 移行プロセスの概要

- 移行スクリプトの生成と使用

- 移行スクリプトの変更

- 生成されたスクリプトによって実行されるアクション

- 移行スクリプトのエラー

- 更新可能なマテリアライズド・ビューの手動移行

- Oracle Streamsに移行できないアドバンスト・レプリケーション要素

- 移行スクリプトの生成の準備

- 移行スクリプトの生成と変更

- Oracle Streamsに移行するアドバンスト・レプリケーション環境の例

- Oracle Streamsへのアドバンスト・レプリケーションの移行の実行

- 移行スクリプトの実行前の手順

- 移行スクリプトの実行

- スクリプトの実行後の手順

- マテリアライズド・ビュー・グループを保持するマスター・サイトの再作成

- Oracle Streams移行スクリプトに移行するアドバンスト・レプリケーションの例

索引

はじめに

『Oracle Streamsレプリケーション管理者ガイド』では、データ・レプリケーションに使用できるOracle Streamsの特長と機能について説明します。また、Oracle Streamsレプリケーションの概念、およびOracle Streamsレプリケーション環境を構成および管理する方法について説明します。

ここでは、次の項目について説明します。

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

対象読者

『Oracle Streamsレプリケーション管理者ガイド』は、Oracle Streamsレプリケーション環境の作成とメンテナンスを担当するデータベース管理者を対象としています。これらの管理者は、次の1つ以上のタスクを実行します。

- Oracle Streamsレプリケーション環境のプラン作成

- Oracle Streamsレプリケーション環境の構成

- Oracle Streamsレプリケーション環境における競合解消の構成

- Oracle Streamsレプリケーション環境の管理

- Oracle Streamsレプリケーション環境の監視

- Oracle Streamsレプリケーション環境に必要なトラブルシューティングの実行

このマニュアルを使用するには、リレーショナル・データベースの概念、SQL、分散データベースの管理、Oracle Streamsの一般的な概念、アドバンスト・キューイングの概念、PL/SQLおよびOracle Streams環境を稼働させるオペレーティング・システムに関する十分な知識が必要です。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

Oracleサポート・サービスでは、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info)か、聴覚に障害のあるお客様は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。

関連ドキュメント

詳細は、次のOracleドキュメントを参照してください。

- 『Oracle Streams概要および管理』

- 『Oracle Database概要』

- 『Oracle Database管理者ガイド』

- 『Oracle Database SQL言語リファレンス』

- 『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』

- 『Oracle Database PL/SQL言語リファレンス』

- 『Oracle Databaseユーティリティ』

- 『Oracle Database Heterogeneous Connectivityユーザーズ・ガイド』

- Oracle Enterprise ManagerのOracle Streamsツールに関するOracle Streamsオンライン・ヘルプ

このマニュアルに記載されている多数の例は、Oracle Databaseとともにデフォルトでインストールされる、サンプル・データベースのサンプル・スキーマを使用しています。これらのスキーマがどのように作成されているかと、その使用方法については、『Oracle Databaseサンプル・スキーマ』を参照してください。

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ドキュメントのタイトル、強調またはユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

第I部

Oracle Streamsレプリケーションの構成

この部では、Oracle Streamsレプリケーションの構成について説明します。この部の構成は、次のとおりです。

- 第1章「Oracle Streamsレプリケーションの準備」

- 第2章「Oracle Streamsレプリケーションの簡単な構成」

- 第3章「Oracle Streamsレプリケーションの柔軟な構成」

- 第4章「Oracle Streamsレプリケーション環境への追加」

- 第5章「暗黙的取得の構成」

- 第6章「キューと伝播の構成」

- 第7章「暗黙的適用の構成」

- 第8章「インスタンス化とOracle Streamsレプリケーション」

- 第9章「Oracle Streamsの競合解消」

- 第10章「Oracle Streamsタグ」

- 第11章「Oracle Streamsの異機種間での情報の共有」

1 Oracle Streamsレプリケーションの準備

この章では、Oracle Streamsレプリケーション環境を準備する方法について説明します。また、Oracle Streamsレプリケーション環境を準備する場合のベスト・プラクティスについても説明します。

この章の内容は次のとおりです。

- Oracle Streamsレプリケーションの概要

- Oracle Streamsレプリケーションを構成する前に行う決定

- Oracle Streamsレプリケーションを構成する前に実行するタスク

関連項目:
Oracle Streamsの概要は、『Oracle Streams概要および管理』を参照してください。このマニュアルでは、『Oracle Streams概要および管理』で説明する概念を理解していることを想定しています。

Oracle Streamsレプリケーションの概要

レプリケーションとは、複数のデータベースのデータベース・オブジェクトおよびデータを共有するプロセスです。レプリケートされたデータベース・オブジェクトおよびデータを複数のデータベースでメンテナンスするために、あるデータベース上でデータベース・オブジェクトのいずれかが変更されると、その変更は他のデータベースと共有されます。このプロセスによって、データベース・オブジェクトおよびデータは、レプリケーション環境にあるすべてのデータベースで、同期状態が保たれます。Oracle Streamsレプリケーション環境では、変更が発生したデータベースはソース・データベース、変更が共有されるデータベースは宛先データベースと呼ばれます。

Oracle Streamsを使用する場合、データ操作言語(DML)変更またはデータ定義言語(DDL)変更のレプリケーションでは、通常、次の3つの手順が実行されます。

1. 取得プロセス、同期取得またはアプリケーションによって、1つ以上の論理変更レコード(LCR)が作成され、エンキューされます。LCRは、データベース変更を説明する特定の形式のメッセージです。取得プロセスではREDOログから取得した変更がLCRに再フォーマットされ、同期取得では内部メカニズムを使用して変更がLCRに再フォーマットされ、アプリケーションではLCRを構成できます。変更がDML操作の場合、各行LCRでは、ソース・データベースのレプリケートされた表に対するDML操作による行の変更がカプセル化されます。変更がDDL操作の場合、DDL LCRでは、ソース・データベースのレプリケートされたデータベース・オブジェクトに対するDDL変更がカプセル化されます。

2. 伝播によって、ステージングされたLCRが別のキューに伝播されますが、通常、このキューはLCRが取得されたデータベースとは別のデータベースに存在します。LCRは、宛先データベースに到達する前に、複数の異なるキューに伝播できます。

3. 宛先データベースでは、適用プロセスによって変更がコンシュームされます。適用プロセスでは、LCRをデキューしてレプリケートされたデータベース・オブジェクトに直接適用するか、またはLCRをデキューして適用ハンドラに送信できます。Oracle Streamsレプリケーション環境では、適用ハンドラによって、カスタマイズされたLCRの処理が実行されます。適用ハンドラでは、LCRの変更をレプリケートされたデータベース・オブジェクトに適用するか、または他のなんらかの方法でLCRをコンシュームできます。

手順1および手順3は必須ですが、取得プロセスまたは同期取得では変更をキューにエンキューでき、適用プロセスでは同じキューから変更をデキューできる場合があるため、手順2はオプションです。また、アプリケーションで、LCRを宛先データベースに直接エンキューすることもできます。さらに、Oracle DatabaseがOracle以外のデータベースと情報を共有している異機種間レプリケーション環境では、LCRを伝播せずに、適用プロセスがOracle以外のデータベースに直接変更を適用できます。

図1-1に、Oracle Streamsレプリケーション環境での情報の流れを示します。

図1-1 Oracle Streamsでの情報の流れ

このマニュアルでは、レプリケーションにOracle Streamsを使用する方法について説明します。また、次の情報も含まれます。

- Oracle Streamsレプリケーションに関する概念

- Oracle Streamsレプリケーション環境の構成手順

- Oracle Streamsレプリケーション環境の管理、監視およびトラブルシューティングの手順

- Oracle Streamsレプリケーション環境を作成およびメンテナンスする例

レプリケーションは、情報共有形式の1つです。Oracle Streamsではレプリケーションが実行可能になり、また、メッセージ、イベントの管理と通知、データ・ウェアハウスのロード、データ保護など、他の情報共有形式も使用できます。

関連項目:
Oracle Streamsの詳細は、『Oracle Streams概要および管理』を参照してください。

Oracle Streamsレプリケーションを使用する一般的な理由

Oracle Streamsレプリケーションを使用する一般的な理由は、次のとおりです。

- 可用性: レプリケーションを使用すると複数のサイト間でアクティビティのバランスを保つことができるため、共有データへの高速なローカル・アクセスが可能になります。一部のユーザーが1つのサーバーにアクセスしてる間に、他のユーザーは別のサーバーにアクセスできるため、すべてのサーバーの負荷が削減されます。また、ユーザーはアクセス・コストが最も低いレプリケーション・サイト(通常、ユーザーから地理的に最も近いサーバー)のデータを利用できます。

- パフォーマンスおよびネットワーク負荷の削減: レプリケーションを使用すると複数のサイト間でアクティビティのバランスを保つことができるため、共有データへの高速のローカル・アクセスが可能になります。一部のユーザーが1つのサーバーにアクセスしてる間に、他のユーザーは別のサーバーにアクセスできるため、すべてのサーバーの負荷が削減されます。アプリケーションでは、1つの中央サーバーにアクセスするかわりに、様々な地域サーバーにアクセスできます。この構成によってネットワーク負荷を大幅に削減できます。

Oracle Streamsレプリケーション環境のルール

ルールとは、イベントの発生時に条件が満たされている場合に、クライアントでアクションを実行できるようにするデータベース・オブジェクトです。ルールは、Oracle Databaseの組込み部分であるルール・エンジンによって評価されます。ルールによって、Oracle Streamsレプリケーション環境での情報の流れが制御されます。次の各コンポーネントはルール・エンジンのクライアントです。

- 取得プロセス

- 同期取得

- 伝播

- 適用プロセス

ルールを使用して、これらの各Oracle Streamsクライアントの動作を制御します。ルール・セットは複数のルールで構成されています。取得プロセス、伝播および適用プロセスにはポジティブ・ルール・セットおよびネガティブ・ルール・セットを関連付けることができますが、同期取得で使用できるのはポジティブ・ルール・セットのみです。

レプリケーション環境では、Oracle Streamsクライアントは、論理変更レコード(LCR)がルール・セットを満たす場合に操作を実行します。一般的に、LCRについてTRUEと評価されるルールがネガティブ・ルール・セットに存在せず、LCRについてTRUEと評価されるルールがポジティブ・ルール・セットに1つでも存在する場合に、LCRはOracle Streamsクライアントのルール・セットを満たします。Oracle Streamsクライアントがポジティブ・ルール・セットおよびネガティブ・ルール・セットの両方に関連付けられている場合、常にネガティブ・ルール・セットが先に評価されます。

具体的には、Oracle Streamsレプリケーション環境では、次の方法で情報の流れを制御します。

- 取得プロセスでREDOログから取得または廃棄する変更を指定します。REDOログで検出された変更が取得プロセスのルール・セットを満たす場合、取得プロセスはその変更を取得します。REDOログで検出された変更が取得プロセスのルール・セットを満たさない場合、取得プロセスはその変更を廃棄します。

- 同期取得で取得または廃棄する変更を指定します。表に対するDML変更が同期取得のルール・セットを満たす場合、同期取得はその変更を取得します。表に対するDML変更が同期取得のルール・セットを満たさない場合、同期取得はその変更を廃棄します。

- 伝播であるキューから別のキューに伝播させるか、または廃棄するLCRを指定します。キュー内のLCRが伝播のルール・セットを満たす場合、伝播はそのLCRを送信します。キュー内のLCRが伝播のルール・セットを満たさない場合、伝播はそのLCRを廃棄します。

- 適用プロセスでデキューするか、または廃棄するLCRを指定します。キュー内のLCRが適用プロセスのルール・セットを満たす場合、適用プロセスはLCRをデキューおよび処理します。キュー内のLCRが適用プロセスのルール・セットを満たさない場合、適用プロセスはそのLCRを廃棄します。

Oracleが提供するDBMS_STREAMS_ADMのPL/SQLパッケージを使用して、Oracle Streamsレプリケーション環境のルールを作成できます。このシステム作成ルールは、次のレベルで指定できます。

- 表レベル: 特定の表に対する変更についてTRUEと評価されるルール条件を含みます。

- スキーマ・レベル: 特定のスキーマおよびそのスキーマ内のデータベース・オブジェクトに対する変更についてTRUEと評価されるルール条件を含みます。

- グローバル・レベル: データベースに対するすべての変更についてTRUEと評価されるルール条件を含みます。

また、1つのシステム作成ルールがDML変更またはDDL変更のどちらかについてTRUEと評価される場合はありますが、両方がそのように評価されることはありません。そのため、たとえば、特定の表に対するDML変更とDDL変更の両方をレプリケートするには、その表に対する表レベルのDMLルールおよび表レベルのDDLルールの両方が必要です。

Oracle Streamsでは、サブセット・ルールを使用した表データのサブセット化もサポートされています。データベース内のレプリケートされた表にデータのサブセットのみが含まれている場合は、データの適切なサブセットのみがレプリケートされるようにOracle Streamsを構成できます。たとえば、あるデータベースは、特定の部門についてのみ従業員のデータをメンテナンスできます。レプリケーション環境の他の1つ以上のデータベースに、従業員表のすべてのデータが含まれている場合があります。この場合、サブセット・ルールでは、サブセット表を使用してその部門の従業員データの変更をレプリケートできますが、他部門の従業員の変更はレプリケートできません。

サブセット化は、Oracle Streamsの情報の流れの中で、どの時点でも実行できます。つまり、取得プロセスまたは同期取得では、サブセット・ルールを使用して特定の表に対する変更のサブセットを取得でき、伝播では、サブセット・ルールを使用して特定の表に対する変更のサブセットを伝播でき、適用プロセスでは、サブセット・ルールを使用して特定の表に対する変更のサブセットを適用できます。

注意:
同期取得では表ルールのみが使用されます。スキーマ・ルールおよびグローバル・ルールは無視されます。

関連項目:
Oracle Streamsでルールを使用する方法の詳細は、『Oracle Streams概要および管理』を参照してください。

Oracle Streamsレプリケーションを構成する前に行う決定

Oracle Streamsレプリケーションを構成する前に、次の決定を行います。

- どのタイプのレプリケーション環境を構成するかの決定

- ソース・データベースに対してローカル取得またはダウンストリーム取得を構成するかどうかの決定

- 1つのデータベースまたは複数のデータベースで変更を許可するかどうかの決定

- レプリケーション環境に異なるレプリカを含めるかどうかの決定

- レプリケーション環境で適用ハンドラを使用するかどうかの決定

- DDL変更をメンテナンスするかどうかの決定

- レプリケーション環境の構成方法の決定

どのタイプのレプリケーション環境を構成するかの決定

レプリケーション環境を構成する前に、まず、レプリケーション環境に含めるデータベースの数、レプリケートするデータベース・オブジェクト、およびレプリケーション環境でのデータベースの変更の流れを決定します。最も一般的なタイプのレプリケーション環境は、次のとおりです。

- 一方のデータベースが読取り/書込み可能で、もう一方のデータベースが読取り専用である2データベース環境での一方向のレプリケーション

- 両方のデータベースが読取り/書込み可能である2データベース環境での双方向のレプリケーション

- 1つの読取り/書込み可能なハブ、および複数の読取り専用スポークを持つハブ・アンド・スポーク・レプリケーション

- 読取り/書込み可能なハブ、および1つ以上の読取り/書込み可能なスポークを持つハブ・アンド・スポーク・レプリケーション

- 複数の読取り/書込み可能なデータベースを持つn-wayレプリケーション

ほとんどの組織のレプリケーション要件は、これらの環境のいずれかによって満たされます。これらの一般的なタイプのレプリケーション環境の詳細は、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

これらの一般的なレプリケーション環境で要件が満たされない場合は、Oracle Streamsを使用して、ほぼすべてのタイプのカスタム・レプリケーション環境を構成できます。たとえば、カスタム・レプリケーション環境では、データベースの変更を、宛先データベースに適用する前に複数の中間データベースを介して送信できます。

ソース・データベースに対してローカル取得またはダウンストリーム取得を構成するかどうかの決定

ローカル取得とは、ソース・データベース上で取得プロセスが実行されることを意味します。ダウンストリーム取得とは、ソース・データベース以外のデータベース上で取得プロセスが実行されることを意味します。ダウンストリーム取得を使用する主な理由は、ソース・データベースの負荷を削減して、パフォーマンスを向上させることです。

ソース・データベースに対する変更を取得するデータベースは、取得データベースと呼ばれます。次のいずれかのデータベースを取得データベースとして使用できます。

- ソース・データベース(ローカル取得)

- 宛先データベース(ダウンストリーム取得)

- 第3のデータベース(ダウンストリーム取得)

図1-2に、取得データベースの役割を示します。

図1-2 取得データベース

ソース・データベースまたは第3のデータベースを取得データベースとして使用すると、伝播によって、取得データベースから宛先データベースに変更が送信されます。宛先データベースを取得データベースとして使用すると、取得プロセスと適用プロセスで同じキューが使用されるため、データベース間でこの伝播を行う必要はありません。

ダウンストリーム取得プロセスを構成する場合は、構成するダウンストリーム取得プロセスのタイプを決定する必要があります。次のタイプを使用できます。

- リアルタイム・ダウンストリーム取得プロセスの構成: REDO転送サービスでソース・データベースのログ・ライター・プロセス(LGWR)を使用してREDOデータをダウンストリーム・データベースに送信し、ダウンストリーム・データベースのリモート・ファイル・サーバー・プロセス(RFS)でネットワークを介してREDOデータを受け取り、スタンバイREDOログにREDOデータを格納します。

- アーカイブ・ログ・ダウンストリーム取得プロセスの構成: ソース・データベースのアーカイブREDOログ・ファイルがダウンストリーム・データベースにコピーされ、取得プロセスでそれらのアーカイブREDOログ・ファイル内の変更を取得します。これらのログ・ファイルは、REDO転送サービスを使用して自動的に転送するか、またはFTPなどの方法を使用して手動で転送できます。

アーカイブ・ログ・ダウンストリーム取得と比較すると、リアルタイム・ダウンストリーム取得には、ソース・データベースで行われた変更の取得にかかる時間が短縮されるという利点があります。リアルタイム・ダウンストリーム取得プロセスでは、REDOログ・ファイルがアーカイブされるまで待たずにREDOログ・ファイルから変更を取得できるため、時間が短縮されます。1つのダウンストリーム・データベースで、同じソース・データベースから変更を取得する複数のリアルタイム・ダウンストリーム取得プロセスを構成することはできますが、複数のソース・データベースに対するリアルタイム・ダウンストリーム取得を構成することはできません。

リアルタイム・ダウンストリーム取得と比較して、アーカイブ・ログ・ダウンストリーム取得では、ダウンストリーム・データベースで複数のソース・データベースからのダウンストリーム取得プロセスを使用できるという利点があります。複数のソース・データベースから1つのダウンストリーム・データベースにREDOログ・ファイルをコピーし、それらのREDOログ・ファイル内の変更を取得するように複数のアーカイブ・ログ・ダウンストリーム取得プロセスを構成することができます。

リアルタイム・ダウンストリーム取得プロセスを構成する場合は、「ダウンストリーム取得データベースへのログ・ファイルの転送の構成」および「リアルタイム・ダウンストリーム取得のためのスタンバイREDOログの追加」の手順を完了する必要があります。

REDO転送サービスによってダウンストリーム・データベースに自動的に転送されるアーカイブREDOログ・ファイルを使用するアーカイブ・ログ・ダウンストリーム取得プロセスを構成する場合は、「ダウンストリーム取得データベースへのログ・ファイルの転送の構成」の手順を完了する必要があります。

注意:
これらのプロシージャのいずれかでデータベースのインスタンス化にRMANのDUPLICATEまたはCONVERT DATABASEコマンドを使用する場合、宛先データベースは取得データベースとして使用できません。

関連項目:

- ローカル取得およびダウンストリーム取得の詳細は、『Oracle Streams概要および管理』を参照してください。

- 「1つのデータベースまたは複数のデータベースで変更を許可するかどうかの決定」

- 「Recovery Manager(RMAN)とOracle Streamsのインスタンス化」

1つのデータベースまたは複数のデータベースで変更を許可するかどうかの決定

レプリケーション環境では、レプリケートされた特定のデータベース・オブジェクトに対する変更は1つのデータベースにのみ制限できます。この場合、レプリケートされたデータベース・オブジェクトは、レプリケーション環境内の1つのデータベースで読取り/書込み可能となり、他のデータベースでは読取り専用となります。また、レプリケーション環境では、レプリケートされたデータベース・オブジェクトに対する変更を2つ以上のデータベースで実行できます。

レプリケートされたデータベース・オブジェクトを2つ以上のデータベースで変更できると、競合が発生する可能性があります。競合は、LCR内の古い値と、表内の予期されるデータが一致しないことです。複数データベース上で同じデータに対して同時のデータ操作言語(DML)操作を許可しているOracle Streamsレプリケーション環境では、競合が発生する可能性があります。通常、競合は、レプリケートされた表の同じ行が2つ以上のデータベースでほぼ同時に変更されると発生します。競合が解消されない場合、レプリカ・データベースのデータに一貫性がなくなる可能性があります。

通常、競合が発生する可能性があるのは、次のような一般的なタイプのレプリケーション環境です。

- レプリケートされたデータベース・オブジェクトが両方のデータベースで読取り/書込み可能な2データベース環境での双方向のレプリケーション

- レプリケートされたデータベース・オブジェクトがハブおよび1つ以上のスポークで読取り/書込み可能なハブ・アンド・スポーク・レプリケーション

- レプリケートされたデータベース・オブジェクトが複数のデータベースで読取り/書込み可能なn-wayレプリケーション

これらの一般的なタイプのレプリケーション環境の詳細は、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

Oracle Streamsには、競合を自動的に解消するためのビルトイン競合ハンドラが用意されています。また、ビジネス・ルールに固有のデータ競合を解消するために、独自のカスタム競合ハンドラを作成することもできます。この種の競合ハンドラは、プロシージャDMLハンドラまたはエラー・ハンドラに付属させることができます。

構成するレプリケーション環境で競合が発生する可能性がある場合は、競合ハンドラを作成してそれらの競合を解消するようにします。

関連項目:

- 「ネットワーク接続性とデータベース・リンクの構成」

- 「各ソース・データベースがARCHIVELOGモードであることの確認」

- 第9章「Oracle Streamsの競合解消」

- 「ソース・データベースに対してローカル取得またはダウンストリーム取得を構成するかどうかの決定」

レプリケーション環境に異なるレプリカを含めるかどうかの決定

Oracle Streamsレプリケーションでは、複数データベースで異なるデータベース・オブジェクトの共有がサポートされます。Oracle Streams環境では、異なるデータベースに、異なる構造を持つレプリケートされたデータベース・オブジェクトを含めることができます。Oracle Streamsレプリケーションでは、ルールベースの変換は、ポジティブ・ルール・セットのルールがTRUEと評価される場合に発生する、論理変更レコード(LCR)に対する変更です。LCRに必要な変更を宛先データベースで適用できるように、取得、伝播または適用中のルールベースの変換を構成できます。

たとえば、ソース・データベースの表は、宛先データベースの表と同じデータを持っていても、一部の列名が異なる場合があります。この場合、ルールベースの変換によって、宛先データベースで正常に適用されるように、ソース・データベースからのLCRにある列名を変更できます。

ルールベースの変換には、宣言とカスタムの2つのタイプがあります。宣言ルールベースの変換では、スキーマ名の変更、表名の変更、列の追加、列名の変更、列リストの保持、列の削除などの行LCRの一般的な変換を実行できます。このような変換は、DBMS_STREAMS_ADMパッケージのプロシージャを使用して指定します。Oracle Streamsでは、PL/SQLを起動せずに内部的に宣言変換が実行されます。

カスタム・ルールベースの変換では、変換を実行するユーザー定義PL/SQLファンクションが必要です。Oracle Streamsでは、変換を実行するPL/SQLファンクションが起動されます。カスタム・ルールベースの変換を実行すると、取得LCR、永続LCRまたはユーザー・メッセージを変更できます。たとえば、カスタム・ルールベースの変換で、LCR内にある特定の列のデータ型を変更できます。カスタム・ルールベースの変換は、入力としてANYDATAオブジェクトを取り、ANYDATAオブジェクトを戻すPL/SQLファンクションとして定義する必要があります。

ルールベースの変換は、Oracle Streamsの情報の流れの中で、どの時点でも実行できます。取得プロセスまたは同期取得は、ポジティブ・ルール・セットのルールが変更についてTRUEと評価される場合に、この変更についてルールベースの変換を実行できます。同様に、伝播または適用プロセスは、ポジティブ・ルール・セットのルールがLCRについてTRUEと評価される場合に、このLCRについて、ルールベースの変換を実行できます。

レプリケーション環境にデータベース・オブジェクトの異なるコピーを含める場合は、LCRが宛先データベースで正常に適用されるように、LCRを変更するルールベースの変換を作成します。

注意:
このマニュアルでは、「ルールベースの変換」という用語は、本文が宣言ルールベースの変換とカスタム・ルールベースの変換の両方に該当する場合に使用されます。このマニュアルでは、必要に応じて、2つのタイプのルールベースの変換を区別しています。

関連項目:
ルールベースの変換の詳細は、『Oracle Streams概要および管理』を参照してください。

レプリケーション環境で適用ハンドラを使用するかどうかの決定

適用ハンドラを使用すると、適用プロセスにより、SQL文のコレクションまたはユーザーが作成したPL/SQLプロシージャにメッセージが渡されて処理されます。

次のタイプの適用ハンドラを使用できます。

- 文DMLハンドラでは、SQL文のコレクションを使用して行の論理変更レコード(行LCR)を処理します。

- プロシージャDMLハンドラでは、PL/SQLプロシージャを使用して行LCRを処理します。

- DDLハンドラでは、PL/SQLプロシージャを使用してDDL LCRを処理します。

- メッセージ・ハンドラでは、PL/SQLプロシージャを使用してユーザー・メッセージを処理します。

- プリコミット・ハンドラでは、PL/SQLプロシージャを使用してトランザクションのコミット情報を処理します。

- エラー・ハンドラでは、PL/SQLプロシージャを使用して適用エラーの原因となった行LCRを処理します。

適用ハンドラでは、カスタマイズした方法でメッセージを処理できます。たとえば、LCRの変更が適用された後で、ハンドラで表に対する変更を監査したり、LCRをキューにエンキューしたりできます。その後、再エンキューされたLCRをアプリケーションで処理できます。また、ハンドラを使用して、データベースに対する変更を監査することもできます。

レプリケーション環境でLCRをカスタマイズされた方法で処理する必要がある場合は、目的を達成するために使用する必要がある適用ハンドラを決定してください。次に、カスタム処理を実行するPL/SQLプロシージャを作成して、環境の構成時にそれらのプロシージャを適用ハンドラとして指定します。

関連項目:
『Oracle Streams概要および管理』

DDL変更をメンテナンスするかどうかの決定

通常、レプリケーション環境では、レプリケートされたデータベース・オブジェクトに対するデータ操作言語(DML)変更がメンテナンスされます。DML変更には、INSERT、UPDATE、DELETEおよびLOBの更新操作が含まれます。レプリケーション環境でデータ定義言語(DDL)変更もメンテナンスするかどうかを決定する必要があります。DDL変更が発生する文には、CREATE TABLE、ALTER TABLE、ALTER TABLESPACE、ALTER DATABASEなどがあります。

一部のOracle Streamsレプリケーション環境では、各データベースに同じデータベース・オブジェクトが存在すると想定されます。この場合、Oracle Streamsを使用してDDL変更をメンテナンスすると、共有データベース・オブジェクトを簡単に同期化できます。ただし、一部のOracle Streamsレプリケーション環境では、データベースによって共有データベース・オブジェクトが異なる必要があります。たとえば、2つの異なるデータベースで、ある表の名前または形状が異なっている場合があります。これらの環境では、ルールベースの変換および適用ハンドラを使用して、データベース間で共有可能になるように変更を変換できるため、Oracle Streamsを使用してDDL変更をメンテナンスする必要はありません。この場合、DDL変更が必要な各データベースで手動で変更を加える必要があります。

データ定義言語(DDL)変更をレプリケートする際、制約または索引に対してシステム生成名を許可しないでください。異なるデータベースのオブジェクト名が一致しないため、これらのデータベース・オブジェクトに対する変更は、宛先データベースで失敗する可能性が高いです。また、宛先データベースが異なる場合、STORAGE句によって問題が発生する場合もあります。Oracle Streams環境でDDLをレプリケートしないことを決定する場合、環境内の各データベースですべての表構造の変更を手動で実行する必要があります。

関連項目:

- 「データ定義言語(DDL)変更」

- 「レプリケーション環境に異なるレプリカを含めるかどうかの決定」

- ルールベースの変換の詳細は、『Oracle Streams概要および管理』を参照してください。

レプリケーション環境の構成方法の決定

Oracle Streamsレプリケーション環境を構成する場合、次の3つのオプションを使用できます。

- Streamsレプリケーションの設定ウィザードを実行して、2つのデータベース間のレプリケーションを構成します。このウィザードを複数回実行すると、3つ以上のデータベースを含むレプリケーション環境を構成できます。
このウィザードでは、レプリケーション環境の構成プロセスを実行できますが、このウィザードを使用して構成できるレプリケーション環境のタイプには制限があります。たとえば、このウィザードでは、現在、同期取得は構成できません。

レプリケーション構成ウィザードの詳細は、「Streamsレプリケーションの設定ウィザードを使用したレプリケーションの構成」、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』およびOracle Enterprise Managerのオンライン・ヘルプを参照してください。

- DBMS_STREAMS_ADMが提供されているPL/SQLパッケージの構成プロシージャを実行して、2つのデータベース間のレプリケーションを構成します。このプロシージャを複数回実行すると、3つ以上のデータベースを含むレプリケーション環境を構成できます。
次のプロシージャによって、Oracle Streamsレプリケーションが構成されます。

- MAINTAIN_GLOBALプロシージャ: 2つのデータベース間でデータベース・レベルの変更をレプリケートするOracle Streams環境が構成されます。

- MAINTAIN_SCHEMASプロシージャ: 2つのデータベース間で、指定されたスキーマに対する変更をレプリケートするOracle Streams環境が構成されます。

- MAINTAIN_SIMPLE_TTSプロシージャ: 宛先データベースでソース・データベースからの単一の表領域がクローニングされ、Oracle Streamsを使用して両方のデータベースでこの表領域がメンテナンスされます。

- MAINTAIN_TABLESプロシージャ: 2つのデータベース間で、指定された表に対する変更をレプリケートするOracle Streams環境が構成されます。

- MAINTAIN_TTSプロシージャ: 宛先データベースでソース・データベースからの表領域セットがクローニングされ、Oracle Streamsを使用して両方のデータベースでこれらの表領域がメンテナンスされます。

これらのプロシージャでは、1回のプロシージャ・コールで複数のOracle Streamsコンポーネントが構成され、これらのプロシージャは、Oracle Streamsのベスト・プラクティスに自動的に従います。それらは、一方向、双方向およびハブ・アンド・スポークのレプリケーション環境の構成に適しています。

これらのプロシージャの詳細は、「DBMS_STREAMS_ADMパッケージを使用したレプリケーションの構成」および『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- 各Oracle Streamsコンポーネントを個別に構成します。これらのコンポーネントには、キュー、取得プロセス、同期取得、伝播、適用プロセスなどがあります。このオプションは、n-wayレプリケーション環境を構成する場合またはウィザードや構成プロシージャでは構成できない別のタイプのレプリケーション環境を構成する場合に選択します。
レプリケーション環境の各コンポーネントを個別に構成する方法の詳細は、第3章「Oracle Streamsレプリケーションの柔軟な構成」を参照してください。

構成するレプリケーション環境のタイプによっては、構成オプションが限定される場合があります。「どのタイプのレプリケーション環境を構成するかの決定」を参照してください。

表1-1に、各タイプのレプリケーション環境で使用可能な構成オプションを示します。

表1-1 Oracle Streamsレプリケーションの構成オプション

レプリケーション環境のタイプ

構成オプションと例

2データベース・レプリケーション環境における一方向のレプリケーション

Oracle Enterprise ManagerのStreamsレプリケーションの設定ウィザード。例は次のとおりです。

- 『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』のチュートリアル: ローカル取得プロセスを使用した2データベース・レプリケーションの構成に関する項

- 『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』のチュートリアル(ダウンストリーム取得プロセスを使用した2データベース・レプリケーションの構成)に関する項

提供のDBMS_STREAMS_ADM PL/SQLパッケージの構成プロシージャ。例は次のとおりです。

- 「ローカル取得を使用した2データベース・スキーマ・レプリケーションの構成」

- 「ローカル取得を使用した2データベース表レプリケーションの構成」

- 「宛先でダウンストリーム取得を使用した表領域レプリケーションの構成」

- 「宛先でダウンストリーム取得を使用したスキーマ・レプリケーションの構成」

各Oracle Streamsコンポーネントの個別の構成。例は次のとおりです。

- 『Oracle Streams拡張例』

2データベース・レプリケーション環境における双方向のレプリケーション

Oracle Enterprise ManagerのStreamsレプリケーションの設定ウィザード。例は次のとおりです。

- 『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』のチュートリアル: ローカル取得プロセスを使用した2データベース・レプリケーションの構成に関する項

提供のDBMS_STREAMS_ADM PL/SQLパッケージの構成プロシージャ。例は次のとおりです。

- 「ローカル取得を使用した2データベース・グローバル・レプリケーションの構成」

- 「ローカル取得を使用した2データベース・スキーマ・レプリケーションの構成」

- 「第3のデータベースでダウンストリーム取得を使用したスキーマ・レプリケーションの構成」

各Oracle Streamsコンポーネントの個別の構成。例は次のとおりです。

- 『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』のチュートリアル: 同期取得を使用した2データベース・レプリケーションの構成に関する項

読取り/書込み可能なハブ、および読取り専用スポークを持つハブ・アンド・スポーク・レプリケーション

提供のDBMS_STREAMS_ADM PL/SQLパッケージの構成プロシージャ。

各Oracle Streamsコンポーネントの個別の構成。

読取り/書込み可能なハブ、および1つ以上の読取り/書込み可能なスポークを持つハブ・アンド・スポーク・レプリケーション

Oracle Enterprise ManagerのStreamsレプリケーションの設定ウィザード。例は次のとおりです。

- 『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』のチュートリアル(ローカル取得プロセスを使用したハブ・アンド・スポーク・レプリケーションの構成)に関する項

提供のDBMS_STREAMS_ADM PL/SQLパッケージの構成プロシージャ。例は次のとおりです。

- 「ハブ・アンド・スポーク・レプリケーションを構成する場合の例」

各Oracle Streamsコンポーネントの個別の構成。

複数の読取り/書込み可能なデータベースを持つn-wayレプリケーション

各Oracle Streamsコンポーネントの個別の構成。例は次のとおりです。

- 『Oracle Streams拡張例』

カスタム・レプリケーション環境

各Oracle Streamsコンポーネントの個別の構成。手順については、第3章「Oracle Streamsレプリケーションの柔軟な構成」を参照してください。例は次のとおりです。

- 『Oracle Streams拡張例』

レプリケーション環境を構成する前に、「Oracle Streamsレプリケーションを構成する前に実行するタスク」で説明されているタスクを完了します。

Oracle Streamsレプリケーションを構成する前に実行するタスク

ここでは、Oracle Streamsレプリケーションを構成する前に実行するタスクについて説明します。

- すべてのデータベースでのOracle Streams管理者の構成

- ネットワーク接続性とデータベース・リンクの構成

- 各ソース・データベースがARCHIVELOGモードであることの確認

- Oracle Streamsに関連する初期化パラメータの設定

- Oracle Streamsプールの構成

- サプリメンタル・ロギングの指定

- ダウンストリーム取得データベースへのログ・ファイルの転送の構成

- リアルタイム・ダウンストリーム取得のためのスタンバイREDOログの追加

すべてのデータベースでのOracle Streams管理者の構成

Oracle Streams環境を構成および管理するには、適切な権限を持つ新しいユーザーを作成するか、それらの権限を既存のユーザーに付与します。 SYSまたはSYSTEMユーザーをOracle Streams管理者として使用しないでください。また、Oracle Streams管理者は、デフォルト表領域としてSYSTEM表領域を使用しないでください。

通常、Oracle Streams管理者のユーザー名はstrmadminですが、適切な権限を持つすべてのユーザーがOracle Streams管理者になることができます。この項の例では、Oracle Streams管理者のユーザー名としてstrmadminを使用します。

関連する各Oracle StreamsデータベースでOracle Streams管理者用に個別の表領域を作成します。この表領域には、スキーマ所有のバッファ・キューからオーバーフローしたすべてのメッセージを含む、Oracle Streams管理者スキーマで作成されたすべてのオブジェクトが格納されます。

関連項目:
Oracle Enterprise Managerを使用してOracle Streams管理者を作成する手順については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

Oracle Streamsを使用する環境の各データベースでOracle Streams管理者を構成するには、次の手順を実行します。

1. SQL*Plusで、ユーザーの作成、権限の付与および表領域の作成を行うことができる管理ユーザーとして接続します。これ以降のすべての手順は、この管理ユーザーとして接続したまま実行します。
SQL*Plusでのデータベースへの接続の詳細は、『Oracle Database管理者ガイド』を参照してください。

2. Oracle Streams管理者用の表領域を作成するか、既存の表領域を使用します。たとえば、次の文では、Oracle Streams管理者用の新規表領域が作成されます。

CREATE TABLESPACE streams_tbs DATAFILE '/usr/oracle/dbs/streams_tbs.dbf'
SIZE 25M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED;

3. Oracle Streams管理者の役割を果たす新規ユーザーを作成するか、既存のユーザーを使用します。たとえば、ユーザーstrmadminを作成し、このユーザーがstreams_tbs表領域を使用するように指定するには、次の文を実行します。

CREATE USER strmadmin IDENTIFIED BY password
DEFAULT TABLESPACE streams_tbs
QUOTA UNLIMITED ON streams_tbs;

注意:
管理ユーザー用の適切なパスワードを入力してください。

関連項目:
パスワード選択のガイドラインについては、『Oracle Databaseセキュリティ・ガイド』を参照してください。

4. 次のようにして、Oracle Streams管理者にDBAロールを付与します。

GRANT DBA TO strmadmin;

注意:
取得プロセス、同期取得および適用プロセスを作成または変更するユーザーには、DBAロールが必要です。ユーザーがこれらのタスクを実行する必要がない場合は、ユーザーのDBAロールを取り消すことができます。

5. DBMS_STREAMS_AUTHパッケージのGRANT_ADMIN_PRIVILEGEプロシージャを実行します。

ユーザー作成サブプログラム内のパッケージのサブプログラムを実行する場合、ユーザーには、パッケージに対する明示的なEXECUTE権限が必要です。また、ユーザー作成サブプログラム内のビューを問い合せる場合は、そのデータ・ディクショナリ・ビューに対する明示的なSELECT権限が必要です。これらの権限は、ロールでは付与できません。これらの権限をOracle Streams管理者に付与するには、GRANT_ADMIN_PRIVILEGEプロシージャを実行するか、または直接付与します。

GRANT_ADMIN_PRIVILEGEプロシージャでは、パラメータ設定に応じて、Oracle Streams管理者にこれらの権限が直接付与されるか、またはこれらの権限を付与するために編集して実行できるスクリプトが生成されます。

関連項目:
このプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

GRANT_ADMIN_PRIVILEGEプロシージャを使用して権限を直接付与する場合:

次のプロシージャを実行します。

BEGIN
DBMS_STREAMS_AUTH.GRANT_ADMIN_PRIVILEGE(
grantee          => 'strmadmin',
grant_privileges => TRUE);
END;
/

GRANT_ADMIN_PRIVILEGEプロシージャを使用してスクリプトを生成する場合:

手順は次のとおりです。

1. SQL文CREATE DIRECTORYを使用して、スクリプトの生成先のディレクトリにディレクトリ・オブジェクトを作成します。ディレクトリ・オブジェクトは、ディレクトリの別名に類似しています。たとえば、コンピュータ・システムの/usr/adminディレクトリにディレクトリ・オブジェクトstrms_dirを作成するには、次のプロシージャを実行します。

CREATE DIRECTORY strms_dir AS '/usr/admin';

2. GRANT_ADMIN_PRIVILEGEプロシージャを実行して、スクリプトgrant_strms_privs.sqlを生成し、そのスクリプトをコンピュータ・システムの/usr/adminディレクトリに配置します。

BEGIN
DBMS_STREAMS_AUTH.GRANT_ADMIN_PRIVILEGE(
grantee          => 'strmadmin',
grant_privileges => FALSE,
file_name        => 'grant_strms_privs.sql',
directory_name   => 'strms_dir');
END;
/

プロシージャによって権限が直接付与されないようにgrant_privilegesパラメータがFALSEに設定されていることに注意してください。また、手順aで作成したディレクトリ・オブジェクトがdirectory_nameパラメータに指定されていることを確認してください。

3. 生成されたスクリプトを必要に応じて編集し、変更を保存します。

4. SQL*Plusで次のスクリプトを実行します。

SET ECHO ON
SPOOL grant_strms_privs.out
@/usr/admin/grant_strms_privs.sql
SPOOL OFF

5. スプール・ファイルをチェックして、すべての付与が正常に実行されていることを確認します。エラーが存在する場合は、スクリプトを編集してエラーを修正してから再実行します。

6. 必要に応じて、次の追加の権限を付与します。

- Oracle Enterprise Managerを使用してOracle Streamsコンポーネント含むデータベースを管理する場合は、Oracle Streams管理者がDatabase Control管理者となるように構成します。これにより、Oracle Enterprise Managerジョブの実行に必要な権限など、Oracle Enterprise Managerで必要な追加の権限が付与されます。手順については、『Oracle Database 2日でデータベース管理者』を参照してください。

- ローカル・データベースでアクションを実行する権限をリモートのOracle Streams管理者に付与します。これらの権限を付与するには、DBMS_STREAMS_AUTHパッケージのGRANT_REMOTE_ADMIN_ACCESSプロシージャを使用します。この権限は、リモートのOracle Streams管理者が、ローカルのOracle Streams管理者に接続して管理アクションを実行するデータベース・リンクを使用する場合に付与します。具体的には、次のいずれかの条件に該当する場合にこれらの権限を付与します。

- ローカル・ソース・データベースで発生した変更を取得するリモート・ダウンストリーム・データベースでダウンストリーム取得プロセスを構成し、そのダウンストリーム取得プロセスでデータベース・リンクを使用してソース・データベースで管理アクションを実行する。

- ローカル・データベースで適用プロセスを構成し、リモートのOracle Streams管理者を使用してローカル・データベースのレプリケートされたデータベース・オブジェクトにインスタンス化SCN値を設定する。

- 適用プロセスに適用ユーザーが指定されていない場合は、他のユーザーが所有している適用オブジェクトに対してDML変更およびDDL変更を実行するために必要な権限をOracle Streams管理者に付与します。適用ユーザーが指定されている場合、適用ユーザーにはこれらの権限が必要です。これらの権限は、直接またはロールを介して付与できます。

- 適用プロセスに適用ユーザーが指定されていない場合は、Oracle Streams適用プロセスによって実行され、他のユーザーが所有しているPL/SQLサブプログラムに対するEXECUTE権限をOracle Streams管理者に付与します。これらのサブプログラムは、適用ハンドラまたはエラー・ハンドラで使用できます。適用ユーザーが指定されている場合、適用ユーザーにはこれらの権限が必要です。これらの権限は、直接付与する必要があります。ロールを介して付与することはできません。

- Oracle Streamsの取得プロセス、同期取得、伝播、適用プロセスまたはメッセージ・クライアントによって使用されるルールにカスタム・ルールベースの変換で指定され、他のユーザーが所有しているPL/SQLファンクションに対するEXECUTE権限をOracle Streams管理者に付与します。取得プロセスまたは同期取得で取得ユーザーが指定されている場合、その取得ユーザーにはこれらの権限が必要です。適用プロセスで適用ユーザーが指定されている場合、その適用ユーザーにはこれらの権限が必要です。これらの権限は、直接付与する必要があります。ロールを介して付与することはできません。

- 必要に応じて、データベース・オブジェクトを変更する権限をOracle Streams管理者に付与します。たとえば、Oracle Streams管理者が別のスキーマ内の表にサプリメンタル・ログ・グループを作成する必要がある場合、Oracle Streams管理者にはその表を変更する権限が必要です。これらの権限は、直接またはロールを介して付与できます。

- Oracle Streams管理者がOracle Streamsの取得プロセス、同期取得、伝播、適用プロセスまたはメッセージ・クライアントによって使用されるキューを所有しておらず、キューの作成時にそのキューのキュー・ユーザーとして指定されていない場合、Oracle Streams管理者がメッセージをキューにエンキューしたり、キューからデキューできるようにするには、Oracle Streams管理者をそのキューの保護キュー・ユーザーとして構成する必要があります。また、Oracle Streams管理者には、そのキューに対するENQUEUE権限またはDEQUEUE権限(あるいはその両方)が必要な場合があります。キューを管理する方法の詳細は、『Oracle Streams概要および管理』を参照してください。

- Oracle Streams管理者がアクセスする必要がある場合がある任意のオブジェクト・タイプに対するEXECUTE権限をOracle Streams管理者に付与します。これらの権限は、直接またはロールを介して付与できます。

- Oracle Streams管理者が、Oracle Streamsのインスタンス化中にデータ・ポンプを使用してデータベース・オブジェクトに対するエクスポート操作とインポート操作を実行する場合は、Oracle Streams管理者にEXP_FULL_DATABASEおよびIMP_FULL_DATABASEのロールを付与します。

- Oracle Database Vaultがインストールされている場合は、次のアクションを実行するユーザーにBECOME USERシステム権限が付与されている必要があります。

- 取得プロセスの作成または変更

- 適用プロセスの作成または変更

Oracle Database Vaultがインストールされていない場合は、これらのアクションを実行するユーザーにBECOME USERシステム権限を付与する必要はありません。必要に応じて、これらのいずれかのアクションの完了後に、ユーザーのBECOME USERシステム権限を取り消すことができます。

7. Oracle Streamsを使用する環境の各データベースで前述のすべての手順を繰り返します。

関連項目:

- 「取得ユーザーへの必要な権限の付与」

- 「適用ユーザーへの必要な権限の付与」

ネットワーク接続性とデータベース・リンクの構成

Oracle Streamsを使用してデータベース間で情報を共有する場合は、これらのデータベース間にネットワーク接続とデータベース・リンクを構成します。

- Oracle Databaseの場合、データベースで相互に通信できるようにネットワークとOracle Netを構成します。

- Oracle以外のデータベースの場合、Oracle DatabaseとOracle以外のデータベースで通信できるようにOracle Database Gatewayを構成します。

- あるデータベースのソース・キューから別のデータベースの宛先キューにメッセージを伝播する場合は、ソース・キューを含むデータベースと宛先キューを含むデータベースの間にプライベート・データベース・リンクを作成します。各データベース・リンクでは、データベース間でメッセージを伝播するユーザー用にCONNECT TO句を使用する必要があります。

ソース・データベースから宛先データベースへのデータベース・リンクは常に必要です。データベース・リンクの名前は、宛先データベースのグローバル名と一致している必要があります。

次のいずれかの場合、宛先データベースからソース・データベースへのデータベース・リンクが必要です。

- Oracle Streamsレプリケーション環境を双方向にする場合。

- インスタンス化中にデータ・ポンプでのネットワーク・インポートを実行する場合。

- 宛先データベースを、ソース・データベースに対する変更のダウンストリーム取得の取得データベースに使用する場合。

- データベースのインスタンス化にRMANのDUPLICATEまたはCONVERT DATABASEコマンドを使用する場合。
instantiation_scnパラメータをNULL以外の値に設定してPOST_INSTANTIATION_SETUPプロシージャを実行すると、宛先データベースでDBMS_APPLY_ADMパッケージのSET_GLOBAL_INSTANTIATION_SCNプロシージャが実行されるため、このデータベース・リンクが必要になります。SET_GLOBAL_INSTANTIATION_SCNプロシージャにはこのデータベース・リンクが必要です。このデータベース・リンクは、RMANによるインスタンス化の実行後、POST_INSTANTIATION_SETUPプロシージャを実行する前に作成する必要があります。

いずれの場合においても、データベース・リンクの名前は、ソース・データベースのグローバル名と一致している必要があります。

第3のデータベースをソース・データベースに対する変更のダウンストリーム取得の取得データベースに使用する場合は、次のデータベース・リンクも必要です。

- 第3のデータベースからソース・データベースへのデータベース・リンク。データベース・リンクの名前は、ソース・データベースのグローバル名と一致している必要があります。

- 第3のデータベースから宛先データベースへのデータベース・リンク。データベース・リンクの名前は、宛先データベースのグローバル名と一致している必要があります。

各データベース・リンクは、Oracle Streams管理者のスキーマに作成する必要があります。たとえば、ソース・データベースのグローバル名がdbs1.example.com、宛先データベースのグローバル名がdbs2.example.com、各データベースのOracle Streams管理者がstrmadminの場合、次の文を実行すると、ソース・データベースから宛先データベースへのデータベース・リンクが作成されます。

CONNECT strmadmin@dbs1.example.com
Enter password: password

CREATE DATABASE LINK dbs2.example.com CONNECT TO strmadmin
IDENTIFIED BY password USING 'dbs2.example.com';

宛先データベースからソース・データベースへのデータベース・リンクが必要な場合、次の文を実行すると、このデータベース・リンクが作成されます。

CONNECT strmadmin@dbs2.example.com
Enter password: password

CREATE DATABASE LINK dbs1.example.com CONNECT TO strmadmin
IDENTIFIED BY password USING 'dbs1.example.com';

第3のデータベースを取得データベースに使用する場合、第3のデータベースからソース・データベースおよび宛先データベースへのデータベース・リンクが必要です。たとえば、第3のデータベースがdbs3.example.comの場合、次の文を実行すると、第3のデータベースからソース・データベースと宛先データベースへのデータベース・リンクが作成されます。

CONNECT strmadmin@dbs3.example.com
Enter password: password

CREATE DATABASE LINK dbs1.example.com CONNECT TO strmadmin
IDENTIFIED BY password USING 'dbs1.example.com';

CREATE DATABASE LINK dbs2.example.com CONNECT TO strmadmin
IDENTIFIED BY password USING 'dbs2.example.com';

RMANを使用してデータベースのインスタンス化を実行した場合、インスタンス化中にソース・データベースのデータベース・リンクが宛先データベースにコピーされます。このコピーされたデータベース・リンクは、宛先データベースで削除する必要があります。この場合、レプリケーションが双方向で、宛先データベースからソース・データベースへのデータベース・リンクが必要な場合、インスタンス化後にこのデータベース・リンクを作成する必要があります。

関連項目:

- 『Oracle Database 2日でデータベース管理者』

- Oracle Enterprise Managerを使用してデータベース・リンクを作成する手順については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

- データベース・リンクの詳細は、『Oracle Database管理者ガイド』を参照してください。

- Oracle DatabaseとOracle以外のデータベースの間の通信の詳細は、『Oracle Database Heterogeneous Connectivityユーザーズ・ガイド』を参照してください。

- 「1つのデータベースまたは複数のデータベースで変更を許可するかどうかの決定」

- 「ソース・データベースに対してローカル取得またはダウンストリーム取得を構成するかどうかの決定」

各ソース・データベースがARCHIVELOGモードであることの確認

Oracle Streamsレプリケーション環境では、取得プロセスによって取得される変更を生成する各ソース・データベースはARCHIVELOGモードである必要があります。ダウンストリーム取得プロセスでは、リアルタイム・ダウンストリーム取得プロセスを構成する場合、ダウンストリーム・データベースもARCHIVELOGモードで実行する必要があります。ダウンストリーム・データベースでアーカイブ・ログ・ダウンストリーム取得プロセスのみを実行する場合は、ダウンストリーム・データベースをARCHIVELOGモードで実行する必要はありません。

Oracle Real Application Clusters(Oracle RAC)環境でOracle Streamsを構成している場合は、すべてのインスタンスからのすべてのスレッドのアーカイブ・ログ・ファイルが、取得プロセスを実行するインスタンスから使用できる必要があります。この要件は、ローカルおよびダウンストリーム取得プロセスの両方に関連します。

注意:
同期取得では、ARCHIVELOGモードは不要です。

関連項目:

- ARCHIVELOGモードでデータベースを実行する手順については、『Oracle Database管理者ガイド』を参照してください。

- 「1つのデータベースまたは複数のデータベースで変更を許可するかどうかの決定」

- 「ソース・データベースに対してローカル取得またはダウンストリーム取得を構成するかどうかの決定」

Oracle Streamsに関連する初期化パラメータの設定

Oracle Streams環境の構成、操作、信頼性およびパフォーマンスには、いくつかの初期化パラメータが重要となります。使用するOracle Streams環境に応じてこれらのパラメータを適切に設定します。

表1-2に、Oracle Streamsに関連する初期化パラメータを示します。この表には、各パラメータが変更可能かどうかが示されています。変更可能な初期化パラメータは、インスタンスの実行中にALTER SYSTEM文を使用して変更できます。変更可能なパラメータの中には、ALTER SESSION文を使用して単一のセッションに対して変更できるものもあります。

表1-2 Oracle Streamsに関連する初期化パラメータ

パラメータ

値

説明

COMPATIBLE

デフォルト: 11.2.0

範囲: 10.0.0からデフォルト・リリースの間

変更の可否: 不可

このパラメータでは、Oracleサーバーとの互換性を保つ必要があるリリースを指定します。互換レベルが異なるOracleサーバーと相互運用できます。

Oracle Database 11gリリース2で導入されたOracle Streamsの新機能を使用するには、このパラメータを11.2.0以上に設定する必要があります。

GLOBAL_NAMES

デフォルト: FALSE

範囲: TRUEまたはFALSE

変更の可否: 可

データベース・リンクの名前を接続先のデータベースと同じ名前にする必要があるかどうかを指定します。

Oracle Streamsを使用してデータベース間で情報を共有するには、Oracle Streams環境の各データベースで、このパラメータをTRUEに設定します。

LOG_ARCHIVE_CONFIG

デフォルト: 'SEND, RECEIVE, NODG_CONFIG'

範囲: 次の値

- SEND

- NOSEND

- RECEIVE

- NORECEIVE

- DG_CONFIG

- NODG_CONFIG

変更の可否: 可

リモートの接続先へのREDOログの送信およびリモートのREDOログの受信を有効または無効にし、Data Guard構成の各データベースに一意のデータベース名(DB_UNIQUE_NAME)を指定します。

ダウンストリーム取得を使用し、REDO転送サービスによってREDOデータをダウンストリーム・データベースにコピーするには、DG_CONFIG属性を使用してソース・データベースとダウンストリーム・データベースのDB_UNIQUE_NAMEを指定します。このパラメータは、ソース・データベースとダウンストリーム・データベースの両方で設定する必要があります。

LOG_ARCHIVE_DEST_n

デフォルト: なし

範囲: なし

変更の可否: 可

ログ・アーカイブの宛先を31個まで定義します。ここで、nは、1、2、3、...31です。

ダウンストリーム取得を使用し、REDO転送サービスによってREDOデータをダウンストリーム・データベースにコピーするには、ダウンストリーム取得プロセスを実行するサイトでログのアーカイブ先を1つ以上設定する必要があります。

LOG_ARCHIVE_DEST_STATE_n

デフォルト: enable

範囲: 次のいずれか

- alternate

- defer

- enable

変更の可否: 可

対応するアーカイブ先の可用性の状態を指定します。パラメータの接尾辞(1から31)では、対応するLOG_ARCHIVE_DEST_n宛先パラメータのいずれかを指定します。

ダウンストリーム取得を使用し、REDO転送サービスによってREDOデータをダウンストリーム・データベースにコピーするには、ダウンストリーム・データベースのLOG_ARCHIVE_DEST_nアーカイブ先に対応するアーカイブ先をenableに設定してください。

LOG_BUFFER

デフォルト: 構成に応じて5MBから32MB

範囲: オペレーティング・システム依存の値

変更の可否: 不可

REDOエントリをREDOログ・ファイルにバッファするときに使用されるメモリー量(バイト単位)を指定します。REDOログ・エントリには、データベース・ブロック・バッファに加えられた変更のレコードが含まれます。

データベースでOracle Streams取得プロセスが実行されている場合は、このパラメータを適切に設定して、取得プロセスがハード・ディスクではなくREDOログ・バッファからREDOログ・レコードを読み取るようにしてください。

MEMORY_MAX_TARGET

デフォルト: 0

範囲: 0(ゼロ)からOracle Databaseで使用可能な物理メモリー・サイズの間

変更の可否: 不可

システム全体でOracle Database用に使用可能な最大メモリーを指定します。

MEMORY_TARGETパラメータが0(ゼロ)以外の値に設定されており、Oracle Databaseの最大メモリー使用量を指定する必要がある場合は、このパラメータを0以外の大きい値に設定します。

関連項目: 「Oracle Streamsプールの構成」

MEMORY_TARGET

デフォルト: 0

範囲: 152MBからMEMORY_MAX_TARGET設定の間

変更の可否: 可

システム全体でOracle Database用に使用可能なメモリーを指定します。

MEMORY_TARGETを0以外の大きい値に設定して、Oracle Databaseのメモリー使用量の自動チューニングを有効にすることをお薦めします(このパラメータがプラットフォームでサポートされている場合)。

関連項目: 「Oracle Streamsプールの構成」

OPEN_LINKS

デフォルト: 4

範囲: 0(ゼロ)から255の間

変更の可否: 不可

1つのセッションでリモート・データベースに対して同時にオープンできる接続の最大数を指定します。これらの接続には、データベース・リンクに加え、外部プロシージャやカートリッジが含まれ、それぞれ別々のプロセスが使用されます。

Oracle Streams環境では、このパラメータをデフォルト値の4以上に設定してください。

PROCESSES

デフォルト: 100

範囲: 6からオペレーティング・システム依存の値の間

変更の可否: 不可

Oracleに同時に接続できるオペレーティング・システム・ユーザー・プロセスの最大数を指定します。

このパラメータの値で、ロックやスレーブ・プロセスなどのすべてのバックグラウンド・プロセスを使用できるようにしてください。Oracle Streamsでは、取得プロセス、適用プロセス、XStreamインバウンド・サーバーおよびXStreamアウトバウンド・サーバーでバックグラウンド・プロセスが使用されます。伝播では、取得と適用の複合構成でバックグラウンド・プロセスが使用されます。取得と適用の複合を使用しない構成の伝播では、Oracle Schedulerスレーブ・プロセスが使用されます。

SESSIONS

デフォルト: 次の式から導出された値

(1.5 * PROCESSES) + 22

範囲: 1から2^31の間

変更の可否: 不可

システムで作成できるセッションの最大数を指定します。

データベースで1つ以上の取得プロセス、適用プロセスを、XStreamアウトバウンド・サーバーまたはXStreamインバウンド・サーバーを実行するには、このパラメータのサイズを大きくする必要がある場合があります。データベースのバックグラウンド・プロセスごとにセッションが必要になります。

SGA_MAX_SIZE

デフォルト: 起動時のSGAの初期サイズ

範囲: 0(ゼロ)からオペレーティング・システム依存の値の間

変更の可否: 不可

データベース・インスタンスの存続期間に対するシステム・グローバル領域(SGA)の最大サイズを指定します。

SGA_TARGETパラメータが0(ゼロ)以外の値に設定されており、SGAサイズを指定する必要がある場合は、このパラメータを0(ゼロ)以外の大きい値に設定します。

関連項目: 「Oracle Streamsプールの構成」

SGA_TARGET

デフォルト: 0(SGAの自動チューニングが無効になっている)

範囲: 64MBからオペレーティング・システム依存の値

変更の可否: 可

すべてのシステム・グローバル領域(SGA)コンポーネントの合計サイズを指定します。

MEMORY_MAX_TARGETおよびMEMORY_TARGETが0(ゼロ)に設定されている場合は、SGA_TARGETを0以外の大きい値に設定して、SGAメモリーの自動チューニングを有効にすることをお薦めします。

このパラメータを0(ゼロ)以外の値に設定すると、Oracle Streamsプールのサイズは自動共有メモリー管理で管理されます。

関連項目: 「Oracle Streamsプールの構成」

SHARED_POOL_SIZE

デフォルト:

SGA_TARGETが0(ゼロ)以外の値に設定されている場合: パラメータを指定しないと、デフォルト値は0(ゼロ)になります(Oracle Databaseで内部的に決定されます)。パラメータを指定すると、ユーザー指定の値が共有メモリー・プールの最小値を示します。

32ビット・プラットフォームでSGA_TARGETが設定されていない場合は、64MBになります(最も近いグラニュル・サイズに切り上げられます)。64ビット・プラットフォームでSGA_TARGETが設定されていない場合は、128MBになります(最も近いグラニュル・サイズに切り上げられます)。

範囲: グラニュル・サイズからオペレーティング・システム依存の値の間

変更の可否: 可

共有プールのサイズ(バイト単位)を指定します。共有プールには、共有カーソル、ストアド・プロシージャおよび制御構造などの構造が含まれます。

MEMORY_MAX_TARGET、MEMORY_TARGET、SGA_TARGETおよびSTREAMS_POOL_SIZE初期化パラメータが0(ゼロ)に設定されている場合、Oracle Streamsでは共有プールの10%と同等の量がバッファ・キャッシュからOracle Streamsプールに転送されます。

関連項目: 「Oracle Streamsプールの構成」

STREAMS_POOL_SIZE

デフォルト: 0

範囲: 0(ゼロ)からオペレーティング・システム依存の制限値の間

変更の可否: 可

Oracle Streamsプールのサイズ(バイト単位)を指定します。Oracle Streamsプールには、バッファ・キュー・メッセージが含まれています。また、Oracle Streamsプールは、パラレル取得時およびパラレル適用時の内部通信にも使用されます。

MEMORY_TARGETまたはMEMORY_MAX_TARGET初期化パラメータが0(ゼロ)以外の値に設定されている場合、Oracle Streamsプールのサイズは自動メモリー管理によって設定され、STREAMS_POOL_SIZEで最小サイズが指定されます。

SGA_TARGET初期化パラメータが0(ゼロ)以外の値に設定されている場合、Oracle Streamsプールのサイズは自動共有メモリー管理によって設定され、STREAMS_POOL_SIZEで最小サイズが指定されます。

このパラメータは変更可能です。インスタンスの実行中にこのパラメータを0(ゼロ)まで小さくすると、Oracle Streamsのプロセスとジョブが実行されない場合があります。

Oracle Streamsコンポーネントに対応するための十分なメモリーがあることを確認してください。最低要件は次のとおりです。

- 各取得プロセスの並列性を確保するために15MB。

- バッファ・キューごとに250MB以上。バッファ・キューは、バッファ・メッセージの格納場所です。

- 各適用プロセスの並列性を確保するために1MB。

- XStreamアウトバウンド・サーバーごとに1MB。

- 各XStreamインバウンド・サーバーの並列性を確保するために1MB。

たとえば、取得プロセスの並列性を3に設定する場合、その取得プロセスには少なくとも45MB必要です。データベースに2つのバッファ・キューが存在する場合、それらのバッファ・キューには20MB以上が必要です。適用プロセスの並列性を4に設定する場合、その適用プロセスには少なくとも4MB必要です。

V$STREAMS_POOL_ADVICE動的パフォーマンス・ビューを使用して、このパラメータの適切な設定を判断できます。

関連項目: 「Oracle Streamsプールの構成」

TIMED_STATISTICS

デフォルト:

STATISTICS_LEVELがTYPICALまたはALLに設定されている場合はTRUEです。

STATISTICS_LEVELがBASICに設定されている場合はFALSEです。

STATISTICS_LEVELのデフォルト値はTYPICALです。

範囲: TRUEまたはFALSE

変更の可否: 可

時間に関連する統計を収集するかどうかを指定します。

Oracle Streamsに関連する動的パフォーマンス・ビューで経過時間の統計を収集するには、このパラメータをTRUEに設定します。経過時間の統計を含むビューには、V$STREAMS_CAPTURE、V$STREAMS_APPLY_COORDINATOR、V$STREAMS_APPLY_READER、V$STREAMS_APPLY_SERVERなどがあります。

UNDO_RETENTION

デフォルト: 900

範囲: 0から2^31 - 1

変更の可否: 可

コミットされたUNDO情報をデータベース内に保存する期間(秒単位)を指定します。

1つ以上の取得プロセスを実行しているデータベースでは、このパラメータを設定して適切なUNDO保存期間を指定してください。

1つ以上の取得プロセスを実行していて、適切な設定がわからない場合は、このパラメータを3600以上に設定してください。「スナップショットが古すぎます」というエラーが発生した場合は、これらのエラーが発生しなくなるまで、このパラメータの設定を大きくます。また、UNDO表領域にUNDO_RETENTION設定を適用するための十分な領域があることを確認してください。

関連項目:

- 初期化パラメータの設定方法の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

- これらの初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

- LOG_ARCHIVE_DEST_nパラメータの詳細は、『Oracle Data Guard概要および管理』を参照してください。

- UNDO_RETENTIONパラメータの詳細は、『Oracle Database管理者ガイド』を参照してください。

- Oracle Database XStreamについてのマニュアル

Oracle Streamsプールの構成

Oracle Streamsプールは、Oracle Streamsで使用されるシステム・グローバル領域(SGA)のメモリーの一部です。Oracle Streamsプールではメモリーにバッファ・キュー・メッセージが格納され、取得プロセス、適用プロセス、XStreamアウトバウンド・サーバーおよびXStreamインバウンド・サーバー用のメモリーが用意されています。Oracle Streamsプールは、取得プロセスで取得されたLCRを常に格納し、アプリケーションによってバッファ・キューにエンキューされたLCRとメッセージを格納します。

Oracle Streamsプールは、データベースで次のいずれかのアクションが初めて発生した場合に初期化されます。

- メッセージがバッファ・キューにエンキューされた場合。
Oracle Streamsコンポーネントによって、バッファ・キュー内のメッセージが操作されます。これらのコンポーネントには、取得プロセス、伝播、適用プロセス、XStreamアウトバウンド・サーバーおよびXStreamインバウンド・サーバーが含まれます。また、データ・ポンプ・エクスポート/インポート操作ではバッファ・キューが使用されるため、これらの操作が行われるとOracle Streamsプールが初期化されます。

- Oracle Real Application Clusters(Oracle RAC)を使用していない構成で、永続キューからメッセージがデキューされた場合。
永続キューからのデキュー操作を最適化するために、Oracle Streamsプールが使用されます。Oracle RAC構成では、永続キューからのデキュー操作の最適化にOracle Streamsプールは使用されません。

- 取得プロセスが起動された場合。

- 伝播が作成された場合。

- 適用プロセスが起動された場合。

- XStreamアウトバウンド・サーバーが起動された場合。

- XStreamインバウンド・サーバーが起動された場合。

Oracle Streamsプールのサイズは、次のいずれかの方法で決定されます。

- 自動メモリー管理を使用したOracle Streamsプールのサイズの設定

- 自動共有メモリー管理を使用したOracle Streamsプールのサイズの設定

- Oracle Streamsプール・サイズの手動による設定

- Oracle Streamsプール・サイズのデフォルト設定の使用

注意:
Oracle Streamsプールを初期化できない場合、ORA-00832エラーが戻されます。この場合は、まず、SGAにOracle Streamsプール用の十分な領域があることを確認してください。必要に応じて、SGA_MAX_SIZE初期化パラメータをリセットしてSGAサイズを増やしてください。次に、MEMORY_TARGET、MEMORY_MAX_TARGET、SGA_TARGETおよびSTREAMS_POOL_SIZE初期化パラメータの1つ以上を設定してください。

関連項目:

- 「Oracle Streamsに関連する初期化パラメータの設定」

- 『Oracle Streams概要および管理』

- Oracle Database XStreamについてのマニュアル

自動メモリー管理を使用したOracle Streamsプールのサイズの設定

MEMORY_TARGETまたはMEMORY_MAX_TARGET初期化パラメータを0(ゼロ)以外の値に設定した場合、Oracle Streamsプールのサイズは自動メモリー管理機能によって自動的に管理されます。自動メモリー管理を使用する場合でも、次の初期化パラメータは引き続き設定できます。

- SGA_TARGET初期化パラメータも0(ゼロ)以外の値に設定すると、自動メモリー管理でその値がシステム・グローバル領域(SGA)の最小値として使用されます。

- STREAMS_POOL_SIZE初期化パラメータも0(ゼロ)以外の値に設定すると、自動メモリー管理でその値がOracle Streamsプールの最小値として使用されます。

自動メモリー管理によってOracle Streamsプールに割り当てられている現行のメモリーは、V$MEMORY_DYNAMIC_COMPONENTSビューを問い合せることによって表示できます。

注意:
現在、MEMORY_TARGETおよびMEMORY_MAX_TARGET初期化パラメータは一部のプラットフォームではサポートされていません。

関連項目:

- 『Oracle Database管理者ガイド』

- 『Oracle Databaseリファレンス』

自動共有メモリー管理を使用したOracle Streamsプールのサイズの設定

次の条件に該当する場合、Oracle Streamsプールのサイズは自動共有メモリー管理機能によって自動的に管理されます。

- MEMORY_TARGETおよびMEMORY_MAX_TARGET初期化パラメータの両方が0(ゼロ)に設定されている。

- SGA_TARGET初期化パラメータが0(ゼロ)以外の値に設定されている。

自動共有メモリー管理を使用している場合に、STREAMS_POOL_SIZE初期化パラメータも0(ゼロ)以外の値に設定すると、自動共有メモリー管理でその値がOracle Streamsプールの最小値として使用されます。環境が適切に動作するためにOracle Streamsプールに最小メモリー量が必要な場合は、最小サイズを設定できます。自動共有メモリー管理によってOracle Streamsプールに割り当てられている現行のメモリーは、V$SGA_DYNAMIC_COMPONENTSビューを問い合せることによって表示できます。

関連項目:

- 『Oracle Database管理者ガイド』

- 『Oracle Databaseリファレンス』

Oracle Streamsプール・サイズの手動による設定

Oracle Streamsプールのサイズは、次の条件に該当する場合にSTREAMS_POOL_SIZEパラメータで指定する値(バイト単位)です。

- MEMORY_TARGET、MEMORY_MAX_TARGETおよびSGA_TARGET初期化パラメータがすべて0(ゼロ)に設定されている。

- STREAMS_POOL_SIZE初期化パラメータが0(ゼロ)以外の値に設定されている。

Oracle Streamsプールのサイズを手動で設定する場合は、V$STREAMS_POOL_ADVICE動的パフォーマンス・ビューを使用して、STREAMS_POOL_SIZE初期化パラメータの適切な設定を確認できます。

関連項目:
『Oracle Streams概要および管理』

Oracle Streamsプール・サイズのデフォルト設定の使用

MEMORY_TARGET、MEMORY_MAX_TARGET、SGA_TARGETおよびSTREAMS_POOL_SIZEパラメータがすべて0(ゼロ)に設定されている場合、Oracle Streamsプールのサイズはデフォルトで設定されます。Oracle Streamsプールのサイズがデフォルトで設定されている場合、データベースでのOracle Streamsの初回使用時に、共有プールの10%と同等のメモリー量がバッファ・キャッシュからOracle Streamsプールに転送されます。バッファ・キャッシュはDB_CACHE_SIZE初期化パラメータによって設定され、共有プール・サイズはSHARED_POOL_SIZE初期化パラメータによって設定されます。

たとえば、Oracle Streamsを初めて使用する前に、データベースの次の構成について検討します。

- DB_CACHE_SIZEが100MBに設定されている。

- SHARED_POOL_SIZEが80MBに設定されている。

- MEMORY_TARGET、MEMORY_MAX_TARGET、SGA_TARGETおよびSTREAMS_POOL_SIZEがすべて0(ゼロ)に設定されている。

この構成を前提とした場合、Oracle Streamsの初回使用後に割り当てられるメモリー量は次のようになります。

- バッファ・キャッシュには92MBが割り当てられます。

- 共有プールには80MBが割り当てられます。

- Oracle Streamsプールには8MBが割り当てられます。

関連項目:
STREAMS_POOL_SIZE初期化パラメータの詳細は、「Oracle Streamsに関連する初期化パラメータの設定」を参照してください。

サプリメンタル・ロギングの指定

取得プロセスを使用して変更を取得する場合は、列に対する変更が宛先データベースで正常に適用されるように、ソース・データベースで特定の列にサプリメンタル・ロギングを指定する必要があります。サプリメンタル・ロギングによって、これらの列に関する追加の情報がREDOログに記録されます。この追加の情報は、取得プロセスによって取得されて論理変更レコード(LCR)に含められ、適用プロセスによって変更を適切に適用するために必要とされる場合があります。

この項の内容は次のとおりです。

- Oracle Streamsレプリケーション環境内の必要なサプリメンタル・ロギング

- 無条件ログ・グループを使用した表サプリメンタル・ロギングの指定

- 条件付きログ・グループを使用した表サプリメンタル・ロギングの指定

- サプリメンタル・ログ・グループの削除

- キー列のデータベース・サプリメンタル・ロギングの指定

- キー列のデータベース・サプリメンタル・ロギングの削除

- サプリメンタル・ロギングを自動的に指定するプロシージャ

注意:
サプリメンタル・ロギングは、同期取得を使用してデータベース・オブジェクトに対する変更を取得する場合は必要ありません。

関連項目:
サプリメンタル・ロギング指定を示す問合せについては、『Oracle Streams概要および管理』を参照してください。

Oracle Streamsレプリケーション環境内の必要なサプリメンタル・ロギング

サプリメンタル・ロギングには、データベース・サプリメンタル・ロギングと表サプリメンタル・ロギングの2種類があります。データベース・サプリメンタル・ロギングではデータベース全体のサプリメンタル・ロギングが指定されますが、表サプリメンタル・ロギングでは、特定の表のサプリメンタル・ロギングに使用するログ・グループを指定できます。表サプリメンタル・ロギングを使用する場合は、無条件ログ・グループと条件付きログ・グループのどちらかを選択できます。

無条件ログ・グループでは、表が変更されると、指定した列が変更の影響を受けるかどうかに関係なく、その列のビフォア・イメージがログに記録されます。無条件ログ・グループは、「常時ログ・グループ」と呼ばれることがあります。条件付きログ・グループでは、ログ・グループ内の少なくとも1列が変更される場合にのみ、指定したすべての列のビフォア・イメージがログに記録されます。

データベース・レベルのサプリメンタル・ロギング、表レベルの無条件ログ・グループおよび表レベルの条件付きログ・グループによって、変更ログに記録する古い値が決定されます。

取得プロセスによって取得されたLCRを、1つ以上の適用プロセスを使用して適用する予定の場合は、宛先データベースの表内にある次のタイプの列について、ソース・データベースでサプリメンタル・ロギングを使用可能にする必要があります。

- 宛先データベースで変更が適用される表の主キーに使用されるソース・データベースの列はすべて、ログ・グループに無条件でログを記録するか、主キー列のデータベース・サプリメンタル・ロギングによってログを記録する必要があります。

- 変更を適用する適用プロセスの並列性が2以上の場合、ソース・データベースの複数の列に基づく宛先データベースの一意制約列は、条件付きでログに記録する必要があります。一意制約列がソース・データベースの1つの列に基づく場合は、サプリメンタル・ロギングを指定する必要はありません。

- 変更を適用する適用プロセスの並列性が2以上の場合、ソース・データベースの複数の列に基づく宛先データベースの外部キー列は、条件付きでログに記録する必要があります。外部キー列がソース・データベースの1つの列に基づく場合は、サプリメンタル・ロギングを指定する必要はありません。

- 変更を適用する適用プロセスの並列性が2以上の場合、ソース・データベースの複数の列に基づく宛先データベースのビットマップ索引列は、条件付きでログに記録する必要があります。ビットマップ索引列がソース・データベースの1つの列に基づく場合は、サプリメンタル・ロギングを指定する必要はありません。

- 宛先データベースで適用プロセスの代替キー列として使用されるソース・データベースの列は、無条件でログに記録する必要があります。表の代替キー列を指定するには、DBMS_APPLY_ADMパッケージのSET_KEY_COLUMNSプロシージャを使用します。

- ソース・データベースの複数の列が宛先データベースの列リストに使用されている場合、適用時に競合解消用の列リストで指定された列は、条件付きでログに記録する必要があります。

- 宛先データベースの文DMLハンドラ、変更ハンドラ、プロシージャDMLハンドラまたはエラー・ハンドラで使用されるソース・データベースの列は、無条件でログに記録する必要があります。

- ルールまたはルールベースの変換で使用されるソース・データベースの列は、無条件でログに記録する必要があります。

- 宛先データベースで値の仮想依存性定義に指定されているソース・データベースの列は、無条件でログに記録する必要があります。

- 宛先データベースで表の行のサブセット化を指定する場合は、宛先表に含まれるソース・データベースの列またはサブセット条件に含まれるソース・データベースの列を、無条件でログに記録する必要があります。適用プロセスの行のサブセット化条件を指定するには、DBMS_STREAMS_ADMパッケージのADD_SUBSET_RULESプロシージャでdml_conditionパラメータを使用します。

ソース・データベースでこれらのタイプの列にサプリメンタル・ロギングを使用しないと、これらの列が関係する変更は宛先データベースで正しく適用されない可能性があります。

注意:
データ型のうちLOB、LONG、LONG RAW、ユーザー定義型(オブジェクト型、REF、VARRAY、NESTED TABLEなど)およびOracleが提供する型(Any型、XML型、空間型、メディア型など)の列は、サプリメンタル・ログ・グループに含めることはできません。

関連項目:

- 「列リスト」

- ルールベースの変換の詳細は、「レプリケーション環境に異なるレプリカを含めるかどうかの決定」を参照してください。

- 「レプリケーション環境で適用ハンドラを使用するかどうかの決定」

- データ型の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

無条件ログ・グループを使用した表サプリメンタル・ロギングの指定

ここでは、無条件サプリメンタル・ログ・グループの作成について説明します。

- 主キー列についての無条件のサプリメンタル・ログ・グループの指定

- 表のすべての列についての無条件のサプリメンタル・ログ・グループの指定

- 選択した列を含む無条件のサプリメンタル・ログ・グループの指定

主キー列についての無条件のサプリメンタル・ログ・グループの指定

表の主キー列のみを含む無条件のサプリメンタル・ログ・グループを指定するには、ADD SUPPLEMENTAL LOG DATA句にPRIMARY KEYオプションを指定してALTER TABLE文を実行します。

たとえば、次の文では、無条件のログ・グループにhr.regions表の主キー列が追加されます。

ALTER TABLE hr.regions ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;

ログ・グループはシステム生成名を持ちます。

表のすべての列についての無条件のサプリメンタル・ログ・グループの指定

表のすべての列を含む無条件のサプリメンタル・ログ・グループを指定するには、ADD SUPPLEMENTAL LOG DATA句にALLオプションを指定して、ALTER TABLE文を実行します。

たとえば、次の文では、無条件のログ・グループにhr.regions表のすべての列が追加されます。

ALTER TABLE hr.regions ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;

ログ・グループはシステム生成名を持ちます。

選択した列を含む無条件のサプリメンタル・ログ・グループの指定

選択した列を含む無条件のサプリメンタル・ログ・グループを指定するには、ADD SUPPLEMENTAL LOG GROUP句にALWAYSを指定して、ALTER TABLE文を実行します。必要に応じて、これらのログ・グループにキー列を含めることができます。

たとえば、次の文では、無条件のログ・グループlog_group_dep_pkにhr.departments表のdepartment_id列およびmanager_id列が追加されます。

ALTER TABLE hr.departments ADD SUPPLEMENTAL LOG GROUP log_group_dep_pk
(department_id, manager_id) ALWAYS;

ALWAYS指定があるため、このログ・グループは無条件のログ・グループになります。

条件付きログ・グループを使用した表サプリメンタル・ロギングの指定

ここでは、条件付きログ・グループの作成について説明します。

- ADD SUPPLEMENTAL LOG DATA句を使用した条件付きログ・グループの指定

- ADD SUPPLEMENTAL LOG GROUP句を使用した条件付きログ・グループの指定

ADD SUPPLEMENTAL LOG DATA句を使用した条件付きログ・グループの指定

ALTER TABLE文のADD SUPPLEMENTAL LOG DATA句で、次のオプションを使用できます。

- FOREIGN KEYオプション: 表の外部キー列を含む条件付きログ・グループが作成されます。

- UNIQUEオプション: 表の一意キー列およびビットマップ索引列を含む条件付きログ・グループが作成されます。

1つのALTER TABLE文に複数のオプションを指定する場合、各オプションに対して個別の条件付きログ・グループが作成されます。

たとえば、次の文では、2つの条件付きログ・グループが作成されます。

ALTER TABLE hr.employees ADD SUPPLEMENTAL LOG DATA
(UNIQUE, FOREIGN KEY) COLUMNS;

一方の条件付きログ・グループには表の一意キー列およびビットマップ索引列が含まれ、他方には表の外部キー列が含まれます。どちらのログ・グループもシステム生成名を持ちます。

注意:
UNIQUEオプションを指定した場合、ビットマップ結合索引列のサプリメンタル・ロギングは有効になりません。

ADD SUPPLEMENTAL LOG GROUP句を使用した条件付きログ・グループの指定

追加するように選択したすべての列を含む条件付きのサプリメンタル・ログ・グループを指定するには、ADD SUPPLEMENTAL LOG GROUP句を指定して、ALTER TABLE文を実行します。ログ・グループを条件付きにするには、ALWAYS指定を含めないでください。

たとえば、hr.jobs表のmin_salaryおよびmax_salary列が、宛先データベースで競合解消用の列リストに含まれているとします。次の文では、min_salaryおよびmax_salary列が条件付きのログ・グループlog_group_jobs_crに追加されます。

ALTER TABLE hr.jobs ADD SUPPLEMENTAL LOG GROUP log_group_jobs_cr
(min_salary, max_salary);

サプリメンタル・ログ・グループの削除

条件付きまたは無条件のサプリメンタル・ログ・グループを削除するには、ALTER TABLE文にDROP SUPPLEMENTAL LOG GROUP句を使用します。たとえば、サプリメンタル・ログ・グループlog_group_jobs_crを削除するには、次の文を実行します。

ALTER TABLE hr.jobs DROP SUPPLEMENTAL LOG GROUP log_group_jobs_cr;

キー列のデータベース・サプリメンタル・ロギングの指定

ソース・データベース内のすべての主キー列、一意キー列、ビットマップ索引列および外部キー列について、サプリメンタル・ロギングを指定するオプションもあります。データベース全体に対する変更を取得するように取得プロセスを構成する場合は、このオプションを選択できます。ソース・データベース内のすべての主キー列、一意キー列、ビットマップ索引列および外部キー列のサプリメンタル・ロギングを指定するには、次のSQL文を発行します。

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA
(PRIMARY KEY, UNIQUE, FOREIGN KEY) COLUMNS;

主キー列、一意キー列、ビットマップ索引列および外部キー列がすべてのソース・データベースと宛先データベースで同一の場合に、このコマンドをソース・データベースで実行すると、すべての宛先データベースで主キー列、一意キー列、ビットマップ索引列および外部キー列に必要なサプリメンタル・ロギングが提供されます。PRIMARY KEYオプションを指定した場合に、表が変更されると、行の主キーのすべての列がREDOログ・ファイルに記録されます(無条件ロギング)。UNIQUEオプションを指定した場合に、一意キーまたはビットマップ索引に属するいずれかの列が変更されると、行の一意キーおよびビットマップ索引のすべての列がREDOログ・ファイルに記録されます(条件付きロギング)。FOREIGN KEYオプションを指定した場合に、外部キーに属するいずれかの列が変更されると、行の外部キーのすべての列がREDOログ・ファイルに記録されます(条件付きロギング)。

これらのオプションの1つ以上を省略できます。たとえば、データベースのすべての外部キー列に対してサプリメンタル・ロギングが必要でない場合、次の例に示すとおり、FOREIGN KEYオプションを省略できます。

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA
(PRIMARY KEY, UNIQUE) COLUMNS;

PRIMARY KEY、UNIQUEおよびFOREIGN KEYのみでなく、ALLオプションを使用することもできます。ALLオプションを指定すると、行が変更された場合に、その行のすべての列(LOB、LONG、LONG RAW、ユーザー定義型およびOracleが提供する型の列を除く)がREDOログ・ファイルに記録されます(無条件ロギング)。

サプリメンタル・ロギングの文は実行ごとに結果を記録します。異なる識別キーを指定して2つのALTER DATABASE ADD SUPPLEMENTAL LOG DATAコマンドを連続して発行すると、どちらのキーに対してもサプリメンタル・ロギングが行われます。

注意:
UNIQUEオプションを指定した場合、ビットマップ結合索引列のサプリメンタル・ロギングは有効になりません。

関連項目:
データ型の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

キー列のデータベース・サプリメンタル・ロギングの削除

ソース・データベース内のすべての主キー列、一意キー列、ビットマップ索引列および外部キー列のサプリメンタル・ロギングを削除するには、ALTER DATABASE DROP SUPPLEMENTAL LOG DATA文を発行します。すべての主キー列、一意キー列、ビットマップ索引列および外部キー列のデータベース・サプリメンタル・ロギングを削除するには、次のSQL文を発行します。

ALTER DATABASE DROP SUPPLEMENTAL LOG DATA
(PRIMARY KEY, UNIQUE, FOREIGN KEY) COLUMNS;

注意:
キー列のデータベース・サプリメンタル・ロギングを削除しても、既存の表レベルのサプリメンタル・ログ・グループには影響しません。

サプリメンタル・ロギングを自動的に指定するプロシージャ

DBMS_CAPTURE_ADMパッケージの次のプロシージャでは、サプリメンタル・ロギングが自動的に指定されます。

- BUILD

- PREPARE_GLOBAL_INSTANTIATION

- PREPARE_SCHEMA_INSTANTIATION

- PREPARE_TABLE_INSTANTIATION

BUILDプロシージャでは、ALTER DATABASE ADD SUPPLEMENTAL LOG DATA文を実行することで、データベース・サプリメンタル・ロギングが自動的に指定されます。ほとんどの場合、BUILDプロシージャは取得プロセスの作成時に自動的に実行されます。

PREPARE_GLOBAL_INSTANTIATION、PREPARE_SCHEMA_INSTANTIATIONおよびPREPARE_TABLE_INSTANTIATIONプロシージャでは、インストール用に準備された表の主キー列、一意キー列、ビットマップ索引列および外部キー列のサプリメンタル・ロギングが自動的に指定されます。

DBMS_STREAMS_ADMパッケージの特定のプロシージャでは、前述のプロシージャが自動的に実行されます。詳細は、「自動的にオブジェクトを準備するDBMS_STREAMS_ADMパッケージのプロシージャ」を参照してください。

関連項目:
これらのプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

ダウンストリーム取得データベースへのログ・ファイルの転送の構成

ソース・データベースでのローカル取得プロセスを使用するように決定した場合、ログ・ファイルを転送する必要はありません。ただし、REDO転送サービスを使用してアーカイブREDOログ・ファイルをダウンストリーム・データベースに自動的に転送するダウンストリーム取得を使用するように決定した場合は、レプリケーション環境を構成する前に、ソース・データベースから取得データベースへのログ・ファイルの転送を構成します。この決定の詳細は、「ソース・データベースに対してローカル取得またはダウンストリーム取得を構成するかどうかの決定」を参照してください。

次のいずれかの方法を使用してダウンストリーム取得を構成する場合は、この項の手順を完了する必要があります。

- DBMS_STREAMS_ADMが提供されているPL/SQLパッケージの構成プロシージャを実行して、2つのデータベース間のレプリケーションを構成する方法

- 各Oracle Streamsコンポーネントを個別に構成する方法

これらの方法の詳細は、「レプリケーション環境の構成方法の決定」を参照してください。

ヒント:
Oracle Enterprise Managerを使用して、ログ・ファイルの転送およびダウンストリーム取得プロセスを構成できます。手順については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

次の手順を実行して、ソース・データベースのREDOログ・ファイルを取得データベースに転送するための準備、および取得データベースでそれらのREDOログ・ファイルを受け入れるための準備を行います。

1. ソース・データベースでダウンストリーム・データベースと通信できるように、Oracle Netを構成します。

関連項目:
『Oracle Database Net Services管理者ガイド』

2. 両方のデータベースで、REDOデータの転送がサポートされるように認証を構成します。
REDO転送セッションは、Secure Sockets Layer(SSL)プロトコルまたはリモート・ログイン・パスワード・ファイルのいずれかを使用して認証されます。ソース・データベースにリモート・ログイン・パスワード・ファイルがある場合は、そのファイルをダウンストリーム取得データベース・システムの適切なディレクトリにコピーします。ソース・データベースとダウンストリーム取得データベースで、同じパスワード・ファイルを使用する必要があります。

関連項目:
REDO転送の認証要件の詳細は、『Oracle Data Guard概要および管理』を参照してください。

3. ソース・データベースからダウンストリーム・データベースにREDOデータを転送するREDO転送サービスを構成するために、ソース・データベースで次の初期化パラメータを設定します。

- LOG_ARCHIVE_DEST_n: ダウンストリーム・データベースにREDOデータが転送されるように、1つ以上のLOG_ARCHIVE_DEST_n初期化パラメータを構成します。このパラメータの次の属性を次の方法で設定します。

- SERVICE: ダウンストリーム・データベースのネットワーク・サービス名を指定します。

- ASYNCまたはSYNC: REDO転送モードを指定します。
ASYNCを指定するメリットは、ソース・データベースのパフォーマンスにほとんど影響を与えないことです。ソース・データベースでOracle Database 10gリリース1以上を実行しており、ダウンストリーム・データベースまたはネットワークのパフォーマンスが低い場合は、ソース・データベースのパフォーマンスに影響を及ぼさないようにASYNCを指定することをお薦めします。

SYNCを指定するメリットは、ASYNCを指定した場合より高速にダウンストリーム・データベースにREDOデータが送信されることです。また、SYNC AFFIRMを指定すると、MAXIMUM AVAILABILITYスタンバイ保護モードと同様に動作します。SQL文ALTER DATABASE STANDBY DATABASE TO MAXIMIZE AVAILABILITYを指定しても、Oracle Streamsの取得プロセスに影響しないことに注意してください。

- NOREGISTER: この属性を指定すると、アーカイブREDOログ・ファイルの位置が、ダウンストリーム・データベースの制御ファイルに記録されません。

- VALID_FOR: (ONLINE_LOGFILE,PRIMARY_ROLE)または(ONLINE_LOGFILE,ALL_ROLES)のいずれかを指定します。

- TEMPLATE: アーカイブ・ログ・ダウンストリームの取得プロセスを構成するときには、ダウンストリーム・データベースでアーカイブREDOログ用のディレクトリおよびフォーマット・テンプレートを指定します。TEMPLATE属性は、ダウンストリーム・データベースのLOG_ARCHIVE_FORMAT初期化パラメータ設定を上書きします。TEMPLATE属性は、リモートの接続先でのみ有効です。各ソース・データベースで、フォーマットに%t、%sおよび%rのすべての変数を使用していることを確認します。
リアルタイム・ダウンストリームの取得プロセスを構成するときには、TEMPLATE属性を指定しないでください。

- DB_UNIQUE_NAME: ダウンストリーム・データベースの一意の名前。ダウンストリーム・データベースでDB_UNIQUE_NAME初期化パラメータに指定した名前を使用します。

次に、リアルタイム・ダウンストリーム取得プロセスにダウンストリーム・データベースdbs2を指定するLOG_ARCHIVE_DEST_n設定の例を示します。

LOG_ARCHIVE_DEST_2='SERVICE=DBS2.EXAMPLE.COM ASYNC NOREGISTER
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=dbs2'

次に、アーカイブ・ログ・ダウンストリーム取得プロセスにダウンストリーム・データベースdbs2を指定するLOG_ARCHIVE_DEST_n設定の例を示します。

LOG_ARCHIVE_DEST_2='SERVICE=DBS2.EXAMPLE.COM ASYNC NOREGISTER
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
TEMPLATE=/usr/oracle/log_for_dbs1/dbs1_arch_%t_%s_%r.log
DB_UNIQUE_NAME=dbs2'

リアルタイム・ダウンストリーム取得とアーカイブ・ログ・ダウンストリーム取得の違いの詳細は、「ソース・データベースに対してローカル取得またはダウンストリーム取得を構成するかどうかの決定」を参照してください。

ヒント:
アーカイブ・ログ・ダウンストリーム取得プロセスを構成している場合は、リモート・ソース・データベースからのログ・ファイルとローカル・データベースのログ・ファイルを別々に保持するTEMPLATE属性の値を指定してください。また、ダウンストリーム・データベースに複数のソース・データベースからのログ・ファイルが含まれている場合、各ソース・データベースからのログ・ファイルを個別に格納する必要があります。

- LOG_ARCHIVE_DEST_STATE_n: ダウンストリーム・データベースのLOG_ARCHIVE_DEST_nパラメータに対応するこの初期化パラメータをENABLEに設定します。
たとえば、LOG_ARCHIVE_DEST_2初期化パラメータがダウンストリーム・データベース用に設定されている場合は、LOG_ARCHIVE_DEST_STATE_2パラメータを次のとおり設定します。

LOG_ARCHIVE_DEST_STATE_2=ENABLE

- LOG_ARCHIVE_CONFIG: ソース・データベースとダウンストリーム・データベースのDB_UNIQUE_NAMEを含めるように、この初期化パラメータのDG_CONFIG属性を設定します。
たとえば、ソース・データベースのDB_UNIQUE_NAMEがdbs1で、ダウンストリーム・データベースのDB_UNIQUE_NAMEがdbs2の場合は、次のパラメータを指定します。

LOG_ARCHIVE_CONFIG='DG_CONFIG=(dbs1,dbs2)'

デフォルトで、LOG_ARCHIVE_CONFIGパラメータによって、データベースによるREDOの送受信が可能になります。

関連項目:
これらの初期化パラメータの詳細は、『Oracle Databaseリファレンス』および『Oracle Data Guard概要および管理』を参照してください。

4. ダウンストリーム・データベースで、ソース・データベースとダウンストリーム・データベースのDB_UNIQUE_NAMEを含めるように、LOG_ARCHIVE_CONFIG初期化パラメータのDG_CONFIG属性を設定します。

たとえば、ソース・データベースのDB_UNIQUE_NAMEがdbs1で、ダウンストリーム・データベースのDB_UNIQUE_NAMEがdbs2の場合は、次のパラメータを指定します。

LOG_ARCHIVE_CONFIG='DG_CONFIG=(dbs1,dbs2)'

デフォルトで、LOG_ARCHIVE_CONFIGパラメータによって、データベースによるREDOの送受信が可能になります。

5. 手順3または手順4で、データベース上でインスタンスを実行中に初期化パラメータをリセットした場合、データベースが再起動されたときに新しい値が保持されるように、それらのパラメータを初期化パラメータ・ファイルでもリセットする必要があります。

手順3または4で、インスタンスの実行中に初期化パラメータをリセットせず、初期化パラメータ・ファイルでリセットした場合は、データベースを再起動します。ソース・データベースのグローバル名は、ソース・データベースがオープンな場合にのみダウンストリーム・データベースに送信されるため、ダウンストリーム・データベースにREDOログ・ファイルを送信するときには、ソース・データベースがオープンである必要があります。

これらの手順が完了したら、次のいずれかのタスクを実行できます。

- アーカイブ・ログ・ダウンストリーム取得プロセスを構成します。この場合、次の項の手順を参照してください。

- 「DBMS_STREAMS_ADMパッケージを使用したレプリケーションの構成」

- 「アーカイブ・ログ・ダウンストリーム取得プロセスの構成」

- ダウンストリーム・データベースでリアルタイム・ダウンストリーム取得プロセス用のスタンバイREDOログ・ファイルを追加します。この場合、「リアルタイム・ダウンストリーム取得のためのスタンバイREDOログの追加」の手順を参照してください。

リアルタイム・ダウンストリーム取得のためのスタンバイREDOログの追加

この項の例では、ダウンストリーム・データベースでスタンバイREDOログを追加します。スタンバイREDOログは、リアルタイム・ダウンストリーム取得プロセスを構成するために必要です。この例では、ソース・データベースはdbs1.example.com、ダウンストリーム・データベースはdbs2.example.comです。

リアルタイム・ダウンストリーム取得とアーカイブ・ログ・ダウンストリーム取得の違いの詳細は、「ソース・データベースに対してローカル取得またはダウンストリーム取得を構成するかどうかの決定」を参照してください。この項の手順は、リアルタイム・ダウンストリーム取得を構成している場合にのみ実行する必要があります。アーカイブ・ログ・ダウンストリーム取得を構成している場合、この項の手順は実行しないでください。

ヒント:
Oracle Enterprise Managerを使用して、リアルタイム・ダウンストリーム取得を構成できます。手順については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

ダウンストリーム・データベースでスタンバイREDOログを追加するには、次の手順を実行します。

1. 「ダウンストリーム取得データベースへのログ・ファイルの転送の構成」の手順を実行します。

2. ダウンストリーム・データベースで、次の初期化パラメータを設定して、ローカルに生成されるREDOデータのアーカイブを構成します。

- LOG_ARCHIVE_DEST_n初期化パラメータで、ダウンストリーム・データベースを実行中のコンピュータ・システム上のディレクトリまたは高速リカバリ領域のいずれかになるよう、アーカイブ・ログの宛先を少なくとも1つ設定します。このパラメータの次の属性を次の方法で設定します。

- LOCATION: ディスク・ディレクトリの有効なパス名を指定するか、または高速リカバリ領域を使用するためにUSE_DB_RECOVERY_FILE_DESTを指定します。この場所は、スタンバイREDOログから書き込まれるアーカイブREDOログ・ファイルのローカルの宛先です。リモート・ソース・データベースからのログ・ファイルは、ローカル・データベースのログ・ファイルとは別々に保持する必要があります。高速リカバリ領域の構成の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- VALID_FOR: (ONLINE_LOGFILE,PRIMARY_ROLE)または(ONLINE_LOGFILE,ALL_ROLES)のいずれかを指定します。

次に、リアルタイム・ダウンストリーム取得データベースでローカルに生成されるREDOデータのためのLOG_ARCHIVE_DEST_n設定の例を示します。

LOG_ARCHIVE_DEST_1='LOCATION=/home/arc_dest/local_rl_dbs2
VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE)'

リアルタイム・ダウンストリーム取得の構成では、アーカイブ・スタンバイREDOログ・ファイルとダウンストリーム・データベースで生成されるアーカイブ・オンラインREDOログ・ファイルは別々に保持する必要があります。これを行うには、VALID_FOR属性のREDOログ・タイプに、ALL_LOGFILESのかわりにONLINE_LOGFILEを指定します。

必要に応じて、LOG_ARCHIVE_DEST_n初期化パラメータの他の属性を指定できます。

- この手順で以前に設定したLOG_ARCHIVE_DEST_nパラメータに対応するLOG_ARCHIVE_DEST_STATE_n初期化パラメータを、ENABLEに設定します。
たとえば、LOG_ARCHIVE_DEST_1初期化パラメータが設定されている場合は、LOG_ARCHIVE_DEST_STATE_1パラメータを次のとおり設定します。

LOG_ARCHIVE_DEST_STATE_1=ENABLE

3. ダウンストリーム・データベースで、次の初期化パラメータを設定して、ソース・データベースからREDOデータを受信し、そのREDOデータをダウンストリーム・データベースのスタンバイREDOログに書き込むようにダウンストリーム・データベースを構成します。

- LOG_ARCHIVE_DEST_n初期化パラメータで、ダウンストリーム・データベースを実行中のコンピュータ・システム上のディレクトリまたは高速リカバリ領域のいずれかになるよう、アーカイブ・ログの宛先を少なくとも1つ設定します。このパラメータの次の属性を次の方法で設定します。

- LOCATION: ディスク・ディレクトリの有効なパス名を指定するか、または高速リカバリ領域を使用するためにUSE_DB_RECOVERY_FILE_DESTを指定します。この場所は、スタンバイREDOログから書き込まれるアーカイブREDOログ・ファイルのローカルの宛先です。リモート・ソース・データベースからのログ・ファイルは、ローカル・データベースのログ・ファイルとは別々に保持する必要があります。高速リカバリ領域の構成の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- VALID_FOR: (STANDBY_LOGFILE,PRIMARY_ROLE)または(STANDBY_LOGFILE,ALL_ROLES)を指定します。

次に、リアルタイム・ダウンストリーム取得データベースでソース・データベースから受信するREDOデータのためのLOG_ARCHIVE_DEST_n設定の例を示します。

LOG_ARCHIVE_DEST_2='LOCATION=/home/arc_dest/srl_dbs1
VALID_FOR=(STANDBY_LOGFILE,PRIMARY_ROLE)'

必要に応じて、LOG_ARCHIVE_DEST_n初期化パラメータの他の属性を指定できます。

- この手順で以前に設定したLOG_ARCHIVE_DEST_nパラメータに対応するLOG_ARCHIVE_DEST_STATE_n初期化パラメータを、ENABLEに設定します。
たとえば、LOG_ARCHIVE_DEST_2初期化パラメータがダウンストリーム・データベース用に設定されている場合は、LOG_ARCHIVE_DEST_STATE_2パラメータを次のとおり設定します。

LOG_ARCHIVE_DEST_STATE_2=ENABLE

関連項目:
これらの初期化パラメータの詳細は、『Oracle Databaseリファレンス』および『Oracle Data Guard概要および管理』を参照してください。

4. 手順2または手順3で、データベース上でインスタンスを実行中に初期化パラメータをリセットした場合、データベースが再起動されたときに新しい値が保持されるように、それらのパラメータを関連する初期化パラメータ・ファイルでもリセットする必要があります。
Step ステップ2または3で、インスタンスの実行中には初期化パラメータをリセットしなかったが、初期化パラメータ・ファイルでリセットした場合は、データベースを再起動します。ソース・データベースのグローバル名は、ソース・データベースがオープンな場合にのみダウンストリーム・データベースに送信されるため、ダウンストリーム・データベースにREDOデータを送信するときには、ソース・データベースがオープンである必要があります。

5. スタンバイREDOログ・ファイルを作成します。

注意:
次の手順では、スタンバイREDOログ・ファイルをダウンストリーム・データベースに追加する一般的な方法の概要を示します。スタンバイREDOログ・ファイルを追加するための特定の手順とSQL文は、環境によって異なります。たとえば、Oracle Real Application Clusters(Oracle RAC)環境では、異なる手順を使用します。スタンバイREDOログ・ファイルをデータベースに追加する手順の詳細は、『Oracle Data Guard概要および管理』を参照してください。

1. SQL*Plusで、管理ユーザーとしてソース・データベースdbs1.example.comに接続します。
SQL*Plusでのデータベースへの接続の詳細は、『Oracle Database管理者ガイド』を参照してください。

2. ソース・データベースで使用されるログ・ファイルのサイズを決定します。スタンバイ・ログ・ファイルのサイズは、ソース・データベースのログ・ファイルのサイズと同じ(またはそれ以上)にする必要があります。たとえば、ソース・データベースのログ・ファイルのサイズが500MBの場合、スタンバイ・ログ・ファイルのサイズは500MB以上にする必要があります。ソース・データベースでV$LOGビューを問い合せて、ソース・データベースのREDOログ・ファイルのサイズ(バイト単位)を確認できます。
たとえば、V$LOGビューを問い合せます。

SELECT BYTES FROM V$LOG;

3. ダウンストリーム・データベースで必要なスタンバイ・ログ・ファイル・グループの数を決定します。スタンバイ・ログ・ファイル・グループの数は、ソース・データベースのオンライン・ログ・ファイル・グループの数より1つ以上多くする必要があります。たとえば、ソース・データベースに2つのオンライン・ログ・ファイル・グループが存在する場合、ダウンストリーム・データベースには3つ以上のスタンバイ・ログ・ファイル・グループが必要です。ソース・データベースでV$LOGビューを問い合せて、ソース・データベースのオンライン・ログ・ファイル・グループの数を確認できます。
たとえば、V$LOGビューを問い合せます。

SELECT COUNT(GROUP#) FROM V$LOG;

4. SQL*Plusで、管理ユーザーとしてダウンストリーム・データベースdbs2.example.comに接続します。

5. SQL文ALTER DATABASE ADD STANDBY LOGFILEを使用して、スタンバイ・ログ・ファイル・グループをダウンストリーム・データベースに追加します。
たとえば、ソース・データベースに2つのオンラインREDOログ・ファイル・グループが存在し、そのソース・データベースで500MBのログ・ファイル・サイズが使用されていると想定します。この場合は、次の文を使用して、適切なスタンバイ・ログ・ファイル・グループを作成します。

ALTER DATABASE ADD STANDBY LOGFILE GROUP 3
('/oracle/dbs/slog3a.rdo', '/oracle/dbs/slog3b.rdo') SIZE 500M;

ALTER DATABASE ADD STANDBY LOGFILE GROUP 4
('/oracle/dbs/slog4.rdo', '/oracle/dbs/slog4b.rdo') SIZE 500M;

ALTER DATABASE ADD STANDBY LOGFILE GROUP 5
('/oracle/dbs/slog5.rdo', '/oracle/dbs/slog5b.rdo') SIZE 500M;

6. 次の問合せを実行して、スタンバイ・ログ・ファイル・グループが正常に追加されたことを確認します。

SELECT GROUP#, THREAD#, SEQUENCE#, ARCHIVED, STATUS
FROM V$STANDBY_LOG;

出力は次のようになります。

GROUP#    THREAD#  SEQUENCE# ARC STATUS
---------- ---------- ---------- --- ----------
3          0          0 YES UNASSIGNED
4          0          0 YES UNASSIGNED
5          0          0 YES UNASSIGNED

7. ソース・データベースからのログ・ファイルが手順3でLOCATION属性に指定した場所に存在することを確認します。ディレクトリ内のファイルを確認するには、ソース・データベースのログ・ファイルを切り替える必要がある場合があります。

これらの手順が完了すると、リアルタイム・ダウンストリーム取得プロセスを構成できます。次の項の手順を参照してください。

- 「DBMS_STREAMS_ADMパッケージを使用したレプリケーションの構成」

- 「リアルタイム・ダウンストリームの取得プロセスの構成」

2 Oracle Streamsレプリケーションの簡単な構成

この章では、簡単な方法を使用したOracle Streamsレプリケーションの構成について説明します。

この章の内容は次のとおりです。

- Streamsレプリケーションの設定ウィザードを使用したレプリケーションの構成

- DBMS_STREAMS_ADMパッケージを使用したレプリケーションの構成

Streamsレプリケーションの設定ウィザードを使用したレプリケーションの構成

Oracle Enterprise ManagerのOracle Streamsツールには、Oracle Streamsレプリケーション環境を構成するStreamsレプリケーションの設定ウィザードが含まれています。このウィザードを使用して、次のいずれかの特性を備えたOracle Streamsレプリケーション環境を構成できます。

- ソース・データベース全体、ソース・データベース内の選択されたスキーマ、ソース・データベース内の選択された表領域、ソース・データベース内の選択された表またはソース・データベース内の表のサブセットに対する変更をレプリケートする

- データ操作言語(DML)変更またはデータ定義言語(DDL)変更(あるいはその両方)をメンテナンスする

- 一方向または双方向のレプリケーション

- ローカル取得またはダウンストリーム取得

このウィザードではレプリケーション環境の構成プロセスを実行でき、さらにこのウィザードを複数回実行することで、3つ以上のデータベースを使用するレプリケーション環境を構成できます。このウィザードを使用して構成できるレプリケーション環境のタイプには制限があります。たとえば、このウィザードでは、現在、同期取得は構成できません。

Oracle Streamsレプリケーション環境を即座に構成することも、またはウィザードを使用してスクリプトを生成することもできます。スクリプトを生成する場合は、スクリプトを実行してレプリケーション環境を構成する前に、スクリプトを確認し、必要に応じて編集できます。

このウィザードをオープンするには、Enterprise Managerで次の手順を実行します。

1. 「Oracle Streamsレプリケーションを構成する前に行う決定」で説明されている決定を確認します。Oracle Streamsレプリケーション環境に関する決定を行ってから、先に進みます。

2. Oracle Streamsレプリケーション環境を準備するタスクを完了します。「Oracle Streamsレプリケーションを構成する前に実行するタスク」を参照してください。
ウィザードにより一部のタスクは自動的に完了しますが、次のタスクは手動で完了する必要があります。

- 両方のデータベースでOracle Streams管理者を構成します。「すべてのデータベースでのOracle Streams管理者の構成」を参照してください。まだ構成済みでない場合は、手順6の「Streams」ページを開いた後に、「Streams管理者ユーザー」リンクをクリックし、Oracle Enterprise Managerを使用してOracle Streamsを管理するOracle Streams管理者を構成する必要があります。

- 2つのデータベース間のネットワーク接続を構成します。「ネットワーク接続性とデータベース・リンクの構成」を参照してください。

- ソース・データベースになるデータベースがARCHIVELOGモードであることを確認します。双方向のレプリケーションを構成する場合は、両方のデータベースがARCHIVELOGモードである必要があります。「各ソース・データベースがARCHIVELOGモードであることの確認」を参照してください。

- 両方のデータベースの初期化パラメータが適切に設定されていることを確認します。「Oracle Streamsに関連する初期化パラメータの設定」を参照してください。

- 両方のデータベースでOracle Streamsプールを適切に構成します。「Oracle Streamsプールの構成」を参照してください。

3. Oracle Enterprise Managerで、Oracle Streams管理者としてデータベースにログインします。レプリケーション環境でソース・データベースになるデータベースにログインします。

4. データベースの「ホーム」ページに移動します。

5. 「データ移動」をクリックして、「データ移動」サブページを開きます。

6. 「Streams」セクションの「設定」をクリックして、「Streams」ページを開きます。

7. 「Streamsレプリケーションの設定」セクションでは、構成するレプリケーション環境のタイプのオプションを選択します。

8. 「ホスト資格証明」セクションでは、ソース・データベースを実行するホスト・コンピュータのユーザー名およびパスワードを入力します。

9. 「続行」をクリックして、Streamsレプリケーションの設定ウィザードをオープンします。
これは、「Streams」ページの「表のレプリケート」を選択すると最初に表示されるウィザード・ページです。

注意:
Streamsレプリケーションの設定ウィザードでは、デフォルトで一方向のレプリケーションが構成されます。双方向のレプリケーションを構成するには、「レプリケーション・オプション」ページの「拡張オプション」セクションを開き、「双方向レプリケーションの設定」を選択します。双方向のレプリケーションを構成する場合は、競合解消が必要になることがあります。

関連項目:

- このウィザードを使用してOracle Streamsレプリケーション環境を構成する場合の例は、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

- 「どのタイプのレプリケーション環境を構成するかの決定」

- 第9章「Oracle Streamsの競合解消」

DBMS_STREAMS_ADMパッケージを使用したレプリケーションの構成

DBMS_STREAMS_ADMパッケージのプロシージャを使用して、Oracle Streamsレプリケーション環境を構成できます。

ここでは、これらのプロシージャ、これらのプロシージャのいずれかの実行を準備する手順および一般的な使用例について説明します。

- Oracle Streamsレプリケーション構成プロシージャ

- 構成プロシージャに関する重要な考慮事項

- 必要なディレクトリ・オブジェクトの作成

- ローカル取得を使用した2データベース・レプリケーションを構成する場合の例

- ダウンストリーム取得を使用した2データベース・レプリケーションを構成する場合の例

- ハブ・アンド・スポーク・レプリケーションを構成する場合の例

- Oracle Streams構成の進捗の監視

関連項目:

- これらのプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- これらのプロシージャを使用してOracle Streamsレプリケーション環境を構成する例については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

Oracle Streamsレプリケーション構成プロシージャ

Oracle Streamsレプリケーション環境を構成する最も簡単な方法は、DBMS_STREAMS_ADMパッケージにある次のいずれかの構成プロシージャを実行することです。

- MAINTAIN_GLOBAL: 2つのデータベース間でデータベース・レベルの変更をレプリケートするOracle Streams環境が構成されます。

- MAINTAIN_SCHEMAS: 2つのデータベース間で、指定されたスキーマに対する変更をレプリケートするOracle Streams環境が構成されます。

- MAINTAIN_SIMPLE_TTS: 宛先データベースでソース・データベースからの単一の表領域がクローニングされ、Oracle Streamsを使用して両方のデータベースでこの表領域がメンテナンスされます。

- MAINTAIN_TABLES: 2つのデータベース間で、指定された表に対する変更をレプリケートするOracle Streams環境が構成されます。

- MAINTAIN_TTS: 宛先データベースでソース・データベースからの表領域セットがクローニングされ、Oracle Streamsを使用して両方のデータベースでこれらの表領域がメンテナンスされます。

- PRE_INSTANTIATION_SETUPおよびPOST_INSTANTIATION_SETUP: 2つのデータベース間でデータベース・レベルの変更または指定された表に対する変更をレプリケートするOracle Streams環境が構成されます。Oracle Streamsレプリケーションの構成を完了するには、これらのプロシージャをともに使用し、インスタンス化の操作を手動で実行する必要があります。通常、これらのプロシージャを使用して、データベースのメンテナンス操作を停止時間なしでまたは短い停止時間で実行します。詳細は、『Oracle Streams概要および管理』を参照してください。

これらのプロシージャでは、2つのデータベースを同時に構成しますので、1つのデータベースをソース・データベースとして、またもう一方のデータベースを宛先データベースとして指定する必要があります。これらのプロシージャを複数回実行することによって、3つ以上のデータベースを使用するレプリケーション環境を構成できます。

表2-1に、これらのプロシージャの必須パラメータを示します。

表2-1 Oracle Streamsレプリケーション構成プロシージャの必須パラメータ

パラメータ

プロシージャ

説明

source_directory_object

すべてのプロシージャ

生成されたデータ・ポンプ・エクスポート・ダンプ・ファイルの格納先となる、ソース・データベースを実行するコンピュータ・システム上にあるディレクトリのディレクトリ・オブジェクト。

注意: 指定したディレクトリ・オブジェクトは、自動ストレージ管理(ASM)ディスク・グループをポイントできません。

destination_directory_object

すべてのプロシージャ

生成されたデータ・ポンプ・エクスポート・ダンプ・ファイルの転送先となる、宛先データベースを実行するコンピュータ・システム上にあるディレクトリのディレクトリ・オブジェクト。ダンプ・ファイルを使用して、宛先データベースでレプリケートされたデータベース・オブジェクトがインスタンス化されます。

注意: 指定したディレクトリ・オブジェクトは、自動ストレージ管理(ASM)ディスク・グループをポイントできません。

source_database

すべてのプロシージャ

ソース・データベースのグローバル名。指定したデータベースには、レプリケートされるデータベース・オブジェクトが含まれている必要があります。

destination_database

すべてのプロシージャ

宛先データベースのグローバル名。宛先データベースにはレプリケートされるデータベース・オブジェクトが含まれている場合と含まれていない場合があります。宛先データベースにレプリケートされるデータベース・オブジェクトが存在しない場合は、データ・ポンプ・エクスポート/インポートによって、レプリケートされるデータベース・オブジェクトがインスタンス化されます。

ローカル・データベースが宛先データベースではない場合は、ローカル・データベースから宛先データベースへのデータベース・リンク(宛先データベースのグローバル名と同じ名前を使用)が存在している必要があり、またプロシージャを実行するユーザーがこのリンクにアクセス可能である必要があります。

schema_names

MAINTAIN_SCHEMASのみ。

レプリケーション用に構成されるスキーマ。

tablespace_name

MAINTAIN_SIMPLE_TTSのみ。

レプリケーション用に構成される表領域。

table_names

MAINTAIN_TABLESのみ。

レプリケーション用に構成される表。

tablespace_names

MAINTAIN_TTSのみ。

レプリケーション用に構成される表領域。

また、これらの各プロシージャには複数のオプション・パラメータが用意されています。bi_directionalパラメータは、重要なオプション・パラメータです。各データベースでレプリケートされたデータベース・オブジェクトへの変更を各データベースで取得し、また他のデータベースへ送信する場合は、bi_directionalパラメータをTRUEに設定する必要があります。このパラメータのデフォルトの設定はFALSEです。bi_directionalパラメータがFALSEに設定されている場合、プロシージャでは、宛先データベースで行われた変更が取得されない一方向のレプリケーション環境を構成します。

これらのプロシージャでは、複数のタスクを実行して、Oracle Streamsレプリケーション環境を構成します。これらのタスクには次が含まれます。

- ソース・データベースのレプリケートされたデータベース・オブジェクトに対するサプリメンタル・ロギングを構成します。

- bi_directionalパラメータがTRUEに設定されている場合は、宛先データベースのレプリケートされたデータベース・オブジェクトに対するサプリメンタル・ロギングを構成します。

- 宛先データベースでデータベース・オブジェクトをインスタンス化します。宛先データベースにデータベース・オブジェクトが存在しない場合、プロシージャではデータ・ポンプ・エクスポート/インポートを使用して宛先データベースでデータベース・オブジェクトをインスタンス化します。

- ソース・データベースのレプリケートされたデータベース・オブジェクトに対する変更を取得する取得プロセスを構成します。この取得プロセスには、ローカル取得プロセスまたはダウンストリーム取得プロセスを使用します。プロシージャがsource_databaseパラメータで指定したデータベースで実行された場合、プロシージャでは、このデータベース上でローカル取得プロセスを構成します。プロシージャがsource_databaseパラメータで指定したデータベース以外のデータベースで実行された場合、プロシージャでは、このプロシージャが実行されたデータベース上でダウンストリーム取得プロセスを構成します。

- bi_directionalパラメータがTRUEに設定されている場合は、宛先データベースのレプリケートされたデータベース・オブジェクトに対する変更を取得する取得プロセスを構成します。この取得プロセスは、ローカル取得プロセスである必要があります。

- 各データベースで、取得された変更を格納する1つ以上のキューを構成します。

- ソース・データベースのデータベース・オブジェクトに対する変更を宛先データベースに送信する伝播を構成します。

- bi_directionalパラメータがTRUEに設定されている場合は、宛先データベースのデータベース・オブジェクトに対する変更をソース・データベースに送信する伝播を構成します。

- 宛先データベースで、ソース・データベースからの変更を適用する適用プロセスを構成します。

- bi_directionalパラメータがTRUEに設定されている場合は、ソース・データベースで、宛先データベースからの変更を適用する適用プロセスを構成します。

- 取得プロセス、伝播および適用プロセスごとに、ルールおよびルール・セットを構成します。ルールでは、指定したデータベース・オブジェクトに対する変更をレプリケートするようにOracle Streamsクライアントに指示します。

- 宛先データベースでレプリケートされたデータベース・オブジェクトのインスタンス化SCNを設定します。

- bi_directionalパラメータがTRUEに設定されている場合は、ソース・データベースでレプリケートされたデータベース・オブジェクトのインスタンス化SCNを設定します。

ヒント:
これらのプロシージャのいずれかによって実行される全アクションの詳細を表示するには、プロシージャを使用してスクリプトを生成し、このスクリプトをテキスト・エディタで表示します。perform_actions、script_nameおよびscript_directory_objectパラメータを使用すると、スクリプトが生成できます。

これらのプロシージャでは、常にハブ・アンド・スポーク・レプリケーション環境のタグを構成します。これらのプロシージャおよびタグに関する重要な考慮事項は次のとおりです。

- 2データベース・レプリケーション環境を構成する場合は、これらのプロシージャを使用して環境を構成できます。これらのプロシージャでは、2データベース環境のタグを構成して、変更の循環を回避します。将来的にレプリケーション環境を拡張して3つ以上のデータベースを使用する計画がある場合は、タグの構成方法を理解することが重要です。拡張されたデータベース環境がハブ・アンド・スポーク環境ではない場合、変更の循環を回避するためにタグの変更が必要になる場合があります。

- 3つ以上のデータベースを含むレプリケーション環境を構成する場合、これらのプロシージャは、ハブ・アンド・スポーク・レプリケーション環境の構成にのみ使用できます。これらのプロシージャでは、ハブ・アンド・スポーク環境のタグを構成して、変更の循環を回避します。

- n-wayレプリケーション環境を構成する場合は、これらのプロシージャを使用して環境を構成しないでください。これらのプロシージャを使用すると、変更の循環が発生する可能性があります。

注意:
現在、これらの構成プロシージャでは、変更を取得する取得プロセスのみを構成します。これらのプロシージャを使用して、同期取得を使用するレプリケーション環境を構成することはできません。同期取得を構成するには、DBMS_STREAMS_ADMパッケージのADD_TABLE_RULESおよびADD_SUBSET_RULESプロシージャを使用します。

関連項目:

- DBMS_STREAMS_ADMパッケージのプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- 第10章「Oracle Streamsタグ」

- 「どのタイプのレプリケーション環境を構成するかの決定」

- 『Oracle Streams概要および管理』

構成プロシージャに関する重要な考慮事項

この項では、構成プロシージャに関する重要な考慮事項について説明します。また、これらの考慮事項に関連するいくつかのプロシージャ・パラメータについても説明します。

この項の内容は次のとおりです。

- ソース・データベースに対するローカル取得またはダウンストリーム取得

- 構成アクションの直接実行またはスクリプトを使用した実行

- これらのプロシージャによって構成されたOracle Streamsコンポーネント

- 一方向または双方向のレプリケーション

- データ定義言語(DDL)変更

- インスタンス化

関連項目:
これらのプロシージャのすべてのパラメータの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

ソース・データベースに対するローカル取得またはダウンストリーム取得

この項のプロシージャでは、source_databaseパラメータに指定したデータベースに対してローカル取得またはダウンストリーム取得のいずれかを構成できます。ソース・データベースに対する変更を取得するデータベースは、取得データベースと呼ばれます。詳細は、「ソース・データベースに対してローカル取得またはダウンストリーム取得を構成するかどうかの決定」を参照してください。

プロシージャが実行されるデータベースは、ソース・データベースに対する変更の取得データベースとして構成されます。そのため、ソース・データベースでのローカル取得を構成するには、ソース・データベースでプロシージャを実行します。宛先データベースでダウンストリーム取得を構成するには、destination_databaseパラメータに指定されているデータベースでプロシージャを実行します。第3のデータベースでダウンストリーム取得を構成するには、source_databaseパラメータまたはdestination_databaseパラメータに指定されていないデータベースでプロシージャを実行します。

ソース・データベースまたは第3のデータベースを取得データベースに使用する場合、この項のプロシージャでは、取得データベースから宛先データベースに変更を送信するように伝播が構成されます。宛先データベースを取得データベースに使用して、双方向のレプリケーションを構成しない場合、データベース間でのこの伝播は不要です。この場合、capture_queue_nameパラメータとapply_queue_nameパラメータの値が同じであると、伝播は構成されません。これらの値が異なる場合は、宛先データベース内の2つのキュー間に伝播が構成されます。

注意:

- この項のプロシージャでダウンストリーム取得を構成すると、常にアーカイブ・ログ・ダウンストリーム取得が構成されます。これらのプロシージャでは、リアルタイム・ダウンストリーム取得は構成されません。ただし、プロシージャを実行する前にリアルタイム・ダウンストリーム取得用のREDO転送サービスを構成して、プロシージャの完了後にdownstream_real_time_mine取得プロセス・パラメータをYに設定することができます。また、これらのプロシージャによって生成されるスクリプトを、リアルタイム・ダウンストリーム取得を構成するように変更することもできます。

- この項のプロシージャで双方向のレプリケーションを構成する場合、宛先データベースの取得プロセスは、常にローカル取得プロセスになります。つまり、これらのプロシージャでは、常に宛先データベースに対する変更の取得プロセスが宛先データベースで実行されるように構成されます。

- 同期取得は構成プロシージャでは構成できません。

関連項目:

- 双方向のレプリケーションの詳細は、「1つのデータベースまたは複数のデータベースで変更を許可するかどうかの決定」および「一方向または双方向のレプリケーション」を参照してください。

- 「これらのプロシージャによって構成されたOracle Streamsコンポーネント」

- ローカル取得およびダウンストリーム取得の詳細は、『Oracle Streams概要および管理』を参照してください。

構成アクションの直接実行またはスクリプトを使用した実行

この項のプロシージャでは、Oracle Streamsレプリケーション環境を直接構成するか、または環境を構成するスクリプトを生成できます。スクリプトを実行するよりプロシージャを使用してレプリケーションを直接構成する方が簡単で、環境が即時に構成されます。ただし、次の理由でスクリプトを生成することもあります。

- 環境を構成する前にプロシージャによって実行される操作を確認する必要がある。

- 構成をカスタマイズするためにスクリプトを変更する必要がある。

たとえば、適用プロセスで、特定の表に変更を適用する前に、適用ハンドラを使用してこれらの変更にカスタマイズされた処理を行う場合があります。この場合、プロシージャを使用してスクリプトを生成し、適用ハンドラを追加するようにスクリプトを変更できます。

また、複数の表に対するDML変更をメンテナンスするが、これらの表のサブセットに対してのみDDL変更をメンテナンスする場合があります。この場合、include_ddlパラメータをFALSEに設定してMAINTAIN_TABLESプロシージャを実行することによって、スクリプトを生成できます。適切な表に対するDDL変更をメンテナンスするようにスクリプトを変更できます。

perform_actionsパラメータは、プロシージャでレプリケーション環境を直接構成するかどうかを制御します。

- この項のいずれかのプロシージャを実行する際にOracle Streams環境を直接構成する場合は、perform_actionsパラメータをTRUEに設定します。このパラメータのデフォルト値はTRUEです。

- この項のいずれかのプロシージャを実行する際に構成スクリプトを生成する場合は、perform_actionsパラメータをFALSEに設定し、script_nameおよびscript_directory_objectパラメータを使用して構成スクリプトの名前と格納場所を指定します。

注意:
script_directory_objectパラメータは、自動ストレージ管理(ASM)ディスク・グループをポイントできません。

関連項目:

- 「レプリケーション環境で適用ハンドラを使用するかどうかの決定」

- 「データ定義言語(DDL)変更」

これらのプロシージャによって構成されたOracle Streamsコンポーネント

これらのプロシージャでは、次のOracle Streamsクライアントが構成されます。

- これらのプロシージャでは、ソース・データベースに対する変更を取得する取得プロセスが構成されます。双方向のレプリケーションが構成される場合は、宛先データベースに対する変更を取得する取得プロセスも構成されます。

- 取得データベースと宛先データベースが異なる場合、これらのプロシージャでは、取得データベースから宛先データベースに変更を送信する伝播が構成されます。

- 取得データベースと宛先データベースが同じ場合、伝播が作成されるかどうかはキュー名によって決まります。

- capture_queue_nameパラメータとapply_queue_nameパラメータで異なるキュー名を指定すると、宛先データベース内の2つのキュー間に伝播が作成されます。

- capture_queue_nameパラメータとapply_queue_nameパラメータで同じキュー名を指定すると、伝播は作成されず、ダウンストリーム取得プロセスと適用プロセスで同じキューが使用されます。この構成は、bi_directionalをFALSEに設定して単一ソース・レプリケーション環境を構成している場合にのみ可能です。

- 双方向のレプリケーションが構成される場合、これらのプロシージャでは、宛先データベースからソース・データベースに変更を送信する伝播が構成されます。

- これらのプロシージャでは、宛先データベースで変更を適用する適用プロセスが構成されます。これらの変更は、ソース・データベースで発生したものです。双方向のレプリケーションが構成される場合は、ソース・データベースに変更を適用する適用プロセスも構成されます。これらの変更は、宛先データベースで発生したものです。

デフォルトでは、capture_queue_nameパラメータとapply_queue_nameパラメータはNULLに設定されます。これらのパラメータがNULLに設定されている場合、これらのプロシージャでは、各取得プロセスおよび適用プロセスに対して別々のキューが構成されます。Oracle Streamsクライアントごとに別々の独自のキューが含まれていると、Oracle Streamsレプリケーション環境がより効率的に動作することがあります。

ただし、次の構成では、2つのOracle Streamsクライアントでキューが共有されます。

- 宛先データベースのダウンストリーム取得プロセスと適用プロセスでキューが共有される構成(この項の前述の説明を参照)

- 次のすべての条件が該当する構成

- 取得データベースがソース・データベースまたは第3のデータベースである。

- bi_directionalパラメータがTRUEに設定されている。

- capture_queue_nameパラメータとapply_queue_nameパラメータに同じキュー名が指定されている。

この場合、宛先データベースのローカル取得プロセスと適用プロセスで同じキューが共有されます。ソース・データベースが取得データベースの場合は、ソース・データベースのローカル取得プロセスと適用プロセスでも同じキューが共有されます。

また、次の両方の条件に該当する場合、capture_nameおよびcapture_queue_nameパラメータをNULLに設定する必要があります。

- 宛先データベースを取得データベースに使用する。

- bi_directionalパラメータがTRUEに設定されている。

これらの両方の条件に該当する場合、この項のプロシージャでは宛先データベースで2つの取得プロセスが構成されるため、これらの取得プロセスには異なる名前を付ける必要があります。一方の取得プロセスがソース・データベースのダウンストリーム取得プロセスになり、もう一方の取得プロセスが宛先データベースに対する変更を取得するローカル取得プロセスになります。capture_nameおよびcapture_queue_nameパラメータがNULLに設定されている場合、これらの取得プロセスに対してシステムによって異なる名前が生成されます。両方の条件に該当し、capture_nameパラメータまたはcapture_queue_nameパラメータのいずれかがNULL以外の値に設定されている場合、この項のプロシージャでエラーが発生します。

関連項目:

- 「一方向または双方向のレプリケーション」

- 「ソース・データベースに対するローカル取得またはダウンストリーム取得」

一方向または双方向のレプリケーション

この項のプロシージャでは、source_databaseパラメータで指定されたデータベースをソース・データベースとする一方向(単一ソース)のOracle Streams構成、または両方のデータベースをソース・データベースと宛先データベースとする双方向のOracle Streams構成のいずれかが設定されます。詳細は、「1つのデータベースまたは複数のデータベースで変更を許可するかどうかの決定」を参照してください。

Oracle Streams構成を単一ソースとするか双方向とするかは、各プロシージャのbi_directionalパラメータで制御されます。

- bi_directionalパラメータをFALSEに指定した場合、取得プロセスがソース・データベースに対する変更を取得し、適用プロセスが宛先データベースでそれらの変更を適用します。宛先データベースを取得データベースに使用しない場合、伝播によって、取得された変更が宛先データベースに送信されます。このパラメータのデフォルト値はFALSEです。

- bi_directionalパラメータをTRUEに設定した場合、個別の取得プロセスが各データベースに対する変更を取得し、伝播によってこれらの変更が他のデータベースに送信され、各データベースで他のデータベースからの変更が適用されます。

レプリケーション環境が双方向ではなく、宛先データベースで変更が許可されていない場合、Oracle Streamsはデータベース間で共有データベース・オブジェクトの同期化を保持します。ただし、レプリケーション環境が双方向ではなく、宛先データベースで独立した変更が許可されている場合、データベース間で共有データベース・オブジェクトが異なる場合があります。独立した変更は、ユーザー、アプリケーション、または第3のデータベースを含むレプリケーションによって行われます。

注意:

- 双方向のレプリケーションを構成する場合、競合解消の構成が必要な場合があります。

- この項のいずれかのプロシージャを実行する際にbi_directionalパラメータをTRUEに設定した場合、プロシージャまたはプロシージャによって生成されたスクリプトの実行中に、宛先データベースの共有データベース・オブジェクトに対するデータ操作言語(DML)変更またはデータ定義言語(DDL)変更を許可しないでください。プロシージャで単一ソース・レプリケーション環境を構成する場合は、この制限は適用されません。

- これらのプロシージャでは、レプリケート表は宛先データベースで読取り専用に構成されません。これらのいずれかのプロシージャを実行する際にbi_directionalパラメータをFALSEに設定し、レプリケート表を宛先データベースで読取り専用にする場合は、必要に応じて宛先データベースで権限を構成してください。ただし、適用プロセスの適用ユーザーは、レプリケートされたデータベース・オブジェクトに対するDML変更を行うことができる必要があります。権限を構成する方法は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

関連項目:

- 第9章「Oracle Streamsの競合解消」

- 「これらのプロシージャによって構成されたOracle Streamsコンポーネント」

変更の循環とタグ

変更の循環は、変更が発生場所であるデータベースに再送されると発生します。通常は、それぞれの変更が無限ループを介して発生場所であるデータベースに送信される可能性があるため、変更の循環を回避する必要があります。このようなループがあると、データベースに意図しないデータが格納され、環境のネットワーキング・リソースとコンピュータ・リソースが過剰に使用される可能性があります。

bi_directionalパラメータがTRUEに設定されている場合、これらのプロシージャでは双方向のレプリケーションが構成されます。また、双方向のOracle Streamsレプリケーション環境で変更の循環を回避するために、次のように環境が構成されます。

- 各データベースの適用プロセスによって、環境に固有の適用タグを持つ各変更が適用されます。適用タグとは、適用プロセスによって作成される各REDOレコードの一部であるOracle Streamsタグのことです。たとえば、プロシージャで双方向のレプリケーション用にデータベースsfdb.netおよびnydb.netを構成する場合、sfdb.netの適用プロセスの適用タグは'1'と等価の16進値になり、nydb.netの適用プロセスの適用タグは'2'と等価の16進値になります。この場合、適用された変更のタグが'1'と等価の16進値である場合、その変更はnydb.netデータベースで発生したものであり、適用された変更のタグが'2'と等価の16進値である場合、その変更はsfdb.netで発生したものになります。

- 各データベースの取得プロセスによって、共有データベース・オブジェクトに対するすべての変更が取得されます。この取得は、それらのデータベース・オブジェクトに対する変更のREDOレコード内のタグに関係なく行われます。

- 各伝播によって、共有データベース・オブジェクトに対するすべての変更(他のデータベースで発生した変更は除く)が双方向レプリケーション環境の他のデータベースに送信されます。前述の例にあてはめると、sfdb.netでの伝播によって、タグ値が'1'と等価の16進値である変更を除くすべての変更がnydb.netに送信されます(これらの変更はnydb.netで発生したものであるためです)。同様に、nydb.netでの伝播によって、タグ値が'2'と等価の16進値である変更を除くすべての変更がsfdb.netに送信されます。タグ値が原因で伝播されない変更は破棄されます。

この項のプロシージャを使用して、環境内の第3のデータベースによってソース・データベースに変更が循環される複数方向のレプリケーションを構成することはできません。たとえば、これらのプロシージャを使用して、3つのデータベースによってそれぞれ環境内の他の2つのデータベースと変更が共有されるOracle Streamsレプリケーション環境を構成することはできません。このような環境は、n-wayレプリケーション環境と呼ばれることがあります。これらのプロシージャを使用してこのタイプの3方向のレプリケーション環境を構成すると、ソース・データベースに加えられた変更は、同じソース・データベースに循環されます。有効な3方向のレプリケーション環境では、特定の変更は各データベースに一度のみ行われます。

これらのプロシージャでは、ソース・データベースで行われた変更が循環して同じソース・データベースに戻らない場合、3つ以上のデータベースを含むOracle Streamsレプリケーション環境を構成できます。たとえば、プロシージャを複数回実行して、プライマリ・データベースが複数のセカンダリ・データベースと変更を共有する環境を構成できます。このような環境は、ハブ・アンド・スポーク・レプリケーション環境と呼ばれることがあります。

各ソース・データベースが他のソース・データベースと変更を共有する複数ソース環境で変更をレプリケートするように、Oracle Streams環境を手動で構成できます。また、生成されたスクリプトを変更してこの操作を行うこともできます。

関連項目:

- 第10章「Oracle Streamsタグ」

- ハブ・アンド・スポーク・レプリケーション環境を構成する例については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

- 『Oracle Streams拡張例』

データ定義言語(DDL)変更

include_ddlパラメータは、DDL変更をメンテナンスするようにプロシージャでOracle Streamsレプリケーションを構成するかどうかを制御します。

- DDL変更をメンテナンスしないOracle Streamsレプリケーション環境を構成するには、この項のいずれかのプロシージャを実行する際に、include_ddlパラメータをFALSEに設定します。このパラメータのデフォルト値はFALSEです。

- DDL変更をメンテナンスするOracle Streamsレプリケーション環境を構成するには、この項のいずれかのプロシージャを実行する際に、include_ddlパラメータをTRUEに設定します。

注意:
MAINTAIN_SIMPLE_TTSプロシージャにはinclude_ddlパラメータは含まれません。MAINTAIN_SIMPLE_TTSプロシージャで構成するOracle Streamsレプリケーション環境では、DML変更のみがメンテナンスされます。

関連項目:
「DDL変更をメンテナンスするかどうかの決定」

インスタンス化

MAINTAIN_GLOBAL、MAINTAIN_SCHEMASおよびMAINTAIN_TABLESプロシージャでは、インスタンス化のオプションが提供されます。インスタンス化とは、ソース・データベースでデータベース・オブジェクトをインスタンス化のために準備するプロセスであり、オプションで、データベース・オブジェクトをソース・データベースから宛先データベースにコピーしたり、インスタンス化された各データベース・オブジェクトにインスタンス化SCNを設定します。

これら3つのプロシージャのいずれかを実行する場合、次のいずれかの方法でインスタンス化を実行するように選択できます。

- データ・ポンプ・エクスポート・ダンプ・ファイルによるインスタンス化: このオプションでは、ソース・データベースで共有データベース・オブジェクトにデータ・ポンプでのエクスポートが実行され、宛先データベースでエクスポート・ダンプ・ファイルのデータ・ポンプでのインポートが実行されます。インポート時に各共有データベース・オブジェクトに対してインスタンス化SCNが設定されます。
このインスタンス化オプションを指定するには、instantiationパラメータを次のいずれかの値に設定します。

- MAINTAIN_GLOBALプロシージャを実行する場合はDBMS_STREAMS_ADM.INSTANTIATION_FULL

- MAINTAIN_SCHEMASプロシージャを実行する場合はDBMS_STREAMS_ADM.INSTANTIATION_SCHEMA

- MAINTAIN_TABLESプロシージャを実行する場合はDBMS_STREAMS_ADM.INSTANTIATION_TABLE

bi_directionalパラメータがTRUEに設定されている場合、プロシージャでは、ソース・データベースの各共有データベース・オブジェクトに対してもインスタンス化SCNが設定されます。

このオプションを使用する場合は、データ・ポンプ・ファイルを保持するためのディレクトリ・オブジェクトを作成する必要があります。「必要なディレクトリ・オブジェクトの作成」を参照してください。

- データ・ポンプでのネットワーク・インポートによるインスタンス化: このオプションでは、共有データベース・オブジェクトのデータ・ポンプでのネットワーク・インポートが実行されます。ネットワーク・インポートとは、エクスポート・ダンプ・ファイルを使用せずにデータ・ポンプでインポートを実行することを意味します。したがって、このオプションを使用する場合、インスタンス化のためにディレクトリ・オブジェクトを作成する必要はありません。インポート時に各共有データベース・オブジェクトに対してインスタンス化SCNが設定されます。
このインスタンス化オプションを指定するには、instantiationパラメータを次のいずれかの値に設定します。

- MAINTAIN_GLOBALプロシージャを実行する場合はDBMS_STREAMS_ADM.INSTANTIATION_FULL_NETWORK

- MAINTAIN_SCHEMASプロシージャを実行する場合はDBMS_STREAMS_ADM.INSTANTIATION_SCHEMA_NETWORK

- MAINTAIN_TABLESプロシージャを実行する場合はDBMS_STREAMS_ADM.INSTANTIATION_TABLE_NETWORK

bi_directionalパラメータがTRUEに設定されている場合、プロシージャでは、ソース・データベースの各共有データベース・オブジェクトに対してもインスタンス化SCNが設定されます。

- インスタンス化を指定しない構成スクリプトの生成: このオプションでは、インスタンス化は実行されません。この設定は、perform_actionsパラメータがFALSEに設定されており、プロシージャで構成スクリプトを生成する場合にのみ有効です。この場合、構成スクリプトではインスタンス化が実行されず、各共有データベース・オブジェクトに対してインスタンス化SCNが設定されません。かわりに、自分でインスタンス化を実行し、インスタンス化SCNの値が適切に設定されていることを確認する必要があります。
このインスタンス化オプションを指定するには、各プロシージャでinstantiationパラメータをDBMS_STREAMS_ADM.INSTANTIATION_NONEに設定します。

これらのいずれかのプロシージャで表のインスタンス化を実行する場合は、宛先データベースにその表を含む表領域が存在している必要があります。これらのいずれかのプロシージャでスキーマのインスタンス化を実行する場合は、宛先データベースにそのスキーマを含む表領域が存在している必要があります。

これらのプロシージャでダンプ・ファイルまたはネットワークのインスタンス化を実行すると、インスタンス化されたデータベース・オブジェクトが宛先データベースに存在しない場合、宛先データベースにデータベース・オブジェクトがインポートされますが、これには、ソース・データベースからのサプリメンタル・ロギング指定およびサポート・データベース・オブジェクト(索引、トリガーなど)が含まれます。ただし、インスタンス化の実行前に宛先データベースにデータベース・オブジェクトがすでに存在する場合は、宛先データベースにデータベース・オブジェクトはインポートされません。このため、ソース・データベースからのサプリメンタル・ロギング指定は宛先データベースのデータベース・オブジェクトに指定されず、サポート・データベース・オブジェクトはインポートされません。

PRE_INSTANTIATION_SETUPおよびPOST_INSTANTIATION_SETUPプロシージャでは、インスタンス化が実行されません。必要なインスタンス化操作を、PRE_INSTANTIATION_SETUPの実行後およびPOST_INSTANTIATION_SETUPの実行前に手動で実行する必要があります。また、instantiationパラメータをDBMS_STREAMS_ADM.INSTANTIATION_NONEに設定してMAINTAIN_GLOBAL、MAINTAIN_SCHEMASおよびMAINTAIN_TABLESプロシージャを使用した場合も、必要なインスタンス化操作を手動で実行する必要があります。

これらの場合、任意のインスタンス化方法を使用できます。たとえば、Recovery Manager(RMAN)のDUPLICATEまたはCONVERT DATABASEコマンドを使用してデータベースをインスタンス化したり、RMANのTRANSPORT TABLESPACEコマンドを使用して表領域をインスタンス化することができます。bi_directionalパラメータがTRUEに設定されている場合、ソース・データベースおよび宛先データベースでインスタンス化SCNの値が適切に設定されていることを確認します。

注意:

- MAINTAIN_SIMPLE_TTSおよびMAINTAIN_TTSプロシージャでは、これらのインスタンス化オプションは提供されません。これらのプロシージャでは、表領域または表領域セットがクローニングされ、インスタンス化に必要なファイルが宛先データベースに送信され、宛先データベースで表領域または表領域セットがアタッチされることによって、常にインスタンス化が実行されます。

- これらのいずれかのプロシージャでインスタンス化を実行する場合は、ソース・データベースにレプリケーションに対して構成するデータベース・オブジェクト、表領域または表領域セットが存在している必要があります。

- データベースのインスタンス化にRMANのDUPLICATEまたはCONVERT DATABASEコマンドを使用する場合、宛先データベースを取得データベースに使用できません。

- MAINTAIN_TABLESプロシージャでダンプ・ファイルまたはネットワークのインスタンス化を実行すると、インスタンス化の実行前にインスタンス化された表が宛先データベースに存在する場合は、このプロシージャによって表に対するインスタンス化SCNは設定されません。この場合は、プロシージャの完了後に表に対するインスタンス化SCNを手動で設定する必要があります。

関連項目:

- 第8章「インスタンス化とOracle Streamsレプリケーション」

- 「構成アクションの直接またはスクリプトを使用した実行」

- 「一方向または双方向のレプリケーション」

必要なディレクトリ・オブジェクトの作成

ディレクトリ・オブジェクトは、ファイル・システム上のディレクトリの別名に類似しています。この項のいずれかのプロシージャを実行する場合、次のディレクトリ・オブジェクトが必要になる場合があります。

- スクリプト・ディレクトリ・オブジェクトは、構成スクリプトを生成する場合に必要です。構成スクリプトは、プロシージャが実行されるコンピュータ・システム上のこのディレクトリに格納されます。これらのいずれかのプロシージャを実行してスクリプト・ディレクトリ・オブジェクトを指定する場合、script_directory_objectパラメータを使用します。

- ソース・ディレクトリ・オブジェクトは、データ・ポンプ・エクスポート・ダンプ・ファイルによるインスタンス化を実行し、MAINTAIN_GLOBAL、MAINTAIN_SCHEMAS、MAINTAIN_SIMPLE_TTS、MAINTAIN_TABLESまたはMAINTAIN_TTSのいずれかのプロシージャを使用する場合に必要です。データ・ポンプ・エクスポート・ダンプ・ファイルおよびログ・ファイルは、ソース・データベースが実行されるコンピュータ・システム上のこのディレクトリに格納されます。これらのいずれかのプロシージャを実行してソース・ディレクトリ・オブジェクトを指定する場合、source_directory_objectパラメータを使用します。PRE_INSTANTIATION_SETUPおよびPOST_INSTANTIATION_SETUPプロシージャを使用する場合、このディレクトリ・オブジェクトは不要です。

- 接続先ディレクトリ・オブジェクトは、データ・ポンプ・エクスポート・ダンプ・ファイルによるインスタンス化を実行し、MAINTAIN_GLOBAL、MAINTAIN_SCHEMAS、MAINTAIN_SIMPLE_TTS、MAINTAIN_TABLESまたはMAINTAIN_TTSのいずれかのプロシージャを使用する場合に必要です。ソース・データベースが実行されているコンピュータ・システムから宛先データベースが実行されているコンピュータ・システムにデータ・ポンプ・エクスポート・ダンプ・ファイルが転送され、宛先データベースが実行されているコンピュータ・システム上のこのディレクトリに格納されます。これらのいずれかのプロシージャを実行して接続先ディレクトリ・オブジェクトを指定する場合、destination_directory_objectパラメータを使用します。PRE_INSTANTIATION_SETUPおよびPOST_INSTANTIATION_SETUPプロシージャを使用する場合、このディレクトリ・オブジェクトは不要です。

各ディレクトリ・オブジェクトは、SQL文CREATE DIRECTORYを使用して作成する必要があります。また、いずれかのプロシージャをコールするユーザーは、各ディレクトリ・オブジェクトに対するREADおよびWRITE権限を持っている必要があります。

たとえば、次の手順を実行し、/usr/db_filesディレクトリに対応するディレクトリ・オブジェクトdb_dirを作成します。

1. SQL*Plusで、Oracle Streams管理者としてデータベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

2. 次のように、ディレクトリ・オブジェクトを作成します。

CREATE DIRECTORY db_dir AS '/usr/db_files';

ディレクトリ・オブジェクトを作成するユーザーには、ディレクトリ・オブジェクトに対するREAD権限およびWRITE権限が自動的に付与されます。Oracle Streamsレプリケーション環境を構成している場合は、通常Oracle Streams管理者がディレクトリ・オブジェクトを作成します。

注意:
ディレクトリ・オブジェクトは、自動ストレージ管理(ASM)ディスク・グループをポイントできません。

関連項目:

- 「構成アクションの直接またはスクリプトを使用した実行」

- 「インスタンス化」

ローカル取得を使用した2データベース・レプリケーションを構成する場合の例

次の各例では、1つ以上のローカル取得プロセスを使用した2データベース・レプリケーション環境を構成します。

- ローカル取得を使用した2データベース・グローバル・レプリケーションの構成

- ローカル取得を使用した2データベース・スキーマ・レプリケーションの構成

- ローカル取得を使用した2データベース表レプリケーションの構成

ローカル取得を使用した2データベース・グローバル・レプリケーションの構成

DBMS_STREAMS_ADMパッケージの次のプロシージャを使用すると、データベース・レベルでレプリケーションを構成できます。

- MAINTAIN_GLOBAL

- PRE_INSTANTIATION_SETUPおよびPOST_INSTANTIATION_SETUP

MAINTAIN_GLOBALプロシージャでは、Oracle Streamsによってサポートされていないデータベース・オブジェクトがレプリケーション環境からは自動的に除外されます。PRE_INSTANTIATION_SETUPおよびPOST_INSTANTIATION_SETUPプロシージャでは、データベース・オブジェクトが自動的に除外されません。かわりに、これらのプロシージャを使用すると、レプリケーション環境から除外するデータベース・オブジェクトを指定できます。Oracle Streamsによってサポートされていないデータベース・オブジェクトを判別するには、DBA_STREAMS_UNSUPPORTEDデータ・ディクショナリ・ビューを問い合せます。サポートされていないデータベース・オブジェクトが除外されていない場合、取得エラーが発生します。

次の表では、この例で構成されたOracle Streamsレプリケーション環境に関して行った決定を示します。

決定

この例の前提

どのタイプのレプリケーション環境を構成するかの決定

この例では、両方のデータベースが読取り/書込み可能な2データベース環境における双方向のレプリケーションを構成します。

ソース・データベースに対してローカル取得またはダウンストリーム取得を構成するかどうかの決定

この例では、各ソース・データベースに対してローカル取得を構成します。

1つのデータベースまたは複数のデータベースで変更を許可するかどうかの決定

この例では、両方のデータベースにおいてレプリケートされたデータベース・オブジェクトへの変更が可能です。

レプリケーション環境に異なるレプリカを含めるかどうかの決定

この例では、複数のデータベースで同じ共有データベース・オブジェクトを構成します。

レプリケーション環境で適用ハンドラを使用するかどうかの決定

この例では、適用ハンドラを構成しません。

DDL変更をメンテナンスするかどうかの決定

この例では、DDL変更をメンテナンスします。

レプリケーション環境の構成方法の決定

この例では、PRE_INSTANTIATION_SETUPおよびPOST_INSTANTIATION_SETUPプロシージャを使用して環境を構成します。

この例では、プロシージャでレプリケーション環境を直接構成します。構成スクリプトは生成されません。RMANによるデータベースのインスタンス化を実行します。

前述の表で示されているように、この例では、PRE_INSTANTIATION_SETUPおよびPOST_INSTANTIATION_SETUPプロシージャを使用してデータベース・レプリケーションを構成します。レプリケーション構成では、Oracle Streamsによってサポートされていないすべてのデータベースが除外されます。この例では、ソース・データベースはdbs1.example.com、宛先データベースはdbs2.example.comです。

図2-1に、この例で作成されるレプリケーション環境の概要を示します。

図2-1 データベース全体をレプリケートするOracle Streams環境の例

注意:
取得プロセスでは、SYS、SYSTEMまたはCTXSYSスキーマ内の変更は取得されません。これらのスキーマに対する変更は、この項で説明するレプリケーション環境でOracle Streamsによってメンテナンスされません。

関連項目:
Oracle Streamsによってサポートされていないデータベース・オブジェクトを判別する手順については、『Oracle Streams概要および管理』を参照してください。

次の手順を実行して、PRE_INSTANTIATION_SETUPおよびPOST_INSTANTIATION_SETUPプロシージャを使用してレプリケーション環境を構成します。

1. PRE_INSTANTIATION_SETUPプロシージャを実行する前に必要なタスクを実行します。手順については、「Oracle Streamsレプリケーションを構成する前に実行するタスク」を参照してください。

この構成について、次のタスクを実行する必要があります。

- 両方のデータベースでOracle Streams管理者を構成します。「すべてのデータベースでのOracle Streams管理者の構成」を参照してください。

- ネットワーク接続性とデータベース・リンクの構成は、次のとおりです。

- ソース・データベースdbs1.example.comと宛先データベースdbs2.example.comとの間で、ネットワーク接続を構成します。

- ソース・データベースdbs1.example.comから宛先データベースdbs2.example.comへのデータベース・リンクを作成します。

「ネットワーク接続性とデータベース・リンクの構成」を参照してください。

- 両方のデータベースがARCHIVELOGモードであることを確認します。「各ソース・データベースがARCHIVELOGモードであることの確認」を参照してください。

- 両方のデータベースの初期化パラメータが適切に設定されていることを確認します。「Oracle Streamsに関連する初期化パラメータの設定」を参照してください。

- 両方のデータベースでOracle Streamsプールを適切に構成します。「Oracle Streamsプールの構成」を参照してください。

宛先データベースからソース・データベースへのデータベース・リンクが必要です。ただし、データベースのインスタンス化にRMANが使用されるため、インスタンス化の後にこのデータベース・リンクを作成する必要があります。レプリケーション環境が双方向であり、データベースのインスタンス化にRMANが使用されるため、このデータベース・リンクが必要です。

2. SQL*Plusで、Oracle Streams管理者としてソース・データベースdbs1.example.comに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

3. PRE_INSTANTIATION_SETUPプロシージャを実行します。

DECLARE
empty_tbs  DBMS_STREAMS_TABLESPACE_ADM.TABLESPACE_SET;
BEGIN
DBMS_STREAMS_ADM.PRE_INSTANTIATION_SETUP(
maintain_mode        => 'GLOBAL',
tablespace_names     => empty_tbs,
source_database      => 'dbs1.example.com',
destination_database => 'dbs2.example.com',
perform_actions      => TRUE,
bi_directional       => TRUE,
include_ddl          => TRUE,
start_processes      => TRUE,
exclude_schemas      => '*',
exclude_flags        => DBMS_STREAMS_ADM.EXCLUDE_FLAGS_UNSUPPORTED +
DBMS_STREAMS_ADM.EXCLUDE_FLAGS_DML +
DBMS_STREAMS_ADM.EXCLUDE_FLAGS_DDL);
END;
/

start_processesパラメータがTRUEに設定されていることに注意してください。したがって、構成中に作成される各取得プロセスおよび適用プロセスは、自動的に起動されます。

また、exclude_schemasおよびexclude_flagsパラメータに指定されている値に注意してください。exclude_schemasに指定されているアスタリスク(*)は、データベース内の各スキーマの特定のデータベース・オブジェクトがレプリケーション環境から除外されることを示します。exclude_flagsパラメータに指定されている値は、サポートされていないすべてのデータベース・オブジェクトに対するDML変更およびDDL変更がレプリケーション環境から除外されることを示します。ルールは、これらのデータベース・オブジェクトを除外するために取得プロセスのネガティブ・ルール・セットに入れられます。

プロシージャはソース・データベースで実行されるため、ソース・データベースでローカル取得が構成されます。

このプロシージャでは双方向のレプリケーション環境が構成されるため、プロシージャの実行中に宛先データベースの共有データベース・オブジェクトに対するDML変更またはDDL変更を許可しないでください。

プロシージャには、apply_nameパラメータを指定しません。したがって、このパラメータには、デフォルトでNULLが指定されます。apply_nameパラメータをNULLに設定すると、ソース・データベースからの変更を適用する適用プロセスは、宛先データベース上に存在することができません。ソース・データベースからの変更を適用する適用プロセスが宛先データベースに存在する場合、NULLでない値をapply_nameパラメータに指定します。

構成操作の進捗を監視するには、「Oracle Streams構成の進捗の監視」の手順に従います。

このプロシージャでエラーが発生してプロシージャが停止した場合、エラーからのリカバリまたは構成操作のロールバックを実行する方法の詳細は、「操作エラーからのリカバリ」を参照してください。

4. インスタンス化を実行します。第8章「インスタンス化とOracle Streamsレプリケーション」で説明されているいずれの方法でもインスタンス化を実行できます。この例では、次の手順を実行することによって、RMANのDUPLICATEコマンドを使用してインスタンス化を実行します。

1. ソース・データベースのバックアップを作成します(存在しない場合)。RMANには、複製用に有効なバックアップが必要です。この例では、dbs1.example.comのバックアップが存在しない場合は作成します。

注意:
RMANのDUPLICATEコマンドを実行する際にFROM ACTIVE DATABASEオプションを使用する場合、ソース・データベースのバックアップは不要です。大規模なデータベースでは、FROM ACTIVE DATABASEオプションの実行に大量のネットワーク・リソースが必要になります。この例では、このオプションは使用しません。

2. SQL*Plusで、Oracle Streams管理者としてソース・データベースdbs1.example.comに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

3. RMANのDUPLICATEコマンドに指定する終了SCNを判断します。

SET SERVEROUTPUT ON SIZE 1000000
DECLARE
until_scn NUMBER;
BEGIN
until_scn:= DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER;
DBMS_OUTPUT.PUT_LINE('Until SCN: ' || until_scn);
END;
/

戻された終了SCNをメモします。この番号は手順hで使用します。この例では、戻された終了SCNが45442631であると想定します。

4. SQL*Plusで、管理ユーザーとしてソース・データベースdbs1.example.comに接続します。

5. 現行のオンラインREDOログをアーカイブします。

ALTER SYSTEM ARCHIVE LOG CURRENT;

6. データベースの複製用に環境を準備します。宛先データベースを複製の補助インスタンスとして準備します。手順については、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

7. RMANクライアントを起動し、TARGETとしてソース・データベースdbs1.example.com、AUXILIARYとして宛先データベースdbs2.example.comに接続します。

関連項目:
RMANのCONNECTコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

8. OPEN RESTRICTEDオプションを指定してRMANのDUPLICATEコマンドを実行し、宛先データベースでソース・データベースをインスタンス化します。OPEN RESTRICTEDオプションは必須です。このオプションを指定すると、SQL文ALTER SYSTEM ENABLE RESTRICTED SESSIONを発行することによって、複製データベースで制限付きセッションを有効にできます。RMANは、複製データベースがオープンされる直前にこの文を発行します。

UNTIL SCN句を使用して、複製用のSCNを指定できます。この句には、手順cで判断した終了SCNを使用します。アーカイブREDOログは、指定した終了SCN値以上で使用可能である必要があります。したがって、手順eでは、終了SCNを含むREDOログをアーカイブしています。

DUPLICATEコマンドのTO database_name に、複製データベースの名前を指定していることを確認してください。この例では、複製データベースはdbs2.example.comです。したがって、この例のDUPLICATEコマンドにはTO dbs2.example.comが含まれます。

次に、RMANのDUPLICATEコマンドの例を示します。

RMAN> RUN
{
SET UNTIL SCN 45442631;
ALLOCATE AUXILIARY CHANNEL dbs2 DEVICE TYPE sbt;
DUPLICATE TARGET DATABASE TO dbs2
NOFILENAMECHECK
OPEN RESTRICTED;
}

関連項目:
RMANのDUPLICATEコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

9. SQL*Plusで、管理ユーザーとして宛先データベースに接続します。

10. グローバル名を変更します。RMANによるデータベースのインスタンス化を実行すると、宛先データベースはソース・データベースと同じグローバル名を持ちます。次の文を使用して、宛先データベースのグローバル名を元の名前に戻します。

ALTER DATABASE RENAME GLOBAL_NAME TO dbs2.example.com;

11. SQL*Plusで、Oracle Streams管理者として宛先データベースdbs2.example.comに接続します。

12. ソース・データベースからクローニングされた、ソース・データベースから宛先データベースへのデータベース・リンクを削除します。

DROP DATABASE LINK dbs2.example.com;

5. 宛先データベースにOracle Streams管理者として接続したままで、宛先データベースからソース・データベースにデータベース・リンクを作成します。

CREATE DATABASE LINK dbs1.example.com CONNECT TO strmadmin
IDENTIFIED BY password USING 'dbs1.example.com';

このデータベース・リンクが必要な理由については、手順1を参照してください。

6. SQL*Plusで、Oracle Streams管理者としてソース・データベースdbs1.example.comに接続します。

7. POST_INSTANTIATION_SETUPプロシージャを実行します。

DECLARE
empty_tbs  DBMS_STREAMS_TABLESPACE_ADM.TABLESPACE_SET;
BEGIN
DBMS_STREAMS_ADM.POST_INSTANTIATION_SETUP(
maintain_mode        => 'GLOBAL',
tablespace_names     => empty_tbs,
source_database      => 'dbs1.example.com',
destination_database => 'dbs2.example.com',
perform_actions      => TRUE,
bi_directional       => TRUE,
include_ddl          => TRUE,
start_processes      => TRUE,
instantiation_scn    => 45442630,
exclude_schemas      => '*',
exclude_flags        => DBMS_STREAMS_ADM.EXCLUDE_FLAGS_UNSUPPORTED +
DBMS_STREAMS_ADM.EXCLUDE_FLAGS_DML +
DBMS_STREAMS_ADM.EXCLUDE_FLAGS_DDL);
END;
/

PRE_INSTANTIATION_SETUPおよびPOST_INSTANTIATION_SETUPプロシージャの両方に指定されたパラメータ値が一致する必要があります。ただし、perform_actions、script_name、script_directory_objectおよびstart_processesは除きます。

また、instantiation_scnパラメータが45442630に設定されていることに注意してください。RMANのDUPLICATEコマンドを実行すると、UNTIL SCN句で指定したSCN値より1つ少ない値まで、データベースが複製されます。したがって、手順4hでDUPLICATEコマンドを実行した際に指定した終了SCN値から1を引く必要があります。この例では、終了SCNを45442631に設定しています。したがって、instantiation_scnパラメータは45442631 - 1の45442630に設定する必要があります。

インスタンス化中に宛先データベースの共有データベース・オブジェクトにインスタンス化SCNが設定されている場合、instantiation_scnパラメータをNULLに設定する必要があります。たとえば、全データベースのエクスポート/インポート中にインスタンス化SCNが設定される場合があります。

このプロシージャでは双方向のレプリケーション環境が構成されるため、プロシージャの実行中に宛先データベースの共有データベース・オブジェクトに対するDML変更またはDDL変更を許可しないでください。

構成操作の進捗を監視するには、「Oracle Streams構成の進捗の監視」の手順に従います。

このプロシージャでエラーが発生してプロシージャが停止した場合、エラーからのリカバリまたは構成操作のロールバックを実行する方法の詳細は、「操作エラーからのリカバリ」を参照してください。

8. SQL*Plusで宛先データベースに管理ユーザーとして接続し、ALTER SYSTEM文を実行してRESTRICTED SESSIONを無効化します。

ALTER SYSTEM DISABLE RESTRICTED SESSION;

9. 必要に応じて、共有データベース・オブジェクトの競合解消を構成します。
通常、双方向のレプリケーション環境では、競合が発生する可能性があります。PRE_INSTANTIATION_SETUPおよびPOST_INSTANTIATION_SETUPプロシージャによって作成された環境で競合が発生する可能性がある場合は、共有データベース・オブジェクトに対する変更をユーザーに許可する前に競合解消を構成します。

詳細は、第9章「Oracle Streamsの競合解消」を参照してください。

この例で構成された双方向のレプリケーション環境には、次の特性があります。

- 両方のデータベースでデータベース・サプリメンタル・ロギングが構成されています。

- dbs1.example.comデータベースには、システム生成名を持つ2つのキューおよびキュー表があります。1つのキューはローカル取得プロセス用で、もう1つのキューは適用プロセス用です。

- dbs2.example.comデータベースには、システム生成名を持つ2つのキューおよびキュー表があります。1つのキューはローカル取得プロセス用で、もう1つのキューは適用プロセス用です。

- dbs1.example.comデータベースで、システム生成名を持つ取得プロセスが、Oracle Streamsによってサポートされているデータベース内のすべてのデータベース・オブジェクトに対するDML変更およびDDL変更を取得します。

- dbs2.example.comデータベースで、システム生成名を持つ取得プロセスが、Oracle Streamsによってサポートされているデータベース内のすべてのデータベース・オブジェクトに対するDML変更およびDDL変更を取得します。

- dbs1.example.comデータベースで実行されているシステム生成名を持つ伝播が、dbs1.example.comデータベースのキューからdbs2.example.comデータベースのキューに取得された変更を送信します。

- dbs2.example.comデータベースで実行されているシステム生成名を持つ伝播が、dbs2.example.comデータベースのキューからdbs1.example.comデータベースのキューに取得された変更を送信します。

- dbs1.example.comで、システム生成名を持つ適用プロセスが、そのキューから変更をデキューしてこれらの変更をデータベース・オブジェクトに適用します。

- dbs2.example.comで、システム生成名を持つ適用プロセスが、そのキューから変更をデキューしてこれらの変更をデータベース・オブジェクトに適用します。

- タグを使用して、変更の循環が回避されます。具体的には、適用プロセスによって適用される変更のREDOレコードにタグが含まれるように、各適用プロセスで適用タグが使用されます。各適用プロセスは、レプリケーション環境で一意の適用タグを使用します。各伝播は、同じデータベースで実行されている適用プロセスのタグを持つ変更を廃棄します。詳細は、「変更の循環とタグ」を参照してください。

ローカル取得を使用した2データベース・スキーマ・レプリケーションの構成

この例では、hrスキーマのすべての表に対するデータ操作言語(DML)変更をレプリケートするOracle Streamsレプリケーション環境を構成します。この例では、ローカル取得プロセスを使用して変更を取得する2データベース・レプリケーション環境を構成します。この例では、グローバル・データベース名db1.example.comおよびdb2.example.comを使用します。ただし、使用している環境内でデータベースを置き換えて例を完成することもできます。

次の表では、この例で構成されたOracle Streamsレプリケーション環境に関して行った決定を示します。

決定

この例の前提

どのタイプのレプリケーション環境を構成するかの決定

この例では、一方向または双方向のレプリケーションを構成する手順を説明します。双方向のレプリケーションを構成するには、追加の手順を完了し、構成プロシージャの実行時にbi_directionalパラメータをTRUEに設定する必要があります。

ソース・データベースに対してローカル取得またはダウンストリーム取得を構成するかどうかの決定

この例では、ソース・データベースに対してローカル取得を構成します。

1つのデータベースまたは複数のデータベースで変更を許可するかどうかの決定

この例では、1つのデータベースまたは両方のデータベースで変更を許可するかどうかを選択できます。

レプリケーション環境に異なるレプリカを含めるかどうかの決定

この例では、複数のデータベースで同じ共有データベース・オブジェクトを構成します。

レプリケーション環境で適用ハンドラを使用するかどうかの決定

この例では、適用ハンドラを構成しません。

DDL変更をメンテナンスするかどうかの決定

この例では、DDL変更をメンテナンスします。

レプリケーション環境の構成方法の決定

この例では、MAINTAIN_SCHEMASプロシージャを使用して環境を構成します。

MAINTAIN_SCHEMASプロシージャの実行時に、宛先データベースにレプリケーション用に構成されたデータベース・オブジェクトが存在する場合と存在しない場合があります。宛先データベースにデータベース・オブジェクトが存在しない場合、MAINTAIN_SCHEMASプロシージャでは、データ・ポンプ・エクスポート/インポートを使用して宛先データベースでデータベース・オブジェクトをインスタンス化します。インスタンス化中に、これらのデータベース・オブジェクトのインスタンス化SCNが設定されます。宛先データベースにすでにデータベース・オブジェクトが存在する場合、MAINTAIN_SCHEMASプロシージャでは、既存のデータベース・オブジェクトを保持し、これらのデータベース・オブジェクトのインスタンス化SCNを設定します。この例では、MAINTAIN_SCHEMASプロシージャを実行する前に、db1.example.comデータベースとdb2.example.comデータベースの両方にhrスキーマが存在します。

この例では、MAINTAIN_SCHEMASプロシージャでレプリケーション環境を直接構成します。構成スクリプトは生成されません。データ・ポンプ・エクスポート・ダンプ・ファイルによるインスタンス化が実行されます。

図2-2に、この例で作成される環境の概要を示します。双方向のレプリケーションに必要な追加コンポーネントはグレーで表示し、これらのコンポーネントのアクションは点線で示しています。

図2-2 ローカル取得プロセスを使用した2データベース・レプリケーション環境

MAINTAIN_SCHEMASプロシージャを使用して環境を構成するには、次の手順を実行します。

1. 次のタスクを完了して、2データベース・レプリケーション環境を準備します。

1. db1.example.comデータベースがdb2.example.comデータベースと通信できるようにネットワーク接続を構成します。
データベース間のネットワーク接続の構成については、『Oracle Database 2日でデータベース管理者』を参照してください。

2. レプリケーション環境に参加する各データベースでOracle Streams管理者を構成します。手順については、「すべてのデータベースでのOracle Streams管理者の構成」を参照してください。この例では、Oracle Streams管理者がstrmadminであると想定しています。

3. db1.example.comデータベースからdb2.example.comデータベースへのデータベース・リンクを作成します。
データベース・リンクは、Oracle Streams管理者のスキーマに作成する必要があります。また、データベース・リンクは、他のデータベースのOracle Streams管理者に接続する必要があります。データベース・リンクの名前とサービス名の両方がdb2.example.comである必要があります。手順については、「ネットワーク接続性とデータベース・リンクの構成」を参照してください。

4. ARCHIVELOGモードで実行するようにdb1.example.comデータベースを構成します。取得プロセスがソース・データベースで生成された変更を取得するには、ソース・データベースをARCHIVELOGモードで実行する必要があります。ARCHIVELOGモードで実行するためのデータベースの構成の詳細は、『Oracle Database管理者ガイド』を参照してください。

2. 双方向のレプリケーション環境を構成するには、次の手順を実行します。一方向のレプリケーション環境を構成する場合は、これらの手順は必要ありませんので、手順3に進みます。

1. db2.example.comデータベースからdb1.example.comデータベースへのデータベース・リンクを作成します。
データベース・リンクは、Oracle Streams管理者のスキーマに作成する必要があります。また、データベース・リンクは、他のデータベースのOracle Streams管理者に接続する必要があります。データベース・リンクの名前とサービス名の両方がdb1.example.comである必要があります。手順については、「ネットワーク接続性とデータベース・リンクの構成」を参照してください。

2. ARCHIVELOGモードで実行するようにdb2.example.comデータベースを構成します。取得プロセスがソース・データベースで生成された変更を取得するには、ソース・データベースをARCHIVELOGモードで実行する必要があります。ARCHIVELOGモードで実行するためのデータベースの構成の詳細は、『Oracle Database管理者ガイド』を参照してください。

3. Oracle Streamsレプリケーション環境に参加する各データベースで初期化パラメータを適切に設定します。手順については、「Oracle Streamsに関連する初期化パラメータの設定」を参照してください。

4. 次に示す必要なディレクトリ・オブジェクトを作成します。

- ソース・データベースのソース・ディレクトリ・オブジェクト。この例では、このディレクトリ・オブジェクトはsource_directoryであると想定しています。

- 宛先データベースの接続先ディレクトリ・オブジェクト。この例では、このディレクトリ・オブジェクトはdest_directoryであると想定しています。

手順については、「必要なディレクトリ・オブジェクトの作成」を参照してください。

5. SQL*Plusで、Oracle Streams管理者としてdb1.example.comデータベースに接続します。
SQL*Plusでのデータベースへの接続の詳細は、『Oracle Database管理者ガイド』を参照してください。

6. MAINTAIN_SCHEMASプロシージャを実行して、db1.example.comデータベースとdb2.example.comデータベース間でhrスキーマのレプリケーションを構成します。
構成しているレプリケーション環境に対してbi_directionalパラメータが適切に設定されていることを確認します。このパラメータは、一方向のレプリケーションの場合にはFALSE、双方向のレプリケーションの場合にはTRUEに設定します。

BEGIN
DBMS_STREAMS_ADM.MAINTAIN_SCHEMAS(
schema_names                 => 'hr',
source_directory_object      => 'source_directory',
destination_directory_object => 'dest_directory',
source_database              => 'db1.example.com',
destination_database         => 'db2.example.com',
bi_directional               => FALSE); -- Set to TRUE for bi-directional
END;
/

MAINTAIN_SCHEMASプロシージャは多くの構成タスクを実行するため、実行に時間がかかる場合があります。プロシージャの実行中に宛先データベースのレプリケートされたデータベース・オブジェクトに対するデータ操作言語(DML)またはデータ定義言語(DDL)変更を許可しないでください。

構成プロシージャの実行時、そのプロシージャの進捗に関する情報は、データ・ディクショナリ・ビューDBA_RECOVERABLE_SCRIPT、DBA_RECOVERABLE_SCRIPT_PARAMS、DBA_RECOVERABLE_SCRIPT_BLOCKSおよびDBA_RECOVERABLE_SCRIPT_ERRORSに記録されます。プロシージャでエラーが発生してプロシージャが停止した場合は、『Oracle Streamsレプリケーション管理者ガイド』でDBMS_STREAMS_ADMパッケージのRECOVER_OPERATIONプロシージャを使用したこれらのエラーからのリカバリ手順を参照してください。

7. 双方向のレプリケーションを構成する場合は、両方のデータベースのhrスキーマあるすべての表に対して最新時刻競合解消を構成します。このスキーマには、countries、departments、employees、jobs、job_history、locationsおよびregionsの表が含まれています。手順については、第9章「Oracle Streamsの競合解消」を参照してください。

関連項目:
Oracle Enterprise Managerを使用してこのレプリケーション環境を構成する場合の例は、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

ローカル取得を使用した2データベース表レプリケーションの構成

DBMS_STREAMS_ADMパッケージのMAINTAIN_TABLESプロシージャを使用すると、表レプリケーションを構成できます。この項の例では、このプロシージャを使用して、hrスキーマ内の特定の表をメンテナンスするOracle Streamsレプリケーション環境を構成します。ソース・データベースはdbs1.example.comで、接続データベースはdbs2.example.comです。

次の表では、この例で構成されたOracle Streamsレプリケーション環境に関して行った決定を示します。

決定

この例の前提

どのタイプのレプリケーション環境を構成するかの決定

この例では、ソース・データベースが読取り/書込み可能であり、宛先データベースが読取り専用である2データベース環境で一方向のレプリケーションを構成します。

ソース・データベースに対してローカル取得またはダウンストリーム取得を構成するかどうかの決定

この例では、ソース・データベースに対してローカル取得を構成します。

1つのデータベースまたは複数のデータベースで変更を許可するかどうかの決定

この例では、ソース・データベースでのみ変更が許可されているレプリケーション環境を構成します。

レプリケーション環境に異なるレプリカを含めるかどうかの決定

この例では、複数のデータベースで同じ共有データベース・オブジェクトを構成します。

レプリケーション環境で適用ハンドラを使用するかどうかの決定

この例では、適用ハンドラを構成しません。

DDL変更をメンテナンスするかどうかの決定

この例では、共有データベース・オブジェクトのサブセットに対するDDL変更をメンテナンスします。

レプリケーション環境の構成方法の決定

この例では、MAINTAIN_TABLESプロシージャを使用して環境を構成します。

レプリケーション環境では、共有データベース・オブジェクトに対する次のDML変更およびDDL変更がメンテナンスされます。

- レプリケーション環境では、hrスキーマ内の次の表に対するDML変更がメンテナンスされます。

- departments

- employees

- countries

- regions

- locations

- jobs

- job_history

- レプリケーション環境では、hrスキーマ内の次の表に対するDDL変更がメンテナンスされます。

- departments

- employees

レプリケーション環境では、hrスキーマ内の次の表に対するDDL変更はメンテナンスされません。

- countries

- regions

- locations

- jobs

- job_history

この例では、MAINTAIN_TABLESプロシージャでレプリケーション環境を直接構成しません。かわりに、構成スクリプトを生成し、departmentsおよびemployees表に対するDDL変更がメンテナンスされるようにこのスクリプトを変更します。データ・ポンプ・ネットワーク・インポートによるインスタンス化が実行されます。

Oracle Streamsによってサポートされていない表は、レプリケートしないようにしてください。

図2-3に、この例で作成されるレプリケーション環境の概要を示します。

図2-3 表をレプリケートするOracle Streams環境の例

関連項目:
Oracle Streamsによってサポートされていないデータベース・オブジェクトを判別する手順については、『Oracle Streams概要および管理』を参照してください。

MAINTAIN_TABLESプロシージャを使用して環境を構成するには、次の手順を実行します。

1. MAINTAIN_TABLESプロシージャを実行する前に必要なタスクを実行します。手順については、「Oracle Streamsレプリケーションを構成する前に実行するタスク」を参照してください。
この構成について、次のタスクを実行する必要があります。

- 両方のデータベースでOracle Streams管理者を構成します。「すべてのデータベースでのOracle Streams管理者の構成」を参照してください。

- ネットワーク接続性とデータベース・リンクの構成は、次のとおりです。

- ソース・データベースdbs1.example.comと宛先データベースdbs2.example.comとの間で、ネットワーク接続を構成します。

- ソース・データベースdbs1.example.comから宛先データベースdbs2.example.comへのデータベース・リンクを作成します。

- MAINTAIN_TABLESプロシージャではデータ・ポンプ・ネットワーク・インポートによるインスタンス化が実行されるため、宛先データベースdbs2.example.comからソース・データベースdbs1.example.comへのデータベース・リンクを作成します。

「ネットワーク接続性とデータベース・リンクの構成」を参照してください。

- ソース・データベースdbs1.example.comがARCHIVELOGモードであることを確認します。「各ソース・データベースがARCHIVELOGモードであることの確認」を参照してください。

- 両方のデータベースの初期化パラメータが適切に設定されていることを確認します。「Oracle Streamsに関連する初期化パラメータの設定」を参照してください。

- 両方のデータベースでOracle Streamsプールを適切に構成します。「Oracle Streamsプールの構成」を参照してください。

2. ソース・データベースでスクリプト・ディレクトリ・オブジェクトを作成します。この例では、このディレクトリ・オブジェクトはscript_directoryであると想定しています。
手順については、「必要なディレクトリ・オブジェクトの作成」を参照してください。

3. SQL*Plusで、Oracle Streams管理者としてソース・データベースdbs1.example.comに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

4. MAINTAIN_TABLESプロシージャを実行します。

DECLARE
tables DBMS_UTILITY.UNCL_ARRAY;
BEGIN
tables(1) := 'hr.departments';
tables(2) := 'hr.employees';
tables(3) := 'hr.countries';
tables(4) := 'hr.regions';
tables(5) := 'hr.locations';
tables(6) := 'hr.jobs';
tables(7) := 'hr.job_history';
DBMS_STREAMS_ADM.MAINTAIN_TABLES(
table_names                  => tables,
source_directory_object      => NULL,
destination_directory_object => NULL,
source_database              => 'dbs1.example.com',
destination_database         => 'dbs2.example.com',
perform_actions              => FALSE,
script_name                  => 'configure_rep.sql',
script_directory_object      => 'script_directory',
bi_directional               => FALSE,
include_ddl                  => FALSE,
instantiation      => DBMS_STREAMS_ADM.INSTANTIATION_TABLE_NETWORK);
END;
/

プロシージャによって生成されたconfigure_rep.sqlスクリプトでは、プロシージャのコールで指定されていないパラメータにデフォルト値が使用されます。スクリプトでは、作成するANYDATAキュー、キュー表、取得プロセス、伝播および適用プロセスにシステム生成名が使用されます。MAINTAIN_TABLESプロシージャに使用可能な追加のパラメータを使用して、異なる名前を指定することもできます。include_ddlパラメータがFALSEに設定されていることに注意してください。したがって、このスクリプトでは、表に対するDDL変更をメンテナンスするようにレプリケーション環境が構成されません。

プロシージャには、apply_nameパラメータを指定しません。したがって、このパラメータには、デフォルトでNULLが指定されます。apply_nameパラメータをNULLに設定すると、ソース・データベースからの変更を適用する適用プロセスは、宛先データベース上に存在することができません。ソース・データベースからの変更を適用する適用プロセスが宛先データベースに存在する場合、NULLでない値をapply_nameパラメータに指定します。

5. configure_rep.sqlスクリプトを変更します。

1. ソース・データベースが実行されているコンピュータ・システムのscript_directoryディレクトリ・オブジェクトに対応するディレクトリにナビゲートします。

2. テキスト・エディタでconfigure_rep.sqlスクリプトをオープンします。このスクリプトを変更する前に、このスクリプトをバックアップすることを検討してください。

3. スクリプトで、hr.departmentsおよびhr.employees表のルールを作成するADD_TABLE_RULESおよびADD_TABLE_PROPAGATION_RULESプロシージャのコールを検索します。たとえば、取得プロセスのプロシージャ・コールは次のようになります。

dbms_streams_adm.add_table_rules(
table_name => '"HR"."DEPARTMENTS"',
streams_type => 'CAPTURE',
streams_name => '"DBS1$CAP"',
queue_name => '"STRMADMIN"."DBS1$CAPQ"',
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => TRUE,
source_database => 'DBS1.EXAMPLE.COM',
inclusion_rule => TRUE,
and_condition => get_compatible);

dbms_streams_adm.add_table_rules(
table_name => '"HR"."EMPLOYEES"',
streams_type => 'CAPTURE',
streams_name => '"DBS1$CAP"',
queue_name => '"STRMADMIN"."DBS1$CAPQ"',
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => TRUE,
source_database => 'DBS1.EXAMPLE.COM',
inclusion_rule => TRUE,
and_condition => get_compatible);

4. 手順cで検索したプロシージャ・コールで、include_ddlパラメータの設定をTRUEに変更します。たとえば、変更後の取得プロセスのプロシージャ・コールは次のようになります。

dbms_streams_adm.add_table_rules(
table_name => '"HR"."DEPARTMENTS"',
streams_type => 'CAPTURE',
streams_name => '"DBS1$CAP"',
queue_name => '"STRMADMIN"."DBS1$CAPQ"',
include_dml => TRUE,
include_ddl => TRUE,
include_tagged_lcr => TRUE,
source_database => 'DBS1.EXAMPLE.COM',
inclusion_rule => TRUE,
and_condition => get_compatible);

dbms_streams_adm.add_table_rules(
table_name => '"HR"."EMPLOYEES"',
streams_type => 'CAPTURE',
streams_name => '"DBS1$CAP"',
queue_name => '"STRMADMIN"."DBS1$CAPQ"',
include_dml => TRUE,
include_ddl => TRUE,
include_tagged_lcr => TRUE,
source_database => 'DBS1.EXAMPLE.COM',
inclusion_rule => TRUE,
and_condition => get_compatible);

すべての取得プロセス、伝播および適用プロセスのプロシージャ・コールを変更する必要があります。

5. configure_rep.sqlスクリプトを保存してクローズします。

6. SQL*Plusで、Oracle Streams管理者としてソース・データベースdbs1.example.comに接続します。

7. ソース・データベースで、次の構成スクリプトを実行します。

SET ECHO ON
SPOOL configure_rep.out
@configure_rep.sql

スクリプトを実行すると、データベース名およびOracle Streams管理者に関する情報を入力するように求められます。この構成スクリプトが完了すると、単一ソースのOracle Streamsレプリケーション環境が構成されます。また、このスクリプトによって、キュー、取得プロセス、伝播および適用プロセスが起動されます。

構成された単一ソース・レプリケーション環境には、次の特性があります。

- ソース・データベースで、共有データベース・オブジェクトのサプリメンタル・ロギングが構成されています。

- ソース・データベースdbs1.example.comには、システム生成名を持つキューおよびキュー表があります。

- 宛先データベースdbs2.example.comには、システム生成名を持つキューおよびキュー表があります。

- ソース・データベースで、システム生成名を持つ取得プロセスが、hrスキーマ内のすべての表に対するDML変更、およびhr.departmentsおよびhr.employees表に対するDDL変更を取得します。

- ソース・データベースで実行されているシステム生成名を持つ伝播が、ソース・データベースのキューから宛先データベースのキューに取得された変更を送信します。

- 宛先データベースで、システム生成名を持つ適用プロセスが、キューから変更をデキューしてこれらの変更を宛先データベースの表に適用します。

ダウンストリーム取得を使用した2データベース・レプリケーションを構成する場合の例

次の各例では、ダウンストリーム取得プロセスを使用した2データベース・レプリケーション環境を構成します。

- 宛先でダウンストリーム取得を使用した表領域レプリケーションの構成

- 宛先でダウンストリーム取得を使用したスキーマ・レプリケーションの構成

- 第3のデータベースでダウンストリーム取得を使用したスキーマ・レプリケーションの構成

宛先でダウンストリーム取得を使用した表領域レプリケーションの構成

DBMS_STREAMS_ADMパッケージの次のプロシージャを使用すると、表領域レプリケーションを構成できます。

- MAINTAIN_SIMPLE_TTS

- MAINTAIN_TTS

- PRE_INSTANTIATION_SETUPおよびPOST_INSTANTIATION_SETUP

MAINTAIN_SIMPLE_TTSプロシージャを使用すると、単一の表領域にOracle Streamsレプリケーションを構成でき、MAINTAIN_TTSプロシージャを使用すると、自己完結型の表領域セットにOracle Streamsレプリケーションを構成できます。これらのプロシージャでは、トランスポータブル表領域、データ・ポンプ、DBMS_STREAMS_TABLESPACE_ADMパッケージおよびDBMS_FILE_TRANSFERパッケージを使用して、環境が構成されます。

自己完結型の表領域には、その表領域の外部を指す表領域からの参照は含まれません。たとえば、表領域の索引が異なる表領域の表に対する索引である場合、その表領域は自己完結型ではありません。単一の表領域は、データ・ファイルを1つのみ使用する自己完結型の表領域です。表領域セットに複数の表領域が存在する場合、自己完結型の表領域セットには、その表領域セットの外部を指す表領域セット内からの参照は含まれません。

これらのプロシージャでは、レプリケーション用に構成された表領域が、ソース・データベースから宛先データベースにクローニングされます。MAINTAIN_SIMPLE_TTSプロシージャでは、DBMS_STREAMS_TABLESPACE_ADMパッケージのCLONE_SIMPLE_TABLESPACEプロシージャが使用され、MAINTAIN_TTSプロシージャでは、DBMS_STREAMS_TABLESPACE_ADMパッケージのCLONE_TABLESPACESプロシージャが使用されます。表領域がクローニングされると、この表領域はクローン操作が完了するまで自動的に読取り専用になります。

この項の例では、MAINTAIN_TTSプロシージャを使用して、Oracle Streamsを使用して次の表領域をメンテナンスするOracle Streamsレプリケーション環境を構成します。

- tbs1

- tbs2

ソース・データベースはdbs1.example.comで、接続データベースはdbs2.example.comです。

次の表では、この例で構成されたOracle Streamsレプリケーション環境に関して行った決定を示します。

決定

この例の前提

どのタイプのレプリケーション環境を構成するかの決定

この例では、ソース・データベースが読取り/書込み可能であり、宛先データベースが読取り専用である2データベース環境で一方向のレプリケーションを構成します。

ソース・データベースに対してローカル取得またはダウンストリーム取得を構成するかどうかの決定

この例では、ソース・データベース(dbs1.example.com)に対する変更を取得する、宛先データベース(dbs2.example.com)で実行されるダウンストリーム取得プロセスを構成します。ダウンストリーム取得プロセスは、アーカイブ・ログ・ダウンストリーム取得プロセスになります。

1つのデータベースまたは複数のデータベースで変更を許可するかどうかの決定

この例では、ソース・データベースでのみ変更が許可されているレプリケーション環境を構成します。

レプリケーション環境に異なるレプリカを含めるかどうかの決定

この例では、複数のデータベースで同じ共有データベース・オブジェクトを構成します。

レプリケーション環境で適用ハンドラを使用するかどうかの決定

この例では、適用ハンドラを構成しません。

DDL変更をメンテナンスするかどうかの決定

この例では、表領域および表領域内のデータベース・オブジェクトに対するDDL変更をメンテナンスします。

レプリケーション環境の構成方法の決定

この例では、MAINTAIN_TTSプロシージャを使用して環境を構成します。

この例では、MAINTAIN_TTSプロシージャでレプリケーション環境を直接構成します。構成スクリプトは生成されません。また、この例では、次のことを想定しています。

- 表領域tbs1およびtbs2が、ソース・データベースdbs1.example.comに自己完結型の表領域セットを構成しています。

- 表領域セットのデータ・ファイルは、いずれもソース・データベースdbs1.example.comの/orc/dbsディレクトリに存在します。

- dbs2.example.comデータベースには現在、表領域セットは含まれていません。

MAINTAIN_SIMPLE_TTSおよびMAINTAIN_TTSプロシージャでは、各取得プロセスおよび適用プロセスのネガティブ・ルール・セットにルールを追加することによって、Oracle Streamsによってサポートされていないデータベース・オブジェクトがレプリケーション環境から自動的に除外されます。PRE_INSTANTIATION_SETUPおよびPOST_INSTANTIATION_SETUPプロシージャを使用すると、レプリケーション環境から除外するデータベース・オブジェクトを指定できます。

Oracle Streamsによってサポートされていないデータベース・オブジェクトを判別するには、DBA_STREAMS_UNSUPPORTEDデータ・ディクショナリ・ビューを問い合せます。サポートされていないデータベース・オブジェクトが除外されていない場合、取得エラーが発生します。

図2-4に、この例で作成されるレプリケーション環境の概要を示します。

図2-4 表領域をレプリケートするOracle Streams環境の例

関連項目:
Oracle Streamsによってサポートされていないデータベース・オブジェクトを判別する手順については、『Oracle Streams概要および管理』を参照してください。

MAINTAIN_TTSプロシージャを使用して環境を構成するには、次の手順を実行します。

1. MAINTAIN_TTSプロシージャを実行する前に必要なタスクを実行します。手順については、「Oracle Streamsレプリケーションを構成する前に実行するタスク」を参照してください。
この構成について、次のタスクを実行する必要があります。

- 両方のデータベースでOracle Streams管理者を構成します。「すべてのデータベースでのOracle Streams管理者の構成」を参照してください。

- ネットワーク接続性とデータベース・リンクの構成は、次のとおりです。

- ソース・データベースdbs1.example.comと宛先データベースdbs2.example.comとの間で、ネットワーク接続を構成します。

- ソース・データベースdbs1.example.comから宛先データベースdbs2.example.comへのデータベース・リンクを作成します。

- 宛先データベースでダウンストリーム取得が構成されるため、宛先データベースdbs2.example.comからソース・データベースdbs1.example.comへのデータベース・リンクを作成します。

「ネットワーク接続性とデータベース・リンクの構成」を参照してください。

- 両方のデータベースがARCHIVELOGモードであることを確認します。「各ソース・データベースがARCHIVELOGモードであることの確認」を参照してください。

- 両方のデータベースの初期化パラメータが適切に設定されていることを確認します。「Oracle Streamsに関連する初期化パラメータの設定」を参照してください。

- 両方のデータベースでOracle Streamsプールを適切に構成します。「Oracle Streamsプールの構成」を参照してください。

- 宛先データベースはソース・データベースに対する変更の取得データベースとなるため、ソース・データベースdbs1.example.comから宛先データベースdbs2.example.comへのログ・ファイルのコピーを構成します。取得プロセスは、アーカイブ・ログ・ダウンストリーム取得プロセスになります。「ダウンストリーム取得データベースへのログ・ファイルの転送の構成」を参照してください。

2. 次に示す必要なディレクトリ・オブジェクトを作成します。

- ソース・データベースのソース・ディレクトリ・オブジェクト。この例では、このディレクトリ・オブジェクトはsource_directoryであると想定しています。

- 宛先データベースの接続先ディレクトリ・オブジェクト。この例では、このディレクトリ・オブジェクトはdest_directoryであると想定しています。

手順については、「必要なディレクトリ・オブジェクトの作成」を参照してください。

3. SQL*Plusで、Oracle Streams管理者として表領域セットを含むデータベースに接続します。この例では、dbs1.example.comデータベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

4. 表領域セットの表領域のデータ・ファイルを含むディレクトリのディレクトリ・オブジェクトを作成します。たとえば、次の文を実行すると、/orc/dbsディレクトリに対応するディレクトリ・オブジェクトtbs_directoryが作成されます。

CREATE DIRECTORY tbs_directory AS '/orc/dbs';

データ・ファイルが複数のディレクトリに存在する場合、ディレクトリ・オブジェクトはそれらのディレクトリごとに存在する必要があり、手順6でMAINTAIN_TTSプロシージャを実行するユーザーが、それらのディレクトリ・オブジェクトに対するREAD権限を持っている必要があります。この例では、Oracle Streams管理者がディレクトリ・オブジェクトを作成するため、この権限を持っていることになります。

5. SQL*Plusで、Oracle Streams管理者として宛先データベースdbs2.example.comに接続します。

6. MAINTAIN_TTSプロシージャを実行します。

DECLARE
t_names  DBMS_STREAMS_TABLESPACE_ADM.TABLESPACE_SET;
BEGIN
-- Tablespace names
t_names(1) := 'TBS1';
t_names(2) := 'TBS2';
DBMS_STREAMS_ADM.MAINTAIN_TTS(
tablespace_names             => t_names,
source_directory_object      => 'source_directory',
destination_directory_object => 'dest_directory',
source_database              => 'dbs1.example.com',
destination_database         => 'dbs2.example.com',
perform_actions              => TRUE,
capture_name                 => 'capture_tts',
capture_queue_table          => 'streams_queue_table',
capture_queue_name           => 'streams_queue',
apply_name                   => 'apply_tts',
apply_queue_table            => 'streams_queue_table',
apply_queue_name             => 'streams_queue');
bi_directional               => FALSE,
include_ddl                  => TRUE);
END;
/

このプロシージャが完了すると、単一ソースのOracle Streamsレプリケーション環境が構成されます。

このプロシージャは宛先データベースで実行されるため、宛先データベースで、ソース・データベースに対する変更のダウンストリーム取得が構成されます。構成プロシージャを使用してダウンストリーム取得を構成する場合は、キューとキュー表の名前を指定するパラメータが重要になります。このような構成では、取得プロセスと適用プロセスでダウンストリーム取得データベースの同じキューを使用してキュー間の変更の伝播を回避すると効率的です。この構成例では、効率を向上させるために、capture_queue_nameパラメータとapply_queue_nameパラメータの両方にstreams_queueを指定しています。また、capture_queue_tableパラメータとapply_queue_tableパラメータの両方にstreams_queue_tableを指定しています。

構成操作の進捗を監視するには、「Oracle Streams構成の進捗の監視」の手順に従います。

このプロシージャでエラーが発生してプロシージャが停止した場合、エラーからのリカバリまたは構成操作のロールバックを実行する方法の詳細は、「操作エラーからのリカバリ」を参照してください。

構成された単一ソース・レプリケーション環境には、次の特性があります。

- ソース・データベースdbs1.example.comで共有データベース・オブジェクトにサプリメンタル・ロギングが構成されています。

- dbs1.example.comデータベースには、キュー表streams_queue_tableを使用するキューstreams_queueがあります。このキューは適用プロセス用です。

- dbs2.example.comデータベースには、キュー表streams_queue_tableを使用するキューstreams_queueがあります。このキューは、ダウンストリーム取得プロセスと適用プロセスで共有されます。

- dbs2.example.comデータベースでは、アーカイブ・ログ・ダウンストリーム取得プロセスcapture_ttsが、ソース・データベースに対する変更を取得します。具体的には、このダウンストリーム取得プロセスは、tbs1およびtbs2表領域内の表に対するDML変更、およびこれらの表領域およびそのデータベース・オブジェクトに対するDDL変更を取得します。
異常に長い時間が経っても取得プロセスが有効化されない場合は、アラート・ログでエラーを確認してください。詳細は、『Oracle Streams概要および管理』を参照してください。

- dbs2.example.comでは、適用プロセスapply_ttsが、そのキューから変更をデキューしてそれらの変更を共有データベース・オブジェクトに適用します。

宛先でダウンストリーム取得を使用したスキーマ・レプリケーションの構成

この例では、hrスキーマのすべての表に対するデータ操作言語(DML)変更をレプリケートするOracle Streamsレプリケーション環境を構成します。この例では、宛先データベースでダウンストリーム取得プロセスを使用した2データベース・レプリケーション環境を構成します。この例では、グローバル・データベース名src.example.comおよびdest.example.comを使用します。ただし、使用している環境内でデータベースを置き換えて例を完成することもできます。2データベース・レプリケーション環境の詳細は、「どのタイプのレプリケーション環境を構成するかの決定」を参照してください。

この例では、宛先データベースdest.example.comでダウンストリーム取得プロセスが実行されます。したがって、変更の取得に必要なリソースは、ソース・データベースsrc.example.comで解放されます。この例では、アーカイブ・ログ・ダウンストリーム取得プロセスではなく、リアルタイム・ダウンストリーム取得プロセスを構成します。リアルタイム・ダウンストリーム取得の利点は、ソース・データベースで行われた変更を取得するのに必要な時間が軽減されることです。時間が軽減されるのは、リアルタイム・ダウンストリーム取得プロセスではREDOログ・ファイルがアーカイブされるのを待たなくてもデータを取得できるためです。

次の表では、この例で構成されたOracle Streamsレプリケーション環境に関して行った決定を示します。

決定

この例の前提

どのタイプのレプリケーション環境を構成するかの決定

この例では、ソース・データベースが読取り/書込み可能であり、宛先データベースが読取り専用である2データベース環境で一方向のレプリケーションを構成します。

ソース・データベースに対してローカル取得またはダウンストリーム取得を構成するかどうかの決定

この例では、ソース・データベース(src.example.com)に対する変更を取得する、宛先データベース(dest.example.com)で実行されるダウンストリーム取得プロセスを構成します。ダウンストリーム取得プロセスは、リアルタイム・ダウンストリーム取得プロセスになります。

1つのデータベースまたは複数のデータベースで変更を許可するかどうかの決定

この例では、ソース・データベースでのみ変更が許可されているレプリケーション環境を構成します。

レプリケーション環境に異なるレプリカを含めるかどうかの決定

この例では、複数のデータベースで同じ共有データベース・オブジェクトを構成します。

レプリケーション環境で適用ハンドラを使用するかどうかの決定

この例では、適用ハンドラを構成しません。

DDL変更をメンテナンスするかどうかの決定

この例では、表領域および表領域内のデータベース・オブジェクトに対するDDL変更をメンテナンスします。

レプリケーション環境の構成方法の決定

この例では、MAINTAIN_SCHEMASプロシージャを使用して環境を構成します。

MAINTAIN_SCHEMASプロシージャの実行時に、宛先データベースにレプリケーション用に構成されたデータベース・オブジェクトが存在する場合と存在しない場合があります。宛先データベースにデータベース・オブジェクトが存在しない場合、MAINTAIN_SCHEMASプロシージャでは、データ・ポンプ・エクスポート/インポートを使用して宛先データベースでデータベース・オブジェクトをインスタンス化します。インスタンス化中に、これらのデータベース・オブジェクトのインスタンス化SCNが設定されます。宛先データベースにすでにデータベース・オブジェクトが存在する場合、MAINTAIN_SCHEMASプロシージャでは、既存のデータベース・オブジェクトを保持し、これらのデータベース・オブジェクトのインスタンス化SCNを設定します。この例では、MAINTAIN_SCHEMASプロシージャを実行する前に、src.example.comデータベースとdest.example.comデータベースの両方にhrスキーマが存在します。

この例では、MAINTAIN_SCHEMASプロシージャでレプリケーション環境を直接構成します。構成スクリプトは生成されません。データ・ポンプ・エクスポート・ダンプ・ファイルによるインスタンス化が実行されます。

図2-5に、この例で作成される環境の概要を示します。

図2-5 ダウンストリーム取得プロセスを使用した2データベース・レプリケーション環境

MAINTAIN_SCHEMASプロシージャを使用して環境を構成するには、次の手順を実行します。

1. 次のタスクを完了して、2データベース・レプリケーション環境を準備します。

1. src.example.comデータベースがdest.example.comデータベースと相互に通信できるようにネットワーク接続を構成します。
データベース間のネットワーク接続の構成については、『Oracle Database 2日でデータベース管理者』を参照してください。

2. レプリケーション環境に参加する各データベースでOracle Streams管理者を構成します。手順については、「すべてのデータベースでのOracle Streams管理者の構成」を参照してください。この例では、Oracle Streams管理者がstrmadminであると想定しています。

3. ソース・データベースから宛先データベースおよび宛先データベースからソース・データベースへのデータベース・リンクを作成します。この例では、次のデータベース・リンクを作成します。

- src.example.comデータベースからdest.example.comデータベース。データベース・リンクの名前とサービス名の両方がdest.example.comである必要があります。

- dest.example.comデータベースからsrc.example.comデータベース。データベース・リンクの名前とサービス名の両方がsrc.example.comである必要があります。

src.example.comデータベースは、dest.example.comデータベースで行うダウンストリーム取得プロセスのソース・データベースであるため、dest.example.comデータベースからsrc.example.comデータベースへのデータベース・リンクは必須です。このデータベース・リンクによって、取得プロセスの作成と構成が簡素化されます。

各データベース・リンクは、Oracle Streams管理者のスキーマに作成する必要があります。また、各データベース・リンクは、他のデータベースのOracle Streams管理者に接続する必要があります。手順については、「ネットワーク接続性とデータベース・リンクの構成」を参照してください。

4. Oracle Streamsレプリケーション環境に参加する各データベースで初期化パラメータを適切に設定します。手順については、「Oracle Streamsに関連する初期化パラメータの設定」を参照してください。

5. ARCHIVELOGモードで実行するように両方のデータベースを構成します。ダウンストリーム取得プロセスがソース・データベースで生成された変更を取得するには、ソース・データベースとダウンストリーム取得データベースの両方をARCHIVELOGモードで実行する必要があります。この例では、src.example.comおよびdest.example.comデータベースがARCHIVELOGモードで実行されている必要があります。ARCHIVELOGモードで実行するためのデータベースの構成の詳細は、『Oracle Database管理者ガイド』を参照してください。

6. 宛先データベース(dest.example.com)をソース・データベースに対する変更の取得データベースとして使用するため、ソース・データベースsrc.example.comから宛先データベースdest.example.comへのログ・ファイルのコピーを構成します。「ダウンストリーム取得データベースへのログ・ファイルの転送の構成」を参照してください。

7. この例ではリアルタイム・ダウンストリーム取得プロセスを構成するため、ダウンストリーム・データベースでスタンバイREDOログを追加します。「リアルタイム・ダウンストリーム取得のためのスタンバイREDOログの追加」を参照してください。

2. 次に示す必要なディレクトリ・オブジェクトを作成します。

- ソース・データベースのソース・ディレクトリ・オブジェクト。この例では、このディレクトリ・オブジェクトはsource_directoryであると想定しています。

- 宛先データベースの接続先ディレクトリ・オブジェクト。この例では、このディレクトリ・オブジェクトはdest_directoryであると想定しています。

手順については、「必要なディレクトリ・オブジェクトの作成」を参照してください。

3. SQL*Plusで、Oracle Streams管理者としてdest.example.comデータベースに接続します。
SQL*Plusでのデータベースへの接続の詳細は、『Oracle Database管理者ガイド』を参照してください。

4. 引き続きOracle Streams管理者としてdest.example.comデータベースに接続したままで、MAINTAIN_SCHEMASプロシージャを実行して、src.example.comデータベースとdest.example.comデータベースの間にレプリケーションを構成します。

BEGIN
DBMS_STREAMS_ADM.MAINTAIN_SCHEMAS(
schema_names                 => 'hr',
source_directory_object      => 'source_directory',
destination_directory_object => 'dest_directory',
source_database              => 'src.example.com',
destination_database         => 'dest.example.com',
capture_name                 => 'capture',
capture_queue_table          => 'streams_queue_qt',
capture_queue_name           => 'streams_queue',
apply_name                   => 'apply',
apply_queue_table            => 'streams_queue_qt',
apply_queue_name             => 'streams_queue');
END;
/

MAINTAIN_SCHEMASプロシージャは多くの構成タスクを実行するため、実行に時間がかかる場合があります。プロシージャの実行中に宛先データベースのレプリケートされたデータベース・オブジェクトに対するデータ操作言語(DML)またはデータ定義言語(DDL)変更を許可しないでください。

MAINTAIN_SCHEMASプロシージャの必須パラメータは、schema_names、source_directory_object、destination_directory_object、source_databaseおよびdestination_databaseのみです。

この例では、他のパラメータを指定して、取得プロセス、取得プロセスのキュー表、取得プロセスのキュー、適用プロセス、適用プロセスのキュー表および適用プロセスのキューの名前を選択可能であることを示しています。これらのパラメータを指定しない場合は、システム生成名が使用されます。

構成プロシージャを使用してダウンストリーム取得を構成する場合は、キューとキュー表の名前を指定するパラメータが重要になります。このような構成では、取得プロセスと適用プロセスでダウンストリーム取得データベースの同じキューを使用してキュー間の変更の伝播を回避すると効率的です。この構成例では、効率を向上させるために、capture_queue_nameパラメータとapply_queue_nameパラメータの両方にstreams_queueを指定しています。また、capture_queue_tableパラメータとapply_queue_tableパラメータの両方にstreams_queue_qtを指定しています。

構成プロシージャの実行時、そのプロシージャの進捗に関する情報は、データ・ディクショナリ・ビューDBA_RECOVERABLE_SCRIPT、DBA_RECOVERABLE_SCRIPT_PARAMS、DBA_RECOVERABLE_SCRIPT_BLOCKSおよびDBA_RECOVERABLE_SCRIPT_ERRORSに記録されます。プロシージャでエラーが発生してプロシージャが停止した場合は、『Oracle Streamsレプリケーション管理者ガイド』でDBMS_STREAMS_ADMパッケージのRECOVER_OPERATIONプロシージャを使用したこれらのエラーからのリカバリ手順を参照してください。

プロシージャが正常に完了したら、次の手順に進みます。

5. 引き続きOracle Streams管理者としてdest.example.comデータベースに接続したままで、downstream_real_time_mine取得プロセス・パラメータをYに設定します。

BEGIN
DBMS_CAPTURE_ADM.SET_PARAMETER(
capture_name => 'capture',
parameter    => 'downstream_real_time_mine',
value        => 'Y');
END;
/

6. SQL*Plusで、管理ユーザーとしてソース・データベースsrc.example.comに接続します。

7. ソース・データベースで現行のログ・ファイルをアーカイブします。

ALTER SYSTEM ARCHIVE LOG CURRENT;

ソース・データベースで現行のログ・ファイルをアーカイブすると、ソース・データベースのREDOログのリアルタイム・マイニングが開始されます。

取得プロセスがREDOデータを待機している時間が異常に長い場合は、アラート・ログでエラーを確認してください。詳細は、『Oracle Streams概要および管理』を参照してください。

関連項目:
Oracle Enterprise Managerを使用してこのレプリケーション環境を構成する場合の例は、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

第3のデータベースでダウンストリーム取得を使用したスキーマ・レプリケーションの構成

DBMS_STREAMS_ADMパッケージのMAINTAIN_SCHEMASプロシージャを使用すると、スキーマ・レプリケーションを構成できます。この項の例では、このプロシージャを使用して、hrスキーマをメンテナンスするOracle Streamsレプリケーション環境を構成します。ソース・データベースはdbs1.example.com、宛先データベースはdbs3.example.comです。

次の表では、この例で構成されたOracle Streamsレプリケーション環境に関して行った決定を示します。

決定

この例の前提

どのタイプのレプリケーション環境を構成するかの決定

この例では、両方のデータベースが読取り/書込み可能な2データベース環境における双方向のレプリケーションを構成します。

ソース・データベースに対してローカル取得またはダウンストリーム取得を構成するかどうかの決定

この例では、ソース・データベース(dbs1.example.com)に対する変更を取得する、第3のデータベースdbs2.example.comで実行されるダウンストリーム取得プロセスを構成し、dbs2.example.comの伝播が宛先データベース(dbs3.example.com)に取得された変更を伝播します。ダウンストリーム取得プロセスは、リアルタイム・ダウンストリーム取得プロセスになります。

1つのデータベースまたは複数のデータベースで変更を許可するかどうかの決定

この例では、レプリケートされたデータベース・オブジェクトへの変更が両方のデータベースにおいて可能なレプリケーション環境を構成します。

レプリケーション環境に異なるレプリカを含めるかどうかの決定

この例では、複数のデータベースで同じ共有データベース・オブジェクトを構成します。

レプリケーション環境で適用ハンドラを使用するかどうかの決定

この例では、適用ハンドラを構成しません。

DDL変更をメンテナンスするかどうかの決定

この例では、hrスキーマおよびhrスキーマ内のデータベース・オブジェクトに対するDDL変更がメンテナンスされます。

レプリケーション環境の構成方法の決定

この例では、MAINTAIN_SCHEMASプロシージャを使用して環境を構成します。

この例では、MAINTAIN_SCHEMASプロシージャでレプリケーション環境を直接構成します。構成スクリプトは生成されません。データ・ポンプ・エクスポート・ダンプ・ファイルによるインスタンス化が実行されます。

MAINTAIN_SCHEMASプロシージャでは、各取得プロセスおよび適用プロセスのネガティブ・ルール・セットにルールを追加することによって、Oracle Streamsによってサポートされていないデータベース・オブジェクトがレプリケーション環境から自動的に除外されます。Oracle Streamsによってサポートされていないデータベース・オブジェクトを判別するには、DBA_STREAMS_UNSUPPORTEDデータ・ディクショナリ・ビューを問い合せます。サポートされていないデータベース・オブジェクトが除外されていない場合、取得エラーが発生します。

図2-6に、この例で作成されるレプリケーション環境の概要を示します。

図2-6 スキーマをレプリケートするOracle Streams環境の例

関連項目:
Oracle Streamsによってサポートされていないデータベース・オブジェクトを判別する手順については、『Oracle Streams概要および管理』を参照してください。

MAINTAIN_SCHEMASプロシージャを使用して環境を構成するには、次の手順を実行します。

1. MAINTAIN_SCHEMASプロシージャを実行する前に必要なタスクを実行します。手順については、「Oracle Streamsレプリケーションを構成する前に実行するタスク」を参照してください。
この構成について、次のタスクを実行する必要があります。

- 3つすべてのデータベースでOracle Streams管理者を構成します。「すべてのデータベースでのOracle Streams管理者の構成」を参照してください。

- ネットワーク接続性とデータベース・リンクの構成は、次のとおりです。

- ソース・データベースdbs1.example.com、宛先データベースdbs3.example.comおよび第3のデータベースdbs2.example.comの3つすべてのデータベース間にネットワーク接続を構成します。

- ソース・データベースdbs1.example.comから宛先データベースdbs3.example.comへのデータベース・リンクを作成します。

- 第3のデータベースでダウンストリーム取得が構成されるため、第3のデータベースdbs2.example.comからソース・データベースdbs1.example.comへのデータベース・リンクを作成します。

- 第3のデータベースでダウンストリーム取得が構成されるため、第3のデータベースdbs2.example.comから宛先データベースdbs3.example.comへのデータベース・リンクを作成します。

- レプリケーション環境は双方向になるため、宛先データベースdbs3.example.comからソース・データベースdbs1.example.comへのデータベース・リンクを作成します。

「ネットワーク接続性とデータベース・リンクの構成」を参照してください。

- ソース・データベース、宛先データベースおよび第3のデータベースがARCHIVELOGモードであることを確認します。「各ソース・データベースがARCHIVELOGモードであることの確認」を参照してください。

- すべてのデータベースの初期化パラメータが適切に設定されていることを確認します。「Oracle Streamsに関連する初期化パラメータの設定」を参照してください。

- 両方のデータベースでOracle Streamsプールを適切に構成します。「Oracle Streamsプールの構成」を参照してください。

- 第3のデータベース(dbs2.example.com)はソース・データベースに対する変更の取得データベースとなるため、ソース・データベースdbs1.example.comから第3のデータベースdbs2.example.comへのログ・ファイルのコピーを構成します。「ダウンストリーム取得データベースへのログ・ファイルの転送の構成」を参照してください。

- この例ではリアルタイム・ダウンストリーム取得プロセスを構成するため、ダウンストリーム・データベース(dbs2.example.com)でスタンバイREDOログを追加します。「リアルタイム・ダウンストリーム取得のためのスタンバイREDOログの追加」を参照してください。

2. 次に示す必要なディレクトリ・オブジェクトを作成します。

- ソース・データベースのソース・ディレクトリ・オブジェクト。この例では、このディレクトリ・オブジェクトはsource_directoryであると想定しています。

- 宛先データベースの接続先ディレクトリ・オブジェクト。この例では、このディレクトリ・オブジェクトはdest_directoryであると想定しています。

手順については、「必要なディレクトリ・オブジェクトの作成」を参照してください。

3. SQL*Plusで、Oracle Streams管理者として第3のデータベースdbs2.example.comに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

4. MAINTAIN_SCHEMASプロシージャを実行します。

BEGIN
DBMS_STREAMS_ADM.MAINTAIN_SCHEMAS(
schema_names                 => 'hr',
source_directory_object      => 'source_directory',
destination_directory_object => 'dest_directory',
source_database              => 'dbs1.example.com',
destination_database         => 'dbs3.example.com',
perform_actions              => TRUE,
dump_file_name               => 'export_hr.dmp',
capture_queue_table          => 'rep_capture_queue_table',
capture_queue_name           => 'rep_capture_queue',
capture_queue_user           => NULL,
apply_queue_table            => 'rep_dest_queue_table',
apply_queue_name             => 'rep_dest_queue',
apply_queue_user             => NULL,
capture_name                 => 'capture_hr',
propagation_name             => 'prop_hr',
apply_name                   => 'apply_hr',
log_file                     => 'export_hr.clg',
bi_directional               => TRUE,
include_ddl                  => TRUE,
instantiation                => DBMS_STREAMS_ADM.INSTANTIATION_SCHEMA);
END;
/

このプロシージャでは双方向のレプリケーション環境が構成されるため、プロシージャの実行中に宛先データベースの共有データベース・オブジェクトに対するDML変更またはDDL変更を許可しないでください。

このプロシージャは第3のデータベースで実行されるため、第3のデータベースで、ソース・データベースに対する変更のダウンストリーム取得が構成されます。

構成操作の進捗を監視するには、「Oracle Streams構成の進捗の監視」の手順に従います。

このプロシージャでエラーが発生してプロシージャが停止した場合、エラーからのリカバリまたは構成操作のロールバックを実行する方法の詳細は、「操作エラーからのリカバリ」を参照してください。

5. downstream_real_time_mine取得プロセス・パラメータをYに設定します。

BEGIN
DBMS_CAPTURE_ADM.SET_PARAMETER(
capture_name => 'capture_hr',
parameter    => 'downstream_real_time_mine',
value        => 'Y');
END;
/

6. ログ・ファイルを切り替えるために必要な権限を持つ管理ユーザーとして、ソース・データベースdbs1.example.comに接続します。

7. ソース・データベースで現行のログ・ファイルをアーカイブします。

ALTER SYSTEM ARCHIVE LOG CURRENT;

ソース・データベースで現行のログ・ファイルをアーカイブすると、ソース・データベースのREDOログのリアルタイム・マイニングが開始されます。

取得プロセスがREDOデータを待機している時間が異常に長い場合は、アラート・ログでエラーを確認してください。詳細は、『Oracle Streams概要および管理』を参照してください。

8. 必要に応じて、共有データベース・オブジェクトの競合解消を構成します。
通常、双方向のレプリケーション環境では、競合が発生する可能性があります。MAINTAIN_SCHEMASプロシージャで作成した環境で競合が発生する可能性がある場合は、競合解消を構成してから、共有データベース・オブジェクトに対する変更をユーザーに許可します。

詳細は、第9章「Oracle Streamsの競合解消」を参照してください。

この例で構成された双方向のレプリケーション環境には、次の特性があります。

- ソース・データベースおよび宛先データベースで共有データベース・オブジェクトのサプリメンタル・ロギングが構成されています。

- dbs1.example.comデータベースには、キュー表rep_dest_queue_tableを使用するキューrep_dest_queueがあります。このキューは適用プロセス用です。

- dbs3.example.comデータベースには、キュー表rep_capture_queue_tableを使用するキューrep_capture_queueがあります。このキューはローカル取得プロセス用です。

- dbs3.example.comデータベースには、キュー表rep_dest_queue_tableを使用するキューrep_dest_queueがあります。このキューは適用プロセス用です。

- dbs2.example.comデータベースには、キュー表rep_capture_queue_tableを使用するキューrep_capture_queueがあります。このキューはダウンストリーム取得プロセス用です。

- dbs2.example.comデータベースで、リアルタイム・ダウンストリームの取得プロセスcapture_hrが、hrスキーマおよびソース・データベースのスキーマ内のデータベース・オブジェクトに対するDML変更およびDDL変更を取得します。

- dbs3.example.comデータベースで、ローカル取得プロセスcapture_hrが、hrスキーマおよび宛先データベースのスキーマ内のデータベース・オブジェクトに対するDML変更およびDDL変更を取得します。

- dbs2.example.comデータベースで実行されている伝播prop_hrが、dbs2.example.comデータベースのキューからdbs3.example.comデータベースのキューに取得された変更を送信します。

- dbs3.example.comデータベースで実行されている伝播prop_hrが、dbs3.example.comデータベースのキューからdbs1.example.comデータベースのキューに取得された変更を送信します。

- dbs1.example.comデータベースで、適用プロセスapply_hrが、rep_dest_queueから変更をデキューしてそれらの変更をデータベース・オブジェクトに適用します。

- dbs3.example.comデータベースで、適用プロセスapply_hrが、rep_dest_queueから変更をデキューしてそれらの変更をデータベース・オブジェクトに適用します。

- タグを使用して、変更の循環が回避されます。具体的には、適用プロセスによって適用される変更のREDOレコードにタグが含まれるように、各適用プロセスで適用タグが使用されます。各適用プロセスは、レプリケーション環境で一意の適用タグを使用します。各伝播は、同じデータベースで実行されている適用プロセスのタグを持つ変更を廃棄します。詳細は、「変更の循環とタグ」を参照してください。

ハブ・アンド・スポーク・レプリケーションを構成する場合の例

この例では、hrスキーマのすべての表に対するデータ操作言語(DML)変更をレプリケートするOracle Streamsハブ・アンド・スポーク・レプリケーション環境を構成します。この例では、各データベースで取得プロセスを使用して、これらの変更を取得します。ハブ・アンド・スポーク・レプリケーションとは、中央ハブ・データベースが1つ以上のスポーク・データベースを使用して変更をレプリケートすることを意味します。スポーク・データベースは相互には直接通信しません。この構成例では、ハブ・データベースが、1つのスポーク・データベースで生成された変更を別のスポーク・データベースに送信します。

この例では、ハブ・データベースのグローバル名はhub.example.comであり、スポーク・データベースのグローバル名はspoke1.example.comおよびspoke2.example.comです。ただし、使用している環境内でデータベースを置き換えて例を完成することもできます。

次の表では、この例で構成されたOracle Streamsレプリケーション環境に関して行った決定を示します。

決定

この例の前提

どのタイプのレプリケーション環境を構成するかの決定

この例では、ハブ・データベースのグローバル名がhub.example.comで、スポーク・データベースのグローバル名がspoke1.example.comおよびspoke2.example.comであるハブ・アンド・スポーク・レプリケーション環境を構成します。環境内のすべてのデータベースは読取り/書込み可能です。

ソース・データベースに対してローカル取得またはダウンストリーム取得を構成するかどうかの決定

この例では、各データベースでローカル取得を構成します。

1つのデータベースまたは複数のデータベースで変更を許可するかどうかの決定

この例では、レプリケートされたデータベース・オブジェクトへの変更が3つのデータベースすべてにおいて可能なレプリケーション環境を構成します。

レプリケーション環境に異なるレプリカを含めるかどうかの決定

この例では、複数のデータベースで同じ共有データベース・オブジェクトを構成します。

レプリケーション環境で適用ハンドラを使用するかどうかの決定

この例では、適用ハンドラを構成しません。

DDL変更をメンテナンスするかどうかの決定

この例では、共有データベース・オブジェクトに対するDDL変更はメンテナンスしません。

レプリケーション環境の構成方法の決定

この例では、MAINTAIN_SCHEMASプロシージャを使用して環境を構成します。

この例では、MAINTAIN_SCHEMASプロシージャでレプリケーション環境を直接構成します。構成スクリプトは生成されません。データ・ポンプ・エクスポート・ダンプ・ファイルによるインスタンス化が実行されます。

MAINTAIN_SCHEMASプロシージャでは、各取得プロセスおよび適用プロセスのネガティブ・ルール・セットにルールを追加することによって、Oracle Streamsによってサポートされていないデータベース・オブジェクトがレプリケーション環境から自動的に除外されます。Oracle Streamsによってサポートされていないデータベース・オブジェクトを判別するには、DBA_STREAMS_UNSUPPORTEDデータ・ディクショナリ・ビューを問い合せます。サポートされていないデータベース・オブジェクトが除外されていない場合、取得エラーが発生します。

MAINTAIN_SCHEMASプロシージャの実行時に、宛先データベースにレプリケーション用に構成されたデータベース・オブジェクトが存在する場合と存在しない場合があります。宛先データベースにデータベース・オブジェクトが存在しない場合、MAINTAIN_SCHEMASプロシージャでは、データ・ポンプ・エクスポート/インポートを使用して宛先データベースでデータベース・オブジェクトをインスタンス化します。インスタンス化中に、これらのデータベース・オブジェクトのインスタンス化SCNが設定されます。宛先データベースにすでにデータベース・オブジェクトが存在する場合、MAINTAIN_SCHEMASプロシージャでは、既存のデータベース・オブジェクトを保持し、これらのデータベース・オブジェクトのインスタンス化SCNを設定します。この例では、MAINTAIN_SCHEMASプロシージャを実行する前に、各データベースにhrスキーマが存在します。

図2-7に、この例で作成される環境の概要を示します。

図2-7 取得プロセスと読取り/書込み可能なスポークを使用したハブ・アンド・スポーク環境

MAINTAIN_SCHEMASプロシージャを使用して環境を構成するには、次の手順を実行します。

1. 次のタスクを完了して、ハブ・アンド・スポーク・レプリケーション環境を準備します。

1. 次のデータベースが相互に通信できるようにネットワーク接続を構成します。

- hub.example.comデータベースとspoke1.example.comデータベース。

- hub.example.comデータベースとspoke2.example.comデータベース。

データベース間のネットワーク接続の構成については、『Oracle Database 2日でデータベース管理者』を参照してください。

2. レプリケーション環境に参加する各データベースでOracle Streams管理者を構成します。手順については、「すべてのデータベースでのOracle Streams管理者の構成」を参照してください。この例では、Oracle Streams管理者がstrmadminであると想定しています。

3. ハブ・データベースから各スポーク・データベースおよび各スポーク・データベースからハブ・データベースへのデータベース・リンクを作成します。この例では、次のデータベース・リンクを作成します。

- hub.example.comデータベースからspoke1.example.comデータベース。データベース・リンクの名前とサービス名の両方がspoke1.example.comである必要があります。

- hub.example.comデータベースからspoke2.example.comデータベース。データベース・リンクの名前とサービス名の両方がspoke2.example.comである必要があります。

- spoke1.example.comデータベースからhub.example.comデータベース。データベース・リンクの名前とサービス名の両方がhub.example.comである必要があります。

- spoke2.example.comデータベースからhub.example.comデータベース。データベース・リンクの名前とサービス名の両方がhub.example.comである必要があります。

各データベース・リンクは、Oracle Streams管理者のスキーマに作成する必要があります。また、各データベース・リンクは、宛先データベースのOracle Streams管理者に接続する必要があります。手順については、「ネットワーク接続性とデータベース・リンクの構成」を参照してください。

4. Oracle Streamsレプリケーション環境に参加する各データベースで初期化パラメータを適切に設定します。手順については、「Oracle Streamsに関連する初期化パラメータの設定」を参照してください。

5. ARCHIVELOGモードで実行するように各ソース・データベースを構成します。取得プロセスがソース・データベースで生成された変更を取得するには、ソース・データベースをARCHIVELOGモードで実行する必要があります。この例では、すべてのデータベースがARCHIVELOGモードで実行されている必要があります。ARCHIVELOGモードで実行するためのデータベースの構成の詳細は、『Oracle Database管理者ガイド』を参照してください。

2. 次に示す必要なディレクトリ・オブジェクトを作成します。

- ハブ・データベースhub.example.comのディレクトリ・オブジェクト。この例では、このディレクトリ・オブジェクトはhub_directoryであると想定しています。

- スポーク・データベースspoke1.example.comのディレクトリ・オブジェクト。この例では、このディレクトリ・オブジェクトはspoke1_directoryであると想定しています。

- スポーク・データベースspoke2.example.comのディレクトリ・オブジェクト。この例では、このディレクトリ・オブジェクトはspoke2_directoryであると想定しています。

手順については、「必要なディレクトリ・オブジェクトの作成」を参照してください。

3. SQL*Plusで、Oracle Streams管理者としてhub.example.comデータベースに接続します。
SQL*Plusの起動の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

4. MAINTAIN_SCHEMASプロシージャを実行して、hub.example.comデータベースとspoke1.example.comデータベース間でレプリケーションを構成します。

BEGIN
DBMS_STREAMS_ADM.MAINTAIN_SCHEMAS(
schema_names                 => 'hr',
source_directory_object      => 'hub_directory',
destination_directory_object => 'spoke1_directory',
source_database              => 'hub.example.com',
destination_database         => 'spoke1.example.com',
capture_name                 => 'capture_hns',
capture_queue_table          => 'source_hns_qt',
capture_queue_name           => 'source_hns',
propagation_name             => 'propagation_spoke1',
apply_name                   => 'apply_spoke1',
apply_queue_table            => 'destination_spoke1_qt',
apply_queue_name             => 'destination_spoke1',
bi_directional               => TRUE);
END;
/

MAINTAIN_SCHEMASプロシージャは多くの構成タスクを実行するため、実行に時間がかかる場合があります。プロシージャの実行中に宛先データベースのレプリケートされたデータベース・オブジェクトに対するデータ操作言語(DML)またはデータ定義言語(DDL)変更を許可しないでください。

MAINTAIN_SCHEMASプロシージャの必須パラメータは、schema_names、source_directory_object、destination_directory_object、source_databaseおよびdestination_databaseのみです。また、構成プロシージャを使用して双方向のレプリケーションを構成する場合は、bi_directionalパラメータをTRUEに設定する必要があります。

この例では、他のパラメータを指定して、取得プロセス、取得プロセスのキュー表、取得プロセスのキュー、伝播、適用プロセス、適用プロセスのキュー表および適用プロセスのキューの名前を選択可能であることを示しています。これらのパラメータを指定しない場合は、システム生成名が使用されます。

構成プロシージャの実行時、そのプロシージャの進捗に関する情報は、データ・ディクショナリ・ビューDBA_RECOVERABLE_SCRIPT、DBA_RECOVERABLE_SCRIPT_PARAMS、DBA_RECOVERABLE_SCRIPT_BLOCKSおよびDBA_RECOVERABLE_SCRIPT_ERRORSに記録されます。プロシージャでエラーが発生してプロシージャが停止した場合は、『Oracle Streamsレプリケーション管理者ガイド』でDBMS_STREAMS_ADMパッケージのRECOVER_OPERATIONプロシージャを使用したこれらのエラーからのリカバリ手順を参照してください。

5. SQL*Plusで引き続きOracle Streams管理者としてhub.example.comデータベースに接続したままで、MAINTAIN_SCHEMASプロシージャを実行して、hub.example.comデータベースとspoke2.example.comデータベースの間にレプリケーションを構成します。

BEGIN
DBMS_STREAMS_ADM.MAINTAIN_SCHEMAS(
schema_names                 => 'hr',
source_directory_object      => 'hub_directory',
destination_directory_object => 'spoke2_directory',
source_database              => 'hub.example.com',
destination_database         => 'spoke2.example.com',
capture_name                 => 'capture_hns',
capture_queue_table          => 'source_hns_qt',
capture_queue_name           => 'source_hns',
propagation_name             => 'propagation_spoke2',
apply_name                   => 'apply_spoke2',
apply_queue_table            => 'destination_spoke2_qt',
apply_queue_name             => 'destination_spoke2',
bi_directional               => TRUE);
END;
/

6. hub.example.com、spoke1.example.comおよびspoke2.example.comデータベースのhrスキーマにあるすべての表に対して最新時刻競合解消を構成します。このスキーマには、countries、departments、employees、jobs、job_history、locationsおよびregionsの表が含まれています。手順については、第9章「Oracle Streamsの競合解消」を参照してください。

関連項目:
Oracle Enterprise Managerを使用してこのレプリケーション環境を構成する場合の例は、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

Oracle Streams構成の進捗の監視

DBMS_STREAMS_ADMパッケージの次のプロシージャでは、Oracle Streamsによってメンテナンスされるレプリケーション環境が構成されます。

- MAINTAIN_GLOBAL

- MAINTAIN_SCHEMAS

- MAINTAIN_SIMPLE_TTS

- MAINTAIN_TABLES

- MAINTAIN_TTS

- PRE_INSTANTIATION_SETUPおよびPOST_INSTANTIATION_SETUP

perform_actionsパラメータをTRUEに設定して、これらのいずれかのプロシージャでレプリケーション環境を直接構成すると、別のターミナル・ウィンドウで構成の進捗を監視できます。

次の手順を実行して、Oracle Streams構成の進捗を監視します。

1. SQL*Plusで、Oracle Streams管理者として取得データベースに接続します。構成プロシージャを実行しているウィンドウとは別のターミナル・ウィンドウを使用します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

2. 構成操作の基本的な情報については、次の問合せを実行します。

COLUMN SCRIPT_ID      HEADING 'Script ID'      FORMAT A40
COLUMN CREATION_TIME  HEADING 'Creation|Time'  FORMAT A20

SELECT SCRIPT_ID,
TO_CHAR(CREATION_TIME,'HH24:Mi:SS MM/DD/YY') CREATION_TIME
FROM DBA_RECOVERABLE_SCRIPT;

出力は次のようになります。

Creation
Script ID                                Time
---------------------------------------- --------------------
64EE0DFCC374CE7EE040578C89174D3E         07:46:54 03/12/09

この出力には、構成操作のスクリプトIDおよび操作が開始された時間が示されています。

3. 構成操作の進捗の詳細は、次の問合せを実行します。

COLUMN STATUS           HEADING 'Status'          FORMAT A12
COLUMN PROGRESS         HEADING 'Steps|Completed' FORMAT A10
COLUMN ELAPSED_SECONDS  HEADING 'Elapsed|Seconds' FORMAT A10
COLUMN CURRENT_STEP     HEADING 'Current Step'    FORMAT A20
COLUMN PROCEDURE        HEADING 'Procedure'       FORMAT A20

SELECT  rs.STATUS,
rs.DONE_BLOCK_NUM||' of '||rs.TOTAL_BLOCKS PROGRESS,
TO_CHAR(TO_NUMBER(SYSDATE-rs.CREATION_TIME)*86400,9999.99) ELAPSED_SECONDS,
SUBSTR(TO_CHAR(rsb.FORWARD_BLOCK),1,100) CURRENT_STEP,
rs.INVOKING_PACKAGE||'.'||rs.INVOKING_PROCEDURE PROCEDURE
FROM DBA_RECOVERABLE_SCRIPT rs, DBA_RECOVERABLE_SCRIPT_BLOCKS rsb
WHERE rs.SCRIPT_ID  = rsb.SCRIPT_ID AND
rsb.BLOCK_NUM = rs.DONE_BLOCK_NUM + 1;

出力は次のようになります。

Steps      Elapsed
Status       Completed  Seconds    Current Step         Procedure
------------ ---------- ---------- -------------------- --------------------
EXECUTING    7 of 39    132        --                   DBMS_STREAMS_ADM.MAI
-- Set up queue "STR NTAIN_SCHEMAS
MADMIN"."PROD$APPQ"
--
BEGIN
dbms_streams_adm.s
et_up_queue(
queue_ta

この出力には、構成操作に関する次の情報が示されています。

- 構成操作の現在の状態(GENERATING、NOT EXECUTED、EXECUTING、EXECUTEDまたはERROR)

- 完了した手順の数、および操作を完了するために必要な手順の合計数

- 構成操作が実行されている時間数(秒単位)

- 現在の手順によって実行されている操作

- 現在の手順で実行されているPL/SQLプロシージャ

関連項目:
「操作エラーからのリカバリ」

3 Oracle Streamsレプリケーションの柔軟な構成

この章では、柔軟な方法を使用した2つ以上のデータベース間でのOracle Streamsレプリケーションの構成について説明します。この章では、単一ソースまたは複数ソースのレプリケーション環境を構築するために各Oracle Streamsコンポーネントを構成する方法を手順ごとに説明します。

一般的なタイプの単一ソース・レプリケーション環境としては、レプリケートされたデータベース・オブジェクトへの変更がスポーク・データベースで許可されていないハブ・アンド・スポーク・レプリケーション環境があります。一般的なタイプの複数ソース・レプリケーション環境は、次のとおりです。

- レプリケートされたデータベース・オブジェクトへの変更がスポーク・データベースで許可されているハブ・アンド・スポーク・レプリケーション環境

- n-wayレプリケーション環境

これらの一般的なタイプのレプリケーション環境の詳細は、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

可能な場合は、第2章「Oracle Streamsレプリケーションの簡単な構成」で説明した、簡単な方法を使用してOracle Streamsレプリケーションを構成することを検討してください。Enterprise ManagerのOracle StreamsツールまたはDBMS_STREAMS_ADMパッケージの1つのプロシージャのみを使用して、2つのデータベースを含むレプリケーション環境内のすべてのOracle Streamsコンポーネントを構成できます。また、次のいずれかの簡単な方法を使用しても、レプリケーション環境のカスタム要件を満たすことができます。

- 構成スクリプトを生成し、要件を満たすようにスクリプトを変更します。

- 2つのデータベース間でOracle Streamsレプリケーションを構成し、第4章「Oracle Streamsレプリケーション環境への追加」の手順を実行して新しいデータベース・オブジェクトまたはデータベースを環境に追加します。

ただし、Oracle Streamsレプリケーションの構成で、簡単な方法より高い柔軟性が必要な場合は、この章の手順を実行して環境を構成します。

この章の内容は次のとおりです。

- 新規の単一ソースOracle Streams環境の作成

- 新規の複数ソースOracle Streams環境の作成

注意:

- ここで説明する手順は、DBMS_STREAMS_ADMパッケージを使用してOracle Streams環境を構成する場合を想定しています。他のパッケージを使用する場合は、タスクごとに追加の手順が必要になることがあります。

- 特定のタイプのデータベース・オブジェクトは、Oracle Streamsではサポートされません。Oracle Streams環境を構成する場合、取得プロセスが、サポートされていないデータベース・オブジェクトに対する変更の取得を試行しないことを確認します。また、同期取得または適用プロセスが、サポートされていない列に対する変更の処理を試行しないことも確認します。サポートされていないデータベース・オブジェクトおよび列を表示するには、DBA_STREAMS_UNSUPPORTEDおよびDBA_STREAMS_COLUMNSデータ・ディクショナリ・ビューを問い合せます。

関連項目:
Oracle Streamsによってサポートされていないデータベース・オブジェクトを判別する手順については、『Oracle Streams概要および管理』を参照してください。

新規の単一ソースOracle Streams環境の作成

この項では、新規の単一ソースOracle Streams環境を作成する場合の一般的な手順について説明します。単一ソース環境とは、レプリケートされたデータのソース・データベースが1つのみの環境です。単一ソース環境に複数のソース・データベースが存在する場合もありますが、2つのソース・データベースが同じデータを取得することはありません。単一ソース環境の例としては、2つのデータベースを使用する一方向レプリケーション環境があります。

新規のOracle Streams環境で取得プロセスを起動して同期取得を作成し、伝播を構成する前に、LCRを受信する伝播または適用プロセスが、これらのLCRを処理するように構成されていることを確認してください。つまり、伝播または適用プロセスが存在し、それぞれがLCRを適切に処理するルール・セットに関連付けられている必要があります。これらの伝播と適用プロセスがこれらのLCRを処理するように適切に構成されていないと、LCRが失われる可能性があります。

この例では、レプリケートされたデータベース・オブジェクトが宛先データベースで読取り専用であることを想定しています。レプリケートされたデータベース・オブジェクトが宛先データベースで読取り/書込み可能である場合、宛先データベースのレプリケート・オブジェクトに対して行われた変更をレプリケートするようにOracle Streamsが構成されないため、レプリケーション環境では同期状態が保たれません。

図3-1に、単一ソースのOracle Streamsレプリケーション環境の例を示します。

図3-1 単一ソースのOracle Streams環境の例

図3-1に示されているものより複雑なOracle Streamsレプリケーション環境を作成することもできます。たとえば、単一ソースのOracle Streamsレプリケーション環境ではダウンストリームの取得および有向ネットワークを使用できます。

通常、レプリケートされたデータベース・オブジェクトに対する変更が1つのデータベースで取得されてから、リモート・データベースに伝播され、そこで適用される新規の単一ソースOracle Streams環境を構成する場合は、環境を次の順序で構成する必要があります。

1. レプリケーション環境の構成に関する必要な決定を行います。「Oracle Streamsレプリケーションを構成する前に行う決定」を参照してください。

2. 次に示す必要なタスクを完了し、Oracle Streams用の環境内で各データベースを準備します。「Oracle Streamsレプリケーションを構成する前に実行するタスク」を参照してください。
これらのタスクの一部は、一部のデータベースでは不要な場合があります。

3. 必要なANYDATAキューを作成します(存在しない場合)。取得プロセス、同期取得または適用プロセスを作成するときに、そのプロセスを特定のANYDATAキューに関連付けます。伝播を作成するときには、その伝播を特定のソース・キューおよび宛先キューに関連付けます。手順については、「ANYDATAキューの作成」を参照してください。

4. 任意のレプリケートされたデータベース・オブジェクトについて、各ソース・データベースでサプリメンタル・ロギングを指定します。手順については、「サプリメンタル・ロギングの指定」を参照してください。

5. 各データベースで、環境に必要な取得プロセス、同期取得、伝播および適用プロセスを作成します。取得プロセス、伝播および適用プロセスは任意の順序で作成できます。同期取得を作成する場合は、関連する伝播および適用プロセスの作成後に作成してください。

- 取得プロセスによって変更を取得する各データベースで、1つ以上の取得プロセスを作成します。各取得プロセスで、変更の取得に適切なルール・セットが使用されることを確認します。作成した取得プロセスは起動しないでください。各ソース・データベースには1つのみの取得プロセスを使用することをお薦めします。手順については、「取得プロセスの構成」を参照してください。
DBMS_STREAMS_ADMパッケージのプロシージャを使用して取得プロセスのルールを追加すると、その取得プロセスがソース・データベースへのデータベース・リンクを持つローカル取得プロセスまたはダウンストリーム取得プロセスである場合は、指定した表、指定したスキーマまたはデータベース全体に対して、それぞれDBMS_CAPTURE_ADMパッケージのPREPARE_TABLE_INSTANTIATION、PREPARE_SCHEMA_INSTANTIATIONまたはPREPARE_GLOBAL_INSTANTIATIONプロシージャが自動的に実行されます。

次のいずれかの条件に該当する場合は、適切なプロシージャを実行してインスタンス化の準備を手動で行う必要があります。

- DBMS_RULE_ADMパッケージを使用してルールを追加または変更する場合。

- 既存の取得プロセスを使用し、レプリケート・オブジェクトの取得プロセスのルールは追加しない場合。

- ソース・データベースへのデータベース・リンクを持たないダウンストリーム取得プロセスを使用する場合。

インスタンス化の準備を手動で行う必要がある場合の手順については、「ソース・データベースでインスタンス化を行うためのデータベース・オブジェクトの準備」を参照してください。

- 取得LCRをソース・キューから宛先キューに送信する伝播をすべて作成します。各伝播で変更の送信に適切なルール・セットが使用されることを確認します。手順については、「ANYDATAキュー間のOracle Streamsの伝播の作成」を参照してください。

- 変更を適用する各データベースで、1つ以上の適用プロセスを作成します。各適用プロセスで、変更の適用に適切なルール・セットが使用されることを確認します。作成した適用プロセスは起動しないでください。手順については、第7章「暗黙的適用の構成」を参照してください。

- 同期取得によって変更を取得する各データベースで、1つ以上の同期取得を作成します。各同期取得で、変更の取得に適切なルール・セットが使用されることを確認します。同期取得は、そのLCRを処理するすべての伝播および適用プロセスを作成するまで作成しないでください。手順については、「同期取得の構成」を参照してください。
DBMS_STREAMS_ADMパッケージのプロシージャを使用して同期取得のルールを追加すると、指定した表に対してDBMS_CAPTURE_ADMパッケージのPREPARE_SYNC_INSTANTIATIONファンクションが自動的に実行されます。

6. 適用プロセスによって変更が適用される各データベース・オブジェクトをインスタンス化するか、そのインスタンス化SCNを設定します。宛先データベースにデータベース・オブジェクトが存在しない場合は、エクスポート/インポート、トランスポータブル表領域またはRMANを使用してインスタンス化します。宛先データベースにデータベース・オブジェクトが存在する場合は、そのインスタンス化SCNを手動で設定します。

- エクスポート/インポートを使用してデータベース・オブジェクトをインスタンス化するには、まずソース・データベースでそれらのデータベース・オブジェクトをエクスポートします。次に、宛先データベースでそれらのオブジェクトをインポートします。第8章「インスタンス化とOracle Streamsレプリケーション」を参照してください。
ソース・データベースでのエクスポート中、エクスポートされるデータベース・オブジェクトに対する変更は許可しないでください。宛先データベースでのインポート中、インポートされるデータベース・オブジェクトに対する変更は許可しないでください。

FLASHBACK_SCNやFLASHBACK_TIMEなどのエクスポート・パラメータを使用して、より厳密な一貫性レベルを指定できます。

- 表、スキーマまたはデータベースのインスタンス化SCNを手動で設定するには、宛先データベースでDBMS_APPLY_ADMパッケージの適切なプロシージャを1つ以上実行します。

- SET_TABLE_INSTANTIATION_SCN

- SET_SCHEMA_INSTANTIATION_SCN

- SET_GLOBAL_INSTANTIATION_SCN

これらのプロシージャのいずれかを実行する場合は、宛先データベースのレプリケート・オブジェクトに、インスタンス化SCNの時点でソース・データベースとの一貫性があることを確認する必要があります。

宛先データベースでSET_GLOBAL_INSTANTIATION_SCNを実行する場合、宛先データベースの各スキーマおよびそれらのスキーマが所有する表にもインスタンス化SCNが設定されるように、このプロシージャのrecursiveパラメータをTRUEに設定します。

宛先データベースでSET_SCHEMA_INSTANTIATION_SCNを実行する場合、スキーマ内の各表にもインスタンス化SCNが設定されるように、このプロシージャのrecursiveパラメータをTRUEに設定します。

SET_GLOBAL_INSTANTIATION_SCNプロシージャまたはSET_SCHEMA_INSTANTIATION_SCNプロシージャでrecursiveパラメータをTRUEに設定する場合は、宛先データベースからソース・データベースへのデータベース・リンクが必要です。このデータベース・リンクはソース・データベースのグローバル名と同じ名前であり、プロシージャを実行するユーザーからアクセス可能である必要があります。手順については、「DBMS_APPLY_ADMパッケージを使用したインスタンス化SCNの設定」を参照してください。

または、メタデータのエクスポート/インポートを実行して、既存のデータベース・オブジェクトについてインスタンス化SCNを設定できます。このオプションを選択した場合は、行がインポートされないことを確認してください。また、すべての宛先データベースのレプリケートされたデータベース・オブジェクトに、エクスポートを実行したソース・データベースとのエクスポート時点での一貫性があることを確認してください。DML変更のみを共有する場合は、表レベルのエクスポート/インポートで十分です。DDL変更も共有する場合は、追加の考慮事項があります。メタデータのエクスポート/インポートを実行する方法の詳細は、「エクスポート/インポートを使用したインスタンス化SCNの設定」を参照してください。

7. DBMS_APPLY_ADMパッケージのSTART_APPLYプロシージャを使用して、手順5で作成した各適用プロセスを起動します。

8. DBMS_CAPTURE_ADMパッケージのSTART_CAPTUREプロシージャを使用して、手順5で作成した各取得プロセスを起動します。

環境を構成するときには、取得プロセスおよび適用プロセスの作成時にこれらのプロセスが停止していることに注意してください。ただし、同期取得は作成すると即時に変更の取得を開始し、伝播は作成すると即時にLCRを送信するようにスケジュールされます。取得プロセスまたは同期取得は、リモートの宛先データベースで関連オブジェクトをインスタンス化する前に作成する必要があります。取得プロセスの起動または同期取得の作成の前に伝播と適用プロセスを作成し、ストリーム全体を実行する前にオブジェクトをインスタンス化してください。

関連項目:

- 単一ソース環境を設定する場合の詳細な例は、『Oracle Streams拡張例』を参照してください。

新規の複数ソースOracle Streams環境の作成

この項では、新規の複数ソースOracle Streams環境を作成する場合の一般的な手順について説明します。複数ソース環境とは、レプリケートされたデータに複数のソース・データベースが存在する環境です。複数ソース環境の例としては、n-wayレプリケーション環境があります。

この例では、次の用語を使用しています。

- 実装済データベース: 新規の複数ソース環境を作成する前に、レプリケートされたデータベース・オブジェクトがすでに含まれているデータベース。新規のOracle Streams環境を作成するには、1つ以上の実装済データベースが必要です。

- エクスポート・データベース: レプリケートされたデータベース・オブジェクトのエクスポートを実行する実装済データベース。このエクスポートを使用して、レプリケートされたデータベース・オブジェクトがインポート・データベースでインスタンス化されます。すべてのデータベースが実装済データベースである環境では、エクスポート・データベースが存在しないことがあります。

- インポート・データベース: 新規の複数ソース環境を作成する前には、レプリケートされたデータベース・オブジェクトが含まれていないデータベース。レプリケートされたデータベース・オブジェクトのインポートを実行して、そのデータベース・オブジェクトをインポート・データベースでインスタンス化します。すべてのデータベースが実装済データベースである環境では、インポート・データベースが存在しないことがあります。

図3-2に、複数ソースのOracle Streams環境の例を示します。

図3-2 複数ソースのOracle Streams環境の例

図3-2に示されているものより複雑なOracle Streamsレプリケーション環境を作成することもできます。たとえば、複数ソースOracle Streamsレプリケーション環境ではダウンストリームの取得および有向ネットワークを使用できます。

Oracle Streamsレプリケーション環境に複数のソース・データベースが存在する場合、変更の循環が発生する可能性があります。変更の循環は、変更が発生場所であるデータベースに再送されると発生します。通常は、変更の循環を回避する必要があります。レプリケーション環境を構成する前に、第10章「Oracle Streamsタグ」を参照して、変更の循環が回避されるようにレプリケーション環境を構成してください。

次の手順に従って複数ソース環境を作成します。

注意:
Oracle Streams環境に追加するデータベースでは、そのデータベースでのインスタンス化が完了するまでは、共有されるオブジェクトに対して変更が行われないことを確認してください。

1. レプリケーション環境の構成に関する必要な決定を行います。「Oracle Streamsレプリケーションを構成する前に行う決定」を参照してください。

2. 次に示す必要なタスクを完了し、Oracle Streams用の環境内で各データベースを準備します。「Oracle Streamsレプリケーションを構成する前に実行するタスク」を参照してください。
これらのタスクの一部は、一部のデータベースでは不要な場合があります。

3. 各実装済データベースで、レプリケートされたデータベース・オブジェクトに必要なサプリメンタル・ロギングを指定します。手順については、「サプリメンタル・ロギングの指定」を参照してください。

4. 必要なANYDATAキューを作成します(存在しない場合)。取得プロセス、同期取得または適用プロセスを作成するときに、そのプロセスを特定のANYDATAキューに関連付けます。伝播を作成するときには、その伝播を特定のソース・キューおよび宛先キューに関連付けます。手順については、「ANYDATAキューの作成」を参照してください。

5. 各データベースで、環境に必要な取得プロセス、同期取得、伝播および適用プロセスを作成します。取得プロセス、伝播および適用プロセスは任意の順序で作成できます。同期取得を作成する場合は、関連する伝播および適用プロセスの作成後に作成してください。

- 取得プロセスによって変更を取得する各データベースで、1つ以上の取得プロセスを作成します。各取得プロセスで、変更の取得に適切なルール・セットが使用されることを確認します。作成した取得プロセスは起動しないでください。各ソース・データベースには1つのみの取得プロセスを使用することをお薦めします。手順については、「取得プロセスの構成」を参照してください。
DBMS_STREAMS_ADMパッケージのプロシージャを使用して取得プロセスのルールを追加すると、その取得プロセスがソース・データベースへのデータベース・リンクを持つローカル取得プロセスまたはダウンストリーム取得プロセスである場合は、指定した表、指定したスキーマまたはデータベース全体に対して、それぞれDBMS_CAPTURE_ADMパッケージのPREPARE_TABLE_INSTANTIATION、PREPARE_SCHEMA_INSTANTIATIONまたはPREPARE_GLOBAL_INSTANTIATIONプロシージャが自動的に実行されます。

次のいずれかの条件に該当する場合は、適切なプロシージャを実行してインスタンス化の準備を手動で行う必要があります。

- DBMS_RULE_ADMパッケージを使用してルールを追加または変更する場合。

- 既存の取得プロセスを使用し、レプリケートされたデータベース・オブジェクトの取得プロセスのルールは追加しない場合。

- ソース・データベースへのデータベース・リンクを持たないダウンストリーム取得プロセスを使用する場合。

インスタンス化の準備を手動で行う必要がある場合の手順については、「ソース・データベースでインスタンス化を行うためのデータベース・オブジェクトの準備」を参照してください。

- 取得LCRをソース・キューから宛先キューに伝播する伝播をすべて作成します。各伝播で変更の伝播に適切なルール・セットが使用されることを確認します。手順については、「ANYDATAキュー間のOracle Streamsの伝播の作成」を参照してください。

- 変更を適用する各データベースで、1つ以上の適用プロセスを作成します。各適用プロセスで、変更の適用に適切なルール・セットが使用されることを確認します。作成した適用プロセスは起動しないでください。手順については、第7章「暗黙的適用の構成」を参照してください。

- 同期取得によって変更を取得する各データベースで、1つ以上の同期取得を作成します。各同期取得で、変更の取得に適切なルール・セットが使用されることを確認します。同期取得は、そのLCRを処理するすべての伝播および適用プロセスを作成するまで作成しないでください。手順については、「同期取得の構成」を参照してください。
DBMS_STREAMS_ADMパッケージのプロシージャを使用して同期取得のルールを追加すると、指定した表に対してDBMS_CAPTURE_ADMパッケージのPREPARE_SYNC_INSTANTIATIONファンクションが自動的に実行されます。

前述の手順を完了してから、環境に応じて次の各項の手順を完了します。各項の一方の手順のみを完了すればよい場合と、両方の手順を完了する必要がある場合があります。

- 各実装済データベースには、「複数ソース環境の作成時の実装済データベースの構成」の手順を実行します。この手順は、環境に複数の実装済データベースが存在する場合にのみ必要です。

- 各インポート・データベースには、「新規環境作成時のインポート・データベースへのレプリケート・オブジェクトの追加」の手順を実行します。

複数ソース環境の作成時の実装済データベースの構成

環境に複数の実装済データベースが存在する場合は、「新規の複数ソースOracle Streams環境の作成」の手順を実行してから、実装済データベースについて次の手順を実行します。

1. 実装済データベースごとに、実装済ソース・データベースの宛先データベースとなる環境内の他の各実装済データベースで、インスタンス化SCNを設定します。これらのインスタンス化SCNの設定は必須であり、特定の実装済データベースで行われた、そのデータベースの対応するSCNより後にコミットされる変更のみが、もう一方の実装済データベースに適用されます。
実装済データベースごとに、これらのインスタンス化SCNを次のいずれかの方法で設定できます。

- レプリケートされたデータベース・オブジェクトのメタデータのみのエクスポートを実装済データベースで実行し、そのメタデータを他のそれぞれの実装済データベースでインポートします。このインポートによって、実装済データベースに必須のインスタンス化SCNが、他の実装済データベースで設定されます。行がインポートされないことを確認してください。また、メタデータのインポートを実行する各実装済データベースのレプリケートされたデータベース・オブジェクトに、メタデータのエクスポートを実行した実装済データベースとのエクスポート時点での一貫性があることを確認してください。
DML変更のみをレプリケートする場合は、表レベルのエクスポート/インポートで十分です。DDL変更もレプリケートする場合は、追加の考慮事項があります。メタデータのエクスポート/インポートを実行する方法の詳細は、「エクスポート/インポートを使用したインスタンス化SCNの設定」を参照してください。

- 他の各実装済データベースで、インスタンス化SCNを手動で設定します。この操作はレプリケートされたデータベース・オブジェクトごとに行います。各実装済データベースのレプリケートされたデータベース・オブジェクトに、そのデータベースで設定したインスタンス化SCNとの一貫性があることを確認してください。手順については、「DBMS_APPLY_ADMパッケージを使用したインスタンス化SCNの設定」を参照してください。

新規環境作成時のインポート・データベースへのレプリケート・オブジェクトの追加

「新規の複数ソースOracle Streams環境の作成」の手順を完了した後に、インポート・データベースについて次の手順を実行します。

1. エクスポート・データベースとして使用する実装済データベースを選択します。まだインスタンス化は実行しないでください。

2. インポート・データベースごとに、インポート・データベースの宛先データベースとなる環境内の他のすべてのデータベースで、インスタンス化SCNを設定します。この場合、インポート・データベースがこれらの宛先データベースのソース・データベースになります。インスタンス化SCNを設定するデータベースには、実装済データベースと他のインポート・データベースが含まれることがあります。

1. インスタンス化中、またはその後のレプリケートされたDDLの変更によって、インポート・データベースで1つ以上のスキーマが作成される場合は、環境内の他のすべてのデータベースで、このインポート・データベースについてDBMS_APPLY_ADMパッケージのSET_GLOBAL_INSTANTIATION_SCNプロシージャを実行します。

2. インポート・データベースにスキーマが存在し、インスタンス化中、またはその後のレプリケートDDLの変更によって、そのスキーマに1つ以上の表が作成される場合は、環境内の他のすべてのデータベースで、このインポート・データベースのスキーマについてDBMS_APPLY_ADMパッケージのSET_SCHEMA_INSTANTIATION_SCNプロシージャを実行します。この操作は、この種のスキーマごとに行います。

手順については、「DBMS_APPLY_ADMパッケージを使用したインスタンス化SCNの設定」を参照してください。

これらのプロシージャは、インポート・データベースで表がインスタンス化される前に実行し、これらのインポート・データベースについてはローカルの取得プロセスまたは同期取得がすでに構成されているため、インスタンス化中に作成される表ごとにSET_TABLE_INSTANTIATION_SCNプロシージャを実行する必要はありません。インポート・データベースの宛先データベースとなる環境内の他のすべてのデータベースで、その表ごとにインスタンス化SCNが自動的に設定されます。

3. 手順1で選択したエクスポート・データベースで、レプリケートされたデータベース・オブジェクトのエクスポートを実行します。次に、各インポート・データベースでレプリケート・オブジェクトのインポートを実行します。エクスポート/インポートの使用方法の詳細は、第8章「インスタンス化とOracle Streamsレプリケーション」および『Oracle Databaseユーティリティ』を参照してください。

ソース・データベースでのデータベース・オブジェクトのエクスポート中、それらのデータベース・オブジェクトに対する変更は許可しないでください。宛先データベースでのデータベース・オブジェクトのインポート中、それらのデータベース・オブジェクトに対する変更は許可しないでください。

FLASHBACK_SCNやFLASHBACK_TIMEなどのエクスポート・パラメータを使用して、より厳密な一貫性レベルを指定できます。

4. エクスポート・データベース以外の実装済データベースごとに、実装済ソース・データベースの宛先データベースとなる各インポート・データベースにインスタンス化SCNを設定します。これらのインスタンス化SCNの設定は必須であり、実装済データベースで行われた、そのデータベースの対応するSCNより後にコミットされる変更のみがインポート・データベースに適用されます。
これらのインスタンス化SCNを設定するには、次の方法があります。

- 各実装済データベースでメタデータのみのエクスポートを実行し、そのメタデータを各インポート・データベースでインポートします。各インポートによって、実装済データベースに必須のインスタンス化SCNが、インポート・データベースで設定されます。この場合は、インポート・データベースのレプリケートされたデータベース・オブジェクトに、エクスポート時点で実装済データベースとの一貫性があることを確認してください。
DML変更のみを共有する場合は、表レベルのエクスポート/インポートで十分です。DDL変更も共有する場合は、追加の考慮事項があります。メタデータのエクスポート/インポートを実行する方法の詳細は、「エクスポート/インポートを使用したインスタンス化SCNの設定」を参照してください。

- 実装済データベースごとに、レプリケートされた各オブジェクトのインスタンス化SCNを各インポート・データベースで手動で設定します。各インポート・データベースのレプリケートされたデータベース・オブジェクトに、対応するインスタンス化SCNの時点で実装済データベースとの一貫性があることを確認してください。手順については、「DBMS_APPLY_ADMパッケージを使用したインスタンス化SCNの設定」を参照してください。

複数ソース環境の構成完了

この項の手順を完了する前に、次のタスクを完了している必要があります。

- 「新規の複数ソースOracle Streams環境の作成」

- 環境に複数の実装済データベースが存在する場合は、「複数ソース環境の作成時の実装済データベースの構成」

- 環境に1つ以上のインポート・データベースが存在する場合は、「新規環境作成時のインポート・データベースへのレプリケート・オブジェクトの追加」

前述の構成手順をすべて完了してから、次の手順を行います。

1. 競合が発生する可能性がある場合は、各データベースで競合解消を構成します。手順については、第9章「Oracle Streamsの競合解消」を参照してください。

2. DBMS_APPLY_ADMパッケージのSTART_APPLYプロシージャを使用して、環境内の各適用プロセスを起動します。

3. DBMS_CAPTURE_ADMパッケージのSTART_CAPTUREプロシージャを使用して、環境内の各取得プロセスを起動します。

関連項目:
複数ソース環境を作成する場合の詳細な例は、『Oracle Streams拡張例』を参照してください。

4 Oracle Streamsレプリケーション環境への追加

この章では、既存のOracle Streamsレプリケーション環境にデータベース・オブジェクトおよびデータベースを追加する方法について説明します。

この章の内容は次のとおりです。

- Oracle Streamsレプリケーション環境への追加について

- 単一のプロシージャを使用した複数のコンポーネントの追加

- 複数の手順でのコンポーネントの個別追加

注意:
特定のタイプのデータベース・オブジェクトは、Oracle Streamsではサポートされません。Oracle Streams環境を拡張する場合、取得プロセスが、サポートされていないデータベース・オブジェクトに対する変更の取得を試行しないことを確認します。また、同期取得または適用プロセスが、サポートされていない列に対する変更の処理を試行しないことも確認します。サポートされていないデータベース・オブジェクトおよび列を表示するには、DBA_STREAMS_UNSUPPORTEDおよびDBA_STREAMS_COLUMNSデータ・ディクショナリ・ビューを問い合せます。

関連項目:

- 第2章「Oracle Streamsレプリケーションの簡単な構成」

- 第3章「Oracle Streamsレプリケーションの柔軟な構成」

- Oracle Streamsによってサポートされていないデータベース・オブジェクトを判別する手順については、『Oracle Streams概要および管理』を参照してください。

Oracle Streamsレプリケーション環境への追加について

組織でのニーズが変化すると、Oracle Streamsレプリケーション環境の拡張が必要な場合があります。Oracle Streamsレプリケーション環境は、データベース・オブジェクトまたはデータベースを追加することによって拡張できます。

Oracle Streamsレプリケーション環境の拡張には次の3つの方法があります。

- Streamsレプリケーションの設定ウィザードまたは単一の構成プロシージャの使用について

- 複数の手順でのOracle Streamsコンポーネントの個別追加について

Streamsレプリケーションの設定ウィザードまたは単一の構成プロシージャの使用について

Oracle Streamsレプリケーション環境を簡単に拡張するには次の2つの方法があります。

- Oracle Enterprise ManagerでStreamsレプリケーションの設定ウィザードを実行

- DBMS_STREAMS_ADMパッケージにある次のいずれかのプロシージャを実行

- MAINTAIN_GLOBALプロシージャ: データベース内のすべてのデータベース・オブジェクトに対する変更をレプリケートする環境に新規データベースを追加できます。

- MAINTAIN_SCHEMASプロシージャ: レプリケーション環境の既存データベースに1つ以上の新規スキーマを追加するか、または現在レプリケートされているスキーマをレプリケートする新規データベースを追加できます。

- MAINTAIN_SIMPLE_TTSプロシージャ: 既存のレプリケーション環境に新しい単一の表領域を追加するか、または現在レプリケートされている単一の表領域をレプリケートする新規データベースを追加できます。

- MAINTAIN_TABLESプロシージャ: レプリケーション環境の既存データベースに1つ以上の新しい表を追加するか、現在レプリケートされている表をレプリケートする新規データベースを追加できます。

- MAINTAIN_TTSプロシージャ: 既存のレプリケーション環境に新しい表領域セットを追加するか、または現在レプリケートされている表領域セットをレプリケートする新規データベースを追加できます。

これらの方法のいずれかを使用してOracle Streamsレプリケーション環境を拡張するには、環境が次の条件を満たしている必要があります。

- Streamsレプリケーションの設定ウィザードまたはDBMS_STREAMS_ADMパッケージのいずれかの構成プロシージャで構成された、2データベース・レプリケーション環境またはハブ・アンド・スポーク・レプリケーション環境である必要があります。これらのタイプのレプリケーション環境の詳細は、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

- Oracle Streamsレプリケーション環境のデータベースでは同期取得を使用できません。同期取得の詳細は、『Oracle Streams概要および管理』を参照してください。

- 環境にデータベースを追加する場合、変更を取得する各データベースはローカル取得プロセスを使用する必要があります。どのデータベースでもダウンストリーム取得プロセスは使用できません。環境に1つ以上のデータベース・オブジェクトを追加する場合は、データベースでローカルかダウンストリームのいずれかの取得プロセスを使用できます。ダウンストリーム取得の詳細は、「ソース・データベースに対してローカル取得またはダウンストリーム取得を構成するかどうかの決定」を参照してください。

- レプリケーション環境にデータベース・オブジェクトを追加する場合、そのデータベース・オブジェクトは、構成プロシージャのsource_databaseパラメータで指定されたデータベースに存在する必要があります。

環境がこれらの条件を満たしている場合は、Streamsレプリケーションの設定ウィザードまたは単一のプロシージャを使用して環境を拡張できます。

次は、ウィザードまたはプロシージャを実行する前に、レプリケートされたデータベース・オブジェクトが対象とする宛先データベースにすでに存在する場合の追加要件です。

- レプリケーション環境にデータベース・オブジェクトを追加する場合に、1つ以上のデータベース・オブジェクトがソース・データベース以外のデータベースに存在するときは、次の要件を満たす必要があります。

- ウィザードまたはプロシージャを実行する前に、各宛先データベースのレプリケートされたデータベース・オブジェクトに、ソース・データベースのレプリケートされたデータベース・オブジェクトとの一貫性があることを確認します。

- ウィザードまたはプロシージャを実行した後、各宛先データベースのレプリケートされたデータベース・オブジェクトそれぞれにインスタンス化SCNが設定されていることを確認します。「宛先データベースでのインスタンス化SCNの設定」および「インスタンス化の監視」を参照してください。

- レプリケーション環境にデータベースを追加する場合に、追加されるデータベースに現在の環境でレプリケーションされたデータベース・オブジェクトが存在するときは、次の要件を満たす必要があります。

- ウィザードまたはプロシージャを実行する前に、追加される各データベースのレプリケートされたデータベース・オブジェクトに、ソース・データベースのレプリケートされたデータベース・オブジェクトとの一貫性があることを確認します。

- ウィザードまたはプロシージャを実行した後、追加されたデータベースのレプリケートされたデータベース・オブジェクトそれぞれにインスタンス化SCNが設定されていることを確認します。「宛先データベースでのインスタンス化SCNの設定」および「インスタンス化の監視」を参照してください。

ウィザードまたは単一のプロシージャを使用してレプリケーション環境に追加する手順については、次のマニュアルを参照してください。

- Streamsレプリケーションの設定ウィザードを使用する手順については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

- DBMS_STREAMS_ADMパッケージの単一のプロシージャを使用する手順については、「単一のプロシージャを使用した複数のコンポーネントの追加」を参照してください。

関連項目:
DBMS_STREAMS_ADMの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

複数の手順でのOracle Streamsコンポーネントの個別追加について

Streamsレプリケーションの設定ウィザード、またはDBMS_STREAMS_ADMパッケージの構成プロシージャを使用してOracle Streamsレプリケーション環境を拡張できない場合は、構成手順を手動で完了する必要があります。この手順には、必要なルールとOracle Streamsコンポーネントを環境に追加するなどの構成手順が含まれます。

Oracle Streamsレプリケーション環境を手動で拡張する必要がある場合は、「複数の手順でのコンポーネントの個別追加」で説明されている手順を参照してください。

単一のプロシージャを使用した複数のコンポーネントの追加

この項では、DBMS_STREAMS_ADMパッケージの単一のPL/SQLプロシージャを使用したOracle Streamsコンポーネントの追加について説明します。Oracle Streamsコンポーネントには、キュー、ルール、ルール・セット、取得プロセス、同期取得、伝播および適用プロセスが含まれます。

この項の内容は次のとおりです。

- 単一のプロシージャを使用したレプリケーション環境へのデータベース・オブジェクトの追加

- 単一のプロシージャを使用したレプリケーション環境へのデータベースの追加

単一のプロシージャを使用したレプリケーション環境へのデータベース・オブジェクトの追加

このトピックには、DBMS_STREAMS_ADMパッケージのMAINTAIN_TABLESプロシージャを使用して、既存のハブ・アンド・スポーク・レプリケーション環境に表を追加する例が含まれます。この例を完了すると、Oracle Streamsレプリケーション環境によって、その環境のデータベースに追加された表に対する変更がレプリケートされます。

具体的には、このトピックの例では、「ハブ・アンド・スポーク・レプリケーションを構成する例」で構成したレプリケーション環境を拡張します。この構成には、次のような特徴があります。

- hrスキーマが、hub.example.com、spoke1.example.com、およびspoke2.example.comの各データベースでレプリケートされます。

- hub.example.comデータベースが、ハブ・アンド・スポーク環境におけるハブ・データベースであり、他のデータベースがスポーク・データベースです。

- スポーク・データベースでは、レプリケートされたスキーマへの変更が可能で、各データベースはそのローカル取得プロセスでこれらの変更を取得します。

- 競合を解消するために、各データベースでレプリケートされた各表に、更新競合ハンドラが構成されます。

この例では、環境に次の表を追加します。

- oe.orders

- oe.order_items

この例ではoeサンプル・スキーマにある表を使用します。oeサンプル・スキーマはOracle Databaseとともにデフォルトでインストールされます。

注意:
DBMS_STREAMS_ADMパッケージの構成プロシージャを使用してOracle Streamsレプリケーション環境を拡張する前に、「Streamsレプリケーションの設定ウィザードまたは単一の構成プロシージャの使用について」で説明されている条件を環境が満たしていることを確認してください。

手順は次のとおりです。

1. 次のディレクトリ・オブジェクトが存在することを確認し、これらのオブジェクトから前の構成に関連するファイル(データ・ポンプ・エクスポート・ダンプ・ファイルおよびエクスポート・ログ・ファイルを含む)をすべて削除します。

- hub.example.comデータベースのhub_dirディレクトリ・オブジェクト。

- spoke1.example.comデータベースのspoke1_dirディレクトリ・オブジェクト。

- spoke2.example.comデータベースのspoke2_dirディレクトリ・オブジェクト。

2. ハブ・アンド・スポーク環境で、ハブ・データベースの取得プロセスを停止します。

取得プロセスを停止するには、DBMS_CAPTURE_ADMパッケージのSTOP_CAPTUREプロシージャを使用します。または、Oracle Enterprise Managerを使用して取得プロセスを停止する手順については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

この例では、hub.example.comデータベースの取得プロセスを停止します。取得プロセスの停止中、レプリケートされたデータベース・オブジェクトは変更に対してオープンなままにしておくことができます。これらの変更は、取得プロセスが再開されたときに取得されます。

3. SQL*Plusでは、ハブ・データベースでDBMS_STREAMS_ADMパッケージの適切な構成プロシージャを実行し、各スポーク・データベースに新規の各データベース・オブジェクトを追加します。
環境に複数のスポーク・データベースが存在する場合、このプロシージャを複数回実行しなければならない場合があります。この例では、次の手順を実行します。

1. SQL*Plusを開き、Oracle Streams管理者としてhub.example.comデータベースに接続します。
SQL*Plusの起動の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

2. hub.example.comとspoke1.example.comの間のレプリケーションを実行するために、MAINTAIN_TABLESプロシージャを実行して、oe.orders表およびoe.order_items表を追加します。

DECLARE
tables DBMS_UTILITY.UNCL_ARRAY;
BEGIN
tables(1) := 'oe.orders';
tables(2) := 'oe.order_items';
DBMS_STREAMS_ADM.MAINTAIN_TABLES(
table_names                  => tables,
source_directory_object      => 'hub_dir',
destination_directory_object => 'spoke1_dir',
source_database              => 'hub.example.com',
destination_database         => 'spoke1.example.com',
capture_name                 => 'capture_hns',
capture_queue_table          => 'source_hns_qt',
capture_queue_name           => 'source_hns',
propagation_name             => 'propagation_spoke1',
apply_name                   => 'apply_spoke1',
apply_queue_table            => 'destination_spoke1_qt',
apply_queue_name             => 'destination_spoke1',
bi_directional               => TRUE);
END;
/

MAINTAIN_TABLESプロシージャは多くの構成タスクを実行するため、実行に時間がかかる場合があります。プロシージャの実行中に宛先データベースの指定した表に対するデータ操作言語(DML)またはデータ定義言語(DDL)変更を許可しないでください。プロシージャが完了すると、環境に新しいデータベース・オブジェクトが追加され、手順2で停止されていた取得プロセスが再開されます。

構成プロシージャの実行時、そのプロシージャの進捗に関する情報は、データ・ディクショナリ・ビューDBA_RECOVERABLE_SCRIPT、DBA_RECOVERABLE_SCRIPT_PARAMS、DBA_RECOVERABLE_SCRIPT_BLOCKSおよびDBA_RECOVERABLE_SCRIPT_ERRORSに記録されます。プロシージャでエラーが発生してプロシージャが停止した場合は、『Oracle Streamsレプリケーション管理者ガイド』でDBMS_STREAMS_ADMパッケージのRECOVER_OPERATIONプロシージャを使用したこれらのエラーからのリカバリ手順を参照してください。

Oracle Streamsコンポーネント名を指定するパラメータ値は、レプリケーション環境を構成したDBMS_STREAMS_ADMパッケージの構成プロシージャで指定されている値と同じである必要があります。指定されるOracle Streamsコンポーネント名には、取得プロセス名、キュー名、キュー表名、伝播名および適用プロセス名が含まれます。この例では、Oracle Streamsコンポーネント名は、「ハブ・アンド・スポーク・レプリケーションを構成する例」で指定されている名前と一致します。

3. hub.example.comとspoke2.example.comの間のレプリケーションを実行するために、MAINTAIN_TABLESプロシージャを実行して、oe.orders表およびoe.order_items表を追加します。

DECLARE
tables DBMS_UTILITY.UNCL_ARRAY;
BEGIN
tables(1) := 'oe.orders';
tables(2) := 'oe.order_items';
DBMS_STREAMS_ADM.MAINTAIN_TABLES(
table_names                  => tables,
source_directory_object      => 'hub_dir',
destination_directory_object => 'spoke2_dir',
source_database              => 'hub.example.com',
destination_database         => 'spoke2.example.com',
capture_name                 => 'capture_hns',
capture_queue_table          => 'source_hns_qt',
capture_queue_name           => 'source_hns',
propagation_name             => 'propagation_spoke2',
apply_name                   => 'apply_spoke2',
apply_queue_table            => 'destination_spoke2_qt',
apply_queue_name             => 'destination_spoke2',
bi_directional               => TRUE);
END;
/

4. スポーク・データベースでレプリケートされた表のインスタンス化SCNを設定します。

注意:
この例でこの手順が必要なのは、MAINTAIN_TABLESプロシージャの実行前に、レプリケートされた表がスポーク・データベースに存在していたためです。MAINTAIN_TABLESプロシージャの実行前に、レプリケートされた表がスポーク・データベースに存在していなかった場合は、プロシージャによって、レプリケートされた表にインスタンス化SCNが設定されるため、この手順は必要ありません。インスタンス化SCNの設定時に共有表のデータがソース・データベースと宛先データベースで一貫していること、およびSCNがインスタンス化SCNに使用されるまでソース・データベースの表が変更されないことを確認します。

1. SQL*Plusで、Oracle Streams管理者としてhub.example.comデータベースに接続します。
SQL*Plusでのデータベースへの接続の詳細は、『Oracle Database管理者ガイド』を参照してください。

2. spoke1.example.comデータベースでoe.orders表のインスタンス化SCNを設定します。

DECLARE
iscn  NUMBER;    -- Variable to hold instantiation SCN value
BEGIN
iscn := DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER();
DBMS_APPLY_ADM.SET_TABLE_INSTANTIATION_SCN@spoke1.example.com(
source_object_name    => 'oe.orders',
source_database_name  => 'hub.example.com',
instantiation_scn     => iscn);
END;
/

3. spoke1.example.comデータベースでoe.order_items表のインスタンス化SCNを設定します。

DECLARE
iscn  NUMBER;    -- Variable to hold instantiation SCN value
BEGIN
iscn := DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER();
DBMS_APPLY_ADM.SET_TABLE_INSTANTIATION_SCN@spoke1.example.com(
source_object_name    => 'oe.order_items',
source_database_name  => 'hub.example.com',
instantiation_scn     => iscn);
END;
/

4. spoke2.example.comデータベースでoe.orders表のインスタンス化SCNを設定します。

DECLARE
iscn  NUMBER;    -- Variable to hold instantiation SCN value
BEGIN
iscn := DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER();
DBMS_APPLY_ADM.SET_TABLE_INSTANTIATION_SCN@spoke2.example.com(
source_object_name    => 'oe.orders',
source_database_name  => 'hub.example.com',
instantiation_scn     => iscn);
END;
/

5. spoke2.example.comデータベースでoe.order_items表のインスタンス化SCNを設定します。

DECLARE
iscn  NUMBER;    -- Variable to hold instantiation SCN value
BEGIN
iscn := DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER();
DBMS_APPLY_ADM.SET_TABLE_INSTANTIATION_SCN@spoke2.example.com(
source_object_name    => 'oe.order_items',
source_database_name  => 'hub.example.com',
instantiation_scn     => iscn);
END;
/

5. hub.example.com、spoke1.example.comおよびspoke2.example.comの各データベースのoeスキーマにあるorders表およびorder_items表に対して最新時刻競合解消を構成します。手順については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

単一のプロシージャを使用したレプリケーション環境へのデータベースの追加

このトピックには、DBMS_STREAMS_ADMパッケージのMAINTAIN_SCHEMASプロシージャを使用して、既存のハブ・アンド・スポーク・レプリケーション環境に新しいスポーク・データベースを追加する例が含まれます。この例を完了すると、Oracle Streamsレプリケーション環境によって、新しいデータベースのスキーマに対する変更がレプリケートされます。

具体的には、このトピックの例では、「ハブ・アンド・スポーク・レプリケーションを構成する例」で構成したレプリケーション環境を拡張します。この構成には、次のような特徴があります。

- hrスキーマが、hub.example.com、spoke1.example.com、およびspoke2.example.comの各データベースでレプリケートされます。

- hub.example.comデータベースが、ハブ・アンド・スポーク環境におけるハブ・データベースであり、他のデータベースがスポーク・データベースです。

- スポーク・データベースでは、レプリケートされたスキーマへの変更が可能で、各データベースはそのローカル取得プロセスでこれらの変更を取得します。

この例では、環境にspoke3.example.comデータベースを追加します。

注意:
DBMS_STREAMS_ADMパッケージの構成プロシージャを使用してOracle Streamsレプリケーション環境を拡張する前に、「Streamsレプリケーションの設定ウィザードまたは単一の構成プロシージャの使用について」で説明されている条件を環境が満たしていることを確認してください。

手順は次のとおりです。

1. 次のタスクを完了して、新しいデータベースの環境を準備します。

1. ハブ・データベースが新しいスポーク・データベースと通信できるようにネットワーク接続を構成します。この例では、hub.example.comデータベースとspoke3.example.comデータベースが相互に通信できるようにネットワーク接続を構成します。
データベース間のネットワーク接続の構成については、『Oracle Database 2日でデータベース管理者』を参照してください。

2. 新しいスポーク・データベースでOracle Streams管理者を構成します。この例では、spoke3.example.comデータベースでOracle Streams管理者を構成します。手順については、「すべてのデータベースでのOracle Streams管理者の構成」を参照してください。この例では、Oracle Streams管理者がstrmadminであると想定しています。

3. ハブ・データベースから新しいスポーク・データベースおよび新しいスポーク・データベースからハブ・データベースへのデータベース・リンクを作成します。この例では、次のデータベース・リンクを作成します。

- hub.example.comデータベースからspoke3.example.comデータベース。データベース・リンクの名前とサービス名の両方がspoke3.example.comである必要があります。

- spoke3.example.comデータベースからhub.example.comデータベース。データベース・リンクの名前とサービス名の両方がhub.example.comである必要があります。

各データベース・リンクは、Oracle Streams管理者のスキーマに作成する必要があります。また、各データベース・リンクは、宛先データベースのOracle Streams管理者に接続する必要があります。手順については、「ネットワーク接続性とデータベース・リンクの構成」を参照してください。

4. 新しいスポーク・データベースで初期化パラメータを正しく設定します。この例では、spoke3.example.comデータベースで初期化パラメータを正しく設定します。手順については、「Oracle Streamsに関連する初期化パラメータの設定」を参照してください。

5. ARCHIVELOGモードで実行するように新しいスポーク・データベースを構成します。取得プロセスがソース・データベースで生成された変更を取得するには、ソース・データベースをARCHIVELOGモードで実行する必要があります。この例では、spoke3.example.comデータベースをARCHIVELOGモードで実行する必要があります。ARCHIVELOGモードで実行するためのデータベースの構成の詳細は、『Oracle Database管理者ガイド』を参照してください。

6. hub.example.comデータベースにhub_dirディレクトリ・オブジェクトが存在することを確認し、このオブジェクトから前の構成に関連するファイル(データ・ポンプ・エクスポート・ダンプ・ファイルおよびエクスポート・ログ・ファイルを含む)をすべて削除します。

2. SQL*Plusを開き、Oracle Streams管理者としてspoke3.example.comデータベースに接続します。
SQL*Plusの起動の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

3. MAINTAIN_SCHEMASプロシージャによって生成されるファイル(インスタンス化に使用されるデータ・ポンプ・エクスポート・ダンプ・ファイルを含む)を保持するディレクトリ・オブジェクトを作成します。ディレクトリ・オブジェクトのポイント先には、コンピュータ・システム上のアクセス可能な任意のディレクトリを指定できます。たとえば、次の文を実行すると、/usr/spoke3_log_filesディレクトリをポイントするspoke3_dirディレクトリ・オブジェクトが作成されます。

CREATE DIRECTORY spoke3_dir AS '/usr/spoke3_log_files';

4. ハブ・アンド・スポーク環境で、ハブ・データベースの取得プロセスを停止します。

取得プロセスを停止するには、DBMS_CAPTURE_ADMパッケージのSTOP_CAPTUREプロシージャを使用します。または、Oracle Enterprise Managerを使用して取得プロセスを停止する手順については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

この例では、hub.example.comデータベースの取得プロセスを停止します。取得プロセスの停止中、レプリケートされたデータベース・オブジェクトは変更に対してオープンなままにしておくことができます。これらの変更は、取得プロセスが再開されたときに取得されます。

5. SQL*Plusでは、ハブ・データベースでDBMS_STREAMS_ADMパッケージの適切な構成プロシージャを実行し、新しいスポーク・データベースを追加します。
この例では、次の手順を実行します。

1. SQL*Plusを開き、Oracle Streams管理者としてhub.example.comデータベースに接続します。

2. MAINTAIN_SCHEMASプロシージャを実行して、Oracle Streamsレプリケーション環境にspoke3.example.comデータベースを追加します。

BEGIN
DBMS_STREAMS_ADM.MAINTAIN_SCHEMAS(
schema_names                 => 'hr',
source_directory_object      => 'hub_dir',
destination_directory_object => 'spoke3_dir',
source_database              => 'hub.example.com',
destination_database         => 'spoke3.example.com',
capture_name                 => 'capture_hns',
capture_queue_table          => 'source_hns_qt',
capture_queue_name           => 'source_hns',
propagation_name             => 'propagation_spoke3',
apply_name                   => 'apply_spoke3',
apply_queue_table            => 'destination_spoke3_qt',
apply_queue_name             => 'destination_spoke3',
bi_directional               => TRUE);
END;
/

MAINTAIN_SCHEMASプロシージャは多くの構成タスクを実行するため、実行に時間がかかる場合があります。プロシージャの実行中に宛先データベースの指定したスキーマにあるデータベース・オブジェクトに対するデータ操作言語(DML)またはデータ定義言語(DDL)変更を許可しないでください。プロシージャが完了すると、環境に新しいデータベース・オブジェクトが追加され、手順4で停止されていた取得プロセスが再開されます。

capture_name、capture_queue_tableおよびcapture_queue_nameに指定されたパラメータ値は、レプリケーション環境を構成したDBMS_STREAMS_ADMパッケージの構成プロシージャで指定されている値と同じである必要があります。この例では、これらのパラメータ値は、「ハブ・アンド・スポーク・レプリケーションを構成する例」で指定されている値と一致します。

構成プロシージャの実行時、そのプロシージャの進捗に関する情報は、データ・ディクショナリ・ビューDBA_RECOVERABLE_SCRIPT、DBA_RECOVERABLE_SCRIPT_PARAMS、DBA_RECOVERABLE_SCRIPT_BLOCKSおよびDBA_RECOVERABLE_SCRIPT_ERRORSに記録されます。プロシージャでエラーが発生してプロシージャが停止した場合は、『Oracle Streamsレプリケーション管理者ガイド』でDBMS_STREAMS_ADMパッケージのRECOVER_OPERATIONプロシージャを使用したこれらのエラーからのリカバリ手順を参照してください。

6. spoke3.example.comデータベースのhrスキーマにあるすべての表に対して最新時刻競合解消を構成します。このスキーマには、countries、departments、employees、jobs、job_history、locationsおよびregionsの表が含まれています。手順については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

複数の手順でのコンポーネントの個別追加

この項では、Oracle Streamsコンポーネントを個別に追加することによるレプリケーション環境の拡張について説明します。Oracle Streamsコンポーネントには、キュー、ルール、ルール・セット、取得プロセス、同期取得、伝播および適用プロセスが含まれます。

この項の内容は次のとおりです。

- 既存の単一ソース環境へのレプリケート・オブジェクトの追加

- 単一ソース環境への新規宛先データベースの追加

- 既存の複数ソース環境へのレプリケート・オブジェクトの追加

- 既存の複数ソース環境への新規データベースの追加

注意:

- 可能な場合は、通常、単一のプロシージャまたはOracle Enterprise ManagerのStreamsレプリケーションの設定ウィザードを使用する方が、Oracle Streamsレプリケーション環境を簡単に拡張できます。単一のプロシージャを使用する手順については「単一のプロシージャを使用した複数のコンポーネントの追加」を、またウィザードを使用した手順についてはOracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

- ここで説明する手順は、DBMS_STREAMS_ADMパッケージを使用してOracle Streams環境を構成する場合を想定しています。他のパッケージを使用する場合は、タスクごとに追加の手順が必要になることがあります。

既存の単一ソース環境へのレプリケート・オブジェクトの追加

既存の単一ソース環境に既存のデータベース・オブジェクトを追加するには、適切な取得プロセス、同期取得、伝播および適用プロセスに必要なルールを追加します。稼働中のOracle Streams環境で取得ルールまたは伝播ルールを作成または変更する前に、新規のルールまたは変更後のルールによって生じる論理変更レコード(LCR)を受信する伝播や適用プロセスが、これらのLCRを処理するように構成されていることを確認してください。つまり、伝播または適用プロセスが存在し、それぞれがLCRを適切に処理するルール・セットに関連付けられている必要があります。これらの伝播と適用プロセスがこれらのLCRを処理するように適切に構成されていないと、LCRが失われる可能性があります。

たとえば、すでに変更が取得、伝播されて他の表に適用されているOracle Streamsレプリケーション環境に、表を追加する必要がある場合を考えます。この表に対する変更を取得する取得プロセスまたは同期取得は1つのみで、この表に変更を適用する適用プロセスも1つのみであるとします。この場合は、次のルール・セットに表の1つ以上のルールを追加する必要があります。

- 表に変更を適用する適用プロセスのポジティブ・ルール・セット

- 表に対する変更を伝播する各伝播のポジティブ・ルール・セット

- 表に対する変更を取得する取得プロセスまたは同期取得のポジティブ・ルール・セット

管理手順を正しい順序で実行しないと、LCRが失われる可能性があります。たとえば、取得プロセスを停止せず、先に取得プロセスのルール・セットにルールを追加した場合、変更を伝播するように指示するルールがなければ伝播は変更を伝播せず、変更が失われる可能性があります。

この例では、レプリケートされたデータベース・オブジェクトが宛先データベースで読取り専用であることを想定しています。レプリケートされたデータベース・オブジェクトが宛先データベースで読取り/書込み可能である場合、宛先データベースのレプリケートされたデータベース・オブジェクトに対して行われた変更をレプリケートするようにOracle Streamsが構成されないため、レプリケーション環境では同期状態が保たれません。

図4-1に、レプリケートされたデータベース・オブジェクトを単一ソースOracle Streams環境に追加するために実行する必要がある追加の構成手順を示します。

図4-1 単一ソース環境へのレプリケート・オブジェクトの追加例

LCRの消失を回避するには、構成手順を次の順序で完了します。

1. レプリケートされたデータベース・オブジェクトを追加する各ソース・データベースで、追加するレプリケートされたデータベース・オブジェクトのサプリメンタル・ロギングを指定します。手順については、「サプリメンタル・ロギングの指定」を参照してください。

2. 取得プロセス、1つの伝播または適用プロセスを停止します。

- 取得プロセスを停止するには、DBMS_CAPTURE_ADMパッケージのSTOP_CAPTUREプロシージャを使用します。または、Oracle Enterprise Managerを使用して取得プロセスを停止する手順については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

- DBMS_PROPAGATION_ADMパッケージのSTOP_PROPAGATIONプロシージャを使用して、伝播を停止します。また、Oracle Enterprise Managerを使用して伝播を無効にする手順については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

- DBMS_APPLY_ADMパッケージのSTOP_APPLYプロシージャを使用して、適用プロセスを停止します。また、Oracle Enterprise Managerを使用して適用プロセスを停止する手順については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

通常は、操作中にメッセージがキューに蓄積されないように、取得プロセスを停止することをお薦めします。

注意:
同期取得は停止できません。

関連項目:
PL/SQLプロシージャを使用してこれらのタスクを実行する方法の詳細は、『Oracle Streams概要および管理』を参照してください。

3. 適用プロセスのルール・セットに、関連ルールを追加します。適用プロセスのルール・セットにルールを追加するには、次のいずれかの手順を実行します。

- DBMS_STREAMS_ADM.ADD_TABLE_RULES

- DBMS_STREAMS_ADM.ADD_SUBSET_RULES

- DBMS_STREAMS_ADM.ADD_SCHEMA_RULES

- DBMS_STREAMS_ADM.ADD_GLOBAL_RULES

ADD_SUBSET_RULESプロシージャ以外のこれらのプロシージャでは、適用プロセスのポジティブ・ルール・セットまたはネガティブ・ルール・セットにルールを追加できます。ADD_SUBSET_RULESプロシージャでは、適用プロセスのポジティブ・ルール・セットにのみルールを追加できます。

4. 伝播のルール・セットに、関連ルールを追加します。伝播のルール・セットにルールを追加するには、次のいずれかのプロシージャを実行します。

- DBMS_STREAMS_ADM.ADD_TABLE_PROPAGATION_RULES

- DBMS_STREAMS_ADM.ADD_SUBSET_PROPAGATION_RULES

- DBMS_STREAMS_ADM.ADD_SCHEMA_PROPAGATION_RULES

- DBMS_STREAMS_ADM.ADD_GLOBAL_PROPAGATION_RULES

ADD_SUBSET_PROPAGATION_RULESプロシージャ以外のこれらのプロシージャでは、伝播のポジティブ・ルール・セットまたはネガティブ・ルール・セットにルールを追加できます。ADD_SUBSET_PROPAGATION_RULESプロシージャでは、伝播のポジティブ・ルール・セットにのみルールを追加できます。

5. 取得プロセスまたは同期取得で使用するルール・セットに関連ルールを追加します。既存の取得プロセスのルール・セットにルールを追加するには、次のいずれかのプロシージャを使用して既存の取得プロセスを指定できます。

- DBMS_STREAMS_ADM.ADD_TABLE_RULES

- DBMS_STREAMS_ADM.ADD_SUBSET_RULES

- DBMS_STREAMS_ADM.ADD_SCHEMA_RULES

- DBMS_STREAMS_ADM.ADD_GLOBAL_RULES

ADD_SUBSET_RULESプロシージャ以外のこれらのプロシージャでは、取得プロセスのポジティブ・ルール・セットまたはネガティブ・ルール・セットにルールを追加できます。ADD_SUBSET_RULESプロシージャでは、取得プロセスのポジティブ・ルール・セットにのみルールを追加できます。

既存の同期取得のルール・セットにルールを追加するには、次のいずれかのプロシージャを使用して既存の同期取得を指定できます。

- DBMS_STREAMS_ADM.ADD_TABLE_RULES

- DBMS_STREAMS_ADM.ADD_SUBSET_RULES

DBMS_STREAMS_ADMパッケージのプロシージャを使用して取得プロセスのルールを追加すると、その取得プロセスがソース・データベースへのデータベース・リンクを持つローカル取得プロセスまたはダウンストリーム取得プロセスである場合は、指定した表、指定したスキーマまたはデータベース全体に対して、それぞれDBMS_CAPTURE_ADMパッケージのPREPARE_TABLE_INSTANTIATION、PREPARE_SCHEMA_INSTANTIATIONまたはPREPARE_GLOBAL_INSTANTIATIONプロシージャが自動的に実行されます。

次のいずれかの条件に該当する場合は、適切なプロシージャを実行してインスタンス化の準備を手動で行う必要があります。

- DBMS_RULE_ADMを使用して、取得プロセスのルール・セット内でルールを作成または変更する場合。

- 取得プロセスは追加されるオブジェクトに対する変更をすでに取得しているため、取得プロセスのルール・セットにはこれらのオブジェクトのルールを追加しない場合。この場合、オブジェクトのルールを環境内の伝播と適用プロセスには追加できますが、取得プロセスには追加できません。

- ソース・データベースへのデータベース・リンクを持たないダウンストリーム取得プロセスを使用する場合。

インスタンス化の準備を手動で行う必要がある場合の手順については、「ソース・データベースでインスタンス化を行うためのデータベース・オブジェクトの準備」を参照してください。

DBMS_STREAMS_ADMパッケージのプロシージャを使用して同期取得のルールを追加すると、指定した表に対してDBMS_CAPTURE_ADMパッケージのPREPARE_SYNC_INSTANTIATIONファンクションが自動的に実行されます。

6. 各宛先データベースで、Oracle Streams環境に追加する各データベース・オブジェクトをインスタンス化するか、そのインスタンス化SCNを設定します。宛先データベースにデータベース・オブジェクトが存在しない場合は、エクスポート/インポート、トランスポータブル表領域またはRMANを使用してインスタンス化します。宛先データベースにデータベース・オブジェクトが存在する場合は、そのインスタンス化SCNを手動で設定します。

- エクスポート/インポートを使用してデータベース・オブジェクトをインスタンス化するには、まずソース・データベースでそれらのデータベース・オブジェクトをエクスポートします。次に、宛先データベースでそれらのオブジェクトをインポートします。第8章「インスタンス化とOracle Streamsレプリケーション」を参照してください。
ソース・データベースでのデータベース・オブジェクトのエクスポート中、それらのデータベース・オブジェクトに対する変更は許可しないでください。宛先データベースでのデータベース・オブジェクトのインポート中、それらのデータベース・オブジェクトに対する変更は許可しないでください。

FLASHBACK_SCNやFLASHBACK_TIMEなどのエクスポート・パラメータを使用して、より厳密な一貫性レベルを指定できます。

- 表、スキーマまたはデータベースのインスタンス化SCNを手動で設定するには、宛先データベースでDBMS_APPLY_ADMパッケージの適切なプロシージャを1つ以上実行します。

- SET_TABLE_INSTANTIATION_SCN

- SET_SCHEMA_INSTANTIATION_SCN

- SET_GLOBAL_INSTANTIATION_SCN

これらのプロシージャのいずれかを宛先データベースで実行する場合は、宛先データベースに追加された各オブジェクトに、インスタンス化SCNの時点でソース・データベースとの一貫性があることを確認する必要があります。

宛先データベースでSET_GLOBAL_INSTANTIATION_SCNを実行する場合、宛先データベースの各スキーマおよびそれらのスキーマが所有する表にもインスタンス化SCNが設定されるように、このプロシージャのrecursiveパラメータをTRUEに設定します。

宛先データベースでSET_SCHEMA_INSTANTIATION_SCNを実行する場合、スキーマ内の各表にもインスタンス化SCNが設定されるように、このプロシージャのrecursiveパラメータをTRUEに設定します。

SET_GLOBAL_INSTANTIATION_SCNプロシージャまたはSET_SCHEMA_INSTANTIATION_SCNプロシージャでrecursiveパラメータをTRUEに設定する場合は、宛先データベースからソース・データベースへのデータベース・リンクが必要です。このデータベース・リンクはソース・データベースのグローバル名と同じ名前であり、プロシージャを実行するユーザーからアクセス可能である必要があります。手順については、「DBMS_APPLY_ADMパッケージを使用したインスタンス化SCNの設定」を参照してください。

または、メタデータのエクスポート/インポートを実行して、既存のデータベース・オブジェクトについてインスタンス化SCNを設定できます。このオプションを選択した場合は、行がインポートされないことを確認してください。また、インポートする宛先データベースに追加された各オブジェクトに、エクスポートを実行したソース・データベースとのエクスポート時点での一貫性があることを確認してください。DML変更のみを共有する場合は、表レベルのエクスポート/インポートで十分です。DDL変更も共有する場合は、追加の考慮事項があります。メタデータのエクスポート/インポートを実行する方法の詳細は、「エクスポート/インポートを使用したインスタンス化SCNの設定」を参照してください。

7. 手順2で停止したOracle Streamsクライアントを起動します。

- DBMS_CAPTURE_ADMパッケージのSTART_CAPTUREプロシージャを使用して、取得プロセスを起動します。また、Oracle Enterprise Managerを使用して取得プロセスを起動する手順については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

- DBMS_PROPAGATION_ADMパッケージのSTART_PROPAGATIONプロシージャを使用して、伝播を起動します。また、Oracle Enterprise Managerを使用して伝播を有効にする手順については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

- DBMS_APPLY_ADMパッケージのSTART_APPLYプロシージャを使用して、適用プロセスを起動します。また、Oracle Enterprise Managerを使用して適用プロセスを起動する手順については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

関連項目:
PL/SQLプロシージャを使用してこれらのタスクを実行する方法の詳細は、『Oracle Streams概要および管理』を参照してください。

追加したルールによって生じる最初のLCRが適用プロセスに到達する前に、表またはスキーマがインスタンス化されるように、手順2で取得プロセスを停止するか、伝播ジョブの1つを無効化するか、適用プロセスを停止する必要があります。この操作を実行しないと、適用プロセスのルールを追加したかどうかに応じてLCRが失われたり、適用エラーが発生する可能性があります。

追加した表がこの手順の実行中にソース・データベースで変更されないことと、表のLCRがストリーム内にないことまたは取得を待機していないことが確実な場合は、手順6の前に手順7を実行して、Oracle Streamsプロセスや伝播ジョブの停止期間を短縮できます。

関連項目:
既存の単一ソース環境にオブジェクトを追加する場合の詳細な例は、『Oracle Streams拡張例』を参照してください。

単一ソース環境への新規宛先データベースの追加

既存の単一ソース環境に宛先データベースを追加するには、新規の宛先データベースで1つ以上の新規適用プロセスを作成し、必要な場合は、そのデータベースに変更を送信する1つ以上の伝播を構成します。また、新規宛先データベースに変更を送信するストリーム内の既存の伝播に、ルールの追加が必要になる場合があります。

「既存の単一ソース環境へのレプリケート・オブジェクトの追加」で説明した例と同様に、稼働中のOracle Streamsレプリケーション環境で伝播ルールを作成または変更する前に、新規のルールまたは変更後のルールによって生じる論理変更レコード(LCR)を受信する伝播や適用プロセスが、これらのLCRを処理するように構成されていることを確認してください。このように構成されていないと、LCRが失われる可能性があります。

この例では、レプリケートされたデータベース・オブジェクトが宛先データベースで読取り専用であることを想定しています。レプリケートされたデータベース・オブジェクトが宛先データベースで読取り/書込み可能である場合、宛先データベースのレプリケートされたデータベース・オブジェクトに対して行われた変更をレプリケートするようにOracle Streamsが構成されないため、レプリケーション環境では同期状態が保たれません。

図4-2に、宛先データベースを単一ソースOracle Streams環境に追加するために実行する必要がある追加の構成手順を示します。

図4-2 単一ソース環境への接続先の追加例

LCRの消失を回避するために、構成手順を次の順序で完了する必要があります。

1. 次に示す必要なタスクを完了し、Oracle Streams用の環境内で各データベースを準備します。「Oracle Streamsレプリケーションを構成する前に実行するタスク」を参照してください。
これらのタスクの一部は、一部のデータベースでは不要な場合があります。

2. 必要なANYDATAキューを作成します(宛先データベースに存在しない場合)。適用プロセスを作成するときに、その適用プロセスを特定のANYDATAキューに関連付けます。手順については、「ANYDATAキューの作成」を参照してください。

3. 新規の宛先データベースで、ソース・データベースからの変更を適用できるように1つ以上の適用プロセスを作成します。各適用プロセスで、変更の適用に適切なルール・セットが使用されることを確認します。新規データベースでは適用プロセスを起動しないでください。手順については、第7章「暗黙的適用の構成」を参照してください。

適用プロセスを停止したままにすると、ソース・データベースで行われた変更は新規データベースのインスタンス化が完了するまで適用されません。適用プロセスを起動すると、データが不正になったりエラーが発生する場合があります。

4. 必要な伝播を、ソース・データベースからの変更を新規の宛先データベースに送信するように構成します。各伝播で変更の伝播に適切なルール・セットが使用されることを確認します。「ANYDATAキュー間のOracle Streamsの伝播の作成」を参照してください。

5. ソース・データベースで、新規の宛先データベースの適用プロセスによって変更が適用される各データベース・オブジェクトについて、インスタンス化の準備を行います。
1つ以上の取得プロセスを使用している場合は、指定した表、指定したスキーマまたはデータベース全体に対して、それぞれDBMS_CAPTURE_ADMパッケージのPREPARE_TABLE_INSTANTIATION、PREPARE_SCHEMA_INSTANTIATIONまたはPREPARE_GLOBAL_INSTANTIATIONプロシージャを実行します。

1つ以上の同期取得を使用している場合は、指定した表に対してDBMS_CAPTURE_ADMパッケージのPREPARE_SYNC_INSTANTIATIONファンクションを実行します。

「ソース・データベースでインスタンス化を行うためのデータベース・オブジェクトの準備」を参照してください。

6. 新規の宛先データベースで、適用プロセスによって変更が適用される各データベース・オブジェクトをインスタンス化するか、そのインスタンス化SCNを設定します。新規の宛先データベースにデータベース・オブジェクトが存在しない場合は、エクスポート/インポート、トランスポータブル表領域またはRMANを使用してインスタンス化します。新規の宛先データベースにデータベース・オブジェクトが存在する場合は、そのインスタンス化SCNを設定します。

- エクスポート/インポートを使用してデータベース・オブジェクトをインスタンス化するには、まずソース・データベースでそれらのデータベース・オブジェクトをエクスポートします。次に、宛先データベースでそれらのオブジェクトをインポートします。第8章「インスタンス化とOracle Streamsレプリケーション」を参照してください。
ソース・データベースでのデータベース・オブジェクトのエクスポート中、それらのデータベース・オブジェクトに対する変更は許可しないでください。宛先データベースでのデータベース・オブジェクトのインポート中、それらのデータベース・オブジェクトに対する変更は許可しないでください。

FLASHBACK_SCNやFLASHBACK_TIMEなどのエクスポート・パラメータを使用して、より厳密な一貫性レベルを指定できます。

- 表、スキーマまたはデータベースのインスタンス化SCNを手動で設定するには、新規の宛先データベースでDBMS_APPLY_ADMパッケージの適切なプロシージャを1つ以上実行します。

- SET_TABLE_INSTANTIATION_SCN

- SET_SCHEMA_INSTANTIATION_SCN

- SET_GLOBAL_INSTANTIATION_SCN

これらのプロシージャのいずれかを実行する場合は、新規の宛先データベースのレプリケートされたデータベース・オブジェクトに、インスタンス化SCNの時点でソース・データベースとの一貫性があることを確認する必要があります。

宛先データベースでSET_GLOBAL_INSTANTIATION_SCNを実行する場合、宛先データベースの各スキーマおよびそれらのスキーマが所有する表にもインスタンス化SCNが設定されるように、このプロシージャのrecursiveパラメータをTRUEに設定します。

宛先データベースでSET_SCHEMA_INSTANTIATION_SCNを実行する場合、スキーマ内の各表にもインスタンス化SCNが設定されるように、このプロシージャのrecursiveパラメータをTRUEに設定します。

SET_GLOBAL_INSTANTIATION_SCNプロシージャまたはSET_SCHEMA_INSTANTIATION_SCNプロシージャでrecursiveパラメータをTRUEに設定する場合は、宛先データベースからソース・データベースへのデータベース・リンクが必要です。このデータベース・リンクはソース・データベースのグローバル名と同じ名前であり、プロシージャを実行するユーザーからアクセス可能である必要があります。手順については、「DBMS_APPLY_ADMパッケージを使用したインスタンス化SCNの設定」を参照してください。

または、メタデータのエクスポート/インポートを実行して、既存のデータベース・オブジェクトについてインスタンス化SCNを設定できます。このオプションを選択した場合は、行がインポートされないことを確認してください。また、インポートする宛先データベースのレプリケート・オブジェクトに、エクスポートを実行したソース・データベースとのエクスポート時点での一貫性があることを確認してください。DML変更のみを共有する場合は、表レベルのエクスポート/インポートで十分です。DDL変更も共有する場合は、追加の考慮事項があります。メタデータのエクスポート/インポートを実行する方法の詳細は、「エクスポート/インポートを使用したインスタンス化SCNの設定」を参照してください。

7. DBMS_APPLY_ADMパッケージのSTART_APPLYプロシージャを使用して、手順3で作成した適用プロセスを起動します。また、Oracle Enterprise Managerを使用して適用プロセスを起動する手順については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

関連項目:
既存の単一ソース環境にデータベースを追加する場合の詳細な例は、『Oracle Streams拡張例』を参照してください。

既存の複数ソース環境へのレプリケート・オブジェクトの追加

既存の複数ソース環境に既存のデータベース・オブジェクトを追加するには、適切な取得プロセス、同期取得、伝播および適用プロセスに必要なルールを追加します。

この例では、次の用語を使用しています。

- 実装済データベース: 複数ソース環境に追加するレプリケートされたデータベース・オブジェクトがすでに含まれているデータベース。環境にオブジェクトを追加するには、少なくとも1つは実装済データベースが必要です。

- エクスポート・データベース: 環境に追加するデータベース・オブジェクトのエクスポートを実行する実装済データベース。このエクスポートを使用して、追加したデータベース・オブジェクトがインポート・データベースでインスタンス化されます。すべてのデータベースが実装済データベースである環境では、エクスポート・データベースが存在しないことがあります。

- インポート・データベース: 複数ソース環境に追加する前には、レプリケートされたデータベース・オブジェクトが含まれていないデータベース。レプリケートされたデータベース・オブジェクトのインポートを実行して、そのデータベース・オブジェクトをインポート・データベースでインスタンス化します。すべてのデータベースが実装済データベースである環境では、インポート・データベースが存在しないことがあります。

稼働中のOracle Streamsレプリケーション環境で取得ルールまたは伝播ルールを作成または変更する前に、新規のルールまたは変更後のルールによって生じる論理変更レコード(LCR)を受信する伝播や適用プロセスが、これらのLCRを処理するように構成されていることを確認してください。つまり、伝播または適用プロセスが存在し、それぞれがLCRを適切に処理するルール・セットに関連付けられている必要があります。これらの伝播と適用プロセスがこれらのLCRを処理するように適切に構成されていないと、LCRが失われる可能性があります。

たとえば、すでに変更が取得、伝播されて他の表に適用されているOracle Streamsレプリケーション環境に、新規の表を追加する必要がある場合を考えます。環境内の複数の取得プロセスまたは同期取得がこの表に対する変更を取得し、複数の適用プロセスがこの表に変更を適用するとします。この場合は、次のルール・セットに表の1つ以上のルールを追加する必要があります。

- 表に変更を適用する各適用プロセスのポジティブ・ルール・セット

- 表に対する変更を伝播する各伝播のポジティブ・ルール・セット

- 表に対する変更を取得する各取得プロセスまたは同期取得のポジティブ・ルール・セット

管理手順を正しい順序で実行しないと、LCRが失われる可能性があります。たとえば、取得プロセスを停止せず、先に取得プロセスのルール・セットにルールを追加した場合、変更を伝播するように指示するルールがなければ伝播は変更を伝播せず、変更が失われる可能性があります。

図4-3に、レプリケートされたデータベース・オブジェクトを複数ソースOracle Streams環境に追加するために実行する必要がある追加の構成手順を示します。

図4-3 複数ソース環境へのレプリケート・オブジェクトの追加例

Oracle Streamsレプリケーション環境に複数のソース・データベースが存在する場合、変更の循環が発生する可能性があります。変更の循環は、変更が発生場所であるデータベースに再送されると発生します。通常は、変更の循環を回避する必要があります。レプリケーション環境を構成する前に、第10章「Oracle Streamsタグ」を参照して、変更の循環が回避されるようにレプリケーション環境を構成してください。

LCRの消失を回避するには、構成手順を次の順序で完了します。

1. 各実装済データベースで、環境に追加するオブジェクトに必要なサプリメンタル・ロギングを指定します。手順については、「サプリメンタル・ロギングの指定」を参照してください。

2. 追加したオブジェクトに対する変更を取得する取得プロセスをすべて停止するか、それを伝播する伝播をすべて停止するか、または追加したオブジェクトに変更を適用する適用プロセスをすべて停止します。

- 取得プロセスを停止するには、DBMS_CAPTURE_ADMパッケージのSTOP_CAPTUREプロシージャを使用します。または、Oracle Enterprise Managerを使用して取得プロセスを停止する手順については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

- DBMS_PROPAGATION_ADMパッケージのSTOP_PROPAGATIONプロシージャを使用して、伝播を停止します。また、Oracle Enterprise Managerを使用して伝播を無効にする手順については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

- DBMS_APPLY_ADMパッケージのSTOP_APPLYプロシージャを使用して、適用プロセスを停止します。また、Oracle Enterprise Managerを使用して適用プロセスを停止する手順については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

通常は、操作中にメッセージがキューに蓄積されないように、取得プロセスを停止することをお薦めします。

注意:
同期取得は停止できません。

関連項目:
PL/SQLプロシージャを使用してこれらのタスクを実行する方法の詳細は、『Oracle Streams概要および管理』を参照してください。

3. 追加したオブジェクトに変更を適用する適用プロセスについて、ルール・セットに関連ルールを追加します。適用プロセスのルール・セットにルールを追加するには、次のいずれかの手順を実行します。

- DBMS_STREAMS_ADM.ADD_TABLE_RULES

- DBMS_STREAMS_ADM.ADD_SUBSET_RULES

- DBMS_STREAMS_ADM.ADD_SCHEMA_RULES

- DBMS_STREAMS_ADM.ADD_GLOBAL_RULES

ADD_SUBSET_RULESプロシージャ以外のこれらのプロシージャでは、適用プロセスのポジティブ・ルール・セットまたはネガティブ・ルール・セットにルールを追加できます。ADD_SUBSET_RULESプロシージャでは、適用プロセスのポジティブ・ルール・セットにのみルールを追加できます。

4. 追加したオブジェクトに変更を伝播する伝播について、ルール・セットに関連ルールを追加します。伝播のルール・セットにルールを追加するには、次のいずれかのプロシージャを実行します。

- DBMS_STREAMS_ADM.ADD_TABLE_PROPAGATION_RULES

- DBMS_STREAMS_ADM.ADD_SUBSET_PROPAGATION_RULES

- DBMS_STREAMS_ADM.ADD_SCHEMA_PROPAGATION_RULES

- DBMS_STREAMS_ADM.ADD_GLOBAL_PROPAGATION_RULES

ADD_SUBSET_PROPAGATION_RULESプロシージャ以外のこれらのプロシージャでは、伝播のポジティブ・ルール・セットまたはネガティブ・ルール・セットにルールを追加できます。ADD_SUBSET_PROPAGATION_RULESプロシージャでは、伝播のポジティブ・ルール・セットにのみルールを追加できます。

5. 追加したオブジェクトに対する変更を取得する各取得プロセスまたは同期取得で使用されるルール・セットに、関連ルールを追加します。既存の取得プロセスのルール・セットにルールを追加するには、次のいずれかのプロシージャを使用して既存の取得プロセスを指定できます。

- DBMS_STREAMS_ADM.ADD_TABLE_RULES

- DBMS_STREAMS_ADM.ADD_SUBSET_RULES

- DBMS_STREAMS_ADM.ADD_SCHEMA_RULES

- DBMS_STREAMS_ADM.ADD_GLOBAL_RULES

ADD_SUBSET_RULESプロシージャ以外のこれらのプロシージャでは、取得プロセスのポジティブ・ルール・セットまたはネガティブ・ルール・セットにルールを追加できます。ADD_SUBSET_RULESプロシージャでは、取得プロセスのポジティブ・ルール・セットにのみルールを追加できます。

既存の同期取得のルール・セットにルールを追加するには、次のいずれかのプロシージャを使用して既存の同期取得を指定できます。

- DBMS_STREAMS_ADM.ADD_TABLE_RULES

- DBMS_STREAMS_ADM.ADD_SUBSET_RULES

DBMS_STREAMS_ADMパッケージのプロシージャを使用して取得プロセスのルールを追加すると、その取得プロセスがソース・データベースへのデータベース・リンクを持つローカル取得プロセスまたはダウンストリーム取得プロセスである場合は、指定した表、指定したスキーマまたはデータベース全体に対して、それぞれDBMS_CAPTURE_ADMパッケージのPREPARE_TABLE_INSTANTIATION、PREPARE_SCHEMA_INSTANTIATIONまたはPREPARE_GLOBAL_INSTANTIATIONプロシージャが自動的に実行されます。

次のいずれかの条件に該当する場合は、適切なプロシージャを実行してインスタンス化の準備を手動で行う必要があります。

- DBMS_RULE_ADMを使用して、取得プロセスのルール・セット内でルールを作成または変更する場合。

- 取得プロセスは追加されるオブジェクトに対する変更をすでに取得しているため、取得プロセスのルール・セットにはこれらのオブジェクトのルールを追加しない場合。この場合、オブジェクトのルールを環境内の伝播と適用プロセスには追加できますが、取得プロセスには追加できません。

- ソース・データベースへのデータベース・リンクを持たないダウンストリーム取得プロセスを使用する場合。

インスタンス化の準備を手動で行う必要がある場合の手順については、「ソース・データベースでインスタンス化を行うためのデータベース・オブジェクトの準備」を参照してください。

DBMS_STREAMS_ADMパッケージのプロシージャを使用して同期取得のルールを追加すると、指定した表に対してDBMS_CAPTURE_ADMパッケージのPREPARE_SYNC_INSTANTIATIONファンクションが自動的に実行されます。

前述の手順を完了してから、環境に応じて次の各項の手順を完了します。各項の一方の手順のみを完了すればよい場合と、両方の手順を完了する必要がある場合があります。

- 各実装済データベースには、「レプリケート・オブジェクト追加時の実装済データベースの構成」の手順を実行します。この手順は、環境に複数の実装済データベースが存在する場合にのみ必要です。

- 各インポート・データベースには、「既存の環境におけるインポート・データベースへのレプリケート・オブジェクトの追加」の手順を実行します。

レプリケート・オブジェクト追加時の実装済データベースの構成

環境に複数の実装済データベースが存在する場合は、「既存の複数ソース環境へのレプリケート・オブジェクトの追加」の手順を完了してから、各実装済データベースについて次の手順を実行します。

1. 実装済データベースごとに、環境内の他の各実装済データベースで追加した各オブジェクトにインスタンス化SCNを設定します。これらのインスタンス化SCNの設定は必須であり、特定の実装済データベースで行われた、そのデータベースの対応するSCNより後にコミットされる変更のみが、もう一方の実装済データベースに適用されます。
実装済データベースごとに、追加した各データベース・オブジェクトにこれらのインスタンス化SCNを次のいずれかの方法で設定できます。

- 追加したデータベース・オブジェクトのメタデータのみのエクスポートを実装済データベースで実行し、そのメタデータを他のそれぞれの実装済データベースでインポートします。このインポートによって、データベースに必須のインスタンス化SCNが、他のデータベースで設定されます。行がインポートされないことを確認してください。また、他の各実装済データベースのレプリケートされたデータベース・オブジェクトに、エクスポートを実行した実装済データベースとのエクスポート時点での一貫性があることを確認してください。
DML変更のみをレプリケートする場合は、表レベルのエクスポート/インポートで十分です。DDL変更もレプリケートする場合は、追加の考慮事項があります。メタデータのエクスポート/インポートを実行する方法の詳細は、「エクスポート/インポートを使用したインスタンス化SCNの設定」を参照してください。

- 他の各実装済データベースで、追加したオブジェクトについてインスタンス化SCNを手動で設定します。各実装済データベースに追加した各データベース・オブジェクトに、そのデータベースで設定したインスタンス化SCNとの一貫性があることを確認してください。手順については、「DBMS_APPLY_ADMパッケージを使用したインスタンス化SCNの設定」を参照してください。

既存の環境におけるインポート・データベースへのレプリケート・オブジェクトの追加

「既存の複数ソース環境へのレプリケート・オブジェクトの追加」の手順を完了した後に、インポート・データベースについて次の手順を実行します。

1. エクスポート・データベースとして使用する実装済データベースを選択します。まだインスタンス化は実行しないでください。

2. インポート・データベースごとに、インポート・データベースの宛先データベースとなる環境内の他のすべてのデータベースで、追加したデータベース・オブジェクトにインスタンス化SCNを設定します。この場合、インポート・データベースがこれらの宛先データベースのソース・データベースになります。インスタンス化SCNを設定するデータベースは、実装済データベースの場合もあれば、他のインポート・データベースの場合もあります。

1. インスタンス化中、またはその後のレプリケートされたDDLの変更によって、インポート・データベースで1つ以上のスキーマが作成される場合は、環境内の他のすべてのデータベースで、このインポート・データベースについてDBMS_APPLY_ADMパッケージのSET_GLOBAL_INSTANTIATION_SCNプロシージャを実行します。

2. インポート・データベースにスキーマが存在し、インスタンス化中、またはその後のレプリケートDDLの変更によって、そのスキーマに1つ以上の表が作成される場合は、環境内の他の各データベースで、このインポート・データベースのスキーマについてDBMS_APPLY_ADMパッケージのSET_SCHEMA_INSTANTIATION_SCNプロシージャを実行します。この操作は、この種のスキーマごとに行います。

手順については、「DBMS_APPLY_ADMパッケージを使用したインスタンス化SCNの設定」を参照してください。

これらのプロシージャは、インポート・データベースで表がインスタンス化される前に実行し、これらのインポート・データベースについてはローカルの取得プロセスまたは同期取得がすでに構成されているため、インスタンス化中に作成される表ごとにSET_TABLE_INSTANTIATION_SCNプロシージャを実行する必要はありません。インポート・データベースの宛先データベースとなる環境内の他のすべてのデータベースで、その表ごとにインスタンス化SCNが自動的に設定されます。

3. 手順1で選択したエクスポート・データベースで、レプリケートされたデータベース・オブジェクトのエクスポートを実行します。次に、各インポート・データベースでレプリケート・オブジェクトのインポートを実行します。エクスポート/インポートの使用方法の詳細は、第8章「インスタンス化とOracle Streamsレプリケーション」および『Oracle Databaseユーティリティ』を参照してください。

ソース・データベースでのデータベース・オブジェクトのエクスポート中、それらのデータベース・オブジェクトに対する変更は許可しないでください。宛先データベースでのデータベース・オブジェクトのインポート中、それらのデータベース・オブジェクトに対する変更は許可しないでください。

FLASHBACK_SCNやFLASHBACK_TIMEなどのエクスポート・パラメータを使用して、より厳密な一貫性レベルを指定できます。

4. エクスポート・データベース以外の実装済データベースごとに、実装済ソース・データベースの宛先データベースとなる各インポート・データベースで、追加したデータベース・オブジェクトにインスタンス化SCNを設定します。これらのインスタンス化SCNの設定は必須であり、実装済データベースで行われた、そのデータベースの対応するSCNより後にコミットされる変更のみがインポート・データベースに適用されます。
実装済データベースごとに、追加したオブジェクトにこれらのインスタンス化SCNを次のいずれかの方法で設定できます。

- 追加したデータベース・オブジェクトのメタデータのみのエクスポートを実装済データベースで実行し、そのメタデータを各インポート・データベースでインポートします。各インポートによって、実装済データベースに必須のインスタンス化SCNが、インポート・データベースで設定されます。この場合は、インポート・データベースで追加した各データベース・オブジェクトに、エクスポート時点で実装済データベースとの一貫性があることを確認してください。
DML変更のみをレプリケートする場合は、表レベルのエクスポート/インポートで十分です。DDL変更もレプリケートする場合は、追加の考慮事項があります。メタデータのエクスポート/インポートを実行する方法の詳細は、「エクスポート/インポートを使用したインスタンス化SCNの設定」を参照してください。

- 各インポート・データベースで、追加したオブジェクトについてインスタンス化SCNを手動で設定します。各インポート・データベースで追加した各オブジェクトに、対応するインスタンス化SCNの時点で実装済データベースとの一貫性があることを確認してください。手順については、「DBMS_APPLY_ADMパッケージを使用したインスタンス化SCNの設定」を参照してください。

複数ソース環境構成へのオブジェクトの追加の完了

構成を完了する前に、次のタスクを完了する必要があります。

- 「既存の複数ソース環境へのレプリケート・オブジェクトの追加」

- 環境に複数の実装済データベースが存在する場合は、「レプリケート・オブジェクト追加時の実装済データベースの構成」

- 「既存の環境におけるインポート・データベースへのレプリケート・オブジェクトの追加」(環境にインポート・データベースが存在する場合)

前述の構成手順をすべて完了してから、次の手順を行います。

1. 競合が発生する可能性がある場合は、各データベースで、追加したデータベース・オブジェクトに対する競合解消を構成します。手順については、第9章「Oracle Streamsの競合解消」を参照してください。

2. 「既存の複数ソース環境へのレプリケート・オブジェクトの追加」の手順2で停止した各Oracle Streamsクライアントを起動します。

- DBMS_CAPTURE_ADMパッケージのSTART_CAPTUREプロシージャを使用して、取得プロセスを起動します。また、Oracle Enterprise Managerを使用して取得プロセスを起動する手順については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

- DBMS_PROPAGATION_ADMパッケージのSTART_PROPAGATIONプロシージャを使用して、伝播を起動します。また、Oracle Enterprise Managerを使用して伝播を有効にする手順については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

- DBMS_APPLY_ADMパッケージのSTART_APPLYプロシージャを使用して、適用プロセスを起動します。また、Oracle Enterprise Managerを使用して適用プロセスを起動する手順については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

関連項目:
PL/SQLプロシージャを使用してこれらのタスクを実行する方法の詳細は、『Oracle Streams概要および管理』を参照してください。

既存の複数ソース環境への新規データベースの追加

図4-4に、ソース・データベースと宛先データベースを複数ソースOracle Streams環境に追加するために実行する必要がある追加の構成手順を示します。

図4-4 複数ソース環境へのデータベースの追加例

Oracle Streamsレプリケーション環境に複数のソース・データベースが存在する場合、変更の循環が発生する可能性があります。変更の循環は、変更が発生場所であるデータベースに再送されると発生します。通常は、変更の循環を回避する必要があります。レプリケーション環境を構成する前に、第10章「Oracle Streamsタグ」を参照して、変更の循環が回避されるようにレプリケーション環境を構成してください。

次の手順を実行して、既存の複数ソースOracle Streamsレプリケーション環境に新規ソース・データベースと宛先データベースを追加します。

注意:
Oracle Streamsレプリケーション環境に追加するデータベースでは、そのデータベースでのインスタンス化が完了するまでは、レプリケートされるデータベース・オブジェクトに対して変更が行われないことを確認してください。

1. 次に示す必要なタスクを完了し、Oracle Streams用の環境内で各データベースを準備します。「Oracle Streamsレプリケーションを構成する前に実行するタスク」を参照してください。
これらのタスクの一部は、一部のデータベースでは不要な場合があります。

2. 必要なANYDATAキューを作成します(存在しない場合)。取得プロセス、同期取得または適用プロセスを作成するときに、そのプロセスを特定のANYDATAキューに関連付けます。伝播を作成するときには、その伝播を特定のソース・キューおよび宛先キューに関連付けます。手順については、「ANYDATAキューの作成」を参照してください。

3. 新規データベースで、ソース・データベースからの変更を適用できるように1つ以上の適用プロセスを作成します。各適用プロセスで、変更の適用に適切なルール・セットが使用されることを確認します。新規データベースでは適用プロセスを起動しないでください。手順については、第7章「暗黙的適用の構成」を参照してください。

適用プロセスを停止したままにすると、ソース・データベースで行われた変更は新規データベースのインスタンス化が完了するまで適用されません。適用プロセスを起動すると、データが不正になったりエラーが発生する場合があります。

4. 新規データベースがソース・データベースとなる場合は、新規データベースで行われる変更の宛先データベースとなる全データベースで、新規データベースからの変更を適用する1つ以上の適用プロセスを作成します。各適用プロセスで、変更の適用に適切なルール・セットが使用されることを確認します。これらの新規適用プロセスは起動しないでください。手順については、第7章「暗黙的適用の構成」を参照してください。

5. 新規データベースのソース・データベースとなるデータベースで、変更を新規データベースに送信するように伝播を構成します。各伝播で変更の伝播に適切なルール・セットが使用されることを確認します。「ANYDATAキュー間のOracle Streamsの伝播の作成」を参照してください。

6. 新規データベースがソース・データベースとなる場合は、そこでの変更を各宛先データベースに送信するように、新規データベースで伝播を構成します。各伝播で変更の伝播に適切なルール・セットが使用されることを確認します。「ANYDATAキュー間のOracle Streamsの伝播の作成」を参照してください。

7. 新規データベースがソース・データベースとなり、そこに既存のレプリケートされたデータベース・オブジェクトがある場合は、そのレプリケートされたデータベース・オブジェクトに必要なサプリメンタル・ロギングを指定します。手順については、「サプリメンタル・ロギングの指定」を参照してください。

8. 新規データベースの各ソース・データベースで、新規データベースの適用プロセスによって変更が適用される各データベース・オブジェクトについて、インスタンス化の準備を行います。
1つ以上の取得プロセスを使用している場合は、指定した表、指定したスキーマまたはデータベース全体に対して、それぞれDBMS_CAPTURE_ADMパッケージのPREPARE_TABLE_INSTANTIATION、PREPARE_SCHEMA_INSTANTIATIONまたはPREPARE_GLOBAL_INSTANTIATIONプロシージャを実行します。

1つ以上の同期取得を使用している場合は、指定した表に対してDBMS_CAPTURE_ADMパッケージのPREPARE_TABLE_INSTANTIATIONプロシージャを実行します。

手順については、「ソース・データベースでインスタンス化を行うためのデータベース・オブジェクトの準備」を参照してください。

9. 新規データベースがソース・データベースとなる場合は、関連する変更を取得するために1つ以上の取得プロセスまたは同期取得を作成します。手順については、第5章「暗黙的取得の構成」を参照してください。取得プロセスを使用する場合、各ソース・データベースには1つのみの取得プロセスを使用することをお薦めします。

DBMS_STREAMS_ADMパッケージのプロシージャを使用して取得プロセスのルールを追加すると、その取得プロセスがソース・データベースへのデータベース・リンクを持つローカル取得プロセスまたはダウンストリーム取得プロセスである場合は、指定した表、指定したスキーマまたはデータベース全体に対して、それぞれDBMS_CAPTURE_ADMパッケージのPREPARE_TABLE_INSTANTIATION、PREPARE_SCHEMA_INSTANTIATIONまたはPREPARE_GLOBAL_INSTANTIATIONプロシージャが自動的に実行されます。

次のいずれかの条件に該当する場合は、適切なプロシージャを実行してインスタンス化の準備を手動で行う必要があります。

- DBMS_RULE_ADMパッケージを使用してルールを追加または変更する場合。

- 既存の取得プロセスを使用し、レプリケートされたデータベース・オブジェクトの取得プロセスのルールは追加しない場合。

- ソース・データベースへのデータベース・リンクを持たないダウンストリーム取得プロセスを使用する場合。

インスタンス化の準備を手動で行う必要がある場合の手順については、「ソース・データベースでインスタンス化を行うためのデータベース・オブジェクトの準備」を参照してください。

DBMS_STREAMS_ADMパッケージのプロシージャを使用して同期取得のルールを追加すると、指定した表に対してDBMS_CAPTURE_ADMパッケージのPREPARE_SYNC_INSTANTIATIONファンクションが自動的に実行されます。

10. 新規データベースがソース・データベースとなる場合は、DBMS_CAPTURE_ADMパッケージのSTART_CAPTUREプロシージャを使用して、手順9で作成した取得プロセスを起動します。また、Oracle Enterprise Managerを使用して取得プロセスを起動する手順については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

前述の手順を完了してから、次の該当する項の手順を完了します。

- 新規データベースにレプリケートするオブジェクトが新規データベースに存在する場合は、「レプリケート・オブジェクトが新規データベースに存在する場合のデータベースの構成」の手順を実行します。

- 新規データベースにレプリケートするオブジェクトが新規データベースに存在しない場合は、「新規データベースへのレプリケート・オブジェクトの追加」の手順を実行します。

レプリケート・オブジェクトが新規データベースに存在する場合のデータベースの構成

新規データベースにレプリケートするオブジェクトがすでに新規データベースに存在する場合は、「既存の複数ソース環境への新規データベースの追加」の手順を完了してから次の手順を実行します。

1. 新規データベースのソース・データベースごとに、新規データベースでインスタンス化SCNを設定します。これらのインスタンス化SCNの設定は必須であり、ソース・データベースで行われた、そのデータベースの対応するSCNより後にコミットされる変更のみが新規データベースに適用されます。
新規データベースのソース・データベースごとに、これらのインスタンス化SCNを次のいずれかの方法で設定できます。

- レプリケートされたデータベース・オブジェクトのメタデータのみのエクスポートをソース・データベースで実行し、そのメタデータを新規データベースでインポートします。このインポートによって、ソース・データベースに必須のインスタンス化SCNが、新規データベースで設定されます。行がインポートされないことを確認してください。この場合は、新規データベースのレプリケートされたデータベース・オブジェクトに、エクスポート時点でソース・データベースとの一貫性があることを確認してください。
DML変更のみをレプリケートする場合は、表レベルのエクスポート/インポートで十分です。DDL変更もレプリケートする場合は、追加の考慮事項があります。メタデータのエクスポート/インポートを実行する方法の詳細は、「エクスポート/インポートを使用したインスタンス化SCNの設定」を参照してください。

- 新規データベースで、レプリケートされたデータベース・オブジェクトについてインスタンス化SCNを手動で設定します。新規データベースのレプリケートされたデータベース・オブジェクトに、対応するインスタンス化SCNの時点でソース・データベースとの一貫性があることを確認してください。手順については、「DBMS_APPLY_ADMパッケージを使用したインスタンス化SCNの設定」を参照してください。

2. 新規データベースについて、新規データベースの各宛先データベースでインスタンス化SCNを設定します。これらのインスタンス化SCNの設定は必須であり、新規のソース・データベースで行われた、それに対応するSCNより後にコミットされる変更のみが宛先データベースに適用されます。新規データベースがソース・データベースでない場合は、この手順を実行しないでください。

新規データベースのインスタンス化SCNを設定するには、次の方法があります。

- 新規データベースでメタデータのみのエクスポートを実行し、そのメタデータを各宛先データベースでインポートします。行がインポートされないことを確認してください。このインポートによって、新規データベースに必須のインスタンス化SCNが、各宛先データベースで設定されます。この場合は、各宛先データベースのレプリケートされたデータベース・オブジェクトに、エクスポート時点で新規データベースとの一貫性があることを確認してください。
DML変更のみをレプリケートする場合は、表レベルのエクスポート/インポートで十分です。DDL変更もレプリケートする場合は、追加の考慮事項があります。メタデータのエクスポート/インポートを実行する方法の詳細は、「エクスポート/インポートを使用したインスタンス化SCNの設定」を参照してください。

- 宛先データベースで、レプリケートされたデータベース・オブジェクトについてインスタンス化SCNを手動で設定します。各宛先データベースのレプリケートされたデータベース・オブジェクトに、対応するインスタンス化SCNの時点で新規データベースとの一貫性があることを確認してください。手順については、「DBMS_APPLY_ADMパッケージを使用したインスタンス化SCNの設定」を参照してください。

3. 競合が発生する可能性がある場合は、新規データベースで競合解消を構成します。手順については、第9章「Oracle Streamsの競合解消」を参照してください。

4. DBMS_APPLY_ADMパッケージのSTART_APPLYプロシージャを使用して、前述の項の手順3で新規データベースに作成した適用プロセスを起動します。また、Oracle Enterprise Managerを使用して適用プロセスを起動する手順については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

5. 前述の項の手順4で他の各宛先データベースに作成した適用プロセスを起動します。新規データベースがソース・データベースでない場合は、この手順を実行しないでください。

新規データベースへのレプリケート・オブジェクトの追加

新規データベースと共有するデータベース・オブジェクトが新規データベースに存在しない場合は、「既存の複数ソース環境への新規データベースの追加」の手順を完了してから次の手順を実行します。

1. 新規データベースが他のデータベースのソース・データベースである場合は、新規ソース・データベースの各宛先データベースで、新規データベースのインスタンス化SCNを設定します。

1. インスタンス化中に、またはその後にレプリケートDDLの変更によって、新規データベースで1つ以上のスキーマが作成される場合は、新規データベースの各宛先データベースで、新規データベースについてDBMS_APPLY_ADMパッケージのSET_GLOBAL_INSTANTIATION_SCNプロシージャを実行します。

2. 新規データベースにスキーマが存在し、インスタンス化中、またはその後のレプリケートDDLの変更によって、そのスキーマに1つ以上の表が作成される場合は、新規データベースの各宛先データベースで、そのスキーマについてDBMS_APPLY_ADMパッケージのSET_SCHEMA_INSTANTIATION_SCNプロシージャを実行します。この操作は、この種のスキーマごとに行います。

手順については、「DBMS_APPLY_ADMパッケージを使用したインスタンス化SCNの設定」を参照してください。

これらのプロシージャは、新規データベースで表がインスタンス化される前に実行し、新規データベースではローカルの取得プロセスまたは同期取得がすでに構成されているため、インスタンス化中に作成される表ごとにSET_TABLE_INSTANTIATION_SCNプロシージャを実行する必要はありません。新規データベースの宛先データベースとなる環境内の他のすべてのデータベースで、その表ごとにインスタンス化SCNが自動的に設定されます。

新規データベースがソース・データベースでない場合は、この手順を実行せずに次の手順に進んでください。

2. 新規データベースでエクスポート/インポートを使用して、レプリケートされたデータベース・オブジェクトをインスタンス化する場合のソース・データベースを1つ選択します。まず、レプリケートされたデータベース・オブジェクトのエクスポートを実行します。次に、レプリケートされたデータベース・オブジェクトのインポートを新規データベースで実行します。エクスポート/インポートの使用方法の詳細は、第8章「インスタンス化とOracle Streamsレプリケーション」および『Oracle Databaseユーティリティ』を参照してください。

ソース・データベースでのデータベース・オブジェクトのエクスポート中、それらのデータベース・オブジェクトに対する変更は許可しないでください。宛先データベースでのデータベース・オブジェクトのインポート中、それらのデータベース・オブジェクトに対する変更は許可しないでください。

FLASHBACK_SCNやFLASHBACK_TIMEなどのエクスポート・パラメータを使用して、より厳密な一貫性レベルを指定できます。

3. 手順2でインスタンス化のためのエクスポートを実行したソース・データベースを除き、新規データベースのソース・データベースごとに、新規データベースでインスタンス化SCNを設定します。これらのインスタンス化SCNの設定は必須であり、ソース・データベースで行われた、そのデータベースの対応するSCNより後にコミットされる変更のみが新規データベースに適用されます。
ソース・データベースごとに、これらのインスタンス化SCNを次のいずれかの方法で設定できます。

- ソース・データベースでメタデータのみのエクスポートを実行し、そのメタデータを新規データベースでインポートします。このインポートによって、ソース・データベースに必須のインスタンス化SCNが、新規データベースで設定されます。この場合は、新規データベースのレプリケートされたデータベース・オブジェクトに、エクスポート時点でソース・データベースとの一貫性があることを確認してください。
DML変更のみをレプリケートする場合は、表レベルのエクスポート/インポートで十分です。DDL変更もレプリケートする場合は、追加の考慮事項があります。メタデータのエクスポート/インポートを実行する方法の詳細は、「エクスポート/インポートを使用したインスタンス化SCNの設定」を参照してください。

- 新規データベースで、レプリケートされたデータベース・オブジェクトについてインスタンス化SCNを手動で設定します。新規データベースのレプリケートされたデータベース・オブジェクトに、対応するインスタンス化SCNの時点でソース・データベースとの一貫性があることを確認してください。手順については、「DBMS_APPLY_ADMパッケージを使用したインスタンス化SCNの設定」を参照してください。

4. 競合が発生する可能性がある場合は、新規データベースで競合解消を構成します。手順については、第9章「Oracle Streamsの競合解消」を参照してください。

5. DBMS_APPLY_ADMパッケージのSTART_APPLYプロシージャを使用して、手順3で新規データベースに作成した適用プロセスを起動します。また、Oracle Enterprise Managerを使用して適用プロセスを起動する手順については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

6. 前述の項の手順4で他の各宛先データベースに作成した適用プロセスを起動します。新規データベースがソース・データベースでない場合は、この手順を実行しないでください。

5 暗黙的取得の構成

暗黙的取得とは、取得プロセスまたは同期取得によってデータベースの変更が自動的に取得およびエンキューされることを意味します。取得プロセスではREDOログ内の変更が取得されるのに対し、同期取得では内部メカニズムを使用してデータ操作言語(DML)変更が取得されます。取得プロセスと同期取得の両方で、取得された変更が論理変更レコード(LCR)に再フォーマットされ、LCRがANYDATAキューにエンキューされます。

ここでは、暗黙的取得の構成について説明します。

- 取得プロセスの構成

- 同期取得の構成

この章で説明する各タスクは、特に指定がないかぎり、適切な権限を付与されたOracle Streams管理者が実行する必要があります。

関連項目:

- 暗黙的取得の詳細は、『Oracle Streams概要および管理』を参照してください。

- 「すべてのデータベースでのOracle Streams管理者の構成」

取得プロセスの構成

変更をソース・データベースでローカルに取得するか、またはダウンストリーム・データベースでリモートに取得する取得プロセスを作成できます。ダウンストリーム取得プロセスはダウンストリーム・データベースで実行され、ソース・データベースからのREDOデータがダウンストリーム・データベースにコピーされます。ダウンストリーム取得プロセスでは、ダウンストリーム・データベースにコピーされたREDOデータの変更が取得されます。

次のどのプロシージャでも、ローカルの取得プロセスを作成できます。

- DBMS_STREAMS_ADM.ADD_TABLE_RULES

- DBMS_STREAMS_ADM.ADD_SUBSET_RULES

- DBMS_STREAMS_ADM.ADD_SCHEMA_RULES

- DBMS_STREAMS_ADM.ADD_GLOBAL_RULES

- DBMS_CAPTURE_ADM.CREATE_CAPTURE

DBMS_STREAMS_ADMパッケージの各プロシージャは、取得プロセスが存在しない場合は名前を指定して取得プロセスを作成し、取得プロセスにポジティブ・ルール・セットまたはネガティブ・ルール・セットがない場合はそれらのルール・セットを作成します。また、ルール・セットに表ルール、スキーマ・ルールまたはグローバル・ルールを追加することもできます。

CREATE_CAPTUREプロシージャは、取得プロセスは作成しますが、その取得プロセスのルール・セットやルールは作成しません。ただし、CREATE_CAPTUREプロシージャを使用すると、取得プロセスにポジティブ・ルール・セットまたはネガティブ・ルール・セットとして関連付ける既存のルール・セット、取得プロセスの先頭SCNおよび開始SCNを指定できます。また、ダウンストリーム取得を実行する取得プロセスを作成するには、CREATE_CAPTUREプロシージャを使用する必要があります。

ここでは、取得プロセスの構成について説明します。

- 取得プロセスの構成の準備

- ローカルの取得プロセスの構成

- ダウンストリーム取得プロセスの構成

- 取得プロセスの構成後

注意:
取得プロセスを起動または再起動する場合、開始SCNよりFIRST_CHANGE#値の小さいREDOログ・ファイルをスキャンする必要がある場合があります。取得プロセスによるスキャン前に必要なREDOログ・ファイルを削除すると、取得プロセスが異常終了します。取得プロセスの先頭SCN、開始SCNおよび必須チェックポイントSCNを判断するには、DBA_CAPTUREデータ・ディクショナリ・ビューを問い合せます。取得プロセスには、必須チェックポイントSCNを含むREDOログ・ファイルと、後続のすべてのREDOログ・ファイルが必要です。取得プロセスの先頭SCNと開始SCNの詳細は、『Oracle Streams概要および管理』を参照してください。

注意:

- DBMS_STREAMS_ADMパッケージのプロシージャまたはOracle Enterprise Managerを使用して、Oracle Streams環境全体(取得プロセスを含む)を構成できます。第2章「Oracle Streamsレプリケーションの簡単な構成」を参照してください。

- 取得プロセスを作成した後は、その取得プロセスのソース・データベースのDBIDまたはグローバル名を変更しないようにしてください。ソース・データベースのDBIDまたはグローバル名を変更した場合は、取得プロセスを削除して再作成する必要があります。「ソース・データベースのDBIDまたはグローバル名の変更」を参照してください。

- ダウンストリーム取得を構成するには、ソース・データベースがOracle Database 10g リリース1以上のデータベースである必要があります。

取得プロセスの構成の準備

取得プロセスを構成する前に、次のタスクを完了する必要があります。

- 「Oracle Streamsレプリケーションを構成する前に実行するタスク」で説明されている次のタスクを完了します。

- 「すべてのデータベースでのOracle Streams管理者の構成」

- 「ネットワーク接続性とデータベース・リンクの構成」

- 「各ソース・データベースがARCHIVELOGモードであることの確認」

- 「Oracle Streamsに関連する初期化パラメータの設定」

- 「Oracle Streamsプールの構成」

- 「サプリメンタル・ロギングの指定」

- REDO転送サービスを使用してアーカイブREDOログ・ファイルをダウンストリーム・データベースに自動的に転送するリアルタイム・ダウンストリーム取得プロセスまたはアーカイブ・ログ・ダウンストリーム取得プロセスを作成する場合は、「ダウンストリーム取得データベースへのログ・ファイルの転送の構成」の手順を実行します。

- リアルタイム・ダウンストリーム取得プロセスを作成する場合は、「リアルタイム・ダウンストリーム取得のためのスタンバイREDOログの追加」の手順を実行します。

- 取得プロセスに関連付けるANYDATAキューを作成します(存在しない場合)。手順については、「ANYDATAキューの作成」を参照してください。この章の例では、取得プロセスで使用されるキューはstrmadmin.streams_queueであると想定しています。取得プロセスを実行するデータベースと同じデータベースでキューを作成します。

ローカルの取得プロセスの構成

ここでは、DBMS_STREAMS_ADMパッケージとDBMS_CAPTURE_ADMパッケージを使用してローカル取得プロセスを作成する方法について説明します。

この項の例は、次のとおりです。

- DBMS_STREAMS_ADMを使用したローカルの取得プロセスの構成

- DBMS_CAPTURE_ADMを使用したローカルの取得プロセスの構成

- NULL以外の開始SCNを使用したローカルの取得プロセスの構成

DBMS_STREAMS_ADMを使用したローカルの取得プロセスの構成

DBMS_STREAMS_ADMパッケージを使用してローカルの取得プロセスを構成するには、次の手順を実行します。

1. 「取得プロセスの構成の準備」で説明されているタスクを完了します。

2. SQL*Plusで、Oracle Streams管理者としてソース・データベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

3. DBMS_STREAMS_ADMパッケージのADD_TABLE_RULESプロシージャを実行して、ローカルの取得プロセスを作成します。

BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
table_name         => 'hr.employees',
streams_type       => 'capture',
streams_name       => 'strm01_capture',
queue_name         => 'strmadmin.streams_queue',
include_dml        => TRUE,
include_ddl        => TRUE,
include_tagged_lcr => FALSE,
source_database    => NULL,
inclusion_rule     => TRUE);
END;
/

このプロシージャを実行すると、次のアクションが実行されます。

- 取得プロセスstrm01_captureが作成されます。この取得プロセスが作成されるのは、それが存在しない場合のみです。新規の取得プロセスが作成される場合、このプロシージャでは開始SCNも作成時点に設定されます。

- 取得プロセスが、既存のキューstrmadmin.streams_queueに関連付けられます。

- 取得プロセスにポジティブ・ルール・セットがない場合はポジティブ・ルール・セットが作成され、取得プロセスに関連付けられます。inclusion_ruleパラメータがTRUEに設定されているため、ルール・セットはポジティブ・ルール・セットとなります。このルール・セットでは、SYS.STREAMS$_EVALUATION_CONTEXT評価コンテキストが使用されます。ルール・セット名は、システムによって生成されます。

- 2つのルールが作成されます。一方のルールはhr.employees表に対するデータ操作言語(DML)変更についてTRUEと評価され、もう一方のルールはhr.employees表に対するデータ定義言語(DDL)変更についてTRUEと評価されます。ルール名は、システムによって生成されます。

- この2つのルールが、取得プロセスに関連付けられたポジティブ・ルール・セットに追加されます。inclusion_ruleパラメータがTRUEに設定されているため、ルールはポジティブ・ルール・セットに追加されます。

- include_tagged_lcrパラメータがFALSEに設定されているため、変更にNULLタグが付いている場合にのみ、取得プロセスでREDOログ内の変更を取得するように指定されます。この動作は、取得プロセスのシステム作成ルールを介して実行されます。

- source_databaseパラメータがNULLに設定されているため、ソース・データベースに対するローカルの変更を取得する取得プロセスが作成されます。ローカルの取得プロセスの場合、このパラメータにローカル・データベースのグローバル名を指定する場合もあります。

- hr.employees表がインスタンス化のために準備されます。

- hr.employees表の主キー列、一意キー列、ビットマップ索引列および外部キー列に対してサプリメンタル・ロギングが有効化されます。

4. 必要に応じて、「取得プロセスの構成後」で説明されている手順を完了します。

関連項目:

- ルールの詳細は、『Oracle Streams概要および管理』を参照してください。

- 第10章「Oracle Streamsタグ」

DBMS_CAPTURE_ADMを使用したローカルの取得プロセスの構成

DBMS_CAPTURE_ADMパッケージを使用してローカル取得プロセスを構成するには、次の手順を実行します。

1. 「取得プロセスの構成の準備」で説明されているタスクを完了します。

2. SQL*Plusで、Oracle Streams管理者としてソース・データベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

3. 取得プロセスで使用されるルール・セットを作成します(存在しない場合)。この例では、ルール・セットがstrmadmin.strm01_rule_setであると想定します。オプションで、ルール・セットにルールを追加することもできます。手順については、『Oracle Streams概要および管理』を参照してください。

4. DBMS_CAPTURE_ADMパッケージのCREATE_CAPTUREプロシージャを実行して、ローカルの取得プロセスを作成します。

BEGIN
DBMS_CAPTURE_ADM.CREATE_CAPTURE(
queue_name         => 'strmadmin.streams_queue',
capture_name       => 'strm02_capture',
rule_set_name      => 'strmadmin.strm01_rule_set',
start_scn          => NULL,
source_database    => NULL,
first_scn          => NULL);
END;
/

このプロシージャを実行すると、次のアクションが実行されます。

- 取得プロセスstrm02_captureが作成されます。同じ名前の取得プロセスは存在できません。

- 取得プロセスが、既存のキューstrmadmin.streams_queueに関連付けられます。

- 取得プロセスが、既存のルール・セットstrmadmin.strm01_rule_setに関連付けられます。このルール・セットは、取得プロセスのポジティブ・ルール・セットです。

- source_databaseパラメータがNULLに設定されているため、ソース・データベースに対するローカルの変更を取得する取得プロセスが作成されます。ローカルの取得プロセスの場合、このパラメータにローカル・データベースのグローバル名を指定する場合もあります。

- start_scnパラメータとfirst_scnパラメータの両方がNULLに設定されているため、取得プロセスの開始SCNと先頭SCNをOracle Databaseで決定するように指定されます。

- ローカルの変更を取得する取得プロセスがローカル・データベースで他に実行されていない場合は、DBMS_CAPTURE_ADMパッケージのBUILDプロシージャが自動的に実行されます。このプロシージャが実行されると、データ・ディクショナリがREDOログに抽出され、取得プロセスの初回起動時にLogMinerデータ・ディクショナリが作成されるようになります。

5. 必要に応じて、「取得プロセスの構成後」で説明されている手順を完了します。

関連項目:
ルールの詳細は、『Oracle Streams概要および管理』を参照してください。

NULL以外の開始SCNを使用したローカルの取得プロセスの構成

この例では、DBMS_CAPTURE_ADMパッケージのCREATE_CAPTUREプロシージャを実行して、開始SCNを223525に設定したローカルの取得プロセスを作成します。この例では、データベースに1つ以上のローカルの取得プロセスが存在し、その取得プロセスで1つ以上のチェックポイントが使用されていることを想定しています。新しい取得プロセスには、ソース・データベースの現行のSCN以上の開始SCNを常に指定できます。データベースの現在のSCNより小さい開始SCNを指定するには、既存のローカル取得プロセス(1回以上正常に起動され、1つ以上のチェックポイントが使用されているもの)の最小先頭SCNより大きくなるよう、開始SCNを指定する必要があります。

次の問合せを実行すると、既存の取得プロセスの先頭SCN、およびそれらの取得プロセスでチェックポイントが使用されているかどうかを判断できます。

SELECT CAPTURE_NAME, FIRST_SCN, MAX_CHECKPOINT_SCN FROM DBA_CAPTURE;

出力は次のようになります。

CAPTURE_NAME                    FIRST_SCN MAX_CHECKPOINT_SCN
------------------------------ ---------- ------------------
CAPTURE_SIMP                       223522             230825

これらの結果は、capture_simp取得プロセスの先頭SCNが223522であることを示しています。また、MAX_CHECKPOINT_SCN値はNULL以外であるため、この取得プロセスではチェックポイントが使用されています。したがって、新しい取得プロセスの開始SCNは223522以上に設定できます。

NULL以外の開始SCNを使用してローカル取得プロセスを構成するには、次の手順を実行します。

1. 「取得プロセスの構成の準備」で説明されているタスクを完了します。

2. SQL*Plusで、Oracle Streams管理者としてソース・データベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

3. 取得プロセスで使用されるルール・セットを作成します(存在しない場合)。この例では、ルール・セットがstrmadmin.strm01_rule_setであると想定します。オプションで、ルール・セットにルールを追加することもできます。手順については、『Oracle Streams概要および管理』を参照してください。

4. 次のプロシージャを実行して、取得プロセスを作成します。

BEGIN
DBMS_CAPTURE_ADM.CREATE_CAPTURE(
queue_name         => 'strmadmin.streams_queue',
capture_name       => 'strm03_capture',
rule_set_name      => 'strmadmin.strm01_rule_set',
start_scn          => 223525,
source_database    => NULL,
first_scn          => NULL);
END;
/

このプロシージャを実行すると、次のアクションが実行されます。

- 取得プロセスstrm03_captureが作成されます。同じ名前の取得プロセスは存在できません。

- 取得プロセスが、既存のキューstrmadmin.streams_queueに関連付けられます。

- 取得プロセスが、既存のルール・セットstrmadmin.strm01_rule_setに関連付けられます。このルール・セットは、取得プロセスのポジティブ・ルール・セットです。

- 取得プロセスの開始SCNとして223525が指定されます。新しい取得プロセスでは、既存の取得プロセスのいずれかと同じLogMinerデータ・ディクショナリが使用されます。Oracle Streamsでは、新しい取得プロセスと共有するLogMinerデータ・ディクショナリが自動的に選択されます。first_scnパラメータがNULLに設定されているため、新しい取得プロセスの先頭SCNは、LogMinerデータ・ディクショナリが共有されている既存の取得プロセスの先頭SCNと同じになります。この例では、既存の取得プロセスはcapture_simpです。

- source_databaseパラメータがNULLに設定されているため、ソース・データベースに対するローカルの変更を取得する取得プロセスが作成されます。ローカルの取得プロセスの場合、このパラメータにローカル・データベースのグローバル名を指定する場合もあります。

注意:
この例のプロシージャの実行時にローカルの取得プロセスが存在しない場合は、取得プロセスの作成時にDBMS_CAPTURE_ADM.BUILDプロシージャが自動的に実行され、データ・ディクショナリがREDOログに抽出されます。新しい取得プロセスの初回起動時に、このREDOデータを使用してLogMinerデータ・ディクショナリが作成されます。この場合、指定するstart_scnパラメータの値は、現行のデータベースのSCN以上にする必要があります。

5. 必要に応じて、「取得プロセスの構成後」で説明されている手順を完了します。

関連項目:

- 『Oracle Streams概要および管理』

- CREATE_CAPTUREプロシージャでfirst_scnパラメータとstart_scnパラメータを設定する方法の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

ダウンストリーム取得プロセスの構成

この項では、リアルタイム・ダウンストリーム取得プロセスまたはアーカイブ・ログ・ダウンストリーム取得プロセスの構成について説明します。

この項の内容は次のとおりです。

- リアルタイム・ダウンストリーム取得プロセスの構成

- アーカイブ・ログ・ダウンストリーム取得プロセスの構成

リアルタイム・ダウンストリーム取得プロセスの構成

ダウンストリーム取得を実行する取得プロセスを作成するには、CREATE_CAPTUREプロシージャを使用する必要があります。この項の例では、ソース・データベースへのデータベース・リンクを使用するリアルタイム・ダウンストリーム取得プロセスの作成について説明します。ただし、リアルタイム・ダウンストリーム取得プロセスでは、データベース・リンクは使用されないことがあります。

この例では、次のことを想定しています。

- ソース・データベースはdbs1.example.com、ダウンストリーム・データベースはdbs2.example.comです。

- dbs2.example.comで作成される取得プロセスでは、strmadmin.streams_queueが使用されます。

- 取得プロセスでは、hr.departments表に対するDML変更が取得されます。

この項では、DBMS_CAPTURE_ADMパッケージのCREATE_CAPTUREプロシージャを実行して、dbs1.example.comソース・データベースに対する変更を取得するリアルタイム・ダウンストリーム取得プロセスをdbs2.example.comダウンストリーム・データベースに作成する例について説明します。この例の取得プロセスでは、管理目的でdbs1.example.comへのデータベース・リンクが使用されます。データベース・リンクの名前は、ソース・データベースのグローバル名と一致している必要があります。

注意:
1つのダウンストリーム・データベースで、同じソース・データベースから変更を取得する複数のリアルタイム・ダウンストリーム取得プロセスを構成することはできますが、複数のソース・データベースに対するリアルタイム・ダウンストリーム取得を構成することはできません。

関連項目:
リアルタイム・ダウンストリーム取得の概念については、『Oracle Streams概要および管理』を参照してください。

手順は次のとおりです。

1. 「取得プロセスの構成の準備」で説明されているタスクを完了します。また、「ダウンストリーム取得データベースへのログ・ファイルの転送の構成」と「リアルタイム・ダウンストリーム取得のためのスタンバイREDOログの追加」のタスクが完了していることも確認してください。

2. SQL*Plusで、Oracle Streams管理者としてダウンストリーム・データベースdbs2.example.comに接続します。
SQL*Plusでのデータベースへの接続の詳細は、『Oracle Database管理者ガイド』を参照してください。

3. dbs2.example.comからdbs1.example.comへのデータベース・リンクを作成します。たとえば、ユーザーstrmadminが両方のデータベースでOracle Streams管理者である場合、次のデータベース・リンクを作成します。

CREATE DATABASE LINK dbs1.example.com CONNECT TO strmadmin
IDENTIFIED BY password
USING 'dbs1.example.com';

この例では、Oracle Streams管理者がソース・データベースdbs1.example.comに存在することを想定しています。ソース・データベースにOracle Streams管理者が存在しない場合は、ダウンストリーム・データベースのOracle Streams管理者が、Oracle Streams管理者からのリモート・アクセスを許可しているユーザーに接続する必要があります。ソース・データベースでDBMS_STREAMS_AUTHパッケージのGRANT_REMOTE_ADMIN_ACCESSプロシージャを実行するときに、ユーザーを権限受領者として指定すると、そのユーザーはリモートでアクセスできるようになります。

4. CREATE_CAPTUREプロシージャを実行して、取得プロセスを作成します。

BEGIN
DBMS_CAPTURE_ADM.CREATE_CAPTURE(
queue_name         => 'strmadmin.streams_queue',
capture_name       => 'real_time_capture',
rule_set_name      => NULL,
start_scn          => NULL,
source_database    => 'dbs1.example.com',
use_database_link  => TRUE,
first_scn          => NULL,
logfile_assignment => 'implicit');
END;
/

このプロシージャを実行すると、次のアクションが実行されます。

- ダウンストリーム・データベースdbs2.example.comに取得プロセスreal_time_captureが作成されます。同じ名前の取得プロセスは存在できません。

- 取得プロセスが、dbs2.example.comの既存のキューstreams_queueに関連付けられ、strmadminによって所有されます。

- 取得プロセスで取得される変更のソース・データベースがdbs1.example.comとなるように指定されます。

- 取得プロセスでソース・データベースのグローバル名と同じ名前のデータベース・リンクを使用して、ソース・データベースで管理アクションを実行するように指定されます。

- dbs1.example.comからのREDOデータを取得プロセスで暗黙的に受け入れるように指定されます。このため、取得プロセスでは、dbs2.example.comのスタンバイREDOログ内の取得が必要な変更がスキャンされます。取得プロセスが遅延した場合は、スタンバイREDOログから書き込まれたアーカイブREDOログ・ファイルがスキャンされます。

この手順では、取得プロセスreal_time_captureをルール・セットに関連付けません。ルール・セットは、後の手順で作成し、取得プロセスに関連付けます。

dbs2.example.comでdbs1.example.comソース・データベースからの変更を取得する取得プロセスが他にない場合は、データベース・リンクを使用して、DBMS_CAPTURE_ADM.BUILDプロシージャがdbs1.example.comで自動的に実行されます。このプロシージャが実行されると、dbs1.example.comのデータ・ディクショナリがREDOログに抽出され、dbs2.example.comでの取得プロセスreal_time_captureの初回起動時にdbs2.example.comでdbs1.example.comのLogMinerデータ・ディクショナリが作成されるようになります。

dbs2.example.comの複数の取得プロセスでdbs1.example.comソース・データベースからの変更を取得している場合、新しい取得プロセスreal_time_captureでは、既存のアーカイブ・ログ取得プロセスのいずれかと同じLogMinerデータ・ディクショナリがdbs1.example.comに対して使用されます。Oracle Streamsでは、新しい取得プロセスと共有するLogMinerデータ・ディクショナリが自動的に選択されます。

注意:
ダウンストリーム取得プロセスの作成時に、CREATE_CAPTUREプロシージャでfirst_scnパラメータをNULLに設定した場合、use_database_linkパラメータはTRUEに設定する必要があります。そうしないと、エラーが発生します。

関連項目:
取得プロセスに関するSCN値の詳細は、『Oracle Streams概要および管理』を参照してください。

5. downstream_real_time_mine取得プロセス・パラメータをYに設定します。

BEGIN
DBMS_CAPTURE_ADM.SET_PARAMETER(
capture_name => 'real_time_capture',
parameter    => 'downstream_real_time_mine',
value        => 'Y');
END;
/

6. 取得プロセスのポジティブ・ルール・セットを作成し、ルールを追加します。

BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
table_name          =>  'hr.departments',
streams_type        =>  'capture',
streams_name        =>  'real_time_capture',
queue_name          =>  'strmadmin.streams_queue',
include_dml         =>  TRUE,
include_ddl         =>  FALSE,
include_tagged_lcr  =>  FALSE,
source_database     =>  'dbs1.example.com',
inclusion_rule      =>  TRUE);
END;
/

このプロシージャを実行すると、次のアクションが実行されます。

- dbs2.example.comで取得プロセスreal_time_captureのルール・セットが作成されます。このルール・セットはシステム生成名を持ちます。inclusion_ruleパラメータがTRUEに設定されているため、このルール・セットは取得プロセスのポジティブ・ルール・セットとなります。

- hr.departments表に対するデータ操作言語(DML)変更を取得するルールが作成され、取得プロセスのポジティブ・ルール・セットに追加されます。このルールはシステム生成名を持ちます。inclusion_ruleパラメータがTRUEに設定されているため、このルールが取得プロセスのポジティブ・ルール・セットに追加されます。

- 手順3で作成したデータベース・リンクを使用して、dbs1.example.comのhr.departments表がインスタンス化のために準備されます。

- dbs1.example.comにある表の主キー列、一意キー列、ビットマップ索引列および外部キー列に対してサプリメンタル・ロギングが有効化されます。

7. ログ・ファイルを切り替えるために必要な権限を持つ管理ユーザーとして、ソース・データベースdbs1.example.comに接続します。

8. ソース・データベースで現行のログ・ファイルをアーカイブします。

ALTER SYSTEM ARCHIVE LOG CURRENT;

ソース・データベースで現行のログ・ファイルをアーカイブすると、ソース・データベースのREDOログのリアルタイム・マイニングが開始されます。

取得プロセスがREDOデータを待機している時間が異常に長い場合は、アラート・ログでエラーを確認してください。詳細は、『Oracle Streams概要および管理』を参照してください。

9. 必要に応じて、「取得プロセスの構成後」で説明されている手順を完了します。

アーカイブ・ログ・ダウンストリーム取得プロセスの構成

この項では、ログ・ファイルを暗黙的または明示的に割り当てるアーカイブ・ログ・ダウンストリーム取得プロセスの構成について説明します。

この項の内容は次のとおりです。

- ログを暗黙的に割り当てるアーカイブ・ログ・ダウンストリーム取得プロセスの構成

- ログを明示的に割り当てるアーカイブ・ログ・ダウンストリーム取得プロセスの構成

ログを暗黙的に割り当てるアーカイブ・ログ・ダウンストリーム取得プロセスの構成

ダウンストリーム取得を実行する取得プロセスを作成するには、CREATE_CAPTUREプロシージャを使用する必要があります。この項の例では、管理目的でソース・データベースへのデータベース・リンクを使用するアーカイブ・ログ・ダウンストリーム取得プロセスの作成について説明します。データベース・リンクの名前は、ソース・データベースのグローバル名と一致している必要があります。

この例では、次のことを想定しています。

- ソース・データベースはdbs1.example.com、ダウンストリーム・データベースはdbs2.example.comです。

- dbs2.example.comで作成される取得プロセスでは、strmadminによって所有されるstreams_queueが使用されます。

- この取得プロセスでは、dbs1.example.comのhr.departments表に対するデータ操作言語(DML)変更が取得されます。

- この取得プロセスでは、ログ・ファイルが暗黙的に割り当てられます。つまり、ダウンストリーム取得プロセスでは、REDO転送サービスまたは手動でソース・データベースからダウンストリーム・データベースに追加されたすべてのREDOログ・ファイルが自動的にスキャンされます。

手順は次のとおりです。

1. 「取得プロセスの構成の準備」で説明されているタスクを完了します。「ダウンストリーム取得データベースへのログ・ファイルの転送の構成」のタスクを完了してください。

2. SQL*Plusで、Oracle Streams管理者としてダウンストリーム・データベースdbs2.example.comに接続します。
SQL*Plusでのデータベースへの接続の詳細は、『Oracle Database管理者ガイド』を参照してください。

3. dbs2.example.comからdbs1.example.comへのデータベース・リンクを作成します。たとえば、ユーザーstrmadminが両方のデータベースでOracle Streams管理者である場合、次のデータベース・リンクを作成します。

CREATE DATABASE LINK dbs1.example.com CONNECT TO strmadmin
IDENTIFIED BY password
USING 'dbs1.example.com';

この例では、Oracle Streams管理者がソース・データベースdbs1.example.comに存在することを想定しています。ソース・データベースにOracle Streams管理者が存在しない場合は、ダウンストリーム・データベースのOracle Streams管理者が、Oracle Streams管理者からのリモート・アクセスを許可しているユーザーに接続する必要があります。ソース・データベースでDBMS_STREAMS_AUTHパッケージのGRANT_REMOTE_ADMIN_ACCESSプロシージャを実行するときに、ユーザーを権限受領者として指定すると、そのユーザーはリモートでアクセスできるようになります。

4. CREATE_CAPTUREプロシージャを実行して、取得プロセスを作成します。

BEGIN
DBMS_CAPTURE_ADM.CREATE_CAPTURE(
queue_name         => 'strmadmin.streams_queue',
capture_name       => 'strm04_capture',
rule_set_name      => NULL,
start_scn          => NULL,
source_database    => 'dbs1.example.com',
use_database_link  => TRUE,
first_scn          => NULL,
logfile_assignment => 'implicit');
END;
/

このプロシージャを実行すると、次のアクションが実行されます。

- ダウンストリーム・データベースdbs2.example.comに取得プロセスstrm04_captureが作成されます。同じ名前の取得プロセスは存在できません。

- 取得プロセスが、dbs2.example.comの既存のキューstreams_queueに関連付けられ、strmadminによって所有されます。

- 取得プロセスで取得される変更のソース・データベースがdbs1.example.comとなるように指定されます。

- 取得プロセスでdbs1.example.comからの新規のREDOログ・ファイルを暗黙的に受け入れるように指定されます。これにより、取得プロセスでは、dbs1.example.comからdbs2.example.comにコピーされた新規のログ・ファイルで取得が必要な変更がスキャンされるようになります。

この手順では、取得プロセスstrm04_captureをルール・セットに関連付けることはありません。ルール・セットは次の手順で作成し、取得プロセスと関連付けます。

dbs2.example.comでdbs1.example.comソース・データベースからの変更を取得する取得プロセスが他にない場合は、データベース・リンクを使用して、DBMS_CAPTURE_ADM.BUILDプロシージャがdbs1.example.comで自動的に実行されます。このプロシージャの実行により、dbs1.example.comのデータ・ディクショナリがREDOログに抽出され、dbs2.example.comでの取得プロセスの初回起動時にdbs2.example.comでdbs1.example.comのLogMinerデータ・ディクショナリが作成されるようになります。

dbs2.example.comの複数の取得プロセスでdbs1.example.comソース・データベースからの変更を取得している場合は、新規の取得プロセスでは既存の取得プロセスと同じdbs1.example.comのLogMinerデータ・ディクショナリが使用されます。Oracle Streamsでは、新しい取得プロセスと共有するLogMinerデータ・ディクショナリが自動的に選択されます。

注意:
ダウンストリーム取得プロセスの作成時に、CREATE_CAPTUREプロシージャでfirst_scnパラメータをNULLに設定した場合、use_database_linkパラメータはTRUEに設定する必要があります。そうしないと、エラーが発生します。

関連項目:

- 『Oracle Streams概要および管理』

- ALTER DATABASE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- REDOログ・ファイルの登録の詳細は、『Oracle Data Guard概要および管理』を参照してください。

5. 取得プロセスのポジティブ・ルール・セットを作成し、ルールを追加します。

BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
table_name          =>  'hr.departments',
streams_type        =>  'capture',
streams_name        =>  'strm04_capture',
queue_name          =>  'strmadmin.streams_queue',
include_dml         =>  TRUE,
include_ddl         =>  FALSE,
include_tagged_lcr  =>  FALSE,
source_database     =>  'dbs1.example.com',
inclusion_rule      =>  TRUE);
END;
/

このプロシージャを実行すると、次のアクションが実行されます。

- dbs2.example.comで取得プロセスstrm04_captureのルール・セットが作成されます。このルール・セットはシステム生成名を持ちます。inclusion_ruleパラメータがTRUEに設定されているため、このルール・セットが取得プロセスのポジティブ・ルール・セットとなります。

- hr.departments表に対するDML変更を取得するルールが作成され、取得プロセスのルール・セットに追加されます。このルールはシステム生成名を持ちます。inclusion_ruleパラメータがTRUEに設定されているため、このルールが取得プロセスのポジティブ・ルール・セットに追加されます。

6. 必要に応じて、「取得プロセスの構成後」で説明されている手順を完了します。

ログを明示的に割り当てるアーカイブ・ログ・ダウンストリーム取得プロセスの構成

ダウンストリーム取得を実行する取得プロセスを作成するには、CREATE_CAPTUREプロシージャを使用する必要があります。この項では、REDOログ・ファイルを明示的に割り当てるアーカイブ・ログ・ダウンストリーム取得プロセスの作成について説明します。つまり、DBMS_FILE_TRANSFERパッケージやFTPなどの方法を使用して、ソース・データベースからダウンストリーム・データベースにREDOログ・ファイルを転送してから、これらのREDOログ・ファイルを手動でダウンストリーム取得プロセスに登録する必要があります。

この例では、次のことを想定しています。

- ソース・データベースはdbs1.example.com、ダウンストリーム・データベースはdbs2.example.comです。

- dbs2.example.comで作成される取得プロセスでは、strmadminによって所有されるstreams_queueが使用されます。

- この取得プロセスでは、dbs1.example.comのhr.departments表に対するデータ操作言語(DML)変更が取得されます。

- 取得プロセスでは、管理アクション用にソース・データベースへのデータベース・リンクを使用しません。

手順は次のとおりです。

1. 「取得プロセスの構成の準備」で説明されているタスクを完了します。この例ではダウンストリーム・データベースでアーカイブREDOログ・ファイルを明示的に転送および登録しているため、「ダウンストリーム取得データベースへのログ・ファイルの転送の構成」のタスクを完了する必要はありません。

2. SQL*Plusで、Oracle Streams管理者としてソース・データベースdbs1.example.comに接続します。

ダウンストリーム・データベースからソース・データベースへのデータベース・リンクを使用しない場合は、Oracle Streams管理者がソース・データベースに存在している必要があります。

SQL*Plusでのデータベースへの接続の詳細は、『Oracle Database管理者ガイド』を参照してください。

3. dbs1.example.comからの変更を取得する取得プロセスがdbs2.example.comに存在しない場合は、REDOログのdbs1.example.comデータ・ディクショナリの構築を実行します。dbs2.example.comの取得プロセスがdbs1.example.comソース・データベースからの変更を取得するようにすでに構成されている場合、この手順は省略できます。

SET SERVEROUTPUT ON
DECLARE
scn  NUMBER;
BEGIN
DBMS_CAPTURE_ADM.BUILD(
first_scn => scn);
DBMS_OUTPUT.PUT_LINE('First SCN Value = ' || scn);
END;
/
First SCN Value = 409391

このプロシージャにより、dbs2.example.comに作成する取得プロセスの有効な先頭SCN値が表示されます。戻されたSCN値をメモし、dbs2.example.comに取得プロセスを作成するときに使用できるようにしてください。

このプロシージャを実行してREDOログのデータ・ディクショナリを構築する場合は、dbs2.example.comでの取得プロセスの初回起動時に、REDOログのデータ・ディクショナリ情報を使用してLogMinerデータ・ディクショナリが作成されます。

4. hr.departments表をインスタンス化のために準備します。

BEGIN
DBMS_CAPTURE_ADM.PREPARE_TABLE_INSTANTIATION(
table_name           =>  'hr.departments',
supplemental_logging =>  'keys');
END;
/

この例ではhr.departments表の変更を取得する取得プロセスを作成するため、この表に対して主キーのサプリメンタル・ロギングが必要です。PREPARE_TABLE_INSTANTIATIONプロシージャのsupplemental_loggingパラメータにkeysを指定すると、表の主キー列、一意キー列、ビットマック索引列および外部キー列のサプリメンタル・ロギングが有効化されます。

5. ソース・データベースの現行のSCNを判別します。

SET SERVEROUTPUT ON SIZE 1000000

DECLARE
iscn  NUMBER;         -- Variable to hold instantiation SCN value
BEGIN
iscn := DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER();
DBMS_OUTPUT.PUT_LINE('Current SCN: ' || iscn);
END;
/

戻されるSCNは、作成する取得プロセスによって取得されるhr.departments表の変更を適用する宛先データベースのインスタンス化SCNとして使用できます。この例では、戻されるSCNは1001656であると想定しています。

6. Oracle Streams管理者としてダウンストリーム・データベースdbs2.example.comに接続します。

7. CREATE_CAPTUREプロシージャを実行して、手順3で取得したfirst_scnパラメータの値を指定します。

BEGIN
DBMS_CAPTURE_ADM.CREATE_CAPTURE(
queue_name         => 'strmadmin.streams_queue',
capture_name       => 'strm05_capture',
rule_set_name      => NULL,
start_scn          => NULL,
source_database    => 'dbs1.example.com',
use_database_link  => FALSE,
first_scn          => 409391, -- Use value from Step 3
logfile_assignment => 'explicit');
END;
/

このプロシージャを実行すると、次のアクションが実行されます。

- ダウンストリーム・データベースdbs2.example.comに取得プロセスstrm05_captureが作成されます。同じ名前の取得プロセスは存在できません。

- 取得プロセスが、dbs2.example.comの既存のキューstreams_queueに関連付けられ、strmadminによって所有されます。

- 取得プロセスで取得される変更のソース・データベースがdbs1.example.comとなるように指定されます。

- 取得プロセスの先頭SCNが409391となるように指定されます。この値は、手順3で取得した値です。先頭SCNとは、取得プロセスで変更を取得できる最小SCNのことです。先頭SCNが指定されるため、取得プロセスの初回起動時に、同じソース・データベースの既存のLogMinerデータ・ディクショナリが存在するかどうかに関係なく、新しいLogMinerデータ・ディクショナリが作成されます。

- dbs1.example.comからの新しいREDOログ・ファイルを取得プロセスに明示的に割り当てる必要があるように指定されます。ダウンストリーム・データベースを実行しているコンピュータにREDOログ・ファイルが転送された後、次の文を使用して、ログ・ファイルを取得プロセスに明示的に割り当てます。

ALTER DATABASE REGISTER LOGICAL LOGFILE file_name FOR capture_process;

ここで、file_nameはREDOログ・ファイルの名前、capture_processはダウンストリーム・データベースでREDOログ・ファイルを使用する取得プロセスの名前です。logfile_assignmentパラメータがexplicitに設定されている場合は、REDOログ・ファイルを手動で追加する必要があります。

この手順では、取得プロセスstrm05_captureはルール・セットに関連付けられません。ルール・セットは次の手順で作成し、取得プロセスと関連付けます。

関連項目:

- 取得プロセスに関するSCN値の詳細は、『Oracle Streams概要および管理』を参照してください。

- ALTER DATABASE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- REDOログ・ファイルの登録の詳細は、『Oracle Data Guard概要および管理』を参照してください。

8. 取得プロセスのポジティブ・ルール・セットを作成し、ルールを追加します。

BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
table_name          =>  'hr.departments',
streams_type        =>  'capture',
streams_name        =>  'strm05_capture',
queue_name          =>  'strmadmin.streams_queue',
include_dml         =>  TRUE,
include_ddl         =>  FALSE,
include_tagged_lcr  =>  FALSE,
source_database     =>  'dbs1.example.com',
inclusion_rule      =>  TRUE);
END;
/

このプロシージャを実行すると、次のアクションが実行されます。

- dbs2.example.comで取得プロセスstrm05_captureのルール・セットが作成されます。このルール・セットはシステム生成名を持ちます。inclusion_ruleパラメータがTRUEに設定されているため、このルール・セットが取得プロセスのポジティブ・ルール・セットとなります。

- hr.departments表に対するDML変更を取得するルールが作成され、取得プロセスのルール・セットに追加されます。このルールはシステム生成名を持ちます。inclusion_ruleパラメータがTRUEに設定されているため、このルールが取得プロセスのポジティブ・ルール・セットに追加されます。

9. ダウンストリーム取得プロセスの先頭SCNを含むREDOログ・ファイルがソース・データベースdbs1.example.comでアーカイブされた後、ダウンストリーム・データベースを実行しているコンピュータにアーカイブREDOログ・ファイルを転送します。ダウンストリーム取得プロセスの先頭SCNは、手順3のBUILDプロシージャにより判別されています。REDOログ・ファイルがまだアーカイブされていない場合は、データベースでALTER SYSTEM SWITCH LOGFILE文を実行してアーカイブできます。
dbs1.example.comで次の問合せを実行して、ダウンストリーム取得プロセスの先頭SCNを含むアーカイブREDOログ・ファイルを識別できます。

COLUMN NAME HEADING 'Archived Redo Log|File Name' FORMAT A50
COLUMN FIRST_CHANGE# HEADING 'First SCN' FORMAT 999999999

SELECT NAME, FIRST_CHANGE# FROM V$ARCHIVED_LOG
WHERE FIRST_CHANGE# IS NOT NULL AND DICTIONARY_BEGIN = 'YES';

ダウンストリーム取得プロセスを実行しているコンピュータに、手順3で戻された先頭SCNと一致する、FIRST_CHANGE#という項目を含むアーカイブ・ログ・ファイルを転送します。

10. 管理ユーザーとしてダウンストリーム・データベースdbs2.example.comに接続します。

11. 転送されたREDOログ・ファイルを取得プロセスに割り当てます。たとえば、REDOログ・ファイルが/oracle/logs_from_dbs1/1_10_486574859.dbfの場合は、次の文を発行します。

ALTER DATABASE REGISTER LOGICAL LOGFILE
'/oracle/logs_from_dbs1/1_10_486574859.dbf' FOR 'strm05_capture';

12. 必要に応じて、「取得プロセスの構成後」で説明されている手順を完了します。

取得プロセスの構成後

新規の取得プロセスによって取得された論理変更レコード(LCR)を処理する伝播および適用プロセスを構成する場合は、次の順序で構成作業を行います。

1. レプリケーション環境で必須の伝播および適用プロセスとなるすべてのキューを作成します。「ANYDATAキューの作成」を参照してください。

2. 新規の取得プロセスによって取得されたLCRを伝播するすべての伝播を作成します。「ANYDATAキュー間のOracle Streamsの伝播の作成」を参照してください。

3. 新規の取得プロセスによって取得されたLCRをデキューして処理するすべての適用プロセスを作成します。第7章「暗黙的適用の構成」を参照してください。取得されたLCRを適用するように各適用プロセスを構成します。

4. 新規の取得プロセスがすべての宛先データベースで変更を取得する表をインスタンス化します。インスタンス化の詳細は、第8章「インスタンス化とOracle Streamsレプリケーション」を参照してください。

5. DBMS_APPLY_ADMパッケージのSTART_APPLYプロシージャを使用して、新規の取得プロセスによって取得されたLCRを処理する適用プロセスを起動します。または、Oracle Enterprise Managerを使用して適用プロセスを起動する手順については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

6. DBMS_CAPTURE_ADMパッケージのSTART_CAPTUREプロシージャを使用して、新規の取得プロセスを起動します。または、Oracle Enterprise Managerを使用して取得プロセスを起動する手順については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

注意:
Oracle Streams環境には、その他の構成手順が必要となる場合があります。たとえば、Oracle Streams環境には変換、適用ハンドラおよび競合解消が含まれている場合があります。

同期取得の構成

次のいずれかのプロシージャを使用して、同期取得を作成できます。

- DBMS_STREAMS_ADM.ADD_TABLE_RULES

- DBMS_STREAMS_ADM.ADD_SUBSET_RULES

- DBMS_CAPTURE_ADM.CREATE_SYNC_CAPTURE

DBMS_STREAMS_ADMパッケージの両方のプロシージャでは、名前を指定して同期取得を作成したり(存在しない場合)、同期取得にポジティブ・ルール・セットを作成します(存在しない場合)。また、ルール・セットに表ルールまたはサブセット・ルールを追加することもできます。

CREATE_SYNC_CAPTUREプロシージャでは、同期取得は作成しますが、その同期取得のルール・セットやルールは作成しません。ただし、CREATE_SYNC_CAPTUREプロシージャを使用すると、同期取得に関連付ける既存のルール・セットを指定したり、デフォルトの取得ユーザー以外の取得ユーザーを指定できます。

ここでは、同期取得の構成について説明します。

- 同期取得の構成の準備

- DBMS_STREAMS_ADMパッケージを使用した同期取得の構成

- DBMS_CAPTURE_ADMパッケージを使用した同期取得の構成

- 同期取得の構成後

関連項目:

- 『Oracle Streams概要および管理』

- 同期取得を使用するレプリケーション環境を構成する場合の例は、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

同期取得の構成の準備

同期取得を構成する前に、次のタスクを完了する必要があります。

- 「Oracle Streamsレプリケーションを構成する前に実行するタスク」で説明されている次のタスクを完了します。

- 「すべてのデータベースでのOracle Streams管理者の構成」

- 「ネットワーク接続性とデータベース・リンクの構成」

- 「Oracle Streamsに関連する初期化パラメータの設定」

- 「Oracle Streamsプールの構成」

- 同期取得に関連付けるANYDATAキューを作成します(存在しない場合)。手順については、「ANYDATAキューの作成」を参照してください。このキューはコミット時間キューである必要があります。この章の例では、同期取得で使用されるキューはstrmadmin.streams_queueであると想定しています。同期取得を実行するデータベースと同じデータベースでキューを作成します。

- 同期取得によって取得された論理変更レコード(LCR)を伝播する伝播、および同期取得によって取得されたLCRをデキューして処理する適用プロセスに関連付けるANYDATAキューを作成します(存在しない場合)。手順については、「ANYDATAキューの作成」を参照してください。

- 新規の同期取得によって取得されたLCRを伝播するすべての伝播を作成します。「ANYDATAキュー間のOracle Streamsの伝播の作成」を参照してください。

- 新規の同期取得によって取得されたLCRをデキューして処理するすべての適用プロセスを作成します。「DBMS_APPLY_ADMを使用した永続LCRの適用プロセスの作成」を参照してください。DBMS_APPLY_ADM.CREATE_APPLYプロシージャのapply_capturedパラメータをFALSEに設定して、永続LCRを適用するように各適用プロセスを構成します。「同期取得の構成後」で実行したインスタンス化が完了するまで適用プロセスを起動しないでください。

- Oracle Streams管理者にDBAロールが付与されていることを確認します。同期取得を作成するには、Oracle Streams管理者にDBAロールが付与されている必要があります。

DBMS_STREAMS_ADMパッケージを使用した同期取得の構成

ADD_TABLE_RULESまたはADD_SUBSET_RULESプロシージャを実行して同期取得を作成する場合は、これらのプロシージャのstreams_typeパラメータをsync_captureに設定します。ADD_TABLE_RULESプロシージャによって作成されるルールでは、表に対するすべてのデータ操作言語(DML)変更を取得するように同期取得に指示します。ADD_SUBSET_RULESプロシージャによって作成されるルールでは、表に対するDML変更のサブセットを取得するように同期取得に指示します。

この例では、次のことを想定しています。

- ソース・データベースはdbs1.example.comです。

- 作成される同期取得では、strmadmin.streams_queueキューを使用します。

- 作成される同期取得では、hr.departments表に対するDML変更の結果が取得されます。

- 作成される同期取得の取得ユーザーはOracle Streams管理者strmadminです。

DBMS_STREAMS_ADMパッケージを使用して同期取得を作成するには、次の手順を実行します。

1. 「同期取得の構成の準備」で説明されているタスクを完了します。

2. SQL*Plusで、Oracle Streams管理者としてdbs1.example.comデータベースに接続します。
SQL*Plusでのデータベースへの接続の詳細は、『Oracle Database管理者ガイド』を参照してください。

3. ADD_TABLE_RULESまたはADD_SUBSET_RULESプロシージャを実行して、同期取得を作成します。次に例を示します。

BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
table_name   => 'hr.departments',
streams_type => 'sync_capture',
streams_name => 'sync_capture',
queue_name   => 'strmadmin.streams_queue');
END;
/

このプロシージャを実行すると、次のアクションが実行されます。

- ソース・データベースに同期取得sync_captureが作成されます。

- 同期取得が有効化されます。同期取得を無効化することはできません。

- 同期取得が、既存のキューstrmadmin.streams_queueに関連付けられます。

- 同期取得にポジティブ・ルール・セットが作成されます。このルール・セットはシステム生成名を持ちます。

- hr.departments表に対するDML変更を取得するルールが作成され、同期取得のポジティブ・ルール・セットに追加されます。このルールはシステム生成名を持ちます。

- 同期取得の取得ユーザーとしてプロシージャを実行するユーザーが構成されます。この場合、ユーザーはstrmadminです。

- DBMS_CAPTURE_ADM.PREPARE_SYNC_INSTANTIATIONファンクションが指定された表に対して自動的に実行され、その表がインスタンス化のために準備されます。

注意:
ADD_TABLE_RULESまたはADD_SUBSET_RULESプロシージャは、同期取得ルール・セットにルールを追加する際、指定された表の排他ロックを取得する必要があります。指定された表に未解決のトランザクションが存在すると、プロシージャはロックを取得できるまで待機します。

4. 必要に応じて、「同期取得の構成後」で説明されている手順を完了します。

DBMS_CAPTURE_ADMパッケージを使用した同期取得の構成

この項では、DBMS_CAPTURE_ADMパッケージおよびDBMS_STREAMS_ADMパッケージのプロシージャを実行して同期取得を構成する例を取り上げます。

この例では、次のことを想定しています。

- ソース・データベースはdbs1.example.comです。

- 作成される同期取得では、strmadmin.streams_queueキューを使用します。

- 作成される同期取得では、strmadminスキーマの既存のルール・セットsync01_rule_setを使用します。

- 作成される同期取得では、hr.departments表に対するDML変更のサブセットの結果が取得されます。

- 作成される同期取得の取得ユーザーはhrです。hrユーザーには、streams_queueにエンキューするための権限が必要です。

DBMS_CAPTURE_ADMパッケージを使用して同期取得を作成するには、次の手順を実行します。

1. 「同期取得の構成の準備」で説明されているタスクを完了します。

2. SQL*Plusで、Oracle Streams管理者としてdbs1.example.comデータベースに接続します。
SQL*Plusでのデータベースへの接続の詳細は、『Oracle Database管理者ガイド』を参照してください。

3. 同期取得で使用されるルール・セットを作成します(存在しない場合)。この例では、ルール・セットがstrmadmin.sync01_rule_setであると想定しています。手順については、『Oracle Streams概要および管理』を参照してください。

4. CREATE_SYNC_CAPTUREプロシージャを実行して、同期取得を作成します。次に例を示します。

BEGIN
DBMS_CAPTURE_ADM.CREATE_SYNC_CAPTURE(
queue_name    => 'strmadmin.streams_queue',
capture_name  => 'sync01_capture',
rule_set_name => 'strmadmin.sync01_rule_set',
capture_user  => 'hr');
END;
/

このプロシージャを実行すると、次のアクションが実行されます。

- 同期取得sync01_captureが作成されます。同じ名前の同期取得は存在できません。

- 同期取得が有効化されます。同期取得を無効化することはできません。

- 同期取得が、既存のキューstrmadmin.streams_queueに関連付けられます。

- 同期取得が、既存のルール・セットstrmadmin.sync01_rule_setに関連付けられます。

- 同期取得の取得ユーザーとしてhrが構成されます。

5. ADD_TABLE_RULESまたはADD_SUBSET_RULESプロシージャを実行して、同期取得のルール・セットにルールを追加します。たとえば、ADD_SUBSET_RULESプロシージャを実行して、hr.departments表に対するDML変更のサブセットを取得するように同期取得に指示します。

BEGIN
DBMS_STREAMS_ADM.ADD_SUBSET_RULES(
table_name          => 'hr.departments',
dml_condition       => 'department_id=1700',
streams_type        => 'sync_capture',
streams_name        => 'sync01_capture',
queue_name          => 'strmadmin.streams_queue',
include_tagged_lcr  =>  FALSE);
END;
/

このプロシージャを実行すると、次のアクションが実行されます。

- ソース・データベースdbs1.example.comで同期取得sync01_captureのルール・セットにサブセット・ルールが追加されます。サブセット・ルールでは、department_idが1700の行に対する変更を取得するように同期取得に指示します。同期取得では、表の他の行に対する変更は取得されません。

- DBMS_CAPTURE_ADM.PREPARE_SYNC_INSTANTIATIONファンクションがhr.departments表に対して自動的に実行され、この表がインスタンス化のために準備されます。

- include_tagged_lcrパラメータがFALSEに設定されているため、変更が行われるセッションのタグがNULLの場合にのみ、同期取得で変更を取得するように指定されます。この動作は、同期取得のシステム作成ルールを介して実行されます。

注意:
CREATE_SYNC_CAPTUREプロシージャは、同期取得を作成する際、変更を取得する各表の排他ロックを取得する必要があります。排他ロックが必要な表は、同期取得に対して指定されたルール・セットのルールによって決定されます。同様に、ADD_TABLE_RULESまたはADD_SUBSET_RULESプロシージャは、同期取得ルール・セットにルールを追加する際、指定された表の排他ロックを取得する必要があります。この場合、同期取得が変更を取得する表に未解決のトランザクションが存在すると、プロシージャはロックを取得できるまで待機します。

6. 必要に応じて、「同期取得の構成後」で説明されている手順を完了します。

同期取得の構成後

新規の同期取得によって取得された論理変更レコード(LCR)を処理する伝播と適用プロセスの構成が完了した後、次の手順を実行します。

1. 新規の同期取得がすべての宛先データベースで変更を取得する表をインスタンス化します。インスタンス化の詳細は、第8章「インスタンス化とOracle Streamsレプリケーション」を参照してください。

2. DBMS_APPLY_ADMパッケージのSTART_APPLYプロシージャを使用して、新規の同期取得によって取得されたLCRを処理する適用プロセスを起動します。または、Oracle Enterprise Managerを使用して適用プロセスを起動する手順については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

注意:
Oracle Streams環境には、その他の構成手順が必要となる場合があります。たとえば、Oracle Streams環境には変換、適用ハンドラおよび競合解消が含まれている場合があります。

6 キューと伝播の構成

次のトピックでは、キューと伝播の構成について説明します。

- ANYDATAキューの作成

- ANYDATAキュー間のOracle Streamsの伝播の作成

この章で説明する各タスクは、特に指定がないかぎり、適切な権限を付与されたOracle Streams管理者が実行する必要があります。

関連項目:

- キューと伝播の詳細は、『Oracle Streams概要および管理』を参照してください。

- 「すべてのデータベースでのOracle Streams管理者の構成」

ANYDATAキューの作成

Oracle Streams環境では、メッセージはキューに格納されます。メッセージに対しては、エンキュー、異なるキュー間での伝播、およびデキューの処理を行うことができます。ANYDATAキューには、ペイロードがANYDATAタイプのメッセージが格納されます。したがって、ペイロードがANYDATAラッパーにラップされている場合は、ほぼすべてのタイプのペイロードを含むメッセージをANYDATAキューに格納できます。Oracle Streamsの各取得プロセス、同期取得、適用プロセスおよびメッセージ・クライアントが1つのANYDATAキューに関連付けられ、Oracle Streamsの各伝播が1つのANYDATAソース・キューと1つのANYDATA宛先キューに関連付けられます。

ANYDATAキューを作成する最も簡単な方法は、DBMS_STREAMS_ADMパッケージのSET_UP_QUEUEプロシージャを使用することです。このプロシージャを使用すると、作成するANYDATAキューについて次の設定を指定できます。

- キューのキュー表

- キュー表のSTORAGE句

- キュー名

- キューの保護キュー・ユーザーとして構成され、キューに対するENQUEUEおよびDEQUEUE権限が付与されるキュー・ユーザー

- キューに関するコメント

指定したキュー表が存在しない場合は、キュー表が作成されます。指定したキュー表が存在する場合は、既存のキュー表が新規キュー用に使用されます。キューの作成時にキュー表を指定しないと、デフォルトでstreams_queue_tableが指定されます。

たとえば、SET_UP_QUEUEプロシージャを使用してANYDATAキューを作成するには、次の手順を実行します。

1. ANYDATAキューを作成する前に、「Oracle Streamsレプリケーションを構成する前に実行するタスク」で説明されている次のタスクを完了します。

- 「すべてのデータベースでのOracle Streams管理者の構成」

- 「Oracle Streamsに関連する初期化パラメータの設定」

- 「Oracle Streamsプールの構成」

2. SQL*Plusで、Oracle Streams管理者としてキューを作成するデータベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

3. SET_UP_QUEUEプロシージャを実行して、次のキューを作成します。

BEGIN
DBMS_STREAMS_ADM.SET_UP_QUEUE(
queue_table => 'strmadmin.streams_queue_table',
queue_name  => 'strmadmin.streams_queue',
queue_user  => 'hr');
END;
/

このプロシージャを実行すると、次のアクションが実行されます。

- strmadminスキーマ内にキュー表streams_queue_tableが作成されます。このキュー表が作成されるのは、それが存在しない場合のみです。このキュー表に基づくキューには、ANYDATAタイプのメッセージが格納されます。キュー表の名前は、最大で24バイトです。

- strmadminスキーマ内にキューstreams_queueが作成されます。このキューが作成されるのは、それが存在しない場合のみです。キューの名前は、最大で24バイトです。

- streams_queueキューがstrmadmin.streams_queue_tableキュー表に基づくように指定されます。

- hrユーザーがキューの保護キュー・ユーザーとして構成され、このユーザーにキューに対するENQUEUE権限とDEQUEUE権限が付与されます。

- キューの起動。

SET_UP_QUEUEプロシージャで明示的に設定しないパラメータには、デフォルトの設定が使用されます。

SET_UP_QUEUEプロシージャでキュー表が作成されるとき、次のDBMS_AQADM.CREATE_QUEUE_TABLEパラメータ設定が指定されます。

- データベースがOracle Database 10g リリース2以上の場合、sort_list設定はcommit_timeです。データベースがOracle Database 10g リリース2より前のリリースの場合、sort_list設定はenq_timeです。

- multiple_consumers設定はTRUEです。

- message_grouping設定はtransactionalです。

- secure設定はTRUEです。

CREATE_QUEUE_TABLEプロシージャの他のパラメータは、それぞれのデフォルト値に設定されます。

DBMS_AQADMパッケージのCREATE_QUEUE_TABLEプロシージャを使用すると、DBMS_STREAMS_ADMパッケージのSET_UP_QUEUEプロシージャで指定されたデフォルト・プロパティ以外のプロパティを使用してANYDATAタイプのキュー表を作成できます。CREATE_QUEUE_TABLEプロシージャでキュー表を作成した後、そのキュー表を使用するキューを作成できます。そのためには、SET_UP_QUEUEプロシージャのqueue_tableパラメータにそのキュー表を指定します。

同様に、SET_UP_QUEUEのかわりに、DBMS_AQADMパッケージのCREATE_QUEUEプロシージャを使用してキューを作成できます。CREATE_QUEUEは、キューにカスタム設定が必要な場合に使用します。たとえば、CREATE_QUEUEを使用して、カスタムの再試行遅延や保存時間を指定できます。CREATE_QUEUEを使用する場合は、キューを手動で起動する必要があります。

注意:

- DBMS_STREAMS_ADMパッケージのプロシージャまたはOracle Enterprise Managerを使用して、Oracle Streams環境全体(キューを含む)を構成できます。第2章「Oracle Streamsレプリケーションの簡単な構成」を参照してください。

- メッセージをデキューできるサブスクライバが構成されていないと、メッセージをエンキューできません。

関連項目:

- 『Oracle Streams概要および管理』

- 『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイド』

- SET_UP_QUEUE、CREATE_QUEUE_TABLEおよびCREATE_QUEUEプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

ANYDATAキュー間のOracle Streamsの伝播の作成

伝播では、Oracle Streamsソース・キューからOracle Streams宛先キューにメッセージを送信します。また、Oracle Streamsアドバンスト・キューイング(AQ)の機能を使用して、Oracle Streamsの伝播を管理できます。

次の任意のプロシージャを使用して、2つのANYDATAキュー間の伝播を作成できます。

- DBMS_STREAMS_ADM.ADD_SUBSET_PROPAGATION_RULES

- DBMS_STREAMS_ADM.ADD_TABLE_PROPAGATION_RULES

- DBMS_STREAMS_ADM.ADD_SCHEMA_PROPAGATION_RULES

- DBMS_STREAMS_ADM.ADD_GLOBAL_PROPAGATION_RULES

- DBMS_PROPAGATION_ADM.CREATE_PROPAGATION

DBMS_STREAMS_ADMパッケージのこれらの各プロシージャでは、名前を指定して伝播を作成したり(存在しない場合)、伝播にポジティブ・ルール・セットまたはネガティブ・ルール・セットを作成します(伝播にこれらのルール・セットがない場合)。また、ルール・セットに表ルール、スキーマ・ルールまたはグローバル・ルールを追加することもできます。

CREATE_PROPAGATIONプロシージャでは、伝播は作成しますが、その伝播のルール・セットやルールは作成しません。ただし、CREATE_PROPAGATIONプロシージャを使用すると、伝播にポジティブ・ルール・セットまたはネガティブ・ルール・セットとして関連付ける既存のルール・セットを指定できます。すべての伝播が作成時に自動的に起動されます。

この項の内容は、次のとおりです。

- 伝播の作成の準備

- DBMS_STREAMS_ADMを使用した伝播の作成

- DBMS_PROPAGATION_ADMを使用した伝播の作成

注意:
DBMS_STREAMS_ADMパッケージのプロシージャまたはOracle Enterprise Managerを使用して、Oracle Streams環境全体(伝播を含む)を構成できます。第2章「Oracle Streamsレプリケーションの簡単な構成」を参照してください。

関連項目:

- 『Oracle Streams概要および管理』

- Oracle Streams AQの機能を使用して伝播を構成する方法の詳細および型付きのキュー間の伝播を構成する手順は、『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイド』を参照してください。

伝播の作成の準備

伝播を作成する前に、次のタスクを完了する必要があります。

- 「Oracle Streamsレプリケーションを構成する前に実行するタスク」で説明されている次のタスクを完了します。

- 「すべてのデータベースでのOracle Streams管理者の構成」

- 「ネットワーク接続性とデータベース・リンクの構成」(伝播でメッセージをデータベース間で送信する場合)

- 「Oracle Streamsに関連する初期化パラメータの設定」

- 「Oracle Streamsプールの構成」

- 存在しない場合は、伝播のソース・キューと宛先キューを作成します。キューは両方ともANYDATAキューである必要があります。この章の例では、ソース・キューがstrmadmin.strm_a_queue、宛先キューがstrmadmin.strm_b_queueであると想定しています。手順については、「ANYDATAキューの作成」を参照してください。

DBMS_STREAMS_ADMを使用した伝播の作成

DBMS_STREAMS_ADMパッケージのADD_TABLE_PROPAGATION_RULESプロシージャを使用して伝播を作成するには、次の手順を実行します。

1. 「伝播の作成の準備」で説明されているタスクを完了します。

2. SQL*Plusで、Oracle Streams管理者として伝播のソース・キューを含むデータベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

3. ADD_TABLE_PROPAGATION_RULESプロシージャを実行して、次の伝播を作成します。

BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_PROPAGATION_RULES(
table_name              => 'hr.departments',
streams_name            => 'strm01_propagation',
source_queue_name       => 'strmadmin.strm_a_queue',
destination_queue_name  => 'strmadmin.strm_b_queue@dbs2.example.com',
include_dml             => TRUE,
include_ddl             => TRUE,
include_tagged_lcr      => FALSE,
source_database         => 'dbs1.example.com',
inclusion_rule          => TRUE,
queue_to_queue          => TRUE);
END;
/

このプロシージャを実行すると、次のアクションが実行されます。

- 伝播strm01_propagationが作成されます。この伝播が作成されるのは、それが存在しない場合のみです。

- 伝播で現行のデータベース内のstrmadmin.strm_a_queueからdbs2.example.comデータベース内のstrmadmin.strm_b_queueに論理変更レコード(LCR)を伝播するように指定されます。これらのキューは必ず存在している必要があります。

- destination_queue_nameパラメータに@dbs2.example.comが指定されているため、伝播でdbs2.example.comデータベース・リンクを使用してLCRを伝播させるように指定されます。このデータベース・リンクは必ず存在している必要があります。

- inclusion_ruleパラメータがTRUEに設定されているため、ポジティブ・ルール・セットが作成され、伝播に関連付けられます。このルール・セットでは、評価コンテキストSYS.STREAMS$_EVALUATION_CONTEXTが使用されます。ルール・セット名は、システムによって生成されます。

- 2つのルールが作成されます。一方のルールは、hr.departments表に対するデータ操作言語(DML)変更の結果を含む行LCRについてTRUEと評価されます。もう一方のルールは、hr.departments表に対するデータ定義言語(DDL)変更を含むDDL LCRについてTRUEと評価されます。ルール名は、システムによって生成されます。

- この2つのルールが、伝播に関連付けられたポジティブ・ルール・セットに追加されます。inclusion_ruleパラメータがTRUEに設定されているため、ルールはポジティブ・ルール・セットに追加されます。

- include_tagged_lcrパラメータがFALSEに設定されているため、NULLタグがある場合にのみ伝播でLCRを伝播させるように設定されます。この動作は、伝播のシステム作成ルールを介して実行されます。

- 伝播されているLCRのソース・データベースがdbs1.example.comであることを指定しますが、これが現行のデータベースになるとはかぎりません。ソース・データベースが異なるソース・キューのLCRは伝播されません。

- キュー・ツー・キュー伝播の伝播ジョブが作成されます。

注意:
キュー・ツー・キュー伝播を使用するには、伝播に使用されるキューが含まれる各データベースの互換レベルが10.2.0以上である必要があります。

関連項目:

- キュー、伝播およびルールの詳細は、『Oracle Streams概要および管理』を参照してください。

- 第10章「Oracle Streamsタグ」

DBMS_PROPAGATION_ADMを使用した伝播の作成

DBMS_PROPAGATION_ADMパッケージのCREATE_PROPAGATIONプロシージャを使用して伝播を作成するには、次の手順を実行します。

1. 「伝播の作成の準備」で説明されているタスクを完了します。

2. SQL*Plusで、Oracle Streams管理者として伝播のソース・キューを含むデータベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

3. 伝播で使用されるルール・セットを作成します(存在しない場合)。この例では、ルール・セットがstrmadmin.strm01_rule_setであると想定します。オプションで、ルール・セットにルールを追加することもできます。手順については、『Oracle Streams概要および管理』を参照してください。

4. CREATE_PROPAGATIONプロシージャを実行して、次の伝播を作成します。

BEGIN
DBMS_PROPAGATION_ADM.CREATE_PROPAGATION(
propagation_name   => 'strm02_propagation',
source_queue       => 'strmadmin.strm_a_queue',
destination_queue  => 'strmadmin.strm_b_queue',
destination_dblink => 'dbs2.example.com',
rule_set_name      => 'strmadmin.strm01_rule_set',
queue_to_queue     => TRUE);
END;
/

このプロシージャを実行すると、次のアクションが実行されます。

- 伝播strm02_propagationが作成されます。同じ名前の伝播は存在できません。

- 伝播で現行のデータベース内のstrmadmin.strm_a_queueからdbs2.example.comデータベース内のstrmadmin.strm_b_queueにメッセージを伝播するように指定されます。これらのキューは必ず存在している必要があります。伝播のルール・セット内のルールに応じて、伝播されるメッセージはLCRまたはユーザー・メッセージ(あるいはその両方)になります。

- 伝播でdbs2.example.comデータベース・リンクを使用してメッセージを伝播するように指定されます。このデータベース・リンクは必ず存在している必要があります。

- 伝播が、ルール・セットstrmadmin.strm01_rule_setに関連付けられます。このルール・セットは必ず存在している必要があります。このルール・セットは、伝播のポジティブ・ルール・セットです。

- キュー・ツー・キュー伝播の伝播ジョブが作成されます。

注意:
キュー・ツー・キュー伝播を使用するには、伝播に使用されるキューが含まれる各データベースの互換レベルが10.2.0以上である必要があります。

7 暗黙的適用の構成

レプリケーション環境では、Oracle Streams適用プロセスが特定のキューから論理変更レコード(LCR)をデキューして、それぞれを直接適用するか、適用ハンドラと呼ばれるユーザー定義プロシージャにパラメータとして渡します。

次のトピックでは、暗黙的適用の構成について説明します。

- 適用プロセスの作成の概要

- DBMS_STREAMS_ADMを使用した取得LCRの適用プロセスの作成

- DBMS_APPLY_ADMを使用した適用プロセスの作成

この章で説明する各タスクは、特に指定がないかぎり、適切な権限を付与されたOracle Streams管理者が実行する必要があります。

関連項目:

- 『Oracle Streams概要および管理』

- 「すべてのデータベースでのOracle Streams管理者の構成」

適用プロセスの作成の概要

次の任意のプロシージャを使用して、適用プロセスを構成できます。

- DBMS_STREAMS_ADM.ADD_TABLE_RULES

- DBMS_STREAMS_ADM.ADD_SUBSET_RULES

- DBMS_STREAMS_ADM.ADD_SCHEMA_RULES

- DBMS_STREAMS_ADM.ADD_GLOBAL_RULES

- DBMS_STREAMS_ADM.ADD_MESSAGE_RULE

- DBMS_APPLY_ADM.CREATE_APPLY

DBMS_STREAMS_ADMパッケージの各プロシージャでは、名前を指定して適用プロセスを作成したり(存在しない場合)、適用プロセスにポジティブ・ルール・セットまたはネガティブ・ルール・セットを作成します(適用プロセスにこれらのルール・セットがない場合)。また、ルール・セットに表ルール、スキーマ・ルール、グローバル・ルールまたはメッセージ・ルールを追加することもできます。

DBMS_APPLY_ADMパッケージのCREATE_APPLYプロシージャでは、適用プロセスは作成しますが、その適用プロセスのルール・セットやルールは作成しません。ただし、CREATE_APPLYプロシージャを使用すると、適用プロセスにポジティブ・ルール・セットまたはネガティブ・ルール・セットとして関連付ける既存のルール・セットを指定したり、適用ハンドラ、適用ユーザー、適用タグなどの他の多数のオプションを指定でき、さらに、バッファ・キューまたは永続キューのいずれからメッセージをデキューするかを指定することもできます。

1つの適用プロセスでは、バッファ・キューまたは永続キューのいずれかからメッセージをデキューする必要があります。取得プロセスによって取得された論理変更レコードは取得LCRと呼ばれ、通常、バッファ・キューに格納されています。したがって、取得プロセスによって取得されたLCRを1つの適用プロセスで適用する場合は、永続LCRまたは永続ユーザー・メッセージは適用できません。

また、同期取得によって取得されたLCRは永続LCRであり、通常、永続キューに格納されています。したがって、同期取得によって取得されたLCRを1つの適用プロセスで適用する場合は、取得プロセスによって取得されたLCRは適用できません。ただし、永続LCRおよび永続ユーザー・メッセージについては、両方のタイプのメッセージが永続キューにステージングされるため、1つの適用プロセスで両方を適用できます。

この章の例では、取得LCR、永続LCRおよび永続ユーザー・メッセージを適用する適用プロセスを作成します。適用プロセスに関連付けるANYDATAキューが存在しない場合は、先にそのキューを作成してから、適用プロセスを作成します。

注意:

- DBMS_STREAMS_ADMパッケージのプロシージャまたはOracle Enterprise Managerを使用して、Oracle Streams環境全体(適用プロセスを含む)を構成できます。第2章「Oracle Streamsレプリケーションの簡単な構成」を参照してください。

- 作成する適用プロセスの構成によっては、適用プロセスで変更を適用する表の列について、ソース・データベースでサプリメンタル・ロギングが必要になる場合があります。「サプリメンタル・ロギングの指定」を参照してください。

- 取得LCRと永続LCRの詳細は、『Oracle Streams概要および管理』を参照してください。

適用プロセスの作成の準備

適用プロセスを作成する前に、次のタスクを完了する必要があります。

- 「Oracle Streamsレプリケーションを構成する前に実行するタスク」で説明されている次のタスクを完了します。

- 「すべてのデータベースでのOracle Streams管理者の構成」

- 「Oracle Streamsに関連する初期化パラメータの設定」

- 「Oracle Streamsプールの構成」

- 適用プロセスに関連付けるANYDATAキューを作成します(存在しない場合)。手順については、「ANYDATAキューの作成」を参照してください。この章の例では、適用プロセスで使用されるキューはstrmadmin.streams_queueであると想定しています。適用プロセスを実行するデータベースと同じデータベースでキューを作成します。

DBMS_STREAMS_ADMを使用した取得LCRの適用プロセスの作成

次の例では、DBMS_STREAMS_ADMパッケージのADD_SCHEMA_RULESプロシージャを実行して、取得論理変更レコード(LCR)を適用する適用プロセスを作成します。この適用プロセスでは、取得プロセスで取得されたLCRを適用できます。

手順は次のとおりです。

1. 「適用プロセスの作成の準備」で説明されているタスクを完了します。

2. SQL*Plusで、適用プロセスを実行するデータベースにOracle Streams管理者として接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

3. 次のように、適用プロセスを作成します。

BEGIN
DBMS_STREAMS_ADM.ADD_SCHEMA_RULES(
schema_name        => 'hr',
streams_type       => 'apply',
streams_name       => 'strm01_apply',
queue_name         => 'strmadmin.streams_queue',
include_dml        => TRUE,
include_ddl        => FALSE,
include_tagged_lcr => FALSE,
source_database    => 'dbs1.example.com',
inclusion_rule     => TRUE);
END;
/

このプロシージャを実行すると、次のアクションが実行されます。

- 取得LCRをローカル・データベースに適用する適用プロセスstrm01_applyが作成されます。この適用プロセスが作成されるのは、それが存在しない場合のみです。

- 適用プロセスが、既存のキューstrmadmin.streams_queueに関連付けられます。このキューは必ず存在している必要があります。

- inclusion_ruleパラメータがTRUEに設定されているため、適用プロセスにポジティブ・ルール・セットがない場合は、ポジティブ・ルール・セットが作成され、適用プロセスに関連付けられます。このルール・セットでは、SYS.STREAMS$_EVALUATION_CONTEXT評価コンテキストが使用されます。ルール・セット名は、システムによって生成されます。

- hrスキーマ内のデータベース・オブジェクトに対するデータ操作言語(DML)変更の結果を含む行LCRに対して、TRUEと評価されるルールが1つ作成されます。ルール名は、システムによって生成されます。

- inclusion_ruleパラメータがTRUEに設定されているため、このルールが、適用プロセスに関連付けられたポジティブ・ルール・セットに追加されます。

- 適用プロセスのapply_tagが、'00'(2つのゼロ)と等価の16進値に設定されます。この値がデフォルトの適用タグ値です。適用プロセスで生成されるREDOエントリのタグは、この値になります。

- include_tagged_lcrパラメータがFALSEに設定されているため、NULLタグがある場合にのみ適用プロセスで行LCRを適用するように設定されます。この動作は、適用プロセスのシステム作成ルールを介して実行されます。

- 適用プロセスでdbs1.example.comソース・データベースからのLCRを適用するように指定されます。適用プロセスでデキューされるLCRは、適用プロセスのルール・セット内のルールによって決定されます。適用プロセスでdbs1.example.com以外のソース・データベースからのLCRがデキューされた場合、エラーが発生します。

DBMS_APPLY_ADMを使用した適用プロセスの作成

この項では、DBMS_APPLY_ADMパッケージを使用して適用プロセスを作成する次の例を取り上げます。

- DBMS_APPLY_ADMを使用した取得LCRの適用プロセスの作成

- DBMS_APPLY_ADMを使用した永続LCRの適用プロセスの作成

関連項目:

- apply_database_linkパラメータを使用してOracle以外のデータベースにメッセージを適用するように適用プロセスを構成する方法の詳細は、「OracleからOracle以外への環境での変更の適用」を参照してください。

- 『Oracle Streams概要および管理』

DBMS_APPLY_ADMを使用した取得LCRの適用プロセスの作成

次の例では、DBMS_APPLY_ADMパッケージのCREATE_APPLYプロシージャを実行して、取得論理変更レコード(LCR)を適用する適用プロセスを作成します。この適用プロセスでは、取得プロセスで取得されたLCRを適用できます。

手順は次のとおりです。

1. 「適用プロセスの作成の準備」で説明されているタスクを完了します。

2. SQL*Plusで、適用プロセスを実行するデータベースにOracle Streams管理者として接続します。
Oracle Streams管理者にDBAロールが付与されていることを確認します。この例では、適用ユーザーをOracle Streams管理者以外のユーザーに設定するため、DBAロールが必要です。

SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

3. 適用プロセスで使用されるルール・セットを作成します(存在しない場合)。この例では、ルール・セットがstrmadmin.strm02_rule_setであると想定します。オプションで、ルール・セットにルールを追加することもできます。手順については、『Oracle Streams概要および管理』を参照してください。

4. 適用プロセスで使用される適用ハンドラを作成します(存在しない場合)。この例では、DDLハンドラがstrmadmin.history_ddlプロシージャであると想定します。『Oracle Streams概要および管理』の例でこのプロシージャを作成しています。

5. 次のように、適用プロセスを作成します。

BEGIN
DBMS_APPLY_ADM.CREATE_APPLY(
queue_name             => 'strmadmin.streams_queue',
apply_name             => 'strm02_apply',
rule_set_name          => 'strmadmin.strm02_rule_set',
message_handler        => NULL,
ddl_handler            => 'strmadmin.history_ddl',
apply_user             => 'hr',
apply_database_link    => NULL,
apply_tag              => HEXTORAW('5'),
apply_captured         => TRUE,
precommit_handler      => NULL,
negative_rule_set_name => NULL,
source_database        => 'dbs1.example.com');
END;
/

このプロシージャを実行すると、次のアクションが実行されます。

- 適用プロセスstrm02_applyが作成されます。同じ名前の適用プロセスは存在できません。

- 適用プロセスが、キューstrmadmin.streams_queueに関連付けられます。このキューは必ず存在している必要があります。

- 適用プロセスが、ルール・セットstrmadmin.strm02_rule_setに関連付けられます。このルール・セットは必ず存在している必要があります。このルール・セットは、適用プロセスのポジティブ・ルール・セットです。

- メッセージ・ハンドラが適用プロセスで使用されないように指定されます。

- DDLハンドラがstrmadminスキーマ内のhistory_ddl PL/SQLプロシージャとなるように指定されます。このプロシージャが存在し、CREATE_APPLYプロシージャを実行するユーザーにhistory_ddl PL/SQLプロシージャに対するEXECUTE権限が付与されている必要があります。

- 変更を適用するユーザーがhrであり、CREATE_APPLYプロシージャを実行するユーザー(Oracle Streams管理者)とならないように指定されます。

- apply_database_linkパラメータがNULLに設定されているため、適用プロセスによってローカル・データベースに変更が適用されるように指定されます。

- 適用プロセスによって生成される各REDOエントリのタグが'5'と等価の16進値になるように指定されます。タグの詳細は、第10章「Oracle Streamsタグ」を参照してください。

- 適用プロセスで永続LCRや永続ユーザー・メッセージではなく取得LCRを適用するように指定されます。したがって、取得プロセスではなく同期取得やユーザー・アプリケーションによってLCRが構成され、そのLCRが適用プロセスのキューにステージングされている場合、この適用プロセスではLCRはデキューされません。

- プリコミット・ハンドラが適用プロセスで使用されないように指定されます。

- ネガティブ・ルール・セットが適用プロセスで使用されないように指定されます。

- 適用プロセスでdbs1.example.comソース・データベースからのLCRを適用するように指定されます。適用プロセスでデキューされるLCRは、適用プロセスのルール・セット内のルールによって決定されます。適用プロセスでdbs1.example.com以外のソース・データベースからのLCRがデキューされた場合、エラーが発生します。

適用プロセスを作成した後、ADD_TABLE_RULESまたはADD_SUBSET_RULESプロシージャを実行して、適用プロセスのルール・セットにルールを追加します。これらのルールによって、適用プロセスは、指定された表のLCRを適用するように指示されます。

関連項目:
ルールの詳細は、『Oracle Streams概要および管理』を参照してください。

DBMS_APPLY_ADMを使用した永続LCRの適用プロセスの作成

次の例では、DBMS_APPLY_ADMパッケージのCREATE_APPLYプロシージャを実行して、永続論理変更レコード(LCR)を適用する適用プロセスを作成します。この適用プロセスでは、同期取得によって取得されたLCRやアプリケーションによって構成されたLCRを適用できます。

手順は次のとおりです。

1. 「適用プロセスの作成の準備」で説明されているタスクを完了します。

2. SQL*Plusで、適用プロセスを実行するデータベースにOracle Streams管理者として接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

3. 適用プロセスで使用されるルール・セットを作成します(存在しない場合)。この例では、ルール・セットがstrmadmin.strm03_rule_setであると想定します。オプションで、ルール・セットにルールを追加することもできます。手順については、『Oracle Streams概要および管理』を参照してください。

4. 適用プロセスで使用される適用ハンドラを作成します(存在しない場合)。この例で作成される適用プロセスでは、適用ハンドラは使用されません。

5. 次のように、適用プロセスを作成します。

BEGIN
DBMS_APPLY_ADM.CREATE_APPLY(
queue_name             => 'strmadmin.streams_queue',
apply_name             => 'strm03_apply',
rule_set_name          => 'strmadmin.strm03_rule_set',
message_handler        => NULL,
ddl_handler            => NULL,
apply_user             => NULL,
apply_database_link    => NULL,
apply_tag              => NULL,
apply_captured         => FALSE,
precommit_handler      => NULL,
negative_rule_set_name => NULL);
END;
/

このプロシージャを実行すると、次のアクションが実行されます。

- 適用プロセスstrm03_applyが作成されます。同じ名前の適用プロセスは存在できません。

- 適用プロセスが、キューstrmadmin.streams_queueに関連付けられます。このキューは必ず存在している必要があります。

- 適用プロセスが、ルール・セットstrmadmin.strm03_rule_setに関連付けられます。このルール・セットは必ず存在している必要があります。このルール・セットは、適用プロセスのポジティブ・ルール・セットです。

- メッセージ・ハンドラが適用プロセスで使用されないように指定されます。

- DDLハンドラが適用プロセスで使用されないように指定されます。

- apply_userパラメータがNULLであるため、変更を適用するユーザーがCREATE_APPLYプロシージャを実行するユーザーになるように指定されます。

- apply_database_linkパラメータがNULLに設定されているため、適用プロセスによってローカル・データベースに変更が適用されるように指定されます。

- 適用プロセスで生成される各REDOエントリのタグがNULLになるように指定されます。タグの詳細は、第10章「Oracle Streamsタグ」を参照してください。

- 取得LCRが適用プロセスで適用されないように指定されます。したがって、適用プロセスで、適用プロセス・キューの永続キュー部分に含まれている永続LCRまたは永続ユーザー・メッセージを適用できます。

- プリコミット・ハンドラが適用プロセスで使用されないように指定されます。

- ネガティブ・ルール・セットが適用プロセスで使用されないように指定されます。

適用プロセスを作成した後、ADD_TABLE_RULESまたはADD_SUBSET_RULESプロシージャを実行して、適用プロセスのルール・セットにルールを追加します。これらのルールによって、適用プロセスは、指定された表のLCRを適用するように指示されます。

関連項目:
ルールの詳細は、『Oracle Streams概要および管理』を参照してください。

8 インスタンス化とOracle Streamsレプリケーション

この章では、インスタンス化とOracle Streamsレプリケーションの概念について説明します。また、インスタンス化のためのデータベース・オブジェクトの準備、インスタンス化の実行、インスタンス化システム変更番号(SCN)の設定およびインスタンス化の監視の各手順についても説明します。

この章の内容は次のとおりです。

- インスタンス化とOracle Streamsレプリケーションの概要

- 取得のルールとインスタンス化の準備

- Oracle Data PumpとOracle Streamsのインスタンス化

- Recovery Manager(RMAN)とOracle Streamsのインスタンス化

- 宛先データベースでのインスタンス化SCNの設定

- インスタンス化の監視

インスタンス化とOracle Streamsレプリケーションの概要

単一のデータベース内または複数のデータベース間で1つのデータベース・オブジェクトをレプリケートするOracle Streams環境では、ソース・データベースでオブジェクトに対する変更が生成され、宛先データベースで変更が適用プロセスによってデキューされます。このような変更が取得プロセスまたは同期取得で取得され、その変更がローカルに適用されるか、または他のデータベースに伝播されてから宛先データベースで適用される場合は、オブジェクトに対する変更をレプリケートする前に、ソース・データベース・オブジェクトをインスタンス化する必要があります。ソース・データベース・オブジェクトへの変更が適用されるデータベースが、ソース・データベースと異なる場合は、宛先データベースにこれらのデータベース・オブジェクトのコピーが必要です。

Oracle Streamsでは通常、次の手順を実行してデータベース・オブジェクトをインスタンス化します。

1. ソース・データベースでデータベース・オブジェクトをインスタンス化のために準備します。

2. データベース・オブジェクトのコピーが宛先データベースに存在しない場合、ソース・データベースのデータベース・オブジェクトに基づいて、宛先データベースで物理的にデータベース・オブジェクトを作成します。エクスポート/インポート、トランスポータブル表領域またはRMANを使用して、インスタンス化用にデータベース・オブジェクトをコピーできます。宛先データベースにデータベース・オブジェクトが存在する場合は、この手順は不要です。

3. 宛先データベースで、データベース・オブジェクトのインスタンス化システム変更番号(SCN)を設定します。インスタンス化SCNは、宛先データベースの適用プロセスに対して、指定したSCNの後にソース・データベースでコミットされた変更のみを適用するように指示します。

レプリケーション環境の構成用にOracleが提供するDBMS_STREAMS_ADMパッケージの次のいずれかのプロシージャを使用すると、これらすべてのインスタンス化手順を自動的に実行できます。

- MAINTAIN_GLOBAL

- MAINTAIN_SCHEMAS

- MAINTAIN_SIMPLE_TTS

- MAINTAIN_TABLES

- MAINTAIN_TTS

手順1と手順3は自動的に完了する場合もあります。たとえば、DBMS_STREAMS_ADMパッケージのプロシージャを実行して取得プロセスのポジティブ・ルール・セットにデータベース・オブジェクトのルールを追加すると、データベース・オブジェクトは自動的にインスタンス化のために準備されます。

また、エクスポート/インポート、トランスポータブル表領域またはRMANのTRANSPORT TABLESPACEコマンドを使用してデータベース・オブジェクトをソース・データベースから宛先データベースへコピーすると、このデータベース・オブジェクトのインスタンス化SCNを自動的に設定できます。

注意:
RMANのDUPLICATEコマンドにより、データベース全体をインスタンス化できますが、このコマンドでは、データベース・オブジェクトのインスタンス化SCNは設定されません。

インスタンス化されるデータベース・オブジェクトが表である場合、ソース・データベースと宛先データベースの表は完全に一致していなくてもかまいません。ただし、表データの一部または全部を2つのデータベース間でレプリケートする場合、表をインスタンス化したときにレプリケートするデータに一貫性がある必要があります。データベース・オブジェクトに対する変更をレプリケートする場合は、常にデータベース・オブジェクトをソース・データベースでインスタンス化のために準備して、宛先データベースでデータベース・オブジェクトのインスタンス化SCNを設定する必要があります。インスタンス化のためにオブジェクトを準備することで、オブジェクトに対する変更を宛先データベースで適用できる最小SCNが設定されます。このSCNは非処理SCNと呼ばれます。データベース・オブジェクトに対する変更を取得するように取得プロセスまたは同期取得を構成した後に、データベース・オブジェクトをインスタンス化する準備を行う必要があります。

エクスポート/インポート、トランスポータブル表領域またはRMANを使用して表をインスタンス化した場合、インスタンス化された表についてサプリメンタル・ログ・グループの指定が保持されます。つまり、インスタンス化の後、インポート・データベースのインポートされた表のログ・グループ指定は、エクスポート・データベースの同じ表のログ・グループの指定と同じです。インポート・データベースで表のサプリメンタル・ログ・グループの指定を保持しない場合は、インポート後に特定のサプリメンタル・ログ・グループを削除できます。

全データベースのエクスポート/インポートを実行する場合でも、エクスポート/インポート中はデータベース・サプリメンタル・ロギングの指定は保持されません。一方、RMANのDUPLICATEコマンドでは、データベース・サプリメンタル・ロギングの指定はインスタンス化されたデータベースで保持されます。

注意:

- Oracle Streamsをインスタンス化するためのエクスポート中は、エクスポート対象のオブジェクトに対してデータ定義言語(DDL)変更が行われないように注意してください。

- 非NULLアクション・コンテキストを持つルールを含むデータベースまたはスキーマをエクスポートする場合は、そのルールを所有するスキーマのデータベースまたはデフォルト表領域が書込み可能である必要があります。データベースまたは表領域が読取り専用であると、エクスポート・エラーが発生します。

関連項目:

- 適用プロセスの最も古いSCNの詳細は、『Oracle Streams概要および管理』を参照してください。

- 「DBMS_STREAMS_ADMパッケージを使用したレプリケーションの構成」

- サプリメンタル・ログ・グループを追加および削除する方法の詳細は、「サプリメンタル・ロギングの指定」を参照してください。

取得のルールとインスタンス化の準備

DBMS_CAPTURE_ADMパッケージの次のサブプログラムでは、インスタンス化のためにデータベース・オブジェクトの準備が行われます。

- PREPARE_TABLE_INSTANTIATIONプロシージャでは、表に対する変更が取得プロセスによって取得される場合、1つの表がインスタンス化のために準備されます。

- PREPARE_SYNC_INSTANTIATIONファンクションでは、表(1つまたは複数)に対する変更が同期取得によって取得される場合、1つの表または複数の表がインスタンス化のために準備されます。

- PREPARE_SCHEMA_INSTANTIATIONプロシージャでは、スキーマ内のすべてのデータベース・オブジェクトおよび将来そのスキーマに追加されるすべてのデータベース・オブジェクトがインスタンス化のために準備されます。このプロシージャは、取得プロセスによって変更が取得される場合にのみ使用する必要があります。

- PREPARE_GLOBAL_INSTANTIATIONプロシージャでは、データベース内のすべてのデータベース・オブジェクトおよび将来そのデータベースに追加されるすべてのデータベース・オブジェクトがインスタンス化のために準備されます。このプロシージャは、取得プロセスによって変更が取得される場合にのみ使用する必要があります。

これらのプロシージャでは、インスタンス化のために各オブジェクトの最小システム変更番号(SCN)が記録されます。オブジェクトの最小SCNより後のSCNは、そのオブジェクトのインスタンス化に使用できます。

変更の取得に取得プロセスを使用する場合、前述のプロシージャでは、インスタンス化の準備対象となる表、スキーマまたはデータベースに対する変更を取得、伝播または適用する取得プロセス、伝播および適用プロセスのために、Oracle Streamsデータ・ディクショナリが移入されます。また、取得プロセスを使用して変更を取得する場合は、オプションでこれらのプロシージャを使用して、インスタンス化のために準備された表のキー列またはすべての列のサプリメンタル・ロギングを有効にすることもできます。

注意:
同期取得を使用するレプリケーションでは、Oracle Streamsデータ・ディクショナリは使用されず、サプリメンタル・ロギングは不要です。

関連項目:

- 「ソース・データベースでインスタンス化を行うためのデータベース・オブジェクトの準備」

- 「サプリメンタル・ロギングを自動的に指定するプロシージャ」

- Oracle Streamsデータ・ディクショナリの詳細は、『Oracle Streams概要および管理』を参照してください。

自動的にオブジェクトを準備するDBMS_STREAMS_ADMパッケージのプロシージャ

DBMS_STREAMS_ADMパッケージ内のプロシージャを実行して取得プロセスまたは同期取得のポジティブ・ルール・セットにルールを追加すると、変更が取得されるデータベース・オブジェクトに対して、DBMS_CAPTURE_ADMパッケージのプロシージャまたはファンクションが自動的に実行されます。表8-1に、DBMS_STREAMS_ADMパッケージのプロシージャを実行した場合に実行されるDBMS_CAPTURE_ADMパッケージのプロシージャまたはファンクションを示します。

表8-1 自動的に実行されるDBMS_CAPTURE_ADMパッケージのプロシージャ

実行するDBMS_STREAMS_ADMパッケージのプロシージャ

自動的に実行されるDBMS_CAPTURE_ADMパッケージのプロシージャまたはファンクション

ADD_TABLE_RULES

ADD_SUBSET_RULES

PREPARE_TABLE_INSTANTIATION(取得プロセスのルール・セットにルールが追加された場合)

PREPARE_SYNC_INSTANTIATION(同期取得のルール・セットにルールが追加された場合)

ADD_SCHEMA_RULES

PREPARE_SCHEMA_INSTANTIATION

ADD_GLOBAL_RULES

PREPARE_GLOBAL_INSTANTIATION

プロシージャは、インスタンス化を準備するために複数回コールできます。ダウンストリームの取得を使用していて、ダウンストリームの取得プロセスでダウンストリーム・データベースからソース・データベースへのデータベース・リンクが使用されている場合、DBMS_STREAMS_ADMパッケージのこれらのプロシージャのいずれかを実行すると、データベース・オブジェクトは自動的にインスタンス化のために準備されます。ただし、ダウンストリームの取得プロセスでダウンストリーム・データベースからソース・データベースへのデータベース・リンクを使用していない場合、データベース・オブジェクトをインスタンス化する準備を手動で行う必要があります。

DBMS_STREAMS_ADMパッケージではなく、DBMS_RULE_ADMパッケージによって取得プロセスのルールが作成される場合、取得プロセスのルールの結果生じた変更を適用プロセスで適用するには、適切なプロシージャを手動で実行して、変更が取得される各表、スキーマまたはデータベースをインスタンス化のために準備する必要があります。

また、これらのプロシージャを自動的に実行するプロシージャもいくつか存在します。たとえば、DBMS_STREAMS_ADM.MAINTAIN_TABLESプロシージャでは、ADD_TABLE_RULESプロシージャが自動的に実行されます。

注意:
同期取得では、ADD_TABLE_RULESまたはADD_SUBSET_RULESプロシージャで作成されたルールに基づく変更のみが取得されます。

関連項目:
「DBMS_STREAMS_ADMパッケージを使用したレプリケーションの構成」

インスタンス化の準備が必要な場合

次のいずれかの条件が該当する場合、データベース・オブジェクトの取得プロセス、伝播または適用プロセスのポジティブ・ルール・セットに含まれるルールについて、条件を追加または変更する際に、常に適切なプロシージャを実行して、ソース・データベースでそのデータベース・オブジェクトをインスタンス化のために準備する必要があります。

- オブジェクトに対する変更を取得するように指示する取得プロセスのポジティブ・ルール・セットに、1つ以上のルールを追加する。

- オブジェクトに対する変更を取得するように指示する取得プロセスのポジティブ・ルール・セットで、ルールについて1つ以上の条件を変更する。

- オブジェクトに対する変更を伝播するように指示する伝播のポジティブ・ルール・セットに、1つ以上のルールを追加する。

- オブジェクトに対する変更を伝播するように指示する伝播のポジティブ・ルール・セットで、ルールについて1つ以上の条件を変更する。

- ソース・データベースのオブジェクトに対する変更を適用するように指示する適用プロセスのポジティブ・ルール・セットに、1つ以上のルールを追加する。

- ソース・データベースのオブジェクトに対する変更を適用するように指示する適用プロセスのポジティブ・ルール・セットで、ルールについて1つ以上の条件を変更する。

次のいずれかの条件が該当する場合、データベース・オブジェクトの取得プロセス、伝播または適用プロセスのネガティブ・ルール・セットに含まれるルールについて、条件を削除または変更する際に、常に適切なプロシージャを実行して、ソース・データベースでそのデータベース・オブジェクトをインスタンス化のために準備する必要があります。

- オブジェクトに対する変更を取得するように指示する取得プロセスのネガティブ・ルール・セットから、1つ以上のルールを削除する。

- オブジェクトに対する変更を取得するように指示する取得プロセスのネガティブ・ルール・セットで、ルールについて1つ以上の条件を変更する。

- オブジェクトに対する変更を伝播するように指示する伝播のネガティブ・ルール・セットから、1つ以上のルールを削除する。

- オブジェクトに対する変更を伝播するように指示する伝播のネガティブ・ルール・セットで、ルールについて1つ以上の条件を変更する。

- ソース・データベースのオブジェクトに対する変更を適用するように指示する適用プロセスのネガティブ・ルール・セットから、1つ以上のルールを削除する。

- ソース・データベースのオブジェクトに対する変更を適用するように指示する適用プロセスのネガティブ・ルール・セットで、ルールについて1つ以上の条件を変更する。

ポジティブまたはネガティブ・ルール・セットに対する変更について、前述の条件に1つでも該当する場合は、ルールを追加または変更したリモート・データベースにオブジェクトが存在していても、ソース・データベースでインスタンス化のために関連するデータベース・オブジェクトの準備を行って、ソース・オブジェクトに関する情報が必要な関連するOracle Streamsデータ・ディクショナリを移入する必要があります。

関連するOracle Streamsデータ・ディクショナリは、ローカル・ディクショナリとすべてのリモート・ディクショナリについて非同期に移入されます。インスタンス化の準備を行うプロシージャでは、ソース・データベースのREDOログに情報が追加されます。ローカルのOracle Streamsデータ・ディクショナリには、取得プロセスがこれらのREDOエントリを取得するとオブジェクトに関する情報が移入され、リモートのOracle Streamsデータ・ディクショナリには情報が伝播されると移入されます。

同期取得ではOracle Streamsデータ・ディクショナリは使用されません。ただし、同期取得でデータベース・オブジェクトに対する変更を取得している場合は、同期取得のルール・セットにデータベース・オブジェクトのルールを追加する際に、データベース・オブジェクトをインスタンス化のために準備する必要があります。データベース・オブジェクトに対するインスタンス化のための最小SCNが記録されるため、ルールを追加する際に、データベース・オブジェクトをインスタンス化のために準備する必要があります。同期取得のルールが変更されている場合は、データベース・オブジェクトをインスタンス化のために準備する必要はありませんが、ルールの変更では、ルール条件のデータベース・オブジェクト名またはスキーマを変更することはできません。

関連項目:

- 「ソース・データベースでインスタンス化を行うためのデータベース・オブジェクトの準備」

- Oracle Streamsデータ・ディクショナリの詳細は、『Oracle Streams概要および管理』を参照してください。

インスタンス化の準備中のサプリメンタル・ロギング・オプション

レプリケーション環境で、変更の取得に取得プロセスが使用されている場合、サプリメンタル・ロギングが必要になります。サプリメンタル・ロギングでは、操作が実行されるたびにREDOログに列データが追加されます。データベース・オブジェクトをインスタンス化のために準備するためのDBMS_CAPTURE_ADMパッケージには、PREPARE_TABLE_INSTANTIATION、PREPARE_SCHEMA_INSTANTIATIONおよびPREPARE_GLOBAL_INSTANTIATIONが含まれます。これらのプロシージャには、supplemental_loggingパラメータが含まれており、このパラメータを使用すると、インスタンス化のために準備されているデータベース・オブジェクトのサプリメンタル・ロギングの指定を制御できます。

表8-2に、各プロシージャに対するsupplemental_loggingパラメータの値を示します。

表8-2 インスタンス化の準備中のサプリメンタル・ロギング・オプション

プロシージャ

supplemental_loggingパラメータの設定

説明

PREPARE_TABLE_INSTANTIATION

keys

インスタンス化のために準備する表の主キー列、一意キー列、ビットマップ索引列および外部キー列のサプリメンタル・ロギングが有効になります。この場合、ログに記録される表の列が、主キー列が無条件のログ・グループ、一意キー列とビットマップ索引列が条件付きのログ・グループ、外部キー列が条件付きのログ・グループと、3つの異なるログ・グループに配置されます。

PREPARE_TABLE_INSTANTIATION

all

インスタンス化のために準備する表のすべての列のサプリメンタル・ロギングが有効になります。この場合、表のすべての列が無条件のログ・グループに配置されます。

PREPARE_SCHEMA_INSTANTIATION

keys

インスタンス化のために準備するスキーマ内の表、および将来このスキーマに追加するすべての表の主キー列、一意キー列、ビットマップ索引列および外部キー列のサプリメンタル・ロギングが有効になります。主キー列は、無条件でログに記録されます。一意キー列、ビットマップ索引列および外部キー列は、条件付きでログに記録されます。

PREPARE_SCHEMA_INSTANTIATION

all

インスタンス化のために準備するスキーマ内の表、および将来このスキーマに追加するすべての表のすべての列のサプリメンタル・ロギングが有効になります。すべての列は、無条件でログに記録されます。

PREPARE_GLOBAL_INSTANTIATION

keys

インスタンス化のために準備するデータベース内の表、および将来このデータベースに追加するすべての表の主キー列、一意キー列、ビットマップ索引列および外部キー列のサプリメンタル・ロギングが有効になります。主キー列は、無条件でログに記録されます。一意キー列、ビットマップ索引列および外部キー列は、条件付きでログに記録されます。

PREPARE_GLOBAL_INSTANTIATION

all

インスタンス化のために準備するデータベース内のすべての表、および将来このデータベースに追加するすべての表のすべての列のサプリメンタル・ロギングが有効になります。すべての列は、無条件でログに記録されます。

すべてのPREPAREプロシージャ

none

インスタンス化のために準備する表のいずれの列に対してもサプリメンタル・ロギングが有効になりません。

supplemental_loggingパラメータを指定せずにいずれかのPREPAREプロシージャを実行した場合、keysがデフォルトになります。DBMS_STREAMS_ADMパッケージの一部のプロシージャでは、取得プロセスのポジティブ・ルール・セットにルールを追加する際に、表がインスタンス化のために準備されます。この場合、インスタンス化のために準備する表には、デフォルトのサプリメンタル・ロギング・オプションのkeysが指定されます。

注意:

- supplemental_loggingパラメータにallを指定した場合、LOB型、LONG型、LONG RAW型、ユーザー定義型およびOracleが提供する型の列のサプリメンタル・ロギングは有効になりません。

- supplemental_loggingパラメータにkeysを指定した場合、ビットマップ結合索引列のサプリメンタル・ロギングは有効になりません。

- PREPAREプロシージャのsupplemental_loggingパラメータは、Oracle Database 10g リリース2で導入されています。デフォルトでは、これらのプロシージャを実行すると、サプリメンタル・ロギングが有効になります。今回より前のリリースでは、これらのプロシージャを実行しても、サプリメンタル・ロギングは有効になりませんでした。Oracle Streams環境を削除したり、Oracle Streams環境から特定のデータベース・オブジェクトを削除すると、これらのプロシージャによって有効化されたサプリメンタル・ロギングを削除して、不要なロギングを回避できます。

関連項目:

- 「ソース・データベースでインスタンス化を行うためのデータベース・オブジェクトの準備」

- 「サプリメンタル・ロギングの指定」

- 「自動的にオブジェクトを準備するDBMS_STREAMS_ADMパッケージのプロシージャ」

- PREPAREプロシージャによって有効化されたサプリメンタル・ロギングを削除する方法については、「ソース・データベースでのインスタンス化の準備の強制終了」を参照してください。

- データ型の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

ソース・データベースでインスタンス化を行うためのデータベース・オブジェクトの準備

DBMS_STREAMS_ADMパッケージを使用して取得プロセスまたは同期取得のルールを作成すると、システム作成ルールで参照されるオブジェクトがインスタンス化のために自動的に準備されます。DBMS_RULE_ADMパッケージを使用して取得プロセスのルールを作成する場合は、これらのルールで参照されるデータベース・オブジェクトをインスタンス化のために手動で準備する必要があります。この場合、データベース・オブジェクトに対する変更を取得するように取得プロセスを構成した後で、データベース・オブジェクトをインスタンス化のために準備する必要があります。同期取得では、DBMS_RULE_ADMパッケージで作成されたルールは無視されます。

データベース・オブジェクトをインスタンス化のために準備するPL/SQLサブプログラムの詳細は、「取得のルールとインスタンス化の準備」を参照してください。インスタンス化の準備対象となる1つ以上のデータベース・オブジェクトを長時間実行トランザクションで変更中に、前述のプロシージャの1つを実行すると、そのプロシージャは長時間実行トランザクションが完了するまで待機してから、オブジェクトの非処理SCNを記録します。非処理SCNは、その下では宛先データベースでオブジェクトに対する変更を適用できないSCNです。V$STREAMS_TRANSACTION動的パフォーマンス・ビューを問い合せて、取得プロセスまたは適用プロセスによって処理されている長時間実行トランザクションを監視します。

ここでは、インスタンス化のためにデータベース・オブジェクトを準備する例について説明します。

- インスタンス化のための表の準備

- インスタンス化のためのスキーマ内のデータベース・オブジェクトの準備

- インスタンス化のためのデータベース内のすべてのデータベース・オブジェクトの準備

関連項目:
適用プロセスのインスタンス化SCNと非処理SCNの詳細は、『Oracle Streams概要および管理』を参照してください。

インスタンス化のための表の準備

この項の内容は次のとおりです。

- 取得プロセスを使用する場合のDBMS_STREAMS_ADMを使用したインスタンス化のための表の準備

- 取得プロセスを使用する場合のDBMS_CAPTURE_ADMを使用したインスタンス化のための表の準備

- 同期取得を使用する場合のDBMS_STREAMS_ADMを使用したインスタンス化のための表の準備

- 同期取得を使用する場合のDBMS_CAPTURE_ADMを使用したインスタンス化のための表の準備

取得プロセスを使用する場合のDBMS_STREAMS_ADMを使用したインスタンス化のための表の準備

この項の例では、表に対する変更が取得プロセスによって取得される場合に、DBMS_STREAMS_ADMパッケージを使用して、表をインスタンス化のために準備します。hr.regions表をインスタンス化のために準備して、表のすべての主キー列、一意キー列、ビットマップ索引列および外部キー列に対してサプリメンタル・ロギングを有効化するには、DBMS_STREAMS_ADMパッケージのプロシージャを使用して、hr.regions表のルールを取得プロセスのポジティブ・ルール・セットに追加します。取得プロセスがソース・データベースへのデータベース・リンクを持つローカルの取得プロセスまたはダウンストリームの取得プロセスである場合に、このプロシージャを実行すると、この表がインスタンス化のために自動的に準備されます。

次のプロシージャを実行すると、ルールが取得プロセスstrm01_captureのポジティブ・ルール・セットに追加され、hr.regions表がインスタンス化のために準備されます。

BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
table_name     => 'hr.regions',
streams_type   => 'capture',
streams_name   => 'strm01_capture',
queue_name     => 'strmadmin.strm01_queue',
include_dml    => TRUE,
include_ddl    => TRUE,
inclusion_rule => TRUE);
END;
/

関連項目:
「サプリメンタル・ロギングの指定」

取得プロセスを使用する場合のDBMS_CAPTURE_ADMを使用したインスタンス化のための表の準備

この項の例では、表に対する変更が取得プロセスによって取得される場合に、DBMS_CAPTURE_ADMパッケージを使用して、表をインスタンス化のために準備します。hr.regions表をインスタンス化のために準備して、表のすべての主キー列、一意キー列、ビットマップ索引列および外部キー列に対してサプリメンタル・ロギングを有効化するには、次のプロシージャを実行します。

BEGIN
DBMS_CAPTURE_ADM.PREPARE_TABLE_INSTANTIATION(
table_name           => 'hr.regions',
supplemental_logging => 'keys');
END;
/

supplemental_loggingパラメータのデフォルト値はkeysです。そのため、このパラメータが指定されていない場合、インスタンス化のために準備する表のすべての主キー列、一意キー列、ビットマップ索引列および外部キー列に対してサプリメンタル・ロギングが有効になります。

関連項目:
「サプリメンタル・ロギングの指定」

同期取得を使用する場合のDBMS_STREAMS_ADMを使用したインスタンス化のための表の準備

この項の例では、表に対する変更が同期取得によって取得される場合に、DBMS_STREAMS_ADMパッケージを使用して、hrスキーマ内のすべての表をインスタンス化のために準備します。DBMS_STREAMS_ADMパッケージのプロシージャを使用して、hr.jobs_transportおよびhr.regions_transport表のルールを同期取得のポジティブ・ルール・セットに追加します。実行するプロシージャによって、表がインスタンス化のために自動的に準備されます。

次のプロシージャを実行すると、同期取得sync_captureのポジティブ・ルール・セットにルールが追加され、hr.regions表がインスタンス化のために準備されます。

BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
table_name   => 'hr.regions',
streams_type => 'sync_capture',
streams_name => 'sync_capture',
queue_name   => 'strmadmin.streams_queue');
END;
/

同期取得を使用する場合のDBMS_CAPTURE_ADMを使用したインスタンス化のための表の準備

この項の例では、表に対する変更が同期取得によって取得される場合に、DBMS_CAPTURE_ADMパッケージを使用して、hrスキーマ内のすべての表をインスタンス化のために準備します。インスタンス化のためにhrスキーマ内の表を準備するには、次のファンクションを実行します。

SET SERVEROUTPUT ON
DECLARE
tables       DBMS_UTILITY.UNCL_ARRAY;
prepare_scn  NUMBER;
BEGIN
tables(1) := 'hr.departments';
tables(2) := 'hr.employees';
tables(3) := 'hr.countries';
tables(4) := 'hr.regions';
tables(5) := 'hr.locations';
tables(6) := 'hr.jobs';
tables(7) := 'hr.job_history';
prepare_scn := DBMS_CAPTURE_ADM.PREPARE_SYNC_INSTANTIATION(
table_names => tables);
DBMS_OUTPUT.PUT_LINE('Prepare SCN = ' || prepare_scn);
END;
/

インスタンス化のためのスキーマ内のデータベース・オブジェクトの準備

この項の内容は次のとおりです。

- DBMS_STREAMS_ADMを使用した、インスタンス化のためのスキーマ内のデータベース・オブジェクトの準備

- DBMS_CAPTURE_ADMを使用した、インスタンス化のためのスキーマ内のデータベース・オブジェクトの準備

DBMS_STREAMS_ADMを使用した、インスタンス化のためのスキーマ内のデータベース・オブジェクトの準備

この項の例では、スキーマ内のデータベース・オブジェクトに対する変更が取得プロセスによって取得される場合に、DBMS_STREAMS_ADMパッケージを使用して、これらのオブジェクトをインスタンス化のために準備します。

インスタンス化のためにhrスキーマ内のデータベース・オブジェクトを準備し、hrスキーマ内の表のすべての列に対してサプリメンタル・ロギングを有効化するには、次のプロシージャを実行し、DBMS_STREAMS_ADMパッケージのプロシージャを使用して、hrスキーマのルールを取得プロセスのポジティブ・ルール・セットに追加します。取得プロセスがソース・データベースへのデータベース・リンクを持つローカルの取得プロセスまたはダウンストリームの取得プロセスである場合に、このプロシージャを実行すると、hrスキーマ内のオブジェクトがインスタンス化のために自動的に準備されます。

次のプロシージャを実行すると、ルールが取得プロセスstrm01_captureのポジティブ・ルール・セットに追加され、hrスキーマおよびそのすべてのデータベース・オブジェクトがインスタンス化のために準備されます。

BEGIN
DBMS_STREAMS_ADM.ADD_SCHEMA_RULES(
schema_name     =>  'hr',
streams_type    =>  'capture',
streams_name    =>  'strm01_capture',
queue_name      =>  'strm01_queue',
include_dml     =>  TRUE,
include_ddl     =>  TRUE,
inclusion_rule  =>  TRUE);
END;
/

指定した取得プロセスが存在しない場合は、このプロシージャによって作成されます。

また、インスタンス化のために準備する表の主キー列、一意キー列、ビットマップ索引列および外部キー列のサプリメンタル・ロギングが有効になります。

関連項目:
「サプリメンタル・ロギングの指定」

DBMS_CAPTURE_ADMを使用した、インスタンス化のためのスキーマ内のデータベース・オブジェクトの準備

この項の例では、スキーマ内のデータベース・オブジェクトに対する変更が取得プロセスによって取得される場合に、DBMS_CAPTURE_ADMパッケージを使用して、これらのオブジェクトをインスタンス化のために準備します。インスタンス化のためにhrスキーマ内のデータベース・オブジェクトを準備し、hrスキーマ内の表のすべての列に対してサプリメンタル・ロギングを有効化するには、次のプロシージャを実行します。

BEGIN
DBMS_CAPTURE_ADM.PREPARE_SCHEMA_INSTANTIATION(
schema_name          => 'hr',
supplemental_logging => 'all');
END;
/

このプロシージャを実行すると、hrスキーマ内の表のすべての列と、将来hrスキーマに追加される表内のすべての列に対してサプリメンタル・ロギングが有効になります。

関連項目:
「サプリメンタル・ロギングの指定」

インスタンス化のためのデータベース内のすべてのデータベース・オブジェクトの準備

この項の内容は次のとおりです。

- DBMS_STREAMS_ADMを使用した、インスタンス化のためのデータベース内のすべてのデータベース・オブジェクトの準備

- DBMS_CAPTURE_ADMを使用した、インスタンス化のためのデータベース内のすべてのデータベース・オブジェクトの準備

DBMS_STREAMS_ADMを使用した、インスタンス化のためのデータベース内のすべてのデータベース・オブジェクトの準備

この項の例では、データベース内のデータベース・オブジェクトに対する変更が取得プロセスによって取得される場合に、DBMS_STREAMS_ADMパッケージを使用して、これらのオブジェクトをインスタンス化のために準備します。データベース内のすべてのデータベース・オブジェクトをインスタンス化のために準備するには、DBMS_STREAMS_ADMパッケージのADD_GLOBAL_RULESプロシージャを実行します。

BEGIN
DBMS_STREAMS_ADM.ADD_GLOBAL_RULES(
streams_type   => 'capture',
streams_name   => 'capture_db',
queue_name     => 'strmadmin.streams_queue',
include_dml    => TRUE,
include_ddl    => TRUE,
inclusion_rule => TRUE);
END;
/

指定した取得プロセスが存在しない場合は、このプロシージャによって作成されます。

また、インスタンス化のために準備する表の主キー列、一意キー列、ビットマップ索引列および外部キー列のサプリメンタル・ロギングが有効になります。

関連項目:
「サプリメンタル・ロギングの指定」

DBMS_CAPTURE_ADMを使用した、インスタンス化のためのデータベース内のすべてのデータベース・オブジェクトの準備

この項の例では、データベース内のデータベース・オブジェクトに対する変更が取得プロセスによって取得される場合に、DBMS_CAPTURE_ADMパッケージを使用して、これらのオブジェクトをインスタンス化のために準備します。インスタンス化のためにデータベース内のデータベース・オブジェクトを準備するには、次のプロシージャを実行します。

BEGIN
DBMS_CAPTURE_ADM.PREPARE_GLOBAL_INSTANTIATION(
supplemental_logging => 'none');
END;
/

supplemental_loggingパラメータにnoneが指定されているため、このプロシージャではどの列に対してもサプリメンタル・ロギングが有効になりません。ただし、ALTER TABLEまたはALTER DATABASE文を使用して、サプリメンタル・ロギングを手動で指定できます。

関連項目:
「サプリメンタル・ロギングの指定」

ソース・データベースでのインスタンス化の準備の強制終了

DBMS_CAPTURE_ADMパッケージの次のプロシージャでは、インスタンス化の準備が強制終了されます。

- ABORT_TABLE_INSTANTIATIONを実行すると、PREPARE_TABLE_INSTANTIATIONの効果が逆転し、PREPARE_TABLE_INSTANTIATIONプロシージャによって有効化されたサプリメンタル・ロギングが削除されます。

- ABORT_SYNC_INSTANTIATIONを実行すると、PREPARE_SYNC_INSTANTIATIONの効果が逆転します。

- ABORT_SCHEMA_INSTANTIATIONを実行すると、PREPARE_SCHEMA_INSTANTIATIONの効果が逆転し、PREPARE_SCHEMA_INSTANTIATIONおよびPREPARE_TABLE_INSTANTIATIONプロシージャによって有効化されたサプリメンタル・ロギングが削除されます。

- ABORT_GLOBAL_INSTANTIATIONを実行すると、PREPARE_GLOBAL_INSTANTIATIONの効果が逆転し、PREPARE_GLOBAL_INSTANTIATION、PREPARE_SCHEMA_INSTANTIATIONおよびPREPARE_TABLE_INSTANTIATIONプロシージャによって有効化されたサプリメンタル・ロギングが削除されます。

これらのプロシージャでは、関連データベース・オブジェクトの潜在的なインスタンス化に関係するデータ・ディクショナリ情報が削除されます。

たとえば、hr.regions表のインスタンス化の準備を強制終了するには、次のプロシージャを実行します。

BEGIN
DBMS_CAPTURE_ADM.ABORT_TABLE_INSTANTIATION(
table_name  => 'hr.regions');
END;
/

Oracle Data PumpとOracle Streamsのインスタンス化

ここでは、Oracle Data Pumpを使用したOracle Streamsのインスタンス化の実行について説明します。

- データ・ポンプ・エクスポートとオブジェクトの一貫性

- Oracle Data Pump ImportとOracle Streamsのインスタンス化

- データ・ポンプ・エクスポート/インポートを使用したオブジェクトのインスタンス化

関連項目:

- Oracle Streamsを使用してデータベース上で全データベースのエクスポート/インポートを実行する方法の詳細は、『Oracle Streams概要および管理』を参照してください。

- データ・ポンプの詳細は、『Oracle Databaseユーティリティ』を参照してください。

データ・ポンプ・エクスポートとオブジェクトの一貫性

エクスポート中、Oracle Data Pumpでは、データベース・オブジェクトごとにエクスポートされたデータおよび手続き型操作が特定の時点で一貫性を持つように、自動的にOracle Flashbackが使用されます。Oracle Streams環境でインスタンス化を実行する場合は、ある程度の一貫性が必要です。データ・ポンプ・エクスポート・ユーティリティを使用すると、Oracle Streamsのインスタンス化についてこの一貫性を確保できます。

Oracle Streamsのインスタンス化のみでなく、他の用途にもエクスポート・ダンプ・ファイルを使用しており、その用途がデータ・ポンプのデフォルトのエクスポートで得られる一貫性より厳密な一貫性要件を伴う場合は、Oracle Streamsのインスタンス化にデータ・ポンプ・エクスポート・ユーティリティ・パラメータFLASHBACK_SCNまたはFLASHBACK_TIMEを使用できます。たとえば、エクスポートに外部キー制約を持つオブジェクトが含まれている場合、より厳密な一貫性が要求される場合があります。

Oracle Data Pump ImportとOracle Streamsのインスタンス化

ここでは、Oracle Data Pump ImportとOracle Streamsのインスタンス化について説明します。

- インスタンス化SCNとデータ・ポンプ・インポート

- インスタンス化SCNとデータ・ポンプ・インポートによるOracle Streamsタグ

- STREAMS_CONFIGURATIONデータ・ポンプ・インポート・ユーティリティ・パラメータ

インスタンス化SCNとデータ・ポンプ・インポート

データ・ポンプ・インポート中、インスタンス化SCNは、データ・ポンプ・エクスポートが実行される前にエクスポート・データベースでインスタンス化が準備されたデータベース・オブジェクトごとに、インポート・データベースで設定されます。インスタンス化SCNは、データ・ポンプ・エクスポート中に取得されるメタデータに基づいて設定されます。

関連項目:
『Oracle Streams概要および管理』

インスタンス化SCNとデータ・ポンプ・インポートによるOracle Streamsタグ

データ・ポンプ・インポート・セッションでは、インポートによって発生する変更の循環を回避するために、Oracle Streamsタグが'00'と等価の16進値に設定される場合があります。このようなインポートによって生成されるREDOエントリに、このタグ値が含まれます。

インポート・セッション・タグが'00'と等価の16進値に設定されるかどうかは、インポートされるエクスポートによって決まります。具体的には、次のいずれかの場合にインポート・セッション・タグが'00'と等価の16進値に設定されます。

- データ・ポンプ・エクスポートがFULLまたはSCHEMAモードである。

- データ・ポンプ・エクスポートがTABLEまたはTABLESPACEモードであり、エクスポートの実行前に、エクスポートに含まれる1つ以上の表がエクスポート・データベースでインスタンス化のために準備されている。

インポートされるデータ・ポンプ・エクスポートで、前述の条件のどちらも該当しない場合は、インポート・セッション・タグはNULLです。

注意:

- データ・ポンプを使用してネットワーク・インポートを実行する場合、インポートと同じモードで暗黙的エクスポートが実行されます。たとえば、ネットワーク・インポートがスキーマ・モードの場合は、暗黙的エクスポートもスキーマ・モードで行われます。

- データ・ポンプ・インポートがTRANSPORTABLE TABLESPACEモードで実行される場合、インポート・セッション・タグは設定されません。このモードで実行されるインポートでは、インポートされるデータのREDOデータを生成しません。そのため、セッション・タグの設定は不要です。

関連項目:
第10章「Oracle Streamsタグ」

STREAMS_CONFIGURATIONデータ・ポンプ・インポート・ユーティリティ・パラメータ

STREAMS_CONFIGURATIONデータ・ポンプ・インポート・ユーティリティ・パラメータでは、エクスポート・ダンプ・ファイルに表示される一般的なOracle Streamsメタデータをインポートするかどうかを指定します。このインポート・パラメータは、全データベースのインポートを実行する場合にのみ関連します。デフォルトでは、STREAMS_CONFIGURATIONインポート・ユーティリティ・パラメータはyに設定されます。通常、インポートがバックアップまたはリストア操作の一部である場合は、yを指定します。

エクスポート・ダンプ・ファイルに情報が表示される場合、次のオブジェクトは、STREAMS_CONFIGURATIONの設定に関係なくインポートされます。

- ANYDATAキューおよびキュー表。

- キュー・サブスクライバ。

- アドバンスト・キューイング・エージェント。

- ポジティブ・ルール・セット、ネガティブ・ルール・セットおよび評価コンテキストを含めたルール。Oracle StreamsルールおよびOracle Streams以外のルールを含め、すべてのルールがインポートされます。Oracle Streamsルールとは、DBMS_STREAMS_ADMパッケージの特定のプロシージャが実行されるときにシステムによって生成されるルールで、Oracle Streams以外のルールとは、DBMS_RULE_ADMパッケージを使用して作成されるルールです。
STREAMS_CONFIGURATIONパラメータの設定がnの場合、Oracle Streamsルールに関する情報は、データ・ディクショナリ・ビューALL_STREAMS_RULES、ALL_STREAMS_GLOBAL_RULES、ALL_STREAMS_SCHEMA_RULES、ALL_STREAMS_TABLE_RULES、DBA_STREAMS_RULES、DBA_STREAMS_GLOBAL_RULES、DBA_STREAMS_SCHEMA_RULESおよびDBA_STREAMS_TABLE_RULESにはインポートされません。ただし、これらのルールに関する情報は、STREAMS_CONFIGURATIONパラメータの設定に関係なく、データ・ディクショナリ・ビューALL_RULES、ALL_RULE_SETS、ALL_RULE_SET_RULES、DBA_RULES、DBA_RULE_SETS、DBA_RULE_SET_RULES、USER_RULES、USER_RULE_SETSおよびUSER_RULE_SET_RULESにインポートされます。

STREAMS_CONFIGURATIONインポート・ユーティリティ・パラメータの設定がyで、次の情報がエクスポート・ダンプ・ファイルに表示されている場合、この情報はインポートに含まれます。STREAMS_CONFIGURATIONインポート・ユーティリティ・パラメータの設定がnの場合は、次の情報はインポートに含まれません。

- ローカルの変更を取得する取得プロセス。各取得プロセスには次の情報が含まれます。

- 取得プロセスの名前。

- 取得プロセスの状態。

- 取得プロセスのパラメータの設定。

- 取得プロセスで使用されるキューのキュー所有者およびキュー名。

- 取得プロセスで使用されるポジティブ・ルール・セットとネガティブ・ルール・セット、それぞれのルール・セット所有者およびルール・セット名。

- 取得プロセスの取得ユーザー。

- 取得プロセスの状態の最終変更時間。この情報は、DBA_CAPTUREデータ・ディクショナリ・ビューに記録されます。

- 原因となったエラーのエラー番号とメッセージ(取得プロセスが無効化されるか異常終了した場合)。この情報は、DBA_CAPTUREデータ・ディクショナリ・ビューに記録されます。

- 同期取得。各同期取得には次の情報が含まれます。

- 同期取得の名前。

- 同期取得で使用されるキューのキュー所有者およびキュー名。

- 同期取得で使用されるそれぞれのルール・セットのルール・セット所有者およびルール・セット名。

- 同期取得の取得ユーザー。

- 表がエクスポート・データベースでインスタンス化の準備を完了している場合、これらの表がインポート・データベースでインスタンス化用に準備されます。

- スキーマがエクスポート・データベースでインスタンス化の準備を完了している場合、これらのスキーマがインポート・データベースでインスタンス化用に準備されます。

- エクスポート・データベースがインスタンス化の準備を完了している場合、インポート・データベースがインスタンス化用に準備されます。

- Oracle Streamsクライアントが使用する各ANYDATAキューの状態(開始または停止)。Oracle Streamsクライアントには、取得プロセス、同期取得、伝播、適用プロセスおよびメッセージ・クライアントが含まれます。ANYDATAキュー自体は、STREAMS_CONFIGURATIONインポート・ユーティリティ・パラメータの設定に関係なくインポートされます。

- 伝播。各伝播には次の情報が含まれます。

- 伝播の名前。

- ソース・キューのキュー所有者およびキュー名。

- 宛先キューのキュー所有者およびキュー名。

- 宛先データベース・リンク。

- 伝播で使用されるポジティブ・ルール・セットとネガティブ・ルール・セット、それぞれのルール・セット所有者およびルール・セット名。

- Oracle Streamsの伝播に関連するOracle Schedulerジョブ。

- 適用プロセス。各適用プロセスには次の情報が含まれます。

- 適用プロセスの名前。

- 適用プロセスの状態。

- 適用プロセスのパラメータの設定。

- 適用プロセスで使用されるキューのキュー所有者およびキュー名。

- 適用プロセスで使用されるルール・セットのポジティブおよびネガティブ・ルール・セット所有者およびルール・セット名。

- 適用プロセスによって、取得LCRがバッファ・キューに適用されるか、メッセージが永続キューに適用されるか。

- 適用プロセスの適用ユーザー。

- 存在する場合は、適用プロセスで使用されるメッセージ・ハンドラ。

- 存在する場合は、適用プロセスで使用されるDDLハンドラ。

- 存在する場合は、適用プロセスで使用されるプリコミット・ハンドラ。

- 適用プロセスによって行われた変更用にREDOログ内で生成されたタグ値。

- 存在する場合は、適用データベース・リンク。

- 適用プロセスのソース・データベース。

- 適用されたメッセージ番号、最も古いメッセージ番号(最も古いSCN)、適用時間および適用されたメッセージの作成時間を含む、DBA_APPLY_PROGRESSデータ・ディクショナリ・ビュー内の適用の進捗に関する情報。

- 適用エラー。

- 適用プロセスの状態の最終変更時間。この情報は、DBA_APPLYデータ・ディクショナリ・ビューに記録されます。

- 原因となったエラーのエラー番号とメッセージ(適用プロセスが無効化されるか異常終了した場合)。この情報は、DBA_APPLYデータ・ディクショナリ・ビューに記録されます。

- DMLハンドラ(文DMLハンドラとプロシージャDMLハンドラの両方を含む)。

- エラー・ハンドラ。

- 更新の競合ハンドラ。

- 適用表の代替キー列。

- 各適用オブジェクトのインスタンス化SCN。

- 各適用オブジェクトの非処理SCN。

- メッセージ・クライアント。各メッセージ・クライアントには次の情報が含まれます。

- メッセージ・クライアントの名前。

- メッセージ・クライアントで使用されるキューのキュー所有者およびキュー名。

- メッセージ・クライアントで使用されるルール・セットのポジティブ・ルール・セットおよびネガティブ・ルール・セット所有者およびルール・セット名。

- メッセージ通知設定。

- Oracle Streamsルールに関する一部のデータ・ディクショナリ情報。ルール自体は、STREAMS_CONFIGURATIONパラメータの設定に関係なくインポートされます。

- Oracle Streams管理者、メッセージ・クライアント、メッセージ・ルール、取得プロセスまたは同期取得で取得される論理変更レコード(LCR)に含まれる追加の属性、およびメッセージ・ルールで使用される追加の属性に関するデータ・ディクショナリ情報。

注意:
ダウンストリームの取得プロセスは、STREAMS_CONFIGURATION設定に関係なくインポートに含まれません。

データ・ポンプ・エクスポート/インポートを使用したオブジェクトのインスタンス化

この項の例では、Oracle Data Pump Export/Importを使用してOracle Streams環境でオブジェクトをインスタンス化する場合に必要な手順について説明します。この例では、次のことを想定しています。

- ソース・データベースでhrスキーマ内のすべてのデータベース・オブジェクトに対する変更を取得して、別の宛先データベースでそれらの変更を適用します。

- hrスキーマはソース・データベースに存在しますが、宛先データベースには存在しません。この例のために、宛先データベースのhrユーザーを削除するには、次のSQL文を使用します。

DROP USER hr CASCADE;

データ・ポンプ・インポートを実行すると、宛先データベースにユーザーおよびユーザーのデータベース・オブジェクトが再作成されます。

- ソース・データベースおよび宛先データベースでOracle Streams管理者strmadminを構成済です。各データベースで、Oracle Streams管理者にはDBAロールが付与されます。

注意:
この項の例では、データ・ポンプ・ユーティリティのコマンドラインを使用します。Oracle Streamsのインスタンス化にはDBMS_DATAPUMPパッケージも使用できます。

関連項目:

- 「すべてのデータベースでのOracle Streams管理者の構成」

- データ・ポンプの詳細は、『Oracle Databaseユーティリティ』を参照してください。

- Oracle Streamsのインスタンス化にDBMS_DATAPUMPパッケージを使用する場合の例は、『Oracle Streams拡張例』を参照してください。

前述の想定で、データ・ポンプ・エクスポート/インポートを使用してhrスキーマをインスタンス化するには、次の手順を実行します。

1. SQL*Plusで、Oracle Streams管理者としてソース・データベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

2. エクスポート・ダンプ・ファイルおよびエクスポート・ログ・ファイルを保持するディレクトリ・オブジェクトを作成します。

CREATE DIRECTORY DPUMP_DIR AS '/usr/dpump_dir';

3. hrスキーマ内のデータベース・オブジェクトをインスタンス化のために準備します。「インスタンス化のためのスキーマ内のデータベース・オブジェクトの準備」を参照してください。

4. ソース・データベースにOracle Streams管理者として接続したまま、ソース・データベースの現行のシステム変更番号(SCN)を判断します。

SELECT DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER FROM DUAL;

この問合せで戻されるSCN値を、手順5でFLASHBACK_SCNデータ・ポンプ・エクスポート・パラメータに指定します。hrスキーマには表間の外部キー制約が含まれるため、FLASHBACK_SCNエクスポート・パラメータ、または類似のエクスポート・パラメータは、エクスポート中に指定する必要があります。この例では、問合せによって876606が戻されたと想定します。

この問合せの実行後、エクスポートが完了するまでは、エクスポート対象のオブジェクトに対してDDL変更が行われないように注意してください。

5. コマンドラインでデータ・ポンプを使用して、ソース・データベースでhrスキーマをエクスポートします。

エクスポートを実行するには、EXP_FULL_DATABASEロールが付与された管理ユーザーとして接続します。このユーザーには、手順2で作成したディレクトリ・オブジェクトに対するREAD権限およびWRITE権限も必要です。この例では、Oracle Streams管理者strmadminとして接続します。

次にデータ・ポンプ・エクスポート・コマンドの例を示します。

expdp strmadmin SCHEMAS=hr DIRECTORY=DPUMP_DIR DUMPFILE=hr_schema_dp.dmp
FLASHBACK_SCN=876606

関連項目:
データ・ポンプ・エクスポートを実行する方法の詳細は、『Oracle Databaseユーティリティ』を参照してください。

6. SQL*Plusで、Oracle Streams管理者として宛先データベースに接続します。

7. インポート・ダンプ・ファイルおよびインポート・ログ・ファイルを保持するディレクトリ・オブジェクトを作成します。

CREATE DIRECTORY DPUMP_DIR AS '/usr/dpump_dir';

8. データ・ポンプ・エクスポート・ダンプ・ファイルhr_schema_dp.dmpを宛先データベースに送信します。DBMS_FILE_TRANSFERパッケージ、バイナリFTPまたは他のなんらかの方法を使用して、ファイルを宛先データベースに送信できます。ファイル送信後、エクスポート・ダンプ・ファイルは、手順7で作成したディレクトリ・オブジェクトに対応するディレクトリに存在することになります。

9. 宛先データベースのコマンドラインでデータ・ポンプを使用して、エクスポート・ダンプ・ファイルhr_schema_dp.dmpをインポートします。インポートが完了するまでは、宛先データベースでインポート対象のスキーマ内の表に対する変更が行われないように注意してください。インポートを実行すると、宛先データベースで、hrスキーマおよびそのすべてのデータベース・オブジェクトにインスタンス化SCNが自動的に設定されます。

インポートを実行するには、IMP_FULL_DATABASEロールが付与された管理ユーザーとして接続します。このユーザーには、手順7で作成したディレクトリ・オブジェクトに対するREAD権限およびWRITE権限も必要です。この例では、Oracle Streams管理者strmadminとして接続します。

次にインポート・コマンドの例を示します。

impdp strmadmin SCHEMAS=hr DIRECTORY=DPUMP_DIR DUMPFILE=hr_schema_dp.dmp

注意:
エクスポート・データベースからエクスポートされた表の表サプリメンタル・ログ・グループは、インポート・データベースで表がインポートされる際に保持されます。これらのサプリメンタル・ログ・グループは、必要に応じて削除できます。

関連項目:
データ・ポンプ・インポートを実行する方法の詳細は、『Oracle Databaseユーティリティ』を参照してください。

Recovery Manager(RMAN)とOracle Streamsのインスタンス化

RMANのTRANSPORT TABLESPACEコマンドを使用すると、表領域をインスタンス化でき、RMANのDUPLICATEおよびCONVERT DATABASEコマンドを使用すると、データベース全体をインスタンス化できます。通常、RMANを使用する方が、他の方法より高速にインスタンス化を実行できます。

ここでは、RMANのコマンドを使用したインスタンス化について説明します。

- トランスポータブル表領域またはRMANを使用した表領域内のオブジェクトのインスタンス化

- RMANを使用したデータベース全体のインスタンス化

トランスポータブル表領域またはRMANを使用した表領域内のオブジェクトのインスタンス化

RMANのTRANSPORT TABLESPACEコマンドを実行すると、データ・ポンプおよびRMANで管理される補助インスタンスを使用して、ソース・データベースの表領域または表領域セットがオンライン状態のままで、表領域または表領域セットのデータベース・オブジェクトがエクスポートされます。補助インスタンスは、RMANによって自動的にシステム生成名で起動されます。RMANのTRANSPORT TABLESPACEコマンドを実行すると、表領域または表領域セットのデータ・ポンプ・エクスポート・ダンプ・ファイルおよびデータ・ファイルが生成されます。

データ・ポンプを使用して、宛先データベースでダンプ・ファイルをインポートするか、DBMS_STREAMS_TABLESPACE_ADMパッケージのATTACH_TABLESPACESプロシージャを使用して、表領域を宛先データベースにアタッチできます。また、表領域がインポートまたはアタッチされると、表領域のデータベース・オブジェクトのインスタンス化SCNの値が宛先データベースで自動的に設定されます。

注意:
RMANのTRANSPORT TABLESPACEコマンドでは、ユーザー管理の補助インスタンスはサポートされていません。

この項の例では、トランスポータブル表領域またはRMANを使用して表領域内のデータベース・オブジェクトをインスタンス化する場合に必要な手順について説明します。通常、これらのインスタンス化オプションを使用する方が、エクスポート/インポートを使用するより高速にインスタンス化を実行できます。次の例では、表領域内のデータベース・オブジェクトをインスタンス化します。

- 「トランスポータブル表領域を使用したオブジェクトのインスタンス化」では、トランスポータブル表領域機能を使用してインスタンス化を完了します。データ・ポンプを使用すると、ソース・データベースで表領域がエクスポートされ、宛先データベースでその表領域がインポートされます。エクスポート中、表領域は読取り専用になります。

- 「バックアップからのトランスポータブル表領域とRMANを使用したオブジェクトのインスタンス化」では、RMANのTRANSPORT TABLESPACEコマンドを使用して、表領域または表領域セットをオンライン状態にしたままで、表領域または表領域セットのデータ・ポンプ・エクスポート・ダンプ・ファイルおよびデータ・ファイルを生成します。データ・ポンプ・インポートまたはDBMS_STREAMS_TABLESPACE_ADMパッケージのATTACH_TABLESPACESプロシージャのいずれかを使用して、宛先データベースに表領域または表領域セットを追加できます。

これらの例では、表領域jobs_tbsおよびregions_tbsを含む表領域セットをインスタンス化します。これらの例を実行するには、SQL*Plusでソース・データベースに管理ユーザーとして接続し、新規の表領域を作成します。

CREATE TABLESPACE jobs_tbs DATAFILE '/usr/oracle/dbs/jobs_tbs.dbf' SIZE 5 M;

CREATE TABLESPACE regions_tbs DATAFILE '/usr/oracle/dbs/regions_tbs.dbf' SIZE 5 M;

jobs_tbs表領域に、新規の表hr.jobs_transportを含めます。

CREATE TABLE hr.jobs_transport TABLESPACE jobs_tbs AS
SELECT * FROM hr.jobs;

regions_tbs表領域に、新規の表hr.regions_transportを含めます。

CREATE TABLE hr.regions_transport TABLESPACE regions_tbs AS
SELECT * FROM hr.regions;

これらの例では、いずれも次のことを想定しています。

- ソース・データベースでhr.jobs_transport表およびhr.regions_transport表に対するすべての変更を取得して、別の宛先データベースでそれらの変更を適用します。

- hr.jobs_transport表はソース・データベースに存在し、単一の自己完結型の表領域jobs_tbsに含まれます。jobs_tbs表領域は、単一のデータ・ファイルjobs_tbs.dbfに格納されます。

- hr.regions_transport表はソース・データベースに存在し、単一の自己完結型の表領域regions_tbsに含まれます。regions_tbs表領域は、単一のデータ・ファイルregions_tbs.dbfに格納されます。

- jobs_tbs表領域およびregions_tbs表領域には、他のスキーマからのデータは含まれません。

- hr.jobs_transport表、hr.regions_transport表、jobs_tbs表領域およびregions_tbs表領域は、宛先データベースには存在しません。

- ソース・データベースおよび宛先データベースの両方でOracle Streams管理者strmadminを構成済です。また、両方のデータベースでこのOracle Streams管理者にDBAロールを付与済です。

関連項目:

- 「インスタンス化の後の一貫性の確認」

- 「すべてのデータベースでのOracle Streams管理者の構成」

- SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

トランスポータブル表領域を使用したオブジェクトのインスタンス化

この例では、トランスポータブル表領域を使用して、表領域セット内のデータベース・オブジェクトをインスタンス化します。「トランスポータブル表領域またはRMANを使用した表領域内のオブジェクトのインスタンス化」に示した想定事項に加えて、この例では、次のことを想定しています。

- ソース・データベースのOracle Streams管理者には、トランスポータブル表領域のエクスポートを実行するためのEXP_FULL_DATABASEロールが付与されています。DBAロールにはEXP_FULL_DATABASEロールが含まれているため、このロールは十分です。この例では、Oracle Streams管理者はトランスポータブル表領域のエクスポートを実行します。

- 宛先データベースのOracle Streams管理者には、トランスポータブル表領域のインポートを実行するためのIMP_FULL_DATABASEロールが付与されています。DBAロールにはIMP_FULL_DATABASEロールが含まれているため、このロールは十分です。この例では、Oracle Streams管理者はトランスポータブル表領域のエクスポートを実行します。

関連項目:
トランスポータブル表領域を使用する方法、および適用される可能性のある制限については、『Oracle Database管理者ガイド』を参照してください。

次の手順を実行して、トランスポータブル表領域を使用してjobs_tbsおよびregions_tbs表領域内のデータベース・オブジェクトをインスタンス化します。

1. SQL*Plusで、Oracle Streams管理者としてソース・データベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

2. エクスポート・ダンプ・ファイルおよびエクスポート・ログ・ファイルを保持するディレクトリ・オブジェクトを作成します。

CREATE DIRECTORY TRANS_DIR AS '/usr/trans_dir';

3. インスタンス化のためにhr.jobs_transport表およびhr.regions_transport表を準備します。手順については、「インスタンス化のための表の準備」を参照してください。

4. インスタンス化するオブジェクトを含む表領域を読取り専用にします。この例では、jobs_tbs表領域およびregions_tbs表領域にデータベース・オブジェクトが含まれています。

ALTER TABLESPACE jobs_tbs READ ONLY;

ALTER TABLESPACE regions_tbs READ ONLY;

5. コマンドラインでデータ・ポンプ・エクスポート・ユーティリティを使用し、トランスポータブル表領域のエクスポート・パラメータにソース・データベースのjobs_tbsおよびregions_tbs表領域を指定して、この表領域をエクスポートします。次に、トランスポータブル表領域のエクスポート・パラメータを使用するエクスポート・コマンドの例を示します。

expdp strmadmin TRANSPORT_TABLESPACES=jobs_tbs, regions_tbs
DIRECTORY=TRANS_DIR DUMPFILE=tbs_ts.dmp

エクスポート・コマンドを実行する際は、EXP_FULL_DATABASEロールが付与され、ディレクトリ・オブジェクトに対するREAD権限およびWRITE権限を持つ管理ユーザーとして接続していることを確認してください。

関連項目:
エクスポートを実行する方法の詳細は、『Oracle Databaseユーティリティ』を参照してください。

6. SQL*Plusで、Oracle Streams管理者として宛先データベースに接続します。

7. インポート・ダンプ・ファイルおよびインポート・ログ・ファイルを保持するディレクトリ・オブジェクトを作成します。

CREATE DIRECTORY TRANS_DIR AS '/usr/trans_dir';

8. 表領域のデータ・ファイルとエクスポート・ダンプ・ファイルtbs_ts.dmpを宛先データベースに送信します。DBMS_FILE_TRANSFERパッケージ、バイナリFTPまたは他のなんらかの方法を使用して、ファイルを宛先データベースに送信できます。ファイル送信後、エクスポート・ダンプ・ファイルは、手順7で作成したディレクトリ・オブジェクトに対応するディレクトリに存在することになります。

9. 宛先データベースのコマンドラインでデータ・ポンプ・インポート・ユーティリティを使用し、トランスポータブル表領域のインポート・パラメータにエクスポート・ダンプ・ファイルtbs_ts.dmpを使用して、このエクスポート・ダンプ・ファイルをインポートします。インポートを実行すると、宛先データベースで、hr.jobs_transport表およびhr.regions_transport表にインスタンス化SCNが自動的に設定されます。
次にインポート・コマンドの例を示します。

impdp strmadmin DIRECTORY=TRANS_DIR DUMPFILE=tbs_ts.dmp
TRANSPORT_DATAFILES=/usr/orc/dbs/jobs_tbs.dbf,/usr/orc/dbs/regions_tbs.dbf

インポート・コマンドを実行する際は、IMP_FULL_DATABASEロールが付与され、ディレクトリ・オブジェクトに対するREAD権限およびWRITE権限を持つ管理ユーザーとして接続していることを確認してください。

関連項目:
インポートを実行する方法の詳細は、『Oracle Databaseユーティリティ』を参照してください。

10. 必要に応じて、ソース・データベースと宛先データベースの両方にOracle Streams管理者として接続し、表領域を読取り/書込みモードに設定します。

ALTER TABLESPACE jobs_tbs READ WRITE;

ALTER TABLESPACE regions_tbs READ WRITE;

注意:
エクスポート・データベースからエクスポートされた表の表サプリメンタル・ログ・グループは、インポート・データベースで表がインポートされる際に保持されます。これらのサプリメンタル・ログ・グループは、必要に応じて削除できます。

関連項目:
「インスタンス化の後の一貫性の確認」

バックアップからのトランスポータブル表領域とRMANを使用したオブジェクトのインスタンス化

RMANのTRANSPORT TABLESPACEコマンドを実行すると、データ・ポンプおよびRMANで管理される補助インスタンスを使用して、ソース・データベースの表領域または表領域セットがオンライン状態のままで、表領域または表領域セットのデータベース・オブジェクトがエクスポートされます。RMANのTRANSPORT TABLESPACEコマンドを使用すると、データ・ポンプ・エクスポート・ダンプ・ファイルおよびデータ・ファイルが生成され、これらのファイルは、宛先データベースでの表領域のデータ・ポンプ・インポートの実行に使用できます。DBMS_STREAMS_TABLESPACE_ADMパッケージのATTACH_TABLESPACESプロシージャを使用して、宛先データベースで表領域をアタッチすることもできます。

「トランスポータブル表領域またはRMANを使用した表領域内のオブジェクトのインスタンス化」に示した想定事項に加えて、この例では、次のことを想定しています。

- ソース・データベースはtts1.example.comです。

- 宛先データベースはtts2.example.comです。

関連項目:
RMANのTRANSPORT TABLESPACEコマンドを使用する手順については、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

次の手順を実行して、トランスポータブル表領域およびRMANを使用してjobs_tbsおよびregions_tbs表領域内のデータベース・オブジェクトをインスタンス化します。

1. インスタンス化する表領域を含むソース・データベースのバックアップを作成します(存在しない場合)。RMANには、表領域のクローニング用に有効なバックアップが必要です。この例では、jobs_tbs表領域およびregions_tbs表領域を含むソース・データベースのバックアップを作成します(存在しない場合)。

2. SQL*Plusで、Oracle Streams管理者としてソース・データベースtts1.example.comに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

3. オプションで、エクスポート・ダンプ・ファイルおよびエクスポート・ログ・ファイルを保持するディレクトリ・オブジェクトを作成します。

CREATE DIRECTORY SOURCE_DIR AS '/usr/db_files';

この手順はオプションです。これは、手順9でDATAPUMP DIRECTORYパラメータを省略してRMANのTRANSPORT TABLESPACEコマンドを実行した場合に、補助インスタンスにディレクトリ・オブジェクトSTREAMS_DIROBJ_DPDIRが作成されるためです。

4. インスタンス化のためにhr.jobs_transport表およびhr.regions_transport表を準備します。手順については、「インスタンス化のための表の準備」を参照してください。

5. RMANのTRANSPORT TABLESPACEコマンドに指定する終了SCNを判断します。

SET SERVEROUTPUT ON SIZE 1000000
DECLARE
until_scn NUMBER;
BEGIN
until_scn:= DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER;
DBMS_OUTPUT.PUT_LINE('Until SCN: ' || until_scn);
END;
/

戻された終了SCNをメモします。この番号は手順9で使用します。この例では、戻された終了SCNが7661956であると想定します。

オプションで、この手順をスキップできます。この場合、手順9でRMANのTRANSPORT TABLESPACEコマンドにUNTIL句を指定しないでください。UNTIL句が指定されない場合、RMANは最後のアーカイブREDOログ・ファイルを使用して終了SCNを自動的に判別します。

6. SQL*Plusで、管理ユーザーとしてソース・データベースtts1.netに接続します。

7. 現行のオンラインREDOログをアーカイブします。

ALTER SYSTEM ARCHIVE LOG CURRENT;

8. RMANクライアントを起動し、TARGETとしてソース・データベースtts1.example.comに接続します。
RMANのCONNECTコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

9. ソース・データベースtts1.example.comで、RMANのTRANSPORT TABLESPACEコマンドを使用して表領域セットのダンプ・ファイルを生成します。

RMAN> RUN
{
TRANSPORT TABLESPACE 'jobs_tbs', 'regions_tbs'
UNTIL SCN 7661956
AUXILIARY DESTINATION '/usr/aux_files'
DATAPUMP DIRECTORY SOURCE_DIR
DUMP FILE 'jobs_regions_tbs.dmp'
EXPORT LOG 'jobs_regions_tbs.log'
IMPORT SCRIPT 'jobs_regions_tbs_imp.sql'
TABLESPACE DESTINATION '/orc/dbs';
}

TRANSPORT TABLESPACEコマンドを実行すると、ソース・データベースが実行されているコンピュータ・システム上の次のディレクトリに、このファイルが格納されます。

- SOURCE_DIRディレクトリ・オブジェクト(/usr/db_files)に対応するディレクトリには、エクスポート・ダンプ・ファイルおよびエクスポート・ログ・ファイルが含まれます。

- /orc/dbsディレクトリには、生成された表領域のデータ・ファイルおよびインポート・スクリプトが含まれます。このスクリプトを使用し、宛先データベースに表領域をアタッチしてインスタンス化を完了します。

10. 必要に応じて、インポート・スクリプトを変更します。スクリプト内の次のいずれかまたは両方の項目の変更が必要になる場合があります。

- エクスポートした表領域を宛先データベースに含めるために使用する方法を変更することもできます。インポート・スクリプトには、エクスポートした表領域を宛先データベースに含めるために、データ・ポンプ・インポート・コマンド(impdp)と、DBMS_STREAMS_TABLESPACE_ADMパッケージのATTACH_TABLESPACESプロシージャを使用して表領域をアタッチするスクリプトという2つの方法があります。
デフォルトでは、スクリプトでは表領域をアタッチする方法が使用されます。データ・ポンプ・インポート・コマンドはコメント・アウトされます。データ・ポンプ・インポートを使用するには、impdpコマンドを囲むコメント記号(/*および*/)を削除し、表領域をアタッチするスクリプトをコメント記号で囲むか、またはそのスクリプトを削除します。表領域をアタッチするスクリプトはSET SERVEROUTPUT ONで始まり、ファイルの最後まで続きます。

- スクリプトに指定されているディレクトリ・パス。手順11で、インポート・スクリプト(jobs_regions_tbs_imp.sql)、データ・ポンプ・エクスポート・ダンプ・ファイル(jobs_regions_tbs.dmp)および生成された各表領域のデータ・ファイル(jobs_tbs.dbfとregions_tbs.dbf)を、宛先データベースが実行されているコンピュータ・システムの1つ以上のディレクトリに転送します。スクリプトに指定されているディレクトリ・パスが正しいことを確認します。

11. インポート・スクリプト(jobs_regions_tbs_imp.sql)、データ・ポンプ・エクスポート・ダンプ・ファイル(jobs_regions_tbs.dmp)および生成された各表領域のデータ・ファイル(jobs_tbs.dbfとregions_tbs.dbf)を宛先データベースに転送します。DBMS_FILE_TRANSFERパッケージ、バイナリFTPまたは他のなんらかの方法を使用して、ファイルを宛先データベースに送信できます。ファイル転送後、これらのファイルは、インポート・スクリプトに指定されたディレクトリに存在します。

12. SQL*Plusで、Oracle Streams管理者として宛先データベースtts2.example.comに接続します。

13. インポート・スクリプトを実行します。

SET ECHO ON
SPOOL jobs_tbs_imp.out
@jobs_tbs_imp.sql

スクリプトが完了したら、jobs_tbs_imp.outスプール・ファイルをチェックして、すべてのアクションが正常に終了していることを確認します。

関連項目:
「インスタンス化の後の一貫性の確認」

RMANを使用したデータベース全体のインスタンス化

RMANのDUPLICATEコマンドを実行すると、別の場所にターゲット・データベースのコピーが作成されます。このコマンドでは、RMANの補助インスタンスを使用してターゲット・データベース・ファイルのバックアップがリストアされ、新しいデータベースが作成されます。Oracle Streamsでのインスタンス化では、ターゲット・データベースがソース・データベース、新しく作成するデータベースが宛先データベースです。RMANのDUPLICATEコマンドを使用する場合、ソース・データベースと宛先データベースが同じプラットフォームで実行されている必要があります。

RMANのCONVERT DATABASEコマンドを実行すると、異なるプラットフォームの新しい宛先データベース用のデータ・ファイルと初期化パラメータ・ファイルが生成されます。また、新しい宛先データベースを作成するスクリプトも生成されます。これらのファイルによって、ソース・データベースと異なるプラットフォームで実行されている(ただし、エンディアン形式はソース・データベースと同じ)宛先データベース全体をインスタンス化できます。

RMANのDUPLICATEおよびCONVERT DATABASEコマンドでは、データベース・オブジェクトのインスタンス化SCNの値は設定されません。インスタンス化SCNの値は、インスタンス化中に手動で設定する必要があります。

この項の例では、RMANのDUPLICATEコマンドまたはCONVERT DATABASEコマンドを使用してデータベース全体をインスタンス化する場合に必要な手順について説明します。これらのいずれかのRMANのコマンドを使用してデータベース全体をインスタンス化するには、次の一般的な手順を実行します。

1. RMANのコマンドを使用して、ソース・データベース全体を接続先サイトにコピーします。

2. DBMS_STREAMS_ADMパッケージのREMOVE_STREAMS_CONFIGURATIONプロシージャを使用して、接続先サイトからOracle Streams構成を削除します。

3. ソース・データベースからの変更を適用する適用プロセスも含め、Oracle Streams接続先サイトを構成します。

この手順は、ソース・データベースで実行中の取得プロセスまたは伝播を停止させずに実行できます。

次のいずれかの項の手順に従います。

- RMANを使用した同じプラットフォーム上のデータベース全体のインスタンス化

- RMANを使用した異なるプラットフォーム上のデータベース全体のインスタンス化

注意:

- データベース全体のサポートされているすべての変更をレプリケートするOracle Streamsレプリケーション環境を構成するには、DBMS_STREAMS_ADMパッケージのPRE_INSTANTIATION_SETUPおよびPOST_INSTANTIATION_SETUPプロシージャを使用します。手順については、「ローカル取得を使用した2データベース・グローバル・レプリケーションの構成」を参照してください。

- 分散トランザクションが実行される可能性のある環境では、インスタンス化にRMANを使用しないことをお薦めします。これを行うと、インダウト・トランザクションが発生し、手動で訂正する必要がある場合があります。かわりに、インスタンス化にはエクスポート/インポートまたはトランスポータブル表領域を使用してください。

関連項目:
Oracle Streams管理者を構成する方法の詳細は、「すべてのデータベースでのOracle Streams管理者の構成」を参照してください。

RMANを使用した同じプラットフォーム上のデータベース全体のインスタンス化

この項の例では、RMANのDUPLICATEコマンドを使用して、データベース全体をインスタンス化します。この例では、次のことを想定しています。

- ソース・データベースdpx1.example.comに対するすべての変更を取得して、別の宛先データベースdpx2.example.comにそれらの変更を伝播し、適用します。

- ソース・データベースでOracle Streams管理者strmadminを構成済です。「すべてのデータベースでのOracle Streams管理者の構成」を参照してください。

- dpx1.example.comデータベースとdpx2.example.comデータベースは、同じプラットフォームで実行されています。

関連項目:
RMANのDUPLICATEコマンドを使用する方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

次の手順を実行して、ソース・データベースと宛先データベースが同じプラットフォームで実行されている場合に、RMANを使用してデータベース全体をインスタンス化します。

1. ソース・データベースのバックアップを作成します(存在しない場合)。RMANには、複製用に有効なバックアップが必要です。この例では、dpx1.example.comのバックアップを作成します(存在しない場合)。

注意:
RMANのDUPLICATEコマンドを実行する際にFROM ACTIVE DATABASEオプションを使用する場合、ソース・データベースのバックアップは不要です。大規模なデータベースでは、FROM ACTIVE DATABASEオプションの実行に大量のネットワーク・リソースが必要になります。この例では、このオプションは使用しません。

2. SQL*Plusで、Oracle Streams管理者としてソース・データベースdpx1.example.comに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

3. ソース・データベースからの変更をステ―ジングするANYDATAキューを作成します(存在しない場合)。このキューは、構成後に宛先データベースに伝播される変更をステージングします。
たとえば、次のプロシージャを実行すると、キューstreams_queueが作成されます。

EXEC DBMS_STREAMS_ADM.SET_UP_QUEUE();

手順9までは、SQL*Plusでソース・データベースにOracle Streams管理者として接続したまま実行してください。

4. dpx1.example.comからdpx2.example.comへのデータベース・リンクを作成します。

CREATE DATABASE LINK dpx2.example.com CONNECT TO strmadmin
IDENTIFIED BY password USING 'dpx2.example.com';

5. ソース・データベースのソース・キューから宛先データベースの宛先キューへの伝播を作成します。この時点では宛先データベースの宛先キューは存在していませんが、この伝播を作成すると、ソース・キューにエンキューされた論理変更レコード(LCR)は、伝播が可能になるまでこのキューでステージングされます。ソース・キューは、取得されたLCRのみでなく、宛先データベースでOracle Streamsデータ・ディクショナリを移入する内部メッセージもステージングします。

次のプロシージャを実行すると、dpx1_to_dpx2伝播が作成されます。

BEGIN
DBMS_STREAMS_ADM.ADD_GLOBAL_PROPAGATION_RULES(
streams_name            => 'dpx1_to_dpx2',
source_queue_name       => 'strmadmin.streams_queue',
destination_queue_name  => 'strmadmin.streams_queue@dpx2.example.com',
include_dml             => TRUE,
include_ddl             => TRUE,
source_database         => 'dpx1.example.com',
inclusion_rule          => TRUE,
queue_to_queue          => TRUE);
END;
/

6. 手順5で作成した伝播を停止します。

BEGIN
DBMS_PROPAGATION_ADM.STOP_PROPAGATION(
propagation_name  => 'dpx1_to_dpx2');
END;
/

7. ソース・データベース全体をインスタンス化のために準備します(準備していない場合)。「インスタンス化のためのデータベース内のすべてのデータベース・オブジェクトの準備」を参照してください。

DBMS_STREAMS_ADMパッケージのADD_GLOBAL_RULESプロシージャを使用して、ソース・データベースに対するすべての変更を取得する取得プロセスを作成します(存在しない場合)。取得プロセスがソース・データベースへのデータベース・リンクを持つローカルの取得プロセスまたはダウンストリームの取得プロセスである場合に、このプロシージャを実行すると、ソース・データベース全体がインスタンス化のために自動的に準備されます。このような取得プロセスがすでに存在している場合は、DBA_CAPTURE_PREPARED_DATABASEデータ・ディクショナリ・ビューを問い合せて、ソース・データベースがインスタンス化のために準備されていることを確認してください。

8. 手順7で取得プロセスを作成している場合、その取得プロセスを起動します。

BEGIN
DBMS_CAPTURE_ADM.START_CAPTURE(
capture_name  => 'capture_db');
END;
/

9. RMANのDUPLICATEコマンドに指定する終了SCNを判断します。

SET SERVEROUTPUT ON SIZE 1000000
DECLARE
until_scn NUMBER;
BEGIN
until_scn:= DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER;
DBMS_OUTPUT.PUT_LINE('Until SCN: ' || until_scn);
END;
/

戻された終了SCNをメモします。この番号は手順14で使用します。この例では、戻された終了SCNが3050191であると想定します。

10. SQL*Plusで、管理ユーザーとしてソース・データベースdpx1.example.comに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

11. 現行のオンラインREDOログをアーカイブします。

ALTER SYSTEM ARCHIVE LOG CURRENT;

12. データベースの複製用に環境を準備します。宛先データベースを複製の補助インスタンスとして準備します。手順については、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

13. RMANクライアントを起動し、TARGETとしてソース・データベースdpx1.example.comに、AUXILIARYとして宛先データベースdpx2.example.comに接続します。
RMANのCONNECTコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

14. OPEN RESTRICTEDオプションを指定してRMANのDUPLICATEコマンドを実行し、宛先データベースでソース・データベースをインスタンス化します。OPEN RESTRICTEDオプションは必須です。このオプションを指定すると、SQL文ALTER SYSTEM ENABLE RESTRICTED SESSIONを発行することによって、複製データベースで制限付きセッションを有効にできます。RMANは、複製データベースがオープンされる直前にこの文を発行します。

UNTIL SCN句を使用して、複製用のSCNを指定できます。この句には、手順9で判断した終了SCNを使用します。RMANのDUPLICATEコマンドに指定した終了SCNは、手順7でデータベースがインスタンス化のために準備された際のSCNより大きい必要があります。また、アーカイブREDOログが、指定した終了SCN値以上で使用可能である必要があります。したがって、手順11では、終了SCNを含むREDOログをアーカイブしています。

DUPLICATEコマンドのTO database_name に、複製データベースの名前を指定していることを確認してください。この例では、複製データベースの名前はdpx2です。したがって、この例のDUPLICATEコマンドにはTO dpx2が含まれます。

次に、RMANのDUPLICATEコマンドの例を示します。

RMAN> RUN
{
SET UNTIL SCN 3050191;
ALLOCATE AUXILIARY CHANNEL dpx2 DEVICE TYPE sbt;
DUPLICATE TARGET DATABASE TO dpx2
NOFILENAMECHECK
OPEN RESTRICTED;
}

関連項目:
RMANのDUPLICATEコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

15. SQL*Plusで宛先データベースに管理ユーザーとして接続し、データベースのグローバル名を変更します。RMANのDUPLICATEコマンドを実行すると、宛先データベースはソース・データベースと同じグローバル名を持ちます。

ALTER DATABASE RENAME GLOBAL_NAME TO DPX2.EXAMPLE.COM;

16. SQL*Plusで宛先データベースに管理ユーザーとして接続し、次のプロシージャを実行します。

注意:
このプロシージャを実行するとローカルのOracle Streams構成が削除されるため、このプロシージャを実行する際は、ソース・データベースではなく宛先データベースに接続していることを確認してください。

EXEC DBMS_STREAMS_ADM.REMOVE_STREAMS_CONFIGURATION();

注意:
ソース・データベースの表のサプリメンタル・ログ・グループは宛先データベースに保持されるため、REMOVE_STREAMS_CONFIGURATIONプロシージャを実行しても削除されません。これらのサプリメンタル・ログ・グループは、必要に応じて削除できます。

関連項目:
REMOVE_STREAMS_CONFIGURATIONプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

17. 宛先データベースでALTER SYSTEM文を実行して、RESTRICTED SESSIONを無効化します。

ALTER SYSTEM DISABLE RESTRICTED SESSION;

18. 宛先データベースで、Oracle Streams管理者として接続します。「すべてのデータベースでのOracle Streams管理者の構成」を参照してください。

19. 宛先データベースで、手順5で指定したキューを作成します。
たとえば、次のプロシージャを実行すると、キューstreams_queueが作成されます。

EXEC DBMS_STREAMS_ADM.SET_UP_QUEUE();

20. 宛先データベースで、Oracle Streams環境を構成します。

注意:
手順22でグローバル・インスタンス化SCNを設定するまでは、宛先データベースで適用プロセスを起動しないでください。

21. 宛先データベースで、宛先データベースからソース・データベースへのデータベース・リンクを作成します。

CREATE DATABASE LINK dpx1.example.com CONNECT TO strmadmin
IDENTIFIED BY password USING 'dpx1.example.com';

次の手順でrecursiveパラメータをTRUEに設定してSET_GLOBAL_INSTANTIATION_SCNプロシージャを実行するため、このデータベース・リンクが必要になります。

22. 宛先データベースで、ソース・データベースのグローバル・インスタンス化SCNを設定します。RMANのDUPLICATEコマンドを実行すると、UNTIL SCN句で指定したSCN値より1つ少ない値まで、データベースが複製されます。したがって、手順14でDUPLICATEコマンドを実行した際に指定した終了SCN値から1を引く必要があります。この例では、終了SCNを3050191に設定しています。したがって、インスタンス化SCNは3050191 - 1の3050190に設定する必要があります。

たとえば、dpx1.example.comソース・データベースのグローバル・インスタンス化SCNを3050190に設定するには、次のプロシージャを実行します。

BEGIN
DBMS_APPLY_ADM.SET_GLOBAL_INSTANTIATION_SCN(
source_database_name   =>  'dpx1.example.com',
instantiation_scn      =>  3050190,
recursive              =>  TRUE);
END;
/

宛先データベースのすべてのスキーマおよび表のインスタンス化SCNを設定するには、recursiveパラメータがTRUEに設定されていることを確認してください。

23. 宛先データベースで、構成した適用プロセスを起動できます。

24. ソース・データベースで、手順6で停止した伝播を起動します。

BEGIN
DBMS_PROPAGATION_ADM.START_PROPAGATION(
queue_name  => 'dpx1_to_dpx2');
END;
/

関連項目:
「インスタンス化の後の一貫性の確認」

RMANを使用した異なるプラットフォーム上のデータベース全体のインスタンス化

この項の例では、RMANのCONVERT DATABASEコマンドを使用して、データベース全体をインスタンス化します。この例では、次のことを想定しています。

- ソース・データベースcvx1.example.comに対するすべての変更を取得して、別の宛先データベースcvx2.example.comにそれらの変更を伝播し、適用します。

- ソース・データベースでOracle Streams管理者strmadminを構成済です。「すべてのデータベースでのOracle Streams管理者の構成」を参照してください。

- cvx1.example.comとcvx2.example.comデータベースは異なるプラットフォーム上で実行され、RMANのCONVERT DATABASEコマンドはそのプラットフォームの組合せでサポートされています。DBMS_TDBパッケージを使用して、任意のプラットフォームの組合せでサポートされているかどうかを判別できます。

RMANのCONVERT DATABASEコマンドを実行すると、変換済のデータ・ファイル、初期化パラメータ・ファイル(PFILE)およびSQLスクリプトが生成されます。変換済のデータ・ファイルおよびPFILEは宛先データベースで使用し、SQLスクリプトは、接続先プラットフォームで宛先データベースを作成するために使用します。

関連項目:
RMANのCONVERT DATABASEコマンドを使用する手順については、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

次の手順を実行して、ソース・データベースと宛先データベースが異なるプラットフォームで実行されている場合に、RMANを使用してデータベース全体をインスタンス化します。

1. ソース・データベースのバックアップを作成します(存在しない場合)。RMANには、有効なバックアップが必要です。この例では、cvx1.example.comのバックアップを作成します(存在しない場合)。

2. SQL*Plusで、Oracle Streams管理者としてソース・データベースcvx1.example.comに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

3. ソース・データベースからの変更をステ―ジングするANYDATAキューを作成します(存在しない場合)。このキューは、構成後に宛先データベースに伝播される変更をステージングします。
たとえば、次のプロシージャを実行すると、キューstreams_queueが作成されます。

EXEC DBMS_STREAMS_ADM.SET_UP_QUEUE();

手順8までは、SQL*Plusでソース・データベースにOracle Streams管理者として接続したまま実行してください。

4. cvx1.example.comからcvx2.example.comへのデータベース・リンクを作成します。

CREATE DATABASE LINK cvx2.example.com CONNECT TO strmadmin
IDENTIFIED BY password USING 'cvx2.example.com';

5. ソース・データベースのソース・キューから宛先データベースの宛先キューへの伝播を作成します。この時点では宛先データベースの宛先キューは存在していませんが、この伝播を作成すると、ソース・キューにエンキューされた論理変更レコード(LCR)は、伝播が可能になるまでこのキューでステージングされます。ソース・キューは、取得されたLCRのみでなく、宛先データベースでOracle Streamsデータ・ディクショナリを移入する内部メッセージもステージングします。

次のプロシージャを実行すると、cvx1_to_cvx2伝播が作成されます。

BEGIN
DBMS_STREAMS_ADM.ADD_GLOBAL_PROPAGATION_RULES(
streams_name            => 'cvx1_to_cvx2',
source_queue_name       => 'strmadmin.streams_queue',
destination_queue_name  => 'strmadmin.streams_queue@cvx2.example.com',
include_dml             => TRUE,
include_ddl             => TRUE,
source_database         => 'cvx1.example.com',
inclusion_rule          => TRUE,
queue_to_queue          => TRUE);
END;
/

6. 手順5で作成した伝播を停止します。

BEGIN
DBMS_PROPAGATION_ADM.STOP_PROPAGATION(
propagation_name  => 'cvx1_to_cvx2');
END;
/

7. ソース・データベース全体をインスタンス化のために準備します(準備していない場合)。「インスタンス化のためのデータベース内のすべてのデータベース・オブジェクトの準備」を参照してください。

DBMS_STREAMS_ADMパッケージのADD_GLOBAL_RULESプロシージャを使用して、ソース・データベースに対するすべての変更を取得する取得プロセスを作成します(存在しない場合)。取得プロセスがソース・データベースへのデータベース・リンクを持つローカルの取得プロセスまたはダウンストリームの取得プロセスである場合に、このプロシージャを実行すると、ソース・データベース全体がインスタンス化のために自動的に準備されます。このような取得プロセスがすでに存在している場合は、DBA_CAPTURE_PREPARED_DATABASEデータ・ディクショナリ・ビューを問い合せて、ソース・データベースがインスタンス化のために準備されていることを確認してください。

8. 手順7で取得プロセスを作成している場合、その取得プロセスを起動します。

BEGIN
DBMS_CAPTURE_ADM.START_CAPTURE(
capture_name  => 'capture_db');
END;
/

9. SQL*Plusで、管理ユーザーとしてソース・データベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

10. 現行のオンラインREDOログをアーカイブします。

ALTER SYSTEM ARCHIVE LOG CURRENT;

11. データベースの変換用に環境を準備します。たとえば、ソース・データベースを読取り専用モードでオープンします。手順は次のとおりです。

1. ソース・データベースがオープンしている場合は、停止して読取り専用モードで起動します。

2. DBMS_TDBパッケージのCHECK_DBおよびCHECK_EXTERNALファンクションを実行します。結果をチェックして、RMANのCONVERT DATABASEコマンドで変換がサポートされていることを確認します。

関連項目:
これらの手順の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

12. ソース・データベースの現行のSCNを判別します。

SET SERVEROUTPUT ON SIZE 1000000
DECLARE
current_scn NUMBER;
BEGIN
current_scn:= DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER;
DBMS_OUTPUT.PUT_LINE('Current SCN: ' || current_scn);
END;
/

戻されたSCN値をメモします。この番号は手順24で使用します。この例では、戻された値が46931285であると想定します。

13. RMANクライアントを起動し、TARGETとしてソース・データベースcvx1.example.comに接続します。
RMANのCONNECTコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

14. CONVERT DATABASEコマンドを実行します。
CONVERT DATABASEコマンドのNEW DATABASE database_name に、宛先データベースの名前を指定していることを確認してください。この例では、宛先データベースの名前はcvx2です。したがって、この例のCONVERT DATABASEコマンドにはNEW DATABASE cvx2が含まれます。

Linux IA(64-bit)プラットフォームで実行される宛先データベースに対するRMANのCONVERT DATABASEコマンドの例を次に示します。

CONVERT DATABASE NEW DATABASE 'cvx2'
TRANSPORT SCRIPT '/tmp/convertdb/transportscript.sql'
TO PLATFORM 'Linux IA (64-bit)'
DB_FILE_NAME_CONVERT '/home/oracle/dbs','/tmp/convertdb';

15. RMANのCONVERT DATABASEコマンドによって生成されたデータ・ファイル、PFILEおよびSQLスクリプトを、宛先データベースが実行されているコンピュータ・システムに転送します。

16. 宛先データベースが実行されているコンピュータ・システムで、制限付きセッションが有効にされた状態で宛先データベースが常にオープンするようにSQLスクリプトを変更します。
次のスクリプトの例では、必要な変更を太字で示しています。

-- The following commands will create a new control file and use it
-- to open the database.
-- Data used by Recovery Manager will be lost.
-- The contents of online logs will be lost and all backups will
-- be invalidated. Use this only if online logs are damaged.

-- After mounting the created controlfile, the following SQL
-- statement will place the database in the appropriate
-- protection mode:
--  ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE

STARTUP NOMOUNT PFILE='init_00gd2lak_1_0.ora'
CREATE CONTROLFILE REUSE SET DATABASE "CVX2" RESETLOGS  NOARCHIVELOG
MAXLOGFILES 32
MAXLOGMEMBERS 2
MAXDATAFILES 32
MAXINSTANCES 1
MAXLOGHISTORY 226
LOGFILE
GROUP 1 '/tmp/convertdb/archlog1'  SIZE 25M,
GROUP 2 '/tmp/convertdb/archlog2'  SIZE 25M
DATAFILE
'/tmp/convertdb/systemdf',
'/tmp/convertdb/sysauxdf',
'/tmp/convertdb/datafile1',
'/tmp/convertdb/datafile2',
'/tmp/convertdb/datafile3'
CHARACTER SET WE8DEC
;

-- NOTE: This ALTER SYSTEM statement is added to enable restricted session.

ALTER SYSTEM ENABLE RESTRICTED SESSION;

-- Database can now be opened zeroing the online logs.
ALTER DATABASE OPEN RESETLOGS;

-- No tempfile entries found to add.
--

set echo off
prompt ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
prompt * Your database has been created successfully!
prompt * There are many things to think about for the new database. Here
prompt * is a checklist to help you stay on track:
prompt * 1. You may want to redefine the location of the directory objects.
prompt * 2. You may want to change the internal database identifier (DBID)
prompt *    or the global database name for this database. Use the
prompt *    NEWDBID Utility (nid).
prompt ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

SHUTDOWN IMMEDIATE
-- NOTE: This startup has the UPGRADE parameter.
-- It already has restricted session enabled, so no change is needed.
STARTUP UPGRADE PFILE='init_00gd2lak_1_0.ora'
@@ ?/rdbms/admin/utlirp.sql
SHUTDOWN IMMEDIATE
-- NOTE: The startup below is generated without the RESTRICT clause.
-- Add the RESTRICT clause.
STARTUP RESTRICT PFILE='init_00gd2lak_1_0.ora'
-- The following step will recompile all PL/SQL modules.
-- It may take serveral hours to complete.
@@ ?/rdbms/admin/utlrp.sql
set feedback 6;

スクリプトに対して他の変更が必要な場合もあります。たとえば、宛先データベースのコンピュータ・システムの正しい位置を指すようにデータ・ファイルの位置およびPFILEの位置を変更する必要がある場合があります。

17. SQL*Plusで宛先データベースに管理ユーザーとして接続し、次のプロシージャを実行します。

注意:
このプロシージャを実行するとローカルのOracle Streams構成が削除されるため、このプロシージャを実行する際は、ソース・データベースではなく宛先データベースに接続していることを確認してください。

EXEC DBMS_STREAMS_ADM.REMOVE_STREAMS_CONFIGURATION();

注意:
ソース・データベースの表のサプリメンタル・ログ・グループは宛先データベースに保持されるため、REMOVE_STREAMS_CONFIGURATIONプロシージャを実行しても削除されません。これらのサプリメンタル・ログ・グループは、必要に応じて削除できます。

関連項目:
REMOVE_STREAMS_CONFIGURATIONプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

18. SQL*Plusで、Oracle Streams管理者として宛先データベースcvx2.example.comに接続します。

19. ソース・データベースからクローニングされた、ソース・データベースから宛先データベースへのデータベース・リンクを削除します。

DROP DATABASE LINK cvx2.example.com;

20. 宛先データベースでALTER SYSTEM文を実行して、RESTRICTED SESSIONを無効化します。

ALTER SYSTEM DISABLE RESTRICTED SESSION;

21. 宛先データベースで、手順5で指定したキューを作成します。
たとえば、次のプロシージャを実行すると、キューstreams_queueが作成されます。

EXEC DBMS_STREAMS_ADM.SET_UP_QUEUE();

22. 宛先データベースにOracle Streams管理者として接続し、Oracle Streams環境を構成します。「すべてのデータベースでのOracle Streams管理者の構成」を参照してください。

注意:
手順24でグローバル・インスタンス化SCNを設定するまでは、宛先データベースで適用プロセスを起動しないでください。

23. 宛先データベースで、ソース・データベースへのデータベース・リンクを作成します。

CREATE DATABASE LINK cvx1.example.com CONNECT TO strmadmin
IDENTIFIED BY password USING 'cvx1.example.com';

次の手順でrecursiveパラメータをTRUEに設定してSET_GLOBAL_INSTANTIATION_SCNプロシージャを実行するため、このデータベース・リンクが必要になります。

24. 宛先データベースで、ソース・データベースのグローバル・インスタンス化SCNを、手順12で戻されたSCN値に設定します。

たとえば、cvx1.example.comソース・データベースのグローバル・インスタンス化SCNを46931285に設定するには、次のプロシージャを実行します。

BEGIN
DBMS_APPLY_ADM.SET_GLOBAL_INSTANTIATION_SCN(
source_database_name   =>  'cvx1.example.com',
instantiation_scn      =>  46931285,
recursive              =>  TRUE);
END;
/

宛先データベースのすべてのスキーマおよび表のインスタンス化SCNを設定するには、recursiveパラメータがTRUEに設定されていることを確認してください。

25. 宛先データベースで、構成した適用プロセスを起動できます。

26. ソース・データベースで、手順6で停止した伝播を起動します。

BEGIN
DBMS_PROPAGATION_ADM.START_PROPAGATION(
propagation_name  => 'cvx1_to_cvx2');
END;
/

関連項目:
「インスタンス化の後の一貫性の確認」

宛先データベースでのインスタンス化SCNの設定

インスタンス化システム変更番号(SCN)は、宛先データベースの適用プロセスに対して、ソース・データベースで特定のSCNより後にコミットされた変更を適用するように指示します。インスタンス化SCNを設定するには、次の方法があります。

- ソース・データベースで関連するデータベース・オブジェクトをエクスポートし、宛先データベースでインポートします。この場合は、エクスポート/インポートによって宛先データベースでデータベース・オブジェクトが作成され、そこにソース・データベースからデータが移入され、関連するインスタンス化SCNが設定されます。インスタンス化には、データ・ポンプ・エクスポート/インポートを使用できます。各種のエクスポート/インポート操作用に設定されるインスタンス化SCNの詳細は、「エクスポート/インポートを使用したインスタンス化SCNの設定」を参照してください。

- データ・ポンプを使用して、メタデータのみのエクスポート/インポートを実行します。データ・ポンプ・エクスポート/インポートを使用する場合、ソース・データベースでのエクスポート中または宛先データベースでのインポート中(あるいはその両方)に、CONTENTパラメータをMETADATA_ONLYに設定します。データベース・オブジェクトのインスタンス化SCNは設定されますが、データはインポートされません。各種のエクスポート/インポート操作用に設定されるインスタンス化SCNの詳細は、「エクスポート/インポートを使用したインスタンス化SCNの設定」を参照してください。

- トランスポータブル表領域を使用して、ソース・データベースから宛先データベースに、1つ以上の表領域内のオブジェクトをコピーします。エクスポート前にインスタンス化のために準備したこれらの表領域内の各スキーマ、および各データベース・オブジェクトにインスタンス化SCNが設定されます。手順については、「トランスポータブル表領域またはRMANを使用した表領域内のオブジェクトのインスタンス化」を参照してください。

- DBMS_APPLY_ADMパッケージのSET_TABLE_INSTANTIATION_SCN、SET_SCHEMA_INSTANATIATION_SCNおよびSET_GLOBAL_INSTANTIATION_SCNプロシージャを使用して、インスタンス化SCNを設定します。手順については、「DBMS_APPLY_ADMパッケージを使用したインスタンス化SCNの設定」を参照してください。

関連項目:
『Oracle Streams概要および管理』

エクスポート/インポートを使用したインスタンス化SCNの設定

この項では、エクスポート/インポートを実行してインスタンス化SCNを設定する方法について説明します。この項の情報は、メタデータのエクスポート/インポート操作と、行をインポートするエクスポート/インポート操作の両方に適用されます。FLASHBACK_SCNやFLASHBACK_TIMEなどのエクスポート・パラメータを使用して、より厳密な一貫性レベルを指定できます。

ここでは、各種のエクスポート/インポート操作用のインスタンス化SCNを設定する方法について説明します。これらの項の説明は、準備済の表を対象としています。準備済の表とは、DBMS_CAPTURE_ADMパッケージのPREPARE_TABLE_INSTANTIATIONプロシージャ、PREPARE_SYNC_INSTANTIATIONファンクション、PREPARE_SCHEMA_INSTANTIATIONプロシージャまたはPREPARE_GLOBAL_INSTANTIATIONプロシージャを使用して、インスタンス化の準備を完了している表です。インポート中にインスタンス化SCNを設定するには、エクスポート前に表を準備済にする必要があります。ただし、データベースとスキーマの場合は、インポート中にインスタンス化SCNが設定されるようにエクスポート前に準備する必要はありません。

全データベースのエクスポートと全データベースのインポート

全データベースのエクスポートと全データベースのインポートでは、インポート・データベースで次のインスタンス化SCNが設定されます。

- データベースの、またはグローバルなインスタンス化SCN

- インポートされるユーザーごとの、スキーマのインスタンス化SCN

- インポートされる準備済の表ごとの、表のインスタンス化SCN

全データベースまたはユーザー・エクスポートおよびユーザー・インポート

全データベースまたはユーザー・エクスポートとユーザー・インポートでは、インポート・データベースで次のインスタンス化SCNが設定されます。

- インポートされるユーザーごとの、スキーマのインスタンス化SCN

- インポートされる準備済の表ごとの、表のインスタンス化SCN

全データベース、ユーザーまたは表エクスポートおよび表インポート

1つ以上の表を含むエクスポートと表のインポートでは、インポート・データベースでインポートされる準備済の表ごとに、表のインスタンス化SCNが設定されます。

注意:

- インポートを実行する宛先データベースに、データベース・オブジェクトについて非NULLのインスタンス化SCNがすでに存在する場合は、インポートを実行すると、そのデータベース・オブジェクトのインスタンス化SCNが更新されます。

- Oracle Streamsをインスタンス化するためのエクスポート中は、エクスポート対象のオブジェクトに対してデータ定義言語(DDL)変更が行われないように注意してください。

- エクスポート・データベースからエクスポートされた表の表サプリメンタル・ロギング指定は、インポート・データベースで表がインポートされる際に保持されます。

関連項目:

- エクスポート/インポートの使用方法は、「Oracle Data PumpとOracle Streamsのインスタンス化」および『Oracle Databaseユーティリティ』を参照してください。

- Oracle Streams環境の構成時に、エクスポート/インポート操作を実行してインスタンス化SCNを設定する方法の詳細は、第I部「Oracle Streamsレプリケーションの構成」を参照してください。

- 「ソース・データベースでインスタンス化を行うためのデータベース・オブジェクトの準備」

DBMS_APPLY_ADMパッケージを使用したインスタンス化SCNの設定

DBMS_APPLY_ADMパッケージの次のいずれかのプロシージャを使用すると、指定した表、指定したスキーマまたはデータベース全体について、宛先データベースでインスタンス化SCNを設定できます。

- SET_TABLE_INSTANTIATION_SCN

- SET_SCHEMA_INSTANTIATION_SCN

- SET_GLOBAL_INSTANTIATION_SCN

SET_SCHEMA_INSTANTIATION_SCNを使用してスキーマのインスタンス化SCNを設定する場合は、このプロシージャを実行する際にrecursiveパラメータをTRUEに設定すると、スキーマ内の表ごとにインスタンス化SCNを設定できます。同様に、SET_GLOBAL_INSTANTIATION_SCNを使用してデータベースのインスタンス化SCNを設定する場合は、このプロシージャを実行する際にrecursiveパラメータをTRUEに設定すると、データベース内のスキーマ、およびそれらのスキーマが所有する表ごとにインスタンス化SCNを設定できます。

注意:

- SET_SCHEMA_INSTANTIATION_SCNプロシージャまたはSET_GLOBAL_INSTANTIATION_SCNプロシージャでrecursiveパラメータをTRUEに設定する場合は、宛先データベースからソース・データベースへのデータベース・リンクが必要です。このデータベース・リンクはソース・データベースのグローバル名と同じ名前であり、プロシージャを実行するユーザーからアクセス可能である必要があります。

- データベース・オブジェクトにインスタンス化SCNを設定する場合は、ルールベースの変換または適用ハンドラがスキーマ名またはデータベース・オブジェクト名を変更するように構成されていても、ソース・データベースでスキーマとデータベース・オブジェクトの名前を必ず指定してください。

- 関連するインスタンス化SCNが存在しないと、適用中にエラーが発生します。

- これらのプロシージャでは、取得プロセスおよび同期取得によって取得された変更に対して、インスタンス化SCNを設定できます。

表8-3に、各プロシージャとインスタンス化SCNを設定する文のタイプを示します。

表8-3 インスタンス化SCNを設定するプロシージャと、その対象となる文

プロシージャ

インスタンス化SCNの設定対象

例

SET_TABLE_INSTANTIATION_SCN

CREATE TABLEを除く、表に対するDML文とDDL文

表の索引と表のトリガーに対するDDL文

UPDATE

ALTER TABLE

DROP TABLE

表に対するCREATE、ALTERまたはDROP INDEX

表に対するCREATE、ALTERまたはDROP TRIGGER

SET_SCHEMA_INSTANTIATION_SCN

CREATE USERを除く、ユーザーに対するDDL文

表レベルのインスタンス化SCNによって処理されるDDL文を除き、PUBLIC以外の所有者を持つ全データベース・オブジェクトに対するDDL文

CREATE TABLE

ALTER USER

DROP USER

CREATE PROCEDURE

SET_GLOBAL_INSTANTIATION_SCN

所有者を持たない、ユーザー以外のデータベース・オブジェクトに対するDDL文

PUBLICに所有されるデータベース・オブジェクトに対するDDL文

CREATE USER文

CREATE USER

CREATE TABLESPACE

ソース・データベースへの接続中のインスタンス化SCNの設定

この項の例を実行するユーザーは、ソース・データベースから宛先データベースへのデータベース・リンクに対するアクセス権を持っている必要があります。この項の例では、データベース・リンクはhrdb2.example.comです。次の例では、ソース・データベースhrdb1.example.comで次のプロシージャを実行することで、hrdb2.example.comデータベースでhr.departments表のインスタンス化SCNが現行のSCNに設定されます。

DECLARE
iscn  NUMBER;         -- Variable to hold instantiation SCN value
BEGIN
iscn := DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER();
DBMS_APPLY_ADM.SET_TABLE_INSTANTIATION_SCN@HRDB2.EXAMPLE.COM(
source_object_name    => 'hr.departments',
source_database_name  => 'hrdb1.example.com',
instantiation_scn     => iscn);
END;
/

次の例では、ソース・データベースhrdb1.example.comで次のプロシージャを実行することで、hrdb2.example.comデータベースでoeスキーマおよびそのすべてのオブジェクトのインスタンス化SCNが、ソース・データベースの現行のSCNに設定されます。

DECLARE
iscn  NUMBER;         -- Variable to hold instantiation SCN value
BEGIN
iscn := DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER();
DBMS_APPLY_ADM.SET_SCHEMA_INSTANTIATION_SCN@HRDB2.EXAMPLE.COM(
source_schema_name    => 'oe',
source_database_name  => 'hrdb1.example.com',
instantiation_scn     => iscn,
recursive             => TRUE);
END;
/

recursiveパラメータがTRUEに設定されているため、このプロシージャを実行すると、oeスキーマ内のデータベース・オブジェクトごとにインスタンス化SCNが設定されます。

注意:
recursiveパラメータをTRUEに設定する際は、ソース・データベースへの接続中にプロシージャを実行する場合でも、宛先データベースからソース・データベースへのデータベース・リンクが必要です。このデータベース・リンクはソース・データベースのグローバル名と同じ名前であり、現行ユーザーからアクセス可能である必要があります。

宛先データベースへの接続中のインスタンス化SCNの設定

この項の例を実行するユーザーは、宛先データベースからソース・データベースへのデータベース・リンクに対するアクセス権を持っている必要があります。この項の例では、データベース・リンクはhrdb1.example.comです。次の例では、宛先データベースhrdb2.example.comで次のプロシージャを実行することで、hrdb2.example.comデータベースでhr.departments表のインスタンス化SCNが、ソース・データベースhrdb1.example.comの現行のSCNに設定されます。

DECLARE
iscn  NUMBER;         -- Variable to hold instantiation SCN value
BEGIN
iscn := DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER@HRDB1.EXAMPLE.COM;
DBMS_APPLY_ADM.SET_TABLE_INSTANTIATION_SCN(
source_object_name    => 'hr.departments',
source_database_name  => 'hrdb1.example.com',
instantiation_scn     => iscn);
END;
/

次の例では、宛先データベースhrdb2.example.comで次のプロシージャを実行することで、hrdb2.example.comデータベースでoeスキーマおよびそのすべてのオブジェクトのインスタンス化SCNが、ソース・データベースhrdb1.example.comの現行のSCNに設定されます。

DECLARE
iscn  NUMBER;         -- Variable to hold instantiation SCN value
BEGIN
iscn := DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER@HRDB1.EXAMPLE.COM;
DBMS_APPLY_ADM.SET_SCHEMA_INSTANTIATION_SCN(
source_schema_name    => 'oe',
source_database_name  => 'hrdb1.example.com',
instantiation_scn     => iscn,
recursive             => TRUE);
END;
/

recursiveパラメータがTRUEに設定されているため、このプロシージャを実行すると、oeスキーマ内のデータベース・オブジェクトごとにインスタンス化SCNが設定されます。

注意:
適用プロセスでOracle以外のリモート・データベースに変更が適用される場合は、インスタンス化SCNを設定するときに、apply_database_linkパラメータをリモートの適用に使用するデータベース・リンクに設定します。

関連項目:

- Oracle Streams環境の構成時にインスタンス化SCNを設定する場合の詳細は、第I部「Oracle Streamsレプリケーションの構成」を参照してください。

- SET_TABLE_INSTANTIATION_SCNプロシージャを使用する場合の詳細な例は、『Oracle Streams拡張例』を参照してください。

- DDL LCRに使用できるインスタンス化SCNの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のDBMS_APPLY_ADMパッケージに関する項を参照してください。

インスタンス化の監視

ここでは、ソース・データベースでインスタンス化のために準備済であるデータベース・オブジェクト、および宛先データベースでのデータベース・オブジェクトのインスタンス化SCNを判断するために実行できる問合せについて説明します。

- どのデータベース・オブジェクトがインスタンス化のために準備済であるかの判断

- インスタンス化SCNが設定されている表の判断

どのデータベース・オブジェクトがインスタンス化のために準備済であるかの判断

データベース・オブジェクトをインスタンス化のために準備する方法の詳細は、「取得のルールとインスタンス化の準備」を参照してください。

どのデータベース・オブジェクトのインスタンス化の準備が完了しているかを判断するには、次のデータ・ディクショナリ・ビューを問い合せます。

- DBA_CAPTURE_PREPARED_TABLES

- DBA_SYNC_CAPTURE_PREPARED_TABS

- DBA_CAPTURE_PREPARED_SCHEMAS

- DBA_CAPTURE_PREPARED_DATABASE

たとえば、PREPARE_TABLE_INSTANTIATIONプロシージャでインスタンス化の準備が完了しているすべての表、各表が準備された時刻およびそのSCNを表示するには、次の問合せを実行します。

COLUMN TABLE_OWNER HEADING 'Table Owner' FORMAT A15
COLUMN TABLE_NAME HEADING 'Table Name' FORMAT A15
COLUMN SCN HEADING 'Prepare SCN' FORMAT 99999999999
COLUMN TIMESTAMP HEADING 'Time Ready for|Instantiation'

SELECT TABLE_OWNER,
TABLE_NAME,
SCN,
TO_CHAR(TIMESTAMP, 'HH24:MI:SS MM/DD/YY') TIMESTAMP
FROM DBA_CAPTURE_PREPARED_TABLES;

出力は次のようになります。

Time Ready for
Table Owner     Table Name            Prepare SCN Instantiation
--------------- --------------- ----------------- -----------------
HR              COUNTRIES                  196655 12:59:30 02/28/02
HR              DEPARTMENTS                196658 12:59:30 02/28/02
HR              EMPLOYEES                  196659 12:59:30 02/28/02
HR              JOBS                       196660 12:59:30 02/28/02
HR              JOB_HISTORY                196661 12:59:30 02/28/02
HR              LOCATIONS                  196662 12:59:30 02/28/02
HR              REGIONS                    196664 12:59:30 02/28/02

関連項目:
「ソース・データベースでインスタンス化を行うためのデータベース・オブジェクトの準備」

インスタンス化SCNが設定されている表の判断

インスタンス化SCNは、宛先データベースで設定されます。これによって、適用プロセスで、データベース・オブジェクトに対して無視される取得論理変更レコード(LCR)と適用される取得LCRが制御されます。ソース・データベースからの表に関するLCRのコミットSCNが、宛先データベースでその表のインスタンス化SCN以下であれば、宛先データベースの適用プロセスではLCRが廃棄されます。それ以外の場合は、適用プロセスによってLCRが適用されます。LCRは、取得プロセスまたは同期取得で取得できます。「宛先データベースでのインスタンス化SCNの設定」を参照してください。

どのデータベース・オブジェクトのインスタンス化SCNが設定されているかを判断するには、対応する次のデータ・ディクショナリ・ビューを問い合せます。

- DBA_APPLY_INSTANTIATED_OBJECTS

- DBA_APPLY_INSTANTIATED_SCHEMAS

- DBA_APPLY_INSTANTIATED_GLOBAL

次の問合せを実行すると、宛先データベースでインスタンス化SCNが設定されている各表と、それぞれの表のインスタンス化SCNが表示されます。

COLUMN SOURCE_DATABASE HEADING 'Source Database' FORMAT A20
COLUMN SOURCE_OBJECT_OWNER HEADING 'Object Owner' FORMAT A15
COLUMN SOURCE_OBJECT_NAME HEADING 'Object Name' FORMAT A15
COLUMN INSTANTIATION_SCN HEADING 'Instantiation SCN' FORMAT 99999999999

SELECT SOURCE_DATABASE,
SOURCE_OBJECT_OWNER,
SOURCE_OBJECT_NAME,
INSTANTIATION_SCN
FROM DBA_APPLY_INSTANTIATED_OBJECTS
WHERE APPLY_DATABASE_LINK IS NULL;

出力は次のようになります。

Source Database     Object Owner    Object Name     Instantiation SCN
-------------------- --------------- --------------- -----------------
DBS1.EXAMPLE.COM     HR              REGIONS                    196660
DBS1.EXAMPLE.COM     HR              COUNTRIES                  196660
DBS1.EXAMPLE.COM     HR              LOCATIONS                  196660

注意:
Oracle以外のリモート・データベースに適用される変更についてのインスタンス化SCNを表示することもできます。この問合せでは、APPLY_DATABASE_LINK列がNULLの場合にのみインスタンス化SCNが表示されるため、これらのインスタンス化SCNは表示されません。

関連項目:
「宛先データベースでのインスタンス化SCNの設定」

9 Oracle Streamsの競合解消

一部のOracle Streams環境では、複数のデータベース間にデータ共有が原因で発生する可能性のあるデータの競合を解消するために、競合ハンドラを使用する必要があります。

この章の内容は次のとおりです。

- Oracle Streams環境内のDMLの競合

- Oracle Streams環境内の競合のタイプ

- Oracle Streams環境内の競合とトランザクションの順序付け

- Oracle Streams環境内の競合検出

- Oracle Streams環境内の競合防止

- Oracle Streams環境内の競合解消

- Oracle Streamsの競合検出および解消の管理

- 競合検出および更新の競合ハンドラの監視

Oracle Streams環境内のDMLの競合

競合は、LCR内の古い値と、表内の予期されるデータが一致しないことです。複数データベース上で同じデータに対して同時のデータ操作言語(DML)操作を許可しているOracle Streams環境では、競合が発生する可能性があります。Oracle Streams環境でDMLの競合が発生する可能性があるのは、適用プロセスがDML操作によって生じる行の変更を含むメッセージを適用している場合のみです。この種のメッセージは、行の論理変更レコードまたは行LCRと呼ばれます。適用プロセスでは、行LCRが原因で発生する競合が自動的に検出されます。

たとえば、異なるデータベースで発生した2つのトランザクションによって同じ行がほぼ同時に更新されると、競合が発生する場合があります。Oracle Streams環境の構成時には、競合の発生を許可するかどうかを考慮する必要があります。システム設計で競合が許可されている場合は、競合を自動的に解消するように競合解消を構成できます。

通常は、競合の可能性を回避するOracle Streams環境を設計する必要があります。この章で後述する競合防止技法を使用すると、ほとんどのシステム設計で共有データ全体または大部分における競合を防止できます。ただし、多くのアプリケーションでは、複数のデータベースで共有データをある程度の割合まで随時更新可能にする必要があります。この場合は、競合の可能性への対処が必要となります。

注意:
適用プロセスでは、DDLの競合またはユーザー・メッセージによって発生する競合は検出されません。この種の競合が環境で防止されることを確認してください。

関連項目:
行LCRの詳細は、『Oracle Streams概要および管理』を参照してください。

Oracle Streams環境内の競合のタイプ

複数のデータベースでデータを共有する場合は、次のタイプの競合が発生する可能性があります。

- Oracle Streams環境内の更新の競合

- Oracle Streams環境内の一意性競合

- Oracle Streams環境内の削除の競合

- Oracle Streams環境内の外部キーの競合

Oracle Streams環境内の更新の競合

更新の競合が発生するのは、適用プロセスで適用される行LCRに含まれている行の更新が、同じ行の他の更新と競合する場合です。また、異なるデータベースからの2つのトランザクションによって、同じ行がほぼ同時に更新される場合にも、更新の競合が発生する可能性があります。

Oracle Streams環境内の一意性競合

一意性競合が発生するのは、適用プロセスで適用される行LCRに含まれている行の変更が、PRIMARY KEY制約やUNIQUE制約など、一意性の整合性制約に違反している場合です。たとえば、2つの異なるデータベースからの2つのトランザクションがあり、それぞれのトランザクションが同じ主キー値を持つ表に1行を挿入する場合を考えます。この場合は、これらのトランザクションによって一意性競合が発生します。

Oracle Streams環境内の削除の競合

削除の競合が発生するのは、異なるデータベースで発生した2つのトランザクションがあり、1つのトランザクションで1行を削除し、もう1つのトランザクションで同じ行を更新または削除する場合です。この場合、行LCR内で参照された行は存在せず、更新も削除もできません。

Oracle Streams環境内の外部キーの競合

外部キーの競合が発生するのは、適用プロセスで適用される行LCRに含まれている行の変更が、外部キー制約に違反している場合です。たとえば、hrスキーマ内で、employees表のdepartment_id列は、departments表のdepartment_id列の外部キーです。次の変更が2つの異なるデータベース(AとB)で発生し、3つ目のデータベース(C)に伝播される場合を考えます。

- データベースAで、department_idが271の1行がdepartments表に挿入されます。この変更はデータベースBに伝播され、そこで適用されます。

- データベースBで、employee_idが206、department_idが271の1行がemployees表に挿入されます。

データベースBで発生した変更がデータベースAで発生した変更よりも先にデータベースCで適用されると、データベースCのdepartments表にはまだdepartment_idが271の部門の行が存在しないため、外部キーの競合が発生します。

Oracle Streams環境内の競合とトランザクションの順序付け

Oracle Streams環境では、3つ以上のデータベースがデータを共有し、そのうち2つ以上のデータベースでデータが更新されると、順序付けの競合が発生する可能性があります。たとえば、3つのデータベースがhr.departments表の情報を共有している使用例を考えます。データベースの名前はmult1.example.com、mult2.example.comおよびmult3.example.comです。mult1.example.comでhr.departments表の1行が変更され、その変更がmult2.example.comとmult3.example.comの両方に伝播されると想定します。次の一連のアクションが発生する可能性があります。

1. 変更がmult2.example.comに伝播します。

2. mult2.example.comの適用プロセスがmult1.example.comからの変更を適用します。

3. mult2.example.comで、同じ行に対して別の変更が行われます。

4. mult2.example.comでの変更がmult3.example.comに伝播します。

5. mult3.example.comで、1つの適用プロセスは、別の適用プロセスがmult3.example.comでmult1.example.comから変更の適用を実施する前に、mult2.example.comから変更の適用を試みます。

この場合、mult3.example.comでの行の列値はmult2.example.comから伝播した行LCR内の対応する元の値と一致しないため、競合が発生します。

トランザクションが順不同で適用されると、データ競合の原因となるのみでなく、データのサポートがリモート・データベースに正常に伝播されていないと、そのデータベースで参照整合性の問題が発生する場合があります。新規の顧客が受注部門に連絡する場合の使用例を考えます。顧客レコードが作成され、受注が処理されます。リモート・データベースで受注データが顧客データより前に適用されると、受注で参照されている顧客はリモート・データベースに存在しないため、参照整合性エラーが発生します。

順序付けの競合が発生した場合は、必要なデータがリモート・データベースに伝播して適用されてから、エラー・キューにあるトランザクションを再実行すれば、競合を解消できます。

Oracle Streams環境内の競合検出

適用プロセスでは、更新、一意性、削除および外部キーの競合が次のように検出されます。

- 行LCR内の行の元の値と、宛先データベースにある同じ行の現行の値が一致しない場合は、適用プロセスによって更新の競合が検出されます。

- 挿入または更新操作を含むLCRの適用時に一意制約違反が発生すると、適用プロセスによって一意性競合が検出されます。

- 更新または削除操作を含むLCRの適用時に、行の主キーが存在しないためにその行が見つからないと、適用プロセスによって削除の競合が検出されます。

- LCRの適用時に外部キー制約違反が発生すると、適用プロセスによって外部キーの競合が検出されます。

適用プロセスでLCRを直接適用しようとするか、DMLハンドラなどの適用プロセス・ハンドラでLCRに対してEXECUTEメンバー・プロシージャを実行すると、競合が検出される場合があります。また、DBMS_APPLY_ADMパッケージのEXECUTE_ERRORまたはEXECUTE_ALL_ERRORSプロシージャの実行時にも、競合が検出される場合があります。

注意:

- 列が更新され、古い列値がその列の新しい値と等しい場合、この列の更新の競合は検出されません。

- 更新LCR、削除LCRおよびLOB列に対するピース単位更新を取り扱うLCR内の古いLOB値は、競合検出には使用されません。

非キー列の競合検出の制御

デフォルトでは、適用プロセスは競合検出中にすべての列の古い値を比較しますが、DBMS_APPLY_ADMパッケージのCOMPARE_OLD_VALUESプロシージャを使用すると、非キー列の競合検出を停止できます。競合検出は、一部の非キー列では不要な場合があります。

関連項目:

- 「非キー列の競合検出の停止」

- 「競合検出に関する情報の表示」

Oracle Streams環境内の競合検出中の行の識別

Oracleは、競合を正確に検出するために、異なるデータベースで対応する行を一意に識別して一致させることができる必要があります。デフォルトでは、Oracleは表の主キーを使用してその表の各行を一意に識別します。表に主キーが存在しない場合は、代替キーを指定する必要があります。代替キーとは、Oracleが表の各行を一意に識別するために使用できる列または列セットです。

関連項目:
『Oracle Streams概要および管理』

Oracle Streams環境内の競合防止

この項では、データ競合を防止する方法について説明します。

プライマリ・データベース所有権モデルの使用

システム内で、共有データを含む表への同時更新アクセスを行うデータベースの数を制限することによって、競合の可能性を回避できます。プライマリ所有権を使用すると、共有データ・セットへの更新が1つのデータベースにしか許可されないため、すべての競合が防止されます。アプリケーションでは、行と列のサブセットを使用して、データの所有権を表レベルよりも細かく設定できます。たとえば、アプリケーションでは、共有表の特定の列や行への更新アクセス権を、データベースごとに設定できます。

特定タイプの競合の防止

プライマリ・データベース所有権モデルではアプリケーション要件にとって限定的すぎる場合は、共有所有権データ・モデルを使用できますが、これは、競合が発生する可能性があることを意味します。その場合でも、通常は、特定のタイプの競合を回避するためにいくつかの簡単な方法を使用する必要があります。

Oracle Streams環境内の一意性競合の防止

各データベースで共有データに一意識別子を使用させることで、一意性競合を回避できます。Oracle Streams環境ですべてのデータベースに一意識別子を確実に使用させるには、3つの方法があります。

その1つは、次のSELECT文を実行して一意識別子を構成することです。

SELECT SYS_GUID() OID FROM DUAL;

このSQL演算子は、16バイトのグローバル一意識別子を戻します。この値は、グローバル一意識別子を生成するために時刻、日付およびコンピュータ識別子を使用するアルゴリズムに基づいています。グローバル一意識別子は、次のような書式で表示されます。

A741C791252B3EA0E034080020AE3E0A

また、データを共有する各データベースで順序を作成し、データベース名(または他のグローバル一意値)をローカルの順序と連結して一意性競合を防止する方法もあります。このアプローチを使用すると、重複する順序値を回避し、一意性競合を防止できます。

最後に、2つのデータベースで同じ値を生成できないように、データを共有する各データベースでカスタマイズされた順序を作成する方法があります。そのためには、CREATE SEQUENCE文で開始値、増分値および最大値の組合せを使用します。たとえば、次の順序を構成できます。

表9-1 Oracle Streamsレプリケーション環境用にカスタマイズされた順序

パラメータ

データベースA

データベースB

データベースC

START WITH

1

3

5

INCREMENT BY

10

10

10

範囲の例

1, 11, 21, 31, 41,...

3, 13, 23, 33, 43,...

5, 15, 25, 35, 45,...

同様のアプローチを使用すると、データベースごとに一意の範囲を生成するSTART WITHおよびMAXVALUEを指定して、各データベースに異なる範囲を定義できます。

Oracle Streams環境内の削除の競合の防止

共有データ環境では、削除の競合を必ず回避してください。通常、共有所有権データ・モデル内で動作するアプリケーションでは、DELETE文を使用して行を削除することはありません。かわりに、アプリケーションで行に削除マークを付けておき、論理的に削除された行を定期的にパージするようにシステムを構成する必要があります。

Oracle Streams環境内の更新の競合の防止

一意性競合と削除の競合の可能性を排除した後、更新の競合の発生可能数も制限する必要があります。ただし、共有所有権データ・モデルでは、更新の競合を全面的に防止することはできません。更新の競合を全面的に防止できない場合は、可能な競合のタイプを把握したうえで、それが発生した場合は解消するようにシステムを構成する必要があります。

Oracle Streams環境内の競合解消

更新の競合が検出された場合、競合ハンドラではその解消を試みることができます。Oracle Streamsには、更新の競合を解消するためのビルトイン競合ハンドラが用意されていますが、一意性、削除、外部キーまたは順序付けの競合については用意されていません。ただし、ビジネス・ルールに固有のデータ競合を解消するために、独自のカスタム競合ハンドラを作成できます。この種の競合ハンドラは、プロシージャDMLハンドラまたはエラー・ハンドラに付属させることができます。

ビルトイン競合ハンドラとカスタム競合ハンドラのどちらを使用する場合も、競合が検出されるとただちに使用されます。指定した競合ハンドラでも関連する適用ハンドラでも競合を解消できない場合、その競合はエラー・キューに記録されます。競合が発生した場合は、関連する適用ハンドラを使用してデータベース管理者に通知する必要があります。

競合のためにトランザクションがエラー・キューに移動される場合は、競合の原因となった条件を訂正できる場合があります。このような場合は、DBMS_APPLY_ADMパッケージのEXECUTE_ERRORプロシージャを使用してトランザクションを再実行できます。

関連項目:

- プロシージャDMLハンドラ、エラー・ハンドラおよびエラー・キューの詳細は、『Oracle Streams概要および管理』を参照してください。

- DBMS_APPLY_ADMパッケージのEXECUTE_ERRORプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

ビルトインの更新の競合ハンドラ

この項では、使用可能なビルトインの更新の競合ハンドラのタイプと、この種のハンドラでの列リストと解消列の使用方法について説明します。列リストは、更新の競合がある場合に更新の競合ハンドラがコールされる列のリストです。解消列は、更新の競合ハンドラの識別に使用される列です。ビルトインの更新の競合ハンドラMAXIMUMまたはMINIMUMを使用する場合は、解消列も競合の解消に使用されます。解消列は、ハンドラの列リスト内の列の1つである必要があります。

特定の表について1つ以上の更新の競合ハンドラを指定するには、DBMS_APPLY_ADMパッケージのSET_UPDATE_CONFLICT_HANDLERプロシージャを使用します。一意性競合や削除または外部キーの競合には、ビルトインの競合ハンドラはありません。

関連項目:

- 更新の競合ハンドラを追加、変更および削除する手順については、「Oracle Streamsの競合検出および解消の管理」を参照してください。

- SET_UPDATE_CONFLICT_HANDLERプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- 「列リスト」

- 「解消列」

ビルトインの更新の競合ハンドラのタイプ

Oracleには、Oracle Streams環境用にOVERWRITE、DISCARD、MAXIMUMおよびMINIMUMタイプのビルトインの更新の競合ハンドラが用意されています。

後述の各タイプのハンドラの説明では、次の競合例を参照しています。

1. dbs1.example.comソース・データベースで次の更新が行われます。

UPDATE hr.employees SET salary = 4900 WHERE employee_id = 200;
COMMIT;

この更新によって、従業員200の給与が4400から4900に変更されます。

2. ほぼ同時に、dbs2.example.com宛先データベースで次の更新が行われます。

UPDATE hr.employees SET salary = 5000 WHERE employee_id = 200;
COMMIT;

3. 取得プロセスまたは同期取得は、dbs1.example.comソース・データベースで更新を取得し、結果の行LCRをキューに入れます。

4. 伝播はdbs1.example.comのキューからdbs2.example.comのキューに行LCRを伝播させます。

5. dbs2.example.comの適用プロセスは、行LCRをhr.employees表に適用しようとしますが、dbs2.example.comの給与値は5000であり、これは行LCR内の給与の元の値(4400)と一致しないため、競合が発生します。

ここでは、各ビルトイン競合ハンドラと、それぞれがこの競合をどのように解消するかについて説明します。

OVERWRITE

競合が発生すると、OVERWRITEハンドラは、宛先データベースの現行の値をソース・データベースからのLCR内の新規の値で置換します。

OVERWRITEハンドラを競合例のdbs2.example.com宛先データベースのhr.employees表に使用すると、行LCR内の新規の値によってdbs2.example.comの値が上書きされます。したがって、競合解消後は、従業員200の給与は4900となります。

DISCARD

競合が発生すると、DISCARDハンドラはソース・データベースからのLCR内の値を無視し、宛先データベースの値を保持します。

DISCARDハンドラを競合例のdbs2.example.com宛先データベースのhr.employees表に使用すると、行LCR内の新規の値が廃棄されます。したがって、競合解消後は、dbs2.example.comでの従業員200の給与は5000となります。

MAXIMUM

競合が発生すると、MAXIMUM競合ハンドラは、指定された解消列について、ソース・データベースからのLCRにある新規の値を、宛先データベース内の現行の値と比較します。LCRにある解消列の新規の値が宛先データベースの列の現行値より大きければ、適用プロセスではLCRを使用して競合が解消されます。LCRにある解消列の新規の値が宛先データベースの列の現行値より小さければ、適用プロセスでは宛先データベースを使用して競合が解消されます。

MAXIMUMハンドラを競合例のdbs2.example.com宛先データベースにあるhr.employees表のsalary列に使用すると、行LCRにある給与は表にある現行の給与より小さいため、適用プロセスでは行LCRは適用されません。したがって、競合解消後は、dbs2.example.comでの従業員200の給与は5000となります。

関係するトランザクションの時間ベースで競合を解消する場合は、トリガーを使用してトランザクションの時刻が自動的に記録されるように、共有表に列を追加する方法があります。この場合は、この列をMAXIMUM競合ハンドラ用の解消列として指定でき、最新(または最大)時刻を伴うトランザクションが自動的に使用されます。

ここでは、hr.employees表に対するトランザクションの時刻を記録するトリガーの例を示します。job_id、salaryおよびcommission_pct列は、競合解消ハンドラの列リストに含まれているとします。トリガーは、列リスト内の列に対してUPDATEが実行されるか、INSERTが実行された場合にのみ起動します。

ALTER TABLE hr.employees ADD (time TIMESTAMP WITH TIME ZONE);

CREATE OR REPLACE TRIGGER hr.insert_time_employees
BEFORE
INSERT OR UPDATE OF job_id, salary, commission_pct ON hr.employees
FOR EACH ROW
BEGIN
-- Consider time synchronization problems. The previous update to this
-- row might have originated from a site with a clock time ahead of the
-- local clock time.
IF :OLD.TIME IS NULL OR :OLD.TIME < SYSTIMESTAMP THEN
:NEW.TIME := SYSTIMESTAMP;
ELSE
:NEW.TIME := :OLD.TIME + 1 / 86400;
END IF;
END;
/

この種のトリガーを競合解消に使用する場合は、トリガーの起動プロパティがデフォルトの1回起動に設定されていることを確認してください。設定が異なると、適用プロセスによってトランザクションが適用されるときに新規時刻がマークされ、トランザクションの実際時刻が失われる可能性があります。

関連項目:
『Oracle Streams概要および管理』

MINIMUM

競合が発生すると、MINIMUM競合ハンドラは、指定された解消列について、ソース・データベースからのLCRにある新規の値を、宛先データベース内の現行の値と比較します。LCRにある解消列の新規の値が宛先データベースの列の現行値より小さければ、適用プロセスではLCRを使用して競合が解消されます。LCRにある解消列の新規の値が宛先データベースの列の現行値より大きければ、適用プロセスでは宛先データベースを使用して競合が解消されます。

MINIMUMハンドラを競合例のdbs2.example.com宛先データベースにあるhr.employees表のsalary列に使用すると、行LCRにある給与は表にある現行の給与より小さいため、適用プロセスでは行LCRを使用して競合が解消されます。したがって、競合解消後は、従業員200の給与は4900となります。

列リスト

表に対してビルトインの更新の競合ハンドラを指定するたびに、列リストを指定する必要があります。列リストは、更新の競合ハンドラがコールされる列のリストです。適用プロセスが行LCRを適用するときに、リスト内の1つ以上の列に更新の競合が発生すると、競合を解消するために更新の競合ハンドラがコールされます。リストにない列にのみ競合が発生した場合、更新の競合ハンドラはコールされません。競合解消の有効範囲は、1つの行LCRの1つの列リストです。

特定の表に対して更新の競合ハンドラを複数指定することはできますが、同じ列を複数の列リストに含めることはできません。たとえば、hr.employees表にビルトインの更新の競合ハンドラを2つ指定する場合を考えます。

- 最初の更新の競合ハンドラの列リストには、列salaryおよびcommission_pctを指定します。

- 2番目の更新の競合ハンドラの列リストには、列job_idおよびdepartment_idを指定します。

また、この表に他の競合ハンドラは存在しないものと想定します。この場合、適用プロセスが行LCRを適用するときにsalary列に競合が発生すると、それを解消するために最初の更新の競合ハンドラがコールされます。ただし、department_id列に競合が発生すると、それを解消するために2番目の更新の競合ハンドラがコールされます。どの競合ハンドラの列リストにもない列に競合が発生すると、競合ハンドラはコールされず、エラーになります。この例では、hr.employees表のmanager_id列に競合が発生すると、エラーになります。行LCRの適用時に複数の列リストに競合が発生し、列リストにない列での競合がなければ、競合が発生した列リストごとに適切な更新の競合ハンドラが起動されます。

列リストを使用すると、データ型ごとに異なるハンドラを使用して競合を解消できます。たとえば、通常、数値データにはMAXIMUMまたはMINIMUM競合ハンドラが適しており、文字データにはOVERWRITEまたはDISCARD競合ハンドラが適しています。

列リストにない列に競合が発生すると、表に対する特定の操作用のエラー・ハンドラがそれを解消しようとします。エラー・ハンドラが競合を解消できない場合や、この種のエラー・ハンドラがない場合は、競合の原因となったトランザクションがエラー・キューに移動されます。

また、OVERWRITE、MAXIMUMまたはMINIMUMビルトイン・ハンドラのいずれかを使用する列リスト内の列に競合が発生した場合に、この列リスト内のすべての列が行LCRに含まれていないと、使用可能でない値があるため、競合は解消できません。この場合は、競合の原因となったトランザクションがエラー・キューに移動されます。列リストでDISCARDビルトイン方法が使用されている場合は、行LCRにこの列リストのすべての列が含まれていない場合にも、行LCRが廃棄され、エラーは発生しません。

ソース・データベースの複数の列が宛先データベースの列リストに影響する場合は、列リストに指定された列に条件付きのサプリメンタル・ログ・グループを指定する必要があります。サプリメンタル・ロギングをソース・データベースで指定し、競合を正しく解消するために必要な情報をLCRに追加します。通常、列リスト内の列に条件付きのサプリメンタル・ログ・グループを指定する必要があるのは、列リストに列が複数存在する場合であり、列リストに存在する列が1つのみの場合は指定する必要ありません。

ただし、列リストに存在する列が1つのみの場合でも、条件付きのサプリメンタル・ログ・グループが必要になることがあります。つまり、適用ハンドラまたはカスタム・ルールベースの変換で、ソース・データベースからの複数列を宛先データベースの列リストの単一行に結合する場合です。たとえば、カスタム・ルールベースの変換で、通り、州および郵便番号を格納するソース・データベースからの3行を使用し、そのデータを宛先データベースで単一の住所列に結合する場合です。

また、列リストに存在する列が複数の場合でも、条件付きのサプリメンタル・ログ・グループが不要なことがあります。たとえば、適用ハンドラまたはカスタム・ルールベースの変換で、ソース・データベースからの単一の住所列を宛先データベースの列リストの複数行に分割する場合です。カスタム・ルールベースの変換で、ソース・データベースの1つの住所列(通り、州および郵便番号を含む)を取得し、そのデータを宛先データベースの3列に分割する場合です。

注意:
ビルトインの更新の競合ハンドラでは、LOB、LONG、LONG RAW、ユーザー定義型およびOracleが提供する型の列はサポートされません。したがって、SET_UPDATE_CONFLICT_HANDLERプロシージャを実行するときには、column_listパラメータにこれらの型の列を含めないでください。

関連項目:

- 「サプリメンタル・ロギングの指定」

- データ型の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

解消列

解消列は、ビルトインの更新の競合ハンドラの識別に使用される列です。ビルトインの更新の競合ハンドラMAXIMUMまたはMINIMUMを使用する場合は、解消列も競合の解消に使用されます。解消列は、ハンドラの列リスト内の列の1つである必要があります。

たとえば、hr.employees表のsalary列をMAXIMUMまたはMINIMUM競合ハンドラの解消列として指定すると、行LCR内の列リストの値を適用するか、宛先データベースにおける列リストの値を保持するかを判断するためにsalary列が評価されます。

競合に解消列が関係する次のどちらの状況でも、エラー・ハンドラで問題を解決できない場合は、適用プロセスは競合の原因となった行LCRを含むトランザクションをエラー・キューに移動します。これらの場合、競合は解消できず、宛先データベースの列の値がそのまま保持されます。

- 解消列について、新規のLCR値と宛先データベースの行の値が同一の場合(解消列が競合の原因となった列でない場合など)。

- 解消列の新規のLCR値、または宛先データベースの解消列の現行の値がNULLの場合。

注意:
解消列は、OVERWRITEおよびDISCARD競合ハンドラには使用されませんが、これらの競合ハンドラ用に指定する必要があります。

データ収束

複数のデータベース間でデータを共有しており、そのすべてでデータを同一にする必要がある場合は、すべてのデータベースでデータを収束させる競合解消ハンドラを使用してください。すべてのデータベースで共有データの変更を許可する場合、表のデータ収束が可能になるのは、データを共有する全データベースが共有データに対する変更を取得し、データを共有する他のすべてのデータベースにその変更を伝播する場合のみです。

このような環境では、MAXIMUM競合解消方法で収束を保証できるのは、解消列の値が常に増加する場合のみです。時間ベースの解消列は、1行の連続するタイムスタンプが個別である場合に、この要件を満たします。このような環境でMINIMUM競合解消方法によって収束を保証できるのは、解消列の値が常に減少する場合のみです。

カスタム競合ハンドラ

PL/SQLプロシージャを作成し、カスタム競合ハンドラとして使用できます。特定の表に1つ以上のカスタム競合ハンドラを指定するには、DBMS_APPLY_ADMパッケージのSET_DML_HANDLERプロシージャを使用します。特に、このプロシージャを実行してカスタム競合ハンドラを指定するときに、次のパラメータを設定します。

- object_nameパラメータを、競合解消の対象となる表の完全修飾された名前に設定します。

- object_typeパラメータをTABLEに設定します。

- operation_nameパラメータを、カスタム競合ハンドラのコール対象となる操作のタイプに設定します。可能な操作は、INSERT、UPDATE、DELETEおよびLOB_UPDATEです。また、デフォルトですべての操作をハンドラのコール対象にする場合は、operation_nameパラメータをDEFAULTに設定します。

- エラー・ハンドラでエラー発生時に競合解消を実行する場合は、error_handlerパラメータをTRUEに設定します。また、競合解消をプロシージャDMLハンドラに組み込む場合は、error_handlerパラメータをFALSEに設定します。
このパラメータをFALSEに設定した場合は、LCR用のEXECUTEメンバー・プロシージャを使用して行LCRを実行すると、指定したオブジェクトと操作に対してプロシージャDMLハンドラ内で競合解消が実行されます。

- user_procedureパラメータを設定して、競合解消用のプロシージャを指定します。このユーザー・プロシージャは、指定したタイプの操作によって指定した表に生じた競合を解消するためにコールされます。

カスタム競合ハンドラが競合を解消できない場合、適用プロセスは、競合を含むトランザクションをエラー・キューに移動し、そのトランザクションを適用しません。

特定のオブジェクトにビルトインの更新の競合ハンドラとカスタム競合ハンドラの両方が存在する場合は、次の両方の条件が満たされる場合にのみビルトインの更新の競合ハンドラが起動されます。

- カスタム競合ハンドラで、LCR用のEXECUTEメンバー・プロシージャを使用して行LCRが実行される場合。

- 行LCR用のEXECUTEメンバー・プロシージャのconflict_resolutionパラメータがTRUEに設定されている場合。

関連項目:

- エラー・ハンドラの管理の詳細は、『Oracle Streams概要および管理』を参照してください。

- SET_DML_HANDLERプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

Oracle Streamsの競合検出および解消の管理

この項では、次のタスクについて説明します。

- 更新の競合ハンドラの設定

- 既存の更新の競合ハンドラの変更

- 既存の更新の競合ハンドラの削除

- 非キー列の競合検出の停止

関連項目:
「更新の競合ハンドラに関する情報の表示」

更新の競合ハンドラの設定

更新の競合ハンドラを設定するには、DBMS_APPLY_ADMパッケージのSET_UPDATE_CONFLICT_HANDLERプロシージャを使用します。更新の競合解消ハンドラを作成する場合は、次のいずれかの事前作成方法を使用できます。

- OVERWRITE

- DISCARD

- MAXIMUM

- MINIMUM

たとえば、Oracle Streams環境のdbs1.example.comでhr.jobs表に対する変更を取得して、dbs2.example.com宛先データベースに伝播し、そこで適用する場合を考えます。この環境の場合、アプリケーションでは両方のデータベースのhr.jobs表に対してDML変更を実行できますが、特定のDML変更に競合がある場合は、dbs1.example.comデータベースでの変更でdbs2.example.comデータベースでの変更を常に上書きする必要があります。この環境では、dbs2.example.comデータベースでOVERWRITEハンドラを指定して、この目標を達成できます。

dbs2.example.comデータベースでhrスキーマ内のhr.jobs表について更新の競合ハンドラを指定するには、dbs2.example.comで次のプロシージャを実行します。

DECLARE
cols DBMS_UTILITY.NAME_ARRAY;
BEGIN
cols(1) := 'job_title';
cols(2) := 'min_salary';
cols(3) := 'max_salary';
DBMS_APPLY_ADM.SET_UPDATE_CONFLICT_HANDLER(
object_name       => 'hr.jobs',
method_name       => 'OVERWRITE',
resolution_column => 'job_title',
column_list       => cols);
END;
/

データベース上で実行中の、指定の表に変更を適用するすべての適用プロセスでは、指定した更新の競合ハンドラがローカルに使用されます。

注意:

- OVERWRITEおよびDISCARDメソッドにはresolution_columnは使用されませんが、column_list内の列の1つは指定する必要があります。

- 宛先データベースのcolumn_listにあるすべての列について、ソース・データベースで条件付きのサプリメンタル・ログ・グループを指定する必要があります。この例では、dbs1.example.comデータベースのhr.jobs表のjob_title、min_salaryおよびmax_salary列を含む条件付きのサプリメンタル・ログ・グループを指定します。

- ビルトインの更新の競合ハンドラでは、LOB、LONG、LONG RAW、ユーザー定義型およびOracleが提供する型の列はサポートされません。したがって、SET_UPDATE_CONFLICT_HANDLERプロシージャを実行するときには、column_listパラメータにこれらの型の列を含めないでください。

関連項目:

- 「サプリメンタル・ロギングの指定」

- 時間ベースの競合解消にMAXIMUM事前作成方法を使用するOracle Streams環境の例については、『Oracle Streams拡張例』を参照してください。

- データ型の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

既存の更新の競合ハンドラの変更

DBMS_APPLY_ADMパッケージのSET_UPDATE_CONFLICT_HANDLERプロシージャを実行すると、既存の更新の競合ハンドラを変更できます。既存の競合ハンドラを更新するには、そのハンドラと同じ表および解消列を指定します。

「更新の競合ハンドラの設定」で作成した更新の競合ハンドラを変更するには、hr.jobs表および解消列としてのjob_title列を指定します。この更新の競合ハンドラを変更するには、異なるタイプの事前作成方法または異なる列リスト、あるいはその両方を指定できます。ただし、更新の競合ハンドラの解消列を変更するには、ハンドラを削除して再作成する必要があります。

たとえば、環境に変更があり、競合が発生した場合にdbs1.example.comからの変更を廃棄する必要があるが、dbs1.example.comからの以前の変更によってdbs2.example.comの変更が上書きされている場合を考えます。dbs2.example.comデータベースでDISCARDハンドラを指定すると、この目標を達成できます。

dbs2.example.comデータベースでhrスキーマ内のhr.jobs表について既存の更新の競合ハンドラを変更するには、次のプロシージャを実行します。

DECLARE
cols DBMS_UTILITY.NAME_ARRAY;
BEGIN
cols(1) := 'job_title';
cols(2) := 'min_salary';
cols(3) := 'max_salary';
DBMS_APPLY_ADM.SET_UPDATE_CONFLICT_HANDLER(
object_name       => 'hr.jobs',
method_name       => 'DISCARD',
resolution_column => 'job_title',
column_list       => cols);
END;
/

既存の更新の競合ハンドラの削除

DBMS_APPLY_ADMパッケージのSET_UPDATE_CONFLICT_HANDLERプロシージャを実行すると、既存の更新の競合ハンドラを削除できます。既存の競合ハンドラを削除するには、メソッドにNULLを指定し、その競合ハンドラと同じ表、列リストおよび解消列を指定します。

たとえば、「更新の競合ハンドラの設定」で作成し、「既存の更新の競合ハンドラの変更」で変更した更新の競合ハンドラを削除する必要があるとします。この更新の競合ハンドラを削除するには、次のプロシージャを実行します。

DECLARE
cols DBMS_UTILITY.NAME_ARRAY;
BEGIN
cols(1) := 'job_title';
cols(2) := 'min_salary';
cols(3) := 'max_salary';
DBMS_APPLY_ADM.SET_UPDATE_CONFLICT_HANDLER(
object_name       => 'hr.jobs',
method_name       => NULL,
resolution_column => 'job_title',
column_list       => cols);
END;
/

非キー列の競合検出の停止

DBMS_APPLY_ADMパッケージのCOMPARE_OLD_VALUESプロシージャを使用すると、非キー列の競合検出を停止できます。

たとえば、hr.employees表の競合解消用にtime列を構成すると想定します(「MAXIMUM」を参照)。この場合、表の他の非キー列の競合検出を停止するように指定できます。これを行うには、time列を追加してトリガーを作成した後(前述の項を参照)、hr.employees表の列を更新の競合ハンドラの列リストに追加します。

DECLARE
cols  DBMS_UTILITY.NAME_ARRAY;
BEGIN
cols(1)  := 'first_name';
cols(2)  := 'last_name';
cols(3)  := 'email';
cols(4)  := 'phone_number';
cols(5)  := 'hire_date';
cols(6)  := 'job_id';
cols(7)  := 'salary';
cols(8)  := 'commission_pct';
cols(9)  := 'manager_id';
cols(10) := 'department_id';
cols(11) := 'time';
DBMS_APPLY_ADM.SET_UPDATE_CONFLICT_HANDLER(
object_name       => 'hr.employees',
method_name       => 'MAXIMUM',
resolution_column => 'time',
column_list       => cols);
END;
/

この例では、主キーに更新がないことを想定しているため、列リストに表の主キーは含まれていません。ただし、他のキー列は列リストに含まれています。

宛先データベースでUPDATEおよびDELETE操作の両方を行う表のすべての非キー列について、競合検出を停止するには、次のプロシージャを実行します。

DECLARE
cols DBMS_UTILITY.LNAME_ARRAY;
BEGIN
cols(1) := 'first_name';
cols(2) := 'last_name';
cols(3) := 'email';
cols(4) := 'phone_number';
cols(5) := 'hire_date';
cols(6) := 'job_id';
cols(7) := 'salary';
cols(8) := 'commission_pct';
DBMS_APPLY_ADM.COMPARE_OLD_VALUES(
object_name  => 'hr.employees',
column_table => cols,
operation    => '*',
compare      => FALSE);
END;
/

operationパラメータのアスタリスク(*)は、UPDATEおよびDELETE操作の両方について競合検出が停止されたことを意味します。このプロシージャを実行すると、データベース上で実行中の、指定の表に変更をローカルに適用するすべての適用プロセスでは、指定した列の競合は検出されません。したがって、この例では、time列のみが競合検出に使用されます。

注意:
この項の例では、更新の競合ハンドラを設定してから、非キー列の競合検出を停止しています。ただし、非キー列の競合検出を停止する前に、更新の競合ハンドラは必要ありません。

関連項目:

- 「非キー列の競合検出の制御」

- 「競合検出に関する情報の表示」

- 時間ベースの競合解消を使用する場合の詳細な例は、『Oracle Streams拡張例』を参照してください。

- COMPARE_OLD_VALUESプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

競合検出および更新の競合ハンドラの監視

ここでは、Streamsレプリケーション環境で適用プロセスを監視するために実行できる問合せについて説明します。

- 競合検出に関する情報の表示

- 更新の競合ハンドラに関する情報の表示

関連項目:
『Oracle Streams概要および管理』

競合検出に関する情報の表示

DBMS_APPLY_ADMパッケージのCOMPARE_OLD_VALUESプロシージャを使用すると、非キー列の競合検出を停止できます。このプロシージャを使用すると、宛先データベースのすべての適用プロセスについて、指定した列の更新および削除の競合検出が停止されます。競合検出が停止された各列を表示するには、次の問合せを実行します。

COLUMN OBJECT_OWNER HEADING 'Table Owner' FORMAT A15
COLUMN OBJECT_NAME HEADING 'Table Name' FORMAT A20
COLUMN COLUMN_NAME HEADING 'Column Name' FORMAT A20
COLUMN COMPARE_OLD_ON_DELETE HEADING 'Compare|Old On|Delete' FORMAT A7
COLUMN COMPARE_OLD_ON_UPDATE HEADING 'Compare|Old On|Update' FORMAT A7

SELECT OBJECT_OWNER,
OBJECT_NAME,
COLUMN_NAME,
COMPARE_OLD_ON_DELETE,
COMPARE_OLD_ON_UPDATE
FROM DBA_APPLY_TABLE_COLUMNS
WHERE APPLY_DATABASE_LINK IS NULL;

出力は次のようになります。

Compare Compare
Old On  Old On
Table Owner     Table Name           Column Name          Delete  Update
--------------- -------------------- -------------------- ------- -------
HR              EMPLOYEES            COMMISSION_PCT       NO      NO
HR              EMPLOYEES            EMAIL                NO      NO
HR              EMPLOYEES            FIRST_NAME           NO      NO
HR              EMPLOYEES            HIRE_DATE            NO      NO
HR              EMPLOYEES            JOB_ID               NO      NO
HR              EMPLOYEES            LAST_NAME            NO      NO
HR              EMPLOYEES            PHONE_NUMBER         NO      NO
HR              EMPLOYEES            SALARY               NO      NO

注意:
Oracle以外のリモート・データベースに適用される変更についての競合検出を停止することもできます。この問合せでは、APPLY_DATABASE_LINK列がNULLの場合にのみ指定が表示されるため、このような指定は表示されません。

関連項目:

- 「非キー列の競合検出の制御」

- 「非キー列の競合検出の停止」

更新の競合ハンドラに関する情報の表示

DBMS_APPLY_ADMパッケージのSET_UPDATE_CONFLICT_HANDLERプロシージャを使用して更新の競合ハンドラを指定した場合は、関連する競合が発生すると、そのハンドラがデータベース内のすべての適用プロセスに対して実行されます。

この項で説明する問合せを実行すると、ビルトインの更新の競合ハンドラを使用して競合解消が指定されている列がすべて表示されます。つまり、データベース内で指定されているすべての列リストの列が表示されます。また、この問合せでは、指定されているビルトインの競合ハンドラの型と、列リストに指定されている解消列も表示されます。

データベース内のすべての更新の競合ハンドラに関する情報を表示するには、次の問合せを実行します。

COLUMN OBJECT_OWNER HEADING 'Table|Owner' FORMAT A5
COLUMN OBJECT_NAME HEADING 'Table Name' FORMAT A12
COLUMN METHOD_NAME HEADING 'Method' FORMAT A12
COLUMN RESOLUTION_COLUMN HEADING 'Resolution|Column' FORMAT A13
COLUMN COLUMN_NAME HEADING 'Column Name' FORMAT A30

SELECT OBJECT_OWNER,
OBJECT_NAME,
METHOD_NAME,
RESOLUTION_COLUMN,
COLUMN_NAME
FROM DBA_APPLY_CONFLICT_COLUMNS
ORDER BY OBJECT_OWNER, OBJECT_NAME, RESOLUTION_COLUMN;

出力は次のようになります。

Table                           Resolution
Owner Table Name   Method       Column        Column Name
----- ------------ ------------ ------------- ------------------------------
HR    COUNTRIES    MAXIMUM      TIME          COUNTRY_NAME
HR    COUNTRIES    MAXIMUM      TIME          REGION_ID
HR    COUNTRIES    MAXIMUM      TIME          TIME
HR    DEPARTMENTS  MAXIMUM      TIME          DEPARTMENT_NAME
HR    DEPARTMENTS  MAXIMUM      TIME          LOCATION_ID
HR    DEPARTMENTS  MAXIMUM      TIME          MANAGER_ID
HR    DEPARTMENTS  MAXIMUM      TIME          TIME

関連項目:
「Oracle Streamsの競合検出および解消の管理」

10 Oracle Streamsタグ

この章では、Oracle Streamsタグに関連する概念について説明します。

この章の内容は次のとおりです。

- タグの概要

- DBMS_STREAMS_ADMパッケージによって作成されるタグとルール

- タグとオンライン・バックアップ文

- タグと適用プロセス

- レプリケーション環境のOracle Streamsタグ

- Oracle Streamsタグの管理

- Oracle Streamsタグの監視

関連項目:
「Oracle Streamsタグの管理」

タグの概要

REDOログの各REDOエントリには、タグが関連付けられています。タグのデータ型はRAWです。デフォルトでは、ユーザーまたはアプリケーションがREDOエントリを生成する時点では、各REDOエントリのタグの値はNULLであり、NULLタグは領域をコンシュームしません。タグ値のサイズの上限は2000バイトです。

タグ値の解析方法を構成できます。たとえば、タグを使用すると、LCRに含まれている変更の発生場所が、ローカル・データベースであるか他のデータベースであるかを判断できるため、変更の循環(発生場所となったデータベースへのLCRの送信)を回避できます。タグは他のLCRの追跡にも使用できます。また、タグを使用して、LCRごとに宛先データベースのセットを指定することもできます。

REDOログ内で生成されるタグの値を制御するには、次の方法があります。

- DBMS_STREAMS.SET_TAGプロシージャを使用して、現行のセッションで生成されるREDOタグの値を指定します。セッション中にデータベースに変更があると、タグはその変更を記録するREDOエントリの一部となります。様々なセッションで同じタグ設定または異なるタグ設定を使用できます。

- DBMS_APPLY_ADMパッケージのCREATE_APPLYまたはALTER_APPLYプロシージャを使用して、適用プロセスの実行時に生成されるREDOタグの値を制御します。このタグ設定は、適用プロセス・コーディネータによって調整されるすべてのセッションで使用されます。デフォルトでは、適用プロセスで生成されるREDOエントリのタグ値は、'00'(2つのゼロ)と等価の16進数です。

取得プロセスのルール・セットに含まれるルールに基づき、変更に関するREDOエントリ内のタグ値によって、変更が取得されるかどうかを判断できます。同期取得のルール・セットに含まれるルールに基づき、変更に関するセッション・タグの値によって、変更が取得されるかどうかを判断できます。タグは、取得プロセスまたは同期取得によって取得されるLCRの一部となります。

同様に、タグがLCRの一部になっている場合は、そのタグの値によって、伝播でLCRが伝播されるかどうかと、適用プロセスでLCRが適用されるかどうかを判別できます。カスタム・ルールベースの変換または適用ハンドラの動作も、タグの値に依存させることが可能です。また、PL/SQLプロシージャを使用するカスタム・ルールベースの変換または適用ハンドラで、LCR用のSET_TAGメンバー・プロシージャを使用すると、既存のLCRのタグ値を設定できます。文DMLハンドラまたは変更ハンドラでは、既存のLCRのタグ値を設定できません。

関連項目:

- LCR用のSET_TAGメンバー・プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- Oracle Streamsでルールを使用する方法の詳細は、『Oracle Streams概要および管理』を参照してください。

DBMS_STREAMS_ADMパッケージによって作成されるタグとルール

DBMS_STREAMS_ADMパッケージのプロシージャを使用してルールを作成し、include_tagged_lcrパラメータをFALSEに設定すると、タグがNULLの場合にのみTRUEと評価される条件が各ルールに含まれます。DMLルールの条件は、次のとおりです。

:dml.is_null_tag()='Y'

DDLルールの条件は、次のとおりです。

:ddl.is_null_tag()='Y'

ポジティブ・ルール・セットに1つのルールが含まれており、そのルールに前述の条件が含まれている場合を考えます。この場合、Oracle Streams取得プロセス、同期取得、伝播および適用プロセスの動作は次のようになります。

- 取得プロセスによって変更が取得されるのは、変更に関するREDOログ・エントリ内のタグがNULLで、かつ、他のルール条件が変更についてTRUEと評価される場合のみです。

- 同期取得によって変更が取得されるのは、変更が行われるセッションのタグがNULLで、かつ、他のルール条件が変更についてTRUEと評価される場合のみです。

- 伝播によってLCRが伝播されるのは、LCR内のタグがNULLで、かつ、他のルール条件がLCRについてTRUEと評価される場合のみです。

- 適用プロセスによってLCRが適用されるのは、LCR内のタグがNULLで、かつ、他のルール条件がLCRについてTRUEと評価される場合のみです。

また、ネガティブ・ルール・セットに1つのルールが含まれており、そのルールに前述の条件が含まれている場合を考えます。この場合、Oracle Streams取得プロセス、伝播および適用プロセスの動作は次のようになります。

- 取得プロセスによって変更が廃棄されるのは、変更に関するREDOログ・エントリ内のタグがNULLで、かつ、他のルール条件が変更についてTRUEと評価される場合のみです。

- 伝播または適用プロセスによってLCRが廃棄されるのは、LCR内のタグがNULLで、かつ、他のルール条件がLCRについてTRUEと評価される場合のみです。

ほとんどの場合、タグ値に関係なく変更が廃棄されるようにルールをネガティブ・ルール・セットに追加するときは、include_tagged_lcrパラメータにTRUEを指定します。

DBMS_STREAMS_ADMパッケージの次のプロシージャでは、デフォルトでこれらの条件のいずれかを含むルールが作成されます。

- ADD_GLOBAL_PROPAGATION_RULES

- ADD_GLOBAL_RULES

- ADD_SCHEMA_PROPAGATION_RULES

- ADD_SCHEMA_RULES

- ADD_SUBSET_PROPAGATION_RULES

- ADD_SUBSET_RULES

- ADD_TABLE_PROPAGATION_RULES

- ADD_TABLE_RULES

前述の条件を含むルールを作成しない場合は、これらのプロシージャを実行するときにinclude_tagged_lcrパラメータをTRUEに設定します。この設定を使用すると、タグに関する条件はルールに含まれません。したがって、データベースの変更のルール評価はタグの値に依存しないことになります。

たとえば、dbs1.example.comソース・データベースで実行されたhr.locations表に対するすべてのDML変更について、TRUEと評価される表ルールを考えます。

ADD_TABLE_RULESプロシージャを実行してこのルールを生成する場合を考えます。

BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
table_name               =>  'hr.locations',
streams_type             =>  'capture',
streams_name             =>  'capture',
queue_name               =>  'streams_queue',
include_tagged_lcr       =>  FALSE,  -- Note parameter setting
source_database          =>  'dbs1.example.com',
include_dml              =>  TRUE,
include_ddl              =>  FALSE);
END;
/

include_tagged_lcrパラメータがデフォルトのFALSEに設定されていることに注意してください。ADD_TABLE_RULESプロシージャでは、次のようなルール条件を持つルールが生成されます。

(((:dml.get_object_owner() = 'HR' and :dml.get_object_name() = 'LOCATIONS'))
and :dml.is_null_tag() = 'Y' and :dml.get_source_database_name() =
'DBS1.EXAMPLE.COM' )

取得プロセスでこのルールを含むポジティブ・ルール・セットを使用すると、REDOエントリ内の変更に関するタグの値が'0'や'1'などの非NULL値の場合に、ルールがFALSEと評価されます。そのため、REDOエントリにhr.locations表の1行の変更が含まれていると、変更が取得されるのはREDOエントリのタグがNULLの場合のみになります。

ただし、ここではADD_TABLE_RULESの実行時にinclude_tagged_lcrパラメータがTRUEに設定されているとします。

BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
table_name               =>  'hr.locations',
streams_type             =>  'capture',
streams_name             =>  'capture',
queue_name               =>  'streams_queue',
include_tagged_lcr       =>  TRUE,   -- Note parameter setting
source_database          =>  'dbs1.example.com',
include_dml              =>  TRUE,
include_ddl              =>  FALSE);
END;
/

この場合、ADD_TABLE_RULESプロシージャでは、次のようなルール条件を持つルールが生成されます。

(((:dml.get_object_owner() = 'HR' and :dml.get_object_name() = 'LOCATIONS'))
and :dml.get_source_database_name() = 'DBS1.EXAMPLE.COM' )

タグに関連する条件がないことに注意してください。取得プロセスでこのルールを含むポジティブ・ルール・セットを使用すると、hr.locations表に対するDML変更についてREDOエントリ内のタグの値が'0'や'1'などの非NULL値の場合に、ルールがTRUEと評価されます。また、このルールは、タグがNULLの場合にもTRUEと評価されます。そのため、REDOエントリにhr.locations表のDML変更が含まれている場合は、タグの値に関係なく変更が取得されます。

既存のシステム作成ルールのis_null_tag条件を変更するには、DBMS_STREAMS_ADMパッケージの適切なプロシージャを使用してルールを作成しますが、このルールは、is_null_tag条件を除き、変更するルールと同じである必要があります。次に、DBMS_STREAMS_ADMパッケージのREMOVE_RULEプロシージャを使用して、適切なルール・セットから古いルールを削除します。また、DBMS_STREAMS_ADMパッケージのルールを作成するプロシージャのand_conditionパラメータを使用して、タグに関連する条件をシステム作成ルールに追加できます。

DBMS_RULE_ADMパッケージでルールを作成した場合は、このパッケージのALTER_RULEプロシージャを使用して、is_null_tag条件を追加、削除または変更できます。

関連項目:

- DBMS_STREAMS_ADMパッケージのプロシージャで生成されるルールの例については、『Oracle Streams概要および管理』を参照してください。

- DBMS_STREAMS_ADMパッケージおよびDBMS_RULE_ADM.ALTER_RULEプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- SET_TAGプロシージャの詳細は、「適用プロセスで生成されるタグ値の設定」を参照してください。

タグとオンライン・バックアップ文

グローバル・ルールを使用していて、データベース全体に対するDDLの変更を取得および適用する場合は、デフォルトでオンライン・バックアップ文が取得され、伝播および適用されます。通常は、データベース管理者はオンライン・バックアップ文のレプリケートを行いません。かわりに、元々それらが実行されるデータベースで実行することのみを考慮します。オンライン・バックアップ文では、ALTER TABLESPACEまたはALTER DATABASE文のBEGIN BACKUPおよびEND BACKUP句が使用されます。

オンライン・バックアップ文のレプリケートの回避策として、次の方針のいずれかを使用できます。

- オンライン・バックアップ・プロシージャにDBMS_STREAMS.SET_TAGプロシージャへのコールを1つ以上含め、セッション・タグにオンライン・バックアップ文が取得プロセスで無視されるような値を設定します。

- 適用プロセスにDDLハンドラを使用し、オンライン・バックアップ文の適用を回避します。

注意:
Recovery Manager(RMAN)を使用してオンライン・バックアップを実行する場合、オンライン・バックアップ文は使用されないため、バックアップ用のOracle Streamsタグを設定する必要はありません。

関連項目:
バックアップを実行する方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

タグと適用プロセス

適用プロセスでは、DML変更またはDDL変更の適用時に、宛先データベースのREDOログにエントリが生成されます。たとえば、適用プロセスで表の1行を更新する変更が適用されると、その変更は宛先データベースのREDOログに記録されます。これらのREDOエントリ内のタグは、DBMS_APPLY_ADMパッケージのCREATE_APPLYまたはALTER_APPLYプロシージャのapply_tagパラメータを設定することで制御できます。たとえば、適用プロセスでは、'0'(ゼロ)または'1'の16進値と等価のREDOタグを生成できます。

適用プロセスによってREDOログ内で生成されるデフォルトのタグ値は'00'(2つのゼロ)です。この値は、DBMS_STREAMS_ADMパッケージのプロシージャまたはDBMS_APPLY_ADMパッケージのCREATE_APPLYプロシージャを使用して適用プロセスを作成した場合の、適用プロセス用のデフォルトのタグ値です。この値は、単に非NULL値であることを示します。非NULL値であることが重要なのは、DBMS_STREAMS_ADMパッケージによって作成されたルールには、デフォルトでREDOエントリまたはLCR内でタグがNULLの場合にのみTRUEと評価される条件が含まれているためです。既存の適用プロセスのタグ値は、DBMS_APPLY_ADMパッケージのALTER_APPLYプロシージャを使用して変更できます。

適用プロセスの適用ハンドラで生成されるREDOエントリには、SET_TAGプロシージャによってハンドラでタグに異なる値が設定される場合を除き、適用プロセスのタグ値が含まれます。プロシージャDMLハンドラ、DDLハンドラまたはメッセージ・ハンドラがDBMS_STREAMSパッケージのSET_TAGプロシージャをコールすると、ハンドラによって生成される後続のREDOエントリには、適用プロセスのタグが異なる場合にも、SET_TAGコールで指定されたタグが含まれます。ハンドラが終了すると、適用プロセスで生成される後続のREDOエントリには、適用プロセス用に指定されたタグが含まれます。

関連項目:

- 適用プロセスの詳細は、『Oracle Streams概要および管理』を参照してください。

- Oracle Streamsのルールに含まれるデフォルトのタグ条件の詳細は、「DBMS_STREAMS_ADMパッケージによって作成されるタグとルール」を参照してください。

- 「Oracle Streamsタグの管理」

- DBMS_STREAMS_ADMパッケージおよびDBMS_APPLY_ADMパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

レプリケーション環境のOracle Streamsタグ

複数のデータベースがデータを双方向で共有しているOracle Streams環境では、タグを使用して変更の循環を回避できます。変更の循環とは、変更が発生場所であるデータベースに再送されることです。通常は、それぞれの変更が無限ループを介して発生場所であるデータベースに送信される可能性があるため、変更の循環を回避する必要があります。このようなループがあると、データベースに意図しないデータが格納され、環境のネットワーキング・リソースとコンピュータ・リソースが過剰に使用される可能性があります。Oracle Streamsは、デフォルトで変更の循環を回避するように設計されています。

Oracle Streamsの取得プロセス、同期取得、伝播および適用プロセスにタグと適切なルールを使用すると、このような変更の循環を回避できます。ここでは、一般的なOracle Streams環境、およびそれらの環境でタグとルールを使用して変更の循環を回避する方法について説明します。

この項の内容は次のとおりです。

- n-wayレプリケーション環境

- ハブ・アンド・スポーク・レプリケーション環境

- 複数の拡張セカンダリ・データベースを含むハブ・アンド・スポーク・レプリケーション環境

n-wayレプリケーション環境

n-wayレプリケーション環境とは、各データベースが他のすべてのデータベースのソース・データベースと宛先データベースを兼ねているレプリケーション環境のことです。各データベースは、他の各データベースと直接通信します。

たとえば、hrmultスキーマ内のデータベース・オブジェクトとデータを、3つのOracle Database mult1.example.com、mult2.example.comおよびmult3.example.com間でレプリケートする環境を考えます。hrmultスキーマ内の表に対するDML変更とDDL変更は、この環境の3つのデータベースすべてで取得され、環境内の他の各データベースに伝播されて、そこで適用されます。図10-1に、n-wayレプリケーション環境の例を示します。

図10-1 各データベースがソース・データベースと宛先データベースを兼ねている場合

前述の環境を次のように構成すると、変更の循環を回避できます。

- 各データベースで、1つの適用プロセスを各ソース・データベースからの変更について非NULLのREDOタグを生成するように構成します。DBMS_STREAMS_ADMパッケージのプロシージャを使用して適用プロセスを作成すると、その適用プロセスでは、デフォルトでREDOログに値'00'を持つ非NULLのタグが生成されます。この場合は、それ以上の操作をしなくても、適用プロセスでは非NULLのタグが生成されます。
DBMS_APPLY_ADMパッケージのCREATE_APPLYプロシージャを使用して適用プロセスを作成する場合は、apply_tagパラメータを設定しないでください。この場合も、適用プロセスでは、デフォルトでREDOログに値'00'を持つ非NULLのタグが生成され、それ以上の操作は不要です。

- 各データベースの取得プロセスを、変更に関するREDOエントリ内のタグがNULLの場合にのみ、その変更を取得するように構成します。そのためには、取得プロセスで使用されるポジティブ・ルール・セットの各DMLルールに、次の条件が含まれていることを確認します。

:dml.is_null_tag()='Y'

各DDLルールには、次の条件が必要です。

:ddl.is_null_tag()='Y'

これらのルール条件は、変更のタグがNULLの場合にのみ取得プロセスで変更が取得されることを示します。DBMS_STREAMS_ADMパッケージを使用してルールを生成すると、各ルールにはデフォルトで前述の条件の1つが含まれます。

この構成では、適用プロセスによって適用されたすべての変更が再取得されることがないため(最初にソース・データベースで取得済であるため)、変更の循環が防止されます。各データベースからは、hrmultスキーマに対するすべての変更が他の各データベースに送信されます。そのため、この環境では変更が失われることはなく、すべてのデータベースが同期化されます。図10-2に、n-wayレプリケーション環境のデータベース内でタグを使用する方法を示します。

図10-2 各データベースがソース・データベースと宛先データベースを兼ねている場合のタグの使用

関連項目:
この例の詳細は、『Oracle Streams拡張例』を参照してください。

ハブ・アンド・スポーク・レプリケーション環境

ハブ・アンド・スポーク・レプリケーション環境とは、1つのプライマリ・データベース(ハブ)が複数のセカンダリ・データベース(スポーク)と通信するレプリケーション環境のことです。スポーク相互は直接通信しません。ハブ・アンド・スポーク・レプリケーション環境では、レプリケートされたデータベース・オブジェクトへの変更がスポークで許可されている場合と許可されていない場合があります。

レプリケートされたデータベース・オブジェクトへの変更がスポークで許可されていない場合は、プライマリ・データベースによって、共有データに対するローカルの変更が取得され、それがすべてのセカンダリ・データベースに伝播され、それぞれのセカンダリ・データベースでローカルに適用されます。レプリケートされたデータベース・オブジェクトへの変更は1つの場所でのみ取得されるため、レプリケートされたデータベース・オブジェクトへの変更がセカンダリ・データベースで許可されていない場合、変更の循環は発生しません。

レプリケートされたデータベース・オブジェクトへの変更がスポークで許可されている場合、変更は次のように取得、伝播および適用されます。

- プライマリ・データベースでは、共有データに対するローカルの変更が取得され、それがすべてのセカンダリ・データベースに伝播され、それぞれのセカンダリ・データベースでローカルに適用されます。

- それぞれのセカンダリ・データベースでは、共有データに対するローカルの変更が取得され、それがプライマリ・データベースにのみ伝播され、プライマリ・データベースでローカルに適用されます。

- プライマリ・データベースでは、それぞれのセカンダリ・データベースからの変更がローカルに適用されます。次に、これらの変更がプライマリ・データベースで取得され、変更の発生場所となったデータベースを除くすべてのセカンダリ・データベースに伝播されます。それぞれのセカンダリ・データベースでは、他のセカンダリ・データベースからの変更がプライマリ・データベースを経由してからローカルに適用されます。この構成は、適用による転送の一例です。
代替使用例では、キューによる転送を使用できます。この環境でキューによる転送を使用した場合、セカンダリ・データベースからの変更がプライマリ・データベースで適用されても、プライマリ・データベースでは取得されません。かわりに、これらの変更は、プライマリ・データベースのキューから、変更の発生場所となったデータベースを除くすべてのセカンダリ・データベースに転送されます。

関連項目:
適用による転送とキューによる転送の詳細は、『Oracle Streams概要および管理』を参照してください。

たとえば、1つのプライマリ・データベースps1.example.comと3つのセカンダリ・データベースps2.example.com、ps3.example.comおよびps4.example.com間で、hrスキーマ内のデータベース・オブジェクトとデータをレプリケートする環境を考えます。この環境では、hrスキーマ内の表に対するDML変更とDDL変更は、プライマリ・データベースと3つのセカンダリ・データベースで取得されます。次に、これらの変更が前述のとおり伝播され、適用されます。この環境では、プライマリ・データベースを介してセカンダリ・データベース間でデータを共有するために、キューによる転送ではなく適用による転送が使用されます。図10-3に、1つのプライマリ・データベースと複数のセカンダリ・データベースを含む環境の例を示します。

図10-3 プライマリ・データベースが複数のセカンダリ・データベースとデータを共有している場合

この環境を次のように構成すると、変更の循環を回避できます。

- プライマリ・データベースps1.example.comの各適用プロセスを、変更の送信元サイトを示す非NULLのREDOタグを生成するように構成します。この環境の場合、プライマリ・データベースには、変更の送信元となるセカンダリ・データベースごとに少なくとも1つは適用プロセスがあります。たとえば、プライマリ・データベースの適用プロセスは、ps2.example.comセカンダリ・データベースから変更を受信すると、適用するすべての変更について16進値'2'と等価のRAW値を生成できます。そのためには、DBMS_APPLY_ADMパッケージのCREATE_APPLYまたはALTER_APPLYプロシージャで、apply_tagパラメータを非NULL値に設定します。
たとえば、次のプロシージャを実行し、16進値'2'と等価のタグを持つREDOエントリを生成する適用プロセスを作成します。

BEGIN
DBMS_APPLY_ADM.CREATE_APPLY(
queue_name      => 'strmadmin.streams_queue',
apply_name      => 'apply_ps2',
rule_set_name   => 'strmadmin.apply_rules_ps2',
apply_tag       => HEXTORAW('2'),
apply_captured  => TRUE);
END;
/

- それぞれのセカンダリ・データベースで、非NULLのREDOタグを生成するように適用プロセスを構成します。タグの正確な値は、非NULLである場合は無関係です。この環境の場合、それぞれのセカンダリ・データベースには、プライマリ・データベースからの変更を適用する適用プロセスが1つあります。
DBMS_STREAMS_ADMパッケージのプロシージャを使用して適用プロセスを作成すると、その適用プロセスでは、デフォルトでREDOログに値'00'を持つ非NULLのタグが生成されます。この場合は、それ以上の操作をしなくても、適用プロセスでは非NULLのタグが生成されます。

たとえば、セカンダリ・データベースに適用プロセスが存在せず、各セカンダリ・データベースでDBMS_STREAMS_ADMパッケージのADD_SCHEMA_RULESプロシージャを実行して、16進値'00'と等価のタグを持つ非NULLのREDOエントリを生成する適用プロセスを作成する場合を考えます。

BEGIN
DBMS_STREAMS_ADM.ADD_SCHEMA_RULES(
schema_name     => 'hr',
streams_type    => 'apply',
streams_name    => 'apply',
queue_name      => 'strmadmin.streams_queue',
include_dml     => TRUE,
include_ddl     => TRUE,
source_database => 'ps1.example.com',
inclusion_rule  => TRUE);
END;
/

- プライマリ・データベースで、タグに関係なく共有データの変更を取得するように取得プロセスを構成します。そのためには、DBMS_STREAMS_ADMパッケージ内の取得プロセスのルールを生成するプロシージャの1つを実行するときに、include_tagged_lcrパラメータをTRUEに設定します。DBMS_RULE_ADMパッケージを使用してプライマリ・データベースの取得プロセスのルールを作成する場合は、is_null_tag条件がREDOログ内のタグが関係するため、作成するルールにこの条件が含まれないことを確認してください。
たとえば、プライマリ・データベースで次のプロシージャを実行し、DML取得プロセスのルールを1つとDDL取得プロセスのルールを1つ生成する場合を考えます。どちらのルールにも、hrスキーマ内の変更について、そのタグに関係なくTRUEと評価される条件が含まれているとします。

BEGIN
DBMS_STREAMS_ADM.ADD_SCHEMA_RULES(
schema_name         => 'hr',
streams_type        => 'capture',
streams_name        => 'capture',
queue_name          => 'strmadmin.streams_queue',
include_tagged_lcr  => TRUE, -- Note parameter setting
include_dml         => TRUE,
include_ddl         => TRUE,
inclusion_rule      => TRUE);
END;
/

- 各セカンダリ・データベースの取得プロセスを、変更に関するREDOエントリ内のタグがNULLの場合にのみ、その変更を取得するように構成します。そのためには、セカンダリ・データベースの取得プロセスで使用されるポジティブ・ルール・セットの各DMLルールに、次の条件が含まれていることを確認します。

:dml.is_null_tag()='Y'

各DDLルールには、次の条件が必要です。

:ddl.is_null_tag()='Y'

これらのルールは、変更のタグがNULLの場合にのみ取得プロセスで変更が取得されることを示します。DBMS_STREAMS_ADMパッケージを使用してルールを生成すると、各ルールにはデフォルトで前述の条件の1つが含まれます。DBMS_RULE_ADMパッケージを使用してセカンダリ・データベースの取得プロセスのルールを作成する場合は、各ルールに前述の条件の1つが含まれることを確認してください。

- プライマリ・データベースのキューからそれぞれのセカンダリ・データベースのキューへの伝播を1つ構成します。各伝播で使用するポジティブ・ルール・セットには、セカンダリ・データベースで発生した変更を除き、プライマリ・データベースのキューにあるすべてのLCRをセカンダリ・データベースのキューに伝播するように指示するルールを含める必要があります。
たとえば、伝播がセカンダリ・データベースps2.example.comに変更を伝播する場合に、そのタグが16進値'2'と等価であれば、伝播のルールでは、タグが'2'のLCRを除き、hrスキーマに関連するすべてのLCRをセカンダリ・データベースに伝播する必要があります。行LCRの場合は、この種のルールに次の条件を含める必要があります。

:dml.get_tag() IS NULL OR :dml.get_tag()!=HEXTORAW('2')

DDL LCRの場合は、この種のルールに次の条件を含める必要があります。

:ddl.get_tag() IS NULL OR :ddl.get_tag()!=HEXTORAW('2')

または、伝播でそのタグ値を持つLCRが廃棄されるように、伝播のネガティブ・ルール・セットにルールを追加できます。行LCRの場合は、この種のルールに次の条件を含める必要があります。

:dml.get_tag()=HEXTORAW('2')

DDL LCRの場合は、この種のルールに次の条件を含める必要があります。

:ddl.get_tag()=HEXTORAW('2')

DBMS_STREAMS_ADMパッケージのプロシージャでand_conditionパラメータを使用すると、これらの条件をシステム作成ルールに追加でき、DBMS_RULE_ADMパッケージのCREATE_RULEプロシージャを使用すると、これらの条件を持つルールを作成できます。and_conditionパラメータで条件を指定する場合は、:dmlまたは:ddlのかわりに:lcrを指定します。and_conditionパラメータの詳細は、『Oracle Streams概要および管理』を参照してください。

- それぞれのセカンダリ・データベースのキューからプライマリ・データベースのキューへの伝播を1つ構成します。セカンダリ・データベースの1つにあるキューには、適用プロセスによって行われた変更ではなく、そのデータベースでユーザー・セッションおよびアプリケーションによってローカルに行われた変更のみが含まれます。したがって、これらの伝播については、それ以上の構成は不要です。

この構成では、次の方法で変更の循環が防止されます。

- セカンダリ・データベースで発生した変更が、そのセカンダリ・データベースに再び伝播されることはありません。

- プライマリ・データベースで発生した変更が、そのプライマリ・データベースに再び伝播されることはありません。

- 環境内のどのデータベースで共有データに対して行われた変更も、すべて環境内の他の各データベースに伝播します。

そのため、この環境では変更が失われることはなく、すべてのデータベースが同期化されます。

図10-4に、プライマリ・データベースps1.example.comでのタグの使用方法を示します。

図10-4 プライマリ・データベースで使用されるタグ

図10-5に、セカンダリ・データベースの1つ(ps2.example.com)でのタグの使用方法を示します。

図10-5 セカンダリ・データベースで使用されるタグ

関連項目:
ハブ・アンド・スポーク・レプリケーション環境およびその構成例については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

複数の拡張セカンダリ・データベースを含むハブ・アンド・スポーク・レプリケーション環境

この環境では、1つのプライマリ・データベースが複数のセカンダリ・データベースとデータを共有しますが、セカンダリ・データベースにはリモート・セカンダリ・データベースと呼ばれる他のセカンダリ・データベースが接続されています。この環境は、「ハブ・アンド・スポーク・レプリケーション環境」で説明した環境が拡張されたものです。

レプリケートされたデータベース・オブジェクトへの変更がリモート・セカンダリ・データベースで許可されている場合、リモート・セカンダリ・データベースはプライマリ・データベースとデータを直接共有しません。かわりに、セカンダリ・データベースを介してプライマリ・データベースと間接的にデータを共有します。そのため、共有データはプライマリ・データベース、それぞれのセカンダリ・データベースおよびそれぞれのリモート・セカンダリ・データベースに存在します。これらのデータベースのいずれかで行われた変更は、他のすべてのデータベースで取得し、伝播できます。図10-6に、1つのプライマリ・データベースと複数の拡張セカンダリ・データベースを含む環境を示します。

図10-6 プライマリ・データベースと複数の拡張セカンダリ・データベース

この種の環境では、次の方法で変更の循環を回避できます。

- 「ハブ・アンド・スポーク・レプリケーション環境」で説明した例の場合と同様の方法で、プライマリ・データベースを構成します。

- 「ハブ・アンド・スポーク・レプリケーション環境」で説明した例でそれぞれのセカンダリ・データベースを構成した場合と同様の方法で、それぞれのリモート・セカンダリ・データベースを構成します。唯一の違いは、リモート・セカンダリ・データベースは、プライマリ・データベースではなくセカンダリ・データベースとデータを直接共有することです。

- それぞれのセカンダリ・データベースで、プライマリ・データベースからの変更のうち、16進値'00'と等価のREDOタグ値を持つ変更を適用するように、適用プロセスを1つ構成します。この値は、適用プロセスのデフォルトのタグ値です。

- それぞれのセカンダリ・データベースで、各リモート・セカンダリ・データベースからの変更のうち、そのリモート・セカンダリ・データベースに一意のREDOタグ値を持つ変更を適用するように、適用プロセスを1つ構成します。

- それぞれのセカンダリ・データベースの取得プロセスを、REDOログ内の共有データに対する変更を、そのタグ値に関係なくすべて取得するように構成します。

- それぞれのセカンダリ・データベースのキューからプライマリ・データベースのキューへの伝播を1つ構成します。伝播で使用するポジティブ・ルール・セットには、プライマリ・データベースで発生した変更を除き、セカンダリ・データベースのキューにあるすべてのLCRをプライマリ・データベースのキューに伝播するように指示するルールを含める必要があります。そのためには、LCR内のタグが'00'でない場合にのみTRUEと評価される条件をルールに追加します。たとえば、行LCRについて次のような条件を入力します。

:dml.get_tag() IS NULL OR :dml.get_tag()!=HEXTORAW('00')

DBMS_STREAMS_ADMパッケージのプロシージャでand_conditionパラメータを使用すると、この条件をシステム作成ルールに追加でき、DBMS_RULE_ADMパッケージのCREATE_RULEプロシージャを使用すると、この条件を持つルールを作成できます。and_conditionパラメータで条件を指定する場合は、:dmlまたは:ddlのかわりに:lcrを指定します。and_conditionパラメータの詳細は、『Oracle Streams概要および管理』を参照してください。

- それぞれのセカンダリ・データベースのキューからそれぞれのリモート・セカンダリ・データベースのキューへの伝播を1つ構成します。各伝播で使用するポジティブ・ルール・セットには、リモート・セカンダリ・データベースで発生した変更を除き、セカンダリ・データベースのキューにあるすべてのLCRをリモート・セカンダリ・データベースのキューに伝播するように指示するルールを含める必要があります。そのためには、LCR内のタグがリモート・セカンダリ・データベースのタグ値と異なる場合にのみTRUEと評価される条件をルールに追加します。
たとえば、リモート・セカンダリ・データベースのタグ値が16進値'19'と等価の場合は、行LCRについて次のような条件を入力します。

:dml.get_tag() IS NULL OR :dml.get_tag()!=HEXTORAW('19')

DBMS_STREAMS_ADMパッケージのプロシージャでand_conditionパラメータを使用すると、この条件をシステム作成ルールに追加でき、DBMS_RULE_ADMパッケージのCREATE_RULEプロシージャを使用すると、この条件を持つルールを作成できます。and_conditionパラメータで条件を指定する場合は、:dmlまたは:ddlのかわりに:lcrを指定します。and_conditionパラメータの詳細は、『Oracle Streams概要および管理』を参照してください。

この方法で環境を構成すると、変更の循環が防止され、どのデータベースで発生した変更も失われません。

関連項目:
ハブ・アンド・スポーク・レプリケーション環境およびその構成例については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

Oracle Streamsタグの管理

現行セッションまたは適用プロセスによって生成されるタグの値を設定または取得できます。ここでは、タグ値の設定方法と取得方法について説明します。

- 現行セッションのOracle Streamsタグの管理

- 適用プロセス用のOracle Streamsタグの管理

関連項目:
「Oracle Streamsタグの監視」

現行セッションのOracle Streamsタグの管理

この項では、現行セッション用のタグを設定する手順と取得する手順について説明します。

現行セッションで生成されるタグ値の設定

DBMS_STREAMSパッケージのSET_TAGプロシージャを使用すると、現行セッションで生成されるすべてのREDOエントリ用のタグを設定できます。たとえば、現行セッションでタグを'1D'の16進値に設定するには、次のプロシージャを実行します。

BEGIN
DBMS_STREAMS.SET_TAG(
tag  =>  HEXTORAW('1D'));
END;
/

このプロシージャを実行すると、現行セッションでDML文またはDDL文によって生成される各REDOエントリのタグ値は1Dになります。このプロシージャを実行すると、現行セッションにのみ影響します。

SET_TAGプロシージャに関する考慮事項は次のとおりです。

- このプロシージャは、トランザクション型ではありません。つまり、SET_TAGの影響はロールバックできません。

- SET_TAGプロシージャを実行して、データ・ディクショナリの構築をデータベースで実行する前に非NULLセッション・タグを設定する場合は、ディクショナリの構築前に開始されたトランザクションのREDOエントリに、そのセッションに指定されたタグ値が含まれない可能性があります。したがって、セッションでSET_TAGプロシージャを実行する前にデータ・ディクショナリの構築を実行します。データ・ディクショナリは、DBMS_CAPTURE_ADM.BUILDプロシージャの実行時に構築されます。BUILDプロシージャは、取得プロセスの作成時に自動的に実行できます。

現行セッションのタグ値の取得

DBMS_STREAMSパッケージのGET_TAGプロシージャを使用すると、現行セッションで生成されるすべてのREDOエントリ用のタグを取得できます。たとえば、現行セッションのREDOエントリに生成されるタグの16進値を取得するには、次のプロシージャを実行します。

SET SERVEROUTPUT ON
DECLARE
raw_tag RAW(2048);
BEGIN
raw_tag := DBMS_STREAMS.GET_TAG();
DBMS_OUTPUT.PUT_LINE('Tag Value = ' || RAWTOHEX(raw_tag));
END;
/

また、次のようにDUALビューを問い合せると、現行セッションのタグ値を表示できます。

SELECT DBMS_STREAMS.GET_TAG FROM DUAL;

適用プロセス用のOracle Streamsタグの管理

この項では、適用プロセス用のタグを設定する手順と削除する手順について説明します。

関連項目:

- 適用プロセスと適用ハンドラによるタグの使用方法の概要は、「タグと適用プロセス」を参照してください。

- 『Oracle Streams概要および管理』

適用プロセスで生成されるタグ値の設定

適用プロセスでは、変更をデータベースに適用するとき、またはハンドラを起動するときに、REDOエントリが生成されます。適用プロセスで生成される全REDOエントリ用のデフォルト・タグは、DBMS_APPLY_ADMパッケージのCREATE_APPLYプロシージャを使用して適用プロセスを作成するとき、またはDBMS_APPLY_ADMパッケージのALTER_APPLYプロシージャを使用して既存の適用プロセスを変更するときに設定できます。どちらのプロシージャでも、apply_tagパラメータを、適用プロセスで生成されるタグ用に指定する値に設定します。

たとえば、既存の適用プロセスstrep01_applyでREDOログに生成されるタグの値を'7'の16進値に設定するには、次のプロシージャを実行します。

BEGIN
DBMS_APPLY_ADM.ALTER_APPLY(
apply_name  =>  'strep01_apply',
apply_tag   =>  HEXTORAW('7'));
END;
/

このプロシージャを実行すると、適用プロセスで生成される各REDOエントリのタグ値が7になります。

適用プロセス用の適用タグの削除

適用プロセスの適用タグを削除するには、DBMS_APPLY_ADMパッケージのALTER_APPLYプロシージャで、remove_apply_tagパラメータをTRUEに設定します。適用タグを削除すると、適用プロセスで生成される各REDOエントリのタグはNULLになります。たとえば、次のプロシージャでは、適用プロセスstrep01_applyから適用タグが削除されます。

BEGIN
DBMS_APPLY_ADM.ALTER_APPLY(
apply_name       => 'strep01_apply',
remove_apply_tag => TRUE);
END;
/

Oracle Streamsタグの監視

ここでは、現行セッション用のOracle Streamsタグと各適用プロセス用のデフォルト・タグを表示するために実行できる問合せについて説明します。

- 現行セッション用のタグ値の表示

- 各適用プロセス用のデフォルトのタグ値の表示

関連項目:

- 「Oracle Streamsタグの管理」

- DBMS_STREAMSパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

現行セッション用のタグ値の表示

次のようにDUALビューを問い合せると、現行セッションについてすべてのREDOエントリ内で生成されたタグ値を表示できます。

SELECT DBMS_STREAMS.GET_TAG FROM DUAL;

出力は次のようになります。

GET_TAG
--------------------------------------------------------------------------------
1D

また、DBMS_STREAMS.GET_TAGファンクションをコールすると、セッション用のタグを判断できます。

各適用プロセス用のデフォルトのタグ値の表示

DBA_APPLYデータ・ディクショナリ・ビューでAPPLY_TAGの値を問い合せると、各適用プロセスによって生成されるすべてのREDOエントリのデフォルト・タグを取得できます。たとえば、各適用プロセスによってREDOエントリ内で生成されるデフォルト・タグの16進値を取得するには、次の問合せを実行します。

COLUMN APPLY_NAME HEADING 'Apply Process Name' FORMAT A30
COLUMN APPLY_TAG HEADING 'Tag Value' FORMAT A30

SELECT APPLY_NAME, APPLY_TAG FROM DBA_APPLY;

出力は次のようになります。

Apply Process Name             Tag Value
------------------------------ ------------------------------
APPLY_FROM_MULT2               00
APPLY_FROM_MULT3               00

適用プロセスに関連付けられているハンドラまたはカスタム・ルールベースの変換ファンクションでは、DBMS_STREAMS.GET_TAGファンクションをコールしてタグを取得できます。

11 Oracle Streamsの異機種間での情報の共有

この章では、Oracle DatabaseとOracle以外のデータベースの間で情報を共有するための、Oracle Streamsのサポートに関連する概念について説明します。

この章の内容は次のとおりです。

- Oracle Streamsを使用したOracleからOracle以外のデータベースへのデータの共有

- Oracle Streamsを使用したOracle以外のデータベースからOracle Databaseへのデータの共有

- Oracle Streamsを使用したOracle以外のデータベース間でのデータの共有

注意:
新機能のXStreamは、Oracle Database 11g リリース2(11.2)以上で使用できます。XStreamを使用すると、Oracle CallインタフェースおよびJavaアプリケーションが、ストリーム内のデータベースの変更にアクセス可能になります。XStreamの詳細は、Oracle Database XStreamについてのマニュアルを参照してください。

Oracle Streamsを使用したOracleからOracle以外のデータベースへのデータの共有

Oracleソース・データベースからOracle以外の宛先データベースへとDML変更を共有するために、Oracle Databaseはプロキシとして機能し、通常は宛先データベースで実行される手順の一部を実行します。つまり、Oracle以外の宛先データベースを対象とするLCRは、Oracle Database自体でデキューされ、Oracle Databaseの適用プロセスはOracle Database Gatewayを介してネットワーク接続経由で変更をOracle以外のデータベースに適用します。図11-1に、Oracle以外のデータベースとデータを共有しているOracle Databaseを示します。

図11-1 OracleからOracle以外のデータベースへの異機種間データ共有

Oracle Database Gatewayを構成してトランザクション・モデルCOMMIT_CONFIRMを使用する必要があります。

関連項目:
Oracle Database Gatewayのトランザクション・モデルCOMMIT_CONFIRMを使用する方法の詳細は、Oracle Database Gateway固有のOracleマニュアルを参照してください。

OracleからOracle以外への環境での変更の取得とステージング

OracleからOracle以外への環境では、取得プロセスまたは同期取得はOracleのみの環境の場合と同様に動作します。つまり、取得プロセスは、REDOログ内で変更を検索し、それを取得プロセスのルールに基づいて取得し、取得された変更をANYDATAキューに論理変更レコード(LCR)としてエンキューします。同期取得は、内部メカニズムを使用して、同期取得のルールに基づいて変更を取得し、取得された変更をANYDATAキューに行LCRとしてエンキューします。また、1つの取得プロセスまたは同期取得で、Oracle DatabaseとOracle以外のデータベースの両方で適用される変更を取得できます。

同様に、LCRをステージングするANYDATAキューは、Oracleのみの環境の場合と同様に動作します。Oracle以外のデータベースで適用される前に、Oracle Database内の任意の数の中間キューにLCRを伝播させることができます。

関連項目:

- 取得プロセス、同期取得、ステージングおよび伝播の概要は、『Oracle Streams概要および管理』を参照してください。

- Oracle Streamsレプリケーション環境の取得プロセス、同期取得、ステージングおよび伝播の詳細は、第1章「Oracle Streamsレプリケーションの準備」を参照してください。

OracleからOracle以外への環境での変更の適用

Oracle Database内で実行される適用プロセスは、異機種間サービスとOracle Database Gatewayを使用して、LCRにカプセル化された変更をOracle以外のデータベース内のデータベース・オブジェクトに直接適用します。LCRは、OracleのみのOracle Streams環境の場合のようには、Oracle以外のデータベース内のキューに伝播しません。かわりに、変更は適用プロセスによってデータベース・リンクを介してOracle以外のデータベースに直接適用されます。

注意:
Oracle Streamsの適用プロセスでは、Generic Connectivityはサポートされていません。

関連項目:
『Oracle Streams概要および管理』

OracleからOracle以外への環境での適用プロセスの構成

この項では、変更をOracle以外のデータベースに適用する適用プロセスの構成について説明します。

OracleとOracle以外の環境で適用プロセスを作成する前に

Oracle以外のデータベースに変更を適用する適用プロセスを作成する前に、異機種間サービス、Oracle Database Gatewayおよびデータベース・リンクを構成します。

Oracle Streamsでは、次のOracle Database Gatewaysがサポートされます。

- Oracle Database Gateway for Sybase

- Oracle Database Gateway for Informix

- Oracle Database Gateway for SQL Server

- Oracle Database Gateway for DRDA

データベース・リンクは、Oracle以外のデータベースに変更を適用するために、適用プロセスで使用されます。データベース・リンクの作成には、明示的なCONNECT TO句を使用してください。

関連項目:

- 異機種間サービスとOracle Database Gatewayの詳細は、『Oracle Database Heterogeneous Connectivityユーザーズ・ガイド』を参照してください。

- Oracle Database GatewayのOracleマニュアルを参照してください。

OracleとOracle以外への環境での適用プロセスの作成

データベース・リンクを作成済で、正常に動作している場合は、DBMS_APPLY_ADMパッケージのCREATE_APPLYプロシージャを使用して適用プロセスを作成し、apply_database_linkパラメータにデータベース・リンクを指定します。適用プロセスの作成後は、そのルールを使用してOracle以外のデータベースで適用する変更を指定できます。

関連項目:

- DBMS_APPLY_ADMパッケージのプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- 適用プロセスのルールを指定する方法は、『Oracle Streams概要および管理』を参照してください。

OracleからOracle以外への異機種間環境での代替キー列

Oracle以外のデータベースでいずれかの表に代替キー列を使用する場合は、DBMS_APPLY_ADMパッケージのSET_KEY_COLUMNSプロシージャを実行するときに、そのデータベースへのデータベース・リンクを指定します。

関連項目:
『Oracle Streams概要および管理』

OracleからOracle以外への異機種間環境での並列性

適用プロセスでOracle以外のデータベースに変更を適用する場合は、parallelism適用プロセス・パラメータをデフォルト設定の1に設定する必要があります。現在、Oracle以外のデータベースへのパラレル適用はサポートされていません。ただし、複数の適用プロセスを使用すると、Oracle以外のデータベースに変更を適用できます。

OracleからOracle以外への異機種間環境でのプロシージャDMLハンドラ

プロシージャDMLハンドラを使用してOracle以外のデータベースでいずれかの表の行LCRを処理する場合は、DBMS_APPLY_ADMパッケージのSET_DML_HANDLERプロシージャを実行するときに、そのデータベースへのデータベース・リンクを指定します。

関連項目:
適用プロセスのメッセージ処理オプションの詳細は、『Oracle Streams概要および管理』を参照してください。

OracleからOracle以外への異機種間環境でのメッセージ・ハンドラ

メッセージ・ハンドラを使用してOracle以外のデータベース用のユーザー・メッセージを処理する場合は、DBMS_APPLY_ADMパッケージのCREATE_APPLYプロシージャを実行するときに、apply_database_linkパラメータを使用してそのデータベースへのデータベース・リンクを指定し、message_handlerパラメータを使用してメッセージ・ハンドラ・プロシージャを指定します。

関連項目:
メッセージ処理オプションおよびメッセージ・ハンドラの管理の詳細は、『Oracle Streams概要および管理』を参照してください。

OracleからOracle以外への異機種間環境でのエラーおよび競合ハンドラ

現在、Oracle DatabaseからOracle以外のデータベースへとデータを共有する場合、エラー・ハンドラと競合ハンドラはサポートされていません。適用エラーが発生すると、エラーの原因となったLCRを含むトランザクションは、Oracle Databaseのエラー・キューに移動します。

Oracle以外のデータベースで適用されるデータ型

変更をOracle以外のデータベースに適用する場合、適用プロセスでは次のデータ型の列に対する変更のみが適用されます。

- CHAR

- VARCHAR2

- NCHAR

- NVARCHAR2

- NUMBER

- DATE

- RAW

- TIMESTAMP

- TIMESTAMP WITH TIME ZONE

- TIMESTAMP WITH LOCAL TIME ZONE

- INTERVAL YEAR TO MONTH

- INTERVAL DAY TO SECOND

適用プロセスでは、データ型のうちCLOB、NCLOB、BLOB、BFILE、LONG、LONG RAW、ROWID、UROWID、ユーザー定義型(オブジェクト型、REF、VARRAY、NESTED TABLEなど)およびOracleが提供する型(ANY型、XML型、空間型、メディア型など)の列における変更は、Oracle以外のデータベースには適用されません。これ以外のデータ型がLCRに含まれている場合、適用プロセスにエラーが発生し、エラーの原因となったLCRを含むトランザクションがOracle Databaseのエラー・キューに移動します。

各Oracle Database Gatewayは、データ型に関してさらに制限を伴う場合があります。あるデータ型がOracleからOracle以外への環境でサポートされるには、そのデータ型がOracle Streamsと使用するOracle Database Gatewayの両方でサポートされる必要があります。

関連項目:

- これらのデータ型の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- Oracle Database Gateway固有のOracleマニュアルを参照してください。

Oracle以外のデータベースで適用されるDML変更のタイプ

特定の表に対するDML変更をOracle以外のデータベースで適用するように指定する場合、適用プロセスで適用できるのは次のタイプのDML変更のみです。

- INSERT

- UPDATE

- DELETE

注意:
適用プロセスでDDL変更をOracle以外のデータベースで適用することはできません。

OracleからOracle以外への環境でのインスタンス化

変更をOracle以外のデータベースに適用する適用プロセスを起動する前に、次の手順に従って、そのデータベースで各表をインスタンス化します。

1. DBMS_HS_PASSTHROUGHパッケージまたはOracle以外のデータベースに用意されているツールを使用して、Oracle以外のデータベースで表を作成します。
次の例では、DBMS_HS_PASSTHROUGHパッケージを使用して、Oracle以外のデータベースhet.example.com内でhr.regions表を作成します。

DECLARE
ret INTEGER;
BEGIN
ret := DBMS_HS_PASSTHROUGH.EXECUTE_IMMEDIATE@het.example.com (
'CREATE TABLE regions (region_id INTEGER, region_name VARCHAR(50))');
END;
/
COMMIT;

関連項目:
異機種間サービスとOracle Database Gatewayの詳細は、『Oracle Database Heterogeneous Connectivityユーザーズ・ガイド』とOracle Database Gateway固有のOracleマニュアルを参照してください。

2. Oracle DatabaseとOracle以外のデータベース間で共有される変更がOracle Database側の取得プロセスまたは同期取得によって取得される場合は、データを共有予定の表すべてをインスタンス化のために準備します。

関連項目:
「ソース・データベースでインスタンス化を行うためのデータベース・オブジェクトの準備」

3. 次のアクションを実行するPL/SQLプロシージャ(またはCプログラム)を作成します。

- DBMS_FLASHBACKパッケージのGET_SYSTEM_CHANGE_NUMBERファンクションを使用し、現行のSCNを取得する。

- DBMS_FLASHBACKパッケージのENABLE_AT_SYSTEM_CHANGE_NUMBERプロシージャを起動し、取得されたSCNを現行セッションに設定する。このアクションによって、すべてのフェッチが同じSCNを使用して実行されることが確実になります。

- Oracle Databaseの表から行を1行ずつフェッチしてOracle以外のサイトの表に移入することにより、Oracle以外のデータベースの表に対する挿入を行う。すべてのフェッチは、GET_SYSTEM_CHANGE_NUMBERファンクションを使用して取得されたSCNで実行する必要があります。

たとえば、次のPL/SQLプロシージャでは、フラッシュバックSCNを取得し、現行のOracle Database内のhr.regions表の各行をフェッチして、Oracle以外のデータベースhet.example.com内のhr.regions表に挿入しています。Oracle以外のデータベースに行が挿入される前に、フラッシュバックが無効化されていることに注意してください。

SET SERVEROUTPUT ON
CREATE OR REPLACE PROCEDURE insert_reg IS
CURSOR c1 IS
SELECT region_id, region_name FROM hr.regions;
c1_rec c1 % ROWTYPE;
scn NUMBER;
BEGIN
scn := DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER();
DBMS_FLASHBACK.ENABLE_AT_SYSTEM_CHANGE_NUMBER(
query_scn  =>  scn);
/* Open c1 in flashback mode */
OPEN c1;
/* Disable Flashback */
DBMS_FLASHBACK.DISABLE;
LOOP
FETCH c1 INTO c1_rec;
EXIT WHEN c1%NOTFOUND;
/*
Note that all the DML operations inside the loop are performed
with Flashback disabled
*/
INSERT INTO hr.regions@het.example.com VALUES (
c1_rec.region_id,
c1_rec.region_name);
END LOOP;
COMMIT;
DBMS_OUTPUT.PUT_LINE('SCN = ' || scn);
EXCEPTION WHEN OTHERS THEN
DBMS_FLASHBACK.DISABLE;
RAISE;
END;
/

戻されたSCNをメモします。

使用しているOracle Database Gatewayで異機種間サービスのコールバック機能がサポートされている場合、次のSQL文で前述の例のループを置換できます。

INSERT INTO hr.region@het.example.com SELECT * FROM hr.region@!;

注意:
前述の例のプロシージャを作成および実行するユーザーには、DBMS_FLASHBACKパッケージについてのEXECUTE権限と、関連する表についてのすべての権限が必要です。

関連項目:
コールバック機能とOracle Database Gatewayの詳細は、『Oracle Database Heterogeneous Connectivityユーザーズ・ガイド』とOracle Database Gateway固有のOracleマニュアルを参照してください。

4. Oracle以外のデータベースで表のインスタンス化SCNを設定します。DBMS_APPLY_ADMパッケージのSET_TABLE_INSTANTIATION_SCNプロシージャに対して手順3で取得されたSCNを指定し、手順3で取得されたSCNより前に発生した変更を含むLCRをすべてスキップするように、適用プロセスへ指示します。apply_database_linkパラメータを、Oracle以外のリモート・データベース用のデータベース・リンクに設定してください。

関連項目:
SET_TABLE_INSTANTIATION_SCNプロシージャの詳細は、「宛先データベースでのインスタンス化SCNの設定」および『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

OracleからOracle以外への環境での変換

OracleからOracle以外への環境での変換では、Oracleのみの環境の場合と同様に、取得または適用中のルールベースの変換を指定できます。また、LCRをOracle以外のデータベースに適用する前に、1つ以上のOracle中間データベースに伝播させる場合は、Oracle DatabaseのキューからOracle Databaseの他のキューへの伝播中に、ルールベースの変換を指定できます。

関連項目:
ルールベースの変換の詳細は、『Oracle Streams概要および管理』を参照してください。

メッセージ・ゲートウェイとOracle Streams

メッセージ・ゲートウェイはOracle Databaseの機能であり、OracleキューとOracle以外のメッセージ・キューイング・システムの間の伝播を提供します。OracleキューにエンキューされたメッセージはOracle以外のキューに自動的に伝播され、Oracle以外のキューにエンキューされたメッセージはOracleキューに自動的に伝播されます。この機能では、Oracle以外のメッセージ・システムへの保証付きメッセージ配信が提供され、Oracle以外のメッセージ・システムについてはシステム固有のメッセージ・フォーマットがサポートされます。また、OracleキューからOracle以外のメッセージ・システムへ、またはOracle以外のメッセージ・システムからOracleキューへの伝播中に起動される、ユーザー定義変換の仕様もサポートされます。

関連項目:
メッセージ・ゲートウェイの詳細は、『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイド』を参照してください。

OracleからOracle以外への環境でのエラー処理

Oracle以外のデータベースでLCRを適用するときに適用プロセスに未処理エラーが発生すると、そのLCRを含むトランザクションは、適用プロセスを実行中のOracle Databaseにあるエラー・キューに置かれます。適用プロセスは、Oracleのみの環境の場合と同様にデータ競合を検出しますが、現在、OracleからOracle以外への環境では、自動競合解消はサポートされていません。したがって、発生したデータ競合は適用エラーとして処理されます。

OracleからOracle以外へのStreams環境の例

OracleからOracle以外へのStreams環境内のデータ共有を含む詳細な例は、『Oracle Streams拡張例』を参照してください。

Oracle Streamsを使用したOracle以外のデータベースからOracleへのデータの共有

Oracle以外のデータベースから変更を取得してOracle Databaseに伝播させるには、カスタム・アプリケーションが必要です。このアプリケーションは、トランザクション・ログを読み込むか、トリガーを使用するか、または他のなんらかの方法で、Oracle以外のデータベースに対する変更を取得します。このアプリケーションではトランザクションをアセンブルし、順序付けし、それぞれの変更を論理変更レコード(LCR)に変換する必要があります。次に、アプリケーションでDBMS_STREAMS_MESSAGINGパッケージまたはDBMS_AQパッケージを使用して、LCRをOracle Databaseにエンキューします。アプリケーションは、各トランザクションのLCRをすべてエンキューした後にコミットする必要があります。図11-2に、Oracle Databaseとデータを共有しているOracle以外のデータベースを示します。

図11-2 Oracle以外のデータベースからOracle Databaseへの異機種間データ共有

Oracle以外からOracleへの環境での変更の取得

カスタム・ユーザー・アプリケーションでは、Oracle以外のデータベースでの変更をLCRにアセンブルし、LCRをOracle Databaseにエンキューする必要があるため、変更の取得全体を受け持つことになります。したがって、アプリケーションではOracle以外のデータベースで変更を表すLCRを構成し、そのLCRをOracle Databaseのキューにエンキューする必要があります。アプリケーションでは、同時に複数のトランザクションをエンキューできますが、Oracle以外のソース・データベースのトランザクションと同じ順序で、トランザクションがコミットされる必要があります。

関連項目:
LCRを構成およびエンキューする方法の詳細は、「LCRの構成とエンキュー」を参照してください。

Oracle以外からOracleへの環境でのステージング

変更が適用されるOracle Databaseと変更が発生するOracle以外のデータベースの両方で、同じトランザクション一貫性を確保するには、トランザクション型のキューを使用してOracle DatabaseでLCRをステージングしてください。たとえば、1つのトランザクションに3行の変更が含まれており、カスタム・アプリケーションでは変更ごとに1つずつ合計3つの行LCRをエンキューしてからコミットする場合を考えます。トランザクション型のキューを使用すると、3番目の行LCRの後で適用プロセスによってコミットが実行され、トランザクションの一貫性が保持されます。非トランザクション型のキューを使用すると、コミットは適用プロセスによって行LCRごとに実行されます。DBMS_STREAMS_ADMパッケージのSET_UP_QUEUEプロシージャでは、自動的にトランザクション型のキューが作成されます。

また、Oracle Databaseのキューはコミット時間キューである必要があります。コミット時間キューでは、LCRを含むトランザクションのおおよそのコミット・システム変更番号(おおよそのCSCN)によってLCRが順序付けされます。LCRをエンキューしたアプリケーションで、トランザクションが正しい順序でコミットされる場合、コミット時間キューでは、キュー内のLCR間で、トランザクション間の依存性による順序付けが保持されます。また、コミット時間キューによって、キュー内のLCRの一貫性のある参照が保証されます。

関連項目:
トランザクション型のキューとコミット時間キューの詳細は、『Oracle Streams概要および管理』を参照してください。

Oracle以外からOracleへの環境での変更の適用

Oracle以外からOracleへの環境では、適用プロセスはOracleのみの環境の場合と同様に動作します。つまり、各LCRは適用プロセスのルールに基づいて関連付けられたキューからデキューされ、ルールベースの変換が実行され、LCRがハンドラに送信されるか、または直接適用されます。エラー処理と競合解消の動作も、Oracleのみの環境の場合と同じです。そのため、ビルトインの更新の競合ハンドラを指定するか、カスタム競合ハンドラを作成して競合を解消できます。

適用プロセスは、取得LCRではなく永続LCRを適用するように構成する必要があります。そのため、適用プロセスはDBMS_APPLY_ADMパッケージのCREATE_APPLYプロシージャを使用して作成する必要があり、このプロシージャを実行するときは、apply_capturedパラメータをFALSEに設定する必要があります。適用プロセスの作成後に、DBMS_STREAMS_ADMパッケージのプロシージャを使用して、適用プロセスのルール・セットにLCRのルールを追加できます。

関連項目:

- 適用プロセス、ルールおよびルールベースの変換の詳細は、『Oracle Streams概要および管理』を参照してください。

- 第9章「Oracle Streamsの競合解消」

Oracle以外のデータベースからOracle Databaseへのインスタンス化

Oracle以外のデータベースに存在する表を、Oracle Databaseで自動的にインスタンス化する方法はありません。ただし、次の一般的な手順に従って表を手動でインスタンス化できます。

1. Oracle以外のデータベースで、Oracle以外のユーティリティを使用して表をフラット・ファイルにエクスポートします。

2. Oracle Databaseで、Oracle以外のデータベースにある表と一致する空の表を作成します。

3. Oracle Databaseで、SQL*Loaderを使用してフラット・ファイルの内容を表にロードします。

関連項目:
SQL*Loaderの使用については、『Oracle Databaseユーティリティ』を参照してください。

Oracle Streamsを使用したOracle以外のデータベース間でのデータの共有

Oracle Streamsでは、Oracle以外の2つのデータベース間でのデータ共有が、Oracle以外からOracleへのデータ共有とOracleからOracle以外へのデータ共有の組合せを介してサポートされます。この種の環境では、Oracle以外の2つのデータベース間に位置する中間データベースとして、Oracle Database内でOracle Streamsが使用されます。

たとえば、Oracle以外からOracle以外への環境は、次のデータベースで構成されている場合があります。

- Oracle以外のデータベースhet1.example.com

- Oracle Database dbs1.example.com

- Oracle以外のデータベースhet2.example.com

ユーザー・アプリケーションでは、het1.example.comでの変更をアセンブルし、それをdbs1.example.comにエンキューします。次に、dbs1.example.comの適用プロセスが、異機種間サービスとOracle Database Gatewayを使用して変更をhet2.example.comに適用します。dbs1.example.comの別の適用プロセスは、dbs1.example.comでキューにある一部またはすべての変更をローカルに適用できます。dbs1.example.comの1つ以上の伝播は、キューにある一部またはすべての変更を他のOracle Databaseに伝播できます。

第II部

Oracle Streamsレプリケーションの管理

この部では、Oracle Streamsレプリケーションの管理について説明します。この部の構成は、次のとおりです。

- 第12章「Oracle Streamsレプリケーションの管理」

- 第13章「データの比較および収束」

- 第14章「論理変更レコード(LCR)の管理」

12 Oracle Streamsレプリケーションの管理

この章では、Oracle Streamsレプリケーション環境を管理する方法について説明します。

この章の内容は次のとおりです。

- Oracle Streamsの管理

- ストリームでのLCRの追跡

- Oracle Streamsの接続先の分割およびマージ

- ソース・データベースのDBIDまたはグローバル名の変更

- 複数ソース環境でのソース・データベースの再同期化

- Oracle Streams環境におけるデータベースのPoint-in-Timeリカバリの実行

- Oracle Streamsレプリケーション環境でのフラッシュバック問合せの実行

- 操作エラーからのリカバリ

Oracle Streamsの管理

Oracle Streamsレプリケーション環境の準備が整ったら、各データベースでOracle Streamsコンポーネントを管理できます。管理作業の1つとしてコンポーネントの管理があります。たとえば、取得処理パラメータを設定して取得プロセスの動作を変更できます。また、管理作業には、Oracle Streamsコンポーネントの監視や問題が発生した場合のトラブルシューティングも含まれます。

次のマニュアルでは、Oracle Streamsを管理する方法について説明されています。

- Oracle Streamsコンポーネントを管理する方法の詳細は、『Oracle Streams概要および管理』を参照してください。

- 最も一般的な管理タスクを実行する方法については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

- Oracle Streamsレプリケーション環境に固有の方法については、『Oracle Streamsレプリケーション管理者ガイド』(このマニュアル)を参照してください。

- Oracle Enterprise Managerを使用してOracle Streamsを管理する方法の詳細は、Oracle Enterprise ManagerのOracle Streamsインタフェースに関するオンライン・ヘルプを参照してください。

ストリームでのLCRの追跡

ストリームでの論理変更レコード(LCR)の流れは通常、次のようになります。

1. データベースの変更が取得され、LCRにフォーマットされてエンキューされます。取得プロセスまたは同期取得では、データベースの変更を暗黙的に取得できます。アプリケーションまたはユーザーは、LCRを構成およびエンキューして、データベースの変更を明示的に取得できます。

2. 1つ以上の伝播によって、LCRがOracle Streams環境内の他のデータベースに送信されます。

3. 1つ以上の適用プロセスによって、LCRがデキューおよび処理されます。

ストリームでLCRを追跡するには、次のいずれかの方法を使用します。

- 取得プロセスによってLCRが取得される場合は、message_tracking_frequency取得プロセス・パラメータを1または他の比較的低い値に設定します。

- 取得プロセスまたは同期取得によってLCRが取得される場合、またはアプリケーションによってLCRが構成される場合は、DBMS_STREAMS_ADMパッケージのSET_MESSAGE_TRACKINGプロシージャを実行します。

LCRの追跡は、1つ以上の適用プロセスでLCRが正しく適用されていない場合に役立ちます。この場合、LCRを追跡することによって、ストリーム内のLCRの停止場所を判断し、その場所で発生している問題に対応できます。

これらの方法のいずれかを使用してLCRを追跡した後は、V$STREAMS_MESSAGE_TRACKINGビューを使用して、ストリームでLCRの進捗を監視します。ストリームでLCRを追跡することによって、LCRがブロックされている場所を判断できます。LCRの追跡開始後、各LCRに追跡ラベルが含まれます。

message_tracking_frequency取得プロセスのパラメータを使用してLCR追跡が開始された場合、追跡ラベルはcapture_process_name:AUTOTRACKで、capture_process_nameは取得プロセスの名前です。取得プロセス名の最初の20バイトのみが使用され、20バイトを超える場合、残りは切り捨てられます。

SET_MESSAGE_TRACKINGプロシージャを使用すると、現行セッションで生成される各LCRの一部として追跡ラベルを指定できます。この追跡ラベルを使用してV$STREAMS_MESSAGE_TRACKINGビューを問い合せると、ストリームでLCRを追跡し、LCRが各Oracle Streamsクライアントによって処理された状況を確認できます。SET_MESSAGE_TRACKINGプロシージャを使用すると、次のLCRが追跡されます。

- 取得プロセスまたは同期取得でLCRを取得する場合、取得されるデータベースの変更を行ったセッションに対して追跡ラベルが設定されていると、LCRに自動的に追跡ラベルが含まれます。

- ユーザーまたはアプリケーションがLCRを構成する場合、LCRを構成するセッションに対して追跡ラベルが設定されていると、LCRに自動的に追跡ラベルが含まれます。

ストリームでLCRを追跡するには、次の手順を実行します。

1. LCRの追跡を開始します。

LCRの追跡を開始するには、次の方法があります。

- 取得プロセスを実行しているデータベースに接続し、message_tracking_frequency取得プロセス・パラメータを1または他の比較的低い値に設定します。取得プロセス・パラメータの設定後、手順2に進みます。
取得プロセス・パラメータの設定の詳細は、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』または『Oracle Streams概要および管理』を参照してください。

SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

- 次の手順を実行して、DBMS_STREAMS_ADMパッケージのSET_MESSAGE_TRACKINGプロシージャを実行します。

1. SQL*Plusで、セッションを開始します。取得プロセスまたは同期取得によって取得されるデータベースの変更に対して追跡ラベルを使用するには、取得プロセスまたは同期取得のソース・データベースに接続します。

2. メッセージの追跡を開始します。

BEGIN
DBMS_STREAMS_ADM.SET_MESSAGE_TRACKING(
tracking_label => 'TRACK_LCRS');
END;
/

LCRの追跡には、任意のラベルを使用できます。この例では、TRACK_LCRSというラベルを使用しています。

LCRに関する情報がメモリーで追跡され、V$STREAMS_MESSAGE_TRACKING動的パフォーマンス・ビューにLCRに関する情報が移入されます。

3. セッションでメッセージの追跡が設定されていることを確認するには、追跡ラベルを問い合せます(オプション)。

SELECT DBMS_STREAMS_ADM.GET_MESSAGE_TRACKING() TRACKING_LABEL FROM DUAL;

手順bで指定した追跡ラベルが、この問合せによって戻されます。

TRACKING_LABEL
--------------------------------------------------------------------------
TRACK_LCRS

2. 取得プロセスまたは同期取得によって取得される変更をソース・データベースに対して行い、取得プロセスまたは同期取得でストリームを開始するか、または追跡するLCRを構成およびエンキューします。通常、これらのLCRはテスト用としてのみ使用します。たとえば、表に複数の仮行を挿入した後で、それらの行を変更できます。テストが完了したら、これらの行は削除できます。

3. Oracle Streams環境全体を監視してLCRを追跡します。これを行うには、LCRを処理する各データベースでV$STREAMS_MESSAGE_TRACKINGビューを問い合せます。
たとえば、各データベースで次の問合せを実行します。

COLUMN COMPONENT_NAME HEADING 'Component|Name' FORMAT A10
COLUMN COMPONENT_TYPE HEADING 'Component|Type' FORMAT A12
COLUMN ACTION HEADING 'Action' FORMAT A11
COLUMN SOURCE_DATABASE_NAME HEADING 'Source|Database' FORMAT A10
COLUMN OBJECT_OWNER HEADING 'Object|Owner' FORMAT A6
COLUMN OBJECT_NAME HEADING 'Object|Name' FORMAT A10
COLUMN COMMAND_TYPE HEADING 'Command|Type' FORMAT A7

SELECT COMPONENT_NAME,
COMPONENT_TYPE,
ACTION,
SOURCE_DATABASE_NAME,
OBJECT_OWNER,
OBJECT_NAME,
COMMAND_TYPE
FROM V$STREAMS_MESSAGE_TRACKING;

WHERE句に正しい追跡ラベルを指定していることを確認します。

この問合せによって、各データベースでのLCRの処理状況が表示されます。LCRが宛先データベースに適用されていない場合は、ストリーム内のLCRの停止場所が表示されます。

たとえば、同期取得によるソース・データベースでの出力は、次のようになります。

Component  Component                Source     Object Object     Command
Name       Type         Action      Database   Owner  Name       Type
---------- ------------ ----------- ---------- ------ ---------- -------
CAPTURE    SYNCHRONOUS  Create      HUB.EXAMPL HR     EMPLOYEES  UPDATE
CAPTURE                  E.COM
CAPTURE    SYNCHRONOUS  Rule evalua HUB.EXAMPL HR     EMPLOYEES  UPDATE
CAPTURE      tion        E.COM
CAPTURE    SYNCHRONOUS  Enqueue     HUB.EXAMPL HR     EMPLOYEES  UPDATE
CAPTURE                  E.COM

適用プロセスによる宛先データベースでの出力は、次のようになります。

Component  Component                Source     Object Object     Command
Name       Type         Action      Database   Owner  Name       Type
---------- ------------ ----------- ---------- ------ ---------- -------
APPLY_SYNC APPLY READER Dequeue     HUB.EXAMPL HR     EMPLOYEES  UPDATE
_CAP                                E.COM
APPLY_SYNC APPLY READER Dequeue     HUB.EXAMPL HR     EMPLOYEES  UPDATE
_CAP                                E.COM
APPLY_SYNC APPLY READER Dequeue     HUB.EXAMPL HR     EMPLOYEES  UPDATE
_CAP                                E.COM

V$STREAMS_MESSAGE_TRACKINGビューで追加の列を問い合せると、詳細情報を表示できます。たとえば、ACTION_DETAILS列では各アクションに関する詳細情報が提供されます。

4. メッセージの追跡を停止します。手順1での選択に基づいて、次のいずれかのアクションを完了します。

- 手順1でmessage_tracking_frequency取得プロセス・パラメータを設定した場合、このパラメータをデフォルト値に戻します。デフォルトでは、200万番目ごとにメッセージが追跡されます。
この取得プロセス・パラメータをデフォルト値に設定するには、取得プロセスを実行しているデータベースに接続し、message_tracking_frequency取得プロセス・パラメータをNULLに設定します。

取得プロセス・パラメータの設定の詳細は、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』または『Oracle Streams概要および管理』を参照してください。

- 現行セッションでメッセージの追跡を開始した場合は、そのセッション内でメッセージの追跡を停止します。
現行セッションでメッセージの追跡を停止するには、SET_MESSAGE_TRACKINGプロシージャでtracking_labelパラメータをNULLに設定します。

BEGIN
DBMS_STREAMS_ADM.SET_MESSAGE_TRACKING(
tracking_label => NULL,
actions        => DBMS_STREAMS_ADM.ACTION_MEMORY);
END;
/

関連項目:
message_tracking_frequency取得プロセス・パラメータの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

Oracle Streamsの接続先の分割およびマージ

次の項では、ストリームの分割方法とマージ方法およびそれらの例を示します。

- Oracle Streamsの分割およびマージ

- 分割およびマージのオプション

- Oracle Streamsの分割およびマージの例

Oracle Streamsの分割およびマージ

Oracle Streams接続先の分割およびマージは、次の場合に役立ちます。

- 単一の取得プロセスで、複数の適用プロセスに送信される変更を取得する場合。

- 適用プロセスが、取得プロセスによって取得された変更の受入れを停止した場合。たとえば、適用プロセスは、適用プロセスが無効化された場合、適用プロセスが含まれているデータベースが停止した場合、ネットワークの問題が発生した場合、適用プロセスが含まれているデータベースを実行しているコンピュータ・システムが停止した場合、または他のなんらかの理由によって、変更の受入れを停止する場合があります。

これらの条件に該当する場合は、問題が発生した宛先を他の宛先から分割することをお薦めします。宛先を分割する理由は、取得と適用の複合による最適化を、構成で使用しているかどうかによって異なります。

- 問題が発生した宛先の適用プロセスが取得と適用の複合による最適化の一部である場合、宛先を分割しないと、その宛先が再度使用可能になったときにパフォーマンスが低下します。この場合、すでに分割されている宛先で適用する必要がある変更を、取得プロセスで取得する必要があります。他の宛先では、問題が発生した宛先が遅延を回復するまで、より新しい変更を受信しません。ただし、問題が発生した宛先が分割されている場合は、他の宛先に影響を与えることなく、他の宛先に対する遅延の回復を独立して行うことができます。

- 宛先の適用プロセスが取得と適用の複合による最適化の一部ではない場合、取得されても問題が発生した宛先キューに送信できない変更はソース・キューに残り、ソース・キューのサイズが増加します。最終的に、ソース・キューの取得論理変更レコード(LCR)はハード・ディスクにオーバーフローし、Oracle Streamsレプリケーション環境のパフォーマンスが低下します。

分割操作およびマージ操作が可能なのは、次のようなタイプのOracle Streamsレプリケーション環境です。

- 単一の取得プロセスによって取得された変更が、伝播を使用して複数のリモートの宛先へ送信され、リモートの宛先で適用プロセスによって適用される環境。

- 単一の取得プロセスによって取得された変更が、取得プロセスを実行しているデータベースと同じデータベース上で複数の適用プロセスによってローカルに適用される環境。

- 単一の取得プロセスによって取得された変更が、伝播を使用して1つ以上のリモートの宛先へ送信され、取得プロセスを実行しているデータベースと同じデータベース上で1つ以上の適用プロセスによってローカルに適用される環境。

ローカルの取得と適用を使用する環境については、取得プロセスと適用プロセスで同じキューを共有している場合、および1つのデータベース内で伝播によって変更が取得プロセスのキューから適用プロセスのキューに送信される場合に、分割操作およびマージ操作が可能です。

図12-1に、伝播を使用して変更を複数の宛先に送信するOracle Streamsレプリケーション環境を示します。この例では、宛先データベースAが停止しています。

図12-1 宛先で問題が発生したOracle Streamsレプリケーション環境

次のデータ・ディクショナリ・ビューを使用すると、ストリームで問題が発生しているかどうかを判別できます。

- V$BUFFERED_QUEUESビューを問い合せて、バッファ・キュー内のメッセージの数およびハード・ディスクにオーバーフローしたメッセージの数を確認します。

- 伝播を使用している場合は、DBA_PROPAGATIONおよびV$PROPAGATION_SENDERビューを問い合せて、データベース内の伝播および各伝播の状態を確認します。

このような状況でのパフォーマンスの低下を回避するには、問題が発生したデータベースに送信されているストリームを、取得プロセスから送信されている他のストリームから分割します。問題が解決したら、分割したストリームを、取得プロセスから送信されている他のストリームとマージします。

取得プロセス・パラメータを設定して、問題が発生したストリームを自動的に分割およびマージすることも、問題が発生したストリームを手動で分割およびマージすることもできます。どちらの場合も、DBMS_STREAMS_ADMパッケージのSPLIT_STREAMS、MERGE_STREAMS_JOBおよびMERGE_STREAMSプロシージャを使用します。SPLIT_STREAMSプロシージャは、問題が発生している宛先に対するストリームを、取得プロセスから他の宛先に送信されている他のすべてのストリームから分割します。SPLIT_STREAMSプロシージャは、常に取得プロセスおよびキューをクローニングします。また、SPLIT_STREAMSプロシージャは、変更をリモートの宛先データベースに送信する環境では、伝播をクローニングします。クローニングされたこれらのコンポーネントは、分割されたストリームで使用されます。問題が発生しているストリームは分割されますが、他の宛先に対するストリームは、通常どおり続行されます。

図12-2に、SPLIT_STREAMSプロシージャによって作成される、クローニングされたストリームを示します。

図12-2 Oracle Streamsの分割

問題が発生した宛先が再度使用可能になると、クローニングされたストリームが、宛先データベースへの取得された変更の送信を再開します。

図12-3に、起動されて実行されている宛先データベースA、および取得データベースで有効になっているクローニングされた取得プロセスを示します。クローニングされたストリームの送信が開始され、元のストリームに対する遅延の回復が開始されます。

図12-3 クローニングされたストリームの送信開始および元のストリームに対する遅延の回復

クローニングされたストリームが元のいずれかのストリームに対する遅延を回復したら、次のいずれかのプロシージャを実行して、これらのストリームをマージできます。

- MERGE_STREAMSプロシージャ: 分割されたストリームを、元の取得プロセスから送信されている他のストリームとマージします。

- MERGE_STREAMS_JOBプロシージャ: ストリームがユーザー指定マージしきい値の範囲内かどうかを判別します。ストリームがマージしきい値の範囲内の場合、MERGE_STREAMS_JOBプロシージャはMERGE_STREAMSプロシージャを実行します。ストリームがマージしきい値の範囲外の場合、MERGE_STREAMS_JOBプロシージャは何も実行しません。

MERGE_STREAMS_JOBプロシージャは、ストリームをマージする前にそれらのストリームをマージする準備が整っているかどうかを自動的に確認するため、通常は、MERGE_STREAMSプロシージャを直接実行するのではなく、MERGE_STREAMS_JOBプロシージャを実行することをお薦めします。

図12-4に、MERGE_STREAMSプロシージャの実行結果を示します。Oracle Streamsレプリケーション環境に元のコンポーネントが存在し、すべてのストリームが正常に送信されています。

図12-4 Oracle Streamsのマージ

関連項目:
取得と適用の複合の詳細は、『Oracle Streams概要および管理』を参照してください。

分割およびマージのオプション

次の分割およびマージのオプションを使用できます。

- 自動の分割およびマージ

- 手動の分割および自動のマージ

- 手動の分割および生成されたスクリプトによるマージ

自動の分割およびマージ

split_thresholdおよびmerge_thesholdという2つの取得プロセス・パラメータを設定すると、Oracle Streamsによって自動的に分割操作とマージ操作が実行できます。これらのパラメータが自動の分割とマージを指定するように設定されている場合、Oracle Schedulerジョブは取得プロセスから送信されているストリームを監視します。Oracle Schedulerジョブがストリームの問題を特定した場合、ジョブは問題のあるストリームを取得プロセスから送信されている他のストリームから分割します。分割操作が完了すると、新しいOracle Schedulerマージ・ジョブが、分割されたストリームを監視します。問題が解決した場合、このジョブはストリームを他のストリームとマージします。

split_threshold取得プロセス・パラメータがINFINITEに設定されている場合、自動の分割は無効です。split_thresholdパラメータがINFINITEに設定されていない場合、自動の分割は有効です。自動の分割は、split_thresholdパラメータで指定された秒数の間、適用プロセスとの通信が失われた場合のみ発生します。たとえば、適用プロセスが無効になった場合や宛先データベースが停止した場合に、適用プロセスとの通信が失われます。1つのストリームが他のストリームより遅い速度で変更を処理している場合、自動の分割は発生しません。

ストリームが分割されると、クローニングされた取得プロセスが作成されます。クローニングされた取得プロセスは、構成で取得と適用の複合による最適化を使用しているかどうかに応じて、分割後に有効化または無効化される場合があります。

- 適用プロセスが取得と適用の複合による最適化の一部である場合、クローニングされた取得プロセスは有効化されます。クローニングされた取得プロセスでは、適用プロセスが有効化されて、適用プロセスとの通信が確立されるまで、変更を取得しません。

- 適用プロセスが取得と適用の複合による最適化の一部ではない場合、キューでLCRが構築されないようにクローニングされた取得プロセスは無効化されます。適用プロセスが有効化され、クローニングされたストリームが送信可能になれば、クローニングされた取得プロセスを手動で起動できます。

クローニングされた取得プロセスと元の取得プロセスのGV$STREAMS_CAPTUREビューのCAPTURE_MESSAGE_CREATE_TIMEの差(秒単位)が、merge_threshold取得プロセス・パラメータに指定された値以下であれば、分割されたストリームは元のストリームと自動的にマージされます。CAPTURE_MESSAGE_CREATE_TIMEは、取得された変更がREDOログに記録された時間を記録します。この差がこの取得プロセス・パラメータによって指定された値よりも大きい場合、自動のマージは開始されず、値がDBA_STREAMS_SPLIT_MERGEビューのLAG列に記録されます。

ストリームに対する取得プロセスと適用プロセスが異なるデータベース・インスタンスで実行されているときは、そのストリームに対する自動の分割およびマージはいつでも使用できます。ストリームに対する取得プロセスと適用プロセスが同じデータベース・インスタンスで実行されているときは、次のすべての条件を満たす場合のみ、自動の分割およびマージを使用できます。

- 取得プロセスおよび適用プロセスで同じキューを使用していること。

- 適用プロセスのエラー・キューにエラーがないこと。

- 適用プロセスがXStreamアウトバウンド・サーバーではないこと。

- 適用プロセスが停止していること。

- バッファ・キューからハード・ディスクにオーバーフローしているメッセージがないこと。

関連項目:

- 例については、「Oracle Streamsの宛先の自動的な分割およびマージ」を参照してください。

- 取得プロセス・パラメータの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- 自動の分割操作およびマージ操作の監視の詳細は、『Oracle Streams概要および管理』を参照してください。

- Oracle Database XStreamについてのマニュアル

手動の分割および自動のマージ

SPLIT_STREAMSプロシージャによってストリームを手動で分割した場合、auto_merge_thresholdプロシージャ・パラメータを使用すると、宛先の問題が解決されたときに、ストリームを元の取得プロセスと自動的にマージできます。問題が発生したストリームの適用プロセスで変更の受入れが開始されたら、クローニングされた取得プロセスを起動して、クローニングされた取得プロセスが元の取得プロセスに対する遅延を回復するまで待機できます。クローニングされた取得プロセスがほぼ遅延を回復したら、auto_merge_thresholdパラメータ設定によって、分割されたストリームが自動的にマージされるか、手動でマージされるかが決定されます。

- auto_merge_thresholdが正数に設定されている場合、SPLIT_STREAMSプロシージャは、スケジュールが設定されたOracle Schedulerジョブを作成します。このジョブによって、MERGE_STREAMS_JOBプロシージャが実行され、auto_merge_thresholdパラメータに指定された値と等しいマージしきい値が指定されます。ジョブは、作成後にそのスケジュールを変更することができます。
この場合、クローニングされた取得プロセスと元の取得プロセスのGV$STREAMS_CAPTUREビューのCAPTURE_MESSAGE_CREATE_TIMEの差(秒単位)が、auto_merge_thresholdパラメータに指定された値以下であれば、分割されたストリームは元のストリームと自動的にマージされます。CAPTURE_MESSAGE_CREATE_TIMEは、取得された変更がREDOログに記録された時間を記録します。

- auto_merge_thresholdがNULLまたは0(ゼロ)に設定されている場合、分割されたストリームは元のストリームと自動的にマージされません。分割されたストリームを元のストリームとマージするには、MERGE_STREAMS_JOBまたはMERGE_STREAMSプロシージャを手動で実行します。

関連項目:
例については、「Oracle Streamsの宛先の手動の分割および自動的なマージ」を参照してください。

手動の分割および生成されたスクリプトによるマージ

SPLIT_STREAMSおよびMERGE_STREAMSプロシージャは、アクションを直接実行するか、またはアクションを実行するスクリプトを生成してスクリプトの実行時にアクションを実行できます。スクリプトを実行するよりプロシージャを使用してアクションを直接実行する方が簡単で、分割操作またはマージ操作が即時に実行されます。ただし、次の理由でスクリプトを生成することもあります。

- ストリームを分割またはマージする前にプロシージャによって実行されるアクションを確認する必要がある。

- アクションをカスタマイズするためにスクリプトを変更する必要がある。

たとえば、クローニングされた取得プロセスのルール・セットのルールを変更する場合、スクリプトを変更することがあります。Oracle Streamsレプリケーション環境によっては、ソース・データベースに対して行われた変更のサブセットのみが各宛先データベースに送信され、各宛先データベースが異なる変更のサブセットを受信する場合があります。このような環境では、クローニングされた伝播によって伝播される変更のみを取得するように、クローニングされた取得プロセスのルール・セットを変更できます。

各プロシージャのperform_actionsパラメータは、プロシージャでアクションを直接実行するかどうかを制御します。

- この項のいずれかのプロシージャを実行する際にストリームを直接分割またはマージする場合は、perform_actionsパラメータをTRUEに設定します。このパラメータのデフォルト値はTRUEです。

- この項のいずれかのプロシージャを実行する際にスクリプトを生成する場合は、perform_actionsパラメータをFALSEに設定し、script_nameおよびscript_directory_objectパラメータを使用してスクリプトの名前と格納場所を指定します。

関連項目:
例については、「Oracle Streamsの宛先のスクリプトによる手動の分割およびマージ」を参照してください。

Oracle Streamsの分割およびマージの例

次の項では、ストリームを分割およびマージする手順について説明します。

- Oracle Streamsの宛先の自動的な分割およびマージ

- Oracle Streamsの宛先の手動での分割および自動的なマージ

- Oracle Streamsの接続先のスクリプトによる手動の分割およびマージ

これらの例では、Oracle Streamsレプリケーション環境に関して次のことを想定しています。

- 1つの取得プロセスstrms_captureで、3つの宛先データベースに送信される変更を取得します。

- 宛先データベースの宛先キューに変更を送信する伝播は、次のとおりです。

- strms_prop_a

- strms_prop_b

- strms_prop_c

- キューstreams_queueが、3つすべての伝播のソース・キューです。

- strms_prop_a伝播の宛先に問題が発生しています。この伝播は、メッセージを宛先キューに送信できません。

- 他の2つの伝播(strms_prop_bおよびstrms_prop_c)は、メッセージを正常に伝播しています。

関連項目:
SPLIT_STREAMSプロシージャおよびMERGE_STREAMSプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

Oracle Streamsの宛先の自動的な分割およびマージ

この例を確認する前に、次の項を参照してください。

- 概念については、「自動の分割およびマージ」を参照してください。

- この例のOracle Streamsレプリケーション環境に関する想定については、「Oracle Streamsの分割およびマージの例」を参照してください。

次の手順を実行して、ストリームを自動的に分割およびマージします。

1. SQL*Plusで、Oracle Streams管理者として取得プロセスを含むデータベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

2. 次のパラメータが自動の分割とマージが有効化されるようにstrms_capture取得プロセスに対して適切に設定されていることを確認します。

- split_threshold: このパラメータがINFINITEに設定されていないことを確認します。このパラメータのデフォルトの設定は1800秒です。

- merge_threshold: このパラメータが負の値に設定されていないことを確認します。このパラメータのデフォルトの設定は60秒です。

これらのパラメータの設定を確認するには、DBA_CAPTURE_PARAMETERSビューを問い合せます。手順については、『Oracle Streams概要および管理』を参照してください。

3. 手順 2で説明した取得プロセス・パラメータのいずれかまたは両方をリセットする必要がある場合は、Oracle Enterprise ManagerまたはDBMS_CAPTURE_ADMパッケージのSET_PARAMETERプロシージャを使用してパラメータをリセットします。Oracle Enterprise Managerの使用手順については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。SET_PARAMETERプロシージャの使用手順については、『Oracle Streams概要および管理』を参照してください。

4. DBA_STREAMS_SPLIT_MERGEビューを定期的に監視し、自動の分割操作およびマージ操作が処理中であるかどうかを確認します。

自動の分割が発生すると、取得プロセス、キュー、伝播などの特定のコンポーネントがクローニングされ、それぞれにシステム生成名が付けられます。DBA_STREAMS_SPLIT_MERGEビューには、クローニングされた各コンポーネントの名前などの分割操作およびマージ操作に関する情報が含まれています。

DBA_STREAMS_SPLIT_MERGEビューを問い合せて、ストリームが元の取得プロセスから分割されたかどうかを判別します。

COLUMN ORIGINAL_CAPTURE_NAME HEADING 'Original|Capture|Process' FORMAT A10
COLUMN ACTION_TYPE HEADING 'Action|Type' FORMAT A7
COLUMN STATUS_UPDATE_TIME HEADING 'Status|Update|Time' FORMAT A15
COLUMN STATUS HEADING 'Status' FORMAT A16
COLUMN JOB_NEXT_RUN_DATE HEADING 'Next Job|Run Date' FORMAT A20

SELECT ORIGINAL_CAPTURE_NAME,
ACTION_TYPE,
STATUS_UPDATE_TIME,
STATUS,
JOB_NEXT_RUN_DATE
FROM DBA_STREAMS_SPLIT_MERGE
ORDER BY STATUS_UPDATE_TIME DESC;

ストリームが元の取得プロセスから分割されている場合、出力は次のようになります。

Original           Status
Capture    Action  Update                           Next Job
Process    Type    Time            Status           Run Date
---------- ------- --------------- ---------------- --------------------
DB$CAP     MERGE   01-APR-09 06.49 NOTHING TO MERGE 01-APR-09 06.54.29.0
.29.204804 AM                    00000 AM -07:00
DB$CAP     SPLIT   01-APR-09 06.49 SPLIT DONE       01-APR-09 06.47.59.0
.17.389146 AM                    00000 AM -07:00

この出力には、自動の分割が実行されたことが示されています。マージ・ジョブは01-APR-09 06.49.29.204804 AMに実行されましたが、分割されたストリームをマージする準備ができていなかったため、状態にはNOTHING TO MERGEが示されています。SPLIT DONE状態は、01-APR-09 06.49.17.389146 AMの日時にストリームが分割されたことを示しています。

5. 自動の分割の実行後、宛先で発生した問題を解決します。宛先データベースの適用プロセスで、クローニングされた取得プロセスからの変更の受入れが可能になったら、問題は解決しています。問題が解決されたら、Oracle Schedulerジョブは自動のマージを実行します。

6. クローニングされた取得プロセスが無効になっている場合は、クローニングされた取得プロセスを起動します。クローニングされた取得プロセスが無効になるのは、ストリームが取得と適用の複合による最適化ではない場合のみです。取得プロセスの起動手順については、『Oracle Streams概要および管理』を参照してください。

クローニングされた取得プロセスでは、ルール・セットを満たす変更を取得します。これらの変更は、適用プロセスに送信されます。

この場合、Oracle Schedulerジョブは、スケジュールに従ってMERGE_STREAMS_JOBプロシージャを実行します。MERGE_STREAMS_JOBプロシージャでは、GV$STREAMS_CAPTUREビューのCAPTURE_MESSAGE_CREATE_TIMEを問い合せます。クローニングされた取得プロセスと元の取得プロセスのCAPTURE_MESSAGE_CREATE_TIMEの差がmerge_threshold取得プロセス・パラメータの値以下であれば、MERGE_STREAMS_JOBプロシージャによって、ストリームをマージする準備ができていると判断されます。MERGE_STREAMS_JOBプロシージャは、MERGE_STREAMSプロシージャを自動的に実行してストリームをマージします。

DBA_STREAMS_SPLIT_MERGEビューのLAG列では、クローニングされた取得プロセスが元の取得プロセスに対して遅延している時間(秒単位)を追跡します。次の問合せでは、遅延時間が表示されます。

COLUMN ORIGINAL_CAPTURE_NAME HEADING 'Original Capture Process' FORMAT A25
COLUMN CLONED_CAPTURE_NAME HEADING 'Cloned Capture Process' FORMAT A25
COLUMN LAG HEADING 'Lag' FORMAT 999999999999999

SELECT ORIGINAL_CAPTURE_NAME,
CLONED_CAPTURE_NAME,
LAG
FROM DBA_STREAMS_SPLIT_MERGE
WHERE ACTION_TYPE = 'MERGE';

出力は次のようになります。

Original Capture Process  Cloned Capture Process                 Lag
------------------------- ------------------------- ----------------
DB$CAP                    CLONED$_DB$CAP_5                      2048

この出力には、元の取得プロセスとクローニングされた取得プロセスのCAPTURE_MESSAGE_CREATE_TIME値の間に2,048秒の遅延があることが示されています。クローニングされた取得プロセスがしきい値の範囲内である場合、マージ・ジョブはMERGE_STREAMSプロシージャを開始できます。デフォルトでは、マージしきい値は60秒です。

MERGE_STREAMSプロシージャを実行すると、次のアクションが実行されます。

- クローニングされた取得プロセスが停止されます。

- 元の伝播strms_prop_aが再作成されます。

- クローニングされた伝播が削除されます。

- クローニングされた取得プロセスが削除されます。

- クローニングされたキューが削除されます。

手順4の問合せを定期的に繰り返し、分割操作およびマージ操作を監視します。マージ操作の完了後、この問合せの出力は次のようになります。

Original           Status
Capture    Action  Update                           Next Job
Process    Type    Time            Status           Run Date
---------- ------- --------------- ---------------- --------------------
DB$CAP     MERGE   01-APR-09 07.32 NOTHING TO MERGE 01-APR-09 07.37.04.0
.04.820795 AM                    00000 AM -07:00
DB$CAP     MONITOR 01-APR-09 07.32 MERGE DONE       01-APR-09 07.36.20.0
.04.434925 AM                    00000 AM -07:00
DB$CAP     SPLIT   01-APR-09 06.49 SPLIT DONE       01-APR-09 06.47.59.0
.17.389146 AM                    00000 AM -07:00

この出力には、01-APR-09 07.32.04.434925 AMの日時に、分割されたストリームが元の取得プロセスとマージされたことが示されています。分割されたストリームは残っていないため、次の状態にはNOTHING TO MERGEが示されています。

ストリームがマージされた後は、Oracle Streamsレプリケーション環境に、分割操作およびマージ操作の前と同じコンポーネントが存在するようになります。今後の参照用に、完了した分割操作およびマージ操作に関する情報はDBA_STREAMS_SPLIT_MERGE_HISTに格納されます。

関連項目:
自動の分割操作およびマージ操作の監視の詳細は、『Oracle Streams概要および管理』を参照してください。

Oracle Streamsの宛先の手動での分割および自動的なマージ

この例を確認する前に、次の項を参照してください。

- 概念については、「手動の分割および自動のマージ」を参照してください。

- この例のOracle Streamsレプリケーション環境に関する想定については、「Oracle Streamsの分割およびマージの例」を参照してください。

この項の例では、手動でストリームを分割し、自動的にマージします。そのため、SPLIT_STREAMSプロシージャのperform_actionsパラメータはTRUEに設定されています。また、この例では、SPLIT_STREAMSプロシージャのauto_merge_thresholdパラメータが正数(60)に設定されているため、ストリームを適切なタイミングで自動的にマージします。

次の手順を実行して、ストリームを直接分割し、自動的にマージします。

1. SQL*Plusで、Oracle Streams管理者として取得プロセスを含むデータベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

2. 次のプロシージャを実行して、伝播strms_prop_aを介して送信されているストリームを、strms_capture取得プロセスから送信されている他の伝播から分割します。

DECLARE
schedule_name  VARCHAR2(30);
job_name       VARCHAR2(30);
BEGIN
schedule_name := 'merge_job1_schedule';
job_name      := 'merge_job1';
DBMS_STREAMS_ADM.SPLIT_STREAMS(
propagation_name        => 'strms_prop_a',
cloned_propagation_name => 'cloned_prop_a',
cloned_queue_name       => 'cloned_queue',
cloned_capture_name     => 'cloned_capture',
perform_actions         => TRUE,
auto_merge_threshold    => 60,
schedule_name           => schedule_name,
merge_job_name          => job_name);
END;
/

このプロシージャを実行すると、次のアクションが実行されます。

- 新しいキューcloned_queueが作成されます。

- cloned_queueキューからstrms_prop_a伝播によって使用されている既存の宛先キューにメッセージを伝播する新しい伝播cloned_prop_aが作成されます。クローニングされた伝播cloned_prop_aでは、元の伝播strms_prop_aと同じルール・セットが使用されます。

- 取得プロセスstrms_captureが停止されます。

- 元の伝播strms_prop_aの確認済SCNが問い合されます。確認済SCNとは、伝播によって送信された変更を適用する適用プロセスによって最後に確認されたSCNです。伝播の確認済SCNは、DBA_PROPAGATIONビューのACKED_SCN値に示されます。

- 新しい取得プロセスcloned_captureが作成されます。cloned_captureの開始SCNは、strms_prop_a伝播の確認済SCNの値に設定されます。クローニングされた取得プロセスcloned_captureでは、元の取得プロセスstrms_captureと同じルール・セットが使用されます。

- 元の伝播strms_prop_aが削除されます。

- 開始SCNがstrms_prop_a伝播の確認済SCNの値に設定された、元の取得プロセスstrms_captureが起動されます。

- スケジュールmerge_job1_scheduleが設定されたOracle Schedulerジョブmerge_job1が作成されます。ジョブとスケジュールは両方とも、SPLIT_STREAMSプロシージャを実行したユーザーによって所有されます。このスケジュールは、SPLIT_STREAMSプロシージャが完了すると実行が開始されます。初期スケジュールは、システムによって定義されますが、他のOracle Schedulerジョブを変更する場合と同じ方法で変更できます。手順については、『Oracle Database管理者ガイド』を参照してください。

3. cloned_prop_aの宛先で発生した問題を解決します。宛先データベースの適用プロセスで、クローニングされた取得プロセスからの変更の受入れが可能になったら、問題は解決しています。

4. Oracle Streams管理者として接続したまま、次のプロシージャを実行して、クローニングされた取得プロセスを起動します。

exec DBMS_CAPTURE_ADM.START_CAPTURE('cloned_capture');

クローニングされた取得プロセスcloned_captureの実行が開始されると、ルール・セットを満たす、確認済SCN以降の変更が取得されます。これらの変更は、cloned_prop_a伝播によって伝播され、宛先データベースの適用プロセスによって処理されます。

この場合、Oracle Schedulerジョブは、スケジュールに従ってMERGE_STREAMS_JOBプロシージャを実行します。MERGE_STREAMS_JOBプロシージャでは、GV$STREAMS_CAPTUREビューのCAPTURE_MESSAGE_CREATE_TIMEを問い合せます。クローニングされた取得プロセスcloned_captureと元の取得プロセスstrms_captureのCAPTURE_MESSAGE_CREATE_TIMEの差が60秒以下であれば、MERGE_STREAMS_JOBプロシージャによって、ストリームをマージする準備ができていると判断されます。MERGE_STREAMS_JOBプロシージャは、MERGE_STREAMSプロシージャを自動的に実行してストリームをマージします。

次の問合せでは、元の取得プロセスおよびクローニングされた取得プロセスのCAPTURE_MESSAGE_CREATE_TIMEが表示されます。

COLUMN CAPTURE_NAME HEADING 'Capture|Name' FORMAT A17
COLUMN STATE HEADING 'State' FORMAT A20
COLUMN CREATE_MESSAGE HEADING 'Last Message|Create Time'

SELECT CAPTURE_NAME,
STATE,
TO_CHAR(CAPTURE_MESSAGE_CREATE_TIME, 'HH24:MI:SS MM/DD/YY') CREATE_MESSAGE
FROM V$STREAMS_CAPTURE;

出力は次のようになります。

Capture                                Last Message
Name              State                Create Time
----------------- -------------------- -----------------
DB$CAP            CAPTURING CHANGES    07:22:55 04/01/09
CLONED$_DB$CAP_5  CAPTURING CHANGES    06:50:39 04/01/09

この出力には、元の取得プロセスとクローニングされた取得プロセスのCAPTURE_MESSAGE_CREATE_TIME値の間に30分を超える遅延があることが示されています。クローニングされた取得プロセスがしきい値の範囲内である場合、マージ・ジョブはMERGE_STREAMSプロシージャを開始できます。デフォルトでは、マージしきい値は60秒です。

MERGE_STREAMSプロシージャを実行すると、次のアクションが実行されます。

- クローニングされた取得プロセスcloned_captureが停止されます。

- 伝播strms_prop_aが再作成されます。

- クローニングされた伝播cloned_prop_aが削除されます。

- クローニングされた取得プロセスcloned_captureが削除されます。

- クローニングされたキューcloned_queueが削除されます。

ストリームがマージされた後は、Oracle Streamsレプリケーション環境に、分割操作およびマージ操作の前と同じコンポーネントが存在するようになります。今後の参照用に、完了した分割操作およびマージ操作に関する情報はDBA_STREAMS_SPLIT_MERGE_HISTに格納されます。

Oracle Streamsの接続先のスクリプトによる手動の分割およびマージ

この例を確認する前に、次の項を参照してください。

- 概念については、「手動の分割および生成されたスクリプトによるマージ」を参照してください。

- この例のOracle Streamsレプリケーション環境に関する想定については、「Oracle Streamsの分割およびマージの例」を参照してください。

この項の例では、スクリプトを生成して実行し、ストリームを分割およびマージします。そのため、SPLIT_STREAMSプロシージャのperform_actionsパラメータは、FALSEに設定されています。また、この例では、SPLIT_STREAMSプロシージャのauto_merge_thresholdパラメータがNULLに設定されているため、ストリームを適切なタイミングで手動でマージします。

次の手順を実行して、スクリプトを使用し、ストリームを分割およびマージします。

1. SQL*Plusで、Oracle Streams管理者として取得プロセスを含むデータベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

2. ディレクトリ・オブジェクトdb_dirが存在しない場合は、プロシージャによって生成されるスクリプトを保持できるようにこのディレクトリ・オブジェクトを作成します。

CREATE DIRECTORY db_dir AS '/usr/db_files';

3. 次のプロシージャを実行して、ストリームを分割するスクリプトを生成します。

DECLARE
schedule_name  VARCHAR2(30);
job_name       VARCHAR2(30);
BEGIN
DBMS_STREAMS_ADM.SPLIT_STREAMS(
propagation_name        => 'strms_prop_a',
cloned_propagation_name => 'cloned_prop_a',
cloned_queue_name       => 'cloned_queue',
cloned_capture_name     => 'cloned_capture',
perform_actions         => FALSE,
script_name             => 'split.sql',
script_directory_object => 'db_dir',
auto_merge_threshold    => NULL,
schedule_name           => schedule_name,
merge_job_name          => job_name);
END;
/

このプロシージャを実行すると、split.sqlスクリプトが生成されます。このスクリプトには、伝播strms_prop_aを介して送信されているストリームを、strms_capture取得プロセスから送信されている他の伝播から分割するアクションが含まれています。

4. db_dirディレクトリ・オブジェクトによって使用されるディレクトリに移動して、テキスト・エディタでsplit.sqlスクリプトをオープンします。

5. スクリプトを確認し、必要に応じて変更します。

6. スクリプトを保存してクローズします。

7. Oracle Streams管理者としてSQL*Plusに接続したままで、スクリプトを実行します。

@/usr/db_files/split.sql

このスクリプトを実行すると、次のアクションが実行されます。

- DBMS_STREAMS_ADMパッケージのSET_UP_QUEUEプロシージャが実行され、キューcloned_queueが作成されます。

- DBMS_PROPAGATION_ADMパッケージのCREATE_PROPAGATIONプロシージャが実行され、伝播cloned_prop_aが作成されます。この新しい伝播では、cloned_queueキューからstrms_prop_a伝播によって使用されている既存の宛先キューにメッセージが伝播されます。クローニングされた伝播cloned_prop_aでは、元の伝播strms_prop_aと同じルール・セットが使用されます。
CREATE_PROPAGATIONプロシージャによって、original_propagation_nameパラメータがstrms_prop_aに、auto_merge_thresholdパラメータがNULLに設定されます。

- DBMS_CAPTURE_ADMパッケージのSTOP_CAPTUREプロシージャが実行され、取得プロセスstrms_captureが停止されます。

- 元の伝播strms_prop_aの確認済SCNが問い合されます。確認済SCNとは、伝播によって送信された変更を適用する適用プロセスによって最後に確認されたSCNです。伝播の確認済SCNは、DBA_PROPAGATIONビューのACKED_SCN値に示されます。

- DBMS_CAPTURE_ADMパッケージのCREATE_CAPTUREプロシージャが実行され、取得プロセスcloned_captureが作成されます。cloned_captureの開始SCNは、strms_prop_a伝播の確認済SCNの値に設定されます。クローニングされた取得プロセスcloned_captureでは、元の取得プロセスstrms_captureと同じルール・セットが使用されます。

- DBMS_PROPAGATION_ADMパッケージのDROP_PROPAGATIONプロシージャが実行され、元の伝播strms_prop_aが削除されます。

- DBMS_CAPTURE_ADMパッケージのSTART_CAPTUREプロシージャが実行され、開始SCNがstrms_prop_a伝播の確認済SCNの値に設定された、元の取得プロセスstrms_captureが起動されます。

8. cloned_prop_aの宛先で発生した問題を解決します。宛先データベースの適用プロセスで、クローニングされた取得プロセスからの変更の受入れが可能になったら、問題は解決しています。

9. Oracle Streams管理者として接続したまま、次のプロシージャを実行して、クローニングされた取得プロセスを起動します。

exec DBMS_CAPTURE_ADM.START_CAPTURE('cloned_capture');

10. クローニングされた取得プロセスが元の取得プロセスに対する遅延を回復する(またはほぼ回復する)まで、Oracle Streamsレプリケーション環境を監視します。具体的には、各取得プロセスのGV$STREAMS_CAPTUREビューのCAPTURE_MESSAGE_CREATION_TIME列を問い合せます。
次の問合せを実行して、各取得プロセスのCAPTURE_MESSAGE_CREATE_TIMEを定期的に確認します。

SELECT CAPTURE_NAME,
TO_CHAR(CAPTURE_MESSAGE_CREATE_TIME, 'HH24:MI:SS MM/DD/YY')
FROM GV$STREAMS_CAPTURE;

クローニングされた取得プロセスcloned_captureと元の取得プロセスstrms_captureのCAPTURE_MESSAGE_CREATE_TIMEの差が比較的小さくなるまで、次の手順には進まないでください。

11. 次のプロシージャを実行して、ストリームをマージするスクリプトを生成します。

BEGIN
DBMS_STREAMS_ADM.MERGE_STREAMS(
cloned_propagation_name => 'cloned_prop_a',
perform_actions         => FALSE,
script_name             => 'merge.sql',
script_directory_object => 'db_dir');
END;
/

このプロシージャを実行すると、merge.sqlスクリプトが生成されます。このスクリプトには、伝播cloned_prop_aを介して送信されているストリームを、strms_capture取得プロセスから送信されている他の伝播とマージするアクションが含まれています。

12. db_dirディレクトリ・オブジェクトによって使用されるディレクトリに移動して、テキスト・エディタでmerge.sqlスクリプトをオープンします。

13. スクリプトを確認し、必要に応じて変更します。

14. スクリプトを保存してクローズします。

15. Oracle Streams管理者としてSQL*Plusに接続したままで、スクリプトを実行します。

@/usr/db_files/merge.sql

このスクリプトを実行すると、次のアクションが実行されます。

- DBMS_CAPTURE_ADMパッケージのSTOP_CAPTUREプロシージャが実行され、クローニングされた取得プロセスcloned_captureが停止されます。

- DBMS_CAPTURE_ADMパッケージのSTOP_CAPTUREプロシージャが実行され、元の取得プロセスstrms_captureが停止されます。

- DBMS_PROPAGATION_ADMパッケージのCREATE_PROPAGATIONプロシージャが実行され、伝播strms_prop_aが再作成されます。

- 元の取得プロセスstrms_captureが、次の2つのSCN値のうちで小さい方のSCN値から起動されます。

- クローニングされた伝播cloned_prop_aの確認済SCN

- 元の取得プロセスによって取得された変更を伝播する他の伝播(この例では伝播strms_prop_bおよびstrms_prop_c)の最も小さい確認済SCN

strms_capture取得プロセスが起動されると、このプロセスによって取得済の変更が再取得されたり、クローニングされた取得プロセスcloned_captureによって取得済の変更が取得される場合があります。いずれの場合も、関連する適用プロセスによって、重複して受信した変更が破棄されます。

- DBMS_PROPAGATION_ADMパッケージのDROP_PROPAGATIONプロシージャが実行され、クローニングされた伝播cloned_prop_aが削除されます。

- DBMS_CAPTURE_ADMパッケージのDROP_CAPTUREプロシージャが実行され、クローニングされた取得プロセスcloned_captureが削除されます。

- DBMS_STREAMS_ADMパッケージのREMOVE_QUEUEプロシージャが実行され、クローニングされたキューcloned_queueが削除されます。

スクリプトが正常に実行された後は、ストリームがマージされ、Oracle Streamsレプリケーション環境に、分割操作およびマージ操作の前と同じコンポーネントが存在するようになります。今後の参照用に、完了した分割操作およびマージ操作に関する情報はDBA_STREAMS_SPLIT_MERGE_HISTに格納されます。

ソース・データベースのDBIDまたはグローバル名の変更

通常、あるデータベースが別のデータベースのクローンである場合、データベース管理者はそのデータベースのDBIDおよびグローバル名を変更します。V$DATABASE動的パフォーマンス・ビューでDBID列を問い合せると、データベースのDBIDを確認でき、GLOBAL_NAME静的データ・ディクショナリ・ビューを問い合せると、データベースのグローバル名を確認できます。ソース・データベースのDBIDまたはグローバル名を変更すると、そのソース・データベースで発生した変更を取得する既存の取得プロセスは使用不可になります。取得プロセスは、ソース・データベースで発生した変更を取得するローカルの取得プロセスまたはダウンストリームの取得プロセスになることが可能です。ソース・データベースの変更を適用する既存の適用プロセスも、使用不可になります。ただし、伝播ルールを変更する必要がある可能性はありますが、既存の同期取得および伝播を再作成する必要はありません。

DBIDまたはグローバル名を変更したソース・データベースに対する変更を取得プロセスまたは同期取得で取得している場合は、次の手順を実行します。

1. ソース・データベースを停止します。

2. STARTUP RESTRICTを使用し、RESTRICTED SESSIONを有効化してソース・データベースを再起動します。

3. DBMS_CAPTURE_ADMパッケージのDROP_CAPTUREプロシージャを使用して、取得プロセスを削除します。取得プロセスは、ソース・データベースのローカルの取得プロセスか、またはリモート・データベースのダウンストリームの取得プロセスである場合があります。同期取得を削除する必要はありません。

4. ソース・データベースでALTER SYSTEM SWITCH LOGFILE文を実行します。

5. ソース・データベースですでに変更が取得されている場合は、このソース・データベースで発生した変更を適用するすべての宛先データベースで、データを手動で再同期化します。まだデータベースで変更が取得されていない場合は、この手順は不要です。

6. ソース・データベース名を条件として使用しているルールを変更します。必要に応じて、これらのルールでソース・データベース名をソース・データベースの新しいグローバル名に変更します。環境内のローカル・データベースおよびリモート・データベースで、取得プロセス、伝播および適用プロセスのルールを変更する必要がある場合があります。通常、同期取得ルールには、ソース・データベースの条件は含まれていません。

7. 手順3で削除した取得プロセスからの変更を適用する適用プロセスを削除します。適用プロセスを削除するには、DBMS_APPLY_ADMパッケージのDROP_APPLYプロシージャを使用します。同期取得で取得した変更を適用する適用プロセスは、削除する必要はありません。

8. ソース・データベースの変更を適用する宛先データベースごとに、手順7で削除した適用プロセスを再作成します。各適用プロセスを、削除される前と同じルール・セットに関連付ける必要がある場合があります。手順については、第7章「暗黙的適用の構成」を参照してください。

9. 必要に応じて、手順3で削除した取得プロセスを再作成します。取得プロセスを、手順3で削除した取得プロセスと同じルール・セットに関連付ける必要がある場合があります。手順については、「取得プロセスの構成」を参照してください。

10. ソース・データベースで、再作成した取得プロセスによって変更が取得されるデータベース・オブジェクトについて、インスタンス化の準備を行います。「ソース・データベースでインスタンス化を行うためのデータベース・オブジェクトの準備」を参照してください。

11. ソース・データベースの変更を適用する宛先データベースごとに、ソース・データベースの変更を適用するすべてのデータベース・オブジェクトについて、インスタンス化SCNを設定します。手順については、「宛先データベースでのインスタンス化SCNの設定」を参照してください。

12. ALTER SYSTEM DISABLE RESTRICTED SESSION文を使用し、RESTRICTED SESSIONを無効化します。

13. ソース・データベースの変更を適用する宛先データベースごとに、手順8で作成した適用プロセスを起動します。

14. ソース・データベースで、手順9で作成した取得プロセスを起動します。

関連項目:
DBNEWIDユーティリティを使用してデータベースのDBIDを変更する方法の詳細は、『Oracle Databaseユーティリティ』を参照してください。

複数ソース環境でのソース・データベースの再同期化

複数ソース環境とは、共有データに複数のソース・データベースが存在する環境です。複数ソース環境のソース・データベースを現在の時点までリカバリできない場合、この項で説明する方法を使用して、そのソース・データベースを環境内の他のソース・データベースと再同期化できます。データベースを現在の時点までリカバリできない理由には、アーカイブREDOログの破損や、オンラインREDOログ・グループのメディア障害などがあります。

たとえば、ある双方向のOracle Streams環境で、2つのデータベースが、レプリケートされたデータベース・オブジェクトおよびデータを共有していると想定します。この例では、再同期化する必要のあるデータベースをデータベースA、環境内の他のソース・データベースをデータベースBとします。この双方向のOracle Streams環境内のデータベースAを再同期化するには、次の手順を実行します。

1. データベースBがデータベースAから送信されたすべての変更を適用しているかどうか検証します。データベースBでV$BUFFERED_SUBSCRIBERSデータ・ディクショナリ・ビューを問い合せると、これらの変更を適用する適用プロセスのキュー内に適用されていない変更があるかどうかを判別できます。このような問合せの例については、『Oracle Streams概要および管理』の「各バッファ・キューからLCRをデキューする伝播の表示」の例を参照してください。すべての変更が適用されたら、次の手順に進みます。

2. DBMS_STREAMS_ADMパッケージのREMOVE_STREAMS_CONFIGURATIONプロシージャを実行して、データベースAからOracle Streams構成を削除します。このプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

3. データベースBで、データベースAの変更を適用する適用プロセスを削除します。後の手順で適用プロセスを再作成するため、この適用プロセスで使用されているルール・セットは削除しないでください。

4. 「既存の複数ソース環境への新規データベースの追加」の手順を完了し、Oracle Streams環境内にデータベースAを再度追加します。

Oracle Streams環境におけるデータベースのPoint-in-Timeリカバリの実行

Point-in-Timeリカバリとは、指定した現在以外の時刻、SCNまたはログ順序番号までデータベースをリカバリすることです。ここでは、Oracle Streamsレプリケーション環境でPoint-in-Timeリカバリを実行する方法について説明します。

- 単一ソース環境のソースにおけるPoint-in-Timeリカバリの実行

- 複数ソース環境におけるPoint-in-Timeリカバリの実行

- 宛先データベースにおけるPoint-in-Timeリカバリの実行

関連項目:
Point-in-Timeリカバリの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

単一ソース環境のソースにおけるPoint-in-Timeリカバリの実行

単一ソースのOracle Streamsレプリケーション環境とは、共有データのソース・データベースが1つのみの環境です。単一ソースのOracle Streams環境のソース・データベースでデータベースのPoint-in-Timeリカバリが必要であり、ソース・データベースで生成される変更を取得するすべての取得プロセスが実行されている場合は、これらの取得プロセスを停止してから、リカバリ操作を実行する必要があります。ソース・データベースで生成される変更を取得するローカルの取得プロセス、およびダウンストリームの取得プロセスの両方を停止する必要があります。通常、データベース管理者は、Point-in-Timeリカバリ中にデータベースのログ順序番号をリセットします。ALTER DATABASE OPEN RESETLOGS文は、ログ順序番号をリセットする文の一例です。

この項の手順では、次の特性を持つ単一ソース・レプリケーション環境を想定しています。

- ローカル取得プロセスまたはダウンストリーム取得プロセスである取得プロセスstrm01_captureが1つのみ存在します。

- グローバル名dest.example.comを持つ宛先データベースが1つのみ存在します。

- 宛先データベースに、適用プロセスstrm01_applyが1つのみ存在します。

ソース・データベースでPoint-in-Timeリカバリを実行する必要がある場合、宛先データベースで適用されるトランザクションを使用してこの項の手順を実行すると、ソース・データベースでできるかぎり多くのトランザクションをリカバリできます。この項の手順では、ソースのPoint-in-Time SCNより後に宛先データベースで適用されたトランザクションを識別し、ソース・データベースでそれらのトランザクションを実行することを想定しています。

注意:
単一ソースのOracle Streamsレプリケーション環境でPoint-in-Timeリカバリを実行する場合は、適用プロセス・パラメータcommit_serializationをFULLに設定することをお薦めします。

単一ソースのOracle Streamsレプリケーション環境のソース・データベースでPoint-in-Timeリカバリを実行するには、次の手順を実行します。

1. ソース・データベースでPoint-in-Timeリカバリを実行します(実行済でない場合)。後の手順で必要になるため、Point-in-TimeリカバリSCNをメモします。

2. ソース・データベースが制限付きモードになっていることを確認します。

3. 取得プロセスを実行するデータベースに接続し、取得プロセスで使用するルール・セットを表示します。
取得プロセスで使用するルール・セットを表示するには、次の問合せを実行します。

COLUMN CAPTURE_NAME HEADING 'Capture|Process|Name' FORMAT A15
COLUMN RULE_SET_OWNER HEADING 'Positive|Rule Owner' FORMAT A15
COLUMN RULE_SET_NAME HEADING 'Positive|Rule Set' FORMAT A15
COLUMN NEGATIVE_RULE_SET_OWNER HEADING 'Negative|Rule Owner' FORMAT A15
COLUMN NEGATIVE_RULE_SET_NAME HEADING 'Negative|Rule Set' FORMAT A15

SELECT CAPTURE_NAME,
RULE_SET_OWNER,
RULE_SET_NAME,
NEGATIVE_RULE_SET_OWNER,
NEGATIVE_RULE_SET_NAME
FROM DBA_CAPTURE;

取得プロセスで使用するルール・セットをメモします。手順12で新規の取得プロセスにこれらのルール・セットを指定する必要があります。

4. 宛先データベースに接続し、適用プロセスで使用するルール・セットを表示します。
取得プロセスで使用するルール・セットを表示するには、次の問合せを実行します。

COLUMN APPLY_NAME HEADING 'Apply|Process|Name' FORMAT A15
COLUMN RULE_SET_OWNER HEADING 'Positive|Rule Owner' FORMAT A15
COLUMN RULE_SET_NAME HEADING 'Positive|Rule Set' FORMAT A15
COLUMN NEGATIVE_RULE_SET_OWNER HEADING 'Negative|Rule Owner' FORMAT A15
COLUMN NEGATIVE_RULE_SET_NAME HEADING 'Negative|Rule Set' FORMAT A15

SELECT APPLY_NAME,
RULE_SET_OWNER,
RULE_SET_NAME,
NEGATIVE_RULE_SET_OWNER,
NEGATIVE_RULE_SET_NAME
FROM DBA_APPLY;

適用プロセスで使用するルール・セットをメモします。手順kで新規の適用プロセスにこれらのルール・セットを指定する必要があります。

5. DBMS_CAPTURE_ADMパッケージのSTOP_CAPTUREプロシージャを使用して、取得プロセスを停止します。

6. ソース・データベースで、データ・ディクショナリの構築を実行します。

SET SERVEROUTPUT ON
DECLARE
scn  NUMBER;
BEGIN
DBMS_CAPTURE_ADM.BUILD(
first_scn => scn);
DBMS_OUTPUT.PUT_LINE('First SCN Value = ' || scn);
END;
/

手順12で必要になるため、戻されたSCN値をメモします。

7. 宛先データベースで、適用プロセスのキューに含まれるソース・データベースからのすべてのトランザクションが適用されるまで待機します。これらのトランザクションが適用されると、適用プロセスはアイドル状態になります。V$STREAMS_APPLY_READERおよびV$STREAMS_APPLY_SERVERの両方で、STATE列を問い合せることができます。両方のビューで適用プロセスの状態がIDLEになってから、次の手順に進む必要があります。

8. 宛先データベースで問合せを実行して、適用されたトランザクションの最大SCNを判断します。

適用プロセスが実行中の場合は、次の問合せを実行します。

SELECT HWM_MESSAGE_NUMBER FROM V$STREAMS_APPLY_COORDINATOR
WHERE APPLY_NAME = 'STRM01_APPLY';

適用プロセスが無効化されている場合は、次の問合せを実行します。

SELECT APPLIED_MESSAGE_NUMBER FROM DBA_APPLY_PROGRESS
WHERE APPLY_NAME = 'STRM01_APPLY';

後の手順で必要になるため、問合せで戻される最大適用SCNをメモします。

9. 手順8で取得した最大適用SCNが、手順1でメモしたPoint-in-TimeリカバリSCNより小さい場合は、手順10に進みます。手順8で取得した最大適用SCNが、手順1でメモしたPoint-in-TimeリカバリSCN以上の場合は、適用プロセスは、Point-in-TimeリカバリSCNの後で、ソース・データベースからのいくつかのトランザクションを適用しており、次の手順を実行する必要があります。

1. ソース・データベースで、Point-in-Time SCNの後に適用されたトランザクションを手動で実行します。これらのトランザクションをソース・データベースで実行する場合は、トランザクションが取得プロセスによって取得されないようにセッションのOracle Streamsタグを設定していることを確認します。Oracle Streamsセッション・タグが設定されていないと、これらの変更が宛先データベースに循環される場合があります。手順については、「現行セッションのOracle Streamsタグの管理」を参照してください。

2. ソース・データベースで、制限付きセッションを無効化します。

3. 手順11に進みます。手順10は実行しないでください。

10. 手順8で取得した最大適用SCNが、手順1でメモしたPoint-in-TimeリカバリSCNより小さい場合、適用プロセスは、Point-in-TimeリカバリSCNの後で、ソース・データベースからのどのトランザクションも適用していません。この場合は、次の手順を実行する必要があります。

1. ソース・データベースで、制限付きセッションを無効化します。

2. 宛先データベースで適用プロセスが実行中であることを確認します。

3. DBMS_CAPTURE_ADMパッケージのSET_PARAMETERプロシージャを使用して、元の取得プロセスのmaximum_scn取得プロセス・パラメータを、Point-in-TimeリカバリSCNに設定します。

4. 元の取得プロセスの開始SCNを、適用プロセスの最も古いSCNに設定します。実行中の適用プロセスの最も古いSCNを判断するには、宛先データベースで、V$STREAMS_APPLY_READER動的パフォーマンス・ビューのOLDEST_SCN_NUM列を問い合せます。取得プロセスの開始SCNを設定するには、DBMS_CAPTURE_ADMパッケージのALTER_CAPTUREプロシージャを実行する際にstart_scnパラメータを指定します。

5. 次のプロシージャを実行して、取得プロセスがアラート・ログに情報を書き込むことを確認します。

BEGIN
DBMS_CAPTURE_ADM.SET_PARAMETER(
capture_name => 'strm01_capture',
parameter    => 'write_alert_log',
value        => 'Y');
END;
/

6. DBMS_CAPTURE_ADMパッケージのSTART_CAPTUREプロシージャを使用して、元の取得プロセスを起動します。

7. DBA_CAPTUREデータ・ディクショナリ・ビューのCAPTURED_SCN列を問い合せて、元の取得プロセスがmaximum_scn設定値までのすべての変更を取得していることを確認します。問合せで戻される値がmaximum_scn値以上である場合、取得プロセスは自動的に停止します。取得プロセスが停止したら、次の手順に進みます。

8. アラート・ログでLAST_ENQUEUE_MESSAGE_NUMBERの値を検索します。後の手順で必要になるため、この値をメモします。

9. 宛先データベースで、すべての変更が適用されるまで待機します。宛先データベースで次の問合せを実行すると、適用プロセスstrm01_applyで適用される変更を監視できます。

SELECT DEQUEUED_MESSAGE_NUMBER
FROM V$STREAMS_APPLY_READER
WHERE APPLY_NAME = 'STRM01_APPLY' AND
DEQUEUED_MESSAGE_NUMBER = last_enqueue_message_number;

手順hでアラート・ログから検出したLAST_ENQUEUE_MESSAGE_NUMBERを、問合せの最後の行のlast_enqueue_message_number に代入します。この問合せが行を戻す場合、取得データベースからのすべての変更は宛先データベースで適用されています。

適用プロセスのリーダー・サーバーおよび各適用サーバーの状態がIDLEになっていることも確認します。たとえば、適用プロセスstrm01_applyに次の問合せを実行します。

SELECT STATE FROM V$STREAMS_APPLY_READER
WHERE APPLY_NAME = 'STRM01_APPLY';

SELECT STATE FROM V$STREAMS_APPLY_SERVER
WHERE APPLY_NAME = 'STRM01_APPLY';

どちらの問合せでもIDLEが戻ったら、次の手順に進みます。

10. 宛先データベースで、DBMS_APPLY_ADMパッケージのDROP_APPLYプロシージャを使用して、適用プロセスを削除します。

11. 宛先データベースで、新規の適用プロセスを作成します。新規の適用プロセスでは、元の適用プロセスと同じキューおよびルール・セットが使用される必要があります。

12. 宛先データベースで、DBMS_APPLY_ADMパッケージのSTART_APPLYプロシージャを使用して、新規の適用プロセスを起動します。

11. DBMS_CAPTURE_ADMパッケージのDROP_CAPTUREプロシージャを使用して、元の取得プロセスを削除します。

12. DBMS_CAPTURE_ADMパッケージのCREATE_CAPTUREプロシージャを使用して新規の取得プロセスを作成し、手順11で削除した取得プロセスと置き換えます。手順6でデータ・ディクショナリの構築によって戻されたSCNを、first_scnおよびstart_scnの両方のパラメータに指定します。新規の取得プロセスでは、元の取得プロセスと同じキューおよびルール・セットが使用される必要があります。

13. DBMS_CAPTURE_ADMパッケージのSTART_CAPTUREプロシージャを使用して、新規の取得プロセスを起動します。

複数ソース環境におけるPoint-in-Timeリカバリの実行

複数ソース環境とは、共有データに複数のソース・データベースが存在する環境です。複数ソースのOracle Streams環境のソース・データベースでデータベースのPoint-in-Timeリカバリが必要な場合、環境内の他のソース・データベースを使用して、Point-in-Timeリカバリ後にリカバリ対象のソース・データベースに対して行われた変更を再取得できます。

たとえば、複数ソースのOracle Streams環境で、あるソース・データベースが時刻T2に使用不可になり、それ以前の時刻T1までのPoint-in-Timeリカバリを実行する場合があります。T1までリカバリされると、リカバリ対象のデータベースでT1からT2の間に実行されたトランザクションは、リカバリ済のデータベースで失われます。ただし、リカバリ対象のデータベースが使用不可になる前に、これらのトランザクションが他のソース・データベースに伝播され、適用されていたと想定します。この場合、この他のソース・データベースを使用して、リカバリ済のデータベースに失われた変更をリストアできます。

具体的には、Point-in-Timeリカバリ後にリカバリ対象のデータベースに対して行われた変更をリストアするには、取得プロセスを構成してこれらの変更を他のソース・データベースのREDOログから再取得し、それらの変更を再取得したデータベースからリカバリ済のデータベースに伝播によって伝播して、リカバリ済のデータベースの適用プロセスで適用します。

他のソース・データベースで発生し、T1からT2の間にリカバリ対象のデータベースで適用された変更も失われているため、それらの変更をリカバリする必要があります。これを行うには、他のソース・データベースで取得プロセスを変更して、それ以前のSCNから変更の取得を開始します。このSCNは、リカバリ対象のデータベースの適用プロセスの最も古いSCNです。

リカバリ済のデータベースに失われた変更をリストアするには、次のSCN値が必要です。

- Point-in-Time SCN: リカバリ対象のデータベースのPoint-in-TimeリカバリのSCN。

- インスタンス化SCN: 変更が再適用されている間に、リカバリ済のデータベースでリカバリに含まれていた各データベース・オブジェクトに設定する必要があるインスタンス化SCNのSCN値。他のソース・データベースでは、このSCN値は、他のソース・データベースで適用され、リカバリ済のデータベースで失われた最初のトランザクションのコミットSCNより小さい値に相当します。

- 開始SCN: 他のソース・データベースで変更を再取得するために作成される取得プロセスに設定する開始SCNのSCN値。このSCN値は、他のソース・データベースの適用プロセスが、リカバリ済のデータベースで失われたトランザクションの適用を開始した最も古いSCNに相当します。この取得プロセスは、そのソース・データベース用に他のソース・データベースを使用するローカルの取得プロセスまたはダウンストリームの取得プロセスである場合があります。

- 最大SCN: 失われた変更を再取得するために作成される取得プロセスのmaximum_scnパラメータに設定する必要があるSCN値。取得プロセスは、このSCN値に達した時点で変更の取得を停止します。他のソース・データベースの現行のSCNが、この値に使用されます。

リカバリ対象のデータベースでPoint-in-Timeリカバリを実行する際に、Point-in-Time SCNをメモする必要があります。DBMS_STREAMS_ADMパッケージのGET_SCN_MAPPINGプロシージャを使用すると、他の必要なSCN値を判断できます。

関連項目:
GET_SCN_MAPPINGプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

宛先データベースにおけるPoint-in-Timeリカバリの実行

Oracle Streams環境の宛先データベースでデータベースのPoint-in-Timeリカバリが必要な場合は、Point-in-Timeリカバリ後に適用された取得済の変更を再適用する必要があります。

関連する取得プロセスごとに、次のいずれかの方法を選択して、Oracle Streams環境の宛先データベースでPoint-in-Timeリカバリを実行できます。

- 宛先データベースで適用される変更を取得する既存の取得プロセスについて、開始SCNをリセットします。

- 宛先データベースで再適用する必要のある変更を取得するように、新規の取得プロセスを作成します。

新規の取得プロセスを作成するよりも、既存の取得プロセスの開始SCNをリセットする方が簡単です。ただし、複数の宛先データベースで適用される変更が取得プロセスによって取得されると、Point-in-Timeリカバリを実行していないデータベースも含め、すべての宛先データベースに変更が再送信されます。変更がすでに宛先データベースで適用されている場合、その変更は適用プロセスで廃棄されますが、複数の宛先データベースに変更を再送信するために必要なネットワーク・リソースとコンピュータ・リソースを、使用しないようにすることが必要な場合があります。この場合は、リカバリ済の宛先データベースにのみ変更を伝播するように、新規の取得プロセスと新規の伝播を作成して一時的に使用できます。

ここでは、次の各タスクの手順について説明します。

- リカバリを実行するための既存の取得プロセスの開始SCNのリセット

- リカバリを実行するための新規の取得プロセスの作成

Point-in-Timeリカバリを実行した宛先データベースに複数の適用プロセスがある場合は、この項で説明するタスクの1つを適用プロセスごとに実行してください。

リカバリ中の宛先データベースに関して、次のいずれかの条件がTRUEである場合、どちらの方法も使用できません。

- 伝播では、永続LCRが宛先データベースに伝播されます。いずれの方法でも、宛先データベースでは、永続LCRではなく取得LCRのみが再適用されます。

- 有向ネットワーク構成では、宛先データベースは取得プロセスからのLCRをその他のデータベースに伝播させる目的で使用されますが、宛先データベースにはこの取得プロセスからのLCRは適用されません。

- 宛先データベースの適用プロセスの最も古いメッセージ番号が、この適用プロセス用の変更を取得する取得プロセスの先頭SCNより小さい値です。宛先データベースで次の問合せを実行すると、各適用プロセスの最も古いメッセージ番号(最も古いSCN)が表示されます。

SELECT APPLY_NAME, OLDEST_MESSAGE_NUMBER FROM DBA_APPLY_PROGRESS;

ソース・データベースで次の問合せを実行すると、各取得プロセスの先頭SCNが表示されます。

SELECT CAPTURE_NAME, FIRST_SCN FROM DBA_CAPTURE;

- 対象の開始SCNを含むアーカイブ・ログ・ファイルが使用不可になっています。

環境でこれらのいずれかの条件がTRUEである場合、この項で説明している方法は使用できません。かわりに、すべての宛先データベースでデータを手動で再同期化する必要があります。

注意:
単一ソースのレプリケーション環境で取得と適用の複合を使用している場合に宛先データベースでPoint-in-Timeリカバリを実行すると、Oracle Streamsの取得プロセスは、再起動時に変更を取得する場所を自動的に検出するため、追加の手順は必要ありません。詳細は、『Oracle Streams概要および管理』を参照してください。

関連項目:
取得プロセスに関連するSCN値および有向ネットワークの詳細は、『Oracle Streams概要および管理』を参照してください。

リカバリを実行するための既存の取得プロセスの開始SCNのリセット

Point-in-Timeリカバリを実行するために、既存の取得プロセスの開始SCNをリセットするように決定した場合は、次の手順を実行します。

1. 複数ソースのOracle Streams環境で、宛先データベースがソース・データベースでもある場合は、「複数ソース環境におけるPoint-in-Timeリカバリの実行」の手順を実行します。

2. ソース・データベースのソース・キューから宛先データベースの宛先キューに変更を伝播させる伝播を削除します。伝播を削除するには、DBMS_PROPAGATION_ADMパッケージのDROP_PROPAGATIONプロシージャを使用します。
有向ネットワークを使用しており、ソース・データベースと宛先データベースの間に中間データベースがある場合は、ソース・データベースの伝播を含め、宛先データベースへのパスに含まれる各中間データベースで伝播を削除します。

削除する伝播で使用されているルール・セットは削除しないでください。

既存の取得プロセスが、宛先データベースで構成されるダウンストリーム取得プロセスである場合、手順3でPoint-in-Timeリカバリを実行すると、ダウンストリーム取得プロセスは宛先データベースと同じ時点にリカバリされます。この場合、この項の手順3より後の手順は不要です。必要なREDOログ・ファイルは取得プロセスで使用可能であることに注意してください。

注意:
適切な伝播を削除する必要があります。無効化するのみでは不十分です。手順7で伝播を再作成しますが、この時点で削除すると、取得プロセスの開始SCNをリセットした後に作成されたLCRのみが確実に伝播されます。

関連項目:
有向ネットワークの詳細は、『Oracle Streams概要および管理』を参照してください。

3. 宛先データベースでPoint-in-Timeリカバリを実行します。

4. 宛先データベースで、適用プロセスについてソース・データベースからの最も古いメッセージ番号(最も古いSCN)を問い合せます。次に、問合せ結果をメモします。最も古いメッセージ番号とは、適用する必要があると思われる最も古いシステム変更番号(SCN)です。

宛先データベースで次の問合せを実行すると、各適用プロセスの最も古いメッセージ番号が表示されます。

SELECT APPLY_NAME, OLDEST_MESSAGE_NUMBER FROM DBA_APPLY_PROGRESS;

5. DBMS_CAPTURE_ADMパッケージのSTOP_CAPTUREプロシージャを使用して、既存の取得プロセスを停止します。

6. 既存の取得プロセスの開始SCNをリセットします。
既存の取得プロセスの開始SCNをリセットするには、DBMS_CAPTURE_ADMパッケージのALTER_CAPTUREプロシージャを実行し、start_scnパラメータを手順4の問合せでメモした値に設定します。たとえば、取得プロセスstrm01_captureの開始SCNを値829381993にリセットするには、次のALTER_CAPTUREプロシージャを実行します。

BEGIN
DBMS_CAPTURE_ADM.ALTER_CAPTURE(
capture_name  =>  'strm01_capture',
start_scn     =>  829381993);
END;
/

7. ソース・データベースと宛先データベースの間で有向ネットワークを使用していない場合は、DBMS_PROPAGATION_ADMパッケージのCREATE_PROPAGATIONプロシージャを使用して、変更をソース・キューから宛先キューに伝播させる新規の伝播を作成します。伝播の作成時には、元の伝播で使用していたルール・セットを指定します。

有向ネットワークを使用しており、ソース・データベースと宛先データベースの間に中間データベースがある場合は、ソース・データベースの伝播を含め、宛先データベースへのパスに含まれる各中間データベースで、新規の伝播を作成します。

8. DBMS_CAPTURE_ADMパッケージのSTART_CAPTUREプロシージャを使用して、既存の取得プロセスを起動します。

リカバリを実行するための新規の取得プロセスの作成

Point-in-Timeリカバリを実行するために取得プロセスを作成するように決定した場合は、次の手順を実行します。

1. 複数ソースのOracle Streams環境で、宛先データベースがソース・データベースでもある場合は、「複数ソース環境におけるPoint-in-Timeリカバリの実行」の手順を実行します。

2. ソース・データベースと宛先データベースの間で有向ネットワークを使用していない場合は、ソース・データベースのソース・キューから宛先データベースの宛先キューに変更を伝播させる伝播を削除します。伝播を削除するには、DBMS_PROPAGATION_ADMパッケージのDROP_PROPAGATIONプロシージャを使用します。

有向ネットワークを使用しており、ソース・データベースと宛先データベースの間に中間データベースがある場合は、最後の中間データベースと宛先データベースの間でLCRを伝播する伝播を削除します。他の中間データベースやソース・データベースでは、伝播を削除する必要はありません。

注意:
適切な伝播を削除する必要があります。伝播を無効化するのみでは不十分です。

関連項目:
有向ネットワークの詳細は、『Oracle Streams概要および管理』を参照してください。

3. 宛先データベースでPoint-in-Timeリカバリを実行します。

4. 宛先データベースで、適用プロセスについてソース・データベースからの最も古いメッセージ番号(最も古いSCN)を問い合せます。次に、問合せ結果をメモします。最も古いメッセージ番号とは、適用する必要があると思われる最も古いシステム変更番号(SCN)です。

宛先データベースで次の問合せを実行すると、各適用プロセスの最も古いメッセージ番号が表示されます。

SELECT APPLY_NAME, OLDEST_MESSAGE_NUMBER FROM DBA_APPLY_PROGRESS;

5. DBMS_STREAMS_ADMパッケージのSET_UP_QUEUEプロシージャを使用して、取得プロセスで使用するキューをソース・データベースに作成します。

有向ネットワークを使用しており、ソース・データベースと宛先データベースの間に中間データベースがある場合は、ソース・データベースの新規キューを含め、宛先データベースへのパスに含まれる各中間データベースでキューを作成します。宛先データベースでは新規キューを作成しないでください。

6. ソース・データベースと宛先データベースの間で有向ネットワークを使用していない場合は、DBMS_PROPAGATION_ADMパッケージのCREATE_PROPAGATIONプロシージャを使用して、変更を手順5で作成したソース・キューから宛先キューに伝播させる新規の伝播を作成します。伝播の作成時には、元の伝播で使用していたルール・セットを指定します。

有向ネットワークを使用しており、ソース・データベースと宛先データベースの間に中間データベースがある場合は、ソース・データベースから最初の中間データベースへの伝播を含め、宛先データベースへのパスに含まれる各中間データベースで伝播を作成します。これらの伝播では、手順7で作成する取得プロセスによって取得された変更が、手順5で作成したキュー間で伝播されます。

7. DBMS_CAPTURE_ADMパッケージのCREATE_CAPTUREプロシージャを使用して、ソース・データベースで新規の取得プロセスを作成します。source_queueパラメータを手順5で作成したローカル・キューに設定し、start_scnパラメータを手順4の問合せでメモした値に設定します。元の取得プロセスで使用していたルール・セットも指定します。元の取得プロセスで使用していたルール・セットによって、リカバリした宛先データベースに送信する必要のない変更が取得される場合は、一部のルールを元のルール・セットと共有するようにカスタマイズした小型のルール・セットを作成して使用できます。

8. DBMS_CAPTURE_ADMパッケージのSTART_CAPTUREプロシージャを使用して、手順7で作成した取得プロセスを起動します。

9. リカバリ後のデータベースの適用プロセスの最も古いメッセージ番号が、ソース・データベースの元の取得プロセスの取得番号に近づいた時点で、DBMS_CAPTURE_ADMパッケージのSTOP_CAPTUREプロシージャを使用して元の取得プロセスを停止します。

宛先データベースでは、次の問合せを使用すると、適用プロセスについてソース・データベースからの最も古いメッセージ番号を判断できます。

SELECT APPLY_NAME, OLDEST_MESSAGE_NUMBER FROM DBA_APPLY_PROGRESS;

ソース・データベースでは、次の問合せを使用すると、元の取得プロセスの取得番号を判断できます。

SELECT CAPTURE_NAME, CAPTURE_MESSAGE_NUMBER FROM V$STREAMS_CAPTURE;

10. リカバリ後のデータベースの適用プロセスの最も古いメッセージ番号が、ソース・データベースの元の取得プロセスの取得番号を超えた時点で、手順7で作成した新規の取得プロセスを削除します。

11. ソース・データベースと宛先データベースの間で有向ネットワークを使用していない場合は、手順6で作成した新規の伝播を削除します。
有向ネットワークを使用しており、ソース・データベースと宛先データベースの間に中間データベースがある場合は、ソース・データベースの新規の伝播を含め、宛先データベースへのパスに含まれる各中間データベースで新規の伝播を削除します。

12. ソース・データベースと宛先データベースの間で有向ネットワークを使用していない場合は、手順5で作成したキューを削除します。
有向ネットワークを使用しており、ソース・データベースと宛先データベースの間に中間データベースがある場合は、ソース・データベースの新規キューを含め、宛先データベースへのパスに含まれる各中間データベースで新規キューを削除します。宛先データベースではキューを削除しないでください。

13. ソース・データベースと宛先データベースの間で有向ネットワークを使用していない場合は、ソース・データベースの元のソース・キューから宛先データベースの宛先キューに変更を伝播させる伝播を作成します。伝播を作成するには、DBMS_PROPAGATION_ADMパッケージのCREATE_PROPAGATIONプロシージャを使用します。伝播の作成時には、元の伝播で使用していたルール・セットを指定します。
有向ネットワークを使用しており、ソース・データベースと宛先データベースの間に中間データベースがある場合は、最後の中間データベースから宛先データベースへの伝播を再作成します。これは、手順2で削除した伝播です。

14. 手順9で停止した取得プロセスを起動します。

手順8より後の手順は、すべて後から実行できます。また、手順9で説明した条件が満たされた時点で実行することもできます。

Oracle Streamsレプリケーション環境でのフラッシュバック問合せの実行

Oracle Flashback Queryを使用すると、履歴データを表示および修正できます。特定の時刻またはシステム変更番号(SCN)におけるデータベースに問合せを実行できます。単一ソースのOracle Streamsレプリケーション環境では、レプリケートされたデータベース・オブジェクトが同じであると予測する過去の時点のソース・データベースと宛先データベースでフラッシュバック問合せを使用できます。

ソース・データベースと宛先データベースで対応するSCNに対して問合せを実行すると、ソース・データベースで実行されたレプリケート・オブジェクトへのすべての変更が、宛先データベースに適用されているかどうかを判断できます。宛先データベースに適用エラーが発生している場合、フラッシュバック問合せによって、エラー発生時のレプリケート・オブジェクトの状態が表示されます。この情報は、エラーの原因と、エラーの最適な訂正方法を判断するために役立ちます。

各データベースでフラッシュバック問合せを実行すると、表の対応するSCNに特定の行が存在するかどうかを確認することもできます。対応するSCNの表データが一致しない場合、レプリケーション環境に問題があります。

問合せを実行するには、Oracle Streamsレプリケーション環境が次の条件を満たしている必要があります。

- レプリケーション環境は単一ソース環境であり、レプリケート・オブジェクトへの変更が1つのデータベースのみで取得される。

- Streamsのレプリケート・オブジェクトに対して変更が行われていない。つまり、変換、サブセット・ルール(行の移行)または適用ハンドラによって、レプリケート・オブジェクトのLCRが変更されていない。

- 宛先データベースのレプリケート・オブジェクトに対して、DMLまたはDDLの変更が行われていない。

- ソース・データベースと宛先データベースの両方がOracle Flashbackを使用するように構成されており、両方のデータベースのOracle Streams管理者がDBMS_FLASHBACKパッケージのサブプログラムを実行する権限を持っている。

- UNDO表領域に、各データベースで問合せを実行するために十分な情報が含まれている。Oracle Flashbackの機能では、自動UNDO管理システムを使用して、トランザクションの履歴データとメタデータが取得されます。各データベースのUNDO_RETENTION初期化パラメータは、フラッシュバック問合せを実行するために十分大きい値に設定されている必要があります。

Oracle Streamsレプリケーションは非同期であるため、フラッシュバック問合せで過去の時間を使用することはできません。ただし、DBMS_STREAMS_ADMパッケージのGET_SCN_MAPPINGプロシージャを使用することによって、ソース・データベースのSCNに対応する宛先データベースのSCNを判断することができます。

次の手順では、ソース・データベースでのフラッシュバック問合せのSCNがわかっていると想定しています。このSCNを使用して、宛先データベースでのフラッシュバック問合せの対応するSCNを判断できます。この問合せを実行するには、次の手順を実行します。

1. 宛先データベースで、フラッシュバック問合せ対象のおおまかな時間のアーカイブREDOログ・ファイルがデータベースで使用可能であることを確認します。GET_SCN_MAPPINGプロシージャを実行する場合、このREDOログ・ファイルが使用可能である必要があります。

2. SQL*Plusで、Oracle Streams管理者として宛先データベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

3. GET_SCN_MAPPINGプロシージャを実行します。この例では、ソース・データベースのSCNが52073983であり、ソース・データベースからの変更を適用する適用プロセスの名前がstrm01_applyであると想定しています。

SET SERVEROUTPUT ON
DECLARE
dest_scn   NUMBER;
start_scn  NUMBER;
dest_skip  DBMS_UTILITY.NAME_ARRAY;
BEGIN
DBMS_STREAMS_ADM.GET_SCN_MAPPING(
apply_name             => 'strm01_apply',
src_pit_scn            => '52073983',
dest_instantiation_scn => dest_scn,
dest_start_scn         => start_scn,
dest_skip_txn_ids      => dest_skip);
IF dest_skip.count = 0 THEN
DBMS_OUTPUT.PUT_LINE('No Skipped Transactions');
DBMS_OUTPUT.PUT_LINE('Destination SCN: ' || dest_scn);
ELSE
DBMS_OUTPUT.PUT_LINE('Destination SCN invalid for Flashback Query.');
DBMS_OUTPUT.PUT_LINE('At least one transaction was skipped.');
END IF;
END;
/

有効な接続先SCNが戻されたら、手順4に進みます。

適用プロセスで1つ以上のトランザクションがスキップされたために、宛先SCNがフラッシュバック問合せで有効ではない場合は、適用プロセス・パラメータcommit_serializationがDEPENDENT_TRANSACTIONSに設定され、非依存トランザクションが順不同で適用されています。戻されたdest_instantiation_scnの後に宛先データベースでコミットされたsrc_pit_scnより小さいソース・コミットSCNを持つトランザクションが1つ以上存在しています。したがって、指定したソースSCNのソース・データベースと宛先データベースの表は異なる可能性があります。別のソースSCNを選択して、手順1から再度実行できます。

4. ソースSCNを使用して、ソース・データベースでフラッシュバック問合せを実行します。

5. 手順3で戻されたSCNを使用して、宛先データベースでフラッシュバック問合せを実行します。

6. 手順4と手順5の問合せの結果を比較し、必要な操作を実行します。

関連項目:

- フラッシュバック問合せの詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。

- GET_SCN_MAPPINGプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

操作エラーからのリカバリ

DBMS_STREAMS_ADMパッケージのRECOVER_OPERATIONプロシージャを使用して、次の操作からのリカバリを行うことができます。

- 次を使用した分割操作およびマージ操作

- split_thresholdおよびmerge_threshold取得プロセス・パラメータによって起動される自動の分割操作およびマージ操作

- DBMS_STREAMS_ADMパッケージのSPLIT_STREAMSおよびMERGE_STREAMS_JOBプロシージャを使用する分割操作およびマージ操作

- DBMS_STREAMS_ADMパッケージのMAINTAIN_CHANGE_TABLEプロシージャによって実行される変更表構成操作

- DBMS_STREAMS_ADMパッケージにある次のプロシージャによって実行されるレプリケーション構成操作

- MAINTAIN_GLOBAL

- MAINTAIN_SCHEMAS

- MAINTAIN_SIMPLE_TTS

- MAINTAIN_TABLES

- MAINTAIN_TTS

- PRE_INSTANTIATION_SETUPおよびPOST_INSTANTIATION_SETUP

操作に関する情報は、操作の処理中に次のデータ・ディクショナリ・ビューに格納されます。

- DBA_RECOVERABLE_SCRIPT

- DBA_RECOVERABLE_SCRIPT_HIST

- DBA_RECOVERABLE_SCRIPT_PARAMS

- DBA_RECOVERABLE_SCRIPT_BLOCKS

- DBA_RECOVERABLE_SCRIPT_ERRORS

注意:
perform_actionsパラメータをFALSEに設定していずれかの構成プロシージャを実行し、スクリプトを使用してOracle Streamsレプリケーション環境を構成した場合、これらのデータ・ディクショナリ・ビューは移入されず、RECOVER_OPERATIONプロシージャを操作に使用できません。

操作が正常に完了すると、操作に関するメタデータがDBA_RECOVERABLE_SCRIPTビューからDBA_RECOVERABLE_SCRIPT_HISTビューに移動されます。その他のビュー(DBA_RECOVERABLE_SCRIPT_PARAMS、DBA_RECOVERABLE_SCRIPT_BLOCKSおよびDBA_RECOVERABLE_SCRIPT_ERRORS)では、操作に関する情報は30日間保存された後に自動的に削除されます。

操作でエラーが発生した場合、DBMS_STREAMS_ADMパッケージのRECOVER_OPERATIONプロシージャを使用して、操作のロールフォワード、操作のロールバックまたは操作に関するメタデータの削除を実行できます。具体的には、RECOVER_OPERATIONプロシージャのoperation_modeパラメータに次のオプションを使用できます。

- FORWARD: 障害が発生した時点から操作の完了が試行されます。このオプションを指定する前に、DBA_RECOVERABLE_SCRIPT_ERRORSビューにレポートされたエラーの原因となった条件を訂正します。
また、FORWARDオプションを使用してエラーの原因の詳細を取得することもできます。そのためには、SQL*PlusでSET SERVEROUTPUT ONを実行し、さらに適切なスクリプトIDを指定してRECOVER_OPERATIONプロシージャを実行します。RECOVER_OPERATIONプロシージャを実行すると、エラーの原因となったアクション、エラー番号およびエラー・メッセージが表示されます。

- ROLLBACK: 操作によって実行されたすべてのアクションがロールバックされます。また、このオプションを指定すると、ロールバックが正常に実行された場合に、操作に関するメタデータがDBA_RECOVERABLE_SCRIPTビューからDBA_RECOVERABLE_SCRIPT_HISTビューに移動されます。他のビューでは、操作に関する情報は30日間保存されます。

- PURGE: 操作をロールバックせずに、操作に関するメタデータがDBA_RECOVERABLE_SCRIPTビューからDBA_RECOVERABLE_SCRIPT_HISTビューに移動されます。他のビューでは、操作に関する情報は30日間保存されます。

リカバリ操作の完了後、操作に関する情報はDBA_RECOVERABLE_SCRIPT_HISTビューに格納されます。STATUS列には、リカバリ操作ごとにEXECUTEDまたはPURGEDが表示されます。

注意:
RECOVER_OPERATIONプロシージャを実行するには、両方のデータベースがOracle Database 10g リリース2以上のデータベースである必要があります。

関連項目:

- これらのプロシージャを使用してOracle Streamsレプリケーション環境を構成する方法の詳細は、「DBMS_STREAMS_ADMパッケージを使用したレプリケーションの構成」を参照してください。

- これらのプロシージャを実行する前に満たす必要がある前提条件については、「Oracle Streamsレプリケーションを構成する前に実行するタスク」を参照してください。

- 『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』

リカバリの例

ここでは、エラーの発生によってMAINTAIN_SCHEMASプロシージャが停止する例について説明します。取得データベースでの実行中に次のプロシージャでエラーが発生したと想定します。

BEGIN
DBMS_STREAMS_ADM.MAINTAIN_SCHEMAS(
schema_names                 => 'hr',
source_directory_object      => 'SOURCE_DIRECTORY',
destination_directory_object => 'DEST_DIRECTORY',
source_database              => 'dbs1.example.com',
destination_database         => 'dbs2.example.com',
perform_actions              => TRUE,
dump_file_name               => 'export_hr.dmp',
capture_queue_table          => 'rep_capture_queue_table',
capture_queue_name           => 'rep_capture_queue',
capture_queue_user           => NULL,
apply_queue_table            => 'rep_dest_queue_table',
apply_queue_name             => 'rep_dest_queue',
apply_queue_user             => NULL,
capture_name                 => 'capture_hr',
propagation_name             => 'prop_hr',
apply_name                   => 'apply_hr',
log_file                     => 'export_hr.clg',
bi_directional               => FALSE,
include_ddl                  => TRUE,
instantiation                => DBMS_STREAMS_ADM.INSTANTIATION_SCHEMA);
END;
/

次の手順を実行して、問題を診断し、操作をリカバリします。

1. SQL*Plusで、Oracle Streams管理者として取得データベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

2. 次の問合せを実行して、操作のSCRIPT_ID値を判断します。

SELECT SCRIPT_ID FROM DBA_RECOVERABLE_SCRIPT ORDER BY CREATION_TIME DESC;

この問合せでは、エラーが発生したのは最新の構成操作であると想定しています。したがって、問合せで複数のSCRIPT_IDが戻される場合は、リストで最初に表示されるSCRIPT_IDを使用します。

3. DBA_RECOVERABLE_SCRIPT_ERRORSデータ・ディクショナリ・ビューを問い合せてエラーがないかどうかを判別し、手順2で戻されたSCRIPT_IDをWHERE句に指定します。

たとえば、SCRIPT_IDがF73ED2C9E96B27B0E030578CB10B2424である場合は、次の問合せを実行します。

COLUMN SCRIPT_ID     HEADING 'Script ID'     FORMAT A35
COLUMN BLOCK_NUM     HEADING 'Block|Number' FORMAT 999999
COLUMN ERROR_MESSAGE HEADING 'Error Message' FORMAT A33

SELECT BLOCK_NUM, ERROR_MESSAGE
FROM DBA_RECOVERABLE_SCRIPT_ERRORS
WHERE SCRIPT_ID = 'F73ED2C9E96B27B0E030578CB10B2424';

この問合せでは、次の出力が戻されます。

Block
Number Error Message
------- ---------------------------------
12 ORA-39001: invalid argument value

4. 手順2で戻されたスクリプトIDおよび手順3で戻されたブロック番号をDBA_RECOVERABLE_SCRIPT_BLOCKSデータ・ディクショナリ・ビューで問い合せて、エラーが発生したブロックに関する情報を取得します。
たとえば、スクリプトIDがF73ED2C9E96B27B0E030578CB10B2424、ブロック番号が12の場合は、次の問合せを実行します。

COLUMN FORWARD_BLOCK        HEADING 'Forward Block'               FORMAT A50
COLUMN FORWARD_BLOCK_DBLINK HEADING 'Forward Block|Database Link' FORMAT A13
COLUMN STATUS               HEADING 'Status'                      FORMAT A12

SET LONG 10000
SELECT FORWARD_BLOCK,
FORWARD_BLOCK_DBLINK,
STATUS
FROM DBA_RECOVERABLE_SCRIPT_BLOCKS
WHERE SCRIPT_ID = 'F73ED2C9E96B27B0E030578CB10B2424' AND
BLOCK_NUM = 12;

この出力には、次の情報が表示されます。

- FORWARD_BLOCK列には、指定したブロック内のプロシージャによって実行されたアクションの詳細が表示されます。必要に応じて、出力をファイルにスプールします。この例では、ブロック12のFORWARD_BLOCK列にデータ・ポンプ・エクスポートのコードが含まれています。

- FORWARD_BLOCK_DBLINK列には、ブロックが実行されたデータベースが表示されます。この例では、エラーの発生時にデータ・ポンプ・エクスポートがDBS1.EXAMPLE.COMで実行されていたため、ブロック12のFORWARD_BLOCK_DBLINK列にDBS1.EXAMPLE.COMが表示されます。

- STATUS列には、ブロック実行の状態が表示されます。この例では、ブロック12のSTATUS列にはERRORが表示されます。

5. オプションで、取得データベースでSET SERVEROUTPUT ONを指定してRECOVER_OPERATIONプロシージャを実行し、エラーの詳細を表示します。

SET SERVEROUTPUT ON
BEGIN
DBMS_STREAMS_ADM.RECOVER_OPERATION(
script_id       => 'F73ED2C9E96B27B0E030578CB10B2424',
operation_mode  => 'FORWARD');
END;
/

サーバー出力をオンにすると、エラーの原因となったアクションが再度実行され、そのアクションとこれにより生じたエラーが表示されます。

6. 前述の手順で生成された出力を解析し、問題を診断します。手順3で戻された出力には、次の情報が提供されます。

- 構成操作の一意識別子はF73ED2C9E96B27B0E030578CB10B2424です。この値は、SCRIPT_IDフィールドに戻されたRAW値です。

- 問合せによって1つの行のみが戻されたため、実行中のOracle Streams構成プロシージャは1つのみです。問合せによって複数の行が戻された場合、DBA_RECOVERABLE_SCRIPTおよびDBA_RECOVERABLE_SCRIPT_PARAMSビューを問い合せて、その構成操作に該当するスクリプトIDを判別します。

- ORA-39001エラーの原因は、『Oracle Databaseエラー・メッセージ』ではユーザーが指定したAPIパラメータのタイプまたは値範囲が不適切であると示されています。DBMS_DATAPUMP.GET_STATUSによって提供される後続のメッセージに、エラーの詳細が説明されます。

- DBA_RECOVERABLE_SCRIPT_BLOCKSビューを問い合せると、データ・ポンプ・エクスポート中にエラーが発生したことが示されます。

問合せの出力には、MAINTAIN_SCHEMASプロシージャでデータ・ポンプ・エラーが発生したことが示されています。MAINTAIN_SCHEMASプロシージャのinstantiationパラメータがDBMS_STREAMS_ADM.INSTANTIATION_SCHEMAに設定されていたことに注意してください。この設定は、MAINTAIN_SCHEMASプロシージャによってデータ・ポンプ・エクスポート/インポートを使用してインスタンス化が実行されることを意味します。データ・ポンプ・エクスポート・ダンプ・ファイルが、エクスポート/インポートを完了するために生成されます。

通常、データ・ポンプ・エラーは次のいずれかの条件が原因で発生します。

- エクスポート・ダンプ・ファイルの格納に使用される1つ以上のディレクトリ・オブジェクトが存在しない。

- プロシージャを実行しているユーザーが、指定されたディレクトリ・オブジェクトに対するアクセス権を持っていない。

- プロシージャによって生成されたエクスポート・ダンプ・ファイルと同じ名前のエクスポート・ダンプ・ファイルが、source_directory_objectまたはdestination_directory_objectパラメータに指定されたディレクトリにすでに存在する。

7. 取得データベースでDBA_RECOVERABLE_SCRIPT_PARAMSデータ・ディクショナリ・ビューを問い合せて、MAINTAIN_SCHEMASプロシージャの実行中に指定されたディレクトリ・オブジェクトの名前を判別します。

COLUMN PARAMETER HEADING 'Parameter' FORMAT A30
COLUMN VALUE     HEADING 'Value'     FORMAT A45

SELECT PARAMETER,
VALUE
FROM DBA_RECOVERABLE_SCRIPT_PARAMS
WHERE SCRIPT_ID = 'F73ED2C9E96B27B0E030578CB10B2424';

この問合せでは、次の出力が戻されます。

Parameter                      Value
------------------------------ ---------------------------------------------
SOURCE_DIRECTORY_OBJECT        SOURCE_DIRECTORY
DESTINATION_DIRECTORY_OBJECT   DEST_DIRECTORY
SOURCE_DATABASE                DBS1.EXAMPLE
DESTINATION_DATABASE           DBS2.EXAMPLE
CAPTURE_QUEUE_TABLE            REP_CAPTURE_QUEUE_TABLE
CAPTURE_QUEUE_OWNER            STRMADMIN
CAPTURE_QUEUE_NAME             REP_CAPTURE_QUEUE
CAPTURE_QUEUE_USER
APPLY_QUEUE_TABLE              REP_DEST_QUEUE_TABLE
APPLY_QUEUE_OWNER              STRMADMIN
APPLY_QUEUE_NAME               REP_DEST_QUEUE
APPLY_QUEUE_USER
CAPTURE_NAME                   CAPTURE_HR
APPLY_NAME                     APPLY_HR
PROPAGATION_NAME               PROP_HR
INSTANTIATION                  INSTANTIATION_SCHEMA
BI_DIRECTIONAL                 TRUE
INCLUDE_DDL                    TRUE
LOG_FILE                       export_hr.clg
DUMP_FILE_NAME                 export_hr.dmp
SCHEMA_NAMES                   HR

8. source_directory_objectパラメータに指定されたディレクトリ・オブジェクトがソース・データベースに存在し、destination_directory_objectパラメータに指定されたディレクトリ・オブジェクトが宛先データベースに存在していることを確認します。これらのディレクトリ・オブジェクトが存在するかどうかをチェックするには、DBA_DIRECTORIESデータ・ディクショナリ・ビューを問い合せます。
この例では、SOURCE_DIRECTORYディレクトリ・オブジェクトがソース・データベースに存在せず、DEST_DIRECTORYディレクトリ・オブジェクトが宛先データベースに存在していないことを想定しています。エクスポート・ダンプ・ファイルに使用されるディレクトリ・オブジェクトが存在していなかったため、データ・ポンプ・エラーが発生しました。

9. SQL文CREATE DIRECTORYを使用して、ソース・データベースおよび宛先データベースに、必要なディレクトリ・オブジェクトを作成します。手順については、「必要なディレクトリ・オブジェクトの作成」を参照してください。

10. 取得データベースでRECOVER_OPERATIONプロシージャを実行します。

BEGIN
DBMS_STREAMS_ADM.RECOVER_OPERATION(
script_id       => 'F73ED2C9E96B27B0E030578CB10B2424',
operation_mode  => 'FORWARD');
END;
/

構成を完了するには、script_idパラメータが手順3で判別した値に設定され、operation_modeパラメータがFORWARDに設定されていることに注意してください。また、RECOVER_OPERATIONプロシージャは、構成プロシージャが実行されたデータベースで実行する必要があります。

13 データの比較および収束

この章では、DBMS_COMPARISONパッケージを使用して、異なる2つのデータベースでデータベース・オブジェクトのデータを比較および収束する方法について説明します。また、作成した比較を管理する方法、およびデータ・ディクショナリ・ビューを問い合せて比較と比較結果に関する情報を取得する方法についても説明します。

この章の内容は次のとおりです。

- データの比較および収束

- DBMS_COMPARISONパッケージに関する他のマニュアル

- 共有データベース・オブジェクトの比較および収束の準備

- 2つのデータベースのデータベース・オブジェクトの拡散の例

- 2つのデータベースの共有データベース・オブジェクトの比較

- 比較および比較結果に関する情報の表示

- 共有データベース・オブジェクトの収束

- 比較の比較結果の再確認

- 比較結果のパージ

- 比較の削除

- Oracle Streamsレプリケーション環境でのDBMS_COMPARISONの使用

関連項目:
DBMS_COMPARISONパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

データの比較および収束

DBMS_COMPARISONパッケージを使用すると、異なるデータベースのデータベース・オブジェクトを比較して違いを識別できます。また、このパッケージを使用すると、異なるデータベースでデータベース・オブジェクトの一貫性が保持されるようにデータベース・オブジェクトを収束できます。通常、このパッケージは、複数のデータベースで1つのデータベース・オブジェクトを共有する環境で使用されます。同じデータベース・オブジェクトのコピーが複数のデータベースに存在する場合、そのデータベース・オブジェクトは共有データベース・オブジェクトとなります。

共有データベース・オブジェクトは、データ・レプリケーションによって保持できます。たとえば、マテリアライズド・ビューまたはOracle Streamsコンポーネントによって、データベース・オブジェクトをレプリケートして複数のデータベースで保持できます。また、カスタム・アプリケーションによって、共有データベース・オブジェクトを保持することもできます。データベース・オブジェクトが共有されている場合、そのデータベース・オブジェクトを共有するデータベースでデータベース・オブジェクトが拡散する可能性があります。DBMS_COMPARISONパッケージを使用すると、共有データベース・オブジェクト間での違いを識別できます。違いの識別後、必要に応じて、このパッケージを使用して共有データベース・オブジェクトを同期化することもできます。

DBMS_COMPARISONパッケージでは、次のタイプのデータベース・オブジェクトを比較できます。

- 表

- 単一表ビュー

- マテリアライズド・ビュー

- 表、単一表ビューおよびマテリアライズド・ビューのシノニム

異なるデータベースで、様々なタイプのデータベース・オブジェクトを比較および収束できます。たとえば、このパッケージを使用して、あるデータベースの表と別のデータベースのマテリアライズド・ビューを比較および収束できます。

2つのデータベース・オブジェクト間の比較を作成するには、DBMS_COMPARISONパッケージのCREATE_COMPARISONプロシージャを使用します。比較の作成後、COMPAREファンクションを使用して比較を随時実行できます。COMPAREファンクションを実行すると、適切なデータ・ディクショナリ・ビューに比較結果が記録されます。COMPAREファンクションを実行するたびに、個別の比較結果が生成されます。

スキャン

COMPAREファンクションを実行するたびに、指定した比較に対して、1回以上の新しいスキャンが実行されます。スキャンでは、共有データベース・オブジェクトの一部またはすべての行で、特定の時点における違いが確認されます。COMPAREファンクションを1回実行すると、その比較結果に、1回以上のスキャンが含まれる場合があります。データベース・オブジェクトは複数回比較することができ、比較結果の各スキャンは一意のスキャンIDによって識別されます。

バケット

バケットとは、比較されているデータベース・オブジェクトの一定範囲の行です。バケットを使用すると、データベース・オブジェクトが複数の範囲に分割され、別々に比較されるため、パフォーマンスが向上します。それぞれの比較で、比較される行が適切な数のバケットに分割されます。使用されるバケットの数は、データベース・オブジェクトのサイズによって異なり、CREATE_COMPARISONプロシージャのmax_num_bucketsパラメータで指定されている、比較用のバケットの最大数より常に少なくなります。

COMPAREファンクションを使用してバケットを比較する場合、結果は次のいずれかになります。

- 違いが検出されなかった場合。この場合、次のバケットの比較へ進みます。

- 違いが検出された場合。この場合、バケットはより小さいバケットに分割され、それぞれの小さいバケットが比較されます。小さいバケットで違いが検出された場合、そのバケットはさらに小さいバケットに分割されます。このプロセスが、バケットで許容される行の最小数に達するまで繰り返されます。比較用のバケットの行の最小数は、CREATE_COMPARISONプロシージャのmin_rows_in_bucketパラメータで指定されています。
バケットの行の最小数に達すると、COMPAREファンクションによって、バケットに違いがあるかどうかがレポートされます。COMPAREファンクションには、perform_row_difパラメータが含まれています。このパラメータによって、違いが検出されたバケットの各行の違いをCOMPAREファンクションで識別するかどうかが制御されます。このパラメータがTRUEに設定されている場合、COMPAREファンクションで各行の違いが識別されます。このパラメータがFALSEに設定されている場合、COMPAREファンクションで特定の行の違いは識別されません。かわりに、バケットに違いがあることのみがレポートされます。

CREATE_COMPARISONプロシージャのmax_num_bucketsパラメータとmin_rows_in_bucketパラメータを調整して、特定のデータベース・オブジェクトを比較する際に最高のパフォーマンスを実現できます。比較の作成後、DBA_COMPARISONデータ・ディクショナリ・ビューのMAX_NUM_BUCKETS列およびMIN_ROWS_IN_BUCKET列を問い合せると、比較用のバケットの指定を参照できます。

DBMS_COMPARISONパッケージでは、バケットのすべての行の指定列に対してORA_HASHファンクションを使用して、そのバケットのハッシュ値を計算します。2つの対応するバケットのハッシュ値が一致した場合、それらのバケットの内容は一致しているとみなされます。行の値はデータベース間で転送されないため、ORA_HASHファンクションによってバケットを効率的に比較できます。かわりにハッシュ値のみが転送されます。

注意:
比較用の索引列がVARCHAR2またはCHAR列の場合、バケットの数が、max_num_bucketsパラメータで指定されている値を超える場合があります。

関連項目:

- ORA_HASHファンクションの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

- 索引列の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

親スキャンおよびルート・スキャン

COMPAREファンクションによってバケットが小さいバケットに分割されるたびに、小さいバケットに対して新しいスキャンが実行されます。大きいバケットを分析するスキャンは、大きいバケットから分割された小さいバケットを分析する各スキャンの親スキャンです。比較結果のルート・スキャンは、最も高いレベルの親スキャンです。ルート・スキャンには親は存在しません。親スキャンIDおよびルート・スキャンIDを確認するには、DBA_COMPARISON_SCANデータ・ディクショナリ・ビューを問い合せます。

スキャンを再チェックするにはRECHECKファンクションを使用し、スキャンを収束するにはCONVERGEプロシージャを使用します。比較結果のすべての行を再チェックまたは収束する場合は、適切なサブプログラムで比較結果のルート・スキャンIDを指定します。比較結果の一部の行を再チェックまたは収束する場合は、相違点が含まれているスキャンのスキャンIDを指定します。

たとえば、20個のバケットに違いが存在するスキャンは、違いが存在するそれぞれのバケットに比較用のバケットの行の最小数として指定されている数より多くの行が含まれている場合、親スキャンとなり、さらに20回のスキャンが実行されます。比較用のバケットの行の最小数を参照するには、DBA_COMPARISONデータ・ディクショナリ・ビューのMIN_ROWS_IN_BUCKET列を問い合せます。

関連項目:
DBMS_COMPARISONパッケージに関連するビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

スキャンおよびバケットでの違いの識別方法

ここでは、2つの異なる比較の例を示し、スキャンおよびバケットでの共有データベース・オブジェクトの違いの識別方法について説明します。それぞれの例で、CREATE_COMPARISONプロシージャのmax_num_bucketsパラメータは3に設定されています。したがって、この比較でCOMPAREまたはRECHECKファンクションが実行される場合、各スキャンで最大3つのバケットが使用されます。

図13-1に、1つ目の例を示します。

図13-1 max_num_buckets=3が設定された比較および各スキャンのそれぞれのバケットでの違い

図13-1には、共有データベース・オブジェクトで比較されている行を表す線が示されています。この図は、各スキャンで使用されるそれぞれのバケットに違いが存在する場合に、スキャンおよびバケットで違いが識別される方法を示しています。

max_num_bucketsパラメータが3に設定されているため、次の手順で比較が実行されます。

1. この比較では、ルート・スキャンによってすべての行が比較されます。ルート・スキャンでは3つのバケットが使用され、各バケットで違いが検出されます。

2. 前述の手順のルート・スキャンによって使用された各バケットの行に対して、個別のスキャンが実行されます。この手順では3回のスキャンが実行され、各スキャンで3つのバケットが使用されます。したがって、この手順では合計9つのバケットが使用されます。各バケットで違いが検出されます。図13-1では、矢印によって、この手順の各スキャンのためにルート・スキャンの各バケットが3つのバケットに分割される状況が示されています。

3. 手順2のスキャンによって使用された各バケットの行に対して、個別のスキャンが実行されます。この手順では9回のスキャンが実行され、各スキャンで3つのバケットが使用されます。したがって、この手順では合計27個のバケットが使用されます。図13-1では、矢印によって、この手順の各スキャンのために手順2の各バケットが3つのバケットに分割される状況が示されています。

手順3の後、比較結果が、適切なデータ・ディクショナリ・ビューに記録されます。

図13-2に、2つ目の例を示します。

図13-2 max_num_buckets=3が設定された比較および各スキャンの1つのバケットでの違い

図13-2には、共有データベース・オブジェクトで比較されている行を表す線が示されています。この図は、各スキャンで使用される1つのバケットのみに違いが存在する場合に、スキャンおよびバケットで違いが識別される方法を示します。

max_num_bucketsパラメータが3に設定されているため、次の手順で比較が実行されます。

1. この比較では、ルート・スキャンによってすべての行が比較されます。ルート・スキャンでは3つのバケットが使用されますが、1つのバケットのみで違いが検出されます。

2. 違いが検出された1つのバケットの行に対して、個別のスキャンが実行されます。この手順では1回のスキャンが実行され、そのスキャンで3つのバケットが使用されます。1つのバケットのみで違いが検出されます。図13-2では、矢印によって、この手順のスキャンのためにルート・スキャンで違いが検出されたバケットが3つのバケットに分割される状況が示されています。

3. 手順2で違いが検出された1つのバケットの行に対して、個別のスキャンが実行されます。この手順では1回のスキャンが実行され、そのスキャンで3つのバケットが使用されます。図13-2では、矢印によって、この手順のスキャンのために手順2で違いが検出されたバケットが3つのバケットに分割される状況が示されています。

手順3の後、比較結果が、適切なデータ・ディクショナリ・ビューに記録されます。

注意:
この項の例では、CREATE_COMPARISONプロシージャのmax_num_bucketsパラメータは3に設定されています。この設定は、スキャンおよびバケットで違いが識別される方法を示すことを目的としています。通常、max_num_bucketsパラメータは、より高い値に設定されます。このパラメータのデフォルト値は1000です。このパラメータの設定を調整して、最高のパフォーマンスを実現できます。

関連項目:

- 「2つのデータベースの共有データベース・オブジェクトの比較」

- 「比較および比較結果に関する情報の表示」

DBMS_COMPARISONパッケージに関する他のマニュアル

この章で説明するタスクを実行する前に、次のマニュアルを参照してください。

- 次に示すDBMS_COMPARISONパッケージの基本的な情報については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

- DBMS_COMPARISONパッケージの基本概念

- このパッケージを使用してデータベース・オブジェクトを比較および収束する場合の簡単な例

- 比較結果に基づいて、異なるデータベースのデータベース・オブジェクト間の違いについての情報を示す問合せの例

- 次に示すパッケージの高度な概念およびサブプログラムの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のDBMS_COMPARISONパッケージに関する章を参照してください。

- このパッケージを使用するための要件

- このパッケージで使用される定数の説明

- このパッケージの各サブプログラムおよびそのパラメータの説明

共有データベース・オブジェクトの比較および収束の準備

2つのデータベースの共有データベース・オブジェクトを比較および収束するには、次の前提条件を満たす必要があります。

- 2つのデータベースが相互に通信できるようにネットワーク接続を構成します。データベース間のネットワーク接続を構成する方法については、『Oracle Database Net Services管理者ガイド』を参照してください。

- 比較を作成、実行および管理するデータベース・ユーザーを指定または作成します。このデータベース・ユーザーは、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のDBMS_COMPARISONパッケージに関する項に示されている権限の要件を満たす必要があります。
必要な権限を持つユーザーを指定または作成した後、DBMS_COMPARISONパッケージのサブプログラムを実行するデータベースからデータベース・オブジェクトを共有するもう一方のデータベースへのデータベース・リンクを作成します。指定したユーザーがデータベース・リンクを所有している必要があり、このリンクは、リモート・データベース上の必要な権限を持つユーザーに接続している必要があります。

たとえば、次の例では、データベースcomp1.example.comのユーザーadminが所有し、リモート・データベースcomp2.example.comのadminユーザーに接続するデータベース・リンクを作成します。

1. SQL*Plusで、adminユーザーとしてローカル・データベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

2. データベース・リンクを作成します。

CREATE DATABASE LINK comp2.example.com CONNECT TO admin
IDENTIFIED BY password USING 'comp2.example.com';

2つのデータベースのデータベース・オブジェクトの拡散の例

次の項では、2つのデータベースの共有データベース・オブジェクトを比較および収束する例を示します。

- 「2つのデータベースの共有データベース・オブジェクトの比較」

- 「共有データベース・オブジェクトの収束」

これらの例のほとんどでは、oe.orders表のデータを比較および収束します。この表は、oeサンプル・スキーマに含まれ、デフォルトでOracle Databaseとともにインストールされます。これらの例では、データベースのグローバル名はcomp1.example.comおよびcomp2.example.comですが、使用している環境内では、「共有データベース・オブジェクトの比較および収束の準備」に示されている前提条件を満たす任意の2つのデータベースに置き換えることができます。

これらの例のために、次の手順を実行してoe.orders表を2つのデータベースで拡散させます。

1. SQL*Plusで、oeユーザーとしてcomp2.example.comデータベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

2. customer_idが147の注文をoe.orders表から削除します。

DELETE FROM oe.orders WHERE customer_id=147;

3. oe.orders表で行のデータを変更します。

UPDATE oe.orders SET sales_rep_id=163 WHERE order_id=2440;

4. oe.orders表に行を挿入します。

INSERT INTO oe.orders VALUES(3000, TIMESTAMP '2006-01-01 2:00:00', 'direct', 107, 3, 16285.21, 156, NULL);

5. 変更をコミットしてSQL*Plusを終了します。

COMMIT;
EXIT

注意:
通常、これらの手順は必要ありません。これらの手順は、2つのデータベースでoe.orders表を確実に拡散させるために記載されています。

2つのデータベースの共有データベース・オブジェクトの比較

この項の例では、DBMS_COMPARISONパッケージを使用して、comp1.example.comおよびcomp2.example.comデータベースのoe.orders表を比較します。例では、このパッケージを使用して異なるタイプの比較を作成し、その比較を使用して表を比較します。

この項の例は、次のとおりです。

- 共有データベース・オブジェクトの列のサブセットの比較

- 行の違いを識別しない共有データベース・オブジェクトの比較

- 共有データベース・オブジェクトのランダム部分の比較

- 共有データベース・オブジェクトの循環比較

- 共有データベース・オブジェクトのカスタム部分の比較

- CLOB列またはBLOB列を含む共有データベース・オブジェクトの比較

共有データベース・オブジェクトの列のサブセットの比較

CREATE_COMPARISONプロシージャのcolumn_listパラメータを使用すると、データベース・オブジェクトの列のサブセットを比較できます。列のサブセットを比較する理由は次のとおりです。

- データベース・オブジェクトに、比較対象のデータベース・オブジェクトに存在しない追加の列が含まれている。この場合、column_listパラメータには、両方のデータベース・オブジェクトに存在する列のみを含める必要があります。

- 特定の列セットに比較を限定する必要がある。たとえば、表に何百もの列が含まれている場合、column_listパラメータに特定の列を指定して、効率的に比較できます。

- 一部の列に違いが存在すると予測される。この場合、違いが存在すると予測される列をcolumn_listパラメータから除外します。

列リストの列は、次の要件を満たしている必要があります。

- 列リストは、DBMS_COMPARISONパッケージの索引列の要件を満たしている必要があります。索引列の要件の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- CONVERGEプロシージャを使用して比較結果に基づいてデータベース・オブジェクトを変更する場合は、そのデータベース・オブジェクト内のNOT NULL制約が指定され、デフォルト値が指定されていないすべての列を、列リストに含める必要があります。

この例では、comp1.example.comデータベースとcomp2.example.comデータベースのoe.orders表のorder_id、order_dateおよびcustomer_id列を比較します。

1. 「共有データベース・オブジェクトの比較および収束の準備」および「2つのデータベースのデータベース・オブジェクトの拡散の例」で説明されているタスクを実行します。

2. 「共有データベース・オブジェクトの比較および収束の準備」で作成したデータベース・リンクを所有する管理ユーザーとして、SQL*Plusからcomp1.example.comデータベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

3. CREATE_COMPARISONプロシージャを実行して、比較を作成します。

BEGIN
DBMS_COMPARISON.CREATE_COMPARISON(
comparison_name => 'compare_subset_columns',
schema_name     => 'oe',
object_name     => 'orders',
dblink_name     => 'comp2.example.com',
column_list     => 'order_id,order_date,customer_id');
END;
/

新しい比較の名前はcompare_subset_columnsです。この比較は、CREATE_COMPARISONプロシージャを実行するユーザーによって所有されます。

4. COMPAREファンクションを実行して、2つのデータベースのoe.orders表を比較します。

SET SERVEROUTPUT ON
DECLARE
consistent   BOOLEAN;
scan_info    DBMS_COMPARISON.COMPARISON_TYPE;
BEGIN
consistent := DBMS_COMPARISON.COMPARE(
comparison_name => 'compare_subset_columns',
scan_info       => scan_info,
perform_row_dif => TRUE);
DBMS_OUTPUT.PUT_LINE('Scan ID: '||scan_info.scan_id);
IF consistent=TRUE THEN
DBMS_OUTPUT.PUT_LINE('No differences were found.');
ELSE
DBMS_OUTPUT.PUT_LINE('Differences were found.');
END IF;
END;
/

COMPAREファンクションのperform_row_difパラメータがTRUEに設定されていることに注意してください。この設定によって、COMPAREファンクションは、表の個々の行の違いを識別します。perform_row_difパラメータがFALSEに設定されている場合、COMPAREファンクションは、表に違いが存在するかどうかは記録しますが、個々の行の違いは記録しません。

出力は次のようになります。

Scan ID: 1
Differences were found.

PL/SQL procedure successfully completed.

関連項目:

- 「スキャンで検出された行の違いの詳細の表示」

- 比較結果で検出された違いを収束する場合は、「共有データベース・オブジェクトの収束」を参照してください。

- 比較結果を再確認する場合は、「比較の比較結果の再確認」を参照してください。

行の違いを識別しない共有データベース・オブジェクトの比較

既存の比較に対してCOMPAREプロシージャを実行する場合は、perform_row_difパラメータによって、COMPAREプロシージャでデータベース・オブジェクトの個々の行の違いを識別するかどうかが制御されます。

- perform_row_difパラメータがTRUEに設定されている場合、COMPAREプロシージャは、データベース・オブジェクトに違いが存在するかどうかを記録し、個々の行の違いを記録します。データベース・オブジェクトのそれぞれの違いを識別する必要がある場合は、このパラメータをTRUEに設定します。

- perform_row_difパラメータがFALSEに設定されている場合、COMPAREプロシージャは、データベース・オブジェクトに違いが存在するかどうかは記録しますが、個々の行の違いは記録しません。データベース・オブジェクトに違いが存在するかどうかを知る必要があり、個々の違いを識別する必要がない場合は、このパラメータをFALSEに設定します。このパラメータをFALSEに設定すると、最も効率的に比較を実行できます。

COMPAREファンクションのperform_row_difパラメータの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

この例では、個々の行の違いを識別せずに、comp1.example.comデータベースとcomp2.example.comデータベースのoe.orders表全体を比較します。

1. 「共有データベース・オブジェクトの比較および収束の準備」および「2つのデータベースのデータベース・オブジェクトの拡散の例」で説明されているタスクを実行します。

2. 「共有データベース・オブジェクトの比較および収束の準備」で作成したデータベース・リンクを所有する管理ユーザーとして、SQL*Plusからcomp1.example.comデータベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

3. CREATE_COMPARISONプロシージャを実行して、比較を作成します。

BEGIN
DBMS_COMPARISON.CREATE_COMPARISON(
comparison_name => 'compare_orders',
schema_name     => 'oe',
object_name     => 'orders',
dblink_name     => 'comp2.example.com');
END;
/

4. COMPAREファンクションを実行して、2つのデータベースのoe.orders表を比較します。

SET SERVEROUTPUT ON
DECLARE
consistent   BOOLEAN;
scan_info    DBMS_COMPARISON.COMPARISON_TYPE;
BEGIN
consistent := DBMS_COMPARISON.COMPARE(
comparison_name => 'compare_orders',
scan_info       => scan_info,
perform_row_dif => FALSE);
DBMS_OUTPUT.PUT_LINE('Scan ID: '||scan_info.scan_id);
IF consistent=TRUE THEN
DBMS_OUTPUT.PUT_LINE('No differences were found.');
ELSE
DBMS_OUTPUT.PUT_LINE('Differences were found.');
END IF;
END;
/

COMPAREファンクションのperform_row_difパラメータがFALSEに設定されていることに注意してください。

出力は次のようになります。

Scan ID: 4
Differences were found.

PL/SQL procedure successfully completed.

関連項目:

- 「スキャンで検出された行の違いの詳細の表示」

- 比較結果で検出された違いを収束する場合は、「共有データベース・オブジェクトの収束」を参照してください。

- 比較結果を再確認する場合は、「比較の比較結果の再確認」を参照してください。

共有データベース・オブジェクトのランダム部分の比較

CREATE_COMPARISONプロシージャのscan_percentおよびscan_modeパラメータを使用すると、共有データベース・オブジェクト全体ではなく、共有データベース・オブジェクトの一部をランダムに比較できます。通常、このオプションは、次の場合に使用します。

- 比較的大きい共有データベース・オブジェクトを比較しており、データベース・オブジェクト全体の比較にリソースおよび時間を費やすことなく、違いが存在するかどうかを判別する場合。

- 後続の比較を使用してデータベース・オブジェクトの別の部分を比較しない場合。後続の比較でデータベース・オブジェクトの別の部分を比較する場合の手順については、「共有データベース・オブジェクトの循環比較」を参照してください。

この例では、comp1.example.comデータベースとcomp2.example.comデータベースのoe.orders表の一部をランダムに比較します。

1. 「共有データベース・オブジェクトの比較および収束の準備」および「2つのデータベースのデータベース・オブジェクトの拡散の例」で説明されているタスクを実行します。

2. 「共有データベース・オブジェクトの比較および収束の準備」で作成したデータベース・リンクを所有する管理ユーザーとして、SQL*Plusからcomp1.example.comデータベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

3. CREATE_COMPARISONプロシージャを実行して、比較を作成します。

BEGIN
DBMS_COMPARISON.CREATE_COMPARISON(
comparison_name => 'compare_random',
schema_name     => 'oe',
object_name     => 'orders',
dblink_name     => 'comp2.example.com',
scan_mode       =>  DBMS_COMPARISON.CMP_SCAN_MODE_RANDOM,
scan_percent    =>  50);
END;
/

比較時に表の半分がスキャンされるように指定するためにscan_percentパラメータが50に設定されていることに注意してください。表のランダムな行が比較されるように指定するためにscan_modeパラメータはDBMS_COMPARISON.CMP_SCAN_MODE_RANDOMに設定されています。

4. COMPAREファンクションを実行して、2つのデータベースのoe.orders表を比較します。

SET SERVEROUTPUT ON
DECLARE
consistent   BOOLEAN;
scan_info    DBMS_COMPARISON.COMPARISON_TYPE;
BEGIN
consistent := DBMS_COMPARISON.COMPARE(
comparison_name => 'compare_random',
scan_info       => scan_info,
perform_row_dif => TRUE);
DBMS_OUTPUT.PUT_LINE('Scan ID: '||scan_info.scan_id);
IF consistent=TRUE THEN
DBMS_OUTPUT.PUT_LINE('No differences were found.');
ELSE
DBMS_OUTPUT.PUT_LINE('Differences were found.');
END IF;
END;
/

COMPAREファンクションのperform_row_difパラメータがTRUEに設定されていることに注意してください。この設定によって、COMPAREファンクションは、表の個々の行の違いを識別します。perform_row_difパラメータがFALSEに設定されている場合、COMPAREファンクションは、表に違いが存在するかどうかは記録しますが、個々の行の違いは記録しません。

出力は次のようになります。

Scan ID: 7
Differences were found.

PL/SQL procedure successfully completed.

この比較のスキャンでは、比較される表の部分に応じて、違いが検出される場合と検出されない場合があります。

関連項目:

- 「スキャンで検出された行の違いの詳細の表示」

- 比較結果で検出された違いを収束する場合は、「共有データベース・オブジェクトの収束」を参照してください。

- 比較結果を再確認する場合は、「比較の比較結果の再確認」を参照してください。

共有データベース・オブジェクトの循環比較

CREATE_COMPARISONプロシージャのscan_percentおよびscan_modeパラメータを使用すると、共有データベース・オブジェクトの一部を循環比較できます。循環比較では、1回の比較で比較対象のデータベース・オブジェクトの一部がスキャンされます。このデータベース・オブジェクトを再度比較すると、前回の比較が終了した箇所から、データベース・オブジェクトの別の部分が比較されます。

通常、このオプションは、次の場合に使用します。

- 比較的大きい共有データベース・オブジェクトを比較しており、データベース・オブジェクト全体の比較にリソースおよび時間を費やすことなく、違いが存在するかどうかを判別する場合。

- 各比較で共有データベース・オブジェクトの別の部分を比較して、データベース・オブジェクト全体が適切な回数のスキャンで比較されるようにする場合。たとえば、共有データベース・オブジェクトの25%を比較する場合、データベース・オブジェクト全体は4回の比較で比較されます。後続の比較でデータベース・オブジェクトの別の部分を比較しない場合の手順については、「共有データベース・オブジェクトのランダム部分の比較」を参照してください。

この例では、comp1.example.comデータベースとcomp2.example.comデータベースのoe.orders表を循環比較します。

1. 「共有データベース・オブジェクトの比較および収束の準備」および「2つのデータベースのデータベース・オブジェクトの拡散の例」で説明されているタスクを実行します。

2. 「共有データベース・オブジェクトの比較および収束の準備」で作成したデータベース・リンクを所有する管理ユーザーとして、SQL*Plusからcomp1.example.comデータベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

3. CREATE_COMPARISONプロシージャを実行して、比較を作成します。

BEGIN
DBMS_COMPARISON.CREATE_COMPARISON(
comparison_name => 'compare_cyclic',
schema_name     => 'oe',
object_name     => 'orders',
dblink_name     => 'comp2.example.com',
scan_mode       =>  DBMS_COMPARISON.CMP_SCAN_MODE_CYCLIC,
scan_percent    =>  50);
END;
/

比較時に表の半分がスキャンされるように指定するためにscan_percentパラメータが50に設定されていることに注意してください。表の行が循環比較されるように指定するためにscan_modeパラメータはDBMS_COMPARISON.CMP_SCAN_MODE_CYCLICに設定されています。

4. COMPAREファンクションを実行して、2つのデータベースのoe.orders表を比較します。

SET SERVEROUTPUT ON
DECLARE
consistent   BOOLEAN;
scan_info    DBMS_COMPARISON.COMPARISON_TYPE;
BEGIN
consistent := DBMS_COMPARISON.COMPARE(
comparison_name => 'compare_cyclic',
scan_info       => scan_info,
perform_row_dif => TRUE);
DBMS_OUTPUT.PUT_LINE('Scan ID: '||scan_info.scan_id);
IF consistent=TRUE THEN
DBMS_OUTPUT.PUT_LINE('No differences were found.');
ELSE
DBMS_OUTPUT.PUT_LINE('Differences were found.');
END IF;
END;
/

COMPAREファンクションのperform_row_difパラメータがTRUEに設定されていることに注意してください。この設定によって、COMPAREファンクションは、表の個々の行の違いを識別します。perform_row_difパラメータがFALSEに設定されている場合、COMPAREファンクションは、表に違いが存在するかどうかは記録しますが、個々の行の違いは記録しません。

出力は次のようになります。

Scan ID: 8
Differences were found.

PL/SQL procedure successfully completed.

この比較のスキャンでは、比較される表の部分に応じて、違いが検出される場合と検出されない場合があります。

5. データベース・オブジェクトで前回の比較が終了した箇所の次の部分を比較するために、手順4で実行したCOMPAREファンクションを再実行します。この例では、手順3でscan_percentパラメータが50に設定されているため、COMPAREファンクションを2回実行すると、データベース・オブジェクト全体が比較されます。

関連項目:

- 「スキャンで検出された行の違いの詳細の表示」

- 比較結果で検出された違いを収束する場合は、「共有データベース・オブジェクトの収束」を参照してください。

- 比較結果を再確認する場合は、「比較の比較結果の再確認」を参照してください。

共有データベース・オブジェクトのカスタム部分の比較

CREATE_COMPARISONプロシージャのscan_modeパラメータを使用すると、共有データベース・オブジェクトのカスタム部分を比較できます。CREATE_COMPARISONプロシージャのscan_modeパラメータをCMP_SCAN_MODE_CUSTOMに設定して比較を作成すると、COMPAREファンクションの実行時に比較されるデータベース・オブジェクトの部分を指定できます。

通常、このオプションは、次の場合に使用します。

- 共有データベース・オブジェクトの特定の部分を比較する場合。

- 比較的大きい共有データベース・オブジェクトを比較しており、データベース・オブジェクト全体の比較にリソースおよび時間を費やすことなく、データベース・オブジェクトの特定の部分に違いが存在するかどうかを判別する場合。

CREATE_COMPARISONプロシージャのscan_modeパラメータの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

この例では、comp1.example.comデータベースとcomp2.example.comデータベースのoe.orders表のカスタム部分を比較します。

1. 「共有データベース・オブジェクトの比較および収束の準備」および「2つのデータベースのデータベース・オブジェクトの拡散の例」で説明されているタスクを実行します。

2. 「共有データベース・オブジェクトの比較および収束の準備」で作成したデータベース・リンクを所有する管理ユーザーとして、SQL*Plusからcomp1.example.comデータベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

3. CREATE_COMPARISONプロシージャを実行して、比較を作成します。

BEGIN
DBMS_COMPARISON.CREATE_COMPARISON(
comparison_name   => 'compare_custom',
schema_name       => 'oe',
object_name       => 'orders',
dblink_name       => 'comp2.example.com',
index_schema_name => 'oe',
index_name        => 'order_pk',
scan_mode         =>  DBMS_COMPARISON.CMP_SCAN_MODE_CUSTOM);
END;
/

scan_modeパラメータがDBMS_COMPARISON.CMP_SCAN_MODE_CUSTOMに設定されていることに注意してください。このスキャン・モードを指定した場合は、比較で使用する索引を指定する必要があります。この例では、or.order_pk索引を指定しています。

4. 次の問合せを実行して、手順3で作成した比較に索引列を指定します。

SELECT COLUMN_NAME, COLUMN_POSITION FROM DBA_COMPARISON_COLUMNS
WHERE COMPARISON_NAME = 'COMPARE_CUSTOM' AND
INDEX_COLUMN    = 'Y';

カスタム比較では、索引列を使用して、次の手順でCOMPAREファンクションを実行する際に比較する表の部分を指定します。この例では、問合せによって次の出力が戻されます。

COLUMN_NAME                    COLUMN_POSITION
------------------------------ ---------------
ORDER_ID                                     1

この出力には、oe.orders表のorder_id列が比較用の索引列であることが示されています。

他のデータベース・オブジェクトでは、CREATE_COMPARISONプロシージャによって複数の索引列を識別できます。複数の索引列が存在する場合は、次の手順でリード索引列の値を指定します。リード索引列のCOLUMN_POSITION値には1が表示されます。

5. COMPAREファンクションを実行して、2つのデータベースのoe.orders表を比較します。

SET SERVEROUTPUT ON
DECLARE
consistent   BOOLEAN;
scan_info    DBMS_COMPARISON.COMPARISON_TYPE;
BEGIN
consistent := DBMS_COMPARISON.COMPARE(
comparison_name => 'compare_custom',
scan_info       => scan_info,
min_value       => '2430',
max_value       => '2460',
perform_row_dif => TRUE);
DBMS_OUTPUT.PUT_LINE('Scan ID: '||scan_info.scan_id);
IF consistent=TRUE THEN
DBMS_OUTPUT.PUT_LINE('No differences were found.');
ELSE
DBMS_OUTPUT.PUT_LINE('Differences were found.');
END IF;
END;
/

COMPAREファンクションの次のパラメータ設定に注意してください。

- min_valueおよびmax_valueパラメータは、それぞれ2430および2460に設定されています。したがって、COMPAREファンクションでは、order_id列が2430から2460の範囲の行のみが比較されます。

- order_id列の列データ型はNUMBERですが、min_valueおよびmax_valueパラメータはVARCHAR2データ型値として指定されています。

- COMPAREファンクションのperform_row_difパラメータがTRUEに設定されています。この設定によって、COMPAREファンクションは、表の個々の行の違いを識別します。perform_row_difパラメータがFALSEに設定されている場合、COMPAREファンクションは、表に違いが存在するかどうかは記録しますが、個々の行の違いは記録しません。

出力は次のようになります。

Scan ID: 10
Differences were found.

PL/SQL procedure successfully completed.

関連項目:

- 「スキャンで検出された行の違いの詳細の表示」

- 比較結果で検出された違いを収束する場合は、「共有データベース・オブジェクトの収束」を参照してください。

- 比較結果を再確認する場合は、「比較の比較結果の再確認」を参照してください。

CLOB列またはBLOB列を含む共有データベース・オブジェクトの比較

DBMS_COMPARISONパッケージでは、CLOBまたはBLOBデータ型の列を含む共有データベース・オブジェクトの比較を直接サポートしていません。ただし、次の基本的な手順を完了することで、CLOBまたはBLOB列を含む表を比較できます。

1. 各データベースで、表に基づくビューを作成し、CLOBまたはBLOB列を、DBMS_CRYPTO.HASHファンクションを使用して生成したRAWデータ型列に置き換えます。

2. 手順1で作成したビューを比較します。

例では、NUMBER例およびCLOB列を含む単純な表に対してこれらの手順を実行する方法を示します。この例では、データベースのグローバル名はcomp1.example.comおよびcomp2.example.comですが、使用している環境内では、「共有データベース・オブジェクトの比較および収束の準備」に示されている前提条件を満たす任意の2つのデータベースに置き換えることができます。

注意:
DBMS_COMPARISONパッケージでは、LOB列を含む共有データベース・オブジェクトを収束できません。

手順は次のとおりです。

1. 「共有データベース・オブジェクトの比較および収束の準備」で説明されているタスクを実行します。

2. comp1.example.comデータベースで、CLOBまたはBLOB列を含む表を所有しているユーザーまたは所有する予定のユーザーが、DBMS_CRYPTOパッケージのEXECUTE権限を持っていることを確認します。
この例では、表を所有する予定のユーザーはoeであると想定しています。次の手順を完了して、この権限をoeユーザーに付与します。

1. 権限を付与できる管理ユーザーとして、SQL*Plusからcomp1.example.comデータベースに接続します。

2. DBMS_CRYPTOパッケージのEXECUTEをユーザーに付与します。

GRANT EXECUTE ON DBMS_CRYPTO TO oe;

3. comp2.example.comデータベースで、CLOBまたはBLOB列を含む表を所有しているユーザーまたは所有する予定のユーザーが、DBMS_CRYPTOパッケージのEXECUTE権限を持っていることを確認します。
この例では、表を所有する予定のユーザーはoeであると想定しています。次の手順を完了して、この権限をoeユーザーに付与します。

1. 権限を付与できる管理ユーザーとして、SQL*Plusからcomp2.example.comデータベースに接続します。

2. DBMS_CRYPTOパッケージのEXECUTEをユーザーに付与します。

GRANT EXECUTE ON DBMS_CRYPTO TO oe;

4. comp1.example.comデータベースでCLOB列を含む表およびこの表に基づいたビューを作成します。

1. 表を所有する予定のユーザーとして、SQL*Plusからcomp1.example.comデータベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

2. 次のように表を作成します。

CREATE TABLE oe.tab_lob(
c1 NUMBER PRIMARY KEY,
c2 CLOB DEFAULT to_clob('c2'));

3. tab_lob表に行を挿入して、変更をコミットします。

INSERT INTO oe.tab_lob VALUES(1, TO_CLOB('row 1'));COMMIT;

4. 次のようにビューを作成します。

BEGIN
EXECUTE IMMEDIATE 'CREATE VIEW view_lob AS SELECT
c1,
DBMS_CRYPTO.HASH(c2, '||DBMS_CRYPTO.HASH_SH1||') c2_hash
FROM tab_lob';
END;
/

関連項目:
DBMS_CRYPTOパッケージで使用される暗号ハッシュ・ファンクションの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

5. comp2.example.comデータベースでCLOB列を含む表およびこの表に基づいたビューを作成します。

1. 表を所有する予定のユーザーとして、SQL*Plusからcomp2.example.comデータベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

2. 次のように表を作成します。

CREATE TABLE oe.tab_lob(
c1 NUMBER PRIMARY KEY,
c2 CLOB DEFAULT to_clob('c2'));

3. tab_lob表に行を挿入して、変更をコミットします。

INSERT INTO oe.tab_lob VALUES(1, TO_CLOB('row 1'));COMMIT;

4. 次のようにビューを作成します。

BEGIN
EXECUTE IMMEDIATE 'CREATE VIEW view_lob AS SELECT
c1,
DBMS_CRYPTO.HASH(c2, '||DBMS_CRYPTO.HASH_SH1||') c2_hash
FROM tab_lob';
END;
/

6. 「共有データベース・オブジェクトの比較および収束の準備」で作成したデータベース・リンクを所有する管理ユーザーとして、SQL*Plusからcomp1.example.comデータベースに接続します。

7. CREATE_COMPARISONプロシージャを実行して、比較を作成します。

BEGIN
DBMS_COMPARISON.CREATE_COMPARISON(
comparison_name => 'compare_lob',
schema_name     => 'oe',
object_name     => 'view_lob',
dblink_name     => 'comp2.example.com');
END;
/

schema_nameおよびobject_nameパラメータでは、oe.view_lobビューを指定しますが、CLOB列を含む表は指定しないことに注意してください。

8. COMPAREファンクションを実行して、2つのデータベースのoe.view_lobビューを比較します。

SET SERVEROUTPUT ON
DECLARE
consistent   BOOLEAN;
scan_info    DBMS_COMPARISON.COMPARISON_TYPE;
BEGIN
consistent := DBMS_COMPARISON.COMPARE(
comparison_name => 'compare_lob',
scan_info       => scan_info,
perform_row_dif => TRUE);
DBMS_OUTPUT.PUT_LINE('Scan ID: '||scan_info.scan_id);
IF consistent=TRUE THEN
DBMS_OUTPUT.PUT_LINE('No differences were found.');
ELSE
DBMS_OUTPUT.PUT_LINE('Differences were found.');
END IF;
END;
/

Scan ID: 1
No differences were found.

PL/SQL procedure successfully completed.

9. 次の手順を実行してoe.tab_lob表を2つのデータベースで拡散させます。

1. 表を所有するユーザーとして、SQL*Plusからcomp1.example.comデータベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

2. 行を挿入して、変更をコミットします。

INSERT INTO oe.tab_lob VALUES(2, TO_CLOB('row a'));
COMMIT;

3. 表を所有するユーザーとして、SQL*Plusからcomp2.example.comデータベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

4. 行を挿入して、変更をコミットします。

INSERT INTO oe.tab_lob VALUES(2, TO_CLOB('row b'));
COMMIT;

10. 再びCOMPAREファンクションを実行して、2つのデータベースのoe.view_lobビューを比較します。手順8を参照してください。
CLOB列を含む共有表は、2つのデータベースで拡散されました。したがって、ビューを比較すると、COMPAREファンクションによって次の出力が戻されます。

Scan ID: 2
Differences were found.

PL/SQL procedure successfully completed.

比較および比較結果に関する情報の表示

次のデータ・ディクショナリ・ビューには、DBMS_COMPARISONパッケージで作成された比較に関する情報が含まれています。

- DBA_COMPARISON

- USER_COMPARISON

- DBA_COMPARISON_COLUMNS

- USER_COMPARISON_COLUMNS

- DBA_COMPARISON_SCAN

- USER_COMPARISON_SCAN

- DBA_COMPARISON_SCAN_VALUES

- USER_COMPARISON_SCAN_VALUES

- DBA_COMPARISON_ROW_DIF

- USER_COMPARISON_ROW_DIF

ここでは、比較および比較結果を監視するために使用できる問合せの例を示します。

- データベース内の比較に関する一般的な情報の表示

- ランダム比較および循環比較固有の情報の表示

- データベース内の各比較によって比較された列の表示

- データベース内の各スキャンに関する一般的な情報の表示

- データベース内の各スキャンの親スキャンIDおよびルート・スキャンIDの表示

- スキャンで検出された行の違いの詳細の表示

- 特定のスキャンで比較された行に関する情報の表示

関連項目:
比較に関連するデータ・ディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

データベース内の比較に関する一般的な情報の表示

DBA_COMPARISONデータ・ディクショナリ・ビューには、ローカル・データベース内の比較に関する情報が含まれています。この項の問合せでは、各比較に関する次の情報が表示されます。

- 比較の所有者。

- 比較の名前。

- 比較によって比較されたデータベース・オブジェクトが含まれているスキーマ。

- 比較によって比較されたデータベース・オブジェクトの名前。

- 比較によって比較されたデータベース・オブジェクトのデータ型。

- 比較で使用されたスキャン・モード。スキャン・モードは次のいずれかになります。

- FULL: データベース・オブジェクト全体が比較されることを示します。

- RANDOM: データベース・オブジェクトのランダム部分が比較されることを示します。

- CYCLIC: 1回の比較でデータベース・オブジェクトの一部が比較されることを示します。このデータベース・オブジェクトを再度比較すると、前回の比較が終了した箇所から、データベース・オブジェクトの別の部分が比較されます。

- CUSTOM: COMPAREファンクションによってデータベース・オブジェクトで比較する範囲が指定されることを示します。

- リモート・データベースへの接続に使用されたデータベース・リンクの名前。

これらの情報を表示するには、次の問合せを実行します。

COLUMN OWNER HEADING 'Comparison|Owner' FORMAT A10
COLUMN COMPARISON_NAME HEADING 'Comparison|Name' FORMAT A22
COLUMN SCHEMA_NAME HEADING 'Schema|Name' FORMAT A8
COLUMN OBJECT_NAME HEADING 'Object|Name' FORMAT A8
COLUMN OBJECT_TYPE HEADING 'Object|Type' FORMAT A8
COLUMN SCAN_MODE HEADING 'Scan|Mode' FORMAT A6
COLUMN DBLINK_NAME HEADING 'Database|Link' FORMAT A15

SELECT OWNER,
COMPARISON_NAME,
SCHEMA_NAME,
OBJECT_NAME,
OBJECT_TYPE,
SCAN_MODE,
DBLINK_NAME
FROM DBA_COMPARISON;

出力は次のようになります。

Comparison Comparison             Schema   Object   Object   Scan   Database
Owner      Name                   Name     Name     Type     Mode   Link
---------- ---------------------- -------- -------- -------- ------ ----------
ADMIN      COMPARE_SUBSET_COLUMNS OE       ORDERS   TABLE    FULL   COMP2.EXAM
PLE
ADMIN      COMPARE_ORDERS         OE       ORDERS   TABLE    FULL   COMP2.EXAM
PLE
ADMIN      COMPARE_RANDOM         OE       ORDERS   TABLE    RANDOM COMP2.EXAM
PLE
ADMIN      COMPARE_CYCLIC         OE       ORDERS   TABLE    CYCLIC COMP2.EXAM
PLE
ADMIN      COMPARE_CUSTOM         OE       ORDERS   TABLE    CUSTOM COMP2.EXAM
PLE

比較では、ローカル・データベース・オブジェクトがリモート・データベースのデータベース・オブジェクトと比較されます。比較は、問合せで示されているデータベース・リンクを使用してリモート・データベースに接続し、実行されます。

デフォルトでは、比較対象のデータベース・オブジェクトの所有者、名前およびデータ型は、両方のデータベースで同じであると想定されます。ただし、ローカル・データベースとリモート・データベースでこれらが異なる場合があります。この項の問合せではリモート・データベース・オブジェクトに関する情報は表示されませんが、REMOTE_SCHEMA_NAME、REMOTE_OBJECT_NAMEおよびREMOTE_OBJECT_TYPE列を問い合せると、この情報を表示できます。

関連項目:
この問合せの出力に示されている比較を作成する方法の詳細は、「2つのデータベースの共有データベース・オブジェクトの比較」を参照してください。

ランダム比較および循環比較固有の情報の表示

スキャン・モードRANDOMまたはCYCLICを使用する比較を作成する場合は、比較する共有データベース・オブジェクトの割合を指定します。この項の問合せでは、ランダム比較および循環比較に関する次の情報が表示されます。

- 比較の所有者。

- 比較の名前。

- 比較によって比較されたデータベース・オブジェクトが含まれているスキーマ。

- 比較によって比較されたデータベース・オブジェクトの名前。

- 比較によって比較されたデータベース・オブジェクトのデータ型。

- 比較におけるスキャンの割合。COMPAREファンクションが実行されて比較スキャンが実行されるたびに、データベース・オブジェクトで、指定されている割合が比較されます。

- 比較で使用されたリード索引列の最後の値。COMPAREファンクションが次回実行される際は、問合せで示されたリード索引列の値の直後の値の行から開始されます。この値は、循環比較にのみ適用されます。

これらの情報を表示するには、次の問合せを実行します。

COLUMN OWNER HEADING 'Comparison|Owner' FORMAT A10
COLUMN COMPARISON_NAME HEADING 'Comparison|Name' FORMAT A22
COLUMN SCHEMA_NAME HEADING 'Schema|Name' FORMAT A8
COLUMN OBJECT_NAME HEADING 'Object|Name' FORMAT A8
COLUMN OBJECT_TYPE HEADING 'Object|Type' FORMAT A8
COLUMN SCAN_PERCENT HEADING 'Scan|Percent' FORMAT 999
COLUMN CYCLIC_INDEX_VALUE HEADING 'Cyclic|Index|Value' FORMAT A10

SELECT OWNER,
COMPARISON_NAME,
SCHEMA_NAME,
OBJECT_NAME,
OBJECT_TYPE,
SCAN_PERCENT,
CYCLIC_INDEX_VALUE
FROM DBA_COMPARISON
WHERE SCAN_PERCENT IS NOT NULL;

出力は次のようになります。

Cyclic
Comparison Comparison             Schema   Object   Object      Scan Index
Owner      Name                   Name     Name     Type     Percent Value
---------- ---------------------- -------- -------- -------- ------- ----------
ADMIN      COMPARE_RANDOM         OE       ORDERS   TABLE         50
ADMIN      COMPARE_CYCLIC         OE       ORDERS   TABLE         50 2677

関連項目:

- 「共有データベース・オブジェクトのランダム部分の比較」

- 「共有データベース・オブジェクトの循環比較」

- 「データベース内の比較に関する一般的な情報の表示」

データベース内の各比較によって比較された列の表示

比較を作成する場合は、比較で共有データベース・オブジェクトのすべての列を比較するか、または列のサブセットを比較するように指定できます。また、比較で使用する索引を指定するか、または索引がシステムによって自動的に指定されるように設定できます。

この項の問合せでは、次の情報が表示されます。

- 比較の所有者。

- 比較の名前。

- 比較によって比較されたデータベース・オブジェクトが含まれているスキーマ。

- 比較によって比較されたデータベース・オブジェクトの名前。

- 各データベース・オブジェクトで比較される各列の列名。

- 各列の列位置。

- 列が索引列かどうか。

これらの情報を表示するには、次の問合せを実行します。

COLUMN OWNER HEADING 'Comparison|Owner' FORMAT A10
COLUMN COMPARISON_NAME HEADING 'Comparison|Name' FORMAT A15
COLUMN SCHEMA_NAME HEADING 'Schema|Name' FORMAT A10
COLUMN OBJECT_NAME HEADING 'Object|Name' FORMAT A10
COLUMN COLUMN_NAME HEADING 'Column|Name' FORMAT A12
COLUMN COLUMN_POSITION HEADING 'Column|Position' FORMAT 9999
COLUMN INDEX_COLUMN HEADING 'Index|Column?' FORMAT A7

SELECT c.OWNER,
c.COMPARISON_NAME,
c.SCHEMA_NAME,
c.OBJECT_NAME,
o.COLUMN_NAME,
o.COLUMN_POSITION,
o.INDEX_COLUMN
FROM DBA_COMPARISON c, DBA_COMPARISON_COLUMNS o
WHERE c.OWNER           = o.OWNER AND
c.COMPARISON_NAME = o.COMPARISON_NAME
ORDER BY COMPARISON_NAME, COLUMN_POSITION;

出力は次のようになります。

Comparison Comparison      Schema     Object     Column         Column Index
Owner      Name            Name       Name       Name         Position Column?
---------- --------------- ---------- ---------- ------------ -------- -------
ADMIN      COMPARE_CUSTOM  OE         ORDERS     ORDER_ID            1 Y
ADMIN      COMPARE_CUSTOM  OE         ORDERS     ORDER_DATE          2 N
ADMIN      COMPARE_CUSTOM  OE         ORDERS     ORDER_MODE          3 N
ADMIN      COMPARE_CUSTOM  OE         ORDERS     CUSTOMER_ID         4 N
ADMIN      COMPARE_CUSTOM  OE         ORDERS     ORDER_STATUS        5 N
ADMIN      COMPARE_CUSTOM  OE         ORDERS     ORDER_TOTAL         6 N
ADMIN      COMPARE_CUSTOM  OE         ORDERS     SALES_REP_ID        7 N
ADMIN      COMPARE_CUSTOM  OE         ORDERS     PROMOTION_ID        8 N
ADMIN      COMPARE_CYCLIC  OE         ORDERS     ORDER_ID            1 Y
ADMIN      COMPARE_CYCLIC  OE         ORDERS     ORDER_DATE          2 N
ADMIN      COMPARE_CYCLIC  OE         ORDERS     ORDER_MODE          3 N
ADMIN      COMPARE_CYCLIC  OE         ORDERS     CUSTOMER_ID         4 N
ADMIN      COMPARE_CYCLIC  OE         ORDERS     ORDER_STATUS        5 N
ADMIN      COMPARE_CYCLIC  OE         ORDERS     ORDER_TOTAL         6 N
ADMIN      COMPARE_CYCLIC  OE         ORDERS     SALES_REP_ID        7 N
ADMIN      COMPARE_CYCLIC  OE         ORDERS     PROMOTION_ID        8 N
.
.
.

関連項目:

- 「データの比較および収束」

- 『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』

データベース内の各スキャンに関する一般的な情報の表示

各スキャンでは、ローカル・データベースのバケットとリモート・データベースのバケットが比較されます。比較されるバケットには、共有データベース・オブジェクトの同じ範囲の行が含まれます。COMPAREファンクションを1回実行して生成された比較結果に、複数のバケットおよび複数回のスキャンが含まれる場合があります。各スキャンには一意のスキャンIDが存在します。

この項の問合せでは、各スキャンに関する次の情報が表示されます。

- スキャンが実行された比較の所有者。

- スキャンが実行された比較の名前。

- スキャンによって比較されたデータベース・オブジェクトが含まれているスキーマ。

- スキャンによって比較されたデータベース・オブジェクトの名前。

- スキャンのスキャンID。

- スキャンの状態。状態の値は次のいずれかになります。

- SUC: 前回このデータ・ディクショナリの行が更新された際に2つの表の2つのバケットが一致したことを示します。

- BUCKET DIF: 2つの表の2つのバケットが一致しなかったことを示します。各バケットは、さらに小さいバケットで構成されています。

- FINAL BUCKET DIF: 2つの表の2つのバケットが一致しなかったことを示します。いずれのバケットも、さらに小さいバケットで構成されていません。COMPAREファンクションまたはRECHECKファンクションのperform_row_difパラメータがFALSEに設定されていたため、バケットで個々の行の違いは識別されませんでした。

- ROW DIF: 2つの表の2つのバケットが一致しなかったことを示します。いずれのバケットも、さらに小さいバケットで構成されていません。COMPAREファンクションまたはRECHECKファンクションのperform_row_difパラメータがTRUEに設定されていたため、バケットで個々の行の違いが識別されました。

- スキャンで比較された行の数。

- スキャンが前回更新された日時。

これらの情報を表示するには、次の問合せを実行します。

COLUMN OWNER HEADING 'Comparison|Owner' FORMAT A10
COLUMN COMPARISON_NAME HEADING 'Comparison|Name' FORMAT A15
COLUMN SCHEMA_NAME HEADING 'Schema|Name' FORMAT A6
COLUMN OBJECT_NAME HEADING 'Object|Name' FORMAT A6
COLUMN SCAN_ID HEADING 'Scan|ID' FORMAT 9999
COLUMN STATUS HEADING 'Scan|Status' FORMAT A10
COLUMN COUNT_ROWS HEADING 'Number|of|Rows' FORMAT 9999999
COLUMN SCAN_NULLS HEADING 'Scan|NULLs?' FORMAT A6
COLUMN LAST_UPDATE_TIME HEADING 'Last|Update' FORMAT A11

SELECT c.OWNER,
c.COMPARISON_NAME,
c.SCHEMA_NAME,
c.OBJECT_NAME,
s.SCAN_ID,
s.STATUS,
s.COUNT_ROWS,
TO_CHAR(s.LAST_UPDATE_TIME, 'DD-MON-YYYY HH24:MI:SS') LAST_UPDATE_TIME
FROM DBA_COMPARISON c, DBA_COMPARISON_SCAN s
WHERE c.OWNER           = s.OWNER AND
c.COMPARISON_NAME = s.COMPARISON_NAME
ORDER BY SCAN_ID;

出力は次のようになります。

Number
Comparison Comparison      Schema Object  Scan Scan             of Last
Owner      Name            Name   Name      ID Status         Rows Update
---------- --------------- ------ ------ ----- ---------- -------- -----------
ADMIN      COMPARE_SUBSET_ OE     ORDERS     1 BUCKET DIF          20-DEC-2006
COLUMNS                                                  09:46:34
ADMIN      COMPARE_SUBSET_ OE     ORDERS     2 ROW DIF         105 20-DEC-2006
COLUMNS                                                  09:46:34
ADMIN      COMPARE_SUBSET_ OE     ORDERS     3 ROW DIF           1 20-DEC-2006
COLUMNS                                                  09:46:35
ADMIN      COMPARE_ORDERS  OE     ORDERS     4 BUCKET DIF          20-DEC-2006
09:47:02
ADMIN      COMPARE_ORDERS  OE     ORDERS     5 FINAL BUCK      105 20-DEC-2006
ET DIF               09:47:02
ADMIN      COMPARE_ORDERS  OE     ORDERS     6 FINAL BUCK        1 20-DEC-2006
ET DIF               09:47:02
ADMIN      COMPARE_RANDOM  OE     ORDERS     7 SUC                 20-DEC-2006
09:47:37
ADMIN      COMPARE_CYCLIC  OE     ORDERS     8 BUCKET DIF          20-DEC-2006
09:48:22
ADMIN      COMPARE_CYCLIC  OE     ORDERS     9 ROW DIF         105 20-DEC-2006
09:48:22
ADMIN      COMPARE_CUSTOM  OE     ORDERS    10 BUCKET DIF          20-DEC-2006
09:49:15
ADMIN      COMPARE_CUSTOM  OE     ORDERS    11 ROW DIF          16 20-DEC-2006
09:49:15
ADMIN      COMPARE_CUSTOM  OE     ORDERS    12 ROW DIF          13 20-DEC-2006
09:49:15

スキャンの状態がBUCKET DIF、FINAL BUCKET DIFまたはROW DIFの場合、CONVERGEプロシージャを実行してスキャンIDを指定すると、スキャンで検出された違いを収束できます。ただし、特定のスキャンで確認された部分ではなく、比較結果のすべての行を収束するには、CONVERGEプロシージャの実行時に比較結果のルート・スキャンIDを指定します。

また、違いが検出されたことがスキャンで示された場合は、RECHECKファンクションを使用してスキャンを再確認できます。比較結果のすべての行を再確認するには、RECHECKファンクションを実行して、比較結果のルート・スキャンIDを指定します。

関連項目:

- スキャンのルート・スキャンを表示する方法の詳細は、「データベース内の各スキャンの親スキャンIDおよびルート・スキャンIDの表示」を参照してください。

- 「共有データベース・オブジェクトの収束」

- 「比較の比較結果の再確認」

- スキャンおよびバケットの詳細は、「データの比較および収束」を参照してください。

- 『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』

データベース内の各スキャンの親スキャンIDおよびルート・スキャンIDの表示

この項の問合せでは、データベースの各スキャンの親スキャンIDおよびルート・スキャンIDが表示されます。具体的には、この問合せによって次の情報が表示されます。

- スキャンが実行された比較の所有者。

- スキャンが実行された比較の名前。

- スキャンによって比較されたデータベース・オブジェクトが含まれているスキーマ。

- スキャンによって比較されたデータベース・オブジェクトの名前。

- スキャンのスキャンID。

- スキャンの親スキャンのスキャンID。

- スキャンのルート・スキャンのスキャンID。

これらの情報を表示するには、次の問合せを実行します。

COLUMN OWNER HEADING 'Comparison|Owner' FORMAT A10
COLUMN COMPARISON_NAME HEADING 'Comparison|Name' FORMAT A15
COLUMN SCHEMA_NAME HEADING 'Schema|Name' FORMAT A10
COLUMN OBJECT_NAME HEADING 'Object|Name' FORMAT A10
COLUMN SCAN_ID HEADING 'Scan|ID' FORMAT 9999
COLUMN PARENT_SCAN_ID HEADING 'Parent|Scan ID' FORMAT 9999
COLUMN ROOT_SCAN_ID HEADING 'Root|Scan ID' FORMAT 9999

SELECT c.OWNER,
c.COMPARISON_NAME,
c.SCHEMA_NAME,
c.OBJECT_NAME,
s.SCAN_ID,
s.PARENT_SCAN_ID,
s.ROOT_SCAN_ID
FROM DBA_COMPARISON c, DBA_COMPARISON_SCAN s
WHERE c.OWNER           = s.OWNER AND
c.COMPARISON_NAME = s.COMPARISON_NAME
ORDER BY s.SCAN_ID;

出力は次のようになります。

Comparison Comparison      Schema     Object      Scan  Parent    Root
Owner      Name            Name       Name          ID Scan ID Scan ID
---------- --------------- ---------- ---------- ----- ------- -------
ADMIN      COMPARE_SUBSET_ OE         ORDERS         1               1
COLUMNS
ADMIN      COMPARE_SUBSET_ OE         ORDERS         2       1       1
COLUMNS
ADMIN      COMPARE_SUBSET_ OE         ORDERS         3       1       1
COLUMNS
ADMIN      COMPARE_ORDERS  OE         ORDERS         4               4
ADMIN      COMPARE_ORDERS  OE         ORDERS         5       4       4
ADMIN      COMPARE_ORDERS  OE         ORDERS         6       4       4
ADMIN      COMPARE_RANDOM  OE         ORDERS         7               7
ADMIN      COMPARE_CYCLIC  OE         ORDERS         8               8
ADMIN      COMPARE_CYCLIC  OE         ORDERS         9       8       8
ADMIN      COMPARE_CUSTOM  OE         ORDERS        10              10
ADMIN      COMPARE_CUSTOM  OE         ORDERS        11      10      10
ADMIN      COMPARE_CUSTOM  OE         ORDERS        12      10      10

たとえば、この出力には、スキャンID 1のスキャンがCOMPARE_SUBSET_COLUMNS比較の比較結果のルート・スキャンであることが示されています。このルート・スキャンでは違いが検出され、このルート・スキャンは2つの小さいバケットに分割されています。スキャンID 2およびスキャンID 3のスキャンは、これらの小さいバケットに対するスキャンです。

特定のスキャンで違いが検出されたかどうかを確認するには、「データベース内の各スキャンに関する一般的な情報の表示」に示されている問合せを実行します。違いに対してRECHECKを実行する場合または共有データベース・オブジェクトの違いに対してCONVERGEを実行する場合は、再確認または収束するスキャンのスキャンIDを指定します。比較結果のすべての行を再確認または収束するには、比較結果のルート・スキャンIDを指定します。

関連項目:

- 「共有データベース・オブジェクトの収束」

- 「比較の比較結果の再確認」

- 「データの比較および収束」

- 『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』

スキャンで検出された行の違いの詳細の表示

この項の問合せでは、比較結果で検出された行の違いに関する詳細が表示されます。この項の問合せの情報を表示するには、比較を実行したCOMPAREファンクションまたはRECHECKファンクションのperform_row_difパラメータをTRUEに設定しておく必要があります。

このパラメータをFALSEに設定した場合、DBA_COMPARISON_SCANビューのSTATUS列を問い合せて、違いの詳細を表示せずに、スキャンで違いが検出されたかどうかを判別できます。詳細および問合せの例については、「データベース内の各スキャンに関する一般的な情報の表示」を参照してください。

次の問合せでは、スキャンID 8のスキャンで検出された違いの合計数が表示されます。

COLUMN OWNER HEADING 'Comparison Owner' FORMAT A16
COLUMN COMPARISON_NAME HEADING 'Comparison Name' FORMAT A25
COLUMN SCHEMA_NAME HEADING 'Schema Name' FORMAT A11
COLUMN OBJECT_NAME HEADING 'Object Name' FORMAT A11
COLUMN CURRENT_DIF_COUNT HEADING 'Differences' FORMAT 9999999

SELECT c.OWNER,
c.COMPARISON_NAME,
c.SCHEMA_NAME,
c.OBJECT_NAME,
s.CURRENT_DIF_COUNT
FROM DBA_COMPARISON c, DBA_COMPARISON_SCAN s
WHERE c.COMPARISON_NAME = s.COMPARISON_NAME AND
c.OWNER           = s.OWNER AND
s.SCAN_ID         = 8;

出力は次のようになります。

Comparison Owner Comparison Name           Schema Name Object Name Differences
---------------- ------------------------- ----------- ----------- -----------
ADMIN            COMPARE_CYCLIC            OE          ORDERS                6

COMPARE_CYCLIC比較の比較結果のスキャンID 8のスキャンで検出された各行の違いに関する詳細を表示するには、次の問合せを実行します。

COLUMN COLUMN_NAME HEADING 'Index Column' FORMAT A15
COLUMN INDEX_VALUE HEADING 'Index Value' FORMAT A15
COLUMN LOCAL_ROWID HEADING 'Local Row Exists?' FORMAT A20
COLUMN REMOTE_ROWID HEADING 'Remote Row Exists?' FORMAT A20

SELECT c.COLUMN_NAME,
r.INDEX_VALUE,
DECODE(r.LOCAL_ROWID,
NULL, 'No',
'Yes') LOCAL_ROWID,
DECODE(r.REMOTE_ROWID,
NULL, 'No',
'Yes') REMOTE_ROWID
FROM DBA_COMPARISON_COLUMNS c,
DBA_COMPARISON_ROW_DIF r,
DBA_COMPARISON_SCAN s
WHERE c.COMPARISON_NAME = 'COMPARE_CYCLIC' AND
r.SCAN_ID         = s.SCAN_ID AND
s.PARENT_SCAN_ID  = 8 AND
r.STATUS          = 'DIF' AND
c.INDEX_COLUMN    = 'Y' AND
c.COMPARISON_NAME = r.COMPARISON_NAME AND
c.OWNER           = r.OWNER
ORDER BY r.INDEX_VALUE;

出力は次のようになります。

Index Column    Index Value     Local Row Exists?    Remote Row Exists?
--------------- --------------- -------------------- --------------------
ORDER_ID        2366            Yes                  No
ORDER_ID        2385            Yes                  No
ORDER_ID        2396            Yes                  No
ORDER_ID        2425            Yes                  No
ORDER_ID        2440            Yes                  Yes
ORDER_ID        2450            Yes                  No

この出力には、比較する表の索引列と、共有データベース・オブジェクトで異なるそれぞれの行の索引値が示されています。この例では、索引列はoe.orders表の主キー列(order_id)です。また、出力には、各行の違いのタイプも示されています。

- 行に対するLocal Row Exists?とRemote Row Exists?の両方がYesの場合、その行はデータベース・オブジェクトの両方のインスタンスに存在しますが、行に含まれるデータは異なります。

- 行に対するLocal Row Exists?がYesでRemote Row Exists?がNoの場合、その行はローカル・データベース・オブジェクトには存在しますが、リモート・データベース・オブジェクトには存在しません。

- 行に対するLocal Row Exists?がNoでRemote Row Exists?がYesの場合、その行はリモート・データベース・オブジェクトには存在しますが、ローカル・データベース・オブジェクトには存在しません。

特定のスキャンで比較された行に関する情報の表示

各スキャンでは、共有データベース・オブジェクトの一定範囲の行が比較されます。この項の問合せでは、データベースの各スキャンで比較された行に関する次の情報が表示されます。

- スキャンが実行された比較の所有者。

- スキャンが実行された比較の名前。

- 問合せで表示された行の値の列位置。

- スキャンによって比較された行の範囲の最小値。

- スキャンによって比較された行の範囲の最大値。

スキャンでは、データベース・オブジェクト内の最小値の行、最大値の行および最小値と最大値の間のすべての行が比較されます。問合せによって戻された各行に最小値および最大値として表示された値は、表示された列位置にある列の値です。列位置は、比較用の索引列です。

これらの情報を表示するには、次の問合せを実行します。

COLUMN OWNER HEADING 'Comparison|Owner' FORMAT A10
COLUMN COMPARISON_NAME HEADING 'Comparison|Name' FORMAT A22
COLUMN SCAN_ID HEADING 'Scan|ID' FORMAT 9999
COLUMN COLUMN_POSITION HEADING 'Column|Position' FORMAT 999
COLUMN MIN_VALUE HEADING 'Minimum|Value' FORMAT A15
COLUMN MAX_VALUE HEADING 'Maximum|Value' FORMAT A15

SELECT OWNER,
COMPARISON_NAME,
SCAN_ID,
COLUMN_POSITION,
MIN_VALUE,
MAX_VALUE
FROM DBA_COMPARISON_SCAN_VALUES
ORDER BY SCAN_ID;

出力は次のようになります。

Comparison Comparison              Scan   Column Minimum         Maximum
Owner      Name                      ID Position Value           Value
---------- ---------------------- ----- -------- --------------- ---------------
ADMIN      COMPARE_SUBSET_COLUMNS     1        1 2354            3000
ADMIN      COMPARE_SUBSET_COLUMNS     2        1 2354            2458
ADMIN      COMPARE_SUBSET_COLUMNS     3        1 3000            3000
ADMIN      COMPARE_ORDERS             4        1 2354            3000
ADMIN      COMPARE_ORDERS             5        1 2354            2458
ADMIN      COMPARE_ORDERS             6        1 3000            3000
ADMIN      COMPARE_RANDOM             7        1 2617.3400241505 2940.3400241505
667163579712423 667163579712423
44590999096     44590999096
ADMIN      COMPARE_CYCLIC             8        1 2354            2677
ADMIN      COMPARE_CYCLIC             9        1 2354            2458
ADMIN      COMPARE_CUSTOM            10        1 2430            2460
ADMIN      COMPARE_CUSTOM            11        1 2430            2445
ADMIN      COMPARE_CUSTOM            12        1 2446            2458

この出力には、各スキャンで比較された行が示されています。一部の比較ではスキャンが小さいバケットに分割されており、問合せによって、それぞれの小さいバケットで比較された行が表示されます。

たとえば、COMPARE_CUSTOM比較の比較結果の出力について考えてみます。

- 比較結果の各スキャンによって、列位置1が表示されます。スキャンの列位置1にある列を判別するには、「データベース内の各比較によって比較された列の表示」に示されている問合せを実行します。この例では、COMPARE_CUSTOM比較の列位置1にある列は、oe.orders表のorder_id列です。

- スキャンID 10はルート・スキャンです。このスキャンでは、違いが検出され、スキャンID 11およびスキャンID 12で表される2つのバケットに行が分割されています。

- スキャンID 11では、order_idが2430の行からorder_idが2445の行までが比較されています。

- スキャンID 12では、order_idが2446の行からorder_idが2458の行までが比較されています。

スキャンで検出された違いを再確認または収束するには、それぞれRECHECKファンクションまたはCONVERGEプロシージャを実行できます。再確認または収束するスキャンのスキャンIDを指定します。比較結果のすべての行を再確認または収束するには、比較結果のルート・スキャンIDを指定します。

関連項目:

- 「共有データベース・オブジェクトの収束」

- 「比較の比較結果の再確認」

- 「データの比較および収束」

- 『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』

共有データベース・オブジェクトの収束

DBMS_COMPARISONパッケージのCONVERGEプロシージャは、データベース・オブジェクトの、指定した比較スキャンで比較された部分を同期化し、その変更に関する情報を戻します。CONVERGEプロシージャは、指定したスキャンで識別された違いのみを収束します。スキャンでは、表の行または列のサブセットの違いのみが識別され、指定したスキャンの完了後に違いが発生する場合があります。この場合、CONVERGEプロシージャによって、共有データベース・オブジェクトの一貫性が完全には保持されない可能性があります。

スキャンで最新の違いを処理するために、通常は、収束する比較スキャンの実行後できるかぎりすぐにCONVERGEプロシージャを実行することをお薦めします。また、いずれのデータベースでも更新されていない行のみを収束する必要があります。たとえば、共有データベース・オブジェクトがレプリケーション・コンポーネントによって更新されている場合は、レプリケーションによる変更が適用済の行のみを収束し、これらの行で新しい変更がレプリケート中でないことを確認します。

注意:
2つのデータベースで共有データベース・オブジェクトの行が異なることがスキャンで識別され、スキャン後にその行が変更された場合、CONVERGEプロシージャの実行後に、予期しないデータが行に含まれる可能性があります。

この項の例は、次のとおりです。

- ローカル・オブジェクトとの一貫性を保持するための共有データベース・オブジェクトの収束

- リモート・オブジェクトとの一貫性を保持するための共有データベース・オブジェクトの収束

- セッション・タグ・セットによる共有データベース・オブジェクトの収束

これらの例では、「行の違いを識別しない共有データベース・オブジェクトの比較」で生成される比較結果を収束します。その比較結果の例では、比較名はcompare_orders、戻されるスキャンIDは4です。この例を完了済の場合は、システムに戻されるスキャンIDが異なることがあります。スキャンIDを判別するには、次の問合せを実行します。

SELECT DISTINCT ROOT_SCAN_ID FROM DBA_COMPARISON_SCAN
WHERE COMPARISON_NAME = 'COMPARE_ORDERS';

複数の値が戻される場合、比較は複数回実行されています。この場合、戻された最大のスキャンIDを使用します。

比較結果のすべての行を収束する場合は、比較結果のルート・スキャンIDを指定します。ただし、比較結果の一部の行を収束する場合は、収束する違いが存在するスキャンのスキャンIDを指定できます。

関連項目:

- データベース・オブジェクトを比較する方法および比較スキャンの詳細は、「2つのデータベースの共有データベース・オブジェクトの比較」を参照してください。

- 違いが検出されたスキャンを表示する問合せについては、「データベース内の各スキャンに関する一般的な情報の表示」を参照してください。

- 各スキャンのルート・スキャンIDを表示する問合せについては、「データベース内の各スキャンの親スキャンIDおよびルート・スキャンIDの表示」を参照してください。

- CONVERGEプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

ローカル・オブジェクトとの一貫性を保持するための共有データベース・オブジェクトの収束

CONVERGEプロシージャのconverge_optionsパラメータは、収束時に優先するデータベースを決定します。ローカル・データベースを優先するように指定するには、converge_optionsパラメータをDBMS_COMPARISON.CMP_CONVERGE_LOCAL_WINSに設定します。ローカル・データベースを優先するように指定した場合、指定した比較スキャンで検出されたそれぞれの違いに対して、リモート・データベースのデータベース・オブジェクトのデータがローカル・データベースのデータベース・オブジェクトのデータに置き換えられます。

両方のデータベース・オブジェクトがローカル・データベースと一貫性を持つようにcompare_orders比較のスキャンを収束するには、次の手順を実行します。

1. 比較を所有する管理ユーザーとして、SQL*Plusからcomp1.example.comデータベースに接続します。また、このユーザーは、「共有データベース・オブジェクトの比較および収束の準備」で作成したデータベース・リンクに対するアクセス権を持っている必要があります。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

2. CONVERGEプロシージャを実行します。

SET SERVEROUTPUT ON
DECLARE
scan_info    DBMS_COMPARISON.COMPARISON_TYPE;
BEGIN
DBMS_COMPARISON.CONVERGE(
comparison_name  => 'compare_orders',
scan_id          => 4, -- Substitute the scan ID from your scan.
scan_info        => scan_info,
converge_options => DBMS_COMPARISON.CMP_CONVERGE_LOCAL_WINS);
DBMS_OUTPUT.PUT_LINE('Local Rows Merged: '||scan_info.loc_rows_merged);
DBMS_OUTPUT.PUT_LINE('Remote Rows Merged: '||scan_info.rmt_rows_merged);
DBMS_OUTPUT.PUT_LINE('Local Rows Deleted: '||scan_info.loc_rows_deleted);
DBMS_OUTPUT.PUT_LINE('Remote Rows Deleted: '||scan_info.rmt_rows_deleted);
END;
/

出力は次のようになります。

Local Rows Merged: 0
Remote Rows Merged: 6
Local Rows Deleted: 0
Remote Rows Deleted: 1

PL/SQL procedure successfully completed.

リモート・オブジェクトとの一貫性を保持するための共有データベース・オブジェクトの収束

CONVERGEプロシージャのconverge_optionsパラメータは、収束時に優先するデータベースを決定します。リモート・データベースを優先するように指定するには、converge_optionsパラメータをDBMS_COMPARISON.CMP_CONVERGE_REMOTE_WINSに設定します。リモート・データベースを優先するように指定した場合、指定した比較スキャンで検出されたそれぞれの違いに対して、ローカル・データベースのデータベース・オブジェクトのデータがリモート・データベースのデータベース・オブジェクトのデータに置き換えられます。

両方のデータベース・オブジェクトがリモート・データベースと一貫性を持つようにcompare_orders比較のスキャンを収束するには、次の手順を実行します。

1. 比較を所有する管理ユーザーとして、SQL*Plusからcomp1.example.comデータベースに接続します。また、このユーザーは、「共有データベース・オブジェクトの比較および収束の準備」で作成したデータベース・リンクに対するアクセス権を持っている必要があります。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

2. CONVERGEプロシージャを実行します。

SET SERVEROUTPUT ON
DECLARE
scan_info    DBMS_COMPARISON.COMPARISON_TYPE;
BEGIN
DBMS_COMPARISON.CONVERGE(
comparison_name  => 'compare_orders',
scan_id          => 4, -- Substitute the scan ID from your scan.
scan_info        => scan_info,
converge_options => DBMS_COMPARISON.CMP_CONVERGE_REMOTE_WINS);
DBMS_OUTPUT.PUT_LINE('Local Rows Merged: '||scan_info.loc_rows_merged);
DBMS_OUTPUT.PUT_LINE('Remote Rows Merged: '||scan_info.rmt_rows_merged);
DBMS_OUTPUT.PUT_LINE('Local Rows Deleted: '||scan_info.loc_rows_deleted);
DBMS_OUTPUT.PUT_LINE('Remote Rows Deleted: '||scan_info.rmt_rows_deleted);
END;
/

出力は次のようになります。

Local Rows Merged: 2
Remote Rows Merged: 0
Local Rows Deleted: 5
Remote Rows Deleted: 0

PL/SQL procedure successfully completed.

セッション・タグ・セットによる共有データベース・オブジェクトの収束

収束する共有データベース・オブジェクトがOracle Streamsレプリケーション環境に含まれている場合は、CONVERGEプロシージャによって行われた変更がレプリケートされないようにセッション・タグを設定できます。通常は、変更の循環(変更元のデータベースにその変更が再送信されること)を回避するために、CONVERGEプロシージャによって行われた変更はレプリケートしないようにする必要があります。Oracle Streamsレプリケーション環境では、セッション・タグを使用して、CONVERGEプロシージャによって行われた変更がOracle Streamsの取得プロセスまたは同期取得によって取得されず、レプリケートされないように設定できます。

CONVERGEプロシージャを実行しているセッションでセッション・タグを設定するには、次のプロシージャ・パラメータを使用します。

- local_converge_tagパラメータ: ローカル・データベースのセッション・タグを設定します。このパラメータには、リモート・データベースを優先し、CONVERGEプロシージャによってローカル・データベースに対して変更が行われる場合にレプリケーションを防止する値を設定します。

- remote_converge_tagパラメータ: リモート・データベースのセッション・タグを設定します。このパラメータには、ローカル・データベースを優先し、CONVERGEプロシージャによってリモート・データベースに対して変更が行われる場合にレプリケーションを防止する値を設定します。

セッション・タグの適切な値は、Oracle Streamsレプリケーション環境に応じて異なります。このタグには、セッションによって行われた変更が取得プロセスおよび同期取得によって取得されることを防止する値を設定します。

関連項目:
「レプリケーション環境のOracle Streamsタグ」

この項の例では、converge_optionsパラメータをDBMS_COMPARISON.CMP_CONVERGE_LOCAL_WINSに設定して、収束操作でローカル・データベースが優先されるように指定します。したがって、この例では、remote_converge_tagパラメータが'11'と等価の16進値に設定されます。セッション・タグは、CONVERGEプロシージャによってリモート・データベースに対して行われた変更がレプリケートされることを防止する任意の非NULL値に設定できます。

データベース・オブジェクトがローカル・データベースと一貫性を持ち、リモート・データベースでセッション・タグが設定されるようにcompare_orders比較のスキャンを収束するには、次の手順を実行します。

1. 比較を所有する管理ユーザーとして、SQL*Plusからcomp1.example.comデータベースに接続します。また、このユーザーは、「共有データベース・オブジェクトの比較および収束の準備」で作成したデータベース・リンクに対するアクセス権を持っている必要があります。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

2. CONVERGEプロシージャを実行します。

SET SERVEROUTPUT ON
DECLARE
scan_info    DBMS_COMPARISON.COMPARISON_TYPE;
BEGIN
DBMS_COMPARISON.CONVERGE(
comparison_name     => 'compare_orders',
scan_id             => 4, -- Substitute the scan ID from your scan.
scan_info           => scan_info,
converge_options    => DBMS_COMPARISON.CMP_CONVERGE_LOCAL_WINS,
remote_converge_tag => HEXTORAW('11'));
DBMS_OUTPUT.PUT_LINE('Local Rows Merged: '||scan_info.loc_rows_merged);
DBMS_OUTPUT.PUT_LINE('Remote Rows Merged: '||scan_info.rmt_rows_merged);
DBMS_OUTPUT.PUT_LINE('Local Rows Deleted: '||scan_info.loc_rows_deleted);
DBMS_OUTPUT.PUT_LINE('Remote Rows Deleted: '||scan_info.rmt_rows_deleted);
END;
/

出力は次のようになります。

Local Rows Merged: 0
Remote Rows Merged: 6
Local Rows Deleted: 0
Remote Rows Deleted: 1

PL/SQL procedure successfully completed.

注意:
CREATE_COMPARISONプロシージャで、ローカルおよびリモートの収束タグ値を設定することもできます。CONVERGEプロシージャのタグ・パラメータが非NULLの場合、このパラメータは、CREATE_COMPARISONプロシージャの対応するタグ・パラメータより優先されます。CONVERGEプロシージャのタグ・パラメータがNULLの場合、このパラメータは無視され、CREATE_COMPARISONプロシージャの対応するタグの値が使用されます。

比較の比較結果の再確認

DBMS_COMPARISONパッケージのRECHECKファンクションを使用すると、前回の比較スキャンを再確認できます。RECHECKファンクションは、指定した比較スキャンに記録された違いを、データベース・オブジェクトの現行のデータで確認します。

たとえば、compare_orders比較のスキャンID 4の結果を再確認するには、比較の所有者としてSQL*Plusにログインして、次のプロシージャを実行します。

SET SERVEROUTPUT ON
DECLARE
consistent   BOOLEAN;
BEGIN
consistent := DBMS_COMPARISON.RECHECK(
comparison_name => 'compare_orders',
scan_id         => 4);
IF consistent=TRUE THEN
DBMS_OUTPUT.PUT_LINE('No differences were found.');
ELSE
DBMS_OUTPUT.PUT_LINE('Differences were found.');
END IF;
END;
/

出力は次のようになります。

Differences were found.

PL/SQL procedure successfully completed.

このファンクションは、違いが検出されなかった場合はTRUE、違いが検出された場合はFALSEを戻します。compare_orders比較は、「行の違いを識別しない共有データベース・オブジェクトの比較」で作成されます。

注意:

- RECHECKファンクションは、共有データベース・オブジェクトで、指定した比較スキャンに記録されていない違いは比較しません。このような違いを確認するには、COMPAREファンクションを実行します。

- 指定した比較スキャンが正常に完了していない場合、RECHECKファンクションは、前回の比較スキャンが終了した箇所から開始されます。

関連項目:
COMPAREファンクションの詳細は、「2つのデータベースの共有データベース・オブジェクトの比較」を参照してください。

比較結果のパージ

DBMS_COMPARISONパッケージのPURGE_COMPARISONプロシージャを使用すると、不要になった1つ以上の比較の比較結果をパージできます。比較のすべての比較結果または比較結果のサブセットのいずれかをパージできます。比較結果をパージすると、比較の再確認または拡散したデータの収束に使用できなくなります。また、比較結果に関する情報が、データ・ディクショナリ・ビューから削除されます。

この項の内容は次のとおりです。

- 比較のすべての比較結果のパージ

- 比較の特定のスキャンIDの比較結果のパージ

- 指定した時間より前の比較の比較結果のパージ

関連項目:
「データの比較および収束」

比較のすべての比較結果のパージ

比較のすべての比較結果をパージするには、comparison_nameパラメータに比較名、scan_idおよびpurge_timeパラメータにデフォルト値のNULLを指定します。

たとえば、compare_orders比較のすべての比較結果をパージするには、比較の所有者としてSQL*Plusにログインして、次のプロシージャを実行します。

BEGIN
DBMS_COMPARISON.PURGE_COMPARISON(
comparison_name => 'compare_orders',
scan_id         => NULL,
purge_time      => NULL);
END;
/

比較の特定のスキャンIDの比較結果のパージ

比較の特定のスキャンの比較結果をパージするには、comparison_nameパラメータに比較名、scan_idパラメータにスキャンIDを指定します。指定するスキャンIDは、ルート・スキャンである必要があります。比較結果のルート・スキャンは、最も高いレベルの親スキャンです。ルート・スキャンには親は存在しません。ルート・スキャンIDを確認するには、DBA_COMPARISON_SCANデータ・ディクショナリ・ビューのROOT_SCAN_ID列を問い合せます。

PURGE_COMPARISONプロシージャを実行し、ルート・スキャンを指定すると、そのルート・スキャンはパージされます。また、指定したルート・スキャンのすべての直接的および間接的な子スキャンがパージされます。他のスキャンの結果はパージされません。

たとえば、compare_orders比較のスキャンID 4の比較結果をパージするには、比較の所有者としてSQL*Plusにログインして、次のプロシージャを実行します。

BEGIN
DBMS_COMPARISON.PURGE_COMPARISON(
comparison_name => 'compare_orders',
scan_id         => 4); -- Substitute the scan ID from your scan.
END;
/

関連項目:

- 「データベース内の各スキャンの親スキャンIDおよびルート・スキャンIDの表示」

- 『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』

指定した時間より前の比較の比較結果のパージ

比較で特定の日時またはそれより前に記録された比較結果をパージするには、comparison_nameパラメータに比較名、purge_timeパラメータに日時を指定します。結果は、スキャンIDに関係なくパージされます。指定した日時より後に記録された比較結果は保持されます。

たとえば、現行セッションのNLS_TIMESTAMP_FORMAT初期化パラメータの設定がYYYY-MM-DD HH24:MI:SSであるとします。compare_orders比較で2006年8月16日午後1時より前に記録されたすべてのスキャンの結果をパージするには、比較の所有者としてSQL*Plusにログインして、次のプロシージャを実行します。

BEGIN
DBMS_COMPARISON.PURGE_COMPARISON(
comparison_name => 'compare_orders',
purge_time      => '2006-08-16 13:00:00');
END;
/

比較の削除

比較およびそのすべての比較結果を削除するには、DBMS_COMPARISONパッケージのDROP_COMPARISONプロシージャを使用します。たとえば、compare_subset_columns比較を削除するには、比較の所有者としてSQL*Plusにログインして、次のプロシージャを実行します。

exec DBMS_COMPARISON.DROP_COMPARISON('compare_subset_columns');

Oracle Streamsレプリケーション環境でのDBMS_COMPARISONの使用

この項では、Oracle Streamsレプリケーション環境でのDBMS_COMPARISONパッケージの一般的な使用方法について説明します。次の使用方法があります。

- インスタンス化の後の一貫性の確認

- 稼働中のOracle Streamsレプリケーション環境での一貫性の確認

インスタンス化の後の一貫性の確認

インスタンス化の後、DBMS_COMPARISONパッケージを使用して、インスタンス化されたデータベース・オブジェクトの一貫性を検証できます。通常、Oracle Streamsレプリケーション環境で変更がレプリケートされる前に一貫性を検証する必要があります。ソース・データベース・オブジェクトおよびインスタンス化されたデータベース・オブジェクトに対する変更を許可する前に、一貫性を確認してください。これらのデータベース・オブジェクトに対する変更は、DBMS_COMPARISONパッケージによって違いとして識別されます。

インスタンス化されたデータベース・オブジェクトの一貫性を検証するには、次の手順を実行します。

1. CREATE_COMPARISONプロシージャを使用して、インスタンス化された各データベース・オブジェクトに対して比較を作成します。各比較に対して、インスタンス化されたデータベース・オブジェクトおよびソース・データベースの対応するデータベース・オブジェクトを指定する必要があります。
CREATE_COMPARISONプロシージャを実行する場合は、comparison_mode、scan_modeおよびscan_percentパラメータが、それぞれデフォルト値のCMP_COMPARE_MODE_OBJECT、CMP_SCAN_MODE_FULLおよびNULLに設定されていることを確認します。

2. COMPAREファンクションを実行して、インスタンス化された各データベース・オブジェクトを比較します。違いが検出されなかった場合、データベース・オブジェクトで一貫性が保持されています。
COMPAREファンクションを実行する場合、min_value、max_valueおよびperform_row_difパラメータが、それぞれデフォルト値のNULL、NULLおよびFALSEに設定されていることを確認します。

3. COMPAREファンクションで違いが検出された場合は、データベース・オブジェクトを再インスタンス化するか、またはCONVERGEプロシージャを使用してデータベース・オブジェクトを収束することができます。CONVERGEプロシージャを使用する場合は、通常、収束時にソース・データベース・オブジェクトを優先する必要があります。

4. データベース・オブジェクトで一貫性が保持されていることが比較結果に示されている場合は、PURGE_COMPARISONプロシージャを使用して比較結果をパージできます。

関連項目:

- CREATE_COMPARISONプロシージャで比較を作成する手順およびCOMPAREファンクションでデータベース・オブジェクトを比較する手順については、「2つのデータベースの共有データベース・オブジェクトの比較」を参照してください。

- 「共有データベース・オブジェクトの収束」

- 「比較結果のパージ」

- 第8章「インスタンス化とOracle Streamsレプリケーション」

稼働中のOracle Streamsレプリケーション環境での一貫性の確認

Oracle Streamsレプリケーション環境では、データベース・オブジェクトに対する変更が常にレプリケートされます。したがって、レプリケートされたデータベース・オブジェクトに次の内容が適用されます。

- レプリケートされたデータベースは、ほとんどの場合、ほぼ同期化されています。Oracle Streamsコンポーネントによって変更がレプリケートおよび適用され、レプリケートされたデータベース・オブジェクトの同期状態が保持されるためです。

- レプリケートされたデータベース・オブジェクトに違いが存在する場合は、通常、短期間のうちにOracle Streamsコンポーネントによって変更が送信および適用され、データベース・オブジェクトが同期化されます。したがって、COMPAREファンクションでは、レプリケート中の違いが示される場合があります。

変更のレプリケート中にデータベース・オブジェクトに違いが存在することが予測されるため、レプリケートされたデータベース・オブジェクトの比較にDBMS_COMPARISONパッケージを使用することが難しくなる場合があります。たとえば、2つのデータベースで表全体を比較する既存の比較が存在するとし、次の状況について考えてみます。

1. いずれかのデータベースで表の行が変更されます。

2. この変更がOracle Streamsの取得プロセスによって取得されます。ただし、この変更は他方のデータベースには伝播されていません。

3. COMPAREファンクションが実行され、2つのデータベースで表が比較されます。

4. COMPAREファンクションによって、手順 1で変更された行の違いが識別されます。

5. 変更が伝播され、宛先データベースで適用されます。したがって、手順4で識別された違いは存在しなくなります。

検出された違いが一時的であると考えられる場合は、一定時間が経過した後にRECHECKファンクションを実行できます。Oracle Streamsによってデータベース・オブジェクトが同期化されている場合、違いは検出されません。

レプリケートされたデータベース・オブジェクトで一部の行が継続的に更新される場合、それらの行の違いが常に比較結果に示される可能性があります。この場合は、環境を監視する際に、次のことを確認します。

- 宛先データベースで、それらの行に対して適用エラーが蓄積されていないこと。

- 宛先データベースで、それらの行がOracle Streamsの適用プロセスによって正しく更新されていること。宛先データベースでそれらの行が含まれている表を問い合せて、レプリケートされた変更が適用されていることを確認できます。

行がこれら両方の条件に該当する場合、比較結果でその行の違いを無視することができます。

COMPAREファンクションでは、レプリケート中の違いが示される場合があるため、このファンクションは、使用している環境のレプリケーション・アクティビティが最も少ない時間帯に実行することをお薦めします。レプリケーション・アクティビティが比較的少ない時間帯の比較結果には、Oracle Streamsレプリケーション環境で次のような違いが示されます。

- 管理者またはプロシージャが一方のデータベースでのみ行を手動で操作する場合に発生する違い。たとえば、管理者またはプロシージャが変更を行う前にセッション・タグを設定し、このセッション・タグによって取得プロセスで変更を取得できなくなる場合があります。

- 一方のデータベースでデータが失われ、別のデータベースでデータを確認してリカバリする必要がある場合に発生する違い。

- 適用エラーによって発生する違い。この場合は、適用エラーのため、一方のデータベースでエラー・トランザクションが適用されません。

いずれの場合も、必要に応じて、CONVERGEプロシージャを実行してデータベース・オブジェクトを同期化できます。たとえば、適用エラーが存在し、エラー・トランザクションを簡単に再実行できない場合、CONVERGEプロシージャを使用してデータベース・オブジェクトを同期化できます。

関連項目:

- CREATE_COMPARISONプロシージャで比較を作成する手順およびCOMPAREファンクションでデータベース・オブジェクトを比較する手順については、「2つのデータベースの共有データベース・オブジェクトの比較」を参照してください。

- RECHECKファンクションの詳細は、「比較の比較結果の再確認」を参照してください。

- 「共有データベース・オブジェクトの収束」

- 第10章「Oracle Streamsタグ」

- 適用エラーの詳細は、『Oracle Streams概要および管理』を参照してください。

14 論理変更レコード(LCR)の管理

この章では、Oracle Streamsレプリケーション環境で論理変更レコード(LCR)を管理する方法について説明します。

この章の内容は次のとおりです。

- LCRを管理するための要件

- LCRの構成とエンキュー

- LCRの実行

- LOB列を含むLCRの管理

- LONGまたはLONG RAW列を含むLCRの管理

関連項目:
LCRの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』および『Oracle Streams概要および管理』を参照してください。

LCRを管理するための要件

この項では、論理変更レコード(LCR)を作成または変更するための要件について説明します。LCR型のコンストラクタを使用してLCRを作成し、そのLCRをANYDATAキューの永続キュー部分にエンキューできます。このようなLCRは、永続LCRです。

また、適用ハンドラまたはルールベースの変換を使用して、LCRを変更できます。取得LCRまたは永続LCRを変更できます。

LCRを管理するときには、次の要件を満たしていることを確認してください。

- 行LCRを作成または変更する場合は、command_type属性に古い列値の有無および新しい列値の有無との一貫性があることを確認してください。

- DDL LCRを作成または変更する場合は、ddl_textがbase_table_name、base_table_owner、object_type、object_owner、object_nameおよびcommand_type属性と一貫していることを確認してください。

- ユーザーが構成する行LCRの列に許可されるデータ型は、次のとおりです。

- CHAR

- VARCHAR2

- NCHAR

- NVARCHAR2

- NUMBER

- DATE

- BINARY_FLOAT

- BINARY_DOUBLE

- RAW

- TIMESTAMP

- TIMESTAMP WITH TIME ZONE

- TIMESTAMP WITH LOCAL TIME ZONE

- INTERVAL YEAR TO MONTH

- INTERVAL DAY TO SECOND

ユーザーが構成する行LCRの列に許可されるデータ型は、これらのデータ型のみです。ただし、特定の方法を使用すると、LOB情報を含むLCRを構成できます。また、取得プロセスによって取得されるLCRでは、サポートされるデータ型がより多くなっていますが、同期取得によって取得されるLCRでは、サポートされるデータ型がより少なくなっています。

関連項目:

- 適用ハンドラの詳細は、『Oracle Streams概要および管理』を参照してください。

- 「LOB列を含むLCRの管理」

- 取得プロセスまたは同期取得によって取得されるデータ型、およびルールベースの変換の詳細は、『Oracle Streams概要および管理』を参照してください。

LCRの構成とエンキュー

次のLCRコンストラクタを使用してLCRを作成します。

- データ操作言語(DML)文によって生じた行に対する変更を含む行LCRを作成するには、SYS.LCR$_ROW_RECORDコンストラクタを使用します。

- データ定義言語(DDL)変更を含むDDL LCRを作成するには、SYS.LCR$_DDL_RECORDコンストラクタを使用します。各DDL LCRのddl_text属性に指定するDDLテキストが、Oracle SQL構文に準拠していることを確認してください。

次の例では、Oracle Database内のキューと、そのキューに関連付けられた適用プロセスを作成します。次に、渡された情報に基づいて行LCRを構成し、それをキューにエンキューするPL/SQLプロシージャを作成します。この例では、Oracle Streams管理者strmadminを構成して、この管理者にDBAロールを付与していると想定しています。

手順は次のとおりです。

1. SQL*Plusで、管理ユーザーとしてデータベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

2. Oracle Streams管理者にDBMS_STREAMS_MESSAGINGパッケージに対するEXECUTE権限を付与します。次に例を示します。

GRANT EXECUTE ON DBMS_STREAMS_MESSAGING TO strmadmin;

手順9のPL/SQLプロシージャ内でこのパッケージのプロシージャをコールするため、このパッケージに対する明示的なEXECUTE権限が必要です。この場合、ロールを介して権限を付与するのみでは不十分です。

3. SQL*Plusで、Oracle Streams管理者としてデータベースに接続します。

4. Oracle DatabaseにANYDATAキューを作成します。

BEGIN
DBMS_STREAMS_ADM.SET_UP_QUEUE(
queue_table          =>  'strm04_queue_table',
storage_clause       =>  NULL,
queue_name           =>  'strm04_queue');
END;
/

5. キュー内のメッセージを受信するOracle Databaseで、適用プロセスを作成します。適用プロセスでは、取得LCRではなく永続LCRが適用されるため、この適用プロセスの作成時には、apply_capturedパラメータをFALSEに設定してください。また、hr.regions表に変更が適用され、適用ユーザーにはこの表にDML変更を加える権限が必要であるため、apply_userパラメータがhrに設定されていることを確認してください。

BEGIN
DBMS_APPLY_ADM.CREATE_APPLY(
queue_name      => 'strm04_queue',
apply_name      => 'strm04_apply',
apply_captured  => FALSE,
apply_user      => 'hr');
END;
/

6. 適用プロセスのポジティブ・ルール・セットを作成し、DML変更をdbs1.example.comソース・データベースに作成されたhr.regions表に適用するルールを追加します。

BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
table_name          =>  'hr.regions',
streams_type        =>  'apply',
streams_name        =>  'strm04_apply',
queue_name          =>  'strm04_queue',
include_dml         =>  TRUE,
include_ddl         =>  FALSE,
include_tagged_lcr  =>  FALSE,
source_database     =>  'dbs1.example.com',
inclusion_rule      =>  TRUE);
END;
/

7. 適用プロセスのdisable_on_errorパラメータをnに設定します。

BEGIN
DBMS_APPLY_ADM.SET_PARAMETER(
apply_name  => 'strm04_apply',
parameter   => 'disable_on_error',
value       => 'N');
END;
/

8. 適用プロセスを起動します。

EXEC DBMS_APPLY_ADM.START_APPLY('strm04_apply');

9. 行LCRを構成して手順4で作成したキューにエンキューするプロシージャconstruct_row_lcrを作成します。

CREATE OR REPLACE PROCEDURE construct_row_lcr(
source_dbname  VARCHAR2,
cmd_type       VARCHAR2,
obj_owner      VARCHAR2,
obj_name       VARCHAR2,
old_vals       SYS.LCR$_ROW_LIST,
new_vals       SYS.LCR$_ROW_LIST) AS
row_lcr        SYS.LCR$_ROW_RECORD;
BEGIN
-- Construct the LCR based on information passed to procedure
row_lcr := SYS.LCR$_ROW_RECORD.CONSTRUCT(
source_database_name  =>  source_dbname,
command_type          =>  cmd_type,
object_owner          =>  obj_owner,
object_name           =>  obj_name,
old_values            =>  old_vals,
new_values            =>  new_vals);
-- Enqueue the created row LCR
DBMS_STREAMS_MESSAGING.ENQUEUE(
queue_name         =>  'strm04_queue',
payload            =>  ANYDATA.ConvertObject(row_lcr));
END construct_row_lcr;
/

注意:
トランザクション識別子やSCNは適用プロセスで生成されてメモリーに格納されるため、これらの値をLCRの作成時にアプリケーションで指定する必要はありません。LCRでトランザクション識別子またはSCNを指定しても、適用プロセスでは無視され、新規の値が割り当てられます。

関連項目:
LCRコンストラクタの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

10. 手順5で作成したconstruct_row_lcrプロシージャを使用してLCRを作成し、エンキューします。

1. SQL*Plusで、Oracle Streams管理者としてデータベースに接続します。

2. hr.regions表に1行を挿入する行LCRを作成します。

DECLARE
newunit1  SYS.LCR$_ROW_UNIT;
newunit2  SYS.LCR$_ROW_UNIT;
newvals   SYS.LCR$_ROW_LIST;
BEGIN
newunit1 := SYS.LCR$_ROW_UNIT(
'region_id',
ANYDATA.ConvertNumber(5),
DBMS_LCR.NOT_A_LOB,
NULL,
NULL);
newunit2 := SYS.LCR$_ROW_UNIT(
'region_name',
ANYDATA.ConvertVarchar2('Moon'),
DBMS_LCR.NOT_A_LOB,
NULL,
NULL);
newvals := SYS.LCR$_ROW_LIST(newunit1,newunit2);
construct_row_lcr(
source_dbname  =>  'dbs1.example.com',
cmd_type       =>  'INSERT',
obj_owner      =>  'hr',
obj_name       =>  'regions',
old_vals       =>  NULL,
new_vals       =>  newvals);
END;
/
COMMIT;

3. SQL*Plusで、hrユーザーとしてデータベースに接続します。

4. hr.regions表を問い合せて、適用済の行の変更を表示します。region_idが5である行は、region_nameがMoonとなっているはずです。

SELECT * FROM hr.regions;

5. SQL*Plusで、Oracle Streams管理者としてデータベースに接続します。

6. hr.regions表から1行を更新する行LCRを作成します。

DECLARE
oldunit1  SYS.LCR$_ROW_UNIT;
oldunit2  SYS.LCR$_ROW_UNIT;
oldvals   SYS.LCR$_ROW_LIST;
newunit1  SYS.LCR$_ROW_UNIT;
newvals   SYS.LCR$_ROW_LIST;
BEGIN
oldunit1 := SYS.LCR$_ROW_UNIT(
'region_id',
ANYDATA.ConvertNumber(5),
DBMS_LCR.NOT_A_LOB,
NULL,
NULL);
oldunit2 := SYS.LCR$_ROW_UNIT(
'region_name',
ANYDATA.ConvertVarchar2('Moon'),
DBMS_LCR.NOT_A_LOB,
NULL,
NULL);
oldvals := SYS.LCR$_ROW_LIST(oldunit1,oldunit2);
newunit1 := SYS.LCR$_ROW_UNIT(
'region_name',
ANYDATA.ConvertVarchar2('Mars'),
DBMS_LCR.NOT_A_LOB,
NULL,
NULL);
newvals := SYS.LCR$_ROW_LIST(newunit1);
construct_row_lcr(
source_dbname  =>  'dbs1.example.com',
cmd_type       =>  'UPDATE',
obj_owner      =>  'hr',
obj_name       =>  'regions',
old_vals       =>  oldvals,
new_vals       =>  newvals);
END;
/
COMMIT;

7. SQL*Plusで、hrユーザーとしてデータベースに接続します。

8. hr.regions表を問い合せて、適用済の行の変更を表示します。region_idが5である行は、region_nameがMarsとなっているはずです。

SELECT * FROM hr.regions;

9. hr.regions表から1行を削除する行LCRを作成します。

DECLARE
oldunit1  SYS.LCR$_ROW_UNIT;
oldunit2  SYS.LCR$_ROW_UNIT;
oldvals   SYS.LCR$_ROW_LIST;
BEGIN
oldunit1 := SYS.LCR$_ROW_UNIT(
'region_id',
ANYDATA.ConvertNumber(5),
DBMS_LCR.NOT_A_LOB,
NULL,
NULL);
oldunit2 := SYS.LCR$_ROW_UNIT(
'region_name',
ANYDATA.ConvertVarchar2('Mars'),
DBMS_LCR.NOT_A_LOB,
NULL,
NULL);
oldvals := SYS.LCR$_ROW_LIST(oldunit1,oldunit2);
construct_row_lcr(
source_dbname  =>  'dbs1.example.com',
cmd_type       =>  'DELETE',
obj_owner      =>  'hr',
obj_name       =>  'regions',
old_vals       =>  oldvals,
new_vals       =>  NULL);
END;
/
COMMIT;

10. SQL*Plusで、hrユーザーとしてデータベースに接続します。

11. hr.regions表を問い合せて、適用済の行の変更を表示します。region_idが5である行は、削除されているはずです。

SELECT * FROM hr.regions;

LCRの実行

行LCRおよびDDL LCR用に、個別のEXECUTEメンバー・プロシージャがあります。これらのメンバー・プロシージャを使用すると、現行ユーザーのセキュリティ・ドメインでLCRが実行されます。LCRが正常に実行されると、LCRに記録された変更がローカル・データベースに対して行われます。ここでは、行LCRおよびDDL LCRの実行について説明します。

- 行LCRの実行

- DDL LCRの実行

行LCRの実行

行LCR用のEXECUTEメンバー・プロシージャは、LCR$_ROW_RECORD型のサブプログラムです。行LCRにEXECUTEメンバー・プロシージャを実行すると、行LCRが実行されます。行LCRが適用プロセスによって実行される場合、LCRに対して実行される適用プロセスのハンドラは実行されません。

次のいずれかの条件が満たされる場合は、行LCRにEXECUTEメンバー・プロシージャを実行できます。

- LCRが適用ハンドラによって処理されている。

- LCRがキューに存在し、このLCRが適用プロセス、アプリケーションまたはユーザーによって最後にエンキューされたLCRである。

- LCRがLCR$_ROW_RECORDコンストラクタ・ファンクションを使用して構成されているが、エンキューされていない。

- LCRがエラー・キューに存在する。

行LCRにEXECUTEメンバー・プロシージャを実行する場合、競合解消を実行するかどうかをconflict_resolutionパラメータで制御します。具体的には、conflict_resolutionパラメータをTRUEに設定した場合、変更対象の表に定義されている競合解消を使用して、LCRの実行によって発生する競合が解消されます。conflict_resolutionパラメータをFALSEに設定した場合、競合解消は使用されません。conflict_resolutionパラメータを設定しない場合、またはNULLに設定した場合は、エラーが発生します。

注意:
カスタム・ルールベースの変換では、行LCRにEXECUTEメンバー・プロシージャを実行しないでください。実行すると、トランザクション・コンテキストの外部で行LCRが実行される場合があります。

関連項目:

- 『Oracle Streams概要および管理』

- 行LCRおよびLCR$_ROW_RECORD型の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

行LCRの構成および実行の例

この項の例では、PL/SQLプロシージャを作成し、行LCRを構成および実行することによってhr.jobs表の行の挿入、更新および削除を実行します。行LCRは、適用プロセスによってエンキューまたは処理されずに実行されます。この例では、Oracle Streams管理者strmadminを構成して、この管理者にDBAロールを付与していると想定しています。

手順は次のとおりです。

1. SQL*Plusで、Oracle Streams管理者としてデータベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

2. 行LCRを実行するPL/SQLプロシージャexecute_row_lcrを作成します。

CREATE OR REPLACE PROCEDURE execute_row_lcr(
source_dbname  VARCHAR2,
cmd_type       VARCHAR2,
obj_owner      VARCHAR2,
obj_name       VARCHAR2,
old_vals       SYS.LCR$_ROW_LIST,
new_vals       SYS.LCR$_ROW_LIST) as
xrow_lcr  SYS.LCR$_ROW_RECORD;
BEGIN
-- Construct the row LCR based on information passed to procedure
xrow_lcr := SYS.LCR$_ROW_RECORD.CONSTRUCT(
source_database_name => source_dbname,
command_type         => cmd_type,
object_owner         => obj_owner,
object_name          => obj_name,
old_values           => old_vals,
new_values           => new_vals);
-- Execute the row LCR
xrow_lcr.EXECUTE(FALSE);
END execute_row_lcr;
/

3. hr.jobs表に行を挿入する行LCRを実行するPL/SQLプロシージャinsert_job_lcrを作成します。

CREATE OR REPLACE PROCEDURE insert_job_lcr(
j_id     VARCHAR2,
j_title  VARCHAR2,
min_sal  NUMBER,
max_sal  NUMBER) AS
xrow_lcr   SYS.LCR$_ROW_RECORD;
col1_unit  SYS.LCR$_ROW_UNIT;
col2_unit  SYS.LCR$_ROW_UNIT;
col3_unit  SYS.LCR$_ROW_UNIT;
col4_unit  SYS.LCR$_ROW_UNIT;
newvals    SYS.LCR$_ROW_LIST;
BEGIN
col1_unit := SYS.LCR$_ROW_UNIT(
'job_id',
ANYDATA.ConvertVarchar2(j_id),
DBMS_LCR.NOT_A_LOB,
NULL,
NULL);
col2_unit := SYS.LCR$_ROW_UNIT(
'job_title',
ANYDATA.ConvertVarchar2(j_title),
DBMS_LCR.NOT_A_LOB,
NULL,
NULL);
col3_unit := SYS.LCR$_ROW_UNIT(
'min_salary',
ANYDATA.ConvertNumber(min_sal),
DBMS_LCR.NOT_A_LOB,
NULL,
NULL);
col4_unit := SYS.LCR$_ROW_UNIT(
'max_salary',
ANYDATA.ConvertNumber(max_sal),
DBMS_LCR.NOT_A_LOB,
NULL,
NULL);
newvals := SYS.LCR$_ROW_LIST(col1_unit,col2_unit,col3_unit,col4_unit);
-- Execute the row LCR
execute_row_lcr(
source_dbname => 'DB1.EXAMPLE.COM',
cmd_type      => 'INSERT',
obj_owner     => 'HR',
obj_name      => 'JOBS',
old_vals      => NULL,
new_vals      => newvals);
END insert_job_lcr;
/

4. hr.jobs表の行のmax_salary値を更新する行LCRを実行するPL/SQLプロシージャupdate_max_salary_lcrを作成します。

CREATE OR REPLACE PROCEDURE update_max_salary_lcr(
j_id         VARCHAR2,
old_max_sal NUMBER,
new_max_sal NUMBER) AS
xrow_lcr      SYS.LCR$_ROW_RECORD;
oldcol1_unit  SYS.LCR$_ROW_UNIT;
oldcol2_unit  SYS.LCR$_ROW_UNIT;
newcol1_unit  SYS.LCR$_ROW_UNIT;
oldvals       SYS.LCR$_ROW_LIST;
newvals       SYS.LCR$_ROW_LIST;
BEGIN
oldcol1_unit := SYS.LCR$_ROW_UNIT(
'job_id',
ANYDATA.ConvertVarchar2(j_id),
DBMS_LCR.NOT_A_LOB,
NULL,
NULL);
oldcol2_unit := SYS.LCR$_ROW_UNIT(
'max_salary',
ANYDATA.ConvertNumber(old_max_sal),
DBMS_LCR.NOT_A_LOB,
NULL,
NULL);
oldvals := SYS.LCR$_ROW_LIST(oldcol1_unit,oldcol2_unit);
newcol1_unit := SYS.LCR$_ROW_UNIT(
'max_salary',
ANYDATA.ConvertNumber(new_max_sal),
DBMS_LCR.NOT_A_LOB,
NULL,
NULL);
newvals := SYS.LCR$_ROW_LIST(newcol1_unit);
-- Execute the row LCR
execute_row_lcr(
source_dbname => 'DB1.EXAMPLE.COM',
cmd_type      => 'UPDATE',
obj_owner     => 'HR',
obj_name      => 'JOBS',
old_vals      => oldvals,
new_vals      => newvals);
END update_max_salary_lcr;
/

5. hr.jobs表から行を削除する行LCRを実行するPL/SQLプロシージャdelete_job_lcrを作成します。

CREATE OR REPLACE PROCEDURE delete_job_lcr(j_id VARCHAR2) AS
xrow_lcr   SYS.LCR$_ROW_RECORD;
col1_unit  SYS.LCR$_ROW_UNIT;
oldvals    SYS.LCR$_ROW_LIST;
BEGIN
col1_unit := SYS.LCR$_ROW_UNIT(
'job_id',
ANYDATA.ConvertVarchar2(j_id),
DBMS_LCR.NOT_A_LOB,
NULL,
NULL);
oldvals := SYS.LCR$_ROW_LIST(col1_unit);
-- Execute the row LCR
execute_row_lcr(
source_dbname => 'DB1.EXAMPLE.COM',
cmd_type      => 'DELETE',
obj_owner     => 'HR',
obj_name      => 'JOBS',
old_vals      => oldvals,
new_vals      => NULL);
END delete_job_lcr;
/

6. insert_job_lcrプロシージャを使用して、hr.jobs表に行を挿入します。

EXEC insert_job_lcr('BN_CNTR','BEAN COUNTER',5000,10000);

7. hr.jobs表に挿入された行を問い合せます。

SELECT * FROM hr.jobs WHERE job_id = 'BN_CNTR';

JOB_ID     JOB_TITLE                           MIN_SALARY MAX_SALARY
---------- ----------------------------------- ---------- ----------
BN_CNTR    BEAN COUNTER                              5000      10000

8. update_max_salary_lcrプロシージャを使用して、手順6でhr.jobs表に挿入した行のmax_salary値を更新します。

EXEC update_max_salary_lcr('BN_CNTR',10000,12000);

9. hr.jobs表で更新された行を問い合せます。

SELECT * FROM hr.jobs WHERE job_id = 'BN_CNTR';

JOB_ID     JOB_TITLE                           MIN_SALARY MAX_SALARY
---------- ----------------------------------- ---------- ----------
BN_CNTR    BEAN COUNTER                              5000      12000

10. delete_job_lcrプロシージャを使用して、手順6でhr.jobs表に挿入した行を削除します。

EXEC delete_job_lcr('BN_CNTR');

11. hr.jobs表から削除された行を問い合せます。

SELECT * FROM hr.jobs WHERE job_id = 'BN_CNTR';

no rows selected

DDL LCRの実行

DDL LCR用のEXECUTEメンバー・プロシージャは、LCR$_DDL_RECORD型のサブプログラムです。DDL LCRにEXECUTEメンバー・プロシージャを実行すると、LCRが実行され、LCRに対して実行される適用プロセスのハンドラは実行されません。DDL LCR用のEXECUTEメンバー・プロシージャを起動できるのは、適用プロセスの適用ハンドラ内のみです。

適用されたDDL LCRは、すべて自動的にコミットされます。したがって、DDLハンドラがDDL LCRのEXECUTEメンバー・プロシージャをコールすると、自動的にコミットが実行されます。

関連項目:

- 『Oracle Streams概要および管理』

- DDL LCRおよびLCR$_DDL_RECORD型の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

LOB列を含むLCRの管理

LOBデータ型は、取得プロセスによって取得される行LCRに存在できますが、他のデータ型として表されます。LOBデータ型は、同期取得によって取得される行LCRには存在できません。特定のLOBデータ型は、ユーザーが構成する行LCRには存在できません。表14-1に、これらのデータ型のLCR表現、および行LCRに存在できるかどうかを示します。

表14-1 行LCR内のLOBデータ型の表現

データ型

行LCR表現

取得プロセスによって取得される行LCRに存在できるかどうか

同期取得によって取得される行LCRに存在できるかどうか

ユーザーが構成する行LCRに存在できるかどうか

固定幅CLOB

VARCHAR2

できる

できない

できる

可変幅CLOB

AL16UTF16キャラクタ・セットのRAW

できる

できない

できない

NCLOB

AL16UTF16キャラクタ・セットのRAW

できる

できない

できない

BLOB

RAW

できる

できない

できる

CLOBとして格納されたXMLType

RAW

できる

できない

できない

Oracle Streams環境でのLOBデータ型に関係する行変更の一般的な考慮事項は、次のとおりです。

- LOB列に関係する行変更は、複数の行LCRとして取得、伝播および適用される場合があります。

- これらの行LCRの評価に使用されるルールは、ルール・セット内のルールが行変更に対応するすべての行LCRをTRUEと評価するか、またはどの行LCRもTRUEと評価しないように、決定的である必要があります。

ここでは、LOB列を構成または処理する場合に満たす必要のある要件、LOB列を含むLCRに対する適用プロセスの動作、およびLOBアセンブリについて説明します。また、LOB列を含むLCRを構成してエンキューする例も示します。

この項の内容は、次のとおりです。

- LOBを含むLCRの直接適用に対する適用プロセスの動作

- LOBアセンブリとLOB列を含むLCRのカスタム適用

- LOB列を含むLCRを構成および処理するための要件

関連項目:

- LOBの詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。

- LOBを含むLCRを構成してエンキューする例については、『Oracle Streams拡張例』を参照してください。

LOBを含むLCRの直接適用に対する適用プロセスの動作

LOB列を含むLCRを(適用ハンドラを使用せずに)直接適用すると、適用プロセスは次のように動作します。

- コマンド・タイプがINSERTまたはUPDATEのLCRにデータを含む新規のLOBがあり、lob_informationがDBMS_LCR.LOB_CHUNKまたはDBMS_LCR.LAST_LOB_CHUNKでない場合は、そのデータが適用されます。

- コマンド・タイプがINSERTまたはUPDATEのLCRにデータを含まない新規のLOBがあり、lob_informationがDBMS_LCR.EMPTY_LOBの場合は、空のLOBとして適用されます。

- コマンド・タイプがINSERTまたはUPDATEのLCRにデータを含まない新規のLOBがあり、lob_informationがDBMS_LCR.NULL_LOBまたはDBMS_LCR.INLINE_LOBの場合は、NULLとして適用されます。

- コマンド・タイプがINSERTまたはUPDATEのLCRに新規のLOBがあり、lob_informationがDBMS_LCR.LOB_CHUNKまたはDBMS_LCR.LAST_LOB_CHUNKの場合は、すべてのLOB値が無視されます。コマンド・タイプがINSERTの場合は、LOBチャンクが続くものとみなされ、列に空のLOBが挿入されます。コマンド・タイプがUPDATEの場合は、LOBチャンクが続くものとみなされ、列の値が無視されます。

- コマンド・タイプがUPDATEのLCR内の新規列がすべてLOBで、そのlob_informationがDBMS_LCR.LOB_CHUNKまたはDBMS_LCR.LAST_LOB_CHUNKの場合は、LOBチャンクが続くものとみなされ、更新がスキップされます。

- コマンド・タイプがUPDATEまたはDELETEのLCRの場合は、古いLOB値が無視されます。

LOBアセンブリとLOB列を含むLCRのカスタム適用

LOB列を含まない表の行に対して変更を行うと、1つの行LCRが生成されますが、1つ以上のLOB列を含む行に対して変更を行うと、複数の行LCRが生成される場合があります。適用プロセスは、LOB列を含む行LCRを適用ハンドラに送信しない場合、その行LCRを直接適用できます。ただし、Oracle Database 10g リリース2より前のリリースでは、1つの行変更に対して複数のLCRが適切に処理されるように適用ハンドラを構成する必要があったため、LOB列を含む行LCRのカスタム処理は複雑でした。

Oracle Database 10g リリース2以上では、LOBアセンブリによって、取得プロセスで取得されたLOB列を含む行LCRのカスタム処理が簡略化されています。LOBアセンブリを使用すると、LOB列を含む行に対する変更によって生成される複数の取得された行LCRが、1つの行LCRに自動的に結合されます。LOBアセンブリを有効にすると、適用プロセスがこの1つの行LCRをDMLハンドラまたはエラー・ハンドラに渡します。また、LOBアセンブリの実行後は、LOB列値がVARCHAR2またはRAWデータ型値ではなくLOBロケータとして表されます。プロシージャDMLハンドラまたはエラー・ハンドラにLOBアセンブリを有効化するには、DBMS_APPLY_ADM.SET_DML_HANDLERプロシージャでassemble_lobsパラメータをTRUEに設定します。文DMLハンドラに対しては、LOBアセンブリは常に有効化されています。

DMLハンドラまたはエラー・ハンドラに対してassemble_lobsパラメータをFALSEに設定した場合、LOBアセンブリは無効化され、LOB列を含む1行の変更に対して複数の行LCRがハンドラに渡されます。表14-2に、LOBアセンブリを無効化した場合のOracle Streamsの動作を示します。具体的には、LOB列を含む1行に対する変更によって生成され、プロシージャDMLハンドラまたはエラー・ハンドラに渡されるLCRを示します。

表14-2 LOBアセンブリを無効化した場合のOracle Streamsの動作

元の行変更

最初のLCRのセット

2番目のLCRのセット

3番目のLCRのセット

最後のLCRのセット

INSERT

1つのINSERT LCR

1つ以上のLOB WRITE LCR

1つ以上のLOB TRIM LCR

UPDATE

UPDATE

1つのUPDATE LCR

1つ以上のLOB WRITE LCR

1つ以上のLOB TRIM LCR

UPDATE

DELETE

1つのDELETE LCR

なし

なし

なし

DBMS_LOB.WRITE

1つ以上のLOB WRITE LCR

なし

なし

なし

DBMS_LOB.TRIM

1つのLOB TRIM LCR

なし

なし

なし

DBMS_LOB.ERASE

1つのLOB ERASE LCR

なし

なし

なし

表14-3に、LOBアセンブリを有効化した場合のOracle Streamsの動作を示します。具体的には、LOB列を含む1行に対する変更によって生成され、DMLハンドラまたはエラー・ハンドラに渡される行LCRを示します。

表14-3 LOBアセンブリを有効化した場合のOracle Streamsの動作

元の行変更

1つのLCR

INSERT

INSERT

UPDATE

UPDATE

DELETE

DELETE

DBMS_LOB.WRITE

LOB WRITE

DBMS_LOB.TRIM

LOB TRIM

DBMS_LOB.ERASE

LOB ERASE

LOBアセンブリを有効化すると、DMLハンドラまたはエラー・ハンドラによって、行LCRのLOB列が変更されます。DMLハンドラまたはエラー・ハンドラとして指定したPL/SQLプロシージャ内でLOBに対する操作を実行するには、DBMS_LOBパッケージのサブプログラムを使用することをお薦めします。行LCRにNULLのLOB列が含まれている場合、新しいLOBロケータでNULLを置き換える必要があります。EXECUTEメンバー・プロシージャを使用して行LCRを適用する場合は、行LCR用のADD_COLUMN、SET_VALUEおよびSET_VALUESメンバー・プロシージャを使用してLOBに対する変更を行います。

LOBアセンブリを有効化すると、LOBアセンブリによって、永続LCR内の非NULLのLOB列がLOBロケータに変換されます。ただし、LOBアセンブリでは、複数の永続行LCRが1つの行LCRに結合されません。たとえば、永続行LCRの場合、LOBアセンブリでは、INSERT行LCRの後に続く複数のLOB WRITE行LCRは1つのINSERT行LCRに結合されません。

関連項目:

- 適用ハンドラの詳細は、『Oracle Streams概要および管理』を参照してください。

- DBMS_LOBパッケージを使用する方法の詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』および『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- 行LCR用のADD_COLUMN、SET_VALUEおよびSET_VALUESメンバー・プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

LOBアセンブリに関する考慮事項

LOBアセンブリを使用する場合の考慮事項は次のとおりです。

- DMLハンドラまたはエラー・ハンドラを使用して、アセンブルされたLOBを複数の宛先データベースで処理するには、LOBアセンブリによって各宛先データベースで個別にLOBをアセンブルする必要があります。

- Oracle Database 10g リリース2より前のリリースのOracleが実行されているデータベースで取得された行LCRは、LOBアセンブリでアセンブルできません。

- 互換レベルが10.2.0より低いOracle Database 10g リリース2以上が実行されているデータベースで取得された行LCRは、LOBアセンブリでアセンブルできません。

- 適用ハンドラにLOBアセンブリを指定するには、適用ハンドラが実行されているデータベースの互換レベルが10.2.0以上である必要があります。

- LONGまたはLONG RAW列を含む表からの行LCRは、LOBアセンブリでアセンブルできません。

- DBMS_APPLY_ADMパッケージのSET_ENQUEUE_DESTINATIONおよびSET_EXECUTEプロシージャは、常に元のアセンブルされていない行LCRに実行されます。したがって、LOB列を含む行LCRの場合、行LCRが宛先データベースで適用ハンドラ用に個別にアセンブルされていても、元のアセンブルされていない行LCRがエンキューまたは実行されます。

- 取得、伝播または適用中に、LOB列を含む行LCRにルールベースの変換が実行された場合、適用ハンドラは変換済の行LCRに実行されます。ソース・データベースにLONGまたはLONG RAW列が存在し、ルールベースの変換で行LCR用のCONVERT_LONG_TO_LOB_CHUNKメンバー・ファンクションを使用してそれらの列がLOBに変換される場合、これらの行LCRに実行される適用ハンドラに対してLOBアセンブリを有効化できます。

- 行LCRに1つ以上のXMLType列が含まれている場合、DMLハンドラまたはエラー・ハンドラに対してassemble_lobsパラメータがFALSEに設定されていても、行LCRのすべてのXMLType列およびLOB列が常にアセンブルされます。

関連項目:

- データベースの互換レベルの詳細は、『Oracle Databaseリファレンス』および『Oracle Databaseアップグレード・ガイド』を参照してください。

- DBMS_APPLY_ADMパッケージのサブプログラムの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

LOBアセンブリの例

この項では、プロシージャDMLハンドラとともにLOBアセンブリを使用する例を示します。この例では、複数のデータベースでoe.production_information表を共有しているが、一部のデータベースのみを会社のオンラインWorld Wide Webカタログに使用している会社について考えます。この会社は各製品の写真をカタログ・データベースに格納する予定ですが、領域を節約するために、カタログ・データベース以外のデータベースには写真を格納しません。

この目標を達成するには、接続先カタログ・データベースのプロシージャDMLハンドラで、データ型BLOBの列photoを、ソース・データベースのproduct_information表に対して実行される各INSERTおよびUPDATEに追加します。ソース・データベースの表にphoto列は含まれません。プロシージャDMLハンドラは、接続先で既存の写真を使用して更新および挿入を実行するように構成されます。また、この会社には、すべてのデータベースのoe.product_information表にproduct_long_descを追加する目標もあります。この表には、簡単な説明を含むproduct_description列がすでに存在します。product_long_desc列のデータ型はCLOBで、詳細な説明が含まれています。詳細な説明は英語で記述されていますが、会社の1つのデータベースを使用して、会社のカタログがスペイン語で表示されます。したがって、適切な言語で詳細な説明が表示されるように、プロシージャDMLハンドラによってproduct_long_desc列が更新されます。

次の手順を実行して、LOBアセンブリを使用して前述の目標を達成するようにプロシージャDMLハンドラを構成します。

手順1: product_information表へのphoto列の追加

次の文を実行すると、photo列が宛先データベースのproduct_information表に追加されます。

ALTER TABLE oe.product_information ADD(photo BLOB);

手順2: product_information表へのproduct_long_desc列の追加

次の文を実行すると、product_long_desc列が、環境内のすべてのデータベースのproduct_information表に追加されます。

ALTER TABLE oe.product_information ADD(product_long_desc CLOB);

手順3: プロシージャDMLハンドラ用のPL/SQLプロシージャの作成

この例では、convert_product_informationプロシージャを作成します。このプロシージャは、プロシージャDMLハンドラ用に使用されます。このプロシージャでは、ユーザーが作成した次のPL/SQLサブプログラムが存在すると想定されています。

- get_photoプロシージャ。product_idに基づいてURLまたは表からBLOB形式の写真を取得し、引数として渡されたBLOBロケータを更新します。

- get_product_long_descプロシージャ。product_idのIN引数およびproduct_long_descのIN OUT引数を持ち、product_long_descをスペイン語に翻訳するか、または置換用のスペイン語の説明を取得して、product_long_descを更新します。

次のコードを実行すると、convert_product_informationプロシージャが作成されます。

CREATE OR REPLACE PROCEDURE convert_product_information(in_any IN ANYDATA)
IS
lcr                      SYS.LCR$_ROW_RECORD;
rc                       PLS_INTEGER;
product_id_anydata       ANYDATA;
photo_anydata            ANYDATA;
long_desc_anydata        ANYDATA;
tmp_photo                BLOB;
tmp_product_id           NUMBER;
tmp_prod_long_desc       CLOB;
tmp_prod_long_desc_src   CLOB;
tmp_prod_long_desc_dest  CLOB;
t                        PLS_INTEGER;
BEGIN
-- Access LCR
rc := in_any.GETOBJECT(lcr);
product_id_anydata := lcr.GET_VALUE('OLD', 'PRODUCT_ID');
t := product_id_anydata.GETNUMBER(tmp_product_id);
IF ((lcr.GET_COMMAND_TYPE = 'INSERT') or (lcr.GET_COMMAND_TYPE = 'UPDATE')) THEN
-- If there is no photo column in the lcr then it must be added
photo_anydata := lcr.GET_VALUE('NEW', 'PHOTO');
-- Check if photo has been sent and if so whether it is NULL
IF (photo_anydata is NULL) THEN
tmp_photo := NULL;
ELSE
t := photo_anydata.GETBLOB(tmp_photo);
END IF;
-- If tmp_photo is NULL then a new temporary LOB must be created and
-- updated with the photo if it exists
IF (tmp_photo is NULL) THEN
DBMS_LOB.CREATETEMPORARY(tmp_photo, TRUE);
get_photo(tmp_product_id, tmp_photo);
END IF;
-- If photo column did not exist then it must be added
IF (photo_anydata is NULL) THEN
lcr.ADD_COLUMN('NEW', 'PHOTO', ANYDATA.CONVERTBLOB(tmp_photo));
-- Else the existing photo column must be set to the new photo
ELSE
lcr.SET_VALUE('NEW', 'PHOTO', ANYDATA.CONVERTBLOB(tmp_photo));
END IF;
long_desc_anydata := lcr.GET_VALUE('NEW', 'PRODUCT_LONG_DESC');
IF (long_desc_anydata is NULL) THEN
tmp_prod_long_desc_src := NULL;
ELSE
t := long_desc_anydata.GETCLOB(tmp_prod_long_desc_src);
END IF;
IF (tmp_prod_long_desc_src IS NOT NULL) THEN
get_product_long_desc(tmp_product_id, tmp_prod_long_desc);
END IF;
-- If tmp_prod_long_desc IS NOT NULL, then use it to update the LCR
IF (tmp_prod_long_desc IS NOT NULL) THEN
lcr.SET_VALUE('NEW', 'PRODUCT_LONG_DESC',
ANYDATA.CONVERTCLOB(tmp_prod_long_desc_dest));
END IF;
END IF;
-- DBMS_LOB operations also are executed
-- Inserts and updates invoke all changes
lcr.EXECUTE(TRUE);
END;
/

手順4: 適用プロセスのプロシージャDMLハンドラの設定

この手順では、宛先データベースでのINSERT、UPDATEおよびLOB_UPDATE操作用のプロシージャDMLハンドラとしてconvert_product_informationプロシージャを設定します。SET_DML_HANDLERプロシージャを実行するたびに、assemble_lobsパラメータがTRUEに設定されていることに注意してください。

BEGIN
DBMS_APPLY_ADM.SET_DML_HANDLER(
object_name         => 'oe.product_information',
object_type         => 'TABLE',
operation_name      => 'INSERT',
error_handler       => FALSE,
user_procedure      => 'strmadmin.convert_product_information',
apply_database_link => NULL,
assemble_lobs       => TRUE);
DBMS_APPLY_ADM.SET_DML_HANDLER(
object_name         => 'oe.product_information',
object_type         => 'TABLE',
operation_name      => 'UPDATE',
error_handler       => FALSE,
user_procedure      => 'strmadmin.convert_product_information',
apply_database_link => NULL,
assemble_lobs       => TRUE);
DBMS_APPLY_ADM.SET_DML_HANDLER(
object_name         => 'oe.product_information',
object_type         => 'TABLE',
operation_name      => 'LOB_UPDATE',
error_handler       => FALSE,
user_procedure      => 'strmadmin.convert_product_information',
apply_database_link => NULL,
assemble_lobs       => TRUE);
END;
/

手順5: DBA_APPLY_DML_HANDLERSビューの問合せ

oe.product_information表に対してプロシージャDMLハンドラが適切に設定されていることを確認するには、次の問合せを実行します。

COLUMN OBJECT_OWNER HEADING 'Table|Owner' FORMAT A5
COLUMN OBJECT_NAME HEADING 'Table Name' FORMAT A20
COLUMN OPERATION_NAME HEADING 'Operation' FORMAT A10
COLUMN USER_PROCEDURE HEADING 'Handler Procedure' FORMAT A25
COLUMN ASSEMBLE_LOBS HEADING 'LOB Assembly?' FORMAT A15

SELECT OBJECT_OWNER,
OBJECT_NAME,
OPERATION_NAME,
USER_PROCEDURE,
ASSEMBLE_LOBS
FROM DBA_APPLY_DML_HANDLERS;

出力は次のようになります。

Table
Owner Table Name           Operation  Handler Procedure         LOB Assembly?
----- -------------------- ---------- ------------------------- ---------------
OE    PRODUCT_INFORMATION  INSERT     "STRMADMIN"."CONVERT_PROD Y
UCT_INFORMATION"

OE    PRODUCT_INFORMATION  UPDATE     "STRMADMIN"."CONVERT_PROD Y
UCT_INFORMATION"

OE    PRODUCT_INFORMATION  LOB_UPDATE "STRMADMIN"."CONVERT_PROD Y
UCT_INFORMATION"

正しいプロシージャconvert_product_informationが、表に対する各操作に使用されていることに注意してください。また、各ハンドラでLOBアセンブリが使用されていることにも注意してください。

LOB列を含むLCRを構成および処理するための要件

環境でLOB列を含む行LCRを生成する場合は、そのLCRを構成または処理するときに、次の項に示す要件を満たす必要があります。

- LOBアセンブリを使用せずにLCRを構成および処理するための要件

- LOBアセンブリを使用してLCRを適用ハンドラで処理するための要件

- LOBを含むLCRをルールベースの変換で処理するための要件

関連項目:
LOBを含むLCRを構成してエンキューする例については、『Oracle Streams拡張例』を参照してください。

LOBアセンブリを使用せずにLCRを構成および処理するための要件

LOB列を含むLCRを構成する場合、およびLOBアセンブリが無効化されているDMLハンドラまたはエラー・ハンドラでLOB列を処理する場合、次の要件を満たす必要があります。

- LOBアセンブリが無効化されているプロシージャDMLハンドラまたはエラー・ハンドラで、行LCR内のLOB列データを変更しないでください。ただし、DMLハンドラまたはエラー・ハンドラで、行LCR内のLOB以外の列を変更することはできます。

- 特定の操作にのみ起動される適用ハンドラで、LOB列を含む表からのLCRを処理しないでください。たとえば、INSERT操作にのみ起動される適用ハンドラによって、1つ以上のLOB列を含む表からのLCRを処理しないでください。

- LCRのLOB列のデータ部分が、VARCHAR2型またはRAW型である必要があります。VARCHAR2はCLOB、RAWはBLOBとして解析されます。

- ユーザーが構成する行LCRのLOB列は、BLOBまたは固定幅CLOBのいずれかである必要があります。NCLOB型または可変幅CLOB型のLOB列を含む行LCRは構成できません。

- 表外のLOBに有効なコマンド・タイプは、LOB WRITE、LOB ERASEおよびLOB TRIMのみです。

- LOB WRITE、LOB ERASEおよびLOB TRIMのLCRの場合は、old_valuesコレクションを空またはNULL、new_valuesを空以外にする必要があります。

- LOB WRITE LCRとLOB ERASE LCRの場合は、lob_offsetを有効な値にする必要があります。他のすべてのコマンド・タイプの場合は、その列のLOBチャンクが続くものとみなして、lob_offsetをNULLにする必要があります。

- LOB ERASE LCRとLOB TRIM LCRの場合は、lob_operation_sizeを有効な値にする必要があります。他のすべてのコマンド・タイプの場合は、lob_operation_sizeをNULLにする必要があります。

- LOB TRIMおよびLOB ERASEは、LCRに含まれているLOB列のlob_informationがLAST_LOB_CHUNKに設定されている場合にのみ有効なコマンド・タイプです。

- LOB WRITEは、LCRに含まれているLOB列のlob_informationがLAST_LOB_CHUNKまたはLOB_CHUNKに設定されている場合にのみ有効なコマンド・タイプです。

- lob_informationがNULL_LOBに設定されているLOBの場合は、列のデータ部分をVARCHAR2型のNULL(CLOBの場合)またはRAW型のNULL(BLOBの場合)にする必要があります。それ以外の場合は、非NULLのインラインLOB列として解析されます。

- 各LOB WRITE LCR、LOB ERASE LCRおよびLOB TRIM LCRに許容されるのは、1つの新規チャンクを持つ1つのLOB列参照のみです。

- LOB ERASE LCRおよびLOB TRIM LCR用の新規LOBチャンクは、ANYDATAにカプセル化されたNULL値にする必要があります。

前述の要件の妥当性チェックは、すべて適用プロセスによって実行されます。前述の要件が満たされない場合、LOB列を含む行LCRは適用プロセスでは適用できず、適用ハンドラでは処理できません。この場合、LCRは同じトランザクション内の他のLCRとともにエラー・キューに移動します。

関連項目:

- 「LCRの構成とエンキュー」

- 適用ハンドラの詳細は、『Oracle Streams概要および管理』を参照してください。

LOBアセンブリを使用してLCRを適用ハンドラで処理するための要件

LOBアセンブリが有効化されているDMLハンドラまたはエラー・ハンドラでLOB列を処理する場合、次の要件を満たす必要があります。

- アセンブルされたLOBを含む行LCR内のLOB列には、次の行LCRのメンバー・プロシージャを使用しないでください。

- SET_LOB_INFORMATION

- SET_LOB_OFFSET

- SET_LOB_OPERATION_SIZE

これらのいずれかのプロシージャを行LCR内のLOB列に使用すると、エラーが発生します。

- LOBアセンブリで構成した行LCRは、プロシージャDMLハンドラまたはエラー・ハンドラではエンキューできません。ただし、宛先データベースの1つ以上のハンドラにLOBアセンブリが有効化されている場合でも、DBMS_APPLY_ADMパッケージのSET_ENQUEUE_DESTINATIONプロシージャを使用して、LOB列を含む元のアセンブルされていない行LCRをエンキューできます。

前述の要件の妥当性チェックは、すべて適用プロセスによって実行されます。前述の要件が満たされない場合、LOB列を含む行LCRは適用プロセスでは適用できず、適用ハンドラでは処理できません。この場合、LCRは同じトランザクション内の他のLCRとともにエラー・キューに移動します。LOB列を含む行LCRの場合、元のアセンブルされていない行LCRがエラー・キューに置かれます。

関連項目:

- 適用ハンドラの詳細は、『Oracle Streams概要および管理』を参照してください。

- 行LCR用のメンバー・プロシージャおよびSET_ENQUEUE_DESTINATIONプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

LOBを含むLCRをルールベースの変換で処理するための要件

ルールベースの変換でLOB列を含む行LCRを処理する場合、次の要件を満たす必要があります。

- カスタム・ルールベースの変換で、行LCR内のLOB列データを変更しないでください。ただし、カスタム・ルールベースの変換で、LOB列を含む行LCR内のLOB以外の列を変更することはできます。

- カスタム・ルールベースの変換で行LCRを処理する場合、次の行LCRのメンバー・プロシージャをLOB列に使用することはできません。

- ADD_COLUMN

- SET_LOB_INFORMATION

- SET_LOB_OFFSET

- SET_LOB_OPERATION_SIZE

- SET_VALUE

- SET_VALUES

- DBMS_STREAMS_ADMパッケージのADD_COLUMNプロシージャで作成した宣言ルールベースの変換では、LOB列を行LCRに追加できません。

- 行変更に対応するすべての行LCRが同じ方法で変換されるように、LOB列を含む行LCRで実行されるルールベースの変換ファンクションは決定的である必要があります。

- 特定の操作にのみ起動されるカスタム・ルールベースの変換で、LOB列を含む表からのLCRを処理しないでください。たとえば、INSERT操作にのみ実行されるカスタム・ルールベースの変換によって、1つ以上のLOB列を含む表からのLCRを処理しないでください。

注意:
行LCRにLOB列が含まれる場合、ルールベースの変換は、常に元のアセンブルされていない行LCRに実行されます。

関連項目:

- 「LCRの構成とエンキュー」

- ルールベースの変換の詳細は、『Oracle Streams概要および管理』を参照してください。

- 行LCR用のメンバー・プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- 決定的なファンクションの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

LONGまたはLONG RAW列を含むLCRの管理

LONGおよびLONG RAWデータ型は、いずれも取得プロセスによって取得される行LCRに存在できますが、これらのデータ型は行LCR内では次のデータ型として表されます。

- LONGデータ型は、行LCR内ではVARCHAR2データ型として表されます。

- LONG RAWデータ型は、行LCR内ではRAWデータ型として表されます。

LONGまたはLONG RAW列に関係する行変更は、複数のLCRとして取得、伝播および適用される場合があります。環境でLONGまたはLONG RAW列を含むLCRを使用する場合は、LCRのLONGまたはLONG RAW列のデータ部分が、VARCHAR2型またはRAW型である必要があります。VARCHAR2はLONG、RAWはLONG RAWとして解析されます。

Oracle StreamsでLONGまたはLONG RAW列のデータを含む行LCRを処理する場合は、次の要件を満たす必要があります。

- カスタム・ルールベースの変換を使用して、LCR内のLONGまたはLONG RAW列のデータを変更しないでください。ただし、ルールベースの変換を使用して、LONGまたはLONG RAW列のデータを含む行LCR内のLONGおよびLONG RAW以外の列を変更することはできます。

- LONGまたはLONG RAWデータを含む行LCRを処理するカスタム・ルールベースの変換では、行LCRのSET_VALUEまたはSET_VALUESメンバー・プロシージャは使用しないでください。これらのメンバー・プロシージャを使用すると、ORA-26679エラーが発生します。

- 行変更に対応するすべてのLCRが同じ方法で変換されるように、LONGまたはLONG RAW列を含むLCRで実行されるルールベースの変換ファンクションは決定的である必要があります。

- DBMS_STREAMS_ADMパッケージのADD_COLUMNプロシージャで作成した宣言ルールベースの変換では、LONGまたはLONG RAW列を行LCRに追加できません。

- プロシージャDMLハンドラまたはエラー・ハンドラを使用して、LONGまたはLONG RAW列のデータを含む行LCRを処理することはできません。

- LONGまたはLONG RAW列を含むLCRの評価に使用されるルールは、ルール・セット内のルールが行変更に対応するすべてのLCRをTRUEと評価するか、またはどのLCRもTRUEと評価しないように、決定的である必要があります。

- 適用プロセスを使用して、LONGまたはLONG RAW列のデータを含むLCRを宛先キューにエンキューすることはできません。DBMS_APPLY_ADMパッケージのSET_DESTINATION_QUEUEプロシージャを実行すると、指定した適用プロセスのルールを満たすLCRの宛先キューが設定されます。

注意:
LONGおよびLONG RAWデータ型は、同期取得によって取得される行LCRまたはユーザーが構成する行LCRには存在できません。

関連項目:

- ルールベースの変換の詳細は、『Oracle Streams概要および管理』を参照してください。

- 決定的なファンクションの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

第III部

Oracle Streamsレプリケーションのベスト・プラクティス

ビジネス要件に応じて多くの異なる方法でOracle Streamsレプリケーションを構成できます。たとえば、次の要件を満たすようにOracle Streamsを構成できます。

- データベースの構造または命名規則が異なっている場合でも、あるデータベースから1つ以上のデータベースにデータをレプリケートします。

- ハードウェア・プラットフォーム、データベース・リリースおよびキャラクタ・セット間でデータをレプリケートします。

- 構造が異なる複数ソースから1つのデータベースにデータを統合します。

- データベースまたはアプリケーションのアップグレードの実行時、またはハードウェア・プラットフォーム間の移行時に高可用性を提供します。

この部の次の章では、Oracle Streamsレプリケーションのベスト・プラクティスについて説明します。

- 第15章「Oracle Streamsレプリケーション・データベースのベスト・プラクティス」

- 第16章「取得のベスト・プラクティス」

- 第17章「伝播のベスト・プラクティス」

- 第18章「適用のベスト・プラクティス」

15 Oracle Streamsレプリケーション・データベースのベスト・プラクティス

Oracle Streamsレプリケーション・データベースとは、Oracle Streamsレプリケーション環境のデータベースです。Oracle Streamsレプリケーション環境では、あるデータベースから別のデータベースへデータベースの変更をレプリケートするOracle Streamsクライアントを使用します。Oracle Streamsクライアントには、取得プロセス、同期取得、伝播および適用プロセスが含まれます。この章では、Oracle Streamsレプリケーション・データベースの一般的なベスト・プラクティスについて説明します。

この章の内容は次のとおりです。

- Oracle Streamsデータベース構成のベスト・プラクティス

- Oracle Streamsデータベースの操作のベスト・プラクティス

- Oracle Real Application ClustersおよびOracle Streamsのベスト・プラクティス

Oracle Streamsデータベース構成のベスト・プラクティス

Oracle Streamsレプリケーション環境を適切かつ効率的に実行するために、環境を構成する際にこの項のベスト・プラクティスに従います。この項の内容は次のとおりです。

- Oracle Streamsクライアント(取得および適用プロセス)用の個別のキューの使用

- Oracle Streamsレプリケーション構成の自動化

関連項目:
Oracle Streamsレプリケーションの準備のベスト・プラクティスについては、第1章「Oracle Streamsレプリケーションの準備」を参照してください。

Oracle Streamsクライアント(取得および適用プロセス)用の個別のキューの使用

各取得プロセス、各同期取得および各適用プロセス用に個別のキューを構成し、各キューに独自のキュー表があることを確認します。2つのデータベース間で双方向のレプリケーションを構成する場合、または単一のデータベースが複数の他のデータベースからメッセージを受信する場合に、個別のキューを使用することは特に重要です。

たとえば、db1というデータベースが取得プロセスを使用して他のデータベースに送信される変更を取得しており、db2というデータベースから変更を受信していると想定します。db2から受信される変更がdb1上で実行する適用プロセスによって適用されます。この例では、db1で取得プロセスおよび適用プロセス用に個別のキューを作成し、これらのキューが異なるキュー表を使用することを確認します。

次の例では、取得プロセスのキューを作成します。キュー名はcapture_queueで、このキューはキュー表qt_capture_queueを使用します。

BEGIN
DBMS_STREAMS_ADM.SET_UP_QUEUE(
queue_table => 'strmadmin.qt_capture_queue',
queue_name  => 'strmadmin.capture_queue');
END;
/

次の例では、適用プロセスのキューを作成します。キュー名はapply_queueで、このキューはキュー表qt_apply_queueを使用します。

BEGIN
DBMS_STREAMS_ADM.SET_UP_QUEUE(
queue_table => 'strmadmin.qt_apply_queue',
queue_name  => 'strmadmin.apply_queue');
END;
/

その後、db1で取得プロセスを構成する際に、キューstrmadmin.capture_queueを指定し、db1で適用プロセスを構成する際に、キューstrmadmin.apply_queueを指定します。必要に応じて、SET_UP_QUEUEプロシージャを使用すると、各キュー表用に個別の表領域および記憶域の仕様を構成するために、storage_clauseパラメータを指定できます。

「Oracle Streamsレプリケーション構成の自動化」の説明に従って構成を自動化すると、各Oracle Streamsクライアントは独自のキューを使用して自動的に構成されるようになります。

関連項目:

- 「ANYDATAキューの作成」

- 「取得プロセスの構成」

- 第7章「暗黙的適用の構成」

Oracle Streamsレプリケーション構成の自動化

可能な場合にOracle Streamsレプリケーション環境を作成するには、DBMS_STREAMS_ADMパッケージの次のプロシージャを使用します。

- MAINTAIN_GLOBAL: 2つのデータベース間でデータベース・レベルの変更をレプリケートするOracle Streams環境が構成されます。

- MAINTAIN_SCHEMAS: 2つのデータベース間で、指定されたスキーマに対する変更をレプリケートするOracle Streams環境が構成されます。

- MAINTAIN_SIMPLE_TTS: 宛先データベースでソース・データベースからの単一の表領域がクローニングされ、Oracle Streamsを使用して両方のデータベースでこの表領域がメンテナンスされます。

- MAINTAIN_TABLES: 2つのデータベース間で、指定された表に対する変更をレプリケートするOracle Streams環境が構成されます。

- MAINTAIN_TTS: 宛先データベースでソース・データベースからの表領域セットがクローニングされ、Oracle Streamsを使用して両方のデータベースでこれらの表領域がメンテナンスされます。

- PRE_INSTANTIATION_SETUPおよびPOST_INSTANTIATION_SETUP: 2つのデータベース間でデータベース・レベルの変更または指定された表に対する変更をレプリケートするOracle Streams環境が構成されます。Oracle Streamsレプリケーションの構成を完了するには、これらのプロシージャをともに使用し、インスタンス化の操作を手動で実行する必要があります。

これらのプロシージャによって複数のデータベースでOracle Streamsクライアントの構成全体が自動化されます。さらに、構成はOracle Streamsのベスト・プラクティスに従います。たとえば、可能な場合はこれらのプロシージャによってキュー・ツー・キュー伝播が作成されます。

これらのプロシージャが環境に適さない場合は、Oracle Streamsクライアント、ルール・セットおよびルールを作成するために、DBMS_STREAMS_ADMパッケージの次のプロシージャを使用します。

- ADD_TABLE_RULES

- ADD_SUBSET_RULES

- ADD_SCHEMA_RULES

- ADD_GLOBAL_RULES

- ADD_TABLE_PROPAGATION_RULES

- ADD_SUBSET_PROPAGATION_RULES

- ADD_SCHEMA_PROPAGATION_RULES

- ADD_GLOBAL_PROPAGATION_RULES

これらのプロシージャは、Oracle Streamsクライアントを構成するのに必要な手順の数を最小化します。また、存在しないオブジェクトのルールを作成することが可能なため、ルールに指定された各オブジェクトのスペルは注意して確認してください。

一般的にはお薦めしませんが、キュー内のすべてのメッセージを常に伝播または適用する場合、ルール・セットまたはルールなしで伝播または適用プロセスを使用できます。ただし、取得プロセスにはルールと1つ以上のルール・セット、同期取得にはポジティブ・ルール・セットが必要です。サポートされないオブジェクトに対する変更がフィルタ処理されるように、取得プロセスに対してネガティブ・ルール・セットを構成すると、ADD_GLOBAL_RULESプロシージャを使用して、データベース全体に対するデータ操作言語(DML)変更を取得プロセスで取得できます。また、ADD_GLOBAL_RULESプロシージャを使用して、データベースに対するすべてのデータ定義言語(DDL)変更を取得プロセスで取得することもできます。

伝播のルール・セットのルールは、取得プロセスまたは同期取得に指定されたルールと異なっていてもかまいません。たとえば、すべての取得された変更が宛先データベースに伝播されるように構成する場合は、たとえ取得プロセスまたは同期取得のADD_TABLE_RULESを使用して複数のルールを構成したとしても、伝播のADD_GLOBAL_PROPAGATION_RULESプロシージャを実行できます。同様に、適用プロセスのルール・セットのルールは、メッセージを取得して適用プロセスに伝播する取得プロセス、同期取得および伝播に指定されたルールと異なっていてもかまいません。

Oracle Streamsクライアントは、複数の表またはスキーマの変更を処理できます。パフォーマンスを最適化するために、これらの表またはスキーマのルールが単純であることを確認します。複雑なルールは、Oracle Streamsのパフォーマンスに影響します。たとえば、LIKE句を含む条件があるルールは複雑です。ルールを作成するためにDBMS_STREAMS_ADMパッケージのプロシージャを使用する場合は、常にルールは単純です。

Oracle Streamsレプリケーション環境に複数のソース・データベースを構成する際、変更の循環を回避する必要があります。変更の循環とは、変更が発生場所であるデータベースに再送されることです。Oracle Streamsタグを使用して変更の循環を回避できます。

関連項目:

- 「DBMS_STREAMS_ADMパッケージを使用したレプリケーションの構成」

- 「キュー・ツー・キュー伝播の使用」

- 変更の循環を回避するためのOracle Streamsタグの使用の詳細は、「レプリケーション環境のOracle Streamsタグ」を参照してください。

- 単純および複雑なルールの詳細は、『Oracle Streams概要および管理』を参照してください。

Oracle Streamsデータベースの操作のベスト・プラクティス

Oracle Streamsレプリケーション環境を構成した後、適切かつ効率的に実行するには、この項のベスト・プラクティスに従います。この項の内容は次のとおりです。

- Oracle Streamsデータベースのグローバル名のベスト・プラクティスへの準拠

- パフォーマンスの監視と必要に応じた調整

- サイズに対する取得プロセスのキューおよび同期取得のキューの監視

- バックアップのOracle Streamsのベスト・プラクティスへの準拠

- オプティマイザ統計の自動収集の調整

- Oracle Streams情報のアラート・ログの確認

- データベースでOracle Streams構成を削除するベスト・プラクティスへの準拠

Oracle Streamsデータベースのグローバル名のベスト・プラクティスへの準拠

Oracle Streamsでは、特定のデータベースからの変更または特定のデータベースへの変更を識別するために、データベースのグローバル名を使用します。たとえば、一般的に取得、伝播および適用のシステム生成ルールでは、ソース・データベースのグローバル名を指定します。また、Oracle Streams取得プロセスまたは同期取得によって取得された変更には、ソース・データベースの現行のグローバル名が自動的に含まれます。可能な場合、環境を構成した後はOracle Streamsレプリケーション環境内のデータベースのグローバル名は変更しません。また、データベース・リンク名が各宛先データベースのグローバル名と一致することを保証するには、GLOBAL_NAMES初期化パラメータをTRUEに設定する必要があります。

Oracle Streamsデータベースのグローバル名を変更する必要がある場合は、データベース上でのユーザーによる変更が不可能で、キューが空で、適用プロセスによって未解決の変更を適用する必要がないときに、一度に実行します。これらの要件を満たす場合、データベースのグローバル名を変更し、変更されたデータベースを参照するOracle Streams構成の一部を再作成できます。ソース・データベースのグローバル名が変更される場合、伝播、適用プロセスなどのすべてのキュー・サブスクライバを再作成する必要があります。

関連項目:
「ソース・データベースのDBIDまたはグローバル名の変更」

パフォーマンスの監視と必要に応じた調整

Oracle Database 11g リリース1(11.1)以上のデータベースでは、Oracle Streamsパフォーマンス・アドバイザによって、Oracle Streamsコンポーネントの実行状況に関する情報が提供されます。このアドバイザを使用すると、環境内の複数のOracle Streamsコンポーネントのパフォーマンスを監視して、必要に応じて調整を行い、パフォーマンスを向上させることができます。

UTL_SPADVパッケージでも、Oracle Streams環境のパフォーマンス統計が提供されます。このパッケージは、Oracle Streamsパフォーマンス・アドバイザを使用してパフォーマンス統計を収集します。このパッケージを使用すると、分析用にスプレッドシートにインポートできる形式で統計を出力することができます。

Oracle Database 11g リリース1(11.1)より前のリリースのデータベースでは、STRMMONを使用してOracle Streams環境のパフォーマンスを監視できます。このツールを使用して、データベース内のOracle Streamsアクティビティの概要を迅速に把握することができます。STRMMONは、情報を1行でレポートします。レポート間隔および表示の反復回数を構成できます。STRMMONは、Oracleホームのrdbms/demoディレクトリで使用可能です。

関連項目:

- Oracle Streamsパフォーマンス・アドバイザの詳細は、『Oracle Streams概要および管理』を参照してください。

- UTL_SPADVパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

サイズに対する取得プロセスのキューおよび同期取得のキューの監視

キューのサイズをチェックするために取得プロセスによって使用されるキューを監視する必要があります。キュー内のメッセージが1つ以上の宛先キューに伝播できない場合、取得プロセスまたは同期取得によって使用されるキュー内のメッセージ数は増加します。ソース・キューのサイズの増加は、Oracle Streamsレプリケーション環境に問題があることを示す場合が多くあります。メッセージを伝播できない一般的な理由は次のとおりです。

- 宛先データベースのいずれかが長期間停止している。

- 宛先データベースの適用プロセスが長期間無効化されている。

- キューが、ネットワークの問題または伝播ジョブの問題のため、長期間メッセージを特定の宛先キューに配信できない伝播のソース・キューである。

取得プロセスのキューのサイズが増加すると、取得プロセスは、ディスクにオーバーフローするメッセージの数を最小化するフロー制御のために中断します。V$BUFFERED_QUEUES動的パフォーマンス・ビューを問い合せて取得プロセスのキュー内のメッセージ数を監視できます。このビューには、メモリ内のメッセージ数およびディスクにオーバーフローしたメッセージ数が表示されます。

V$PERSISTENT_QUEUESまたはV$AQ動的パフォーマンス・ビューを問い合せて同期取得のキュー内のメッセージ数を監視できます。このビューには、永続キュー内の様々なメッセージ状態のメッセージの数が表示されます。

伝播はOracle Schedulerを使用して実装します。ジョブを連続して16回実行できない場合は、ジョブは「故障」としてマークされ、強制終了されます。ソース・キューのサイズを最小化するために伝播ジョブが正常に動作していることを確認するには、定期的に伝播ジョブをチェックします。

関連項目:
「故障した伝播の再起動」

バックアップのOracle Streamsのベスト・プラクティスへの準拠

次の項には、Oracle Streamsレプリケーション環境内のソース・データベースおよび宛先データベースをバックアップするベスト・プラクティスに関する情報が含まれます。単一のデータベースがソース・データベースおよび宛先データベースの両方である場合があります。

Oracle Streamsソース・データベースのバックアップのベスト・プラクティス

ソース・データベースとは、取得プロセスによって取得される変更がREDOログで生成されるデータベース、またはOracle Streams同期取得が構成されるデータベースです。次のOracle Streamsソース・データベースのバックアップのベスト・プラクティスに従います。

- ソース・データベースに対する変更を取得する取得プロセスがバックアップ文を取得しないことを確認するために、オンライン・バックアップSQL文を実行するセッションでOracle Streamsタグを使用します。オンライン・バックアップ文では、ALTER TABLESPACEまたはALTER DATABASE文のBEGIN BACKUPおよびEND BACKUP句が使用されます。Oracle Streamsセッション・タグを設定するには、DBMS_STREAMS.SET_TAGプロシージャを使用します。

注意:
Recovery Manager(RMAN)を使用して実行するバックアップでは、Oracle Streamsセッション・タグを設定する必要はありません。

関連項目:
第10章「Oracle Streamsタグ」

- 取得プロセスで必要なアーカイブ・ログを削除する可能性があるアーカイブ・ログの自動バックアップは許可しないでください。取得プロセスによるすべての必要なアーカイブ・ログ・ファイルの処理が完了するまで、それらのファイルが予期された場所にあり、オンラインで使用可能であることはOracle Streams環境では特に重要です。取得プロセスで必要なログが使用不可能な場合、取得プロセスは異常終了します。
データベース内の必要な各アーカイブREDOログを表示するには、次の問合せを実行します。

COLUMN CONSUMER_NAME HEADING 'Capture|Process|Name' FORMAT A15
COLUMN SOURCE_DATABASE HEADING 'Source|Database' FORMAT A10
COLUMN SEQUENCE# HEADING 'Sequence|Number' FORMAT 99999
COLUMN NAME HEADING 'Required|Archived Redo Log|File Name' FORMAT A40

SELECT r.CONSUMER_NAME,
r.SOURCE_DATABASE,
r.SEQUENCE#,
r.NAME
FROM DBA_REGISTERED_ARCHIVED_LOG r, DBA_CAPTURE c
WHERE r.CONSUMER_NAME =  c.CAPTURE_NAME AND
r.NEXT_SCN      >= c.REQUIRED_CHECKPOINT_SCN;

- すべてのスレッドからのすべてのアーカイブ・ログ・ファイルが使用可能であることを確認します。データベース・リカバリはこれらのログの可用性に応じて異なるため、ログが欠落すると、不完全リカバリになります。

- ソース・データベースで不完全リカバリ(Point-in-Timeリカバリ)が発生する状況では、「単一ソース環境のソースにおけるPoint-in-Timeリカバリの実行」または「複数ソース環境におけるPoint-in-Timeリカバリの実行」の手順に従います。

Oracle Streams宛先データベースのバックアップのベスト・プラクティス

Oracle Streamsレプリケーション環境では、宛先データベースは、適用プロセスが変更を適用するデータベースです。Oracle Streams宛先データベースのバックアップに関する次のベスト・プラクティスに従います。

- commit_serialization適用プロセス・パラメータがFULLに設定されていることを確認します。

- 宛先データベースで不完全リカバリ(Point-in-Timeリカバリ)が発生する状況では、「宛先データベースにおけるPoint-in-Timeリカバリの実行」の手順に従います。

オプティマイザ統計の自動収集の調整

デフォルトでは毎晩、オプティマイザは統計が古くなった表に関する統計を自動的に収集します。Oracle Streamsキュー表などの揮発性表の場合、これらの表が完全ロード期間を表すデータを所有していないときに、統計収集ジョブが動作する可能性があります。

DBMS_AQADM.CREATE_QUEUE_TABLEまたはDBMS_STREAMS_ADM.SETUP_QUEUEプロシージャを使用して、これらの揮発性キュー表を作成します。これらのプロシージャを実行する際にキュー表の名前を指定します。キュー表が作成され、その表が揮発性である場合は、キュー表に加えて次の表が作成されます。

- AQ$_queue_table_name_I

- AQ$_queue_table_name_H

- AQ$_queue_table_name_T

- AQ$_queue_table_name_P

- AQ$_queue_table_name_D

- AQ$_queue_table_name_C

queue_table_name をキュー表の名前に置換します。

次の手順を完了して、揮発性表で統計を収集することをお薦めします。

1. これらの表が一杯のときに、揮発性表でDBMS_STATS.GATHER_TABLE_STATSプロシージャを手動で実行します。

2. 揮発性表で統計が収集された直後に、これらの表でDBMS_STATS.LOCK_TABLE_STATSプロシージャを実行します。

揮発性表で統計をロックすると、自動統計収集ジョブがこれらの表をスキップして、表が分析されません。

関連項目:
オプティマイザ統計の管理の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

Oracle Streams情報のアラート・ログの確認

デフォルトでは、アラート・ログには、Oracle Streamsの取得プロセスおよび適用プロセスが停止した理由に関する情報が含まれます。また、Oracle Streamsの取得プロセスおよび適用プロセスは、アラート・ログに長時間実行トランザクションおよび大規模なトランザクションをレポートします。

長時間実行トランザクションとは、長期間(20分)アクティビティがない(新しい変更レコード、ロールバック、コミットがない)オープン・トランザクションです。大規模なトランザクションとは、大量の変更レコードがあるオープン・トランザクションです。アラート・ログでは、長時間実行トランザクションまたは大規模なトランザクションが20分ごとに確認されたかどうかをレポートします。各20分間で1つのトランザクションのみがレポートされるため、すべてのそのようなトランザクションがレポートされるわけではありません。コミットまたはロールバックが受け入れられると、この情報はアラート・ログにもレポートされます。

長時間実行トランザクションについて次のビューを使用できます。

- V$STREAMS_TRANSACTION動的パフォーマンス・ビューによって、Oracle Streamsの取得プロセスおよび適用プロセスによって処理中の長時間実行トランザクションを監視できます。

- DBA_APPLY_SPILL_TXNおよびV$STREAMS_APPLY_READERビューによって、適用プロセスでオーバーフローしたトランザクションおよびメッセージの数を監視できます。

注意:
V$STREAMS_TRANSACTIONビューは、同期取得には関連していません。

関連項目:
アラート・ログ内のOracle Streamsの情報の詳細は、『Oracle Streams概要および管理』を参照してください。

データベースでOracle Streams構成を削除するベスト・プラクティスへの準拠

データベースでOracle Streams構成を完全に削除するには、次の手順を実行します。

1. SQL*Plusで、管理ユーザーとしてデータベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

2. DBMS_STREAMS_ADM.REMOVE_STREAMS_CONFIGURATIONプロシージャを実行します。

3. 可能な場合は、Oracle Streams管理者を削除します。

Oracle Real Application ClustersおよびOracle Streamsのベスト・プラクティス

次のベスト・プラクティスは、Oracle Streamsレプリケーション環境のOracle Real Application Clusters(Oracle RAC)データベース用です。

- すべてのスレッドのアーカイブ・ログ・ファイルの取得プロセスでの使用可能化

- Oracle RACデータベースのグローバル名のベスト・プラクティスへの準拠

- 伝播を構成および管理するベスト・プラクティスへの準拠

- キュー所有権のベスト・プラクティスへの準拠

関連項目:
Oracle StreamsがOracle RACと動作する方法の詳細は、『Oracle Streams概要および管理』を参照してください。

すべてのスレッドのアーカイブ・ログ・ファイルの取得プロセスでの使用可能化

すべてのインスタンスからのすべてのスレッドのアーカイブ・ログ・ファイルは、取得プロセスを実行するすべてのインスタンスで使用可能である必要があります。この要件は、ローカルおよびダウンストリーム取得プロセスの両方に関連します。

Oracle RACデータベースのグローバル名のベスト・プラクティスへの準拠

「Oracle Streamsデータベースのグローバル名のベスト・プラクティスへの準拠」で説明されている一般的なベスト・プラクティスは、Oracle Streams環境内のOracle Real Application Clusters(Oracle RAC)データベースにも適用します。また、Oracle RAC宛先データベースのグローバル名が、データベースのDB_NAME.DB_DOMAIN に一致しない場合、SERVICE_NAMES初期化パラメータによって指定されたデータベースのサービスのリストにデータベースのグローバル名が含まれます。

tnsnames.oraファイルで、接続記述子のCONNECT_DATA句では、SERVICE_NAMEに宛先データベースのグローバル名を指定することを確認します。また、CONNECT_DATA句には、INSTANCE_NAMEパラメータを含まないことを確認します。

Oracle Streams伝播を含むOracle RACデータベースのグローバル名を変更する場合、すべての伝播を削除して再作成します。作成時にqueue_to_queueパラメータをTRUEに設定して、新しい伝播がキュー・ツー・キュー伝播であることを確認します。

Oracle RAC宛先データベースのグローバル名を変更する必要がある場合、グローバル名を変更する前に、各適用プロセスによって使用されるキューが空で、適用されていないトランザクションが存在しないことを確認します。グローバル名を変更した後、各適用プロセスのキューおよび各適用プロセスを削除して再作成します。

関連項目:
tnsnames.oraファイルのSERVICE_NAMEパラメータの詳細は、「キュー所有権のベスト・プラクティスへの準拠」を参照してください。

伝播を構成および管理するベスト・プラクティスへの準拠

「故障した伝播の再起動」で説明する一般的なベスト・プラクティスは、Oracle Streams環境のOracle Real Application Clusters(Oracle RAC)データベースにも適用します。伝播を起動および停止するには、DBMS_PROPAGATION_ADMパッケージのプロシージャSTART_PROPAGATIONおよびSTOP_PROPAGATIONを使用します。これらのプロシージャでは、自動的にキュー・ツー・キュー伝播を処理します。

また、Oracle RACデータベースでは、サービスは各バッファ・キューに対して作成されます。常に、このサービスは、宛先キューの所有者のインスタンス上で動作し、インスタンス起動、インスタンス停止などを含むキュー所有権の切り替え時にこのキューの所有権に従います。このサービスは、キュー・ツー・キュー伝播によって使用されます。キュー・ツー・キュー伝播のサービス名を判断するには、DBA_SERVICESデータ・ディクショナリ・ビューのNETWORK_NAME列を問い合せます。Oracle RACインスタンスを実行しており、Oracle Database 10g リリース2より前に作成されたキューを所有している場合、自動サービス生成およびキュー・ツー・キュー伝播を利用するには、これらのキューを削除して再作成します。これらのキューが空で、新しいメッセージがこれらのキューにエンキューされていない場合は、これらのキューを再作成することを確認します。

関連項目:
「キュー・ツー・キュー伝播の使用」

キュー所有権のベスト・プラクティスへの準拠

すべてのOracle Streams処理は、Oracle Streamsクライアントによって使用されるキューの所有するインスタンスで行われます。データベース内の各ANYDATAキューの所有するインスタンスを判断するには、次の問合せを実行します。

SELECT q.OWNER, q.NAME, t.QUEUE_TABLE, t.OWNER_INSTANCE
FROM DBA_QUEUES q, DBA_QUEUE_TABLES t
WHERE t.OBJECT_TYPE = 'SYS.ANYDATA' AND
q.QUEUE_TABLE = t.QUEUE_TABLE AND
q.OWNER = t.OWNER;

Oracle StreamsがOracle Real Application Clusters(Oracle RAC)環境で構成されている場合、各キュー表には所有するインスタンスがあります。また、各キュー表内のすべてのキューは、同じインスタンスによって所有されます。次のOracle Streamsクライアントでは、作業の実行に、関連するキューの所有するインスタンスを使用します。

- 各取得プロセスは、そのキューの所有するインスタンスで実行されます。

- 各伝播は、伝播のソース・キューの所有するインスタンスで実行されます。

- 各伝播は、伝播の宛先キューの所有するインスタンスに接続する必要があります。

- 各適用プロセスは、そのキューの所有するインスタンスで実行されます。

DBMS_AQADM.ALTER_QUEUE_TABLEプロシージャを実行して、primary_instanceおよびsecondary_instanceパラメータを設定すると、インスタンスが使用可能である場合は、特定のインスタンス上に存在するようにキューの所有権を構成できます。キュー表のプライマリ・インスタンスを特定のインスタンスに設定すると、インスタンスが動作しているときは、常に、キューの所有権は指定されたインスタンスに戻ります。

取得プロセスおよび適用プロセスは、自動的にキューの所有権に従います。プロセスの動作中に所有権が変わる場合、プロセスは現在のインスタンス上で停止し、新しい所有者のインスタンス上で再起動します。

キュー・ツー・キュー伝播は、宛先キューとして識別された特定のキューにのみメッセージを送信します。また、宛先データベースの接続記述子のソース・データベース・リンクでは、宛先データベースに接続する適切なサービスを指定する必要があります。接続記述子のCONNECT_DATA句では、SERVICE_NAMEに宛先データベースのグローバル名を指定する必要があります。

たとえば、グローバル名がdb.mycompany.comであるデータベースのtnsnames.oraファイルを検討します。最初のインスタンスの別名はdb1で、2番目のインスタンスの別名はdb2であると想定します。このデータベースのtnsnames.oraファイルには、次のエントリが含まれる場合があります。

db.mycompany.com=
(description=
(load_balance=on)
(address=(protocol=tcp)(host=node1-vip)(port=1521))
(address=(protocol=tcp)(host=node2-vip)(port=1521))
(connect_data=
(service_name=db.mycompany.com)))

db1.mycompany.com=
(description=
(address=(protocol=tcp)(host=node1-vip)(port=1521))
(connect_data=
(service_name=db.mycompany.com)
(instance_name=db1)))

db2.mycompany.com=
(description=
(address=(protocol=tcp)(host=node2-vip)(port=1521))
(connect_data=
(service_name=db.mycompany.com)
(instance_name=db2)))

16 取得のベスト・プラクティス

この章では、Oracle Streamsレプリケーション環境の取得プロセスまたは同期取得を使用して変更を取得するベスト・プラクティスについて説明します。この章の内容は次のとおりです。

- 取得プロセスの構成のベスト・プラクティス

- 取得プロセスの操作のベスト・プラクティス

- 同期取得の構成のベスト・プラクティス

関連項目:

- 「Oracle Real Application ClustersおよびOracle Streamsのベスト・プラクティス」

- Oracle Streams取得プロセスを準備する場合のベスト・プラクティスについては、第1章「Oracle Streamsレプリケーションの準備」を参照してください。

取得プロセスの構成のベスト・プラクティス

ここでは、取得プロセスを構成するベスト・プラクティスについて説明します。

- 取得ユーザーへの必要な権限の付与

- 取得プロセスの並列性の設定

- チェックポイント保存時間の設定

取得ユーザーへの必要な権限の付与

取得ユーザーは、取得プロセスがそのルール・セットを満たす変更を取得し、取得プロセスのルール用に構成されたカスタム・ルールベースの変換を実行するセキュリティ・ドメイン内のユーザーです。

取得プロセスを作成すると、取得プロセスの取得ユーザーが構成され、取得プロセスを変更すると、取得ユーザーを変更できます。適用ユーザーに次の権限を付与します。

- 取得プロセスによって使用されるルール・セットに対するEXECUTE権限

- ポジティブ・ルール・セットで使用されるすべてのルールベースの変換ファンクションに対するEXECUTE権限

これらの権限は、取得ユーザーに直接付与することも、ロールを介して付与することもできます。

また、取得ユーザーには、取得プロセスによって実行されるルールベースの変換で起動されるすべてのパッケージ(オラクル社が提供するパッケージを含む)に対するEXECUTE権限が付与されている必要があります。これらの権限は、取得ユーザーに直接付与する必要があります。ロールを介して付与することはできません。

関連項目:

- 権限の付与の概要は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

- ルール・セットに対する権限の付与の詳細は、『Oracle Streams概要および管理』を参照してください。

取得プロセスの並列性の設定

各取得プロセスの並列性を設定するには、DBMS_CAPTURE_ADM.SET_PARAMETERプロシージャのparallelismパラメータを指定します。parallelismパラメータによって、変更のためにREDOログを同時にマイニングするプロセスの数を制御します。

parallelism取得プロセス・パラメータのデフォルト設定は1で、デフォルトのparallelismの設定は、ほとんどの取得プロセスの構成に適しています。parallelism取得プロセス・パラメータを設定する際に、PROCESSES初期化パラメータが適切に設定されていることを確認します。

関連項目:

- 『Oracle Streams概要および管理』

- 『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』

チェックポイント保存時間の設定

各取得プロセスのチェックポイント保存時間を設定します。再起動をより迅速に行うために、取得プロセスは定期的にチェックポイントを取得します。デフォルトではこれらのチェックポイントは、SYSAUX表領域でメンテナンスされます。取得プロセスのチェックポイント保存時間は、保存するチェックポイント・データの量を制御します。チェックポイント保存時間では、チェックポイントを保存するのに必要なチェックポイントSCNより前の日数を指定します。チェックポイントが指定された期間よりも古い場合は、取得プロセスがチェックポイントを消去します。

チェックポイントが消去されると、取得プロセスの先頭SCNが前に移動し、Oracle Databaseによってアラート・ログに「先頭SCNが変更されました」というテキストを含むメッセージが書き込まれます。先頭SCNとは、変更を取得するのに使用可能な最小SCNです。取得プロセスを作成すると、チェックポイント保存時間が設定され、取得プロセスを変更すると、チェックポイント保存時間を設定できます。チェックポイント保存時間を超えると、先頭SCNが前に移動し、この新しい先頭SCNより前のOracle Streamsメタデータ表が消去されます。SYSAUX表領域のこれらの表によって使用される領域が再利用されます。取得プロセスのチェックポイント保存時間を変更するには、DBMS_CAPTURE_ADMパッケージのALTER_CAPTUREプロシージャを使用し、checkpoint_retention_timeパラメータを使用して新しい保存時間を指定します。

チェックポイント保存時間のデフォルト値は、60日です。チェックポイントが過去の時間に使用できる場合、取得プロセスによって宛先データベースをリカバリするために変更を再取得できます。環境の適切な値にチェックポイント保存時間を設定する必要があります。一般的な設定は7日間です。

関連項目:

- 『Oracle Streams概要および管理』

- ALTER_CAPTUREプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

取得プロセスの操作のベスト・プラクティス

ここでは、既存の取得プロセスを操作するベスト・プラクティスについて説明します。

- Oracle Streams環境内の各ソース・データベースでのハートビート表の構成

- 定期的なディクショナリ構築およびインスタンス化のためのデータベース・オブジェクトの定期的な準備

- バッチ処理のパフォーマンスへの影響の最小化

Oracle Streams環境内の各ソース・データベースでのハートビート表の構成

ハートビート表を使用して、Oracle Streamsレプリケーション環境内に変更がレプリケートされているかを確認できます。特に、取得データベースが定期的に更新されているかを確認するために、取得データベースでDBA_CAPTUREデータ・ディクショナリ・ビューのAPPLIED_SCN値を確認できます。たとえレプリケートされた変更が少なくても、レプリケーション環境が適切に動作していることを確認できるため、アクティビティ・レートが低いデータベースにハートビート表は、特に有効です。

Oracle Streams取得プロセスは、10MBのREDOが生成されるごとにチェックポイントを要求します。アクティブなトランザクションがある場合、チェックポイント中にOracle Streamsのメタデータがメンテナンスされます。ハートビート表を実装すると、メタデータが頻繁に更新される機会が追加され、ソース・データベースで定期的に発生するオープン・トランザクションが存在することを確認できます。さらに、ハートビート表によってOracle Streamsレプリケーション環境の状態に関して迅速なフィードバックがデータベース管理者に提供されます。

ハートビート表を実装するには、次の手順を実行します。

1. 日付列またはタイムスタンプ列およびソース・データベースのグローバル名を含むソース・データベースで表を作成します。

2. 宛先データベースで表をインスタンス化します。複数の宛先データベースが存在する場合、各宛先データベースでハートビート表をインスタンス化します。

3. ソース・データベースに対する変更を取得する取得プロセスのポジティブ・ルール・セットにルールを追加します。ルールは、取得プロセスに対し、ハートビート表に対する変更を取得するように指示します。

4. ソース・データベースから宛先データベースに変更を伝播する伝播のポジティブ・ルール・セットにルールを追加します。ルールは、伝播に対し、ハートビート表のLCRを伝播するように指示します。複数の伝播が存在する場合、各伝播のルール・セットにルールを追加します。環境で有向ネットワークを使用する場合、いくつかのデータベースで伝播にルールを追加する必要があります。

5. ソース・データベースで発生した変更を適用する適用プロセスのポジティブ・ルール・セットにルールを追加します。ルールは、適用プロセスに対し、ハートビート表に対する変更を適用するように指示します。ソース・データベースで発生した変更を適用する複数のデータベースで複数の適用プロセスが存在する場合、各適用プロセスにルールを追加します。

6. ソース・データベースでハートビート表が定期的に更新されるように自動化ジョブを構成します。たとえば、表は1分ごとに更新されます。

7. ソース・データベースでのハートビート表に対する変更が宛先データベースにレプリケートされていることを確認するために、Oracle Streamsレプリケーション環境を監視します。

定期的なディクショナリ構築およびインスタンス化のためのデータベース・オブジェクトの定期的な準備

ソース・データベースのREDOログで、定期的にデータ・ディクショナリの構築を実行します。REDOログ内のデータ・ディクショナリの現行のコピーを構築するには、DBMS_CAPTURE_ADM.BUILDプロシージャを実行します。理想的には、構築が実行された後にデータベース・オブジェクトがインスタンス化のために準備される必要があります。データベース・オブジェクトをインスタンス化のために準備するには、DBMS_CAPTURE_ADMパッケージの1つ以上の次のプロシージャを実行します。

- PREPARE_GLOBAL_INSTANTIATION

- PREPARE_SCHEMA_INSTANTIATION

- PREPARE_TABLE_INSTANTIATION

取得プロセスが変更を取得する各データベース・オブジェクトは、インスタンス化のために定期的に準備される必要があります。追加の取得プロセスが作成される場合、または構築を実行してインスタンス化のために共有オブジェクトを定期的に準備することによって既存の取得プロセスを再作成する必要がある場合に、処理する必要があるREDOデータの量を減らせます。

関連項目:

- 『Oracle Streams概要および管理』

- 「取得のルールとインスタンス化の準備」

バッチ処理のパフォーマンスへの影響の最小化

パフォーマンスを最適化するために、バッチ処理ジョブのコミット・ポイントを小さくする必要があります。また、ソース・データベースで大きなバッチ処理ジョブを実行する必要がある場合は、各Oracle Streamsレプリケーション・データベースで独立して実行することを検討します。この技術を使用する場合、バッチ処理ジョブから生じる変更がレプリケートされないことを確認します。これを行うには、バッチ処理ジョブを実行するセッションでDBMS_STREAMS.SET_TAGプロシージャを実行し、取得プロセスによって取得されない値にセッション・タグを設定します。

関連項目:
第10章「Oracle Streamsタグ」

同期取得の構成のベスト・プラクティス

DBMS_STREAMS_ADMパッケージを使用すると、同期取得の作成および管理が簡単になります。具体的には、同期取得の作成および同期取得のルールの構成を行う場合は、DBMS_STREAMS_ADMパッケージの次のプロシージャを使用します。

- ADD_TABLE_RULES

- ADD_SUBSET_RULES

また、同期取得のルール・セットからルールを削除する場合は、DBMS_STREAMS_ADMパッケージのREMOVE_RULEプロシージャを使用します。

関連項目:
「同期取得の構成」

17 伝播のベスト・プラクティス

この章では、Oracle Streamsレプリケーション環境でメッセージを伝播するベスト・プラクティスについて説明します。この章の内容は次のとおりです。

- 伝播の構成のベスト・プラクティス

- 伝播の操作のベスト・プラクティス

関連項目:
「Oracle Real Application ClustersおよびOracle Streamsのベスト・プラクティス」

伝播の構成のベスト・プラクティス

ここでは、伝播を構成するベスト・プラクティスについて説明します。

- キュー・ツー・キュー伝播の使用

- 各伝播の伝播待機時間の設定

- ネットワーク・パフォーマンス向上のためのWide Area NetworkにおけるSDUの増加

キュー・ツー・キュー伝播の使用

伝播は、キュー・ツー・キューまたはキュー・ツー・データベース・リンク(キュー・ツーdblink)です。可能な場合は、キュー・ツー・キュー伝播を使用します。キュー・ツー・キュー伝播は、常に、ソース・キューから接続先キューにメッセージを伝播する独自の排他伝播ジョブを所有しています。各伝播ジョブには独自の伝播スケジュールがあるため、各キュー・ツー・キュー伝播の伝播スケジュールは個別に管理できます。複数のキュー・ツー・キュー伝播が同じデータベース・リンクを使用する場合でも、各キュー・ツー・キュー伝播に対して伝播スケジュールを個別に有効化、無効化または設定することができます。

Oracle Database 10gリリース2よりも前に構成された伝播は、キュー・ツーdblink伝播です。また、Oracle Database 10gリリース2よりも前のデータベース内のキューを含むすべての伝播は、キュー・ツーdblink伝播である必要があります。キュー・ツーdblink伝播が使用されると、データベース・リンクが宛先キューの所有するインスタンスに接続しない場合、伝播は成功しません。

Oracle Databaseの以前のリリースで作成されたキュー・ツーdblink伝播を所有する場合、キュー・ツー・キュー伝播を使用するには、メンテナンス・ウィンドウでこれらの伝播を再作成できます。伝播を再作成するには、次の手順を実行します。

1. 伝播を停止します。

2. ソース・キューが空であることを確認します。

3. 伝播を削除する前に、宛先キューが空で、未適用のオーバーフローしたメッセージがないことを確認します。

4. 作成プロシージャのqueue_to_queueパラメータをTRUEに設定して伝播を再作成します。

「Oracle Streamsレプリケーション構成の自動化」の説明に従って構成を自動化すると、各伝播でキュー・ツー・キュー伝播が自動的に使用されるようになります。

関連項目:

- Oracle Real Application Clusters(Oracle RAC)環境の伝播の詳細は、「伝播を構成および管理するベスト・プラクティスへの準拠」を参照してください。

- 「ANYDATAキュー間のOracle Streamsの伝播の作成」

各伝播の伝播待機時間の設定

伝播待機時間は、メッセージがエンキューされてから伝播されるまでの伝播期間における最大待機時間(秒単位)です。伝播待機時間を、Oracle Streamsレプリケーション環境内の各伝播に対する適切な値に設定します。デフォルトの伝播待機時間の値は60です。

次の例では、指定された、異なる伝播待機時間の値に対する伝播の動作について説明します。

- 待機時間を60に設定し、伝播期間中にエンキューされたメッセージがない場合、メッセージが特定の宛先に伝播される60秒間、キューはチェックされません。つまり、伝播宛先のキューにエンキューされたメッセージは、60秒間以上は伝播されません。

- 待機時間を600に設定し、伝播期間中にエンキューされたメッセージがない場合、メッセージが特定の宛先に伝播される10分間、キューはチェックされません。つまり、伝播宛先に対するキューにエンキューされたメッセージは、10分間以上は伝播されません。

- 待機時間を0に設定した場合、ジョブ・スレーブは、メッセージが宛先に対してエンキューされるまで待機しており、メッセージがエンキューされると、すぐに伝播されます。NORMALモードで停止するデータベースの機能に影響する場合があるため、待機時間を0に設定することはお薦めしません。

DBMS_AQADMパッケージからのALTER_PROPAGATION_SCHEDULEプロシージャを使用して伝播パラメータを設定できます。たとえば、strmadminが所有するq1ソース・キューからグローバル名がdbs2.example.comであるデータベースの宛先キューq2への伝播の待機時間を設定するには、Oracle Streams管理者としてログインし、次のプロシージャを実行します。

BEGIN
DBMS_AQADM.ALTER_PROPAGATION_SCHEDULE(
queue_name        => 'strmadmin.q1',
destination       => 'dbs2.example.com',
latency           => 5,
destination_queue => 'strmadmin.q2');
END;
/

注意:
latencyパラメータを設定しない場合、伝播待機時間はデフォルト値60に設定されます。

関連項目:
『Oracle Streams概要および管理』

ネットワーク・パフォーマンス向上のためのWide Area NetworkにおけるSDUの増加

Wide Area Network(WAN)でOracle Streams伝播を使用する際に、伝播パフォーマンスを向上するためにセッション・データ・ユニット(SDU)を増加します。SDUの最大値は、32K(32767)です。ネットワーク転送のSDU値は、接続の送信側と受信側で折衝し、2つのエンドポイントの最小SDU値がすべての個々の接続に対して使用されます。Oracle Streams伝播の増加したSDUを利用するには、受信側のsqlnet.oraファイルにDEFAULT_SDU_SIZEパラメータが含まれる必要があります。受信側のlistener.oraファイルでは、システム識別子(SID)に対してSDUの変更を示す必要があります。また、送信側のtnsnames.oraファイルの接続文字列には、特定のサービスに対するSDUの変更が含まれる必要があります。

また、listener.oraおよびtnsnames.oraファイルのSEND_BUF_SIZEおよびRECV_BUF_SIZEパラメータによって、システム上の伝播のパフォーマンスが向上します。これらのパラメータによって、伝播されたメッセージを送信または受信するために使用するバッファのサイズが増加します。これらのパラメータは、システム・パフォーマンスに対する全体の影響を注意深く分析してから増やす必要があります。

関連項目:
『Oracle Database Net Services管理者ガイド』

伝播の操作のベスト・プラクティス

ここでは、既存の伝播を操作するベスト・プラクティスについて説明します。

故障した伝播の再起動

伝播の伝播ジョブは、エラーの発生後またはデータベースの再起動後に「故障」になったり、起動に失敗する場合があります。通常、伝播を停止して再起動すると、問題は解決されます。たとえば、prop1という伝播を停止して再起動するには、次の手順を実行します。

BEGIN
DBMS_PROPAGATION_ADM.STOP_PROPAGATION(
propagation_name => 'prop1');
END;
/

BEGIN
DBMS_PROPAGATION_ADM.START_PROPAGATION(
propagation_name => 'prop1');
END;
/

これらの手順を実行しても問題が解決されない場合は、forceパラメータをTRUEに設定して、STOP_PROPAGATIONプロシージャを実行して、伝播を再起動します。次に例を示します。

BEGIN
DBMS_PROPAGATION_ADM.STOP_PROPAGATION(
propagation_name => 'prop1',
force            => TRUE);
END;
/

BEGIN
DBMS_PROPAGATION_ADM.START_PROPAGATION(
propagation_name => 'prop1');
END;
/

forceパラメータをTRUEに設定して伝播を停止すると、伝播の統計が消去されます。

18 適用のベスト・プラクティス

この章では、Oracle Streamsレプリケーション環境の適用プロセスを使用して変更を適用するベスト・プラクティスについて説明します。この章の内容は次のとおりです。

- 宛先データベース構成のベスト・プラクティス

- 適用プロセスの構成のベスト・プラクティス

- 適用プロセスの操作のベスト・プラクティス

関連項目:
「Oracle Real Application ClustersおよびOracle Streamsのベスト・プラクティス」

宛先データベース構成のベスト・プラクティス

Oracle Streamsレプリケーション環境では、宛先データベースは、適用プロセスが変更を適用するデータベースです。この項の内容は次のとおりです。

- 適用ユーザーへの必要な権限の付与

- インスタンス化SCNの値の設定

- 競合解消の構成

適用ユーザーへの必要な権限の付与

適用ユーザーは、適用プロセスが次のアクションを実行するセキュリティ・ドメイン内のユーザーです。

- ルール・セットを満たすメッセージのデキュー

- 適用プロセスのルール用に構成されたカスタム・ルールベースの変換の実行

- メッセージのデータベース・オブジェクトへの直接適用

- 適用プロセス用に構成された適用ハンドラの実行

適用プロセスを作成すると、適用プロセスの適用ユーザーが構成され、適用プロセスを変更すると、適用ユーザーを変更できます。適用ユーザーに次の権限を付与します。

- 適用プロセスがデータ操作言語(DML)の変更を表に適用する場合、表に対するINSERT、UPDATEおよびDELETE権限を適用ユーザーに付与します。

- 適用プロセスがデータ定義言語(DDL)の変更を表に適用する場合、CREATE TABLEまたはCREATE ANY TABLE、CREAT INDEXまたはCREATE ANY INDEX、CREATE PROCEDUREまたはCREATE ANY PROCEDUREを適用ユーザーに付与します。

- 適用プロセスによって使用されるルール・セットに対してEXECUTE権限を付与します。

- 適用プロセスのポジティブ・ルール・セット内のルールに指定されたすべてのカスタム・ルールベースの変換ファンクションに対してEXECUTE権限を付与します。

- 適用プロセスによって使用されるすべての適用ハンドラに対してEXECUTE権限を付与します。

- 適用プロセスのキューからメッセージをデキューする権限を付与します。

これらの権限は、適用ユーザーに直接付与することも、ロールを介して付与することもできます。

また、適用ユーザーには、適用プロセスによって実行されるサブプログラムで起動されるすべてのパッケージ(オラクル社が提供するパッケージを含む)に対するEXECUTE権限が付与されている必要があります。これらの権限は、適用ユーザーに直接付与する必要があります。ロールを介して付与することはできません。

関連項目:

- 権限の付与の概要は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

- ルール・セットに対する権限の付与の詳細は、『Oracle Streams概要および管理』を参照してください。

インスタンス化SCNの値の設定

インスタンス化SCNの値は、適用プロセスが変更を適用する各データベース・オブジェクトに対して設定する必要があります。すべてのそのようなオブジェクトに対してインスタンス化SCNが設定されていることを確認し、未設定のすべての必要なインスタンス化SCNの値を設定します。

インスタンス化SCNの値は、エクスポート/インポート、Recovery Manager(RMAN)、手動などの様々な方法で設定できます。インスタンス化SCNの値を手動で設定するには、DBMS_APPLY_ADMパッケージの次のいずれかのプロシージャを使用します。

- SET_TABLE_INSTANTIATION_SCN

- SET_SCHEMA_INSTANTIATION_SCN

- SET_GLOBAL_INSTANTIATION_SCN

たとえば、スキーマ内の各表に対して手動でインスタンス化SCNを設定するには、recursiveパラメータをTRUEに設定して、SET_SCHEMA_INSTANTIATION_SCNプロシージャを実行します。適用プロセスがデータ定義言語(DDL)変更を適用する場合、SET_SCHEMA_INSTANTIATION_SCNまたはSET_GLOBAL_INSTANTIATION_SCNプロシージャのいずれかを使用して表レベルより高いレベルでインスタンス化SCNの値を設定します。

関連項目:
インスタンス化およびインスタンス化SCNの値の設定の詳細は、第8章「インスタンス化とOracle Streamsレプリケーション」を参照してください。

競合解消の構成

更新が複数のデータベースで同じ共有データベース・オブジェクトに対して実行される場合、そのオブジェクトの競合解消を構成されていることを確認します。LOB列を含む表の競合解消を簡素化するには、表のエラーを処理するエラー・ハンドラを作成します。DBMS_APPLY_ADM.SET_DML_HANDLERプロシージャを使用してエラー・ハンドラを登録するときに、assemble_lobsパラメータをTRUEに設定していることを確認します。

宛先データベースで競合解消を構成する場合、ソース・データベースで追加のサプリメンタル・ロギングが必要です。特に、ソース・データベースの複数の列が宛先データベースの列リストに使用されている場合、適用時に競合解消用の列リストで指定された列は、条件付きでログに記録する必要があります。

関連項目:

- 第9章「Oracle Streamsの競合解消」

- 「サプリメンタル・ロギングの指定」

適用プロセスの構成のベスト・プラクティス

ここでは、適用プロセスを構成するベスト・プラクティスについて説明します。

- 適用プロセスの並列性の設定

- エラー発生時の適用プロセスの続行の検討

適用プロセスの並列性の設定

適用プロセスの並列性を設定するには、DBMS_APPLY_ADM.SET_PARAMETERプロシージャのparallelismパラメータを指定します。parallelismパラメータによって、変更を同時に適用するプロセスの数を制御します。parallelism適用プロセス・パラメータのデフォルト設定は、4です。

通常、適用プロセスの並列性は、1、4、8または16のいずれかに設定されます。特定の適用プロセスに最適な設定は、適用されるロードおよびデータベースを実行するコンピュータ・システムの処理能力に依存します。適用プロセスの並列性を設定する際は、次のガイドラインに従ってください。

- 適用プロセスのロードが高く、データベースを実行するコンピュータ・システムの処理能力が高い場合は、適用プロセスの並列性を8または16に設定します。複数の高速CPUによって、高い処理能力が提供されます。

- 適用プロセスのロードが低い場合は、適用プロセスの並列性を1または4に設定します。

- データベースを実行するコンピュータ・システムの処理能力が最適な処理能力よりも低い場合は、適用プロセスの並列性を1または4に設定します。

parallelism適用プロセス・パラメータを設定する際に、PROCESSES初期化パラメータが適切に設定されていることを確認します。

また、適用プロセスの並列性が1より大きい場合に、適用プロセスによって変更が適用されるすべてのデータベース・オブジェクトにINITRANSおよびPCTFREEパラメータが適切に設定されていることを確認します。INITRANSパラメータでは、データベース・オブジェクトに割り当てられた各データ・ブロック内で割当て済のトランザクション・エントリの初期の数を指定します。INITRANSパラメータを適用プロセス以上の並列性に設定します。PCTFREEパラメータでは、オブジェクトの列への将来の更新のために予約されたデータベース・オブジェクトの各データ・ブロック内の領域の割合を指定します。PCTFREEパラメータは、10以上に設定する必要があります。ALTER TABLE文を使用して表のこれらのパラメータを変更できます。

関連項目:

- 『Oracle Streams概要および管理』

- 『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』

- ALTER TABLE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

エラー発生時の適用プロセスの続行の検討

disable_on_error適用プロセス・パラメータをYに設定すると、たとえエラーがリカバリ不能でなくても、適用プロセスは最初の未解決のエラーに対して無効化されます。disable_on_error適用プロセス・パラメータをNに設定すると、未解決のエラーにかかわらず適用プロセスは続行します。このパラメータのデフォルトの設定はYです。エラーが発生しても適用プロセスが無効化されないようにするには、disable_on_errorパラメータをNに設定します。

適用プロセスの操作のベスト・プラクティス

ここでは、既存の適用プロセスを操作するベスト・プラクティスについて説明します。

適用エラーの管理

エラー・キューには、データベースのすべての現行の適用エラーが含まれます。データベースに複数の適用プロセスが存在する場合、エラー・キューには各適用プロセスの適用エラーが含まれます。適用プロセスがトランザクション内の論理変更レコード(LCR)を適用しようとする際にエラーが発生する場合、トランザクション内のすべてのLCRは、エラー・キューに移動されます。適用エラーの情報を表示するには、DBA_APPLY_ERRORデータ・ディクショナリ・ビューを問い合せるか、またはEnterprise Managerを使用します。

DBA_APPLY_ERRORビューのMESSAGE_NUMBER列は、エラーが発生したトランザクション内のLCRを示します。適用エラーが発生した場合、エラーの原因となった問題を訂正し、エラー・キュー内のエラー・トランザクションを再試行するか、または削除します。

関連項目:
適用エラーの管理およびエラー・トランザクション内の各LCRの列値の詳細情報の表示の詳細は、『Oracle Streams概要および管理』を参照してください。

第IV部

付録

この部の構成は、次のとおりです。

- 付録A「Oracle Streamsへのアドバンスト・レプリケーションの移行」

A Oracle Streamsへのアドバンスト・レプリケーションの移行

アドバンスト・レプリケーションを使用して異なるサイト間でレプリケートされたデータベース・オブジェクトをメンテナンスしているデータベース管理者は、アドバンスト・レプリケーション環境をOracle Streams環境に移行できます。この付録では、このプロセスでの手順の概要を示し、各手順についてプロシージャと例を示して説明します。

この章の内容は次のとおりです。

- 移行プロセスの概要

- 移行スクリプトの生成の準備

- 移行スクリプトの生成と変更

- Oracle Streamsへのアドバンスト・レプリケーションの移行の実行

- マテリアライズド・ビュー・グループを保持するマスター・サイトの再作成

- Oracle Streams移行スクリプトに移行するアドバンスト・レプリケーションの例

関連項目:
アドバンスト・レプリケーションの詳細は、『Oracle Databaseアドバンスト・レプリケーション』および『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

移行プロセスの概要

ここでは、移行プロセスの概要を説明します。

- 移行スクリプトの生成と使用

- 移行スクリプトの変更

- 生成されたスクリプトによって実行されるアクション

- 移行スクリプトのエラー

- 更新可能なマテリアライズド・ビューの手動移行

- Oracle Streamsに移行できないアドバンスト・レプリケーション要素

移行スクリプトの生成と使用

DBMS_REPCAT.STREAMS_MIGRATIONプロシージャを使用すると、既存のアドバンスト・レプリケーション環境をOracle Streams環境に移行するSQL*Plusスクリプトを生成できます。マルチマスター・レプリケーション環境のマスター定義サイトでDBMS_REPCAT.STREAMS_MIGRATIONプロシージャを実行すると、指定した場所のファイルにSQL*Plusスクリプトが生成されます。スクリプトが生成された後、アドバンスト・レプリケーション環境の各マスター・サイトでそれを実行し、マスター・サイトごとにOracle Streams環境を設定します。レプリケーション・グループのOracle Streams環境を正常に生成するには、スクリプトの実行対象となるレプリケーション・グループに同じマスター・サイトが含まれている必要があります。レプリケーション・グループに異なるマスター・サイトが存在する場合、複数のスクリプトを生成して、各レプリケーション・グループをOracle Streamsに移行できます。

特定の管理タスクを実行するために、レプリケーション・グループのすべてのレプリケーション・アクティビティを停止または静止する必要がある場合があります。DBMS_REPCAT.STREAMS_MIGRATIONプロシージャを実行する場合は、レプリケーション・グループを静止する必要はありません。ただし、マスター・サイトで生成されたスクリプトを実行する場合は、Oracle Streamsに移行するレプリケーション・グループを静止する必要があります。レプリケーション・グループを静止してからマスター・サイトでスクリプトを実行するため、これらのサイトで既存の取得プロセス、伝播ジョブまたは適用プロセスを停止する必要はありません。

移行スクリプトの変更

生成された移行スクリプトでは、コメントを使用して、Oracle Streamsに変換できないアドバンスト・レプリケーション要素が示されます。また、これらの要素をOracle Streamsに変換するためのスクリプトの変更に関する推奨事項も示されます。この推奨事項に基づいて、実行前にスクリプトを編集できます。必要に応じて、移行スクリプトを別の方法でカスタマイズすることもできます。

このスクリプトは、PL/SQLプロシージャおよびファンクションを実行する際、すべてのパラメータを設定します。スクリプトを生成すると、パラメータにデフォルト値が設定され、通常、これらのデフォルト値を変更する必要はありません。ただし、必要に応じてスクリプトを編集することで、これらのデフォルト・パラメータを変更できます。デフォルトに設定されるパラメータは、次のとおりです。

- include_dml

- include_ddl

- include_tagged_lcr

スクリプトの先頭には、スクリプト内のプロシージャとファンクションが使用する名前の変数のリストが含まれます。スクリプトを生成すると、これらの変数はデフォルト値に設定され、これらの値を変更する必要はありません。ただし、必要に応じてこれらの変数のデフォルト設定を変更することができます。変数では、キュー、取得プロセス、伝播および適用プロセスの名前が指定されます。

生成されたスクリプトによって実行されるアクション

移行スクリプトを実行すると、次のアクションが実行されます。

- レプリケーション・グループにOracle Streamsに変換できない機能が含まれている場合、コメント内に警告が出力されます。

- 必要に応じて、DBMS_STREAMS_ADM.SET_UP_QUEUEプロシージャを使用してANYDATAキューが作成されます。

- 各表にDBMS_STREAMS_ADMIN.ADD_TABLE_PROPAGATION_RULESプロシージャを使用して、すべてのマスター・サイト間で伝播が構成されます。

- 各表にDBMS_STREAMS_ADMIN.ADD_TABLE_RULESプロシージャを使用して、各マスター・サイトで取得が構成されます。

- 各表にDBMS_STREAMS_ADMIN.ADD_TABLE_RULESプロシージャを使用して、他のすべてのマスター・サイトからの変更の適用が構成されます。

- オブジェクトに対する変更が適用される各サイトで、各レプリケート・オブジェクトのインスタンス化SCNが設定されます。

- ソース・データベースで必要なサプリメンタル・ログ・グループが作成されます。

- キー列が設定されます(存在する場合)。

- 移行するアドバンスト・レプリケーション環境に競合解消が構成されている場合は、競合解消が構成されます。

移行スクリプトのエラー

移行スクリプトの実行中にOracleにエラーが発生した場合、移行スクリプトは即時に終了します。このような状況が発生した場合、スクリプトを変更し、正常に実行されなかったすべてのコマンドを実行する必要があります。

更新可能なマテリアライズド・ビューの手動移行

移行スクリプトを使用して、更新可能なマテリアライズド・ビューを移行することはできません。アドバンスト・レプリケーション環境からOracle Streams環境への更新可能なマテリアライズド・ビューの移行は、手動で行う必要があります。

関連項目:
「マテリアライズド・ビュー・グループを保持するマスター・サイトの再作成」

Oracle Streamsに移行できないアドバンスト・レプリケーション要素

Oracle Streamsでは、次の機能はサポートされていません。

- BFILE、ROWIDデータ型、およびユーザー定義型(オブジェクト型、REF、VARRAY、ネストした表など)の列を持つ表に対する変更のレプリケーション

- 同期レプリケーション

現行のアドバンスト・レプリケーション環境でこれらの機能を使用している場合、環境のこれらの要素はOracle Streamsに移行できません。この場合、現時点ではOracle Streamsへの環境の移行を中止するか、またはOracle Streamsに移行できるように環境を変更します。

移行スクリプトの生成の準備

移行スクリプトを生成する前に、次の条件がすべて満たされていることを確認してください。

- すべてのレプリケーション・グループのマスター・サイトが同じである。

- 移行スクリプトを生成するマスター・サイトでOracle Database 10g 以上が稼働している。

- スクリプトを実行する(ただし、生成はしない)他のマスター・サイトでOracle9i データベース リリース2(9.2)以上が稼働している。

移行スクリプトの生成と変更

移行スクリプトを生成するには、DBMS_REPCATパッケージのDBMS_REPCAT.STREAMS_MIGRATIONプロシージャを使用します。このプロシージャの構文は次のとおりです。

DBMS_REPCAT.STREAMS_MIGRATION (
gnames              IN   DBMS_UTILITY.NAME_ARRAY,
file_location       IN   VARCHAR2,
filename            IN   VARCHAR2);

DBMS_REPCAT.STREAMS_MIGRATIONプロシージャには、次のパラメータがあります。

- gnames: Oracle Streamsに移行するレプリケーション・グループのリスト。リスト内のすべてのレプリケーション・グループは、同じマスター・サイトを持つ必要があります。レプリケーション・グループのマスターが異なる場合、エラーが発生します。

- file_location: 移行スクリプトのディレクトリの場所。

- filename: 移行スクリプトの名前。

このプロシージャを実行すると、特定のレプリケーション・グループに対するOracle Streams環境を設定するスクリプトが生成されます。スクリプトをカスタマイズして、各マスター・サイトでそのスクリプトを実行することもできます。

Oracle Streamsに移行するアドバンスト・レプリケーション環境の例

図A-1に、この例でOracle Streamsに移行するアドバンスト・レプリケーション環境を示します。

図A-1 Oracle Streamsに移行するアドバンスト・レプリケーション環境

このアドバンスト・レプリケーション環境には、次の特性があります。

- orc1.example.comデータベースは、orc2.example.comおよびorc3.example.comを含む3方向のマスター構成のマスター定義サイトです。

- orc1.example.comデータベースは、mv1.example.comマテリアライズド・ビュー・サイトのマスター・サイトです。

- この環境は、3つのマスター・サイト間およびマスター・サイトとマテリアライズド・ビュー・サイトの間で、hrスキーマのデータベース・オブジェクトに対する変更をレプリケートします。レプリケーション・グループhr_repgは、レプリケート・オブジェクトを含んでいます。

- マルチマスター環境のhr.countries表に、競合解消が構成されています。この表では、最新のタイムスタンプによる競合解消方法によって、競合が解消されます。

- mv1.example.comサイトのマテリアライズド・ビューは更新可能です。

このアドバンスト・レプリケーション環境を構成するには、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』の次の各操作に関する項で説明されているタスクを実行してください。

- 3つのマスター・サイトの設定

- マテリアライズド・ビュー・サイトの設定(mv1.example.comの設定のみ)

- orc1.example.comをマスター定義サイトとする3つのマスター・サイトのhr_repgマスター・グループの作成

- hr.countries表に対するタイムスタンプによる競合解消の構成

- orc1.example.comのhr_repgマスター・グループに基づく、mv1.example.comのマテリアライズド・ビュー・グループの作成

このアドバンスト・レプリケーション環境の移行スクリプトを生成するには、次の手順を実行します。

1. すべてのマスター・サイトでのOracle Streams管理者の作成

2. ディレクトリへのアクセスの許可

3. 移行スクリプトの生成

4. 生成された移行スクリプトの作成の確認とスクリプトの変更

手順1: すべてのマスター・サイトでのOracle Streams管理者の作成

次の手順を実行して、Oracle Streamsに移行するレプリケーション・グループの各マスター・サイトにOracle Streams管理者を作成します。「Oracle Streamsに移行するアドバンスト・レプリケーション環境の例」に示した環境例の場合、orc1.example.com、orc2.example.comおよびorc3.example.comでこれらの手順を実行してください。

1. ユーザーの作成、権限の付与および表領域の作成を行うことができる管理ユーザーとして接続します。

2. Oracle Streams管理者用の表領域を作成するか、既存の表領域を使用します。たとえば、次の文では、Oracle Streams管理者用の新規表領域が作成されます。

CREATE TABLESPACE streams_tbs DATAFILE '/usr/oracle/dbs/streams_tbs.dbf'
SIZE 25 M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED;

3. Oracle Streams管理者の役割を果たす新規ユーザーを作成するか、既存のユーザーを使用します。たとえば、ユーザーstrmadminを作成し、このユーザーがstreams_tbs表領域を使用するように指定するには、次の文を実行します。

CREATE USER strmadmin IDENTIFIED BY password
DEFAULT TABLESPACE streams_tbs
QUOTA UNLIMITED ON streams_tbs;

GRANT DBA TO strmadmin;

注意:

- この移行スクリプトでは、Oracle Streams管理者のユーザー名がstrmadminであると想定しています。Oracle Streams管理者がこれ以外のユーザー名を持つ場合は、移行スクリプトを編集して、すべてのインスタンスのstrmadminをOracle Streams管理者のユーザー名に置き換えてください。

- Oracle Streams管理者にDBAロールが付与されていることを確認してください。

4. 各マスター・サイトで、Oracle Streams管理者に必要な追加の権限を付与します。必要な権限は、個々のOracle Streams環境によって異なります。

関連項目:
Oracle Streams管理者に必要になる可能性がある追加権限の詳細は、「すべてのデータベースでのOracle Streams管理者の構成」を参照してください。

手順2: ディレクトリへのアクセスの許可

DBMS_REPCAT.STREAMS_MIGRATIONプロシージャのfile_locationパラメータで指定したディレクトリは、PL/SQLでアクセスできる必要があります。Oracle Streams管理者が現在アクセス可能なディレクトリ・オブジェクトがマスター定義サイトにない場合は、Oracle Streams管理者として接続し、SQL文CREATE DIRECTORYを使用してディレクトリ・オブジェクトを作成します。

ディレクトリ・オブジェクトは、ディレクトリの別名に類似しています。たとえば、コンピュータ・システムの/usr/scriptsディレクトリにディレクトリ・オブジェクトMIG2STR_DIRを作成するには、次のプロシージャを実行します。

CONNECT strmadmin@orc1.example.com
Enter password: password

CREATE DIRECTORY MIG2STR_DIR AS '/usr/scripts';

関連項目:
CREATE DIRECTORY文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

手順3: 移行スクリプトの生成

移行スクリプトを生成するには、マスター定義サイトでDBMS_REPCAT.STREAMS_MIGRATIONプロシージャを実行し、適切なパラメータを指定します。たとえば、次のプロシージャを実行すると、レプリケーション・グループhr_repgを持つアドバンスト・レプリケーション環境を移行するスクリプトが生成されます。スクリプトはrep2streams.sqlという名前で、ローカル・コンピュータ・システムの/usr/scriptsディレクトリに生成されます。このディレクトリは、ディレクトリ・オブジェクトMIG2STR_DIRで表されます。

CONNECT strmadmin@orc1.example.com
Enter password: password

DECLARE
rep_groups DBMS_UTILITY.NAME_ARRAY;
BEGIN
rep_groups(1) := 'HR_REPG';
DBMS_REPCAT.STREAMS_MIGRATION(
gnames         =>  rep_groups,
file_location  =>  'MIG2STR_DIR',
filename       =>  'rep2streams.sql');
END;
/

関連項目:
この例で生成されたスクリプトは、「Oracle Streams移行スクリプトに移行するアドバンスト・レプリケーションの例」を参照してください。

手順4: 生成された移行スクリプトの作成の確認とスクリプトの変更

移行スクリプトの生成後、指定したディレクトリを表示して、そのスクリプトが作成されたことを確認します。必要に応じて、次の機能をサポートするように変更することができます。

- 加算、平均、優先グループまたはサイトの優先順位によるアドバンスト・レプリケーション競合解消方法を使用した競合解消が環境に必要な場合、ユーザー定義の競合解消方法を構成して競合を解消します。Oracle Streamsには、これらの方法と同等の競合解消方法が組み込まれていません。
ただし、移行スクリプトでは、上書き、廃棄、最大および最小の競合解消方法が自動的にサポートされます。スクリプトは最古のタイムスタンプによる方法を最小の方法に、最新のタイムスタンプによる方法を最大の方法に自動変換します。タイムスタンプ競合解消方法を使用する場合、スクリプトでは、表のタイムスタンプ列を移入するために必要なトリガーがすでに存在するとみなされます。

- 一意性競合の解消。

- 削除の競合の解消。

- 競合が発生した場合、複数の競合解消方法を指定した順序で実行します。Oracle Streamsでは、各列リストに指定できる競合解消方法は1つのみです。

- 手続き型レプリケーション。

- 次のような、表以外のオブジェクトに対するデータ定義言語(DDL)変更のレプリケーション。

- ファンクション

- 索引

- 索引タイプ

- 演算子

- パッケージ

- パッケージ本体

- プロシージャ

- シノニム

- トリガー

- タイプ

- タイプ本体

- ビュー

これらのオブジェクトに対する変更は、アドバンスト・レプリケーションによってすべてのサイトでレプリケートされているため、移行スクリプトではこれらのオブジェクトを移行するためになんらかの操作を実行する必要はありません。Oracle Streams環境にDDLルールを追加することで、これらのオブジェクトの将来の変更と作成をサポートできます。

たとえば、orc1.example.comデータベースの取得プロセスstreams_captureが、hrスキーマのすべてのデータベース・オブジェクトに対するDDL変更を取得するように指定するには、スクリプトに次の記述を追加します。

BEGIN
DBMS_STREAMS_ADM.ADD_SCHEMA_RULES(
schema_name        => 'hr',
streams_type       => 'capture',
streams_name       => 'streams_capture',
queue_name         => 'strmadmin.streams_queue',
include_dml        => FALSE,
include_ddl        => TRUE,
include_tagged_lcr => FALSE,
source_database    => 'orc1.example.com');
END;
/

include_ddlパラメータがTRUEに設定されていることに注意してください。このパラメータをTRUEに設定することで、このプロシージャはhrスキーマに対するDDL変更のスキーマ・ルールを、取得プロセスのルール・セットに追加します。このルールは、取得プロセスに対し、hrスキーマおよびそのオブジェクトに対するDDL変更を取得するように指示します。DDL変更をレプリケートする場合、適切な伝播と適用プロセスに同様のルールを追加する必要があります。

関連項目:

- 第9章「Oracle Streamsの競合解消」

- キュー・ツー・キュー伝播の詳細は、『Oracle Streams概要および管理』を参照してください。

Oracle Streamsへのアドバンスト・レプリケーションの移行の実行

ここでは、アドバンスト・レプリケーション環境からOracle Streams環境への移行を実行する方法について説明します。

この項の内容は、次のとおりです。

- 移行スクリプトの実行前の手順

- 移行スクリプトの実行

- スクリプトの実行後の手順

移行スクリプトの実行前の手順

移行スクリプトを実行する前に、次の手順を完了します。

1. Oracle Streamsに関連する初期化パラメータの設定

2. すべてのサイトでのアーカイブ・ロギングの有効化

3. データベース・リンクの作成

4. Oracle Streamsに移行する各レプリケーション・グループの静止

手順1: Oracle Streamsに関連する初期化パラメータの設定

各レプリケーション・データベースで、Oracle Streamsに関連する初期化パラメータを設定し、必要に応じてデータベースを再起動します。

関連項目:
Oracle Streamsに重要な初期化パラメータの詳細は、『Oracle Streamsに関連する初期化パラメータの設定』を参照してください。

手順2: すべてのサイトでのアーカイブ・ロギングの有効化

取得プロセスではARCHIVELOGモードである必要があるため、各マスター・サイトがARCHIVELOGモードで実行されていることを確認します。サンプル環境では、orc1.example.com、orc2.example.comおよびorc3.example.comがARCHIVELOGモードで実行されている必要があります。データベースのログ・モードは、V$DATABASE動的パフォーマンス・ビューのLOG_MODE列を問い合せることで確認できます。

関連項目:
ARCHIVELOGモードでデータベースを実行する方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

手順3: データベース・リンクの作成

各マスター・サイトで、Oracle Streams管理者から他のマスター・サイトのOracle Streams管理者へのデータベース・リンクを作成します。「Oracle Streamsに移行するアドバンスト・レプリケーション環境の例」に示した環境例の場合、次のデータベース・リンクを作成します。

CONNECT strmadmin@orc1.example.com
Enter password: password

CREATE DATABASE LINK orc2.example.com CONNECT TO strmadmin
IDENTIFIED BY password USING 'orc2.example.com';

CREATE DATABASE LINK orc3.example.com CONNECT TO strmadmin
IDENTIFIED BY password USING 'orc3.example.com';

CONNECT strmadmin@orc2.example.com
Enter password: password

CREATE DATABASE LINK orc1.example.com CONNECT TO strmadmin
IDENTIFIED BY password USING 'orc1.example.com';

CREATE DATABASE LINK orc3.example.com CONNECT TO strmadmin
IDENTIFIED BY password USING 'orc3.example.com';

CONNECT strmadmin@orc3.example.com
Enter password: password

CREATE DATABASE LINK orc1.example.com CONNECT TO strmadmin
IDENTIFIED BY password USING 'orc1.example.com';

CREATE DATABASE LINK orc2.example.com CONNECT TO strmadmin
IDENTIFIED BY password USING 'orc2.example.com';

手順4: Oracle Streamsに移行する各レプリケーション・グループの静止

Oracle Streamsに移行する各レプリケーション・グループのマスター定義サイトで、DBMS_REPCAT.SUSPEND_MASTER_ACTIVITYプロシージャを実行します。

前述の環境例では、orc1.example.comがマスター定義サイトであり、hr_repgがOracle Streamsに移行するレプリケーション・グループです。したがって、レプリケーション管理者としてorc1.example.comに接続し、SUSPEND_MASTER_ACTIVITYプロシージャを実行します。

CONNECT repadmin@orc1.example.com
Enter password: password

BEGIN
DBMS_REPCAT.SUSPEND_MASTER_ACTIVITY (
gname => 'hr_repg');
END;
/

マスター・グループが静止されるまで、次の手順に進まないでください。マスター・グループの状態を確認するには、DBA_REPGROUPデータ・ディクショナリ・ビューのSTATUS列を問い合せます。

移行スクリプトの実行

移行を行うには、次の手順を実行します。

1. Oracle Streams管理者としての接続と各サイトでのスクリプトの実行

2. すべてのサイトにおけるOracle Streams構成の正常終了の確認

手順1: Oracle Streams管理者としての接続と各サイトでのスクリプトの実行

前述の環境例では、SQL*Plusでorc1.example.com、orc2.example.comおよびorc3.example.comにOracle Streams管理者strmadminとして接続し、移行スクリプトrep2streams.sqlを実行します。

CONNECT strmadmin@orc1.example.com
Enter password: password

SET ECHO ON
SPOOL rep2streams.out
@rep2streams.sql

CONNECT strmadmin@orc2.example.com
Enter password: password

SET ECHO ON
SPOOL rep2streams.out
@rep2streams.sql

CONNECT strmadmin@orc3.example.com
Enter password: password

SET ECHO ON
SPOOL rep2streams.out
@rep2streams.sql

手順2: すべてのサイトにおけるOracle Streams構成の正常終了の確認

各サイトでスプール・ファイルをチェックして、エラーがないことを確認します。エラーがある場合は、正常に実行されなかった手順が実行されるようにスクリプトを変更し、スクリプトを再実行する必要があります。前述の環境例では、スプール・ファイルは各マスター・サイトのrep2streams.outです。

スクリプトの実行後の手順

移行プロセスを完了するには、次の手順を実行します。

1. 各サイトでの移行済レプリケーション・グループの削除

2. 各サイトでの取得プロセスの起動

3. 各サイトでの取得プロセスの起動

手順1: 各サイトでの移行済レプリケーション・グループの削除

レプリケーション管理者としてマスター定義サイトに接続し、DBMS_REPCAT.DROP_MASTER_REPGROUPプロシージャを実行して、Oracle Streamsへの移行が正常に終了したレプリケーション・グループを削除します。

注意:
DROP_MASTER_REPGROUPプロシージャのdrop_contentsパラメータがFALSEに設定されていることを確認してください。TRUEに設定されている場合、レプリケートされたデータベース・オブジェクトが削除されます。

CONNECT repadmin@orc1.example.com
Enter password: password

BEGIN
DBMS_REPCAT.DROP_MASTER_REPGROUP (
gname         => 'hr_repg',
drop_contents => FALSE,
all_sites     => TRUE);
END;
/

各データベースで移行済のレプリケーション・グループが削除されていることを確認するには、DBA_REPGROUPデータ・ディクショナリ・ビューのGNAME列を問い合せます。移行済のレプリケーション・グループがどのデータベースの問合せでも出力されないことを確認する必要があります。

レプリケーション管理者が不要になった場合、このユーザーも削除できます。

注意:
Oracle Streamsの設定後は、アドバンスト・レプリケーションのアクティビティを再開しないでください。

手順2: 各サイトでの適用プロセスの起動

Oracle Streams管理者として接続中に次の問合せを実行すると、各サイトの適用プロセスの名前を表示できます。

SELECT APPLY_NAME FROM DBA_APPLY;

適用プロセス名がわかっている場合、Oracle Streams管理者として接続中にDBMS_APPLY_ADMパッケージのSTART_APPLYプロシージャを実行することで、各適用プロセスを起動できます。たとえば、次のプロシージャを実行すると、適用プロセスapply_from_orc2がorc1.example.comで起動されます。

CONNECT strmadmin@orc1.example.com
Enter password: password

BEGIN
DBMS_APPLY_ADM.START_APPLY(
apply_name => 'apply_from_orc2');
END;
/

新しいOracle Streams環境のすべてのデータベースで各適用プロセスを起動してください。

手順3: 各サイトでの取得プロセスの起動

Oracle Streams管理者として接続中に次の問合せを実行すると、各サイトの取得プロセスの名前を表示できます。

SELECT CAPTURE_NAME FROM DBA_CAPTURE;

取得プロセス名がわかっている場合、Oracle Streams管理者として接続中にDBMS_CAPTURE_ADMパッケージのSTART_CAPTUREプロシージャを実行することで、各取得プロセスを起動できます。たとえば、次のプロシージャを実行すると、取得プロセスstreams_captureがorc1.example.comで起動されます。

CONNECT strmadmin@orc1.example.com
Enter password: password

BEGIN
DBMS_CAPTURE_ADM.START_CAPTURE(
capture_name => 'streams_capture');
END;
/

新しいOracle Streams環境のすべてのデータベースで各取得プロセスを起動してください。

マテリアライズド・ビュー・グループを保持するマスター・サイトの再作成

1つ以上のマテリアライズド・ビュー・グループで、Oracle Streamsに移行したマスター・グループが使用されていた場合、マスター・グループを再作成して、そのマテリアライズド・ビュー・グループを保持する必要があります。したがって、マテリアライズド・ビュー・グループのマスター・サイトとして機能している各データベースは、そのマテリアライズド・ビュー・グループのマテリアライズド・ビューで使用されている表を含む単一マスター構成のレプリケーション・グループのマスター定義サイトとなる必要があります。

Oracle Streamsに移行された元のレプリケーション・グループと同様のレプリケーション・グループを作成するには、レプリケーション・マネージメントAPIを使用します。新しいレプリケーション・グループは、同じレプリケーション・グループ名、オブジェクト、競合解消方法およびキー列を持ちます。既存のマテリアライズド・ビュー・グループを保持するには、マテリアライズド・ビュー・グループのマスター・グループが含まれていた各マスター・サイトでそれぞれのマスター・グループを再作成し、マスター・グループでマスター・レプリケーション・オブジェクトを再作成して、マスター・グループのレプリケーション・サポートを再生成し、マスター・グループのレプリケーション・アクティビティを再開する必要があります。

たとえば、次のアドバンスト・レプリケーション環境を考えます。

- 2つのマスター・サイトmdb1.example.comおよびmdb2.example.comに、レプリケーション・グループrg1が存在します。mdb1.example.comデータベースはマスター定義サイトであり、rg1レプリケーション・グループのオブジェクトはmdb1.example.comとmdb2.example.comの間でレプリケートされます。

- mdb1.example.comのrg1レプリケーション・グループは、mv1.example.comのmvg1マテリアライズド・ビュー・グループのマスター・グループです。

- mdb2.example.comのrg1レプリケーション・グループは、mv2.example.comのmvg2マテリアライズド・ビュー・グループのマスター・グループです。

rg1レプリケーション・グループがmdb1.example.comとmdb2.example.comの両方でOracle Streamsに移行され、mv1.example.comのマテリアライズド・ビュー・グループmvg1およびmv2.example.comのマテリアライズド・ビュー・グループmvg2を保持する場合、Oracle Streamsへの移行後に、mdb1.example.comとmdb2.example.comでrg1レプリケーション・グループを再作成する必要があります。単一マスター環境で、mdb1.example.comとmdb2.example.comの両方がrg1レプリケーション・グループのマスター定義サイトになるように構成します。

マテリアライズド・ビュー・サイトでマテリアライズド・ビュー・グループを削除または再作成する必要はありません。新しいマスター・レプリケーション・グループが元のレプリケーション・グループと同様である場合、マテリアライズド・ビュー・グループに影響はありません。各マスター・オブジェクトのレプリケーション・サポートの生成が完了するまで、これらのマテリアライズド・ビュー・グループをリフレッシュしないでください(この項の手順3を参照)。また、各マスター・オブジェクトのレプリケーション・サポートの生成が完了するまで、更新可能なマテリアライズド・ビューを持つマテリアライズド・ビュー・サイトで遅延トランザクション・キューをプッシュしないでください。

「Oracle Streamsに移行するアドバンスト・レプリケーション環境の例」に示した環境例では、orc1.example.comのhr_repgレプリケーション・グループのみがmv1.example.comのマテリアライズド・ビュー・グループのマスター・グループでした。mv1.example.comのこのマテリアライズド・ビュー・グループを保持するには、レプリケーション管理者として接続中に次の手順を実行します。

1. orc1.example.comでマスター・グループhr_repgを作成します。

CONNECT repadmin@orc1.example.com
Enter password: password

BEGIN
DBMS_REPCAT.CREATE_MASTER_REPGROUP (
gname => 'hr_repg');
END;
/

2. hr_repgマスター・グループにhrスキーマの表を追加します。これらの表は、mv1.example.comのマテリアライズド・ビューのマスター表です。

BEGIN
DBMS_REPCAT.CREATE_MASTER_REPOBJECT (
gname               => 'hr_repg',
type                => 'TABLE',
oname               => 'countries',
sname               => 'hr',
use_existing_object => TRUE,
copy_rows           => FALSE);
END;
/

BEGIN
DBMS_REPCAT.CREATE_MASTER_REPOBJECT (
gname               => 'hr_repg',
type                => 'TABLE',
oname               => 'departments',
sname               => 'hr',
use_existing_object => TRUE,
copy_rows           => FALSE);
END;
/

BEGIN
DBMS_REPCAT.CREATE_MASTER_REPOBJECT (
gname               => 'hr_repg',
type                => 'TABLE',
oname               => 'employees',
sname               => 'hr',
use_existing_object => TRUE,
copy_rows           => FALSE);
END;
/

BEGIN
DBMS_REPCAT.CREATE_MASTER_REPOBJECT (
gname               => 'hr_repg',
type                => 'TABLE',
oname               => 'jobs',
sname               => 'hr',
use_existing_object => TRUE,
copy_rows           => FALSE);
END;
/

BEGIN
DBMS_REPCAT.CREATE_MASTER_REPOBJECT (
gname               => 'hr_repg',
type                => 'TABLE',
oname               => 'job_history',
sname               => 'hr',
use_existing_object => TRUE,
copy_rows           => FALSE);
END;
/

BEGIN
DBMS_REPCAT.CREATE_MASTER_REPOBJECT (
gname               => 'hr_repg',
type                => 'TABLE',
oname               => 'locations',
sname               => 'hr',
use_existing_object => TRUE,
copy_rows           => FALSE);
END;
/

BEGIN
DBMS_REPCAT.CREATE_MASTER_REPOBJECT (
gname               => 'hr_repg',
type                => 'TABLE',
oname               => 'regions',
sname               => 'hr',
use_existing_object => TRUE,
copy_rows           => FALSE);
END;
/

3. hr_repgマスター・グループの各オブジェクトのレプリケーション・サポートを生成します。

BEGIN
DBMS_REPCAT.GENERATE_REPLICATION_SUPPORT (
sname             => 'hr',
oname             => 'countries',
type              => 'TABLE');
END;
/

BEGIN
DBMS_REPCAT.GENERATE_REPLICATION_SUPPORT (
sname             => 'hr',
oname             => 'departments',
type              => 'TABLE');
END;
/

BEGIN
DBMS_REPCAT.GENERATE_REPLICATION_SUPPORT (
sname             => 'hr',
oname             => 'employees',
type              => 'TABLE');
END;
/

BEGIN
DBMS_REPCAT.GENERATE_REPLICATION_SUPPORT (
sname             => 'hr',
oname             => 'jobs',
type              => 'TABLE');
END;
/

BEGIN
DBMS_REPCAT.GENERATE_REPLICATION_SUPPORT (
sname             => 'hr',
oname             => 'job_history',
type              => 'TABLE');
END;
/

BEGIN
DBMS_REPCAT.GENERATE_REPLICATION_SUPPORT (
sname             => 'hr',
oname             => 'locations',
type              => 'TABLE');
END;
/

BEGIN
DBMS_REPCAT.GENERATE_REPLICATION_SUPPORT (
sname             => 'hr',
oname             => 'regions',
type              => 'TABLE');
END;
/

4. hr_repgマスター・グループのマスター・アクティビティを再開します。

BEGIN
DBMS_REPCAT.RESUME_MASTER_ACTIVITY (
gname => 'hr_repg');
END;
/

注意:
レプリケーション・グループをOracle Streamsに移行した後にこれらのログを手動で削除した場合を除き、hr_repgマスター・グループに追加した表ごとにマテリアライズド・ビュー・ログが存在します。マテリアライズド・ビュー・ログが存在しない場合は、これらのログを作成する必要があります。

Oracle Streams移行スクリプトに移行するアドバンスト・レプリケーションの例

環境に対して生成されたスクリプトの例を次に示します。

The following is an example script generated for the environment:
----------------------------------------------------------
-- Migration Script Generated on 12-JUN-05 by user STRMADMIN. --
----------------------------------------------------------

----------------------------------------------------------
--  ************** Notes and Assumptions ************** --
--
-- 1. The Oracle Streams Administrator is "strmadmin".
--    The user "strmadmin" must be created and granted the
--    required privileges before running the script.
--
-- 2. Names of queue tables, queues, capture processes
--    propagation jobs, and apply processes will be the
--    same at all sites. If the DBA wants different names,
--    he must edit the script manually before running it
--    at each master site.
--
-- 3. Archive logging must be enabled at all sites before
--    running the script.
--
-- 4. Users must set up database links for queue to queue
--    propagation, if needed.
--
-- 5. Repgroups must be quiesced before running the script.
----------------------------------------------------------

set pagesize 1000
set echo on
set serveroutput on
whenever sqlerror exit sql.sqlcode;

--
-- Raise error if Repgroups are not Quiesced.
--
declare
repgroup_status VARCHAR2(10);
begin
select status into repgroup_status
from dba_repcat
where gname = 'HR_REPG';

if (repgroup_status != 'QUIESCED') THEN
raise_application_error(-20000,
'ORA-23310: object group "HR_REPG" is not quiesced.');
end if;
exception when no_data_found then
null;
end;
/

-------------------------------
-- Queue Owner
-------------------------------
-- streams queue owner at ORC1.EXAMPLE.COM
define QUEUE_OWNER_ORC1 = strmadmin

-- streams queue owner at ORC2.EXAMPLE.COM
define QUEUE_OWNER_ORC2 = strmadmin

-- streams queue owner at ORC3.EXAMPLE.COM
define QUEUE_OWNER_ORC3 = strmadmin

-------------------------------
-- Queue Table
-------------------------------
-- streams queue table at ORC1.EXAMPLE.COM
define QUEUE_TABLE_ORC1 = streams_queue_table

-- streams queue table at ORC2.EXAMPLE.COM
define QUEUE_TABLE_ORC2 = streams_queue_table

-- streams queue table at ORC3.EXAMPLE.COM
define QUEUE_TABLE_ORC3 = streams_queue_table

-------------------------------
-- Queue
-------------------------------
-- streams queue at ORC1.EXAMPLE.COM
define QUEUE_ORC1 = streams_queue

-- streams queue at ORC2.EXAMPLE.COM
define QUEUE_ORC2 = streams_queue

-- streams queue at ORC3.EXAMPLE.COM
define QUEUE_ORC3 = streams_queue

-------------------------------
-- Propagation names
-------------------------------
-- propagation process to ORC1.EXAMPLE.COM
define PROP_ORC1 = prop_to_ORC1

-- propagation process to ORC2.EXAMPLE.COM
define PROP_ORC2 = prop_to_ORC2

-- propagation process to ORC3.EXAMPLE.COM
define PROP_ORC3 = prop_to_ORC3

-------------------------------
-- Capture Process
-------------------------------
-- capture process to be used or created at the local site
define CAPTURE_NAME = streams_capture

-------------------------------
-- Apply processes
-------------------------------
-- apply process for applying LCRs from ORC1.EXAMPLE.COM
define APPLY_ORC1 = apply_from_ORC1

-- apply process for applying LCRs from ORC2.EXAMPLE.COM
define APPLY_ORC2 = apply_from_ORC2

-- apply process for applying LCRs from ORC3.EXAMPLE.COM
define APPLY_ORC3 = apply_from_ORC3

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- DEPT_LOCATION_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_DEPARTMENT_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_JOB_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_MANAGER_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- INSERT_TIME of type TRIGGER belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_DEPARTMENT_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_EMPLOYEE_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_JOB_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- LOC_COUNTRY_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- DEPT_LOCATION_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_DEPARTMENT_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_JOB_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_MANAGER_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- INSERT_TIME of type TRIGGER belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_DEPARTMENT_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_EMPLOYEE_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_JOB_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- LOC_COUNTRY_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- DEPT_LOCATION_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_DEPARTMENT_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_JOB_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_MANAGER_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- INSERT_TIME of type TRIGGER belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_DEPARTMENT_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_EMPLOYEE_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_JOB_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- LOC_COUNTRY_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- DEPT_LOCATION_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_DEPARTMENT_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_JOB_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_MANAGER_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- INSERT_TIME of type TRIGGER belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_DEPARTMENT_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_EMPLOYEE_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_JOB_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- LOC_COUNTRY_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- DEPT_LOCATION_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_DEPARTMENT_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_JOB_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_MANAGER_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- INSERT_TIME of type TRIGGER belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_DEPARTMENT_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_EMPLOYEE_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_JOB_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- LOC_COUNTRY_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- DEPT_LOCATION_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_DEPARTMENT_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_JOB_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_MANAGER_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- INSERT_TIME of type TRIGGER belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_DEPARTMENT_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_EMPLOYEE_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_JOB_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- LOC_COUNTRY_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- DEPT_LOCATION_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_DEPARTMENT_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_JOB_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_MANAGER_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- INSERT_TIME of type TRIGGER belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_DEPARTMENT_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_EMPLOYEE_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_JOB_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- LOC_COUNTRY_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--

-------------------------------
-- Setup Queue
-------------------------------

variable local_db          varchar2(128);
variable local_queue_table varchar2(30);
variable local_queue       varchar2(30);
variable local_queue_owner varchar2(30);

-- get the local database name
declare
global_name varchar2(128);
begin
select global_name into :local_db from global_name;
dbms_output.put_line('The local database name is: ' || :local_db);
end;
/

-- get the local queue table and queue name
begin
if :local_db = 'ORC1.EXAMPLE.COM' then
:local_queue_table := '&QUEUE_TABLE_ORC1';
:local_queue := '&QUEUE_ORC1';
:local_queue_owner := '&QUEUE_OWNER_ORC1';

elsif :local_db = 'ORC2.EXAMPLE.COM' then
:local_queue_table := '&QUEUE_TABLE_ORC2';
:local_queue := '&QUEUE_ORC2';
:local_queue_owner := '&QUEUE_OWNER_ORC2';

elsif :local_db = 'ORC3.EXAMPLE.COM' then
:local_queue_table := '&QUEUE_TABLE_ORC3';
:local_queue := '&QUEUE_ORC3';
:local_queue_owner := '&QUEUE_OWNER_ORC3';

end if;

dbms_output.put_line('The local queue owner is: ' || :local_queue_owner);
dbms_output.put_line('The local queue table is: ' || :local_queue_table);
dbms_output.put_line('The local queue name  is: ' || :local_queue);
end;
/

begin
dbms_streams_adm.set_up_queue(
queue_table => :local_queue_table,
storage_clause => NULL,
queue_name => :local_queue,
queue_user => :local_queue_owner,
comment => 'streams_comment');
end;
/

-------------------------------
-- Set Instantiation SCN
-------------------------------

variable flashback_scn number;

begin
select dbms_flashback.get_system_change_number into :flashback_scn
from dual;
dbms_output.put_line('local flashback SCN is: ' || :flashback_scn);
end;
/

--
-- Setup instantiation SCN for ORC1.EXAMPLE.COM
--
begin
--
-- HR_REPG : Set instantiation SCN for "HR"."COUNTRIES" at
-- ORC1.EXAMPLE.COM
--
if (:local_db != 'ORC1.EXAMPLE.COM') then
dbms_apply_adm.set_table_instantiation_scn@ORC1.EXAMPLE.COM(
source_object_name => '"HR"."COUNTRIES"',
source_database_name => :local_db,
instantiation_scn => :flashback_scn,
apply_database_link => NULL);
end if;
end;
/

begin
--
-- HR_REPG : Set instantiation SCN for "HR"."DEPARTMENTS" at
-- ORC1.EXAMPLE.COM
--
if (:local_db != 'ORC1.EXAMPLE.COM') then
dbms_apply_adm.set_table_instantiation_scn@ORC1.EXAMPLE.COM(
source_object_name => '"HR"."DEPARTMENTS"',
source_database_name => :local_db,
instantiation_scn => :flashback_scn,
apply_database_link => NULL);
end if;
end;
/

begin
--
-- HR_REPG : Set instantiation SCN for "HR"."EMPLOYEES" at
-- ORC1.EXAMPLE.COM
--
if (:local_db != 'ORC1.EXAMPLE.COM') then
dbms_apply_adm.set_table_instantiation_scn@ORC1.EXAMPLE.COM(
source_object_name => '"HR"."EMPLOYEES"',
source_database_name => :local_db,
instantiation_scn => :flashback_scn,
apply_database_link => NULL);
end if;
end;
/

begin
--
-- HR_REPG : Set instantiation SCN for "HR"."JOBS" at
-- ORC1.EXAMPLE.COM
--
if (:local_db != 'ORC1.EXAMPLE.COM') then
dbms_apply_adm.set_table_instantiation_scn@ORC1.EXAMPLE.COM(
source_object_name => '"HR"."JOBS"',
source_database_name => :local_db,
instantiation_scn => :flashback_scn,
apply_database_link => NULL);
end if;
end;
/

begin
--
-- HR_REPG : Set instantiation SCN for "HR"."JOB_HISTORY" at
-- ORC1.EXAMPLE.COM
--
if (:local_db != 'ORC1.EXAMPLE.COM') then
dbms_apply_adm.set_table_instantiation_scn@ORC1.EXAMPLE.COM(
source_object_name => '"HR"."JOB_HISTORY"',
source_database_name => :local_db,
instantiation_scn => :flashback_scn,
apply_database_link => NULL);
end if;
end;
/

begin
--
-- HR_REPG : Set instantiation SCN for "HR"."LOCATIONS" at
-- ORC1.EXAMPLE.COM
--
if (:local_db != 'ORC1.EXAMPLE.COM') then
dbms_apply_adm.set_table_instantiation_scn@ORC1.EXAMPLE.COM(
source_object_name => '"HR"."LOCATIONS"',
source_database_name => :local_db,
instantiation_scn => :flashback_scn,
apply_database_link => NULL);
end if;
end;
/

begin
--
-- HR_REPG : Set instantiation SCN for "HR"."REGIONS" at
-- ORC1.EXAMPLE.COM
--
if (:local_db != 'ORC1.EXAMPLE.COM') then
dbms_apply_adm.set_table_instantiation_scn@ORC1.EXAMPLE.COM(
source_object_name => '"HR"."REGIONS"',
source_database_name => :local_db,
instantiation_scn => :flashback_scn,
apply_database_link => NULL);
end if;
end;
/

--
-- Setup instantiation SCN for ORC2.EXAMPLE.COM
--
begin
--
-- HR_REPG : Set instantiation SCN for "HR"."COUNTRIES" at
-- ORC2.EXAMPLE.COM
--
if (:local_db != 'ORC2.EXAMPLE.COM') then
dbms_apply_adm.set_table_instantiation_scn@ORC2.EXAMPLE.COM(
source_object_name => '"HR"."COUNTRIES"',
source_database_name => :local_db,
instantiation_scn => :flashback_scn,
apply_database_link => NULL);
end if;
end;
/

begin
--
-- HR_REPG : Set instantiation SCN for "HR"."DEPARTMENTS" at
-- ORC2.EXAMPLE.COM
--
if (:local_db != 'ORC2.EXAMPLE.COM') then
dbms_apply_adm.set_table_instantiation_scn@ORC2.EXAMPLE.COM(
source_object_name => '"HR"."DEPARTMENTS"',
source_database_name => :local_db,
instantiation_scn => :flashback_scn,
apply_database_link => NULL);
end if;
end;
/

begin
--
-- HR_REPG : Set instantiation SCN for "HR"."EMPLOYEES" at
-- ORC2.EXAMPLE.COM
--
if (:local_db != 'ORC2.EXAMPLE.COM') then
dbms_apply_adm.set_table_instantiation_scn@ORC2.EXAMPLE.COM(
source_object_name => '"HR"."EMPLOYEES"',
source_database_name => :local_db,
instantiation_scn => :flashback_scn,
apply_database_link => NULL);
end if;
end;
/

begin
--
-- HR_REPG : Set instantiation SCN for "HR"."JOBS" at
-- ORC2.EXAMPLE.COM
--
if (:local_db != 'ORC2.EXAMPLE.COM') then
dbms_apply_adm.set_table_instantiation_scn@ORC2.EXAMPLE.COM(
source_object_name => '"HR"."JOBS"',
source_database_name => :local_db,
instantiation_scn => :flashback_scn,
apply_database_link => NULL);
end if;
end;
/

begin
--
-- HR_REPG : Set instantiation SCN for "HR"."JOB_HISTORY" at
-- ORC2.EXAMPLE.COM
--
if (:local_db != 'ORC2.EXAMPLE.COM') then
dbms_apply_adm.set_table_instantiation_scn@ORC2.EXAMPLE.COM(
source_object_name => '"HR"."JOB_HISTORY"',
source_database_name => :local_db,
instantiation_scn => :flashback_scn,
apply_database_link => NULL);
end if;
end;
/

begin
--
-- HR_REPG : Set instantiation SCN for "HR"."LOCATIONS" at
-- ORC2.EXAMPLE.COM
--
if (:local_db != 'ORC2.EXAMPLE.COM') then
dbms_apply_adm.set_table_instantiation_scn@ORC2.EXAMPLE.COM(
source_object_name => '"HR"."LOCATIONS"',
source_database_name => :local_db,
instantiation_scn => :flashback_scn,
apply_database_link => NULL);
end if;
end;
/

begin
--
-- HR_REPG : Set instantiation SCN for "HR"."REGIONS" at
-- ORC2.EXAMPLE.COM
--
if (:local_db != 'ORC2.EXAMPLE.COM') then
dbms_apply_adm.set_table_instantiation_scn@ORC2.EXAMPLE.COM(
source_object_name => '"HR"."REGIONS"',
source_database_name => :local_db,
instantiation_scn => :flashback_scn,
apply_database_link => NULL);
end if;
end;
/

--
-- Setup instantiation SCN for ORC3.EXAMPLE.COM
--
begin
--
-- HR_REPG : Set instantiation SCN for "HR"."COUNTRIES" at
-- ORC3.EXAMPLE.COM
--
if (:local_db != 'ORC3.EXAMPLE.COM') then
dbms_apply_adm.set_table_instantiation_scn@ORC3.EXAMPLE.COM(
source_object_name => '"HR"."COUNTRIES"',
source_database_name => :local_db,
instantiation_scn => :flashback_scn,
apply_database_link => NULL);
end if;
end;
/

begin
--
-- HR_REPG : Set instantiation SCN for "HR"."DEPARTMENTS" at
-- ORC3.EXAMPLE.COM
--
if (:local_db != 'ORC3.EXAMPLE.COM') then
dbms_apply_adm.set_table_instantiation_scn@ORC3.EXAMPLE.COM(
source_object_name => '"HR"."DEPARTMENTS"',
source_database_name => :local_db,
instantiation_scn => :flashback_scn,
apply_database_link => NULL);
end if;
end;
/

begin
--
-- HR_REPG : Set instantiation SCN for "HR"."EMPLOYEES" at
-- ORC3.EXAMPLE.COM
--
if (:local_db != 'ORC3.EXAMPLE.COM') then
dbms_apply_adm.set_table_instantiation_scn@ORC3.EXAMPLE.COM(
source_object_name => '"HR"."EMPLOYEES"',
source_database_name => :local_db,
instantiation_scn => :flashback_scn,
apply_database_link => NULL);
end if;
end;
/

begin
--
-- HR_REPG : Set instantiation SCN for "HR"."JOBS" at
-- ORC3.EXAMPLE.COM
--
if (:local_db != 'ORC3.EXAMPLE.COM') then
dbms_apply_adm.set_table_instantiation_scn@ORC3.EXAMPLE.COM(
source_object_name => '"HR"."JOBS"',
source_database_name => :local_db,
instantiation_scn => :flashback_scn,
apply_database_link => NULL);
end if;
end;
/

begin
--
-- HR_REPG : Set instantiation SCN for "HR"."JOB_HISTORY" at
-- ORC3.EXAMPLE.COM
--
if (:local_db != 'ORC3.EXAMPLE.COM') then
dbms_apply_adm.set_table_instantiation_scn@ORC3.EXAMPLE.COM(
source_object_name => '"HR"."JOB_HISTORY"',
source_database_name => :local_db,
instantiation_scn => :flashback_scn,
apply_database_link => NULL);
end if;
end;
/

begin
--
-- HR_REPG : Set instantiation SCN for "HR"."LOCATIONS" at
-- ORC3.EXAMPLE.COM
--
if (:local_db != 'ORC3.EXAMPLE.COM') then
dbms_apply_adm.set_table_instantiation_scn@ORC3.EXAMPLE.COM(
source_object_name => '"HR"."LOCATIONS"',
source_database_name => :local_db,
instantiation_scn => :flashback_scn,
apply_database_link => NULL);
end if;
end;
/

begin
--
-- HR_REPG : Set instantiation SCN for "HR"."REGIONS" at
-- ORC3.EXAMPLE.COM
--
if (:local_db != 'ORC3.EXAMPLE.COM') then
dbms_apply_adm.set_table_instantiation_scn@ORC3.EXAMPLE.COM(
source_object_name => '"HR"."REGIONS"',
source_database_name => :local_db,
instantiation_scn => :flashback_scn,
apply_database_link => NULL);
end if;
end;
/

-------------------------------
-- Setup Propagation
-------------------------------

--
-- Propagation from local queue to ORC1.EXAMPLE.COM
--
begin
if :local_db != 'ORC1.EXAMPLE.COM' then
--
-- HR_REPG: Propagate "COUNTRIES" from local queue to ORC1
--
dbms_streams_adm.add_table_propagation_rules(
table_name => '"HR"."COUNTRIES"',
streams_name => '&PROP_ORC1',
source_queue_name => :local_queue_owner || '.' || :local_queue,
destination_queue_name => '&QUEUE_OWNER_ORC1' ||
'.' || '&QUEUE_ORC1' ||
'@ORC1.EXAMPLE.COM',
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => :local_db);
end if;
end;
/

begin
if :local_db != 'ORC1.EXAMPLE.COM' then
--
-- HR_REPG: Propagate "DEPARTMENTS" from local queue to ORC1
--
dbms_streams_adm.add_table_propagation_rules(
table_name => '"HR"."DEPARTMENTS"',
streams_name => '&PROP_ORC1',
source_queue_name => :local_queue_owner || '.' || :local_queue,
destination_queue_name => '&QUEUE_OWNER_ORC1' ||
'.' || '&QUEUE_ORC1' ||
'@ORC1.EXAMPLE.COM',
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => :local_db);
end if;
end;
/

begin
if :local_db != 'ORC1.EXAMPLE.COM' then
--
-- HR_REPG: Propagate "EMPLOYEES" from local queue to ORC1
--
dbms_streams_adm.add_table_propagation_rules(
table_name => '"HR"."EMPLOYEES"',
streams_name => '&PROP_ORC1',
source_queue_name => :local_queue_owner || '.' || :local_queue,
destination_queue_name => '&QUEUE_OWNER_ORC1' ||
'.' || '&QUEUE_ORC1' ||
'@ORC1.EXAMPLE.COM',
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => :local_db);
end if;
end;
/

begin
if :local_db != 'ORC1.EXAMPLE.COM' then
--
-- HR_REPG: Propagate "JOBS" from local queue to ORC1
--
dbms_streams_adm.add_table_propagation_rules(
table_name => '"HR"."JOBS"',
streams_name => '&PROP_ORC1',
source_queue_name => :local_queue_owner || '.' || :local_queue,
destination_queue_name => '&QUEUE_OWNER_ORC1' ||
'.' || '&QUEUE_ORC1' ||
'@ORC1.EXAMPLE.COM',
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => :local_db);
end if;
end;
/

begin
if :local_db != 'ORC1.EXAMPLE.COM' then
--
-- HR_REPG: Propagate "JOB_HISTORY" from local queue to ORC1
--
dbms_streams_adm.add_table_propagation_rules(
table_name => '"HR"."JOB_HISTORY"',
streams_name => '&PROP_ORC1',
source_queue_name => :local_queue_owner || '.' || :local_queue,
destination_queue_name => '&QUEUE_OWNER_ORC1' ||
'.' || '&QUEUE_ORC1' ||
'@ORC1.EXAMPLE.COM',
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => :local_db);
end if;
end;
/

begin
if :local_db != 'ORC1.EXAMPLE.COM' then
--
-- HR_REPG: Propagate "LOCATIONS" from local queue to ORC1
--
dbms_streams_adm.add_table_propagation_rules(
table_name => '"HR"."LOCATIONS"',
streams_name => '&PROP_ORC1',
source_queue_name => :local_queue_owner || '.' || :local_queue,
destination_queue_name => '&QUEUE_OWNER_ORC1' ||
'.' || '&QUEUE_ORC1' ||
'@ORC1.EXAMPLE.COM',
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => :local_db);
end if;
end;
/

begin
if :local_db != 'ORC1.EXAMPLE.COM' then
--
-- HR_REPG: Propagate "REGIONS" from local queue to ORC1
--
dbms_streams_adm.add_table_propagation_rules(
table_name => '"HR"."REGIONS"',
streams_name => '&PROP_ORC1',
source_queue_name => :local_queue_owner || '.' || :local_queue,
destination_queue_name => '&QUEUE_OWNER_ORC1' ||
'.' || '&QUEUE_ORC1' ||
'@ORC1.EXAMPLE.COM',
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => :local_db);
end if;
end;
/

--
-- Propagation from local queue to ORC2.EXAMPLE.COM
--
begin
if :local_db != 'ORC2.EXAMPLE.COM' then
--
-- HR_REPG: Propagate "COUNTRIES" from local queue to ORC2
--
dbms_streams_adm.add_table_propagation_rules(
table_name => '"HR"."COUNTRIES"',
streams_name => '&PROP_ORC2',
source_queue_name => :local_queue_owner || '.' || :local_queue,
destination_queue_name => '&QUEUE_OWNER_ORC2' ||
'.' || '&QUEUE_ORC2' ||
'@ORC2.EXAMPLE.COM',
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => :local_db);
end if;
end;
/

begin
if :local_db != 'ORC2.EXAMPLE.COM' then
--
-- HR_REPG: Propagate "DEPARTMENTS" from local queue to ORC2
--
dbms_streams_adm.add_table_propagation_rules(
table_name => '"HR"."DEPARTMENTS"',
streams_name => '&PROP_ORC2',
source_queue_name => :local_queue_owner || '.' || :local_queue,
destination_queue_name => '&QUEUE_OWNER_ORC2' ||
'.' || '&QUEUE_ORC2' ||
'@ORC2.EXAMPLE.COM',
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => :local_db);
end if;
end;
/

begin
if :local_db != 'ORC2.EXAMPLE.COM' then
--
-- HR_REPG: Propagate "EMPLOYEES" from local queue to ORC2
--
dbms_streams_adm.add_table_propagation_rules(
table_name => '"HR"."EMPLOYEES"',
streams_name => '&PROP_ORC2',
source_queue_name => :local_queue_owner || '.' || :local_queue,
destination_queue_name => '&QUEUE_OWNER_ORC2' ||
'.' || '&QUEUE_ORC2' ||
'@ORC2.EXAMPLE.COM',
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => :local_db);
end if;
end;
/

begin
if :local_db != 'ORC2.EXAMPLE.COM' then
--
-- HR_REPG: Propagate "JOBS" from local queue to ORC2
--
dbms_streams_adm.add_table_propagation_rules(
table_name => '"HR"."JOBS"',
streams_name => '&PROP_ORC2',
source_queue_name => :local_queue_owner || '.' || :local_queue,
destination_queue_name => '&QUEUE_OWNER_ORC2' ||
'.' || '&QUEUE_ORC2' ||
'@ORC2.EXAMPLE.COM',
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => :local_db);
end if;
end;
/

begin
if :local_db != 'ORC2.EXAMPLE.COM' then
--
-- HR_REPG: Propagate "JOB_HISTORY" from local queue to ORC2
--
dbms_streams_adm.add_table_propagation_rules(
table_name => '"HR"."JOB_HISTORY"',
streams_name => '&PROP_ORC2',
source_queue_name => :local_queue_owner || '.' || :local_queue,
destination_queue_name => '&QUEUE_OWNER_ORC2' ||
'.' || '&QUEUE_ORC2' ||
'@ORC2.EXAMPLE.COM',
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => :local_db);
end if;
end;
/

begin
if :local_db != 'ORC2.EXAMPLE.COM' then
--
-- HR_REPG: Propagate "LOCATIONS" from local queue to ORC2
--
dbms_streams_adm.add_table_propagation_rules(
table_name => '"HR"."LOCATIONS"',
streams_name => '&PROP_ORC2',
source_queue_name => :local_queue_owner || '.' || :local_queue,
destination_queue_name => '&QUEUE_OWNER_ORC2' ||
'.' || '&QUEUE_ORC2' ||
'@ORC2.EXAMPLE.COM',
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => :local_db);
end if;
end;
/

begin
if :local_db != 'ORC2.EXAMPLE.COM' then
--
-- HR_REPG: Propagate "REGIONS" from local queue to ORC2
--
dbms_streams_adm.add_table_propagation_rules(
table_name => '"HR"."REGIONS"',
streams_name => '&PROP_ORC2',
source_queue_name => :local_queue_owner || '.' || :local_queue,
destination_queue_name => '&QUEUE_OWNER_ORC2' ||
'.' || '&QUEUE_ORC2' ||
'@ORC2.EXAMPLE.COM',
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => :local_db);
end if;
end;
/

--
-- Propagation from local queue to ORC3.EXAMPLE.COM
--
begin
if :local_db != 'ORC3.EXAMPLE.COM' then
--
-- HR_REPG: Propagate "COUNTRIES" from local queue to ORC3
--
dbms_streams_adm.add_table_propagation_rules(
table_name => '"HR"."COUNTRIES"',
streams_name => '&PROP_ORC3',
source_queue_name => :local_queue_owner || '.' || :local_queue,
destination_queue_name => '&QUEUE_OWNER_ORC3' ||
'.' || '&QUEUE_ORC3' ||
'@ORC3.EXAMPLE.COM',
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => :local_db);
end if;
end;
/

begin
if :local_db != 'ORC3.EXAMPLE.COM' then
--
-- HR_REPG: Propagate "DEPARTMENTS" from local queue to ORC3
--
dbms_streams_adm.add_table_propagation_rules(
table_name => '"HR"."DEPARTMENTS"',
streams_name => '&PROP_ORC3',
source_queue_name => :local_queue_owner || '.' || :local_queue,
destination_queue_name => '&QUEUE_OWNER_ORC3' ||
'.' || '&QUEUE_ORC3' ||
'@ORC3.EXAMPLE.COM',
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => :local_db);
end if;
end;
/

begin
if :local_db != 'ORC3.EXAMPLE.COM' then
--
-- HR_REPG: Propagate "EMPLOYEES" from local queue to ORC3
--
dbms_streams_adm.add_table_propagation_rules(
table_name => '"HR"."EMPLOYEES"',
streams_name => '&PROP_ORC3',
source_queue_name => :local_queue_owner || '.' || :local_queue,
destination_queue_name => '&QUEUE_OWNER_ORC3' ||
'.' || '&QUEUE_ORC3' ||
'@ORC3.EXAMPLE.COM',
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => :local_db);
end if;
end;
/

begin
if :local_db != 'ORC3.EXAMPLE.COM' then
--
-- HR_REPG: Propagate "JOBS" from local queue to ORC3
--
dbms_streams_adm.add_table_propagation_rules(
table_name => '"HR"."JOBS"',
streams_name => '&PROP_ORC3',
source_queue_name => :local_queue_owner || '.' || :local_queue,
destination_queue_name => '&QUEUE_OWNER_ORC3' ||
'.' || '&QUEUE_ORC3' ||
'@ORC3.EXAMPLE.COM',
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => :local_db);
end if;
end;
/

begin
if :local_db != 'ORC3.EXAMPLE.COM' then
--
-- HR_REPG: Propagate "JOB_HISTORY" from local queue to ORC3
--
dbms_streams_adm.add_table_propagation_rules(
table_name => '"HR"."JOB_HISTORY"',
streams_name => '&PROP_ORC3',
source_queue_name => :local_queue_owner || '.' || :local_queue,
destination_queue_name => '&QUEUE_OWNER_ORC3' ||
'.' || '&QUEUE_ORC3' ||
'@ORC3.EXAMPLE.COM',
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => :local_db);
end if;
end;
/

begin
if :local_db != 'ORC3.EXAMPLE.COM' then
--
-- HR_REPG: Propagate "LOCATIONS" from local queue to ORC3
--
dbms_streams_adm.add_table_propagation_rules(
table_name => '"HR"."LOCATIONS"',
streams_name => '&PROP_ORC3',
source_queue_name => :local_queue_owner || '.' || :local_queue,
destination_queue_name => '&QUEUE_OWNER_ORC3' ||
'.' || '&QUEUE_ORC3' ||
'@ORC3.EXAMPLE.COM',
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => :local_db);
end if;
end;
/

begin
if :local_db != 'ORC3.EXAMPLE.COM' then
--
-- HR_REPG: Propagate "REGIONS" from local queue to ORC3
--
dbms_streams_adm.add_table_propagation_rules(
table_name => '"HR"."REGIONS"',
streams_name => '&PROP_ORC3',
source_queue_name => :local_queue_owner || '.' || :local_queue,
destination_queue_name => '&QUEUE_OWNER_ORC3' ||
'.' || '&QUEUE_ORC3' ||
'@ORC3.EXAMPLE.COM',
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => :local_db);
end if;
end;
/

-------------------------------
-- Setup Capture
-------------------------------
begin
--
-- HR_REPG : Add "COUNTRIES"
--
dbms_streams_adm.add_table_rules(
table_name => '"HR"."COUNTRIES"',
streams_type => 'CAPTURE',
streams_name => '&CAPTURE_NAME',
queue_name => :local_queue_owner || '.' || :local_queue,
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => :local_db);
end;
/

begin
--
-- HR_REPG : Add "DEPARTMENTS"
--
dbms_streams_adm.add_table_rules(
table_name => '"HR"."DEPARTMENTS"',
streams_type => 'CAPTURE',
streams_name => '&CAPTURE_NAME',
queue_name => :local_queue_owner || '.' || :local_queue,
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => :local_db);
end;
/

begin
--
-- HR_REPG : Add "EMPLOYEES"
--
dbms_streams_adm.add_table_rules(
table_name => '"HR"."EMPLOYEES"',
streams_type => 'CAPTURE',
streams_name => '&CAPTURE_NAME',
queue_name => :local_queue_owner || '.' || :local_queue,
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => :local_db);
end;
/

begin
--
-- HR_REPG : Add "JOBS"
--
dbms_streams_adm.add_table_rules(
table_name => '"HR"."JOBS"',
streams_type => 'CAPTURE',
streams_name => '&CAPTURE_NAME',
queue_name => :local_queue_owner || '.' || :local_queue,
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => :local_db);
end;
/

begin
--
-- HR_REPG : Add "JOB_HISTORY"
--
dbms_streams_adm.add_table_rules(
table_name => '"HR"."JOB_HISTORY"',
streams_type => 'CAPTURE',
streams_name => '&CAPTURE_NAME',
queue_name => :local_queue_owner || '.' || :local_queue,
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => :local_db);
end;
/

begin
--
-- HR_REPG : Add "LOCATIONS"
--
dbms_streams_adm.add_table_rules(
table_name => '"HR"."LOCATIONS"',
streams_type => 'CAPTURE',
streams_name => '&CAPTURE_NAME',
queue_name => :local_queue_owner || '.' || :local_queue,
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => :local_db);
end;
/

begin
--
-- HR_REPG : Add "REGIONS"
--
dbms_streams_adm.add_table_rules(
table_name => '"HR"."REGIONS"',
streams_type => 'CAPTURE',
streams_name => '&CAPTURE_NAME',
queue_name => :local_queue_owner || '.' || :local_queue,
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => :local_db);
end;
/

-------------------------------
-- Setup Apply
-------------------------------
--
-- Setup Apply from ORC1.EXAMPLE.COM
--

begin
--
-- HR_REPG : Add "COUNTRIES" to apply rules for apply from
-- ORC1.EXAMPLE.COM
--
if(:local_db != 'ORC1.EXAMPLE.COM') then
dbms_streams_adm.add_table_rules(
table_name => '"HR"."COUNTRIES"',
streams_type => 'APPLY',
streams_name => '&APPLY_ORC1',
queue_name => :local_queue_owner || '.' || :local_queue,
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => 'ORC1.EXAMPLE.COM');
end if;
end;
/

begin
--
-- HR_REPG : Add "DEPARTMENTS" to apply rules for apply from
-- ORC1.EXAMPLE.COM
--
if(:local_db != 'ORC1.EXAMPLE.COM') then
dbms_streams_adm.add_table_rules(
table_name => '"HR"."DEPARTMENTS"',
streams_type => 'APPLY',
streams_name => '&APPLY_ORC1',
queue_name => :local_queue_owner || '.' || :local_queue,
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => 'ORC1.EXAMPLE.COM');
end if;
end;
/

begin
--
-- HR_REPG : Add "EMPLOYEES" to apply rules for apply from
-- ORC1.EXAMPLE.COM
--
if(:local_db != 'ORC1.EXAMPLE.COM') then
dbms_streams_adm.add_table_rules(
table_name => '"HR"."EMPLOYEES"',
streams_type => 'APPLY',
streams_name => '&APPLY_ORC1',
queue_name => :local_queue_owner || '.' || :local_queue,
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => 'ORC1.EXAMPLE.COM');
end if;
end;
/

begin
--
-- HR_REPG : Add "JOBS" to apply rules for apply from
-- ORC1.EXAMPLE.COM
--
if(:local_db != 'ORC1.EXAMPLE.COM') then
dbms_streams_adm.add_table_rules(
table_name => '"HR"."JOBS"',
streams_type => 'APPLY',
streams_name => '&APPLY_ORC1',
queue_name => :local_queue_owner || '.' || :local_queue,
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => 'ORC1.EXAMPLE.COM');
end if;
end;
/

begin
--
-- HR_REPG : Add "JOB_HISTORY" to apply rules for apply from
-- ORC1.EXAMPLE.COM
--
if(:local_db != 'ORC1.EXAMPLE.COM') then
dbms_streams_adm.add_table_rules(
table_name => '"HR"."JOB_HISTORY"',
streams_type => 'APPLY',
streams_name => '&APPLY_ORC1',
queue_name => :local_queue_owner || '.' || :local_queue,
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => 'ORC1.EXAMPLE.COM');
end if;
end;
/

begin
--
-- HR_REPG : Add "LOCATIONS" to apply rules for apply from
-- ORC1.EXAMPLE.COM
--
if(:local_db != 'ORC1.EXAMPLE.COM') then
dbms_streams_adm.add_table_rules(
table_name => '"HR"."LOCATIONS"',
streams_type => 'APPLY',
streams_name => '&APPLY_ORC1',
queue_name => :local_queue_owner || '.' || :local_queue,
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => 'ORC1.EXAMPLE.COM');
end if;
end;
/

begin
--
-- HR_REPG : Add "REGIONS" to apply rules for apply from
-- ORC1.EXAMPLE.COM
--
if(:local_db != 'ORC1.EXAMPLE.COM') then
dbms_streams_adm.add_table_rules(
table_name => '"HR"."REGIONS"',
streams_type => 'APPLY',
streams_name => '&APPLY_ORC1',
queue_name => :local_queue_owner || '.' || :local_queue,
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => 'ORC1.EXAMPLE.COM');
end if;
end;
/

--
-- Setup Apply from ORC2.EXAMPLE.COM
--

begin
--
-- HR_REPG : Add "COUNTRIES" to apply rules for apply from
-- ORC2.EXAMPLE.COM
--
if(:local_db != 'ORC2.EXAMPLE.COM') then
dbms_streams_adm.add_table_rules(
table_name => '"HR"."COUNTRIES"',
streams_type => 'APPLY',
streams_name => '&APPLY_ORC2',
queue_name => :local_queue_owner || '.' || :local_queue,
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => 'ORC2.EXAMPLE.COM');
end if;
end;
/

begin
--
-- HR_REPG : Add "DEPARTMENTS" to apply rules for apply from
-- ORC2.EXAMPLE.COM
--
if(:local_db != 'ORC2.EXAMPLE.COM') then
dbms_streams_adm.add_table_rules(
table_name => '"HR"."DEPARTMENTS"',
streams_type => 'APPLY',
streams_name => '&APPLY_ORC2',
queue_name => :local_queue_owner || '.' || :local_queue,
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => 'ORC2.EXAMPLE.COM');
end if;
end;
/

begin
--
-- HR_REPG : Add "EMPLOYEES" to apply rules for apply from
-- ORC2.EXAMPLE.COM
--
if(:local_db != 'ORC2.EXAMPLE.COM') then
dbms_streams_adm.add_table_rules(
table_name => '"HR"."EMPLOYEES"',
streams_type => 'APPLY',
streams_name => '&APPLY_ORC2',
queue_name => :local_queue_owner || '.' || :local_queue,
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => 'ORC2.EXAMPLE.COM');
end if;
end;
/

begin
--
-- HR_REPG : Add "JOBS" to apply rules for apply from
-- ORC2.EXAMPLE.COM
--
if(:local_db != 'ORC2.EXAMPLE.COM') then
dbms_streams_adm.add_table_rules(
table_name => '"HR"."JOBS"',
streams_type => 'APPLY',
streams_name => '&APPLY_ORC2',
queue_name => :local_queue_owner || '.' || :local_queue,
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => 'ORC2.EXAMPLE.COM');
end if;
end;
/

begin
--
-- HR_REPG : Add "JOB_HISTORY" to apply rules for apply from
-- ORC2.EXAMPLE.COM
--
if(:local_db != 'ORC2.EXAMPLE.COM') then
dbms_streams_adm.add_table_rules(
table_name => '"HR"."JOB_HISTORY"',
streams_type => 'APPLY',
streams_name => '&APPLY_ORC2',
queue_name => :local_queue_owner || '.' || :local_queue,
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => 'ORC2.EXAMPLE.COM');
end if;
end;
/

begin
--
-- HR_REPG : Add "LOCATIONS" to apply rules for apply from
-- ORC2.EXAMPLE.COM
--
if(:local_db != 'ORC2.EXAMPLE.COM') then
dbms_streams_adm.add_table_rules(
table_name => '"HR"."LOCATIONS"',
streams_type => 'APPLY',
streams_name => '&APPLY_ORC2',
queue_name => :local_queue_owner || '.' || :local_queue,
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => 'ORC2.EXAMPLE.COM');
end if;
end;
/

begin
--
-- HR_REPG : Add "REGIONS" to apply rules for apply from
-- ORC2.EXAMPLE.COM
--
if(:local_db != 'ORC2.EXAMPLE.COM') then
dbms_streams_adm.add_table_rules(
table_name => '"HR"."REGIONS"',
streams_type => 'APPLY',
streams_name => '&APPLY_ORC2',
queue_name => :local_queue_owner || '.' || :local_queue,
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => 'ORC2.EXAMPLE.COM');
end if;
end;
/

--
-- Setup Apply from ORC3.EXAMPLE.COM
--

begin
--
-- HR_REPG : Add "COUNTRIES" to apply rules for apply from
-- ORC3.EXAMPLE.COM
--
if(:local_db != 'ORC3.EXAMPLE.COM') then
dbms_streams_adm.add_table_rules(
table_name => '"HR"."COUNTRIES"',
streams_type => 'APPLY',
streams_name => '&APPLY_ORC3',
queue_name => :local_queue_owner || '.' || :local_queue,
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => 'ORC3.EXAMPLE.COM');
end if;
end;
/

begin
--
-- HR_REPG : Add "DEPARTMENTS" to apply rules for apply from
-- ORC3.EXAMPLE.COM
--
if(:local_db != 'ORC3.EXAMPLE.COM') then
dbms_streams_adm.add_table_rules(
table_name => '"HR"."DEPARTMENTS"',
streams_type => 'APPLY',
streams_name => '&APPLY_ORC3',
queue_name => :local_queue_owner || '.' || :local_queue,
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => 'ORC3.EXAMPLE.COM');
end if;
end;
/

begin
--
-- HR_REPG : Add "EMPLOYEES" to apply rules for apply from
-- ORC3.EXAMPLE.COM
--
if(:local_db != 'ORC3.EXAMPLE.COM') then
dbms_streams_adm.add_table_rules(
table_name => '"HR"."EMPLOYEES"',
streams_type => 'APPLY',
streams_name => '&APPLY_ORC3',
queue_name => :local_queue_owner || '.' || :local_queue,
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => 'ORC3.EXAMPLE.COM');
end if;
end;
/

begin
--
-- HR_REPG : Add "JOBS" to apply rules for apply from
-- ORC3.EXAMPLE.COM
--
if(:local_db != 'ORC3.EXAMPLE.COM') then
dbms_streams_adm.add_table_rules(
table_name => '"HR"."JOBS"',
streams_type => 'APPLY',
streams_name => '&APPLY_ORC3',
queue_name => :local_queue_owner || '.' || :local_queue,
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => 'ORC3.EXAMPLE.COM');
end if;
end;
/

begin
--
-- HR_REPG : Add "JOB_HISTORY" to apply rules for apply from
-- ORC3.EXAMPLE.COM
--
if(:local_db != 'ORC3.EXAMPLE.COM') then
dbms_streams_adm.add_table_rules(
table_name => '"HR"."JOB_HISTORY"',
streams_type => 'APPLY',
streams_name => '&APPLY_ORC3',
queue_name => :local_queue_owner || '.' || :local_queue,
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => 'ORC3.EXAMPLE.COM');
end if;
end;
/

begin
--
-- HR_REPG : Add "LOCATIONS" to apply rules for apply from
-- ORC3.EXAMPLE.COM
--
if(:local_db != 'ORC3.EXAMPLE.COM') then
dbms_streams_adm.add_table_rules(
table_name => '"HR"."LOCATIONS"',
streams_type => 'APPLY',
streams_name => '&APPLY_ORC3',
queue_name => :local_queue_owner || '.' || :local_queue,
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => 'ORC3.EXAMPLE.COM');
end if;
end;
/

begin
--
-- HR_REPG : Add "REGIONS" to apply rules for apply from
-- ORC3.EXAMPLE.COM
--
if(:local_db != 'ORC3.EXAMPLE.COM') then
dbms_streams_adm.add_table_rules(
table_name => '"HR"."REGIONS"',
streams_type => 'APPLY',
streams_name => '&APPLY_ORC3',
queue_name => :local_queue_owner || '.' || :local_queue,
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => 'ORC3.EXAMPLE.COM');
end if;
end;
/

-------------------------------
-- Add Supplemental Log Groups
-------------------------------
--
-- ** NOTE ** --
-- The primary key columns must be supplementally logged.
--
alter database add supplemental log data (primary key) columns;

--
-- ** NOTE ** --
-- The unique key columns must be supplementally logged.
--
alter database add supplemental log data (unique index) columns;

--
-- ** NOTE ** --
-- All the columns in a column group that is assigned an Oracle Streams
-- supported update conflict handler must be supplementally logged.
--

-- Supplementally log columns in column group 'COUNTRIES_TIMESTAMP_CG'
-- that is assigned the LATEST TIMESTAMP update conflict resolution method.
alter table "HR"."COUNTRIES" add supplemental log group COUNTRIES_LogGrp1 (
"COUNTRY_NAME"
,"REGION_ID"
,"TIMESTAMP"
);

-------------------------------
-- Setup Conflict Resolution
-------------------------------
--
-- ** WARNING ** --
-- Oracle Streams does not support LATEST TIMESTAMP
-- conflict resolution method.
-- Changing LATEST TIMESTAMP to MAXIMUM as
-- they handle the conflicts in a similar manner.
--
declare
cols dbms_utility.name_array;
begin
cols(1) := 'COUNTRY_NAME';
cols(2) := 'REGION_ID';
cols(3) := 'TIMESTAMP';
dbms_apply_adm.set_update_conflict_handler(
object_name => 'HR.COUNTRIES',
method_name => 'MAXIMUM',
resolution_column => 'TIMESTAMP',
column_list => cols);
end;
/

-------------------------------
-- Verify Oracle Streams Setup
-------------------------------

-- Verify creation of queues
select * from dba_queues
where name = upper(:local_queue)
and owner = upper(:local_queue_owner)
and queue_table = upper(:local_queue_table)
order by name;

-- Verify creation of capture_process
select * from dba_capture
where capture_name = upper('&CAPTURE_NAME');

-- Verify creation of apply processes
select * from dba_apply
where apply_name IN (
upper('&APPLY_ORC1'),
upper('&APPLY_ORC2'),
upper('&APPLY_ORC3') )
order by apply_name;

-- Verify propagation processes
select * from dba_propagation
where propagation_name IN (
upper('&PROP_ORC1'),
upper('&PROP_ORC2'),
upper('&PROP_ORC3') )
order by propagation_name;

-- Verify Oracle Streams rules
select * from dba_streams_table_rules
where streams_name = upper('&CAPTURE_NAME');

select * from dba_streams_table_rules
where streams_name IN (
upper('&APPLY_ORC1'),
upper('&APPLY_ORC2'),
upper('&APPLY_ORC3') )
order by source_database;

select * from dba_streams_table_rules
where streams_name IN (
upper('&PROP_ORC1'),
upper('&PROP_ORC2'),
upper('&PROP_ORC3') )
order by source_database;

-- Do not resume Repcat activity once Oracle Streams is set up.
-- Drop all the repgroups that have been migrated to Oracle Streams.
-- Start apply and capture processes at all sites.

索引
A  B  C  D  E  F  G  H  I  L  M  N  O  P  Q  R  S  T  U  V  X

A

ABORT_GLOBAL_INSTANTIATIONプロシージャ, 8.2.5

ABORT_SCHEMA_INSTANTIATIONプロシージャ, 8.2.5

ABORT_SYNC_INSTANTIATIONプロシージャ, 8.2.5

ABORT_TABLE_INSTANTIATIONプロシージャ, 8.2.5

ADD SUPPLEMENTAL LOG, 1.3.6.2

ADD SUPPLEMENTAL LOG DATA, 1.3.6.3

ALTER DATABASEのADD SUPPLEMENTAL LOG DATA句, 1.3.6.5

ALTER TABLEのADD SUPPLEMENTAL LOG GROUP句

条件付きログ・グループ, 1.3.6.3

無条件ログ・グループ, 1.3.6.2

アラート・ログ

Streamsベスト・プラクティス, 15.2.6

ALTER DATABASE文

ADD SUPPLEMENTAL LOG DATA句, 1.3.6.5

DROP SUPPLEMENTAL LOG DATA句, 1.3.6.6

ALTER TABLE文

ADD SUPPLEMENTAL LOG DATA句

条件付きログ・グループ, 1.3.6.3

無条件ログ・グループ, 1.3.6.2

ADD SUPPLEMENTAL LOG GROUP句

条件付きログ・グループ, 1.3.6.3

無条件ログ・グループ, 1.3.6.2

DROP SUPPLEMENTAL LOG GROUP句, 1.3.6.4 ALTER_APPLYプロシージャ

タグ値の削除, 10.6.2.2

タグ値の設定, 10.1, 10.4, 10.6.2.1

ANYDATAデータ型

キュー

作成, 6.1

適用プロセス

適用ハンドラ, 1.2.5

適用ユーザー

ベスト・プラクティス, 18.1.1

ベスト・プラクティス

構成, 18.2

操作, 18.3

競合解消, 9 作成, 7.1 適用されるデータ型

異機種間環境, 11.1.2.2

DML変更

異機種間環境, 11.1.2.3

DMLハンドラ

異機種間環境, 11.1.2.1.5

エラー・ハンドラ

異機種間, 11.1.2.1.7

エラー

ベスト・プラクティス, 18.2.2, 18.3.1

異機種間環境, 11.1.2, 11.2.3

データベース・リンク, 11.1.2.1.1

Oracle Database Gateway, 11.1.2.1.1

LOB, 14.4.1 メッセージ・ハンドラ

異機種間環境, 11.1.2.1.6

最も古いSCN

Point-in-Timeリカバリ, 12.6.3

並列性

ベスト・プラクティス, 18.2.1

代替キー列

異機種間環境, 11.1.2.1.3, 11.1.2.1.4, 11.1.2.1.5, 11.1.2.1.6, 11.1.2.1.7

タグ, 10.4

監視, 10.7.2

削除, 10.6.2.2

設定, 10.6.2.1

更新の競合ハンドラ

監視, 9.8.2

ARCHIVELOGモード, 1.3.3

取得プロセス, 5.1.1

B

バックアップ

オンライン

Streams, 10.3

Streamsベスト・プラクティス, 15.2.4 バッチ処理

取得プロセスのベスト・プラクティス, 16.2.3

ベスト・プラクティス

Streamsレプリケーション, 14.5

アラート・ログ, 15.2.6

適用, 18

適用エラー, 18.2.2, 18.3.1

適用プロセスの構成, 18.2

適用プロセスの操作, 18.3

適用プロセスの並列性, 18.2.1

適用ユーザー, 18.1.1

アーカイブ・ログ・スレッド, 15.3.1

自動化構成, 15.1.2

バックアップ, 15.2.4

バッチ処理, 16.2.3

取得, 16

取得プロセス・キュー, 15.2.3

取得プロセスの構成, 16.1

取得プロセスの操作, 16.2

取得プロセスの並列性, 16.1.2

取得ユーザー, 16.1.1

チェックポイント保存, 16.1.3

競合解消, 18.1.3

データ・ディクショナリの構築, 16.2.2

データベース構成, 15.1

データベース操作, 15.2

DDLレプリケーション, 1.2.6

宛先データベース, 18.1

グローバル名, 15.2.1

ハートビート表, 16.2.1

インスタンス化SCN, 18.1.2

Oracle Real Application Clusters(Oracle RAC)データベース, 15.3

パフォーマンス, 15.2.2

インスタンス化のための準備, 16.2.2

伝播, 17

伝播待機時間, 17.1.2

キュー・ツー・キュー伝播, 17.1.1

削除, 15.2.7

伝播の再起動, 17.2.1

SDU, 17.1.3

統計収集, 15.2.5

同期取得の構成, 16.3

双方向のレプリケーション, 1.2.3, 1.2.7

C

取得プロセス

ARCHIVELOGモード, 5.1.1

ベスト・プラクティス

バッチ処理, 16.2.3

構成, 16.1

データ・ディクショナリの構築, 16.2.2

操作, 16.2

インスタンス化のための準備, 16.2.2

取得ユーザー

ベスト・プラクティス, 16.1.1

構成, 5 作成, 5.1 DBID, 5.1

変更, 12.4

ダウンストリーム取得, 1.2.2, 2.2.2.1

作成, 5.1

グローバル名, 5.1

変更, 12.4

異機種間環境, 11.1.1 ローカル取得, 1.2.2, 2.2.2.1 ログ順序番号

リセット, 12.6.1

並列性

ベスト・プラクティス, 16.1.2

パラメータ

merge_threshold, 12.3.2.1

message_tracking_frequency, 12.2

split_threshold, 12.3.2.1

準備, 5.1.1 サプリメンタル・ロギング, 1.3.6, 8.2.3 変更の循環

回避

タグ, 10.5

チェックポイント保存

ベスト・プラクティス, 16.1.3

列リスト, 9.6.1.2 COMPAREファンクション, 13.5

perform_row_difパラメータ, 13.5.2

COMPARE_OLD_VALUESプロシージャ, 9.4.1, 9.7.4 データベース・オブジェクトの比較, 13.5 COMPATIBLE初期化パラメータ, 1.3.4 競合解消, 9

ベスト・プラクティス, 18.1.3

列リスト, 9.6.1.2

競合ハンドラ, 9.3, 9.4, 9.5, 9.6

カスタム, 9.6.2

変更, 9.7.2

ビルトイン, 9.6.1

削除, 9.7.3

設定, 9.7.1

データ収束, 9.6.1.4 DISCARDハンドラ, 9.6.1.1.2 MAXIMUMハンドラ, 9.6.1.1.3

最新時刻, 9.6.1.1.3

MINIMUMハンドラ, 9.6.1.1.4 OVERWRITEハンドラ, 9.6.1.1.1 解消列, 9.6.1.3 時間ベース, 9.6.1.1.3 競合

回避, 9.5

削除, 9.5.2.2

プライマリ・データベースの所有権, 9.5.1

順序, 9.5.2.1

一意性, 9.5.2.1

更新, 9.5.2.3

削除, 9.2.3 検出, 9.4

行の識別, 9.4.2

監視, 9.8.1

停止, 9.4.1, 9.7.4

DMLの競合, 9.1 外部キー, 9.2.4 トランザクションの順序付け, 9.3 タイプ, 9.2 一意性, 9.2.2 更新, 9.2.1, 9.2.2, 9.2.3, 9.2.4 CONVERGEプロシージャ, 13.7 CREATE_APPLYプロシージャ, 7.1

タグ, 10.1, 10.4

CREATE_CAPTUREプロシージャ, 5.1, 5.1.2.2 CREATE_COMPARISONプロシージャ, 13.5 CREATE_PROPAGATIONプロシージャ, 6.2 CREATE_SYNC_CAPTUREプロシージャ, 5.2.3

D

データ

比較, 13.5

カスタム, 13.5.5

循環, 13.5.4

結果の削除, 13.9

ランダム, 13.5.3

再確認, 13.8

列のサブセット, 13.5.1

収束, 13.7

セッション・タグ, 13.7.3

データ型

異機種間環境, 11.1.2.2

データベース・リンク, 1.3.2 データベース

レプリケーションへの追加, 4.2.2, 4.3.2, 4.3.4

DBA_APPLYビュー, 10.7.2 DBA_APPLY_CONFLICT_COLUMNSビュー, 9.8.2 DBA_APPLY_INSTANTIATED_OBJECTSビュー, 8.6.2 DBA_APPLY_TABLE_COLUMNSビュー, 9.8.1 DBA_CAPTURE_PREPARED_DATABASEビュー, 8.6.1 DBA_CAPTURE_PREPARED_SCHEMASビュー, 8.6.1 DBA_CAPTURE_PREPARED_TABLESビュー, 8.6.1 DBA_COMPARISONビュー, 13.6, 13.6.5, 13.6.6 DBA_COMPARISON_COLUMNSビュー, 13.6.3 DBA_COMPARISON_SCANビュー, 13.6.4, 13.6.5, 13.6.6 DBA_COMPARISON_SCAN_VALUESビュー, 13.6.7 DBA_RECOVERABLE_SCRIPTビュー, 12.8 DBA_RECOVERABLE_SCRIPT_BLOCKSビュー, 12.8 DBA_RECOVERABLE_SCRIPT_ERRORSビュー, 12.8 DBA_RECOVERABLE_SCRIPT_PARAMSビュー, 12.8 DBA_SYNC_CAPTURE_PREPARED_TABSビュー, 8.6.1 DBID(データベース識別子)

取得プロセス, 5.1

変更, 12.4

DBMS_CAPTURE_ADMパッケージ, 5 DBMS_COMPARISONパッケージ

バケット, 13.1.2

データベース・オブジェクトの比較, 13.5

カスタム, 13.5.5

循環, 13.5.4

結果の削除, 13.9

ランダム, 13.5.3

再確認, 13.8

列のサブセット, 13.5.1

データベース・オブジェクトの収束, 13.7

セッション・タグ, 13.7.3

監視, 13.6 親スキャン, 13.1.3 準備, 13.3 ルート・スキャン, 13.1.3 スキャン, 13.1.1 Streamsレプリケーション, 13.11 使用, 13 DBMS_PROPAGATION_ADMパッケージ, 6 DBMS_STREAMSパッケージ, 10.6 DBMS_STREAMS_ADMパッケージ, 1.1.2, 5, 6

取得プロセスの作成, 5.1

伝播の作成, 6.2

適用プロセスの作成, 7.1

インスタンス化のための準備, 8.2.1

タグ, 10.2

DDLレプリケーション

ベスト・プラクティス, 1.2.6

ディレクトリ・オブジェクト, 2.2.3

作成, 4.2.2

DISCARD競合解消ハンドラ, 9.6.1.1.2 DMLハンドラ

LOBアセンブリ, 14.4.2

ダウンストリーム取得, 1.2.2, 2.2.2.1

アーカイブ・ログ, 1.2.2

構成, 2.2.5

ログ・ファイルの転送, 1.3.7

リアルタイム, 1.2.2, 1.3.8

スタンバイREDOログ, 1.3.8

ALTER DATABASEのDROP SUPPLEMENTAL LOG DATA句, 1.3.6.6 DROP SUPPLEMENTAL LOG GROUP句, 1.3.6.4 DROP_COMPARISONプロシージャ, 13.10

E

ENQUEUEプロシージャ, 14.2

エラー・ハンドラ

LOBアセンブリ, 14.4.2

エラー・キュー

異機種間環境, 11.1.5

エクスポート

Oracle Streams, 8.5.1

F

フラッシュバック問合せ

Streamsレプリケーション, 12.7

G

GET_MESSAGE_TRACKINGファンクション, 12.2

GET_SCN_MAPPINGプロシージャ, 12.6.2, 12.7

GET_TAGファンクション, 10.6.1.2, 10.7.1

グローバル名

ベスト・プラクティス, 15.2.1

取得プロセス, 5.1

変更, 12.4

GLOBAL_NAMES初期化パラメータ, 1.3.4 GRANT_REMOTE_ADMIN_ACCESSプロシージャ, 5.1.3.1, 5.1.3.2.1

H

ハートビート表

Streamsベスト・プラクティス, 16.2.1

異機種間での情報の共有, 11

Oracle以外からOracle以外へ, 11.3

Oracle以外からOracleへ, 11.2

適用プロセス, 11.2.3

変更の取得, 11.2.1

インスタンス化, 11.2.4

ユーザー・アプリケーション, 11.2.1

OracleからOracle以外へ, 11.1

適用プロセス, 11.1.2

取得プロセス, 11.1.1

適用されるデータ型, 11.1.2.2

データベース・リンク, 11.1.2.1.1

DML変更, 11.1.2.3

DMLハンドラ, 11.1.2.1.5

エラー・ハンドラ, 11.1.2.1.7

エラー, 11.1.5

インスタンス化, 11.1.2.4

メッセージ・ハンドラ, 11.1.2.1.6

ステ－ジング, 11.1.1

代替キー列, 11.1.2.1.3, 11.1.2.1.4, 11.1.2.1.5, 11.1.2.1.6, 11.1.2.1.7

変換, 11.1.3

ハブ・アンド・スポーク・レプリケーション, 1.2.3, 1.2.7, 10.5.2

構成, 2.2.6

I

インポート

Oracle Streams, 8.5.1

STREAMS_CONFIGURATIONパラメータ, 8.3.2.3

初期化パラメータ

COMPATIBLE, 1.3.4

GLOBAL_NAMES, 1.3.4

LOG_ARCHIVE_CONFIG, 1.3.4

LOG_ARCHIVE_DEST_n, 1.3.4

LOG_ARCHIVE_DEST_STATE_n, 1.3.4

LOG_BUFFER, 1.3.4

MEMORY_MAX_TARGET, 1.3.4

MEMORY_TARGET, 1.3.4

OPEN_LINKS, 1.3.4

PROCESSES, 1.3.4

SESSIONS, 1.3.4

SGA_MAX_SIZE, 1.3.4

SGA_TARGET, 1.3.4

SHARED_POOL_SIZE, 1.3.4

STREAMS_POOL_SIZE, 1.3.4

TIMED_STATISTICS, 1.3.4

UNDO_RETENTION, 1.3.4

インスタンス化, 2.2.2.6, 8

準備の強制終了, 8.2.5

データ・ポンプ, 8.3

データベース, 8.4.2

例

データ・ポンプ・エクスポート/インポート, 8.3.3

RMAN CONVERT DATABASE, 8.4.2.2

RMAN DUPLICATE, 8.4.2.1

RMAN TRANSPORT TABLESPACE, 8.4.1

トランスポータブル表領域, 8.4.1

異機種間環境

Oracle以外からOracleへ, 11.2.4

OracleからOracle以外へ, 11.1.2.4

監視, 8.6 Oracle Streams, 8.5.1 準備, 8.2 準備, 8.1, 8.2.4 RMAN, 8.4 SCNの設定, 8.5

DDL LCR, 8.5.2

エクスポート/インポート, 8.5.1

サプリメンタル・ロギング指定, 8.1 インスタンス化SCN

ベスト・プラクティス, 18.1.2

L

LCR。「論理変更レコード」を参照

LOBアセンブリ, 14.4.2

LOB

Oracle Streams, 14.4

適用プロセス, 14.4.1

ログ順序番号

Streams取得プロセス, 12.6.1

LOG_ARCHIVE_CONFIG初期化パラメータ, 1.3.4 LOG_ARCHIVE_DEST_n初期化パラメータ, 1.3.4 LOG_ARCHIVE_DEST_STATE_n初期化パラメータ, 1.3.4 LOG_BUFFER初期化パラメータ, 1.3.4 論理変更レコード(LCR)

構成, 14.2

エンキュー, 14.2

実行, 14.3

DDL LCR, 14.3.2

行LCR, 14.3.1

LOB列, 14.4, 14.5

適用プロセス, 14.4.1

要件, 14.4.3

LONG列, 14.5

要件, 14.5

LONG RAW列, 14.5

要件, 14.5

管理, 14 要件, 14.1 追跡, 12.2 XMLType, 14.4 LONGデータ型

Oracle Streams, 14.5

LONG RAWデータ型

Oracle, 14.5

M

MAINTAIN_GLOBALプロシージャ, 2.2, 2.2.4.1

MAINTAIN_SCHEMASプロシージャ, 2.2, 2.2.4.2, 2.2.5.2, 2.2.5.3, 2.2.6

MAINTAIN_SIMPLE_TTSプロシージャ, 2.2, 2.2.5.1, 2.2.5.1

MAINTAIN_TABLESプロシージャ, 2.2, 2.2.4.3

MAINTAIN_TTSプロシージャ, 2.2, 2.2.5.1, 2.2.5.1

MAXIMUM競合解消ハンドラ, 9.6.1.1.3

最新時刻, 9.6.1.1.3

MEMORY_MAX_TARGET初期化パラメータ, 1.3.4, 1.3.5.1 MEMORY_TARGET初期化パラメータ, 1.3.4, 1.3.5.1 ストリームのマージ, 12.3 MERGE_STREAMSプロシージャ, 12.3.2.2 MERGE_STREAMS_JOBプロシージャ, 12.3.2.2 メッセージの追跡, 12.2, 12.2 message_tracking_frequency取得プロセス・パラメータ, 12.2 MINIMUM競合解消ハンドラ, 9.6.1.1.4 監視

適用プロセス

更新の競合ハンドラ, 9.8.2

比較, 13.6 競合検出, 9.8.1 インスタンス化, 8.6 タグ, 10.7

適用プロセスの値, 10.7.2

現行セッションの値, 10.7.1

N

n-wayレプリケーション, 1.2.3, 1.2.7, 10.5.1

O

オブジェクト

レプリケーションへの追加, 4.2.1, 4.3.1, 4.3.3

最も古いSCN

Point-in-Timeリカバリ, 12.6.3

一方向のレプリケーション, 1.2.7 OPEN_LINKS初期化パラメータ, 1.3.4 オプティマイザ

統計収集

ベスト・プラクティス, 15.2.5

Oracle Data Pump

Importユーティリティ

STREAMS_CONFIGURATIONパラメータ, 8.3.2.3

インスタンス化, 8.3.3 Streamsのインスタンス化, 8.3 Oracle Database Gateway

Oracle Streams, 11.1.2.1.1

Oracle Real Application Clusters

Streamsベスト・プラクティス, 15.3

アーカイブ・ログ・スレッド, 15.3.1

グローバル名, 15.3.2

伝播, 15.3.3

キュー所有権, 15.3.4

Oracle Streams

競合解消, 9

DBMS_COMPARISONパッケージ, 13.11

エクスポート・ユーティリティ, 8.5.1

異機種間での情報の共有, 11

インポート・ユーティリティ, 8.5.1

インスタンス化, 8.1, 8.5.1

LOB, 14.4

論理変更レコード(LCR)

管理, 14

LONGデータ型, 14.5 アドバンスト・レプリケーションからの移行, A Oracle Database Gateway, 11.1.2.1.1 Point-in-Timeリカバリ, 12.6 レプリケーション, 1

データベースの追加, 4.2.2, 4.3.2, 4.3.4

オブジェクトの追加, 4.2.1, 4.3.1, 4.3.3

追加, 4

ベスト・プラクティス, 14.5

構成, 2, 3

管理, 12

順序, 9.5.2.1

ルール, 1.1.2 順序, 9.5.2.1 タグ, 10 XMLType, 14.4 Oracle Streamsパフォーマンス・アドバイザ, 15.2.2 OVERWRITE競合解消ハンドラ, 9.6.1.1.1

P

パフォーマンス

Oracle Streams, 15.2.2

Point-in-Timeリカバリ

Oracle Streams, 12.6

POST_INSTANTIATION_SETUPプロシージャ, 2.2, 2.2.4.1, 2.2.5.1, 2.2.5.1 PRE_INSTANTIATION_SETUPプロシージャ, 2.2, 2.2.4.1, 2.2.5.1, 2.2.5.1 PREPARE_GLOBAL_INSTANTIATIONプロシージャ, 8.2, 8.2.4 PREPARE_SCHEMA_INSTANTIATIONプロシージャ, 8.2, 8.2.4 PREPARE_SYNC_INSTANTIATIONプロシージャ, 8.2, 8.2.4 PREPARE_TABLE_INSTANTIATIONプロシージャ, 8.2, 8.2.4 PROCESSES初期化パラメータ, 1.3.4 伝播

ベスト・プラクティス, 17

故障した伝播, 17.2.1

構成, 17.1

伝播待機時間, 17.1.2

伝播の操作, 17.2

キュー・ツー・キュー伝播, 17.1.1

伝播の再起動, 17.2.1

SDU, 17.1.3

伝播ジョブ

管理, 6.2

伝播

作成, 6, 6.2

管理, 6.2

PURGE_COMPARISONプロシージャ, 13.9

Q

キュー

ANYDATA

作成, 6.1

コミット時間, 11.2.2 作成, 6 サイズ

ベスト・プラクティス, 15.2.3

トランザクション, 11.2.2 キュー・ツー・キュー伝播

ベスト・プラクティス, 17.1.1

R

RECHECKファンクション, 13.8

RECOVER_OPERATIONプロシージャ, 12.8

Recovery Manager

CONVERT DATABASEコマンド

Streamsのインスタンス化, 8.4.2.2

DUPLICATEコマンド

Streamsのインスタンス化, 8.4.2.1

Streamsのインスタンス化, 8.4 TRANSPORT TABLESPACEコマンド

Streamsのインスタンス化, 8.4.1

レプリケーション

データベースの追加, 4.2.2, 4.3.2, 4.3.4

オブジェクトの追加, 4.2.1, 4.3.1, 4.3.3

追加, 4

双方向, 1.2.1, 2.2.2.4

構成エラー

リカバリ, 12.8

構成, 2, 3

適用ハンドラ, 1.2.5

ARCHIVELOGモード, 1.3.3

双方向, 1.2.3, 1.2.7

データベース, 2.2.4.1

データベース・リンク, 1.3.2

DBMS_STREAMS_ADMパッケージ, 2.2

DDL変更, 1.2.6, 2.2.2.5

ディレクトリ・オブジェクト, 2.2.3

ダウンストリーム取得, 1.2.2, 2.2.2.1, 2.2.5

Enterprise Manager, 2.1

ハブ・アンド・スポーク, 1.2.3, 1.2.7, 2.2.6

初期化パラメータ, 1.3.4

インスタンス化, 2.2.2.6

ローカル取得, 1.2.2, 2.2.2.1

ログ・ファイルの転送, 1.3.7

複数ソース環境, 3.2

n-way, 1.2.3, 1.2.7

一方向, 1.2.7

Oracle Streamsプール, 1.3.5

準備, 1

スキーマ, 2.2.4.2, 2.2.5.2, 2.2.5.3, 2.2.6

スクリプト, 2.2.2.2

単一ソース環境, 3.1

スタンバイREDOログ, 1.3.8

サプリメンタル・ロギング, 1.3.6

表, 2.2.4.3

表領域, 2.2.5.1

表領域, 2.2.5.1

タグ, 2.2.2.4.1

ハブ・アンド・スポーク, 1.2.1, 10.5.2 管理, 12 Streamsへの移行, A n-way, 1.2.1, 10.5.1 一方向, 1.2.1, 2.2.2.4 Oracle Streams, 1

ベスト・プラクティス, 14.5

管理, 12

順序, 9.5.2.1 分割およびマージ, 12.3 解消列, 9.6.1.3 ルールベースの変換, 1.2.4 ルール, 1.1.2

システム作成

タグ, 10.2

S

SDU

Streamsベスト・プラクティス, 17.1.3

順序, 9.5.2.1

レプリケーション, 9.5.2.1

SESSIONS初期化パラメータ, 1.3.4 SET_DML_HANDLERプロシージャ, 9.6.2 SET_GLOBAL_INSTANTIATION_SCNプロシージャ, 8.5, 8.5.2 SET_MESSAGE_TRACKINGプロシージャ, 12.2 SET_SCHEMA_INSTANTIATION_SCNプロシージャ, 8.5, 8.5.2 SET_TABLE_INSTANTIATION_SCNプロシージャ, 8.5 SET_TAGプロシージャ, 10.1, 10.6.1.1 SET_UP_QUEUEプロシージャ, 6.1 SET_UPDATE_CONFLICT_HANDLERプロシージャ, 9.6.1

更新の競合ハンドラの変更, 9.7.2

更新の競合ハンドラの削除, 9.7.3

更新の競合ハンドラの設定, 9.7.1

SGA_MAX_SIZE初期化パラメータ, 1.3.4 SGA_TARGET初期化パラメータ, 1.3.4, 1.3.5.2 SHARED_POOL_SIZE初期化パラメータ, 1.3.4 ストリームの分割, 12.3 SPLIT_STREAMSプロシージャ, 12.3.2.2 ステージング

異機種間環境, 11.1.1

統計

Oracle Streams, 15.2.2

Streamsプール

MEMORY_MAX_TARGET初期化パラメータ, 1.3.5.1

MEMORY_TARGET初期化パラメータ, 1.3.5.1

SGA_TARGET初期化パラメータ, 1.3.5.2

STREAMS_CONFIGURATIONパラメータ

データ・ポンプ・インポート・ユーティリティ, 8.3.2.3

インポート・ユーティリティ, 8.3.2.3

STREAMS_MIGRATIONプロシージャ, A STREAMS_POOL_SIZE初期化パラメータ, 1.3.4 STRMMON, 15.2.2 サプリメンタル・ロギング, 1.3.6

列リスト, 9.6.1.2

インスタンス化, 8.1

インスタンス化のための準備, 8.2.3, 8.2.4

同期取得

ベスト・プラクティス

構成, 16.3

構成, 5.2 準備, 5.2.1 システム変更番号(SCN)

適用プロセスの最も古いSCN

Point-in-Timeリカバリ, 12.6.3

T

タグ, 2.2.2.4.1, 10

ALTER_APPLYプロシージャ, 10.1, 10.4

適用プロセス, 10.4

変更の循環

回避, 10.5

CONVERGEプロシージャ, 13.7.3 CREATE_APPLYプロシージャ, 10.1, 10.4 例, 10.5 現行セッションの値の取得, 10.6.1.2 ハブ・アンド・スポーク・レプリケーション, 10.5 管理, 10.6 監視, 10.7

適用プロセスの値, 10.7.2

現行セッションの値, 10.7.1

n-wayレプリケーション, 10.5 オンライン・バックアップ, 10.3 適用プロセスの値の削除, 10.6.2.2 ルール, 10.2

include_tagged_lcrパラメータ, 10.2

SET_TAGプロシージャ, 10.1 適用プロセス用の値の設定, 10.6.2.1 現行セッション用の値の設定, 10.6.1.1 TIMED_STATISTICS初期化パラメータ, 1.3.4 LCRの追跡, 12.2 変換

異機種間環境

OracleからOracle以外へ, 11.1.3

ルールベース, 1.2.4, 1.2.4 トランスポータブル表領域

Streamsのインスタンス化, 8.4.1

U

UNDO_RETENTION初期化パラメータ, 1.3.4

V

V$STREAMS_MESSAGE_TRACKINGビュー, 12.2

V$STREAMS_POOL_ADVICEビュー, 1.3.5.3

V$STREAMS_TRANSACTIONビュー, 8.2.4

X

XMLType

論理変更レコード(LCR), 14.4

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2013, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

制限付権利

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション（人的傷害を発生させる可能性があるアプリケーションを含む）への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。