Oracle® Streams

概要および管理

11gリリース2 (11.2)

B61351-03(原本部品番号:E17069-08)

2013年6月

Oracle Streams概要および管理 11g リリース2 (11.2)

B61351-03

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

原本著者:  Randy Urbano

原本協力者:  Sundeep Abraham、Geeta Arora、Nimar Arora、Lance Ashdown、Ram Avudaiappan、Neerja Bhatt、Ragamayi Bhyravabhotla、Chipper Brown、Jack Chung、Alan Downing、Jacco Draaijer、Curt Elsbernd、Yong Feng、Jairaj Galagali、Lei Gao、Connie Green、Richard Huang、Thuvan Hoang、Lewis Kaplan、Joydip Kundu、Tianshu Li、Jing Liu、Edwina Lu、Raghu Mani、Rui Mao、Pat McElroy、Shailendra Mishra、Valarie Moore、Bhagat Nainani、Srikanth Nalla、Maria Pratt、Arvind Rajaram、Ashish Ray、Abhishek Saxena、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、Ying 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の登録商標です。

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

目次

図一覧

表一覧

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

はじめに

- 対象読者

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

- 関連ドキュメント

- 表記規則

Oracle Streamsの新機能

- Oracle Database 11g リリース2(11.2)のOracle Streamsの新機能

- Oracle Database 11g リリース1(11.1)のOracle Streamsの新機能

第I部 Oracle Streamsの基本概念

1 Oracle Streamsの概要

- Oracle Streamsの概要

- Oracle Streamsの機能

- データベースでのメッセージの取得

- キューへのメッセージのステージング

- キュー間でのメッセージの伝播

- メッセージのコンシューム

- 競合の検出と解決

- メッセージの変換

- Oracle Streamsタグの付いたメッセージの追跡

- Oracle以外のデータベースとの情報の共有

- Oracle Streamsの用途

- データ・レプリケーション

- データ・ウェアハウスのロード

- アップグレードおよびメンテナンス操作時のデータベースの可用性

- メッセージ・キューイング

- イベントの管理および通知

- データ保護

- Oracle Streams構成の例

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

- ダウンストリーム取得によるレプリケーション構成の例

- 同期取得によるレプリケーション構成の例

- N-Wayレプリケーション構成の例

- 単一データベースで取得および適用を実行する構成の例

- メッセージ構成の例

- Oracle Streamsのドキュメント・ロードマップ

- Oracle Streamsの概要に関するドキュメント

- Oracle Streams環境の設定または拡張に関するドキュメント

- Oracle Streams環境の管理に関するドキュメント

- Oracle Streams環境の監視に関するドキュメント

- Oracle Streamsを使用したアップグレードおよびメンテナンスに関するドキュメント

2 Oracle Streams情報取得

- Oracle Streamsで情報を取得する方法

- 暗黙的取得

- 取得プロセス

- 同期取得

- 明示的取得

- Oracle Streamsで取得される情報のタイプ

- 論理変更レコード(LCR)

- 行LCR

- DDL LCR

- LCRのその他の情報

- ユーザー・メッセージ

- Oracle Streamsでの情報取得オプションのまとめ

- Oracle Streams環境でのインスタンス化

- Oracle Streams取得プロセスによる暗黙的取得

- 取得プロセスの概要

- 取得プロセスのルール

- 取得プロセスによって取得されるデータ型

- 取得プロセスによって取得されるDML変更のタイプ

- Oracle Streams環境内のサプリメンタル・ロギング

- ローカル取得およびダウンストリーム取得

- ローカル取得

- ダウンストリーム取得

- 取得プロセスに関連するSCN値

- 取得済SCNおよび適用済SCN

- 先頭SCNおよび開始SCN

- Oracle Streamsの取得プロセスおよびRESTRICTED SESSION

- 取得プロセスのサブコンポーネント

- 取得ユーザー

- 取得プロセスの状態

- 取得プロセス・パラメータ

- データベースの再起動時における取得プロセスの永続的状態

- 同期取得による暗黙的取得

- 同期取得の概要

- 同期取得およびキュー

- 同期取得のルール

- 同期取得によって取得されるデータ型

- 同期取得によって取得されるDML変更のタイプ

- 同期取得の取得ユーザー

- 単一データベースでの複数の同期取得

- アプリケーションによる明示的取得

- 明示的にエンキューできるメッセージのタイプ

- ユーザー・メッセージ

- 論理変更レコード(LCR)とメッセージ

- エンキュー機能

3 Oracle Streamsのステージングと伝播

- メッセージのステージングと伝播の概要

- キュー

- ANYDATAキューおよび型付きキュー

- 永続キューとバッファ・キュー

- キューおよびOracle Streamsクライアント

- キュー間でのメッセージの伝播

- 伝播ルール

- キュー・ツー・キュー伝播

- 保証付きのメッセージ配信

- 有向ネットワーク

- キューによる転送と適用による転送

4 Oracle Streams情報コンシューム

- Oracle Streamsでの情報コンシュームの概要

- Oracle Streamsで情報をコンシュームする方法

- 暗黙的コンシューム

- 明示的コンシューム

- Oracle Streamsでコンシュームされる情報のタイプ

- 取得LCR

- 永続LCR

- バッファLCR

- 永続ユーザー・メッセージ

- バッファ・ユーザー・メッセージ

- 情報コンシューム・オプションのまとめ

- 適用プロセスによる暗黙的コンシューム

- 適用プロセスの概要

- 適用プロセスのルール

- 適用プロセスで処理できるメッセージのタイプ

- 適用プロセスのメッセージ処理オプション

- DMLハンドラ

- エラー・ハンドラ

- DDLハンドラ

- メッセージ・ハンドラ

- プリコミット・ハンドラ

- 適用ハンドラに関する考慮事項

- メッセージ処理オプションのまとめ

- 適用プロセスによって適用されるメッセージのソース

- 適用されるデータ型

- 適用時の自動データ型変換

- 適用時の文字データ型の自動トリミング

- 自動変換とLOBデータ型

- SQL生成

- SQL生成を実行するためのインタフェース

- SQL生成のフォーマット

- SQL生成およびデータ型

- SQL生成およびキャラクタ・セット

- 生成されたSQL文の例

- Oracle Streamsの適用プロセスおよびRESTRICTED SESSION

- 適用プロセスのサブコンポーネント

- リーダー・サーバーの状態

- コーディネータ・プロセスの状態

- 適用サーバーの状態

- 適用ユーザー

- 適用プロセス・パラメータ

- データベースの再起動時における適用プロセスの永続的状態

- エラー・キュー

- メッセージ・クライアントによる明示的コンシューム

- 手動デキューによる明示的コンシューム

5 Oracle Streamsでのルールの使用方法

- Oracle Streamsでのルールの使用方法の概要

- ルール・セットおよびメッセージのルール評価

- Oracle Streamsクライアントにルール・セットが存在しない場合

- Oracle Streamsクライアントにポジティブ・ルール・セットのみが存在する場合

- Oracle Streamsクライアントにネガティブ・ルール・セットのみが存在する場合

- Oracle Streamsクライアントにポジティブ・ルール・セットとネガティブ・ルール・セットの両方が存在する場合

- Oracle Streamsクライアントに空のルール・セットが1つ以上存在する場合

- ルール・セットとOracle Streamsクライアントの動作のまとめ

- システム作成ルール

- グローバル・ルール

- グローバル・ルールの例

- システム作成グローバル・ルールによる空のルール条件の自動回避

- スキーマ・ルール

- スキーマ・ルールの例

- 表ルール

- 表ルールの例

- サブセット・ルール

- サブセット・ルールの例

- 行の移行およびサブセット・ルール

- サブセット・ルールとサプリメンタル・ロギング

- サブセット・ルールを使用する際のガイドライン

- メッセージ・ルール

- メッセージ・ルールの例

- システム作成ルールとネガティブ・ルール・セット

- ネガティブ・ルール・セットの例

- システム作成ルールへのユーザー定義条件の追加

6 ルールベースの変換

- 宣言ルールベースの変換

- カスタム・ルールベースの変換

- カスタム・ルールベースの変換およびアクション・コンテキスト

- カスタム・ルールベースの変換に必須の権限

- ルールベースの変換およびOracle Streamsクライアント

- ルールベースの変換と取得プロセス

- 取得プロセスによる取得中のルールベース変換のエラー

- ルールベースの変換と同期取得

- 同期取得による取得中のルールベースの変換のエラー

- ルールベースの変換と伝播

- 伝播中のルールベース変換のエラー

- ルールベースの変換と適用プロセス

- 適用プロセスによるデキュー中のルールベースの変換のエラー

- 変換済メッセージの適用エラー

- ルールベースの変換とメッセージ・クライアント

- メッセージ・クライアントによるデキュー中のルールベースの変換のエラー

- 複数のルールベース変換

- 変換の順序

- 宣言ルールベースの変換の順序

- 宣言ルールベースの変換のデフォルトの順序

- 宣言ルールベースの変換のユーザー指定の順序

- ルールベースの変換に関する考慮事項

第II部 Oracle Streamsの高度な概念

7 取得プロセスの高度な概念

- 単一データベースでの複数の取得プロセス

- 取得プロセスのチェックポイント

- 必須チェックポイントSCN

- 最大チェックポイントSCN

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

- 新しい先頭SCN値および消去されたLogMinerデータ・ディクショナリ情報

- ARCHIVELOGモードおよび取得プロセス

- 取得プロセスの作成

- 取得プロセスのLogMinerデータ・ディクショナリ

- 取得プロセスに対するLogMinerデータ・ディクショナリの必要性を示す使用例

- 同じソース・データベースに対する複数の取得プロセス

- Oracle Streamsデータ・ディクショナリ

- 取得プロセス・ルールの評価

8 キューの高度な概念

- 保護キュー

- 保護キューおよびSET_UP_QUEUEプロシージャ

- 保護キューおよびOracle Streamsクライアント

- トランザクション・キューと非トランザクション・キュー

- コミット時間キュー

- コミット時間キューを使用する場合

- デキュー時のトランザクション間の依存性による順序付け

- キュー内のメッセージの一貫性のある参照

- コミット時間キューの仕組み

9 伝播の高度な概念

- 伝播ジョブ

- 伝播のスケジューリングとOracle Streams伝播

- 伝播ジョブとRESTRICTED SESSION

- 伝播用のOracle Streamsデータ・ディクショナリ

- バイナリ・ファイルの伝播

10 適用プロセスの高度な概念

- 適用プロセスの作成

- 適用プロセスおよび依存性

- 依存トランザクションが適用される仕組み

- 適用時の行LCRの順序付け

- 依存性および制約

- 依存性検出、ルールベースの変換および適用ハンドラ

- 仮想依存性定義

- 値の依存性

- オブジェクトの依存性

- バリア・トランザクション

- 表へのDML変更の適用に関する考慮事項

- 制約と表に対するDML変更の適用

- 代替キー列

- 列の不一致に対する適用プロセスの動作

- 宛先データベースの列の欠落

- 宛先データベースの余分な列

- 列のデータ型の不一致

- 競合解決と適用プロセス

- ハンドラと行LCRの処理

- 関連ハンドラがない場合

- 関連する更新の競合ハンドラがある場合

- DMLハンドラはあるが関連する更新の競合ハンドラがない場合

- DMLハンドラおよび関連する更新の競合ハンドラがある場合

- 文DMLハンドラおよびプロシージャDMLハンドラがある場合

- エラー・ハンドラはあるが関連する更新の競合ハンドラがない場合

- エラー・ハンドラおよび関連する更新の競合ハンドラがある場合

- 文DMLハンドラおよび関連するエラー・ハンドラがある場合

- 文DMLハンドラ、エラー・ハンドラおよび関連する更新の競合ハンドラがある場合

- DDL変更を適用するときの考慮事項

- システム生成名

- CREATE TABLE AS SELECT文

- DDL文内のDML文

- DDL文に導出値が含まれている場合

- DDL文によってDMLトリガーが起動される場合

- 適用プロセスのインスタンス化SCNと非処理SCN

- 適用プロセスの最も古いSCN

- 適用プロセスの最低水位標と最高水位標

- 適用プロセスおよびトリガー

- トリガー起動プロパティ

- 適用プロセスとON SCHEMA句で作成したトリガー

- 適用プロセス用のOracle Streamsデータ・ディクショナリ

- 単一データベースでの複数の適用プロセス

11 ルールの高度な概念

- ルールのコンポーネント

- ルール条件

- ルール条件内の変数

- 単純ルール条件

- ルール評価コンテキスト

- 明示的変数と暗黙的変数

- 評価コンテキストとルール・セットおよびルールとの関連付け

- 評価ファンクション

- ルール・アクション・コンテキスト

- ルール・セットの評価

- ルール・セットの評価プロセス

- 部分評価

- ルールに関連するデータベース・オブジェクトと権限

- ルール関連のデータベース・オブジェクトを作成するための権限

- ルール関連のデータベース・オブジェクトを変更するための権限

- ルール関連のデータベース・オブジェクトを削除するための権限

- ルール・セットにルールを含めるための権限

- ルール・セットを評価するための権限

- 評価コンテキストを使用するための権限

- Oracle Streamsで使用される評価コンテキスト

- グローバル・ルール、スキーマ・ルール、表ルールおよびサブセット・ルールの評価コンテキスト

- メッセージ・ルールの評価コンテキスト

- Oracle Streamsおよびイベント・コンテキスト

- Oracle Streamsおよびアクション・コンテキスト

- Oracle Streamsにおけるアクション・コンテキストの用途

- サブセット・ルールでの内部LCR変換

- 宣言ルールベースの変換に関する情報

- カスタム・ルールベースの変換

- 適用時のメッセージの実行ディレクティブ

- 適用時のメッセージのエンキューの宛先

- 特定のルール条件についてTRUEと評価できるルールが1つのみであることの確認

- スキーマ・ルールおよびグローバル・ルールに関するアクション・コンテキストの考慮事項

- ユーザー作成ルール、ルール・セットおよび評価コンテキスト

- ユーザー作成ルールとルール・セット

- 特定タイプの操作に関するルール条件

- サポートされていないLCRを廃棄するようにOracle Streamsクライアントに指示するルール条件

- 複合ルール条件

- NULLと評価される未定義変数を伴うルール条件

- ルール条件のファンクション・パラメータとしての変数

- ユーザー作成評価コンテキスト

12 取得と適用の複合による最適化

- 取得と適用の複合による最適化について

- 取得と適用の複合の要件

- 取得と適用の複合の使用方法

- 取得と適用の複合が使用されているかどうかの判断方法

- 取得と適用の複合およびPoint-in-Timeリカバリ

13 Oracle Streams高可用性環境

- Oracle Streams高可用性環境の概要

- 障害からの保護

- Oracle Streamsレプリカ・データベース

- レプリカ・データベースの更新

- 異機種間プラットフォームのサポート

- 複数キャラクタ・セット

- オンラインREDOログのマイニングによる待機時間の最小化

- 高速フェイルオーバー

- 複数宛先への単一の取得

- Oracle Streamsを使用しない場合

- アプリケーションによるコピーのメンテナンス

- Oracle Streams高可用性環境のベスト・プラクティス

- 高可用性のためのOracle Streamsの構成

- データベースとその他の各データベースとの直接接続

- ハブ・アンド・スポーク構成の作成

- Oracle Streamsの取得プロセスを使用したローカル取得またはダウンストリーム取得

- 障害からのリカバリ

- フェイルオーバー後の取得プロセスの自動的な再起動

- フェイルオーバー後のデータベース・リンクの再確立

- フェイルオーバー後の伝播ジョブの再起動

- フェイルオーバー後の適用プロセスの自動的な再起動

第III部 Oracle Streamsの管理

14 Oracle Streamsの管理の概要

- Oracle提供のPL/SQLパッケージ

- DBMS_APPLY_ADMパッケージ

- DBMS_CAPTURE_ADMパッケージ

- DBMS_COMPARISONパッケージ

- DBMS_PROPAGATION_ADMパッケージ

- DBMS_RULEパッケージ

- DBMS_RULE_ADMパッケージ

- DBMS_STREAMSパッケージ

- DBMS_STREAMS_ADMパッケージ

- DBMS_STREAMS_ADVISOR_ADMパッケージ

- DBMS_STREAMS_AUTHパッケージ

- DBMS_STREAMS_HANDLER_ADMパッケージ

- DBMS_STREAMS_MESSAGINGパッケージ

- DBMS_STREAMS_TABLESPACE_ADMパッケージ

- UTL_SPADVパッケージ

- Oracle Streamsのデータ・ディクショナリ・ビュー

- Oracle Enterprise ManagerのOracle Streamsツール

15 Oracle Streams暗黙的取得の管理

- 取得プロセスの管理

- 取得プロセスの起動

- 取得プロセスの停止

- 取得プロセスのルール・セットの管理

- 取得プロセスのルール・セットの指定

- 取得プロセスのルール・セットへのルールの追加

- 取得プロセスのルール・セットからのルールの削除

- 取得プロセスのルール・セットの削除

- 取得プロセス・パラメータの設定

- 取得プロセスの取得ユーザーの設定

- 取得プロセスのチェックポイント保存時間の管理

- 新しい値の取得プロセスのチェックポイント保存時間の設定

- 無期限の取得プロセスのチェックポイント保存時間の設定

- 取得プロセスへのアーカイブREDOログ・ファイルの明示的な追加

- 既存の取得プロセスの先頭SCNの設定

- 既存の取得プロセスの開始SCNの設定

- ダウンストリーム取得でデータベース・リンクを使用するかどうかの指定

- 取得プロセスの削除

- 同期取得の管理

- 同期取得のルール・セットの管理

- 同期取得のルール・セットの指定

- 同期取得のルール・セットへのルールの追加

- 同期取得のルール・セットからのルールの削除

- 同期取得の取得ユーザーの設定

- 同期取得の削除

- 取得LCRの追加属性の管理

- 暗黙的に取得されたLCRへの追加属性の包含

- 暗黙的に取得されたLCRからの追加属性の排除

- 取得プロセスから同期取得への切替え

- 同期取得から取得プロセスへの切替え

16 ステージングと伝播の管理

- キューの管理

- 保護キューでのユーザー操作の有効化

- 保護キューでのユーザー操作の無効化

- キューの削除

- Oracle Streamsの伝播および伝播ジョブの管理

- 伝播の開始

- 伝播の停止

- 伝播ジョブのスケジュールの変更

- キュー・ツー・キュー伝播の伝播ジョブのスケジュール変更

- キュー・ツーdblink伝播の伝播ジョブのスケジュール変更

- 伝播のルール・セットの指定

- 伝播のポジティブ・ルール・セットの指定

- 伝播のネガティブ・ルール・セットの指定

- 伝播のルール・セットへのルールの追加

- 伝播のポジティブ・ルール・セットへのルールの追加

- 伝播のネガティブ・ルール・セットへのルールの追加

- 伝播のルール・セットからのルールの削除

- 伝播のルール・セットの削除

- 伝播の削除

17 Oracle Streams情報コンシュームの管理

- 適用プロセスの起動

- 適用プロセスの停止

- 適用プロセスのルール・セットの管理

- 適用プロセスのルール・セットの指定

- 適用プロセスのポジティブ・ルール・セットの指定

- 適用プロセスのネガティブ・ルール・セットの指定

- 適用プロセスのルール・セットへのルールの追加

- 適用プロセスのポジティブ・ルール・セットへのルールの追加

- 適用プロセスのネガティブ・ルール・セットへのルールの追加

- 適用プロセスのルール・セットからのルールの削除

- 適用プロセスのルール・セットの削除

- 適用プロセス・パラメータの設定

- 適用プロセスの適用ユーザーの設定

- DMLハンドラの管理

- 文DMLハンドラの管理

- 文DMLハンドラの作成および適用プロセスへの追加

- 文DMLハンドラへの文の追加

- 文DMLハンドラ内の文の変更

- 文DMLハンドラからの文の削除

- 適用プロセスからの文DMLハンドラの削除

- 文DMLハンドラの削除

- プロシージャDMLハンドラの管理

- プロシージャDMLハンドラの作成

- プロシージャDMLハンドラの設定

- プロシージャDMLハンドラの設定解除

- DDLハンドラの管理

- 適用プロセスのDDLハンドラの作成

- 適用プロセスのDDLハンドラの設定

- 適用プロセスのDDLハンドラの削除

- 適用プロセスのメッセージ・ハンドラの管理

- 適用プロセスのメッセージ・ハンドラの設定

- 適用プロセスのメッセージ・ハンドラの設定解除

- 適用プロセスのプリコミット・ハンドラの管理

- 適用プロセスのプリコミット・ハンドラの作成

- 適用プロセスのプリコミット・ハンドラの設定

- 適用プロセスのプリコミット・ハンドラの設定解除

- 適用プロセスによるメッセージのエンキューの指定

- ルールを満たすメッセージの宛先キューの設定

- ルールの宛先キュー設定の削除

- 適用プロセスの実行ディレクティブの指定

- ルールを満たすメッセージの実行の回避の指定

- ルールを満たすメッセージの実行の指定

- エラー・ハンドラの管理

- エラー・ハンドラの作成

- エラー・ハンドラの設定

- エラー・ハンドラの設定解除

- 適用エラーの管理

- 適用エラー・トランザクションの再試行

- 特定の適用エラー・トランザクションの再試行

- 適用プロセスのすべてのエラー・トランザクションの再試行

- 適用エラー・トランザクションの削除

- 特定の適用エラー・トランザクションの削除

- 適用プロセスのすべてのエラー・トランザクションの削除

- 表の代替キー列の管理

- 表の代替キー列の設定

- 表の代替キー列の削除

- 仮想依存性定義の使用

- 値の依存性の設定および設定解除

- スキーマの相違および値の依存性

- 宛先データベースでの未定義の制約および値の依存性

- オブジェクト依存性の作成および削除

- オブジェクト依存性の作成

- オブジェクト依存性の削除

- 適用プロセスの削除

18 ルールの管理

- ルール・セットの管理

- ルール・セットの作成

- ルール・セットへのルールの追加

- ルール・セットからのルールの削除

- ルール・セットの削除

- ルールの管理

- ルールの作成

- アクション・コンテキストを持たないルールの作成

- アクション・コンテキストを持つルールの作成

- ルールの変更

- ルール条件の変更

- ルールのアクション・コンテキストの名前/値ペアの変更

- ルールのアクション・コンテキストへの名前/値ペアの追加

- ルールのアクション・コンテキストからの名前/値ペアの削除

- システム作成ルールの変更

- ルールの削除

- 評価コンテキスト、ルール・セットおよびルールに対する権限の管理

- 評価コンテキスト、ルール・セットおよびルールに対するシステム権限の付与

- 評価コンテキスト、ルール・セットまたはルールに対するオブジェクト権限の付与

- 評価コンテキスト、ルール・セットおよびルールに対するシステム権限の取消し

- 評価コンテキスト、ルール・セットまたはルールに対するオブジェクト権限の取消し

19 ルールベースの変換の管理

- 宣言ルールベースの変換の管理

- 宣言ルールベースの変換の追加

- 表名を変更する宣言ルールベースの変換の追加

- 列を追加する宣言ルールベースの変換の追加

- 既存の宣言ルールベースの変換の上書き

- 宣言ルールベースの変換の削除

- カスタム・ルールベース変換の管理

- カスタム・ルールベースの変換の作成

- カスタム・ルールベースの変換の変更

- カスタム・ルールベース変換の設定解除

20 Oracle Streamsを使用した表の変更の記録

- Oracle Streamsを使用した表の変更の記録について

- 表の変更を記録するOracle Streams環境の準備

- MAINTAIN_CHANGE_TABLEプロシージャを実行する前に行う決定

- 構成する環境のタイプの決定

- 追跡する列の決定

- 記録するメタデータの決定

- 更新操作に応じて追跡する値の決定

- KEEP_COLUMNS変換を構成するかどうかの決定

- チェンジ・テーブルに対してCREATE TABLEオプションを指定するかどうかの決定

- 構成アクションを直接実行するか、スクリプトで実行するかの決定

- ソース・テーブルをレプリケートするかどうかの決定

- MAINTAIN_CHANGE_TABLEプロシージャに関する前提条件

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

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

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

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

- Oracle Streamsプールの構成

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

- リアルタイム・ダウンストリーム取得に対するスタンバイREDOログの構成

- スクリプトを使用する場合に必要なディレクトリ・オブジェクトの構成

- 宛先データベースでのソース・テーブルのインスタンス化

- 表の変更を記録するOracle Streams環境の構成

- 1つのデータベースでのローカル取得とローカル適用を使用した表の変更の記録

- ローカル取得とリモート適用を使用した表の変更の記録およびレプリケーション

- ダウンストリーム取得とローカル適用を使用した表の変更の記録

- ダウンストリーム取得とリモート適用を使用した表の変更の記録

- 表の変更を記録するOracle Streams環境の管理

- 変更ハンドラの設定解除および設定

- 既存のOracle Streamsコンポーネントを使用した表の変更の記録

- チェンジ・テーブルのメンテナンス

- Oracle Streams環境の管理

- 表の変更を記録するOracle Streams環境の監視

- チェンジ・テーブルの監視

- 変更ハンドラの監視

- 変更ハンドラに関する一般情報の表示

- 変更ハンドラの対象となるチェンジ・テーブルとソース・テーブルの表示

- Oracle Streams環境の監視

21 その他のOracle Streams管理タスク

- Oracle Streams環境での全データベースのエクスポート/インポートの実行

- Oracle Streams構成の削除

第IV部 Oracle Streamsの監視

22 Oracle Streams環境の監視

- Oracle Streamsの静的データ・ディクショナリ・ビューの概要

- Oracle Streams動的パフォーマンス・ビューのサマリー

23 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環境でのデータベースの表示

- 各データベースでのOracle Streamsコンポーネントの表示

- Oracle Streamsのトポロジでの各ストリーム・パスの表示

- Oracle Streamsコンポーネントのパフォーマンス統計の表示

- Oracle Streamsのトポロジのボトルネック・コンポーネントのチェック

- コンポーネント・レベル統計の表示

- セッション・レベル統計の表示

- Oracle Streams環境でのストリーム・パスの統計の表示

- UTL_SPADVパッケージの使用

- UTL_SPADVパッケージを使用したOracle Streamsの統計の収集

- Oracle Streamsの監視ジョブが現在実行されているかどうかの確認

- Oracle Streamsの監視ジョブの変更

- Oracle Streamsの監視ジョブの停止

- UTL_SPADVパッケージを使用したOracle Streamsの統計の表示

24 Oracle Streams暗黙的取得の監視

- 取得プロセスの監視

- 各取得プロセスのキュー、ルール・セットおよび状態の表示

- 各取得プロセスに関するセッション情報の表示

- 各取得プロセスに関する変更取得情報の表示

- 各取得プロセスの状態変更およびメッセージ作成時刻の表示

- 各取得プロセスの取得操作の実行経過時間の表示

- 各ダウンストリーム取得プロセスに関する情報の表示

- 各取得プロセスの登録済REDOログ・ファイルの表示

- 各取得プロセスで必要なREDOログ・ファイルの表示

- 各取得プロセスで使用される各REDOログ・ファイルのSCN値の表示

- 各取得プロセスで使用可能な最後のアーカイブREDOエントリの表示

- 各取得プロセスのパラメータ設定の表示

- データベース内のすべての取得プロセスの適用済SCNの判別

- 各取得プロセスのREDOログのスキャン待機時間の判別

- 各取得プロセスのメッセージのエンキュー待機時間の判別

- 各取得プロセスのルールの評価に関する情報の表示

- 取得と適用の複合を使用する取得プロセスの判別

- 分割とマージ操作に関する情報の表示

- 元およびクローニングされたOracle Streamsコンポーネントの名前の表示

- 分割とマージ操作のアクションおよびしきい値の表示

- クローニングされた取得プロセスのタイム・ラグの表示

- 分割とマージ・ジョブに関する情報の表示

- 過去の分割とマージ操作に関する情報の表示

- サプリメンタル・ロギングの監視

- ソース・データベースでのサプリメンタル・ログ・グループの表示

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

- インスタンス化の準備中に指定されたサプリメンタル・ロギングの表示

- 同期取得の監視

- 各同期取得のキュー、ルール・セットおよび状態の表示

- 同期取得によって変更が取得される表の表示

- 暗黙的取得によって取得された追加属性の表示

25 Oracle Streamsのキューおよび伝播の監視

- キューおよびメッセージの監視

- データベース内のANYDATAキューの表示

- データベースでのメッセージ・クライアントの表示

- メッセージ通知の表示

- 永続キュー内の各メッセージのコンシューマの決定

- 永続キュー内のメッセージの内容の表示

- バッファ・キューの監視

- 各バッファ・キュー内のメッセージ数の決定

- 各バッファ・キュー内のLCRの取得プロセスの表示

- バッファ・メッセージを送信する伝播に関する情報の表示

- 伝播によって送信されたメッセージ数およびバイト数の表示

- バッファ・メッセージを送信する伝播のパフォーマンス統計の表示

- 各バッファ・キューからメッセージをデキューする伝播の表示

- バッファ・メッセージを受信する伝播のパフォーマンス統計の表示

- 各バッファ・キューからのメッセージをデキューする適用プロセスの表示

- Oracle Streamsの伝播および伝播ジョブの監視

- 各伝播のキューおよびデータベース・リンクの表示

- 各伝播のソース・キューと宛先キューの判断

- 各伝播のルール・セットの判断

- 伝播ジョブのスケジュールに関する情報の表示

- 伝播されたメッセージの合計数とバイト数の判断

- 伝播送信者に関する情報の表示

- 伝播受信者に関する情報の表示

- 各伝播に関するセッション情報の表示

26 Oracle Streams適用プロセスの監視

- 各適用プロセスのキュー、ルール・セットおよび状態の確認

- 各適用プロセスに関する一般情報の表示

- 各適用プロセスのパラメータ設定の表示

- 適用ハンドラの情報の表示

- DMLハンドラに関する情報の表示

- すべてのDMLハンドラに関する情報の表示

- 文DMLハンドラに関する情報の表示

- プロシージャDMLハンドラに関する情報の表示

- 各適用プロセスのDDLハンドラの表示

- ローカル適用プロセスのすべてのエラー・ハンドラの表示

- 各適用プロセスのメッセージ・ハンドラの表示

- 各適用プロセスのプリコミット・ハンドラの表示

- 各適用プロセスに関するセッション情報の表示

- 各適用プロセスのリーダー・サーバーに関する情報の表示

- 各適用プロセスによってオーバーフローしたトランザクションおよびメッセージの監視

- メッセージが取得されてからデキューされるまでの待機時間の確認

- 各コーディネータ・プロセスに関する一般情報の表示

- 受信および適用されたトランザクションに関する情報の表示

- 各適用プロセスのメッセージが取得されてから適用されるまでの待機時間の確認

- 待機時間に関するV$STREAMS_APPLY_COORDINATORの問合せの例

- 待機時間に関するDBA_APPLY_PROGRESSの問合せの例

- 各適用プロセスの適用サーバーに関する情報の表示

- 適用プロセスの有効な適用並列性の表示

- 適用時に宛先キューを指定するルールの表示

- 適用時に実行しないことを指定するルールの表示

- 取得と適用の複合を使用する適用プロセスの判別

- 宛先データベースで指定された代替キー列の表示

- 仮想依存性定義の監視

- 値の依存性の表示

- オブジェクト依存性の表示

- 適用エラーのチェック

- 適用エラーの詳細情報の表示

27 ルールの監視

- すべてのOracle Streamsクライアントによって使用される全ルールの表示

- 特定のOracle Streamsクライアントによって使用されるOracle Streamsルールの表示

- Oracle Streamsクライアント用のポジティブ・ルール・セット内のルールの表示

- Oracle Streamsクライアント用のネガティブ・ルール・セット内のルールの表示

- ルールの現行の条件の表示

- Oracle Streamsルール用に変更されたルール条件の表示

- 各ルール・セットの評価コンテキストの表示

- 評価コンテキストで使用される表に関する情報の表示

- 評価コンテキスト内で使用される変数に関する情報の表示

- ルール・セットの全ルールの表示

- ルール・セット内の各ルールの条件の表示

- 条件に指定パターンが含まれる各ルールのリスト表示

- すべてのルール・セット評価の総合統計の表示

- 各ルール・セットの評価に関する情報の表示

- 各ルール・セットの評価に使用されたリソースの判断

- ルールの評価統計の表示

28 ルールベースの変換の監視

- すべてのルールベースの変換に関する情報の表示

- 宣言ルールベースの変換の表示

- ADD COLUMN変換に関する情報の表示

- RENAME TABLE変換に関する情報の表示

- カスタム・ルールベースの変換の表示

29 その他のOracle Streamsコンポーネントの監視

- Oracle Streams管理者とその他のOracle Streamsユーザーの監視

- ローカルOracle Streams管理者の表示

- リモートOracle Streams管理者にアクセスを許可するユーザーの表示

- Oracle Streamsプールの監視

- Oracle Streamsプール・サイズの拡大が推奨される問合せ結果

- Oracle Streamsプール・サイズの保持が推奨される問合せ結果

- Oracle Streamsプール・サイズの縮小が推奨される問合せ結果

- Oracle Streams環境での互換性の監視

- 取得プロセスに対する互換性の監視

- 取得プロセスと互換性のないデータベース・オブジェクトの表示

- 最近取得プロセスとの互換性を持つようになったデータベース・オブジェクトの表示

- 同期取得と互換性のないデータベース・オブジェクトおよび列の表示

- 適用プロセスに対する互換性の監視

- 適用プロセスと互換性のないデータベース・オブジェクトおよび列の表示

- 最近適用プロセスとの互換性を持つようになった列の表示

- AWRおよびStatspackを使用したOracle Streamsのパフォーマンスの監視

第V部 Oracle Streams環境のトラブルシューティング

30 Oracle Streams環境内での問題の特定

- Oracle Streamsアラートの表示

- Streams構成レポートおよびヘルス・チェック・スクリプトの使用

- 使用不可能な宛先によるパフォーマンスの問題の処理

- トレース・ファイルとアラート・ログでの問題のチェック

- 取得プロセスのトレース・ファイルには、取得の問題に関するメッセージが含まれているか

- 伝播ジョブに関連するトレース・ファイルには、問題に関するメッセージが含まれているか

- 適用プロセスのトレース・ファイルには、適用の問題に関するメッセージが含まれているか

31 暗黙的取得のトラブルシューティング

- 取得プロセスの問題のトラブルシューティング

- 取得プロセスの作成またはデータ・ディクショナリのビルドに長時間を要していないか

- 取得プロセスが有効かどうか

- 取得プロセスでREDOを待機しているか

- 取得プロセスでフロー制御のために一時停止しているか

- 現行の取得プロセスかどうか

- 必須のREDOログ・ファイルが欠落していないか

- ダウンストリーム取得プロセスがREDOデータを待機していないか

- 不適切にダウンストリーム取得の構成を試行していないか

- 適切な認証を使用しないでダウンストリーム取得の構成を試行していないか

- データベース・リンクのないダウンストリーム取得に追加のアクションが必要か

- 同期取得に関する問題のトラブルシューティング

- 同期取得で表の変更の取得に失敗しないか

32 伝播のトラブルシューティング

- 伝播で適切なソース・キューと宛先キューが使用されているか

- 伝播が有効かどうか

- ANYDATAキューのセキュリティは適切に構成されているか

- ORA-24093: AQエージェントはデータベース・ユーザーの権限を付与されていません。

- ORA-25224: セキュア・キューにエンキューするために送信者名を指定する必要があります。

33 適用のトラブルシューティング

- 適用プロセスが有効かどうか

- 現行の適用プロセスかどうか

- 適用プロセスが取得LCRに適用されているか

- 適用プロセスのキューが適用するメッセージを受信しているか

- カスタム適用ハンドラが指定されているか

- AQ_TM_PROCESSES初期化パラメータが0に設定されているか

- 適用ユーザーに必要な権限があるか

- 適用プロセスで競合が発生しているか

- 適用プロセスで依存トランザクションを待機しているか

- 適用サーバーのパフォーマンスが特定のトランザクションに対して低いか

- エラー・キューに適用エラーがあるか

- DMLハンドラを使用したエラー・トランザクションの修正

- 特定の適用エラーのトラブルシューティング

- ORA-01031 権限が不足しています。

- ORA-01403 データが見つかりません。

- ORA-23605 Oracle Streamsパラメータの値が無効です

- ORA-23607 列は無効です。

- ORA-24031 値が無効です。parameter_nameにはNULLでない値が必要です。

- ORA-26687 インスタンス化SCNが指定されていません

- ORA-26688 LCRにキーがありません。

- ORA-26689 列データ型が一致していません

- ORA-26786 キーの行は存在しますが、競合する列が表にあります

- ORA-26787 キーcolumn_valueの行は表table_nameにありません

34 ルールおよびルールベースの変換のトラブルシューティング

- Oracle Streamsクライアントのルールが適切に構成されているか

- スキーマ・ルールおよびグローバル・ルールのチェック

- 表ルールのチェック

- サブセット・ルールのチェック

- メッセージ・ルールのチェック

- ルールに関する問題の解決

- 宣言ルールベースの変換が適切に構成されているか

- カスタム・ルールベースの変換が適切に構成されているか

- 誤って変換されたLCRがエラー・キューにないか

第VI部 Oracle Streamsの情報のプロビジョニング

35 情報のプロビジョニングの概要

- 情報のプロビジョニングの概要

- 大量の情報のバルク・プロビジョニング

- データ・ポンプ・エクスポート/インポート

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

- DBMS_STREAMS_TABLESPACE_ADMプロシージャ

- ファイル・グループ・リポジトリ

- 表領域リポジトリ

- エクスポート中に表領域が読取り専用である必要性

- 表領域のプラットフォームの自動変換

- 情報のバルク・プロビジョニングのオプション

- Oracle Streamを使用した情報の増分プロビジョニング

- オンデマンドでの情報へのアクセス

36 情報のプロビジョニングの使用

- 表領域リポジトリの使用

- 表領域リポジトリの作成および移入

- 共有ファイル・システムを使用したリモート・レポートに対する表領域リポジトリの使用

- 共有ファイル・システムを使用しないリモート・レポートに対する表領域リポジトリの使用

- ファイル・グループ・リポジトリの使用

37 ファイル・グループおよび表領域リポジトリの監視

- ファイル・グループ・リポジトリの監視

- データベース内のファイル・グループに関する一般情報の表示

- ファイル・グループのバージョンに関する情報の表示

- ファイル・グループのファイルに関する情報の表示

- 表領域リポジトリの監視

- 表領域リポジトリ内の表領域に関する情報の表示

- 表領域リポジトリ内の表に関する情報の表示

- 表領域リポジトリ内のバージョンに関するエクスポート情報の表示

第VII部 付録

A Oracle Streamsと他のデータベース・コンポーネントとの連携

- Oracle StreamsおよびOracle Real Application Clusters

- 取得プロセスおよびOracle Real Application Clusters

- 同期取得およびOracle Real Application Clusters

- 取得と適用の複合およびOracle Real Application Clusters

- キューとOracle Real Application Clusters

- 伝播およびOracle Real Application Clusters

- 適用プロセスおよびOracle Real Application Clusters

- Oracle Streamsおよび透過的データ暗号化

- 取得プロセスおよび透過的データ暗号化

- 同期取得および透過的データ暗号化

- 明示的取得および透過的データ暗号化

- キューおよび透過的データ暗号化

- 伝播とネットワーク・データの暗号化

- 適用プロセスおよび透過的データ暗号化

- メッセージ・クライアントおよび透過的データ暗号化

- 手動デキューおよび透過的データ暗号化

- Oracle Streamsおよびフラッシュバック・データ・アーカイブ

- Oracle StreamsおよびRecovery Manager(RMAN)

- RMANおよびインスタンス化

- 取得プロセスで必要なRMANおよびアーカイブREDOログ・ファイル

- RMANおよびローカル取得プロセス

- RMANおよびダウンストリーム取得プロセス

- リカバリ・カタログおよびOracle Streams

- Oracle Streamsおよび分散トランザクション

- Oracle StreamsおよびOracle Data Vault

B Oracle Streamsの制限事項

- 取得プロセスの制限事項

- 取得プロセスではサポートされていないデータ型

- 取得プロセスではサポートされていない変更

- 取得プロセスではサポートされていないスキーマ

- 取得プロセスではサポートされていない表タイプ

- 取得プロセスではサポートされていないDDL変更

- 取得プロセスによって無視される変更

- SQL操作用のNOLOGGINGおよびUNRECOVERABLEキーワード

- ダイレクト・パス・ロード用のUNRECOVERABLE句

- サプリメンタル・ロギング・データ型の制限事項

- ダウンストリーム取得の操作要件

- 取得プロセスではサポートされていないOracle Label Security

- Oracle Streams適用プロセスと取得プロセスの相互運用性

- 同期取得の制限事項

- 表ルールのみを使用する同期取得

- 同期取得ではサポートされていないデータ型

- 同期取得ではサポートされていない変更

- 同期取得ではサポートされていないスキーマ

- 同期取得ではサポートされていない表タイプ

- 同期取得によって無視される変更

- 同期取得ルールおよびDBMS_STREAMS_ADMパッケージ

- 同期取得ではサポートされていないOracle Label Security

- キューの制限事項

- ANYDATAキューの明示的エンキューの制限事項

- バッファ・メッセージ機能の制限事項

- トリガーおよびキュー表

- 伝播の制限事項

- 接続修飾子および伝播

- 伝播のキャラクタ・セットの制限事項

- キュー・ツー・キュー伝播の互換性要件

- 適用プロセスの制限事項

- 適用プロセスではサポートされていないデータ型

- 適用ハンドラではサポートされていないデータ型

- 適用プロセスによって無視されるDDL変更のタイプ

- Oracle Streams環境におけるデータベース構造

- 宛先データベースに存在する必要がある現行スキーマ・ユーザー

- 適用プロセスではサポートされていないOracle Label Security

- Oracle Streams取得コンポーネントと適用プロセスの相互運用性

- メッセージ・クライアントの制限事項

- メッセージ・クライアントおよびバッファ・メッセージ

- ルールの制限事項

- サブセット・ルールの制限

- アクション・コンテキストの制限事項

- ルールベースの変換の制限事項

- 宣言ルールベースの変換ではサポートされていないデータ型

- カスタム・ルールベースの変換ではサポートされていないデータ型

- Oracle Streamsレプリケーションのキャラクタ・セットの制限事項

C LCR用のXMLスキーマ

- LCR用のXMLスキーマ定義

D Oracle Streamsを使用したオンラインでのデータベースのアップグレードおよびメンテナンス

- Oracle Streamsを使用したアップグレードおよびメンテナンス操作の概要

- アップグレードまたはメンテナンス操作中の取得データベース

- アップグレードまたはメンテナンス対象のデータベースの前提条件

- ジョブ・スレーブおよびPL/SQLパッケージのサブプログラムに関する考慮事項

- サポートされないデータベース・オブジェクトの除外

- データベースのアップグレードまたはメンテナンス操作の準備

- ダウンストリーム取得の準備

- ユーザー定義型を含むデータベースのアップグレードまたはメンテナンスの準備

- ユーザー作成アプリケーションへのアップグレード準備

- スキーマ・オブジェクトに対する変更の処理

- 論理的な依存性の処理

- Oracle Streamsを直接構成するかスクリプトを生成するかの決定

- インスタンス化で使用するユーティリティの決定

- Oracle Streamsを使用したデータベースのアップグレードまたはメンテナンス操作の実行

- タスク1: 操作の開始

- タスク2: インスタンス化前のOracle Streamsの設定

- 取得データベースにソース・データベースを使用する場合

- 取得データベースに宛先データベースを使用する場合

- 取得データベースに第3のデータベースを使用する場合

- タスク3: データベースのインスタンス化

- エクスポート/インポートを使用したデータベースのインスタンス化

- RMANのDUPLICATEコマンドを使用したデータベースのインスタンス化

- RMANのCONVERT DATABASEコマンドを使用したデータベースのインスタンス化

- タスク4: インスタンス化後のOracle Streamsの設定

- 取得データベースにソース・データベースを使用する場合

- 取得データベースに宛先データベースを使用する場合

- 取得データベースに第3のデータベースを使用する場合

- タスク5: アップグレードまたはメンテナンス操作の完了およびOracle Streamsの削除

E Oracle Streamsを使用した10.1以下のデータベースのオンラインでのアップグレード

- Oracle Streamsを使用したデータベースのアップグレード・プロセスの概要

- アップグレード・プロセス中の取得データベース

- アップグレード対象のデータベースの前提条件

- ジョブ・キュー・プロセスおよびPL/SQLパッケージのサブプログラムに関する考慮事項

- Oracle Streamsを使用したデータベースのアップグレードの準備

- ユーザー定義型を含むデータベースのアップグレードの準備

- インスタンス化で使用するユーティリティの決定

- Oracle Streamsを使用したデータベースのアップグレードの実行

- タスク1: アップグレードの開始

- タスク2: インスタンス化前のOracle Streamsの設定

- 取得データベースにソース・データベースを使用する場合

- 取得データベースに宛先データベースを使用する場合

- 取得データベースに第3のデータベースを使用する場合

- タスク3: データベースのインスタンス化

- エクスポート/インポートを使用したデータベースのインスタンス化

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

- タスク4: インスタンス化後のOracle Streamsの設定

- 取得データベースにソース・データベースを使用する場合

- 取得データベースに宛先データベースを使用する場合

- 取得データベースに第3のデータベースを使用する場合

- タスク5: アップグレードの完了およびOracle Streamsの削除

用語集

索引

図一覧

- 1-1 Oracle Streamsの情報フロー

- 1-2 ハブ・アンド・スポーク・レプリケーション構成例

- 1-3 ダウンストリーム取得によるレプリケーション構成の例

- 1-4 同期取得によるレプリケーション構成の例

- 1-5 N-Wayレプリケーション構成の例

- 1-6 単一データベースの取得および適用構成の例

- 1-7 メッセージ構成の例

- 2-1 取得プロセス

- 2-2 リアルタイム・ダウンストリーム取得

- 2-3 アーカイブ・ログ・ダウンストリーム取得

- 2-4 同期取得

- 3-1 ソース・キューから宛先キューへの伝播

- 3-2 有向ネットワーク環境の例

- 4-1 適用プロセスのメッセージ処理オプション

- 4-2 メッセージ・クライアント

- 5-1 ルール・エンジンの複数クライアントで使用できる1つのルール・セット

- 5-2 取得プロセスによる取得中の行の移行

- 5-3 伝播中の行の移行

- 5-4 適用中の行の移行

- 5-5 メッセージ・クライアントによるデキュー中の行の移行

- 6-1 取得プロセスによる取得中の変換

- 6-2 同期取得による取得中の変換

- 6-3 伝播中の変換

- 6-4 適用中の変換

- 6-5 メッセージ・クライアント・デキュー中の変換

- 7-1 チェックポイント保存時間が20日に設定されている場合

- 7-2 リセットされた先頭SCNより開始SCNが大きい場合

- 7-3 リセットされた先頭SCNより開始SCNが小さい場合

- 7-4 LogMinerデータ・ディクショナリを共有するかどうかの決定

- 7-5 取得プロセス・ルールの評価を示すフロー・チャート

- 8-1 デキュー時のトランザクション間の依存性の違反

- 8-2 キュー内のメッセージの一貫性のない参照

- 11-1 ルール・セットの評価

- 14-1 Enterprise Managerのレプリケーションの管理ページ

- 20-1 1つのデータベースでのローカル取得およびローカル適用による変更の記録

- 20-2 レプリケーションでのローカル取得およびリモート適用による変更の記録

- 20-3 ダウンストリーム取得およびローカル適用による変更の記録

- 20-4 ダウンストリーム取得およびリモート適用による変更の記録

- 23-1 2つの個別のストリーム・パスが存在するOracle Streamsのトポロジ

- 23-2 単一ソースに複数の適用プロセスが存在するOracle Streamsのトポロジ

- 23-3 Oracle Streamsレプリケーション環境の例

- 36-1 表領域リポジトリの例

- 36-2 共有ファイル・システムを使用した表領域のアタッチ

- 36-3 共有ファイル・システムを使用した表領域のデタッチ

- 36-4 共有ファイル・システムを使用しない表領域のアタッチ

- 36-5 ファイル・グループ・リポジトリの例

- D-1 Oracle Streamsを使用したオンラインでのデータベースのアップグレードおよびメンテナンス

- E-1 Oracle Streamsを使用したオンラインでのデータベースのアップグレード

表一覧

- 1-1 Oracle Streamsの概要に関するドキュメント

- 1-2 Oracle Streams環境の設定または拡張に関するドキュメント

- 1-3 Oracle Streams環境の管理に関するドキュメント

- 1-4 Oracle Streams環境の監視に関するドキュメント

- 1-5 Oracle Streamsを使用したデータのアップグレードおよびメンテナンスに関するドキュメント

- 2-1 すべての行LCRに含まれる属性

- 2-2 取得された行LCRの追加の属性

- 2-3 すべてのDDL LCRに含まれる属性

- 2-4 取得されたDDL LCRの追加の属性

- 2-5 LCRのその他の属性

- 2-6 Oracle Streamsでの情報取得オプション

- 4-1 Oracle Streamsでの情報コンシューム・オプション

- 4-2 適用ハンドラの特性

- 4-3 メッセージ処理オプションのまとめ

- 4-4 適用時に自動的に変換されるデータ型の組合せ

- 5-1 ルール・セットとOracle Streamsクライアントの動作

- 5-2 タスクのタイプとルールのレベル

- 5-3 DBMS_STREAMS_ADMパッケージによって生成されるシステム作成ルールの条件

- 7-1 プライマリ・データ・ディクショナリ内とLogMinerデータ・ディクショナリ内の表t1に関する情報

- 8-1 トランザクション・キューと非トランザクション・キューに対する適用プロセスの動作

- 10-1 DBMS_STREAMS_ADMを使用した場合とDBMS_APPLY_ADMを使用した場合の適用プロセスの作成

- 10-2 トリガー起動プロパティ

- 15-1 取得プロセスから同期取得への切替えの例

- 15-2 同期取得から取得プロセスへの切替えの例

- 20-1 MAINTAIN_CHANGE_TABLEの構成オプション

- 22-1 Oracle Streamsの静的データ・ディクショナリ・ビュー

- 23-1 ストリーム・パスの例と各リンクの位置

- 23-2 Oracle Streamsパフォーマンス・アドバイザによるセッション内での情報の収集方法

- 23-3 Oracle Streamsコンポーネントのコンポーネント・レベルの統計

- 23-4 Oracle Streamsコンポーネントのセッション・レベル統計

- 35-1 表領域リポジトリのプロシージャ

- 35-2 表領域の移動またはコピーのオプション

- D-1 Oracle Streamsを使用したデータベースのメンテナンスのためのインスタンス化方法

- E-1 サポートされているアップグレード中の取得データベース

- E-2 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環境の監視

- 必要なトラブルシューティング・アクティビティの実行

このマニュアルを使用するには、リレーショナル・データベースの概念、SQL、分散データベースの管理、アドバンスト・キューイングの概念、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 Streamsアドバンスト・キューイング・ユーザーズ・ガイド』

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

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

表記規則

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

規則

意味

太字

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

イタリック体

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

固定幅フォント

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

Oracle Streamsの新機能

ここでは、Oracle Database 11gのOracle Streamsの新機能を説明し、それらの詳細の参照先を示します。

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

- Oracle Database 11g リリース2(11.2)のOracle Streamsの新機能

- Oracle Database 11g リリース1(11.1)のOracle Streamsの新機能

Oracle Database 11g リリース2(11.2)のOracle Streamsの新機能

Oracle Database 11g リリース2(11.2)のOracle Streamsには、次の新機能があります。

- XStream

- 文DMLハンドラ

- Oracle Streamsを使用した表の変更の記録

- SQL生成

- Oracle Streamsによる圧縮表のサポート

- 取得プロセスおよび適用プロセスによるSecureFiles LOBのサポート

- 新しい列を保持する宣言ルールベースの変換

- 自動分割とマージ

- 新しい適用プロセス・パラメータ: txn_age_spill_threshold

- ジョブの監視

- 新しいDBA_RECOVERABLE_SCRIPT_HISTビュー

XStream

XStreamには、Oracle Database間およびOracle Databaseと他のシステム間での情報共有を可能にするアプリケーション・プログラミング・インタフェース(API)が備えられています。他のシステムには、Oracle Times TenなどのOracleシステム、Oracle以外のデータベース、RDBMS以外のOracle製品、ファイル・システム、サード・パーティ・ソフトウェア・アプリケーションなどが含まれます。

関連項目:
『Oracle Database XStreamガイド』

文DMLハンドラ

文DMLハンドラと呼ばれる新しいタイプの適用ハンドラでは、SQL文のコレクションを使用し、カスタマイズした方法で行LCRを処理できます。PL/SQLの処理を必要としないので、文DMLハンドラは通常、プロシージャDMLハンドラよりもよいパフォーマンスで動作します。

関連項目:

- 「文DMLハンドラ」

- 「文DMLハンドラの管理」

- 「文DMLハンドラに関する情報の表示」

Oracle Streamsを使用した表の変更の記録

DBMS_STREAMS_ADMパッケージの新しいMAINTAIN_CHANGE_TABLEプロシージャを使用すると、表に対して行われた変更を記録するOracle Streams環境を簡単に構成できます。

関連項目:

- 第20章「Oracle Streamsを使用した表の変更の記録」

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

SQL生成

SQL生成とは、行論理変更レコード(行LCR)にカプセル化された変更を実行する際に必要となるSQL文を生成する機能です。

関連項目:

- 「SQL生成」

- SQL生成を使用するプロシージャDMLハンドラの例は、「プロシージャDMLハンドラの作成」を参照

- GET_ROW_TEXT行LCRメンバー・ファンクションの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

Oracle Streamsによる圧縮表のサポート

以前のリリースのOracle Databaseでは、Oracle Streamsは、圧縮表に対する変更の取得をサポートしていませんでした。Oracle Database 11g リリース2(11.2)以上のOracle Streamsの取得プロセスおよび同期取得は、基本表圧縮またはOLTP表圧縮のいずれかにより圧縮された表に対する変更を取得できます。また、適用プロセスでは、圧縮表に変更を適用できます。

注意:
取得プロセスが圧縮表に対する変更を取得できるのは、ソース・データベースで互換性レベルが11.2.0以上に設定されている場合のみです。ダウンストリーム取得構成では、取得プロセスを実行しているデータベースでも互換性レベルが11.2.0以上に設定されている必要があります。同期取得で圧縮表に対する変更を取得できるのは、データベースで互換性レベルが11.2.0以上に設定されている場合のみです。

関連項目:

- 『Oracle Database概要』

- 『Oracle Database管理者ガイド』

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

取得プロセスおよび適用プロセスによるSecureFiles LOBのサポート

以前のリリースのOracle Databaseでは、Oracle Streamsは、SecureFiles LOBをサポートしていませんでした。Oracle Database 11gリリース2 (11.2)以上のOracle Streamsの取得プロセスでは、SecureFiles CLOB、NCLOBおよびBLOB列に対して行われた変更を取得でき、Oracle Streamsの適用プロセスでは、SecureFiles CLOB、NCLOBおよびBLOB列に変更を適用できます。

関連項目:

- 「取得プロセスによって取得されるデータ型」

- 「適用されるデータ型」

新しい列を保持する宣言ルールベースの変換

列を保持する宣言ルールベースの変換では、指定したルールを満たす行論理変更レコード(LCR)に列のリストが保持されます。変換によって、リストにない列が行LCRから削除されます。列を保持する宣言ルールベースの変換を指定するには、DBMS_STREAMS_ADMパッケージのKEEP_COLUMNSプロシージャを使用します。

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

自動分割とマージ

split_thresholdおよびmerge_thesholdという2つの新しい取得プロセス・パラメータを使用すると、自動分割とマージが可能になります。これらのパラメータが自動分割とマージを指定するように設定されていると、Oracle Schedulerジョブにより取得プロセスから送られるストリームが監視されます。Oracle Schedulerジョブにより、ストリームに問題があることがわかった場合、ジョブは新しいOracle Schedulerジョブを発行して、取得プロセスから送られるその他のストリームから、問題のストリームを切り離します。その他のOracle Schedulerジョブはストリームの監視を続行し、問題が修正されると、Oracle Schedulerジョブがそのストリームをその他のストリームにマージします。

関連項目:

- 『Oracle Streamsレプリケーション管理者ガイド』

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

新しい適用プロセス・パラメータ: txn_age_spill_threshold

適用プロセスは、特定のトランザクションについて、トランザクションのメッセージがtxn_age_spill_thresholdパラメータで指定した秒数を超えてメモリー内に存在すると、メッセージをメモリーからハード・ディスクにオーバーフローさせます。

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

ジョブの監視

UTL_SPADVパッケージの新しいSTART_MONITORINGプロシージャでは、指定した間隔で継続的にOracle Streamsパフォーマンスを監視する監視ジョブを作成できます。このパッケージの他の新しいプロシージャを使用して、監視ジョブを管理できます。

関連項目:

- 「UTL_SPADVパッケージの使用」

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

新しいDBA_RECOVERABLE_SCRIPT_HISTビュー

新しいDBA_RECOVERABLE_SCRIPT_HISTビューには、DBMS_STREAMS_ADMパッケージのRECOVER_OPERATIONプロシージャによって実行されたリカバリ操作の結果が格納されます。

関連項目:

- 『Oracle Streamsレプリケーション管理者ガイド』

- 『Oracle Databaseリファレンス』

Oracle Database 11g リリース1(11.1)のOracle Streamsの新機能

Oracle Database 11g リリース1(11.1)のOracle Streamsには、次の新機能があります。

- Oracle StreamsのトポロジおよびOracle Streamsパフォーマンス・アドバイザ

- 適用時の自動データ型変換

- パラメータのデフォルト値をリストアするための簡単な方法

- Oracle Streamsによるフラッシュバック・データ・アーカイブ内の表のサポート

- Oracle Streamsによる仮想列のサポート

- 新しい取得プロセス・パラメータ: skip_autofiltered_table_ddl

- 新しい適用プロセス・パラメータ: rtrim_on_implicit_conversion

- 同期取得

- Oracle StreamsによるXMLType列のサポート

- Oracle Streamsによる透過的データ暗号化のサポート

- ストリームの宛先の分割とマージ

- ストリームを介したLCRの追跡

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

- Oracle Streamsクライアント用の自動アラートおよびしきい値

- Oracle StreamsジョブによるOracle Schedulerの使用

- 通知機能の改善

- エラー処理が簡単になった新しいエラー・メッセージ

- 取得と適用の複合

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コンポーネントが調査され、それらのパフォーマンスを向上させるための推奨方法が示されます。

関連項目:
第23章「Oracle Streamsのトポロジおよびパフォーマンスの監視」

適用時の自動データ型変換

行論理変更レコード(行LCR)の列のデータ型と表の対応する列のデータ型が一致しない場合、適用プロセスによって、適用時に自動的に特定のデータ型が変換されます。

関連項目:
「適用時の自動データ型変換」

パラメータのデフォルト値をリストアするための簡単な方法

DBMS_CAPTURE_ADM.SET_PARAMETERプロシージャのパラメータの値にNULLを指定すると、取得プロセス・パラメータにそのデフォルト値を設定できます。同様に、DBMS_APPLY_ADM.SET_PARAMETERプロシージャのパラメータの値にNULLを指定すると、適用プロセス・パラメータ値にそのデフォルト値を設定できます。

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

Oracle Streamsによるフラッシュバック・データ・アーカイブ内の表のサポート

以前のリリースのOracle Databaseでは、Oracle Streamsは、フラッシュバック・データ・アーカイブ内の表に対する変更のレプリケーションをサポートしていませんでした。Oracle Database 11g リリース1(11.1)以上では、Oracle Streamsは、フラッシュバック・データ・アーカイブ内の表をサポートします。

関連項目:
「Oracle Streamsおよびフラッシュバック・データ・アーカイブ」

Oracle Streamsによる仮想列のサポート

以前のリリースのOracle Databaseでは、Oracle Streamsは、仮想列を持つ表に対する変更のレプリケーションをサポートしていませんでした。Oracle Database 11g リリース1(11.1)以上では、Oracle Streamsは、仮想列を持つ表をサポートします。

新しい取得プロセス・パラメータ: skip_autofiltered_table_ddl

新しい取得プロセス・パラメータskip_autofiltered_table_ddlを使用すると、データ操作言語(DML)の変更が自動的にフィルタ処理されるデータベース・オブジェクトに対するデータ定義言語(DDL)の変更を取得できます。

関連項目:

- この取得プロセス・パラメータの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照

- 「取得プロセスと互換性のないデータベース・オブジェクトの表示」

- 「取得プロセス・パラメータの設定」

新しい適用プロセス・パラメータ: rtrim_on_implicit_conversion

新しい適用プロセス・パラメータrtrim_on_implicit_conversionは、データ型の自動変換時に適用プロセスがキャラクタ・データをトリミングするかどうかを決定します。

関連項目:

- この適用プロセス・パラメータの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照

- 「適用時の自動データ型変換」

- 「適用プロセス・パラメータの設定」

同期取得

同期取得は新しいOracle Streamsクライアントであり、表へのデータ操作言語(DML)の変更をコミット直後に取得します。

関連項目:
「同期取得による暗黙的取得」

Oracle StreamsによるXMLType列のサポート

XMLTypeはOracleが提供する型であり、データベースにXMLデータを格納したり、データベース内のXMLデータを問い合せるために使用できます。Oracle Streamsでは、XMLTypeデータへの変更の取得、伝播および適用が可能です。

取得プロセスでは、CLOB列として格納されているXMLType列に対する変更を取得できますが、オブジェクト・リレーショナルまたはバイナリXMLとして格納されているXMLType列に対する変更は取得できません。適用プロセスでは、CLOB列、オブジェクト・リレーショナルまたはバイナリXMLとして格納されているXMLType列に対して変更を適用できます。

関連項目:

- 「取得プロセスによって取得されるデータ型」

- 「適用されるデータ型」

Oracle Streamsによる透過的データ暗号化のサポート

Oracle Streamsは、透過的データ暗号化を使用して暗号化された列への変更の取得、伝播および適用をサポートします。また、列レベルで暗号化された列や、表領域の暗号化を介して暗号化された列をサポートします。表領域の暗号化を使用すると、表領域全体を暗号化できます。暗号化された表領域で作成されたすべてのオブジェクトは、その表領域内のデータベース・オブジェクト内のすべての列も含め、自動的に暗号化されます。列が暗号化されると、その暗号化が列の暗号化によるものか、表領域の暗号化によるものかに関係なく、Oracle Streamsコンポーネントでは同じ方法で列データが処理されます。

関連項目:

- 「取得プロセスおよび透過的データ暗号化」

- 「同期取得および透過的データ暗号化」

- 「伝播とネットワーク・データの暗号化」

- 「適用プロセスおよび透過的データ暗号化」

ストリームの宛先の分割とマージ

Streamsレプリケーション構成から使用できないレプリカを簡単に分割できます。ストリームを分割すると、再び使用可能になったレプリカを最新の状態にするのに必要な時間を短縮できます。最新の状態になったレプリカは、元の構成に再びマージできます。この機能では、DBMS_STREAMS_ADMパッケージ内の3つの新しいプロシージャ(SPLIT_STREAMS、MERGE_STREAMS_JOBおよびMERGE_STREAMS)が使用されます。

関連項目:
『Oracle Streamsレプリケーション管理者ガイド』

ストリームを介したLCRの追跡

DBMS_STREAMS_ADMパッケージ内の新しいSET_MESSAGE_TRACKINGプロシージャを使用すると、データベース・セッションによって生成された論理変更レコード(LCR)に追跡ラベルを指定できます。新しいV$STREAMS_MESSAGE_TRACKING ビューを問い合せると、ストリームを介してLCRを追跡し、それらが各Oracle Streamsクライアントでどのように処理されたかを確認できます。

LCRの追跡は、1つ以上の適用プロセスでLCRが期待どおりに適用されない場合に役立ちます。この場合、LCRの追跡を使用することで、LCRが停止しているストリーム内の場所を特定し、その場所での問題に対処することができます。

また、新しいmessage_tracking_frequency取得プロセス・パラメータを使用すると、LCRを自動的に追跡できます。

関連項目:

- 『Oracle Streamsレプリケーション管理者ガイド』

- message_tracking_frequency取得プロセス・パラメータの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照

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

Oracleが提供するDBMS_COMPARISONと呼ばれる新しいパッケージを使用すると、2つの異なるデータベースで、表などの共有データベース・オブジェクト内の行を比較できます。データベース・オブジェクトに相違点が見つかると、このパッケージによってデータベース・オブジェクトが収束され、一貫性が確保されます。

関連項目:

- Oracle Database 2日でデータ・レプリケーションおよび統合ガイド

- 『Oracle Streamsレプリケーション管理者ガイド』

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

Oracle Streamsクライアント用の自動アラートおよびしきい値

Oracle Streamsクライアントが無効になったり、Oracle Streamsに関連するユーザー定義のしきい値を超えると、Enterprise Managerによって自動的にアラートが通知されます。

関連項目:
「Oracle Streamsアラートの表示」

Oracle StreamsジョブによるOracle Schedulerの使用

以前のリリースでは、Oracle StreamsはDBMS_JOBパッケージで作成されたジョブを使用して、伝播、イベント通知などのジョブを実行し、JOB_QUEUE_PROCESSES初期化パラメータが、作成されるスレーブ・プロセスの数を制御していました。

Oracle Database 11g リリース1(11.1)以上のOracle Streamsでは、Oracle Schedulerを使用してこれらのジョブを実行します。Oracle Schedulerは、コンピュータ・システムの負荷に基づいて、これらのジョブのスレーブ・プロセスの数を自動的に調整します。JOB_QUEUE_PROCESSES初期化パラメータは、スレーブ・プロセスの最大数を指定するためだけに使用されます。したがって、作成可能なスレーブの数を制限する場合を除き、JOB_QUEUE_PROCESSES初期化パラメータを設定する必要はありません。

関連項目:
「伝播ジョブ」

通知機能の改善

今回のリリースでは、通知機能について次のような改善が行われました。

- 時間ごとの通知の分類

- 大量の通知の同時送信を可能にする拡張

- 登録統計を使用した通知の診断機能の向上

関連項目:
『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイド』

エラー処理が簡単になった新しいエラー・メッセージ

Oracle Database 11g リリース1(11.1)では、次の適用エラー・メッセージが新しく追加されました。

- 更新または削除する行が対象の表に存在しない場合、ORA-26787エラーが発生します。

- 対象の表には行が存在するが、一部の列の値が、行の論理変更レコード(行LCR)の値と一致していない場合、ORA-26786エラーが発生します。

以前のリリースでは、このような場合にORA-01403エラーが戻されていました。これらの新しいエラー・メッセージによって、DMLハンドラおよびエラー・ハンドラでの適用エラーの処理が簡単になりました。既存のプロシージャ・ハンドラおよびエラー・ハンドラが存在する場合は、現行のリリースに対応するように修正する必要がある場合があります。

関連項目:
「エラー・キューに適用エラーがあるか」

取得と適用の複合

Oracle Streamsによって、特定の条件下での伝播効率が向上します。

関連項目:
第12章「取得と適用の複合による最適化」

第I部

Oracle Streamsの基本概念

この部では、Oracle Streamsの概要について説明します。この部の構成は、次のとおりです。

- 第1章「Oracle Streamsの概要」

- 第2章「Oracle Streams情報取得」

- 第3章「Oracle Streamsのステージングと伝播」

- 第4章「Oracle Streams情報コンシューム」

- 第5章「Oracle Streamsでのルールの使用方法」

- 第6章「ルールベースの変換」

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には、分散エンタープライズ・アプリケーション、データ・ウェアハウスおよび高可用性ソリューションの構築と運用に必要な機能が用意されています。Oracle Streamsの機能は、すべて同時に使用できます。変更が必要な場合は、既存の機能を損わずにOracle Streamsの新機能を実装できます。

Oracle Streamsを使用して、データ・ストリームに入れる情報、ストリームが流れる方法、データベース間でのストリームのルーティング方法、ストリーム内のメッセージが各データベースに達したときの処理、およびストリームの終了方法を制御します。Oracle Streamsの特定の機能を構成することで、特定の要件に対処できます。Oracle Streamsでは、指定に基づいてデータベースでメッセージの取得、ステージングおよび管理を自動的に行うことができます。メッセージには、データ操作言語(DML)の変更やデータ定義言語(DDL)の変更などがありますが、それにとどまりません。また、ユーザー定義のメッセージをストリームに挿入して、Oracle Streamsが他のデータベースやアプリケーションに情報を自動的に伝播することもできます。メッセージが宛先に達すると、Oracle Streamsは指定に基づいてこれらを消費できます。

図1-1は、Oracle Streamsの情報フローを示しています。

図1-1 Oracle Streamsの情報フロー

Oracle Streamsの機能

次の各項では、Oracle Streamsの機能の概要について説明します。

- データベースでのメッセージの取得

- キューへのメッセージのステージング

- キュー間でのメッセージの伝播

- メッセージのコンシューム

- 競合の検出と解決

- メッセージの変換

- Oracle Streamsタグの付いたメッセージの追跡

- Oracle以外のデータベースとの情報の共有

データベースでのメッセージの取得

Oracle Streamsには、データベース変更を暗黙に取得する2つの方法があります。これらは、取得プロセスおよび同期取得です。取得プロセスでは、表、スキーマまたはデータベース全体に対して行われたDML変更、およびDDL変更を取得できます。同期取得では、表に対して行われたDML変更を取得できます。変更が取得プロセスまたは同期取得のいずれによって取得されるかは、ルールによって決まります。

データベース変更は、データベースのREDOログに記録されます。取得プロセスは、REDOログから変更を取得して、取得した変更をそれぞれ論理変更レコード(LCR)と呼ばれる形式のメッセージにフォーマットします。取得プロセスによって取得されたメッセージを、取得LCRと呼びます。

同期取得では、内部メカニズムを使用して変更を取得し、取得した変更をそれぞれLCRにフォーマットします。同期取得によって取得されたメッセージを、永続LCRと呼びます。

取得プロセスまたは同期取得で使用されるルールによって、取得する変更が決められます。変更が取得プロセスで取得された場合、変更がREDOログに生成されたデータベースがソース・データベースになります。変更が同期取得で取得された場合は、同期取得が構成されているデータベースがソース・データベースになります。

取得プロセスは、ソース・データベースで変更をローカルに取得することも、ダウンストリーム・データベースで変更をリモートに取得することもできます。同期取得は、ソース・データベースで変更をローカルに取得することのみが可能です。取得プロセスと同期取得は、論理変更レコード(LCR)をキューにエンキューします。取得プロセスまたは同期取得による変更の取得は暗黙的取得と呼ばれます。

ユーザーおよびアプリケーションが、メッセージを手動でエンキューすることもできます。これらのメッセージはLCRです。または、ユーザー・メッセージと呼ばれるユーザー定義型のメッセージです。ユーザーおよびアプリケーションがメッセージを手動でエンキューすることを、明示的取得と呼びます。

キューへのメッセージのステージング

メッセージはキューに格納(ステージング)されます。このようなメッセージは、論理変更レコード(LCR)またはユーザー・メッセージです。取得プロセスおよび同期取得は、メッセージをANYDATAキューにエンキューします。ANYDATAキューは様々なタイプのメッセージをステージングできます。ユーザーとアプリケーションはメッセージをANYDATAキューまたは型付きキューにエンキューできます。型付きキューは、1つのタイプのメッセージのみをステージングできます。

キュー間でのメッセージの伝播

Oracle Streamsの伝播によって、あるキューから別のキューにメッセージを伝播できます。これらのキューは、同じデータベースにあっても異なるデータベースにあってもかまいません。ルールによって、伝播で伝播するメッセージが決定されます。

Oracle Streamsでは、有向ネットワークを介して変更が共有される環境を構成できます。有向ネットワークでは、伝播されるメッセージは、それらがコンシュームされる宛先データベースに到達する前に1つ以上の中間データベースを通過します。メッセージは、宛先データベースに加えて、中間データベースでコンシュームされる場合もコンシュームされない場合もあります。Oracle Streamsを使用すると、各宛先データベースに伝播されるメッセージを選択し、メッセージが宛先データベースに到達するまでのルートを指定できます。

メッセージのコンシューム

メッセージは、キューからデキューされるとコンシュームされます。適用プロセスは、メッセージを暗黙的にデキューできます。ユーザー、アプリケーションまたはメッセージ・クライアントは、メッセージを明示的にデキューできます。メッセージがコンシュームされるデータベースは、宛先データベースと呼ばれます。構成によっては、ソース・データベースと宛先データベースが同一の場合があります。

ルールによって、適用プロセスでデキューおよび処理するメッセージが決まります。適用プロセスはメッセージをデータベース・オブジェクトに直接適用するか、処理のためにメッセージをカスタムPL/SQLサブプログラムに渡します。

ルールによって、メッセージ・クライアントでデキューするメッセージが決まります。メッセージ・クライアントは、アプリケーションまたはユーザーによって起動された際にメッセージをデキューします。

競合の検出と解決

適用プロセスは、レプリケーション環境でLCRを直接適用するときに、競合を自動的に検出します。競合とは、LCRの古い値と表内の予期されるデータの不一致です。通常、競合が発生するのは、ソース・データベース内と宛先データベース内で同じ行がほぼ同時に変更される場合です。

競合が発生した場合は、ビジネス・ルールに従って競合を確実に解消するメカニズムが必要です。Oracle Streamsには、様々なビルトイン競合ハンドラが用意されています。これらのビルトイン・ハンドラを使用すると、データベースごとに、ビジネス・ルールに従って競合を解消する競合解消システムを定義できます。ビルトイン競合解消ハンドラが解決できない固有の状況がある場合は、独自の競合解消ハンドラを作成できます。

競合が解決されない場合や、ハンドラ・プロシージャにエラーが発生した場合、エラーを発生させたトランザクション内のすべてのメッセージは、後で分析して可能であれば再実行できるようにエラー・キューに保存されます。

関連項目:

- 『Oracle Streamsレプリケーション管理者ガイド』

メッセージの変換

ルールベースの変換は、ポジティブ・ルール・セットのルールがTRUEと評価される場合に発生するメッセージの変更です。ルールベースの変換には、宣言とカスタムという2つのタイプがあります。

宣言ルールベースの変換では、スキーマ名の変更、表の名前変更、列の追加、列の名前変更、列の保持、および列の削除などの行LCRの一般的な変換を実行できます。このような変換はOracle Enterprise Manager、またはDBMS_STREAMS_ADMパッケージのプロシージャを使用して指定(宣言)します。Oracle Streamsでは、PL/SQLを起動せずに内部的に宣言変換が実行されます。

カスタム・ルールベースの変換では、変換を実行するユーザー定義PL/SQLファンクションが必要です。Oracle Streamsでは、変換を実行するPL/SQLファンクションが起動されます。カスタム・ルールベースの変換を実行すると、LCRまたはユーザー・メッセージのいずれかを変更できます。たとえば、カスタム・ルールベースの変換で、LCRの特定の列のデータ型を変更できます。

いずれのタイプのルールベースの変換も、次の時点で発生します。

- 取得プロセスによるメッセージのエンキュー時。すべての宛先データベースに適切な方法でメッセージをフォーマットする場合に役立ちます。

- メッセージの伝播時。メッセージが特定のリモート・サイトに送信される前にメッセージを変換する場合に役立ちます。

- 適用プロセスまたはメッセージ・クライアントによるメッセージのデキュー時。特定の宛先データベースに適切な方法でメッセージをフォーマットする場合に役立ちます。

適用中に変換を実行すると、適用プロセスは変換されたメッセージを直接適用するか、変換されたメッセージを適用ハンドラに送信して処理させることができます。

注意:

- ルールベースの変換を起動するには、ルールをポジティブ・ルール・セットに含める必要があります。ネガティブ・ルール・セット内のルールに指定したルールベースの変換は、取得プロセス、伝播、適用プロセスおよびメッセージ・クライアントによって無視されます。

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

関連項目:
第6章「ルールベースの変換」

Oracle Streamsタグの付いたメッセージの追跡

REDOログの各REDOエントリには、タグが関連付けられています。タグのデータ型はRAWです。デフォルトでは、ユーザーまたはアプリケーションがREDOエントリを生成する時点では、各REDOエントリのタグの値はNULLであり、NULLタグは、REDOエントリの領域をコンシュームしません。タグ値の上限は2000バイトです。

Oracle Streamsでは、タグ値に関連する条件がルールに含まれ、これによってOracle Streamsクライアントの動作を制御できます。たとえば、タグを使用すると、LCRに含まれている変更の発生場所が、ローカル・データベースであるか異なるデータベースであるかを判断できるため、変更の循環(発生場所となったデータベースへのLCRの送信)を回避できます。また、タグを使用して、LCRごとに一連の宛先データベースを指定できます。タグは、他のLCRの追跡にも使用できます。

Oracle Streamsタグは、特定のセッションまたは適用プロセスで生成されるREDOエントリ用に指定できます。これらのタグは、取得プロセスまたは同期取得によって取得されたLCRの一部になります。通常、タグはOracle Streamsレプリケーション環境で使用されますが、データベース変更およびLCRを追跡するために、必要に応じて使用できます。

関連項目:

- 『Oracle Streamsレプリケーション管理者ガイド』

Oracle以外のデータベースとの情報の共有

Oracle Streamsでは、Oracle Database間のみでなく、Oracle DatabaseとOracle以外のデータベースの間でも異機種間での情報の共有がサポートされます。

関連項目:

- 『Oracle Streamsレプリケーション管理者ガイド』

Oracle Streamsの用途

次の各項では、Oracle Streamsを使用する理由について説明します。

- データ・レプリケーション

- データ・ウェアハウスのロード

- アップグレードおよびメンテナンス操作時のデータベースの可用性

- メッセージ・キューイング

- イベントの管理および通知

- データ保護

場合によっては、Oracle StreamsコンポーネントによってOracleの様々な機能のインフラストラクチャが提供されます。

データ・レプリケーション

Oracle Streamsでは、データベース・オブジェクトに対するデータ操作言語(DML)とデータ定義言語(DDL)の変更を取得し、それらの変更を他の1つ以上のデータベースにレプリケートできます。Oracle Streamsの取得プロセスまたは同期取得は、ソース・データベース・オブジェクトに対する変更を取得して、LCR形式でフォーマットします。LCRは宛先データベースに伝播されて、Oracle Streamsの適用プロセスで適用できます。

宛先データベースでは、同じデータベース・オブジェクトに対するDML変更およびDDL変更が可能です。これらの変更は、環境内の他のデータベースに伝播される場合と、伝播されない場合があります。つまり、Oracle Streams環境を、変更を伝播する1つのデータベースで構成する方法と、データベース間で変更が双方向に伝播するように構成する方法があります。また、データを共有する表が、すべてのデータベースで同一である必要はありません。これらの表の構造と内容はデータベースごとに異なっていてもよく、各表の情報はこれらのデータベース間で共有できます。

関連項目:

- レプリケーションのためのOracle Streamsの使用の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

データ・ウェアハウスのロード

データ・ウェアハウスのロードは、データ・レプリケーションの特殊なケースです。データ・ウェアハウスの作成とメンテナンスで特に重要となるタスクには、既存データのリフレッシュと、実稼働データベースからの新規データの追加があります。Oracle Streamsのコンポーネントは、本番システムに加えられた変更を取得した後、それらをステージング・データベースに送ることも、データ・ウェアハウスや実稼働データ・ストアに直接送ることもできます。またOracle Streamsは、REDOログの情報を取得プロセスで取得することにより、本番システムに余計なオーバーヘッドがかかるの防ぎます。表に加えられた変更がOracle Streamsによって記録されるようにするための構成は、Oracle Streamsに付属するワンステップ型のプロシージャ(DBMS_STREAMS_ADM.MAINTAIN_CHANGE_TABLE)を使用して実行できます。データ変換やユーザー定義の適用プロシージャもサポートされているので、データがロードされる際、データを再フォーマットしたり、ウェアハウス固有のデータ・フィールドを更新するなど、必要な処理を柔軟に実装できます。また、Oracle Streamsの一部のコンポーネントはチェンジ・データ・キャプチャでも使用されます。つまり、変更されたデータを識別し、データ・ウェアハウスへロード可能にするために使用されます。

関連項目:

- 第20章「Oracle Streamsを使用した表の変更の記録」

- データ・ウェアハウスの詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照

アップグレードおよびメンテナンス操作時のデータベースの可用性

Oracle Streamsの機能を使用すると、データベースのアップグレードやメンテナンス操作の際に、停止時間を最小限に抑えること、または停止時間をなくすことができます。メンテナンス操作には、別のプラットフォームへのデータベースの移行、別のキャラクタ・セットへのデータベースの移行、ユーザー作成アプリケーションのアップグレードをサポートするためのデータベース・スキーマ・オブジェクトの変更、Oracleソフトウェア・パッチの適用などがあります。

関連項目:

- 付録E「Oracle Streamsを使用した10.1以下のデータベースのオンラインでのアップグレード」

- 付録D「Oracle Streamsを使用したオンラインでのデータベースのアップグレードおよびメンテナンス」

メッセージ・キューイング

Oracle Streamsアドバンスト・キューイング(AQ)を使用すると、ユーザー・アプリケーションは、メッセージをキューにエンキューしたり、サブスクライバ・キューに伝播することができます。また、コンシュームの準備ができたことをユーザー・アプリケーションに通知したり、宛先でのメッセージのデキューを実行できるようになります。キューは、特定の型のメッセージのみをステージングするように構成するか、またはANYDATAキューとして構成できます。ほぼすべての型のメッセージは、ANYDATAラッパーにラップして、ANYDATAキューにステージングできます。Oracle Streams AQでは、マルチ・コンシューマ・キュー、パブリッシュおよびサブスクライブ、コンテンツベースのルーティング、インターネット伝播、変換、他のメッセージ・サブシステムへのゲートウェイなど、メッセージ・キューイング・システムのすべての標準機能がサポートされます。

データベースにキューを作成できます。また、アプリケーションはメッセージをキューに明示的にエンキューできます。サブスクライバ・アプリケーションまたはメッセージ・クライアントは、このキューからメッセージを直接デキューできます。アプリケーションがリモートの場合、ソース・キューでパブリッシュされたメッセージをサブスクライブするリモート・データベースにキューを作成できます。宛先アプリケーションは、リモート・キューからメッセージをデキューできます。また、宛先アプリケーションは、様々な標準プロトコルを使用して、ソース・キューからメッセージを直接デキューすることもできます。

関連項目:

- Oracle Streams AQの詳細は、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドを参照してください。

イベントの管理および通知

ビジネス・イベントは、アプリケーション間または組織間の重要な通信手段です。アプリケーションがイベントを表すメッセージをキューに明示的にエンキューするか、Oracle Streams取得プロセスまたは同期取得がデータベース・イベントを取得して、LCRというメッセージにカプセル化します。このようなメッセージは、DMLまたはDDLの変更によって生成されます。伝播は、複数のキューを介してストリーム内のメッセージを伝播します。最後に、ユーザー・アプリケーションがメッセージを明示的にデキューするか、Oracle Streams適用プロセスがメッセージを暗黙的にデキューします。適用プロセスは、必要に応じて、これらのメッセージを同じキューまたは別のキューに明示的に再エンキューできます。

コンシューム後も、指定の期間が経過するまで明示的にエンキューされたメッセージを保持するように、キューを構成できます。この機能が備わっているため、Oracle Streamsアドバンスト・キューイング(AQ)をビジネス・イベント管理システムとして使用できます。Oracle Streams AQは、データベース内のすべてのメッセージをトランザクションとして格納します。これらのメッセージは自動的に監査および追跡できます。この監査証跡を使用して、ビジネス活動に関する情報を抽出できます。

Oracle Streams取得プロセス、同期取得、伝播、適用プロセスおよびメッセージ・クライアントは、ルールに基づいてアクションを実行します。取得、伝播、適用およびデキューするイベントは、ルールを使用して指定できます。組込みルール・エンジンは、これらのルールに基づいてイベントを評価します。イベントを取得し、ルールに基づいてそのイベントを関連するコンシューマに伝播する機能により、イベント通知にOracle Streamsを使用できます。イベントを表すメッセージはキュー内にステージングし、メッセージ・クライアントまたはアプリケーションで明示的にデキューできます。その後、これらのイベントに基づいて、電子メールによる通知、あるいは携帯電話やページャへの送信用ワイヤレス・ゲートウェイにメッセージを渡すなどのアクションを実行できます。

関連項目:

- 第3章「Oracle Streamsのステージングと伝播」

- 第16章「ステージングと伝播の管理」

- 『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイド』

- メッセージを明示的にデキューするサンプル環境は、『Oracle Streams拡張例』を参照

データ保護

データ保護のための1つのソリューションは、本番データベースのコピーをローカルまたはリモートで作成することです。人為的エラーや災害の際にコピーを使用して処理を再開できます。

また、Oracle Data Guard SQL Apply (Oracle Streamsと同様のインフラストラクチャの一部を使用するデータ保護機能)を使用して、ロジカル・スタンバイ・データベースを作成してメンテナンスすることもできます。Oracle Streamsレプリケーションの場合と同様に、取得プロセスがREDOログの変更を取得し、それらの変更をLCR形式でフォーマットします。このようなLCRがスタンバイ・データベースで適用されます。スタンバイ・データベースはすべての読取りおよび書込みに対応し、特殊な索引やその他のデータベース・オブジェクトを含むことができます。このため、更新が適用されるときには、スタンバイ・データベースを問い合せることができます。

更新は、できるだけ早くリモート・サイトのロジカル・スタンバイ・データベースに移動することが重要です。これによって、障害発生時にも、トランザクション消失が最小限で済みます。リモート・データベースにREDOログを同期式で直接書き込むことで、障害発生時にもデータ消失が発生しません。スタンバイ・システム側では、変更が取得され、適用プロセスによってスタンバイ・データベースに直接適用されます。

関連項目:

- 第13章「Oracle Streams高可用性環境」

- ロジカル・スタンバイ・データベースの詳細は、『Oracle Data Guard概要および管理』を参照

Oracle Streams構成の例

次の各項では、Oracle Streams構成の例の概要について説明します。

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

- ダウンストリーム取得によるレプリケーション構成の例

- 同期取得によるレプリケーション構成の例

- N-Wayレプリケーション構成の例

- 単一データベースで取得および適用を実行する構成の例

- メッセージ構成の例

ハブ・アンド・スポーク・レプリケーション構成の例

図1-2に、ハブ・アンド・スポーク・レプリケーション構成の例を示します。通常、ハブ・アンド・スポーク・レプリケーション構成は、複数のターゲット・データベースに情報を配信したり、複数のデータベースの情報を単一のデータベースに統合するために使用されます。

ハブ・アンド・スポーク・レプリケーション構成は、中央データベース(ハブ)が1つ以上のセカンダリ・データベース(スポーク)と通信する環境です。スポークどおしは直接通信しません。ハブ・アンド・スポーク・レプリケーション構成では、スポークはレプリケートされたデータベース・オブジェクトに対する変更を許可する場合と許可しない場合があります。

図1-2のハブ・アンド・スポーク・レプリケーション構成の例には、1つのハブ・データベースと2つのスポーク・データベースがあります。スポーク・データベースでは、レプリケートされたデータベース・オブジェクトに対する変更が可能です。

図1-2 ハブ・アンド・スポーク・レプリケーション構成の例

この構成の詳細は、Oracle Database 2日でデータ・レプリケーションおよび統合ガイドを参照してください。

ダウンストリーム取得によるレプリケーション構成の例

図1-3に、ダウンストリーム取得プロセスを使用するレプリケーション構成の例を示します。ダウンストリーム取得は、ソース・データベースではなくリモート・データベース上で取得プロセスが実行されることを意味します。ダウンストリーム取得を使用すると、本番データベースからの取得ワークロードが削除されます。

図1-3のレプリケーション構成の例では、ダウンストリーム取得プロセスがリモート・データベースdest.example.com上で実行され、REDOデータがソース・データベースsrc.example.comからリモート・データベースに送信されます。リモート・データベースでは、ダウンストリーム取得プロセスがソース・データベースから送信されたREDOデータの変更を取得し、適用プロセスがこれらの変更をローカル・データベース・オブジェクトに適用します。

図1-3 ダウンストリーム取得によるレプリケーション構成の例

この構成の詳細は、Oracle Database 2日でデータ・レプリケーションおよび統合ガイドを参照してください。

同期取得によるレプリケーション構成の例

図1-4に、取得プロセスのかわりに同期取得を使用して変更を取得するレプリケーション構成の例を示します。同期取得レプリケーション構成を使用すると、非常にアクティブなデータベースやREDOログからの変更の取得が不可能な状況で、データの変更頻度が低い表に対する変更をレプリケートできます。

図1-4 同期取得によるレプリケーション構成の例

この構成の詳細は、Oracle Database 2日でデータ・レプリケーションおよび統合ガイドを参照してください。

N-Wayレプリケーション構成の例

図1-5に、n-wayレプリケーション構成の例を示します。通常、n-wayレプリケーション構成は複数のピア・データベースを持つ環境で使用され、各データベースではデータを他の各データベースと相互にレプリケートする必要があります。n-wayレプリケーション構成はロード・バランシングを提供でき、単一データベースが使用できなくなった場合は、フェイルオーバー保護を提供できます。

n-wayレプリケーション構成は、各データベースが環境内の他のデータベースと相互に直接通信する構成です。あるデータベースでレプリケートされたデータベース・オブジェクトに対する変更は、取得されて環境内の他の各データベースに直接送信され、そこで適用されます。

図1-5のn-wayレプリケーション構成のサンプルでは、3つの各データベースが、レプリケートされたデータベース・オブジェクトへの変更を取得し、これらの変更を構成内の他の2つのデータベースに送信します。各データベースでの適用プロセスは、他の2つのデータベースから送信された変更を適用します。

図1-5 N-Wayレプリケーション構成の例

この構成の詳細は、『Oracle Streams拡張例』を参照してください。

単一データベースで取得および適用を実行する構成の例

図1-6に、単一データベースで取得プロセスによってデータベースの変更を取得し、適用プロセスによってこれらの変更を適用する構成の例を示します。この構成では、適用プロセスは変更をキューに再エンキューし、アプリケーションに処理させます。また、プロシージャDMLハンドラは、hr.employees表から削除された行をhr.emp_del表に挿入します。

図1-6 単一データベースの取得および適用構成の例

この構成の詳細は、『Oracle Streams拡張例』を参照してください。

メッセージ構成の例

図1-7に、メッセージ構成の例を示します。メッセージ構成では、キューからキューへメッセージを送信します。これらの2つのキューは、同じデータベースにあっても、異なるデータベースにあってもかまいません。メッセージは、カスタマイズされた方法でアプリケーションによりデキューして処理できます。

図1-7のメッセージ構成の例では、一方のデータベースのトリガーがメッセージを作成してエンキューします。伝播は、このメッセージをもう一方のデータベースに送信します。ここで、PL/SQLプロシージャがこのメッセージをデキューして処理します。

図1-7 メッセージ構成の例

この構成の詳細は、Oracle Database 2日でデータ・レプリケーションおよび統合ガイドを参照してください。

Oracle Streamsのドキュメント・ロードマップ

Oracle Streamsでは、情報共有環境を設定、管理および監視するための様々なオプションが提供されています。この項では、必要なドキュメントの検索に役立つドキュメント・ロードマップを示します。

Oracle Streamsのドキュメント・セットには、次のドキュメントが含まれています。

- 『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』は、Oracle Streamsに関する基本概念、最も一般的なレプリケーションおよびメッセージ環境の設定例、およびOracle Streamsコンポーネントを管理および監視するための基本的な手順を記載しています。このドキュメント内の手順では、可能な場合にOracle Enterprise Managerを使用してタスクを実行する方法が示されています。一部の手順では、SQL*PlusおよびOracle提供パッケージを使用してタスクを実行する方法が示されています。

- Oracle Streams概要および管理は、Oracle Streamsの概念、Oracleで提供されるパッケージを使用したOracle Streamsコンポーネントの管理手順、およびデータ・ディクショナリ・ビューを使用したOracle Streamsコンポーネントの監視手順について詳しく記載しています。

- 『Oracle Streamsレプリケーション管理者ガイド』は、Oracle Streamsレプリケーション環境に関する概念、およびOracle提供パッケージを使用したOracle Streamsレプリケーション環境の構成と管理について記載しています。

- 『Oracle Streams拡張例』は、Oracle提供パッケージを使用して様々なタイプのOracle Streams環境(レプリケーション環境を含む)を構成する詳細な例を記載しています。

- Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドは、Oracle Streamsメッセージング(アドバンスト・キューイング)環境の概念、メッセージ環境の構成、およびOracleで提供されるパッケージや他の管理インタフェースを使用したメッセージ環境の管理について詳しく記載しています。

- 『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』は、Oracleで提供される、Oracle Streams関連すのパッケージおよびタイプのリファレンス情報を記載しています。

- 『Oracle Databaseリファレンス』は、Oracle Streamsに関連するデータ・ディクショナリ・ビューのリファレンス情報を記載しています。

- Oracle Enterprise ManagerのOracle Streamsオンライン・ヘルプは、Oracle Enterprise Managerを使用したOracle Streams環境の設定、管理および監視の手順について説明しています。

このドキュメント・ロードマップは、これらのドキュメントから必要な情報を検索する際に役立ちます。

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

- Oracle Streamsの概要に関するドキュメント

- Oracle Streams環境の設定または拡張に関するドキュメント

- Oracle Streams環境の管理に関するドキュメント

- Oracle Streams環境の監視に関するドキュメント

- Oracle Streamsを使用したアップグレードおよびメンテナンスに関するドキュメント

Oracle Streamsの概要に関するドキュメント

Oracle Streams環境を設定する前に、Oracle Streamsの機能および使用方法を理解しておくことをお薦めします。表1-1に、Oracle Streamsの概念を示します。

表1-1 Oracle Streamsの概要に関するドキュメント

概念を示す項目

参照先

適用プロセス

適用プロセスを使用したデータベース変更およびその他のメッセージ・タイプの適用に関する基本情報については、Oracle Database 2日でデータ・レプリケーションおよび統合ガイド

適用プロセスの一般概念については、「適用プロセスによる暗黙的コンシューム」

依存性のある変更の適用やDML変更とDDL変更の適用など、適用プロセスの高度な概念については、第10章「適用プロセスの高度な概念」

取得プロセス

取得プロセスを使用してREDOログに記録されたデータベース変更を取得する際の基本情報については、Oracle Database 2日でデータ・レプリケーションおよび統合ガイド

取得プロセスの一般概念については、「Oracle Streams取得プロセスによる暗黙的取得」

単一のデータベースにおける複数の取得プロセスや取得プロセスのチェックポイントなど、取得プロセスの高度な概念については、第7章「取得プロセスの高度な概念」

サプリメンタル・ロギングの概念については、『Oracle Streamsレプリケーション管理者ガイド』

アプリケーションによるメッセージの取得(明示的取得)

アプリケーションによるメッセージの取得の概要は、「アプリケーションによる明示的取得」

アプリケーションによるメッセージの取得の基本情報については、Oracle Database 2日でデータ・レプリケーションおよび統合ガイド

アプリケーションによるメッセージの取得の詳細は、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドを参照

取得と適用の複合による最適化

レプリケーション環境で取得プロセスから適用プロセスへデータベース変更をより効率的に送信することで、パフォーマンスを向上させる方法の詳細は、第12章「取得と適用の複合による最適化」

データの比較および収束

2つの異なるデータベースでデータベース・オブジェクトを比較して、その相違点を収束する方法の基本情報については、Oracle Database 2日でデータ・レプリケーションおよび統合ガイド

2つの異なるデータベースでデータベース・オブジェクトを比較して、その相違点を収束する方法の詳細は、『Oracle Streamsレプリケーション管理者ガイド』

競合および競合解決

レプリケートされた2つ以上の表で同じ行に対する変更がほぼ同時に行われた場合に発生する競合、および発生した競合の自動的な解決の基本情報については、Oracle Database 2日でデータ・レプリケーションおよび統合ガイド

競合と競合解決の詳細は、『Oracle Streamsレプリケーション管理者ガイド』

アプリケーションによるメッセージのコンシューム(明示的コンシューム)

アプリケーションによるメッセージのコンシュームの概要は、「手動デキューによる明示的コンシューム」

アプリケーションによるメッセージのコンシュームの基本情報については、Oracle Database 2日でデータ・レプリケーションおよび統合ガイド

アプリケーションによるメッセージのコンシュームの詳細は、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイド

異機種間での情報の共有

Oracle以外のデータベースの処理の基本情報については、Oracle Database 2日でデータ・レプリケーションおよび統合ガイド

異機種間での情報の共有にXStreamを使用する方法の詳細は、『Oracle Database XStreamガイド』

Oracle以外のデータベースの処理の詳細は、『Oracle Streamsレプリケーション管理者ガイド』

高可用性

第13章「Oracle Streams高可用性環境」

高可用性オプションの詳細は、Oracle Database高可用性概要

情報のプロビジョニング

大量の情報を効率的に移動またはコピーする方法の詳細は、第35章「情報のプロビジョニングの概要」

インスタンス化

2つ以上のデータベースでレプリケーション用にデータベース・オブジェクトを準備する場合の詳細は、『Oracle Streamsレプリケーション管理者ガイド』

インスタンス化の詳細は、『Oracle Streamsレプリケーション管理者ガイド』

論理変更レコード(LCR)

Oracle Streamsでメッセージを使用してデータベース変更を記述する方法の詳細は、「論理変更レコード(LCR)」

メッセージ・クライアント

「メッセージ・クライアントによる明示的コンシューム」

Oracle Streamsのベスト・プラクティス

『Oracle Streamsレプリケーション管理者ガイド』

Oracle Streamsの機能

「Oracle Streamsの機能」

Oracle Streamsと他のOracle Databaseとの相互運用性

付録A「Oracle Streamsと他のデータベース・コンポーネントとの連携」

Oracle Streamsの制限事項

付録B「Oracle Streamsの制限事項」

Oracle Streamsの用途

「Oracle Streamsの用途」

伝播

キュー間でのメッセージの送信の基本情報については、Oracle Database 2日でデータ・レプリケーションおよび統合ガイド

伝播の一般概念については、「キュー間でのメッセージの伝播」

伝播の高度な概念については、第9章「伝播の高度な概念」

キュー

キューでのメッセージの格納方法の詳細は、「キュー」

キューの高度な概念については、第8章「キューの高度な概念」

キューの詳細は、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイド

ルール

ルールおよびOracle Streamsでのルールの使用の基本情報については、Oracle Database 2日でデータ・レプリケーションおよび統合ガイド

ルールに基づいてOracle Streamsクライアントの動作を決定する方法の詳細は、第5章「Oracle Streamsでのルールの使用方法」

ルールの高度な概念については、第11章「ルールの高度な概念」

ルールベースの変換

データベース・オブジェクトの異なるレプリカをサポートするルールベースの変換の基本情報については、Oracle Database 2日でデータ・レプリケーションおよび統合ガイド

ルールベースの変換の詳細は、第6章「ルールベースの変換」

同期取得

同期取得を使用してデータベース変更を取得する方法の基本情報については、Oracle Database 2日でデータ・レプリケーションおよび統合ガイド

同期取得の詳細は、「同期取得による暗黙的取得」

タグ

取得されるデータベース変更にタグによって情報を追加する方法の基本情報については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』

タグの詳細は、『Oracle Streamsレプリケーション管理者ガイド』

ユーザー・メッセージ

ユーザーおよびアプリケーションによって作成されてエンキューされるメッセージの基本情報については、「ユーザー・メッセージ」

ユーザー・メッセージの詳細は、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイド

Oracle Streams環境の設定または拡張に関するドキュメント

設定できるOracle Streams環境には多くのタイプがあり、様々なオプションを使用して設定できます。表1-2に、Oracle Streams環境の設定に必要なドキュメントを示します。

表1-2 Oracle Streams環境の設定または拡張に関するドキュメント

手順

参照先

Oracle Enterprise Managerを使用したOracle Streamsレプリケーション環境の設定

Oracle Enterprise Managerを使用して最も一般的なタイプのOracle Streamsレプリケーション環境を設定する場合の例については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』

Oracle Enterprise ManagerのStreamsレプリケーションの設定ウィザードについては、オンライン・ヘルプ

Oracle Enterprise ManagerのStreamsレプリケーションの設定ウィザードを開く手順については、『Oracle Streamsレプリケーション管理者ガイド』

1ステップのプロシージャを使用したOracle Streams レプリケーション 環境の設定

DBMS_STREAMS_ADMパッケージで1ステップのプロシージャを使用する場合の詳細な手順(プロシージャの実行前に行う必要のある決定とタスクを含む)は、『Oracle Streamsレプリケーション管理者ガイド』

DBMS_STREAMS_ADMパッケージの1ステップのプロシージャのリファレンス情報は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』

コンポーネントの個別構成によるOracle Streamsレプリケーション環境の設定

個々のコンポーネントを適切な順序で構成してOracle Streamsレプリケーション環境を設定する手順は、『Oracle Streamsレプリケーション管理者ガイド』

同期取得を使用するOracle Streamsレプリケーション環境を設定する手順の例については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』

次の例については、『Oracle Streams拡張例』

- 1つの表に変更をレプリケートする単純なレプリケーション環境を設定する手順の例

- ルールベースの変換を含む異機種間レプリケーション環境を設定する手順の例

- 競合解決を使用してn-wayレプリケーション環境を設定する手順の例

Oracle Streamsレプリケーション環境を設定できるパッケージのリファレンス情報は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』。これらのパッケージの詳細は、「Oracle提供のPL/SQLパッケージ」。

Oracle Enterprise Managerを使用したOracle Streamsレプリケーション環境の拡張

Oracle Enterprise Managerを使用して、データベースおよび表を追加することによって最も一般的なタイプのOracle Streamsレプリケーション環境を拡張する場合の例については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』

1ステップのプロシージャを使用したOracle Streamsレプリケーション環境の拡張

DBMS_STREAMS_ADMパッケージの1ステップのプロシージャを使用して、データベースおよび表を追加することによって最も一般的なタイプのOracle Streamsレプリケーション環境を拡張する場合の例については、『Oracle Streamsレプリケーション管理者ガイド』

Oracle Streamsレプリケーション環境を拡張できる1ステップのプロシージャのリファレンス情報は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』

コンポーネントの個別構成によるOracle Streamsレプリケーション環境の拡張

個々のコンポーネントを適切な順序で構成してOracle Streamsレプリケーション環境を拡張する場合の手順は、『Oracle Streamsレプリケーション管理者ガイド』

異機種間レプリケーション環境を拡張する手順の例については、『Oracle Streams拡張例』

Oracle Streamsレプリケーション環境を拡張できるパッケージのリファレンス情報は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』。これらのパッケージの詳細は、「Oracle提供のPL/SQLパッケージ」。

Oracle Streamsのメッセージ環境の設定

次の例については、Oracle Database 2日でデータ・レプリケーションおよび統合ガイド

- データベース間でメッセージを送信するメッセージング環境を設定する手順の例

- 新しいメッセージがキューに入るとアプリケーションに通知するメッセージ通知を設定する手順の例

メッセージング環境を設定する手順の詳細は、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイド

メッセージ環境の設定に使用されるパッケージ(DBMS_STREAMS_ADM、DBMS_STREAMS_MESSAGING、DBMS_AQADMおよびDBMS_AQを含む)のリファレンス情報は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』

Oracle Streamsのベスト・プラクティス

Oracle Streams環境の設定時のベスト・プラクティスについては、『Oracle Streamsレプリケーション管理者ガイド』

表領域リポジトリの設定

「表領域リポジトリの使用」

ファイル・グループ・リポジトリの設定

「ファイル・グループ・リポジトリの使用」

Oracle Streams環境の管理に関するドキュメント

Oracle Sterams環境は、Oracle提供のPL/SQLパッケージおよびOracle Enterprise Managerを使用して管理できます。表1-3に、Oracle Streams環境の管理に必要なドキュメントを示します。

表1-3 Oracle Streams環境の管理に関するドキュメント

管理の手順

参照先

適用プロセス

Oracle Enterprise Managerを使用した適用プロセスの起動、停止および設定の詳細は、Oracle Database 2日でデータ・レプリケーションおよび統合ガイド

Oracle Enterprise Managerを使用した適用ハンドラと適用タグの管理および適用プロセスの削除の詳細は、Oracle Enterprise Managerのオンライン・ヘルプ

Oracle提供パッケージを使用した適用プロセスの管理の詳細は、第 17章「 Oracle Streams情報コンシュームの管理」

取得プロセス

Oracle Enterprise Managerを使用した取得プロセスの起動と停止および取得プロセス・パラメータの設定の詳細は、Oracle Database 2日でデータ・レプリケーションおよび統合ガイド

Oracle Enterprise Managerを使用した取得プロセスの先頭SCNまたは開始SCNの設定および取得プロセスの削除の詳細は、Oracle Enterprise Managerのオンライン・ヘルプ

Oracle提供パッケージを使用した取得プロセスの管理の詳細は、「取得プロセスの管理」

サプリメンタル・ロギングの管理の詳細は、『Oracle Streamsレプリケーション管理者ガイド』

Oracle StreamsデータベースのDBIDまたはグローバル名の変更

『Oracle Streamsレプリケーション管理者ガイド』

データの比較および収束

DBMS_COMPARISONパッケージおよび関連するデータ・ディクショナリ・ビューの使用に関する基本情報については、Oracle Database 2日でデータ・レプリケーションおよび統合ガイド

DBMS_COMPARISONパッケージおよび関連するデータ・ディクショナリ・ビューの使用に関する詳細は、『Oracle Streamsレプリケーション管理者ガイド』

競合および競合解決

競合の回避と競合解決の構成の詳細は、『Oracle Streamsレプリケーション管理者ガイド』

Oracle Streamsでのエクスポート/インポート

「Oracle Streams環境での全データベースのエクスポート/インポートの実行」

情報のプロビジョニング

第36章「情報のプロビジョニングの使用」

インスタンス化

インスタンス化の実行の詳細は、『Oracle Streamsレプリケーション管理者ガイド』

論理変更レコード(LCR)

「取得LCRの追加属性の管理」

『Oracle Streamsレプリケーション管理者ガイド』

Oracle Streamsのベスト・プラクティス

Oracle Streams環境の管理に関する推奨事項の詳細は、『Oracle Streamsレプリケーション管理者ガイド』

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

『Oracle Streamsレプリケーション管理者ガイド』

Oracle Streamsに関連するOracle提供パッケージ

Oracle Streams環境を管理できるパッケージのリファレンス情報は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』。これらのパッケージの概要は、「Oracle提供のPL/SQLパッケージ」。

Point-in-TimeリカバリおよびOracle Streams

『Oracle Streamsレプリケーション管理者ガイド』

伝播

Oracle Enterprise Managerを使用した伝播の有効化および無効化の詳細は、Oracle Database 2日でデータ・レプリケーションおよび統合ガイド

Oracle Enterprise Managerを使用した伝播のスケジューリング、スケジュール解除および削除の詳細は、Oracle Enterprise Managerのオンライン・ヘルプ

Oracle提供パッケージを使用した伝播の管理の詳細は、「Oracle Streamsの伝播および伝播ジョブの管理」

Oracle提供パッケージおよびその他の管理インタフェースを使用した伝播の管理の詳細は、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイド

キュー

Oracle Enterprise Managerを使用したキューおよびキュー表の変更の詳細は、Oracle Database 2日でデータ・レプリケーションおよび統合ガイド

Oracle Enterprise Managerを使用したキュー、キュー表およびアドバンスト・キューイングの変換の管理の詳細は、Oracle Enterprise Managerのオンライン・ヘルプ

Oracle提供パッケージおよびその他の管理インタフェースを使用したキューの管理の詳細は、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイド

「キューの管理」

Oracle Streams構成の削除

「Oracle Streams構成の削除」

ソース・データベースの再同期化

『Oracle Streamsレプリケーション管理者ガイド』

ルール

Oracle Enterprise Managerを使用したルールの管理の詳細は、Oracle Enterprise Managerのオンライン・ヘルプ

Oracle提供パッケージを使用したルールの管理の詳細は、第18章「ルールの管理」

ルールベースの変換

Oracle Enterprise Managerを使用したルールベースの変換の管理の詳細は、Oracle Enterprise Managerのオンライン・ヘルプ

Oracle提供パッケージを使用したルールベースの変換の管理の詳細は、第19章「ルールベースの変換の管理」

同期取得

Oracle提供パッケージを使用した同期取得の管理の詳細は、「同期取得の管理」

タグ

『Oracle Streamsレプリケーション管理者ガイド』

トラブルシューティング

Oracle Enterprise Managerを使用したOracle Streamsアラートへの対応と適用エラーの管理の詳細は、Oracle Database 2日でデータ・レプリケーションおよび統合ガイド

Oracle Enterprise Managerを使用したOracle Streams環境のトラブルシューティングの詳細は、Oracle Enterprise Managerのオンライン・ヘルプ

Oracle Streams環境のトラブルシューティングの詳細は、第V部「Oracle Streams環境のトラブルシューティング」

使用不可能な宛先データベース

使用不可能な宛先データベースをレプリケーション環境から分離し、使用可能になった時点で再びレプリケーション環境にマージする方法の詳細は、『Oracle Streamsレプリケーション管理者ガイド』

Oracle Streams環境の監視に関するドキュメント

Oracle Sterams環境は、主にOracle提供のPL/SQLパッケージ、データ・ディクショナリ・ビューおよびOracle Enterprise Managerを使用して管理できます。表1-4に、Oracle Streams環境の管理に必要なドキュメントを示します。

表1-4 Oracle Streams環境の監視に関するドキュメント

監視の手順

参照先

適用プロセス

Oracle Enterprise Managerを使用した適用プロセス・プロパティおよび統計情報の監視の詳細は、Oracle Database 2日でデータ・レプリケーションおよび統合ガイド

Oracle Enterprise Managerを使用した適用プロセス・パラメータ、適用ハンドラおよび適用エラーの監視の詳細は、Oracle Enterprise Managerのオンライン・ヘルプ

データ・ディクショナリ・ビューを使用した適用プロセスの監視の詳細は、第26章「Oracle Streams適用プロセスの監視」

取得プロセス

Oracle Enterprise Managerを使用した取得プロセス・プロパティおよび統計情報の監視の詳細は、Oracle Database 2日でデータ・レプリケーションおよび統合ガイド

Oracle Enterprise Managerを使用した取得プロセス・パラメータの監視の詳細は、Oracle Enterprise Managerのオンライン・ヘルプ

データ・ディクショナリ・ビューを使用した取得プロセスの監視の詳細は、「取得プロセスの監視」

取得と適用の複合による最適化

「取得と適用の複合を使用する取得プロセスの判別」

「取得と適用の複合を使用する適用プロセスの判別」

互換性

Oracle Streamsクライアントと互換性のないデータベース・オブジェクトの表示の詳細は、「Oracle Streams環境での互換性の監視」

競合および競合解決

データ・ディクショナリ・ビューを使用した更新競合ハンドラの表示の詳細は、Oracle Database 2日でデータ・レプリケーションおよび統合ガイド

データ・ディクショナリ・ビューを使用した競合検出および更新競合ハンドラの監視の詳細は、『Oracle Streamsレプリケーション管理者ガイド』

Oracle Streamsに関連するデータ・ディクショナリ・ビュー

第22章「Oracle Streamsの静的データ・ディクショナリ・ビュー」

『Oracle Databaseリファレンス』

情報のプロビジョニング

第37章「ファイル・グループおよび表領域リポジトリの監視」

インスタンス化

『Oracle Streamsレプリケーション管理者ガイド』

論理変更レコード(LCR)

ストリームを介したLCRの追跡の詳細は、『Oracle Streamsレプリケーション管理者ガイド』

メッセージ機能

Oracle Enterprise Managerを使用したキュー、キュー統計およびキュー・サブスクライバの表示の詳細は、Oracle Database 2日でデータ・レプリケーションおよび統合ガイド

データ・ディクショナリ・ビューを使用したメッセージ環境の監視の詳細は、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイド

「キューおよびメッセージの監視」

「バッファ・キューの監視」

Oracle Streams管理者

「Oracle Streams管理者とその他のOracle Streamsユーザーの監視」

Oracle Streamsプール

「Oracle Streamsプールの監視」

Oracle Streamsのトポロジおよびパフォーマンス統計

第23章「Oracle Streamsのトポロジおよびパフォーマンスの監視」

伝播

Oracle Enterprise Managerを使用した伝播プロパティおよび統計の監視の詳細は、Oracle Database 2日でデータ・レプリケーションおよび統合ガイド

データ・ディクショナリ・ビューを使用した伝播の監視の詳細は、「Oracle Streamsの伝播および伝播ジョブの監視」

ルール

Oracle Enterprise Managerを使用したルールの監視の詳細は、Oracle Enterprise Managerのオンライン・ヘルプ

データ・ディクショナリ・ビューを使用したルールの監視の詳細は、第27章「ルールの監視」

ルールベースの変換

データ・ディクショナリ・ビューを使用したルールベースの変換の監視の詳細は、第28章「ルールベースの変換の監視」

同期取得

データ・ディクショナリ・ビューを使用した同期取得の監視の詳細は、「同期取得の監視」

注意: 現在、Oracle Enterprise Managerでは同期取得の監視はサポートされていません。

タグ

データ・ディクショナリ・ビューを使用したタグの監視の詳細は、『Oracle Streamsレプリケーション管理者ガイド』

Oracle Streamsを使用したアップグレードおよびメンテナンスに関するドキュメント

Oracle Streamsを使用すると、データベースのアップグレードなどの1回のみの操作を、わずかな停止時間または停止時間なしで実行できます。表1-5は、Oracle Streamsを使用して1回のみの操作を実行する際に必要なドキュメントを示します。

表1-5 Oracle Streamsを使用したデータのアップグレードおよびメンテナンスに関するドキュメント

手順

参照先

Oracle Streamsを使用した、わずかな停止時間または停止時間なしでのデータベースのアップグレードおよびメンテナンス操作の実行

Oracle Streamsを使用して、わずかな停止時間または停止時間なしで10.2以上のデータベースを現在のリリースにアップグレードする方法、およびOracle Streamsを使用して、わずかな停止時間または停止時間なしでデータベースをメンテナンスする方法の詳細は、付録D「Oracle Streamsを使用したオンラインでのデータベースのアップグレードおよびメンテナンス」。データベースのメンテナンス操作には、異なるプラットフォームへのデータベースの移行、異なるキャラクタ・セットへのデータベースの移行、ユーザー作成アプリケーションへのアップグレードをサポートするためのデータベース・スキーマ・オブジェクトの変更、およびOracle Databaseソフトウェアのパッチまたはパッチ・セットの適用が含まれます。

Oracle Streamsを使用した、わずかな停止時間または停止時間なしでのデータベースのアップグレード

Oracle Streamsを使用して、わずかな停止時間または停止時間なしで10.1以下のデータベースを現在のリリースにアップグレードする方法の詳細は、付録E「Oracle Streamsを使用した10.1以下のデータベースのオンラインでのアップグレード」

2 Oracle Streams情報取得

Oracle Streamsでの情報の取得とは、情報を含むメッセージを作成し、そのメッセージをキューにエンキューすることです。取得される情報は、データベースの変更に関する説明の場合もあれば、その他の情報である場合もあります。

次の各項では、Oracle Streamsによる情報の取得の概念について説明します。

- Oracle Streamsで情報を取得する方法

- Oracle Streamsで取得される情報のタイプ

- Oracle Streamsでの情報取得オプションのまとめ

- Oracle Streams環境でのインスタンス化

- Oracle Streams取得プロセスによる暗黙的取得

- 同期取得による暗黙的取得

- アプリケーションによる明示的取得

関連項目:

- 暗黙的取得の構成の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- 第15章「Oracle Streams暗黙的取得の管理」

- 「取得プロセスの問題のトラブルシューティング」

- 第24章「Oracle Streams暗黙的取得の監視」

Oracle Streamsで情報を取得する方法

Oracle Streamsで情報を取得する方法には、暗黙的取得と明示的取得の2つがあります。

- 暗黙的取得

- 明示的取得

暗黙的取得

暗黙的取得では、取得プロセスまたは同期取得によってデータ定義言語(DDL)とデータ操作言語(DML)の変更が自動的に取得されます。論理変更レコード(LCR)と呼ばれる特殊なタイプのメッセージに、このようなデータベースの変更が記述されています。取得プロセスと同期取得は両方とも、ユーザー定義のルールを使用してデータベース変更をフィルタ処理できます。したがって、指定したオブジェクトに対する変更のみを取得できます。

次の各項では、取得プロセスと同期取得について説明します。

- 取得プロセス

- 同期取得

取得プロセス

取得プロセスは、オンラインREDOログのマイニングまたは必要であればアーカイブ・ログ・ファイルのマイニングを行って、REDOログから変更データを取り出します。データを取り出したら、取得プロセスはそのデータをLCR形式にフォーマットし、さらに処理するためにエンキューします。

取得プロセスは、データベース変更に関する情報を、LCRを含むメッセージの形式でエンキューします。取得プロセスが取得してエンキューしたLCRを含むメッセージは、取得LCRと呼ばれます。取得プロセスでは、メッセージは常にバッファ・キューにエンキューされます。バッファ・キューは、メモリーへのメッセージの格納にOracle Streamsプールを使用し、メモリーからオーバーフローしたメッセージの格納にキュー表を使用するキューの一部です。

取得プロセスは次の場合に役立ちます。

- 比較的多数の表への変更を取得するとき

- スキーマまたはデータベース全体への変更を取得するとき

- DDL変更を取得するとき

- ダウンストリーム取得を使用してソース・データベース以外のデータベースで変更を取得するとき

関連項目:

- 「Oracle Streams取得プロセスによる暗黙的取得」

- 「永続キューおよびバッファ・キュー」

同期取得

同期取得では、内部メカニズムを使用して、DML変更を発生直後に取得します。DML変更に関する情報は、行LCRを含むメッセージの形式で取得します。これらのLCRは永続キューにエンキューされます。同期取得では、メッセージは常に永続キューにエンキューされます。永続キューは、メッセージをメモリーではなくハード・ディスクのキュー表にのみ格納するキューの一部です。同期取得で取得されるメッセージは、永続LCRです。

同期取得は次の場合に役立ちます。

- 比較的少数の表へのDML変更を取得するとき(最適なパフォーマンスが得られる)

- 表へのDML変更を変更直後に取得するとき

関連項目:

- 「同期取得による暗黙的取得」

明示的取得

明示的取得では、アプリケーションがメッセージを生成してエンキューします。これらのメッセージはLCRとして書式設定することも、他のアプリケーションでコンシュームするために別の型で書式設定することもできます。また、メッセージは、適用プロセスまたは適用プロセスの適用ハンドラによって明示的にエンキューできます。

明示的取得は次の場合に役立ちます。

- アプリケーションが生成するメッセージを他のアプリケーションで処理する必要があるとき。

- 異機種レプリケーション環境で、Oracle Databaseの適用プロセスが、Oracle以外のデータベースで行われた変更を適用するとき。この場合、Oracle以外のデータベースでの変更に基づいてアプリケーションがLCRを取得し、それらのLCRはOracle Databaseで適用プロセスによって処理されます。

関連項目:

- 「アプリケーションによる明示的取得」

- Oracle Streamsでの異機種間の情報共有の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

Oracle Streamsで取得される情報のタイプ

Oracle Streamsで取得される情報のタイプは、次のとおりです。

- 論理変更レコード(LCR)

- ユーザー・メッセージ

論理変更レコード(LCR)

LCRとは、データベースの変更を記述する、特定のフォーマットのメッセージです。行LCRとDDL LCRという2種類のLCRがあります。取得プロセス、同期取得またはアプリケーションがLCRを取得できます。

Oracle Streamsでは次のタイプのLCRを取得できます。

- 取得LCRは、取得プロセスによって暗黙的に取得され、ANYDATAキューのバッファ・キュー部分にエンキューされるLCRです。

- 永続LCRは、ANYDATAキューの永続キュー部分にエンキューされるLCRです。永続LCRは次のいずれかの方法でエンキューできます。

- 同期取得による暗黙的な取得およびエンキュー

- アプリケーションによる明示的な作成およびエンキュー

- 適用プロセスによるデキュー、および同じ適用プロセスによるDBMS_APPLY_ADMパッケージ内のSET_ENQUEUE_DESTINATIONプロシージャを使用したエンキュー

これら3つの方法で取得された各永続LCR間の唯一の違いは、同期取得で取得された永続LCRの方が、アプリケーションによって作成された場合や適用プロセスによってエンキューされた場合よりも、属性が多くなるという点です。

- バッファLCRは、アプリケーションによって明示的に作成され、ANYDATAキューのバッファ・キュー部分にエンキューされるLCRです。

次の各項では、LCRの情報について説明します。

- 行LCR

- DDL LCR

- LCRのその他の情報

関連項目:

- 「永続キューおよびバッファ・キュー」

- LCRの管理の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- LCRタイプの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

- SET_ENQUEUE_DESTINATIONプロシージャの詳細は、「ルールを満たすメッセージの宛先キューの設定」を参照

行LCR

行LCRでは、1行のデータに対する変更、あるいは1行の1つのLOB列、LONG列、LONG RAW列、またはCLOB列として格納されたXMLTypeに対する変更が記述されます。この変更は、データ操作言語(DML)文またはピース単位の操作によるものです。たとえば、1つのDML文で、表への複数行の挿入またはマージ、表の複数行の更新、表からの複数行の削除を実行できます。アプリケーションでLCRを構築して、さらに処理を行うためにエンキューすることもできます。

単一のDML文で複数の行LCRが生成される可能性があります。つまり、取得プロセスではDML文によって変更される行ごとに行LCRが作成されます。また、1つのLOB、LONG列、LONG RAW列、またはCLOB列として格納されたXMLTypeに対する更新によって複数の行LCRが生成されることがあります。

それぞれの行LCRは、LCR$_ROW_RECORDタイプのオブジェクトにカプセル化されます。次の表2-1は、行LCRごとに存在する属性の一覧です。

表2-1 すべての行LCRに含まれる属性

属性

説明

source_database_name

行の変更が発生したソース・データベースの名前。

command_type

変更を生成したDML文のタイプ(INSERT、UPDATE、DELETE、LOB ERASE、LOB WRITEまたはLOB TRIM)。

object_owner

行に変更があった表を含むスキーマの名前。

object_name

変更があった行を含む表の名前。

tag

LCRの追跡に使用できるRAWタグ。

transaction_id

DML文が実行されたトランザクションの識別子。

scn

変更が行われた時点のシステム変更番号(SCN)。

old_values

変更に関連する古い列の値。DML変更が行われる前の行の列値です。DML文のタイプがUPDATEまたはDELETEの場合、古い値には、DML文以前の変更対象行の一部またはすべての列が含まれます。DML文のタイプがINSERTの場合、古い値はありません。UPDATE文とDELETE文では、取得プロセスで作成される行LCRには、行の古い列値の一部またはすべてが含まれることがありますが、同期取得で作成される行LCRには、常に行の新しい列値すべてが含まれます。

new_values

変更に関連する新しい列の値。DML変更が行われた後の行の列値です。DML文のタイプがUPDATEまたはINSERTの場合、新しい値には、DML文の後の変更対象行の一部またはすべての列が含まれます。DML文のタイプがDELETEの場合、新しい値はありません。UPDATE文とINSERT文では、取得プロセスで作成される行LCRには、行の新しい列値の一部またはすべてが含まれることがありますが、同期取得で作成される行LCRには、常に行の新しい列値すべてが含まれます。

position

各LCRのRAWデータ型の一意の識別子。positionは、トランザクション内およびトランザクション全体で正確に増加します。

LCRのpositionは、一般的にXStream構成で使用されます。

『Oracle Database XStreamガイド』を参照してください。

取得プロセスまたは同期取得プロセスによって取得された行LCRには、追加の属性が含まれます。表2-2には、それらの追加属性が説明されています。またこの表には、取得プロセスで取得された行LCRと同期取得プロセスで取得された行LCRに、それぞれの属性が含まれるかどうかも示しています。これらの属性は、明示的に取得された行LCRには含まれません。

表2-2 取得された行LCRの追加の属性

属性

説明

取得プロセスの行LCRに含まれるか

同期取得の行LCRに含まれるか

commit_scn

LCRが属するトランザクションのコミット・システム変更番号(SCN)。

はい

いいえ

commit_scn_from_position

入力位置によって決定された、トランザクションのコミット・システム変更番号(SCN)。XStreamアウトバウンド・サーバーによって生成される。

はい

いいえ

commit_time

LCRが属するトランザクションのコミット時間。

はい

いいえ

compatible

そのLCRのサポートに必要なデータベースの最小互換レベル。

はい

はい

instance_number

変更が加えられたデータベース・インスタンスのうち、そのLCR内にカプセル化されたインスタンスの数。通常、インスタンス数はOracle Real Application Clusters(Oracle RAC)の構成に関連する。

はい

はい

lob_information

列のLOB情報(NOT_A_LOBやLOB_CHUNKなど)。

はい

いいえ

lob_offset

指定された列のLOBオフセット(CLOB列の文字数とBLOB列のバイト数)。

はい

いいえ

lob_operation_size

LOB列の操作サイズ(CLOB列の文字数とBLOB列のバイト数)。

はい

いいえ

long_information

列のLONG情報(NOT_A_LONGやLONG_CHUNKなど)。

はい

いいえ

row_text

行LCR内にカプセル化された変更に対応するSQL文。

はい

はい

scn_from_position

入力位置によって決定された、トランザクションのコミット・システム変更番号(SCN)。XStreamアウトバウンド・サーバーによって生成される。

はい

いいえ

source_time

取得プロセスによって取得されたLCR内の変更がソース・データベースのREDOログ内に生成された時刻か、または永続LCRが作成された時刻。

はい

はい

xml_information

列のXML情報(NOT_XML、XML_DOC、XML_DIFFなど)。

はい

いいえ

取得プロセスまたは同期取得で取得された行LCRには、トランザクション制御文が含まれていることもあります。これらの行LCRには、COMMITやROLLBACKなどのトランザクション制御ディレクティブが含まれています。このような行LCRは、ソース・データベースと宛先データベースの間でトランザクションの一貫性を保つために適用プロセスによって内部的に使用されます。

DDL LCR

DDL LCRでは、データ定義言語(DDL)の変更が記述されます。DDL文は、データベースの構造を変更します。たとえば、DDL文でデータベース・オブジェクトを作成、変更または削除できます。

それぞれのDDL LCRは、LCR$_DDL_RECORDタイプのオブジェクトにカプセル化されます。次の表2-3は、DDL LCRごとに存在する属性の一覧です。

表2-3 すべてのDDL LCRに含まれる属性

属性

説明

source_database_name

行の変更が発生したソース・データベースの名前。

command_type

変更を生成したDDL文のタイプ(ALTER TABLE、CREATE INDEXなど)。

object_owner

DDL文が実行されたデータベース・オブジェクトを所有しているユーザーのスキーマ名。

object_name

DDL文が実行されたデータベース・オブジェクトの名前。

object_type

DDL文が実行されたデータベース・オブジェクトのタイプ(TABLE、PACKAGEなど)。

ddl_text

DDL文のテキスト。

logon_user

ログオン・ユーザー。DDL文を実行したセッションのユーザーです。

current_schema

DDLテキストでオブジェクトに対するスキーマが指定されていない場合に使用されるスキーマ。

base_table_owner

実表の所有者。DDL文が表に依存する場合、実表の所有者は依存先となる表の所有者です。

base_table_name

実表の名前。DDL文が表に依存する場合、実表の名前は依存先となる表の名前です。

tag

LCRの追跡に使用できるRAWタグ。

transaction_id

DDL文が実行されたトランザクションの識別子。

scn

変更が行われた時点のシステム変更番号(SCN)。

position

各LCRのRAWデータ型の一意の識別子。positionは、トランザクション内およびトランザクション全体で正確に増加します。

LCRのpositionは、一般的にXStream構成で使用されます。

『Oracle Database XStreamガイド』を参照してください。

edition_name

DDL文が実行されたエディションの名前。

取得プロセスによって取得されたDDL LCRには、追加の属性が含まれます。表2-2には、それらの追加属性が説明されています。同期取得ではDDLの変更を取得することができないため、これらの属性は、明示的に取得されたDDL LCRには含まれません。

表2-4 取得されたDDL LCRの追加の属性

属性

説明

commit_scn

LCRが属するトランザクションのコミット・システム変更番号(SCN)。

commit_scn_from_position

入力位置によって決定された、トランザクションのコミット・システム変更番号(SCN)。XStreamアウトバウンド・サーバーによって生成される。

commit_time

LCRが属するトランザクションのコミット時間。

compatible

そのLCRのサポートに必要なデータベースの最小互換レベル。

instance_number

変更が加えられたデータベース・インスタンスのうち、そのLCR内にカプセル化されたインスタンスの数。通常、インスタンス数はOracle Real Application Clusters(Oracle RAC)の構成に関連する。

scn_from_position

入力位置によって決定された、トランザクションのコミット・システム変更番号(SCN)。XStreamアウトバウンド・サーバーによって生成される。

source_time

取得プロセスによって取得されたLCR内の変更がソース・データベースのREDOログ内に生成された時刻か、または永続LCRが作成された時刻。

注意:
行LCRとDDL LCRの両方に、変更が発生したデータベースのソース・データベース名が含まれています。取得LCRが伝播によって伝播されるか、適用プロセスによって適用される場合は、伝播と適用に伴う問題を回避するために、取得プロセスによる変更の取得が開始された後はソース・データベースの名前を変更しないことをお薦めします。

関連項目:

- SQLコマンド・コード表のDDL文のタイプの完全なリストについては、『Oracle Call Interfaceプログラマーズ・ガイド』を参照

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

LCRのその他の情報

行LCRとDDL LCRには、先の各項で説明した情報の他にも、表2-5に示す情報(LCR属性)をオプションとして含めることができます。

表2-5 LCRのその他の属性

属性

説明

row_id

行LCRの変更された行のROWID。この属性は、索引構成表のDDL LCRまたは行LCRには含まれません。

serial#

LCRに取得された変更を実行したセッションのシリアル番号。

session#

LCRに取得された変更を実行したセッションの識別子。

thread#

LCRに取得された変更を実行したインスタンスの番号。通常、スレッド番号が使用されるのはOracle Real Application Clusters(Oracle RAC)環境のみです。

tx_name

LCRを含むトランザクションの名前。

username

LCRに取得された変更を実行した現行ユーザーの名前。

DBMS_CAPTURE_ADMパッケージのINCLUDE_EXTRA_ATTRIBUTEプロシージャを使用すると、これらの1つ以上の属性を取得するように取得プロセスまたは同期取得に指定できます。

関連項目:

- 「取得LCRの追加属性の管理」

- 「暗黙的取得によって取得された追加属性の表示」

- INCLUDE_EXTRA_ATTRIBUTEプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

- 現在のユーザーの詳細は、『Oracle Database PL/SQL言語リファレンス』を参照

ユーザー・メッセージ

LCRを含まないメッセージは、ユーザー・メッセージと呼ばれます。ユーザー・メッセージはどのタイプ(LCRタイプを除く)でもかまいません。ユーザー・メッセージは、アプリケーションによって作成され、アプリケーションによってコンシュームされます。たとえば、ビジネス・アプリケーションが各注文に対してユーザー・メッセージを作成し、そのメッセージを別のアプリケーションが処理することができます。

Oracle Streamsでは次のタイプのユーザー・メッセージを取得できます。

- 永続ユーザー・メッセージは、永続キューにエンキューされるユーザー定義型のLCR以外のメッセージです。永続ユーザー・メッセージは次のいずれかの方法でエンキューできます。

- アプリケーションによる明示的な作成およびエンキュー

- 適用プロセスによるデキュー、および同じ適用プロセスによるDBMS_APPLY_ADMパッケージ内のSET_ENQUEUE_DESTINATIONプロシージャを使用したエンキュー

永続ユーザー・メッセージはANYDATAキューまたは型付きキューの永続キュー部分にエンキューできます。

- バッファ・ユーザー・メッセージは、アプリケーションによって明示的に作成され、バッファ・キューにエンキューされるユーザー定義型のLCR以外のメッセージです。バッファ・ユーザー・メッセージは、ANYDATAキューまたは型付きキューのバッファ・キュー部分にエンキューできます。

注意:
取得プロセスと同期取得がユーザー・メッセージを取得することはありません。

関連項目:

- 「永続キューおよびバッファ・キュー」

- SET_ENQUEUE_DESTINATIONプロシージャの詳細は、「ルールを満たすメッセージの宛先キューの設定」を参照

- メッセージングのANYDATAキューの詳細は、『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイド』を参照

Oracle Streamsでの情報取得オプションのまとめ

表2-6に、Oracle Streamsで使用可能な取得オプションのまとめを示します。

表2-6 Oracle Streamsでの情報取得オプション

取得のタイプ

取得のメカニズム

メッセージのタイプ

エンキューされるキュー

使用ケース

Oracle Streams取得プロセスによる暗黙的取得

REDOログのマイニング

取得LCR

バッファ・キュー

多数の表への変更を取得するとき。

スキーマまたはデータベース全体への変更を取得するとき。

DDL変更を取得するとき。

ダウンストリーム・データベースで変更を取得するとき。

同期取得による暗黙的取得

内部メカニズム

永続LCR

永続キュー

少数の表へのDML変更を取得するとき。

DML変更を直後に取得するとき。

アプリケーションによる明示的取得

手動でのメッセージ作成とエンキュー

バッファLCR

永続LCR

バッファ・ユーザー・メッセージ

永続ユーザー・メッセージ

バッファ・キューまたは永続キュー

アプリケーションでコンシュームされるユーザー・メッセージを取得するとき。

異機種レプリケーション環境でLCRを取得するとき。

取得プロセスまたは同期取得のかわりにアプリケーションを使用してLCRを作成するとき。

注意:
1つのデータベースで、この表の取得オプションを任意に組み合せて使用することができます。

関連項目:

- 「永続キューおよびバッファ・キュー」

Oracle Streams環境でのインスタンス化

Oracle Streams環境では、単一データベース内または複数データベース間でデータベース・オブジェクトを共有できます。データベース・オブジェクトを共有し、暗黙的取得を使用してデータベース・オブジェクトへの変更を取得するOracle Streams環境では、ソース・データベースが変更が行われるデータベースです。ソース・データベースは、使用される暗黙的取得のタイプに応じて次のいずれかになります。

- 取得プロセスが変更を取得する場合、ソース・データベースは、オブジェクトへの変更がREDOログに生成されるデータベースです。

- 同期取得が変更を取得する場合、ソース・データベースは、同期取得が構成されているデータベースです。

変更が取得された後は、ローカルに適用されるか、他のデータベースに伝播されて宛先データベースで適用できます。

データベース・オブジェクトを共有するOracle Streams環境では、共有ソース・データベース・オブジェクトをインスタンス化する必要があります。その後、データベース・オブジェクトへの変更を適用プロセスでデキューして処理できるようになります。ソース・データベース・オブジェクトへの変更が適用されるデータベースが、ソース・データベースと異なる場合は、宛先データベースにこれらのデータベース・オブジェクトのコピーが必要です。

Oracle Streamsではデータベース・オブジェクトをインスタンス化するために、一般的には次の手順を実行します。

1. ソース・データベースでオブジェクトのインスタンス化を準備します。

2. オブジェクトのコピーが接続先データベースに存在しない場合は、ソース・データベースのオブジェクトに基づいて、接続先データベースでオブジェクトを物理的に作成します。エクスポートとインポート、トランスポータブル表領域またはRMANを使用してインスタンス化のためにデータベース・オブジェクトをコピーします。データベース・オブジェクトが接続先データベースにすでに存在している場合、この手順は必要ありません。

3. 宛先データベースでデータベース・オブジェクトのインスタンス化SCNを設定します。インスタンス化システム変更番号(SCN)によって、指定SCNの後にソース・データベースでコミットされた変更のみを適用するように、宛先データベースの適用プロセスに指示されます。

場合によっては、手順1と手順3は自動的に行われます。たとえば、DBMS_STREAMS_ADMパッケージのプロシージャを実行してオブジェクトのルールを取得プロセスのポジティブ・ルール・セットに追加すると、オブジェクトのインスタンス化が自動的に準備されます。また、エクスポート/インポートまたはトランスポータブル表領域を使用して、ソース・データベースのデータベース・オブジェクトを宛先データベースにコピーすると、これらのオブジェクトのインスタンス化SCNを自動的に設定できます。インスタンス化は、適用プロセスが取得LCRをデキューするときには常に必要です。適用プロセスがLCRを適用ハンドラに送信し、適用ハンドラがLCRを実行しない場合にも必要です。

関連項目:

- Oracle Streamsレプリケーション環境のインスタンス化の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

Oracle Streams取得プロセスによる暗黙的取得

この項では、Oracle Streamsの取得プロセスに関連する概念について説明します。

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

- 取得プロセスの概要

- 取得プロセスのルール

- 取得プロセスによって取得されるデータ型

- 取得プロセスによって取得されるDML変更のタイプ

- Oracle Streams環境内のサプリメンタル・ロギング

- ローカル取得およびダウンストリーム取得

- 取得プロセスに関連するSCN値

- Oracle Streamsの取得プロセスおよびRESTRICTED SESSION

- 取得プロセスのサブコンポーネント

- 取得ユーザー

- 取得プロセスの状態

- 取得プロセス・パラメータ

- データベースの再起動時における取得プロセスの永続的状態

取得プロセスの概要

各Oracle Databaseには、複数のREDOログ・ファイルのセットがあります。データベースのREDOログ・ファイルを総称して、データベースのREDOログと呼びます。REDOログの主要な機能は、データベースに対して行われた変更をすべて記録することです。

REDOログは、人為的エラーやメディア障害が発生した場合のリカバリ能力を保証するために使用されます。取得プロセスはオプションのOracleバックグラウンド・プロセスであり、データベースのREDOログをスキャンし、データベース・オブジェクトに対するデータ操作言語(DML)変更とデータ定義言語(DDL)変更を取得します。取得プロセスがREDOログから変更を取得するように構成されている場合、変更が生成されるデータベースは、その取得プロセスのソース・データベースと呼ばれます。

取得プロセスはデータベースの変更を取得すると、論理変更レコード(LCR)と呼ばれる特殊なメッセージ・フォーマットに変換します。LCRを取得した後、取得プロセスはLCRを含むメッセージをキューにエンキューします。取得プロセスは常に1つのANYDATAキューと関連付けられており、このキューのみにメッセージをエンキューします。パフォーマンスの向上のため、取得LCRは常にバッファ・キューに格納されます。このキューは、キューに関連付けられているシステム・グローバル領域(SGA)メモリーです。複数のキューを作成して各キューに別の取得プロセスを関連付けることができます。

取得LCRは、伝播によって同じデータベースまたは他のデータベースのキューに送信できます。また、取得LCRは、適用プロセスによってデキューできます。状況によっては、最適化を行って、取得プロセスでLCRを適用プロセスにより効率的に送信することもできます。このような最適化は、取得と適用の複合と呼ばれます。

取得プロセスは、ソース・データベースまたはリモート・データベース上で実行されます。取得プロセスをソース・データベース上で実行する場合、取得プロセスはローカル取得プロセスです。取得プロセスがリモート・データベース上で実行される場合、取得プロセスはダウンストリーム取得プロセスであり、そのリモート・データベースはダウンストリーム・データベースと呼ばれます。

図2-1に、LCRを取得する取得プロセスを示します。

図2-1 取得プロセス

注意:

- 取得プロセスを関連付けることができるのはANYDATAキューのみです。型付きキューに関連付けることはできません。

- 同じ表に対して行われた変更が取得プロセスと同期取得によって取得されないようにする必要があります。

関連項目:

- 「論理変更レコード(LCR)」

- 「Oracle Streams環境内のサプリメンタル・ロギング」

- 第12章「取得と適用の複合による最適化」

取得プロセスのルール

取得プロセスは、定義したルールに基づいて変更を取得または廃棄します。各ルールによって、TRUEと評価されるデータベース・オブジェクトおよび変更のタイプを指定します。これらのルールは、取得プロセスのポジティブ・ルール・セットまたはネガティブ・ルール・セットに含めることができます。

ルールが変更をTRUEと評価し、そのルールが取得プロセスのポジティブ・ルール・セットに含まれる場合、取得プロセスはその変更を取得します。ルールが変更をTRUEと評価し、そのルールが取得プロセスのネガティブ・ルール・セットに含まれる場合、取得プロセスはその変更を廃棄します。取得プロセスにポジティブ・ルール・セットとネガティブ・ルール・セットの両方がある場合、ネガティブ・ルール・セットが常に最初に評価されます。

取得プロセスのルールは次のレベルで指定できます。

- 表ルールは、特定の表に対するDML変更による行変更またはDDL変更を取得または廃棄します。サブセット・ルールは、特定の表に対する行変更のサブセットを含む表ルールです。

- スキーマ・ルールは、特定のスキーマのデータベース・オブジェクトに対するDML変更による行変更またはDDL変更を取得または廃棄します。

- グローバル・ルールは、データベース内のDML変更によるすべての行変更またはすべてのDDL変更を取得または廃棄します。

注意:
取得プロセスは、特定のタイプの変更および表の列の特定のデータ型に対する変更を取得しません。また、SYS、SYSTEMまたはCTXSYSスキーマ内での変更は取得しません。

関連項目:

- 第11章「ルールの高度な概念」

- 第5章「Oracle Streamsでのルールの使用方法」

取得プロセスによって取得されるデータ型

表に対するDML変更による行の変更を取得するとき、取得プロセスは、次のデータ型の列に対して行われる変更を取得できます。

- VARCHAR2

- NVARCHAR2

- FLOAT

- NUMBER

- LONG

- DATE

- BINARY_FLOAT

- BINARY_DOUBLE

- TIMESTAMP

- TIMESTAMP WITH TIME ZONE

- TIMESTAMP WITH LOCAL TIME ZONE

- INTERVAL YEAR TO MONTH

- INTERVAL DAY TO SECOND

- RAW

- LONG RAW

- CHAR

- NCHAR

- UROWID

- BASICFILEまたはSECUREFILE記憶域を持つCLOB

- BASICFILEまたはSECUREFILE記憶域を持つNCLOB

- BASICFILEまたはSECUREFILE記憶域を持つBLOB

- CLOBとして格納されているXMLType

注意:

- これらのデータ型の一部は、以前のリリースのOracle DatabaseのOracle Streamsではサポートされていない場合があります。Oracle Streams環境に旧リリースのOracle Databaseが1つ以上あるときは、サポートしていない行LCRデータ型のあるデータベースに、その行LCRが送られないようにしてください。サポートされるデータ型の詳細は、以前のリリースのOracle Streamsドキュメントを参照してください。

- 取得プロセスでは、データベース互換性レベルが11.2.0以上に設定されている場合のみ、SecureFiles LOB列への変更を取得できます。

関連項目:

- SecureFiles LOBの制限事項を含む、取得プロセスのデータ型の制限事項の詳細は、「取得プロセスではサポートされていないデータ型」を参照

- 第5章「Oracle Streamsでのルールの使用方法」

- 「適用されるデータ型」

- データ型の詳細は、『Oracle Database SQL言語リファレンス』を参照

- データベースの互換性の詳細は、『Oracle Databaseアップグレード・ガイド』を参照

取得プロセスによって取得されるDML変更のタイプ

特定の表に対して行われたDML変更が取得されるように指定した場合、取得プロセスでは、これらの表に対して行われた次のタイプのDML変更が取得されます。

- INSERT

- UPDATE

- DELETE

- MERGE

- ピース単位の操作

取得プロセスによって、MERGEの変更がそれぞれINSERTまたはUPDATEの変更に変換されます。MERGEは、行LCRでは無効なコマンド・タイプです。

関連項目:

- 「取得プロセスではサポートされていない表タイプ」

- 適用プロセスで適用可能な変更のタイプの詳細は、第4章「Oracle Streams情報コンシューム」を参照

Oracle Streams環境内のサプリメンタル・ロギング

サプリメンタル・ロギングでは、操作が実行されるたびにREDOログに列データが追加されます。取得プロセスは、この追加情報を取得してLCRに含めます。サプリメンタル・ロギングは、ソース・データベースに対する変更を取得する取得プロセスの場所に関係なく、常にソース・データベースで構成されます。

通常、Oracle Streamsレプリケーション環境ではサプリメンタル・ロギングが必要です。これらの環境の適用プロセスでは、ソース・データベースから宛先データベースにレプリケートされる変更を適切に適用するために、LCRの追加情報が必要になります。ただし、適用プロセスによって変更がデータベース・オブジェクトに直接適用されない環境でも、サプリメンタル・ロギングが必要な場合があります。このような環境では、適用ハンドラによって、データベース・オブジェクトに適用されることなく変更が処理され、適用ハンドラで補足情報が必要になる場合があります。

関連項目:

- サプリメンタル・ロギングの詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- ソース・データベースでのサプリメンタル・ロギングを必要とする適用プロセスの動作の詳細は、「表へのDML変更の適用に関する考慮事項」を参照

- 値の依存性の詳細は、「仮想依存性定義」を参照

- ビットマップ索引列および適用プロセスの並列性の詳細は、「適用プロセスで依存トランザクションを待機しているか」を参照

- 第6章「ルールベースの変換」

ローカル取得およびダウンストリーム取得

取得プロセスは、ソース・データベースでローカルに実行されるか、またはダウンストリーム・データベースで実行されるように構成できます。単一のデータベースに、ローカルの変更を取得する1つ以上の取得プロセスおよびリモート・ソース・データベースの変更を取得する他の取得プロセスを含めることができます。つまり、単一のデータベースを構成することによって、ローカル取得およびダウンストリーム取得の両方を実行できます。

ローカル取得

ローカル取得とは、取得プロセスがソース・データベースで実行される取得プロセスのことです。図2-1に、ローカル取得を使用するデータベースを示します。

ソース・データベースによるすべての変更取得アクションの実行

ローカル取得を構成すると、ソース・データベースで次のアクションが実行されます。

- DBMS_CAPTURE_ADM.BUILDプロシージャが実行され、データ・ディクショナリがREDOログに抽出(構築)されます。

- ソース・データベースでのサプリメンタル・ロギングによって、REDOログに追加情報が記録されます。この情報は、取得された変更が適用プロセスによって適用される際に必要になる場合があります。

- データベースで取得プロセスが初めて起動される場合、Oracle Databaseでは、REDOログ内の抽出されたデータ・ディクショナリ情報を使用して、LogMinerデータ・ディクショナリが作成されます。LogMinerデータ・ディクショナリは、ソース・データベースのプライマリ・データ・ディクショナリとは別のデータ・ディクショナリです。後続の取得プロセスでは、この既存のLogMinerデータ・ディクショナリを使用するか、または新しいLogMinerデータ・ディクショナリを作成できます。

- 取得プロセスで、LogMinerを使用してREDOログの変更がスキャンされます。

- ルール・エンジンによって、1つ以上の取得プロセスのルール・セットのルールに基づいて、変更が評価されます。

- 取得プロセスで、ルール・セットのルールを満たす変更がローカルのANYDATAキューにエンキューされます。

- 取得された変更が1つ以上の他のデータベースと共有されている場合、1つ以上の伝播によって、これらの変更がソース・データベースから他のデータベースに伝播されます。

- ソース・データベースのデータベース・オブジェクトを宛先データベースでインスタンス化する必要がある場合は、オブジェクトをインスタンス化のために準備し、エクスポート・ユーティリティなどのメカニズムを使用してデータベース・オブジェクトのコピーを作成する必要があります。

ローカル取得のメリット

ローカル取得を使用するメリットは次のとおりです。

- ダウンストリーム取得を使用する場合より、取得プロセスを簡単に構成および管理できます。ローカル取得を使用すると、ダウンストリーム・データベースにコピーされるようにREDOデータを構成する必要がなくなり、取得した変更が行われたデータベースでローカルに取得プロセスを管理できます。

- ローカル取得プロセスでは、データベースによってオンラインREDOログの変更がアーカイブREDOログ・ファイルに書き込まれる前に、これらの変更をスキャンできます。アーカイブ・ログ・ダウンストリーム取得プロセスを使用すると、ダウンストリーム・データベースへのアーカイブREDOログ・ファイルのコピーは、ソース・データベースによる変更の書込みが終了した後に行われるため、ダウンストリーム・データベースへのREDOログ・ファイルのコピーには時間がかかります。ただし、リアルタイム・ダウンストリーム取得プロセスは、ソース・データベースから送信されたオンラインREDOログの変更を取得できます。

- REDOデータがダウンストリーム・データベースにコピーされるわけではないため、ネットワークを介して送信されるデータの量が低減されます。取得LCRは、他のデータベースに伝播される場合でも、データベースに対する変更全体のサブセットであることがあり、伝播のルール・セットのルールを満たすLCRのみを伝播できます。

- REDOデータにアクセスできるのはソース(ローカル)データベースのみのため、セキュリティを向上できます。たとえば、hrスキーマの変更のみを取得プロセスで取得する場合にローカル取得を使用すると、REDOログにアクセスし、hrスキーマに対する変更を取得プロセスのキューにエンキューできるのはソース・データベースのみです。一方、ダウンストリーム取得を使用すると、REDOデータがダウンストリーム・データベースにコピーされ、REDOデータに、hrスキーマに対する変更のみではなく、データベースに対するすべての変更が含まれます。

- 取得プロセスがローカルのソース・データベースで実行されている場合、一部のタイプのカスタム・ルールベースの変換を簡単に構成できます。たとえば、ローカル取得を使用すると、カスタム・ルールベースの変換で、ソース・データベースに格納されたデータが移入されているPL/SQLセッション変数にキャッシュされた情報を使用できます。

- メッセージの取得および適用が同じデータベースで行われるOracle Streams環境では、取得された変更およびローカルのデータに関する情報が必要なローカルの問合せおよび計算を簡単に構成でき、使用されるリソースも少なくなります。

ダウンストリーム取得

ダウンストリーム取得とは、ソース・データベース以外のデータベースで実行される取得プロセスのことです。構成可能なダウンストリーム取得には、リアルタイム・ダウンストリーム取得およびアーカイブ・ログ・ダウンストリーム取得の2つのタイプがあります。downstream_real_time_mine取得プロセス・パラメータによって、ダウンストリーム取得プロセスでリアルタイム・ダウンストリーム取得またはアーカイブ・ログ・ダウンストリーム取得のいずれを実行するかが制御されます。ダウンストリーム・データベースには、1つのリアルタイム・ダウンストリーム取得プロセスと1つ以上のアーカイブ・ログ・ダウンストリーム取得プロセスが共存できます。

注意:

- このマニュアルでは、「ダウンストリーム取得プロセス」とは、リアルタイム・ダウンストリーム取得プロセスとアーカイブ・ログ・ダウンストリーム取得プロセスの両方のことを示します。必要に応じて、これら2つのタイプのダウンストリーム取得プロセスを区別しています。

- ダウンストリーム取得プロセスでは、単一のソース・データベースからの変更のみを取得できます。ただし、単一のダウンストリーム・データベースで複数のダウンストリーム取得プロセスを使用すると、単一のソース・データベースまたは複数のソース・データベースから変更を取得することができます。

- ダウンストリーム取得を構成するには、ソース・データベースがOracle Database 10g リリース1以上のデータベースである必要があります。

リアルタイム・ダウンストリーム取得

リアルタイム・ダウンストリーム取得構成は、次のように機能します。

- REDO転送サービスが、ソース・データベースでログ・ライター・プロセス(LGWR)を使用して、REDOデータをダウンストリーム・データベースに同期または非同期に送信します。同時に、LGWRは、REDOデータをソース・データベースのオンラインREDOログに記録します。

- ダウンストリーム・データベースのリモート・ファイル・サーバー・プロセス(RFS)が、ネットワークを介してREDOデータを受信し、スタンバイREDOログにREDOデータを格納します。

- ソース・データベースでログ・スイッチが発生すると、ダウンストリーム・データベースでもログ・スイッチが発生し、ダウンストリーム・データベースのARCHnプロセスによって、現行のスタンバイREDOログ・ファイルがアーカイブされます。

- リアルタイム・ダウンストリーム取得プロセスは、可能な場合は常にスタンバイREDOログからの変更を取得し、必要に応じてアーカイブ済スタンバイREDOログ・ファイルからの変更を取得します。取得プロセスは、遅延が発生すると、アーカイブ済スタンバイREDOログ・ファイルの変更を取得できるようになります。遅延が解消されたら、スタンバイREDOログからの変更の取得を再開します。

図2-2 リアルタイム・ダウンストリーム取得

アーカイブ・ログ・ダウンストリーム取得と比較すると、リアルタイム・ダウンストリーム取得には、ソース・データベースで行われた変更を短時間で取得できるというメリットがあります。リアルタイム・ダウンストリーム取得プロセスでは、REDOログ・ファイルからデータを取得する前に、REDOログ・ファイルがアーカイブされるまで待機する必要がないため、取得時間が短縮されます。

注意:
同じソース・データベースから変更を取得する複数のリアルタイム・ダウンストリーム取得プロセスを構成できますが、1つのダウンストリーム・データベースで複数のソース・データベースに対してリアルタイム・ダウンストリーム取得を構成することはできません。

アーカイブ・ログ・ダウンストリーム取得

アーカイブ・ログ・ダウンストリーム取得構成では、ソース・データベースのアーカイブREDOログ・ファイルがダウンストリーム・データベースにコピーされ、取得プロセスによってこれらのアーカイブREDOログ・ファイルの変更が取得されます。アーカイブREDOログ・ファイルをダウンストリーム・データベースにコピーするには、REDO転送サービス、DBMS_FILE_TRANSFERパッケージ、ファイル転送プロトコル(FTP)などのメカニズムを使用します。

図2-3 アーカイブ・ログ・ダウンストリーム取得

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

関連項目:
REDO転送サービスの詳細は、『Oracle Data Guard概要および管理』を参照

ダウンストリーム・データベースによるほとんどの変更取得アクションの実行

リアルタイム・ダウンストリーム取得またはアーカイブ・ログ・ダウンストリーム取得のいずれかを構成すると、ダウンストリーム・データベースで次のアクションが実行されます。

- ダウンストリーム・データベースでダウンストリーム取得プロセスが初めて起動される場合、Oracle Databaseでは、ソース・データベースのREDOデータのデータ・ディクショナリ情報を使用して、ダウンストリーム・データベースにLogMinerデータ・ディクショナリが作成されます。ソース・データベースでDBMS_CAPTURE_ADM.BUILDプロシージャが実行され、ソース・データベースのREDOログにソース・データ・ディクショナリ情報が抽出されます。次に、REDOデータがソース・データベースからダウンストリーム・データベースにコピーされます。同じソース・データベースに対する後続のダウンストリーム取得プロセスでは、この既存のLogMinerデータ・ディクショナリを使用するか、または新しいLogMinerデータ・ディクショナリを作成できます。また、リアルタイム・ダウンストリーム取得プロセスでは、1つのLogMinerデータ・ディクショナリを1つ以上のアーカイブ・ログ・ダウンストリーム取得プロセスと共有できます。

- 取得プロセスで、LogMinerを使用してソース・データベースのREDOデータの変更がスキャンされます。

- ルール・エンジンによって、1つ以上の取得プロセスのルール・セットのルールに基づいて、変更が評価されます。

- 取得プロセスで、ルール・セットのルールを満たす変更がローカルのANYDATAキューにエンキューされます。この変更は、取得プロセスによってLCRにフォーマットされます。

- 取得LCRが、1つ以上の他のデータベースと共有されている場合、1つ以上の伝播によって、それらのLCRがダウンストリーム・データベースから他のデータベースに伝播されます。

ダウンストリーム取得を構成すると、ソース・データベースで次のアクションが実行されます。

- ソース・データベースでDBMS_CAPTURE_ADM.BUILDプロシージャが実行され、データ・ディクショナリがREDOログに抽出されます。

- ソース・データベースでのサプリメンタル・ロギングによって、適用に必要となる可能性がある追加情報がREDOログに記録されます。

- ソース・データベースのデータベース・オブジェクトを環境内の他のデータベースでインスタンス化する必要がある場合は、オブジェクトをインスタンス化のために準備し、エクスポート・ユーティリティなどのメカニズムを使用してデータベース・オブジェクトのコピーを作成する必要があります。

また、ソース・データベースを実行しているコンピュータ・システムから、ダウンストリーム・データベースを実行しているコンピュータ・システムにREDOデータをコピーする必要があります。リアルタイム・ダウンストリーム取得構成では、REDO転送サービスがLGWRを使用して、REDOデータをダウンストリーム・データベースに送信します。通常、アーカイブ・ログ・ダウンストリーム取得構成では、REDO転送サービスがアーカイブREDOログ・ファイルをダウンストリーム・データベースにコピーします。

関連項目:
Oracle Streamsクライアントのルール・セット、およびメッセージがルール・セットを満たす仕組みの詳細は、第5章「Oracle Streamsでのルールの使用方法」を参照

ダウンストリーム取得のメリット

ダウンストリーム取得を使用するメリットは次のとおりです。

- 必要なほとんどの作業がダウンストリーム・データベースで実行されるため、ソース・データベースで、変更の取得に使用されるリソースが少なくなります。

- 複数のソース・データベースで行われた変更を取得する場合、複数のソース・データベースに対する複数のアーカイブ・ログ・ダウンストリーム取得プロセスを1つのダウンストリーム・データベースで実行することによって、取得プロセスを簡単に管理できます。つまり、1つのダウンストリーム・データベースが、複数のソースからの変更を取得するための中心の場所として機能します。このような構成では、アーカイブ・ログ・ダウンストリーム取得プロセスに加えて、1つのリアルタイム・ダウンストリーム取得プロセスもダウンストリーム・データベースで実行できます。

- REDOデータを1つ以上のダウンストリーム・データベースにコピーすることによって、データ損失に対する保護が強化されます。たとえば、状況によっては、ダウンストリーム・データベースのREDOログ・ファイルをソース・データベースのリカバリに使用できます。

- 1つ以上のダウンストリーム・データベースに、単一のソース・データベースから変更を取得する複数の取得プロセスを構成できるため、柔軟性およびスケーラビリティが向上します。

ダウンストリーム・データベースからソース・データベースへのオプションのデータベース・リンク

ダウンストリーム取得プロセスを作成または変更する場合は、オプションで、ダウンストリーム・データベースからソース・データベースへのデータベース・リンクが使用されるように指定できます。このデータベース・リンクには、ソース・データベースのグローバル名と同じ名前を付ける必要があります。このようなデータベース・リンクを使用すると、ダウンストリーム取得プロセスを簡単に作成および管理できます。ダウンストリーム取得プロセスでデータベース・リンクが使用されるように指定するには、ダウンストリーム取得プロセスでCREATE_CAPTUREまたはALTER_CAPTUREプロシージャを実行する際に、use_database_linkパラメータをTRUEに設定します。データベース・リンクの名前は、ソース・データベースのグローバル名と一致している必要があります。

ダウンストリーム取得プロセスでソース・データベースへのデータベース・リンクを使用すると、取得プロセスがソース・データベースに接続され、次の管理アクションが自動的に実行されます。

- 特定の状況では、ソース・データベースでDBMS_CAPTURE_ADM.BUILDプロシージャが実行され、取得プロセスの作成時にソース・データベースのデータ・ディクショナリがREDOログに抽出されます。

- ソース・データベース・オブジェクトがインスタンス化のために準備されます。

- 取得プロセスの作成時に先頭システム変更番号(SCN)を指定しなかった場合は、ダウンストリーム取得プロセスの先頭SCNが取得されます。取得プロセスを作成するには、先頭SCNが必要です。

ダウンストリーム取得プロセスでデータベース・リンクを使用していない場合は、これらのアクションを手動で実行する必要があります。

注意:
ダウンストリーム取得プロセスの作成時、CREATE_CAPTUREプロシージャのfirst_scnパラメータがNULLに設定されている場合は、use_database_linkパラメータをTRUEに設定する必要があります。TRUEに設定しないと、エラーが発生します。

関連項目:
ダウンストリーム取得プロセスでデータベース・リンクが使用されている場合、取得プロセスの作成時にDBMS_CAPTURE_ADM.BUILDプロシージャが自動的に実行されるタイミングの詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

ダウンストリーム取得の操作要件

ダウンストリーム取得を使用する場合の操作要件は次のとおりです。

- ソース・データベースでOracle Database 10g以上が実行されており、ダウンストリーム取得データベースで、ソース・データベースのリリース以上のOracle Databaseが実行されている必要があります。

- リアルタイム・ダウンストリーム取得を構成するには、ダウンストリーム・データベースでOracle Database 10gリリース2以上が実行されている必要があります。この場合、ソース・データベースでOracle Database 10gリリース1以上が実行されている必要があります。

- ソース・サイトおよびダウンストリーム取得サイトのオペレーティング・システムは同じである必要があります。ただし、オペレーティング・システムのリリースが同じである必要はありません。また、ダウンストリーム・サイトでは、ソース・サイトと異なるディレクトリ構造を使用できます。

- ソース・サイトおよびダウンストリーム取得サイトのハードウェア・アーキテクチャが同じである必要があります。たとえば、ダウンストリーム取得構成では、ソース・データベースが32ビットのSunシステム上に構成されている場合、ダウンストリーム・データベースが32ビットのSunシステム上に構成されている必要があります。CPUの数、メモリー・サイズ、記憶域構成などのその他のハードウェア要素は、ソース・サイトとダウンストリーム・サイトで同じである必要はありません。

取得プロセスに関連するSCN値

ここでは、取得プロセスで重要となるシステム変更番号(SCN)値を説明します。1つ以上の取得プロセスのシステム変更番号を表示するには、DBA_CAPTUREデータ・ディクショナリ・ビューを問い合せます。

- 取得済SCNおよび適用済SCN

- 先頭SCNおよび開始SCN

取得済SCNおよび適用済SCN

取得済SCNは、取得プロセスによってスキャンされたREDOログの最新の変更に対応するSCNです。取得プロセスの適用済SCNは、関連する適用プロセスにより最後にデキューされたメッセージのSCNです。このSCNより番号が小さいすべてのメッセージは、取得プロセスで取得された変更を適用するすべての適用プロセスによってデキューされています。取得プロセスの適用済SCNは、取得プロセスで取得された変更を適用する適用プロセスの最低水位標SCNと等価です。

先頭SCNおよび開始SCN

次の各項では、取得プロセスの先頭SCNおよび開始SCNについて説明します。

- 先頭SCN

- 開始SCN

- 開始SCNが先頭SCN以上である必要性

- インスタンス化の準備以前の時間への開始SCNの設定

先頭SCN

先頭SCNは、取得プロセスで変更を取得できる、REDOログ内の最小SCNです。取得プロセスの作成時に先頭SCNを指定する場合、データベースは、指定したSCN以上のREDOデータにアクセスできる必要があります。

DBMS_CAPTURE_ADM.BUILDプロシージャは、ソース・データベースのデータ・ディクショナリをREDOログに抽出します。取得プロセスを作成する際、REDOログのこのデータ・ディクショナリ・ビルドに対応する先頭SCNを指定できます。特に、作成中の取得プロセスの先頭SCNは、次の問合せで返される任意の値に設定できます。

COLUMN FIRST_CHANGE# HEADING 'First SCN' FORMAT 999999999
COLUMN NAME HEADING 'Log File Name' FORMAT A50

SELECT DISTINCT FIRST_CHANGE#, NAME FROM V$ARCHIVED_LOG
WHERE DICTIONARY_BEGIN = 'YES';

NAME列に対して返される値は、先頭SCNに相当するSCNが含まれるREDOログ・ファイルの名前です。このREDOログ・ファイルおよびすべての後続のREDOログ・ファイルは、取得プロセスで使用可能であることが必要です。この問合せでFIRST_CHANGE#に対して複数の異なる値が返される場合、DBMS_CAPTURE_ADM.BUILDプロシージャがソース・データベースに対して2回以上実行されています。この場合、作成する取得プロセスに最も適した先頭SCN値を選択します。

場合によっては、取得プロセスの作成時に、DBMS_CAPTURE_ADM.BUILDプロシージャが自動的に実行されます。このとき、取得プロセスの先頭SCNは、このデータ・ディクショナリ・ビルドに対応します。

開始SCN

開始SCNは、取得プロセスで変更の取得を開始するSCNです。取得プロセスの作成時に先頭SCNとは別に開始SCNを指定するか、または取得プロセスを変更して開始SCNを設定できます。取得プロセスの通常の操作については開始SCNを変更する必要はありません。一般的に、取得プロセスの開始SCNをリセットするのは、取得プロセスから変更を受け取る宛先データベースのいずれかでPoint-in-Timeリカバリを実行する必要がある場合です。このような場合は、取得プロセスを使用して、Point-in-Timeリカバリの後にソース・データベースで行われた変更を取得することができます。

注意:
開始SCNを設定する前に、既存の取得プロセスを停止する必要があります。

開始SCNが先頭SCN以上である必要性

取得プロセスの作成または変更時に開始SCNを指定する場合、指定する開始SCNは、取得プロセスの先頭SCN以上である必要があります。取得プロセスでは、REDOログ・レコードが開始SCNより小さいSCN値を含む場合でも、先頭SCNより大きいSCN値を含む(スキャン済でない)REDOログ・レコードが常にスキャンされます。そのため、先頭SCNより大きい開始SCNを指定すると、取得プロセスは、開始SCNより小さい番号のSCNが含まれるために変更を取得できないREDOログ・レコードをスキャンする場合があります。

開始SCNより前のREDOログ・レコードのスキャンには時間がかかる場合があるため、可能であれば回避する必要があります。そのため、取得プロセスの作成時には、先頭SCNと開始SCNの差をできるかぎり小さくして、取得プロセスの初期起動時間を最小限に抑えることをお薦めします。

注意:
取得プロセスを起動または再起動する際、開始SCN未満のFIRST_CHANGE#値が含まれるREDOログ・ファイルをスキャンすることが必要になる場合があります。取得プロセスがスキャンする前に必要なREDOログ・ファイルを削除すると、取得プロセスが強制終了されます。先頭SCN、開始SCNおよび必須チェックポイントSCNを判別するには、DBA_CAPTUREデータ・ディクショナリ・ビューを問い合せます。取得プロセスには、必須チェックポイントSCNが含まれるREDOログ・ファイルおよび後続のすべてのREDOログ・ファイルが必要です。

関連項目:

- 取得プロセスの先頭SCNおよび開始SCNの詳細は、「取得プロセスの作成」を参照

インスタンス化の準備以前の時間への開始SCNの設定

データベース・オブジェクトに対する変更を取得し、適用プロセスを使用してこれらの変更を適用する場合は、データベース・オブジェクトがインスタンス化のために準備された後に発生した変更のみを適用できます。このため、取得プロセスの開始SCNを、データベース・オブジェクトがインスタンス化のために準備された時間に対応するSCNより小さい番号に設定すると、準備SCN以前に取得されたこのデータベース・オブジェクトに対する変更は、適用プロセスでは適用できません。

この制限は、取得プロセスの作成時に問題となる場合があります。取得プロセスの作成時より前に、データベース・オブジェクトがインスタンス化のために準備されなかった場合、取得プロセスの作成時より前に行われたオブジェクトに対する変更は、適用プロセスでは適用できません。

新しい取得プロセスの作成前に、データベース・オブジェクトがインスタンス化のために準備されている場合があります。たとえば、1つ以上の既存の取得プロセスで取得されている変更を含むソース・データベースの取得プロセスを作成する場合、一部またはすべてのデータベース・オブジェクトが新しい取得プロセスの作成前にインスタンス化のために準備されていることがあります。新しい取得プロセスで、この新しい取得プロセスの作成時より前に特定のデータベースに対して行われた変更を取得した場合、適用プロセスでこれらの取得された変更を適用するには、次の条件を満たしている必要があります。

- 新しい取得プロセスの作成時より前に、データベース・オブジェクトがインスタンス化のために準備されている必要があります。

- 新しい取得プロセスの開始SCNが、データベース・オブジェクトがインスタンス化のために準備された時間より前の時間に対応している必要があります。

- 指定した開始SCNに対応する時間のREDOログが使用可能である必要があります。また、開始SCNより前に追加のREDOログが必要な場合もあります。

関連項目:

- データベース・オブジェクトをインスタンス化のために準備する方法の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- 「取得プロセスの作成」

Oracle Streamsの取得プロセスおよびRESTRICTED SESSION

システム起動時にSTARTUP RESTRICT文を発行して制限付きセッションを有効にすると、データベースの停止時に取得プロセスを実行していた場合でも、取得プロセスは起動されません。ALTER SYSTEM文を使用して制限付きセッションを無効にすると、データベースの停止時に実行されたいた各取得プロセスが起動されます。

SQL文ALTER SYSTEMのENABLE RESTRICTED SESSION句によって実行中のデータベースで制限付きセッションを有効にしても、実行中の取得プロセスには影響がありません。これらの取得プロセスは引き続き実行され、変更の取得が行われます。停止している取得プロセスを制限付きセッションで起動しても、この取得プロセスは、制限付きセッションを無効にするまで実際には起動されません。

取得プロセスのサブコンポーネント

取得プロセスはオプションのOracleバックグラウンド・プロセスであり、プロセス名はCPnn(nnは文字または数字)です。取得プロセスは、LogMinerのインフラストラクチャを使用してREDOログから変更を取得します。LogMinerは、Oracle Streamsによって自動的に構成されます。基礎となるLogMinerプロセス名はMSnn(nnは文字または数字)です。取得プロセスの作成、変更、起動、停止および削除を行うことができます。また、取得プロセスで取得される変更を制御する取得プロセスのルールを定義できます。

取得プロセスのサブコンポーネントは、次のとおりです。

- 1つのリーダー・サーバー。REDOログを読み取って複数の領域に分割します。

- 1つ以上のプリペアラ・サーバー。リーダー・サーバーによって定義された領域をパラレルでスキャンし、REDOログ内で検出された変更の事前フィルタ処理を実行します。事前フィルタ処理では、変更に関する部分的な情報(変更のスキーマ名やオブジェクト名など)が評価のためにルール・エンジンに送信され、評価の結果が受信されます。parallelism取得プロセス・パラメータを使用してプリペアラ・サーバーの数を制御できます。

- 1つのビルダー・サーバー。プリペアラ・サーバーからのREDOレコードをマージします。これらのREDOレコードには、部分評価の実行中にTRUEと評価されたものと、部分評価で結果が生成されていないものがあります。ビルダー・サーバーは、これらのREDOレコードのシステム変更番号(SCN)の順序を保持し、マージされたREDOログ・レコードを取得プロセスに渡します。

- 取得プロセス(CPnn)。マージされたREDOレコードをビルダー・サーバーから受信すると、各変更に対して次のアクションを実行します。

- 変更をLCR形式でフォーマットします

- プリペアラ・サーバーによって実行された部分評価で、LCRの変更に対する結果が生成されていない場合は、LCRを完全評価のためにルール・エンジンに送信します

- LCRの完全評価が実行された場合は、その結果を受信します

- LCRが取得プロセスのネガティブ・ルール・セットのルールを満たすか、ポジティブ・ルール・セットのルールを満たさない場合は、LCRを廃棄します。

- LCRが取得プロセスのポジティブ・ルール・セットのルールを満たす場合は、取得プロセスに関連付けられたキューにLCRをエンキューします。

各リーダー・サーバー、プリペアラ・サーバーおよびビルダー・サーバーはプロセスです。

関連項目:

- 「取得プロセス・ルールの評価」

- 「取得プロセス・パラメータ」

取得ユーザー

変更は、取得プロセスの取得ユーザーのセキュリティ・ドメインで取得されます。取得ユーザーは、取得プロセスのルール・セットを満たすすべての変更を取得します。また、取得ユーザーは、これらのルール・セット内のルールで指定されたカスタム・ルールベースの変換をすべて実行します。取得ユーザーは、アクションの実行に必要な権限(取得プロセスで使用されるルール・セットのEXECUTE権限、ポジティブ・ルール・セットのルールに指定されたすべてのカスタム・ルールベースの変換ファンクションのEXECUTE権限、取得プロセス・キューへのメッセージのエンキュー権限など)を持っている必要があります。1つの取得プロセスは1ユーザーにしか関連付けできませんが、1ユーザーは複数の取得プロセスに関連付けることができます。

関連項目:

- 必要な権限の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

取得プロセスの状態

取得プロセスの状態は、取得プロセスが現在行っている処理を示します。取得プロセスの状態は、V$STREAMS_CAPTURE動的パフォーマンス・ビューのSTATE列を問い合せることによって表示できます。取得プロセスの状態は次のいずれかになります。

- INITIALIZING: 起動中。

- WAITING FOR DICTIONARY REDO: 先頭SCNに関連するディクショナリ・ビルドを含むREDOログ・ファイルが取得プロセス・セッションに追加されるまで待機しています。このディクショナリ・ビルドを含むすべてのログ・ファイルが追加されるまで、取得プロセスはREDOログ・ファイルのスキャンを開始できません。

- DICTIONARY INITIALIZATION: ディクショナリ・ビルドを処理しています。

- MINING (PROCESSED SCN = scn_value): SCN(scn_value)でデータ・ディクショナリ・ビルドをマイニングしています。

- LOADING (step X of Y): ディクショナリ・ビルドの情報を処理中で、現在、Y個の手順を含むプロセスの手順Xです。XおよびYは数値です。

- CAPTURING CHANGES: 取得プロセスのルール・セットを満たす変更についてREDOログをスキャンしています。

- WAITING FOR REDO: 新しいREDOログ・ファイルが取得プロセス・セッションに追加されるまで待機しています。取得プロセスは、セッションに追加されたすべてのREDOログ・ファイルの処理を終了しました。ソース・データベースにアクティビティが存在しない場合に、この状態が発生する可能性があります。ダウンストリーム取得プロセスでは、セッションに新しいログ・ファイルが追加されるのを取得プロセスが待機しているときに、この状態が発生する可能性があります。

- EVALUATING RULE: 取得プロセスのルール・セットに対して変更を評価しています。

- CREATING LCR: 変更を論理変更レコード(LCR)形式に変換しています。

- ENQUEUING MESSAGE: 取得プロセスのルール・セットを満たすLCRを取得プロセス・キューにエンキューしています。

- PAUSED FOR FLOW CONTROL: メモリー不足、または伝播および適用プロセスでのメッセージのコンシューム速度が取得プロセスでのメッセージの作成速度より遅いことが原因で、LCRをエンキューできません。この状態は、伝播または適用が遅延した場合あるいは処理が行われない場合に、取得LCRのオーバーフローを減らすために、フロー制御が行われていることを示します。

- WAITING FOR A SUBSCRIBER TO BE ADDED: 取得プロセスのキューのサブスクライバが追加されるのを待機中。サブスクライバは、伝播プロセスまたは適用プロセスのいずれかです。

- WAITING FOR THE BUFFERED QUEUE TO SHRINK: バッファ・キュー小さくなるのを待機中。バッファ・キューは、メモリー制限や管理者の操作によってサイズが減らされることがあります。

- WAITING FOR n SUBSCRIBER(S) INITIALIZING: 起動するために取得プロセスからLCRを受け取る適用プロセスを待機中。nは適用プロセスの数です。

- WAITING FOR TRANSACTION: LogMinerでより多くのトランザクションが提供されるのを待機中。

- WAITING FOR INACTIVE DEQUEUERS: 取得プロセスのキュー・サブスクライバが開始するのを待機中。キューに対してアクティブなサブスクライバが存在しない場合は、取得プロセスはLCRのエンキューを停止します。

- SUSPENDED FOR AUTO SPLIT/MERGE: マージ操作が完了するのを待機中。

- SHUTTING DOWN: 停止しています。

- ABORTING: 中断しています。

関連項目:

- 取得プロセスの状態を表示する問合せの詳細は、「各取得プロセスに関する変更取得情報の表示」を参照

- 分割とマージの詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

取得プロセス・パラメータ

作成後の取得プロセスは、最初に起動する前に環境に合わせて取得プロセス・パラメータを設定できるように無効になっています。取得プロセス・パラメータによって、取得プロセスの動作が制御されます。たとえば、parallelism取得プロセス・パラメータによって、取得プロセスで使用されるプリペアラ・サーバーの数が制御され、time_limit取得プロセス・パラメータによって、適用プロセスが自動的に停止されるまでの実行時間が指定されます。DBMS_CAPTURE_ADM.SET_PARAMETERプロシージャを使用して取得プロセス・パラメータを設定します。

関連項目:

- 「取得プロセス・パラメータの設定」

- プリペアラ・サーバーの詳細は、「取得プロセスのサブコンポーネント」を参照

- すべての取得プロセス・パラメータの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

データベースの再起動時における取得プロセスの永続的状態

取得プロセスを実行しているデータベースが停止され、再起動されても、取得プロセスは永続的状態を保ちます。たとえば、データベースの停止時に取得プロセスを有効にすると、その取得プロセスはデータベースの再起動時に自動的に開始されます。同様に、データベースの停止時に取得プロセスを無効にするか、または強制終了させると、その取得プロセスはデータベースが再起動されても開始されず、無効または強制終了の状態のままとなります。

同期取得による暗黙的取得

この項では、同期取得に関連する概念について説明します。

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

- 同期取得の概要

- 同期取得およびキュー

- 同期取得のルール

- 同期取得によって取得されるデータ型

- 同期取得によって取得されるDML変更のタイプ

- 同期取得の取得ユーザー

- 単一データベースでの複数の同期取得

関連項目:

- 同期取得の構成の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- 「同期取得の管理」

- 「同期取得の監視」

- 同期取得を使用するレプリケーション環境の構成例については、Oracle Database 2日でデータ・レプリケーションおよび統合ガイドを参照

同期取得の概要

同期取得は、表へのデータ操作言語(DML)の変更を取得する、オプションのOracle Streamsクライアントです。同期取得は、内部メカニズムを使用して指定の表へのDML変更を取得します。同期取得は表への変更を取得するように構成されますが、そのような表を含むデータベースがソース・データベースと呼ばれます。

表へのDML変更が行われると、表の1つ以上の行が変更されます。同期取得は、各行の変更を取得し、行論理変更レコード(行LCR)と呼ばれる特殊なメッセージ・フォーマットに変換します。行LCRを取得した後、同期取得は行LCRを含むメッセージをキューにエンキューします。同期取得によって作成される行LCRには、変更によって変更されていない行であっても、常に行のすべての列の値が含まれます。

図2-4に、LCRを取得する同期取得を示します。

図2-4 同期取得

注意:
同じ表に対して行われた変更が同期取得と取得プロセスによって取得されないようにする必要があります。

関連項目:

- 「コミット時間キュー」

- 「同期取得の管理」

同期取得およびキュー

同期取得は、常に、単一のANYDATAキューに関連付けられており、このキューにのみメッセージをエンキューします。同期取得で使用されるキューは、コミット時間キューである必要があります。コミット時間キューによって、メッセージがトランザクションにグループ化され、トランザクション・グループがコミット・システム変更番号(CSCN)順に配置されます。同期取得では、常に、行LCRを永続キューにエンキューします。永続キューは、メモリーではなくハード・ディスクのキュー表にのみメッセージを格納するキューの一部分です。複数のキューを作成し、各キューに異なる同期取得を関連付けることができます。

同期取得ではコミット時間キューにメッセージをエンキューする必要がありますが、同期取得で取得されたメッセージは、コミット時間キュー以外のキューに伝播することができます。したがって、同期取得で取得されたメッセージを格納する中間キューがコミット時間キューである必要はありません。また、同期取得で取得されたメッセージを適用する適用プロセスでは、コミット時間キュー以外のキューを使用できます。

注意:

- 同期取得を関連付けることができるのはANYDATAキューのみです。型付きキューに関連付けることはできません。

- 取得プロセスで使用されるメッセージが同期取得によってエンキューされないようにする必要があります。

同期取得のルール

同期取得は、定義したルールに基づいて、変更を取得または廃棄します。各ルールによって、TRUEと評価されるデータベース・オブジェクトおよび変更のタイプを指定します。これらのルールは、ポジティブ・ルール・セットに含めることができます。変更がルールによってTRUEと評価され、そのルールがポジティブ・ルール・セットに含まれている場合、同期取得はこの変更を取得します。同期取得では、ネガティブ・ルール・セットは使用されません。

同期取得ルールは、表レベルで指定できます。表ルールには、特定の表に対するDML変更による行変更を取得または廃棄します。サブセット・ルールは、特定の表に対する行変更のサブセットを含む表ルールです。同期取得では、スキーマまたはグローバル・ルールは使用されません。

すべての同期取得ルールは、DBMS_STREAMS_ADMパッケージの次のいずれかのプロシージャを使用して作成する必要があります。

- ADD_TABLE_RULES

- ADD_SUBSET_RULES

同期取得では、次のタイプのルールに基づいた変更は取得されません。

- DBMS_STREAMS_ADMパッケージのADD_TABLE_RULESまたはADD_SUBSET_RULESプロシージャ以外のプロシージャによって同期取得ルール・セットに追加されたルール

- DBMS_RULE_ADMパッケージによって作成されたルール

これらのタイプのルールが同期取得ルール・セットに存在する場合、これらのルールは無視されます。

同期取得では、DBMS_RULE_ADMパッケージのCREATE_RULE_SETプロシージャによって作成されたルール・セットを使用できますが、ADD_TABLE_RULESまたはADD_SUBSET_RULESプロシージャを使用してルール・セットにルールを追加する必要があります。

ADD_TABLE_RULESまたはADD_SUBSET_RULESプロシージャの実行時に、指定した同期取得が存在しない場合は、このプロシージャによって自動的に同期取得が作成されます。また、DBMS_CAPTURE_ADMパッケージのCREATE_SYNC_CAPTUREプロシージャを使用して、同期取得を作成することもできます。

注意:

- 同期取得は、特定のタイプの変更および表の列の特定のデータ型に対する変更を取得しません。また、SYS、SYSTEMまたはCTXSYSスキーマ内での変更は取得しません。

- ルールが同期取得のルール・セットに含まれている場合、ルールの条件:dml.get_object_nameおよび:dml.get_object_ownerは変更しないでください。これらの条件を変更すると、同期取得でデータベース・オブジェクトの変更が取得されなくなる場合があります。同期取得のルールに含まれる他の条件は変更できます。

関連項目:

- 第11章「ルールの高度な概念」

- 第5章「Oracle Streamsでのルールの使用方法」

- 同期取得の構成の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

同期取得によって取得されるデータ型

表に対するDML変更による行の変更を取得するとき、同期取得は、次のデータ型の列に対して行われる変更を取得できます。

- VARCHAR2

- NVARCHAR2

- NUMBER

- FLOAT

- DATE

- BINARY_FLOAT

- BINARY_DOUBLE

- TIMESTAMP

- TIMESTAMP WITH TIME ZONE

- TIMESTAMP WITH LOCAL TIME ZONE

- INTERVAL YEAR TO MONTH

- INTERVAL DAY TO SECOND

- RAW

- CHAR

- NCHAR

- UROWID

関連項目:

- 「同期取得ではサポートされていないデータ型」

- 取得プロセスによって適用できるデータ型の詳細は、「適用されるデータ型」を参照

- データ型の詳細は、『Oracle Database SQL言語リファレンス』を参照

同期取得によって取得されるDML変更のタイプ

特定の表に対して行われたDML変更を取得するように指定した場合、同期取得では、これらの表に対して行われた次のタイプのDML変更が取得されます。

- INSERT

- UPDATE

- DELETE

- MERGE

同期取得では、MERGEの変更がそれぞれINSERTまたはUPDATEの変更に変換されます。MERGEは、行LCRでは無効なコマンド・タイプです。

関連項目:

- 「同期取得ではサポートされていない変更」

- 適用プロセスで適用可能な変更のタイプの詳細は、第4章「Oracle Streams情報コンシューム」を参照

同期取得の取得ユーザー

変更は、同期取得の取得ユーザーのセキュリティ・ドメインで取得されます。取得ユーザーは、同期取得のルール・セットを満たすすべての変更を取得します。また、取得ユーザーは、これらのルール・セット内のルールで指定されたカスタム・ルールベースの変換をすべて実行します。取得ユーザーは、アクションの実行に必要な権限(同期取得で使用されるルール・セットのEXECUTE権限、ルール・セットのルールに指定されたすべてのカスタム・ルールベースの変換ファンクションのEXECUTE権限、同期取得キューへのメッセージのエンキュー権限など)を持っている必要があります。1つの同期取得に関連付けることができるのは1ユーザーのみですが、1ユーザーには複数の同期取得を関連付けることができます。

関連項目:
必要な権限の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

単一データベースでの複数の同期取得

同期取得、伝播または適用プロセスで使用されるANYDATAキューには、特定のソース・データベースの最大1つの同期取得からのメッセージを格納することをお薦めします。したがって、特定のソース・データベースで行われた変更を取得する各同期取得で個別のキューを使用し、各キューに独自のキュー表が存在することを確認します。また、同じソース・データベースの2つ以上の同期取得からのメッセージが同じ宛先キューに伝播されないようにする必要があります。

アプリケーションによる明示的取得

アプリケーションによるメッセージの手動エンキューは明示的取得と呼ばれます。エンキューの後、Oracle Streamsの伝播によって、これらのメッセージを同じデータベース内または他のデータベースに伝播できます。また、アプリケーション、適用プロセスおよびメッセージ・クライアントによってこれらのメッセージをコンシュームすることもできます。メッセージをエンキューするには、DBMS_STREAMS_MESSAGINGパッケージまたはDBMS_AQADMパッケージを使用します。

次の各項では、メッセージのエンキューの概念について説明します。

- 明示的にエンキューできるメッセージのタイプ

- エンキュー機能

関連項目:

- メッセージングに関する基本情報は、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照

- メッセージのエンキューに関する主なドキュメントは、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドを参照してください。

明示的にエンキューできるメッセージのタイプ

Oracle Streams環境では、アプリケーションによって、様々なタイプのメッセージを様々な目的のために作成してエンキューできます。これらのメッセージは、ユーザー・メッセージと呼ばれるユーザー定義型のメッセージ、またはLCRです。

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

- ユーザー・メッセージ

- 論理変更レコード(LCR)とメッセージ

ユーザー・メッセージ

アプリケーションは、ユーザー定義型のメッセージを作成して、エンキューすることができます。エンキューできるキューは、メッセージと同じタイプのキューまたはANYDATAキューです。通常、このようなユーザー・メッセージはアプリケーションまたは適用プロセスによってコンシュームされます。

バッファ・キューにエンキューされるユーザー・メッセージはバッファ・ユーザー・メッセージと呼ばれます。バッファ・ユーザー・メッセージはアプリケーションでのみデキューできます。アプリケーションではデキュー後にメッセージを処理します。

永続キューにエンキューされるユーザー・メッセージは永続ユーザー・メッセージと呼ばれます。永続ユーザー・メッセージは次の方法でデキューできます。

- メッセージ・クライアント: メッセージ・クライアントは、メッセージの処理のためにメッセージ・クライアントを起動したアプリケーションにメッセージを渡します。

- アプリケーション: アプリケーションはメッセージをデキューした後で処理します。

- 適用プロセス: 適用プロセスは、処理のためにメッセージ・ハンドラにメッセージを渡します。適用プロセスがメッセージをデキューするためには、キューがANYDATAキューであることが必要です。

論理変更レコード(LCR)とメッセージ

アプリケーションはLCRを作成して、ANYDATAキューにエンキューすることができます。行LCRはDML変更の結果を記述し、DDL LCRはDDL変更について記述します。通常、LCRは適用プロセスによってコンシュームされますが、メッセージ・クライアントやアプリケーションによってコンシュームされることもあります。異機種レプリケーション環境では、LCRの明示的エンキューを使用して、データベースの変更をOracle以外のデータベースからOracle Databaseにレプリケートすることができます。

バッファ・キューに明示的にエンキューされるLCRはバッファLCRと呼ばれます。バッファLCRはアプリケーションでのみデキューできます。アプリケーションではデキュー後にバッファLCRを処理します。

永続キューに明示的にエンキューされるLCRは永続LCRと呼ばれます。永続LCRは次の方法でデキューできます。

- メッセージ・クライアント: メッセージ・クライアントは、メッセージの処理のためにメッセージ・クライアントを起動したアプリケーションにメッセージを渡します。

- アプリケーション: アプリケーションはメッセージをデキューした後で処理します。

- 適用プロセス: 適用プロセスは、LCRを直接適用するか、処理のために適用ハンドラに渡すことができます。

関連項目:

- 「論理変更レコード(LCR)」

エンキュー機能

Oracle Streamsアドバンスト・キューイングでは次のエンキュー機能が使用できます。

- バッファ・キューまたは永続キューへのエンキュー

- エンキュー時間またはコミット時間に基づくメッセージの順序付け

- メッセージの配列エンキュー

- 相関識別子

- メッセージのグループ分け

- 送信者の識別

- 時間指定とスケジュール設定

関連項目:

- これらの機能およびOracle Streamsアドバンスト・キューイングで利用できるその他の機能の詳細は、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドを参照してください。

- メッセージングに関する基本情報は、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照

3 Oracle Streamsのステージングと伝播

次の各項では、キューでのメッセージのステージングやキュー間でのメッセージの伝播の概要について説明します。

- メッセージのステージングと伝播の概要

- キュー

- キュー間でのメッセージの伝播

関連項目:

- 第16章「ステージングと伝播の管理」

- 「キューおよびメッセージの監視」

- 「Oracle Streamsの伝播および伝播ジョブの監視」

- 第32章「伝播のトラブルシューティング」

メッセージのステージングと伝播の概要

Oracle Streamsでは、キューを使用してメッセージをステージングします。ステージングされたメッセージは、コンシュームまたは伝播(あるいはその両方)の対象になります。ステージングされたメッセージは、適用プロセス、メッセージ・クライアントまたはユーザー・アプリケーションでコンシュームできます。実行中の適用プロセスはメッセージを暗黙的にデキューしますが、メッセージ・クライアントとユーザー・アプリケーションはメッセージを明示的にデキューします。Oracle Streamsの伝播で他の1つ以上のキューへのメッセージの伝播(送信)を構成している場合、またはキューでメッセージの保存が指定されている場合は、メッセージがコンシュームされた後でも、キューに残ることができます。メッセージの保存は、同期取得で取得されたメッセージまたは明示的にエンキューされたメッセージに適用されます。取得プロセスで取得されたメッセージには適用されません。

関連項目:

- 第16章「ステージングと伝播の管理」

- 「キューおよびメッセージの監視」

- 「Oracle Streamsの伝播および伝播ジョブの監視」

- 第32章「伝播のトラブルシューティング」

- 『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイド』

キュー

キューは、メッセージ・システムがメッセージを格納するために使用する抽象的な記憶域単位です。この項の内容は次のとおりです。

- ANYDATAキューおよび型付きキュー

- 永続キューとバッファ・キュー

関連項目:

- キューの管理

- 「キューの制限事項」

- 第8章「キューの高度な概念」

ANYDATAキューおよび型付きキュー

ANYDATAタイプのキューは、ほとんどのタイプのメッセージをステージングでき、ANYDATAキューと呼ばれます。型付きキューは特定のタイプのメッセージをステージングできます。Oracle Streamsクライアントは常にANYDATAキューを使用します。

Oracle Streamsレプリケーション環境では、論理変更レコード(LCR)をANYDATAキューにステージングする必要があります。Oracle Streamsメッセージ環境では、ANYDATAキューと型付きキューの両方がメッセージをステージングできます。パブリッシュ・アプリケーションはメッセージを1つのキューにエンキューでき、サブクライブ・アプリケーションがそれらのメッセージをデキューできます。

LCRとユーザー・メッセージという2種類のメッセージをANYDATAオブジェクトにカプセル化してANYDATAキューにステージングできます。LCRは、データベース・オブジェクトに対する変更に関する情報を格納するオブジェクトです。ユーザー・メッセージは、ユーザーまたはアプリケーションによって作成された、ユーザー定義型のメッセージです。どちらのタイプのメッセージも、単一データベース内またはデータベース間で情報を共有するために使用できます。

ANYDATAキューは、ペイロードのタイプがANYDATAのユーザー・メッセージをステージングできます。ANYDATAペイロードは、様々なデータ型のペイロードのラッパーとして使用できます。

メッセージのペイロードにANYDATAラッパーを使用すると、パブリッシュ・アプリケーションが様々なタイプのメッセージを1つのキューにエンキューでき、サブスクライブ・アプリケーションが、メッセージ・クライアントまたはアプリケーションを使用して明示的に、あるいは適用プロセスを使用して暗黙的に、それらのメッセージをデキューできます。サブスクライブ・アプリケーションがリモートの場合、メッセージをリモート・サイトに伝播することができ、サブスクライブ・アプリケーションがリモート・データベースのローカル・キューからメッセージをデキューできます。または、リモート・サブスクライブ・アプリケーションが、様々な標準プロトコル(PL/SQLやOCIなど)を使用してソース・キューからメッセージを直接デキューすることもできます。

ほぼすべての型のペイロードをANYDATAペイロードでラップできます。このためには、ANYDATAタイプのConvertdata_type静的関数を使用します。data_typeはラップするオブジェクトの型です。このような関数は入力としてオブジェクトを取り、ANYDATAオブジェクトを返します。

Oracle StreamsにはOracle Streamsアドバンスト・キューイング(AQ)の機能が含まれ、マルチ・コンシューマ・キュー、パブリッシュおよびサブスクライブ、コンテンツベースのルーティング、インターネット伝播、変換、他のメッセージ・サブシステムへのゲートウェイなど、メッセージ・キューイング・システムの標準機能がすべてサポートされます。

関連項目:

- Oracle Database 2日でデータ・レプリケーションおよび統合ガイド

- 「キューの制限事項」

- ANYDATAラッパーでのペイロードのラップ、ANYDATAキューへのメッセージのエンキューおよびデキューのためのプログラム的な環境、伝播およびユーザー定義型など、ANYDATAキューの関連情報については、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドを参照

- ANYDATAタイプの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

永続キューとバッファ・キュー

Oracle Streamsでは、次のメッセージ・モードがサポートされています。

- 永続メッセージ機能: メッセージは、ディスク上のキュー表と呼ばれるデータベース表に常に格納されます。この記憶域のタイプは、永続キュー記憶域と呼ばれることがあります。

- バッファ・メッセージ機能: メッセージは、メモリーに格納されますが、一定の条件でキュー表にあふれることがあります。この記憶域のタイプは、バッファ・キュー記憶域と呼ばれることがあります。このメモリーには、取得プロセスで取得されたメッセージまたはアプリケーションでエンキューされたメッセージを含むキューに関連付けられているOracle Streamsプール・メモリーが含まれます。

バッファ・キューを使用すると、Oracleでは、メッセージを常にキュー表に格納するのではなく、システム・グローバル領域(SGA)に格納することによって、メッセージを最適化できます。バッファ・メッセージ機能は、より高いパフォーマンスを提供しますが、メッセージ保持などの一部のメッセージ機能をサポートしません。メッセージ保持では、デキュー後にメッセージがキュー表に保持される時間を指定できます。

Oracle Streamsプールのサイズが自動的に管理されない場合は、データベースの各バッファ・キューに対してOracle Streamsプールのサイズを10MBずつ増やす必要があります。バッファ・キューによってパフォーマンスは改善されますが、バッファ・キューを含むインスタンスが正常または異常な状態で停止すると、バッファ・キューの一部の情報が失われることがあります。このような場合に、インスタンス上でデータベース全体のリカバリが実行されるとOracle Streamsは自動的にリカバリします。

バッファ・キューのメッセージがメモリーからオーバーフローしてキュー表に格納されるのは、メッセージがバッファ・キューにステージングされてから一定期間デキューされない場合か、すべてのメッセージを保持する十分な領域がメモリーにない場合です。メモリーからオーバーフローしたメッセージは、適切なAQ$_queue_table_name_p表に格納されます。queue_table_nameはキューのキュー表の名前です。また、オーバーフローした各メッセージについては、メッセージの処理に使用できる伝播や適用プロセスに関する情報がAQ$_queue_table_name_d表に格納されます。

取得プロセスで取得されたLCRは常にバッファ・キューに格納されますが、同期取得で取得されたLCRは常に永続キューに格納されます。バッファ・キューには、他のタイプのメッセージが格納されることがあります。アプリケーションがメッセージをエンキューすると、エンキュー操作によって、エンキューされたメッセージがバッファ・キューと永続キューのいずれに格納されるかが指定されます。DBMS_AQ.ENQUEUEプロシージャのenqueue_optionsパラメータのdelivery_mode属性によって、メッセージがバッファ・キューと永続キューのどちらに格納されるかが決まります。具体的には、delivery_mode属性がデフォルトのPERSISTENTの場合、メッセージは永続キューにエンキューされます。この属性をBUFFEREDに設定すると、メッセージはバッファ・キューにエンキューされます。トランザクションがエラー・キューに移動される場合、そのトランザクションのすべてのメッセージはバッファ・キューではなく常にキュー表に格納されます。

注意:
バッファ・メッセージと永続メッセージを同一のキューに格納できます。1つのキューにバッファ部と永続部があると考えることをお薦めします。ここでは、各部分をバッファ・キューおよび永続キューと呼びます。ANYDATAキューおよび型付きキューは、バッファ・キューと永続キューの両方を含むことができます。

関連項目:

- Oracle Streamsプールの詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- バッファ・メッセージ機能の概念および使用の詳細は、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドを参照してください。

キューおよびOracle Streamsクライアント

Oracle Streamsクライアントでは、常にANYDATAキューを使用します。次の項では、Oracle Streamsクライアントとキューの対話方法を説明します。

- キューと取得プロセス

- キューと同期取得

- キューと伝播

- キューと適用プロセス

- キューとメッセージ・クライアント

関連項目:

- 「永続キューおよびバッファ・キュー」

- バッファ・メッセージ機能の概念および使用の詳細は、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドを参照してください。

キューと取得プロセス

取得プロセスがLCRをエンキューできるのは、バッファ・キューにのみです。取得プロセスによってバッファ・キューにエンキューされたLCRは、適用プロセスによってのみデキューできます。取得LCRはアプリケーションまたはユーザーによってデキューできません。

キューと同期取得

同期取得がLCRをエンキューできるのは永続キューにのみできます。同期取得によって取得されたLCRは、適用プロセス、メッセージ・クライアント、アプリケーションおよびユーザーによってデキューできます。

キューと伝播

伝播では、ルール・セットを満たすソース・キューのすべてのメッセージを伝播します。これらのメッセージは、バッファ・キューまたは永続キューに格納できます。伝播では、伝播で使用されるルール・セットを満たす場合、どちらのタイプのメッセージでも伝播できます。

キューと適用プロセス

1つの適用プロセスは、バッファ・キューまたは永続キューのいずれかからメッセージをデキューできますが、両方からデキューすることはできません。適用プロセスでは、バッファ・キューの取得LCRをデキューおよび処理できます。取得LCRをデキューするには、適用プロセスの構成でapply_capturedパラメータをTRUEに設定する必要があります。適用プロセスではバッファLCRまたはバッファ・ユーザー・メッセージをデキューできません。永続LCRまたは永続ユーザー・メッセージをデキューするには、適用プロセスの構成でapply_capturedパラメータをFALSEに設定する必要があります。

キューとメッセージ・クライアント

メッセージ・クライアントでは、永続キューからのみメッセージをデキューできます。また、DBMS_STREAMS_MESSAGINGパッケージを使用してバッファ・キューにメッセージをエンキューしたり、バッファ・キューからメッセージをデキューすることはできません。

注意:
DBMS_AQおよびDBMS_AQADMパッケージは、バッファ・メッセージをサポートします。

関連項目:
DBMS_AQおよびDBMS_AQADM パッケージの使用方法の詳細は、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドを参照

キュー間でのメッセージの伝播

Oracle Streamsを使用すると、2つのキュー間でメッセージ伝播するように構成できます。これらのキューは、同じデータベースに存在することも異なるデータベースに存在することもできます。Oracle StreamsではOracle Schedulerジョブを使用してメッセージが伝播されます。

伝播は、常にソース・キューと宛先キューの間で行われます。伝播は常に2つのキュー間で行われますが、1つのキューが多数の伝播にかかわることができます。つまり、1つのソース・キューがメッセージを複数の宛先キューに伝播でき、1つの宛先キューが複数のソース・キューからメッセージを受信できます。また、1つのキューが、ある伝播の宛先キューと他の伝播のソース・キューを兼ねることができます。ただし、特定のソース・キューと特定の宛先キューの間で許可される伝播は1つのみです。

図3-1に、ソース・キューから宛先キューへの伝播を示します。

図3-1 ソース・キューから宛先キューへの伝播

伝播の作成、変更および削除を行うことができます。また、伝播するメッセージを制御する伝播ルールを定義できます。ソース・キューを所有するユーザーが、メッセージを伝播するユーザーです。このユーザーは、メッセージの伝播に必要な権限を持っている必要があります。これには、次の権限が含まれます。

- 伝播で使用されるルール・セットのEXECUTE権限

- ルール・セットで使用されるすべてのカスタム・ルールベースの変換ファンクションのEXECUTE権限

- 宛先キューのエンキュー権限(宛先キューが同じデータベースにある場合)

伝播によってメッセージがリモート・データベース内の宛先キューに伝播される場合、ソース・キューの所有者は、伝播で使用されるデータベース・リンクを使用できる必要があり、リモート・データベースでデータベース・リンクの接続先となるユーザーは、宛先キューに対するエンキュー権限を持っている必要があります。

伝播では、ソース・キューのすべてのメッセージを宛先キューに伝播することも、メッセージのサブセットのみを伝播することもできます。一度の伝播で、キューのバッファ・キュー部分および永続キュー部分の両方のメッセージを伝播できます。また、一度の伝播でLCRとユーザー・メッセージを伝播することもできます。ルールを使用して、ソース・キューから宛先キューに伝播するメッセージおよび破棄するメッセージを制御できます。

Oracle Streams環境の設定方法によっては、変更が発生元のサイトに送り返される場合があります。変更が無限ループで循環しないように環境を構成していることを確認してください。Oracle Streamsタグを使用すると、このような変更の循環ループを回避できます。

次の各項では、伝播についてさらに詳しく説明します。

- 伝播ルール

- キュー・ツー・キュー伝播

- 保証付きのメッセージ配信

- 有向ネットワーク

関連項目:

- 「Oracle Streamsの伝播および伝播ジョブの管理」

- 第9章「伝播の高度な概念」

- Oracle Streams AQの伝播インフラストラクチャの詳細は、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドを参照

- Oracle Streamsタグの詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

伝播ルール

伝播は、ユーザーが定義するルールに基づいてメッセージを伝播または廃棄します。LCRの場合は、各ルールでTRUEと評価するデータベース・オブジェクトと変更の種類を指定します。ユーザー・メッセージの場合は、特定のタイプのメッセージに対する伝播の動作を制御するルールを作成できます。これらのルールは、伝播で使用されるポジティブ・ルール・セットまたはネガティブ・ルール・セットに指定します。

ルールがメッセージをTRUEと評価し、そのルールが伝播のポジティブ・ルール・セットに含まれる場合、伝播はその変更を伝播します。ルールがメッセージをTRUEと評価し、そのルールが伝播のネガティブ・ルール・セットに含まれる場合、伝播はその変更を廃棄します。伝播にポジティブ・ルール・セットとネガティブ・ルール・セットの両方がある場合、ネガティブ・ルール・セットが常に最初に評価されます。

LCRの伝播ルールは次のレベルで指定できます。

- 表ルールは、特定の表に対するDML変更による行変更またはDDL変更を伝播または廃棄します。サブセット・ルールは、特定の表に対する行変更のサブセットを含む表ルールです。

- スキーマ・ルールは、特定のスキーマのデータベース・オブジェクトに対するDML変更による行変更またはDDL変更を伝播または廃棄します。

- グローバル・ルールは、ソース・キュー内のDML変更によるすべての行変更またはすべてのDDL変更を伝播または廃棄します。

条件を指定するキュー・サブスクライバによって、システムでルールが生成されます。キューのすべてのサブスクライバ用のルール・セットが組み合されて、サブスクリプションをより効率的にする1つのシステム生成ルール・セットとなります。

関連項目:

- 第11章「ルールの高度な概念」

- 第5章「Oracle Streamsでのルールの使用方法」

- 第18章「ルールの管理」

キュー・ツー・キュー伝播

伝播は、キュー・ツー・キューまたはキュー・ツー・データベース・リンク(キュー・ツーdblink)が可能です。キュー・ツー・キュー伝播は、独自の排他的な伝播ジョブを使用してメッセージをソース・キューから宛先キューに伝播します。各伝播ジョブには独自の伝播スケジュールがあるため、各キュー・ツー・キュー伝播は個別に管理することができます。複数のキュー・ツー・キュー伝播が同じデータベース・リンクを使用する場合でも、各伝播の無効化、有効化および伝播スケジュールの設定を個別に行うことができます。伝播ジョブについては次に詳しく説明します。

1つのデータベース・リンクは、複数のキュー・ツー・キュー伝播で使用できます。このデータベース・リンクを作成するときのサービス名には、宛先キューを含むデータベースのグローバル名を指定する必要があります。

反対に、キュー・ツーdblink伝播は、同じソース・キューの同じデータベース・リンクを使用するキュー・ツーdblink伝播と伝播ジョブを共有します。このため、これらの伝播は同じ伝播スケジュールを共有し、伝播スケジュールを変更すると、データベース・リンクを使用するソース・キューのすべてのキュー・ツーdblink伝播に影響します。

関連項目:

- 「キューとOracle Real Application Clusters」

- 「伝播ジョブ」

- 第16章「ステージングと伝播の管理」

保証付きのメッセージ配信

取得LCRが宛先キューに正常に伝播されるのは、次の両方のアクションが完了した時点です。

- メッセージが、宛先キューに関連付けられた関連するすべての適用プロセスによって処理される場合。

- メッセージがソース・キューからその関連宛先キューすべてに正常に伝播される場合。

他のタイプのメッセージが宛先キューに正常に伝播されるのは、宛先キューへのエンキューがコミットされた時点です。他のタイプのメッセージには、バッファLCR、バッファ・ユーザー・メッセージ、永続LCRおよびバッファ・ユーザー・メッセージがあります。

2つのキュー間でメッセージが正常に伝播されると、宛先キューはそのことを確認します。ソース・キューが複数の宛先キューにメッセージを伝播するように構成されている場合は、各宛先キューがソース・キューにメッセージ伝播の確認を送信し終わるまで、メッセージはソース・キューに残ります。各宛先キューがメッセージの正常な伝播を確認し、ソース・キュー・データベース内のすべてのローカル・コンシューマがメッセージをコンシュームし終わると、ソース・キューはメッセージを削除できます。

この確認システムによって、メッセージが常にソース・キューから宛先キューに確実に伝播されますが、構成によってはソース・キューが最適サイズより大きくなる可能性があります。ソース・キューが大きくなると、システム・グローバル領域(SGA)メモリーの使用量が増加し、ディスク領域の使用量も増加する場合があります。

ソース・キューの拡大には、通常、次の2つの原因があります。

- なんらかの理由(ネットワークの問題など)で、メッセージを指定された宛先キューに伝播できない場合、メッセージは宛先キューが使用可能になるまでソース・キューに残ります。この状況がソース・キューの拡大の原因となることがあります。そのため、キューを定期的に監視して問題を早期に検出する必要があります。

- 取得プロセスまたは同期取得によって取得されたメッセージをソース・キューが複数の宛先キューに伝播しており、1つ以上の宛先データベースが、他のキューよりもはるかに低速でメッセージが正常に伝播されたことを確認する場合を考えます。この場合、低速の宛先データベースでは、高速の宛先データベースによってすでに確認されたメッセージのバックログが作成されるため、ソース・キューが大きくなることがあります。このような環境では、複数の取得プロセスまたは同期取得を作成してソース・データベースでの変更を取得することを検討してください。これによって、あるソース・キューを低速の宛先データベースに、別のソース・キューを高速の宛先データベースに使用できます。

関連項目:

- 第2章「Oracle Streams情報取得」

- 「キューおよびメッセージの監視」

有向ネットワーク

有向ネットワークとは、伝播されるメッセージが宛先データベースに到達する前に1つ以上の中間データベースを経由するネットワークです。メッセージは、中間データベースで適用プロセスによって処理される場合と、処理されない場合があります。Oracle Streamsを使用すると、各宛先データベースに伝播させるメッセージを選択し、メッセージが宛先データベースに到達するまでのルートを指定できます。図3-2に、有向ネットワーク環境の例を示します。

図3-2 有向ネットワーク環境の例

有向ネットワークを使用する利点は、ソース・データベースと宛先データベースとの間に物理的なネットワーク接続を必要としないことです。そのため、メッセージをデータベース間で伝播する必要があるが、これらのデータベースを実行しているコンピュータ間にダイレクト・ネットワーク接続がない場合も、1つ以上の中間データベースがソース・データベースを宛先データベースに接続していれば、ネットワークを再構成せずにメッセージを伝播させることができます。

有向ネットワークを使用している場合に、中間サイトが長期間停止されるか、中間サイトが削除されると、ネットワークとOracle Streams環境の再構成が必要になることがあります。

キューによる転送および適用による転送

有向ネットワークにおける中間データベースでは、キューによる転送または適用による転送を使用してメッセージを伝播できます。キューによる転送は、中間データベースで転送されるメッセージが中間データベースによって受信されるメッセージであることを意味します。メッセージのソース・データベースは、メッセージが発生したデータベースです。

適用による転送は、中間データベースで転送されるメッセージが、最初に適用プロセスによって処理されることを意味します。このようなメッセージは、中間データベースで取得プロセスまたは同期取得によって再取得されてから転送されます。適用による転送を使用すると、中間データベースがメッセージの新しいソース・データベースになります。メッセージは、中間データベースで生成されたREDOログから取得プロセスによって再取得されるか、中間データベースで構成された同期取得によって再取得されます。

Oracle Streams環境を計画するときには、キューによる転送と適用による転送に次の違いがあることに注意してください。

- キューによる転送を使用すると、取得または伝播に伴う変換がなければ、メッセージは変更されずにそのまま有向ネットワークを介して伝播されます。適用による転送を使用すると、メッセージは中間データベースで適用および再取得され、競合解消、適用ハンドラまたは適用変換によって変更される場合があります。

- キューによる転送を使用する場合、宛先データベースでは、各ソース・データベースからのメッセージを個別の適用プロセスで適用する必要があります。適用による転送を使用すると、中間データベースでメッセージが再取得されることによって、変更が宛先データベースに到達する時点でソース・データベースの数が減少する場合があるため、宛先データベースに必要な適用プロセスの数が少数で済む可能性があります。

- キューによる転送を使用する場合は、ソース・データベースと宛先データベースの間に1つ以上の中間データベースが位置します。適用による転送を使用する場合、メッセージは中間データベースで再取得されるため、メッセージのソース・データベースは、宛先データベースと直接接続している中間データベースと同じでもかまいません。

単一のOracle Streams環境で、キューによる転送と適用による転送を併用できます。

キューによる転送の利点

キューによる転送には、適用による転送と比較して次の利点があります。

- メッセージが1回のみ取得されるため、パフォーマンスを改善できます。

- 1つ以上の中間データベースでメッセージが適用および再取得されることがないため、メッセージを生成元データベースから宛先データベースへと伝播させる所要時間が短縮されます。つまり、キューによる転送を使用すると、待機時間を短縮できる場合があります。

- メッセージの発生元は、メッセージに含まれているLCRに対してGET_SOURCE_DATABASE_NAMEメンバー・プロシージャを実行すると簡単に判断できます。適用による転送を使用する場合は、メッセージの発生元を判断するために、Oracle Streamsタグおよび適用ハンドラを使用する必要があります。

- 別々の適用プロセスを使用すると、依存性が低減し、複数の適用コーディネータと適用リーダー・プロセスによって作業が実行されるため、パラレル適用によってスケーラビリティが向上し、スループットが増大します。

- 1つの中間データベースが停止した場合、キューを再度ルーティングし、取得サイトで開始SCNをリセットして、エンドツーエンドの取得、伝播および適用を再構成できます。
適用による転送を使用すると、使用不可能になった中間データベースから宛先データベースへのダウンストリームでは、この中間データベースのSCN情報が使用されているため、メッセージについてエンドツーエンドの取得、伝播および適用の再構成に必要な作業量が実質的に増大します。このSCN情報がないと、宛先データベースでは変更を正しく適用できません。

適用による転送の利点

適用による転送には、キューによる転送と比較して次の利点があります。

- 各データベースは、複数のリモート・ソース・データベースではなく、直接接続されているデータベースからのみ変更を適用できるため、Oracle Streams環境の構成が容易です。

- 中間データベースによって変更が適用される大規模なOracle Streams環境では、適用プロセスが少数で済むため、環境の監視と管理が容易です。変更を適用する中間データベースでは、変更を受信するソース・データベースごとに1つの適.用プロセスが必要です。適用による転送の環境では、中間データベースのソース・データベースは、直接接続されているデータベースのみです。キューによる転送環境では、中間データベースのソース・データベースは、中間データベースに直接接続されているかどうかに関係なく環境内の他のすべてのデータベースです。

関連項目:

- 第4章「Oracle Streams情報コンシューム」

- キューによる転送を使用する環境の例については、『Oracle Streams拡張例』を参照

- 適用による転送を使用する環境の例については、『Oracle Streamsレプリケーション管理者ガイド』を参照

4 Oracle Streams情報コンシューム

次の各項では、Oracle Streamsでの情報のコンシュームについて説明します。

- Oracle Streamsでの情報コンシュームの概要

- 適用プロセスによる暗黙的コンシューム

- メッセージ・クライアントによる明示的コンシューム

- 手動デキューによる明示的コンシューム

関連項目:

- 第17章「Oracle Streams情報コンシュームの管理」

- 第26章「Oracle Streams適用プロセスの監視」

- 第33章「適用のトラブルシューティング」

Oracle Streamsでの情報コンシュームの概要

Oracle Streamsでの情報のコンシュームとは、キューから情報を含むメッセージをデキューして、メッセージを処理または廃棄することです。コンシュームされる情報は、データベースの変更に関する説明の場合もあれば、その他の情報である場合もあります。デキューされたメッセージは、デキューされたデータベースで生成されていることもあれば、別のデータベースで生成されていることもあります。

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

- Oracle Streamsで情報をコンシュームする方法

- Oracle Streamsでコンシュームされる情報のタイプ

- 情報コンシューム・オプションのまとめ

Oracle Streamsで情報をコンシュームする方法

次の各項では、Oracle Streamsで情報をコンシュームする方法について説明します。

- 暗黙的コンシューム

- 明示的コンシューム

暗黙的コンシューム

暗黙的コンシュームでは、適用プロセスが取得LCR、永続LCRまたは永続ユーザー・メッセージを自動的にデキューします。キューはANYDATAキューであることが必要です。メッセージに論理変更レコード(LCR)が含まれる場合、適用プロセスでは、LCRを直接適用することも、ユーザー指定プロシージャをコールして処理することも可能です。メッセージにLCRが含まれない場合、適用プロセスではメッセージ・ハンドラと呼ばれるユーザー指定プロシージャを起動してメッセージを処理できます。

注意:
取得LCRは適用プロセスによってデキューされる必要があります。ただし、適用プロセスまたは適用プロセスによってコールされたユーザー・プロシージャが取得LCRを再エンキューする場合、LCRは永続LCRになり明示的にデキューできます。

明示的コンシューム

明示的コンシュームでは、メッセージは次のいずれかの方法でデキューされます。

- メッセージ・クライアントで永続LCRまたは永続ユーザー・メッセージを明示的にデキューします。キューはANYDATAキューである必要があります。メッセージ・クライアントは、アプリケーションによって起動された場合にメッセージをデキューします。メッセージ・クライアントがメッセージをデキューした後、アプリケーションがメッセージを処理します。

- アプリケーションがメッセージを明示的に手動でデキューして処理します。アプリケーションは、タイプが永続LCR、永続ユーザー・メッセージ、バッファLCRおよびバッファ・ユーザー・メッセージであるメッセージをデキューできます。メッセージは、ANYDATAキューまたは型付きキューからデキューできます。

Oracle Streamsでコンシュームされる情報のタイプ

Oracle Streamsでコンシュームされる情報のタイプは次のとおりです。

- 取得LCR

- 永続LCR

- バッファLCR

- 永続ユーザー・メッセージ

- バッファ・ユーザー・メッセージ

関連項目:

- 「Oracle Streamsで取得される情報のタイプ」

- 「Oracle Streamsでの情報取得オプションのまとめ」

取得LCR

取得LCRは、取得プロセスによって暗黙的に取得され、ANYDATAキューのバッファ・キュー部分にエンキューされた論理変更レコード(LCR)です。

適用プロセスのみが取得LCRをデキューできます。デキュー後、適用プロセスは取得LCRを直接適用し、データベースを変更したり、取得LCRを取り消したり、処理のため適用ハンドラへ取得LCRを送信したり、永続キューに取得LCRを再エンキューしたりできます。

関連項目:

- 「Oracle Streams取得プロセスによる暗黙的取得」

- 「適用プロセスによる暗黙的コンシューム」

永続LCR

永続LCRは、ANYDATAキューの永続キュー部分にエンキューされた論理変更レコード(LCR)です。永続LCRは次のいずれかの方法でエンキューできます。

- 同期取得による暗黙的な取得およびエンキュー

- アプリケーションによる明示的な作成およびエンキュー

- 適用プロセスによるデキュー、および同じ適用プロセスによるDBMS_APPLY_ADMパッケージ内のSET_ENQUEUE_DESTINATIONプロシージャを使用したエンキュー

永続LCRは、適用プロセス、メッセージ・クライアントまたはアプリケーションでデキューできます。

関連項目:

- 「同期取得による暗黙的取得」

- 「アプリケーションによる明示的取得」

- 「適用プロセスによる暗黙的コンシューム」

- 「メッセージ・クライアントによる明示的コンシューム」

- 「手動デキューによる明示的コンシューム」

バッファLCR

バッファLCRは、アプリケーションによって明示的に作成され、ANYDATAキューのバッファ・キュー部分にエンキューされた論理変更レコード(LCR)です。アプリケーションのみがバッファLCRをデキューできます。

関連項目:

- 「アプリケーションによる明示的取得」

- 「手動デキューによる明示的コンシューム」

永続ユーザー・メッセージ

永続ユーザー・メッセージは、永続キューにエンキューされたユーザー定義型のLCR以外のメッセージです。永続ユーザー・メッセージは次のいずれかの方法でエンキューできます。

- アプリケーションによる明示的な作成およびエンキュー

- 適用プロセスによるデキュー、および同じ適用プロセスによるDBMS_APPLY_ADMパッケージ内のSET_ENQUEUE_DESTINATIONプロシージャを使用したエンキュー

適用プロセスおよびメッセージ・クライアントは、ANYDATAキューの永続ユーザー・メッセージのみをデキューできます。アプリケーションは、ANYDATAキューまたは型付きキューの永続ユーザー・メッセージをデキューできます。

関連項目:

- 「アプリケーションによる明示的取得」

- 「適用プロセスによる暗黙的コンシューム」

- 「メッセージ・クライアントによる明示的コンシューム」

- 「手動デキューによる明示的コンシューム」

バッファ・ユーザー・メッセージ

バッファ・ユーザー・メッセージは、アプリケーションによって明示的に作成され、バッファ・キューにエンキューされたユーザー定義型のLCR以外のメッセージです。バッファ・ユーザー・メッセージは、ANYDATAキューまたは型付きキューのバッファ・キュー部分にエンキューできます。アプリケーションのみがバッファ・ユーザー・メッセージをデキューできます。

関連項目:

- 「アプリケーションによる明示的取得」

- 「手動デキューによる明示的コンシューム」

情報コンシューム・オプションのまとめ

表4-1に、Oracle Streamsで使用可能な情報コンシューム・オプションのまとめを示します。

表4-1 Oracle Streamsでの情報コンシューム・オプション

コンシュームのタイプ

メッセージのデキュー

メッセージのタイプ

使用ケース

適用プロセスによる暗黙的コンシューム

有効にすると自動的に継続して行われる

取得LCR

永続LCR

永続ユーザー・メッセージ

取得LCRをデキューして処理する場合。

永続LCRまたは永続ユーザー・メッセージを、ANYDATAキューの永続キュー部分から自動的に継続してデキューする場合。

データベースを変更するためにデータベース・オブジェクトに直接適用する必要があるLCRをデキューする場合。

メッセージをデキューし、適用ハンドラを使用して処理する場合。

メッセージ・クライアントによる明示的コンシューム

アプリケーションから起動されたときに行われる

永続LCR

永続ユーザー・メッセージ

単純な方法を使用して、ANYDATAキューの永続キュー部分から永続LCRまたは永続ユーザー・メッセージを必要に応じてデキューする場合。

デキューの後でメッセージをアプリケーションに処理のために送信する場合。

手動デキューによる明示的コンシューム

アプリケーションのロジックに基づいて手動で行われる

永続LCR

バッファLCR

永続ユーザー・メッセージ

バッファ・ユーザー・メッセージ

アプリケーションで永続LCRまたはバッファLCRを手動でANYDATAキューからデキューし、処理する場合。

アプリケーションで永続ユーザー・メッセージまたはバッファ・ユーザー・メッセージを手動でANYDATAキューまたは型付きキューからデキューし、処理する場合。

注意:
1つのデータベースで、この表の情報コンシューム・オプションを任意に組み合せて使用することができます。

関連項目:

- 第2章「Oracle Streams情報取得」

- メッセージのエンキューの詳細は、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドを参照

- LCRの管理の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

適用プロセスによる暗黙的コンシューム

この項では、Oracle Streamsの適用プロセスに関連する概念について説明します。

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

- 適用プロセスの概要

- 適用プロセスのルール

- 適用プロセスで処理できるメッセージのタイプ

- 適用プロセスのメッセージ処理オプション

- 適用プロセスによって適用されるメッセージのソース

- 適用されるデータ型

- 適用時の自動データ型変換

- SQL生成

- Oracle Streamsの適用プロセスおよびRESTRICTED SESSION

- 適用プロセスのサブコンポーネント

- 適用ユーザー

- 適用プロセス・パラメータ

- データベースの再起動時における適用プロセスの永続的状態

- エラー・キュー

適用プロセスの概要

適用プロセスとは、メッセージを特定のキューからデキューし、各メッセージを直接適用したり、廃棄したり、適用ハンドラにパラメータとして渡したり、または再リクエストするための、オプションのOracleバックグラウンド・プロセスです。これらのメッセージは、論理変更レコード(LCR)またはユーザー・メッセージです。

注意:
適用プロセスでデキューできるのは、ANYDATAキューのメッセージのみです。型付きキューからはデキューできません。

適用プロセスのルール

適用プロセスは、ユーザーが定義するルールに基づいてメッセージを適用します。LCRの場合は、各ルールでTRUEと評価するデータベース・オブジェクトと変更の種類を指定します。ユーザー・メッセージの場合は、特定のタイプのメッセージに対する適用プロセスの動作を制御するルールを作成できます。これらのルールは、適用プロセスのポジティブ・ルール・セットまたはネガティブ・ルール・セットに指定します。

メッセージに対してルールがTRUEと評価され、そのルールが適用プロセスのポジティブ・ルール・セットに含まれる場合、適用プロセスはメッセージをデキューして処理します。メッセージに対してルールがTRUEと評価され、そのルールが適用プロセスのネガティブ・ルール・セットに含まれる場合、適用プロセスはメッセージを廃棄します。適用プロセスにポジティブ・ルール・セットとネガティブ・ルール・セットの両方がある場合、ネガティブ・ルール・セットが常に最初に評価されます。

LCRの適用プロセスのルールは次のレベルで指定できます。

- 表ルールは、特定の表に対するDML変更による行変更またはDDL変更を適用または廃棄します。サブセット・ルールは、特定の表に対する行変更のサブセットを含む表ルールです。

- スキーマ・ルールは、特定のスキーマのデータベース・オブジェクトに対するDML変更による行変更またはDDL変更を適用または廃棄します。

- グローバル・ルールは、適用プロセスに関連付けられているキュー内のDML変更によるすべての行変更またはすべてのDDL変更を適用または廃棄します。

関連項目:

- 第11章「ルールの高度な概念」

- 第5章「Oracle Streamsでのルールの使用方法」

- 「ルールの管理」

適用プロセスで処理できるメッセージのタイプ

適用プロセスでデキューできるメッセージのタイプを次に示します。

- 取得LCR: 取得プロセスによって暗黙的に取得され、ANYDATAキューのバッファ・キュー部分にエンキューされた論理変更レコード(LCR)。状況によっては、最適化を行って、取得プロセスでLCRを適用プロセスにより効率的に送信することもできます。このような最適化は、取得と適用の複合と呼ばれます。

- 永続LCR: 同期取得によって暗黙的に取得されたLCR、アプリケーションによって永続的に作成およびエンキューされたLCR、または適用プロセスによってエンキューされたLCR。永続LCRはANYDATAキューの永続キュー部分にエンキューされます。

- 永続ユーザー・メッセージ: アプリケーションまたは適用プロセスによって明示的にエンキューされたユーザー定義型のLCR以外のメッセージ。永続ユーザー・メッセージは、ANYDATAキューの永続キュー部分にエンキューされます。また、ユーザー・メッセージはANYDATAキューまたは型付きキューにエンキューできますが、適用プロセスでデキューできるのはANYDATAキューのユーザー・メッセージのみです。

1つの適用プロセスで、1つのキューのバッファ・キュー部分と永続キュー部分の両方からデキューを行うことはできません。バッファ・キューと永続キューの両方のメッセージを適用プロセスで処理する必要がある場合は、宛先データベースにメッセージを処理するための2つ以上の適用プロセスが必要です。

関連項目:

- 「メッセージのステージングと伝播の概要」

- 適用プロセスを作成する方法の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- 第12章「取得と適用の複合による最適化」

適用プロセスのメッセージ処理オプション

適用プロセスは、メッセージを直接適用するか、メッセージを適用ハンドラに送信して処理します。メッセージ処理のオプションは、適用プロセスで受信したメッセージが行論理変更レコード(行LCR)、DDL論理変更レコード(DDL LCR)、ユーザー・メッセージのいずれであるかによって異なります。

図4-1に、適用プロセスのメッセージ処理オプションおよび様々なタイプのメッセージに使用できるオプションを示します。

図4-1 適用プロセスのメッセージ処理オプション

デフォルトでは、適用プロセスはLCRを直接適用します。適用プロセスは、LCR内の変更を該当のデータベース・オブジェクトに対して実行します。LCR内の変更が正常に適用されなかった場合、つまり、競合または適用エラーが発生した場合は、競合ハンドラまたはエラー・ハンドラと呼ばれるユーザー指定プロシージャを使用してエラーの解決が試行されます。

競合ハンドラが競合を解消できる場合は、競合ハンドラがLCRを適用するか、LCR内の変更を廃棄します。エラー・ハンドラがエラーを解決できる場合は、エラー・ハンドラが必要に応じてLCRを適用します。エラー・ハンドラは、適用前にLCRを変更することでエラーを解決できる場合があります。競合ハンドラまたはエラー・ハンドラがエラーを解決できない場合、適用プロセスは、トランザクションとトランザクションに関連付けられたすべてのLCRをエラー・キューに入れます。

LCRを直接適用するかわりに、適用ハンドラを使用し、カスタマイズした方法でLCRを処理することもできます。適用ハンドラを使用した場合、適用プロセスはメッセージをSQL文のコレクションに渡すか、またはユーザー定義のPL/SQLプロシージャに渡します。適用ハンドラにより、メッセージをカスタムな方法で処理することができます。

適用プロセスは、ユーザー・メッセージを直接適用することはできません。ユーザー・メッセージをデキューする適用プロセスは、そのユーザー・メッセージを処理するためのメッセージ・ハンドラを持つ必要があります。

適用ハンドラにはいくつかのタイプがあります。この項では、適用ハンドラを次のカテゴリに分けて説明します。

表4-2 適用ハンドラの特性

カテゴリ

説明

メカニズム

適用ハンドラがメッセージの処理に使用する手段のことです。適用ハンドラに使用されるメカニズムは、SQL文、またはユーザー定義のPL/SQLプロシージャです。

メッセージのタイプ

適用ハンドラによって処理されるメッセージのタイプです。メッセージ・タイプには、行論理変更レコード(行LCR)、DDL論理変更レコード(DDL LCR)、永続ユーザー・メッセージ、およびトランザクション制御ディレクティブがあります。

メッセージ・クリエータ

適用ハンドラによって処理されるメッセージを作成するコンポーネントです。メッセージ・クリエータは、取得プロセス、同期取得、またはアプリケーションのいずれかになります。

有効範囲

適用ハンドラに設定されたレベルのことです。有効範囲は、1つの表に対する1つの操作か、またはすべてのデータベースに対するすべての操作のいずれかになります。

各適用プロセスへの割当て数

各適用プロセスに対して、そのタイプの適用ハンドラがいくつ割り当てられるかを示す数です。割当て数は1つまたは複数のいずれかになります。

適用ハンドラの各タイプについては、次の各項で説明しています。

- DMLハンドラ

- DDLハンドラ

- メッセージ・ハンドラ

- プリコミット・ハンドラ

- 適用ハンドラに関する考慮事項

注意:
適用プロセスはLCR以外のメッセージを直接適用することはできません。適用プロセスでデキューしたユーザー・メッセージは、メッセージ・ハンドラで処理する必要があります。

DMLハンドラ

DMLハンドラは、適用プロセスによってデキューされた行論理変更レコード(行LCR)を処理します。DMLハンドラには2つのタイプがあります。文DMLハンドラとプロシージャDMLハンドラです。文DMLハンドラは、SQL文のコレクションを使用して行LCRを処理します。一方プロシージャDMLハンドラは、PL/SQLプロシージャを使用して行LCRを処理します。

DMLハンドラとエラー・ハンドラについては、次の各項で詳しく説明しています。

- 文DMLハンドラ

- プロシージャDMLハンドラ

文DMLハンドラ

文DMLハンドラの特性は次のとおりです。

- メカニズム: SQL文のコレクション

- メッセージのタイプ: 行LCR

- メッセージ・クリエータ: 取得プロセス、同期取得、またはアプリケーション

- 有効範囲: 1つの表に対する1つの操作

- 各適用プロセスへの割当て数: 複数(同じ表に対する同じ操作について複数指定可能)

文DMLハンドラに含まれる各SQL文には、それぞれ固有の実行順序番号があります。文DMLハンドラが呼び出されると、文は実行順序番号の小さいものから大きいものへと進める順序で実行されます。実行順序番号は、正の数、負の数、または小数で指定できます。

文DMLハンドラは、適用プロセスに関連付けられている表ごとに個別に設定できます。処理できる操作(行LCR内の操作)は次のとおりです。

- INSERT

- UPDATE

- DELETE

文DMLハンドラは、特定の表に対する特定の操作に対応し、その操作を実行する行LCRが適用プロセスによってデキューされたときに呼び出されます。そのため、たとえばhr.employees表でINSERT操作を処理するための文DMLハンドラを1つ設定し、それとは別に、UPDATE操作を処理するための文DMLハンドラをもう1つ設定することなどが可能です。また、hr.employees表にあるこれら各タイプの操作に、同じ文DMLハンドラを使用することもできます。

同じ表に対する同じ操作について、複数の文DMLハンドラを指定することもできます。その場合、それらの文DMLハンドラは任意の順序で実行できます。なお、それぞれの文DMLハンドラは、適用プロセスによってデキューされた、元の行LCRのコピーを受け取ります。

文DMLハンドラ内のSQL文では、行LCRに含まれる次のタイプの操作を使用することができます。

- INSERT

- UPDATE

- DELETE

- MERGE

たとえば、文DMLハンドラ内のSQL文で、hr.employees表を更新する行LCRを処理し、その文に、別の表への行挿入を行うためのINSERT操作を含めることなどもできます。

文DMLハンドラでは、行LCR上の有効なDML文を実行することはできますが、行LCR内の列値を修正することはできません。ただし、文DMLハンドラでSQLを使用し、行を挿入したり、行LCRの列値とは異なる列値で行を更新できます。なお、文DMLハンドラによってコミットやロールバックが実行されることはありません。

文DMLハンドラ内で行LCRを実行するには、その行LCRのEXECUTEメンバー・プロシージャを呼び出します。EXECUTEメンバー・プロシージャを実行する文は、文DMLハンドラの何番目の実行順序番号に配置することもできます。行LCRは、文DMLハンドラ内のその他のSQL文実行以外に、行LCRの変更を特定の表に適用する場合以外は実行する必要はありません。

文DMLハンドラに文を追加するには、DBMS_STREAMS_HANDLER_ADMパッケージ内のADD_STMT_TO_HANDLERプロシージャを使用します。適用プロセスに文DMLハンドラを追加するには、DBMS_APPLY_ADMパッケージ内のADD_STMT_HANDLERプロシージャを使用します。文DMLハンドラは、特定の適用プロセスに対して追加することもできますし、データベース内のすべての適用プロセスによって使用される、汎用の文DMLハンドラとして追加することもできます。表の操作に対する文DMLハンドラが特定の適用プロセスによって使用され、かつ別の文DMLハンドラが同じ表の同じ操作に対する汎用ハンドラとして存在する場合、適用プロセスでその表への操作を含む行LCRがデキューされたときには、両方のハンドラが呼び出されます。各文DMLハンドラによって元の行LCRが受け取られ、文DMLハンドラは任意の順序で実行できます。

文DMLハンドラは、表に加えられた変更を記録する目的で使用されることもよくあります。また、文DMLハンドラでは、列値を修正しないで変更を実行することもできます。たとえば、文DMLハンドラを使用して、特定の列のデータ型を変更することなども可能です。

注意:

- ADD_STMT_HANDLERプロシージャを実行するときは、ハンドラを使用する対象のオブジェクトを指定します。このオブジェクトはプロシージャの実行時に宛先データベースに存在する必要はありません。

- 変更ハンドラは、表の変更を追跡する特殊なタイプの文DMLハンドラで、DBMS_STREAMS_ADM.MAINTAIN_CHANGE_TABLEプロシージャとDBMS_APPLY_ADM.SET_CHANGE_HANDLERプロシージャのいずれかによって作成されます。

関連項目:

- 「文DMLハンドラの管理」

- 「文DMLハンドラに関する情報の表示」

- 「行LCR」

- 「適用ハンドラではサポートされていないデータ型」

- 変更ハンドラの詳細は、第20章「Oracle Streamsを使用した表の変更の記録」を参照

- LCRタイプのEXECUTEメンバー・プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

プロシージャDMLハンドラ

プロシージャDMLハンドラの特性は次のとおりです。

- メカニズム: ユーザー定義のPL/SQLプロシージャ

- メッセージのタイプ: 行LCR

- メッセージ・クリエータ: 取得プロセス、同期取得、またはアプリケーション

- 有効範囲: 1つの表に対する1つの操作

- 各適用プロセスへの割当て数: 複数(ただし、同じ表に対する同じ操作については1つのみ指定可能)

プロシージャDMLハンドラは、適用プロセスに関連付けられている表ごとに個別に設定できます。処理できる操作(行LCR内の操作)は次のとおりです。

- INSERT

- UPDATE

- DELETE

- LOB_UPDATE

プロシージャDMLハンドラは、特定の表に対する特定の操作に対応し、その操作を実行する行LCRが適用プロセスによってデキューされたときに呼び出されます。そのため、たとえばhr.employees表でINSERT操作を処理するためのプロシージャDMLハンドラを1つ設定し、それとは別に、UPDATE操作を処理するためのプロシージャDMLハンドラをもう1つ設定することなどが可能です。また、hr.employees表にあるこれら各タイプの操作に、同じプロシージャDMLハンドラを使用することもできます。

PL/SQLプロシージャでは、行LCRの処理を自由にカスタマイズして実行できます。たとえば、ソース・データベースの特定の表に対して挿入が行われるたびに、宛先データベースの複数の表に対して挿入が実行されるようにする場合は、その表に対するINSERT操作を処理するためのPL/SQLプロシージャをユーザー定義で作成すれば解決できます。文DMLハンドラと違い、プロシージャDMLハンドラでは行LCR内の列値を修正することができます。

プロシージャDMLハンドラによってコミットやロールバックが実行されることはありません。ただし、ユーザー定義のPL/SQLプロシージャによって設定された名前付きセーブポイントがある場合は例外です。DMLハンドラ内で行LCRを実行するには、行LCRのEXECUTEメンバー・プロシージャを呼び出します。なお、プロシージャDMLハンドラでは、処理中に発生したエラーをすべて処理する必要があります。

プロシージャDMLハンドラを設定するには、DBMS_APPLY_ADMパッケージ内のSET_DML_HANDLERプロシージャを使用します。プロシージャDMLハンドラは、特定の適用プロセスに対して設定することもできますし、データベース内のすべての適用プロセスによって使用される、汎用のハンドラとして設定することもできます。なお、ある表への操作を処理するプロシージャDMLハンドラが特定の適用プロセス専用に設定されていて、それとは別に、それと同じ表への同じ操作を処理する汎用のプロシージャDMLハンドラも存在する場合は、専用のハンドラが汎用のハンドラよりも優先されます。

プロシージャDMLハンドラは通常、行LCRをカスタムで処理するために、Oracle Streamsレプリケーション環境内で使用されますが、レプリケーション環境以外で使用することもできます。たとえば、データベース・オブジェクトに加えられた変更を、レプリケートせずに記録する場合にも使用できます。

注意:
SET_DML_HANDLERプロシージャを実行するときは、ハンドラを使用する対象のオブジェクトを指定します。このオブジェクトはプロシージャの実行時に宛先データベースに存在する必要はありません。

関連項目:

- 「行LCR」

- 「適用ハンドラではサポートされていないデータ型」

- LCRタイプのEXECUTEメンバー・プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

- 「DMLハンドラの管理」

エラー・ハンドラ

エラー・ハンドラの特性は次のとおりです。

- メカニズム: ユーザー定義のPL/SQLプロシージャ

- メッセージのタイプ: 行LCR

- メッセージ・クリエータ: 取得プロセス、同期取得、またはアプリケーション

- 有効範囲: 1つの表に対する1つの操作

- 各適用プロセスへの割当て数: 複数(ただし、同じ表に対する同じ操作については1つのみ指定可能)

エラー・ハンドラは、プロシージャDMLハンドラに似ています。ただしエラー・ハンドラは、特定の表に対して特定の操作を行うための行LCRを適用プロセスが適用する際、適用エラーが発生した場合にのみ呼び出されます。

エラー・ハンドラは基本的にプロシージャDMLハンドラと同じ方法で作成しますが、SET_DML_HANDLERプロシージャを実行する際、error_handlerパラメータをTRUEに設定するという点が異なります。

エラー・ハンドラは、同じ表への同じ操作を行うプロシージャDMLハンドラとは共存できません。ただし、同じ表に同じ操作を行う場合でも、文DMLハンドラエラー・ハンドラとは共存できます。

注意:
文DMLハンドラは、エラー・ハンドラとしては使用できません。

関連項目:

- 「行LCR」

- 「適用ハンドラではサポートされていないデータ型」

DDLハンドラ

DDLハンドラの特性は次のとおりです。

- メカニズム: ユーザー定義のPL/SQLプロシージャ

- メッセージのタイプ: DDL LCR

- メッセージ・クリエータ: 取得プロセス、またはアプリケーション

- 有効範囲: 適用プロセスによってデキューされたすべてのDDL LCR

- 各適用プロセスへの割当て数: 1つ

ユーザー定義のPL/SQLプロシージャでは、DDL LCRの処理を自由にカスタマイズして実行できます。たとえば、DDL変更を適用の前に記録する場合、DDL操作の処理に使用するプロシージャを独自に作成することでこのことを実現できます。

DDLハンドラ内でDDL LCRを実行するには、DDL LCRのEXECUTEメンバー・プロシージャを起動します。DDLハンドラを特定の適用プロセスに関連付けるには、DBMS_APPLY_ADMパッケージのCREATE_APPLYプロシージャまたはALTER_APPLYプロシージャのddl_handlerパラメータを使用します。

DDLハンドラは通常、DDL LCRをカスタムで処理するために、Oracle Streamsレプリケーション環境内で使用されますが、レプリケーション環境以外で使用することもできます。たとえば、データベース・オブジェクトに加えられた変更を、レプリケートせずに記録する場合にも使用できます。

関連項目:

- 「DDL LCR」

- LCRタイプのEXECUTEメンバー・プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

- DDLハンドラの詳細は、「DDLハンドラの管理」を参照

メッセージ・ハンドラ

メッセージ・ハンドラの特性は次のとおりです。

- メカニズム: ユーザー定義のPL/SQLプロシージャ

- メッセージのタイプ: 永続ユーザー・メッセージ(非LCR)

- メッセージ・クリエータ: アプリケーション

- 有効範囲: 適用プロセスによってデキューされたすべてのユーザー・メッセージ

- 各適用プロセスへの割当て数: 1つ

メッセージ・ハンドラは、1つ以上のリモート・データベースの更新または他のリモート・アクションを実行する必要のあるアプリケーションを含む環境においてメリットがあります。このようなアプリケーションが永続ユーザー・メッセージをローカル・データベースのキューにエンキューすると、Oracle Streamsが各永続ユーザー・メッセージを宛先データベースの適切なキューに伝播できます。複数の宛先がある場合、Oracle Streamsはこれらのメッセージを自動的に各宛先に伝播して処理するためのインフラストラクチャを提供します。宛先が1つしかない場合も、Oracle Streamsはソース・データベースのアプリケーションと宛先データベースのアプリケーションの間にレイヤーを提供します。これによって、リモート・データベースのアプリケーションが使用不可能になった場合も、ソース・データベースのアプリケーションはそのまま正常に動作できます。

たとえば、メッセージ・ハンドラは、永続ユーザー・メッセージを電子メール・メッセージに変換できます。この場合、永続ユーザー・メッセージには、from、to、subject、text_of_messageなど、電子メール・メッセージで使用される属性を含めることができます。メッセージを電子メール・メッセージに変換した後、メッセージ・ハンドラがそのメッセージを電子メール・ゲートウェイを介して送信できます。

適用プロセスにメッセージ・ハンドラを指定するには、DBMS_APPLY_ADMパッケージのCREATE_APPLYプロシージャまたはALTER_APPLYプロシージャのmessage_handlerパラメータを使用します。Oracle Streams適用プロセスでは、常に、LCR以外のメッセージはキューのその他のメッセージに依存しないとみなされます。永続ユーザー・メッセージを適用する適用プロセスの並列性が1より大きい場合、これらのメッセージはメッセージ・ハンドラによって任意の順序でデキューされます。このため、ご使用の環境でメッセージ間に依存性がある場合は、適用プロセスの並列性を1に設定することをお薦めします。

関連項目:

- 「適用プロセスのメッセージ・ハンドラの管理」

プリコミット・ハンドラ

プリコミット・ハンドラの特性は次のとおりです。

- メカニズム: ユーザー定義のPL/SQLプロシージャ

- メッセージのタイプ: 行LCRまたは永続ユーザー・メッセージを含むトランザクションのコミット・ディレクティブ

- メッセージ・クリエータ: 取得プロセス、同期取得、またはアプリケーション

- 有効範囲: 適用プロセスによってデキューされたコミット・ディレクティブに付属するすべての行LCR

- 各適用プロセスへの割当て数: 1つ

プリコミット・ハンドラを使用して、取得LCRのコミット・ディレクティブ、および永続LCRと永続ユーザー・メッセージのトランザクション境界を監査できます。コミット・ディレクティブは、COMMITを含むトランザクション制御ディレクティブです。プリコミット・ハンドラは、トランザクションのコミット情報を受信し、カスタマイズした方法でコミット情報を処理できるユーザー定義のPL/SQLプロシージャです。プリコミット・ハンドラは、文DMLハンドラ、プロシージャDMLハンドラ、またはメッセージ・ハンドラと併用できます。

たとえば、プリコミット・ハンドラで1トランザクション分のデータをキャッシュすることで、パフォーマンスが改善される場合があります。このデータには、カーソル、一時LOB、メッセージのデータなどが含まれます。プリコミット・ハンドラは、トランザクションが完了すると、ハンドラでキャッシュしたオブジェクトを解放または実行できます。

プリコミット・ハンドラは、適用プロセスがトランザクションをコミットするときに実行されます。適用プロセスのcommit_serializationパラメータを使用すると、適用プロセスのコミット順序を制御できます。

次に、コミット・ディレクティブとトランザクション境界について説明します。

- 取得LCRのコミット・ディレクティブ: 取得プロセスの使用中にユーザーがトランザクションをコミットすると、取得プロセスによって取得された行LCRがトランザクションに含まれている場合、取得プロセスによってトランザクションの内部コミット・ディレクティブが取得されます。また、取得プロセスによって、トランザクション内の各取得LCRにトランザクション識別子も記録されます。
コミット・ディレクティブは、エンキューされた後、トランザクション内のLCRとともに宛先キューに伝播できます。プリコミット・ハンドラによって、これらの内部コミット・ディレクティブのコミットSCNが適用プロセスのキューに受信されます。その後、それらのコミット・ディレクティブが適用プロセスによって処理されます。

- 同期取得によってエンキューされた永続LCRのトランザクション境界: 同期取得の使用中にユーザーがトランザクションをコミットすると、同期取得によってエンキューされた永続LCRはメッセージ・グループに編成されます。同期取得では、トランザクション内の各永続LCRにトランザクション識別子が記録されます。
同期取得によって永続LCRがエンキューされた後、メッセージ・グループの永続LCRを他のキューに伝播できます。適用プロセスがこれらの永続LCRを処理するように構成されている場合は、メッセージ・グループのすべての永続LCRに対して1つのコミットSCNが生成されます。個々の適用プロセスで生成されるコミットSCNの値は、ソース・トランザクションまたは他の適用プロセスで生成される値とは関係ありません。そのような適用プロセスに対して構成されているプリコミット・ハンドラが、適用プロセスによって提供されるコミットSCNを受信します。

- アプリケーションによってエンキューされたメッセージのトランザクション境界: アプリケーションでは、永続LCR、永続ユーザー・メッセージおよびその他のタイプのメッセージをエンキューできます。これらのエンキュー操作を行っているユーザーが、COMMIT文を発行してトランザクションを終了すると、エンキューされた永続LCRおよび永続ユーザー・メッセージは、メッセージ・グループに編成されます。
アプリケーションによってエンキューされたメッセージがメッセージ・グループに分類されると、メッセージ・グループのメッセージを他のキューに伝播できます。適用プロセスがこれらのメッセージを処理するように構成されている場合は、メッセージ・グループのすべてのメッセージに対して1つのトランザクション識別子とコミットSCNを生成します。個々の適用プロセスで生成されるトランザクション識別子とコミットSCNの値は、ソース・トランザクションまたは他の適用プロセスで生成される値とは関係ありません。そのような適用プロセスに対して構成されているプリコミット・ハンドラが、適用プロセスによって提供されるコミットSCNを受信します。

関連項目:

- 「適用プロセスのプリコミット・ハンドラの管理」

- 適用プロセス・パラメータの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

適用ハンドラに関する考慮事項

適用ハンドラを使用する際には、次の点を考慮する必要があります。

- 文DMLハンドラとプロシージャDMLハンドラは、どちらも行LCRを処理します。違いとしては、プロシージャDMLハンドラではPL/SQLの処理が必要なのに対し、文DMLハンドラでは必要ありません。そのため、通常は文DMLハンドラの方がプロシージャDMLハンドラよりもよいパフォーマンスで動作します。また、通常は構成作業も文DMLハンドラの方が簡単です。ただし、プロシージャDMLハンドラには、文DMLハンドラで処理できない操作を実行できるという利点があります(プログラム・フローの制御やエラーのトラップなど)。また、プロシージャDMLハンドラでは、行LCR内の列値を修正することもできます(文DMLハンドラではできない)。

- 文DMLハンドラ、プロシージャDMLハンドラ、エラー・ハンドラ、DDLハンドラおよびメッセージ・ハンドラは、LCRのEXECUTEメンバー・プロシージャをコールしてLCRを実行できます。

- すべての適用済DDL LCRは、自動的にコミットされます。したがって、DDLハンドラがDDL LCRのEXECUTEメンバー・プロシージャをコールすると、自動的にコミットが実行されます。

- PL/SQLプロシージャを使用する適用ハンドラは、Oracle Streamsセッション・タグを設定できます。文DMLハンドラは、Oracle Streamsセッション・タグを設定できません。

- ユーザー定義のPL/SQLプロシージャを使用する適用ハンドラは、PL/SQLプロシージャでパブリッシュ(またはラップ)されたJavaストアド・プロシージャをコールできます。文DMLハンドラは、Javaストアド・プロシージャをコールできません。

- 適用プロセスが、存在しない適用ハンドラまたは無効な適用ハンドラを起動しようとすると、その適用プロセスは強制終了されます。

- PL/SQLプロシージャを使用した適用ハンドラでOracle提供パッケージのプロシージャまたはファンクションを呼び出す場合、適用ハンドラを実行するユーザーにはそのパッケージに対する直接のEXECUTE権限が必要です。ロールを介してこの権限を付与するのみでは不十分です。DBMS_STREAMS_AUTH.GRANT_ADMIN_PRIVILEGEプロシージャを実行すると、すべてのOracle Streamsパッケージ、およびOracle Streamsに関連する他の権限に対するEXECUTE権限が付与されます。一方、文DMLハンドラではプロシージャやファンクションを呼び出すことはできません。

関連項目:

- LCRタイプのEXECUTEメンバー・プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

- Oracle Streamsタグの詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

メッセージ処理オプションのまとめ

前述した1つ以上の適用ハンドラを使用する場合に有効なメッセージ処理オプションを、この項の表に示します。行LCRとDDL LCRは適用プロセスで直接適用できるため、適用ハンドラはオプションです。ただし、永続ユーザー・メッセージを処理するにはメッセージ・ハンドラが必須です。また、適用プロセスがメッセージをデキューするのは、そのメッセージが適用プロセスのルール・セットを満たしている場合のみです。通常、メッセージが適用プロセスのルール・セットを満たすのは、メッセージについてネガティブ・ルール・セットのどのルールもTRUEと評価されず、ポジティブ・ルール・セットの少なくとも1つのルールがTRUEと評価された場合です。

表4-3は、適用プロセスのメッセージ処理オプションをまとめたものです。

表4-3 メッセージ処理オプションのまとめ

メッセージ処理オプション

メカニズム

メッセージのタイプ

メッセージ・クリエータ

適用プロセスのデフォルト動作

ハンドラの有効範囲

各適用プロセスへの割当て数

メッセージの直接適用

該当なし

行LCRまたはDDL LCR

メッセージ・クリエータ: 取得プロセス、同期取得、またはアプリケーション

DMLまたはDDLを実行

該当なし

該当なし

文DMLハンドラ

SQL文

行LCR

メッセージ・クリエータ: 取得プロセス、同期取得、またはアプリケーション

DMLを実行

1つの表に対する1つの操作

複数(ただし、同じ表に対する同じ操作については複数指定可能)

プロシージャDMLハンドラまたはエラー・ハンドラ

ユーザー定義のPL/SQLプロシージャ

行LCR

メッセージ・クリエータ: 取得プロセス、同期取得、またはアプリケーション

DMLを実行

1つの表に対する1つの操作

複数(ただし、同じ表に対する同じ操作については1つのみ指定可能)

DDLハンドラ

ユーザー定義のPL/SQLプロシージャ

DDL LCR

取得プロセス、またはアプリケーション

DDLを実行

適用プロセス全体

1つ

メッセージ・ハンドラ

ユーザー定義のPL/SQLプロシージャ

永続ユーザー・メッセージ

アプリケーション

エラー・トランザクションを作成(メッセージ・ハンドラが存在しない場合)

適用プロセス全体

1つ

プリコミット・ハンドラ

ユーザー定義のPL/SQLプロシージャ

行LCRまたはユーザー・メッセージを含むトランザクションのコミット・ディレクティブ

メッセージ・クリエータ: 取得プロセス、同期取得、またはアプリケーション

トランザクションをコミット

適用プロセス全体

1つ

ここで説明したメッセージ処理オプションに加えて、DBMS_APPLY_ADMパッケージのSET_ENQUEUE_DESTINATIONプロシージャを使用すると、指定した宛先キューの永続キュー部分にメッセージをエンキューするように適用プロセスに指示できます。また、メッセージの実行を制御するには、DBMS_APPLY_ADMパッケージのSET_EXECUTEプロシージャを使用する方法もあります。

関連項目:

- 第5章「Oracle Streamsでのルールの使用方法」

- 「適用プロセスによるメッセージのエンキューの指定」

- 「適用プロセスの実行ディレクティブの指定」

適用プロセスによって適用されるメッセージのソース

適用プロセスで処理できる様々なメッセージのタイプに対応するソース・データベースを次に示します。

- 取得LCRの場合、ソース・データベースは、LCRにカプセル化された変更がREDOログに生成されたデータベースです。

- 同期取得によって取得された永続LCRの場合、ソース・データベースは、行LCRを取得した同期取得が構成されているデータベースです。

- アプリケーションによって作成およびエンキューされた永続LCRの場合、ソース・データベースはメッセージが最初にエンキューされたデータベースです。

- ユーザー・メッセージの場合、ソース・データベースは、メッセージが最初にエンキューされたデータベースです。

1つの適用プロセスでは、複数のデータベースで発生したユーザー・メッセージを適用できます。一方、1つの適用プロセスでは、1つのソース・データベースのみから取得された取得LCRを適用できます。同様に、1つの適用プロセスでは、1つのソース・データベースのみから同期取得によって取得された永続LCRを適用できます。このようなLCRの適用には、依存関係、有効なトランザクション順序指定、およびソース・データベースでのトランザクション境界の理解が必要です。

複数のデータベースの取得LCRを1つの宛先キューに送信できます。同期取得により取得された永続LCRについても同様です。ただし、1つのキューに複数のソース・データベースのLCRが含まれる場合、それらのLCRを取得する複数の適用プロセスが必要です。ルールを使用して各適用プロセスが1つのソース・データベースからのメッセージを受信するように構成してください。各ソース・データベースのメッセージに対して別のANYDATAキューを使用することをお薦めします。

また、各適用プロセスで適用できるのは、1つの取得プロセスからの取得LCRのみです。ソース・データベース上で複数の取得プロセスが実行されていて、複数の取得プロセスからのLCRが宛先データベースで適用される場合は、各取得プロセスからの変更を適用するために1つの適用プロセスが必要です。このような環境では、取得プロセス、伝播または適用プロセスで使用される各ANYDATAキューで、特定のソース・データベースの最大1つの取得プロセスからの取得LCRを格納することをお薦めします。キューが複数の取得プロセスからのLCRを含むことができるのは、各取得プロセスが別のソース・データベースで発生した変更を取得している場合です。

同じソース・データベースの複数の同期取得で取得された永続LCRにも同じ制約が適用されます。これらのLCRは別のANYDATAキューに格納し、個別の適用プロセスを使用して各同期取得のLCRを適用します。

注意:
取得LCRはキューのバッファ・キュー部分に格納されますが、永続LCRはキューの永続キュー部分に格納されます。このため、1つの適用プロセスで取得LCRと永続LCRの両方を適用することはできません。

関連項目:

- 「適用プロセスで処理できるメッセージのタイプ」

適用されるデータ型

DML変更で生成される行LCRを表に適用するとき、適用プロセスは、次のデータ型の列に変更を適用します。

- VARCHAR2

- NVARCHAR2

- NUMBER

- FLOAT

- LONG

- DATE

- BINARY_FLOAT

- BINARY_DOUBLE

- TIMESTAMP

- TIMESTAMP WITH TIME ZONE

- TIMESTAMP WITH LOCAL TIME ZONE

- INTERVAL YEAR TO MONTH

- INTERVAL DAY TO SECOND

- RAW

- LONG RAW

- CHAR

- NCHAR

- BASICFILEまたはSECUREFILE記憶域を持つCLOB

- BASICFILEまたはSECUREFILE記憶域を持つNCLOB

- BASICFILEまたはSECUREFILE記憶域を持つBLOB

- UROWID

- CLOB、オブジェクト・リレーショナルまたはバイナリXMLとして格納されているXMLType

注意:
Oracle Streams取得プロセスは、CLOBとして格納されているXMLType列への変更しか取得できません。ただし、適用プロセスは、このような取得LCRを、CLOB、オブジェクト・リレーショナルまたはバイナリXMLとして格納されているXMLType列に適用することはできます。

関連項目:

- 「適用プロセスと互換性のないデータベース・オブジェクトおよび列の表示」

- 「適用プロセスではサポートされていないデータ型」

- 第5章「Oracle Streamsでのルールの使用方法」

- 「取得プロセスによって取得されるデータ型」

- データ型の詳細は、『Oracle Database SQL言語リファレンス』を参照

適用時の自動データ型変換

行論理変更レコード(行LCR)の列のデータ型と表の対応する列のデータ型が一致しない場合、適用プロセスによって、適用時に自動的に特定のデータ型が変換されます。

表4-4に、適用時に自動的に変換されるデータ型の組合せを示します。

表4-4 適用時に自動的に変換されるデータ型の組合せ

データ型

CHARへ

NCHARへ

VARCHAR2へ

NVARCHAR2へ

CLOBへ

BLOBへ

DATEへ

TIMESTAMPへ

CHARから

適用不可

はい

はい

はい

はい

いいえ

いいえ

いいえ

NCHARから

はい

適用不可

はい

はい

はい

いいえ

いいえ

いいえ

VARCHAR2から

はい

はい

適用不可

はい

はい

いいえ

いいえ

いいえ

NVARCHAR2から

はい

はい

はい

適用不可

はい

いいえ

いいえ

いいえ

NUMBERから

はい

はい

はい

はい

いいえ

いいえ

いいえ

いいえ

LONGから

いいえ

いいえ

いいえ

いいえ

はい

いいえ

いいえ

いいえ

LONG RAWから

いいえ

いいえ

いいえ

いいえ

いいえ

はい

はい

いいえ

RAWから

いいえ

いいえ

いいえ

いいえ

いいえ

はい

はい

いいえ

DATEから

いいえ

いいえ

いいえ

いいえ

いいえ

いいえ

適用不可

はい

TIMESTAMPから

いいえ

いいえ

いいえ

いいえ

いいえ

いいえ

はい

適用不可

表4-4の組合せで「はい」が指定されている場合、適用プロセスはデータ型の組合せに対して自動的にデータ型変換を実行します。表4-4の組合せで「いいえ」が指定されている場合、適用プロセスはデータ型の組合せに対してデータ型変換を実行しません。たとえば、適用プロセスは自動的にCHARをNCHARに変換しますが、CHARをBLOBには変換しません。

また、対応する表の列が行LCR列から変換した文字列を保持できるほど十分に大きくない場合は、適用プロセスでエラーが発生します。

次の各項では、適用時の自動データ型変換について詳しく説明します。

- 適用時の文字データ型の自動トリミング

- 自動変換とLOBデータ型

注意:
自動データ型変換を実行するには、適用プロセスはOracle Database 11g リリース1(11.1.0.7)以上に含まれている必要があります。ただし、以前のOracle Databaseリリースで取得または作成された行LCRの列は適用プロセスによって変換できます。

関連項目:
データ型の詳細は、『Oracle Database SQL言語リファレンス』を参照

適用時の文字データ型の自動トリミング

rtrim_on_implicit_conversion適用プロセス・パラメータ では、適用プロセスがCHARまたはNCHARをVARCHAR2、NVARCHAR2またはCLOBに変換する場合にデータをトリミングするかどうかを決定します。このパラメータをYに設定すると、適用プロセスはデータ型の変換時に列の右端から埋め込まれている空白を自動的に削除します。このパラメータをNに設定すると、適用プロセスはデータ型の変換時に埋め込まれている空白を保持します。

次に例を示します。

- 行LCRでは、CHAR(10)列に「abc」が格納されています。

- 行LCRの対応する表の列はNVARCHAR2(10)です。

rtrim_on_implicit_conversion適用プロセス・パラメータをYに設定すると、適用プロセスは表の列に「abc」を挿入し、これらの文字の後に続く埋込みを削除します。rtrim_on_implicit_conversion適用プロセス・パラメータをNに設定すると、適用プロセスは表の列に「abc」を挿入し、列の残りの領域を空白で埋めます。

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

自動変換とLOBデータ型

プロシージャDMLハンドラとエラー・ハンドラでは、LONGからCLOBまたはLONG RAWからBLOBに変換されたデータにLOBアセンブリを使用できます。

関連項目:
『Oracle Streamsレプリケーション管理者ガイド』

SQL生成

SQL生成とは、行論理変更レコード(行LCR)内にカプセル化された変更を実行するのに必要なSQL文を生成する機能のことです。適用プロセスで、行LCRに含まれる挿入、更新または削除の各操作を実行するのに必要なSQL文を生成できます。

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

- SQL生成を実行するためのインタフェース

- SQL生成のフォーマット

- SQL生成およびデータ型

- SQL生成およびキャラクタ・セット

- 生成されたSQL文の例

注意:
この項では、PL/SQLインタフェースを使用したSQL生成の使用について説明します。XStreamインタフェースを使用してSQL生成を使用することもできます。

関連項目:

- SQL生成を使用するプロシージャDMLハンドラの例は、「プロシージャDMLハンドラの作成」を参照

- XStreamでのSQL生成の使用の詳細は、『Oracle Database XStreamガイド』を参照

SQL生成を実行するためのインタフェース

行LCRに対してGET_ROW_TEXTおよびGET_WHERE_CLAUSEメンバー・プロシージャを使用して、SQL生成を実行できます。PL/SQLインタフェースを使用すると、CLOBデータ型のSQLが生成されます。

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

SQL生成のフォーマット

SQL文は、インライン値またはバインド変数の2つのフォーマットのいずれかで生成できます。返されたSQL文が比較的小さい場合は、インライン値を使用します。SQL文が大きい場合は、バインド変数を使用します。この場合、バインド変数は、古い列値と新しい列値の両方を指すポインタを含む個別のリストで渡されます。

各インタフェースでのバインド変数の使用の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のGET_ROW_TEXTおよびGET_WHERE_CLAUSEの各行LCRメンバー・プロシージャについての説明を参照してください。

注意:
インライン値で生成されたSQL文の場合は、SQLインジェクションが発生する可能性があります。SQLインジェクションとは、SQL文内のクライアント提供データを使用するアプリケーションを不正に利用する手法であり、これにより機密データを表示または操作するためにデータベースに不正にアクセスできるようになります。生成されたSQL文を実行する予定の場合は、バインド変数を使用することを強くお薦めします。SQLインジェクションの詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

SQL生成およびデータ型

SQL生成では、次のデータ型がサポートされています。

- VARCHAR2

- NVARCHAR2

- NUMBER

- FLOAT

- DATE

- BINARY_FLOAT

- BINARY_DOUBLE

- LONG

- TIMESTAMP

- TIMESTAMP WITH TIME ZONE

- TIMESTAMP WITH LOCAL TIME ZONE

- INTERVAL YEAR TO MONTH

- INTERVAL DAY TO SECOND

- RAW

- LONG RAW

- CHAR

- NCHAR

- BASICFILE記憶域を持つCLOB

- BASICFILE記憶域を持つNCLOB

- BASICFILE記憶域を持つBLOB

- CLOBとして格納されているXMLType

SQL生成および自動データ型変換

適用プロセスによって暗黙的データ型変換が実行され(可能な場合)、生成されたSQLはANSI規格に従います(可能な場合)。自動データ型変換では、次の点を考慮する必要があります。

- NULLは"NULL"として指定します。

- データ型CHAR、VARCHAR2、NVARCHAR2、NCHAR、CLOBおよびNCLOBでは、一重引用符は二重引用符に変換されます(インライン値の場合)。

- LONGデータはCLOBデータに変換されます。

- LONG RAWデータはBLOBデータに変換されます。

SQL生成とLOB、LONG、LONG RAWおよびXMLTypeの各データ型

LOB列に対するINSERTおよびUPDATE操作では、適用プロセスにより、LOBアセンブリを使用してLOBチャンクが自動的にアセンブルされます。これらの操作の場合、生成されたSQLにはNULL以外の空の値が含まれます。チャンク化された列の実際の値は、後続のLCRに到達します。チャンクごとに、適切な列に対して適切なSQL操作を実行する必要があります。

同様に、LONG、LONG RAWおよびXMLTypeの各データ型に対して、適用プロセスによりNULL以外の空の値が生成され、列の実際の値が後続のLCRのチャンクに到達します。チャンクごとに、適切な列に対して適切なSQL操作を実行する必要があります。

生成されたSQLのインライン・バージョンでは、LOB、LONG、LONG RAWおよびXMLTypeの各データ型の列について、挿入と更新に対して次のSQLが生成されます。

- CLOB、NCLOBおよびLONGの各データ型の列の場合:

EMPTY_CLOB()

- BLOBおよびLONG RAWの各データ型の列の場合:

EMPTY_BLOB()

- XMLType列の場合:

XMLTYPE.CREATEXML('xml /')

ここで、xml /とはXMLチャンクのことです。

DML文を含むLCRが到達してから、これらの変更に対するデータが個別のチャンクに到達します。このような変更に対してWHERE句を生成し、生成したWHERE句を使用してチャンクに含まれる変更対象の行を識別できます。たとえば、PL/SQLでは、GET_WHERE_CLAUSE行LCRメンバー・プロシージャを使用して、行変更に対してWHERE句を生成できます。

INSERTおよびUPDATE操作の場合は、生成されたWHERE句によって挿入または更新後の行が識別されます。たとえば、hr.departments表に対する次の更新の場合を考えます。

UPDATE hr.departments SET department_name='Management'
WHERE department_name='Administration';

この変更に対して生成されたWHERE句は、次のとおりです。

WHERE "DEPARTMENT_NAME"='Management'

DBMS_LOBパッケージのサブプログラムによって実行されるピース単位のLOB操作(WRITE、TRIMおよびERASEの各プロシージャなど)の場合、生成されたSQLにはSELECT FOR UPDATE文が含まれます。

たとえば、clob_colに対するLOB_WRITE操作では、次のようなSQLが生成されます。

SELECT "CLOB_COL" FROM "HR"."LOB_TAB" WHERE "N1"=2 FOR UPDATE

選択されるclob_colは定義されている必要があります。LOBロケータを使用して、行LCRに続くLOBチャンクでピース単位のLOB操作を実行できます。

関連項目:

- 「LOB列のある表に対して生成されたSQL文の例」

- LOBアセンブリの詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

SQL生成およびキャラクタ・セット

LCRメソッドを使用する場合、SQLはデータベース・キャラクタ・セットで生成されます。INSERT、UPDATE、INTOなどのSQLキーワードは、キャラクタ・セットに応じて変更されることはありません。

関連項目:

- JDBCでのデータ変換の詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照

- SQLキーワードの詳細は、『Oracle Database SQL言語リファレンス』を参照

生成されたSQL文の例

この項では、生成されたSQL文の例を示します。

- hr.employees表に対して生成されたSQL文の例

- LOB列のある表に対して生成されたSQL文の例

hr.employees表に対して生成されたSQL文の例

この項では、hr.employees表に行われた変更に対して適用プロセスによって生成されたSQL文の例を示します。

この項では、次の例を示します。

- 例4-1「生成された挿入」

- 例4-2「生成された更新」

- 例4-3「生成された削除」

注意:
生成されたSQLは単一行であり、フォーマットされていません。

例4-1 生成された挿入

次の挿入が実行されるとします。

INSERT INTO hr.employees (employee_id,
last_name,
email,
hire_date,
job_id,
salary,
commission_pct)
VALUES (207,
'Gregory',
'pgregory@example.com',
SYSDATE,
'PU_CLERK',
9000,
NULL);

インライン値を使用して生成されたSQLは、次のとおりです。

INSERT INTO "HR"."EMPLOYEES"("EMPLOYEE_ID","FIRST_NAME","LAST_NAME",
"EMAIL","PHONE_NUMBER","HIRE_DATE","JOB_ID","SALARY","COMMISSION_PCT",
"MANAGER_ID","DEPARTMENT_ID" ) VALUES ( 207, NULL,'Gregory',
'pgregory@example.com', NULL , TO_DATE(' 2009-04-15','syyyy-mm-dd'),
'PU_CLERK',9000, NULL , NULL , NULL )

バインド変数を使用して生成されたSQLは、次のとおりです。

INSERT INTO "HR"."EMPLOYEES"("EMPLOYEE_ID","FIRST_NAME","LAST_NAME",
"EMAIL","PHONE_NUMBER","HIRE_DATE","JOB_ID","SALARY",
"COMMISSION_PCT","MANAGER_ID","DEPARTMENT_ID" ) VALUES ( :1   ,:2   ,:3
,:4   ,:5   ,:6   ,:7   ,:8   ,:9   ,:10  ,:11  )

例4-2 生成された更新

次の更新が実行されるとします。

UPDATE hr.employees SET salary=10000 WHERE employee_id=207;

インライン値を使用して生成されたSQLは、次のとおりです。

UPDATE "HR"."EMPLOYEES" SET "SALARY"=10000 WHERE "EMPLOYEE_ID"=207
AND "SALARY"=9000

バインド変数を使用して生成されたSQLは、次のとおりです。

UPDATE "HR"."EMPLOYEES" SET "SALARY"=:1    WHERE "EMPLOYEE_ID"=:2
AND "SALARY"=:3

例4-3 生成された削除

次の削除が実行されるとします。

DELETE FROM hr.employees WHERE employee_id=207;

インライン値を使用して生成されたSQLは、次のとおりです。

DELETE  FROM "HR"."EMPLOYEES" WHERE "EMPLOYEE_ID"=207 AND "FIRST_NAME" IS NULL
AND "LAST_NAME"='Gregory' AND "EMAIL"='pgregory@example.com' AND
"PHONE_NUMBER" IS NULL  AND "HIRE_DATE"= TO_DATE(' 2009-04-15','syyyy-mm-dd')
AND "JOB_ID"='PU_CLERK' AND "SALARY"=10000 AND "COMMISSION_PCT" IS NULL
AND "MANAGER_ID" IS NULL  AND "DEPARTMENT_ID" IS NULL

バインド変数を使用して生成されたSQLは、次のとおりです。

DELETE  FROM "HR"."EMPLOYEES" WHERE "EMPLOYEE_ID"=:1    AND "FIRST_NAME"=:2
AND "LAST_NAME"=:3    AND "EMAIL"=:4    AND "PHONE_NUMBER"=:5    AND
"HIRE_DATE"=:6    AND "JOB_ID"=:7    AND "SALARY"=:8    AND
"COMMISSION_PCT"=:9   AND "MANAGER_ID"=:10   AND "DEPARTMENT_ID"=:11

LOB列のある表に対して生成されたSQL文の例

この項では、次の表に行われた変更に対して適用プロセスによって生成されたSQL文の例を示します。

CREATE TABLE hr.lob_tab(
n1        number primary key,
clob_col  CLOB,
nclob_col NCLOB,
blob_col  BLOB);

この項では、次の例を示します。

- 例4-4「LOB列のある表に対して生成された挿入」

- 例4-5「LOB列のある表に対して生成された更新」

- 例4-6「LOB列のある表に対して生成された削除」

注意:
生成されたSQLは単一行であり、フォーマットされていません。

例4-4 LOB列のある表に対して生成された挿入

次の挿入が実行されるとします。

INSERT INTO hr.lob_tab VALUES (2, 'test insert', NULL, NULL);

インライン値を使用して生成されたSQLは、次のとおりです。

INSERT INTO "HR"."LOB_TAB"("N1","BLOB_COL","CLOB_COL","NCLOB_COL" )
VALUES ( 2,, EMPTY_CLOB() ,)

バインド変数を使用して生成されたSQLは、次のとおりです。

INSERT INTO "HR"."LOB_TAB"("N1","BLOB_COL","CLOB_COL","NCLOB_COL" )
VALUES ( :1   ,:2   ,:3   ,:4   )

GET_WHERE_CLAUSEメンバー・プロシージャを使用すると、この挿入に対して次のWHERE句が生成されます。

- インラインの場合:

WHERE "N1"=2

- バインド変数の場合:

WHERE "N1"=:1

WHERE句を使用して、後続のチャンクがLOB列の変更に到達するときに挿入された行を識別できます。

例4-5 LOB列のある表に対して生成された更新

次の更新が実行されるとします。

UPDATE hr.lob_tab SET clob_col='test update' WHERE n1=2;

インライン値を使用して生成されたSQLは、次のとおりです。

UPDATE "HR"."LOB_TAB" SET "CLOB_COL"= EMPTY_CLOB()  WHERE "N1"=2

バインド変数を使用して生成されたSQLは、次のとおりです。

UPDATE "HR"."LOB_TAB" SET "CLOB_COL"=:1    WHERE "N1"=:2

例4-6 LOB列のある表に対して生成された削除

次の削除が実行されるとします。

DELETE FROM hr.lob_tab WHERE n1=2;

インライン値を使用して生成されたSQLは、次のとおりです。

DELETE  FROM "HR"."LOB_TAB" WHERE "N1"=2

バインド変数を使用して生成されたSQLは、次のとおりです。

DELETE  FROM "HR"."LOB_TAB" WHERE "N1"=:1

Oracle Streamsの適用プロセスおよびRESTRICTED SESSION

システム起動時にSTARTUP RESTRICT文を発行して制限付きセッションを有効にすると、データベースの停止時に適用プロセスが実行中であった場合でも、適用プロセスは起動されません。制限付きセッションを無効にすると、停止されていない各適用プロセスが起動されます。

SQL文ALTER SYSTEM ENABLE RESTRICTED SESSIONによって実行中のデータベースで制限付きセッションを有効にしても、実行中の適用プロセスには影響がありません。これらの適用プロセスは引き続き実行され、メッセージの適用が行われます。停止した適用プロセスを制限付きセッションで起動しても、この適用プロセスは、制限付きセッションを無効にするまで実際には起動されません。

適用プロセスのサブコンポーネント

適用プロセスのサブコンポーネントは、次のとおりです。

- メッセージをデキューするリーダー・サーバー。リーダー・サーバーは、論理変更レコード(LCR)間の依存性を計算してメッセージをトランザクションにアセンブルするプロセスです。その後、リーダー・サーバーは、アセンブルしたトランザクションをコーディネータ・プロセスに返します。

- リーダー・サーバーからトランザクションを取得して適用サーバーに渡すコーディネータ・プロセス。コーディネータ・プロセス名はAPnn(nnは文字および数字)です。コーディネータ・プロセスはOracleバックグラウンド・プロセスです。

- LCRをDML文またはDDL文としてデータベース・オブジェクトに適用するか、LCRを適切な適用ハンドラに渡す1つ以上の適用サーバー。LCR以外のメッセージの場合、適用サーバーはメッセージをメッセージ・ハンドラに渡します。適用サーバーは、DBMS_APPLY_ADM.SET_ENQUEUE_DESTINATIONプロシージャで指定されたキューの永続キュー部分にLCRメッセージとLCR以外のメッセージをエンキューすることもできます。各適用サーバーはプロセスです。適用サーバーにエラーが発生すると、ユーザー指定の競合ハンドラまたはエラー・ハンドラを使用してエラーを解決しようとします。エラーを解決できない場合、適用サーバーはトランザクションをロールバックし、すべてのメッセージを含めてトランザクション全体をエラー・キューに置きます。
適用サーバーが完了したトランザクションをコミットする時点で、このトランザクションは適用済になっています。適用サーバーがトランザクションをエラー・キューに置いてコミットした場合も、このトランザクションは適用済になっています。

リーダー・サーバー名および適用サーバー・プロセス名はASnn(nnは文字および数字)です。適用サーバーで処理されているトランザクションに、適用されているかどうかが不明な別のトランザクションとの依存関係がある場合、適用サーバーはコーディネータ・プロセスに接続して指示を待ちます。コーディネータ・プロセスは、トランザクションが正しい順序で適用およびコミットされていることを確認するため、すべての適用サーバーを監視します。

次の各項では、適用プロセスの各サブコンポーネントの考えられる状態について説明します。

- リーダー・サーバーの状態

- コーディネータ・プロセスの状態

- 適用サーバーの状態

関連項目:

- 「適用プロセスおよび依存性」

リーダー・サーバーの状態

リーダー・サーバーの状態は、リーダー・サーバーが現在行っている処理を示します。適用プロセスのリーダー・サーバーの状態は、V$STREAMS_APPLY_READER動的パフォーマンス・ビューを問い合せることによって表示できます。リーダー・サーバーの状態は次のいずれかになります。

- INITIALIZING: 起動中。

- IDLE: 実行中の作業なし。

- DEQUEUE MESSAGES: 適用プロセスのキューからメッセージをデキュー中

- SCHEDULE MESSAGES: メッセージ間の依存性を計算して、メッセージをトランザクションにアセンブル中

- SPILLING: 適用されていないメッセージがメモリーからハード・ディスクにオーバーフロー中

- PAUSED - WAITING FOR DDL TO COMPLETE - DDL LCRが適用されるのを待つために一時停止中

関連項目:

- 適用プロセスのリーダー・サーバーの状態を表示する問合せの詳細は、「各適用プロセスのリーダー・サーバーに関する情報の表示」を参照

コーディネータ・プロセスの状態

コーディネータ・プロセスの状態は、コーディネータ・プロセスが現在行っている処理を示します。コーディネータ・プロセスの状態は、V$STREAMS_APPLY_COORDINATOR動的パフォーマンス・ビューを問い合せることによって表示できます。コーディネータ・プロセスの状態は次のいずれかになります。

- INITIALIZING: 起動中。

- IDLE: 実行中の作業なし。

- APPLYING: 適用サーバーにトランザクションを引渡し中

- SHUTTING DOWN CLEANLY: 停止中(エラーなし)

- ABORTING: 適用エラーのために停止中

関連項目:

- コーディネータ・プロセスの状態を表示する問合せの詳細は、「各コーディネータ・プロセスに関する一般情報の表示」を参照

適用サーバーの状態

適用サーバーの状態は、適用サーバーが現在行っている処理を示します。適用プロセスの各適用サーバーの状態は、V$STREAMS_APPLY_SERVER動的パフォーマンス・ビューを問い合せることによって表示できます。適用サーバーの状態は次のいずれかになります。

- INITIALIZING: 起動中。

- IDLE: 実行中の作業なし。

- RECORD LOW-WATERMARK: 適用の進捗に関する情報をメンテナンスする管理操作を実行中。この情報は、ALL_APPLY_PROGRESSおよびDBA_APPLY_PROGRESSデータ・ディクショナリ・ビューで使用されます。

- ADD PARTITION: 進行中のトランザクションに関する情報の記録に使用されるパーティションを追加する管理操作を実行中。

- DROP PARTITION: 進行中のトランザクションに関する情報の記録に使用されたパーティションを削除する管理操作を実行中。

- EXECUTE TRANSACTION: トランザクションを適用中。

- WAIT COMMIT: コミットSCNが小さい、他のすべてのトランザクションが適用されるまで、トランザクションのコミットを待機中。commit_serialization適用プロセス・パラメータがDEPENDENT_TRANSACTIONS以外の値に設定され、parallelism適用プロセス・パラメータが1より大きい値に設定された場合にのみ、この状態は発生します。

- WAIT DEPENDENCY: 依存関係にある別のトランザクションが適用されるまで、トランザクション内のLCRの適用を待機中。PARALLELISM適用プロセス・パラメータが1より大きい値に設定されている場合のみ、この状態は発生します。

- WAIT FOR CLIENT: XStream Inクライアント・アプリケーションが論理変更レコード(LCR)をさらにリクエストしてくるのを待機中。

- WAIT FOR NEXT CHUNK: 大規模なトランザクションの次のLCRのセットを待機中。

- ROLLBACK TRANSACTION: トランザクションのロールバック中。

- TRANSACTION CLEANUP: 適用済トランザクションのクリーンアップ中(適用プロセスのキューからのLCRの削除も含む)。

関連項目:

- 各適用プロセスの適用サーバーの状態を表示する問合せの詳細は、「各適用プロセスの適用サーバーに関する情報の表示」を参照

- 適用プロセス・パラメータの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

- 『Oracle Database XStreamガイド』

適用ユーザー

メッセージは、適用プロセスの適用ユーザーのセキュリティ・ドメインで適用されます。適用ユーザーは、適用プロセスのルール・セットを満たすすべてのメッセージをデキューします。適用ユーザーは、メッセージをデータベース・オブジェクトに直接適用できます。また、適用ユーザーは、これらのルール・セットのルールで指定されたすべてのカスタム・ルールベースの変換を実行します。ユーザー定義の適用ハンドラも実行します。

適用ユーザーは、次の権限を含む、変更の適用に必要な権限を持っている必要があります。

- 適用プロセスで使用するルール・セットのEXECUTE権限

- ポジティブ・ルール・セットのルールに指定されているすべてのカスタム・ルールベースの変換ファンクションのEXECUTE権限

- すべての適用ハンドラのEXECUTE権限

- 適用プロセスのキューからメッセージをデキューする権限

適用プロセスは1ユーザーのみに関連付けることができますが、1ユーザーは複数の適用プロセスと関連付けることができます。

関連項目:

- 必要な権限の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

適用プロセス・パラメータ

適用プロセスの作成後、適用プロセスは、最初の起動前に環境に合わせて適用プロセス・パラメータを設定できるように無効になっています。適用プロセス・パラメータによって、適用プロセスの動作が制御されます。たとえば、parallelism適用プロセス・パラメータによって、トランザクションを同時に適用できる適用サーバーの数が指定され、time_limit 適用プロセス・パラメータによって、適用プロセスが自動的に停止されるまでの実行時間が指定されます。適用プロセス・パラメータを設定した後、適用プロセスを起動できます。

関連項目:

- 「適用プロセス・パラメータの設定」

- すべての適用プロセス・パラメータの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

データベースの再起動時における適用プロセスの永続的状態

適用プロセスを実行しているデータベースが停止され、再起動されても、適用プロセスは永続的状態を保ちます。たとえば、データベースの停止時に適用プロセスを有効にすると、その適用プロセスはデータベースの再起動時に自動的に開始されます。同様に、データベースの停止時に適用プロセスを無効にするか、または強制終了させると、その適用プロセスはデータベースが再起動されても開始されず、無効または強制終了の状態のままとなります。

エラー・キュー

エラー・キューには、1つのデータベースの現在の適用エラーがすべて格納されます。データベースに複数の適用プロセスが存在する場合、エラー・キューには各適用プロセスの適用エラーが格納されます。適用エラーに関する情報を表示するには、DBA_APPLY_ERRORデータ・ディクショナリ・ビューを問い合せるか、Enterprise Managerを使用します。

エラー・キューには、データベースで実行中の適用プロセスによって正常に適用できなかったトランザクションに関する情報が格納されます。1つのトランザクションには、多数のメッセージが含まれる可能性があります。適用中に未処理エラーが発生すると、適用プロセスのルール・セットを満たすトランザクション内のすべてのメッセージがエラー・キューに自動的に移されます。

エラーの原因となった状態を修正し、エラー・トランザクションを再実行できます。たとえば、表の1行を変更して、エラーの原因となった状態を修正できる場合もあります。

エラーの原因となった条件を訂正した後、EXECUTE_ERRORまたはEXECUTE_ALL_ERRORSプロシージャを使用してエラー・キュー内のトランザクションを再実行するか、またはDELETE_ERRORやDELETE_ALL_ERRORSプロシージャを使用してエラー・キューからトランザクションを削除できます。これらのプロシージャは、DBMS_APPLY_ADMパッケージに含まれています。

エラー・キュー内のトランザクションを再実行する場合は、そのトランザクションを実行するユーザーとして、最初にエラー・キューにエラーを置いたユーザーまたはトランザクションを再実行するユーザーを指定できます。また、エラー・キュー内のトランザクションを再実行する場合は、適用プロセスの現行のOracle Streamsタグが使用されます。

再実行のトランザクションでは、適用ハンドラと競合解決ハンドラを関連付けて使用できます。たとえば、エラーの解決策として、エラー・キュー内の行LCRが実行前に変更されるようにするには、エラーの原因となった行LCRをエラー・キュー内で処理するようにプロシージャDMLハンドラを構成します。つまり、DMLハンドラに行LCRを修正させることで、同じエラーの繰返しを回避できます。行LCRを含んだエラーが再実行されると、その行LCRはDMLハンドラに渡されます。その後、たとえば文DMLハンドラであれば、行LCRが示す挿入とは異なる値を挿入することができますし、プロシージャDMLハンドラを使用すれば、行LCR内の1つ以上の列を修正することによって、同じエラーの繰返しを回避することができます。

エラー・キューには、ローカルの宛先データベースのみで発生したエラーに関する情報が格納されます。Oracle Streams環境の他のデータベースで実行中の適用プロセスに関するエラー情報は格納されません。

エラー・キューは、データベースの例外キューを使用します。DBMS_STREAMS_ADMパッケージのSET_UP_QUEUEプロシージャを使用してANYDATAキューを作成する際にキューのキュー表が存在しない場合は、プロシージャによって作成されます。キュー表が作成されると、キュー表の例外キューが自動的に作成されます。1つのキュー表を複数のキューで使用できます。また、各キュー表には1つの例外キューがあります。したがって、1つの例外キューで、複数のキューおよび複数の適用プロセスのエラーを格納できます。

例外キューには自身のキュー表に対する適用エラーのみが格納されますが、Oracle Streamsエラー・キューにはデータベースの各例外キュー内のすべての適用エラーに関する情報が格納されます。Oracle Streams適用エラーを管理するには、DBMS_APPLY_ADMパッケージ内のプロシージャを使用する必要があります。適用エラーは例外キューから直接デキューしないでください。

注意:
メッセージ・クライアントは、メッセージのデキュー時にエラーが発生すると、自身のキュー表に関連付けられている例外キューにこれらのメッセージを移動します。ただし、メッセージ・クライアントのエラーに関する情報はエラー・キューには格納されません。適用プロセスのエラーに関する情報のみがエラー・キューに格納されます。

関連項目:

- 「適用エラーの管理」

- 「適用エラーのチェック」

- 「適用エラーの詳細情報の表示」

- 「エラー・ハンドラの管理」

- 第5章「Oracle Streamsでのルールの使用方法」

- DBMS_APPLY_ADMパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

- DBA_APPLY_ERRORデータ・ディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照

メッセージ・クライアントによる明示的コンシューム

メッセージ・クライアントは、アプリケーションまたはユーザーに起動されたときに永続キューからメッセージをデキューします。ルールを使用して、メッセージ・クライアントによってキューからデキューされるメッセージを指定できます。このようなメッセージは、永続LCRまたは永続ユーザー・メッセージです。

メッセージ・クライアントを作成するには、DBMS_STREAMS_ADMパッケージの次のいずれかのプロシージャを実行するときにstreams_typeパラメータにdequeueを指定します。

- ADD_MESSAGE_RULE

- ADD_TABLE_RULES

- ADD_SUBSET_RULES

- ADD_SCHEMA_RULES

- ADD_GLOBAL_RULES

メッセージ・クライアントを作成するとき、メッセージ・クライアントの名前と、メッセージ・クライアントがメッセージをデキューするANYDATAキューを指定します。これらのプロシージャを使用して、メッセージ・クライアントのポジティブ・ルール・セットまたはネガティブ・ルール・セットにルールを追加することもできます。ルールごとにメッセージ・タイプを指定すると、1つのメッセージ・クライアントで様々なタイプのメッセージをデキューできます。

メッセージ・クライアントを作成するユーザーは、そのメッセージ・クライアントを使用してキューからデキューする権限を付与されます。このユーザーは、メッセージ・クライアント・ユーザーです。メッセージ・クライアント・ユーザーは、メッセージ・クライアントのルール・セットを満たすメッセージをデキューできます。1つのメッセージ・クライアントを関連付けることができるのは1ユーザーのみですが、1人のユーザーには多数のメッセージ・クライアントを関連付けることができます。

図4-2に、メッセージをデキューするメッセージ・クライアントを示します。

図4-2 メッセージ・クライアント

関連項目:

- 第5章「Oracle Streamsでのルールの使用方法」

- 「メッセージ・クライアントの制限事項」

- メッセージングに関する基本情報は、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照

- DBMS_AQパッケージの詳細は、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドを参照してください。

手動デキューによる明示的コンシューム

手動デキューによる明示的コンシュームでは、アプリケーションはバッファLCR、永続LCR、バッファ・ユーザー・メッセージまたは永続ユーザー・メッセージを手動で明示的にデキューして処理します。メッセージがデキューされるキューは、ANYDATAキューまたは型付きキューです。DBMS_STREAMS_MESSAGINGパッケージまたはDBMS_AQパッケージを使用してメッセージをデキューできます。

Oracle Streamsアドバンスト・キューイングでは次のデキュー機能が使用できます。

- バッファ・キューまたは永続キューからのデキュー

- 同時デキュー

- デキュー方法

- デキュー・モード

- メッセージ配列のデキュー

- メッセージの状態

- デキュー時のメッセージの操作

- メッセージの待機

- 遅延時の再試行

- トランザクション保護(オプション)

- 例外キュー

関連項目:

- Oracle Database 2日でデータ・レプリケーションおよび統合ガイド

- これらの機能およびOracle Streamsアドバンスト・キューイングで利用できるその他の機能の詳細は、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドを参照してください。

- 「バッファ・メッセージ機能の制限」

5 Oracle Streamsでのルールの使用方法

次の各項では、Oracle Streamsでのルールの使用方法について説明します。

- Oracle Streamsでのルールの使用方法の概要

- ルール・セットおよびメッセージのルール評価

- システム作成ルール

関連項目:

- 第11章「ルールの高度な概念」

- 第18章「ルールの管理」

- 第27章「ルールの監視」

- 第34章「ルールおよびルールベースの変換のトラブルシューティング」

Oracle Streamsでのルールの使用方法の概要

Oracle Streamsでは、次の各メカニズムをOracle Streamsクライアントと呼びます。これは、各メカニズムがルール・エンジンのクライアントであるためです(メカニズムが1つ以上のルール・セットと関連付けられている場合)。

- 取得プロセス

- 同期取得

- 伝播

- 適用プロセス

- メッセージ・クライアント

同期取得を除き、これらの各クライアントはポジティブ・ルール・セットとネガティブ・ルール・セットという最大2つのルール・セットに関連付けることができます。同期取得を関連付けることができるのは1つのポジティブ・ルール・セットのみです。ネガティブ・ルール・セットに関連付けることはできません。

1つのルール・セットは、同一データベース内の複数の取得プロセス、同期取得、伝播、適用プロセスおよびメッセージ・クライアントで使用できます。また、1つのルール・セットを、あるOracle Streamsクライアントに対してはポジティブ・ルール・セット、別のOracle Streamsクライアントに対してはネガティブ・ルール・セットとして使用できます。

図5-1は、1つのルール・セットをルール・エンジンの複数のクライアントがどのように使用できるかを示しています。

図5-1 ルール・エンジンの複数クライアントで使用できる1つのルール・セット

Oracle Streamsクライアントがタスクを実行するのは、メッセージがそのクライアントのルール・セットを満たす場合です。通常、メッセージがOracle Streamsクライアントのルール・セットを満たすのは、メッセージについてネガティブ・ルール・セットのどのルールもTRUEと評価されず、ポジティブ・ルール・セットの少なくとも1つのルールがTRUEと評価された場合です。

「ルール・セットおよびメッセージのルール評価」では、メッセージがどのようにOracle Streamsクライアントのルール・セットを満たすかに関する詳細情報を示します。これには、1つ以上のルール・セットが指定されていない場合のOracle Streamsクライアントの動作に関する情報が含まれます。

Oracle Streamsでは、次のようにルール・セットを使用します。

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

- 同期取得が取得する変更を指定します。つまり、DML変更が同期取得のルール・セットを満たす場合、同期取得は変更がコミットされた直後に変更を取得します。表に対して行われたDML変更が同期取得のルール・セットを満たさない場合、同期取得は変更を取得しません。

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

- 適用プロセスがデキューまたは廃棄するメッセージを指定します。キュー内のメッセージが適用プロセスのルール・セットを満たしている場合、適用プロセスはそのメッセージをデキューして処理します。キュー内のメッセージが適用プロセスのルール・セットを満たしていない場合、適用プロセスはメッセージを廃棄します。

- メッセージ・クライアントがデキューまたは廃棄する永続LCRまたは永続ユーザー・メッセージを指定します。つまり、永続キュー内のメッセージがメッセージ・クライアントのルール・セットの条件を満たしている場合、メッセージ・クライアントを使用しているユーザーまたはアプリケーションはそのメッセージをデキューします。永続キュー内のメッセージがメッセージ・クライアントのルール・セットの条件を満たしていない場合、メッセージ・クライアントを使用しているユーザーまたはアプリケーションはそのメッセージを廃棄します。

伝播の場合、ルール・セットで検証されるメッセージは、取得LCR、永続LCR、バッファLCR、永続ユーザー・メッセージまたはバッファ・ユーザー・メッセージを含むすべてのタイプのメッセージです。

適用プロセスの場合、ルール・セットで検証されるメッセージは、取得LCR、永続LCRまたは永続ユーザー・メッセージです。

クライアントに関連付けられているポジティブ・ルール・セットに競合するルールが含まれる場合、どちらかのルールがTRUEと評価されると、そのクライアントはタスクを実行します。たとえば、取得プロセスのポジティブ・ルール・セットに、hr.employees表に対するデータ操作言語(DML)変更の結果を取得するように指示する1つのルールが含まれているときは、同じルール・セットにhr.employees表に対するDML変更の結果を取得しないように指示する別のルールが含まれていても、取得プロセスはこれらの変更を取得します。

同様に、クライアントに関連付けられているネガティブ・ルール・セットに競合するルールが含まれる場合、メッセージについてどちらかのルールがTRUEと評価されると、そのクライアントはメッセージを廃棄します。たとえば、取得プロセスのネガティブ・ルール・セットに、hr.departments表に対するDML変更の結果を廃棄するように指示する1つのルールが含まれているときは、同じルール・セットにhr.departments表に対するDML変更の結果を廃棄しないように指示する別のルールが含まれていても、取得プロセスはこれらの変更を廃棄します。

関連項目:

- 第2章「Oracle Streams情報取得」

- 「キュー間でのメッセージの伝播」

- 第4章「Oracle Streams情報コンシューム」

- 「メッセージ・クライアントによる明示的コンシューム」

ルール・セットおよびメッセージのルール評価

Oracle Streamsクライアントでは、ルールに基づいて次のタスクを実行します。

- 取得プロセスは、REDOログで変更を取得し、取得した変更を論理変更レコード(LCR)に変換して、これらのLCRを含むメッセージを取得プロセスのキューにエンキューします。

- 同期取得は、表に対するDML変更の結果を取得し、取得した変更を行論理変更レコード(行LCR)に変換して、これらの行LCRを含むメッセージを同期取得のキューにエンキューします。

- 伝播は、任意のタイプのメッセージをソース・キューから宛先キューに伝播します。

- 適用プロセスは、取得LCR、永続LCRまたは永続ユーザー・メッセージをそのキューからデキューし、これらのメッセージを直接適用するか、または適用ハンドラに送信します。

- メッセージ・クライアントは、永続LCRまたは永続ユーザー・メッセージをそのキューからデキューします。

これらの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クライアントは、表示されるすべてのメッセージのタスクを実行します。空のルール・セットが存在する場合とルール・セットが存在しない場合は区別されます。

取得プロセスでは、サポートされていないデータベース・オブジェクトに対する変更を取得しないように、常に、1つ以上のルール・セットを所有する必要があります。常に、伝播がソース・キュー内のすべてのメッセージを伝播する必要がある場合、または常に、適用プロセスがキュー内のすべてのメッセージをデキューする必要がある場合、伝播または適用プロセスからすべてのルール・セットを削除すると、パフォーマンスが向上する場合があります。同期取得には、ポジティブ・ルール・セットが必要です。ルール・セットがないと、同期取得を構成できません。

Oracle Streamsクライアントにポジティブ・ルール・セットのみが存在する場合

ポジティブ・ルール・セットが存在してネガティブ・ルール・セットが存在しない場合、メッセージについてポジティブ・ルール・セットのいずれかのルールがTRUEと評価されると、そのメッセージに対してOracle Streamsクライアントのタスクが実行されます。ただし、メッセージについてポジティブ・ルール・セットのすべてのルールがFALSEと評価されると、Oracle Streamsクライアントによってメッセージが破棄されます。

Oracle Streamsクライアントにネガティブ・ルール・セットのみが存在する場合

Oracle Streamsクライアントでは、ネガティブ・ルール・セットが存在してポジティブ・ルール・セットが存在しない場合、メッセージについてネガティブ・ルール・セットのいずれかのルールがTRUEと評価されると、そのメッセージは破棄されます。ただし、メッセージについてネガティブ・ルール・セットのすべてのルールがFALSEと評価されると、Oracle Streamsクライアントによってメッセージのタスクが実行されます。同期取得は、ネガティブ・ルール・セットを保持できません。

Oracle Streamsクライアントにポジティブ・ルール・セットとネガティブ・ルール・セットの両方が存在する場合

Oracle Streamsクライアントにポジティブ・ルール・セットとネガティブ・ルール・セットの両方が存在する場合は、メッセージについてネガティブ・ルール・セットが最初に評価されます。メッセージについてネガティブ・ルール・セットのいずれかのルールがTRUEと評価されると、メッセージは破棄されて、ポジティブ・ルール・セットに対する評価は行われなくなります。

ただし、メッセージについてネガティブ・ルール・セットのすべてのルールがFALSEと評価されると、メッセージがポジティブ・ルール・セットに対して評価されます。この場合の動作は、Oracle Streamsクライアントにポジティブ・ルール・セットのみが存在する場合と同じになります。つまり、メッセージについてポジティブ・ルール・セットのいずれかのルールがTRUEと評価されると、そのメッセージに対してOracle Streamsクライアントのタスクが実行されます。メッセージについてポジティブ・ルール・セットのすべてのルールがFALSEと評価されると、Oracle Streamsクライアントによってメッセージが廃棄されます。

同期取得は、ネガティブ・ルール・セットを保持できません。

Oracle Streamsクライアントに空のルール・セットが1つ以上存在する場合

Oracle Streamsクライアントに空のルール・セットが1つ以上存在する場合があります。その場合、Oracle Streamsクライアントは次のように動作します。

- Oracle Streamsクライアントにポジティブ・ルール・セットが存在せず、ネガティブ・ルール・セットが空の場合、すべてのメッセージに対してOracle Streamsクライアントのタスクが実行されます。

- Oracle Streamsクライアントにポジティブ・ルール・セットとネガティブ・ルール・セットの両方が存在し、ネガティブ・ルール・セットは空だが、ポジティブ・ルール・セットにルールが含まれている場合、ポジティブ・ルール・セットのルールに基づいてOracle Streamsクライアントのタスクが実行されます。

- Oracle Streamsクライアントに空のポジティブ・ルール・セットがある場合、ネガティブ・ルール・セットの状態にかかわりなく、Oracle Streamsクライアントによってすべてのメッセージが廃棄されます。

ルール・セットとOracle Streamsクライアントの動作のまとめ

表5-1に、前項で説明したOracle Streamsクライアントの動作のまとめを示します。

表5-1 ルール・セットとOracle Streamsクライアントの動作

ネガティブ・ルール・セット

ポジティブ・ルール・セット

Oracle Streamsクライアントの動作

なし

なし

すべてのメッセージに対してタスクが実行されます。

なし

あり(ルールを含む)

ポジティブ・ルール・セットでTRUEと評価されたメッセージに対してタスクが実行されます。

あり(ルールを含む)

なし

ネガティブ・ルール・セットでTRUEと評価されたメッセージが廃棄され、他のすべてのメッセージに対してタスクが実行されます。

あり(ルールを含む)

あり(ルールを含む)

ネガティブ・ルール・セットでTRUEと評価されたメッセージが廃棄され、ポジティブ・ルール・セットでTRUEと評価された残りのメッセージに対してタスクが実行されます。ネガティブ・ルール・セットが最初に評価されます。

あり(空)

なし

すべてのメッセージに対してタスクが実行されます。

あり(空)

あり(ルールを含む)

ポジティブ・ルール・セットでTRUEと評価されたメッセージに対してタスクが実行されます。

なし

あり(空)

すべてのメッセージが廃棄されます。

あり(空)

あり(空)

すべてのメッセージが廃棄されます。

あり(ルールを含む)

あり(空)

すべてのメッセージが廃棄されます。

システム作成ルール

Oracle Streamsクライアントがメッセージに対するタスクを実行するのは、メッセージがそのクライアントのルール・セットを満たしている場合です。システム作成ルールは、DBMS_STREAMS_ADMパッケージで作成され、粒度レベルとして表、スキーマまたはグローバルのいずれかを指定できます。このセクションでは、各レベルについて説明します。特定のタスクに複数のレベルを指定できます。たとえば、1つの適用プロセスに対して、oeスキーマの特定の表に表レベルの適用を実行し、hrスキーマ全体にスキーマ・レベルの適用を実行するように指示できます。また、1つのルールは、データ操作言語(DML)変更またはデータ定義言語(DDL)変更のいずれかの結果に関連しています。そのため、たとえば、特定の表のすべての変更に対処するには、DML変更の結果とDDL変更の結果それぞれに対応する少なくとも2つのシステム作成ルールが必要です。DML変更の結果とは、DML変更の結果として生成される行変更、または各行の変更をカプセル化するキュー内の行LCRです。

表5-2は、ルールの各レベルが各Oracle Streamsタスクについてどのような意味を持つかを示します。ネガティブ・ルール・セットがポジティブ・ルール・セットよりも前に評価されることに注意してください。

表5-2 タスクのタイプとルールのレベル

タスク

表ルール

スキーマ・ルール

グローバル・ルール

取得プロセスによる取得

ネガティブ・ルール・セットに含まれる場合、指定した表に関するREDOログ内の変更を廃棄します。

ポジティブ・ルール・セットに含まれる場合、指定した表に関するREDOログ内のすべての変更または変更のサブセットを取得し、論理変更レコード(LCR)に変換してエンキューします。

ネガティブ・ルール・セットに含まれる場合、スキーマ自体および指定したスキーマ内のデータベース・オブジェクトに関するREDOログ内の変更を廃棄します。

ポジティブ・ルール・セットに含まれる場合、スキーマ自体および指定したスキーマ内のデータベース・オブジェクトに関するREDOログ内の変更を取得し、論理変更レコード(LCR)に変換してエンキューします。

ネガティブ・ルール・セットに含まれる場合、データベース内のすべてのデータベース・オブジェクトに対する変更を廃棄します。

ポジティブ・ルール・セットに含まれる場合、データベース内のすべてのデータベース・オブジェクトに対する変更を取得し、LCRに変換してエンキューします。

同期取得による取得

ポジティブ・ルール・セットに含まれる場合、指定した表に対するすべての変更または変更のサブセットを取得し、論理変更レコード(LCR)に変換してエンキューします。

同期取得は、ネガティブ・ルール・セットを保持できません。

同期取得にはスキーマ・ルールを関連付けることができません。

同期取得にはグローバル・ルールを関連付けることができません。

伝播による伝播

ネガティブ・ルール・セットに含まれる場合、指定した表に関連するLCRをソース・キューから廃棄します。

ポジティブ・ルール・セットに含まれる場合、指定した表に関連するLCRのすべてまたはサブセットをソース・キューから宛先キューに伝播します。

ネガティブ・ルール・セットに含まれる場合、指定したスキーマ自体およびスキーマ内のデータベース・オブジェクトに関連するLCRをソース・キューから廃棄します。

ポジティブ・ルール・セットに含まれる場合、指定したスキーマ自体およびスキーマ内のデータベース・オブジェクトに関連するLCRをソース・キューから宛先キューに伝播します。

ネガティブ・ルール・セットに含まれる場合、ソース・キュー内のすべてのLCRを廃棄します。

ポジティブ・ルール・セットに含まれる場合、ソース・キュー内のすべてのLCRを宛先キューに伝播します。

適用プロセスによる適用

ネガティブ・ルール・セットに含まれる場合、指定した表に関連するLCRをキューから廃棄します。

ポジティブ・ルール・セットに含まれる場合、指定した表に関連する、キュー内のLCRのすべてまたはサブセットを適用します。

ネガティブ・ルール・セットに含まれる場合、指定したスキーマ自体およびそのスキーマ内のデータベース・オブジェクトに関連するLCRをキューから廃棄します。

ポジティブ・ルール・セットに含まれる場合、指定したスキーマ自体およびそのスキーマ内のデータベース・オブジェクトに関連するキュー内のLCRを適用します。

ネガティブ・ルール・セットに含まれる場合、キュー内のすべてのLCRを廃棄します。

ポジティブ・ルール・セットに含まれる場合、キュー内のすべてのLCRを適用します。

メッセージ・クライアントによるデキュー

ネガティブ・ルール・セットに含まれる場合、メッセージ・クライアントが起動されると、指定した表に関連する永続LCRをキューから廃棄します。

ポジティブ・ルール・セットに含まれる場合、メッセージ・クライアントが起動されると、指定した表に関連する永続LCRのすべてまたはサブセットをキューからデキューします。

ネガティブ・ルール・セットに含まれる場合、メッセージ・クライアントが起動されると、指定したスキーマ自体およびスキーマ内のデータベース・オブジェクトに関連する永続LCRをキューから廃棄します。

ポジティブ・ルール・セットに含まれる場合、メッセージ・クライアントが起動されると、指定したスキーマ自体およびスキーマ内のデータベース・オブジェクトに関連する永続LCRをキューからデキューします。

ネガティブ・ルール・セットに含まれる場合、メッセージ・クライアントが起動されると、すべての永続LCRをキューから廃棄します。

ポジティブ・ルール・セットに含まれる場合、メッセージ・クライアントが起動されると、すべての永続LCRをキューからデキューします。

DBMS_STREAMS_ADMパッケージのプロシージャを使用して、これらの各レベルでルールを作成できます。システム作成ルールには、表5-2で説明されている以外にも、Oracle Streamsクライアントの動作を変更する条件を含めることができます。たとえば、LCRに対して特定のソース・データベースを指定できるルールがあります。この場合は、LCRが指定されたソース・データベースで発生したときのみ、このルールがTRUEと評価されます。表5-3に、DBMS_STREAMS_ADMパッケージによって作成されるルールで指定できるシステム作成ルール条件のタイプを示します。

表5-3 DBMS_STREAMS_ADMパッケージによって生成されるシステム作成ルールの条件

ルール条件がTRUEと評価される対象

Oracle Streamsクライアント

作成に使用されるプロシージャ

特定のデータベース内の任意の表に対するDML変更のためにREDOログに記録されるすべての行変更

取得プロセス

ADD_GLOBAL_RULES

特定のデータベース内の任意のデータベース・オブジェクトに対する、REDOログに記録されるすべてのDDL変更

取得プロセス

ADD_GLOBAL_RULES

特定のスキーマ内の任意の表に対するDML変更のためにREDOログに記録されるすべての行変更

取得プロセス

ADD_SCHEMA_RULES

特定のスキーマと、そのスキーマ内の任意のデータベース・オブジェクトに対する、REDOログに記録されるすべてのDDL変更

取得プロセス

ADD_SCHEMA_RULES

特定の表に対するDML変更のためにREDOログに記録されるすべての行変更

取得プロセス

ADD_TABLE_RULES

特定の表に対する、REDOログに記録されるすべてのDDL変更

取得プロセス

ADD_TABLE_RULES

特定の表内の行のサブセットに対するDML変更のためにREDOログに記録されるすべての行変更

取得プロセス

ADD_SUBSET_RULES

DML文の結果、特定の表に対して行われるすべての行変更

同期取得

ADD_TABLE_RULES

DML文の結果、特定の表内の行のサブセットに対して行われるすべての行変更

同期取得

ADD_SUBSET_RULES

ソース・キュー内のすべての行LCR

伝播

ADD_GLOBAL_PROPAGATION_RULES

ソース・キュー内のすべてのDDL LCR

伝播

ADD_GLOBAL_PROPAGATION_RULES

特定のスキーマ内の表に関連するソース・キュー内のすべての行LCR

伝播

ADD_SCHEMA_PROPAGATION_RULES

特定のスキーマと、そのスキーマ内の任意のデータベース・オブジェクトに関連するソース・キュー内のすべてのDDL LCR

伝播

ADD_SCHEMA_PROPAGATION_RULES

特定の表に関連するソース・キュー内のすべての行LCR

伝播

ADD_TABLE_PROPAGATION_RULES

特定の表に関連するソース・キュー内のすべてのDDL LCR

伝播

ADD_TABLE_PROPAGATION_RULES

特定の表内の行のサブセットに関連するソース・キュー内のすべての行LCR

伝播

ADD_SUBSET_PROPAGATION_RULES

ユーザー指定のルール条件を満たす、指定されたタイプのソース・キュー内のすべてのユーザー・メッセージ

伝播

ADD_MESSAGE_PROPAGATION_RULE

適用プロセスで使用されるキュー内のすべての行LCR

適用プロセス

ADD_GLOBAL_RULES

適用プロセスで使用されるキュー内のすべてのDDL LCR

適用プロセス

ADD_GLOBAL_RULES

特定のスキーマ内の表に関連する適用プロセスで使用されるキュー内のすべての行LCR

適用プロセス

ADD_SCHEMA_RULES

特定のスキーマと、そのスキーマ内の任意のデータベース・オブジェクトに関連する適用プロセスで使用されるキュー内のすべてのDDL LCR

適用プロセス

ADD_SCHEMA_RULES

特定の表に関連する適用プロセスで使用されるキュー内のすべての行LCR

適用プロセス

ADD_TABLE_RULES

特定の表に関連する適用プロセスで使用されるキュー内のすべてのDDL LCR

適用プロセス

ADD_TABLE_RULES

特定の表内の行のサブセットに関連する適用プロセスで使用されるキュー内のすべての行LCR

適用プロセス

ADD_SUBSET_RULES

ユーザー指定のルール条件を満たす、指定されたタイプの適用プロセスで使用されるキュー内のすべての永続ユーザー・メッセージ

適用プロセス

ADD_MESSAGE_RULE

メッセージ・クライアントで使用されるキュー内のすべての永続行LCR

メッセージ・クライアント

ADD_GLOBAL_RULES

メッセージ・クライアントで使用されるキュー内のすべての永続DDL LCR

メッセージ・クライアント

ADD_GLOBAL_RULES

特定のスキーマ内の表に関連するメッセージ・クライアントで使用されるキュー内のすべての永続行LCR

メッセージ・クライアント

ADD_SCHEMA_RULES

特定のスキーマと、そのスキーマ内の任意のデータベース・オブジェクトに関連するメッセージ・クライアントで使用されるキュー内のすべての永続DDL LCR

メッセージ・クライアント

ADD_SCHEMA_RULES

特定の表に関連するメッセージ・クライアントのキュー内のすべての永続行LCR

メッセージ・クライアント

ADD_TABLE_RULES

特定の表に関連するメッセージ・クライアントで使用されるキュー内のすべての永続DDL LCR

メッセージ・クライアント

ADD_TABLE_RULES

特定の表内の行のサブセットに関連するメッセージ・クライアントで使用されるキュー内のすべての永続行LCR

メッセージ・クライアント

ADD_SUBSET_RULES

ユーザー指定のルール条件を満たす、指定されたタイプのメッセージ・クライアントで使用されるキュー内のすべての永続メッセージ

メッセージ・クライアント

ADD_MESSAGE_RULE

表5-3に示した各プロシージャでは、次の操作が実行されます。

- 取得プロセス、同期取得、伝播、適用プロセスまたはメッセージ・クライアントは、存在しない場合には作成されます。

- 指定された取得プロセス、同期取得、伝播、適用プロセスまたはメッセージ・クライアントのルール・セットは、存在しない場合には作成されます。取得プロセス、伝播、適用プロセスまたはメッセージ・クライアントについては、このルール・セットはポジティブ・ルール・セットまたはネガティブ・ルール・セットになります。プロシージャを2回以上実行して、各タイプのルール・セットを作成できます。同期取得については、このルール・セットはポジティブ・ルール・セットである必要があります。

- 0(ゼロ)個以上のルールが作成され、指定された取得プロセス、同期取得、伝播、適用プロセスまたはメッセージ・クライアントのルール・セットに追加されます。これらのプロシージャのいずれかを実行すると、ユーザーによる指定に基づいて、ポジティブ・ルール・セットまたはネガティブ・ルール・セットのいずれかにルールが追加されます。

ADD_MESSAGE_RULEおよびADD_MESSAGE_PROPAGATION_RULEプロシージャを除き、これらのプロシージャを実行すると、SYS.STREAMS$_EVALUATION_CONTEXT評価コンテキストを使用するルール・セットが作成されます。これは、Oracle Streams環境向けにOracleが提供する評価コンテキストです。

グローバル・ルール、スキーマ・ルール、表ルールおよび サブセット・ルールでは、SYS.STREAMS$_EVALUATION_CONTEXT評価コンテキストが使用されます。ただし、ADD_MESSAGE_RULEまたはADD_MESSAGE_PROPAGATION_RULEプロシージャを使用してルールを作成すると、そのルールではメッセージ・タイプごとに特別にカスタマイズされたシステム生成評価コンテキストが使用されます。ADD_MESSAGE_RULEまたはADD_MESSAGE_PROPAGATION_RULEプロシージャによって作成されたルール・セットには、評価コンテキストがありません。

ADD_SUBSET_RULES、ADD_SUBSET_PROPAGATION_RULES、ADD_MESSAGE_RULEおよびADD_MESSAGE_PROPAGATION_RULEを除き、これらのプロシージャではルールが作成されないか、1つまたは2つのルールが作成されます。DML変更またはDDL変更の結果発生する行変更のみについて、Oracle Streamsタスクを実行する場合は、ルールが1つのみ作成されます。ただし、DML変更とDDL変更の両方の結果についてOracle Streamsタスクを実行する場合は、ルールが個々に作成されます。ここで表のDMLルールを作成すると、以前に作成したDMLルールを変更せずに、後で同じ表のDDLルールを作成できます。これは、最初に表のDDLルールを作成してから、後で同じ表のDMLルールを作成する場合も同じです。

ADD_SUBSET_RULESおよびADD_SUBSET_PROPAGATION_RULESプロシージャでは、表に対する3種類のDML操作であるINSERT、UPDATEおよびDELETEについて、常に3つのルールが作成されます。これらのプロシージャでは、表に対するDDL変更のルールは作成されません。ADD_TABLE_RULESまたはADD_TABLE_PROPAGATION_RULESプロシージャを使用すると、表のDDLルールを作成できます。また、サブセット・ルールはポジティブ・ルール・セットにのみ追加でき、ネガティブ・ルール・セットには追加できません。

ADD_MESSAGE_RULEおよびADD_MESSAGE_PROPAGATION_RULEプロシージャでは、ユーザー指定のルール条件のある1つのルールが常に作成されます。これらのプロシージャでは、ユーザー・メッセージのルールが作成されます。表に対するDML変更またはDDL変更の結果のルールは作成されません。

取得LCRの伝播ルールを作成する場合は、変更対象のソース・データベースを指定することをお薦めします。適用プロセスでは、トランザクション制御メッセージを使用して、取得LCRがコミット済のトランザクションに組み立てられます。COMMITやROLLBACKなどのトランザクション制御メッセージには、メッセージが発生したソース・データベースの名前が含まれます。意図に反したこれらのメッセージの循環を回避するには、ソース・データベースを指定する条件を伝播ルールに含める必要があります。そのためには、伝播ルールの作成時にソース・データベースを指定します。

次の各項では、システム作成ルールについてさらに詳しく説明します。

- グローバル・ルール

- スキーマ・ルール

- 表ルール

- サブセット・ルール

- メッセージ・ルール

- システム作成ルールとネガティブ・ルール・セット

- システム作成ルールへのユーザー定義条件の追加

注意:

- NOTまたはORの論理条件を使用するルールなど、より複雑なルール条件のあるルールを作成するには、DBMS_STREAMS_ADMパッケージの一部のプロシージャで使用可能なand_conditionパラメータを使用するか、DBMS_RULE_ADMパッケージを使用します。

- 以降の項で説明する各例は、特に指定がなければ、適切な権限を付与されたOracle Streams管理者が完了する必要があります。

- この項の一部の例には、追加の前提条件があります。たとえば、プロシージャ・パラメータで指定されるキューが存在する必要があります。

関連項目:

- 「ルールの管理」

- メッセージがOracle Streamsクライアントのルール・セットを満たす場合の詳細は、「ルール・セットおよびメッセージのルール評価」を参照

- DBMS_STREAMS_ADMパッケージおよびDBMS_RULE_ADMパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

- 「Oracle Streamsで使用される評価コンテキスト」

- 「論理変更レコード(LCR)」

- 「複合ルール条件」

グローバル・ルール

ルールを使用して、データベース全体またはキュー全体に関連するOracle Streamsタスクを指定するときには、グローバル・ルールを指定します。DML変更に関するグローバル・ルール、DDL変更に関するグローバル・ルール、または各のタイプの変更に関するグローバル・ルール(合計2つのルール)を指定できます。

取得プロセスの場合、ポジティブ・ルール・セットに1つのグローバル・ルールを含めると、ソース・データベースに対するすべてのDML変更またはすべてのDDL変更の結果を取得します。また、ネガティブ・ルール・セットに1つのグローバル・ルールを含めると、ソース・データベースに対するすべてのDML変更またはすべてのDDL変更の結果を廃棄します。

伝播の場合、ポジティブ・ルール・セットに1つのグローバル・ルールを含めると、ソース・キュー内のすべての行LCRまたはすべてのDDL LCRを宛先キューに伝播します。また、ネガティブ・ルール・セットに1つのグローバル・ルールを含めると、ソース・キュー内のすべての行LCRまたはすべてのDDL LCRを廃棄します。

適用プロセスの場合、ポジティブ・ルール・セットに1つのグローバル・ルールを含めると、指定したソース・データベースに関する、キュー内のすべての行LCRまたはすべてのDDL LCRを適用します。適用プロセスの場合、ネガティブ・ルール・セットに1つのグローバル・ルールを含めると、指定したソース・データベースに関する、キュー内のすべての行LCRまたはすべてのDDL LCRを廃棄します。

グローバル・ルールを使用する際、Oracle Streamsでサポートされないデータベース・オブジェクトを変更する場合は、DBMS_RULE_ADMパッケージを使用してサポートされない変更を廃棄するルールを作成できます。

関連項目:

- 「サポートされていないLCRを廃棄するようにOracle Streamsクライアントに指示するルール条件」

グローバル・ルールの例

DBMS_STREAMS_ADMパッケージのADD_GLOBAL_RULESプロシージャを使用し、Oracle Streamsの取得プロセスに対してデータベース内のすべてのDML変更とDDL変更を取得するよう指示する場合を考えます。

ADD_GLOBAL_RULESプロシージャを実行してルールを作成します。

BEGIN
DBMS_STREAMS_ADM.ADD_GLOBAL_RULES(
streams_type        =>  'capture',
streams_name        =>  'capture',
queue_name          =>  'streams_queue',
include_dml         =>  TRUE,
include_ddl         =>  TRUE,
include_tagged_lcr  =>  FALSE,
source_database     =>  NULL,
inclusion_rule      =>  TRUE);
END;
/

inclusion_ruleパラメータがTRUEに設定されていることに注意してください。この設定によって、システム作成ルールが取得プロセスのポジティブ・ルール・セットに追加されます。

作成しているルールはローカル取得プロセス用であるため、source_databaseパラメータにNULLを指定できます。ローカル・データベースのグローバル名も指定できます。ADD_GLOBAL_RULESを使用してダウンストリーム取得プロセスまたは適用プロセスのルールを作成する場合は、ソース・データベース名を指定します。

ADD_GLOBAL_RULESプロシージャによって2つのルールが作成されます。1つは行LCR(DML変更の結果を含む)用、もう1つはDDL LCR用です。

行LCRルールで使用されるルール条件を次に示します。

(:dml.is_null_tag() = 'Y' )

DMLルールの条件は変数:dmlで始まることに注意してください。この値は、評価される行LCRに対して指定されたメンバー・ファンクションのコールによって決定されます。したがって:dml.is_null_tag()は、評価される行LCRのIS_NULL_TAGメンバー・ファンクションのコールです。

DDL LCRルールで使用されるルール条件を次に示します。

(:ddl.is_null_tag() = 'Y' )

DDLルールの条件は変数:ddlで始まることに注意してください。この値は、評価されるDDL LCRに対して指定されたメンバー・ファンクションのコールによって決定されます。したがって:ddl.is_null_tag()は、評価されるDDL LCRのIS_NULL_TAGメンバー・ファンクションのコールです。

取得プロセスの場合、これらの条件は、取得プロセスによって変更を取得するにはREDOレコード内のタグがNULLである必要があることを示します。伝播の場合、これらの条件は、伝播によってLCRを伝播するにはLCR内のこのタグがNULLである必要があることを示します。適用プロセスの場合、これらの条件は、適用プロセスによってLCRを適用するにはLCR内のこのタグがNULLである必要があることを示します。

この例で作成したルールを取得プロセスのポジティブ・ルール・セットで使用すると、データベースに対して行ったサポート対象のDML変更とDDL変更が取得プロセスによってすべて取得されます。

注意:
取得プロセスのポジティブ・ルール・セットにグローバル・ルールを追加する場合は、取得プロセスでサポートされないデータベース・オブジェクトを除外するために、必ず取得プロセスのネガティブ・ルール・セットにルールを追加してください。DBA_STREAMS_UNSUPPORTEDデータ・ディクショナリ・ビューを問い合せて、取得プロセスでサポートされないデータベース・オブジェクトを特定します。サポートされないデータベース・オブジェクトを除外しないと、取得エラーが発生します。
適用プロセスのポジティブ・ルール・セットにグローバル・ルールを追加する場合は、適用プロセスによってサポートされない列への変更の適用が試行されないようにしてください。そのためには、適用プロセスのネガティブ・ルール・セットにルールを追加して、その列を含む表を除外するか、ルールベースの変換またはDMLハンドラを使用してその列を除外できます。DBA_STREAMS_COLUMNSデータ・ディクショナリ・ビューを問い合せて、適用プロセスでサポートされない列を特定します。サポートされない列を除外しないと、エラーが発生します。

関連項目:

- 「取得プロセスと互換性のないデータベース・オブジェクトの表示」

- 「適用プロセスと互換性のないデータベース・オブジェクトおよび列の表示」

- 第6章「ルールベースの変換」

- 「DMLハンドラ」

システム作成グローバル・ルールによる空のルール条件の自動回避

DBMS_STREAMS_ADMパッケージのプロシージャを実行する場合、include_tagged_lcrパラメータにTRUEを指定すると、システム作成ルールでis_null_tag条件を省略できます。たとえば、次のADD_GLOBAL_RULESプロシージャでは、is_null_tag条件なしでもルールが作成されます。

BEGIN DBMS_STREAMS_ADM.ADD_GLOBAL_RULES(
streams_type        =>  'capture',
streams_name        =>  'capture_002',
queue_name          =>  'streams_queue',
include_dml         =>  TRUE,
include_ddl         =>  TRUE,
include_tagged_lcr  =>  TRUE,
source_database     =>  NULL,
inclusion_rule      =>  TRUE);
END;
/

グローバル・ルールについてinclude_tagged_lcrパラメータをTRUEに設定し、source_database_nameパラメータをNULLに設定すると、行LCRルールで使用されるルール条件は次のようになります。

(( :dml.get_source_database_name()>=' ' OR
:dml.get_source_database_name()<=' ') )

DDL LCRルールで使用されるルール条件を次に示します。

(( :ddl.get_source_database_name()>=' ' OR
:ddl.get_source_database_name()<=' ') )

システム作成グローバル・ルールに含まれるこれらの条件によって、すべての行LCRおよびDDL LCRがTRUEと評価されます。

これらのルール条件は、これらのルールに対するNULLのルール条件を回避するために指定されます。NULLのルール条件はサポートされません。この場合、データベースに対するすべてのDML変更とDDL変更を取得する必要があり、取得時にそれらの変更に対してルールベースの変換を使用しないときは、グローバル・ルールを指定するかわりに、ポジティブ・ルール・セットなしで取得プロセスを実行できます。

注意:

- DBMS_STREAMS_ADMパッケージのプロシージャを使用して取得プロセスを作成し、取得プロセスに対して1つ以上のルールを生成すると、取得された変更の対象となるオブジェクトがインスタンス化のために自動的に準備されます。ただし、その取得プロセスがダウンストリーム取得プロセスであり、ダウンストリーム・データベースからソース・データベースへのデータベース・リンクが存在しない場合は除きます。

- この取得プロセスでは、一部のタイプのDML変更およびDDL変更が取得されず、SYS、SYSTEMまたはCTXSYSスキーマで行われた変更も取得されません。

関連項目:

- 取得プロセス・ルールおよびインスタンス化の準備の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- 取得プロセスと、取得プロセスによって取得されるDML文およびDDL文の詳細は、第2章「Oracle Streams情報取得」を参照

- 条件内の変数の詳細は、第11章「ルールの高度な概念」を参照

- Oracle Streamsタグの詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- ポジティブ・ルール・セットなしでの取得プロセスの実行の詳細は、「ルール・セットおよびメッセージのルール評価」を参照

スキーマ・ルール

ルールを使用してスキーマに関連するOracle Streamsタスクを指定するときには、スキーマ・ルールを指定します。DML変更に関するスキーマ・ルール、DDL変更に関するスキーマ・ルール、またはスキーマに対するそれぞれの変更に関するスキーマ・ルール(合計2つのルール)を指定できます。

取得プロセスの場合、ポジティブ・ルール・セットに1つのスキーマ・ルールを含めると、スキーマに対するDML変更またはDDL変更を取得します。また、ネガティブ・ルール・セットに1つのスキーマ・ルールを含めると、スキーマに対するDML変更またはDDL変更の結果を廃棄します。

伝播の場合、ポジティブ・ルール・セットに1つのスキーマ・ルールを含めると、スキーマに対する変更を含む行LCRまたはDDL LCRをソース・キューから伝播します。また、ネガティブ・ルール・セットに1つのスキーマ・ルールを含めると、スキーマに対する変更を含む行LCRまたはDDL LCRをソース・キューから廃棄します。

適用プロセスの場合、ポジティブ・ルール・セットに1つのスキーマ・ルールを含めると、スキーマに対する変更を含むキュー内の行LCRまたはDDL LCRを適用します。また、ネガティブ・ルール・セットに1つのスキーマ・ルールを含めると、スキーマに対する変更を含むキュー内の行LCRまたはDDL LCRを廃棄します。

スキーマ・ルールを使用する際、Oracle Streamsでサポートされないスキーマのデータベース・オブジェクトを変更する場合は、DBMS_RULE_ADMパッケージを使用してサポートされない変更を廃棄するルールを作成できます。

関連項目:

- 「サポートされていないLCRを廃棄するようにOracle Streamsクライアントに指示するルール条件」

スキーマ・ルールの例

DBMS_STREAMS_ADMパッケージのADD_SCHEMA_PROPAGATION_RULESプロシージャを使用して、Oracle Streams伝播でhrスキーマに関連する行LCRおよびDDL LCRをdbs1.example.comデータベースのキューからdbs2.example.comデータベースのキューに伝播するよう指示する場合を考えます。

dbs1.example.comでADD_SCHEMA_PROPAGATION_RULESプロシージャを実行して、ルールを作成します。

BEGIN
DBMS_STREAMS_ADM.ADD_SCHEMA_PROPAGATION_RULES(
schema_name              =>  'hr',
streams_name             =>  'dbs1_to_dbs2',
source_queue_name        =>  'streams_queue',
destination_queue_name   =>  'streams_queue@dbs2.example.com',
include_dml              =>  TRUE,
include_ddl              =>  TRUE,
include_tagged_lcr       =>  FALSE,
source_database          =>  'dbs1.example.com',
inclusion_rule           =>  TRUE);
END;
/

inclusion_ruleパラメータがTRUEに設定されていることに注意してください。この設定によって、システム作成ルールが伝播のポジティブ・ルール・セットに追加されます。

ADD_SCHEMA_PROPAGATION_RULESプロシージャによって2つのルールが作成されます。1つは行LCR(DML変更の結果を含む)用、もう1つはDDL LCR用です。

行LCRルールで使用されるルール条件を次に示します。

((:dml.get_object_owner() = 'HR') and :dml.is_null_tag() = 'Y'
and :dml.get_source_database_name() = 'DBS1.EXAMPLE.COM' )

DDL LCRルールで使用されるルール条件を次に示します。

((:ddl.get_object_owner() = 'HR' or :ddl.get_base_table_owner() = 'HR')
and :ddl.is_null_tag() = 'Y' and :ddl.get_source_database_name() =
'DBS1.EXAMPLE.COM' )

オブジェクトを所有しないユーザーがそのオブジェクトのDDL変更を実行した場合、GET_OBJECT_OWNERファンクションではNULLが返される可能性があるため、DDL LCRルールではGET_BASE_TABLE_OWNERメンバー・ファンクションが使用されます。

伝播のポジティブ・ルール・セットにこれらのルールが含まれる場合に、伝播によって伝播される変更の例を次に示します。

- hr.countries表への1行の挿入

- hr.loc_city_ix索引の変更

- hr.employees表の切捨て

- hr.countries表への列の追加

- hr.update_job_historyトリガーの変更

- hrスキーマでのcandidatesという新規表の作成

- hr.candidates行への20行の挿入

伝播によって、これらの変更のすべてを含むLCRがソース・キューから宛先キューに伝播されます。

次に、同じルールが使用され、oe.inventories表に1行が挿入されたる場合を考えます。oeスキーマがスキーマ・ルールで指定されておらず、oe.inventories表が表ルールで指定されていないため、この変更は無視されます。

注意:
取得プロセスのポジティブ・ルール・セットにスキーマ・ルールを追加する場合は、取得プロセスでサポートされないスキーマ内のデータベース・オブジェクトを除外するために、必ず取得プロセスのネガティブ・ルール・セットにルールを追加してください。DBA_STREAMS_UNSUPPORTEDデータ・ディクショナリ・ビューを問い合せて、取得プロセスでサポートされないデータベース・オブジェクトを特定します。サポートされないデータベース・オブジェクトを除外しないと、取得エラーが発生します。
適用プロセスのポジティブ・ルール・セットにスキーマ・ルールを追加する場合は、適用プロセスによってサポートされない列への変更の適用が試行されないようにしてください。そのためには、適用プロセスのネガティブ・ルール・セットにルールを追加して、その列を含む表を除外するか、ルールベースの変換またはDMLハンドラを使用してその列を除外できます。DBA_STREAMS_COLUMNSデータ・ディクショナリ・ビューを問い合せて、適用プロセスでサポートされない列を特定します。サポートされない列を除外しないと、エラーが発生します。

関連項目:

- 「取得プロセスと互換性のないデータベース・オブジェクトの表示」

- 「適用プロセスと互換性のないデータベース・オブジェクトおよび列の表示」

- 第6章「ルールベースの変換」

- 「DMLハンドラ」

表ルール

ルールを使用して個々の表のみに関連するOracle Streamsタスクを指定するときには、表ルールを指定します。特定の表に対するDML変更に関する表ルール、DDL変更に関する表ルール、または各タイプの変更に関する表ルール(合計2つのルール)を指定できます。

取得プロセスの場合、ポジティブ・ルール・セットに1つの表ルールを含めると、表に対するDML変更またはDDL変更の結果を取得します。また、ネガティブ・ルール・セットに1つの表ルールを含めると、表に対するDML変更またはDDL変更の結果を廃棄します。

同期取得の場合、ポジティブ・ルール・セットに1つの表ルールを含めると、表に対するDML変更の結果を取得します。ネガティブ・ルール・セットを同期取得に関連付けることはできません。

伝播の場合、ポジティブ・ルール・セットに1つの表ルールを含めると、表に対する変更を含む行LCRまたはDDL LCRをソース・キューから伝播します。また、ネガティブ・ルール・セットに1つの表ルールを含めると、表に対する変更を含む行LCRまたはDDL LCRをソース・キューから廃棄します。

適用プロセスの場合、ポジティブ・ルール・セットに1つの表ルールを含めると、表に対する変更を含むキュー内の行LCRまたはDDL LCRを適用します。また、ネガティブ・ルール・セットに1つの表ルールを含めると、表に対する変更を含むキュー内の行LCRまたはDDL LCRを廃棄します。

表ルールの例

DBMS_STREAMS_ADMパッケージのADD_TABLE_RULESプロシージャを使用して、Oracle Streamsの適用プロセスに次の動作を指示する場合を考えます。

- hr.locations表に関連するすべての行LCRの適用

- hr.countries表に関連するすべてのDDL LCRの適用

hr.locations表に関連するすべての行LCRの適用

これらの行LCRの変更が、dbs1.example.comソース・データベースで発生しました。

ADD_TABLE_RULESプロシージャを実行して次のルールを作成します。

BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
table_name          =>  'hr.locations',
streams_type        =>  'apply',
streams_name        =>  'apply',
queue_name          =>  'streams_queue',
include_dml         =>  TRUE,
include_ddl         =>  FALSE,
include_tagged_lcr  =>  FALSE,
source_database     =>  'dbs1.example.com',
inclusion_rule      =>  TRUE);
END;
/

inclusion_ruleパラメータがTRUEに設定されていることに注意してください。この設定によって、システム作成ルールが適用プロセスのポジティブ・ルール・セットに追加されます。

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' )

hr.countries表に関連するすべてのDDL LCRの適用

これらのDDL LCRの変更が、dbs1.example.comソース・データベースで発生しました。

ADD_TABLE_RULESプロシージャを実行して次のルールを作成します。

BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
table_name          =>  'hr.countries',
streams_type        =>  'apply',
streams_name        =>  'apply',
queue_name          =>  'streams_queue',
include_dml         =>  FALSE,
include_ddl         =>  TRUE,
include_tagged_lcr  =>  FALSE,
source_database     =>  'dbs1.example.com',
inclusion_rule      =>  TRUE);
END;
/

inclusion_ruleパラメータがTRUEに設定されていることに注意してください。この設定によって、システム作成ルールが適用プロセスのポジティブ・ルール・セットに追加されます。

ADD_TABLE_RULESプロシージャによって、次のようなルール条件のあるルールが作成されます。

(((:ddl.get_object_owner() = 'HR' and :ddl.get_object_name() = 'COUNTRIES')
or (:ddl.get_base_table_owner() = 'HR'
and :ddl.get_base_table_name() = 'COUNTRIES')) and :ddl.is_null_tag() = 'Y'
and :ddl.get_source_database_name() = 'DBS1.EXAMPLE.COM' )

オブジェクトを所有しないユーザーがそのオブジェクトのDDL変更を実行した場合、GET_OBJECT_OWNERおよびGET_OBJECT_NAMEファンクションではNULLが返される可能性があるため、DDL LCRルールではGET_BASE_TABLE_OWNERおよびGET_BASE_TABLE_NAMEメンバー・ファンクションが使用されます。

生成されたDDL表のルールは、表または表の一部を構成するオブジェクト(表の索引やトリガーなど)で行われるすべてのDDL変更について、TRUEと評価します。DDL変更は、表を参照しない場合または次の方法で表を参照する場合にFALSEと評価されます。たとえば、表に基づいてシノニムまたはビューを作成する変更について、FALSEと評価されます。また、表を参照するPL/SQLサブプログラムに対する変更についてもFALSEと評価されます。

ルールのまとめ

この例では、次の表ルールが定義されています。

- hr.locations表に対するDML操作の結果発生した行変更が行LCRに含まれている場合にTRUEに評価される表ルール

- hr.countries表で実行されたDDL変更がDDL LCRに含まれている場合にTRUEに評価される表ルール

これらのルールを使用した場合に適用プロセスによって適用される変更の例を次に示します。

- hr.locations表への1行の挿入

- hr.locations表からの5行の削除

- hr.countries表への列の追加

適用プロセスによって、これらの変更を含むLCRがその関連キューからデキューされ、宛先データベースのデータベース・オブジェクトに適用されます。

これらのルールを使用した場合に適用プロセスによって無視される変更の例を次に示します。

- hr.employees表への1行の挿入。hr.employees表の変更はどのルールも満たさないため、この変更は適用されません。

- hr.countries表内の1行の更新。この変更はDDL変更ではなくDML変更です。hr.countries表に関するルールはDDL変更のみを対象としているため、この変更は適用されません。

- hr.locations表への1列の追加。この変更はDML変更ではなくDDL変更です。hr.locations表に関するルールはDML変更のみを対象としているため、この変更は適用されません。

注意:
取得プロセスでサポートされない表については、取得プロセスのポジティブ・ルール・セットに表ルールを追加しないでください。DBA_STREAMS_UNSUPPORTEDデータ・ディクショナリ・ビューを問い合せて、取得プロセスでサポートされない表を特定します。サポートされない表を除外しないと、取得エラーが発生します。
同期取得または適用プロセスのポジティブ・ルール・セットに表ルールを追加する場合は、サポートされない列の変更の処理がこれらのOracle Streamsクライアントによって試行されないようにしてください。サポートされない列が表に含まれる場合はルールベースの変換によって、また、適用プロセスの場合はDMLハンドラによってその列を除外できます。DBA_STREAMS_COLUMNSデータ・ディクショナリ・ビューを問い合せて、同期取得または適用プロセスでサポートされない列を特定します。サポートされない列を除外しないと、エラーが発生します。

関連項目:

- 「取得プロセスと互換性のないデータベース・オブジェクトの表示」

- 「同期取得と互換性のないデータベース・オブジェクトおよび列の表示」

- 「適用プロセスと互換性のないデータベース・オブジェクトおよび列の表示」

- 第6章「ルールベースの変換」

- 「DMLハンドラ」

サブセット・ルール

サブセット・ルールはDML変更の特殊な表ルールであり、表の行のサブセットのみに関連します。取得プロセス、同期取得、適用プロセスおよびメッセージ・クライアントのサブセット・ルールはADD_SUBSET_RULESプロシージャを使用して作成できます。伝播のサブセット・ルールはADD_SUBSET_PROPAGATION_RULESプロシージャを使用して作成できます。これらのプロシージャでは、SELECT文のWHERE句と同様の条件を使用して次の指定ができます。

- 取得プロセスが、特定の表に対するDML変更によって発生する行変更のサブセットのみを取得するように指定

- 同期取得が、特定の表に対するDML変更によって発生する行変更のサブセットのみを取得するように指定

- 伝播が、特定の表に関連する行LCRのサブセットのみを伝播するように指定

- 適用プロセスが、特定の表に関連する行LCRのサブセットのみを適用するように指定

- メッセージ・クライアントが、特定の表に関連する行LCRのサブセットのみをデキューするように指定

ADD_SUBSET_RULESプロシージャとADD_SUBSET_PROPAGATION_RULESプロシージャでは、Oracle Streamsクライアントのポジティブ・ルール・セットのみにサブセット・ルールを追加できます。これらのプロシージャでは、Oracle Streamsクライアントのネガティブ・ルール・セットにサブセット・ルールを追加できません。

次の各項では、サブセット・ルールについてさらに詳しく説明します。

- サブセット・ルールの例

- 行の移行およびサブセット・ルール

- サブセット・ルールとサプリメンタル・ロギング

- サブセット・ルールを使用する際のガイドライン

関連項目:

- 「サブセット・ルールの制限」

サブセット・ルールの例

この例では、region_idが2であるhr.regions表に関連する行LCRのサブセットをOracle Streamsの適用プロセスで適用するよう指示します。これらの変更は、dbs1.example.comソース・データベースで発生しています。

ADD_SUBSET_RULESプロシージャを実行して3つのルールを作成します。

BEGIN
DBMS_STREAMS_ADM.ADD_SUBSET_RULES(
table_name               =>  'hr.regions',
dml_condition            =>  'region_id=2',
streams_type             =>  'apply',
streams_name             =>  'apply',
queue_name               =>  'streams_queue',
include_tagged_lcr       =>  FALSE,
source_database          =>  'dbs1.example.com');
END;
/

ADD_SUBSET_RULESプロシージャによって、INSERT操作用、UPDATE操作用およびDELETE操作用に1つずつ、合計3つのルールが作成されます。

挿入ルールで使用されるルール条件を次に示します。

:dml.get_object_owner()='HR' AND :dml.get_object_name()='REGIONS'
AND :dml.is_null_tag()='Y' AND :dml.get_source_database_name()='DBS1.EXAMPLE.COM'
AND :dml.get_command_type() IN ('UPDATE','INSERT')
AND (:dml.get_value('NEW','"REGION_ID"') IS NOT NULL)
AND (:dml.get_value('NEW','"REGION_ID"').AccessNumber()=2)
AND (:dml.get_command_type()='INSERT'
OR ((:dml.get_value('OLD','"REGION_ID"') IS NOT NULL)
AND (((:dml.get_value('OLD','"REGION_ID"').AccessNumber() IS NOT NULL)
AND NOT (:dml.get_value('OLD','"REGION_ID"').AccessNumber()=2))
OR ((:dml.get_value('OLD','"REGION_ID"').AccessNumber() IS NULL)
AND NOT EXISTS (SELECT 1 FROM SYS.DUAL
WHERE (:dml.get_value('OLD','"REGION_ID"').AccessNumber()=2))))))

このルール条件に基づいて、行LCRが次のように評価されます。

- 挿入の場合は、行LCRでregion_idの新しい値が2であれば、挿入が適用されます。

- 挿入の場合は、行LCRでregion_idの新しい値が2でないか、またはNULLであれば、挿入が除外されます。

- 更新の場合は、行LCRでregion_idの古い値が2でないか、またはNULLであり、行LCRでregion_idの新しい値が2であれば、更新が挿入に変換されてから適用されます。この自動変換を行の移行といいます。詳細は、「行の移行およびサブセット・ルール」を参照してください。

更新ルールで使用されるルール条件を次に示します。

:dml.get_object_owner()='HR' AND :dml.get_object_name()='REGIONS'
AND :dml.is_null_tag()='Y' AND :dml.get_source_database_name()='DBS1.EXAMPLE.COM'
AND :dml.get_command_type()='UPDATE'
AND (:dml.get_value('NEW','"REGION_ID"') IS NOT NULL)
AND (:dml.get_value('OLD','"REGION_ID"') IS NOT NULL)
AND (:dml.get_value('OLD','"REGION_ID"').AccessNumber()=2)
AND (:dml.get_value('NEW','"REGION_ID"').AccessNumber()=2)

このルール条件に基づいて、行LCRが次のように評価されます。

- 更新の場合は、行LCRでregion_idの古い値と新しい値がどちらも2であれば、更新がそのまま適用されます。

- 更新の場合は、行LCRでregion_idの古い値または新しい値が2でないか、あるいはNULLであれば、その更新は更新ルールを満たしません。LCRは、挿入ルールを満たす場合、削除ルールを満たす場合、またはどちらのルールも満たさない場合があります。

削除ルールで使用されるルール条件を次に示します。

:dml.get_object_owner()='HR' AND :dml.get_object_name()='REGIONS'
AND :dml.is_null_tag()='Y' AND :dml.get_source_database_name()='DBS1.EXAMPLE.COM'
AND :dml.get_command_type() IN ('UPDATE','DELETE')
AND (:dml.get_value('OLD','"REGION_ID"') IS NOT NULL)
AND (:dml.get_value('OLD','"REGION_ID"').AccessNumber()=2)
AND (:dml.get_command_type()='DELETE'
OR ((:dml.get_value('NEW','"REGION_ID"') IS NOT NULL)
AND (((:dml.get_value('NEW','"REGION_ID"').AccessNumber() IS NOT NULL)
AND NOT (:dml.get_value('NEW','"REGION_ID"').AccessNumber()=2))
OR ((:dml.get_value('NEW','"REGION_ID"').AccessNumber() IS NULL)
AND NOT EXISTS (SELECT 1 FROM SYS.DUAL
WHERE (:dml.get_value('NEW','"REGION_ID"').AccessNumber()=2))))))

このルール条件に基づいて、行LCRが次のように評価されます。

- 削除の場合は、行LCRでregion_idの古い値が2であれば、削除が適用されます。

- 削除の場合は、行LCRでregion_idの古い値が2でないか、またはNULLであれば、削除が除外されます。

- 更新の場合は、行LCRでregion_idの古い値が2で、かつ、行LCRでregion_idの新しい値が2でないか、NULLであれば、更新が削除に変換されてから適用されます。この自動変換を行の移行といいます。詳細は、「行の移行およびサブセット・ルール」を参照してください。

これらのサブセット・ルールを使用した場合に適用プロセスによって適用される変更の例を次に示します。

- region_idの古い値が4で、region_idの新しい値が2であるhr.regions表での行の更新。この更新は挿入に変換されます。

- region_idの古い値が2で、region_idの新しい値が1である hr.regions表での行の更新。この更新は削除に変換されます。

適用プロセスによって、これらの変更を含む行LCRがその関連キューからデキューされ、宛先データベースのhr.regions表に適用されます。

これらのサブセット・ルールを使用した場合に適用プロセスによって無視される変更の例を次に示します。

- hr.employees表への1行の挿入。hr.employees表の変更はサブセット・ルールを満たさないため、この変更は適用されません。

- 更新前のregion_idが1であり、更新後も1のままであるhr.regions表での行の更新。hr.regions表のサブセット・ルールはregion_idの新しい値または古い値(あるいはその両方)が2の場合にのみTRUEと評価されるため、この変更は適用されません。

注意:
取得プロセスでサポートされない表については、取得プロセスのポジティブ・ルール・セットにサブセット・ルールを追加しないでください。DBA_STREAMS_UNSUPPORTEDデータ・ディクショナリ・ビューを問い合せて、取得プロセスでサポートされない表を特定します。サポートされない表を除外しないと、取得エラーが発生します。
同期取得または適用プロセスのポジティブ・ルール・セットにサブセット・ルールを追加する場合は、サポートされない列の変更の処理がこれらのOracle Streamsクライアントによって試行されないようにしてください。サポートされない列が表に含まれる場合はルールベースの変換によって、また、適用プロセスの場合はDMLハンドラによってその列を除外できます。DBA_STREAMS_COLUMNSデータ・ディクショナリ・ビューを問い合せて、同期取得または適用プロセスでサポートされない列を特定します。サポートされない列を除外しないと、エラーが発生します。

関連項目:

- 「取得プロセスと互換性のないデータベース・オブジェクトの表示」

- 「同期取得と互換性のないデータベース・オブジェクトおよび列の表示」

- 「適用プロセスと互換性のないデータベース・オブジェクトおよび列の表示」

行の移行およびサブセット・ルール

サブセット・ルールを使用すると、更新操作が、取得、伝播、適用またはデキューされる際に挿入操作または削除操作に変換されることがあります。この自動変換は行の移行と呼ばれ、サブセット・ルールのアクション・コンテキストで自動的に指定された内部変換によって実行されます。次の項では、取得、伝播、適用およびデキュー中の行の移行について説明します。

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

- 取得中の行の移行

- 伝播中の行の移行

- 適用中の行の移行

- メッセージ・クライアントによるデキュー中の行の移行

注意:
サブセット・ルールはポジティブ・ルール・セットにのみ存在する必要があります。ネガティブ・ルール・セットにはサブセット・ルールを追加しないでください。ネガティブ・ルール・セットで廃棄されないLCRでは行の移行が実行されないため、ネガティブ・ルール・セットにサブセット・ルールを追加すると、予期せぬ結果が発生する可能性があります。また、ネガティブ・ルール・セットでTRUEと評価されたために廃棄されるLCRでも、行の移行は実行されません。

取得中の行の移行

サブセット・ルールが取得プロセスまたは同期取得のルール・セットに含まれる場合、そのサブセット・ルールを満たす更新は、取得時に挿入または削除に変換されることがあります。

たとえば、サブセット・ルールを使用し、department_id = 50というサブセット条件を指定して、従業員のdepartment_idが50の場合にhr.employees表の変更を取得プロセスまたは同期取得で取得するよう指定する場合を考えます。ソース・データベースの表に、全部門の従業員レコードが含まれていると仮定します。DML操作によって従業員のdepartment_idが80から50に変更された場合、このサブセット・ルールによって更新操作が挿入操作に変換され、変更が取得されます。したがって、INSERTを含む行LCRがキューにエンキューされます。図5-2は、取得プロセスのサブセット・ルールが使用される場合のこの例を示しています。

図5-2 取得プロセスによる取得中の行の移行

同様に、取得される更新によって従業員のdepartment_idが50から20に変更される場合、このサブセット・ルールが指定された取得プロセスまたは同期取得では、更新操作がDELETE操作に変換されます。

伝播中の行の移行

サブセット・ルールが伝播のルール・セットに含まれる場合、更新操作は、行LCRの伝播時に挿入操作または削除操作に変換されることがあります。

たとえば、サブセット・ルールを使用し、department_id = 50というサブセット条件を指定して、従業員のdepartment_idが50の場合にhr.employees表の変更を伝播によって伝播するよう指定する場合を考えます。伝播のソース・キューに、従業員のdepartment_idを50から80に変更するhr.employees表の更新操作を指定した行LCRが含まれる場合、このサブセット・ルールが指定されている伝播では更新操作が削除操作に変換され、行LCRが宛先キューに伝播されます。したがって、DELETEを含む行LCRが宛先キューにエンキューされます。図5-3はこの例を示しています。

図5-3 伝播中の行の移行

同様に、取得される更新によって従業員のdepartment_idが80から50に変更される場合、このサブセット・ルールが指定された伝播では、更新操作がINSERT操作に変換されます。

適用中の行の移行

サブセット・ルールが適用プロセスのルール・セットに含まれる場合は、行LCRの適用時に更新操作が挿入操作または削除操作に変換されることがあります。

たとえば、サブセット・ルールを使用し、department_id = 50というサブセット条件を指定して、従業員のdepartment_idが50の場合にhr.employees表の変更を適用プロセスで適用するよう指定する場合を考えます。宛先データベースの表が、department_idが50の従業員のレコードのみを含むサブセット表であると仮定します。従業員のdepartment_idを80から50に変更する従業員の変更がソース・データベースで取得された場合、このサブセット・ルールが指定されている宛先データベースの適用プロセスによって、更新操作が挿入操作に変換されてこの変更が適用されます。この変換が必要なのは、その従業員の行が宛先の表に存在しないためです。図5-4はこの例を示しています。

図5-4 適用中の行の移行

同様に、取得される更新によって従業員のdepartment_idが50から20に変更される場合、このサブセット・ルールが指定された適用プロセスでは、更新操作がDELETE操作に変換されます。

メッセージ・クライアントによるデキュー中の行の移行

サブセット・ルールがメッセージ・クライアントのルール・セットに含まれる場合は、行LCRのデキュー時に更新操作が挿入操作または削除操作に変換されることがあります。

たとえば、サブセット・ルールを使用し、department_id = 50というサブセット条件を指定して、従業員のdepartment_idが50の場合にhr.employees表の変更をメッセージ・クライアントでデキューするよう指定する場合を考えます。従業員のdepartment_idを50から90に変更するhr.employees表の更新操作を含む永続行LCRがメッセージ・クライアントのキューに含まれる場合、このサブセット・ルールが指定されているメッセージ・クライアントをユーザーまたはアプリケーションが起動したとき、メッセージ・クライアントによって更新操作が削除操作に変換され、行LCRがデキューされます。したがって、DELETEを含む行LCRがデキューされます。メッセージ・クライアントでは、カスタマイズされた任意の方法でこの行LCRを処理できます。たとえば、行LCRをカスタム・アプリケーションに送信できます。図5-5はこの例を示しています。

図5-5 メッセージ・クライアントによるデキュー中の行の移行

同様に、従業員のdepartment_idを90から50に変更する更新が永続行LCRに含まれる場合、このサブセット・ルールが指定されたメッセージ・クライアントでは、デキュー中にUPDATE操作がINSERT操作に変換されます。

サブセット・ルールとサプリメンタル・ロギング

次のタイプのサブセット・ルールを指定すると、サプリメンタル・ロギングが必要になります。

- 取得プロセスのサブセット・ルール

- 取得プロセスで取得されたLCRを伝播する伝播のサブセット・ルール

- 取得プロセスで取得されたLCRを適用する適用プロセスのサブセット・ルール

いずれの場合も、サブセット条件に含まれるすべての列と、これらの変更を適用する宛先データベースにある表のすべての列について、無条件のサプリメンタル・ログ・グループをソース・データベースに指定する必要があります。場合によっては、サブセット・ルールを指定すると、更新が挿入に変換されることがあり、このときに一部またはすべての列に補足情報が必要になることがあります。

たとえば、データベースdbs2.example.comでhr.locations表のpostal_code列に取得LCRを適用する適用プロセスにサブセット・ルールを指定する場合、この表に対する変更のソース・データベースがdbs1.example.comであれば、dbs2.example.comのhr.locations表に存在するすべての列、およびpostal_code列について、dbs1.example.comでサプリメンタル・ロギングを指定します(postal_code列が宛先データベースの表に存在しない場合も、このように指定します)。

注意:
サプリメンタル・ロギングが必要ないのは、サブセット・ルールが同期取得で使用されるときです。また、同期取得で取得されたLCRを処理する伝播や適用プロセスに関しても、サプリメンタル・ロギングは必要ありません。

関連項目:

- サプリメンタル・ロギングの詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- 「Oracle Streams環境内のサプリメンタル・ロギング」

サブセット・ルールを使用する際のガイドライン

次の各項では、サブセット・ルールを使用する際のガイドラインを示します。

- 取得のサブセット・ルールの使用(すべての宛先で変更のサブセットのみが必要な場合)

- 伝播または適用のサブセット・ルールの使用(一部の宛先でサブセットが必要な場合)

- サブセットの行LCRが適用される表がサブセット表であることの確認

取得のサブセット・ルールの使用(すべての宛先で変更のサブセットのみが必要な場合)

取得される変更のすべての宛先データベースで、表のサブセット条件を満たす行変更のみが必要な場合は、取得プロセスまたは同期取得でサブセット・ルールを使用します。この場合、取得プロセスまたは同期取得によって、表に対するDML変更のサブセットが取得され、1つ以上の伝播によってこれらの変更が行LCRの形式で1つ以上の宛先データベースに伝播されます。各宛先データベースでは、適用プロセスによって、すべての行が取得プロセスのサブセット・ルールのサブセット条件を満たしているサブセット表にこれらの行LCRが適用されます。どの宛先データベースでも、表に対して行われるすべてのDML変更が必要なわけではありません。ローカル取得プロセスまたは同期取得のサブセット・ルールを使用すると、ソース・データベースが実行されているサイトで、行の移行を実行するために追加のオーバーヘッドが発生します。

伝播または適用のサブセット・ルールの使用(一部の宛先でサブセットが必要な場合)

環境内の一部の宛先で、取得されるDML変更のサブセットのみが必要な場合は、伝播または適用プロセスでサブセット・ルールを使用します。このような環境の例を次に示します。

- 表に対するDML変更が取得される宛先データベースのほとんどで、これらの変更の別のサブセットが必要な場合

- 表に対するDML変更のうち、ほとんどの宛先データベースでは取得されたすべての変更が必要だが、一部の宛先データベースではこれらの変更のサブセットのみが必要な場合

このような環境では、取得プロセスまたは同期取得によって表に対する変更をすべて取得する必要があります。ただし、伝播および適用プロセスでサブセット・ルールを使用すると、宛先データベースのサブセット表が、取得されたDML変更の正しいサブセットのみを適用できます。

このような環境で伝播にサブセット・ルールを使用することを決定する場合、次の点を考慮します。

- ネットワークを介して伝播される行LCRの数が少ないため、ネットワーク通信量を削減できます。

- 伝播のソース・キューを含むサイトでは、行の移行を実行するためにオーバーヘッドが増加します。

このような環境で適用プロセスにサブセット・ルールを使用することを決定する場合、次の点を考慮します。

- 適用プロセスで使用されるキューには、サブセット表のすべての行LCRを含めることができます。有向ネットワーク環境で伝播を実行すると、適用プロセスによる行LCRの適用の有無に関係なく、必要に応じて表の任意の行LCRを宛先キューに伝播できます。

- 適用プロセスが実行されているサイトでは、行の移行を実行するためにオーバーヘッドが増加します。

サブセットの行LCRが適用される表がサブセット表であることの確認

行の移行によって変換された行LCRが、適用プロセスによって適用される可能性がある場合は、宛先データベースの表を、各行がサブセット・ルールの条件に適合するサブセット表にすることをお薦めします。表がこのようなサブセット表でない場合、適用エラーが発生する可能性があります。

たとえば、取得プロセスのサブセット・ルールに、hr.employees表のDML変更に関してdepartment_id = 50という条件がある場合を考えます。この取得プロセスの宛先データベースのhr.employees表に、部門50のみでなく全部門の従業員の行が含まれていると、適用中に制約違反が発生する可能性があります。

1. ソース・データベースで、DML変更によってhr.employees表が更新され、employee_idが100である従業員のdepartment_idが90から50に変更されます。

2. サブセット・ルールを使用する取得プロセスが変更を取得し、更新を挿入に変換して、変更を行LCRとして取得プロセスのキューにエンキューします。

3. 伝播によって、行LCRが変更されずに宛先データベースに伝播されます。

4. 適用プロセスでは、宛先データベースで挿入としての行LCRの適用が試行されますが、employee_idが100の従業員はすでにhr.employees表に存在するため、適用エラーが発生します。

この場合、宛先データベースの表がhr.employees表のサブセットで、department_idが50である従業員の行のみが含まれていれば、挿入は正常に適用されます。

同様に、行の移行によって変換された行LCRが適用プロセスで表に適用される可能性があり、ユーザーまたはアプリケーションによる表のDML操作を許可する場合は、すべてのDML変更がサブセット条件を満たすようにすることをお薦めします。表に対するローカル変更を許可すると、適用プロセスでは表のすべての行がサブセット条件を満たしていることを確認できません。たとえば、hr.employees表の条件がdepartment_id = 50であるとします。department_idが30である従業員の行をユーザーまたはアプリケーションが挿入した場合、この行は表に残り、適用プロセスでは削除されません。同様に、ユーザーまたはアプリケーションが行をローカルに更新してdepartment_idを30に変更した場合、この行も表に残ります。

メッセージ・ルール

ルールを使用して、LCR以外の特定のメッセージ・タイプのユーザー・メッセージのみに関連するOracle Streamsタスクを実行する場合は、メッセージ・ルールを指定します。メッセージ・ルールは、伝播、適用プロセスおよびメッセージ・クライアントに指定できます。

伝播の場合、ポジティブ・ルール・セットに1つのメッセージ・ルールを含めると、ソース・キュー内のルール条件を満たすメッセージ・タイプのユーザー・メッセージを伝播します。また、ネガティブ・ルール・セットに1つのメッセージ・ルールを含めると、ソース・キュー内のルール条件を満たすメッセージ・タイプのユーザー・メッセージを廃棄します。

適用プロセスの場合、ポジティブ・ルール・セットに1つのメッセージ・ルールを含めると、ルール条件を満たすメッセージ・タイプのユーザー・メッセージをデキューします。これらのユーザー・メッセージは適用プロセスのメッセージ・ハンドラに送信されます。また、ネガティブ・ルール・セットに1つのメッセージ・ルールを含めると、キュー内のルール条件を満たすメッセージ・タイプのユーザー・メッセージを廃棄します。

メッセージ・クライアントの場合、ポジティブ・ルール・セットに1つのメッセージ・ルールを含めると、ユーザーまたはアプリケーションはメッセージ・クライアントを使用して、ルール条件を満たすメッセージ・タイプのユーザー・メッセージをデキューできます。また、ネガティブ・ルール・セットに1つのメッセージ・ルールを含めると、キュー内のルール条件を満たすメッセージ・タイプのユーザー・メッセージを廃棄します。伝播および適用プロセスでは実行時にメッセージが自動的に伝播または適用されるのに対して、メッセージ・クライアントではメッセージは自動的にデキューまたは廃棄されません。メッセージをデキューまたは廃棄するためには、ユーザーまたはアプリケーションがメッセージ・クライアントを起動する必要があります。

メッセージ・ルールの例

DBMS_STREAMS_ADMパッケージのADD_MESSAGE_RULEプロシージャを使用して、Oracle Streamsクライアントの動作を次のように指示する場合を考えます。

- 地域がEUROPEで優先度が1である場合のユーザー・メッセージのデキュー

- 地域がAMERICASで優先度が2である場合のメッセージ・ハンドラへのユーザー・メッセージの送信

前述の1つ目の指示はメッセージ・クライアントに関連し、2つ目の指示は適用プロセスに関連します。

これらの例では、次のようなメッセージに関するルールを作成します。

CREATE TYPE strmadmin.region_pri_msg AS OBJECT(
region         VARCHAR2(100),
priority       NUMBER,
message        VARCHAR2(3000))
/

地域がEUROPEで優先度が1である場合のユーザー・メッセージのデキュー

ADD_MESSAGE_RULEプロシージャを実行して、region_pri_msgタイプのメッセージに対するルールを作成します。

BEGIN
DBMS_STREAMS_ADM.ADD_MESSAGE_RULE (
message_type    =>  'strmadmin.region_pri_msg',
rule_condition  =>  ':msg.region = ''EUROPE'' AND  ' ||
':msg.priority = ''1'' ',
streams_type    =>  'dequeue',
streams_name    =>  'msg_client',
queue_name      =>  'streams_queue',
inclusion_rule  =>  TRUE);
END;
/

streams_typeパラメータにdequeueが指定されていることに注意してください。つまり、msg_clientという名前のメッセージ・クライアントが存在しなければ、このプロシージャによって作成されます。このメッセージ・クライアントがすでに存在する場合は、このプロシージャによってメッセージ・ルールがそのルール・セットに追加されます。また、inclusion_ruleパラメータがTRUEに設定されていることにも注意してください。この設定によって、システム作成ルールがメッセージ・クライアントのポジティブ・ルール・セットに追加されます。このプロシージャを実行するユーザーには、メッセージ・クライアントを使用してキューからデキューする権限が付与されます。

ADD_MESSAGE_RULEプロシージャによって、次のようなルール条件のあるルールが作成されます。

:"VAR$_52".region = 'EUROPE' AND  :"VAR$_52".priority = '1'

ルール条件内のVAR$で始まる変数は、ルールのシステム生成評価コンテキストで指定される変数です。

関連項目:
「Oracle Streamsで使用される評価コンテキスト」

地域がAMERICASで優先度が 2である場合のメッセージ・ハンドラへのユーザー・メッセージの送信

ADD_MESSAGE_RULEプロシージャを実行して、region_pri_msgタイプのメッセージに対するルールを作成します。

BEGIN
DBMS_STREAMS_ADM.ADD_MESSAGE_RULE (
message_type    =>  'strmadmin.region_pri_msg',
rule_condition  =>  ':msg.region = ''AMERICAS'' AND  ' ||
':msg.priority = ''2'' ',
streams_type    =>  'apply',
streams_name    =>  'apply_msg',
queue_name      =>  'streams_queue',
inclusion_rule  =>  TRUE);
END;
/

streams_typeパラメータにapplyが指定されていることに注意してください。つまり、apply_msgという名前の適用プロセスが存在しなければ、このプロシージャによって作成されます。この適用プロセスがすでに存在する場合は、このプロシージャによってメッセージ・ルールがそのルール・セットに追加されます。また、inclusion_ruleパラメータがTRUEに設定されていることにも注意してください。この設定によって、システム作成ルールがメッセージ・クライアントのポジティブ・ルール・セットに追加されます。

ADD_MESSAGE_RULEプロシージャによって、次のようなルール条件のあるルールが作成されます。

:"VAR$_56".region = 'AMERICAS' AND  :"VAR$_56".priority = '2'

ルール条件内のVAR$で始まる変数は、ルールのシステム生成評価コンテキストで指定される変数です。

関連項目:
「Oracle Streamsで使用される評価コンテキスト」

ルールのまとめ

この例では、次のメッセージ・ルールが定義されています。

- メッセージの地域がEUROPE、優先度が1の場合にTRUEと評価される、msg_clientという名前のメッセージ・クライアントのメッセージ・ルール。このルールが指定されている場合、ユーザーまたはアプリケーションはこのメッセージ・クライアントを使用して、ルール条件を満たすregion_pri_msgタイプのメッセージをデキューできます。

- メッセージの地域がAMERICAS、優先度が2の場合にTRUEと評価される、apply_msgという名前の適用プロセスのメッセージ・ルール。このルールが指定されている場合、ルール条件を満たすregion_pri_msgタイプのメッセージが適用プロセスによってデキューされ、これらのメッセージがメッセージ・ハンドラに送信されるか、指定されたキューに再エンキューされます。

関連項目:

- 「メッセージ・ハンドラ」

- 「適用時のメッセージのエンキューの宛先」

システム作成ルールとネガティブ・ルール・セット

システム作成ルールをネガティブ・ルール・セットに追加すると、ルールを満たす変更に対してOracle Streamsクライアントがタスクを実行しないように指定することになります。システム作成ルールがネガティブ・ルール・セットに含まれる場合、各タイプのOracle Streamsクライアントは具体的には次のように動作します。

- 取得プロセスは、ルールを満たす変更を廃棄します。

- 伝播は、ルールを満たすソース・キュー内のメッセージを廃棄します。

- 適用プロセスは、ルールを満たすキュー内のメッセージを廃棄します。

- メッセージ・クライアントは、ルールを満たすキュー内のメッセージを廃棄します。

注意:
同期取得にはネガティブ・ルール・セットを関連付けることができません。

Oracle Streamsクライアントにネガティブ・ルール・セットが存在する場合、次のいずれかのプロシージャを実行してinclusion_ruleパラメータをFALSEに設定すると、ネガティブ・ルール・セットを作成してルールを追加できます。

- DBMS_STREAMS_ADM.ADD_TABLE_RULES

- DBMS_STREAMS_ADM.ADD_SCHEMA_RULES

- DBMS_STREAMS_ADM.ADD_GLOBAL_RULES

- DBMS_STREAMS_ADM.ADD_MESSAGE_RULE

- DBMS_STREAMS_ADM.ADD_TABLE_PROPAGATION_RULES

- DBMS_STREAMS_ADM.ADD_SCHEMA_PROPAGATION_RULES

- DBMS_STREAMS_ADM.ADD_GLOBAL_PROPAGATION_RULES

- DBMS_STREAMS_ADM.ADD_MESSAGE_PROPAGATION_RULE

Oracle Streamsクライアントにすでにネガティブ・ルール・セットが存在している場合に、このいずれかのプロシージャを実行すると、プロシージャによってシステム作成ルールが既存のネガティブ・ルール・セットに追加されます。

また、次のいずれかのプロシージャを実行してnegative_rule_set_nameパラメータにNULL以外の値を指定すると、Oracle Streamsクライアントの作成時にネガティブ・ルール・セットを作成することもできます。

- DBMS_CAPTURE_ADM.CREATE_CAPTURE

- DBMS_PROPAGATION_ADM.CREATE_PROPAGATION

- DBMS_APPLY_ADM.CREATE_APPLY

また、クライアントを変更することで、既存のOracle Streamsクライアントにネガティブ・ルール・セットを指定することもできます。たとえば、既存の取得プロセスにネガティブ・ルール・セットを指定するには、DBMS_CAPTURE_ADM.ALTER_CAPTUREプロシージャを使用します。Oracle Streamsクライアントにネガティブ・ルール・セットを指定した後、前述のDBMS_STREAMS_ADMパッケージのプロシージャを使用して、ネガティブ・ルール・セットにシステム作成ルールを追加できます。

ネガティブ・ルール・セットにルールを追加するかわりに、次のように、特定の表またはスキーマに対する変更を除外することもできます。

- 該当する表またはスキーマのシステム作成ルールを、Oracle Streamsクライアントのポジティブ・ルール・セットに追加しないようにします。たとえば、特定のスキーマに存在する1つの表を除くすべての表に対するDML変更を取得するには、除外する表以外のスキーマの各表に対するDML表ルールを、取得プロセスのポジティブ・ルール・セットに追加します。この方法のデメリットは、スキーマに多くの表が存在する場合にも各表に個別のDMLルールが必要であるという点です。また、スキーマに新規の表を追加して、その表に対する変更を取得する場合は、この表のための新規DMLルールを取得プロセスのポジティブ・ルール・セットに追加する必要があります。

- Oracle Streamsクライアントのポジティブ・ルール・セットに複合ルールを追加し、そのルール条件でNOT論理条件を使用します。たとえば、特定のスキーマに存在する1つの表を除くすべての表に対するDML変更を取得するには、DBMS_STREAMS_ADM.ADD_SCHEMA_RULESプロシージャを使用して、そのスキーマに対する変更を取得するように取得プロセスに指示するシステム作成DMLスキーマ・ルールを取得プロセスのポジティブ・ルール・セットに追加し、and_conditionパラメータを使用して、該当の表をNOT論理条件で除外します。この方法のデメリットは、ルール条件の一部を手動で指定するため、ミスが発生する可能性があるという点です。また、変更を加えないシステム作成ルールに比べて、複合ルールに対するルール評価は効率的に実行できません。

特定のスキーマに存在する1つの表を除くすべての表に対するDML変更を取得する場合は、取得プロセスのポジティブ・ルール・セットにDMLスキーマ・ルールを追加し、除外する表に対するDML表ルールをネガティブ・ルール・セットに追加できます。

この方法には、前述した方法と比べると次のようなメリットがあります。

- 2つのルールを追加するのみで目標を達成できます。

- スキーマに新規の表を追加して、その表に対するDML変更を取得する場合も、既存のルールの変更または新規ルールの追加を行わずに、取得プロセスによってこれらの変更を取得できます。

- ルール条件を手動で指定または編集する必要がありません。

- 複合ルールを使用しないため、ルール評価をより効率的に実行できます。

関連項目:

- 「複合ルール条件」

- 「システム作成ルールへのユーザー定義条件の追加」

ネガティブ・ルール・セットの例

job_history表を除き、hrスキーマ内のすべての表に対するDML変更の結果を含む行LCRを適用する場合を考えます。これを行うには、DBMS_STREAMS_ADMパッケージのADD_SCHEMA_RULESプロシージャを使用して、hrスキーマ内の表に対するDML変更の結果を含む行LCRを適用するように、Oracle Streamsの適用プロセスに指示します。この場合、プロシージャによってスキーマ・ルールが作成され、適用プロセスのポジティブ・ルール・セットに追加されます。

DBMS_STREAMS_ADMパッケージのADD_TABLE_RULESプロシージャを使用すると、表に対するDML変更の結果を含む行LCRをhr.job_history表では廃棄するように、Oracle Streamsに指示できます。この場合、プロシージャによって表ルールが作成され、適用プロセスのネガティブ・ルール・セットに追加されます。

次の各項では、これらのプロシージャの実行方法について説明します。

- hrスキーマの表に対するすべてのDML変更の適用

- hr.job_history表に対するDML変更を含む行LCRの廃棄

hrスキーマの表に対するすべてのDML変更の適用

これらの変更は、dbs1.example.comソース・データベースで発生しています。

ADD_SCHEMA_RULESプロシージャを実行して次のルールを作成します。

BEGIN
DBMS_STREAMS_ADM.ADD_SCHEMA_RULES(
schema_name         =>  'hr',
streams_type        =>  'apply',
streams_name        =>  'apply',
queue_name          =>  'streams_queue',
include_dml         =>  TRUE,
include_ddl         =>  FALSE,
include_tagged_lcr  =>  FALSE,
source_database     =>  'dbs1.example.com',
inclusion_rule      =>  TRUE);
END;
/

inclusion_ruleパラメータがTRUEに設定されていることに注意してください。この設定によって、システム作成ルールが適用プロセスのポジティブ・ルール・セットに追加されます。

ADD_SCHEMA_RULESプロシージャによって、次のようなルール条件のあるルールが作成されます。

((:dml.get_object_owner() = 'HR') and :dml.is_null_tag() = 'Y'
and :dml.get_source_database_name() = 'DBS1.EXAMPLE.COM' )

hr.job_history表に対するDML変更を含む行LCRの廃棄

これらの変更がdbs1.example.comソース・データベースで発生しました。

ADD_TABLE_RULESプロシージャを実行して次のルールを作成します。

BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
table_name          =>  'hr.job_history',
streams_type        =>  'apply',
streams_name        =>  'apply',
queue_name          =>  'streams_queue',
include_dml         =>  TRUE,
include_ddl         =>  FALSE,
include_tagged_lcr  =>  TRUE,
source_database     =>  'dbs1.example.com',
inclusion_rule      =>  FALSE);
END;
/

inclusion_ruleパラメータがFALSEに設定されていることに注意してください。この設定によって、システム作成ルールが適用プロセスのネガティブ・ルール・セットに追加されます。

また、include_tagged_lcrパラメータがTRUEに設定されていることにも注意してください。この設定によって、表に対するすべての変更(他のすべてのルール条件を満たすタグ付きLCRを含む)が廃棄されます。ほとんどの場合、inclusion_ruleパラメータがFALSEに設定されているときは、include_tagged_lcrパラメータにTRUEを指定します。

ADD_TABLE_RULESプロシージャによって、次のようなルール条件のあるルールが作成されます。

(((:dml.get_object_owner() = 'HR' and :dml.get_object_name() = 'JOB_HISTORY'))
and :dml.get_source_database_name() = 'DBS1.EXAMPLE.COM' )

ルールのまとめ

この例では、次のルールが定義されています。

- hrスキーマの表に対してDML操作が実行された場合にTRUEと評価されるスキーマ・ルール。このルールは適用プロセスのポジティブ・ルール・セットに含まれます。

- hr.job_history表に対してDML操作が実行された場合にTRUEと評価される表ルール。このルールは適用プロセスのネガティブ・ルール・セットに含まれます。

これらのルールを使用した場合に適用プロセスによって適用される変更の例を次に示します。

- hr.departments表への1行の挿入

- hr.employees表内の5行の更新

- hr.countries表からの1行の削除

適用プロセスによって、これらの変更がその関連キューからデキューされ、宛先データベースのデータベース・オブジェクトに適用されます。

これらのルールを使用した場合に適用プロセスによって無視される変更の例を次に示します。

- hr.job_history表への1行の挿入

- hr.job_history表内の1行の更新

- hr.job_history表からの1行の削除

これらの変更は、適用プロセスのネガティブ・ルール・セットのルールを満たすため適用されません。

関連項目:
「ルール・セットおよびメッセージのルール評価」

システム作成ルールへのユーザー定義条件の追加

DBMS_STREAMS_ADMパッケージのプロシージャには、and_conditionパラメータを使用してルールを作成するものがあります。このパラメータを使用すると、システム作成ルールに条件を追加できます。and_conditionパラメータによって指定される条件は、次のようにAND句を使用してシステム作成ルール条件に追加されます。

(system_condition) AND (and_condition)

指定する条件内の変数は:lcrである必要があります。たとえば、表がhr.departments、ソース・データベースがdbs1.example.com、Oracle Streamsタグが02に等しい16進数の場合にのみ、ADD_TABLE_RULESプロシージャによって生成される表ルールがTRUEと評価されるよう指定するには、次のプロシージャを実行します。

BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
table_name          =>  'hr.departments',
streams_type        =>  'apply',
streams_name        =>  'apply_02',
queue_name          =>  'streams_queue',
include_dml         =>  TRUE,
include_ddl         =>  TRUE,
include_tagged_lcr  =>  TRUE,
source_database     =>  'dbs1.example.com',
inclusion_rule      =>  TRUE,
and_condition       =>  ':lcr.get_tag() = HEXTORAW(''02'')');
END;
/

ADD_TABLE_RULESプロシージャによって、次の条件のあるDMLルールが作成されます。

(((((:dml.get_object_owner() = 'HR' and :dml.get_object_name() = 'DEPARTMENTS'))
and :dml.get_source_database_name() = 'DBS1.EXAMPLE.COM' ))
and (:dml.get_tag() = HEXTORAW('02')))

次の条件のあるDDLルールが作成されます。

(((((:ddl.get_object_owner() = 'HR' and :ddl.get_object_name() = 'DEPARTMENTS')
or (:ddl.get_base_table_owner() = 'HR'
and :ddl.get_base_table_name() = 'DEPARTMENTS'))
and :ddl.get_source_database_name() = 'DBS1.EXAMPLE.COM' ))
and (:ddl.get_tag() = HEXTORAW('02')))

指定された条件の:lcrが、生成されるルールに応じて:dmlまたは:ddlに変換されることに注意してください。LCRタイプ(行またはDDL)に依存するLCRメンバー・サブプログラムを指定する場合は、このプロシージャによって適切なルールのみが作成されることを確認します。特に、行LCRに対してのみ有効なLCRメンバー・サブプログラムを指定する場合は、include_dmlパラメータにTRUE、include_ddlパラメータにFALSEを指定します。DDL LCRのみに対して有効なLCRメンバー・サブプログラムを指定する場合は、include_dmlパラメータにFALSE、include_ddlパラメータにTRUEを指定します。

たとえば、GET_OBJECT_TYPEメンバー・ファンクションはDDL LCRのみに適用されます。したがって、and_conditionでこのメンバー・ファンクションを使用する場合は、include_dmlパラメータにFALSE、include_ddlパラメータにTRUEを指定します。

関連項目:

- LCRメンバー・サブプログラムの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

- Oracle Streamsタグの詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

6 ルールベースの変換

ルールベースの変換は、ポジティブ・ルール・セットのルールがTRUEに評価される場合に発生するメッセージへの変更です。ルールベースの変換には、宣言とカスタムという2つのタイプがあります。

次の各項では、ルールベースの変換について説明します。

- 宣言ルールベースの変換

- カスタム・ルールベースの変換

- ルールベースの変換およびOracle Streamsクライアント

- 変換の順序

- ルールベースの変換に関する考慮事項

関連項目:

- 第19章「ルールベースの変換の管理」

- 第28章「ルールベースの変換の監視」

- 第34章「ルールおよびルールベースの変換のトラブルシューティング」

宣言ルールベースの変換

宣言ルールベース変換は、行LCRに対する共通の変換シナリオ・セットを扱います。

DBMS_STREAMS_ADMパッケージに含まれる次のいずれかのプロシージャを使用して変換を指定(宣言)します。

- ADD_COLUMN: 行LCRに列を追加する宣言変換を追加または削除します。

- DELETE_COLUMN: 行LCRから列を削除する宣言変換を追加または削除します。

- KEEP_COLUMNS: 行LCRの列のリストを保持する宣言変換を追加または削除します。リストに含まれない列は行LCRから削除されます。

- RENAME_COLUMN: 行LCRの列名を変更する宣言変換を追加または削除します。

- RENAME_SCHEMA: 行LCRのスキーマ名を変更する宣言変換を追加または削除します。

- RENAME_TABLE: 行LCRの表名を変更する宣言変換を追加または削除します。

宣言ルールベース変換を指定する場合、宣言ルールベース変換に関連付けられたルールを指定します。指定したルールが行LCRに関してTRUEと評価されると、Oracle Streamsによって、行LCRに対する宣言変換が内部的に実行されます。このとき、PL/SQLは起動されません。

宣言ルールベースの変換には次のメリットがあります。

- 変換が内部的に実行され、PL/SQLを使用しないため、パフォーマンスが改善されます。

- カスタムPL/SQLファンクションが不要なため複雑になりません。

注意:
宣言ルールベースの変換で変換できるのは行LCRのみです。この行LCRは、取得LCRまたは永続LCRです。このため、いずれかのプロシージャを実行して宣言変換を追加するときはDMLルールを指定する必要があります。DDLルールを指定すると、エラーが発生します。

関連項目:

- 「宣言ルールベースの変換の管理」

- 「宣言ルールベースの変換ではサポートされていないデータ型」

- 「行LCR」

- データ型の詳細は、『Oracle Database SQL言語リファレンス』を参照

カスタム・ルールベース変換

カスタム・ルールベースの変換では、変換を実行するユーザー定義PL/SQLファンクションが必要です。このファンクションは、入力としてメッセージを含むANYDATAオブジェクトを取り、変換済メッセージを含むANYDATAオブジェクト、または0(ゼロ)個以上のANYDATAメッセージをカプセル化した配列のいずれかを戻します。1つのメッセージを戻すカスタム・ルールベースの変換ファンクションは、1対1の変換ファンクションです。配列で2つ以上のメッセージを戻すことができるカスタム・ルールベースの変換ファンクションは、1対多の変換ファンクションです。1対1の変換ファンクションはすべてのタイプのOracle Streamsクライアントでサポートされますが、1対多の変換ファンクションがサポートされるのはOracle Streamsの取得プロセスと同期取得のみです。

カスタム・ルールベースの変換を指定するには、DBMS_STREAMS_ADM.SET_RULE_TRANSFORM_FUNCTIONプロシージャを使用します。カスタム・ルールベースの変換を使用して、取得LCR、永続LCRおよび永続ユーザー・メッセージを変更できます。

たとえば、カスタム・ルールベースの変換は、表の特定の列のデータ型が2つのデータベースで異なる場合に使用できます。ある列がソース・データベースではNUMBER列、宛先データベースではVARCHAR2列という場合があります。この場合、変換は、列がNUMBERデータ型の行LCRを含むANYDATAオブジェクトを入力として取り、同じ列がVARCHAR2データ型の行LCRを含むANYDATAオブジェクトを返します。

メッセージに対するカスタム変換のその他の例を次に示します。

- 列を複数列に分割する場合

- 複数列から1列に結合する場合

- 列の内容を変更する場合

- ユーザー・メッセージのペイロードを変更する場合

カスタム・ルールベースの変換には次のメリットがあります。

- PL/SQLを使用してカスタム変換を実行できるため柔軟性が増します。

- 行LCRのみでなくDDL LCRやユーザー・メッセージなど様々なメッセージを変換できます。

カスタム・ルールベースの変換では次の点に注意してください。

- DDL LCRに対してカスタム・ルールベースの変換を実行するときは、他の変更と一致するようにDDL LCRのDDLテキストの変更が必要になる場合があります。たとえば、DDL LCRの表の名前をルールベースの変換で変更する場合は、DDLテキストの表名も変換によって同じように変更することが必要です。

- 可能であれば、ルールがTRUEと評価される比較的少数のLCRを変換する場合は、グローバル・ルールまたはスキーマ・ルールにカスタム・ルールベースの変換を指定しないでください。たとえば、1つの表を処理するカスタム・ルールベースの変換をスキーマ・ルールに指定したとき、このスキーマに数百の表が含まれることがあります。このようなルールベースの変換を指定すると、変換されないLCRに関して余分な処理が必要になるためパフォーマンスに影響します。
このようなカスタム・ルールベース変換の指定を回避するには、プロシージャDMLハンドラを使用して変換を実行するか、グローバル・ルールやスキーマ・ルールではなく表ルールに変換を指定してください。ただし、グローバル・ルールまたはスキーマ・ルールを表ルールで置き換えると、ルールの合計数が増え、表の追加時のメンテナンス操作が増加します。

- 1対1変換ファンクションを使用するカスタム・ルールベースの変換では、取得LCRまたは永続LCRを受け取ると、新しいLCRを作成して返すことができます。同様に、1対多変換ファンクションを使用するカスタム・ルールベースの変換では、取得LCRまたは永続LCRを受け取ると、複数の新しいLCRを作成して配列として返すことができます。
カスタム・ルールベースの変換で作成されて返されるすべてのLCRでは、source_database_name、transaction_idおよびscnパラメータ値が元のLCRの値と一致する必要があります。異なる値のLCRを作成しようとしても、Oracleによってこれらのパラメータには元のLCRの値が自動的に指定されます。

- ユーザー・メッセージを受け取るカスタム・ルールベースの変換では、新しいメッセージを作成して返すことができます。この場合、返されるメッセージは、カスタム・ルールベースの変換で作成されるLCRです。

- カスタム・ルールベースの変換では、LCRをLCR以外のメッセージに変換することはできません。この制限は、取得LCRおよび永続LCRに適用されます。

- カスタム・ルールベースの変換では、行LCRをDDL LCRに、またはDDL LCRを行LCRに変換することはできません。この制限は、取得LCRおよび永続LCRに適用されます。

関連項目:

- 「カスタム・ルールベースの変換に必須の権限」

- 「カスタム・ルールベースの変換の管理」

- 「カスタム・ルールベースの変換ではサポートされていないデータ型」

- 「Oracle Streamsでのルールの使用方法」

- 「適用プロセスで処理できるメッセージのタイプ」

- SET_RULE_TRANSFORM_FUNCTIONプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

- 「論理変更レコード(LCR)」

カスタム・ルールベースの変換およびアクション・コンテキスト

DBMS_STREAMS_ADMパッケージのSET_RULE_TRANSFORM_FUNCTIONプロシージャを使用して、ルールのカスタム・ルールベースの変換を指定します。このプロシージャは、ルールのアクション・コンテキストを変更して、変換を指定します。ルール・アクション・コンテキストはルールに関連付けられたオプションの情報であり、メッセージのルールがTRUEと評価された後でルール・エンジンのクライアントによって解析されます。ルール・エンジンのクライアントは、ユーザー作成アプリケーション、またはOracle StreamsなどのOracleの内部機能です。アクション・コンテキストの情報は、名前/値ペアのリストで構成されるSYS.RE$NV_LIST型のオブジェクトです。

Oracle Streamsのカスタム・ルール変換は常に、アクション・コンテキストの次の名前/値ペアで構成されます。

- ファンクションが1対1変換ファンクションである場合、名前はSTREAMS$_TRANSFORM_FUNCTIONになります。ファンクションが1対多変換ファンクションである場合、名前はSTREAMS$_ARRAY_TRANS_FUNCTIONになります。

- 値は、VARCHAR2と指定されたPL/SQLファンクション名を含むANYDATAインスタンスです。このファンクションは、次の変換を実行します。

データベース内の既存のカスタム・ルールベースの変換は、DBA_STREAMS_TRANSFORM_FUNCTIONデータ・ディクショナリ・ビューを問い合せることで表示できます。

Oracle Streams環境で、ポジティブ・ルール・セットのルールで、メッセージがTRUEと評価され、名前がSTREAMS$_TRANSFORM_FUNCTIONまたはSTREAMS$_ARRAY_TRANS_FUNCTIONである名前/値のペアを含むアクション・コンテキストが返されると、メッセージを入力パラメータとして使用してPL/SQLファンクションが実行されます。アクション・コンテキスト内の、STREAMS$_で始まるその他の名前は、Oracleによって内部的に使用されるため、直接追加、変更または削除することはできません。Oracle Streamsは、STREAMS$_またはAPPLY$_で始まらない名前/値ペアをすべて無視します。

Oracle Streams環境で、ルールによってメッセージがFALSEと評価されると、このルールはクライアントに返されず、アクション・コンテキストの名前/値ペアに表示されるPL/SQLファンクションは実行されません。様々なルールに同じ変換または異なる変換を使用できます。たとえば、メッセージの取得、伝播、適用またはデキュー対象となる様々な操作タイプ、表またはスキーマに、異なる変換を関連付けることができます。

カスタム・ルールベースの変換に必須の権限

変換ファンクションをコールするユーザーは、ファンクションのEXECUTE権限が必要です。変換ファンクションをコールするユーザーを次に示します。

- 取得プロセスで使用されるルールで変換が指定されている場合、取得プロセスの取得ユーザーが変換ファンクションをコールします。

- 同期取得で使用されるルールで変換が指定されている場合、同期取得の取得ユーザーが変換ファンクションをコールします。

- 伝播で使用されるルールで変換が指定されている場合、伝播のソース・キューの所有者が変換ファンクションをコールします。

- 適用プロセスで使用されるルールで変換が指定されている場合、適用プロセスの適用ユーザーが変換ファンクションをコールします。

- メッセージ・クライアントで使用されるルールで変換が指定されている場合、メッセージ・クライアントを起動するユーザーが変換ファンクションをコールします。

関連項目:

- 第19章「ルールベースの変換の管理」

- 第2章「Oracle Streams情報取得」

- 第3章の「キュー間でのメッセージの伝播」

- 第4章「Oracle Streams情報コンシューム」

ルールベースの変換およびOracle Streamsクライアント

次の各項では、ルールベースの変換とOracle Streamsクライアントについて説明します。

- ルールベースの変換と取得プロセス

- ルールベースの変換と同期取得

- ルールベースの変換と伝播

- ルールベースの変換と適用プロセス

- ルールベースの変換とメッセージ・クライアント

- 複数のルールベース変換

この項の情報は、宣言ルールベースの変換とカスタム・ルールベースの変換の両方に該当します。

関連項目:

- 第19章「ルールベースの変換の管理」

- 「ルール・アクション・コンテキスト」

- 「適用プロセスで処理できるメッセージのタイプ」

ルールベースの変換と取得プロセス

取得プロセスによって取得中に変換を実行する場合は、REDOログの特定の変更に対して、取得プロセスのポジティブ・ルール・セット内のルールベースの変換に対応するルールがTRUEと評価される必要があります。

宣言ルールベースの変換の場合は、メッセージに対してポジティブ・ルール・セットのルールがTRUEと評価されると、取得LCRが内部的に変換されます。カスタム・ルールベースの変換の場合は、取得LCRに対してポジティブ・ルール・セットのルールがTRUEと評価されると、STREAMS$_TRANSFORM_FUNCTIONまたはSTREAMS$_ARRAY_TRANS_FUNCTIONという名前の名前/値ペアを含むアクション・コンテキストが取得プロセスに返されます。

取得プロセスは、次の手順でルールベースの変換を実行します。

1. REDOログ内の変更をLCRにフォーマットします。

2. LCRをANYDATAオブジェクトに変換します。

3. LCRを変換します。宣言ルールベースの変換の場合は、宣言変換の指定に基づいてANYDATAオブジェクトが内部的に変換されます。カスタム・ルールベースの変換の場合は、取得プロセスの取得ユーザーが名前/値ペアのPL/SQLファンクションを実行してANYDATAオブジェクトを変換します。

4. 変換された1つ以上のANYDATAオブジェクトを、取得プロセスに関連付けられたキューにエンキューします。または、要素が0個の配列が変換ファンクションで返される場合はLCRを廃棄します。

すべてのアクションが、取得プロセスの取得ユーザーによって実行されます。図6-1は、取得プロセスによる取得中の変換を示しています。

図6-1 取得プロセスによる取得中の変換

たとえば、LCRが取得プロセスによって取得中に変換される場合、変換済LCRは、取得プロセスで使用されるキューにエンキューされます。このため、このような取得LCRがdbs1.example.comデータベースからdbs2.example.comデータベースとdbs3.example.comデータベースに伝播される場合は、伝播の後でdbs2.example.comとdbs3.example.comのキューに変換済LCRが含まれます。

取得プロセスによって取得中に変換を実行すると次のメリットがあります。

- プライベート情報はソース・キューに入れられず宛先キューにも伝播されないため、変換によってプライベート情報を削除または変更することができ、セキュリティを向上できます。

- 実行する変換のタイプによっては、領域消費を削減できます。たとえば、変換でデータ容量を削減すると、エンキュー、伝播および適用するデータが減少します。

- 変換済LCRに複数の宛先がある場合、変換は複数の宛先ではなくソース側で1回しか実行されないため、変換によるオーバーヘッドが減少します。

- 取得プロセスの変換では、1つのメッセージを複数のメッセージに変換することができます。

取得プロセスによって取得中に変換を実行する場合に考えられるデメリットは、次のとおりです。

- 取得プロセスがローカル取得プロセスである場合、変換によるオーバーヘッドがソース・データベースで発生します。ただし、取得プロセスがダウンストリーム取得プロセスである場合、このオーバーヘッドはソース・データベースではなくダウンストリーム・データベースで発生します。

- すべてのサイトで変換済LCRが受信されます。

注意:
取得プロセスでルールベースの変換を使用して、Oracle Streamsでサポートされないデータ型の列を変更または削除することはできません。

関連項目:

- 「取得プロセスによって取得されるデータ型」

- 「ルールベースの変換の管理」

取得プロセスによる取得中のルールベースの変換のエラー

取得プロセスの動作は、実行される変換の種類と発生したエラーの種類によって次のいずれかになります。取得プロセスの動作は、実行中の変換のタイプと、発生したエラーのタイプによって異なります。取得プロセスには次のいずれかの動作が考えられます。

- 変換が宣言ルールベースの変換で、取得プロセスがエラーを無視できる場合、取得プロセスは変換を実行して変更を取得します。たとえば、取得プロセスがDELETE_COLUMN宣言ルールベースの変換を実行しようとしたときに、削除対象として指定された列が行LCRに存在しない場合、取得プロセスは変更を取得して実行を続けます。

- 変換が宣言ルールベースの変換で、取得プロセスがエラーを無視できない場合、変更は取得されず、取得プロセスが無効になります。たとえば、取得プロセスがADD_COLUMN宣言ルールベースの変換を実行しようとしたときに、追加対象として指定された列がすでに行LCRに存在していた場合、変更は取得されず、取得プロセスが無効になります。

- カスタム・ルールベースの変換でエラーが発生した場合は、常に、変更は取得されず、取得プロセスが無効になります。

取得プロセスが無効になった場合は、エラーが発生しないようにルールベースの変換を変更または削除してから、取得プロセスを有効にしてください。

ルールベースの変換と同期取得

同期取得によって取得中に変換を実行する場合は、同期取得のポジティブ・ルール・セットのルールベースの変換に対応するルールが、表に対する特定のDML変更について、TRUEと評価される必要があります。

宣言ルールベースの変換の場合は、メッセージに対してポジティブ・ルール・セットのルールがTRUEと評価されると、永続LCRが内部的に変換されます。カスタム・ルールベースの変換の場合は、永続LCRに対してポジティブ・ルール・セットのルールがTRUEと評価されると、STREAMS$_TRANSFORM_FUNCTIONという名前の名前/値ペアを含むアクション・コンテキストが取得プロセスに返されます。

同期取得は、次の手順でルールベースの変換を実行します。

1. REDOログ内の変更を行LCRにフォーマットします。

2. 行LCRをANYDATAオブジェクトに変換します。

3. LCRを変換します。宣言ルールベースの変換の場合は、宣言変換の指定に基づいてANYDATAオブジェクトが内部的に変換されます。カスタム・ルールベースの変換の場合は、同期取得の取得ユーザーが名前/値ペアのPL/SQLファンクションを実行してANYDATAオブジェクトを変換します。

4. 変換されたANYDATAオブジェクトを、同期取得に関連付けられたキューにエンキューします。

すべてのアクションが、同期取得の取得ユーザーによって実行されます。図6-2は、取得中の変換を示しています。

図6-2 同期取得による取得中の変換

たとえば、行LCRが同期取得によって取得中に変換される場合、変換済行LCRは、同期取得で使用されるキューにエンキューされます。このため、このような取得LCRがdbs1.example.comデータベースからdbs2.example.comデータベースとdbs3.example.comデータベースに伝播される場合は、伝播の後でdbs2.example.comとdbs3.example.comのキューに変換済行LCRが含まれます。

同期取得によって取得中に変換を実行すると次のメリットがあります。

- プライベート情報はソース・キューに入れられず宛先キューにも伝播されないため、変換によってプライベート情報を削除または変更することができ、セキュリティを向上できます。

- 実行する変換のタイプによっては、領域消費を削減できます。たとえば、変換でデータ容量を削減すると、エンキュー、伝播および適用するデータが減少します。

- 変換済行LCRに複数の宛先がある場合、変換は複数の宛先ではなくソース側で1回しか実行されないため、変換によるオーバーヘッドが減少します。

同期取得によって取得中に変換を実行する場合に考えられるデメリットは、次のとおりです。

- ソース・データベースで、変換オーバーヘッドが発生します。

- すべてのサイトで変換済LCRが受信されます。

注意:
同期取得でルールベースの変換を使用して、Oracle Streamsでサポートされないデータ型の列を変更または削除することはできません。

関連項目:
同期取得によって取得されるデータ型

同期取得による取得中のルールベースの変換のエラー

同期取得によって取得中に変換が実行されるときにエラーが発生すると、エラーは同期取得に返されます。同期取得の動作は、実行中の変換のタイプと、発生したエラーのタイプによって異なります。同時取得には次のいずれかの動作が考えられます。

- 変換が宣言ルールベースの変換で、同期取得がエラーを無視できる場合、同期取得は変換を実行して変更を取得します。たとえば、同期取得がDELETE_COLUMN宣言ルールベースの変換を実行しようとしたときに、削除対象として指定された列が行LCRに存在しない場合、同期取得は変更を取得して実行を続けます。

- 変換が宣言ルールベースの変換で、同期取得がエラーを無視できない場合、変更は取得されず、DML操作は中断されます。たとえば、同期取得がADD_COLUMN宣言ルールベースの変換を実行しようとしたときに、追加対象として指定された列がすでに行LCRに存在していた場合、変更は取得されず、DMLは中断します。

- カスタム・ルールベースの変換でエラーが発生した場合は常に、変更は取得されず、DMLは中断します。

DMLがルールベースの変換によって中断した場合は、そのルールベースの変換を変更するか、または削除してDML操作を実行する必要があります。

ルールベースの変換と伝播

伝播中に変換を実行する場合は、伝播のソース・キューのメッセージに対して、伝播のポジティブ・ルール・セット内のルールベースの変換に対応するルールがTRUEと評価される必要があります。このメッセージは、取得LCR、バッファLCR、バッファ・ユーザー・メッセージ、永続LCRおよび永続ユーザー・メッセージの場合があります。

宣言ルールベースの変換の場合は、メッセージに対してポジティブ・ルール・セットのルールがTRUEと評価されると、メッセージは内部的に変換されます。カスタム・ルールベースの変換の場合は、メッセージに対してポジティブ・ルール・セットのルールがTRUEと評価されると、STREAMS$_TRANSFORM_FUNCTIONという名前の名前/値ペアを含むアクション・コンテキストが伝播に返されます。

伝播は、次の手順でルールベースの変換を実行します。

1. ソース・キューからメッセージのデキューを開始します。

2. メッセージを変換します。宣言ルールベースの変換の場合は、宣言変換の指定に基づいてメッセージが内部的に変換されます。カスタム・ルールベースの変換の場合は、ソース・キューの所有者が名前/値ペアのPL/SQLファンクションを実行してメッセージを変換します。

3. 変換済メッセージのデキューを終了します。

4. 変換済メッセージを宛先キューに伝播します。

関連項目:
「Oracle Streamsで情報をコンシュームする方法」

図6-3は、伝播中の変換を示しています。

図6-3 伝播中の変換

たとえば、メッセージのdbs1.example.comデータベースからdbs2.example.comデータベースへの伝播でルールベースの変換を使用するが、dbs1.example.comデータベースからdbs3.example.comデータベースへのメッセージの伝播ではルールベースの変換を使用しないとします。

この場合、dbs1.example.comのキューのメッセージは、dbs2.example.comに伝播する前に変換できますが、同じメッセージをdbs3.example.comに伝播するときには元のままにしておくことができます。この場合、伝播の後には、dbs2.example.comのキューには変換済メッセージが含まれ、dbs3.example.comのキューには元のメッセージが含まれます。

伝播中に変換を実行するメリットは、次のとおりです。

- メッセージを伝播する前に変換でプライベート情報を削除または変更すると、セキュリティを向上できます。

- 一部の宛先キューで変換済メッセージを受信し、その他の宛先キューで元のメッセージを受信できます。

- 様々な宛先が様々な形で同じ変換済メッセージを受信できます。

伝播中に変換を実行する場合に考えられるデメリットは、次のとおりです。

- メッセージが変換されると、最初の伝播後に伝播先となるデータベースは変換済メッセージを受信します。たとえば、メッセージがdbs2.example.comからdbs4.example.comに伝播される場合、dbs4.example.comは変換済メッセージを受信します。

- 有向ネットワークで最初の伝播によって変換が実行され、ローカルの取得プロセスがメッセージを取得した場合、変換によるオーバーヘッドはソース・データベースで発生します。ただし、取得プロセスがダウンストリーム取得プロセスである場合、このオーバーヘッドはソース・データベースではなくダウンストリーム・データベースで発生します。

- 有向ネットワークで最初の伝播によって変換が実行され、同期取得がメッセージを取得した場合、変換によるオーバーヘッドはソース・データベースで発生します。

- 様々な伝播によって1つのメッセージが複数の宛先データベースに送信される場合は、そのメッセージに対して同じ変換が2回以上実行されることがあります。

伝播中のルールベース変換のエラー

変換においてエラーが発生すると、エラーの原因となったメッセージはデキューも伝播もされず、伝播にエラーが返されます。メッセージを伝播するためには、ルールベースの変換を変更または削除してエラーを回避する必要があります。

ルールベースの変換と適用プロセス

適用中に変換を実行する場合は、適用プロセスのキューのメッセージに対して、適用プロセスのポジティブ・ルール・セット内のルールベースの変換に対応するルールがTRUEと評価される必要があります。このメッセージは、取得LCR、永続LCRまたは永続ユーザー・メッセージの場合があります。

宣言ルールベースの変換の場合は、メッセージに対してポジティブ・ルール・セットのルールがTRUEと評価されると、メッセージは内部的に変換されます。カスタム・ルールベースの変換の場合は、メッセージに対してポジティブ・ルール・セットのルールがTRUEと評価されると、STREAMS$_TRANSFORM_FUNCTIONという名前の名前/値ペアを含むアクション・コンテキストが適用プロセスに返されます。

適用プロセスは、次の手順でルールベースの変換を実行します。

1. キューからメッセージのデキューを開始します。

2. メッセージを変換します。宣言ルールベースの変換の場合は、宣言変換の指定に基づいてメッセージが内部的に変換されます。カスタム・ルールベースの変換の場合は、適用ユーザーが名前/値ペアのPL/SQLファンクションを実行してメッセージを変換します。

3. 変換済メッセージのデキューを終了します。

4. 変換済メッセージを適用します。このとき、宛先データベースでのデータベース・オブジェクトの変更や、適用ハンドラへの変換済メッセージの送信が行われることがあります。

すべてのアクションは適用ユーザーが実行します。

関連項目:
「Oracle Streamsで情報をコンシュームする方法」

図6-4は、適用中の変換を示しています。

図6-4 適用中の変換

たとえば、メッセージがdbs1.example.comデータベースからdbs2.example.comデータベースに元の形で伝播されるとします。適用プロセスがdbs2.example.comでメッセージをデキューするときに、メッセージが変換されます。

適用中に変換を実行するメリットは、次のとおりです。

- 最初の伝播後にメッセージの伝播先となるデータベースは、メッセージを元の形で受信できます。たとえば、メッセージがdbs2.example.comからdbs4.example.comに伝播される場合、dbs4.example.comは元のメッセージを受信できます。

- ソース・データベースと宛先データベースが異なる場合、ソース・データベースでは変換によるオーバーヘッドは発生しません。

適用中に変換を実行する場合に考えられるデメリットは、次のとおりです。

- メッセージの伝播先となるデータベースすべてに元のメッセージが伝播されるため、メッセージにプライベート情報が含まれている場合はセキュリティが問題になる可能性があります。

- 複数の宛先データベースが同じ変換を必要とする場合は、同じ変換が2回以上実行される可能性があります。

注意:
適用プロセスの1つ以上のルールを変更するときは、その前に適用プロセスを停止する必要があります。

適用プロセスによるデキュー中のルールベース変換のエラー

適用プロセスによるデキュー中に変換ファンクションの実行エラーが発生すると、エラーの原因となったメッセージはデキューされず、そのメッセージを含むトランザクションは適用されません。また、適用プロセスにエラーが返され、適用プロセスは無効化されます。適用プロセスを有効化する前に、ルールベースの変換を変更または削除してエラーを回避する必要があります。

変換済メッセージの適用エラー

トランザクションで適用エラーが発生し、そのトランザクションの一部のメッセージがルールベースの変換によって変換済の場合、変換済メッセージもトランザクションの他のすべてのメッセージとともにエラー・キューに移動されます。DBMS_APPLY_ADMパッケージのEXECUTE_ERRORプロシージャを使用して、エラー・キュー内の変換済メッセージを含むトランザクションを再実行しても、メッセージの変換は再実行されません。対応するルールを含む適用プロセスのルール・セットが再評価されないためです。

ルールベースの変換とメッセージ・クライアント

メッセージ・クライアントによるデキュー中に変換を実行する場合は、メッセージ・クライアントのポジティブ・ルール・セット内のルールベースの変換に対応するルールが、メッセージ・クライアントのキュー内のメッセージに対して、TRUEと評価される必要があります。

宣言ルールベースの変換の場合は、メッセージに対してポジティブ・ルール・セットのルールがTRUEと評価されると、メッセージは内部的に変換されます。カスタム・ルールベースの変換の場合は、メッセージに対してポジティブ・ルール・セット内のルールがTRUEと評価されると、STREAMS$_TRANSFORM_FUNCTIONという名前の名前/値ペアを含むアクション・コンテキストがメッセージ・クライアントに返されます。

メッセージ・クライアントは、次の手順でルールベースの変換を実行します。

1. キューからメッセージのデキューを開始します。

2. メッセージを変換します。変換が宣言ルールベースの変換である場合、メッセージは永続LCRである必要があります。行LCRは、宣言変換の指定に基づいて内部的に変換されます。変換がカスタム・ルールベースの変換である場合、メッセージは、永続LCRまたは永続ユーザー・メッセージのいずれかになります。メッセージ・クライアントを起動するユーザーは、名前/値ペアのPL/SQLファンクションを実行して、デキュー中にメッセージを変換します。

3. 変換済メッセージのデキューを終了します。

すべてのアクションは、メッセージ・クライアントを起動するユーザーによって実行されます。

図6-5は、メッセージ・クライアント・デキュー中の変換を示しています。

図6-5 メッセージ・クライアント・デキュー中の変換

たとえば、メッセージがdbs1.example.comデータベースからdbs2.example.comデータベースに元の形で伝播されるとします。メッセージ・クライアントがdbs2.example.comでメッセージをデキューするときに、メッセージが変換されます。

デキュー時にメッセージ環境で変換を実行するメリットの1つは、最初の伝播の後にメッセージが伝播されるすべてのデータベースが、メッセージを元の形式で受け取ることです。たとえば、メッセージがdbs2.example.comからdbs4.example.comに伝播される場合、dbs4.example.comは元のメッセージを受信できます。

デキュー中にメッセージ環境で変換を実行する場合に考えられるデメリットは、次のとおりです。

- メッセージの伝播先となるデータベースすべてに元のメッセージが伝播されるため、メッセージにプライベート情報が含まれている場合はセキュリティが問題になる可能性があります。

- 複数の宛先データベースが同じ変換を必要とする場合は、同じ変換が2回以上実行される可能性があります。

メッセージ・クライアントによるデキュー中のルールベースの変換のエラー

メッセージ・クライアントのデキュー中に変換ファンクションが実行してエラーが発生すると、エラーの原因となったメッセージはデキューされず、エラーがメッセージ・クライアントに返されます。メッセージをメッセージ・クライアントでデキューするためには、ルールベースの変換を変更または削除してエラーを回避する必要があります。

複数のルールベース変換

取得、伝播、適用、デキュー、またはそれらを任意に組み合せて実行しているときに、メッセージを変換できます。たとえば、機密データをすべての受信先で隠す必要がある場合は、取得中にメッセージを変換できます。一部の受信先でさらにカスタム変換が必要な場合は、すでに変換したメッセージを伝播、適用またはデキュー中に変換できます。

変換の順序

宣言ルールベースの変換とカスタム・ルールベースの変換に加えて、行の移行も、サブセット・ルールがTRUEと評価された場合に発生する内部変換です。3種類の変換すべてが単一のルールに指定されている場合、ルールがTRUEと評価されると、変換は次の順序で実行されます。

1. 行の移行

2. 宣言ルールベースの変換

3. カスタム・ルールベースの変換

宣言ルールベースの変換の順序

単一のルールに複数の宣言ルールベースの変換が指定されている場合、一定の順序で変換を実行する必要があります。宣言ルールベースの変換にデフォルトの順序を使用するか、または順序を指定できます。

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

- 宣言ルールベースの変換のデフォルトの順序

- 宣言ルールベースの変換のユーザー指定の順序

宣言ルールベースの変換のデフォルトの順序

ルールがTRUEと評価されると、デフォルトでは、次の順序で宣言ルールベースの変換が実行されます。

1. 列の保持

2. 列の削除

3. 列名の変更

4. 列の追加

5. 表名の変更

6. スキーマ名の変更

後続の各宣言変換では、宣言変換の結果が使用されます。たとえば、1つのルールに、次の宣言ルールベースの変換が指定されたとします。

- 列addressの削除

- 列addressの追加

列addressが行LCRに存在するとした場合、両方の宣言変換を実行する必要があります。これは、列addressが行LCRに戻される前に、列addressアドレスが行LCRから削除されるためです。次の表に、この例での変換の順序付けを示します。

手順番号

変換のタイプ

変換の詳細

変換が実行されるかどうか

1

列の保持

-

-

2

列の削除

行LCRから列addressを削除します

はい

3

列名の変更

-

-

4

列の追加

行LCRに列addressを追加します

はい

5

表名の変更

-

-

6

スキーマ名の変更

-

-

別の例として、表名を変更してからスキーマ名を変更する場合を考えます。たとえば、1つのルールに、次の宣言ルールベースの変換が指定されたとします。

- 表名john.customersをsue.clientsに変更

- スキーマ名sueをmaryに変更

表名の変更の変換では、表のスキーマ名も変更されることに注意してください。この場合、変換は両方とも実行され、両方の変換後の表名はmary.clientsになります。次の表に、この例での変換の順序付けを示します。

手順番号

変換のタイプ

変換の詳細

変換が実行されるかどうか

1

列の保持

-

-

2

列の削除

-

-

3

列名の変更

-

-

4

列の追加

-

-

5

表名の変更

表名john.customersをsue.clientsに変更

はい

6

スキーマ名の変更

スキーマ名sueをmaryに変更

はい

類似した例で、1つのルールに、次の宣言ルールベースの変換が指定された場合を考えます。

- 表名john.customersをsue.clientsに変更

- スキーマ名johnをmaryに変更

この場合、1つ目の変換は実行されますが、2つ目の変換は実行されません。1つ目の変換の実行後、表名はsue.clientsになります。2つ目の変換の実行時、表のスキーマ名はjohnではなくsueであるため、2つ目の変換は実行されません。次の表に、この例での変換の順序付けを示します。

手順番号

変換のタイプ

変換の詳細

変換が実行されるかどうか

1

列の保持

-

-

2

列の削除

-

-

3

列名の変更

-

-

4

列の追加

-

-

5

表名の変更

表名john.customersをsue.clientsに変更

はい

6

スキーマ名の変更

スキーマ名johnをmaryに変更

いいえ

スキーマ名の変更の変換は実行されませんが、エラーは発生しません。この場合、表名の変更の変換によって、行LCRは変換され、表名sue.clientsの行LCRが返されます。

宣言ルールベースの変換のユーザー指定の順序

特定のルールに対して、宣言ルールベースの変換のデフォルトの順序を使用しない場合、ルールに指定された各宣言変換に手順番号を指定できます。特定のルールに対する1つ以上の宣言ルールベースの変換に手順番号を指定した場合、宣言ルールベースの変換は、次のように実行されます。

- 宣言変換は、手順番号の昇順で実行されます。

- 宣言変換デフォルトの手順番号は0 (ゼロ)です。宣言変換に手順番号が明示的に指定されていない場合、このデフォルトが使用されます。

- 複数の宣言変換に同じ手順番号が指定された場合、これらの宣言変換は、「宣言ルールベースの変換のデフォルトの順序」で説明されているデフォルトの順序付けに従います。

たとえば、特定のルールに関連付けられた変換に次の手順番号を指定すると、宣言変換のデフォルトの順序付けを逆にすることができます。

- 列の保持: 手順番号6

- 列の削除: 手順番号5

- 列名の変更: 手順番号4

- 列の追加: 手順番号3

- 表名の変更: 手順番号2

- スキーマ名の変更: 手順番号1

このように順序を指定すると、スキーマ名の変更の変換が最初に実行され、列の削除の変換は最後に実行されます。

ルールベースの変換に関する考慮事項

宣言ルールベースの変換とカスタム・ルールベースの変換では次の点に注意してください。

- ルールベースの変換をOracle Streamsクライアントで実行するには、ルールをOracle Streamsクライアントのポジティブ・ルール・セットに含める必要があります。ルールがOracle Streamsクライアントのネガティブ・ルール・セットにある場合、Oracle Streamsクライアントではルールベースの変換が無視されます。

- ルールベースの変換は、DBMS_TRANSFORMパッケージを使用して実行される変換とは異なります。このヘルプでは、DBMS_TRANSFORMパッケージで実行される変換については説明しません。

- ご使用の環境で大半の行LCRを変換する場合、または実行が必要な行LCRの変換にコストがかかる場合、DMLハンドラ内で変更を行うことを検討してください。DMLハンドラは、適用の並列性が1より大きい場合にはパラレルで実行できるためです。

関連項目:
DBMS_TRANSFORMパッケージの詳細は、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドおよびOracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンスを参照

第II部

Oracle Streamsの高度な概念

この部では、Oracle Streamsの高度な概念について説明します。この部の構成は、次のとおりです。

- 第7章「取得プロセスの高度な概念」

- 第8章「キューの高度な概念」

- 第9章「伝播の高度な概念」

- 第10章「適用プロセスの高度な概念」

- 第11章「ルールの高度な概念」

- 第12章「取得と適用の複合による最適化」

- 第13章「Oracle Streams高可用性環境」

7 取得プロセスの高度な概念

Oracle Streamsでの情報の取得とは、情報を含むメッセージを作成し、そのメッセージをキューにエンキューすることです。取得される情報は、データベースの変更に関する説明の場合もあれば、その他の情報である場合もあります。

次の各項では、Oracle Streamsによる情報の取得の概念について説明します。

- 単一データベースでの複数の取得プロセス

- 取得プロセスのチェックポイント

- 新しい先頭SCN値および消去されたLogMinerデータ・ディクショナリ情報

- ARCHIVELOGモードおよび取得プロセス

- 取得プロセスの作成

- Oracle Streamsデータ・ディクショナリ

- 取得プロセス・ルールの評価

関連項目:

- 「Oracle Streams取得プロセスによる暗黙的取得」

- 「取得プロセスの管理」

- 「取得プロセスの監視」

- 「暗黙的取得のトラブルシューティング」

単一データベースでの複数の取得プロセス

単一データベースで複数の取得プロセスを実行する場合は、各インスタンスのシステム・グローバル領域(SGA)のサイズを増やしてください。SGAサイズを増やすには、SGA_MAX_SIZE初期化パラメータを使用します。また、Oracle Streamsプールのサイズがデータベースで自動管理されていない場合は、取得プロセスの並列性ごとにOracle Streamsプールを 10MB増やす必要があります。たとえば、2つの取得プロセスがデータベースで実行されており、parallelismパラメータが一方の取得プロセスでは4、もう一方の取得プロセスでは1に設定されている場合、Oracle Streamsプールを50MB(並列性は4+1=5)増やします。

また、取得プロセス、伝播または取得プロセスで使用される各ANYDATAキューには、特定のソース・データベースの最大1つの取得プロセスからの取得LCRを格納することをお薦めします。したがって、特定のソース・データベースで行われた変更を取得する各取得プロセスで個別のキューを使用し、各キューに独自のキュー表があることを確認します。また、同じソース・データベースの2つ以上の取得プロセスからのメッセージが同じキューに伝播されないようにしてください。

注意:
MEMORY_TARGET、MEMORY_MAX_TARGETまたはSGA_TARGET初期化パラメータが0(ゼロ)以外の値に設定されている場合、Oracle Streamsプールのサイズは自動的に管理されます。

関連項目:

- Oracle Streamsプールの詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- STREAMS_POOL_SIZE初期化パラメータの詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

取得プロセスのチェックポイント

チェックポイントは、取得プロセスの現在の状態に関する情報です。この情報は、取得プロセスを実行しているデータベースのデータ・ディクショナリに永続的に格納されます。取得プロセスでは、チェックポイント間隔と呼ばれる定期的な間隔でチェックポイントの記録が試行されます。

必須チェックポイントSCN

取得プロセスでREDOデータが必要となる最小のチェックポイントに対応するシステム変更番号(SCN)は、必須チェックポイントSCNと呼ばれます。必須チェックポイントSCNが含まれているREDOログ・ファイルおよび後続のすべてのREDOログ・ファイルが、取得プロセスで使用可能である必要があります。取得プロセスを停止して再起動すると、REDOログのスキャンは、必須チェックポイントSCNに対応するSCNから開始されます。必須チェックポイントSCNは、データベースが予期せず停止した場合のリカバリで重要となります。また、取得プロセス用に先頭SCNをリセットする場合は、取得プロセスの必須チェックポイントSCN以下の値に設定する必要があります。取得プロセスの必須チェックポイントSCNを確認するには、DBA_CAPTUREデータ・ディクショナリ・ビューのREQUIRED_CHECKPOINT_SCN列を問い合せます。

関連項目:
「各取得プロセスで必要なREDOログ・ファイルの表示」

最大チェックポイントSCN

取得プロセスによって記録された最後のチェックポイントに対応するSCNは、最大チェックポイントSCNと呼ばれます。ソース・データベースから変更を取得する取得プロセスを作成し、同じソース・データベースから変更を取得する別の取得プロセスが存在している場合は、既存の取得プロセスの最大チェックポイントSCNを使用して、新しい取得プロセスでLogMinerデータ・ディクショナリを作成するか、既存のLogMinerデータ・ディクショナリのいずれかを共有するかを決定できます。取得プロセスの最大チェックポイントSCNを確認するには、DBA_CAPTUREデータ・ディクショナリ・ビューのMAX_CHECKPOINT_SCN列を問い合せます。

チェックポイント保存時間

チェックポイント保存時間とは、チェックポイントが自動的に消去されるまで取得プロセスによって保持される時間(日数)のことです。取得プロセスでは、取得プロセスの必須チェックポイントSCNが含まれているアーカイブREDOログ・ファイルのFIRST_TIMEから、チェックポイントに対応するアーカイブREDOログ・ファイルのNEXT_TIMEを差し引くことによって、チェックポイントの経過時間が定期的に計算されます。計算された値がチェックポイント保存時間より大きい場合、先頭SCN値を進めることによってチェックポイントが自動的に消去されます。計算された値がチェックポイント保存時間より小さい場合、チェックポイントは保持されます。DBA_REGISTERED_ARCHIVED_LOGビューにはアーカイブREDOログ・ファイルのFIRST_TIMEおよびNEXT_TIMEが表示され、DBA_CAPTUREビューのREQUIRED_CHECKPOINT_SCN列には取得プロセスの必須チェックポイントSCNが表示されます。

図7-1に、チェックポイント保存期間が20日に設定されている場合のチェックポイントの消去の例を示します。

図7-1 チェックポイント保存時間が20日に設定されている場合

図7-1では、チェックポイント保存時間が20日に設定されています。経過時間が21日のSCN 435250のチェックポイントは消去され、経過時間が8日のSCN 479315のチェックポイントは保持されています。

取得プロセスの先頭SCNがリセットされるたびに、取得プロセスによって、新しい先頭SCNより前のアーカイブREDOログ・ファイルに関する情報がLogMinerデータ・ディクショナリから消去されます。この情報が消去された後、アーカイブREDOログ・ファイルはハード・ディスクに残りますが、これらのファイルは取得プロセスでは不要となります。不要となったアーカイブREDOログ・ファイルに対して、DBA_REGISTERED_ARCHIVED_LOGビューのPURGEABLE列にYESが表示されます。これらのファイルをディスクから削除したり、別の場所に移動しても、取得プロセスに影響はありません。

DBMS_CAPTURE_ADMパッケージのCREATE_CAPTUREプロシージャを使用して取得プロセスを作成する場合、checkpoint_retention_timeパラメータを使用して、チェックポイント保存時間(日数)を指定できます。CREATE_CAPTUREプロシージャにcheckpoint_retention_timeパラメータを指定しなかった場合、またはDBMS_STREAMS_ADMパッケージを使用して取得プロセスを作成する場合、デフォルトのチェックポイント保存時間の60日が使用されます。DBA_CAPTUREビューのCHECKPOINT_RETENTION_TIME列に、取得プロセスの現在のチェックポイント保存時間が表示されます。

取得プロセスのチェックポイント保存時間を変更するには、DBMS_CAPTURE_ADMパッケージのALTER_CAPTUREプロシージャで新しい期間を指定します。取得プロセスのチェックポイントが自動的に消去されないようにするには、CREATE_CAPTUREまたはALTER_CAPTUREのcheckpoint_retention_timeパラメータにDBMS_CAPTURE_ADM.INFINITEを指定します。

注意:
取得プロセスのチェックポイント保存時間を指定するには、取得プロセスが実行されているデータベースの互換性レベルが10.2.0以上である必要があります。データベースの互換性レベルが10.2.0未満の場合は、データベースで実行されているすべての取得プロセスのチェックポイント保存時間が無期限になります。

関連項目:

- 「取得プロセスのLogMinerデータ・ディクショナリ」

- 「新しい先頭SCN値および消去されたLogMinerデータ・ディクショナリ情報」

- 「取得プロセスのチェックポイント保存時間の管理」

- CREATE_CAPTUREおよびALTER_CAPTUREプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

新しい先頭SCN値および消去されたLogMinerデータ・ディクショナリ情報

既存の取得プロセスに対する先頭SCN値をリセットする場合、またはチェックポイントの消去時に先頭SCNが自動的にリセットされる場合は、新しい先頭SCNの設定前にLogMinerデータ・ディクショナリ情報が自動的に消去されます。取得プロセスの開始SCNが、消去されたREDO情報に対応している場合は、開始SCNが先頭SCNと同じ値に自動的にリセットされます。ただし、開始SCNが新しい先頭SCNの設定より大きい場合、開始SCNは変更されません。

図7-2に、新しい先頭SCNの設定前にLogMinerデータ・ディクショナリ情報が自動的に消去される仕組み、および開始SCNが新しい先頭SCNの設定値より大きい場合に開始SCNが変更されない仕組みを示します。

図7-2 リセットされた先頭SCNより開始SCNが大きい場合

この例に示されているように、先頭SCNが取得プロセスの開始SCNより大きい値に再度リセットされた場合、開始SCNはLogMinerデータ・ディクショナリ内の既存の情報に対応しなくなります。図7-3に、開始SCNが新しい先頭SCNの設定より小さい場合、開始SCNが自動的にリセットされる仕組みを示します。

図7-3 リセットされた先頭SCNより開始SCNが小さい場合

この図に示されているように、取得プロセスの先頭SCNおよび開始SCNは、時間の経過に伴い大きくなる場合があります。先頭SCNは、大きくなることによって、DBMS_CAPTURE_ADM.BUILDプロシージャで設定したSCNに対応しなくなる可能性があります。

関連項目:

- 「先頭SCNおよび開始SCN」

- 「既存の取得プロセスの開始SCNの設定」

- 取得プロセスの変更の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のDBMS_CAPTURE_ADM.ALTER_CAPTUREプロシージャに関する項を参照

ARCHIVELOGモードおよび取得プロセス

次に、異なるタイプの取得プロセスによるREDOデータの読取り方法について説明します。

- ローカル取得プロセスでは、可能な場合、REDOログ・バッファを読み取ります。ログ・バッファを読み取ることができない場合は、オンラインREDOログを読み取ります。ログ・バッファまたはオンラインREDOログを読み取ることができない場合は、アーカイブREDOログ・ファイルを読み取ります。このため、ローカル取得プロセスが変更を取得するように構成されている場合は、ソース・データベースをARCHIVELOGモードで実行している必要があります。

- リアルタイム・ダウンストリーム取得プロセスでは、可能な場合、ソース・データベースのオンラインREDOデータを読み取ります。これが可能ではない場合は、ソース・データベースからREDOデータが含まれているアーカイブREDOログ・ファイルを読み取ります。この場合、ソース・データベースからのREDOデータはダウンストリーム・データベースのスタンバイREDOログに格納され、スタンバイREDOログのREDOデータはダウンストリーム・データベースのアーカイバによって格納されます。このため、リアルタイム・ダウンストリーム取得プロセスが変更を取得するように構成されている場合は、ソース・データベースとダウンストリーム・データベースの両方をARCHIVELOGモードで実行している必要があります。

- アーカイブ・ログ・ダウンストリーム取得プロセスでは、常にソース・データベースからアーカイブREDOログ・ファイルを読み取ります。このため、アーカイブ・ログ・ダウンストリーム取得プロセスが変更を取得するように構成されている場合は、ソース・データベースをARCHIVELOGモードで実行している必要があります。

取得プロセスの必須チェックポイントSCNを判別するには、DBA_CAPTUREデータ・ディクショナリ・ビューのREQUIRED_CHECKPOINT_SCN列を問い合せます。取得プロセスを再起動すると、必須チェックポイントSCN以降のREDOログがスキャンされます。このため、必須チェックポイントSCNが含まれているREDOログ・ファイルおよび後続のすべてのREDOログ・ファイルが取得プロセスに対して使用可能になっている必要があります。

アーカイブREDOログ・ファイルは、アーカイブREDOログ・ファイルを必要とする取得プロセスが存在しなくなるまで使用可能にしておく必要があります。取得プロセスの先頭SCNは、大きい値にリセットすることはできますが、小さい値にリセットすることはできません。このため、取得プロセスでは、先頭SCNより前の情報が含まれているREDOログ・ファイルは必要ありません。いずれの取得プロセスでも必要とされないアーカイブREDOログ・ファイルを判別するには、DBA_LOGMNR_PURGED_LOGデータ・ディクショナリ・ビューを問い合せます。

ローカル取得プロセスで遅延が発生すると、オンラインREDOログの読取りからアーカイブREDOログの読取りへとシームレスに推移し、ローカル取得プロセスで遅延が取り戻されると、アーカイブREDOログの読取りからオンラインREDOログの読取りへとシームレスに推移します。同様に、リアルタイム・ダウンストリーム取得プロセスで遅延が発生すると、スタンバイREDOログの読取りからアーカイブREDOログの読取りへとシームレスに推移し、リアルタイム・ダウンストリーム取得プロセスで遅延が取り戻されると、アーカイブREDOログの読取りからスタンバイREDOログの読取りへとシームレスに推移します。

注意:
ダウンストリーム取得プロセス構成のダウンストリーム・データベースでは、リモート・ソース・データベースのログ・ファイルを、ローカル・データベースとは別に格納する必要があります。また、ダウンストリーム・データベースに複数のソース・データベースからのログ・ファイルが含まれている場合は、各ソース・データベースからのログ・ファイルを個別に格納する必要があります。

関連項目:

- ARCHIVELOGモードでのデータベースの運用については、『Oracle Database管理者ガイド』を参照

- 不要なREDOログ・ファイルを判別する問合せについては、「各取得プロセスで使用される各REDOログ・ファイルのSCN値の表示」を参照

取得プロセスの作成

取得プロセスは、DBMS_STREAMS_ADMパッケージまたはDBMS_CAPTURE_ADMパッケージのプロシージャを使用して作成できます。DBMS_STREAMS_ADMパッケージのプロシージャを使用すると、いくつかの構成オプションにデフォルトが自動的に使用されるため、取得プロセスをより簡単に作成できます。また、DBMS_STREAMS_ADMパッケージのプロシージャを使用すると、取得プロセスに対してルール・セットが作成され、このルール・セットに自動的にルールを追加することができます。ルール・セットは、そのプロシージャでinclusion_ruleパラメータがTRUEに設定されている場合(デフォルト)はポジティブ・ルール・セット、inclusion_ruleパラメータがFALSEに設定されている場合はネガティブ・ルール・セットになります。

DBMS_CAPTURE_ADMパッケージのCREATE_CAPTUREプロシージャを使用すると、より柔軟に取得プロセスを作成できます。取得プロセスの作成前または作成後に1つ以上のルール・セットおよびルールを作成します。DBMS_STREAMS_ADMパッケージまたはDBMS_RULE_ADMパッケージのプロシージャを使用すると、取得プロセスのルール・セットにルールを追加できます。ダウンストリーム・データベースで取得プロセスを作成するには、 DBMS_CAPTURE_ADMパッケージを使用する必要があります。

DBMS_STREAMS_ADMパッケージのプロシージャを使用して取得プロセスを作成し、この取得プロセスのポジティブ・ルール・セットに1つ以上のルールを生成すると、変更を取得されるオブジェクトがインスタンス化のために自動的に準備されます。ただし、この取得プロセスがダウンストリーム取得プロセスで、ダウンストリーム・データベースからソース・データベースへのデータベース・リンクが存在しない場合は除きます。

DBMS_CAPTURE_ADMパッケージのCREATE_CAPTUREプロシージャを使用して取得プロセスを作成する場合は、変更を取得するすべてのオブジェクトのインスタンス化を準備する必要があります。取得プロセスの作成後、できるだけ早く、これらのオブジェクトのインスタンス化を準備してください。オブジェクトのインスタンス化を準備するには、DBMS_CAPTURE_ADMパッケージの次のいずれかのプロシージャを使用します。

- PREPARE_TABLE_INSTANTIATION: 単一表をインスタンス化のために準備します。

- PREPARE_SCHEMA_INSTANTIATION: スキーマ内のすべてのオブジェクトおよび将来そのスキーマに追加されるすべてのオブジェクトをインスタンス化のために準備します。

- PREPARE_GLOBAL_INSTANTIATION: データベース内のすべてのオブジェクトおよび将来そのデータベースに追加されるすべてのオブジェクトをインスタンス化のために準備します。

これらのプロシージャを使用して、インスタンス化のために準備された表のキー列またはすべてのキー列のサプリメンタル・ロギングを有効にすることもできます。

注意:
取得プロセスの作成後、その取得プロセスのソース・データベースのDBIDまたはグローバル名は変更しないでください。ソース・データベースのDBIDまたはグローバル名のいずれかを変更した場合、その取得プロセスを削除して再作成する必要があります。

関連項目:

- 取得プロセスを作成できるプロシージャの詳細は、『Oracle Streamsレプリケーション管理者ガイド』および『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

- 取得プロセスのルールおよびインスタンス化の準備、ソース・データベースのDBIDまたはグローバル名の変更の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

取得プロセスのLogMinerデータ・ディクショナリ

取得プロセスには、ソース・データベースのプライマリ・データ・ディクショナリとは別個のデータ・ディクショナリが必要です。この別個のデータ・ディクショナリは、LogMinerデータ・ディクショナリと呼ばれます。特定のソース・データベースに対して、複数のLogMinerデータ・ディクショナリが存在する場合があります。ソース・データベースから変更を取得する複数の取得プロセスが存在する場合は、複数の取得プロセスで1つのLogMinerデータ・ディクショナリを共有するか、または取得プロセスごとに独自のLogMinerデータ・ディクショナリを所有できます。取得プロセスに必要なLogMinerデータ・ディクショナリが存在しない場合は、取得プロセスの最初の起動時にREDOログの情報を使用してLogMinerデータ・ディクショナリが移入されます。

データ・ディクショナリ情報は、DBMS_CAPTURE_ADM.BUILDプロシージャによってREDOログに抽出されます。このプロシージャは、ソース・データベースで発生した変更を取得するように構成された任意の取得プロセスが起動される前に、ソース・データベース上で1回以上実行する必要があります。REDOログに抽出されたデータ・ディクショナリ情報には、DBMS_CAPTURE_ADM.BUILDプロシージャの実行時のプライマリ・データ・ディクショナリとの一貫性があります。また、このプロシージャでは、取得プロセスの作成に使用できる有効な先頭SCN値の識別も行われます。

REDOログでのデータ・ディクショナリ情報のビルドは複数回実行できますが、特定のビルドが取得プロセスによるLogMinerデータ・ディクショナリの作成に使用されない場合もあります。BUILDプロシージャの実行時にREDOログに抽出される情報の量は、データベース内のオブジェクトの数によって異なります。通常、BUILDプロシージャでは大量のREDOデータが生成されます。これらのデータは後で取得プロセスでスキャンする必要があります。このため、BUILDプロシージャは、必要な場合にのみ実行する必要があります。

ほとんどの場合、DBMS_STREAMS_ADMまたはDBMS_CAPTURE_ADMパッケージのプロシージャを使用して取得プロセスを作成する際にビルドが必要な場合は、このプロシージャによって自動的にBUILDプロシージャが実行されます。ただし、次の場合は、取得プロセスの作成時にBUILDプロシージャは自動的には実行されません。

- CREATE_CAPTUREを使用し、first_scnパラメータにNULL以外の値を指定した場合。この場合、指定した先頭SCNが以前のビルドに対応している必要があります。

- データベース・リンクを使用しないダウンストリーム取得プロセスを作成した場合。この場合、ダウンストリーム・データベースのコマンドで、ソース・データベースと通信してBUILDプロシージャを自動的に実行することはできません。このため、ソース・データベースでBUILDプロシージャを手動で実行し、取得プロセス作成時のビルドに対応する先頭SCNを指定する必要があります。

プライマリ・データ・ディクショナリの情報はREDOログから取得される変更に適用できない場合があるため、取得プロセスにはLogMinerデータ・ディクショナリが必要です。このような変更は、取得プロセスによって取得される数分前、数時間前または数日前に発生した可能性があります。たとえば、次の使用例について考えてみます。

1. 取得プロセスは、表に対する変更を取得するように構成されています。

2. データベース管理者が取得プロセスを停止します。取得プロセスを停止すると、その時点で取得中だった変更のSCNが取得プロセスによって記録されます。

3. ユーザー・アプリケーションは、取得プロセスの停止中も引き続き表に対する変更を行います。

4. 停止してから3時間後に取得プロセスが再起動されます。

この場合、取得プロセスでは、データ整合性を確保するために、停止された時点からREDOログの変更の取得を開始する必要があります。取得プロセスでは、停止時に記録したSCNから変更の取得が開始されます。

REDOログにはRAWデータが含まれています。これには、データベース・オブジェクト名および表の列名は含まれていません。かわりに、データベース・オブジェクトおよび列にそれぞれオブジェクト番号および内部列番号が使用されます。したがって、取得プロセスでは、変更を取得する場合、データ・ディクショナリを参照して変更の詳細を確認する必要があります。

取得プロセスの最初の起動時にLogMinerデータ・ディクショナリが移入される場合があるため、変更の取得の開始に時間がかかることがあります。所要時間は、データベース内のデータベース・オブジェクトの数によって異なります。取得プロセスによるデータ・ディクショナリ・ビルドの処理の進捗を監視するには、V$STREAMS_CAPTURE動的パフォーマンス・ビューのSTATE列を問い合せます。

関連項目:

- 「取得プロセス・ルールの評価」

- 「先頭SCNおよび開始SCN」

- 「取得プロセスの状態」

- データベース・オブジェクトをインスタンス化のために準備する方法の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

取得プロセスに対するLogMinerデータ・ディクショナリの必要性を示す使用例

取得プロセスが、表t1に対する変更を取得するように構成されている場合について考えてみます。この表には列aおよびbがあり、この表に対して3つの異なる時点で次の変更が行われるとします。

時刻1: 値a=7およびb=15の挿入

時刻2: 列cの追加

時刻3: 列bの削除

なんらかの理由で取得プロセスがこれ以前の時点から変更を取得している場合は、プライマリ・データ・ディクショナリとLogMinerデータ・ディクショナリ内の関連バージョンに異なる情報が含まれていることになります。表7-1に、現在の時刻が変更取得時刻とは異なる場合の、LogMinerデータ・ディクショナリ内の情報の使用方法を示します。

表7-1 プライマリ・データ・ディクショナリ内とLogMinerデータ・ディクショナリ内の表t1に関する情報

現在の時刻

変更取得時刻

プライマリ・データ・ディクショナリ

LogMinerデータ・ディクショナリ

1

1

表t1には、列aおよびbが含まれています。

表t1には、時間1における列aおよびbが含まれています。

2

1

表t1には、時間2における列a、bおよびcが含まれています。

表t1には、時間1における列aおよびbが含まれています。

3

1

表t1には、時間3における列aおよびcが含まれています。

表t1には、時間1における列aおよびbが含まれています。

取得プロセスで、実際の時刻が3のときに、時間1に行われた挿入による変更を取得するとします。取得プロセスでプライマリ・データ・ディクショナリが使用されていた場合、列aに値7、列cに値15が挿入されたとみなされる可能性があります。これらの列がプライマリ・データ・ディクショナリ内の時刻 3における表t1の列であるためです。ただし、実際には、値15は、列cではなく列bに挿入されています。

取得プロセスではLogMinerデータ・ディクショナリが使用されるため、このエラーは回避されます。LogMinerデータ・ディクショナリは取得プロセスと同期化され、時刻1の時点で表t1に列aおよびbが存在することを引き続き記録します。このため、取得された変更は、列bに値15が挿入されたことを示します。

同じソース・データベースに対する複数の取得プロセス

1つ以上の取得プロセスでソース・データベースに対する変更を取得しているときに、同じソース・データベースに対する変更を取得する取得プロセスを作成する場合、新しい取得プロセスでは、LogMinerデータ・ディクショナリを作成するか、または他の1つ以上の取得プロセスと既存のLogMinerデータ・ディクショナリの1つを共有することができます。

新しい取得プロセスに対して新しいLogMinerデータ・ディクショナリが作成されるかどうかは、CREATE_CAPTUREを実行して取得プロセスを作成したときのfirst_scnパラメータの設定によって異なります。

複数のLogMinerデータ・ディクショナリが存在し、かつ取得プロセスの作成時にfirst_scnパラメータにNULLを指定した場合、新しい取得プロセスでは、1つ以上のチェックポイントを取得済の既存のいずれかの取得プロセスのLogMinerデータ・ディクショナリの共有が自動的に試行されます。DBA_CAPTUREデータ・ディクショナリ・ビューのMAX_CHECKPOINT_SCN列を問い合せると、すべての既存の取得プロセスに対する最大チェックポイントSCNを表示できます。取得プロセスの作成時に、first_scnパラメータがNULL、start_scnパラメータがNULL以外で、start_scnパラメータ設定がすべての既存の取得プロセスに対するすべての先頭SCN値より小さい場合、エラーが発生します。

複数のLogMinerデータ・ディクショナリが存在し、かつ取得プロセスの作成時にfirst_scnパラメータでNULL以外の値を指定した場合、新しい取得プロセスの最初の起動時に新しいLogMinerデータ・ディクショナリが作成されます。この場合、新しい取得プロセスを作成する前に、データベースでDBMS_CAPTURE_ADMパッケージのBUILDプロシージャを実行する必要があります。BUILDプロシージャによって、対応する有効な先頭SCN値が生成されます。この値は、新しい取得プロセスの作成時に指定できます。

BUILDプロシージャによって生成される先頭SCNを検索するには、次の問合せを実行します。

COLUMN FIRST_CHANGE# HEADING 'First SCN' FORMAT 999999999
COLUMN NAME HEADING 'Log File Name' FORMAT A50

SELECT DISTINCT FIRST_CHANGE#, NAME FROM V$ARCHIVED_LOG
WHERE DICTIONARY_BEGIN = 'YES';

BUILDプロシージャを複数回実行すると、この問合せによって複数の行が返される場合があります。

新しい取得プロセスで既存のLogMinerデータ・ディクショナリを共有するか、またはLogMinerデータ・ディクショナリを作成するかを決定する際に考慮する最も重要な要素は、既存の取得プロセスの最大チェックポイントSCN値と新しい取得プロセスの開始SCN値の差です。新しい取得プロセスでは、LogMinerデータ・ディクショナリを共有する場合、先頭SCNより前の変更を取得できないにもかかわらず、共有するLogMinerデータ・ディクショナリの最大チェックポイントSCN以降のREDOログをスキャンする必要があります。新しい取得プロセスの開始SCNが既存の取得プロセスの最大チェックポイントSCNより大幅に大きい場合は、開始SCNに達する前に大量のREDOデータをスキャンする必要があります。

取得プロセスの作成時にfirst_scnパラメータにNULL以外の値を指定した場合、取得プロセスでは、新しいLogMinerデータ・ディクショナリが作成されます。新しい取得プロセスで既存のLogMinerデータ・ディクショナリを共有するか、LogMinerデータ・ディクショナリを作成するかを決定する場合は、次のガイドラインに従ってください。

- 1つ以上の最大チェックポイントSCN値が、指定する開始SCN値より大きい場合、およびこの開始SCNが1つ以上の既存の取得プロセスの先頭SCNより大きい場合は、既存の取得プロセスのLogMinerデータ・ディクショナリを共有することをお薦めします。この場合、開始SCNより小さいチェックポイントSCNが存在すること、およびこのチェックポイントSCNと開始SCNの差が小さいことを想定できます。新しい取得プロセスは、このチェックポイントSCN以降のREDOログのスキャンを開始し、開始SCNに迅速に到達します。

- 開始SCN値より大きい最大チェックポイントSCNがない場合、および最大チェックポイントSCNと開始SCNの差が小さい場合は、既存の取得プロセスのLogMinerデータ・ディクショナリを共有することをお薦めします。新しい取得プロセスは、最大チェックポイントSCN以降のREDOログのスキャンを開始しますが、開始SCNに迅速に到達します。

- 開始SCN値より大きい最大チェックポイントSCNがない場合、および最大チェックポイントSCNと開始SCNの差が大きい場合は、取得プロセスが開始SCNに到達するまでに長い時間かかる可能性があります。この場合は、新しい取得プロセスでLogMinerデータ・ディクショナリを作成することをお薦めします。取得プロセスの最初の起動時には新しいLogMinerデータ・ディクショナリの作成に時間がかかりますが、先頭SCNと開始SCNに同じ値を指定すると、大量のREDOデータをスキャンする必要がなくなります。

図7-4に、これらのガイドラインを示します。

図7-4 LogMinerデータ・ディクショナリを共有するかどうかの決定

注意:

- DBMS_STREAMS_ADMパッケージのいずれかのプロシージャを使用して取得プロセスを作成することは、CREATE_CAPTUREプロシージャでfirst_scnパラメータとstart_scnパラメータにNULLを指定することと同じです。

- 新しい取得プロセスでデータベース・オブジェクトに対する変更を取得する場合、これらのデータベース・オブジェクトをインスタンス化のために準備する必要があります。新しい取得プロセスで、これらのデータベース・オブジェクトがインスタンス化のために準備されている1つ以上の取得プロセスとLogMinerデータ・ディクショナリを共有する場合でも、この要件は当てはまります。

関連項目:

- 「先頭SCNおよび開始SCN」

- 「取得プロセスのチェックポイント」

- CREATE_CAPTUREプロシージャのfirst_scnパラメータおよびstart_scnパラメータの設定の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

Oracle Streamsデータ・ディクショナリ

伝播および適用プロセスでは、Oracle Streamsデータ・ディクショナリを使用して、特定のソース・データベースのデータベース・オブジェクトが追跡されます。Oracle Streamsデータ・ディクショナリは、ソース・データベースで1つ以上のデータベース・オブジェクトをインスタンス化のために準備するたびに移入されます。具体的には、データベース・オブジェクトをインスタンス化のために準備すると、そのデータベース・オブジェクトがREDOログに記録されます。取得プロセスでは、REDOログのスキャン時に、この情報を使用して、ソース・データベースのローカルのOracle Streamsデータ・ディクショナリが移入されます。ローカル取得の場合、このOracle Streamsデータ・ディクショナリはソース・データベースに存在します。ダウンストリーム取得の場合、このOracle Streamsデータ・ディクショナリはダウンストリーム・データベースに存在します。

データベース・オブジェクトをインスタンス化のために準備すると、伝播(データベース・オブジェクトに対する変更の伝播)および適用プロセス(データベース・オブジェクトに対する変更の適用)で、データベース・オブジェクトに関する情報が必要であることがOracle Streamsに通知されます。これらの変更を伝播または適用するデータベースでは、変更が発生したソース・データベースのOracle Streamsデータ・ディクショナリが必要となります。

オブジェクトをインスタンス化のために準備した後、取得プロセスによってオブジェクトに対するDDL文が処理される際に、ローカルのOracle Streamsデータ・ディクショナリが更新されます。また、このDDL文に関する情報が含まれている内部メッセージが取得され、取得プロセスのキューに配置されます。その後、伝播によって、これらの内部メッセージをデータベースの宛先キューに伝播できます。

Oracle Streamsデータ・ディクショナリはマルチバージョンです。データベースに複数の伝播および適用プロセスが含まれている場合は、これらすべての伝播および適用プロセスで特定のソース・データベースに対して同じOracle Streamsデータ・ディクショナリが使用されます。データベースには、特定のソース・データベースに対するOracle Streamsデータ・ディクショナリを1つのみ含めることができます。ただし、複数のソース・データベースからの変更を伝播または適用する場合は、複数のOracle Streamsデータ・ディクショナリを含めることができます。

関連項目:

- インスタンス化の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- 「伝播用のOracle Streamsデータ・ディクショナリ」

- 「適用プロセス用のOracle Streamsデータ・ディクショナリ」

取得プロセス・ルールの評価

取得プロセスは、ポジティブ・ルール・セットおよびネガティブ・ルール・セットに対してREDOログ内で検出した変更を評価します。取得プロセスは、まずネガティブ・ルール・セットに対して変更を評価します。ネガティブ・ルール・セットの1つ以上のルールが変更に対してTRUEと評価されると、この変更は廃棄されます。一方、変更に対してTRUEと評価されるルールがネガティブ・ルール・セットに含まれていない場合、この変更はネガティブ・ルール・セットを満たしています。変更が取得プロセスのネガティブ・ルール・セットを満たす場合、取得プロセスは、ポジティブ・ルール・セットに対して変更を評価します。ポジティブ・ルール・セットの1つ以上のルールが変更に対してTRUEと評価される場合、この変更はポジティブ・ルール・セットを満たしています。一方、変更に対してTRUEと評価されるルールがポジティブ・ルール・セットに含まれていない場合、この変更は廃棄されます。取得プロセスにルール・セットが1つのみ含まれている場合は、この1つのルール・セットに対してのみ変更が評価されます。

実行中の取得プロセスは、次の一連のアクションを実行して変更を取得します。

1. REDOログ内で変更を検索します。

2. REDOログ内の変更の事前フィルタ処理を実行します。この手順で、取得プロセスは、基本レベルでルール・セット内のルールを評価し、REDOログ内で検出された変更を2つのカテゴリに分類します。一方のカテゴリはLCRに変換する変更で、もう一方はLCRに変換しない変更です。事前フィルタ処理は、2つのフェーズで実行されます。1つ目のフェーズでは、事前フィルタ処理で評価可能な情報に、スキーマ名、オブジェクト名、コマンド・タイプなどが含まれます。変更をLCRに変換する必要があるかどうかの判断に追加の情報が必要な場合、事前フィルタ処理の2つ目のフェーズで評価可能な情報に、可能な場合にタグの値および列値が含まれます。
事前フィルタ処理は、不完全な情報を使用して実行される安全な最適化です。この手順では、これ以後に処理対象となる関連する変更が次のように識別されます。

- 変更が取得プロセスのルール・セットを満たす場合、取得プロセスは変更をLCRに変換します。この場合、手順3に進みます。

- 変更が取得プロセスのルール・セットを満たさない場合、取得プロセスは変更をLCRに変換しません。

- MAYBE評価の場合、ルール評価は次のとおり行われます。

- 取得プロセスのポジティブ・ルール・セットおよびネガティブ・ルール・セットの両方に対して変更がMAYBEと評価された場合、この変更が両方のルール・セットを確実に満たすかどうかを判別するための十分な情報が取得プロセスに含まれていない可能性があります。この場合、追加の評価が必要です。手順3に進みます。

- 取得プロセスのネガティブ・ルール・セットに対して変更がFALSEと評価され、ポジティブ・ルール・セットに対してMAYBEと評価された場合、この変更が両方のルール・セットを確実に満たすかどうかを判別するための十分な情報が取得プロセスに含まれていない可能性があります。この場合、追加の評価が必要です。手順3に進みます。

- 取得プロセスのネガティブ・ルール・セットに対して変更がMAYBEと評価され、ポジティブ・ルール・セットに対してTRUEと評価された場合、この変更が両方のルール・セットを確実に満たすかどうかを判別するための十分な情報が取得プロセスに含まれていない可能性があります。この場合、追加の評価が必要です。手順3に進みます。

- 取得プロセスのネガティブ・ルール・セットに対して変更がTRUEと評価され、ポジティブ・ルール・セットに対してMAYBEと評価された場合、取得プロセスはこの変更を廃棄します。

- 取得プロセスのネガティブ・ルール・セットに対して変更がMAYBEと評価され、ポジティブ・ルール・セットに対してFALSEと評価された場合、取得プロセスはこの変更を廃棄します。

3. 事前フィルタ処理に基づいて、取得プロセスのルール・セットを満たすか、または満たす可能性がある変更をLCRに変換します。

4. LCRのフィルタ処理を実行します。この手順で、取得プロセスは各LCR内の情報に関するルールを評価して、LCRを2つのカテゴリに分けます。一方のカテゴリはエンキューする必要があるLCRで、もう一方は廃棄する必要があるLCRです。

5. 取得プロセスのルール・セットを満たさなかったためエンキューしないLCRを廃棄します。

6. 残っている取得LCRを、取得プロセスに関連付けられているキューにエンキューします。

たとえば、取得プロセスのポジティブ・ルール・セットに対して、department_idが50であるhr.employees表に対する変更を取得するというルールが定義されているとします。この取得プロセスに他のルールは定義されておらず、そのparallelismパラメータは1に設定されています。

このルールが定義されている場合に、hr.employees表に対するUPDATE文によって表の50行が変更されるとします。この取得プロセスは、行の変更ごとに次の一連のアクションを実行します。

1. REDOログ内でUPDATE文によって発生する次の変更を検索します。

2. hr.employees表に対するUPDATE文によって変更が発生しており、取得する必要があると判断します。変更が異なる表に対するものの場合、取得プロセスはその変更を無視します。

3. 変更を取得してLCRに変換します。

4. LCRをフィルタ処理し、department_idが50である行が関係しているかどうかを判断します。

5. LCRに含まれている行のdepartment_idが50の場合は、取得プロセスに関連付けられているキューにLCRをエンキューします。または、LCRに含まれている行のdepartment_idが50でないか、またはdepartment_idが含まれていない場合は、LCRを廃棄します。

関連項目:

- 「取得プロセスのサブコンポーネント」

- Oracle Streamsクライアントのルール・セット、およびメッセージがルール・セットを満たす仕組みの詳細は、第5章「Oracle Streamsでのルールの使用方法」を参照

図7-5に、取得プロセス・ルールの評価をフロー・チャート形式で示します。

図7-5 取得プロセス・ルールの評価を示すフロー・チャート

8 キューの高度な概念

次の各項では、キューでのメッセージのステージングやキュー間でのメッセージの伝播の概念について説明します。

- 保護キュー

- トランザクション・キューと非トランザクション・キュー

- コミット時間キュー

関連項目:

- 「キュー間でのメッセージの伝播」

- 「キューの管理」

- 「キューの制限事項」

保護キュー

保護キューは、エンキューやデキューなどのキュー操作を実行できる1人以上のデータベース・ユーザーにOracle Streamsアドバンスト・キューイング(AQ)・エージェントを明示的に関連付ける必要があるキューです。保護キューの所有者はキューに対してすべてのキュー操作を実行できますが、他のユーザーは保護キュー・ユーザーとして構成されていないかぎり、保護キューに対するキュー操作を実行できません。Oracle Streamsでは、保護キューを使用して、適切なユーザーおよびOracle Streamsクライアントのみがメッセージのエンキューとデキューを確実に行うことができます。

保護キューおよびSET_UP_QUEUEプロシージャ

DBMS_STREAMS_ADMパッケージのSET_UP_QUEUEプロシージャを使用して作成されたすべてのANYDATAキューは、保護キューです。SET_UP_QUEUEプロシージャを使用してキューを作成すると、queue_userパラメータで指定したユーザーは、可能であればキューの保護キュー・ユーザーとして自動的に構成されます。また、キュー・ユーザーには、キューに対するENQUEUEおよびDEQUEUE権限が付与されます。メッセージをエンキューおよびデキューするには、キュー・ユーザーはDBMS_STREAMS_MESSAGINGパッケージまたはDBMS_AQ パッケージのEXECUTE権限も必要です。SET_UP_QUEUEプロシージャでは、これらのいずれの権限も付与されません。また、メッセージは、デキューできるサブスクライバが構成されるまで、キューにエンキューできません。

キュー・ユーザーを保護キュー・ユーザーとして構成するために、SET_UP_QUEUEプロシージャでは、存在しない場合はユーザー名と同じ名前でOracle Streams AQエージェントが作成されます。ユーザーは、このエージェントを使用してキューに対するキュー操作を実行する必要があります。この名前のエージェントがすでに存在し、そのキュー・ユーザーのみに関連付けられている場合は、既存のエージェントが使用されます。SET_UP_QUEUEでは、エージェントとユーザーを指定して、DBMS_AQADMパッケージのENABLE_DB_ACCESSプロシージャが実行されます。

DBMS_STREAMS_ADMパッケージのSET_UP_QUEUEプロシージャを使用して保護キューを作成し、キュー所有者ではなくqueue_userパラメータで指定していないユーザーに、キューに対する操作の実行を許可する必要がある場合は、そのユーザーを手動でキューの保護キュー・ユーザーとして構成できます。また、SET_UP_QUEUEプロシージャを再実行して、キューに異なるqueue_userを指定することもできます。この場合、SET_UP_QUEUEではキューの作成をスキップしますが、queue_userで指定したユーザーがキューの保護キュー・ユーザーとして構成されます。

DBMS_AQADMパッケージを使用してANYDATAキューを作成する場合は、CREATE_QUEUE_TABLEプロシージャを実行するときにsecureパラメータを使用して、キューが保護キューかどうかを指定します。このプロシージャを実行するときにsecureパラメータにTRUEを指定すると、キューは保護キューになります。DBMS_AQADMパッケージを使用して保護キューを作成し、ユーザーが保護キューに対してキュー操作を実行できるようにする必要がある場合は、これらの保護キュー・ユーザーを手動で構成する必要があります。

保護キューおよびOracle Streamsクライアント

取得プロセスまたは適用プロセスを作成すると、Oracle Streamsプロセスに関連付けられている保護キューのOracle Streams AQエージェントが自動的に構成され、Oracle Streamsプロセスを実行するユーザーは、このキューの保護キュー・ユーザーとして自動的に指定されます。したがって、取得プロセスは保護キューを自動的にエンキューするように構成され、適用プロセスは保護キューから自動的にデキューするように構成されます。どちらの場合も、Oracle Streams AQエージェントの名前はOracle Streamsクライアントと同じになります。

取得プロセスの場合は、capture_userとして指定したユーザーが、取得プロセスを実行するユーザーとなります。適用プロセスの場合は、apply_userとして指定したユーザーが、適用プロセスを実行するユーザーとなります。capture_userまたはapply_userを指定しなければ、Oracle Streamsプロセスの作成プロシージャを起動したユーザーが、Oracle Streamsプロセスを実行するユーザーとなります。

同期取得を作成すると、同期取得と同じ名前を持つ保護キューのOracle Streams AQエージェントは、capture_userに指定されたユーザーに関連付けられます。capture_userが指定されていない場合は、同期取得を作成するプロシージャを起動したユーザーがcapture_userになります。capture_userは、このキューの保護キュー・ユーザーとして自動的に指定されます。そのため、同期取得では、保護キューを自動的にエンキューできます。

取得プロセスまたは同期取得のcapture_user、あるいは適用プロセスのapply_userを変更すると、指定したcapture_userまたはapply_userはOracle Streamsクライアントで使用されるキューの保護キュー・ユーザーとして構成されます。ただし、古い取得ユーザーまたは適用ユーザーは、キューの保護キュー・ユーザーとして構成されたままです。古いユーザーを削除するには、そのユーザーと関連するOracle Streams AQエージェントを指定して、DBMS_AQADMパッケージのDISABLE_DB_ACCESSプロシージャを実行します。また、不要になったエージェントは削除できます。DBA_AQ_AGENT_PRIVSデータ・ディクショナリ・ビューを問い合せると、Oracle Streams AQエージェントとその関連ユーザーを表示できます。

メッセージ・クライアントを作成すると、メッセージ・クライアントと同じ名前の保護キューのOracle Streams AQエージェントは、メッセージ・クライアントの作成プロシージャを実行するユーザーに関連付けられます。このメッセージ・クライアント・ユーザーは、このキューの保護キュー・ユーザーとして自動的に指定されます。そのため、このユーザーはメッセージ・クライアントを使用して、キューからメッセージをデキューできます。

取得プロセス、同期取得、適用プロセスまたはメッセージ・クライアントは、1ユーザーのみに関連付けることができます。ただし、ユーザーは、複数の取得プロセス、同期取得、適用プロセスおよびメッセージ・クライアントを含む複数のOracle Streamsクライアントに関連付けることができます。たとえば、適用プロセスに適用ユーザーとしてhrとoeの両方を含めることはできませんが、hrを複数の適用プロセスの適用ユーザーにすることはできます。

取得プロセス、同期取得、適用プロセスまたはメッセージ・クライアントを削除しても、これらのOracle Streamsクライアントの保護キュー・ユーザーとして構成されていたユーザーは、引き続きキューの保護キュー・ユーザーのままです。保護キュー・ユーザーとしてのユーザーを削除するには、ユーザーごとにDBMS_AQADMパッケージのDISABLE_DB_ACCESSプロシージャを実行します。また、不要になったエージェントは削除できます。

注意:
伝播および保護キューについては構成は必要ありません。つまり、伝播の削除時に、伝播のキューから保護キュー・ユーザーを削除するための追加の手順は必要ありません。

関連項目:

- 「保護キューでのユーザー操作の有効化」

- 「保護キューでのユーザー操作の無効化」

- Oracle Streams AQエージェントとDBMS_AQADMパッケージの使用方法の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

トランザクション・キューと非トランザクション・キュー

トランザクション・キューは、複数のメッセージを1つのトランザクションとして適用されるセットにグループ化できるキューです。つまり、適用プロセスでは、グループ内のすべてのメッセージを適用した後にCOMMITを実行します。非トランザクション・キューは、各メッセージが個別のトランザクションであるキューです。つまり、適用プロセスは、各メッセージが適用された後に、COMMITを実行します。どちらの場合も、メッセージはLCRまたはユーザー・メッセージのいずれかです。

DBMS_STREAMS_ADMパッケージのSET_UP_QUEUEプロシージャでは、常にトランザクション・キューが作成されます。トランザクション・キューと非トランザクション・キューの違いが重要になるのは、アプリケーション、同期取得または適用プロセスによってエンキューされたメッセージに対してのみです。適用プロセスは、常にソース・データベースで実行されたトランザクションが保つトランザクション内で取得LCRを適用します。

表8-1に、メッセージ・タイプとキューの型ごとに、適用プロセスの動作を示します。

表8-1 トランザクション・キューと非トランザクション・キューに対する適用プロセスの動作

メッセージ・タイプ

トランザクション・キュー

非トランザクション・キュー

取得LCR

適用プロセスは元のトランザクションを保持します。

適用プロセスは元のトランザクションを保持します。

永続LCRまたは永続ユーザー・メッセージ

ユーザーが指定したメッセージのグループを、1つのトランザクションとして適用します。

各メッセージをそれぞれのトランザクション内で適用します。

ソース・データベースで実行されたトランザクションを保持する必要がある場合は、トランザクション・キューを使用してメッセージを格納します。同期取得で取得されたLCRがトランザクション・キューに格納されていることを確認します。

関連項目:

- 「キューの管理」

- メッセージのグループ化の詳細は、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドを参照

コミット時間キュー

永続キュー内のメッセージが参照またはデキューされる順序を制御できます。キュー内のメッセージの順序付けは、キュー表によって決定されます。キュー表の作成時にキュー表に対してメッセージの順序を指定できます。具体的には、DBMS_AQADM.CREATE_QUEUE_TABLEプロシージャのsort_listパラメータによって、メッセージの順序付けの方法が決定されます。コミット時間キュー内の各メッセージは、それぞれのメッセージをエンキューするトランザクションのコミット時に取得される近似コミット・システム変更番号(近似CSCN)によって順序付けされます。

コミット時間による順序付けはキュー表に対して指定され、そのキュー表を使用するキューをコミット時間キューと呼びます。DBMS_AQADM.CREATE_QUEUE_TABLEプロシージャのsort_listパラメータにcommit_timeを指定すると、生成されるキュー表でコミット時間による順序付けが使用されます。

Oracle Database 10g リリース2以上では、DBMS_STREAMS_ADMパッケージのSET_UP_QUEUEプロシージャによって作成されるキュー表のsort_listは、デフォルトで、commit_timeに設定されています。Oracle Database 10g リリース2より前のリリースでは、デフォルトで、enq_timeに設定されています(詳細は、次の項を参照)。SET_UP_QUEUEプロシージャのqueue_tableパラメータに既存のキュー表が指定されている場合、SET_UP_QUEUEによって作成されるキュー内でのメッセージの順序付けは、既存のキュー表によって決定されます。

注意:
同期取得では、トランザクションが確実に順序付けされるように、常にコミット時間キューにエンキューします。

コミット時間キューを使用する場合

Oracle Database内のキューにメッセージをエンキューすることによって、ユーザーまたはアプリケーションが情報を共有できます。エンキューされたメッセージは、単一のデータベース内で共有したり、他のデータベースに伝播することができます。メッセージは、LCRの場合とユーザー・メッセージの場合があります。たとえば、アプリケーション固有のメッセージが発生した場合や、データベースの変更に対してトリガーが起動された場合に、メッセージをエンキューできます。また、異機種間環境では、Oracle以外のデータベースで発生したメッセージを、アプリケーションでOracle Databaseでエンキューできます。

CREATE_QUEUE_TABLEプロシージャのsort_listパラメータには、commit_timeの他に、priorityとenq_timeを設定できます。priorityを設定すると、エンキュー時に指定された優先順位の高いものから順にメッセージが順序付けされます。enq_timeを設定すると、エンキューされた時間の古いものから順にメッセージが順序付けされます。

コミット時間キューは、環境でメッセージの同時エンキューに対して次のいずれかの要件をサポートする必要がある場合に役立ちます。

- デキュー時のトランザクション間の依存性による順序付け

- キュー内のメッセージの一貫性のある参照

コミット時間キューでは、これらの要件がサポートされます。優先順位またはエンキュー時間による順序付けでは、トランザクション間の依存性の違反および一貫性のない参照が許可されるため、いずれの順序付けでもこれらの要件はサポートされません。これらの設定では、元の依存性にかかわらずメッセージがデキューされるため、トランザクションの間の依存性の違反が許可されます。また、これらの設定では、デキュー操作を伴わずに実行される複数の参照によってメッセージの様々なセットが生成されるため、キュー内のメッセージの一貫性のない参照が許可されます。

関連項目:

- 「メッセージのステージングと伝播の概要」

- 「キュー間でのメッセージの伝播」

- 異機種間での情報の共有の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

デキュー時のトランザクション間の依存性による順序付け

1つのデータベース・トランザクションを正常にコミットするために別のデータベース・トランザクションのコミットを必要とする場合、トランザクション間の依存性が発生します。データベース・トランザクションに関する情報を含むメッセージをエンキューできます。たとえば、データベース・トリガーによってメッセージのエンキューを実行できます。図8-1に、エンキュー時間による順序付けで、これらのメッセージのデキュー時にトランザクション間の依存性による順序付けがサポートされないことを示します。

図8-1 デキュー時のトランザクション間の依存性の違反

図8-1に、エンキュー時間による順序付けで、トランザクション間の依存性による順序付けが違反される場合があることを示します。メッセージe2をエンキューしたトランザクションは、メッセージe1およびe3をエンキューしたトランザクションがコミットされる前にコミットされています。メッセージe3に含まれる更新は、メッセージe2に含まれる挿入に依存しています。そのため、トランザクション間の依存性をサポートする正しいデキュー順序は、e2、e1、e3になります。ただし、エンキュー時間による順序付けでは、e2の前にe3をデキューできます。そのため、e3のデキュー時に、e3に含まれる変更をアプリケーションがhr.employees表に適用しようとすると、エラーが発生します。また、3つのメッセージがすべてデキューされた後、e3に含まれる変更が実行されていないために、hr.employees表の行に誤った情報が含まれています。

キュー内のメッセージの一貫性のある参照

図8-2に、エンキュー時間による順序付けで、キュー内のメッセージの一貫性のある参照がサポートされないことを示します。

図8-2 キュー内のメッセージの一貫性のない参照

図8-2に、エンキュー時間による順序付けで、クライアントがキュー内のメッセージを参照するときに一定の順序が保証されないことを示します。セッション1および2は、メッセージをエンキューしている同時セッションです。セッション3は、エンキューされた3つのメッセージを異なる順序で返すクライアント参照の2つのセットを示します。クライアントがメッセージの決定的な順序付けを必要とする場合は、このクライアントに対して障害が発生します。たとえば、クライアントが参照を実行してプログラム状態を開始すると、後続のデキューによって予想と異なる順序でメッセージが返される場合があります。

コミット時間キューの仕組み

キューにエンキューされたメッセージのコミット・システム変更番号(CSCN)は、メッセージを含むトランザクションのコミットに関するREDOレコードがOracle DatabaseでREDOログに書き込まれるまで不明です。メッセージのエンキュー時にCSCNを記録することはできません。コミット時間キューでは、トランザクションのコミット時のデータベースの現行のSCNが、トランザクション内のすべてのメッセージに対する近似CSCNとして使用されます。コミット時間キュー内のメッセージの順序は、メッセージをエンキューしたトランザクションの近似CSCNに基づきます。

コミット時間キューでは、近似CSCNを使用してメッセージの決定的な順序を確立できるまで、デキューおよび参照操作でトランザクション内のメッセージを参照することはできません。複数のトランザクションによって同じコミット時間キューにメッセージが同時にエンキューされる場合、複数のトランザクションがほぼ同時にコミットされたり、これらのトランザクションのコミット間隔が重複する可能性があります。この場合、これらのトランザクション内のメッセージは、トランザクションがコミットされるまで参照できません。その時点では、メッセージの順序は各トランザクションの近似CSCNを使用して決定できます。エンキュー時間ではなくメッセージの近似CSCNを使用することによって、依存性が保持されます。順序が完全に決定されたメッセージのみを参照可能にすることによって、参照の読取りの一貫性が保持されます。

コミット時間キューは、常に、データベース・トランザクションに基づくメッセージに対してトランザクション間の依存性による順序付けを保持します。ただし、アプリケーションおよびユーザーが、データベース・トランザクションに基づかないメッセージをエンキューする場合があります。これらのメッセージでは、トランザクション間に依存性が存在する場合には、アプリケーションまたはユーザーは、トランザクションが正しい順序でコミットされること、および依存するトランザクションのコミット間隔が重複しないことを保証する必要があります。

コミット時間キューによって記録されたトランザクションの近似CSCNには、これらのトランザクションの実際のコミット順序が反映されない場合があります。たとえば、トランザクション1およびトランザクション2は、メッセージのエンキュー後、ほぼ同時にコミットされる可能性があります。トランザクション1の近似CSCNがトランザクション2の近似CSCNより小さい場合に、トランザクション2よりもトランザクション1の方がコミットの完了に時間がかかる場合があります。この場合、トランザクション2の実際のCSCNは、トランザクション1の実際のCSCNより小さくなります。

注意:
CREATE_QUEUE_TABLEのsort_listパラメータを次のように設定できます。

priority, commit_time

この場合、まず優先順位によって、次にコミット時間によって順序付けが行われます。そのため、この設定は、優先順位の異なるメッセージに対して、トランザクション間の依存性による順序付けおよび参照の読取り一貫性を保証しません。ただし、優先順位が同じメッセージに対しては、トランザクション間の依存性による順序付けと参照の読取り一貫性が保証されます。

関連項目:
コミット時間キューの作成の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

9 伝播の高度な概念

次の各項では、キューでのメッセージのステージングやキュー間でのメッセージの伝播の概念について説明します。

- 伝播ジョブ

- 伝播用のOracle Streamsデータ・ディクショナリ

- バイナリ・ファイルの伝播

関連項目:

- 「キュー間でのメッセージの伝播」

- 「Oracle Streamsの伝播および伝播ジョブの管理」

- Oracle Streams AQの伝播インフラストラクチャの詳細は、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドを参照

伝播ジョブ

Oracle Streams伝播は、Oracle Schedulerを使用して内部的に構成されます。したがって、伝播ジョブは、ソース・キューから宛先キューにメッセージを伝播するジョブです。他のOracle Schedulerジョブと同様に、伝播ジョブには所有者が存在し、必要に応じてスレーブ・プロセス(jnnn)を使用してジョブを実行します。

次のプロシージャでは、これらのプロシージャによって伝播が作成されるときに、伝播ジョブを作成できます。

- DBMS_STREAMS_ADMパッケージのADD_GLOBAL_PROPAGATION_RULESプロシージャ

- DBMS_STREAMS_ADMパッケージのADD_SCHEMA_PROPAGATION_RULESプロシージャ

- DBMS_STREAMS_ADMパッケージのADD_TABLE_PROPAGATION_RULESプロシージャ

- DBMS_STREAMS_ADMパッケージのADD_SUBSET_PROPAGATION_RULEプロシージャ

- DBMS_PROPAGATION_ADMパッケージのCREATE_PROPAGATIONプロシージャ

このいずれかのプロシージャによって伝播が作成されると、次の場合に新しい伝播ジョブが作成されます。

- queue_to_queueパラメータをTRUEに設定した場合、常に伝播に対して新しい伝播ジョブが作成されます。各キュー・ツー・キュー伝播には独自の伝播ジョブが作成されます。ただし、スレーブ・プロセスは複数の伝播ジョブで使用できます。

- queue_to_queueパラメータをFALSEに設定した場合、指定されたソース・キューおよびデータベース・リンクの伝播ジョブが存在しない場合に伝播ジョブが作成されます。指定したソース・キューおよびデータベース・リンクの伝播ジョブがすでに存在する場合、新しい伝播は、既存の伝播ジョブを使用し、この伝播ジョブが、同じデータベース・リンクを使用する他のすべてのキュー・ツーdblink伝播と、この伝播ジョブを共有します。

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

- 伝播のスケジューリングとOracle Streams伝播

- 伝播ジョブとRESTRICTED SESSION

注意:
ソース・キューの所有者が伝播を実行しますが、伝播ジョブの所有者はそれを作成したユーザーです。この2人のユーザーは同一であっても異なっていてもかまいません。

関連項目:

- 「キュー・ツー・キュー伝播」

- Oracle Schedulerの詳細は、『Oracle Database管理者ガイド』を参照

伝播のスケジューリングとOracle Streams伝播

伝播スケジュールでは、伝播ジョブでソース・キューから宛先キューにメッセージを伝播する頻度を指定します。各キュー・ツー・キュー伝播には独自の伝播ジョブおよび伝播スケジュールがありますが、同じ伝播ジョブを使用するキュー・ツーdblink伝播では同じ伝播スケジュールが共有されます。

デフォルトの伝播スケジュールは、DBMS_STREAMS_ADMまたはDBMS_PROPAGATION_ADMパッケージのプロシージャによって新しい伝播ジョブが作成されるときに設定されます。

デフォルトのスケジュールのプロパティは次のとおりです。

- 開始時間はSYSDATE()です。

- 継続期間は無限を意味するNULLです。

- 次回の時刻はNULLで、これは現行の期間が終了した直後に伝播が再開されることを意味します。

- 待機時間は3秒で、これはキューが空になってから伝播ジョブを再発行するまでの待機時間です。したがって、メッセージがエンキューされてから伝播されるまでの伝播期間での最大待機時間(秒単位)です。

DBMS_AQADMパッケージのALTER_PROPAGATION_SCHEDULEプロシージャを使用すると、伝播ジョブのスケジュールを変更できます。伝播ジョブに対する変更は、伝播ジョブを使用するすべての伝播に影響を及ぼします。

関連項目:

- 「伝播ジョブ」

- 「伝播ジョブのスケジュールの変更」

伝播ジョブとRESTRICTED SESSION

システム起動時にSTARTUP RESTRICT文を発行して制限付きセッションが有効化された場合、伝播スケジュールが有効化された伝播ジョブでのメッセージの伝播は行われません。制限付きセッションが無効化されると、有効化されて実行準備が整っている各伝播スケジュールは、使用可能なスレーブ・プロセスがあるときに実行されます。

SQL文ALTER SYSTEM ENABLE RESTRICTED SESSIONによって実行中のデータベースで制限付きセッションが有効化された場合、実行中の伝播ジョブは完了するまで引き続き実行されます。ただし、伝播スケジュールに対して発行された新規の伝播ジョブは開始しません。したがって、有効化されたスケジュールの伝播が最終的に停止する可能性があります。

伝播用のOracle Streamsデータ・ディクショナリ

ソース・データベースでデータベース・オブジェクトのインスタンス化が準備されている場合、オブジェクトに対する変更が取得プロセスによって取得されるデータベースで、Oracle Streamsデータ・ディクショナリが自動的に移入されます。Oracle Streamsデータ・ディクショナリは、ソース・データベースのプライマリ・データ・ディクショナリ内の一部の情報のマルチバージョン・コピーです。Oracle Streamsデータ・ディクショナリでは、ソース・データベースのオブジェクト番号、オブジェクト・バージョン情報および内部列番号が表名、列名および列のデータ型にマップされます。このマッピングによって、メッセージ内部に名前ではなく番号を格納できるため、各取得LCRのサイズが最小に保たれます。

ソース・データベースで取得LCRを伝播するデータベースでルールを評価するために、ソース・データベースにあるOracle Streamsデータ・ディクショナリ内のマッピング情報が必要になります。このマッピング情報を伝播で使用できるように、OracleはOracle Streamsの伝播がある各データベースでマルチバージョンのOracle Streamsデータ・ディクショナリを自動的に移入します。ソース・データベースにあるOracle Streamsデータ・ディクショナリからの関連情報を含む内部メッセージは、ソース・データベースから取得LCRを受信する他のすべてのデータベースに自動的に送信されます。

キュー内のこれらの内部メッセージに含まれるOracle Streamsデータ・ディクショナリ情報は、伝播によって伝播される場合と、伝播されない場合があります。どのOracle Streamsデータ・ディクショナリ情報が伝播されるかは、伝播のルール・セットによって決定されます。伝播が表のOracle Streamsデータ・ディクショナリ情報を検出すると、ソース・データベース名、表名および表の所有者などの特定の情報を使用して、その伝播のルール・セットが評価されます。これらのルール・セットの特定のルールを評価した結果、指定されたデータベースの特定の表に関連するLCRがあると判断された場合、その表のOracle Streamsデータ・ディクショナリ情報が伝播されます。

Oracle Streamsデータ・ディクショナリ情報が宛先キューに伝播されると、宛先キューにエンキューされるのみでなく、宛先キューを含むデータベースのOracle Streamsデータ・ディクショナリにも取り込まれます。したがって、有向ネットワーク構成で宛先キューを読み込む伝播は、Oracle Streamsデータ・ディクショナリの移入を待たずに、LCRを即時に転送できます。この方法により、ソース・データベースのOracle Streamsデータ・ディクショナリは常に、関連するデータベース・オブジェクトの正しい状態を、これらのデータベース・オブジェクトに関連するLCRに反映します。

関連項目:

- 「Oracle Streamsデータ・ディクショナリ」

- 第5章「Oracle Streamsでのルールの使用方法」

バイナリ・ファイルの伝播

Oracle Streamsを使用すると、データベース間でバイナリ・ファイルを伝播できます。これを行うには、1つ以上のBFILE属性をメッセージ・ペイロードに入れ、メッセージをリモート・キューに伝播します。ペイロードで参照される各BFILEは、メッセージが伝播された後、メッセージの伝播がコミットされる前にリモート・データベースに転送されます。伝播された各BFILEのディレクトリ・オブジェクトとファイル名は保持されますが、ソース・データベースと宛先データベースの異なるディレクトリにディレクトリ・オブジェクトをマップできます。メッセージ・ペイロードは、ANYDATAペイロードにラップされたBFILE、またはANYDATAペイロードにラップされたオブジェクトの1つ以上のBFILE属性になります。

メッセージのペイロードでは、次のものがサポートされません。

- 1つ以上のBFILE属性を含むVARRAY

- 1つ以上のBFILE属性を含むANYDATA属性を持つ、ユーザー定義型オブジェクト

Oracle StreamsでのBFILEの伝播には、DBMS_FILE_TRANSFER.PUT_FILEプロシージャと同じ制限があります。

関連項目:
DBMS_FILE_TRANSFERパッケージを使用したファイルの転送方法の詳細は、『Oracle Database管理者ガイド』および『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

10 適用プロセスの高度な概念

次の各項では、Oracle Streamsでの情報のコンシュームについて説明します。

- 適用プロセスの作成

- 適用プロセスおよび依存性

- 表へのDML変更の適用に関する考慮事項

- DDL変更を適用するときの考慮事項

- 適用プロセスのインスタンス化SCNと非処理SCN

- 適用プロセスの最も古いSCN

- 適用プロセスの最低水位標と最高水位標

- 適用プロセスおよびトリガー

- 適用プロセス用のOracle Streamsデータ・ディクショナリ

- 単一データベースでの複数の適用プロセス

関連項目:

- 「適用プロセスによる暗黙的コンシューム」

- 第17章「Oracle Streams情報コンシュームの管理」

- 第26章「Oracle Streams適用プロセスの監視」

適用プロセスの作成

適用プロセスは、DBMS_STREAMS_ADMパッケージまたはDBMS_APPLY_ADMパッケージを使用して作成できます。DBMS_STREAMS_ADMパッケージを使用すると、一部の構成オプションにデフォルトが自動的に使用されるため、適用プロセスをより簡単に作成できます。DBMS_APPLY_ADMパッケージを使用すると、適用プロセスをより柔軟に作成できます。

DBMS_APPLY_ADMパッケージのCREATE_APPLYプロシージャを実行して適用プロセスを作成する場合は、apply_captured、apply_database_linkおよびapply_tagパラメータに対してデフォルト以外の値を指定できます。これによって、DBMS_STREAMS_ADMパッケージまたはDBMS_RULE_ADMパッケージのプロシージャを使用して、適用プロセスのルール・セットにルールを追加できます。

1つのデータベースに複数の適用プロセスを作成した場合、これらの適用プロセスは完全に独立したものになります。同じソース・データベースからのLCRを適用する場合でも、これらの適用プロセスが相互に同期化することはありません。

表10-1に、適用プロセスの作成にDBMS_STREAMS_ADMパッケージを使用した場合とDBMS_APPLY_ADMパッケージを使用した場合の相違点を示します。

表10-1 DBMS_STREAMS_ADMを使用した場合とDBMS_APPLY_ADMを使用した場合の適用プロセスの作成

DBMS_STREAMS_ADMパッケージ

DBMS_APPLY_ADMパッケージ

適用プロセスに対して自動的にルール・セットが作成され、このルール・セットに対して自動的にルールを追加することができます。ルール・セットは、inclusion_ruleパラメータがTRUE(デフォルト)に設定されている場合はポジティブ・ルール・セットになります。inclusion_ruleパラメータがFALSEに設定されている場合はネガティブ・ルール・セットになります。適用プロセスの作成後は、DBMS_STREAMS_ADMおよびDBMS_RULE_ADMパッケージのプロシージャを使用して適用プロセスのルール・セットおよびルールを管理できます。

適用プロセスの作成前または作成後に、適用プロセスに対して1つ以上のルール・セットおよびルールを作成します。DBMS_RULE_ADMパッケージのプロシージャを使用すると、適用プロセスの作成前または作成後に適用プロセスに対してルール・セットおよびルールを作成できます。DBMS_STREAMS_ADMパッケージのプロシージャを使用すると、適用プロセスの作成後に適用プロセスに対してルール・セットおよびルールを作成できます。

適用プロセスでは、ローカル・データベースでのみメッセージを適用できます。

適用プロセスの作成時に、ローカル・データベースまたはリモート・データベースのいずれでメッセージを適用するかを指定します。

適用プロセスによって適用された変更によって、宛先データベースのREDOログに、値が00(ゼロが2つ)のタグが生成されます。

適用プロセスの作成時に、適用プロセスによって適用された変更に対するタグ値を指定します。タグのデフォルト値は、00(ゼロが2つ)です。

関連項目:

- 適用プロセスを作成する方法の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- Oracle Streamsタグの詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

適用プロセスおよび依存性

次の各項では、適用プロセスで依存性が処理される仕組みについて説明します。

- 依存トランザクションが適用される仕組み

- 適用時の行LCRの順序付け

- 依存性および制約

- 依存性検出、ルールベースの変換および適用ハンドラ

- 仮想依存性定義

- バリア・トランザクション

依存トランザクションが適用される仕組み

parallelism適用プロセス・パラメータでは、適用プロセスの並列性を制御します。適用プロセスの並列性が1に設定されている場合、単一の適用サーバーによってトランザクションがソース・データベースでのコミット順に適用されます。この場合、依存性は問題になりません。たとえば、ソース・データベースでトランザクションAがトランザクションBより前にコミットされた場合、宛先データベースでは、トランザクションA内のすべてのLCRがトランザクションB内のどのLCRよりも前に適用されます。

ただし、適用プロセスの並列性の値が2以上に設定されている場合、複数の適用サーバーによってトランザクションが同時に適用されます。適用プロセスによってトランザクションがパラレルで適用される場合、これらのトランザクション内の行LCRが適用された後で、別のトランザクション内の行LCRに依存する行LCRが検出されます。依存する行LCRが検出されると、コミット・システム変更番号(CSCN)が小さいトランザクション内のLCRの適用が終了し、このトランザクションがコミットされてから、CSCNが大きいトランザクション内の残りの行LCRの適用が終了します。

たとえば、トランザクションAとトランザクションBの2つのトランザクションを考えます。これらのトランザクションは依存トランザクションであり、各トランザクションにはそれぞれ100個の行LCRが含まれています。ソース・データベースでは、トランザクションAがトランザクションBより前にコミットされました。したがって、2つのトランザクションのうちCSCNが小さいのはトランザクションAです。適用プロセスでは、これらのトランザクションを次のようにパラレルで適用できます。

1. 適用プロセスは、両方のトランザクション内の行LCRをパラレルで適用し始めます。

2. 適用プロセスは、宛先データベースのデータ・ディクショナリの制約または宛先データベースの仮想依存性定義に基づいて、トランザクションA内の行LCRとトランザクションB内の行LCRの依存性を検出します。

3. 2つのトランザクションのうちCSCNが大きいのはトランザクションBであるため、適用プロセスはトランザクションBの適用を遅らせ、トランザクションB内の依存する行LCRについては適用しません。トランザクションB内の依存する行LCRより前の行LCRは適用されます。たとえば、トランザクションB内の依存する行LCRが81番目の行LCRである場合、適用プロセスはトランザクションB内の100個の行LCRのうち80個を適用することになります。

4. 2つのトランザクションのうちCSCNが小さいのはトランザクションAであるため、適用プロセスはトランザクションA内のすべての行LCRを適用してコミットします。

5. 適用プロセスは、トランザクションB内の依存する行LCRを適用し、さらに残りの行LCRを適用します。トランザクションB内のすべての行LCRが適用されたら、適用プロセスはトランザクションBをコミットします。

注意:
parallelism適用プロセス・パラメータは、DBMS_APPLY_ADMパッケージのSET_PARAMETERプロシージャを使用して設定できます。

適用時の行LCRの順序付け

適用プロセスでは、次のように行LCRを順序付けして適用します。

- 単一のトランザクション内の行LCRは、常にソース・データベースでの対応する変更と同じ順序で適用されます。

- 異なるトランザクション内の相互に依存する行LCRは、常にソース・データベースでの対応する変更と同じ順序で適用されます。適用プロセスの並列性が2以上であり、適用プロセスで異なるトランザクション内の行LCR間の依存性が検出された場合、常にCSCNが小さいトランザクションが実行されてから、依存する行LCRが実行されます。この動作の詳細は、「依存トランザクションが適用される仕組み」を参照してください。

- commit_serialization適用プロセス・パラメータがFULLに設定されている場合、依存する行LCRの有無に関係なく、すべてのトランザクションがソース・データベースの対応するトランザクションと同じ順序でコミットされます。

- commit_serialization適用プロセス・パラメータがDEPENDENT_TRANSACTIONSに設定されている場合、相互に依存しないトランザクションは、ソース・データベースの対応するトランザクションのコミット順とは異なる順序で適用されることがあります。

注意:
commit_serialization適用プロセス・パラメータは、DBMS_APPLY_ADMパッケージのSET_PARAMETERプロシージャを使用して設定できます。

依存性および制約

ソース・データベースと宛先データベースで共有データベース・オブジェクトの名前が同じ場合、かつこれらのデータベースでオブジェクトが同じスキーマ内に含まれている場合、適用プロセスでは、宛先データベースのデータベース・オブジェクトに対して制約が定義されていると仮定して、行LCR間の依存性が自動的に検出されます。これらの制約に関する情報は、宛先データベースのデータ・ディクショナリに格納されています。

適用プロセスでは、commit_serializationパラメータおよび適用プロセスの並列性の設定に関係なく、データベース制約によって強制されるトランザクション間の依存性が常に重視されます。適用対象のトランザクション内の行LCRが別のトランザクション内の行LCRに依存している場合、適用プロセスでは、依存性を維持するために、行LCRが確実に正しい順序で適用され、トランザクションが確実に正しい順序でコミットされます。適用プロセスでは、取得行LCRと永続行LCRの依存性が検出されます。

ただし、環境によっては、データベース制約によって強制されない依存性が存在することもあります。たとえば、アプリケーションを使用して依存性を強制する環境などです。共有データベース・オブジェクトの依存性がデータベース制約によって強制されない環境を使用している場合は、これらのデータベース・オブジェクトに変更を適用する適用プロセスに対してcommit_serializationパラメータをFULLに設定します。

依存性検出、ルールベースの変換および適用ハンドラ

適用プロセスで使用されるルールに対してルールベースの変換が指定されていて、その適用プロセスに適用ハンドラが構成されている場合、LCRは次の順序で処理されます。

1. 適用プロセスは、そのキューからLCRをデキューします。

2. 適用プロセスは、LCRに対してルールベースの変換を実行します(適切な場合)。

3. 適用プロセスは、LCR間の依存性を検出します。

4. 適用プロセスは、LCRを適用ハンドラに渡します(適切な場合)。

関連項目:
「適用プロセスのサブコンポーネント」

仮想依存性定義

適用プロセスでは、パラレルで適用される行LCR間の依存性を検出するために、追加の情報が必要になる場合があります。次に、依存性を検出するために適用プロセスで追加の情報が必要になる場合の例を示します。

- 宛先データベースのデータ・ディクショナリに必要な情報が含まれていない場合。たとえば、次のような場合が該当します。

- 適用プロセスで、宛先データベースのデータ・ディクショナリでデータベース・オブジェクトに関する情報を検出できない場合。このような状況は、ソース・データベースと宛先データベースの間で共有データベース・オブジェクトのデータ・ディクショナリが異なる場合に発生します。たとえば、ソース・データベースと宛先データベースで共有データベース・オブジェクトの名前が異なっていたり、共有データベース・オブジェクトが異なるスキーマに含まれている場合があります。

- 2つ以上の表が関係していて、その関係が宛先データベースのデータ・ディクショナリに記録されていない場合。このような状況は、パフォーマンスを向上させるためのデータベース制約が定義されていない場合や、データベースの操作中にデータベース制約のかわりにアプリケーションによって依存性が強制される場合に発生します。

- 依存性の計算後に適用ハンドラによってデータが非正規化される場合。たとえば、単一の行LCR内の情報を使用して、複数の表に適用される複数の行LCRを作成できます。

適用プロセスで依存性を適切に判別できない場合、適用エラーが発生したり、不適切な処理が行われることがあります。前述のような一部の状況においては、ルールベースの変換を使用して、適用の問題を回避できます。たとえば、ソース・データベースと宛先データベースで共有データベース・オブジェクトが異なるスキーマに含まれている場合、ルールベースの変換を使用して、該当するLCRのスキーマを変更できます。ただし、ルールベースの変換はパラレルで実行できないというデメリットがあります。

仮想依存性定義とは、宛先データベースでトランザクション間の依存性を検出するために、適用プロセスで使用される依存性の記述です。仮想依存性定義は、宛先データベースのデータ・ディクショナリの制約としては記述されません。かわりに、DBMS_APPLY_ADMパッケージのプロシージャを使用して指定されます。仮想依存性定義を使用すると、適用プロセスで、データ・ディクショナリの制約情報のみを使用した場合には検出できない依存性を検出できるようになります。依存性が検出されると、適用プロセスは、LCRおよびトランザクションを正しい順序で適用するようにスケジュールします。

仮想依存性定義は、適用プロセスがLCRを直接適用したり、LCRを適用ハンドラに渡す前に、その依存性を正しく検出できるようにするために必要な情報を提供します。仮想依存性定義を使用すると、適用ハンドラでこれらのLCRを正しく処理できるようになります。また、適用ハンドラでLCRをパラレルで処理してパフォーマンスを向上させることができます。

仮想依存性定義では、次の依存性タイプのいずれかを定義できます。

- 値の依存性

- オブジェクトの依存性

注意:
仮想依存性定義を指定するには、宛先データベースでOracle Database 10g リリース2以上が実行されている必要があります。

関連項目:

- 「仮想依存性定義の使用」

- 「仮想依存性定義の監視」

値の依存性

値の依存性では、一意キーなどの表制約、または2つ以上の表の列間の関係を定義します。値の依存性は1つ以上の列に対して設定され、適用プロセスでは値の依存性を使用して、これらの列の値を含む行LCR間の依存性を検出します。値の依存性では、表間の仮想外部キー関係を定義できますが、外部キー関係とは異なり、3つ以上の表を対象とすることができます。

値の依存性は、表の列間の関係が宛先データベースのデータ・ディクショナリの制約で記述されていない場合に役立ちます。値の依存性ではこれらの関係が記述され、適用プロセスではこれらの値の依存性を使用して、異なるトランザクション内の2つ以上の行LCRが宛先データベースの表の同じ行に関連していることが判別されます。パラレルで適用されるトランザクションでは、2つ以上の行LCRが同じ行に関連している場合、これらの行LCRを含むトランザクションは依存トランザクションになります。

宛先データベースで値の依存性を定義または削除するには、DBMS_APPLY_ADMパッケージのSET_VALUE_DEPENDENCYプロシージャを使用します。このプロシージャでは、表の列を属性として指定します。

値の依存性には、次の制限事項が適用されます。

- 値の依存性に指定されたデータベース・オブジェクトに関連する行LCRは、1つのソース・データベースから生成する必要があります。

- それぞれの値の依存性には、特定のデータベース・オブジェクトに対する1つの属性セットのみを含める必要があります。

また、宛先データベースの値の依存性に指定されたすべての列に対して、ソース・データベースでサプリメンタル・ロギングを実行する必要があります。これらの列は、無条件でログに記録する必要があります。

関連項目:
「Oracle Streams環境内のサプリメンタル・ロギング」

オブジェクトの依存性

オブジェクトの依存性では、宛先データベースの2つのオブジェクト間の親子関係を定義します。適用プロセスでは、コミット・システム変更番号(CSCN)の値が小さく、親オブジェクトを含むすべてのトランザクションのコミット後に、子オブジェクトを含むトランザクションが実行されるようにスケジュールします。適用プロセスでは、各行LCR内のオブジェクト識別子を使用して依存性を検出します。適用プロセスでは、オブジェクトの依存性を検出するために、行LCR内の列の値を使用しません。

オブジェクトの依存性は、表間の関係が宛先データベースのデータ・ディクショナリの制約で記述されていない場合に役立ちます。オブジェクトの依存性ではこれらの関係が記述され、適用プロセスではこれらのオブジェクトの依存性を使用して、異なるトランザクション内の2つ以上の行LCRがこれらの表に関連していることが判別されます。パラレルで適用されるトランザクションでは、あるトランザクション内の行LCRが子の表に関連し、別のトランザクション内の行LCRが親の表に関連している場合、これらの行LCRを含むトランザクションは依存トランザクションになります。

宛先データベースでオブジェクトの依存性を作成するには、CREATE_OBJECT_DEPENDENCYプロシージャを使用します。宛先データベースでオブジェクトの依存性を削除するには、DROP_OBJECT_DEPENDENCYプロシージャを使用します。これらのプロシージャは、いずれもDBMS_APPLY_ADMパッケージに含まれています。

注意:
適用プロセスの並列性が2以上のときに表の循環依存が存在する場合、適用プロセスのデッドロックが発生する可能性があります。循環依存の例には、表Aが表Bに対する外部キー制約を持ち、表Bが表Aに対する外部キー制約を持つ場合があります。循環依存関係にある表を含む2つ以上のトランザクションが同じSCNでコミットされると、適用プロセスのデッドロックが発生する可能性があります。

バリア・トランザクション

適用プロセスで宛先データベースのデータ・ディクショナリおよび仮想依存性定義を使用して、行LCRに指定された表の行またはデータベース・オブジェクトを識別できない場合、その行LCRを含むトランザクションは、CSCN値が小さい他のすべてのトランザクションが適用された後で適用されます。このようなトランザクションはバリア・トランザクションと呼ばれます。バリア・トランザクションよりCSCN値が大きいトランザクションは、バリア・トランザクションがコミットされるまで適用されません。また、DDLトランザクションはいずれもバリア・トランザクションです。

表へのDML変更の適用に関する考慮事項

次の各項では、表へのDML変更の適用に関する考慮事項について説明します。

- 制約と表に対するDML変更の適用

- 代替キー列

- 列の不一致に対する適用プロセスの動作

- 競合解決と適用プロセス

- ハンドラと行LCRの処理

制約と表に対するDML変更の適用

宛先データベースの主キー列が、更新のたびにソース・データベースのREDOログに確実に記録されるようにする必要があります。ソース・データベースの複数列のデータが含まれる宛先データベースの一意キー制約または外部キー制約には、ソース・データベースでの追加ロギングが必要です。

列をソース・データベースのログに確実に記録させるには、様々な方法があります。たとえば、列の値が更新されるたびに、その列がログに記録されます。また、Oracleには、指定した列のロギングを自動化するサプリメンタル・ロギングと呼ばれる機能があります。

ソース・データベースの単一列のデータのみが含まれる宛先データベースの一意キー制約と外部キー制約については、サプリメンタル・ロギングは不要です。ただし、ソース・データベースの複数列のデータが含まれる制約については、宛先データベースの制約で使用されるソース・データベースのすべての列が含まれる条件付きのサプリメンタル・ログ・グループを作成する必要があります。

通常、一意キー制約と外部キー制約には、ソース・データベースおよび宛先データベースで同じ列が含まれます。ただし、適用ハンドラまたはカスタム・ルールベースの変換により、ソース・データベースの複数列制約が宛先データベースの単一キー列に結合される場合があります。また、適用ハンドラまたはカスタム・ルールベースの変換により、ソース・データベースの単一キー列が宛先データベースの複数列制約に分割される場合があります。このような場合は、ソース・データベースの制約内の列数により、条件付きのサプリメンタル・ログ・グループが必要かどうかが決定されます。ソース・データベースの制約に複数の列が存在する場合、ソース・データベースに、すべての制約列が含まれる条件付きのサプリメンタル・ログ・グループが必要です。ソース・データベースの制約に1列のみが存在する場合、キー列にサプリメンタル・ロギングは不要です。

関連項目:
サプリメンタル・ロギングの詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

代替キー列

可能な場合は、適用プロセスによって変更が適用される各表に主キーを用意する必要があります。主キーを使用できない場合は、各表に各行の一意識別子として使用できる列セットを含めることをお薦めします。Oracle Streams環境で使用する予定の表に主キーまたは一意列セットがない場合は、これらの表を適宜変更することを検討してください。

Oracleは、競合を検出してエラーを正確に処理するために、異なるデータベースで対応する行を一意に識別して一致させることができる必要があります。デフォルトでは、Oracle Streamsは、表の主キーを使用して表の各行を識別します。主キーが存在しない場合は、少なくとも1つのNOT NULL列を持つ最小の一意キーを使用して、表内の行を識別します。宛先データベースの表に主キーまたは少なくとも1つのNOT NULL列を持つ一意キーがない場合や、主キーまたは一意キー以外の列をキーとして使用する必要がある場合は、宛先データベースで代替キーを指定できます。代替キーとは、Oracleが適用中に表の各行を識別するために使用できる列または列セットです。

表の代替主キーを指定するには、DBMS_APPLY_ADMパッケージのSET_KEY_COLUMNSプロシージャを使用します。主キーとは異なり、代替キー列にはNULLを指定できます。また、代替キー列は、宛先データベースのすべての適用プロセスについて、指定された表の既存の主キーまたは一意キーよりも優先されます。

宛先データベースで表の代替キーを指定する場合に、これらの列がソース・データベースの同じ表の主キーでなければ、ソース・データベースで代替キー列を含む無条件のサプリメンタル・ログ・グループを作成する必要があります。

代替キー列、主キー制約および一意キー制約がない場合、適用プロセスでは、LOB、LONG、LONG RAW、ユーザー定義型(オブジェクト型、REF、VARRAY、ネストした表など)、およびOracle提供の型(Any型、XML型、空間型、メディア型など)の各データ型の列を除く、表内のすべての列がキー列として使用されます。この場合、ソース・データベースでこれらの列を含む無条件のサプリメンタル・ログ・グループを作成する必要があります。行LCRでは必要な列が少ないため、表の主キー制約がない場合は代替キー列を使用することをお薦めします。

注意:

- 代替キー列として指定する各列はNOT NULL列にすることをお薦めします。また、代替キーにすべての列を含む1つの索引を作成する必要があります。これらのガイドラインに従うと、データベースでは関連する行を効率的に検索できるため、変更のパフォーマンスが向上します。

- LOB、LONG、LONG RAW、ユーザー定義型およびOracle提供の型の列は、代替キー列として指定できません。

関連項目:

- 『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のDBMS_APPLY_ADM.SET_KEY_COLUMNSプロシージャ

- サプリメンタル・ロギングの詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- データ型の詳細は、『Oracle Database SQL言語リファレンス』を参照

- 「表の代替キー列の管理」

列の不一致に対する適用プロセスの動作

列の不一致とは、ソース・データベースの表の列と宛先データベースの同じ表の列が一致しないことです。Oracle Streams環境に列の不一致がある場合は、ルールベースの変換、文DMLハンドラまたはプロシージャDMLハンドラを使用して、適用プロセスで適用される行LCRの列を宛先データベースにある関連表の列と一致させます。

次の各項では、一般的な列の不一致に対する適用プロセスの動作について説明します。

- 宛先データベースの列の欠落

- 宛先データベースの余分な列

- 列のデータ型の不一致

関連項目:

- 「DMLハンドラ」

- 第6章「ルールベースの変換」

- LCRの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

宛先データベースの列の欠落

ソース・データベースの表にある1つ以上の列が宛先データベースの表から欠落していると、適用プロセスにエラーが発生し、エラーの原因となったトランザクションがエラー・キューに移動します。この種のエラーは、適用前に欠落している列をLCRから削除するルールベースの変換またはプロシージャDMLハンドラを作成することで回避できます。具体的には、変換またはハンドラでは、行LCRに対してDELETE_COLUMNメンバー・プロシージャを使用して、余分な列を削除できます。また、欠落している列を除外するSQL文を使用する文DMLハンドラを作成することもできます。

宛先データベースの余分な列

宛先データベースの表の列数がソース・データベースの表よりも多い場合、適用プロセスの動作は余分な列が依存性の計算に必要かどうかに応じて異なります。余分な列が依存性の計算に使用されない場合、適用プロセスでは変更が宛先の表に適用されます。この場合、宛先データベースに余分な列に関する列のデフォルトが存在すると、すべての挿入でこれらの列にはデフォルトが使用されます。それ以外の場合、挿入されるこれらの列はNULLになります。

ただし、余分な列が依存性の計算に使用される場合、適用プロセスではこれらの変更を含むトランザクションがエラー・キューに置かれます。依存性の計算には、次のタイプの列が必要です。

- どのような変更の場合も、すべてのキー列

- INSERTおよびDELETE文の場合は、制約に関係するすべての列

- UPDATE文の場合は、一意キー制約列や外部キー制約列などの制約列に変更があれば、その制約に関係するすべての列

余分な列が依存性の計算に使用される場合、適用エラーを回避する方法の1つは、文DMLハンドラを使用して余分な列を追加することです。

関連項目:
「文DMLハンドラ」

列のデータ型の不一致

宛先データベースにある表の列のデータ型が、ソース・データベースにある同じ列のデータ型と一致しない場合は、列のデータ型の不一致が発生します。列のデータ型の不一致が発生すると、適用プロセスでは特定のデータ型を自動的に変換できます。適用プロセスでデータ型を自動的に変換できない場合、不一致の列に対する変更を含むトランザクションがエラー・キューに格納されます。この種のエラーを回避するために、データ型を変換するカスタム・ルールベースの変換またはDMLハンドラを作成できます。

関連項目:
「適用時の自動データ型変換」

競合解決と適用プロセス

複数のデータベース間でデータが共有されるOracle Streams構成では、競合が発生する可能性があります。競合とは、LCR内の古い値と表内の予期されるデータの不一致です。変更の取得対象となる表とこれらの変更が適用される表について、DML変更が許可されている場合は、競合が発生する可能性があります。

たとえば、ソース・データベースのトランザクションによって行が更新されるのとほぼ同時に、それと同じ行が宛先データベースの異なるトランザクションによって更新されることがあります。この場合、2つのデータベース間でデータの整合性が重要であれば、変更が宛先データベースに伝播されるときに、適用プロセスに対して、宛先データベースで変更を保持するか、ソース・データベースからの変更で置換するように指示する必要があります。データの競合が発生した場合は、競合をビジネス・ルールに従って確実に解決するメカニズムが必要です。

Oracle Streamsでは、競合を自動的に検出し、更新の競合の場合は、更新の競合ハンドラが構成されていれば、それを使用して解決しようとします。Oracle Streamsには様々なビルトイン・ハンドラが用意されており、ビジネス・ルールに従って競合を解決する競合解決システムをデータベースに対して定義できます。ビルトイン競合解決ハンドラで解決できない固有の状況がある場合は、独自のカスタム競合解決ハンドラを作成してエラー・ハンドラまたはプロシージャDMLハンドラ内で使用できます。競合検出は非キー列では無効な場合があります。

関連項目:
『Oracle Streamsレプリケーション管理者ガイド』

ハンドラと行LCRの処理

次のどのハンドラでも、行LCRを処理できます。

- DMLハンドラ(文DMLハンドラまたはプロシージャDMLハンドラのいずれか)

- エラー・ハンドラ

- 更新の競合ハンドラ

次の各項では、これらのハンドラに関係する使用例について説明します。

- 関連ハンドラがない場合

- 関連する更新の競合ハンドラがある場合

- DMLハンドラはあるが関連する更新の競合ハンドラがない場合

- DMLハンドラおよび関連する更新の競合ハンドラがある場合

- 文DMLハンドラおよびプロシージャDMLハンドラがある場合

- エラー・ハンドラはあるが関連する更新の競合ハンドラがない場合

- エラー・ハンドラおよび関連する更新の競合ハンドラがある場合

- 文DMLハンドラおよび関連するエラー・ハンドラがある場合

- 文DMLハンドラ、エラー・ハンドラおよび関連する更新の競合ハンドラがある場合

関連項目:

- 行LCRのEXECUTEメンバー・プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

- 「DMLハンドラ」

- 第5章「Oracle Streamsでのルールの使用方法」

- 『Oracle Streamsレプリケーション管理者ガイド』

関連ハンドラがない場合

行LCRに対する関連ハンドラがない場合、適用プロセスは行LCRで指定された変更を直接適用しようとします。適用プロセスが行LCRを適用できる場合は、表のその行が変更されます。適用中に競合またはエラーが発生すると、その行LCRを含むトランザクションがロールバックされ、適用プロセスのルール・セットに従って適用される必要があるトランザクション内のLCRは、すべてエラー・キューに移動します。

関連する更新の競合ハンドラがある場合

関連する更新の競合ハンドラは構成されているが、他の関連ハンドラが構成されていない場合を考えます。適用プロセスは、行LCRで指定された変更を直接適用しようとします。適用プロセスが行LCRを適用できる場合は、表のその行が変更されます。

適用中に、一意性競合や削除の競合など、更新の競合以外の条件によってエラーが発生すると、その行LCRを含むトランザクションがロールバックされ、適用プロセスのルール・セットに従って適用される必要があるトランザクション内のLCRは、すべてエラー・キューに移動します。

適用中に更新の競合が発生すると、関連する更新の競合ハンドラが起動します。更新の競合ハンドラによって競合が正常に解決されると、適用プロセスは更新の競合の解決方法に応じてLCRを適用または廃棄し、適用プロセスのルール・セットに従って適用される必要があるトランザクション内の他のLCRを引き続き適用します。更新の競合ハンドラが競合を解決できない場合は、その行LCRを含むトランザクションがロールバックされ、適用プロセスのルール・セットに従って適用される必要があるトランザクション内のLCRは、すべてエラー・キューに移動します。

DMLハンドラはあるが関連する更新の競合ハンドラがない場合

適用プロセスが行LCRをDMLハンドラに渡し、関連する更新の競合ハンドラが構成されていない場合を考えます。DMLハンドラは、文DMLハンドラとプロシージャDMLハンドラのどちらでもかまいません。

DMLハンドラによって行LCRが処理されます。DMLハンドラのデザイナがこの処理を全面的に制御します。一部のDMLハンドラは、SQL操作を実行するか、行LCRのEXECUTEメンバー・プロシージャを実行する場合があります。DMLハンドラが行LCRのEXECUTEメンバー・プロシージャを実行すると、適用プロセスは行LCRを適用しようとします。この行LCRは、DMLハンドラによって変更されている可能性があります。

文DMLハンドラの失敗

適用プロセスでは、同じ表に対する同じ操作について、複数の文DMLハンドラを使用できます。これらの文DMLハンドラは任意の順序で実行でき、それぞれの文DMLハンドラは元の行LCRを受け取ります。文DMLハンドラによって実行されるSQL操作が失敗するか、EXECUTEメンバー・プロシージャの実行に失敗した場合、その行LCRを含むトランザクションがロールバックされ、適用プロセスのルール・セットに従って適用される必要があるトランザクション内のLCRは、すべてエラー・キューに移動します。

プロシージャDMLハンドラの失敗

プロシージャDMLハンドラによって実行されるSQL操作が失敗するか、EXECUTEメンバー・プロシージャの実行に失敗した場合、プロシージャDMLハンドラは例外処理を試みることができます。プロシージャDMLハンドラが例外を呼び出さなければ、適用プロセスはプロシージャDMLハンドラが行LCRで適切なアクションを実行したものとみなして、適用プロセスのルール・セットに従って適用される必要があるトランザクション内の他のLCRを引き続き適用します。

プロシージャDMLハンドラは、例外を処理できなければ例外を呼び出します。この場合、その行LCRを含むトランザクションがロールバックされ、適用プロセスのルール・セットに従って適用される必要があるトランザクション内のLCRは、すべてエラー・キューに移動します。

DMLハンドラおよび関連する更新の競合ハンドラがある場合

適用プロセスが行LCRをDMLハンドラに渡し、関連する更新の競合ハンドラが構成されている場合を考えます。DMLハンドラは、文DMLハンドラとプロシージャDMLハンドラのどちらでもかまいません。適用プロセスでは、同じ表に対する同じ操作について、複数の文DMLハンドラを使用できます。これらの文DMLハンドラは任意の順序で実行でき、それぞれの文DMLハンドラは元の行LCRを受け取ります。

DMLハンドラによって行LCRが処理されます。DMLハンドラのデザイナがこの処理を全面的に制御します。一部のDMLハンドラは、SQL操作を実行するか、行LCRのEXECUTEメンバー・プロシージャを実行する場合があります。DMLハンドラが行LCRのEXECUTEメンバー・プロシージャを実行すると、適用プロセスは行LCRを適用しようとします。DMLハンドラがプロシージャDMLハンドラである場合、この行LCRはプロシージャDMLハンドラによって変更されている可能性があります。

DMLハンドラによって実行されるSQL操作が失敗するか、更新の競合以外の理由でEXECUTEメンバー・プロシージャの実行に失敗した場合の動作は、「DMLハンドラはあるが関連する更新の競合ハンドラがない場合」で説明した動作と同じです。一意性競合と削除の競合は、更新の競合ではないことに注意してください。

更新の競合が原因でEXECUTEメンバー・プロシージャの実行に失敗した場合の動作は、EXECUTEメンバー・プロシージャのconflict_resolutionパラメータの設定に応じて次のように異なります。

conflict_resolutionパラメータがTRUEに設定されている場合

conflict_resolutionパラメータがTRUEに設定されている場合は、関連する更新の競合ハンドラが起動します。更新の競合ハンドラによって競合が正常に解決され、DMLハンドラによって実行された他のすべての操作が正常終了すると、DMLハンドラは例外を呼び出さずに終了し、適用プロセスはそのルール・セットに従って適用される必要があるトランザクション内の他のLCRを引き続き適用します。

更新の競合ハンドラが競合を解決できず、DMLハンドラが文DMLハンドラである場合、その行LCRを含むトランザクションがロールバックされ、適用プロセスのルール・セットに従って適用される必要があるトランザクション内のLCRは、すべてエラー・キューに移動します。

更新の競合ハンドラが競合を解決できず、DMLハンドラがプロシージャDMLハンドラである場合、プロシージャDMLハンドラは例外処理を試みることができます。プロシージャDMLハンドラが例外を呼び出さなければ、適用プロセスはプロシージャDMLハンドラが行LCRで適切なアクションを実行したものとみなして、適用プロセスのルール・セットに従って適用される必要があるトランザクション内の他のLCRを引き続き適用します。プロシージャDMLハンドラは、例外を処理できなければ例外を呼び出します。この場合、その行LCRを含むトランザクションがロールバックされ、適用プロセスのルール・セットに従って適用される必要があるトランザクション内のLCRは、すべてエラー・キューに移動します。

conflict_resolutionパラメータがFALSEに設定されている場合

conflict_resolutionパラメータがFALSEに設定されている場合、関連する更新の競合ハンドラは起動しません。この場合の動作は、「DMLハンドラはあるが関連する更新の競合ハンドラがない場合」で説明した動作と同じです。

文DMLハンドラおよびプロシージャDMLハンドラがある場合

適用プロセスが行LCRを文DMLハンドラとプロシージャDMLハンドラの両方に渡し、同じ表に対して同じ操作を実行する場合を考えます。この場合、DMLハンドラは任意の順序で実行でき、それぞれのDMLハンドラは元の各行LCRを受け取ります。また、適用プロセスでは、同じ表に対する同じ操作について、複数の文DMLハンドラを使用できます。これらの文DMLハンドラは任意の順序で実行でき、それぞれの文DMLハンドラは元の行LCRを受け取ります。それぞれのDMLハンドラでは行LCRを個別に処理し、その動作はDMLハンドラが関係する他の使用例と同じです。

文DMLハンドラまたはプロシージャDMLハンドラが失敗した場合、その行LCRを含むトランザクションがロールバックされ、適用プロセスのルール・セットに従って適用される必要があるトランザクション内のLCRは、すべてエラー・キューに移動します。

エラー・ハンドラはあるが関連する更新の競合ハンドラがない場合

適用プロセスが行LCRを適用するときにエラーが発生した場合を考えます。このエラーは、競合または他の条件が原因となっている可能性があります。表操作用のエラー・ハンドラはありますが、関連する更新の競合ハンドラは構成されていません。

行LCRがエラー・ハンドラに渡されます。エラー・ハンドラによって行LCRが処理されます。エラー・ハンドラのデザイナがこの処理を全面的に制御します。一部のエラー・ハンドラは、SQL操作を実行するか、行LCRのEXECUTEメンバー・プロシージャを実行する場合があります。エラー・ハンドラが行LCRのEXECUTEメンバー・プロシージャを実行すると、適用プロセスは行LCRを適用しようとします。この行LCRは、エラー・ハンドラによって変更されている可能性があります。

エラー・ハンドラによって実行されるSQL操作が失敗するか、EXECUTEメンバー・プロシージャの実行に失敗した場合、エラー・ハンドラは例外処理を試みることができます。エラー・ハンドラが例外を呼び出さなければ、適用プロセスはエラー・ハンドラが行LCRで適切なアクションを実行したものとみなして、適用プロセスのルール・セットに従って適用される必要があるトランザクション内の他のLCRを引き続き適用します。

エラー・ハンドラは、例外を処理できなければ例外を呼び出します。この場合、その行LCRを含むトランザクションがロールバックされ、適用プロセスのルール・セットに従って適用される必要があるトランザクション内のLCRは、すべてエラー・キューに移動します。

エラー・ハンドラおよび関連する更新の競合ハンドラがある場合

適用プロセスが行LCRを適用するときにエラーが発生した場合を考えます。表操作用のエラー・ハンドラがあり、関連する更新の競合ハンドラが構成されています。

エラー処理のために起動されるハンドラは、次のようにエラーのタイプに応じて異なります。

- 一意性競合や削除の競合など、更新の競合以外の条件によってエラーが発生すると、エラー・ハンドラが起動します。この場合の動作は、「エラー・ハンドラはあるが関連する更新の競合ハンドラがない場合」で説明した動作と同じです。

- 更新の競合が原因でエラーが発生すると、更新の競合ハンドラが起動します。更新の競合ハンドラによって競合が正常に解決されると、適用プロセスはそのルール・セットに従って適用される必要があるトランザクション内の他のLCRを引き続き適用します。この場合、エラー・ハンドラは起動しません。
更新の競合ハンドラが競合を解決できない場合、エラー・ハンドラが起動します。エラー・ハンドラが例外を呼び出さなければ、適用プロセスはエラー・ハンドラが行LCRで適切なアクションを実行したものとみなして、適用プロセスのルール・セットに従って適用される必要があるトランザクション内の他のLCRを引き続き適用します。エラー・ハンドラは、LCRを処理できなければ例外を呼び出します。この場合、その行LCRを含むトランザクションがロールバックされ、適用プロセスのルール・セットに従って適用される必要があるトランザクション内のLCRは、すべてエラー・キューに移動します。

文DMLハンドラおよび関連するエラー・ハンドラがある場合

適用プロセスが行LCRを文DMLハンドラに渡し、関連するエラー・ハンドラが構成されている場合を考えます。

文DMLハンドラによって行LCRが処理されます。文DMLハンドラのデザイナがこの処理を全面的に制御します。一部の文DMLハンドラは、SQL操作を実行するか、行LCRのEXECUTEメンバー・プロシージャを実行する場合があります。文DMLハンドラが行LCRのEXECUTEメンバー・プロシージャを実行すると、適用プロセスは行LCRを適用しようとします。

また、適用プロセスでは、同じ表に対する同じ操作について、複数の文DMLハンドラを使用できます。これらの文DMLハンドラは任意の順序で実行でき、それぞれの文DMLハンドラは元の行LCRを受け取ります。

文DMLハンドラによって実行されるSQL操作が失敗するか、なんらかの理由でEXECUTEメンバー・プロシージャの実行に失敗した場合の動作は、「エラー・ハンドラはあるが関連する更新の競合ハンドラがない場合」で説明した動作と同じです。エラー・ハンドラは、文DMLハンドラによって処理された行LCRではなく、元の行LCRを取得します。

注意:
プロシージャDMLハンドラとエラー・ハンドラを同時に使用して、同じ表に対して同じ操作を実行することはできません。したがって、両方のハンドラが起動される使用例はありません。

文DMLハンドラ、エラー・ハンドラおよび関連する更新の競合ハンドラがある場合

適用プロセスが行LCRを文DMLハンドラに渡し、関連するエラー・ハンドラと更新の競合ハンドラが構成されている場合を考えます。

文DMLハンドラによって行LCRが処理されます。文DMLハンドラのデザイナがこの処理を全面的に制御します。一部の文DMLハンドラは、SQL操作を実行するか、行LCRのEXECUTEメンバー・プロシージャを実行する場合があります。文DMLハンドラが行LCRのEXECUTEメンバー・プロシージャを実行すると、適用プロセスは行LCRを適用しようとします。

また、適用プロセスでは、同じ表に対する同じ操作について、複数の文DMLハンドラを使用できます。これらの文DMLハンドラは任意の順序で実行でき、それぞれの文DMLハンドラは元の行LCRを受け取ります。

文DMLハンドラによって実行されるSQL操作が失敗するか、なんらかの理由でEXECUTEメンバー・プロシージャの実行に失敗した場合の動作は、「エラー・ハンドラおよび関連する更新の競合ハンドラがある場合」で説明した動作と同じです。

注意:
プロシージャDMLハンドラとエラー・ハンドラを同時に使用して、同じ表に対して同じ操作を実行することはできません。したがって、両方のハンドラが起動される使用例はありません。

DDL変更を適用するときの考慮事項

次の各項では、表にDDL変更を適用するときの考慮事項について説明します。

- システム生成名

- CREATE TABLE AS SELECT文

- DDL文内のDML文

システム生成名

ソース・データベースでDDL変更を取得して、それを宛先データベースで適用する予定の場合は、システム生成名を使用しないでください。DDL文の結果としてオブジェクト名がシステムによって生成される場合、通常、オブジェクト名はソース・データベースとそこからのDDL変更を適用する各宛先データベースで異なるものになります。オブジェクト名が異なると、将来のDDL変更に適用エラーが発生する可能性があります。

たとえば、ソース・データベースで次のDDL文を実行する場合を考えます。

CREATE TABLE sys_gen_name (n1 NUMBER  NOT NULL);

この文の結果、システム生成名を持つNOT NULL制約が作成されます。たとえば、NOT NULL制約の名前がsys_001500であるとします。この変更が宛先データベースで適用されると、この制約のシステム生成名がsys_c1000となる場合があります。

ソース・データベースで次のDDL文を実行する場合を考えます。

ALTER TABLE sys_gen_name DROP CONSTRAINT sys_001500;

このDDL文は、ソース・データベースでは成功しますが、宛先データベースでは失敗し、適用エラーになります。

この種のエラーを回避するには、DDL文によって作成されるすべてのオブジェクトの名前を明示的に指定します。たとえば、NOT NULL制約の名前を明示的に指定するには、次のDDL文を実行します。

CREATE TABLE sys_gen_name (n1 NUMBER CONSTRAINT sys_gen_name_nn NOT NULL);

CREATE TABLE AS SELECT文

CREATE TABLE AS SELECT文から発生した変更を適用する場合、適用プロセスでは次の2つの手順が実行されます。

1. CREATE TABLE AS SELECT文が宛先データベースで実行されますが、表の構造のみが作成されます。表に行は挿入されません。CREATE TABLE AS SELECT文が失敗すると、適用プロセスがエラーになります。それ以外の場合は、文が自動コミットされ、適用プロセスによって手順2が実行されます。

2. 適用プロセスによって、CREATE TABLE AS SELECT文の結果としてソース・データベースで挿入された行が、宛先データベースで対応する表に挿入されます。取得プロセス、伝播または適用プロセスでは、これらの挿入を伴うすべての行LCRが、それぞれのルール・セットに基づいて廃棄される場合があります。この場合、宛先データベースでは表が空のままになります。

関連項目:
第5章「Oracle Streamsでのルールの使用方法」

DDL文内のDML文

適用プロセスによってデータ定義言語(DDL)の変更が適用されるとき、Oracle Streamsでは同じトランザクション内のDDLターゲットに対するデータ操作言語(DML)の変更は宛先データベースに絶対にレプリケートされません。したがって、ソース・データベースと宛先データベースに相違が生じる場合があります。行論理変更レコード(LCR)の古い値が宛先の表の現在の値と一致しないと、相違によって適用プロセス・エラーが発生する可能性があります。

次の場合、ソース・データベースと宛先データベースに相違が生じます。

- DDL文に導出値が含まれている場合

- DDL文によってDMLトリガーが起動される場合

DDL文に導出値が含まれている場合

DDL文に導出される非リテラル値が含まれている場合、導出される値はソース・データベースと宛先データベースで一致しない可能性があります。たとえば、次のDDL文を実行すると、hr.employees表に1列が追加され、ソース・データベースを実行しているコンピュータ・システムから導出される日付値が挿入されます。

ALTER TABLE hr.employees ADD(start_date DATE DEFAULT SYSDATE);

レプリケーション環境においてソース・データベースと宛先データベースの間でhr.employees表に対するDML変更とDDL変更が維持されると想定します。この場合、SYSDATEファンクションはソース・データベースと宛先データベースで個別に実行されます。したがって、ソース・データベースで挿入されるDATE値は、宛先データベースで挿入されるDATE値と一致しません。

DDL文によってDMLトリガーが起動される場合

DDL文によって、宛先の表で定義されたDMLトリガーが起動される場合、トリガーによって行われるDML変更は宛先データベースでレプリケートされません。トリガーによるDML変更はDDL文と同じトランザクションで行われ、DDL文のターゲットである表に影響するため、トリガーされるDML変更は宛先データベースでレプリケートされません。

たとえば、次の表を作成するものとします。

CREATE TABLE hr.temp_employees(
emp_id       NUMBER  PRIMARY KEY,
first_name   VARCHAR2(64),
last_name    VARCHAR2(64),
modify_date  TIMESTAMP);

表でトリガーを作成し、表が更新されるたびにmodify_date列を更新して変更時間を反映するようにするとします。

CREATE OR REPLACE TRIGGER hr.trg_mod_dt BEFORE UPDATE ON hr.temp_employees
REFERENCING
NEW AS NEW_ROW FOR EACH ROW
BEGIN
:NEW_ROW.modify_date:= SYSTIMESTAMP;
END;
/

レプリケーション環境においてソース・データベースと宛先データベースの間でhr.temp_employees表に対するDML変更とDDL変更が維持されると想定します。この場合、ソース・データベースでhr.temp_employees表に対して直接行われるDML変更にあわせて、宛先データベースでもこの表は正しく維持されます。ただし、ソース・データベースのADD COLUMN文によってこの表に列が追加される場合、hr.trg_mod_dt更新トリガーによって表のすべての行のmodify_date列が新しいタイムスタンプに変更されます。modify_date列に対するこれらの変更は宛先データベースでレプリケートされません。

適用プロセスのインスタンス化SCNと非処理SCN

1つのデータベース内または複数のデータベース間で情報を共有するOracle Streams環境の場合、ソース・データベースとはREDOログ内で変更が生成されるデータベースです。次の特性を持つ環境を考えます。

- 取得プロセスまたは同期取得は、ソース・データベースの表に対する変更を取得し、変更をLCRとしてキューにステージングします。

- 適用プロセスは、同じデータベースまたはLCRが伝播された宛先データベースのどちらかで、これらのLCRを適用します。

このような環境では、表ごとに、ソース・データベースで特定のシステム変更番号(SCN)の後にコミットされた変更のみが適用されます。インスタンス化SCNは、各表でこの値を指定します。

インスタンス化SCNは、インスタンス化時に設定するか、またはDBMS_APPLY_ADMパッケージのプロシージャを使用して設定できます。Oracle Streamsレプリケーション環境が構成される前に表が宛先データベースに存在しない場合、ソース・データベースからのコピーを使用して、表が物理的に作成(インスタンス化)され、インスタンス化SCNがインスタンス化時に各表に設定されます。Oracle Streamsレプリケーション環境が構成される前に表が宛先データベースにすでに存在する場合、ソース・データベースからのコピーを使用した表のインスタンス化は行われません。かわりに、DBMS_APPLY_ADMパッケージに含まれるSET_TABLE_INSTANTIATION_SCN、SET_SCHEMA_INSTANATIATION_SCNまたはSET_GLOBAL_INSTANTIATION_SCNプロシージャのいずれかを使用して、表ごとに手動でインスタンス化SCNを設定する必要があります。

データベース・オブジェクトのインスタンス化SCNによって、データベース・オブジェクトに対する変更を含むLCRのうち、適用プロセスで無視されるLCRと適用されるLCRが制御されます。ソース・データベースからのデータベース・オブジェクトに関するLCRのコミットSCNが、宛先データベースでそのデータベース・オブジェクトのインスタンス化SCN以下であれば、宛先データベースの適用プロセスではLCRが廃棄されます。それ以外の場合は、適用プロセスによってLCRが適用されます。

また、宛先データベースの共有データベース・オブジェクトに対して複数のソース・データベースがある場合は、ソース・データベースごとにインスタンス化SCNを設定する必要があります。このインスタンス化SCNは、ソース・データベースごとに異なっていてもかまいません。エクスポート/インポートまたはトランスポータブル表領域を使用して、インスタンス化SCNを設定できます。また、DBMS_APPLY_ADMパッケージのプロシージャを使用して、インスタンス化SCNを設定することもできます。

また、Oracle Streamsでは各データベース・オブジェクトについて非処理SCNが記録されます。非処理SCNは、その下にデータベース・オブジェクトに対する変更を適用できないSCNです。オブジェクトのインスタンス化SCNは、オブジェクトの非処理SCNの下には設定できません。この値は、オブジェクトがインスタンス化のために準備された時点でのソース・データベースのSCN値に相当します。非処理SCNは、Oracle Data Pumpを使用してデータベース・オブジェクトがインスタンス化された場合にのみ、データベース・オブジェクトに設定されます。

データベース・オブジェクトのインスタンス化SCNおよび非処理SCNを表示するには、DBA_APPLY_INSTANTIATED_OBJECTSデータ・ディクショナリ・ビューを問い合せます。

関連項目:
『Oracle Streamsレプリケーション管理者ガイド』

適用プロセスの最も古いSCN

適用プロセスが実行されている場合、最も古いSCNは、現在デキューおよび適用されているトランザクションの最も若いSCNです。停止した適用プロセスの場合、最も古いSCNは、適用プロセスが停止した際に適用されていたトランザクションの最も若いSCNです。

最も古いSCNが重要になるのは、次の2つの一般的な使用例の場合です。

- 適用プロセスを実行中のデータベースを特定の時点までリカバリする必要がある場合。

- 適用プロセス用の変更を取得するために、既存の取得プロセスの使用を停止し、別の取得プロセスを使用する場合。

どちらの場合も、DBA_APPLY_PROGRESSデータ・ディクショナリ・ビューを問い合せて、適用プロセス用の最も古いSCNを判別する必要があります。このビューのOLDEST_MESSAGE_NUMBER列に、最も古いSCNが含まれています。次に、適用プロセス用の変更を取得する取得プロセスの開始SCNを、最も古いSCNと同じ値に設定します。取得プロセスが他の適用プロセス用の変更を取得している場合は、取得プロセスの開始SCNをリセットすると、これらの他の適用プロセスは重複するLCRを受け取ることがあります。この場合、これらの適用プロセスでは重複するLCRが自動的に廃棄されます。

注意:
最も古いSCNは、取得プロセスで取得されたLCRを適用する適用プロセスに対してのみ有効です。同期取得で取得されたLCRまたは明示的にエンキューされたLCRを適用する適用プロセスには関連していません。

関連項目:

- 「取得プロセスに関連するSCN値」

- 『Oracle Streamsレプリケーション管理者ガイド』

適用プロセスの最低水位標と最高水位標

適用プロセスの最低水位標は、すべてのLCRが適用済となっている最大のシステム変更番号(SCN)です。つまり、最低水位標番号以下のSCNでコミットされたLCRは確実に適用されていますが、それを超えるSCNでコミットされた一部のLCRも適用されている可能性があります。適用プロセスの最低水位標SCNは、取得プロセスの適用済SCNと等価です。

適用プロセスの最高水位標は、その番号を超えて適用されたLCRのないSCNです。つまり、最高水位標を超えるSCNでコミットされたLCRは適用されていません。

1つ以上の適用プロセスについて最低水位標と最高水位標を表示するには、V$STREAMS_APPLY_COORDINATORおよびALL_APPLY_PROGRESSデータ・ディクショナリ・ビューを問い合せます。

適用プロセスおよびトリガー

この項では、Oracle Streamsの適用プロセスとトリガーの対話の仕組みについて説明します。

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

- トリガー起動プロパティ

- 適用プロセスとON SCHEMA句で作成したトリガー

関連項目:

- 「DDL文によってDMLトリガーが起動される場合」

- 『Oracle Database概要』

トリガー起動プロパティ

DBMS_DDLパッケージのSET_TRIGGER_FIRING_PROPERTYプロシージャを使用すると、DMLまたはDDLトリガーの起動プロパティを制御できます。このプロシージャでは、トリガーを常に起動するか、1回起動するか、または適用プロセスによって変更が行われる場合にのみ起動するかを指定できます。

SET_TRIGGER_FIRING_PROPERTYプロシージャはオーバーロードされます。トリガーの起動プロパティは、次のいずれかの方法で設定します。

- トリガーを常に起動するように指定するには、fire_onceプロシージャ・パラメータをFALSEに設定します。

- トリガーを1回起動するように指定するには、fire_onceプロシージャ・パラメータをTRUEに設定します。

- 適用プロセスによって変更が行われる場合にのみトリガーを起動するように指定するには、propertyパラメータをDBMS_DDL.APPLY_SERVER_ONLYに設定します。

トリガーに対してDBMS_DDL.APPLY_SERVER_ONLYプロパティを設定すると、fire_onceパラメータの設定に関係なく、適用プロセスによって変更が行われる場合にのみトリガーが起動します。つまり、propertyパラメータに対してDBMS_DDL.APPLY_SERVER_ONLYを設定した場合、fire_onceパラメータの設定よりも優先されます。

トリガーの起動プロパティによって、次のそれぞれの状況でトリガーが起動するかどうかが決まります。

- ユーザー・プロセスによってトリガー・イベントが実行された場合

- 適用プロセスによってトリガー・イベントが実行された場合

- DBMS_APPLY_ADMパッケージのEXECUTE_ERRORまたはEXECUTE_ALL_ERRORSプロシージャを使用して1つ以上の適用エラーを実行した結果としてトリガー・イベントが発生した場合

表10-2に、トリガー起動プロパティに基づくトリガーの起動有無を示します。

表10-2 トリガー起動プロパティ

トリガー起動プロパティ

ユーザー・プロセスによってトリガー・イベントが発生した場合

適用プロセスによってトリガー・イベントが発生した場合

適用エラーの実行によってトリガー・イベントが発生した場合

常に起動

トリガーは起動する

トリガーは起動する

トリガーは起動する

1回起動

トリガーは起動する

トリガーは起動しない

トリガーは起動しない

適用プロセスによって変更が行われる場合のみ

トリガーは起動しない

トリガーは起動する

トリガーは起動する

たとえば、hrスキーマ内で、employees表のjob_id列またはdepartment_id列のデータが更新されると、update_job_historyトリガーによってjob_history表に1行が追加されます。この場合、Oracle Streams環境に次の構成が存在すると考えます。

- 取得プロセスまたは同期取得は、dbs1.example.comデータベースでこの2つの表に対する変更を取得します。

- 伝播は、これらの変更をdbs2.example.comデータベースに伝播させます。

- 適用プロセスは、これらの変更をdbs2.example.comデータベースで適用します。

- どちらのデータベースでも、hrスキーマにupdate_job_historyトリガーが存在します。

この使用例で、update_job_historyトリガーがdbs2.example.comで常に起動するように設定されていれば、これらのアクションの結果は次のようになります。

1. dbs1.example.comで、employees表の従業員に関するjob_id列が更新されます。

2. dbs1.example.comでupdate_job_historyトリガーが起動し、変更を記録するjob_history表に1行が追加されます。

3. dbs1.example.comの取得プロセスまたは同期取得は、employees表とjob_history表の両方に対する変更を取得します。

4. 伝播は、これらの変更をdbs2.example.comデータベースに伝播させます。

5. dbs2.example.comデータベースの適用プロセスは、両方の変更を適用します。

6. 適用プロセスによってemployees表が更新されると、dbs2.example.comでupdate_job_historyトリガーが起動します。

この場合、employees表に対する変更は、dbs2.example.comデータベースで2回記録されます。1回は適用プロセスが変更をjob_history表に適用する時点で、もう1回はupdate_job_historyトリガーが起動して、適用プロセスによってemployees表に対して行われた変更を記録する時点です。

データベース管理者は、適用プロセスによって変更が行われるときに、dbs2.example.comデータベースでupdate_job_historyトリガーが起動しないようにする必要がある場合があります。同様に、データベース管理者は、適用エラー・トランザクションの実行が原因でトリガーが起動しないようにする必要がある場合もあります。update_job_historyトリガーの起動プロパティを1回起動するように設定すると、適用プロセスによって変更がemployees表に適用されるときにも、実行されたエラー・トランザクションによってemployees表が更新されるときにも、dbs2.example.comでトリガーは起動しません。

注意:
1回起動するように設定できるのは、DMLトリガーとDDLトリガーのみです。他のタイプのトリガーは、すべて常に起動します。

関連項目:
SET_TRIGGER_FIRING_PROPERTYプロシージャを使用してトリガーの起動プロパティを設定する方法の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

適用プロセスとON SCHEMA句で作成したトリガー

ON SCHEMA句を使用してスキーマ・トリガーを作成した場合、そのスキーマ・トリガーは、スキーマにより関連する変更が実行される場合にのみ起動します。したがって、適用プロセスにより変更が適用されるときには、常に起動するように設定されたスキーマ・トリガーは、適用ユーザーがスキーマ・トリガーで指定されたスキーマと同じ場合にのみ起動します。スキーマ・トリガーが1回起動するように設定されている場合は、適用ユーザーがスキーマ・トリガーで指定されたスキーマと同じかどうかにかかわらず、適用プロセスでの変更適用時にトリガーは起動しません。

たとえば、ソース・データベースおよび宛先データベースのhrスキーマで常に起動するスキーマ・トリガーを指定した場合に、宛先データベースの適用ユーザーがstrmadminであれば、hrユーザーがソース・データベースで関連する変更を実行するときにはトリガーが起動しますが、この変更が宛先データベースで適用されるときにはトリガーは起動しません。ただし、宛先データベースのstrmadminスキーマで常に起動するスキーマ・トリガーを指定した場合は、ソース・データベースのトリガー仕様にかかわらず、適用プロセスにより関連する変更が行われるときに必ずこのトリガーが起動します。

適用プロセス用のOracle Streamsデータ・ディクショナリ

ソース・データベースでデータベース・オブジェクトのインスタンス化が準備されている場合、オブジェクトに対する変更が取得プロセスによって取得されるデータベースで、Oracle Streamsデータ・ディクショナリが自動的に移入されます。Oracle Streamsデータ・ディクショナリは、ソース・データベースのプライマリ・データ・ディクショナリ内の一部の情報のマルチバージョン・コピーです。Oracle Streamsデータ・ディクショナリでは、ソース・データベースのオブジェクト番号、オブジェクト・バージョン情報および内部列番号が表名、列名および列のデータ型にマップされます。取得LCRでは名前ではなく番号を内部的に使用できるため、このマッピングによって、各取得LCRのサイズが最小に保たれます。

取得または伝播時に取得LCRがパラメータとしてカスタム・ルールベースの変換に渡される場合を除き、取得LCRを適用するすべてのデータベースで、LCRの内容の解釈にソース・データベースのOracle Streamsデータ・ディクショナリのマッピング情報が必要となります。適用プロセスでこのマッピング情報を使用できるようにするために、Oracle Streams適用プロセスを持つ各宛先データベースで、マルチバージョンOracle Streamsデータ・ディクショナリが自動的に移入されます。ソース・データベースのOracle Streamsデータ・ディクショナリから、ソース・データベースからの取得LCRを適用するその他すべてのデータベースに、関連情報が自動的に伝播されます。

関連項目:

- 「Oracle Streamsデータ・ディクショナリ」

- 「伝播用のOracle Streamsデータ・ディクショナリ」

単一データベースでの複数の適用プロセス

単一データベースで複数の適用プロセスを実行する場合は、システム・グローバル領域(SGA)のサイズを増やすことを検討してください。SGAサイズを増やすには、SGA_MAX_SIZE初期化パラメータを使用します。また、Oracle Streamsプールのサイズがデータベースで自動管理されていない場合は、適用プロセスの並列性ごとにOracle Streamsプールを 1MB増やす必要があります。たとえば、2つの適用プロセスがデータベースで実行されており、parallelismパラメータが一方の適用プロセスでは4、もう一方の適用プロセスでは1に設定されている場合、Oracle Streamsプールを5MB(並列性は4+1=5)増やします。

注意:
MEMORY_TARGET、MEMORY_MAX_TARGETまたはSGA_TARGET初期化パラメータが0(ゼロ)以外の値に設定されている場合、Oracle Streamsプールのサイズは自動的に管理されます。

関連項目:

- Oracle Streamsプールの詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- STREAMS_POOL_SIZE初期化パラメータの詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

11 ルールの高度な概念

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

- ルールのコンポーネント

- ルール・セットの評価

- ルールに関連するデータベース・オブジェクトと権限

- Oracle Streamsで使用される評価コンテキスト

- Oracle Streamsおよびイベント・コンテキスト

- Oracle Streamsおよびアクション・コンテキスト

- ユーザー作成ルール、ルール・セットおよび評価コンテキスト

関連項目:

- 第5章「Oracle Streamsでのルールの使用方法」

- 第18章「ルールの管理」

- 『Oracle Streams拡張例』

ルールのコンポーネント

ルールとは、イベントの発生時に条件が満たされている場合に、クライアントでアクションを実行できるようにするデータベース・オブジェクトです。ルールのコンポーネントは、次のとおりです。

- ルール条件

- ルール評価コンテキスト(オプション)

- ルール・アクション・コンテキスト(オプション)

各ルールは、SQL問合せのWHERE句の条件と同様の条件として指定します。関連するルールをグループ化してルール・セットを作成できます。1つのルールを1つ以上のルール・セットに含めることができます。また、どのルール・セットにも含めなくてもかまいません。

ルール・セットは、Oracleの組込み部分であるルール・エンジンによって評価されます。ユーザー作成アプリケーションとOracle StreamsなどのOracleの機能の両方が、ルール・エンジンのクライアントとなることができます。

注意:
ルールを評価するには、ルール・セットに含める必要があります。

ルール条件

ルール条件は、1つ以上の式と条件を組み合せてブール値を戻します。ブール値は、TRUE、FALSEまたはNULL(不明)のいずれかです。式は、1つ以上の値と、評価結果が値になる演算子の組合せです。値には、表のデータ、変数のデータ、またはSQLファンクションやPL/SQLファンクションから戻されるデータを使用できます。たとえば、次の式には1つの値のみが含まれます。

salary

次の式には2つの値(salaryおよび.1)と1つの演算子(*)が含まれます。

salary * .1

次の条件は2つの式(salaryおよび3800)と1つの条件(=)で構成されています。

salary = 3800

この論理条件は、salary列が3800の場合は、特定の行についてTRUEと評価されます。この場合、値は表のsalary列のデータです。

複数の条件をAND、ORおよびNOT論理条件で結合して複合条件を形成し、1つのルール条件に含めることができます。論理条件は、コンポーネントである2つの条件の結果を結合し、その結果に基づいて1つの結果を生成します。たとえば、次の複合条件を考えます。

salary = 3800 OR job_title = 'Programmer'

このルール条件には、OR論理条件で結合された2つの条件が含まれています。どちらかの条件がTRUEと評価されると、ルール条件がTRUEと評価されます。論理条件がORではなくANDの場合、ルール条件全体がTRUEと評価されるためには、両方の条件がTRUEと評価される必要があります。

ルール条件内の変数

ルール条件には変数を使用できます。その場合は、各変数の先頭にコロン(:)を付けます。ルール条件に使用する変数の例を次に示します。

:x = 55

変数を使用すると、表に格納されていないデータを参照できます。また、変数を使用すると、共通して発生する式を置換することでパフォーマンスを改善できます。これは、同じ式が2回以上評価されるかわりに、変数が1回評価されるためです。

ルール条件には、サブプログラムのコールの評価も含めることができます。このような条件は、他の条件と同じ方法で評価されます。つまり、値TRUE、FALSEまたはNULL(不明)として評価されます。次の例に、従業員がマネージャかどうかを判断する単純なファンクションis_managerのコールを含む条件を示します。

is_manager(employee_id) = 'Y'

この場合、employee_idの値はemployee_id列を持つ表のデータによって決定されます。

変数には、ユーザー定義型を使用できます。したがって、変数では属性を指定できます。変数に属性を指定する場合、各属性には変数の部分データが含まれます。ルール条件内では、属性はドット表記法を使用して指定します。たとえば、次の条件は、変数yの属性zの値が9の場合にTRUEと評価されます。

:y.z = 9

注意:
ルールには、NULL(または空)のルール条件を含めることはできません。

関連項目:

- 条件、式および演算子の詳細は、『Oracle Database SQL言語リファレンス』を参照

- ユーザー定義型の詳細は、『Oracle Databaseオブジェクト・リレーショナル開発者ガイド』を参照

単純ルール条件

単純ルール条件とは、次のいずれかの形式で表される条件を指します。

- simple_rule_expression condition constant

- constant condition simple_rule_expression

- constant condition constant

単純ルール式

単純ルール条件では、simple_rule_expressionは次のいずれかです。

- 表の列。

- 変数。

- 変数の属性。

- 引数または定数引数を取らないメソッドの結果。そのメソッドの結果は変数メソッド・ファンクションから戻すことができるため、式は単純ルール用にサポートされているデータ型のいずれかです。このようなメソッドには、これらの要件を満たすGET_TAG、GET_VALUE、GET_COMPATIBLE、GET_EXTRA_ATTRIBUTEなどのLCRメンバー・サブプログラムが含まれます。

表の列、変数、変数の属性およびメソッドの結果については、次のデータ型を単純ルール条件に使用できます。

- VARCHAR2

- NVARCHAR2

- NUMBER

- DATE

- BINARY_FLOAT

- BINARY_DOUBLE

- TIMESTAMP

- TIMESTAMP WITH TIME ZONE

- TIMESTAMP WITH LOCAL TIME ZONE

- RAW

- CHAR

式に他のデータ型を使用すると、単純ルール条件ではなくなります。

条件

単純ルール条件では、conditionは次のいずれかです。

- <=

- <

- =

- >

- >=

- !=

- IS NULL

- IS NOT NULL

他の条件を使用すると、単純ルール条件ではなくなります。

定数

constantは固定値です。定数は次のいずれかです。

- 12や5.4などの数値

- xや$などの文字

- this is a stringなどの文字列

単純ルール条件の例

単純ルール条件の例を次に示します。式で使用されているデータ型が、単純ルール条件でサポートされていると想定しています。

- tab1.col = 5

- tab2.col != 5

- :v1 > 'aaa'

- :v2.a1 < 10.01

- :v3.m() = 10

- :v4 IS NOT NULL

- 1 = 1

- 'abc' > 'AB'

- :date_var < to_date('04-01-2004, 14:20:17', 'mm-dd-yyyy, hh24:mi:ss')

- :adt_var.ts_attribute >= to_timestamp('04-01-2004, 14:20:17 PST', 'mm-dd-yyyy, hh24:mi:ss TZR')

- :my_var.my_to_upper('abc') = 'ABC'

単純ルール条件を含むルールは、単純ルールと呼ばれます。論理条件ANDおよびORを使用して2つ以上の単純な条件を結合したルールも、単純ルールです。たとえば、次の条件を含むルールは単純ルールです。

- tab1.col = 5 AND :v1 > 'aaa'

- tab1.col = 5 OR :v1 > 'aaa'

ただし、ルールの条件内でNOT論理条件を使用すると、単純ルールではなくなります。

単純ルールのメリット

単純ルールは、次の理由で重要です。

- 単純ルールは、ルール・エンジンによって内部的に索引を付けられます。

- 単純ルールは、SQLを実行せずに評価できます。

- 単純ルールは、部分データを使用して評価できます。

クライアントがDBMS_RULE.EVALUATEプロシージャを使用してイベントを評価する場合、クライアントは、simple_rules_onlyパラメータにTRUEを指定すると、単純ルールのみを評価するように指定できます。

関連項目:

- 条件および論理条件の詳細は、『Oracle Database SQL言語リファレンス』を参照

- LCR型およびそれらのメンバー・サブプログラムの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

ルール評価コンテキスト

評価コンテキストは、ルール条件内で参照できる外部データを定義するデータベース・オブジェクトです。外部データは、変数または表データ、あるいはその両方として存在します。次のように類推するとわかりやすくなります。ルール条件がSQL問合せのWHERE句であると考えると、評価コンテキスト内の外部データは、その問合せのFROM句で参照される表およびバインド変数です。つまり、有効なWHERE句を作成するには、ルール条件内の式が評価コンテキスト内の表、表の別名および変数を参照する必要があります。

ルール評価コンテキストは、外部データを参照するルール条件の解析と評価に必要な情報を提供します。たとえば、ルールで変数を参照する場合、ルール評価コンテキスト内の情報には変数の型を含める必要があります。また、ルールで表の別名を参照する場合、評価コンテキストには表の別名を定義する情報を含める必要があります。

ルールによって参照されるオブジェクトは、そのルールに関連付けられたルール評価コンテキストによって決定されます。ルール所有者は、表に対するSELECT権限や型に対するEXECUTE権限など、これらのオブジェクトへのアクセスに必要な権限を持つ必要があります。ルール条件は、評価コンテキストを所有するスキーマ内で解決されます。

たとえば、次の情報を含むルール評価コンテキストhr_evaluation_contextを考えます。

- 表の別名depは、hr.departments表に対応します。

- 変数loc_id1およびloc_id2は、どちらもNUMBER型です。

hr_evaluation_contextルール評価コンテキストは、次のルール条件の評価に必要な情報を提供します。

dep.location_id IN (:loc_id1, :loc_id2)

この場合、loc_id1またはloc_id2変数で渡されたいずれかの値に対応する値が行のlocation_id列に含まれていると、hr.departments表のその行についてはルール条件がTRUEと評価されます。hr_evaluation_contextルール評価コンテキスト内に情報がなければ、ルールを適切に解析または評価できません。また、表の別名depでのlocation_id列の指定にドット表記法を使用していることに注意してください。

注意:
ビューは、評価コンテキストの実表としてはサポートされていません。

明示的変数と暗黙的変数

ルール条件内で参照される変数の値をルールが評価されるときに明示的に指定するか、変数の値を特定のイベントに暗黙的に使用可能にすることができます。

明示的変数は、評価時にコール元から提供されます。これらの値は、DBMS_RULE.EVALUATEプロシージャの実行時にvariable_valuesパラメータで指定します。

暗黙的変数には、評価時にコール元から提供される値が与えられません。暗黙的変数の値は、変数値のファンクションをコールすることで取得されます。このファンクションは、DBMS_RULE_ADMパッケージのCREATE_EVALUATION_CONTEXTプロシージャを使用して評価コンテキストの作成中にvariable_typesリストを指定するときに定義します。暗黙的変数の値が評価中に指定されると、その値によって変数値のファンクションから戻される値がオーバーライドされます。

特に、variable_typesリストはSYS.RE$VARIABLE_TYPE_LIST型であり、SYS.RE$VARIABLE_TYPE型の変数のリストです。リストにあるSYS.RE$VARIABLE_TYPEの各インスタンス内で、暗黙的変数の値の決定に使用されるファンクションをvariable_value_function属性として指定します。

変数が明示的であるか暗黙的であるかは、ルール・エンジンを使用するアプリケーションのデザイナによって選択されます。暗黙的変数を使用する理由は、次のとおりです。

- DBMS_RULE.EVALUATEプロシージャのコール元は、変数を意識する必要はありません。このため、ルール・エンジンを使用するアプリケーションの複雑さを軽減できます。たとえば、変数では、評価対象のデータに基づいて値を戻すファンクションをコールできます。

- コール元には、変数値のファンクションに対するEXECUTE権限がなくてもかまいません。

- DBMS_RULE.EVALUATEプロシージャのコール元は、イベントに基づいた変数値を認識しません。このため、変数値に機密情報が含まれている場合に、セキュリティを向上できます。

- 変数の使用頻度は低くなり、また変数の値は必要に応じていつでも導出できます。このような変数を暗黙的変数にすると、DBMS_RULE.EVALUATEプロシージャのコール元では、一般的ではない多数の変数を指定する必要がなくなります。

たとえば、次のルール条件では、変数xおよびyの値を明示的に指定し、変数maxの値はmaxファンクションを実行して戻すように指定できます。

:x = 4 AND :y < :max

また、変数xおよびyを暗黙的変数に、変数maxを明示的変数にすることもできます。そのため、ルール条件内では、明示的変数と暗黙的変数に構文上の違いはありません。変数が明示的であるか暗黙的であるかは、DBA_EVALUATION_CONTEXT_VARSデータ・ディクショナリ・ビューを問い合せることで判断できます。明示的変数の場合は、VARIABLE_VALUE_FUNCTIONフィールドがNULLになっています。暗黙的変数の場合、このフィールドにはその変数によってコールされるファンクションの名前が含まれます。

関連項目:

- DBMS_RULEおよびDBMS_RULE_ADMパッケージと、Oracleが提供するルールのタイプの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

- DBA_EVALUATION_CONTEXT_VARSデータ・ディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照

評価コンテキストとルール・セットおよびルールとの関連付け

ルールを評価するには、各ルールが評価コンテキストと関連付けられているか、評価コンテキストに関連付けられたルール・セットの一部である必要があります。1つの評価コンテキストを、複数のルールまたはルール・セットに関連付けることができます。次のリストに、ルールが評価されるときに使用される評価コンテキストを示します。

- 評価コンテキストがルールに関連付けられている場合は、ルールが評価されるたびにその評価コンテキストが使用され、評価対象のルール・セットに関連付けられている評価コンテキストは無視されます。

- ルールに評価コンテキストがなくても、DBMS_RULE_ADMパッケージのADD_RULEプロシージャを使用してルール・セットにルールを追加するときに、ルール用の評価コンテキストを指定した場合、ルール・セットが評価されるときには、ADD_RULEプロシージャで指定した評価コンテキストがルールに使用されます。

- ルール評価コンテキストがルールに関連付けられておらず、ADD_RULEプロシージャでも指定されていない場合、ルール・セットが評価されるときには、ルール・セットの評価コンテキストがルールに使用されます。

注意:
ルールに評価コンテキストがない場合に、そのルールを評価コンテキストのないルール・セットに追加しようとすると、ADD_RULEプロシージャの実行時に評価コンテキストを指定しないかぎりエラーが発生します。

評価ファンクション

ルール評価コンテキストで実行する評価ファンクションを作成できるようにオプションが用意されています。次のような理由で、評価ファンクションを使用できます。

- ルール・エンジンをバイパスし、かわりに評価ファンクションを使用してイベントを評価する場合。

- イベントをフィルタ処理して、一部のイベントは評価ファンクションを使用して評価し、他のイベントはルール・エンジンを使用して評価する場合。

DBMS_RULE_ADMパッケージのCREATE_EVALUATION_CONTEXTプロシージャを使用してルール評価コンテキストを作成するときに、evaluation_functionパラメータにファンクション名を指定して、ファンクションをルール評価コンテキストに関連付けます。評価ファンクションは、評価コンテキストを使用する任意のルール・セットの評価中に、ルール・エンジンによって起動されます。

DBMS_RULE.EVALUATEプロシージャはオーバーロードされます。ファンクションには、いずれかのDBMS_RULE.EVALUATEプロシージャの各パラメータが必要です。各パラメータには、DBMS_RULE.EVALUATEプロシージャ内の対応するパラメータと同じ型を使用する必要がありますが、パラメータの名前は異なってもかまいません。

評価ファンクションから戻される値は、次のとおりです。

- DBMS_RULE_ADM.EVALUATION_SUCCESS: ユーザーによって指定された評価ファンクションが、ルール・セットの評価を正常終了しました。ルール・エンジンは、評価ファンクションによって取得された評価結果をDBMS_RULE.EVALUATEプロシージャを使用してルール・エンジン・クライアントに戻します。

- DBMS_RULE_ADM.EVALUATION_CONTINUE: ルール・エンジンは、評価ファンクションが存在しない場合と同様にルール・セットを評価します。評価ファンクションは使用されず、評価ファンクションから戻されるすべての結果は無視されます。

- DBMS_RULE_ADM.EVALUATION_FAILURE: ユーザーによって指定された評価ファンクションが失敗しました。ルール・セットの評価は停止し、エラーが発生します。

ルール・エンジンを常にバイパスする場合は、評価ファンクションはEVALUATION_SUCCESSまたはEVALUATION_FAILUREを戻す必要があります。ただし、一部のイベントを評価ファンクションで評価し、他のイベントをルール・エンジンで評価するようにイベントをフィルタ処理する場合は、評価ファンクションが3つの戻り値すべてを戻すことができます。評価にルール・エンジンを使用する必要がある場合は、EVALUATION_CONTINUEを戻します。

評価コンテキストに対して評価ファンクションを指定していると、その評価コンテキストがルール・セットまたはルールによって使用される場合、評価中にその評価ファンクションが実行されます。

関連項目:
DBMS_RULE_ADM.CREATE_EVALUATION_CONTEXTプロシージャ内に指定する評価ファンクションの詳細およびオーバーロードされたDBMS_RULE.EVALUATEプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

ルール・アクション・コンテキスト

アクション・コンテキストには、イベントのルールの評価時にルール・エンジンのクライアントによって解析されるルールに関連付けられたオプションの情報が含まれています。ルール・エンジンのクライアントは、ユーザー作成アプリケーション、またはOracle StreamsなどのOracleの内部機能です。各ルールのアクション・コンテキストは1つのみです。アクション・コンテキスト内の情報は、名前/値ペアの配列を含む型であるSYS.RE$NV_LIST型です。

ルール・アクション・コンテキスト情報は、ルールがTRUEまたはMAYBEに評価される場合に、ルール・エンジンのクライアントによって実行されるアクションのコンテキストを提供します。ルール・エンジンは、アクション・コンテキストを解析しません。かわりに、ルール・エンジンはアクション・コンテキストを戻し、ルール・エンジンのクライアントがアクション・コンテキスト情報を解析できます。

たとえば、イベントが会社への新規従業員の追加として定義されているとします。従業員情報がhr.employees表に格納されている場合は、この表に行が挿入されるたびにイベントが発生します。会社は、新規従業員を追加するときにいくつかのアクションが実行されるように指定する必要がありますが、アクションは従業員の所属部門に応じて異なります。これらのアクションの1つは、従業員を部門関連のコースに登録することです。

この使用例では、会社は適切なアクション・コンテキストを使用して、各部門用のルールを作成できます。この場合、ルールがTRUEと評価された場合に戻されるアクション・コンテキストでは、従業員が参加する必要のあるコースの番号を指定します。3つの部門がある場合のルール条件の一部およびアクション・コンテキストを次に示します。

ルール名

ルール条件の一部

アクション・コンテキストの名前/値ペア

rule_dep_10

department_id = 10

course_number, 1057

rule_dep_20

department_id = 20

course_number, 1215

rule_dep_30

department_id = 30

NULL

これらのアクション・コンテキストでは、クライアント・アプリケーションに次の指示が戻されます。

- rule_dep_10ルールのアクション・コンテキストはクライアント・アプリケーションに対して、新規従業員をコース番号1057に登録するように指示します。

- rule_dep_20ルールのアクション・コンテキストはクライアント・アプリケーションに対して、新規従業員をコース番号1215に登録するように指示します。

- rule_dep_30ルールのNULLアクション・コンテキストはクライアント・アプリケーションに対して、新規従業員をどのコースにも登録しないように指示します。

各アクション・コンテキストには、0個以上の名前/値ペアを含めることができます。アクション・コンテキストに複数の名前/値ペアが含まれている場合、リスト内のそれぞれの名前は一意である必要があります。この例では、ルール・エンジンからアクション・コンテキストが戻されるクライアント・アプリケーションでは、戻されたコース番号を持つコースに新規従業員が登録されます。NULLアクション・コンテキストが戻される場合や、アクション・コンテキストにコース番号が含まれていない場合、クライアント・アプリケーションでは従業員はコースに登録されません。

複数のクライアントで同じルールを使用する場合や、アクション・コンテキストから複数の名前/値ペアが戻されるようにする必要がある場合は、1つのアクション・コンテキストで複数の名前/値ペアをリストできます。たとえば、会社が新規従業員を部門の電子メール・リストにも追加する場合を考えます。この場合、rule_dep_10ルールのアクション・コンテキストに次の2つの名前/値ペアを含めることができます。

名前

値

course_number

1057

dist_list

admin_list

名前/値ペアで指定する名前については、次のことを考慮する必要があります。

- 異なるアプリケーションで同じアクション・コンテキストを使用する場合は、異なる名前または名前の接頭辞を使用してネーミングの競合を回避してください。

- Oracleが提供するアクション・コンテキスト名との競合が発生する可能性があるため、名前には$と#を使用しないでください。

アクション・コンテキストに名前/値ペアを追加するには、RE$NV_LIST型のADD_PAIRメンバー・プロシージャを使用します。アクション・コンテキストから名前/値ペアを削除するには、RE$NV_LIST型のREMOVE_PAIRメンバー・プロシージャを使用します。アクション・コンテキスト内の既存の名前/値ペアを変更する場合は、最初にREMOVE_PAIRメンバー・プロシージャを使用して削除してから、ADD_PAIRメンバー・プロシージャを使用して適切な名前/値ペアを追加する必要があります。

注意:
Oracle Streamsでは、カスタム・ルールベースの変換にアクション・コンテキストが使用されます。サブセット・ルールが指定されている場合は、UPDATE操作を含むLCRで必要な内部変換にも、アクション・コンテキストが使用されます。また、Oracle Streamsでは、アクション・コンテキストを使用して、ルールを満たすメッセージを適用プロセスがエンキューする宛先キューを指定します。さらに、Oracle Streamsでは、アクション・コンテキストを使用して、適用プロセスのルールを満たすメッセージを適用プロセスで実行するかどうかを指定します。

関連項目:

- 「Oracle Streamsとアクション・コンテキスト」

- 「アクション・コンテキストの制限事項」

- 名前/値ペアを追加および変更する例については、「アクション・コンテキストを持つルールの作成」および「ルールの変更」を参照

- RE$NV_LIST型の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

ルール・セットの評価

ルール・エンジンは、イベントに対してルール・セットを評価します。イベントとは、ルール・エンジンのクライアントによって定義された状態変化です。クライアントは、DBMS_RULE.EVALUATEプロシージャをコールして、イベントの評価を開始します。このプロシージャを使用すると、クライアントは、イベントに関するなんらかの情報をルール・セットの評価用のルール・エンジンに送信できます。イベント自体には、クライアントがルール・エンジンに送信する情報以外の情報を含めることができます。

DBMS_RULE.EVALUATEプロシージャのコール時にクライアントによって指定される情報には、次の項目が含まれます。

- イベントの評価に使用するルールを含むルール・セットの名前。

- 評価に使用する評価コンテキスト。指定した評価コンテキストを使用するルールのみが評価されます。

- 表の値および変数値。表の値にはその表の行のデータを参照するROWIDが含まれ、変数値には明示的変数のデータが含まれます。暗黙的変数に指定された値は、変数値のファンクションを使用して取得される値をオーバーライドします。指定された変数に属性がある場合、クライアントはその変数全体に対する1つの値を送信するか、またはその変数の任意の数の属性の値を送信できます。ただし、変数全体に対する値が指定されている場合は、クライアントは属性の値を指定できません。

- オプションのイベント・コンテキスト。イベント・コンテキストは、名前/値ペアを含むSYS.RE$NV_LIST型のVARRAYで、イベントに関する情報を含みます。このオプションの情報がルール・エンジンによって直接使用または解析されることはありません。かわりに、評価ファンクション、変数値のファンクション(暗黙的変数用)、変数メソッド・ファンクションなど、クライアントのコールバックに渡されます。

また、クライアントは、DBMS_RULE.EVALUATEプロシージャを使用して、ルール・セットでのイベントの評価方法に関する情報を送信することもできます。たとえば、最初のTRUEルールまたは最初のMAYBEルール(TRUEルールがない場合)が検出された時点で評価を停止する必要があるかどうかを、コール元が指定できます。

TRUEまたはMAYBEと評価されるすべてのルールをクライアントに戻す必要がある場合、クライアントは、TRUEまたはMAYBEと評価されたルールの完全なリストを使用して評価結果が送信されるようにするか、または評価結果が繰り返し送信されるようにするかを指定できます。評価結果がクライアントに繰り返し送信される場合、クライアントは、DBMS_RULEパッケージのGET_NEXT_HITファンクションを使用して、TRUEまたはMAYBEと評価された各ルールを1つずつ取り出せます。

ルール・エンジンは、指定されたルール・セット内のルールを評価に使用し、クライアントにその結果を戻します。ルールが戻されるときには、EVALUATEプロシージャの2つのOUTパラメータが使用されます。このプロシージャはオーバーロードされ、2つのOUTパラメータはプロシージャのバージョンごとに異なります。

- プロシージャの一方のバージョンでは、TRUEと評価されるすべてのルールまたはMAYBEと評価されるすべてのルールが1つのリストで戻されます。プロシージャのこのバージョンでは、2つのOUTパラメータはtrue_rulesおよびmaybe_rulesです。true_rulesパラメータではTRUEと評価されるルールが1つのリストで戻され、maybe_rulesパラメータではさらに情報を与えるとTRUEと評価される可能性があるルールが1つのリストで戻されます。

- プロシージャのもう一方のバージョンでは、TRUEまたはMAYBEと評価されるすべてのルールがクライアントの要求に応じて繰り返し戻されます。プロシージャのこのバージョンでは、2つのOUTパラメータはtrue_rules_iteratorおよびmaybe_rules_iteratorです。true_rules_iteratorパラメータではTRUEと評価されるルールが1つずつ戻され、maybe_rules_iteratorパラメータではさらに情報を与えるとTRUEと評価される可能性があるルールが1つずつ戻されます。

ルール・セットの評価プロセス

図11-1に、ルール・セットの評価プロセスを示します。

1. クライアント定義のイベントが発生します。

2. クライアントは、DBMS_RULE.EVALUATEプロシージャを使用してイベントに関する情報をルール・エンジンに送信し、ルール・セットの評価を開始します。

3. ルール・エンジンが、関連する評価コンテキストを使用してイベントのルール・セットを評価します。クライアントが、DBMS_RULE.EVALUATEプロシージャのコールでルール・セットと評価コンテキストの両方を指定します。評価に使用されるのは、指定されたルール・セット内に存在し、指定された評価コンテキストを使用するルールのみです。

4. ルール・エンジンが評価の結果を取得します。各ルールは、TRUE、FALSEまたはNULL(不明)と評価されます。

5. ルール・エンジンが、TRUEと評価されたルールを完全なリストで、または1つずつクライアントに戻します。各ルールとともにアクション・コンテキスト全体が戻されます。アクション・コンテキストには、情報が含まれている場合とNULLの場合があります。

6. クライアントが、ルール・エンジンから戻された結果に基づいてアクションを実行します。ルール・エンジンでは、ルールの評価に基づくアクションは実行されません。

図11-1 ルール・セットの評価

関連項目:

- DBMS_RULE.EVALUATEプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

- Oracle Streamsクライアントおよびmaybe_rulesの詳細は、「NULLと評価される未定義変数を伴うルール条件」を参照

部分評価

部分評価は、指定された評価コンテキストのすべての表および変数にデータがない状態でDBMS_RULE.EVALUATEプロシージャが実行される場合に発生します。部分評価では、一部のルールが使用不可能な列、変数または属性を参照し、別の一部のルールが使用可能なデータのみを参照する場合があります。

例として、評価中に使用可能なデータが次のものにかぎられる場合を考えます。

- 列tab1.col = 7

- 属性v1.a1 = 'ABC'

次のルールが評価に使用されます。

- ルールR1には、次の条件があります。

(tab1.col = 5)

- ルールR2には、次の条件があります。

(:v1.a2 > 'aaa')

- ルールR3には、次の条件があります。

(:v1.a1 = 'ABC') OR (:v2 = 5)

- ルールR4には、次の条件があります。

(:v1.a1 = UPPER('abc'))

この使用例では、R1およびR4は使用可能なデータを、R2は使用不可能なデータを、R3は使用可能なデータおよび使用不可能なデータを参照します。

部分評価は常に、ルール内の単純な条件のみを評価します。ルール条件に単純でない部分が含まれている場合は、データがどの程度使用可能であるかに応じて、ルールが完全に評価される場合と評価されない場合があります。ルールが完全に評価されない場合、それをMAYBEルールとして戻すことができます。

前述の使用例では、R1と、R3の最初の部分が評価されますが、R2およびR4は評価されません。クライアントには次の結果が戻されます。

- R1はFALSEと評価されるため、戻されません。

- R2は、属性v1.a2に関する情報が使用可能でないため、MAYBEとして戻されます。

- R3は単純ルールであり、v1.a1の値がルール条件の最初の部分と一致するため、R3はTRUEとして戻されます。

- R4は、ルール条件が単純ではないため、MAYBEとして戻されます。このルールをTRUEまたはFALSEとして評価するには、クライアントが変数v1の値を指定する必要があります。

関連項目:
「単純ルール条件」

ルールに関連するデータベース・オブジェクトと権限

DBMS_RULE_ADMパッケージを使用して、次の型のデータベース・オブジェクトを直接作成できます。

- 評価コンテキスト

- ルール

- ルール・セット

DBMS_STREAMS_ADMパッケージを使用すると、ルールとルール・セットを間接的に作成できます。これらのデータベース・オブジェクトに対する権限を制御するには、DBMS_RULE_ADMパッケージの次のプロシージャを使用します。

- GRANT_OBJECT_PRIVILEGE

- GRANT_SYSTEM_PRIVILEGE

- REVOKE_OBJECT_PRIVILEGE

- REVOKE_SYSTEM_PRIVILEGE

ユーザーに対して独自スキーマ内でのルール・セット、ルールおよび評価コンテキストの作成を許可するには、そのユーザーに次のシステム権限を付与します。

- CREATE_RULE_SET_OBJ

- CREATE_RULE_OBJ

- CREATE_EVALUATION_CONTEXT_OBJ

これらの権限と後述する権限は、ユーザーに直接付与するか、ロールを介して付与できます。

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

- ルール関連のデータベース・オブジェクトを作成するための権限

- ルール関連のデータベース・オブジェクトを変更するための権限

- ルール関連のデータベース・オブジェクトを削除するための権限

- ルール・セットにルールを含めるための権限

- ルール・セットを評価するための権限

- 評価コンテキストを使用するための権限

注意:
ANYオブジェクト(ALTER_ANY_RULEなど)に対する権限を付与する場合に、初期化パラメータO7_DICTIONARY_ACCESSIBILITYをFALSEに設定すると、SYSスキーマを除くすべてのスキーマに含まれる指定した型のオブジェクトへのアクセス権をユーザーに付与できます。デフォルトでは、初期化パラメータO7_DICTIONARY_ACCESSIBILITYはFALSEに設定されます。
SYSスキーマ内のオブジェクトへのアクセス権を付与する場合は、オブジェクトに対するオブジェクト権限を明示的に付与できます。または、O7_DICTIONARY_ACCESSIBILITY初期化パラメータをTRUEに設定することもできます。この場合、ANYオブジェクトについて付与される権限では、SYSを含むすべてのスキーマへのアクセスが許可されます。

関連項目:

- これらのデータベース・オブジェクトの詳細は、「ルールのコンポーネント」を参照

- これらのデータベース・オブジェクトのシステム権限およびオブジェクト権限の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

- ユーザー権限の概要は、『Oracle Database概要』および』Oracle Databaseセキュリティ・ガイド』を参照

- DBMS_STREAMS_ADMパッケージを使用してルールとルール・セットを間接的に作成する方法の詳細は、第5章「Oracle Streamsでのルールの使用方法」を参照

ルール関連のデータベース・オブジェクトを作成するための権限

ユーザーがスキーマ内で評価コンテキスト、ルールまたはルール・セットを作成するには、次の条件を少なくとも1つは満たしている必要があります。

- スキーマがユーザー独自のスキーマであり、作成するデータベース・オブジェクトの型に対するCREATEシステム権限を付与されていること。たとえば、ユーザーが独自スキーマ内でルール・セットを作成するには、CREATE_RULE_SET_OBJシステム権限を付与されている必要があります。

- 作成するデータベース・オブジェクトの型に対するCREATE ANYシステム権限を付与されていること。たとえば、ユーザーが任意のスキーマ内で評価コンテキストを作成するには、CREATE_ANY_EVALUATION_CONTEXTシステム権限を付与されている必要があります。

注意:
評価コンテキストを伴うルールを作成する場合、ルール所有者は、評価コンテキストによってアクセスされるすべてのオブジェクトに対する権限を持っている必要があります。

ルール関連のデータベース・オブジェクトを変更するための権限

ユーザーが評価コンテキスト、ルールまたはルール・セットを変更するには、次の条件を少なくとも1つは満たしている必要があります。

- データベース・オブジェクトの所有者であること。

- データベース・オブジェクトが他のユーザーのスキーマにある場合は、データベース・オブジェクトに対するALTER OBJECT権限を付与されていること。たとえば、ユーザーが他のユーザーのスキーマにあるルール・セットを変更するには、そのルール・セットに対するALTER_ON_RULE_SETオブジェクト権限を付与されている必要があります。

- データベース・オブジェクトに対するALTER ANYシステム権限を付与されていること。たとえば、ユーザーが任意のスキーマにあるルールを変更するには、ALTER_ANY_RULEシステム権限を付与されている必要があります。

ルール関連のデータベース・オブジェクトを削除するための権限

ユーザーが評価コンテキスト、ルールまたはルール・セットを削除するには、次の条件を少なくとも1つは満たしている必要があります。

- データベース・オブジェクトの所有者であること。

- データベース・オブジェクトに対するDROP ANYシステム権限を付与されていること。たとえば、ユーザーが任意のスキーマにあるルール・セットを削除するには、DROP_ANY_RULE_SETシステム権限を付与されている必要があります。

ルール・セットにルールを含めるための権限

この項では、ルール・セットにルールを含めるために必要な権限について説明します。ユーザーは、ルールについて次の条件を少なくとも1つは満たしている必要があります。

- ルールの所有者であること。

- ルールが他のユーザーのスキーマにある場合は、そのルールに対するEXECUTE OBJECT権限を付与されていること。たとえば、ユーザーがhrスキーマ内でルール・セットにルールdeptsを含めるには、hr.deptsルールに対するEXECUTE_ON_RULE権限を付与されている必要があります。

- ルールに対するEXECUTE ANYシステム権限を付与されていること。たとえば、ユーザーがルール・セットに任意のルールを含めるには、EXECUTE_ANY_RULEシステム権限を付与されている必要があります。

また、ユーザーはルール・セットについて次の条件を少なくとも1つは満たしている必要があります。

- ルール・セットの所有者であること。

- ルール・セットが他のユーザーのスキーマにある場合は、そのルール・セットに対するALTER OBJECT権限を付与されていること。たとえば、ユーザーがhrスキーマ内でhuman_resourcesルール・セットにルールを含めるには、hr.human_resourcesルール・セットに対するALTER_ON_RULE_SET権限を付与されている必要があります。

- ルール・セットに対するALTER ANYシステム権限を付与されていること。たとえば、ユーザーが任意のルール・セットにルールを含めるには、ALTER_ANY_RULE_SETシステム権限を付与されている必要があります。

また、ルール所有者は、ルールによって参照されるすべてのオブジェクトに対する権限を持っている必要があります。この権限は、ルールに関連付けられた評価コンテキストが存在しない場合に重要です。

ルール・セットを評価するための権限

ルール・セットを評価するには、ユーザーは次の条件を少なくとも1つは満たしている必要があります。

- ルール・セットの所有者であること。

- ルール・セットが他のユーザーのスキーマにある場合は、そのルール・セットに対するEXECUTE OBJECT権限を付与されていること。たとえば、ユーザーがhrスキーマ内でhuman_resourcesルール・セットを評価するには、hr.human_resourcesルール・セットに対するEXECUTE_ON_RULE_SET権限を付与されている必要があります。

- ルール・セットに対するEXECUTE ANYシステム権限を付与されていること。たとえば、ユーザーが任意のルール・セットを評価するには、EXECUTE_ANY_RULE_SETシステム権限を付与されている必要があります。

ルール・セットに対するEXECUTEオブジェクト権限を付与するには、権限付与者のEXECUTE権限で、現在ルール・セットに含まれているすべてのルールについてWITH GRANT OPTIONを指定する必要があります。

評価コンテキストを使用するための権限

ルールまたはルール・セットの評価コンテキストを使用するには、ルールまたはルール・セットを所有するユーザーが、評価コンテキストに関する次の条件を少なくとも1つは満たしている必要があります。

- 評価コンテキストの所有者であること。

- 評価コンテキストが他のユーザーのスキーマにある場合は、その評価コンテキストに対するEXECUTE_ON_EVALUATION_CONTEXT権限を付与されていること。

- 評価コンテキストに対するEXECUTE_ANY_EVALUATION_CONTEXTシステム権限を付与されていること。

Oracle Streamsで使用される評価コンテキスト

次の各項では、Oracle Streamsで使用されるシステム作成の評価コンテキストについて説明します。

- グローバル・ルール、スキーマ・ルール、表ルールおよびサブセット・ルールの評価コンテキスト

- メッセージ・ルールの評価コンテキスト

グローバル・ルール、スキーマ・ルール、表ルールおよびサブセット・ルールの評価コンテキスト

グローバル・ルール、スキーマ・ルール、表ルールおよびサブセット・ルールを作成する際、システム作成のルール・セットおよびルールでは、SYSスキーマ内のSTREAMS$_EVALUATION_CONTEXTという名前の組込み評価コンテキストが使用されます。この評価コンテキストのEXECUTE権限はPUBLICに付与されます。グローバル・ルール、スキーマ・ルール、表ルールおよびサブセット・ルールは、取得プロセス、同期取得、伝播、適用プロセスおよびメッセージ・クライアントで使用できます。

Oracleのインストール中に、次の文によってOracle Streamsの評価コンテキストが作成されます。

DECLARE
vt  SYS.RE$VARIABLE_TYPE_LIST;
BEGIN
vt := SYS.RE$VARIABLE_TYPE_LIST(
SYS.RE$VARIABLE_TYPE('DML', 'SYS.LCR$_ROW_RECORD',
'SYS.DBMS_STREAMS_INTERNAL.ROW_VARIABLE_VALUE_FUNCTION',
'SYS.DBMS_STREAMS_INTERNAL.ROW_FAST_EVALUATION_FUNCTION'),
SYS.RE$VARIABLE_TYPE('DDL', 'SYS.LCR$_DDL_RECORD',
'SYS.DBMS_STREAMS_INTERNAL.DDL_VARIABLE_VALUE_FUNCTION',
'SYS.DBMS_STREAMS_INTERNAL.DDL_FAST_EVALUATION_FUNCTION'));
SYS.RE$VARIABLE_TYPE(NULL, 'SYS.ANYDATA',
NULL,
'SYS.DBMS_STREAMS_INTERNAL.ANYDATA_FAST_EVAL_FUNCTION'));
DBMS_RULE_ADM.CREATE_EVALUATION_CONTEXT(
evaluation_context_name => 'SYS.STREAMS$_EVALUATION_CONTEXT',
variable_types          => vt,
evaluation_function     =>
'SYS.DBMS_STREAMS_INTERNAL.EVALUATION_CONTEXT_FUNCTION');
END;
/

この文には、SYS.DBMS_STREAM_INTERNALパッケージ内の次の内部ファンクションへの参照が含まれます。

- ROW_VARIABLE_VALUE_FUNCTION

- DDL_VARIABLE_VALUE_FUNCTION

- EVALUATION_CONTEXT_FUNCTION

- ROW_FAST_EVALUATION_FUNCTION

- DDL_FAST_EVALUATION_FUNCTION

- ANYDATA_FAST_EVAL_FUNCTION

注意:
前述の内部ファンクションに関する情報は、あくまでも参考用です。これらのファンクションは直接実行しないでください。

ROW_VARIABLE_VALUE_FUNCTIONでは、SYS.LCR$_ROW_RECORDインスタンスをカプセル化するANYDATAペイロードがSYS.LCR$_ROW_RECORDインスタンスに変換されてから、データに対するルールが評価されます。

DDL_VARIABLE_VALUE_FUNCTIONでは、SYS.LCR$_DDL_RECORDインスタンスをカプセル化するANYDATAペイロードがSYS.LCR$_DDL_RECORDインスタンスに変換されてから、データに対するルールが評価されます。

EVALUATION_CONTEXT_FUNCTIONは、CREATE_EVALUATION_CONTEXTプロシージャのコールでevaluation_functionとして指定されます。このファンションによって、取得LCRに対する通常のルール評価が補足されます。取得プロセスによって行LCRとDDL LCRがそのキューにエンキューされ、このファンクションによってコミット、ロールバック、データ・ディクショナリの変更などの他の内部メッセージをキューにエンキューできます。取得プロセスによってエンキューされる情報は、伝播または適用プロセスのルール評価中にも使用されます。同期取得ではEVALUATION_CONTEXT_FUNCTIONは使用されません。

ROW_FAST_EVALUATION_FUNCTIONでは、ルール評価中に次のLCR$_ROW_RECORDメンバー・ファンクションへのアクセスを最適化することで、パフォーマンスが改善されます。

- GET_OBJECT_OWNER

- GET_OBJECT_NAME

- IS_NULL_TAG

- GET_SOURCE_DATABASE_NAME

- GET_COMMAND_TYPE

DDL_FAST_EVALUATION_FUNCTIONでは、条件が<、<=、=、>=または>であり、残りのオペランドが定数である場合は、ルール評価中に次のLCR$_DDL_RECORDメンバー・ファンクションへのアクセスを最適化することで、パフォーマンスが改善されます。

- GET_OBJECT_OWNER

- GET_OBJECT_NAME

- IS_NULL_TAG

- GET_SOURCE_DATABASE_NAME

- GET_COMMAND_TYPE

- GET_BASE_TABLE_NAME

- GET_BASE_TABLE_OWNER

ANYDATA_FAST_EVAL_FUNCTIONでは、ANYDATAオブジェクト内の値へのアクセスを最適化することで、パフォーマンスが改善されます。

DBMS_STREAMS_ADMパッケージを使用して作成されたルールでは、ADD_SUBSET_RULESまたはADD_SUBSET_PROPAGATION_RULESプロシージャを使用して作成されたサブセット・ルールを除き、ROW_FAST_EVALUATION_FUNCTIONまたはDDL_FAST_EVALUATION_FUNCTIONが使用されます。

関連項目:

- LCRとそのメンバー・ファンクションの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

メッセージ・ルールの評価コンテキスト

ADD_MESSAGE_RULEまたはADD_MESSAGE_PROPAGATION_RULEプロシージャを使用してメッセージ・ルールを作成する場合、メッセージ・ルールでは作成時に指定したユーザー定義のメッセージ・タイプが使用されます。このようなシステム作成メッセージ・ルールでは、システム作成評価コンテキストが使用されます。システム作成評価コンテキスト名は、メッセージ・ルールの作成に使用されるメッセージ・タイプごとに異なります。このような評価コンテキストにはシステム生成名が付けられ、ルールを所有するスキーマに作成されます。この評価コンテキストのEXECUTE権限は、この評価コンテキストを所有するユーザーにのみ付与されます。

このタイプのメッセージ・ルールの評価コンテキストには、メッセージ・タイプと同じタイプの変数が含まれます。この変数の名前はVAR$_numberという形式になります(numberはシステム生成番号)。たとえば、メッセージ・ルールの作成時にstrmadmin.region_pri_msgをメッセージ・タイプとして指定すると、システム作成評価コンテキストにこのタイプの変数が組み込まれ、変数がルール条件で使用されます。次の文によってstrmadmin.region_pri_msgタイプを作成したと想定します。

CREATE TYPE strmadmin.region_pri_msg AS OBJECT(
region         VARCHAR2(100),
priority       NUMBER,
message        VARCHAR2(3000))
/

このタイプを使用してメッセージ・ルールを作成すると、次のルール条件を指定できます。

:msg.region = 'EUROPE' AND :msg.priority = '1'

システム作成メッセージ・ルールでは、指定したルール条件の:msgが変数名で置換されます。置換されたメッセージ・ルール条件の例を次に示します。

:VAR$_52.region = 'EUROPE' AND  :VAR$_52.priority = '1'

この場合、VAR$_52が変数名、変数VAR$_52のタイプがstrmadmin.region_pri_msgであり、ルールの評価コンテキストにこの変数が含まれます。

メッセージ・ルールそのものに評価コンテキストが含まれます。次のような文によってメッセージ・ルールの評価コンテキストが作成されます。

DECLARE
vt  SYS.RE$VARIABLE_TYPE_LIST;
BEGIN
vt := SYS.RE$VARIABLE_TYPE_LIST(
SYS.RE$VARIABLE_TYPE('VAR$_52', 'STRMADMIN.REGION_PRI_MSG',
'SYS.DBMS_STREAMS_INTERNAL.MSG_VARIABLE_VALUE_FUNCTION', NULL));
DBMS_RULE_ADM.CREATE_EVALUATION_CONTEXT(
evaluation_context_name => 'STRMADMIN.EVAL_CTX$_99',
variable_types          => vt,
evaluation_function     => NULL);
END;
/

評価コンテキストの名前はEVAL_CTX$_numberという形式になります(numberはシステム生成番号)。この例では、評価コンテキスト名はEVAL_CTX$_99になります。

この文には、SYS.DBMS_STREAM_INTERNALパッケージのMSG_VARIABLE_VALUE_FUNCTION内部ファンクションへの参照も含まれています。このファンクションでは、メッセージ・インスタンスをカプセル化するANYDATAペイロードが変数と同じタイプのインスタンスに変換された後、データに対するルールが評価されます。たとえば、変数のタイプがstrmadmin.region_pri_msgである場合、MSG_VARIABLE_VALUE_FUNCTIONでは、メッセージ・ペイロードがANYDATAペイロードからstrmadmin.region_pri_msgペイロードに変換されます。

様々なメッセージ・タイプについてルールを作成する場合、Oracleでは、それぞれのメッセージ・タイプに対して異なる評価コンテキストが作成されます。既存のルールと同じメッセージ・タイプのルールを作成する場合、新規ルールでは既存のルールの評価コンテキストが使用されます。ADD_MESSAGE_RULEまたはADD_MESSAGE_PROPAGATION_RULEによってメッセージ・クライアントまたは適用プロセスのルール・セットを作成する場合は、新規のルール・セットには評価コンテキストが含まれません。

関連項目:

- 「メッセージ・ルール」

- 「グローバル・ルール、スキーマ・ルール、表ルールおよびサブセット・ルールの評価コンテキスト」

- 「特定のOracle Streamsクライアントによって使用されるOracle Streamsルールの表示」

Oracle Streamsおよびイベント・コンテキスト

Oracle Streamsで、取得プロセス、同期取得およびメッセージ・クライアントではイベント・コンテキストは使用されませんが、伝播および適用プロセスでは使用されます。取得LCR、バッファLCR、バッファ・ユーザー・メッセージ、永続LCRおよび永続ユーザー・メッセージの各タイプのメッセージを、キュー内でステージングできます。メッセージがキュー内でステージングされると、伝播または適用プロセスでは、メッセージとイベント・コンテキストを評価するためにルール・エンジンに送信できます。イベント・コンテキストには常に、AQ$_MESSAGEを名前、メッセージを値とする名前/値ペアがあります。

カスタム評価コンテキストを作成する場合は、暗黙的変数を使用して、Oracle Streamsイベントを参照する伝播および適用プロセスのルールを作成できます。各暗黙的変数の変数値ファンクションでは、AQ$_MESSAGEという名前のイベント・コンテキストをチェックできます。この名前のイベント・コンテキストが検出されると、変数値ファンクションによってメッセージに基づく値が返されます。イベント・コンテキストは、評価ファンクションおよび変数メソッド・ファンクションにも渡すことができます。

関連項目:

- イベント・コンテキストの詳細は、「ルール・セットの評価」を参照

- 変数値ファンクションの詳細は、「明示的変数と暗黙的変数」を参照

- 「評価ファンクション」

Oracle Streamsおよびアクション・コンテキスト

次の各項では、Oracle Streamsにおけるアクション・コンテキストの用途と、特定のルール条件についてTRUEと評価できるルールがルール・セット内に1つのみであることの重要性について説明します。

Oracle Streamsにおけるアクション・コンテキストの用途

Oracle Streamsにおけるアクション・コンテキストの用途は、次のとおりです。

- サブセット・ルールでの内部LCR変換

- 宣言ルールベースの変換に関する情報

- カスタム・ルールベースの変換

- 適用時のメッセージの実行ディレクティブ

- 適用時のメッセージのエンキューの宛先

それぞれの用途に対し、ルールのアクション・コンテキストには異なる名前/値ペアが存在する場合があります。ルールのアクション・コンテキストに複数の名前/値ペアが含まれる場合、名前/値ペアで指定または記述されたアクションは、次の順序で実行されます。

1. サブセットの変換が実行されます。

2. 宣言ルールベースの変換に関する情報が表示されます。

3. カスタム・ルールベースの変換が実行されます。

4. 実行ディレクティブに従います。指示があれば、その指示が実行されます(適用のみ)。

5. 宛先キューにエンキューされます(適用のみ)。

注意:
ルールのアクション・コンテキストで指定されたアクションは、そのルールが取得プロセス、同期取得、伝播、適用プロセスまたはメッセージ・クライアントのポジティブ・ルール・セットに含まれる場合にのみ実行されます。ルールがネガティブ・ルール・セットに含まれる場合、そのルールのアクション・コンテキストはこれらのOracle Streamsクライアントによって無視されます。

サブセット・ルールでの内部LCR変換

サブセット・ルールを使用すると、更新操作が、取得、伝播、適用またはデキューされる際に挿入操作または削除操作に変換されることがあります。この自動変換は行の移行と呼ばれ、サブセット・ルールがTRUEと評価された場合に、アクション・コンテキストで指定された内部変換によって実行されます。サブセット変換の名前/値ペアでは、名前はSTREAMS$_ROW_SUBSET、値はINSERTまたはDELETEとなります。

関連項目:

- 「サブセット・ルール」

- サブセット・ルールでルールベースの変換を使用する方法については、第19章「ルールベースの変換の管理」を参照

宣言ルールベースの変換に関する情報

宣言ルールベースの変換は、ルールがTRUEと評価された結果発生する行LCRの内部変更です。宣言ルールベースの変換の名前/値ペアでは、名前はSTREAMS$_INTERNAL_TRANFORM、値は変換に関する追加情報を提供するデータ・ディクショナリ・ビューの名前となります。

宣言ルールベースの変換に追加される名前/値ペアは、あくまでも参考用です。これらの名前/値ペアは、Oracle Streamsクライアントによって使用されません。ただし、アクション・コンテキストに記述された宣言ルールベースの変換は、同じアクション・コンテキストに指定されたどのカスタム・ルールベースの変換よりも前に内部的に実行されます。

関連項目:

- 「宣言ルールベースの変換」

- 「宣言ルールベースの変換の管理」

カスタム・ルールベースの変換

カスタム・ルールベースの変換は、ルールがTRUEと評価された場合に発生する、ユーザー定義ファンクションによるメッセージの変更です。カスタム・ルールベースの変換の名前/値ペアでは、名前はSTREAMS$_TRANSFORM_FUNCTION、値は変換ファンクションの名前となります。

関連項目:

- 「カスタム・ルールベースの変換」

- 「カスタム・ルールベースの変換の管理」

適用時のメッセージの実行ディレクティブ

DBMS_APPLY_ADMパッケージのSET_EXECUTEプロシージャでは、指定されたルールを満たすメッセージが適用プロセスで実行されるかどうかが指定されます。適用プロセスでメッセージを実行しない場合、実行ディレクティブの名前/値ペアでは、名前はAPPLY$_EXECUTE、値はNOとなります。ルールを満たすメッセージを適用プロセスで実行する場合は、そのルールのアクション・コンテキストにこの名前/値ペアを含めません。

関連項目:
「適用プロセスの実行ディレクティブの指定」

適用時のメッセージのエンキューの宛先

DBMS_APPLY_ADMパッケージのSET_ENQUEUE_DESTINATIONプロシージャでは、指定されたルールを満たすメッセージが適用プロセスによって自動的にエンキューされるキューが設定されます。エンキューの宛先の名前/値ペアでは、名前はAPPLY$_ENQUEUE、値は宛先キューの名前となります。

関連項目:
「適用プロセスによるメッセージのエンキューの指定」

特定のルール条件についてTRUEと評価できるルールが1つのみであることの確認

ポジティブ・ルール・セット内の1つ以上のルールにNULL以外のアクション・コンテキストを使用する場合は、特定のルール条件についてTRUEと評価できるルールが1つのみであることを確認してください。特定の条件について複数のルールがTRUEと評価された場合も、返されるルールは1つのみであるため、予測できない結果が発生する可能性があります。

たとえば、hr.employees表に対するDML変更がLCRに含まれている場合に2つのルールがTRUEと評価されるとします。最初のルールにはNULLのアクション・コンテキストがあります。2つ目のルールには、カスタム・ルールベースの変換を指定するアクション・コンテキストがあります。hr.employees表に対するDML変更が存在する場合、両方のルールが変更についてTRUEと評価されますが、返されるルールは1つのみです。この場合、どちらのルールが返されるかに応じて、変換が行われる場合と行われない場合があります。

いずれかのルールにNULL以外のアクション・コンテキストがあるかどうかに関係なく、TRUEと評価できるルールがどの条件についてもポジティブ・ルール・セット内で1つのみになるようにする必要があります。このガイドラインに従うと、NULL以外のアクション・コンテキストが将来ルールに追加された場合などでも、予測できない結果を回避できます。

関連項目:
第6章「ルールベースの変換」

スキーマ・ルールおよびグローバル・ルールに関するアクション・コンテキストの考慮事項

スキーマ・ルールまたはグローバル・ルールに、カスタム・ルールベースの変換、エンキューの宛先、または実行ディレクティブのアクション・コンテキストを使用すると、そのアクション・コンテキストで指定されたアクションは、メッセージによってスキーマ・ルールまたはグローバル・ルールがTRUEと評価された場合に、メッセージに対して実行されます。たとえば、スキーマ・ルールにカスタム・ルールベースの変換を指定するアクション・コンテキストがある場合、スキーマ内の表のLCRに対して変換が実行されます。

スキーマ・ルールまたはグローバル・ルールにアクション・コンテキストを使用するが、アクション・コンテキストによって実行されるアクションからLCRのサブセットを除外する場合があります。たとえば、hrスキーマ内のjob_history表を除くすべての表に対してカスタム・ルールベースの変換を実行する場合は、表がjob_historyである場合に変換ファンクションによって元のLCRが返されるようにします。

hrスキーマ内のjob_history表を除くすべての表に対してエンキューの宛先または実行ディレクティブを設定する場合は、スキーマ・ルールを使用して、次の条件を追加できます。

:dml.get_object_name() != 'JOB_HISTORY'

この場合、job_history表のLCRがTRUEと評価されても、エンキューまたは実行ディレクティブが実行されないようにするために、この表の表ルールをポジティブ・ルール・セットに追加できます。つまり、スキーマ・ルールにはエンキューの宛先または実行ディレクティブが含まれますが、表ルールにはそれらが含まれません。

関連項目:
スキーマ・ルールおよびグローバル・ルールの詳細は、「システム作成ルール」を参照

ユーザー作成ルール、ルール・セットおよび評価コンテキスト

DBMS_STREAMS_ADMパッケージでは、システム作成のルールおよびルール・セットが生成されます。また、Oracleが提供する評価コンテキストがルールおよびルール・セットに対して指定されるか、システム作成評価コンテキストが生成されます。DBMS_STREAMS_ADMパッケージを使用して作成できないルール、ルール・セットまたは評価コンテキストを作成する必要がある場合は、DBMS_RULE_ADMパッケージを使用してそれらを作成できます。

次のような場合に、DBMS_RULE_ADMパッケージを使用します。

- 特定タイプの操作のルール条件や、LIKE条件を使用するルール条件など、DBMS_STREAMS_ADMパッケージでは作成できないルール条件のあるルールを作成する必要がある場合。

- Oracle Streams環境でルールのカスタム評価コンテキストを作成する必要がある場合。

DBMS_RULE_ADMパッケージを使用してルール・セットを作成し、それを取得プロセス、同期取得、伝播、適用プロセスまたはメッセージ・クライアントに関連付けることができます。このようなルール・セットは、Oracle Streamsクライアントのポジティブ・ルール・セットまたはネガティブ・ルール・セットとして使用でき、1つのルール・セットを1つのOracle Streamsクライアントのポジティブ・ルール・セットおよび別のOracle Streamsクライアントのネガティブ・ルール・セットとして使用することもできます。

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

- ユーザー作成ルールとルール・セット

- ユーザー作成評価コンテキスト

関連項目:

- 「取得プロセスのルール・セットの指定」

- 「伝播のルール・セットの指定」

- 「適用プロセスのルール・セットの指定」

ユーザー作成ルールとルール・セット

次の各項では、DBMS_RULE_ADMパッケージを使用して作成できる一部のタイプのルールおよびルール・セットについて説明します。

- 特定タイプの操作に関するルール条件

- サポートされていないLCRを廃棄するようにOracle Streamsクライアントに指示するルール条件

- 複合ルール条件

- NULLと評価される未定義変数を伴うルール条件

- ルール条件のファンクション・パラメータとしての変数

注意:
DBMS_STREAMS_ADMパッケージの一部のプロシージャで使用可能なand_conditionパラメータを使用して、ユーザー定義条件をシステム作成ルールに追加できます。and_conditionパラメータを使用する方が、DBMS_RULE_ADMパッケージでルールを作成するよりも簡単な場合があります。

関連項目:
and_conditionパラメータの詳細は、「システム作成ルールへのユーザー定義条件の追加」を参照

特定タイプの操作に関するルール条件

特定タイプの操作を含む変更のみの取得、伝播、適用またはデキューが必要になることがあります。たとえば、特定の表に対する挿入操作のみが含まれ、更新や削除などの他の操作が含まれない変更の適用が必要な場合があります。

hr.employees表に対するINSERT操作についてのみTRUEと評価されるルール条件を指定する場合を考えます。そのためには、ルール条件でINSERTコマンド・タイプを指定します。

:dml.get_command_type() = 'INSERT' AND :dml.get_object_owner() = 'HR'
AND :dml.get_object_name() = 'EMPLOYEES' AND :dml.is_null_tag() = 'Y'

同様に、DELETE操作を除き、hr.departments表に対するすべてのDML操作についてTRUEと評価されるルール条件を指定する場合を考えます。そのためには、次のルール条件を指定します。

:dml.get_object_owner() = 'HR' AND :dml.get_object_name() = 'DEPARTMENTS' AND
:dml.is_null_tag() = 'Y' AND (:dml.get_command_type() = 'INSERT' OR
:dml.get_command_type() = 'UPDATE')

このルール条件は、DELETE操作を除き、hr.departments表に対するINSERTおよびUPDATE操作についてはTRUEと評価されます。hr.departments表にはLOB列が含まれていないため、DML操作のLOBコマンド・タイプ(LOB ERASE、LOB WRITEおよびLOB TRIM)を指定する必要はありませんが、1つ以上のLOB列を含む表のルール条件ではこれらのコマンド・タイプを指定する必要があります。

次のルール条件では、hr.departments表に対して同じ動作が実行されます。つまり、次のルール条件では、DELETE操作を除き、hr.departments表に対するすべてのDML操作についてTRUEと評価されます。

:dml.get_object_owner() = 'HR' AND :dml.get_object_name() = 'DEPARTMENTS' AND
:dml.is_null_tag() = 'Y' AND :dml.get_command_type() != 'DELETE'

この項で前述した例のルール条件は、すべて単純ルール条件です。ただし、システム作成ルール条件にカスタム条件を追加すると、条件全体が単純ルール条件でなくなる可能性があり、単純ルールでないルールは効率的に評価されないことがあります。通常は、ルール評価のパフォーマンスを改善するために、可能なかぎり単純ルール条件を使用する必要があります。DBMS_STREAMS_ADMパッケージを使用して作成され、カスタム条件が追加されていないルール条件は常に単純です。

関連項目:

- 「単純ルール条件」

- 「複合ルール条件」

サポートされていないLCRを廃棄するようにOracle Streamsクライアントに指示するルール条件

ルール条件で次のファンクションを使用して、サポートされていない変更をカプセル化するLCRを廃棄するようにOracle Streamsクライアントに指示できます。

- LCR用のGET_COMPATIBLEメンバー・ファンクション。このファンクションでは、LCRのサポートに必要なデータベースの最小互換レベルが返されます。

- DBMS_STREAMSパッケージのCOMPATIBLE_9_2ファンクション、COMPATIBLE_10_1ファンクション、COMPATIBLE_10_2ファンクション、COMPATIBLE_11_1ファンクション、COMPATIBLE_11_2ファンクションおよびMAX_COMPATIBLEファンクション。これらのファンクションでは、それぞれデータベースの9.2.0、10.1.0、10.2.0、11.1.0、11.2.0および最大互換性に対応する定数の値が返されます。Oracle Databaseの互換性は、COMPATIBLE初期化パラメータを使用して制御します。

たとえば、次のルールを考えてみます。

BEGIN
DBMS_RULE_ADM.CREATE_RULE(
rule_name => 'strmadmin.dml_compat_9_2',
condition => ':dml.GET_COMPATIBLE() > DBMS_STREAMS.COMPATIBLE_9_2()');
END;
/

このルールが取得プロセス、伝播、適用プロセスなどのOracle Streamsクライアントのネガティブ・ルール・セットに含まれる場合は、Oracle9i Database リリース2(9.2)と互換性のない行LCRがOracle Streamsによって廃棄されます。

ポジティブ・ルール・セットの場合のより適切な例を次に示します。

BEGIN
DBMS_RULE_ADM.CREATE_RULE(
rule_name => 'strmadmin.dml_compat_9_2',
condition => ':dml.GET_COMPATIBLE() <= DBMS_STREAMS.COMPATIBLE_10_1()');
END;
/

このルールがOracle Streamsクライアントのポジティブ・ルール・セットに含まれる場合、Oracle Database 10g リリース1以下と互換性のない行LCRがOracle Streamsクライアントによって廃棄されます。つまり、Oracle9i Database リリース2(9.2)またはOracle Database 10g リリース1(10.1)と互換性があり、ルール・セットのその他のルールを満たす行LCRはOracle Streamsクライアントによって処理されますが、これらのリリースと互換性のない行LCRは廃棄されます。

次のルールをポジティブ・ルール・セットに追加すると、現在のリリースのOracle DatabaseのOracle Streamsでサポートされていない行LCRを廃棄できます。

BEGIN
DBMS_RULE_ADM.CREATE_RULE(
rule_name => 'strmadmin.dml_compat_max',
condition => ':dml.GET_COMPATIBLE() < DBMS_STREAMS.MAX_COMPATIBLE()');
END;
/

MAX_COMPATIBLEファンクションでは、常に、最大互換性が返されます。最大互換性はDBMS_STREAMSパッケージによって返される互換性定数よりも大きい値になります。したがって、このファンクションをルール条件で使用すると、以降のリリースのOracle Databaseにアップグレードする場合にルール条件を変更する必要がありません。以降のリリースで新しくサポートされている変更は自動的に取得され、新たにサポートされる変更を含むLCRは廃棄されません。

前述の例のルールは効率的に評価されます。DBMS_STREAMS_ADMパッケージによって作成されたスキーマ・ルールまたはグローバル・ルールを使用してLCRを取得、伝播、適用またはデキューする場合は、これらのルールを使用して、特定のデータベースでサポートされていないLCRを廃棄できます。

注意:

- DBA_STREAMS_UNSUPPORTEDおよびDBA_STREAMS_COLUMNSデータ・ディクショナリ・ビューを問い合せると、Oracle Streamsでサポートされていないデータベース内のデータベース・オブジェクトを特定できます。

- DBMS_RULE_ADMパッケージを使用してGET_COMPATIBLE条件のあるルールを作成するかわりに、DBMS_STREAMS_ADMパッケージのいずれかのプロシージャを使用して、AND_CONDITIONパラメータでGET_COMPATIBLE条件を指定すると、このようなルールを作成できます。

- DDL LCRは常にDBMS_STREAMS.COMPATIBLE_9_2を返します。

関連項目:

- 「Oracle Streams環境での互換性の監視」

- 「グローバル・ルールの例」、「スキーマ・ルールの例」および「システム作成ルールへのユーザー定義条件の追加」

- COMPATIBLE初期化パラメータの詳細は、『Oracle Databaseリファレンス』およびOracle Databaseアップグレード・ガイドを参照

複合ルール条件

複合ルール条件とは、「単純ルール条件」で説明した単純ルール条件の要件を満たしていないルール条件です。Oracle Streams環境では、DBMS_STREAMS_ADMパッケージによって作成されるルールには単純ルール条件のみが含まれ、システム作成ルールにはカスタム条件が追加されていないことが想定されます。

DBMS_STREAMS_ADMパッケージで作成できる各タイプのシステム作成ルール条件については、表5-3を参照してください。複合条件のあるルールを作成する必要がある場合は、DBMS_RULE_ADMパッケージを使用できます。

様々な複合ルール条件があります。次の各項では、複合ルール条件の例をいくつか示します。

注意:

- 複合ルール条件は、ルール評価のパフォーマンスを低下させる場合があります。

- ルール条件でデータベース名を指定する場合は、ドメイン名を含む完全データベース名を指定する必要があります。

NOT論理条件を使用してオブジェクトを除外するルール条件

NOT論理条件を使用すると、Oracle Streams環境で特定の変更を取得、伝播、適用またはデキューから除外できます。

たとえば、hr.regions表の変更を除き、hrスキーマ内のすべてのデータベース・オブジェクトに対するすべてのDML変更およびDDL変更についてTRUEと評価されるルール条件を指定する必要があるとします。NOT論理条件を使用すると、DML変更用に1つとDDL変更用に1つ、合計2つのルールを使用して、このルール条件を指定できます。これらのルールのルール条件を次に示します。

(:dml.get_object_owner() = 'HR' AND NOT :dml.get_object_name() = 'REGIONS')
AND :dml.is_null_tag() = 'Y' ((:ddl.get_object_owner() = 'HR' OR :ddl.get_base_
table_owner() =   'HR') AND NOT :ddl.get_object_name() = 'REGIONS') AND :ddl.is_
null_tag() = 'Y'

この例ではHRやREGIONSなどのオブジェクト名がすべて大文字で指定されていることに注意してください。ルールが正しく評価されるには、表やユーザーなどのオブジェクト名での大/小文字の表記が、データ・ディクショナリでの大/小文字の表記と一致する必要があります。したがって、オブジェクトの作成時に大/小文字の表記が指定されなかった場合、ルール条件ではオブジェクト名をすべて大文字で指定します。ただし、オブジェクトの作成時に二重引用符を使用して特定の大/小文字の表記を指定した場合は、ルール条件でも同じように大/小文字の表記を指定します。ただし、ルール条件ではオブジェクト名を二重引用符で囲むことはできません。

たとえば、HRスキーマ内のREGIONS表が実際には"Regions"という名前で作成された場合、この表に関連するルール条件では、次の例のようにRegionsを指定します。

:dml.get_object_name() = 'Regions'

DBMS_RULE_ADMパッケージを使用してこれらのルールを作成する場合は、Oracle Streams評価コンテキストを使用できます。次の例では、複合ルールを保持するルール・セットを作成し、前述の条件を伴うルールを作成して、それらのルールをルール・セットに追加します。

BEGIN
-- Create the rule set
DBMS_RULE_ADM.CREATE_RULE_SET(
rule_set_name       => 'strmadmin.complex_rules',
evaluation_context  => 'SYS.STREAMS$_EVALUATION_CONTEXT');
-- Create the complex rules
DBMS_RULE_ADM.CREATE_RULE(
rule_name  => 'strmadmin.hr_not_regions_dml',
condition  => ' (:dml.get_object_owner() = ''HR'' AND NOT ' ||
' :dml.get_object_name() = ''REGIONS'') AND ' ||
' :dml.is_null_tag() = ''Y'' ');
DBMS_RULE_ADM.CREATE_RULE(
rule_name  => 'strmadmin.hr_not_regions_ddl',
condition  => ' ((:ddl.get_object_owner() = ''HR'' OR ' ||
' :ddl.get_base_table_owner() =   ''HR'') AND NOT ' ||
' :ddl.get_object_name() = ''REGIONS'') AND ' ||
' :ddl.is_null_tag() = ''Y'' ');
--  Add the rules to the rule set
DBMS_RULE_ADM.ADD_RULE(
rule_name      => 'strmadmin.hr_not_regions_dml',
rule_set_name  => 'strmadmin.complex_rules');
DBMS_RULE_ADM.ADD_RULE(
rule_name      => 'strmadmin.hr_not_regions_ddl',
rule_set_name  => 'strmadmin.complex_rules');
END;
/

この場合、ルールはルール・セットからOracle Streams評価コンテキストを継承します。

注意:
ほとんどの場合、DBMS_STREAMS_ADMパッケージを使用してOracle Streamsクライアントのネガティブ・ルール・セットにルールを追加すれば、NOT論理条件を持つ複合ルールを使用する必要はありません。

関連項目:
「システム作成ルールとネガティブ・ルール・セット」

LIKE条件を使用するルール条件

LIKE条件を使用すると、ルールの条件が指定されたパターンと一致する場合にTRUEと評価される複合ルールを作成できます。たとえば、JOBというパターンで始まるhrスキーマ内のすべてのデータベース・オブジェクトに対するすべてのDML変更およびDDL変更についてTRUEと評価されるルール条件を指定する必要があるとします。DML変更用に1つとDDL変更用に1つ、合計2つのルール条件を指定して、LIKE条件を使用できます。これらのルールのルール条件を次に示します。

(:dml.get_object_owner() = 'HR' AND :dml.get_object_name() LIKE 'JOB%')
AND :dml.is_null_tag() = 'Y'

((:ddl.get_object_owner() = 'HR' OR :ddl.get_base_table_owner() =      'HR')
AND :ddl.get_object_name() LIKE 'JOB%') AND :ddl.is_null_tag() = 'Y'

NULLと評価される未定義変数を伴うルール条件

評価中に、変数に対する変数値のファンクションからNULLが返される場合、ルール条件内の暗黙的変数は未定義となります。DBMS_RULE.EVALUATEプロシージャの実行時に変数の値がクライアントからルール・エンジンに送信されないと、ルール条件内に属性を持たない明示的変数は未定義となります。

属性を持つ変数に関しては、DBMS_RULE.EVALUATEプロシージャの実行時にクライアントからルール・エンジンへ、変数またはそのいずれかの属性の値が送信されないと、変数は未定義となります。たとえば、変数xが属性aとbを持つ場合、クライアントからxの値が送信されず、aの値もbの値も送信されないと、この変数は未定義となります。ただし、1つ以上の属性の値がクライアントから送信されると、この変数は定義されます。この場合では、クライアントからaの値が送信され、bの値が送信されなくても、この変数は定義されます。

ルール条件内の未定義の変数は、取得プロセス、同期取得、伝播、適用プロセスおよびメッセージ・クライアントを含む、ルール・エンジンのOracle Streamsクライアントに対して NULLと評価されます。これに対し、ルール・エンジンのOracle Streams以外のクライアントに対しては、ルール条件内の未定義の変数が原因で、ルール・エンジンからクライアントにmaybe_rulesが返されることがあります。ルール・セットの評価時に、さらに情報を提供するとTRUEと評価される可能性があるルールがmaybe_rulesです。

未定義の各変数をNULLとして処理すると、Oracle Streamsクライアントに返されるmaybe_rulesの数が削減されます。maybe_rulesの数が削減され、その結果、メッセージの発生時にルール・セットがより効率的に評価されれば、パフォーマンスが改善される可能性があります。Oracle Streams以外のクライアントにmaybe_rulesを返すルールは、次の各例に示すように、Oracle Streamsクライアントに対してはTRUEまたはFALSEのルールとなる可能性があります。

Oracle Streamsクライアントに対してTRUEルールとなる未定義変数の例

次のユーザー定義ルール条件を考えてみます。

:m IS NULL

評価中に変数mの値が定義されない場合、ルール・エンジンのOracle Streams以外のクライアントにmaybeルールが発生します。ただし、Oracle Streamsクライアントについては、未定義変数mがNULLとして処理されるため、この条件はTRUEと評価されます。このようなルールはすべてのメッセージに対してTRUEと評価されるため、Oracle Streamsクライアントのルール・セットには追加しないでください。そのため、たとえば、取得プロセスのポジティブ・ルール・セットにこのようなルールが含まれる場合、取得の対象外とされているメッセージが取得プロセスによって取得される場合があります。

次に、Oracle Streamsの:dml変数を使用する別のユーザー指定ルール条件を示します。

:dml.get_object_owner() = 'HR' AND :m IS NULL

Oracle Streamsクライアントでは、メッセージがhrスキーマ内の表に対する行変更で構成されていて、評価時に変数mの値が不明な場合、未定義変数mがNULLとして処理されるため、この条件はTRUEと評価されます。

Oracle Streamsクライアントに対してFALSEルールとなる未定義変数の例

次のユーザー定義ルール条件を考えてみます。

:m = 5

評価中に変数mの値が定義されない場合、ルール・エンジンのOracle Streams以外のクライアントにmaybeルールが発生します。ただし、Oracle Streamsクライアントについては、未定義変数mがNULLとして処理されるため、この条件はFALSEと評価されます。

Oracle Streamsの:dml変数を使用する別のユーザー指定ルール条件を考えてみます。

:dml.get_object_owner() = 'HR' AND :m = 5

Oracle Streamsクライアントでは、メッセージがhrスキーマ内の表に対する行変更で構成されていて、評価時に変数mの値が不明な場合、未定義変数mがNULLとして処理されるため、この条件はFALSEと評価されます。

関連項目:
「ルール・セットの評価」

ルール条件のファンクション・パラメータとしての変数

ルール条件のファンクション・パラメータとして、:dmlおよび:ddl変数を使用しないことをお薦めします。次の例では、:dml変数がmy_functionというファンクションのパラメータとして使用されています。

my_function(:dml) = 'Y'

このようなルール条件を指定すると、ルール評価のパフォーマンスが低下したり、誤ったOracle Streamsデータ・ディクショナリ情報が取得または伝播される結果となる可能性があります。

関連項目:
「Oracle Streamsデータ・ディクショナリ」

ユーザー作成評価コンテキスト

Oracle Streams環境では、カスタム評価コンテキストを使用できます。LCRに関連するユーザー定義評価コンテキストには、SYS.STREAMS$_EVALUATION_CONTEXT内のすべての変数を含める必要があります。各変数のタイプとその変数値ファンクションは、SYS.STREAMS$_EVALUATION_CONTEXTで変数ごとに定義されているタイプおよびファンクションと同じである必要があります。また、DBMS_RULE_ADM.CREATE_EVALUATION_CONTEXTを使用して評価コンテキストを作成する場合は、evaluation_functionパラメータに対してSYS.DBMS_STREAMS_INTERNAL.EVALUATION_CONTEXT_FUNCTIONを指定する必要があります。DBMS_RULE_ADM.ALTER_EVALUATION_CONTEXTプロシージャを使用すると、既存の評価コンテキストを変更できます。

評価コンテキストに関する情報は、次のデータ・ディクショナリ・ビューで参照できます。

- ALL_EVALUATION_CONTEXT_TABLES

- ALL_EVALUATION_CONTEXT_VARS

- ALL_EVALUATION_CONTEXTS

必要に応じて、これらのデータ・ディクショナリ・ビューの情報を使用し、SYS.STREAMS$_EVALUATION_CONTEXTに基づいて新しい評価コンテキストを作成できます。

注意:
Oracleが提供する評価コンテキストの変数との競合を回避するために、$や#などの特殊文字を含む変数名は使用しないでください。

関連項目:
これらのデータ・ディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照

12 取得と適用の複合による最適化

次の各項では、取得と適用の複合による最適化について説明します。

- 取得と適用の複合の要件

- 取得と適用の複合の使用方法

- 取得と適用の複合が使用されているかどうかの判断方法

- 取得と適用の複合およびPoint-in-Timeリカバリ

取得と適用の複合による最適化について

効率を向上させるために、取得プロセスでは、特定の条件下で伝播受信者に論理変更レコード(LCR)を直接送信する伝播送信者を作成できます。LCRは、伝播受信者によって宛先キューのバッファ・キューにエンキューされた後、適用プロセスによってデキューされます。このような最適化は、取得と適用の複合と呼ばれます。

取得と適用の複合の要件

取得と適用の複合は、取得プロセスおよび適用プロセスが同じデータベース・インスタンスまたは異なるデータベースで実行される場合に使用できます。

取得プロセスと適用プロセスが同じデータベース・インスタンスで実行されるときは、次の条件がすべて満たされている場合にのみ、取得と適用の複合を使用できます。

- 取得プロセスと適用プロセスで同じキューを使用する必要があります。

- キューに単一のパブリッシャがあり、それが取得プロセスである必要があります。

取得プロセスと適用プロセスが異なるデータベースまたは同じデータベースの異なるインスタンスで実行されるときは、次の条件がすべて満たされている場合にのみ、取得と適用の複合を使用できます。

- 取得プロセス・キューに単一のパブリッシャがあり、それが取得プロセスである必要があります。

- 取得プロセス・キューと適用プロセス・キューの間で伝播が構成されている必要があります。中間キューは必要ありません(有向ネットワークなし)。

- 同じソース・データベースからの変更を適用する各適用プロセスは、それぞれ異なるキューを使用する必要があります。

注意:

- 同期取得では、取得と適用の複合を使用できません。

- Oracle Database 10g以下のデータベースが構成に含まれる場合、取得と適用の複合は使用できません。

- 取得と適用の複合の要件は、Oracle Database 11g リリース2(11.2)とOracle Database 11g リリース1(11.1)とで異なります。取得と適用の複合による最適化でのデータベースが11.1データベースの場合は、11.1の要件が満たされている必要があります。これらの要件の詳細は、11.1リリース用の『Oracle Streams概要および管理』を参照してください。

関連項目:

- 「Oracle Streams取得プロセスによる暗黙的取得」

- 「永続キューおよびバッファ・キュー」

- 「有向ネットワーク」

- 「適用プロセスによる暗黙的コンシューム」

取得と適用の複合の使用方法

取得と適用の複合の要件を満たした後は、取得と適用の複合を使用するために他の構成タスクを実行する必要はありません。取得プロセスが開始されると、取得と適用の複合が使用可能であることが自動的に検出されます。伝播受信者との接続を確立する伝播送信者が作成された後、伝播送信者から伝播受信者に取得LCRが直接送信されます。

取得と適用の複合が使用されていて、構成を変更したために構成が取得と適用の複合の要件を満たさなくなった場合は、取得プロセスによってこの変更が検出され、取得プロセスが再起動します。取得プロセスの再起動後、取得と適用の複合は使用されません。

取得と適用の複合が使用されておらず、構成を変更したために構成が取得と適用の複合の要件を満たすようになった場合は、取得プロセスが再起動したときに、取得と適用の複合が自動的に使用されます。この場合、取得プロセスを手動で再起動する必要があります。自動的には再起動されません。

関連項目:
「取得と適用の複合の要件」

取得と適用の複合が使用されているかどうかの判断方法

取得と適用の複合が使用されているかどうかを判断するには、次の動的パフォーマンス・ビューを確認します。

- 取得プロセスの場合は、V$STREAMS_CAPTUREビューでOPTIMIZATION列が0より大きい場合に取得と適用の複合が使用されます。

- 適用プロセスの場合は、V$STREAMS_APPLY_READERビューでPROXY_SID列がNULLでない場合に取得と適用の複合が使用されます。

関連項目:

- 「取得と適用の複合を使用する取得プロセスの判別」

- 「取得と適用の複合を使用する適用プロセスの判別」

- 「取得プロセスの状態」

- データ・ディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照

取得と適用の複合およびPoint-in-Timeリカバリ

単一ソース・レプリケーション環境で取得と適用の複合を使用すると、Oracle Streamsクライアントによって宛先データベースのPoint-in-Timeリカバリが自動的に処理されます。Oracle Streamsクライアントには、取得と適用の複合による最適化を構成する取得プロセス、伝播および適用プロセスが含まれます。

取得と適用の複合を使用する単一ソース・レプリケーション環境では、次の一般的な手順を使用して、宛先データベースでPoint-in-Timeリカバリを実行します。

1. 取得プロセスと適用プロセスを停止し、伝播を無効にします。

2. 宛先データベースでPoint-in-Timeリカバリを実行します。

3. 取得プロセスが、以前の時点のアーカイブREDOログ・ファイルにアクセスできることを確認します。

4. 適用プロセスを起動します。

5. 伝播を有効にします。

6. 取得プロセスを起動します。

これらの手順を実行すると、取得プロセスによってその開始SCNが自動的に決定されるため、その他の手順は必要ありません。

関連項目:
Oracle Streamsレプリケーション環境におけるPoint-in-Timeリカバリの実行の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

13 Oracle Streams高可用性環境

この章では、Oracle Streams高可用性環境について説明します。

- Oracle Streams高可用性環境の概要

- 障害からの保護

- Oracle Streams高可用性環境のベスト・プラクティス

Oracle Streams高可用性環境の概要

高可用性ソリューションの構成には、念入りな計画と障害発生時の使用例の分析が必要です。データベース・バックアップとフィジカル・スタンバイ・データベースでは、フェイルオーバー保護用にソース・データベースの物理コピーが提供されます。Oracle Data Guardには、SQL Applyモードの場合、高可用性環境にロジカル・スタンバイ・データベースが実装されます。Oracle Data Guardは高可用性環境用に設計されているため、ほとんどの障害発生例に対応します。ただし、一部の環境で、Oracle Streamsによって実現された柔軟性が必要になる場合には、Oracle Streamsによって提供される拡張機能セットが使用可能です。

この章では、Oracle Streamsベースのソリューションが適している使用例と、高可用性環境で発生するOracle Streams固有の問題を説明します。

関連項目:

- Oracle Data Guardの詳細は、『Oracle Data Guard概要および管理』を参照

- 『Oracle Real Application Clusters管理およびデプロイメント・ガイド』

障害からの保護

インスタンスまたはシステム障害から保護するには、Oracle Real Application Clusters(Oracle RAC)が適しています。障害が発生すると、クラスタ内にある障害の発生していない方のノードによってサービスが提供されます。ただし、クラスタ化では、ユーザー・エラー、メディア障害および障害からは保護されません。このような障害には、データベースの重複コピーが必要です。データベースの物理コピーと論理コピーの両方を作成できます。

物理コピーはブロック単位でソース・データベースと同一になるように行われるもので、データ保護に適した方法です。物理コピーにはデータベース・バックアップ、ミラー化または多重データベース・ファイル、フィジカル・スタンバイ・データベースの3タイプがあります。

論理コピーにはソース・データベースと同じ情報が含まれますが、情報はデータベース内に異なる形式で格納できます。データベースの論理コピーを作成することには、多くのメリットがあります。ただし、論理コピーの作成は、常に物理コピーも作成したうえで行う必要があります。物理コピーの代替として作成しないでください。

論理コピーには、次のメリットがあります。

- 更新中に論理コピーを開くことができます。このため、論理コピーはほぼリアルタイムのレポートに役立ちます。

- 論理コピーに様々な物理レイアウトを指定し、目的に応じて最適化できます。たとえば、追加の索引を含めることができ、その結果として論理コピーを使用したレポート・アプリケーションのパフォーマンスが改善されます。

- 論理コピーによって、破損からの保護が強化されます。データは論理的に取得および適用されるため、物理的な破損がデータベースの論理コピーに伝播することはほとんど考えられません。

データベースの論理コピーには3タイプあります。

- ロジカル・スタンバイ・データベース

- Oracle Streamsレプリカ・データベース

- アプリケーションによるコピーのメンテナンス

ロジカル・スタンバイ・データベースは、SQL ApplyモードのOracle Data Guardを使用した場合に最適な状態でメンテナンスされます。この章の後半では、Oracle Streamsレプリカ・データベースとアプリケーションによるコピーのメンテナンスを説明します。

関連項目:

- 「Oracle StreamsおよびOracle Real Application Clusters」

- データベース・バックアップと、データベース・ファイルのミラー化または多重化の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照

- フィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースの詳細は、『Oracle Data Guard概要および管理』を参照

Oracle Streamsレプリカ・データベース

SQL ApplyモードのOracle Data Guardと同様に、Oracle Streamsを使用して、データベース変更を取得して宛先に伝播し、変更をこれらの宛先に適用できます。Oracle Streamsは、データのレプリケートのために最適化されます。Oracle Streamsでは、ソース・データベースの変更が取得され、取得された変更がレプリカ・データベースへ非同期に伝播できます。この最適化によって待機時間を短縮し、レプリカのプライマリ・データベースからの遅れを数秒以内に抑えることができます。

それでもなお、本番データベースの論理コピーの構成およびメンテナンスにOracle Streamsの使用を選択する場合があります。Oracle Streamsを使用すると追加の作業が必要になりますが、固有のビジネス要件を満たすために必要な優れた柔軟性が提供されます。Oracle Streamsを使用して構成およびメンテナンスされる論理コピーでは、通常定義のスタンバイ・データベースの範囲を超える多くの機能が提供されるため、ロジカル・スタンバイではなくレプリカと呼ばれます。Oracle Streamsレプリカの使用が適した要件の一部を次の項に示します。

関連項目:
Oracle Streamsを使用してデータベース変更をレプリケートする方法の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

レプリカ・データベースの更新

レプリカ・データベースとスタンバイ・データベースの最大の違いは、レプリカ・データベースが更新可能であるのに対し、スタンバイ・データベースは更新不可である点です。ジョブや、レポート・アクティビティをログに記録するレポート・アプリケーションなど、データの更新が必要なアプリケーションをレプリカに対して実行できます。また、レプリカ・データベースでは、ローカル・アプリケーションをWANの障害から保護し、データベース操作の待機時間を減少させながら、自律的に実行できます。

異機種間プラットフォームのサポート

本番データベースとレプリカ・データベースは、同じプラットフォーム上で稼働している必要はありません。そのため、コンピュータ資産の使用が柔軟になり、プラットフォーム間の移行が容易になります。

複数キャラクタ・セット

Oracle Streamsレプリカでは、本番データベースとは異なるキャラクタ・セットを使用できます。データは、適用される前に、1つのキャラクタ・セットから別のキャラクタ・セットに自動的に変換されます。グローバル操作を使用していて、データを複数の国に配布する必要がある場合に、この機能はきわめて重要です。

オンラインREDOログのマイニングによる待機時間の最小化

レプリカをほぼリアルタイムのレポートに使用すると、Oracle Streamsの本番データベースからの遅れが数秒以内に抑えられ、最新で正確な問合せが提供できます。変更は、アーカイブ後のREDOログからではなく、記録中のオンラインREDOログから読取り可能です。

高速フェイルオーバー

Oracle Streamsレプリカは、常に読取り/書込み操作用にオープンできます。プライマリ・データベースに障害が発生した場合、Oracle Streamsレプリカですぐに処理を再開できます。少量のデータがプライマリ・データベースに残る場合がありますが、このデータはプライマリ・データベースがリカバリされると自動的に適用されます。データの消失を防ぐよりもリカバリ時間の短縮を重視する場合、この機能が重要になることがあります。最終的にプライマリ・データベースをリカバリできるとすると、データが使用不可能になるのは一時的なものにすぎません。

複数宛先への単一の取得

複合環境では、変更の取得は1回のみ必要です。これらの変更は複数の宛先に送信できます。取得プロセスを使用して変更を取得する場合、この機能によって、REDOログで変更をマイニングするために必要なリソースをさらに効率的に使用できます。

Oracle Streamsを使用しない場合

前述のように、一部の高可用性の要件を満たすためにOracle Streamsの使用を選択する使用例があります。高可用性のルールの1つは、単純さの保持です。Oracle Data Guardは高可用性のために設計されており、Oracle Streamsベースの高可用性ソリューションよりも実装が容易です。Oracle Streamsによって提供される柔軟性を利用する場合は、Oracle Streamsベースのソリューションを強固にするために必要な専門技術と計画に投資する準備が必要です。Oracle Data Guardで提供される自動化ツールおよび管理ツールのほとんどを、スクリプトを作成して実装する必要がある場合があります。

アプリケーションによるコピーのメンテナンス

データの論理コピーのメンテナンスをアプリケーションで直接実行するように設計すると、可用性を最大限にできます。重要なデータやデータ消失を防ぐためオフサイトに即時移動する必要のあるデータは、アプリケーションで認識されています。また、重要なデータは同期式にレプリケートでき、それほど重要でないデータは非同期式にレプリケートできます。アプリケーションでは、別のデータの論理コピーを管理する他のアプリケーションにデータを同期式または非同期式に送信することによって、データのコピーがメンテナンスされます。同期操作は、分散SQLまたはデータベースのリモート・プロシージャ機能を使用して実行されます。非同期操作は、アドバンスト・キューイングを使用して実行されます。アドバンスト・キューイングは、Oracle Streamsに備えられているデータベース・メッセージ・キューイング機能です。

アプリケーションによるデータ・コピーのメンテナンスでは、最高レベルの可用性が実現可能ですが、最大限の注意が必要です。通常、多くのカスタム開発が必要になります。Oracle Data GuardやOracle Streamsレプリケーションなどのソリューションによって分析および解決されてきた難しい境界条件の多くを、カスタム・アプリケーションの開発者が再分析し解決する必要があります。また、Oracle Data GuardやOracle Streamsレプリケーションのような標準ソリューションは、オラクル社と顧客の両方による厳密なテストを通過しています。カスタム開発のソリューションが同じ程度の完成度を示すまでには、大変な労力が必要です。これらの理由から、アプリケーションによるコピーのメンテナンス機能を持つ高可用性ソリューションの構築は、時間と専門技術が十分にある組織のみが行うようにします。

関連項目:
アドバンスト・キューイングを使用したアプリケーション開発の詳細は、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドを参照

Oracle Streams高可用性環境のベスト・プラクティス

高可用性環境にOracle Streamsを実装するには、発生する可能性のある障害とリカバリでの使用例を考慮し、障害発生後にもOracle Streamsで引き続き変更を取得、伝播および適用できるプロシージャを実装する必要があります。次の項目を確認します。

- 高可用性のためのOracle Streamsの構成

- 障害からのリカバリ

高可用性のためのOracle Streamsの構成

Oracle Streamsを使用したソリューションを構成する場合、障害を予想し、アーキテクチャ内に可用性を組み込んで設計することが重要です。分散システム内の各データベースを調べ、そのデータベースに障害が発生した場合のリカバリ・プランを設計する必要があります。データベース障害の影響する対象が、そのデータベースのデータにアクセスするサービスのみの場合もあれば、他のデータベースにも影響して、障害が拡大する場合もあります。

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

- データベースとその他の各データベースとの直接接続

- ハブ・アンド・スポーク構成の作成

- Oracle Streamsの取得プロセスを使用したローカル取得またはダウンストリーム取得

データベースとその他の各データベースとの直接接続

分散システム内の各データベースがその他すべてのデータベースと個々に直接接続した構成では、1つのデータベースに障害が発生しても他のデータベースでの操作または通信を妨げないため、障害に対して最も耐性があります。すべてのデータがレプリケートされていれば、障害の発生したデータベースを使用していたサービスは、障害の発生していないレプリカに接続できます。

関連項目:

- このような環境の詳細な例については、『Oracle Streams拡張例』を参照

- 「キューによる転送と適用による転送 」

ハブ・アンド・スポーク構成の作成

各データベースがその他すべてのデータベースと個々に直接接続された構成では、最高の高可用性特性が提供されますが、データベースの数が増加すると管理が困難になります。この管理上の問題は、ハブ・アンド・スポーク構成で、多くのデータベースからの変更をハブ・データベースを介してから他のハブ・データベースまたは他のスポーク・データベースに伝播することによって解決されます。新規ソースまたは宛先の追加は、データベースごとに接続を確立するのではなく、ハブ・データベースへの接続を行うのみです。

ただし、ハブは分散環境において非常に重要なノードになります。それに障害が発生すると、ハブを介して行われるすべての通信に障害が発生します。ハブを介して伝播するメッセージは非同期な性質を持つため、あるハブから別のハブにストリームをリダイレクトすることは非常に困難です。適切なアプローチとは、ハブを障害に対して耐性がある状態にすることです。

単一データベースを障害に対して耐性がある状態にするために使用した手法は、分散ハブ・データベースにも適用されます。インスタンスおよびノードの障害からの保護には、Oracle Real Application Clusters(Oracle RAC)を使用することをお薦めします。障害とデータ・エラーから保護するためには、この構成を損失のないフィジカル・スタンバイ・データベースと結合する必要があります。障害とデータ・エラーからの保護方法としてOracle Streamsレプリカのみを使用することは、お薦めしません。

関連項目:

- ハブ・アンド・スポーク・レプリケーション環境とその構成方法の詳細は、Oracle Database 2日でデータ・レプリケーションおよび統合ガイドを参照

- このような環境の詳細な例は、Oracle Streamsレプリケーション管理者ガイドを参照

- 「Oracle StreamsおよびOracle Real Application Clusters」

Oracle Streamsの取得プロセスを使用したローカル取得またはダウンストリーム取得

Oracle Streamsの取得プロセスを使用して、ローカル・ソース・データベース、または異なるサイトのダウンストリーム・データベースに存在するREDOログ内の変更を取得できます。ローカル取得またはダウンストリーム取得の選択は、可用性に影響を及ぼします。ソース・データベースに障害が発生した場合、一部の変更は取得されていない場合があります。ローカル取得の場合、それらの変更はソース・データベースがリカバリされるまで取得できない場合があります。突発的な障害が発生した場合、変更が失われる場合があります。

リモート・データベースでダウンストリーム取得を実行すると、障害発生時のデータ消失の可能性が減少します。構成によっては、ダウンストリーム取得を使用して、ソース・データベースでコミットされたすべての変更が安全にリモート・サイトにコピーされることを保証できます。リモート・サイトでは、それらの変更を他のデータベースやアプリケーションに取得および伝播できます。Oracle Streamsは、Oracle Data Guardと同じメカニズムを使用してリモートの宛先にREDOデータまたはログ・ファイルをコピーし、最大限の保護、最大の可用性、最大限のパフォーマンスなどの、同じ操作モードをサポートします。

注意:
同期取得は常に、ソース・データベースで構成されます。

関連項目:
「ローカル取得およびダウンストリーム取得」

障害からのリカバリ

ここでは、障害からのリカバリのベスト・プラクティスを説明します。

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

- フェイルオーバー後の取得プロセスの自動的な再起動

- フェイルオーバー後のデータベース・リンクの再確立

- フェイルオーバー後の伝播ジョブの再起動

- フェイルオーバー後の適用プロセスの自動的な再起動

フェイルオーバー後の取得プロセスの自動的な再起動

障害発生後に単一ノードのデータベースが再起動されるか、または障害発生後にコールド・フェイルオーバー・クラスタ内の別のノード上にあるデータベースが再起動されると、取得プロセスは障害発生時の状態に自動的に戻ります。つまり、障害発生時に取得プロセスが実行中であった場合は、自動的に再起動されます。

関連項目:

- 「取得プロセスおよびOracle Real Application Clusters」

- 「取得プロセスの起動」

- キューのプライマリ・インスタンスおよびセカンダリ・インスタンスの所有権の詳細は、「キューとOracle Real Application Clusters」を参照

フェイルオーバー後のデータベース・リンクの再確立

宛先データベースのインスタンスで障害が発生した後も、伝播が引き続き機能することは重要です。障害発生後、伝播ジョブでは接続が再確立されるまでデータベース・リンクが16回再試行されます(再試行と次の再試行との間隔は徐々に長くなります)。16回目の再試行後も接続が再確立されない場合、伝播スケジュールは中断されます。

データベースが同じノード、またはコールド・フェイルオーバー・クラスタ内の別のノードで再起動された場合、接続の再確立が必要になります。状況によってはデータベース・リンクが読取りまたは書込みを待機している場合があり、冗長なタイムアウトが期限切れになるまで、障害は検出されません。タイムアウトは、TCP_KEEPALIVE_INTERVAL TCP/IPパラメータによって制御されます。このような場合は、データベース・リンクを一度削除してから再作成し、通信が迅速に再確立されるようにする必要があります。

高可用性環境では、必要なデータベース・リンクすべてを削除および再作成するスクリプトを準備することが考えられます。フェイルオーバー後、これらのスクリプトを実行し、Oracle Streamsで伝播を再開できます。

関連項目:

- Oracle Streams環境におけるデータベース・リンクの作成の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- Oracle RAC環境のデータベース・リンクの詳細は、「伝播およびOracle Real Application Clusters」を参照

フェイルオーバー後の伝播ジョブの再起動

メッセージをソース・キューから宛先キューに伝播させるには、ソース・キューを所有しているインスタンス上で伝播ジョブを実行する必要があります。単一ノードのデータベースまたはコールド・フェイルオーバー・クラスタでは、単一データベース・インスタンスが再起動されると伝播が再開されます。

関連項目:
「伝播およびOracle Real Application Clusters」

フェイルオーバー後の適用プロセスの自動的な再起動

障害発生後に単一ノードのデータベースが再起動されるか、または障害発生後にコールド・フェイルオーバー・クラスタ内の別のノード上にあるデータベースが再起動されると、適用プロセスは障害発生時の状態に自動的に戻ります。つまり、障害発生時に適用プロセスが実行中であった場合は、自動的に再起動されます。

関連項目:

- 「適用プロセスおよびOracle Real Application Clusters」

- 「適用プロセスの起動」

- キューのプライマリ・インスタンスおよびセカンダリ・インスタンスの所有権の詳細は、「キューとOracle Real Application Clusters」を参照

第III部

Oracle Streamsの管理

この部では、構成、管理、監視およびトラブルシューティングの手順を含む、Oracle Streams環境の管理について説明します。この部の構成は、次のとおりです。

- 第14章「Oracle Streamsの管理の概要」

- 第15章「Oracle Streams暗黙的取得の管理」

- 第16章「ステージングと伝播の管理」

- 第17章「Oracle Streams情報コンシュームの管理」

- 第18章「ルールの管理」

- 第19章「ルールベースの変換の管理」

- 第20章「Oracle Streamsを使用した表の変更の記録」

- 第21章「その他のOracle Streams管理タスク」

14 Oracle Streamsの管理の概要

Oracle Streams環境を構成、管理および監視するには、複数のツールを使用できます。Oracle提供のPL/SQLパッケージは主要な構成および管理ツールですが、Oracle Enterprise ManagerのOracle Streamsツールにも環境を管理できるように構成、管理および監視機能が用意されています。また、Oracle Streamsデータ・ディクショナリ・ビューには、Oracle Streams環境に関する情報が常に表示されます。

次の各項では、Oracle Streamsの管理に使用できるツールについて説明します。

- Oracle提供のPL/SQLパッケージ

- Oracle Streamsのデータ・ディクショナリ・ビュー

- Oracle Enterprise ManagerのOracle Streamsツール

Oracle提供のPL/SQLパッケージ

次のOracle提供のPL/SQLパッケージには、Oracle Streams環境を構成して管理するためのプロシージャおよびファンクションが含まれています。

- DBMS_APPLY_ADMパッケージ

- DBMS_CAPTURE_ADMパッケージ

- DBMS_COMPARISONパッケージ

- DBMS_PROPAGATION_ADMパッケージ

- DBMS_RULEパッケージ

- DBMS_RULE_ADMパッケージ

- DBMS_STREAMSパッケージ

- DBMS_STREAMS_ADMパッケージ

- DBMS_STREAMS_ADVISOR_ADMパッケージ

- DBMS_STREAMS_AUTHパッケージ

- DBMS_STREAMS_HANDLER_ADMパッケージ

- DBMS_STREAMS_MESSAGINGパッケージ

- DBMS_STREAMS_TABLESPACE_ADMパッケージ

- UTL_SPADVパッケージ

DBMS_APPLY_ADMパッケージ

DBMS_APPLY_ADMパッケージには、適用プロセスを起動、停止および構成するための管理インタフェースが用意されています。このパッケージには、適用ハンドラを構成し、メッセージのエンキューの宛先を設定し、メッセージの実行ディレクティブを指定するためのプロシージャが含まれています。また、このパッケージには、宛先データベースでオブジェクトのインスタンス化SCNを設定するための管理プロシージャも用意されています。さらに、競合検出と競合解決を構成するためのサブプログラム、および適用エラーを管理するためのサブプログラムも含まれています。

DBMS_CAPTURE_ADMパッケージ

DBMS_CAPTURE_ADMパッケージには、取得プロセスを起動、停止および構成するための管理インタフェースが用意されています。また、同期取得を構成するための管理インタフェースも用意されています。このパッケージには、宛先データベースでインスタンス化するために、ソース・データベースでデータベース・オブジェクトを準備するための管理プロシージャもあります。

DBMS_COMPARISONパッケージ

DBMS_COMPARISONパッケージには、異なるデータベースでデータベース・オブジェクトを比較してまとめるためのインタフェースが用意されています。

DBMS_PROPAGATION_ADMパッケージ

DBMS_PROPAGATION_ADMパッケージには、ソース・キューから宛先キューへの伝播を構成するための管理インタフェースが用意されています。

DBMS_RULEパッケージ

DBMS_RULEパッケージには、ルール・セットを評価するEVALUATEプロシージャが含まれています。このプロシージャの目的は、データに基づいて条件を満たすルールのリストを作成することです。このパッケージには、ルール評価中にイテレータを使用するためのサブプログラムも含まれています。イテレータは、評価に対してTRUEまたはMAYBEと評価されるすべてのルールを返すのではなく、1つのルールを1つずつ返すことができます。

DBMS_RULE_ADMパッケージ

DBMS_RULE_ADMパッケージには、ルール、ルール・セットおよびルール評価コンテキストを作成および管理するための管理インタフェースが用意されています。さらに、ルールに関連する権限を管理するためのサブプログラムも含まれています。

DBMS_STREAMSパッケージ

DBMS_STREAMSパッケージには、ANYDATAオブジェクトをLCRオブジェクトに変換し、Oracle Streams属性およびOracle Streamsクライアントに関する情報を返し、さらにセッションで生成されたREDOエントリにタグを付けるためのインタフェースが用意されています。このタグは、ルールにREDOエントリまたはLCRのタグの仕様が含まれている取得プロセス、伝播、適用プロセスまたはメッセージ・クライアントの動作に影響する場合があります。

DBMS_STREAMS_ADMパッケージ

DBMS_STREAMS_ADMパッケージには、表、スキーマおよびデータベースの各レベルでの取得プロセス、伝播および適用プロセスに関する単純ルールを追加および削除するための管理インタフェースが用意されています。このパッケージを使用すると、伝播によって伝播されるメッセージ、およびメッセージ・クライアントによってデキューされるメッセージを制御するルールを追加することもできます。また、このパッケージには、キューを作成し、データ・ディクショナリ情報など、Oracle Streamsのメタデータを管理するためのプロシージャも含まれています。このパッケージには、Oracle Streams レプリケーション環境を構成および管理するためのプロシージャも含まれています。このパッケージは、Oracle Streams環境で共通のタスクを完了するための簡便な方法として提供されます。DBMS_CAPTURE_ADM、DBMS_PROPAGATION_ADM、DBMS_APPLY_ADM、DBMS_RULE_ADMおよびDBMS_AQADMなど、他のパッケージを使用すると、これと同じタスクのみでなく、追加のカスタマイズを必要とするタスクを完了できます。

DBMS_STREAMS_ADVISOR_ADMパッケージ

DBMS_STREAMS_ADVISOR_ADMパッケージには、Oracle Streams環境に関する情報を収集し、それらの情報に基づいてデータベース管理者にアドバイスするためのインタフェースが用意されています。このパッケージは、Oracle Streamsパフォーマンス・アドバイザに含まれています。

DBMS_STREAMS_AUTHパッケージ

DBMS_STREAMS_AUTHパッケージには、Oracle Streams管理者の権限を付与および取消しを行うためのインタフェースが用意されています。

DBMS_STREAMS_HANDLER_ADMパッケージ

DBMS_STREAMS_HANDLER_ADMパッケージには、文DMLハンドラを管理するためのインタフェースが用意されています。

DBMS_STREAMS_MESSAGINGパッケージ

DBMS_STREAMS_MESSAGINGパッケージには、ANYDATAキューにメッセージをエンキューしたり、そこからメッセージをデキューするためのインタフェースが用意されています。

DBMS_STREAMS_TABLESPACE_ADMパッケージ

DBMS_STREAMS_TABLESPACE_ADMパッケージには、表領域リポジトリを作成および管理するための管理プロシージャが用意されています。また、このパッケージには、データベース間で表領域をコピーするための管理プロシージャ、およびあるデータベースから別のデータベースに表領域を移動するための管理プロシージャも用意されています。このパッケージでは、トランスポータブル表領域、データ・ポンプおよびDBMS_FILE_TRANSFERパッケージが使用されます。

UTL_SPADVパッケージ

UTL_SPADVパッケージには、分散データベース環境におけるOracle Streamsコンポーネントの統計を収集および分析するためのサブプログラムが用意されています。このパッケージでは、Oracle Streamsパフォーマンス・アドバイザを使用して統計を収集します。

関連項目:
これらのパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

Oracle Streamsのデータ・ディクショナリ・ビュー

Oracle Streams環境内の各データベースには、Oracle Streamsのデータ・ディクショナリ・ビューがあります。これらのビューでは、ローカルのルール、オブジェクト、取得プロセス、伝播、適用プロセスおよびメッセージ・クライアントに関する管理情報が保持されます。これらのビューを使用してOracle Streams環境を監視できます。

関連項目:

- 第22章「Oracle Streams環境の監視」

- これらのデータ・ディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照

Oracle Enterprise ManagerのOracle Streamsツール

Oracle Streams環境の構成、管理および監視を容易にするために、OracleではOracle Enterprise ManagerにOracle Streamsツールを用意しています。Oracle Streamsツールを使用すると、Oracle Streams構成スクリプトを生成し、それを変更して実行し、Oracle Streams環境を構成できます。Oracle Streamsツールの主な資料は、オンライン・ヘルプです。

データベースのレプリケーション・コンポーネントの概要を表示するには:

1. Oracle Enterprise Managerで、Oracle Streams管理者としてハブ・データベースにログインします。

2. データベース・ホームページに移動します。

3. 「高可用性」で、「Streamsコンポーネント」にある数値リンクをクリックします。
レプリケーションの管理ページが表示され、概要サブページが表示されます。

図14-1に、Enterprise Managerのレプリケーションの管理ページを示します。

図14-1 Enterprise Managerのレプリケーションの管理ページ

関連項目:

- Oracle Database 2日でデータ・レプリケーションおよび統合ガイド

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

15 Oracle Streams暗黙的取得の管理

取得プロセスと同期取得は両方とも暗黙的取得を実行します。この章では、暗黙的取得の管理の手順を説明します。

次の各項では、Oracle Streams暗黙的取得の管理について説明します。

- 取得プロセスの管理

- 同期取得の管理

- 取得LCRの追加属性の管理

- 取得プロセスから同期取得への切替え

- 同期取得から取得プロセスへの切替え

この章で説明する各タスクは、特に明記されていないかぎり、適切な権限を付与されているOracle Streams管理者が完了する必要があります。

関連項目:

- 第2章「Oracle Streams情報取得」

- Oracle Streams管理者を作成する方法の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- 「Oracle Streams暗黙的取得の監視」

- 第31章「暗黙的取得のトラブルシューティング」

取得プロセスの管理

取得プロセスは、REDOログの変更を取得して、取得した各変更を論理変更レコード(LCR)形式にフォーマットし、LCRをANYDATAキューにエンキューします。

次の各項では、取得プロセスの管理について説明します。

- 取得プロセスの起動

- 取得プロセスの停止

- 取得プロセスのルール・セットの管理

- 取得プロセス・パラメータの設定

- 取得プロセスの取得ユーザーの設定

- 取得プロセスのチェックポイント保存時間の管理

- 取得プロセスへのアーカイブREDOログ・ファイルの明示的な追加

- 既存の取得プロセスの先頭SCNの設定

- 既存の取得プロセスの開始SCNの設定

- ダウンストリーム取得でデータベース・リンクを使用するかどうかの指定

- 取得プロセスの削除

関連項目:

- 「Oracle Streams取得プロセスによる暗黙的取得」

- 取得プロセスの構成の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- Enterprise Managerでの取得プロセスの管理の詳細は、Oracle Database 2日でデータ・レプリケーションおよび統合ガイドおよびEnterprise Managerのオンライン・ヘルプを参照

取得プロセスの起動

既存の取得プロセスを起動するには、DBMS_CAPTURE_ADMパッケージのSTART_CAPTUREプロシージャを実行します。たとえば、次のプロシージャでは取得プロセスstrm01_captureが起動されます。

BEGIN
DBMS_CAPTURE_ADM.START_CAPTURE(
capture_name => 'strm01_capture');
END;
/

注意:
新しい取得プロセスで新しいLogMinerデータ・ディクショナリが使用される場合は、新しい取得プロセスを初めて起動するときに、新しいLogMinerデータ・ディクショナリの移入に時間がかかる場合があります。新しいLogMinerデータ・ディクショナリは、取得プロセスの作成時にNULL以外の先頭SCN値を指定した場合に作成されます。

関連項目:
Oracle Enterprise Managerを使用した取得プロセスの起動については、Oracle Database 2日でデータ・レプリケーションおよび統合ガイドを参照

取得プロセスの停止

既存の取得プロセスを停止するには、DBMS_CAPTURE_ADMパッケージのSTOP_CAPTUREプロシージャを実行します。たとえば、次のプロシージャでは取得プロセスstrm01_captureが停止されます。

BEGIN
DBMS_CAPTURE_ADM.STOP_CAPTURE(
capture_name => 'strm01_capture');
END;
/

関連項目:
Oracle Enterprise Managerを使用した取得プロセスの停止方法については、Oracle Database 2日でデータ・レプリケーションおよび統合ガイドを参照

取得プロセスのルール・セットの管理

この項では、次のタスクの実行手順を説明します。

- 取得プロセスのルール・セットの指定

- 取得プロセスのルール・セットへのルールの追加

- 取得プロセスのルール・セットからのルールの削除

- 取得プロセスのルール・セットの削除

関連項目:

- 第5章「Oracle Streamsでのルールの使用方法」

- 第11章「ルールの高度な概念」

取得プロセスのルール・セットの指定

取得プロセスには、1つのポジティブ・ルール・セットおよび1つのネガティブ・ルール・セットを指定できます。ポジティブ・ルール・セットの1つ以上のルールがTRUEと評価され、ネガティブ・ルール・セットのすべてのルールがFALSEと評価された場合、取得プロセスによって変更が取得されます。ネガティブ・ルール・セットは、ポジティブ・ルール・セットの前に評価されます。

取得プロセスのポジティブ・ルール・セットの指定

既存のルール・セットをポジティブ・ルール・セットとして既存の取得プロセスに指定するには、ALTER_CAPTUREプロシージャのrule_set_nameパラメータを使用します。このプロシージャは、DBMS_CAPTURE_ADMパッケージに含まれています。

たとえば、次のプロシージャでは、取得プロセスstrm01_captureのポジティブ・ルール・セットがstrm02_rule_setに設定されます。

BEGIN
DBMS_CAPTURE_ADM.ALTER_CAPTURE(
capture_name  => 'strm01_capture',
rule_set_name => 'strmadmin.strm02_rule_set');
END;
/

取得プロセスのネガティブ・ルール・セットの指定

既存のルール・セットをネガティブ・ルール・セットとして既存の取得プロセスに指定するには、ALTER_CAPTUREプロシージャのnegative_rule_set_nameパラメータを使用します。このプロシージャは、DBMS_CAPTURE_ADMパッケージに含まれています。

たとえば、次のプロシージャでは、取得プロセスstrm01_captureのネガティブ・ルール・セットがstrm03_rule_setに設定されます。

BEGIN
DBMS_CAPTURE_ADM.ALTER_CAPTURE(
capture_name           => 'strm01_capture',
negative_rule_set_name => 'strmadmin.strm03_rule_set');
END;
/

取得プロセスのルール・セットへのルールの追加

既存の取得プロセスのルール・セットにルールを追加するには、DBMS_STREAMS_ADMパッケージの次のいずれかのプロシージャを実行して既存の取得プロセスを指定します。

- ADD_TABLE_RULES

- ADD_SUBSET_RULES

- ADD_SCHEMA_RULES

- ADD_GLOBAL_RULES

ADD_SUBSET_RULESプロシージャ以外のこれらのプロシージャでは、取得プロセスのポジティブ・ルール・セットまたはネガティブ・ルール・セットにルールを追加できます。ADD_SUBSET_RULESプロシージャでは、取得プロセスのポジティブ・ルール・セットのみにルールを追加できます。

関連項目:
「システム作成ルール」

取得プロセスのポジティブ・ルール・セットへのルールの追加

次の例では、DBMS_STREAMS_ADMパッケージのADD_TABLE_RULESプロシージャを実行して、取得プロセスstrm01_captureのポジティブ・ルール・セットにルールを追加します。

BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
table_name      =>  'hr.departments',
streams_type    =>  'capture',
streams_name    =>  'strm01_capture',
queue_name      =>  'strmadmin.streams_queue',
include_dml     =>  TRUE,
include_ddl     =>  TRUE,
inclusion_rule  =>  TRUE);
END;
/

このプロシージャを実行すると、次のアクションが実行されます。

- 2つのルールが作成されます。一方のルールはhr.departments表に対するDML変更についてTRUEと評価され、他方のルールはhr.departments表に対するDDL変更についてTRUEと評価されます。ルール名は、システムによって生成されます。

- inclusion_ruleパラメータがTRUEに設定されているため、これらの2つのルールは、取得プロセスに関連付けられたポジティブ・ルール・セットに追加されます。

- DBMS_CAPTURE_ADMパッケージのPREPARE_TABLE_INSTANTIATIONプロシージャを実行することで、インスタンス化用にhr.departments表が準備されます。

- hr.departments表の主キー、一意キー、ビットマップ索引および外部キー列のサプリメンタル・ロギングが有効になります。PREPARE_TABLE_INSTANTIATIONプロシージャの実行時に、supplemental_loggingパラメータにデフォルト値(keys)が指定されます。

取得プロセスによってダウンストリーム取得が実行される場合、そのダウンストリーム取得プロセスでソース・データベースへのデータベース・リンクが使用される場合にのみ、表がインスタンス化のために準備され、キー列のサプリメンタル・ロギングが有効になります。ダウンストリーム取得プロセスでソース・データベースへのデータベース・リンクが使用されない場合、インスタンス化のために表を手動で準備し、手動でサプリメンタル・ロギングを有効にする必要があります。

取得プロセスのネガティブ・ルール・セットへのルールの追加

次の例では、DBMS_STREAMS_ADMパッケージのADD_TABLE_RULESプロシージャを実行して、取得プロセスstrm01_captureのネガティブ・ルール・セットにルールを追加します。

BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
table_name      =>  'hr.job_history',
streams_type    =>  'capture',
streams_name    =>  'strm01_capture',
queue_name      =>  'strmadmin.streams_queue',
include_dml     =>  TRUE,
include_ddl     =>  TRUE,
inclusion_rule  =>  FALSE);
END;
/

このプロシージャを実行すると、次のアクションが実行されます。

- 2つのルールが作成されます。一方のルールはhr.job_history表に対するDML変更についてTRUEと評価され、他方のルールはhr.job_history表に対するDDL変更についてTRUEと評価されます。ルール名は、システムによって生成されます。

- inclusion_ruleパラメータがFALSEに設定されているため、これらの2つのルールは、取得プロセスに関連付けられたネガティブ・ルール・セットに追加されます。

取得プロセスのルール・セットからのルールの削除

取得プロセスでルールに指定された変更を取得しない場合には、取得プロセスのルール・セットからルールを削除します。たとえば、ルールdepartments3でhr.departments表へのDML変更が取得されるように指定するとします。取得プロセスでhr.departments表への変更を取得しない場合は、ルール・セットからルールdepartments3を削除します。

DBMS_STREAMS_ADMパッケージのREMOVE_RULEプロシージャを実行して、既存の取得プロセスのルール・セットからルールを削除します。たとえば、次のプロシージャでは、取得プロセスstrm01_captureのポジティブ・ルール・セットからルールdepartments3が削除されます。

BEGIN
DBMS_STREAMS_ADM.REMOVE_RULE(
rule_name        => 'departments3',
streams_type     => 'capture',
streams_name     => 'strm01_capture',
drop_unused_rule => TRUE,
inclusion_rule   => TRUE);
END;
/

この例では、REMOVE_RULEプロシージャのdrop_unused_ruleパラメータがTRUEに設定されています。これはデフォルトの設定です。したがって、削除するルールが他のどのルール・セットにも含まれていなければ、そのルールはデータベースから削除されます。drop_unused_ruleパラメータがFALSEに設定されている場合、ルールはルール・セットから削除されますが、データベースからは削除されません。

inclusion_ruleパラメータがFALSEに設定されている場合、REMOVE_RULEプロシージャによって、取得プロセスのポジティブ・ルール・セットではなく、ネガティブ・ルール・セットからルールが削除されます。

取得プロセスのルール・セットからすべてのルールを削除するには、REMOVE_RULEプロシージャの実行時にrule_nameパラメータにNULLを指定します。

関連項目:
「Oracle Streamsクライアントに空のルール・セットが1つ以上存在する場合」

取得プロセスのルール・セットの削除

既存の取得プロセスからルール・セットを削除するには、DBMS_CAPTURE_ADMパッケージのALTER_CAPTUREプロシージャを使用します。このプロシージャでは、ポジティブ・ルール・セットまたはネガティブ・ルール・セット、あるいはその両方を削除できます。取得プロセスのポジティブ・ルール・セットを削除するには、remove_rule_setパラメータにTRUEを指定します。取得プロセスのネガティブ・ルール・セットを削除するには、remove_negative_rule_setパラメータにTRUEを指定します。

たとえば、次のプロシージャでは、取得プロセスstrm01_captureからポジティブ・ルール・セットとネガティブ・ルール・セットの両方が削除されます。

BEGIN
DBMS_CAPTURE_ADM.ALTER_CAPTURE(
capture_name             => 'strm01_capture',
remove_rule_set          => TRUE,
remove_negative_rule_set => TRUE);
END;
/

注意:
取得プロセスにポジティブ・ルール・セットまたはネガティブ・ルール・セットが存在しない場合、その取得プロセスでは、SYSスキーマ、SYSTEMスキーマおよびCTXSYSスキーマ内のデータベース・オブジェクトを除き、データベース内のすべてのオブジェクトに対するすべてのサポートされる変更が取得されます。

取得プロセスのパラメータの設定

取得プロセスのパラメータを設定するには、DBMS_CAPTURE_ADMパッケージのSET_PARAMETERプロシージャを使用します。取得プロセス・パラメータによって、取得プロセスの動作が制御されます。

たとえば、次のプロシージャでは、取得プロセスstrm01_captureのparallelismパラメータが4に設定されます。

BEGIN
DBMS_CAPTURE_ADM.SET_PARAMETER(
capture_name => 'strm01_capture',
parameter    => 'parallelism',
value        => '4');
END;
/

注意:

- parallelismパラメータを設定すると、取得プロセスが自動的に停止され、再起動されます。

- valueパラメータは、パラメータ値が数値の場合にも、常にVARCHAR2値として入力されます。

- valueパラメータがNULLに設定されているか、または指定されていない場合、パラメータはデフォルト値に設定されます。

関連項目:

- Oracle Enterprise Managerを使用した取得プロセス・パラメータの設定については、Oracle Database 2日でデータ・レプリケーションおよび統合ガイドを参照

- 「取得プロセスのサブコンポーネント」

- 取得プロセス・パラメータの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のDBMS_CAPTURE_ADM.SET_PARAMETERプロシージャに関する項を参照

取得プロセスの取得ユーザーの設定

取得ユーザーは、取得プロセスのルール・セットを満たすすべてのDML変更およびDDL変更を取得するユーザーです。取得プロセスの取得ユーザーを設定するには、DBMS_CAPTURE_ADMパッケージのALTER_CAPTUREプロシージャでcapture_userパラメータを使用します。

取得ユーザーを変更するには、ALTER_CAPTUREプロシージャを起動するユーザーにDBAロールが付与されている必要があります。SYSユーザーのみが、capture_userをSYSに設定できます。

たとえば、次のプロシージャでは、取得プロセスstrm01_captureの取得ユーザーがhrに設定されます。

BEGIN
DBMS_CAPTURE_ADM.ALTER_CAPTURE(
capture_name => 'strm01_capture',
capture_user => 'hr');
END;
/

このプロシージャを実行すると、新しい取得ユーザーに、取得プロセスで使用するキューのエンキュー権限が付与され、そのユーザーがキューの保護キュー・ユーザーとして構成されます。また、取得ユーザーが次の権限を持っていることを確認する必要があります。

- 取得プロセスで使用するルール・セットのEXECUTE権限

- ルール・セットで使用するすべてのカスタム・ルールベースの変換ファンクションのEXECUTE権限

これらの権限は、取得ユーザーに直接付与するか、ロールを介して付与できます。

また、取得ユーザーには、取得プロセスで実行されるルールベースの変換で起動されるすべてのパッケージ(Oracle提供パッケージを含む)に対するEXECUTE権限を付与する必要があります。これらの権限は、取得ユーザーに直接付与する必要があります。これらの権限は、ロールを介して付与することはできません。

注意:
Oracle Database Vaultがインストールされている場合は、「Oracle StreamsおよびOracle Data Vault」に記載されている手順に従って、適切な権限やロールが付与されていることを確認してください。

取得プロセスのチェックポイント保存時間の管理

チェックポイント保存時間は、チェックポイントが取得プロセスによって自動的にパージされるまでの保存期間です。

DBMS_CAPTURE_ADMパッケージのALTER_CAPTUREプロシージャのcheckpoint_retention_timeパラメータを使用して、取得プロセスのチェックポイント保存時間を設定します。

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

- 新しい値の取得プロセスのチェックポイント保存時間の設定

- 無期限の取得プロセスのチェックポイント保存時間の設定

関連項目:

- 「取得プロセスのチェックポイント」

新しい値の取得プロセスのチェックポイント保存時間の設定

チェックポイント保存時間を設定する場合、小数値を使用して日数と時間を指定できます。たとえば、取得プロセスstrm01_captureによってチェックポイントが10日と12時間ごとに自動的に消去されるように指定するには、次のプロシージャを実行します。

BEGIN
DBMS_CAPTURE_ADM.ALTER_CAPTURE(
capture_name              => 'strm01_capture',
checkpoint_retention_time => 10.5);
END;
/

無期限の取得プロセスのチェックポイント保存時間の設定

取得プロセスによってチェックポイントが自動的に消去されないように指定するには、チェックポイント保存時間をDBMS_CAPTURE_ADM.INFINITEに設定します。たとえば、次のプロシージャでは、取得プロセスstrm01_captureのチェックポイント保存時間が無期限に設定されます。

BEGIN
DBMS_CAPTURE_ADM.ALTER_CAPTURE(
capture_name              => 'strm01_capture',
checkpoint_retention_time => DBMS_CAPTURE_ADM.INFINITE);
END;
/

取得プロセスへのアーカイブREDOログ・ファイルの明示的な追加

取得プロセスにアーカイブREDOログ・ファイルを手動で追加するには、次の文を使用します。

ALTER DATABASE REGISTER LOGICAL LOGFILE
file_name FOR capture_process;

ここでは、file_nameは追加するアーカイブREDOログ・ファイルの名前で、capture_processはダウンストリーム・データベースのREDOログ・ファイルを使用する取得プロセスの名前です。capture_processは、logminer_session_nameと同じで、指定する必要があります。取得プロセスが実行されるサイトには、REDOログ・ファイルが存在する必要があります。

たとえば、取得プロセスstrm03_captureに/usr/log_files/1_3_486574859.dbfアーカイブREDOログ・ファイルを追加するには、次の文を発行します。

ALTER DATABASE REGISTER LOGICAL LOGFILE '/usr/log_files/1_3_486574859.dbf'
FOR 'strm03_capture';

関連項目:
ALTER DATABASE文の詳細は、『Oracle Database SQL言語リファレンス』を参照、またREDOログ・ファイルの登録については、『Oracle Data Guard概要および管理』を参照

既存の取得プロセスの先頭SCNの設定

既存の取得プロセスの先頭SCNを設定できます。

指定する先頭SCNは、次の要件を満たす必要があります。

- 取得プロセスの現在の先頭SCNより大きい値である必要があります。

- 取得プロセスの現行の適用済SCN以下であること。ただし、取得プロセスの現行の適用済SCNが0(ゼロ)である場合、この要件はあてはまりません。

- 取得プロセスの必須チェックポイントSCN以下の値である必要があります。

データベース内の各取得プロセスの現行の先頭SCN、適用済SCNおよび必須チェックポイントSCNを特定するには、次の問合せを使用します。

SELECT CAPTURE_NAME, FIRST_SCN, APPLIED_SCN, REQUIRED_CHECKPOINT_SCN
FROM DBA_CAPTURE;

取得プロセスの先頭SCNをリセットすると、新しい先頭SCN設定よりも値が小さい情報が、取得プロセスのLogMinerデータ・ディクショナリから自動的に消去されます。このため、取得プロセスの先頭SCNのリセット後は、その取得プロセスの開始SCNを新しい先頭SCNより小さい値に設定することはできません。また、新しい先頭SCNの設定前の情報を含むREDOログ・ファイルは、取得プロセスでは必要なくなります。

たとえば、次のプロシージャでは、DBMS_CAPTURE_ADMパッケージのALTER_CAPTUREプロシージャを使用して、取得プロセスstrm01_captureの先頭SCNが351232に設定されます。

BEGIN
DBMS_CAPTURE_ADM.ALTER_CAPTURE(
capture_name => 'strm01_capture',
first_scn    => 351232);
END;
/

注意:

- 指定した先頭SCNが取得プロセスの現行の開始SCNより大きい場合、開始SCNは、新しい先頭SCNの値に自動的に設定されます。

- 過去のある時点でのREDOログ内の変更を取得する必要がある場合、取得プロセスを作成し、REDOログでの以前のデータ・ディクショナリ・ビルドに対応する先頭SCNを指定できます。DBMS_CAPTURE_ADMパッケージのBUILDプロシージャによって、REDOログでデータ・ディクショナリ・ビルドが実行されます。

- DBA_LOGMNR_PURGED_LOGデータ・ディクショナリ・ビューを問い合せて、取得プロセスに不要なREDOログ・ファイルを特定できます。

関連項目:

- 「取得プロセスに関連するSCN値」

- 「取得プロセスのLogMinerデータ・ディクショナリ」

- 不要なREDOログ・ファイルを判別する問合せについては、「各取得プロセスで使用される各REDOログ・ファイルのSCN値の表示」を参照

既存の取得プロセスの開始SCNの設定

既存の取得プロセスの開始SCNを設定できます。通常、取得プロセスから変更を受け取る宛先データベースのいずれかでPoint-in-Timeリカバリを実行する必要がある場合、取得プロセスの開始SCNをリセットします。

指定した開始SCNは、取得プロセスの先頭SCNよりも大きいか等しいことが必要です。また、取得プロセスの開始SCNをリセットするときは、必要なREDOログ・ファイルが取得プロセスで使用できることを確認してください。

データベース内の各取得プロセスの先頭SCNを判別するには、次の問合せを使用します。

SELECT CAPTURE_NAME, FIRST_SCN FROM DBA_CAPTURE;

たとえば、取得プロセスstrm01_captureの開始SCNを750338に設定するには、次の手順を実行します。

1. 取得プロセスを停止します。方法については、「取得プロセスの停止」を参照してください。

2. ALTER_CAPTUREプロシージャを実行して、開始SCNを設定します。

BEGIN
DBMS_CAPTURE_ADM.ALTER_CAPTURE(
capture_name => 'strm01_capture',
start_scn    => 750338);
END;
/

3. 取得プロセスを起動します。方法については、「取得プロセスの起動」を参照してください。

関連項目:

- 「取得プロセスに関連するSCN値」

- Oracle Streams環境において、宛先データベースでPoint-in-Timeリカバリを実行する方法の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

ダウンストリーム取得でデータベース・リンクを使用するかどうかの指定

既存のダウンストリーム取得プロセスで、ソース・データベースへの管理用のデータベース・リンクを使用するかどうかを指定するには、DBMS_CAPTURE_ADMパッケージのALTER_CAPTUREプロシージャを使用します。ダウンストリーム取得プロセスでデータベース・リンクを使用するように指定するには、use_database_linkパラメータをTRUEに設定します。ダウンストリーム取得プロセスでデータベース・リンクを使用しないように指定するには、use_database_linkパラメータをFALSEに設定します。

現在データベース・リンクを使用していない取得プロセスでデータベース・リンクを使用するようにするには、use_database_linkパラメータをTRUEに設定します。この場合、ソース・データベースのグローバル名と同じ名前を持つデータベース・リンクが、ダウンストリーム・データベースに存在する必要があります。

現在データベース・リンクを使用している取得プロセスでデータベース・リンクを使用しないようにするには、use_database_linkパラメータをFALSEに設定します。この場合、取得プロセスの変更後に、いくつかの管理操作を手動で行う必要があります。たとえば、DBMS_STREAMS_ADMパッケージを使用して新しい取得プロセスのルールを追加する場合、ソース・データベースで、そのルールに関連付けられたオブジェクトのインスタンス化の準備を手動で行う必要があります。

use_database_linkパラメータをNULLに設定した場合、取得プロセスに対するこのパラメータの現行の値は変更されません。

ソース・データベースdbs1.example.comへのデータベース・リンクを作成し、この取得プロセスがデータベース・リンクを使用するように指定するには、次の手順を実行します。

1. SQL*Plusで、ダウンストリーム・データベースにOracle Streams管理者として接続します。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

2. ソース・データベースへのデータベース・リンクを作成します。データベース・リンクが、ソース・データベースのOracle Streams管理者に接続することを確認してください。次に例を示します。

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

3. データベース・リンクを使用するように取得プロセスを変更します。次に例を示します。

BEGIN
DBMS_CAPTURE_ADM.ALTER_CAPTURE(
capture_name       => 'strm05_capture',
use_database_link  => TRUE);
END;
/

関連項目:
「ローカル取得およびダウンストリーム取得」

取得プロセスの削除

既存の取得プロセスを削除するには、DBMS_CAPTURE_ADMパッケージのDROP_CAPTUREプロシージャを実行します。たとえば、次のプロシージャでは、取得プロセスstrm02_captureが削除されます。

BEGIN
DBMS_CAPTURE_ADM.DROP_CAPTURE(
capture_name          => 'strm02_capture',
drop_unused_rule_sets => TRUE);
END;
/

drop_unused_rule_setsパラメータがTRUEに設定されているため、このプロシージャでは、取得プロセスstrm02_captureで使用されているすべてのルール・セットも削除されます。ただし、他のOracle Streamsクライアントで使用されているルール・セットは削除されません。drop_unused_rule_setsパラメータがTRUEに設定されている場合は、取得プロセスのポジティブ・ルール・セットとネガティブ・ルール・セットの両方が削除されることがあります。このプロシージャによってルール・セットが削除された場合、そのルール・セット内のルールのうち、他のルール・セットに含まれていないルールも削除されます。

注意:
取得プロセスを削除するには、状態がDISABLEDまたはABORTEDであることが必要です。ENABLEDの取得プロセスは削除できません。

同期取得の管理

同期取得では内部メカニズムを使用して、表へのデータ操作言語(DML)の変更を取得します。同期取得は、取得した各変更を論理変更レコード(LCR)形式に再フォーマットし、LCRをANYDATAキューにエンキューします。

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

- 同期取得のルール・セットの管理

- 同期取得の取得ユーザーの設定

- 同期取得の削除

関連項目:

- 「同期取得による暗黙的取得」

- 同期取得の構成の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- 「同期取得の監視」

- 同期取得を使用するレプリケーション環境の構成例については、Oracle Database 2日でデータ・レプリケーションおよび統合ガイドを参照

同期取得のルール・セットの管理

この項では、次のタスクの実行手順を説明します。

- 同期取得のルール・セットの指定

- 同期取得のルール・セットへのルールの追加

- 同期取得のルール・セットからのルールの削除

関連項目:

- 第5章「Oracle Streamsでのルールの使用方法」

- 第11章「ルールの高度な概念」

同期取得のルール・セットの指定

同期取得には、1つのポジティブ・ルール・セットを指定できます。ポジティブ・ルール・セットの1つ以上のルールがTRUEと評価された場合、同期取得によって変更が取得されます。

既存のルール・セットをポジティブ・ルール・セットとして既存の同期取得に指定するには、ALTER_SYNC_CAPTUREプロシージャのrule_set_nameパラメータを使用します。このプロシージャは、DBMS_CAPTURE_ADMパッケージに含まれています。

たとえば、次のプロシージャでは、同期取得sync_captureのポジティブ・ルール・セットがsync_rule_setに設定されます。

BEGIN
DBMS_CAPTURE_ADM.ALTER_SYNC_CAPTURE(
capture_name  => 'sync_capture',
rule_set_name => 'strmadmin.sync_rule_set');
END;
/

注意:
同期取得のルール・セットは削除できません。

同期取得のルール・セットへのルールの追加

既存の同期取得のルール・セットにルールを追加するには、DBMS_STREAMS_ADMパッケージの次のいずれかのプロシージャを実行して既存の同期取得を指定できます。

- ADD_TABLE_RULES

- ADD_SUBSET_RULES

関連項目:
「システム作成ルール」

次の例では、DBMS_STREAMS_ADMパッケージのADD_TABLE_RULESプロシージャを実行して、同期取得sync_captureのポジティブ・ルール・セットにルールを追加します。

BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
table_name      =>  'hr.departments',
streams_type    =>  'sync_capture',
streams_name    =>  'sync_capture',
queue_name      =>  'strmadmin.streams_queue',
include_dml     =>  TRUE);
END;
/

このプロシージャを実行すると、次のアクションが実行されます。

- ルールが1つ作成されます。このルールは、hr.departments表に対するDML変更についてTRUEと評価されます。ルール名はシステムによって生成されます。

- ルールは、同期取得に関連付けられたポジティブ・ルール・セットに追加されます。

- DBMS_CAPTURE_ADMパッケージのPREPARE_SYNC_INSTANTIATIONファンクションが実行され、インスタンス化用にhr.departments表が準備されます。

注意:

- ADD_TABLE_RULESプロシージャまたはADD_SUBSET_RULESプロシージャを使用して、表のルールが同期取得のルール・セットに追加された場合のみ、同期取得によって表への変更が取得されます。DBMS_RULE_ADMパッケージのADD_RULEプロシージャを使用して、表ルールまたはサブセット・ルールがルール・セットに追加されると、同期取得によって表への変更は取得されません。また、同期取得では、グローバル・ルールやスキーマ・ルールなど、ルール・セットの表ルール以外およびサブセット・ルール以外のすべてのルールは無視されます。

- ADD_TABLE_RULESプロシージャまたはADD_SUBSET_RULESプロシージャでルールが同期取得のルール・セットに追加される場合、プロシージャは指定した表の排他ロックを取得する必要があります。指定した表に処理中のトランザクションがある場合、プロシージャはロックを取得できるまで待機します。

同期取得のルール・セットからのルールの削除

同期取得でルールに指定された変更を取得しない場合、同期取得のルール・セットからルールを削除します。たとえば、ルールdepartments3でhr.departments表へのDML変更が取得されるように指定するとします。同期取得でhr.departments表への変更を取得しない場合は、ルール・セットからルールdepartments3を削除します。

DBMS_STREAMS_ADMパッケージのREMOVE_RULEプロシージャを実行して、既存の同期取得のルール・セットからルールを削除します。たとえば、次のプロシージャでは、同期取得sync_captureのポジティブ・ルール・セットからルールdepartments3が削除されます。

BEGIN
DBMS_STREAMS_ADM.REMOVE_RULE(
rule_name        => 'departments3',
streams_type     => 'sync_capture',
streams_name     => 'sync_capture',
drop_unused_rule => TRUE);
END;
/

この例では、REMOVE_RULEプロシージャのdrop_unused_ruleパラメータがTRUEに設定されています。これはデフォルトの設定です。したがって、削除するルールが他のどのルール・セットにも含まれていなければ、そのルールはデータベースから削除されます。drop_unused_ruleパラメータがFALSEに設定されている場合、ルールはルール・セットから削除されますが、データベースからは削除されません。

同期取得のルール・セットからすべてのルールを削除するには、REMOVE_RULEプロシージャの実行時にrule_nameパラメータにNULLを指定します。

関連項目:
「Oracle Streamsクライアントに空のルール・セットが1つ以上存在する場合」

同期取得の取得ユーザーの設定

取得ユーザーは、同期取得のルール・セットを満たすすべてのDML変更を取得するユーザーです。同期取得の取得ユーザーを設定するには、DBMS_CAPTURE_ADMパッケージのALTER_SYNC_CAPTUREプロシージャでcapture_userパラメータを使用します。

取得ユーザーを変更するには、ALTER_SYNC_CAPTUREプロシージャを起動するユーザーにDBAロールが付与されている必要があります。SYSユーザーのみが、capture_userをSYSに設定できます。

たとえば、次のプロシージャでは、同期取得sync_captureの取得ユーザーがhrに設定されます。

BEGIN
DBMS_CAPTURE_ADM.ALTER_SYNC_CAPTURE(
capture_name => 'sync_capture',
capture_user => 'hr');
END;
/

このプロシージャを実行すると、新しい取得ユーザーに、同期取得で使用するキューのエンキュー権限が付与され、そのユーザーがキューの保護キュー・ユーザーとして構成されます。また、取得ユーザーが次の権限を持っていることを確認する必要があります。

- 同期取得で使用されるルール・セットのEXECUTE権限

- ルール・セットで使用するすべてのカスタム・ルールベースの変換ファンクションのEXECUTE権限

これらの権限は、取得ユーザーに直接付与するか、ロールを介して付与できます。

また、取得ユーザーには、同期取得で実行されるルールベースの変換で起動されるすべてのパッケージ(Oracle提供パッケージを含む)に対するEXECUTE権限を付与する必要があります。これらの権限は、取得ユーザーに直接付与する必要があります。これらの権限は、ロールを介して付与することはできません。

注意:
Oracle Database Vaultがインストールされている場合は、「Oracle StreamsおよびOracle Data Vault」に記載されている手順に従って、適切な権限やロールが付与されていることを確認してください。

同期取得の削除

既存の同期取得を削除するには、DBMS_CAPTURE_ADMパッケージのDROP_CAPTUREプロシージャを実行します。たとえば、次のプロシージャでは、同期取得sync_captureが削除されます。

BEGIN
DBMS_CAPTURE_ADM.DROP_CAPTURE(
capture_name          => 'sync_capture',
drop_unused_rule_sets => TRUE);
END;
/

drop_unused_rule_setsパラメータがTRUEに設定されているため、このプロシージャでは、同期取得sync_captureで使用されているすべてのルール・セットも削除されます(ただし、他のOracle Streamsクライアントで使用されているルール・セットは削除されません)。drop_unused_rule_setsパラメータがTRUEに設定されている場合は、同期取得のルール・セットが削除されることがあります。このプロシージャによってルール・セットが削除された場合、そのルール・セット内のルールのうち、他のルール・セットに含まれていないルールも削除されます。

取得LCRの追加属性の管理

1つ以上の追加属性を取得するように取得プロセスまたは同期取得に指示するには、DBMS_CAPTURE_ADMパッケージのINCLUDE_EXTRA_ATTRIBUTEプロシージャを使用します。また、このプロシージャを使用して、現在取得している追加属性を排除するように取得プロセスまたは同期取得に指示することもできます。

追加属性は次のとおりです。

- row_id(行LCRのみ)

- serial#

- session#

- thread#

- tx_name

- username

この項では、次のタスクの実行手順を説明します。

- 暗黙的に取得されたLCRへの追加属性の包含

- 暗黙的に取得されたLCRからの追加属性の排除

関連項目:

- 「LCRのその他の情報」

- 「暗黙的取得によって取得された追加属性の表示」

- INCLUDE_EXTRA_ATTRIBUTEプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

暗黙的に取得されたLCRへの追加属性の包含

取得プロセスまたは同期取得で取得されたLCRに追加属性を含めるには、INCLUDE_EXTRA_ATTRIBUTESプロシージャを実行して、includeパラメータをTRUEに設定します。たとえば、取得された各LCRにトランザクション名を含めるように取得プロセスまたは同期取得strm01_captureに指示するには、次のプロシージャを実行します。

BEGIN
DBMS_CAPTURE_ADM.INCLUDE_EXTRA_ATTRIBUTE(
capture_name   => 'strm01_capture',
attribute_name => 'tx_name',
include        => TRUE);
END;
/

暗黙的に取得されたLCRからの追加属性の排除

取得プロセスまたは同期取得で取得されたLCRから追加属性を排除するには、INCLUDE_EXTRA_ATTRIBUTESプロシージャを実行して、includeパラメータをFALSEに設定します。たとえば、取得された各LCRからトランザクション名を排除するように取得プロセスまたは同期取得strm01_captureに指示するには、次のプロシージャを実行します。

BEGIN
DBMS_CAPTURE_ADM.INCLUDE_EXTRA_ATTRIBUTE(
capture_name   => 'strm01_capture',
attribute_name => 'tx_name',
include        => FALSE);
END;
/

取得プロセスから同期取得への切替え

この項では、取得プロセスから同期取得への切替え方法について説明します。通常、同期取得は、比較的少数の表へのデータ操作言語(DML)変更を取得するために使用されます。現在、同期取得ではなく取得プロセスを使用して少数の表への変更を取得している場合は、この切替えを決定できます。

次のいずれかの条件に該当する場合は、取得プロセスから同期取得への切替えは行わないでください。

- 取得プロセスで、少数の表への変更を取得するのではなく、データベース全体、1つ以上のスキーマまたは多数の表への変更を取得している場合で、引き続きこれらの変更を取得する場合。

- 取得プロセスでデータ定義言語(DDL)変更を取得している場合で、引き続きDDL変更を取得する場合。同期取得では、DDL変更は取得できません。

- 取得プロセスでネガティブ・ルール・セットを使用しており、引き続きネガティブ・ルール・セットを使用する場合。同期取得では、ネガティブ・ルール・セットは使用できません。

- 取得プロセスがダウンストリーム取得プロセスの場合。同期取得では、ダウンストリーム取得は実行できません。

この項では例を用いて、取得プロセスから同期取得への切替え方法について説明します。表15-1に、サンプル環境での切替え前後のOracle Streamsコンポーネントを示します。

表15-1 取得プロセスから同期取得への切替えの例

Oracle Streamsコンポーネント

切替え前

切替え後

取得プロセス

cap_proc

なし

取得プロセス・ルール・セット

cap_rules

なし

同期取得

なし

sync_cap

同期取得ルール・セット

なし

cap_rules

伝播

cap_proc_prop

sync_cap_prop

伝播ルール・セット

prop_rules

prop_rules

ソース・キュー

cap_proc_source

sync_cap_source

宛先キュー

cap_proc_dest

sync_cap_dest

適用プロセス

apply_cap_proc

apply_sync_cap

適用プロセス・ルール・セット

apply_rules

apply_rules

表15-1では、Oracle Streams環境で切替え前と切替え後に同じルール・セットが使用されていることに注意してください。また、この項の例では、ソース・データベースがdb1.example.comで、宛先データベースがdb2.example.comであるとします。

注意:
この項の例では、Oracle Streams環境に2つのデータベースのみを含むものとします。有向ネットワークを使用して複数のデータベース経由で変更を送信している場合は、変更の新しい同期取得ストリーム用に追加の伝播およびキューを構成し、取得プロセスのストリームによって使用されていた追加の伝播およびキューを削除することが必要になる場合もあります。

取得プロセスから同期取得に切り替えるには、次の手順を実行します。

1. SQL*Plusで、ソース・データベースにOracle Streams管理者としてログインします。
この例では、各データベースのOracle Streams管理者はstrmadminであると想定しています。Oracle Streams管理者を作成する方法の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

2. 取得プロセスを停止します。

この例では、次のプロシージャを実行します。

BEGIN
DBMS_CAPTURE_ADM.STOP_CAPTURE(
capture_name => 'cap_proc');
END;
/

3. SQL*Plusで、宛先データベースにOracle Streams管理者としてログインします。

4. 同期取得で取得された変更を適用する適用プロセスにコミット時間キューを作成します。

この例では、次のプロシージャを実行します。

BEGIN
DBMS_STREAMS_ADM.SET_UP_QUEUE(
queue_table => 'strmadmin.sync_cap_dest_qt',
queue_name  => 'strmadmin.sync_cap_dest');
END;
/

5. 手順4で作成したキューの変更を適用する適用プロセスを作成します。apply_capturedパラメータをFALSEに設定します。また、rule_set_nameパラメータで、既存の適用プロセスで使用されているルール・セットが指定されていることを確認します。

この例では、次のプロシージャを実行します。

BEGIN
DBMS_APPLY_ADM.CREATE_APPLY(
queue_name     => 'strmadmin.sync_cap_dest',
apply_name     => 'apply_sync_cap',
rule_set_name  => 'strmadmin.apply_rules',
apply_captured => FALSE);
END;
/

適用プロセスが環境に適切に構成されていることを確認します。具体的には、新しい適用プロセスが、次の項目について適切に構成されていることを確認します。

- 適用ユーザー

- 適用ハンドラ

- 適用タグ

必要に応じて、新しい適用プロセスが、これらの項目について既存の適用プロセスと同じように構成されていることを確認します。

適用プロセスを作成する方法の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

6. SQL*Plusで、ソース・データベースにOracle Streams管理者としてログインします。

7. 同期取得のコミット時間キューを作成します。

この例では、次のプロシージャを実行します。

BEGIN
DBMS_STREAMS_ADM.SET_UP_QUEUE(
queue_table => 'strmadmin.sync_cap_source_qt',
queue_name  => 'strmadmin.sync_cap_source');
END;
/

キューを構成する方法の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

8. 手順7で作成したキューの変更を手順4で作成したキューに送信する伝播を作成します。rule_set_nameパラメータで、既存の伝播で使用されているルール・セットが指定されていることを確認します。
この例では、次のプロシージャを実行します。

BEGIN
DBMS_PROPAGATION_ADM.CREATE_PROPAGATION(
propagation_name   => 'sync_cap_prop',
source_queue       => 'strmadmin.sync_cap_source',
destination_queue  => 'strmadmin.sync_cap_dest',
destination_dblink => 'db2.example.com',
rule_set_name      => 'strmadmin.prop_rules');
END;
/

伝播を作成する方法の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

9. 同期取得を作成します。queue_nameパラメータに、手順7で作成したキューが指定されていることを確認します。また、rule_set_nameパラメータに、既存の取得プロセスで使用されているルール・セットが指定されていることを確認します。
この例では、次のプロシージャを実行します。

BEGIN
DBMS_CAPTURE_ADM.CREATE_SYNC_CAPTURE(
queue_name    => 'strmadmin.sync_cap_source',
capture_name  => 'sync_cap',
rule_set_name => 'strmadmin.capture_rules');
END;
/

指定したルール・セットには、DBMS_STREAMS_ADMパッケージのADD_TABLE_RULESプロシージャおよびADD_SUBSET_RULESプロシージャを使用して作成されたルールのみが含まれている必要があります。現行の取得プロセス・ルール・セットに他のタイプのルールが含まれている場合は、同期取得用のルール・セットを作成し、ADD_TABLE_RULESプロシージャおよびADD_SUBSET_RULESプロシージャを使用して、新しいルール・セットにルールを追加します。

また、同期取得ではネガティブ・ルール・セットを使用できません。現行の取得プロセスにネガティブ・ルール・セットがあり、同期取得に取得プロセスと同様の動作をさせる場合には、同期取得のポジティブ・ルール・セットにルールを追加すると、同じ動作結果が得られます。

既存の取得プロセスの取得ユーザーがOracle Streams管理者でない場合、CREATE_SYNC_CAPTUREプロシージャのcapture_userパラメータを使用して、新しい同期取得に適切な取得ユーザーが指定されていることを確認します。

同期取得を構成する方法の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

10. 次の問合せを実行して、同期取得用に構成された表が、既存の取得プロセス用に構成された表と同じであることを確認します。

SELECT * FROM DBA_SYNC_CAPTURE_TABLES ORDER BY TABLE_OWNER, TABLE_NAME;

表が無効であるか、存在していない場合は、ADD_TABLE_RULESプロシージャまたはADD_SUBSET_RULESプロシージャを使用して表を追加します。

11. インスタンス化するためにレプリケートされた表を準備します。レプリケートされた表は、同期取得が変更を取得した表です。

たとえば、同期取得でhr.employees表およびhr.departments表への変更が取得される場合は、次のファンクションを実行します。

SET SERVEROUTPUT ON
DECLARE
tables       DBMS_UTILITY.UNCL_ARRAY;
prepare_scn  NUMBER;
BEGIN
tables(1) := 'hr.departments';
tables(2) := 'hr.employees';
prepare_scn := DBMS_CAPTURE_ADM.PREPARE_SYNC_INSTANTIATION(
table_names => tables);
DBMS_OUTPUT.PUT_LINE('Prepare SCN = ' || prepare_scn);
END;
/

戻された準備システム変更番号(SCN)は、手順13、17および18で使用されます。この例では、準備SCNは2700000とします。

レプリケートされた表はすべて、PREPARE_SYNC_INSTANTIATIONファンクションに対する1つのコールに含まれている必要があります。

データベース・オブジェクトのインスタンス化の準備については、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

12. SQL*Plusで、宛先データベースにOracle Streams管理者としてログインします。

13. 手順11で戻された値に1を加えたSCNに達したときに変更の適用を停止するように、取得プロセスの変更を適用する適用プロセスを設定します。

たとえば、準備SCNが2700000の場合、次のプロシージャを実行して、maximum_scnパラメータを2700001(2700000 + 1)に設定します。

BEGIN
DBMS_APPLY_ADM.SET_PARAMETER(
apply_name   => 'apply_cap_proc',
parameter    => 'maximum_scn',
value        => '2700001');
END;
/

14. SQL*Plusで、ソース・データベースにOracle Streams管理者としてログインします。

15. 手順2で停止した取得プロセスを起動します。
この例では、次のプロシージャを実行します。

BEGIN
DBMS_CAPTURE_ADM.START_CAPTURE(
capture_name => 'cap_proc');
END;
/

16. SQL*Plusで、宛先データベースにOracle Streams管理者としてログインします。

17. 取得プロセスによって取得された変更を適用する適用プロセスが、手順13で指定したSCNの値に達するまで待機します。このイベントが発生すると、SCNの制限値に達したことを示すエラーORA-26717を伴って、適用プロセスは自動的に無効になります。

適用プロセスがこの制限値に達したことを確認するには、DBA_APPLYビューを問い合せます。この例では、次の問合せを実行します。

SELECT 1 FROM DBA_APPLY
WHERE STATUS       = 'DISABLED' AND
ERROR_NUMBER = 26717 AND
APPLY_NAME   = 'APPLY_CAP_PROC';

この問合せで行が戻されるまで、次の手順には進まないでください。

18. レプリケートされた表のインスタンス化SCNを、手順11でSCNにより戻されたSCN値に設定します。

この例では、次のプロシージャを実行します。

BEGIN
DBMS_APPLY_ADM.SET_TABLE_INSTANTIATION_SCN(
source_object_name    => 'hr.employees',
source_database_name  => 'db1.example.com',
instantiation_scn     => 2700000);
END;
/

BEGIN
DBMS_APPLY_ADM.SET_TABLE_INSTANTIATION_SCN(
source_object_name    => 'hr.departments',
source_database_name  => 'db1.example.com',
instantiation_scn     => 2700000);
END;
/

インスタンス化SCNの設定の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

19. 手順5で作成した適用プロセスを起動します。
この例では、次のプロシージャを実行します。

BEGIN
DBMS_APPLY_ADM.START_APPLY(
apply_name => 'apply_sync_cap');
END;
/

20. 取得プロセスで取得された変更を適用した適用プロセスを削除します。

この例では、次のプロシージャを実行します。

BEGIN
DBMS_APPLY_ADM.DROP_APPLY(
apply_name => 'apply_cap_proc');
END;
/

21. 手順20で削除した適用プロセスによって使用されたキューが不要であれば、削除します。
この例では、次のプロシージャを実行します。

BEGIN
DBMS_STREAMS_ADM.REMOVE_QUEUE(
queue_name  => 'strmadmin.cap_proc_dest',
drop_unused_queue_table => TRUE);
END;
/

22. SQL*Plusで、ソース・データベースにOracle Streams管理者としてログインします。

23. 取得プロセスを停止します。
この例では、次のプロシージャを実行します。

BEGIN
DBMS_CAPTURE_ADM.STOP_CAPTURE(
capture_name => 'cap_proc');
END;
/

24. 取得プロセスを削除します。

この例では、次のプロシージャを実行します。

BEGIN
DBMS_CAPTURE_ADM.DROP_CAPTURE(
capture_name => 'cap_proc');
END;
/

25. 取得プロセスで取得された変更を送信した伝播を削除します。

この例では、次のプロシージャを実行します。

BEGIN
DBMS_PROPAGATION_ADM.DROP_PROPAGATION(
propagation_name => 'cap_proc_prop');
END;
/

26. 手順24と25で削除した取得プロセスおよび伝播によって使用されたキューが不要であれば、削除します。
この例では、次のプロシージャを実行します。

BEGIN
DBMS_STREAMS_ADM.REMOVE_QUEUE(
queue_name  => 'strmadmin.cap_proc_source',
drop_unused_queue_table => TRUE);
END;
/

双方向レプリケーション環境の場合、これらの手順を個別に実行し、取得プロセスから同期取得に双方向で切り替えることができます。

関連項目:

- 第2章「Oracle Streams情報取得」

- 第5章「Oracle Streamsでのルールの使用方法」

同期取得から取得プロセスへの切替え

この項では、同期取得から取得プロセスへの切替え方法について説明します。この切替えは、次のいずれかの場合に行います。

- 現在は少数の表への変更を取得しているが、使用する環境を拡張して、多数の表、1つ以上のスキーマまたはデータベース全体への変更を取得する場合。

- 変更の取得中に、ネガティブ・ルール・セットを使用する場合。

- データベース・オブジェクトへのデータ定義言語(DDL)変更を取得する場合。

この項では例を用いて、同期取得から取得プロセスへの切替え方法について説明します。表 15-2に、サンプル環境での切替え前後のOracle Streamsコンポーネントを示します。

表 15-2 同期取得から取得プロセスへの切替えの例

Oracle Streamsコンポーネント

切替え前

切替え後

同期取得

sync_proc

なし

同期取得ルール・セット

cap_rules

なし

取得プロセス

なし

cap_proc

取得プロセス・ルール・セット

なし

cap_rules

伝播

sync_cap_prop

cap_proc_prop

伝播ルール・セット

prop_rules

prop_rules

ソース・キュー

sync_cap_source

cap_proc_source

宛先キュー

sync_cap_dest

cap_proc_dest

適用プロセス

apply_sync_cap

apply_cap_proc

適用プロセス・ルール・セット

apply_rules

apply_rules

表15-2では、Oracle Streams環境で切替え前と切替え後に同じルール・セットが使用されていることに注意してください。また、この項の例では、ソース・データベースがdb1.example.comで、宛先データベースがdb2.example.comであるとします。

注意:
この項の例では、Oracle Streams環境に2つのデータベースのみを含むものとします。有向ネットワークを使用して複数のデータベースを介して変更を送信している場合、変更の新規取得プロセス・ストリーム用に追加の伝播およびキューを構成し、同期取得のストリームによって使用された追加の伝播およびキューを削除することが必要になる場合もあります。

同期取得から取得プロセスに切り替えるには、次の手順を実行します。

1. ソース・データベースがARCHIVELOGモードで実行されていることを確認します。詳細は、「ARCHIVELOGモードおよび取得プロセス」および『Oracle Database管理者ガイド』を参照してください。

2. SQL*Plusで、宛先データベースにOracle Streams管理者としてログインします。
この例では、各データベースのOracle Streams管理者はstrmadminであると想定しています。Oracle Streams管理者を作成する方法の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

3. 取得プロセスで取得された変更を適用する適用プロセスにキューを作成します。

この例では、次のプロシージャを実行します。

BEGIN
DBMS_STREAMS_ADM.SET_UP_QUEUE(
queue_table => 'strmadmin.cap_proc_dest_qt',
queue_name  => 'strmadmin.cap_proc_dest');
END;
/

キューを構成する方法の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

4. 手順3で作成したキューの変更を適用する適用プロセスを作成します。apply_capturedパラメータをTRUEに設定します。また、rule_set_nameパラメータで、既存の適用プロセスで使用されているルール・セットが指定されていることを確認します。

この例では、次のプロシージャを実行します。

BEGIN
DBMS_APPLY_ADM.CREATE_APPLY(
queue_name     => 'strmadmin.cap_proc_dest',
apply_name     => 'apply_cap_proc',
rule_set_name  => 'strmadmin.apply_rules',
apply_captured => TRUE);
END;
/

適用プロセスが環境に適切に構成されていることを確認します。具体的には、新しい適用プロセスが、次の項目について適切に構成されていることを確認します。

- 適用ユーザー

- 適用ハンドラ

- 適用タグ

必要に応じて、新しい適用プロセスが、これらの項目について既存の適用プロセスと同じように構成されていることを確認します。

適用プロセスを作成する方法の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

5. 同期取得で取得された変更を適用する適用プロセスを停止します。
この例では、次のプロシージャを実行します。

BEGIN
DBMS_APPLY_ADM.STOP_APPLY(
apply_name => 'apply_sync_cap');
END;
/

6. SQL*Plusで、ソース・データベースにOracle Streams管理者としてログインします。

7. 取得プロセスのキューを作成します。

この例では、次のプロシージャを実行します。

BEGIN
DBMS_STREAMS_ADM.SET_UP_QUEUE(
queue_table => 'strmadmin.cap_proc_source_qt',
queue_name  => 'strmadmin.cap_proc_source');
END;
/

8. 手順7で作成したキューの変更を手順3で作成したキューに送信する伝播を作成します。rule_set_nameパラメータで、既存の伝播で使用されているルール・セットが指定されていることを確認します。
この例では、次のプロシージャを実行します。

BEGIN
DBMS_PROPAGATION_ADM.CREATE_PROPAGATION(
propagation_name   => 'cap_proc_prop',
source_queue       => 'strmadmin.cap_proc_source',
destination_queue  => 'strmadmin.cap_proc_dest',
destination_dblink => 'db2.example.com',
rule_set_name      => 'strmadmin.prop_rules');
END;
/

伝播を作成する方法の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

9. 取得プロセスを作成します。次に示すように、パラメータがCREATE_CAPTUREプロシージャで適切に設定されていることを確認します。

- queue_nameパラメータを手順7で作成したキューに設定します。

- rule_set_nameパラメータを既存の同期取得で使用されているルール・セットに設定します。

- 既存の同期取得の取得ユーザーがOracle Streams管理者でない場合、capture_userパラメータを、新しい取得プロセスの適切な取得ユーザーに設定します。

この例では、次のプロシージャを実行します。

BEGIN
DBMS_CAPTURE_ADM.CREATE_CAPTURE(
queue_name    => 'strmadmin.cap_proc_source',
capture_name  => 'cap_proc',
rule_set_name => 'strmadmin.cap_rules');
END;
/

取得プロセスを構成する方法の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

10. インスタンス化するためにレプリケートされた表を準備します。レプリケートされた表は、取得プロセスで変更を取得した表です。
たとえば、取得プロセスでhr.employees表およびhr.departments表への変更が取得される場合は、次のプロシージャを実行します。

BEGIN
DBMS_CAPTURE_ADM.PREPARE_TABLE_INSTANTIATION(
table_name           => 'hr.employees',
supplemental_logging => 'keys');
END;
/

BEGIN
DBMS_CAPTURE_ADM.PREPARE_TABLE_INSTANTIATION(
table_name           => 'hr.departments',
supplemental_logging => 'keys');
END;
/

データベース・オブジェクトのインスタンス化の準備については、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

11. SHAREMODEでレプリケートされたすべての表をロックします。
この例では、次のSQL文を実行します。

LOCK TABLE hr.employees, hr.departments IN SHARE MODE;

12. 次の問合せを実行して、現行のシステム変更番号(SCN)を確認します。

SELECT CURRENT_SCN FROM V$DATABASE;

戻された切替えSCNは、手順15および18で使用されます。この例では、切替えSCNは2700000とします。

13. COMMIT文を実行して、レプリケートされた表のロックを解放します。

COMMIT;

14. SQL*Plusで、宛先データベースにOracle Streams管理者としてログインします。

15. 手順12で戻された値に1を加えたSCNに達したときに変更の適用を停止するように、同期取得の変更を適用する適用プロセスを設定します。

たとえば、切替えSCNが2700000の場合、次のプロシージャを実行して、maximum_scnパラメータを2700001(2700000 + 1)に設定します。

BEGIN
DBMS_APPLY_ADM.SET_PARAMETER(
apply_name   => 'apply_sync_cap',
parameter    => 'maximum_scn',
value        => '2700001');
END;
/

16. 同期取得からの変更を適用する適用プロセスを起動します。
この例では、次のプロシージャを実行します。

BEGIN
DBMS_APPLY_ADM.START_APPLY(
apply_name => 'apply_sync_cap');
END;
/

17. 同期取得によって取得された変更を適用する適用プロセスが、手順15で指定したSCNの値に達するまで待機します。このイベントが発生すると、SCNの制限値に達したことを示すエラーORA-26717を伴って、適用プロセスは自動的に無効になります。

適用プロセスがこの制限値に達したことを確認するには、DBA_APPLYビューを問い合せます。この例では、次の問合せを実行します。

SELECT 1 FROM DBA_APPLY
WHERE STATUS       = 'DISABLED' AND
ERROR_NUMBER = 26717 AND
APPLY_NAME   = 'APPLY_SYNC_CAP';

この問合せで行が戻されるまで、次の手順には進まないでください。

18. レプリケートされた表のインスタンス化SCNを、手順12で戻されたSCN値に設定します。

この例では、次のプロシージャを実行します。

BEGIN
DBMS_APPLY_ADM.SET_TABLE_INSTANTIATION_SCN(
source_object_name    => 'hr.employees',
source_database_name  => 'db1.example.com',
instantiation_scn     => 2700000);
END;
/

BEGIN
DBMS_APPLY_ADM.SET_TABLE_INSTANTIATION_SCN(
source_object_name    => 'hr.departments',
source_database_name  => 'db1.example.com',
instantiation_scn     => 2700000);
END;
/

インスタンス化SCNの設定の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

19. 手順4で作成した適用プロセスを起動します。
この例では、次のプロシージャを実行します。

BEGIN
DBMS_APPLY_ADM.START_APPLY(
apply_name => 'apply_cap_proc');
END;
/

20. 同期取得で取得された変更を適用した適用プロセスを削除します。

この例では、次のプロシージャを実行します。

BEGIN
DBMS_APPLY_ADM.DROP_APPLY(
apply_name => 'apply_sync_cap');
END;
/

21. 手順20で削除した適用プロセスによって使用されたキューが不要であれば、削除します。
この例では、次のプロシージャを実行します。

BEGIN
DBMS_STREAMS_ADM.REMOVE_QUEUE(
queue_name              => 'strmadmin.sync_cap_dest',
drop_unused_queue_table => TRUE);
END;
/

22. SQL*Plusで、ソース・データベースにOracle Streams管理者としてログインします。

23. 手順9で作成した取得プロセスを起動します。
この例では、次のプロシージャを実行します。

BEGIN
DBMS_CAPTURE_ADM.START_CAPTURE(
capture_name => 'cap_proc');
END;
/

24. 同期取得を削除します。

この例では、次のプロシージャを実行します。

BEGIN
DBMS_CAPTURE_ADM.DROP_CAPTURE(
capture_name => 'sync_cap');
END;
/

25. 同期取得で取得された変更を送信した伝播を削除します。

この例では、次のプロシージャを実行します。

BEGIN
DBMS_PROPAGATION_ADM.DROP_PROPAGATION(
propagation_name => 'sync_cap_prop');
END;
/

26. 手順24と25で削除した同期取得および伝播によって使用されたキューが不要であれば、削除します。
この例では、次のプロシージャを実行します。

BEGIN
DBMS_STREAMS_ADM.REMOVE_QUEUE(
queue_name              => 'strmadmin.sync_cap_source',
drop_unused_queue_table => TRUE);
END;
/

双方向レプリケーション環境の場合、これらの手順を個別に実行して、同期取得から取得プロセスに双方向で切り替えることができます。

関連項目:

- 第2章「Oracle Streams情報取得」

- 第5章「Oracle Streamsでのルールの使用方法」

16 ステージングと伝播の管理

次の各項では、ANYDATAキューと伝播の管理について説明します。

- キューの管理

- Oracle Streamsの伝播および伝播ジョブの管理

この章で説明する各タスクは、特に明記されていないかぎり、適切な権限を付与されているOracle Streams管理者が完了する必要があります。

関連項目:

- 第3章「Oracle Streamsのステージングと伝播」

- Oracle Streams管理者を作成する方法の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- 「キューおよびメッセージの監視」

- 「Oracle Streamsの伝播および伝播ジョブの監視」

- 第32章「伝播のトラブルシューティング」

キューの管理

ANYDATAキューでは、ペイロードがANYDATA型であるメッセージがステージングされます。したがって、ANYDATAキューでは、ペイロードがANYDATAラッパーにラップされていれば、ほぼすべての型のペイロードのメッセージをステージングできます。Oracle Streamsの各取得プロセス、適用プロセスおよびメッセージ・クライアントは1つのANYDATAキューに関連付けられ、Oracle Streamsの各伝播は1つのANYDATAソース・キューと1つのANYDATA宛先キューに関連付けられます。

この項では、キューに関連する次のタスクの実行手順を説明します。

- 保護キューでのユーザー操作の有効化

- 保護キューでのユーザー操作の無効化

- キューの削除

保護キューでのユーザー操作の有効化

ユーザーが保護キューでエンキューやデキューなどのキュー操作を実行できるようにするには、そのユーザーをキューの保護キュー・ユーザーとして構成する必要があります。DBMS_STREAMS_ADMパッケージのSET_UP_QUEUEプロシージャを使用して保護キューを作成すると、キュー所有者とqueue_userパラメータで指定したユーザーは自動的にキューの保護ユーザーとして構成されます。他のユーザーに対してキュー操作の実行を許可する場合は、そのユーザーを次のいずれかの方法で構成できます。

- SET_UP_QUEUEを実行してqueue_userを指定します。キューが存在する場合、キューの作成はスキップされますが、新規キュー・ユーザーを指定した場合はそのユーザーが構成されます。

- ユーザーをOracle Streamsアドバンスト・キューイング(AQ)・エージェントに手動で関連付けます。

次の例に、ユーザーをOracle Streams AQエージェントに手動で関連付ける手順を示します。streams_queueという名前のキューに対して、oeユーザーがキュー操作を実行できるようにするとします。次の手順に従って、oeユーザーをstreams_queueの保護キュー・ユーザーとして構成します。

1. SQL*Plusで、Oracle Streams AQエージェントを作成してユーザーを変更できる管理ユーザーとして接続します。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

2. 次のように入力してエージェントを作成します。

EXEC DBMS_AQADM.CREATE_AQ_AGENT(agent_name => 'streams_queue_agent');

3. ユーザーがキューからメッセージをデキューできるようにする必要がある場合は、エージェントを保護キューのサブスクライバにします。

DECLARE
subscriber SYS.AQ$_AGENT;
BEGIN
subscriber :=  SYS.AQ$_AGENT('streams_queue_agent', NULL, NULL);
DBMS_AQADM.ADD_SUBSCRIBER(
queue_name          =>  'strmadmin.streams_queue',
subscriber          =>  subscriber,
rule                =>  NULL,
transformation      =>  NULL);
END;
/

4. ユーザーをエージェントに関連付けます。

BEGIN
DBMS_AQADM.ENABLE_DB_ACCESS(
agent_name  => 'streams_queue_agent',
db_username => 'oe');
END;
/

5. ユーザーにDBMS_STREAMS_MESSAGINGパッケージまたはDBMS_AQパッケージのEXECUTE権限が付与されていない場合は、これらの権限を付与します。

GRANT EXECUTE ON DBMS_STREAMS_MESSAGING TO oe;

GRANT EXECUTE ON DBMS_AQ TO oe;

前述の手順を完了すると、oeユーザーはstreams_queueの保護ユーザーとなり、このキューを操作できます。ただし、ユーザーにはエンキュー権限やデキュー権限など、キュー操作を実行するための特定の権限を付与する必要もあります。

関連項目:

- 「保護キュー」

- Oracle Streams AQエージェントとDBMS_AQADMパッケージの使用方法の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

保護キューでのユーザー操作の無効化

次のような理由でユーザーに対して、保護キューのキュー操作を禁止する場合があります。

- 取得プロセスまたは同期取得を削除したが、取得プロセスまたは同期取得で使用されていたキューを削除しておらず、取得ユーザーであったユーザーに対して残りの保護キューの操作を禁止する場合。

- 適用プロセスを削除したが、適用プロセスで使用されていたキューを削除しておらず、適用ユーザーであったユーザーには残りの保護キューの操作を禁止する場合。

- DBMS_APPLY_ADMパッケージのALTER_APPLYプロシージャを使用して適用プロセスのapply_userを変更しており、変更前のapply_userには適用プロセスのキューの操作を禁止する場合。

- 「保護キューでのユーザー操作の有効化」で説明した手順に従って、ユーザーに保護キューの操作を許可したが、この後、このユーザーには保護キューのキュー操作を禁止する場合。

保護キュー・ユーザーを無効化するには、キューに対するENQUEUEおよびDEQUEUE権限をユーザーから取り消す方法と、DBMS_AQADMパッケージのDISABLE_DB_ACCESSプロシージャを実行する方法があります。たとえば、oeユーザーに対して、streams_queueという名前のキューのキュー操作を禁止するとします。

注意:
複数の保護キューにOracle Streams AQエージェントを使用している場合は、そのエージェントに対してDISABLE_DB_ACCESSを実行すると、そのエージェントに関連付けられているユーザーがこれらすべてのキューに対する操作を実行できなくなります。

1. 次のプロシージャを実行し、oeユーザーに対して保護キューstreams_queueのキュー操作を禁止します。

BEGIN
DBMS_AQADM.DISABLE_DB_ACCESS(
agent_name  => 'streams_queue_agent',
db_username => 'oe');
END;
/

2. 不要になったエージェントは削除できます。

BEGIN
DBMS_AQADM.DROP_AQ_AGENT(
agent_name  => 'streams_queue_agent');
END;
/

3. キューに対する権限がユーザーにとって不要になった場合は、その権限を取り消します。

BEGIN
DBMS_AQADM.REVOKE_QUEUE_PRIVILEGE (
privilege   => 'ALL',
queue_name  => 'strmadmin.streams_queue',
grantee     => 'oe');
END;
/

関連項目:

- 「保護キュー」

- Oracle Streams AQエージェントとDBMS_AQADMパッケージの使用方法の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

キューの削除

既存のANYDATAキューを削除するには、DBMS_STREAMS_ADMパッケージのREMOVE_QUEUEプロシージャを使用します。REMOVE_QUEUEプロシージャを実行すると、キューにある既存のメッセージがコンシュームされるまでプロシージャは待機します。その後、プロシージャによってキューが停止され、キューに対するエンキューまたはデキューが禁止されます。停止したキューは、プロシージャによって削除されます。

キューのキュー表が空で他のキューに使用されていない場合、キュー表も削除できます。キュー表を削除するには、drop_unused_queue_tableパラメータにTRUE(デフォルト)を指定します。

また、cascadeパラメータをTRUEに設定すると、そのキューを使用するすべてのOracle Streamsクライアントを削除できます。デフォルトでは、cascadeパラメータはFALSEに設定されています。

たとえば、strmadminスキーマ内のANYDATAキューstreams_queueを削除して、そのキューの空のキュー表を削除するには、次のプロシージャを実行します。

BEGIN
DBMS_STREAMS_ADM.REMOVE_QUEUE(
queue_name              => 'strmadmin.streams_queue',
cascade                 => FALSE,
drop_unused_queue_table => TRUE);
END;
/

この例ではcascadeパラメータがFALSEに設定されているため、Oracle Streamsクライアントがstreams_queueを使用していない場合のみ、このプロシージャはそのキューを削除します。cascadeパラメータがFALSEに設定されており、Oracle Streamsクライアントがそのキューを使用している場合は、エラーが発生します。

Oracle Streamsの伝播および伝播ジョブの管理

伝播では、Oracle Streamsのソース・キューから宛先キューにメッセージが伝播されます。この項では、次のタスクの実行手順を説明します。

- 伝播の開始

- 伝播の停止

- 伝播ジョブのスケジュールの変更

- 伝播のルール・セットの指定

- 伝播のルール・セットへのルールの追加

- 伝播のルール・セットからのルールの削除

- 伝播のルール・セットの削除

- 伝播の削除

また、Oracle Streamsの伝播は、Oracle Streamsアドバンスト・キューイング(AQ)の機能を使用して管理することもできます。

関連項目:

- 「キュー間でのメッセージの伝播」

- Enterprise Managerでの伝播の管理の詳細は、Oracle Database 2日でデータ・レプリケーションおよび統合ガイドおよびOracle Enterprise Managerのオンライン・ヘルプを参照

- Oracle Streams AQの機能を使用した伝播の管理の詳細は、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドを参照してください。

伝播の開始

既存の伝播を開始するには、DBMS_PROPAGATION_ADMパッケージのSTART_PROPAGATIONプロシージャを実行します。たとえば、次のプロシージャでは、伝播strm01_propagationが開始されます。

BEGIN
DBMS_PROPAGATION_ADM.START_PROPAGATION(
propagation_name => 'strm01_propagation');
END;
/

伝播の停止

既存の伝播を停止するには、DBMS_PROPAGATION_ADMパッケージのSTOP_PROPAGATIONプロシージャを実行します。たとえば、次のプロシージャでは、伝播strm01_propagationが停止されます。

BEGIN
DBMS_PROPAGATION_ADM.STOP_PROPAGATION(
propagation_name => 'strm01_propagation',
force            => FALSE);
END;
/

伝播の停止時に統計を消去するには、forceパラメータをTRUEに設定します。伝播に問題が発生した場合は、forceパラメータをTRUEに設定して伝播を停止してから伝播を再開始すると、問題を解決できることがあります。forceパラメータがFALSEに設定されている場合は、伝播の統計は消去されません。

伝播ジョブのスケジュールの変更

既存の伝播ジョブのスケジュールを変更するには、DBMS_AQADMパッケージのALTER_PROPAGATION_SCHEDULEプロシージャを使用します。次の各項では、キュー・ツー・キュー伝播およびキュー・ツーdblink伝播の伝播ジョブのスケジュールを変更する例を説明します。これらの例では、メッセージを15分(900秒)ごとに300秒間伝播させ、25秒待機してから、完全に伝播されたキューの新しいメッセージが伝播されるように、伝播ジョブを設定します。

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

- キュー・ツー・キュー伝播の伝播ジョブのスケジュール変更

- キュー・ツーdblink伝播の伝播ジョブのスケジュール変更

関連項目:

- ALTER_PROPAGATION_SCHEDULEプロシージャの使用方法の詳細は、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドを参照

- 「キュー・ツー・キュー伝播」

- 「伝播ジョブ」

キュー・ツー・キュー伝播の伝播ジョブのスケジュール変更

dbs2.example.comデータベース・リンクを使用してstrmadmin.strm_a_queueソース・キューからstrmadmin.strm_b_queue宛先キューにメッセージを伝播するキュー・ツー・キュー伝播の伝播ジョブのスケジュールを変更するには、次のプロシージャを実行します。

BEGIN
DBMS_AQADM.ALTER_PROPAGATION_SCHEDULE(
queue_name        => 'strmadmin.strm_a_queue',
destination       => 'dbs2.example.com',
duration          => 300,
next_time         => 'SYSDATE + 900/86400',
latency           => 25,
destination_queue => 'strmadmin.strm_b_queue');
END;
/

各キュー・ツー・キュー伝播には独自の伝播ジョブがあるため、このプロシージャでは、指定した2つのキュー間でメッセージが伝播される伝播のスケジュールのみを変更できます。キュー・ツー・キュー伝播の伝播スケジュールを変更するには、destination_queueパラメータで宛先キューの名前を指定する必要があります。

キュー・ツーdblink伝播の伝播ジョブのスケジュール変更

dbs3.example.comデータベース・リンクを使用してstrmadmin.streams_queueソース・キューからメッセージを伝播するキュー・ツーdblink伝播の伝播ジョブのスケジュールを変更するには、次のプロシージャを実行します。

BEGIN
DBMS_AQADM.ALTER_PROPAGATION_SCHEDULE(
queue_name  => 'strmadmin.streams_queue',
destination => 'dbs3.example.com',
duration    => 300,
next_time   => 'SYSDATE + 900/86400',
latency     => 25);
END;
/

伝播がキュー・ツーdblink伝播であるため、destination_queueパラメータは指定されていません。このタスクは、dbs3.example.com データベース・リンクを使用するすべての宛先キューに対してソース・キューからメッセージを伝播するすべてのキュー・ツーdblink伝播に影響します。

伝播のルール・セットの指定

伝播には、1つのポジティブ・ルール・セットおよび1つのネガティブ・ルール・セットを指定できます。伝播では、ポジティブ・ルール・セット内の1つ以上のルールがTRUEと評価される場合にメッセージは伝播され、ネガティブ・ルール・セット内の1つ以上のルールがTRUEと評価される場合は変更が破棄されます。ネガティブ・ルール・セットは、ポジティブ・ルール・セットの前に評価されます。

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

- 伝播のポジティブ・ルール・セットの指定

- 伝播のネガティブ・ルール・セットの指定

関連項目:

- 第5章「Oracle Streamsでのルールの使用方法」

- 第11章「ルールの高度な概念」

伝播のポジティブ・ルール・セットの指定

既存のルール・セットを既存の伝播のポジティブ・ルール・セットとして指定するには、ALTER_PROPAGATIONプロシージャのrule_set_nameパラメータを使用します。このプロシージャはDBMS_PROPAGATION_ADMパッケージに含まれています。

たとえば、次のプロシージャでは伝播strm01_propagationのポジティブ・ルール・セットがstrm02_rule_setに設定されます。

BEGIN
DBMS_PROPAGATION_ADM.ALTER_PROPAGATION(
propagation_name  => 'strm01_propagation',
rule_set_name     => 'strmadmin.strm02_rule_set');
END;
/

伝播のネガティブ・ルール・セットの指定

既存のルール・セットを既存の伝播のネガティブ・ルール・セットとして指定するには、ALTER_PROPAGATIONプロシージャのnegative_rule_set_nameパラメータを使用します。このプロシージャはDBMS_PROPAGATION_ADMパッケージに含まれています。

たとえば、次のプロシージャでは伝播strm01_propagationのネガティブ・ルール・セットがstrm03_rule_setに設定されます。

BEGIN
DBMS_PROPAGATION_ADM.ALTER_PROPAGATION(
propagation_name        => 'strm01_propagation',
negative_rule_set_name  => 'strmadmin.strm03_rule_set');
END;
/

伝播のルール・セットへのルールの追加

伝播のルール・セットにルールを追加するには、次のいずれかのプロシージャを実行します。

- 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プロシージャでは、伝播のポジティブ・ルール・セットのみにルールを追加できます。

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

- 伝播のポジティブ・ルール・セットへのルールの追加

- 伝播のネガティブ・ルール・セットへのルールの追加

関連項目:

- 「キュー間でのメッセージの伝播」

- 「システム作成ルール」

伝播のポジティブ・ルール・セットへのルールの追加

次の例では、DBMS_STREAMS_ADMパッケージのADD_TABLE_PROPAGATION_RULESプロシージャを実行して、既存の伝播strm01_propagationのポジティブ・ルール・セットにルールを追加します。

BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_PROPAGATION_RULES(
table_name              => 'hr.locations',
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,
source_database         => 'dbs1.example.com',
inclusion_rule          => TRUE);
END;
/

このプロシージャを実行すると、次のアクションが実行されます。

- 2つのルールが作成されます。一方のルールは、hr.locations表に対するDML変更の結果を含む行LCRについてTRUEと評価されます。他方のルールは、hr.locations表に対するDDL変更を含むDDL LCRについてTRUEと評価されます。ルール名は、システムによって生成されます。

- どちらのルールも、dbs1.example.comソース・データベースで変更が発生したLCRに対してのみTRUEと評価されるように指定されます。

- inclusion_ruleパラメータがTRUEに設定されているため、これらの2つのルールは、伝播に関連付けられたポジティブ・ルール・セットに追加されます。

伝播のネガティブ・ルール・セットへのルールの追加

次の例では、DBMS_STREAMS_ADMパッケージのADD_TABLE_PROPAGATION_RULESプロシージャを実行して、既存の伝播strm01_propagationのネガティブ・ルール・セットにルールを追加します。

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,
source_database         => 'dbs1.example.com',
inclusion_rule          => FALSE);
END;
/

このプロシージャを実行すると、次のアクションが実行されます。

- 2つのルールが作成されます。一方のルールはhr.departments表に対するDML変更の結果を含む行LCRについてTRUEと評価され、他方のルールは、hr.departments表に対するDDL変更を含むDDL LCRについてTRUEと評価されます。ルール名は、システムによって生成されます。

- どちらのルールも、dbs1.example.comソース・データベース で変更が発生したLCRに対してのみ TRUEと評価されるように指定されます。

- inclusion_ruleパラメータがFALSEに設定されているため、これらの2つのルールは、伝播に関連付けられたネガティブ・ルール・セットに追加されます。

伝播のルール・セットからのルールの削除

DBMS_STREAMS_ADMパッケージのREMOVE_RULEプロシージャを実行すると、既存の伝播のルール・セットからルールを削除できます。たとえば、次のプロシージャでは、伝播strm01_propagationのポジティブ・ルール・セットからルールdepartments3が削除されます。

BEGIN
DBMS_STREAMS_ADM.REMOVE_RULE(
rule_name        => 'departments3',
streams_type     => 'propagation',
streams_name     => 'strm01_propagation',
drop_unused_rule => TRUE,
inclusion_rule   => TRUE);
END;
/

この例では、REMOVE_RULEプロシージャのdrop_unused_ruleパラメータがTRUEに設定されています。これはデフォルトの設定です。したがって、削除するルールが他のどのルール・セットにも含まれていなければ、そのルールはデータベースから削除されます。drop_unused_ruleパラメータがFALSEに設定されている場合、ルールはルール・セットから削除されますが、他のどのルール・セットにも含まれていない場合でも、データベースからは削除されません。

inclusion_ruleパラメータがFALSEに設定されている場合、REMOVE_RULEプロシージャによって、伝播のポジティブ・ルール・セットからではなく、ネガティブ・ルール・セットからルールが削除されます。

伝播のルール・セットからすべてのルールを削除するには、REMOVE_RULEプロシージャの実行時にrule_nameパラメータにNULLを指定します。

関連項目:
「Oracle Streamsクライアントに空のルール・セットが1つ以上存在する場合」

伝播のルール・セットの削除

伝播からルール・セットを削除するには、DBMS_PROPAGATION_ADMパッケージのALTER_PROPAGATIONプロシージャを使用します。このプロシージャでは、ポジティブ・ルール・セットまたはネガティブ・ルール・セット、あるいはその両方を削除できます。伝播のポジティブ・ルール・セットを削除するには、remove_rule_setパラメータをTRUEに指定します。伝播のネガティブ・ルール・セットを削除するには、remove_negative_rule_setパラメータをTRUEに指定します。

たとえば、次のプロシージャでは、伝播strm01_propagationからポジティブ・ルール・セットとネガティブ・ルール・セットの両方が削除されます。

BEGIN
DBMS_PROPAGATION_ADM.ALTER_PROPAGATION(
propagation_name         => 'strm01_propagation',
remove_rule_set          => TRUE,
remove_negative_rule_set => TRUE);
END;
/

注意:
伝播にポジティブ・ルール・セットまたはネガティブ・ルール・セットを指定していない場合、その伝播では、ソース・キューのすべてのメッセージが宛先キューに伝播されます。

伝播の削除

既存の伝播を削除するには、DBMS_PROPAGATION_ADMパッケージのDROP_PROPAGATIONプロシージャを実行します。たとえば、次のプロシージャでは、伝播strm01_propagationが削除されます。

BEGIN
DBMS_PROPAGATION_ADM.DROP_PROPAGATION(
propagation_name      => 'strm01_propagation',
drop_unused_rule_sets => TRUE);
END;
/

drop_unused_rule_setsパラメータがTRUEに設定されているため、このプロシージャでは伝播strm01_propagationで使用されているすべてのルール・セットも削除されます。ただし、他のOracle Streamsクライアントで使用されているルール・セットは削除されません。drop_unused_rule_setsパラメータがTRUEに設定されている場合、伝播のポジティブ・ルール・セットとネガティブ・ルール・セットが両方とも削除されます。このプロシージャによってルール・セットが削除された場合、そのルール・セット内のルールのうち、他のルール・セットに含まれていないルールも削除されます。

注意:
伝播を削除すると、その伝播が使用していた伝播ジョブは、他の伝播で使用されていないかぎり自動的に削除されます。

17 Oracle Streams情報コンシュームの管理

適用プロセスは、Oracle Streams環境で暗黙的に情報をコンシュームします。論理変更レコード(LCR)およびユーザー・メッセージを特定のキューからデキューして、各メッセージを直接適用するか、パラメータとしてユーザー定義プロシージャに渡します。

次の各項では、Oracle Streamsの適用プロセスの管理について説明します。

- 適用プロセスの起動

- 適用プロセスの停止

- 適用プロセスのルール・セットの管理

- 適用プロセス・パラメータの設定

- 適用プロセスの適用ユーザーの設定

- DMLハンドラの管理

- DDLハンドラの管理

- 適用プロセスのメッセージ・ハンドラの管理

- 適用プロセスのプリコミット・ハンドラの管理

- 適用プロセスによるメッセージのエンキューの指定

- 適用プロセスの実行ディレクティブの指定

- エラー・ハンドラの管理

- 適用エラーの管理

- 表の代替キー列の管理

- 仮想依存性定義の使用

- 適用プロセスの削除

この章で説明する各タスクは、特に明記されていないかぎり、適切な権限を付与されているOracle Streams管理者が完了する必要があります。

関連項目:

- 第4章「Oracle Streams情報コンシューム」

- 「Oracle Streams適用プロセスの監視」

- 第33章「適用のトラブルシューティング」

- Oracle Streams管理者を作成する方法の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- Enterprise Managerでの適用プロセスの管理の詳細は、Oracle Database 2日でデータ・レプリケーションおよび統合ガイドおよびEnterprise Managerのオンライン・ヘルプを参照

適用プロセスの起動

既存の適用プロセスを起動するには、DBMS_APPLY_ADMパッケージのSTART_APPLYプロシージャを実行します。たとえば、次のプロシージャでは適用プロセスstrm01_applyが起動されます。

BEGIN
DBMS_APPLY_ADM.START_APPLY(
apply_name => 'strm01_apply');
END;
/

関連項目:
Oracle Enterprise Managerを使用した適用プロセスの起動については、Oracle Database 2日でデータ・レプリケーションおよび統合ガイドを参照

適用プロセスの停止

既存の適用プロセスを停止するには、DBMS_APPLY_ADMパッケージのSTOP_APPLYプロシージャを実行します。たとえば、次のプロシージャでは適用プロセスstrm01_applyが停止されます。

BEGIN
DBMS_APPLY_ADM.STOP_APPLY(
apply_name => 'strm01_apply');
END;
/

関連項目:
Oracle Enterprise Managerでの適用プロセスの停止方法については、Oracle Database 2日でデータ・レプリケーションおよび統合ガイドを参照

適用プロセスのルール・セットの管理

この項では、次のタスクの実行手順を説明します。

- 適用プロセスのルール・セットの指定

- 適用プロセスのルール・セットへのルールの追加

- 適用プロセスのルール・セットからのルールの削除

- 適用プロセスのルール・セットの削除

関連項目:

- 第5章「Oracle Streamsでのルールの使用方法」

- 第11章「ルールの高度な概念」

適用プロセスのルール・セットの指定

適用プロセスには、1つのポジティブ・ルール・セットおよび1つのネガティブ・ルール・セットを指定できます。適用プロセスでは、メッセージは、ポジティブ・ルール・セットの少なくとも1つのルールについてTRUEと評価される場合は適用され、ネガティブ・ルール・セットの少なくとも1つのルールについてTRUEと評価される場合は廃棄されます。ネガティブ・ルール・セットは、ポジティブ・ルール・セットの前に評価されます。

適用プロセスのポジティブ・ルール・セットの指定

既存のルール・セットをポジティブ・ルール・セットとして既存の適用プロセスに指定するには、ALTER_APPLYプロシージャのrule_set_nameパラメータを使用します。このプロシージャは、DBMS_APPLY_ADMパッケージに含まれています。

たとえば、次のプロシージャでは、適用プロセスstrm01_applyのポジティブ・ルール・セットがstrm02_rule_setに設定されます。

BEGIN
DBMS_APPLY_ADM.ALTER_APPLY(
apply_name    => 'strm01_apply',
rule_set_name => 'strmadmin.strm02_rule_set');
END;
/

適用プロセスのネガティブ・ルール・セットの指定

既存のルールセットをネガティブ・ルール・セットとして既存の適用プロセスに指定するには、ALTER_APPLYプロシージャのnegative_rule_set_nameパラメータを使用します。このプロシージャは、DBMS_APPLY_ADMパッケージに含まれています。

たとえば、次のプロシージャでは、適用プロセスstrm01_applyのネガティブ・ルール・セットがstrm03_rule_setに設定されます。

BEGIN
DBMS_APPLY_ADM.ALTER_APPLY(
apply_name             => 'strm01_apply',
negative_rule_set_name => 'strmadmin.strm03_rule_set');
END;
/

適用プロセスのルール・セットへのルールの追加

適用プロセスのルール・セットにルールを追加するには、次のプロシージャのいずれかを実行します。

- 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プロシージャを実行して、適用プロセスstrm01_applyのポジティブ・ルール・セットにルールを追加します。

BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
table_name       => 'hr.departments',
streams_type     => 'apply',
streams_name     => 'strm01_apply',
queue_name       => 'streams_queue',
include_dml      => TRUE,
include_ddl      => TRUE,
source_database  => 'dbs1.example.com',
inclusion_rule   => TRUE);
END;
/

このプロシージャを実行すると、次のアクションが実行されます。

- ルールが1つ作成されます。このルールは、hr.departments表に対するDML変更の結果を含む行LCRについてTRUEと評価されます。ルール名はシステムによって生成されます。

- ルールが1つ作成されます。このルールは、hr.departments表に対するDDL変更を含むDDL LCRについてTRUEと評価されます。ルール名はシステムによって生成されます。

- どちらのルールも、dbs1.example.comソース・データベースで変更が発生したLCRに対してのみTRUEと評価されるように指定されます。

- inclusion_ruleパラメータがTRUEに設定されているため、そのルールは適用プロセスに関連付けられたポジティブ・ルール・セットに追加されます。

適用プロセスのネガティブ・ルール・セットへのルールの追加

次の例では、DBMS_STREAMS_ADMパッケージのADD_TABLE_RULESプロシージャを実行して、適用プロセスstrm01_applyのネガティブ・ルール・セットにルールを追加します。

BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
table_name       => 'hr.regions',
streams_type     => 'apply',
streams_name     => 'strm01_apply',
queue_name       => 'streams_queue',
include_dml      => TRUE,
include_ddl      => TRUE,
source_database  => 'dbs1.example.com',
inclusion_rule   => FALSE);
END;
/

このプロシージャを実行すると、次のアクションが実行されます。

- ルールが1つ作成されます。このルールは、hr.regions表に対するDML変更の結果を含む行LCRについてTRUEと評価されます。ルール名はシステムによって生成されます。

- ルールが1つ作成されます。このルールは、hr.regions表に対するDDL変更を含むDDL LCRについてTRUEと評価されます。ルール名はシステムによって生成されます。

- どちらのルールも、dbs1.example.comソース・データベース で変更が発生したLCRに対してのみ TRUEと評価されるように指定されます。

- inclusion_ruleパラメータがFALSEに設定されているため、そのルールは適用プロセスに関連付けられたネガティブ・ルール・セットに追加されます。

適用プロセスのルール・セットからのルールの削除

既存の適用プロセスのルール・セットからルールを削除するには、DBMS_STREAMS_ADMパッケージのREMOVE_RULEプロシージャを実行します。たとえば、次のプロシージャでは、適用プロセスstrm01_applyのポジティブ・ルール・セットからルールdepartments3が削除されます。

BEGIN
DBMS_STREAMS_ADM.REMOVE_RULE(
rule_name        => 'departments3',
streams_type     => 'apply',
streams_name     => 'strm01_apply',
drop_unused_rule => TRUE,
inclusion_rule   => TRUE);
END;
/

この例では、REMOVE_RULEプロシージャのdrop_unused_ruleパラメータがTRUEに設定されています。これはデフォルトの設定です。したがって、削除するルールが他のどのルール・セットにも含まれていなければ、そのルールはデータベースから削除されます。drop_unused_ruleパラメータがFALSEに設定されている場合、ルールはルール・セットから削除されますが、他のどのルール・セットにも含まれていない場合でも、データベースからは削除されません。

inclusion_ruleパラメータをFALSEに設定すると、REMOVE_RULEプロシージャによって、適用プロセスのポジティブ・ルール・セットからではなく、ネガティブ・ルール・セットからルールが削除されます。

適用プロセスのルール・セットからすべてのルールを削除するには、REMOVE_RULEプロシージャの実行時にrule_nameパラメータにNULLを指定します。

関連項目:
「Oracle Streamsクライアントに空のルール・セットが1つ以上存在する場合」

適用プロセスのルール・セットの削除

既存の適用プロセスから ルール・セットを削除するには、DBMS_APPLY_ADMパッケージのALTER_APPLYプロシージャを使用します。このプロシージャでは、ポジティブ・ルール・セットまたはネガティブ・ルール・セット、あるいはその両方を削除できます。適用プロセスのポジティブ・ルール・セットを削除するには、remove_rule_setパラメータにTRUEを設定します。適用プロセスのネガティブ・ルール・セットを削除するには、remove_negative_rule_setパラメータにTRUEを設定します。

たとえば、次のプロシージャでは、適用プロセスstrm01_applyからポジティブ・ルール・セットとネガティブルール・セットの両方が削除されます。

BEGIN
DBMS_APPLY_ADM.ALTER_APPLY(
apply_name               => 'strm01_apply',
remove_rule_set          => TRUE,
remove_negative_rule_set => TRUE);
END;
/

注意:
バッファ・キューからメッセージをデキューする適用プロセスに、ポジティブ・ルール・セットまたはネガティブ・ルール・セットがない場合、適用プロセスによって、キュー内のすべての取得LCRがデキューされます。同様に、永続キューからメッセージをデキューする適用プロセスに、ポジティブ・ルール・セットまたはネガティブ・ルール・セットがない場合も、適用プロセスによって、キュー内のすべての永続LCRおよび 永続ユーザー・メッセージがデキューされます。

適用プロセスのパラメータの設定

適用プロセス・パラメータを設定するには、DBMS_APPLY_ADMパッケージのSET_PARAMETERプロシージャを使用します。適用プロセス・パラメータによって、適用プロセスの動作が制御されます。

たとえば、次のプロシージャでは、適用プロセスstrm01_applyのcommit_serializationパラメータがDEPENDENT_TRANSACTIONSに設定されます。commit_serializationパラメータをこの値に設定にすると、適用プロセスはトランザクションを任意の順序でコミットできます。

BEGIN
DBMS_APPLY_ADM.SET_PARAMETER(
apply_name   => 'strm01_apply',
parameter    => 'commit_serialization',
value        => 'DEPENDENT_TRANSACTIONS');
END;
/

注意:

- valueパラメータは、パラメータ値が数値の場合にも、常にVARCHAR2値として入力されます。

- valueパラメータがNULLに設定されているか、または指定されていない場合、パラメータはデフォルト値に設定されます。

- parallelism適用プロセス・パラメータを1より大きい値に設定する場合は、適用プロセスで変更が適用される表のすべての一意キー列と外部キー列について、ソース・データベースに条件付きのサプリメンタル・ログ・グループを指定する必要があります。構成によっては、これらの表の他の列についても同様にサプリメンタル・ロギングが必要になる場合があります。

関連項目:

- 「適用プロセス・パラメータ」

- Oracle Enterprise Managerを使用した適用プロセス・パラメータの設定については、Oracle Database 2日でデータ・レプリケーションおよび統合ガイドを参照

- 適用プロセス・パラメータの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のDBMS_APPLY_ADM.SET_PARAMETERプロシージャに関する項を参照

- サプリメンタル・ロギングの指定の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

適用プロセスの適用ユーザーの設定

適用ユーザーは、適用プロセスのルール・セットを満たすすべてのDML変更およびDDL変更を適用し、ユーザー定義の適用ハンドラを実行するユーザーです。適用プロセスの適用ユーザーを設定するには、DBMS_APPLY_ADMパッケージのALTER_APPLYプロシージャでapply_userパラメータを使用します。

適用ユーザーを変更するには、ALTER_APPLYプロシージャを起動するユーザーにDBAロールが付与されている必要があります。SYSユーザーのみが、SYSにapply_userを設定できます。

たとえば、次のプロシージャでは、適用プロセスstrm03_applyの適用ユーザーがhrに設定されます。

BEGIN
DBMS_APPLY_ADM.ALTER_APPLY(
apply_name => 'strm03_apply',
apply_user => 'hr');
END;
/

このプロシージャを実行すると、新しい適用ユーザーに、適用プロセスで使用されるキューのデキュー権限が付与され、そのユーザーがキューの保護キュー・ユーザーとして構成されます。また、適用ユーザーが次の権限を持っていることを確認する必要があります。

- 適用オブジェクトに対してDML変更およびDDL変更を実行するための権限

- 適用プロセスで使用するルール・セットのEXECUTE権限

- ルール・セットで使用するすべてのカスタム・ルールベースの変換ファンクションのEXECUTE権限

- すべての適用ハンドラ・プロシージャのEXECUTE権限

これらの権限は、適用ユーザーに直接付与するか、ロールを介して付与できます。

また、適用ユーザーには、適用プロセスで実行されるサブプログラムで起動されるすべてのパッケージ(Oracle提供パッケージを含む)に対するEXECUTE権限を付与する必要があります。これらの権限は、適用ユーザーに直接付与する必要があります。これらの権限は、ロールを介して付与することはできません。

注意:
Oracle Database Vaultがインストールされている場合は、「Oracle StreamsおよびOracle Data Vault」に記載されている手順に従って、適切な権限やロールが付与されていることを確認してください。

DMLハンドラの管理

DMLハンドラは、適用プロセスによってデキューされた行論理変更レコード(行LCR)を処理します。DMLハンドラには2つのタイプがあります。文DMLハンドラとプロシージャDMLハンドラです。文DMLハンドラは、SQL文のコレクションを使用して行LCRを処理します。一方プロシージャDMLハンドラは、PL/SQLプロシージャを使用して行LCRを処理します。

この項では、DMLハンドラの管理手順について説明します。

- 文DMLハンドラの管理

- プロシージャDMLハンドラの管理

関連項目:
「適用プロセスのメッセージ処理オプション」

文DMLハンドラの管理

この項では、文DMLハンドラの次の管理手順について説明します。

- 文DMLハンドラの作成および適用プロセスへの追加

- 文DMLハンドラへの文の追加

- 文DMLハンドラ内の文の変更

- 文DMLハンドラからの文の削除

- 適用プロセスからの文DMLハンドラの削除

- 文DMLハンドラの削除

関連項目:

- 「文DMLハンドラ」

- 「文DMLハンドラに関する情報の表示」

文DMLハンドラの作成および適用プロセスへの追加

文DMLハンドラを作成して適用プロセスに追加するには、次の2とおりの方法があります。

- 1つ目は、文DMLハンドラの作成、1つの文の追加および適用プロセスへのその文DMLハンドラの追加をすべて1ステップで行う方法です。

- 2つ目は、文DMLハンドラの作成、1つ以上の文の追加および適用プロセスへのその文DMLハンドラの追加を個々のステップで行う方法です。

通常、文DMLハンドラに含まれる文が1つのみの場合には1ステップの方法が最適です。文DMLハンドラに複数の文が含まれる場合には複数ステップの方法が最適です。

次の各項では、それぞれの方法について詳しく説明する例を示します。

- 1つの文を含む文DMLハンドラの作成

- 1つ以上の文を含む文DMLハンドラの作成

1つの文を含む文DMLハンドラの作成

一部のOracle Streamsレプリケーション環境では、レプリケートされた表はその表を共有するデータベースでまったく同じではありません。このような環境では、文DMLハンドラによって、行LCRで実行されたDML変更が変更される可能性があります。文DMLハンドラでは行LCRの列値は変更できません。ただし、文DMLハンドラでSQLを使用し、行を挿入したり、行LCRの列値とは異なる列値で行を更新できます。

この項の例では、次のことを想定しています。

- Oracle Streamsレプリケーション環境は、ソース・データベースと宛先データベースとの間でoe.orders表に変更をレプリケートするように構成されています。oe.orders表への変更はソース・データベースで取得プロセスまたは同期取得によって取得され、伝播によって宛先データベースに送信されて、宛先データベースで適用プロセスによって適用されます。

- ソース・データベースでは、oe.orders表にorder_status列が含まれます。宛先データベースで1のorder_statusの挿入が適用されると、order_statusが2に変更されることが想定されます。この例では、文DMLハンドラによってこの変更が行われます。1ではないorder_statusが挿入されると、文DMLハンドラでは、order_status値を変更せずに行LCRの元の変更が適用されます。

oe.orders表への挿入を変更する文DMLハンドラを作成するには、次の手順を実行します。

1. この例のために、ソース・データベースで次のように必須のサプリメンタル・ロギングを指定します。

1. ソース・データベースにOracle Streams管理者として接続します。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

2. oe.orders表のorder_status列を含む無条件サプリメンタル・ログ・グループを次のように指定します。

ALTER TABLE oe.orders ADD SUPPLEMENTAL LOG GROUP log_group_ord_stat  (order_status) ALWAYS;

宛先データベースで文DMLハンドラによって使用されるすべての列は、ソース・データベースで無条件ログ・グループに存在している必要があります。

2. 宛先データベースにOracle Streams管理者として接続します。

3. 文DMLハンドラを作成して適用プロセスに追加します。

DECLARE
stmt CLOB;
BEGIN
stmt := 'INSERT INTO oe.orders(
order_id,
order_date,
order_mode,
customer_id,
order_status,
order_total,
sales_rep_id,
promotion_id)
VALUES(
:new.order_id,
:new.order_date,
:new.order_mode,
:new.customer_id,
DECODE(:new.order_status, 1, 2, :new.order_status),
:new.order_total,
:new.sales_rep_id,
:new.promotion_id)';
DBMS_APPLY_ADM.ADD_STMT_HANDLER(
object_name        => 'oe.orders',
operation_name     => 'INSERT',
handler_name       => 'modify_orders',
statement          => stmt,
apply_name         => 'apply$_sta_2',
comment            => 'Modifies inserts into the orders table');
END;
/

DECODEファンクションによってorder_statusが1から2に変更されることに注意してください。行LCRのorder_statusが1でない場合、DECODEファンクションでデフォルトに:new.order_statusを指定することにより、DECODEファンクションでは元のorder_status値が使用されます。

ADD_STMT_HANDLERプロシージャによって、modify_orders文DMLハンドラが作成されてapply$_sta_2適用プロセスに追加されます。文DMLハンドラは、oe.orders表への挿入を実行する行LCRがこの適用プロセスによってデキューされるときに起動されます。この表に対して行われる更新や削除を実行する行LCRを変更するには、個別の文DMLハンドラが必要となります。

注意:

- modify_orders文DMLハンドラのこの文により、宛先の表に対する行変更が実行されます。したがって、文DMLハンドラに実行文を追加する必要はありません。この文によって実行される行変更は、適用プロセスによって行LCRのトランザクションに対するコミット・ディレクティブがデキューされるときにコミットされます。

- この例では、ADD_STMT_HANDLERプロシージャによって文DMLハンドラがapply$_sta_2適用プロセスに追加されます。データベース内のすべての適用プロセスによって使用される汎用文DMLハンドラを追加するには、このプロシージャのapply_nameパラメータを省略するか、またはapply_nameパラメータをNULLに設定します。

1つ以上の文を含む文DMLハンドラの作成

文DMLハンドラを使用すると、表に対して行われた変更を追跡できます。この例では、文DMLハンドラによってhr.jobs表に対して行われた更新が追跡されます。

この項の例では、次のことを想定しています。

- Oracle Streamsレプリケーション環境は、ソース・データベースと宛先データベースとの間でhr.jobs表に変更をレプリケートするように構成されています。hr.jobs表への変更はソース・データベースで取得プロセスまたは同期取得によって取得され、伝播によって宛先データベースに送信されて、宛先データベースで適用プロセスによって適用されます。hr.jobs表には、ある組織の様々な役職に対する最小および最大の給与が含まれます。

- 給与情報に対する更新およびこれらの更新がいつ行われたかを追跡することが目的です。この目的のために、文DMLハンドラによってhr.track_jobs表に行が挿入されます。

- hr.jobs表に変更をレプリケートするには、適用プロセスで行LCRを実行する必要もあります。

hr.jobsに対する更新を追跡する文DMLハンドラを作成するには、次の手順を実行します。

1. ソース・データベースにOracle Streams管理者として接続します。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

2. hr.jobs表のすべての列を含む無条件サプリメンタル・ログ・グループを指定します。次に例を示します。

ALTER TABLE hr.jobs ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;

宛先データベースで文DMLハンドラによって使用されるすべての列は、ソース・データベースで無条件ログ・グループに存在している必要があります。

3. 宛先データベースにhrユーザーとして接続します。

4. 追跡表の順序を次のように作成します。

CREATE SEQUENCE hr.track_jobs_seq
START WITH 1
INCREMENT BY 1;

5. hr.jobs表に対する変更を追跡する表を次のように作成します。

CREATE TABLE hr.track_jobs(
change_id       NUMBER  CONSTRAINT track_jobs_pk PRIMARY KEY,
job_id          VARCHAR2(10),
job_title       VARCHAR2(35),
min_salary_old  NUMBER(6),
min_salary_new  NUMBER(6),
max_salary_old  NUMBER(6),
max_salary_new  NUMBER(6),
timestamp       TIMESTAMP);

文DMLハンドラは、手順4で作成した順序を使用して、追跡した変更ごとにhr.track_jobs表のchange_id列に一意の値を挿入します。

6. 宛先データベースにOracle Streams管理者として接続します。

7. 文DMLハンドラを次のように作成します。

BEGIN
DBMS_STREAMS_HANDLER_ADM.CREATE_STMT_HANDLER(
handler_name => 'track_jobs',
comment      => 'Tracks updates to the jobs table');
END;
/

8. 行LCRを実行する文DMLハンドラに、次のように文を追加します。

DECLARE
stmt CLOB;
BEGIN
stmt := ':lcr.execute TRUE';
DBMS_STREAMS_HANDLER_ADM.ADD_STMT_TO_HANDLER(
handler_name       => 'track_jobs',
statement          => stmt,
execution_sequence => 10);
END;
/

TRUE引数は、LCR$_ROW_RECORDタイプのEXECUTEメンバー・プロシージャのconflict_resolutionパラメータに対して使用されます。TRUE引数は、行LCRの実行時に、表に対して定義された任意の競合解決が使用されることを示します。行LCRの実行時に競合解決を使用しない場合は、FALSEを指定します。

ヒント:
表に対する変更を追跡するがレプリケートは行わない場合は、文DMLハンドラに実行文を含めません。

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

9. 行LCRへの変更を追跡する文DMLハンドラに、次のように文を追加します。

DECLARE
stmt CLOB;
BEGIN
stmt := 'INSERT INTO hr.track_jobs(
change_id,
job_id,
job_title,
min_salary_old,
min_salary_new,
max_salary_old,
max_salary_new,
timestamp)
VALUES(
hr.track_jobs_seq.NEXTVAL,
:new.job_id,
:new.job_title,
:old.min_salary,
:new.min_salary,
:old.max_salary,
:new.max_salary,
:source_time)';
DBMS_STREAMS_HANDLER_ADM.ADD_STMT_TO_HANDLER(
handler_name       => 'track_jobs',
statement          => stmt,
execution_sequence => 20);
END;
/

この文により、hr.jobs表の行を更新する各行LCRに対して、hr.track_jobs表に行が挿入されます。hr.track_jobs表に挿入される値には、給与列ごとの古い値と新しい値を追跡するために行LCRの古い値と新しい値が使用されることに注意してください。また、行LCRのsource_time属性はtimestamp列を移入するために使用されます。

10. 文DMLハンドラを適用プロセスに追加します。たとえば、次のプロシージャを使用すると、文DMLハンドラが適用プロセスapply$_sta_2に追加されます。

BEGIN
DBMS_APPLY_ADM.ADD_STMT_HANDLER(
object_name    => 'hr.jobs',
operation_name => 'UPDATE',
handler_name   => 'track_jobs',
apply_name     => 'apply$_sta_2');
END;
/

注意:
この例では、ADD_STMT_HANDLERプロシージャによって文DMLハンドラがapply$_sta_2適用プロセスに追加されます。データベース内のすべての適用プロセスによって使用される汎用文DMLハンドラを追加するには、このプロシージャのapply_nameパラメータを省略するか、またはapply_nameパラメータをNULLに設定します。

文DMLハンドラへの文の追加

文DMLハンドラに文を追加するには、DBMS_STREAMS_HANDLER_ADMパッケージのADD_STMT_TO_HANDLERプロシージャを実行して、文DMLハンドラに対してまだ指定されていない実行順序番号を指定します。

この項の例では、modify_orders文DMLハンドラに文を追加します。この文DMLハンドラは「1つの文を含む文DMLハンドラの作成」で作成したものです。この文により、oe.orders表への挿入が変更されます。

この項の例では、宛先データベースで特定の顧客に対して注文の10%を割引するとします。oe.orders表でのこの顧客のcustomer_id値は118です。この場合、文DMLハンドラのSQL文を使用して、customer_id値が118のoe.orders表への挿入について、order_total値に.9を乗算します。

modify_orders文DMLハンドラに文を追加するには、次の手順を実行します。

1. 適用プロセスが構成されている宛先データベースに、Oracle Streams管理者として接続します。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

2. 文DMLハンドラの文によってすでに使用されている実行順序番号を次のようにチェックします。

COLUMN HANDLER_NAME HEADING 'Statement|Handler' FORMAT A15
COLUMN EXECUTION_SEQUENCE HEADING 'Execution|Sequence' FORMAT 999999
COLUMN STATEMENT HEADING 'Statement' FORMAT A50

SET LONG  8000
SET PAGES 8000
SELECT HANDLER_NAME,
EXECUTION_SEQUENCE,
STATEMENT
FROM DBA_STREAMS_STMTS
WHERE HANDLER_NAME = 'MODIFY_ORDERS'
ORDER BY EXECUTION_SEQUENCE;

出力は次のようになります。

Statement       Execution
Handler          Sequence Statement
--------------- --------- --------------------------------------------------
MODIFY_ORDERS           1 INSERT INTO oe.orders(
order_id,
order_date,
order_mode,
customer_id,
order_status,
order_total,
sales_rep_id,
promotion_id)
VALUES(
:new.order_id,
:new.order_date,
:new.order_mode,
:new.customer_id,
DECODE(:new.order_status, 1, 2, :new.
order_status),
:new.order_total,
:new.sales_rep_id,
:new.promotion_id)

この出力は、文DMLハンドラに含まれる文が1つのみであり、この1つの文の実行順序番号が1であることを示しています。

3. 文DMLハンドラにすべての注文を10%割引する文を次のように追加します。

DECLARE
stmt CLOB;
BEGIN
stmt := 'UPDATE oe.orders SET order_total=order_total*.9
WHERE order_id=:new.order_id AND :new.customer_id=118';
DBMS_STREAMS_HANDLER_ADM.ADD_STMT_TO_HANDLER(
handler_name       => 'modify_orders',
statement          => stmt,
execution_sequence => 10);
END;
/

この文により、実行順序番号が1の文によって挿入された行が更新されます。したがって、この文の実行順序番号は1より大きい値である必要があります。この例では、追加された文の実行順序番号に10を指定しています。

ヒント:
ADD_STMT_TO_HANDLERプロシージャでexecution_sequenceパラメータがNULLに設定されている場合、この文は、文DMLハンドラ内のどの文の実行順序番号よりも大きい実行順序番号で文DMLハンドラに追加されます。したがって、この例では、execution_sequenceパラメータを省略するか、またはNULLに設定できます。

これらの手順を完了した後、手順2の問合せに対する出力は次のようになります。

Statement       Execution
Handler          Sequence Statement
--------------- --------- --------------------------------------------------
MODIFY_ORDERS           1 INSERT INTO oe.orders(
order_id,
order_date,
order_mode,
customer_id,
order_status,
order_total,
sales_rep_id,
promotion_id)
VALUES(
:new.order_id,
:new.order_date,
:new.order_mode,
:new.customer_id,
DECODE(:new.order_status, 1, 2, :new.
order_status),
:new.order_total,
:new.sales_rep_id,
:new.promotion_id)

MODIFY_ORDERS          10 UPDATE oe.orders SET order_total=order_total*.9
WHERE order_id=:new.order_id AND :new.
customer_id=118

この出力は、実行順序番号が10の新しい文が文DMLハンドラに追加されていることを示しています。

文DMLハンドラ内の文の変更

文DMLハンドラ内の文を変更するには、DBMS_STREAMS_HANDLER_ADMパッケージのADD_STMT_TO_HANDLERプロシージャを実行し、変更する文の実行順序番号を指定します。

この項の例では、track_jobs文DMLハンドラの実行順序番号が20の文が変更されます。この文DMLハンドラは「1つ以上の文を含む文DMLハンドラの作成」で作成したものです。これにより、hr.track_jobs表を使用してhr.jobs表への変更が追跡されます。

この項の例では、hr.jobs表を更新したユーザーも追跡するとします。この場合、ソース・データベースで取得された行LCRにこの情報を追加して、user_name列をhr.track_jobs表に追加し、ユーザーを追跡するように文DMLハンドラ内の文を変更します。

文DMLハンドラ内の文を変更するには、次の手順を実行します。

1. ソース・データベースにOracle Streams管理者として接続します。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

2. ソース・データベースで取得された行LCR情報に、次のようにユーザー名を追加します。

BEGIN
DBMS_CAPTURE_ADM.INCLUDE_EXTRA_ATTRIBUTE(
capture_name   => 'sta$cap',
attribute_name => 'username',
include        => TRUE);
END;
/

capture_nameパラメータで、文DMLハンドラによって処理される変更を取得する取得プロセスまたは同期取得を指定します。

3. 宛先データベースにOracle Streams管理者として接続します。

4. user_name列をhr.track_jobs表に次のように追加します。

ALTER TABLE hr.track_jobs
ADD (user_name VARCHAR2(30));

5. track_jobs文DMLハンドラの実行順序番号が20の文を次のように変更します。

DECLARE
stmt CLOB;
BEGIN
stmt := 'INSERT INTO hr.track_jobs(
change_id,
job_id,
job_title,
min_salary_old,
min_salary_new,
max_salary_old,
max_salary_new,
timestamp,
user_name)
VALUES(
hr.track_jobs_seq.NEXTVAL,
:new.job_id,
:new.job_title,
:old.min_salary,
:new.min_salary,
:old.max_salary,
:new.max_salary,
:source_time,
:extra_attribute.username)';
DBMS_STREAMS_HANDLER_ADM.ADD_STMT_TO_HANDLER(
handler_name       => 'track_jobs',
statement          => stmt,
execution_sequence => 20);
END;
/

変更した文により、行LCRのusername情報をhr.track_jobs表のuser_name列に挿入して、ユーザー追跡を追加します。usernameは追加のLCR属性であり、次の構文を使用して指定する必要があることに注意してください。

:extra_attribute.username

関連項目:
「LCRのその他の情報」

文DMLハンドラからの文の削除

文DMLハンドラから文を削除するには、DBMS_STREAMS_HANDLER_ADMパッケージのREMOVE_STMT_FROM_HANDLERプロシージャを実行し、削除する文の実行順序番号を指定します。

この項の例では、track_jobs文DMLハンドラから実行順序番号が10の文が削除されます。この文DMLハンドラは「1つ以上の文を含む文DMLハンドラの作成」で作成したものです。これにより、hr.track_jobs表を使用してhr.jobs表への変更が追跡されます。

この項の例では、hr.jobs表に対する更新を含む行LCRの実行が不要になったことを想定しています。この場合、この行LCRを実行する文を削除する必要があり、track_jobs文DMLハンドラでのこの文の実行順序番号は10です。

文DMLハンドラから文を削除するには、次の手順を実行します。

1. 文DMLハンドラを含むデータベースにOracle Streams管理者として接続します。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

2. 文DMLハンドラから、文を次のように削除します。

BEGIN
DBMS_STREAMS_HANDLER_ADM.REMOVE_STMT_FROM_HANDLER(
handler_name       => 'track_jobs',
execution_sequence => 10);
END;
/

適用プロセスからの文DMLハンドラの削除

適用プロセスから文DMLハンドラを削除するには、DBMS_APPLY_ADMパッケージのREMOVE_STMT_HANDLERプロシージャを実行します。

この項の例では、apply$_sta_2適用プロセスからtrack_jobs文DMLハンドラが削除されます。この文DMLハンドラは「1つ以上の文を含む文DMLハンドラの作成」で作成したものです。これにより、hr.track_jobs表を使用してhr.jobs表への変更が追跡されます。

適用プロセスから文DMLハンドラを削除するには、次の手順を実行します。

1. 適用プロセスが使用されるデータベースにOracle Streams管理者として接続します。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

2. 適用プロセスから次のように文DMLハンドラを削除します。

BEGIN
DBMS_APPLY_ADM.REMOVE_STMT_HANDLER(
object_name    => 'hr.jobs',
operation_name => 'UPDATE',
handler_name   => 'track_jobs',
apply_name     => 'apply$_sta_2');
END;
/

文DMLハンドラは、適用プロセスから削除した後でもデータベースには存在します。

文DMLハンドラの削除

データベースから文DMLハンドラを削除するには、DBMS_STREAMS_HANDLER_ADMパッケージのDROP_STMT_HANDLERプロシージャを実行します。

この項の例では、track_jobs文DMLハンドラが削除されます。この文DMLハンドラは「1つ以上の文を含む文DMLハンドラの作成」で作成したものです。これにより、hr.track_jobs表を使用してhr.jobs表への変更が追跡されます。

文DMLハンドラを削除するには、次の手順を実行します。

1. 文DMLハンドラを含むデータベースにOracle Streams管理者として接続します。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

2. 文DMLハンドラを次のように削除します。

exec DBMS_STREAMS_HANDLER_ADM.DROP_STMT_HANDLER('track_jobs');

プロシージャDMLハンドラの管理

この項では、プロシージャDMLハンドラの次の管理手順について説明します。

- プロシージャDMLハンドラの作成

- プロシージャDMLハンドラの設定

- プロシージャDMLハンドラの設定解除

関連項目:

- 「プロシージャDMLハンドラ」

- 「DMLハンドラに関する情報の表示」

プロシージャDMLハンドラの作成

プロシージャDMLハンドラには、次のシグネチャが必要です。

PROCEDURE user_procedure (
parameter_name   IN  ANYDATA);

ここで、user_procedureはプロシージャの名前、parameter_nameはプロシージャに渡されるパラメータの名前です。プロシージャに渡されるパラメータは、行論理変更レコード(行LCR)をANYDATAにカプセル化したものです。

ユーザー・プロシージャには次の制限事項が適用されます。

- COMMIT文またはROLLBACK文を実行しないでください。実行すると、行LCRを含むトランザクションの一貫性が失われる危険性があります。

- 行LCR用のEXECUTEメンバー・プロシージャを使用して行を操作している場合は、1つの行操作で複数の行を操作しないでください。複数行を操作する任意のDML文を手動で作成して実行する必要があります。

- コマンド・タイプがUPDATEまたはDELETEの場合、LCRに対してEXECUTEメンバー・プロシージャを使用して再実行される行操作では、以前の値リストにキー全体が含まれている必要があります。キーは、代替キーがSET_KEY_COLUMNSプロシージャによって指定されていないかぎり、少なくとも1つのNOT NULL列を含む主キーまたは最小の一意キーとなります。キーが指定されていない場合、キーはすべての表の列で構成されますが、LOB、LONG、LONG RAWの各データ型、ユーザー定義型(オブジェクト型、REF、VARRAY、ネストした表など)およびOracle提供の型(Any型、XML型、空間型、メディア型など)の列は除外されます。

- コマンド・タイプがINSERTの場合、LCR用のEXECUTEメンバー・プロシージャを使用して再発行された行操作には、新しい値のリストのキー全体が含まれる必要があります。含まれないと重複行が生じる可能性があります。キーは、代替キーがSET_KEY_COLUMNSプロシージャによって指定されていないかぎり、少なくとも1つのNOT NULL列を含む主キーまたは最小の一意キーとなります。キーが指定されていない場合、キーは非LOB、非LONGおよび非LONG RAW列のすべてで構成されます。

プロシージャDMLハンドラは、行LCRの任意のカスタム処理に使用できます。たとえば、ハンドラでLCRを変更してから、そのLCRに対するEXECUTEメンバー・プロシージャを使用してLCRを実行することができます。プロシージャDMLハンドラで行LCRを実行すると、適用プロセスはプロシージャDMLハンドラを再度呼び出すことなくLCRを適用します。

プロシージャDMLハンドラでSQL生成を使用して、表に対して行われるDML変更を記録することもできます。これらの変更は、表かファイルに記録できます。たとえば、この項のサンプル・プロシージャDMLハンドラでは、SQL生成を使用し、GET_ROW_TEXTメンバー・プロシージャによりhr.departments表に対して実行された各UPDATE SQL文を記録します。プロシージャDMLハンドラによって、EXECUTEメンバー・プロシージャを使用して行LCRも適用されます。

このプロシージャDMLハンドラで使用されるプロシージャを作成するには、次の手順を実行します。

1. SQL*Plusで、データベースにOracle Streams管理者として接続します。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

2. テキスト・ファイルが含まれるディレクトリに対してディレクトリ・オブジェクトを作成します。

この例では、hr.departments表に対して実行されたUPDATE SQL文が、適用プロセスによってこのディレクトリのテキスト・ファイルに書き込まれます。

たとえば、/usr/sql_genディレクトリに対してSQL_GEN_DIRというディレクトリ・オブジェクトを作成するには、次のSQL文を入力します。

CREATE DIRECTORY SQL_GEN_DIR AS '/usr/sql_gen';

3. SQL文が書き込まれるテキスト・ファイルが、手順2で指定したディレクトリに存在することを確認します。
この例では、sql_gen_file.txtファイルがファイル・システムの/usr/sql_genディレクトリに存在することを確認します。

4. プロシージャDMLハンドラに対して、次のようにプロシージャを作成します。

CREATE OR REPLACE PROCEDURE strmadmin.sql_gen_dep(lcr_anydata IN SYS.ANYDATA) IS
lcr          SYS.LCR$_ROW_RECORD;
int          PLS_INTEGER;
row_txt_clob CLOB;
fp           UTL_FILE.FILE_TYPE;
BEGIN
int   := lcr_anydata.GETOBJECT(lcr);
DBMS_LOB.CREATETEMPORARY(row_txt_clob, TRUE);
-- Generate SQL from row LCR and save to file
lcr.GET_ROW_TEXT(row_txt_clob);
fp := UTL_FILE.FOPEN (
location     => 'SQL_GEN_DIR',
filename     => 'sql_gen_file.txt',
open_mode    => 'a',
max_linesize => 5000);
UTL_FILE.PUT_LINE(
file      => fp,
buffer    => row_txt_clob,
autoflush => TRUE);
DBMS_LOB.TRIM(row_txt_clob, 0);
UTL_FILE.FCLOSE(fp);
--  Apply row LCR
lcr.EXECUTE(TRUE);
END;
/

プロシージャを作成した後、「プロシージャDMLハンドラの設定」の手順に従って、作成したプロシージャをプロシージャDMLハンドラとして設定できます。

注意:

- 宛先データベースでプロシージャDMLハンドラが必要とする任意の列に対して、ソース・データベースで無条件サプリメンタル・ログ・グループを指定する必要があります。このサンプル・プロシージャDMLハンドラではSQL文が記録され、その他の方法で行LCRが操作されることはないため、このサンプル・プロシージャDMLハンドラに追加のサプリメンタル・ロギングは必要ありません。

- プロシージャDMLハンドラを使用前にテストしたり、プロシージャDMLハンドラをデバッグするために、行LCRを作成し、適用プロセスのコンテキスト外でプロシージャDMLハンドラのプロシージャを実行できます。

関連項目:

- 「SQL生成」

- GET_ROW_TEXT行LCRメンバー・ファンクションの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

- 「Oracle Streams環境内のサプリメンタル・ロギング」

- 『Oracle Streamsレプリケーション管理者ガイド』

- プロシージャDMLハンドラで処理する可能性のある一般的な適用エラーの詳細は、「エラー・キューに適用エラーがあるか」を参照

- データ型の詳細は、『Oracle Database SQL言語リファレンス』を参照

プロシージャDMLハンドラの設定

プロシージャDMLハンドラにより、特定の表に対する特定の操作を含む任意の適用プロセスによってデキューされた各行LCRが処理されます。表に対する様々な操作を処理するために、同じ表で複数のプロシージャDMLハンドラを指定できます。ローカル・データベース内の指定した表に変更を適用するすべての適用プロセスでは、指定したプロシージャDMLハンドラが使用されます。

DBMS_APPLY_ADMパッケージのSET_DML_HANDLERプロシージャを使用して、プロシージャDMLハンドラを設定します。たとえば、次のプロシージャでは、hr.departments表に対するUPDATE操作用のプロシージャDMLハンドラを設定します。したがって、変更をローカルに適用する任意の適用プロセスがhr.departments表に対するUPDATE操作を含む行LCRをデキューすると、適用プロセスは行LCRをstrmadminスキーマのsql_gen_dep PL/SQLプロシージャに処理用に送信します。適用プロセスでは、このような変更を含む行LCRを直接適用することはありません。

この例では、apply_nameパラメータがNULLに設定されています。したがって、プロシージャDMLハンドラは、データベース内のすべての適用プロセスによって使用される汎用プロシージャDMLハンドラです。

BEGIN
DBMS_APPLY_ADM.SET_DML_HANDLER(
object_name         => 'hr.departments',
object_type         => 'TABLE',
operation_name      => 'UPDATE',
error_handler       => FALSE,
user_procedure      => 'strmadmin.sql_gen_dep',
apply_database_link => NULL,
apply_name          => NULL);
END;
/

注意:

- プロシージャDMLハンドラを1つの適用プロセスに対してのみ指定するには、適用プロセスの名前をapply_nameパラメータで指定します。

- 適用プロセスによってOracle以外のリモート・データベースに変更が適用される場合、この適用プロセスでは、同じ表に対して別のプロシージャDMLハンドラを使用できます。DBMS_APPLY_ADMパッケージのSET_DML_HANDLERプロシージャを実行して、apply_database_linkパラメータをNULL以外の値に設定することにより、Oracle以外のリモート・データベースに適用される変更に対してプロシージャDMLハンドラを指定できます。

- operation_nameパラメータにDEFAULTを指定して、プロシージャをデータベース・オブジェクトのデフォルトのプロシージャDMLハンドラとして設定できます。この場合、データベース・オブジェクトに対する操作に別のプロシージャDMLハンドラが明確に設定されているのでなければ、データベース・オブジェクトに対するINSERT、UPDATE、DELETEおよびLOB_WRITEのすべてにこのプロシージャDMLハンドラが使用されます。

関連項目:
『Oracle Streamsレプリケーション管理者ガイド』

プロシージャDMLハンドラの設定解除

プロシージャDMLハンドラの設定を解除するには、DBMS_APPLY_ADMパッケージのSET_DML_HANDLERプロシージャを使用します。このプロシージャを実行するときに、特定の表に対する特定の操作について、user_procedureパラメータをNULLに設定します。プロシージャDMLハンドラの設定を解除した後、変更をローカルに適用する任意の適用プロセスで、このような変更を含む行LCRが直接適用されるようになります。

たとえば、次のプロシージャでは、hr.departments表に対するUPDATE操作について、プロシージャDMLハンドラの設定が解除されます。

BEGIN
DBMS_APPLY_ADM.SET_DML_HANDLER(
object_name    => 'hr.departments',
object_type    => 'TABLE',
operation_name => 'UPDATE',
error_handler  => FALSE,
user_procedure => NULL,
apply_name     => NULL);
END;
/

DDLハンドラの管理

この項では、適用プロセスのDDLハンドラの作成、指定および削除の手順について説明します。

注意:
すべての適用済DDL LCRは、自動的にコミットされます。したがって、DDLハンドラがDDL LCRのEXECUTEメンバー・プロシージャをコールすると、自動的にコミットが実行されます。

関連項目:

- 「適用プロセスのメッセージ処理オプション」

- LCRタイプのEXECUTEメンバー・プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

適用プロセスのDDLハンドラの作成

DDLハンドラには、次のシグネチャが必要です。

PROCEDURE handler_procedure (
parameter_name   IN  ANYDATA);

ここで、handler_procedureはプロシージャの名前、parameter_nameはプロシージャに渡されるパラメータの名前です。プロシージャに渡されるパラメータは、DDL LCRをANYDATAにカプセル化したものです。

DDLハンドラは、DDL LCRの任意のカスタム処理に使用できます。たとえば、ハンドラでLCRを変更してから、そのLCRに対するEXECUTEメンバー・プロシージャを使用してLCRを実行できます。DDLハンドラでDDL LCRを実行すると、適用プロセスはDDLハンドラを再度呼び出すことなくLCRを適用します。

また、DDLハンドラを使用してDDL変更の履歴を記録することもできます。たとえば、DDLハンドラを使用すると、DDLハンドラで処理したLCRに関する情報を表に挿入してから、EXECUTEメンバー・プロシージャを使用してLCRを適用できます。

このようなDDLハンドラを作成するには、最初に、履歴情報を保持するための表を次のように作成します。

CREATE TABLE strmadmin.history_ddl_lcrs(
timestamp             DATE,
source_database_name  VARCHAR2(128),
command_type          VARCHAR2(30),
object_owner          VARCHAR2(32),
object_name           VARCHAR2(32),
object_type           VARCHAR2(18),
ddl_text              CLOB,
logon_user            VARCHAR2(32),
current_schema        VARCHAR2(32),
base_table_owner      VARCHAR2(32),
base_table_name       VARCHAR2(32),
tag                   RAW(10),
transaction_id        VARCHAR2(10),
scn                   NUMBER);

CREATE OR REPLACE PROCEDURE history_ddl(in_any IN ANYDATA)
IS
lcr       SYS.LCR$_DDL_RECORD;
rc        PLS_INTEGER;
ddl_text  CLOB;
BEGIN
-- Access the LCR
rc := in_any.GETOBJECT(lcr);
DBMS_LOB.CREATETEMPORARY(ddl_text, TRUE);
lcr.GET_DDL_TEXT(ddl_text);
--  Insert DDL LCR information into history_ddl_lcrs table
INSERT INTO strmadmin.history_ddl_lcrs VALUES(
SYSDATE, lcr.GET_SOURCE_DATABASE_NAME(), lcr.GET_COMMAND_TYPE(),
lcr.GET_OBJECT_OWNER(), lcr.GET_OBJECT_NAME(), lcr.GET_OBJECT_TYPE(),
ddl_text, lcr.GET_LOGON_USER(), lcr.GET_CURRENT_SCHEMA(),
lcr.GET_BASE_TABLE_OWNER(), lcr.GET_BASE_TABLE_NAME(), lcr.GET_TAG(),
lcr.GET_TRANSACTION_ID(), lcr.GET_SCN());
--  Apply DDL LCR
lcr.EXECUTE();
-- Free temporary LOB space
DBMS_LOB.FREETEMPORARY(ddl_text);
END;
/

適用プロセスのDDLハンドラの設定

DDLハンドラによって、適用プロセスでデキューされたすべてのDDL LCRが処理されます。適用プロセスのDDLハンドラを設定するには、DBMS_APPLY_ADMパッケージのALTER_APPLYプロシージャでddl_handlerパラメータを使用します。たとえば、次のプロシージャでは、適用プロセスstrep01_applyのDDLハンドラがstrmadminスキーマ内のhistory_ddlプロシージャに設定されます。

BEGIN
DBMS_APPLY_ADM.ALTER_APPLY(
apply_name  => 'strep01_apply',
ddl_handler => 'strmadmin.history_ddl');
END;
/

適用プロセスのDDLハンドラの削除

DDLハンドラによって、適用プロセスでデキューされたすべてのDDL LCRが処理されます。適用プロセスのDDLハンドラを削除するには、DBMS_APPLY_ADMパッケージのALTER_APPLYプロシージャでremove_ddl_handlerパラメータをTRUEに設定します。たとえば、次のプロシージャでは、適用プロセスstrep01_applyからDDLハンドラが削除されます。

BEGIN
DBMS_APPLY_ADM.ALTER_APPLY(
apply_name         => 'strep01_apply',
remove_ddl_handler => TRUE);
END;
/

適用プロセスのメッセージ・ハンドラの管理

メッセージ・ハンドラは、永続ユーザー・メッセージを処理する適用ハンドラです。次の各項では、適用プロセスにメッセージ・ハンドラを設定または設定解除する手順について説明します。

- 適用プロセスのメッセージ・ハンドラの設定

- 適用プロセスのメッセージ・ハンドラの設定解除

関連項目:

- 「適用プロセスで処理できるメッセージのタイプ」

- 「メッセージ・ハンドラ」

- メッセージ・ハンドラの作成例については、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドを参照してください。

適用プロセスのメッセージ・ハンドラの設定

適用プロセスのメッセージ・ハンドラを設定するには、DBMS_APPLY_ADMパッケージのALTER_APPLYプロシージャでmessage_handlerパラメータを使用します。たとえば、次のプロシージャでは、適用プロセスstrm03_applyのメッセージ・ハンドラがoeスキーマ内のmes_handlerプロシージャに設定されます。

BEGIN
DBMS_APPLY_ADM.ALTER_APPLY(
apply_name      => 'strm03_apply',
message_handler => 'oe.mes_handler');
END;
/

ALTER_APPLYプロシージャを実行するユーザーは、指定したメッセージ・ハンドラのEXECUTE権限を持っている必要があります。メッセージ・ハンドラが適用プロセスにすでに設定されている場合は、ALTER_APPLYプロシージャを実行して、適用プロセスのメッセージ・ハンドラを変更できます。

適用プロセスのメッセージ・ハンドラの設定解除

適用プロセスのメッセージ・ハンドラを設定解除するには、DBMS_APPLY_ADMパッケージのALTER_APPLYプロシージャでremove_message_handlerパラメータをTRUEに設定します。たとえば、次のプロシージャでは、適用プロセスstrm03_applyのメッセージ・ハンドラの設定が解除されます。

BEGIN
DBMS_APPLY_ADM.ALTER_APPLY(
apply_name             => 'strm03_apply',
remove_message_handler => TRUE);
END;
/

適用プロセスのプリコミット・ハンドラの管理

プリコミット・ハンドラは、トランザクションのコミット情報を受信し、カスタマイズした方法でコミット情報を処理できる適用ハンドラです。

次の各項では、適用プロセスのプリコミット・ハンドラの作成、設定および設定解除の手順について説明します。

- 適用プロセスのプリコミット・ハンドラの作成

- 適用プロセスのプリコミット・ハンドラの設定

- 適用プロセスのプリコミット・ハンドラの設定解除

適用プロセスのプリコミット・ハンドラの作成

プリコミット・ハンドラには、次のシグネチャが必要です。

PROCEDURE handler_procedure (
parameter_name   IN  NUMBER);

ここで、handler_procedureはプロシージャの名前、parameter_nameはプロシージャに渡されるパラメータの名前です。プロシージャに渡されるパラメータは、適用プロセスで使用されるキューに含まれる内部コミット・ディレクティブのコミットSCNです。

プリコミット・ハンドラを使用すると、適用プロセスによって処理されたコミットの情報を記録できます。適用プロセスでは、取得LCR、永続LCRまたは永続ユーザー・メッセージを適用できます。取得された行LCRの場合は、コミット・ディレクティブに、ソース・データベースからのトランザクションのコミットSCNが含まれます。永続LCRおよび永続ユーザー・メッセージの場合、コミットSCNは適用プロセスによって生成されます。

プリコミット・ハンドラ・プロシージャは、次の制限に従う必要があります。

- コミットする作業は、自律型トランザクションである必要があります。

- プロシージャで作成された指定のセーブ・ポイントまでロールバックする必要があります。

プリコミット・ハンドラで例外が発生した場合、適用トランザクション全体がロールバックされ、トランザクション内のすべてのメッセージがエラー・キューに移動されます。

たとえば、プリコミット・ハンドラは、適用プロセスによって適用された行LCRの監査に使用できます。このようなプリコミット・ハンドラを1つ以上の個別のプロシージャDMLハンドラとともに使用し、トランザクションのソース・データベースのコミットSCNを監査表に記録し、適用プロセスがトランザクションを適用する時間を監査表に記録する場合もあります。

特に、この例では、次の表の行LCRに関する情報を記録するプロシージャDMLハンドラとともに使用されるプリコミット・ハンドラが作成されます。

CREATE TABLE strmadmin.history_row_lcrs(
timestamp             DATE,
source_database_name  VARCHAR2(128),
command_type          VARCHAR2(30),
object_owner          VARCHAR2(32),
object_name           VARCHAR2(32),
tag                   RAW(10),
transaction_id        VARCHAR2(10),
scn                   NUMBER,
commit_scn            NUMBER,
old_values            SYS.LCR$_ROW_LIST,
new_values            SYS.LCR$_ROW_LIST)
NESTED TABLE old_values STORE AS old_values_ntab
NESTED TABLE new_values STORE AS new_values_ntab;

プロシージャDMLハンドラは、適用プロセスによって処理される行LCRごとに、strmadmin.history_row_lcrs表に1行挿入します。この例で作成されるプリコミット・ハンドラは、トランザクションのコミット時に、strmadmin.history_row_lcrs表に1行挿入します。

history_row_lcrs表にコミット情報を挿入するプロシージャを作成します。

CREATE OR REPLACE PROCEDURE strmadmin.history_commit(commit_number IN NUMBER)
IS
BEGIN
-- Insert commit information into the history_row_lcrs table
INSERT INTO strmadmin.history_row_lcrs (timestamp, commit_scn)
VALUES (SYSDATE, commit_number);
END;
/

関連項目:

- 「プリコミット・ハンドラ」

- 「DMLハンドラの管理」

適用プロセスのプリコミット・ハンドラの設定

プリコミット・ハンドラは、適用プロセスによってデキューされたすべてのコミット・ディレクティブを処理します。適用プロセスにプリコミット・ハンドラを設定すると、適用プロセスがデキューするすべてのコミット・ディレクティブの処理に使用されます。適用プロセスには1つのプリコミット・ハンドラのみを設定できます。

適用プロセスのプリコミット・ハンドラを設定するには、DBMS_APPLY_ADMパッケージのALTER_APPLYプロシージャでprecommit_handlerパラメータを使用します。たとえば、次のプロシージャでは、適用プロセスstrm01_applyのプリコミット・ハンドラにstrmadminスキーマのhistory_commitプロシージャが設定されます。

BEGIN
DBMS_APPLY_ADM.ALTER_APPLY(
apply_name        => 'strm01_apply',
precommit_handler => 'strmadmin.history_commit');
END;
/

また、DBMS_APPLY_ADMパッケージのCREATE_APPLYプロシージャを使用して適用プロセスを作成する際に、プリコミット・ハンドラを指定することもできます。適用プロセスにプリコミット・ハンドラがすでに設定されている場合は、ALTER_APPLYプロシージャを実行して、適用プロセスのプリコミット・ハンドラを変更できます。

適用プロセスのプリコミット・ハンドラの設定解除

適用プロセスのプリコミット・ハンドラを設定解除するには、DBMS_APPLY_ADMパッケージのALTER_APPLYプロシージャでremove_precommit_handlerパラメータをTRUEに設定します。たとえば、次のプロシージャでは、適用プロセスstrm01_applyのプリコミット・ハンドラの設定が解除されます。

BEGIN
DBMS_APPLY_ADM.ALTER_APPLY(
apply_name               => 'strm01_apply',
remove_precommit_handler => TRUE);
END;
/

適用プロセスによるメッセージのエンキューの指定

この項では、ポジティブ・ルール・セットに指定したルールを使用する適用プロセスで、ルールを満たすメッセージがエンキューされる宛先キューを設定する手順について説明します。また、宛先キューの設定を削除する手順についても説明します。

関連項目:
「適用時に宛先キューを指定するルールの表示」

ルールを満たすメッセージの宛先キューの設定

特定のルールを満たすメッセージの宛先キューを設定するには、DBMS_APPLY_ADMパッケージのSET_ENQUEUE_DESTINATIONプロシージャを使用します。たとえば、ルールemployees5の宛先キューをキューhr.change_queueに設定するには、次のプロシージャを実行します。

BEGIN
DBMS_APPLY_ADM.SET_ENQUEUE_DESTINATION(
rule_name               =>  'employees5',
destination_queue_name  =>  'hr.change_queue');
END;
/

このプロシージャでは、ルールのアクション・コンテキストを変更してキューを指定します。ポジティブ・ルール・セットにemployees5ルールが含まれるローカル・データベースのすべての適用プロセスで、employees5ルールを満たすメッセージがhr.change_queueにエンキューされます。employees5ルールの宛先キューを変更するには、SET_ENQUEUE_DESTINATIONプロシージャを再実行して異なるキューを指定します。

指定したルールを使用する各適用プロセスの適用ユーザーは、指定したキューにメッセージをエンキューするために必要な権限を持っている必要があります。キューが保護キューの場合、適用ユーザーはキューの保護キュー・ユーザーである必要があります。

SET_ENQUEUE_DESTINATIONプロシージャを使用してエンキューされたメッセージは、手動でエンキューされている他のすべてのメッセージと同様です。このメッセージに対して、手動でのデキュー、apply_capturedパラメータをFALSEに設定して作成された適用プロセスによる適用、または他のキューへの伝播を実行できます。

注意:

- 指定したルールは、適用プロセスのポジティブ・ルール・セットに含まれている必要があります。ルールが適用プロセスのネガティブ・ルール・セットに含まれている場合、適用プロセスはメッセージを宛先キューにエンキューしません。

- 適用プロセスは、常にメッセージを永続キューにエンキューします。バッファ・キューへのメッセージのエンキューはできません。

関連項目:

- 「保護キューでのユーザー操作の有効化」

- 指定したルールのアクション・コンテキストをSET_ENQUEUE_DESTINATIONプロシージャで変更する方法については、「適用時のメッセージのエンキューの宛先」を参照

ルールの宛先キュー設定の削除

指定したルールを満たすメッセージの宛先キューを削除するには、DBMS_APPLY_ADMパッケージのSET_ENQUEUE_DESTINATIONプロシージャを使用します。具体的には、このプロシージャで、ルールのdestination_queue_nameパラメータをNULLに設定します。ルールの宛先キューの指定が削除された場合、ルールを満たすメッセージは、適用プロセスによってキューにエンキューされません。

たとえば、ルールemployees5の宛先キューを削除するには、次のプロシージャを実行します。

BEGIN
DBMS_APPLY_ADM.SET_ENQUEUE_DESTINATION(
rule_name               =>  'employees5',
destination_queue_name  =>  NULL);
END;
/

ポジティブ・ルール・セットにemployees5ルールが含まれるローカル・データベースのすべての適用プロセスで、employees5ルールを満たすメッセージがhr.change_queueにエンキューされなくなります。

適用プロセスの実行ディレクティブの指定

この項では、適用プロセスで、ポジティブ・ルール・セットで指定されたルールを満たすメッセージ用の実行ディレクティブを設定する手順について説明します。

関連項目:
「適用時に実行しないことを指定するルールの表示」

ルールを満たすメッセージの実行の回避の指定

適用プロセスが、指定されたルールを満たすメッセージを実行しないように指定するには、DBMS_APPLY_ADMパッケージのSET_EXECUTEプロシージャを使用します。具体的には、このプロシージャで、ルールのexecuteパラメータをFALSEに設定します。ルールの実行ディレクティブをFALSEに設定すると、そのルールがポジティブ・ルール・セットに含まれる適用プロセスでは、そのルールを満たすメッセージは実行されません。

たとえば、適用プロセスでルールdepartments8を満たすメッセージが実行されないように指定するには、次のプロシージャを実行します。

BEGIN
DBMS_APPLY_ADM.SET_EXECUTE(
rule_name   =>  'departments8',
execute     =>  FALSE);
END;
/

このプロシージャは、ルールのアクション・コンテキストを変更して、実行ディレクティブを指定します。ポジティブ・ルール・セットにdepartments8ルールが含まれるローカル・データベースのすべての適用プロセスで、departments8ルールを満たすメッセージは実行されません。したがって、メッセージがLCRの場合、適用プロセスでは、LCRの変更が、関連するデータベース・オブジェクトに対して適用されません。また、適用プロセスでは、このルールを満たすメッセージは適用ハンドラに送信されません。

注意:

- 適用プロセスが実行ディレクティブに従うには、指定したルールが適用プロセスのポジティブ・ルール・セットに含まれている必要があります。ルールが適用プロセスのネガティブ・ルール・セットに含まれている場合、適用プロセスはルールの実行ディレクティブを無視します。

- 特定のルールを満たすメッセージを、実行せずに宛先キューにエンキューするには、SET_EXECUTEプロシージャとSET_ENQUEUE_DESTINATIONプロシージャを併用できます。SET_ENQUEUE_DESTINATIONプロシージャを使用してメッセージをエンキューすると、そのメッセージは手動でエンキューしたメッセージと同様になります。したがって、そのメッセージに対して、手動のデキュー、適用プロセスによる適用、または他のキューへの伝播を実行できます。

関連項目:

- 指定したルールのアクション・コンテキストをSET_EXECUTEプロシージャで変更する方法の詳細は、「適用時のメッセージの実行ディレクティブ」を参照

- 「適用プロセスによるメッセージのエンキューの指定」

ルールを満たすメッセージの実行の指定

適用プロセスが、指定されたルールを満たすメッセージを実行するように指定するには、DBMS_APPLY_ADMパッケージのSET_EXECUTEプロシージャを使用します。具体的には、このプロシージャでルールのexecuteパラメータをTRUEに設定します。デフォルトでは、メッセージが適用プロセスのネガティブ・ルール・セットのルールを満たしていないことを想定して、適用プロセスのポジティブ・ルール・セットに含まれるルールを満たすメッセージが各適用プロセスで実行されます。したがって、ルールのexecuteパラメータが以前FALSEに設定されていた場合にのみ、TRUEに設定する必要があります。

たとえば、適用プロセスがルールdepartments8を満たすメッセージを実行するように指定するには、次のプロシージャを実行します。

BEGIN
DBMS_APPLY_ADM.SET_EXECUTE(
rule_name   =>  'departments8',
execute     =>  TRUE);
END;
/

ポジティブ・ルール・セットにdepartments8ルールが含まれるローカル・データベースのすべての適用プロセスで、departments8ルールを満たすメッセージが実行されます。したがって、メッセージがLCRの場合、適用プロセスによって、LCRの変更が、関連するデータベース・オブジェクトに対して適用されます。また、適用プロセスでは、このルールを満たすメッセージは適用ハンドラに送信されます(適用プロセスをそのように設定している場合)。

エラー・ハンドラの管理

エラー・ハンドラは、任意の適用プロセスによってデキューされた、指定の表に対する指定の操作を含む行LCRから生成されたエラーを処理します。

次の各項では、エラー・ハンドラの作成、設定および設定解除の手順について説明します。

- エラー・ハンドラの作成

- エラー・ハンドラの設定

- エラー・ハンドラの設定解除

関連項目:

- 「適用プロセスで処理できるメッセージのタイプ」

- 「適用プロセスのメッセージ処理オプション」

エラー・ハンドラの作成

エラー・ハンドラを作成するには、DBMS_APPLY_ADMパッケージのSET_DML_HANDLERプロシージャを実行して、error_handlerパラメータをTRUEに設定します。

エラー・ハンドラには、次のシグネチャが必要です。

PROCEDURE user_procedure (
message             IN ANYDATA,
error_stack_depth   IN NUMBER,
error_numbers       IN DBMS_UTILITY.NUMBER_ARRAY,
error_messages      IN emsg_array);

user_procedureは、プロシージャ名です。各パラメータは必須であり、指定されたデータ型を使用する必要があります。ただし、パラメータ名は変更できます。emsg_arrayパラメータには、VARCHAR2型のPL/SQL表である76文字以上のユーザー定義配列で指定する必要があります。

注意:
エラー・ハンドラは、SET_DML_HANDLERで指定されたユーザー・プロシージャに関するいくつかの条件を満たす必要があります。これらの条件の詳細は、「DMLハンドラの管理」を参照してください。

エラー・ハンドラの実行結果は、次のいずれかになります。

- エラー・ハンドラによって、エラーが正常に解決され、該当する場合は行LCRが適用され、制御が適用プロセスに戻されます。

- エラー・ハンドラがエラーの解決に失敗し、エラーが発生します。エラーが発生すると、トランザクションはロールバックされ、エラー・キューに置かれます。

DML操作を再実行する場合は、エラー・ハンドラ・プロシージャで、LCR用のEXECUTEメンバー・プロシージャを実行します。

次の例では、hr.regions表の主キー違反を解決するエラー・ハンドラregions_pk_errorを作成します。宛先データベースでは、ユーザーがhr.regions表に行を挿入し、リモート・ソース・データベースの取得プロセスによって発生したhr.regions表に対する変更が、適用プロセスによって適用されるとします。この環境では、宛先データベースのユーザーが、ソース・データベースから適用された挿入行LCRと同じ主キー値を持つ行を挿入すると、エラーが発生する可能性があります。

この例では、hr.regions表の主キー違反によるエラーごとに次の情報を記録するため、strmadminスキーマにerrorlogという表を作成します。

- エラー発生時のタイム・スタンプ

- エラーが発生した適用プロセスの名前

- エラーの原因となったユーザー(送信者)。これは、取得LCRの場合は取得プロセス名、同期取得によって取得された永続LCRの場合は同期取得名、アプリケーションによってエンキューされた永続LCRおよび永続ユーザー・メッセージの場合はOracle Streams Advanced Queuing(AQ)エージェントの名前です

- 将来、他のオブジェクトのエラーがログに記録される可能性があるため、DMLの操作が実行されたオブジェクトの名前

- DML操作で使用されたコマンドのタイプ

- 違反となった制約の名前

- エラー・メッセージ

- エラーの原因となったLCR

このエラー・ハンドラでは、hr.regions表での主キー違反によるエラーのみが解決されます。このタイプのエラーを解決するために、エラー・ハンドラでは、順序を使用して行LCRのregion_id値が変更した後、行LCRを実行して適用します。他のタイプのエラーが発生した場合は、errorlog表に格納した行LCRを使用して手動でエラーを解決できます。

たとえば、エラー・ハンドラでは次のエラーが解決されます。

1. 宛先データベースで、ユーザーがhr.regions表にregion_idの値が6、region_nameの値が'LILLIPUT'の1行を挿入します。

2. ソース・データベースで、ユーザーがhr.regions表にregion_idの値が6、region_nameの値が'BROBDINGNAG'の1行を挿入します。

3. ソース・データベースの取得プロセスが、手順2で説明した変更を取得します。

4. 伝播によって、ソース・データベースのキューから宛先データベースの適用プロセスで使用されるキューに、変更を含むLCRが伝播されます。

5. 適用プロセスがLCRを適用すると、主キー違反のためにエラーが発生します。

6. 適用プロセスがエラー・ハンドラを起動して、エラーを処理します。

7. エラー・ハンドラは、エラーをstrmadmin.errorlog表に記録します。

8. エラー・ハンドラは、順序を使用してLCR内でregion_id値を変更し、そのLCRを実行して適用します。

regions_pk_errorエラー・ハンドラを作成する手順は、次のとおりです。

1. SQL*Plusで、データベースにhrユーザーとして接続します。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

2. 新しい主キー値に割り当てるためにエラー・ハンドラで使用される順序を作成します。

CREATE SEQUENCE hr.reg_exception_s START WITH 9000;

この例では、宛先データベースのユーザーはregion_idが8999を超える行をhr.regions表に挿入しないと仮定します。

3. Oracle Streams管理者に、順序に対するALL権限を付与します。

GRANT ALL ON reg_exception_s TO strmadmin;

4. データベースにOracle Streams管理者として接続します。

5. errorlog表を作成します。

CREATE TABLE strmadmin.errorlog(
logdate       DATE,
apply_name    VARCHAR2(30),
sender        VARCHAR2(100),
object_name   VARCHAR2(32),
command_type  VARCHAR2(30),
errnum        NUMBER,
errmsg        VARCHAR2(2000),
text          VARCHAR2(2000),
lcr           SYS.LCR$_ROW_RECORD);

6. regions_pk_errorプロシージャを含めるパッケージを作成します。

CREATE OR REPLACE PACKAGE errors_pkg
AS
TYPE emsg_array IS TABLE OF VARCHAR2(2000) INDEX BY BINARY_INTEGER;
PROCEDURE regions_pk_error(
message            IN ANYDATA,
error_stack_depth  IN NUMBER,
error_numbers      IN DBMS_UTILITY.NUMBER_ARRAY,
error_messages     IN EMSG_ARRAY);
END errors_pkg ;
/

7. パッケージ本体を作成します。

CREATE OR REPLACE PACKAGE BODY errors_pkg AS
PROCEDURE regions_pk_error (
message            IN ANYDATA,
error_stack_depth  IN NUMBER,
error_numbers      IN DBMS_UTILITY.NUMBER_ARRAY,
error_messages     IN EMSG_ARRAY )
IS
reg_id     NUMBER;
ad         ANYDATA;
lcr        SYS.LCR$_ROW_RECORD;
ret        PLS_INTEGER;
vc         VARCHAR2(30);
apply_name VARCHAR2(30);
errlog_rec errorlog%ROWTYPE ;
ov2        SYS.LCR$_ROW_LIST;
BEGIN
-- Access the error number from the top of the stack.
-- In case of check constraint violation,
-- get the name of the constraint violated.
IF error_numbers(1) IN ( 1 , 2290 ) THEN
ad  := DBMS_STREAMS.GET_INFORMATION('CONSTRAINT_NAME');
ret := ad.GetVarchar2(errlog_rec.text);
ELSE
errlog_rec.text := NULL ;
END IF ;
-- Get the name of the sender and the name of the apply process.
ad  := DBMS_STREAMS.GET_INFORMATION('SENDER');
ret := ad.GETVARCHAR2(errlog_rec.sender);
apply_name := DBMS_STREAMS.GET_STREAMS_NAME();
-- Try to access the LCR.
ret := message.GETOBJECT(lcr);
errlog_rec.object_name  := lcr.GET_OBJECT_NAME() ;
errlog_rec.command_type := lcr.GET_COMMAND_TYPE() ;
errlog_rec.errnum := error_numbers(1) ;
errlog_rec.errmsg := error_messages(1) ;
INSERT INTO strmadmin.errorlog VALUES (SYSDATE, apply_name,
errlog_rec.sender, errlog_rec.object_name, errlog_rec.command_type,
errlog_rec.errnum, errlog_rec.errmsg, errlog_rec.text, lcr);
-- Add the logic to change the contents of LCR with correct values.
-- In this example, get a new region_id number
-- from the hr.reg_exception_s sequence.
ov2 := lcr.GET_VALUES('new', 'n');
FOR i IN 1 .. ov2.count
LOOP
IF ov2(i).column_name = 'REGION_ID' THEN
SELECT hr.reg_exception_s.NEXTVAL INTO reg_id FROM DUAL;
ov2(i).data := ANYDATA.ConvertNumber(reg_id) ;
END IF ;
END LOOP ;
-- Set the NEW values in the LCR.
lcr.SET_VALUES(value_type => 'NEW', value_list => ov2);
-- Execute the modified LCR to apply it.
lcr.EXECUTE(TRUE);
END regions_pk_error;
END errors_pkg;
/

注意:

- 変更された行に対する以降の変更が正常に適用されるように、2つのデータベースの行をできるだけ迅速に収束する必要があります。つまり、ソース・データベースと宛先データベースの行のregion_idを一致させる必要があります。このような手動での変更をデータベースで再取得させないようにする場合は、DBMS_STREAMSパッケージのSET_TAGプロシージャを使用して、取得されない値を変更するセッション用のタグを設定します。

- この例のエラー・ハンドラでは、LCRに対してGET_VALUESメンバー・ファンクションとSET_VALUESメンバー・プロシージャを使用しています。LCR内で変更する値が1つのみの場合は、GET_VALUESメンバー・ファンクションとSET_VALUEメンバー・プロシージャを使用する方が簡単で効率的な場合があります。

関連項目:

- 現行セッションで生成されるタグの値の設定の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- エラー・ハンドラで処理する特定のエラー・メッセージの詳細は、「エラー・キューに適用エラーがあるか」を参照

エラー・ハンドラの設定

エラー・ハンドラは、任意の適用プロセスによってデキューされた、指定の表に対する指定の操作を含む行LCRから生成されたエラーを処理します。同一の表に対する様々な操作で生成されるエラーを処理するために、表に複数のエラー・ハンドラを指定できます。特定の適用プロセスにエラー・ハンドラを設定できます。また、指定の表に指定の操作を適用するすべての適用プロセスで使用される一般的なエラー・ハンドラとして、エラー・ハンドラを設定することもできます。

エラー・ハンドラを設定するには、DBMS_APPLY_ADMパッケージのSET_DML_HANDLERプロシージャを使用します。このプロシージャを実行してエラー・ハンドラを設定する場合は、error_handlerパラメータをTRUEに設定します。

たとえば、次のプロシージャでは、hr.regions表に対するINSERT操作用のエラー・ハンドラを設定します。したがって、適用プロセスによって、ローカルのhr.regions表に対するINSERT操作を含む行LCRがデキューされ、行LCRがエラーになると、適用プロセスでは、行LCRがstrmadmin.errors_pkg.regions_pk_error PL/SQLプロシージャに送信されて処理されます。エラー・ハンドラでエラーを解決できない場合は、その行LCRと、同じトランザクション内の他のすべての行LCRがエラー・キューに移動されます。

この例では、apply_nameパラメータがNULLに設定されています。したがって、エラー・ハンドラは、データベース内のすべての適用プロセスで使用される汎用エラー・ハンドラになります。

次のプロシージャを実行してエラー・ハンドラを設定します。

BEGIN
DBMS_APPLY_ADM.SET_DML_HANDLER(
object_name         => 'hr.regions',
object_type         => 'TABLE',
operation_name      => 'INSERT',
error_handler       => TRUE,
user_procedure      => 'strmadmin.errors_pkg.regions_pk_error',
apply_database_link => NULL,
apply_name          => NULL);
END;
/

エラー・ハンドラがすでに設定されている場合は、SET_DML_HANDLERプロシージャを実行してエラー・ハンドラを変更できます。

エラー・ハンドラの設定解除

エラー・ハンドラの設定を解除するには、DBMS_APPLY_ADMパッケージのSET_DML_HANDLERプロシージャを使用します。このプロシージャを実行するときに、特定の表に対する特定の操作について、user_procedureパラメータをNULLに設定します。

たとえば、次のプロシージャでは、hr.regions表に対するINSERT操作について、エラー・ハンドラの設定が解除されます。

BEGIN
DBMS_APPLY_ADM.SET_DML_HANDLER(
object_name    => 'hr.regions',
object_type    => 'TABLE',
operation_name => 'INSERT',
user_procedure => NULL,
apply_name     => NULL);
END;
/

注意:
error_handlerパラメータを指定する必要はありません。

適用エラーの管理

次の各項では、適用エラーの再試行と削除の手順について説明します。

- 適用エラー・トランザクションの再試行

- 適用エラー・トランザクションの削除

関連項目:

- 「エラー・キュー」

- 「適用エラーのチェック」

- 「適用エラーの詳細情報の表示」

- Oracle Enterprise Managerでの適用エラーの管理方法については、Oracle Database 2日でデータ・レプリケーションおよび統合ガイドを参照

- 適用エラーの考えられる原因の詳細は、「表へのDML変更の適用に関する考慮事項」を参照

適用エラー・トランザクションの再試行

特定のエラー・トランザクション、または適用プロセスのすべてのエラー・トランザクションを再試行できます。場合によっては、エラー・トランザクションを再試行する前に、データベース・オブジェクトに対してDML変更またはDDL変更を行い、1つ以上の適用エラーの原因となった状態を修正する必要があります。また、同じデータベース・オブジェクトに対する変更を取得するように1つ以上の取得プロセスまたは同期取得を構成しているときに、変更の取得が不要になる可能性があります。この場合は、変更を行うセッションのセッション・タグを、取得されない値に設定できます。

関連項目:
現行セッションで生成されるタグの値の設定の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

特定の適用エラー・トランザクションの再試行

エラー・トランザクションを再試行する場合は、直接実行することも、ユーザー・プロシージャにエラー・トランザクションを送信して変更した後で実行することもできます。次の各項では、各方法の手順について説明します。

- ユーザー・プロシージャを使用しない特定の適用エラー・トランザクションの再試行

- ユーザー・プロシージャを使用した特定の適用エラー・トランザクションの再試行

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

ユーザー・プロシージャを使用しない特定の適用エラー・トランザクションの再試行

適用エラーの原因となった条件を修正した後に、ユーザー・プロシージャを指定せずにDBMS_APPLY_ADMパッケージのEXECUTE_ERRORプロシージャを実行して、トランザクションを再試行できます。この場合、トランザクションはカスタム処理を使用せずに実行されます。

たとえば、トランザクション識別子が5.4.312のトランザクションを再試行するには、次のプロシージャを実行します。

BEGIN
DBMS_APPLY_ADM.EXECUTE_ERROR(
local_transaction_id => '5.4.312',
execute_as_user      => FALSE,
user_procedure       => NULL);
END;
/

execute_as_userがTRUEの場合は、適用プロセスでは、現行ユーザーのセキュリティ・コンテキスト内でトランザクションが実行されます。execute_as_userがFALSEの場合、適用プロセスでは、トランザクションの元の受信者のセキュリティ・コンテキスト内でトランザクションが実行されます。元の受信者は、エラー発生時にトランザクションを処理していたユーザーです。

いずれの場合も、トランザクションを実行するユーザーには、適用オブジェクトに対するDML変更およびDDL変更を実行するための権限と、任意の適用ハンドラを実行するための権限が必要です。また、このユーザーには、適用プロセスで使用されるキューに対するデキュー権限も必要です。

ユーザー・プロシージャを使用した特定の適用エラー・トランザクションの再試行

DBMS_APPLY_ADMパッケージのEXECUTE_ERRORプロシージャを実行してエラー・トランザクションを再試行できます。また、ユーザー・プロシージャを指定して、トランザクションの実行前に、トランザクション内の1つ以上のメッセージを変更することもできます。この変更によって、トランザクションが正常に実行できるはずです。トランザクション内のメッセージは、LCRまたはユーザー・メッセージです。

たとえば、競合のために適用エラーが発生したとします。エラー・トランザクションを検証すると、行LCRのsalary列の古い値が間違っていることが判明しました。具体的には、hr.employees表のemployee_idが197の従業員について、給料の現行の値が、行LCRにおけるこの従業員の給料の古い値と一致していません。hr.employees表で、この従業員の現行の値が3250であるとします。

この場合、次のユーザー・プロシージャで、エラーの原因となった行LCRの給料を変更します。

CREATE OR REPLACE PROCEDURE strmadmin.modify_emp_salary(
in_any                        IN      ANYDATA,
error_record                  IN      DBA_APPLY_ERROR%ROWTYPE,
error_message_number          IN      NUMBER,
messaging_default_processing  IN OUT  BOOLEAN,
out_any                       OUT     ANYDATA)
AS
row_lcr          SYS.LCR$_ROW_RECORD;
row_lcr_changed  BOOLEAN := FALSE;
res              NUMBER;
ob_owner         VARCHAR2(32);
ob_name          VARCHAR2(32);
cmd_type         VARCHAR2(30);
employee_id      NUMBER;
BEGIN
IF in_any.getTypeName() = 'SYS.LCR$_ROW_RECORD' THEN
-- Access the LCR
res := in_any.GETOBJECT(row_lcr);
-- Determine the owner of the database object for the LCR
ob_owner := row_lcr.GET_OBJECT_OWNER;
-- Determine the name of the database object for the LCR
ob_name := row_lcr.GET_OBJECT_NAME;
-- Determine the type of DML change
cmd_type := row_lcr.GET_COMMAND_TYPE;
IF (ob_owner = 'HR' AND ob_name = 'EMPLOYEES' AND cmd_type = 'UPDATE') THEN
-- Determine the employee_id of the row change
IF row_lcr.GET_VALUE('old', 'employee_id') IS NOT NULL THEN
employee_id := row_lcr.GET_VALUE('old', 'employee_id').ACCESSNUMBER();
IF (employee_id = 197) THEN
-- error_record.message_number should equal error_message_number
row_lcr.SET_VALUE(
value_type => 'OLD',
column_name => 'salary',
column_value => ANYDATA.ConvertNumber(3250));
row_lcr_changed := TRUE;
END IF;
END IF;
END IF;
END IF;
-- Specify that the apply process continues to process the current message
messaging_default_processing := TRUE;
-- assign out_any appropriately
IF row_lcr_changed THEN
out_any := ANYDATA.ConvertObject(row_lcr);
ELSE
out_any := in_any;
END IF;
END;
/

トランザクション識別子が5.6.924のトランザクションを再試行する際、実行前にstrmadminスキーマ内のmodify_emp_salaryプロシージャでトランザクションを処理するには、次のプロシージャを実行します。

BEGIN
DBMS_APPLY_ADM.EXECUTE_ERROR(
local_transaction_id => '5.6.924',
execute_as_user      => FALSE,
user_procedure       => 'strmadmin.modify_emp_salary');
END;
/

注意:
プロシージャを実行するユーザーは、DBA_APPLY_ERRORデータ・ディクショナリ・ビューに対するSELECT権限を持っている必要があります。

関連項目:
「適用エラーの詳細情報の表示」

適用プロセスのすべてのエラー・トランザクションの再試行

適用プロセスについて、すべての適用エラーの原因となった条件を修正した後に、DBMS_APPLY_ADMパッケージのEXECUTE_ALL_ERRORSプロシージャを実行してすべてのエラー・トランザクションを再試行できます。たとえば、適用プロセスstrm01_applyのすべてのエラー・トランザクションを再試行するには、次のプロシージャを実行します。

BEGIN
DBMS_APPLY_ADM.EXECUTE_ALL_ERRORS(
apply_name       => 'strm01_apply',
execute_as_user  => FALSE);
END;
/

注意:
apply_nameパラメータに対してNULLを指定した場合に、複数の適用プロセスが存在すると、すべての適用プロセスのすべての適用エラーが再試行されます。

適用エラー・トランザクションの削除

特定のエラー・トランザクションまたは適用プロセスのすべてのエラー・トランザクションを削除できます。

特定の適用エラー・トランザクションの削除

エラー・トランザクションを適用する必要がない場合は、DBMS_APPLY_ADMパッケージのDELETE_ERRORプロシージャを使用して、エラー・キューからトランザクションを削除できます。たとえば、トランザクション識別子が5.4.312のトランザクションを削除するには、次のプロシージャを実行します。

EXEC DBMS_APPLY_ADM.DELETE_ERROR(local_transaction_id => '5.4.312');

適用プロセスのすべてのエラー・トランザクションの削除

すべてのエラー・トランザクションを適用しない場合は、DBMS_APPLY_ADMパッケージのDELETE_ALL_ERRORSプロシージャを実行して、すべてのエラー・トランザクションを削除できます。たとえば、適用プロセスstrm01_applyのすべてのエラー・トランザクションを削除するには、次のプロシージャを実行します。

EXEC DBMS_APPLY_ADM.DELETE_ALL_ERRORS(apply_name => 'strm01_apply');

注意:
apply_nameパラメータに対してNULLを指定した場合に、複数の適用プロセスが存在すると、すべての適用プロセスのすべての適用エラーが削除されます。

表の代替キー列の管理

この項では、表の代替キー列の設定および削除の手順について説明します。

関連項目:

- 「代替キー列」

- 「宛先データベースで指定された代替キー列の表示」

表の代替キー列の設定

適用プロセスによって表に変更が適用される場合、代替キー列は、主キーを含む表の主キー列と置き換えられるか、または主キーを含まない表の主キー列として使用できます。表の代替キー列を設定するには、DBMS_APPLY_ADMパッケージのSET_KEY_COLUMNSプロシージャを使用します。この設定は、ローカルの変更をデータベースに適用する適用プロセスすべてに適用されます。

たとえば、hr.employees表の代替キー列をfirst_name、last_nameおよびhire_dateの各列に設定して、employee_id列を置換するには、次のプロシージャを実行します。

BEGIN
DBMS_APPLY_ADM.SET_KEY_COLUMNS(
object_name         => 'hr.employees',
column_list         => 'first_name,last_name,hire_date');
END;
/

注意:

- 宛先データベースのcolumn_listまたはcolumn_tableパラメータで代替キー列として指定されたすべての列に対して、ソース・データベースで無条件サプリメンタル・ログ・グループを指定する必要があります。この例では、hr.employees表のfirst_name、last_nameおよびhire_date列を含む無条件サプリメンタル・ログ・グループを指定します。

- 適用プロセスによってOracle以外のリモート・データベースに変更が適用される場合、この適用プロセスでは、同じ表に対して別の代替キー列を使用できます。DBMS_APPLY_ADMパッケージのSET_KEY_COLUMNSプロシージャを実行して、apply_database_linkパラメータをNULL以外の値に設定することにより、Oracle以外のリモート・データベースに適用される変更に対して代替キー列を指定できます。

関連項目:

- 「Oracle Streams環境内のサプリメンタル・ロギング」

- 『Oracle Streamsレプリケーション管理者ガイド』

表の代替キー列の削除

表の代替キー列を削除するには、DBMS_APPLY_ADMパッケージのSET_KEY_COLUMNSプロシージャでcolumn_listまたはcolumn_tableパラメータにNULLを指定します。表に主キーがある場合、代替主キーを削除すると、適用プロセスではデータベースに対するローカルの変更にその表の主キーが使用されます。

たとえば、hr.employees表の代替キー列を削除するには、次のプロシージャを実行します。

BEGIN
DBMS_APPLY_ADM.SET_KEY_COLUMNS(
object_name  => 'hr.employees',
column_list  => NULL);
END;
/

仮想依存性定義の使用

仮想依存性定義とは、宛先データベースで適用されるトランザクション間の依存性を検出するために、適用プロセスで使用される依存性の記述です。仮想依存性定義は、適用プロセスの並列性が1より大きく、依存性が宛先データベースのデータ・ディクショナリに制約によって記述されていない場合に役立ちます。仮想依存性定義には、値の依存性とオブジェクト依存性の2つのタイプがあります。

値の依存性は、一意キーなどの表制約、または2つ以上の表の列間の関連を定義します。オブジェクト依存性は、宛先データベースの2つのオブジェクト間の親子関係を定義します。

次の各項では、仮想依存性定義の使用について説明します。

- 値の依存性の設定および設定解除

- オブジェクト依存性の作成および削除

関連項目:
仮想依存性定義の詳細は、「適用プロセスおよび依存性」を参照

値の依存性の設定および設定解除

DBMS_APPLY_ADMパッケージのSET_VALUE_DEPENDENCYプロシージャを使用して、値の依存性を設定または設定解除します。次の各項では、値の依存性を使用する場合の使用例について説明します。

- スキーマの相違および値の依存性

- 宛先データベースでの未定義の制約および値の依存性

スキーマの相違および値の依存性

この使用例に関連する環境では、ソース・データベースと宛先データベースの間で数多くの表を共有するものの、これら2つのデータベースで表を所有するスキーマが異なっています。また、このレプリケーション環境では、ソース・データベースが米国に存在し、宛先データベースが英国に存在します。ある設計会社が製品設計を作成するのに多くの表を使用していますが、ソース・データベースの表では米国の測定単位(インチ、フィートなど)が使用され、宛先データベースの表ではメートル法の測定単位が使用されています。ソース・データベースでデータベース・オブジェクトを所有するスキーマの名前はus_designs、宛先データベースでのスキーマの名前はuk_designsです。したがって、適用前に共有データベース・オブジェクトのスキーマ名を変更する必要があり、すべての測定単位を米国の測定単位からメートル法の測定単位に変換する必要があります。データベース・オブジェクト間に依存性を持たせるために、両方のデータベースで同じ制約を使用します。

必要となる変更はルールベースの変換を使用して行うことができますが、ここでの目的は複数のLCRをパラレルで適用することです。ルールベースの変換では、LCRをシリアルに適用する必要があります。そのため、宛先データベースでのプロシージャDMLハンドラがLCRに必要な変更を行うように構成され、適用プロセスの並列性が5に設定されます。この環境では、宛先データベースにはソース・データベースから送信されるLCRのスキーマus_designsに関する情報がありません。適用プロセスではLCRを適用ハンドラに渡す前に依存性を計算するため、適用プロセスにLCR間の依存性に関する情報が通知される必要があります。値の依存性を使用すると、これらの依存性を記述できます。

この使用例では、複数の表で異なる設計が作成され、これらの表にそれぞれ主キーが存在するとします。これらの表の1つにdesign_53があり、その主キー列はkey_53です。また、表all_designs_summaryには個別の設計すべての概要が含まれ、この表には各設計表の外部キー列が含まれます。all_designs_summaryには、design_53表の主キーの外部キーであるkey_53列が含まれます。これらの表の関係について適用プロセスに通知するには、次のプロシージャを実行して、宛先データベースで値の依存性を作成します。

BEGIN
DBMS_APPLY_ADM.SET_VALUE_DEPENDENCY(
dependency_name   => 'key_53_foreign_key',
object_name       => 'us_designs.design_53',
attribute_list    => 'key_53');
END;
/

BEGIN
DBMS_APPLY_ADM.SET_VALUE_DEPENDENCY(
dependency_name   => 'key_53_foreign_key',
object_name       => 'us_designs.all_designs_summary',
attribute_list    => 'key_53');
END;
/

LCRにはソース・データベースのスキーマが含まれるため、値の依存性でそのソース・データベースのスキーマ(us_designs)が使用されていることに注意してください。適用プロセスによって行LCRがハンドラに渡された後、プロシージャDMLハンドラによってスキーマがuk_designsに変更されます。

値の依存性を設定解除するには、SET_VALUE_DEPENDENCYプロシージャを実行して、dependency_nameパラメータに値の依存性の名前を指定し、object_nameパラメータにNULLを指定します。たとえば、以前に設定した値の依存性key_53_foreign_keyを設定解除するには、次のプロシージャを実行します。

BEGIN
DBMS_APPLY_ADM.SET_VALUE_DEPENDENCY(
dependency_name   => 'key_53_foreign_key',
object_name       => NULL,
attribute_list    => NULL);
END;
/

関連項目:
「DMLハンドラの管理」

宛先データベースでの未定義の制約および値の依存性

この使用例に関連する環境では、ソース・データベースの共有表に対して外部キー制約が使用され、宛先データベースのこれらの表に対しては制約が使用されていません。このレプリケーション環境では、宛先データベースがデータ・ウェアハウスとして使用されており、問合せよりもデータベースへのデータの書込みの方がはるかに頻繁に行われます。書込み操作を最適化するために、宛先データベースでは制約が定義されていません。

このような環境では、トランザクションを一貫して適用するために、宛先データベースで実行中の適用プロセスに制約について通知する必要があります。値の依存性を使用すると、適用プロセスにこれらの制約について通知できます。

たとえば、oeスキーマ内のordersおよびorder_items表が、この環境のソース・データベースと宛先データベース間で共有されているとします。ソース・データベースでは、order_id列はorders表の主キーであり、order_items表のorder_id列はorders表の主キー列と一致する外部キーです。宛先データベースでは、これらの制約は削除されています。次のプロシージャを実行し、適用プロセスにこれらの表の列の関係について通知する値の依存性を宛先データベースで作成します。

BEGIN
DBMS_APPLY_ADM.SET_VALUE_DEPENDENCY(
dependency_name   => 'order_id_foreign_key',
object_name       => 'oe.orders',
attribute_list    => 'order_id');
END;
/

BEGIN
DBMS_APPLY_ADM.SET_VALUE_DEPENDENCY(
dependency_name   => 'order_id_foreign_key',
object_name       => 'oe.order_items',
attribute_list    => 'order_id');
END;
/

また、この環境では、適用プロセスでトランザクションが一貫して適用できるように、次のアクションを実行する必要があります。

- ソース・データベースで一意キーまたはビットマップ索引を含む各列に対して値の依存性を設定する必要があります。

- DBMS_APPLY_ADM.SET_KEY_COLUMNSプロシージャを実行して、ソース・データベースで主キー列である列の代替キー列を設定する必要があります。

以前に設定した値の依存性を設定解除するには、次のプロシージャを実行します。

BEGIN
DBMS_APPLY_ADM.SET_VALUE_DEPENDENCY(
dependency_name   => 'order_id_foreign_key',
object_name       => NULL,
attribute_list    => NULL);
END;
/

関連項目:
「表の代替キー列の管理」

オブジェクト依存性の作成および削除

DBMS_APPLY_ADMパッケージのCREATE_OBJECT_DEPENDENCYおよびDROP_OBJECT_DEPENDENCYプロシージャを実行して、オブジェクト依存性を作成または削除します。次の各項では、オブジェクト依存性の作成および削除の詳しい手順について説明します。

オブジェクト依存性の作成

特定の表の行LCRが常に別の表の行LCRより前に適用される必要があり、宛先データベースのデータ・ディクショナリにこの関係を持たせる制約が含まれていない場合に、オブジェクト依存性を使用できます。オブジェクト依存性を定義する場合、最初に適用される必要がある行LCRを含む表が親表であり、2番目に適用される必要がある行LCRを含む表が子表です。

たとえば、次の特性を持つOracle Streamsレプリケーション環境を考えます。

- ordスキーマ内の次の表はソース・データベースと宛先データベース間で共有されます。

- customers表には、顧客に関する情報(各顧客の出荷先住所など)が含まれます。

- orders表には、各注文に関する情報が含まれます。

- order_items表には、各注文内のアイテムに関する情報が含まれます。

- ship_orders表には、出荷の準備が完了している注文に関する情報は含まれますが、顧客の詳細情報または各注文で出荷される個別のアイテムに関する情報は含まれません。

- ship_orders表には、制約によって定義された、他の表との関係は存在しません。

- 注文に関する情報はソース・データベースに入力され、宛先データベースに伝播されて適用されます。

- 宛先データベースのサイトは注文が顧客に出荷されるウェアハウスです。このサイトで、プロシージャDMLハンドラによってship_orders、customers、ordersおよびorder_itemsの各表の情報が使用され、顧客の出荷先住所と出荷するアイテムを含むレポートが生成されます。

プロシージャDMLハンドラによって生成されたレポートの情報は、出荷注文記録が作成された時間と一貫性がある必要があります。宛先データベースのオブジェクト依存性によって、この目的が達成されます。この場合、ship_orders表は子表customers、ordersおよびorder_itemsの親表です。ship_ordersがこれらの表の親であるため、ship_orders表の記録が入力された後にこれらの表に対して行われた変更は、プロシージャDMLハンドラによって出荷注文のレポートが生成されるまで適用されません。

これらのオブジェクト依存性を作成するには、宛先データベースで次のプロシージャを実行します。

BEGIN
DBMS_APPLY_ADM.CREATE_OBJECT_DEPENDENCY(
object_name         =>  'ord.customers',
parent_object_name  =>  'ord.ship_orders');
END;
/

BEGIN
DBMS_APPLY_ADM.CREATE_OBJECT_DEPENDENCY(
object_name         =>  'ord.orders',
parent_object_name  =>  'ord.ship_orders');
END;
/

BEGIN
DBMS_APPLY_ADM.CREATE_OBJECT_DEPENDENCY(
object_name         =>  'ord.order_items',
parent_object_name  =>  'ord.ship_orders');
END;
/

関連項目:
「DMLハンドラの管理」

オブジェクト依存性の削除

「オブジェクト依存性の作成」で作成したオブジェクト依存性を削除するには、次のプロシージャを実行します。

BEGIN
DBMS_APPLY_ADM.DROP_OBJECT_DEPENDENCY(
object_name         =>  'ord.customers',
parent_object_name  =>  'ord.ship_orders');
END;
/

BEGIN
DBMS_APPLY_ADM.DROP_OBJECT_DEPENDENCY(
object_name         =>  'ord.orders',
parent_object_name  =>  'ord.ship_orders');
END;
/

BEGIN
DBMS_APPLY_ADM.DROP_OBJECT_DEPENDENCY(
object_name         =>  'ord.order_items',
parent_object_name  =>  'ord.ship_orders');
END;
/

適用プロセスの削除

既存の適用プロセスを削除するには、DBMS_APPLY_ADMパッケージのDROP_APPLYプロシージャを実行します。たとえば、次のプロシージャでは、適用プロセスstrm02_applyが削除されます。

BEGIN
DBMS_APPLY_ADM.DROP_APPLY(
apply_name            => 'strm02_apply',
drop_unused_rule_sets => TRUE);
END;
/

drop_unused_rule_setsパラメータがTRUEに設定されているため、このプロシージャではstrm02_apply適用プロセスで使用されているルール・セットも削除されます。ただし、他のOracle Streamsクライアントで使用されているルール・セットは削除されません。drop_unused_rule_setsパラメータがTRUEに設定されている場合は、適用プロセスのポジティブ・ルール・セットとネガティブ・ルール・セットの両方が削除されることがあります。このプロシージャによってルール・セットが削除された場合、そのルール・セット内のルールのうち、他のルール・セットに含まれていないルールも削除されます。

適用プロセスを削除しようとしたときに、指定した適用プロセスのエラー・キューにエラーが存在すると、エラーが発生します。このため、適用プロセスのエラー・キューにエラーが存在する場合は、適用プロセスを削除する前にエラーを削除します。

関連項目:

- 「適用エラーの管理」

18 ルールの管理

Oracle Streams環境では、ルールを使用してOracle Streamsクライアント(取得プロセス、伝播、適用プロセスおよびメッセージ・クライアント)の動作を制御します。また、ルール・エンジンのクライアントであるカスタム・アプリケーションも作成できます。この章では、ルール・セット、ルールおよびルールに関連する権限の管理手順について説明します。

次の各項では、ルールの管理について説明します。

- ルール・セットの管理

- ルールの管理

- 評価コンテキスト、ルール・セットおよびルールに対する権限の管理

この章で説明する各タスクは、特に明記されていないかぎり、適切な権限を付与されているOracle Streams管理者が完了する必要があります。

注意:
Oracle Streamsクライアントで使用されるルールおよびルール・セットを変更すると、Oracle Streamsクライアントの動作が変化します。

注意:
この章では、評価コンテキストの作成例およびDBMS_RULE.EVALUATEプロシージャを使用したイベントの評価例は説明していません。これらの例については、『Oracle Streams拡張例』を参照してください。

関連項目:

- 第5章「Oracle Streamsでのルールの使用方法」

- 第11章「ルールの高度な概念」

- 第6章「ルールベースの変換」

- Oracle Streams管理者を作成する方法の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- 第34章「ルールおよびルールベースの変換のトラブルシューティング」

ルール・セットの管理

ルール・セットの変更は、そのルール・セットを使用するOracle Streams取得プロセス、伝播および適用プロセスを停止せずに行うことができます。Oracle Streamsはコミットされた直後の変更を検出します。新しいバージョンのルール・セットが使用されるメッセージについて厳密に制御する必要がある場合は、次の手順を実行します。

1. 対応する取得プロセス、伝播および適用プロセスを停止します。

2. ルール・セットを変更します。

3. 手順1で停止したOracle Streamsクライアントを再起動します。

この項では、次のタスクの実行手順を説明します。

- ルール・セットの作成

- ルール・セットへのルールの追加

- ルール・セットからのルールの削除

- ルール・セットの削除

関連項目:

- 「取得プロセスの停止」

- 「伝播の停止」

- 「適用プロセスの停止」

- 第34章「ルールおよびルールベースの変換のトラブルシューティング」

ルール・セットの作成

次の例では、DBMS_RULE_ADMパッケージのCREATE_RULE_SETプロシージャを実行してルール・セットを作成します。

BEGIN
DBMS_RULE_ADM.CREATE_RULE_SET(
rule_set_name       => 'strmadmin.hr_capture_rules',
evaluation_context  => 'SYS.STREAMS$_EVALUATION_CONTEXT');
END;
/

このプロシージャを実行すると、次のアクションが実行されます。

- strmadminスキーマにルール・セットhr_capture_rulesが作成されます。同じ名前と所有者を持つルール・セットは作成できません。

- ルール・セットが、SYS.STREAMS$_EVALUATION_CONTEXT評価コンテキストに関連付けられます。これは、Oracleが提供するOracle Streams用の評価コンテキストです。

また、DBMS_STREAMS_ADMパッケージの次のプロシージャを使用すると、Oracle Streamsの取得プロセス、伝播、適用プロセスまたはメッセージ・クライアントにルール・セットが存在しない場合に自動的にルール・セットを作成できます。

- ADD_MESSAGE_PROPAGATION_RULE

- ADD_MESSAGE_RULE

- ADD_TABLE_PROPAGATION_RULES

- ADD_TABLE_RULES

- ADD_SUBSET_PROPAGATION_RULES

- ADD_SUBSET_RULES

- ADD_SCHEMA_PROPAGATION_RULES

- ADD_SCHEMA_RULES

- ADD_GLOBAL_PROPAGATION_RULES

- ADD_GLOBAL_RULES

ADD_SUBSET_PROPAGATION_RULESおよびADD_SUBSET_RULESを除き、前述のプロシージャは、Oracle Streamsクライアントのポジティブ・ルール・セットまたはネガティブ・ルール・セットを作成できます。ADD_SUBSET_PROPAGATION_RULESおよびADD_SUBSET_RULESは、Oracle Streamsクライアントのポジティブ・ルール・セットのみを作成できます。

関連項目:
Streamsクライアントを作成する方法の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

ルール・セットへのルールの追加

ルール・セットにルールを追加すると、そのルール・セットを使用するOracle Streamsクライアントの動作が変化します。手順を実行する前に、ルール・セットにルールを追加した場合のOracle Streamsクライアントへの影響を理解する必要があります。

次の例では、DBMS_RULE_ADMパッケージのADD_RULEプロシージャを実行して、hr_capture_rulesルール・セットにhr_dmlルールを追加します。

BEGIN
DBMS_RULE_ADM.ADD_RULE(
rule_name          => 'strmadmin.hr_dml',
rule_set_name      => 'strmadmin.hr_capture_rules',
evaluation_context => NULL);
END;
/

この例では、ADD_RULEプロシージャの実行時には評価コンテキストは指定されていません。したがって、ルールに独自の評価コンテキストがなければ、hr_capture_rulesルール・セットの評価コンテキストを継承します。ルール・セットに指定した以外の評価コンテキストをルールで使用する場合は、ADD_RULEプロシージャの実行時にevaluation_contextパラメータをその評価コンテキストに設定できます。

ルール・セットからのルールの削除

ルール・セットからルールを削除すると、そのルール・セットを使用するOracle Streamsクライアントの動作が変化します。手順を実行する前に、ルール・セットからルールを削除した場合のOracle Streamsクライアントへの影響を理解する必要があります。

次の例では、DBMS_RULE_ADMパッケージのREMOVE_RULEプロシージャを実行して、hr_capture_rulesルール・セットからhr_dmlルールを削除します。

BEGIN
DBMS_RULE_ADM.REMOVE_RULE(
rule_name     => 'strmadmin.hr_dml',
rule_set_name => 'strmadmin.hr_capture_rules');
END;
/

REMOVE_RULEプロシージャの実行後も、ルールはデータベース内に存在し、他のルール・セットに含まれていた場合は、そのルール・セットに残ります。

関連項目:
「ルールの削除」

ルール・セットの削除

次の例では、DBMS_RULE_ADMパッケージのDROP_RULE_SETプロシージャを実行して、データベースからhr_capture_rulesルール・セットを削除します。

BEGIN
DBMS_RULE_ADM.DROP_RULE_SET(
rule_set_name => 'strmadmin.hr_capture_rules',
delete_rules  => FALSE);
END;
/

この例では、DROP_RULE_SETプロシージャのdelete_rulesパラメータがFALSEに設定されています。これはデフォルト設定です。したがって、このルール・セットにルールが含まれている場合、そのルールは削除されません。delete_rulesパラメータをTRUEに設定すると、指定したルール・セットに含まれるルールのうち、他のルール・セットには含まれていないルールは、データベースから自動的に削除されます。ルール・セットのルールのうち、1つ以上の他のルール・セットに含まれているルールは削除されません。

ルールの管理

ルールの変更は、そのルールを使用するOracle Streamsの取得プロセス、伝播および適用プロセスを停止せずに行うことができます。Oracle Streamsはコミットされた直後の変更を検出します。新しいバージョンのルールが使用されるメッセージについて厳密に制御する必要がある場合は、次の手順を実行します。

1. 対応する取得プロセス、伝播および適用プロセスを停止します。

2. ルールを変更します。

3. 手順1で停止したOracle Streamsクライアントを再起動します。

この項では、次のタスクの実行手順を説明します。

- ルールの作成

- ルールの変更

- システム作成ルールの変更

- ルールの削除

関連項目:

- 「取得プロセスの停止」

- 「伝播の停止」

- 「適用プロセスの停止」

ルールの作成

次の例では、DBMS_RULE_ADMパッケージのCREATE_RULEプロシージャを使用して、アクション・コンテキストを持たないルールおよびアクション・コンテキストを持つルールを作成します。

アクション・コンテキストを持たないルールの作成

アクション・コンテキストを持たないルールを作成するには、次の例のように、CREATE_RULEプロシージャを実行し、rule_nameパラメータを使用してルールの名前、conditionパラメータを使用してルール条件を指定します。

BEGIN
DBMS_RULE_ADM.CREATE_RULE(
rule_name  => 'strmadmin.hr_dml',
condition  => ' :dml.get_object_owner() = ''HR'' ');
END;
/

このプロシージャを実行すると、次のアクションが実行されます。

- strmadminスキーマにルールhr_dmlが作成されます。同じ名前と所有者を持つルールは作成できません。

- hrスキーマ内の表に対するDML変更について、TRUEと評価される条件が作成されます。

この例では、ルールの評価コンテキストは指定されていません。したがって、このルールは追加先となるルール・セットの評価コンテキストを継承します。または、DBMS_RULE_ADM.ADD_RULEプロシージャを実行してこのルールをルール・セットに追加するときに、明示的に評価コンテキストが割り当てられます。この時点では、ルールはどのルール・セットにも属していないため、このルールは評価できません。

また、DBMS_STREAMS_ADMパッケージの次のプロシージャを使用すると、自動的にルールを作成してルール・セットに追加できます。

- ADD_MESSAGE_PROPAGATION_RULE

- ADD_MESSAGE_RULE

- ADD_TABLE_PROPAGATION_RULES

- ADD_TABLE_RULES

- ADD_SUBSET_PROPAGATION_RULES

- ADD_SUBSET_RULES

- ADD_SCHEMA_PROPAGATION_RULES

- ADD_SCHEMA_RULES

- ADD_GLOBAL_PROPAGATION_RULES

- ADD_GLOBAL_RULES

ADD_SUBSET_PROPAGATION_RULESおよびADD_SUBSET_RULESを除き、前述のプロシージャは、Oracle Streamsクライアントのポジティブ・ルール・セットまたはネガティブ・ルール・セットにルールを追加できます。ADD_SUBSET_PROPAGATION_RULESおよびADD_SUBSET_RULESは、Oracle Streamsクライアントのポジティブ・ルール・セットのみにルールを追加できます。

関連項目:
Streamsクライアントを作成する方法の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

アクション・コンテキストを持つルールの作成

アクション・コンテキストを持つルールを作成するには、CREATE_RULEプロシージャを実行し、rule_nameパラメータを使用してルールの名前、conditionパラメータを使用してルール条件、action_contextパラメータを使用してルールのアクション・コンテキストを指定します。RE$NV_LIST型のADD_PAIRメンバー・プロシージャを使用すると、アクション・コンテキストに名前/値ペアを追加できます。

次の例では、非NULLのアクション・コンテキストを持つルールを作成します。

DECLARE
ac  SYS.RE$NV_LIST;
BEGIN
ac := SYS.RE$NV_LIST(NULL);
ac.ADD_PAIR('course_number', ANYDATA.CONVERTNUMBER(1057));
DBMS_RULE_ADM.CREATE_RULE(
rule_name      => 'strmadmin.rule_dep_10',
condition      => ' :dml.get_object_owner()=''HR'' AND ' ||
' :dml.get_object_name()=''EMPLOYEES'' AND ' ||
' (:dml.get_value(''NEW'', ''DEPARTMENT_ID'').AccessNumber()=10) AND ' ||
' :dml.get_command_type() = ''INSERT'' ',
action_context => ac);
END;
/

このプロシージャを実行すると、次のアクションが実行されます。

- strmadminスキーマにルールrule_dep_10が作成されます。同じ名前と所有者を持つルールは作成できません。

- department_idが10のhr.employees表への挿入についてTRUEと評価される条件が作成されます。

- 名前がcourse_numberで、値が1057の名前/値ペアを持つアクション・コンテキストが作成されます。

関連項目:
アクション・コンテキストにこのような名前/値ペアを使用する例については、「ルール・アクション・コンテキスト」を参照

ルールの変更

DBMS_RULE_ADMパッケージのALTER_RULEプロシージャを使用すると、既存のルールを変更できます。具体的には、このプロシージャを使用すると次のことができます。

- ルール条件の変更

- ルールの評価コンテキストの変更

- ルールの評価コンテキストの削除

- ルールのアクション・コンテキストの名前/値ペアの変更

- ルールのアクション・コンテキストへの名前/値ペアの追加

- ルールのアクション・コンテキストからの名前/値ペアの削除

- ルールに関するコメントの変更

- ルールに関するコメントの削除

ここでは、これらの変更の例をいくつか示します。

ルール条件の変更

ALTER_RULEプロシージャのconditionパラメータを使用すると、既存のルールの条件を変更できます。たとえば、「ルールの作成」で作成したルールの条件を変更する必要がある場合を考えます。既存のhr_dmlルールの条件は、hrスキーマ内の任意のオブジェクトに対する任意のDML変更についてTRUEと評価されます。このスキーマ内のemployees表に対する変更を除外する必要がある場合は、hr.employees表に対するDML変更についてはFALSEと評価されるが、このスキーマの他の表に対するDML変更については引き続きTRUEと評価されるように、このルールを変更できます。次のプロシージャを実行すると、ルールが前述のとおり変更されます。

BEGIN
DBMS_RULE_ADM.ALTER_RULE(
rule_name          => 'strmadmin.hr_dml',
condition          => ' :dml.get_object_owner() = ''HR'' AND NOT ' ||
' :dml.get_object_name() = ''EMPLOYEES'' ',
evaluation_context => NULL);
END;
/

注意:

- ルールの条件を変更すると、そのルールを含むすべてのルール・セットに影響します。

- ルールのアクション・コンテキストを保持しながらルールを変更するには、ALTER_RULEプロシージャのaction_contextパラメータにNULLを指定します。NULLは、action_contextパラメータのデフォルト値です。

- ルールが同期取得のルール・セットに含まれている場合、ルールの条件:dml.get_object_nameおよび:dml.get_object_ownerは変更しないでください。これらの条件を変更すると、同期取得でデータベース・オブジェクトの変更が取得されなくなる場合があります。同期取得のルールに含まれる他の条件は変更できます。

ルールのアクション・コンテキストの名前/値ペアの変更

ルールのアクション・コンテキストの名前/値ペアを変更するには、最初にルールのアクション・コンテキストから名前/値ペアを削除し、次にルールのアクション・コンテキストに異なる名前/値ペアを追加します。

この例では、ルールrule_dep_10の名前/値ペアを変更します。そのために、最初にこのルールのアクション・コンテキストから名前course_nameを持つ名前/値ペアを削除し、次に名前は同じ(course_name)で値は異なる名前/値ペアを追加します。この変更される名前/値ペアは「アクション・コンテキストを持つツールの作成」の例でルールに追加したものです。

アクション・コンテキストに、変更する名前/値ペアの他にも名前/値ペアが含まれている場合、アクション・コンテキストを変更するときには、他の名前/値ペアを変更または削除しないように注意してください。

次の手順に従って、アクション・コンテキストの名前/値ペアを変更します。

1. 次の問合せを実行すると、ルールのアクション・コンテキスト内の名前/値ペアを表示できます。

COLUMN ACTION_CONTEXT_NAME HEADING 'Action Context Name' FORMAT A25
COLUMN AC_VALUE_NUMBER HEADING 'Action Context Number Value' FORMAT 9999

SELECT
AC.NVN_NAME ACTION_CONTEXT_NAME,
AC.NVN_VALUE.ACCESSNUMBER() AC_VALUE_NUMBER
FROM DBA_RULES R, TABLE(R.RULE_ACTION_CONTEXT.ACTX_LIST) AC
WHERE RULE_NAME = 'RULE_DEP_10';

この問合せでは、次のような出力が表示されます。

Action Context Name       Action Context Number Value
------------------------- ---------------------------
course_number                                    1057

2. 名前/値ペアを変更します。他のユーザーがアクション・コンテキストを同時に変更していないことを確認してください。この手順では、最初にRE$NV_LIST型のREMOVE_PAIRメンバー・プロシージャを使用して、名前course_numberを含む名前/値ペアをrule_dep_10ルールのアクション・コンテキストから削除します。次に、この手順では、同じ型のADD_PAIRメンバー・プロシージャを使用して、新しい名前/値ペアを含む名前/値ペアをこのルールのアクション・コンテキストに追加します。この場合、追加する名前/値ペアの名前はcourse_number、値は1108になります。
この例では、ルールのアクション・コンテキストの既存の名前/値ペアを保持するために、変更前にルールのアクション・コンテキストを選択して変数に挿入しています。

DECLARE
action_ctx       SYS.RE$NV_LIST;
ac_name          VARCHAR2(30) := 'course_number';
BEGIN
SELECT RULE_ACTION_CONTEXT
INTO action_ctx
FROM DBA_RULES R
WHERE RULE_OWNER='STRMADMIN' AND RULE_NAME='RULE_DEP_10';
action_ctx.REMOVE_PAIR(ac_name);
action_ctx.ADD_PAIR(ac_name,
ANYDATA.CONVERTNUMBER(1108));
DBMS_RULE_ADM.ALTER_RULE(
rule_name       =>  'strmadmin.rule_dep_10',
action_context  => action_ctx);
END;
/

名前/値ペアが正しく変更されたかどうかを確認するには、手順1の問合せを再実行できます。この問合せでは、次のような出力が表示されます。

Action Context Name       Action Context Number Value
------------------------- ---------------------------
course_number                                    1108

ルールのアクション・コンテキストへの名前/値ペアの追加

RE$NV_LIST型のADD_PAIRメンバー・プロシージャを使用して新しいペアを追加する前に、アクション・コンテキストを選択して変数に挿入すると、アクション・コンテキスト内の既存の名前/値ペアを保持できます。他のユーザーがアクション・コンテキストを同時に変更していないことを確認してください。次の例では、rule_dep_10ルールのアクション・コンテキスト内の既存の名前/値ペアが保持され、名前がdist_listで値がadmin_listの新しい名前/値ペアが追加されます。

DECLARE
action_ctx       SYS.RE$NV_LIST;
ac_name          VARCHAR2(30) := 'dist_list';
BEGIN
action_ctx := SYS.RE$NV_LIST(SYS.RE$NV_ARRAY());
SELECT RULE_ACTION_CONTEXT
INTO action_ctx
FROM DBA_RULES R
WHERE RULE_OWNER='STRMADMIN' AND RULE_NAME='RULE_DEP_10';
action_ctx.ADD_PAIR(ac_name,
ANYDATA.CONVERTVARCHAR2('admin_list'));
DBMS_RULE_ADM.ALTER_RULE(
rule_name       =>  'strmadmin.rule_dep_10',
action_context  => action_ctx);
END;
/

名前/値ペアが正しく追加されたかどうかを確認するには、次の問合せを実行できます。

COLUMN ACTION_CONTEXT_NAME HEADING 'Action Context Name' FORMAT A25
COLUMN AC_VALUE_NUMBER HEADING 'Action Context|Number Value' FORMAT 9999
COLUMN AC_VALUE_VARCHAR2 HEADING 'Action Context|Text Value' FORMAT A25

SELECT
AC.NVN_NAME ACTION_CONTEXT_NAME,
AC.NVN_VALUE.ACCESSNUMBER() AC_VALUE_NUMBER,
AC.NVN_VALUE.ACCESSVARCHAR2() AC_VALUE_VARCHAR2
FROM DBA_RULES R, TABLE(R.RULE_ACTION_CONTEXT.ACTX_LIST) AC
WHERE RULE_NAME = 'RULE_DEP_10';

この問合せでは、次のような出力が表示されます。

Action Context Action Context
Action Context Name         Number Value Text Value
------------------------- -------------- -------------------------
course_number                       1088
dist_list                                admin_list

関連項目:
アクション・コンテキストに同様の名前/値ペアを使用する例については、「ルール・アクション・コンテキスト」を参照

ルールのアクション・コンテキストからの名前/値ペアの削除

RE$NV_LIST型のREMOVE_PAIRメンバー・プロシージャを使用して、ルールのアクション・コンテキストから名前/値ペアを削除できます。他のユーザーがアクション・コンテキストを同時に変更していないことを確認してください。

名前/値ペアを削除すると、ルールのアクション・コンテキストが変更されます。アクション・コンテキストに、削除する名前/値ペアの他にも名前/値ペアが含まれている場合、アクション・コンテキストを変更するときには、他の名前/値ペアを変更または削除しないように注意してください。

この例では、rule_dep_10ルールに次の名前/値ペアが含まれていることを想定しています。

名前

値

course_number

1088

dist_list

admin_list

関連項目:
次の項の例を完了していれば、rule_dep_10ルールにこれらの名前/値ペアが追加されています。

- 「アクション・コンテキストを持つルールの作成」

- 「ルールのアクション・コンテキストの名前/値ペアの変更」

- 「ルールのアクション・コンテキストへの名前/値ペアの追加」

この例では、既存のアクション・コンテキストを選択して変数に挿入し、名前がdist_listの名前/値ペアを削除します。これによって、rule_dep_10ルールのアクション・コンテキスト内の削除しない既存の名前/値ペアが保持されます。

DECLARE
action_ctx       SYS.RE$NV_LIST;
ac_name          VARCHAR2(30) := 'dist_list';
BEGIN
SELECT RULE_ACTION_CONTEXT
INTO action_ctx
FROM DBA_RULES R
WHERE RULE_OWNER='STRMADMIN' AND RULE_NAME='RULE_DEP_10';
action_ctx.REMOVE_PAIR(ac_name);
DBMS_RULE_ADM.ALTER_RULE(
rule_name       =>  'strmadmin.rule_dep_10',
action_context  =>  action_ctx);
END;
/

アクション・コンテキスト内の他の名前/値ペアを削除せずに名前/値ペアが正しく削除されたかどうかを確認するには、次の問合せを実行できます。

COLUMN ACTION_CONTEXT_NAME HEADING 'Action Context Name' FORMAT A25
COLUMN AC_VALUE_NUMBER HEADING 'Action Context|Number Value' FORMAT 9999
COLUMN AC_VALUE_VARCHAR2 HEADING 'Action Context|Text Value' FORMAT A25

SELECT
AC.NVN_NAME ACTION_CONTEXT_NAME,
AC.NVN_VALUE.ACCESSNUMBER() AC_VALUE_NUMBER,
AC.NVN_VALUE.ACCESSVARCHAR2() AC_VALUE_VARCHAR2
FROM DBA_RULES R, TABLE(R.RULE_ACTION_CONTEXT.ACTX_LIST) AC
WHERE RULE_NAME = 'RULE_DEP_10';

この問合せでは、次のような出力が表示されます。

Action Context Action Context
Action Context Name         Number Value Text Value
------------------------- -------------- -------------------------
course_number                       1108

システム作成ルールの変更

システム作成ルールとは、DBMS_STREAMS_ADMパッケージのプロシージャを実行して作成するルールです。DBMS_STREAMS_ADMパッケージを使用して必要なルール条件を持つルールを作成できない場合は、次の一般的な手順に従って、システム作成ルールに基づく条件を持つルールを作成できます。

1. システム作成ルールのルール条件をコピーします。DBA_STREAMS_RULESデータ・ディクショナリ・ビューを問い合せると、システム作成ルールのルール条件を表示できます。

2. 条件を変更します。

3. 変更した条件を持つルールを作成します。

4. 新しいルールをOracle Streamsの取得プロセス、伝播、適用プロセスまたはメッセージ・クライアントのルール・セットに追加します。

5. 元のルールが不要になった場合は、DBMS_STREAMS_ADMパッケージのREMOVE_RULEプロシージャを使用して削除します。

関連項目:

- 第6章「ルールベースの変換」

- Oracle Streamsに関連するデータ・ディクショナリ・ビューの詳細は、第22章「Oracle Streams環境の監視」を参照

ルールの削除

次の例では、DBMS_RULE_ADMパッケージのDROP_RULEプロシージャを実行して、データベースからhr_dmlルールを削除します。

BEGIN
DBMS_RULE_ADM.DROP_RULE(
rule_name => 'strmadmin.hr_dml',
force     => FALSE);
END;
/

この例では、DROP_RULEプロシージャのforceパラメータがFALSEに設定されています。これはデフォルト設定です。したがって、このルールが1つ以上のルール・セットに含まれている場合は削除できません。forceパラメータがTRUEに設定されている場合は、ルールがデータベースから削除され、それを含むルール・セットから自動的に削除されます。

評価コンテキスト、ルール・セットおよびルールに対する権限の管理

この項では、次のタスクの実行手順を説明します。

- 評価コンテキスト、ルール・セットおよびルールに対するシステム権限の付与

- 評価コンテキスト、ルール・セットまたはルールに対するオブジェクト権限の付与

- 評価コンテキスト、ルール・セットおよびルールに対するシステム権限の取消し

- 評価コンテキスト、ルール・セットまたはルールに対するオブジェクト権限の取消し

関連項目:

- 「ルールに関連するデータベース・オブジェクトと権限」

- 『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のDBMS_RULE_ADMパッケージのGRANT_SYSTEM_PRIVILEGEおよびGRANT_OBJECT_PRIVILEGEプロシージャに関する項を参照

評価コンテキスト、ルール・セットおよびルールに対するシステム権限の付与

DBMS_RULE_ADMパッケージのGRANT_SYSTEM_PRIVILEGEプロシージャを使用すると、評価コンテキスト、ルール・セットおよびルールに対するシステム権限をユーザーおよびロールに付与できます。これらの権限によって、ユーザーは自分のスキーマ内で、またはANYバージョンの権限が付与されている場合は任意のスキーマ内で、これらのオブジェクトを作成、変更、実行または削除できます。

たとえば、hrユーザーに自分のスキーマ内で評価コンテキストを作成するための権限を付与するには、権限の付与およびユーザーの変更を行うことができるユーザーとして接続し、次のように入力します。

BEGIN
DBMS_RULE_ADM.GRANT_SYSTEM_PRIVILEGE(
privilege    => SYS.DBMS_RULE_ADM.CREATE_EVALUATION_CONTEXT_OBJ,
grantee      => 'hr',
grant_option => FALSE);
END;
/

この例では、GRANT_SYSTEM_PRIVILEGEプロシージャのgrant_optionパラメータがFALSEに設定されています。これはデフォルト設定です。したがって、hrユーザーは、他のユーザーやロールにはCREATE_EVALUATION_CONTEXT_OBJシステム権限を付与できません。grant_optionパラメータをTRUEに設定した場合、hrユーザーはこのシステム権限を他のユーザーまたはロールに付与できます。

評価コンテキスト、ルール・セットまたはルールに対するオブジェクト権限の付与

DBMS_RULE_ADMパッケージのGRANT_OBJECT_PRIVILEGEプロシージャを使用すると、特定の評価コンテキスト、ルール・セットまたはルールに対するオブジェクト権限を付与できます。これらの権限を付与されたユーザーは、指定されたオブジェクトを変更または実行できます。

たとえば、hrユーザーに、strmadminスキーマ内のルール・セットhr_capture_rulesを変更および実行するための権限を付与するには、次のように入力します。

BEGIN
DBMS_RULE_ADM.GRANT_OBJECT_PRIVILEGE(
privilege    => SYS.DBMS_RULE_ADM.ALL_ON_RULE_SET,
object_name  => 'strmadmin.hr_capture_rules',
grantee      => 'hr',
grant_option => FALSE);
END;
/

この例では、GRANT_OBJECT_PRIVILEGEプロシージャのgrant_optionパラメータがFALSEに設定されています(デフォルト)。したがって、hrユーザーは、指定されたルール・セットに対するALL_ON_RULE_SETオブジェクト権限を他のユーザーやロールに付与できません。grant_optionパラメータをTRUEに設定した場合、hrユーザーはこのオブジェクト権限を他のユーザーまたはロールに付与できます。

評価コンテキスト、ルール・セットおよびルールに対するシステム権限の取消し

DBMS_RULE_ADMパッケージのREVOKE_SYSTEM_PRIVILEGEプロシージャを使用すると、評価コンテキスト、ルール・セットおよびルールに対するシステム権限を取り消すことができます。

たとえば、hrユーザーが自分のスキーマ内で評価コンテキストを作成するための権限を取り消すには、権限の付与およびユーザーの変更を行うことができるユーザーとして接続し、次のように入力します。

BEGIN
DBMS_RULE_ADM.REVOKE_SYSTEM_PRIVILEGE(
privilege    => SYS.DBMS_RULE_ADM.CREATE_EVALUATION_CONTEXT_OBJ,
revokee      => 'hr');
END;
/

評価コンテキスト、ルール・セットまたはルールに対するオブジェクト権限の取消し

DBMS_RULE_ADMパッケージのREVOKE_OBJECT_PRIVILEGEプロシージャを使用すると、特定の評価コンテキスト、ルール・セットまたはルールに対するオブジェクト権限を取り消すことができます。

たとえば、hrユーザーから、strmadminスキーマ内のルール・セットhr_capture_rulesを変更および実行するための権限を取り消すには、次のように入力します。

BEGIN
DBMS_RULE_ADM.REVOKE_OBJECT_PRIVILEGE(
privilege    => SYS.DBMS_RULE_ADM.ALL_ON_RULE_SET,
object_name  => 'strmadmin.hr_capture_rules',
revokee      => 'hr');
END;
/

19 ルールベースの変換の管理

Oracle Streamsでのルールベースの変換は、ポジティブ・ルール・セットのルールがTRUEに評価される場合に行われるメッセージの変更を意味します。ルールベースの変換には、宣言とカスタムという2つのタイプがあります。

次の項では、ルールベースの変換の管理について説明します。

- 宣言ルールベースの変換の管理

- カスタム・ルールベース変換の管理

注意:
ルールがポジティブ・ルール・セットに含まれる場合にのみ、ルールに指定した変換が実行されます。ルールが取得プロセス、伝播、適用プロセスまたはメッセージ・クライアントのネガティブ・ルール・セットに含まれる場合、これらのOracle Streamsクライアントではルールベースの変換が無視されます。

関連項目:

- 第6章「ルールベースの変換」

宣言ルールベースの変換の管理

宣言ルールベースの変換を管理するには、DBMS_STREAMS_ADMパッケージのADD_COLUMN、DELETE_COLUMN、KEEP_COLUMNS、RENAME_COLUMN、RENAME_SCHEMAおよびRENAME_TABLEプロシージャを使用します。

この項では、次のタスクの実行手順を説明します。

- 宣言ルールベースの変換の追加

- 既存の宣言ルールベースの変換の上書き

- 宣言ルールベースの変換の削除

宣言ルールベースの変換の追加

次の各項では、宣言ルールベースの変換をDMLルールに追加する例について説明します。

注意:
DMLルールに対してのみ宣言ルールベースの変換を指定できます。DDLルールには指定できません。

表名を変更する宣言ルールベースの変換の追加

DBMS_STREAMS_ADMパッケージのRENAME_TABLEプロシージャを使用して、行LCR内の表名を変更する宣言ルールベースの変換を追加します。たとえば、次のプロシージャを実行すると、strmadminスキーマのjobs12ルールに宣言ルールベースの変換が追加されます。

BEGIN
DBMS_STREAMS_ADM.RENAME_TABLE(
rule_name       => 'strmadmin.jobs12',
from_table_name => 'hr.jobs',
to_table_name   => 'hr.assignments',
step_number     => 0,
operation       => 'ADD');
END;
/

このプロシージャによって追加された宣言ルールベースの変換では、ルールjobs12が行LCRについてTRUEと評価された場合に、行LCR内の表hr.jobsの名前がhr.assignmentsに変更されます。jobs12ルールに複数の宣言ルールベースの変換が指定された場合、step_numberパラメータが0(ゼロ)に設定されているため、この変換はデフォルトの変換順序に従って実行されます。また、operationパラメータがADDに設定されており、変換はルールから削除されるのではなく、ルールに追加されることを示しています。

RENAME_TABLEプロシージャでは、表の他にスキーマ名を変更する変換を追加することもできます。たとえば、前述の例でスキーマ名をoeに変更するように指定するには、to_table_nameパラメータにoe.assignmentsを指定します。

列を追加する宣言ルールベースの変換の追加

DBMS_STREAMS_ADMパッケージのADD_COLUMNプロシージャを使用して、行LCR内の行に列を追加する宣言ルールベースの変換を追加します。たとえば、次のプロシージャを実行すると、strmadminスキーマのemployees35ルールに宣言ルールベースの変換が追加されます。

BEGIN
DBMS_STREAMS_ADM.ADD_COLUMN(
rule_name    => 'employees35',
table_name   => 'hr.employees',
column_name  => 'birth_date',
column_value => ANYDATA.ConvertDate(NULL),
value_type   => 'NEW',
step_number  => 0,
operation    => 'ADD');
END;
/

このプロシージャによって追加された宣言ルールベースの変換では、ルールemployees35が行LCRについてTRUEと評価された場合に、行LCR内のhr.employees表の行に、データ型DATEのbirth_date列が追加されます。

ANYDATA.ConvertDateファンクションによって列の型および列の値が指定されることに注意してください。この例では、追加された列の値はNULLです。ただし、有効な日付を指定することもできます。追加する列に適したANYDATAファンクションを使用します。たとえば、追加する列のデータ型がNUMBERである場合、ANYDATA.ConvertNumberファンクションを使用します。

value_typeパラメータがNEWに設定されており、これは、行LCR内の新しい値に列が追加されることを示しています。OLDを指定して、古い値に列を追加することもできます。

employees35ルールに複数の宣言ルールベースの変換が指定された場合、step_numberパラメータが0(ゼロ)に設定されているため、この変換はデフォルトの変換順序に従って実行されます。また、operationパラメータがADDに設定されており、変換はルールから削除されるのではなく、ルールに追加されることを示しています。

注意:
ADD_COLUMNプロシージャはオーバーロードされます。column_functionパラメータを指定すると、追加された列の値を現行のシステム日付またはタイムスタンプにすることができます。column_valueとcolumn_functionパラメータは相互に排他的です。

関連項目:
AnyData型ファンクションの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

既存の宣言ルールベースの変換の上書き

宣言ルールベースの変換を追加するプロシージャのoperationパラメータをADDに設定すると、次のリストのパラメータが既存の変換パラメータと一致した場合に、既存の宣言ルールベースの変換が上書きされます。

- ADD_COLUMNプロシージャ: rule_name、table_name、column_nameおよびstep_numberパラメータ

- DELETE_COLUMNプロシージャ: rule_name、table_name、column_nameおよびstep_numberパラメータ

- KEEP_COLUMNSプロシージャ: rule_name、table_name、column_listおよびstep_numberパラメータ、またはrule_name、table_name、column_tableおよびstep_numberパラメータ(column_listおよびcolumn_tableパラメータは相互に排他的です)

- RENAME_COLUMNプロシージャ: rule_name、table_name、from_column_nameおよびstep_numberパラメータ

- RENAME_SCHEMAプロシージャ: rule_name、from_schema_nameおよびstep_numberパラメータ

- RENAME_TABLEプロシージャ: rule_name、from_table_nameおよびstep_numberパラメータ

たとえば、次のプロシージャを実行して、既存の宣言ルールベースの変換を作成したとします。

BEGIN
DBMS_STREAMS_ADM.RENAME_COLUMN(
rule_name         => 'departments33',
table_name        => 'hr.departments',
from_column_name  => 'manager_id',
to_column_name    => 'lead_id',
value_type        => 'NEW',
step_number       => 0,
operation         => 'ADD');
END;
/

次のプロシージャを実行すると、この既存の宣言ルールベースの変換は上書きされます。

BEGIN
DBMS_STREAMS_ADM.RENAME_COLUMN(
rule_name         => 'departments33',
table_name        => 'hr.departments',
from_column_name  => 'manager_id',
to_column_name    => 'lead_id',
value_type        => '*',
step_number       => 0,
operation         => 'ADD');
END;
/

この場合、宣言ルールベースの変換のvalue_typeパラメータがNEWから*に変更されています。つまり、元の変換では新しい値の名前のみが行LCRで変更されますが、新しい変換では古い値と新しい値の両方の名前が行LCRで変更されます。

宣言ルールベースの変換の削除

宣言ルールベースの変換をルールから削除するには、変換を追加するために使用したものと同じプロシージャを使用しますが、operationパラメータにREMOVEを指定します。たとえば、「表名を変更する宣言ルールベースの変換の追加」で追加した変換を削除するには、次のプロシージャを実行します。

BEGIN
DBMS_STREAMS_ADM.RENAME_TABLE(
rule_name       => 'strmadmin.jobs12',
from_table_name => 'hr.jobs',
to_table_name   => 'hr.assignments',
step_number     => 0,
operation       => 'REMOVE');
END;
/

「宣言ルールベースの変換の管理」に示すいずれかの宣言変換プロシージャでoperationパラメータがREMOVEに設定されている場合、そのプロシージャのrule_nameパラメータ以外のパラメータはオプションになります。これらのオプションのパラメータがNULLに設定されている場合、これらはワイルドカードになります。

前述の例のRENAME_TABLEプロシージャは、1つ以上のオプションのパラメータがNULLに設定されている場合、次のように動作します。

from_table_nameパラメータ

to_table_nameパラメータ

step_numberパラメータ

結果

NULL

NULL

NULL

指定したルールからすべての表名変更変換が削除されます

NULL以外

NULL

NULL

指定したfrom_table_nameを含むすべての表名変更変換が、指定したルールから削除されます

NULL

NULL以外

NULL

指定したto_table_nameを含むすべての表名変更変換が、指定したルールから削除されます

NULL

NULL

NULL以外

指定したstep_numberを含むすべての表名変更変換が、指定したルールから削除されます

NULL以外

NULL以外

NULL

指定したfrom_table_nameおよびto_table_nameを含むすべての表名変更変換が、指定したルールから削除されます

NULL

NULL以外

NULL以外

指定したto_table_nameおよびstep_numberを含むすべての表名変更変換が、指定したルールから削除されます

NULL以外

NULL

NULL以外

指定したfrom_table_nameおよびstep_numberを含むすべての表名変更変換が、指定したルールから削除されます

オプションのパラメータをNULLに設定してoperationパラメータをREMOVEに設定した場合、他の宣言変換プロシージャも同様に動作します。

カスタム・ルールベース変換の管理

ルールのカスタム・ルールベースの変換を設定または設定解除するには、DBMS_STREAMS_ADMパッケージのSET_RULE_TRANSFORM_FUNCTIONプロシージャを使用します。このプロシージャは、ルールのアクション・コンテキストを変更して、カスタム・ルールベースの変換を指定します。

この項では、次のタスクの実行手順を説明します。

- カスタム・ルールベースの変換の作成

- カスタム・ルールベースの変換の変更

- カスタム・ルールベース変換の設定解除

注意:
LCRのLONG、LONG RAW、LOBまたはXMLType列のデータは、カスタム・ルールベースの変換で変更しないでください。

注意:

- ルールのアクション・コンテキストには自動ロック・メカニズムがありません。このため、アクション・コンテキストを複数のセッションで同時に更新しないようにしてください。

- DDL LCRに対してカスタム・ルールベースの変換を実行するときは、他の変更と一致するようにDDL LCRのDDLテキストの変更が必要になる場合があります。たとえば、DDL LCRの表の名前を変換で変更する場合は、DDLテキストの表名も変換によって同じように変更することが必要です。

カスタム・ルールベースの変換の作成

カスタム・ルールベースの変換ファンクションは、常に1つのメッセージに対して動作しますが、1つまたは多数のメッセージを戻すことができます。1つのメッセージを戻すカスタム・ルールベースの変換ファンクションは、1対1の変換ファンクションです。1対1の変換ファンクションには、次のシグネチャが必要です。

FUNCTION user_function (
parameter_name   IN  ANYDATA)
RETURN ANYDATA;

user_functionはファンクション名で、parameter_nameはファンクションに渡されるパラメータの名前です。ファンクションに渡されるパラメータはメッセージをANYDATAにカプセル化したもので、ファンクションではANYDATAにカプセル化したメッセージを戻す必要があります。

2つ以上のメッセージを戻すことができるカスタム・ルールベースの変換ファンクションは、1対多の変換ファンクションです。1対多の変換ファンクションには、次のシグネチャが必要です。

FUNCTION user_function (
parameter_name   IN  ANYDATA)
RETURN STREAMS$_ANYDATA_ARRAY;

user_functionはファンクション名で、parameter_nameはファンクションに渡されるパラメータの名前です。ファンクションに渡されるパラメータはメッセージをANYDATAにカプセル化したもので、ファンクションはカプセル化したANYDATAメッセージを0個以上含む配列を戻す必要があります。配列に含まれるカプセル化したANYDATAメッセージが0個の場合､元のメッセージは廃棄されます。1対多の変換ファンクションは、Oracle Streamsの取得プロセスおよび同期取得に対してのみサポートされます。

STREAMS$_ANYDATA_ARRAY型はOracleが提供する型で、次の定義を持ちます。

CREATE OR REPLACE TYPE SYS.STREAMS$_ANYDATA_ARRAY
AS VARRAY(2147483647) of SYS.ANYDATA
/

次の手順では、1対1のファンクションを使用するカスタム・ルールベースの変換を作成する一般的な手順について説明します。

1. SQL*Plusで、管理ユーザーまたはPL/SQLファンクションを所有するユーザーとしてデータベースに接続します。この例では、hrユーザーとして接続します。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

2. 変換を実行するPL/SQLファンクションを作成します。

注意:
変換ファンクションが決定的であるようにしてください。決定的なファンクションでは、入力された引数の値がどのような組合せであっても、常に同じ値が戻されます。また、変換ファンクションで例外が発生しないようにしてください。例外により、取得プロセス、伝播または適用プロセスが無効化される場合があり、これらの処理を続行するために変換ファンクションの修正が必要になります。同期取得のカスタム・ルールベースの変換で例外が発生すると、その例外を発生させたDML文が強制終了されます。メッセージ・クライアントのカスタム・ルールベースの変換で例外が発生すると、メッセージ・クライアントでメッセージをデキューできなくなる場合があります。

次の例では、departments表のdepartment_name列の値をExecutiveからManagementに変更するファンクションexecutive_to_managementがhrスキーマ内に作成されます。会社の事業所の1つがこの部門に異なる名称を使用している場合に、このような変換が必要になることがあります。

CREATE OR REPLACE FUNCTION hr.executive_to_management(in_any IN ANYDATA)
RETURN ANYDATA
IS
lcr SYS.LCR$_ROW_RECORD;
rc  NUMBER;
ob_owner VARCHAR2(30);
ob_name VARCHAR2(30);
dep_value_anydata ANYDATA;
dep_value_varchar2 VARCHAR2(30);
BEGIN
-- Get the type of object
-- Check if the object type is SYS.LCR$_ROW_RECORD
IF in_any.GETTYPENAME='SYS.LCR$_ROW_RECORD' THEN
-- Put the row LCR into lcr
rc := in_any.GETOBJECT(lcr);
-- Get the object owner and name
ob_owner := lcr.GET_OBJECT_OWNER();
ob_name := lcr.GET_OBJECT_NAME();
-- Check for the hr.departments table
IF ob_owner = 'HR' AND ob_name = 'DEPARTMENTS' THEN
-- Get the old value of the department_name column in the LCR
dep_value_anydata := lcr.GET_VALUE('old','DEPARTMENT_NAME');
IF dep_value_anydata IS NOT NULL THEN
-- Put the column value into dep_value_varchar2
rc := dep_value_anydata.GETVARCHAR2(dep_value_varchar2);
-- Change a value of Executive in the column to Management
IF (dep_value_varchar2 = 'Executive') THEN
lcr.SET_VALUE('OLD','DEPARTMENT_NAME',
ANYDATA.CONVERTVARCHAR2('Management'));
END IF;
END IF;
-- Get the new value of the department_name column in the LCR
dep_value_anydata := lcr.GET_VALUE('new', 'DEPARTMENT_NAME', 'n');
IF dep_value_anydata IS NOT NULL THEN
-- Put the column value into dep_value_varchar2
rc := dep_value_anydata.GETVARCHAR2(dep_value_varchar2);
-- Change a value of Executive in the column to Management
IF (dep_value_varchar2 = 'Executive') THEN
lcr.SET_VALUE('new','DEPARTMENT_NAME',
ANYDATA.CONVERTVARCHAR2('Management'));
END IF;
END IF;
END IF;
RETURN ANYDATA.CONVERTOBJECT(lcr);
END IF;
RETURN in_any;
END;
/

3. Oracle Streams管理者にhr.executive_to_managementファンクションのEXECUTE権限を付与します。

GRANT EXECUTE ON hr.executive_to_management TO strmadmin;

4. データベースにOracle Streams管理者として接続します。

5. hr.departments表のDML操作についてサブセット・ルールを作成します。このサブセット・ルールでは、手順2で作成した変換を使用します。
カスタム・ルールベースの変換を使用する場合、サブセット・ルールは不要です。この例では、複数の名前/値ペアを持つアクション・コンテキストの具体例を示すために、サブセット・ルールを使用しています。この例では、データベースdbs1.example.comの適用プロセスにサブセット・ルールを作成します。これらのルールがTRUEと評価されるのは、hr.departments表内のlocation_idが1700の1行に対するDML変更がLCRに含まれる場合です。この例では、streams_queueというANYDATAキューがデータベースに存在することを想定しています。

これらのルールを作成するには、次のADD_SUBSET_RULESプロシージャを実行します。

BEGIN
DBMS_STREAMS_ADM.ADD_SUBSET_RULES(
table_name               =>  'hr.departments',
dml_condition            =>  'location_id=1700',
streams_type             =>  'apply',
streams_name             =>  'strm01_apply',
queue_name               =>  'streams_queue',
include_tagged_lcr       =>  FALSE,
source_database          =>  'dbs1.example.com');
END;
/

注意:

- Oracle Streams管理者がルールとルール・セットを作成するには、CREATE_RULE_SET_OBJ(またはCREATE_ANYRULE_SET_OBJ)およびCREATE_RULE_OBJ(またはCREATE_ANY_RULE_OBJ)システム権限が必要です。これらの権限を付与するには、DBMS_RULE_ADMパッケージのGRANT_SYSTEM_PRIVILEGEプロシージャを使用します。

- この例では、DBMS_STREAMS_ADMパッケージを使用してルールを作成します。また、DBMS_RULE_ADMパッケージを使用してルールを作成し、ルール・セットに追加し、カスタム・ルールベースの変換を指定することもできます。このプロシージャの例については、『Oracle Streams拡張例』を参照してください。

- ADD_SUBSET_RULESプロシージャでは、適用プロセスのポジティブ・ルール・セットにサブセット・ルールが追加されます。

6. 次の問合せを実行して、システムで作成されたルールの名前を特定します。

SELECT RULE_NAME, SUBSETTING_OPERATION FROM DBA_STREAMS_RULES
WHERE OBJECT_NAME='DEPARTMENTS' AND DML_CONDITION='location_id=1700';

この問合せでは、次のような出力が表示されます。

RULE_NAME                      SUBSET
------------------------------ ------
DEPARTMENTS5                   INSERT
DEPARTMENTS6                   UPDATE
DEPARTMENTS7                   DELETE

注意:
この情報を取得するには、ADD_SUBSET_RULESを実行するときにOUTパラメータを使用する方法もあります。

これらはサブセット・ルールであるため、そのうちの2つには内部変換を実行するNULL以外のアクション・コンテキストが含まれています。

- サブセット化条件INSERTを持つルールには、更新によってlocation_id列の値が他の値から1700に変更される場合に、更新を挿入に変換する内部変換が含まれています。内部変換は、挿入には影響しません。

- サブセット化条件DELETEを持つルールには、更新によってlocation_id列の値が1700から他の値に変更される場合に、更新を削除に変換する内部変換が含まれています。内部変換は、削除には影響しません。

この例では、次の問合せを実行すると、ルールDEPARTMENTS5およびDEPARTMENTS7がNULL以外のアクション・コンテキストを持ち、ルールDEPARTMENTS6がNULLのアクション・コンテキストを持つことを確認できます。

COLUMN RULE_NAME HEADING 'Rule Name' FORMAT A13
COLUMN ACTION_CONTEXT_NAME HEADING 'Action Context Name' FORMAT A27
COLUMN ACTION_CONTEXT_VALUE HEADING 'Action Context Value' FORMAT A30

SELECT
RULE_NAME,
AC.NVN_NAME ACTION_CONTEXT_NAME,
AC.NVN_VALUE.ACCESSVARCHAR2() ACTION_CONTEXT_VALUE
FROM DBA_RULES R, TABLE(R.RULE_ACTION_CONTEXT.ACTX_LIST) AC
WHERE RULE_NAME IN ('DEPARTMENTS5','DEPARTMENTS6','DEPARTMENTS7');

この問合せでは、次のような出力が表示されます。

Rule Name     Action Context Name         Action Context Value
------------- --------------------------- ------------------------------
DEPARTMENTS5  STREAMS$_ROW_SUBSET         INSERT
DEPARTMENTS7  STREAMS$_ROW_SUBSET         DELETE

DEPARTMENTS6ルールは、アクション・コンテキストがNULLであるため出力には表示されません。

7. SET_RULE_TRANSFORM_FUNCTIONプロシージャを実行して、カスタム・ルールベースの変換をサブセット・ルールごとに設定します。この手順では、このプロシージャをルールごとに実行し、hr.executive_to_managementを変換ファンクションとして指定します。他のユーザーがアクション・コンテキストを同時に変更していないことを確認してください。

BEGIN
DBMS_STREAMS_ADM.SET_RULE_TRANSFORM_FUNCTION(
rule_name           => 'departments5',
transform_function  => 'hr.executive_to_management');
DBMS_STREAMS_ADM.SET_RULE_TRANSFORM_FUNCTION(
rule_name           => 'departments6',
transform_function  => 'hr.executive_to_management');
DBMS_STREAMS_ADM.SET_RULE_TRANSFORM_FUNCTION(
rule_name           => 'departments7',
transform_function  => 'hr.executive_to_management');
END;
/

具体的には、このプロシージャでは、STREAMS$_TRANSFORM_FUNCTIONを名前として指定し、変換を実行するPL/SQLファンクションの名前を含むANYDATAインスタンスを値として指定する各ルールのアクション・コンテキストに、名前/値ペアが追加されます。この場合、変換ファンクションはhr.executive_to_managementです。

注意:
SET_RULE_TRANSFORM_FUNCTIONでは、指定した変換ファンクションが存在するかどうかは検証されません。そのファンクションが存在しない場合、Oracle Streamsのプロセスまたはジョブで変換ファンクションの起動が試行されたときにエラーが発生します。

これらのルールのアクション・コンテキスト内の名前/値ペアを表示する問合せを実行すると、DEPARTMENTS6ルールを含め、ルールごとにカスタム・ルールベースの変換用の名前/値ペアが表示されます。

SELECT
RULE_NAME,
AC.NVN_NAME ACTION_CONTEXT_NAME,
AC.NVN_VALUE.ACCESSVARCHAR2() ACTION_CONTEXT_VALUE
FROM DBA_RULES R, TABLE(R.RULE_ACTION_CONTEXT.ACTX_LIST) AC
WHERE RULE_NAME IN ('DEPARTMENTS5','DEPARTMENTS6','DEPARTMENTS7');

この問合せでは、次のような出力が表示されます。

Rule Name     Action Context Name         Action Context Value
------------- --------------------------- ------------------------------
DEPARTMENTS5  STREAMS$_ROW_SUBSET         INSERT
DEPARTMENTS5  STREAMS$_TRANSFORM_FUNCTION "HR"."EXECUTIVE_TO_MANAGEMENT"
DEPARTMENTS6  STREAMS$_TRANSFORM_FUNCTION "HR"."EXECUTIVE_TO_MANAGEMENT"
DEPARTMENTS7  STREAMS$_ROW_SUBSET         DELETE
DEPARTMENTS7  STREAMS$_TRANSFORM_FUNCTION "HR"."EXECUTIVE_TO_MANAGEMENT"

また、DBA_STREAMS_TRANSFORM_FUNCTIONデータ・ディクショナリ・ビューを使用して、変換ファンクションを表示することもできます。

関連項目:
この例で使用したSET_RULE_TRANSFORM_FUNCTIONおよびルールのタイプの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

カスタム・ルールベースの変換の変更

カスタム・ルールベースの変換を変更するには、変換ファンクションを編集するか、またはSET_RULE_TRANSFORM_FUNCTIONプロシージャを実行して異なる変換ファンクションを指定します。この例では、SET_RULE_TRANSFORM_FUNCTIONプロシージャを実行して異なる変換ファンクションを指定します。SET_RULE_TRANSFORM_FUNCTIONプロシージャでは、指定したルールのアクション・コンテキストが変更され、異なる変換ファンクションが実行されるようになります。変換ファンクション自体を編集する場合は、このプロシージャを実行する必要はありません。

この例では、変換ファンクションをhr.execute_to_managementからhr.executive_to_leadに変更して、ルールDEPARTMENTS5のカスタム・ルールベースの変換を変更します。hr.execute_to_managementルールベースの変換は、「カスタム・ルールベースの変換の作成」の例のDEPARTMENTS5ルールに追加したものです。

Oracle Streamsでは、場合によっては、UPDATE操作をINSERTおよびDELETE操作に変換する内部変換が、アクション・コンテキスト内の名前/値ペアを使用してサブセット・ルールによって実行されます。このような変換は、行の移行と呼ばれます。SET_RULE_TRANSFORM_FUNCTIONプロシージャでは、行の移行を実行する名前/値ペアが保持されます。

関連項目:
行の移行の詳細は、「行の移行およびサブセット・ルール」を参照

カスタム・ルールベースの変換を変更するには、次の手順を実行します。

1. 次の問合せを実行すると、ルールのアクション・コンテキスト内のすべての名前/値ペアを表示できます。

COLUMN ACTION_CONTEXT_NAME HEADING 'Action Context Name' FORMAT A30
COLUMN ACTION_CONTEXT_VALUE HEADING 'Action Context Value' FORMAT A30

SELECT
AC.NVN_NAME ACTION_CONTEXT_NAME,
AC.NVN_VALUE.ACCESSVARCHAR2() ACTION_CONTEXT_VALUE
FROM DBA_RULES R, TABLE(R.RULE_ACTION_CONTEXT.ACTX_LIST) AC
WHERE RULE_NAME = 'DEPARTMENTS5';

この問合せでは、次のような出力が表示されます。

Action Context Name            Action Context Value
------------------------------ ------------------------------
STREAMS$_ROW_SUBSET            INSERT
STREAMS$_TRANSFORM_FUNCTION    "HR"."EXECUTIVE_TO_MANAGEMENT"

2. SET_RULE_TRANSFORM_FUNCTIONプロシージャを実行して、DEPARTMENTS5ルールの変換ファンクションをexecutive_to_leadに設定します。この例では、新しい変換ファンクションがhr.executive_to_leadで、strmadminユーザーにはそのEXECUTE権限が付与されていると想定しています。

BEGIN
DBMS_STREAMS_ADM.SET_RULE_TRANSFORM_FUNCTION(
rule_name           => 'departments5',
transform_function  => 'hr.executive_to_lead');
END;
/

変換ファンクションが正しく変更されたかどうかを確認するには、手順1の問合せを再実行します。3つのサブセット・ルールの一貫性を保つために、DEPARTMENTS6およびDEPARTMENTS7ルールのアクション・コンテキストも同様に変更する必要があります。

注意:

- SET_RULE_TRANSFORM_FUNCTIONでは、指定した変換ファンクションが存在するかどうかは検証されません。そのファンクションが存在しない場合、Oracle Streamsのプロセスまたはジョブで変換ファンクションの起動が試行されたときにエラーが発生します。

- カスタム・ルールベースの変換ファンクションが、Oracle Streamsクライアントがそのファンクションへのアクセスを試行したのと同時に変更された場合、エラーが発生することがあります。

カスタム・ルールベースの変換の設定解除

カスタム・ルールベースの変換をルールから設定解除するには、SET_RULE_TRANSFORM_FUNCTIONを実行し、変換ファンクションにNULLを指定します。NULLを指定すると、ルールのアクション・コンテキストでカスタム・ルールベースの変換を指定する名前/値ペアが設定解除されます。この例では、ルールDEPARTMENTS5からカスタム・ルールベースの変換を設定解除します。この変換は、「カスタム・ルールベースの変換の作成」の例のDEPARTMENTS5ルールに追加したものです。

Oracle Streamsでは、場合によっては、UPDATE操作をINSERTおよびDELETE操作に変換する内部変換が、アクション・コンテキスト内の名前/値ペアを使用してサブセット・ルールによって実行されます。このような変換は、行の移行と呼ばれます。SET_RULE_TRANSFORM_FUNCTIONプロシージャでは、行の移行を実行する名前/値ペアが保持されます。

関連項目:
行の移行の詳細は、「行の移行およびサブセット・ルール」を参照

次のプロシージャを実行して、ルールDEPARTMENTS5のカスタム・ルールベースの変換を設定解除します。

BEGIN
DBMS_STREAMS_ADM.SET_RULE_TRANSFORM_FUNCTION(
rule_name           => 'departments5',
transform_function  => NULL);
END;
/

変換ファンクションが設定解除されたかどうかを確認するには、手順1の問合せを実行します。3つのサブセット・ルールの一貫性を保つために、DEPARTMENTS6およびDEPARTMENTS7ルールのアクション・コンテキストも同様に変更する必要があります。

関連項目:
行の移行の詳細は、「行の移行およびサブセット・ルール」を参照

20 Oracle Streamsを使用した表の変更の記録

この章では、Oracle Streamsを使用して、表に対するデータ操作言語(DML)の変更を記録する方法について説明します。

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

- Oracle Streamsを使用した表の変更の記録について

- 表の変更を記録するOracle Streams環境の準備

- 表の変更を記録するOracle Streams環境の構成

- 表の変更を記録するOracle Streams環境の管理

- 表の変更を記録するOracle Streams環境の監視

Oracle Streamsを使用した表の変更の記録について

Oracle Streamsでは、挿入、更新および削除に関する情報など、データベース表に対する変更に関する情報を記録できます。変更が記録される表はソース・テーブルと呼ばれ、記録された変更に関する情報はチェンジ・テーブルと呼ばれる別の表に格納されます。また、ソース・テーブルが存在するデータベースはソース・データベースと呼ばれ、チェンジ・テーブルが存在するデータベースは宛先データベースと呼ばれます。宛先データベースは、ソース・データベースと同じデータベースにすることも、異なるデータベースにすることもできます。

記録される情報は、DML操作によって各行で変更されたデータ、および各変更に関するメタデータを示すものです。通常、データ・ウェアハウス環境では表の変更に関する情報が記録されますが、他のタイプの環境では表の変更が追跡されることもあります。

Oracle Streamsの適用プロセスでは、表の変更をチェンジ・テーブルに記録するために、変更ハンドラを使用します。変更ハンドラは、表の変更を追跡する特別なタイプの文DMLハンドラであり、DBMS_STREAMS_ADM.MAINTAIN_CHANGE_TABLEプロシージャまたはDBMS_APPLY_ADM.SET_CHANGE_HANDLERプロシージャのいずれかによって作成されたものです。この章では、これらのプロシージャを使用して変更ハンドラを作成および管理する方法について説明します。変更ハンドラに関する情報は、ALL_APPLY_CHANGE_HANDLERSおよびDBA_APPLY_CHANGE_HANDLERSビューに格納されます。

注意:
変更ハンドラのプロシージャを使用しなくても、表の変更を追跡する文DMLハンドラを作成できます。このような文DMLハンドラは技術的には変更ハンドラとみなされず、その情報もALL_APPLY_CHANGE_HANDLERSおよびDBA_APPLY_CHANGE_HANDLERSビューには格納されません。

関連項目:

- 「文DMLハンドラ」

- 「文DMLハンドラの管理」

- 「文DMLハンドラに関する情報の表示」

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

表の変更を記録するOracle Streams環境の準備

DBMS_STREAMS_ADMパッケージのMAINTAIN_CHANGE_TABLEプロシージャでは、ソース・テーブルに対する変更を記録するOracle Streams環境を構成できます。このプロシージャでは、必要なすべてのOracle Streamsコンポーネントを構成します。また、このプロシージャを使用すると、各変更に関して記録するメタデータを識別できます。たとえば、他の多くのタイプのメタデータと同様に、変更を行ったユーザーのユーザー名と変更時間を記録するように指定できます。

MAINTAIN_CHANGE_TABLEプロシージャを使用して、表の変更を記録するOracle Stream環境を構成する前に、いくつかの決定を行い、前提条件を満たす必要があります。

次の各項では、MAINTAIN_CHANGE_TABLEプロシージャに関する決定と前提条件について説明します。

- MAINTAIN_CHANGE_TABLEプロシージャを実行する前に行う決定

- MAINTAIN_CHANGE_TABLEプロシージャに関する前提条件

MAINTAIN_CHANGE_TABLEプロシージャを実行する前に行う決定

次の各項では、MAINTAIN_CHANGE_TABLEプロシージャを実行する前に行う決定について説明します。

- 構成する環境のタイプの決定

- 追跡する列の決定

- 記録するメタデータの決定

- 更新操作に応じて追跡する値の決定

- KEEP_COLUMNS変換を構成するかどうかの決定

- チェンジ・テーブルに対してCREATE TABLEオプションを指定するかどうかの決定

- 構成アクションを直接実行するか、スクリプトで実行するかの決定

- ソース・テーブルをレプリケートするかどうかの決定

構成する環境のタイプの決定

表の変更を記録するOracle Streams環境は、次のコンポーネントで構成されます。

1. 取得プロセスは、ソース・テーブルに対する変更に関する情報をREDOログから取得します。取得プロセスは、行論理変更レコード(行LCR)の各行変更に関する情報をカプセル化します。変更が行われるデータベースはソース・データベースと呼ばれます。取得プロセスが実行されるデータベースは取得データベースと呼ばれます。

2. 伝播は、ソース・テーブルとチェンジ・テーブルが異なるデータベースにある場合に、取得された行LCRをチェンジ・テーブルが存在するデータベースに送信します。ソース・テーブルとチェンジ・テーブルが同じデータベースにある場合、伝播は不要です。

3. 適用プロセスは、情報をチェンジ・テーブルに記録します。適用プロセスは、文DMLハンドラを使用して、行LCR内の情報をチェンジ・テーブルに挿入します。

これらのコンポーネントは、次の方法で構成できます。

- 1つのデータベースでのローカル取得とローカル適用: ソース・テーブル、取得プロセス、適用プロセスおよびチェンジ・テーブルがすべて同じデータベースにあります。すべてのコンポーネントが1つのデータベースにあるため、構成およびメンテナンスが最も容易なオプションです。

- ローカル取得とリモート適用: 1つのデータベースにソース・テーブルと取得プロセスがあり、もう1つのデータベースに適用プロセスとチェンジ・テーブルがあります。伝播によって、ソース・データベースの行LCRが宛先データベースに送信されます。このオプションは、構成およびメンテナンスの容易さが求められ、ソース・テーブルとチェンジ・テーブルが異なるデータベースに存在する必要がある場合に適しています。

- ダウンストリーム取得とローカル適用: 1つのデータベースにソース・テーブルがあり、もう1つのデータベースに取得プロセス、適用プロセスおよびチェンジ・テーブルがあります。このオプションは、ソース・テーブルが存在するデータベースのパフォーマンスを最適化し、変更の取得をもう1つのデータベースで行って負荷を軽減する必要がある場合に適しています。このオプションを使用した場合、チェンジ・テーブルが存在するデータベースでほとんどのコンポーネントが実行されます。

- ダウンストリーム取得とリモート適用: 1つのデータベースにソース・テーブルがあり、もう1つのデータベースに適用プロセスとチェンジ・テーブルがあり、第3のデータベースに取得プロセスがあります。このオプションは、ソース・テーブルが存在するデータベースとチェンジ・テーブルが存在するデータベースの両方のパフォーマンスを最適化する必要がある場合に適しています。このオプションを使用した場合、取得プロセスは第3のデータベースで実行され、伝播によって取得データベースから宛先データベースに行LCRが送信されます。

MAINTAIN_CHANGE_TABLEプロシージャが実行されるデータベースが常に取得データベースになります。表20-1に、各タイプの環境を構成するときのプロシージャの実行場所を示します。

表20-1 MAINTAIN_CHANGE_TABLEの構成オプション

環境のタイプ

MAINTAIN_CHANGE_TABLEの実行場所

1つのデータベースでのローカル取得とローカル適用

ソース・テーブルが存在するソース・データベース

ローカル取得とリモート適用

ソース・テーブルが存在するソース・データベース

ダウンストリーム取得とローカル適用

ソース・テーブルは存在せず、チェンジ・テーブルが存在する宛先データベース

ダウンストリーム取得とリモート適用

ソース・テーブルもチェンジ・テーブルも存在しない第3のデータベース

ダウンストリーム取得を構成するには、追加の要件を満たす必要があります。詳細は、「ダウンストリーム取得の操作要件」を参照してください。

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

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

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

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

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

関連項目:

- 「Oracle Streams取得プロセスによる暗黙的取得」

- 第3章「Oracle Streamsのステージングと伝播」

- 「適用プロセスによる暗黙的コンシューム」

- 「文DMLハンドラ」

追跡する列の決定

MAINTAIN_CHANGE_TABLEプロシージャのcolumn_type_listパラメータでは、チェンジ・テーブル内で追跡する列を指定できます。Oracle Streams環境では、リストに指定した列の変更のみが記録されます。表のすべての列を追跡するには、このパラメータですべての列を指定します。列のサブセットを追跡するには、追跡する列を指定します。column_type_listパラメータでは、列のデータ型と有効な任意の列プロパティ(表内の制約指定など)を指定できます。

様々な理由でリストから列を省略できます。たとえば、一部の列には、チェンジ・テーブルへの移入を避けるべき給与データなどの機密情報が含まれている場合があります。また、表が数百もの列で構成されていても、追跡が必要な列はごくわずかしかない場合があります。

記録するメタデータの決定

MAINTAIN_CHANGE_TABLEプロシージャのextra_column_listパラメータでは、チェンジ・テーブルに記録するメタデータを指定できます。このパラメータでは、次のタイプのメタデータを指定できます。

- value_type

- source_database_name

- command_type

- object_owner

- object_name

- tag

- transaction_id

- scn

- commit_scn

- commit_time

- position

- compatible

- instance_number

- message_number

- row_text

- row_id

- serial#

- session#

- source_time

- thread#

- tx_name

- username

チェンジ・テーブルでは、各メタデータ属性の列名にはドル記号($)が追加されます。たとえば、command_type属性のメタデータは、チェンジ・テーブルのcommand_type$列に格納されます。

value_typeおよびmessage_numberを除き、これらのメタデータ属性はすべて行LCR属性であり、行LCRに格納できます。

チェンジ・テーブルのvalue_type$列には、列値が元の列値であるか、新しい列値であるかに応じて、OLDまたはNEWのいずれかが含まれます。

チェンジ・テーブルのmessage_number$列には、トランザクション内の各行LCRの識別番号が含まれます。メッセージ番号は、トランザクション内の行LCRごとに段階的に増加し、トランザクション内の行LCRの順序を示します。

注意:
LCRのpositionは、一般的にXStream構成で使用されます。

関連項目:

- 「行LCR」

- 「LCRのその他の情報」

- 『Oracle Database XStreamガイド』

更新操作に応じて追跡する値の決定

MAINTAIN_CHANGE_TABLEプロシージャのcapture_valuesパラメータでは、ソース・テーブルに対する更新操作に応じてチェンジ・テーブルに記録する値を指定できます。行に対して更新操作が実行されると、各列の古い値は更新操作前の値になり、新しい値は更新操作後の値になります。古い値または新しい値あるいはその両方を記録するように指定できます。

KEEP_COLUMNS変換を構成するかどうかの決定

MAINTAIN_CHANGE_TABLEプロシージャのkeep_change_columns_onlyパラメータでは、KEEP_COLUMNS宣言ルールベースの変換を構成するかどうかを指定できます。KEEP_COLUMNS宣言ルールベースの変換では、column_type_listパラメータで指定したリストに含まれる列が行LCRに維持されます。リストに含まれない列は行LCRから削除されます。

たとえば、表が10列で構成され、そのうち3列のみをチェンジ・テーブルで追跡する必要があるとします。この場合、通常、追跡しない7列を削除する7つのDELETE_COLUMN宣言ルールベースの変換を構成するよりも、追跡する必要がある3列を維持する1つのKEEP_COLUMNS宣言ルールベースの変換を構成する方が効率的です。

keep_change_columns_onlyパラメータは、column_type_listパラメータで表の列のサブセットを指定する場合にのみ関係します。この場合、ネットワークで送信される情報量を減らしたり、行LCRから機密情報を除外するように変換を構成できます。

column_type_listパラメータで指定していない列に関する情報が宛先データベースで必要な場合は、keep_change_columns_onlyパラメータをFALSEに設定します。たとえば、execute_lcrパラメータをTRUEに設定し、構成でソース・テーブルのすべての列がレプリケートされる状況で、column_type_listパラメータでこれらの列のサブセットを指定した場合は、keep_change_columns_onlyパラメータをFALSEに設定します。

関連項目:

- 「宣言ルールベースの変換」

- 「追跡する列の決定」

- 「ソース・テーブルをレプリケートするかどうかの決定」

チェンジ・テーブルに対してCREATE TABLEオプションを指定するかどうかの決定

MAINTAIN_CHANGE_TABLEプロシージャのoptions_stringパラメータでは、チェンジ・テーブルを作成するCREATE TABLE文にオプションの文字列を追加できます。この文字列は、生成されたCREATE TABLE文において、表の列を定義する右カッコの後に追加されます。文字列は構文的に正確である必要があります。たとえば、特定の表領域に表を格納するTABLESPACE句を指定できます。また、チェンジ・テーブルをパーティション化することもできます。チェンジ・テーブルをパーティション化するメリットは、DELETE文で行を削除するかわりに、ALTER TABLE文のTRUNCATE PARTITION句を使用してパーティションを切り捨てることができることです。

関連項目:
CREATE TABLEオプションの詳細は、『Oracle Database SQL言語リファレンス』を参照

構成アクションを直接実行するか、スクリプトで実行するかの決定

MAINTAIN_CHANGE_TABLEプロシージャでは、Oracle Streams環境を直接構成することも、環境を構成するスクリプトを生成することもできます。プロシージャを使用して直接構成する方がスクリプトを実行するよりも簡単で、環境も即座に構成されます。ただし、次のような理由でスクリプトを生成することもできます。

- 環境を構成する前に、プロシージャによって実行されるアクションを確認する。

- スクリプトを変更して構成をカスタマイズする。

たとえば、適用プロセスによって変更が適用される前に、適用ハンドラを使用してそれらの変更のカスタマイズ処理を行う必要がある場合があります。この場合、プロシージャを使用してスクリプトを生成し、適用ハンドラを追加するようにそのスクリプトを変更できます。

perform_actionsパラメータでは、プロシージャで環境を直接構成するかどうかを制御します。

- MAINTAIN_CHANGE_TABLEプロシージャの実行時に環境を直接構成するには、perform_actionsパラメータをTRUEに設定します。このパラメータのデフォルト値はTRUEです。

- MAINTAIN_CHANGE_TABLEプロシージャの実行時に構成スクリプトを生成するには、perform_actionsパラメータをFALSEに設定し、script_nameおよびscript_directory_objectパラメータを使用して構成スクリプトの名前と場所を指定します。

ソース・テーブルをレプリケートするかどうかの決定

一部の環境では、チェンジ・テーブルに加えて、ソース・テーブルを宛先データベースにレプリケートする必要があります。この場合、ソース・テーブルとチェンジ・テーブルは異なるデータベースにあり、ソース・テーブルの追加のレプリカがチェンジ・テーブルと同じデータベースに含まれます。

たとえば、hr.employees表に対する変更を記録するOracle Streams環境を考えます。チェンジ・テーブルの名前はhr.emp_change_tableであり、ソース・テーブルとチェンジ・テーブルは異なるデータベースにあるとします。この場合、hr.employees表に対する変更を記録するOracle Streams環境には、次の表が関係します。

- データベース1のhr.employees表

- データベース2のhr.emp_change_table

宛先データベースの適用プロセスでは、操作のタイプ(挿入、更新および削除)ごとに別々の変更ハンドラを使用して変更が記録されます。

Oracle Streams環境でデータベース2にhr.employees表もレプリケートされる場合は、次の表が関係します。

- データベース1のhr.employees表

- データベース2のhr.employees表(レプリカ)

- データベース2のhr.emp_change_table

表の変更を記録するのみでなく、表をレプリケートする環境では、操作のタイプ(挿入、更新および削除)ごとに別々の変更ハンドラが宛先データベースの適用プロセスに追加されます。これらの変更ハンドラでは、行LCRを実行して、レプリケートされた表に変更を適用します。

execute_lcrパラメータでは、プロシージャでソース・テーブルのレプリケーションを構成するかどうかを制御します。

- ソース・テーブルをレプリケートするOracle Streams環境を構成するには、execute_lcrパラメータをTRUEに設定します。

- ソース・テーブルをレプリケートしないOracle Streams環境を構成するには、execute_lcrパラメータをFALSEに設定します。このパラメータのデフォルト値はFALSEです。

注意:
keep_change_columns_onlyパラメータをTRUEに設定し、column_listパラメータでソース・テーブルの列のサブセットを指定した場合は、execute_lcrパラメータをFALSEに設定する必要があります。変更をレプリケートするために必要な列値が行LCRに含まれていない場合は、適用エラーが発生します。

関連項目:
「KEEP_COLUMNS変換を構成するかどうかの決定」

MAINTAIN_CHANGE_TABLEプロシージャに関する前提条件

DBMS_STREAMS_ADMパッケージには、MAINTAIN_GLOBAL、MAINTAIN_SCHEMAS、MAINTAIN_TABLESなど、レプリケーション環境を構成するプロシージャが用意されています。MAINTAIN_CHANGE_TABLEプロシージャの使用方法はこれらの他のプロシージャの使用方法と類似しており、前提条件の多くも同じです。

次の各項では、MAINTAIN_CHANGE_TABLEプロシージャを実行する前に満たす必要がある前提条件について説明します。

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

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

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

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

- Oracle Streamsプールの構成

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

- リアルタイム・ダウンストリーム取得に対するスタンバイREDOログの構成

- スクリプトを使用する場合に必要なディレクトリ・オブジェクトの構成

- 宛先データベースでのソース・テーブルのインスタンス化

これらの前提条件の多くは、『Oracle Streamsレプリケーション管理者ガイド』で詳しく説明されています。

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

環境内の各データベースでは、Oracle Streams管理者にOracle Streamsコンポーネントを構成および管理させる必要があります。手順については、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

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

構成する予定のOracle Streams環境のタイプに応じて、ネットワーク接続性と1つ以上のデータベース・リンクが必要になる場合があります。環境に複数のデータベースが存在する場合は、環境内のデータベース間のネットワーク接続性が必要です。

各タイプのOracle Streams環境では、次のデータベース・リンクが必要です。

- 1つのデータベースでのローカル取得とローカル適用: データベース・リンクは不要です。

- ローカル取得とリモート適用: ソース・データベースから宛先データベースへのデータベース・リンクが必要です。

- ダウンストリーム取得とローカル適用: 次のデータベース・リンクが必要です。

- ソース・データベースから接続先データベースへのデータベース・リンク。

- 宛先データベースからソース・データベースへのデータベース・リンク

- ダウンストリーム取得とリモート適用: 次のデータベース・リンクが必要です。

- ソース・データベースから接続先データベースへのデータベース・リンク。

- ソース・データベースから取得データベースへのデータベース・リンク

- 取得データベースからソース・データベースへのデータベース・リンク

- 取得データベースから宛先データベースへのデータベース・リンク

手順については、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

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

Oracle Streamsの取得プロセスではREDOログをスキャンして変更を取得するため、ソース・テーブルが存在するソース・データベースをARCHIVELOGモードにする必要があります。ダウンストリーム取得プロセスを構成する予定の場合は、取得データベースもARCHIVELOGモードにする必要があります。手順については、『Oracle Database管理者ガイド』を参照してください。

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

一部の初期化パラメータは、Oracle Streams環境の構成、操作、信頼性およびパフォーマンスにとって重要です。これらのパラメータをOracle Streams環境にあわせて適切に設定します。手順については、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

Oracle Streamsプールの構成

Oracle Streamsプールは、Oracle Streamsで使用されるシステム・グローバル領域(SGA)にあるメモリーです。データベース・メモリーを構成して、Oracle Streamsプールに十分な空き領域を確保します。手順については、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

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

ソース・データベースでローカル取得プロセスを使用するように決定した場合は、ログ・ファイルの転送は不要です。ただし、REDO転送サービスによってアーカイブREDOログ・ファイルをダウンストリーム・データベースに自動的に転送するダウンストリーム取得を使用するように決定した場合は、Oracle Streams環境を構成する前に、ソース・データベースから取得データベースへのログ・ファイルの転送を構成します。手順については、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

関連項目:
「構成する環境のタイプの決定」

リアルタイム・ダウンストリーム取得に対するスタンバイREDOログの構成

リアルタイム・ダウンストリーム取得プロセスを使用するように決定した場合は、取得データベースでスタンバイREDOログを構成する必要があります。手順については、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

関連項目:
「構成する環境のタイプの決定」

スクリプトを使用する場合に必要なディレクトリ・オブジェクトの構成

MAINTAIN_CHANGE_TABLEプロシージャでスクリプトを生成し、そのスクリプトを使用してOracle Streams環境を構成するように決定した場合は、取得データベースにスクリプトを格納するディレクトリ・オブジェクトを作成します。取得データベースは、プロシージャを実行するデータベースです。スクリプトを生成しない場合、このディレクトリ・オブジェクトは不要です。

ディレクトリ・オブジェクトは、ファイル・システム上のディレクトリの別名と類似しています。各ディレクトリ・オブジェクトはSQL文CREATE DIRECTORYを使用して作成する必要があり、MAINTAIN_CHANGE_TABLEプロシージャを起動するユーザーにはそのディレクトリ・オブジェクトに対するREADおよびWRITE権限が必要です。

たとえば、次の文では、/usr/db_filesディレクトリに対応するdb_files_directoryという名前のディレクトリ・オブジェクトを作成します。

CREATE DIRECTORY db_files_directory AS '/usr/db_files';

ディレクトリ・オブジェクトを作成するユーザーには、そのディレクトリ・オブジェクトに対するREADおよびWRITE権限が自動的に割り当てられます。Oracle Streamsレプリケーション環境を構成する場合は、通常、Oracle Streams管理者がディレクトリ・オブジェクトを作成します。

関連項目:

- 「構成アクションを直接実行するか、スクリプトで実行するかの決定」

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

宛先データベースでのソース・テーブルのインスタンス化

ソース・テーブルをレプリケートするように決定した場合は、宛先データベースでソース・テーブルをインスタンス化します。ソース・テーブルをレプリケートしないように決定した場合、インスタンス化は不要です。

ソース・テーブルをレプリケートするように決定したためにインスタンス化が必要な場合は、MAINTAIN_CHANGE_TABLEプロシージャを実行する前に、次の手順を実行します。

1. ソース・テーブルをインスタンス化のために準備します。

2. ソース・テーブルとレプリカ・テーブルに一貫性があることを確認します。

3. 宛先データベースでレプリカ・テーブルのインスタンス化SCNを設定します。

関連項目:

- インスタンス化手順については、『Oracle Streamsレプリケーション管理者ガイド』を参照

- 「ソース・テーブルをレプリケートするかどうかの決定」

表の変更を記録するOracle Streams環境の構成

この項では、表の変更を記録するOracle Streams環境を構成する方法について例を挙げて説明します。具体的には、表の変更を記録する4つのタイプのOracle Streams環境について説明します。

この項では、次の例を示します。

- 1つのデータベースでのローカル取得とローカル適用を使用した表の変更の記録

- ローカル取得とリモート適用を使用した表の変更の記録およびレプリケーション

- ダウンストリーム取得とローカル適用を使用した表の変更の記録

- ダウンストリーム取得とリモート適用を使用した表の変更の記録

1つのデータベースでのローカル取得とローカル適用を使用した表の変更の記録

この例では、1つのデータベースでのローカル取得とローカル適用を使用して表に対する変更を記録する方法について説明します。具体的には、この例では、hr.jobs表に対する変更を記録します。

次の表に、この例で構成されるOracle Streams環境に関する事前の決定を示します。

決定

この例での前提

構成する環境のタイプの決定

この例では、1つのデータベースでのローカル取得とローカル適用を構成します。

追跡する列の決定

この例では、hr.jobs表のすべての列を追跡します。

記録するメタデータの決定

この例では、command_type、value_type (OLDまたはNEW)およびcommit_scnメタデータを記録します。

更新操作に応じて追跡する値の決定

この例では、ソース・テーブルに対して更新操作が実行されたときに、古い列値と新しい列値の両方を追跡します。

KEEP_COLUMNS変換を構成するかどうかの決定

この例では、KEEP_COLUMNS宣言ルールベースの変換を構成しません。

チェンジ・テーブルに対してCREATE TABLEオプションを指定するかどうかの決定

この例では、どのCREATE TABLEオプションも指定しません。チェンジ・テーブルは、デフォルトのCREATE TABLEオプションを使用して作成されます。

構成アクションを直接実行するか、スクリプトで実行するかの決定

この例では、構成アクションを直接実行します。スクリプトは使用しません。

ソース・テーブルをレプリケートするかどうかの決定

この例では、ソース・テーブルをレプリケートしません。

図20-1に、この例で作成されるOracle Stream環境の概要を示します。

図20-1 1つのデータベースでのローカル取得とローカル適用を使用した変更の記録

1つのデータベースでのローカル取得とローカル適用を使用して表に対する変更を記録するOracle Streams環境を構成するには、次の手順を実行します。

1. MAINTAIN_CHANGE_TABLEプロシージャを実行するために必要な前提条件を満たします。手順については、「MAINTAIN_CHANGE_TABLEプロシージャに関する前提条件」を参照してください。
この構成では、次のタスクを完了する必要があります。

- データベースでOracle Streams管理者を構成します。「すべてのデータベースでのOracle Streams管理者の構成」を参照してください。

- データベースがARCHIVELOGモードであることを確認します。「ソース・データベースがARCHIVELOGモードであることの確認」を参照してください。

- データベースで初期化パラメータが適切に設定されていることを確認します。「Oracle Streamsに関連する初期化パラメータの設定」を参照してください。

- データベースでOracle Streamsプールを適切に構成します。「Oracle Streamsプールの構成」を参照してください。

2. データベースにOracle Streams管理者として接続します。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

3. MAINTAIN_CHANGE_TABLEプロシージャを実行します。

BEGIN
DBMS_STREAMS_ADM.MAINTAIN_CHANGE_TABLE(
change_table_name       => 'hr.jobs_change_table',
source_table_name       => 'hr.jobs',
column_type_list        => 'job_id VARCHAR2(10),
job_title VARCHAR2(35),
min_salary NUMBER(6),
max_salary NUMBER(6)',
extra_column_list        => 'command_type,value_type,commit_scn',
capture_values           => '*',
keep_change_columns_only => FALSE);
END;
/

このプロシージャでは、指定のない各パラメータにはデフォルト値が使用されます。hr.jobs表のすべての列がcolumn_type_listパラメータで指定されているため、keep_change_columns_onlyパラメータはFALSEに設定されています。

このプロシージャが完了したら、Oracle Streams環境が構成されます。

このプロシージャがエラーによって停止した場合は、エラーからのリカバリ方法またはDBMS_STREAMS_ADM.RECOVER_OPERATIONプロシージャを使用して構成操作をロールバックする方法について、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

構成されたOracle Streams環境は次の特性を持ちます。

- 無条件のサプリメンタル・ログ・グループには、hr.jobs表のすべての列が含まれます。

- データベースにはhr.jobs_change_tableが存在します。このチェンジ・テーブルの定義は次のとおりです。

Name                                      Null?    Type
----------------------------------------- -------- ---------------------------
COMMAND_TYPE$                                      VARCHAR2(10)
VALUE_TYPE$                                        VARCHAR2(3)
COMMIT_SCN$                                        NUMBER
JOB_ID                                             VARCHAR2(10)
JOB_TITLE                                          VARCHAR2(35)
MIN_SALARY                                         NUMBER(6)
MAX_SALARY                                         NUMBER(6)

- データベースには、システム生成名を持つキューがあります。このキューは、取得プロセスおよび適用プロセスで使用されます。

- システム生成名を持つ取得プロセスでは、hr.jobs表に対するデータ操作言語(DML)の変更を取得します。

- システム生成名を持つ適用プロセスが使用されます。この適用プロセスでは、システム生成名を持つ変更ハンドラを使用して、hr.jobs表に対する挿入、更新および削除に関して取得された行LCRを処理します。変更ハンドラでは、行LCR内の情報を使用して、hr.jobs_change_tableへの移入を行います。

関連項目:
hr.jobs表を変更し、hr.jobs_change_tableを問い合せて変更の追跡を確認する例については、「チェンジ・テーブルの監視」を参照

ローカル取得とリモート適用を使用した表の変更の記録およびレプリケーション

この例では、ローカル取得とリモート適用を使用して表に対する変更を記録する方法について説明します。この例で構成されるOracle Stream環境では、表に対する変更を記録するのみでなく、変更をレプリケートします。

具体的には、この例では、hr.departments表の列のサブセットに対する変更を記録します。また、hr.departments表のすべての列に対するデータ操作言語(DML)の変更をレプリケートします。この例で構成されるOracle Streams環境では、ソース・データベースct1.example.comに対する変更を取得し、その変更を宛先データベースct2.example.comに送信します。ct2.example.comの適用プロセスでは、チェンジ・テーブルに変更を記録し、その変更をレプリカのhr.departments表に適用します。

次の表に、この例で構成されるOracle Streams環境に関する事前の決定を示します。

決定

この例での前提

構成する環境のタイプの決定

この例では、2つのデータベースを使用するローカル取得とリモート適用を構成します。ソース・データベースはct1.example.comであり、宛先データベースはct2.example.comです。取得プロセスは、ct1.example.comのローカル取得プロセスになります。

追跡する列の決定

この例では、hr.departments表のdepartment_idおよびmanager_id列を追跡します。

記録するメタデータの決定

この例では、command_typeおよびvalue_type (OLDまたはNEW)メタデータを記録します。extra_column_listパラメータがMAINTAIN_CHANGE_TABLEで指定されていない場合、このメタデータはデフォルトで記録されます。

更新操作に応じて追跡する値の決定

この例では、ソース・テーブルに対して更新操作が実行されたときに、古い列値と新しい列値の両方を追跡します。

KEEP_COLUMNS変換を構成するかどうかの決定

この例では、表のすべての列がレプリケートされるため、KEEP_COLUMNS宣言ルールベースの変換を構成しません。

チェンジ・テーブルに対してCREATE TABLEオプションを指定するかどうかの決定

この例では、どのCREATE TABLEオプションも指定しません。チェンジ・テーブルは、デフォルトのCREATE TABLEオプションを使用して作成されます。

構成アクションを直接実行するか、スクリプトで実行するかの決定

この例では、構成アクションを直接実行します。スクリプトは使用しません。

ソース・テーブルをレプリケートするかどうかの決定

この例では、宛先データベースにソース・テーブルをレプリケートします。したがって、ソース・データベースと宛先データベースの両方にhr.departments表が存在します。MAINTAIN_CHANGE_TABLEプロシージャでは、ソース・データベースから宛先データベースへのこの表の単方向レプリケーション環境を構成します。

図20-2に、この例で作成されるOracle Stream環境の概要を示します。

図20-2 ローカル取得とリモート適用を使用した変更の記録およびレプリケーション

ローカル取得とリモート適用を使用して表に対する変更を記録およびレプリケートするOracle Streams環境を構成するには、次の手順を実行します。

1. MAINTAIN_CHANGE_TABLEプロシージャを実行するために必要な前提条件を満たします。手順については、「MAINTAIN_CHANGE_TABLEプロシージャに関する前提条件」を参照してください。
この構成では、次のタスクを完了する必要があります。

- 両方のデータベースでOracle Streams管理者を構成します。「すべてのデータベースでのOracle Streams管理者の構成」を参照してください。

- ネットワーク接続性とデータベース・リンクを構成します。

- ソース・データベースct1.example.comと宛先データベースct2.example.comの間のネットワーク接続性を構成します。

- ソース・データベースct1.example.comから宛先データベースct2.example.comへのデータベース・リンクを作成します。

手順については、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

- ソース・データベースがARCHIVELOGモードであることを確認します。この例では、ソース・データベースはct1.example.comです。「ソース・データベースがARCHIVELOGモードであることの確認」を参照してください。

- すべてのデータベースで初期化パラメータが適切に設定されていることを確認します。「Oracle Streamsに関連する初期化パラメータの設定」を参照してください。

- すべてのデータベースでOracle Streamsプールを適切に構成します。「Oracle Streamsプールの構成」を参照してください。

- この例ではソース・テーブルhr.departmentsをレプリケートするため、宛先データベースでソース・テーブルをインスタンス化します。「宛先データベースでのソース・テーブルのインスタンス化」を参照してください。

2. ソース・データベースct1.example.comにOracle Streams管理者として接続します。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

3. MAINTAIN_CHANGE_TABLEプロシージャを実行します。

BEGIN
DBMS_STREAMS_ADM.MAINTAIN_CHANGE_TABLE(
change_table_name       => 'hr.dep_change_table',
source_table_name       => 'hr.departments',
column_type_list        => 'department_id NUMBER(4),
manager_id NUMBER(6)',
capture_values           => '*',
source_database          => 'ct1.example.com',
destination_database     => 'ct2.example.com',
keep_change_columns_only => FALSE,
execute_lcr              => TRUE);
END;
/

このプロシージャでは、指定のない各パラメータにはデフォルト値が使用されます。execute_lcrパラメータがTRUEに設定されているため、keep_change_columns_onlyパラメータはFALSEに設定されています。すべての列が宛先データベースにレプリケートされるため、行論理変更レコード(LCR)には表のすべての列の変更に関する情報が含まれている必要があります。execute_lcrパラメータがTRUEに設定されていて、column_type_listパラメータでレプリケート対象のすべての列が指定されている場合(この例は該当しません)、keep_change_columns_onlyパラメータはTRUEにしか設定できません。

このプロシージャが完了したら、Oracle Streams環境が構成されます。

このプロシージャがエラーによって停止した場合は、エラーからのリカバリ方法またはDBMS_STREAMS_ADM.RECOVER_OPERATIONプロシージャを使用して構成操作をロールバックする方法について、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

構成されたOracle Streams環境は次の特性を持ちます。

- 無条件のサプリメンタル・ログ・グループには、ソース・データベースct1.example.comで変更が記録されるhr.departments表の列が含まれます。これらの列は、MAINTAIN_CHANGE_TABLEプロシージャのcolumn_type_listパラメータで指定されたものです。

- 宛先データベースct2.example.comにはhr.dep_change_tableが存在します。このチェンジ・テーブルの定義は次のとおりです。

Name                                      Null?    Type
----------------------------------------- -------- ---------------------------
COMMAND_TYPE$                                      VARCHAR2(10)
VALUE_TYPE$                                        VARCHAR2(3)
DEPARTMENT_ID                                      NUMBER(4)
MANAGER_ID                                         NUMBER(6)

- ソース・データベースct1.example.comには、システム生成名を持つキューがあります。このキューは、取得プロセスで使用されます。

- 宛先データベースct2.example.comには、システム生成名を持つキューがあります。このキューは、適用プロセスで使用されます。

- ソース・データベースct1.example.comでは、システム生成名を持つローカル取得プロセスを使用して、hr.departments表に対するデータ操作言語(DML)の変更を取得します。

- 宛先データベースct2.example.comでは、システム生成名を持つ適用プロセスが使用されます。この適用プロセスでは、システム生成名を持つ変更ハンドラを使用して、hr.departments表に対する挿入、更新および削除に関して取得された行LCRを処理します。変更ハンドラでは、行LCR内の情報を使用して、hr.dep_change_tableへの移入を行います。
また、適用プロセスでは、操作のタイプ(挿入、更新および削除)ごとに、システム生成名を持つ変更ハンドラを使用して行LCRを実行します。これにより、ソース・テーブルに対する変更が宛先データベースにあるレプリカのhr.departments表に適用されます。

- ct1.example.comデータベースでは、システム生成名を持つ伝播が実行されます。この伝播によって、ct1.example.comデータベースから取得された変更がct2.example.comデータベースに送信されます。

ダウンストリーム取得とローカル適用を使用した表の変更の記録

この例では、ダウンストリーム取得とローカル適用を使用して表に対する変更を記録する方法について説明します。具体的には、この例では、ソース・データベースと宛先データベースを使用して、hr.locations表に対する変更を記録します。宛先データベースは、ダウンストリーム取得プロセス用の取得データベースにもなります。

次の表に、この例で構成されるOracle Streams環境に関する事前の決定を示します。

決定

この例での前提

構成する環境のタイプの決定

この例では、ソース・データベースct1.example.comと宛先データベースct2.example.comを使用するダウンストリーム取得とローカル適用を構成します。取得プロセスは、ct2.example.comで実行されるリアルタイム・ダウンストリーム取得プロセスになります。

追跡する列の決定

この例では、hr.locations表のすべての列を追跡します。

記録するメタデータの決定

この例では、command_type、value_type (OLDまたはNEW)、object_owner、object_nameおよびusernameメタデータを記録します。

更新操作に応じて追跡する値の決定

この例では、ソース・テーブルに対して更新操作が実行されたときに、古い列値と新しい列値の両方を追跡します。

KEEP_COLUMNS変換を構成するかどうかの決定

この例では、KEEP_COLUMNS宣言ルールベースの変換を構成しません。

チェンジ・テーブルに対してCREATE TABLEオプションを指定するかどうかの決定

この例では、どのCREATE TABLEオプションも指定しません。チェンジ・テーブルは、デフォルトのCREATE TABLEオプションを使用して作成されます。

構成アクションを直接実行するか、スクリプトで実行するかの決定

この例では、構成アクションを直接実行します。スクリプトは使用しません。

ソース・テーブルをレプリケートするかどうかの決定

この例では、ソース・テーブルをレプリケートしません。

図20-3に、この例で作成されるOracle Stream環境の概要を示します。

図20-3 ダウンストリーム取得とローカル適用を使用した変更の記録

ダウンストリーム取得とリモート適用を使用して表に対する変更を記録するOracle Streams環境を構成するには、次の手順を実行します。

1. MAINTAIN_CHANGE_TABLEプロシージャを実行するために必要な前提条件を満たします。手順については、「MAINTAIN_CHANGE_TABLEプロシージャに関する前提条件」を参照してください。
この構成では、次のタスクを完了する必要があります。

- 両方のデータベースでOracle Streams管理者を構成します。「すべてのデータベースでのOracle Streams管理者の構成」を参照してください。

- ネットワーク接続性とデータベース・リンクを構成します。

- ソース・データベースct1.example.comと宛先データベースct2.example.comの間のネットワーク接続性を構成します。

- ダウンストリーム取得は宛先データベースで構成されるため、ソース・データベースct1.example.comから宛先データベースct2.example.comへのデータベース・リンクを作成します。このデータベース・リンクは、ct1.example.comからct2.example.comにREDOログ・データを送信するために使用されます。

- ダウンストリーム取得は宛先データベースで構成されるため、宛先データベースct2.example.comからソース・データベースct1.example.comへのデータベース・リンクを作成します。このデータベース・リンクは、ソース・データベースでダウンストリーム取得に関連する管理タスクを実行するために使用されます。

手順については、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

- ソース・データベースと宛先データベースがARCHIVELOGモードであることを確認します。この例では、ソース・データベースはct1.example.comであり、宛先データベースはct2.example.comです。「ソース・データベースがARCHIVELOGモードであることの確認」を参照してください。

- 両方のデータベースで初期化パラメータが適切に設定されていることを確認します。「Oracle Streamsに関連する初期化パラメータの設定」を参照してください。

- 両方のデータベースでOracle Streamsプールを適切に構成します。「Oracle Streamsプールの構成」を参照してください。

- 宛先データベースがソース・データベースに対する変更の取得データベースになるため、ソース・データベースct1.example.comから取得データベースct2.example.comにコピーするログ・ファイルを構成します。「ダウンストリーム取得データベースへのログ・ファイルの転送の構成」を参照してください。

- この例ではリアルタイム・ダウンストリーム取得プロセスを構成するため、取得データベースにスタンバイREDOログを追加し、取得データベースct2.example.comでスタンバイREDOログを構成します。「リアルタイム・ダウンストリーム取得に対するスタンバイREDOログの構成」を参照してください。

2. 宛先データベースct2.example.comにOracle Streams管理者として接続します。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

3. MAINTAIN_CHANGE_TABLEプロシージャを実行します。

BEGIN
DBMS_STREAMS_ADM.MAINTAIN_CHANGE_TABLE(
change_table_name       => 'hr.loc_change_table',
source_table_name       => 'hr.locations',
column_type_list        => 'location_id NUMBER(4),
street_address VARCHAR2(40),
postal_code VARCHAR2(12),
city VARCHAR2(30),
state_province VARCHAR2(25),
country_id CHAR(2)',
extra_column_list       => 'command_type,value_type,object_owner,
object_name,username',
capture_values          => '*',
source_database          => 'ct1.example.com',
destination_database     => 'ct2.example.com',
keep_change_columns_only => FALSE);
END;
/

このプロシージャでは、指定のない各パラメータにはデフォルト値が使用されます。hr.locations表のすべての列がcolumn_type_listパラメータで指定されているため、keep_change_columns_onlyパラメータはFALSEに設定されています。

このプロシージャが完了したら、Oracle Streams環境が構成されます。

このプロシージャがエラーによって停止した場合は、エラーからのリカバリ方法またはDBMS_STREAMS_ADM.RECOVER_OPERATIONプロシージャを使用して構成操作をロールバックする方法について、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

4. downstream_real_time_mine取得プロセス・パラメータをYに設定します。

1. DBA_CAPTUREビューのCAPTURE_NAME列を問い合せて、取得プロセスの名前を調べます。

2. DBMS_CAPTURE_ADMパッケージのSET_PARAMETERプロシージャを実行して、downstream_real_time_mine取得プロセス・パラメータをYに設定します。
たとえば、取得プロセス名がcap$chg5である場合、次のプロシージャを実行します。

BEGIN
DBMS_CAPTURE_ADM.SET_PARAMETER(
capture_name => 'cap$chg5',
parameter    => 'downstream_real_time_mine',
value        => 'Y');
END;
/

5. ログ・ファイルを切り替えるために必要な権限を持つ管理ユーザーとして、ソース・データベースct1.example.comに接続します。

6. 現行のログ・ファイルがソース・データベースにアーカイブされます。

ALTER SYSTEM ARCHIVE LOG CURRENT;

現行のログ・ファイルがソース・データベースにアーカイブされると、ソース・データベースのREDOログのリアルタイム・マイニングが開始されます。

構成されたOracle Streams環境は次の特性を持ちます。

- ソース・データベースct1.example.comの無条件のサプリメンタル・ログ・グループには、hr.locations表のすべての列が含まれます。

- extra_column_listパラメータでusernameが指定されているため、変更を行ったユーザーのユーザー名に関する追加情報がREDOログに記録されるように、ソース・データベースが構成されます。この情報は、取得プロセスで取得され、チェンジ・テーブルに記録されます。extra_column_listパラメータで指定された他の値(command_type、value_type、object_ownerおよびobject_name)は常にREDOログで追跡されます。したがって、この情報を取得するのに追加の構成は不要です。

- 宛先データベースct2.example.comにはhr.loc_change_tableが存在します。このチェンジ・テーブルの定義は次のとおりです。

Name                                      Null?    Type
----------------------------------------- -------- ---------------------------
COMMAND_TYPE$                                      VARCHAR2(10)
VALUE_TYPE$                                        VARCHAR2(3)
OBJECT_OWNER$                                      VARCHAR2(30)
OBJECT_NAME$                                       VARCHAR2(30)
USERNAME$                                          VARCHAR2(30)
LOCATION_ID                                        NUMBER(4)
STREET_ADDRESS                                     VARCHAR2(40)
POSTAL_CODE                                        VARCHAR2(12)
CITY                                               VARCHAR2(30)
STATE_PROVINCE                                     VARCHAR2(25)
COUNTRY_ID                                         CHAR(2)

- 宛先データベースct2.example.comには、システム生成名を持つキューがあります。このキューは、ダウンストリーム取得プロセスおよび適用プロセスで使用されます。

- 宛先データベースct2.example.comでは、システム生成名を持つリアルタイム・ダウンストリーム取得プロセスを使用して、hr.locations表に対するデータ操作言語(DML)の変更を取得します。

- 宛先データベースct2.example.comでは、システム生成名を持つ適用プロセスが使用されます。この適用プロセスでは、システム生成名を持つ変更ハンドラを使用して、hr.locations表に対する挿入、更新および削除に関して取得された行LCRを処理します。変更ハンドラでは、行LCR内の情報を使用して、hr.loc_change_tableへの移入を行います。

関連項目:
「取得プロセス・パラメータの設定」

ダウンストリーム取得とリモート適用を使用した表の変更の記録

この例では、ダウンストリーム取得とリモート適用を使用して表に対する変更を記録する方法について説明します。具体的には、この例では、ソース・データベース、宛先データベースおよび取得データベースの3つのデータベースを使用して、hr.employees表に対する変更を記録します。

次の表に、この例で構成されるOracle Streams環境に関する事前の決定を示します。

決定

この例での前提

構成する環境のタイプの決定

この例では、3つのデータベースを使用するダウンストリーム取得とリモート適用を構成します。ソース・データベースはct1.example.comであり、宛先データベースはct2.example.comであり、取得データベースはct3.example.comです。取得プロセスは、リアルタイム・ダウンストリーム取得プロセスになります。

追跡する列の決定

この例では、hr.employees表のsalaryおよびcommission_pct以外の列を追跡します。

記録するメタデータの決定

この例では、command_type、value_type (OLDまたはNEW)、object_owner、object_nameおよびusernameメタデータを記録します。

更新操作に応じて追跡する値の決定

この例では、ソース・テーブルに対して更新操作が実行されたときに、古い列値と新しい列値の両方を追跡します。

KEEP_COLUMNS変換を構成するかどうかの決定

この例では、従業員の給与と歩合に関する情報を行LCRに含めないように、KEEP_COLUMNS宣言ルールベースの変換を構成します。

チェンジ・テーブルに対してCREATE TABLEオプションを指定するかどうかの決定

この例では、CREATE TABLEオプションでSTORAGE句を指定します。

構成アクションを直接実行するか、スクリプトで実行するかの決定

この例では、構成アクションを直接実行します。スクリプトは使用しません。

ソース・テーブルをレプリケートするかどうかの決定

この例では、ソース・テーブルをレプリケートしません。

図20-4に、この例で作成されるOracle Stream環境の概要を示します。

図20-4 ダウンストリーム取得とリモート適用を使用した変更の記録

ダウンストリーム取得とリモート適用を使用して表に対する変更を記録するOracle Streams環境を構成するには、次の手順を実行します。

1. MAINTAIN_CHANGE_TABLEプロシージャを実行するために必要な前提条件を満たします。手順については、「MAINTAIN_CHANGE_TABLEプロシージャに関する前提条件」を参照してください。
この構成では、次のタスクを完了する必要があります。

- 3つすべてのデータベースでOracle Streams管理者を構成します。「すべてのデータベースでのOracle Streams管理者の構成」を参照してください。

- ネットワーク接続性とデータベース・リンクを構成します。

- ソース・データベースct1.example.comと宛先データベースct2.example.comの間のネットワーク接続性を構成します。

- ソース・データベースct1.example.comと第3のデータベースct3.example.comの間のネットワーク接続性を構成します。

- 宛先データベースct2.example.comと第3のデータベースct3.example.comの間のネットワーク接続性を構成します。

- ソース・データベースct1.example.comから宛先データベースct2.example.comへのデータベース・リンクを作成します。

- ダウンストリーム取得は第3のデータベースで構成されるため、ソース・データベースct1.example.comから第3のデータベースct3.example.comへのデータベース・リンクを作成します。

- ダウンストリーム取得は第3のデータベースで構成されるため、第3のデータベースct3.example.comからソース・データベースct1.example.comへのデータベース・リンクを作成します。

- ダウンストリーム取得は第3のデータベースで構成されるため、第3のデータベースct3.example.comから宛先データベースct2.example.comへのデータベース・リンクを作成します。

手順については、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

- ソース・データベースと取得データベースがARCHIVELOGモードであることを確認します。この例では、ソース・データベースはct1.example.comであり、取得データベースはct3.example.comです。「ソース・データベースがARCHIVELOGモードであることの確認」を参照してください。

- すべてのデータベースで初期化パラメータが適切に設定されていることを確認します。「Oracle Streamsに関連する初期化パラメータの設定」を参照してください。

- すべてのデータベースでOracle Streamsプールを適切に構成します。「Oracle Streamsプールの構成」を参照してください。

- 第3のデータベース(ct3.example.com)がソース・データベースに対する変更の取得データベースになるため、ソース・データベースct1.example.comから取得データベースct3.example.comにコピーするログ・ファイルを構成します。「ダウンストリーム取得データベースへのログ・ファイルの転送の構成」を参照してください。

- この例ではリアルタイム・ダウンストリーム取得プロセスを構成するため、取得データベースにスタンバイREDOログを追加し、取得データベースct3.example.comでスタンバイREDOログを構成します。「リアルタイム・ダウンストリーム取得に対するスタンバイREDOログの構成」を参照してください。

2. 取得データベースct3.example.comにOracle Streams管理者として接続します。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

3. MAINTAIN_CHANGE_TABLEプロシージャを実行します。

BEGIN
DBMS_STREAMS_ADM.MAINTAIN_CHANGE_TABLE(
change_table_name       => 'hr.emp_change_table',
source_table_name       => 'hr.employees',
column_type_list        => 'employee_id VARCHAR2(6),
first_name VARCHAR2(20),
last_name VARCHAR2(25),
email VARCHAR2(25),
phone_number VARCHAR2(20),
hire_date DATE,
job_id VARCHAR2(10),
manager_id NUMBER(6),
department_id NUMBER(4)',
capture_values          => '*',
options_string          => 'STORAGE (INITIAL     6144
NEXT        6144
MINEXTENTS     1
MAXEXTENTS     5)',
source_database          => 'ct1.example.com',
destination_database     => 'ct2.example.com',
keep_change_columns_only => TRUE);
END;
/

このプロシージャでは、指定のない各パラメータにはデフォルト値が使用されます。options_stringパラメータでは、チェンジ・テーブルに対するSTORAGE句を指定しています。keep_change_columns_onlyパラメータはTRUEに設定されているため、取得された行論理変更レコード(LCR)にsalaryおよびcommission_pct列以外の列を保持する宣言ルールベースの変換が作成されます。salaryおよびcommission_pct列はcolumn_type_listパラメータで指定されていないため、これらの列は除外されます。

このプロシージャが完了したら、Oracle Streams環境が構成されます。

このプロシージャがエラーによって停止した場合は、エラーからのリカバリ方法またはDBMS_STREAMS_ADM.RECOVER_OPERATIONプロシージャを使用して構成操作をロールバックする方法について、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

4. downstream_real_time_mine取得プロセス・パラメータをYに設定します。

1. DBA_CAPTUREビューのCAPTURE_NAME列を問い合せて、取得プロセスの名前を調べます。

2. DBMS_CAPTURE_ADMパッケージのSET_PARAMETERプロシージャを実行して、downstream_real_time_mine取得プロセス・パラメータをYに設定します。
たとえば、取得プロセス名がcap$chg5である場合、次のプロシージャを実行します。

BEGIN
DBMS_CAPTURE_ADM.SET_PARAMETER(
capture_name => 'cap$chg5',
parameter    => 'downstream_real_time_mine',
value        => 'Y');
END;
/

5. ログ・ファイルを切り替えるために必要な権限を持つ管理ユーザーとして、ソース・データベースct1.example.comに接続します。

6. 現行のログ・ファイルがソース・データベースにアーカイブされます。

ALTER SYSTEM ARCHIVE LOG CURRENT;

現行のログ・ファイルがソース・データベースにアーカイブされると、ソース・データベースのREDOログのリアルタイム・マイニングが開始されます。

構成されたOracle Streams環境は次の特性を持ちます。

- 無条件のサプリメンタル・ログ・グループには、ソース・データベースct1.example.comで変更が記録されるhr.employees表の列が含まれます。これらの列は、MAINTAIN_CHANGE_TABLEプロシージャのcolumn_type_listパラメータで指定されたものです。

- 宛先データベースct2.example.comにはhr.emp_change_tableが存在します。このチェンジ・テーブルの定義は次のとおりです。

Name                                      Null?    Type
----------------------------------------- -------- ---------------------------
COMMAND_TYPE$                                      VARCHAR2(10)
VALUE_TYPE$                                        VARCHAR2(3)
EMPLOYEE_ID                               NOT NULL NUMBER(6)
FIRST_NAME                                         VARCHAR2(20)
LAST_NAME                                 NOT NULL VARCHAR2(25)
EMAIL                                     NOT NULL VARCHAR2(25)
PHONE_NUMBER                                       VARCHAR2(20)
HIRE_DATE                                 NOT NULL DATE
JOB_ID                                    NOT NULL VARCHAR2(10)
MANAGER_ID                                         NUMBER(6)
DEPARTMENT_ID                                      NUMBER(4)

- 取得データベースct3.example.comには、システム生成名を持つキューがあります。このキューは、ダウンストリーム取得プロセスで使用されます。

- 宛先データベースct2.example.comには、システム生成名を持つキューがあります。このキューは、適用プロセスで使用されます。

- 取得データベースct3.example.comでは、システム生成名を持つリアルタイム・ダウンストリーム取得プロセスを使用して、hr.employees表に対するデータ操作言語(DML)の変更を取得します。

- 取得データベースct3.example.comでは、hr.employees表の行LCRにsalaryおよびcommission_pct列以外のすべての列を保持するKEEP_COLUMNS宣言ルールベースの変換が使用されます。

- ct3.example.comデータベースでは、システム生成名を持つ伝播が実行されます。この伝播によって、ct3.example.comデータベースから取得された変更がct2.example.comデータベースに送信されます。

- 宛先データベースct2.example.comでは、システム生成名を持つ適用プロセスが使用されます。この適用プロセスでは、システム生成名を持つ変更ハンドラを使用して、hr.employees表に対する挿入、更新および削除に関して取得された行LCRを処理します。変更ハンドラでは、行LCR内の情報を使用して、hr.emp_change_tableへの移入を行います。

関連項目:
「取得プロセス・パラメータの設定」

表の変更を記録するOracle Streams環境の管理

この項では、変更ハンドラの設定および設定解除について説明します。

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

- 変更ハンドラの設定解除および設定

- 既存のOracle Streamsコンポーネントを使用した表の変更の記録

- チェンジ・テーブルのメンテナンス

- Oracle Streams環境の管理

変更ハンドラの設定解除および設定

DBMS_APPLY_ADMパッケージのSET_CHANGE_HANDLERプロシージャでは、単一の適用プロセスの対象として指定された表に対する特定の操作用の変更ハンドラを設定解除および設定できます。このプロシージャでは、指定された表に対する変更を取得し、その変更を指定された適用プロセスに送信するようにOracle Streamsコンポーネントが構成されていると想定されます。

この項の例では、「ローカル取得とリモート適用を使用した表の変更の記録およびレプリケーション」で作成された更新操作用の変更ハンドラを設定解除するものとします。次に、この変更ハンドラを再設定します。

変更ハンドラを設定するには、次の手順を実行します。

1. 適用プロセスが使用されるデータベースにOracle Streams管理者として接続します。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

2. 変更する変更ハンドラを識別します。

この例では、hr.departments表に対するUPDATE操作用の変更ハンドラを設定解除します。これらの変更はapp$chg38適用プロセスによって適用されると想定します。次の問合せを実行して、チェンジ・テーブルの所有者、チェンジ・テーブルの名前、チェンジ・テーブルで追跡される取得値および変更ハンドラの名前を調べます。

COLUMN CHANGE_TABLE_OWNER HEADING 'Change Table Owner' FORMAT A20
COLUMN CHANGE_TABLE_NAME HEADING 'Change Table Name' FORMAT A20
COLUMN CAPTURE_VALUES HEADING 'Capture|Values' FORMAT A7
COLUMN HANDLER_NAME HEADING 'Change Handler Name' FORMAT A25

SELECT CHANGE_TABLE_OWNER,
CHANGE_TABLE_NAME,
CAPTURE_VALUES,
HANDLER_NAME
FROM DBA_APPLY_CHANGE_HANDLERS
WHERE SOURCE_TABLE_OWNER = 'HR' AND
SOURCE_TABLE_NAME  = 'DEPARTMENTS' AND
APPLY_NAME         = 'APP$CHG38' AND
OPERATION_NAME     = 'UPDATE';

出力は次のようになります。

Capture
Change Table Owner   Change Table Name    Values  Change Handler Name
-------------------- -------------------- ------- -------------------------
HR                   DEP_CHANGE_TABLE     *       HR_DEPARTMENTS_CHG$10

この問合せで返される値を書き留めて、この例の後続の手順で使用してください。

3. 変更ハンドラを設定解除します。
変更ハンドラを設定解除するには、SET_CHANGE_HANDLERプロシージャのchange_handler_nameパラメータにNULLを指定し、他のプロシージャ・パラメータを使用してチェンジ・テーブルの所有者、チェンジ・テーブルの名前、取得値、操作、ソース・テーブルおよび適用プロセスを指定します。次に例を示します。

BEGIN
DBMS_APPLY_ADM.SET_CHANGE_HANDLER(
change_table_name    =>  'hr.dep_change_table',
source_table_name    =>  'hr.departments',
capture_values       =>  '*',
apply_name           =>  'app$chg38',
operation_name       =>  'UPDATE',
change_handler_name  =>  NULL);
END;
/

この変更ハンドラが設定解除されると、今後更新の変更が記録されなくなります。

4. 変更ハンドラを設定します。
変更ハンドラを設定するには、SET_CHANGE_HANDLERプロシージャのchange_handler_nameパラメータに変更ハンドラを指定し、他のプロシージャ・パラメータを使用してチェンジ・テーブルの所有者、チェンジ・テーブルの名前、取得値、操作、ソース・テーブルおよび適用プロセスを指定します。次に例を示します。

BEGIN
DBMS_APPLY_ADM.SET_CHANGE_HANDLER(
change_table_name    =>  'hr.dep_change_table',
source_table_name    =>  'hr.departments',
capture_values       =>  '*',
apply_name           =>  'app$chg38',
operation_name       =>  'UPDATE',
change_handler_name  =>  'hr_departments_chg$10');
END;
/

この変更ハンドラが再設定されると、更新の変更が記録されるようになります。

既存のOracle Streamsコンポーネントを使用した表の変更の記録

表に対する変更を記録するように既存のOracle Streamsコンポーネントを構成できます。これらの既存のコンポーネントには、取得プロセス、伝播および適用プロセスがあります。既存のコンポーネントを使用するには、DBMS_STREAMS_ADMパッケージのMAINTAIN_CHANGE_TABLEプロシージャを実行するときにコンポーネント名を指定します。

この項の例は、「1つのデータベースでのローカル取得とローカル適用を使用した表の変更の記録」で作成されたOracle Streams環境に基づきます。その例では、hr.jobs表に対する変更を記録するOracle Streams環境を構成しました。この項の例では、hr.employees表に対する変更も記録するように、既存の取得プロセスと適用プロセスを構成します。

次の表に、hr.employees表で記録される変更に関する事前の決定を示します。

決定

この例での前提

構成する環境のタイプの決定

この例では、1つのデータベースでローカル取得とローカル適用を実行する既存のOracle Streamsコンポーネントを使用します。

追跡する列の決定

この例では、hr.employees表のすべての列を追跡します。

記録するメタデータの決定

この例では、command_type、value_type (OLDまたはNEW)およびcommit_scnメタデータを記録します。

更新操作に応じて追跡する値の決定

この例では、ソース・テーブルに対して更新操作が実行されたときに、古い列値と新しい列値の両方を追跡します。

KEEP_COLUMNS変換を構成するかどうかの決定

この例では、KEEP_COLUMNS宣言ルールベースの変換を構成しません。

チェンジ・テーブルに対してCREATE TABLEオプションを指定するかどうかの決定

この例では、どのCREATE TABLEオプションも指定しません。チェンジ・テーブルは、デフォルトのCREATE TABLEオプションを使用して作成されます。

構成アクションを直接実行するか、スクリプトで実行するかの決定

この例では、構成アクションを直接実行します。スクリプトは使用しません。

ソース・テーブルをレプリケートするかどうかの決定

この例では、ソース・テーブルをレプリケートしません。

既存のOracle Streamsコンポーネントを使用して表に対する変更を記録するには、次の手順を実行します。

1. MAINTAIN_CHANGE_TABLEプロシージャを実行するために必要な前提条件を満たしていることを確認します。手順については、「MAINTAIN_CHANGE_TABLEプロシージャに関する前提条件」を参照してください。
この構成では、次のタスクを完了する必要があります。

- データベースでOracle Streams管理者を構成します。「すべてのデータベースでのOracle Streams管理者の構成」を参照してください。

- データベースがARCHIVELOGモードであることを確認します。「ソース・データベースがARCHIVELOGモードであることの確認」を参照してください。

- データベースで初期化パラメータが適切に設定されていることを確認します。「Oracle Streamsに関連する初期化パラメータの設定」を参照してください。

- データベースでOracle Streamsプールを適切に構成します。「Oracle Streamsプールの構成」を参照してください。

この例では、これらの前提条件はすでに満たされているはずです。既存のOracle Streams環境では、hr.jobs表に対する変更が記録されているためです。

2. 既存のOracle Streamsコンポーネントの名前を調べます。
SQL*Plusで、コンポーネントが存在するデータベースに接続し、該当するデータ・ディクショナリ・ビューを問い合せます。

- データベースの取得プロセスの名前を調べるには、DBA_CAPTUREビューのCAPTURE_NAME列を問い合せます。

- データベースの伝播の名前を調べるには、DBA_PROPAGATIONビューのPROPAGATION_NAME列を問い合せます。

- データベースの適用プロセスの名前を調べるには、DBA_APPLYビューのAPPLY_NAME列を問い合せます。

この例では、1つのデータベースで取得プロセスと適用プロセスを使用して変更を記録します。したがって、伝播は使用しません。

取得プロセスの名前がcap$chg3であり、適用プロセスの名前がapp$chg4であると想定します。

SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

3. 既存の取得プロセスが使用されるデータベースにOracle Streams管理者として接続します。

4. MAINTAIN_CHANGE_TABLEプロシージャを実行します。

BEGIN
DBMS_STREAMS_ADM.MAINTAIN_CHANGE_TABLE(
change_table_name       => 'hr.employees_change_table',
source_table_name       => 'hr.employees',
column_type_list        => 'employee_id VARCHAR2(6),
first_name VARCHAR2(20),
last_name VARCHAR2(25),
email VARCHAR2(25),
phone_number VARCHAR2(20),
hire_date DATE,
job_id VARCHAR2(10),
salary NUMBER(8,2),
commission_pct NUMBER(2,2),
manager_id NUMBER(6),
department_id NUMBER(4)',
extra_column_list        => 'command_type,value_type,commit_scn',
capture_values           => '*',
capture_name             => 'cap$chg3',
apply_name               => 'app$chg4',
keep_change_columns_only => FALSE);
END;
/

このプロシージャでは、指定のない各パラメータにはデフォルト値が使用されます。hr.jobs表のすべての列がcolumn_type_listパラメータで指定されているため、keep_change_columns_onlyパラメータはFALSEに設定されています。

このプロシージャが完了したら、Oracle Streams環境が構成されます。

このプロシージャがエラーによって停止した場合は、エラーからのリカバリ方法またはDBMS_STREAMS_ADM.RECOVER_OPERATIONプロシージャを使用して構成操作をロールバックする方法について、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

構成されたOracle Streams環境は次の特性を持ちます。

- 前述の「1つのデータベースでのローカル取得とローカル適用を使用した表の変更の記録」で説明した特性を持ちます。

- 無条件のサプリメンタル・ログ・グループには、hr.employees表のすべての列が含まれます。

- データベースにはhr.employees_change_tableが存在します。このチェンジ・テーブルの定義は次のとおりです。

Name                                      Null?    Type
----------------------------------------- -------- ---------------------------
COMMAND_TYPE$                                      VARCHAR2(10)
VALUE_TYPE$                                        VARCHAR2(3)
COMMIT_SCN$                                        NUMBER
EMPLOYEE_ID                                        VARCHAR2(6)
FIRST_NAME                                         VARCHAR2(20)
LAST_NAME                                          VARCHAR2(25)
EMAIL                                              VARCHAR2(25)
PHONE_NUMBER                                       VARCHAR2(20)
HIRE_DATE                                          DATE
JOB_ID                                             VARCHAR2(10)
SALARY                                             NUMBER(8,2)
COMMISSION_PCT                                     NUMBER(2,2)
MANAGER_ID                                         NUMBER(6)
DEPARTMENT_ID                                      NUMBER(4)

- 取得プロセスcap$chg3では、hr.employees表に対するデータ操作言語(DML)の変更を取得します。

- 適用プロセスapp$chg4では、システム生成名を持つ変更ハンドラを使用して、hr.employees表に対する挿入、更新および削除に関して取得された行LCRを処理します。変更ハンドラでは、行LCR内の情報を使用して、hr.employees_change_tableへの移入を行います。

チェンジ・テーブルのメンテナンス

チェンジ・テーブルは、時間の経過に伴って大きくなることがあります。1つ以上のチェンジ・テーブルを問い合せて、トランザクション一貫性が保証された一連の変更データを取得できます。変更データが不要になった場合は、チェンジ・テーブルから削除できます。これらの操作を実行するには、MAINTAIN_CHANGE_TABLEプロシージャの実行時にextra_column_listパラメータにcommit_scnを含めることで、コミットSCNメタデータを追跡するようにチェンジ・テーブルを構成します。コミットSCNを使用すると、一貫性が保証されたデータを取得したり、削除する不要データを指定できます。

この項の例では、次の各項で作成されたチェンジ・テーブルをメンテナンスします。

- hr.jobs_change_tableは、「1つのデータベースでのローカル取得とローカル適用を使用した表の変更の記録」の例で作成されたものです。

- hr.employees_change_tableは、「既存のOracle Streamsコンポーネントを使用した表の変更の記録」で作成されたものです。

この項の例では、チェンジ・テーブルを問い合せてトランザクション一貫性が保証された一連の変更データを取得してから、表示された変更データを削除します。

チェンジ・テーブルをメンテナンスするには、次の手順を実行します。

1. チェンジ・テーブルに変更を適用する適用プロセスの現在の最低水位標を調べます。この最低水位標以下のシステム変更番号(SCN)でコミットされた変更は確実に適用されています。

たとえば、適用プロセスの名前がapp$chg4である場合は、次の問合せを実行してその最低水位標を調べます。

SELECT APPLIED_MESSAGE_NUMBER
FROM DBA_APPLY_PROGRESS
WHERE APPLY_NAME='APP$CHG4';

返された最低水位標SCNを書き留めます。この例では、最低水位標SCNは663090であるとします。

2. 手順1で返された最低水位標以下の変更について、チェンジ・テーブルを問い合せます。

たとえば、hr.jobs_change_tableに対しては次の問合せを実行します。

SELECT * FROM hr.jobs_change_table WHERE commit_scn$ <= 663090;

たとえば、hr.employees_change_tableに対しては次の問合せを実行します。

SELECT * FROM hr.employees_change_table WHERE commit_scn$ <= 663090;

これらの問合せでは、手順1で返された最低水位標SCNを指定します。返される変更のトランザクション一貫性は、指定したSCNまで保証されています。

3. 手順2で表示された変更が不要な場合は、次の文を実行してその変更を削除します。

DELETE FROM hr.jobs_change_table WHERE commit_scn$ <= 663090;

DELETE FROM hr.employees_change_table WHERE commit_scn$ <= 663090;

COMMIT;

これらの問合せでは、手順1で返され、手順2の問合せで使用したものと同じ最低水位標SCNを指定します。

他の方法でチェンジ・テーブルをメンテナンスすることもできます。たとえば、2つのSCN値の間の変更の範囲を使用して、チェンジ・テーブルを問い合せることができます。また、2つ以上のチェンジ・テーブル内の一貫性が保証された一連のデータを表示するビューを作成することもできます。

関連項目:
「適用プロセスの最低水位標と最高水位標」

Oracle Streams環境の管理

MAINTAIN_CHANGE_TABLEプロシージャによってOracle Streams環境が構成されたら、次の表に示す項を参照して、Oracle Streams環境を管理できます。

管理対象

参照先

サプリメンタル・ロギング

『Oracle Streamsレプリケーション管理者ガイド』

取得プロセス

「取得プロセスの管理」

適用プロセス

第17章「Oracle Streams情報コンシュームの管理」

文DMLハンドラ

「文DMLハンドラの管理」

キュー

「キューの管理」

伝播

「Oracle Streamsの伝播および伝播ジョブの管理」

ルール

第18章「ルールの管理」

表の変更を記録するOracle Streams環境の監視

この項では、表の変更を追跡する構成でのOracle Streamsコンポーネントの監視について説明します。

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

- チェンジ・テーブルの監視

- 変更ハンドラの監視

- Oracle Streams環境の監視

チェンジ・テーブルの監視

他のデータベース表を監視する場合と同様に、SELECT文を使用してチェンジ・テーブルを監視できます。チェンジ・テーブルの列は、MAINTAIN_CHANGE_TABLEプロシージャのcolumn_type_listパラメータによって異なります。チェンジ・テーブルには、ソース・テーブルの各列に対応する列を追跡対象として含めることも、ソース・テーブルの列のサブセットを含めることもできます。また、チェンジ・テーブルには、各変更に関するメタデータを含むいくつかの列を追加することもできます。

たとえば、「1つのデータベースでのローカル取得とローカル適用を使用した表の変更の記録」で構成されたOracle Streams環境では、hr.jobs表に対する変更が記録されます。hr.jobs表の各列がチェンジ・テーブルhr.jobs_change_tableで追跡され、デフォルトのメタデータ列(command_type$、value_type$およびcommit_scn$)がチェンジ・テーブルに追加されています。

このサンプル・チェンジ・テーブルを監視するには、次の手順を実行します。

1. データベースにhrユーザーとして接続します。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

2. ソース・テーブルを変更して、チェンジ・テーブルに移入されるようにします。

INSERT INTO hr.jobs VALUES('BN_CNTR','Bean Counter',6000,8000);
COMMIT;

UPDATE hr.jobs SET min_salary=7000 WHERE job_id='BN_CNTR';
COMMIT;

DELETE FROM hr.jobs WHERE job_id='BN_CNTR';
COMMIT;

3. チェンジ・テーブルを問い合せます。

COLUMN COMMAND_TYPE$ HEADING 'Command Type' FORMAT A12
COLUMN VALUE_TYPE$ HEADING 'Value|Type' FORMAT A5
COLUMN COMMIT_SCN$ HEADING 'Commit SCN' FORMAT 9999999
COLUMN JOB_ID HEADING 'Job ID' FORMAT A10
COLUMN JOB_TITLE HEADING 'Job Title' FORMAT A12
COLUMN MIN_SALARY HEADING 'Minimum|Salary' FORMAT 9999999
COLUMN MAX_SALARY HEADING 'Maximum|Salary' FORMAT 9999999

SELECT * FROM hr.jobs_change_table;

出力は次のようになります。

Value                                     Minimum  Maximum
Command Type Type  Commit SCN Job ID     Job Title      Salary   Salary
------------ ----- ---------- ---------- ------------ -------- --------
INSERT       NEW       663075 BN_CNTR    Bean Counter     6000     8000
UPDATE       OLD       663082 BN_CNTR    Bean Counter     6000     8000
UPDATE       NEW       663082 BN_CNTR    Bean Counter     7000     8000
DELETE       OLD       663090 BN_CNTR    Bean Counter     7000     8000

この出力には、手順2で行った変更が示されます。

変更ハンドラの監視

この項では、変更ハンドラの監視について説明します。

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

- 変更ハンドラに関する一般情報の表示

- 変更ハンドラの対象となるチェンジ・テーブルとソース・テーブルの表示

変更ハンドラに関する一般情報の表示

DBA_APPLY_CHANGE_HANDLERSビューを問い合せて、データベースの各変更ハンドラに関する次の情報を表示できます。

- 変更ハンドラの名前

- 更新操作用の変更ハンドラによって追跡される取得値(新しい列値の場合はNEW、古い列値の場合はOLD、両方の場合は*)

- 変更ハンドラを使用している適用プロセスの名前

- 変更ハンドラが起動される操作(INSERT、UPDATEまたはDELETE)

次の問合せを実行すると、前述の情報が表示されます。

COLUMN HANDLER_NAME HEADING 'Change Handler Name' FORMAT A30
COLUMN CAPTURE_VALUES HEADING 'Capture|Values' FORMAT A7
COLUMN APPLY_NAME HEADING 'Apply|Process' FORMAT A10
COLUMN OPERATION_NAME HEADING 'Operation' FORMAT A10

SELECT HANDLER_NAME,
CAPTURE_VALUES,
APPLY_NAME,
OPERATION_NAME
FROM DBA_APPLY_CHANGE_HANDLERS
ORDER BY HANDLER_NAME;

出力は次のようになります。

Capture Apply
Change Handler Name            Values  Process    Operation
------------------------------ ------- ---------- ----------
HR_DEPARTMENTS_CHG$40                  APP$CHG38  INSERT
HR_DEPARTMENTS_CHG$41                  APP$CHG38  DELETE
HR_DEPARTMENTS_CHG$42          *       APP$CHG38  UPDATE
HR_JOBS_CHG$80                         APP$CHG79  INSERT
HR_JOBS_CHG$81                         APP$CHG79  DELETE
HR_JOBS_CHG$82                 *       APP$CHG79  UPDATE

INSERTおよびDELETE操作の「Capture Values」列がNULLであることに注意してください。DBA_APPLY_CHANGE_HANDLERSビューには、UPDATE操作を追跡する変更ハンドラの取得値のみが表示されます。挿入については新しい列値のみが対象となり、削除については古い列値のみが対象となります。

変更ハンドラの対象となるチェンジ・テーブルとソース・テーブルの表示

DBA_APPLY_CHANGE_HANDLERSビューを問い合せて、データベースの各変更ハンドラに関する次の情報を表示できます。

- 変更ハンドラの名前

- ソース・テーブルに対する変更を追跡するチェンジ・テーブルの所有者

- ソース・テーブルに対する変更を追跡するチェンジ・テーブルの名前

- ソース・テーブルの所有者

- ソース・テーブルの名前

次の問合せを実行すると、前述の情報が表示されます。

COLUMN HANDLER_NAME HEADING 'Change Handler Name' FORMAT A25
COLUMN CHANGE_TABLE_OWNER HEADING 'Change|Table|Owner' FORMAT A8
COLUMN CHANGE_TABLE_NAME HEADING 'Change|Table|Name' FORMAT A17
COLUMN SOURCE_TABLE_OWNER HEADING 'Source|Table|Owner' FORMAT A8
COLUMN SOURCE_TABLE_NAME HEADING 'Source|Table|Name' FORMAT A17

SELECT HANDLER_NAME,
CHANGE_TABLE_OWNER,
CHANGE_TABLE_NAME,
SOURCE_TABLE_OWNER,
SOURCE_TABLE_NAME
FROM DBA_APPLY_CHANGE_HANDLERS
ORDER BY HANDLER_NAME;

出力は次のようになります。

Change   Change            Source   Source
Table    Table             Table    Table
Change Handler Name       Owner    Name              Owner    Name
------------------------- -------- ----------------- -------- -----------------
HR_DEPARTMENTS_CHG$40     HR       DEP_CHANGE_TABLE  HR       DEPARTMENTS
HR_DEPARTMENTS_CHG$41     HR       DEP_CHANGE_TABLE  HR       DEPARTMENTS
HR_DEPARTMENTS_CHG$42     HR       DEP_CHANGE_TABLE  HR       DEPARTMENTS
HR_JOBS_CHG$80            HR       JOBS_CHANGE_TABLE HR       JOBS
HR_JOBS_CHG$81            HR       JOBS_CHANGE_TABLE HR       JOBS
HR_JOBS_CHG$82            HR       JOBS_CHANGE_TABLE HR       JOBS

Oracle Streams環境の監視

MAINTAIN_CHANGE_TABLEプロシージャによってOracle Streams環境が構成されたら、次の表に示す項を参照して、Oracle Streams環境を監視できます。

監視対象

参照先

サプリメンタル・ロギング

「サプリメンタル・ロギングの監視」

取得プロセス

「取得プロセスの監視」

適用プロセス

第26章「Oracle Streams適用プロセスの監視」

文DMLハンドラ

「文DMLハンドラに関する情報の表示」

キュー

「バッファ・キューの監視」

伝播

「Oracle Streamsの伝播および伝播ジョブの監視」

ルール

第27章「ルールの監視」

21 その他の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 Databaseユーティリティ』を参照

次の手順に従って、Oracle Streamsを使用するデータベースで全データベースのエクスポート/インポートを実行します。

1. エクスポート・データベースに、他のデータベースからの伝播のための宛先キューが含まれる場合、エクスポート・データベースにメッセージを伝播する各伝播を停止します。DBMS_PROPAGATION_ADMパッケージのSTOP_PROPAGATIONプロシージャを使用すると、伝播を停止できます。

2. 手順1で無効化した伝播ジョブで使用されていたデータベース・リンクが、インポート・データベースが動作するコンピュータを指し示すように、ネットワーク構成に必要な変更を加えます。
この手順を実行するには、これらの伝播ジョブで使用されていたデータベース・リンクを再作成するか、またはソース・キューが含まれるデータベースでOracleネットワーキング・ファイルを変更する必要がある場合があります。

3. エクスポート・データベースに対するデータ操作言語(DML)およびデータ定義言語(DDL)変更を中止するようすべてのユーザーに通知し、これらの変更が中止されるまで待機します。

4. エクスポート・データベースの現行のシステム変更番号(SCN)を書き留めます。DBMS_FLASHBACKパッケージのGET_SYSTEM_CHANGE_NUMBERファンクションを使用すると、現行の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値を7000000とします。

この手順を実行した後は、エクスポート・データベースで実行中の取得プロセスを停止しないでください。手順7dでは、V$STREAMS_CAPTURE動的パフォーマンス・ビューを使用して、手順3の後にデータベースに対しDMLまたはDDL変更が加えられていないことを確認するよう指示しています。取得プロセスが停止および再起動されると、このビューの取得プロセスに関する情報がリセットされます。

手順7dのチェックを有効にするには、取得プロセスでこの情報がリセットされないことが必要です。取得プロセスが自動的に停止されないようにするには、取得プロセスのmessage_limitおよびtime_limitパラメータがINFINITE以外の値に設定されている場合、これらのパラメータをINFINITEに設定する必要があります。

5. ダウンストリーム取得プロセスによってエクスポート・データベースで行われた変更が取得されている場合は、手順4で特定したSCNを含むログ・ファイルがダウンストリーム・データベースに転送され、取得プロセス・セッションに追加されていることを確認します。この情報を特定できる問合せについては、「各取得プロセスの登録済REDOログ・ファイルの表示」を参照してください。

6. エクスポート・データベースで適用プロセスが実行されておらず、メッセージが伝播されていない場合は、この時点で全データベースのエクスポートを開始します。必要なOracle Streamsメタデータがエクスポートされるように、FULLエクスポート・パラメータがyに設定されていることを確認します。

エクスポート・データベースで1つ以上の適用プロセスが実行されているか、またはメッセージが伝播されている場合は、エクスポートを開始せずに次の手順に進みます。

7. エクスポート・データベースが任意の取得プロセスによって取得された変更のソース・データベースの場合は、各取得プロセスに対して次の手順を実行します。

1. 取得プロセスによって、手順4で決定したSCNに対応するREDOレコードがスキャンされるまで待機します。取得プロセスで最後にスキャンされたREDOレコードのSCNは、V$STREAMS_CAPTURE動的パフォーマンス・ビューのCAPTURE_MESSAGE_NUMBER列を問い合せることによって表示できます。次の手順に進む前に、CAPTURE_MESSAGE_NUMBERの値が、手順4で特定したSCN以上であることを確認します。

2. SQL*Plusで、データベースにOracle Streams管理者として接続します。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

3. 適用プロセスが、取得データベースからのすべての変更を宛先データベースに適用するまで、Oracle Streams環境を監視します。たとえば、取得プロセスの名前がcapture、適用プロセスの名前がapply、宛先データベースのグローバル名がdest.example.com、手順4での戻りSCN値が7000000の場合は、取得データベースで次の問合せを実行します。

SELECT cap.ENQUEUE_MESSAGE_NUMBER
FROM V$STREAMS_CAPTURE cap
WHERE cap.CAPTURE_NAME = 'CAPTURE' AND
cap.ENQUEUE_MESSAGE_NUMBER IN (
SELECT DEQUEUED_MESSAGE_NUMBER
FROM V$STREAMS_APPLY_READER@dest.example.com reader,
V$STREAMS_APPLY_COORDINATOR@dest.example.com coord
WHERE reader.APPLY_NAME = 'APPLY' AND
reader.DEQUEUED_MESSAGE_NUMBER = reader.OLDEST_SCN_NUM AND
coord.APPLY_NAME = 'APPLY' AND
coord.LWM_MESSAGE_NUMBER = coord.HWM_MESSAGE_NUMBER AND
coord.APPLY# = reader.APPLY#) AND
cap.CAPTURE_MESSAGE_NUMBER >= 7000000;

この問合せで行が戻される場合は、取得データベースからのすべての変更が宛先データベースに適用済で、次の手順に進むことができます。

この問合せの結果が通常より長い時間が経過しても返されない場合は、ソース・データベースのDBA_CAPTUREビューおよび宛先データベースのDBA_APPLYビューのSTATUS列を問い合せて、環境のOracle Streamsクライアントが有効かどうかを確認します。「伝播ジョブのスケジュールに関する情報の表示」にある問合せを実行して、伝播の状態を確認できます。

Oracle Streamsクライアントが無効な場合は、再起動します。Oracle Streamsクライアントが再起動されない場合は、第30章「Oracle Streams環境内での問題の特定」を参照して、環境に対するトラブルシューティングを実行します。

この問合せでは、取得データベースと宛先データベース間に、Oracle Streams管理者にアクセスできるデータベース・リンクが存在すると想定しています。このようなデータベース・リンクが存在しない場合は、取得データベースおよび宛先データベースで2つの問合せを個別に実行できます。

4. 各取得プロセスのエンキュー・メッセージ番号が、手順4で特定したSCN以下であるかどうか検証します。各取得プロセスのエンキュー・メッセージ番号を表示するには、V$STREAMS_CAPTURE動的パフォーマンス・ビューのENQUEUE_MESSAGE_NUMBER列を問い合せます。

各取得プロセスのエンキュー・メッセージ番号が、手順4で特定したSCN以下である場合は、手順9に進みます。

ただし、いずれかの取得プロセスのエンキュー・メッセージ番号が手順4で特定したSCNを超えている場合は、手順4で特定したSCNより後に1つ以上のDMLまたはDDL変更が加えられており、これらの変更は取得プロセスによって取得およびエンキューされています。この場合は、手順1から、この項のすべての手順を再実行します。

注意:
この検証を有効にするため、手順4以降は各取得プロセスが途切れずに実行されている必要があります。

8. ダウンストリーム取得プロセスがエクスポート・データベースで行われた変更を取得した場合は、これらのダウンストリーム取得プロセスを削除します。ダウンストリーム取得プロセスは、手順14aで再作成します。

9. エクスポート・データベースに、メッセージを伝播させている伝播が存在する場合は、DBMS_PROPAGATIONパッケージのSTOP_PROPAGATIONプロシージャを使用して、これらの伝播を停止します。

10. エクスポート・データベースで1つ以上の適用プロセスが実行されているか、またはメッセージが伝播されている場合は、この時点で全データベースのエクスポートを開始します。必要なOracle Streamsメタデータがエクスポートされるように、FULLエクスポート・パラメータがyに設定されていることを確認します。手順6ですでにエクスポートを開始した場合は、手順11に進みます。

11. エクスポートが完了した後、インポート・データベースが動作しているコンピュータにエクスポート・ダンプ・ファイルを転送します。

12. 全データベースのインポートを実行します。必要なOracle Streamsメタデータがインポートされるように、STREAMS_CONFIGURATIONとFULLインポート・パラメータの両方がyに設定されていることを確認します。STREAMS_CONFIGURATIONインポート・パラメータのデフォルト設定はyです。また、インポート中は、インポート・データベースに対するDMLまたはDDL変更が行われないことを確認してください。

13. ダウンストリーム取得プロセスがデータベースで行われた変更を取得した場合は、ログ・ファイルがインポート・データベースからダウンストリーム・データベースに転送されるように、必要な変更を行います。手順については、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

14. ダウンストリーム取得プロセスを再作成します。

1. 必要に応じて、手順8で削除したダウンストリーム取得プロセスを再作成します。削除したこれらのダウンストリーム取得プロセスでは、エクスポート・データベースで行われた変更が取得されていました。インポート・データベースで行われた変更を取得するように、再作成したダウンストリーム取得プロセスを構成します。

2. 必要に応じて、エクスポート・データベースで実行していたダウンストリーム取得プロセスをインポート・データベースに再作成します。エクスポート・データベースに存在していたダウンストリーム取得プロセスはエクスポートされていません。

関連項目:
取得プロセスの構成の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

15. ローカル取得プロセスまたはダウンストリーム取得プロセスがデータベースで発生する変更を取得する場合は、インスタンス化のために変更が取得されるデータベース・オブジェクトをインポート・データベースに用意します。データベース・オブジェクトをインスタンス化のために準備する方法は、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

16. ユーザーに対し、インポート・データベースへのアクセスを許可し、エクスポート・データベースを停止します。

17. 手順1および9で無効化した伝播ジョブを有効化します。

18. 手順4で取得プロセスのmessage_limitまたはtime_limitパラメータの値をリセットした場合、インポート・データベースでそのパラメータを元の設定にリセットします。

Oracle Streams構成の削除

DBMS_STREAMS_ADMパッケージのREMOVE_STREAMS_CONFIGURATIONプロシージャを実行して、ローカル・データベースのOracle Streams構成を削除します。

注意:
このプロシージャを実行する場合は注意してください。データベースのOracle Streams構成全体を削除する必要がある場合にのみ、このプロシージャを実行します。

ローカル・データベースのOracle Streams構成を削除するには、Oracle Streams管理者としてデータベースに接続した状態で、次のプロシージャを実行します。

EXEC DBMS_STREAMS_ADM.REMOVE_STREAMS_CONFIGURATION();

このプロシージャの実行後、可能な場合はデータベースでOracle Streams管理者を削除します。

関連項目:
REMOVE_STREAMS_CONFIGURATIONプロシージャで実行されるアクションの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

第IV部

Oracle Streamsの監視

この部では、Oracle Streams環境の監視について説明します。この部の構成は、次のとおりです。

- 第22章「Oracle Streams環境の監視」

- 第23章「Oracle Streamsのトポロジおよびパフォーマンスの監視」

- 第24章「Oracle Streams暗黙的取得の監視」

- 第25章「Oracle Streamsのキューおよび伝播の監視」

- 第26章「Oracle Streams適用プロセスの監視」

- 第27章「ルールの監視」

- 第28章「ルールベースの変換の監視」

- 第29章「その他のOracle Streamsコンポーネントの監視」

22 Oracle Streams環境の監視

この章では、Oracle Streamsに関連する静的データ・ディクショナリ・ビューと動的パフォーマンス・ビューを示します。これらのビューを使用してOracle Streams環境を監視できます。

次の各項では、Oracle Streams環境の監視に使用するデータ・ディクショナリ・ビューについて説明します。

- Oracle Streamsの静的データ・ディクショナリ・ビューの概要

- Oracle Streams動的パフォーマンス・ビューのサマリー

注意:
Oracle Enterprise ManagerのOracle Streamsツールも、Oracle Streams環境を監視するための優れた手段です。詳細は、Oracle Database 2日でデータ・レプリケーションおよび統合ガイドおよびOracle Streamsツールのオンライン・ヘルプを参照してください。

関連項目:
この章で説明するデータ・ディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照

Oracle Streamsの静的データ・ディクショナリ・ビューの概要

表22-1に、Oracle Streamsの静的データ・ディクショナリ・ビューを示します。

表22-1 Oracle Streamsの静的データ・ディクショナリ・ビュー

ALL_ビュー

DBA_ビュー

USER_ビュー

ALL_APPLY

DBA_APPLY

N/A

ALL_APPLY_CHANGE_HANDLERS

DBA_APPLY_CHANGE_HANDLERS

N/A

ALL_APPLY_CONFLICT_COLUMNS

DBA_APPLY_CONFLICT_COLUMNS

N/A

ALL_APPLY_DML_HANDLERS

DBA_APPLY_DML_HANDLERS

N/A

ALL_APPLY_ENQUEUE

DBA_APPLY_ENQUEUE

N/A

ALL_APPLY_ERROR

DBA_APPLY_ERROR

N/A

ALL_APPLY_EXECUTE

DBA_APPLY_EXECUTE

N/A

N/A

DBA_APPLY_INSTANTIATED_GLOBAL

N/A

N/A

DBA_APPLY_INSTANTIATED_OBJECTS

N/A

N/A

DBA_APPLY_INSTANTIATED_SCHEMAS

N/A

ALL_APPLY_KEY_COLUMNS

DBA_APPLY_KEY_COLUMNS

N/A

N/A

DBA_APPLY_OBJECT_DEPENDENCIES

N/A

ALL_APPLY_PARAMETERS

DBA_APPLY_PARAMETERS

N/A

ALL_APPLY_PROGRESS

DBA_APPLY_PROGRESS

N/A

N/A

DBA_APPLY_SPILL_TXN

N/A

ALL_APPLY_TABLE_COLUMNS

DBA_APPLY_TABLE_COLUMNS

N/A

N/A

DBA_APPLY_VALUE_DEPENDENCIES

N/A

ALL_CAPTURE

DBA_CAPTURE

N/A

ALL_CAPTURE_EXTRA_ATTRIBUTES

DBA_CAPTURE_EXTRA_ATTRIBUTES

N/A

ALL_CAPTURE_PARAMETERS

DBA_CAPTURE_PARAMETERS

N/A

ALL_CAPTURE_PREPARED_DATABASE

DBA_CAPTURE_PREPARED_DATABASE

N/A

ALL_CAPTURE_PREPARED_SCHEMAS

DBA_CAPTURE_PREPARED_SCHEMAS

N/A

ALL_CAPTURE_PREPARED_TABLES

DBA_CAPTURE_PREPARED_TABLES

N/A

N/A

DBA_COMPARISON

USER_COMPARISON

N/A

DBA_COMPARISON_COLUMNS

USER_COMPARISON_COLUMNS

N/A

DBA_COMPARISON_ROW_DIF

USER_COMPARISON_ROW_DIF

N/A

DBA_COMPARISON_SCAN

USER_COMPARISON_SCAN

N/A

DBA_COMPARISON_SCAN_VALUES

USER_COMPARISON_SCAN_VALUES

ALL_EVALUATION_CONTEXT_TABLES

DBA_EVALUATION_CONTEXT_TABLES

USER_EVALUATION_CONTEXT_TABLES

ALL_EVALUATION_CONTEXT_VARS

DBA_EVALUATION_CONTEXT_VARS

USER_EVALUATION_CONTEXT_VARS

ALL_EVALUATION_CONTEXTS

DBA_EVALUATION_CONTEXTS

USER_EVALUATION_CONTEXTS

ALL_FILE_GROUP_EXPORT_INFO

DBA_FILE_GROUP_EXPORT_INFO

USER_FILE_GROUP_EXPORT_INFO

ALL_FILE_GROUP_FILES

DBA_FILE_GROUP_FILES

USER_FILE_GROUP_FILES

ALL_FILE_GROUP_TABLES

DBA_FILE_GROUP_TABLES

USER_FILE_GROUP_TABLES

ALL_FILE_GROUP_TABLESPACES

DBA_FILE_GROUP_TABLESPACES

USER_FILE_GROUP_TABLESPACES

ALL_FILE_GROUP_VERSIONS

DBA_FILE_GROUP_VERSIONS

USER_FILE_GROUP_VERSIONS

ALL_FILE_GROUPS

DBA_FILE_GROUPS

USER_FILE_GROUPS

N/A

DBA_HIST_STREAMS_APPLY_SUM

N/A

N/A

DBA_HIST_STREAMS_CAPTURE

N/A

N/A

DBA_HIST_STREAMS_POOL_ADVICE

N/A

ALL_PROPAGATION

DBA_PROPAGATION

N/A

N/A

DBA_RECOVERABLE_SCRIPT

N/A

N/A

DBA_RECOVERABLE_SCRIPT_BLOCKS

N/A

N/A

DBA_RECOVERABLE_SCRIPT_ERRORS

N/A

N/A

DBA_RECOVERABLE_SCRIPT_HIST

N/A

N/A

DBA_RECOVERABLE_SCRIPT_PARAM

N/A

N/A

DBA_REGISTERED_ARCHIVED_LOG

N/A

ALL_RULE_SET_RULES

DBA_RULE_SET_RULES

USER_RULE_SET_RULES

ALL_RULE_SETS

DBA_RULE_SETS

USER_RULE_SETS

ALL_RULES

DBA_RULES

USER_RULES

N/A

DBA_STREAMS_ADD_COLUMN

N/A

N/A

DBA_STREAMS_ADMINISTRATOR

N/A

ALL_STREAMS_COLUMNS

DBA_STREAMS_COLUMNS

N/A

N/A

DBA_STREAMS_DELETE_COLUMN

N/A

ALL_STREAMS_GLOBAL_RULES

DBA_STREAMS_GLOBAL_RULES

N/A

N/A

DBA_STREAMS_KEEP_COLUMNS

N/A

ALL_STREAMS_MESSAGE_CONSUMERS

DBA_STREAMS_MESSAGE_CONSUMERS

N/A

ALL_STREAMS_MESSAGE_RULES

DBA_STREAMS_MESSAGE_RULES

N/A

ALL_STREAMS_NEWLY_SUPPORTED

DBA_STREAMS_NEWLY_SUPPORTED

N/A

N/A

DBA_STREAMS_RENAME_COLUMN

N/A

N/A

DBA_STREAMS_RENAME_SCHEMA

N/A

N/A

DBA_STREAMS_RENAME_TABLE

N/A

ALL_STREAMS_RULES

DBA_STREAMS_RULES

N/A

ALL_STREAMS_SCHEMA_RULES

DBA_STREAMS_SCHEMA_RULES

N/A

N/A

DBA_STREAMS_SPLIT_MERGE

N/A

N/A

DBA_STREAMS_SPLIT_MERGE_HIST

N/A

N/A

DBA_STREAMS_STMT_HANDLERS

N/A

N/A

DBA_STREAMS_STMTS

N/A

ALL_STREAMS_TABLE_RULES

DBA_STREAMS_TABLE_RULES

N/A

N/A

DBA_STREAMS_TRANSFORMATIONS

N/A

ALL_STREAMS_TRANSFORM_FUNCTION

DBA_STREAMS_TRANSFORM_FUNCTION

N/A

N/A

DBA_STREAMS_TP_COMPONENT

N/A

N/A

DBA_STREAMS_TP_COMPONENT_LINK

N/A

N/A

DBA_STREAMS_TP_COMPONENT_STAT

N/A

N/A

DBA_STREAMS_TP_DATABASE

N/A

N/A

DBA_STREAMS_TP_PATH_BOTTLENECK

N/A

N/A

DBA_STREAMS_TP_PATH_STAT

N/A

ALL_STREAMS_UNSUPPORTED

DBA_STREAMS_UNSUPPORTED

N/A

ALL_SYNC_CAPTURE

DBA_SYNC_CAPTURE

N/A

ALL_SYNC_CAPTURE_PREPARED_TABS

DBA_SYNC_CAPTURE_PREPARED_TABS

N/A

N/A

DBA_SYNC_CAPTURE_TABLES

N/A

Oracle Streams動的パフォーマンス・ビューのサマリー

Oracle Streams動的パフォーマンス・ビューは次のとおりです。

- V$BUFFERED_PUBLISHERS

- V$BUFFERED_QUEUES

- V$BUFFERED_SUBSCRIBERS

- V$PROPAGATION_RECEIVER

- V$PROPAGATION_SENDER

- V$RULE

- V$RULE_SET

- V$RULE_SET_AGGREGATE_STATS

- V$STREAMS_APPLY_COORDINATOR

- V$STREAMS_APPLY_READER

- V$STREAMS_APPLY_SERVER

- V$STREAMS_CAPTURE

- V$STREAMS_POOL_ADVICE

- V$STREAMS_POOL_STATISTICS

- V$STREAMS_TRANSACTION

注意:

- Oracle Real Application Clusters(Oracle RAC)データベースを監視する場合は、動的パフォーマンス・ビューのGV$バージョンを使用します。

- これらの動的パフォーマンス・ビューの経過時間の統計を収集するには、TIMED_STATISTICS初期化パラメータをTRUEに設定します。

23 Oracle Streamsのトポロジおよびパフォーマンスの監視

Oracle Streamsパフォーマンス・アドバイザは、DBMS_STREAMS_ADVISOR_ADM PL/SQLパッケージと、データ・ディクショナリ・ビューのコレクションから構成されます。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のパフォーマンスの分析

- UTL_SPADVパッケージの使用

Oracle Streamsのトポロジについて

Oracle Streamsを使用すると、複数のデータベース間でメッセージを送信できます。Oracle Streams環境では、次のタイプのメッセージを送信できます。

- データベースの変更を含む論理変更レコード(LCR)

- ユーザー定義に基づくカスタム情報を含むユーザー・メッセージ

Oracle Streamsのトポロジとは、Oracle Streams環境におけるデータベース、これらのデータベースに構成されたOracle Streamsコンポーネントおよびこれらのコンポーネント間のメッセージ・フローを表したものです。

環境内のメッセージは、別々のストリーム・パスを流れます。ストリーム・パスは、取得プロセス、同期取得、またはアプリケーションがメッセージを生成してこれらをエンキューすると開始します。メッセージは、そのストリーム・パスで1つ以上の伝播およびキューを介して流れます。ストリーム・パスは、メッセージが適用プロセス、メッセージ・クライアントまたはアプリケーションによってデキューされると終了します。

現在、Oracle Streamsのトポロジは、ストリーム・パスが適用プロセスで終了した場合のストリーム・パスに関する情報のみを収集します。Oracle Streamsのトポロジは、メッセージ・クライアントまたはアプリケーションがメッセージをデキューしたときに終了するストリーム・パスを追跡しません。

関連項目:

- 「Oracle Streams取得プロセスによる暗黙的取得」

- 「キュー間でのメッセージの伝播」

- 「適用プロセスによる暗黙的コンシューム」

- 「キュー」

- 「Oracle Streamsで取得される情報のタイプ」

Oracle Streamsパフォーマンス・アドバイザについて

Oracle Streamsパフォーマンス・アドバイザは、DBMS_STREAMS_ADVISOR_ADM PL/SQLパッケージと、データ・ディクショナリ・ビューのコレクションから構成されます。DBMS_STREAMS_ADVISOR_ADMパッケージのANALYZE_CURRENT_PERFORMANCEプロシージャを使用すると、Oracle Streamsのトポロジに関する情報と、トポロジ内のOracle Streamsコンポーネントのパフォーマンスに関する情報を収集できます。

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

- Oracle Streamsパフォーマンス・アドバイザのデータ・ディクショナリ・ビュー

- Oracle Streamsのコンポーネントおよび統計

Oracle Streamsパフォーマンス・アドバイザのデータ・ディクショナリ・ビュー

Oracle Streamsパフォーマンス・アドバイザによって情報が収集されたら、次のデータ・ディクショナリ・ビューを問い合せることによって、それらを表示できます。

- DBA_STREAMS_TP_COMPONENTには、各データベースの各Oracle Streamsコンポーネントに関する情報が含まれています。

- DBA_STREAMS_TP_COMPONENT_LINKには、Oracle Streamsコンポーネント間でのメッセージ・フローの方法に関する情報が含まれています。

- DBA_STREAMS_TP_COMPONENT_STATには、各Oracle Streamsコンポーネントに関する一時的なパフォーマンス統計およびセッション統計が含まれています。

- DBA_STREAMS_TP_DATABASEには、Oracle Streamsコンポーネントを含む各データベースに関する情報が含まれています。

- DBA_STREAMS_TP_PATH_BOTTLENECKには、ストリーム・パスのメッセージ・フローの速度を低下させる可能性のあるOracle Streamsコンポーネントに関する一時的な情報が含まれています。

- DBA_STREAMS_TP_PATH_STATには、Oracle Streamsのトポロジ内に存在する各ストリーム・パスに関する一時的なパフォーマンス統計が含まれています。

トポロジの情報は、データ・ディクショナリ・ビューDBA_STREAMS_TP_DATABASE、DBA_STREAMS_TP_COMPONENTおよびDBA_STREAMS_TP_COMPONENT_LINKに永続的に格納されます。

DBA_STREAMS_TP_COMPONENT_STAT、DBA_STREAMS_TP_PATH_BOTTLENECKおよびDBA_STREAMS_TP_PATH_STATには、一時的な情報が含まれます。これらのビュー内のデータの一部は、ANALYZE_CURRENT_PERFORMANCEプロシージャを実行するユーザー・セッションのためにのみ保持されます。このユーザー・セッションが終了すると、これらの一時的な情報は消去されます。

関連項目:
「Oracle Streamsのトポロジの表示とOracle Streamsのパフォーマンスの分析」

Oracle Streamsのコンポーネントおよび統計

DBMS_STREAMS_ADVISOR_ADMパッケージは、次のOracle Streamsコンポーネントに関する情報を収集します。

- QUEUEは、メッセージを格納します。パッケージは、キューについて、次のコンポーネント・レベルの統計を収集します。

- ENQUEUE RATE

- SPILL RATE

- CURRENT QUEUE SIZE

- CAPTUREは、取得プロセスです。取得プロセスでは、REDOログにあるデータベース変更を取得し、変更を論理変更レコード(LCR)としてエンキューします。各取得プロセスには、次のサブコンポーネントがあります。

- LOGMINER BUILDERは、ビルダー・サーバーです。

- LOGMINER PREPARERは、プリペアラ・サーバーです。

- LOGMINER READERは、リーダー・サーバーです。

- CAPTURE SESSIONは、取得プロセス・セッションです。

このパッケージは、各取得プロセス(CAPTURE)について次のコンポーネント・レベル統計を収集します。

- CAPTURE RATE

- ENQUEUE RATE

- LATENCY

このパッケージは、取得プロセスのサブコンポーネントについてセッション・レベル統計も収集します。

- PROPAGATION SENDERは、ソース・キューから宛先キューへメッセージを送信します。このパッケージは、伝播送信者について次のコンポーネント・レベル統計を収集します。

- SEND RATE

- BANDWIDTH

- LATENCY

このパッケージは、伝播送信者についてセッション・レベル統計も収集します。

- PROPAGATION RECEIVERは、伝播送信者によって送信されたメッセージを宛先キューにエンキューします。このパッケージは、伝播受信者についてセッション・レベル統計を収集します。

- APPLYは適用プロセスです。これらのコンポーネントは、メッセージを直接適用するか、メッセージを適用ハンドラに送信します。このタイプのコンポーネントには、次のサブコンポーネントがあります。

- APPLY READERは、リーダー・サーバーです。

- APPLY COORDINATORは、コーディネータ・プロセスです。

- APPLY SERVERは、適用サーバーです。

このパッケージは、このコンポーネント(APPLY)について次のコンポーネント・レベル統計を収集します。

- MESSAGE APPLY RATE

- TRANSACTION APPLY RATE

- LATENCY

このパッケージは、サブコンポーネントについてセッション・レベル統計も収集します。

パッケージがコンポーネントまたはサブコンポーネントについてセッション・レベル統計を収集する場合、このセッション・レベル統計には次のものが含まれます。

- IDLEパーセンテージ

- FLOW CONTROLパーセンテージ

- 待機イベントのEVENTパーセンテージ

注意:
現在、DBMS_STREAMS_ADVISOR_ADMパッケージは、同期取得またはメッセージ・クライアントに関する情報を収集しません。

関連項目:

- コンポーネント・レベル統計の詳細は、「コンポーネント・レベル統計の表示」を参照

- セッション・レベル統計の詳細は、「セッション・レベル統計の表示」を参照

Oracle Streamsのトポロジのストリーム・パスについて

Oracle Streamsのトポロジのストリーム・パスは、ソースから宛先へのメッセージ・フローのことです。ストリーム・パスは、取得プロセス、同期取得またはアプリケーションがメッセージをキューにエンキューした場所から開始します。ストリーム・パスは、適用プロセスがメッセージをデキューした場所で終了します。ストリーム・パスは、複数のキューと伝播を介して適用プロセスに到達することがあります。したがって、単一のストリーム・パスが最後のコンポーネントに到達するまでに、複数のソース/宛先コンポーネント・ペアが生成される場合があります。

Oracle Streamsのトポロジは、それぞれのパスを簡単に監視できるように、各ストリーム・パスに番号を割り当てます。また、ストリーム・パスの2つの要素間の各リンクにも番号を割り当てます。この番号には、ストリーム・パス全体のリンクの位置が指定されます。

表23-1に、ストリーム・パスの例における各リンクの位置を示します。

表23-1 ストリーム・パスの例と各リンクの位置

始点コンポーネント

終点コンポーネント

位置

取得プロセス

キュー

1

キュー

伝播送信者

2

伝播送信者

伝播受信者

3

伝播受信者

キュー

4

キュー

適用プロセス

5

Oracle Streamsパフォーマンス・アドバイザは、Oracle Streams環境に関する情報を収集する際、各適用プロセスから開始して、その始点に戻りながら動作することによって、ストリーム・パスを追跡します。始点が取得プロセスの場合、Oracle Streamsパフォーマンス・アドバイザは、適用プロセスから取得プロセスへとパスを追跡します。メッセージをエンキューする同期取得またはアプリケーションが始点の場合、Oracle Streamsパフォーマンス・アドバイザは、適用プロセスから、メッセージがエンキューされるキューへとパスを追跡します。

次の各項では、レプリケーション環境の例とそれぞれのストリーム・パスについて説明します。

- Oracle Streams環境における個別のストリーム・パス

- Oracle Streamsレプリケーション環境における共有ストリーム・パス

関連項目:
Oracle Streamsレプリケーション環境のベスト・プラクティスの詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

Oracle Streams環境における個別のストリーム・パス

2つのデータベースを持つOracle Streams環境を考えてみます。各データベースは、取得プロセスによってレプリケートされたデータベース・オブジェクトに対する変更を取得して、その変更をもう一方のデータベースに送信します。これらの変更は、そこで適用プロセスによって適用されます。この環境におけるストリーム・パスは完全に別々のものです。

図23-1に、このタイプのOracle Streamsレプリケーション環境の例を示します。

図23-1 2つの個別のストリーム・パスが存在するOracle Streamsのトポロジ

Oracle Streamsパフォーマンス・アドバイザは、各Oracle StreamsコンポーネントにコンポーネントIDを割り当て、各パスにパスIDを割り当てます。図23-1のOracle Streamsのトポロジは、次の情報を示しています。

- Oracle Streams環境には、12のOracle Streamsコンポーネントがあります。

- Oracle Streams環境には、2つのストリーム・パスがあります。

- ストリーム・パス1は、コンポーネント1で始まり、コンポーネント6で終了します。

- ストリーム・パス2は、コンポーネント7で始まり、コンポーネント12で終了します。

Oracle Streamsレプリケーション環境における共有ストリーム・パス

単一ソースによって生成された変更を適用する複数の適用プロセスがある場合は、1つのストリーム・パスが複数のストリーム・パスに分かれます。この場合、ストリーム・パスの一部は共有されますが、パスは2つ以上の異なるストリーム・パスに分かれます。

図23-2は、このタイプのOracle Streams環境を示しています。

図23-2 単一ソースに複数の適用プロセスが存在するOracle Streamsのトポロジ

図23-2のOracle Streamsのトポロジには、次の情報が示されています。

- Oracle Streams環境には、10のOracle Streamsコンポーネントがあります。

- Oracle Streams環境には、2つのストリーム・パスがあります。

- ストリーム・パス1は、コンポーネント1で始まり、コンポーネント7で終了します。

- ストリーム・パス2は、コンポーネント1で始まり、コンポーネント10で終了します。

- コンポーネント1とコンポーネント2の間のメッセージ・フローはパス1とパス2の両方にあります。

関連項目:
「キュー間でのメッセージの伝播」

Oracle Streamsパフォーマンス・アドバイザによって収集される情報について

DBMS_STREAMS_ADVISOR_ADMパッケージのANALYZE_CURRENT_PERFORMANCEプロシージャは、Oracle StreamsのトポロジとOracle Streamsコンポーネントのパフォーマンスに関する情報を収集します。このプロシージャは、多数のデータ・ディクショナリ・ビューに情報を格納します。Oracle Streamsパフォーマンス・アドバイザを効果的に使用するには、プロシージャによる情報の収集方法と統計の計算方法を理解することが重要です。

このプロシージャは、Oracle Streams環境のスナップショットを取って、情報を収集し、統計を計算します。統計によっては、単一のスナップショットの情報のみで十分な場合があります。たとえば、キュー内の現在のメッセージ数を判断するために必要なスナップショットは1つのみです。ただし、他の統計を計算するには、2つのスナップショットを比較する必要があります。このような統計には、レート、帯域幅、イベントおよびフロー制御の各統計があります。このような統計を計算するため、ユーザー・セッションでの初回実行時には、2つのスナップショットが取られます。この後は、同じユーザー・セッションで実行するたびに1つのスナップショットを取り、前回の実行時に取得したスナップショットと比較します。

表23-2に、単一のユーザー・セッションでアドバイザが実行されるたびに、どのように情報が収集されるかを示します。

表23-2 Oracle Streamsパフォーマンス・アドバイザによるセッション内での情報の収集方法

アドバイザの実行

収集される情報

1

1. 統計のスナップショットを取ります。

2. 5秒以上待機します。

3. 統計のスナップショットをもう1つ取ります。

4. 最初のスナップショット・データと2番目のスナップショット・データを比較して、パフォーマンス統計を計算します。

2

1. 統計のスナップショットを取ります。

2. アドバイザの実行1の最後のスナップショットのデータと、アドバイザの実行2で取られたスナップショットを比較して、パフォーマンス統計を計算します。

3

1. 統計のスナップショットを取ります。

2. アドバイザの実行2のスナップショットのデータを、アドバイザの実行3で取られたスナップショットと比較して、パフォーマンス統計を計算します。

アドバイザの実行において最善の結果を得るために、次の基準を満たします。

- アドバイザの実行で使用される2つのスナップショットが取られる期間は、できるだけ多くのOracle Streamsコンポーネントを有効化しておいてください。特に、取得プロセス、伝播および適用プロセスを有効化しておく必要があります。また、キューは起動しておく必要があり、データベース・リンクはアクティブである必要があります。

- Oracle Streams環境でデータがレプリケートされる場合は、アドバイザの実行で使用される2つのスナップショットが取られる期間に、レプリケートされるデータベース・オブジェクトが、平均的か、または平均に近い頻度で更新されていることを確認します。Oracle Streamsレプリケーション環境のレプリケーション・アクティビティが典型的であるときにOracle Streamsパフォーマンス・アドバイザを実行すると、より正確な統計を収集できます。

- メッセージがOracle Streams環境のアプリケーションによって送信される場合は、アドバイザの実行で使用される2つのスナップショットが取られる期間に、そのアプリケーションが、平均的か、または平均に近い頻度でメッセージを送信していることを確認します。Oracle Streamsメッセージング環境で送信されるメッセージ数が平均値であるときにOracle Streamsパフォーマンス・アドバイザを実行すると、より正確な統計を収集できます。

Oracle Streamsのトポロジおよびパフォーマンスに関する情報の収集

Oracle StreamsのトポロジおよびOracle Streamsパフォーマンスに関する情報を収集するには、次の手順を実行します。

1. 情報の収集に使用するデータベースを指定します。このデータベースの管理ユーザーは、次の要件を満たしている必要があります。

- このユーザーには、Oracle Streamsコンポーネントを含む各データベースへのデータベース・リンクに対するアクセス権が必要です。

- ユーザーは、DBMS_STREAMS_AUTH.GRANT_ADMIN_PRIVILEGEプロシージャを使用して権限を付与されている必要があります。各データベース・リンクは、DBMS_STREAMS_AUTH.GRANT_ADMIN_PRIVILEGEプロシージャを使用して権限を付与されたリモート・データベースのユーザーに接続する必要があります。
Oracle Streamsコンポーネントを使用して各データベースでOracle Streams管理者を構成すると、Oracle Streams管理者に必要な権限が割り当てられます。Oracle Streams管理者を作成する方法の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

ご使用の環境に、これらの要件を満たすデータベースがない場合は、データベースを1つ選択し、必要なデータベース・リンクを構成して、必要な権限をユーザーに付与してから処理を進めてください。

Oracle Database 11g リリース2(11.2)データベースで実行されるOracle Streamsパフォーマンス・アドバイザでは、Oracle Database 10g リリース2(10.2)以上のデータベースを監視できます。リリース10.2より前のデータベースは監視できません。

2. SQL*Plusでは、手順1で指定したデータベースに、手順1に示される要件を満たすユーザーとして接続します。
たとえば、Oracle Streams管理者としてhub.example.comに接続します。

SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

3. DBMS_STREAMS_ADVISOR_ADMパッケージのANALYZE_CURRENT_PERFORMANCEプロシージャを実行します。

exec DBMS_STREAMS_ADVISOR_ADM.ANALYZE_CURRENT_PERFORMANCE;

4. 必要に応じて、手順3のプロシージャを実行したセッションと同じセッションで、ANALYZE_CURRENT_PERFORMANCEプロシージャを複数回再実行します。

exec DBMS_STREAMS_ADVISOR_ADM.ANALYZE_CURRENT_PERFORMANCE;

5. 次の問合せを実行して、手順4で収集された情報に関するアドバイザの実行IDを識別します。

SELECT DISTINCT ADVISOR_RUN_ID FROM DBA_STREAMS_TP_COMPONENT_STAT
ORDER BY ADVISOR_RUN_ID;

出力は次のようになります。

ADVISOR_RUN_ID
--------------
1
2

Oracle Streamsパフォーマンス・アドバイザは、アドバイザの実行IDを各実行の統計に割り当てます。Oracle Streamsコンポーネントのパフォーマンス統計の表示の問合せで出力される、最後のアドバイザ実行IDの値を使用します。この例では、問合せのアドバイザ実行IDに対して2を使用します。

Oracle Streamsパフォーマンス・アドバイザでは、ユーザー・セッションが終了すると、収集したパフォーマンス統計が削除される場合があります。したがって、ANALYZE_CURRENT_PERFORMANCEプロシージャを実行したセッションと同じセッションで、パフォーマンス統計の問合せを実行します。

Oracle Streams環境の現在のパフォーマンスを監視する必要がある場合は、必ず、これらの手順を完了してください。

ANALYZE_CURRENT_PERFORMANCEプロシージャは、Oracle Streams環境のいずれかのデータベースに新規Oracle Streamsコンポーネントが追加された場合にも実行する必要があります。このプロシージャを実行すると、新規コンポーネントに関する情報によって、Oracle Streamsのトポロジが更新されます。

関連項目:

- DBMS_STREAMS_ADVISOR_ADMパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

- 「Oracle Streamsのトポロジについて」

Oracle Streamsのトポロジの表示とOracle Streamsのパフォーマンスの分析

この項では、Oracle Streamsのトポロジを表示して、Oracle Streamsコンポーネントのパフォーマンスを監視するために使用できるいくつかの問合せについて説明します。これらの問合せは、「Oracle Streamsのトポロジについて」で説明したビューを指定します。

この項の問合せは、任意のOracle Stream環境で実行できます。ただし、問合せで示される出力には、図23-3に示すOracle Streamsレプリケーション環境の例を使用します。

図23-3 Oracle Streamsレプリケーション環境の例

『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』には、図23-3で示すOracle Streamsレプリケーション環境を構成するための手順が記載されています。この環境には、次の両方のタイプのストリーム・パスがあります。

- spoke1.example.comデータベースからhub.example.comデータベースへ、およびspoke2.example.comデータベースからhub.example.comデータベースへの個別のストリーム・パス・フロー。このタイプのストリーム・パスについては、「Oracle Streams環境における個別のストリーム・パス」を参照してください。

- hub.example.comデータベースからspoke1.example.comおよびspoke2.example.comデータベースへのパス・フローの一部を共有する2つのストリーム・パス。このタイプのストリーム・パスについては、「Oracle Streamsレプリケーション環境における共有ストリーム・パス」を参照してください。

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

- Oracle Streamsのトポロジの表示

- Oracle Streamsコンポーネントのパフォーマンス統計の表示

Oracle Streamsのトポロジの表示

Oracle Streamsのトポロジを表示するには、まず最初にDBMS_STREAMS_ADVISOR_ADMパッケージを使用して、Oracle Streams環境に関する情報を収集する必要があります。「Oracle Streamsのトポロジおよびパフォーマンスに関する情報の収集」を参照してください。

次の各項では、Oracle Streamsのトポロジの様々なタイプの情報を表示する方法について説明します。

- Oracle Streams環境でのデータベースの表示

- 各データベースでのOracle Streamsコンポーネントの表示

- Oracle Streamsのトポロジでの各ストリーム・パスの表示

Oracle Streams環境でのデータベースの表示

Oracle Streams環境のデータベースに関する次の情報を表示できます。

- 各データベースのグローバル名

- 各データベースでOracle Streamsパフォーマンス・アドバイザが実行された最終時刻

- 各データベースのバージョン番号

- 各データベースの互換性レベル

- 各データベースにOracle Diagnostics PackおよびOracle Tuning Packへのアクセス権があるかどうか

これらの情報を表示するには、次の問合せを実行します。

COLUMN GLOBAL_NAME HEADING 'Global Name' FORMAT A15
COLUMN LAST_QUERIED HEADING 'Last|Queried'
COLUMN VERSION HEADING 'Version' FORMAT A15
COLUMN COMPATIBILITY HEADING 'Compatibility' FORMAT A15
COLUMN MANAGEMENT_PACK_ACCESS HEADING 'Management Pack' FORMAT A20

SELECT GLOBAL_NAME, LAST_QUERIED, VERSION, COMPATIBILITY, MANAGEMENT_PACK_ACCESS
FROM DBA_STREAMS_TP_DATABASE;

次の出力は、「Oracle Streamsのトポロジの表示とOracle Streamsのパフォーマンスの分析」で説明したOracle Streamsレプリケーション環境のデータベースを示しています。

Last
Global Name     Queried   Version         Compatibility   Management Pack
--------------- --------- --------------- --------------- --------------------
HUB.EXAMPLE.COM 08-APR-08 11.1.0.7.0      11.1.0          DIAGNOSTIC+TUNING
SPOKE1.EXAMPLE. 08-APR-08 11.1.0.7.0      11.1.0          DIAGNOSTIC+TUNING
COM
SPOKE2.EXAMPLE. 08-APR-08 11.1.0.7.0      11.1.0          DIAGNOSTIC+TUNING
COM

この出力は、Oracle Streams環境のデータベースに関する次の情報を示しています。

- Global Name列は、データベースのグローバル名がhub.example.com、spoke1.example.comおよびspoke2.example.comであることを示しています。

- Last Queried列は、 2008年4月8日に、各データベースでOracle Streamsパフォーマンス・アドバイザが最後に実行されたことを示しています。

- Version列は、各データベースのバージョンが11.1.0.7.0であることを示しています。

- Compatibility列は、各データベースの互換性レベルが11.1.0であることを示しています。

- Management Pack列は、各データベースに、Oracle Diagnostics PackおよびOracle Tuning Packへのアクセス権があることを示しています。

関連項目:
データベースの互換性の詳細は、『Oracle Databaseアップグレード・ガイド』を参照

各データベースでのOracle Streamsコンポーネントの表示

Oracle Streams環境のコンポーネントに関する次の情報を表示できます。

- 各Oracle StreamsコンポーネントのコンポーネントID。Oracle Streamsのトポロジは、各コンポーネントにID番号を割り当て、この番号を使用してそのコンポーネントに関する情報と、そのコンポーネントを流れるストリーム・パスに関する情報を追跡します。

- Oracle Streamsコンポーネントの名前。取得プロセスおよび適用プロセスについては、問合せにより各プロセスの名前がリストされます。キューについては、各キューの名前がリストされます。伝播については、2つのOracle StreamsコンポーネントがOracle Streamsのトポロジで追跡されます。

- 伝播送信者の名前は、伝播のソース・キューおよびメッセージ送信先の宛先キューとデータベースになります。たとえば、spoke1.example.comデータベースのstrmadmin.destination_spoke1宛先キューにメッセージを送信するstrmadmin.source_hnsソース・キューを持つ伝播送信者は、次のように示されます。

"STRMADMIN"."SOURCE_HNS"=>"STRMADMIN"."DESTINATION_SPOKE1"
@SPOKE1.EXAMPLE.COM

- 伝播受信者の名前は、メッセージ送信元のソース・キューとデータベースおよび伝播の宛先キューになります。たとえば、hub.example.comデータベースのstrmadmin.source_hnsソース・キューからメッセージを受信して、それらをstrmadmin.destination_spoke1宛先キューにエンキューする伝播受信者は、次のように示されます。

"STRMADMIN"."SOURCE_HNS"@HUB.EXAMPLE.COM=>"STRMADMIN".
"DESTINATION_SPOKE1"

- Oracle Streamsコンポーネントのタイプ。次のタイプがあります。

- CAPTURE: 取得プロセスを示します。

- QUEUE: キューを示します。

- PROPAGATION SENDER: 伝播送信者を示します。

- PROPAGATION RECEIVER: 伝播受信者を示します。

- APPLY: 適用プロセスを示します。

- コンポーネントを含むデータベース

これらの情報を表示するには、次の問合せを実行します。

COLUMN COMPONENT_ID HEADING 'ID' FORMAT 999
COLUMN COMPONENT_NAME HEADING 'Name' FORMAT A43
COLUMN COMPONENT_TYPE HEADING 'Type' FORMAT A20
COLUMN COMPONENT_DB HEADING 'Database' FORMAT A10

SELECT COMPONENT_ID, COMPONENT_NAME, COMPONENT_TYPE, COMPONENT_DB
FROM DBA_STREAMS_TP_COMPONENT
ORDER BY COMPONENT_ID;

次の出力は、「Oracle Streamsのトポロジの表示とOracle Streamsのパフォーマンスの分析」で説明したOracle Streamsレプリケーション環境のコンポーネントを示しています。

ID Name                                        Type                 Database
---- ------------------------------------------- -------------------- ----------
1 "STRMADMIN"."DESTINATION_SPOKE1"            QUEUE                HUB.EXAMPL
E.COM
2 "STRMADMIN"."DESTINATION_SPOKE2"            QUEUE                HUB.EXAMPL
E.COM
3 "STRMADMIN"."SOURCE_HNS"                    QUEUE                HUB.EXAMPL
E.COM
4 "STRMADMIN"."SOURCE_HNS"=>"STRMADMIN"."DEST PROPAGATION SENDER   HUB.EXAMPL
INATION_SPOKE1"@SPOKE1.EXAMPLE.COM                               E.COM
5 "STRMADMIN"."SOURCE_HNS"=>"STRMADMIN"."DEST PROPAGATION SENDER   HUB.EXAMPL
INATION_SPOKE2"@SPOKE2.EXAMPLE.COM                               E.COM
6 "STRMADMIN"."SOURCE_HNS"@SPOKE1.EXAMPLE.COM PROPAGATION RECEIVER HUB.EXAMPL
=>"STRMADMIN"."DESTINATION_SPOKE1"                               E.COM
7 "STRMADMIN"."SOURCE_HNS"@SPOKE2.EXAMPLE.COM PROPAGATION RECEIVER HUB.EXAMPL
=>"STRMADMIN"."DESTINATION_SPOKE2"                               E.COM
8 APPLY_SPOKE1                                APPLY                HUB.EXAMPL
E.COM
9 APPLY_SPOKE2                                APPLY                HUB.EXAMPL
E.COM
10 CAPTURE_HNS                                 CAPTURE              HUB.EXAMPL
E.COM
11 "STRMADMIN"."DESTINATION_SPOKE1"            QUEUE                SPOKE1.EXA
MPLE.COM
12 "STRMADMIN"."SOURCE_HNS"                    QUEUE                SPOKE1.EXA
MPLE.COM
13 "STRMADMIN"."SOURCE_HNS"=>"STRMADMIN"."DEST PROPAGATION SENDER   SPOKE1.EXA
INATION_SPOKE1"@HUB.EXAMPLE.COM                                  MPLE.COM
14 "STRMADMIN"."SOURCE_HNS"@HUB.EXAMPLE.COM=>" PROPAGATION RECEIVER SPOKE1.EXA
STRMADMIN"."DESTINATION_SPOKE1"                                  MPLE.COM
15 APPLY_SPOKE1                                APPLY                SPOKE1.EXA
MPLE.COM
16 CAPTURE_HNS                                 CAPTURE              SPOKE1.EXA
MPLE.COM
17 "STRMADMIN"."DESTINATION_SPOKE2"            QUEUE                SPOKE2.EXA
MPLE.COM
18 "STRMADMIN"."SOURCE_HNS"                    QUEUE                SPOKE2.EXA
MPLE.COM
19 "STRMADMIN"."SOURCE_HNS"=>"STRMADMIN"."DEST PROPAGATION SENDER   SPOKE2.EXA
INATION_SPOKE2"@HUB.EXAMPLE.COM                                  MPLE.COM
20 "STRMADMIN"."SOURCE_HNS"@HUB.EXAMPLE.COM=>" PROPAGATION RECEIVER SPOKE2.EXA
STRMADMIN"."DESTINATION_SPOKE2"                                  MPLE.COM
21 APPLY_SPOKE2                                APPLY                SPOKE2.EXA
MPLE.COM
22 CAPTURE_HNS                                 CAPTURE              SPOKE2.EXA
MPLE.COM

関連項目:

- 「Oracle Streamsのトポロジについて」

- Oracle Streamsコンポーネントごとのパフォーマンス統計を示す問合せについては、「コンポーネント・レベル統計の表示」を参照

- 出力に示されたn-wayレプリケーション環境の詳細は、『Oracle Streams拡張例』を参照

Oracle Streamsのトポロジでの各ストリーム・パスの表示

Oracle Streamsのトポロジのストリーム・パスに関する次の情報を表示できます。

- パスID。Oracle Streamsのトポロジは、識別するストリーム・パスごとにID番号を割り当てます。このパスIDは、パスの各リンクに関連付けられます。単一のパスIDが関連付けられるコンポーネント・リンクの例には、次のものがあります。

- 取得プロセスからキュー

- キューから伝播送信者

- 伝播送信者から伝播受信者

- 伝播受信者からキュー

- キューから適用プロセス

- ソース・コンポーネントID。ソース・コンポーネントとは、メッセージが別のコンポーネントに送られるときの元のコンポーネントのことです。

- ソース・コンポーネントの名前。問合せ出力でのコンポーネントの命名方法の詳細は、「各データベースでのOracle Streamsコンポーネントの表示」を参照してください。

- 宛先コンポーネントID。宛先コンポーネントは、別のコンポーネントからメッセージを受信します。

- 宛先コンポーネントの名前。

- ストリーム・パス内の位置は、パスの特定リンクの場所を示します。たとえば、ある位置はパスの最初のリンク、パスの2番目のリンクなどの場合があります。

これらの情報を表示するには、次の問合せを実行します。

COLUMN PATH_ID HEADING 'Path|ID' FORMAT 9999
COLUMN SOURCE_COMPONENT_ID HEADING 'Source|Component|ID' FORMAT 9999
COLUMN SOURCE_COMPONENT_NAME HEADING 'Source|Component|Name' FORMAT A20
COLUMN DESTINATION_COMPONENT_ID HEADING 'Dest|Component|ID' FORMAT 9999
COLUMN DESTINATION_COMPONENT_NAME HEADING 'Dest|Component|Name' FORMAT A15
COLUMN POSITION HEADING 'Position' FORMAT 9999

SELECT PATH_ID,
SOURCE_COMPONENT_ID,
SOURCE_COMPONENT_NAME,
DESTINATION_COMPONENT_ID,
DESTINATION_COMPONENT_NAME,
POSITION
FROM DBA_STREAMS_TP_COMPONENT_LINK
ORDER BY PATH_ID, POSITION;

次の出力は、「各データベースでのOracle Streamsコンポーネントの表示」に示されているコンポーネントのOracle Streamsのトポロジでのパスを示しています。

Source Source                    Dest Dest
Path Component Component            Component Component
ID        ID Name                        ID Name            Position
----- --------- -------------------- --------- --------------- --------
1        16 CAPTURE_HNS                 12 "STRMADMIN"."SO        1
URCE_HNS"
1        12 "STRMADMIN"."SOURCE_        13 "STRMADMIN"."SO        2
HNS"                           URCE_HNS"=>"STR
MADMIN"."DESTIN
ATION_SPOKE1"@H
UB.EXAMPLE.COM
1        13 "STRMADMIN"."SOURCE_         6 "STRMADMIN"."SO        3
HNS"=>"STRMADMIN"."D           URCE_HNS"@SPOKE
ESTINATION_SPOKE1"@H           1.EXAMPLE.COM=>
UB.EXAMPLE.COM                 "STRMADMIN"."DES
TINATION_SPOKE1"
1         6 "STRMADMIN"."SOURCE_         1 "STRMADMIN"."DE        4
HNS"@SPOKE1.EXAMPLE.           STINATION_SPOKE
COM=>"STRMADMIN"."DE           1"
STINATION_SPOKE1"
1         1 "STRMADMIN"."DESTINA         8 APPLY_SPOKE1           5
TION_SPOKE1"
2        22 CAPTURE_HNS                 18 "STRMADMIN"."SO        1
URCE_HNS"
2        18 "STRMADMIN"."SOURCE_        19 "STRMADMIN"."SO        2
HNS"                           URCE_HNS"=>"STR
MADMIN"."DESTIN
ATION_SPOKE2"@H
UB.EXAMPLE.COM
2        19 "STRMADMIN"."SOURCE_         7 "STRMADMIN"."SO        3
HNS"=>"STRMADMIN"."D           URCE_HNS"@SPOKE
ESTINATION_SPOKE2"@H           2.EXAMPLE.COM=>
UB.EXAMPLE.COM                 "STRMADMIN"."DES
TINATION_SPOKE2"
2         7 "STRMADMIN"."SOURCE_         2 "STRMADMIN"."DE        4
HNS"@SPOKE2.EXAMPLE.           STINATION_SPOKE
COM=>"STRMADMIN"."DE           2"
STINATION_SPOKE2"
2         2 "STRMADMIN"."DESTINA         9 APPLY_SPOKE2           5
TION_SPOKE2"
3        10 CAPTURE_HNS                  3 "STRMADMIN"."SO        1
URCE_HNS"
3         3 "STRMADMIN"."SOURCE_         4 "STRMADMIN"."SO        2
HNS"                           URCE_HNS"=>"STR
MADMIN"."DESTIN
ATION_SPOKE1"@S
POKE1.EXAMPLE.CO
M
3         4 "STRMADMIN"."SOURCE_        14 "STRMADMIN"."SO        3
HNS"=>"STRMADMIN"."D           URCE_HNS"@HUB.N
ESTINATION_SPOKE1"@S           ET=>"STRMADMIN"
POKE1.EXAMPLE.COM              ."DESTINATION_S
POKE1"
3        14 "STRMADMIN"."SOURCE_        11 "STRMADMIN"."DE        4
HNS"@HUB.EXAMPLE.COM           STINATION_SPOKE
=>"STRMADMIN"."DESTI           1"
NATION_SPOKE1"
3        11 "STRMADMIN"."DESTINA        15 APPLY_SPOKE1           5
TION_SPOKE1"
4        10 CAPTURE_HNS                  3 "STRMADMIN"."SO        1
URCE_HNS"
4         3 "STRMADMIN"."SOURCE_         5 "STRMADMIN"."SO        2
HNS"                           URCE_HNS"=>"STR
MADMIN"."DESTIN
ATION_SPOKE2"@S
POKE2.EXAMPLE.C
OM
4         5 "STRMADMIN"."SOURCE_        20 "STRMADMIN"."SO        3
HNS"=>"STRMADMIN"."D           URCE_HNS"@HUB.N
ESTINATION_SPOKE2"@S           ET=>"STRMADMIN"
POKE2.EXAMPLE.COM              ."DESTINATION_S
POKE2"
4        20 "STRMADMIN"."SOURCE_        17 "STRMADMIN"."DE        4
HNS"@HUB.EXAMPLE.COM           STINATION_SPOKE
=>"STRMADMIN"."DESTI           2"
NATION_SPOKE2"
4        17 "STRMADMIN"."DESTINA        21 APPLY_SPOKE2           5
TION_SPOKE2"

関連項目:

- 「Oracle Streamsのトポロジのストリーム・パスについて」

- 「Oracle Streams環境でのストリーム・パスの統計の表示」

Oracle Streamsコンポーネントのパフォーマンス統計の表示

Oracle Streamsパフォーマンス・アドバイザは、DBMS_STREAMS_ADVISOR_ADMパッケージおよびOracle Streamsのトポロジ・ビューで構成されます。Oracle Streamsのトポロジ・ビューを使用すると、使用する環境のOracle Streamsコンポーネントのパフォーマンス統計を表示および分析できます。

Oracle Streamsコンポーネントのパフォーマンス統計を表示するには、まず最初にDBMS_STREAMS_ADVISOR_ADMパッケージを使用して、Oracle Streams環境に関する情報を収集する必要があります。「Oracle Streamsのトポロジおよびパフォーマンスに関する情報の収集」を参照してください。

次の各項では、Oracle Streamsコンポーネントのパフォーマンス統計を表示する方法について説明します。

- Oracle Streamsのトポロジのボトルネック・コンポーネントのチェック

- コンポーネント・レベル統計の表示

- セッション・レベル統計の表示

- Oracle Streams環境でのストリーム・パスの統計の表示

注意:
Oracle Streamsコンポーネントのパフォーマンスは、その環境で使用されるコンピュータ機器やネットワーク速度などの複数の要因によって変わります。

Oracle Streamsのトポロジのボトルネック・コンポーネントのチェック

ボトルネック・コンポーネントとは、最もビジーか、またはアイドル時間がほとんどないコンポーネントのことです。Oracle Streams環境のボトルネック・コンポーネントについて、次の情報を表示できます。

- そのコンポーネントを含むパスのパスID。

- 各Oracle StreamsコンポーネントのコンポーネントID。Oracle Streamsのトポロジは、各コンポーネントにID番号を割り当て、この番号を使用してそのコンポーネントに関する情報と、そのコンポーネントを流れるストリーム・パスに関する情報を追跡します。

- Oracle Streamsコンポーネントの名前。問合せ出力でのコンポーネントの命名方法の詳細は、「各データベースでのOracle Streamsコンポーネントの表示」を参照してください。

- Oracle Streamsコンポーネントのタイプ。次のタイプがあります。

- CAPTURE: 取得プロセスを示します。

- QUEUE: キューを示します。

- PROPAGATION SENDER: 伝播送信者を示します。

- PROPAGATION RECEIVER: 伝播受信者を示します。

- APPLY: 適用プロセスを示します。

- コンポーネントを含むデータベース

次の問合せを実行すると、Oracle Streams環境のボトルネック・コンポーネントがチェックされます。

COLUMN PATH_ID HEADING 'Path ID' FORMAT 999
COLUMN COMPONENT_ID HEADING 'Component ID' FORMAT 999
COLUMN COMPONENT_NAME HEADING 'Name' FORMAT A20
COLUMN COMPONENT_TYPE HEADING 'Type' FORMAT A20
COLUMN COMPONENT_DB HEADING 'Database' FORMAT A15

SELECT PATH_ID,
COMPONENT_ID,
COMPONENT_NAME,
COMPONENT_TYPE,
COMPONENT_DB
FROM DBA_STREAMS_TP_PATH_BOTTLENECK
WHERE BOTTLENECK_IDENTIFIED='YES' AND
ADVISOR_RUN_ID=2
ORDER BY PATH_ID, COMPONENT_ID;

この例では、WHERE句でADVISOR_RUN_IDに2を使用しています。アドバイザ実行IDには、問い合せるアドバイザ実行を指定します。ADVISOR_RUN_IDの確認方法の詳細は、「Oracle Streamsのトポロジおよびパフォーマンスに関する情報の収集」を参照してください。

次の出力は、「各データベースでのOracle Streamsコンポーネントの表示」に示されているコンポーネントに関するボトルネック・コンポーネントを示しています。

Path ID Component ID Name                 Type                 Database
------- ------------ -------------------- -------------------- ---------------
1            6 "STRMADMIN"."SOURCE_ PROPAGATION RECEIVER HUB.EXAMPLE.COM
HNS"@SPOKE1.EXAMPLE.
COM=>"STRMADMIN"."DE
STINATION_SPOKE1"
3           10 CAPTURE_HNS          CAPTURE              HUB.EXAMPLE.COM
4           10 CAPTURE_HNS          CAPTURE              HUB.EXAMPLE.COM

この問合せで結果が返されない場合は、使用している環境において、Oracle Streamsパフォーマンス・アドバイザがボトルネック・コンポーネントを特定しなかったということです。ただし、この問合せで1つ以上のボトルネック・コンポーネントが返された場合は、これらのコンポーネントのステータスをチェックしてください。これらが無効になっている場合は、それらを有効にできます。コンポーネントを有効化したら、パフォーマンスが向上するようにその環境を修正できるかどうかを調べます。

Oracle Streamsパフォーマンス・アドバイザでは、あるコンポーネントがボトルネック・コンポーネントかどうかを判断できないことがあります。このようなコンポーネントを表示するには、DBA_STREAMS_TP_PATH_BOTTLENECKビューを問い合せるときにBOTTLENECK_IDENTIFIEDをNOに設定します。ADVISOR_RUN_REASON列の出力には、Oracle Streamsパフォーマンス・アドバイザが、あるコンポーネントがボトルネック・コンポーネントかどうかを判断できない理由が示されます。次の理由がADVISOR_RUN_REASON列の出力に示されます。

- PRE-11.1 DATABASE EXISTS: そのコンポーネントが、Oracle Database 11g リリース1よりも前のデータベースを含むストリーム・パスにあることを示しています。このようなコンポーネントに対してはボトルネック分析は実行されません。

- DIAGNOSTIC PACK REQUIRED: そのコンポーネントが、Oracle Diagnostics Packのないデータベースを含むストリーム・パスにあることを示しています。このようなコンポーネントに対してはボトルネック分析は実行されません。

- NO BOTTLENECK IDENTIFIED: ストリーム・パスでボトルネックが特定できなかったか、またはストリーム・パスに2つ以上のボトルネック・コンポーネントが存在する可能性があることを意味します。

関連項目:
第30章「Oracle Streams環境内での問題の特定」

コンポーネント・レベル統計の表示

Oracle StreamsのトポロジのOracle Streamsコンポーネントの統計を表示できます。この項の問合せでは、コンポーネントごとの次の情報が表示されます。

- コンポーネントが属するパスのID

- Oracle Streamsコンポーネントの名前。

- Oracle Streamsコンポーネントのタイプ。次のタイプがあります。

- CAPTURE: 取得プロセスを示します。

- QUEUE: キューを示します。

- PROPAGATION SENDER: 伝播送信者を示します。

- PROPAGATION RECEIVER: 伝播受信者を示します。

- APPLY: 適用プロセスを示します。

- コンポーネントについて収集された統計

- 統計の値および単位。たとえば、LATENCY統計は、値の数および単位のSECONDSを示します。TRANSACTION APPLY RATE統計は、値の数と単位のTRANSACTIONS PER SECONDを示します。

DBMS_STREAMS_ADVISOR_ADMパッケージのANALYZE_CURRENT_PERFORMANCEプロシージャは、この項の問合せによって返された統計を収集します。したがって、問合せによって返される統計は、プロシージャ実行時点の統計です。統計は自動的には更新されません。

表23-3は、この項の問合せによって返される各統計を説明しています。

表23-3 Oracle Streamsコンポーネントのコンポーネント・レベル統計

コンポーネント・タイプ

統計

単位

説明

CAPTURE

CAPTURE RATE

MESSAGES PER SECOND

取得プロセスによってスキャンされたREDOログのデータベース変更の1秒当たりの平均数。

取得プロセスは、そのルール・セットを満たすスキャン済変更を取得してエンキューします。

CAPTURE

ENQUEUE RATE

MESSAGES PER SECOND

取得プロセスによってエンキューされる1秒当たりの平均論理変更レコード(LCR)数。

CAPTURE

LATENCY

SECONDS

取得プロセスでREDOエントリが最後に使用可能になってから、取得プロセスが最後にスキャンしたREDOエントリがREDOログに記録されるまでの時間。

統計の目的は、変更がREDOログに記録されてから、そのREDOレコードが取得プロセスによってスキャンされるまでの時間を示すことです。

取得プロセスは、スキャンされた変更をエンキューする場合もしない場合もあります。取得プロセスは、変更がそのルール・セットを満たす場合にのみ変更をエンキューします。

PROPAGATION SENDER

SEND RATE

MESSAGES PER SECOND

伝播送信者によって送信された1秒当たりの平均メッセージ数。

PROPAGATION SENDER

BANDWIDTH

BYTES PER SECOND

伝播送信者によって送信された1秒当たりの平均バイト数。

PROPAGATION SENDER

LATENCY

SECONDS

メッセージがソース・データベースで作成されてから、伝播送信者によって宛先キューに送信されるまでの時間。

示される値は、伝播送信者によってソース・キューから宛先キューへ送信された単一のメッセージについてのものです。このメッセージは、ANALYZE_CURRENT_PERFORMANCEプロシージャが実行されたときに最後に伝播送信者によって送信されたのメッセージです。

伝播によって送信されたメッセージのタイプによって、メッセージの作成時間は次のいずれかになります。

- 取得LCRの場合は、データベース変更のREDOエントリが記録された時間

- 永続LCRの場合は、LCRが作成された時間

- 永続ユーザー・メッセージの場合は、メッセージがエンキューされた時間

APPLY

MESSAGE APPLY RATE

MESSAGES PER SECOND

適用プロセスによって1秒当たりに適用される平均メッセージ数。

取得LCRまたは永続LCRは、次のいずれかの方法で適用できます。

- 適用プロセスが、LCRでカプセル化された変更をデータベース・オブジェクトに対して実行します。

- 適用プロセスが、LCRを適用ハンドラに渡します。

- LCRでエラーが発生した場合、適用プロセスがそのLCRをエラー・キューへ送信します。

永続ユーザー・メッセージは、次のいずれかの方法で適用できます。

- 適用プロセスが、メッセージをメッセージ・ハンドラへ送信します。

- LCRでエラーが発生した場合、適用プロセスがメッセージをエラー・キューへ送信します。

APPLY

TRANSACTION APPLY RATE

TRANSACTIONS PER SECOND

適用プロセスによって適用された1秒当たりの平均トランザクション数。トランザクションには通常、複数のメッセージが含まれます。

取得LCRまたは永続LCRを含むトランザクションは、次のいずれかの方法で適用できます。

- 適用プロセスが、トランザクション内のすべての変更を実行して、トランザクションをコミットします。

- 適用プロセスは、トランザクション内のすべてのLCRを適用ハンドラに渡します。

- LCRでエラーが発生した場合、適用プロセスがトランザクションとその中のすべてのLCRをエラー・キューへ送信します。

永続ユーザー・メッセージを含むトランザクションは、次のいずれかの方法で適用できます。

- 適用プロセスは、トランザクション内のすべてのメッセージをメッセージ・ハンドラに渡します。

- LCRでエラーが発生した場合、適用プロセスがトランザクション内のすべてのメッセージをエラー・キューへ送信します。

APPLY

LATENCY

SECONDS

適用プロセスの場合、メッセージがソース・データベースで作成されてから、適用プロセスによって宛先データベースで適用されるまでの時間。

示される値は、適用プロセスによって適用された単一メッセージについてのものです。このメッセージは、ANALYZE_CURRENT_PERFORMANCEプロシージャが実行されたときに最後に適用されたメッセージです。

適用されたメッセージのタイプによって、メッセージの作成時間は次のいずれかになります。

- 取得LCRの場合は、データベース変更のREDOエントリが記録された時間

- 永続LCRの場合は、LCRが作成された時間

- ユーザー・メッセージの場合は、メッセージがエンキューされた時間

QUEUE

ENQUEUE RATE

MESSAGES PER SECOND

キューにエンキューされた1秒当たりの平均メッセージ数。

QUEUE

SPILL RATE

MESSAGES PER SECOND

バッファ・キューからキュー表にオーバーフローした1秒当たりの平均メッセージ数。

QUEUE

CURRENT QUEUE SIZE

NUMBER OF MESSAGES

ANALYZE_CURRENT_PERFORMANCEプロシージャ実行時のキュー内のメッセージ数。

CAPTURE、PROPAGATION SENDER、PROPAGATION RECEIVERおよびAPPLY

EVENT(最上位待機イベント)

PERCENT

Oracle Streamsコンポーネントが、待機イベントが原因で待機に費やす時間のパーセンテージ。

Oracle Streamsパフォーマンス・アドバイザは、コンポーネントごとに上位3つのイベントに関する情報のみを収集します。

たとえば、取得プロセスは、REDOログ・ファイルが使用可能になるまで待機する場合があります。

次に、これらのパフォーマンス統計についての一般的な考慮事項を示します。

- レート、帯域幅およびイベント統計については、同じユーザー・セッションのANALYZE_CURRENT_PERFORMANCEプロシージャによって使用される2つのスナップショット間の時間差として期間が計算されます。スナップショットの詳細は、「Oracle Streamsパフォーマンス・アドバイザによって収集される情報について」を参照してください。ユーザー・セッションが終了すると、レート、帯域幅およびイベント統計は削除されます。

- 待機時間統計が-1秒の場合は、ANALYZE_CURRENT_PERFORMANCEプロシージャは実行時にコンポーネントの統計を収集できなかったということです。ほとんどの場合、この結果は、プロシージャの実行時にコンポーネントが無効であったことを示します。たとえば、適用プロセスのLATENCY統計が-1の場合は、コンポーネントが、ANALYZE_CURRENT_PERFORMANCEプロシージャの実行時に無効だったと考えられます。

Oracle Streamsのトポロジのコンポーネントのパフォーマンス統計を表示するには、次の問合せを実行します。

COLUMN PATH_ID HEADING 'Path|ID' FORMAT 999
COLUMN COMPONENT_ID HEADING 'Component|ID' FORMAT 999
COLUMN COMPONENT_NAME HEADING 'Name' FORMAT A20
COLUMN COMPONENT_TYPE HEADING 'Type' FORMAT A12
COLUMN STATISTIC_NAME HEADING 'Statistic' FORMAT A15
COLUMN STATISTIC_VALUE HEADING 'Value' FORMAT 99999999999.99
COLUMN STATISTIC_UNIT HEADING 'Unit' FORMAT A15

SELECT DISTINCT
cp.PATH_ID,
cs.COMPONENT_ID,
cs.COMPONENT_NAME,
cs.COMPONENT_TYPE,
cs.STATISTIC_NAME,
cs.STATISTIC_VALUE,
cs.STATISTIC_UNIT
FROM DBA_STREAMS_TP_COMPONENT_STAT  cs,
(SELECT PATH_ID, SOURCE_COMPONENT_ID AS COMPONENT_ID
FROM DBA_STREAMS_TP_COMPONENT_LINK
UNION
SELECT PATH_ID, DESTINATION_COMPONENT_ID AS COMPONENT_ID
FROM DBA_STREAMS_TP_COMPONENT_LINK) cp
WHERE cs.ADVISOR_RUN_ID = 2 AND
cs.SESSION_ID IS NULL AND
cs.SESSION_SERIAL# IS NULL AND
cs.COMPONENT_ID = cp.COMPONENT_ID
ORDER BY PATH_ID, COMPONENT_ID, COMPONENT_NAME, COMPONENT_TYPE, STATISTIC_NAME;

この例では、WHERE句でADVISOR_RUN_IDに2を使用しています。アドバイザ実行IDには、問い合せるアドバイザ実行を指定します。ADVISOR_RUN_IDの確認方法の詳細は、「Oracle Streamsのトポロジおよびパフォーマンスに関する情報の収集」を参照してください。

次の出力は、「各データベースでのOracle Streamsコンポーネントの表示」に示されているコンポーネントについてのパフォーマンス統計の一部を示しています。具体的には、ストリーム・パス 1およびストリーム・パス 3のコンポーネントのパフォーマンス統計を示しています。

Path Component
ID         ID Name                 Type         Statistic                 Value Unit
---- ---------- -------------------- ------------ --------------- --------------- ---------------
1          1 "STRMADMIN"."DESTINA QUEUE        CURRENT QUEUE S             .00 NUMBER OF MESSA
TION_SPOKE1"                      IZE                             GES
1          1 "STRMADMIN"."DESTINA QUEUE        ENQUEUE RATE            2573.21 MESSAGES PER SE
TION_SPOKE1"                                                      COND
1          1 "STRMADMIN"."DESTINA QUEUE        SPILL RATE                  .00 MESSAGES PER SE
TION_SPOKE1"                                                      COND
1          6 "STRMADMIN"."SOURCE_ PROPAGATION  EVENT: CPU + Wa           32.55 PERCENT
HNS"@SPOKE1.EXAMPLE. RECEIVER     it for CPU
COM=>"STRMADMIN"."DE
STINATION_SPOKE1"
1          6 "STRMADMIN"."SOURCE_ PROPAGATION  EVENT: SQL*Net            23.62 PERCENT
HNS"@SPOKE1.EXAMPLE. RECEIVER     more data from
COM=>"STRMADMIN"."DE              client
STINATION_SPOKE1"
1          6 "STRMADMIN"."SOURCE_ PROPAGATION  EVENT: latch: r            2.10 PERCENT
HNS"@SPOKE1.EXAMPLE. RECEIVER     ow cache object
COM=>"STRMADMIN"."DE              s
STINATION_SPOKE1"
1          8 APPLY_SPOKE1         APPLY        EVENT: CPU + Wa           23.10 PERCENT
it for CPU
1          8 APPLY_SPOKE1         APPLY        EVENT: latch: r            1.31 PERCENT
ow cache object
s
1          8 APPLY_SPOKE1         APPLY        EVENT: latch: s            1.57 PERCENT
hared pool
1          8 APPLY_SPOKE1         APPLY        LATENCY                    2.13 SECONDS
1          8 APPLY_SPOKE1         APPLY        MESSAGE APPLY R        10004.00 MESSAGES PER SE
ATE                             COND
1          8 APPLY_SPOKE1         APPLY        TRANSACTION APP          100.00 TRANSACTIONS PE
LY RATE                         R SECOND
1         12 "STRMADMIN"."SOURCE_ QUEUE        CURRENT QUEUE S             .00 NUMBER OF MESSA
HNS"                              IZE                             GES
1         12 "STRMADMIN"."SOURCE_ QUEUE        ENQUEUE RATE            9932.00 MESSAGES PER SE
HNS"                                                              COND

1         12 "STRMADMIN"."SOURCE_ QUEUE        SPILL RATE                  .00 MESSAGES PER SE
HNS"                                                              COND
1         13 "STRMADMIN"."SOURCE_ PROPAGATION  BANDWIDTH              32992.96 BYTES PER SECON
HNS"=>"STRMADMIN"."D SENDER                                       D
ESTINATION_SPOKE1"@H
UB.EXAMPLE.COM
1         13 "STRMADMIN"."SOURCE_ PROPAGATION  EVENT: CPU + Wa           35.96 PERCENT
HNS"=>"STRMADMIN"."D SENDER       it for CPU
ESTINATION_SPOKE1"@H
UB.EXAMPLE.COM
1         13 "STRMADMIN"."SOURCE_ PROPAGATION  EVENT: SQL*Net              .26 PERCENT
HNS"=>"STRMADMIN"."D SENDER       message to dbli
ESTINATION_SPOKE1"@H              nk
UB.EXAMPLE.COM
1         13 "STRMADMIN"."SOURCE_ PROPAGATION  EVENT: latch: r             .26 PERCENT
HNS"=>"STRMADMIN"."D SENDER       ow cache object
ESTINATION_SPOKE1"@H              s
UB.EXAMPLE.COM
1         13 "STRMADMIN"."SOURCE_ PROPAGATION  LATENCY                    4.00 SECONDS
HNS"=>"STRMADMIN"."D SENDER
ESTINATION_SPOKE1"@H
UB.EXAMPLE.COM
1         13 "STRMADMIN"."SOURCE_ PROPAGATION  SEND RATE               2568.00 MESSAGES PER SE
HNS"=>"STRMADMIN"."D SENDER                                       COND
ESTINATION_SPOKE1"@H
UB.EXAMPLE.COM
1         16 CAPTURE_HNS          CAPTURE      CAPTURE RATE           10464.00 MESSAGES PER SE
COND
1         16 CAPTURE_HNS          CAPTURE      ENQUEUE RATE           10002.00 MESSAGES PER SE
COND
1         16 CAPTURE_HNS          CAPTURE      EVENT: CPU + Wa           11.02 PERCENT
it for CPU
1         16 CAPTURE_HNS          CAPTURE      EVENT: CPU + Wa           35.96 PERCENT
it for CPU
1         16 CAPTURE_HNS          CAPTURE      EVENT: SQL*Net             5.51 PERCENT
message from db
link
1         16 CAPTURE_HNS          CAPTURE      LATENCY                    2.65 SECONDS
.
.
.

注意:
この出力は、説明のみを目的としています。実際のパフォーマンス特性は、個々の構成および条件によって異なります。

この出力は、「各データベースでのOracle Streamsコンポーネントの表示」および「Oracle Streamsのトポロジでの各ストリーム・パスの表示」の問合せに対する出力とともに分析できます。

関連項目:

- 「Oracle Streamsのトポロジについて」

- ANALYZE_CURRENT_PERFORMANCEプロシージャの実行による統計の収集方法の詳細は、「Oracle Streamsのトポロジおよびパフォーマンスに関する情報の収集」を参照

- 適用ハンドラの詳細は、「適用プロセスのメッセージ処理オプション」を参照

- 「エラー・キュー」

セッション・レベル統計の表示

Oracle Streamsコンポーネントのセッション・レベル統計を表示できます。この項の問合せでは、それぞれのセッション・レベル統計についての次の情報が表示されます。

- Oracle Streamsコンポーネントの名前。

- Oracle Streamsコンポーネントのタイプ。次のタイプがあります。

- CAPTURE: 取得プロセスを示します。

- PROPAGATION SENDER: 伝播送信者を示します。

- PROPAGATION RECEIVER: 伝播受信者を示します。

- APPLY: 適用プロセスを示します。

- サブコンポーネントのタイプ。取得プロセスおよび適用プロセスにのみサブコンポーネントがあります。
取得プロセスには、次のサブコンポーネント・タイプがあります。

- LOGMINER READER: 取得プロセスのビルダー・サーバーを示します。

- LOGMINER PREPARER取得プロセスのプリペアラ・サーバーを示します。

- LOGMINER BUILDER取得プロセスのリーダー・サーバーを示します。

- CAPTURE SESSION: 取得プロセス・セッションを示します。

適用プロセスには、次のサブコンポーネント・タイプがあります。

- PROPAGATION SENDER+RECEIVER: 取得と適用の複合による最適化でLCRを取得プロセスから適用プロセスに直接送信します。

- APPLY READER: リーダー・サーバーを示します。

- APPLY COORDINATOR: コーディネータ・プロセスを示します。

- APPLY SERVER: リーダー・サーバーを示します。

- コンポーネントについて収集された統計

- 統計の値および単位。セッション・レベル統計は、単位のPERCENTを示します。この値は、IDLE、FLOW CONTROLのための一時停止、EVENTの待機のいずれかに費やされた時間のパーセンテージです。

DBMS_STREAMS_ADVISOR_ADMパッケージのANALYZE_CURRENT_PERFORMANCEプロシージャは、この項の問合せによって返された統計を収集します。したがって、問合せによって返される統計は、プロシージャ実行時点の統計です。統計は自動的には更新されません。

表23-4は、この項の問合せによって返される各統計を説明しています。

表23-4 Oracle Streamsコンポーネントのセッション・レベル統計

統計

単位

説明

IDLE

PERCENT

セッションがアイドル状態で費やした時間のパーセンテージ。アイドル状態のセッションでは、何の処理も実行しません。

FLOW CONTROL

PERCENT

セッションがフロー制御のために一時停止した時間のパーセンテージ。フロー制御の詳細は、「取得プロセスの状態」を参照してください。

EVENT(最上位待機イベント)

PERCENT

セッションが、待機イベントが原因で待機に費やす時間のパーセンテージ。

Oracle Streamsパフォーマンス・アドバイザは、セッションごとに上位3つのイベントに関する情報のみを収集します。

たとえば、適用サーバーは、依存するトランザクションが適用されるまで待機してから、そのトランザクションを適用する場合があります。

フロー制御およびイベント統計については、同じユーザー・セッションのANALYZE_CURRENT_PERFORMANCEプロシージャによって使用される2つのスナップショット間の時間差として期間が計算されます。スナップショットの詳細は、「Oracle Streamsパフォーマンス・アドバイザによって収集される情報について」を参照してください。ユーザー・セッションが終了すると、フロー制御およびイベント統計は消去されます。

Oracle Streamsのトポロジのコンポーネントのセッション・レベル・パフォーマンス統計を表示するには、次の問合せを実行します。

COLUMN PATH_ID HEADING 'Path|ID' FORMAT 999
COLUMN COMPONENT_ID HEADING 'Component|ID' FORMAT 999
COLUMN COMPONENT_NAME HEADING 'Component|Name' FORMAT A20
COLUMN COMPONENT_TYPE HEADING 'Component|Type' FORMAT A10
COLUMN SUB_COMPONENT_TYPE HEADING 'Subcomponent|Type' FORMAT A17
COLUMN STATISTIC_NAME HEADING 'Statistic' FORMAT A15
COLUMN STATISTIC_VALUE HEADING 'Value' FORMAT 999.99
COLUMN STATISTIC_UNIT HEADING 'Unit' FORMAT A7

SELECT DISTINCT
cp.PATH_ID,
cs.COMPONENT_ID,
cs.COMPONENT_NAME,
cs.COMPONENT_TYPE,
cs.SUB_COMPONENT_TYPE,
cs.STATISTIC_NAME,
cs.STATISTIC_VALUE,
cs.STATISTIC_UNIT
FROM DBA_STREAMS_TP_COMPONENT_STAT  cs,
(SELECT PATH_ID, SOURCE_COMPONENT_ID AS COMPONENT_ID
FROM DBA_STREAMS_TP_COMPONENT_LINK
UNION
SELECT PATH_ID, DESTINATION_COMPONENT_ID AS COMPONENT_ID
FROM DBA_STREAMS_TP_COMPONENT_LINK) cp
WHERE cs.ADVISOR_RUN_ID=2 AND
cs.SESSION_ID IS NOT NULL AND
cs.SESSION_SERIAL# IS NOT NULL AND
cs.COMPONENT_ID = cp.COMPONENT_ID
ORDER BY PATH_ID, COMPONENT_ID, COMPONENT_NAME, COMPONENT_TYPE, STATISTIC_NAME;

この例では、WHERE句でADVISOR_RUN_IDに2を使用しています。アドバイザ実行IDには、問い合せるアドバイザ実行を指定します。ADVISOR_RUN_IDの確認方法の詳細は、「Oracle Streamsのトポロジおよびパフォーマンスに関する情報の収集」を参照してください。

次の出力は、「各データベースでのOracle Streamsコンポーネントの表示」に示されているコンポーネントについてのセッション・レベル・パフォーマンス統計の一部を示しています。具体的には、ストリーム・パス1およびストリーム・パス3のコンポーネントのセッション・レベル・パフォーマンス統計を示しています。

Path Component Component            Component  Subcomponent
ID        ID Name                 Type       Type              Statistic         Value Unit
---- --------- -------------------- ---------- ----------------- --------------- ------- -------
1         6 "STRMADMIN"."SOURCE_ PROPAGATIO                   EVENT: CPU + Wa   32.55 PERCENT
HNS"@SPOKE1.EXAMPLE. N RECEIVER                   it for CPU
COM=>"STRMADMIN"."DE
STINATIO N_SPOKE1"
1         6 "STRMADMIN"."SOURCE_ PROPAGATIO                   EVENT: SQL*Net    23.62 PERCENT
HNS"@SPOKE1.EXAMPLE. N RECEIVER                   more data from
COM=>"STRMADMIN"."DE                              client
STINATION_SPOKE1"
1         6 "STRMADMIN"."SOURCE_ PROPAGATIO                   EVENT: latch: r    2.10 PERCENT
HNS"@SPOKE1.EXAMPLE. N RECEIVER                   ow cache object
COM=>"STRMADMIN"."DE                              s
STINATION_SPOKE1"
1         6 "STRMADMIN"."SOURCE_ PROPAGATIO                   FLOW CONTROL        .89 PERCENT
HNS"@SPOKE1.EXAMPLE. N RECEIVER
COM=>"STRMADMIN"."DE
STINATION_SPOKE1"
1         6 "STRMADMIN"."SOURCE_ PROPAGATIO                   IDLE              36.61 PERCENT
HNS"@SPOKE1.EXAMPLE. N RECEIVER
COM=>"STRMADMIN"."DE
STINATION_SPOKE1"
1         8 APPLY_SPOKE1         APPLY      APPLY READER      EVENT: CPU + Wa     .26 PERCENT
it for CPU
1         8 APPLY_SPOKE1         APPLY      APPLY SERVER      EVENT: CPU + Wa   23.10 PERCENT
it for CPU
1         8 APPLY_SPOKE1         APPLY      APPLY SERVER      EVENT: latch: r    1.31 PERCENT
ow cache object
s
1         8 APPLY_SPOKE1         APPLY      APPLY READER      EVENT: latch: s     .26 PERCENT
hared pool
1         8 APPLY_SPOKE1         APPLY      APPLY SERVER      EVENT: latch: s    1.57 PERCENT
hared pool
1         8 APPLY_SPOKE1         APPLY      APPLY COORDINATOR FLOW CONTROL        .00 PERCENT
1         8 APPLY_SPOKE1         APPLY      APPLY READER      FLOW CONTROL      10.76 PERCENT
1         8 APPLY_SPOKE1         APPLY      APPLY SERVER      FLOW CONTROL        .00 PERCENT
1         8 APPLY_SPOKE1         APPLY      APPLY COORDINATOR IDLE               6.21 PERCENT
1         8 APPLY_SPOKE1         APPLY      APPLY READER      IDLE               9.24 PERCENT
1         8 APPLY_SPOKE1         APPLY      APPLY SERVER      IDLE               8.53 PERCENT
1        13 "STRMADMIN"."SOURCE_ PROPAGATIO                   EVENT: CPU + Wa   21.65 PERCENT
HNS"=>"STRMADMIN"."D N SENDER                     it for CPU
ESTINATION_SPOKE1"@H
UB.EXAMPLE.COM
1        13 "STRMADMIN"."SOURCE_ PROPAGATIO                   EVENT: SQL*Net      .26 PERCENT
HNS"=>"STRMADMIN"."D N SENDER                     message to dbli
ESTINATION_SPOKE1"@H                              nk
UB.EXAMPLE.COM
1        13 "STRMADMIN"."SOURCE_ PROPAGATIO                   EVENT: latch: r     .26 PERCENT
HNS"=>"STRMADMIN"."D N SENDER                     ow cache object
ESTINATION_SPOKE1"@H                              s
UB.EXAMPLE.COM
1        13 "STRMADMIN"."SOURCE_ PROPAGATIO                   EVENT: latch: s     .26 PERCENT
HNS"=>"STRMADMIN"."D N SENDER                     hared pool
ESTINATION_SPOKE1"@H
UB.EXAMPLE.COM
1        13 "STRMADMIN"."SOURCE_ PROPAGATIO                   FLOW CONTROL       7.37 PERCENT
HNS"=>"STRMADMIN"."D N SENDER
ESTINATION_SPOKE1"@H
UB.EXAMPLE.COM
1        13 "STRMADMIN"."SOURCE_ PROPAGATIO                   IDLE              67.41 PERCENT
HNS"=>"STRMADMIN"."D N SENDER
ESTINATION_SPOKE1"@H
UB.EXAMPLE.COM
1        16 CAPTURE_HNS          CAPTURE    LOGMINER READER   EVENT: ARCH wai     .26 PERCENT
t on c/f tx acq
uire 2
1        16 CAPTURE_HNS          CAPTURE    CAPTURE SESSION   EVENT: CPU + Wa   35.96 PERCENT
it for CPU
1        16 CAPTURE_HNS          CAPTURE    LOGMINER BUILDER  EVENT: CPU + Wa     .26 PERCENT
it for CPU
1        16 CAPTURE_HNS          CAPTURE    LOGMINER PREPARER EVENT: CPU + Wa   11.02 PERCENT
it for CPU
1        16 CAPTURE_HNS          CAPTURE    LOGMINER READER   EVENT: CPU + Wa     .26 PERCENT
it for CPU
1        16 CAPTURE_HNS          CAPTURE    CAPTURE SESSION   EVENT: SQL*Net     5.51 PERCENT
message from db
link
1        16 CAPTURE_HNS          CAPTURE    CAPTURE SESSION   EVENT: SQL*Net      .26 PERCENT
message to dbli
nk
1        16 CAPTURE_HNS          CAPTURE    CAPTURE SESSION   EVENT: latch: r     .26 PERCENT
ow cache object
s
1        16 CAPTURE_HNS          CAPTURE    LOGMINER BUILDER  EVENT: latch: r    1.84 PERCENT
ow cache object
s
1        16 CAPTURE_HNS          CAPTURE    LOGMINER PREPARER EVENT: latch: r     .79 PERCENT
ow cache object
s
1        16 CAPTURE_HNS          CAPTURE    CAPTURE SESSION   EVENT: latch: s     .26 PERCENT
hared pool
1        16 CAPTURE_HNS          CAPTURE    LOGMINER READER   EVENT: latch: s     .79 PERCENT
hared pool
1        16 CAPTURE_HNS          CAPTURE    CAPTURE SESSION   FLOW CONTROL      16.27 PERCENT
1        16 CAPTURE_HNS          CAPTURE    LOGMINER BUILDER  FLOW CONTROL        .00 PERCENT
1        16 CAPTURE_HNS          CAPTURE    LOGMINER PREPARER FLOW CONTROL        .00 PERCENT
1        16 CAPTURE_HNS          CAPTURE    LOGMINER READER   FLOW CONTROL        .00 PERCENT
1        16 CAPTURE_HNS          CAPTURE    CAPTURE SESSION   IDLE              41.47 PERCENT
1        16 CAPTURE_HNS          CAPTURE    LOGMINER BUILDER  IDLE              97.90 PERCENT
1        16 CAPTURE_HNS          CAPTURE    LOGMINER PREPARER IDLE              88.19 PERCENT
1        16 CAPTURE_HNS          CAPTURE    LOGMINER READER   IDLE              98.69 PERCENT
.
.
.
3         4 "STRMADMIN"."SOURCE_ PROPAGATIO                   FLOW CONTROL       6.50 PERCENT
HNS"=>"STRMADMIN"."D N SENDER
ESTINATION_SPOKE1"@S
POKE1.EXAMPLE.COM
3         4 "STRMADMIN"."SOURCE_ PROPAGATIO                   IDLE              70.50 PERCENT
HNS"=>"STRMADMIN"."D N SENDER
ESTINATION_SPOKE1"@S
POKE1.EXAMPLE.COM
3        10 CAPTURE_HNS          CAPTURE    CAPTURE SESSION   EVENT: ARCH wai   52.23 PERCENT
t for archivelo
g lock
3        10 CAPTURE_HNS          CAPTURE    CAPTURE SESSION   EVENT: CPU + Wa    7.35 PERCENT
it for CPU
3        10 CAPTURE_HNS          CAPTURE    CAPTURE SESSION   EVENT: control      .52 PERCENT
file sequential
read
3        10 CAPTURE_HNS          CAPTURE    CAPTURE SESSION   FLOW CONTROL       4.24 PERCENT
3        10 CAPTURE_HNS          CAPTURE    CAPTURE SESSION   IDLE               2.23 PERCENT
3        14 "STRMADMIN"."SOURCE_ PROPAGATIO                   EVENT: CPU + Wa    6.92 PERCENT
HNS"@HUB.EXAMPLE.COM N RECEIVER                   it for CPU
=>"STRMADMIN"."DESTI
NATION_SPOKE1"
3        14 "STRMADMIN"."SOURCE_ PROPAGATIO                   EVENT: latch: r    2.23 PERCENT
HNS"@HUB.EXAMPLE.COM N RECEIVER                   ow cache object
=>"STRMADMIN"."DESTI                              s
NATION_SPOKE1"
3        14 "STRMADMIN"."SOURCE_ PROPAGATIO                   EVENT: library     3.79 PERCENT
HNS"@HUB.EXAMPLE.COM N RECEIVER                   cache: mutex X
=>"STRMADMIN"."DESTI
NATION_SPOKE1"
3        14 "STRMADMIN"."SOURCE_ PROPAGATIO                   FLOW CONTROL        .67 PERCENT
HNS"@HUB.EXAMPLE.COM N RECEIVER
=>"STRMADMIN"."DESTI
NATION_SPOKE1"
3        14 "STRMADMIN"."SOURCE_ PROPAGATIO                   IDLE              85.04 PERCENT
HNS"@HUB.EXAMPLE.COM N RECEIVER
=>"STRMADMIN"."DESTI
NATION_SPOKE1"
3        15 APPLY_SPOKE1         APPLY      APPLY COORDINATOR EVENT: latch: r    4.20 PERCENT
ow cache object
s
3        15 APPLY_SPOKE1         APPLY      APPLY COORDINATOR EVENT: latch: s     .52 PERCENT
hared pool
3        15 APPLY_SPOKE1         APPLY      APPLY READER      EVENT: latch: s     .26 PERCENT
hared pool
3        15 APPLY_SPOKE1         APPLY      APPLY COORDINATOR FLOW CONTROL        .00 PERCENT
3        15 APPLY_SPOKE1         APPLY      APPLY READER      FLOW CONTROL       1.56 PERCENT
3        15 APPLY_SPOKE1         APPLY      APPLY SERVER      FLOW CONTROL        .00 PERCENT
3        15 APPLY_SPOKE1         APPLY      APPLY COORDINATOR IDLE              87.28 PERCENT
3        15 APPLY_SPOKE1         APPLY      APPLY READER      IDLE              96.88 PERCENT
3        15 APPLY_SPOKE1         APPLY      APPLY SERVER      IDLE              91.29 PERCENT

注意:

- この出力は、説明のみを目的としています。実際のパフォーマンス特性は、個々の構成および条件によって異なります。

- 各セッションのセッションIDとシリアル番号は、DBA_STREAMS_TP_COMPONENT_STATビューの問合せにSESSION_IDおよびSESSION_SERIAL#の各列を、追加することによって表示できます。

関連項目:

- 取得プロセスのサブコンポーネントの詳細は、「取得プロセスのサブコンポーネント」を参照

- 適用プロセスのサブコンポーネントの詳細は、「適用プロセスのサブコンポーネント」を参照

- 第12章「取得と適用の複合による最適化」

Oracle Streams環境でのストリーム・パスの統計の表示

この項の問合せは、Oracle Streamsのトポロジ内の各ストリーム・パスに関する次の情報を表示します。

- パスにOracle Streamsの最適化モードを使用するかどうかを示します。パスのOPTIMIZATION_MODE統計が0より大きい場合、パスは取得と適用の複合による最適化を使用します。OPTIMIZATION_MODE統計が0の場合、パスは取得と適用の複合による最適化を使用しません。

- MESSAGE RATE値は、パスの開始からパスの終了までに送信される1秒当たりの平均メッセージ数を示します。

- TRANSACTION RATE値は、パスの開始からパスの終了までに送信される1秒当たりの平均トランザクション数を示します。

これらの統計の期間は、同じユーザー・セッションのANALYZE_CURRENT_PERFORMANCEプロシージャによって使用される2つのスナップショット間の時間差として期間が計算されます。スナップショットの詳細は、「Oracle Streamsパフォーマンス・アドバイザによって収集される情報について」を参照してください。ユーザー・セッションが終了すると、これらの統計は消去されます。

これらの情報を表示するには、次の問合せを実行します。

COLUMN PATH_ID HEADING 'Path ID' FORMAT 999
COLUMN STATISTIC_NAME HEADING 'Statistic' FORMAT A25
COLUMN STATISTIC_VALUE HEADING 'Value' FORMAT 99999999.99
COLUMN STATISTIC_UNIT HEADING 'Unit' FORMAT A25

SELECT PATH_ID,
STATISTIC_NAME,
STATISTIC_VALUE,
STATISTIC_UNIT
FROM DBA_STREAMS_TP_PATH_STAT
WHERE ADVISOR_RUN_ID=2
ORDER BY PATH_ID, STATISTIC_NAME;

この例では、WHERE句でADVISOR_RUN_IDに2を使用しています。アドバイザ実行IDには、問い合せるアドバイザ実行を指定します。ADVISOR_RUN_IDの確認方法の詳細は、「Oracle Streamsのトポロジおよびパフォーマンスに関する情報の収集」を参照してください。

次の出力は、「Oracle Streamsのトポロジでの各ストリーム・パスの表示」に示されているストリーム・パスのパス統計を示しています。

Path ID Statistic                        Value Unit
------- ------------------------- ------------ -------------------------
1 OPTIMIZATION_MODE                 1.00 NUMBER
1 MESSAGE RATE                  10004.00 MESSAGES PER SECOND
1 TRANSACTION RATE                100.00 TRANSACTIONS PER SECOND
2 OPTIMIZATION_MODE                 1.00 NUMBER
2 MESSAGE RATE                  10028.25 MESSAGES PER SECOND
2 TRANSACTION RATE                100.37 TRANSACTIONS PER SECOND
3 OPTIMIZATION_MODE                 1.00 NUMBER
3 MESSAGE RATE                   9623.20 MESSAGES PER SECOND
3 TRANSACTION RATE                 97.10 TRANSACTIONS PER SECOND
4 OPTIMIZATION_MODE                 1.00 NUMBER
4 MESSAGE RATE                  10180.05 MESSAGES PER SECOND
4 TRANSACTION RATE                 102.68 TRANSACTIONS PER SECOND

注意:
この出力は、説明のみを目的としています。実際のパフォーマンス特性は、個々の構成および条件によって異なります。

関連項目:

- 「Oracle Streamsのトポロジのストリーム・パスについて」

- 第12章「取得と適用の複合による最適化」

UTL_SPADVパッケージの使用

UTL_SPADVパッケージには、分散データベース環境のOracle Streamsコンポーネントの統計を収集して分析するサブプログラムがあります。このパッケージは、Oracle Streamsパフォーマンス・アドバイザを使用して統計を収集します。

COLLECT_STATSおよびSTART_MONITORINGプロシージャでは、Oracle Streamsパフォーマンス・アドバイザを使用して、分散データベース環境のOracle Streamsコンポーネントおよびサブコンポーネントに関する統計を収集します。SHOW_STATSプロシージャでは、統計を含む出力を生成します。出力は、スプレッドシートに簡単にインポートして分析できるように書式設定されます。

COLLECT_STATSプロシージャを使用すると、プロシージャを呼び出すたびに統計を収集できます。comp_stat_tableおよびpath_stat_tableパラメータでは、パフォーマンスの統計を格納する表を指定します。デフォルトでは、これらの表はそれぞれSTREAMS$_ADVISOR_COMP_STATおよびSTREAMS$_ADVISOR_PATH_STATです。

また、START_MONITORINGプロシージャを使用して、指定した間隔で継続的にOracle Streamsパフォーマンスを監視する監視ジョブを作成することもできます。監視ジョブでは、COLLECT_STATSプロシージャを使用して統計を収集します。START_MONITORINGプロシージャではSTREAMS$_PA_MONITORING表への移入を行い、この表のSHOW_STATS_TABLE列ではパフォーマンスの統計を含む表を指定します。監視ジョブを変更するにはALTER_MONITORINGプロシージャを使用し、監視ジョブを停止するにはSTOP_MONITORINGプロシージャを使用します。

これらのプロシージャは、Oracle Streamsパフォーマンス・アドバイザと同じ統計を収集します。これらの統計の詳細は、表23-3「Oracle Streamsコンポーネントのコンポーネント・レベル統計」および表23-4「Oracle Streamsコンポーネントのセッション・レベル統計」を参照してください。

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

- UTL_SPADVパッケージを使用したOracle Streamsの統計の収集

- Oracle Streamsの監視ジョブが現在実行されているかどうかの確認

- Oracle Streamsの監視ジョブの変更

- Oracle Streamsの監視ジョブの停止

- UTL_SPADVパッケージを使用したOracle Streamsの統計の表示

関連項目:
UTL_SPADVパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

UTL_SPADVパッケージを使用したOracle Streamsの統計の収集

UTL_SPADVパッケージを使用して統計を収集するには、次の手順を実行します。

1. 情報の収集に使用するデータベースを指定します。このデータベースの管理ユーザーは、次の要件を満たしている必要があります。

- このユーザーには、監視対象のOracle Streamsコンポーネントを含む各データベースへのデータベース・リンクに対するアクセス権が必要です。

- ユーザーは、DBMS_STREAMS_AUTH.GRANT_ADMIN_PRIVILEGEプロシージャを使用して権限を付与されている必要があります。各データベース・リンクは、DBMS_STREAMS_AUTH.GRANT_ADMIN_PRIVILEGEプロシージャを使用して権限を付与されたリモート・データベースのユーザーに接続する必要があります。
Oracle Streamsコンポーネントを使用して各データベースでOracle Streams管理者を構成すると、Oracle Streams管理者に必要な権限が割り当てられます。Oracle Streams管理者を作成する方法の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

ご使用の環境に、これらの要件を満たすデータベースがない場合は、データベースを1つ選択し、必要なデータベース・リンクを構成して、必要な権限をユーザーに付与してから処理を進めてください。

2. SQL*Plusでは、手順1で指定したデータベースに、手順1に示される要件を満たすユーザーとして接続します。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

3. ORACLE_HOMEのrdbms/adminディレクトリでutlspadv.sqlスクリプトを実行してUTL_SPADVパッケージをロードします。次に例を示します。

@utlspadv.sql

4. 現在のOracle Streamsパフォーマンスの統計を1回収集するか、Oracle Streamsパフォーマンスを継続的に監視するジョブを作成します。

- 現在のOracle Streamsパフォーマンスの統計を1回収集するには、COLLECT_STATSプロシージャを実行します。

exec UTL_SPADV.COLLECT_STATS

この例では、COLLECT_STATSプロシージャのパラメータにデフォルト値を使用します。したがって、この例では、60秒間隔でパフォーマンス・アドバイザが10回実行されます。これらの値は、COLLECT_STATSプロシージャのintervalおよびnum_runsパラメータのデフォルト値にそれぞれ対応します。

- Oracle Streamsパフォーマンスを継続的に監視するジョブを作成するには、次のプロシージャを実行します。

exec UTL_SPADV.START_MONITORING

この例では、監視ジョブを作成します。その監視ジョブでは、設定した間隔で継続的にパフォーマンスの統計を収集します。この例では、START_MONITORINGプロシージャのパラメータにデフォルト値を使用します。したがって、この例では、60秒ごとにパフォーマンス・アドバイザが実行されます。この値は、START_MONITORINGプロシージャのintervalパラメータのデフォルト値に対応します。START_MONITORINGプロシージャで間隔を指定すると、COLLECT_STATSプロシージャのintervalパラメータにその間隔が使用されます。

これらのプロシージャには、パフォーマンスの統計を収集する方法を調整するために使用できるいくつかのパラメータが用意されています。詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

統計を表示するには、SHOW_STATSプロシージャを実行します。「UTL_SPADVパッケージを使用したOracle Streamsの統計の表示」を参照してください。

関連項目:
UTL_SPADVパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

Oracle Streamsの監視ジョブが現在実行されているかどうかの確認

UTL_SPADVパッケージを使用して監視ジョブが実行されているかどうかを確認するには、次の手順を実行します。

1. 監視ジョブを発行したユーザーとしてデータベースに接続します。

2. IS_MONITORINGファンクションを実行します。たとえば、STREAM$_MONITORING_JOBという完全な監視ジョブ名で現在のユーザーによって発行された監視ジョブが実行されているかどうかを調べるには、次のように入力します。

SET SERVEROUTPUT ON
DECLARE
is_mon   BOOLEAN;
BEGIN
is_mon := UTL_SPADV.IS_MONITORING(
job_name    => 'STREAMS$_MONITORING_JOB',
client_name => NULL);
IF is_mon=TRUE THEN
DBMS_OUTPUT.PUT_LINE('The monitoring job is running.');
ELSE
DBMS_OUTPUT.PUT_LINE('No monitoring job was found.');
END IF;
END;
/

指定した完全な監視ジョブ名の監視ジョブが現在実行されている場合は、出力に次のテキストが表示されます。

The monitoring job is running.

指定した完全な監視ジョブ名の監視ジョブが現在実行されていない場合は、出力に次のテキストが表示されます。

No monitoring job was found.

注意:
監視ジョブを発行すると、クライアント名とジョブ名が連結されて完全な監視ジョブ名が形成されます。Oracle Enterprise Managerによって発行される監視ジョブのクライアント名は常にEMになります。

Oracle Streamsの監視ジョブの変更

UTL_SPADVパッケージを使用して監視ジョブを変更するには、次の手順を実行します。

1. 監視ジョブをまだ作成していない場合は、「UTL_SPADVパッケージを使用したOracle Streamsの統計の収集」で説明した手順を実行して作成します。手順4では、必ずSTART_MONITORINGプロシージャを実行してください。

2. 監視ジョブを発行したユーザーとしてデータベースに接続します。監視ジョブを変更できるのは、その監視ジョブを発行したユーザーのみであり、各ユーザーが1回に発行できる監視ジョブは1つのみです。

3. ALTER_MONITORINGプロシージャを実行します。次の例では、監視ジョブの間隔を120秒に設定しています。

BEGIN
UTL_SPADV.ALTER_MONITORING(
interval => 120);
END;
/

このプロシージャを実行すると、監視ジョブは120秒ごとに統計を収集します。

Oracle Streamsの監視ジョブの停止

UTL_SPADVパッケージを使用して監視ジョブを停止するには、次の手順を実行します。

1. 監視ジョブを発行したユーザーとしてデータベースに接続します。監視ジョブを停止できるのは、その監視ジョブを発行したユーザーのみであり、各ユーザーが1回に発行できる監視ジョブは1つのみです。

2. STOP_MONITORINGプロシージャを実行します。

exec UTL_SPADV.STOP_MONITORING

STOP_MONITORINGプロシージャには、監視ジョブによって収集された統計を結果の表から消去するために使用できるpurgeパラメータが用意されています。デフォルトでは、purgeパラメータはFALSEに設定されており、結果は維持されます。結果を消去するには、purgeパラメータをTRUEに設定します。

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

UTL_SPADVパッケージを使用したOracle Streamsの統計の表示

SHOW_STATSプロシージャでは、パフォーマンス・アドバイザによって収集および格納された統計を表示します。path_stat_tableパラメータを使用して、統計を含む表を指定します。

COLLECT_STATSプロシージャを使用して統計を収集するとき、COLLECT_STATSプロシージャのpath_stat_tableパラメータでこの表を指定します。デフォルトでは、表名はSTREAMS$_ADVISOR_PATH_STATです。

START_MONITORINGプロシージャを使用して統計を収集するとき、この表の名前を調べるには、STREAMS$_PA_MONITORINGビューのSHOW_STATS_TABLE列を問い合せます。監視ジョブのデフォルトの表はSTREAMS$_PA_SHOW_PATH_STATです。

UTL_SPADVパッケージによって収集され、STREAMS$_ADVISOR_PATH_STAT表に格納された統計を表示するには、次の手順を実行します。

1. 「UTL_SPADVパッケージを使用したOracle Streamsの統計の収集」で説明した手順を実行して、統計を収集します。

2. 統計を収集したユーザーとしてデータベースに接続します。

3. 監視ジョブを使用している場合は、STREAMS$_PA_MONITORINGビューのSHOW_STATS_TABLE列を問い合せて、統計が格納されているこの表の名前を調べます。

SELECT SHOW_STATS_TABLE FROM STREAMS$_PA_MONITORING;

4. SHOW_STATSプロシージャを実行します。
たとえば、監視ジョブおよびデフォルトの格納表を使用している場合は、次のプロシージャを実行します。

SET SERVEROUTPUT ON SIZE 50000
BEGIN
UTL_SPADV.SHOW_STATS(
path_stat_table => 'STREAMS$_PA_SHOW_PATH_STAT');
END;
/

出力には、次の凡例が含まれています。

LEGEND
<statistics>= <capture> [ <queue> <psender> <preceiver> <queue> ] <apply>
<bottleneck>
<capture>   = '|<C>' <name> <msgs captured/sec> <msgs enqueued/sec> <latency>
'LMR' <idl%> <flwctrl%> <topevt%> <topevt>
'LMP' (<parallelism>) <idl%> <flwctrl%> <topevt%> <topevt>
'LMB' <idl%> <flwctrl%> <topevt%> <topevt>
'CAP' <idl%> <flwctrl%> <topevt%> <topevt>
'CAP+PS' <msgs sent/sec> <bytes sent/sec> <latency> <idl%>
<flwctrl%> <topevt%> <topevt>
<apply>     = '|<A>' <name> <msgs applied/sec> <txns applied/sec> <latency>
'PS+PR' <idl%> <flwctrl%> <topevt%> <topevt>
'APR' <idl%> <flwctrl%> <topevt%> <topevt>
'APC' <idl%> <flwctrl%> <topevt%> <topevt>
'APS' (<parallelism>) <idl%> <flwctrl%> <topevt%> <topevt>
<queue>     = '|<Q>' <name> <msgs enqueued/sec> <msgs spilled/sec> <msgs in
queue>
<psender>   = '|<PS>' <name> <msgs sent/sec> <bytes sent/sec> <latency> <idl%>
<flwctrl%> <topevt%> <topevt>
<preceiver> = '|<PR>' <name> <idl%> <flwctrl%> <topevt%> <topevt>
<bottleneck>= '|<B>' <name> <sub_name> <sessionid> <serial#> <topevt%> <topevt>

次の表は、凡例で使用される略称について説明しています。

略称

説明

A

適用プロセス

APC

適用プロセスによって使用されるコーディネータ・プロセス

APR

適用プロセスによって使用されるリーダー・サーバー

APS

適用プロセスによって使用される適用サーバー

B

ボトルネック

CまたはCAP

取得プロセス

CAP+PS

取得と適用の複合による最適化での取得プロセス・セッションおよび伝播送信者

CCA

取得と適用の複合(Yはパスに使用されることを示し、Nはパスに使用されないことを示します。)

flwctrl

フロー制御

idl

アイドル

LMB

取得プロセスによって使用されるビルダー・サーバー(LogMiner builder)

LMP

取得プロセスによって使用されるプリペアラ・サーバー(LogMiner preparer)

LMR

取得プロセスによって使用されるリーダー・サーバー(LogMiner reader)

msgs

メッセージ

preceiverまたはPR

伝播受信者

psenderまたはPS

伝播送信者

PS+PR

取得と適用の複合による最適化(取得プロセスと適用プロセスが同じデータベース・インスタンスで実行されている)での伝播送信者および伝播受信者

Q

キュー

serial#

セッション・シリアル番号

sec

秒

sid

セッション識別子

sub_name

サブコンポーネント名

topevt

最上位イベント

次に、パス内の最後のコンポーネントが適用プロセスである場合の出力例を示します。

OUTPUT
PATH 1 RUN_ID 3 RUN_TIME 2009-JUL-02 05:59:38 CCA Y
|<C> DB2$CAP 10267 10040 3 LMR 95% 0% 3.3% "" LMP (1) 86.7% 0% 11.7% "" LMB 86.7% 0% 11.7% ""
CAP 71.7% 16.7% 11.7% "" |<Q> "STRMADMIN"."DB2$CAPQ" 2540.45 0 30 |<PS>
=>DB1.EXAMPLE.COM 2152.03 32992.96 4 59.2% 9.8% 0% "" |<PR> DB2.EXAMPLE.COM=> 98.5%
0% 0.6% "" |<Q> "STRMADMIN"."DB2$APPQ" 3657.03 0.01 460 |<A> APPLY$_DB2_2 10042 100 4
APR 93.3% 0% 6.7% "" APC 98.1% 0% 1.8% "" APS (4) 370% 0% 6.1% "" |<B> NO BOTTLENECK
IDENTIFIED

PATH 1 RUN_ID 4 RUN_TIME 2009-JUL-02 06:01:39 CCA Y
|<C> DB2$CAP 10464 10002 3 LMR 95% 0% 1.7% "" LMP (1) 83.3% 0% 16.7% "" LMB 85% 0% 15% ""
CAP 62.9% 0% 35.7% "" |<Q> "STRMADMIN"."DB2$CAPQ" 2677.03 0.01 45 |<PS>
=>DB1.EXAMPLE.COM 2491.08 47883.46 4 65.5% 10.7% 0% "" |<PR> DB2.EXAMPLE.COM=> 0% 83.3%
13.3% "" |<Q> "STRMADMIN"."DB2$APPQ" 2444.03 0.01 0 |<A> APPLY$_DB2_2 10004 100 3
APR 42.9% 57.1% 0% "" APC 90% 0% 10% "" APS (4) 346% 0% 10.3% "" |<B> NO BOTTLENECK
IDENTIFIED
.
.
.

注意:
この出力は、説明のみを目的としています。実際のパフォーマンス特性は、個々の構成および条件によって異なります。

出力の統計を判断するのに凡例および略称を使用します。たとえば、次の出力は、パスが1で実行IDが3のdb2$cap取得プロセスを表します。

|<C> DB2$CAP 10267 10040 3 LMR 95% 0% 3.3% "" LMP (1) 86.7% 0% 11.7% "" LMB 86.7% 0% 11.7% ""
CAP 71.7% 16.7% 11.7% ""

この出力は、次の統計を示しています。

- 取得プロセスは、平均して毎秒10267のデータベース変更を取得しました。

- 取得プロセスは、平均して毎秒10040のメッセージをエンキューしました。

- 取得プロセスの待機時間は、3秒でした。

- 取得プロセスが使用したリーダー・サーバー(LMR)のアイドル時間は、95%でした。

- 取得プロセスが使用したリーダー・サーバーがフロー制御モードだった時間は、0%でした。

- 取得プロセスが使用したリーダー・サーバーが上位待機イベントに費やした時間は、3.3%でした。

- プリペアラ・サーバー(LMP)の並列性は、1でした。

- 取得プロセスが使用したプリペアラ・サーバーのアイドル時間は、86.7%でした。

- 取得プロセスが使用したプリペアラ・サーバーがフロー制御モードだった時間は、0%でした。

- 取得プロセスが使用したプリペアラ・サーバーが上位待機イベントに費やした時間は、11.7%でした。

- 取得プロセスが使用したビルダー・サーバー(LMB)のアイドル時間は、86.7%でした。

- 取得プロセスが使用したビルダー・サーバーがフロー制御モードだった時間は、0%でした。

- 取得プロセスが使用したビルダー・サーバーが上位待機イベントに費やした時間は、11.7%でした。

- 取得プロセスのセッションのアイドル時間は、71.7%でした。

- 取得プロセスのセッションがフロー制御モードだった時間は、16.7%でした。

- 取得プロセスのセッションが最上位待機イベントに費やした時間は、11.7%でした。

関連項目:
第12章「取得と適用の複合による最適化」

24 Oracle Streams暗黙的取得の監視

取得プロセスと同期取得は両方とも暗黙的取得を実行します。

次の各項では、Oracle Streams暗黙的取得の監視について説明します。

- 取得プロセスの監視

- 同期取得の監視

- 暗黙的取得によって取得された追加属性の表示

注意:
Oracle Enterprise ManagerのOracle Streamsツールも、Oracle Streams環境を監視するための優れた手段です。詳細は、Oracle Database 2日でデータ・レプリケーションおよび統合ガイドおよびOracle Streamsツールのオンライン・ヘルプを参照してください。

関連項目:

- 第2章「Oracle Streams情報取得」

- 第15章「Oracle Streams暗黙的取得の管理」

- 第31章「暗黙的取得のトラブルシューティング」

- この章で説明するデータ・ディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照

取得プロセスの監視

この項では、Oracle Streamsの取得プロセスの監視に使用できる問合せの例を示します。

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

- 各取得プロセスのキュー、ルール・セットおよび状態の表示

- 各取得プロセスに関するセッション情報の表示

- 各取得プロセスに関する変更取得情報の表示

- 各取得プロセスの状態変更およびメッセージ作成時刻の表示

- 各取得プロセスの取得操作の実行経過時間の表示

- 各ダウンストリーム取得プロセスに関する情報の表示

- 各取得プロセスの登録済REDOログ・ファイルの表示

- 各取得プロセスで必要なREDOログ・ファイルの表示

- 各取得プロセスで使用される各REDOログ・ファイルのSCN値の表示

- 各取得プロセスで使用可能な最後のアーカイブREDOエントリの表示

- 各取得プロセスのパラメータ設定の表示

- データベース内のすべての取得プロセスの適用済SCNの判別

- 各取得プロセスのREDOログのスキャン待機時間の判別

- 各取得プロセスのメッセージのエンキュー待機時間の判別

- 各取得プロセスのルールの評価に関する情報の表示

- 取得と適用の複合を使用する取得プロセスの判別

- 分割とマージ操作に関する情報の表示

- サプリメンタル・ロギングの監視

各取得プロセスのキュー、ルール・セットおよび状態の表示

この項で説明する問合せを実行すると、データベース内の各取得プロセスに関する情報を表示できます。

- 取得プロセスの名前

- 取得プロセスで使用されるキューの名前

- 取得プロセスで使用されるポジティブ・ルール・セットの名前

- 取得プロセスで使用されるネガティブ・ルール・セットの名前

- 取得プロセスの状態(ENABLED、DISABLEDまたはABORTED)

データベース内の各取得プロセスに関する一般情報を表示するには、次の問合せを実行します。

COLUMN CAPTURE_NAME HEADING 'Capture|Process|Name' FORMAT A15
COLUMN QUEUE_NAME HEADING 'Capture|Process|Queue' FORMAT A15
COLUMN RULE_SET_NAME HEADING 'Positive|Rule Set' FORMAT A15
COLUMN NEGATIVE_RULE_SET_NAME HEADING 'Negative|Rule Set' FORMAT A15
COLUMN STATUS HEADING 'Capture|Process|Status' FORMAT A15

SELECT CAPTURE_NAME, QUEUE_NAME, RULE_SET_NAME, NEGATIVE_RULE_SET_NAME, STATUS
FROM DBA_CAPTURE;

出力は次のようになります。

Capture         Capture                                         Capture
Process         Process         Positive        Negative        Process
Name            Queue           Rule Set        Rule Set        Status
--------------- --------------- --------------- --------------- ---------------
STRM01_CAPTURE  STREAMS_QUEUE   RULESET$_25     RULESET$_36     ENABLED

取得プロセスの状態がABORTEDの場合、DBA_CAPTUREデータ・ディクショナリ・ビューのERROR_NUMBERおよびERROR_MESSAGE列を問い合せると、エラーを特定できます。

関連項目:
取得プロセスがABORTEDの場合のエラー番号およびエラー・メッセージを表示する問合せの例は、「取得プロセスが有効かどうか」を参照

各取得プロセスに関するセッション情報の表示

この項で説明する問合せを実行すると、データベース内の取得プロセスに関連付けられている各セッション情報が表示されます。

- 取得プロセスのコンポーネント

- セッション識別子

- シリアル番号

- オペレーション・システムのプロセス識別番号

- CPnnという形式の取得プロセスのプロセス名(nnは文字および数字)

データベースの各取得プロセスに関する前述の情報を表示するには、次の問合せを実行します。

COLUMN ACTION HEADING 'Capture Process Component' FORMAT A25
COLUMN SID HEADING 'Session ID' FORMAT 99999
COLUMN SERIAL# HEADING 'Session|Serial|Number' FORMAT 99999999
COLUMN PROCESS HEADING 'Operating System|Process Number' FORMAT A20
COLUMN PROCESS_NAME HEADING 'Process|Name' FORMAT A7

SELECT /*+PARAM('_module_action_old_length',0)*/ ACTION,
SID,
SERIAL#,
PROCESS,
SUBSTR(PROGRAM,INSTR(PROGRAM,'(')+1,4) PROCESS_NAME
FROM V$SESSION
WHERE MODULE ='Streams' AND
ACTION LIKE '%Capture%';

出力は次のようになります。

Session
Serial Operating System     Process
Capture Process Component Session ID    Number Process Number       Name
------------------------- ---------- --------- -------------------- -------
EMDBA$CAP - Capture               74         9 10019                CP01

関連項目:
取得プロセスの並列性の詳細は、「取得プロセスのサブコンポーネント」を参照

各取得プロセスに関する変更取得情報の表示

この項で説明する問合せを実行すると、データベース内の各取得プロセスに関する次の情報が表示されます。

- 取得プロセスの名前。

- プロセス番号CPnn(nnは文字および数字)。

- セッション識別子。

- セッションのシリアル番号。

- 取得プロセスの現在の状態
「取得プロセスの状態」を参照してください。

- 詳細なルール評価のためにLogMinerから取得プロセスに渡されたREDOエントリの合計数。取得プロセスでREDOエントリがメッセージに変換され、取得プロセスの事前フィルタ処理で変更を廃棄できない場合、メッセージの詳細なルール評価が行われます。

- 取得プロセスが最後に起動されてからエンキューされたLCRの合計数。

データベースの各取得プロセスに関する前述の情報を表示するには、次の問合せを実行します。

COLUMN CAPTURE_NAME HEADING 'Capture|Name' FORMAT A7
COLUMN PROCESS_NAME HEADING 'Capture|Process|Number' FORMAT A7
COLUMN SID HEADING 'Session|ID' FORMAT 9999
COLUMN SERIAL# HEADING 'Session|Serial|Number' FORMAT 9999
COLUMN STATE HEADING 'State' FORMAT A20
COLUMN TOTAL_MESSAGES_CAPTURED HEADING 'Redo|Entries|Evaluated|In Detail' FORMAT 9999999
COLUMN TOTAL_MESSAGES_ENQUEUED HEADING 'Total|LCRs|Enqueued' FORMAT 9999999999

SELECT c.CAPTURE_NAME,
SUBSTR(s.PROGRAM,INSTR(s.PROGRAM,'(')+1,4) PROCESS_NAME,
c.SID,
c.SERIAL#,
c.STATE,
c.TOTAL_MESSAGES_CAPTURED,
c.TOTAL_MESSAGES_ENQUEUED
FROM V$STREAMS_CAPTURE c, V$SESSION s
WHERE c.SID = s.SID AND
c.SERIAL# = s.SERIAL#;

出力は次のようになります。

Redo
Capture         Session                        Entries       Total
Capture Process Session  Serial                      Evaluated        LCRs
Name    Number       ID  Number State                In Detail    Enqueued
------- ------- ------- ------- -------------------- --------- -----------
CAPTURE CP01        954       3 CAPTURING CHANGES      3719085     3389713
_HNS

スキャンされたREDOエントリの数は、取得プロセスによって取得されたDMLおよびDDLのREDOエントリの数より多くなる場合があります。取得プロセスのルール・セットを満たすDMLおよびDDLのREDOエントリのみが取得され、取得プロセスのキューにエンキューされます。また、エンキューされたLCRの合計数には、トランザクション制御文を含むLCRも含まれます。これらの行LCRには、COMMIT、ROLLBACKなどのディレクティブが含まれます。このため、エンキューされたLCRの合計数は、取得プロセスによってエンキューされた行変更およびDDL変更の数より多くなります。

関連項目:
トランザクション制御文の詳細は、「行LCR」を参照

各取得プロセスの状態変更およびメッセージ作成時刻の表示

この項で説明する問合せを実行すると、データベース内の各取得プロセスに関する次の情報が表示されます。

- 取得プロセスの名前。

- 取得プロセスの現在の状態
「取得プロセスの状態」を参照してください。

- 取得プロセスの状態が最後に変更された日時。

- 取得プロセスで最後にLCRが作成された日時。

データベースの各取得プロセスに関する前述の情報を表示するには、次の問合せを実行します。

COLUMN CAPTURE_NAME HEADING 'Capture|Name' FORMAT A15
COLUMN STATE HEADING 'State' FORMAT A27
COLUMN STATE_CHANGED HEADING 'State|Change Time'
COLUMN CREATE_MESSAGE HEADING 'Last Message|Create Time'

SELECT CAPTURE_NAME,
STATE,
TO_CHAR(STATE_CHANGED_TIME, 'HH24:MI:SS MM/DD/YY') STATE_CHANGED,
TO_CHAR(CAPTURE_MESSAGE_CREATE_TIME, 'HH24:MI:SS MM/DD/YY') CREATE_MESSAGE
FROM V$STREAMS_CAPTURE;

出力は次のようになります。

Capture                                     State             Last Message
Name            State                       Change Time       Create Time
--------------- --------------------------- ----------------- -----------------
CAPTURE_SIMP    CAPTURING CHANGES           13:24:42 11/08/04 13:24:41 11/08/04

各取得プロセスの取得操作の実行経過時間の表示

この項で説明する問合せを実行すると、データベース内の各取得プロセスに関する次の情報が表示されます。

- 取得プロセスの名前。

- 取得の経過時間。取得プロセスが最後に起動されてから、REDOログ内の変更のスキャンにかかった時間(秒)を示します。

- ルール評価の経過時間。取得プロセスが最後に起動されてから、ルール評価にかかった時間(秒)を示します。

- エンキューの経過時間。取得プロセスが最後に起動されてから、メッセージのエンキューにかかった時間(秒)を示します。

- LCR作成の経過時間。取得プロセスが最後に起動されてから、論理変更レコード(LCR)の作成にかかった時間(秒)を示します。

- 停止の経過時間。取得プロセスが最後に起動されてから、フロー制御のために停止した時間(秒)を示します。

注意:
この問合せに関するすべての時間は秒単位で表示されます。デフォルトでは、V$STREAMS_CAPTUREビューには経過時間がセンチセカンドで表示されます。センチセカンドは、100分の1秒です。この項で説明する問合せを実行すると、各経過時間が100で割られ、秒単位で表示されます。

データベースの各取得プロセスに関する前述の情報を表示するには、次の問合せを実行します。

COLUMN CAPTURE_NAME HEADING 'Capture|Name' FORMAT A15
COLUMN ELAPSED_CAPTURE_TIME HEADING 'Elapsed|Capture|Time' FORMAT 99999999.99
COLUMN ELAPSED_RULE_TIME HEADING 'Elapsed|Rule|Evaluation|Time' FORMAT 99999999.99
COLUMN ELAPSED_ENQUEUE_TIME HEADING 'Elapsed|Enqueue|Time' FORMAT 99999999.99
COLUMN ELAPSED_LCR_TIME HEADING 'Elapsed|LCR|Creation|Time' FORMAT 99999999.99
COLUMN ELAPSED_PAUSE_TIME HEADING 'Elapsed|Pause|Time' FORMAT 99999999.99

SELECT CAPTURE_NAME,
(ELAPSED_CAPTURE_TIME/100) ELAPSED_CAPTURE_TIME,
(ELAPSED_RULE_TIME/100) ELAPSED_RULE_TIME,
(ELAPSED_ENQUEUE_TIME/100) ELAPSED_ENQUEUE_TIME,
(ELAPSED_LCR_TIME/100) ELAPSED_LCR_TIME,
(ELAPSED_PAUSE_TIME/100) ELAPSED_PAUSE_TIME
FROM V$STREAMS_CAPTURE;

出力は次のようになります。

Elapsed                   Elapsed
Elapsed         Rule      Elapsed          LCR      Elapsed
Capture              Capture   Evaluation      Enqueue     Creation        Pause
Name                    Time         Time         Time         Time         Time
--------------- ------------ ------------ ------------ ------------ ------------
STM1$CAP             1213.92          .04        33.84       185.25       600.60

各ダウンストリーム取得プロセスに関する情報の表示

ダウンストリーム取得とは、ソース・データベース以外のデータベースで実行される取得プロセスのことです。この項で説明する問合せを実行すると、データベース内の各ダウンストリーム取得プロセスに関する次の情報を表示できます。

- 取得プロセスの名前

- 取得プロセスで取得された変更のソース・データベース

- 取得プロセスで使用されるキューの名前

- 取得プロセスの状態(ENABLED、DISABLEDまたはABORTED)

- ダウンストリーム取得プロセスで、ソース・データベースへのデータベース・リンクを使用して管理アクションを実行するかどうか

データベース内の各ダウンストリーム取得プロセスに関する前述の情報を表示するには、次の問合せを実行します。

COLUMN CAPTURE_NAME HEADING 'Capture|Process|Name' FORMAT A15
COLUMN SOURCE_DATABASE HEADING 'Source|Database' FORMAT A15
COLUMN QUEUE_NAME HEADING 'Capture|Process|Queue' FORMAT A15
COLUMN STATUS HEADING 'Capture|Process|Status' FORMAT A15
COLUMN USE_DATABASE_LINK HEADING 'Uses|Database|Link?' FORMAT A8

SELECT CAPTURE_NAME,
SOURCE_DATABASE,
QUEUE_NAME,
STATUS,
USE_DATABASE_LINK
FROM DBA_CAPTURE
WHERE CAPTURE_TYPE = 'DOWNSTREAM';

出力は次のようになります。

Capture                              Capture         Capture         Uses
Process         Source               Process         Process         Database
Name            Database             Queue           Status          Link?
--------------- -------------------- --------------- --------------- --------
STRM03_CAPTURE  DBS1.EXAMPLE.COM     STRM03_QUEUE    ENABLED         YES

この場合、取得プロセスのソース・データベースはdbs1.example.comですが、取得プロセスを実行しているローカル・データベースはdbs1.example.comではありません。また、この問合せで戻される取得プロセスでは、ソース・データベースへのデータベース・リンクを使用して管理アクションを実行します。データベース・リンクの名前は、ソース・データベースのグローバル名(この場合はdbs1.example.com)と同じです。

取得プロセスの状態がABORTEDの場合、DBA_CAPTUREデータ・ディクショナリ・ビューのERROR_NUMBERおよびERROR_MESSAGE列を問い合せると、エラーを特定できます。

注意:
Oracle Streamsダウンストリーム取得プロセスのソース・データベースでは、V$ARCHIVE_DEST_STATUSビューを問い合せてダウンストリーム・データベースに関する情報を表示できます。このビューの次の列がダウンストリーム・データベースに関連しています。

- REDOログ情報がダウンストリーム取得データベースに送信されている場合は、TYPE列にDOWNSTREAMが表示されます。

- DESTINATION列には、ダウンストリーム取得データベースの名前が表示されます。

関連項目:

- 「ローカル取得およびダウンストリーム取得」

- 取得プロセスの作成の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- 取得プロセスがABORTEDの場合のエラー番号およびエラー・メッセージを表示する問合せの例は、「取得プロセスが有効かどうか」を参照

各取得プロセスの登録済REDOログ・ファイルの表示

この項で説明する問合せを実行すると、データベース内の各取得プロセスの登録済アーカイブREDOログ・ファイルに関する情報を表示できます。この問合せによって、ローカル取得プロセスおよびダウンストリーム取得プロセスのこれらのファイルに関する情報が表示されます。

この問合せでは、各登録済アーカイブREDOログ・ファイルに関する次の情報が表示されます。

- ファイルを使用する取得プロセスの名前

- ファイルのソース・データベース

- ファイルの順序番号

- ローカル・サイトでのファイルの名前および場所

- ファイルにデータ・ディクショナリ・ビルドの最初の部分が含まれているかどうか

- ファイルにデータ・ディクショナリ・ビルドの最後の部分が含まれているかどうか

データベースの各登録済アーカイブ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 'Archived Redo Log|File Name' FORMAT A20
COLUMN DICTIONARY_BEGIN HEADING 'Dictionary|Build|Begin' FORMAT A10
COLUMN DICTIONARY_END HEADING 'Dictionary|Build|End' FORMAT A10

SELECT r.CONSUMER_NAME,
r.SOURCE_DATABASE,
r.SEQUENCE#,
r.NAME,
r.DICTIONARY_BEGIN,
r.DICTIONARY_END
FROM DBA_REGISTERED_ARCHIVED_LOG r, DBA_CAPTURE c
WHERE r.CONSUMER_NAME = c.CAPTURE_NAME;

出力は次のようになります。

Capture                                                  Dictionary Dictionary
Process         Source     Sequence Archived Redo Log    Build      Build
Name            Database     Number File Name            Begin      End
--------------- ---------- -------- -------------------- ---------- ----------
STRM02_CAPTURE  DBS2.EXAMP       15 /orc/dbs/log/arch2_1 NO         NO
LE.COM              _15_478347508.arc
STRM02_CAPTURE  DBS2.EXAMP       16 /orc/dbs/log/arch2_1 NO         NO
LE.COM              _16_478347508.arc
STRM03_CAPTURE  DBS1.EXAMP       45 /remote_logs/arch1_1 YES        YES
LE.COM              _45_478347335.arc
STRM03_CAPTURE  DBS1.EXAMP       46 /remote_logs/arch1_1 NO         NO
LE.COM              _46_478347335.arc
STRM03_CAPTURE  DBS1.EXAMP       47 /remote_logs/arch1_1 NO         NO
LE.COM              _47_478347335.arc

strm02_captureがローカル取得プロセス、strm03_captureがダウンストリーム取得プロセスの場合にこの問合せをdbs2.example.comデータベースで実行したとします。strm03_captureダウンストリーム取得プロセスのソース・データベースはdbs1.example.comです。この問合せによって、strm02_captureの登録済アーカイブREDOログ・ファイルが2つ、strm03_captureの登録済アーカイブREDOログ・ファイルが3つ表示されます。この問合せでは、ローカル・ファイル・システムにおけるこれらの各ファイルの名前および場所が表示されます。

関連項目:

- データ・ディクショナリ・ビルドの詳細は、「取得プロセスのLogMinerデータ・ディクショナリ」を参照

- 「ローカル取得およびダウンストリーム取得」

- 取得プロセスの構成の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- 「ARCHIVELOGモードおよび取得プロセス」

各取得プロセスで必要なREDOログ・ファイルの表示

取得プロセスには、必須チェックポイントSCNが含まれているREDOログ・ファイルおよび後続のすべてのREDOログ・ファイルが必要です。DBA_CAPTUREデータ・ディクショナリ・ビューのREQUIRED_CHECKPOINT_SCN列を問い合せると、取得プロセスの必須チェックポイントSCNを判別できます。必須チェックポイントSCNが含まれているREDOログ・ファイルより前のREDOログ・ファイルは、取得プロセスでは不要になります。これらのREDOログ・ファイルは、他の目的でも不要になるとオフラインで格納できます。後で取得プロセスの開始SCNを小さい値にリセットする場合、これらのREDOログ・ファイルが必要となることがあります。

この問合せでは、必要な各アーカイブREDOログ・ファイルに関する次の情報が表示されます。

- ファイルを使用する取得プロセスの名前

- ファイルのソース・データベース

- ファイルの順序番号

- ローカル・サイトでの必要なREDOログ・ファイルの名前および場所

データベース内の必要な各アーカイブ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;

出力は次のようになります。

Capture                             Required
Process         Source     Sequence Archived Redo Log
Name            Database     Number File Name
--------------- ---------- -------- ----------------------------------------
STRM02_CAPTURE  DBS2.EXAMP       16 /orc/dbs/log/arch2_1_16_478347508.arc
LE.COM
STRM03_CAPTURE  DBS1.EXAMP       47 /remote_logs/arch1_1_47_478347335.arc
LE.COM

関連項目:
「必須チェックポイントSCN」

各取得プロセスで使用される各REDOログ・ファイルのSCN値の表示

この項で説明する問合せを実行すると、データベース内の各取得プロセスの登録済アーカイブREDOログ・ファイルのSCN値に関する情報を表示できます。この問合せによって、ローカル取得プロセスおよびダウンストリーム取得プロセスのこれらのファイルのSCN値に関する情報が表示されます。また、この問合せでは、ローカル・データベースの取得プロセスで不要になったREDOログ・ファイルが識別されます。

この問合せでは、各登録済アーカイブREDOログ・ファイルに関する次の情報が表示されます。

- ファイルを使用する取得プロセスの取得プロセス名

- ローカル・サイトでのファイルの名前および場所

- REDOログ・ファイルに含まれている情報の最小SCN値

- 連続するREDOログ・ファイルの次のREDOログ・ファイルの最小SCN値

- REDOログ・ファイルが消去可能かどうか

データベースの各登録済アーカイブREDOログ・ファイルに関する前述の情報を表示するには、次の問合せを実行します。

COLUMN CONSUMER_NAME HEADING 'Capture|Process|Name' FORMAT A15
COLUMN NAME HEADING 'Archived Redo Log|File Name' FORMAT A25
COLUMN FIRST_SCN HEADING 'First SCN' FORMAT 99999999999
COLUMN NEXT_SCN HEADING 'Next SCN' FORMAT 99999999999
COLUMN PURGEABLE HEADING 'Purgeable?' FORMAT A10

SELECT r.CONSUMER_NAME,
r.NAME,
r.FIRST_SCN,
r.NEXT_SCN,
r.PURGEABLE
FROM DBA_REGISTERED_ARCHIVED_LOG r, DBA_CAPTURE c
WHERE r.CONSUMER_NAME = c.CAPTURE_NAME;

出力は次のようになります。

Capture
Process         Archived Redo Log
Name            File Name                    First SCN     Next SCN Purgeable?
--------------- ------------------------- ------------ ------------ ----------
CAPTURE_SIMP    /private1/ARCHIVE_LOGS/1_       509686       549100 YES
3_502628294.dbf

CAPTURE_SIMP    /private1/ARCHIVE_LOGS/1_       549100       587296 YES
4_502628294.dbf

CAPTURE_SIMP    /private1/ARCHIVE_LOGS/1_       587296       623107 NO
5_502628294.dbf

すべての取得プロセスに対してPurgeable?がYESに設定されているREDOログ・ファイルは、ローカル・データベースの取得プロセスでは不要です。これらのREDOログ・ファイルは、ローカル・データベースの既存の取得プロセスに影響を与えずに削除できます。1つ以上の取得プロセスに対してPurgeable?がNOに設定されているREDOログ・ファイルは、保持しておく必要があります。

関連項目:
「ARCHIVELOGモードおよび取得プロセス」

各取得プロセスで使用可能な最後のアーカイブREDOエントリの表示

ローカル取得プロセスの場合、使用可能な最後のアーカイブREDOエントリは、オンラインREDOログからアーカイブ・ログ・ファイルに最後にフラッシュされたエントリです。ダウンストリーム取得プロセスの場合、使用可能な最終アーカイブREDOエントリは、取得プロセスで使用されるLogMinerセッションに最後に追加されたアーカイブ・ログ・ファイル内の最新のシステム変更番号(SCN)を持つREDOエントリです。

この項で説明する問合せを実行すると、各取得プロセスで使用可能な最後のREDOエントリに関する次の情報が表示されます。

- 取得プロセスの名前。

- 取得プロセスで使用されるLogMinerセッションの識別番号

- 取得プロセスで使用可能な最大SCN
ローカル取得の場合、このSCNは最後にログ・ファイルにフラッシュされたREDOのSCNです。ダウンストリーム取得の場合、このSCNはアーカイブ・ログによって最後にLogMinerに追加されたSCNです。

- 取得プロセスで使用可能な最大SCNのタイムスタンプ
ローカル取得の場合、このタイムスタンプはSCNがログ・ファイルに書き込まれた時刻です。ダウンストリーム取得の場合、このタイムスタンプはLogMinerで使用可能な最新のアーカイブ・ログ(最新のSCNが含まれる)の時刻です。

この問合せで表示される情報は、有効になっている取得プロセスに対してのみ有効です。

次の問合せを実行すると、各取得プロセスに関する前述の情報が表示されます。

COLUMN CAPTURE_NAME HEADING 'Capture|Name' FORMAT A20
COLUMN LOGMINER_ID HEADING 'LogMiner ID' FORMAT 9999
COLUMN AVAILABLE_MESSAGE_NUMBER HEADING 'Highest|Available SCN' FORMAT 9999999999
COLUMN AVAILABLE_MESSAGE_CREATE_TIME HEADING 'Time of|Highest|Available SCN'

SELECT CAPTURE_NAME,
LOGMINER_ID,
AVAILABLE_MESSAGE_NUMBER,
TO_CHAR(AVAILABLE_MESSAGE_CREATE_TIME, 'HH24:MI:SS MM/DD/YY')
AVAILABLE_MESSAGE_CREATE_TIME
FROM V$STREAMS_CAPTURE;

出力は次のようになります。

Time of
Capture                                Highest Highest
Name                 LogMiner ID Available SCN Available SCN
-------------------- ----------- ------------- -----------------
DB1$CAP                        1       1506751 09:46:11 06/29/09

各取得プロセスのパラメータ設定の表示

次の問合せを実行すると、データベース内の取得プロセスごとの各取得プロセス・パラメータの現行の設定が表示されます。

COLUMN CAPTURE_NAME HEADING 'Capture|Process|Name' FORMAT A25
COLUMN PARAMETER HEADING 'Parameter' FORMAT A30
COLUMN VALUE HEADING 'Value' FORMAT A10
COLUMN SET_BY_USER HEADING 'Set by|User?' FORMAT A10

SELECT CAPTURE_NAME,
PARAMETER,
VALUE,
SET_BY_USER
FROM DBA_CAPTURE_PARAMETERS;

出力は次のようになります。

Capture
Process                                                             Set by
Name                      Parameter                      Value      User?
------------------------- ------------------------------ ---------- ----------
DA$CAP                    CAPTURE_IDKEY_OBJECTS          N          NO
DA$CAP                    CAPTURE_SEQUENCE_NEXTVAL       N          NO
DA$CAP                    DISABLE_ON_LIMIT               N          NO
DA$CAP                    DOWNSTREAM_REAL_TIME_MINE      Y          NO
DA$CAP                    EXCLUDETRANS                              NO
DA$CAP                    EXCLUDEUSER                               NO
DA$CAP                    EXCLUDEUSERID                             NO
DA$CAP                    GETAPPLOPS                     Y          NO
DA$CAP                    GETREPLICATES                  N          NO
DA$CAP                    IGNORE_TRANSACTION                        NO
DA$CAP                    IGNORE_UNSUPPORTED_TABLE       *          NO
DA$CAP                    MAXIMUM_SCN                    INFINITE   NO
DA$CAP                    MAX_SGA_SIZE                   INFINITE   NO
DA$CAP                    MERGE_THRESHOLD                60         NO
DA$CAP                    MESSAGE_LIMIT                  INFINITE   NO
DA$CAP                    MESSAGE_TRACKING_FREQUENCY     2000000    NO
DA$CAP                    PARALLELISM                    1          NO
DA$CAP                    SKIP_AUTOFILTERED_TABLE_DDL    Y          NO
DA$CAP                    SPLIT_THRESHOLD                1800       NO
DA$CAP                    STARTUP_SECONDS                0          NO
DA$CAP                    TIME_LIMIT                     INFINITE   NO
DA$CAP                    TRACE_LEVEL                    0          NO
DA$CAP                    WRITE_ALERT_LOG                Y          NO
DA$CAP                    XOUT_CLIENT_EXISTS             N          NO

注意:
パラメータのSet by user列がNOの場合、そのパラメータはデフォルト値に設定されます。パラメータのSet by user列がYESの場合、パラメータはユーザーによって設定され、デフォルト値に設定されることもされないこともあります。

関連項目:

- 「取得プロセスのサブコンポーネント」

- 「取得プロセス・パラメータの設定」

データベース内のすべての取得プロセスの適用済SCNの判別

取得プロセスの適用済システム変更番号(SCN)は、関連する適用プロセスによってデキューされた最新のメッセージのSCNです。この適用済SCNより小さいすべての変更は、取得プロセスによって取得された変更を適用するすべての適用プロセスによってデキューされています。

データベース内のすべての取得プロセスの適用済SCNを表示するには、次の問合せを実行します。

COLUMN CAPTURE_NAME HEADING 'Capture Process Name' FORMAT A30
COLUMN APPLIED_SCN HEADING 'Applied SCN' FORMAT 99999999999

SELECT CAPTURE_NAME, APPLIED_SCN FROM DBA_CAPTURE;

出力は次のようになります。

Capture Process Name           Applied SCN
------------------------------ -----------
CAPTURE_EMP                         177154

各取得プロセスのREDOログのスキャン待機時間の判別

この項で説明する問合せを実行すると、各取得プロセスに関する次の情報を検索できます。

- REDOログのスキャン待機時間。取得プロセスによってスキャンされた最新のREDOログ・エントリの作成時刻から現在の時刻までの秒数を示します。取得プロセスを起動した直後は、この数値が比較的大きくなる場合があります。

- 状態が最後に記録されてからの秒数。取得プロセスで最後に状態が記録されてからの秒数を示します。

- 現行の取得プロセス時刻。取得プロセスで最後に状態が記録された時刻を示します。

- メッセージ作成時刻。データ操作言語(DML)またはデータ定義言語(DDL)の変更によって、最新の取得LCRに関するREDOデータがソース・データベースで生成された時刻です。

この問合せで表示される情報は、有効になっている取得プロセスに対してのみ有効です。

次の問合せを実行すると、各取得プロセスのREDOスキャンの待機時間が判別されます。

COLUMN CAPTURE_NAME HEADING 'Capture|Process|Name' FORMAT A10
COLUMN LATENCY_SECONDS HEADING 'Latency|in|Seconds' FORMAT 999999
COLUMN LAST_STATUS HEADING 'Seconds Since|Last Status' FORMAT 999999
COLUMN CAPTURE_TIME HEADING 'Current|Process|Time'
COLUMN CREATE_TIME HEADING 'Message|Creation Time' FORMAT 999999

SELECT CAPTURE_NAME,
((SYSDATE - CAPTURE_MESSAGE_CREATE_TIME)*86400) LATENCY_SECONDS,
((SYSDATE - CAPTURE_TIME)*86400) LAST_STATUS,
TO_CHAR(CAPTURE_TIME, 'HH24:MI:SS MM/DD/YY') CAPTURE_TIME,
TO_CHAR(CAPTURE_MESSAGE_CREATE_TIME, 'HH24:MI:SS MM/DD/YY') CREATE_TIME
FROM V$STREAMS_CAPTURE;

出力は次のようになります。

Capture    Latency               Current
Process         in Seconds Since Process           Message
Name       Seconds   Last Status Time              Creation Time
---------- ------- ------------- ----------------- -----------------
DA$CAP           1             1 12:33:39 07/14/10 12:33:39 07/14/10

この問合せで戻される"Latency in Seconds"は、現在の時刻(SYSDATE)と"Message Creation Time"の差です。この問合せで戻される"Seconds Since Last Status"は、現在の時刻(SYSDATE)と"Current Process Time"の差です。

各取得プロセスのメッセージのエンキュー待機時間の判別

この項で説明する問合せを実行すると、各取得プロセスに関する次の情報を検索できます。

- メッセージのエンキュー待機時間。エントリがソース・データベースでREDOログに記録されてから取得プロセスでメッセージがエンキューされるまでの秒数を示します

- メッセージ作成時刻。データ操作言語(DML)またはデータ定義言語(DDL)の変更によって、最新のエンキュー済メッセージに関するREDOデータがソース・データベースで生成された時刻を示します

- エンキュー時刻。取得プロセスによってメッセージがキューにエンキューされた時刻を示します。

- エンキューされたメッセージのメッセージ番号。

この問合せで表示される情報は、有効になっている取得プロセスに対してのみ有効です。

次の問合せを実行すると、各取得プロセスのメッセージの取得待機時間が判別されます。

COLUMN CAPTURE_NAME HEADING 'Capture|Process|Name' FORMAT A10
COLUMN LATENCY_SECONDS HEADING 'Latency|in|Seconds' FORMAT 999999
COLUMN CREATE_TIME HEADING 'Message Creation|Time' FORMAT A20
COLUMN ENQUEUE_TIME HEADING 'Enqueue Time' FORMAT A20
COLUMN ENQUEUE_MESSAGE_NUMBER HEADING 'Message|Number' FORMAT 9999999999

SELECT CAPTURE_NAME,
(ENQUEUE_TIME-ENQUEUE_MESSAGE_CREATE_TIME)*86400 LATENCY_SECONDS,
TO_CHAR(ENQUEUE_MESSAGE_CREATE_TIME, 'HH24:MI:SS MM/DD/YY') CREATE_TIME,
TO_CHAR(ENQUEUE_TIME, 'HH24:MI:SS MM/DD/YY') ENQUEUE_TIME,
ENQUEUE_MESSAGE_NUMBER
FROM V$STREAMS_CAPTURE;

出力は次のようになります。

Capture    Latency
Process         in Message Creation                            Message
Name       Seconds Time                 Enqueue Time          Number
---------- ------- -------------------- -------------------- -------
CAPTURE          0 10:56:51 03/01/02    10:56:51 03/01/02     253962

この問合せで戻される"Latency in Seconds"は、"Enqueue Time"と"Message Creation Time"の差です。

各取得プロセスのルールの評価に関する情報の表示

この項で説明する問合せを実行すると、各取得プロセスのルールの評価に関する情報を表示できます。

- 取得プロセスの名前。

- 取得プロセスが最後に起動されてから事前フィルタ処理中に廃棄された変更数。これらの変更が取得プロセスのルール・セットを完全には満たしていないことが、事前フィルタ処理中に取得プロセスによって判定されています。

- 取得プロセスが最後に起動されてから事前フィルタ処理中に保持された変更数。これらの変更が取得プロセスのルール・セットを完全に満たしていることが、事前フィルタ処理中に取得プロセスによって判定されています。このような変更はLCRに変換され、取得プロセス・キューにエンキューされます。

- 取得プロセスが最後に起動されてからの事前フィルタ処理評価の合計数。

- 取得プロセスが最後に起動されてから事前フィルタ処理後に判定されていない変更数。これらの変更は、取得プロセスのルール・セットを満たしている場合も満たしていない場合もあります。一部の変更は、完全評価を必要とせずに、事前フィルタ処理後に実行するフィルタ処理で除外できる場合があります。その他の変更は、完全評価を実行して、取得プロセスのルール・セットを満たしているかどうかを判定する必要があります。

- 取得プロセスが最後に起動されてからの完全評価の数。完全評価を実行するとコストが高くなる場合があります。したがって、取得プロセスでは、この数が比較的小さい場合に最高のパフォーマンスが実現されます。

この問合せで表示される情報は、有効になっている取得プロセスに対してのみ有効です。

次の問合せを実行すると、各取得プロセスに関する前述の情報が表示されます。

COLUMN CAPTURE_NAME HEADING 'Capture|Name' FORMAT A15
COLUMN TOTAL_PREFILTER_DISCARDED HEADING 'Prefilter|Changes|Discarded'
FORMAT 9999999999
COLUMN TOTAL_PREFILTER_KEPT HEADING 'Prefilter|Changes|Kept' FORMAT 9999999999
COLUMN TOTAL_PREFILTER_EVALUATIONS HEADING 'Prefilter|Evaluations'
FORMAT 9999999999
COLUMN UNDECIDED HEADING 'Undecided|After|Prefilter' FORMAT 9999999999
COLUMN TOTAL_FULL_EVALUATIONS HEADING 'Full|Evaluations' FORMAT 9999999999

SELECT CAPTURE_NAME,
TOTAL_PREFILTER_DISCARDED,
TOTAL_PREFILTER_KEPT,
TOTAL_PREFILTER_EVALUATIONS,
(TOTAL_PREFILTER_EVALUATIONS -
(TOTAL_PREFILTER_KEPT + TOTAL_PREFILTER_DISCARDED)) UNDECIDED,
TOTAL_FULL_EVALUATIONS
FROM V$STREAMS_CAPTURE;

出力は次のようになります。

Prefilter   Prefilter               Undecided
Capture            Changes     Changes   Prefilter       After        Full
Name             Discarded        Kept Evaluations   Prefilter Evaluations
--------------- ---------- ----------- ----------- ----------- -----------
CAPTURE_HNS         927409     3271491     4198900           0           9

事前フィルタ処理評価の合計数は、事前フィルタ処理で廃棄された変更、保持された変更および判定されなかった変更の合計と等しくなります。

関連項目:
「取得プロセス・ルールの評価」

取得と適用の複合を使用する取得プロセスの判別

取得プロセスは伝播送信者として動作し、バッファ・キューは変更のレプリケーションがより効率的になるように最適化されるため、取得と適用の複合環境は効率的です。

取得プロセスで取得と適用の複合が使用される場合、V$STREAMS_CAPTUREデータ・ディクショナリ・ビューのOPTIMIZATION列は0(ゼロ)より大きい値です。取得プロセスで取得と適用の複合が使用されない場合、OPTIMIZATION列は0(ゼロ)です。

取得プロセスで取得と適用の複合が使用されるかどうかを判別するには、次の問合せを実行します。

COLUMN CAPTURE_NAME HEADING 'Capture Name' FORMAT A30
COLUMN OPTIMIZATION HEADING 'Optimized?' FORMAT A10

SELECT CAPTURE_NAME,
DECODE(OPTIMIZATION,
0, 'No',
'Yes') OPTIMIZATION
FROM V$STREAMS_CAPTURE;

出力は次のようになります。

Capture Name                   Optimized?
------------------------------ ----------
CAPTURE_HNS                    Yes

この出力は、取得プロセスcapture_hnsで取得と適用の複合が使用されていることを示しています。

関連項目:
第12章「取得と適用の複合による最適化」

分割とマージ操作に関する情報の表示

Oracle Streamsの宛先の分割とマージは、次の条件のときに役立ちます。

- 単一の取得プロセスによって、複数の適用プロセスに送信される変更が取得されます。

- 適用プロセスは、取得プロセスによって取得された変更の受入れを停止します。適用プロセスが変更の受入れを停止するのは、たとえば、適用プロセスが無効の場合、適用プロセスが含まれるデータベースが停止する場合、ネットワークの問題がある場合、適用プロセスが含まれるデータベースを実行しているコンピュータ・システムが停止する場合またはその他の理由のときです。

これらの条件が満たされている場合、問題のある宛先のストリームを、他の宛先のストリームから分割してパフォーマンスが低下しないようにすることをお薦めします。問題が修正されたら、分割された宛先のストリームを取得プロセスの他の宛先のストリームにマージできます。

デフォルトでは、分割とマージ操作は、Oracle Streamsが問題のある宛先を検出したときに自動的に実行されます。自動分割とマージ操作は、split_thresholdおよびmerge_thresholdの2つの取得プロセス・パラメータで制御されています。

次の各項では、現在および過去の自動分割とマージ操作を監視するために実行できる問合せについて説明します。

- 元およびクローニングされたOracle Streamsコンポーネントの名前の表示

- 分割とマージ操作のアクションおよびしきい値の表示

- クローニングされた取得プロセスのタイム・ラグの表示

- 分割とマージ・ジョブに関する情報の表示

- 過去の分割とマージ操作に関する情報の表示

注意:
この項で説明する問合せを実行すると、自動分割とマージ操作の情報のみが表示されます。これらの問合せでは、DBMS_STREAMS_ADMパッケージのSPLIT_STREAMSプロシージャを使用して手動でストリームを分割する操作に関する情報は表示されません。

関連項目:

- 分割とマージ操作の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- 取得プロセス・パラメータの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

元およびクローニングされたOracle Streamsコンポーネントの名前の表示

この項で説明する問合せを実行すると、分割とマージ操作に関与するOracle Streamsコンポーネントに関する次の情報が表示されます。

- 宛先のストリームの分割元となった元の取得プロセスの名前

- 問題のある宛先に関する変更を取得する、クローニングされた取得プロセスの名前

- 分割されたストリームの一部となっていた元の伝播または適用プロセスの名前
複数データベース構成では、伝播によって取得プロセスのキューから適用プロセスのキューに変更が送信され、伝播がこの問合せで表示されます。単一データベース構成では、適用プロセスによって、取得プロセスが使用するキューから変更がデキューされ、適用プロセスがこの問合せで表示されます。

- 問題のある宛先に関する変更を処理する、クローニングされた伝播または適用プロセスの名前

- 取得プロセスから変更を受信するOracle Streamsコンポーネントのタイプ(PROPAGATIONまたはAPPLYのいずれか)

次の問合せを実行すると、前述の情報が表示されます。

COLUMN ORIGINAL_CAPTURE_NAME HEADING 'Original|Capture|Process' FORMAT A15
COLUMN CLONED_CAPTURE_NAME HEADING 'Cloned|Capture|Process' FORMAT A15
COLUMN ORIGINAL_STREAMS_NAME HEADING 'Original|Streams|Name' FORMAT A15
COLUMN CLONED_STREAMS_NAME HEADING 'Cloned|Streams|Name' FORMAT A15
COLUMN STREAMS_TYPE HEADING 'Streams|Type' FORMAT A11

SELECT ORIGINAL_CAPTURE_NAME,
CLONED_CAPTURE_NAME,
ORIGINAL_STREAMS_NAME,
CLONED_STREAMS_NAME,
STREAMS_TYPE
FROM DBA_STREAMS_SPLIT_MERGE;

出力は次のようになります。

Original        Cloned          Original        Cloned
Capture         Capture         Streams         Streams         Streams
Process         Process         Name            Name            Type
--------------- --------------- --------------- --------------- -----------
DB$CAP          CLONED$_DB$CAP_ PROPAGATION$_17 CLONED$_PROPAGA PROPAGATION
1                               TION$_17_2

関連項目:
分割とマージ操作の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

分割とマージ操作のアクションおよびしきい値の表示

この項で説明する問合せを実行すると、分割とマージ操作によって実行されるアクション、および問題のある宛先を分割およびマージするために設定されたしきい値に関する次の情報が表示されます。

- 宛先のストリームの分割元となった元の取得プロセスの名前

- 分割またはマージ・ジョブのスクリプト・ステータス(GENERATING、NOT EXECUTED、EXECUTING、EXECUTEDまたはERRORのいずれか)

- ジョブによって実行されたアクションのタイプ(SPLIT、MERGEまたはMONITORのいずれか)
分割の実行が必要であることがSPLITジョブによって判断された場合、SPLITアクション・タイプを持つ行がDBA_STREAMS_SPLIT_MERGEビューに挿入されます。

分割操作が完了すると、SPLITアクション・タイプ行がDBA_STREAMS_SPLIT_MERGE_HISTビューにコピーされ、MERGEジョブが作成されます。MERGEアクション・タイプの行がDBA_STREAMS_SPLIT_MERGEビューに挿入されます。マージ操作が完了すると、MERGEアクション・タイプ行がDBA_STREAMS_SPLIT_MERGE_HISTビューに移動し、SPLITアクション・タイプ行がDBA_STREAMS_SPLIT_MERGEビューから削除されます。SPLITアクション・タイプ行は以前にDBA_STREAMS_SPLIT_MERGE_HISTビューにコピーされています。

元の各取得プロセスには、そのすべての宛先を監視するSPLITジョブがあります。このタイプのジョブでは、DBA_STREAMS_SPLIT_MERGEビュー内の行のMONITORアクション・タイプが表示されます。MONITORアクション・タイプ行は、SPLITジョブが無効の場合にのみDBA_STREAMS_SPLIT_MERGE_HISTビューに移動します。SPLITジョブは、split_threshold取得プロセス・パラメータをINFINITEに設定するか、または取得プロセスを削除することによって無効にできます。

- 操作に対して設定されている取得プロセス・パラメータのしきい値(秒単位)
SPLITジョブの場合、しきい値はsplit_threshold取得プロセス・パラメータで設定されます。MERGEジョブの場合、しきい値はmerge_threshold取得プロセス・パラメータで設定されます。

- アクションのステータス
SPLITアクションの場合、ステータスはSPLITTING、SPLIT DONEまたはERRORのいずれかです。SPLITTINGステータスは、分割操作が実行中であることを示します。SPLIT DONEステータスは、分割操作が完了していることを示します。ERRORステータスは、分割操作中にエラーが返されたことを示します。

MERGEアクションの場合、ステータスはNOTHING TO MERGE、MERGING、MERGE DONEまたはERRORのいずれかです。NOTHING TO MERGEステータスは、分割は実行されたものの分割済ストリームのマージ準備がまだできていないことを示します。MERGINGステータスは、マージ操作が実行中であることを示します。MERGE DONEステータスは、マージ操作が完了していることを示します。ERRORステータスは、マージ操作中にエラーが返されたことを示します。

MONITORアクションの場合、ステータスはSPLITおよびMERGEステータス値のいずれかです。また、MONITORアクションでは、そのステータスに関してNOTHING TO SPLITまたはNONSPLITTABLEが表示されることがあります。NOTHING TO SPLITステータスは、取得プロセスから送られるストリームがすべての宛先で処理中であり、分割できるストリームがないことを示します。NONSPLITTABLEステータスは、取得プロセスのストリームを分割できないことを示します。NONSPLITTABLEステータスが表示される可能性があるのは次の場合です。

- 取得プロセスが無効または中断されています。

- 取得プロセスのキューに、取得プロセスに加えて少なくとも1つのパブリッシャがあります。追加のパブリッシャは、別の取得プロセスまたはメッセージをキューに送信する伝播であることがあります。

- 取得プロセスにある宛先が1つのみです。分割とマージ操作は、取得プロセスによって取得される変更に複数の宛先が存在する場合にのみ可能です。

- ジョブ・ステータスが最後に更新されたときの日時

次の問合せを実行すると、前述の情報が表示されます。

COLUMN ORIGINAL_CAPTURE_NAME HEADING 'Original|Capture|Process' FORMAT A10
COLUMN SCRIPT_STATUS HEADING 'Script|Status' FORMAT A12
COLUMN ACTION_TYPE HEADING 'Action|Type' FORMAT A7
COLUMN ACTION_THRESHOLD HEADING 'Action|Threshold' FORMAT A15
COLUMN STATUS HEADING 'Status' FORMAT A16
COLUMN STATUS_UPDATE_TIME HEADING 'Status|Update|Time' FORMAT A15

SELECT ORIGINAL_CAPTURE_NAME,
SCRIPT_STATUS,
ACTION_TYPE,
ACTION_THRESHOLD,
STATUS,
STATUS_UPDATE_TIME
FROM DBA_STREAMS_SPLIT_MERGE
ORDER BY STATUS_UPDATE_TIME DESC;

出力は次のようになります。

Original                                                         Status
Capture    Script       Action  Action                           Update
Process    Status       Type    Threshold       Status           Time
---------- ------------ ------- --------------- ---------------- ---------------
DB$CAP     EXECUTED     SPLIT   1800            SPLIT DONE       31-MAR-09 01.31
.37.133788 PM

関連項目:

- 分割とマージ操作の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- 取得プロセス・パラメータの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

クローニングされた取得プロセスのタイム・ラグの表示

問題のある宛先に関して、取得プロセスからストリームが分割された後、宛先での問題を修正し、クローニングされた取得プロセスが有効になっていることを確認する必要があります。クローニングされた取得プロセスが問題のある宛先に変更を送信しており、問題のある宛先で適用プロセスがこれらの変更を適用していると、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;

出力は次のようになります。

Original Capture Process  Cloned Capture Process                 Lag
------------------------- ------------------------- ----------------
DB$CAP                    CLONED$_DB$CAP_1                       526

MERGE_STREAMS_JOBが実行され、タイム・ラグがmerge_threshold取得プロセス・パラメータの値以下の場合は、マージ操作が開始されます。

関連項目:
分割とマージ操作の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

分割とマージ・ジョブに関する情報の表示

この項で説明する問合せを実行すると、分割とマージ・ジョブに関する次の情報が表示されます。

- 宛先のストリームの分割元となった元の取得プロセスの名前

- ジョブの所有者

- ジョブの名前

- ジョブの現在の状態(DISABLED、RETRY SCHEDULED、SCHEDULED、RUNNING、COMPLETED、BROKEN、FAILED、REMOTE、SUCCEEDEDまたはCHAIN_STALLEDのいずれか)
これらのジョブの状態の詳細は、『Oracle Database管理者ガイド』を参照してください。

- ジョブが次に実行される日時

次の問合せを実行すると、前述の情報が表示されます。

COLUMN ORIGINAL_CAPTURE_NAME HEADING 'Original|Capture|Process' FORMAT A10
COLUMN JOB_OWNER HEADING 'Job Owner' FORMAT A10
COLUMN JOB_NAME HEADING 'Job Name' FORMAT A15
COLUMN JOB_STATE HEADING 'Job State' FORMAT A15
COLUMN JOB_NEXT_RUN_DATE HEADING 'Job Next|Run Date' FORMAT A20

SELECT ORIGINAL_CAPTURE_NAME,
JOB_OWNER,
JOB_NAME,
JOB_STATE,
JOB_NEXT_RUN_DATE
FROM DBA_STREAMS_SPLIT_MERGE;

出力は次のようになります。

Original
Capture                                               Job Next
Process    Job Owner  Job Name        Job State       Run Date
---------- ---------- --------------- --------------- --------------------
DB$CAP     SYS        STREAMS_SPLITJO SCHEDULED       01-APR-09 01.14.55.0
B$_3                            00000 PM -07:00
DB$CAP     SYS        STREAMS_MERGEJO SCHEDULED       01-APR-09 01.17.08.0
B$_6                            00000 PM -07:00

関連項目:
分割とマージ操作の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

過去の分割とマージ操作に関する情報の表示

この項で説明する問合せを実行すると、過去に実行された分割とマージ操作に関する次の履歴情報が表示されます。

- 宛先のストリームの分割元となった元の取得プロセスの名前

- 分割またはマージ・ジョブのスクリプト・ステータス

- ジョブによって実行されたアクションのタイプ(SPLITまたはMERGEのいずれか)

- ジョブによって実行されたアクションのステータス
ステータス値の詳細は、「分割とマージ操作のアクションおよびしきい値の表示」を参照してください。

- ジョブの所有者

- ジョブの名前

- リカバリ可能なスクリプトID

次の問合せを実行すると、前述の情報が表示されます。

COLUMN ORIGINAL_CAPTURE_NAME HEADING 'Original|Capture|Process' FORMAT A8
COLUMN SCRIPT_STATUS HEADING 'Script|Status' FORMAT A12
COLUMN ACTION_TYPE HEADING 'Action|Type' FORMAT A8
COLUMN STATUS HEADING 'Status' FORMAT A10
COLUMN JOB_OWNER HEADING 'Job Owner' FORMAT A10
COLUMN JOB_NAME HEADING 'Job Name' FORMAT A10
COLUMN RECOVERABLE_SCRIPT_ID HEADING 'Recoverable|Script ID' FORMAT A15

SELECT ORIGINAL_CAPTURE_NAME,
SCRIPT_STATUS,
ACTION_TYPE,
STATUS,
JOB_OWNER,
JOB_NAME,
RECOVERABLE_SCRIPT_ID
FROM DBA_STREAMS_SPLIT_MERGE_HIST;

出力は次のようになります。

Original
Capture  Script       Action                                    Recoverable
Process  Status       Type     Status     Job Owner  Job Name   Script ID
-------- ------------ -------- ---------- ---------- ---------- ---------------
DB1$CAP  EXECUTED     SPLIT    SPLIT DONE SYS        STREAMS_SP 6E5C6C49CDB5798
LITJOB$_9  3E040578C891704
87

DB1$CAP  EXECUTED     MERGE    MERGE DONE SYS        STREAMS_ME 6E5BA57554F1C4C
RGEJOB$_12 3E040578C89170A
1F

関連項目:
分割とマージ操作の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

サプリメンタル・ロギングの監視

次の各項では、ソース・データベースでのサプリメンタル・ロギングを監視するために実行できる問合せについて説明します。

- ソース・データベースでのサプリメンタル・ログ・グループの表示

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

- インスタンス化の準備中に指定されたサプリメンタル・ロギングの表示

データベースでのサプリメンタル・ロギングの合計は、これらの項で説明する3つすべての問合せで表示される結果の組合せによって決定されます。たとえば、サプリメンタル・ロギングは、表に関して「ソース・データベースでのサプリメンタル・ログ・グループの表示」の項の問合せで結果がまったく返されない場合であっても、表内の列に対して有効にできます。つまり、データベース・サプリメンタル・ロギングが有効になっている場合、またはインスタンス化の準備中にサプリメンタル・ロギングが有効にされたスキーマ内に表がある場合は、表に対してサプリメンタル・ロギングを有効にできます。

サプリメンタル・ロギングでは、操作が実行されたときにREDOログに列データが配置されます。取得プロセスは、この追加情報を取得し、LCRに配置します。これらの取得LCRを適用する適用プロセスは、変更を正しくスケジュールまたは適用するためにこの追加情報を必要とする場合があります。

関連項目:

- 「Oracle Streams環境内のサプリメンタル・ロギング」

- 『Oracle Streamsレプリケーション管理者ガイド』

ソース・データベースでのサプリメンタル・ログ・グループの表示

ソース・データベースで表に対して1つ以上のログ・グループが指定されているかどうかをチェックするには、次の問合せを実行します。

COLUMN LOG_GROUP_NAME HEADING 'Log Group' FORMAT A20
COLUMN TABLE_NAME HEADING 'Table' FORMAT A15
COLUMN ALWAYS HEADING 'Conditional or|Unconditional' FORMAT A14
COLUMN LOG_GROUP_TYPE HEADING 'Type of Log Group' FORMAT A20

SELECT
LOG_GROUP_NAME,
TABLE_NAME,
DECODE(ALWAYS,
'ALWAYS', 'Unconditional',
'CONDITIONAL', 'Conditional') ALWAYS,
LOG_GROUP_TYPE
FROM DBA_LOG_GROUPS;

出力は次のようになります。

Conditional or
Log Group            Table           Unconditional  Type of Log Group
-------------------- --------------- -------------- --------------------
LOG_GROUP_DEP_PK     DEPARTMENTS     Unconditional  USER LOG GROUP
SYS_C002105          REGIONS         Unconditional  PRIMARY KEY LOGGING
SYS_C002106          REGIONS         Conditional    FOREIGN KEY LOGGING
SYS_C002110          LOCATIONS       Unonditional   ALL COLUMN LOGGING
SYS_C002111          COUNTRIES       Conditional    ALL COLUMN LOGGING
LOG_GROUP_JOBS_CR    JOBS            Conditional    USER LOG GROUP

ログ・グループのタイプの出力で、ログ・グループの作成方法が表示される場合は、次のようになります。

- 出力がUSER LOG GROUPの場合、ログ・グループはALTER TABLE文のADD SUPPLEMENTAL LOG GROUP句を使用して作成されました。

- それ以外の場合、ログ・グループは、ALTER TABLE文のADD SUPPLEMENTAL LOG DATA句を使用して作成されました。

ログ・グループのタイプがUSER LOG GROUPの場合は、DBA_LOG_GROUP_COLUMNSデータ・ディクショナリ・ビューを問い合せることによって、ログ・グループ内の列をリストできます。

注意:
ログ・グループのタイプがUSER LOG GROUPではない場合、DBA_LOG_GROUP_COLUMNSデータ・ディクショナリ・ビューには、ログ・グループ内の列に関する情報は含まれません。かわりに、表に対して操作が実行されたときに正しい列が補足的にログに記録されます。たとえば、ログ・グループのタイプがPRIMARY KEY LOGGINGの場合、表に対して変更が実行されたときに現在の主キー列がログに記録されます。

データベース・サプリメンタル・ロギングの指定の表示

データベース・サプリメンタル・ロギングの指定を表示するには、次に示す例のように、V$DATABASE動的パフォーマンス・ビューを問い合せます。

COLUMN log_min HEADING 'Minimum|Supplemental|Logging?' FORMAT A12
COLUMN log_pk HEADING 'Primary Key|Supplemental|Logging?' FORMAT A12
COLUMN log_fk HEADING 'Foreign Key|Supplemental|Logging?' FORMAT A12
COLUMN log_ui HEADING 'Unique|Supplemental|Logging?' FORMAT A12
COLUMN log_all HEADING 'All Columns|Supplemental|Logging?' FORMAT A12

SELECT SUPPLEMENTAL_LOG_DATA_MIN log_min,
SUPPLEMENTAL_LOG_DATA_PK log_pk,
SUPPLEMENTAL_LOG_DATA_FK log_fk,
SUPPLEMENTAL_LOG_DATA_UI log_ui,
SUPPLEMENTAL_LOG_DATA_ALL log_all
FROM V$DATABASE;

出力は次のようになります。

Minimum      Primary Key  Foreign Key  Unique        All Columns
Supplemental Supplemental Supplemental Supplemental  Supplemental
Logging?     Logging?     Logging?     Logging?      Logging?
------------ ------------ ------------ ------------- ------------
YES          YES          YES          YES           NO

これらの結果では、データベース内のすべての表に関して、最小列、主キー列、外部キー列および一意キー列が補足的にログに記録されていることが示されます。一意キー列は補足的にログに記録されるため、ビットマップ索引列も補足的にログに記録されます。ただし、すべての列が補足的にログに記録されるわけではありません。

インスタンス化の準備中に指定されたサプリメンタル・ロギングの表示

サプリメンタル・ロギングは、データベース・オブジェクトのインスタンス化の準備がDBMS_CAPTURE_ADMパッケージの3つのプロシージャのうちの1つを使用して行われた場合に有効にできます。データ・ディクショナリ・ビューでは、PREPARE_TABLE_INSTANTIATION、PREPARE_SCHEMA_INSTANTIATIONおよびPREPARE_GLOBAL_INSTANTIATIONのプロシージャのいずれかによって有効にされたサプリメンタル・ロギングが表示されます。

- DBA_CAPTURE_PREPARED_TABLESビューでは、PREPARE_TABLE_INSTANTIATIONプロシージャによって有効にされたサプリメンタル・ロギングが表示されます。

- DBA_CAPTURE_PREPARED_SCHEMASビューでは、PREPARE_SCHEMA_INSTANTIATIONプロシージャによって有効にされたサプリメンタル・ロギングが表示されます。

- DBA_CAPTURE_PREPARED_DATABASEビューでは、PREPARE_GLOBAL_INSTANTIATIONプロシージャによって有効にされたサプリメンタル・ロギングが表示されます。

これらのビューにはそれぞれ次の列があります。

- SUPPLEMENTAL_LOG_DATA_PKでは、主キーのサプリメンタル・ロギングがプロシージャによって有効にされたかどうかが表示されます。

- SUPPLEMENTAL_LOG_DATA_UIでは、一意キーおよびビットマップ索引のサプリメンタル・ロギングがプロシージャによって有効にされたかどうかが表示されます。

- SUPPLEMENTAL_LOG_DATA_FKでは、外部キーのサプリメンタル・ロギングがプロシージャによって有効にされたかどうかが表示されます。

- SUPPLEMENTAL_LOG_DATA_ALLでは、すべての列のサプリメンタル・ロギングがプロシージャによって有効にされたかどうかが表示されます。

これらの列にはそれぞれ次の値のいずれかが表示されます。

- IMPLICITは、関連プロシージャによって列のサプリメンタル・ロギングが有効にされたことを示します。

- EXPLICITは、ALTER TABLEまたはALTER DATABASE文でADD SUPPLEMENTAL LOG DATA句を使用して手動で列のサプリメンタル・ロギングが有効にされたことを示します。

- NOは、準備プロシージャ、またはALTER TABLEまたはALTER DATABASE文でADD SUPPLEMENTAL LOG DATA句を使用して、列のサプリメンタル・ロギングが有効にされていないことを示します。列のサプリメンタル・ロギングが有効にされていない可能性があります。ただし、サプリメンタル・ロギングが、別のレベル(表、スキーマまたはデータベース)で有効にされているか、またはALTER TABLE文でADD SUPPLEMENTAL LOG GROUP句を使用して有効にされている場合があります。

次の各項では、これらのプロシージャで有効にされたサプリメンタル・ロギングを表示する問合せについて説明します。

- PREPARE_TABLE_INSTANTIATIONにより有効にされたサプリメンタル・ロギングの表示

- PREPARE_SCHEMA_INSTANTIATIONにより有効にされたサプリメンタル・ロギングの表示

- PREPARE_GLOBAL_INSTANTIATIONにより有効にされたサプリメンタル・ロギングの表示

PREPARE_TABLE_INSTANTIATIONにより有効にされたサプリメンタル・ロギングの表示

次の問合せを実行すると、hrスキーマの表に対してPREPARE_TABLE_INSTANTIATIONプロシージャを使用して有効にされたサプリメンタル・ロギングが表示されます。

COLUMN TABLE_NAME HEADING 'Table Name' FORMAT A15
COLUMN log_pk HEADING 'Primary Key|Supplemental|Logging' FORMAT A12
COLUMN log_fk HEADING 'Foreign Key|Supplemental|Logging' FORMAT A12
COLUMN log_ui HEADING 'Unique|Supplemental|Logging' FORMAT A12
COLUMN log_all HEADING 'All Columns|Supplemental|Logging' FORMAT A12

SELECT TABLE_NAME,
SUPPLEMENTAL_LOG_DATA_PK log_pk,
SUPPLEMENTAL_LOG_DATA_FK log_fk,
SUPPLEMENTAL_LOG_DATA_UI log_ui,
SUPPLEMENTAL_LOG_DATA_ALL log_all
FROM DBA_CAPTURE_PREPARED_TABLES
WHERE TABLE_OWNER = 'HR';

出力は次のようになります。

Primary Key  Foreign Key  Unique         All Columns
Supplemental Supplemental Supplemental   Supplemental
Table Name      Logging      Logging      Logging        Logging
--------------- ------------ ------------ -------------- ------------
COUNTRIES       NO           NO           NO             NO
REGIONS         IMPLICIT     IMPLICIT     IMPLICIT       NO
DEPARTMENTS     IMPLICIT     IMPLICIT     IMPLICIT       NO
LOCATIONS       EXPLICIT     NO           NO             NO
EMPLOYEES       NO           NO           NO             IMPLICIT
JOB_HISTORY     NO           NO           NO             NO
JOBS            NO           NO           NO             NO

これらの結果では次の内容が表示されます。

- PREPARE_TABLE_INSTANTIATIONプロシージャによって、hr.regionsおよびhr.departments表の主キー、一意キー、ビットマップ索引および外部キーの列に対してサプリメンタル・ロギングが有効にされています。

- PREPARE_TABLE_INSTANTIATIONプロシージャによって、hr.employees表のすべての列に対してサプリメンタル・ロギングが有効にされています。

- ALTER TABLE文でADD SUPPLEMENTAL LOG DATA句を使用して、hr.locations表に対して主キーのサプリメンタル・ロギングが有効にされています。

注意:
問合せでWHERE句を省略すると、データベース内のすべての表の情報がリストされます。

PREPARE_SCHEMA_INSTANTIATIONにより有効にされたサプリメンタル・ロギングの表示

次の問合せを実行すると、PREPARE_SCHEMA_INSTANTIATIONプロシージャによって有効にされたサプリメンタル・ロギングが表示されます。

COLUMN SCHEMA_NAME HEADING 'Schema Name' FORMAT A20
COLUMN log_pk HEADING 'Primary Key|Supplemental|Logging' FORMAT A12
COLUMN log_fk HEADING 'Foreign Key|Supplemental|Logging' FORMAT A12
COLUMN log_ui HEADING 'Unique|Supplemental|Logging' FORMAT A12
COLUMN log_all HEADING 'All Columns|Supplemental|Logging' FORMAT A12

SELECT SCHEMA_NAME,
SUPPLEMENTAL_LOG_DATA_PK log_pk,
SUPPLEMENTAL_LOG_DATA_FK log_fk,
SUPPLEMENTAL_LOG_DATA_UI log_ui,
SUPPLEMENTAL_LOG_DATA_ALL log_all
FROM DBA_CAPTURE_PREPARED_SCHEMAS;

出力は次のようになります。

Primary Key  Foreign Key  Unique         All Columns
Supplemental Supplemental Supplemental   Supplemental
Schema Name          Logging      Logging      Logging        Logging
-------------------- ------------ ------------ -------------- ------------
HR                   NO           NO           NO             IMPLICIT
OE                   IMPLICIT     IMPLICIT     IMPLICIT       NO

これらの結果では次の内容が表示されます。

- PREPARE_SCHEMA_INSTANTIATIONプロシージャによって、hrスキーマ内の表のすべての列に対してサプリメンタル・ロギングが有効にされています。

- PREPARE_SCHEMA_INSTANTIATIONプロシージャによって、oeスキーマ内の表の主キー、一意キー、ビットマップ索引および外部キーの列に対してサプリメンタル・ロギングが有効にされています。

PREPARE_GLOBAL_INSTANTIATIONにより有効にされたサプリメンタル・ロギングの表示

次の問合せを実行すると、PREPARE_GLOBAL_INSTANTIATIONプロシージャによって有効にされたサプリメンタル・ロギングが表示されます。

COLUMN log_pk HEADING 'Primary Key|Supplemental|Logging' FORMAT A12
COLUMN log_fk HEADING 'Foreign Key|Supplemental|Logging' FORMAT A12
COLUMN log_ui HEADING 'Unique|Supplemental|Logging' FORMAT A12
COLUMN log_all HEADING 'All Columns|Supplemental|Logging' FORMAT A12

SELECT SUPPLEMENTAL_LOG_DATA_PK log_pk,
SUPPLEMENTAL_LOG_DATA_FK log_fk,
SUPPLEMENTAL_LOG_DATA_UI log_ui,
SUPPLEMENTAL_LOG_DATA_ALL log_all
FROM DBA_CAPTURE_PREPARED_DATABASE;

出力は次のようになります。

Primary Key  Foreign Key  Unique         All Columns
Supplemental Supplemental Supplemental   Supplemental
Logging      Logging      Logging        Logging
------------ ------------ -------------- ------------
IMPLICIT     IMPLICIT     IMPLICIT       NO

これらの結果では、PREPARE_GLOBAL_INSTANTIATIONプロシージャによって、データベース内のすべての表の主キー、一意キー、ビットマップ索引および外部キーの列に対してサプリメンタル・ロギングが有効にされていることが示されます。

同期取得の監視

この項では、Oracle Streamsの同期取得の監視に使用できる問合せの例を示します。

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

- 各同期取得のキュー、ルール・セットおよび状態の表示

- 同期取得によって変更が取得される表の表示

関連項目:

- 「同期取得による暗黙的取得」

- 同期取得の構成の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- 「同期取得の管理」

- 同期取得を使用するレプリケーション環境の構成例については、Oracle Database 2日でデータ・レプリケーションおよび統合ガイドを参照

各同期取得のキュー、ルール・セットおよび状態の表示

この項で説明する問合せを実行すると、データベース内の各同期取得に関する次の情報を表示できます。

- 同期取得の名前

- 同期取得で使用されるキューの名前

- 同期取得で使用されるポジティブ・ルール・セットの名前

- 同期取得の取得ユーザー

データベース内の各同期取得に関する一般情報を表示するには、次の問合せを実行します。

COLUMN CAPTURE_NAME HEADING 'Synchronous|Capture Name' FORMAT A20
COLUMN QUEUE_NAME HEADING 'Synchronous|Capture Queue' FORMAT A20
COLUMN RULE_SET_NAME HEADING 'Positive Rule Set' FORMAT A20
COLUMN CAPTURE_USER HEADING 'Capture User' FORMAT A15

SELECT CAPTURE_NAME, QUEUE_NAME, RULE_SET_NAME, CAPTURE_USER
FROM DBA_SYNC_CAPTURE;

出力は次のようになります。

Synchronous          Synchronous
Capture Name         Capture Queue        Positive Rule Set    Capture User
-------------------- -------------------- -------------------- ---------------
SYNC01_CAPTURE       STRM01_QUEUE         RULESET$_21          STRMADMIN
SYNC02_CAPTURE       STRM02_QUEUE         SYNC02_RULE_SET      HR

同期取得によって変更が取得される表の表示

ローカル・データベースの同期取得によってDML変更が取得される表は、DBA_SYNC_CAPTURE_TABLESビューに表示されます。DBA_STREAMS_TABLE_RULESビューには、各同期取得の名前および各同期取得で使用されるルールに関する情報が含まれています。この項で説明する問合せを実行すると、次の情報を表示できます。

- 各同期取得の名前。

- 同期取得で使用されるルールの名前。

- ルールが適用されるサブセット化操作のタイプ(ルールがサブセット・ルールの場合)。

- 各ルールで指定されている各表の所有者。

- 各ルールで指定されている各表の名前。

- 同期取得が表に対して有効または無効のいずれになっているか。表に対して同期取得が有効になっている場合、表に対して行われたDML変更は同期取得によって取得されます。表に対して同期取得が有効になっていない場合、表に対して行われたDML変更は同期取得によって取得されません。

これらの情報を表示するには、次の問合せを実行します。

COLUMN STREAMS_NAME HEADING 'Synchronous|Capture Name' FORMAT A15
COLUMN RULE_NAME HEADING 'Rule Name' FORMAT A15
COLUMN SUBSETTING_OPERATION HEADING 'Subsetting|Operation' FORMAT A10
COLUMN TABLE_OWNER HEADING 'Table|Owner' FORMAT A10
COLUMN TABLE_NAME HEADING 'Table Name' FORMAT A15
COLUMN ENABLED HEADING 'Enabled?' FORMAT A8

SELECT r.STREAMS_NAME,
r.RULE_NAME,
r.SUBSETTING_OPERATION,
t.TABLE_OWNER,
t.TABLE_NAME,
t.ENABLED
FROM DBA_STREAMS_TABLE_RULES r,
DBA_SYNC_CAPTURE_TABLES t
WHERE r.STREAMS_TYPE = 'SYNC_CAPTURE' AND
r.TABLE_OWNER  = t.TABLE_OWNER AND
r.TABLE_NAME   = t.TABLE_NAME;

出力は次のようになります。

Synchronous                     Subsetting Table
Capture Name    Rule Name       Operation  Owner      Table Name      Enabled?
--------------- --------------- ---------- ---------- --------------- --------
SYNC01_CAPTURE  EMPLOYEES20                HR         EMPLOYEES       YES
SYNC02_CAPTURE  DEPARTMENTS24   DELETE     HR         DEPARTMENTS     YES
SYNC02_CAPTURE  DEPARTMENTS23   UPDATE     HR         DEPARTMENTS     YES
SYNC02_CAPTURE  DEPARTMENTS22   INSERT     HR         DEPARTMENTS     YES

この出力は、表hr.employeesに対して行われたDML変更が同期取得sync01_captureによって取得されることを示しています。また、この出力は、表hr.departmentsに対して行われた変更のサブセットが同期取得sync02_captureによって取得されることも示しています。

表のENABLED列にNOが表示されている場合、この表に対する変更は同期取得によっては取得されません。DBMS_STREAMS_ADMパッケージのADD_TABLE_RULESまたはADD_SUBSET_RULES以外のプロシージャによって同期取得のルール・セットに表ルールが追加されると、ENABLED列にNOが表示されます。たとえば、DBMS_RULE_ADMパッケージのADD_RULEプロシージャによって同期取得のルール・セットに表ルールが追加された場合、DBA_SYNC_CAPTURE_TABLESビューを問い合せると表は表示されますが、同期取得によって表に対するDML変更は取得されません。DBA_SYNC_CAPTURE_TABLESビューに、スキーマおよびグローバル・ルールの結果は表示されません。

暗黙的取得によって取得された追加属性の表示

DBMS_CAPTURE_ADMパッケージのINCLUDE_EXTRA_ATTRIBUTEプロシージャを使用すると、1つ以上の追加属性を取得してLCRに含めるように取得プロセスまたは同期取得に指示できます。次の問合せを実行すると、ローカル・データベースの各取得プロセスによって取得されたLCRに含まれている追加属性が表示されます。

COLUMN CAPTURE_NAME HEADING 'Capture Process or|Synchronous Capture' FORMAT A20
COLUMN ATTRIBUTE_NAME HEADING 'Attribute Name' FORMAT A15
COLUMN INCLUDE HEADING 'Include Attribute in LCRs?' FORMAT A30

SELECT CAPTURE_NAME, ATTRIBUTE_NAME, INCLUDE
FROM DBA_CAPTURE_EXTRA_ATTRIBUTES
ORDER BY CAPTURE_NAME;

出力は次のようになります。

Capture Process or   Attribute Name  Include Attribute in LCRs?
Synchronous Capture
-------------------- --------------- ------------------------------
SYNC_CAPTURE         ROW_ID          NO
SYNC_CAPTURE         SERIAL#         NO
SYNC_CAPTURE         SESSION#        NO
SYNC_CAPTURE         THREAD#         NO
SYNC_CAPTURE         TX_NAME         YES
SYNC_CAPTURE         USERNAME        NO

この出力に基づいて、取得プロセスまたは同期取得sync_captureでは、取得したLCRにトランザクション名(tx_name)が含められますが、その他の追加属性は含められません。CAPTURE_NAME列によって戻される名前が取得プロセスまたは同期取得のいずれであるかを判別するには、DBA_CAPTUREおよびDBA_SYNC_CAPTUREビューを問い合せます。

関連項目:

- 「LCRのその他の情報」

- 「取得LCRの追加属性の管理」

- INCLUDE_EXTRA_ATTRIBUTEプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

25 Oracle Streamsのキューおよび伝播の監視

次の各項では、Oracle Streamsのキューと伝播の監視について説明します。

- キューおよびメッセージの監視

- バッファ・キューの監視

- Oracle Streamsの伝播および伝播ジョブの監視

注意:
Oracle Enterprise ManagerのOracle Streamsツールも、Oracle Streams環境を監視するための優れた手段です。詳細は、Oracle Database 2日でデータ・レプリケーションおよび統合ガイドおよびOracle Streamsツールのオンライン・ヘルプを参照してください。

関連項目:

- 第3章「Oracle Streamsのステージングと伝播」

- 第16章「ステージングと伝播の管理」

- この章で説明するデータ・ディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照

キューおよびメッセージの監視

次の各項では、キューとメッセージの情報の表示について説明します。

- データベース内のANYDATAキューの表示

- データベースでのメッセージ・クライアントの表示

- メッセージ通知の表示

- 永続キュー内の各メッセージのコンシューマの決定

- 永続キュー内のメッセージの内容の表示

関連項目:

- 第3章「Oracle Streamsのステージングと伝播」

- 第16章「ステージングと伝播の管理」

データベース内のANYDATAキューの表示

データベース内のすべてのANYDATAキューを表示するには、次の問合せを実行します。

COLUMN OWNER HEADING 'Owner' FORMAT A10
COLUMN NAME HEADING 'Queue Name' FORMAT A28
COLUMN QUEUE_TABLE HEADING 'Queue Table' FORMAT A22
COLUMN USER_COMMENT HEADING 'Comment' FORMAT A15

SELECT q.OWNER, q.NAME, t.QUEUE_TABLE, q.USER_COMMENT
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;

出力は次のようになります。

Owner      Queue Name                   Queue Table            Comment
---------- ---------------------------- ---------------------- ---------------
STRMADMIN  DB$APPQ                      DB$APPQT
STRMADMIN  AQ$_DB$APPQT_E               DB$APPQT               exception queue
STRMADMIN  DA$CAPQ                      DA$CAPQT
STRMADMIN  AQ$_DA$CAPQT_E               DA$CAPQT               exception queue
IX         STREAMS_QUEUE                STREAMS_QUEUE_TABLE
IX         AQ$_STREAMS_QUEUE_TABLE_E    STREAMS_QUEUE_TABLE    exception queue

例外キューは、ANYDATAキューを作成すると自動的に作成されます。

関連項目:
「キューの管理」

データベースでのメッセージ・クライアントの表示

DBA_STREAMS_MESSAGE_CONSUMERSデータ・ディクショナリ・ビューを問い合せると、データベース内のメッセージ・クライアントを表示できます。この項で説明する問合せを実行すると、各メッセージ・クライアントに関する次の情報が表示されます。

- メッセージ・クライアントの名前

- メッセージ・クライアントで使用されるキュー

- メッセージ・クライアントで使用されるポジティブ・ルール・セット

- メッセージ・クライアントで使用されるネガティブ・ルール・セット

次の問合せを実行すると、メッセージ・クライアントに関する前述の情報が表示されます。

COLUMN STREAMS_NAME HEADING 'Messaging|Client' FORMAT A25
COLUMN QUEUE_OWNER HEADING 'Queue|Owner' FORMAT A10
COLUMN QUEUE_NAME HEADING 'Queue Name' FORMAT A18
COLUMN RULE_SET_NAME HEADING 'Positive|Rule Set' FORMAT A11
COLUMN NEGATIVE_RULE_SET_NAME HEADING 'Negative|Rule Set' FORMAT A11

SELECT STREAMS_NAME,
QUEUE_OWNER,
QUEUE_NAME,
RULE_SET_NAME,
NEGATIVE_RULE_SET_NAME
FROM DBA_STREAMS_MESSAGE_CONSUMERS;

出力は次のようになります。

Messaging                 Queue                         Positive    Negative
Client                    Owner      Queue Name         Rule Set    Rule Set
------------------------- ---------- ------------------ ----------- -----------
SCHEDULER_PICKUP          SYS        SCHEDULER$_JOBQ    RULESET$_8
SCHEDULER_COORDINATOR     SYS        SCHEDULER$_JOBQ    RULESET$_4
HR                        STRMADMIN  STREAMS_QUEUE      RULESET$_15

関連項目:
メッセージ・クライアントの詳細は、第3章「 Oracle Streamsのステージングと伝播」を参照

メッセージ通知の表示

メッセージ・クライアントによってデキュー可能なメッセージがキューにエンキューされる際に、通知が送信されるようにメッセージ通知を構成することができます。通知は、電子メール・アドレス、HTTP URLまたはPL/SQLプロシージャに送信できます。次の問合せを実行すると、データベース内で構成されたメッセージ通知が表示されます。

COLUMN STREAMS_NAME HEADING 'Messaging|Client' FORMAT A10
COLUMN QUEUE_OWNER HEADING 'Queue|Owner' FORMAT A5
COLUMN QUEUE_NAME HEADING 'Queue Name' FORMAT A20
COLUMN NOTIFICATION_TYPE HEADING 'Notification|Type' FORMAT A15
COLUMN NOTIFICATION_ACTION HEADING 'Notification|Action' FORMAT A25

SELECT STREAMS_NAME,
QUEUE_OWNER,
QUEUE_NAME,
NOTIFICATION_TYPE,
NOTIFICATION_ACTION
FROM DBA_STREAMS_MESSAGE_CONSUMERS
WHERE NOTIFICATION_TYPE IS NOT NULL;

出力は次のようになります。

Messaging  Queue                      Notification    Notification
Client     Owner Queue Name           Type            Action
---------- ----- -------------------- --------------- -------------------------
OE         OE    NOTIFICATION_QUEUE   MAIL            mary.smith@example.com

関連項目:

- メッセージ通知の基本情報については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照

- メッセージ通知の詳細は、『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイド』を参照

永続キュー内の各メッセージのコンシューマの決定

永続キュー内の各メッセージのコンシューマを決定するには、キュー所有者のスキーマ内でAQ$queue_table_nameを問い合せます。この場合、queue_table_nameはキュー表名です。たとえば、oe_q_table_anyキュー表内のメッセージのコンシューマを検索するには、次の問合せを実行します。

COLUMN MSG_ID HEADING 'Message ID' FORMAT 9999
COLUMN MSG_STATE HEADING 'Message State' FORMAT A13
COLUMN CONSUMER_NAME HEADING 'Consumer' FORMAT A30

SELECT MSG_ID, MSG_STATE, CONSUMER_NAME FROM AQ$OE_Q_TABLE_ANY;

出力は次のようになります。

Message ID                       Message State Consumer
-------------------------------- ------------- ------------------------------
B79AC412AE6E08CAE034080020AE3E0A PROCESSED     OE
B79AC412AE6F08CAE034080020AE3E0A PROCESSED     OE
B79AC412AE7008CAE034080020AE3E0A PROCESSED     OE

注意:
この問合せを実行すると、取得LCRや、バッファ・キュー内の他のメッセージではなく、永続キューのメッセージのみが表示されます。

関連項目:
メッセージをANYDATAキューにエンキューする例については、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイド を参照。

永続キュー内のメッセージの内容の表示

ANYDATAキュー内で、ANYDATAペイロード内にカプセル化されているペイロードの内容を表示するには、ANYDATA型のAccessdata_type統計ファンクションを使用してキュー表を問い合せます。この場合、data_typeは表示するペイロードの型です。

関連項目:
この項の問合せで表示されるメッセージをANYDATAキューにエンキューする例については、『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイド』を参照

たとえば、キュー表oe_queue_tableを持つキューにあるNUMBER型のペイロードの内容を表示するには、キュー所有者として次の問合せを実行します。

SELECT qt.user_data.AccessNumber() "Numbers in Queue"
FROM strmadmin.oe_q_table_any qt;

出力は次のようになります。

Numbers in Queue
----------------
16

同様に、キュー表oe_q_table_anyを持つキューにあるVARCHAR2型のペイロードの内容を表示するには、次の問合せを実行します。

SELECT qt.user_data.AccessVarchar2() "Varchar2s in Queue"
FROM strmadmin.oe_q_table_any qt;

出力は次のようになります。

Varchar2s in Queue
--------------------------------------------------------------------------------
Chemicals - SW

ユーザー定義のデータ型の内容を表示するには、作成したカスタム・ファンクションを使用してキュー表を問い合せます。たとえば、oe.cust_address_typのペイロードの内容を表示するには、次のようなファンクションを作成します。

CREATE OR REPLACE FUNCTION oe.view_cust_address_typ(
in_any IN ANYDATA)
RETURN oe.cust_address_typ
IS
address   oe.cust_address_typ;
num_var   NUMBER;
BEGIN
IF (in_any.GetTypeName() = 'OE.CUST_ADDRESS_TYP') THEN
num_var := in_any.GetObject(address);
RETURN address;
ELSE RETURN NULL;
END IF;
END;
/

GRANT EXECUTE ON oe.view_cust_address_typ TO strmadmin;

GRANT EXECUTE ON oe.cust_address_typ TO strmadmin;

次の例のように、ファンクションを使用してキュー表を問い合せます。

SELECT oe.view_cust_address_typ(qt.user_data) "Customer Addresses"
FROM strmadmin.oe_q_table_any qt
WHERE qt.user_data.GetTypeName() = 'OE.CUST_ADDRESS_TYP';

出力は次のようになります。

Customer Addresses(STREET_ADDRESS, POSTAL_CODE, CITY, STATE_PROVINCE, COUNTRY_ID
--------------------------------------------------------------------------------
CUST_ADDRESS_TYP('1646 Brazil Blvd', '361168', 'Chennai', 'Tam', 'IN')

バッファ・キューの監視

バッファ・キューには、次の記憶域が含まれます。

- キューに関連付けられたシステム・グローバル領域(SGA)メモリー

- メモリーからオーバーフローしたメッセージを格納するキューのキュー表の一部

バッファ・キューはOracle Streamsプールに格納されます。Oracle Streamsプールは、Oracle Streamsによって使用されるSGAのメモリーの一部です。Oracle Streams環境では、取得プロセスによって取得されたLCRは、常にANYDATAキューのバッファ・キューに格納されます。また、ユーザーおよびアプリケーションは、バッファ・キューにメッセージをエンキューできます。これらのバッファ・キューは、ANYDATAキューまたは型付きキューの一部です。

バッファ・キューを使用すると、Oracle Databaseでは、メッセージを常にキュー表に格納するのではなく、SGAに格納することによって、メッセージを最適化できます。取得LCRは常にバッファ・キューに格納されますが、他のタイプのメッセージは、バッファ・キューに格納するか、またはキュー表に永続的に格納できます。バッファ・キュー内のメッセージは、一定期間デキューされずにバッファ・キュー内でステージングされた場合や、メモリーにすべてのメッセージを保持するための十分な領域がない場合に、メモリーからオーバーフローします。メモリーからオーバーフローしたメッセージは、適切なキュー表に格納されます。

次の項では、バッファ・キューを監視する問合せについて説明します。

- 各バッファ・キュー内のメッセージ数の決定

- 各バッファ・キュー内のLCRの取得プロセスの表示

- バッファ・メッセージを送信する伝播に関する情報の表示

- 伝播によって送信されたメッセージ数およびバイト数の表示

- バッファ・メッセージを送信する伝播のパフォーマンス統計の表示

- 各バッファ・キューからメッセージをデキューする伝播の表示

- バッファ・メッセージを受信する伝播のパフォーマンス統計の表示

- 各バッファ・キューからのメッセージをデキューする適用プロセスの表示

各バッファ・キュー内のメッセージ数の決定

V$BUFFERED_QUEUES動的パフォーマンス・ビューには、バッファ・キュー内のメッセージ数に関する情報が含まれます。メッセージは、取得LCR、バッファLCRまたはバッファ・ユーザー・メッセージのいずれかです。

この項で説明する問合せを実行すると、データベース内の各バッファ・キューに関する次の情報を特定できます。

- キューの所有者

- キュー名

- 現在メモリー内にあるメッセージの数

- メモリーからキュー表にオーバーフローしたメッセージの数

- バッファ・キュー内のメッセージの合計数(メモリー内のメッセージおよびキュー表にオーバーフローしたメッセージを含む)

これらの情報を表示するには、次の問合せを実行します。

COLUMN QUEUE_SCHEMA HEADING 'Queue Owner' FORMAT A15
COLUMN QUEUE_NAME HEADING 'Queue Name' FORMAT A15
COLUMN MEM_MSG HEADING 'Messages|in Memory' FORMAT 99999999
COLUMN SPILL_MSGS HEADING 'Messages|Spilled' FORMAT 99999999
COLUMN NUM_MSGS HEADING 'Total Messages|in Buffered Queue' FORMAT 99999999

SELECT QUEUE_SCHEMA,
QUEUE_NAME,
(NUM_MSGS - SPILL_MSGS) MEM_MSG,
SPILL_MSGS,
NUM_MSGS
FROM V$BUFFERED_QUEUES;

出力は次のようになります。

Messages      Messages      Total Messages
Queue Owner     Queue Name          in Memory       Spilled   in Buffered Queue
--------------- --------------- ------------- ------------- -------------------
STRMADMIN       STREAMS_QUEUE             534            21                 555

各バッファ・キュー内のLCRの取得プロセスの表示

取得プロセスは、取得LCRをバッファ・キューにエンキューするキュー・パブリッシャです。これらのLCRは、それ以後に他のキューに伝播できます。V$BUFFERED_PUBLISHERS動的パフォーマンス・ビューを問い合せると、バッファ・キュー内のLCRを取得した各取得プロセスを表示できます。これらのLCRはローカル・データベースで取得されているか、またはリモート・データベースで取得され、問合せで指定されたキューに伝播されている場合があります。

この項で説明する問合せでは、ローカル・データベースのバッファ・キューには取得LCRのみが格納され、バッファLCRやバッファ・ユーザー・メッセージは格納されないと想定しています。この問合せを実行すると、各取得プロセスに関する次の情報が表示されます。

- バッファ・キューのLCRを取得した取得プロセスの名前

- 取得プロセスがリモート・データベースで実行されており、取得LCRがローカル・キューに伝播された場合、取得LCRの最新の伝播元であるキューおよびデータベースの名前

- 取得LCRをステージングするローカル・キューの名前

- 取得プロセスによって取得されたLCR(データベース・インスタンスが前回起動してからバッファ・キューにステージングされたLCR)の合計数

- 送信者からバッファ・キューに最後にエンキューされたLCRのメッセージ番号

- 取得プロセス・データベースで使用されるStreamsプールのパーセンテージ

- パブリッシャの状態。取得プロセスがパブリッシャであり、次の状態があります。

- PUBLISHING MESSAGES

- IN FLOW CONTROL: TOO MANY UNBROWSED MESSAGES

- IN FLOW CONTROL: OVERSPILLED MESSAGES

- IN FLOW CONTROL: INSUFFICIENT MEMORY AND UNBROWSED MESSAGES

これらの情報を表示するには、次の問合せを実行します。

COLUMN SENDER_NAME HEADING 'Capture|Process' FORMAT A10
COLUMN SENDER_ADDRESS HEADING 'Sender Queue' FORMAT A15
COLUMN QUEUE_NAME HEADING 'Queue Name' FORMAT A10
COLUMN CNUM_MSGS HEADING 'Number|of LCRs|Enqueued' FORMAT 99999999
COLUMN LAST_ENQUEUED_MSG HEADING 'Last|Enqueued|LCR' FORMAT 9999999999
COLUMN MEMORY_USAGE HEADING 'Percent|Streams|Pool|Used' FORMAT 999
COLUMN PUBLISHER_STATE HEADING 'Publisher|State' FORMAT A10

SELECT SENDER_NAME,
SENDER_ADDRESS,
QUEUE_NAME,
CNUM_MSGS,
LAST_ENQUEUED_MSG,
MEMORY_USAGE,
PUBLISHER_STATE
FROM V$BUFFERED_PUBLISHERS;

出力は次のようになります。

Percent
Number        Last Streams
Capture                                 of LCRs    Enqueued    Pool Publisher
Process    Sender Queue    Queue Name  Enqueued         LCR    Used State
---------- --------------- ---------- --------- ----------- ------- ----------
DB1$CAP                    DB1$CAPQ        3670     1002253      21 PUBLISHING
MESSAGES

DB2$CAP    "STRMADMIN"."DB DB2$APPQ        3427      981066      21 PUBLISHING
2$CAPQ"@DB2.EXA                                           MESSAGES
MPLE.COM

この出力から次のことがわかります。

- ローカルのdb1$cap取得プロセスの3670個のLCRが、db1$capqというローカル・キューにエンキューされました。この取得プロセスは、Sender Queue列がNULLであるため、ローカルです。この取得プロセスから最後にエンキューされたLCRのメッセージ番号は1002253でした。Streamsプールの21%が取得プロセス・データベースで使用され、通常は取得プロセスがメッセージをパブリッシュします。

- リモート・データベースで実行されるdb2$cap取得プロセスの3427個のLCRが、データベースdb2.example.comのキューdb2$capqからローカル・キューdb2$appqに伝播されました。この送信者から最後にエンキューされたLCRのメッセージ番号は961066でした。Streamsプールの21%がリモートの取得プロセス・データベースで使用され、通常は取得プロセスがメッセージをパブリッシュします。

バッファ・メッセージを送信する伝播に関する情報の表示

この項で説明する問合せを実行すると、バッファ・メッセージをローカル・データベースのバッファ・キューから送信する各伝播に関する次の情報が表示されます。

- 伝播の名前

- キューの所有者

- キュー名

- 伝播で使用されるデータベース・リンクの名前

- 伝播スケジュールの状態

これらの情報を表示するには、次の問合せを実行します。

COLUMN PROPAGATION_NAME HEADING 'Propagation' FORMAT A15
COLUMN QUEUE_SCHEMA HEADING 'Queue|Owner' FORMAT A10
COLUMN QUEUE_NAME HEADING 'Queue|Name' FORMAT A15
COLUMN DBLINK HEADING 'Database|Link' FORMAT A10
COLUMN SCHEDULE_STATUS HEADING 'Schedule Status' FORMAT A20

SELECT p.PROPAGATION_NAME,
s.QUEUE_SCHEMA,
s.QUEUE_NAME,
s.DBLINK,
s.SCHEDULE_STATUS
FROM DBA_PROPAGATION p, V$PROPAGATION_SENDER s
WHERE p.SOURCE_QUEUE_OWNER      = s.QUEUE_SCHEMA AND
p.SOURCE_QUEUE_NAME       = s.QUEUE_NAME AND
p.DESTINATION_QUEUE_OWNER = s.DST_QUEUE_SCHEMA AND
p.DESTINATION_QUEUE_NAME  = s.DST_QUEUE_NAME;

出力は次のようになります。

Queue      Queue           Database
Propagation     Owner      Name            Link       Schedule Status
--------------- ---------- --------------- ---------- --------------------
PROPAGATION$_6  STRMADMIN  DB1$CAPQ        "STRMADMIN SCHEDULE OPTIMIZED
"."DB1$APP
Q"@DB2.EXA
MPLE.COM

V$PROPAGATION_SENDERビューのSCHEDULE_STATUS列で伝播がSCHEDULE OPTIMIZEDになっている場合は、伝播が取得と適用の複合による最適化の一部であることを意味します。

関連項目:
第12章「取得と適用の複合による最適化」

伝播によって送信されたメッセージ数およびバイト数の表示

この項で説明する問合せを実行すると、ローカル・データベースのバッファ・キューからバッファ・メッセージを送信する各伝播によって送信されたメッセージの数とバイト数が表示されます。

- 伝播の名前

- キュー名

- 伝播で使用されるデータベース・リンクの名前

- データベース・インスタンスが最後に起動されてから送信されたメッセージの合計数

- データベース・インスタンスが最後に起動されてから送信されたバイトの合計数

これらの情報を表示するには、次の問合せを実行します。

COLUMN PROPAGATION_NAME HEADING 'Propagation' FORMAT A15
COLUMN QUEUE_NAME HEADING 'Queue|Name' FORMAT A15
COLUMN DBLINK HEADING 'Database|Link' FORMAT A20
COLUMN TOTAL_MSGS HEADING 'Total|Messages' FORMAT 99999999
COLUMN TOTAL_BYTES HEADING 'Total|Bytes' FORMAT 999999999999

SELECT p.PROPAGATION_NAME,
s.QUEUE_NAME,
s.DBLINK,
s.TOTAL_MSGS,
s.TOTAL_BYTES
FROM DBA_PROPAGATION p, V$PROPAGATION_SENDER s
WHERE p.SOURCE_QUEUE_OWNER      = s.QUEUE_SCHEMA AND
p.SOURCE_QUEUE_NAME       = s.QUEUE_NAME AND
p.DESTINATION_QUEUE_OWNER = s.DST_QUEUE_SCHEMA AND
p.DESTINATION_QUEUE_NAME  = s.DST_QUEUE_NAME;

出力は次のようになります。

Queue           Database            Total     Total
Propagation     Name            Link                 Messages     Bytes
--------------- --------------- -------------------- --------- ---------
MULT1_TO_MULT3  STREAMS_QUEUE   MULT3.EXAMPLE.COM           79     71467
MULT1_TO_MULT2  STREAMS_QUEUE   MULT2.EXAMPLE.COM           79     71467

バッファ・メッセージを送信する伝播のパフォーマンス統計の表示

この項で説明する問合せを実行すると、バッファ・メッセージを送信する伝播が様々なタスクを実行するためにかかった時間が表示されます。各伝播では、ソース・キューから宛先キューにメッセージが送信されます。この問合せを実行すると、具体的には次の情報が表示されます。

- 伝播の名前

- キュー名

- 伝播で使用されるデータベース・リンクの名前

- データベース・インスタンスが最後に起動されてから、キューからメッセージをデキューするためにかかった時間(秒単位)

- データベース・インスタンスが最後に起動されてから、メッセージをピクルするためにかかった時間(秒単位)。ピクルを行うと、メモリー内のメッセージが、ネットワーク経由で送信可能な一連のバイトに変更されます。

- データベース・インスタンスが最後に起動されてから、メッセージを伝播するためにかかった時間(秒単位)

これらの情報を表示するには、次の問合せを実行します。

COLUMN PROPAGATION_NAME HEADING 'Propagation' FORMAT A15
COLUMN QUEUE_NAME HEADING 'Queue|Name' FORMAT A13
COLUMN DBLINK HEADING 'Database|Link' FORMAT A9
COLUMN ELAPSED_DEQUEUE_TIME HEADING 'Dequeue|Time' FORMAT 99999999.99
COLUMN ELAPSED_PICKLE_TIME HEADING 'Pickle|Time' FORMAT 99999999.99
COLUMN ELAPSED_PROPAGATION_TIME HEADING 'Propagation|Time' FORMAT 99999999.99

SELECT p.PROPAGATION_NAME,
s.QUEUE_NAME,
s.DBLINK,
(s.ELAPSED_DEQUEUE_TIME / 100) ELAPSED_DEQUEUE_TIME,
(s.ELAPSED_PICKLE_TIME / 100) ELAPSED_PICKLE_TIME,
(s.ELAPSED_PROPAGATION_TIME / 100) ELAPSED_PROPAGATION_TIME
FROM DBA_PROPAGATION p, V$PROPAGATION_SENDER s
WHERE p.SOURCE_QUEUE_OWNER      = s.QUEUE_SCHEMA AND
p.SOURCE_QUEUE_NAME       = s.QUEUE_NAME AND
p.DESTINATION_QUEUE_OWNER = s.DST_QUEUE_SCHEMA AND
p.DESTINATION_QUEUE_NAME  = s.DST_QUEUE_NAME;

出力は次のようになります。

Queue         Database       Dequeue       Pickle  Propagation
Propagation     Name          Link              Time         Time         Time
--------------- ------------- --------- ------------ ------------ ------------
MULT1_TO_MULT2  STREAMS_QUEUE MULT2.EXA        30.65        45.10        10.91
MPLE.COM
MULT1_TO_MULT3  STREAMS_QUEUE MULT3.EXA        25.36        37.07         8.35
MPLE.COM

各バッファ・キューからメッセージをデキューする伝播の表示

伝播は、メッセージをデキューできるキュー・サブスクライバです。V$BUFFERED_SUBSCRIBERS動的パフォーマンス・ビューを問い合せると、バッファ・メッセージをデキューできるすべての伝播を表示できます。

適用プロセスもキュー・サブスクライバです。この問合せはDBA_PROPAGATIONおよびV$BUFFERED_QUEUESビューと結合され、伝播ののみ情報を出力するように制限し、各伝播の伝播名を表示します。

この項で説明する問合せを実行すると、キューからメッセージをデキューできる各伝播に関する次の情報が表示されます。

- 伝播の名前

- 伝播がサブスクライブするキューの所有者と名前
このキューは、伝播用のソース・キューです。

- サブスクライバ・アドレス
伝播では、サブスクライバ・アドレスが伝播の宛先キューおよび宛先データベースになります。

- 伝播が最後に起動された時刻

- データベースが最後に起動されてから、伝播によってデキューされたメッセージの累積数

- 伝播が最後に起動されてから、その伝播によってデキューされたメッセージの合計数

- 伝播によって最後にデキューされたメッセージのメッセージ番号

これらの情報を表示するには、次の問合せを実行します。

COLUMN PROPAGATION_NAME HEADING 'Propagation' FORMAT A11
COLUMN QUEUE_SCHEMA HEADING 'Queue|Owner' FORMAT A5
COLUMN QUEUE_NAME HEADING 'Queue|Name' FORMAT A5
COLUMN SUBSCRIBER_ADDRESS HEADING 'Subscriber|Address' FORMAT A15
COLUMN STARTUP_TIME HEADING 'Startup|Time' FORMAT A9
COLUMN CNUM_MSGS HEADING 'Cumulative|Messages' FORMAT 99999999
COLUMN TOTAL_DEQUEUED_MSG HEADING 'Total|Messages' FORMAT 99999999
COLUMN LAST_DEQUEUED_NUM HEADING 'Last|Dequeued|Message|Number' FORMAT 99999999

SELECT p.PROPAGATION_NAME,
s.QUEUE_SCHEMA,
s.QUEUE_NAME,
s.SUBSCRIBER_ADDRESS,
s.STARTUP_TIME,
s.CNUM_MSGS,
s.TOTAL_DEQUEUED_MSG,
s.LAST_DEQUEUED_NUM
FROM DBA_PROPAGATION p, V$BUFFERED_SUBSCRIBERS s
WHERE p.SOURCE_QUEUE_OWNER = s.QUEUE_SCHEMA AND
p.SOURCE_QUEUE_NAME  = s.QUEUE_NAME AND
p.PROPAGATION_NAME   = s.SUBSCRIBER_NAME AND
s.SUBSCRIBER_ADDRESS LIKE '%' || p.DESTINATION_DBLINK;

出力は次のようになります。

Last
Dequeued
Queue Queue Subscriber      Startup   Cumulative     Total   Message
Propagation Owner Name  Address         Time        Messages  Messages    Number
----------- ----- ----- --------------- --------- ---------- --------- ---------
PROPAGATION STRMA DB1$C "STRMADMIN"."DB 25-JUN-09      11079     11079   1525762
$_5         DMIN  APQ   1$APPQ"@DB2.EXA
MPLE.COM

注意:
同じデータベース・リンクを使用する複数の伝播によって、宛先データベースの異なるキューにメッセージが伝播される場合、この問合せによって返される統計は正確な値ではなく、概算になります。

バッファ・メッセージを受信する伝播のパフォーマンス統計の表示

この項で説明する問合せを実行すると、バッファ・メッセージを受信する各伝播が様々なタスクを実行するためにかかった時間が表示されます。各伝播でメッセージが受信され、そのメッセージが伝播の宛先キューにエンキューされます。この問合せを実行すると、具体的には次の情報が表示されます。

- メッセージの伝播元となるソース・キューの名前

- ソース・データベースの名前

- データベース・インスタンスが最後に起動されてから、メッセージをアンピクルするためにかかった時間(秒単位)。アンピクルを行うと、ネットワーク経由で送信可能な一連のバイトが、メモリー内のバッファ・メッセージに変更されます。

- データベース・インスタンスが最後に起動されてから、伝播されたメッセージのルールを評価するためにかかった時間(秒単位)

- データベース・インスタンスが最後に起動されてから、伝播の宛先キューにメッセージをエンキューするためにかかった時間(秒単位)

これらの情報を表示するには、次の問合せを実行します。

COLUMN SRC_QUEUE_NAME HEADING 'Source|Queue|Name' FORMAT A20
COLUMN SRC_DBNAME HEADING 'Source|Database' FORMAT A20
COLUMN ELAPSED_UNPICKLE_TIME HEADING 'Unpickle|Time' FORMAT 99999999.99
COLUMN ELAPSED_RULE_TIME HEADING 'Rule|Evaluation|Time' FORMAT 99999999.99
COLUMN ELAPSED_ENQUEUE_TIME HEADING 'Enqueue|Time' FORMAT 99999999.99

SELECT SRC_QUEUE_NAME,
SRC_DBNAME,
(ELAPSED_UNPICKLE_TIME / 100) ELAPSED_UNPICKLE_TIME,
(ELAPSED_RULE_TIME / 100) ELAPSED_RULE_TIME,
(ELAPSED_ENQUEUE_TIME / 100) ELAPSED_ENQUEUE_TIME
FROM V$PROPAGATION_RECEIVER;

出力は次のようになります。

Source                                                    Rule
Queue                Source              Unpickle   Evaluation      Enqueue
Name                 Database                Time         Time         Time
-------------------- -------------------- ------------ ------------ ------------
STREAMS_QUEUE        MULT2.EXAMPLE.COM           45.65         5.44        45.85
STREAMS_QUEUE        MULT3.EXAMPLE.COM           53.35         8.01        50.41

各バッファ・キューからメッセージをデキューする適用プロセスの表示

適用プロセスは、メッセージをデキューできるキュー・サブスクライバです。V$BUFFERED_SUBSCRIBERS動的パフォーマンス・ビューを問い合せると、メッセージをデキューできるすべての適用プロセスを表示できます。

この問合せはV$BUFFERED_QUEUESビューと結合され、キューの名前を表示します。また、伝播もキュー・サブスクライバであり、この問合せでは、SUBSCRIBER_ADDRESSがNULLであるサブスクライバの情報が出力されるように制限されるため、適用プロセスのみが返されます。

この項で説明する問合せを実行すると、キューからメッセージをデキューできる適用プロセスに関する次の情報が表示されます。

- 適用プロセスの名前

- キューの所有者

- キュー名

- 適用プロセスが最後に起動された時刻

- データベースが最後に起動されてから、適用プロセスによってデキューされたメッセージの累積数

- 適用プロセスが最後に起動されてから、その適用プロセスによってデキューされたメッセージの合計数

- 適用プロセスによって最後にデキューされたメッセージのメッセージ番号

これらの情報を表示するには、次の問合せを実行します。

COLUMN SUBSCRIBER_NAME HEADING 'Apply Process' FORMAT A16
COLUMN QUEUE_SCHEMA HEADING 'Queue|Owner' FORMAT A5
COLUMN QUEUE_NAME HEADING 'Queue|Name' FORMAT A5
COLUMN STARTUP_TIME HEADING 'Startup|Time' FORMAT A9
COLUMN CNUM_MSGS HEADING 'Cumulative|Messages' FORMAT 99999999
COLUMN TOTAL_DEQUEUED_MSG HEADING 'Number of|Dequeued|Messages'
FORMAT 99999999
COLUMN LAST_DEQUEUED_NUM HEADING 'Last|Dequeued|Message|Number' FORMAT 99999999

SELECT s.SUBSCRIBER_NAME,
q.QUEUE_SCHEMA,
q.QUEUE_NAME,
s.STARTUP_TIME,
s.CNUM_MSGS,
s.TOTAL_DEQUEUED_MSG,
s.LAST_DEQUEUED_NUM
FROM V$BUFFERED_QUEUES q, V$BUFFERED_SUBSCRIBERS s, DBA_APPLY a
WHERE q.QUEUE_ID = s.QUEUE_ID AND
s.SUBSCRIBER_ADDRESS IS NULL AND
s.SUBSCRIBER_NAME = a.APPLY_NAME;

出力は次のようになります。

Last
Number of  Dequeued
Queue Queue Startup   Cumulative   Dequeued   Message
Apply Process    Owner Name  Time        Messages   Messages    Number
---------------- ----- ----- --------- ---------- ---------- ---------
APPLY$_DB2_2     STRMA DB2$A 25-JUN-09      11039      11039   1509859
DMIN  PPQ

Oracle Streamsの伝播および伝播ジョブの監視

次の各項では、伝播および伝播ジョブの監視について説明します。

- 各伝播のキューおよびデータベース・リンクの表示

- 各伝播のソース・キューと宛先キューの判断

- 各伝播のルール・セットの判断

- 伝播ジョブのスケジュールに関する情報の表示

- 伝播されたメッセージの合計数とバイト数の判断

- 伝播送信者に関する情報の表示

- 伝播受信者に関する情報の表示

- 各伝播に関するセッション情報の表示

関連項目:

- 第3章「Oracle Streamsのステージングと伝播」

- 「Oracle Streamsの伝播および伝播ジョブの管理」

- 第32章「伝播のトラブルシューティング」

各伝播のキューおよびデータベース・リンクの表示

DBA_PROPAGATIONデータ・ディクショナリ・ビューを問い合せると、各伝播に関する情報を表示できます。このビューには、ローカル・データベースにソース・キューを含む各伝播に関する情報が表示されます。

この項で説明する問合せを実行すると、各伝播に関する次の情報が表示されます。

- 伝播の名前

- ソース・キュー名

- 伝播で使用されるデータベース・リンク

- 宛先キュー名

- 伝播の状態(ENABLED、DISABLEDまたはABORTED)

- 伝播がキュー・ツー・キュー伝播であるかどうか

データベース内の各伝播に関する情報を表示するには、次の問合せを実行します。

COLUMN PROPAGATION_NAME        HEADING 'Propagation|Name'   FORMAT A19
COLUMN SOURCE_QUEUE_NAME       HEADING 'Source|Queue|Name'  FORMAT A17
COLUMN DESTINATION_DBLINK      HEADING 'Database|Link'      FORMAT A9
COLUMN DESTINATION_QUEUE_NAME  HEADING 'Dest|Queue|Name'    FORMAT A15
COLUMN STATUS                  HEADING 'Status'             FORMAT A8
COLUMN QUEUE_TO_QUEUE          HEADING 'Queue-|to-|Queue?'  FORMAT A6

SELECT PROPAGATION_NAME,
SOURCE_QUEUE_NAME,
DESTINATION_DBLINK,
DESTINATION_QUEUE_NAME,
STATUS,
QUEUE_TO_QUEUE
FROM DBA_PROPAGATION;

出力は次のようになります。

Source                      Dest                     Queue-
Propagation         Queue             Database  Queue                    to-
Name                Name              Link      Name            Status   Queue?
------------------- ----------------- --------- --------------- -------- ------
PROPAGATION$_6      DA$CAPQ           DB.EXAMPL DA$APPQ         ENABLED  TRUE
E.COM

各伝播のソース・キューと宛先キューの判断

DBA_PROPAGATIONデータ・ディクショナリ・ビューを問い合せると、各伝播のソース・キューと宛先キューを判断できます。

この項で説明する問合せを実行すると、各伝播に関する次の情報が表示されます。

- 伝播の名前

- ソース・キューの所有者

- ソース・キュー名

- ソース・キューを含むデータベース

- 宛先キューの所有者

- 宛先キュー名

- 宛先キューを含むデータベース

データベース内の各伝播に関する情報を表示するには、次の問合せを実行します。

COLUMN PROPAGATION_NAME HEADING 'Propagation|Name' FORMAT A20
COLUMN SOURCE_QUEUE_OWNER HEADING 'Source|Queue|Owner' FORMAT A10
COLUMN 'Source Queue' HEADING 'Source|Queue' FORMAT A15
COLUMN DESTINATION_QUEUE_OWNER HEADING 'Dest|Queue|Owner'   FORMAT A10
COLUMN 'Destination Queue' HEADING 'Destination|Queue' FORMAT A15

SELECT p.PROPAGATION_NAME,
p.SOURCE_QUEUE_OWNER,
p.SOURCE_QUEUE_NAME ||'@'||
g.GLOBAL_NAME "Source Queue",
p.DESTINATION_QUEUE_OWNER,
p.DESTINATION_QUEUE_NAME ||'@'||
p.DESTINATION_DBLINK "Destination Queue"
FROM DBA_PROPAGATION p, GLOBAL_NAME g;

出力は次のようになります。

Source                     Dest
Propagation          Queue      Source          Queue      Destination
Name                 Owner      Queue           Owner      Queue
-------------------- ---------- --------------- ---------- ---------------
PROPAGATION$_6       STRMADMIN  DA$CAPQ@DA.EXAM STRMADMIN  DA$APPQ@DB.EXAM
PLE.COM                    PLE.COM

各伝播のルール・セットの判断

この項で説明する問合せを実行すると、各伝播に関する次の情報が表示されます。

- 伝播の名前

- 伝播のポジティブ・ルール・セットの所有者

- 伝播で使用されるポジティブ・ルール・セットの名前

- 伝播で使用されるネガティブ・ルール・セットの所有者

- 伝播で使用されるネガティブ・ルール・セットの名前

データベース内の各伝播に関する一般情報を表示するには、次の問合せを実行します。

COLUMN PROPAGATION_NAME HEADING 'Propagation|Name' FORMAT A20
COLUMN RULE_SET_OWNER HEADING 'Positive|Rule Set|Owner' FORMAT A10
COLUMN RULE_SET_NAME HEADING 'Positive Rule|Set Name' FORMAT A15
COLUMN NEGATIVE_RULE_SET_OWNER HEADING 'Negative|Rule Set|Owner' FORMAT A10
COLUMN NEGATIVE_RULE_SET_NAME HEADING 'Negative Rule|Set Name' FORMAT A15

SELECT PROPAGATION_NAME,
RULE_SET_OWNER,
RULE_SET_NAME,
NEGATIVE_RULE_SET_OWNER,
NEGATIVE_RULE_SET_NAME
FROM DBA_PROPAGATION;

出力は次のようになります。

Positive                   Negative
Propagation          Rule Set   Positive Rule   Rule Set   Negative Rule
Name                 Owner      Set Name        Owner      Set Name
-------------------- ---------- --------------- ---------- ---------------
PROPAGATION$_6       STRMADMIN  RULESET$_7      STRMADMIN  RULESET$_9

伝播ジョブのスケジュールに関する情報の表示

この項で説明する問合せを実行すると、データベースの伝播で使用される各伝播ジョブの伝播スケジュールに関して次の情報が表示されます。

- 伝播の名前

- 伝播ジョブの待機時間。これは、継続期間中にキューにある他のすべてのメッセージが関連した宛先に伝播された場合に、新規メッセージを伝播するための最大待機時間です。

- 伝播ジョブが有効化されているかどうか

- 最後にスケジュールを実行したプロセスの名前

- スケジュールの実行の連続失敗回数(該当する場合)
16回連続して失敗すると、伝播ジョブは自動的に中断されます。

- 伝播がキュー・ツー・キューであるか、キュー・ツーdblinkであるか

- 前回伝播の実行が失敗したときのエラー・メッセージ・テキスト

ソース・キューを含むデータベースで、次の問合せを実行します。

COLUMN PROPAGATION_NAME HEADING 'Propagation' FORMAT A15
COLUMN LATENCY HEADING 'Latency|in Seconds' FORMAT 99999
COLUMN SCHEDULE_DISABLED HEADING 'Status' FORMAT A8
COLUMN PROCESS_NAME HEADING 'Process' FORMAT A8
COLUMN FAILURES HEADING 'Failures' FORMAT 999
COLUMN QUEUE_TO_QUEUE HEADING 'Queue|to|Queue'
COLUMN LAST_ERROR_MSG HEADING 'Last Error|Message' FORMAT A15

SELECT p.PROPAGATION_NAME,
s.LATENCY,
DECODE(s.SCHEDULE_DISABLED,
'Y', 'Disabled',
'N', 'Enabled') SCHEDULE_DISABLED,
s.PROCESS_NAME,
s.FAILURES,
p.QUEUE_TO_QUEUE,
s.LAST_ERROR_MSG
FROM DBA_QUEUE_SCHEDULES s, DBA_PROPAGATION p
WHERE s.MESSAGE_DELIVERY_MODE = 'BUFFERED'
AND s.DESTINATION LIKE '%' || p.DESTINATION_DBLINK
AND s.SCHEMA = p.SOURCE_QUEUE_OWNER
AND s.QNAME  = p.SOURCE_QUEUE_NAME
ORDER BY PROPAGATION_NAME;

出力は次のようになります。

Queue
Latency                            to     Last Error
Propagation     in Seconds Status   Process  Failures Queue  Message
--------------- ---------- -------- -------- -------- ------ ---------------
PROPAGATION$_6          19 Enabled  CS00            0 TRUE

関連項目:

- Oracle Streamsの伝播ジョブのデフォルト伝播スケジュールの詳細は、「伝播スケジュールとOracle Streamsの伝播」を参照

- 「キュー・ツー・キュー伝播」

- 伝播ジョブが無効化されている場合は、「伝播が有効かどうか」を参照

- DBA_QUEUE_SCHEDULESデータ・ディクショナリ・ビューの詳細は、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドおよびOracle Databaseリファレンスを参照

伝播されたメッセージの合計数とバイト数の判断

伝播は、キュー・ツー・キューまたはキュー・ツー・データベース・リンク(キュー・ツーdblink)が可能です。キュー・ツー・キュー伝播は、独自の排他的な伝播ジョブを使用してメッセージをソース・キューから宛先キューに伝播します。各伝播ジョブには独自の伝播スケジュールがあるため、各キュー・ツー・キュー伝播は個別に管理することができます。同じデータベース・リンクを共有するすべてのキュー・ツーdblink伝播には、1つの伝播スケジュールがあります。

この項で説明する問合せを実行すると、各伝播に関する次の情報が表示されます。

- 伝播の名前

- 伝播スケジュールを実行するシステムによって消費された合計時間

- 伝播スケジュールによって伝播されたメッセージの合計数

- 伝播スケジュールによって伝播された合計バイト数

次の問合せを実行すると、ソース・キューがローカル・データベースに含まれる伝播ごとにこの情報が表示されます。

COLUMN PROPAGATION_NAME HEADING 'Propagation|Name' FORMAT A20
COLUMN TOTAL_TIME HEADING 'Total Time|Executing|in Seconds' FORMAT 999999
COLUMN TOTAL_NUMBER HEADING 'Total Messages|Propagated' FORMAT 999999999
COLUMN TOTAL_BYTES HEADING 'Total Bytes|Propagated' FORMAT 9999999999999

SELECT p.PROPAGATION_NAME, s.TOTAL_TIME, s.TOTAL_NUMBER, s.TOTAL_BYTES
FROM DBA_QUEUE_SCHEDULES s, DBA_PROPAGATION p
WHERE s.DESTINATION LIKE '%' || p.DESTINATION_DBLINK
AND s.SCHEMA = p.SOURCE_QUEUE_OWNER
AND s.QNAME  = p.SOURCE_QUEUE_NAME
AND s.MESSAGE_DELIVERY_MODE = 'BUFFERED';

出力は次のようになります。

Total Time
Propagation           Executing Total Messages    Total Bytes
Name                 in Seconds     Propagated     Propagated
-------------------- ---------- -------------- --------------
PROPAGATION$_6                0         432615       94751013

関連項目:
DBA_QUEUE_SCHEDULESデータ・ディクショナリ・ビューの詳細は、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドおよびOracle Databaseリファレンスを参照

伝播送信者に関する情報の表示

伝播送信者は、メッセージをソース・キューから宛先キューに伝播します。

この項で説明する問合せを実行すると、データベース内の各伝播送信者に関する次の情報が表示されます。

- 伝播の名前

- 伝播送信者のセッション識別子

- 伝播送信者のセッションのシリアル番号

- 伝播送信者のオペレーティング・システムのプロセス識別番号

- 伝播送信者の状態

取得と適用の複合による最適化で、取得プロセスは伝播送信者として機能し、伝播受信者にメッセージを直接送信します。伝播が取得と適用の複合による最適化の一部である場合は、この問合せによって、取得プロセスのセッションID、セッションのシリアル番号、オペレーティング・システムのプロセスIDおよび状態が表示されます。

伝播が取得と適用の複合による最適化の一部でない場合は、この問合せによって、伝播ジョブのセッションID、セッションのシリアル番号、オペレーティング・システムのプロセスIDおよび状態が表示されます。

この情報を表示するには、次の問合せを実行します。

COLUMN PROPAGATION_NAME HEADING 'Propagation|Name' FORMAT A11
COLUMN SESSION_ID HEADING 'Session ID' FORMAT 9999
COLUMN SERIAL# HEADING 'Session|Serial Number' FORMAT 9999
COLUMN SPID HEADING 'Operating System|Process ID' FORMAT A24
COLUMN STATE HEADING 'State' FORMAT A16

SELECT p.PROPAGATION_NAME,
s.SESSION_ID,
s.SERIAL#,
s.SPID,
s.STATE
FROM DBA_PROPAGATION p, V$PROPAGATION_SENDER s
WHERE p.SOURCE_QUEUE_OWNER      = s.QUEUE_SCHEMA AND
p.SOURCE_QUEUE_NAME       = s.QUEUE_NAME AND
p.DESTINATION_QUEUE_OWNER = s.DST_QUEUE_SCHEMA AND
p.DESTINATION_QUEUE_NAME  = s.DST_QUEUE_NAME;

出力は次のようになります。

Propagation                  Session Operating System
Name        Session ID Serial Number Process ID               State
----------- ---------- ------------- ------------------------ ----------------
PROPAGATION         61            17 21145                    Waiting on empty
$_6                                                            queue

注意:
V$PROPAGATION_SENDERビューのSCHEDULE_STATUS列にSCHEDULE OPTIMIZEDと表示された場合は、伝播が取得と適用の複合による最適化の一部であることを意味します。

関連項目:
第12章「取得と適用の複合による最適化」

伝播受信者に関する情報の表示

伝播受信者は、伝播送信者から送信されたメッセージを宛先キューにエンキューします。この項で説明する問合せを実行すると、データベース内の各伝播受信者に関する次の情報が表示されます。

- 伝播の名前

- 伝播受信者のセッションID

- 伝播受信者のセッションのシリアル番号

- 伝播受信者のオペレーティング・システムのプロセス識別番号

- 伝播受信者の状態

この情報を表示するには、次の問合せを実行します。

COLUMN PROPAGATION_NAME HEADING 'Propagation|Name' FORMAT A15
COLUMN SESSION_ID HEADING 'Session ID' FORMAT 999999
COLUMN SERIAL# HEADING 'Session|Serial|Number' FORMAT 999999
COLUMN SPID HEADING 'Operating|System|Process ID' FORMAT 999999
COLUMN STATE HEADING 'State' FORMAT A16

SELECT PROPAGATION_NAME,
SESSION_ID,
SERIAL#,
SPID,
STATE
FROM V$PROPAGATION_RECEIVER;

出力は次のようになります。

Session Operating
Propagation                 Serial System
Name            Session ID  Number Process ID               State
--------------- ---------- ------- ------------------------ ----------------
PROPAGATION$_5          60       5 21050                    Waiting for mess
age from propaga
tion sender

各伝播に関するセッション情報の表示

この項で説明する問合せを実行すると、データベースの伝播に関連付けられている各セッションに関して次のセッション情報が表示されます。

- Oracle Streamsコンポーネント

- セッション識別子

- シリアル番号

- オペレーション・システムのプロセス識別番号

- 伝播送信者および伝播受信者のプロセスのプロセス名

データベース内の各伝播に関する情報を表示するには、次の問合せを実行します。

COLUMN ACTION HEADING 'Streams Component' FORMAT A28
COLUMN SID HEADING 'Session ID' FORMAT 99999
COLUMN SERIAL# HEADING 'Session|Serial|Number' FORMAT 9999999
COLUMN PROCESS HEADING 'Operating System|Process Number' FORMAT A20
COLUMN PROCESS_NAME HEADING 'Process|Names' FORMAT A7

SELECT /*+PARAM('_module_action_old_length',0)*/ ACTION,
SID,
SERIAL#,
PROCESS,
SUBSTR(PROGRAM,INSTR(PROGRAM,'(')+1,4) PROCESS_NAME
FROM V$SESSION
WHERE MODULE ='Streams' AND
ACTION LIKE '%Propagation%';

出力は次のようになります。

Session
Serial Operating System     Process
Streams Component            Session ID   Number Process Number       Names
---------------------------- ---------- -------- -------------------- -------
APPLY$_DB_3 - Propagation Re         60        5 21048                TNS
ceiver CCA

PROPAGATION$_6 - Propagation         61       17 21145                CS00
Sender CCA

Streamsコンポーネントの出力例にあるCCAは、伝播が取得と適用の複合による最適化の一部であることを示します。TNSというプロセス名は、伝播受信者が取得プロセスによってリモートから開始されたことを示します。

関連項目:
第12章「取得と適用の複合による最適化」

26 Oracle Streams適用プロセスの監視

次の各項では、Oracle Streamsの適用プロセスの監視について説明します。

- 各適用プロセスのキュー、ルール・セットおよび状態の確認

- 各適用プロセスに関する一般情報の表示

- 各適用プロセスのパラメータ設定の表示

- 適用ハンドラの情報の表示

- 各適用プロセスに関するセッション情報の表示

- 各適用プロセスのリーダー・サーバーに関する情報の表示

- 各適用プロセスによってオーバーフローしたトランザクションおよびメッセージの監視

- メッセージが取得されてからデキューされるまでの待機時間の確認

- 各コーディネータ・プロセスに関する一般情報の表示

- 受信および適用されたトランザクションに関する情報の表示

- 各適用プロセスのメッセージが取得されてから適用されるまでの待機時間の確認

- 各適用プロセスの適用サーバーに関する情報の表示

- 適用プロセスの有効な適用並列性の表示

- 適用時に宛先キューを指定するルールの表示

- 適用時に実行しないことを指定するルールの表示

- 取得と適用の複合を使用する適用プロセスの判別

- 宛先データベースで指定された代替キー列の表示

- 仮想依存性定義の監視

- 適用エラーのチェック

- 適用エラーの詳細情報の表示

注意:
Oracle Enterprise ManagerのOracle Streamsツールも、Oracle Streams環境を監視するための優れた手段です。詳細は、Oracle Database 2日でデータ・レプリケーションおよび統合ガイドおよびOracle Streamsツールのオンライン・ヘルプを参照してください。

関連項目:

- 第4章「Oracle Streams情報コンシューム」

- 第17章「Oracle Streams情報コンシュームの管理」

- 第33章「適用のトラブルシューティング」

- この章で説明するデータ・ディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照

各適用プロセスのキュー、ルール・セットおよび状態の確認

この項で説明する問合せを実行すると、データベース内の各適用プロセスに関する次の情報を確認できます。

- 適用プロセスの名前。

- 適用プロセスで使用されるキューの名前

- 適用プロセスで使用されるポジティブ・ルール・セットの名前

- 適用プロセスで使用されるネガティブ・ルール・セットの名前

- 適用プロセスの状態(ENABLED、DISABLEDまたはABORTED)

データベース内の各適用プロセスに関する前述の一般情報を表示するには、次の問合せを実行します。

COLUMN APPLY_NAME HEADING 'Apply|Process|Name' FORMAT A15
COLUMN QUEUE_NAME HEADING 'Apply|Process|Queue' FORMAT A15
COLUMN RULE_SET_NAME HEADING 'Positive|Rule Set' FORMAT A15
COLUMN NEGATIVE_RULE_SET_NAME HEADING 'Negative|Rule Set' FORMAT A15
COLUMN STATUS HEADING 'Apply|Process|Status' FORMAT A15

SELECT APPLY_NAME,
QUEUE_NAME,
RULE_SET_NAME,
NEGATIVE_RULE_SET_NAME,
STATUS
FROM DBA_APPLY;

出力は次のようになります。

Apply           Apply                                           Apply
Process         Process         Positive        Negative        Process
Name            Queue           Rule Set        Rule Set        Status
--------------- --------------- --------------- --------------- ---------------
STRM01_APPLY    STREAMS_QUEUE   RULESET$_36                     ENABLED
APPLY_EMP       STREAMS_QUEUE   RULESET$_16                     DISABLED
APPLY           STREAMS_QUEUE   RULESET$_21     RULESET$_23     ENABLED

適用プロセスの状態がABORTEDの場合、DBA_APPLYデータ・ディクショナリ・ビューのERROR_NUMBERおよびERROR_MESSAGE列を問い合せてエラーを特定できます。これらの列は、適用プロセスが強制終了された場合または適用プロセスが制限値に達して無効になった場合に移入されます。適用プロセスを再起動すると、これらの列は消去されます。

注意:
DBA_APPLYデータ・ディクショナリ・ビューのERROR_NUMBERおよびERROR_MESSAGE列は、DBA_APPLY_ERRORデータ・ディクショナリ・ビューの情報とは関連がありません。

関連項目:
適用プロセスの状態がABORTEDの場合に適用エラーの有無をチェックするには、「適用エラーのチェック」を参照

各適用プロセスに関する一般情報の表示

この項で説明する問合せを実行すると、データベース内の各適用プロセスに関する一般情報を表示できます。

- 適用プロセスの名前。

- 適用プロセスによって適用されたメッセージのタイプ。適用プロセスでは、取得LCRを適用するか、または永続LCRと永続ユーザー・メッセージを適用できます。

- 適用ユーザー。

データベース内の各適用プロセスに関する前述の一般情報を表示するには、次の問合せを実行します。

COLUMN APPLY_NAME HEADING 'Apply Process Name' FORMAT A20
COLUMN APPLY_CAPTURED HEADING 'Applies Captured LCRs?' FORMAT A22
COLUMN APPLY_USER HEADING 'Apply User' FORMAT A20

SELECT APPLY_NAME, APPLY_CAPTURED, APPLY_USER
FROM DBA_APPLY;

出力は次のようになります。

Apply Process Name   Applies Captured LCRs? Apply User
-------------------- ---------------------- --------------------
STRM01_APPLY         YES                    STRMADMIN
SYNC_APPLY           NO                     STRMADMIN

各適用プロセスのパラメータ設定の表示

次の問合せを実行すると、データベース内の適用プロセスごとの各適用プロセス・パラメータの現行の設定が表示されます。

COLUMN APPLY_NAME HEADING 'Apply Process|Name' FORMAT A15
COLUMN PARAMETER HEADING 'Parameter' FORMAT A30
COLUMN VALUE HEADING 'Value' FORMAT A22
COLUMN SET_BY_USER HEADING 'Set by|User?' FORMAT A10

SELECT APPLY_NAME,
PARAMETER,
VALUE,
SET_BY_USER
FROM DBA_APPLY_PARAMETERS;

出力は次のようになります。

Apply Process                                                         Set by
Name            Parameter                      Value                  User?
--------------- ------------------------------ ---------------------- ----------
APPLY$_DB_3     ALLOW_DUPLICATE_ROWS           N                      NO
APPLY$_DB_3     APPLY_SEQUENCE_NEXTVAL         N                      NO
APPLY$_DB_3     COMMIT_SERIALIZATION           DEPENDENT_TRANSACTIONS NO
APPLY$_DB_3     COMPARE_KEY_ONLY               N                      NO
APPLY$_DB_3     DISABLE_ON_ERROR               Y                      NO
APPLY$_DB_3     DISABLE_ON_LIMIT               N                      NO
APPLY$_DB_3     GROUPTRANSOPS                  250                    NO
APPLY$_DB_3     IGNORE_TRANSACTION                                    NO
APPLY$_DB_3     MAXIMUM_SCN                    INFINITE               NO
APPLY$_DB_3     MAX_SGA_SIZE                   INFINITE               NO
APPLY$_DB_3     PARALLELISM                    4                      NO
APPLY$_DB_3     PRESERVE_ENCRYPTION            Y                      NO
APPLY$_DB_3     RTRIM_ON_IMPLICIT_CONVERSION   Y                      NO
APPLY$_DB_3     STARTUP_SECONDS                0                      NO
APPLY$_DB_3     TIME_LIMIT                     INFINITE               NO
APPLY$_DB_3     TRACE_LEVEL                    0                      NO
APPLY$_DB_3     TRANSACTION_LIMIT              INFINITE               NO
APPLY$_DB_3     TXN_AGE_SPILL_THRESHOLD        900                    NO
APPLY$_DB_3     TXN_LCR_SPILL_THRESHOLD        10000                  NO
APPLY$_DB_3     WRITE_ALERT_LOG                Y                      NO

注意:
パラメータのSet by user列がNOの場合、そのパラメータはデフォルト値に設定されます。パラメータのSet by user列がYESの場合、パラメータはユーザーによって設定され、デフォルト値に設定されることもされないこともあります。

関連項目:

- 「適用プロセス・パラメータ」

- 「適用プロセス・パラメータの設定」

- Oracle Database 2日でデータ・レプリケーションおよび統合ガイド

- 適用プロセス・パラメータの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のDBMS_APPLY_ADM.SET_PARAMETERプロシージャに関する項を参照

適用ハンドラの情報の表示

この項では、適用プロセスの適用ハンドラに関する情報を表示する手順について説明します。

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

- DMLハンドラに関する情報の表示

- 各適用プロセスのDDLハンドラの表示

- ローカル適用プロセスのすべてのエラー・ハンドラの表示

- 各適用プロセスのメッセージ・ハンドラの表示

- 各適用プロセスのプリコミット・ハンドラの表示

DMLハンドラに関する情報の表示

次の各項では、DMLハンドラの情報を表示する手順について説明します。

- すべてのDMLハンドラに関する情報の表示

- 文DMLハンドラに関する情報の表示

- プロシージャDMLハンドラに関する情報の表示

関連項目:

- 「DMLハンドラ」

- 「DMLハンドラの管理」

すべてのDMLハンドラに関する情報の表示

データベース内のすべてのDMLハンドラ(すべての文DMLハンドラおよびすべてのプロシージャDMLハンドラを含む)に関する次の情報を表示できます。

- DMLハンドラが設定されている表の所有者および名前

- DMLハンドラが設定されている操作

- DMLハンドラの名前

- DMLハンドラのタイプ(文またはプロシージャのいずれか)

- DMLハンドラが使用されている適用プロセスの名前

データベース内の各DMLハンドラに関する前述の情報を表示するには、次の問合せを実行します。

COLUMN OBJECT_OWNER HEADING 'Table|Owner' FORMAT A7
COLUMN OBJECT_NAME HEADING 'Table Name' FORMAT A11
COLUMN OPERATION_NAME HEADING 'Operation' FORMAT A9
COLUMN HANDLER HEADING 'DML Handler' FORMAT A13
COLUMN HANDLER_TYPE HEADING 'Handler|Type' FORMAT A9
COLUMN APPLY_NAME HEADING 'Apply|Process|Name' FORMAT A15

SELECT OBJECT_OWNER,
OBJECT_NAME,
OPERATION_NAME,
NVL(USER_PROCEDURE,HANDLER_NAME) Handler,
DECODE(HANDLER_TYPE,'PROCEDURE HANDLER','PROCEDURE','STMT HANDLER',
'STATEMENT','UNKNOWN') HANDLER_TYPE,
APPLY_NAME
FROM DBA_APPLY_DML_HANDLERS
WHERE ERROR_HANDLER = 'N' AND
APPLY_DATABASE_LINK IS NULL
ORDER BY OBJECT_OWNER, OBJECT_NAME;

出力は次のようになります。

Apply
Table                                       Handler   Process
Owner   Table Name  Operation DML Handler   Type      Name
------- ----------- --------- ------------- --------- ---------------
HR      DEPARTMENTS UPDATE    "STRMADMIN"." PROCEDURE
SQL_GEN_DEP"
HR      JOBS        UPDATE    TRACK_JOBS    STATEMENT APPLY$_PROD_25
OE      ORDERS      INSERT    MODIFY_ORDERS STATEMENT APPLY$_PROD_25

strmadmin.sql_gen_depプロシージャDMLハンドラのApply Process NameがNULLであるため、このハンドラは、すべてのローカル適用プロセスに対して実行される汎用ハンドラです。

文DMLハンドラに関する情報の表示

次の各項では、データベース内の文DMLハンドラに関する情報を表示する問合せについて説明します。

- データベース内の文DMLハンドラの表示

- 各適用プロセスによって使用される文DMLハンドラの表示

- 文DMLハンドラのすべての文の表示

関連項目:

- 「文DMLハンドラ」

- 「文DMLハンドラの管理」

データベース内の文DMLハンドラの表示

データベース内の文DMLハンドラに関する次の情報を表示できます。

- 文DMLハンドラの名前

- 文DMLハンドラのコメント

- 文DMLハンドラが作成された時間

- 文DMLハンドラが最後に変更された時間

データベース内の各文DMLハンドラに関する前述の情報を表示するには、次の問合せを実行します。

COLUMN HANDLER_NAME HEADING 'Handler Name' FORMAT A15
COLUMN HANDLER_COMMENT HEADING 'Comment' FORMAT A35
COLUMN CREATION_TIME HEADING 'Creation|Time' FORMAT A10
COLUMN MODIFICATION_TIME HEADING 'Last|Change|Time' FORMAT A10

SELECT HANDLER_NAME,
HANDLER_COMMENT,
CREATION_TIME,
MODIFICATION_TIME
FROM DBA_STREAMS_STMT_HANDLERS
ORDER BY HANDLER_NAME;

出力は次のようになります。

Last
Creation   Change
Handler Name    Comment                             Time       Time
--------------- ----------------------------------- ---------- ----------
MODIFY_ORDERS   Modifies inserts into the orders ta 12-MAR-09
ble                                 07.59.56.9
46180 AM

TRACK_JOBS      Tracks updates to the jobs table    11-MAR-09
10.47.52.7
76489 AM

この出力でのLast Change Timeが示すようにMODIFICATION_TIMEがNULLの場合、ハンドラが作成以降に変更されていないことを示します。

各適用プロセスによって使用される文DMLハンドラの表示

宛先データベースでDBMS_APPLY_ADMパッケージのADD_STMT_HANDLERプロシージャを使用して文DMLハンドラを指定する場合、特定の適用プロセスに対してハンドラが実行されるように指定するか、または変更をローカルに適用するデータベース内のすべての適用プロセスに対して実行される汎用ハンドラとしてハンドラが実行されるように指定することができます。表の操作に対する文DMLハンドラが特定の適用プロセスによって使用され、かつ別の文DMLハンドラが同じ表の同じ操作に対する汎用ハンドラとして存在する場合、適用プロセスでその表への操作を含む行LCRがデキューされたときには、両方のハンドラが呼び出されます。各文DMLハンドラによって元の行LCRが受け取られ、文DMLハンドラは任意の順序で実行できます。

データベース内の適用プロセスによって使用される文DMLハンドラに関する次の情報を表示できます。

- 文DMLハンドラが設定されている表の所有者および名前

- 文DMLハンドラが設定されている操作

- 文DMLハンドラが使用されている適用プロセスの名前

- 文DMLハンドラの名前

各適用プロセスによって使用される文DMLハンドラに関する前述の情報を表示するには、次の問合せを実行します。

COLUMN OBJECT_OWNER HEADING 'Table|Owner' FORMAT A10
COLUMN OBJECT_NAME HEADING 'Table Name' FORMAT A10
COLUMN OPERATION_NAME HEADING 'Operation' FORMAT A9
COLUMN APPLY_NAME HEADING 'Apply Process|Name' FORMAT A15
COLUMN HANDLER_NAME HEADING 'Statement DML|Handler Name' FORMAT A30

SELECT OBJECT_OWNER,
OBJECT_NAME,
OPERATION_NAME,
APPLY_NAME,
HANDLER_NAME
FROM DBA_APPLY_DML_HANDLERS
WHERE HANDLER_TYPE='STMT HANDLER'
ORDER BY OBJECT_OWNER, OBJECT_NAME, OPERATION_NAME;

出力は次のようになります。

Table                           Apply Process   Statement DML
Owner      Table Name Operation Name            Handler Name
---------- ---------- --------- --------------- ------------------------------
HR         JOBS       UPDATE    APPLY$_PROD_25  TRACK_JOBS
OE         ORDERS     INSERT    APPLY$_PROD_25  MODIFY_ORDERS

文DMLハンドラのApply Process NameがNULLである場合、このハンドラは、すべてのローカル適用プロセスに対して実行される汎用ハンドラです。

文DMLハンドラのすべての文の表示

この項で説明する問合せを実行すると、データベース内の文DMLハンドラの文に関する次の情報が表示されます。

- それぞれの文を含む文DMLハンドラの名前

- それぞれの文の実行順序

- それぞれの文のテキスト

これらの情報を表示するには、次の問合せを実行します。

COLUMN HANDLER_NAME HEADING 'Statement|Handler' FORMAT A15
COLUMN EXECUTION_SEQUENCE HEADING 'Execution|Sequence' FORMAT 999999
COLUMN STATEMENT HEADING 'Statement' FORMAT A50

SET LONG  8000
SET PAGES 8000
SELECT HANDLER_NAME,
EXECUTION_SEQUENCE,
STATEMENT
FROM DBA_STREAMS_STMTS
ORDER BY HANDLER_NAME, EXECUTION_SEQUENCE;

出力は次のようになります。

Statement       Execution
Handler          Sequence Statement
--------------- --------- --------------------------------------------------
MODIFY_ORDERS           1 INSERT INTO oe.orders(
order_id,
order_date,
order_mode,
customer_id,
order_status,
order_total,
sales_rep_id,
promotion_id)
VALUES(
:new.order_id,
:new.order_date,
:new.order_mode,
:new.customer_id,
DECODE(:new.order_status, 1, 2, :new.
order_status),
:new.order_total,
:new.sales_rep_id,
:new.promotion_id)

TRACK_JOBS             10 :lcr.execute TRUE
TRACK_JOBS             20 INSERT INTO hr.track_jobs(
change_id,
job_id,
job_title,
min_salary_old,
min_salary_new,
max_salary_old,
max_salary_new,
timestamp)
VALUES(
hr.track_jobs_seq.NEXTVAL,
:new.job_id,
:new.job_title,
:old.min_salary,
:new.min_salary,
:old.max_salary,
:new.max_salary,
:source_time)

プロシージャDMLハンドラに関する情報の表示

宛先データベースでDBMS_APPLY_ADMパッケージのSET_DML_HANDLERプロシージャを使用してローカルのプロシージャDMLハンドラを指定する場合、必要に応じて、特定の適用プロセスに対してハンドラが実行されるように指定するか、または変更をローカルに適用するデータベース内のすべての適用プロセスに対して実行される汎用ハンドラとしてハンドラが実行されるように指定することができます。特定のプロシージャDMLハンドラは、汎用プロシージャDMLハンドラより優先されます。DMLハンドラは、特定の表への指定した操作に対して実行されます。

データベース内の各適用プロセスに対するプロシージャDMLハンドラを表示するには、次の問合せを実行します。

COLUMN OBJECT_OWNER HEADING 'Table|Owner' FORMAT A11
COLUMN OBJECT_NAME HEADING 'Table Name' FORMAT A15
COLUMN OPERATION_NAME HEADING 'Operation' FORMAT A9
COLUMN USER_PROCEDURE HEADING 'Handler Procedure' FORMAT A25
COLUMN APPLY_NAME HEADING 'Apply Process|Name' FORMAT A15

SELECT OBJECT_OWNER,
OBJECT_NAME,
OPERATION_NAME,
USER_PROCEDURE,
APPLY_NAME
FROM DBA_APPLY_DML_HANDLERS
WHERE ERROR_HANDLER = 'N' AND
USER_PROCEDURE IS NOT NULL
ORDER BY OBJECT_OWNER, OBJECT_NAME;

出力は次のようになります。

Table                                                           Apply Process
Owner       Table Name      Operation Handler Procedure         Name
----------- --------------- --------- ------------------------- ---------------
HR          DEPARTMENTS     UPDATE    "STRMADMIN"."SQL_GEN_DEP"

strmadmin.sql_gen_depプロシージャDMLハンドラのApply Process NameがNULLであるため、このハンドラは、すべてのローカル適用プロセスに対して実行される汎用ハンドラです。

関連項目:

- 「プロシージャDMLハンドラ」

- 「プロシージャDMLハンドラの管理」

各適用プロセスのDDLハンドラの表示

データベース内の各適用プロセスに対するDDLハンドラを表示するには、次の問合せを実行します。

COLUMN APPLY_NAME HEADING 'Apply Process Name' FORMAT A20
COLUMN DDL_HANDLER HEADING 'DDL Handler' FORMAT A40

SELECT APPLY_NAME, DDL_HANDLER FROM DBA_APPLY;

出力は次のようになります。

Apply Process Name   DDL Handler
-------------------- ----------------------------------------
STREP01_APPLY        "STRMADMIN"."HISTORY_DDL"

関連項目:
「DDLハンドラの管理」

ローカル適用プロセスのすべてのエラー・ハンドラの表示

宛先データベースでDBMS_APPLY_ADMパッケージのSET_DML_HANDLERプロシージャを使用してローカルのエラー・ハンドラを指定する際、適用プロセスでエラーが発生した場合に特定の適用プロセスに対してハンドラが実行されるように指定するか、または変更をローカルに適用するデータベース内のすべての適用プロセスに対して実行される汎用ハンドラとしてハンドラが実行されるように指定することができます。特定のエラー・ハンドラは、汎用エラー・ハンドラより優先されます。エラー・ハンドラは、特定の表への指定した操作に対して実行されます。

データベース内で変更をローカルに適用する各適用プロセスに対するエラー・ハンドラを表示するには、次の問合せを実行します。

COLUMN OBJECT_OWNER HEADING 'Table|Owner' FORMAT A5
COLUMN OBJECT_NAME HEADING 'Table Name' FORMAT A10
COLUMN OPERATION_NAME HEADING 'Operation' FORMAT A10
COLUMN USER_PROCEDURE HEADING 'Handler Procedure' FORMAT A30
COLUMN APPLY_NAME HEADING 'Apply Process|Name' FORMAT A15

SELECT OBJECT_OWNER,
OBJECT_NAME,
OPERATION_NAME,
USER_PROCEDURE,
APPLY_NAME
FROM DBA_APPLY_DML_HANDLERS
WHERE ERROR_HANDLER = 'Y'
ORDER BY OBJECT_OWNER, OBJECT_NAME;

出力は次のようになります。

Table                                                      Apply Process
Owner Table Name Operation  Handler Procedure              Name
----- ---------- ---------- ------------------------------ --------------
HR    REGIONS    INSERT     "STRMADMIN"."ERRORS_PKG"."REGI
ONS_PK_ERROR"

strmadmin.errors_pkg.regions_pk_errorエラー・ハンドラのApply Process NameはNULLです。このため、このハンドラはすべてのローカル適用プロセスに対して実行される汎用ハンドラです。

関連項目:
「エラー・ハンドラの管理」

各適用プロセスのメッセージ・ハンドラの表示

データベース内の各メッセージ・ハンドラを表示するには、次の問合せを実行します。

COLUMN APPLY_NAME HEADING 'Apply Process Name' FORMAT A20
COLUMN MESSAGE_HANDLER HEADING 'Message Handler' FORMAT A20

SELECT APPLY_NAME, MESSAGE_HANDLER FROM DBA_APPLY
WHERE MESSAGE_HANDLER IS NOT NULL;

出力は次のようになります。

Apply Process Name   Message Handler
-------------------- --------------------
STRM03_APPLY         "OE"."MES_HANDLER"

関連項目:
「適用プロセスのメッセージ・ハンドラの管理」

各適用プロセスのプリコミット・ハンドラの表示

この項で説明する問合せを実行すると、データベース内の適用プロセスで使用される各プリコミット・ハンドラに関する情報を表示できます。

- 適用プロセスの名前。

- プリコミット・ハンドラの所有者および名前。

- 適用プロセスによって適用されたメッセージのタイプ。適用プロセスでは、取得LCRを適用するか、または永続LCRと永続ユーザー・メッセージを適用できます。

データベース内の各プリコミット・ハンドラに関する前述の情報を表示するには、次の問合せを実行します。

COLUMN APPLY_NAME HEADING 'Apply Process Name' FORMAT A15
COLUMN PRECOMMIT_HANDLER HEADING 'Precommit Handler' FORMAT A30
COLUMN APPLY_CAPTURED HEADING 'Applies Captured|Messages?' FORMAT A20

SELECT APPLY_NAME, PRECOMMIT_HANDLER, APPLY_CAPTURED
FROM DBA_APPLY
WHERE PRECOMMIT_HANDLER IS NOT NULL;

出力は次のようになります。

Applies Captured
Apply Process Name   Precommit Handler              Messages?
-------------------- ------------------------------ --------------------
STRM01_APPLY         "STRMADMIN"."HISTORY_COMMIT"   YES

関連項目:
「適用プロセスのプリコミット・ハンドラの管理」

各適用プロセスに関するセッション情報の表示

この項で説明する問合せを実行すると、データベース内の適用プロセスに関連付けられる各セッションに関する次のセッション情報が表示されます。

- 適用プロセスのコンポーネント

- セッション識別子

- シリアル番号

- オペレーション・システムのプロセス識別番号

- コーディネータ・プロセス、リーダー・プロセスおよび適用サーバーの各プロセス名

データベースの各取得プロセスに関する前述の情報を表示するには、次の問合せを実行します。

COLUMN ACTION HEADING 'Apply Process Component' FORMAT A30
COLUMN SID HEADING 'Session ID' FORMAT 99999
COLUMN SERIAL# HEADING 'Session|Serial|Number' FORMAT 99999999
COLUMN PROCESS HEADING 'Operating System|Process Number' FORMAT A17
COLUMN PROCESS_NAME HEADING 'Process|Names' FORMAT A7

SELECT /*+PARAM('_module_action_old_length',0)*/ ACTION,
SID,
SERIAL#,
PROCESS,
SUBSTR(PROGRAM,INSTR(PROGRAM,'(')+1,4) PROCESS_NAME
FROM V$SESSION
WHERE MODULE ='Streams' AND
ACTION LIKE '%Apply%';

出力は次のようになります。

Session
Serial Operating System  Process
Apply Process Component        Session ID    Number Process Number    Names
------------------------------ ---------- --------- ----------------- -------
APPLY$_EMDBB_3 - Apply Coordin         17      3040 9863              AP01
ator
APPLY$_EMDBB_3 - Apply Server          58     52788 9869              AS02
APPLY$_EMDBB_3 - Apply Reader          63        21 9865              AS01
APPLY$_EMDBB_3 - Apply Server          64        37 9872              AS03
APPLY$_EMDBB_3 - Apply Server          67        22 9875              AS04
APPLY$_EMDBB_3 - Apply Server          69         1 9877              AS05

関連項目:
「適用プロセスのサブコンポーネント」

各適用プロセスのリーダー・サーバーに関する情報の表示

適用プロセスのリーダー・サーバーは、キューからのメッセージをデキューします。リーダー・サーバーは、LCR間の依存性を計算してメッセージをトランザクションにアセンブルするプロセスです。リーダー・サーバーが、アセンブルしたトランザクションをコーディネータに返すと、コーディネータがアイドル状態の適用サーバーにトランザクションを割り当てます。

この項で説明する問合せを実行すると、各適用プロセスのリーダー・サーバーに関する次の情報が表示されます。

- 適用プロセスの名前

- リーダー・サーバーによってデキューされたメッセージのタイプ。適用プロセスでは、取得LCRをデキューするか、または永続LCRと永続ユーザー・メッセージをデキューできます。

- リーダー・サーバーで使用されるプロセスの名前。プロセスの名前の形式は、ASnnです(nnには文字および数字を使用できます)。

- リーダー・サーバーの現在の状態
「リーダー・サーバーの状態」を参照してください。

- 適用プロセスが最後に起動されてから、リーダー・サーバーがデキューしたメッセージの合計数。

この問合せで表示される情報は、有効になっている適用プロセスに対してのみ有効です。

次の問合せを実行すると、各適用プロセスに関する前述の情報が表示されます。

COLUMN APPLY_NAME HEADING 'Apply Process|Name' FORMAT A15
COLUMN APPLY_CAPTURED HEADING 'Dequeues Captured|Messages?' FORMAT A17
COLUMN PROCESS_NAME HEADING 'Process|Name' FORMAT A7
COLUMN STATE HEADING 'State' FORMAT A17
COLUMN TOTAL_MESSAGES_DEQUEUED HEADING 'Total Messages|Dequeued' FORMAT 99999999

SELECT r.APPLY_NAME,
ap.APPLY_CAPTURED,
SUBSTR(s.PROGRAM,INSTR(s.PROGRAM,'(')+1,4) PROCESS_NAME,
r.STATE,
r.TOTAL_MESSAGES_DEQUEUED
FROM V$STREAMS_APPLY_READER r, V$SESSION s, DBA_APPLY ap
WHERE r.SID = s.SID AND
r.SERIAL# = s.SERIAL# AND
r.APPLY_NAME = ap.APPLY_NAME;

出力は次のようになります。

Apply Process   Dequeues Captured Process                   Total Messages
Name            Messages?         Name    State                   Dequeued
--------------- ----------------- ------- ----------------- --------------
APPLY_SPOKE     YES               AS01    DEQUEUE MESSAGES              54

各適用プロセスによってオーバーフローしたトランザクションおよびメッセージの監視

txn_lcr_spill_threshold適用プロセス・パラメータがINFINITE以外の値に設定されている場合、トランザクション内のメッセージの数が指定された数を超えると、適用プロセスによって、メモリーからハード・ディスクにメッセージをオーバーフローできます。

この項で説明する最初の問合せを実行すると、メッセージがオーバーフローした適用プロセスに対して現在適用されている各トランザクションに関する次の情報が表示されます。

- 適用プロセスの名前

- メッセージがオーバーフローしたトランザクションのトランザクションID。

- トランザクションの最初のメッセージのシステム変更番号(SCN)。

- トランザクションで現在オーバーフローしているメッセージの数。

データベース内の各適用プロセスに関する前述の情報を表示するには、次の問合せを実行します。

COLUMN APPLY_NAME HEADING 'Apply Name' FORMAT A20
COLUMN 'Transaction ID' HEADING 'Transaction ID' FORMAT A15
COLUMN FIRST_SCN HEADING 'First SCN'   FORMAT 99999999
COLUMN MESSAGE_COUNT HEADING 'Message Count' FORMAT 99999999

SELECT APPLY_NAME,
XIDUSN ||'.'||
XIDSLT ||'.'||
XIDSQN "Transaction ID",
FIRST_SCN,
MESSAGE_COUNT
FROM DBA_APPLY_SPILL_TXN;

出力は次のようになります。

Apply Name           Transaction ID  First SCN Message Count
-------------------- --------------- --------- -------------
APPLY_HR             1.42.2277         2246944           100

この項で説明する次の問合せを実行すると、ローカル・データベース内の適用プロセスによってオーバーフローしたメッセージに関する次の情報が表示されます。

- 適用プロセスの名前

- 適用プロセスが最後に起動されてからオーバーフローしたメッセージの合計数。

- 適用プロセスでメッセージのオーバーフローにかかった時間(秒単位)。

データベース内の各適用プロセスに関する前述の情報を表示するには、次の問合せを実行します。

COLUMN APPLY_NAME HEADING 'Apply Name' FORMAT A15
COLUMN TOTAL_MESSAGES_SPILLED HEADING 'Total|Spilled Messages' FORMAT 99999999
COLUMN ELAPSED_SPILL_TIME HEADING 'Elapsed Time|Spilling Messages' FORMAT 99999999.99

SELECT APPLY_NAME,
TOTAL_MESSAGES_SPILLED,
(ELAPSED_SPILL_TIME/100) ELAPSED_SPILL_TIME
FROM V$STREAMS_APPLY_READER;

出力は次のようになります。

Total      Elapsed Time
Apply Name      Spilled Messages Spilling Messages
--------------- ---------------- -----------------
APPLY_HR                     100              2.67

注意:
メッセージのオーバーフローの経過時間は秒単位で表示されます。V$STREAMS_APPLY_READERビューには、経過時間はデフォルトでセンチセカンドで表示されます。センチセカンドは、100分の1秒です。この項で説明する問合せを実行すると、各経過時間が100で割られ、秒単位で表示されます。

メッセージが取得されてからデキューされるまでの待機時間の確認

この項で説明する問合せを実行すると、各適用プロセスによってデキューされた最後のメッセージに関する情報が表示されます。

- 適用プロセスの名前。

- 待機時間。取得LCRの場合、待機時間は、ソース・データベースでメッセージが作成されてから適用プロセスでデキューされるまでの時間です。他のタイプのメッセージの場合、待機時間は、ローカル・データベースでメッセージがエンキューされてから適用プロセスでデキューされるまでの時間です。

- メッセージ作成時刻。取得LCRの場合、メッセージ作成時刻は、データ操作言語(DML)またはデータ定義言語(DDL)の変更によって、ソース・データベースでメッセージに関するREDOデータが生成された時刻です。アプリケーションまたは適用プロセスによってエンキューされたメッセージの場合、メッセージ作成時刻は、メッセージが最後にエンキューされた時刻です。メッセージは、適用プロセスに到達する前に、伝播によって1回以上エンキューされることがあります。

- メッセージが適用プロセスによってデキューされた時刻。

- 適用プロセスによって最後にデキューされたメッセージのメッセージ番号。

この問合せで表示される情報は、有効になっている適用プロセスに対してのみ有効です。

次の問合せを実行すると、各適用プロセスに関する前述の情報が表示されます。

COLUMN APPLY_NAME HEADING 'Apply Process|Name' FORMAT A17
COLUMN LATENCY HEADING 'Latency|in|Seconds' FORMAT 999999
COLUMN CREATION HEADING 'Message Creation' FORMAT A17
COLUMN LAST_DEQUEUE HEADING 'Last Dequeue Time' FORMAT A20
COLUMN DEQUEUED_MESSAGE_NUMBER HEADING 'Dequeued|Message Number' FORMAT 9999999999

SELECT APPLY_NAME,
(DEQUEUE_TIME-DEQUEUED_MESSAGE_CREATE_TIME)*86400 LATENCY,
TO_CHAR(DEQUEUED_MESSAGE_CREATE_TIME,'HH24:MI:SS MM/DD/YY') CREATION,
TO_CHAR(DEQUEUE_TIME,'HH24:MI:SS MM/DD/YY') LAST_DEQUEUE,
DEQUEUED_MESSAGE_NUMBER
FROM V$STREAMS_APPLY_READER;

出力は次のようになります。

Latency
Apply Process          in                                              Dequeued
Name              Seconds Message Creation  Last Dequeue Time    Message Number
----------------- ------- ----------------- -------------------- --------------
APPLY$_STM1_14          1 15:22:15 06/13/05 15:22:16 06/13/05            502129

各コーディネータ・プロセスに関する一般情報の表示

コーディネータ・プロセスは、リーダー・サーバーからトランザクションを取得して適用サーバーに渡します。コーディネータ・プロセスの名前はAPnnです(nnはコーディネータ・プロセス番号)。

この項で説明する問合せを実行すると、各適用プロセスのコーディネータ・プロセスに関する次の情報が表示されます。

- 適用プロセスの名前。

- プロセスの名前APnn内のコーディネータの番号(nnには文字および数字を使用できます)。

- コーディネータのセッションのセッション識別子。

- コーディネータのセッションのシリアル番号。

- コーディネータの現在の状態
「コーディネータ・プロセスの状態」を参照してください。

この問合せで表示される情報は、有効になっている適用プロセスに対してのみ有効です。

次の問合せを実行すると、各適用プロセスに関する前述の情報が表示されます。

COLUMN APPLY_NAME HEADING 'Apply Process|Name' FORMAT A17
COLUMN PROCESS_NAME HEADING 'Coordinator|Process|Name' FORMAT A11
COLUMN SID HEADING 'Session|ID' FORMAT 9999
COLUMN SERIAL# HEADING 'Session|Serial|Number' FORMAT 9999
COLUMN STATE HEADING 'State' FORMAT A21

SELECT c.APPLY_NAME,
SUBSTR(s.PROGRAM,INSTR(s.PROGRAM,'(')+1,4) PROCESS_NAME,
c.SID,
c.SERIAL#,
c.STATE
FROM V$STREAMS_APPLY_COORDINATOR c, V$SESSION s
WHERE c.SID = s.SID AND
c.SERIAL# = s.SERIAL#;

出力は次のようになります。

Coordinator         Session
Apply Process     Process     Session  Serial
Name              Name             ID  Number State
----------------- ----------- ------- ------- ---------------------
APPLY_SPOKE       AP01            944       5 IDLE

受信および適用されたトランザクションに関する情報の表示

この項で説明する問合せを実行すると、各適用プロセスによって受信および適用されたトランザクションと現在適用されているトランザクションに関する次の情報が表示されます。

- 適用プロセスの名前。

- 適用プロセスが最後に起動されてから、コーディネータ・プロセスが受信したトランザクションの合計数。

- 適用プロセスが最後に起動されてから、適用プロセスによって正常に適用されたトランザクションの合計数。

- 適用プロセスが最後に起動されてから、適用プロセスによって適用され、適用エラーが発生したトランザクションの合計数。

- 適用プロセスによって現在適用されているトランザクションの合計数。

- コーディネータ・プロセスによって受信されたが、適用プロセスに割り当てられていない完全なトランザクションの合計数。

- 適用プロセスが最後に起動されてから、適用プロセスによってトランザクションがすでに適用されていたため、コーディネータ・プロセスが受信しても無視したトランザクションの合計数。

この問合せで表示される情報は、有効になっている適用プロセスに対してのみ有効です。

たとえば、適用プロセスapplyに関する前述の情報を表示するには、次の問合せを実行します。

COLUMN APPLY_NAME HEADING 'Apply Process Name' FORMAT A20
COLUMN TOTAL_RECEIVED HEADING 'Total|Trans|Received' FORMAT 99999999
COLUMN TOTAL_APPLIED HEADING 'Total|Trans|Applied' FORMAT 99999999
COLUMN TOTAL_ERRORS HEADING 'Total|Apply|Errors' FORMAT 9999
COLUMN BEING_APPLIED HEADING 'Total|Trans Being|Applied' FORMAT 99999999
COLUMN UNASSIGNED_COMPLETE_TXNS HEADING 'Total|Unnasigned|Trans' FORMAT 99999999
COLUMN TOTAL_IGNORED HEADING 'Total|Trans|Ignored' FORMAT 99999999

SELECT APPLY_NAME,
TOTAL_RECEIVED,
TOTAL_APPLIED,
TOTAL_ERRORS,
(TOTAL_ASSIGNED - (TOTAL_ROLLBACKS + TOTAL_APPLIED)) BEING_APPLIED,
UNASSIGNED_COMPLETE_TXNS,
TOTAL_IGNORED
FROM V$STREAMS_APPLY_COORDINATOR;

出力は次のようになります。

Total     Total  Total       Total      Total     Total
Trans     Trans  Apply Trans Being Unnasigned     Trans
Apply Process Name    Received   Applied Errors     Applied      Trans   Ignored
-------------------- --------- --------- ------ ----------- ---------- ---------
APPLY_FROM_MULT1            81        73      2           6          4         0
APPLY_FROM_MULT2           114        96      0          14          7         4

各適用プロセスのメッセージが取得されてから適用されるまでの待機時間の確認

この項では、特定のメッセージに関して取得から適用までの待機時間を表示する2つの異なる問合せについて説明します。つまり、これらの問合せでは、ソース・データベースでメッセージが作成されてから、適用プロセスで適用されるまでの時間が表示されます。一方の問合せでは、V$STREAMS_APPLY_COORDINATOR動的パフォーマンス・ビューが使用されます。もう一方の問合せでは、DBA_APPLY_PROGRESS静的データ・ディクショナリ・ビューが使用されます。

これらの2つの問合せは、次の点で異なっています。

- V$STREAMS_APPLY_COORDINATORビューに対する問合せは、取得LCRまたは永続LCRが取得されてから適用されるまでの待機時間を確認する場合に使用できます。一方、DBA_APPLY_PROGRESSビューに対する問合せは、取得LCRの結果のみを戻します。

- V$STREAMS_APPLY_COORDINATORビューに対する問合せを実行する場合は、適用プロセスが有効になっている必要がありますが、DBA_APPLY_PROGRESSビューに対する問合せは、適用プロセスが有効または無効のいずれの場合でも実行できます。したがって、適用プロセスが現在無効になっており、取得プロセスによって変更の取得が実行される場合は、DBA_APPLY_PROGRESSビューに対する問合せを実行して、取得から適用までの待機時間を確認します。

- V$STREAMS_APPLY_COORDINATORビューに対する問合せでは、DBA_APPLY_PROGRESSビューに対する問合せより新しいトランザクションの待機時間を表示できます。

いずれの問合せでも、各適用プロセスによって適用されたメッセージに関する次の情報が表示されます。

- 適用プロセスの名前。

- メッセージが取得されてから適用されるまでの待機時間。

- メッセージ作成時刻。
取得LCRの場合、メッセージ作成時刻は、データ操作言語(DML)またはデータ定義言語(DDL)の変更によって、ソース・データベースでメッセージに関するREDOデータが生成された時刻です。

永続LCRの場合、メッセージ作成時刻は、LCRが作成された時刻です。

- メッセージが適用プロセスによって適用された時刻。

- メッセージのメッセージ番号。

注意:
これらの問合せは、永続ユーザー・メッセージには関連していません。

待機時間に関するV$STREAMS_APPLY_COORDINATORの問合せの例

V$STREAMS_APPLY_COORDINATORビューを使用して次の問合せを実行すると、各適用プロセスの取得LCRまたは永続LCRの取得から適用までの待機時間が表示されます。

COLUMN APPLY_NAME HEADING 'Apply Process|Name' FORMAT A13
COLUMN 'Latency in Seconds' FORMAT 999999
COLUMN 'Message Creation' FORMAT A17
COLUMN 'Apply Time' FORMAT A17
COLUMN HWM_MESSAGE_NUMBER HEADING 'Applied|Message|Number' FORMAT 9999999999

SELECT APPLY_NAME,
(HWM_TIME-HWM_MESSAGE_CREATE_TIME)*86400 "Latency in Seconds",
TO_CHAR(HWM_MESSAGE_CREATE_TIME,'HH24:MI:SS MM/DD/YY')
"Message Creation",
TO_CHAR(HWM_TIME,'HH24:MI:SS MM/DD/YY') "Apply Time",
HWM_MESSAGE_NUMBER
FROM V$STREAMS_APPLY_COORDINATOR;

出力は次のようになります。

Apply Process                                                            Message
Name          Latency in Seconds Message Creation  Apply Time             Number
------------- ------------------ ----------------- ----------------- -----------
APPLY$_DA_2                    2 13:00:10 07/14/10 13:00:12 07/14/10      672733

待機時間に関するDBA_APPLY_PROGRESSの問合せの例

DBA_APPLY_PROGRESSビューを使用して次の問合せを実行すると、各適用プロセスの取得LCRの取得から適用までの待機時間が表示されます。

COLUMN APPLY_NAME HEADING 'Apply Process|Name' FORMAT A17
COLUMN 'Latency in Seconds' FORMAT 999999
COLUMN 'Message Creation' FORMAT A17
COLUMN 'Apply Time' FORMAT A17
COLUMN APPLIED_MESSAGE_NUMBER HEADING 'Applied|Message|Number' FORMAT 9999999999

SELECT APPLY_NAME,
(APPLY_TIME-APPLIED_MESSAGE_CREATE_TIME)*86400 "Latency in Seconds",
TO_CHAR(APPLIED_MESSAGE_CREATE_TIME,'HH24:MI:SS MM/DD/YY')
"Message Creation",
TO_CHAR(APPLY_TIME,'HH24:MI:SS MM/DD/YY') "Apply Time",
APPLIED_MESSAGE_NUMBER
FROM DBA_APPLY_PROGRESS;

出力は次のようになります。

Applied
Apply Process                                                            Message
Name              Latency in Seconds Message Creation  Apply Time         Number
----------------- ------------------ ----------------- ----------------- -------
APPLY$_STM1_14                    33 14:05:13 06/13/05 14:05:46 06/13/05  498215

各適用プロセスの適用サーバーに関する情報の表示

適用プロセスでは、1つ以上の適用サーバーを使用できます。適用サーバーによって、LCRは、DML文またはDDL文としてデータベース・オブジェクトに適用されるか、または適切なハンドラに渡されます。LCR以外のメッセージの場合、それらのメッセージは、適用サーバーによってメッセージ・ハンドラに渡されます。各適用サーバーはプロセスです。

この項で説明する問合せを実行すると、各適用プロセスの適用サーバーに関する次の情報が表示されます。

- 適用プロセスの名前。

- リーダー・サーバー・プロセスの名前(順に表示されます)。各プロセスの名前の形式は、ASnnです(nnには文字および数字を使用できます)。

- 各適用サーバーの現在の状態
「適用サーバーの状態」を参照してください。

- 適用プロセスが最後に起動されてから、各適用サーバーに割り当てられたトランザクションの合計数。トランザクションには、複数のメッセージが含まれる場合があります。

- 適用プロセスが最後に起動されてから、各適用サーバーによって適用されたメッセージの合計数。

この問合せで表示される情報は、有効になっている適用プロセスに対してのみ有効です。

次の問合せを実行すると、各適用プロセスの適用サーバーに関する情報が表示されます。

COLUMN APPLY_NAME HEADING 'Apply Process Name' FORMAT A22
COLUMN PROCESS_NAME HEADING 'Process Name' FORMAT A12
COLUMN STATE HEADING 'State' FORMAT A17
COLUMN TOTAL_ASSIGNED HEADING 'Total|Transactions|Assigned' FORMAT 99999999
COLUMN TOTAL_MESSAGES_APPLIED HEADING 'Total|Messages|Applied' FORMAT 99999999

SELECT r.APPLY_NAME,
SUBSTR(s.PROGRAM,INSTR(S.PROGRAM,'(')+1,4) PROCESS_NAME,
r.STATE,
r.TOTAL_ASSIGNED,
r.TOTAL_MESSAGES_APPLIED
FROM V$STREAMS_APPLY_SERVER R, V$SESSION S
WHERE r.SID = s.SID AND
r.SERIAL# = s.SERIAL#
ORDER BY r.APPLY_NAME, r.SERVER_ID;

出力は次のようになります。

Total     Total
Transactions  Messages
Apply Process Name     Process Name State                 Assigned   Applied
---------------------- ------------ ----------------- ------------ ---------
APPLY$_DA_2            AS02         IDLE                      1012    109190
APPLY$_DA_2            AS03         IDLE                       996    107568
APPLY$_DA_2            AS04         IDLE                      1006    108648
APPLY$_DA_2            AS05         IDLE                       987    10659
6

適用プロセスの有効な適用並列性の表示

環境によっては、適用プロセスで、使用可能なすべての適用サーバーを使用できない場合があります。たとえば、適用プロセスの並列性を5に設定しても、その適用プロセスで3つの適用サーバーのみが使用される場合があります。この場合、有効な適用並列性は3です。

次の問合せを実行すると、適用プロセスapplyの有効な適用並列性が表示されます。

SELECT COUNT(SERVER_ID) "Effective Parallelism"
FROM V$STREAMS_APPLY_SERVER
WHERE APPLY_NAME = 'APPLY' AND
TOTAL_MESSAGES_APPLIED > 0;

出力は次のようになります。

Effective Parallelism
---------------------
2

この問合せでは、有効な並列性として2が戻されています。適用プロセスapplyの並列性が3に設定されている場合は、適用プロセスが最後に起動されてから使用されていない適用サーバーが1つあることになります。

各適用サーバーによって適用されるメッセージの合計数を表示するには、次の問合せを実行します。

COLUMN SERVER_ID HEADING 'Apply Server ID' FORMAT 99
COLUMN TOTAL_MESSAGES_APPLIED HEADING 'Total Messages Applied' FORMAT 999999

SELECT SERVER_ID, TOTAL_MESSAGES_APPLIED
FROM V$STREAMS_APPLY_SERVER
WHERE APPLY_NAME = 'APPLY'
ORDER BY SERVER_ID;

出力は次のようになります。

Apply Server ID Total Messages Applied
--------------- ----------------------
1                   2141
2                    276
3                      0
4                      0

この場合、適用サーバー3および4は、適用プロセスが最後に起動されてから使用されていません。適用プロセスのparallelismがその適用プロセスの有効な並列性より大幅に大きい値に設定されている場合は、parallelismを小さい値に設定することを検討します。たとえば、parallelismが6に設定されているが、適用プロセスの有効な並列性が2である場合、小さい値に設定することを検討します。

適用時に宛先キューを指定するルールの表示

ルールの宛先キューを指定するには、DBMS_APPLY_ADMパッケージのSET_ENQUEUE_DESTINATIONプロシージャを使用します。宛先キューを指定したルールが適用プロセスのポジティブ・ルール・セットに含まれており、メッセージがそのルールを満たす場合、このメッセージは適用プロセスによって宛先キューにエンキューされます。

ルールの宛先キューの設定を表示するには、次の問合せを実行します。

COLUMN RULE_OWNER HEADING 'Rule Owner' FORMAT A15
COLUMN RULE_NAME HEADING 'Rule Name' FORMAT A15
COLUMN DESTINATION_QUEUE_NAME HEADING 'Destination Queue' FORMAT A30

SELECT RULE_OWNER, RULE_NAME, DESTINATION_QUEUE_NAME
FROM DBA_APPLY_ENQUEUE;

出力は次のようになります。

Rule Owner      Rule Name       Destination Queue
--------------- --------------- ------------------------------
STRMADMIN       DEPARTMENTS17   "STRMADMIN"."STREAMS_QUEUE"

関連項目:

- 「適用プロセスによるメッセージのエンキューの指定」

- 「適用時のメッセージのエンキューの宛先」

適用時に実行しないことを指定するルールの表示

ルールの実行ディレクティブを指定するには、DBMS_APPLY_ADMパッケージのSET_EXECUTEプロシージャを使用します。実行ディレクティブによって、指定したルールを満たすメッセージを適用プロセスで実行するかどうかが制御されます。適用プロセスのポジティブ・ルール・セットに、実行ディレクティブがNOに設定されたルールが含まれており、メッセージがそのルールを満たす場合、このメッセージは、適用プロセスによって実行されず、適用ハンドラにも送信されません。

実行ディレクティブがNOに設定された各ルールを表示するには、次の問合せを実行します。

COLUMN RULE_OWNER HEADING 'Rule Owner' FORMAT A20
COLUMN RULE_NAME HEADING 'Rule Name' FORMAT A20

SELECT RULE_OWNER, RULE_NAME
FROM DBA_APPLY_EXECUTE
WHERE EXECUTE_EVENT = 'NO';

出力は次のようになります。

Rule Owner           Rule Name
-------------------- --------------------
STRMADMIN            DEPARTMENTS18

関連項目:

- 「適用プロセスの実行ディレクティブの指定」

- 「適用時のメッセージの実行ディレクティブ」

取得と適用の複合を使用する適用プロセスの判別

取得プロセスは論理変更レコード(LCR)を 伝播受信者に直接送信する伝播送信者として動作するため、取得と適用の複合環境は効率的です。

適用プロセスで取得と適用の複合が使用される場合、V$STREAMS_APPLY_READERデータ・ディクショナリ・ビューの次の列が移入されます。

- PROXY_SID: 伝播受信者のセッションIDが表示されます。

- PROXY_SERIAL: 伝播受信者のシリアル番号が表示されます。

- PROXY_SPID: 伝播受信者のプロセス識別番号が表示されます。

- CAPTURE_BYTES_RECEIVED: 適用プロセスが最後に起動されてから受信したバイト数が表示されます。

適用プロセスで取得と適用の複合が使用されない場合、PROXY_SIDおよびPROXY_SERIAL列は0(ゼロ)になり、PROXY_SPIDおよびCAPTURE_BYTES_RECEIVED列は移入されません。

適用プロセスで取得と適用の複合が使用されるかどうかを判別するには、次の問合せを実行します。

COLUMN APPLY_NAME HEADING 'Apply Process Name' FORMAT A20
COLUMN PROXY_SID HEADING 'Propagation|Receiver|Session ID' FORMAT 99999999
COLUMN PROXY_SERIAL HEADING 'Propagation|ReceiverSerial|Number' FORMAT 99999999
COLUMN PROXY_SPID HEADING 'Propagation|Receiver|Process ID' FORMAT 99999999999
COLUMN CAPTURE_BYTES_RECEIVED HEADING 'Number of|Bytes Received' FORMAT 9999999999

SELECT APPLY_NAME,
PROXY_SID,
PROXY_SERIAL,
PROXY_SPID,
CAPTURE_BYTES_RECEIVED
FROM V$STREAMS_APPLY_READER;

出力は次のようになります。

Propagation    Propagation Propagation
Receiver ReceiverSerial Receiver          Number of
Apply Process Name    Session ID         Number Process ID   Bytes Received
-------------------- ----------- -------------- ------------ --------------
APPLY_SPOKE1                 940              1 22636               4358614
APPLY_SPOKE2                 928              4 29154               4310581

この出力は、適用プロセスapply_spoke1で取得と適用の複合が使用されていることを示しています。この適用プロセスは、最後に起動されてから、4358614バイトを取得プロセスから受信しています。適用プロセスapply_spoke2でも取得と適用の複合が使用されています。この適用プロセスは、最後に起動されてから、4310581バイトを取得プロセスから受信しています。

関連項目:
第12章「取得と適用の複合による最適化」

宛先データベースで指定された代替キー列の表示

宛先データベースで代替キー(Oracleが適用時に表内の行を識別するのに使用できる列または列セット)を指定できます。代替キー列を使用して主キーが存在しない表のキー列を指定したり、宛先データベースで表が任意の適用プロセスによって処理されるときに代替キー列を表の主キーのかわりに使用できます。

宛先データベースで指定されたすべての代替キー列を表示するには、次の問合せを実行します。

COLUMN OBJECT_OWNER HEADING 'Table Owner' FORMAT A20
COLUMN OBJECT_NAME HEADING 'Table Name' FORMAT A20
COLUMN COLUMN_NAME HEADING 'Substitute Key Name' FORMAT A20
COLUMN APPLY_DATABASE_LINK HEADING 'Database Link|for Remote|Apply' FORMAT A15

SELECT OBJECT_OWNER, OBJECT_NAME, COLUMN_NAME, APPLY_DATABASE_LINK
FROM DBA_APPLY_KEY_COLUMNS
ORDER BY APPLY_DATABASE_LINK, OBJECT_OWNER, OBJECT_NAME;

出力は次のようになります。

Database Link
for Remote
Table Owner          Table Name           Substitute Key Name  Apply
-------------------- -------------------- -------------------- ---------------
HR                   DEPARTMENTS          DEPARTMENT_NAME
HR                   DEPARTMENTS          LOCATION_ID
HR                   EMPLOYEES            FIRST_NAME
HR                   EMPLOYEES            LAST_NAME
HR                   EMPLOYEES            HIRE_DATE

注意:
この問合せを実行すると、代替キー列がOracle以外のリモート・データベースに対して指定されている場合、最後の列にデータベース・リンクが表示されます。代替キー列がローカルの宛先データベースに対して指定されている場合、最後の列はNULLとなります。

関連項目:

- 「代替キー列」

- 「表の代替キー列の管理」

- 「適用エラーの管理」

仮想依存性定義の監視

次の各項では、データベース内の仮想依存性定義に関する情報を表示する問合せについて説明します。

- 値の依存性の表示

- オブジェクト依存性の表示

関連項目:
仮想依存性定義の詳細は、「適用プロセスおよび依存性」を参照

値の依存性の表示

データベース内の値の依存性を表示するには、次の問合せを実行します。

COLUMN DEPENDENCY_NAME HEADING 'Dependency Name' FORMAT A25
COLUMN OBJECT_OWNER HEADING 'Object Owner' FORMAT A15
COLUMN OBJECT_NAME HEADING 'Object Name' FORMAT A20
COLUMN COLUMN_NAME HEADING 'Column Name' FORMAT A15

SELECT DEPENDENCY_NAME,
OBJECT_OWNER,
OBJECT_NAME,
COLUMN_NAME
FROM DBA_APPLY_VALUE_DEPENDENCIES;

出力は次のようになります。

Dependency Name           Object Owner    Object Name          Column Name
------------------------- --------------- -------------------- ---------------
ORDER_ID_FOREIGN_KEY      OE              ORDERS               ORDER_ID
ORDER_ID_FOREIGN_KEY      OE              ORDER_ITEMS          ORDER_ID
KEY_53_FOREIGN_KEY        US_DESIGNS      ALL_DESIGNS_SUMMARY  KEY_53
KEY_53_FOREIGN_KEY        US_DESIGNS      DESIGN_53            KEY_53

この出力は、次の値の依存性を示しています。

- order_id_foreign_keyという値の依存性は、oe.orders表のorder_id列とoe.order_items表のorder_id列との間の依存性を示しています。

- key_53_foreign_keyという値の依存性は、us_designs.all_designs_summary表のkey_53列とus_designs.design_53表のkey_53列との間の依存性を示しています。

オブジェクト依存性の表示

データベース内のオブジェクト依存性を表示するには、次の問合せを実行します。

COLUMN OBJECT_OWNER HEADING 'Object Owner' FORMAT A15
COLUMN OBJECT_NAME HEADING 'Object Name' FORMAT A15
COLUMN PARENT_OBJECT_OWNER HEADING 'Parent Object Owner' FORMAT A20
COLUMN PARENT_OBJECT_NAME HEADING 'Parent Object Name' FORMAT A20

SELECT OBJECT_OWNER,
OBJECT_NAME,
PARENT_OBJECT_OWNER,
PARENT_OBJECT_NAME
FROM DBA_APPLY_OBJECT_DEPENDENCIES;

出力は次のようになります。

Object Owner    Object Name     Parent Object Owner  Parent Object Name
--------------- --------------- -------------------- --------------------
ORD             CUSTOMERS       ORD                  SHIP_ORDERS
ORD             ORDERS          ORD                  SHIP_ORDERS
ORD             ORDER_ITEMS     ORD                  SHIP_ORDERS

この出力は、ord.ship_orders表が次の子表の親表であるオブジェクト依存性を示しています。

- ord.customers

- ord.orders

- ord.order_items

適用エラーのチェック

適用エラーの有無をチェックするには、次の問合せを実行します。

COLUMN APPLY_NAME HEADING 'Apply|Process|Name' FORMAT A11
COLUMN SOURCE_DATABASE HEADING 'Source|Database' FORMAT A10
COLUMN LOCAL_TRANSACTION_ID HEADING 'Local|Transaction|ID' FORMAT A11
COLUMN ERROR_NUMBER HEADING 'Error Number' FORMAT 99999999
COLUMN ERROR_MESSAGE HEADING 'Error Message' FORMAT A20
COLUMN MESSAGE_COUNT HEADING 'Messages in|Error|Transaction' FORMAT 99999999

SELECT APPLY_NAME,
SOURCE_DATABASE,
LOCAL_TRANSACTION_ID,
ERROR_NUMBER,
ERROR_MESSAGE,
MESSAGE_COUNT
FROM DBA_APPLY_ERROR;

適用エラーがある場合、出力は次のようになります。

Apply                  Local                                         Messages in
Process     Source     Transaction                                         Error
Name        Database   ID          Error Number Error Message        Transaction
----------- ---------- ----------- ------------ -------------------- -----------
APPLY$_DB_2 DB.EXAMPLE 13.16.334          26786 ORA-26786: A row wit           1
.COM                                h key ("EMPLOYEE_ID"
) = (206) exists but
has conflicting col
umn(s) "SALARY" in t
able HR.EMPLOYEES
ORA-01403: no data f
ound
APPLY$_DB_2 DB.EXAMPLE 15.17.540          26786 ORA-26786: A row wit           1
.COM                                h key ("EMPLOYEE_ID"
) = (206) exists but
has conflicting col
umn(s) "SALARY" in t
able HR.EMPLOYEES
ORA-01403: no data f
ound

適用エラーがある場合は、エラーが発生したトランザクションを再実行するか、またはそのトランザクションを削除することができます。エラーが発生したトランザクションを再実行する場合は、まず、トランザクションでエラーが発生する原因となった状態を修正します。

エラーが発生したトランザクションを削除する場合、複数のデータベースでデータを共有しているときは、手動によるデータの再同期化が必要になることがあります。データを手動で再同期化する場合は、必要に応じて適切なセッション・タグを設定してください。

関連項目:

- 第33章「適用のトラブルシューティング」

- 「エラー・キュー」

- 「適用エラーの管理」

- 適用エラーの考えられる原因の詳細は、「表へのDML変更の適用に関する考慮事項」を参照

- 現行セッションで生成されるタグの値の設定の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

適用エラーの詳細情報の表示

この項では、データベースのエラー・キューにあるエラー・トランザクションの詳細情報を表示するために使用できるSQLスクリプトについて説明します。これらのスクリプトはLCRの情報を表示するように設計されていますが、環境で使用される非LCRメッセージ情報を表示するようにも拡張できます。

これらのスクリプトを使用するには、次の手順を実行します。

1. DBA_APPLY_ERRORビューに対する明示的なSELECT権限の付与

2. ANYDATAオブジェクト内の値を出力するプロシージャの作成

3. 指定したLCRを出力するプロシージャの作成

4. エラー・キューにあるすべてのLCRを出力するプロシージャの作成

5. トランザクションに関するすべてのエラーLCRを出力するプロシージャの作成

注意:
これらのスクリプトでは、LCR内のVARCHAR2値の最初の253文字のみが表示されます。

手順1: DBA_APPLY_ERRORビューに対する明示的なSELECT権限の付与

ここで説明するprint_errorsおよびprint_transactionプロシージャを作成して実行するユーザーには、DBA_APPLY_ERRORデータ・ディクショナリ・ビューに対する明示的なSELECT権限が付与されている必要があります。この権限は、ロールを介しては付与できません。ユーザーに対してDBMS_STREAMS_AUTHパッケージのGRANT_ADMIN_PRIVILEGEプロシージャを実行すると、そのユーザーにこの権限が付与されます。

ユーザーにこの権限を直接付与するには、次の手順を実行します。

1. SQL*Plusで、権限を付与できる管理ユーザーとして接続します。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

2. DBA_APPLY_ERRORデータ・ディクショナリ・ビューに対するSELECT権限を適切なユーザーに付与します。たとえば、この権限をstrmadminユーザーに付与するには、次の文を実行します。

GRANT SELECT ON DBA_APPLY_ERROR TO strmadmin;

3. DBMS_APPLY_ADMパッケージのEXECUTE権限を付与します。たとえば、この権限をstrmadminユーザーに付与するには、次の文を実行します。

GRANT EXECUTE ON DBMS_APPLY_ADM TO strmadmin;

4. 手順2および3で権限を付与したユーザーとして、データベースに接続します。

手順2: ANYDATAオブジェクト内の値を出力するプロシージャの作成

次のプロシージャを実行すると、選択したデータ型に対して、指定したANYDATAオブジェクト内の値が出力されます。このプロシージャには、オプションで他のデータ型を追加できます。

CREATE OR REPLACE PROCEDURE print_any(data IN ANYDATA) IS
tn  VARCHAR2(61);
str VARCHAR2(4000);
chr VARCHAR2(1000);
num NUMBER;
dat DATE;
rw  RAW(4000);
res NUMBER;
BEGIN
IF data IS NULL THEN
DBMS_OUTPUT.PUT_LINE('NULL value');
RETURN;
END IF;
tn := data.GETTYPENAME();
IF tn = 'SYS.VARCHAR2' THEN
res := data.GETVARCHAR2(str);
DBMS_OUTPUT.PUT_LINE(SUBSTR(str,0,253));
ELSIF tn = 'SYS.CHAR' then
res := data.GETCHAR(chr);
DBMS_OUTPUT.PUT_LINE(SUBSTR(chr,0,253));
ELSIF tn = 'SYS.VARCHAR' THEN
res := data.GETVARCHAR(chr);
DBMS_OUTPUT.PUT_LINE(chr);
ELSIF tn = 'SYS.NUMBER' THEN
res := data.GETNUMBER(num);
DBMS_OUTPUT.PUT_LINE(num);
ELSIF tn = 'SYS.DATE' THEN
res := data.GETDATE(dat);
DBMS_OUTPUT.PUT_LINE(dat);
ELSIF tn= 'SYS.TIMESTAMP' THEN
res := data.GETTIMESTAMP(dat);
DBMS_OUTPUT.PUT_LINE(TO_CHAR(dat,'DD-MON-RR HH.MI.SSXFF AM'));
ELSIF tn= 'SYS.TIMESTAMPTZ' THEN
res := data.GETTIMESTAMPTZ(dat);
DBMS_OUTPUT.PUT_LINE(TO_CHAR(dat,'DD-MON-RR HH.MI.SSXFF AM'));
ELSIF tn= 'SYS.TIMESTAMPLTZ' THEN
res := data.GETTIMESTAMPLTZ(dat);
DBMS_OUTPUT.PUT_LINE(TO_CHAR(dat,'DD-MON-RR HH.MI.SSXFF AM'));
ELSIF tn = 'SYS.RAW' THEN
-- res := data.GETRAW(rw);
-- DBMS_OUTPUT.PUT_LINE(SUBSTR(DBMS_LOB.SUBSTR(rw),0,253));
DBMS_OUTPUT.PUT_LINE('BLOB Value');
ELSIF tn = 'SYS.BLOB' THEN
DBMS_OUTPUT.PUT_LINE('BLOB Found');
ELSE
DBMS_OUTPUT.PUT_LINE('typename is ' || tn);
END IF;
END print_any;
/

手順3: 指定したLCRを出力するプロシージャの作成

次のプロシージャを実行すると、指定したLCRが出力されます。このプロシージャでは、「ANYDATAオブジェクト内の値を出力するプロシージャの作成」で作成したprint_anyプロシージャがコールされます。

CREATE OR REPLACE PROCEDURE print_lcr(lcr IN ANYDATA) IS
typenm    VARCHAR2(61);
ddllcr    SYS.LCR$_DDL_RECORD;
proclcr   SYS.LCR$_PROCEDURE_RECORD;
rowlcr    SYS.LCR$_ROW_RECORD;
res       NUMBER;
newlist   SYS.LCR$_ROW_LIST;
oldlist   SYS.LCR$_ROW_LIST;
ddl_text  CLOB;
ext_attr  ANYDATA;
BEGIN
typenm := lcr.GETTYPENAME();
DBMS_OUTPUT.PUT_LINE('type name: ' || typenm);
IF (typenm = 'SYS.LCR$_DDL_RECORD') THEN
res := lcr.GETOBJECT(ddllcr);
DBMS_OUTPUT.PUT_LINE('source database: ' ||
ddllcr.GET_SOURCE_DATABASE_NAME);
DBMS_OUTPUT.PUT_LINE('owner: ' || ddllcr.GET_OBJECT_OWNER);
DBMS_OUTPUT.PUT_LINE('object: ' || ddllcr.GET_OBJECT_NAME);
DBMS_OUTPUT.PUT_LINE('is tag null: ' || ddllcr.IS_NULL_TAG);
DBMS_LOB.CREATETEMPORARY(ddl_text, TRUE);
ddllcr.GET_DDL_TEXT(ddl_text);
DBMS_OUTPUT.PUT_LINE('ddl: ' || ddl_text);
-- Print extra attributes in DDL LCR
ext_attr := ddllcr.GET_EXTRA_ATTRIBUTE('serial#');
IF (ext_attr IS NOT NULL) THEN
DBMS_OUTPUT.PUT_LINE('serial#: ' || ext_attr.ACCESSNUMBER());
END IF;
ext_attr := ddllcr.GET_EXTRA_ATTRIBUTE('session#');
IF (ext_attr IS NOT NULL) THEN
DBMS_OUTPUT.PUT_LINE('session#: ' || ext_attr.ACCESSNUMBER());
END IF;
ext_attr := ddllcr.GET_EXTRA_ATTRIBUTE('thread#');
IF (ext_attr IS NOT NULL) THEN
DBMS_OUTPUT.PUT_LINE('thread#: ' || ext_attr.ACCESSNUMBER());
END IF;
ext_attr := ddllcr.GET_EXTRA_ATTRIBUTE('tx_name');
IF (ext_attr IS NOT NULL) THEN
DBMS_OUTPUT.PUT_LINE('transaction name: ' || ext_attr.ACCESSVARCHAR2());
END IF;
ext_attr := ddllcr.GET_EXTRA_ATTRIBUTE('username');
IF (ext_attr IS NOT NULL) THEN
DBMS_OUTPUT.PUT_LINE('username: ' || ext_attr.ACCESSVARCHAR2());
END IF;
DBMS_LOB.FREETEMPORARY(ddl_text);
ELSIF (typenm = 'SYS.LCR$_ROW_RECORD') THEN
res := lcr.GETOBJECT(rowlcr);
DBMS_OUTPUT.PUT_LINE('source database: ' ||
rowlcr.GET_SOURCE_DATABASE_NAME);
DBMS_OUTPUT.PUT_LINE('owner: ' || rowlcr.GET_OBJECT_OWNER);
DBMS_OUTPUT.PUT_LINE('object: ' || rowlcr.GET_OBJECT_NAME);
DBMS_OUTPUT.PUT_LINE('is tag null: ' || rowlcr.IS_NULL_TAG);
DBMS_OUTPUT.PUT_LINE('command_type: ' || rowlcr.GET_COMMAND_TYPE);
oldlist := rowlcr.GET_VALUES('old');
FOR i IN 1..oldlist.COUNT LOOP
IF oldlist(i) IS NOT NULL THEN
DBMS_OUTPUT.PUT_LINE('old(' || i || '): ' || oldlist(i).column_name);
print_any(oldlist(i).data);
END IF;
END LOOP;
newlist := rowlcr.GET_VALUES('new', 'n');
FOR i in 1..newlist.count LOOP
IF newlist(i) IS NOT NULL THEN
DBMS_OUTPUT.PUT_LINE('new(' || i || '): ' || newlist(i).column_name);
print_any(newlist(i).data);
END IF;
END LOOP;
-- Print extra attributes in row LCR
ext_attr := rowlcr.GET_EXTRA_ATTRIBUTE('row_id');
IF (ext_attr IS NOT NULL) THEN
DBMS_OUTPUT.PUT_LINE('row_id: ' || ext_attr.ACCESSUROWID());
END IF;
ext_attr := rowlcr.GET_EXTRA_ATTRIBUTE('serial#');
IF (ext_attr IS NOT NULL) THEN
DBMS_OUTPUT.PUT_LINE('serial#: ' || ext_attr.ACCESSNUMBER());
END IF;
ext_attr := rowlcr.GET_EXTRA_ATTRIBUTE('session#');
IF (ext_attr IS NOT NULL) THEN
DBMS_OUTPUT.PUT_LINE('session#: ' || ext_attr.ACCESSNUMBER());
END IF;
ext_attr := rowlcr.GET_EXTRA_ATTRIBUTE('thread#');
IF (ext_attr IS NOT NULL) THEN
DBMS_OUTPUT.PUT_LINE('thread#: ' || ext_attr.ACCESSNUMBER());
END IF;
ext_attr := rowlcr.GET_EXTRA_ATTRIBUTE('tx_name');
IF (ext_attr IS NOT NULL) THEN
DBMS_OUTPUT.PUT_LINE('transaction name: ' || ext_attr.ACCESSVARCHAR2());
END IF;
ext_attr := rowlcr.GET_EXTRA_ATTRIBUTE('username');
IF (ext_attr IS NOT NULL) THEN
DBMS_OUTPUT.PUT_LINE('username: ' || ext_attr.ACCESSVARCHAR2());
END IF;
ELSE
DBMS_OUTPUT.PUT_LINE('Non-LCR Message with type ' || typenm);
END IF;
END print_lcr;
/

手順4: エラー・キューにあるすべてのLCRを出力するプロシージャの作成

次のプロシージャを実行すると、すべてのエラー・キューに含まれているすべてのLCRが出力されます。このプロシージャでは、「指定したLCRを出力するプロシージャの作成」で作成したprint_lcrプロシージャがコールされます。

CREATE OR REPLACE PROCEDURE print_errors IS
CURSOR c IS
SELECT LOCAL_TRANSACTION_ID,
SOURCE_DATABASE,
MESSAGE_NUMBER,
MESSAGE_COUNT,
ERROR_NUMBER,
ERROR_MESSAGE
FROM DBA_APPLY_ERROR
ORDER BY SOURCE_DATABASE, SOURCE_COMMIT_SCN;
i      NUMBER;
txnid  VARCHAR2(30);
source VARCHAR2(128);
msgno  NUMBER;
msgcnt NUMBER;
errnum NUMBER := 0;
errno  NUMBER;
errmsg VARCHAR2(2000);
lcr    ANYDATA;
r      NUMBER;
BEGIN
FOR r IN c LOOP
errnum := errnum + 1;
msgcnt := r.MESSAGE_COUNT;
txnid  := r.LOCAL_TRANSACTION_ID;
source := r.SOURCE_DATABASE;
msgno  := r.MESSAGE_NUMBER;
errno  := r.ERROR_NUMBER;
errmsg := r.ERROR_MESSAGE;
DBMS_OUTPUT.PUT_LINE('*************************************************');
DBMS_OUTPUT.PUT_LINE('----- ERROR #' || errnum);
DBMS_OUTPUT.PUT_LINE('----- Local Transaction ID: ' || txnid);
DBMS_OUTPUT.PUT_LINE('----- Source Database: ' || source);
DBMS_OUTPUT.PUT_LINE('----Error in Message: '|| msgno);
DBMS_OUTPUT.PUT_LINE('----Error Number: '||errno);
DBMS_OUTPUT.PUT_LINE('----Message Text: '||errmsg);
FOR i IN 1..msgcnt LOOP
DBMS_OUTPUT.PUT_LINE('--message: ' || i);
lcr := DBMS_APPLY_ADM.GET_ERROR_MESSAGE(i, txnid);
print_lcr(lcr);
END LOOP;
END LOOP;
END print_errors;
/

このプロシージャを作成後に実行するには、次のように入力します。

SET SERVEROUTPUT ON SIZE 1000000

EXEC print_errors

手順5: トランザクションに関するすべてのエラーLCRを出力するプロシージャの作成

次のプロシージャを実行すると、特定のトランザクションに対するエラー・キューに含まれているすべてのLCRが出力されます。このプロシージャでは、「指定したLCRを出力するプロシージャの作成」で作成したprint_lcrプロシージャがコールされます。

CREATE OR REPLACE PROCEDURE print_transaction(ltxnid IN VARCHAR2) IS
i      NUMBER;
txnid  VARCHAR2(30);
source VARCHAR2(128);
msgno  NUMBER;
msgcnt NUMBER;
errno  NUMBER;
errmsg VARCHAR2(2000);
lcr    ANYDATA;
BEGIN
SELECT LOCAL_TRANSACTION_ID,
SOURCE_DATABASE,
MESSAGE_NUMBER,
MESSAGE_COUNT,
ERROR_NUMBER,
ERROR_MESSAGE
INTO txnid, source, msgno, msgcnt, errno, errmsg
FROM DBA_APPLY_ERROR
WHERE LOCAL_TRANSACTION_ID =  ltxnid;
DBMS_OUTPUT.PUT_LINE('----- Local Transaction ID: ' || txnid);
DBMS_OUTPUT.PUT_LINE('----- Source Database: ' || source);
DBMS_OUTPUT.PUT_LINE('----Error in Message: '|| msgno);
DBMS_OUTPUT.PUT_LINE('----Error Number: '||errno);
DBMS_OUTPUT.PUT_LINE('----Message Text: '||errmsg);
FOR i IN 1..msgcnt LOOP
DBMS_OUTPUT.PUT_LINE('--message: ' || i);
lcr := DBMS_APPLY_ADM.GET_ERROR_MESSAGE(i, txnid); -- gets the LCR
print_lcr(lcr);
END LOOP;
END print_transaction;
/

このプロシージャを作成後に実行するには、このプロシージャにエラー・トランザクションのローカル・トランザクション識別子を渡します。たとえば、ローカル・トランザクション識別子が1.17.2485の場合は、次のように入力します。

SET SERVEROUTPUT ON SIZE 1000000

EXEC print_transaction('1.17.2485')

27 ルールの監視

次の各項では、ルール、ルール・セットおよび評価コンテキストの監視について説明します。

- すべてのOracle Streamsクライアントによって使用される全ルールの表示

- 特定のOracle Streamsクライアントによって使用されるOracle Streamsルールの表示

- ルールの現行の条件の表示

- Oracle Streamsルール用に変更されたルール条件の表示

- 各ルール・セットの評価コンテキストの表示

- 評価コンテキストで使用される表に関する情報の表示

- 評価コンテキスト内で使用される変数に関する情報の表示

- ルール・セットの全ルールの表示

- ルール・セット内の各ルールの条件の表示

- 条件に指定パターンが含まれる各ルールのリスト表示

- すべてのルール・セット評価の総合統計の表示

- 各ルール・セットの評価に関する情報の表示

- 各ルール・セットの評価に使用されたリソースの判断

- ルールの評価統計の表示

注意:
Oracle Enterprise ManagerのOracle Streamsツールも、Oracle Streams環境を監視するための優れた手段です。詳細は、Oracle Streamsツールのオンライン・ヘルプを参照してください。

関連項目:

- 第5章「Oracle Streamsでのルールの使用方法」

- 第11章「ルールの高度な概念」

- 第18章「ルールの管理」

- 第34章「ルールおよびルールベースの変換のトラブルシューティング」

- ルールのアクション・コンテキストの表示の詳細は、「ルールのアクション・コンテキストの名前/値ペアの変更」を参照

- この章で説明するデータ・ディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照

すべてのOracle Streamsクライアントによって使用される全ルールの表示

Oracle Streamsルールは、DBMS_STREAMS_ADMパッケージまたはOracle Enterprise ManagerのOracle Streamsツールを使用して作成されます。Oracle Streamsクライアントのルール・セット内のOracle Streamsルールにより、Oracle Streamsクライアントの動作が決まります。Oracle Streamsクライアントには、取得プロセス、伝播、適用プロセスおよびメッセージ・クライアントが含まれています。Oracle Streamsクライアントのルール・セットには、DBMS_RULE_ADMパッケージを使用して作成されたルールも含まれる場合があり、これらのルールも、Oracle Streamsクライアントの動作に影響します。

たとえばhr.employees表に対するDML変更について、取得プロセスのポジティブ・ルール・セットのルールがTRUEと評価されると、この表に対するDML変更が取得プロセスで取得されます。ただし、hr.employees表に対するDML変更について、取得プロセスのネガティブ・ルール・セットのルールがTRUEと評価されると、この表に対するDML変更が廃棄されます。

次のデータ・ディクショナリ・ビューを問い合せると、Oracle Streamsクライアントのルール・セット内のすべてのルール(Oracle StreamsルールおよびDBMS_RULE_ADMパッケージを使用して作成されたルールを含む)が表示されます。

- ALL_STREAMS_RULES

- DBA_STREAMS_RULES

また、これらの2つのビューには、各ルールの現在のルール条件と、ルール条件が変更されたかどうかが表示されます。

この項で説明する問合せを実行すると、データベース内のOracle Streamsクライアントによって使用されるすべてのルールに関する次の情報が表示されます。

- ルールを使用する各Oracle Streamsクライアントの名前

- ルールを使用する各Oracle Streamsクライアントのタイプ(取得プロセスを示すCAPTURE、同期取得を示すSYNCHRONOUS CAPTURE、伝播を示すPROPAGATION、適用プロセスを示すAPPLY、またはメッセージ・クライアントを示すDEQUEUE)

- ルール名

- Oracle Streamsクライアントのルールを含むルール・セットのタイプ(POSITIVEまたはNEGATIVE)

- Oracle Streamsルール・レベル(GLOBAL、SCHEMAまたはTABLE)

- スキーマ・ルールおよび表ルールのスキーマ名

- 表ルールの表の名前

- ルール・タイプ(DMLまたはDDL)

次の問合せを実行すると、前述の情報が表示されます。

COLUMN STREAMS_NAME HEADING 'Oracle|Streams|Name' FORMAT A14
COLUMN STREAMS_TYPE HEADING 'Oracle|Streams|Type' FORMAT A11
COLUMN RULE_NAME HEADING 'Rule|Name' FORMAT A12
COLUMN RULE_SET_TYPE HEADING 'Rule Set|Type' FORMAT A8
COLUMN STREAMS_RULE_TYPE HEADING 'Oracle|Streams|Rule|Level' FORMAT A7
COLUMN SCHEMA_NAME HEADING 'Schema|Name' FORMAT A6
COLUMN OBJECT_NAME HEADING 'Object|Name' FORMAT A11
COLUMN RULE_TYPE HEADING 'Rule|Type' FORMAT A4

SELECT STREAMS_NAME,
STREAMS_TYPE,
RULE_NAME,
RULE_SET_TYPE,
STREAMS_RULE_TYPE,
SCHEMA_NAME,
OBJECT_NAME,
RULE_TYPE
FROM DBA_STREAMS_RULES;

出力は次のようになります。

Oracle
Oracle         Oracle                            Streams
Streams        Streams     Rule         Rule Set Rule    Schema Object      Rule
Name           Type        Name         Type     Level   Name   Name        Type
-------------- ----------- ------------ -------- ------- ------ ----------- ----
STRM01_CAPTURE CAPTURE     JOBS4        POSITIVE TABLE   HR     JOBS        DML
STRM01_CAPTURE CAPTURE     JOBS5        POSITIVE TABLE   HR     JOBS        DDL
DBS1_TO_DBS2   PROPAGATION HR18         POSITIVE SCHEMA  HR                 DDL
DBS1_TO_DBS2   PROPAGATION HR17         POSITIVE SCHEMA  HR                 DML
APPLY          APPLY       HR20         POSITIVE SCHEMA  HR                 DML
APPLY          APPLY       JOB_HISTORY2 NEGATIVE TABLE   HR     JOB_HISTORY DML
OE             DEQUEUE     RULE$_28     POSITIVE

この出力から、データベース内のOracle Streamsクライアントが使用するルールについて、次の情報が得られます。

- DMLルールjobs4とDDLルールjobs5はいずれも、取得プロセスstrm01_captureのポジティブ・ルール・セットに含まれるhr.jobs表の表ルールである。

- DMLルールhr17とDDLルールhr18はいずれも、伝播dbs1_to_dbs2のポジティブ・ルール・セットに含まれるhrスキーマのスキーマ・ルールである。

- DMLルールhr20は、適用プロセスapplyのポジティブ・ルール・セットに含まれるhrスキーマのスキーマ・ルールである。

- DMLルールjob_history2は、適用プロセスapplyのネガティブ・ルール・セットに含まれるhrスキーマの表ルールである。

- ルールrule$_28は、メッセージ・クライアントoeのポジティブ・ルール・セットに含まれるメッセージ・ルールである。

ALL_STREAMS_RULESビューおよびDBA_STREAMS_RULESビューには、Oracle Streamsクライアントによって使用されるルール・セットに関する情報、Oracle Streamsルールの現在および元のルール条件、ルール条件が変更されたかどうか、各Oracle Streams サブセット・ルールのサブセット化操作とDML条件、各Oracle Streamsルールに指定されたソース・データベース、およびOracle Streamsメッセージ・ルールのメッセージ・タイプとメッセージ変数に関する情報も含まれます。

次のデータ・ディクショナリ・ビューでも、Oracle Streamsルールが表示されます。

- ALL_STREAMS_GLOBAL_RULES

- DBA_STREAMS_GLOBAL_RULES

- ALL_STREAMS_MESSAGE_RULES

- DBA_STREAMS_MESSAGE_RULES

- ALL_STREAMS_SCHEMA_RULES

- DBA_STREAMS_SCHEMA_RULES

- ALL_STREAMS_TABLE_RULES

- DBA_STREAMS_TABLE_RULES

これらのビューには、Oracle Streamsのルールのみが表示されます。DBMS_RULE_ADMパッケージによって行われたこれらのルールに対して手動で行われた変更や、DBMS_RULE_ADMパッケージを使用して作成されたルールは、表示されません。これらのビューには、各ルールの元のルール条件のみが表示されます。ルールの作成後にそのルール条件が変更されても、そのルールの最新のルール条件は表示されません。

特定のOracle Streamsクライアントによって使用されるOracle Streamsルールの表示

特定のOracle Streamsクライアントによって使用されているルール・セット内のルールを判別するには、DBA_STREAMS_RULESデータ・ディクショナリ・ビューを問い合せます。たとえば、データベースがstrm01_applyという適用プロセスを実行しているとします。次の項では、この適用プロセスのポジティブ・ルール・セットおよびネガティブ・ルール・セット内のルールを判別する方法を説明します。

次の各項では、特定のOracle Streamsクライアントによって使用されるルール・セット内のルールを判別する方法を説明します。

- Oracle Streamsクライアント用のポジティブ・ルール・セット内のルールの表示

- Oracle Streamsクライアント用のネガティブ・ルール・セット内のルールの表示

関連項目:

- 「システム作成ルール」

Oracle Streamsクライアント用のポジティブ・ルール・セット内のルールの表示

次の問合せを実行すると、strm01_applyという適用プロセスのポジティブ・ルール・セットに含まれるすべてのルールが表示されます。

COLUMN RULE_OWNER HEADING 'Rule Owner' FORMAT A10
COLUMN RULE_NAME HEADING 'Rule|Name' FORMAT A12
COLUMN STREAMS_RULE_TYPE HEADING 'Oracle Streams|Rule|Level' FORMAT A7
COLUMN SCHEMA_NAME HEADING 'Schema|Name' FORMAT A6
COLUMN OBJECT_NAME HEADING 'Object|Name' FORMAT A11
COLUMN RULE_TYPE HEADING 'Rule|Type' FORMAT A4
COLUMN SOURCE_DATABASE HEADING 'Source' FORMAT A10
COLUMN INCLUDE_TAGGED_LCR HEADING 'Apply|Tagged|LCRs?' FORMAT A9

SELECT RULE_OWNER,
RULE_NAME,
STREAMS_RULE_TYPE,
SCHEMA_NAME,
OBJECT_NAME,
RULE_TYPE,
SOURCE_DATABASE,
INCLUDE_TAGGED_LCR
FROM DBA_STREAMS_RULES
WHERE STREAMS_NAME  = 'STRM01_APPLY' AND
RULE_SET_TYPE = 'POSITIVE';

この問合せで行が戻された場合、適用プロセスは、ルールがTRUEと評価される変更を含むLCRを適用します。

出力は次のようになります。

Oracle Streams                                    Apply
Rule            Rule    Schema Object      Rule            Tagged
Rule Owner Name            Level   Name   Name        Type Source     LCRs?
---------- --------------- ------- ------ ----------- ---- ---------- ---------
STRMADMIN  HR20            SCHEMA  HR                 DML   DBS1.EXAM NO
PLE.COM
STRMADMIN  HR21            SCHEMA  HR                 DDL   DBS1.EXAM NO
PLE.COM

この問合せによって返されたOracle Streamsルールのルール条件が変更されていないとすると、これらの結果は、hrスキーマに対してdbs1.example.comデータベースで発生したDML変更およびDDL変更を含むLCRが、適用プロセスによって適用されることを示します。これらのLCRを適用するように適用プロセスに指示するポジティブ・ルール・セット内のルールは、所有者がstrmadminユーザーで、名前はhr20およびhr21です。また、適用プロセスではこれらのルールの1つを満たすLCRが適用されますが、LCR内のタグがNULLの場合にかぎります。

Oracle Streamsルールのルール条件が変更された場合は、現行のルール条件をチェックして、ルールがOracle Streamsクライアントに及ぼす影響を判断する必要があります。ルール条件が変更されたOracle StreamsルールのSAME_RULE_CONDITION列はNO となります。

関連項目:

- 「Oracle Streamsルール用に変更されたルール条件の表示」

Oracle Streamsクライアント用のネガティブ・ルール・セット内のルールの表示

次の問合せは、strm01_applyという適用プロセスのネガティブ・ルール・セット内にあるすべてのルールを表示しています。

COLUMN RULE_OWNER HEADING 'Rule Owner' FORMAT A10
COLUMN RULE_NAME HEADING 'Rule|Name' FORMAT A15
COLUMN STREAMS_RULE_TYPE HEADING 'Oracle Streams|Rule|Level' FORMAT A7
COLUMN SCHEMA_NAME HEADING 'Schema|Name' FORMAT A6
COLUMN OBJECT_NAME HEADING 'Object|Name' FORMAT A11
COLUMN RULE_TYPE HEADING 'Rule|Type' FORMAT A4
COLUMN SOURCE_DATABASE HEADING 'Source' FORMAT A10
COLUMN INCLUDE_TAGGED_LCR HEADING 'Apply|Tagged|LCRs?' FORMAT A9

SELECT RULE_OWNER,
RULE_NAME,
STREAMS_RULE_TYPE,
SCHEMA_NAME,
OBJECT_NAME,
RULE_TYPE,
SOURCE_DATABASE,
INCLUDE_TAGGED_LCR
FROM DBA_STREAMS_RULES
WHERE STREAMS_NAME  = 'APPLY' AND
RULE_SET_TYPE = 'NEGATIVE';

この問合せで行が戻された場合、適用プロセスは、ルールがTRUEと評価される変更を含むLCRを廃棄します。

出力は次のようになります。

Oracle Streams                                    Apply
Rule            Rule    Schema Object      Rule            Tagged
Rule Owner Name            Level   Name   Name        Type Source     LCRs?
---------- --------------- ------- ------ ----------- ---- ---------- ---------
STRMADMIN  JOB_HISTORY22   TABLE   HR     JOB_HISTORY DML  DBS1.EXAMP YES
LE.COM
STRMADMIN  JOB_HISTORY23   TABLE   HR     JOB_HISTORY DDL  DBS1.EXAMP YES
LE.COM

この問合せによって返されたOracle Streamsルールのルール条件が変更されていないとすると、これらの結果は、hr.job_history表に対してdbs1.example.comデータベースで発生したDML変更およびDDL変更を含むLCRが、適用プロセスによって廃棄されることを示します。これらのLCRを適用するように適用プロセスに指示するネガティブ・ルール・セット内のルールは、所有者がstrmadminで、名前はjob_history22およびjob_history23です。また、LCRのタグの値に関係なく、適用プロセスではこれらのルールの1つを満たすLCRが廃棄されます。

Oracle Streamsルールのルール条件が変更された場合は、現行のルール条件をチェックして、ルールがOracle Streamsクライアントに及ぼす影響を判断する必要があります。ルール条件が変更されたOracle StreamsルールのSAME_RULE_CONDITION列はNO となります。

関連項目:

- 「Oracle Streamsルール用に変更されたルール条件の表示」

ルールの現行の条件の表示

ルールの名前がわかっている場合は、そのルール条件を表示できます。たとえば、「特定のOracle Streamsクライアントによって使用されるOracle Streamsルールの表示」の問合せで返されるルールについて考えてみます。このルールの名前はhr1で、次の問合せを実行するとその条件を表示できます。

SET LONG  8000
SET PAGES 8000
SELECT RULE_CONDITION "Current Rule Condition"
FROM DBA_STREAMS_RULES
WHERE RULE_NAME  = 'HR1' AND
RULE_OWNER = 'STRMADMIN';

出力は次のようになります。

Current Rule Condition
--------------------------------------------------------------------------------
((((:dml.get_object_owner() = 'HR') and :dml.get_source_database_name() = 'DA.EX
AMPLE.COM' )) and (:dml.get_compatible() <= dbms_streams.compatible_11_2))

関連項目:

- 「ルール条件」

- 「システム作成ルール」

Oracle Streamsルール用に変更されたルール条件の表示

Oracle Streamsルールのルール条件は変更できます。ルール条件を変更すると、Oracle Streamsルールを使用するOracle Streamsクライアントの動作が変化する場合があります。また、変更によってはルール評価のパフォーマンスが低下することもあります。

次の問合せを実行すると、条件が変更された各Oracle Streamsルールのルール名、元のルール条件および現行のルール条件が表示されます。

COLUMN RULE_NAME HEADING 'Rule Name' FORMAT A12
COLUMN ORIGINAL_RULE_CONDITION HEADING 'Original Rule Condition' FORMAT A33
COLUMN RULE_CONDITION HEADING 'Current Rule Condition' FORMAT A33

SET LONG  8000
SET PAGES 8000
SELECT RULE_NAME, ORIGINAL_RULE_CONDITION, RULE_CONDITION
FROM DBA_STREAMS_RULES
WHERE SAME_RULE_CONDITION = 'NO';

出力は次のようになります。

Rule Name    Original Rule Condition           Current Rule Condition
------------ --------------------------------- ---------------------------------
HR20         ((:dml.get_object_owner() = 'HR') ((:dml.get_object_owner() = 'HR')
and :dml.is_null_tag() = 'Y' )    and :dml.is_null_tag() = 'Y' and
:dml.get_object_name() != 'JOB_H
ISTORY')

この例で、出力はhr20ルールの条件が変更されたことを示しています。最初、このスキーマ・ルールは、hrスキーマに対するすべての変更についてTRUEと評価されていました。このルールの現行の条件では、hr.job_history表に対するDML変更を除き、hrスキーマに対するすべての変更についてTRUEと評価されます。

注意:
この項の問合せは、Oracle Streamsルールのみに使用できます。DBMS_RULE_ADMパッケージを使用して作成されたルールには適用されません。これは、これらのルールが常に、ORIGINAL_RULE_CONDITION列にNULL、およびSAME_RULE_CONDITION列にNULLが表示されるためです。

関連項目:

- 「ルール条件」

- 「システム作成ルール」

各ルール・セットの評価コンテキストの表示

次の問合せを実行すると、データベース内のルール・セットごとにデフォルトの評価コンテキストが表示されます。

COLUMN RULE_SET_OWNER HEADING 'Rule Set|Owner' FORMAT A10
COLUMN RULE_SET_NAME HEADING 'Rule Set Name' FORMAT A20
COLUMN RULE_SET_EVAL_CONTEXT_OWNER HEADING 'Eval Context|Owner' FORMAT A12
COLUMN RULE_SET_EVAL_CONTEXT_NAME HEADING 'Eval Context Name' FORMAT A30

SELECT RULE_SET_OWNER,
RULE_SET_NAME,
RULE_SET_EVAL_CONTEXT_OWNER,
RULE_SET_EVAL_CONTEXT_NAME
FROM DBA_RULE_SETS;

出力は次のようになります。

Rule Set                        Eval Context
Owner      Rule Set Name        Owner        Eval Context Name
---------- -------------------- ------------ ------------------------------
STRMADMIN  RULESET$_2           SYS          STREAMS$_EVALUATION_CONTEXT
STRMADMIN  STRM02_QUEUE_R       STRMADMIN    AQ$_STRM02_QUEUE_TABLE_V
STRMADMIN  APPLY_OE_RS          STRMADMIN    OE_EVAL_CONTEXT
STRMADMIN  OE_QUEUE_R           STRMADMIN    AQ$_OE_QUEUE_TABLE_V
STRMADMIN  AQ$_1_RE             STRMADMIN    AQ$_OE_QUEUE_TABLE_V
SUPPORT    RS                   SUPPORT      EVALCTX
OE         NOTIFICATION_QUEUE_R OE           AQ$_NOTIFICATION_QUEUE_TABLE_V

関連項目:

- 「ルール評価コンテキスト」

- 「Oracle Streamsで使用される評価コンテキスト」

評価コンテキストで使用される表に関する情報の表示

次の問合せを実行すると、supportユーザーが所有するevalctxという評価コンテキストで使用される表に関する情報が表示されます。

COLUMN TABLE_ALIAS HEADING 'Table Alias' FORMAT A20
COLUMN TABLE_NAME HEADING 'Table Name' FORMAT A40

SELECT TABLE_ALIAS,
TABLE_NAME
FROM DBA_EVALUATION_CONTEXT_TABLES
WHERE EVALUATION_CONTEXT_OWNER = 'SUPPORT' AND
EVALUATION_CONTEXT_NAME = 'EVALCTX';

出力は次のようになります。

Table Alias          Table Name
-------------------- ----------------------------------------
PROB                 problems

関連項目:
「ルール評価コンテキスト」

評価コンテキスト内で使用される変数に関する情報の表示

次の問合せを実行すると、supportユーザーが所有するevalctxという評価コンテキストによって使用される変数に関する情報が表示されます。

COLUMN VARIABLE_NAME HEADING 'Variable Name' FORMAT A15
COLUMN VARIABLE_TYPE HEADING 'Variable Type' FORMAT A15
COLUMN VARIABLE_VALUE_FUNCTION HEADING 'Variable Value|Function' FORMAT A20
COLUMN VARIABLE_METHOD_FUNCTION HEADING 'Variable Method|Function' FORMAT A20

SELECT VARIABLE_NAME,
VARIABLE_TYPE,
VARIABLE_VALUE_FUNCTION,
VARIABLE_METHOD_FUNCTION
FROM DBA_EVALUATION_CONTEXT_VARS
WHERE EVALUATION_CONTEXT_OWNER = 'SUPPORT' AND
EVALUATION_CONTEXT_NAME = 'EVALCTX';

出力は次のようになります。

Variable Value       Variable Method
Variable Name   Variable Type   Function             Function
--------------- --------------- -------------------- --------------------
CURRENT_TIME    DATE            timefunc

関連項目:
「ルール評価コンテキスト」

ルール・セットの全ルールの表示

この項で説明する問合せを実行すると、ルール・セット内の全のルールに関する次の情報が表示されます。

- ルールの所有者。

- ルールの名前。

- 存在する場合は、ルールの評価コンテキスト。ルールに評価コンテキストがなく、そのルールをルール・セットに追加するときにADD_RULEプロシージャで評価コンテキストが指定されていない場合は、ルール・セットの評価コンテキストが継承されます。

- ルールに評価コンテキストがある場合は、評価コンテキストの所有者。

たとえば、ユーザーstrmadminが所有するoe_queue_rというルール・セット内のルールごとにこの情報を表示するには、次の問合せを実行します。

COLUMN RULE_OWNER HEADING 'Rule Owner' FORMAT A10
COLUMN RULE_NAME HEADING 'Rule Name' FORMAT A20
COLUMN RULE_EVALUATION_CONTEXT_NAME HEADING 'Eval Context Name' FORMAT A27
COLUMN RULE_EVALUATION_CONTEXT_OWNER HEADING 'Eval Context|Owner' FORMAT A11

SELECT R.RULE_OWNER,
R.RULE_NAME,
R.RULE_EVALUATION_CONTEXT_NAME,
R.RULE_EVALUATION_CONTEXT_OWNER
FROM DBA_RULES R, DBA_RULE_SET_RULES RS
WHERE RS.RULE_SET_OWNER = 'STRMADMIN' AND
RS.RULE_SET_NAME = 'OE_QUEUE_R' AND
RS.RULE_NAME = R.RULE_NAME AND
RS.RULE_OWNER = R.RULE_OWNER;

出力は次のようになります。

Eval Contex
Rule Owner Rule Name            Eval Context Name           Owner
---------- -------------------- --------------------------- -----------
STRMADMIN  HR1                  STREAMS$_EVALUATION_CONTEXT SYS
STRMADMIN  APPLY_LCRS           STREAMS$_EVALUATION_CONTEXT SYS
STRMADMIN  OE_QUEUE$3
STRMADMIN  APPLY_ACTION

ルール・セット内の各ルールの条件の表示

次の問合せでは、ユーザーstrmadminが所有するルール・セットhr_queue_r内の各ルールについて前述の条件が表示されます。

SET LONGCHUNKSIZE 4000
SET LONG 4000
COLUMN RULE_OWNER HEADING 'Rule Owner' FORMAT A15
COLUMN RULE_NAME HEADING 'Rule Name' FORMAT A15
COLUMN RULE_CONDITION HEADING 'Rule Condition' FORMAT A45

SELECT R.RULE_OWNER,
R.RULE_NAME,
R.RULE_CONDITION
FROM DBA_RULES R, DBA_RULE_SET_RULES RS
WHERE RS.RULE_SET_OWNER = 'STRMADMIN' AND
RS.RULE_SET_NAME = 'HR_QUEUE_R' AND
RS.RULE_NAME = R.RULE_NAME AND
RS.RULE_OWNER = R.RULE_OWNER;

出力は次のようになります。

Rule Owner      Rule Name       Rule Condition
--------------- --------------- ---------------------------------------------
STRMADMIN       APPLY_ACTION     hr.get_hr_action(tab.user_data) = 'APPLY'
STRMADMIN       APPLY_LCRS      :dml.get_object_owner() = 'HR' AND  (:dml.get
_object_name() = 'DEPARTMENTS' OR
:dml.get_object_name() = 'EMPLOYEES')

STRMADMIN       HR_QUEUE$3      hr.get_hr_action(tab.user_data) != 'APPLY'

関連項目:

- 「ルール条件」

- 「システム作成ルール」

条件に指定パターンが含まれる各ルールのリスト表示

条件に指定パターンが含まれるデータベース内の各ルールをリストするには、DBMS_RULESデータ・ディクショナリ・ビューを問い合せ、DBMS_LOB.INSTRファンクションを使用して、ルール条件のパターンを検索します。たとえば、次の問合せでは、条件にパターン'HR'が含まれる各ルールがリストされます。

COLUMN RULE_OWNER HEADING 'Rule Owner' FORMAT A30
COLUMN RULE_NAME HEADING 'Rule Name' FORMAT A30

SELECT RULE_OWNER, RULE_NAME FROM DBA_RULES
WHERE DBMS_LOB.INSTR(RULE_CONDITION, 'HR', 1, 1) > 0;

出力は次のようになります。

Rule Owner                     Rule Name
------------------------------ ------------------------------
STRMADMIN                      DEPARTMENTS4
STRMADMIN                      DEPARTMENTS5
STRMADMIN                      DEPARTMENTS6

すべてのルール・セット評価の総合統計の表示

データベース・インスタンスが最後に起動された後に実行されたすべてのルール・セット評価に関する統計を表示するには、V$RULE_SET_AGGREGATE_STATS動的パフォーマンス・ビューを問い合せます。

この項の問合せを実行すると、ルール・セット評価に関する次の情報が表示されます。

- ルール・セット評価の数。

- 最初のヒットで停止するように指示されたルール・セット評価の数。

- 単純ルールのみを評価するように指示されたルール・セット評価の数。

- SQLを発行しないでルール・セットが評価された回数。一般に、SQLを発行してルールを評価すると、発行しない場合よりコストが高くなります。

- ルール・セット評価にかかったCPUタイム(センチセカンド)。

- ルール・セット評価にかかった時間(センチセカンド)。

- ルール・セット内のルールを評価するために発行されたSQLの数。

- ルール・セット評価中に処理されたルール条件の数。

- ルール・エンジン・クライアントに返されたTRUEルールの数。

- ルール・エンジン ・クライアントに返されたMAYBEルールの数。

- ルール・セット評価中に、変数値ファンクション、変数メソッド・ファンクションおよび評価ファンクションがコールされた回数。

次の問合せを実行すると、前述の情報が表示されます。

COLUMN NAME HEADING 'Name of Statistic' FORMAT A55
COLUMN VALUE HEADING 'Value' FORMAT 999999999

SELECT NAME, VALUE FROM V$RULE_SET_AGGREGATE_STATS;

出力は次のようになります。

Name of Statistic                                            Value
------------------------------------------------------- ----------
rule set evaluations (all)                                    5584
rule set evaluations (first_hit)                              5584
rule set evaluations (simple_rules_only)                      3675
rule set evaluations (SQL free)                               5584
rule set evaluation time (CPU)                                 179
rule set evaluation time (elapsed)                            1053
rule set SQL executions                                          0
rule set conditions processed                                11551
rule set true rules                                             10
rule set maybe rules                                           328
rule set user function calls (variable value function)         182
rule set user function calls (variable method function)      12794
rule set user function calls (evaluation function)            3857

注意:
センチセカンドは、100分の1秒です。そのため、たとえば、前述の出力では、CPUタイムが1.79秒、経過時間が10.53秒です。

各ルール・セットの評価に関する情報の表示

データベース・インスタンスが最後に起動された後に実行されたすべてのルール・セットの評価に関する情報を表示するには、V$RULE_SET動的パフォーマンス・ビューを問い合せます。この項で説明する問合せを実行すると、データベース内の各ルール・セットに関する次の情報が表示されます。

- ルール・セットの所有者

- ルール・セットの名前。

- データベース・インスタンスが前回起動してから実施されたルール・セット評価の合計数。

- データベース・インスタンスが最後に起動されてからルールを評価するためにSQLが実行された回数。一般に、SQLを発行してルールを評価すると、発行しない場合よりコストが高くなります。

- データベース・インスタンスが最後に起動されてから、SQLを発行せずに実行されたルール・セット評価の合計数。

- データベース・インスタンスが最後に起動されてから、ルール・セットを使用してルール・エンジン・クライアントに返されたTRUEルールの合計数。

- データベース・インスタンスが最後に起動されてから、ルール・セットを使用してルール・エンジン・クライアントに戻されたMAYBEルールの合計数。

次の問合せを実行すると、データベース内の各ルール・セットに関する前述の情報が表示されます。

COLUMN OWNER HEADING 'Rule Set|Owner' FORMAT A9
COLUMN NAME HEADING 'Rule Set|Name' FORMAT A11
COLUMN EVALUATIONS HEADING 'Total|Evaluations' FORMAT 99999999
COLUMN SQL_EXECUTIONS HEADING 'SQL|Executions' FORMAT 99999999
COLUMN SQL_FREE_EVALUATIONS HEADING 'SQL Free|Evaluations' FORMAT 99999999
COLUMN TRUE_RULES HEADING 'True|Rules' FORMAT 999999999
COLUMN MAYBE_RULES HEADING 'Maybe|Rules' FORMAT 99999999

SELECT OWNER,
NAME,
EVALUATIONS,
SQL_EXECUTIONS,
SQL_FREE_EVALUATIONS,
TRUE_RULES,
MAYBE_RULES
FROM V$RULE_SET;

出力は次のようになります。

Rule Set  Rule Set          Total        SQL    SQL Free       True     Maybe
Owner     Name        Evaluations Executions Evaluations      Rules     Rules
--------- ----------- ----------- ---------- ----------- ---------- ---------
SYS       ALERT_QUE_R           3          0           0          2         0
STRMADMIN RULESET$_4           86          0           0         43         1
STRMADMIN RULESET$_11         458          0           0         11         0
STRMADMIN RULESET$_9           87          0           0          1        42
STRMADMIN RULESET$_7           87          0           0         44         1

注意:
データベースのライブラリ・キャッシュのサイズが大きい場合、V$RULE_SETビューを問い合せると、パフォーマンスが低下するおそれがあります。

各ルール・セットの評価に使用されたリソースの判断

データベース・インスタンスが最後に起動された後のルール・セットの評価で使用されたリソースを判断するには、V$RULE_SET動的パフォーマンス・ビューを問い合せます。データベース・インスタンスが最後に起動されてからルール・セットが複数回評価されている場合、CPUタイム、評価時間、使用された共有メモリー(バイト)などの一部の統計は累積されます。

この項で説明する問合せを実行すると、データベース内の各ルール・セットに関する次の情報が表示されます。

- ルール・セットの所有者

- ルール・セットの名前

- データベース・インスタンスが最後に起動された後のルール・セット評価に使用された合計CPUタイム(秒)

- データベース・インスタンスが最後に起動された後のルール・セット評価に使用された合計時間(秒)

- データベース・インスタンスが最後に起動された後のルール・セット評価に使用された共有メモリーの合計量(バイト)

次の問合せを実行すると、データベース内の各ルール・セットに関する前述の情報が表示されます。

COLUMN OWNER HEADING 'Rule Set|Owner' FORMAT A15
COLUMN NAME HEADING 'Rule Set Name' FORMAT A15
COLUMN CPU_SECONDS HEADING 'Seconds|of CPU|Time' FORMAT 999999.999
COLUMN ELAPSED_SECONDS HEADING 'Seconds of|Evaluation|Time' FORMAT 999999.999
COLUMN SHARABLE_MEM HEADING 'Bytes|of Shared|Memory' FORMAT 999999999

SELECT OWNER,
NAME,
(CPU_TIME/100) CPU_SECONDS,
(ELAPSED_TIME/100) ELAPSED_SECONDS,
SHARABLE_MEM
FROM V$RULE_SET;

出力は次のようになります。

Seconds  Seconds of      Bytes
Rule Set                             of CPU  Evaluation  of Shared
Owner           Rule Set Name          Time        Time     Memory
--------------- --------------- ----------- ----------- ----------
SYS             ALERT_QUE_R            .230        .490      25120
STRMADMIN       RULESET$_4             .060        .970      25097
STRMADMIN       RULESET$_11            .040        .030      25098
STRMADMIN       RULESET$_9             .220       3.040      25505
STRMADMIN       RULESET$_7             .040        .380      21313

注意:
データベースのライブラリ・キャッシュのサイズが大きい場合、V$RULE_SETビューを問い合せると、パフォーマンスが低下するおそれがあります。

ルールの評価統計の表示

データベース・インスタンスが最後に起動された後に実行された特定ルールの評価統計を表示するには、V$RULE動的パフォーマンス・ビューを問い合せます。この項で説明する問合せを実行すると、データベース内の各ルール・セットに関する次の情報が表示されます。

- データベース・インスタンスが最後に起動されてから、ルールがTRUEと評価された合計回数。

- データベース・インスタンスが最後に起動されてから、ルールがMAYBEと評価された合計回数。

- データベース・インスタンスが最後に起動されてから、SQLを発行したルール評価の合計数。一般的に、SQLを発行してルールを評価すると、発行しない場合よりコストが高くなります。

たとえば、次の問合せを実行すると、strmadminスキーマのlocations25ルールに関する前述の情報が表示されます。

COLUMN TRUE_HITS HEADING 'True Evaluations' FORMAT 99999999999
COLUMN MAYBE_HITS HEADING 'Maybe Evaluations' FORMAT 99999999999
COLUMN SQL_EVALUATIONS HEADING 'SQL Evaluations' FORMAT 99999999999

SELECT TRUE_HITS, MAYBE_HITS, SQL_EVALUATIONS
FROM V$RULE
WHERE RULE_OWNER = 'STRMADMIN' AND
RULE_NAME  = 'LOCATIONS25';

出力は次のようになります。

True Evaluations Maybe Evaluations SQL Evaluations
---------------- ----------------- ---------------
1518               154               0

28 ルールベースの変換の監視

ルールベースの変換は、ポジティブ・ルール・セットのルールがTRUEに評価される場合に発生するメッセージへの変更です。この章では、ルールベースの変換の監視に使用できる問合せの例を示します。

次の各項では、ルールベースの変換の監視について説明します。

- すべてのルールベースの変換に関する情報の表示

- 宣言ルールベースの変換の表示

- カスタム・ルールベースの変換の表示

注意:
Oracle Enterprise ManagerのOracle Streamsツールも、Oracle Streams環境を監視するための優れた手段です。詳細は、Oracle Streamsツールのオンライン・ヘルプを参照してください。

関連項目:

- 第6章「ルールベースの変換」

- 第19章「ルールベースの変換の管理」

- この章で説明するデータ・ディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照

すべてのルールベースの変換に関する情報の表示

この項で説明する問合せを実行すると、データベース内の各ルールベースの変換に関する次の情報が表示されます。

- ルールベースの変換が指定されたルールの所有者

- ルールベースの変換が指定されたルールの名前

- ルールベースの変換のタイプ

- 内部のルールベースの変換を使用するサブセット・ルールの場合は、SUBSET RULEと表示されます。

- 宣言ルールベースの変換の場合は、DECLARATIVE TRANSFORMATIONと表示されます。

- カスタム・ルールベースの変換の場合は、CUSTOM TRANSFORMATIONと表示されます。

次の問合せを実行すると、データベース内のルールベースの変換に関する前述の情報が表示されます。

COLUMN RULE_OWNER HEADING 'Rule Owner' FORMAT A20
COLUMN RULE_NAME HEADING 'Rule Name' FORMAT A20
COLUMN TRANSFORM_TYPE HEADING 'Transformation Type' FORMAT A30

SELECT RULE_OWNER,
RULE_NAME,
TRANSFORM_TYPE
FROM DBA_STREAMS_TRANSFORMATIONS;

出力は次のようになります。

Rule Owner           Rule Name            Transformation Type
-------------------- -------------------- ------------------------------
STRMADMIN            EMPLOYEES23          DECLARATIVE TRANSFORMATION
STRMADMIN            JOBS26               DECLARATIVE TRANSFORMATION
STRMADMIN            DEPARTMENTS33        SUBSET RULE
STRMADMIN            DEPARTMENTS32        SUBSET RULE
STRMADMIN            DEPARTMENTS34        SUBSET RULE
STRMADMIN            DEPARTMENTS32        CUSTOM TRANSFORMATION
STRMADMIN            DEPARTMENTS33        CUSTOM TRANSFORMATION
STRMADMIN            DEPARTMENTS34        CUSTOM TRANSFORMATION

宣言ルールベースの変換の表示

宣言ルールベースの変換は、行LCRの一般的な変換シナリオに対応するルールベースの変換です。宣言ルールベースの変換は、PL/SQLを使用せずに内部的に実行されます。

この項で説明する問合せを実行すると、データベース内の各宣言ルールベースの変換に関する次の情報が表示されます。

- 宣言ルールベースの変換が指定されたルールの所有者

- 宣言ルールベースの変換が指定されたルールの名前

- 指定された宣言ルールベースの変換のタイプ。ADD COLUMN、DELETE COLUMN、KEEP COLUMNS、RENAME COLUMN、RENAME SCHEMAおよびRENAME TABLEの各タイプが表示される可能性があります。

- 宣言ルールベースの変換の優先順位。この優先順位は、同じルールに指定されている同じ手順番号の他の変換に対する、変換の実行順序です。手順番号が同じ変換では、優先順位が最も低い変換が最初に実行されます。

- 宣言ルールベースの変換の手順番号。複数の宣言ルールベースの変換が同じルールに指定された場合、手順番号が最も小さい変換が最初に実行されます。変換を作成する際に、宣言ルールベースの変換の手順番号を指定できます。

次の問合せを実行すると、データベース内の宣言ルールベースの変換に関する情報が表示されます。

COLUMN RULE_OWNER HEADING 'Rule Owner' FORMAT A15
COLUMN RULE_NAME HEADING 'Rule Name' FORMAT A15
COLUMN DECLARATIVE_TYPE HEADING 'Declarative|Type' FORMAT A15
COLUMN PRECEDENCE HEADING 'Precedence' FORMAT 99999
COLUMN STEP_NUMBER HEADING 'Step Number' FORMAT 99999

SELECT RULE_OWNER,
RULE_NAME,
DECLARATIVE_TYPE,
PRECEDENCE,
STEP_NUMBER
FROM DBA_STREAMS_TRANSFORMATIONS
WHERE TRANSFORM_TYPE = 'DECLARATIVE TRANSFORMATION';

出力は次のようになります。

Declarative
Rule Owner      Rule Name       Type            Precedence Step Number
--------------- --------------- --------------- ---------- -----------
STRMADMIN       JOBS26          RENAME TABLE             4           0
STRMADMIN       EMPLOYEES23     ADD COLUMN               3           0

この出力から、変換の手順番号が同じ(0(ゼロ))で、ADD COLUMN変換の優先順位が低いため、ADD COLUMN変換がRENAME TABLE変換より前に実行されることがわかります。

データベースに存在する宣言ルールベースの変換のタイプを判別する場合は、各変換の詳細を表示できます。次のデータ・ディクショナリ・ビューには、様々なタイプの宣言ルールベースの変換の詳細が含まれます。

- DBA_STREAMS_ADD_COLUMNビューには、ADD COLUMN宣言変換に関する情報が含まれます。

- DBA_STREAMS_DELETE_COLUMNビューには、DELETE COLUMN宣言変換に関する情報が含まれます。

- DBA_STREAMS_KEEP_COLUMNSビューには、KEEP COLUMNS宣言変換に関する情報が含まれます。

- DBA_STREAMS_RENAME_COLUMNビューには、RENAME COLUMN宣言変換に関する情報が含まれます。

- DBA_STREAMS_RENAME_SCHEMAビューには、RENAME SCHEMA宣言変換に関する情報が含まれます。

- DBA_STREAMS_RENAME_TABLEビューには、RENAME TABLE宣言変換に関する情報が含まれます。

たとえば、前述の問合せではADD COLUMN変換およびRENAME TABLE変換が表示されます。次の各項では、これらの変換の詳細情報を表示する問合せを示します。

- ADD COLUMN変換に関する情報の表示

- RENAME TABLE変換に関する情報の表示

注意:
優先順位および手順番号は、宣言ルールベースの変換のみに関連します。サブセット・ルール変換またはカスタム・ルールベースの変換には関連しません。

関連項目:

- 「宣言ルールベースの変換」

- 「宣言ルールベースの変換の管理」

ADD COLUMN変換に関する情報の表示

次の問合せを実行すると、データベース内のADD COLUMN 宣言ルールベースの変換に関する詳細情報が表示されます。

COLUMN RULE_OWNER HEADING 'Rule|Owner' FORMAT A9
COLUMN RULE_NAME HEADING 'Rule|Name' FORMAT A12
COLUMN SCHEMA_NAME HEADING 'Schema|Name' FORMAT A6
COLUMN TABLE_NAME HEADING 'Table|Name' FORMAT A9
COLUMN COLUMN_NAME HEADING 'Column|Name' FORMAT A10
COLUMN COLUMN_TYPE HEADING 'Column|Type' FORMAT A8

SELECT RULE_OWNER,
RULE_NAME,
SCHEMA_NAME,
TABLE_NAME,
COLUMN_NAME,
ANYDATA.AccessDate(COLUMN_VALUE) "Value",
COLUMN_TYPE
FROM DBA_STREAMS_ADD_COLUMN;

出力は次のようになります。

Rule      Rule         Schema Table     Column                          Column
Owner     Name         Name   Name      Name       Value                Type
--------- ------------ ------ --------- ---------- -------------------- --------
STRMADMIN EMPLOYEES23  HR     EMPLOYEES BIRTH_DATE                      SYS.DATE

この出力には、ADD COLUMN宣言ルールベースの変換に関する次の情報が表示されています。

- この変換は、strmadminスキーマのemployees23ルールに対して指定されています。

- この変換によって、hrスキーマのemployees表を含む行LCRに列が追加されています。

- 追加された列の列名はbirth_dateです。

- 追加された列の値はNULLです。DBA_STREAMS_ADD_COLUMNビューのCOLUMN_VALUE列の型がANYDATAであることに注意してください。この例では、列の型がDATEであるため、ANYDATA.AccessDateメンバー・ファンクションを使用して値が表示されています。他の型の値を表示するには、適切なメンバー・ファンクションを使用します。

- 追加された列の型はDATEです。

RENAME TABLE変換に関する情報の表示

次の問合せを実行すると、データベース内のRENAME TABLE 宣言ルールベースの変換に関する詳細情報が表示されます。

COLUMN RULE_OWNER HEADING 'Rule|Owner' FORMAT A10
COLUMN RULE_NAME HEADING 'Rule|Name' FORMAT A10
COLUMN FROM_SCHEMA_NAME HEADING 'From|Schema|Name' FORMAT A10
COLUMN TO_SCHEMA_NAME HEADING 'To|Schema|Name' FORMAT A10
COLUMN FROM_TABLE_NAME HEADING 'From|Table|Name' FORMAT A15
COLUMN TO_TABLE_NAME HEADING 'To|Table|Name' FORMAT A15

SELECT RULE_OWNER,
RULE_NAME,
FROM_SCHEMA_NAME,
TO_SCHEMA_NAME,
FROM_TABLE_NAME,
TO_TABLE_NAME
FROM DBA_STREAMS_RENAME_TABLE;

出力は次のようになります。

From       To         From            To
Rule       Rule       Schema     Schema     Table           Table
Owner      Name       Name       Name       Name            Name
---------- ---------- ---------- ---------- --------------- ---------------
STRMADMIN  JOBS26     HR         HR         JOBS            ASSIGNMENTS

この出力には、RENAME TABLE宣言ルールベースの変換に関する次の情報が表示されています。

- この変換は、strmadminスキーマのjobs26ルールに対して指定されています。

- この変換によって、行LCR内のhr.jobs表の名前が、hr.assignments表に変更されています。

カスタム・ルールベースの変換の表示

カスタム・ルールベースの変換は、ユーザー定義PL/SQLファンクションが必要なルールベースの変換です。この項で説明する問合せを実行すると、データベース内の指定されたカスタム・ルールベースの変換に関する次の情報が表示されます。

- このカスタム・ルールベースの変換が設定されたルールの所有者

- このカスタム・ルールベースの変換が設定されたルールの名前

- 変換ファンクションの所有者および名前

- このカスタム・ルールベースの変換が1対1と1対多のどちらであるか

次の問合せを実行すると、前述の情報が表示されます。

COLUMN RULE_OWNER HEADING 'Rule Owner' FORMAT A20
COLUMN RULE_NAME HEADING 'Rule Name' FORMAT A15
COLUMN TRANSFORM_FUNCTION_NAME HEADING 'Transformation Function' FORMAT A30
COLUMN CUSTOM_TYPE HEADING 'Type' FORMAT A11

SELECT RULE_OWNER, RULE_NAME, TRANSFORM_FUNCTION_NAME, CUSTOM_TYPE
FROM DBA_STREAMS_TRANSFORM_FUNCTION;

出力は次のようになります。

Rule Owner           Rule Name       Transformation Function        Type
-------------------- --------------- ------------------------------ -----------
STRMADMIN            DEPARTMENTS31   "HR"."EXECUTIVE_TO_MANAGEMENT" ONE TO ONE
STRMADMIN            DEPARTMENTS32   "HR"."EXECUTIVE_TO_MANAGEMENT" ONE TO ONE
STRMADMIN            DEPARTMENTS33   "HR"."EXECUTIVE_TO_MANAGEMENT" ONE TO ONE

注意:
変換ファンクション名はVARCHAR2型にする必要があります。そうでない場合、TRANSFORM_FUNCTION_NAMEの値がNULLになります。DBA_STREAMS_TRANSFORM_FUNCTIONビューのVALUE_TYPE列には、変換ファンクション名の型が表示されます。

関連項目:

- 「カスタム・ルールベースの変換」

- 「カスタム・ルールベースの変換の管理」

29 その他のOracle Streamsコンポーネントの監視

この章では、様々なOracle Streamsコンポーネントの監視に使用できる問合せの例を示します。

次の各項では、様々なOracle Streamsコンポーネントの監視について説明します。

- Oracle Streams管理者とその他のOracle Streamsユーザーの監視

- Oracle Streamsプールの監視

- Oracle Streams環境での互換性の監視

- AWRおよびStatspackを使用したOracle Streamsのパフォーマンスの監視

注意:
Oracle Enterprise ManagerのOracle Streamsツールも、Oracle Streams環境を監視するための優れた手段です。詳細は、Oracle Streamsツールのオンライン・ヘルプを参照してください。

関連項目:
この章で説明するデータ・ディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照

Oracle Streams管理者とその他のOracle Streamsユーザーの監視

次の各項では、Oracle Streams管理者、およびリモートOracle Streams管理者にアクセスを許可する他のユーザーを表示するために実行できる問合せについて説明します。

- ローカルOracle Streams管理者の表示

- リモートOracle Streams管理者にアクセスを許可するユーザーの表示

関連項目:
DBMS_STREAMS_AUTHパッケージを使用したOracle Streams管理者およびその他のOracle Streamsユーザーの構成の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

ローカルOracle Streams管理者の表示

DBMS_STREAMS_AUTHパッケージのGRANT_ADMIN_PRIVILEGEプロシージャを実行して、ローカルOracle Streams管理者に権限を付与できます。DBA_STREAMS_ADMINISTRATORデータ・ディクショナリ・ビューには、ユーザーに対して GRANT_ADMIN_PRIVILEGEプロシージャを実行する際にgrant_privilegesパラメータをTRUEに設定して作成したローカルOracle Streams管理者のみが含まれます。生成されたスクリプトを使用してOracle Streams管理者を作成し、そのユーザーに対してGRANT_ADMIN_PRIVILEGEプロシージャを実行する際にgrant_privilegesパラメータをFALSEに設定した場合、そのユーザーはOracle Streams管理者としてDBA_STREAMS_ADMINISTRATORデータ・ディクショナリ・ビューに表示されません。

GRANT_ADMIN_PRIVILEGE プロシージャの実行時にgrant_privilegesパラメータをTRUEに設定して作成したローカルOracle Streams管理者を表示するには、次の問合せを実行します。

COLUMN USERNAME HEADING 'Local Streams Administrator' FORMAT A30

SELECT USERNAME FROM DBA_STREAMS_ADMINISTRATOR
WHERE LOCAL_PRIVILEGES = 'YES';

出力は次のようになります。

Local Streams Administrator
------------------------------
STRMADMIN

Oracle Streams管理者であるユーザーについてGRANT_ADMIN_PRIVILEGEが実行されていない可能性があります。そのような管理者は、この項の問合せによって返されません。また、ユーザーに対してGRANT_ADMIN_PRIVILEGEプロシージャが実行された後、リスト表示されたユーザーの権限を変更できます。この変更は、DBMS_STREAMS_AUTHパッケージによって実行されないかぎり、DBA_STREAMS_ADMINISTRATORビューでは追跡されません。たとえば、REVOKE SQL文を使用して、GRANT_ADMIN_PRIVILEGEプロシージャによって特定のユーザーに付与された権限を取り消すことができますが、DBA_STREAMS_ADMINISTRATORビューを問い合せるとこのユーザーが表示されます。

この項の問合せで表示されるユーザーの権限を取り消す場合は、DBMS_STREAMS_AUTHパッケージのREVOKE_ADMIN_PRIVILEGEプロシージャを使用することをお薦めします。このプロシージャを使用してユーザーの権限を取り消すと、そのユーザーはDBA_STREAMS_ADMINISTRATORビューから削除されます。

関連項目:
Oracle Streams管理者を作成する方法の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

リモートOracle Streams管理者にアクセスを許可するユーザーの表示

DBMS_STREAMS_AUTHパッケージのGRANT_REMOTE_ADMIN_ACCESSプロシージャを実行して、リモートOracle Streams管理者にアクセスを許可するユーザーを構成できます。このユーザーは、リモートOracle Streams管理者がデータベース・リンクを使用してローカル・データベース内で管理操作を実行することを許可します。

通常、ローカル・ソース・データベースで発生した変更がダウンストリーム取得プロセスによって取得される場合は、このようなユーザーをローカル・ソース・データベースで構成します。ダウンストリーム取得データベースのOracle Streams管理者は、この接続を使用してソース・データベースを管理します。

リモートOracle Streams管理者にアクセスを許可するユーザーを表示するには、次の問合せを実行します。

COLUMN USERNAME HEADING 'Users Who Allow Remote Access' FORMAT A30

SELECT USERNAME FROM DBA_STREAMS_ADMINISTRATOR
WHERE ACCESS_FROM_REMOTE = 'YES';

出力は次のようになります。

Users Who Allow Remote Access
------------------------------
STRMREMOTE

Oracle Streamsプールの監視

Oracle Streamsプールは、Oracle Streamsで使用されるシステム・グローバル領域(SGA)のメモリーの一部です。Oracle Streamsプールは、メモリー内のエンキューされたメッセージを格納し、取得プロセスおよび適用プロセスにメモリーを提供します。Oracle Streamsプールは取得プロセスで取得されたLCRを常に格納します。また、バッファ・キューに手動でエンキューされる他のタイプのメッセージも格納できます。

MEMORY_TARGET、MEMORY_MAX_TARGETまたはSGA_TARGET初期化パラメータを0(ゼロ)以外の値に設定すると、Oracle Streamsプールのサイズが自動的に管理されます。これらのパラメータをすべて0(ゼロ)に設定した場合は、STREAMS_POOL_SIZE初期化パラメータを使用して、Oracle Streamsプールのサイズをバイト単位で指定できます。この場合、STREAMS_POOL_SIZE初期化パラメータの適切な設定に関する情報がV$STREAMS_POOL_ADVICE動的パフォーマンス・ビューに表示されます。

この項では、Oracle Streamsプールのサイズを拡大、保持または縮小する場合を示す問合せの例を示します。各問合せによって、Oracle Streamsプールに関する次の情報が表示されます。

- STREAMS_POOL_SIZE_FOR_ESTIMATE: 見積り用のOracle Streamsプールのサイズ(MB単位)が表示されます。このサイズの範囲は、Oracle Streamsプールの現在のサイズより小さい値から、Oracle Streamsプールの現在のサイズより大きい値で、増分ごとに別々の行が表示されます。Oracle Streamsプールの現在のサイズを示すエントリが必ず存在し、常に20の増分があります。増分の範囲とサイズは、Oracle Streamsプールの現在のサイズによって異なります。

- STREAMS_POOL_SIZE_FACTOR: Oracle Streamsプールの現在のサイズに関連した見積りのサイズ係数が表示されます。たとえば、サイズ係数.2は、見積りがOracle Streamsプールの現在のサイズの20%に相当することを示し、サイズ係数1.6は見積りがOracle Streamsプールの現在のサイズの160%に相当することを示します。サイズ係数が1.0の行には、Oracle Streamsプールの現在のサイズが表示されます。

- ESTD_SPILL_COUNT: 問合せによって返されるSTREAMS_POOL_SIZE_FOR_ESTIMATEおよびSTREAMS_POOL_SIZE_FACTORごとに、メモリーからオーバーフローしてキュー表に入れられるメッセージの見積り数が表示されます。

- ESTD_SPILL_TIME: 問合せによって返されるSTREAMS_POOL_SIZE_FOR_ESTIMATEおよびSTREAMS_POOL_SIZE_FACTORごとに、メッセージがオーバーフローしてキュー表に入れられるまでの見積り経過時間(秒単位)が表示されます。

- ESTD_UNSPILL_COUNT: 問合せによって返されるSTREAMS_POOL_SIZE_FOR_ESTIMATEおよびSTREAMS_POOL_SIZE_FACTORごとに、オーバーフローしたメッセージがキュー表からメモリーに戻される見積り数が表示されます。

- ESTD_UNSPILL_TIME: 問合せによって返されるSTREAMS_POOL_SIZE_FOR_ESTIMATEおよびSTREAMS_POOL_SIZE_FACTORごとに、オーバーフローしたメッセージがキュー表からメモリーに戻されるまでの見積り経過時間(秒単位)が表示されます。

V$STREAMS_POOL_ADVICEビューを問い合せたとき、取得プロセス、伝播または適用プロセスがいずれも無効になっていて、将来それらを有効にする予定がある場合は、Oracle Streamsプールのサイズを縮小する前に、これらのOracle Streamsクライアントに必要なメモリー・リソースを必ず考慮に入れてください。

ヒント:

- 通常、Oracle Streamsプールの最適サイズは、オーバーフローするメッセージ、オーバーフローから戻されるメッセージおよび経過時間が0(ゼロ)に近い最小のサイズです。

- 最も正確な結果を得るには、データベースで伝播および適用プロセスによって通常の量のデキュー・アクティビティが実行されているときに、V$STREAMS_POOL_ADVICEビューの問合せを実行します。デキュー・アクティビティの量が通常より大幅に少ないか、通常より大幅に多い場合は、問合せ結果がOracle Streamsプールのサイズの調整に有効な情報でない場合があります。

関連項目:

- Oracle Streamsプールの詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- STREAMS_POOL_SIZE初期化パラメータの詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

Oracle Streamsプール・サイズの拡大が推奨される問合せ結果

V$STREAMS_POOL_ADVICEビューによって次の結果が返された場合を考えます。

COLUMN STREAMS_POOL_SIZE_FOR_ESTIMATE HEADING 'Oracle Streams Pool Size|for Estimate(MB)'
FORMAT 999999999999
COLUMN STREAMS_POOL_SIZE_FACTOR HEADING 'Oracle Streams Pool|Size|Factor' FORMAT 99.9
COLUMN ESTD_SPILL_COUNT HEADING 'Estimated|Spill|Count' FORMAT 99999999
COLUMN ESTD_SPILL_TIME HEADING 'Estimated|Spill|Time' FORMAT 99999999.99
COLUMN ESTD_UNSPILL_COUNT HEADING 'Estimated|Unspill|Count' FORMAT 99999999
COLUMN ESTD_UNSPILL_TIME HEADING 'Estimated|Unspill|Time' FORMAT 99999999.99

SELECT STREAMS_POOL_SIZE_FOR_ESTIMATE,
STREAMS_POOL_SIZE_FACTOR,
ESTD_SPILL_COUNT,
ESTD_SPILL_TIME,
ESTD_UNSPILL_COUNT,
ESTD_UNSPILL_TIME
FROM V$STREAMS_POOL_ADVICE;

Oracle Streams Pool Estimated    Estimated Estimated
Oracle Streams Pool Size                Size     Spill        Spill   Unspill
for Estimate(MB)              Factor     Count         Time     Count
------------------------ ------------------- --------- ------------ ---------
24           .1       158        62.00         0          .00
48           .2       145        59.00         0          .00
72           .3       137        53.00         0          .00
96           .4       122        50.00         0          .00
120           .5       114        48.00         0          .00
144           .6       103        45.00         0          .00
168           .7        95        39.00         0          .00
192           .8        87        32.00         0          .00
216           .9        74        26.00         0          .00
240          1.0        61        21.00         0          .00
264          1.1        56        17.00         0          .00
288          1.2        43        15.00         0          .00
312          1.3        36        11.00         0          .00
336          1.4        22         8.00         0          .00
360          1.5         9         2.00         0          .00
384          1.6         0          .00         0          .00
408          1.7         0          .00         0          .00
432          1.8         0          .00         0          .00
456          1.9         0          .00         0          .00
480          2.0         0          .00         0          .00

これらの結果から、Oracle Streamsプールの現在のサイズの160%である384MBがOracle Streamsプールの最適なサイズになります。つまり、このサイズは、オーバーフローするメッセージおよびオーバーフローから戻されるメッセージの見積り数が0(ゼロ)になる最小のサイズです。

注意:
Oracle Streamsプールのサイズを調整した後、新しいサイズがV$STREAMS_POOL_ADVICEビューの新しい出力に表示されるまでに時間がかかる場合があります。

Oracle Streamsプール・サイズの保持が推奨される問合せ結果

V$STREAMS_POOL_ADVICEビューによって次の結果が返された場合を考えます。

COLUMN STREAMS_POOL_SIZE_FOR_ESTIMATE  HEADING 'Oracle Streams Pool|Size for Estimate'
FORMAT 999999999999
COLUMN STREAMS_POOL_SIZE_FACTOR HEADING 'Oracle Streams Pool|Size|Factor' FORMAT 99.9
COLUMN ESTD_SPILL_COUNT HEADING 'Estimated|Spill|Count' FORMAT 99999999
COLUMN ESTD_SPILL_TIME HEADING 'Estimated|Spill|Time' FORMAT 99999999.99
COLUMN ESTD_UNSPILL_COUNT HEADING 'Estimated|Unspill|Count' FORMAT 99999999
COLUMN ESTD_UNSPILL_TIME HEADING 'Estimated|Unspill|Time' FORMAT 99999999.99

SELECT STREAMS_POOL_SIZE_FOR_ESTIMATE,
STREAMS_POOL_SIZE_FACTOR,
ESTD_SPILL_COUNT,
ESTD_SPILL_TIME,
ESTD_UNSPILL_COUNT,
ESTD_UNSPILL_TIME
FROM V$STREAMS_POOL_ADVICE;

Oracle Streams Pool Estimated    Estimated Estimated
Oracle Streams Pool Size                Size     Spill        Spill   Unspill
for Estimate(MB)              Factor     Count         Time     Count
------------------------ ------------------- --------- ------------ ---------
24           .1        89        52.00         0          .00
48           .2        78        48.00         0          .00
72           .3        71        43.00         0          .00
96           .4        66        37.00         0          .00
120           .5        59        32.00         0          .00
144           .6        52        26.00         0          .00
168           .7        39        20.00         0          .00
192           .8        27        12.00         0          .00
216           .9        15         5.00         0          .00
240          1.0         0          .00         0          .00
264          1.1         0          .00         0          .00
288          1.2         0          .00         0          .00
312          1.3         0          .00         0          .00
336          1.4         0          .00         0          .00
360          1.5         0          .00         0          .00
384          1.6         0          .00         0          .00
408          1.7         0          .00         0          .00
432          1.8         0          .00         0          .00
456          1.9         0          .00         0          .00
480          2.0         0          .00         0          .00

これらの結果から、Oracle Streamsプールの現在のサイズが最適サイズになります。つまり、このサイズは、オーバーフローするメッセージおよびオーバーフローから戻されるメッセージの見積り数が0(ゼロ)になる最小のサイズです。

Oracle Streamsプール・サイズの縮小が推奨される問合せ結果

V$STREAMS_POOL_ADVICEビューによって次の結果が返された場合を考えます。

COLUMN STREAMS_POOL_SIZE_FOR_ESTIMATE  HEADING 'Oracle Streams Pool|Size for Estimate'
FORMAT 999999999999
COLUMN STREAMS_POOL_SIZE_FACTOR HEADING 'Oracle Streams Pool|Size|Factor' FORMAT 99.9
COLUMN ESTD_SPILL_COUNT HEADING 'Estimated|Spill|Count' FORMAT 99999999
COLUMN ESTD_SPILL_TIME HEADING 'Estimated|Spill|Time' FORMAT 99999999.99
COLUMN ESTD_UNSPILL_COUNT HEADING 'Estimated|Unspill|Count' FORMAT 99999999
COLUMN ESTD_UNSPILL_TIME HEADING 'Estimated|Unspill|Time' FORMAT 99999999.99

SELECT STREAMS_POOL_SIZE_FOR_ESTIMATE,
STREAMS_POOL_SIZE_FACTOR,
ESTD_SPILL_COUNT,
ESTD_SPILL_TIME,
ESTD_UNSPILL_COUNT,
ESTD_UNSPILL_TIME
FROM V$STREAMS_POOL_ADVICE;

Oracle Streams Pool Estimated    Estimated Estimated
Oracle Streams Pool Size                Size     Spill        Spill   Unspill
for Estimate(MB)              Factor     Count         Time     Count
------------------------ ------------------- --------- ------------ ---------
24           .1       158        62.00         0          .00
48           .2       145        59.00         0          .00
72           .3       137        53.00         0          .00
96           .4       122        50.00         0          .00
120           .5       114        48.00         0          .00
144           .6       103        45.00         0          .00
168           .7         0          .00         0          .00
192           .8         0          .00         0          .00
216           .9         0          .00         0          .00
240          1.0         0          .00         0          .00
264          1.1         0          .00         0          .00
288          1.2         0          .00         0          .00
312          1.3         0          .00         0          .00
336          1.4         0          .00         0          .00
360          1.5         0          .00         0          .00
384          1.6         0          .00         0          .00
408          1.7         0          .00         0          .00
432          1.8         0          .00         0          .00
456          1.9         0          .00         0          .00
480          2.0         0          .00         0          .00

これらの結果から、Oracle Streamsプールの現在のサイズの70%である168MBがOracle Streamsプールの最適なサイズになります。つまり、このサイズは、オーバーフローするメッセージおよびオーバーフローから戻されるメッセージの見積り数が0(ゼロ)になる最小のサイズです。

注意:
Oracle Streamsプールのサイズを調整した後、新しいサイズがV$STREAMS_POOL_ADVICEビューの新しい出力に表示されるまでに時間がかかる場合があります。

Oracle Streams環境での互換性の監視

一部のデータベース・オブジェクトおよびデータ型には、Oracle Streamsの取得プロセス、同期取得および適用プロセスとの互換性がありません。そのいずれかのOracle Streamsクライアントで、サポートされないオブジェクトまたはデータ型の処理が試行されると、エラーが発生します。

次の項の問合せでは、ローカル・データベース内のデータベース・オブジェクトおよび列に対するOracle Streamsの互換性を示します。

- 取得プロセスに対する互換性の監視

- 同期取得と互換性のないデータベース・オブジェクトおよび列の表示

- 適用プロセスに対する互換性の監視

取得プロセスに対する互換性の監視

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

- 取得プロセスと互換性のないデータベース・オブジェクトの表示

- 最近取得プロセスとの互換性を持つようになったデータベース・オブジェクトの表示

取得プロセスと互換性のないデータベース・オブジェクトの表示

取得プロセスでデータベース・オブジェクトに対する変更を取得できない場合は、そのデータベース・オブジェクトに取得プロセスとの互換性がありません。この項の問合せでは、取得プロセスと互換性のないデータベース・オブジェクトに関して次の情報が表示されます。

- オブジェクトの所有者

- オブジェクト名

- オブジェクトと取得プロセスに互換性がない理由

- 取得プロセスによってデータベース・オブジェクトに対する変更が自動的にフィルタ処理で除外されるかどうか(AUTO_FILTERED列)

取得プロセスによってデータベース・オブジェクトに対する変更が自動的にフィルタ処理で除外される場合は、取得プロセスでルール・セットを使用して明示的にフィルタ処理で除外する必要はありません。たとえば、ドメイン索引に対する変更は、取得プロセスによって自動的にフィルタ処理で除外されます。ただし、互換性のないデータベース・オブジェクトに対する変更が自動的にフィルタ処理で除外されない場合は、エラーを回避するために、各取得プロセスでルール・セットを使用してフィルタ処理で除外する必要があります。

たとえば、取得プロセスのルール・セットで、取得プロセスが、特定のスキーマに対して行われたすべての変更を取得するように指示されているとします。また、この項の問合せによって、このスキーマ内の1つのオブジェクトが取得プロセスと互換性がなく、そのオブジェクトに対する変更が自動的にはフィルタ処理で除外されないことが示されたとします。この場合、取得プロセスのネガティブ・ルール・セットにルールを追加して、互換性のないデータベース・オブジェクトの変更をフィルタ処理で除外できます。

取得プロセスと互換性のないローカル・データベース内のデータベース・オブジェクトを表示するには、次の問合せを実行します。

COLUMN OWNER HEADING 'Object|Owner' FORMAT A8
COLUMN TABLE_NAME HEADING 'Object Name' FORMAT A30
COLUMN REASON HEADING 'Reason' FORMAT A30
COLUMN AUTO_FILTERED HEADING 'Auto|Filtered?' FORMAT A9

SELECT OWNER, TABLE_NAME, REASON, AUTO_FILTERED FROM DBA_STREAMS_UNSUPPORTED;

出力は次のようになります。

Object                                                                 Auto
Owner    Object Name                    Reason                         Filtered?
-------- ------------------------------ ------------------------------ ---------
IX       AQ$_ORDERS_QUEUETABLE_G        column with user-defined type  NO
IX       AQ$_ORDERS_QUEUETABLE_H        unsupported column exists      NO
IX       AQ$_ORDERS_QUEUETABLE_I        unsupported column exists      NO
IX       AQ$_ORDERS_QUEUETABLE_L        AQ queue table                 NO
IX       AQ$_ORDERS_QUEUETABLE_S        AQ queue table                 NO
IX       AQ$_ORDERS_QUEUETABLE_T        AQ queue table                 NO
IX       AQ$_STREAMS_QUEUE_TABLE_C      AQ queue table                 NO
IX       AQ$_STREAMS_QUEUE_TABLE_G      column with user-defined type  NO
IX       AQ$_STREAMS_QUEUE_TABLE_H      unsupported column exists      NO
IX       AQ$_STREAMS_QUEUE_TABLE_I      unsupported column exists      NO
IX       AQ$_STREAMS_QUEUE_TABLE_L      AQ queue table                 NO
IX       AQ$_STREAMS_QUEUE_TABLE_S      AQ queue table                 NO
IX       AQ$_STREAMS_QUEUE_TABLE_T      AQ queue table                 NO
IX       ORDERS_QUEUETABLE              column with user-defined type  NO
IX       STREAMS_QUEUE_TABLE            column with user-defined type  NO
OE       ACTION_TABLE                   column with user-defined type  NO
OE       CATEGORIES_TAB                 column with user-defined type  NO
.
.
.

sh.dr$sup_text_indx$iドメイン索引のAuto Filtered?列がYESになっていることに注意してください。取得プロセスは、取得プロセスのルール・セットでこのデータベース・オブジェクトに対する変更を取得するように指示されている場合でも、それらのデータ操作言語(DML)変更を自動的にフィルタ処理で除外します。デフォルトでは、取得プロセスは、これらのデータベース・オブジェクトに対するデータ定義言語(DDL)変更もフィルタ処理で除外します。ただし、これらのDDL変更を取得する場合は、DBMS_CAPTURE_ADM.SET_PARAMETERプロシージャを使用してset_autofiltered_table_ddl取得プロセス・パラメータをNに設定し、これらのDDL変更を取得するように取得プロセス・ルール・セットを構成します。

出力例に表示されている他のデータベース・オブジェクトについてはAuto Filtered?列がNOになっているため、これらのデータベース・オブジェクトに対する変更は、取得プロセスによって自動的にはフィルタ処理で除外されません。取得プロセスで、これらのサポートされていないデータベース・オブジェクトに対する変更を処理しようすると、エラーが生成されます。ただし、これらのエラーは、サポートされていないオブジェクトに対する変更を取得しないように取得プロセスに指示するルール・セットを構成して回避できます。

注意:

- この項の問合せの結果は、データベースの互換レベルによって異なります。互換レベルが低くなると、取得プロセスと互換性のないデータベース・オブジェクトの数が多くなります。データベースの互換レベルは、COMPATIBLE初期化パラメータによって制御されます。

- 取得プロセスについては、ルールベースの変換を使用して、サポートされなていないデータ型の列を除外できません。取得エラーを回避するには、データベース・オブジェクト全体を除外する必要があります。

- DBA_STREAMS_UNSUPPORTEDビューは、Oracle Database 11g リリース1(11.1)以上のデータベースにおける取得プロセスのみに関連します。このビューは同期取得および適用プロセスには関連しません。

関連項目:

- 第5章「Oracle Streamsでのルールの使用方法」

- COMPATIBLE初期化パラメータの詳細は、『Oracle Databaseリファレンス』およびOracle Databaseアップグレード・ガイドを参照

- DBMS_CAPTURE_ADM.SET_PARAMETERプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

最近取得プロセスとの互換性を持つようになったデータベース・オブジェクトの表示

この項の問合せでは、Oracle Databaseの最近のリリースで取得プロセスとの互換性を持つようになったデータベース・オブジェクトに関する次の情報が表示されます。

- オブジェクトの所有者

- オブジェクト名

- Oracle Databaseの以前のリリースで、オブジェクトが取得プロセスとの互換性を持たなかった理由

- オブジェクトが取得プロセスとの互換性を持ったOracle Databaseのリリース

次の問合せを実行すると、ローカル・データベースに関して前述の情報が表示されます。

COLUMN OWNER HEADING 'Owner' FORMAT A10
COLUMN TABLE_NAME HEADING 'Object Name' FORMAT A20
COLUMN REASON HEADING 'Reason' FORMAT A30
COLUMN COMPATIBLE HEADING 'Compatible' FORMAT A10

SELECT OWNER, TABLE_NAME, REASON, COMPATIBLE FROM DBA_STREAMS_NEWLY_SUPPORTED;

この問合せの出力例を次に示します。

Owner      Object Name          Reason                         Compatible
---------- -------------------- ------------------------------ ----------
HR         COUNTRIES            IOT                            10.1
OE         WAREHOUSES           table with XMLType column      11.1
SH         CAL_MONTH_SALES_MV   materialized view              10.1
SH         FWEEK_PSCAT_SALES_MV materialized view              10.1

Compatible列には、取得プロセスがデータベース・オブジェクトをサポートするための最小データベース互換性が表示されます。データベース・オブジェクトのローカル・データベース互換性がCompatible列の値以上である場合は、取得プロセスによって、データベース・オブジェクトに対する変更が正常に取得できます。COMPATIBLE初期化パラメータで、データベースの互換性を制御します。

Oracle Streams環境に、異なるバージョンのOracle Databaseを実行するデータベースが含まれている場合は、LCRのGET_COMPATIBLEメンバー・ファンクションを使用して、特定のデータベースと互換性のないLCRをフィルタ処理で除外するルールを構成できます。これらのルールを取得プロセス、同期取得、伝播および適用プロセスのルール・セットに追加して、ストリーム内の必要な場所で、互換性のないLCRをフィルタ処理で除外できます。

注意:
DBA_STREAMS_NEWLY_SUPPORTEDビューは、Oracle Database 11g リリース1(11.1)以上のデータベースにおける取得プロセスのみに関連します。このビューは同期取得および適用プロセスには関連しません。

関連項目:

- COMPATIBLE初期化パラメータの詳細は、『Oracle Databaseリファレンス』およびOracle Databaseアップグレード・ガイドを参照

- 「取得プロセスと互換性のないデータベース・オブジェクトの表示」

- LCRのGET_COMPATIBLEメンバー・ファンクションを使用するルールの作成の詳細は、「サポートされていないLCRを廃棄するようにOracle Streamsクライアントに指示するルール条件」を参照

同期取得と互換性のないデータベース・オブジェクトおよび列の表示

同期取得でデータベース・オブジェクトまたは表内の列に対する変更を取得できない場合、そのデータベース・オブジェクトまたは列は同期取得と互換性がありません。たとえば、同期取得ではオブジェクト表に対する変更を取得できません。同期取得でリレーショナル表に対する変更は取得できますが、一部のデータ型の列に対する変更は取得できません。

この項の問合せでは、同期取得と互換性のないデータベース・オブジェクトおよび列に関して次の情報が表示されます。

- オブジェクトの所有者

- オブジェクト名

- 列名

- 列と同期取得に互換性がない理由

同期取得と互換性のないローカル・データベース内の列を表示するには、次の問合せを実行します。

COLUMN OWNER HEADING 'Object|Owner' FORMAT A8
COLUMN TABLE_NAME HEADING 'Object Name' FORMAT A20
COLUMN COLUMN_NAME HEADING 'Column Name' FORMAT A20
COLUMN SYNC_CAPTURE_REASON HEADING 'Synchronous|Capture Reason' FORMAT A25

SELECT OWNER,
TABLE_NAME,
COLUMN_NAME,
SYNC_CAPTURE_REASON
FROM DBA_STREAMS_COLUMNS
WHERE SYNC_CAPTURE_VERSION IS NULL;

DBA_STREAMS_COLUMNSビューの問合せでSYNC_CAPTURE_VERSIONに対してNULLが返された場合、それはこの列が同期取得でサポートされていないことを意味します。この問合せのWHERE句のため、同期取得でサポートされていない列のみが問合せによって返されます。

この問合せの出力例を次に示します。

Object                                             Synchronous
Owner    Object Name          Column Name          Capture Reason
-------- -------------------- -------------------- -------------------------
.
.
.
SH       SALES_TRANSACTIONS_E UNIT_COST            external table
XT
OE       LINEITEM_TABLE       SYS_XDBPD$           object table
OE       LINEITEM_TABLE       ITEMNUMBER           object table
PM       PRINT_MEDIA          AD_FINALTEXT         table with nested table c
olumn
.
.
.

同期取得エラーを回避するには、同期取得が、オブジェクト表などのサポートされていないデータベース・オブジェクトに対する変更を取得しようとしないように、同期取得ルール・セットを構成します。リレーショナル表に対する変更を取得する際の同期取得エラーを回避するには、次のオプションがあります。

- 同期取得が、サポートされていない1つ以上の列を含む表に対する変更を取得しようとしないように、同期取得ルール・セットを構成します。

- 同期取得でサポートされていない列を除外するルールベースの変換を構成します。

注意:
同期取得はOracle Database 11g リリース1(11.1)以上のデータベースで使用できます。それ以前のリリースのOracle Databaseでは使用できません。

関連項目:

- 同期取得によって取得されるデータ型

- 第6章「ルールベースの変換」

- 第5章「Oracle Streamsでのルールの使用方法」

適用プロセスに対する互換性の監視

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

- 適用プロセスと互換性のないデータベース・オブジェクトおよび列の表示

- 最近適用プロセスとの互換性を持つようになった列の表示

適用プロセスと互換性のないデータベース・オブジェクトおよび列の表示

適用プロセスでデータベース・オブジェクトまたは表内の列に変更を適用できない場合、そのデータベース・オブジェクトまたは列は適用プロセスと互換性がありません。たとえば、適用プロセスではリレーショナル表に変更を適用できますが、一部のデータ型の列には変更を適用できません。たとえば、適用プロセスではリレーショナル表に変更を適用できますが、一部のデータ型の列には変更を適用できません。

この項の問合せでは、適用プロセスと互換性のないデータベース・オブジェクトおよび列に関して次の情報が表示されます。

- オブジェクトの所有者

- オブジェクト名

- 列名

- 列と適用プロセスに互換性がない理由

適用プロセスと互換性のないローカル・データベース内の列を表示するには、次の問合せを実行します。

COLUMN OWNER HEADING 'Object|Owner' FORMAT A8
COLUMN TABLE_NAME HEADING 'Object Name' FORMAT A20
COLUMN COLUMN_NAME HEADING 'Column Name' FORMAT A20
COLUMN APPLY_REASON HEADING 'Apply Process Reason' FORMAT A25

SELECT OWNER,
TABLE_NAME,
COLUMN_NAME,
APPLY_REASON
FROM DBA_STREAMS_COLUMNS
WHERE APPLY_VERSION IS NULL;

DBA_STREAMS_COLUMNSビューの問合せでAPPLY_VERSIONに対してNULLが返された場合、それはこの列が適用プロセスでサポートされていないことを意味します。この問合せのWHERE句のため、適用プロセスでサポートされていない列のみが問合せによって返されます。

この問合せの出力例を次に示します。

Object
Owner    Object Name          Column Name          Apply Process Reason
-------- -------------------- -------------------- -------------------------
.
.
.
SH       SALES_TRANSACTIONS_E CHANNEL_ID           external table
XT
OE       ACTION_TABLE         ACTIONED_BY          object table
OE       LINEITEM_TABLE       PART                 object table
PM       ONLINE_MEDIA         PRODUCT_AUDIO        ADT column
OE       CATEGORIES_TAB       CATEGORY_DESCRIPTION object table
.
.
.

適用エラーを回避するには、適用プロセスが、オブジェクト表などのサポートされていないデータベース・オブジェクトに変更を適用しようとしないように、適用プロセス・ルール・セットを構成します。リレーショナル表に変更を適用する際の適用エラーを回避するには、次のオプションがあります。

- 適用プロセスが、サポートされていない1つ以上の列を含む表に変更を適用しようとしないように、適用プロセス・ルール・セットを構成します。

- 適用プロセスでサポートされていない列を除外するルールベースの変換を構成します。

- 適用プロセスでサポートされていない列を除外するプロシージャDMLハンドラを構成します。

関連項目:

- 「適用されるデータ型」

- 第6章「ルールベースの変換」

- 「DMLハンドラ」

- 第5章「Oracle Streamsでのルールの使用方法」

最近適用プロセスとの互換性を持つようになった列の表示

この項の問合せでは、Oracle Databaseの最近のリリースで適用プロセスとの互換性を持つようになったデータベース・オブジェクトおよび列に関する次の情報が表示されます。

- オブジェクトの所有者

- オブジェクト名

- 列名

- Oracle Databaseの以前のリリースで、オブジェクトが適用プロセスと互換性を持たなかった理由

- オブジェクトが適用プロセスとの互換性を持ったOracle Databaseのリリース

次の問合せを実行すると、ローカル・データベースに関して前述の情報が表示されます。

COLUMN OWNER HEADING 'Object|Owner' FORMAT A8
COLUMN TABLE_NAME HEADING 'Object Name' FORMAT A15
COLUMN COLUMN_NAME HEADING 'Column Name' FORMAT A15
COLUMN APPLY_VERSION HEADING 'Apply|Process|Vesion' FORMAT 99.9
COLUMN APPLY_REASON HEADING 'Apply|Process Reason' FORMAT A25

SELECT OWNER,
TABLE_NAME,
COLUMN_NAME,
APPLY_VERSION,
APPLY_REASON
FROM DBA_STREAMS_COLUMNS
WHERE APPLY_VERSION > 11;

DBA_STREAMS_COLUMNSビューの問合せでAPPLY_VERSIONに対してNULL以外の値が返された場合、それは適用プロセスでこの列がサポートされていることを意味します。この問合せのWHERE句のため、適用プロセスでサポートされている列のみが問合せによって返されます。この問合せでは、Oracle Database 11g リリース1以上で適用プロセスによってサポートされるようになった列が返されます。

この問合せの出力例を次に示します。

Apply
Object                                   Process Apply
Owner    Object Name     Column Name      Vesion Process Reason
-------- --------------- --------------- ------- -------------------------
OE       WAREHOUSES      WAREHOUSE_SPEC     11.1 XMLType column

Apply Process Version列には、適用プロセスがその列をサポートするための最小データベース互換性が表示されます。列のローカル・データベース互換性がApply Process Version列の値以上である場合は、適用プロセスでその列に変更を正常に適用できます。COMPATIBLE初期化パラメータで、データベースの互換性を制御します。

Oracle Streams環境に、異なるバージョンのOracle Databaseを実行するデータベースが含まれている場合は、LCRのGET_COMPATIBLEメンバー・ファンクションを使用して、特定のデータベースと互換性のないLCRをフィルタ処理で除外するルールを構成できます。これらのルールを取得プロセス、同期取得、伝播および適用プロセスのルール・セットに追加して、ストリーム内の必要な場所で、互換性のないLCRをフィルタ処理で除外できます。

注意:
この問合せでApply Process Reasonに対してNULLが返された場合、それはOracle Streamsを含む最初のOracle Databaseリリースから、この列が常に適用プロセスでサポートされていることを意味します。

関連項目:

- COMPATIBLE初期化パラメータの詳細は、『Oracle Databaseリファレンス』およびOracle Databaseアップグレード・ガイドを参照

- 「適用プロセスと互換性のないデータベース・オブジェクトおよび列の表示」

- LCRのGET_COMPATIBLEメンバー・ファンクションを使用するルールの作成の詳細は、「サポートされていないLCRを廃棄するようにOracle Streamsクライアントに指示するルール条件」を参照

AWRおよびStatspackを使用したOracle Streamsのパフォーマンスの監視

自動ワークロード・リポジトリ(AWR)を使用して、Oracle Streamsに関連するパフォーマンスの統計を監視できます。データベースでAWRが使用できない場合は、Statspackパッケージを使用して、Oracle Streamsに関連するパフォーマンスの統計を監視できます。Statspackパッケージのインストールおよび使用に関する最新の手順と情報は、データベースとともにインストールされるspdoc.txtファイルに含まれています。Statspackの詳細は、このファイルを参照してください。Unixシステムでは、このファイルはORACLE_HOME/rdbms/adminディレクトリにあります。Windowsシステムでは、このファイルはORACLE_HOME\rdbms\adminディレクトリにあります。

関連項目:

- AWRの詳細は、Oracle Databaseパフォーマンス・チューニング・ガイドを参照

- Oracle Streamsパフォーマンス・アドバイザを使用したパフォーマンスの監視の詳細は、第23章「Oracle Streamsのトポロジおよびパフォーマンスの監視」を参照

第V部

Oracle Streams環境のトラブルシューティング

この部では、Oracle Streams環境のトラブルシューティングについて説明します。この部の構成は、次のとおりです。

- 第30章「Oracle Streams環境内での問題の特定」

- 第31章「暗黙的取得のトラブルシューティング」

- 第32章「伝播のトラブルシューティング」

- 第33章「適用のトラブルシューティング」

- 第34章「ルールおよびルールベースの変換のトラブルシューティング」

30 Oracle Streams環境内での問題の特定

次の各項では、Oracle Streams環境での一般的な問題の特定と解決について説明します。

- Oracle Streamsアラートの表示

- Streams構成レポートおよびヘルス・チェック・スクリプトの使用

- 使用不可能な宛先によるパフォーマンスの問題の処理

- トレース・ファイルとアラート・ログでの問題のチェック

Oracle Streamsアラートの表示

アラートとは、潜在的に問題があったり、クリティカルのしきい値を超えた場合に発せられる警告のことです。アラートには2つのタイプがあります。

- ステートレス: 必ずしもシステムの状態と結び付かない単一イベントを示すアラート。たとえば、取得が特定のエラーで中断したことを示すアラートはステートレス・アラートです。

- ステートフル: 特定のシステム状態に関連するアラート。ステートフル・アラートは、通常は数値に基づき、警告レベルとクリティカル・レベルでしきい値が定義されます。たとえば、警告レベルが85%でクリティカル・レベルが95%の現在のOracle Streamsプール・メモリー使用率に関するアラートは、ステートフル・アラートです。

Oracle Database 11g リリース1以上のデータベースでは、次の条件下でステートレスOracle Streamsアラートが生成されます。

- 取得プロセスが中断された場合

- エラーが連続して16回発生した後に伝播が中断された場合

- 適用プロセスが中断された場合

- 空のエラー・キューのある適用プロセスで適用エラーが発生した場合

Oracle Database 11g リリース1以上のデータベースでは、次の条件下でステートフルOracle Streamsアラートが生成されます。

- Oracle Streamsプールのメモリー使用量が、STREAMS_POOL_USED_PCTメトリックに指定されたパーセンテージを超えた場合。このメトリックは、DBMS_SERVER_ALERTパッケージのSET_THRESHOLDプロシージャを使用して管理できます。

Enterprise Managerでアラートを表示するか、次のデータ・ディクショナリ・ビューを問い合せることができます。

- DBA_OUTSTANDING_ALERTSビューでは、現行のステートフル・アラートが記録されます。DBA_ALERT_HISTORYビューでは、クリアされたステートレス・アラートおよびステートフル・アラートが記録されます。たとえば、Oracle Streamsプールでのメモリー使用量が指定されたしきい値を超えると、DBA_OUTSTANDING_ALERTSビューにステートフル・アラートが記録されます。

- DBA_ALERT_HISTORYデータ・ディクショナリ・ビューには、DBA_OUTSTANDING_ALERTSビューからクリアされたアラートが表示されます。たとえば、Oracle Streamsプールでのメモリー使用量が指定されたしきい値を下回ると、DBA_OUTSTANDING_ALERTSビューに記録されていたアラートがクリアされ、DBA_ALERT_HISTORYビューに移動します。

たとえば、現行のOracle Streamsステートフル・アラートをリストするには、DBA_OUTSTANDING_ALERTSビューで次の問合せを実行します。

COLUMN REASON HEADING 'Reason for Alert' FORMAT A35
COLUMN SUGGESTED_ACTION HEADING 'Suggested Response' FORMAT A35

SELECT REASON, SUGGESTED_ACTION
FROM DBA_OUTSTANDING_ALERTS
WHERE MODULE_ID LIKE '%STREAMS%';

Oracle Streamsステートレス・アラートと、クリアされたOracle Streamsステートフル・アラートをリストするには、DBA_ALERT_HISTORYビューで次の問合せを実行します。

COLUMN REASON HEADING 'Reason for Alert' FORMAT A35
COLUMN SUGGESTED_ACTION HEADING 'Suggested Response' FORMAT A35

SELECT REASON, SUGGESTED_ACTION
FROM DBA_ALERT_HISTORY
WHERE MODULE_ID LIKE '%STREAMS%';

DBA_ALERT_HISTORYビューを問い合せた出力例を次に示します。

Reason for Alert                    Suggested Response
----------------------------------- -----------------------------------
STREAMS apply process "APPLY_EMP_DE Obtain the exact error message in d
P" aborted with ORA-26714           ba_apply, take the appropriate acti
on for this error, and restart the
apply process using dbms_apply_adm.
start_apply.  If the error is an OR
A-26714, consider setting the 'DISA
BLE_ON_ERROR' apply parameter to 'N
' to avoid aborting on future user
errors.

STREAMS error queue for apply proce Look at the contents of the error q
ss "APPLY_EMP_DEP" contains new tra ueue as well as dba_apply_error to
nsaction with ORA-26786             determine the cause of the error.
Once the errors are resolved, reexe
cute them using dbms_apply_adm.exec
ute_error or dbms_apply_adm.execute
_all_errors.

注意:
Oracle Streamsアラートは情報提供のみを目的としています。これらのアラートを管理する必要はありません。Oracle Streams環境を定期的に監視し、問題が発生したときに対処する場合は、Oracle Streamsアラートの監視は必要でない可能性があります。

関連項目:

- Oracle Streamsアラートの詳細は、Oracle Database 2日でデータ・レプリケーションおよび統合ガイドを参照

- アラートおよびメトリックしきい値の管理の詳細は、Oracle Database 2日でデータベース管理者を参照

- アラートの詳細と、新規アラートの生成時に通知を受信するためのALERT_QUEキューのサブスクライブの詳細は、『Oracle Database管理者ガイド』を参照

- DBMS_SERVER_ALERTパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

- Oracle Streamsに関連する初期化パラメータ設定の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- Oracle Streamsプールの詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

Streams構成レポートおよびヘルス・チェック・スクリプトの使用

Streams構成レポートおよびヘルス・チェック・スクリプトでは、個々のOracle DatabaseのOracle Streamsコンポーネントに関する重要な情報が提供されます。このレポートは、Oracle Streamsの前提条件を満たしているかどうかの確認、Oracle Streamsの対象データベース・オブジェクトの識別に役立ちます。また、このレポートでは、データベースのルールを分析して、Oracle Streamsルールに関する一般的な問題を特定することもできます。

Streams構成レポートおよびヘルス・チェック・スクリプトは、My Oracle Support(旧OracleMetaLink)のWebサイトで使用可能です。スクリプトを実行するには、次の手順を実行します。

1. Webブラウザを使用して、My Oracle Support Webサイトに移動します。

http://support.oracle.com/

2. My Oracle Supportにログインします。

注意:
My Oracle Supportの登録済ユーザーでない場合は、「こちらで登録してください」をクリックして登録します。

3. 次のタイトルのデータベース掲示板を検索します。

Streams Configuration Report and Health Check Script

この掲示板のドキュメントIDは273674.1です。

4. 手順に従ってご使用のリリースに対するスクリプトダウンロードし、スクリプトを実行して結果を分析します。

使用不可能な宛先によるパフォーマンスの問題の処理

Oracle Streamsレプリケーション環境のデータベースに、複数の宛先データベースに対する変更を取得する取得プロセスが1つ存在する場合、いずれかの宛先データベースが使用不可能になると、パフォーマンスの問題が発生する可能性があります。このことが発生して使用不可能な宛先に対する変更が伝播できなくなると、これらの変更は取得プロセスのキューに蓄積され、最終的にはハード・ディスクにオーバーフローします。取得データベースでメッセージがハード・ディスクにオーバーフローすると、Oracle Streamsレプリケーション環境のパフォーマンスが低下する可能性があります。V$BUFFERED_QUEUESビューを問い合せて、キュー内のメッセージ数およびハード・ディスクにオーバーフローしたメッセージ数をチェックできます。また、DBA_PROPAGATIONおよびV$PROPAGATION_SENDERビューを問い合せて、データベース内の伝播および各伝播の状態を表示することもできます。

このような状況が発生した場合は、DBMS_STREAMS_ADMパッケージのSPLIT_STREAMSおよびMERGE_STREAMS_JOBプロシージャを使用して問題に対処できます。SPLIT_STREAMSプロシージャは、問題のある宛先のストリームを取得プロセスから送られるその他のストリームから分離します。ストリームを分離することにより、宛先が使用不可能な間のパフォーマンスの問題を回避できます。宛先の問題が解決した後、MERGE_STREAMS_JOBプロシージャを使用して、そのストリームを取得プロセスから送られるその他のストリームにマージします。

関連項目:
宛先の分離およびマージの詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

トレース・ファイルとアラート・ログでの問題のチェック

各取得プロセス、伝播および適用プロセスに関するメッセージは、そのプロセスまたは伝播ジョブが実行されているデータベースのトレース・ファイルに記録されます。ローカル取得プロセスはソース・データベース、ダウンストリーム取得プロセスはダウンストリーム・データベース、伝播ジョブは伝播のソース・キューを含むデータベース、適用プロセスは宛先データベースでそれぞれ実行されます。これらのトレース・ファイル・メッセージは、Oracle Streams環境内の問題を特定し、解決するために役立ちます。

バックグラウンド・プロセスのすべてのトレース・ファイルは、自動診断リポジトリに書き込まれます。トレース・ファイル名はオペレーティング・システム固有ですが、通常、各ファイルにはそれを書き込むプロセスの名前が含まれます。

たとえば、一部のオペレーティング・システムでは、プロセスのトレース・ファイル名はsid_xxxx_iiiii.trcとなります。その意味は次のとおりです。

- sidはデータベースのシステム識別子です。

- xxxxはプロセスの名前です。

- iiiiiはオペレーティング・システムのプロセス番号です。

また、取得プロセスと適用プロセスの両方について、write_alert_logパラメータをyに設定できます。このパラメータにyを設定(デフォルト)すると、取得プロセスまたは適用プロセスが停止した理由を示すメッセージがデータベースのアラート・ログに書き込まれます。

DBMS_CAPTURE_ADMおよびDBMS_APPLY_ADMパッケージのSET_PARAMETERプロシージャを使用して取得プロセスまたは適用プロセスのtrace_levelパラメータを設定すると、トレース・ファイル内の情報を制御できます。

次のチェックリストを使用して、Oracle Streamsに関連するトレース・ファイルをチェックします。

- 取得プロセスのトレース・ファイルには、取得の問題に関するメッセージが含まれているか

- 伝播ジョブに関連するトレース・ファイルには、問題に関するメッセージが含まれているか

- 適用プロセスのトレース・ファイルには、適用の問題に関するメッセージが含まれているか

関連項目:

- トレース・ファイルおよびアラート・ログの詳細と、それらの名前および場所の詳細は、『Oracle Database管理者ガイド』を参照

- trace_level取得プロセス・パラメータおよびtrace_level適用プロセス・パラメータの設定の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

- トレース・ファイルの名前および場所の詳細は、オペレーティング・システム固有のOracleドキュメントを参照

取得プロセスのトレース・ファイルに取得の問題に関するメッセージが含まれているか

取得プロセスは、CPnnという名前のOracleバックグラウンド・プロセスです。nnには文字および番号が含まれます。たとえば、一部のオペレーティング・システムでは、取得プロセスが実行されているデータベースのシステム識別子がhqdbで、取得プロセス番号が01であれば、その取得プロセスのトレース・ファイル名はhqdb_CP01で始まります。

関連項目:
取得プロセスの取得プロセス番号を表示する問合せについては、「各取得プロセスに関する変更取得情報の表示」を参照

伝播ジョブに関連するトレース・ファイルには、問題に関するメッセージが含まれているか

各伝播では、jnnnという名前の1つ以上のスレーブ・プロセスに依存する伝播ジョブが使用されます。ここでnnnはスレーブ・プロセス番号です。たとえば、一部のオペレーティング・システムでは、スレーブ・プロセスが001であれば、そのスレーブ・プロセスのトレース・ファイル名にはj001が含まれます。DBA_QUEUE_SCHEDULESデータ・ディクショナリ・ビューのPROCESS_NAME列を問い合せると、プロセス名をチェックできます。

関連項目:
伝播ジョブで使用されるジョブ・スレーブを表示する問合せについては、「伝播が有効かどうか」を参照

適用プロセスのトレース・ファイルには、適用の問題に関するメッセージが含まれているか

適用プロセスは、APnnという名前のOracleバックグラウンド・プロセスです。nnには文字および番号が含まれます。たとえば、一部のオペレーティング・システムでは、適用プロセスが実行されているデータベースのシステム識別子がhqdbで、適用プロセス番号が01であれば、その適用プロセスのトレース・ファイル名はhqdb_AP01で始まります。

適用プロセスでは他のプロセスも使用されます。適用プロセスに関する情報は、それらの1つ以上のプロセスのトレース・ファイルに記録される可能性があります。リーダー・サーバーと適用サーバーのプロセス名はASnnであり、nnには文字および番号が含まれます。したがって、一部のオペレーティング・システムでは、適用プロセスが実行されているデータベースのシステム識別子がhqdbであり、プロセス番号が01であれば、適用プロセスで使用されるプロセスに関する情報を含むトレース・ファイルの名前はhqdb_AS01で始まります。

関連項目:

- 適用プロセスの適用プロセス番号を表示する問合せについては、「各コーディネータ・プロセスに関する一般情報の表示」を参照

- 適用プロセスのリーダー・サーバーで使用されるプロセスを表示する問合せについては、「各適用プロセスのリーダー・サーバーに関する情報の表示」を参照

- 適用プロセスの適用サーバーで使用されるプロセスを表示する問合せについては、「各適用プロセスの適用サーバーに関する情報の表示」を参照

31 暗黙的取得のトラブルシューティング

次の各項では、Oracle Streams環境での取得プロセスおよび同期取得の一般的な問題の特定と解決について説明します。

- 取得プロセスの問題のトラブルシューティング

- 同期取得に関する問題のトラブルシューティング

取得プロセスの問題のトラブルシューティング

取得プロセスで予期したとおりに変更が取得されない場合や、取得プロセスに他の問題が発生した場合は、次のチェックリストを使用し、問題を特定して解決します。

- 取得プロセスの作成またはデータ・ディクショナリのビルドに長時間を要していないか

- 取得プロセスが有効かどうか

- 取得プロセスでREDOを待機しているか

- 取得プロセスでフロー制御のために一時停止しているか

- 現行の取得プロセスかどうか

- 必須のREDOログ・ファイルが欠落していないか

- ダウンストリーム取得プロセスがREDOデータを待機していないか

- 不適切にダウンストリーム取得の構成を試行していないか

- 適切な認証を使用しないでダウンストリーム取得の構成を試行していないか

- データベース・リンクのないダウンストリーム取得に追加のアクションが必要か

関連項目:

- 「Oracle Streams取得プロセスによる暗黙的取得」

- 取得プロセスの構成の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- 「取得プロセスの管理」

- 「取得プロセスの監視」

取得プロセスの作成またはデータ・ディクショナリのビルドに長時間を要していないか

取得プロセスの作成またはデータ・ディクショナリのビルドに異常に長い時間を要している場合は、まだコミットされていない、処理中のトランザクションがあることが原因である場合があります。処理中のトランザクションとは、取得プロセスの作成時またはデータ・ディクショナリのビルド時にアクティブなトランザクションです。

処理中のトランザクションの有無を判別するには、アラート・ログで次のメッセージをチェックします。

wait for inflight txns at this scn
Done with waiting for inflight txns at this scn

アラート・ログに最初のメッセージのみが表示される場合、取得プロセスの作成またはデータ・ディクショナリのビルドは処理中のトランザクションの待機状態であり、処理中のトランザクションがすべてのコミットされた後に完了します。

関連項目:

- 取得プロセスの構成の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- 「取得プロセスの作成」

- 「トレース・ファイルとアラート・ログでの問題のチェック」

取得プロセスが有効かどうか

取得プロセスが変更を取得するのは、そのプロセスが有効になっている場合のみです。

取得プロセスが有効か、無効か、中断されているかは、DBA_CAPTUREデータ・ディクショナリ・ビューを問い合せるとチェックできます。たとえば、captureという取得プロセスが有効かどうかをチェックするには、次の問合せを実行します。

SELECT STATUS FROM DBA_CAPTURE WHERE CAPTURE_NAME = 'CAPTURE';

取得プロセスが無効の場合は、出力が次のようになります。

STATUS
--------
DISABLED

取得プロセスが無効の場合は、再起動してみてください。取得プロセスが中断されている場合、エラーを修正しないと正常に再起動できないことがあります。

取得プロセスが中断された理由を特定するには、DBA_CAPTUREデータ・ディクショナリ・ビューを問い合せるか、取得プロセスのトレース・ファイルをチェックします。次の問合せでは、取得プロセスがいつ中断されたかと、中断の原因となったエラーが表示されます。

COLUMN CAPTURE_NAME HEADING 'Capture|Process|Name' FORMAT A10
COLUMN STATUS_CHANGE_TIME HEADING 'Abort Time'
COLUMN ERROR_NUMBER HEADING 'Error Number' FORMAT 99999999
COLUMN ERROR_MESSAGE HEADING 'Error Message' FORMAT A40

SELECT CAPTURE_NAME, STATUS_CHANGE_TIME, ERROR_NUMBER, ERROR_MESSAGE
FROM DBA_CAPTURE WHERE STATUS='ABORTED';

関連項目:

- 「取得プロセスの起動」

- 「トレース・ファイルとアラート・ログでの問題のチェック」

- Oracle Real Application Clusters(Oracle RAC)環境で取得プロセスを再起動する方法については、「取得プロセスおよびOracle Real Application Clusters」を参照

取得プロセスでREDOを待機しているか

有効になっている取得プロセスで予期したとおりに変更が取得されない場合、取得プロセスはWAITING FOR REDOの状態にあります。

データベース内の各取得プロセスの状態をチェックするには、次の問合せを実行します。

COLUMN CAPTURE_NAME HEADING 'Capture Name' FORMAT A30
COLUMN STATE HEADING 'State' FORMAT A30

SELECT CAPTURE_NAME, STATE FROM V$STREAMS_CAPTURE;

取得プロセスの状態がWAITING FOR REDOの場合、取得プロセスは新しいREDOログ・ファイルが取得プロセス・セッションに追加されるまで待機しています。この状態は、REDOログ・ファイルが欠落しているか、またはソース・データベースにアクティビティが存在しない場合に発生する可能性があります。ダウンストリーム取得プロセスでは、セッションに新しいログ・ファイルが追加されるのを取得プロセスが待機している場合に、この状態が発生する可能性があります。

V$STREAMS_CAPTUREビューを問い合せると、状態の情報とともに追加情報が表示されることがあります。追加情報は、取得プロセスがREDOを待機している理由を判別するのに役立ちます。たとえば、ビューを問い合せると、次のような文がSTATE列に対して表示される場合があります。

WAITING FOR REDO: LAST SCN MINED 8077284

この場合、出力では取得プロセスによってスキャンされた最後のシステム変更番号(SCN)のみが識別されます。場合によっては、出力でREDOログ・ファイル名が明示的に識別されることもあります。いずれにしても、追加情報は取得プロセスが待機しているREDOログを識別するのに役立ちます。問題を修正するには、欠落している任意のREDOログ・ファイルを取得プロセスに対して使用可能にします。

関連項目:
「ダウンストリーム取得プロセスがREDOデータを待機していないか」

取得プロセスでフロー制御のために一時停止しているか

有効になっている取得プロセスで予期したとおりに変更が取得されない場合、取得プロセスはPAUSED FOR FLOW CONTROLの状態にあります。

データベース内の各取得プロセスの状態をチェックするには、次の問合せを実行します。

COLUMN CAPTURE_NAME HEADING 'Capture Name' FORMAT A30
COLUMN STATE HEADING 'State' FORMAT A30

SELECT CAPTURE_NAME, STATE FROM V$STREAMS_CAPTURE;

取得プロセスの状態がPAUSED FOR FLOW CONTROLの場合、メモリー不足、または伝播および適用プロセスでのメッセージのコンシューム速度が取得プロセスでのメッセージの作成速度より遅いことが原因で、取得プロセスでは論理変更レコード(LCR)をエンキューできません。この状態は、伝播または適用が遅延した場合あるいは使用不可能な場合に、取得LCRのオーバーフローを削減するために、フロー制御が行われていることを示します。

取得プロセスがこの状態にある場合、次の問題をチェックします。

- 適用プロセスが無効化されているかパフォーマンスが低速である。

- 伝播が無効化されているかパフォーマンスが低速である。

- Streamsプールのメモリーが不足している。

V$STREAMS_APPLY_READERビューを問い合せて、適用プロセスによって受信されているLCRを監視できます。また、V$STREAMS_APPLY_SERVERビューを問い合せて、すべての適用サーバーでLCRが適用され、トランザクションが実行されているかどうかを判別することもできます。

また、V$BUFFERED_PUBLISHERSビューのPUBLISHER_STATE列を問い合せると、取得プロセスがフロー制御のために一時停止している正確な理由を判別することもできます。

この問題を修正するには、次の1つ以上のアクションを実行します。

- 伝播または適用プロセスが無効化されている場合、伝播または適用プロセスを有効化します。

- 適用リーダーでデータが十分な速度で受信されていない場合は、伝播ルールおよび適用プロセス・ルールを削除するか、またはルール条件を単純化することを試行します。

- 取得プロセス・データベースでStreamsプールのメモリーが不足している場合は、Streamsプールのサイズの拡大を試行します。

関連項目:

- 第16章「ステージングと伝播の管理」

- 第17章「Oracle Streams情報コンシュームの管理」

- 第12章「取得と適用の複合による最適化」

現行の取得プロセスかどうか

取得プロセスによって最近の変更が取得されていない場合は、取得プロセスの遅延が原因の可能性があります。これをチェックするには、V$STREAMS_CAPTURE動的パフォーマンス・ビューを問い合せます。取得プロセスの待機時間が長い場合は、parallelism取得プロセス・パラメータの設定を調整すると、パフォーマンスを改善できることがあります。

関連項目:

- 「各取得プロセスのREDOログのスキャン待機時間の判別」

- 「各取得プロセスのメッセージのエンキュー待機時間の判別」

- 「取得プロセスのサブコンポーネント」

- 「取得プロセス・パラメータの設定」

必須のREDOログ・ファイルが欠落していないか

取得プロセスの起動時または再起動時には、開始SCNを含むログ・ファイルよりも前に生成されたREDOログ・ファイルをスキャンする必要がある場合があります。取得プロセスの先頭SCNと開始SCNを確認するには、DBA_CAPTUREデータ・ディクショナリ・ビューを問い合せます。必要なREDOログ・ファイルを取得プロセスでスキャンする前に削除すると、取得プロセスが異常終了し、取得プロセスのトレース・ファイルで次のエラーが発生します。

ORA-01291: missing logfile

このエラーが表示された場合は、欠落しているREDOファイルをリストアした後、取得プロセスを再起動してみてください。V$LOGMNR_LOGS動的パフォーマンス・ビューをチェックして欠落しているSCNの範囲を特定し、該当するREDOログ・ファイルを追加できます。取得プロセスには、必須チェックポイントSCNを含むREDOログ・ファイルと、後続のすべてのREDOログ・ファイルが必要です。DBA_CAPTUREデータ・ディクショナリ・ビューのREQUIRED_CHECKPOINT_SCN列を問い合せると、取得プロセスの必須チェックポイントSCNを判別できます。

Oracle Streams環境内のソース・データベースでRecovery Manager(RMAN)の高速リカバリ領域機能を使用している場合、取得プロセスに必要なアーカイブREDOログ・ファイルがRMANによって削除されることがあります。リカバリ関連ファイルで使用されているディスク領域が、高速リカバリ領域で指定されたディスク割当て制限に近づくと、RMANによってこれらのファイルが削除される場合があります。将来この問題が発生するのを防止するには、次のアクションを1つ以上実行します。

- 高速リカバリ領域のディスク割当て制限を引き上げます。ディスク割当て制限を引き上げると、必要なアーカイブREDOログ・ファイルがRMANによって削除される可能性が低減しますが、必ずしも問題を回避できるわけではありません。

- アーカイブREDOログ・ファイルが高速リカバリ領域以外の場所に格納されるようにソース・データベースを構成します。ローカル取得プロセスでは、必要なログ・ファイルが高速リカバリ領域に見つからない場合に、別の場所にあるログ・ファイルを使用できます。この場合、別の場所にあるログ・ファイルをデータベース管理者が手動で管理する必要があります。

RMANでは、アーカイブREDOログ・ファイルを削除する前に、それらがバックアップされていることを常に確認します。取得プロセスに必要なアーカイブREDOログ・ファイルがRMANによって削除されると、このアクションがRMANによってアラート・ログに記録されます。

関連項目:

- 「ARCHIVELOGモードおよび取得プロセス」

- 「先頭SCNおよび開始SCN」

- 「各取得プロセスの登録済REDOログ・ファイルの表示」

- 高速リカバリ領域機能の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照

ダウンストリーム取得プロセスがREDOデータを待機していないか

ダウンストリーム取得プロセスで変更が取得されない場合は、スキャン対象のREDOデータを待機している可能性があります。REDOログ・ファイルはダウンストリーム取得プロセスに暗黙的に登録される場合と明示的に登録される場合があります。暗黙的に登録されるREDOログ・ファイルは、一般に次のいずれかの方法で登録されます。

- リアルタイム・ダウンストリーム取得プロセスの場合は、REDO転送サービスによって、ログ・ライター・プロセス(LGWR)を使用してソース・データベースからダウンストリーム・データベースのスタンバイREDOログにREDOデータが転送されます。次に、ダウンストリーム・データベースのアーカイバによって、REDOログ・ファイルがアーカイブ時にダウンストリーム取得プロセスに登録されます。

- アーカイブ・ログ・ダウンストリーム取得プロセスの場合は、REDO転送サービスによって、アーカイブREDOログ・ファイルがソース・データベースからダウンストリーム・データベースに転送され、ダウンストリーム取得プロセスに登録されます。

REDOログ・ファイルがダウンストリーム取得プロセスに明示的に登録されている場合は、REDOログ・ファイルを手動でダウンストリーム・データベースに転送し、ダウンストリーム取得プロセスに登録する必要があります。

REDOログファイルが暗黙的に登録されるか、明示的に登録されるかにかかわりなく、ダウンストリーム取得プロセスでは適切なREDOログ・ファイルがその取得プロセスに登録されている場合にのみ、ソース・データベースで行われた変更が取得されます。V$STREAMS_CAPTURE動的パフォーマンス・ビューを問い合せると、ダウンストリーム取得プロセスがREDOログ・ファイルを待機しているかどうかを判別できます。たとえば、strm05_captureというダウンストリーム取得プロセスについて次の問合せを実行します。

SELECT STATE FROM V$STREAMS_CAPTURE WHERE CAPTURE_NAME='STRM05_CAPTURE';

取得プロセスの状態がWAITING FOR DICTIONARY REDOまたはWAITING FOR REDOの場合は、DBA_REGISTERED_ARCHIVED_LOGおよびDBA_CAPTUREデータ・ディクショナリ・ビューを問い合せて、REDOログ・ファイルがそのダウンストリーム取得プロセスに登録されているかどうかを確認します。たとえば次の問合せでは、strm05_captureダウンストリーム取得プロセスに現在登録されているREDOログ・ファイルがリストされます。

COLUMN SOURCE_DATABASE HEADING 'Source|Database' FORMAT A15
COLUMN SEQUENCE# HEADING 'Sequence|Number' FORMAT 9999999
COLUMN NAME HEADING 'Archived Redo Log|File Name' FORMAT A30
COLUMN DICTIONARY_BEGIN HEADING 'Dictionary|Build|Begin' FORMAT A10
COLUMN DICTIONARY_END HEADING 'Dictionary|Build|End' FORMAT A10

SELECT r.SOURCE_DATABASE,
r.SEQUENCE#,
r.NAME,
r.DICTIONARY_BEGIN,
r.DICTIONARY_END
FROM DBA_REGISTERED_ARCHIVED_LOG r, DBA_CAPTURE c
WHERE c.CAPTURE_NAME = 'STRM05_CAPTURE' AND
r.CONSUMER_NAME = c.CAPTURE_NAME;

この問合せによって行が返されない場合、現在、この取得プロセスにREDOファイルは登録されていません。この取得プロセスのためにソース・データベースからダウンストリーム・データベースにREDOデータを転送するようREDO転送サービスを構成した場合は、REDO転送サービスが正しく構成されていることを確認してください。REDO転送サービスが正しく構成されている場合は、ソース・データベースでALTER SYSTEM ARCHIVE LOG CURRENT文を実行してログ・ファイルをアーカイブします。REDOデータを転送するようREDO転送サービスを構成しなかった場合は、ログ・ファイルの転送と登録に使用している方法が正常に機能していることを確認してください。ALTER DATABASE REGISTER LOGICAL LOGFILE文を使用すると、ログ・ファイルを明示的に登録できます。

ダウンストリーム取得プロセスがREDOを待機している場合、ソース・データベースとダウンストリーム・データベースの間のネットワーク接続に問題がある可能性もあります。また、ログ・ファイルの転送方法に問題がある可能性もあります。ネットワーク接続とログ・ファイルの転送方法をチェックして、それらが正常に機能していることを確認してください。

リアルタイム・ダウンストリーム取得プロセスを構成していて、その取得プロセスにREDOログ・ファイルが登録されていない場合は、ソース・データベースのログ・ファイルを切り替えてみてください。ソース・データベースにアクティビティがほとんどまたはまったく存在しない場合は、ログ・ファイルを複数回切替える必要がある場合があります。

また、ダウンストリーム取得プロセスを使用して履歴データの変更を取得する予定の場合は、さらに次の項目を考慮します。

- REDOログ・ファイルが生成されるソース・データベースと、ダウンストリーム取得プロセスが実行されるデータベースは、どちらもOracle Database 10g以上のデータベースである必要があります。

- 作成されたデータ・ディクショナリの先頭が、最も早く追加されたREDOログに存在している必要があります。また、取得プロセスが、作成されたデータ・ディクショナリの先頭と一致する先頭SCNで構成されている必要があります。

- 取得プロセスで変更を取得するデータベース・オブジェクトは、ダウンストリーム・データベースではなくソース・データベースでインスタンス化のために準備する必要があります。また、インスタンス化のためにオブジェクトを準備する場合、過去の時点は指定できません。オブジェクトは常に現行のデータベースSCNでインスタンス化のために準備され、オブジェクトがインスタンス化のために準備された後に発生したデータベース・オブジェクトの変更のみを取得プロセスによって取得できます。

関連項目:

- 「ローカル取得およびダウンストリーム取得」

- 取得プロセスの状態

- 取得プロセスの構成の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

不適切にダウンストリーム取得の構成を試行していないか

ダウンストリーム取得プロセスを作成するには、次のプロシージャのいずれかを使用する必要があります。

- DBMS_CAPTURE_ADM.CREATE_CAPTURE

- DBMS_STREAMS_ADM.MAINTAIN_GLOBAL

- DBMS_STREAMS_ADM.MAINTAIN_SCHEMAS

- DBMS_STREAMS_ADM.MAINTAIN_SIMPLE_TTS

- DBMS_STREAMS_ADM.MAINTAIN_TABLES

- DBMS_STREAMS_ADM.MAINTAIN_TTS

- DBMS_STREAMS_ADMパッケージのPRE_INSTANTIATION_SETUPおよびPOST_INSTANTIATION_SETUP

DBMS_STREAMS_ADMパッケージのプロシージャでは、ダウンストリーム取得プロセス以外にも、Oracle Streamsレプリケーション環境のその他のOracle Streamsコンポーネントを構成できます。

これらのプロシージャを使用せずにダウンストリーム取得プロセスを作成しようとすると、次のエラーが戻されます。

ORA-26678: Streams capture process must be created first

この問題を修正するには、これらのプロシージャのいずれかを使用してダウンストリーム取得プロセスを作成します。

DBMS_STREAMS_ADMパッケージのプロシージャを使用してローカル取得プロセスを作成しているときにこのエラーが発生した場合は、実行しているプロシージャのsource_databaseパラメータに指定されているデータベース名が、ローカル・データベースのグローバル名と一致していることを確認します。

関連項目:
取得プロセスの構成の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

適切な認証を使用しないでダウンストリーム取得の構成を試行していないか

ソース・データベースおよびダウンストリーム取得データベース間で認証が適切に構成されていないと、REDOデータ転送が次のいずれかのエラーで失敗します。

ORA-16191: Primary log shipping client not logged on standby

ORA-1017: Invalid username/password; login denied

REDO転送セッションは、Secure Sockets Layer(SSL)プロトコルまたはリモート・ログイン・パスワード・ファイルのいずれかを使用して認証されます。パスワード・ファイルは、ソース・データベースおよびダウンストリーム取得データベースで同じである必要があります。

この問題を修正するには、次のアクションのいずれかを実行します。

- ソース・データベースにリモート・ログイン・パスワード・ファイルがある場合は、ダウンストリーム取得データベース・システムの適切なディレクトリにこのファイルをコピーします。ファイルをコピーした後、両方のデータベースを再起動して変更を反映する必要がある場合があります。

- 初期化パラメータSEC_CASE_SENSITIVE_LOGONにFALSEを設定し、大/小文字区別オプションを無効にします。次に、ORAPWDを使用し、ソースおよびダウンストリーム取得データベース・システムでパスワード・ファイルを作成します。パスワードは両方のシステムで同一にし、ignorecase引数にYを設定する必要があります。

関連項目:
REDO転送の認証要件の詳細は、『Oracle Data Guard概要および管理』を参照

データベース・リンクのないダウンストリーム取得に追加のアクションが必要か

ダウンストリーム取得がデータベース・リンク付きで構成されている場合は、そのデータベース・リンクを使用してソース・データベースで操作を実行し、ソース・データベースから自動的に情報を取得できます。ダウンストリーム取得がデータベース・リンクなしで構成されている場合は、これらのアクションを手動で実行し、情報を手動で取得する必要があります。これらのアクションを手動で完了しないでダウンストリーム取得プロセスを作成しようとすると、エラーが発生します。

ダウンストリーム取得をデータベース・リンクなしで構成する場合、具体的には次のアクションを手動で実行する必要があります。

- 状況によっては、取得プロセスを作成する前にソース・データベースでDBMS_CAPTURE_ADM.BUILDプロシージャを実行して、ソース・データベースのデータ・ディクショナリをREDOログに抽出する必要があります。

- ソース・データベース・オブジェクトをインスタンス化のために準備する必要があります。

- ダウンストリーム取得プロセスの先頭SCNを取得し、DBMS_CAPTURE_ADMパッケージのCREATE_CAPTUREプロシージャを使用して取得プロセスを作成する際に、first_scnパラメータでその先頭SCNを指定する必要があります。

関連項目:
取得プロセスの構成の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

同期取得に関する問題のトラブルシューティング

同期取得によって変更が予期したとおりに取得されない場合は、この項を参考にして、同期取得に関する問題を特定し、解決してください。

関連項目:

- 「同期取得による暗黙的取得」

- 同期取得の構成の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- 「同期取得の管理」

- 「同期取得の監視」

同期取得で表の変更の取得に失敗しないか

同期取得で表の変更が予期したとおりに取得されない場合は、同期取得のルール・セット内のルールが正しく構成されていない可能性があります。問題を回避するには、同期取得のルール・セットにルールを追加する際、常にDBMS_STREAMS_ADMパッケージのADD_TABLE_RULESまたはADD_SUBSET_RULESプロシージャを使用します。

同期取得で変更が予期したとおりに取得されない場合の一般的な原因を次に示します。

- 同期取得の動作を制御しようとするグローバル・ルールまたはスキーマ・ルールが使用されている場合。同期取得では、そのルール・セット内のグローバル・ルールおよびスキーマ・ルールは無視されます。同期取得では、表ルールとサブセット・ルールを満たす変更のみが取得されます。

- 同期取得のルールの構成にDBMS_RULE_ADMパッケージが使用された場合。この場合は同期取得が正常に動作しません。

- 同期取得のルール・セットに追加するルールの作成にDBMS_RULE_ADMパッケージが使用された場合。

- 同期取得のルール・セットへのルールの追加にDBMS_RULE_ADMパッケージが使用された場合。

同期取得で表の変更が予期したとおりに取得されない場合は、次の手順を実行して、問題を特定し、解決してください。

1. DBA_SYNC_CAPTURE_TABLESデータ・ディクショナリ・ビューを問い合せて、同期取得で変更が取得されている表を特定します。同期取得では、表のENABLED列がYESに設定されている場合にのみ表の変更が取得されます。

2. 同期取得で変更を取得する必要がある表がDBA_SYNC_CAPTURE_TABLESビューにリストされない場合は、DBMS_STREAMS_ADMパッケージのADD_TABLE_RULESまたはADD_SUBSET_RULESプロシージャを使用して、それらの表についてのルールを追加します。

DBA_SYNC_CAPTURE_TABLESで表のENABLEDが表示されていても、同期取得でその表の変更が取得されない場合は、表のルールに含まれるルール条件に問題がある可能性があります。この場合は、ルール条件をチェックしてエラーを訂正するか、そのルールを削除し、ADD_TABLE_RULESまたはADD_SUBSET_RULESプロシージャを使用してルールを作成し直します。

注意:
同期取得のルール・セットからルールを削除したり、同期取得で使用されるルールを削除する場合は、DBMS_STREAMS_ADMパッケージのREMOVE_RULEプロシージャを使用することをお薦めします。ただし、DBMS_RULE_ADMパッケージのREMOVE_RULEまたはDROP_RULEプロシージャを使用してこれらのアクションを実行することもできます。

関連項目:

- 「同期取得によって変更が取得される表の表示」

- 「同期取得のルール・セットへのルールの追加」

- 「ルール・セット内の各ルールの条件の表示」

- 「同期取得のルール・セットからのルールの削除」

32 伝播のトラブルシューティング

次の各項では、Oracle Streams環境での伝播の一般的な問題の特定と解決について説明します。

- 伝播で適切なソース・キューと宛先キューが使用されているか

- 伝播が有効かどうか

- ANYDATAキューのセキュリティは適切に構成されているか

関連項目:

- 「キュー間でのメッセージの伝播」

- 伝播の作成の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- 「Oracle Streamsの伝播および伝播ジョブの管理」

- 「Oracle Streamsの伝播および伝播ジョブの監視」

伝播で適切なソース・キューと宛先キューが使用されているか

メッセージが予期したとおりに伝播の宛先キューに格納されないときは、適切なソース・キューから適切な宛先キューにメッセージを伝播するように伝播が構成されていない場合があります。

たとえば、dbs1_to_dbs2という伝播のソース・キューと宛先キューをチェックするには、次の問合せを実行します。

COLUMN SOURCE_QUEUE HEADING 'Source Queue' FORMAT A35
COLUMN DESTINATION_QUEUE HEADING 'Destination Queue' FORMAT A35

SELECT
p.SOURCE_QUEUE_OWNER||'.'||
p.SOURCE_QUEUE_NAME||'@'||
g.GLOBAL_NAME SOURCE_QUEUE,
p.DESTINATION_QUEUE_OWNER||'.'||
p.DESTINATION_QUEUE_NAME||'@'||
p.DESTINATION_DBLINK DESTINATION_QUEUE
FROM DBA_PROPAGATION p, GLOBAL_NAME g
WHERE p.PROPAGATION_NAME = 'DBS1_TO_DBS2';

出力は次のようになります。

Source Queue                        Destination Queue
----------------------------------- -----------------------------------
STRMADMIN.QUEUE1@DBS1.EXAMPLE.COM   STRMADMIN.QUEUE2@DBS2.EXAMPLE.COM

伝播が適切なキューを使用していない場合は、別の伝播を作成します。ご使用の環境に既存の伝播が適さない場合には削除が必要になることがあります。

関連項目:

- 伝播の作成の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- 「伝播の削除」

伝播が有効かどうか

伝播ジョブでメッセージを伝播するには、伝播が有効であることが必要です。予期したとおりに伝播でメッセージが伝播されないときは、伝播が無効になっている場合があります。

伝播について次の情報を確認できます。

- ソース・キューから宛先キューへのメッセージの伝播で使用されるデータベース・リンク

- 伝播がENABLED、DISABLEDまたはABORTEDのいずれであるか

- 最後のエラーの日付(伝播エラーが発生した場合)

- 最後のエラーのエラー番号(伝播エラーが発生した場合)

- 最後のエラーのエラー・メッセージ(伝播エラーが発生した場合)

たとえば、streams_propagationという伝播が有効かどうかチェックするには、次の問合せを実行します。

COLUMN DESTINATION_DBLINK HEADING 'Database|Link'      FORMAT A15
COLUMN STATUS             HEADING 'Status'             FORMAT A8
COLUMN ERROR_DATE         HEADING 'Error|Date'
COLUMN ERROR_MESSAGE      HEADING 'Error Message'      FORMAT A35

SELECT DESTINATION_DBLINK,
STATUS,
ERROR_DATE,
ERROR_MESSAGE
FROM DBA_PROPAGATION
WHERE PROPAGATION_NAME = 'STREAMS_PROPAGATION';

伝播が現在無効の場合は、出力が次のようになります。

Database                 Error
Link            Status   Date      Error Message
--------------- -------- --------- -----------------------------------
D2.EXAMPLE.COM  DISABLED 27-APR-05 ORA-25307: Enqueue rate too high, f
low control enabled

問題がある場合は、次の方法を試行して修正してください。

- 伝播が無効の場合、DBMS_PROPAGATION_ADMパッケージのSTART_PROPAGATIONプロシージャをまだ実行していなければ、これを実行して伝播を有効にできます。

- 伝播が無効になっているか、中断されていて、Error DateおよびError Messageフィールドに値が移入されている場合は、エラー・メッセージに基づいて問題を診断し、修正します。

- 伝播が無効になっているか、中断されている場合は、伝播ジョブ・プロセスのトレース・ファイルをチェックします。「伝播ジョブのスケジュールに関する情報の表示」の問合せを実行すると、伝播ジョブ・プロセスが表示されます。

- 伝播ジョブが有効だが、メッセージが伝播されない場合は、伝播を停止してから再起動します。

関連項目:

- 「伝播の開始」

- 「トレース・ファイルとアラート・ログでの問題のチェック」

- 「伝播の停止」

- 特定のエラー・メッセージの詳細は、Oracle Databaseエラー・メッセージを参照

ANYDATAキューのセキュリティは適切に構成されているか

ANYDATAキューは保護キューであり、ユーザーがその操作を実行できるように、セキュリティを適切に構成する必要があります。DBMS_STREAMS_ADMパッケージのSET_UP_QUEUEプロシージャを使用して保護キューANYDATAを構成する場合、SET_UP_QUEUEが作成しようとするエージェントがすでに存在し、このプロシージャのqueue_userで指定されているユーザー以外のユーザーに関連付けられていると、エラーが発生します。この場合は、DBMS_AQADMパッケージのALTER_AQ_AGENTプロシージャを使用して既存のエージェントの名前を変更するか、DROP_AQ_AGENTプロシージャを使用して既存のエージェントを削除します。次に、SET_UP_QUEUEを再試行します。

また、ANYDATAキューのセキュリティが適切に構成されていないと、次のいずれかのエラーが発生することがあります。

- ORA-24093: AQエージェントはデータベース・ユーザーの権限を付与されていません。

- ORA-25224: セキュア・キューにエンキューするために送信者名を指定する必要があります。

関連項目:
「保護キュー」

ORA-24093: AQエージェントはデータベース・ユーザーの権限を付与されていません。

Oracle Streamsアドバンスト・キューイング(AQ)エージェントには、エンキュー操作とデキュー操作の両方について、保護キューへのアクセス権が明示的に付与される必要があります。DBMS_AQADMパッケージのENABLE_DB_ACCESSプロシージャを使用して、エージェントにこれらの権限を付与します。

たとえば、explicit_dqというエージェントにデータベース・ユーザーoeの権限を付与するには、次のプロシージャを実行します。

BEGIN
DBMS_AQADM.ENABLE_DB_ACCESS(
agent_name  => 'explicit_dq',
db_username => 'oe');
END;
/

データベースでのエージェントの権限をチェックするには、次の問合せを実行します。

SELECT AGENT_NAME "Agent", DB_USERNAME "User" FROM DBA_AQ_AGENT_PRIVS;

出力は次のようになります。

Agent                          User
------------------------------ ------------------------------
EXPLICIT_ENQ                   OE
APPLY_OE                       OE
EXPLICIT_DQ                    OE

関連項目:
エージェントへの権限付与の詳細な例は、「保護キューでのユーザー操作の有効化」を参照

ORA-25224: セキュア・キューにエンキューするために送信者名を指定する必要があります。

保護キューにエンキューするには、メッセージ・プロパティで、そのキューに対する保護キュー権限を持つOracle Streamsアドバンスト・キューイング(AQ)エージェントにSENDER_IDを設定する必要があります。

関連項目:
エンキューのSENDER_IDを設定する例の詳細は、『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイド』を参照

33 適用のトラブルシューティング

次の各項では、Oracle Streams環境内での適用プロセスの一般的な問題の特定と解決について説明します。

- 適用プロセスが有効かどうか

- 現行の適用プロセスかどうか

- 適用プロセスが取得LCRに適用されているか

- 適用プロセスのキューが適用するメッセージを受信しているか

- カスタム適用ハンドラが指定されているか

- AQ_TM_PROCESSES初期化パラメータが0に設定されているか

- 適用ユーザーに必要な権限があるか

- 適用プロセスで競合が発生しているか

- 適用プロセスで依存トランザクションを待機しているか

- 適用サーバーのパフォーマンスが特定のトランザクションに対して低いか

- エラー・キューに適用エラーがあるか

関連項目:

- 「適用プロセスによる暗黙的コンシューム」

- 適用の構成の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- 第17章「Oracle Streams情報コンシュームの管理」

- 第26章「Oracle Streams適用プロセスの監視」

適用プロセスが有効かどうか

適用プロセスが変更を適用するのは、そのプロセスが有効になっている場合のみです。

適用プロセスが有効か、無効か、中断されているかは、DBA_APPLYデータ・ディクショナリ・ビューを問い合せるとチェックできます。たとえば、applyという適用プロセスが有効かどうかチェックするには、次の問合せを実行します。

SELECT STATUS FROM DBA_APPLY WHERE APPLY_NAME = 'APPLY';

適用プロセスが無効の場合は、出力が次のようになります。

STATUS
--------
DISABLED

適用プロセスが無効の場合は、再起動してみてください。適用プロセスが中断されている場合、エラーを修正しないと正常に起動できないことがあります。適用プロセスが正常に停止されていない場合は、再起動しないことがあります。この場合は次のエラーが返されます。

ORA-26666 cannot alter STREAMS process

このとき、DBMS_APPLY_ADMパッケージのSTOP_APPLYプロシージャをforceパラメータをTRUEに設定して実行してください。その後、適用プロセスを再起動します。

適用プロセスが中断された理由を特定するには、DBA_APPLYデータ・ディクショナリ・ビューを問い合せるか、適用プロセスのトレース・ファイルをチェックします。次の問合せを実行すると、適用プロセスがいつ中断されたかと、中断の原因となったエラーが表示されます。

COLUMN APPLY_NAME HEADING 'APPLY|Process|Name' FORMAT A10
COLUMN STATUS_CHANGE_TIME HEADING 'Abort Time'
COLUMN ERROR_NUMBER HEADING 'Error Number' FORMAT 99999999
COLUMN ERROR_MESSAGE HEADING 'Error Message' FORMAT A40

SELECT APPLY_NAME, STATUS_CHANGE_TIME, ERROR_NUMBER, ERROR_MESSAGE
FROM DBA_APPLY WHERE STATUS='ABORTED';

関連項目:

- 「適用プロセスの起動」

- 「適用エラーの詳細情報の表示」

- 「トレース・ファイルとアラート・ログでの問題のチェック」

- Oracle Real Application Clusters(Oracle RAC)環境で適用プロセスを再起動する方法については、「適用プロセスおよびOracle Real Application Clusters」を参照

現行の適用プロセスかどうか

適用プロセスによって最近の変更が適用されていない場合、問題は適用プロセスの遅延である可能性があります。適用プロセスの待機時間が長い場合は、parallelism適用プロセス・パラメータの設定を調整すると、パフォーマンスを改善できることがあります。

V$STREAMS_APPLY_COORDINATOR動的パフォーマンス・ビューを問い合せて、適用プロセスの待機時間をチェックできます。

関連項目:

- 各適用プロセスのメッセージが取得されてから適用されるまでの待機時間の確認

- 「適用プロセス・パラメータ」

- 「適用プロセス・パラメータの設定」

- Oracle Database 2日でデータ・レプリケーションおよび統合ガイド

- 適用プロセス・パラメータの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のDBMS_APPLY_ADM.SET_PARAMETERプロシージャに関する項を参照

適用プロセスが取得LCRに適用されているか

適用プロセスはバッファ・キューの取得LCRに適用できます。また、永続キューのメッセージにも適用できますが、両方のタイプのメッセージには適用できません。永続キューのメッセージは永続LCRおよび永続ユーザー・メッセージです。適用プロセスは1つのタイプのメッセージに適用されるように構成されているため、別のタイプのメッセージには適用できません。

適用プロセスで適用されるメッセージのタイプは、DBA_APPLYデータ・ディクショナリ・ビューを問い合せるとチェックできます。たとえば、applyという適用プロセスで取得LCRが適用されるかどうかをチェックするには、次の問合せを実行します。

COLUMN APPLY_CAPTURED HEADING 'Type of Messages Applied' FORMAT A25

SELECT DECODE(APPLY_CAPTURED,
'YES', 'Captured',
'NO',  'Messages from Persistent Queue') APPLY_CAPTURED
FROM DBA_APPLY
WHERE APPLY_NAME = 'APPLY';

この適用プロセスで取得LCRが適用される場合は、出力が次のようになります。

Type of Messages Applied
-------------------------
Captured

適用プロセスが予期したタイプのメッセージを適用しないときは、これらのメッセージを適用するために適用プロセスの作成が必要になる場合があります。

関連項目:

- 「Oracle Streamsで情報をコンシュームする方法」

- Oracle Streamsレプリケーションの詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

適用プロセスのキューが適用するメッセージを受信しているか

適用プロセスがメッセージを適用するためには、その前にキューにメッセージを受信する必要があります。このため、適用プロセスが、取得プロセスまたは同期取得で取得されるメッセージを適用する場合、それらのメッセージを取得する取得プロセスまたは同期取得が適切に構成されていることが必要です。また、取得プロセスの場合は有効になっている必要があります。同じく、メッセージが1つまたは複数のデータベースから伝播されて適用プロセスに送られる場合は、各伝播が有効になっており、適切に構成されていることが必要です。適用プロセスが依存する取得プロセス、同期取得または伝播が適切に構成されていないと、メッセージが取得プロセスのキューに到達しない可能性があります。

取得プロセス、同期取得および伝播を含むすべてのOracle Streamsクライアントで使用されるルール・セットによって、これらのOracle Streamsクライアントの動作が決定されます。したがって、適用プロセスが依存する取得プロセス、同期取得または伝播のルール・セットに適切なルールが含まれていることを確認してください。これらのOracle Streamsクライアントのルールが適切に構成されていない場合、適用プロセスのキューが適切なメッセージを受信しない可能性があります。また、ストリームを介して送受信されるメッセージには、その過程で実行されるすべての変換が反映されます。たとえば、メッセージの取得中に取得プロセスがサブセット・ルールを使用して行の移行を実行し、伝播がメッセージにルールベースの変換を実行して表の名前を変更した場合、メッセージが適用プロセスに到達した時点で、適用プロセスのルールではこれらの変換を考慮する必要があります。

取得プロセスまたは同期取得が取得する変更が、複数のデータベースに伝播されて適用される環境では、次のガイドラインに従って、問題の原因は適用プロセスが依存する取得プロセス、同期取得取得または伝播にあるのか、あるいは適用プロセス自体にあるのかを判断できます。

- 取得プロセスまたは同期取得の他の宛先データベースでも変更が適用されない場合、問題の原因は取得プロセスまたは同期取得、あるいは取得プロセスに近い伝播にあると考えられます。この場合、まず取得プロセスまたは同期取得が適切に構成されていることを確認し、次に取得プロセスまたは同期取得に最も近い伝播が有効化され適切に構成されていることを確認します。取得プロセスの場合は、取得プロセスが有効化されていることも確認します。

- 取得プロセスまたは同期取得の他の宛先データベースで、変更が適用されている場合は、問題の原因は適用プロセス自体にあるか、その適用プロセスに近い伝播にあると考えられます。この場合、まず適用プロセスが有効化され適切に構成されていることを確認し、次にその適用プロセスに最も近い伝播が有効化され適切に構成されていることを確認します。

関連項目:

- 「取得プロセスの問題のトラブルシューティング」

- 第32章「伝播のトラブルシューティング」

- 第34章「ルールおよびルールベースの変換のトラブルシューティング」

カスタム適用ハンドラが指定されているか

適用ハンドラを使用すると、適用プロセスでデキューされたメッセージをカスタマイズした方法で処理できます。このようなハンドラには、文DMLハンドラ、プロシージャDMLハンドラ、DDLハンドラ、プリコミット・ハンドラおよびメッセージ・ハンドラがあります。適用プロセスが予期したとおりに動作していない場合は、その適用プロセスで使用されるハンドラ・プロシージャをチェックして、不備があれば修正します。適用の問題を修正するには、文DMLハンドラでSQL文の修正が必要な場合があります。また、PL/SQLプロシージャの変更や削除が必要な場合もあります。

これらのプロシージャの名前は、DBA_APPLY_DML_HANDLERSおよびDBA_APPLYデータ・ディクショナリ・ビューを問い合せると検索できます。

関連項目:

- 「適用プロセスのメッセージ処理オプション」

- 第17章「Oracle Streams情報コンシュームの管理」

- 「適用ハンドラに関する情報の表示」

AQ_TM_PROCESSES初期化パラメータが0に設定されているか

AQ_TM_PROCESSES初期化パラメータは、キュー・メッセージに対する時間の監視、および遅延プロパティと有効期限プロパティが指定されたメッセージの処理を制御します。Oracle Database 10g以上では、AQ_TM_PROCESSES初期化パラメータが設定されていない場合、データベースによってこれらのアクションが自動的に制御されます。

適用プロセスのルール・セットを満たすメッセージが適用プロセス・キューに存在していても、適用プロセスによってメッセージが適用されない場合は、宛先データベースでAQ_TM_PROCESSES初期化パラメータが0に設定されていないことを確認します。このパラメータが0に設定されている場合は、その設定を解除するか、0以外の値に設定し、適用プロセスを監視してメッセージの適用が開始されるかどうかを確認します。

バッファ・キューにメッセージがあるかどうかを判別するには、V$BUFFERED_QUEUESおよびV$BUFFERED_SUBSCRIBERS動的パフォーマンス・ビューを問い合せます。永続キューにメッセージがあるかどうかを判別するには、そのキューのキュー表を問い合せます。

関連項目:

- 「永続キュー内のメッセージの内容の表示」

- 「バッファ・キューの監視」

- AQ_TM_PROCESSES初期化パラメータの詳細は、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドを参照

適用ユーザーに必要な権限があるか

適用ユーザーに、適用ハンドラ・プロシージャまたはカスタム・ルールベースの変換ファンクションの明示的なEXECUTE権限がない場合、プロシージャまたはファンクションを実行しようとしてORA-26808エラーが発生することがあります。通常、このエラーでは、DBA_APPLY_ERRORビューにエラーが追加されずに適用プロセスが中断します。ただし、適用コーディネータのトレース・ファイルでエラーが報告されます。具体的には次のようなエラーがトレース・ファイルに記録されます。

ORA-26808: Apply process AP01 died unexpectedly

通常、このメッセージの前後にはエラー・メッセージがあり、それらのメッセージの1つ以上にプロシージャまたはファンクションの名前が含まれています。問題を解決するには、適用ユーザーに必要なEXECUTE権限を付与します。

関連項目:

- 「適用ユーザー」

- 第17章「Oracle Streams情報コンシュームの管理」

- 適用プロセスのトレース・ファイルに適用の問題に関するメッセージが含まれているか

適用プロセスで競合が発生しているか

適用サーバーとは適用プロセスのコンポーネントのことです。適用サーバーでは、DML変更およびDDL変更が宛先データベースのデータベース・オブジェクトに適用されます。適用プロセスでは1つ以上の適用サーバーを使用でき、parallelism適用プロセス・パラメータを使用して、トランザクションを同時に適用できる適用サーバーの数を指定します。たとえば、parallelismを5に設定すると、適用プロセスで合計5つの適用サーバーが使用されます。

適用サーバーが別のセッションで使用中のリソースを待機する必要がある場合、適用サーバーで競合が発生します。競合は論理的な依存性が原因で発生する可能性があります。たとえば、ユーザーがロックした行に対して適用サーバーで変更を適用する場合、適用サーバーはユーザーを待機する必要があります。また、競合は物理的な依存性が原因で発生する可能性もあります。たとえば、対象トランザクション・リスト(ITL)の競合は、適用中の2つのトランザクション(論理的に依存していない場合があります)がディスク上の同じブロックをロックしようとした場合に発生します。この場合、1つ目の適用サーバーがブロック内の行をロックすると、2つ目の適用サーバーは、異なる行をロックしようとしていてもブロックへのアクセスを待機する必要があります。ITLの競合の詳細は、「適用プロセスで依存トランザクションを待機しているか」を参照してください。

同じ適用プロセス内の別の適用サーバーに関係のない競合が適用サーバーで発生した場合、適用サーバーは競合が解決するまで待機します。同じ適用プロセス内の別の適用サーバーに関係のある競合が適用サーバーで発生した場合、2つの適用サーバーのいずれかがロールバックされます。複数の適用サーバーを使用中の適用プロセスでは、複数のトランザクションが同時に適用されることがあります。適用プロセスでは、コミットSCNが最小のトランザクションを適用中の適用サーバーの状態を追跡します。2つのトランザクション間に依存性がある場合、適用プロセスでは常に、コミットSCNが最小のトランザクションが最初に適用されます。コミットSCNがより大きいトランザクションは、他のトランザクションがコミットされるのを待機します。したがって、最小のコミットSCNのトランザクションを含む適用サーバーで競合が発生している場合には、競合の原因は依存トランザクション以外にあります。この場合、最小のコミットSCNのトランザクションを含む適用サーバーを監視して、競合の原因を判別できます。

適用サーバーの待機状態として、次の4とおりが考えられます。

- 待機していない: 適用サーバーで競合は発生しておらず、サーバーは待機していません。この場合、アクションは必要ありません。

- 別のセッションに関連していないイベントを待機中: 別のセッションに関連していないイベント例としては、log file syncイベントがあげられます。このイベントでは、コミットまたはロールバックが原因でREDOデータをフラッシュする必要があります。このような場合、こうした待機が一般的で通常一時的なものであるため、Oracle Databaseでは最初は何も書き込まれません。特定の時間間隔が経過しても適用サーバーが同じイベントを待機している場合、適用サーバーはアラート・ログおよび適用プロセスのトレース・ファイルにメッセージを書き込みます。たとえば、適用サーバーAS01では、次のようなメッセージが書き込まれる場合があります。

AS01: warning -- apply server 1, sid 26 waiting for event:
AS01: [log file sync] ...

Oracle Databaseでは、問題が修正されるまで、この出力が周期的にアラート・ログに書き込まれます。

- 適用サーバー以外のセッションに関連しているイベントを待機中: 適用サーバーは、アラート・ログおよび適用プロセスのトレース・ファイルに即時にメッセージを書き込みます。たとえば、適用サーバーAS01では、次のようなメッセージが書き込まれる場合があります。

AS01: warning -- apply server 1, sid 10 waiting on user sid 36 for event:
AS01: [enq: TM - contention] name|mode=544d0003, object #=a078,
table/partition=0

Oracle Databaseでは、問題が修正されるまで、この出力が周期的にアラート・ログに書き込まれます。

- 別の適用サーバー・セッションを待機中: この状態は対象トランザクション・リスト(ITL)の競合によって引き起こされる可能性がありますが、より深刻な問題(適用ハンドラが競合するロックを取得するなど)によって引き起こされる可能性もあります。この場合、別の適用サーバーにブロックされた適用サーバーによって、アラート・ログおよび適用プロセスのトレース・ファイルに1回のみ出力され、ブロックされた適用サーバーではブロックしている適用サーバーに対してロールバックが発行されます。ブロックしている適用サーバーがロールバックされると、適用サーバーがロールバックされたことを示す別のメッセージがログ・ファイルに出力され、ロールバックされたトランザクションが適用プロセスのコーディネータ・プロセスによって再割当てされます。
たとえば、適用プロセスAP01の適用サーバー1が同じ適用プロセス(AP01)の適用サーバー2によってブロックされている場合、適用プロセスによって次のメッセージがログ・ファイルに書き込まれます。

AP01: apply server 1 blocked on server 2
AP01: [enq: TX - row lock contention] name|mode=54580006, usn<<16 |
slot=1000e, sequence=1853
AP01: apply server 2 rolled back

適用プロセスが最後に起動されてから適用サーバーがロールバックされた合計回数を判別するには、V$STREAMS_APPLY_COORDINATOR動的パフォーマンス・ビューのTOTAL_ROLLBACKS列を問い合せます。

関連項目:

- 競合、および様々なタイプの競合の解決の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照

- 「トレース・ファイルとアラート・ログでの問題のチェック」

適用プロセスで依存トランザクションを待機しているか

適用プロセスのparallelismパラメータを1より大きい値に設定して適用プロセスのcommit_serializationパラメータをFULLに設定すると、SCNがより大きい別のトランザクションに依存しているトランザクションが存在する場合に、適用プロセスで対象トランザクション・リスト(ITL)の競合を検出できます。ITLの競合は、トランザクションを作成したセッションがブロックのITLスロットを待機した場合に発生します。このことが発生するのは、セッションでそのブロックの行をロックする必要があるものの、1つ以上の他のセッションで同じブロックの行がロックされており、ブロックにITLの空きスロットがない場合です。

ITLの競合は、ビットマップ索引のフラグメントが共有されているためにセッションが待機中である場合にも発生する可能性があります。ビットマップ索引では、キー値およびROWID範囲が索引付けされます。ビットマップ索引の各エントリには実際の表の行を数多く含めることができます。同じビットマップ索引のフラグメントに含まれている行を2つのセッションで更新する必要がある場合、2番目のセッションは1番目のトランザクションがコミットまたはロールバックされるのを待機します。

適用プロセスでこのような依存性が検出されると、適用プロセスによってITLの競合が動的に解決され、その競合に関する情報がデータベースのアラート・ログおよび適用プロセスのトレース・ファイルに記録されます。デッドロックが検出されている間は進捗が停止する場合があるため、ITLの競合は適用プロセスのパフォーマンスに悪影響を与える可能性があります。

この問題が将来発生しないようにするには、次のアクションのいずれかを実行します。

- 使用可能なITLの数を増やします。このことを行うには、ALTER TABLE文を使用して表のINITRANS設定を変更します。

- 適用プロセスに対して、commit_serializationパラメータをDEPENDENT_TRANSACTIONSに設定します。

- 適用プロセスに対して、parallelism適用プロセス・パラメータを1に設定します。

関連項目:

- 「トレース・ファイルとアラート・ログでの問題のチェック」

- 適用プロセス・パラメータの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

- INITRANSの詳細は、『Oracle Database管理者ガイド』および『Oracle Database SQL言語リファレンス』を参照

適用サーバーのパフォーマンスが特定のトランザクションに対して低いか

適用プロセスのパフォーマンスがよくない場合、適用プロセスによって使用される1つ以上の適用サーバーで、特定のトランザクションを適用するのに異常に長い時間を要しているためであることがあります。次の問合せを実行すると、適用プロセスstrm01_applyによって使用される各適用サーバーで適用中のトランザクションに関する情報が表示されます。

COLUMN SERVER_ID HEADING 'Apply Server ID' FORMAT 99999999
COLUMN STATE HEADING 'Apply Server State' FORMAT A20
COLUMN APPLIED_MESSAGE_NUMBER HEADING 'Applied Message|Number' FORMAT 99999999
COLUMN MESSAGE_SEQUENCE HEADING 'Message Sequence|Number' FORMAT 99999999

SELECT SERVER_ID, STATE, APPLIED_MESSAGE_NUMBER, MESSAGE_SEQUENCE
FROM V$STREAMS_APPLY_SERVER
WHERE APPLY_NAME = 'STRM01_APPLY'
ORDER BY SERVER_ID;

この問合せを繰り返し実行する場合、適用サーバーがトランザクションを適用すると、各適用サーバーの状態、適用されるメッセージ番号およびメッセージ順序番号が長時間かけて変更され続けます。これらの値が1つ以上の適用サーバーに対して変更されない場合、適用サーバーのパフォーマンスが低下することがあります。この場合、適用プロセスによって変更が適用される表ごとに、すべてのキー列に索引が設定されていることを確認する必要があります。

このような表が数多くある場合は、特定の表と適用サーバーのパフォーマンスを低下させているDML操作またはDDL操作を判別する必要があることがあります。このことを行うには、適用サーバーでトランザクションを適用するのに異常に長い時間がかかっているときに、次の問合せを実行します。この例では、適用プロセスの名前がstrm01_applyであり、適用サーバー番号2のパフォーマンスが低いと想定しています。

COLUMN OPERATION HEADING 'Operation' FORMAT A20
COLUMN OPTIONS HEADING 'Options' FORMAT A20
COLUMN OBJECT_OWNER HEADING 'Object|Owner' FORMAT A10
COLUMN OBJECT_NAME HEADING 'Object|Name' FORMAT A10
COLUMN COST HEADING 'Cost' FORMAT 99999999

SELECT p.OPERATION, p.OPTIONS, p.OBJECT_OWNER, p.OBJECT_NAME, p.COST
FROM V$SQL_PLAN p, V$SESSION s, V$STREAMS_APPLY_SERVER a
WHERE a.APPLY_NAME = 'STRM01_APPLY' AND a.SERVER_ID = 2
AND s.SID = a.SID
AND p.HASH_VALUE = s.SQL_HASH_VALUE;

この問合せにより、指定した適用サーバーで現在実行中の操作が返されます。また、操作が実行されている表の所有者と名前および操作のコストも返されます。この表の各キー列に索引があることを確認します。結果がCOST列に対してFULLを示している場合、この操作によって全表スキャンが実行されています。この問題は、表のキー列の索引を作成することにより解決する場合があります。

また、次の問合せを実行すると、適用サーバーのパフォーマンスを低下させている特定のDMLまたはDDL SQL文を判別できます。適用プロセスの名前がstrm01_applyであり、適用サーバー番号2のパフォーマンスが低いと想定しています。

SELECT t.SQL_TEXT
FROM V$SESSION s, V$SQLTEXT t, V$STREAMS_APPLY_SERVER a
WHERE a.APPLY_NAME = 'STRM01_APPLY' AND a.SERVER_ID = 2
AND s.SID = a.SID
AND s.SQL_ADDRESS = t.ADDRESS
AND s.SQL_HASH_VALUE = t.HASH_VALUE
ORDER BY PIECE;

この問合せにより、指定した適用サーバーで現在実行中のSQL文が返されます。この文には、トランザクションが適用されている表の名前が含まれます。この表の各キー列に索引があることを確認します。

前述の問合せで返されるSQL文が1000文字未満である場合は、かわりに次の簡易化された問合せを実行できます。

SELECT t.SQL_TEXT
FROM V$SESSION s, V$SQLAREA t, V$STREAMS_APPLY_SERVER a
WHERE a.APPLY_NAME = 'STRM01_APPLY' AND a.SERVER_ID = 2
AND s.SID = a.SID
AND s.SQL_ADDRESS = t.ADDRESS
AND s.SQL_HASH_VALUE = t.HASH_VALUE;

関連項目:
V$SQL_PLAN動的パフォーマンス・ビューの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』および『Oracle Databaseリファレンス』を参照

エラー・キューに適用エラーがあるか

適用プロセスでメッセージが適用できない場合は、そのメッセージおよび同じトランザクション内の他のすべてのメッセージがエラー・キューに移されます。適用エラーを定期的にチェックして、適用できなかったトランザクションの有無をチェックする必要があります。

関連項目:

- 「適用エラーのチェック」

- 「適用エラーの詳細情報の表示」

DMLハンドラを使用したエラー・トランザクションの修正

適用プロセスによってトランザクションがエラー・キューに移動される場合は、トランザクションを確認してトランザクションを正常に再実行できる可能性を分析できます。トランザクションに異常が見つかった場合は、文DMLハンドラまたはプロシージャDMLハンドラを構成して問題を修正できることがあります。この場合、エラー・トランザクションを再実行するときに実行されるようにDMLハンドラを構成します。

DMLハンドラを使用してエラー・トランザクションの問題を修正する場合は、そのDMLハンドラを使用する適用プロセスを停止して、エラー・トランザクションに関係ないLCRがDMLハンドラによって処理されないようにする必要があります。正常に再実行した後で、DMLハンドラが不要であれば削除します。また、トランザクションがエラー・キューに移動される原因となった問題を修正して、将来エラー・トランザクションが発生しないようにします。

関連項目:
「DMLハンドラの管理」

特定の適用エラーのトラブルシューティング

LCRについて次のタイプの適用プロセス・エラーが発生する場合があります。

- ORA-01031 権限が不足しています。

- ORA-01403 データが見つかりません。

- ORA-23605 Oracle Streamsパラメータの値が無効です*

- ORA-23607 列は無効です。*

- ORA-24031 値が無効です。parameter_nameにはNULLでない値が必要です。*

- ORA-26687 インスタンス化SCNが指定されていません

- ORA-26688 LCRにキーがありません。

- ORA-26689 列データ型が一致していません*

- ORA-26786 キーの行は存在しますが、競合する列が表にあります

- ORA-26787 キーcolumn_valueの行は表table_nameにありません

前述のリストでアスタリスク(*)の付いたエラーは、通常、適用ハンドラまたはルールベースの変換に関する問題が原因となって発生します。

関連項目:

- 「適用エラーのチェック」

- 「適用エラーの管理」

- 「エラー・キュー」

ORA-01031 権限が不足しています

ORA-01031エラーは、適用ユーザーとして指定されたユーザーに、レプリケートされたオブジェクトにSQL操作を実行する権限がない場合に発生します。適用ユーザーの権限は直接付与するか、またはロールを介して付与できます。

具体的には、次の権限が必要となります。

- 表レベルのDML変更の場合は、INSERT、UPDATE、DELETEおよびSELECTの各権限が付与されている必要があります。

- 表レベルのDDL変更の場合は、ALTER TABLE権限が付与されている必要があります。

- スキーマ・レベルの変更の場合は、CREATE ANY TABLE、CREATE ANY INDEX、CREATE ANY PROCEDURE、ALTER ANY TABLEおよびALTER ANY PROCEDUREの各権限が付与されている必要があります。

- グローバル・レベルの変更の場合は、ALL PRIVILEGESが適用ユーザーに付与されている必要があります。

このエラーを修正するには、次の手順を実行します。

1. 宛先データベースの適用ユーザーとして接続します。

2. SESSION_PRIVSデータ・ディクショナリ・ビューを問い合せて、適用ユーザーに付与されていない必須の権限を判別します。

3. 権限を付与できる管理ユーザーとして接続します。

4. 必要な権限を適用ユーザーに付与します。

5. 適用プロセスのエラー・キューにあるエラー・トランザクションを再実行します。

関連項目:

- 「適用ユーザー」

- 「適用エラー・トランザクションの再試行」

ORA-01403 データが見つかりません。

通常、ORA-01403エラーは、適用プロセスが既存の行の更新を試行した際に、行LCRのOLD_VALUESが宛先データベースの現在の値と一致しない場合に発生します。

通常、このエラーは次の状態のいずれかが原因となって発生します。

- ソース・データベースでサプリメンタル・ロギングを必要とする列に対してサプリメンタル・ロギングが指定されていない状態。この場合、ソース・データベースのLCRにキー列値が含まれていないことがあります。プロシージャDMLハンドラを使用して、必要なサプリメンタル・データが含まれるようにLCRを変更できます。「DMLハンドラを使用したエラー・トランザクションの修正」を参照してください。また、将来エラーが発生しないように、ソース・データベースで必要なサプリメンタル・ロギングを指定します。

- LCRが変更を適用する表の主キーに問題がある状態。この場合、DBA_CONSTRAINTSデータ・ディクショナリ・ビューを問い合せて主キーが使用可能となるようにします。表に対して主キーが存在しないか、または対象の表の主キーがソース表の主キーと異なる場合は、DBMS_APPLY_ADMパッケージのSET_KEY_COLUMNSプロシージャを使用して代替キー列を指定します。また、適用されている表に主キーが存在しない場合、エラーORA-23416が発生することもあります。これらの変更を行った後、エラー・トランザクションを再実行できます。

- 適用されているトランザクションが、まだ実行されていない別のトランザクションに依存している状態。たとえば、トランザクションでemployee_idが300の従業員を更新しようとしたものの、この従業員の行がまだemployees表に挿入されていない場合、更新は失敗します。この場合、エラー・トランザクションが依存するトランザクションを実行します。次に、エラー・トランザクションを再実行します。

関連項目:

- 「Oracle Streams環境内のサプリメンタル・ロギング」

- 適用エラーの考えられる原因の詳細は、「表へのDML変更の適用に関する考慮事項」を参照

- 「適用エラーの詳細情報の表示」

- 「適用エラーの管理」

- Oracle Streamsタグの詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

ORA-23605 Oracle Streamsパラメータの値が無効です

行LCR(SYS.LCR$_ROW_RECORDタイプ)メンバー・サブプログラムをコールする際に、このメンバー・サブプログラムによって渡されるパラメータの値が行LCRと一致しない場合にORA-23605エラーが発生することがあります。たとえば、メンバー・サブプログラムが挿入行LCRへの古い列値の追加や、LOB列値の数値への設定を試行した場合にエラーが発生します。

行LCRには、操作に応じて次のように古い値と新しい値が含まれている必要があります。

- INSERT操作の行LCRには、古い値ではなく新しい値が含まれている必要があります。

- UPDATE操作の行LCRには、新しい値と古い値の両方を含めることができます。

- DELETE操作の行LCRには、新しい値ではなく古い値が含まれている必要があります。

正しいパラメータ・タイプ(OLDまたはNEWあるいはその両方)が行LCRの操作(INSERT、UPDATEまたはDELETE)に対して指定されていることを確認します。たとえば、プロシージャDMLハンドラまたはカスタム・ルールベースの変換によってUPDATEの行LCRがINSERTの行LCRに変更される場合は、ハンドラまたは変換で行LCRの古い値が削除される必要があります。

適用ハンドラがエラーの原因である場合、適用ハンドラを修正し、エラー・トランザクションを再実行してください。カスタム・ルールベースの変換がエラーの原因である場合、DMLハンドラを作成して問題を修正できます。「DMLハンドラを使用したエラー・トランザクションの修正」を参照してください。また、将来エラーが発生しないようにルールベースの変換を修正します。

関連項目:
第6章「ルールベースの変換」

ORA-23607 列は無効です。

ORA-23607エラーは、メンバー・サブプログラムのcolumn_nameパラメータの値が行LCRの列名のいずれとも一致しない場合、行LCR(SYS.LCR$_ROW_RECORDタイプ)メンバー・サブプログラムが原因で発生します。行LCRの列名をチェックします。

適用ハンドラがエラーの原因である場合、適用ハンドラを修正し、エラー・トランザクションを再実行してください。カスタム・ルールベースの変換がエラーの原因である場合、DMLハンドラを作成して問題を修正できます。「DMLハンドラを使用したエラー・トランザクションの修正」を参照してください。また、将来エラーが発生しないようにルールベースの変換を修正します。

次の行LCRメンバー・プロシージャのいずれかを使用することにより、適用ハンドラまたはカスタム・ルールベースの変換が原因でこのエラーが発生する可能性があります。

- DELETE_COLUMN(このプロシージャによって、行LCRから、行LCRに存在しない列の削除が試行される場合)

- RENAME_COLUMN(このプロシージャによって、行LCRに存在しない列の名前の変更が試行される場合)

この場合、同様の問題が将来発生しないようにするには、次のアクションのいずれかを実行します。

- 行LCRの列を削除したり名前を変更するために適用ハンドラまたはカスタム・ルールベースの変換を使用するかわりに、宣言ルールベースの変換を使用します。宣言ルールベースの変換によって存在しない列の削除または名前の変更が試行される場合、宣言ルールベースの変換ではエラーは発生しません。DBMS_STREAMS_ADM.DELETE_COLUMNプロシージャを使用して列を削除する宣言ルールベースの変換を指定でき、DBMS_STREAMS_ADM.RENAME_COLUMNプロシージャを使用して列の名前を変更する宣言ルールベースの変換を指定できます。宣言ルールベースの変換は、適用ハンドラおよびカスタム・ルールベースの変換と組み合せて使用できます。

- 行LCRの列を削除したり名前を変更するのに適用ハンドラまたはカスタム・ルールベースの変換を引き続き使用する必要がある場合は、将来エラーが発生しないようにハンドラまたは変換を変更します。たとえば、ハンドラや変換を変更して列が存在していることを確認してから、その列を削除したり名前を変更します。

関連項目:

- 第6章「ルールベースの変換」

- 行LCRのDELETE_COLUMNおよびRENAME_COLUMNメンバー・プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

ORA-24031 値が無効です。parameter_nameにはNULLでない値が必要です。

ORA-24031エラーは、適用ハンドラまたはカスタム・ルールベースの変換により、LCRメンバー・サブプログラムにNULLを含むANYDATAではなく、NULL値が渡された場合に発生する可能性があります。

たとえば、行LCRに対するADD_COLUMNメンバー・プロシージャの次のコールでは、このエラーが発生する可能性があります。

new_lcr.ADD_COLUMN('OLD','LANGUAGE',NULL);

次の例は、行LCRに対してADD_COLUMNメンバー・プロシージャを適切にコールする方法を示しています。

new_lcr.ADD_COLUMN('OLD','LANGUAGE',ANYDATA.ConvertVarchar2(NULL));

適用ハンドラがエラーの原因である場合、適用ハンドラを修正し、エラー・トランザクションを再実行してください。カスタム・ルールベースの変換がエラーの原因である場合、DMLハンドラを作成して問題を修正できます。「DMLハンドラを使用したエラー・トランザクションの修正」を参照してください。また、将来エラーが発生しないようにルールベースの変換を修正します。

関連項目:
第6章「ルールベースの変換」

ORA-26687 インスタンス化SCNが指定されていません

ORA-26687エラーは、適用プロセスが変更の適用を試行しているオブジェクトにインスタンス化SCNが設定されていない場合に発生します。この場合、DBA_APPLY_INSTANTIATED_OBJECTSデータ・ディクショナリ・ビューに問い合せ、インスタンス化SCNを持つオブジェクトをリストできます。

インスタンス化SCNは、ソース・データベースでオブジェクトをエクスポートしてから宛先データベースでそれらのオブジェクトをインポートすることにより、1つ以上のオブジェクトに対して設定できます。データ・ポンプ・エクスポート/インポートを使用できます。エクスポート/インポートを使用しない場合は、DBMS_APPLY_ADMパッケージ内の次のプロシージャのうち1つ以上を実行できます。

- SET_TABLE_INSTANTIATION_SCN

- SET_SCHEMA_INSTANTIATION_SCN

- SET_GLOBAL_INSTANTIATION_SCN

インスタンス化SCNが宛先データベースでオブジェクトに対して設定されない場合の一般的な理由としては、次のような理由があげられます。

- インスタンス化にエクスポート/インポートを使用して、オブジェクトをインスタンス化のために準備する前にソース・データベースからエクスポートしました。DBMS_STREAMS_ADMパッケージを使用してOracle Streamsルールをオブジェクトに対して作成するか、またはDBMS_CAPTURE_ADMパッケージのプロシージャまたはファンクションを実行し、オブジェクトのインスタンス化の準備を行うことができます。エクスポート前にオブジェクトのインスタンス化の準備が行われていないと、インスタンス化SCNの情報をエクスポート・ファイルで使用できず、インスタンス化SCNが設定されません。
この場合、ソース・データベースでデータベース・オブジェクトのインスタンス化の準備を行います。次に、宛先データベースでデータベース・オブジェクトに対してインスタンス化SCNを設定します。

- インスタンス化にエクスポート/インポートを使用するかわりに、DBMS_APPLY_ADMパッケージの適切なプロシージャを使用してインスタンス化SCNを明示的に設定しました。データベース管理者によってインスタンス化SCNが明示的に設定される場合、データの正確性についての責任は管理者にあります。
この場合、データベース・オブジェクトに対してインスタンス化SCNを明示的に設定します。または、メタデータのみのエクスポート/インポートを実行してインスタンス化SCNを設定することもできます。

- DDL変更を適用する必要があるものの、スキーマ・レベルまたはグローバル・レベルでインスタンス化SCNを設定しませんでした。
この場合、SET_SCHEMA_INSTANTIATION_SCNプロシージャを実行して適切なスキーマに対してインスタンス化SCNを設定するか、またはSET_GLOBAL_INSTANTIATION_SCNプロシージャを実行してソース・データベースに対してインスタンス化SCNを設定します。これらのプロシージャは両方ともDBMS_APPLY_ADMパッケージにあります。

エラーが発生する原因となった状態を修正した後、エラー・トランザクションを再実行または削除する必要があるかどうかは、トランザクションに含まれる変更がエラー状態を修正したときに宛先データベースで実行されたかどうかによって異なります。エラー・キュー内のトランザクションを再実行または削除する必要があるかどうかを決定するときには、次のガイドラインに従ってください。

- 新規エクスポート/インポートを実行し、新規エクスポートにエラー・キュー内のトランザクションが含まれる場合は、エラー・キュー内のトランザクションを削除します。

- インスタンス化SCNを明示的に設定するか既存のエクスポート・ダンプ・ファイルを再インポートした場合は、エラー・キュー内のトランザクションを再実行します。

関連項目:

- インスタンス化の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- 「適用エラー・トランザクションの再試行」

ORA-26688 LCRにキーがありません。

通常、ORA-26688エラーは次の状態のいずれかが原因となって発生します。

- トランザクションの少なくとも1つのLCRに、そのLCRを適用するための適用プロセスに関する十分な情報が含まれていない状態。依存性を計算する場合、適用プロセスでは常に、宛先データベースで定義された主キー列(複数可)の値が必要となります。また、変更を適用する任意の適用プロセスの並列性が1より大きい場合、適用プロセスでは、宛先データベースで任意の索引列(一意または一意でない索引列、外部キー列およびビットマップ索引列など)の値が必要となります。
適用プロセスで列に値が設定されている必要があり、その列がソース・データベースに存在する場合、ソース・データベースでこれらの1つ以上の列に対してサプリメンタル・ロギングが指定されていないとこのエラーが発生します。この場合、適用エラーを回避するには、ソース・データベースで必要なサプリメンタル・ロギングを指定します。

ただし、ソース・データベース表の定義が対応する宛先データベース表の定義と異なる場合があります。適用プロセスで列に値が設定されている必要があり、その列が宛先データベースに存在するがソース・データベースには存在しない場合、ソース・データベースのLCRに必要な値を追加するようにルールベースの変換を構成し、適用エラーを回避できます。

このエラーが原因でエラー・キューに置かれたトランザクションを修正するには、プロシージャDMLハンドラを使用して、必要なサプリメンタル・データが含まれるようにLCRを変更できます。「DMLハンドラを使用したエラー・トランザクションの修正」を参照してください。

- LCRが変更を適用する表の主キーに問題がある状態。この場合、DBA_CONSTRAINTSデータ・ディクショナリ・ビューを問い合せて主キーが使用可能となるようにします。表に対して主キーが存在していないか、または宛先の表の主キーがソース表の主キーと異なる場合は、DBMS_APPLY_ADMパッケージのSET_KEY_COLUMNSプロシージャを使用して代替キー列を指定します。また、表に主キーが存在しない場合、エラーORA-23416が発生することもあります。これらの変更を行った後、エラー・トランザクションを再実行できます。

関連項目:

- 「Oracle Streams環境内のサプリメンタル・ロギング」

- 「代替キー列」

- 第6章「ルールベースの変換」

ORA-26689 列データ型が一致していません

通常、ORA-26689エラーは、ソース・データベース内の1つ以上の列が宛先データベースの対応する列と一致しないために発生します。ソース・データベースのLCRに宛先データベースの表よりも多くの列が含まれていたり、1つ以上の列に対して列名や列の型が一致していない場合があります。列がデータベース間で異なる場合は、ルールベースの変換を使用して将来エラーが発生しないようにできます。

適用ハンドラまたはカスタム・ルールベースの変換を使用する場合は、任意のANYDATA変換ファンクションが変換対象のLCRのデータ型と一致することを確認します。たとえば、列がVARCHAR2として指定されている場合、ANYDATA.CONVERTVARCHAR2ファンクションを使用して、データを型ANYからVARCHAR2に変換します。

また、ルール条件、適用ハンドラおよびルールベースの変換で適切な大/小文字を使用していることを確認してください。たとえば、列名がデータ・ディクショナリですべて大文字となっている場合、ルール条件、適用ハンドラおよびルールベースの変換ですべて大文字を使用して列名を指定する必要があります。

このエラーは、サプリメンタル・ロギングがソース・データベースの非キー列に対して必須である場所で指定されていないために発生する可能性もあります。この場合、ソース・データベースのLCRにはこれらの非キー列に対する必要な値が含まれていないことがあります。

エラー・トランザクションを適用するようにDMLハンドラを構成できる場合があります。「DMLハンドラを使用したエラー・トランザクションの修正」を参照してください。

関連項目:

- 適用エラーの考えられる原因の詳細は、「表へのDML変更の適用に関する考慮事項」を参照

- 「Oracle Streams環境内のサプリメンタル・ロギング」

- 第6章「ルールベースの変換」

ORA-26786 キーの行は存在しますが、競合する列が表にあります

宛先の表の行における一部の列の値が、行LCRの対応する列の古い値と一致しない場合、ORA-26786エラーが発生します。

将来適用エラーが発生しないようにするには、競合ハンドラ、DMLハンドラまたはエラー・ハンドラを構成できます。ハンドラによって、レプリケーション環境にとって適切な方法で一致しない列が解決される必要があります。

また、このエラーが原因となって発生した既存のエラー・トランザクションを適用するようにDMLハンドラを構成できる場合があります。「DMLハンドラを使用したエラー・トランザクションの修正」を参照してください。

または、行LCRを正常に適用できるように行の現在の値を更新できます。行への変更が宛先データベースで取得プロセスまたは同期取得によって取得される場合、このような手動による変更が他の宛先データベースに対してレプリケートされないようにすることがあります。この場合、次の手順を実行します。

1. 行を修正するセッションでタグを設定します。手動による変更がレプリケートされないようにする値をタグに設定するようにしてください。たとえば、タグにより、取得プロセスまたは同期取得によって変更が取得されないようにすることができます。

EXEC DBMS_STREAMS.SET_TAG(tag => HEXTORAW('17'));

環境によっては、異なる値をタグに設定する必要がある場合があります。

2. データがLCRの古い値と一致するように表の行を更新します。

3. 該当するエラーまたはすべてのエラーを再実行します。1つのエラーを再実行するには、DBMS_APPLY_ADMパッケージのEXECUTE_ERRORプロシージャを実行して、そのエラーの原因となったトランザクションのトランザクション識別子を指定します。次に例を示します。

EXEC DBMS_APPLY_ADM.EXECUTE_ERROR(local_transaction_id => '5.4.312');

または、次のようにEXECUTE_ALL_ERRORSプロシージャを実行して、適用プロセスに対するすべてのエラーを実行します。

EXEC DBMS_APPLY_ADM.EXECUTE_ALL_ERRORS(apply_name => 'APPLY');

4. 現在のセッションで他の変更を行い、その変更を宛先データベースにレプリケートする場合は、セッションのタグを適切な値に設定しなおします。次に例を示します。

EXEC DBMS_STREAMS.SET_TAG(tag => NULL);

環境によっては、NULL以外の値をタグに設定する必要があります。

関連項目:

- 競合解決の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- 「DMLハンドラの管理」

ORA-26787 キーcolumn_valueの行は表table_nameにありません

行LCRが更新または削除しようとしている行が宛先の表に存在しない場合、ORA-26787エラーが発生します。

将来適用エラーが発生しないようにするには、競合ハンドラ、DMLハンドラまたはエラー・ハンドラを構成できます。ハンドラによって、レプリケーション環境にとって適切な方法で、対応する表の行が存在しない行LCRが解決されます。

また、このエラーが原因となって発生した既存のエラー・トランザクションを適用するようにDMLハンドラを構成できる場合があります。「DMLハンドラを使用したエラー・トランザクションの修正」を参照してください。

または、行LCRを正常に適用できるように行の現在の値を更新できます。手順については、「ORA-26786 キーの行は存在しますが、競合する列が表にあります」を参照してください。

関連項目:

- 競合解決の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- 「DMLハンドラの管理」

34 ルールおよびルールベースの変換のトラブルシューティング

取得プロセス、同期取得、伝播、適用プロセスまたはメッセージ・クライアントが予期したとおりに動作しない場合、Oracle Streamsクライアントのルール・セット、ルールまたはルールベース変換が適切に構成されていないことが原因である可能性があります。次の項を参照して、ルール・セット、ルールおよびルールベース変換の問題を特定して解決します。

次の各項では、Oracle Streams環境でのルールおよびルールベース変換の一般的な問題の特定と解決について説明します。

- Oracle Streamsクライアントのルールが適切に構成されているか

- 宣言ルールベースの変換が適切に構成されているか

- カスタム・ルールベースの変換が適切に構成されているか

- 誤って変換されたLCRがエラー・キューにないか

関連項目:

- 第5章「Oracle Streamsでのルールの使用方法」

- 第11章「ルールの高度な概念」

- 第18章「ルールの管理」

- 第27章「ルールの監視」

Oracle Streamsクライアントのルールが適切に構成されているか

取得プロセス、同期取得、伝播、適用プロセスまたはメッセージ・クライアントが想定したとおりに動作しない場合は、Oracle Streamsクライアントの1つ以上のルール・セットのルールが適切に構成されていないことが問題である可能性があります。たとえば、取得プロセスが特定の表に対する変更を取得することを予期していたが、取得しないという場合は、取得プロセスで使用されるルール・セット内のルールが、表の変更を取得するように取得プロセスに指示していないことが原因である可能性があります。

DBA_STREAMS_RULESデータ・ディクショナリ・ビューを問い合せると、特定のOracle Streamsクライアントのルールをチェックできます。Oracle Streams環境でポジティブ・ルール・セットとネガティブ・ルール・セットの両方を使用する場合は、このビューで返されるルールが特定のOracle Streamsクライアントのポジティブ・ルール・セットかネガティブ・ルール・セットかを把握することが重要です。

Oracle Streamsクライアントは、ルール・セットを満たすメッセージに対して取得、伝播、適用、デキューなどのアクションを実行します。通常、メッセージがOracle Streamsクライアントのルールを満たすのは、メッセージについてネガティブ・ルール・セットのどのルールもTRUEと評価されず、ポジティブ・ルール・セットの1つ以上のルールがTRUEと評価された場合です。

「ルール・セットおよびメッセージのルール評価」では、メッセージがどのようにOracle Streamsクライアントのルール・セットを満たすかに関する詳細情報を示します。これには、1つ以上のルール・セットが指定されていない場合のOracle Streamsクライアントの動作に関する情報が含まれます。

関連項目:

- 「ルール・セットおよびメッセージのルール評価」

この項は、次のトピックで構成されています。

- スキーマ・ルールおよびグローバル・ルールのチェック

- 表ルールのチェック

- サブセット・ルールのチェック

- メッセージ・ルールのチェック

- ルールに関する問題の解決

スキーマ・ルールおよびグローバル・ルールのチェック

Oracle Streamsクライアントのポジティブ・ルール・セット内のスキーマ・ルールおよびグローバル・ルールでは、それぞれ特定のスキーマまたはデータベースに関連するすべてのメッセージに対してタスクを実行するようOracle Streamsクライアントに指示します。Oracle Streamsクライアントのネガティブ・ルール・セット内のスキーマ・ルールおよびグローバル・ルールでは、それぞれ特定のスキーマまたはデータベースに関連するすべてのメッセージを廃棄するようOracle Streamsクライアントに指示します。Oracle Streamsクライアントが予期したとおりに動作しない場合、Oracle Streamsに対してスキーマ・ルールまたはグローバル・ルールが正しく構成されていないことが原因の可能性があります。

たとえば、データベースでstrm01_applyという適用プロセスが実行されていて、hrスキーマの変更を含むLCRをこの適用プロセスで適用するとします。適用プロセスでネガティブ・ルール・セットが使用される場合は、このスキーマについてTRUEと評価されるスキーマ・ルールがそのネガティブ・ルール・セットに存在しないことを確認します。そのようなルールがあると、スキーマの変更を含むLCRが適用プロセスによって廃棄されます。Oracle Streamsクライアント用のネガティブ・ルール・セット内のルールの表示に、このようなルールを表示する問合せの例を示しています。

問合せによってこのようなルールが返される場合、返されたルールが原因で、スキーマの変更が適用プロセスによって廃棄されている可能性があります。この問合せによって行が返されない場合は、このスキーマについてTRUEと評価されるスキーマ・ルールが適用プロセスのポジティブ・ルール・セット内に存在することを確認してください。Oracle Streamsクライアント用のネガティブ・ルール・セット内のルールの表示に、このようなルールが表示される問合せの例を示しています。

表ルールのチェック

Oracle Streamsクライアントのポジティブ・ルール・セット内の表ルールでは、1つ以上の特定の表に関連するメッセージに対してタスクを実行するようOracle Streamsクライアントに指示します。Oracle Streamsクライアントのネガティブ・ルール・セット内の表ルールでは、1つ以上の特定の表に関連するメッセージを廃棄するようOracle Streamsクライアントに指示します。

Oracle Streamsクライアントが特定の表に対して予期したとおりに動作しない場合は、次のいずれかが原因の可能性があります。

- その表が特定のデータベースに含まれるために、Oracle Streamsクライアントのルール・セット内の1つ以上のグローバル・ルールで、その表に関連するメッセージに対して特定の方法で動作するよう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クライアントのルール・セット内の1つ以上の表ルールで、その表に関連するメッセージに対して特定の方法で動作するようOracle Streamsクライアントに指示している場合。

関連項目:
「スキーマ・ルールおよびグローバル・ルールのチェック」

予期しない動作の原因がグローバル・ルールまたはスキーマ・ルールではないと思われる場合は、Oracle Streamsクライアントのルール・セット内の表ルールをチェックします。たとえば、取得プロセスが特定の表の変更を取得することを想定しているが、取得されない場合、取得プロセスのポジティブ・ルール・セットとネガティブ・ルール・セット内のルールで、その表の変更を取得するように指示していないことが原因であることがあります。

データベースでstrm01_captureという取得プロセスが実行され、この取得プロセスでhr.departments表に対する変更を取得するとします。取得プロセスでネガティブ・ルール・セットが使用される場合、この表に対してTRUEと評価される表ルールがこのネガティブ・ルール・セットに存在しないことを確認します。そのようなルールがあると、この表に対する変更が取得プロセスによって廃棄されます。「Oracle Streamsクライアント用のネガティブ・ルール・セット内のルールの表示」に、ネガティブ・ルール・セット内のルールを表示する問合せの例を示しています。

問合せによってこのようなルールが返される場合、返されたルールが原因で、表の変更が取得プロセスによって廃棄されている可能性があります。この問合せによってルールが返されない場合は、この表についてTRUEと評価される表ルールが取得プロセスのポジティブ・ルール・セットに1つ以上含まれていることを確認します。「Oracle Streamsクライアント用のポジティブ・ルール・セット内のルールの表示」に、ポジティブ・ルール・セット内のルールを表示する問合せの例を示しています。

ルール条件に特定のパターンが含まれるルールを特定することもできます。「条件に指定パターンが含まれる各ルールのリスト表示 」を参照してください。たとえば、ルール条件にdepartmentsという文字列のあるすべてのルールを検索し、これらのルールが正しいルール・セットに含まれることを確認できます。

関連項目:
表ルールの指定の詳細は、「表ルールの例」を参照

サブセット・ルールのチェック

サブセット・ルールは、取得プロセス、同期取得、伝播、適用プロセスまたはメッセージ・クライアントで使用されるルール・セットに含めることができます。サブセット・ルールは、表内の特定の行サブセットに対する変更がDML操作に含まれる場合にのみTRUEと評価されます。たとえば、hr.departments表に対する変更があるときに、strm01_applyという適用プロセスについてTRUEと評価される表ルールをチェックするには、次の問合せを実行します。

COLUMN RULE_NAME HEADING 'Rule Name' FORMAT A20
COLUMN RULE_TYPE HEADING 'Rule Type' FORMAT A20
COLUMN DML_CONDITION HEADING 'Subset Condition' FORMAT A30

SELECT RULE_NAME, RULE_TYPE, DML_CONDITION
FROM DBA_STREAMS_RULES
WHERE STREAMS_NAME   = 'STRM01_APPLY' AND
STREAMS_TYPE   = 'APPLY' AND
SCHEMA_NAME    = 'HR' AND
OBJECT_NAME    = 'DEPARTMENTS';

Rule Name            Rule Type            Subset Condition
-------------------- -------------------- ------------------------------
DEPARTMENTS5         DML                  location_id=1700
DEPARTMENTS6         DML                  location_id=1700
DEPARTMENTS7         DML                  location_id=1700

この問合せでは、出力結果にSubset Conditionというラベルが付くDML_CONDITION列に表のサブセット条件が返されることに注意してください。この例では、hr.departments表に対してサブセット・ルールが指定されています。これらのサブセット・ルールは、location_id が1700である行が関与する変更がLCRに含まれている場合にのみTRUEと評価されます。したがって、適用プロセスで表のすべての変更が適用されることを想定している場合でも、これらのサブセット・ルールにより、location_idが1700ではない行が関係する変更は廃棄されます。

注意:
サブセット・ルールは、ポジティブ・ルール・セット内にのみ存在する必要があります。

関連項目:

- サブセット・ルールの指定の詳細は、「表ルールの例」を参照

- 「行の移行およびサブセット・ルール」

メッセージ・ルールのチェック

メッセージ・ルールは、伝播、適用プロセスまたはメッセージ・クライアントで使用されるルール・セットに含めることができます。メッセージ・ルールは、取得LCRではなく、指定したメッセージ・タイプのユーザー・メッセージのみに関連します。メッセージ・ルールがTRUEと評価されるのは、キュー内のユーザー・メッセージがメッセージ・ルールで指定されたメッセージ・タイプであり、メッセージ・ルールのルール条件を満たしている場合のみです。

伝播、適用プロセスまたはメッセージ・クライアントで特定のユーザー・メッセージに対してタスクが実行されることを想定していたが、Oracle Streamsクライアントではそれらのメッセージに対するタスクが実行されない場合は、Oracle Streamsクライアントのポジティブ・ルール・セットおよびネガティブ・ルール・セット内のルールで、それらのメッセージに対するタスクを実行するようにOracle Streamsクライアントに指示していないことが原因である可能性があります。同様に、伝播、適用プロセスまたはメッセージ・クライアントで、特定のユーザー・メッセージが廃棄されることを想定していたが、Oracle Streamsクライアントではそれらのメッセージが廃棄されない場合は、Oracle Streamsクライアントのポジティブ・ルール・セットおよびネガティブ・ルール・セット内のルールで、それらのメッセージを廃棄するように指示していないことが原因である可能性があります。

たとえば、oeというメッセージ・クライアントで、次の条件を満たすoe.user_msgタイプのメッセージをデキューするとします。

:"VAR$_2".OBJECT_OWNER = 'OE' AND  :"VAR$_2".OBJECT_NAME = 'ORDERS'

メッセージ・クライアントでネガティブ・ルール・セットが使用される場合は、このメッセージ・タイプについてTRUEと評価されるメッセージ・ルールがネガティブ・ルール・セット内に存在しないことを確認します。このようなルールがあると、メッセージ・クライアントでそれらのメッセージが廃棄されます。たとえば、メッセージ・クライアントのネガティブ・ルール・セットにそのようなルールが存在するかどうか判別するには、次の問合せを実行します。

COLUMN RULE_NAME HEADING 'Rule Name' FORMAT A30
COLUMN RULE_CONDITION HEADING 'Rule Condition' FORMAT A30

SELECT RULE_NAME, RULE_CONDITION
FROM DBA_STREAMS_RULES
WHERE STREAMS_NAME       = 'OE' AND
MESSAGE_TYPE_OWNER = 'OE' AND
MESSAGE_TYPE_NAME  = 'USER_MSG' AND
RULE_SET_TYPE      = 'NEGATIVE';

この問合せによってルールが返される場合は、それらのルールが原因となってメッセージ・クライアントでメッセージが廃棄されている可能性があります。返されたルールのルール条件を調べて、それらのルールが、メッセージ・クライアントでデキューする必要があるメッセージを廃棄する原因となっているかどうか判別します。この問合せでルールが返されない場合は、このメッセージ・タイプと条件についてTRUEと評価されるメッセージ・ルールがメッセージ・クライアントのポジティブ・ルール・セットに存在することを確認します。

たとえば、このメッセージ・タイプについてTRUEと評価されるメッセージ・ルールがメッセージ・クライアントのポジティブ・ルール・セットに存在するかどうか判別するには、次の問合せを実行します。

COLUMN RULE_NAME HEADING 'Rule Name' FORMAT A35
COLUMN RULE_CONDITION HEADING 'Rule Condition' FORMAT A35

SELECT RULE_NAME, RULE_CONDITION
FROM DBA_STREAMS_RULES
WHERE STREAMS_NAME       = 'OE' AND
MESSAGE_TYPE_OWNER = 'OE' AND
MESSAGE_TYPE_NAME  = 'USER_MSG' AND
RULE_SET_TYPE      = 'POSITIVE';

このメッセージ・タイプについてTRUEと評価されるメッセージ・ルールがメッセージ・クライアントのポジティブ・ルール・セットに存在する場合は、それらのルールが返されます。この場合、出力は次のようになります。

Rule Name                           Rule Condition
----------------------------------- -----------------------------------
RULE$_3                             :"VAR$_2".OBJECT_OWNER = 'OE' AND
:"VAR$_2".OBJECT_NAME = 'ORDERS'

返されたルールのルール条件を調べて、適切なメッセージをデキューするようメッセージ・クライアントに指示しているかどうか判別します。これらの結果に基づき、oeというメッセージ・クライアントは出力に表示された条件を満たすoe.user_msgタイプのメッセージをデキューします。つまり、ルール条件を満たすoe.user_msgタイプのメッセージがキュー内でメッセージ・クライアントによって検出されたときに、それらのメッセージを廃棄するルールが、メッセージ・クライアントのネガティブ・ルール・セットに存在せず、そのメッセージをTRUEと評価するルールがメッセージ・クライアントのポジティブ・ルール・セットに存在しています。

関連項目:

- メッセージ・ルールの指定の詳細は、「メッセージ・ルールの例」を参照

- メッセージングに関する基本情報は、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照

- メッセージングの詳細は、『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイド』を参照

ルールに関する問題の解決

Oracle Streamsクライアントのルール・セットに、必要なルールが欠落していることにより、Oracle Streamsの取得プロセス、同期取得、伝播、適用プロセスまたはメッセージ・クライアントが予期したとおりに動作していないと思われる場合は、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

- ADD_MESSAGE_PROPAGATION_RULE

- ADD_MESSAGE_RULE

必要に応じて、DBMS_RULE_ADMパッケージを使用してカスタマイズ済ルールを追加できます。

また、Oracle Streamsの取得プロセス、同期取得、伝播、適用プロセスまたはメッセージ・クライアントが予期したとおりに動作しない原因は、ルールを変更する必要があるか、ルール・セットからルールを削除する必要があるためである場合もあります。

ルールが適切であっても、必要なメッセージがOracle Streamsの取得プロセス、伝播または適用プロセスで除外される場合は、トレース・ファイルとアラート・ログで、マルチバージョン・データ・ディクショナリ(Oracle Streamsデータ・ディクショナリ)の欠落に関する警告をチェックします。このような警告メッセージには、次の情報が含まれます。

- gdbnm: 欠落しているオブジェクトのソース・データベースのグローバル名

- scn: 欠落しているトランザクションのSCN

このようなメッセージがあるときに、カスタム取得プロセス・ルールを使用している場合、または新しい宛先データベースに既存の取得プロセス・ルールを再利用している場合は、次のようなプロシージャを適切に実行し、インスタンス化の準備をしてください。

- PREPARE_TABLE_INSTANTIATION

- PREPARE_SCHEMA_INSTANTIATION

- PREPARE_GLOBAL_INSTANTIATION

また、ソース・データベースから宛先データベースへの伝播が機能していることを確認します。Oracle Streamsデータ・ディクショナリの情報は、宛先データベースに伝播された後、その宛先データベースのディクショナリにロードされます。

関連項目:

- 「ルールの変更」

- 「ルール・セットからのルールの削除」

- データベース・オブジェクトをインスタンス化のために準備する方法の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- Oracle Streamsデータ・ディクショナリの詳細は、「Oracle Streamsデータ・ディクショナリ」を参照

宣言ルールベースの変換が適切に構成されているか

宣言ルールベースの変換は、行LCRの一般的な変換シナリオに対応するルールベースの変換です。宣言ルールベースの変換は、PL/SQLを使用せずに内部的に実行されます。Oracle Streamsの取得プロセス、同期取得、伝播、適用プロセスまたはメッセージ・クライアントが想定したとおりに動作しない場合は、そのOracle Streamsクライアントで使用されるルールに指定されている宣言ルールベースの変換をチェックし、誤りがあれば訂正します。

宣言ルールベースの変換で多く発生する問題には、次のものがあります。

- 宣言ルールベースの変換が表に指定されているか、または変換が表の列に関係している場合に、その変換が作成されたときに、そのスキーマが指定されなかった、または正しく指定されませんでした。宣言ルールベースの変換のスキーマが正しくないと、適切なLCRで変換されません。宣言ルールベースの変換を作成する際は、その表を所有しているスキーマを指定する必要があります。宣言ルールベースの変換を作成する際にスキーマを指定していないときは、デフォルトで、変換を作成するユーザーがスキーマに指定されます。
宣言ルールベースの変換のスキーマが正しくない場合、問題を解決するには、変換を削除して再作成し、各表の正しいスキーマを指定します。

- 特定のルールに対して複数の宣言ルールベースの変換が指定されている場合は、それらの変換の実行順序が正しいことを確認します。宣言ルールベースの変換の順序が正しくないと、エラーが発生するか、一貫性のないデータが生成される可能性があります。
単一のルールに対して指定された宣言ルールベースの変換の順序が正しくない場合、問題を解決するには、変換を削除し、正しい順序で再作成します。

関連項目:

- 「宣言ルールベースの変換の表示」

- 「宣言ルールベースの変換の管理」

- 「変換の順序」

カスタム・ルールベースの変換が適切に構成されているか

カスタム・ルールベースの変換は、ルールがTRUEと評価されたときに実行される、ユーザー定義ファンクションによるメッセージの変更です。カスタム・ルールベースの変換は、ルールのアクション・コンテキスト内で指定されます。また、このようなアクション・コンテキストに含まれる名前/値ペアは、名前がSTREAMS$_TRANSFORM_FUNCTION、値がユーザー作成ファンクション名です。このユーザー作成ファンクションによって変換が実行されます。ユーザー作成ファンクションに不備があると、予期しない動作が発生する可能性があります。

Oracle Streamsの取得プロセス、同期取得、伝播、適用プロセスまたはメッセージ・クライアントが想定したとおりに動作しない場合は、Oracle Streamsクライアントで使用されるルールで指定したカスタム・ルールベースの変換ファンクションをチェックして不備を修正します。DBA_STREAMS_TRANSFORM_FUNCTIONデータ・ディクショナリ・ビューを問い合せると、これらのファンクションの名前を検索できます。問題を解決するには、変換ファンクションの変更やカスタム・ルールベースの変換の削除が必要になる場合があります。また、ルールに対して変換を指定するときにはファンクション名を正確に指定してください。

カスタム・ルールベースの変換が原因のエラーによって、取得プロセス、同期取得、伝播、適用プロセスおよびメッセージ・クライアントが中断されることがあります。この場合、変換を修正しないと、Oracle Streamsクライアントを再起動または起動できないことがあります。

ルールの評価は、カスタム・ルールベースの変換の前に行われます。たとえば、表名をempsからemployeesに変更する変換がある場合は、その変換を使用する各ルールのルール条件で、表名employeesではなくempsが指定されていることを確認してください。

関連項目:

- 「ルールベースの変換」

- 「カスタム・ルールベースの変換の管理」

- 「カスタム・ルールベースの変換の表示」

誤って変換されたLCRがエラー・キューにないか

場合によっては、誤って変換されたLCRが、適用プロセスによってエラー・キューに移動されていることがあります。このときは、エラー・キューのトランザクションを調べて、トランザクションを正常に再実行できる可能性を分析する必要があります。トランザクションに異常が見つかった場合は、問題を修正するためにプロシージャDMLハンドラを構成することができます。DMLハンドラは、エラー・トランザクションを再実行するときに実行されます。DMLハンドラを使用してエラー・トランザクションの問題を修正する場合は、そのDMLハンドラを使用する適用プロセスを停止して、エラー・トランザクションに関係ないLCRがDMLハンドラによって処理されないようにする必要があります。正常に再実行した後で、DMLハンドラが不要であれば削除します。また、ルールベースの変換を修正して、将来エラーが発生しないようにします。

関連項目:

- 「エラー・キュー」

- 「適用エラーのチェック」

- 「適用エラーの詳細情報の表示」

第VI部

Oracle Streamsの情報のプロビジョニング

この部では、Oracle Streamsを使用した情報のプロビジョニングについて説明します。この部の構成は、次のとおりです。

- 第35章「情報のプロビジョニングの概要」

- 第36章「情報のプロビジョニングの使用」

- 第37章「ファイル・グループおよび表領域リポジトリの監視」

35 情報のプロビジョニングの概要

情報をプロビジョニングすることによって、必要なときに必要な場所で情報を使用できるようになります。情報のプロビジョニングは、Oracleグリッド・コンピューティングの一環として行われ、エンタープライズ・コンピューティングのニーズに応えるために、多数のサーバー、記憶領域およびネットワークを柔軟なオンデマンド・コンピューティング・リソースにプーリングします。情報のプロビジョニングでは、情報の統合で使用される多くの機能が使用されます。

次の各項では、情報のプロビジョニングについて説明します。

- 情報のプロビジョニングの概要

- 大量の情報のバルク・プロビジョニング

- Oracle Streamを使用した情報の増分プロビジョニング

- オンデマンドでの情報へのアクセス

関連項目:

- 第36章「情報のプロビジョニングの使用」

- 情報の統合の詳細は、『Oracle Database概要』を参照

情報のプロビジョニングの概要

Oracleグリッド・コンピューティングでは、Oracle Real Application Clusters(Oracle RAC)、Oracle Scheduler、データベース・リソース・マネージャなどの機能を使用してリソースをプロビジョニングできます。Oracle RACを使用すると、物理サーバーのクラスタ上で単一のOracle Databaseサーバーを実行することによって、ハードウェア・リソースをプロビジョニングできます。Oracle Schedulerを使用すると、長期間のデータベースのワークロードをプロビジョニングして、リソースをより効率的に使用できます。データベース・リソース・マネージャは、Oracle Database内のデータベース・ユーザー、アプリケーションまたはサービスに対してリソースをプロビジョニングします。

Oracleグリッド・コンピューティングでは、リソースのプロビジョニングに加えて、情報のプロビジョニングも行うことができます。現在、情報がグリッド上のどの場所にあるかに関係なく、情報のプロビジョニングによって、必要なときに必要な場所に情報が配信されます。分散システムを含むグリッド環境では、必要な場所で情報が使用可能になるように、グリッドによって情報を効率的に移動またはコピーする必要があります。

情報のプロビジョニングは次の形式で実行できます。

- 大量の情報のバルク・プロビジョニング: データ・ポンプ・エクスポート/インポート、トランスポータブル表領域、DBMS_STREAMS_TABLESPACE_ADMパッケージおよびDBMS_FILE_TRANSFERパッケージは、いずれも大量の情報を提供するために使用できます。データ・ポンプ・エクスポート/インポートを使用すると、データベース・レベル、表領域レベル、スキーマ・レベルまたは表レベルで情報を移動またはコピーできます。トランスポータブル表領域を使用すると、データベース間で表領域を効率的に移動またはコピーできます。DBMS_STREAMS_TABLESPACE_ADMパッケージのプロシージャを使用すると、表領域をクローニング、デタッチおよびアタッチできます。また、このパッケージの一部のプロシージャでは、表領域をバージョニングする表領域リポジトリに表領域を格納できます。表領域が必要になった場合、表領域リポジトリから取リ出してデータベースに割り当てることができます。DBMS_FILE_TRANSFERパッケージのプロシージャを使用すると、データベース内またはデータベース間でバイナリ・ファイルをコピーできます。

- Oracle Streamを使用した情報の増分プロビジョニング: 一部のデータは、時々バルク共有を行うのではなく、作成または変更された時点で共有を行う必要があります。Oracle Streamsは、グリッド内のデータベース、ノードまたはブレード・ファーム間のデータをストリーミングして、複数のコピーを更新が行われるたびに同期化できます。

- オンデマンドでの情報へのアクセス: 情報を新しい場所に移動またはコピーせずに、使用可能にすることができます。Oracleの分散SQLを使用すると、グリッド・ユーザーは、複数のOracle Databaseに格納されたデータ、およびゲートウェイを介してOracle以外のデータベースに格納されたデータにアクセスして、データを統合できます。

このような情報のプロビジョニング機能を個別にまたは組み合せて使用することで、実行している環境で完全な情報のプロビジョニング・ソリューションを使用できます。この章の残りの項では、情報をプロビジョニングする方法の詳細を説明します。

関連項目:

- Oracle RACの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照

- Oracle Schedulerおよびデータベース・リソース・マネージャの詳細は、『Oracle Database管理者ガイド』を参照

大量の情報のバルク・プロビジョニング

Oracleには、データベース間で大量の情報を効率的に移動またはコピーするためのいくつかの方法があります。データ・ポンプを使用すると、データベース・レベル、表領域レベル、スキーマ・レベルまたは表レベルで大量の情報をエクスポートおよびインポートできます。Oracleのデータベース間で表領域セットを移動またはコピーするには、複数の方法があります。トランスポータブル表領域を使用すると、Oracle Databaseのサブセットを移動またはコピーし、別のOracle Databaseに割り当てることができます。RMANを使用したバックアップからのトランスポータブル表領域を使用すると、表領域をオンラインの状態にしたまま、表領域セットを移動またはコピーできます。DBMS_STREAMS_TABLESPACE_ADMパッケージのプロシージャを使用すると、表領域セットの移動またはコピーに必要な複数の手順を組み合せて、1つのプロシージャ・コールにできます。

いずれの方法で表領域セットを移動またはコピーする場合も、表領域セットが自己完結型である必要があります。自己完結型の表領域には、その表領域から表領域の外部を指している参照はありません。たとえば、表領域内の索引が別の表領域内の表に対するものである場合、その表領域は自己完結型ではありません。自己完結型の表領域セットには、その表領域セットの内部から表領域セットの外部を指している参照はありません。たとえば、パーティション表の一部が表領域セットに含まれている場合、その表領域セットは自己完結型ではありません。表領域セットが自己完結型かどうかを判別するには、Oracleが提供するDBMS_TTSパッケージのTRANSPORT_SET_CHECKプロシージャを使用します。

次の各項では、大量の情報を移動またはコピーするためのオプションと、各オプションをどのような場合に使用するかについて説明します。

- データ・ポンプ・エクスポート/インポート

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

- DBMS_STREAMS_TABLESPACE_ADMプロシージャ

- 情報のバルク・プロビジョニングのオプション

データ・ポンプ・エクスポート/インポート

データ・ポンプ・エクスポート/インポートを使用すると、データベース間でデータを効率的に移動またはコピーできます。データ・ポンプでは、データベース全体、表領域、スキーマまたは表のエクスポート/インポートを実行して、大量または少量のデータを特定の要件に合わせてプロビジョニングできます。データ・ポンプでのエクスポートおよびインポートは、コマンドライン・クライアント(expdpおよびimpdp)またはDBMS_DATAPUMPパッケージを使用して実行できます。

トランスポータブル表領域でのエクスポート/インポートは、TRANSPORT_TABLESPACESパラメータで指定します。トランスポータブル表領域を使用すると、データベースから表領域セットを取り出して別の場所に移動またはコピーし、それらを別のデータベースに割り当てることができます。トランスポートは迅速に行われます。これはメタデータおよびファイルがそのプロセスによって転送されるためです。データのアンロードおよびロードは実行されません。トランスポータブル表領域モードでは、指定された表領域セット内の表(およびそれに依存するオブジェクト)のメタデータのみがソース・データベースでアンロードされ、ターゲット・データベースでロードされます。これによって、表領域のデータファイルをターゲットのOracle Databaseにコピーして、効率的に取り込むことができます。

転送する表領域は、ディクショナリ管理表領域またはローカル管理表領域のいずれかになります。トランスポータブル表領域を使用した表領域の移動またはコピーは、同じデータのエクスポート/インポートまたはアンロード/ロードを使用するより高速で実行されます。トランスポータブル表領域を使用するには、EXP_FULL_DATABASEおよびIMP_FULL_DATABASEロールが必要です。転送する表領域は、エクスポート中は読取り専用である必要があります。また、エクスポートでは、並列度を1より大きくすることはできません。

関連項目:

- データ・ポンプの詳細は、『Oracle Databaseユーティリティ』を参照

- TRANSPORT_TABLESPACESオプションを指定したデータ・ポンプの使用方法の詳細は、『Oracle Database管理者ガイド』を参照

RMANを使用したバックアップからのトランスポータブル表領域

Recovery Manager(RMAN)のTRANSPORT TABLESPACEコマンドを実行して表領域をコピーすると、転送処理中に表領域を読取り専用モードにする必要はありません。バックアップからRMANのトランスポータブル表領域を実行するには、適切なデータベース・バックアップが使用可能である必要があります。

関連項目:

- 『Oracle Databaseバックアップおよびリカバリ・リファレンス』

- 『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』

DBMS_STREAMS_TABLESPACE_ADMプロシージャ

DBMS_STREAMS_TABLESPACE_ADMパッケージの次のプロシージャを使用して、表領域を移動またはコピーできます。

- ATTACH_TABLESPACES: DBMS_STREAMS_TABLESPACE_ADMパッケージ、データ・ポンプ・エクスポートまたはRMANのTRANSPORT TABLESPACEコマンドを使用して以前にエクスポートされた自己完結型の表領域セットを、データ・ポンプを使用してインポートします。

- CLONE_TABLESPACES: データ・ポンプ・エクスポートを使用して、自己完結型の表領域セットをクローニングします。表領域セットは、クローニング後にデータベースにアタッチできます。表領域セットは、クローニング元のデータベースに残ります。

- DETACH_TABLESPACES: データ・ポンプ・エクスポートを使用して、自己完結型の表領域セットをデタッチします。表領域セットは、デタッチ後にデータベースにアタッチできます。表領域セットは、デタッチ元のデータベースから削除されます。

- PULL_TABLESPACES: データ・ポンプ・エクスポート/インポートを使用して、リモート・データベースから自己完結型の表領域セットをコピーし、現行のデータベースにアタッチします。

また、DBMS_STREAMS_TABLESPACE_ADMパッケージには、ATTACH_SIMPLE_TABLESPACE、CLONE_SIMPLE_TABLESPACE、DETACH_SIMPLE_TABLESPACEおよびPULL_SIMPLE_TABLESPACEプロシージャも含まれています。これらのプロシージャは、表領域セットではなく1つのデータファイルのみを使用する単一の表領域で実行されます。

ファイル・グループ・リポジトリ

ファイル・グループに関して、ファイルはハード・ディスクに格納されているファイルを示します。ファイルは、ファイル名、ディレクトリ・オブジェクトおよびファイル・タイプで構成されます。ディレクトリ・オブジェクトは、ファイルがハード・ディスク上で格納されているディレクトリです。バージョンは関連ファイルの集合で、ファイル・グループはバージョンの集合です。

ファイル・グループ・リポジトリは、データベース内のすべてのファイル・グループの集合です。ファイル・グループ・リポジトリには、複数のファイル・グループおよび特定のファイル・グループの複数のバージョンを含めることができます。

たとえば、reportsという名前のファイル・グループに、売上レポートの複数のバージョンを格納できます。レポートは定期的なスケジュールで生成でき、各バージョンにはレポート・ファイルを含めることができます。ファイル・グループ・リポジトリでは、ファイル・グループをsales_reports_v1、sales_reports_v2などの名前でバージョニングできます。

ファイル・グループ・リポジトリには、すべてのタイプのファイルを含めることができます。DBMS_FILE_GROUPパッケージを使用すると、ファイル・グループ・リポジトリを作成および管理できます。

関連項目:

- 「ファイル・グループ・リポジトリの使用」

- DBMS_FILE_GROUPパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

表領域リポジトリ

表領域リポジトリは、ファイル・グループ・リポジトリ内の表領域セットの集合です。表領域リポジトリはファイル・グループ・リポジトリ上に構築されますが、表領域リポジトリには、データベース間での表領域の移動またはコピーに必要なファイルのみが含まれます。ファイル・グループ・リポジトリには、表領域セットを含む(ただし、これ以外のファイルも含む)バージョニングされたファイルのセットを格納できます。

表領域リポジトリには、異なる表領域セットを格納できます。また、特定の表領域セットの異なるバージョンも格納できます。表領域リポジトリ内の表領域セットのバージョンは、次のファイルで構成されます。

- 表領域セットに対するデータ・ポンプ・エクスポートのダンプ・ファイル

- エクスポートのデータ・ポンプのログ・ファイル

- 表領域セットを構成するデータファイル

バージョン内のすべてのファイルは、単一のディレクトリまたは複数のディレクトリに格納できます。次のプロシージャを実行すると、表領域リポジトリを使用するかどうかに関係なく、表領域を移動またはコピーできます。

- ATTACH_TABLESPACES

- CLONE_TABLESPACES

- DETACH_TABLESPACES

表領域リポジトリを使用せずにこれらのいずれかのプロシージャを実行した場合、表領域セットを移動またはコピーできますが、表領域リポジトリに格納したり、表領域リポジトリからコピーすることはできません。表領域リポジトリを使用してCLONE_TABLESPACESまたはDETACH_TABLESPACESプロシージャを実行した場合、表領域セットは1つのバージョンとしてリポジトリに格納されます。表領域リポジトリを使用してATTACH_TABLESPACESプロシージャを実行した場合、表領域セットの特定のバージョンがリポジトリからコピーされ、データベースにアタッチされます。

表領域リポジトリを使用する場合

表領域リポジトリは、1つ以上の表領域セットの複数のバージョンを格納する必要がある場合に役立ちます。たとえば、表領域リポジトリを使用すると、次の目標を達成できます。

- 表領域セットに四半期レポートを実行する。バージョニングされた表領域リポジトリに格納するために、四半期ごとに表領域セットをクローニングできます。また、表領域セットの特定のバージョンをリポジトリから要求し、別のデータベースにアタッチしてレポートを実行できます。

- グリッド環境において、アプリケーションで必要な表領域セットをオンデマンドでアタッチできるようにする。表領域リポジトリには、複数の異なる表領域セットの複数のバージョンを格納できます。各表領域セットは、アプリケーションで異なる目的に使用できます。アプリケーションで特定の表領域セットの特定のバージョンが必要な場合、アプリケーションで表領域リポジトリをスキャンして、正しい表領域セットをデータベースにアタッチできます。

表領域リポジトリのプロシージャ間の相違点

DBMS_STREAMS_TABLESPACE_ADMパッケージのfile_group_nameパラメータを含むプロシージャは、表領域セット、表領域セット内のデータファイルおよびエクスポート・ダンプ・ファイルに関して動作が異なります。表35-1に、これらの相違点を示します。

表35-1 表領域リポジトリのプロシージャ

プロシージャ

表領域セット

データファイル

エクスポート・ダンプ・ファイル

ATTACH_TABLESPACES

表領域セットはローカル・データベースに追加されます。

datafiles_directory_objectパラメータがNULL以外の場合、データファイルは表領域リポジトリ内のバージョンの現在の場所から、datafiles_directory_objectパラメータで指定されたディレクトリ・オブジェクトにコピーされます。アタッチされた表領域セットでは、コピーされたデータファイルが使用されます。

datafiles_directory_objectパラメータがNULLの場合、データファイルは移動またはコピーされません。データファイルは表領域リポジトリ内のバージョンのディレクトリ・オブジェクトに残り、アタッチされた表領域セットではこれらのデータファイルが使用されます。

datafiles_directory_objectパラメータがNULL以外の場合、エクスポート・ダンプ・ファイルは表領域リポジトリ内のバージョンのディレクトリ・オブジェクトから、datafiles_directory_objectパラメータで指定されたディレクトリ・オブジェクトにコピーされます。

datafiles_directory_objectパラメータがNULLの場合、エクスポート・ダンプ・ファイルは移動またはコピーされません。

CLONE_TABLESPACES

表領域セットはローカル・データベースに保持されます。

データファイルは、現在の場所からtablespace_directory_objectパラメータで指定されたディレクトリ・オブジェクト、またはそのバージョンまたはファイル・グループのデフォルト・ディレクトリにコピーされます。このパラメータで、表領域セットのバージョンを格納する表領域リポジトリ内の場所を指定します。データファイルの現在の場所を確認するには、DBA_DATA_FILESデータ・ディクショナリ・ビューを問い合せます。各データファイルの場所にディレクトリ・オブジェクトが存在し、プロシージャを実行するユーザーがそれらにアクセスできる必要があります。

エクスポート・ダンプ・ファイルは、tablespace_directory_objectパラメータで指定されたディレクトリ・オブジェクト、またはそのバージョンまたはファイル・グループのデフォルト・ディレクトリに格納されます。

DETACH_TABLESPACES

表領域セットはローカル・データベースから削除されます。

データファイルは移動またはコピーされません。データファイルは現在の場所に残ります。各データファイルの場所にディレクトリ・オブジェクトが存在し、プロシージャを実行するユーザーがそれらにアクセスできる必要があります。これらのデータファイルは、表領域リポジトリに格納された表領域セットのバージョンに含まれます。

エクスポート・ダンプ・ファイルは、export_directory_objectパラメータで指定されたディレクトリ・オブジェクト、またはそのバージョンまたはファイル・グループのデフォルト・ディレクトリに格納されます。

表領域リポジトリへのリモート・アクセス

表領域リポジトリは、表領域を使用するデータベース、またはリモート・データベースに構築できます。表領域リポジトリがリモート・データベースに存在する場合、いずれかのプロシージャの実行時に、プロシージャを実行するユーザーがアクセス可能なデータベース・リンクをrepository_db_linkパラメータに指定する必要があります。

1つのデータベースでオンラインにできるのは1つの表領域バージョンのみ

表領域リポジトリ内の表領域セットのバージョンは、データベースでオンラインまたはオフラインのいずれかにできます。ATTACH_TABLESPACESプロシージャを使用して表領域セットのバージョンをデータベースにアタッチした場合、その表領域セットのバージョンはデータベースでオンラインになります。特定の時点のデータベースでオンラインにできるのは、表領域セットの1つのバージョンのみです。ただし、様々なデータベースで表領域セットの同じバージョンまたは異なるバージョンを同時にオンラインにすることができます。この場合、1つのデータベースのみが表領域セットを変更できるようにする必要がある場合があります。

表領域リポジトリのプロシージャによる自動的なDBMS_FILE_GROUPパッケージの使用

表領域リポジトリはファイル・グループ・リポジトリ上に構築されますが、DBMS_STREAMS_TABLESPACE_ADMパッケージのいずれかのプロシージャを使用する前にDBMS_FILE_GROUPパッケージを使用してファイル・グループ・リポジトリを作成する必要はありません。存在しないファイル・グループを指定してCLONE_TABLESPACESまたはDETACH_TABLESPACESプロシージャを実行した場合、そのファイル・グループが自動的に作成されます。

バージョニングは行われるがソースの制御は行われない表領域リポジトリ

表領域リポジトリでは、表領域セットのバージョニングは行われますが、ソースの制御は行われません。複数のバージョンの表領域セットが同時に変更され、1つの表領域リポジトリに格納された場合、これらの変更はマージされません。

エクスポート中に表領域が読取り専用である必要性

データ・ポンプ・エクスポートを実行するDBMS_STREAMS_TABLESPACE_ADMパッケージのプロシージャを実行すると、エクスポートするすべての読取り/書込み可能表領域は、読取り専用になります。DBMS_STREAMS_TABLESPACE_ADMパッケージのプロシージャによって表領域が読取り専用にされた場合、エクスポートの完了後、その表領域は読取り/書込み可能になります。

表領域のプラットフォームの自動変換

DBMS_STREAMS_TABLESPACE_ADMパッケージのいずれかのプロシージャを使用して、異なるプラットフォーム上で実行されているデータベースに表領域を移動またはコピーする際、変換がサポートされている場合は、データファイルを適切なプラットフォームに変換できます。V$TRANSPORTABLE_PLATFORM動的パフォーマンス・ビューに、クロス・プラットフォームのトランスポータブル表領域をサポートするすべてのプラットフォームのリストが表示されます。

表領域リポジトリを使用すると、プラットフォームの変換は自動的に実行されます(サポートされている場合)。表領域リポジトリを使用しない場合、表領域の変換先または変換元のプラットフォームを指定する必要があります。

関連項目:

- DBMS_STREAMS_TABLESPACE_ADMパッケージのプロシージャの使用方法と使用例については、第36章「情報のプロビジョニングの使用」を参照

- DBMS_STREAMS_TABLESPACE_ADMパッケージおよびDBMS_FILE_GROUPパッケージのリファレンス情報は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

情報のバルク・プロビジョニングのオプション

表35-2に、情報のバルク・プロビジョニングの各オプションを使用する場合を示します。

表35-2 表領域の移動またはコピーのオプション

オプション

このオプションを使用する状況

データ・ポンプ・エクスポート/インポート

- データベース・レベル、表領域レベル、スキーマ・レベルまたは表レベルでデータを移動またはコピーする場合。

- データ・ポンプ・エクスポート/インポートの完了に必要な各手順を実行する場合。

TRANSPORT_TABLESPACESオプションを指定したデータ・ポンプ・エクスポート/インポート

- 移動またはコピーする表領域を、操作中に読取り専用にできる場合。

- データ・ポンプ・エクスポート/インポートの完了に必要な各手順を実行する場合。

RMANのTRANSPORT TABLESPACEコマンドを使用したバックアップからのトランスポータブル表領域

移動またはコピーする表領域を、操作中にオンライン(書込み可能)のままにする必要がある場合。

表領域リポジトリを使用せずに実行するDBMS_STREAMS_TABLESPACE_ADMプロシージャ

- 移動またはコピーする表領域を、操作中に読取り専用にできる場合。

- データ・ポンプ・エクスポート/インポートの複数の手順を組み合せて1つのプロシージャ・コールにする場合。

- 移動またはコピーする表領域に対して表領域リポジトリを使用しない場合。

表領域リポジトリを使用して実行するDBMS_STREAMS_TABLESPACE_ADMプロシージャ

- 移動またはコピーする表領域を、操作中に読取り専用にできる場合。

- データ・ポンプ・エクスポート/インポートの複数の手順を組み合せて1つのプロシージャ・コールにする場合。

- 移動またはコピーする表領域に対して表領域リポジトリを使用する場合。

- プラットフォームの変換を自動的に実行する場合。

Oracle Streamを使用した情報の増分プロビジョニング

Oracle Streamsは、異なるデータベース内のデータベース・オブジェクトを次の各レベルで共有および保持できます。

- データベース

- スキーマ

- 表

- 表サブセット

Oracle Streamsは、複数のデータベースでの共有データベース・オブジェクトの同期化を保持できます。具体的には、Oracle Streamsの取得プロセスまたは同期取得で ソース・データベースの共有データベース・オブジェクトに対する変更を取得し、1つ以上の伝播でその変更を別のデータベースに伝播し、適用プロセスでその変更を共有データベース・オブジェクトに適用します。データベース・オブジェクトが異なるデータベースで共通でない場合、Oracle Streamsでは、プロセスの任意の時点でそれらのオブジェクトを変換できます。つまり、取得中、伝播中または適用中に変更を変換できます。また、Oracle Streamsでは、適用ハンドラを使用した変更の適用中に、変更のカスタム処理を実行できます。データベース・オブジェクトはOracle Database間で共有するか、またはOracle Database Gatewayを使用してOracle DatabaseとOracle以外のデータベース間で共有できます。Oracle Streamsでは、データのレプリケーションに加えて、メッセージ機能、イベントの管理と通知およびデータ・ウェアハウスのロードが提供されます。

Oracle Streamsとバルク・プロビジョニングを組み合せると、単一のプロシージャを実行することによって大量のデータをコピーおよび保持できます。DBMS_STREAMS_ADMパッケージの次のプロシージャを使用すると、データ・ポンプを使用してデータベース間でデータをコピーし、コピーされたデータを段階的に保持するように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を使用してこれらの表領域を両方のデータベースで保持します。

また、PRE_INSTANTIATION_SETUPおよびPOST_INSTANTIATION_SETUPプロシージャでは、2つのデータベース間で、データベース・レベルでの変更、または指定された表領域に対する変更をレプリケートするOracle Streams環境を構成します。これらのプロシージャは一緒に使用する必要があります。また、Oracle Streamsレプリケーションの構成を完了するために、インスタンス化のアクションを手動で実行する必要があります。

これらのプロシージャを使用すると、1つのデータベースからデータをエクスポートして別のデータベースに移動し、移動先のデータベースが異なるプラットフォーム上にある場合は、データを再フォーマットして移動先のデータベースにインポートし、元のデータベースで変更が発生した場合にデータの同期化を開始できます。移動先のデータベースがグリッド上にある場合、1つのコマンドでアプリケーションをグリッドに移行できます。

これらのプロシージャを使用すると、単一ソース・レプリケーション環境においてソース・データベースで発生した変更を保持するか、または双方向レプリケーション環境において両方のデータベースで発生した変更を保持するようにOracle Streamsクライアントを構成できます。データの変更を保持することによって、両方のデータベースでのデータの同期化を保持できます。これらのプロシージャでは、これらのアクションを直接実行するか、またはこれらのアクションを実行する1つ以上のスクリプトを生成できます。

関連項目:

- 第1章「Oracle Streamsの概要」

- DBMS_STREAMS_ADMパッケージのリファレンス情報は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

- DBMS_STREAMS_ADMパッケージについては、『Oracle Streamsレプリケーション管理者ガイド』を参照

オンデマンドでの情報へのアクセス

ユーザーおよびアプリケーションは、情報を新しい場所に移動またはコピーしなくても、情報にアクセスできます。分散SQLを使用すると、グリッド・ユーザーは、複数のOracle Databaseに格納されたデータ、およびOracle Database Gatewayを介してOracle以外のデータベースに格納されたデータにアクセスし、データを統合できます。分散SQLを使用した透過的なリモート・データ・アクセスによって、グリッド・ユーザーは、アプリケーションのコードを変更しなくても、他のデータベースに対してアプリケーションを実行できます。複数のデータ・ストアにまたがるデータの統合やトランザクションを管理する一方で、Oracle Databaseによって、最も効率的な方法でデータにアクセスできるように実行計画が最適化されます。

関連項目:

- 分散SQLの詳細は、『Oracle Database管理者ガイド』を参照

- Oracle Database Gatewayの詳細は、『Oracle Database Heterogeneous Connectivity管理者ガイド』を参照

36 情報のプロビジョニングの使用

この章では、情報のプロビジョニングの使用方法について説明します。この章では、表領域リポジトリの作成例、データベース間での表領域の転送例、およびファイル・グループ・リポジトリを使用した異なるバージョンのファイルの格納例を示します。

次の各項では、情報のプロビジョニングの使用について説明します。

- 表領域リポジトリの使用

- ファイル・グループ・リポジトリの使用

関連項目:
第35章「情報のプロビジョニングの概要」

表領域リポジトリの使用

DBMS_STREAMS_TABLESPACE_ADMパッケージの次のプロシージャを使用すると、表領域リポジトリの作成、表領域リポジトリに対するバージョニングされた表領域セットの追加、および表領域リポジトリからのバージョニングされた表領域セットのコピーを実行できます。

- ATTACH_TABLESPACES: 表領域リポジトリから表領域セットのバージョンをコピーし、データベースに表領域をアタッチします。

- CLONE_TABLESPACES: データベースから表領域セットをコピーして、表領域リポジトリに新しいバージョンの表領域セットを追加します。表領域セット内の表領域は、コピー元のデータベースの一部として残ります。

- DETACH_TABLESPACES: 表領域セットをデータベースからリポジトリに移動して、表領域リポジトリに新しいバージョンの表領域セットを追加します。表領域セット内の表領域は、コピー元のデータベースから削除されます。

この項では、表領域リポジトリの使用方法を例とともに説明します。この例での目標は、sales表領域(sales_tbs1およびsales_tbs2)に四半期レポートを実行することです。売上は、inst1.example.comデータベース内のこれらの表領域に記録されます。この例では、四半期ごとに表領域をクローニングし、表領域リポジトリに新しいバージョンの表領域を格納します。表領域リポジトリは、inst1.example.comデータベースにも存在します。レポート・データベースでレポートを実行するために表領域セットの特定のバージョンが必要な場合、そのバージョンが表領域リポジトリからコピーされ、レポート・データベースにアタッチされます。

この例では、次のデータベースがレポート・データベースです。

- レポート・データベースinst2.example.com: inst1.example.comデータベースとファイル･システムを共有します。また、inst2.example.comで実行されるレポートによって表領域が変更される場合があります。そのため、表領域はinst2.example.comで読取り/書込み可能になり、レポートの完了時に、新しいバージョンの表領域ファイルが、元のバージョンの表領域ファイルとは別のディレクトリに格納されます。

- レポート・システムinst3.example.com: inst1.example.comデータベースとファイル･システムを共有しません。inst3.example.comで実行されるレポートによって表領域が変更されることはありません。そのため、表領域はinst3.example.comで読取り専用のままになり、レポートの完了時に、元のバージョンの表領域ファイルが単一のディレクトリ内に残ります。

次の各項では、表領域リポジトリを作成および移入する方法、および表領域リポジトリを使用して他のデータベースでレポートを実行する方法について説明します。

- 表領域リポジトリの作成および移入

- 共有ファイル・システムを使用したリモート・レポートに対する表領域リポジトリの使用

- 共有ファイル・システムを使用しないリモート・レポートに対する表領域リポジトリの使用

これらの例は、前述のプロシージャを実行するために必要な権限を持つ管理ユーザーが実行する必要があります。

関連項目:
これらのプロシージャおよびそれらの実行に必要な権限の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

表領域リポジトリの作成および移入

この例では、表領域リポジトリを作成し、表領域セットの新しいバージョンを各四半期後にリポジトリに追加します。表領域セットは、企業のsales表領域(sales_tbs1およびsales_tbs2)で構成されています。

図36-1に、この例で作成される表領域リポジトリの概要を示します。

図36-1 表領域リポジトリの例

次の表に、この例で作成される表領域セットのバージョン、それらのディレクトリ・オブジェクト、および各ディレクトリ・オブジェクトの対応するファイル・システム・ディレクトリを示します。

バージョン

ディレクトリ・オブジェクト

対応するファイル・システム・ディレクトリ

v_q1fy2005

q1fy2005

/home/sales/q1fy2005

v_q2fy2005

q2fy2005

/home/sales/q2fy2005

この例では、次のことを想定しています。

- inst1.example.comデータベースが存在しています。

- inst1.example.comデータベース内にsales_tbs1およびsales_tbs2表領域が存在しています。

表領域リポジトリを作成および移入するには、次の手順を実行します。

1. sales表領域が新しい売上データで変更されたデータベースに、管理ユーザーとして接続します。この例では、inst1.example.comデータベースに接続します。
管理ユーザーは、DBMS_STREAMS_TABLESPACE_ADMパッケージのプロシージャの実行およびディレクトリ・オブジェクトの作成に必要な権限を持っている必要があります。

SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

2. inst1.example.comで、 2005年度の第1四半期用のディレクトリ・オブジェクトを作成します。

CREATE OR REPLACE DIRECTORY q1fy2005 AS '/home/sales/q1fy2005';

ディレクトリ・オブジェクトの作成時に、指定したファイル・システム・ディレクトリが存在している必要があります。

3. inst1.example.comデータベース内の表領域のデータファイルを含むディレクトリに対応するディレクトリ・オブジェクトを作成します。たとえば、表領域のデータファイルが/orc/inst1/dbsディレクトリに存在する場合は、このディレクトリに対応するディレクトリ・オブジェクトを作成します。

CREATE OR REPLACE DIRECTORY dbfiles_inst1 AS '/orc/inst1/dbs';

4. 表領域セットをクローニングし、表領域セットの最初のバージョンを表領域リポジトリに追加します。

DECLARE
tbs_set DBMS_STREAMS_TABLESPACE_ADM.TABLESPACE_SET;
BEGIN
tbs_set(1) := 'sales_tbs1';
tbs_set(2) := 'sales_tbs2';
DBMS_STREAMS_TABLESPACE_ADM.CLONE_TABLESPACES(
tablespace_names            => tbs_set,
tablespace_directory_object => 'q1fy2005',
file_group_name             => 'strmadmin.sales',
version_name                => 'v_q1fy2005');
END;
/

salesファイル・グループが存在しない場合は、自動的に作成されます。

5. 2005年度の第2四半期の終了時に、2005年度の第2四半期用のディレクトリ・オブジェクトを作成します。

CREATE OR REPLACE DIRECTORY q2fy2005 AS '/home/sales/q2fy2005';

ディレクトリ・オブジェクトの作成時に、指定したファイル・システム・ディレクトリが存在している必要があります。

6. 表領域セットをクローニングし、inst1.example.comデータベースで次のバージョンの表領域セットを表領域リポジトリに追加します。

DECLARE
tbs_set DBMS_STREAMS_TABLESPACE_ADM.TABLESPACE_SET;
BEGIN
tbs_set(1) := 'sales_tbs1';
tbs_set(2) := 'sales_tbs2';
DBMS_STREAMS_TABLESPACE_ADM.CLONE_TABLESPACES(
tablespace_names            => tbs_set,
tablespace_directory_object => 'q2fy2005',
file_group_name             => 'strmadmin.sales',
version_name                => 'v_q2fy2005');
END;
/

各四半期の終了時に手順5と6を繰り返して、四半期ごとに表領域セットのバージョンを格納できます。その際、四半期ごとの表領域ファイルを格納するためにディレクトリ・オブジェクトを作成し、その四半期に対して一意のバージョン名を指定します。

共有ファイル・システムを使用したリモート・レポートに対する表領域リポジトリの使用

この例では、inst2.example.comで、inst1.example.comの表領域リポジトリに格納されたsales表領域の特定のバージョンに対してレポートを実行します。これらの2つのデータベースは1つのファイル・システムを共有するため、inst2.example.comで実行されるレポートによって表領域が変更される場合があります。そのため、表領域はinst2.example.comで読取り/書込み可能になります。レポートの完了時、表領域ファイルの新しいバージョンは、表領域ファイルの元のバージョンとは別のディレクトリに格納されます。

図36-2に、この例で表領域リポジトリ内の表領域を異なるデータベースにアタッチする方法の概要を示します。

図36-2 共有ファイル・システムを使用した表領域のアタッチ

図36-3に、この例で表領域リポジトリ内に表領域をデタッチおよび配置する方法の概要を示します。

図36-3 共有ファイル・システムを使用した表領域のデタッチ

次の表に、この例の完了時の表領域リポジトリ内の表領域セットのバージョンを示します。この表には、各バージョンのディレクトリ・オブジェクトおよび各ディレクトリ・オブジェクトの対応するファイル・システム・ディレクトリを示します。この例では新しいバージョンが作成されます。この例より前に存在していたバージョンは「表領域リポジトリの作成および移入」で作成されたものです。

バージョン

ディレクトリ・オブジェクト

対応するファイル・システム・ディレクトリ

新しいバージョンかどうか

v_q1fy2005

q1fy2005

/home/sales/q1fy2005

いいえ

v_q1fy2005_r

q1fy2005_r

/home/sales/q1fy2005_r

はい

v_q2fy2005

q2fy2005

/home/sales/q2fy2005

いいえ

v_q2fy2005_r

q2fy2005_r

/home/sales/q2fy2005_r

はい

この例では、次のことを想定しています。

- inst1.example.comおよびinst2.example.comデータベースが存在しています。

- inst1.example.comおよびinst2.example.comデータベースは共有ファイル・システムにアクセスできます。

- これらのデータベースが相互に通信できるように、ネットワークがデータベース間で構成されています。

- 様々な四半期用のsales表領域(sales_tbs1およびsales_tbs2)のバージョンを含む表領域リポジトリは、inst1.example.comデータベースに存在しています。この表領域リポジトリは、「表領域リポジトリの作成および移入」の例で作成および移入されたものです。

次の手順を実行します。

1. SQL*Plusで、inst1.example.comに管理ユーザーとして接続します。
管理ユーザーは、ディレクトリ・オブジェクトの作成に必要な権限を持っている必要があります。

SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

2. inst2.example.comデータベースで 2005年度の第1四半期のレポートを完了した後、inst1.example.comでこの四半期用の表領域ファイルを格納するディレクトリ・オブジェクトを作成します。

CREATE OR REPLACE DIRECTORY q1fy2005_r AS '/home/sales/q1fy2005_r';

ディレクトリ・オブジェクトの作成時に、指定したファイル・システム・ディレクトリが存在している必要があります。

3. inst2.example.comデータベースに管理ユーザーとして接続します。
管理ユーザーは、DBMS_STREAMS_TABLESPACE_ADMパッケージでのプロシージャの実行、ディレクトリ・オブジェクトの作成およびデータベース・リンクの作成に必要な権限を持っている必要があります。

4. inst2.example.comで、 2005年度の第1四半期用のディレクトリ・オブジェクトを2つ作成します。これらのディレクトリ・オブジェクトは、inst1.example.comデータベース内の表領域リポジトリによって使用される第1四半期用のディレクトリ・オブジェクトと同じ名前を持ち、共有ファイル・システム上の同じディレクトリに対応する必要があります。

CREATE OR REPLACE DIRECTORY q1fy2005 AS '/home/sales/q1fy2005';

CREATE OR REPLACE DIRECTORY q1fy2005_r AS '/home/sales/q1fy2005_r';

5. inst2.example.comからinst1.example.comデータベースへのデータベース・リンクを作成します。次に例を示します。

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

6. inst1.example.comデータベース内のstrmadmin.salesファイル・グループから、表領域セットをinst2.example.comデータベースにアタッチします。

DECLARE
tbs_set DBMS_STREAMS_TABLESPACE_ADM.TABLESPACE_SET;
BEGIN
DBMS_STREAMS_TABLESPACE_ADM.ATTACH_TABLESPACES(
file_group_name            => 'strmadmin.sales',
version_name               => 'v_q1fy2005',
datafiles_directory_object => 'q1fy2005_r',
repository_db_link         => 'inst1.example.com',
tablespace_names           => tbs_set);
END;
/

datafiles_directory_objectパラメータにq1fy2005_rが指定されていることに注意してください。したがって、表領域のデータファイルおよびエクスポート・ダンプ・ファイルは、プロシージャによって/home/sales/q1fy2005ディレクトリから/home/sales/q1fy2005_rディレクトリにコピーされます。inst2.example.comデータベース内のアタッチされた表領域は、/home/sales/q1fy2005_rディレクトリ内のデータファイルを使用します。データ・ポンプのインポート・ログ・ファイルもこのディレクトリに格納されます。

アタッチされた表領域は、/home/sales/q1fy2005_rディレクトリ内のデータファイルを使用します。ただし、表領域リポジトリ内の表領域のv_q1fy2005バージョンは、元の/home/sales/q1fy2005ディレクトリ内のファイルによって構成されています。

7. 表領域をinst2.example.comで読取り/書込み可能にします。

ALTER TABLESPACE sales_tbs1 READ WRITE;

ALTER TABLESPACE sales_tbs2 READ WRITE;

8. inst2.example.comデータベースで、sales表領域内のデータにレポートを実行します。レポートによって表領域が変更されます。

9. 2005年度の第1四半期用の表領域セットのバージョンを、inst2.example.comデータベースからデタッチします。

DECLARE
tbs_set  DBMS_STREAMS_TABLESPACE_ADM.TABLESPACE_SET;
BEGIN
tbs_set(1) := 'sales_tbs1';
tbs_set(2) := 'sales_tbs2';
DBMS_STREAMS_TABLESPACE_ADM.DETACH_TABLESPACES(
tablespace_names        => tbs_set,
export_directory_object => 'q1fy2005_r',
file_group_name         => 'strmadmin.sales',
version_name            => 'v_q1fy2005_r',
repository_db_link      => 'inst1.example.com');
END;
/

一度にデータベースにアタッチできるのは、1つのバージョンの表領域セットのみです。そのため、2005年度の第1四半期用のsales表領域のバージョンをinst2.example.comからデタッチしてから、 2005年度の第2四半期用のこの表領域セットのバージョンをアタッチする必要があります。

また、export_directory_objectにq1fy2005_rが指定され、version_nameがv_q1fy2005_rであることに注意してください。デタッチ操作後、inst1.example.comの表領域リポジトリ内に、2005年度の第1四半期用の表領域ファイルのバージョンが2つ(1つはレポート前の表領域のバージョン、もう1つはレポート後のバージョン)格納されます。これらの2つのバージョンは異なるバージョン名を持ち、異なるディレクトリ・オブジェクトに格納されます。

10. inst1.example.comデータベースに管理ユーザーとして接続します。

11. inst2.example.comデータベースで 2005年度の第2四半期のレポートを完了した後、inst1.example.comでこの四半期用の表領域ファイルを格納するディレクトリ・オブジェクトを作成します。

CREATE OR REPLACE DIRECTORY q2fy2005_r AS '/home/sales/q2fy2005_r';

ディレクトリ・オブジェクトの作成時に、指定したファイル・システム・ディレクトリが存在している必要があります。

12. inst2.example.comデータベースに管理ユーザーとして接続します。

13. inst2.example.comで、2005年度の第2四半期用のディレクトリ・オブジェクトを2つ作成します。これらのディレクトリ・オブジェクトは、inst1.example.comデータベース内の表領域リポジトリによって使用される第2四半期用のディレクトリ・オブジェクトと同じ名前を持ち、共有ファイル・システム上の同じディレクトリに対応する必要があります。

CREATE OR REPLACE DIRECTORY q2fy2005 AS '/home/sales/q2fy2005';

CREATE OR REPLACE DIRECTORY q2fy2005_r AS '/home/sales/q2fy2005_r';

14. inst1.example.comデータベース内のsalesファイル・グループから、 2005年度の第2四半期用の表領域セットをinst2.example.comデータベースにアタッチします。

DECLARE
tbs_set DBMS_STREAMS_TABLESPACE_ADM.TABLESPACE_SET;
BEGIN
DBMS_STREAMS_TABLESPACE_ADM.ATTACH_TABLESPACES(
file_group_name            => 'strmadmin.sales',
version_name               => 'v_q2fy2005',
datafiles_directory_object => 'q2fy2005_r',
repository_db_link         => 'inst1.example.com',
tablespace_names           => tbs_set);
END;
/

15. 表領域をinst2.example.comで読取り/書込み可能にします。

ALTER TABLESPACE sales_tbs1 READ WRITE;

ALTER TABLESPACE sales_tbs2 READ WRITE;

16. inst2.example.comデータベースで、sales表領域内のデータにレポートを実行します。レポートによって表領域が変更されます。

17. 2005年度の第2四半期用の表領域セットのバージョンを、inst2.example.comからデタッチします。

DECLARE
tbs_set  DBMS_STREAMS_TABLESPACE_ADM.TABLESPACE_SET;
BEGIN
tbs_set(1) := 'sales_tbs1';
tbs_set(2) := 'sales_tbs2';
DBMS_STREAMS_TABLESPACE_ADM.DETACH_TABLESPACES(
tablespace_names        => tbs_set,
export_directory_object => 'q2fy2005_r',
file_group_name         => 'strmadmin.sales',
version_name            => 'v_q2fy2005_r',
repository_db_link      => 'inst1.example.com');
END;
/

各四半期の終了時に手順11から17を繰り返して、各四半期のレポートを実行できます。

共有ファイル・システムを使用しないリモート・レポートに対する表領域リポジトリの使用

この例では、inst3.example.comで、inst1.example.comの表領域リポジトリに格納されたsales表領域の特定のバージョンに対してレポートを実行します。これらの2つのデータベースは1つのファイル・システムを共有しないため、inst3.example.comで実行されるレポートによって表領域は変更されません。そのため、表領域はinst3.example.comで読取り専用のままになり、レポートの完了時に、inst1.example.comの表領域リポジトリに新しいバージョンの表領域ファイルは必要ありません。

図36-4に、この例で表領域リポジトリ内の表領域を異なるデータベースにアタッチする方法の概要を示します。

図36-4 共有ファイル・システムを使用しない表領域のアタッチ

次の表に、この例で使用されるディレクトリ・オブジェクトを示します。この表には、inst1.example.comデータベースの表領域リポジトリのバージョンに関連付けられた既存のディレクトリ・オブジェクト、およびこの例でinst3.example.comデータベースに作成された新しいディレクトリ・オブジェクトを示します。この例より前に存在していたディレクトリ・オブジェクトは「表領域リポジトリの作成および移入」で作成されたものです。

ディレクトリ・オブジェクト

データベース

バージョン

対応するファイル・システム・ディレクトリ

新しいバージョンかどうか

q1fy2005

inst1.example.com

v_q1fy2005

/home/sales/q1fy2005

いいえ

q2fy2005

inst1.example.com

v_q2fy2005

/home/sales/q2fy2005

いいえ

q1fy2005

inst3.example.com

表領域リポジトリのバージョンには関連付けられていない

/usr/sales_data/fy2005q1

はい

q2fy2005

inst3.example.com

表領域リポジトリのバージョンには関連付けられていない

/usr/sales_data/fy2005q2

はい

この例では、次のことを想定しています。

- inst1.example.comおよびinst3.example.comデータベースが存在しています。

- inst1.example.comおよびinst3.example.comデータベースはファイル・システムを共有しません。

- データベースが相互に通信できるように、ネットワークがデータベース間で構成されています。

- inst1.example.comデータベース内にsales表領域(sales_tbs1およびsales_tbs2)が存在しています。

次の手順を実行します。

1. SQL*Plusで、inst3.example.comデータベースに管理ユーザーとして接続します。
管理ユーザーは、DBMS_STREAMS_TABLESPACE_ADMパッケージでのプロシージャの実行、ディレクトリ・オブジェクトの作成およびデータベース・リンクの作成に必要な権限を持っている必要があります。

SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

2. inst3.example.comからinst1.example.comデータベースへのデータベース・リンクを作成します。次に例を示します。

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

3. inst3.example.comで、 2005年度の第1四半期用のディレクトリ・オブジェクトを作成します。inst3.example.comは、inst1.example.comとファイル・システムを共有しないリモート・データベースであるにもかかわらず、ディレクトリ・オブジェクトは、inst1.example.comデータベース内の表領域リポジトリによって使用される第1四半期用のディレクトリ・オブジェクトと同じ名前を持つ必要があります。ただし、inst1.example.comとinst3.example.com上のディレクトリ・オブジェクトのディレクトリ・パスが一致する必要はありません。

CREATE OR REPLACE DIRECTORY q1fy2005 AS '/usr/sales_data/fy2005q1';

ディレクトリ・オブジェクトの作成時に、指定したファイル・システム・ディレクトリが存在している必要があります。

4. inst1.example.comデータベースに管理ユーザーとして接続します。
管理ユーザーは、DBMS_FILE_TRANSFERパッケージのプロシージャの実行およびデータベース・リンクの作成に必要な権限を持っている必要があります。この例では、DBMS_FILE_TRANSFERパッケージを使用して、表領域ファイルをinst1.example.comからinst3.example.comにコピーします。その他の方法を使用してファイルを転送した場合、DBMS_FILE_TRANSFERパッケージのプロシージャを実行するための権限は必要ありません。

5. inst1.example.comからinst3.example.comデータベースへのデータベース・リンクを作成します。次に例を示します。

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

このデータベース・リンクは、手順6でinst3.example.comデータベースへのファイルの転送に使用されます。

6. 第1四半期用の各表領域のデータファイルおよびエクスポート・ダンプ・ファイルをinst3.example.comデータベースにコピーします。

BEGIN
DBMS_FILE_TRANSFER.PUT_FILE(
source_directory_object      => 'q1fy2005',
source_file_name             => 'sales_tbs1.dbf',
destination_directory_object => 'q1fy2005',
destination_file_name        => 'sales_tbs1.dbf',
destination_database         => 'inst3.example.com');
DBMS_FILE_TRANSFER.PUT_FILE(
source_directory_object      => 'q1fy2005',
source_file_name             => 'sales_tbs2.dbf',
destination_directory_object => 'q1fy2005',
destination_file_name        => 'sales_tbs2.dbf',
destination_database         => 'inst3.example.com');
DBMS_FILE_TRANSFER.PUT_FILE(
source_directory_object      => 'q1fy2005',
source_file_name             => 'expdat16.dmp',
destination_directory_object => 'q1fy2005',
destination_file_name        => 'expdat16.dmp',
destination_database         => 'inst3.example.com');
END;
/

エクスポート・ダンプ・ファイルにPUT_FILEプロシージャを実行する前に、DBA_FILE_GROUP_FILESデータ・ディクショナリ・ビューを問い合せて、エクスポート・ダンプ・ファイルの名前およびディレクトリ・オブジェクトを確認できます。たとえば、v_q1fy2005バージョン内のエクスポート・ダンプ・ファイルの情報を表示するには、次の問合せを実行します。

COLUMN FILE_NAME HEADING 'Export Dump|File Name' FORMAT A35
COLUMN FILE_DIRECTORY HEADING 'Directory Object' FORMAT A35

SELECT FILE_NAME, FILE_DIRECTORY FROM DBA_FILE_GROUP_FILES
where FILE_GROUP_NAME = 'SALES' AND
VERSION_NAME    = 'V_Q1FY2005';

7. inst3.example.comデータベースに管理ユーザーとして接続します。

8. inst1.example.comデータベース内のsalesファイル・グループから、 2005年度の第1四半期用の表領域セットをinst3.example.comデータベースにアタッチします。

DECLARE
tbs_set DBMS_STREAMS_TABLESPACE_ADM.TABLESPACE_SET;
BEGIN
DBMS_STREAMS_TABLESPACE_ADM.ATTACH_TABLESPACES(
file_group_name            => 'strmadmin.sales',
version_name               => 'v_q1fy2005',
datafiles_directory_object => 'q1fy2005',
repository_db_link         => 'inst1.example.com',
tablespace_names           => tbs_set);
END;
/

表領域は、アタッチ時に読取り専用になります。inst3.example.comへのレポートでは表領域が変更されないため、表領域は読取り専用のままになります。

9. inst3.example.comデータベースで、sales表領域内のデータにレポートを実行します。

10. 表領域およびその内容をinst3.example.comで削除します。

DROP TABLESPACE sales_tbs1 INCLUDING CONTENTS;

DROP TABLESPACE sales_tbs2 INCLUDING CONTENTS;

表領域がinst3.example.comデータベースから削除されても、表領域ファイルはディレクトリ・オブジェクトに残ったままです。

11. inst3.example.comで、 2005年度の第2四半期用のディレクトリ・オブジェクトを作成します。ディレクトリ・オブジェクトは、inst1.example.comデータベース内の表領域リポジトリによって使用されている第2四半期用のディレクトリ・オブジェクトと同じ名前を持つ必要があります。ただし、inst1.example.comとinst3.example.com上のディレクトリ・オブジェクトのディレクトリ・パスが一致する必要はありません。

CREATE OR REPLACE DIRECTORY q2fy2005 AS '/usr/sales_data/fy2005q2';

ディレクトリ・オブジェクトの作成時に、指定したファイル・システム・ディレクトリが存在している必要があります。

12. inst1.example.comデータベースに管理ユーザーとして接続します。

13. 第2四半期用のデータファイルおよびエクスポート・ダンプ・ファイルをinst3.example.comデータベースにコピーします。

BEGIN
DBMS_FILE_TRANSFER.PUT_FILE(
source_directory_object      => 'q2fy2005',
source_file_name             => 'sales_tbs1.dbf',
destination_directory_object => 'q2fy2005',
destination_file_name        => 'sales_tbs1.dbf',
destination_database         => 'inst3.example.com');
DBMS_FILE_TRANSFER.PUT_FILE(
source_directory_object      => 'q2fy2005',
source_file_name             => 'sales_tbs2.dbf',
destination_directory_object => 'q2fy2005',
destination_file_name        => 'sales_tbs2.dbf',
destination_database         => 'inst3.example.com');
DBMS_FILE_TRANSFER.PUT_FILE(
source_directory_object      => 'q2fy2005',
source_file_name             => 'expdat18.dmp',
destination_directory_object => 'q2fy2005',
destination_file_name        => 'expdat18.dmp',
destination_database         => 'inst3.example.com');
END;
/

エクスポート・ダンプ・ファイルにPUT_FILEプロシージャを実行する前に、DBA_FILE_GROUP_FILESデータ・ディクショナリ・ビューを問い合せて、エクスポート・ダンプ・ファイルの名前およびディレクトリ・オブジェクトを確認できます。たとえば、v_q2fy2005バージョン内のエクスポート・ダンプ・ファイルの情報を表示するには、次の問合せを実行します。

COLUMN FILE_NAME HEADING 'Export Dump|File Name' FORMAT A35
COLUMN FILE_DIRECTORY HEADING 'Directory Object' FORMAT A35

SELECT FILE_NAME, FILE_DIRECTORY FROM DBA_FILE_GROUP_FILES
where FILE_GROUP_NAME = 'SALES' AND
VERSION_NAME    = 'V_Q2FY2005';

14. inst3.example.comデータベースに管理ユーザーとして接続します。

15. inst1.example.comデータベース内のsalesファイル・グループから、 2005年度の第2四半期用の表領域セットをinst3.example.comデータベースにアタッチします。

DECLARE
tbs_set DBMS_STREAMS_TABLESPACE_ADM.TABLESPACE_SET;
BEGIN
DBMS_STREAMS_TABLESPACE_ADM.ATTACH_TABLESPACES(
file_group_name            => 'strmadmin.sales',
version_name               => 'v_q2fy2005',
datafiles_directory_object => 'q2fy2005',
repository_db_link         => 'inst1.example.com',
tablespace_names           => tbs_set);
END;
/

表領域は、アタッチ時に読取り専用になります。inst3.example.comへのレポートでは表領域が変更されないため、表領域は読取り専用のままになります。

16. inst3.example.comデータベースで、sales表領域内のデータにレポートを実行します。

17. 表領域およびその内容を削除します。

DROP TABLESPACE sales_tbs1 INCLUDING CONTENTS;

DROP TABLESPACE sales_tbs2 INCLUDING CONTENTS;

表領域がinst3.example.comデータベースから削除されても、表領域ファイルはディレクトリ・オブジェクトに残ったままです。

各四半期の終了時に手順11から17を繰り返して、各四半期のレポートを実行できます。

ファイル・グループ・リポジトリの使用

DBMS_FILE_GROUPパッケージを使用すると、ファイル・グループ・リポジトリの作成、リポジトリへのバージョニングされたファイル・グループの追加およびリポジトリからのバージョニングされたファイル・グループのコピーを実行できます。この項では、ファイル・グループ・リポジトリの使用方法とリポジトリにレポートを格納する使用例について説明します。

この例では、ある企業がインターネット経由で書籍および音楽商品を販売します。企業は、inst1.example.comデータベース内の売上データに関する週次レポートを実行し、これらのレポートをコンピュータ・ファイル・システムに2つのHTMLファイルで格納します。book_sales.htmファイルには、書籍の売上レポートが含まれ、music_sales.htmファイルには、音楽商品の売上レポートが含まれます。企業は、これらの週次レポートを、inst2.example.comリモート・データベースのファイル・グループ・リポジトリに格納します。毎週、2つのレポートがinst1.example.comデータベースで生成され、inst2.example.comデータベースが実行されているコンピュータ・システムに転送され、ファイル・グループ・バージョンとしてリポジトリに追加されます。ファイル・グループ・リポジトリには、週ごとのレポートを含むすべてのファイル・グループのバージョンが格納されます。

図36-5に、この例で作成されるファイル・グループ・リポジトリの概要を示します。

図36-5 ファイル・グループ・リポジトリの例

ファイル・グループ・リポジトリのメリットは、データ・ディクショナリ内の各ファイル・グループのバージョンに関するメタデータを格納し、ファイル・グループのバージョンを管理するための標準インタフェースを提供することです。たとえば、企業が特定の売上レポートを表示する必要がある場合、inst2.example.comデータベース内のデータ・ディクショナリを問い合せて、コンピュータ・ファイル・システム上のレポートの場所を判別できます。

次の表に、この例で作成されるディレクトリ・オブジェクトを示します。この表には、新しいレポートを格納するためにinst1.example.comデータベースに作成されるディレクトリ・オブジェクト、およびinst2.example.comデータベース上のファイル・グループ・リポジトリのバージョンに関連付けられたディレクトリ・オブジェクトを示します。

ディレクトリ・オブジェクト

データベース

バージョン

対応するファイル・システム・ディレクトリ

sales_reports

inst1.example.com

ファイル・グループ・リポジトリのバージョンには関連付けられていない

/home/sales_reports

sales_reports1

inst2.example.com

sales_reports_v1

/home/sales_reports/fg1

sales_reports2

inst2.example.com

sales_reports_v1

/home/sales_reports/fg2

この例では、次のことを想定しています。

- inst1.example.comおよびinst2.example.comデータベースが存在しています。

- inst1.example.comおよびinst2.example.comデータベースはファイル・システムを共有しません。

- データベースが相互に通信できるように、ネットワークがデータベース間で構成されています。

- inst1.example.comデータベースでは、データベース内の書籍および音楽商品の売上データに関するレポートが実行され、コンピュータ・ファイル・システムにHTMLファイルとしてレポートが格納されます。

リモート・データベースでファイル・グループ・リポジトリを構成および移入するには、次の手順を実行します。

1. ファイル・グループ・リポジトリを含むリモート・データベースに、管理ユーザーとして接続します。この例では、inst2.example.comデータベースに接続します。
管理ユーザーは、ディレクトリ・オブジェクトの作成およびDBMS_FILE_GROUPパッケージのプロシージャの実行に必要な権限を持っている必要があります。

SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

2. ファイル・グループの最初のバージョンを保持するためのディレクトリ・オブジェクトを作成します。

CREATE OR REPLACE DIRECTORY sales_reports1 AS '/home/sales_reports/fg1';

ディレクトリ・オブジェクトの作成時に、指定したファイル・システム・ディレクトリが存在している必要があります。

3. レポートを実行するデータベースに、管理ユーザーとして接続します。この例では、inst1.example.comデータベースに接続します。
管理ユーザーは、ディレクトリ・オブジェクトの作成に必要な権限を持っている必要があります。

4. 最新のレポートを保持するためのディレクトリ・オブジェクトを作成します。

CREATE OR REPLACE DIRECTORY sales_reports AS '/home/sales_reports';

ディレクトリ・オブジェクトの作成時に、指定したファイル・システム・ディレクトリが存在している必要があります。

5. inst2.example.comデータベースへのデータベース・リンクを作成します。

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

6. inst1.example.comデータベースにレポートを実行します。レポートを実行すると、book_sales.htmおよびmusic_sales.htmファイルが、手順4で指定したディレクトリに配置されます。

7. ファイル転送プロトコル(FTP)またはその他の方法を使用して、inst1.example.comデータベースが実行されているコンピュータ・システムからinst2.example.comデータベースが実行されているコンピュータ・システムにレポート・ファイルを転送します。ファイルが、手順2で作成したディレクトリ・オブジェクトに対応するディレクトリにコピーされていることを確認します。

8. ファイル・グループ・リポジトリを含むリモート・データベースに、管理ユーザーとして接続します。この例では、inst2.example.comデータベースに接続します。

9. レポートを含むファイル・グループ・リポジトリを作成します。

BEGIN
DBMS_FILE_GROUP.CREATE_FILE_GROUP(
file_group_name => 'strmadmin.reports');
END;
/

reportsファイル・グループ・リポジトリは、次のデフォルト・プロパティを使用して作成されます。

- リポジトリ内のバージョンの最小数は2です。ファイル・グループを消去するとバージョンの数が2未満になる場合は、そのファイル・グループを消去できません。

- バージョンの最大数は無制限です。ファイル・グループのバージョンは、リポジトリ内のファイル・グループのバージョン数が原因で削除されることはありません。

- 保持日数は無制限です。ファイル・グループのバージョンは、リポジトリ内で保持された時間が原因で消去されることはありません。

10. ファイル・グループの最初のバージョンを作成します。

BEGIN
DBMS_FILE_GROUP.CREATE_VERSION(
file_group_name => 'strmadmin.reports',
version_name    => 'sales_reports_v1',
comments        => 'Sales reports for week of 06-FEB-2005');
END;
/

11. ファイル・グループのバージョンにレポート・ファイルを追加します。

BEGIN
DBMS_FILE_GROUP.ADD_FILE(
file_group_name  => 'strmadmin.reports',
file_name        => 'book_sales.htm',
file_type        => 'HTML',
file_directory   => 'sales_reports1',
version_name     => 'sales_reports_v1');
DBMS_FILE_GROUP.ADD_FILE(
file_group_name  => 'strmadmin.reports',
file_name        => 'music_sales.htm',
file_type        => 'HTML',
file_directory   => 'sales_reports1',
version_name     => 'sales_reports_v1');
END;
/

12. ファイル・グループの次のバージョンを保持するためのディレクトリ・オブジェクトをinst2.example.comに作成します。

CREATE OR REPLACE DIRECTORY sales_reports2 AS '/home/sales_reports/fg2';

ディレクトリ・オブジェクトの作成時に、指定したファイル・システム・ディレクトリが存在している必要があります。

13. 翌週末にinst1.example.comデータベースにレポートを実行します。レポートを実行すると、新しいbook_sales.htmおよびmusic_sales.htmファイルが、手順4で指定したディレクトリに格納されます。必要に応じて、このディレクトリから古いファイルを削除してからレポートを実行します。

14. ファイル転送プロトコル(FTP)またはその他の方法を使用して、inst1.example.comデータベースが実行されているコンピュータ・システムからinst2.example.comデータベースが実行されているコンピュータ・システムにレポート・ファイルを転送します。ファイルが、手順12で作成したディレクトリ・オブジェクトに対応するディレクトリにコピーされていることを確認します。

15. SQL*Plusで、inst2.example.comデータベースに管理ユーザーとして接続します。

16. ファイル・グループの次のバージョンを作成します。

BEGIN
DBMS_FILE_GROUP.CREATE_VERSION(
file_group_name => 'strmadmin.reports',
version_name    => 'sales_reports_v2',
comments        => 'Sales reports for week of 13-FEB-2005');
END;
/

17. ファイル・グループのバージョンにレポート・ファイルを追加します。

BEGIN
DBMS_FILE_GROUP.ADD_FILE(
file_group_name  => 'strmadmin.reports',
file_name        => 'book_sales.htm',
file_type        => 'HTML',
file_directory   => 'sales_reports2',
version_name     => 'sales_reports_v2');
DBMS_FILE_GROUP.ADD_FILE(
file_group_name  => 'strmadmin.reports',
file_name        => 'music_sales.htm',
file_type        => 'HTML',
file_directory   => 'sales_reports2',
version_name     => 'sales_reports_v2');
END;
/

この時点で、ファイル・グループ・リポジトリには、売上レポート・ファイルを含むファイル・グループの2つのバージョンが含まれます。ファイル・グループの新しいバージョンをリポジトリに追加するには、手順12から17を繰り返します。

関連項目:

- 「ファイル・グループ・リポジトリ」

- DBMS_FILE_GROUPパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

37 ファイル・グループおよび表領域リポジトリの監視

ファイル・グループ・リポジトリには、複数のファイル・グループおよび特定のファイル・グループの複数のバージョンを含めることができます。表領域リポジトリは、ファイル・グループ・リポジトリ内の表領域セットの集合です。表領域リポジトリはファイル・グループ・リポジトリ上に構築されますが、表領域リポジトリには、データベース間での表領域の移動またはコピーに必要なファイルのみが含まれます。この章では、ファイル・グループ・リポジトリおよび表領域リポジトリの監視に使用できる問合せ例を示します。

次の各項では、ファイル・グループおよび表領域リポジトリの監視について説明します。

- ファイル・グループ・リポジトリの監視

- 表領域リポジトリの監視

注意:
Oracle Enterprise ManagerのOracle Streamsツールも、Oracle Streams環境を監視するための優れた手段です。詳細は、Oracle Streamsツールのオンライン・ヘルプを参照してください。

関連項目:

- 第35章「情報のプロビジョニングの概要」

- 第36章「情報のプロビジョニングの使用」

- この章で説明するデータ・ディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照

ファイル・グループ・リポジトリの監視

次の各項では、ファイル・グループ・リポジトリを監視するための問合せの例を示します。

- データベース内のファイル・グループに関する一般情報の表示

- ファイル・グループのバージョンに関する情報の表示

- ファイル・グループのファイルに関する情報の表示

関連項目:

- 「ファイル・グループ・リポジトリ」

- 「ファイル・グループ・リポジトリの使用」

データベース内のファイル・グループに関する一般情報の表示

この項で説明する問合せを実行すると、ローカル・データベース内の各ファイル・グループに関する次の情報が表示されます。

- ファイル・グループの所有者

- ファイル・グループの名前

- バージョンが削除された場合に、ファイル・グループのバージョン内のファイルがディスクに格納されるかどうか

- ファイル・グループのバージョンの許容最小数

- ファイル・グループのバージョンの許容最大数

- ファイル・グループのバージョンが作成後に保持される日数

次の問合せを実行すると、ローカル・データベースに関して前述の情報が表示されます。

COLUMN FILE_GROUP_OWNER HEADING 'File Group|Owner' FORMAT A10
COLUMN FILE_GROUP_NAME HEADING 'File Group|Name' FORMAT A10
COLUMN KEEP_FILES HEADING 'Keep|Files?' FORMAT A10
COLUMN MIN_VERSIONS HEADING 'Minimum|Number|of Versions' FORMAT 9999
COLUMN MAX_VERSIONS HEADING 'Maximum|Number|of Versions' FORMAT 9999999999
COLUMN RETENTION_DAYS HEADING 'Days to|Retain|a Version' FORMAT 9999999999.99

SELECT FILE_GROUP_OWNER,
FILE_GROUP_NAME,
KEEP_FILES,
MIN_VERSIONS,
MAX_VERSIONS,
RETENTION_DAYS
FROM DBA_FILE_GROUPS;

出力は次のようになります。

Minimum     Maximum        Days to
File Group File Group Keep            Number      Number         Retain
Owner      Name       Files?     of Versions of Versions      a Version
---------- ---------- ---------- ----------- ----------- --------------
STRMADMIN  REPORTS    Y                    2  4294967295  4294967295.00

この出力から、次の特性を持つ1つのファイル・グループがデータベースに含まれていることがわかります。

- ファイル・グループの所有者はstrmadminです。

- ファイル・グループの名前はreportsです。

- ファイル・グループのKeep Files?がYであるため、バージョンが削除された場合に、バージョン内のファイルはディスクに格納されます。

- バージョンの許容最小数は2です。ファイル・グループで自動的にバージョンが削除される場合、バージョンの削除によってバージョンの合計数が2未満になるときは、そのバージョンは削除されません。

- ファイル・グループで許容されるバージョンの数は無制限です。4294967295という数値は、バージョン数が無制限であることを意味します。

- ファイル・グループでは、無制限の日数のバージョンが保持されます。4294967295という数値は、日数が無制限であることを意味します。

ファイル・グループのバージョンに関する情報の表示

この項で説明する問合せを実行すると、ローカル・データベース内の各ファイル・グループのバージョンに関する次の情報が表示されます。

- バージョンを含むファイル・グループの所有者

- バージョンを含むファイル・グループの名前

- バージョン名

- バージョン番号

- バージョンを作成したユーザーの名前

- バージョンに関するコメント

次の問合せを実行すると、ローカル・データベースに関して前述の情報が表示されます。

COLUMN FILE_GROUP_OWNER HEADING 'File Group|Owner' FORMAT A10
COLUMN FILE_GROUP_NAME HEADING 'File Group|Name' FORMAT A10
COLUMN VERSION_NAME HEADING 'Version Name' FORMAT A20
COLUMN VERSION HEADING 'Version|Number' FORMAT 99999999
COLUMN CREATOR HEADING 'Creator' FORMAT A10
COLUMN COMMENTS HEADING 'Comments' FORMAT A14

SELECT FILE_GROUP_OWNER,
FILE_GROUP_NAME,
VERSION_NAME,
VERSION,
CREATOR,
COMMENTS
FROM DBA_FILE_GROUP_VERSIONS;

出力は次のようになります。

File Group File Group                        Version
Owner      Name       Version Name            Number Creator    Comments
---------- ---------- -------------------- --------- ---------- --------------
STRMADMIN  REPORTS    SALES_REPORTS_V1             1 STRMADMIN  Sales reports
for week of 06
-FEB-2005

STRMADMIN  REPORTS    SALES_REPORTS_V2             2 STRMADMIN  Sales reports
for week of 13
-FEB-2005

ファイル・グループのファイルに関する情報の表示

この項で説明する問合せを実行すると、ローカル・データベース内のファイル・グループのバージョン内の各ファイルに関する次の情報が表示されます。

- ファイルを含むファイル・グループの所有者

- ファイルを含むファイル・グループの名前

- ファイルを含むファイル・グループ内のバージョンの名前

- ファイル名

- ファイルを含むディレクトリ・オブジェクト

COLUMN FILE_GROUP_OWNER HEADING 'File Group|Owner' FORMAT A10
COLUMN FILE_GROUP_NAME HEADING 'File Group|Name' FORMAT A10
COLUMN VERSION_NAME HEADING 'Version Name' FORMAT A20
COLUMN FILE_NAME HEADING 'File Name' FORMAT A15
COLUMN FILE_DIRECTORY HEADING 'File Directory|Object' FORMAT A15

SELECT FILE_GROUP_OWNER,
FILE_GROUP_NAME,
VERSION_NAME,
FILE_NAME,
FILE_DIRECTORY
FROM DBA_FILE_GROUP_FILES;

出力は次のようになります。

File Group File Group                                      File Directory
Owner      Name       Version Name         File Name       Object
---------- ---------- -------------------- --------------- ---------------
STRMADMIN  REPORTS    SALES_REPORTS_V1     book_sales.htm  SALES_REPORTS1
STRMADMIN  REPORTS    SALES_REPORTS_V1     music_sales.htm SALES_REPORTS1
STRMADMIN  REPORTS    SALES_REPORTS_V2     book_sales.htm  SALES_REPORTS2
STRMADMIN  REPORTS    SALES_REPORTS_V2     music_sales.htm SALES_REPORTS2

DBA_DIRECTORIESデータ・ディクショナリ・ビューを問い合せて、ディレクトリ・オブジェクトの対応するファイル・システム・ディレクトリを判別します。

表領域リポジトリの監視

次の各項では、表領域リポジトリを監視するための問合せの例を示します。

- 表領域リポジトリ内の表領域に関する情報の表示

- 表領域リポジトリ内の表に関する情報の表示

- 表領域リポジトリ内のバージョンに関するエクスポート情報の表示

関連項目:

- 「表領域リポジトリ」

- 「表領域リポジトリの使用」

表領域リポジトリ内の表領域に関する情報の表示

この項で説明する問合せを実行すると、ローカル・データベース内の表領域リポジトリ内の各表領域に関する次の情報が表示されます。

- 表領域リポジトリ内の表領域を含むファイル・グループの所有者

- 表領域リポジトリ内の表領域を含むファイル・グループの名前

- 表領域を含むバージョンの名前

- 表領域の名前

COLUMN FILE_GROUP_OWNER HEADING 'File Group|Owner' FORMAT A15
COLUMN FILE_GROUP_NAME HEADING 'File Group|Name' FORMAT A15
COLUMN VERSION_NAME HEADING 'Version Name' FORMAT A15
COLUMN VERSION HEADING 'Version|Number' FORMAT 99999999
COLUMN TABLESPACE_NAME HEADING 'Tablespace Name' FORMAT A15

SELECT FILE_GROUP_OWNER,
FILE_GROUP_NAME,
VERSION_NAME,
VERSION,
TABLESPACE_NAME
FROM DBA_FILE_GROUP_TABLESPACES;

出力は次のようになります。

File Group      File Group                        Version
Owner           Name            Version Name       Number Tablespace Name
--------------- --------------- --------------- --------- ---------------
STRMADMIN       SALES           V_Q1FY2005              1 SALES_TBS1
STRMADMIN       SALES           V_Q1FY2005              1 SALES_TBS2
STRMADMIN       SALES           V_Q2FY2005              3 SALES_TBS1
STRMADMIN       SALES           V_Q2FY2005              3 SALES_TBS2
STRMADMIN       SALES           V_Q1FY2005_R            4 SALES_TBS1
STRMADMIN       SALES           V_Q1FY2005_R            4 SALES_TBS2
STRMADMIN       SALES           V_Q2FY2005_R            5 SALES_TBS1
STRMADMIN       SALES           V_Q2FY2005_R            5 SALES_TBS2

表領域リポジトリ内の表に関する情報の表示

この項で説明する問合せを実行すると、ローカル・データベース内の表領域リポジトリ内の各表に関する次の情報が表示されます。

- 表領域リポジトリ内の表を含むファイル・グループの所有者

- 表領域リポジトリ内の表を含むファイル・グループの名前

- 表を含むバージョンの名前

- 表の所有者

- 表の名前

- 表を含む表領域

COLUMN FILE_GROUP_OWNER HEADING 'File Group|Owner' FORMAT A10
COLUMN FILE_GROUP_NAME HEADING 'File Group|Name' FORMAT A10
COLUMN VERSION_NAME HEADING 'Version Name' FORMAT A15
COLUMN OWNER HEADING 'Table|Owner' FORMAT A10
COLUMN TABLE_NAME HEADING 'Table Name' FORMAT A15
COLUMN TABLESPACE_NAME HEADING 'Tablespace Name' FORMAT A15

SELECT FILE_GROUP_OWNER,
FILE_GROUP_NAME,
VERSION_NAME,
OWNER,
TABLE_NAME,
TABLESPACE_NAME
FROM DBA_FILE_GROUP_TABLES;

出力は次のようになります。

File Group File Group                 Table
Owner      Name       Version Name    Owner      Table Name      Tablespace Name
---------- ---------- --------------- ---------- --------------- ---------------
STRMADMIN  SALES      V_Q1FY2005      SL         ORDERS          SALES_TBS1
STRMADMIN  SALES      V_Q1FY2005      SL         ORDER_ITEMS     SALES_TBS1
STRMADMIN  SALES      V_Q1FY2005      SL         CUSTOMERS       SALES_TBS2
STRMADMIN  SALES      V_Q2FY2005      SL         ORDERS          SALES_TBS1
STRMADMIN  SALES      V_Q2FY2005      SL         ORDER_ITEMS     SALES_TBS1
STRMADMIN  SALES      V_Q2FY2005      SL         CUSTOMERS       SALES_TBS2
STRMADMIN  SALES      V_Q1FY2005_R    SL         ORDERS          SALES_TBS1
STRMADMIN  SALES      V_Q1FY2005_R    SL         ORDER_ITEMS     SALES_TBS1
STRMADMIN  SALES      V_Q1FY2005_R    SL         CUSTOMERS       SALES_TBS2
STRMADMIN  SALES      V_Q2FY2005_R    SL         ORDERS          SALES_TBS1
STRMADMIN  SALES      V_Q2FY2005_R    SL         ORDER_ITEMS     SALES_TBS1
STRMADMIN  SALES      V_Q2FY2005_R    SL         CUSTOMERS       SALES_TBS2

表領域リポジトリ内のバージョンに関するエクスポート情報の表示

ローカル・データベース内の表領域リポジトリ内のバージョンに関するエクスポート情報を表示するには、DBA_FILE_GROUP_EXPORT_INFOデータ・ディクショナリ・ビューを問い合せます。このビューは、有効なデータ・ポンプ・エクスポート・ダンプ・ファイルを含むバージョンの情報のみを表示します。この項で説明する問合せを実行すると、ローカル・データベース内の各バージョンに関する次のエクスポート情報が表示されます。

- バージョンを含むファイル・グループの名前

- バージョンの名前

- エクスポート・ダンプ・ファイルのエクスポート・バージョン。エクスポート・バージョンは、エクスポートを実行したデータ・ポンプのバージョンに対応します。

- エクスポートが実行されたプラットフォーム

- エクスポートの日時

- エクスポートするデータベースのグローバル名

COLUMN FILE_GROUP_NAME HEADING 'File Group|Name' FORMAT A10
COLUMN VERSION_NAME HEADING 'Version Name' FORMAT A13
COLUMN EXPORT_VERSION HEADING 'Export|Version' FORMAT A7
COLUMN PLATFORM_NAME HEADING 'Export Platform' FORMAT A17
COLUMN EXPORT_TIME HEADING 'Export Time' FORMAT A17
COLUMN SOURCE_GLOBAL_NAME HEADING 'Export|Database' FORMAT A10

SELECT FILE_GROUP_NAME,
VERSION_NAME,
EXPORT_VERSION,
PLATFORM_NAME,
TO_CHAR(EXPORT_TIME, 'HH24:MI:SS MM/DD/YY') EXPORT_TIME,
SOURCE_GLOBAL_NAME
FROM DBA_FILE_GROUP_EXPORT_INFO;

出力は次のようになります。

File Group               Export                                      Export
Name       Version Name  Version Export Platform   Export Time       Database
---------- ------------- ------- ----------------- ----------------- ----------
SALES      V_Q1FY2005    10.2.0  Linux IA (32-bit) 12:23:52 03/08/05 INST1.EXAM
PLE.COM
SALES      V_Q2FY2005    10.2.0  Linux IA (32-bit) 12:27:37 03/08/05 INST1.EXAM
PLE.COM
SALES      V_Q1FY2005_R  10.2.0  Linux IA (32-bit) 12:39:50 03/08/05 INST2.EXAM
PLE.COM
SALES      V_Q2FY2005_R  10.2.0  Linux IA (32-bit) 12:46:04 03/08/05 INST2.EXAM
PLE.COM

第VII部

付録

この部の構成は、次のとおりです。

- 付録A「Oracle Streamsと他のデータベース・コンポーネントとの連携」

- 付録B「Oracle Streamsの制限事項」

- 付録C「LCR用のXMLスキーマ」

- 付録D「Oracle Streamsを使用したオンラインでのデータベースのアップグレードおよびメンテナンス」

- 付録E「Oracle Streamsを使用した10.1以下のデータベースのオンラインでのアップグレード」

A Oracle Streamsと他のデータベース・コンポーネントとの連携

この付録では、Oracle Streamsと他のOracle Databaseコンポーネントとの連携について説明します。

内容は次のとおりです。

- Oracle StreamsおよびOracle Real Application Clusters

- Oracle Streamsおよび透過的データ暗号化

- Oracle Streamsおよびフラッシュバック・データ・アーカイブ

- Oracle StreamsおよびRecovery Manager(RMAN)

- Oracle Streamsおよび分散トランザクション

- Oracle StreamsおよびOracle Data Vault

Oracle StreamsおよびOracle Real Application Clusters

次の項では、Oracle StreamsとOracle Real Application Clusters(Oracle RAC)との連携について説明します。

- 取得プロセスおよびOracle Real Application Clusters

- 同期取得およびOracle Real Application Clusters

- 取得と適用の複合およびOracle Real Application Clusters

- キューとOracle Real Application Clusters

- 伝播およびOracle Real Application Clusters

- 適用プロセスおよびOracle Real Application Clusters

関連項目:
Oracle RAC環境におけるOracle Streamsのベスト・プラクティスについては、『Oracle Streamsレプリケーション管理者ガイド』を参照

取得プロセスおよびOracle Real Application Clusters

取得プロセスは、Oracle Real Application Clusters(Oracle RAC)環境での変更を取得できます。同じ環境で1つ以上の取得プロセスとOracle RACを使用する場合は、取得プロセスによって取得される変更を含むすべてのアーカイブ・ログは、Oracle RAC環境のすべてのインスタンスで使用可能である必要があります。Oracle RAC環境では、取得プロセスによってすべてのインスタンスによる変更が読み取られます。単一の取得プロセスによって使用されるプロセスは、Oracle RAC環境の単一インスタンスで実行されます。

各取得プロセスは、起動プロシージャまたは停止プロシージャが別のインスタンスで実行されている場合でも、そのANYDATAキューの所有者インスタンスで起動および停止されます。また、現行の所有者インスタンスが使用不可能になった場合、取得プロセスは別のインスタンスに対するキューに従います。キュー自体は、プライマリ・インスタンスとセカンダリ・インスタンスの所有権のルールに従います。

取得プロセスによって使用されるキューを含むキュー表の所有者インスタンスが使用不可能になった場合、キュー所有権がクラスタ内の別のインスタンスに自動的に移動します。さらに、所有者インスタンスが使用不可能になったときに取得プロセスが有効であった場合、取得プロセスは新しい所有者インスタンスで自動的に再起動されます。所有者インスタンスが使用不可能になったときに取得プロセスが無効であった場合、取得プロセスは新しい所有者インスタンスでも無効のままです。

LogMinerではLOG_ARCHIVE_DEST_n初期化パラメータがサポートされており、Oracle Streamsの取得プロセスでは、LogMinerを使用してREDOログから変更が取得されます。1つの宛先からアーカイブ・ログ・ファイルにアクセスできない場合は、ローカル取得プロセスで、アクセス可能な別の宛先からアーカイブ・ログ・ファイルを読み取ることができます。Oracle RACデータベースでは、この機能を使用して、インスタンス間アーカイブ(CIA)を使用することもできます。CIAでは、各インスタンスによってファイルがすべてのインスタンスにアーカイブされます。この方法では、アーカイブ・ログ・ファイルの欠落による差異を検出したり、解決することはできません。このため、この方法は、既存の方法を補完して、アーカイブ・ファイルをすべてのインスタンスで共有可能にする場合にのみ使用できます。

ダウンストリーム取得プロセス環境では、ソース・データベースは、単一インスタンス・データベースまたは複数インスタンスのOracle RACデータベースです。ダウンストリーム・データベースは、ソース・データベースが単一インスタンスか複数インスタンスかに関係なく、単一インスタンスのデータベースまたは複数インスタンスのOracle RACデータベースとして構成できます。

関連項目:

- 「Oracle Streams取得プロセスによる暗黙的取得」

- DBA_QUEUE_TABLESデータ・ディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照

- インスタンス間で共有されるアーカイブ・ログの構成の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照

同期取得およびOracle Real Application Clusters

同期取得は、Oracle Real Application Clusters(Oracle RAC)環境での変更を取得できます。Oracle RAC環境では、同期取得によって、すべてのインスタンスで行われた変更が読み取られます。

Oracle RAC環境での同期取得のパフォーマンスを向上させるには、個別の表セットに対する変更を個別の同期取得で取得する必要があります。たとえば、様々なアプリケーションでデータベース内の異なるセットのデータベース・オブジェクトが使用されている場合は、各アプリケーションのデータベース・オブジェクトに対する変更を取得する個別の同期取得を構成します。この場合、各同期取得で、別々のキューおよびキュー表を使用する必要があります。

関連項目:
「同期取得による暗黙的取得」

取得と適用の複合およびOracle Real Application Clusters

取得と適用の複合はOracle Real Application Clusters(Oracle RAC)環境で使用できます。Oracle RAC環境では、取得プロセスおよび適用プロセスは、同じインスタンス、単一のOracle RACデータベース内の異なるインスタンス、または異なるデータベースに存在することができます。取得プロセスおよび適用プロセスが同じデータベースの異なるインスタンスまたは異なるデータベースに存在する場合、取得と適用の複合を使用するには、取得プロセスのキューと適用プロセスのキューの間の伝播を構成する必要があります。

関連項目:
第12章「取得と適用の複合による最適化」

キューとOracle Real Application Clusters

Oracle Real Application Clusters(Oracle RAC)環境で、LCRとユーザー・メッセージをステージングするようにキューを構成できます。Oracle RAC環境では、キューのバッファを使用できるのは所有者インスタンスのみですが、別のインスタンスは、別のキューのバッファを使用できます。バッファ・キューは、キューに関連付けられたシステム・グローバル領域(SGA)メモリーです。

Oracle Streamsのプロセスおよびジョブは、キュー表のプライマリ・インスタンスおよびセカンダリ・インスタンスの指定をサポートしています。これらの指定を使用する場合、プライマリ・インスタンスが使用不可能になると、セカンダリ・インスタンスがキュー表の所有者となります。プライマリ・インスタンスが再度使用可能になると、所有権はプライマリ・インスタンスに戻ります。

プライマリ・インスタンスおよびセカンダリ・インスタンスの指定は、DBMS_AQADMパッケージのALTER_QUEUE_TABLEプロシージャを使用して設定できます。DBA_QUEUE_TABLESデータ・ディクショナリ・ビューは、キュー表の所有者インスタンスに関する情報を示します。キュー表には、複数のキューが含まれている場合があります。この場合、キュー表内の各キューの所有者インスタンスは、キュー表と同じになります。

関連項目:

- 「キュー」

- DBA_QUEUE_TABLESデータ・ディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照

- キューおよびOracle RACの詳細は、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドを参照

- ALTER_QUEUE_TABLEプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

伝播およびOracle Real Application Clusters

伝播は、あるキューからOracle Real Application Clusters(Oracle RAC)環境内の別のキューにメッセージを伝播できます。インスタンスで実行されている伝播ジョブは、そのインスタンスで所有されるキューから宛先キューに論理変更レコード(LCR)を伝播します。

Oracle RACデータベースへの伝播は、データベース・リンクを介して行われます。データベース・リンクは、メッセージを受信予定のキューを所有している宛先インスタンスに接続するように構成する必要があります。

伝播で宛先キューを含むキュー表の所有者インスタンスが使用不可能になると、キューの所有権がクラスタ内の別のインスタンスに自動的に移動します。宛先キューを含むキュー表のプライマリ・インスタンスおよびセカンダリ・インスタンスの両方が使用不可能になると、キューの所有権がクラスタ内の別のインスタンスに自動的に移動します。この場合、プライマリ・インスタンスまたはセカンダリ・インスタンスが再度使用可能になると、所有権は使用可能になったインスタンスに戻ります。

バッファ宛先キューへのキュー・ツー・キュー伝播は、サービスを使用してOracle RAC環境での透過的フェイルオーバーを提供します。つまり、キュー・ツー・キュー伝播の伝播ジョブは、宛先キューを所有するインスタンスに自動的に接続します。キュー・ツー・キュー伝播で使用されるサービスは、常に宛先キューの所有者インスタンスで実行されます。このサービスは、Oracle RACデータベース内のバッファ・キュー用にのみ作成されます。Oracle RACデータベースにバッファリングされたメッセージ機能を使用する予定の場合は、任意のインスタンスでメッセージをバッファ・キューにエンキューできます。キューを所有していないインスタンスにメッセージがエンキューされた場合、メッセージは正しいインスタンスに送信されますが、キューを所有しているインスタンスにメッセージをエンキューする方がより効率的です。このサービスを使用すると、メッセージをバッファ・キューにエンキューする前にキューの所有者インスタンスに接続できます。

キュー・サービスはキューの所有者インスタンスで常に実行しているため、Oracle RACインスタンスが失敗すると、透過的フェイルオーバーが行われます。複数のキュー・ツー・キュー伝播が1つのデータベース・リンクを使用する場合、メッセージを適切な宛先キューに伝播するように各伝播の接続記述が自動的に変わります。

これに対し、キュー・ツーdblink伝播ではサービスを使用しません。伝播で宛先キューを含むOracle RACデータベースの所有者インスタンスが失敗すると、キュー・ツーdblink伝播ではユーザーがデータベース・リンクを再び指す必要があります。伝播ジョブが宛先データベースの正しいインスタンスに接続するようにするには、宛先キューを所有しているインスタンスに接続するようにソース・データベースからのデータベース・リンクを手動で再構成します。再作成されたデータベース・リンクを使用する伝播を変更する必要はありません。

DBA_SERVICESデータ・ディクショナリ・ビューのNAME列に、キューのサービス名が含まれています。DBA_QUEUESデータ・ディクショナリ・ビューのNETWORK_NAME列には、キューのネットワーク名が含まれています。キュー・ツー・キュー伝播のサービスを管理することはできません。これらのサービスはOracleによって自動的に管理されます。キュー・ツーdblink伝播の場合、正しいインスタンスに接続するには、データベース・リンクの接続文字列でネットワーク名をサービス名として使用します。

注意:
Oracle RAC環境でキューが取得LCRを含む場合、キュー・ツー・キュー伝播を使用してOracle RACの宛先データベースにメッセージを伝播してください。キュー・ツーdblink伝播で取得LCRがOracle RACの宛先データベースに伝播される場合、この伝播は、宛先キューの所有者インスタンスを参照するインスタンス固有のデータベース・リンクを使用する必要があります。このような伝播が他のインスタンスに接続すると、伝播でエラーが発生します。

関連項目:
「キュー間でのメッセージの伝播」

適用プロセスおよびOracle Real Application Clusters

Oracle Streamsの適用プロセスは、Oracle Real Application Clusters(Oracle RAC)環境での変更を適用するように構成できます。各適用プロセスは、開始プロシージャおよび停止プロシージャが別のインスタンスで実行されている場合でも、そのANYDATAキューの所有者インスタンスで開始または停止されます。適用コーディネータ・プロセス、それに対応する適用リーダー・サーバーおよびそのすべての適用サーバーは、単一インスタンスで実行されます。

適用プロセスで使用されるキューが含まれているキュー表の所有者インスタンスが使用不可能になると、キューの所有権は自動的にクラスタ内の別のインスタンスに譲渡されます。また、現行の所有者インスタンスが使用不可能になった場合、適用プロセスは、別のインスタンスに対するキューに従います。キュー自体は、プライマリ・インスタンスとセカンダリ・インスタンスの所有権のルールに従います。また、適用プロセスは、所有者インスタンスが使用不可能になったときに有効だった場合、新しい所有者インスタンスで自動的に起動されます。所有者インスタンスが使用不可能になったときに無効だった場合は、新しい所有者インスタンスでも無効のままになります。

関連項目:

- 「適用プロセスによる暗黙的コンシューム」

- DBA_QUEUE_TABLESデータ・ディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照

Oracle Streamsおよび透過的データ暗号化

次の項では、Oracle Streamsと透過的データ暗号化との連携について説明します。

- 取得プロセスおよび透過的データ暗号化

- 同期取得および透過的データ暗号化

- 明示的取得および透過的データ暗号化

- キューおよび透過的データ暗号化

- 伝播とネットワーク・データの暗号化

- 適用プロセスおよび透過的データ暗号化

- メッセージ・クライアントおよび透過的データ暗号化

- 手動デキューおよび透過的データ暗号化

関連項目:
透過的データ暗号化の詳細は、Oracle Database Advanced Security管理者ガイドを参照

取得プロセスおよび透過的データ暗号化

ローカル取得プロセスでは、透過的データ暗号化を使用して暗号化されている列に対する変更を取得できます。ダウンストリーム取得プロセスでは、ダウンストリーム・データベースがソース・データベースとウォレットを共有している場合にのみ、暗号化されている列に対する変更を取得できます。ウォレットは、ネットワーク・ファイル・システム(NFS)を介して共有するか、または1つのコンピュータ・システムから別のコンピュータ・システムに手動でコピーできます。ウォレットがダウンストリーム・データベースと共有されている場合は、ダウンストリーム・データベースのsqlnet.oraファイルのENCRYPTION_WALLET_LOCATIONパラメータにウォレットの場所が指定されていることを確認してください。

ダウンストリーム・データベースにウォレットをコピーする場合は、ソース・データベースのウォレットが変更されるたびに、ソース・データベースからダウンストリーム・データベースにウォレットをコピーしてください。ダウンストリーム・データベースのウォレットに対して、レプリケートされた表の暗号化鍵の変更などの操作は実行しないでください。

ローカル取得プロセスまたはダウンストリーム取得プロセスによって取得された行論理変更レコード(行LCR)内の暗号化された列は、行LCRがバッファ・キューにステージングされると復号化されます。透過的データ暗号化が有効になっているデータベース内のディスクに行LCRがオーバーフローした場合、行LCRはディスクに格納されますが、すべての暗号化された列はOracle Streamsによって透過的に暗号化されます。

注意:
取得プロセスによって使用されるREDOログが互換性レベル11.0.0以上のデータベースで生成されている場合、取得プロセスでは、暗号化された列のみがサポートされます。互換性レベルは、COMPATIBLE初期化パラメータによって制御されます。

関連項目:

- 「Oracle Streams取得プロセスによる暗黙的取得」

- 「永続キューおよびバッファ・キュー」

同期取得および透過的データ暗号化

同期取得では、透過的データ暗号化を使用して暗号化されている列に対する変更を取得できます。同期取得によって取得された行論理変更レコード(行LCR)内の暗号化された列は、行LCRが永続キューにステージングされている場合は暗号化されたままになります。

関連項目:
「同期取得による暗黙的取得」

明示的取得および透過的データ暗号化

明示的取得を使用すると、データベース表で暗号化されている列の行論理変更レコード(行LCR)を作成およびエンキューできます。ただし、行LCRの作成時に列が暗号化されるように指定することはできません。したがって、明示的に取得された行LCRがキューにステージングされると、行LCRのすべての列が復号化されます。

関連項目:
「アプリケーションによる明示的取得」

キューおよび透過的データ暗号化

永続キューは、同期取得によって取得された行論理変更レコード(行LCR)を格納できます。これらの行LCRには、透過的データ暗号化を使用して暗号化された列に対する変更を含めることができます。行LCRは、永続キューに格納されている間は暗号化されたままです。明示的に取得された行LCRには、暗号化された列を含めることはできません。

バッファ・キューは、取得プロセスによって取得された変更を含む行LCRを格納できます。これらの行LCRには、透過的データ暗号化を使用して暗号化された列に対する変更を含めることができます。暗号化された列を含む行LCRがバッファ・キューに格納されると、それらの列は復号化されます。行LCRがディスクにオーバーフローした場合に、その行LCRがディスクに格納されている間、Oracle Streamsは透過的に暗号化された列を暗号化します。

注意:
Oracle Streamsで列を透過的に暗号化するには、ローカル・データベース上のウォレットに暗号化のマスター鍵が格納されており、ウォレットがオープンしている必要があります。次の文を実行すると、マスター鍵が設定され、ウォレットがオープンします。

ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY key-password;

ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY key-password;

関連項目:

- 「キュー」

- 「Oracle Streamsで情報を取得する方法」

伝播とネットワーク・データの暗号化

伝播では、ネットワーク・データの暗号化を使用して暗号化された列に対する変更を含む行論理変更レコード(行LCR)を伝播できます。伝播によって、暗号化された列とともに行LCRが伝播されると、行LCRがネットワーク上を転送される間に、暗号化された列が復号化されます。必要に応じて、Oracle Advanced Securityの機能を使用して、ネットワーク上でのデータ転送を暗号化できます。

関連項目:

- ネットワーク・データの暗号化の構成の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照

- 「キュー間でのメッセージの伝播」

適用プロセスおよび透過的データ暗号化

適用プロセスでは、透過的データ暗号化を使用して暗号化された列を含む、暗黙的に取得された行論理変更レコード(行LCR)をデキューおよび処理できます。暗号化された列は、それらの暗号化列を含む行LCRが適用プロセスによってデキューされると復号化されます。復号化された列を含むこれらの行LCRは、カスタム処理のために適用ハンドラに送信するか、または直接適用することができます。行LCRが適用され、変更された表に暗号化された列が含まれている場合、暗号化された列に対する変更は適用時に暗号化されます。

暗号化された列が行LCRに含まれていて、宛先データベースの対応する列が暗号化されていない場合は、preserve_encryption適用プロセス・パラメータによって適用プロセスの動作が制御されます。

- preserve_encryptionパラメータがYに設定されているときに、暗号化された列が行LCRに含まれていて、宛先データベースの対応する列が暗号化されていない場合は、適用プロセスでエラーが発生します。エラーが発生すると、行LCRは適用されず、トランザクションのすべての行LCRがエラー・キューに移動されます。

- preserve_encryptionパラメータがNに設定されているときに、暗号化された列が行LCRに含まれていて、宛先データベースの対応する列が暗号化されていない場合は、適用プロセスによって行の変更が適用されます。

適用プロセスが、暗黙的に取得された行LCR(暗号化された列を含む)をエラー・キューに移動する場合、行LCRがエラー・キュー内に存在している間は暗号化された列は暗号化されています。行LCRは、取得プロセスおよび同期取得を使用して暗黙的に取得されます。

関連項目:
「適用プロセスによる暗黙的コンシューム」

メッセージ・クライアントおよび透過的データ暗号化

メッセージ・クライアントは、暗黙的に取得された行LCR(透過的データ暗号化を使用して暗号化された列を含む)をデキューできます。暗号化された列を含む行LCRがメッセージ・クライアントでデキューされるとその列は復号化されます。

関連項目:
「メッセージ・クライアントによる明示的コンシューム」

手動デキューおよび透過的データ暗号化

ユーザーまたはアプリケーションは、暗黙的に取得された行LCR(透過的データ暗号化を使用して暗号化された列を含む)をデキューできます。暗号化された列を含む行LCRがデキューされると、その暗号化された列は復号化されます。

関連項目:
「手動デキューによる明示的コンシューム」

Oracle Streamsおよびフラッシュバック・データ・アーカイブ

Oracle Streamsは、フラッシュバック・データ・アーカイブ内の表をサポートします。取得プロセスは、これらの表に対して行われたデータ操作言語(DML)およびデータ定義言語(DDL)の変更を取得できます。同期取得は、これらの表に対するDMLの変更を取得できます。適用プロセスは、論理変更レコード(LCR)でカプセル化された変更をこれらの表に適用できます。

また、Oracle Streamsの取得プロセスおよび適用プロセスは、次のDDL文もサポートします。

- CREATE FLASHBACK ARCHIVE

- ALTER FLASHBACK ARCHIVE

- DROP FLASHBACK ARCHIVE

- FLASHBACK ARCHIVE句を指定したCREATE TABLE

- FLASHBACK ARCHIVE句を指定したALTER TABLE

注意:
Oracle Streamsは、フラッシュバック・データ・アーカイブによって使用される内部表に対して行われた変更を取得または適用しません。

関連項目:

- フラッシュバック・データ・アーカイブについては、Oracle Databaseアドバンスト・アプリケーション開発者ガイドを参照

- 第2章の「Oracle Streams取得プロセスによる暗黙的取得」

- 第2章の「同期取得による暗黙的取得」

- 第4章の「適用プロセスによる暗黙的コンシューム」

Oracle StreamsおよびRecovery Manager(RMAN)

次の項では、Oracle StreamsとRecovery Manager(RMAN)との連携について説明します。

- RMANおよびインスタンス化

- 取得プロセスで必要なRMANおよびアーカイブREDOログ・ファイル

- リカバリ・カタログおよびOracle Streams

関連項目:
『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』

RMANおよびインスタンス化

RMANを使用すると、Oracle Streamsレプリケーション環境の構成中にデータベース・オブジェクトをインスタンス化することができます。RMANのDUPLICATEおよびCONVERT DATABASEコマンドはデータベース全体をインスタンス化することができ、RMANのTRANSPORT TABLESPACEコマンドは1つの表領域または表領域のセットをインスタンス化することができます。

関連項目:
インスタンス化のためのRMANの使用については、『Oracle Streamsレプリケーション管理者ガイド』を参照

取得プロセスで必要なRMANおよびアーカイブREDOログ・ファイル

Recovery Manager(RMAN)の一部の削除ポリシーおよびコマンドは、アーカイブREDOログ・ファイルを削除します。RMANのこれらのポリシーまたはコマンドのいずれかを、1つ以上の取得プロセスに対してREDOログ・ファイルを生成するデータベースで使用する場合は、そのRMANのコマンドが取得プロセスで必要となるアーカイブREDOログ・ファイルを削除しないことを確認してください。

次の項では、ローカル取得プロセスおよびダウンストリーム取得プロセスにおけるRMANの削除ポリシーおよびコマンドの動作について説明します

- RMANおよびローカル取得プロセス

- RMANおよびダウンストリーム取得プロセス

関連項目:

- 「ARCHIVELOGモードおよび取得プロセス」

- 取得プロセスで必要なアーカイブREDOログ・ファイルが欠落しているかどうかを確認する方法、およびこの問題を解決する方法については、「必須のREDOログ・ファイルが欠落していないか」を参照してください。この項には、高速リカバリ領域およびローカル取得プロセスに関する情報も含まれています。

- 「トレース・ファイルとアラート・ログでの問題のチェック」

- RMANの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』および『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

RMANおよびローカル取得プロセス

ローカル取得プロセスが構成されるとき、高速リカバリ領域に余裕があれば、RMANはローカル取得プロセスで必要となるアーカイブREDOログ・ファイルを削除しません。具体的には、RMANは、ローカル取得プロセスの必須チェックポイントSCN以上のシステム変更番号(SCN)値の変更を含むアーカイブREDOログ・ファイルを削除しません。これは、RMANのすべての削除ポリシーおよびDELETEコマンド(DELETE ARCHIVELOGおよびDELETE OBSOLETEを含む)におけるRMANのデフォルトの動作です。

高速リカバリ領域に新しいログ・ファイルを書き込む領域が十分にない場合、RMANは1つ以上のアーカイブREDOログ・ファイルを自動的に削除します。RMANが自動的に削除したアーカイブREDOログ・ファイルがローカル取得プロセスで必要なものであれば、Oracle Databaseによってアラート・ログに警告が書き込まれます。

アーカイブREDOログ・ファイルのバックアップがローカル取得プロセス・データベースで作成される場合は、RMANの次の削除ポリシーをお薦めします。

CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP integer TIMES
TO DEVICE TYPE deviceSpecifier;

この削除ポリシーでは、ログ・ファイルが削除対象とみなされるまでにinteger回バックアップされる必要があります。

アーカイブREDOログ・ファイルのバックアップがローカル取得プロセス・データベースで作成されない場合は、推奨される特定の削除ポリシーはありません。デフォルトでは、RMANはローカル取得プロセスで必要となるアーカイブREDOログ・ファイルを削除しません。

RMANおよびダウンストリーム取得プロセス

ダウンストリーム取得プロセスが、ソース・データベースで行われたデータベースの変更を取得する場合、アーカイブREDOログ・ファイルがソース・データベースからダウンストリーム取得プロセス・データベースに移動されるまで、RMANの削除ポリシーまたはコマンドがそのアーカイブREDOログ・ファイルを削除しないことを確認してください。

アーカイブREDOログ・ファイルを削除するRMANの特定の削除ポリシーおよびコマンドの考慮事項を次に示します。

- RMANコマンドCONFIGURE ARCHIVELOG DELETION POLICYは、高速リカバリ領域内のアーカイブREDOログ・ファイルが削除対象となるタイミングを決定する削除ポリシーを設定します。また、この削除ポリシーは、RMANのすべてのDELETEコマンド(DELETE ARCHIVELOGおよびDELETE OBSOLETEを含む)に適用されます。
次の設定は、ソース・データベースでの動作を決定します。

- TO SHIPPED TO STANDBYを設定した削除ポリシーは、ログ・ファイルを必要とするダウンストリーム取得プロセス・データベースにそのファイルが移動されるまで、ログ・ファイルを削除しません。これらのログ・ファイルは、ダウンストリーム取得プロセスで処理された場合もあれば、処理されなかった場合もあります。自動削除が発生するのは、高速リカバリ領域に新しいログ・ファイルを書き込む領域が十分にない場合です。

- TO APPLIED ON STANDBYを設定した削除ポリシーは、ログ・ファイルを必要とするダウンストリーム取得プロセス・データベースにそのファイルが移動され、ソース・データベースがそのログ・ファイルを適用済とマークするまで、ログ・ファイルを削除しません。ソース・データベースがログ・ファイルを適用済とマークするのは、ソース・データベースのすべてのダウンストリーム取得プロセスの最小必須チェックポイントSCNがログ・ファイル内の最大SCNより大きくなった場合です。

- TO BACKED UP integer TIMES TO DEVICE TYPEを設定した削除ポリシーでは、ログ・ファイルが削除対象とみなされるまでに、そのログ・ファイルはinteger回バックアップされる必要があります。ログ・ファイルは、そのファイルを必要とするダウンストリーム取得プロセスで処理されていない場合であっても削除できます。

- TO NONEを設定した削除ポリシーは、高速リカバリ領域に余裕がなくなった場合に、ログ・ファイルが、そのファイルを必要とするダウンストリーム取得プロセスで処理されていなくても、そのログ・ファイルを削除できることを意味します。

- RMANコマンドDELETE ARCHIVELOGは、次の条件をすべて満たすアーカイブREDOログ・ファイルを削除します。

- ログ・ファイルが、DELETE ARCHIVELOGコマンドで指定した条件を満たしている。

- CONFIGURE ARCHIVELOG DELETION POLICYに従ってログ・ファイルを削除できる。たとえば、ポリシーにTO SHIPPED TO STANDBYを設定した場合、ログ・ファイルが、そのファイルを必要とするダウンストリーム取得プロセス・データベースに移動されるまで、このコマンドではそのログ・ファイルを削除できません。

この動作は、データベースがマウントまたはオープンされたときに適用されます。

アーカイブREDOログ・ファイルがダウンストリーム取得プロセスで必要な変更を含むために削除されない場合は、RMANによって警告メッセージが表示され、これらのファイルに対する削除操作がスキップされたことが示されます。

- RMANコマンドDELETE OBSOLETEは、次の条件をすべて満たすアーカイブREDOログ・ファイルを完全に削除します。

- ログ・ファイルが、保存ポリシーに従って不要になっている。

- CONFIGURE ARCHIVELOG DELETION POLICYに従ってログ・ファイルを削除できる。たとえば、ポリシーにTO SHIPPED TO STANDBYを設定した場合、ログ・ファイルが、そのファイルを必要とするダウンストリーム取得プロセス・データベースに移動されるまで、このコマンドではそのログ・ファイルを削除できません。

この動作は、データベースがマウントまたはオープンされたときに適用されます。

- RMANコマンドBACKUP ARCHIVELOG ALL DELETE INPUTは、アーカイブREDOログ・ファイルをコピーし、バックアップの完了後に元のファイルを削除します。このコマンドでは、次の条件が満たされている場合、ログ・ファイルがダウンストリーム取得プロセス・データベースに移動されるまで、そのログ・ファイルは削除されません。

- データベースがマウントまたはオープンされている。

- ログ・ファイルが、ダウンストリーム取得プロセスで必要である。

- 削除ポリシーにTO SHIPPED TO STANDBYを設定している。

アーカイブREDOログ・ファイルがダウンストリーム取得プロセスで必要な変更を含むために削除されない場合は、RMANによって警告メッセージが表示され、これらのファイルに対する削除操作がスキップされたことが示されます。

ダウンストリーム取得プロセスの場合、ソース・データベースにおけるRMANの削除ポリシーを次のいずれかにすることをお薦めします。

- アーカイブREDOログ・ファイルのバックアップがソース・データベースで作成される場合、削除ポリシーを次のように設定します。

CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO STANDBY
BACKED UP integer TIMES TO DEVICE TYPE deviceSpecifier;

- アーカイブREDOログ・ファイルのバックアップがソース・データベースで作成されない場合、削除ポリシーを次のように設定します。

CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO STANDBY;

注意:
ダウンストリーム取得プロセス・データベースでは、ソース・データベースから移動されたアーカイブREDOログ・ファイルは、RMANで管理されません。

リカバリ・カタログおよびOracle Streams

Oracle Streamsでは、単方向レプリケーション環境におけるリカバリ・カタログのレプリケートがサポートされます。リカバリ・カタログの双方向レプリケーションはサポートされません。

関連項目:

- 単方向および双方向レプリケーションについては、Oracle Database 2日でデータ・レプリケーションおよび統合ガイドを参照

- リカバリ・カタログについては、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照

Oracle Streamsおよび分散トランザクション

次のいずれかの方法を使用して分散トランザクションを実行できます。

- データベース・リンクを使用して、複数のデータベース内の表を調節された方法で変更します。

- DBMS_XA提供のPL/SQLパッケージ、あるいはOCIまたはJDBCライブラリによって公開されているXAインタフェースを使用します。XAインタフェースは、X/Open分散トランザクション処理(DTP)アーキテクチャを実装します。

これらの2つの方法のいずれかを使用した分散トランザクション中にソース・データベースに変更が加えられると、Oracle Streamsはその変更を宛先データベースにレプリケートします。宛先データベースの適用プロセスは、トランザクションがコミットされた後に、そのトランザクションでの変更を適用します。

ただし、分散トランザクションの状態はレプリケートも送信もされません。宛先データベースやクライアント・アプリケーションは、このようなトランザクションのインダウト状態または準備済状態を継承しません。また、Oracle Streamsでは、ソース・データベースでXAトランザクションのために使用されるものと同じグローバル・トランザクション識別子を使用した変更はレプリケートも送信もしません。

XAトランザクションは、次の2つの方法で実行できます。

- 密結合(異なるXAブランチがロックを共有する)

- 疎結合(異なるXAブランチがロックを共有しない)

Oracle Streamsでは、疎結合のXAブランチによって行われる変更のレプリケーションは、COMPATIBLE初期化パラメータの値に関係なくサポートされます。Oracle RACソース・データベースで密結合のブランチによって行われる変更のレプリケーションについては、COMPATIBLE初期化パラメータが11.2.0以上に設定されている場合にのみサポートされます。

関連項目:

- 分散トランザクションの詳細は、『Oracle Database管理者ガイド』を参照

- Oracle XAの詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照

Oracle StreamsおよびOracle Data Vault

Oracle Database Vaultは、管理権限を持つユーザーを含めた任意のユーザーによるOracle Database内の特定のエリアへのアクセスを制限します。Oracle Data Vault環境でOracle Streamsを使用する場合は、次の権限およびロールが必要です。

- 取得プロセスの作成、適用プロセスの作成および取得プロセスの取得ユーザーの変更というタスクを実行するために、Streams管理者にDV_STREAMS_ADMINロールを付与する必要があります。Streams管理者がこれらのタスクを実行しない場合は、Streams管理者のDV_STREAMS_ADMINロールを取り消すことができます。

- 適用プロセスの適用ユーザーは、レプリケートされたデータベース・オブジェクトを含むレルムに対する変更の適用が可能である必要があります。レプリケートされたデータベース・オブジェクトは、適用プロセスが変更を適用するオブジェクトです。

レルムに対する適用ユーザーを認可するには、DBMS_MACADM.ADD_AUTH_TO_REALMプロシージャを実行して、レルムおよび適用ユーザーを指定します。たとえば、salesレルムに対し適用ユーザーstrmadminを認可するには、次のプロシージャを実行します。

BEGIN
DBMS_MACADM.ADD_AUTH_TO_REALM(
realm_name  => 'sales',
grantee     => 'strmadmin');
END;
/

また、次の操作を実行するユーザーにBECOME USERシステム権限を付与する必要があります。

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

- アウトバウンド・サーバーの作成または変更

- インバウンド・サーバーの作成または変更

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

『Oracle Database Vault管理者ガイド』を参照してください。

B Oracle Streamsの制限事項

この付録では、Oracle Streamsの制限事項について説明します。

内容は次のとおりです。

- 取得プロセスの制限事項

- 同期取得の制限事項

- キューの制限事項

- 伝播の制限事項

- 適用プロセスの制限事項

- メッセージ・クライアントの制限事項

- ルールの制限事項

- ルールベースの変換の制限事項

- Oracle Streamsレプリケーションのキャラクタ・セットの制限事項

取得プロセスの制限事項

この項では、取得プロセスの制限事項について説明します。

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

- 取得プロセスではサポートされていないデータ型

- 取得プロセスではサポートされていない変更

- サプリメンタル・ロギング・データ型の制限事項

- ダウンストリーム取得の操作要件

- 取得プロセスではサポートされていないOracle Label Security

- Oracle Streams適用プロセスと取得プロセスの相互運用性

取得プロセスではサポートされていないデータ型

取得プロセスは、次のデータ型の列に対するDML変更の結果は取得しません。

- BFILE

- ROWID

- ユーザー定義型(オブジェクト型、REF、VARRAY、ネストした表など)

- オブジェクト・リレーショナルまたはバイナリXMLとして格納されているXMLType

- Oracle提供のAny型、URI型、空間型、メディア型

これらのデータ型の制限事項は、通常の(ヒープ構成)表および索引構成表の両方に適用されます。

取得プロセスでは、ソース・データベースの互換性レベルが11.2.0.0以上に設定されている場合のみ、SecureFiles LOB列への変更を取得できます。また、取得プロセスでは、重複除外を使用して格納されたSecureFiles LOB列への変更の取得、SecureFiles LOB列に対するフラグメントベースの操作によって生じた変更の取得、およびSecureFilesアーカイブ・マネージャ操作によって生じた変更の取得はサポートされていません。

取得プロセスで、サポートされていないデータ型の列へのDML変更に関して行LCRを作成しようとすると、エラーが発生します。エラーが発生すると、取得プロセスはエラーの原因となったLCRをトレース・ファイルに書き込み、ORA-26744エラーを生成した後で無効になります。この場合は、エラーを回避するように、取得プロセスで使用されるルールを変更してから、取得プロセスを再起動します。

拡張データ型をサポートするようにOracle Streamsを構成できます。手順については、Webブラウザを使用してMy Oracle Support (旧OracleMetaLink) Webサイトを参照してください。

http://support.oracle.com/

Oracle Streamsの拡張データ型のサポートについては、データベース掲示板556742.1で説明されています。

注意:
取得プロセスのネガティブ・ルール・セットに、サポートされていないデータ型の列を含む表への変更を廃棄するように取得プロセスに指示するルールを追加できます。ただし、これらのルールが単純なルールではない場合、取得プロセスは変更に対する行LCRを作成して、処理を続行することがあります。この場合、変更が取得プロセスで使用されるルール・セットの条件を満たさなくても、サポートされないデータ型を含む変更のために、取得プロセスでエラーが発生することがあります。DBMS_STREAMS_ADMパッケージでは単純なルールのみを作成できます。

関連項目:

- 「取得プロセスによって取得されるデータ型」

- 「取得プロセスと互換性のないデータベース・オブジェクトの表示」

- 単純ルールの詳細は、「単純ルール条件」を参照

- 「システム作成ルールとネガティブ・ルール・セット」

- 「取得プロセス・ルールの評価」

- データ型の詳細は、『Oracle Database SQL言語リファレンス』を参照

- SecureFiles LOB列に関するLogMinerの制限事項の詳細は、『Oracle Databaseユーティリティ』を参照

- データベースの互換性の詳細は、『Oracle Databaseアップグレード・ガイド』を参照

取得プロセスではサポートされていない変更

この項では、取得プロセスでサポートされていない変更について説明します。

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

- 取得プロセスではサポートされていないスキーマ

- 取得プロセスではサポートされていない表タイプ

- 取得プロセスではサポートされていないDDL変更

- 取得プロセスによって無視される変更

- SQL操作用のNOLOGGINGおよびUNRECOVERABLEキーワード

- ダイレクト・パス・ロード用のUNRECOVERABLE句

取得プロセスではサポートされていないスキーマ

取得プロセスでは、次のスキーマに対して行われた変更は取得されません。

- CTXSYS

- DBSNMP

- DMSYS

- DVSYS

- EXFSYS

- LBACSYS

- MDDATA

- MDSYS

- OLAPSYS

- ORDDATA

- ORDPLUGINS

- ORDSYS

- OUTLN

- SI_INFORMTN_SCHEMA

- SYS

- SYSMAN

- SYSTEM

- WMSYS

- XDB

取得プロセスではサポートされていない表タイプ

取得プロセスでは、一時表またはオブジェクト表に加えられたDML変更は取得できません。

注意:

- 基本表圧縮およびOLTP表圧縮によって圧縮された表に対する変更を取得プロセスで取得できるのは、ソース・データベースと取得データベースのどちらの互換性レベルも11.2.0.0.0以上に設定されている場合のみです。

- Oracle Database 11g リリース2 (11.2.0.2)以上の取得プロセスでは、次のすべての条件を満たす場合、ハイブリッド・コラム圧縮によって圧縮された表に対する変更を取得できます。その条件とは、ソース・データベースと取得データベースの両方でOracle Database 11g リリース2 (11.2.0.2)が実行されていること、およびソース・データベースと取得データベースのどちらの互換性レベルも11.2.0.0.0以上に設定されていることです。

関連項目:

- 「取得プロセスによって取得されるDML変更のタイプ」

- 「表へのDML変更の適用に関する考慮事項」

- 圧縮表の詳細は、『Oracle Database管理者ガイド』を参照

取得プロセスではサポートされていないDDL変更

取得プロセスでは、次のタイプのDDL変更を除き、ルール・セットを満たすDDL変更が取得されます。

- ALTER DATABASE

- CREATE CONTROLFILE

- CREATE DATABASE

- CREATE PFILE

- CREATE SPFILE

取得プロセスではDDL文を取得できますが、DDL文がCREATE TABLE AS SELECT文である場合を除き、DDL文の結果は取得できません。たとえば、取得プロセスでANALYZE文が取得される場合でも、ANALYZE文によって生成された統計は取得されません。ただし、取得プロセスでCREATE TABLE AS SELECT文が取得される場合は、この文自体と(INSERTの行LCRとして)選択されたすべての行が取得されます。

取得プロセスによって取得される一部のタイプのDDL変更は、適用プロセスでは適用できません。適用プロセスでは、適用できない操作を指定するDDL LCRを受信した場合、そのDDL LCRは無視され、そのDDL LCRに関する情報が適用プロセスのトレース・ファイルに記録されます。

構文にタイムスタンプまたはシステム変更番号(SCN)値が指定されたDDL変更が取得プロセスによって取得された場合は、この変更をデキューする適用プロセスのDDLハンドラを構成します。DDLハンドラは、タイムスタンプまたはSCN値を適切に処理する必要があります。たとえば、特定の表に対するDDL変更を取得するようにルール・セットで指定されている場合はFLASHBACK TABLE文が取得されます。FLASHBACK TABLE文の構文には、タイムスタンプまたはSCN値が指定されます。

関連項目:

- 適用プロセスによるDDL変更の適用の詳細は、「DDL変更を適用するときの考慮事項」を参照

- Oracle Streamsクライアントのルール・セット、およびメッセージがルール・セットを満たす仕組みの詳細は、第5章「Oracle Streamsでのルールの使用方法」を参照

取得プロセスによって無視される変更

取得プロセスでは、次のタイプの変更が無視されます。

- セッション制御文ALTER SESSIONおよびSET ROLE。

- システム制御文ALTER SYSTEM。

- CALL、EXPLAIN PLANおよびLOCK TABLE文。

- ビューに対するGRANT文。

- DBMS_REDEFINITIONパッケージを使用して、オンライン再定義によって表またはスキーマに対して行われた変更。取得プロセスが変更を取得する表では、オンラインで表を再定義できますが、表の論理構造は、オンライン再定義前とオンライン再定義後とで同一の構造である必要があります。

- 順序値の変更。たとえば、ユーザーがNEXTVALを参照するか、または順序を設定した場合、取得プロセスでは、これらの操作による変更は取得されません。また、複数のデータベースで順序を共有すると、これらのデータベースの個別の行で使用される順序値が異なる場合があります。

- PL/SQLプロシージャの起動。これは、PL/SQLプロシージャのコールが取得されないことを意味します。ただし、PL/SQLプロシージャのコールによってデータベース・オブジェクトが変更された場合は、それらの変更が取得プロセスのルール・セットを満たせば、取得プロセスでそれらの変更を取得できます。

注意:

- XMLに関連するOracle提供パッケージによってデータベース・オブジェクトが変更された場合、これらの変更は、取得プロセスによっては取得されません。XMLに関連するパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- Oracle Textに関連するOracle提供パッケージによってデータベース・オブジェクトが変更された場合、これらの変更は、取得プロセスによっては取得されません。Oracle Textに関連するパッケージの詳細は、『Oracle Textリファレンス』を参照してください。

関連項目:
様々なデータベースの異なる2つの行で順序生成値が同一になることを回避する方針の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

SQL操作用のNOLOGGINGおよびUNRECOVERABLEキーワード

SQL操作にNOLOGGINGまたはUNRECOVERABLEキーワードを使用した場合、取得プロセスではSQL操作によって発生する変更は取得できません。したがって、SQL操作によって発生する変更を取得するために、これらのキーワードを使用しないでください。

ロギング属性を指定しているオブジェクトがFORCE LOGGINGモードのデータベースまたは表領域に存在する場合、Oracle Databaseでは、そのデータベースまたは表領域がFORCE LOGGINGモードでなくなるまでNOLOGGINGまたはUNRECOVERABLE設定は無視されます。データベースの現行のロギング・モードを判別するには、V$DATABASE動的パフォーマンス・ビューのFORCE_LOGGING列を問い合せます。表領域の現在のロギング・モードを判別するには、DBA_TABLESPACES静的データ・ディクショナリ・ビューのFORCE_LOGGING列を問い合せます。

注意:
UNRECOVERABLEキーワードは非推奨のため、logging_clauseではNOLOGGINGキーワードに置き換えられています。UNRECOVERABLEは下位互換性用にサポートされていますが、可能な場合はNOLOGGINGキーワードを使用することを強くお薦めします。

関連項目:
NOLOGGINGキーワード、UNRECOVERABLEキーワード、FORCE LOGGINGモードおよびlogging_clauseの詳細は、『Oracle Database SQL言語リファレンス』を参照

ダイレクト・パス・ロード用のUNRECOVERABLE句

ダイレクト・パス・ロードでSQL*Loader制御ファイルにUNRECOVERABLE句を使用した場合、ダイレクト・パス・ロードによって発生する変更を取得プロセスでは取得できません。したがって、ダイレクト・パス・ロードによって発生する変更を取得プロセスで取得する必要がある場合は、UNRECOVERABLE句を使用しないでください。

ソース・データベースで変更を記録せずにダイレクト・パス・ロードを実行し、ソース・データベースの宛先データベースで同様のダイレクト・パス・ロードを実行しない場合、ソース・データベースのロード済オブジェクトに対して変更が行われると、これらの宛先データベースで適用エラーが発生することがあります。この場合、ソース・データベースの取得プロセスによってこれらのオブジェクトに対する変更を取得し、1つ以上の伝播によってそれらの変更を宛先データベースに伝播できます。適用プロセスによってこれらの変更の適用が試行された場合、変更されたオブジェクトとそのオブジェクト内の変更された行が宛先データベースに存在していないと、エラーが発生します。

したがって、ダイレクト・パス・ロードでUNRECOVERABLE句を使用し、ロード済オブジェクトに対する変更を取得するように取得プロセスが構成されている場合は、適用エラーを回避するために、すべての宛先データベースにロード済オブジェクトとロード済データが含まれていることを確認してください。宛先データベースにこれらのオブジェクトが存在するかどうかを確認する方法の1つとして、ソース・データベースで実行したダイレクト・パス・ロードと同様のダイレクト・パス・ロードを、これらの宛先データベースそれぞれで実行する方法があります。

FORCE LOGGINGモードのデータベースまたは表領域にオブジェクトをロードする場合、Oracle Databaseでは、ダイレクト・パス・ロード時にすべてのUNRECOVERABLE句が無視され、ロードされた変更が記録されます。データベースの現行のロギング・モードを判別するには、V$DATABASE動的パフォーマンス・ビューのFORCE_LOGGING列を問い合せます。表領域の現在のロギング・モードを判別するには、DBA_TABLESPACES静的データ・ディクショナリ・ビューのFORCE_LOGGING列を問い合せます。

関連項目:
ダイレクト・パス・ロードおよびSQL*Loaderの詳細は、『Oracle Databaseユーティリティ』を参照

サプリメンタル・ロギング・データ型の制限事項

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

関連項目:

- 『Oracle Streamsレプリケーション管理者ガイド』

- データ型の詳細は、『Oracle Database SQL言語リファレンス』を参照

ダウンストリーム取得の操作要件

ダウンストリーム取得を使用する場合の操作要件は次のとおりです。

- ソース・データベースでOracle Database 10g以上が実行されており、ダウンストリーム取得データベースで、ソース・データベースのリリース以上のOracle Databaseが実行されている必要があります。

- リアルタイム・ダウンストリーム取得を構成するには、ダウンストリーム・データベースでOracle Database 10gリリース2以上が実行されている必要があります。この場合、ソース・データベースでOracle Database 10gリリース1以上が実行されている必要があります。

- ソース・サイトおよびダウンストリーム取得サイトのオペレーティング・システムは同じである必要があります。ただし、オペレーティング・システムのリリースが同じである必要はありません。また、ダウンストリーム・サイトでは、ソース・サイトと異なるディレクトリ構造を使用できます。

- ソース・サイトおよびダウンストリーム取得サイトのハードウェア・アーキテクチャが同じである必要があります。たとえば、ダウンストリーム取得構成では、ソース・データベースが32ビットのSunシステム上に構成されている場合、ダウンストリーム・データベースが32ビットのSunシステム上に構成されている必要があります。CPUの数、メモリー・サイズ、記憶域構成などのその他のハードウェア要素は、ソース・サイトとダウンストリーム・サイトで同じである必要はありません。

関連項目:
「ローカル取得およびダウンストリーム取得」

取得プロセスではサポートされていないOracle Label Security

取得プロセスでは、Oracle Label Security(OLS)を使用するデータベース・オブジェクトはサポートされません。

関連項目:
『Oracle Label Security管理者ガイド』

Oracle Streams適用プロセスと取得プロセスの相互運用性

Oracle Database 11g リリース2 (11.2)の適用プロセスによって処理される変更を取得する場合、取得プロセスはOracle9i Databaseリリース9.2.0.6以上である必要があります。取得プロセスのリリースにおけるデータ型の制限事項は、取得プロセスのソース・データベースで適用されます。

関連項目:
以前のリリースでの取得プロセスと適用プロセスのデータ型の制限事項については、そのOracle DatabaseリリースのOracle Streamsのマニュアルを参照

同期取得の制限事項

この項では、同期取得の制限事項について説明します。

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

- 表ルールのみを使用する同期取得

- 同期取得ではサポートされていないデータ型

- 同期取得ではサポートされていない変更

- 同期取得ルールおよびDBMS_STREAMS_ADMパッケージ

- 同期取得ではサポートされていないOracle Label Security

表ルールのみを使用する同期取得

同期取得は、DBMS_STREAMS_ADMパッケージ内のプロシージャで作成された表ルールのみを使用します。同期取得は、スキーマ・ルール、グローバル・ルール、およびDBMS_RULE_ADMパッケージ内のプロシージャで作成されたルールを無視します。

関連項目:
「同期取得のルール」

同期取得ではサポートされていないデータ型

同期取得は、次のデータ型の列に対するDML変更の結果は取得しません。

- LONG

- LONG RAW

- CLOB

- NCLOB

- BLOB

- BFILE

- ROWID

- ユーザー定義型(オブジェクト型、REF、VARRAY、ネストした表など)

- Oracle提供の型(Any型、XML型、空間型、メディア型など)

これらのデータ型の制限事項は、通常の(ヒープ構成)表および索引構成表の両方に適用されます。

同期取得では、サポートされていないデータ型の列が含まれている表に対するDML変更に対して行LCRを作成しようとすると、エラーが発生します。ユーザーにORA-25341エラーが戻され、DML変更は行われません。エラーが発生しないようにするには、同期取得で使用されるルールを変更します。

注意:

- 同期取得で取得される変更のタイプは、ポジティブ・ルール・セットのルールによって決定されます。エラーが発生しないようにするには、サポートされていないデータ型の表に対する変更が同期取得で取得されないようにこれらのルールが指定されていることを確認します。

- サポートされていない列が含まれている表に対する変更を取得できるように同期取得を構成することもできます。この場合は、関連する同期取得ルールにDELETE_COLUMN宣言ルールベースの変換を指定して、サポートされていない列を削除します。

関連項目:

- 同期取得によって取得されるデータ型

- 「同期取得と互換性のないデータベース・オブジェクトおよび列の表示」

- Oracle Streamsクライアントのルール・セット、およびメッセージがルール・セットを満たす仕組みの詳細は、第5章「Oracle Streamsでのルールの使用方法」を参照

- 「宣言ルールベースの変換」

- データ型の詳細は、『Oracle Database SQL言語リファレンス』を参照

同期取得ではサポートされていない変更

この項では、同期取得でサポートされていない変更について説明します。

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

- 同期取得ではサポートされていないスキーマ

- 同期取得ではサポートされていない表タイプ

- 同期取得によって無視される変更

同期取得ではサポートされていないスキーマ

同期取得では、次のスキーマに対して行われた変更は取得されません。

- CTXSYS

- DBSNMP

- DMSYS

- DVSYS

- EXFSYS

- LBACSYS

- MDDATA

- MDSYS

- OLAPSYS

- ORDDATA

- ORDPLUGINS

- ORDSYS

- OUTLN

- SI_INFORMTN_SCHEMA

- SYS

- SYSMAN

- SYSTEM

- WMSYS

- XDB

同期取得ではサポートされていない表タイプ

同期取得では、一時表、オブジェクト表またはハイブリッド列圧縮によって圧縮された表に加えられたDML変更は取得できません。

注意:
基本表圧縮またはOLTP表圧縮によって圧縮された表に対する変更を同期取得で取得できるのは、データベースの互換性レベルが11.2.0.0.0以上に設定されている場合です。

関連項目:

- 「同期取得によって取得されるDML変更のタイプ」

- 「表へのDML変更の適用に関する考慮事項」

同期取得によって無視される変更

同期取得によって無視される変更のタイプは次のとおりです。

- DDL変更。

- セッション制御文ALTER SESSIONおよびSET ROLE。

- システム制御文ALTER SYSTEM。

- 同期取得では、CALL、EXPLAIN PLANまたはLOCK TABLE文は無視されます。

- ダイレクト・パス・ロードによって行われた変更。

- DBMS_REDEFINITIONパッケージを使用して、オンライン再定義によって表またはスキーマに対して行われた変更。同期取得が変更を取得する表では、オンラインで表を再定義できますが、表の論理構造は、オンライン再定義前とオンライン再定義後とで同一の構造である必要があります。

- 実際の順序値の変更。たとえば、ユーザーがNEXTVALを参照するか、または順序を設定した場合、同期取得では、これらの操作による変更は取得されません。また、複数のデータベースで順序を共有すると、これらのデータベースの個別の行で使用される順序値が異なる場合があります。

- PL/SQLプロシージャの起動。これは、PL/SQLプロシージャのコールが取得されないことを意味します。ただし、PL/SQLプロシージャのコールによってデータベース・オブジェクトが変更された場合は、それらの変更が同期取得のルール・セットを満たせば、同期取得でそれらの変更を取得できます。

注意:

- XMLに関連するOracle提供パッケージによって、データベース・オブジェクトが変更された場合、これらの変更は、同期取得によっては取得されません。XMLに関連するパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- Oracle Textに関連するOracle提供パッケージによってデータベース・オブジェクトが変更された場合、これらの変更は、同期取得によっては取得されません。Oracle Textに関連するパッケージの詳細は、『Oracle Textリファレンス』を参照してください。

関連項目:
様々なデータベースの異なる2つの行で順序生成値が同一になることを回避する方針の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

同期取得ルールおよびDBMS_STREAMS_ADMパッケージ

DBMS_RULE_ADMパッケージを使用して同期取得のルール・セットを作成できますが、同期取得の動作はDBMS_STREAMS_ADMパッケージを使用して作成されたルールのみによって決定されます。同期取得ではDBMS_RULE_ADMパッケージによって作成されたルールは無視されます。

同期取得ではサポートされていないOracle Label Security

同期取得では、Oracle Label Security(OLS)を使用するデータベース・オブジェクトはサポートされません。

関連項目:
『Oracle Label Security管理者ガイド』

キューの制限事項

この項では、キューの制限事項について説明します。

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

- ANYDATAキューの明示的エンキューの制限事項

- バッファ・メッセージ機能の制限事項

- トリガーおよびキュー表

関連項目:
「キュー」

ANYDATAキューの明示的エンキューの制限事項

次の型のペイロードを含むANYDATAペイロードはANYDATAキューに明示的にエンキューできません。

- CLOB

- NCLOB

- BLOB

- LOB属性を含むオブジェクト型

- 型進化または型継承を使用するオブジェクト型

注意:
ROWIDデータ型のペイロードはANYDATAラッパーでラップできません。この制約はUROWIDデータ型のペイロードには適用されません。

関連項目:

- 「ANYDATAキューおよび型付きキュー」

- ANYDATAラッパーでのペイロードのラップ、ANYDATAキューへのメッセージのエンキューおよびデキューのためのプログラム的な環境、伝播およびユーザー定義型など、ANYDATAキューの関連情報については、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドを参照

- ANYDATAタイプの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

- データ型の詳細は、『Oracle Database SQL言語リファレンス』を参照

バッファ・メッセージ機能の制限事項

バッファ・メッセージ機能を使用するには、Oracle Databaseの互換性レベルが10.2.0以上である必要があります。

DBMS_STREAMS_MESSAGINGパッケージを使用して、バッファ・キューへのメッセージのエンキューおよびバッファ・キューからのメッセージのデキューを行うことはできません。ただし、DBMS_AQパッケージではバッファ・メッセージのエンキューとデキューがサポートされています。

関連項目:

- 「永続キューおよびバッファ・キュー」

- DBMS_AQパッケージの詳細は、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドを参照してください。

トリガーおよびキュー表

パフォーマンスに悪影響を与える可能性があるので、キュー表でのトリガーの使用はお薦めしません。索引構成キュー表でのトリガーもサポートされていません。

伝播の制限事項

この項では、伝播の制限事項について説明します。

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

- 接続修飾子および伝播

- 伝播のキャラクタ・セットの制限事項

- キュー・ツー・キュー伝播の互換性要件

関連項目:
「キュー間でのメッセージの伝播」

接続修飾子および伝播

Oracle Streams伝播で使用されるデータベース・リンクに接続修飾子を指定することはできません。

伝播のキャラクタ・セットの制限事項

伝播によって、オブジェクト型、VARRAYまたはネストした表のペイロードをカプセル化したANYDATAメッセージをデータベース間で伝播できるのは、それらのデータベースで同じキャラクタ・セットを使用している場合のみです。

伝播では、同じキャラクタ・セットまたは異なるキャラクタ・セットのデータベース間で論理変更レコード(LCR)を伝播できます。

キュー・ツー・キュー伝播の互換性要件

キュー・ツー・キュー伝播を使用するには、伝播が行われるキューを含む各データベースの互換レベルが10.2.0以上であることが必要です。

関連項目:
「キュー・ツー・キュー伝播」

適用プロセスの制限事項

この項では、適用プロセスの制限事項について説明します。

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

- 適用プロセスではサポートされていないデータ型

- 適用ハンドラではサポートされていないデータ型

- 適用プロセスによって無視されるDDL変更のタイプ

- Oracle Streams環境におけるデータベース構造

- 宛先データベースに存在する必要がある現行スキーマ・ユーザー

- 適用プロセスではサポートされていないOracle Label Security

- Oracle Streams取得コンポーネントと適用プロセスの相互運用性

適用プロセスではサポートされていないデータ型

適用プロセスは、次のデータ型の列にはDML変更の結果を含む行LCRを適用しません。

- BFILE

- ROWID

- ユーザー定義型(オブジェクト型、REF、VARRAY、ネストした表など)

- Oracle提供のAny型、URI型、空間型、メディア型

サポートされていないデータ型の列に関する情報を含む行LCRを適用しようとすると、適用プロセスにエラーが発生します。また、適用プロセスでは、一時表またはオブジェクト表に対するDML変更を適用できません。このような変更を適用しようとすると、適用プロセスにエラーが発生します。適用プロセスでは、LCRのエラーが発生すると、LCRを含むトランザクションがエラー・キューに移動されます。

これらのデータ型の制限事項は、通常の(ヒープ構成)表および索引構成表の両方に適用されます。

拡張データ型をサポートするようにOracle Streamsを構成できます。手順については、Webブラウザを使用してMy Oracle Support (旧OracleMetaLink) Webサイトを参照してください。

http://support.oracle.com/

Oracle Streamsの拡張データ型のサポートについては、データベース掲示板556742.1で説明されています。

関連項目:
「適用されるデータ型」

適用ハンドラではサポートされていないデータ型

文DMLハンドラでは、行LCRのLONG、LONG RAWまたはアセンブルされていないLOB列データは処理できません。ただし、文DMLハンドラでは、LOBアセンブリで構築された行LCRのLOB列データは処理できます。LOBアセンブリは、文DMLハンドラに対してデフォルトで有効になっています。

プロシージャDMLハンドラおよびエラー・ハンドラでは、行LCRのLONGまたはLONG RAWの列データは処理できません。ただし、プロシージャDMLハンドラおよびエラー・ハンドラでは、行LCRのアセンブルされていないLOB列データとアセンブルされたLOB列データの両方を処理できますが、アセンブルされていないLOB列データは変更できません。

関連項目:

- 「適用プロセスのメッセージ処理オプション」

- LOBアセンブリの詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- データ型の詳細は、『Oracle Database SQL言語リファレンス』を参照

適用プロセスによって無視されるDDL変更のタイプ

次のタイプのDDL変更は、適用プロセスでサポートされていません。これらのタイプのDDL変更は、適用されません。

- ALTER MATERIALIZED VIEW

- ALTER MATERIALIZED VIEW LOG

- CREATE DATABASE LINK

- CREATE SCHEMA AUTHORIZATION

- CREATE MATERIALIZED VIEW

- CREATE MATERIALIZED VIEW LOG

- DROP DATABASE LINK

- DROP MATERIALIZED VIEW

- DROP MATERIALIZED VIEW LOG

- FLASHBACK DATABASE

- RENAME

適用プロセスでは、適用できない操作を指定するDDL LCRを受信した場合、そのDDL LCRは無視され、無視されたDDLテキストの後に次のメッセージが適用プロセスのトレース・ファイルに記録されます。

Apply process ignored the following DDL:

適用プロセスのルール・セットに従って、変更を含むDDL LCRが適用される必要がある場合、適用プロセスは、その他のすべてのタイプのDDL変更を適用します。

注意:

- 適用プロセスは、ALTER TABLE jobs RENAMEなど、ALTER object_type object_name RENAME変更を適用します。したがって、オブジェクトの名前を変更するDDL変更を適用する場合は、RENAME文のかわりにALTER object_type object_name RENAME文を使用します。データベース・オブジェクトの名前を変更した後、そのデータベース・オブジェクトに対する変更をレプリケートするには、新しいデータベース・オブジェクト名を指定する新しいルールが必要になる場合があります。

- マテリアライズド・ビューとは、スナップショットの同義語です。マテリアライズド・ビューでの文に相当するスナップショットは、適用プロセスで無視されます。

関連項目:
第5章「Oracle Streamsでのルールの使用方法」

Oracle Streams環境におけるデータベース構造

取得されたDDL変更が宛先データベースで適切に適用されるためには、宛先データベースの構造がソース・データベースと同じであるか、DDL文に指定されているデータベース構造情報が同じである必要があります。データベース構造には、データファイル、表領域、ロールバック・セグメントと、データベース・オブジェクトをサポートするその他の物理構造および論理構造が含まれます。

たとえば、表に対して取得されたDDL変更が宛先データベースで適切に適用されるためには、次の条件を満たす必要があります。

- CREATE TABLE文には、ソース・データベースおよび宛先データベースで同じ記憶域パラメータを指定する必要があります。

- DDL文が特定の表領域またはロールバック・セグメントを参照する場合、その表領域またはロールバック・セグメントには、ソース・データベースおよび宛先データベースで同じ名前および同じ互換性の指定が必要です。
ただし、表領域およびロールバック・セグメントがDDL文に指定されていない場合は、デフォルトの表領域およびロールバック・セグメントが使用されます。この場合、表領域およびロールバック・セグメントは、ソース・データベースと宛先データベースで異なることがあります。

- ソース・データベースおよび宛先データベースで同じパーティションの指定が使用される必要があります。

宛先データベースに存在する必要がある現行スキーマ・ユーザー

DDL LCRが宛先データベースで正常に適用されるためには、DDL LCRのcurrent_schemaとして指定されるユーザーは、宛先データベースに存在する必要があります。現行スキーマは、DDLテキストでオブジェクトにスキーマが指定されていない場合に使用されるスキーマです。

関連項目:

- データベース構造の詳細は、『Oracle Database概要』を参照

- DDL LCRのcurrent_schema属性の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

適用プロセスではサポートされていないOracle Label Security

適用プロセスでは、Oracle Label Security(OLS)を使用するデータベース・オブジェクトはサポートされません。

関連項目:
『Oracle Label Security管理者ガイド』

Oracle Streams取得コンポーネントと適用プロセスの相互運用性

Oracle Database 11g リリース2 (11.2)の取得プロセスで取得される変更を処理する場合、適用プロセスはOracle9i Databaseリリース9.2.0.6以上である必要があります。適用プロセスのリリースにおけるデータ型の制限事項は、適用プロセス・データベースで適用されます。

Oracle Database 11g リリース2(11.2)の同期取得で取得される変更を処理する場合、適用プロセスはOracle Database 11g リリース1(11.1)以上である必要があります。適用プロセスのリリースにおけるデータ型の制限事項は、適用プロセス・データベースで適用されます。

関連項目:
以前のリリースでの適用プロセスのデータ型の制限事項については、そのOracle DatabaseリリースのOracle Streamsのマニュアルを参照してください。

メッセージ・クライアントの制限事項

この項では、メッセージ・クライアントの制限事項について説明します。

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

- メッセージ・クライアントおよびバッファ・メッセージ

関連項目:
「メッセージ・クライアントによる明示的コンシューム」

メッセージ・クライアントおよびバッファ・メッセージ

メッセージ・クライアントはバッファ・メッセージをデキューできません。ただし、DBMS_AQパッケージではバッファ・メッセージのエンキューとデキューがサポートされています。

関連項目:
DBMS_AQパッケージの詳細は、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドを参照してください。

ルールの制限事項

この項では、ルールの制限事項について説明します。

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

- サブセット・ルールの制限

- アクション・コンテキストの制限事項

サブセット・ルールの制限

サブセット・ルールには次の制限が適用されます。

- サブセット・ルールで参照される表名の表が、サブセット・ルールと同じデータベースに存在する必要があります。また、この表は、サブセット・ルールで表に関して参照されるスキーマと同じスキーマに存在する必要があります。

- サブセット・ルールが取得プロセスまたは同期取得のポジティブ・ルール・セットに含まれる場合、表には、サブセット条件で指定した列が含まれている必要があります。これらの各列のデータ型はソース・データベースの対応する列のデータ型と一致する必要があります。

- サブセット・ルールが伝播または適用プロセスのポジティブ・ルール・セットに含まれる場合、表には、サブセット条件で指定した列が含まれている必要があります。各列のデータ型は、サブセット・ルールでTRUEと評価された行LCRの対応する列のデータ型と一致する必要があります。

- LOB、LONG、LONG RAW、ユーザー定義型(オブジェクト型、REF、VARRAY、ネストした表など)およびOracle提供の型(Any型、XML型、空間型、メディア型など)のデータ型の列が1つ以上存在する表に対してサブセット・ルールを作成することはできません。

関連項目:

- 「サブセット・ルール」

- データ型の詳細は、『Oracle Database SQL言語リファレンス』を参照

アクション・コンテキストの制限事項

アクション・コンテキストには、次のデータ型の情報を含めることはできません。

- CLOB

- NCLOB

- BLOB

- LONG

- LONG RAW

また、アクション・コンテキストには、これらのデータ型の属性を持つオブジェクト型、および型進化や型継承を使用するオブジェクト型を含めることはできません。

関連項目:
「Oracle Streamsとアクション・コンテキスト」

ルールベースの変換の制限事項

この項では、ルールベースの変換の制限事項について説明します。

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

- 宣言ルールベースの変換ではサポートされていないデータ型

- カスタム・ルールベースの変換ではサポートされていないデータ型

関連項目:
第6章「ルールベースの変換」

宣言ルールベースの変換ではサポートされていないデータ型

列の追加の変換を除き、列に対して実行される宣言ルールベースの変換では、Oracle Streamsの取得プロセスでサポートされているものと同じデータ型がサポートされています。

列の追加の変換では、BLOB、CLOB、NCLOB、BFILE、LONG、LONG RAW、ROWID、ユーザー定義型(オブジェクト型、REF、VARRAY、ネストした表など)およびOracle提供の型(Any型、XML型、空間型、メディア型など)のデータ型の列は追加できません。

関連項目:

- 「取得プロセスによって取得されるデータ型」

- 「取得プロセスではサポートされていないデータ型」

カスタム・ルールベースの変換ではサポートされていないデータ型

LONG、LONG RAW、アセンブルされていないLOB列データまたはXMLTypeデータは、カスタム・ルールベースの変換ファンクションでは変更しないでください。

関連項目:
「カスタム・ルールベースの変換」

Oracle Streamsレプリケーションのキャラクタ・セットの制限事項

Oracle Streamsレプリケーション構成では、宛先データベースのキャラクタ・セットは、ソース・データベースのキャラクタ・セットと互換性があるか、そのスーパーセットである必要があります。また、データの整合性を保証するためには、データ・コンテンツの文字レパートリがソース・データベースと宛先データベースの両方のキャラクタ・セットでサポートされている必要があります。

関連項目:

- キャラクタ・セットと文字レパートリを選択する方法の詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照

- キャラクタ・セットのスーパーセットの詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照

C LCR用のXMLスキーマ

この付録で説明するXMLスキーマでは、論理変更レコード(LCR)のフォーマットが定義されます。LCR用のXMLスキーマを使用するには、Oracle XML DBをインストールする必要があります。

このスキーマ用の名前空間は次のとおりです。

http://xmlns.oracle.com/streams/schemas/lcr

スキーマは次のとおりです。

http://xmlns.oracle.com/streams/schemas/lcr/streamslcr.xsd

LCR用のXMLスキーマ定義

LCR用のXMLスキーマ定義は、次のとおりです。

'<schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://xmlns.oracle.com/streams/schemas/lcr"
xmlns:lcr="http://xmlns.oracle.com/streams/schemas/lcr"
xmlns:xdb="http://xmlns.oracle.com/xdb"
version="1.0"
elementFormDefault="qualified">

<simpleType name = "short_name">
<restriction base = "string">
<maxLength value="30"/>
</restriction>
</simpleType>

<simpleType name = "long_name">
<restriction base = "string">
<maxLength value="4000"/>
</restriction>
</simpleType>

<simpleType name = "db_name">
<restriction base = "string">
<maxLength value="128"/>
</restriction>
</simpleType>

<!-- Default session parameter is used if format is not specified -->
<complexType name="datetime_format">
<sequence>
<element name = "value" type = "string" nillable="true"/>
<element name = "format" type = "string" minOccurs="0" nillable="true"/>
</sequence>
</complexType>

<complexType name="anydata">
<choice>
<element name="varchar2" type = "string" xdb:SQLType="CLOB"
nillable="true"/>

<!-- Represent char as varchar2. xdb:CHAR blank pads upto 2000 bytes! -->
<element name="char" type = "string" xdb:SQLType="CLOB"
nillable="true"/>
<element name="nchar" type = "string" xdb:SQLType="NCLOB"
nillable="true"/>

<element name="nvarchar2" type = "string" xdb:SQLType="NCLOB"
nillable="true"/>
<element name="number" type = "double" xdb:SQLType="NUMBER"
nillable="true"/>
<element name="raw" type = "hexBinary" xdb:SQLType="BLOB"
nillable="true"/>
<element name="date" type = "lcr:datetime_format"/>
<element name="timestamp" type = "lcr:datetime_format"/>
<element name="timestamp_tz" type = "lcr:datetime_format"/>
<element name="timestamp_ltz" type = "lcr:datetime_format"/>

<!-- Interval YM should be as per format allowed by SQL -->
<element name="interval_ym" type = "string" nillable="true"/>

<!-- Interval DS should be as per format allowed by SQL -->
<element name="interval_ds" type = "string" nillable="true"/>

<element name="urowid" type = "string" xdb:SQLType="VARCHAR2"
nillable="true"/>
</choice>
</complexType>

<complexType name="column_value">
<sequence>
<element name = "column_name" type = "lcr:long_name" nillable="false"/>
<element name = "data" type = "lcr:anydata" nillable="false"/>
<element name = "lob_information" type = "string" minOccurs="0"
nillable="true"/>
<element name = "lob_offset" type = "nonNegativeInteger" minOccurs="0"
nillable="true"/>
<element name = "lob_operation_size" type = "nonNegativeInteger"
minOccurs="0" nillable="true"/>
<element name = "long_information" type = "string" minOccurs="0"
nillable="true"/>
</sequence>
</complexType>

<complexType name="extra_attribute">
<sequence>
<element name = "attribute_name" type = "lcr:short_name"/>
<element name = "attribute_value" type = "lcr:anydata"/>
</sequence>
</complexType>

<element name = "ROW_LCR" xdb:defaultTable="">
<complexType>
<sequence>
<element name = "source_database_name" type = "lcr:db_name"
nillable="false"/>
<element name = "command_type" type = "string" nillable="false"/>
<element name = "object_owner" type = "lcr:short_name"
nillable="false"/>
<element name = "object_name" type = "lcr:short_name"
nillable="false"/>
<element name = "tag" type = "hexBinary" xdb:SQLType="RAW"
minOccurs="0" nillable="true"/>
<element name = "transaction_id" type = "string" minOccurs="0"
nillable="true"/>
<element name = "scn" type = "double" xdb:SQLType="NUMBER"
minOccurs="0" nillable="true"/>
<element name = "old_values" minOccurs = "0">
<complexType>
<sequence>
<element name = "old_value" type="lcr:column_value"
maxOccurs = "unbounded"/>
</sequence>
</complexType>
</element>
<element name = "new_values" minOccurs = "0">
<complexType>
<sequence>
<element name = "new_value" type="lcr:column_value"
maxOccurs = "unbounded"/>
</sequence>
</complexType>
</element>
<element name = "extra_attribute_values" minOccurs = "0">
<complexType>
<sequence>
<element name = "extra_attribute_value"
type="lcr:extra_attribute"
maxOccurs = "unbounded"/>
</sequence>
</complexType>
</element>
</sequence>
</complexType>
</element>

<element name = "DDL_LCR" xdb:defaultTable="">
<complexType>
<sequence>
<element name = "source_database_name" type = "lcr:db_name"
nillable="false"/>
<element name = "command_type" type = "string" nillable="false"/>
<element name = "current_schema" type = "lcr:short_name"
nillable="false"/>
<element name = "ddl_text" type = "string" xdb:SQLType="CLOB"
nillable="false"/>
<element name = "object_type" type = "string"
minOccurs = "0" nillable="true"/>
<element name = "object_owner" type = "lcr:short_name"
minOccurs = "0" nillable="true"/>
<element name = "object_name" type = "lcr:short_name"
minOccurs = "0" nillable="true"/>
<element name = "logon_user" type = "lcr:short_name"
minOccurs = "0" nillable="true"/>
<element name = "base_table_owner" type = "lcr:short_name"
minOccurs = "0" nillable="true"/>
<element name = "base_table_name" type = "lcr:short_name"
minOccurs = "0" nillable="true"/>
<element name = "tag" type = "hexBinary" xdb:SQLType="RAW"
minOccurs = "0" nillable="true"/>
<element name = "transaction_id" type = "string"
minOccurs = "0" nillable="true"/>
<element name = "scn" type = "double" xdb:SQLType="NUMBER"
minOccurs = "0" nillable="true"/>
<element name = "extra_attribute_values" minOccurs = "0">
<complexType>
<sequence>
<element name = "extra_attribute_value"
type="lcr:extra_attribute"
maxOccurs = "unbounded"/>
</sequence>
</complexType>
</element>
</sequence>
</complexType>
</element>
</schema>';

D Oracle Streamsを使用したオンラインでのデータベースのアップグレードおよびメンテナンス

この付録では、Oracle Streamsを使用して、データベースを次のいずれかのOracle Databaseリリースから現在のリリースにアップグレードする方法について説明します。

- Oracle Database 10g リリース2(10.2)

- Oracle Database 11g リリース1 (11.1)

また、この付録では、Oracle Streamsを使用してOracle Database 11g リリース2 (11.2)データベースにいくつかのメンテナンス操作を実行する方法についても説明します。これらのメンテナンス操作には、異なるプラットフォームまたはキャラクタ・セットへのOracle Databaseの移行、ユーザー作成アプリケーションのアップグレードおよびOracle Databaseパッチまたはパッチ・セットの適用が含まれます。

この付録で説明するアップグレードおよびメンテナンス操作では、わずかな停止時間または停止時間なしでデータベースを操作するために、Oracle Streamsの機能を使用します。

次の項では、Oracle Streamsを使用したオンラインでのデータベースのメンテナンスについて説明します。

- Oracle Streamsを使用したアップグレードおよびメンテナンス操作の概要

- データベースのアップグレードまたはメンテナンス操作の準備

- Oracle Streamsを使用したデータベースのアップグレードまたはメンテナンス操作の実行

関連項目:
Oracle Database 10g リリース2 (10.2)より前のリリースをアップグレードする手順については、付録E「Oracle Streamsを使用した10.1以下のデータベースのオンラインでのアップグレード」を参照

Oracle Streamsを使用したアップグレードおよびメンテナンス操作の概要

データベースをアップグレードするには、データベースを長時間停止する必要がある場合があります。また、通常、次のメンテナンス操作を実行するには、データベースを長時間停止する必要があります。

- 異なるプラットフォームへのデータベースの移行

- 異なるキャラクタ・セットへのデータベースの移行

- ユーザー作成アプリケーションにアップグレードするためのデータベース・スキーマ・オブジェクトの変更

- Oracle Databaseソフトウェア・パッチまたはパッチ・セットの適用

Oracle Streamsの機能を使用することで、わずかな停止時間または停止時間なしで、これらのアップグレードおよびメンテナンス操作を実行できます。そのためには、Oracle Streamsを使用して、次のデータベースを含むレプリケーション環境を構成します。

- ソース・データベース: メンテナンス対象の元のデータベース。

- 取得データベース: メンテナンス操作中にソース・データベースに対して行われた変更が取得プロセスによって取得されるデータベース。

- 宛先データベース: メンテナンス操作中にソース・データベースに対して行われた変更が適用プロセスによって適用されるソース・データベースのコピー。

次の一般的な手順で、データベースがオンラインの状態でアップグレードまたはメンテナンス操作を実行できます。

1. 空の宛先データベースを作成します。

2. Oracle Streamsのレプリケーション環境を構成します。その環境では、元のデータベースがソース・データベースで、データベースのコピーが宛先データベースです。DBMS_STREAMS_ADMパッケージのPRE_INSTANTIATION_SETUPおよびPOST_INSTANTIATION_SETUPプロシージャで、Oracle Streamsレプリケーション環境を構成します。

3. 宛先データベースに対してアップグレードまたはメンテナンス操作を実行します。このとき、元のソース・データベースはオンラインで使用可能です。元のソース・データベースに対する変更は、取得プロセスによって取得されます。

4. Oracle Streamsを使用して、ソース・データベースで行われた変更を宛先データベースに適用します。

5. ソース・データベースで行われた変更を宛先データベースに適用した後、ソース・データベースをオフラインにして、アプリケーションおよびユーザーが宛先データベースを使用できるようにします。

図D-1に、このプロセスの概要を示します。

図D-1 Oracle Streamsを使用したオンラインでのデータベースのアップグレードおよびメンテナンス

アップグレードまたはメンテナンス操作中の取得データベース

アップグレードまたはメンテナンス操作中に取得プロセスが作成されるデータベースが、取得データベースです。メンテナンス操作中にソース・データベースにローカル取得プロセスを作成するか、あるいは宛先データベースまたは第3のデータベースにダウンストリーム取得プロセスを作成できます。宛先データベースが取得データベースである場合、取得データベースから宛先データベースへの伝播は不要です。ダウンストリーム取得プロセスを使用すると、メンテナンス操作中にソース・データベースに必要なリソースが削減されます。

注意:

- Oracle Streamsを使用したデータベースのアップグレードまたはメンテナンス操作を開始する前に、取得データベースとするデータベースを決定してください。

- RMANのDUPLICATEまたはCONVERT DATABASEコマンドを使用してデータベースのインスタンス化を行う場合、宛先データベースを取得データベースとすることはできません。

関連項目:

- 「ローカル取得およびダウンストリーム取得」

- 「インスタンス化で使用するユーティリティの決定」

アップグレードまたはメンテナンス対象のデータベースの前提条件

この付録で説明する手順は、アップグレードまたはメンテナンス対象のデータベースが次のすべての条件を満たしていることを前提としています。

- データベースは、既存のOracle Streams環境に含まれない。

- データベースは、既存のロジカル・スタンバイ環境に含まれない。

- データベースは、既存のAdvanced Replication環境に含まれない。

- データベースには、他のデータベースのマテリアライズド・ビューのマスター表である表は存在しない。

- アップグレードまたはメンテナンス操作中、メッセージはユーザー作成キューにエンキューされない。

ジョブ・スレーブおよびPL/SQLパッケージのサブプログラムに関する考慮事項

可能であれば、アップグレードまたはメンテナンス操作中にジョブ・スレーブを作成、変更または削除しないでください。また、メンテナンス操作中は、ユーザー・データとデータ・ディクショナリ・メタデータを同時に変更するOracle提供のPL/SQLパッケージのサブプログラムを起動しないでください。DBMS_RLS、DBMS_STATSおよびDBMS_JOBパッケージには、ユーザー・データとデータ・ディクショナリ・メタデータを同時に変更するサブプログラムが含まれています。

「Oracle Streamsを使用したデータベースのアップグレードまたはメンテナンス操作の実行」の手順19および20で、ソース・データベースと宛先データベースで同じ操作を確実に実行した場合に、データベースでこのような操作が実行される可能性があります。たとえば、メンテナンス操作中に、PL/SQLプロシージャによってソース・データベース上で統計が収集された場合、手順20でも、宛先データベースで同じPL/SQLプロシージャを起動する必要があります。

サポートされないデータベース・オブジェクトの除外

DBMS_STREAMS_ADMパッケージのPRE_INSTANTIATION_SETUPおよびPOST_INSTANTIATION_SETUPプロシージャには、次のパラメータがあります。

- exclude_schemas

- exclude_flags

これらのパラメータには、Oracle Streams構成から除外するデータベース・オブジェクトを指定します。この付録の例では、これらのパラメータを次の値に設定します。

exclude_schemas => '*',
exclude_flags   => DBMS_STREAMS_ADM.EXCLUDE_FLAGS_UNSUPPORTED +
DBMS_STREAMS_ADM.EXCLUDE_FLAGS_DML +
DBMS_STREAMS_ADM.EXCLUDE_FLAGS_DDL);

これらの値によって、Oracle Streamsでサポートされないすべてのデータベース・オブジェクトが除外されます。exclude_schemasに指定されているアスタリスク(*)は、データベース内の各スキーマの一部のデータベース・オブジェクトがレプリケーション環境から除外されることを示します。exclude_flagsパラメータに指定されている値は、サポートされていないすべてのデータベース・オブジェクトに対するDMLおよびDDLの変更がレプリケーション環境から除外されることを示します。ルールは、これらのデータベース・オブジェクトを除外するために取得プロセスのネガティブ・ルール・セットに入れられます。

サポートされていないデータベース・オブジェクトを表示するには、ソース・データベースでDBA_STREAMS_UNSUPPORTEDデータ・ディクショナリ・ビューを問い合せます。これらのパラメータ設定を使用すると、このビューに表示されたデータベース・オブジェクトは、メンテナンス操作中にOracle Streamsによってメンテナンスされません。そのため、「タスク1: メンテナンス操作の開始」の手順7では、データベースのアップグレードまたはメンテナンス操作中にこれらのデータベース・オブジェクトが変更されないようにする必要があります。

注意:
「ユーザー定義型を含むデータベースのアップグレードまたはメンテナンスの準備」で、メンテナンス操作中にユーザー定義型を含む表に対して行われる変更を保持する方法について説明しています。この方法を使用すると、メンテナンス操作中に、ユーザー定義型を含む表をオープン状態のままにできます。

関連項目:
exclude_schemasおよびexclude_flagsパラメータの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

データベースのアップグレードまたはメンテナンス操作の準備

この項では、Oracle Streamsを使用したデータベースのアップグレードまたはメンテナンス操作を開始する前に完了する必要があるタスクについて説明します。

- ダウンストリーム取得の準備

- ユーザー定義型を含むデータベースのアップグレードまたはメンテナンスの準備

- ユーザー作成アプリケーションへのアップグレード準備

- Oracle Streamsを直接構成するかスクリプトを生成するかの決定

- インスタンス化で使用するユーティリティの決定

ダウンストリーム取得の準備

宛先データベースまたは第3のデータベースを取得データベースにすることを決定した場合、ソース・データベースから取得データベースにログ・ファイルがコピーされるように構成して、ダウンストリーム取得のための準備を行う必要があります。ソース・データベースを取得データベースにすることを決定した場合、ログ・ファイルのコピーは不要です。決定については、「アップグレードまたはメンテナンス操作中の取得データベース」を参照してください。

次の手順に従って、ソース・データベースの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を指定するメリットは、ソース・データベースのパフォーマンスへの影響が、ほとんどまたはまったくないことです。ダウンストリーム・データベースまたはネットワークのパフォーマンスが低い場合は、ASYNCを使用してソース・データベースのパフォーマンスへの影響を回避することをお薦めします。

SYNCを指定するメリットは、ASYNCを指定した場合より速くREDOデータがダウンストリーム・データベースに送信されることです。また、SYNC AFFIRMを指定すると、MAXIMUM AVAILABILITYスタンバイ保護モードと同様の動作になります。ALTER DATABASE STANDBY DATABASE TO MAXIMIZE AVAILABILITY SQL文を指定しても、Oracle Streamsの取得プロセスには影響しないことに注意してください。

- NOREGISTER: アーカイブREDOログ・ファイルの場所がダウンストリーム・データベース制御ファイルに記録されないようにこの属性を指定します。

- VALID_FOR: (ONLINE_LOGFILE,PRIMARY_ROLE)または(ONLINE_LOGFILE,ALL_ROLES)を指定します。

- TEMPLATE: ダウンストリーム・データベースのアーカイブREDOログのディレクトリおよび書式テンプレートを指定します。TEMPLATE属性は、ダウンストリーム・データベースのLOG_ARCHIVE_FORMAT初期化パラメータ設定より優先されます。TEMPLATE属性は、リモートの宛先でのみ有効です。各ソース・データベースで、書式に%t、%sおよび%rのすべての変数が使用されるようにしてください。

- DB_UNIQUE_NAME: ダウンストリーム・データベースの一意の名前。ダウンストリーム・データベースでDB_UNIQUE_NAME初期化パラメータに指定した名前を使用します。

取得データベース(DBS2.EXAMPLE.COM)を指定する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_STATE_nパラメータに対応する初期化パラメータをENABLEに設定します。
たとえば、ダウンストリーム・データベースにLOG_ARCHIVE_DEST_2初期化パラメータが設定されている場合、LOG_ARCHIVE_DEST_STATE_2パラメータを次のように設定します。

LOG_ARCHIVE_DEST_STATE_2=ENABLE

- LOG_ARCHIVE_CONFIG: ソース・データベースおよびダウンストリーム・データベースのDB_UNIQUE_NAMEを含むように、この初期化パラメータのDB_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初期化パラメータのDB_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ログ・ファイルを送信するには、ソース・データベースがオープンされている必要があります。これは、ソース・データベースのグローバル名は、ソース・データベースがオープンである場合にのみ取得データベースに送信されるためです。

関連項目:
取得データベースの詳細は、「Oracle Streamsを使用したアップグレードおよびメンテナンス操作の概要」を参照

ユーザー定義型を含むデータベースのアップグレードまたはメンテナンスの準備

ユーザー定義型には、オブジェクト型、REF値、VARRAY、ネストした表などがあります。今回のリリースでは、Oracle Streamsの取得プロセスおよび適用プロセスでは、ユーザー定義型はサポートされていません。この項では、Oracle Streamsを使用してユーザー定義型を含むデータベースにアップグレードまたはメンテナンス操作を実行する方法について説明します。

1つの方法は、操作中に、ユーザー定義型を含む表に対して、データ操作言語(DML)またはデータ定義言語(DDL)の変更が行われないようにすることです。この場合、これらの表は宛先データベースでインスタンス化され、操作中にその表に対する変更は行われません。操作の完了後に、宛先データベースでユーザー定義型を含む表を読取り/書込み可能にします。

ただし、操作中にユーザー定義型を含む表をオープン状態のままにしておく必要がある場合は、次の一般的な手順を実行して、操作中にこれらのデータ型に対する変更を保持してください。

1. ソース・データベースで、ユーザー定義型を含む表に対する行変更を格納するための1つ以上のロギング表を作成します。ロギング表の各列では、Oracle Streamsでサポートされているデータ型を使用する必要があります。

2. ソース・データベースで、ユーザー定義のデータ型を含む表で起動されるDMLトリガーを作成します。このトリガーによって、各行変更が等価なリレーショナルに変換され、手順1で作成したロギング表に変更された行が記録されます。

3. ロギング表に対する変更を取得し、必要に応じて宛先データベースに伝播するように、取得プロセスおよび伝播が構成されていることを確認します。ユーザー定義型を含む表に対する変更は、取得または伝播されないようにする必要があります。そのため、PRE_INSTANTIATION_SETUPおよびPOST_INSTANTIATION_SETUPプロシージャによって、ロギング表が含まれ、ユーザー定義型を含む表が除外されていることを確認します。

4. 宛先データベースで、ロギング表に対する変更を処理するDMLハンドラを使用するように適用プロセスを構成します。DMLハンドラによって等価なリレーショナルからユーザー定義型が再構成され、ユーザー定義型を含む表に対する変更が適用されます。

手順については、Webブラウザを使用してMy Oracle Support (旧OracleMetaLink) Webサイトを参照してください。

http://support.oracle.com/

Oracle Streamsの拡張データ型のサポートについては、データベース掲示板556742.1で説明されています。

関連項目:

- トリガーを作成する方法の詳細は、『Oracle Database PL/SQL言語リファレンス』を参照

- 「DMLハンドラの管理」

ユーザー作成アプリケーションへのアップグレード準備

この項の内容は、操作にユーザー作成アプリケーションのアップグレードが必要な場合にのみ該当します。ユーザー作成アプリケーションのアップグレード中にスキーマ・オブジェクトを変更できますが、データベースのみでは検出できない論理的な依存性が存在する場合があります。次の各項では、アプリケーションのアップグレード中に発生するこれらの問題を処理する方法について説明します。

- スキーマ・オブジェクトに対する変更の処理

- 論理的な依存性の処理

スキーマ・オブジェクトに対する変更の処理

ユーザー作成アプリケーションをアップグレードする場合は、通常、データベースのスキーマ・オブジェクトを、アップグレード後のアプリケーションをサポートするように変更します。Oracle Streamsでは、行論理変更レコード(LCR)に、DML文の実行結果である行変更の情報が含まれます。宣言ルールベースの変換またはDMLハンドラでは、宛先データベースの変更された表に行LCRが適用されるように、ソース・データベースのREDOログから取得された行LCRを変更できます。

ルールベースの変換は、ポジティブ・ルール・セットのルールがTRUEに評価される場合に発生するメッセージの変更です。宣言ルールベースの変換では、行LCRの一連の一般的な変換を実行できます。宣言ルールベースの変換は、PL/SQLを使用せずに内部的に実行されます。このような変換は、DBMS_STREAMS_ADMパッケージのプロシージャを使用して指定します。宣言ルールベースの変換では、取得、伝播または適用中に行LCRを変更できます。

DMLハンドラは、ソース・データベースで実行したDML文によって発生した行LCRを処理するSQL文のコレクションまたはユーザー・プロシージャです。宛先データベースのOracle Streamsの適用プロセスが行LCRをDMLハンドラに渡し、DMLハンドラが行LCRを変更できます。

Oracle Streamsを使用してユーザー作成アプリケーションをアップグレードするプロセスには、インスタンス化後に宛先データベースで行うスキーマ・オブジェクトの変更および作成が含まれる場合があります。宛先データベースで1つ以上の宣言ルールベースの変換およびDMLハンドラを使用して、ソース・データベースからの変更が、変更済のスキーマ・オブジェクトに正確に適用されるように、それらの変更を処理できます。アプリケーションのアップグレード中に宣言ルールベースの変換およびDMLハンドラを使用して、ソース・データベースと宛先データベースの差異を考慮できます。

通常、宣言ルールベースの変換の方がDMLハンドラより簡単に使用できます。そのため、行LCRの変更が必要な場合、まず宣言ルールベースの変換を構成します。宣言ルールベースの変換では不十分な場合には、DMLハンドラを使用します。1つ以上のLOB列が含まれる表の行LCRを変更する必要がある場合、プロシージャDMLハンドラおよびLOBアセンブリを使用する必要があります。

データベースのアップグレードまたはメンテナンス操作を開始する前に、次のタスクを実行して、宣言ルールベースの変換またはDMLハンドラを準備する必要があります。

- 宣言ルールベースの変換について理解します。「宣言ルールベースの変換」を参照してください。

- DMLハンドラについて理解します。「適用プロセスのメッセージ処理オプション」を参照してください。

- 宛先データベースで宣言ルールベースの変換とDMLハンドラのどちらが必要になるかを決定します。アップグレードしたアプリケーションで必要なスキーマ・オブジェクトへの変更によって、どちらが必要になるが異なります。

- データベースのメンテナンス操作のDMLハンドラで使用するSQL文またはPL/SQLプロシージャを作成します。PL/SQLプロシージャを作成する方法については、「DMLハンドラの管理」を参照してください。

- 1つ以上のLOB列が含まれる表の行LCRを変更する必要がある場合、LOBアセンブリの使用方法について理解します。『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

注意:
カスタム・ルールベースの変換を使用して、アプリケーションのアップグレード中に行LCRを変更することもできます。ただし、これらの変更はDMLハンドラを使用して実行可能であり、DMLハンドラの方がカスタム・ルールベースの変換より効率的です。

論理的な依存性の処理

適用プロセスでは、パラレルで適用される行LCR間の依存性を検出するために、追加の情報が必要になる場合があります。アプリケーションのアップグレード中、次のような状況で、依存性を検出するために適用プロセスに追加の情報が必要になる場合があります。

- データベースではなくアプリケーションに論理的な依存性がある。

- アプリケーションのアップグレードをサポートするようにスキーマ・オブジェクトが変更されており、DMLハンドラがソース・データベースと宛先データベースの差異を考慮するために行LCRを変更する。

仮想依存性定義とは、宛先データベースでトランザクション間の依存性を検出するために、適用プロセスで使用される依存性の記述です。仮想依存性定義は、宛先データベースのデータ・ディクショナリの制約としては記述されません。かわりに、DBMS_APPLY_ADMパッケージのプロシージャを使用して指定されます。仮想依存性定義を使用すると、適用プロセスで、データ・ディクショナリの制約情報のみを使用した場合には検出できない依存性を検出できるようになります。依存性が検出されると、適用プロセスは、LCRおよびトランザクションを正しい順序で適用するようにスケジュールします。

アプリケーションのアップグレードに仮想依存性定義が必要な場合、仮想依存性定義について理解し、アプリケーションのアップグレード中に仮想依存性定義を構成することを計画します。

関連項目:
仮想依存性定義の詳細は、「適用プロセスおよび依存性」を参照

Oracle Streamsを直接構成するかスクリプトを生成するかの決定

DBMS_STREAMS_ADMパッケージのPRE_INSTANTIATION_SETUPおよびPOST_INSTANTIATION_SETUPプロシージャで、アップグレードまたはメンテナンス操作中のOracle Streamsレプリケーション環境を構成します。これらのプロシージャでは、Oracle Streamsレプリケーション環境を直接構成するか、またはOracle Streamsレプリケーション環境を構成するスクリプトを生成できます。

プロシージャを使用してレプリケーションを直接構成する方がスクリプトを実行するよりも簡単で、環境が即時に構成されます。ただし、次のような理由でスクリプトを生成することもできます。

- 環境を構成する前に、プロシージャによって実行されるアクションを確認する。

- スクリプトを変更して構成をカスタマイズする。

これらのプロシージャのいずれかを実行するときにOracle Streamsを直接構成するには、perform_actionsパラメータをTRUEに設定します。この付録の例では、プロシージャによってOracle Streamsが直接構成されると想定しています。

これらのプロシージャのいずれかを実行するときに構成スクリプトを生成するには、この付録でこれらのプロシージャを実行する際に、次の手順を実行します。

1. SQL*Plusで、プロシージャを実行するデータベースにOracle Streams管理者として接続します。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

2. プロシージャによって生成されるスクリプトを格納するディレクトリ・オブジェクトを作成します。次に例を示します。

CREATE DIRECTORY scripts_dir AS '/usr/scripts';

3. プロシージャを実行します。スクリプトを生成するように次のパラメータが設定されていることを確認します。

- perform_actionsパラメータ: FALSEに設定します。

- script_nameパラメータ: 生成するスクリプトの名前に設定します。

- script_directory_objectパラメータ: スクリプトを配置するディレクトリ・オブジェクトに設定します。このディレクトリ・オブジェクトは手順2で作成されています。

4. 必要に応じて、スクリプトを確認または変更します。

5. SQL*Plusで、プロシージャを実行するデータベースにOracle Streams管理者として接続します。

6. 生成されたスクリプトを実行します。次に例を示します。

@/usr/scripts/pre_instantiation.sql;

インスタンス化で使用するユーティリティの決定

データベースのアップグレードまたはメンテナンス操作を始める前に、操作中に宛先データベースをインスタンス化するために、エクスポート/インポート・ユーティリティ(データ・ポンプまたはオリジナル)を使用するか、Recovery Manager(RMAN)ユーティリティを使用するかを決定します。宛先データベースのインスタンス化にどちらのユーティリティを使用するかを決定するには、次の事項を考慮します。

- データベースを異なるプラットフォームに移行する場合は、エクスポート/インポートまたはRMANのCONVERT DATABASEコマンドを使用します。RMANのDUPLICATEコマンドを使用しても、データベースを異なるオペレーティング・システムに移行できません。

- データベースを異なるキャラクタ・セットに移行する場合は、エクスポート/インポートを使用する必要があり、新しいキャラクタ・セットは古いキャラクタ・セットのスーパーセットである必要があります。RMANのDUPLICATEおよびCONVERT DATABASEコマンドを使用しても、データベースを異なるキャラクタ・セットに移行できません。

- 以前のリリースのOracle DatabaseをOracle Database 11g リリース2 (11.2)にアップグレードする場合は、さらに次の点を考慮してください。

- RMANを使用できる場合は、特にデータベースが大きい場合に、RMANを使用する方が、エクスポート/インポートを使用するより速くインスタンス化を実行できます。

- 分散トランザクションが可能な環境でインスタンス化を行う場合は、RMANを使用しないことをお薦めします。これを行うと、手動での修正が必要なインダウント・トランザクションが実行される場合があります。

- RMANのDUPLICATEまたはCONVERT DATABASEコマンドを使用してデータベースのインスタンス化を行う場合、宛先データベースを取得データベースとすることはできません。

- 以前のリリースのOracle DatabaseをOracle Database 11g リリース2 (11.2)にアップグレードする場合は、さらに次の点を考慮してください。

- エクスポート/インポートを使用すると、操作の最初で、宛先データベースをOracle Database 11g リリース2 (11.2)データベースにできます。つまり、インスタンス化の後、宛先データベースをアップグレードする必要はありません。

- RMANのDUPLICATEを使用する場合は、宛先データベースのデータベース・リリースがソース・データベースと同じである必要があります。

- RMANのCONVERT DATABASEを使用する場合は、宛先データベースのデータベース・リリースがソース・データベース以上である必要があります。

表D-1に、ソース・データベースと宛先データベースのプラットフォームまたはキャラクタ・セットが同じまたは異なる場合に、各インスタンス化方法がサポートされるかどうかを示します。

表D-1 Oracle Streamsを使用したデータベースのメンテナンスのためのインスタンス化方法

インスタンス化方法

プラットフォームが同じ場合にサポートされるかどうか

プラットフォームが異なる場合にサポートされるかどうか

キャラクタ・セットが同じ場合にサポートされるかどうか

キャラクタ・セットが異なる場合にサポートされるかどうか

データ・ポンプ・エクスポート/インポート

はい

はい

はい

はい

RMANのDUPLICATE

はい

いいえ

はい

いいえ

RMANのCONVERT DATABASE

いいえ

場合による

はい

いいえ

RMANのCONVERT DATABASEコマンドがサポートされるプラットフォームの組合せは限られています。DBMS_TDBパッケージを使用すると、任意のプラットフォームの組合せでサポートされているかどうかを判別できます。

関連項目:

- Oracle Streamsのインスタンス化の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

- RMANのDUPLICATEおよびCONVERT DATABASEコマンドを使用する手順については、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照

- RMANのDUPLICATEおよびCONVERT DATABASEコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照

- DBMS_TDBパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

- キャラクタ・セット変換およびエクスポート/インポートの詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照

Oracle Streamsを使用したデータベースのアップグレードまたはメンテナンス操作の実行

この項では、Oracle Databaseに対して次のいずれかの操作を実行する方法について説明します。

- Oracle Database 10g リリース2(10.2)またはOracle Database 11g リリース1(11.1)から現在のリリースのOracle Databaseへのアップグレード

- 異なるプラットフォームへのデータベースの移行

- 異なるキャラクタ・セットへのデータベースの移行

- ユーザー作成アプリケーションにアップグレードするためのデータベース・スキーマ・オブジェクトの変更

- Oracle Databaseソフトウェア・パッチまたはパッチ・セットの適用

Oracle Streamsを使用すると、わずかな停止時間または停止時間なしで、これらの操作を実行できます。操作中、ソース・データベースは、データベースの操作を実行している既存のデータベースです。取得データベースは、Oracle Streamsの取得プロセスが実行されるデータベースです。宛先データベースは、操作の最後で、ソース・データベースと置き換えられるデータベースです。

Oracle Streamsを使用してデータベースのメンテナンス操作を実行するには、次のタスクを実行します。

- タスク1: 操作の開始

- タスク2: インスタンス化前のOracle Streamsの設定

- タスク3: データベースのインスタンス化

- タスク4: インスタンス化後のOracle Streamsの設定

- タスク5: アップグレードまたはメンテナンス操作の完了およびOracle Streamsの削除

タスク1: 操作の開始

次の手順を実行して、Oracle Streamsを使用したアップグレードまたはメンテナンス操作を開始します。

1. 空の宛先データベースを作成します。データベースを異なるプラットフォームに移行する場合は、新しいプラットフォームを使用するコンピュータ・システムにデータベースを作成します。データベースを異なるキャラクタ・セットに移行する場合は、新しいキャラクタ・セットを使用するデータベースを作成します。
宛先データベースのグローバル名がソース・データベースとは異なることを確認してください。ここでは、ソース・データベースのグローバル名がorcl.example.com、メンテナンス操作で使用する宛先データベースのグローバル名がstms.example.comであると想定しています。宛先データベースのグローバル名は、メンテナンス操作の最後で、宛先データベースがソース・データベースと置き換わるときに変更されます。

以前のリリースのOracle Databaseからアップグレードしない場合は、Oracle Database 11g リリース2 (11.2)データベースを作成します。Oracleをインストールする必要がある場合は、ご使用のオペレーティング・システムのOracleインストレーション・ガイドを参照してください。データベースを作成する方法については、『Oracle Database管理者ガイド』を参照してください。

以前のリリースのOracle Databaseからアップグレードする場合、作成する空のデータベースのリリースは、「インスタンス化で使用するユーティリティの決定」で使用することを決定したインスタンス化方法によって異なります。

- インスタンス化にエクスポート/インポートを使用することを決定した場合、空のOracle Database 11g リリース2データベースを作成します。このデータベースは、アップグレード・プロセス中の宛先データベースとなります。
Oracle Databaseをインストールする必要がある場合は、ご使用のオペレーティング・システムのOracle Databaseインストレーション・ガイドを参照してください。また、データベースを作成する方法については、『Oracle Database管理者ガイド』を参照してください。

- インスタンス化にRMANのDUPLICATEを使用することを決定した場合、アップグレード対象のデータベースと同じリリースの空のOracle Databaseを作成します。
具体的には、Oracle Database 10g リリース2(10.2)データベースをアップグレードする場合は、Oracle Database 10g リリース2データベースを作成します。また、Oracle Database 11g リリース1(11.1)データベースをアップグレードする場合は、Oracle Database 11g リリース1データベースを作成します。

このデータベースは、アップグレード・プロセス中の宛先データベースとなります。アップグレード・プロセスを開始する場合、アップグレード対象のソース・データベースと宛先データベースの両方が同じリリースのOracleである必要があります。

Oracleをインストールする必要がある場合は、ご使用のオペレーティング・システムのOracleインストレーション・ガイドを参照してください。また、データベースを作成する方法については、対象のリリースの『Oracle Database管理者ガイド』を参照してください。

- インスタンス化にRMANのCONVERT DATABASEを使用することを決定した場合、アップグレード対象のデータベース以上のリリースの空のOracle Databaseを作成します。
具体的には、Oracle Database 10g リリース2(10.2)データベースをアップグレードする場合は、Oracle Database 10g リリース2データベース、Oracle Database 11g リリース1データベースまたはOracle Database 11g リリース2データベースを作成します。また、Oracle Database 11g リリース1(11.1)データベースをアップグレードする場合は、Oracle Database 11g リリース1データベースまたはOracle Database 11g リリース2データベースを作成します。

このデータベースは、アップグレード・プロセス中の宛先データベースとなります。

Oracleをインストールする必要がある場合は、ご使用のオペレーティング・システムのOracleインストレーション・ガイドを参照してください。また、データベースを作成する方法については、対象のリリースの『Oracle Database管理者ガイド』を参照してください。

2. ソース・データベースがARCHIVELOGモードで実行されていることを確認します。ARCHIVELOGモードでデータベースを実行する方法については、『Oracle Database管理者ガイド』を参照してください。

3. 取得データベースでUNDO表領域を作成します(存在しない場合)。たとえば、取得データベースに管理ユーザーとしてログインしているときに、次の文を実行します。

CREATE UNDO TABLESPACE undotbs_02
DATAFILE '/u01/oracle/rbdb1/undo0201.dbf' SIZE 2M REUSE AUTOEXTEND ON;

UNDO表領域は、取得データベースの取得プロセスで使用されます。

取得データベースの詳細は、「アップグレードまたはメンテナンス操作中の取得データベース」を参照してください。

UNDO表領域を作成する方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

4. 両方のデータベースでOracle Streams環境がサポートされるように初期化パラメータが適切に設定されていることを確認します。
Oracle Database 11g リリース2 (11.2)データベースの場合、Oracle Streamsに関連する初期化パラメータ設定の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

以前のリリースのOracle Databaseからアップグレードする場合のソース・データベースについては、Oracle Streamsマニュアルでソース・データベースのリリースに関する説明を参照してください。

5. ソース・データベース、宛先データベースおよび取得データベース(取得データベースに第3のデータベースを使用する場合)の各データベースにOracle Streams管理者を構成します。この例では、各データベースのOracle Streams管理者の名前がstrmadminであると想定しています。
Oracle Database 11g リリース2 (11.2)データベースの場合の手順については、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

以前のリリースのOracle Databaseからアップグレードする場合のソース・データベースについては、Oracle Streamsマニュアルでソース・データベースのリリースに関する説明を参照してください。

6. ユーザー作成アプリケーションをアップグレードする場合、ソース・データベースで、ルールベースの変換、プロシージャDMLハンドラまたは値の依存性に関係するすべての列のサプリメンタル・ロギングを実行します。これらの列は、ソース・データベースで無条件に記録される必要があります。これらの列に対する無条件サプリメンタル・ログ・グループを指定する方法については、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

7. ソース・データベースで、アップグレードまたはメンテナンス操作中に、Oracle Streamsではサポートされていないデータベース・オブジェクトが変更されないようにします。サポートされていないデータベース・オブジェクトを表示するには、DBA_STREAMS_UNSUPPORTEDデータ・ディクショナリ・ビューを問い合せます。

「ユーザー定義型を含むデータベースのアップグレードまたはメンテナンスの準備」で、メンテナンス操作中にユーザー定義型を含む表に対して行われる変更を保持する方法について説明しています。この方法を使用すると、操作中に、ユーザー定義型を含む表をオープン状態のままにできます。

ヒント:
Oracle Database 11g リリース1 (11.1)以上のデータベースでは、ALTER TABLE文とともにREAD ONLY句を使用して、表を読取り専用にできます。

タスク2: インスタンス化前のOracle Streamsの設定

インスタンス化の前にOracle Streamsを設定する手順は、取得データベースとするデータベースによって異なります。PRE_INSTANTIATION_SETUPプロシージャを実行すると、常に、このプロシージャが実行されるデータベースに取得プロセスが構成されます。そのため、このプロシージャは取得データベースで実行する必要があります。

このプロシージャを実行する場合、プロシージャによって構成が直接実行されるようにするか、またはプロシージャによって構成アクションが含まれるスクリプトが生成されるようにするかを指定できます。「Oracle Streamsを直接構成するかスクリプトを生成するかの決定」を参照してください。この項の例では、プロシージャによって構成が直接実行されるように指定します。

次のいずれかの項の手順に従ってください。

- 取得データベースにソース・データベースを使用する場合

- 取得データベースに宛先データベースを使用する場合

- 取得データベースに第3のデータベースを使用する場合

注意:
perform_actionsパラメータをTRUEに設定してPRE_INSTANTIATION_SETUPプロシージャを実行すると、構成アクションに関するメタデータがデータ・ディクショナリ・ビューDBA_RECOVERABLE_SCRIPT、DBA_RECOVERABLE_SCRIPT_PARAMS、DBA_RECOVERABLE_SCRIPT_BLOCKSおよびDBA_RECOVERABLE_SCRIPT_ERRORSに記録されます。エラーが発生したためにプロシージャが停止した場合、DBMS_STREAMS_ADMパッケージのRECOVER_OPERATIONプロシージャを使用して、エラーの原因となった条件を訂正してから構成を完了できます。スクリプトを使用してレプリケーション環境を構成する場合、これらのビューは移入されません。

関連項目:

- 取得データベースの詳細は、「Oracle Streamsを使用したアップグレードおよびメンテナンス操作の概要」を参照

- RECOVER_OPERATIONプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

取得データベースにソース・データベースを使用する場合

取得データベースにソース・データベースを使用する場合、次の手順を実行して、インスタンス化の前にOracle Streamsを設定します。

1. ソース・データベースが宛先データベースと通信できるように、ネットワークおよびOracle Netを構成します。手順については、Oracle Database Net Services管理者ガイドを参照してください。

2. SQL*Plusで、ソース・データベースにOracle Streams管理者として接続します。この例では、ソース・データベースはorcl.example.comです。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

3. 宛先データベースへのデータベース・リンクを作成します。次に例を示します。

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

4. 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         => 'orcl.example.com',
destination_database    => 'stms.example.com',
perform_actions         => TRUE,
script_name             => NULL,
script_directory_object => NULL,
capture_name            => 'capture_maint',
capture_queue_table     => 'strmadmin.capture_q_table',
capture_queue_name      => 'strmadmin.capture_q',
propagation_name        => 'prop_maint',
apply_name              => 'apply_maint',
apply_queue_table       => 'strmadmin.apply_q',
apply_queue_name        => 'strmadmin.apply_q_table',
bi_directional          => FALSE,
include_ddl             => TRUE,
start_processes         => FALSE,
exclude_schemas         => '*',
exclude_flags           => DBMS_STREAMS_ADM.EXCLUDE_FLAGS_UNSUPPORTED +
DBMS_STREAMS_ADM.EXCLUDE_FLAGS_DML +
DBMS_STREAMS_ADM.EXCLUDE_FLAGS_DDL);
END;
/

5. 「タスク3: データベースのインスタンス化」に進みます。

取得データベースに宛先データベースを使用する場合

取得データベースに宛先データベースを使用する場合、次の手順を実行して、インスタンス化の前にOracle Streamsを設定します。

1. ソース・データベースが宛先データベースと通信できるように、ネットワークおよびOracle Netを構成します。手順については、Oracle Database Net Services管理者ガイドを参照してください。

2. ソース・データベースから宛先データベースにログ・ファイルが送信されるように構成されていることを確認します。手順については、「ダウンストリーム取得の準備」を参照してください。

3. SQL*Plusで、宛先データベースにOracle Streams管理者として接続します。この例では、宛先データベースはstms.example.comです。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

4. ソース・データベースへのデータベース・リンクを作成します。次に例を示します。

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

5. 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         => 'orcl.example.com',
destination_database    => 'stms.example.com',
perform_actions         => TRUE,
script_name             => NULL,
script_directory_object => NULL,
capture_name            => 'capture_maint',
capture_queue_table     => 'strmadmin.streams_q_table',
capture_queue_name      => 'strmadmin.streams_q',
apply_name              => 'apply_maint',
apply_queue_table       => 'strmadmin.streams_q',
apply_queue_name        => 'strmadmin.streams_q_table',
bi_directional          => FALSE,
include_ddl             => TRUE,
start_processes         => FALSE,
exclude_schemas         => '*',
exclude_flags           => DBMS_STREAMS_ADM.EXCLUDE_FLAGS_UNSUPPORTED +
DBMS_STREAMS_ADM.EXCLUDE_FLAGS_DML +
DBMS_STREAMS_ADM.EXCLUDE_FLAGS_DDL);
END;
/

宛先データベースを取得データベースとし、ダウンストリーム取得プロセスと適用プロセスで宛先データベースの同じキューが使用される場合、伝播が不要なためにpropagation_nameパラメータが省略されることに注意してください。

また、取得プロセスおよび適用プロセスは、宛先データベースのstreams_qというキューを共有します。

6. 「タスク3: データベースのインスタンス化」に進みます。

取得データベースに第3のデータベースを使用する場合

ここでは、第3のデータベースのグローバル名がthrd.example.comであると想定しています。取得データベースに第3のデータベースを使用する場合、次の手順を実行して、インスタンス化の前にOracle Streamsを設定します。

1. ソース・データベース、宛先データベースおよび第3のデータベースが相互に通信できるように、ネットワークおよびOracle Netを構成します。手順については、Oracle Database Net Services管理者ガイドを参照してください。

2. ソース・データベースから第3のデータベースにログ・ファイルが送信されるように構成されていることを確認します。手順については、「ダウンストリーム取得の準備」を参照してください。

3. SQL*Plusで、第3のデータベースにOracle Streams管理者として接続します。この例では、第3のデータベースはthrd.example.comです。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

4. ソース・データベースへのデータベース・リンクを作成します。次に例を示します。

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

5. 宛先データベースへのデータベース・リンクを作成します。次に例を示します。

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

6. 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         => 'orcl.example.com',
destination_database    => 'stms.example.com',
perform_actions         => TRUE,
script_name             => NULL,
script_directory_object => NULL,
capture_name            => 'capture_maint',
capture_queue_table     => 'strmadmin.capture_q_table',
capture_queue_name      => 'strmadmin.capture_q',
propagation_name        => 'prop_maint',
apply_name              => 'apply_maint',
apply_queue_table       => 'strmadmin.apply_q',
apply_queue_name        => 'strmadmin.apply_q_table',
bi_directional          => FALSE,
include_ddl             => TRUE,
start_processes         => FALSE,
exclude_schemas         => '*',
exclude_flags           => DBMS_STREAMS_ADM.EXCLUDE_FLAGS_UNSUPPORTED +
DBMS_STREAMS_ADM.EXCLUDE_FLAGS_DML +
DBMS_STREAMS_ADM.EXCLUDE_FLAGS_DDL);
END;
/

7. 「タスク3: データベースのインスタンス化」に進みます。

タスク3: データベースのインスタンス化

「インスタンス化で使用するユーティリティの決定」で、データベース全体をインスタンス化するための様々な方法について説明しています。使用するインスタンス化方法に基づいて、次のいずれかの項の手順を実行します。

- エクスポート/インポートを使用したデータベースのインスタンス化

- RMANのDUPLICATEコマンドを使用したデータベースのインスタンス化

- RMANのCONVERT DATABASEコマンドを使用したデータベースのインスタンス化

関連項目:
インスタンス化の実行の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

エクスポート/インポートを使用したデータベースのインスタンス化

次の手順を実行して、データ・ポンプを使用してデータベース全体をインスタンス化します。

1. SQL*Plusで、ソース・データベースにOracle Streams管理者として接続します。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

2. エクスポート・ダンプ・ファイルとエクスポート・ログ・ファイルを保持するディレクトリ・オブジェクトを作成します。次に例を示します。

CREATE DIRECTORY dpump_dir AS '/usr/dpump_dir';

3. Oracle Streams管理者としてソース・データベースに接続した状態で、ソース・データベースの現在のシステム変更番号(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値は、手順4でデータ・ポンプのFLASHBACK_SCNエクスポート・パラメータに指定します。FLASHBACK_SCNエクスポート・パラメータまたは類似したエクスポート・パラメータを指定すると、エクスポートが単一のSCNでの一貫性のある状態になります。この例では、問合せによって876606という値が戻されると想定しています。

この問合せの実行後、エクスポートが完了するまでエクスポート中のオブジェクトに対してDDL変更が行われないようにします。

4. コマンドラインで、データ・ポンプを使用してソース・データベースをエクスポートします。

EXP_FULL_DATABASEロールが付与された管理ユーザーとして接続し、エクスポートを実行します。このユーザーには、手順2で作成したディレクトリ・オブジェクトに対するREADおよびWRITE権限も必要です。この例では、Oracle Streams管理者strmadminとして接続します。

データ・ポンプでのエクスポート・コマンドの例を次に示します。

expdp strmadmin FULL DIRECTORY=DPUMP_DIR DUMPFILE=orc1.dmp FLASHBACK_SCN=876606

関連項目:
データ・ポンプでのエクスポートを実行する方法については、『Oracle Databaseユーティリティ』を参照

5. SQL*Plusで、宛先データベースにOracle Streams管理者として接続します。

6. インポート・ダンプ・ファイルとインポート・ログ・ファイルを保持するディレクトリ・オブジェクトを作成します。次に例を示します。

CREATE DIRECTORY dpump_dir AS '/usr/dpump_dir';

7. データ・ポンプのエクスポート・ダンプ・ファイルorc1.dmpを宛先データベースに転送します。このファイルを宛先データベースに転送するには、DBMS_FILE_TRANSFERパッケージ、バイナリFTPまたはその他の方法を使用します。ファイルの転送後、エクスポート・ダンプ・ファイルは、手順6で作成したディレクトリ・オブジェクトに対応するディレクトリに格納されます。

8. 宛先データベースのコマンドラインで、データ・ポンプを使用してエクスポート・ダンプ・ファイルorc1.dmpをインポートします。インポートが完了するまでデータベース表に対して変更が行われないようにします。インポートを実行すると、宛先データベースおよびそのすべてのオブジェクトに対してインスタンス化SCNが自動的に設定されます。
IMP_FULL_DATABASEロールが付与された管理ユーザーとして接続し、インポートを実行します。このユーザーには、手順6で作成したディレクトリ・オブジェクトに対するREADおよびWRITE権限も必要です。この例では、Oracle Streams管理者strmadminとして接続します。

STREAMS_CONFIGURATIONインポート・パラメータをnに設定していることを確認します。

インポート・コマンドの例を次に示します。

impdp strmadmin FULL DIRECTORY=DPUMP_DIR DUMPFILE=orc1.dmp STREAMS_CONFIGURATION=n

関連項目:
データ・ポンプでのインポートを実行する方法については、『Oracle Databaseユーティリティ』を参照

RMANのDUPLICATEコマンドを使用したデータベースのインスタンス化

同じプラットフォーム上でのインスタンス化にRMANのDUPLICATEコマンドを使用する場合、次の手順を実行します。

1. バックアップがまだの場合は、ソース・データベースのバックアップを作成します。RMANでは、複製に有効なバックアップが必要です。ここでは、バックアップがまだの場合は、orcl.example.comのバックアップを作成します。

注意:
RMANのDUPLICATEコマンドの実行時にFROM ACTIVE DATABASEオプションを使用する場合、ソース・データベースのバックアップは必要ありません。データベースが大きい場合、FROM ACTIVE DATABASEオプションを使用するには、多くのネットワーク・リソースが必要です。ここでは、このオプションは使用していません。

2. SQL*Plusで、ソース・データベースに管理ユーザーとして接続します。この例では、ソース・データベースはorcl.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値を書き留めます。ここでは、終了SCN値を748045としています。手順7でRMANを使用してデータベースを複製するときに、UNTIL SCNオプションをこの値に設定します。また、「タスク4: インスタンス化後のOracle Streamsの設定」のインスタンス化SCNもこの値に設定します。

4. 現行のオンラインREDOログをアーカイブします。次に例を示します。

ALTER SYSTEM ARCHIVE LOG CURRENT;

5. データベースの複製用に環境を準備します。宛先データベースを複製の補助インスタンスとして準備します。手順については、Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイドを参照してください。

6. RMANクライアントを起動して、TARGETとしてデータベースorcl.example.comに、AUXILIARYとしてデータベースstms.example.comに接続します。管理ユーザーとして各データベースに接続します。
RMANのCONNECTコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

7. RMANのDUPLICATEコマンドにOPEN RESTRICTEDオプションを指定して、宛先データベースでソース・データベースをインスタンス化します。OPEN RESTRICTEDオプションは必須です。このオプションを指定してSQL文ALTER SYSTEM ENABLE RESTRICTED SESSIONを発行することで、複製データベースの制限付きのセッションが有効になります。RMANは、複製データベースのオープン直前にこの文を発行します。

UNTIL SCN句を使用して、複製のSCNを指定できます。この句には、手順3で決定した終了SCNを使用します。指定した終了SCNおよび上位SCN値に対して、アーカイブREDOログが使用可能である必要があります。そのために、手順4で終了SCNを含むREDOログをアーカイブしました。

複製データベースの名前を指定するには、DUPLICATEコマンドでTO database_nameを使用します。ここでは、複製データベースの名前をstmsとします。つまり、この例のDUPLICATEコマンドには、TO stmsが含まれます。

次に、RMANのDUPLICATEコマンドの例を示します。

RMAN> RUN
{
SET UNTIL SCN 748045;
ALLOCATE AUXILIARY CHANNEL stms DEVICE TYPE sbt;
DUPLICATE TARGET DATABASE TO stms
NOFILENAMECHECK
OPEN RESTRICTED;
}

8. SQL*Plusで、宛先データベースにシステム管理者として接続します。この例では、宛先データベースはstms.example.comです。

9. グローバル名を変更します。RMANを使用してデータベースをインスタンス化すると、宛先データベースとソース・データベースのグローバル名が同じになりますが、宛先データベースの名前は、操作が完了するまで元の名前である必要があります。次の文を使用して、宛先データベースのグローバル名を元の名前に戻します。

ALTER DATABASE RENAME GLOBAL_NAME TO stms.example.com;

10. データベースを以前のリリースからOracle Database 11g リリース2にアップグレードする場合は、宛先データベースをアップグレードします。手順については、『Oracle Databaseアップグレード・ガイド』を参照してください。データベースをアップグレードしない場合は、この手順をスキップし、次の手順に進んでください。

11. SQL*Plusで、宛先データベースにOracle Streams管理者として接続します。

12. ソース・データベースへのデータベース・リンクを作成します。次に例を示します。

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

このデータベース・リンクは、POST_INSTANTIATION_SETUPプロシージャによって、宛先データベースでDBMS_APPLY_ADMパッケージのSET_GLOBAL_INSTANTIATION_SCNプロシージャが実行されるために必要です。SET_GLOBAL_INSTANTIATION_SCNプロシージャには、データベース・リンクが必要です。

13. ソース・データベースと取得データベースが同じデータベースの場合、SQL*Plusで宛先データベースにOracle Streams管理者として接続した状態で、ソース・データベースからクローニングされた、ソース・データベースから宛先データベースへのデータベース・リンクを削除します。

DROP DATABASE LINK stms.example.com;

関連項目:
RMANのDUPLICATEコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照

RMANのCONVERT DATABASEコマンドを使用したデータベースのインスタンス化

インスタンス化にRMANのCONVERT DATABASEコマンドを使用してデータベースを異なるプラットフォームに移行する場合、次の手順を実行します。

1. バックアップがまだの場合は、ソース・データベースのバックアップを作成します。RMANでは、有効なバックアップが必要です。ここでは、バックアップがまだの場合は、orcl.example.comのバックアップを作成します。

2. SQL*Plusで、ソース・データベースに管理ユーザーとして接続します。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

3. 現行のオンラインREDOログをアーカイブします。次に例を示します。

ALTER SYSTEM ARCHIVE LOG CURRENT;

4. データベースの変換用に環境を準備します。たとえば、ソース・データベースを読取り専用モードでオープンします。次の手順を実行します。

1. ソース・データベースがオープンしている場合は、停止して読取り専用モードで起動します。

2. DBMS_TDBパッケージのCHECK_DBおよびCHECK_EXTERNALファンクションを実行します。結果をチェックして、RMANのCONVERT DATABASEコマンドで変換がサポートされていることを確認します。

関連項目:
これらの手順の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照

5. ソース・データベースの現行の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値を書き留めます。「タスク4: インスタンス化後のOracle Streamsの設定」で、インスタンス化SCNにこの数を使用します。この例では、戻される値を748044と想定しています。

6. RMANクライアントを起動し、TARGETとしてのソース・データベースorcl.example.comに管理ユーザーとして接続します。
RMANのCONNECTコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

7. CONVERT DATABASEコマンドを実行します。
CONVERT DATABASEコマンドでNEW DATABASE database_nameを使用して、宛先データベースの名前を指定する必要があります。この例では、宛先データベースの名前をstmsとします。つまり、この例のCONVERT DATABASEコマンドには、NEW DATABASE stmsが含まれます。

Linux IA (64-bit)プラットフォームで実行される宛先データベースに対するRMANのCONVERT DATABASEコマンドの例を次に示します。

CONVERT DATABASE NEW DATABASE 'stms'
TRANSPORT SCRIPT '/tmp/convertdb/transportscript.sql'
TO PLATFORM 'Linux IA (64-bit)'
DB_FILE_NAME_CONVERT = ('/home/oracle/dbs','/tmp/convertdb');

8. RMANのCONVERT DATABASEコマンドによって生成されたデータファイル、PFILEおよびSQLスクリプトを、宛先データベースが実行されているコンピュータ・システムに転送します。

9. 宛先データベースが実行されているコンピュータ・システムで、制限付きセッションが有効にされた状態で宛先データベースが常にオープンするようにSQLスクリプトを変更します。
次のスクリプトの例では、必要な変更を太字で示しています。

-- The following commands will create a 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 "STMS" 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.
-- The startup 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の位置を変更する必要がある場合があります。

10. SQL*Plusで、宛先データベースにシステム管理者として接続します。

11. グローバル名を変更します。RMANを使用してデータベースをインスタンス化すると、宛先データベースとソース・データベースのグローバル名が同じになりますが、宛先データベースの名前は、メンテナンス操作が完了するまで元の名前である必要があります。次の文を使用して、宛先データベースのグローバル名を元の名前に戻します。

ALTER DATABASE RENAME GLOBAL_NAME TO stms.example.com;

12. データベースを以前のリリースからOracle Database 11g リリース2にアップグレードする場合は、宛先データベースをアップグレードします。手順については、『Oracle Databaseアップグレード・ガイド』を参照してください。データベースをアップグレードしない場合は、この手順をスキップし、次の手順に進んでください。

13. 新しいグローバル名を使用して、宛先データベースにOracle Streams管理者として接続します。

14. ソース・データベースへのデータベース・リンクを作成します。次に例を示します。

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

このデータベース・リンクは、POST_INSTANTIATION_SETUPプロシージャによって、宛先データベースでDBMS_APPLY_ADMパッケージのSET_GLOBAL_INSTANTIATION_SCNプロシージャが実行されるために必要です。SET_GLOBAL_INSTANTIATION_SCNプロシージャには、データベース・リンクが必要です。

15. ソース・データベースと取得データベースが同じデータベースの場合、SQL*Plusで宛先データベースにOracle Streams管理者として接続した状態で、ソース・データベースからクローニングされた、ソース・データベースから宛先データベースへのデータベース・リンクを削除します。

DROP DATABASE LINK stms.example.com;

タスク4: インスタンス化後のOracle Streamsの設定

インスタンス化の後にOracle Streamsを設定するには、POST_INSTANTIATION_SETUPプロシージャを実行します。POST_INSTANTIATION_SETUPプロシージャは、「タスク2: インスタンス化前のOracle Streamsの設定」でPRE_INSTANTIATION_SETUPプロシージャを実行したデータベースで実行する必要があります。

POST_INSTANTIATION_SETUPプロシージャを実行する場合、プロシージャによって構成が直接実行されるようにするか、またはプロシージャによって構成アクションが含まれるスクリプトが生成されるようにするかを指定できます。「Oracle Streamsを直接構成するかスクリプトを生成するかの決定」を参照してください。この項の例では、プロシージャによって構成が直接実行されるように指定します。

perform_actions、script_name、script_directory_objectおよびstart_processesを除き、PRE_INSTANTIATION_SETUPとPOST_INSTANTIATION_SETUPプロシージャに指定されているパラメータ値は一致する必要があります。次の例では、2つのプロシージャのすべてのパラメータ値が一致しています。

POST_INSTANTIATION_SETUPプロシージャのinstantiation_scnパラメータを正しく設定することが重要です。このパラメータを設定するには、次の手順を実行します。

- インスタンス化にRMANを使用した場合、instantiation_scnパラメータをインスタンス化中に判別した値に設定します。この値は、「RMANのDUPLICATEコマンドを使用したデータベースのインスタンス化」または「RMANのCONVERT DATABASEコマンドを使用したデータベースのインスタンス化」でインスタンス化を実行したときに判別した値です。
この項に示すソース・データベースと第3のデータベースの例では、次のような理由で、instantiation_scnパラメータを748044に設定します。

- インスタンス化にRMANのDUPLICATEコマンドを使用した場合、UNTIL SCN句で指定したSCN値より1少ないSCNまでデータベースが複製されます。つまり、「RMANのDUPLICATEコマンドを使用したデータベースのインスタンス化」の手順7でDUPLICATEコマンドを実行したときに指定した終了SCN値から1を引きます。この場合、終了SCN値は748045でした。つまり、instantiation_scnパラメータは、 748045 - 1で748044となります。

- インスタンス化にRMANのCONVERT DATABASEコマンドを使用した場合、instantiation_scnパラメータはCONVERT DATABASEコマンドを実行する直前に判別したSCN値に設定する必要があります。この値は、「RMANのCONVERT DATABASEコマンドを使用したデータベースのインスタンス化」の手順5で判別しています。

- インスタンス化にエクスポート/インポートを使用した場合、インスタンス化SCNはインポート中に設定されているため、instantiation_scnパラメータをNULLに設定する必要があります。この項に示す宛先データベースの例では、宛先データベースを取得データベースとする場合にはデータベースのインスタンス化にRMANを使用できないため、instantiation_scnをNULLに設定します。

インスタンス化の後にOracle Streamsを設定する手順は、取得データベースとするデータベースによって異なります。次のいずれかの項の手順に従ってください。

- 取得データベースにソース・データベースを使用する場合

- 取得データベースに宛先データベースを使用する場合

- 取得データベースに第3のデータベースを使用する場合

注意:
perform_actionsパラメータをTRUEに設定してPOST_INSTANTIATION_SETUPプロシージャを実行すると、構成アクションに関するメタデータがデータ・ディクショナリ・ビューDBA_RECOVERABLE_SCRIPT、DBA_RECOVERABLE_SCRIPT_PARAMS、DBA_RECOVERABLE_SCRIPT_BLOCKSおよびDBA_RECOVERABLE_SCRIPT_ERRORSに記録されます。エラーが発生したためにプロシージャが停止した場合、DBMS_STREAMS_ADMパッケージのRECOVER_OPERATIONプロシージャを使用して、エラーの原因となった条件を訂正してから構成を完了できます。スクリプトを使用してレプリケーション環境を構成する場合、これらのビューは移入されません。

関連項目:

- 取得データベースの詳細は、「Oracle Streamsを使用したアップグレードおよびメンテナンス操作の概要」を参照

- RECOVER_OPERATIONプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照

取得データベースにソース・データベースを使用する場合

取得データベースにソース・データベースを使用する場合、次の手順を実行して、インスタンス化の後にOracle Streamsを設定します。

1. SQL*Plusで、ソース・データベースにOracle Streams管理者として接続します。この例では、ソース・データベースはorcl.example.comです。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

2. 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         => 'orcl.example.com',
destination_database    => 'stms.example.com',
perform_actions         => TRUE,
script_name             => NULL,
script_directory_object => NULL,
capture_name            => 'capture_maint',
capture_queue_table     => 'strmadmin.capture_q_table',
capture_queue_name      => 'strmadmin.capture_q',
propagation_name        => 'prop_maint',
apply_name              => 'apply_maint',
apply_queue_table       => 'strmadmin.apply_q',
apply_queue_name        => 'strmadmin.apply_q_table',
bi_directional          => FALSE,
include_ddl             => TRUE,
start_processes         => FALSE,
instantiation_scn       => 748044, -- NULL if Export/Import instantiation
exclude_schemas         => '*',
exclude_flags           => DBMS_STREAMS_ADM.EXCLUDE_FLAGS_UNSUPPORTED +
DBMS_STREAMS_ADM.EXCLUDE_FLAGS_DML +
DBMS_STREAMS_ADM.EXCLUDE_FLAGS_DDL);
END;
/

インスタンス化にRMANのかわりにエクスポート/インポートを使用した場合は、instantiation_scnパラメータがNULLに設定されていることを確認します。

3. 「タスク5: アップグレードまたはメンテナンス操作の完了およびOracle Streamsの削除」に進みます。

取得データベースに宛先データベースを使用する場合

取得データベースに宛先データベースを使用する場合、次の手順を実行して、インスタンス化の後にOracle Streamsを設定します。

1. SQL*Plusで、宛先データベースにOracle Streams管理者として接続します。この例では、宛先データベースはstms.example.comです。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

2. 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         => 'orcl.example.com',
destination_database    => 'stms.example.com',
perform_actions         => TRUE,
script_name             => NULL,
script_directory_object => NULL,
capture_name            => 'capture_maint',
capture_queue_table     => 'strmadmin.streams_q_table',
capture_queue_name      => 'strmadmin.streams_q',
apply_name              => 'apply_maint',
apply_queue_table       => 'strmadmin.streams_q',
apply_queue_name        => 'strmadmin.streams_q_table',
bi_directional          => FALSE,
include_ddl             => TRUE,
start_processes         => FALSE,
instantiation_scn       => NULL,
exclude_schemas         => '*',
exclude_flags           => DBMS_STREAMS_ADM.EXCLUDE_FLAGS_UNSUPPORTED +
DBMS_STREAMS_ADM.EXCLUDE_FLAGS_DML +
DBMS_STREAMS_ADM.EXCLUDE_FLAGS_DDL);
END;
/

宛先データベースを取得データベースとする場合、伝播が不要なためにpropagation_nameパラメータが省略されることに注意してください。

3. 「タスク5: アップグレードまたはメンテナンス操作の完了およびOracle Streamsの削除」に進みます。

取得データベースに第3のデータベースを使用する場合

ここでは、第3のデータベースのグローバル名がthrd.example.comであると想定しています。取得データベースに第3のデータベースを使用する場合、次の手順を実行して、インスタンス化の後にOracle Streamsを設定します。

1. SQL*Plusで、第3のデータベースにOracle Streams管理者として接続します。この例では、第3のデータベースはthrd.example.comです。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

2. 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         => 'orcl.example.com',
destination_database    => 'stms.example.com',
perform_actions         => TRUE,
script_name             => NULL,
script_directory_object => NULL,
capture_name            => 'capture_maint',
capture_queue_table     => 'strmadmin.capture_q_table',
capture_queue_name      => 'strmadmin.capture_q',
propagation_name        => 'prop_maint',
apply_name              => 'apply_maint',
apply_queue_table       => 'strmadmin.apply_q',
apply_queue_name        => 'strmadmin.apply_q_table',
bi_directional          => FALSE,
include_ddl             => TRUE,
start_processes         => FALSE,
instantiation_scn       => 748044, -- NULL if Export/Import instantiation
exclude_schemas         => '*',
exclude_flags           => DBMS_STREAMS_ADM.EXCLUDE_FLAGS_UNSUPPORTED +
DBMS_STREAMS_ADM.EXCLUDE_FLAGS_DML +
DBMS_STREAMS_ADM.EXCLUDE_FLAGS_DDL);
END;
/

インスタンス化にRMANのかわりにエクスポート/インポートを使用した場合は、instantiation_scnパラメータがNULLに設定されていることを確認します。

3. 「タスク5: アップグレードまたはメンテナンス操作の完了およびOracle Streamsの削除」に進みます。

タスク5: アップグレードまたはメンテナンス操作の完了およびOracle Streamsの削除

次の手順を実行して、Oracle Streamsを使用したアップグレードまたはメンテナンス操作を完了し、Oracle Streamsコンポーネントを削除します。

1. 宛先データベースで、ソース・データベースからレプリケートされるデータを変更するインポート済のジョブを無効にします。DBA_JOBSデータ・ディクショナリ・ビューを問い合せて、ジョブを表示します。

2. ここで、パッチまたはパッチ・セットを宛先データベースに適用します。パッチまたはパッチ・セットに付属の手順に従います。パッチまたはパッチ・セットを適用しない場合は、この手順をスキップし、次の手順に進んでください。

3. ユーザー作成アプリケーションをアップグレードする場合は、宛先データベースで、次の手順の実行が必要な場合があります。

1. データベースのスキーマ・オブジェクトを、アップグレード後のユーザー作成アプリケーションをサポートするように変更します。

2. ソース・データベースからの行LCRが、適用プロセスによって変更済のスキーマ・オブジェクトに正確に適用されるように、これらの行LCRを変更する1つ以上の宣言ルールベースの変換およびプロシージャDMLハンドラを構成します。たとえば、アップグレード済のユーザー作成アプリケーションをサポートするように列名が変更された場合、宣言ルールベースの変換では、列を含む行LCRで列の名前が変更される必要があります。
「スキーマ・オブジェクトに対する変更の処理」を参照してください。

3. 適用プロセスのみでは検出できない論理的な依存性が行LCRに含まれる場合、1つ以上の仮想依存性定義を構成します。
「論理的な依存性の処理」を参照してください。

4. SQL*Plusで、宛先データベースに管理ユーザーとして接続します。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

5. RESTRICTED SESSIONを無効にするには、ALTER SYSTEM文を使用します。

ALTER SYSTEM DISABLE RESTRICTED SESSION;

6. SQL*Plusで、宛先データベースにOracle Streams管理者として接続します。

7. 適用プロセスを開始します。次に例を示します。

BEGIN
DBMS_APPLY_ADM.START_APPLY(
apply_name  => 'apply_maint');
END;
/

8. SQL*Plusで、取得データベースにOracle Streams管理者として接続します。

9. 取得プロセスを起動します。次に例を示します。

BEGIN
DBMS_CAPTURE_ADM.START_CAPTURE(
capture_name  => 'capture_maint');
END;
/

この手順は、宛先データベースのインスタンス化中に、ソース・データベースに対して行われた変更をレプリケートするプロセスを起動します。

10. 適用プロセスが、ソース・データベースからのほとんどの変更を宛先データベースに適用するまで、Oracle Streams環境を監視します。

適用プロセスが、ソース・データベースからのほとんどの変更を宛先データベースに適用したかどうかを判断するには、次の手順を実行します。

1. 取得プロセスのエンキュー・メッセージ番号、および適用プロセスのシステム変更番号(SCN)が最も古いメッセージを問い合せ、これらがほとんど等しいかどうかを確認します。

たとえば、取得プロセスの名前がcapture_maint、適用プロセスの名前がapply_maintの場合は、取得データベースで次の問合せを実行します。

COLUMN ENQUEUE_MESSAGE_NUMBER HEADING 'Captured SCN' FORMAT 99999999999
COLUMN OLDEST_SCN_NUM HEADING 'Oldest Applied SCN' FORMAT 99999999999

SELECT c.ENQUEUE_MESSAGE_NUMBER, a.OLDEST_SCN_NUM
FROM V$STREAMS_CAPTURE c, V$STREAMS_APPLY_READER@stms.example.com a
WHERE c.CAPTURE_NAME = 'CAPTURE_MAINT'
AND a.APPLY_NAME   = 'APPLY_MAINT';

この問合せで戻される2つの値がほぼ同じ場合は、ソース・データベースからのほとんどの変更が宛先データベースに適用済で、次の手順に進むことができます。この時点では、ソース・データベースがまだ変更可能であるため、この問合せで同じ値が戻されることはありません。

この問合せで結果が返されない場合は、取得データベースのDBA_CAPTUREビューおよび宛先データベースのDBA_APPLYビューのSTATUS列を問い合せて、環境のOracle Streamsクライアントが有効かどうかを確認します。伝播を使用する場合、「伝播ジョブのスケジュールに関する情報の表示」にある問合せを実行して、伝播の状態を確認できます。

Oracle Streamsクライアントが無効な場合は、再起動します。Oracle Streamsクライアントが再起動されない場合は、第30章「Oracle Streams環境内での問題の特定」を参照して、環境に対するトラブルシューティングを実行します。

2. 宛先データベースでの適用サーバーの適用プロセスの状態を問い合せ、変更の適用が終了しているかどうかを確認します。
たとえば、適用プロセスの名前がapply_maintである場合は、ソース・データベースで次の問合せを実行します。

COLUMN STATE HEADING 'Apply Server State' FORMAT A20

SELECT STATE
FROM V$STREAMS_APPLY_SERVER@stms.example.com
WHERE APPLY_NAME = 'APPLY_MAINT';

すべての適用サーバーの状態がIDLEであれば、次の手順に進むことができます。

11. 宛先データベースにOracle Streams管理者として接続します。

12. 次の問合せを実行して、適用エラーがないことを確認します。

SELECT COUNT(*) FROM DBA_APPLY_ERROR;

この問合せで0(ゼロ)が戻されたら、次の手順に進みます。この問合せでエラー・キューにエラーが表示される場合は、エラーを解決してから次の手順に進みます。手順については、「適用エラーの管理」を参照してください。

13. ソース・データベースから、すべてのアプリケーションとユーザーの接続を切断します。

14. ソース・データベースに管理ユーザーとして接続します。

15. データベースへのアクセスを制限します。次に例を示します。

ALTER SYSTEM ENABLE RESTRICTED SESSION;

16. SQL*Plusでソース・データベースに管理ユーザーとして接続した状態で、手順10aで実行した問合せを再度実行します。この問合せで返される2つの値が同じ場合は、ソース・データベースからのすべての変更が宛先データベースに適用済で、次の手順に進むことができます。

17. 宛先データベースにOracle Streams管理者として接続します。

18. 手順12で実行した問合せを再度実行します。この問合せで0(ゼロ)が戻されたら、次の手順に進みます。この問合せでエラー・キューにエラーが表示される場合は、エラーを解決してから次の手順に進みます。手順については、「適用エラーの管理」を参照してください。

19. アップグレードまたはメンテナンス操作中にソース・データベースでジョブ・スレーブを作成、変更または削除するアクションを実行した場合は、同じアクションを宛先データベースで実行します。詳細は、「ジョブ・スレーブおよびPL/SQLパッケージのサブプログラムに関する考慮事項」を参照してください。

20. ユーザー・データとディクショナリ・メタデータを同時に変更するアップグレードまたはメンテナンス操作中に、Oracleが提供するPL/SQLパッケージのサブプログラムをソース・データベースで起動した場合、同じサブプログラムを宛先データベースで起動します。詳細は、「ジョブ・スレーブおよびPL/SQLパッケージのサブプログラムに関する考慮事項」を参照してください。

21. 両方のデータベースから、ANYDATAキュー、サプリメンタル・ロギングの指定、取得プロセス、伝播(存在する場合)、適用プロセスなど、不要になったOracle Streamsコンポーネントを削除します。SQL*Plusで、取得データベースにOracle Streams管理者として接続し、CLEANUP_INSTANTIATION_SETUPプロシージャを実行して両方のデータベースからOracle Streamsコンポーネントを削除します。
取得データベースにソース・データベースまたは第3のデータベースを使用する場合、次のプロシージャを実行します。

DECLARE
empty_tbs  DBMS_STREAMS_TABLESPACE_ADM.TABLESPACE_SET;
BEGIN
DBMS_STREAMS_ADM.CLEANUP_INSTANTIATION_SETUP(
maintain_mode           => 'GLOBAL',
tablespace_names        => empty_tbs,
source_database         => 'orcl.example.com',
destination_database    => 'stms.example.com',
perform_actions         => TRUE,
script_name             => NULL,
script_directory_object => NULL,
capture_name            => 'capture_maint',
capture_queue_table     => 'strmadmin.capture_q_table',
capture_queue_name      => 'strmadmin.capture_q',
propagation_name        => 'prop_maint',
apply_name              => 'apply_maint',
apply_queue_table       => 'strmadmin.apply_q',
apply_queue_name        => 'strmadmin.apply_q_table',
bi_directional          => FALSE,
change_global_name      => TRUE);
END;
/

取得データベースに宛先データベースを使用する場合、次のプロシージャを実行します。

DECLARE
empty_tbs  DBMS_STREAMS_TABLESPACE_ADM.TABLESPACE_SET;
BEGIN
DBMS_STREAMS_ADM.CLEANUP_INSTANTIATION_SETUP(
maintain_mode           => 'GLOBAL',
tablespace_names        => empty_tbs,
source_database         => 'orcl.example.com',
destination_database    => 'stms.example.com',
perform_actions         => TRUE,
script_name             => NULL,
script_directory_object => NULL,
capture_name            => 'capture_maint',
capture_queue_table     => 'strmadmin.streams_q_table',
capture_queue_name      => 'strmadmin.streams_q',
apply_name              => 'apply_maint',
apply_queue_table       => 'strmadmin.streams_q',
apply_queue_name        => 'strmadmin.streams_q_table',
bi_directional          => FALSE,
change_global_name      => TRUE);
END;
/

宛先データベースを取得データベースとする場合、伝播が不要なためにpropagation_nameパラメータが省略されることに注意してください。

change_global_nameパラメータがTRUEに設定されているため、この手順に示す両方のサンプル・プロシージャによって、宛先データベースのグローバル名がorc1.example.comに変更されます。

22. ソース・データベースを停止します。このデータベースは再度オープンしないでください。

23. 宛先データベースで、以前に無効にしたジョブを有効にします。

24. 宛先データベースを、アプリケーションおよびユーザーからアクセスできるようにします。ソース・データベースに接続していたアプリケーションおよびユーザーを、宛先データベースにリダイレクトします。必要に応じて、ソース・データベースと通信していたシステムが宛先データベースと通信できるように、ネットワークおよびOracle Netを再構成します。手順については、Oracle Database Net Services管理者ガイドを参照してください。

25. 宛先データベースでOracle Streams管理者が不要になった場合は、SQL*Plusで宛先データベースに管理ユーザーとして接続し、次の文を実行します。

DROP USER strmadmin CASCADE;

これで、アップグレードまたはメンテナンス操作は完了です。

E Oracle Streamsを使用した10.1以下のデータベースのオンラインでのアップグレード

この付録では、Oracle Streamsを使用して、データベースを次のいずれかのOracle Databaseリリースからアップグレードする方法について説明します。

- Oracle Database 10g リリース1(10.1)

- Oracle9i Databaseリリース2 (9.2)

この付録で説明するデータベースのアップグレード操作では、わずかな停止時間または停止時間なしでデータベースをアップグレードするために、Oracle Streamsの機能を使用します。

次の項では、Oracle Streamsを使用したオンラインでのデータベースのアップグレードについて説明します。

- Oracle Streamsを使用したデータベースのアップグレード・プロセスの概要

- Oracle Streamsを使用したデータベースのアップグレードの準備

- Oracle Streamsを使用したデータベースのアップグレードの実行

関連項目:
Oracle Database 10g リリース2 (10.2)以上からアップグレードする方法の詳細、およびOracle Streamsを使用してデータベースに対して他のメンテナンス操作を実行する方法の詳細は、付録D「Oracle Streamsを使用したオンラインでのデータベースのアップグレードおよびメンテナンス」を参照

Oracle Streamsを使用したデータベースのアップグレード・プロセスの概要

Oracle Databaseのアップグレードは、既存の以前のリリースのOracle Databaseを今回のリリースのOracle Databaseに変換するプロセスです。通常、データベースをアップグレードするには、データベースを長時間停止する必要がありますが、Oracle Streamsの機能を使用することで、わずかな停止時間または停止時間なしでデータベースをアップグレードできます。そのためには、Oracle Streamsを使用して、次のデータベースを含むレプリケーション環境を構成します。

- ソース・データベース: アップグレード対象の元のデータベース。

- 取得データベース: アップグレード中にソース・データベースに対して行われた変更が取得プロセスによって取得されるデータベース。

- 宛先データベース: アップグレード・プロセス中にソース・データベースに対して行われた変更が適用プロセスによって適用されるソース・データベースのコピー。

次の一般的な手順で、データベースがオンラインの状態でデータベースをアップグレードできます。

1. 空の宛先データベースを作成します。

2. Oracle Streamsのレプリケーション環境を構成します(元のデータベースがソース・データベースで、データベースのコピーがソースで行われた変更の宛先データベースです)。

3. 宛先データベースに対してデータベースのアップグレードを実行します。このとき、元のソース・データベースはオンラインで使用可能です。

4. Oracle Streamsを使用して、ソース・データベースで行われた変更を宛先データベースに適用します。

5. ソース・データベースで行われた変更を宛先データベースに適用した後、ソース・データベースをオフラインにして、アプリケーションおよびユーザーが宛先データベースを使用できるようにします。

図E-1に、このプロセスの概要を示します。

図E-1 Oracle Streamsを使用したオンラインでのデータベースのアップグレード

アップグレード・プロセス中の取得データベース

アップグレード・プロセス中、取得データベースで取得プロセスが作成されます。Oracle Database 10g リリース1 (10.1)にはダウンストリーム取得が導入されています。データベースをOracle Database 10g リリース1からアップグレードする場合は、次のオプションを使用できます。

- アップグレード・プロセス中に、ソース・データベースでローカル取得プロセスを作成する。

- 宛先データベースで、ダウンストリーム取得プロセスを作成する。宛先データベースが取得データベースである場合、取得データベースから宛先データベースへの伝播は不要です。

- 第3のデータベースを取得データベースにする。この場合、第3のデータベースには、Oracle Database 10g リリース1以上のデータベースを使用できます。

ただし、データベースをOracle9i Databaseリリース2 (9.2)からOracle Database 11g リリース2にアップグレードする場合、ダウンストリーム取得がサポートされていないため、ローカル取得プロセスをソース・データベースで作成する必要があります。

ダウンストリーム取得プロセスを使用すると、アップグレード・プロセス中にソース・データベースに必要なリソースが削減されますが、ローカル取得プロセスの方が構成が簡単です。表E-1に、アップグレード・プロセス中に取得データベースにできるデータベースを示します。

表E-1 サポートされているアップグレード中の取得データベース

既存のデータベースのリリース

取得データベースにソース・データベースを使用可能かどうか

取得データベースに宛先データベースを使用可能かどうか

取得データベースに第3のデータベースを使用可能かどうか

9.2

はい

いいえ

いいえ

10.1

はい

はい

はい

注意:
Oracle Database 10g リリース1 (10.1)からアップグレードする場合、アップグレードを開始する前に、取得データベースとするデータベースを決定してください。

関連項目:
「ローカル取得およびダウンストリーム取得」

アップグレード対象のデータベースの前提条件

この付録で説明する手順は、アップグレード対象のデータベースが次のすべての条件を満たしていることを前提としています。

- データベースは、既存のOracle Streams環境に含まれない。

- データベースは、既存のロジカル・スタンバイ環境に含まれない。

- データベースは、既存のAdvanced Replication環境に含まれない。

- データベースには、他のデータベースのマテリアライズド・ビューのマスター表である表は存在しない。

- アップグレード・プロセス中、メッセージはユーザー作成キューにエンキューされない。

ジョブ・キュー・プロセスおよびPL/SQLパッケージのサブプログラムに関する考慮事項

可能であれば、アップグレード・プロセス中にジョブ・キュー・プロセスを作成、変更または削除しないでください。また、アップグレード・プロセス中は、ユーザー・データとディクショナリ・メタデータを同時に変更するOracle提供のPL/SQLパッケージのサブプログラムを起動しないでください。DBMS_RLS、DBMS_STATSおよびDBMS_JOBパッケージには、ユーザー・データとディクショナリ・メタデータを同時に変更するサブプログラムが含まれています。

「タスク5: アップグレードの完了およびOracle Streamsの削除」の手順13および14で、ソース・データベースと宛先データベースで同じ操作を確実に実行した場合に、データベースでこのような操作が実行される可能性があります。たとえば、アップグレード・プロセス中に、PL/SQLプロシージャによってソース・データベース上で統計が収集された場合、手順14でも、宛先データベースで同じPL/SQLプロシージャを起動する必要があります。

Oracle Streamsを使用したデータベースのアップグレードの準備

この項では、Oracle Streamsを使用したデータベースのアップグレードを開始する前に完了する必要があるタスクについて説明します。

- ユーザー定義型を含むデータベースのアップグレードの準備

- インスタンス化で使用するユーティリティの決定

ユーザー定義型を含むデータベースのアップグレードの準備

ユーザー定義型には、オブジェクト型、REF値、VARRAY、ネストした表などがあります。今回のリリースでは、Oracle Streamsの取得プロセスおよび適用プロセスでは、ユーザー定義型はサポートされていません。この項では、Oracle Streamsを使用してユーザー定義型を含むデータベースをアップグレードする方法について説明します。

1つの方法は、データベースのアップグレード中に、ユーザー定義型を含む表に対して、データ操作言語(DML)またはデータ定義言語(DDL)の変更が行われないようにすることです。この場合、これらの表は宛先データベースでインスタンス化され、操作中にその表に対する変更は行われません。アップグレードの完了後に、宛先データベースでユーザー定義型を含む表を読取り/書込み可能にします。

アップグレード中にユーザー定義型を含む表をオープン状態のままにしておく必要がある場合は、次の一般的な手順を実行して、アップグレード中にその表に対して行われる変更を保持してください。

1. 「Oracle Streamsを使用したデータベースのアップグレードの実行」で説明するアップグレード・プロセスを開始する前に、ユーザー定義型を含むソース・データベースの表に対する行変更を格納する1つ以上のロギング表を作成します。ロギング表の各列では、ソース・データベースのリリースのOracle Streamsでサポートされているデータ型を使用する必要があります。

2. 「Oracle Streamsを使用したデータベースのアップグレードの実行」で説明するアップグレード・プロセスを開始する前に、ユーザー定義のデータ型を含む表で起動されるDMLトリガーをソース・データベースで作成します。このトリガーによって、各行変更が等価なリレーショナルに変換され、手順1で作成したロギング表に変更された行が記録されます。

3. 「Oracle Streamsを使用したデータベースのアップグレードの実行」の手順で取得プロセスおよび伝播を構成するときに、ロギング表に対する変更を取得して宛先データベースに伝播するように、取得プロセスおよび伝播を構成します。ユーザー定義型を含む表に対する変更は、取得または伝播されないようにする必要があります。

4. 「Oracle Streamsを使用したデータベースのアップグレードの実行」の手順で宛先データベースの適用プロセスを構成するときに、ロギング表に対する変更を処理するプロシージャDMLハンドラを使用するように適用プロセスを構成します。プロシージャDMLハンドラによって等価なリレーショナルからユーザー定義型が再構成され、ユーザー定義型を含む表に対する変更が適用されます。

手順については、Webブラウザを使用してMy Oracle Support (旧OracleMetaLink) Webサイトを参照してください。

http://support.oracle.com/

Oracle Streamsの拡張データ型のサポートについては、データベース掲示板556742.1で説明されています。

関連項目:

- トリガーを作成する方法の詳細は、『Oracle Database PL/SQL言語リファレンス』を参照

- 「DMLハンドラの管理」

インスタンス化で使用するユーティリティの決定

データベースのアップグレードを開始する前に、操作中に宛先データベースをインスタンス化するために、エクスポート/インポート・ユーティリティ(データ・ポンプまたはオリジナル)を使用するか、Recovery Manager(RMAN)ユーティリティを使用するかを決定します。アップグレード対象の既存のデータベースは、宛先データベースに置き換えられます。

宛先データベースのインスタンス化にどちらのユーティリティを使用するかを決定するには、次の事項を考慮します。

- オリジナルのエクスポート/インポートまたはデータ・ポンプ・エクスポート/インポートを使用すると、操作の最初で、宛先データベースをOracle Database 11g リリース2 (11.2)データベースにできます。つまり、インスタンス化の後、宛先データベースをアップグレードする必要はありません。
インスタンス化にエクスポート/インポートを使用する場合、データ・ポンプがサポートされているときは、データ・ポンプを使用することをお薦めします。データ・ポンプを使用すると、オリジナルのエクスポート/インポートを使用するより高速でインスタンス化を実行できます。

- RMANのDUPLICATEコマンドを使用する場合は、特にデータベースが大きいときに、エクスポート/インポートを使用するより速くインスタンス化を実行できます。ただし、RMANインスタンス化ではデータベース・リリースが同じである必要があります。したがって、次の条件を満たしている必要があります。

- データベースがOracle9i Databaseリリース2 (9.2)データベースである場合、インスタンス化時の宛先データベースもOracle9i Databaseリリース2データベースである。

- データベースがOracle Database 10g リリース1 (10.1)データベースである場合、インスタンス化時の宛先データベースもOracle Database 10g リリース1データベースである。

インスタンス化の後で、宛先データベースをアップグレードする必要があります。

また、分散トランザクションが可能な環境でインスタンス化を行う場合は、RMANを使用しないことをお薦めします。これを行うと、手動での修正が必要なインダウント・トランザクションが実行される場合があります。

表E-2に、各インスタンス化方法でサポートされているアップグレード対象のデータベースのリリースを示します。また、ソース・データベースと宛先データベースのプラットフォームまたはキャラクタ・セットが異なる場合に、各インスタンス化方法がサポートされるかどうかを示します。ソース・データベースと宛先データベースのプラットフォームおよびキャラクタ・セットが同じ場合は、すべてのインスタンス化方法がサポートされます。

表E-2 Oracle Streamsを使用したデータベースのアップグレードのためのインスタンス化方法

インスタンス化方法

サポートされるアップグレード対象のデータベースのリリース

プラットフォームが異なる場合にサポートされるかどうか

キャラクタ・セットが異なる場合にサポートされるかどうか

オリジナルのエクスポート/インポート

9.2または10.1

はい

はい

データ・ポンプ・エクスポート/インポート

10.1

はい

はい

RMANのDUPLICATE

9.2または10.1

いいえ

いいえ

Oracle Streamsを使用したデータベースのアップグレードの実行

この項では、Oracle Streamsを使用してデータベースをアップグレードする手順について説明します。これらの手順では、Oracle Streamsを使用して、Oracle9i Databaseリリース2(9.2)またはOracle Database 10g リリース1(10.1)のいずれかのOracle Databaseリリースをアップグレードします。

Oracle Streamsを使用してデータベースをアップグレードするには、次のタスクを実行します。

- タスク1: アップグレードの開始

- タスク2: インスタンス化前のOracle Streamsの設定

- タスク3: データベースのインスタンス化

- タスク4: インスタンス化後のOracle Streamsの設定

- タスク5: アップグレードの完了およびOracle Streamsの削除

タスク1: アップグレードの開始

次の手順を実行して、Oracle Streamsを使用したアップグレードを開始します。

1. 空の宛先データベースを作成します。このデータベースのグローバル名がソース・データベースとは異なることを確認してください。ここでは、ソース・データベースのグローバル名がorcl.example.com、アップグレードで使用する宛先データベースのグローバル名がupdb.example.comであると想定しています。宛先データベースのグローバル名は、アップグレード・プロセスの最後で、宛先データベースがソース・データベースと置き換わるときに変更されます。
作成する空のデータベースのリリースは、「インスタンス化で使用するユーティリティの決定」で使用することを決定したインスタンス化方法によって異なります。

- インスタンス化にエクスポート/インポートを使用することを決定した場合、空のOracle Database 11g リリース2データベースを作成します。このデータベースは、アップグレード・プロセス中の宛先データベースとなります。
Oracle Databaseをインストールする必要がある場合は、ご使用のオペレーティング・システムのOracle Databaseインストレーション・ガイドを参照してください。また、データベースを作成する方法については、『Oracle Database管理者ガイド』を参照してください。

- インスタンス化にRMANを使用することを決定した場合、アップグレード対象のデータベースと同じリリースの空のOracle Databaseを作成します。
具体的には、Oracle9i リリース2(9.2)データベースをアップグレードする場合、Oracle9i リリース2データベースを作成します。また、Oracle Database 10g リリース1(10.1)データベースをアップグレードする場合は、Oracle Database 10g リリース1データベースを作成します。

このデータベースは、アップグレード・プロセス中の宛先データベースとなります。アップグレード・プロセスを開始する場合、アップグレード対象のソース・データベースと宛先データベースの両方が同じリリースのOracleである必要があります。

Oracleをインストールする必要がある場合は、ご使用のオペレーティング・システムのOracleインストレーション・ガイドを参照してください。また、データベースを作成する方法については、対象のリリースの『Oracle Database管理者ガイド』を参照してください。

2. ソース・データベースがARCHIVELOGモードで実行されていることを確認します。ARCHIVELOGモードでデータベースを実行する方法については、そのソース・データベースのリリースの『Oracle Database管理者ガイド』を参照してください。

3. 各データベースで、Oracle Streams環境がサポートされるように初期化パラメータが適切に設定されていることを確認します。ソース・データベースについては、そのソース・データベースのリリースのOracle Streamsマニュアルを参照してください。宛先データベースについては、Oracle Streamsに関連する初期化パラメータを設定する方法について、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。取得データベースに第3のデータベースを使用する場合は、その取得データベースのリリースのOracle Streamsマニュアルを参照してください。

4. ソース・データベースで、アップグレード・プロセス中に、アップグレード対象のリリースにおいてOracle Streamsではサポートされていないデータベース・オブジェクトが変更されないようにします。

- Oracle9i リリース2 (9.2)データベースをアップグレードする場合、データ型がNCLOB、LONG、LONG RAW、BFILE、ROWID、UROWIDの列を持つ表、およびユーザー定義型(オブジェクト型、REF、VARRAY、ネストした表など)の列を持つ表はサポートされていません。また、一時表、索引構成表およびオブジェクト表はサポートされていません。サポートされていないデータベース・オブジェクトについては、Oracle9i Streamsを参照してください。

- Oracle Database 10g リリース1 (10.1)データベースをアップグレードする場合、DBA_STREAMS_UNSUPPORTEDデータ・ディクショナリ・ビューを問い合せて、Oracle Streamsでサポートされていないデータベース・オブジェクトを表示します。アップグレード・プロセス中にこれらのデータベース・オブジェクトが変更されないようにしてください。

「ユーザー定義型を含むデータベースのアップグレードの準備」で、アップグレード中にユーザー定義型を含む表に対して行われる変更を保持する方法を説明しています。この方法を使用すると、アップグレード中に、ユーザー定義型を含む表をオープン状態のままにできます。

5. ソース・データベースで、Oracle Streams管理者を構成します。

- Oracle9i リリース2 (9.2)データベースをアップグレードする場合、手順については、Oracle9iのStreamsのマニュアルを参照してください。

- Oracle Database 10g リリース1データベースをアップグレードする場合、手順については、そのリリースの『Oracle Streams概要および管理』を参照してください。

これらの手順では、ソース・データベースのOracle Streams管理者の名前がstrmadminであると想定しています。このOracle Streams管理者は、インスタンス化中に、自動的に宛先データベースにコピーされます。

6. SQL*Plusで、ソース・データベースorcl.example.comに管理ユーザーとして接続します。
SQL*Plusでデータベースに接続する方法については、ソース・データベースのリリースの『Oracle Database管理者ガイド』を参照してください。

7. すべての更新に対して主キー、一意キーおよび外部キーのデータベース・サプリメンタル・ロギングを指定します。次に例を示します。

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA
(PRIMARY KEY, UNIQUE, FOREIGN KEY) COLUMNS;

タスク2: インスタンス化前のOracle Streamsの設定

インスタンス化の前にOracle Streamsを設定する手順は、取得データベースとするデータベースによって異なります。次のいずれかの項の手順に従ってください。

- 取得データベースにソース・データベースを使用する場合

- 取得データベースに宛先データベースを使用する場合

- 取得データベースに第3のデータベースを使用する場合

関連項目:
取得データベースの詳細は、「Oracle Streamsを使用したデータベースのアップグレード・プロセスの概要」を参照

取得データベースにソース・データベースを使用する場合

取得データベースにソース・データベースを使用する場合、次の手順を実行して、インスタンス化の前にOracle Streamsを設定します。

1. ソース・データベースが宛先データベースと通信できるように、ネットワークおよびOracle Netを構成します。手順については、Oracle Database Net Services管理者ガイドを参照してください。

2. SQL*Plusで、ソース・データベースorcl.example.comにOracle Streams管理者として接続します。
SQL*Plusでデータベースに接続する方法については、ソース・データベースのリリースの『Oracle Database管理者ガイド』を参照してください。

3. アップグレード・プロセス中にソース・データベースに対して行われた変更をステージングするANYDATAキューを作成します。次に例を示します。

BEGIN
DBMS_STREAMS_ADM.SET_UP_QUEUE(
queue_table => 'strmadmin.capture_queue_table',
queue_name  => 'strmadmin.capture_queue');
END;
/

4. ソース・データベースへのすべてのサポートされている変更を取得する取得プロセスを構成し、手順3で作成したキューにこれらの変更をステージングします。取得プロセスは起動しないでください。次に例を示します。

BEGIN
DBMS_STREAMS_ADM.ADD_GLOBAL_RULES(
streams_type       => 'capture',
streams_name       => 'capture_upgrade',
queue_name         => 'strmadmin.capture_queue',
include_dml        => TRUE,
include_ddl        => TRUE,
include_tagged_lcr => FALSE,
source_database    => 'orcl.example.com',
inclusion_rule     => TRUE);
END;
/

「ユーザー定義型を含むデータベースのアップグレードの準備」で、メンテナンス操作中にユーザー定義型を含む表に対して行われる変更を保持する方法について説明しています。この方法を使用する場合、ユーザー定義型を含む表に対する変更が取得プロセスによって取得されないことを確認します。ルールを使用してOracle Streams構成からデータベース・オブジェクトを除外する方法については、ソース・データベースのリリースのOracle Streamsマニュアルを参照してください。

5. 「タスク3: データベースのインスタンス化」に進みます。

取得データベースに宛先データベースを使用する場合

この方法を使用するには、アップグレード対象のデータベースがOracle Database 10g リリース1 (10.1)データベースである必要があります。取得データベースに宛先データベースを使用する場合、次の手順を実行して、インスタンス化の前にOracle Streamsを設定します。

1. ソース・データベースが宛先データベースと通信できるように、ネットワークおよびOracle Netを構成します。手順については、Oracle Database Net Services管理者ガイドを参照してください。

2. 使用するインスタンス化方法に基づいて、次のいずれかの項の手順を実行します。

- エクスポート/インポート

- RMAN

エクスポート/インポート

インスタンス化にエクスポート/インポートを使用する場合、次の手順を実行します。

1. SQL*Plusで、宛先データベースupdb.example.comにOracle Streams管理者として接続します。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

2. アップグレード・プロセス中にソース・データベースに対して行われた変更をステージングするANYDATAキューを作成します。次に例を示します。

BEGIN
DBMS_STREAMS_ADM.SET_UP_QUEUE(
queue_table => 'strmadmin.destination_queue_table',
queue_name  => 'strmadmin.destination_queue');
END;
/

3. ソース・データベースへのすべてのサポートされている変更を取得するダウンストリーム取得プロセスを構成し、手順bで作成したキューにこれらの変更をステージングします。取得プロセスでソース・データベースへのデータベース・リンクが使用されることを確認します。取得プロセスには、リアルタイム・ダウンストリーム取得プロセスまたはアーカイブ・ログ・ダウンストリーム取得プロセスを使用できます。手順については、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。取得プロセスは起動しないでください。
「ユーザー定義型を含むデータベースのアップグレードの準備」で、メンテナンス操作中にユーザー定義型を含む表に対して行われる変更を保持する方法について説明しています。この方法を使用する場合、ユーザー定義型を含む表に対する変更が取得プロセスによって取得されないことを確認します。ルールを使用してOracle Streams構成からデータベース・オブジェクトを除外する方法については、ソース・データベースのOracle Streamsマニュアルを参照してください。

RMAN

インスタンス化にRMANを使用する場合、次の手順を実行します。

1. SQL*Plusで、ソース・データベースorcl.example.comにOracle Streams管理者として接続します。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

2. REDOログにデータ・ディクショナリを作成します。

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 = 1122610

このプロシージャによって、宛先データベースで作成される取得プロセスの有効な先頭SCN値が表示されます。戻されたSCN値を書き留めます。この値は、宛先データベースで取得プロセスを作成するときに使用します。

3. ソース・データベースでインスタンス化の準備を行います。

exec DBMS_CAPTURE_ADM.PREPARE_GLOBAL_INSTANTIATION();

3. 「タスク3: データベースのインスタンス化」に進みます。

取得データベースに第3のデータベースを使用する場合

この方法を使用するには、次の要件を満たす必要があります。

- アップグレード対象のデータベースは、Oracle Database 10g リリース1 (10.1)データベースである必要があります。

- 第3のデータベースは、Oracle Database 10g リリース1以上のデータベースである必要があります。

ここでは、第3のデータベースのグローバル名がthrd.example.comであると想定しています。取得データベースに第3のデータベースを使用する場合、次の手順を実行して、インスタンス化の前にOracle Streamsを設定します。

1. ソース・データベース、宛先データベースおよび第3のデータベースが相互に通信できるように、ネットワークおよびOracle Netを構成します。手順については、Oracle Database Net Services管理者ガイドを参照してください。

2. SQL*Plusで、第3のデータベースthrd.example.comに管理ユーザーとして接続します。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

3. Oracle Streams管理者を作成します。

- 第3のデータベースがOracle Database 10g データベースまたはOracle Database 11g リリース1データベースである場合、手順については、そのリリースの『Oracle Streams概要および管理』を参照してください。

- 第3のデータベースがOracle Database 11g リリース2データベースの場合、手順については、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

これらの手順では、第3のデータベースのOracle Streams管理者の名前がstrmadminであると想定しています。

4. 第3のデータベースにOracle Streams管理者として接続したままの状態で、アップグレード・プロセス中にソース・データベースに対して行われた変更をステージングするANYDATAキューを作成します。次に例を示します。

BEGIN
DBMS_STREAMS_ADM.SET_UP_QUEUE(
queue_table => 'strmadmin.capture_queue_table',
queue_name  => 'strmadmin.capture_queue');
END;
/

5. ソース・データベースへのすべてのサポートされている変更を取得するダウンストリーム取得プロセスを構成し、手順4で作成したキューにこれらの変更をステージングします。取得プロセスでソース・データベースへのデータベース・リンクが使用されることを確認します。取得プロセスは起動しないでください。
手順については、次のドキュメントを参照してください。

- 取得データベースがOracle Database 10g データベースまたはOracle Database 11g リリース1データベースである場合、手順については、そのリリースの『Oracle Streams概要および管理』を参照してください。

- 取得データベースがOracle Database 11g リリース2データベースの場合は、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

取得プロセスには、リアルタイム・ダウンストリーム取得プロセスまたはアーカイブ・ログ・ダウンストリーム取得プロセスを使用できます。

「ユーザー定義型を含むデータベースのアップグレードの準備」で、アップグレード操作中にユーザー定義型を含む表に対して行われる変更を保持する方法について説明しています。この方法を使用する場合、ユーザー定義型を含む表に対する変更が取得プロセスによって取得されないことを確認します。ルールを使用してOracle Streams構成からデータベース・オブジェクトを除外する方法については、ソース・データベースのOracle Streamsマニュアルを参照してください。

6. 「タスク3: データベースのインスタンス化」に進みます。

タスク3: データベースのインスタンス化

「インスタンス化で使用するユーティリティの決定」で、データベース全体をインスタンス化するための様々な方法について説明しています。使用するインスタンス化方法に基づいて、次のいずれかの項の手順を実行します。

- エクスポート/インポートを使用したデータベースのインスタンス化

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

エクスポート/インポートを使用したデータベースのインスタンス化

次の手順を実行して、エクスポート/インポートを使用して宛先データベースをインスタンス化します。

1. エクスポート/インポートを使用して、宛先データベースをインスタンス化します。インスタンス化を実行する方法の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。エクスポート/インポート・ユーティリティを使用してエクスポート/インポートを実行する方法の詳細は、『Oracle Databaseユーティリティ』を参照してください。
Oracle Data Pumpまたはオリジナルのエクスポート/インポートを使用して宛先データベースをインスタンス化する場合、次のとおりパラメータが適切な値に設定されていることを確認します。

- STREAMS_CONFIGURATIONインポート・パラメータをnに設定します。

- オリジナルのエクスポート/インポートを使用する場合は、CONSISTENTエクスポート・パラメータをyに設定します。このパラメータは、データ・ポンプでのエクスポートには適用されません。

- オリジナルのエクスポート/インポートを使用する場合は、STREAMS_INSTANTIATIONインポート・パラメータをyに設定します。このパラメータは、データ・ポンプでのインポートには適用されません。

Oracle9i Databaseリリース2(9.2)をアップグレードする場合、オリジナルのエクスポート/インポートを使用する必要があります。

2. 宛先データベースで、ソース・データベースからレプリケートされるデータを変更するインポート済のジョブを無効にします。DBA_JOBSデータ・ディクショナリ・ビューを問い合せて、ジョブを表示します。

3. 「タスク4: インスタンス化後のOracle Streamsの設定」に進みます。

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

次の手順を実行して、RMANのDUPLICATEコマンドを使用して宛先データベースをインスタンス化します。

注意:
ここで示すのは、RMANを使用してデータベースを複製する手順の概略です。Oracle9i リリース2データベースをアップグレードする場合、そのリリースのRMANを使用する方法の詳細は、『Oracle9i Recovery Managerユーザーズ・ガイド』を参照してください。Oracle Database 10g リリース1(10.1)データベースをアップグレードする場合、そのリリースの『Oracle Databaseバックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』を参照してください。

1. バックアップがまだの場合は、ソース・データベースのバックアップを作成します。RMANでは、複製に有効なバックアップが必要です。ここでは、バックアップがまだの場合は、orcl.example.comのバックアップを作成します。

2. SQL*Plusで、ソース・データベースorcl.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値を書き留めます。ここでは、終了SCN値を439882としています。手順7でRMANを使用してデータベースを複製するときに、UNTIL SCNオプションをこの値に設定します。

4. SQL*Plusでソース・データベースに管理ユーザーとして接続した状態で、現行のオンラインREDOログをアーカイブします。次に例を示します。

ALTER SYSTEM ARCHIVE LOG CURRENT;

5. データベースの複製用に環境を準備します。宛先データベースを複製の補助インスタンスとして準備します。手順については、アップグレード対象のリリースのマニュアルを参照してください。具体的には、Oracle9i Recovery Managerユーザーズ・ガイドまたはOracle Databaseバックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド(10g用)のRecovery Managerを使用したデータベースの複製に関する章を参照してください。

6. RMANクライアントを起動して、TARGETとしてデータベースorcl.example.comに、AUXILIARYとしてデータベースupdb.example.comに接続します。管理ユーザーとして各データベースに接続します。
RMANのCONNECTコマンドの詳細は、ご使用のOracle DatabaseリリースのRMANのマニュアルを参照してください。

7. RMANのDUPLICATEコマンドにOPEN RESTRICTEDオプションを指定して、宛先データベースでソース・データベースをインスタンス化します。OPEN RESTRICTEDオプションは必須です。このオプションを指定してSQL文ALTER SYSTEM ENABLE RESTRICTED SESSIONを発行することで、複製データベースの制限付きのセッションが有効になります。RMANは、複製データベースのオープン直前にこの文を発行します。

UNTIL SCN句を使用して、複製のSCNを指定できます。この句には、手順3で決定した終了SCNを使用します。指定した終了SCNおよび上位SCN値に対して、アーカイブREDOログが使用可能である必要があります。そのために、手順4で終了SCNを含むREDOログをアーカイブしました。

複製データベースの名前を指定するには、DUPLICATEコマンドでTO database_nameを使用します。ここでは、複製データベースの名前をupdbとします。つまり、この例のDUPLICATEコマンドには、TO updbが含まれます。

次にRMANのDUPLICATEコマンドの例を示します。

RMAN> RUN
{
SET UNTIL SCN 439882;
ALLOCATE AUXILIARY CHANNEL updb DEVICE TYPE sbt;
DUPLICATE TARGET DATABASE TO updb
NOFILENAMECHECK
OPEN RESTRICTED;
}

8. SQL*Plusで、宛先データベースに管理ユーザーとして接続します。

9. RESTRICTED SESSIONを無効にするには、ALTER SYSTEM文を使用します。

ALTER SYSTEM DISABLE RESTRICTED SESSION;

10. SQL*Plusで、宛先データベースに管理ユーザーとして接続したままの状態で、データベースのグローバル名を変更します。RMANのDUPLICATEコマンドを実行すると、宛先データベースとソース・データベースのグローバル名が同じになりますが、宛先データベースの名前は、アップグレードが完了するまで元の名前である必要があります。次に例を示します。

ALTER DATABASE RENAME GLOBAL_NAME TO updb.example.com;

11. 宛先データベースで、ソース・データベースからレプリケートされるデータを変更するジョブを無効にします。DBA_JOBSデータ・ディクショナリ・ビューを問い合せて、ジョブを表示します。

12. 宛先データベースをOracle Database 11g リリース2にアップグレードします。手順については、『Oracle Databaseアップグレード・ガイド』を参照してください。

13. ソース・データベースが宛先データベースと通信できるように、ネットワークおよびOracle Netを構成します(まだ構成していない場合)。手順については、Oracle Database Net Services管理者ガイドを参照してください。

14. SQL*Plusで、宛先データベースにOracle Streams管理者として接続します。この例では、宛先データベースはupdb.example.comです。

15. ソース・データベースへのデータベース・リンクを作成します。次に例を示します。

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

16. データベース全体およびすべてのデータベース・オブジェクトのインスタンス化SCNを設定します。RMANのDUPLICATEコマンドは、UNTIL SCN句で指定したSCN値より1少ないSCNまでデータベースを複製します。つまり、手順7でDUPLICATEコマンドを実行したときに指定した終了SCN値から1を引きます。この場合、終了SCN値は439882でした。つまり、インスタンス化SCNは、439882 - 1で439881となります。

BEGIN
DBMS_APPLY_ADM.SET_GLOBAL_INSTANTIATION_SCN(
source_database_name => 'orcl.example.com',
instantiation_scn    => 439881,
recursive            => TRUE);
END;
/

17. 「タスク4: インスタンス化後のOracle Streamsの設定」に進みます。

タスク4: インスタンス化後のOracle Streamsの設定

インスタンス化の後にOracle Streamsを設定する手順は、取得データベースとするデータベースによって異なります。次のいずれかの項の手順に従ってください。

- 取得データベースにソース・データベースを使用する場合

- 取得データベースに宛先データベースを使用する場合

- 取得データベースに第3のデータベースを使用する場合

関連項目:
取得データベースの詳細は、「Oracle Streamsを使用したデータベースのアップグレード・プロセスの概要」を参照

取得データベースにソース・データベースを使用する場合

取得データベースにソース・データベースを使用する場合、次の手順を実行して、インスタンス化の後にOracle Streamsを設定します。

1. SQL*Plusで、宛先データベースにOracle Streams管理者として接続します。この例では、宛先データベースはupdb.example.comです。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

2. インスタンス化中にソース・データベースからクローニングされたOracle Streamsコンポーネントを削除します。

- インスタンス化にエクスポート/インポートを使用した場合、ソース・データベースからクローニングされたANYDATAキューを削除します。

- インスタンス化にRMANを使用した場合、ソース・データベースからクローニングされたANYDATAキューおよび取得プロセスを削除します。

ソース・データベースからクローニングされたキューを削除するには、DBMS_STREAMS_ADMパッケージのREMOVE_QUEUEプロシージャを実行します。次に例を示します。

BEGIN
DBMS_STREAMS_ADM.REMOVE_QUEUE(
queue_name              => 'strmadmin.capture_queue',
cascade                 => FALSE,
drop_unused_queue_table => TRUE);
END;
/

ソース・データベースからクローニングされた取得プロセスを削除するには、DBMS_CAPTURE_ADMパッケージのDROP_CAPTUREプロシージャを実行します。次に例を示します。

BEGIN
DBMS_CAPTURE_ADM.DROP_CAPTURE(
capture_name          => 'capture_upgrade',
drop_unused_rule_sets => TRUE);
END;
/

3. ANYDATAキューを作成します。このキューは、ソース・データベースから伝播された変更をステージングします。次に例を示します。

BEGIN
DBMS_STREAMS_ADM.SET_UP_QUEUE(
queue_table => 'strmadmin.destination_queue_table',
queue_name  => 'strmadmin.destination_queue');
END;
/

4. ソース・データベースにOracle Streams管理者として接続します。この例では、ソース・データベースはorcl.example.comです。

5. 宛先データベースへのデータベース・リンクを作成します。次に例を示します。

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

6. ソース・キューからのすべての変更を、手順3で作成した宛先データベースに伝播する伝播を作成します。次に例を示します。

BEGIN
DBMS_STREAMS_ADM.ADD_GLOBAL_PROPAGATION_RULES(
streams_name            => 'to_updb',
source_queue_name       => 'strmadmin.capture_queue',
destination_queue_name  => 'strmadmin.destination_queue@updb.example.com',
include_dml             => TRUE,
include_ddl             => TRUE,
include_tagged_lcr      => TRUE,
source_database         => 'orcl.example.com');
END;
/

7. 宛先データベースにOracle Streams管理者として接続します。

8. 手順3で作成したキューにすべての変更を適用する適用プロセスを作成します。次に例を示します。

BEGIN
DBMS_STREAMS_ADM.ADD_GLOBAL_RULES(
streams_type       => 'apply',
streams_name       => 'apply_upgrade',
queue_name         => 'strmadmin.destination_queue',
include_dml        => TRUE,
include_ddl        => TRUE,
include_tagged_lcr => TRUE,
source_database    => 'orcl.example.com');
END;
/

9. 「タスク5: アップグレードの完了およびOracle Streamsの削除」に進みます。

取得データベースに宛先データベースを使用する場合

取得データベースに宛先データベースを使用する場合、次の手順を実行して、インスタンス化の後にOracle Streamsを設定します。

1. インスタンス化にRMANを使用した場合、次の手順を実行します。インスタンス化にエクスポート/インポートを使用した場合は、手順2に進みます。

1. SQL*Plusで、宛先データベースにOracle Streams管理者として接続します。この例では、宛先データベースはupdb.example.comです。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

2. アップグレード・プロセス中にソース・データベースに対して行われた変更をステージングするANYDATAキューを作成します。次に例を示します。

BEGIN
DBMS_STREAMS_ADM.SET_UP_QUEUE(
queue_table => 'strmadmin.destination_queue_table',
queue_name  => 'strmadmin.destination_queue');
END;
/

3. ソース・データベースへのすべてのサポートされている変更を取得するダウンストリーム取得プロセスを構成し、手順bで作成したキューにこれらの変更をステージングします。
CREATE_CAPTUREプロシージャのfirst_scnパラメータが、「取得データベースに宛先データベースを使用する場合」の手順2bのデータ・ディクショナリの作成時に取得した値に設定されていることを確認します。この例では、first_scnパラメータは1122610に設定されています。

取得プロセスには、リアルタイム・ダウンストリーム取得プロセスまたはアーカイブ・ログ・ダウンストリーム取得プロセスを使用できます。手順については、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。取得プロセスは起動しないでください。

「ユーザー定義型を含むデータベースのアップグレードの準備」で、メンテナンス操作中にユーザー定義型を含む表に対して行われる変更を保持する方法について説明しています。この方法を使用する場合、ユーザー定義型を含む表に対する変更が取得プロセスによって取得されないことを確認します。ルールを使用してOracle Streams構成からデータベース・オブジェクトを除外する方法については、ソース・データベースのOracle Streamsマニュアルを参照してください。

2. ダウンストリーム取得プロセスで使用されるキューにすべての変更を適用する適用プロセスを作成します。次に例を示します。

BEGIN
DBMS_STREAMS_ADM.ADD_GLOBAL_RULES(
streams_type       => 'apply',
streams_name       => 'apply_upgrade',
queue_name         => 'strmadmin.destination_queue',
include_dml        => TRUE,
include_ddl        => TRUE,
include_tagged_lcr => TRUE,
source_database    => 'orcl.example.com');
END;
/

3. 「タスク5: アップグレードの完了およびOracle Streamsの削除」に進みます。

取得データベースに第3のデータベースを使用する場合

ここでは、第3のデータベースのグローバル名がthrd.example.comであると想定しています。取得データベースに第3のデータベースを使用する場合、次の手順を実行して、インスタンス化の後にOracle Streamsを設定します。

1. SQL*Plusで、宛先データベースにOracle Streams管理者として接続します。この例では、宛先データベースはupdb.example.comです。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

2. ANYDATAキューを作成します。このキューは、取得データベースから伝播された変更をステージングします。次に例を示します。

BEGIN
DBMS_STREAMS_ADM.SET_UP_QUEUE(
queue_table => 'strmadmin.destination_queue_table',
queue_name  => 'strmadmin.destination_queue');
END;
/

3. 取得データベースにOracle Streams管理者として接続します。この例では、取得データベースはthrd.example.comです。

4. 宛先データベースへのデータベース・リンクを作成します。次に例を示します。

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

5. 取得データベースのソース・キューからのすべての変更を、手順2で作成した宛先キューに伝播する伝播を作成します。次に例を示します。

BEGIN
DBMS_STREAMS_ADM.ADD_GLOBAL_PROPAGATION_RULES(
streams_name            => 'to_updb',
source_queue_name       => 'strmadmin.capture_queue',
destination_queue_name  => 'strmadmin.destination_queue@updb.example.com',
include_dml             => TRUE,
include_ddl             => TRUE,
include_tagged_lcr      => TRUE,
source_database         => 'orcl.example.com');
END;
/

6. 宛先データベースにOracle Streams管理者として接続します。この例では、宛先データベースはupdb.example.comです。

7. 手順2で作成したキューにすべての変更を適用する適用プロセスを作成します。次に例を示します。

BEGIN
DBMS_STREAMS_ADM.ADD_GLOBAL_RULES(
streams_type       => 'apply',
streams_name       => 'apply_upgrade',
queue_name         => 'strmadmin.destination_queue',
include_dml        => TRUE,
include_ddl        => TRUE,
include_tagged_lcr => TRUE,
source_database    => 'orcl.example.com');
END;
/

8. 「タスク5: アップグレードの完了およびOracle Streamsの削除」の手順を完了します。

タスク5: アップグレードの完了およびOracle Streamsの削除

次の手順を実行して、Oracle Streamsを使用したアップグレード操作を完了し、Oracle Streamsコンポーネントを削除します。

1. 宛先データベースにOracle Streams管理者として接続します。この例では、宛先データベースはupdb.example.comです。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。

2. 適用プロセスを起動します。次に例を示します。

BEGIN
DBMS_APPLY_ADM.START_APPLY(
apply_name  => 'apply_upgrade');
END;
/

3. 取得データベースにOracle Streams管理者として接続します。

4. 取得プロセスを起動します。次に例を示します。

BEGIN
DBMS_CAPTURE_ADM.START_CAPTURE(
capture_name  => 'capture_upgrade');
END;
/

この手順は、宛先データベースのインスタンス化中に、ソース・データベースに対して行われた変更をレプリケートするプロセスを開始します。

5. SQL*Plusで、取得データベースにOracle Streams管理者として接続したままの状態で、適用プロセスが、ソース・データベースからのほとんどの変更を宛先データベースに適用するまで、Oracle Streams環境を監視します。

適用プロセスが、ソース・データベースからのほとんどの変更を宛先データベースに適用したかどうかを判断するには、次の手順を実行します。

1. 取得プロセスのエンキュー・メッセージ番号、および適用プロセスのシステム変更番号(SCN)が最も古いメッセージ番号を問い合せ、これらがほとんど等しいかどうかを確認します。

たとえば、取得プロセスの名前がcapture_upgrade、適用プロセスの名前がapply_upgradeの場合は、取得データベースで次の問合せを実行します。

COLUMN ENQUEUE_MESSAGE_NUMBER HEADING 'Captured SCN' FORMAT 99999999999
COLUMN OLDEST_SCN_NUM HEADING 'Oldest Applied SCN' FORMAT 99999999999

SELECT c.ENQUEUE_MESSAGE_NUMBER, a.OLDEST_SCN_NUM
FROM V$STREAMS_CAPTURE c, V$STREAMS_APPLY_READER@updb.example.com a
WHERE c.CAPTURE_NAME = 'CAPTURE_UPGRADE'
AND a.APPLY_NAME   = 'APPLY_UPGRADE';

この問合せで戻される2つの値がほぼ同じ場合は、ソース・データベースからのほとんどの変更が宛先データベースに適用済で、次の手順に進むことができます。この時点では、ソース・データベースがまだ変更可能であるため、この問合せで同じ値が戻されることはありません。

この問合せで結果が返されない場合は、取得データベースのDBA_CAPTUREビューおよび宛先データベースのDBA_APPLYビューのSTATUS列を問い合せて、環境のOracle Streamsクライアントが有効かどうかを確認します。伝播を使用する場合、「伝播ジョブのスケジュールに関する情報の表示」にある問合せを実行して、伝播の状態を確認できます。

Oracle Streamsクライアントが無効な場合は、再起動します。Oracle Streamsクライアントが再起動されない場合は、第30章「Oracle Streams環境内での問題の特定」を参照して、環境に対するトラブルシューティングを実行します。

2. 宛先データベースでの適用サーバーの適用プロセスの状態を問い合せ、変更の適用が終了しているかどうかを確認します。
たとえば、適用プロセスの名前がapply_upgradeである場合は、取得データベースで次の問合せを実行します。

COLUMN STATE HEADING 'Apply Server State' FORMAT A20

SELECT STATE
FROM V$STREAMS_APPLY_SERVER@updb.example.com
WHERE APPLY_NAME = 'APPLY_UPGRADE';

すべての適用サーバーの状態がIDLEであれば、次の手順に進むことができます。

6. 宛先データベースにOracle Streams管理者として接続します。この例では、宛先データベースはupdb.example.comです。

7. 次の問合せを実行して、適用エラーがないことを確認します。

SELECT COUNT(*) FROM DBA_APPLY_ERROR;

この問合せで0(ゼロ)が戻されたら、次の手順に進みます。この問合せでエラー・キューにエラーが表示される場合は、エラーを解決してから次の手順に進みます。手順については、「適用エラーの管理」を参照してください。

8. ソース・データベースから、すべてのアプリケーションとユーザーの接続を切断します。

9. ソース・データベースに管理ユーザーとして接続します。この例では、ソース・データベースはorcl.example.comです。

10. データベースへのアクセスを制限します。次に例を示します。

ALTER SYSTEM ENABLE RESTRICTED SESSION;

11. SQL*Plusで、取得データベースに管理ユーザーとして接続し、手順5aで実行した問合せを再度実行します。この問合せで戻される2つの値が同じ場合は、ソース・データベースからのすべての変更が宛先データベースに適用済で、次の手順に進むことができます。

12. SQL*Plusで、宛先データベースにOracle Streams管理者として接続し、手順7で実行した問合せを再度実行します。この問合せで0(ゼロ)が戻されたら、次の手順に進みます。この問合せでエラー・キューにエラーが表示される場合は、エラーを解決してから次の手順に進みます。手順については、「適用エラーの管理」を参照してください。

13. アップグレード・プロセス中にソース・データベースでジョブ・キュー・プロセスを作成、変更または削除するアクションを実行した場合は、同じアクションを宛先データベースで実行します。詳細は、「ジョブ・キュー・プロセスおよびPL/SQLパッケージのサブプログラムに関する考慮事項」を参照してください。

14. ユーザー・データとディクショナリ・メタデータを同時に変更するアップグレード・プロセス中に、Oracleが提供するPL/SQLパッケージのサブプログラムをソース・データベースで起動した場合、同じサブプログラムを宛先データベースで起動します。詳細は、「ジョブ・キュー・プロセスおよびPL/SQLパッケージのサブプログラムに関する考慮事項」を参照してください。

15. ソース・データベースを停止します。このデータベースは再度オープンしないでください。

16. 宛先データベースに管理ユーザーとして接続します。

17. データベースのグローバル名をソース・データベースと一致するように変更します。次に例を示します。

ALTER DATABASE RENAME GLOBAL_NAME TO orcl.example.com;

18. 宛先データベースで、以前に無効にしたジョブを有効にします。

19. 宛先データベースを、アプリケーションおよびユーザーからアクセスできるようにします。ソース・データベースに接続していたアプリケーションおよびユーザーを、宛先データベースにリダイレクトします。必要に応じて、ソース・データベースと通信していたシステムが宛先データベースと通信できるように、ネットワークおよびOracle Netを再構成します。手順については、Oracle Database Net Services管理者ガイドを参照してください。

20. 宛先データベースで、不要になったOracle Streamsコンポーネントを削除します。管理ユーザーとして宛先データベースに接続し、次のプロシージャを実行します。

注意:
このプロシージャを実行する場合は注意してください。このプロシージャでは、ローカルのOracle Streams構成が削除されます。このプロシージャを実行する前に、宛先データベースのOracle Streams構成を削除できるかどうかを確認してください。

EXEC DBMS_STREAMS_ADM.REMOVE_STREAMS_CONFIGURATION();

宛先データベースでデータベース・サプリメンタル・ロギングが不要になった場合は、次の文を実行して、不要になったサプリメンタル・ロギングを削除します。

ALTER DATABASE DROP SUPPLEMENTAL LOG DATA
(PRIMARY KEY, UNIQUE, FOREIGN KEY) COLUMNS;

宛先データベースでOracle Streams管理者が不要になった場合は、次の文を実行します。

DROP USER strmadmin CASCADE;

21. 取得データベースに第3のデータベースを使用した場合、その第3のデータベースで、不要になったOracle Streamsコンポーネントを削除します。管理ユーザーとして第3のデータベースに接続し、次のプロシージャを実行します。

注意:
このプロシージャを実行する場合は注意してください。このプロシージャでは、ローカルのOracle Streams構成が削除されます。このプロシージャを実行する前に、第3のデータベースのOracle Streams構成を削除できるかどうかを確認してください。

EXEC DBMS_STREAMS_ADM.REMOVE_STREAMS_CONFIGURATION();

第3のデータベースでデータベース・サプリメンタル・ロギングが不要になった場合は、次の文を実行して、不要になったサプリメンタル・ロギングを削除します。

ALTER DATABASE DROP SUPPLEMENTAL LOG DATA
(PRIMARY KEY, UNIQUE, FOREIGN KEY) COLUMNS;

宛先データベースでOracle Streams管理者が不要になった場合は、次の文を実行します。

DROP USER strmadmin CASCADE;

これで、データベースのアップグレードは完了です。

用語集

アクション・コンテキスト

ルールがメッセージに対して評価される際に、ルール・エンジンのクライアントによって解釈されるルールに関連付けられたオプションの情報です。

ANYDATAキュー

タイプがANYDATAのキュー。このキューは、ANYDATAラッパーでラップされた様々なタイプのメッセージをステージングできます。

「型付きキュー」も参照。

適用済SCN

取得プロセスに関連するシステム変更番号(SCN)。この番号は、取得プロセスで取得された変更を適用する適用プロセスによりデキューされた最新のメッセージに対応します。

適用による転送

中間データベースで転送されるメッセージが、適用プロセスにより最初に処理される有向ネットワークです。それらのメッセージは、中間データベースで取得プロセスに再度取得され、転送されます。

「キューによる転送」も参照。

適用ハンドラ

メッセージの処理をカスタマイズするために適用プロセスによって使用される、SQL文のコレクションまたはユーザー定義のプロシージャです。適用ハンドラには、メッセージ・ハンドラ、プロシージャDMLハンドラ、DDLハンドラ、プリコミット・ハンドラおよびエラー・ハンドラが含まれます。

適用プロセス

オプションのOracleバックグラウンド・プロセス。メッセージを特定のキューからデキューし、各メッセージを直接適用するか、廃棄するか、適用ハンドラにパラメータとして渡すか、または再エンキューします。適用プロセスはOracle Streamsクライアントです。

「論理変更レコード(LCR)」も参照。

適用サーバー

適用プロセスのコンポーネント。LCRをDML文またはDDL文としてデータベース・オブジェクトに適用するか、LCRを適切な適用ハンドラに渡す、1つ以上のプロセスが含まれます。ユーザー・メッセージの場合、メッセージはメッセージ・ハンドラに渡されます。適用サーバーは、DBMS_APPLY_ADM.SET_ENQUEUE_DESTINATIONプロシージャで指定された論理変更レコード(LCR)メッセージとLCR以外のメッセージをエンキューすることもできます。適用サーバーにエラーが発生すると、ユーザー指定のエラー・ハンドラを使用してエラーの解決を試行します。エラーを解決できない場合は、すべてのLCRを含めてトランザクション全体をエラー・キューに置きます。

「論理変更レコード(LCR)」も参照。

適用ユーザー

このユーザーのセキュリティ・ドメインで、適用プロセスがルール・セットを満たすメッセージをデキューし、メッセージをデータベース・オブジェクトに直接適用し、適用プロセスのルールで構成されたカスタム・ルールベースの変換を実行し、適用プロセスに構成された適用ハンドラを実行します。

近似コミット・システム変更番号(近似CSCN)

メッセージをコミット時間キューにエンキューしたトランザクションがコミットされる際のデータベースの現行のSCNに基づいたSCN値。

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

ソース・データベースからダウンストリーム・データベースにコピーされたアーカイブREDOログ・ファイルの変更を取得するダウンストリーム取得プロセスです。

バリア・トランザクション

行論理変更レコード(行LCR)を含むトランザクションまたはDDLトランザクションです。適用プロセスは、バリア・トランザクションに対して、宛先データベースのデータ・ディクショナリや仮想依存性定義を使用して、表の行またはデータベース・オブジェクトを識別することはできません。

バッファLCR

アプリケーションによって明示的に作成され、ANYDATAキューのバッファ・キュー部分にエンキューされる論理変更レコード(LCR)。

バッファ・キュー

メモリーへのメッセージの格納にOracle Streamsプールを使用し、メモリーからオーバーフローしたメッセージの格納にキュー表を使用するキューの一部です。

バッファ・ユーザー・メッセージ

アプリケーションによって明示的に作成され、バッファ・キューにエンキューされるユーザー定義型のLCR以外のメッセージ。バッファ・ユーザー・メッセージは、ANYDATAキューまたは型付きキューのバッファ・キュー部分にエンキューできます。

ビルダー・サーバー

取得プロセスのコンポーネント。プリペアラ・サーバーからのREDOレコードをマージするプロセスです。これらのREDOレコードには、部分評価の実行中にTRUEと評価されたものと、部分評価で結果が生成されていないものがあります。ビルダー・サーバーは、これらのREDOレコードのシステム変更番号(SCN)の順序を保持し、マージされたREDOログ・レコードを取得プロセスに渡します。

取得データベース

ソース・データベースに対して行われた変更を取得する取得プロセスを実行しているデータベース。取得データベースおよびソース・データベースは、取得プロセスがローカル取得プロセスである場合は同じデータベースになります。取得データベースおよびソース・データベースは、取得プロセスがダウンストリーム取得プロセスの場合は異なるデータベースになります。

取得プロセス

オプションのOracleバックグラウンド・プロセス。データベースのREDOログをスキャンして、データベース・オブジェクトに対するDML変更とDDL変更を取得します。取得プロセスはOracle Streamsクライアントです。

取得ユーザー

このユーザーのセキュリティ・ドメインで、取得プロセスがルール・セットを満たす変更を取得し、取得プロセスのルールで構成されたカスタム・ルールベースの変換を実行します。または、同期取得がルール・セットを満たす変更を取得し、同期取得のルールで構成されたカスタム・ルールベースの変換を実行します。

取得LCR

取得プロセスによって暗黙的に取得され、ANYDATAキューのバッファ・キュー部分にエンキューされた論理変更レコード(LCR)。

「ユーザー・メッセージ」も参照。

取得済SCN

取得プロセスによってスキャンされたREDOログの最新の変更に対応するシステム変更番号(SCN)です。

変更の循環

変更が発生元のデータベースに再送されることです。通常、タグの使用や、ルール条件におけるLCRメンバー関数のGET_SOURCE_DATABASE_NAMEの使用により情報を共有している環境では、変更の循環は回避する必要があります。

「論理変更レコード(LCR)」も参照。

変更ハンドラ

表の変更を追跡する特殊なタイプの文DMLハンドラで、DBMS_STREAMS_ADM.MAINTAIN_CHANGE_TABLEプロシージャかDBMS_APPLY_ADM.SET_CHANGE_HANDLERプロシージャのいずれかによって作成されます。

チェックポイント

取得プロセスの現在の状態に関する情報。取得プロセスは、取得プロセスを実行しているデータベースのデータ・ディクショナリに永続的に格納されます。

チェックポイント間隔

取得プロセスがチェックポイントの記録を試行する一定の間隔です。

チェックポイント保存時間

チェックポイントが取得プロセスにより自動的にパージされるまでに保存される期間です。

列リスト

列のリスト。リストの1つ以上の列で更新の競合が発生した場合には、更新の競合ハンドラがコールされます。

「競合解決」も参照。

コミット時間キュー

メッセージが近似コミット・システム変更番号(近似CSCN)の値でソートされるキューです。

条件付きログ・グループ

サプリメンタル・ログ・グループで少なくとも1列が変更された場合に、指定されたすべての列のビフォア・イメージのみを記録するサプリメンタル・ログ・グループです。

「無条件ログ・グループ」も参照。

競合

LCRの古い値と表の予期したデータ間の不一致を意味します。競合は、適用プロセスがLCRの適用を試行する際に検出されます。競合は、表のデータを共有している2つの異なるデータベースが、ほぼ同時に表の同じ行を変更する場合に発生します。

「論理変更レコード(LCR)」も参照。

競合解決

競合を処理して、適用エラーを回避することです。競合は、ビルトインの更新の競合ハンドラか、カスタムの競合ハンドラによって解決できます。

コンシューム

メッセージをキューからデキューするプロセスです。

コーディネータ・プロセス

適用プロセスのコンポーネント。Oracleバックグラウンド・プロセスであり、リーダー・サーバーからトランザクションを取得して適用サーバーに渡します。

カスタム適用

適用プロセスにより、LCRがユーザー・プロシージャにパラメータとして渡され、処理されます。ユーザー・プロシージャは、カスタマイズした方法でLCRを処理できます。

「論理変更レコード(LCR)」も参照。

カスタム・ルールベースの変換

変換の実行にユーザー定義のPL/SQLファンクションが必要なルールベースの変換です。

「宣言ルールベースの変換」も参照。

データベース・サプリメンタル・ロギング

データベース全体の主キー、外部キーおよび一意のキー列に適用されるサプリメンタル・ロギングの一種です。

DDLハンドラ

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

「DDL論理変更レコード(DDL LCR)」も参照。

DDL論理変更レコード(DDL LCR)

データ定義言語(DDL)変更を記述する論理変更レコード(LCR)です。

宣言ルールベースの変換

行LCRに対する共通の変換シナリオ・セットの1つを扱うルールベースの変換です。宣言ルールベースの変換は、PL/SQLを使用せずに内部的に実行されます。

「行論理変更レコード(行LCR)」および「カスタムルールベースの変換」も参照。

デキュー

キューからメッセージを取得することです。

宛先データベース

メッセージがコンシュームされるデータベースです。メッセージがコンシュームされるのは、伝播または適用プロセスにより暗黙的にキューからデキューされた場合か、アプリケーション、メッセージ・クライアントまたはユーザーにより明示的にデキューされた場合です。

「コンシューム」も参照。

宛先キュー

ソース・キューから伝播により伝播されたメッセージを受信するキューです。

直接適用

ユーザー・プロシージャを実行せずにLCRを適用する適用プロセスです。

「論理変更レコード(LCR)」も参照。

有向ネットワーク

伝播されたメッセージが宛先データベースに到達するまでに、1つ以上の中間データベースを経由するネットワークです。

DMLハンドラ

行LCRを処理する適用ハンドラです。

「行論理変更レコード(行LCR)」も参照。

ダウンストリーム取得プロセス

ソース・データベース以外のデータベースで実行されている取得プロセスです。

ダウンストリーム・データベース

ダウンストリーム取得プロセスが実行されているデータベースです。

エンキュー

キューにメッセージを配置することです。

エラー・ハンドラ

PL/SQLプロシージャを使用して適用エラーの解決を試行する適用ハンドラです。エラー・ハンドラは、行論理変更レコード(行LCR)で適用プロセスのエラーが発生した場合にのみ起動されます。競合ハンドラが指定されていない場合や、更新の競合ハンドラが競合を解決できない場合に、競合に起因するそのようなエラーが発生する可能性があります。

評価コンテキスト

ルール条件で参照される可能性のある外部データを定義するデータベース・オブジェクト。外部データは、変数または表データ、あるいはその両方として存在します。

例外キュー

なんらかの理由により取得および処理されない場合、メッセージは例外キューに転送されます。

明示的取得

メッセージが、アプリケーションまたはユーザーによってキューにエンキューされます。

明示的コンシューム

キューのメッセージが、ユーザーまたはアプリケーションで起動されたメッセージ・クライアントによってデキューされます。あるいは、アプリケーションまたはユーザーによって直接デキューされます。

式

値を評価する1つ以上の値と演算子の組合せです。

ファイル

ファイル・グループに関して、ハード・ディスクに格納されているファイルを意味します。ファイルは、ファイル名、ディレクトリ・オブジェクトおよびファイル・タイプで構成されます。ディレクトリ・オブジェクトは、ファイルがハード・ディスク上で格納されているディレクトリです。

ファイル・グループ

バージョンのコレクションです。

ファイル・グループ・リポジトリ

データベース内のファイル・グループすべてのコレクションです。

先頭SCN

取得プロセスで変更を取得できる、REDOログ内の最小のシステム変更番号(SCN)です。

グローバル・ルール

データベース全体またはキュー全体に関連するルールです。

異機種間での情報の共有

Oracle DatabaseとOracle以外のデータベース間で情報を共有することです。

最大値

適用プロセスにより、その番号を超えて適用されたメッセージがないシステム変更番号(SCN)です。

「最小値」も参照。

非処理SCN

表に指定されたシステム変更番号(SCN)で、その番号未満には適用プロセスによる変更の適用ができません。

暗黙的取得

メッセージが、取得プロセスまたは同期取得によって自動的に取得され、キューにエンキューされます。

暗黙的コンシューム

キューのメッセージが適用プロセスによって自動的にデキューされます。

インスタンス化

ソース・データベースでインスタンス化するためにデータベース・オブジェクトを準備するプロセス。オプションで、ソース・データベースから宛先データベースへのデータベース・オブジェクトのコピーや、インスタンス化された各データベース・オブジェクトのインスタンス化SCNの設定が可能です。

インスタンス化SCN

ソース・データベースでそのSCNの後にコミットされた変更のみが適用プロセスにより適用されることを指定する、表のシステム変更番号(SCN)です。

LCR

「論理変更レコード(LCR)」も参照。

LOBアセンブリ

DMLハンドラおよびエラー・ハンドラのオプションで、LOB列のある単一の行に対する変更により発生した複数の行LCRを単一の行LCRにアセンブルします。LOBアセンブリにより、DMLハンドラおよびエラー・ハンドラでLOB列のある行LCRの処理が簡略化されます。

ローカル取得プロセス

ソース・データベースで実行されている取得プロセスです。

論理変更レコード(LCR)

データベース変更を記述する特定のフォーマットのメッセージです。

「行論理変更レコード(行LCR)」および「DDL論理変更レコード(DDL LCR)」も参照。

LogMinerデータ・ディクショナリ

取得中の変更の詳細を確認するために、取得プロセスにより使用される個別のデータ・ディクショナリです。ソース・データベースのプライマリ・データ・ディクショナリは、取得プロセスによりスキャンされたREDOデータと同期していない可能性があるため、LogMinerデータ・ディクショナリが必要です。

最小値

その番号までは、適用プロセスによりすべてのメッセージが適用されているシステム変更番号(SCN)です。

「最大値」も参照。

最大チェックポイントSCN

取得プロセスによって記録された最新のチェックポイント間隔に対応するシステム変更番号(SCN)です。

メッセージ

Oracle Streams環境で共有される情報の単位です。

メッセージ・ハンドラ

PL/SQLプロシージャを使用して永続ユーザー・メッセージを処理する適用ハンドラです。

「論理変更レコード(LCR)」も参照。

メッセージ・ルール

特定のメッセージ・タイプのユーザー・メッセージにのみ関連するルールです。

メッセージ・クライアント

アプリケーションまたはユーザーによって起動された際に永続LCRまたは永続ユーザー・メッセージをデキューするオプションのOracle Streamsクライアント。

ネガティブ・ルール・セット

Oracle Streamsクライアントのルール・セット。このルール・セットでは、ルールがメッセージをTRUEと評価すると、Oracle Streamsクライアントがメッセージを破棄します。Oracle Streamsクライアントのネガティブ・ルール・セットは、常にポジティブ・ルール・セットよりも前に評価されます。

非永続キュー

非永続キューは、メッセージをメモリーに格納します。現在接続しているすべてのユーザーに、通知を送信するための非同期メカニズムを実現するために使用されます。非永続キューはOracle Database 10gリリース2で非推奨となりました。バッファ・メッセージを使用することをお薦めします。

非トランザクション・キュー

各メッセージが自身のトランザクションであるキュー。

「トランザクション・キュー」も参照。

オブジェクト依存性

宛先データベースの2つのオブジェクト間の親子関係を定義する仮想依存性定義です。

最も古いSCN

実行中の適用プロセスの場合は、現在デキューおよび適用されているトランザクションの最も若いシステム変更番号(SCN)です。停止した適用プロセスの場合、最も古いSCNは、適用プロセスが停止した際に適用されていたトランザクションの最も若いSCNです。

Oracle Streamsクライアント

Oracle Streams環境で作業を実行するメカニズムで、ルール・エンジンのクライアントです(メカニズムが1つ以上のルール・セットに関連している場合)。Oracle Streamsクライアントには、取得プロセス、伝播、適用プロセスおよびメッセージ・クライアントが含まれます。

Oracle Streamsデータ・ディクショナリ

特定のソース・データベースからのデータベース・オブジェクトを追跡するために、伝播および適用プロセスにより使用される個別のデータ・ディクショナリです。

Oracle Streamsプール

Oracle Streamsで使用されるシステム・グローバル領域(SGA)にあるメモリーです。Oracle Streamsプールは、バッファ・キューのメッセージをメモリーに格納し、取得プロセスと適用プロセスにメモリーを提供します。

Oracle Streamsのトポロジ

Oracle Streams環境のデータベース、データベースで構成されるOracle Streamsコンポーネント、およびコンポーネント間のメッセージ・フローの表現。

永続LCR

ANYDATAキューの永続キュー部分にエンキューされる論理変更レコード(LCR)。永続LCRは次のいずれかの方法でエンキューできます。

- 同期取得による暗黙的な取得およびエンキュー

- アプリケーションによる明示的な作成およびエンキュー

- 適用プロセスによるデキュー、および同じ適用プロセスによるDBMS_APPLY_ADMパッケージ内のSET_ENQUEUE_DESTINATIONプロシージャを使用したエンキュー

永続キュー

メモリーではなくハード・ディスク上のキュー表のみにメッセージを格納するキューの一部です。

永続ユーザー・メッセージ

永続キューにエンキューされるユーザー定義型のLCR以外のメッセージ。永続ユーザー・メッセージは次のいずれかの方法でエンキューできます。

- アプリケーションによる明示的な作成およびエンキュー

- 適用プロセスによるデキュー、および同じ適用プロセスによるDBMS_APPLY_ADMパッケージ内のSET_ENQUEUE_DESTINATIONプロシージャを使用したエンキュー

永続ユーザー・メッセージはANYDATAキューまたは型付きキューの永続キュー部分にエンキューできます。

ポジティブ・ルール・セット

Oracle Streamsクライアントのルール・セット。このルール・セットでは、ルールがメッセージをTRUEと評価すると、Oracle Streamsクライアントがメッセージのタスクを実行します。Oracle Streamsクライアントのネガティブ・ルール・セットは、常にポジティブ・ルール・セットよりも前に評価されます。

プリコミット・ハンドラ

トランザクションのコミット情報を受信し、PL/SQLプロシージャを使用してコミット情報の処理方法をカスタマイズできる適用ハンドラです。

準備済の表

インスタンス化するために準備された表です。

プリペアラ・サーバー

取得プロセスのコンポーネント。リーダー・サーバーによって定義された領域をスキャンし、REDOログ内で検出された変更の事前フィルタ処理を実行します。リーダー・サーバーはプロセスで、複数のリーダー・サーバーをパラレルで実行できます。事前フィルタ処理では、変更に関する部分的な情報(変更のスキーマ名やオブジェクト名など)が評価のためにルール・エンジンに送信され、評価の結果が受信されます。

プロシージャDMLハンドラ

PL/SQLプロシージャを使用して行LCRを処理する適用ハンドラです。

「行論理変更レコード(行LCR)」も参照。

伝播

オプションのOracle Streamsクライアントで、ソース・キューから宛先キューへのメッセージの送信にOracle Schedulerジョブを使用します。

伝播ジョブ

メッセージを伝播するために伝播で使用されるOracle Schedulerジョブです。

伝播スケジュール

伝播ジョブがメッセージを伝播する頻度を指定するスケジュールです。

キュー

メッセージを格納するために、メッセージ・システムによって使用される抽象的な記憶域の単位です。

キューによる転送

中間データベースで転送されるメッセージが、中間データベースに受信されるメッセージである有向ネットワークです。そのため、この有向ネットワークでは、メッセージのソース・データベースはメッセージが発生したデータベースです。

「適用による転送」も参照。

キュー表

キューが格納されるデータベース表です。各キュー表には、デフォルトの例外キューが含まれます。

リーダー・サーバー

1. 取得プロセスのコンポーネント。REDOログを読み取って複数の領域に分割するプロセスです。

2. メッセージをデキューする適用プロセスのコンポーネント。リーダー・サーバーは、LCR間の依存性を計算してメッセージをトランザクションにアセンブルするプロセスです。リーダー・サーバーが、アセンブルしたトランザクションをコーディネータ・プロセスに返すと、コーディネータ・プロセスがアイドル状態の適用サーバーにトランザクションを割り当てます。

「論理変更レコード(LCR)」も参照。

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

変更がアーカイブREDOログ・ファイルにアーカイブされる前に、ソース・データベースで行われた変更を取得できるダウンストリーム取得プロセスです。

必須チェックポイントSCN

取得プロセスにREDOデータが必要な最小のチェックポイント間隔に対応するシステム変更番号(SCN)です。

レプリケーション

複数のデータベースでデータベース・オブジェクトやデータを共有するプロセスです。

解決列

ビルトインの更新の競合ハンドラを識別するために使用される列です。

「競合解決」も参照。

行論理変更レコード(行LCR)

単一行のデータへの変更、または単一のLONG、LONG RAWまたは行のLOB列への変更を記述する論理変更レコード(LCR)で、データ操作言語(DML)文またはピース単位操作によって発生します。1つのDML文により、複数の行LCRが発生する可能性があります。

行の移行

サブセット・ルールがTRUEに評価される際に、内部のルールベースの変換によって実行される自動変換です。自動変換では、UPDATE操作がINSERTまたはDELETE操作に変換されます。

ルール

イベントが発生し、条件が満たされている場合に、クライアントによるアクションの実行を可能にするデータベース・オブジェクトです。

ルールベースの変換

ポジティブ・ルール・セットのルールがTRUEに評価される場合に発生するメッセージへの変更です。

ルール条件

ルールのコンポーネント。1つ以上の式と条件を結合し、TRUE、FALSEまたはNULL(不明)のいずれかのブール値を返します。

ルール・セット

ルールのグループです。

ルール・エンジン

ルール・セットを評価するOracleのビルトインの一部です。

スキーマ・ルール

特定のスキーマにのみ関連するルールです。

保護キュー

このキューに対しては、Oracle Streamsアドバンスト・キューイング(AQ)エージェントが、エンキューやデキューなどのキュー操作を実行できる1人以上のデータベース・ユーザーに明示的に関連付けられている必要があります。

ソース・データベース

取得プロセスで取得される変更がREDOログに生成されるデータベース。または、LCRを生成する同期取得が構成されているデータベース。

ソース・キュー

このキューから伝播がメッセージを宛先キューに伝播します。

開始SCN

取得プロセスが変更の取得を開始するシステム変更番号(SCN)です。

文DMLハンドラ

1つ以上のSQL文を使用して行LCRを処理する適用ハンドラ。

「行論理変更レコード(行LCR)」も参照。

サブセット・ルール

特定の表に存在する行のサブセットにのみ関連するルールです。

サプリメンタル・ログ・グループ

補足的に記録された表の列のグループです。

「サプリメンタル・ロギング」も参照。

サプリメンタル・ロギング

操作が実行されるたびにREDOログに配置される追加の列データです。取得プロセスはこの追加の情報を取得してLCRに含めます。追加の情報は、適用プロセスが宛先データベースでLCRを適切に適用するために必要です。

「論理変更レコード(LCR)」も参照。

同期取得

オプションのOracle Streamsクライアント。内部メカニズムを使用して、表へのDML変更を変更直後に取得します。

システム作成ルール

DBMS_STREAMS_ADMパッケージを使用して作成されたシステム生成名を持つルールです。

表ルール

特定の表にのみ関連するルールです。

表サプリメンタル・ロギング

特定の表の列に適用されるサプリメンタル・ロギングの一種です。

表領域リポジトリ

ファイル・グループ内の表領域セットのコレクションです。

タグ

各REDOエントリおよびLCRに含まれるRAWデータ型のデータ。タグは、Oracle Streamsクライアントの動作の変更やLCRの追跡に使用されます。また、変更の循環の回避にも使用できます。

「論理変更レコード(LCR)」も参照。

トポロジ

「Oracle Streamsのトポロジ」を参照。

トランザクション制御ディレクティブ

トランザクション制御文(COMMITやROLLBACKなど)を含んだ取得プロセスまたは同期取得によって取得される、特殊なタイプの行LCRです。

「行論理変更レコード(行LCR)」も参照。

トランザクション・キュー

このキューでは、メッセージを、1つのトランザクションとして適用されるセットにグループ化できます。

「非トランザクション・キュー」も参照。

型付きキュー

特定のタイプのメッセージのみをステージングできるキューです。

「ANYDATAキュー」も参照。

無条件ログ・グループ

指定された列に影響する変更かどうかにかかわらず、表が変更された場合に、指定された列のビフォア・イメージを記録するサプリメンタル・ログ・グループです。

「条件付きログ・グループ」も参照。

ユーザー・メッセージ

ユーザー定義型のLCR以外のメッセージ。ユーザー・メッセージは、バッファ・ユーザー・メッセージまたは永続ユーザー・メッセージです。

「論理変更レコード(LCR)」も参照。

値の依存性

一意キーなどの表制約、または2つ以上の表の列間の関連を定義する仮想依存性定義です。

バージョン

関連するファイルのコレクションです。

仮想依存性定義

接続先データベースで適用されるトランザクション間の依存を検出するために、適用プロセスによって使用される依存性の説明です。

索引
A  B  C  D  E  F  G  H  I  K  L  M  N  O  P  Q  R  S  T  U  V  W  X

A

アクション・コンテキスト, 11.1.3

名前/値ペア

追加, 18.2.2.3, 19.2.1, 19.2.2

変更, 18.2.2.2

削除, 18.2.2.4, 19.2.2

問合せ, 19.2.1 システム作成ルール, 11.6 ADD_COLUMNプロシージャ, 6.1, 19.1.1.2 ADD_GLOBAL_RULESプロシージャ, 5.3.1 ADD_PAIRメンバー・プロシージャ, 18.2.2.2, 18.2.2.3, 19.2.1, 19.2.2 ADD_RULEプロシージャ, 11.1.2.2, 18.1.2 ADD_SCHEMA_PROPAGATION_RULESプロシージャ, 5.3.2 ADD_SUBSCRIBERプロシージャ, 16.1.1 ADD_SUBSET_PROPAGATION_RULESプロシージャ

行の移行, 5.3.4.2

ADD_SUBSET_RULESプロシージャ, 5.3, 5.3.4

行の移行, 5.3.4.2

ADD_TABLE_RULESプロシージャ, 5.3.3 アラート・ログ

Oracle Streamsのエントリ, 30.4

アラート, 30.1 ALTER_APPLYプロシージャ

ルール・セットの削除, 17.3.4

DDLハンドラの削除, 17.7.3

適用ユーザーの設定, 17.5

DDLハンドラの設定, 17.7.2

メッセージ・ハンドラの設定, 17.8.1

プリコミット・ハンドラの設定, 17.9.2

ルール・セットの指定, 17.3.1

メッセージ・ハンドラの設定解除, 17.8.2

プリコミット・ハンドラの設定解除, 17.9.3

ALTER_CAPTUREプロシージャ

ルール・セットの削除, 15.1.3.4

取得ユーザーの設定, 15.1.5

先頭SCNの設定, 15.1.8, 15.1.9

ルール・セットの指定, 15.1.3.1, 15.2.1.1

データベース・リンクの使用の指定, 15.1.10

ALTER_PROPAGATIONプロシージャ

ルール・セットの削除, 16.2.7

ルール・セットの指定, 16.2.4

ALTER_PROPAGATION_SCHEDULEプロシージャ, 16.2.3 ALTER_RULEプロシージャ, 18.2.2 ALTER_SYNC_CAPTUREプロシージャ

取得ユーザーの設定, 15.2.2

ANALYZE_CURRENT_PERFORMANCEプロシージャ, 23.5 ANALYZE_CURRENT_STATISTICSプロシージャ, 23.2 ANYDATAデータ型

キュー, 3.2.1

監視, 25.1

削除, 16.1.3

メッセージ用のラッパー, 3.2.1 アプリケーション

アップグレード

Streamsの使用, D.3

適用済SCN, 2.5.7.1, 10.7, 24.1.12 適用による転送, 3.3.4.1 適用プロセス, 4, 10

適用済SCN, 10.7

適用による転送, 3.3.4.1

適用ハンドラ, 4.2.4, 10.3.5

Javaストアド・プロシージャ, 4.2.4.6

適用サーバー, 4.2.10

状態, 4.2.10.3

トラブルシューティング, 33.10

適用ユーザー, 4.2.1

権限, 33.7

保護キュー, 8.1.2

設定, 17.5

アーキテクチャ, 4.2.10 取得と適用の複合, 12.1

判別する問合せ, 26.16

競合ハンドラ, 10.3.5 競合解決, 10.3.4 制約, 10.3.1 競合, 33.8, 33.9 コーディネータ・プロセス, 4.2.10

状態, 4.2.10.2

作成, 10.1 データ型変換, 4.2.7 データ型, B.5.1 適用されるデータ型, 4.2.6

自動変換, 4.2.7

DDL変更, 10.4

DML変更を含む, 10.4.3

CREATE TABLE AS SELECT, 10.4.2

現行のスキーマ, B.5.5

データ構造, B.5.4

DMLの導出値, 10.4.3.1

DMLトリガー, 10.4.3.2

無視, B.5.3

システム生成名, 10.4.1

DDLハンドラ, 4.2.4, 4.2.4.3

管理, 17.7

監視, 26.4.2

依存性, 10.2

バリア・トランザクション, 10.2.6

トラブルシューティング, 33.9

仮想依存性定義, 10.2.5, 17.15, 26.18

DML変更, 10.3 DMLハンドラ, 4.2.4, 4.2.4.1, 26.4.1

変更ハンドラ, 20

削除, 17.16 メッセージのエンキュー, 17.10

監視, 26.14

エラー・ハンドラ

管理, 17.12

監視, 26.4.3

エラー・キュー, 4.2.14

監視, 26.19, 26.20

最大値, 10.7 非処理SCN, 10.5 索引構成表, B.5.1 インスタンス化SCN, 10.5 取得プロセスとの相互運用性, B.1.6, B.5.7 キー列, 10.3.1 最小値, 10.7 管理, 17 メッセージ・ハンドラ, 4.2.4, 4.2.4.4

管理, 17.8

監視, 26.4.4

メッセージ

取得LCR, 4.2.3

永続LCR, 4.2.3

ユーザー・メッセージ, 4.2.3

監視, 26

適用ハンドラ, 26.4

互換性のある列, 29.3.3.1

待機時間, 26.8, 26.11, 26.11

トランザクション, 26.10

LCR以外のメッセージ, 4.2.4.4 最も古いSCN, 10.6 オプション, 4.2.4 Oracle Label Security (OLS), B.5.6 Oracle Real Application Clusters, A.1.6 並列性, 26.13 パラメータ, 4.2.12

commit_serialization, 33.9

並列性, 33.9

preserve_encryption, A.2.6

設定, 17.4

txn_lcr_spill_threshold, 26.7

パフォーマンス, 33.10 永続的状態, 4.2.13 プリコミット・ハンドラ, 4.2.4.5

管理, 17.9

監視, 26.4.5

リーダー・サーバー, 4.2.10

状態, 4.2.10.1

RESTRICTED SESSION, 4.2.9 行のサブセット化, 5.3 ルール・セット

削除, 17.3.4

指定, 17.3.1

ルール, 4.2.2, 5.1

追加, 17.3.2

削除, 17.3.3

セッション情報, 26.5 実行の指定, 17.11

監視, 26.15

オーバーフローしたメッセージ, 26.7 SQL生成, 4.2.8 起動, 17.1 停止, 17.2 代替キー列, 10.3.2

削除, 17.14.2

設定, 17.14.1

表, 10.3

適用ハンドラ, 10.3.5

列の不一致, 10.3.3

トレース・ファイル, 30.4.3 変換

ルールベース, 6.3.4

透過的データ暗号化, A.2.6 トリガー

起動プロパティ, 10.8.1

ON SCHEMA句, 10.8.2

トラブルシューティング, 33

適用ハンドラのチェック, 33.5

メッセージ・タイプのチェック, 33.3

ステータスのチェック, 33.1

エラー・キュー, 33.11

近似CSCN, 8.3.2 AQ_TM_PROCESSES初期化パラメータ

Streamsの適用プロセス, 33.6

ARCHIVELOGモード

取得プロセス, 7.4

Recovery Manager, A.4.2

ATTACH_TABLESPACESプロシージャ, 36.1

B

バッファ・メッセージ機能, 3.2.2.1

バッファ・キュー, 3.2.2

監視, 25.2

適用プロセス, 25.2.8

取得プロセス, 25.2.2

伝播, 25.2.3, 25.2.4, 25.2.5, 25.2.6, 25.2.7

透過的データ暗号化, A.2.4 BUILDプロシージャ, 2.5.7.2, 7.5.1

トラブルシューティング, 31.1.1

C

取得

明示的, 2.7

取得プロセス, 2, 2.5, 2.6, 7

適用済SCN, 2.5.7.1, 24.1.12

アーキテクチャ, 2.5.9

ARCHIVELOGモード, 7.4

自動的にフィルタ処理された変更, 29.3.1.1

ビルダー・サーバー, 2.5.9

取得ユーザー, 2.5.10

保護キュー, 8.1.2

設定, 15.1.5

取得LCR, 4.1.1 取得済SCN, 2.5.7.1 取得される変更

DDL変更, B.1.2.3

DML変更, 2.5.4

NOLOGGINGキーワード, B.1.2.5

SQL*LoaderのUNRECOVERABLE句, B.1.2.6

UNRECOVERABLE SQLキーワード, B.1.2.5

チェックポイント, 7.2

保存時間の管理, 15.1.6

最大チェックポイントSCN, 7.2.2

必須チェックポイントSCN, 7.2.1, 7.4

保存時間, 7.2.3

取得と適用の複合, 12.1

判別する問合せ, 24.1.16

作成, 7.5 データ型の制限事項, B.1.2.1 取得されるデータ型, 2.5.3 DBID, 7.5 ダウンストリーム・キャプチャ, 2.5.6

メリット, 2.5.6.2.4

データベース・リンク, 2.5.6.2.5, 15.1.10

監視, 24.1.6

リモート・アクセスの監視, 29.1.2

操作要件, 2.5.6.2.6

削除, 15.1.11 高速リカバリ領域, A.4.2 先頭SCN, 2.5.7.2

設定, 15.1.8, 15.1.9

グローバル名, 7.5 索引構成表, B.1.2.1, B.1.2.2 適用プロセスとの相互運用性, B.1.6, B.5.7 待機時間

取得から適用まで, 26.11

REDOログのスキャン, 24.1.13

ローカル取得, 2.5.6

メリット, 2.5.6.1.2

LogMiner, 7.1

データ・ディクショナリ, 7.5.1

複数セッション, 7.1

管理, 15.1 最大チェックポイントSCN, 7.2.2, 7.5.1.2 監視, 24.1

適用済SCN, 24.1.12

互換性のある表, 29.3.1.1

ダウンストリーム・キャプチャ, 24.1.6

経過時間, 24.1.5

最後のREDOエントリ, 24.1.10

待機時間, 24.1.13, 24.1.14, 24.1.14, 26.11

メッセージ作成時刻, 24.1.4

古いログ・ファイル, 24.1.9

登録済ログ・ファイル, 24.1.7, 24.1.9

必要なログ・ファイル, 24.1.8

ルールの評価, 24.1.15

状態変化時刻, 24.1.4

オンラインでの再定義, B.1.2.4 Oracle Label Security (OLS), B.1.5 Oracle Real Application Clusters, A.1.1 パラメータ, 2.5.12

並列性, 2.5.12

set_autofiltered_table_ddl, 29.3.1.1

設定, 15.1.4

time_limit, 2.5.12

PAUSED FOR FLOW CONTROL状態, 2.5.11 永続的状態, 2.5.13 プリペアラ・サーバー, 2.5.9 リーダー・サーバー, 2.5.9 Recovery Manager, A.4.2

高速リカバリ領域, 31.1.6

REDOログ, 2.5.1

手動での追加, 15.1.7

欠落しているファイル, 31.1.6

REDO転送サービス, 2.5.6 必須チェックポイントSCN, 7.2.1 RESTRICTED SESSION, 2.5.8 ルールの評価, 7.7 ルール・セット

削除, 15.1.3.4

指定, 15.1.3.1

ルール, 2.5.2, 5.1

追加, 15.1.3.2

削除, 15.1.3.3

セッション情報, 24.1.2 SGA_MAX_SIZE初期化パラメータ, 7.1 開始SCN, 2.5.7.2, 2.5.7.2.4 起動, 15.1.1 状態, 2.5.11 停止, 15.1.2 サプリメンタル・ロギング, 2.5.5 切替え, 15.5 SYSスキーマ, 2.5.2 SYSTEMスキーマ, 2.5.2 表タイプの制限事項, B.1.2.2 トレース・ファイル, 30.4.1 変換

ルールベース, 6.3.1

透過的データ暗号化, A.2.1 トラブルシューティング, 31, 31.1

進捗のチェック, 31.1.5

ステータスのチェック, 31.1.2

作成, 31.1.1

取得ユーザー

取得プロセス, 2.5.10

同期取得, 2.6.6

取得LCR, 4.1.2.1 取得済SCN, 2.5.7.1 変更ハンドラ, 4.2.4.1.1, 20

概要, 20.1

チェンジ・テーブル, 20.1

メンテナンス, 20.4.3

監視, 20.5.1

構成オプション, 20.2.1.1 構成, 20.3 KEEP_COLUMNS変換, 20.2.1.5 管理, 20.4 監視, 20.5 準備, 20.2 前提条件, 20.2.2 レプリケーション, 20.2.1.8 設定, 20.4.1 設定解除, 20.4.1 既存のコンポーネントの使用, 20.4.2 キャラクタ・セット

移行

Streamsの使用, D.3

チェックポイント, 7.2

保存時間, 7.2.3

管理, 15.1.6

CLONE_TABLESPACESプロシージャ, 36.1 取得と適用の複合, 12.1

適用プロセス

判別する問合せ, 26.16

取得プロセス

判別する問合せ, 24.1.16

伝播

判別する問合せ, 25.3.6, 25.3.7

ストリーム・パス, 23.3.1 トポロジ, 23.3.1 COMPATIBLE_10_1ファンクション, 11.7.1.2 COMPATIBLE_10_2ファンクション, 11.7.1.2 COMPATIBLE_11_1ファンクション, 11.7.1.2 COMPATIBLE_11_2ファンクション, 11.7.1.2 COMPATIBLE_9_2ファンクション, 11.7.1.2 条件

ルール, 11.1.1

構成レポート・スクリプト

Oracle Streams, 30.2

競合解決

競合ハンドラ

適用ハンドラとの相互作用, 10.3.5

CREATE TABLE文

AS SELECT

適用プロセス, 10.4.2

CREATE_APPLYプロシージャ, 10.1 CREATE_CAPTUREプロシージャ, 7.5 CREATE_RULEプロシージャ, 18.2.1 CREATE_RULE_SETプロシージャ, 18.1.1

D

データ型

適用, 4.2.6

自動変換, 4.2.7

データベースのメンテナンス

Streamsの使用, D

前提条件, D.1.2

取得データベース, D.1.1

インスタンス化, D.2.5

ジョブ・スレーブ, D.1.3

論理的な依存性, D.2.3.2

PL/SQLパッケージのサブプログラム, D.1.3

ユーザー作成アプリケーション, D.2.3

ユーザー定義型, D.2.2

DBA_APPLYビュー, 26.1, 26.2, 26.4.2, 26.4.2, 26.4.4, 26.6, 26.12, 33.1, 33.3 DBA_APPLY_CHANGE_HANDLERSビュー, 20.4.1, 20.5.2 DBA_APPLY_DML_HANDLERSビュー, 26.4.1, 26.4.3 DBA_APPLY_ENQUEUEビュー, 26.14 DBA_APPLY_ERRORビュー, 26.19, 26.20, 26.20, 26.20 DBA_APPLY_EXECUTEビュー, 26.15 DBA_APPLY_KEY_COLUMNSビュー, 26.17 DBA_APPLY_PARAMETERSビュー, 26.3 DBA_APPLY_PROGRESSビュー, 26.11 DBA_APPLY_SPILL_TXNビュー, 26.7 DBA_CAPTUREビュー, 24.1.1, 24.1.6, 24.1.7, 24.1.8, 24.1.9, 24.1.12, 31.1.2 DBA_CAPTURE_EXTRA_ATTRIBUTESビュー, 24.3 DBA_CAPTURE_PARAMETERSビュー, 24.1.11 DBA_EVALUATION_CONTEXT_TABLESビュー, 27.6 DBA_EVALUATION_CONTEXT_VARSビュー, 27.7 DBA_FILE_GROUP_EXPORT_INFOビュー, 37.2.3 DBA_FILE_GROUP_FILESビュー, 37.1.3 DBA_FILE_GROUP_TABLESビュー, 37.2.2 DBA_FILE_GROUP_TABLESPACESビュー, 37.2.1 DBA_FILE_GROUP_VERSOINSビュー, 37.1.2 DBA_FILE_GROUPSビュー, 37.1.1 DBA_LOG_GROUPSビュー, 24.1.18.1 DBA_LOGMNR_PURGED_LOGビュー, 2.5.7.2.3, 7.4 DBA_PROPAGATIONビュー, 25.2.3, 25.2.4, 25.2.5, 25.2.6, 25.3.1, 25.3.2, 25.3.3, 25.3.4, 25.3.5, 32.1, 32.2 DBA_QUEUE_SCHEDULESビュー, 25.3.4, 25.3.5 DBA_QUEUE_TABLESビュー, 25.1.1 DBA_QUEUESビュー, 25.1.1 DBA_REGISTERED_ARCHIVED_LOGビュー, 24.1.7, 24.1.8, 24.1.9 DBA_RULE_SET_RULESビュー, 27.8, 27.9 DBA_RULE_SETSビュー, 27.5 DBA_RULESビュー, 27.8, 27.9, 27.10 DBA_STREAMS_ADD_COLUMNビュー, 28.2.1 DBA_STREAMS_COLUMNSビュー, 29.3.2, 29.3.3.1 DBA_STREAMS_NEWLY_SUPPORTEDビュー, 29.3.1.2 DBA_STREAMS_RENAME_TABLEビュー, 28.2.2 DBA_STREAMS_RULESビュー, 27.3, 34.1 DBA_STREAMS_TABLE_RULESビュー, 24.2.2 DBA_STREAMS_TP_COMPONENTビュー, 23.2.1, 23.6.1.2 DBA_STREAMS_TP_COMPONENT_LINKビュー, 23.2.1, 23.6.1.3 DBA_STREAMS_TP_COMPONENT_STATビュー, 23.2.1, 23.6.2.2 DBA_STREAMS_TP_DATABASEビュー, 23.2.1, 23.6.1.1 DBA_STREAMS_TP_PATH_BOTTLENECKビュー, 23.2.1, 23.6.2.1 DBA_STREAMS_TP_PATH_STATビュー, 23.2.1, 23.6.2.4 DBA_STREAMS_TRANSFORM_FUNCTIONビュー, 28.3 DBA_STREAMS_TRANSFORMATIONSビュー, 28.1, 28.2 DBA_STREAMS_UNSUPPORTEDビュー, 29.3.1.1 DBA_SYNC_CAPTUREビュー, 24.2.1 DBA_SYNC_CAPTURE_TABLESビュー, 24.2.2 DBID (データベース識別子)

取得プロセス, 7.5

DBMS_APPLY_ADMパッケージ, 14.1.1, 17 DBMS_CAPTURE_ADMパッケージ, 14.1.2, 15.1 DBMS_COMPARISONパッケージ, 14.1.3 DBMS_PROPAGATION_ADMパッケージ, 14.1.4, 16

伝播の開始, 16.2.1

伝播の停止, 16.2.2

DBMS_RULEパッケージ, 11.2, 14.1.5 DBMS_RULE_ADMパッケージ, 14.1.6, 18, 18.1 DBMS_STREAMSパッケージ, 14.1.7 DBMS_STREAMS_ADMパッケージ, 5.3, 14.1.8, 15.1, 16, 17

取得プロセスの作成, 7.5

適用プロセスの作成, 10.1

DBMS_STREAMS_ADVISOR_ADMパッケージ, 14.1.9, 23.2

情報の収集, 23.5

DBMS_STREAMS_AUTHパッケージ, 14.1.10 DBMS_STREAMS_HANDLER_ADMパッケージ, 14.1.11 DBMS_STREAMS_MESSAGINGパッケージ, 14.1.12 DBMS_STREAMS_TABLESPACE_ADMパッケージ, 14.1.13, 36.1

情報のプロビジョニング, 35.2.3

プラットフォームの変換, 35.2.3.4

DDLハンドラ, 4.2.4, 4.2.4.3

作成, 17.7.1

管理, 17.7

監視, 26.4.2

削除, 17.7.3

設定, 17.7.2

DELETE_ALL_ERRORSプロシージャ, 17.13.2.2 DELETE_COLUMNプロシージャ, 6.1 DELETE_ERRORプロシージャ, 4.2.14, 17.13.2.1 依存性

適用プロセス, 10.2

キュー, 8.3.1

最大値のデキュー, 8.3.2 宛先キュー, 3.1 DETACH_TABLESPACESプロシージャ, 36.1 ダイレクト・パス・ロード

取得プロセス, B.1.2.6

有向ネットワーク, 3.3.4

適用による転送, 3.3.4.1

キューによる転送, 3.3.4.1

DISABLE_DB_ACCESSプロシージャ, 16.1.2 DMLハンドラ, 4.2.4, 4.2.4.1, 10.3.5

変更ハンドラ, 4.2.4.1.1, 20

管理, 17.6

監視, 26.4.1, 26.4.1

プロシージャDMLハンドラ, 4.2.4.1.2

管理, 17.6.2

監視, 26.4.1.3

文DMLハンドラ, 4.2.4.1.1

管理, 17.6.1

監視, 26.4.1.2

設定解除, 17.6.2.3 マニュアル

Oracle Streams, 1.5

DROP_APPLYプロシージャ, 17.16 DROP_CAPTUREプロシージャ, 15.1.11, 15.2.3 DROP_PROPAGATIONプロシージャ, 16.2.8 DROP_RULEプロシージャ, 18.2.4 DROP_RULE_SETプロシージャ, 18.1.4

E

ENABLE_DB_ACCESSプロシージャ, 16.1.1

エラー・ハンドラ, 10.3.5

作成, 17.12.1

管理, 17.12

監視, 26.4.3

設定, 17.12.2

設定解除, 17.12.3

エラー・キュー, 4.2.14

適用プロセス, 33.11

エラーの削除, 17.13.2

エラーの実行, 17.13.1

監視, 26.19, 26.20

透過的データ暗号化, A.2.6

EVALUATEプロシージャ, 11.2 評価コンテキスト, 11.1.2

ルール・セットとの関連付け, 11.1.2.2

ルールとの関連付け, 11.1.2.2

評価ファンクション, 11.1.2.3

オブジェクト権限

付与, 18.3.2

取消し, 18.3.4

システム権限

付与, 18.3.1

取消し, 18.3.3

ユーザー作成, 11.7, 11.7.2 変数, 11.1.2.1 イベント・コンテキスト

システム作成ルール, 11.5

EXECUTEメンバー・プロシージャ, 17.7.1, 17.12.1 EXECUTE_ALL_ERRORSプロシージャ, 17.13.1.2 EXECUTE_ERRORプロシージャ, 4.2.14, 17.13.1.1 明示的取得, 1.2.1, 2.7

機能, 2.7.2

メッセージ・タイプ, 2.7.1

透過的データ暗号化, A.2.3

明示的コンシューム

デキュー, 4.4

エクスポート

データベースのメンテナンス, D.2.5

データベースのアップグレード, E.2.2

Oracle Streams, 21.1

F

高速リカバリ領域

取得プロセス, A.4.2

アーカイブREDOログ・ファイル, 31.1.6

ファイル・グループ・リポジトリ, 35.2.3.1

監視, 37, 37.1

使用, 36.2

先頭SCN, 2.5.7.2 フラッシュバック・データ・アーカイブ

Oracle Streams, A.3

フロー制御, 2.5.11

G

GET_BASE_TABLE_NAMEメンバー・ファンクション, 17.7.1

GET_COMMA, 26.20

GET_COMMAND_TY, 17.7.1

GET_COMMAND_TYPEメンバー・ファンクション, 17.12.1, 17.13.1.1.2

GET_COMPATIBLEメンバー・ファンクション, 11.7.1.2

GET_DDL_TEXTメンバー・ファンクション, 26.20

GET_ERROR_MESSAGEファンクション, 26.20, 26.20

GET_INFORMATIONファンクション, 17.12.1

GET_NEXT_HITファンクション, 11.2

GET_OBJECT_NAMEメンバー・ファンクション, 17.12.1, 17.13.1.1.2, 19.2.1, 26.20

GET_OBJECT_OWNERメンバー・ファンクション, 17.13.1.1.2, 19.2.1, 26.20

GET_SCNメンバー・ファンクション, 17.7.1

GET_SOURCE_DATABASE_NAMEメンバー・ファンクション, 17.7.1, 26.20

GET_STREAMS_NAMEファンクション, 17.12.1

GET_TAGメンバー・ファンクション, 17.7.1

GET_TRANSACTION_IDメンバー・ファンクション, 17.7.1

GET_VALUEメンバー・ファンクション, 17.13.1.1.2

LCR, 19.2.1

GET_VALUESメンバー・ファンクション, 17.12.1, 26.20 グローバル名

取得プロセス, 7.5

GLOBAL_NAMEビュー, 24.1.6, 32.1 GRANT_OBJECT_PRIVILEGEプロシージャ, 11.3 GRANT_SYSTEM_PRIVILEGEプロシージャ, 11.3 グリッド

情報のプロビジョニング, 35

H

ヘルス・チェック・スクリプト

Oracle Streams, 30.2

高可用性

Streams, 13

メリット, 13.2.1

適用, 13.3.2.4

ベスト・プラクティス, 13.3

取得, 13.3.2.1

データベース・リンク, 13.3.2.2

伝播, 13.3.2.3

最大値, 10.7

I

非処理SCN, 10.5

暗黙的取得, 1.2.1

管理, 15

切替えメカニズム, 15.4, 15.5

インポート

データベースのメンテナンス, D.2.5

データベースのアップグレード, E.2.2

Oracle Streams, 21.1

INCLUDE_EXTRA_ATTRIBUTEプロシージャ, 2.2.1.3, 15.3 索引構成表

適用プロセス, B.5.1

取得プロセス, B.1.2.1, B.1.2.2

同期取得, 2.6.5, B.2.3.1

処理中のトランザクション, 31.1.1 情報のプロビジョニング, 35

バルク・プロビジョニング, 35.2

データ・ポンプ, 35.2.1

DBMS_STREAMS_TABLESPACE_ADMパッケージ, 35.2.3 ファイル・グループ・リポジトリ, 35.2.3.1 増分プロビジョニング, 35.3 オンデマンドでの情報へのアクセス, 35.4 RMAN

バックアップからのトランスポータブル表領域, 35.2.2

表領域リポジトリ, 35.2.3.2 使用, 36 初期化パラメータ

AQ_TM_PROCESSES

Streamsの適用プロセス, 33.6

インスタンス化

例

RMANのCONVERT DATABASE, D.3.3.3

RMANのDUPLICATE, D.3.3.2, E.3.3.2

エクスポート/インポート, D.2.5, E.2.2 Streams, 2.4 RMANのCONVERT DATABASE, D.2.5 RMANのDUPLICATE, D.2.5, E.2.2 インスタンス化SCN, 10.5 相互運用性

互換性, 29.3

Streams, 29.3.1.2

IS_NULL_TAGメンバー・ファンクション, 26.20 IS_TRIGGER_FIRE_ONCEファンクション, 10.8.1

K

KEEP_COLUMNSプロシージャ, 6.1

L

LCR。「論理変更レコード」を参照

論理変更レコード(LCR), 2.2.1, 17.12.1

DDL LCR, 2.2.1.2

current_schema, B.5.5

ルール, 5.3.3.1.2, 5.3.6.1.2

追加の属性, 2.2.1.3

管理, 15.3

監視, 24.3

情報の取得, 17.7.1, 19.2.1, 26.20

互換性, 11.7.1.2

行LCR, 2.2.1.1

ルール, 5.3.1.1

XMLスキーマ, C LogMiner

取得プロセス, 7.1

複数セッション, 7.1

最小値, 10.7

M

MAINTAIN_CHANGE_TABLEプロシージャ

例, 20.3

準備, 20.2

前提条件, 20.2.2

MAINTAIN_GLOBALプロシージャ, 35.3 MAINTAIN_SCHEMASプロシージャ, 35.3 MAINTAIN_SIMPLE_TTSプロシージャ, 35.3 MAINTAIN_TABLESプロシージャ, 35.3 MAINTAIN_TTSプロシージャ, 35.3 MAX_COMPATIBLEファンクション, 11.7.1.2 最大チェックポイントSCN, 7.5.1.2 ストリームのマージ, 30.3 MERGE_STREAMS_JOBプロシージャ, 30.3 メッセージ・ハンドラ, 4.2.4, 4.2.4.4

管理, 17.8

監視, 26.4.4

設定, 17.8.1

設定解除, 17.8.2

メッセージ

取得, 4.1.2.1

取得LCR, 4.1.1

デキュー, 4.1.1

エンキュー, 2.7

永続LCR, 4.1.1, 4.1.2.2

永続ユーザー・メッセージ, 4.1.2.4

伝播, 3.3

ユーザー・メッセージ, 4.1.1, 4.1.2.4

メッセージ機能, 3.2.1

バッファ・メッセージ機能, 3.2.2.1

デキュー, 4.4

透過的データ暗号化, A.2.8

エンキュー, 2.7 メッセージ・クライアント, 4.3

メッセージ・クライアント・ユーザー

保護キュー, 8.1.2

変換

ルールベース, 6.3.5

メッセージ・クライアント

透過的データ暗号化, A.2.7, A.2.8

移行

異なるキャラクタ・セット

Streamsの使用, D.3

異なるオペレーティング・システム

Streamsの使用, D.3

監視

ANYDATAデータ型のキュー, 25.1

メッセージのコンシューマ, 25.1.4

イベントの内容の表示, 25.1.5

適用プロセス, 26

適用ハンドラ, 26.4

互換性のある列, 29.3.3.1

DDLハンドラ, 26.4.2

エラー・ハンドラ, 26.4.3

エラー・キュー, 26.19, 26.20

メッセージ・ハンドラ, 26.4.4

取得プロセス, 24.1

適用済SCN, 24.1.12

互換性のある表, 29.3.1.1

経過時間, 24.1.5

待機時間, 24.1.13, 24.1.14, 24.1.14, 26.11

メッセージ作成時刻, 24.1.4

ルールの評価, 24.1.15

状態変化時刻, 24.1.4

互換性, 29.3 DMLハンドラ, 26.4.1 ファイル・グループ・リポジトリ, 37 Oracle Streams, 22

パフォーマンス, 23.2, 29.4

伝播ジョブ, 25.3 伝播, 25, 25.3 キュー, 25 ルールベースの変換, 28 ルール, 27 サプリメンタル・ロギング, 24.1.18 同期取得, 24.2

互換性のある列, 29.3.2

待機時間, 26.11

表領域リポジトリ, 37 マルチバージョン・データ・ディクショナリ

欠落, 34.1.5

N

NOLOGGINGモード

取得プロセス, B.1.2.5

O

最も古いSCN, 10.6

ON SCHEMA句

CREATE TRIGGER

適用プロセス, 10.8.2

オンラインでの再定義

取得プロセス, B.1.2.4

同期取得, B.2.3.3

オペレーティング・システム

移行

Streamsの使用, D.3

ORA-01291エラー, 31.1.6 ORA-01403エラー, 33.11.2.2 ORA-06550エラー, 33.7 ORA-23605エラー, 33.11.2.3 ORA-23607エラー, 33.11.2.4 ORA-24031エラー, 33.11.2.5 ORA-24093エラー, 32.3.1 ORA-25224エラー, 32.3.2 ORA-26666エラー, 33.1 ORA-26678エラー, 31.1.8 ORA-26687エラー, 33.11.2.6 ORA-26688エラー, 33.11.2.7 ORA-26689エラー, 33.11.2.8 Oracle Data Pump

情報のプロビジョニング, 35.2.1

Oracle Enterprise Manager

Streamsツール, 14.3

Oracle Label Security (OLS)

適用プロセス, B.5.6

取得プロセス, B.1.5

同期取得, B.2.5

Oracle Real Application Clusters

Oracle Streamsとの相互運用性, A.1, A.1.1, A.1.2, A.1.4, A.1.6

キュー, A.1.4

Oracle Scheduler

伝播ジョブ, 9.1

Oracle Streams

管理者

監視, 29.1.1

アラート・ログ, 30.4 アラート, 30.1 適用プロセス, 4, 10 取得プロセス, 2, 2.5, 2.6, 7 互換性, 11.7.1.2, 29.3 データ・ディクショナリ, 9.2, 10.9, 22 データベースのメンテナンス, D 有向ネットワーク, 3.3.4 ドキュメント・ロードマップ, 1.5 エクスポート・ユーティリティ, 21.1 フラッシュバック・データ・アーカイブ, A.3 ヘルス・チェック・スクリプト, 30.2 高可用性, 13 インポート・ユーティリティ, 21.1 情報のプロビジョニング, 35.3 インスタンス化, 2.4 相互運用性, 29.3.1.2 Oracle Real Application Clustersとの相互運用性, A.1 透過的データ暗号化との相互運用性, A.2 論理変更レコード(LCR), 2.2.1

XMLスキーマ, C

LogMinerデータ・ディクショナリ, 7.5.1 メッセージ機能, 3.2.1 メッセージ・クライアント, 4.3 監視, 22 概要, 1.1 パッケージ, 14.1 伝播, 3, 9

Oracle Real Application Clusters, A.1.4

キュー, 8

Oracle Real Application Clusters, A.1.4

ルール, 5

アクション・コンテキスト, 11.6

評価コンテキスト, 5.3, 11.4

イベント・コンテキスト, 11.5

サブセット・ルール, 5.3, 5.3.4

システム作成, 5.3

ステージング, 3

Oracle Real Application Clusters, A.1.4

Streamsデータ・ディクショナリ, 7.6 Streamsプール

監視, 29.2

Streamsツール, 14.3 サプリメンタル・ロギング, 2.5.5 同期取得, 2.6 タグ, 1.2.7 トポロジ, 23.1 トレース・ファイル, 30.4 変換

ルールベース, 6

透過的データ暗号化, A.2.4 トラブルシューティング, 30, 31, 32, 33, 34 オンラインでのアップグレード, D, E ユーザー・メッセージ, 3.1 Oracle Streamsパフォーマンス・アドバイザ, 23.2

情報の収集, 23.5

Streamsコンポーネント, 23.2.2

統計の表示, 23.6.2

ボトルネック・コンポーネント, 23.6.2.1

コンポーネント・レベル, 23.6.2.2

待機時間, 23.6.2.2

速度, 23.6.2.2

セッション・レベル, 23.6.2.3

ストリーム・パス, 23.6.2.4

P

パッチ

適用

Streamsの使用, D.3

パフォーマンス

Oracle Streamsパフォーマンス・アドバイザ, 23.2

情報の収集, 23.5

Streamsコンポーネント, 23.2.2

統計の表示, 23.6.2

永続LCR, 4.1.2.2 永続ユーザー・メッセージ, 4.1.2.4 POST_INSTANTIATION_SETUPプロシージャ, 35.3 PRE_INSTANTIATION_SETUPプロシージャ, 35.3 プリコミット・ハンドラ, 4.2.4.5

作成, 17.9.1

管理, 17.9

監視, 26.4.5

設定, 17.9.2

設定解除, 17.9.3

SCNの準備, 2.5.7.2.4 権限

Oracle Streams管理者

監視, 29.1.1

ルール, 11.3 プロシージャDMLハンドラ, 4.2.4.1.2

作成, 17.6.2.1

管理, 17.6.2

監視, 26.4.1.3

設定, 17.6.2.2, 17.6.2.2

SQL生成, 17.6.2.1

設定解除, 17.6.2.3

伝播

取得と適用の複合, 12.1

判別する問合せ, 25.3.6, 25.3.7

伝播受信者, 25.3.7 伝播送信者, 25.3.6 伝播ジョブ, 9.1

変更, 16.2.3

管理, 16.2

監視, 25.3

Oracle Scheduler, 9.1

RESTRICTED SESSION, 9.1.2

スケジューリング, 9.1.1

トレース・ファイル, 30.4.2

トラブルシューティング, 32

伝播, 3, 3.3, 9

バイナリ・ファイル, 9.3

バッファ・キュー, 3.2.2

宛先キュー, 3.1

有向ネットワーク, 3.3.4

削除, 16.2.8

保証付きの配信, 3.3.3

管理, 16.2

監視, 25, 25.3

キュー・ツー・キュー, 3.3.2, 3.3.2, 25.3.1

Oracle Real Application Clusters, A.1.4

伝播ジョブ, 9.1

スケジュール, 16.2.3.1

ルール・セット

削除, 16.2.7

指定, 16.2.4

ルール, 3.3.1, 5.1

追加, 16.2.5

削除, 16.2.6

セッション情報, 25.3.8 ソース・キュー, 3.1 起動, 16.2.1 停止, 16.2.2 変換

ルールベース, 6.3.3

透過的データ暗号化, A.2.5 トラブルシューティング, 32

キューのチェック, 32.1

ステータスのチェック, 32.2

セキュリティ, 32.3

Q

キューによる転送, 3.3.4.1

キュー

ANYDATA, 3.2.1

削除, 16.1.3

参照, 8.3.1.2 バッファ, 3.2.2 コミット時間, 8.3 依存性, 8.3.1 最大値のデキュー, 8.3.2 監視, 25 非トランザクション, 8.2 Oracle Real Application Clusters, A.1.4 キュー表, 3.2.2

トリガー, 3.2.2

保護, 8.1

ユーザー・アクセスの無効化, 16.1.2

ユーザー・アクセスの有効化, 16.1.1

ユーザー, 8.1.2

同期取得, 2.6.2 トランザクション, 8.2 型付き, 3.2.1 キュー・ツー・キュー伝播, 3.3.2, 3.3.2, 25.3.1

スケジュール, 16.2.3.1

R

RE$NV_LIST型, 11.2

ADD_PAIRメンバー・プロシージャ, 18.2.2.2, 18.2.2.3, 19.2.1, 19.2.2

REMOVE_PAIRメンバー・プロシージャ, 18.2.2.2, 18.2.2.4, 19.2.2, 19.2.3

Recovery Manager

取得プロセス

アーカイブREDOログ・ファイル, A.4.2

高速リカバリ領域, 31.1.6

CONVERT DATABASEコマンド

Streamsのインスタンス化, D.2.5, D.3.3.3

DUPLICATEコマンド

Streamsのインスタンス化, D.2.5, D.3.3.2, E.2.2, E.3.3.2

情報のプロビジョニング, 35.2.2 REDOログ

取得プロセス, 2.5.1

REMOVE_PAIRメンバー・プロシージャ, 18.2.2.2, 18.2.2.4, 19.2.2, 19.2.2, 19.2.3 REMOVE_QUEUEプロシージャ, 16.1.3 REMOVE_RULEプロシージャ, 15.1.3.3, 16.2.6, 17.3.3, 18.1.3 RENAME_COLUMNプロシージャ, 6.1, 19.1.2 RENAME_SCHEMAプロシージャ, 6.1 RENAME_TABLEプロシージャ, 6.1, 19.1.1.1, 19.1.3 レプリケーション

分割とマージ, 30.3

必須チェックポイントSCN, 7.4 RESTRICTED SESSIONシステム権限

適用プロセス, 4.2.9

取得プロセス, 2.5.8

伝播ジョブ, 9.1.2

REVOKE_OBJECT_PRIVILEGEプロシージャ, 11.3 REVOKE_SYSTEM_PRIVILEGEプロシージャ, 11.3 RMAN「Recovery Manager」を参照 行の移行, 5.3.4.2, 5.3.4.2 ルール・セット, 11.1

ルールの追加, 18.1.2

作成, 18.1.1

削除, 18.1.4

評価, 11.2

部分的, 11.2.2

ネガティブ, 5.2 オブジェクト権限

付与, 18.3.2

取消し, 18.3.4

ポジティブ, 5.2 ルールの削除, 18.1.3 システム権限

付与, 18.3.1

取消し, 18.3.3

ルールベースの変換, 6

カスタム, 6.2

アクション・コンテキスト, 6.2.1

変更, 19.2.2

作成, 19.2.1

管理, 19.2

監視, 28.3

権限, 6.2.2

削除, 19.2.3

宣言, 6.1

追加, 19.1.1

管理, 19.1

監視, 28.2

削除, 19.1.3

ステップ番号, 6.4.1

トラブルシューティング, 34.2

管理, 19 監視, 28 順序付け, 6.4 ルール, 11

アクション・コンテキスト, 11.1.3

名前/値ペアの追加, 18.2.2.2, 18.2.2.3, 19.2.1, 19.2.2

変更, 18.2.2.2

名前/値ペアの削除, 18.2.2.4, 19.2.2, 19.2.3

変換, 6.2.1

ADD_RULEプロシージャ, 11.1.2.2 変更, 18.2.2 適用プロセス, 4.2.2, 5.1 取得プロセス, 2.5.2, 5.1 コンポーネント, 11.1 作成, 18.2.1 DBMS_RULEパッケージ, 11.2 DBMS_RULE_ADMパッケージ, 18 削除, 18.2.4 EVALUATEプロシージャ, 11.2 評価, 11.2

取得プロセス, 7.7

イテレータ, 11.2

部分的, 11.2.2

評価コンテキスト, 11.1.2

評価ファンクション, 11.1.2.3

ユーザー作成, 11.7.2

変数, 11.1.2.1

イベント・コンテキスト, 11.2 明示的変数, 11.1.2.1 暗黙的変数, 11.1.2.1 繰返しの結果, 11.2 管理, 18.1 MAYBEルール, 11.2 監視, 27 オブジェクト権限

付与, 18.3.2

取消し, 18.3.4

部分評価, 11.2.2 権限, 11.3

管理, 18.3

伝播, 3.3.1, 5.1 ルール条件, 5.3.3, 5.3.4, 11.1.1

複合, 11.7.1.3

明示的変数, 11.1.2.1

パターンの検索, 27.10

暗黙的変数, 11.1.2.1

Streamsの互換性, 11.7.1.2

操作のタイプ, 11.7.1.1

未定義変数, 11.7.1.4

NOTの使用, 11.7.1.3.1

変数, 5.3.1.1

rule_hits, 11.2 単純ルール, 11.1.1.2 サブセット, 5.3.4

アクション・コンテキストの問合せ, 19.2.1

名前の問合せ, 19.2.1

同期取得, 2.6.3 システム権限

付与, 18.3.1

取消し, 18.3.3

システム作成, 5, 5.3

アクション・コンテキスト, 11.6

and_conditionパラメータ, 5.3.7

DDLルール, 5.3.3.1.2, 5.3.6.1.2

DMLルール, 5.3.1.1

評価コンテキスト, 5.3, 11.4

イベント・コンテキスト, 11.5

グローバル, 5.3.1

変更, 18.2.3

行の移行, 5.3.4.2

スキーマ, 5.3.2

STREAMS$EVALUATION_CONTEXT, 5.3, 11.4

サブセット, 5.3, 5.3.4

表, 5.3.3

トラブルシューティング, 34 TRUEルール, 11.2 ユーザー作成, 11.7 変数, 11.1.2.1

S

スクリプト

Oracle Streams, 30.2

保護キュー, 8.1

ユーザー・アクセスの無効化, 16.1.2

ユーザー・アクセスの有効化, 16.1.1

伝播, 32.3

Streamsクライアント

ユーザー, 8.1.2

SET_CHANGE_HANDLERプロシージャ, 20.4.1 SET_DML_HANDLERプロシージャ, 4.2.4.1.1, 4.2.4.1.2

DMLハンドラの設定, 17.6.2.2

エラー・ハンドラの設定, 17.12.2

DMLハンドラの設定解除, 17.6.2.3, 17.6.2.3

エラー・ハンドラの設定解除, 17.12.3

SET_ENQUEUE_DESTINATIONプロシージャ, 17.10 SET_EXECUTEプロシージャ, 17.11 SET_KEY_COLUMNSプロシージャ, 10.3.2

代替キー列の削除, 17.14.2

代替キー列の設定, 17.14.1

SET_PARAMETERプロシージャ

適用プロセス, 17.4, 33.9

取得プロセス, 15.1.4

SET_RULE_TRANSFORM_FUNCTIONプロシージャ, 19.2 SET_TRIGGER_FIRING_PROPERTYプロシージャ, 10.8.1 SET_VALUEメンバー・プロシージャ, 17.13.1.1.2, 19.2.1 SET_VALUESメンバー・プロシージャ, 17.12.1, 17.12.1 SGA_MAX_SIZE初期化パラメータ, 7.1 ソース・キュー, 3.1 ストリームの分割, 30.3 SPLIT_STREAMSプロシージャ, 30.3 SQL生成, 4.2.8

キャラクタ・セット, 4.2.8.4

サポートされているデータ型, 4.2.8.3

例, 4.2.8.5, 17.6.2.1

書式, 4.2.8.2

インタフェース, 4.2.8.1

プロシージャDMLハンドラ, 17.6.2.1

SQL*Loader

取得プロセス, B.1.2.6

ステージング, 3

近似CSCN, 8.3.2

バッファ・キュー, 3.2.2

監視, 25.2

管理, 16 メッセージ, 4.1.1 保護キュー, 8.1

ユーザー・アクセスの無効化, 16.1.2

ユーザー・アクセスの有効化, 16.1.1

開始SCN, 2.5.7.2 START_APPLYプロシージャ, 17.1 START_CAPTUREプロシージャ, 15.1.1 START_PROPAGATIONプロシージャ, 16.2.1 文DMLハンドラ, 4.2.4.1.1

文の追加, 17.6.1.2

作成, 17.6.1.1

削除, 17.6.1.6

管理, 17.6.1

変更, 17.6.1.3

監視, 26.4.1.2

適用プロセスからの削除, 17.6.1.5

文の削除, 17.6.1.4

Statspack

Oracle Streams, 29.4

STOP_APPLYプロシージャ, 17.2 STOP_CAPTUREプロシージャ, 15.1.2 STOP_PROPAGATIONプロシージャ, 16.2.2 ストリーム・パス, 23.3

取得と適用の複合, 23.3.1

Streamsデータ・ディクショナリ, 7.6, 9.2, 10.9 ストリーム・パス

統計情報, 23.6.2.4

Streamsプール

監視, 29.2

Streams。「Oracle Streams」を参照 Streamsツール, 14.3 Streamsトポロジ

DBMS_STREAMS_ADVISOR_ADMパッケージ

情報の収集, 23.5

STREAMS$_EVALUATION_CONTEXT, 5.3, 11.4 STREAMS$_TRANSFORM_FUNCTION, 6.2.1 サプリメンタル・ロギング, 2.5.5

条件付きログ・グループ, 2.5.5

DBA_LOG_GROUPSビュー, 24.1.18.1

監視, 24.1.18

無条件ログ・グループ, 2.5.5

同期取得, 2.6

取得ユーザー, 2.6.6

設定, 15.2.2

取得される変更

DML変更, 2.6.5

データ型の制限事項, B.2.3.1 取得されるデータ型, 2.6.4 削除, 15.2.3 索引構成表, 2.6.5, B.2.3.1 待機時間

取得から適用まで, 26.11

管理, 15.2 監視, 24.2

互換性のある列, 29.3.2

オンラインでの再定義, B.2.3.3 Oracle Label Security (OLS), B.2.5 Oracle Real Application Clusters, A.1.2 キュー, 2.6.2 ルール・セット

指定, 15.2.1.1

ルール, 2.6.3

追加, 15.2.1.2

変更, 2.6.3, 18.2.2.1

切替え, 15.4 SYSスキーマ, 2.6.3 SYSTEMスキーマ, 2.6.3 表タイプの制限事項, B.2.3.2 変換

ルールベース, 6.3.2

透過的データ暗号化, A.2.2 SYS.AnyData。「ANYDATAデータ型」を参照 システム変更番号(SCN)

取得プロセスの適用済SCN, 2.5.7.1, 24.1.12

適用プロセスの適用済SCN, 10.7

取得プロセスの取得済SCN, 2.5.7.1

取得プロセスの先頭SCN, 2.5.7.2

取得プロセスの最大チェックポイントSCN, 7.2.2

適用プロセスの最も古いSCN, 10.6

取得プロセスの必須チェックポイントSCN, 7.2.1

取得プロセスの開始SCN, 2.5.7.2

システム生成名

適用プロセス, 10.4.1

T

表

索引構成

取得プロセス, B.1.2.2

表領域リポジトリ, 35.2.3.2

作成, 36.1.1

監視, 37, 37.2

使用, 36.1

共有ファイル・システムあり, 36.1.2

共有ファイル・システムなし, 36.1.3

タグ, 1.2.7 トポロジ

コンポーネントID, 23.3

DBMS_STREAMS_ADVISOR_ADMパッケージ

情報の収集, 23.5

情報の収集, 23.5 Oracle Streams, 23.1 ストリーム・パス, 23.3

取得と適用の複合, 23.3.1

統計情報, 23.6.2.4

表示, 23.6.1.3

表示, 23.6.1 トレース・ファイル

Oracle Streams, 30.4

変換

カスタム・ルールベース, 6.2

アクション・コンテキスト, 6.2.1

変更, 19.2.2

作成, 19.2.1

監視, 28.3

削除, 19.2.3

STREAMS$_TRANSFORM_FUNCTION, 6.2.1

トラブルシューティング, 34.3

宣言ルールベース, 6.1

監視, 28.2

トラブルシューティング, 34.2

Oracle Streams, 6 ルールベース, 6

適用プロセス, 6.3.4

取得プロセス, 6.3.1

適用中のエラー, 6.3.4.1

取得中のエラー, 6.3.1.1

デキュー中のエラー, 6.3.5.1

伝播中のエラー, 6.3.3.1

管理, 19

メッセージ・クライアント, 6.3.5

監視, 28

複数, 6.3.6

伝播, 6.3.3

同期取得, 6.3.2

データの透過的な暗号化

適用プロセス, A.2.6

バッファ・キュー, A.2.4

取得プロセス, A.2.1

デキュー, A.2.8

エラー・キュー, A.2.6

明示的取得, A.2.3

メッセージ・クライアント, A.2.7, A.2.8

伝播, A.2.5

同期取得, A.2.2

透過的データ暗号化

Oracle Streamsとの相互運用性, A.2

トリガー

起動プロパティ, 10.8.1

キュー表, 3.2.2

システム・トリガー

SCHEMA, 10.8.2

トラブルシューティング

アラート, 30.1

適用プロセス, 33

適用ハンドラのチェック, 33.5

メッセージ・タイプのチェック, 33.3

ステータスのチェック, 33.1

エラー・キュー, 33.11

パフォーマンス, 33.10

取得プロセス, 31, 31.1

進捗のチェック, 31.1.5

ステータスのチェック, 31.1.2

作成, 31.1.1

カスタム・ルールベースの変換, 34.3 マルチバージョン・データ・ディクショナリの欠落, 34.1.5 Oracle Streams, 30, 31, 32, 33, 34 伝播ジョブ, 32 伝播, 32

キューのチェック, 32.1

ステータスのチェック, 32.2

セキュリティ, 32.3

ルール, 34

U

UNRECOVERABLE句

SQL*Loader

取得プロセス, B.1.2.6

UNRECOVERABLE SQLキーワード

取得プロセス, B.1.2.5

アップグレード

Streamsを使用したオンライン, D, E

前提条件, E.1.2

取得データベース, E.1.1

インスタンス化, E.2.2

ジョブ・キュー・プロセス, E.1.3

PL/SQLパッケージのサブプログラム, E.1.3

ユーザー定義型, E.2.1

ユーザー・メッセージ, 3.1, 4.1.2.4 UTL_SPADVパッケージ, 14.1.14

V

V$ARCHIVE_DESTビュー, 24.1.6

V$ARCHIVED_LOGビュー, 2.5.7.2

V$BUFFERED_PUBLISHERSビュー, 25.2.2

V$BUFFERED_QUEUESビュー, 25.2.1, 25.2.6, 25.2.8

V$BUFFERED_SUBSCRIBERSビュー, 25.2.6, 25.2.8

V$DATABASEビュー

サプリメンタル・ロギング, 24.1.18.2

V$PROPAGATION_RECEIVERビュー, 25.2.7, 25.3.7 V$PROPAGATION_SENDERビュー, 25.2.3, 25.2.4, 25.2.5, 25.3.6 V$RULEビュー, 27.14 V$RULE_SETビュー, 27.12, 27.13 V$RULE_SET_AGGREGATE_STATSビュー, 27.11 V$SESSIONビュー, 24.1.2, 24.1.3, 25.3.8, 26.5, 26.6, 26.8, 26.9, 26.12 V$STREAMS_APPLY_COORDINATORビュー, 4.2.10.2, 26.9, 26.10, 26.11 V$STREAMS_APPLY_READERビュー, 4.2.10.1, 26.6, 26.7, 26.8, 26.16 V$STREAMS_APPLY_SERVERビュー, 4.2.10.3, 26.12, 26.13, 33.10 V$STREAMS_CAPTUREビュー, 2.5.11, 24.1.3, 24.1.4, 24.1.5, 24.1.10, 24.1.13, 24.1.14, 24.1.14, 24.1.15, 24.1.16, 31.1.5 V$STREAMS_POOL_ADVICEビュー, 29.2 仮想依存性定義, 10.2.5

オブジェクトの依存性, 10.2.5.2

管理, 17.15.2

監視, 26.18.2

値の依存性, 10.2.5.1

管理, 17.15.1

監視, 26.18.1

W

ウォレット

Oracle Streams, A.2.4

X

XMLスキーマ

LCR用, C

オラクル社の法律上の注意点について

コピーライトについて

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）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

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

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。