Oracle Streams概要および管理, 10gリリース1（10.ഀㇿotndnld.oracle.co.jp/.../doc_v12/server.101/B12438-01.pdfOracle Streams 概要および管理, 10g リリース1（10.1）

Oracle® Streams概要および管理

10g リリース 1（10.1）

部品番号部品番号部品番号部品番号 : B12438-01

2004 年 1 月

Oracle Streams 概要および管理 , 10g リリース 1（10.1）

部品番号 : B12438-01

原本名 : Oracle Streams Concepts and Administration, 10g Release 1 (10.1)

原本部品番号 : B10727-01

原本著者 : Randy Urbano

原本協力者 : Sundeep Abraham、Nimar Arora、Lance Ashdown、Ram Avudaiappan、Sukanya Balaraman、Neerja Bhatt、Ragamayi Bhyravabhotla、Chipper Brown、Diego Cassinera、Debu Chatterjee、Jack Chung、Alan Downing、Lisa Eldridge、Curt Elsbernd、Yong Feng、Jairaj Galagali、Brajesh Goyal、Connie Green、Sanjay Kaluskar、Lewis Kaplan、Joydip Kundu、Anand Lakshminath、Jing Liu、Edwina Lu、Raghu Mani、Pat McElroy、Krishnan Meiyyappan、Shailendra Mishra、Tony Morales、Bhagat Nainani、Anand Padmanaban、Maria Pratt、Arvind Rajaram、Viv Schupmann、Vipul Shah、Neeraj Shodhan、Wayne Smith、Benny Souder、Jim Stamos、Janet Stern、Mahesh Subramaniam、Kapil Surlaker、Bob Thome、Hung Tran、Ramkumar Venkatesan、Byron Wang、Wei Wang、James M. Wilson、Lik Wong、David Zhang、Valarie Moore

Copyright © 2002, 2003 Oracle Corporation. All rights reserved.

制限付権利の説明

このプログラム（ソフトウェアおよびドキュメントを含む）には、オラクル社およびその関連会社に所有権のある情報が含まれています。このプログラムの使用または開示は、オラクル社およびその関連会社との契約に記された制約条件に従うものとします。著作権、特許権およびその他の知的財産権と工業所有権に関する法律により保護されています。

独立して作成された他のソフトウェアとの互換性を得るために必要な場合、もしくは法律によって規定される場合を除き、このプログラムのリバース・エンジニアリング、逆アセンブル、逆コンパイル等は禁止されています。

このドキュメントの情報は、予告なしに変更される場合があります。オラクル社およびその関連会社は、このドキュメントに誤りが無いことの保証は致し兼ねます。これらのプログラムのライセンス契約で許諾されている場合を除き、プログラムを形式、手段（電子的または機械的）、目的に関係なく、複製または転用することはできません。

このプログラムが米国政府機関、もしくは米国政府機関に代わってこのプログラムをライセンスまたは使用する者に提供される場合は、次の注意が適用されます。

U.S. GOVERNMENT RIGHTS

Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation, and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the Programs, including documentation and technical data, shall be subject to the licensing restrictions set forth in the applicable Oracle license agreement, and, to the extent applicable, the additional rights set forth in FAR 52.227-19, Commercial Computer Software--Restricted Rights (June 1987). Oracle Corporation, 500 Oracle Parkway, Redwood City, CA 94065.

このプログラムは、核、航空産業、大量輸送、医療あるいはその他の危険が伴うアプリケーションへの用途を目的としておりません。このプログラムをかかる目的で使用する際、上述のアプリケーションを安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。万一かかるプログラムの使用に起因して損害が発生いたしましても、オラクル社およびその関連会社は一切責任を負いかねます。

Oracle は Oracle Corporation およびその関連会社の登録商標です。その他の名称は、Oracle Corporation または各社が所有する商標または登録商標です。

目次目次目次目次

はじめにはじめにはじめにはじめに .......................................................................................................................................................................... xv

対象読者 ................................................................................................................................................................... xviこのマニュアルの構成 ........................................................................................................................................... xvi

関連ドキュメント ................................................................................................................................................... xix表記規則 .................................................................................................................................................................... xx

Oracle Streams の新機能の新機能の新機能の新機能 ............................................................................................................................... xxiii

Streams のパフォーマンスの向上 ...................................................................................................................... xxivStreams の構成および管理の拡張機能 .............................................................................................................. xxivStreams レプリケーションの拡張機能 .............................................................................................................. xxxi

Streams メッセージの拡張機能 ......................................................................................................................... xxxvルール・インタフェースの拡張機能 .............................................................................................................. xxxvii

第第第第 I 部部部部 Streams の概要の概要の概要の概要

1 Streams の概要の概要の概要の概要

Streams の概要の概要の概要の概要 ....................................................................................................................................................... 1-2

Streams の機能 ................................................................................................................................................ 1-2

Streams を使用する理由 ................................................................................................................................ 1-4

取得プロセスの概要取得プロセスの概要取得プロセスの概要取得プロセスの概要 ............................................................................................................................................... 1-7イベントのステージングと伝播の概要イベントのステージングと伝播の概要イベントのステージングと伝播の概要イベントのステージングと伝播の概要 ............................................................................................................... 1-9

有向ネットワークの概要 ............................................................................................................................... 1-9

イベントの明示的エンキューおよびデキュー ......................................................................................... 1-11適用プロセスの概要適用プロセスの概要適用プロセスの概要適用プロセスの概要 ............................................................................................................................................. 1-12メッセージ・クライアントの概要メッセージ・クライアントの概要メッセージ・クライアントの概要メッセージ・クライアントの概要 ..................................................................................................................... 1-13

i

自動競合検出および解消の概要自動競合検出および解消の概要自動競合検出および解消の概要自動競合検出および解消の概要 ......................................................................................................................... 1-14

ルールの概要ルールの概要ルールの概要ルールの概要 ......................................................................................................................................................... 1-14変換の概要変換の概要変換の概要変換の概要 ............................................................................................................................................................. 1-15Streams タグの概要タグの概要タグの概要タグの概要 ............................................................................................................................................. 1-16

異機種間での情報共有の概要異機種間での情報共有の概要異機種間での情報共有の概要異機種間での情報共有の概要 ............................................................................................................................. 1-17

Oracle データベースから Oracle 以外のデータベースへのデータ共有の概要 .................................. 1-17

Oracle 以外のデータベースから Oracle データベースへのデータ共有の概要 .................................. 1-18

Streams 構成の例構成の例構成の例構成の例 ................................................................................................................................................. 1-20Streams 環境用の管理ツール環境用の管理ツール環境用の管理ツール環境用の管理ツール ............................................................................................................................. 1-21

オラクル社が提供する PL/SQL パッケージ ............................................................................................ 1-22

Streams のデータ・ディクショナリ・ビュー .......................................................................................... 1-24

Oracle Enterprise Manager コンソールの Streams ツール .................................................................... 1-24

2 Streams の取得プロセスの取得プロセスの取得プロセスの取得プロセス

REDO ログと取得プロセスログと取得プロセスログと取得プロセスログと取得プロセス .................................................................................................................................. 2-2論理変更レコード（論理変更レコード（論理変更レコード（論理変更レコード（LCR）））） ..................................................................................................................................... 2-2

行 LCR .............................................................................................................................................................. 2-3

DDL LCR ......................................................................................................................................................... 2-4

LCR 内の追加情報 .......................................................................................................................................... 2-5取得プロセスのルール取得プロセスのルール取得プロセスのルール取得プロセスのルール ........................................................................................................................................... 2-6

取得されるデータ型取得されるデータ型取得されるデータ型取得されるデータ型 ............................................................................................................................................... 2-7取得される変更のタイプ取得される変更のタイプ取得される変更のタイプ取得される変更のタイプ ....................................................................................................................................... 2-9

取得される DML 変更のタイプ ................................................................................................................... 2-9

取得プロセスによって無視される DDL 変更のタイプ .......................................................................... 2-10

取得プロセスによって無視されるその他のタイプの変更 ..................................................................... 2-11

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

ダイレクト・パス・ロードの UNRECOVERABLE 句 ........................................................................... 2-12

Streams 環境内のサプリメンタル・ロギング環境内のサプリメンタル・ロギング環境内のサプリメンタル・ロギング環境内のサプリメンタル・ロギング ................................................................................................. 2-13Streams 環境でのインスタンス化環境でのインスタンス化環境でのインスタンス化環境でのインスタンス化 ..................................................................................................................... 2-13ローカル取得とダウンストリーム取得ローカル取得とダウンストリーム取得ローカル取得とダウンストリーム取得ローカル取得とダウンストリーム取得 ............................................................................................................. 2-14

ローカル取得 ................................................................................................................................................. 2-14

ダウンストリーム取得 ................................................................................................................................. 2-16取得プロセスに関連する取得プロセスに関連する取得プロセスに関連する取得プロセスに関連する SCN 値値値値 ...................................................................................................................... 2-21

取得済 SCN および適用済 SCN ................................................................................................................. 2-21

先頭 SCN および開始 SCN ......................................................................................................................... 2-21Streams の取得プロセスとの取得プロセスとの取得プロセスとの取得プロセスと RESTRICTED SESSION ................................................................................... 2-24

ii

Streams の取得プロセスとの取得プロセスとの取得プロセスとの取得プロセスと Oracle Real Application Clusters .................................................................... 2-24

取得プロセスのアーキテクチャ取得プロセスのアーキテクチャ取得プロセスのアーキテクチャ取得プロセスのアーキテクチャ ......................................................................................................................... 2-25

取得プロセスのコンポーネント ................................................................................................................. 2-26

取得プロセスの状態 ..................................................................................................................................... 2-27

単一データベース内の複数の取得プロセス ............................................................................................. 2-28

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

取得プロセスの作成 ..................................................................................................................................... 2-29

新しい先頭 SCN 値および削除された LogMiner ディクショナリ情報 ............................................... 2-39

Streams データ・ディクショナリ .............................................................................................................. 2-41

ARCHIVELOG モードと取得プロセス .................................................................................................... 2-42

取得プロセスのパラメータ ......................................................................................................................... 2-43

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

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

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

イベントのステージングと伝播の概要イベントのステージングと伝播の概要イベントのステージングと伝播の概要イベントのステージングと伝播の概要 ............................................................................................................... 3-2取得イベントとユーザー・エンキュー・イベント取得イベントとユーザー・エンキュー・イベント取得イベントとユーザー・エンキュー・イベント取得イベントとユーザー・エンキュー・イベント ........................................................................................... 3-3キュー間でのイベントの伝播キュー間でのイベントの伝播キュー間でのイベントの伝播キュー間でのイベントの伝播 ............................................................................................................................... 3-4

伝播ルール ....................................................................................................................................................... 3-5

保証付きのイベント配信 ............................................................................................................................... 3-6

有向ネットワーク ........................................................................................................................................... 3-7

バイナリ・ファイルの伝播 ........................................................................................................................... 3-9メッセージ・クライアントメッセージ・クライアントメッセージ・クライアントメッセージ・クライアント ................................................................................................................................. 3-10SYS.AnyData 型のキューとユーザー・メッセージ型のキューとユーザー・メッセージ型のキューとユーザー・メッセージ型のキューとユーザー・メッセージ ....................................................................................... 3-11

SYS.AnyData キューとキューとキューとキューと Oracle Real Application Clusters .......................................................................... 3-13Streams のステージングと伝播のアーキテクチャのステージングと伝播のアーキテクチャのステージングと伝播のアーキテクチャのステージングと伝播のアーキテクチャ ......................................................................................... 3-14

バッファ・キュー ......................................................................................................................................... 3-15

伝播ジョブ ..................................................................................................................................................... 3-16

保護キュー ..................................................................................................................................................... 3-17

トランザクション型のキューと非トランザクション型のキュー ......................................................... 3-20

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

4 Streams の適用プロセスの適用プロセスの適用プロセスの適用プロセス

適用プロセスの概要適用プロセスの概要適用プロセスの概要適用プロセスの概要 ............................................................................................................................................... 4-2

適用プロセスのルール適用プロセスのルール適用プロセスのルール適用プロセスのルール ........................................................................................................................................... 4-2

iii

適用プロセスによるイベント処理適用プロセスによるイベント処理適用プロセスによるイベント処理適用プロセスによるイベント処理 ....................................................................................................................... 4-3

適用プロセスによる取得イベントとユーザー・エンキュー・イベントの処理 ................................... 4-3

適用プロセスによるイベント処理オプション ........................................................................................... 4-4適用されるデータ型適用されるデータ型適用されるデータ型適用されるデータ型 ............................................................................................................................................. 4-10

Streams の適用プロセスとの適用プロセスとの適用プロセスとの適用プロセスと RESTRICTED SESSION ................................................................................... 4-11Streams の適用プロセスとの適用プロセスとの適用プロセスとの適用プロセスと Oracle Real Application Clusters .................................................................... 4-11適用プロセスのアーキテクチャ適用プロセスのアーキテクチャ適用プロセスのアーキテクチャ適用プロセスのアーキテクチャ ......................................................................................................................... 4-12

適用プロセスのコンポーネント ................................................................................................................. 4-13

適用プロセスの作成 ..................................................................................................................................... 4-15

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

適用プロセスのパラメータ ......................................................................................................................... 4-17

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

エラー・キュー ............................................................................................................................................. 4-19

5 ルールルールルールルール

ルールの構成要素ルールの構成要素ルールの構成要素ルールの構成要素 ................................................................................................................................................... 5-2

ルール条件 ....................................................................................................................................................... 5-2

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

ルール・アクション・コンテキスト ........................................................................................................... 5-9ルール・セットの評価ルール・セットの評価ルール・セットの評価ルール・セットの評価 ......................................................................................................................................... 5-11

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

部分評価 ......................................................................................................................................................... 5-14ルールに関連するデータベース・オブジェクトと権限ルールに関連するデータベース・オブジェクトと権限ルールに関連するデータベース・オブジェクトと権限ルールに関連するデータベース・オブジェクトと権限 ................................................................................. 5-15

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

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

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

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

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

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

6 Streams でのルールの使用方法でのルールの使用方法でのルールの使用方法でのルールの使用方法

Streams でのルールの使用方法の概要でのルールの使用方法の概要でのルールの使用方法の概要でのルールの使用方法の概要 ............................................................................................................... 6-2ルール・セットとイベントのルール評価ルール・セットとイベントのルール評価ルール・セットとイベントのルール評価ルール・セットとイベントのルール評価 ........................................................................................................... 6-4

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

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

iv

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

Streams クライアントにポジティブ・ルール・セットとネガティブ・ルール・セットの両方が

存在する場合 ........................................................................................................................................... 6-5

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

ルール・セットと Streams クライアントの動作のまとめ ....................................................................... 6-6システム作成ルールシステム作成ルールシステム作成ルールシステム作成ルール ............................................................................................................................................... 6-6

グローバル・ルール ..................................................................................................................................... 6-13

スキーマ・ルール ......................................................................................................................................... 6-16

表ルール ......................................................................................................................................................... 6-18

サブセット・ルール ..................................................................................................................................... 6-21

メッセージ・ルール ..................................................................................................................................... 6-31

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

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

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

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

メッセージ・ルールの評価コンテキスト ................................................................................................. 6-42Streams とイベント・コンテキストとイベント・コンテキストとイベント・コンテキストとイベント・コンテキスト ................................................................................................................. 6-44

Streams とアクション・コンテキストとアクション・コンテキストとアクション・コンテキストとアクション・コンテキスト ............................................................................................................. 6-45

Streams でのアクション・コンテキストの用途 ...................................................................................... 6-45

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

スキーマ・ルールとグローバル・ルールに関するアクション・コンテキストの考慮事項 ............. 6-47ユーザー作成ルール、ルール・セットおよび評価コンテキストユーザー作成ルール、ルール・セットおよび評価コンテキストユーザー作成ルール、ルール・セットおよび評価コンテキストユーザー作成ルール、ルール・セットおよび評価コンテキスト ................................................................. 6-48

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

ユーザー作成評価コンテキスト ................................................................................................................. 6-56ルールベースの変換ルールベースの変換ルールベースの変換ルールベースの変換 ............................................................................................................................................. 6-56

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

ルールベースの変換と伝播 ......................................................................................................................... 6-61

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

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

ルールベースの複数の変換 ......................................................................................................................... 6-67

7 Streams 高可用性環境高可用性環境高可用性環境高可用性環境

Streams 高可用性環境の概要高可用性環境の概要高可用性環境の概要高可用性環境の概要 ............................................................................................................................... 7-2障害からの保護障害からの保護障害からの保護障害からの保護 ....................................................................................................................................................... 7-2

Streams レプリカ・データベース ................................................................................................................ 7-3

v

Streams を使用しない場合 ............................................................................................................................ 7-5

アプリケーションによるコピーのメンテナンス ....................................................................................... 7-5Streams 高可用性環境の良の実施例高可用性環境の良の実施例高可用性環境の良の実施例高可用性環境の良の実施例 ............................................................................................................... 7-6

高可用性のための Streams の構成 ............................................................................................................... 7-6

障害からのリカバリ ....................................................................................................................................... 7-8

第第第第 II 部部部部 Streams の管理の管理の管理の管理

8 Streams 環境の準備環境の準備環境の準備環境の準備

Streams 管理者の構成管理者の構成管理者の構成管理者の構成 ........................................................................................................................................... 8-2

Streams に関連する初期化パラメータの設定に関連する初期化パラメータの設定に関連する初期化パラメータの設定に関連する初期化パラメータの設定 ................................................................................................... 8-5Streams の取得プロセスを実行するためのデータベースの準備の取得プロセスを実行するためのデータベースの準備の取得プロセスを実行するためのデータベースの準備の取得プロセスを実行するためのデータベースの準備 ................................................................. 8-11ネットワーク接続性とデータベース・リンクの構成ネットワーク接続性とデータベース・リンクの構成ネットワーク接続性とデータベース・リンクの構成ネットワーク接続性とデータベース・リンクの構成 ..................................................................................... 8-11

9 取得プロセスの管理取得プロセスの管理取得プロセスの管理取得プロセスの管理

取得プロセスの作成取得プロセスの作成取得プロセスの作成取得プロセスの作成 ............................................................................................................................................... 9-2

ローカルの取得プロセスの作成 ................................................................................................................... 9-3

ログ・ファイルを暗黙的に割り当てるダウンストリーム取得プロセスの作成 ................................... 9-6

ログ・ファイルを明示的に割り当てるダウンストリーム取得プロセスの作成 ................................. 9-17

NULL 以外の開始 SCN を持つローカルの取得プロセスの作成 .......................................................... 9-22

取得プロセスの起動、停止および削除取得プロセスの起動、停止および削除取得プロセスの起動、停止および削除取得プロセスの起動、停止および削除 ............................................................................................................. 9-24

取得プロセスの起動 ..................................................................................................................................... 9-24

取得プロセスの停止 ..................................................................................................................................... 9-24

取得プロセスの削除 ..................................................................................................................................... 9-25

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

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

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

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

取得プロセスのルール・セットの削除 ..................................................................................................... 9-29取得プロセスのパラメータの設定取得プロセスのパラメータの設定取得プロセスのパラメータの設定取得プロセスのパラメータの設定 ..................................................................................................................... 9-30

取得プロセスの取得ユーザーの設定取得プロセスの取得ユーザーの設定取得プロセスの取得ユーザーの設定取得プロセスの取得ユーザーの設定 ................................................................................................................. 9-30ソース・データベースでのサプリメンタル・ロギングの指定ソース・データベースでのサプリメンタル・ロギングの指定ソース・データベースでのサプリメンタル・ロギングの指定ソース・データベースでのサプリメンタル・ロギングの指定 ..................................................................... 9-31取得プロセスへのアーカイブ取得プロセスへのアーカイブ取得プロセスへのアーカイブ取得プロセスへのアーカイブ REDO ログ・ファイルの明示的な追加ログ・ファイルの明示的な追加ログ・ファイルの明示的な追加ログ・ファイルの明示的な追加 ....................................................... 9-31

既存の取得プロセスの既存の取得プロセスの既存の取得プロセスの既存の取得プロセスの SCN 値の設定値の設定値の設定値の設定 .............................................................................................................. 9-32

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

vi

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

ダウンストリーム取得でデータベース・リンクを使用するかどうかの指定ダウンストリーム取得でデータベース・リンクを使用するかどうかの指定ダウンストリーム取得でデータベース・リンクを使用するかどうかの指定ダウンストリーム取得でデータベース・リンクを使用するかどうかの指定 ............................................. 9-34取得取得取得取得 LCR 内の追加の属性の管理内の追加の属性の管理内の追加の属性の管理内の追加の属性の管理 ...................................................................................................................... 9-35

取得 LCR への追加の属性の包含 ............................................................................................................... 9-36

取得 LCR からの追加の属性の排除 ........................................................................................................... 9-36

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

SYS.AnyData キューの管理キューの管理キューの管理キューの管理 ............................................................................................................................... 10-2

SYS.AnyData キューの作成 ........................................................................................................................ 10-2

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

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

SYS.AnyData キューの削除 ........................................................................................................................ 10-6Streams の伝播および伝播ジョブの管理の伝播および伝播ジョブの管理の伝播および伝播ジョブの管理の伝播および伝播ジョブの管理 ......................................................................................................... 10-7

伝播の作成 ..................................................................................................................................................... 10-7

伝播ジョブの有効化 ................................................................................................................................... 10-10

伝播ジョブのスケジューリング ............................................................................................................... 10-11

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

伝播ジョブのスケジュール解除 ............................................................................................................... 10-12

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

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

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

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

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

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

伝播ジョブの無効化 ................................................................................................................................... 10-17

伝播の削除 ................................................................................................................................................... 10-18Streams メッセージ環境の管理メッセージ環境の管理メッセージ環境の管理メッセージ環境の管理 ....................................................................................................................... 10-18

SYS.AnyData ラッパーでのユーザー・メッセージ・ペイロードのラップおよびエンキュー ...... 10-19

SYS.AnyData ペイロードにラップされているペイロードのデキュー .............................................. 10-21

メッセージ・クライアントおよびメッセージ通知の構成 ................................................................... 10-23

11 適用プロセスの管理適用プロセスの管理適用プロセスの管理適用プロセスの管理

適用プロセスの作成、起動、停止および削除適用プロセスの作成、起動、停止および削除適用プロセスの作成、起動、停止および削除適用プロセスの作成、起動、停止および削除 ................................................................................................. 11-2

適用プロセスの作成 ..................................................................................................................................... 11-2

適用プロセスの起動 ..................................................................................................................................... 11-9

vii

適用プロセスの停止 ..................................................................................................................................... 11-9

適用プロセスの削除 ..................................................................................................................................... 11-9適用プロセスのルール・セットの管理適用プロセスのルール・セットの管理適用プロセスのルール・セットの管理適用プロセスのルール・セットの管理 ........................................................................................................... 11-10

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

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

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

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

適用プロセス・パラメータの設定適用プロセス・パラメータの設定適用プロセス・パラメータの設定適用プロセス・パラメータの設定 ................................................................................................................... 11-14適用プロセスの適用ユーザーの設定適用プロセスの適用ユーザーの設定適用プロセスの適用ユーザーの設定適用プロセスの適用ユーザーの設定 ............................................................................................................... 11-15適用プロセスのメッセージ・ハンドラの管理適用プロセスのメッセージ・ハンドラの管理適用プロセスのメッセージ・ハンドラの管理適用プロセスのメッセージ・ハンドラの管理 ............................................................................................... 11-16

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

適用プロセスのメッセージ・ハンドラの削除 ....................................................................................... 11-17適用プロセスのプリコミット・ハンドラの管理適用プロセスのプリコミット・ハンドラの管理適用プロセスのプリコミット・ハンドラの管理適用プロセスのプリコミット・ハンドラの管理 ........................................................................................... 11-17

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

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

適用プロセスのプリコミット・ハンドラの削除 ................................................................................... 11-19適用プロセスによるイベントのエンキューの指定適用プロセスによるイベントのエンキューの指定適用プロセスによるイベントのエンキューの指定適用プロセスによるイベントのエンキューの指定 ....................................................................................... 11-19

ルールを満たすイベントの宛先キューの設定 ....................................................................................... 11-20

ルールの宛先キュー設定の削除 ............................................................................................................... 11-21適用プロセスの実行ディレクティブの指定適用プロセスの実行ディレクティブの指定適用プロセスの実行ディレクティブの指定適用プロセスの実行ディレクティブの指定 ................................................................................................... 11-21

ルールを満たすイベントの実行の回避の指定 ....................................................................................... 11-21

ルールを満たすイベントの実行の指定 ................................................................................................... 11-22エラー・ハンドラの管理エラー・ハンドラの管理エラー・ハンドラの管理エラー・ハンドラの管理 ................................................................................................................................... 11-23

エラー・ハンドラの作成 ........................................................................................................................... 11-23

エラー・ハンドラの設定 ........................................................................................................................... 11-27

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

適用エラーの管理適用エラーの管理適用エラーの管理適用エラーの管理 ............................................................................................................................................... 11-29

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

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

12 ルールおよびルールベースの変換の管理ルールおよびルールベースの変換の管理ルールおよびルールベースの変換の管理ルールおよびルールベースの変換の管理

ルール・セットとルールの管理ルール・セットとルールの管理ルール・セットとルールの管理ルール・セットとルールの管理 ......................................................................................................................... 12-2

ルール・セットの作成 ................................................................................................................................. 12-2

ルールの作成 ................................................................................................................................................. 12-3

ルール・セットへのルールの追加 ............................................................................................................. 12-6

viii

ルールの変更 ................................................................................................................................................. 12-6

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

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

ルールの削除 ............................................................................................................................................... 12-13

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

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

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

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

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

ルールベースの変換の管理ルールベースの変換の管理ルールベースの変換の管理ルールベースの変換の管理 ............................................................................................................................... 12-16

ルールベースの変換の作成 ....................................................................................................................... 12-17

ルールベースの変換の変更 ....................................................................................................................... 12-22

ルールベースの変換の削除 ....................................................................................................................... 12-24

13 その他のその他のその他のその他の Streams 管理タスク管理タスク管理タスク管理タスク

Streams 環境での全データベースのエクスポート環境での全データベースのエクスポート環境での全データベースのエクスポート環境での全データベースのエクスポート / インポートの実行インポートの実行インポートの実行インポートの実行 ...................................................... 13-2Streams 構成の削除構成の削除構成の削除構成の削除 ............................................................................................................................................. 13-7

14 Streams 環境の監視環境の監視環境の監視環境の監視

Streams の静的データ・ディクショナリ・ビューの概要の静的データ・ディクショナリ・ビューの概要の静的データ・ディクショナリ・ビューの概要の静的データ・ディクショナリ・ビューの概要 ............................................................................. 14-2Streams の動的パフォーマンス・ビューの概要の動的パフォーマンス・ビューの概要の動的パフォーマンス・ビューの概要の動的パフォーマンス・ビューの概要 ............................................................................................. 14-3

Streams 管理者およびその他の管理者およびその他の管理者およびその他の管理者およびその他の Streams ユーザーの監視ユーザーの監視ユーザーの監視ユーザーの監視 ............................................................................ 14-4

ローカル Streams 管理者のリスト表示 ..................................................................................................... 14-4

リモート Streams 管理者からのアクセスを許可するユーザーのリスト表示 .................................... 14-5

Streams の取得プロセスの監視の取得プロセスの監視の取得プロセスの監視の取得プロセスの監視 ......................................................................................................................... 14-5

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

各取得プロセスに関する一般情報の表示 ................................................................................................. 14-7

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

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

取得プロセスでは不要な REDO ログ・ファイルの表示 ..................................................................... 14-11

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

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

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

各取得プロセスで取得された追加の属性の表示 ................................................................................... 14-15

ix

データベースにおける全取得プロセスの適用済 SCN の判断 ............................................................ 14-15

各取得プロセスに関する REDO ログのスキャン待機時間の判断 ..................................................... 14-16

各取得プロセスに関するイベントのエンキュー待機時間の判断 ....................................................... 14-17

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

SYS.AnyData キューおよびメッセージの監視キューおよびメッセージの監視キューおよびメッセージの監視キューおよびメッセージの監視 ............................................................................................. 14-19

データベース内の SYS.AnyData キューの表示 ..................................................................................... 14-20

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

メッセージ通知の表示 ............................................................................................................................... 14-21

キュー内の各ユーザー・エンキュー・イベントのコンシューマの判断 ........................................... 14-22

キュー内のユーザー・エンキュー・イベントの内容の表示 ............................................................... 14-23

Streams 伝播および伝播ジョブの監視伝播および伝播ジョブの監視伝播および伝播ジョブの監視伝播および伝播ジョブの監視 ........................................................................................................... 14-24

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

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

伝播ジョブのスケジュールの表示 ........................................................................................................... 14-26

各伝播によって伝播されたイベントの合計数とバイト数の判断 ....................................................... 14-28Streams の適用プロセスの監視の適用プロセスの監視の適用プロセスの監視の適用プロセスの監視 ....................................................................................................................... 14-29

各適用プロセスのキュー、ルール・セットおよび状態の表示 ........................................................... 14-29

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

各適用プロセスのパラメータ設定のリスト表示 ................................................................................... 14-31

適用ハンドラに関する情報の表示 ........................................................................................................... 14-32

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

イベントが取得されてからデキューされるまでの待機時間の判断 ................................................... 14-35

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

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

各適用プロセスのイベントが取得されてから適用されるまでの待機時間の判断 ........................... 14-38

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

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

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

適用時に実行の回避を指定するルールの表示 ....................................................................................... 14-43

適用エラーのチェック ............................................................................................................................... 14-44

適用エラーの詳細情報の表示 ................................................................................................................... 14-45ルールおよびルールベースの変換の監視ルールおよびルールベースの変換の監視ルールおよびルールベースの変換の監視ルールおよびルールベースの変換の監視 ....................................................................................................... 14-51

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

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

ルールの現行の条件の表示 ....................................................................................................................... 14-57

x

Streams ルールの変更されたルール条件の表示 .................................................................................... 14-58

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

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

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

ルール・セットの全ルールの表示 ........................................................................................................... 14-61

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

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

ルールベースの変換の表示 ....................................................................................................................... 14-63

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

ルール・セット評価に関する一般情報の表示 ....................................................................................... 14-65

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

ルールの評価統計の表示 ........................................................................................................................... 14-67Streams 環境での互換性の監視環境での互換性の監視環境での互換性の監視環境での互換性の監視 ....................................................................................................................... 14-68

Streams と互換性のないデータベース・オブジェクトのリスト表示 ............................................... 14-68

近のリリースで Streams との互換性を持ったデータベース・オブジェクトのリスト表示 ...... 14-70Statspack を使用したを使用したを使用したを使用した Streams のパフォーマンスの監視のパフォーマンスの監視のパフォーマンスの監視のパフォーマンスの監視 ........................................................................... 14-71

15 Streams 環境のトラブルシューティング環境のトラブルシューティング環境のトラブルシューティング環境のトラブルシューティング

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

取得プロセスが有効化されているかどうか ............................................................................................. 15-2

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

必要な REDO ログ・ファイルが欠落していないかどうか ................................................................... 15-4

ダウンストリーム取得プロセスが REDO ログ・ファイルを待機しているかどうか ....................... 15-4

DBMS_STREAMS_ADM を使用してダウンストリーム取得を構成しているかどうか .................... 15-6

データベース・リンクなしのダウンストリーム取得に追加の操作が必要かどうか ......................... 15-6伝播に関する問題のトラブルシューティング伝播に関する問題のトラブルシューティング伝播に関する問題のトラブルシューティング伝播に関する問題のトラブルシューティング ................................................................................................. 15-7

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

伝播で使用される伝播ジョブが有効化されているか ............................................................................. 15-8

十分な数のジョブ・キュー・プロセスがあるか ................................................................................... 15-10

SYS.AnyData キューのセキュリティは適切に構成されているか ...................................................... 15-10適用に関する問題のトラブルシューティング適用に関する問題のトラブルシューティング適用に関する問題のトラブルシューティング適用に関する問題のトラブルシューティング ............................................................................................... 15-12

適用プロセスが有効化されているかどうか ........................................................................................... 15-12

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

適用プロセスで取得イベントとユーザー・エンキュー・イベントのどちらが適用されるか ....... 15-14

適用するイベントを適用プロセスのキューが受信しているか ........................................................... 15-15

xi

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

AQ_TM_PROCESSES 初期化パラメータが 0（ゼロ）に設定されていないかどうか .................... 15-16

エラー・キューに適用エラーがあるか ................................................................................................... 15-17ルールおよびルールベースの変換に関する問題のトラブルシューティングルールおよびルールベースの変換に関する問題のトラブルシューティングルールおよびルールベースの変換に関する問題のトラブルシューティングルールおよびルールベースの変換に関する問題のトラブルシューティング ........................................... 15-17

ルールは Streams クライアント用に適切に構成されているか ........................................................... 15-18

ルールベースの変換が適切に構成されているか ................................................................................... 15-25トレース・ファイルとアラート・ログでの問題のチェックトレース・ファイルとアラート・ログでの問題のチェックトレース・ファイルとアラート・ログでの問題のチェックトレース・ファイルとアラート・ログでの問題のチェック ....................................................................... 15-25

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

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

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

第第第第 III 部環境とアプリケーションの例部環境とアプリケーションの例部環境とアプリケーションの例部環境とアプリケーションの例

16 単一データベースの取得および適用の例単一データベースの取得および適用の例単一データベースの取得および適用の例単一データベースの取得および適用の例

単一データベースの取得および適用の例の概要単一データベースの取得および適用の例の概要単一データベースの取得および適用の例の概要単一データベースの取得および適用の例の概要 ............................................................................................. 16-2前提条件前提条件前提条件前提条件 ................................................................................................................................................................. 16-3

17 ルールベースのアプリケーションの例ルールベースのアプリケーションの例ルールベースのアプリケーションの例ルールベースのアプリケーションの例

ルールベースのアプリケーションの概要ルールベースのアプリケーションの概要ルールベースのアプリケーションの概要ルールベースのアプリケーションの概要 ......................................................................................................... 17-2

第第第第 IV 部付録部付録部付録部付録

A LCR 用の用の用の用の XML Schema

LCR 用の用の用の用の XML Schema 定義定義定義定義 ............................................................................................................................... A-2

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

Streams を使用したデータベースのメンテナンス・プロセスの概要を使用したデータベースのメンテナンス・プロセスの概要を使用したデータベースのメンテナンス・プロセスの概要を使用したデータベースのメンテナンス・プロセスの概要 ........................................................... B-2Streams を使用したデータベースのバージョン・アップグレードの実行を使用したデータベースのバージョン・アップグレードの実行を使用したデータベースのバージョン・アップグレードの実行を使用したデータベースのバージョン・アップグレードの実行 ................................................... B-3

Streams とオリジナルのエクスポート / インポートを使用したデータベースの

バージョン・アップグレードの実行 ................................................................................................... B-4

Streams と Recovery Manager を使用したデータベースのバージョン・アップグレードの実行 .... B-7Streams を使用したデータベースのメンテナンス操作の実行を使用したデータベースのメンテナンス操作の実行を使用したデータベースのメンテナンス操作の実行を使用したデータベースのメンテナンス操作の実行 .................................................................... B-13

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

xii

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

エクスポート / インポートおよび Streams を使用したメンテナンス操作の実行 ........................... B-15

Recovery Manager および Streams を使用したメンテナンス操作の実行 ......................................... B-19データベースのメンテナンス操作の完了データベースのメンテナンス操作の完了データベースのメンテナンス操作の完了データベースのメンテナンス操作の完了 ........................................................................................................ B-26

索引索引索引索引

xiii

xiv

はじめにはじめにはじめにはじめに

このマニュアルでは、Streams の特徴と機能を説明します。このマニュアルには、Streamsの概念と、Streams 環境の管理方法の説明が含まれます。さらに、Streams の取得環境と適用環境、およびルールベース・アプリケーションの詳細な構成例も含まれます。

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

� 対象読者

� このマニュアルの構成

� 関連ドキュメント

� 表記規則

xv

対象読者対象読者対象読者対象読者このマニュアルは、Streams 環境の作成とメンテナンスを担当するデータベース管理者を対象としています。これらの管理者は、次の 1 つ以上のタスクを実行します。

� Streams 環境のプラン作成

� Streams 環境の構成

� Streams 環境の管理

� Streams 環境の監視

� 必要なトラブルシューティング・アクティビティの実行

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

このマニュアルの構成このマニュアルの構成このマニュアルの構成このマニュアルの構成このマニュアルは次の部と章で構成されています。

第第第第 I 部「部「部「部「Streams の概要」の概要」の概要」の概要」

第 I 部の各章では、Streams に関連する概念について説明します。

第第第第 1 章「章「章「章「Streams の概要」の概要」の概要」の概要」

Streams の主な機能と使用方法について説明します。

第第第第 2 章「章「章「章「Streams の取得プロセス」の取得プロセス」の取得プロセス」の取得プロセス」

Streams の取得プロセスの概念について説明します。これには、論理変更レコード（LCR）、データ型、取得される変更のタイプ、サプリメンタル・ロギングおよび取得プロセス・アーキテクチャに関する情報が含まれます。

第第第第 3 章「章「章「章「Streams のステージングと伝播」のステージングと伝播」のステージングと伝播」のステージングと伝播」

Streams 環境でのステージングと伝播の概念について説明します。これには、取得イベントとユーザーがエンキューするイベントの違い、伝播、トランザクション型のキューと非トランザクション型のキューの違い、SYS.AnyDataキューの使用方法などが含まれます。また、キューと伝播のアーキテクチャについても説明します。

第第第第 4 章「章「章「章「Streams の適用プロセス」の適用プロセス」の適用プロセス」の適用プロセス」

Streams の適用プロセスの概念について説明します。これには、適用プロセスによるイベント処理、変更を表に適用する際の考慮事項、DDL 変更を適用する際の条件、トリガーの起動プロパティの制御、適用プロセスに関するも古い SCN および適用プロセスのアーキテクチャに関する情報が含まれます。

xvi

第第第第 5 章「ルール」章「ルール」章「ルール」章「ルール」

ルールの概念について説明します。これには、ルールのコンポーネント、ルール・セットおよびルール関連の権限に関する情報が含まれます。

第第第第 6 章「章「章「章「Streams でのルールの使用方法」でのルールの使用方法」でのルールの使用方法」でのルールの使用方法」

Streams でルールを使用する方法の概要について説明します。これには、表ルール、サブセット・ルール、スキーマ・ルールおよびグローバル・レベルのルールに関する情報が含まれます。また、ルールベースの変換についても説明します。

第第第第 7 章「章「章「章「Streams 高可用性環境」高可用性環境」高可用性環境」高可用性環境」

高可用性環境を実現するために Streams を使用する場合の概念を説明します。

第第第第 II 部「部「部「部「Streams の管理」の管理」の管理」の管理」第 II 部の各章では、取得プロセス、ステージング、伝播、適用プロセス、ルール、ルールベースの変換、論理変更レコード（LCR）および Streams タグの管理について説明します。

第第第第 8 章「章「章「章「Streams 環境の準備」環境の準備」環境の準備」環境の準備」

Streams 環境の準備について説明します。これには、Streams 管理者の構成、Streams に重要な初期化パラメータの設定、取得プロセスの準備およびネットワーク接続性の構成に関する手順が含まれます。

第第第第 9 章「取得プロセスの管理」章「取得プロセスの管理」章「取得プロセスの管理」章「取得プロセスの管理」

取得プロセスの管理について説明します。これには、取得プロセスの作成、起動、停止および変更の各手順と、取得プロセスの管理に関連するその他の情報が含まれます。

第第第第 10 章「ステージングと伝播の管理」章「ステージングと伝播の管理」章「ステージングと伝播の管理」章「ステージングと伝播の管理」

Streams 環境でのイベントのステージングと伝播の管理について説明します。これには、SYS.AnyDataキューの作成手順、伝播の有効化、無効化および変更のための手順と、ステージング、伝播およびメッセージングに関連するその他の情報が含まれます。

第第第第 11 章「適用プロセスの管理」章「適用プロセスの管理」章「適用プロセスの管理」章「適用プロセスの管理」

適用プロセスの管理について説明します。これには、適用プロセスの作成、起動、停止および変更の各手順と、適用プロセス・ハンドラの使用、競合解消の構成および例外キューの管理に関する各手順が含まれます。

第第第第 12 章「ルールおよびルールベースの変換の管理」章「ルールおよびルールベースの変換の管理」章「ルールおよびルールベースの変換の管理」章「ルールおよびルールベースの変換の管理」

ルールとルールベースの変換の管理について説明します。これには、ルールおよびルール・セットの管理手順と、ルールに関連する権限の付与と取消しに関する情報が含まれます。また、この章では、ルールベースの変換の作成、変更および削除の手順についても説明します。

xvii

第第第第 13 章「その他の章「その他の章「その他の章「その他の Streams 管理タスク」管理タスク」管理タスク」管理タスク」

論理変更レコード（LCR）と Streams タグの管理について説明します。これには、LCR の構成手順およびエンキュー手順と、セッションまたは適用プロセスのタグ値の設定手順および削除手順が含まれます。

第第第第 14 章「章「章「章「Streams 環境の監視」環境の監視」環境の監視」環境の監視」

データ・ディクショナリ・ビューとスクリプトを使用して Streams 環境を監視する方法について説明します。これには、取得プロセス、キュー、伝播、適用プロセス、ルール、ルールベースの変換およびタグを監視する方法が含まれます。

第第第第 15 章「章「章「章「Streams 環境のトラブルシューティング」環境のトラブルシューティング」環境のトラブルシューティング」環境のトラブルシューティング」

Streams 環境に考えられる問題とその解決方法について説明します。これには、取得プロセス、伝播、適用プロセス、メッセージ・クライアントおよびこれらの Streams クライアントで使用されるルールのトラブルシューティングと、トレース・ファイルとアラート・ログで問題をチェックする方法が含まれます。

第第第第 III 部「環境とアプリケーションの例」部「環境とアプリケーションの例」部「環境とアプリケーションの例」部「環境とアプリケーションの例」

第 III 部の各章では、環境の例をあげて説明します。

第第第第 16 章「単一データベースの取得および適用の例」章「単一データベースの取得および適用の例」章「単一データベースの取得および適用の例」章「単一データベースの取得および適用の例」

Streams を使用して単一データベースにおける取得と適用例を構成する手順の例を示します。具体的には、この章では、単一データベースで、表に対する変更を取得し、適用時に DMLハンドラを使用して取得済変更をキューに再エンキューし、さらに変更のサブセットを別の表に適用する例を示します。

第第第第 17 章「ルールベースのアプリケーションの例」章「ルールベースのアプリケーションの例」章「ルールベースのアプリケーションの例」章「ルールベースのアプリケーションの例」

Oracle ルール・エンジンを使用するルールベース・アプリケーションに関する手順の例を示します。

第第第第 IV 部「付録」部「付録」部「付録」部「付録」

論理変更レコード（LCR）用の XML Schema に関する付録が含まれています。

付録付録付録付録 A「「「「LCR 用の用の用の用の XML Schema」」」」LCR 用の XML Schema の定義について説明します。

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

Oracle データベースをわずかな停止時間でメンテナンスする操作について説明します。これらのメンテンナンス操作には、新しいバージョンの Oracle データベースへのアップグレード、異なるオペレーティング・システムまたはキャラクタ・セットへの Oracle データベー

xviii

スの移行、ユーザー作成アプリケーションのアップグレードおよび Oracle データベース・パッチの適用が含まれます。

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

� 『Oracle Streams レプリケーション管理者ガイド』

� 『Oracle Database 概要』

� 『Oracle Database 管理者ガイド』

� 『Oracle Database SQL リファレンス』

� 『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』

� 『PL/SQL ユーザーズ・ガイドおよびリファレンス』

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

� 『Oracle Database Heterogeneous Connectivity 管理者ガイド』

� 『Oracle Streams アドバンスト・キューイング・ユーザーズ・ガイドおよびリファレンス』

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

特定の内容の詳細情報は、Oracle のマニュアル・セットの他のマニュアルに記載されている場合があります。

Oracle エラー・メッセージのドキュメントは、HTML 版のみが存在します。Oracle ドキュメント CD を使用する場合は、エラー・メッセージを範囲ごとに参照できます。特定の範囲のページを表示したら、ブラウザの「このページの検索」機能を使用して特定のメッセージを検索できます。インターネットに接続できる場合、Oracle オンライン・ドキュメントのエラー・メッセージ検索機能を使用して特定のエラー・メッセージを検索できます。

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

リリース・ノート、インストール関連ドキュメント、ホワイト・ペーパーまたはその他の関連ドキュメントは、OTN-J（Oracle Technology Network Japan）から、無償でダウンロードできます。OTN-J を使用するには、オンラインでの登録が必要です。登録は、次の Web サイトから無償で行えます。

http://otn.oracle.co.jp/membership/

xix

すでに OTN-J のユーザー名およびパスワードを取得している場合は、次の URL で OTN-J Web サイトのドキュメントのセクションに直接接続できます。

http://otn.oracle.co.jp/document/

表記規則表記規則表記規則表記規則この項では、このマニュアルの本文およびコード例で使用される表記規則について説明します。この項の内容は次のとおりです。

� 本文の表記規則

� コード例の表記規則

本文の表記規則本文の表記規則本文の表記規則本文の表記規則

本文では、特定の項目が一目でわかるように、次の表記規則を使用します。次の表に、その規則と使用例を示します。

規則規則規則規則意味意味意味意味例例例例

太字太字太字太字太字は、本文中で定義されている用語および用語集に記載されている用語を示します。

この句を指定すると、索引構成表索引構成表索引構成表索引構成表が作成されます。

固定幅フォントの大文字

固定幅フォントの大文字は、システム指定の要素を示します。このような要素には、パラメータ、権限、データ型、Recovery Manager キーワード、SQL キーワード、

SQL*Plus またはユーティリティ・コマン

ド、パッケージおよびメソッドがあります。また、システム指定の列名、データベース・オブジェクト、データベース構造、ユーザー名およびロールも含まれます。

NUMBER列に対してのみ、この句を指定できます。

BACKUPコマンドを使用して、データベースの

バックアップを作成できます。

USER_TABLESデータ・ディクショナリ・ビュー

内の TABLE_NAME列を問い合せます。

DBMS_STATS.GENERATE_STATSプロシージャを

使用します。

xx

コード例の表記規則コード例の表記規則コード例の表記規則コード例の表記規則

コード例は、SQL、PL/SQL、SQL*Plus または他のコマンドライン文の例です。次のように固定幅フォントで表示され、通常のテキストと区別されます。

SELECT username FROM dba_users WHERE username = 'MIGRATE';

次の表に、コード例で使用される表記規則とその使用例を示します。

固定幅フォントの小文字

固定幅フォントの小文字は、実行可能ファイル、ファイル名、ディレクトリ名およびユーザーが指定する要素のサンプルを示します。このような要素には、コンピュータ名およびデータベース名、ネット・サービス名および接続識別子があります。また、ユーザーが指定するデータベース・オブジェクトとデータベース構造、列名、パッケージとクラス、ユーザー名とロール、プログラム・ユニットおよびパラメータ値も含まれます。

注意注意注意注意 : プログラム要素には、大文字と小文

字を組み合せて使用するものもあります。これらの要素は、記載されているとおりに入力してください。

sqlplusと入力して、SQL*Plus をオープンしま

す。

パスワードは、orapwdファイルで指定します。

/disk1/oracle/dbsディレクトリ内のデータ・

ファイルおよび制御ファイルのバックアップを作成します。

hr.departments表には、department_id、department_nameおよび location_id列があ

ります。

QUERY_REWRITE_ENABLED初期化パラメータを

trueに設定します。

oeユーザーとして接続します。

JRepUtilクラスが次のメソッドを実装します。

固定幅フォントの小文字のイタリック

固定幅フォントの小文字のイタリックは、プレースホルダまたは変数を示します。

parallel_clauseを指定できます。

Uold_release.SQLを実行します。ここで、

old_releaseとはアップグレード前にインス

トールしたリリースを示します。


[ ] 大カッコは、カッコ内の項目を任意に選択することを表します。大カッコは、入力しないでください。

DECIMAL (digits [ , precision ])

{ } 中カッコは、カッコ内の項目のうち、1 つが

必須であることを表します。中カッコは、入力しないでください。

{ENABLE | DISABLE}

| 縦線は、大カッコまたは中カッコ内の複数の選択項目の区切りに使用します。項目のうちの 1 つを入力します。縦線は、入力し

ないでください。

{ENABLE | DISABLE}[COMPRESS | NOCOMPRESS]


xxi

... 水平の省略記号は、次のいずれかを示します。

� 例に直接関連しないコードの一部が省略されている。

� コードの一部を繰り返すことができる。

CREATE TABLE ... AS subquery;

SELECT col1, col2, ... , coln FROM employees;

. . .

垂直の省略記号は、例に直接関連しない複数の行が省略されていることを示します。

SQL> SELECT NAME FROM V$DATAFILE;NAME------------------------------------/fsl/dbs/tbs_01.dbf/fs1/dbs/tbs_02.dbf.../fsl/dbs/tbs_09.dbf9 rows selected.

その他の記号大カッコ、中カッコ、縦線および省略記号以外の記号は、記載されているとおりに入力する必要があります。

acctbal NUMBER(11,2);acct CONSTANT NUMBER(4) := 3;

イタリック体イタリック体は、特定の値を指定する必要があるプレースホルダや変数を示します。

CONNECT SYSTEM/system_passwordDB_NAME = database_name

大文字大文字は、システム指定の要素を示します。これらの要素は、ユーザー定義の要素と区別するために大文字で示されます。大カッコ内にないかぎり、表示されているとおりの順序および綴りで入力します。ただし、大 / 小文字が区別されないため、小文字で

も入力できます。

SELECT last_name, employee_id FROM employees;SELECT * FROM USER_TABLES;DROP TABLE hr.employees;

小文字小文字は、ユーザー指定のプログラム要素を示します。たとえば、表名、列名またはファイル名などです。

注意注意注意注意 : プログラム要素には、大文字と小文

字を組み合せて使用するものもあります。これらの要素は、記載されているとおりに入力してください。

SELECT last_name, employee_id FROM employees;sqlplus hr/hrCREATE USER mjones IDENTIFIED BY ty3MU9;


xxii

Oracle Streams の新機能の新機能の新機能の新機能

ここでは、Oracle Database 10g リリース 1（10.1）の Oracle Streams の新機能を説明し、それらの詳細の参照先を示します。


� Streams のパフォーマンスの向上

� Streams の構成および管理の拡張機能

� Streams レプリケーションの拡張機能

� Streams メッセージの拡張機能

� ルール・インタフェースの拡張機能

xxiii

Streams のパフォーマンスの向上のパフォーマンスの向上のパフォーマンスの向上のパフォーマンスの向上Oracle Database 10g リリース 1（10.1）では、ほとんどの Streams 操作のパフォーマンスが向上しています。特に、次の Streams コンポーネントが改善され、より効率的な実行およびより多くのワークロードの処理が実現されています。

� 取得プロセス

� 伝播

� 適用プロセス

今回のリリースでは、SYS.AnyDataキューの操作およびルール・セットの評価のパフォーマンスも向上しています。

Streams の構成および管理の拡張機能の構成および管理の拡張機能の構成および管理の拡張機能の構成および管理の拡張機能この項では、Oracle Database 10g リリース 1（10.1）における Streams 構成の管理の拡張機能を説明します。

� ネガティブ・ルール・セット

� ダウンストリーム取得

� 取得および伝播のサブセット・ルール

� Streams プール

� バッファ・キューの情報へのアクセス

� SYSAUX 表領域の使用

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

� ルールベース変換のより簡単な構成および管理

� 適用時のエンキューの宛先

� 適用時の実行ディレクティブ

� 追加のデータ型のサポート

� 索引構成表のサポート

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

� Oracle Real Application Clusters（RAC）との相互運用性の向上

� ファンクション索引および降順索引のサポート

� Streams クライアントの削除時におけるルール・セットのより簡単な削除

� SYS.AnyData キューのより簡単な削除

xxiv

� REDO ログでのデータ・ディクショナリの作成に対する制御

� Streams データ・ディクショナリ・ビューおよびビュー列の追加

� 表領域のコピーおよび移動

� より簡単な Streams 管理者の構成

� Streams 構成の削除

ネガティブ・ルール・セットネガティブ・ルール・セットネガティブ・ルール・セットネガティブ・ルール・セット取得プロセス、伝播、適用プロセスおよびメッセージ・クライアントを含む Streams クライアントでは、2 つのルール・セット（ポジティブ・ルール・セットとネガティブ・ルール・セット）を使用できます。ネガティブ・ルール・セットを使用すると、Streams クライアントによって処理されないように、特定の変更を簡単に廃棄することができます。

ダウンストリーム取得ダウンストリーム取得ダウンストリーム取得ダウンストリーム取得

取得プロセスは、ソース・データベース以外のデータベースで実行できます。ソース・データベースの REDO ログ・ファイルはその他のデータベース（ダウンストリーム・データベースと呼ぶ）にコピーされ、取得プロセスが、そのダウンストリーム・データベースでこれらの REDO ログ・ファイル内の変更を取得します。

取得および伝播のサブセット・ルール取得および伝播のサブセット・ルール取得および伝播のサブセット・ルール取得および伝播のサブセット・ルール

取得プロセス、伝播、メッセージ・クライアントおよび適用プロセスのサブセット・ルールを使用できます。

Streams プールプールプールプール

単一データベースでは、Streams プールという SGA の新しいプールから Streams メモリーが割り当てられるように指定できます。Streams プールを構成するには、STREAMS_POOL_SIZE初期化パラメータを使用して、プールのサイズ（バイト単位）を指定します。 Streams プールは、バッファ・キューを含み、パラレル取得およびパラレル適用中の内部通信に使用されます。

参照参照参照参照 : 第 6 章「Streams でのルールの使用方法」

参照参照参照参照 :

� 2-16 ページの「ダウンストリーム取得」

� 9-2 ページの「取得プロセスの作成」

参照参照参照参照 : 6-21 ページの「サブセット・ルール」

xxv

バッファ・キューの情報へのアクセスバッファ・キューの情報へのアクセスバッファ・キューの情報へのアクセスバッファ・キューの情報へのアクセス

次の新しい動的パフォーマンス・ビューを使用すると、バッファ・キューを監視できます。

� V$BUFFERED_QUEUES

� V$BUFFERED_SUBSCRIBERS

� V$BUFFERED_PUBLISHERS

SYSAUX 表領域の使用表領域の使用表領域の使用表領域の使用

LogMiner のデフォルトの表領域は、SYSTEM表領域から SYSAUX表領域に変更されています。取得プロセスを実行するように新しいデータベースを構成する場合に、LogMiner 表をSYSTEM以外の表領域に再配置する必要がなくなりました。

システム作成ルールへのユーザー定義条件の追加機能システム作成ルールへのユーザー定義条件の追加機能システム作成ルールへのユーザー定義条件の追加機能システム作成ルールへのユーザー定義条件の追加機能DBMS_STREAMS_ADMパッケージのプロシージャには、and_conditionパラメータを使用してルールを作成するものがあります。このパラメータを使用すると、カスタム条件をシステム作成ルールに追加できます。

ルールベース変換のより簡単な構成および管理ルールベース変換のより簡単な構成および管理ルールベース変換のより簡単な構成および管理ルールベース変換のより簡単な構成および管理

DBMS_STREAMS_ADMパッケージの新しいプロシージャ SET_RULE_TRANSFORM_FUNCTIONを使用すると、ルールベースの変換を簡単に指定および管理できます。


� 3-15 ページの「バッファ・キュー」

� 8-5 ページの「Streams に関連する初期化パラメータの設定」



� バッファ・キューを監視する方法の詳細は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。

参照参照参照参照 : 6-39 ページの「システム作成ルールへのユーザー定義条件の追加」


� 6-56 ページの「ルールベースの変換」

� 12-16 ページの「ルールベースの変換の管理」

xxvi

適用時のエンキューの宛先適用時のエンキューの宛先適用時のエンキューの宛先適用時のエンキューの宛先DBMS_APPLY_ADMパッケージの新しいプロシージャ SET_ENQUEUE_DESTINATIONを使用すると、特定のルールを満たすイベントの宛先キューを簡単に指定できます。あるイベントがそのような適用プロセスのルールを満たす場合、その適用プロセスによって指定のキューにそのイベントがエンキューされます。

適用時の実行ディレクティブ適用時の実行ディレクティブ適用時の実行ディレクティブ適用時の実行ディレクティブ

DBMS_APPLY_ADMパッケージの新しいプロシージャ SET_EXECUTEを使用すると、適用プロセスによって特定のルールを満たすイベントが実行されないように指定できます。

追加のデータ型のサポート追加のデータ型のサポート追加のデータ型のサポート追加のデータ型のサポート

Streams の取得プロセスおよび適用プロセスは、次の追加のデータ型をサポートします。

� NCLOB

� BINARY_FLOAT

� BINARY_DOUBLE

� LONG

� LONG RAW

これらのデータ型を含む論理変更レコード（LCR）は、伝播を使用して伝播することもできます。

索引構成表のサポート索引構成表のサポート索引構成表のサポート索引構成表のサポート

Streams の取得プロセスおよび適用プロセスは、索引構成表への変更の処理をサポートします。

参照参照参照参照 : 11-19 ページの「適用プロセスによるイベントのエンキューの指定」

参照参照参照参照 : 11-21 ページの「適用プロセスの実行ディレクティブの指定」


� 2-7 ページの「取得されるデータ型」

� 4-10 ページの「適用されるデータ型」


� 2-9 ページの「取得される DML 変更のタイプ」


xxvii

プリコミット・ハンドラプリコミット・ハンドラプリコミット・ハンドラプリコミット・ハンドラプリコミット・ハンドラという新しいタイプの適用ハンドラを使用して、適用プロセスによって処理されたコミットの情報を記録できます。

Oracle Real Application Clusters（（（（RAC）との相互運用性の向上）との相互運用性の向上）との相互運用性の向上）との相互運用性の向上

Streams と RAC の相互運用性を向上する特定の拡張機能を次に示します。

� RAC 環境で実行されている Streams 取得プロセスは、オンライン REDO ログおよびアーカイブ REDO ログ内の変更を取得できます。

� 取得プロセスまたは適用プロセスで使用されるキューを含むキュー表の所有者インスタンスが使用不可能になると、キューの所有権は自動的にクラスタ内の別のインスタンスに移り、取得プロセスまたは適用プロセスは自動的に再起動されます（実行中であった場合）。

ファンクション索引および降順索引のサポートファンクション索引および降順索引のサポートファンクション索引および降順索引のサポートファンクション索引および降順索引のサポート

Streams の取得プロセスおよび適用プロセスは、ファンクション索引および降順索引を使用する表への変更の処理をサポートします。

Streams クライアントの削除時におけるルール・セットのより簡単な削除クライアントの削除時におけるルール・セットのより簡単な削除クライアントの削除時におけるルール・セットのより簡単な削除クライアントの削除時におけるルール・セットのより簡単な削除

新しいパラメータ drop_unused_rule_setsが、次のプロシージャに追加されています。

� DBMS_CAPTURE_ADMパッケージの DROP_CAPTURE

� DBMS_PROPAGATION_ADMパッケージの DROP_PROPAGATION

� DBMS_APPLY_ADMパッケージの DROP_APPLY

これらのいずれかのプロシージャを使用して Streams クライアントを削除し、drop_unused_rule_sets パラメータを trueに設定した場合、そのプロシージャは、削除した Streams クライアントによって使用されていたすべてのルール・セット（ネガティブおよびポジティブ）を削除します。ただし、これらのルール・セットが他のどの Streams クライ


� 4-8 ページの「プリコミット・ハンドラを使用したイベントのコミット情報の監査」

� 11-17 ページの「適用プロセスのプリコミット・ハンドラの管理」


� 2-24 ページの「Streams の取得プロセスと Oracle Real Application Clusters」

� 4-11 ページの「Streams の適用プロセスと Oracle Real Application Clusters」

xxviii

アントでも使用されていない場合です。Streams クライアントには、取得プロセス、伝播、適用プロセスおよびメッセージ・クライアントが含まれます。このプロシージャがルール・セットを削除する場合は、そのルール・セット内のルールで、他のルール・セットに含まれていないルールも削除します。

SYS.AnyData キューのより簡単な削除キューのより簡単な削除キューのより簡単な削除キューのより簡単な削除

DBMS_STREAMS_ADMパッケージの新しいプロシージャ REMOVE_QUEUEを使用すると、SYS.AnyDataキューを削除できます。このプロシージャには、cascadeパラメータも指定できます。cascadeを trueに設定すると、その SYS.AnyData キューを使用するすべてのStream クライアントも削除されます。

REDO ログでのデータ・ディクショナリの作成に対する制御ログでのデータ・ディクショナリの作成に対する制御ログでのデータ・ディクショナリの作成に対する制御ログでのデータ・ディクショナリの作成に対する制御

DBMS_CAPTURE_ADMパッケージの BUILDプロシージャを使用すると、現行のデータベースのデータ・ディクショナリを REDO ログに抽出できます。取得プロセスは、REDO ログ内に抽出された情報を使用して、取得プロセス用の LogMiner データ・ディクショナリを作成できます。このプロシージャは、取得プロセスで使用できる有効な先頭システム変更番号

（SCN）値も識別します。取得プロセスの先頭 SCN は、取得プロセスで変更を取得可能な、REDO ログ内の小の SNC です。また、取得プロセスの先頭 SCN をリセットして、LogMiner データ・ディクショナリ内の不要な情報を削除できます。


� 9-25 ページの「取得プロセスの削除」

� 10-18 ページの「伝播の削除」

� 11-9 ページの「適用プロセスの削除」

� Streams クライアントを削除するためのプロシージャの詳細は、『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。


� 10-6 ページの「SYS.AnyData キューの削除」

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



� 2-21 ページの「先頭 SCN および開始 SCN」

� 2-36 ページの「取得プロセスの作成時の先頭 SCN および開始 SCN の指定」

xxix

Streams データ・ディクショナリ・ビューおよびビュー列の追加データ・ディクショナリ・ビューおよびビュー列の追加データ・ディクショナリ・ビューおよびビュー列の追加データ・ディクショナリ・ビューおよびビュー列の追加今回のリリースには、新しい Streams データ・ディクショナリ・ビューが追加されています。また、以前のリリースの Streams データ・ディクショナリ・ビューに新しい列が追加されています。

表領域のコピーおよび移動表領域のコピーおよび移動表領域のコピーおよび移動表領域のコピーおよび移動

DBMS_STREAMS_TABLESPACE_ADMパッケージには、データベース間で表領域をコピーするための管理プロシージャ、およびあるデータベースから別のデータベースに表領域を移動するための管理プロシージャが含まれています。このパッケージでは、トランスポータブル表領域、Data Pump および DBMS_FILE_TRANSFERパッケージが使用されます。

より簡単なより簡単なより簡単なより簡単な Streams 管理者の構成管理者の構成管理者の構成管理者の構成

今回のリリースでは、Streams 管理者に DBA権限を付与するだけで、Streams 管理者はほとんどの操作を実行できます。また、新しいパッケージ DBMS_STREAMS_AUTHには、Streams管理者を簡単に構成および管理可能なプロシージャが含まれています。

Streams 構成の削除構成の削除構成の削除構成の削除

DBMS_STREAMS_ADMパッケージの新しいプロシージャREMOVE_STREAMS_CONFIGURATIONを使用すると、データベースで Streams 構成全体を削除できます。


� Streams データ・ディクショナリ・ビューの概要および問合せの例については、第 14 章「Streams 環境の監視」を参照してください。

� Streams レプリケーション環境で有効な問合せの例については、『Oracle Streams レプリケーション管理者ガイド』を参照してください。

参照参照参照参照 : 『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』

参照参照参照参照 : 8-2 ページの「Streams 管理者の構成」

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

xxx

Streams レプリケーションの拡張機能レプリケーションの拡張機能レプリケーションの拡張機能レプリケーションの拡張機能この項では、Oracle Database 10g リリース 1（10.1）における Streams レプリケーションの拡張機能を説明します。

� サプリメンタル・ロギングの追加オプション

� 他の方法を使用したインスタンス化の実行

� スキーマのインスタンス化およびグローバル・インスタンス化用の新しいデータ・ディクショナリ・ビュー

� スキーマおよびグローバルのインスタンス化 SCN の再帰的な設定

� LCR の処理中の Streams クライアント情報へのアクセス

� 表領域のメンテナンス

� 競合検出で古い値を比較するかどうかの指定

� LCR 内の追加の属性

� LCR 型用の新しいメンバー・プロシージャおよびメンバー・ファンクション

� 生成したスクリプトによる Advanced Replication から Streams への移行

サプリメンタル・ロギングの追加オプションサプリメンタル・ロギングの追加オプションサプリメンタル・ロギングの追加オプションサプリメンタル・ロギングの追加オプション

データベースのサプリメンタル・ロギングでは、データベース内のすべての外部キー列（FOREIGN KEY）のサプリメンタル・ロギングを実行するか、またはデータベース内のすべての列（ALL）のサプリメンタル・ロギングを実行するかを指定できます。これらの新しいオプションが、以前のリリースの PRIMARY KEYオプションおよび UNIQUEオプションに追加されています。

表のサプリメンタル・ロギングでは、ログ・グループに次のオプションを指定できます。

� PRIMARY KEY

� FOREIGN KEY

� UNIQUE

� ALL

これらの新しいオプションを使用すると、ログ・グループ内の各行をリストせずにサプリメンタル・ロギングを指定できるため、ソース・データベースでのサプリメンタル・ロギングの指定および管理が簡単になります。将来、表が変更された場合、正しい列が自動的にログに記録されます。たとえば、表のログ・グループに FOREIGN KEYを指定した場合、外部キー内の列が変更されても、行が更新されるたびに行の外部キーがログに記録されます。

参照参照参照参照 : Streams レプリケーション環境でのサプリメンタル・ロギングの詳細は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。

xxxi

他の方法を使用したインスタンス化の実行他の方法を使用したインスタンス化の実行他の方法を使用したインスタンス化の実行他の方法を使用したインスタンス化の実行オリジナルのエクスポート / インポートに加えて、Data Pump Export/Import、トランスポータブル表領域および Recovery Manager を使用して Streams のインスタンス化を実行できます。

スキーマのインスタンス化およびグローバル・インスタンス化用の新しいスキーマのインスタンス化およびグローバル・インスタンス化用の新しいスキーマのインスタンス化およびグローバル・インスタンス化用の新しいスキーマのインスタンス化およびグローバル・インスタンス化用の新しいデータ・ディクショナリ・ビューデータ・ディクショナリ・ビューデータ・ディクショナリ・ビューデータ・ディクショナリ・ビュー

次の新しいデータ・ディクショナリ・ビューを使用すると、スキーマ・レベルおよびグローバル・レベルで設定済のインスタンス化 SCN を持つデータベース・オブジェクトを判別できます。

� DBA_APPLY_INSTANTIATED_SCHEMAS

� DBA_APPLY_INSTANTIATED_GLOBAL

スキーマおよびグローバルのインスタンス化スキーマおよびグローバルのインスタンス化スキーマおよびグローバルのインスタンス化スキーマおよびグローバルのインスタンス化 SCN の再帰的な設定の再帰的な設定の再帰的な設定の再帰的な設定

SET_SCHEMA_INSTANTIATION_SCNおよび SET_GLOBAL_INSTANTIATION_SCNプロシージャの新しい recursiveパラメータを使用すると、スキーマまたはデータベースのインスタンス化 SCN、およびそれらに含まれるすべてのデータベース・オブジェクトのインスタンス化 SCN を設定できます。

LCR の処理中のの処理中のの処理中のの処理中の Streams クライアント情報へのアクセスクライアント情報へのアクセスクライアント情報へのアクセスクライアント情報へのアクセス

DBMS_STREAMSパッケージには、2 つの新しいファンクション（GET_STREAMS_NAMEおよび GET_STREAMS_TYPE）が含まれています。これらのファンクションはそれぞれ、LCR を処理している Streams クライアントの名前と型を戻します。これらのファンクションは、ルール条件、ルールベースの変換、適用ハンドラおよびエラー・ハンドラで使用できます。

たとえば、複数の適用プロセスに 1 つのエラー・ハンドラを使用する場合、GET_STREAMS_NAMEファンクションを使用して、エラーが発生した適用プロセスの名前を判別できます。また、DML ハンドラが適用プロセス・キュー（APPLY型）ではなく、エラー・キュー（ERROR_EXECUTION型）のイベントを処理している場合に、

参照参照参照参照 : インスタンス化の実行の詳細は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。


� インスタンス化の実行の詳細は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。

� SET_SCHEMA_INSTANTIATION_SCNおよびSET_GLOBAL_INSTANTIATION_SCNプロシージャの詳細は、

『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

xxxii

GET_STREAMS_TYPEファンクションを使用して、DML ハンドラに異なる操作を実行するように指示できます。

表領域のメンテナンス表領域のメンテナンス表領域のメンテナンス表領域のメンテナンス

MAINTAIN_SIMPLE_TABLESPACEプロシージャを使用すると、単純な表領域の Streams レプリケーションを構成できます。また、MAINTAIN_TABLESPACESプロシージャを使用すると、自己完結型の表領域セットの Streams レプリケーションを構成できます。これらのプロシージャは、いずれも DBMS_STREAMS_ADMパッケージに含まれています。これらのプロシージャは、トランスポータブル表領域、Data Pump、DBMS_STREAMS_TABLESPACE_ADMパッケージおよび DBMS_FILE_TRANSFERパッケージを使用して、環境を構成します。

競合検出で古い値を比較するかどうかの指定競合検出で古い値を比較するかどうかの指定競合検出で古い値を比較するかどうかの指定競合検出で古い値を比較するかどうかの指定DBMS_APPLY_ADMパッケージの COMPARE_OLD_VALUESプロシージャを使用すると、適用中に、行 LCR に含まれる 1 つ以上の列の古い値を、宛先データベースの対応する列の現行の値と比較するかどうかを指定できます。

LCR 内の追加の属性内の追加の属性内の追加の属性内の追加の属性

オプションで DBMS_CAPTURE_ADMパッケージの INCLUDE_EXTRA_ATTRIBUTEプロシージャを使用すると、取得プロセスに LCR の次の追加属性を含めるように指示できます。

� row_id

� serial#

� session#

� thread#

� tx_name


� GET_STREAMS_NAMEファンクションを使用するエラー・ハンドラの例は、11-23 ページの「エラー・ハンドラの管理」を参照してください。

� これらのファンクションの詳細は、『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。



� 『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』

参照参照参照参照 : 『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』

xxxiii

� username

Streams 環境での環境での環境での環境での Point-in-Time リカバリ用の新しいプロシージャリカバリ用の新しいプロシージャリカバリ用の新しいプロシージャリカバリ用の新しいプロシージャ

DBMS_STREAMS_ADMパッケージの GET_SCN_MAPPINGプロシージャを使用すると、複数のソースを含む Streams 環境でソース・データベースに Point-in-Time リカバリが実行された後に、トランザクションをリカバリする Streams の取得プロセスおよび適用プロセスに使用する SCN 値の情報を取得できます。

LCR 型用の新しいメンバー・プロシージャおよびメンバー・ファンクション型用の新しいメンバー・プロシージャおよびメンバー・ファンクション型用の新しいメンバー・プロシージャおよびメンバー・ファンクション型用の新しいメンバー・プロシージャおよびメンバー・ファンクション

次のとおり、LCR 型用の新しいメンバー・プロシージャおよびメンバー・ファンクションを使用できます。

� LCR のコミット SCN へのアクセス

GET_COMMIT_SCNメンバー・ファンクションは、現行の LCR が属するトランザクションのコミット SCN を戻します。

� LCR 内の追加属性の取得および設定

GET_EXTRA_ATTRIBUTEメンバー・ファンクションは、LCR 内の指定の追加属性の値を戻します。SET_EXTRA_ATTRIBUTEメンバー・プロシージャを使用すると、LCR 内の指定の追加属性の値を設定できます。

� LCR の互換性情報へのアクセス

GET_COMPATIBLEメンバー・ファンクションは、LCR をサポートするために必要なデータベースの小互換レベルを戻します。

� 行 LCR に含まれる LONGデータの LOB チャンクへの変換

CONVERT_LONG_TO_LOB_CHUNKメンバー・ファンクションは、行 LCR 内の LONGデータを CLOBに変換するか、または行 LCR 内の LONG RAWデータを BLOBに変換します。

参照参照参照参照 : 2-5 ページの「LCR 内の追加情報」

参照参照参照参照 : 『Oracle Streams レプリケーション管理者ガイド』

xxxiv

生成したスクリプトによる生成したスクリプトによる生成したスクリプトによる生成したスクリプトによる Advanced Replication からからからから Streams への移行への移行への移行への移行

DBMS_REPCAT.STREAMS_MIGRATIONプロシージャを使用して、既存の Advanced Replication 環境を Streams 環境に移行する SQL*Plus スクリプトを生成できます。

Streams メッセージの拡張機能メッセージの拡張機能メッセージの拡張機能メッセージの拡張機能この項では、Oracle Database 10g リリース 1（10.1）における Streams メッセージの拡張機能を説明します。

� Streams メッセージ・クライアント

� メッセージのより簡単なエンキューおよびデキュー

� メッセージのルールベースのデキューまたは適用のより簡単な構成

� メッセージのルールベースの伝播のより簡単な構成

� メッセージ通知のより簡単な構成

Streams メッセージ・クライアントメッセージ・クライアントメッセージ・クライアントメッセージ・クライアント

メッセージ・クライアントは新しいタイプの Streams クライアントであり、これを使用すると、ユーザーおよびアプリケーションはルールに基づいて SYS.AnyDataキューからメッセージをデキューできます。メッセージ・クライアントを作成するには、DBMS_STREAMS_ADMパッケージの特定のプロシージャの streams_typeパラメータにdequeueを指定します。


� LCR 型および新しいメンバー・プロシージャとメンバー・ファンクションの詳細は、『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

� GET_COMMIT_SCNメンバー・ファンクションを使用する DML ハンドラの例は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。

� GET_COMPATIBLEメンバー・ファンクションを使用するルール条件の例は、6-50 ページの「サポートされていない LCR を廃棄するように Streams クライアントに指示するルール条件」を参照してください。

参照参照参照参照 : Advanced Replication から Streams への移行の詳細は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。

参照参照参照参照 : Streams メッセージの拡張機能の詳細は、『Oracle Streams アドバンスト・キューイング・ユーザーズ・ガイドおよびリファレンス』を参照してください。

xxxv

メッセージのより簡単なエンキューおよびデキューメッセージのより簡単なエンキューおよびデキューメッセージのより簡単なエンキューおよびデキューメッセージのより簡単なエンキューおよびデキュー

新しいパッケージ DBMS_STREAMS_MESSAGINGには、SYS.AnyDataキューにメッセージをエンキューしたり、SYS.AnyData キューからメッセージをデキューするための簡単なインタフェースが含まれています。

メッセージのルールベースのデキューまたは適用のより簡単な構成メッセージのルールベースのデキューまたは適用のより簡単な構成メッセージのルールベースのデキューまたは適用のより簡単な構成メッセージのルールベースのデキューまたは適用のより簡単な構成

DBMS_STREAMS_ADMパッケージの新しいプロシージャ ADD_MESSAGE_RULEを使用すると、メッセージ・クライアントおよび適用プロセスを構成できます。また、これらのメッセージ・クライアントおよび適用プロセスの動作を制御するユーザー・エンキュー・メッセージのルールを作成できます。

メッセージのルールベースの伝播のより簡単な構成メッセージのルールベースの伝播のより簡単な構成メッセージのルールベースの伝播のより簡単な構成メッセージのルールベースの伝播のより簡単な構成

DBMS_STREAMS_ADMパッケージの新しいプロシージャADD_MESSAGE_PROPAGATION_RULEを使用すると、伝播を構成し、ユーザー・エンキュー・メッセージを伝播する伝播のルールを作成できます。


� 第 3 章「Streams のステージングと伝播」

� 6-32 ページの「メッセージ・ルールの例」

� 10-23 ページの「メッセージ・クライアントおよびメッセージ通知の構成」

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



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


� 6-31 ページの「メッセージ・ルール」

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

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

xxxvi

メッセージ通知のより簡単な構成メッセージ通知のより簡単な構成メッセージ通知のより簡単な構成メッセージ通知のより簡単な構成DBMS_STREAMS_ADMパッケージの新しいプロシージャ SET_MESSAGE_NOTIFICATIONを使用すると、Streams メッセージ・クライアントがメッセージをデキューした際に送信されるメッセージ通知を構成できます。通知は、電子メール・アドレス、URL または PL/SQLプロシージャに送信できます。

ルール・インタフェースの拡張機能ルール・インタフェースの拡張機能ルール・インタフェースの拡張機能ルール・インタフェースの拡張機能この項では、Oracle Database 10g リリース 1（10.1）におけるルール・インタフェースの拡張機能を説明します。

� 繰返しの評価結果

� ルール・セットおよびルール評価用の新しい動的パフォーマンス・ビュー

繰返しの評価結果繰返しの評価結果繰返しの評価結果繰返しの評価結果

ルール・セットの評価中、クライアントは、評価結果が一度に完全なリストで送信されるのではなく、繰り返し送信されるように指定できます。DBMS_RULEパッケージの EVALUATEプロシージャには、2 つのパラメータ（true_rules_interatorおよびmaybe_rules_iterator）が含まれています。これらのパラメータを使用すると、評価結果が繰り返し送信されるように指定できます。

また、DBMS_RULEパッケージの新しいプロシージャ GET_NEXT_HITは、true ルール・イテレータから TRUEに評価された次のルールを戻すか、または maybe ルール・イテレータから MAYBEに評価された次のルールを戻します。さらに、DBMS_RULEパッケージの新しいプロシージャ CLOSE_ITERATORを使用すると、オープン・イテレータをクローズできます。



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


� 5-11 ページの「ルール・セットの評価」

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

xxxvii

ルール・セットおよびルール評価用の新しい動的パフォーマンス・ビュールール・セットおよびルール評価用の新しい動的パフォーマンス・ビュールール・セットおよびルール評価用の新しい動的パフォーマンス・ビュールール・セットおよびルール評価用の新しい動的パフォーマンス・ビュー次の新しい動的パフォーマンス・ビューを使用すると、ルール・セットおよびルール評価を監視できます。

� V$RULE_SET_AGGREGATE_STATS

� V$RULE_SET

� V$RULE

参照参照参照参照 : 14-51 ページの「ルールおよびルールベースの変換の監視」

xxxviii

第第第第I部部部部
Streams の概要の概要の概要の概要
第 I 部では、Streams の概要について説明します。第 I 部の構成は、次のとおりです。

� 第 1 章「Streams の概要」

� 第 2 章「Streams の取得プロセス」


� 第 4 章「Streams の適用プロセス」

� 第 5 章「ルール」

� 第 6 章「Streams でのルールの使用方法」

� 第 7 章「Streams 高可用性環境」

Streams の

1
Streams の概要の概要の概要の概要
この章では、Oracle Streams に関連する基本的な概念と用語について説明します。これらの概念の詳細は、他の章および『Oracle Streams レプリケーション管理者ガイド』を参照してください。

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

� Streams の概要

� 取得プロセスの概要

� イベントのステージングと伝播の概要

� 適用プロセスの概要

� メッセージ・クライアントの概要

� 自動競合検出および解消の概要

� ルールの概要

� 変換の概要

� Streams タグの概要

� 異機種間での情報共有の概要

� Streams 構成の例

� Streams 環境用の管理ツール

概要 1-1

Streams の概要

Streams の概要の概要の概要の概要Oracle Streams は、情報の共有を可能にします。Oracle Streams を使用すると、ストリーム内のデータとイベントを共有できます。ストリームによって、データベース内またはデータベース間でこの情報を伝播できます。また、指定の情報が指定の宛先にルーティングされます。その結果、イベントの取得と管理、および他のデータベースやアプリケーションとのイベントの共有に関して、従来のソリューションよりも機能性と柔軟性に優れた機能が得られます。Oracle Streams には、分散エンタープライズ・アプリケーション、データ・ウェアハウスおよび高可用性ソリューションの構築と運用に必要な機能が用意されています。Oracle Streams の機能は、すべて同時に使用できます。変更が必要な場合は、既存の機能を損なわずに Streams の新機能を実装できます。

Oracle Streams を使用して、ストリームに入れる情報、ストリームのフローまたはデータベース間でのルーティング、各データベースに送られるストリーム内のイベントに発生する処理およびストリームの終了方法を制御します。Streams の特定の機能を構成することで、特定の要件に対処できます。Streams では、仕様に基づいて、データ操作言語（DML）の変更やデータ定義言語（DDL）の変更など、データベース内のイベントを自動的に取得、ステージングおよび管理できます。また、ユーザー定義イベントをストリームに入れることも可能です。Streams では、その情報を他のデータベースやアプリケーションに自動的に伝播できます。イベントが接続先に到達すると、Streams では仕様に基づいてイベントをコンシュームできます。図 1-1 に、Streams の情報の流れを示します。

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

Streams の機能の機能の機能の機能ここでは、Streams の機能の概要について説明します。

データベースでのイベントの取得データベースでのイベントの取得データベースでのイベントの取得データベースでのイベントの取得取得プロセス取得プロセス取得プロセス取得プロセスでは、表、スキーマまたはデータベース全体に対して行われた変更を取得できます。これらの変更はデータベースの REDO ログに記録されます。取得プロセスは REDOログから変更を取得し、取得した変更をそれぞれ論理変更レコード（LCR）と呼ばれる形式のイベントにフォーマットします。取得プロセスが取得する変更はルールによって決定され、このように取得された変更は取得イベント取得イベント取得イベント取得イベントと呼ばれます。

REDO ログ内で変更が生成されるデータベースを、ソース・データベースソース・データベースソース・データベースソース・データベースと呼びます。取得プロセスは、ソース・データベースで変更をローカルに取得するか、またはダウンストリーム・データベースで変更をリモートに取得できます。取得プロセスは関連付けられたキュー

1-2 Oracle Streams 概要および管理

Streams の概要

に LCR をエンキューします。取得プロセスがイベントを取得することを、暗黙的取得暗黙的取得暗黙的取得暗黙的取得ともいいます。

ユーザーおよびアプリケーションは、イベントを手動でキューにエンキューすることもできます。これらのイベントはユーザー・エンキュー・イベントユーザー・エンキュー・イベントユーザー・エンキュー・イベントユーザー・エンキュー・イベントと呼ばれ、LCR またはユーユーユーユーザー・メッセージザー・メッセージザー・メッセージザー・メッセージと呼ばれるユーザー定義型のメッセージになります。ユーザーおよびアプリケーションがイベントを手動でキューにエンキューすることを、明示的取得明示的取得明示的取得明示的取得ともいいます。

キューへのイベントのステージングキューへのイベントのステージングキューへのイベントのステージングキューへのイベントのステージングイベントはキューに格納（またはステージングステージングステージングステージング）されます。これらのイベントは、取得イベントまたはユーザー・エンキュー・イベントであってもかまいません。取得プロセスは、SYS.AnyData キューキューキューキューにイベントをエンキューします。SYS.AnyDataキューは様々なタイプのイベントをステージングできます。ユーザーおよびアプリケーションは、SYS.AnyDataキューまたは型付きのキュー型付きのキュー型付きのキュー型付きのキューにイベントをエンキューできます。型付きキューは、特定のタイプのイベントのみをステージングできます。

キュー間でのイベントの伝播キュー間でのイベントの伝播キュー間でのイベントの伝播キュー間でのイベントの伝播Streams の伝播伝播伝播伝播によって、あるキューから別のキューにイベントを伝播させることができます。これらのキューは、同じデータベースにあっても異なるデータベースにあってもかまいません。ルールによって、伝播で伝播するイベントが決定されます。

イベントのコンシュームイベントのコンシュームイベントのコンシュームイベントのコンシュームイベントは、キューからデキューされるとコンシュームコンシュームコンシュームコンシュームされます。適用プロセス適用プロセス適用プロセス適用プロセスは、イベントをキューから暗黙的にデキューできます。ユーザー、アプリケーションまたはメッセーメッセーメッセーメッセージ・クライアントジ・クライアントジ・クライアントジ・クライアントは、イベントを明示的にデキューできます。イベントがコンシュームされるデータベースを、接続先データベース接続先データベース接続先データベース接続先データベースと呼びます。構成によっては、ソース・データベースと接続先データベースが同一の場合があります。

ルールによって、適用プロセスでデキューおよび処理するイベントが決定されます。適用プロセスはイベントをデータベース・オブジェクトに直接適用したり、処理のためにイベントをカスタム PL/SQL サブプログラムに渡すことができます。

ルールによって、メッセージ・クライアントでデキューするイベントが決定されます。メッセージ・クライアントは、アプリケーションまたはユーザーによって起動された際にイベントをデキューします。

Streams の概要 1-3

Streams の概要

Streams のその他の機能のその他の機能のその他の機能のその他の機能その他、Streams には次の機能があります。

� 有向ネットワーク

� 自動競合検出および解消

� 変換

� 異機種間での情報の共有

この章では、これらの機能の概要について説明します。詳細は、他の章および『Oracle Streams レプリケーション管理者ガイド』を参照してください。

Streams を使用する理由を使用する理由を使用する理由を使用する理由ここでは、Streams を使用する理由について説明します。Streams コンポーネントは、Oracle の様々な機能のインフラストラクチャを提供することがあります。

メッセージ・キューイングメッセージ・キューイングメッセージ・キューイングメッセージ・キューイングOracle Streams Advanced Queuing（AQ）を使用すると、ユーザー・アプリケーションはメッセージをキューにエンキューし、メッセージをサブスクライバ・キューに伝播し、メッセージをコンシューム（使用）する準備ができたことをユーザー・アプリケーションに通知し、接続先でメッセージをデキューできます。キューは、特定の型のメッセージのみをステージングするように構成するか、または SYS.AnyDataキューとして構成できます。ほぼすべての型のメッセージは、SYS.AnyDataラッパーにラップして、SYS.AnyDataキューにステージングできます。AQ では、マルチ・コンシューマ・キュー、パブリッシュおよびサブスクライブ、コンテンツ・ベースのルーティング、インターネット伝播、変換、他のメッセージ・サブシステムへのゲートウェイなど、メッセージ・キューイング・システムのすべての標準機能がサポートされます。

データベースでキューを作成できます。また、アプリケーションはメッセージをキューに明示的にエンキューできます。サブスクライバ・アプリケーションまたはメッセージ・クライアントは、このキューからメッセージを直接デキューできます。アプリケーションがリモートの場合、ソース・キューでパブリッシュされたメッセージをサブスクライブするリモート・データベースにキューを作成できます。接続先アプリケーションは、リモート・キューからメッセージをデキューできます。また、接続先アプリケーションでは、様々な標準プロトコルを使用して、ソース・キューからメッセージを直接デキューできます。

参照参照参照参照 : AQ の詳細は、『Oracle Streams アドバンスト・キューイング・ユーザーズ・ガイドおよびリファレンス』を参照してください。


Streams の概要

データ・レプリケーションデータ・レプリケーションデータ・レプリケーションデータ・レプリケーションStreams では、データベース・オブジェクトに対する DML と DDL の変更を取得し、他の 1つ以上のデータベースにレプリケートできます。Streams の取得プロセスは、ソース・データベース・オブジェクトに対する変更を取得し、それを接続先データベースに伝播してStreams の適用プロセスで適用できる LCR 形式でフォーマットします。

接続先データベースでは、同じデータベース・オブジェクトに対する DML および DDL 変更を許可できます。これらの変更は、環境内の他のデータベースに伝播される場合と、伝播されない場合があります。つまり、Streams 環境は、変更を伝播する 1 つのデータベースを使用して構成する方法と、データベース間で変更が両方向に伝播するように構成する方法があります。また、データが共有される表をすべてのデータベースで同一コピーにする必要はありません。これらの表の構造と内容はデータベースごとに異なっていてもよく、各表の情報をこれらのデータベース間で共有できます。

イベントの管理および通知イベントの管理および通知イベントの管理および通知イベントの管理および通知ビジネス・イベントは、アプリケーションまたは組織間の重要な通信です。アプリケーションがイベントをキューに明示的にエンキューするか、または Streams 取得プロセスがデータベース・イベントを取得できます。取得可能なイベントは、DML 変更または DDL 変更です。伝播は、複数のキューを介してストリーム内のイベントを伝播できます。後に、ユーザー・アプリケーションがイベントを明示的にエンキューするか、または Streams 適用プロセスがイベントを暗黙的にデキューできます。適用プロセスは、必要に応じて、これらのイベントを同じキューまたは別のキューに明示的に再エンキューできます。

指定した期間コンシュームされた後に、キューが明示的にエンキューされたメッセージを保持するように構成できます。これによって、Advanced Queuing（AQ）をビジネス・イベント管理システムとして使用できます。AQ は、データベース内のすべてのメッセージをトランザクションとして格納します。これらのメッセージは、自動的に監査および追跡できます。この監査証跡を使用して、ビジネス操作に関するインテリジェンスを抽出できます。

取得プロセス、伝播、適用プロセスおよびメッセージ・クライアントは、ルールに基づいてアクションを実行します。ルールを使用して取得、伝播、適用およびデキューするイベントを指定できます。組込みルール・エンジンは、これらのルールに基づいてイベントを評価します。イベントを取得し、ルールに基づいてそのイベントを関連のコンシューマに伝播できることは、イベント通知に Streams を使用できることを意味します。キュー内でステージングされたイベントは、メッセージ・クライアントまたはアプリケーションで明示的にデキューできます。その後、これらのイベントに基づいて、電子メールで通知したり、携帯電話やポケットベルへの送信用ワイヤレス・ゲートウェイにメッセージを渡すなどのアクションを実行できます。

参照参照参照参照 : レプリケーションに Streams を使用する方法の詳細は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。


Streams の概要

データ・ウェアハウスのロードデータ・ウェアハウスのロードデータ・ウェアハウスのロードデータ・ウェアハウスのロードデータ・ウェアハウスのロードは、データ・レプリケーションの特殊なケースです。データ・ウェアハウスの作成と管理のうちも重要なタスクには、既存データのリフレッシュと業務系データベースからの新規データの追加があります。Streams コンポーネントでは、本番システムに対して行われた変更を取得し、それをステージング・データベースに送信するか、またはデータ・ウェアハウスやオペレーショナル・データ・ストアに直接送信できます。Streams は REDO ログの情報を取得することで、本番システムに発生する不要なオーバーヘッドを回避します。データ変換とユーザー定義の適用手順がサポートされることで、データがロードされるときのデータの再フォーマットやウェアハウス固有のデータ・フィールドの更新に必要な柔軟性が得られます。また、チェンジ・データ・キャプチャは Streamsのいくつかのコンポーネントを使用して、データ・ウェアハウスにロードできるように、変更されたデータを識別します。

データ保護データ保護データ保護データ保護データ保護に関する解決策の 1 つは、本番データベースのローカル・コピーまたはリモート・コピーを作成することです。人為的なエラーや災害が発生した場合は、コピーを使用して処理を再開できます。Streams を使用すると、柔軟な高可用性環境を構成できます。また、Streams と同じインフラストラクチャの一部を使用するデータ保護機能である Oracle Data Guard を使用して、本番データベースと論理的に等価のスタンバイ・コピーであるロジカル・スタンバイ・データベースを作成し、メンテナンスできます。Streams のレプリケーションの場合と同様に、取得プロセスは REDO ログ内の変更を取得し、これらの変更をLCR 形式でフォーマットします。これらの LCR は、スタンバイ・データベースで適用されます。

スタンバイ・データベースは読取り / 書込み用に完全にオープンされており、特殊な索引や他のデータベース・オブジェクトを含んでいる場合があります。したがって、これらのスタンバイ・データベースを更新の適用中に問い合せることができます。これによって、Oracle Data Guard は本番データベースを問合せによる負荷から解放する優れたソリューションとなります。

ロジカル・スタンバイ・データベースでの更新は、できるだけ早期にリモート・サイトに移動することが重要です。これによって、障害発生時にも、トランザクション消失が小限で


� イベントの明示的エンキューおよびデキューの詳細は、第 3 章「Streams のステージングと伝播」、第 10 章「ステージングと伝播の管理」および『Oracle Streams アドバンスト・キューイング・ユーザーズ・ガイドおよびリファレンス』を参照してください。

� イベントを明示的にデキューする環境の例は、第 16 章「単一データベースの取得および適用の例」を参照してください。

参照参照参照参照 : データ・ウェアハウスの詳細は、『Oracle データ・ウェアハウス・ガイド』を参照してください。


取得プロセスの概要

済みます。リモート・データベースで REDO ログを同期式で直接書き込むことで、障害発生時にもデータ消失が発生しません。スタンバイ・システム側では、変更が取得され、適用プロセスによってスタンバイ・データベースに直接適用されます。

取得プロセスの概要取得プロセスの概要取得プロセスの概要取得プロセスの概要Oracle データベース内でデータベース・オブジェクトに対して行われた変更は、ユーザー・エラーやメディア障害が発生した場合にもリカバリを保証するために、REDO ログに記録されます。取得プロセスは Oracle バックグラウンド・プロセスであり、データベースのREDO ログをスキャンして、データベース・オブジェクトに対する DML と DDL の変更を取得します。取得プロセスは、これらの変更を LCR と呼ばれるイベント形式でフォーマットし、キューにエンキューします。LCR には 2 種類あり、行行行行 LCR には、DML 操作によって発生する表内の行に対する変更の情報が含まれ、DDL LCR には、データベース・オブジェクトに対する DDL 変更の情報が含まれます。ルールによって、取得する変更が決定されます。図 1-2 に、LCR を取得する取得プロセスを示します。


� 第 7 章「Streams 高可用性環境」

� ロジカル・スタンバイ・データベースの詳細は、『Oracle Data Guard概要および管理』を参照してください。


取得プロセスの概要

図図図図 1-2 取得プロセス取得プロセス取得プロセス取得プロセス

変更をソース・データベースでローカルに取得するか、またはダウンストリーム・データダウンストリーム・データダウンストリーム・データダウンストリーム・データベースベースベースベースでリモートに取得するように構成できます。取得プロセスがダウンストリーム・データベースで実行される場合、ソース・データベースの REDO ログ・ファイルはダウンストリーム・データベースにコピーされ、取得プロセスがこれらの REDO ログ・ファイル内の変更を取得します。

注意注意注意注意 : 取得プロセスは、一部の DML 変更や DDL 変更は取得せず、SYS、SYSTEMまたは SYSTEMスキーマ内で行われた変更も取得しません。

参照参照参照参照 : 取得プロセスと、取得プロセスによって取得される DML 文および DDL 文の詳細は、第 2 章「Streams の取得プロセス」を参照してください。


イベントのステージングと伝播の概要

イベントのステージングと伝播の概要イベントのステージングと伝播の概要イベントのステージングと伝播の概要イベントのステージングと伝播の概要Streams では、キューを使用してイベントが伝播またはコンシュームのためにステージングされます。伝播によって、キューが同一データベース内にあるか、異なるデータベース内にあるかに関係なく、あるキューから別のキューにイベントが送信されます。イベントの伝播元となるキューはソース・キューソース・キューソース・キューソース・キュー、イベントを受信するキューは宛先キュー宛先キュー宛先キュー宛先キューと呼ばれます。ソース・キューと宛先キューの間には、1 対多、多対 1 または多対多の関連が可能です。

キュー内でステージングされるイベントは、適用プロセス、メッセージ・クライアントまたはアプリケーションでコンシュームできます。ルールによって、伝播で伝播するイベントが決定されます。図 1-3 に、ソース・キューから宛先キューへの伝播について示します。

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

有向ネットワークの概要有向ネットワークの概要有向ネットワークの概要有向ネットワークの概要Streams では、有向ネットワーク有向ネットワーク有向ネットワーク有向ネットワークを介して変更が共有される環境を構成できます。有向ネットワークでは、伝播されるイベントは、それらがコンシュームされる接続先データベースに到達する前に 1 つ以上の中間データベースを通過します。イベントは、接続先データベースに加えて、中間データベースでコンシュームされる場合もコンシュームされない場合もあります。Streams を使用すると、各接続先データベースに伝播させるイベントを選択し、イベントが接続先データベースに到達するまでのルートを指定できます。



図 1-4 に、有向ネットワーク環境の例を示します。この例では、シカゴにある中間データベースのキューが、ソース・キューと宛先キューの両方を兼ねていることに注意してください。

図図図図 1-4 有向ネットワーク環境の例有向ネットワーク環境の例有向ネットワーク環境の例有向ネットワーク環境の例

参照参照参照参照 : ステージングと伝播の詳細は、第 3 章「Streams のステージングと伝播」を参照してください。



イベントの明示的エンキューおよびデキューイベントの明示的エンキューおよびデキューイベントの明示的エンキューおよびデキューイベントの明示的エンキューおよびデキューユーザー・アプリケーションでは、イベントを明示的にエンキューできます。ユーザー・アプリケーションは、これらのユーザー・エンキュー・イベントを LCR またはユーザー・メッセージとしてフォーマットできます。また、適用プロセス、メッセージ・クライアントまたはユーザー・アプリケーションは、これらのイベントをコンシュームできます。明示的にキューにエンキューされたイベントは、他のキューに伝播したり、同じキューから明示的にデキューできます。図 1-5 に、同じキューでのイベントの明示的なエンキューとデキューを示します。

図図図図 1-5 単一キューでのイベントの明示的なエンキューおよびデキュー単一キューでのイベントの明示的なエンキューおよびデキュー単一キューでのイベントの明示的なエンキューおよびデキュー単一キューでのイベントの明示的なエンキューおよびデキュー


適用プロセスの概要

イベントがキュー間で伝播する場合、ソース・キューに明示的にエンキューされたイベントは、メッセージ・クライアントまたはユーザー・アプリケーションが宛先キューから明示的にデキューできます。また、これらのイベントは適用プロセスでも処理できます。図 1-6 に、ソース・キューへのイベントの明示的なエンキュー、宛先キューへの伝播および宛先キューからのイベントの明示的なデキューを示します。

図図図図 1-6 イベントの明示的エンキュー、伝播およびデキューイベントの明示的エンキュー、伝播およびデキューイベントの明示的エンキュー、伝播およびデキューイベントの明示的エンキュー、伝播およびデキュー

適用プロセスの概要適用プロセスの概要適用プロセスの概要適用プロセスの概要適用プロセスは Oracle バックグラウンド・プロセスであり、キューからイベントをデキューし、各イベントをデータベース・オブジェクトに直接適用するか、適用ハンドラと呼ばれるユーザー定義プロシージャにパラメータとして渡します。適用ハンドラには、メッセージ・ハンドラ、DML ハンドラ、DDL ハンドラ、プリコミット・ハンドラおよびエラー・ハンドラがあります。

通常、適用プロセスは、イベントを稼働中のローカル・データベースに適用しますが、異機種間データベース環境では、Oracle 以外のリモート・データベースにイベントを適用するよ

参照参照参照参照 : イベントの明示的エンキューおよびデキューの詳細は、3-11 ページの「SYS.AnyData 型のキューとユーザー・メッセージ」を参照してください。


メッセージ・クライアントの概要

うに構成できます。ルールによって、適用プロセスでデキューするイベントが決定されます。図 1-7 に、LCR とユーザー・メッセージを処理する適用プロセスを示します。

図図図図 1-7 適用プロセス適用プロセス適用プロセス適用プロセス

メッセージ・クライアントの概要メッセージ・クライアントの概要メッセージ・クライアントの概要メッセージ・クライアントの概要メッセージ・クライアントは、アプリケーションまたはユーザーによって起動された際にユーザー・エンキュー・イベントをコンシュームします。ルールによって、メッセージ・クライアントでデキューするユーザー・エンキュー・イベントが決定されます。デキューするユーザー・エンキュー・イベントには、LCR またはユーザー・メッセージを指定できます。図 1-8 に、メッセージ・クライアントによるユーザー・エンキュー・イベントのデキューを示します。

図図図図 1-8 メッセージ・クライアントメッセージ・クライアントメッセージ・クライアントメッセージ・クライアント

参照参照参照参照 : 第 4 章「Streams の適用プロセス」

参照参照参照参照 : 3-10 ページの「メッセージ・クライアント」


自動競合検出および解消の概要

自動競合検出および解消の概要自動競合検出および解消の概要自動競合検出および解消の概要自動競合検出および解消の概要適用プロセスは、レプリケーション環境で LCR を直接適用するときに、競合を自動的に検出します。通常、競合が発生するのは、ソース・データベース内と接続先データベース内で同じ行がほぼ同時に変更される場合です。

競合が発生した場合は、競合をビジネス・ルールに従って確実に解消するメカニズムが必要です。Streams には、様々なビルトイン競合ハンドラが用意されています。これらのビルトイン・ハンドラを使用すると、データベースごとに、ビジネス・ルールに従って競合を解消する競合解消システムを定義できます。Oracle のビルトイン競合解消ハンドラでは解消できない固有の状況がある場合は、独自の競合解消ハンドラを作成できます。

競合が解消されない場合や、ハンドラ・プロシージャにエラーが発生した場合、エラーを発生させたトランザクション内のすべてのイベントは、後で分析して可能であれば再実行できるようにエラー・キューに保存されます。

ルールの概要ルールの概要ルールの概要ルールの概要Streams では、どの情報をどのような場合に共有するかを、ルールルールルールルールを使用して制御できます。ルールは、SQL 問合せの WHERE句の条件と同様に、条件として指定します。

ルールの構成要素は、次のとおりです。

� ルール条件ルール条件ルール条件ルール条件は、1 つ以上の式と条件を組み合せてブール値を戻します。ブール値は、イベントに基づく TRUE、FALSEまたは NULL（不明）のいずれかです。

� ルール評価コンテキストルール評価コンテキストルール評価コンテキストルール評価コンテキストでは、ルール条件内で参照できる外部データを定義します。外部データは、外部変数または表データ、あるいはその両方として存在します。

� ルール・アクション・コンテキストルール・アクション・コンテキストルール・アクション・コンテキストルール・アクション・コンテキストはルールに関連付けられたオプションの情報であり、ルールが評価されるときにルール・エンジンのクライアントによって解析されます。

関連するルールをグループ化してルール・セットルール・セットルール・セットルール・セットを作成できます。Streams では、ルール・セットはポジティブまたはネガティブになります。

たとえば、表を所有するスキーマの名前が hr、表名が departmentsである場合に TRUEと評価されるように指定するには、ルールに次のルール条件を Streams で使用します。

:dml.get_object_owner() = 'HR' AND :dml.get_object_name() = 'DEPARTMENTS'

:dml変数は行 LCR のルール条件で使用されます。Streams 環境では、この条件を含むルールを次のように使用できます。

� ルールが取得プロセスのポジティブ・ルール・セットに含まれる場合、取得プロセスは、hr.departments表に対する DML の実行結果である行変更を取得します。ルー

参照参照参照参照 : 『Oracle Streams レプリケーション管理者ガイド』


変換の概要

ルが取得プロセスのネガティブ・ルール・セットに含まれる場合、取得プロセスは、hr.departments表に対する DML 変更を廃棄します。

� ルールが伝播のポジティブ・ルール・セットに含まれる場合、伝播は、hr.departments表に対する行変更を含む LCR を伝播します。ルールが伝播のネガティブ・ルール・セットに含まれる場合、伝播は、hr.departments表に対する行変更を含む LCR を廃棄します。

� ルールが適用プロセスのポジティブ・ルール・セットに含まれる場合、適用プロセスは、hr.departments表に対する行変更を含む LCR を適用します。ルールが適用プロセスのネガティブ・ルール・セットに含まれる場合、適用プロセスは、hr.departments表に対する行変更を含む LCR を廃棄します。

� ルールがメッセージ・クライアントのポジティブ・ルール・セットに含まれる場合、メッセージ・クライアントは、hr.departments表に対する行変更を含む LCR をデキューします。ルールがメッセージ・クライアントのネガティブ・ルール・セットに含まれる場合、メッセージ・クライアントは、hr.departments表に対する行変更を含む LCR を廃棄します。

Streams では、タスクはルールに基づいて実行されます。これらのタスクには、取得プロセスによるイベントの取得、伝播によるイベントの伝播、適用プロセスによるイベントの適用、メッセージ・クライアントによるイベントのデキュー、イベントの廃棄などがあります。

変換の概要変換の概要変換の概要変換の概要ルールベースの変換ルールベースの変換ルールベースの変換ルールベースの変換は、ポジティブ・ルール・セットのルールが TRUEに評価される場合に発生するイベントの変更です。たとえば、ルールベースの変換で、イベントについて表内にある特定の列のデータ型を変更できます。この場合、入力として列の NUMBERデータ型のLCR を含む SYS.AnyDataオブジェクトを取り、同じ列の VARCHAR2データ型の LCR を含む SYS.AnyDataオブジェクトを戻す PL/SQL ファンクションを変換に使用できます。

変換は、次の時点で発生します。

� 取得プロセスによるイベントのエンキュー時。すべての接続先データベースに適切な方法でイベントをフォーマットする場合に役立ちます。

� イベントの伝播時。リモート・サイトに送信する前にデータをサブセット化する場合に役立ちます。

� 適用プロセスまたはメッセージ・クライアントによるイベントのデキュー時。特定の接続先データベースに適切な方法でイベントをフォーマットする場合に役立ちます。





Streams タグの概要

適用中に変換を実行すると、適用プロセスは変換済イベントを直接適用するか、または変換済イベントを適用ハンドラに送信して処理させることができます。図 1-9 に、適用中のルールベースの変換を示します。

図図図図 1-9 適用中の変換適用中の変換適用中の変換適用中の変換

Streams タグの概要タグの概要タグの概要タグの概要REDO ログの各 REDO エントリには、タグタグタグタグが関連付けられています。タグのデータ型はRAWです。デフォルトでは、ユーザーまたはアプリケーションが REDO エントリを生成する時点では、各 REDO エントリのタグの値は NULLであり、NULLタグは REDO エントリの領域をコンシュームしません。タグ値のサイズの上限は 2000 バイトです。

Streams では、タグ値に関連する条件がルールに含まれ、これによって Streams クライアントの動作を制御できます。たとえば、タグを使用すると、LCR に含まれている変更の発生場所が、ローカル・データベースであるか他のデータベースであるかを判断できるため、変更の循環（発生場所となったデータベースへの LCR の送信）を回避できます。また、タグを使用して、LCR ごとに接続先データベースのセットを指定することもできます。タグは他のLCR の追跡にも使用できます。

注意注意注意注意 : ルールベースの変換を実行するには、ルールをポジティブ・ルール・セットに含める必要があります。ネガティブ・ルール・セット内のルールに指定したルールベースの変換は、取得プロセス、伝播、適用プロセスおよびメッセージ・クライアントによって無視されます。

参照参照参照参照 : 6-56 ページの「ルールベースの変換」


異機種間での情報共有の概要

特定のセッションまたは適用プロセスによって生成される REDO エントリ用に、Streams タグを指定できます。これらのタグは、取得プロセスによって取得される LCR の一部となります。通常、タグは Streams レプリケーション環境で使用されますが、データベース変更および LCR を追跡するために、必要に応じて使用できます。

異機種間での情報共有の概要異機種間での情報共有の概要異機種間での情報共有の概要異機種間での情報共有の概要Streams では、Oracle データベース間のみでなく、Oracle データベースと Oracle 以外のデータベースの間でも情報の共有がサポートされます。ここでは、このサポートの概要について説明します。

Oracle データベースからデータベースからデータベースからデータベースから Oracle 以外のデータベースへのデータ共有の概要以外のデータベースへのデータ共有の概要以外のデータベースへのデータ共有の概要以外のデータベースへのデータ共有の概要ソース・データベースが Oracle で、接続先データベースが Oracle 以外の場合、Oracle 以外の接続先データベースには次の Streams メカニズムがありません。

� イベントを受信するためのキュー

� イベントをデキューして適用する適用プロセス

Oracle ソース・データベースの DML 変更を Oracle 以外の接続先データベースと共有するために、Oracle データベースはプロキシとして機能し、通常は接続先データベースで実行される手順の一部を実行します。つまり、Oracle 以外の接続先データベースを対象とするイベントは、Oracle データベース自体でデキューされ、Oracle データベースの適用プロセスは異機種間サービスを使用し、ゲートウェイを介してネットワーク接続経由でイベントを Oracle以外のデータベースに適用します。図 1-10 に、Oracle 以外のデータベースとデータを共有している Oracle データベースを示します。

参照参照参照参照 : Streams タグの詳細は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。

参照参照参照参照 : Streams を使用した異機種間での情報共有の詳細は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。



図図図図 1-10 Oracle データベースからデータベースからデータベースからデータベースから Oracle 以外のデータベースへの異機種間データ共有以外のデータベースへの異機種間データ共有以外のデータベースへの異機種間データ共有以外のデータベースへの異機種間データ共有

Oracle 以外のデータベースから以外のデータベースから以外のデータベースから以外のデータベースから Oracle データベースへのデータ共有の概要データベースへのデータ共有の概要データベースへのデータ共有の概要データベースへのデータ共有の概要Oracle 以外のデータベースから変更を取得して Oracle データベースに伝播するには、カスタム・アプリケーションが必要です。このアプリケーションは、トランザクション・ログを読み込むか、トリガーを使用するか、または他のなんらかの方法で、Oracle 以外のデータベースに対する変更を取得します。このアプリケーションではトランザクションをアセンブルして順序付けし、それぞれの変更を LCR に変換する必要があります。次に、PL/SQL インタフェースを使用して、適用プロセスで処理できるように LCR を Oracle データベースのキューにエンキューします。図 1-11 に、Oracle データベースとデータを共有しているOracle 以外のデータベースを示します。

参照参照参照参照 : 異機種間サービスの詳細は、『Oracle Database Heterogeneous Connectivity 管理者ガイド』を参照してください。



図図図図 1-11 Oracle 以外のデータベースから以外のデータベースから以外のデータベースから以外のデータベースから Oracle データベースへの異機種間データ共有データベースへの異機種間データ共有データベースへの異機種間データ共有データベースへの異機種間データ共有


Streams 構成の例

Streams 構成の例構成の例構成の例構成の例図 1-12 に、単一データベース内の情報を共有するように Streams を構成する方法を示します。図 1-13 には、2 つの異なるデータベース間で情報を共有するように Streams を構成する方法を示します。

図図図図 1-12 単一データベースでの単一データベースでの単一データベースでの単一データベースでの Streams 構成構成構成構成


Streams 環境用の管理ツール

図図図図 1-13 データベース間で情報を共有するデータベース間で情報を共有するデータベース間で情報を共有するデータベース間で情報を共有する Streams 構成構成構成構成

Streams 環境用の管理ツール環境用の管理ツール環境用の管理ツール環境用の管理ツールStreams 環境の構成、管理および監視には、複数のツールを使用できます。オラクル社が提供する PL/SQL パッケージは主要な構成および管理ツールですが、Oracle Enterprise Manager コンソールの Streams ツールにも環境を管理できるように構成、管理および監視機能が用意されています。また、Streams データ・ディクショナリ・ビューには、Streams 環境に関する情報が常に表示されます。



オラクル社が提供するオラクル社が提供するオラクル社が提供するオラクル社が提供する PL/SQL パッケージパッケージパッケージパッケージオラクル社が提供する次の PL/SQL パッケージには、Streams 環境の構成と管理用のプロシージャとファンクションが含まれています。

DBMS_STREAMS_ADM パッケージパッケージパッケージパッケージDBMS_STREAMS_ADMパッケージには、表、スキーマ、データベースの各レベルでの取得プロセス、伝播および適用プロセスに関する単純なルールを追加および削除するための管理インタフェースが用意されています。このパッケージを使用すると、伝播によって伝播されるイベント、およびメッセージ・クライアントによってデキューされるイベントを制御するルールを追加することもできます。また、このパッケージには、キューを作成し、データ・ディクショナリ情報など、Streams のメタデータを管理するためのプロシージャも含まれています。このパッケージには、特定の表領域用の Streams レプリケーション環境を構成および管理するためのプロシージャも含まれています。このパッケージは、Streams 環境で共通のタスクを完了するための簡便な方法として提供されます。DBMS_CAPTURE_ADM、DBMS_PROPAGATION_ADM、DBMS_APPLY_ADM、DBMS_RULE_ADM、DBMS_AQADMなど、他のパッケージを使用すると、これと同じタスクのみでなく、追加のカスタマイズを必要とするタスクを完了できます。

DBMS_CAPTURE_ADM パッケージパッケージパッケージパッケージDBMS_CAPTURE_ADMパッケージには、取得プロセスを起動、停止および構成するための管理インタフェースが用意されています。また、このパッケージには、接続先データベースでインスタンス化するために、ソース・データベースでデータベース・オブジェクトを準備するための管理プロシージャも用意されています。

DBMS_PROPAGATION_ADM パッケージパッケージパッケージパッケージDBMS_PROPAGATION_ADMパッケージには、ソース・キューから宛先キューへの伝播を構成するための管理インタフェースが用意されています。

DBMS_APPLY_ADM パッケージパッケージパッケージパッケージDBMS_APPLY_ADMパッケージには、適用プロセスを起動、停止および構成するための管理インタフェースが用意されています。このパッケージには、適用ハンドラを構成し、イベントのエンキューの宛先を設定し、イベントの実行ディレクティブを指定するためのプロシージャが含まれています。また、このパッケージには、接続先データベースでオブジェクトのインスタンス化 SCN を設定するための管理プロシージャも用意されています。さらに、競合検出と解消を構成するためのサブプログラム、および適用エラーを管理するためのサブプログラムも含まれています。

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



DBMS_STREAMS_MESSAGING パッケージパッケージパッケージパッケージDBMS_STREAMS_MESSAGINGパッケージには、SYS.AnyDataキューにメッセージをエンキューしたり、SYS.AnyData キューからメッセージをデキューするためのインタフェースが用意されています。

DBMS_RULE_ADM パッケージパッケージパッケージパッケージDBMS_RULE_ADMパッケージには、ルール、ルール・セットおよびルール評価コンテキストを作成および管理するための管理インタフェースが用意されています。さらに、ルールに関連する権限を管理するためのサブプログラムも含まれています。

DBMS_RULE パッケージパッケージパッケージパッケージDBMS_RULEパッケージには、ルール・セットを評価する EVALUATEプロシージャが含まれています。このプロシージャの目的は、データに基づいて条件を満たすルールのリストを生成することです。このパッケージには、ルール評価中にイテレータを使用するためのサブプログラムも含まれています。イテレータは、評価に対して TRUEまたは MAYBEと評価されるすべてのルールを戻すのではなく、ルールを 1 つずつ戻すことができます。

DBMS_STREAMS パッケージパッケージパッケージパッケージDBMS_STREAMSパッケージには、SYS.AnyDataオブジェクトを LCR オブジェクトに変換し、Streams 属性および Streams クライアントの情報を戻し、さらにセッションで生成された REDO エントリにタグで注釈を付けるためのインタフェースが用意されています。このタグは、ルールに REDO エントリまたは LCR 内のバイナリ・タグの仕様が含まれている取得プロセス、伝播ジョブ、適用プロセスまたはメッセージ・クライアントの動作に影響する場合があります。

DBMS_STREAMS_AUTH パッケージパッケージパッケージパッケージDBMS_STREAMS_AUTHパッケージには、Streams 管理者の権限の付与および取消しを行うためのインタフェースが用意されています。

DBMS_STREAMS_TABLESPACE_ADMDBMS_STREAMS_TABLESPACE_ADMパッケージには、データベース間で表領域をコピーするための管理プロシージャ、およびあるデータベースから別のデータベースに表領域を移動するための管理プロシージャが含まれています。このパッケージでは、トランスポータブル表領域、Data Pump および DBMS_FILE_TRANSFERパッケージが使用されます。



Streams のデータ・ディクショナリ・ビューのデータ・ディクショナリ・ビューのデータ・ディクショナリ・ビューのデータ・ディクショナリ・ビューStreams 環境内の各データベースには、Streams のデータ・ディクショナリ・ビューがあります。これらのビューでは、ローカルのルール、オブジェクト、取得プロセス、伝播、適用プロセスおよびメッセージ・クライアントに関する管理情報が保持されます。これらのビューを使用して、Streams 環境を監視できます。

Oracle Enterprise Manager コンソールのコンソールのコンソールのコンソールの Streams ツールツールツールツールStreams 環境の構成、管理および監視を容易にするために、Oracle では Oracle Enterprise Manager のコンソールに Streams ツールを用意しています。また、Streams ツールを使用すると、Streams 構成スクリプトを生成し、それを変更して実行し、Streams 環境を構成できます。Streams ツールの主な資料は、オンライン・ヘルプです。図 1-14 に、Streams ツールの「「「「Topology」」」」タブを示します。


� 第 14 章「Streams 環境の監視」

� Streams レプリケーション環境で有効な問合せの例については、『Oracle Streams レプリケーション管理者ガイド』を参照してください。

� これらのデータ・ディクショナリ・ビューの詳細は、『Oracle Database リファレンス』を参照してください。



図図図図 1-14 Streams ツールツールツールツール

参照参照参照参照 : Streams ツールの使用方法の詳細は、Oracle Enterprise Managerコンソールのオンライン・ヘルプを参照してください。




Streams の取得プロ

2
Streams の取得プロセスの取得プロセスの取得プロセスの取得プロセス
この章では、Streams の取得プロセスの概念とアーキテクチャについて説明します。


� REDO ログと取得プロセス

� 論理変更レコード（LCR）

� 取得プロセスのルール

� 取得されるデータ型

� 取得される変更のタイプ

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

� Streams 環境でのインスタンス化

� ローカル取得とダウンストリーム取得

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

� Streams の取得プロセスと RESTRICTED SESSION

� Streams の取得プロセスと Oracle Real Application Clusters

� 取得プロセスのアーキテクチャ

参照参照参照参照 : 第 9 章「取得プロセスの管理」

セス 2-1

REDO ログと取得プロセス

REDO ログと取得プロセスログと取得プロセスログと取得プロセスログと取得プロセス各 Oracle データベースには、2 つ以上の REDO ログ・ファイルのセットがあります。データベースの REDO ログ・ファイルを総称して、データベースの REDO ログと呼びます。REDO ログの主要機能は、データベースに対して行われた変更をすべて記録することです。

REDO ログは、人為的エラーやメディア障害が発生した場合のリカバリ能力を保証するために使用されます。取得プロセス取得プロセス取得プロセス取得プロセスはオプションの Oracle バックグラウンド・プロセスであり、データベースの REDO ログをスキャンし、データベース・オブジェクトに対する DML 変更と DDL 変更を取得します。取得プロセスが REDO ログから変更を取得するように構成されている場合、変更が生成されたデータベースはソース・データベースソース・データベースソース・データベースソース・データベースと呼ばれます。

取得プロセスは、ソース・データベースまたはリモート・データベース上で実行されます。取得プロセスをソース・データベース上で実行する場合、取得プロセスはローカルの取得プロセスになります。取得プロセスがリモート・データベース上で実行される場合、そのリモート・データベースはダウンストリーム・データベースダウンストリーム・データベースダウンストリーム・データベースダウンストリーム・データベースと呼ばれます。取得プロセスがダウンストリーム・データベースで実行される場合、ソース・データベースのアーカイブREDO ログ・ファイルはダウンストリーム・データベースにコピーされ、取得プロセスが、そのダウンストリーム・データベースでこれらのファイルの変更を取得します。

論理変更レコード（論理変更レコード（論理変更レコード（論理変更レコード（LCR））））取得プロセスは、REDO ログから取得した変更を LCR 形式に再フォーマットします。LCRは、データベース変更を記述する特定のフォーマットを持ったオブジェクトです。取得プロセスは、行行行行 LCR および DDL LCR という 2 種類の LCR を取得します。行 LCR および DDL LCR の詳細は、この項の後半で説明します。

LCR の取得後に、取得プロセスは LCR を含むイベントをキューにエンキューします。取得プロセスには常に単一の SYS.AnyDataキューが関連付けられており、このキューにのみイベントをエンキューします。パフォーマンスを改善するために、取得されたイベントが常にバッファリングされたキュー、すなわち SYS.AnyDataキューに関連付けられたシステム・グローバル領域（SGA）メモリーに格納されます。複数のキューを作成し、各キューに異なる取得プロセスを関連付けることができます。図 2-1 に、LCR を取得する取得プロセスを示します。

注意注意注意注意 : 取得プロセスを関連付けることができるのは SYS.AnyDataキューのみで、型付きのキューに関連付けることはできません。


論理変更レコード（LCR）

図図図図 2-1 取得プロセス取得プロセス取得プロセス取得プロセス

行行行行 LCR行 LCR では、1 行のデータに対する変更、あるいは 1 行の単一 LONG、LONG RAWまたはLOB 列に対する変更が記述されます。この変更は、データ操作言語（DML）文または LOBのピース単位更新によるものです。たとえば、単一の DML 文では、表に複数の行を挿入またはマージしたり、表の複数の行を更新したり、表から複数の行を削除する場合があります。

そのため、単一の DML 文で複数の行 LCR が生成される可能性があります。つまり、取得プロセスでは DML 文によって変更される行ごとに LCR が作成されます。また、1 行の LONG、


� LCR の管理の詳細は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。

� LCR 型の詳細は、『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。


Streams の取得プロセス 2-3


LONG RAWまたは LOB 列に対する更新を行うことによって複数の行 LCR が生成される場合があります。

それぞれの行 LCR は、LCR$_ROW_RECORDタイプのオブジェクトにカプセル化されます。行 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: 変更レコードが REDO ログに書き込まれたときのシステム変更番号（SCN）。

� old_values: 変更に関連する古い列値。これらの値は、DML 変更前の行の列値です。DML 文のタイプが UPDATEまたは DELETEの場合、これらの古い値には、DML 文の実行前に変更があった行の一部またはすべての列が含まれます。DML 文のタイプがINSERTの場合、古い値はありません。

� new_values: 変更に関連する新しい列値。これらの値は、DML 変更後の行の列値です。DML 文のタイプが UPDATEまたは INSERTの場合、これらの新規の値には、DML文の実行後に変更があった行の一部またはすべての列が含まれます。DML 文のタイプが DELETEの場合、新規の値はありません。

取得された行 LCR には、トランザクション制御文も含まれている場合があります。これらの行 LCR には、COMMITや ROLLBACKなどのディレクティブが含まれています。このような行 LCR は内部的であり、ソース・データベースと接続先データベースの間でトランザクションの一貫性を保つために適用プロセスによって使用されます。

DDL LCRDDL LCR では、データ定義言語（DDL）の変更が記述されます。DDL 文は、データベースの構造を変更します。たとえば、DDL 文でデータベース・オブジェクトを作成、変更または削除できます。

それぞれの DDL LCR には、次の情報が含まれます。

� source_database_name: DDL の変更が発生したソース・データベースの名前。

� 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: 変更が REDO ログに書き込まれた時点の SCN。

LCR 内の追加情報内の追加情報内の追加情報内の追加情報前項で説明した情報の他に、オプションで、行 LCR と DDL LCR に、次の追加情報（LCR属性）が含まれている場合があります。

� row_id: 行 LCR に含まれる変更があった行の ROWID。この属性は、DDL LCR および索引構成表の行 LCR には含まれません。

� serial#: LCR に含まれる取得された変更を実行したセッションのシリアル番号。

� session#: LCR に含まれる取得された変更を実行したセッションの識別子。

� thread#: LCR に含まれる取得された変更が実行されたインスタンスのスレッド番号。通常、スレッド番号は、Real Application Clusters 環境でのみ使用されます。

� tx_name: LCR を含むトランザクションの名前。

注意注意注意注意 : 行 LCR と DDL LCR の両方に、変更が発生したデータベースのソース・データベース名が含まれています。取得された LCR が伝播によって伝播されるか、適用プロセスによって適用される場合は、伝播と適用に伴う問題を回避するために、取得プロセスによる変更の取得が開始された後はソース・データベースの名前を変更しないことをお薦めします。

参照参照参照参照 : DDL 文の全タイプのリストは、『Oracle Call Interface プログラマーズ・ガイド』の表「SQL コマンド・コード」を参照してください。


取得プロセスのルール

� username: LCR に含まれる取得された変更を実行したユーザーの名前。

1 つ以上の追加の属性を取得するように取得プロセスに指示するには、DBMS_CAPTURE_ADMパッケージの INCLUDE_EXTRA_ATTRIBUTEプロシージャを使用します。

取得プロセスのルール取得プロセスのルール取得プロセスのルール取得プロセスのルール取得プロセスでは、定義したルールに基づいて変更が取得または廃棄されます。各ルールでは、TRUEと評価するデータベース・オブジェクトおよび変更のタイプを指定します。これらのルールは、取得プロセスのポジティブ・ルール・セットおよびネガティブ・ルール・セットに含めることができます。

ルールが変更について TRUEと評価され、そのルールが取得プロセスのポジティブ・ルール・セットに含まれる場合、取得プロセスはその変更を取得します。ルールが変更についてTRUEと評価され、そのルールが取得プロセスのネガティブ・ルール・セットに含まれる場合、取得プロセスは変更を廃棄します。取得プロセスにポジティブ・ルール・セットとネガティブ・ルール・セットの両方がある場合、常にネガティブ・ルール・セットが初に評価されます。

取得プロセスのルールは次のレベルで指定できます。

� 表ルールは、特定の表に対する DML 変更や DDL 変更によって発生したいずれかの行変更を取得または廃棄します。サブセット・ルールは、特定の表に対する行変更のサブセットを含む表ルールです。

� スキーマ・ルールは、特定のスキーマのデータベース・オブジェクトに対する DML 変更や DDL 変更によって発生したいずれかの行変更を取得または廃棄します。

� グローバル・ルールは、データベース内のすべての DML 変更または DDL 変更によって発生したすべての行変更を取得または廃棄します。


� 9-35 ページの「取得 LCR 内の追加の属性の管理」

� 14-15 ページの「各取得プロセスで取得された追加の属性の表示」

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

注意注意注意注意 : 取得プロセスは、特定のタイプの変更と表の列の特定のデータ型に対する変更を取得しません。また、SYS、SYSTEMまたは CTXSYSスキーマ内での変更は取得しません。


取得されるデータ型

取得されるデータ型取得されるデータ型取得されるデータ型取得されるデータ型表に対する DML 変更によって発生した行変更を取得するときに、取得プロセスは次のデータ型の列に対する変更を取得できます。

� VARCHAR2

� NVARCHAR2

� 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

� CLOB

� NCLOB

� BLOB

� UROWID

取得プロセスは、データ型 BFILEと ROWIDの列およびユーザー定義型（オブジェクト型、REF、VARRAY、ネストした表、Oracle が提供する型など）の列に対する DML 変更の結果は取得しません。取得プロセスで、サポートされていないデータ型の列を含む表に対するDML 変更について行 LCR の作成が試行されると、エラーが発生します。





取得されるデータ型

取得プロセスにエラーが発生すると、エラーの原因となった LCR がトレース・ファイルに書き込まれ、ORA-00902 エラーが発生し、取得プロセスが無効化されます。この場合、取得プロセスで使用されるルールを変更してエラーを回避し、取得プロセスを再起動します。

注意注意注意注意 :

� 取得プロセスのネガティブ・ルール・セットに、取得プロセスに対して、サポートされていないデータ型の列を含む表に対する変更を廃棄するように指示するルールを追加できます。ただし、これらのルールが単純なルールではない場合、取得プロセスで変更に対する行 LCRが作成され、引き続き処理される場合があります。この場合、変更が取得プロセスで使用されるルール・セットを満たさない場合でも、サポートされていないデータ型が変更に含まれていると、取得プロセスでエラーが発生する場合があります。DBMS_STREAMS_ADMパッケージでは、単純なルールのみが作成されます。

� Oracle の以前のリリースでは、Streams で前述のデータ型の一部がサポートされていない場合があります。Streams 環境に Oracle の以前のリリースのデータベースが 1 つ以上含まれている場合、行 LCR が、この行 LCR に含まれるすべてのデータ型がサポートされていないデータベースに送られないことを確認してください。サポートされるデータ型については、Oracle の以前のリリースの Streams マニュアルを参照してください。


� Streams クライアントのルール・セットの詳細、およびイベントがルール・セットを満たす場合の詳細は、第 6 章「Streams でのルールの使用方法」を参照してください。

� 2-44 ページの「取得プロセス・ルールの評価」

� 適用プロセスによって適用できるデータ型については、4-10 ページの「適用されるデータ型」を参照してください。

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


取得される変更のタイプ

取得される変更のタイプ取得される変更のタイプ取得される変更のタイプ取得される変更のタイプ取得プロセスは、データベースとそのオブジェクトに対して行われた特定タイプの変更のみを取得できます。次の項では、取得できる DML 変更と DDL 変更のタイプを説明します。

取得される取得される取得される取得される DML 変更のタイプ変更のタイプ変更のタイプ変更のタイプ特定の表に対する DML 変更を取得するように指定すると、取得プロセスはそれらの表に対する次のタイプの DML 変更を取得します。

� INSERT

� UPDATE

� DELETE

� MERGE

� LOB のピース単位更新

DML 変更を取得する際の考慮事項は、次のとおりです。

� 取得プロセスは、各 MERGE変更を INSERT変更または UPDATE変更に変換します。MERGEは、行 LCR では有効なコマンド・タイプではありません。

� 取得プロセスでは、索引構成表が次の条件を満たす場合のみ、索引構成表に対する変更を取得できます。

� 索引構成表が OVERFLOW句を必要としない。

� 索引構成表に、データ型 LONG、LONG RAW、CLOB、NCLOB、BLOB、BFILE、ROWID、UROWIDおよびユーザー定義型（オブジェクト型、REF、VARRAY、ネストした表など）の列が含まれていない。

� 索引構成表がパーティション化されており、行の移動が有効になっていない。

索引構成表がこれらの要件を満たさない場合、ユーザーが索引構成表を変更し、この変更が取得プロセスのルール・セットを満たすと、取得プロセスでエラーが発生します。

� 取得プロセスは、CALL、EXPLAIN PLANまたは LOCK TABLE文を取得しません。

� 取得プロセスでは、一時表またはオブジェクト表に対する DML 変更は取得できません。

注意注意注意注意 : 取得プロセスは、SYS、SYSTEMまたは CTXSYSスキーマ内での変更は取得しません。

参照参照参照参照 : 適用プロセスによって適用できる変更のタイプについては、第 4章「Streams の適用プロセス」を参照してください。



� 順序を複数のデータベースで共有する場合、これらのデータベースで個々の行に使用される順序値が異なっている可能性があります。また、実際の順序値に対する変更は取得されません。たとえば、ユーザーが NEXTVALを参照するか、順序を設定する場合、取得プロセスではこれらの操作によって発生する変更は取得されません。

取得プロセスによって無視される取得プロセスによって無視される取得プロセスによって無視される取得プロセスによって無視される 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を無視して、それに関する情報を適用プロセスのトレース・ファイルに記録します。


� 取得プロセスでサポートされるデータ型については、2-7 ページの「取得されるデータ型」を参照してください。


� 適用プロセスを使用した DML 変更の適用、および様々なデータベースで 2 つの異なる行の順序生成値が同一になることを回避する方針については、『Oracle Streams レプリケーション管理者ガイド』を参照してください。



取得プロセスによって無視されるその他のタイプの変更取得プロセスによって無視されるその他のタイプの変更取得プロセスによって無視されるその他のタイプの変更取得プロセスによって無視されるその他のタイプの変更次のタイプの変更は、取得プロセスによって無視されます。

� セッション制御文 ALTER SESSIONおよび SET ROLE

� システム制御文 ALTER SYSTEM

� PL/SQL プロシージャの起動。これは、PL/SQL プロシージャのコールが取得されないことを意味します。ただし、PL/SQL プロシージャのコールによってデータベース・オブジェクトが変更される場合、これらの変更が取得プロセスのルール・セットを満たせば、取得プロセスで変更が取得されます。

また、取得プロセスが変更を取得する表またはスキーマでは、DBMS_REDEFINITIONパッケージを使用したオンラインの表の再定義はサポートされません。

SQL 操作用の操作用の操作用の操作用の NOLOGGING およびおよびおよびおよび UNRECOVERABLE キーワードキーワードキーワードキーワードSQL 操作に NOLOGGINGまたは UNRECOVERABLEキーワードを使用した場合、SQL 操作によって発生する変更は取得プロセスで取得できません。したがって、SQL 操作によって発生する変更を取得する場合は、これらのキーワードを使用しないでください。

ロギング属性を指定しているオブジェクトが FORCE LOGGINGモードのデータベースまたは表領域に存在する場合、このデータベースまたは表領域が FORCE LOGGINGモードでなくなるまで、Oracle では NOLOGGINGまたは UNRECOVERABLE設定は無視されます。データベースの現行ロギング・モードを判別するには、V$DATABASE動的パフォーマンス・ビューのFORCE_LOGGING列を問い合せます。表領域の現行ロギング・モードを判別するには、DBA_TABLESPACES静的データ・ディクショナリ・ビューの FORCE_LOGGING列を問い合せます。


� 適用プロセスを使用した DDL 変更の適用については、『Oracle Streams レプリケーション管理者ガイド』を参照してください。




ダイレクト・パス・ロードのダイレクト・パス・ロードのダイレクト・パス・ロードのダイレクト・パス・ロードの UNRECOVERABLE 句句句句ダイレクト・パス・ロードで SQL*Loader 制御ファイルに UNRECOVERABLE句を使用した場合、ダイレクト・パス・ロードによって発生する変更は取得プロセスで取得できません。したがって、ダイレクト・パス・ロードによって発生する変更を取得プロセスで取得する必要がある場合、UNRECOVERABLE句は使用しないでください。

ソース・データベースで変更をログに記録せずにダイレクト・パス・ロードを実行し、ソース・データベースの接続先データベースで同様のダイレクト・パス・ロードを実行しない場合、ソース・データベースのロード済オブジェクトに変更が加えられると、これらの接続先データベースで適用エラーが発生する可能性があります。この場合、ソース・データベースでの取得プロセスはこれらのオブジェクトに対する変更を取得し、1 つ以上の伝播で接続先データベースに対する変更を伝播できますが、これらのオブジェクトが接続先データベースに存在しないか、またはオブジェクトが接続先データベースに存在しても、これらの変更に関連する行が存在しない可能性があります。

したがって、ダイレクト・パス・ロードで UNRECOVERABLE句を使用し、取得プロセスがロード済オブジェクトに対する変更を取得するように構成されている場合、適用エラーを回避するために、接続先データベースにロード済オブジェクトおよびロード済データが含まれることを確認してください。これらのオブジェクトが接続先データベースで確実に存在するようにするには、ソース・データベースで実行したダイレクト・パス・ロードと同様のダイレクト・パス・ロードを、これらの各接続先データベースで実行する方法があります。

FORCE LOGGINGモードのデータベースまたは表領域にオブジェクトをロードする場合、Oracle ではダイレクト・パス・ロード時に UNRECOVERABLE句が無視され、ロード済変更がログに記録されます。データベースの現行ロギング・モードを判別するには、V$DATABASE動的パフォーマンス・ビューの FORCE_LOGGING列を問い合せます。表領域の現行ロギング・モードを判別するには、DBA_TABLESPACES静的データ・ディクショナリ・ビューの FORCE_LOGGING列を問い合せます。

注意注意注意注意 : UNRECOVERABLEキーワードは推奨できないため、logging_clauseでは NOLOGGINGキーワードに置き換えられています。UNRECOVERABLEは下位互換性のためサポートされていますが、可能な場合は常に NOLOGGINGキーワードを使用することをお薦めします。

参照参照参照参照 : NOLOGGINGおよび UNRECOVERABLEキーワード、FORCE LOGGINGモード、および logging_clauseの詳細は、『Oracle Database SQL リファレンス』を参照してください。

参照参照参照参照 : ダイレクト・パス・ロードおよび SQL*Loader については、『Oracle Database ユーティリティ』を参照してください。


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

Streams 環境内のサプリメンタル・ロギング環境内のサプリメンタル・ロギング環境内のサプリメンタル・ロギング環境内のサプリメンタル・ロギングサプリメンタル・ロギングでは、操作が実行されるたびに REDO ログに列データが追加されます。取得プロセスは、この追加情報を取得して LCR に含めます。サプリメンタル・ロギングは、ソース・データベースに対する変更を取得する取得プロセスの位置に関係なく、常にソース・データベースで構成されます。

通常、サプリメンタル・ロギングは、Streams レプリケーション環境で必要です。これらの環境では、ソース・データベースから接続先データベースにレプリケートされた DML 変更および DDL 変更を適切に適用するために、適用プロセスで LCR に追加情報が必要になります。ただし、適用プロセスで変更がデータベース・オブジェクトに直接適用されない環境でも、サプリメンタル・ロギングが必要な場合があります。このような環境では、変更が、適用ハンドラによってデータベース・オブジェクトに適用されることなく処理される場合があり、適用ハンドラに補足情報が必要な場合があります。

Streams 環境でのインスタンス化環境でのインスタンス化環境でのインスタンス化環境でのインスタンス化単一のデータベース内または複数のデータベース間で 1 つのデータベース・オブジェクトを共有する Streams 環境では、ソース・データベースとはオブジェクトに対する変更が REDOログ内で生成されるデータベースで、接続先データベースとは適用プロセスによってこれらの変更がデキューされるデータベースです。このような変更が取得プロセスで取得されているか、今後取得され、その変更がローカルに適用されるか、他のデータベースに伝播されてから接続先データベースで適用される場合は、適用プロセスでこれらの変更をデキューおよび処理するために、ソース・データベース・オブジェクトをインスタンス化インスタンス化インスタンス化インスタンス化する必要があります。ソース・データベース・オブジェクトに対する変更が適用されるデータベースがソース・データベース以外のデータベースである場合、接続先データベースにこれらのデータベース・オブジェクトのコピーが存在する必要があります。

Streams では、次の一般的な手順に従って、データベース・オブジェクトをインスタンス化します。

1. ソース・データベースで、オブジェクトをインスタンス化のために準備します。

2. 接続先データベースにオブジェクトのコピーが存在しない場合、ソース・データベースのオブジェクトに基づいて、接続先データベースでオブジェクトを物理的に作成します。インスタンス化のためにデータベース・オブジェクトをコピーするには、エクスポート / インポート、トランスポータブル表領域または Recovery Manager を使用できます。データベース・オブジェクトが接続先データベースに存在する場合、この手順は不要です。

3. 接続先データベースで、データベース・オブジェクトのインスタンス化 SCN を設定します。インスタンス化 SCN は、接続先データベースの適用プロセスに対して、特定のSCN より後にソース・データベースでコミットされた変更のみを適用するように指示します。

参照参照参照参照 : サプリメンタル・ロギングが必要な場合の詳細は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。


ローカル取得とダウンストリーム取得

手順 1 および手順 3 は、自動的に完了する場合があります。たとえば、DBMS_STREAMS_ADMパッケージのプロシージャを実行して、オブジェクトのルールを取得プロセスのポジティブ・ルール・セットに追加する場合、そのオブジェクトはインスタンス化のために自動的に準備されます。また、エクスポート / インポートまたはトランスポータブル表領域を使用して、ソース・データベースから接続先データベースにデータベース・オブジェクトをコピーする場合、これらのオブジェクトに初期化 SCN が自動的に設定されます。適用プロセスで LCR がこれらの LCR を実行しない適用ハンドラに送られる場合でも、取得された LCR が適用プロセスでデキューされるたびにインスタンス化を行う必要があります。

ローカル取得とダウンストリーム取得ローカル取得とダウンストリーム取得ローカル取得とダウンストリーム取得ローカル取得とダウンストリーム取得取得プロセスは、ソース・データベース上でローカルに実行されるか、またはダウンストリーム・データベース上でリモートに実行されるように構成できます。ここでは、これらのオプションの詳細を説明します。

ローカル取得ローカル取得ローカル取得ローカル取得ローカル取得は、ソース・データベース上で実行される取得プロセスです。2-3 ページの図2-1 に、ローカル取得を使用するデータベースを示します。

ソース・データベースによるすべての変更取得アクションの実行ソース・データベースによるすべての変更取得アクションの実行ソース・データベースによるすべての変更取得アクションの実行ソース・データベースによるすべての変更取得アクションの実行ローカル取得を構成すると、ソース・データベースで次のアクションが実行されます。

� DBMS_CAPTURE_ADM.BUILDプロシージャが実行され、データ・ディクショナリがREDO ログに抽出（構築）されます。

� ソース・データベースでのサプリメンタル・ロギングによって、追加情報が REDO ログに書き込まれます。この情報は、取得された変更が適用プロセスによって適用される際に必要な場合があります。

� データベースで取得プロセスが初に起動される場合、Oracle で、REDO ログに抽出されたデータ・ディクショナリ情報を使用して、LogMiner データ・ディクショナリが作

注意注意注意注意 : Streams でのインスタンス化には、Data Pump Export/Import またはオリジナルのエクスポート / インポートのいずれかを使用できます。このマニュアルでは、エクスポート / インポートとは、Data Pump Export/Import とオリジナルのエクスポート / インポートの両方を示します。このマニュアルでは、必要に応じて、Data Pump Export/Import とオリジナルのエスポート / インポートを区別しています。

参照参照参照参照 : Streams レプリケーション環境でのインスタンス化の詳細は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。



成されます。これは、ソース・データベースの 1 次データ・ディクショナリとは別のデータ・ディクショナリです。以後の取得プロセスでは、この既存の LogMiner データ・ディクショナリが使用される場合と、新しい LogMiner データ・ディクショナリが作成される場合があります。

� 取得プロセスで、LogMiner を使用して REDO ログの変更がスキャンされます。

� ルール・エンジンによって、1 つ以上の取得プロセスのルール・セットに含まれるルールに基づいて、変更が評価されます。

� 取得プロセスで、そのルール・セットに含まれるルールを満たす変更が、ローカルのSYS.AnyDataキューにエンキューされます。

� 取得された変更が 1 つ以上の他のデータベースと共有されている場合、1 つ以上の伝播によって、これらの変更がソース・データベースから他のデータベースに伝播されます。

� ソース・データベースのデータベース・オブジェクトを接続先データベースでインスタンス化する必要がある場合、オブジェクトをインスタンス化のために準備し、エクスポート・ユーティリティなどのメカニズムを使用してデータベース・オブジェクトのコピーを作成する必要があります。

ローカル取得のメリットローカル取得のメリットローカル取得のメリットローカル取得のメリットローカル取得を使用するメリットは、次のとおりです。

� ダウンストリーム取得を使用する場合より、取得プロセスを簡単に構成および管理できます。ローカル取得を使用すると、REDO ログ・ファイルがダウンストリーム・データベースにコピーされるように構成する必要がなく、取得した変更が行われたデータベースでローカルに取得プロセスを管理できます。

� ローカルの取得プロセスでは、データベースによってオンライン REDO ログの変更がアーカイブ REDO ログ・ファイルに書き込まれる前に、これらの変更をスキャンできます。ダウンストリーム取得を使用する場合、ダウンストリーム・データベースへのアーカイブ REDO ログ・ファイルのコピーはソース・データベースによる変更の書込みが終了した後に行われるため、ダウンストリーム・データベースへの REDO ログ・ファイルのコピーには時間がかかります。

� ダウンストリーム・データベースに REDO ログ・ファイル全体がコピーされないため、ネットワークを経由して送信されるデータの量が少なくなります。取得された LCR が他のデータベースに伝播される場合でも、取得された LCR は、データベースに対するすべての変更のサブセットである場合があり、伝播のルール・セットに含まれるルールを満たす LCR のみを伝播することができます。

� REDO ログ・ファイルにアクセスできるのはソース（ローカル）・データベースのみであるため、セキュリティを向上できます。たとえば、hrスキーマのみの変更を取得する場合にローカル取得を使用すると、ソース・データベースのみが REDO ログにアクセスし、hrスキーマに対する変更を取得プロセスのキューにエンキューできます。一方、ダウンストリーム取得を使用すると、REDO ログ・ファイルがダウンストリーム・



データベースにコピーされ、これらの REDO ログ・ファイルには、hrスキーマに対する変更のみでなく、データベースに対するすべての変更が含まれます。

� 取得プロセスがローカル・ソース・データベースで実行されている場合、一部のタイプのルールベースの変換を簡単に構成できます。たとえば、ローカル取得を使用すると、ルールベースの変換で、ソース・データベースに格納されたデータが移入されているPL/SQL セッション変数にキャッシュされた情報を使用できます。

� イベントの取得および適用が同じデータベースで行われる Streams 環境では、取得された変更およびローカルのデータに関する情報が必要なローカルの問合せおよび計算を簡単に構成でき、使用されるリソースも少なくなります。

ダウンストリーム取得ダウンストリーム取得ダウンストリーム取得ダウンストリーム取得ダウンストリーム取得は、ソース・データベース以外のデータベースで実行される取得プロセスです。ソース・データベースのアーカイブ REDO ログ・ファイルはダウンストリーム・データベースにコピーされ、取得プロセスが、そのダウンストリーム・データベースでこれらのファイル内の変更を取得します。ダウンストリーム・データベースにアーカイブ REDOログ・ファイルをコピーするには、ログ転送サービス、DBMS_FILE_TRANSFERパッケージ、ファイル転送プロトコル（FTP）などのメカニズムを使用します。



図図図図 2-2 ダウンストリーム取得ダウンストリーム取得ダウンストリーム取得ダウンストリーム取得

単一のソース・データベースから変更を取得するように、ダウンストリーム・データベースに複数の取得プロセスを構成することができます。また、複数のソース・データベースからREDO ログ・ファイルをコピーし、これらの REDO ログ・ファイルの変更を単一のダウンストリーム・データベースで取得するように、複数の取得プロセスを構成することもできます。

注意注意注意注意 : 図 2-2 に示すとおり、ダウンストリーム取得プロセスで取得される変更のソース・データベースは、変更が REDO ログへ記録されたデータベースです。ダウンストリーム取得プロセスを実行しているデータベースではありません。



さらに、単一のデータベースに、ローカルの変更を取得する 1 つ以上の取得プロセスおよびリモート・ソース・データベースの変更を取得する他の取得プロセスを含めることができます。つまり、単一のデータベースを構成することによって、ローカル取得とダウンストリーム取得の両方を実行できます。

ダウンストリーム・データベースによるほとんどの変更取得アクションダウンストリーム・データベースによるほとんどの変更取得アクションダウンストリーム・データベースによるほとんどの変更取得アクションダウンストリーム・データベースによるほとんどの変更取得アクションの実行の実行の実行の実行ダウンストリーム取得を構成すると、ダウンストリーム・データベースで次のアクションが実行されます。

� ダウンストリーム・データベースでダウンストリーム取得プロセスが初に起動される場合、Oracle で、REDO ログに含まれるデータ・ディクショナリ情報を使用して、ダウンストリーム・データベースに LogMiner データ・ディクショナリが作成されます。ソース・データベースで DBMS_CAPTURE_ADM.BUILDプロシージャが実行され、ソース・データベースの REDO ログにソース・データ・ディクショナリ情報が抽出されます。次に、ソース・データベースからダウンストリーム・データベースに REDO ログ・ファイルがコピーされます。同じソース・データベースに対する以後のダウンストリーム取得プロセスでは、この既存の LogMiner データ・ディクショナリが使用される場合と、新しい LogMiner データ・ディクショナリが作成される場合があります。

� 取得プロセスで、LogMiner を使用して REDO ログ・ファイルの変更がスキャンされます。

� ルール・エンジンによって、1 つ以上の取得プロセスのルール・セットに含まれるルールに基づいて、変更が評価されます。

� 取得プロセスで、そのルール・セットに含まれるルールを満たす変更が、ローカルのSYS.AnyDataキューにエンキューされます。

� 取得された変更が 1 つ以上の他のデータベースと共有されている場合、1 つ以上の伝播によって、これらの変更がダウンストリーム・データベースから他のデータベースに伝播されます。

ダウンストリーム取得を構成すると、ソース・データベースで次のアクションが実行されます。

� ソース・データベースで DBMS_CAPTURE_ADM.BUILDプロシージャが実行され、データ・ディクショナリが REDO ログに抽出されます。

� ソース・データベースでのサプリメンタル・ロギングによって、適用で必要となる可能性がある追加情報が REDO ログに書き込まれます。

� ソース・データベースのデータベース・オブジェクトを環境内の他のデータベースでインスタンス化する必要がある場合、オブジェクトをインスタンス化のために準備し、エ

参照参照参照参照 : ログ転送サービスの詳細は、『Oracle Data Guard 概要および管理』を参照してください。



クスポート・ユーティリティなどのメカニズムを使用してデータベース・オブジェクトのコピーを作成する必要があります。

また、ソース・データベースを実行しているコンピュータ・システムからダウンストリーム・データベースを実行しているコンピュータ・システムに REDO ログ・ファイルをコピーする必要があります。通常、ログ転送サービスによって、これらの REDO ログ・ファイルがダウンストリーム・データベースにコピーされます。

ダウンストリーム取得のメリットダウンストリーム取得のメリットダウンストリーム取得のメリットダウンストリーム取得のメリットダウンストリーム取得を使用するメリットは、次のとおりです。

� 必要な作業のほとんどがダウンストリーム・データベースによって実行されるため、ソース・データベースで変更の取得に使用されるリソースが少なくなります。

� 複数のソース・データベースで行われた変更を取得する予定の場合、1 つのダウンストリーム・データベースで様々なソース・データベースに対する複数の取得プロセスを実行することによって、取得プロセスを簡単に管理できます。1 つのダウンストリーム・データベースを、複数のソースから変更を取得するための中心として使用できます。

� REDO ログ・ファイルを 1 つ以上のダウンストリーム・データベースにコピーすることによって、データ損失に対する保護を強化できます。たとえば、ダウンストリーム・データベースの REDO ログ・ファイルをソース・データベースのリカバリに使用できる場合があります。

� 1 つ以上のダウンストリーム・データベースに、単一のソース・データベースから変更を取得する複数の取得プロセスを構成できるため、柔軟性が向上し、スケーラビリティが向上する場合があります。

ダウンストリーム・データベースからソース・データベースへのオプダウンストリーム・データベースからソース・データベースへのオプダウンストリーム・データベースからソース・データベースへのオプダウンストリーム・データベースからソース・データベースへのオプションのデータベース・リンクションのデータベース・リンクションのデータベース・リンクションのデータベース・リンクダウンストリーム取得プロセスを作成または変更する場合、オプションで、ダウンストリーム・データベースからソース・データベースへのデータベース・リンクを使用するように指定できます。このデータベース・リンクには、ソース・データベースのグローバル名と同じ

参照参照参照参照 : Streams クライアントのルール・セットの詳細、およびイベントがルール・セットを満たす場合の詳細は、第 6 章「Streams でのルールの使用方法」を参照してください。

注意注意注意注意 : 単一のソース・データベースから 2 つの異なる取得プロセスによって変更が取得され、適用プロセスでこれらの変更のいずれかを適用するキューが使用される場合、2 つの異なる取得プロセスで作成された LCRを同じキューにステージングできません。かわりに、各取得プロセスで取得された変更を適用するには、個別のキューおよび適用プロセスを使用する必要があります。



名前を付ける必要があります。このようなデータベース・リンクを使用すると、ダウンストリーム取得プロセスを簡単に作成および管理できます。ダウンストリーム取得プロセスでデータベース・リンクを使用するように指定するには、ダウンストリーム取得プロセスでCREATE_CAPTUREまたは ALTER_CAPTUREを実行する際に、use_database_linkパラメータを trueに設定します。

ダウンストリーム取得プロセスでソース・データベースへのデータベース・リンクを使用すると、取得プロセスでソース・データベースに接続し、次の管理アクションが自動的に実行されます。

� 特定の状況で、ソース・データベースで DBMS_CAPTURE_ADM.BUILDプロシージャが実行され、取得プロセスの作成時にソース・データベースのデータ・ディクショナリがREDO ログに抽出されます。

� ソース・データベース・オブジェクトがインスタンス化のために準備されます。

� 取得プロセスの作成時に先頭 SCN を指定していない場合、ダウンストリーム取得プロセスの先頭 SCN が取得されます。先頭 SCN は、取得プロセスを作成するために必要です。

ダウンストリーム取得プロセスでデータベース・リンクを使用しない場合、これらのアクションを手動で実行する必要があります。

ダウンストリーム取得の操作要件ダウンストリーム取得の操作要件ダウンストリーム取得の操作要件ダウンストリーム取得の操作要件ダウンストリーム取得を使用するための操作要件は、次のとおりです。

� ソース・データベースで Oracle Database 10g 以上が実行されており、ダウンストリーム取得データベースでソース・データベースと同じバージョン以上の Oracle が実行されている。

� ソース・サイトおよびダウンストリーム取得サイトのオペレーティング・システムが同じである。ただし、オペレーティング・システムのリリースが同じである必要はありません。また、ダウンストリーム・サイトでは、ソース・サイトと異なるディレクトリ構造を使用できます。

� ソース・サイトおよびダウンストリーム取得サイトのハードウェア・アーキテクチャが同じである。たとえば、ダウンストリーム取得構成でソース・データベースが 32 ビットの Sun システム上に構成されている場合、ダウンストリーム・データベースが 32ビットの Sun システム上に構成されている必要があります。CPU の数、メモリー・サイズ、記憶域の構成などの他のハードウェア要素は、ソース・サイトとダウンストリーム・サイトで同じである必要はありません。

参照参照参照参照 : ダウンストリーム取得プロセスでデータベース・リンクが使用される場合、取得プロセスの作成時に DBMS_CAPTURE_ADM.BUILDプロシージャが自動的に実行される場合の詳細は、9-8 ページの「データベース・リンクを使用するダウンストリーム取得プロセスの作成」を参照してください。


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

ダウンストリーム取得環境では、ソース・データベースは、単一インスタンスのデータベースまたは複数インスタンスの Real Application Clusters（RAC）データベースとして構成できます。ダウンストリーム・データベースは、ソース・データベースが単一インスタンスであるか、または複数インスタンスであるかに関係なく、単一インスタンスのデータベースまたは複数インスタンスの RAC データベースとして構成できます。

取得プロセスに関連する取得プロセスに関連する取得プロセスに関連する取得プロセスに関連する SCN 値値値値この項では、取得プロセスで重要となるシステム変更番号（SCN）値を説明します。1 つ以上の取得プロセスのシステム変更番号を表示するには、ALL_CAPTUREデータ・ディクショナリ・ビューを問い合せます。

取得済取得済取得済取得済 SCN および適用済および適用済および適用済および適用済 SCN取得済取得済取得済取得済 SCN は、取得プロセスによって REDO ログでスキャンされた新の変更に対応する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 999999999COLUMN 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 が先頭が先頭が先頭が先頭 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 の詳細は、2-29 ページの「取得プロセスの作成」を参照してください。



インスタンス化の準備以前の時間への開始インスタンス化の準備以前の時間への開始インスタンス化の準備以前の時間への開始インスタンス化の準備以前の時間への開始 SCN の設定の設定の設定の設定データベース・オブジェクトに対する変更を取得し、適用プロセスを使用してこれらの変更を適用する場合、データベース・オブジェクトがインスタンス化のために準備された後に発生した変更のみ適用できます。そのため、取得プロセスの開始 SCN を、データベース・オブジェクトがインスタンス化のために準備された時間に対応する SCN より小さい番号に設定すると、準備 SCN 以前に行われたこのデータベース・オブジェクトに対する変更が取得された場合に、適用プロセスでこれらの変更を適用できません。

この制限は、取得プロセスの作成時に問題になる場合があります。取得プロセスの作成時より前にインスタンス化のために準備されたデータベース・オブジェクトが存在しない場合、取得プロセスの作成時より前に行われたオブジェクトに対する変更が取得された場合、適用プロセスでこれらの変更を適用できません。

新しい取得プロセスの作成前にデータベース・オブジェクトがインスタンス化のために準備されている場合があります。たとえば、1 つ以上の既存の取得プロセスで取得されている変更を含むソース・データベースの新しい取得プロセスを作成する場合、一部またはすべてのデータベース・オブジェクトが、新しい取得プロセスの作成前にインスタンス化のために準備されている場合があります。新しい取得プロセスで、この新しい取得プロセスの作成時より前に特定のデータベース・オブジェクトに対して行われた変更を取得する場合、適用プロセスでこれらの取得された変更を適用するには、次の条件を満たしている必要があります。

� 新しい取得プロセスの作成時より前に、データベース・オブジェクトがインスタンス化のために準備されている。

� 新しい取得プロセスの開始 SCN が、データベース・オブジェクトがインスタンス化のために準備された時間より前の時間に対応している。

� 指定された開始 SCN に対応する時間の REDO ログが使用可能である。開始 SCN より前に追加の REDO ログが必要な場合もある。


� データベース・オブジェクトをインスタンス化のために準備する方法の詳細は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。



Streams の取得プロセスと RESTRICTED SESSION

Streams の取得プロセスとの取得プロセスとの取得プロセスとの取得プロセスと RESTRICTED SESSIONシステム起動時に STARTUP RESTRICT文を発行して制限付きセッションを有効化した場合、データベースの停止時に取得プロセスが実行中であった場合も、取得プロセスは起動しません。制限付きセッションを無効化すると、データベースの停止時に実行中であった各取得プロセスが起動されます。

SQL 文 ALTER SYSTEMおよび ENABLE RESTRICTED SESSION句によって実行中のデータベースで制限付きセッションが有効化された場合、実行中の取得プロセスには影響しません。これらの取得プロセスは引き続き実行され、変更の取得が行われます。制限付きセッションで停止済の取得プロセスが起動された場合、この取得プロセスは制限付きセッションが無効化されるまで起動されません。

Streams の取得プロセスとの取得プロセスとの取得プロセスとの取得プロセスと Oracle Real Application ClustersStreams の取得プロセスは、Real Application Clusters（RAC）環境での変更を取得するように構成できます。同一の環境で 1 つ以上の取得プロセスおよび RAC を使用する場合、取得プロセスによって取得される変更を含むすべてのアーカイブ・ログは、RAC 環境の全インスタンスで使用可能であることが必要です。RAC 環境では、取得プロセスですべてのインスタンスによる変更が読み取られます。

各取得プロセスは、開始プロシージャが別のインスタンスで実行されている場合でも、そのSYS.AnyDataキューに対して所有者インスタンスで開始されます。また、現在の所有者インスタンスが使用不可能になった場合、取得プロセスは別のインスタンスに対するキューに従います。キュー自体はプライマリ・インスタンスおよびセカンダリ・インスタンスの所有権のルールに従います。取得プロセスで使用されるキューを含むキュー表の所有者インスタンスが使用不可能になると、キューの所有権は自動的にクラスタ内の別のインスタンスに移ります。また、所有者インスタンスが使用不可能になったときに取得プロセスが有効にされると、その取得プロセスは新しい所有者インスタンスで自動的に再起動されます。所有者インスタンスが使用不可能になったときに取得プロセスが無効にされると、その取得プロセスは新しい所有者インスタンスで使用不可能のままになります。

DBA_QUEUE_TABLESデータ・ディクショナリ・ビューは、キュー表の所有者インスタンスに関する情報を示します。また、単一の取得プロセスによって使用されるパラレル実行サーバーは、RAC 環境の単一インスタンスで実行されます。


取得プロセスのアーキテクチャ

取得プロセスのアーキテクチャ取得プロセスのアーキテクチャ取得プロセスのアーキテクチャ取得プロセスのアーキテクチャ取得プロセスはオプションの Oracle バックグラウンド・プロセスであり、そのプロセス名は cnnnです。この場合、nnnは取得プロセス番号です。有効な取得プロセス名は、c001～ c999です。取得プロセスは、LogMiner のインフラストラクチャを使用して REDO ログから変更を取得します。LogMiner は、Streams によって自動的に構成されます。取得プロセスの作成、変更、起動、停止および削除と、取得プロセスで取得される変更を制御する取得プロセスのルールの定義を行うことができます。

変更は取得ユーザー取得ユーザー取得ユーザー取得ユーザーによって取得されます。取得ユーザーは、取得プロセスのルール・セットを満たすすべての変更を取得します。また、取得ユーザーは、これらのルール・セット内のルールで指定されたすべてのルールベースの変換を実行します。取得ユーザーは、取得プロセスで使用されるルール・セットの実行権限、ポジティブ・ルール・セットに含まれるルールに指定されたすべてのルールベースの変換ファンクションの実行権限、取得プロセス・キューへのイベントのエンキュー権限など、前述のアクションの実行に必要な権限を持っている必要があります。取得プロセスは 1 ユーザーのみに関連付けることができます。ただし、ユーザーは複数の取得プロセスに関連付けることができます。

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

� 取得プロセスのコンポーネント

� 取得プロセスの状態

� 単一データベース内の複数の取得プロセス

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

� 取得プロセスの作成

� 新しい先頭 SCN 値および削除された LogMiner ディクショナリ情報


� キューのプライマリ・インスタンスおよびセカンダリ・インスタンスの所有権の詳細は、3-13 ページの「SYS.AnyData キューと Oracle Real Application Clusters」を参照してください。


� DBA_QUEUE_TABLESデータ・ディクショナリ・ビューの詳細は、『Oracle Database リファレンス』を参照してください。

� インスタンス間で共有されるアーカイブ・ログを構成する方法の詳細は、『Oracle Real Application Clusters 管理』を参照してください。

参照参照参照参照 : 必要な権限については、8-2 ページの「Streams 管理者の構成」を参照してください。



� Streams データ・ディクショナリ

� ARCHIVELOG モードと取得プロセス

� 取得プロセスのパラメータ

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

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

取得プロセスのコンポーネント取得プロセスのコンポーネント取得プロセスのコンポーネント取得プロセスのコンポーネント取得プロセスのコンポーネントは、次のとおりです。

� REDO ログを読み取って複数の領域に分割するリーダー・サーバーリーダー・サーバーリーダー・サーバーリーダー・サーバー。

� リーダー・サーバーによって定義された領域をスキャンし、REDO ログ内で検出された変更の事前フィルタ処理をパラレル実行する 1 つ以上のプリペアラ・サーバープリペアラ・サーバープリペアラ・サーバープリペアラ・サーバー。事前フィルタ処理では、変更のスキーマ名やオブジェクト名など、変更に関する情報の一部が評価のためにルール・エンジンに送信され、評価の結果が受信されます。

� プリペアラ・サーバーからの REDO レコードをマージする 1 つのビルダー・サーバービルダー・サーバービルダー・サーバービルダー・サーバー。これらの REDO レコードは、部分評価の実行中に TRUE と評価されるか、または部分評価でこれらの REDO レコードについての結果が生成されません。ビルダー・サーバーは、これらの REDO レコードの SCN の順序を保持し、マージされた REDO ログを取得プロセスに渡します。

� 取得プロセス（cnnn）。これは、マージされた REDO レコードをビルダー・サーバーから受信すると、各変更に対して次のアクションを実行します。

� 変更を LCR 形式でフォーマットします。

� プリペアラ・サーバーによって実行された部分評価で、LCR の変更に対する結果が生成されない場合、LCR を完全評価のためにルール・エンジンに送信します。

� LCR の完全評価が実行された場合、その結果を受信します。

� LCR が取得プロセスのポジティブ・ルール・セットに含まれるルールを満たす場合は、取得プロセスに関連付けられたキューに LCR をエンキューします。LCR が取得プロセスのネガティブ・ルール・セットに含まれるルールを満たすか、または取得プロセスのポジティブ・ルール・セットに含まれるルールを満たさない場合は、LCR を廃棄します。

各リーダー・サーバー、プリペアラ・サーバーおよびビルダー・サーバーは、パラレル実行サーバーです。取得プロセス（cnnn）は、Oracle バックグラウンド・プロセスです。



取得プロセスの状態取得プロセスの状態取得プロセスの状態取得プロセスの状態取得プロセスの状態は、取得プロセスが現在行っていることを示します。取得プロセスの状態は、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: 取得プロセスのルール・セットに対して TRUE と評価される変更の REDO ログをスキャン中。

� WAITING FOR REDO: 新しい REDO ログ・ファイルが取得プロセス・セッションに追加されるまで待機中。取得プロセスは、セッションに追加したすべての REDO ログ・ファイルの処理を終了しています。ソース・データベースにアクティビティが存在しない場合に、この状態が発生する可能性があります。ダウンストリーム取得プロセスの場合、取得プロセスがセッションに新しいログ・ファイルが追加されるまで待機中である場合に、この状態が発生する可能性があります。

� EVALUATING RULE: 取得プロセスのルール・セットに対して変更を評価中。

� CREATING LCR: 変更を LCR 形式に変換中。

� ENQUEUING MESSAGE: 取得プロセスのルール・セットを満たす LCR を取得プロセス・キューにエンキュー中。

� PAUSED FOR FLOW CONTROL: メモリー不足、または伝播および適用プロセスでのメッセージの消費速度が取得プロセスでのメッセージの作成速度より遅いことが原因で、LCR をエンキューできない。この状態は、伝播または適用が遅延した場合に取得 LCR


� parallelismパラメータの詳細は、2-43 ページの「取得プロセスの並列性」を参照してください。


� パラレル実行サーバーの管理については、『Oracle Database 管理者ガイド』を参照してください。



がオーバーフローすることを減らすために、フロー制御が行われていることを示します。

� SHUTTING DOWN: 停止中。

単一データベース内の複数の取得プロセス単一データベース内の複数の取得プロセス単一データベース内の複数の取得プロセス単一データベース内の複数の取得プロセス単一データベース上で複数の取得プロセスを実行する場合、各インスタンスのシステム・グローバル領域（SGA）のサイズを増やすことを検討してください。SGA のサイズを増やすには、SGA_MAX_SIZE初期化パラメータを使用します。また、データベース上での取得プロセスの並列性が 1 増えるごとに、共有プールのサイズを 10MB ずつ増やす必要があります。たとえば、データベース上で 2 つの取得プロセスが実行されている場合に、1 つの取得プロセスに対して並列性パラメータが 4に設定されており、もう 1 つの取得プロセスに対しては 1に設定されている場合、Streams プールを 50MB（並列性は 4 ＋ 1 ＝ 5）増やします。

取得プロセスのチェックポイント取得プロセスのチェックポイント取得プロセスのチェックポイント取得プロセスのチェックポイント取得プロセスは、定期的に、チェックポイントチェックポイントチェックポイントチェックポイントの記録を試行します。チェックポイントでは、取得プロセスが、取得プロセスを実行しているデータベースのデータ・ディクショナリに現在の状態を永続的に記録します。

必須チェックポイント必須チェックポイント必須チェックポイント必須チェックポイント SCN は、取得プロセスが REDO 情報を要求する小チェックポイント SCN です。必須チェックポイント SCN を含む REDO ログ・ファイルおよびすべての後続の REDO ログ・ファイルは、取得プロセスで使用可能である必要があります。取得プロセスを停止および再起動すると、REDO ログのスキャンは、その必須チェックポイントSCN に対応する SCN から開始されます。必須チェックポイント SCN は、データベースが予期せず停止した場合のリカバリで重要です。また、取得プロセス用に先頭 SCN をリセットする場合は、取得プロセスの必須チェックポイント SCN 以下の値に設定する必要があり

参照参照参照参照 : 取得プロセスの状態を表示する問合せについては、14-7 ページの「各取得プロセスに関する一般情報の表示」を参照してください。


� 様々な取得プロセスからの LCR を別個に保存するために、各取得プロセスでは個別のキューを使用することをお薦めします。

� Streams プールのサイズが 0（ゼロ）である場合、Streams で使用可能な共有プールの割合は 10% 以下になります。STREAMS_POOL_SIZE初期化パラメータは、Streams プールのサイズを制御します。

� 各取得プロセスでは、1 つの LogMiner セッションが使用されます。

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



ます。取得プロセスの必須チェックポイント SCN を判別するには、DBA_CAPTUREデータ・ディクショナリ・ビューの REQUIRED_CHECKPOINT_SCN列を問い合せます。

また、取得プロセスによって記録された後のチェックポイントに対応する SCN 値は大大大大チェックポイントチェックポイントチェックポイントチェックポイント SCN です。ソース・データベースから変更を取得する取得プロセスを作成し、同じソース・データベースから変更を取得する他の既存の取得プロセスが存在する場合、新しい取得プロセスで新しい LogMiner データ・ディクショナリを作成する必要があるか、または既存の LogMiner データ・ディクショナリを共有する必要があるかを判別するうえで、既存の取得プロセスの大チェックポイント SCN が役立ちます。取得プロセスの大チェックポイント SCN を判別するには、DBA_CAPTUREデータ・ディクショナリ・ビューの MAX_CHECKPOINT_SCN列を問い合せます。

取得プロセスの作成取得プロセスの作成取得プロセスの作成取得プロセスの作成取得プロセスを作成するには、DBMS_STREAMS_ADMパッケージを使用する方法と、DBMS_CAPTURE_ADMパッケージを使用する方法があります。一部の構成オプションにはデフォルトが自動的に使用されるため、DBMS_STREAMS_ADMパッケージを使用して取得プロセスを作成する方が簡単です。また、DBMS_STREAMS_ADMパッケージを使用すると、取得プロセスのルール・セットが作成され、自動的にそのルール・セットにルールが追加される場合があります。inclusion_ruleパラメータが true（デフォルト）に設定されている場合、そのルール・セットはポジティブ・ルール・セットです。inclusion_ruleパラメータが falseに設定されている場合、そのルール・セットはネガティブ・ルール・セットです。

それに対して DBMS_CAPTURE_ADMパッケージを使用して取得プロセスを作成するのは、より柔軟性があり、1 つ以上のルール・セットとルールの作成は取得プロセスの作成前または作成後に行われます。DBMS_STREAMS_ADMパッケージまたは DBMS_RULE_ADMパッケージのプロシージャを使用すると、取得プロセスのルール・セットにルールを追加できます。

DBMS_STREAMS_ADMパッケージのプロシージャを使用して取得プロセスを作成し、取得プロセスのポジティブ・ルール・セットに 1 つ以上のルールを生成する場合、変更が取得されるオブジェクトは自動的にインスタンス化用に準備されます。ただし、その取得プロセスがダウンストリーム取得プロセスで、ダウンストリーム・データベースからソース・データベースへのデータベース・リンクが存在しない場合は除きます。

DBMS_CAPTURE_ADMパッケージの CREATE_CAPTUREプロシージャを使用して取得プロセスを作成する場合、取得プロセスの作成後、できるだけ早期に、変更を取得する予定のすべてのオブジェクトをインスタンス化のために準備する必要があります。オブジェクトをインスタンス化のために準備するには、DBMS_CAPTURE_ADMパッケージの次のいずれかのプロシージャを使用します。


� 2-30 ページの「取得プロセスの LogMiner データ・ディクショナリ」




� PREPARE_TABLE_INSTANTIATIONでは、1 つの表がインスタンス化のために準備されます。

� PREPARE_SCHEMA_INSTANTIATIONでは、スキーマ内のすべてのオブジェクトと、将来そのスキーマに追加されるすべてのオブジェクトが、インスタンス化のために準備されます。

� PREPARE_GLOBAL_INSTANTIATIONでは、データベース内の全オブジェクトと、将来そのデータベースに追加される全オブジェクトが、インスタンス化のために準備されます。

取得プロセスの取得プロセスの取得プロセスの取得プロセスの LogMiner データ・ディクショナリデータ・ディクショナリデータ・ディクショナリデータ・ディクショナリ取得プロセスには、ソース・データベースの 1 次データ・ディクショナリとは別のデータ・ディクショナリが必要です。この個別のデータ・ディクショナリは、LogMiner データ・データ・データ・データ・ディクショナリディクショナリディクショナリディクショナリと呼ばれます。特定のソース・データベースに対して複数の LogMiner データ・ディクショナリが存在する場合があります。ソース・データベースから変更を取得する取得プロセスが複数存在する場合は、複数の取得プロセスが LogMiner データ・ディクショナリを共有するか、または各取得プロセスが独自の LogMiner データ・ディクショナリを所


� ダウンストリーム・データベースで取得プロセスを作成するには、DBMS_CAPTURE_ADMパッケージを使用する必要があります。

� 取得プロセスを作成した後は、その取得プロセスのソース・データベースの DBIDまたはグローバル名を変更しないでください。ソース・データベースの DBIDまたはグローバル名のいずれかを変更した場合、その取得プロセスを削除して再作成する必要があります。


� 取得プロセスの作成に使用できる次のプロシージャの詳細は、第 9 章「取得プロセスの管理」および『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

DBMS_STREAMS_ADM.ADD_SUBSET_RULES

DBMS_STREAMS_ADM.ADD_TABLE_RULES

DBMS_STREAMS_ADM.ADD_SCHEMA_RULES

DBMS_STREAMS_ADM.ADD_GLOBAL_RULES

DBMS_CAPTURE_ADM.CREATE_CAPTURE

� 取得ルールおよびインスタンス化の準備の詳細およびソース・データベースの DBID またはグローバル名の変更の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。



有します。取得プロセスに必要な LogMiner データ・ディクショナリが存在しない場合、取得プロセスの初の起動時に、REDO ログの情報を使用して LogMiner データ・ディクショナリが移入されます。

DBMS_CAPTURE_ADM.BUILDプロシージャは、データ・ディクショナリ情報を REDO ログに抽出します。このプロシージャは、ソース・データベースで発生した変更を取得する任意の取得プロセスが起動される前に、ソース・データベース上で 1 回以上実行する必要があります。REDO ログに抽出されたデータ・ディクショナリ情報には、DBMS_CAPTURE_ADM.BUILDプロシージャの実行時の 1 次データ・ディクショナリとの一貫性があります。このプロシージャは、取得プロセスの作成で使用できる有効な先頭 SCN値も識別します。

REDO ログへのデータ・ディクショナリ情報の作成を 2 回以上実行できます。また、LogMiner データ・ディクショナリを作成するために取得プロセスで特定の作成を使用するかどうかを指定できます。BUILDプロシージャの実行時に REDO ログに抽出される情報の量は、データベース内のデータベース・オブジェクトの数に応じて異なります。通常、BUILDプロシージャでは大量の REDO 情報が生成されます。これらの REDO 情報は、取得プロセスでスキャンする必要があります。そのため、BUILDプロシージャは、必要な場合にのみ実行する必要があります。

1 次データ・ディクショナリ内の情報は REDO ログから取得される変更に適用できないため、取得プロセスには LogMiner データ・ディクショナリが必要です。このような変更は、取得プロセスによって取得される数分前、数時間前または数日前に発生した可能性があります。たとえば、次の使用例を考えます。

1. 取得プロセスは、表に対する変更を取得するように構成されています。

2. データベース管理者が取得プロセスを停止します。取得プロセスが停止されると、その時点で取得中だった変更の SCN が記録されます。

3. ユーザー・アプリケーションは、取得プロセスの停止中も引き続き表に対する変更を行います。

4. 取得プロセスが、停止から 3 時間後に再起動されます。

この場合、データ整合性を確保するために、取得プロセスは停止された時点から REDO ログ内の変更の取得を開始する必要があります。取得プロセスは、停止時に記録した SCN から変更の取得を開始します。

REDO ログには RAW データが含まれています。データベース・オブジェクト名および表の列名は含まれていません。かわりに、データベース・オブジェクトと列には、それぞれオブジェクト番号と内部列番号が使用されます。したがって、変更を取得する場合、取得プロセスはデータ・ディクショナリを参照して変更の詳細を判別する必要があります。

取得プロセスの初の起動時には LogMiner データ・ディクショナリが移入される場合があるため、変更の取得を開始するには時間がかかることがあります。所要時間は、データベース内のデータベース・オブジェクトの数に応じて異なります。取得プロセスによる作成されたデータ・ディクショナリの処理中に進捗を監視するには、V$STREAMS_CAPTURE動的パフォーマンス・ビューの STATE列を問い合せます。



取得プロセスに対する取得プロセスに対する取得プロセスに対する取得プロセスに対する LogMiner データ・ディクショナリの必要性を示す使用例データ・ディクショナリの必要性を示す使用例データ・ディクショナリの必要性を示す使用例データ・ディクショナリの必要性を示す使用例取得プロセスが表 t1に対する変更を取得するように構成されている場合を考えます。この表には列 aおよび bがあり、この表に対して 3 つの異なる時点で次の変更が行われるとします。

時刻時刻時刻時刻 1: 値 a=7および b=15を挿入

時刻時刻時刻時刻 2: 列 cを追加

時刻時刻時刻時刻 3: 列 bを削除

なんらかの理由で取得プロセスがこれ以前の時点から変更を取得している場合、1 次データ・ディクショナリと LogMiner データ・ディクショナリ内の関連バージョンには異なる情報が含まれていることになります。表 2-1 に、現在の時刻が変更取得時刻とは異なる場合の、LogMiner データ・ディクショナリ内の情報の使用方法を示します。

取得プロセスは、実際の時刻が 3 のときに、時刻 1 に行われた挿入による変更を取得すると想定します。取得プロセスが 1 次データ・ディクショナリを使用していた場合は、列 aに値7が挿入され、列 cに値 15が挿入されたと想定する可能性があります。これは、この 2 つが 1 次データ・ディクショナリ内の時刻 3 における表 t1の列であるためです。ただし、実際には、値 15が、列 cではなく、列 bに挿入されています。

取得プロセスは LogMiner データ・ディクショナリを使用するため、このエラーは回避されます。LogMiner データ・ディクショナリは取得プロセスと同期化され、表 t1に時刻 1 の時点で列 aおよび bがあることを引き続き記録します。そのため、取得された変更は値 15が列 bに挿入されたことを示します。




� 2-27 ページの「取得プロセスの状態」


表表表表 2-1 1 次データ・ディクショナリ内と次データ・ディクショナリ内と次データ・ディクショナリ内と次データ・ディクショナリ内と LogMiner データ・ディクショナリ内の表データ・ディクショナリ内の表データ・ディクショナリ内の表データ・ディクショナリ内の表 t1 に関する情報に関する情報に関する情報に関する情報

現在の時刻現在の時刻現在の時刻現在の時刻変更取得時刻変更取得時刻変更取得時刻変更取得時刻 1 次データ・ディクショナリ次データ・ディクショナリ次データ・ディクショナリ次データ・ディクショナリ LogMiner データ・ディクショナリデータ・ディクショナリデータ・ディクショナリデータ・ディクショナリ

1 1 表 t1には列 aおよび bが含まれて

います。

表 t1には、時刻 1 における列 aおよび bが含まれています。

2 1 表 t1には、列 a、bおよび cが含ま

れています。


3 1 表 t1には列 aおよび cが含まれて

います。




同じソース・データベースに対する複数の取得プロセス同じソース・データベースに対する複数の取得プロセス同じソース・データベースに対する複数の取得プロセス同じソース・データベースに対する複数の取得プロセス 1 つ以上の取得プロセスでソース・データベースに対する変更を取得しているときに、同じソース・データベースに対する変更を取得する新しい取得プロセスを作成する場合、新しい取得プロセスでは、新しいLogMiner データ・ディクショナリを作成するか、または既存の LogMiner データ・ディクショナリを他の 1 つ以上の取得プロセスと共有できます。新しい取得プロセスのために新しい LogMiner データ・ディクショナリが作成されるかどうかは、CREATE_CAPTUREを実行して取得プロセスを作成するときの first_scnパラメータの設定によって異なります。

� first_scnパラメータに NULLを指定すると、新しい取得プロセスは、同じソース・データベースから変更を取得する 1 つ以上の既存の取得プロセスと LogMiner データ・ディクショナリを共有しようとします。first_scnパラメータのデフォルト値は、NULLです。

� first_scnパラメータに NULL以外の値を指定すると、新しい取得プロセスは、この新しい取得プロセスの初の起動時に作成される新しい LogMiner データ・ディクショナリを使用します。

複数の LogMiner データ・ディクショナリが存在する場合に、取得プロセスの作成時にfirst_scnパラメータに NULLを指定すると、新しい取得プロセスは、1 つ以上のチェック・ポイントを取得済の既存のいずれかの取得プロセスの LogMiner データ・ディクショナリを自動的に共有しようとします。すべての既存の取得プロセスに対する大チェックポイント SCN を表示するには、DBA_CAPTUREデータ・ディクショナリ・ビューのMAX_CHECKPOINT_SCN列を問い合せます。

複数の LogMiner データ・ディクショナリが存在する場合、取得プロセスの作成時にfirst_scnパラメータに NULL以外の値を指定すると、新しい取得プロセスは、この取得プロセスの初の起動時に新しい LogMiner データ・ディクショナリを作成します。この場合、新しい取得プロセスを作成する前に、ソース・データベース上で DBMS_CAPTURE_ADMパッケージの BUILDプロシージャを実行する必要があります。BUILDプロシージャは、対応する有効な先頭 SCN 値を生成します。この値は、新しい取得プロセスの作成時に指定できます。BUILDプロシージャによって生成される先頭 SCN を検索するには、次の問合せを実行します。


� 取得プロセスを作成し、first_scnパラメータに NULL以外の値を指定する場合、この値は、DBMS_CAPTURE_ADM.BUILDプロシージャを実行することによって取得される REDO ログに作成されたデータ・ディクショナリに対応している必要があります。

� 取得プロセスの作成時に、first_scnパラメータを NULL、start_scnパラメータを NULL以外に設定した場合、start_scnパラメータをすべての既存の取得プロセスに対するすべての先頭 SCNより小さい値に設定すると、エラーが発生します。



COLUMN FIRST_CHANGE# HEADING 'First SCN' FORMAT 999999999COLUMN NAME HEADING 'Log File Name' FORMAT A50

SELECT DISTINCT FIRST_CHANGE#, NAME FROM V$ARCHIVED_LOG WHERE DICTIONARY_BEGIN = 'YES';

BUILDプロシージャを 2 回以上実行した場合、この問合せによって複数の行が戻される場合があります。

新しい取得プロセスが既存の LogMiner データ・ディクショナリを共有する必要があるか、または新しいデータ・ディクショナリを作成する必要があるかを判断する際に考慮する必要があるも重要な要素は、既存の取得プロセスの大チェックポイント SCN 値と新しい取得プロセスの開始 SCN の差です。新しい取得プロセスが LogMiner データ・ディクショナリを共有する場合、新しい取得プロセスは、その先頭 SCN より前の変更を取得できないにもかかわらず、共有する LogMiner データ・ディクショナリの大チェックポイント SCN以降の REDO ログをスキャンする必要があります。新しい取得プロセスの開始 SCN が、既存の取得プロセスの大チェックポイント SCN より大幅に大きい場合、新しい取得プロセスは、開始 SCN に到達する前に大量の REDO ログ情報をスキャンする必要があります。

取得プロセスの作成中に first_scnパラメータが NULL以外である場合、取得プロセスは新しい 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 情報がスキャンされることを回避できます。



図 2-3 に、これらのガイドラインを示します。

図図図図 2-3 LogMiner データ・ディクショナリを共有するかどうかの判断データ・ディクショナリを共有するかどうかの判断データ・ディクショナリを共有するかどうかの判断データ・ディクショナリを共有するかどうかの判断


� DBMS_STREAMS_ADMパッケージのいずれかのプロシージャを使用して取得プロセスを作成することは、CREATE_CAPTUREプロシージャで first_scnおよび start_scnパラメータに NULLを指定する場合と同じです。

� 新しい取得プロセスがデータベース・オブジェクトに対する変更を取得する場合、これらのデータベース・オブジェクトをインスタンス化のために準備する必要があります。新しい取得プロセスが 1 つ以上の取得プロセスと LogMiner データ・ディクショナリを共有し、これらの取得プロセスでデータベース・オブジェクトがすでにインスタンス化のために準備されている場合でも、この要件は当てはまります。



取得プロセスの作成時の先頭取得プロセスの作成時の先頭取得プロセスの作成時の先頭取得プロセスの作成時の先頭 SCN および開始および開始および開始および開始 SCN の指定の指定の指定の指定DBMS_CAPTURE_ADMパッケージの CREATE_CAPTUREプロシージャを使用して取得プロセスを作成する場合、取得プロセスに先頭 SCN および開始 SCN を指定できます。先頭 SCNは、取得プロセスで変更を取得可能な、REDO ログの小 SCN です。これは、作成されたデータ・ディクショナリまたは V$ARCHIVED_LOG動的パフォーマンス・ビューに対する問合せから取得する必要があります。開始 SCN は、取得プロセスが変更の取得を開始するSCN です。開始 SCN は、先頭 SCN 以上である必要があります。

取得プロセスは、開始 SCN が先頭 SCN またはチェックポイント SCN より大きい場合でも、先頭 SCN または既存の取得プロセスのチェックポイント以降の REDO 情報をスキャンします。この場合、取得プロセスは、開始 SCN より前の REDO 情報の変更を取得しません。取得プロセスの作成時、先頭 SCN と開始 SCN の差をできるかぎり小さくして、取得プロセスでスキャンされる REDO の量を小限に抑えることをお薦めします。

取得プロセスの動作は、これらの SCN の設定値、および取得プロセスがローカルであるか、またはダウンストリームであるかによって異なる場合があります。

次の項では、SCN の設定値に対する取得プロセスの動作について説明します。

� ローカル取得プロセスまたはダウンストリーム取得プロセスの先頭 SCN が NULL 以外で開始 SCN が NULL である場合

� ローカル取得プロセスまたはダウンストリーム取得プロセスの先頭 SCN と開始 SCN の両方が NULL 以外である場合

� ローカル取得プロセスの先頭 SCN が NULL で開始 SCN が NULL 以外である場合

� ダウンストリーム取得プロセスの先頭 SCNがNULL で開始 SCNがNULL 以外である場合

� 先頭 SCN と開始 SCN の両方が NULL である場合



� 2-28 ページの「取得プロセスのチェックポイント」

注意注意注意注意 : DBMS_STREAMS_ADMパッケージを使用して取得プロセスを作成する場合、取得プロセスの作成時に、先頭 SCN と開始 SCN の両方がNULLに設定されます。



ローカル取得プロセスまたはダウンストリーム取得プロセスの先頭ローカル取得プロセスまたはダウンストリーム取得プロセスの先頭ローカル取得プロセスまたはダウンストリーム取得プロセスの先頭ローカル取得プロセスまたはダウンストリーム取得プロセスの先頭 SCN がががが NULL 以外で開始以外で開始以外で開始以外で開始SCN がががが NULL である場合である場合である場合である場合新しい取得プロセスは、first_scnパラメータに指定した値から開始される新しい LogMiner セッションとともに、ローカル・データベースで作成されます。開始 SCN は指定した先頭 SCN 値に自動的に設定され、新しい取得プロセスは、このSCN より前に行われた変更を取得しません。

DBMS_CAPTURE_ADMパッケージの BUILDプロシージャは、自動的に実行されません。このプロシージャがソース・データベース上で 1 回以上コールされており、指定した先頭 SCNが、現在でも REDO ログで使用可能な以前の作成の SCN 値に対応している必要があります。新しい取得プロセスが初めて起動されるときに、REDO ログのデータ・ディクショナリ情報を使用して新しい LogMiner データ・ディクショナリが作成されます。DBMS_CAPTURE_ADMパッケージの BUILDプロシージャがソース・データベース上で 1 回も実行されていない場合、取得プロセスの起動時にエラーが発生します。

これらの SCN 設定で作成したローカル取得プロセスおよびダウンストリーム取得プロセスでは、取得プロセスの動作は同じになります。ただし、ローカル取得プロセスはソース・データベースで作成され、ダウンストリーム取得プロセスはダウンストリーム・データベースで作成されます。

ローカル取得プロセスまたはダウンストリーム取得プロセスの先頭ローカル取得プロセスまたはダウンストリーム取得プロセスの先頭ローカル取得プロセスまたはダウンストリーム取得プロセスの先頭ローカル取得プロセスまたはダウンストリーム取得プロセスの先頭 SCN と開始と開始と開始と開始 SCN の両方の両方の両方の両方がががが NULL 以外である場合以外である場合以外である場合以外である場合 start_scnパラメータに指定した値が first_scnパラメータに指定した値以上である場合、指定した先頭 SCN から開始される新しい LogMiner セッションとともに、新しい取得プロセスがローカル・データベース上で作成されます。この場合、新しい取得プロセスは、指定した開始 SCN より前に行われた変更を取得しません。start_scnパラメータに指定した値が first_scnパラメータに指定した値より小さい場合、エラーが発生します。

DBMS_CAPTURE_ADMパッケージの BUILDプロシージャは、自動的に実行されません。このプロシージャがソース・データベース上で 1 回以上コールされており、指定したfirst_scnが、現在でも REDO ログで使用可能な以前の作成の SCN 値に対応している必要があります。新しい取得プロセスが初めて起動されるときに、REDO ログのデータ・ディクショナリ情報を使用して新しい LogMiner データ・ディクショナリが作成されます。DBMS_CAPTURE_ADMパッケージの BUILDプロシージャがソース・データベース上で 1 回も実行されていない場合、エラーが発生します。

これらの SCN 設定で作成したローカル取得プロセスおよびダウンストリーム取得プロセスでは、取得プロセスの動作は同じになります。ただし、ローカル取得プロセスはソース・データベースで作成され、ダウンストリーム取得プロセスはダウンストリーム・データベースで作成されます。



ローカル取得プロセスの先頭ローカル取得プロセスの先頭ローカル取得プロセスの先頭ローカル取得プロセスの先頭 SCN がががが NULL で開始で開始で開始で開始 SCN がががが NULL 以外である場合以外である場合以外である場合以外である場合次のいずれかの条件が満たされている場合、新しい取得プロセスは新しい LogMiner データ・ディクショナリを作成します。

� ローカルのソース・データベースに既存の取得プロセスが存在せず、start_scnパラメータに指定した値がデータベースの現行の SCN 以上である。

� 既存の取得プロセスが存在するが、いずれの取得プロセスもチェックポイントを未取得で、start_scnパラメータに指定した値がデータベースの現行の SCN 以上である。

これらのいずれかの場合、取得プロセスの作成時に DBMS_CAPTURE_ADMパッケージのBUILDプロシージャが実行されます。新しい取得プロセスは、この取得プロセスを初めて起動する際に、REDO ログに作成されたソース・データ・ディクショナリを使用してLogMiner データ・ディクショナリを作成します。先頭 SCN は、作成されたデータ・ディクショナリの SCN に対応しています。

ただし、ローカルのソース・データベースに、チェックポイントを取得済の 1 つ以上の既存のローカルの取得プロセスが存在する場合、新しい取得プロセスは、既存の LogMiner データ・ディクショナリを 1 つ以上の既存の取得プロセスと共有します。この場合、指定した開始 SCN 以下の先頭 SCN を持つ取得プロセスが、1 回以上正常に起動されている必要があります。

ローカルのソース・データベースに既存の取得プロセスが存在せず（チェックポイントを取得済の既存の取得プロセスが存在しない）、指定した開始 SCN がデータベースの現行のSCN より小さい場合、エラーが発生します。

ダウンストリーム取得プロセスの先頭ダウンストリーム取得プロセスの先頭ダウンストリーム取得プロセスの先頭ダウンストリーム取得プロセスの先頭 SCN がががが NULL で開始で開始で開始で開始 SCN がががが NULL 以外である場合以外である場合以外である場合以外である場合取得プロセスの作成時に use_database_linkパラメータを trueに設定すると、データベース・リンクを使用して、ソース・データベースの現行の SCN が取得されます。この場合、次のいずれかの条件が満たされると、新しい取得プロセスは新しい LogMiner データ・ディクショナリを作成します。

� ソース・データベースに対する変更を取得する既存の取得プロセスがダウンストリーム・データベースに存在せず、start_scnパラメータに指定した値がソース・データベースの現行の SCN 以上である。

� ソース・データベースに対する変更を取得する既存の取得プロセスがダウンストリーム・データベースに存在するが、いずれの取得プロセスもチェックポイントを未取得で、start_scnパラメータに指定した値がソース・データベースの現行の SCN 以上である。

これらのいずれかの場合、取得プロセスの作成時に DBMS_CAPTURE_ADMパッケージのBUILDプロシージャが実行されます。新しい取得プロセスは、この取得プロセスを初めて起動する際に、ダウンストリーム・データベースにコピーされた REDO ログ・ファイルに作成されたソース・データ・ディクショナリを使用して、LogMiner データ・ディクショナリを作成します。この場合、新しい取得プロセスの先頭 SCN は、作成されたデータ・ディクショナリの SCN に対応します。



ただし、チェックポイントを取得済で、ソース・データベースに対する変更を取得する、1つ以上の既存の取得プロセスがダウンストリーム・データベースに存在する場合、新しい取得プロセスは、use_database_linkパラメータの設定にかかわらず、既存の LogMinerデータ・ディクショナリを 1 つ以上の既存の取得プロセスと共有します。この場合、指定した開始 SCN 以下の先頭 SCN を持つこれらの既存の取得プロセスのいずれかが、1 回以上正常に起動されている必要があります。

取得プロセスの作成時に use_database_linkパラメータが trueに設定されており、ソース・データベースに対する変更を取得する既存の取得プロセスがダウンストリーム・データベースに存在せず（またはチェックポイントを取得済の既存のプロセスが存在しない）、指定した start_scnパラメータ値がソース・データベースの現行の SCN より小さい場合、エラーが発生します。

取得プロセスの作成時に use_database_linkパラメータが falseに設定されており、ソース・データベースに対する変更を取得する既存の取得プロセスがダウンストリーム・データベースに存在しない（またはチェックポイントを取得済の既存の取得プロセスが存在しない）場合、エラーが発生します。

先頭先頭先頭先頭 SCN と開始と開始と開始と開始 SCN の両方がの両方がの両方がの両方が NULL である場合である場合である場合である場合動作は、first_scnパラメータを NULLに設定し、start_scnパラメータをソース・データベースの現行の SCN に設定する場合と同じになります。

新しい先頭新しい先頭新しい先頭新しい先頭 SCN 値および削除された値および削除された値および削除された値および削除された LogMiner ディクショナリ情報ディクショナリ情報ディクショナリ情報ディクショナリ情報既存の取得プロセスに対する先頭 SCN 値をリセットすると、Oracle によって、新しい先頭SCN の設定前に LogMiner データ・ディクショナリ情報が削除されます。取得プロセスの開始 SCN が、削除された情報に対応している場合、Oracle によって、開始 SCN が先頭 SCNと同じ値に自動的にリセットされます。ただし、開始 SCN が新しい先頭 SCN の設定より大きい場合、開始 SCN は変更されません。


� 2-38 ページの「ローカル取得プロセスの先頭 SCN が NULL で開始SCN が NULL 以外である場合」

� 2-38 ページの「ダウンストリーム取得プロセスの先頭 SCN が NULLで開始 SCN が NULL 以外である場合」



図 2-4 に、Oracle によって新しい先頭 SCN の設定前に LogMiner データ・ディクショナリ情報が自動的に削除される仕組み、および開始 SCN が新しい先頭 SCN の設定値より大きい場合に開始 SCN が変更されない仕組みを示します。

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

この例に示すとおり、先頭 SCN が取得プロセスの開始 SCN 値より大きい値に再度リセットされると、開始 SCN は LogMiner データ・ディクショナリの既存の情報に対応しなくなります。図 2-5 に、開始 SCN が新しい先頭 SCN の設定より小さい場合に、Oracle によって開始 SCN が自動的にリセットされる仕組みを示します。

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

このように、取得プロセスの先頭 SCN および開始は継続的に大きくなります。先頭 SCN が大きくなることによって、DBMS_CAPTURE_ADM.BUILDプロシージャによって設定されたSCN に対応しなくなる場合があります。



Streams データ・ディクショナリデータ・ディクショナリデータ・ディクショナリデータ・ディクショナリ伝播および適用プロセスは、Streams データ・ディクショナリデータ・ディクショナリデータ・ディクショナリデータ・ディクショナリを使用して、特定のソース・データベースのデータベース・オブジェクトを追跡します。Streams データ・ディクショナリは、ソース・データベースで 1 つ以上のデータベース・オブジェクトがインスタンス化のために準備されるたびに移入されます。データベース・オブジェクトがインスタンス化のために準備されると、REDO ログに記録されます。取得プロセスが REDO ログをスキャンする場合、この情報を使用して、ソース・データベースのローカルの Streams データ・ディクショナリを移入します。ローカル取得の場合、この Streams データ・ディクショナリはソース・データベースに存在します。ダウンストリーム取得の場合、この Streams データ・ディクショナリはダウンストリーム・データベースに存在します。

データベース・オブジェクトをインスタンス化のために準備すると、データベース・オブジェクトに対する変更を伝播する伝播プロセスおよびデータベース・オブジェクトに対する変更を適用する適用プロセスでデータベース・オブジェクトに関する情報が必要であることが Streams に通知されます。これらの変更を伝播または適用する任意のデータベースには、変更が発生したソース・データベースの Streams データ・ディクショナリが必要です。

オブジェクトをインスタンス化のために準備した後、取得プロセスによってオブジェクトに対する DDL 文が処理される際に、ローカルの Streams データ・ディクショナリが更新されます。また、この DDL 文に関する情報が含まれる内部メッセージが取得され、取得プロセスのキューに置かれます。その後、伝播は、これらの内部メッセージをデータベースの宛先キューに伝播します。

Streams データ・ディクショナリは、マルチバージョンです。データベースに複数の伝播および適用プロセスが含まれる場合、これらのすべての伝播および適用プロセスが、特定のソース・データベースに対する同じ Streams データ・ディクショナリを使用します。データベースには、特定のソース・データベースに対する 1 つのみの Streams データ・ディクショナリを含めることができます。ただし、複数のソース・データベースからの変更を伝播または適用する場合は、複数の Streams データ・ディクショナリを含めることができます。



� 9-33 ページの「既存の取得プロセスの開始 SCN の設定」

� 取得プロセスを変更する方法については、『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』のDBMS_CAPTURE_ADM.ALTER_CAPTUREプロシージャに関する説明を参照してください。



ARCHIVELOG モードと取得プロセスモードと取得プロセスモードと取得プロセスモードと取得プロセスローカルの取得プロセスは、可能な場合はオンライン REDO ログを読み取り、それ以外の場合はアーカイブ REDO ログ・ファイルを読み取ります。ダウンストリーム取得プロセスは、常にソース・データベースからアーカイブ REDO ログを読み取ります。このため、変更を取得するように取得プロセスを構成している場合は、ソース・データベースをARCHIVELOGモードで実行する必要があります。アーカイブ REDO ログ・ファイルは、それを必要とする取得プロセスがないことが確実になるまで、使用可能にしておく必要があります。

DBA_CAPTUREデータ・ディクショナリ・ビューの REQUIRED_CHECKPOINT_SCN列を問い合せて、取得プロセスの必須チェックポイント SCN を判別することができます。取得プロセスの再起動時、必須チェックポイント SCN 以降の REDO ログがスキャンされます。そのため、必須チェックポイント SCN を含む REDO ログ・ファイルおよびすべての後続のREDO ログ・ファイルは、取得プロセスで使用可能である必要があります。

取得プロセスの先頭 SCN は大きい値にリセットできますが、小さい値にリセットすることはできません。したがって、取得プロセスでは先頭 SCN 以前の情報を含む REDO ログは不要になります。取得プロセスで不要なアーカイブ REDO ログ・ファイルを判別するには、DBA_LOGMNR_PURGED_LOGデータ・ディクショナリ・ビューを問い合せます。

ローカルの取得プロセスに遅れが生じると、オンライン REDO ログの読取りからアーカイブ REDO ログの読取りへとシームレスに推移し、ローカルの取得プロセスが追いつくと、アーカイブ REDO ログの読取りからオンライン REDO ログの読取りへとシームレスに推移します。


� インスタンス化の詳細は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。

� 3-20 ページの「伝播用の Streams データ・ディクショナリ」

� 4-16 ページの「適用プロセス用の Streams データ・ディクショナリ」


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

� 14-11 ページの「取得プロセスでは不要な REDO ログ・ファイルの表示」



取得プロセスのパラメータ取得プロセスのパラメータ取得プロセスのパラメータ取得プロセスのパラメータ作成後の取得プロセスは無効化されているため、初めて起動する前に環境に合わせて取得プロセス・パラメータを設定できます。取得プロセス・パラメータでは、取得プロセスの動作を制御します。たとえば、time_limit取得プロセス・パラメータを使用すると、取得プロセスが自動的に停止するまでの実行時間を指定できます。

取得プロセスの並列性取得プロセスの並列性取得プロセスの並列性取得プロセスの並列性parallelism取得プロセス・パラメータでは、取得プロセスで使用するプリペアラ・サーバーの数を制御します。プリペアラ・サーバーは、REDO ログ内で検出された変更を同時にLCR 形式にフォーマットします。各リーダー・サーバー、プリペアラ・サーバーおよびビルダー・サーバーはパラレル実行サーバーであり、プリペアラ・サーバーの数は、parallelism取得プロセス・パラメータに指定した数と同じになります。そのため、parallelismを 5に設定すると、取得プロセスは合計 7 つのパラレル実行サーバーを使用します。合計 7 つのパラレル実行サーバーが使用可能な場合、リーダー・サーバーが 1 つ、プリペアラ・サーバーが 5 つおよびビルダー・サーバーが 1 つになります。


� 9-30 ページの「取得プロセスのパラメータの設定」

� この項では、使用可能な取得プロセス・パラメータの一部のみを説明しています。すべての取得プロセス・パラメータの詳細は、『PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』のDBMS_CAPTURE_ADM.SET_PARAMETERプロシージャに関する説明を参照してください。


� parallelismパラメータをリセットすると、取得プロセスが自動的に停止され、再起動されます。

� parallelismパラメータを使用可能なパラレル実行サーバー数より大きい数に設定すると、取得プロセスが無効化される場合があります。parallelism取得プロセス・パラメータの設定時には、PROCESSESおよび PARALLEL_MAX_SERVERS初期化パラメータが適切に設定されているかどうかを確認してください。

参照参照参照参照 : プリペアラ・サーバーの詳細は、2-26 ページの「取得プロセスのコンポーネント」を参照してください。



取得プロセスの自動再起動取得プロセスの自動再起動取得プロセスの自動再起動取得プロセスの自動再起動取得プロセスは、特定の上限に達した時点で自動的に停止するように構成できます。time_limit取得プロセス・パラメータで取得プロセスの実行時間を指定し、message_limit取得プロセス・パラメータで取得プロセスが取得できるイベントの数を指定します。取得プロセスは、これらのいずれかの上限に達した時点で自動的に停止します。

disable_on_limitパラメータでは、取得プロセスが上限に達した時点で無効化されるか、再起動するかを制御します。disable_on_limitパラメータを yに設定すると、取得プロセスは上限に達した時点で無効化され、明示的に指定するまで再起動されません。ただし、disable_on_limitパラメータを nに設定すると、取得プロセスは上限に達した時点で自動的に停止し、再起動します。

取得プロセスは、再起動されると後に停止した時点から変更の取得を開始します。再起動された取得プロセスは新規のセッション識別子を取得し、取得プロセスに関連付けられているパラレル実行サーバーも新規のセッション識別子を取得します。ただし、取得プロセス番号（cnnn）は変わりません。

取得プロセス・ルールの評価取得プロセス・ルールの評価取得プロセス・ルールの評価取得プロセス・ルールの評価取得プロセスは、ポジティブ・ルール・セットおよびネガティブ・ルール・セットに対してREDO ログ内で検出した変更を評価します。取得プロセスは、まずネガティブ・ルール・セットに対して変更を評価します。ネガティブ・ルール・セットの 1 つ以上のルールが変更について TRUEと評価されると、この変更は廃棄されます。一方、変更について TRUEと評価されるルールがネガティブ・ルール・セットに含まれない場合、この変更はネガティブ・ルール・セットを満たしています。変更が取得プロセスのネガティブ・ルール・セットを満たす場合、取得プロセスは、ポジティブ・ルール・セットに対して変更を評価します。ポジティブ・ルール・セットの 1 つ以上のルールが変更について TRUEと評価される場合、この変更はポジティブ・ルール・セットを満たしています。一方、変更について TRUEと評価されるルールがポジティブ・ルール・セットに含まれない場合、この変更は廃棄されます。取得プロセスに 1 つのみのルール・セットが含まれる場合、この 1 つのルール・セットのみに対して変更が評価されます。

実行中の取得プロセスは、次の一連のアクションを完了して変更を取得します。

1. REDO ログ内で変更を検索します。

2. REDO ログ内で変更の事前フィルタ処理を実行します。この手順で、取得プロセスはオブジェクト・レベルとスキーマ・レベルでルール・セット内のルールを評価し、REDOログ内で見つかった変更を 2 つのカテゴリに分類します。カテゴリの一方は、LCR への変換を必要とする変更で、他方は LCR に変換しない変更です。

事前フィルタ処理は、不完全な情報を使用して実行される安全な適化です。この手順では、次のように、それ以後に処理対象となる関連する変更が識別されます。

� 変更が取得プロセスのルール・セットを満たす場合、取得プロセスは変更を LCR に変換します。



� 変更が取得プロセスのルール・セットを満たさない場合は、取得プロセスが変更をLCR に変換しません。

� MAYBE評価の場合、ルール評価は次のとおり行われます。

– 取得プロセスのポジティブ・ルール・セットおよびネガティブ・ルール・セットの両方に対して変更が MAYBEと評価される場合、この変更が両方のルール・セットを確実に満たすかどうかを判別するために十分な情報が取得プロセスに含まれていない可能性があります。この場合、変更が LCR に変換され、追加の評価が行われます。

– 取得プロセスのネガティブ・ルール・セットに対して変更が FALSEと評価され、ポジティブ・ルール・セットに対して MAYBEと評価される場合、この変更が両方のルール・セットを確実に満たすかどうかを判別するために十分な情報が取得プロセスに含まれていない可能性があります。この場合、変更が LCRに変換され、追加の評価が行われます。

– 取得プロセスのネガティブ・ルール・セットに対して変更が MAYBEと評価され、ポジティブ・ルール・セットに対して TRUEと評価される場合、この変更が両方のルール・セットを確実に満たすかどうかを判別するために十分な情報が取得プロセスに含まれていない可能性があります。この場合、変更が LCRに変換され、追加の評価が行われます。

– 取得プロセスのネガティブ・ルール・セットに対して変更が 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 を廃棄します。


� 2-26 ページの「取得プロセスのコンポーネント」




図 2-6 に、取得プロセス・ルールの評価をフロー・チャート形式で示します。

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



データベースの再起動時における取得プロセスの永続的状態データベースの再起動時における取得プロセスの永続的状態データベースの再起動時における取得プロセスの永続的状態データベースの再起動時における取得プロセスの永続的状態取得プロセスを実行しているデータベースが停止され、再起動されても、取得プロセスは永続的状態を保ちます。たとえば、データベースの停止時に取得プロセスを有効にすると、その取得プロセスはデータベースの再起動時に自動的に開始されます。同様に、データベースの停止時に取得プロセスを無効化または異常終了させると、その取得プロセスはデータベースが再起動されても開始されず、無効または異常終了の状態のままとなります。


Streams のステージングと

3
Streams のステージングと伝播のステージングと伝播のステージングと伝播のステージングと伝播
この章では、キューにあるイベントのステージングと、キュー間でのイベントの伝播に関連する概念について説明します。


� イベントのステージングと伝播の概要

� 取得イベントとユーザー・エンキュー・イベント

� キュー間でのイベントの伝播

� メッセージ・クライアント

� SYS.AnyData 型のキューとユーザー・メッセージ

� SYS.AnyData キューと Oracle Real Application Clusters

� Streams のステージングと伝播のアーキテクチャ

参照参照参照参照 : 第 10 章「ステージングと伝播の管理」

伝播 3-1


イベントのステージングと伝播の概要イベントのステージングと伝播の概要イベントのステージングと伝播の概要イベントのステージングと伝播の概要Streams では、SYS.AnyData型のキューを使用してイベントがステージングされます。Streams では、SYS.AnyDataイベントにカプセル化でき、SYS.AnyDataキューでステージングできるイベントには、論理変更レコード（LCR）とユーザー・メッセージの 2 種類があります。LCR はデータベース・オブジェクトに対する変更情報を含むオブジェクトで、ユーザー・メッセージはユーザーまたはアプリケーションが作成するユーザー定義型のメッセージです。どちらのタイプのイベントも、単一データベース内またはデータベース間で情報を共有するために使用できます。

ステージングされたイベントは、コンシュームまたは伝播、あるいはその両方が可能です。ステージングされたイベントは、適用プロセス、メッセージ・クライアントまたはユーザー・アプリケーションでコンシュームできます。実行中の適用プロセスは、イベントを暗黙的にデキューしますが、メッセージ・クライアントおよびユーザー・アプリケーションは、イベントを明示的にデキューします。イベントを 1 つ以上の他のキューに伝播するように Streams を構成している場合、またはユーザー・エンキュー・メッセージの保存が指定されている場合は、イベントをコンシューム後もキューに残すことができます。イベントが伝播されるキューは、同一のデータベースにあっても、イベントが伝播されるデータベースとは別のデータベースにあってもかまいません。どちらの場合も、イベントの伝播元となるキューはソース・キューソース・キューソース・キューソース・キュー、イベントを受信するキューは宛先キュー宛先キュー宛先キュー宛先キューと呼ばれます。ソース・キューと宛先キューの間には、1 対多、多対 1 または多対多の関連が可能です。図 3-1 に、ソース・キューから宛先キューへの伝播を示します。

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

伝播の作成、変更および削除と、伝播するイベントを制御する伝播ルールの定義ができます。ソース・キューを所有するユーザーが、イベントを伝播するユーザーです。このユーザーは、イベントの伝播に必要な権限を持っている必要があります。

これには、次の権限が含まれます。

� 伝播で使用するルール・セットの実行権限

� ルール・セットで使用するすべてのルールベース変換ファンクションの実行権限


取得イベントとユーザー・エンキュー・イベント

� 宛先キューが同じデータベースにある場合は、宛先キューのエンキュー権限

伝播によってイベントがリモート・データベース内の宛先キューに伝播される場合、ソース・キューの所有者は伝播のデータベース・リンクを使用できる必要があり、リモート・データベースでデータベース・リンクの接続先となるユーザーは、宛先キューに対するエンキュー権限を持っている必要があります。

取得イベントとユーザー・エンキュー・イベント取得イベントとユーザー・エンキュー・イベント取得イベントとユーザー・エンキュー・イベント取得イベントとユーザー・エンキュー・イベントイベントをエンキューするには、次の 2 つの方法があります。

� 取得プロセスは、取得した変更を LCR を含むイベントの形式でエンキューします。初に取得プロセスによって取得されエンキューされた LCR を含んでいるイベントは、取取取取得イベント得イベント得イベント得イベントと呼ばれます。

� ユーザー・アプリケーションは、SYS.AnyData型のイベントにカプセル化されたユーザー・メッセージをエンキューします。これらのユーザー・メッセージには、LCR や他のタイプのメッセージを含めることができます。ユーザーまたはアプリケーションによって明示的にエンキューされたユーザー・メッセージは、ユーザー・エンキュー・イユーザー・エンキュー・イユーザー・エンキュー・イユーザー・エンキュー・イベントベントベントベントと呼ばれます。適用プロセスからコールされたユーザー・プロシージャによってエンキューされたイベントも、ユーザー・エンキュー・イベントです。

そのため、各取得イベントには LCR が含まれていますが、ユーザー・エンキュー・イベントには LCR が含まれていない場合もあります。取得イベントまたはユーザー・エンキュー・イベントを伝播すると、宛先キューにイベントがエンキューされます。

イベントをデキューするには、次の 2 つの方法があります。

� 適用プロセスは、取得イベントまたはユーザー・エンキュー・イベントをデキューします。イベントに LCR が含まれている場合、適用プロセスはそれを直接適用するか、ユーザー指定のプロシージャをコールして処理させることができます。イベントに LCRが含まれていない場合、適用プロセスではメッセージ・ハンドラと呼ばれるユーザー指


� Streams の伝播では、接続修飾子は使用できません。

� メッセージの保存は、取得プロセスによって取得された LCR には適用されません。


� 2-2 ページの「論理変更レコード（LCR）」

� ユーザー・エンキュー・メッセージの保存の詳細は、『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドおよびリファレンス』を参照してください。

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

キュー間でのイベントの伝播

定のプロシージャを起動してイベントを処理できます。また、適用プロセスによってデキューされ、DBMS_APPLY_ADMパッケージの SET_ENQUEUE_DESTINATIONプロシージャを使用してエンキューされた取得 LCR は、ユーザー・エンキュー・イベントです。

� ユーザー・アプリケーションは、ユーザー・エンキュー・イベントを明示的にデキューして処理します。ユーザー・アプリケーションは、Streams メッセージ・クライアントを使用する場合と、使用しない場合があります。取得されたイベントは、ユーザー・アプリケーションでデキューできません。取得されたイベントは、適用プロセスでデキューする必要があります。ただし、適用プロセスによってコールされたユーザー・プロシージャがイベントを明示的にエンキューする場合、そのイベントはユーザー・エンキュー・イベントであり、初は取得イベントであったとしても明示的にデキューできます。

デキューされたイベントは、デキュー時と同じデータベースで発生した場合と、異なるデータベースで発生した場合があります。

キュー間でのイベントの伝播キュー間でのイベントの伝播キュー間でのイベントの伝播キュー間でのイベントの伝播Streams を使用すると、異なるデータベースにある 2 つのキュー間でイベントを伝播するように構成できます。Streams では、ジョブ・キューを使用してイベントが伝播されます。

伝播は、常にソース・キューと宛先キューの間で行われます。伝播は常に 2 つのキュー間で行われますが、単一のキューが多数の伝播に関わることができます。つまり、単一のソース・キューがイベントを複数の宛先キューに伝播でき、単一の宛先キューが複数のソース・キューからイベントを受信できます。ただし、特定のソース・キューと特定の宛先キューの間に許される伝播は 1 つのみです。また、単一のキューが、ある伝播の宛先キューと他の伝播のソース・キューを兼ねることができます。

伝播では、ソース・キューにあるイベントすべてを宛先キューに伝播するか、イベントのサブセットのみを伝播できます。また、単一の伝播で取得イベントとユーザー・エンキュー・イベントの両方を伝播できます。ルールを使用すると、ソース・キュー内のどのイベントが宛先キューに伝播され、どのイベントが廃棄されるかを制御できます。


� 取得プロセスの詳細は、第 2 章「Streams の取得プロセス」を参照してください。

� 3-10 ページの「メッセージ・クライアント」

� 適用プロセスの詳細は、第 4 章「Streams の適用プロセス」を参照してください。

� イベントをキューにエンキューする方法については、『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドおよびリファレンス』を参照してください。

� LCR の管理の詳細は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。



Streams 環境の設定方法によっては、変更が発生元のサイトに送り返される場合があります。変更が無限ループ内で循環しないように環境を構成していることを確認してください。Streams タグを使用すると、このような変更の循環ループを回避できます。

伝播ルール伝播ルール伝播ルール伝播ルール伝播では、定義したルールに基づいてイベントが伝播または廃棄されます。LCR イベントの場合、各ルールでは、TRUEと評価するデータベース・オブジェクトおよび変更のタイプを指定します。これらのルールは、伝播のポジティブ・ルール・セットまたはネガティブ・ルール・セットに含めることができます。

ルールがイベントについて TRUEと評価され、そのルールが伝播のポジティブ・ルール・セットに含まれる場合、伝播は変更を伝播します。ルールがイベントについて TRUEと評価され、そのルールが伝播のネガティブ・ルール・セットに含まれる場合、伝播は変更を廃棄します。伝播にポジティブ・ルール・セットとネガティブ・ルール・セットの両方がある場合、常にネガティブ・ルール・セットが初に評価されます。

LCR イベントの伝播ルールは次のレベルで指定できます。

� 表ルールは、特定の表に対する DML 変更や DDL 変更によって発生したいずれかの行変更を伝播または廃棄します。サブセット・ルールは、特定の表に対する行変更のサブセットを含む表ルールです。

� スキーマ・ルールは、特定のスキーマのデータベース・オブジェクトに対する DML 変更や DDL 変更によって発生したいずれかの行変更を伝播または廃棄します。

� グローバル・ルールは、ソース・キュー内のすべての DML 変更または DDL 変更によって発生したすべての行変更を伝播または廃棄します。

非 LCR イベントの場合は、伝播を制御する独自のルールを作成できます。

条件を指定するキュー・サブスクライバによって、システムでルールが生成されます。キューへのすべてのサブスクライバ用のルール・セットが組み合されて、サブスクリプションをより効率的にする単一のシステム生成ルール・セットとなります。


� 10-7 ページの「Streams の伝播および伝播ジョブの管理」

� AQ の伝播のインフラストラクチャの詳細は、『Oracle Streams アドバンスト・キューイング・ユーザーズ・ガイドおよびリファレンス』を参照してください。

� Streams タグの詳細は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。



保証付きのイベント配信保証付きのイベント配信保証付きのイベント配信保証付きのイベント配信ユーザー・エンキュー・イベントが宛先キューに正常に伝播されるのは、宛先キューへのエンキューがコミットされる時点です。取得イベントが宛先キューに正常に伝播されるのは、次の両方のアクションが完了した時点です。

� イベントが、宛先キューに関連付けられた関連するすべての適用プロセスによって処理される場合。

� イベントが宛先キューからその関連宛先キューすべてに正常に伝播される場合。

2 つの SYS.AnyDataキュー間でイベントが正常に伝播されると、宛先キューはそのことを確認します。ソース・キューがイベントを複数の宛先キューに伝播するように構成されている場合は、各宛先キューがソース・キューにイベント伝播の確認を送信し終わるまで、イベントはソース・キューに残ります。各宛先キューがイベントの正常な伝播を確認し、ソース・キュー・データベース内のすべてのローカル・コンシューマがイベントをコンシュームし終わると、ソース・キューはイベントを削除できます。

この確認システムによって、イベントが常にソース・キューから宛先キューに確実に伝播されますが、構成によってはソース・キューが適サイズより大きくなる可能性があります。ソース・キューが大きくなると、SGA メモリーの使用量が増加し、ディスク領域の使用量も増加する場合があります。

ソース・キューの拡大には、通常、次の 2 つの原因があります。

� なんらかの理由（ネットワークの問題など）でイベントを指定された宛先キューに伝播できない場合、イベントは宛先キューが使用可能になるまでソース・キューに残ります。この状況がソース・キューの拡大の原因となることがあります。そのため、キューを定期的に監視して問題を早期に検出する必要があります。

� ソース・キューが取得イベントを複数の宛先キューに伝播しており、1 つ以上の接続先データベースが、他のキューよりもはるかに低速でイベントが正常に伝播されたことを確認する場合を考えます。この場合、低速の接続先データベースでは、高速の接続先データベースによってすでに確認済のイベントのバックログが作成されるため、ソース・キューが大きくなることがあります。このような環境では、複数の取得プロセスを作成してソース・データベースでの変更を取得することを考慮してください。この場合、あるソース・キューを低速の接続先データベースに、別のソース・キューを高速の接続先データベースに使用できます。






� 14-19 ページの「SYS.AnyData キューおよびメッセージの監視」



有向ネットワーク有向ネットワーク有向ネットワーク有向ネットワーク有向ネットワークとは、伝播されるイベントが接続先データベースに到達する前に 1 つ以上の中間データベースを通過するネットワークです。イベントは、中間データベースで適用プロセスによって処理される場合と、処理されない場合があります。Streams を使用すると、各接続先データベースに伝播させるイベントを選択し、イベントが接続先データベースに到達するまでのルートを指定できます。図 3-2 に、有向ネットワーク環境の例を示します。

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

有向ネットワークを使用するメリットは、ソース・データベースと接続先データベースの間に物理的なネットワーク接続を必要としないことです。そのため、イベントをデータベース間で伝播させる必要があるが、これらのデータベースを稼働させているコンピュータ間にダイレクト・ネットワーク接続がない場合も、1 つ以上の中間データベースがソース・データベースを接続先データベースに接続しているかぎり、ネットワークを再構成せずにイベントを伝播させることができます。

有向ネットワークを使用している場合に、中間サイトが長期間停止されるか、中間サイトが削除されると、ネットワークと Streams 環境の再構成が必要になる場合があります。

キューによる転送と適用による転送キューによる転送と適用による転送キューによる転送と適用による転送キューによる転送と適用による転送有向ネットワークにおける中間データベースでは、キューによる転送または適用による転送を使用してイベントを伝播できます。キューによる転送キューによる転送キューによる転送キューによる転送は、中間データベースで受信されたイベントが転送されることを意味します。イベントのソース・データベースは、イベントが発生したデータベースです。



適用による転送適用による転送適用による転送適用による転送は、中間データベースで転送されるイベントが、初に適用プロセスによって処理されることを意味します。このようなイベントは、中間データベースで取得プロセスによって再取得されてから転送されます。適用による転送を使用すると、イベントは中間データベースで生成された REDO ログから再取得されるため、中間データベースはイベントの新しいソース・データベースとなります。

Streams 環境のプランを作成するときには、キューによる転送と適用による転送に次の違いがあることに注意してください。

� キューによる転送を使用すると、取得または伝播に伴う変換がなければ、イベントは変更されずにそのまま有向ネットワークを介して伝播されます。適用による転送を使用すると、イベントは中間データベースで適用されてから再取得されます。競合解消、適用ハンドラまたは適用変換によって変更される場合があります。

� キューによる転送を使用する場合、接続先データベースでは、各ソース・データベースからのイベントを別個の適用プロセスで適用する必要があります。適用による転送を使用すると、中間データベースでイベントが再取得されることによって、変更が接続先データベースに到達する時点でソース・データベースの数が減少する場合があるため、接続先データベースに必要な適用プロセスが少数で済む可能性があります。

� キューによる転送を使用する場合は、ソース・データベースと接続先データベースの間に 1 つ以上の中間データベースが位置します。適用による転送を使用する場合、イベントは中間データベースで再取得されるため、イベントのソース・データベースは、接続先データベースと直接接続している中間データベースと同じでもかまいません。

単一の Streams 環境で、キューによる転送と適用による転送を併用できます。

キューによる転送のメリットキューによる転送のメリットキューによる転送のメリットキューによる転送のメリットキューによる転送を適用による転送と比較すると、次のようなメリットがあります。

� イベントが一度のみ取得されるため、パフォーマンスを改善できます。

� イベントが 1つ以上の中間データベースで適用されてから再取得されることがないため、イベントを発生元データベースから接続先データベースへと伝播させる所要時間が短縮されます。つまり、キューによる転送を使用すると、待機時間を短縮できる場合があります。

� イベントの発生元は、イベントに含まれている LCR に対してGET_SOURCE_DATABASE_NAMEメンバー・プロシージャを実行すると簡単に判断できます。適用による転送を使用する場合は、イベントの発生元を判断するために、Streams タグおよび適用ハンドラを使用する必要があります。

� 別々の適用プロセスを使用すると、依存性が低減し、複数の適用コーディネータと適用リーダー・プロセスによって作業が実行されるため、パラレル適用によってスケーラビリティが向上し、スループットが増大します。

� 1 つの中間データベースが停止した場合は、キューを再度ルーティングし、取得サイトで開始 SCN をリセットして、エンド・トゥ・エンドの取得、伝播および適用を再構成できます。



適用による転送を使用すると、使用不可能な中間データベースから接続先データベースへのダウンストリームでは、この中間データベースの SCN 情報が使用されているため、イベントについてエンド・トゥ・エンドの取得、伝播および適用の再構成に必要な作業量が実質的に増大します。この SCN 情報がなければ、接続先データベースでは変更を正しく適用できません。

適用による転送のメリット適用による転送のメリット適用による転送のメリット適用による転送のメリット適用による転送をキューによる転送と比較すると、次のようなメリットがあります。

� 各データベースは、複数のリモート・ソース・データベースではなく直接接続しているデータベースからのみ変更を適用できるため、Streams 環境の構成が容易です。

� 中間データベースによって変更が適用される大規模な Streams 環境では、適用プロセスが少数で済むため、環境の監視と管理が容易です。変更を適用する中間データベースでは、変更を受信するソース・データベースごとに 1 つの適用プロセスが必要です。適用による転送環境では、中間データベースのソース・データベースは、直接接続されているデータベースのみです。キューによる転送環境では、中間データベースのソース・データベースは、中間データベースに直接接続されているかどうかに関係なく環境内の他のすべてのソース・データベースです。

バイナリ・ファイルの伝播バイナリ・ファイルの伝播バイナリ・ファイルの伝播バイナリ・ファイルの伝播Streams を使用すると、データベース間でバイナリ・ファイルを伝播できます。これを行うには、メッセージ・ペイロードに 1 つ以上の BFILE属性を入れ、メッセージをリモート・キューに伝播します。ペイロードで参照される各 BFILEは、メッセージが伝播された後、メッセージの伝播がコミットされる前にリモート・データベースに転送されます。伝播された各 BFILEのディレクトリ・オブジェクトおよびファイル名は保存されますが、ソース・データベースと接続先データベースの異なるディレクトリにディレクトリ・オブジェクトをマップできます。メッセージ・ペイロードは、SYS.AnyDataペイロードにラップされたBFILE、または SYS.AnyDataペイロードにラップされたオブジェクトの 1 つ以上の BFILE属性になります。

メッセージ・ペイロードでは、次のものがサポートされません。

� 1 つ以上の BFILE属性を含む VARRAY

� 1 つ以上の BFILE属性を含む SYS.AnyData属性を持つ、ユーザー定義型オブジェクト

Streams での BFILEの伝播には、DBMS_FILE_TRANSFER.PUT_FILEプロシージャと同じ制限があります。



� キューによる転送を使用する環境の例、および適用による転送を使用する環境の例は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。


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

メッセージ・クライアントメッセージ・クライアントメッセージ・クライアントメッセージ・クライアントメッセージ・クライアントは、アプリケーションまたはユーザーによって起動された際にユーザー・エンキュー・イベントをコンシュームします。メッセージ・クライアントにキュー内のどのユーザー・エンキュー・イベントをデキューさせるかは、ルールを使用して指定します。デキューするユーザー・エンキュー・イベントには、ユーザー・エンキューLCR またはユーザー・エンキュー・メッセージを指定できます。

メッセージ・クライアントを作成するには、DBMS_STREAMS_ADMパッケージの次のいずれかのプロシージャを実行する際に、streams_typeパラメータに dequeueを指定します。

� ADD_MESSAGE_RULE

� ADD_TABLE_RULES

� ADD_SUBSET_RULES

� ADD_SCHEMA_RULES

� ADD_GLOBAL_RULES

メッセージ・クライアントを作成するには、メッセージ・クライアントの名前、およびメッセージ・クライアントがメッセージをデキューする SYS.AnyDataキューを指定します。これらのプロシージャを使用して、メッセージ・クライアントのポジティブ・ルール・セットまたはネガティブ・ルール・セットにルールを追加することもできます。各ルールのメッセージ型を指定すると、単一のメッセージ・クライアントで異なる型のメッセージをデキューできます。

メッセージ・クライアントを作成するユーザーには、メッセージ・クライアントを使用してキューからデキューするための権限が付与されます。このユーザーをメッセージ・クライアメッセージ・クライアメッセージ・クライアメッセージ・クライアント・ユーザーント・ユーザーント・ユーザーント・ユーザーといいます。メッセージ・クライアント・ユーザーは、メッセージ・クライアントのルール・セットを満たすメッセージをデキューできます。メッセージ・クライアントは 1 ユーザーのみに関連付けることができます。ただし、ユーザーは複数のメッセージ・クライアントに関連付けることができます。

参照参照参照参照 : DBMS_FILE_TRANSFERパッケージを使用したファイルの転送方法の詳細は、『Oracle Database 概要』、『Oracle Database 管理者ガイド』および『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。


SYS.AnyData 型のキューとユーザー・メッセージ

図 3-3 に、ユーザー・エンキュー・イベントをデキューするメッセージ・クライアントを示します。

図図図図 3-3 メッセージ・クライアントメッセージ・クライアントメッセージ・クライアントメッセージ・クライアント

SYS.AnyData 型のキューとユーザー・メッセージ型のキューとユーザー・メッセージ型のキューとユーザー・メッセージ型のキューとユーザー・メッセージStreams では、SYS.AnyData型のキューを使用したメッセージングが可能です。これらのキューでは、SYS.AnyData型のペイロードを伴うユーザー・メッセージをステージングできます。SYS.AnyData型のペイロードには、異なるデータ型のペイロード用のラッパーを使用できます。

メッセージ・ペイロードに SYS.AnyDataラッパーを使用すると、パブリッシャ・アプリケーションでは様々な型のメッセージを 1 つのキューにエンキューし、サブスクライバ・アプリケーションではこれらのメッセージをメッセージ・クライアントまたはアプリケーションを使用して明示的に、または適用プロセスを使用して暗黙的にデキューできます。サブスクライバ・アプリケーションがリモートの場合は、メッセージをリモート・サイトに伝播し、サブスクライバ・アプリケーションでリモート・データベースのローカル・キューからメッセージをデキューできます。また、リモート・サブスクライバ・アプリケーションでは、PL/SQL や OCI など、様々な標準プロトコルを使用して、ソース・キューからメッセージを直接デキューできます。

アドバンスト・キューイング（AQ）の機能を持つ Streams では、マルチ・コンシューマ・キュー、パブリッシュおよびサブスクライブ、コンテンツ・ベースのルーティング、インターネット伝播、変換、他のメッセージ・サブシステムへのゲートウェイなど、メッセージ・キューイング・システムのすべての標準機能がサポートされます。


� メッセージ・クライアントおよびルールの詳細は、第 6 章「Streamsでのルールの使用方法」を参照してください。



SYS.AnyData 型のキューとユーザー・メッセージ

ほぼすべての型のペイロードは、SYS.AnyDataペイロードでラップできます。そのためには、SYS.AnyData型の Convertdata_type静的ファンクションを使用します。この場合、data_typeはラップするオブジェクトの型です。これらのファンクションは、入力としてオブジェクトを取り、SYS.AnyDataオブジェクトを戻します。

次のデータ型のペイロードを含む SYS.AnyDataペイロードは、SYS.AnyDataキューにエンキューできません。

� CLOB

� NCLOB

� BLOB

また、これらのデータ型の属性を持つオブジェクト型のペイロードを含むか、または型進化や型継承を使用するオブジェクト型のペイロードを含む SYS.AnyDataペイロードは、SYS.AnyDataキューにエンキューできません。


� ROWIDデータ型のペイロードは、SYS.AnyDataラッパーでラップできません。この制限は、UROWIDデータ型のペイロードには該当しません。

� ステージングできるのが特定の 1つの型のメッセージのみのキューを、型付きのキュー型付きのキュー型付きのキュー型付きのキューと呼びます。


� 10-18 ページの「Streams メッセージ環境の管理」

� 10-19 ページの「SYS.AnyData ラッパーでのユーザー・メッセージ・ペイロードのラップおよびエンキュー」

� SYS.AnyDataラッパーでのペイロードのラップ、SYS.AnyDataキューにメッセージをエンキューしたり、SYS.AnyDataキューからメッセージをデキューするためのプログラム的な環境、伝播、ユーザー定義型など、SYS.AnyDataキュー関連の詳細は、『Oracle Streams アドバンスト・キューイング・ユーザーズ・ガイドおよびリファレンス』を参照してください。

� SYS.AnyData型の詳細は、『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。


SYS.AnyData キューと Oracle Real Application Clusters

SYS.AnyData キューとキューとキューとキューと Oracle Real Application ClustersReal Application Clusters（RAC）環境で、取得イベントとユーザー・エンキュー・イベントをステージングして伝播するように、SYS.AnyDataキューを構成できます。RAC 環境では、キューのバッファを使用できるのは所有者インスタンスのみですが、別のインスタンスは、別のキューのバッファを使用できます。バッファ・キューは、取得イベントのみを含むSYS.AnyDataキューに関連付けられたシステム・グローバル領域（SGA）メモリーです。バッファ・キューの詳細はこの章の後半で説明します。

RAC 環境では、ユーザー・エンキュー・イベントのみを含む SYS.AnyDataキューの動作は型付きのキューと同じです。ただし、RAC 環境で SYS.AnyDataキューが取得イベントを含む場合、取得イベントを RAC の接続先データベースに伝播する各伝播は、宛先キューの所有者インスタンスを参照するインスタンス固有のデータベース・リンクを使用する必要があります。伝播が他のインスタンスに接続すると、伝播でエラーが発生します。

各取得プロセスおよび適用プロセスは、開始プロシージャが別のインスタンスで実行されている場合でも、その SYS.AnyDataキューに対して所有者インスタンスで開始されます。宛先キューを含むキュー表の所有者インスタンスが使用不可能になると、キューの所有権は自動的にクラスタ内の別のインスタンスに移ります。この状況が発生した場合は、リモート・ソース・キューからのデータベース・リンクを、宛先キューを所有するインスタンスに接続するように、手動で再構成する必要があります。

Streams のプロセスおよびジョブは、キュー表のプライマリ・インスタンスおよびセカンダリ・インスタンスの指定をサポートしています。これらの指定を使用する場合、プライマリ・インスタンスが使用不可能になると、セカンダリ・インスタンスがキュー表の所有者となります。プライマリ・インスタンスが再度使用可能になると、所有権はプライマリ・インスタンスに戻ります。宛先キューを含むキュー表のプライマリ・インスタンスおよびセカンダリ・インスタンスの両方が使用不可能になると、キューの所有権は自動的にクラスタ内の別のインスタンスに移ります。この場合、プライマリ・インスタンスまたはセカンダリ・インスタンスが再度使用可能になると、所有権は使用可能になったインスタンスに戻ります。DBMS_AQADMパッケージの ALTER_QUEUE_TABLEプロシージャを使用して、プライマリ・インスタンスおよびセカンダリ・インスタンスの指定を設定できます。

DBA_QUEUE_TABLESデータ・ディクショナリ・ビューは、キュー表の所有者インスタンスに関する情報を示します。キュー表には、複数のキューが含まれている場合があります。この場合、キュー表内の各キューの所有者インスタンスは、キュー表と同じになります。


Streams のステージングと伝播のアーキテクチャ

Streams のステージングと伝播のアーキテクチャのステージングと伝播のアーキテクチャのステージングと伝播のアーキテクチャのステージングと伝播のアーキテクチャ通常、SYS.AnyDataキューには AQ のインフラストラクチャが使用されます。ただし、型付きキューではキュー表内のすべてのイベントがステージングされるのに対して、SYS.AnyDataキューにはバッファ・キューがあり、そこで共有メモリー内の取得イベントがステージングされます。この項では、バッファ・キュー、伝播ジョブ、保護キューと、Streams でのそれらの使用方法について説明します。また、トランザクション型のキューで取得イベントおよびユーザー・エンキュー・イベントがどのように処理されるかと、取得イベントを伝播するデータベースでの Streams データ・ディクショナリの必要性についても説明します。


� バッファ・キュー

� 伝播ジョブ

� 保護キュー

� トランザクション型のキューと非トランザクション型のキュー

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






� キューおよび RAC の詳細は、『Oracle Streams アドバンスト・キューイング・ユーザーズ・ガイドおよびリファレンス』を参照してください。

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



バッファ・キューバッファ・キューバッファ・キューバッファ・キューバッファ・キューバッファ・キューバッファ・キューバッファ・キューには、次の記憶領域が含まれます。

� 取得イベントのみを含む SYS.AnyDataキューに関連付けられたシステム・グローバル領域（SGA）メモリー

� メモリーからオーバーフローした取得イベントを格納する SYS.AnyDataキューのキュー表の一部

バッファ・キューによって、Oracle では、常にキュー表に格納するかわりに SGA にバッファリングすることで、取得イベントを適化できます。この取得イベントのバッファリングは、SYS.AnyDataキュー内で取得イベントがステージングされるデータベースで発生します。このようなデータベースは、ソース・データベース、中間データベースまたは接続先データベースのいずれでもかまいません。取得イベントは常にバッファ・キューに格納されますが、LCR ユーザー・エンキュー・イベントと LCR 以外のユーザー・エンキュー・イベントは、バッファ・キューではなく常にキュー表内で格納されます。また、トランザクションがエラー・キューに移動すると、トランザクション内のすべてのイベントは、バッファ・キューではなくキュー表内で格納されます。

バッファ・キューによってパフォーマンスは改善されますが、バッファ・キューを含むインスタンスが正常または異常な状態で停止すると、バッファ・キューの一部の情報が失われる場合があります。インスタンス上でデータベース全体のリカバリが実行されると、Streamsはこのような場合に自動的にリカバリします。

単一データベースでは、Streams プールという SGA の新しいプールから Streams メモリーが割り当てられるように指定できます。Streams プールを構成するには、STREAMS_POOL_SIZE初期化パラメータを使用して、プールのサイズ（バイト単位）を指定します。Streams プールのサイズが 0（ゼロ）より大きい場合、Streams によって使用される SGA メモリーは Streams プールから割り当てられます。Streams プールのサイズが 0（ゼロ）に設定されている場合、Streams によって使用されるメモリーは共有プールから割り当てられます（共有プールの大 10% まで使用できます）。

バッファ・キュー内の取得イベントは、一定の時間デキューされずにバッファ・キュー内でステージングされるか、またはメモリーにすべての取得イベントを保持するための十分な領域がない場合に、メモリーからオーバーフローしてキュー表に入れられます。メモリーからオーバーフローした取得イベントは、適切な AQ$_queue_table_name_p表に格納されます。queue_table_nameはこのキューのキュー表名です。


� AQ のインフラストラクチャの詳細は、『Oracle Streams アドバンスト・キューイング・ユーザーズ・ガイドおよびリファレンス』を参照してください。

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



伝播ジョブ伝播ジョブ伝播ジョブ伝播ジョブStreams 伝播は、DBMS_JOBSパッケージを使用して内部的に構成されます。したがって、伝播ジョブはイベントをソース・キューから宛先キューに伝播するメカニズムです。DBMS_JOBSパッケージを使用して構成される他のジョブと同様に、伝播ジョブには所有者が存在し、必要に応じてジョブ・キュー・プロセス（Jnnn）を使用してジョブが実行されます。

伝播ジョブは、複数の伝播で使用される場合があります。データベースのすべての宛先キューは、単一の伝播ジョブを介して単一のソース・キューからイベントを受信します。Streams では、複数の宛先キューに単一の伝播ジョブを使用することで、同じデータベースにある複数の宛先キューが同じメッセージを受信する場合にも、1 つのイベントが接続先データベースに確実に 1 回のみ送信されます。メッセージが同じデータベースに複数回送信されることはないため、通信リソースが節減されます。

伝播のスケジューリングと伝播のスケジューリングと伝播のスケジューリングと伝播のスケジューリングと Streams 伝播伝播伝播伝播伝播スケジュールでは、伝播ジョブでソース・キューから宛先キューにイベントを伝播する頻度を指定します。したがって、伝播ジョブを使用するすべての伝播で伝播スケジュールが同じとなります。デフォルトの伝播スケジュールは、次のいずれかのプロシージャを使用して伝播ジョブを作成するときに、その伝播ジョブに対して設定されます。

� DBMS_STREAMS_ADMパッケージの ADD_GLOBAL_PROPAGATION_RULESプロシージャ

� DBMS_STREAMS_ADMパッケージの ADD_SCHEMA_PROPAGATION_RULESプロシージャ


� STREAMS_POOL_SIZE初期化パラメータの詳細は、8-5 ページの「Streams に関連する初期化パラメータの設定」を参照してください。

� SGA の詳細は、『Oracle Database 概要』を参照してください。

� Streams 環境において、データベースで Point-in-Time リカバリを実行する方法の詳細は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。


� データベース・リンクが複数の宛先キューにイベントを伝播するために複数の伝播で使用されている場合でも、そのデータベース・リンクを使用するすべてのイベントが、単一の伝播ジョブによって伝播されます。

� ソース・キューの所有者が伝播を実行しますが、伝播ジョブの所有者はそれを作成したユーザーです。この 2 人のユーザーは、同一であっても異なっていてもかまいません。



� DBMS_STREAMS_ADMパッケージの ADD_TABLE_PROPAGATION_RULESプロシージャ

� DBMS_STREAMS_ADMパッケージの ADD_SUBSET_PROPAGATION_RULEプロシージャ

� DBMS_PROPAGATION_ADMパッケージの CREATE_PROPAGATIONプロシージャ

デフォルトのスケジュールのプロパティは、次のとおりです。

� 開始時刻は SYSDATE()です。

� 継続時間は無限を意味する NULLです。

� 次回の時刻は NULLで、これは現行の継続時間が終了した直後に伝播が再開されることを意味します。

� 待機時間は 3 秒間で、これはキューが空になってから伝播ジョブを再送するまでの待機時間です。したがって、この待機時間は、メッセージがエンキューされてから伝播されるまでの伝播期間での大待機時間（秒単位）です。

伝播ジョブのデフォルト・スケジュールを変更する場合は、DBMS_AQADMパッケージのALTER_PROPAGATION_SCHEDULEプロシージャを使用します。

伝播ジョブと伝播ジョブと伝播ジョブと伝播ジョブと RESTRICTED SESSIONシステム起動時に STARTUP RESTRICT文を発行することで制限付きセッションが有効化された場合、伝播スケジュールが有効化された伝播ジョブでのイベントの伝播は行われません。制限付きセッションが無効化されると、有効化されて実行準備が整っている各伝播スケジュールは、使用可能なジョブ・キュー・プロセスがあるときに実行されます。

SQL 文 ALTER SYSTEMおよび ENABLE RESTRICTED SESSION句によって実行中のデータベースで制限付きセッションが有効化された場合、実行中の伝播ジョブは完了するまで引き続き実行されます。ただし、伝播スケジュールに対して発行された新規の伝播ジョブは開始されません。したがって、有効化されたスケジュールの伝播が終的に停止する可能性があります。

保護キュー保護キュー保護キュー保護キュー保護キュー保護キュー保護キュー保護キューは、エンキューやデキューなどのキュー操作を実行できる 1 人以上のデータベース・ユーザーに、AQ エージェントを明示的に関連付ける必要のあるキューです。保護キューの所有者はキューに対してすべてのキュー操作を実行できますが、他のユーザーは、保護キュー・ユーザー保護キュー・ユーザー保護キュー・ユーザー保護キュー・ユーザーとして構成されていないかぎり、保護キューに対するキュー操作を実行できません。Streams では、保護キューを使用して、適切なユーザーと Streams クライアントのみがキューとの間でイベントのエンキューとデキューを確実に行えます。

参照参照参照参照 : 10-11 ページの「伝播ジョブのスケジュールの変更」



保護キューおよび保護キューおよび保護キューおよび保護キューおよび SET_UP_QUEUE プロシージャプロシージャプロシージャプロシージャDBMS_STREAMS_ADMパッケージの SET_UP_QUEUEプロシージャを使用して作成されたすべての SYS.AnyDataキューは、保護キューです。SET_UP_QUEUEプロシージャを使用してキューを作成すると、queue_userパラメータで指定したユーザーは、可能であればキューの保護キュー・ユーザーとして自動的に構成されます。また、キュー・ユーザーには、キューに対する ENQUEUEおよび DEQUEUE権限が付与されます。キューとの間でイベントのエンキューとデキューを行うには、キュー・ユーザーはDBMS_STREAMS_MESSAGINGパッケージまたは DBMS_AQパッケージに対する EXECUTE権限も必要です。SET_UP_QUEUEプロシージャでは、これらのいずれの権限も付与されません。また、イベントはデキューできるサブスクライバが構成されるまで、キューにエンキューできません。

キュー・ユーザーを保護キュー・ユーザーとして構成するために、SET_UP_QUEUEプロシージャでは、存在しない場合はユーザー名と同じ名前で 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パッケージを使用して SYS.AnyDataキューを作成する場合は、CREATE_QUEUE_TABLEプロシージャを実行するときに secureパラメータを使用して、キューが保護キューかどうかを指定します。このプロシージャを実行するときに secureパラメータに trueを指定すると、キューは保護キューになります。DBMS_AQADMパッケージを使用して保護キューを作成し、ユーザーが保護キューに対してキュー操作を実行できるようにする必要がある場合は、これらの保護キュー・ユーザーを手動で構成する必要があります。

保護キューおよび保護キューおよび保護キューおよび保護キューおよび Streams クライアントクライアントクライアントクライアント取得プロセスまたは適用プロセスを作成すると、Streams プロセスに関連付けられている保護キューの AQ エージェントが自動的に構成され、Streams プロセスを実行するユーザーは、自動的にこのキューの保護キュー・ユーザーとして指定されます。したがって、取得プロセスは保護キューを自動的にエンキューするように構成され、適用プロセスは保護キューから自動的にデキューするように構成されます。どちらの場合も、AQ エージェントの名前はStreams クライアントと同一になります。

取得プロセスの場合は、capture_userとして指定したユーザーが、取得プロセスを実行するユーザーとなります。適用プロセスの場合は、apply_userとして指定したユーザー



が、適用プロセスを実行するユーザーとなります。capture_userまたは apply_userを指定しなければ、Streams プロセスの作成プロシージャを起動したユーザーが、Streams プロセスを実行するユーザーとなります。

また、取得プロセスの capture_userまたは適用プロセスの apply_userを変更すると、指定した capture_userまたは apply_userは Streams プロセスで使用されるキューの保護キュー・ユーザーとして構成されます。ただし、古い取得ユーザーまたは適用ユーザーは、キューの保護キュー・ユーザーとして構成されたままです。古いユーザーを削除するには、そのユーザーと関連 AQ エージェントを指定して、DBMS_AQADMパッケージのDISABLE_DB_ACCESSプロシージャを実行します。また、不要になったエージェントは削除できます。DBA_AQ_AGENT_PRIVSデータ・ディクショナリ・ビューを問い合せると、AQ エージェントとその関連ユーザーを確認できます。

メッセージ・クライアントを作成すると、メッセージ・クライアントと同じ名前の保護キューの AQ エージェントは、メッセージ・クライアントの作成プロシージャを実行するユーザーに関連付けられます。このメッセージ・クライアント・ユーザーは、自動的にこのキューの保護キュー・ユーザーとして指定されます。そのため、このユーザーはメッセージ・クライアントを使用して、キューからメッセージをデキューできます。

取得プロセス、適用プロセスまたはメッセージ・クライアントは 1 ユーザーのみに関連付けることができます。ただし、ユーザーは、複数の取得プロセス、適用プロセスおよびメッセージ・クライアントを含む複数の Streams クライアントに関連付けることができます。たとえば、適用プロセスに適用ユーザーとして hrと oeの両方を含めることはできませんが、hrを複数の適用プロセスの適用ユーザーにすることはできます。

取得プロセス、適用プロセスまたはメッセージ・クライアントを削除しても、これらのStreams クライアントの保護キュー・ユーザーとして構成されていたユーザーは、引き続きキューの保護キュー・ユーザーのままです。保護キュー・ユーザーとしてのユーザーを削除するには、ユーザーごとに DBMS_AQADMパッケージの DISABLE_DB_ACCESSプロシージャを実行します。また、不要になったエージェントは削除できます。

注意注意注意注意 : 伝播および保護キューに対する構成は必要ありません。つまり、伝播の削除時に、伝播のキューから保護キュー・ユーザーを削除するための他の手順は必要ありません。


� 10-3 ページの「保護キューでのユーザー操作の有効化」

� 10-5 ページの「保護キューでのユーザー操作の無効化」

� AQ エージェントと DBMS_AQADMパッケージの使用方法の詳細は、『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。



トランザクション型のキューと非トランザクション型のキュートランザクション型のキューと非トランザクション型のキュートランザクション型のキューと非トランザクション型のキュートランザクション型のキューと非トランザクション型のキュートランザクション型のキュートランザクション型のキュートランザクション型のキュートランザクション型のキューは、複数のユーザー・エンキュー・イベントを 1 つのトランザクションとして適用されるセットにグループ化できるキューです。つまり、適用プロセスは、グループ内のすべてのユーザー・エンキュー・イベントを適用した後に COMMITを実行します。DBMS_STREAMS_ADMパッケージの SET_UP_QUEUEプロシージャでは、常にトランザクション型のキューが作成されます。

非トランザクション型のキュー非トランザクション型のキュー非トランザクション型のキュー非トランザクション型のキューは、各ユーザー・エンキュー・イベントが個別のトランザクションであるキューです。つまり、適用プロセスは、適用する各ユーザー・エンキュー・イベントの後に COMMITを実行します。どちらの場合も、ユーザー・エンキュー・イベントには、ユーザーが作成した LCR が含まれている場合と、含まれていない場合があります。

トランザクション型のキューと非トランザクション型のキューの違いが重要になるのは、ユーザー・エンキュー・イベントの場合のみです。適用プロセスは、常にソース・データベースで実行されるトランザクションを保つトランザクション内で取得イベントを適用します。表 3-1 に、イベントの型とキューの型ごとに、適用プロセスの動作を示します。

伝播用の伝播用の伝播用の伝播用の Streams データ・ディクショナリデータ・ディクショナリデータ・ディクショナリデータ・ディクショナリソース・データベースでデータベース・オブジェクトがインスタンス化のために準備されると、取得プロセスによってオブジェクトの変更が取得されたデータベースで、Streams データ・ディクショナリが自動的に移入されます。Streams データ・ディクショナリは、ソース・データベースにある 1 次データ・ディクショナリ内の一部の情報のマルチバージョン・コピーです。Streams データ・ディクショナリでは、ソース・データベースからのオブジェクト番号、オブジェクトのバージョン情報および内部の列番号が、表名、列名および列の

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

イベント型イベント型イベント型イベント型トランザクション型のキュートランザクション型のキュートランザクション型のキュートランザクション型のキュー非トランザクション型のキュー非トランザクション型のキュー非トランザクション型のキュー非トランザクション型のキュー

取得イベント適用プロセスはオリジナルのトランザクションを保ちます。

適用プロセスはオリジナルのトランザクションを保ちます。

ユーザー・エンキュー・イベント

ユーザーが指定したユーザー・エンキュー・イベントのグループを、1 つのトランザクションとし

て適用します。

各ユーザー・エンキュー・イベントをそれぞれのトランザクション内で適用します。


� 10-2 ページの「SYS.AnyData キューの管理」

� メッセージのグループ化の詳細は、『Oracle Streams アドバンスト・キューイング・ユーザーズ・ガイドおよびリファレンス』を参照してください。



データ型にマップされます。このマッピングによって、内部的には、イベントに名前ではなく番号を格納できるため、各取得イベントが小サイズに保たれます。

ソース・データベースから取得イベントを伝播するデータベースでルールを評価するために、ソース・データベースにある Streams データ・ディクショナリ内のマッピング情報が必要になります。このマッピング情報を伝播で使用できるように、Oracle は Streams の伝播がある各データベースでマルチバージョンの Streams データ・ディクショナリを自動的に移入します。ソース・データベースにある Streams データ・ディクショナリからの関連情報を含む内部メッセージは、ソース・データベースから取得イベントを受信する他のすべてのデータベースに自動的に送信されます。

キュー内のこれらの内部メッセージに含まれている Streams データ・ディクショナリ情報は、伝播によって伝播される場合と、伝播されない場合があります。どの Streams データ・ディクショナリ情報が伝播されるかは、伝播のルール・セットによって決定されます。伝播が表の Streams データ・ディクショナリ情報を検出すると、ソース・データベース名、表名、表所有者などの特定の情報を使用して、その伝播のルール・セットが評価されます。これらのルール・セットの特定のルールを評価した結果、指定されたデータベースの特定の表に関連する LCR があると判断された場合、その表の Streams データ・ディクショナリ情報が伝播されます。

Streams データ・ディクショナリ情報が宛先キューに伝播されると、宛先キューにエンキューされるのみでなく、宛先キューを含むデータベースの Streams データ・ディクショナリにも取り込まれます。したがって、有向ネットワーク構成で宛先キューを読み込む伝播は、Streams データ・ディクショナリの移入を待たずに、LCR を即時に転送できます。このように、ソース・データベースの Streams データ・ディクショナリは常に、関連するデータベース・オブジェクトの正しい状態を、これらのデータベース・オブジェクトに関連するLCR に反映します。


� 2-41 ページの「Streams データ・ディクショナリ」





Streams の適用プロ

4
Streams の適用プロセスの適用プロセスの適用プロセスの適用プロセス
この章では、Streams の適用プロセスの概念とアーキテクチャについて説明します。


� 適用プロセスの概要

� 適用プロセスのルール

� 適用プロセスによるイベント処理

� 適用されるデータ型

� Streams の適用プロセスと RESTRICTED SESSION

� Streams の適用プロセスと Oracle Real Application Clusters

� 適用プロセスのアーキテクチャ

参照参照参照参照 : 第 11 章「適用プロセスの管理」

セス 4-1

適用プロセスの概要

適用プロセスの概要適用プロセスの概要適用プロセスの概要適用プロセスの概要適用プロセスはオプションの Oracle バックグラウンド・プロセスであり、特定のキューから論理変更レコード（LCR）とユーザー・メッセージをデキューして、それぞれを直接適用するか、ユーザー定義プロシージャにパラメータとして渡します。適用プロセスによってデキューされる LCR には、適用プロセスが接続先データベース内のデータベース・オブジェクトに適用できるデータ操作言語（DML）変更またはデータ定義言語（DDL）変更の結果が含まれています。適用プロセスによってデキューされるユーザー・エンキュー・メッセージは SYS.AnyData型であり、ユーザー作成の LCR など、どのようなユーザー・メッセージでも含めることができます。

適用プロセスのルール適用プロセスのルール適用プロセスのルール適用プロセスのルール適用プロセスでは、定義したルールに基づいて変更が適用されます。各ルールでは、TRUEと評価するデータベース・オブジェクトおよび変更のタイプを指定します。これらのルールは、適用プロセスのポジティブ・ルール・セットまたはネガティブ・ルール・セットに含めることができます。

ルールが変更について TRUEと評価され、そのルールが適用プロセスのポジティブ・ルール・セットに含まれる場合、適用プロセスは変更を適用します。ルールが変更についてTRUEと評価され、そのルールが適用プロセスのネガティブ・ルール・セットに含まれる場合、適用プロセスは変更を廃棄します。適用プロセスにポジティブ・ルール・セットとネガティブ・ルール・セットの両方がある場合、常にネガティブ・ルール・セットが初に評価されます。

LCR イベントの適用プロセスのルールは次のレベルで指定できます。

� 表ルールは、特定の表に対する DML 変更や DDL 変更によって発生したいずれかの行変更を適用または伝播します。サブセット・ルールは、特定の表に対する行変更のサブセットを含む表ルールです。

� スキーマ・ルールは、特定のスキーマのデータベース・オブジェクトに対する DML 変更や DDL 変更によって発生したいずれかの行変更を適用または廃棄します。

� グローバル・ルールは、適用プロセスに関連付けられたキュー内のすべての DML 変更や DDL 変更によって発生したすべての行変更を適用または廃棄します。

非 LCR イベントの場合は、適用プロセスの動作を制御する独自のルールを作成できます。

注意注意注意注意 : 適用プロセスを関連付けることができるのは SYS.AnyDataキューのみで、型付きのキューに関連付けることはできません。





適用プロセスによるイベント処理

適用プロセスによるイベント処理適用プロセスによるイベント処理適用プロセスによるイベント処理適用プロセスによるイベント処理適用プロセスは、キュー内のイベントを処理するための柔軟なメカニズムです。環境に合わせて 1 つ以上の適用プロセスを構成する場合には、考慮を必要とするオプションがあります。この項では、適用プロセスで適用できるイベントの型と適用方法について説明します。

適用プロセスによる取得イベントとユーザー・エンキュー・イベントの処理適用プロセスによる取得イベントとユーザー・エンキュー・イベントの処理適用プロセスによる取得イベントとユーザー・エンキュー・イベントの処理適用プロセスによる取得イベントとユーザー・エンキュー・イベントの処理1 つの適用プロセスで、取得イベントまたはユーザー・エンキュー・イベントを適用できます。両方を適用することはできません。接続先データベースのキューに取得イベントとユーザー・エンキュー・イベントの両方が含まれている場合、接続先データベースにはイベントを処理する適用プロセスが少なくとも 2 つ必要です。

DBMS_STREAMS_ADMパッケージの次のいずれかのプロシージャを使用して適用プロセスを作成した場合、その適用プロセスは取得イベントにのみ適用されます。


� ADD_TABLE_RULES



DBMS_STREAMS_ADMパッケージの ADD_MESSAGE_RULEプロシージャを使用して適用プロセスを作成した場合、その適用プロセスはユーザー・エンキュー・イベントにのみ適用されます。

DBMS_APPLY_ADMパッケージの CREATE_APPLYプロシージャを使用して適用プロセスを作成する場合は、apply_capturedパラメータを使用して、取得イベントとユーザー・エンキュー・イベントのどちらを適用するかを指定します。このプロシージャで作成された適用プロセスの場合、apply_capturedパラメータはデフォルトで falseに設定されます。したがって、DBMS_APPLY_ADMパッケージの CREATE_APPLYプロシージャを使用して作成した適用プロセスは、デフォルトでユーザー・エンキュー・イベントを適用します。


� 取得イベントとユーザー・エンキュー・イベントの詳細は、3-2 ページの「イベントのステージングと伝播の概要」を参照してください。

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

Streams の適用プロセス 4-3


適用プロセスによるイベント処理オプション適用プロセスによるイベント処理オプション適用プロセスによるイベント処理オプション適用プロセスによるイベント処理オプションイベント処理オプションは、適用プロセスが受信するイベントが LCR イベントであるかどうかに応じて異なります。図 4-1 に、適用プロセスのイベント処理オプションを示します。

図図図図 4-1 適用プロセス適用プロセス適用プロセス適用プロセス

LCR イベントの処理イベントの処理イベントの処理イベントの処理適用プロセスで、取得 LCR またはユーザー・エンキュー LCR を適用できます。両方を適用することはできません。取得 LCR の場合、適用プロセスで適用できるのは、1 つのソース・データベースからの取得 LCR のみです。これは、これらの LCR を処理するには、ソース・データベースで依存性、意味のあるトランザクションの順序付けおよびトランザクションの境界を認識する必要があるためです。取得 LCR の場合、ソース・データベースは、LCR にカプセル化された変更が REDO ログで生成されたデータベースです。

複数のデータベースから取得された LCR を、単一の宛先キューに送信できます。ただし、単一のキューに複数のソース・データベースから取得された LCR が含まれている場合は、これらの LCR を取り出す適用プロセスが複数必要です。これらの各適用プロセスは、正確に 1 つのソース・データベースから取得された LCR のみを受信するように、ルールを使用して構成する必要があります。LCR を含むユーザー・エンキュー・イベント（取得イベントではなく）の場合、複数のソース・データベースからのユーザー・エンキュー・イベントであっても、1 つの適用プロセスで適用可能です。

また、各適用プロセスで適用できるのは、1 つの取得プロセスからの取得 LCR のみです。ソース・データベース上で複数の取得プロセスが実行されていて、接続先データベースで複数の取得プロセスからの LCR が適用される場合は、各取得プロセスからの変更を適用するために 1 つの適用プロセスが必要です。このような環境では、取得プロセスまたは適用プロセスで使用される各 SYS.AnyDataキューに、特定のソース・データベースの大 1 つの取得プロセスからの取得 LCR を入れることをお薦めします。各取得プロセスが異なるソース・



データベースで発生した変更を取得している場合は、キューに複数の取得プロセスからのLCR を含めることができます。

適用プロセスを構成するときに、LCR を含む取得イベントまたはユーザー・エンキュー・イベントの処理方法を次から指定できます。LCR イベントを直接適用する方法と、LCR イベントをユーザー・プロシージャにパラメータとして渡して処理させる方法があります。ここでは、これらのオプションについて説明します。

LCR イベントを直接適用する場合イベントを直接適用する場合イベントを直接適用する場合イベントを直接適用する場合このオプションを使用すると、適用プロセスではユーザー・プロシージャを実行せずに LCR イベントが適用されます。適用プロセスは、データベース・オブジェクトに LCR 内の変更を正常に適用します。また、競合または適用エラーが発生した場合は、競合ハンドラまたはエラー・ハンドラと呼ばれるユーザー指定プロシージャを使用してエラーを解決しようとします。

競合ハンドラが競合を解消できる場合は、LCR が適用されるか、LCR 内の変更が廃棄されます。エラー・ハンドラがエラーを解決できる場合は、必要に応じて LCR を適用する必要があります。エラー・ハンドラは、適用前に LCR を変更することでエラーを解決できる場合があります。競合ハンドラまたはエラー・ハンドラがエラーを解決できない場合、適用プロセスはトランザクションとそれに関連付けられたすべての LCR をエラー・キューに入れます。

ユーザー・プロシージャをコールしてユーザー・プロシージャをコールしてユーザー・プロシージャをコールしてユーザー・プロシージャをコールして LCR イベントを処理する場合イベントを処理する場合イベントを処理する場合イベントを処理する場合このオプションを使用すると、適用プロセスは LCR イベントをユーザー・プロシージャにパラメータとして渡して処理させます。ユーザー・プロシージャは、LCR イベントをカスタマイズされた方法で処理できます。

DML 文によって発生した行 LCR を処理するユーザー・プロシージャは DML ハンドラハンドラハンドラハンドラと呼ばれ、DDL 文によって発生した DDL LCR を処理するユーザー・プロシージャは DDL ハンハンハンハンドラドラドラドラと呼ばれます。適用プロセスでは多数の DML ハンドラを使用できますが、DDL ハンドラは 1 つのみで、適用プロセスによってデキューされるすべての DDL LCR を処理します。

適用プロセスに関連付けられている表ごとに、行 LCR 内の次のタイプの各操作を処理するように個別の DML ハンドラを設定できます。

� INSERT

� UPDATE

� DELETE

� LOB_UPDATE

たとえば、hr.employees表には、INSERT操作を処理する DML ハンドラが 1 つと、UPDATE操作を処理する別の DML ハンドラがあるとします。

ユーザー・プロシージャは、LCR のカスタマイズされた処理に使用できます。たとえば、ソース・データベースで特定の表に対する個々の挿入によって、接続先データベースで複数の表に挿入する必要がある場合は、そのために表に対する INSERT操作を処理するユー



ザー・プロシージャを作成できます。また、DDL 変更を適用前にログに記録する場合は、そのために DDL 操作を処理するユーザー・プロシージャを作成できます。

DML ハンドラでは、ユーザー・プロシージャによって設定された名前付きセーブポイントが対象の場合を除き、コミットもロールバックも行いません。DML ハンドラ内で行 LCR を実行するには、行 LCR 用の EXECUTEメンバー・プロシージャを起動します。DDL ハンドラ内で DDL LCR を実行するには、DDL LCR 用の EXECUTEメンバー・プロシージャを起動します。

DML ハンドラを設定するには、DBMS_APPLY_ADMパッケージの SET_DML_HANDLERプロシージャを使用します。特定の適用プロセスの DML ハンドラを設定するか、データベース内のすべての適用プロセスで使用される汎用 DML ハンドラとなる DML ハンドラを設定します。表に対する操作用の DML ハンドラを特定の適用プロセスに設定し、別の DML ハンドラを同一の表に対する同一の操作用の汎用ハンドラにする場合、特定の DML ハンドラは汎用 DML ハンドラよりも優先されます。

DDL ハンドラを特定の適用プロセスに関連付けるには、DBMS_APPLY_ADMパッケージのCREATE_APPLYまたは ALTER_APPLYプロシージャで ddl_handlerパラメータを使用します。

エラー・ハンドラは DML ハンドラの場合と同じ方法で作成しますが、SET_DML_HANDLERプロシージャを実行する際に、error_handlerパラメータを trueに設定する点は異なります。エラー・ハンドラが起動するのは、適用プロセスで指定の表において指定の操作が行われて、行 LCR の適用が試行されたときに、適用エラーが発生した場合のみとなります。

通常、DML ハンドラと DDL ハンドラは、LCR のカスタム処理を実行するために Streamsレプリケーション環境で使用されますが、これらのハンドラはレプリケーション以外の環境でも使用できます。たとえば、これらのハンドラを使用して、データベース・オブジェクトに対する変更を、レプリケートせずに記録できます。

注意注意注意注意 : LCR の LONG、LONG RAWまたは LOB 列のデータは変更しないでください。これには、DML ハンドラ、エラー・ハンドラおよびルールベースの変換ファンクションが含まれるためです。

注意注意注意注意 : SET_DML_HANDLERプロシージャを実行する場合、ハンドラを使用するオブジェクトを指定します。このオブジェクトは接続先データベースに存在する必要はありません。



LCR 以外のユーザー・メッセージの処理以外のユーザー・メッセージの処理以外のユーザー・メッセージの処理以外のユーザー・メッセージの処理LCR を含まないユーザー・エンキュー・イベントは、適用プロセス用に指定されたメッセーメッセーメッセーメッセージ・ハンドラジ・ハンドラジ・ハンドラジ・ハンドラによって処理されます。メッセージ・ハンドラとは、環境に合わせてカスタマイズされた方法で LCR 以外のユーザー・メッセージを処理できるユーザー定義プロシージャです。

メッセージ・ハンドラには、1 つ以上のリモート・データベースの更新や他のリモート・アクションを実行する必要のあるアプリケーションを含む環境で使用するとメリットがあります。これらのアプリケーションでユーザー・メッセージをローカル・データベースのキューにエンキューし、Streams で各ユーザー・メッセージを接続先データベースの適切なキューに伝播できます。複数の接続先がある場合、Streams はこれらのメッセージを自動的に各接続先に伝播して処理するためのインフラストラクチャを提供します。接続先が 1 つしかない場合も、Streams はソース・データベースのアプリケーションと接続先データベースのアプリケーションの間にレイヤーを提供します。これによって、リモート・データベースのアプリケーションが使用不可能になった場合も、ソース・データベースのアプリケーションは引き続き正常に動作できます。

たとえば、メッセージ・ハンドラは、ユーザー・メッセージを電子メール・メッセージとしてフォーマットできます。この場合、ユーザー・メッセージには、from、to、subject、text_of_messageなど、電子メール・メッセージで使用される属性が含まれます。メッセージ・ハンドラは、これらのユーザー・メッセージを電子メール・メッセージに変換し、電子メール・ゲートウェイを介して送信できます。

適用プロセス用のメッセージ・ハンドラを指定するには、DBMS_APPLY_ADMパッケージのCREATE_APPLYまたは ALTER_APPLYプロシージャで message_handlerパラメータを使用します。Streams の適用プロセスでは常に、非 LCR メッセージにはキュー内の他のイベントに対する依存性がないものとみなされます。ユーザー・エンキュー・メッセージを適用する適用プロセスの並列性が 1より大きい場合、メッセージ・ハンドラは、これらのメッセージを任意の順序でデキューできます。したがって、環境内でこれらのメッセージ間に依存性が存在する場合は、適用プロセスの並列性を 1に設定することをお薦めします。


� 行 LCR と DDL LCR の詳細は、2-2 ページの「論理変更レコード（LCR）」を参照してください。

� LCR 型用の EXECUTEメンバー・プロシージャの詳細は、『PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。


� DML ハンドラおよび DDL ハンドラの詳細は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。

参照参照参照参照 : 11-16 ページの「適用プロセスのメッセージ・ハンドラの管理」



プリコミット・ハンドラを使用したイベントのコミット情報の監査プリコミット・ハンドラを使用したイベントのコミット情報の監査プリコミット・ハンドラを使用したイベントのコミット情報の監査プリコミット・ハンドラを使用したイベントのコミット情報の監査プリコミット・ハンドラを使用して、取得イベントのコミット・ディレクティブ、およびユーザー・エンキュー・イベントのトランザクション境界を監査できます。プリコミット・ハンドラは、トランザクションのコミット情報を受信し、そのコミット情報をカスタマイズされた方法で処理できるユーザー定義の PL/SQL プロシージャです。プリコミット・ハンドラは、DML ハンドラまたはメッセージ・ハンドラと併用できます。

たとえば、ハンドラでトランザクションの長さ分のデータをキャッシュすることで、パフォーマンスが改善される場合があります。このデータには、カーソル、一時 LOB、イベントからのデータなどが含まれます。プリコミット・ハンドラは、トランザクションが完了すると、ハンドラによってキャッシュされたオブジェクトを解放または実行できます。

プリコミット・ハンドラは、適用プロセスがトランザクションをコミットする際に実行されます。commit_serialization適用プロセス・パラメータを使用して、適用プロセスのコミットの順序を制御できます。

取得イベントのコミット・ディレクティブ取得イベントのコミット・ディレクティブ取得イベントのコミット・ディレクティブ取得イベントのコミット・ディレクティブ取得プロセスを使用している場合にユーザーによってトランザクションがコミットされると、トランザクションに取得された行 LCR が含まれている場合は、取得プロセスによってトランザクションの内部コミット・ディレクティブが取得されます。これらのコミット・ディレクティブは、一度キューにエンキューされると、トランザクション内の LCR とともに宛先キューに伝播できます。プリコミット・ハンドラは、これらの内部コミット・ディレクティブのコミット SCN を適用プロセスのキューに受信します。その後、コミット SCN は適用プロセスによって処理されます。

ユーザー・エンキュー・イベントのトランザクション境界ユーザー・エンキュー・イベントのトランザクション境界ユーザー・エンキュー・イベントのトランザクション境界ユーザー・エンキュー・イベントのトランザクション境界ユーザーまたはアプリケーションは、メッセージをキューにエンキューし、COMMIT文を発行して、トランザクションを終了できます。エンキューされたメッセージは、メッセージ・グループに構成されます。キューにエンキューされたメッセージ・グループ内のメッセージは、他のキューに伝播できます。適用プロセスは、ユーザー・エンキュー・メッセージを処理するように構成されている場合、メッセージ・グループ内のすべてのメッセージに対して単一のトランザクション識別子およびコミット SCN を生成します。個別の適用プロセスによって生成されたトランザクション識別子およびコミット SCN の値は、ソース・トランザクション、または他の適用プロセスによって生成された値のいずれにも関係ありません。このような適用プロセス用に構成されたプリコミット・ハンドラは、適用プロセスによって提供されるコミット SCN を受信します。

イベント処理オプションのまとめイベント処理オプションのまとめイベント処理オプションのまとめイベント処理オプションのまとめ表 4-1 に、前項で説明した 1 つ以上の適用ハンドラを使用する場合に使用可能なイベント処理オプションのまとめを示します。行 LCR と DDL LCR は適用プロセスで直接適用できるため、適用ハンドラはオプションです。ただし、LCR 以外のユーザー・メッセージを処理するには、メッセージ・ハンドラが必須です。また、イベントが適用プロセスのルール・セットを満たしている場合にのみ、適用プロセスでこのイベントがデキューされます。通常、イベントについてネガティブ・ルール・セットのどのルールも TRUEと評価されず、ポジティ

参照参照参照参照 : 11-17 ページの「適用プロセスのプリコミット・ハンドラの管理」



ブ・ルール・セットの少なくとも 1 つのルールが TRUEと評価された場合に、そのイベントは適用プロセスのルール・セットを満たします。

この項で説明したイベント処理オプションに加えて、DBMS_APPLY_ADMパッケージのSET_ENQUEUE_DESTINATIONプロシージャを使用して、指定した宛先キューにイベントをエンキューするように適用プロセスに指示できます。また、イベントの実行を制御するには、DBMS_APPLY_ADMパッケージの SET_EXECUTEプロシージャを使用する方法もあります。

適用ハンドラに関する考慮事項適用ハンドラに関する考慮事項適用ハンドラに関する考慮事項適用ハンドラに関する考慮事項適用ハンドラを使用する際の考慮事項は、次のとおりです。

� DML ハンドラ、DDL ハンドラおよびメッセージ・ハンドラは、LCR の EXECUTEメンバー・プロシージャをコールして LCR を実行できます。

� 適用されたすべての DDL LCR は、自動的にコミットされます。したがって、DDL ハンドラが DDL LCR の EXECUTEメンバー・プロシージャをコールすると、自動的にコミットが実行されます。

表表表表 4-1 イベント処理オプションのまとめイベント処理オプションのまとめイベント処理オプションのまとめイベント処理オプションのまとめ

適用ハンドラ適用ハンドラ適用ハンドラ適用ハンドライベントの型イベントの型イベントの型イベントの型適用プロセスのデフォ適用プロセスのデフォ適用プロセスのデフォ適用プロセスのデフォルト動作ルト動作ルト動作ルト動作

ユーザー・プロシーユーザー・プロシーユーザー・プロシーユーザー・プロシージャの有効範囲ジャの有効範囲ジャの有効範囲ジャの有効範囲

DML ハンドラまたは

エラー・ハンドラ

行 LCR DML を実行 1 つの表に対する 1 つ

の操作

DDL ハンドラ DDL LCR DDL を実行適用プロセス全体

メッセージ・ハンドラ LCR 以外のユーザー・

メッセージ

エラー・トランザクションを作成（メッセージ・ハンドラが存在しない場合）

適用プロセス全体

プリコミット・ハンドラ

行 LCR を含むトラン

ザクションのコミット・ディレクティブ、または LCR 以外の

ユーザー・メッセージ

トランザクションをコミット

適用プロセス全体



� 11-19 ページの「適用プロセスによるイベントのエンキューの指定」

� 11-21 ページの「適用プロセスの実行ディレクティブの指定」


適用されるデータ型

� 必要な場合、適用ハンドラは Streams セッション・タグを設定できます。

� 適用ハンドラは、PL/SQL プロシージャでパブリッシュされた（またはラップされた）Java ストアド・プロシージャをコールできます。

� 適用プロセスが、存在しない適用ハンドラまたは無効な適用ハンドラを起動しようとすると、その適用プロセスは強制終了されます。

� 適用ハンドラが Oracle が提供するパッケージのプロシージャまたはファンクションを起動する場合、適用ハンドラを実行するユーザーにはそのパッケージに対して直接のEXECUTE権限が必要です。ロールを介してこの権限を付与するだけでは不十分です。

適用されるデータ型適用されるデータ型適用されるデータ型適用されるデータ型表に対する DML 変更によって発生した行 LCR を適用する場合、適用プロセスでは次のデータ型の列に対する変更が適用されます。

� VARCHAR2

� NVARCHAR2

� 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


� LCR 型用の EXECUTEメンバー・プロシージャの詳細は、『PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。



Streams の適用プロセスと Oracle Real Application Clusters

� CHAR

� NCHAR

� CLOB

� NCLOB

� BLOB

� UROWID

適用プロセスは、データ型 BFILE、ROWIDの列およびユーザー定義型（オブジェクト型、REF、VARRAY、ネストした表、Oracle が提供する型など）の列に DML 変更の結果を含む行 LCR は適用しません。サポートされていないデータ型の列に関する情報を含む行 LCR を適用しようとすると、適用プロセスにエラーが発生します。その場合、適用プロセスではLCR を含むトランザクションがエラー・キューに移動されます。

Streams の適用プロセスとの適用プロセスとの適用プロセスとの適用プロセスと RESTRICTED SESSIONシステム起動時に STARTUP RESTRICT文を発行して制限付きセッションを有効化した場合は、適用プロセスは起動しません。これは、データベースの停止時に適用プロセスが実行中であった場合も同様です。制限付きセッションを無効化すると、停止しなかった各適用プロセスが起動します。

ALTER SYSTEM文の ENABLE RESTRICTED SESSION句を使用して実行中のデータベースで制限付きセッションを有効化した場合は、実行中の適用プロセスには影響しません。これらの適用プロセスは引き続き実行され、イベントの適用が行われます。停止した適用プロセスは、制限付きセッション内では、制限付きセッションが無効化されるまで起動しません。

Streams の適用プロセスとの適用プロセスとの適用プロセスとの適用プロセスと Oracle Real Application ClustersStreams の適用プロセスは、Real Application Clusters（RAC）環境での変更を適用するように構成できます。各適用プロセスは、開始プロシージャが別のインスタンスで実行されている場合でも、その SYS.AnyDataキューに対して所有者インスタンスで開始されます。

適用プロセスで使用されるキューを含むキュー表の所有者インスタンスが使用不可能になると、キューの所有権は自動的にクラスタ内の別のインスタンスに移ります。また、現在の所有者インスタンスが使用不可能になった場合、適用プロセスは別のインスタンスに対するキューに従います。キュー自体はプライマリ・インスタンスおよびセカンダリ・インスタンスの所有権のルールに従います。また、所有者インスタンスが使用不可能になったときに適


� 2-7 ページの「取得されるデータ型」

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


適用プロセスのアーキテクチャ

用プロセスが有効にされると、その適用プロセスは新しい所有者インスタンスで自動的に再起動されます。所有者インスタンスが使用不可能になったときに適用プロセスが無効にされると、その適用プロセスは新しい所有者インスタンスで使用不可能のままになります。

DBA_QUEUE_TABLESデータ・ディクショナリ・ビューは、キュー表の所有者インスタンスに関する情報を示します。また、RAC 環境では、適用コーディネータ・プロセス、それに対応する適用リーダー・サーバーおよびすべての適用サーバー・プロセスが、単一のインスタンスで実行されます。

適用プロセスのアーキテクチャ適用プロセスのアーキテクチャ適用プロセスのアーキテクチャ適用プロセスのアーキテクチャ適用プロセスの作成、変更、起動、停止および削除と、適用プロセスによってキューからデキューされるイベントを制御する適用プロセスのルールの定義を行うことができます。適用プロセスで適用されるイベントは、適用ユーザー適用ユーザー適用ユーザー適用ユーザーによって適用されます。適用ユーザーは、適用プロセスのルール・セットを満たすすべての変更を適用します。また、適用ユーザーは、これらのルール・セット内のルールで指定されたすべてのルールベースの変換を実行します。適用ユーザーは、ユーザー定義の適用ハンドラも実行します。

適用ユーザーは、適用プロセスで使用されるルール・セットの実行権限、ポジティブ・ルール・セットに含まれるルールに指定されたすべてのルールベースの変換ファンクションの実行権限、適用ハンドラの実行権限、適用プロセス・キューからのイベントのデキュー権限など、変更の適用に必要な権限を持っている必要があります。適用プロセスは 1 ユーザーのみに関連付けることができます。ただし、ユーザーは複数の適用プロセスに関連付けることができます。


� 適用プロセスのコンポーネント

� 適用プロセスの作成


� キューのプライマリ・インスタンスおよびセカンダリ・インスタンスの所有権の詳細は、3-13 ページの「SYS.AnyData キューと Oracle Real Application Clusters」を参照してください。



� 4-19 ページの「データベースの再起動時における適用プロセスの永続的状態」

参照参照参照参照 : 必要な権限については、8-2 ページの「Streams 管理者の構成」を参照してください。



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

� 適用プロセスのパラメータ

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

� エラー・キュー

適用プロセスのコンポーネント適用プロセスのコンポーネント適用プロセスのコンポーネント適用プロセスのコンポーネント適用プロセスのコンポーネントは、次のとおりです。

� イベントをデキューするリーダー・サーバーリーダー・サーバーリーダー・サーバーリーダー・サーバー。リーダー・サーバーはパラレル実行サーバーであり、LCR 間の依存性を計算してイベントをトランザクションにアセンブルします。次に、アセンブルしたトランザクションをコーディネータ・プロセスに戻すと、コーディネータ・プロセスはそれをアイドル状態の適用サーバーに割り当てます。

� リーダー・サーバーからトランザクションを取得して適用サーバーに渡すコーディネーコーディネーコーディネーコーディネータ・プロセスタ・プロセスタ・プロセスタ・プロセス。コーディネータ・プロセス名は annnで、nnnはコーディネータ・プロセス番号です。有効なコーディネータ・プロセス名は、a001～ a999です。コーディネータ・プロセスは、Oracle バックグラウンド・プロセスです。

� LCR を DML 文または DDL 文としてデータベース・オブジェクトに適用するか、LCR を適切なハンドラに渡す 1 つ以上の適用サーバー適用サーバー適用サーバー適用サーバー。LCR 以外のメッセージの場合、適用サーバーはイベントをメッセージ・ハンドラに渡します。各適用サーバーは、パラレル実行サーバーです。適用サーバーにエラーが発生すると、ユーザー指定の競合ハンドラまたはエラー・ハンドラを使用してエラーを解決しようとします。エラーを解決できない場合、適用サーバーはトランザクションをロールバックし、すべてのイベントを含めてトランザクション全体をエラー・キューに置きます。

適用サーバーが完了したトランザクションをコミットする時点で、このトランザクションは適用済になっています。適用サーバーがトランザクションをエラー・キューに置いてコミットした場合も、このトランザクションは適用済になっています。

適用サーバーで処理中のトランザクションに、適用済として認識されていない別のトランザクションとの依存性がある場合、適用サーバーはコーディネータ・プロセスに通知して指示があるまで待機します。コーディネータ・プロセスはすべての適用サーバーを監視して、トランザクションが適切な順序で適用され、コミットされることを確認します。

たとえば、次の 2 つのトランザクションを考えます。

1. 表に 1 行が挿入されます。

2. 同じ行が、特定の列の値を変更するように更新されます。

この場合、行は表に挿入されるまで更新できないため、トランザクション 2 はトランザクション 1 に依存します。この 2 つのトランザクションがソース・データベースで REDO ログから取得され、接続先データベースに伝播され、そこで適用されるとします。適用サーバー A は挿入トランザクションを処理し、適用サーバー B は更新トランザクションを処理します。



適用サーバー A が挿入トランザクションを適用する前に、適用サーバー B で更新トランザクションを適用する準備が完了すると、適用サーバー B はコーディネータ・プロセスから指示があるまで待機します。適用サーバー A が挿入トランザクションを適用すると、コーディネータ・プロセスは更新トランザクションを適用するように適用サーバー B に対して指示します。

リーダー・サーバーの状態リーダー・サーバーの状態リーダー・サーバーの状態リーダー・サーバーの状態リーダー・サーバーの状態は、リーダー・サーバーが現在行っていることを示します。適用プロセスのリーダー・サーバーの状態は、V$STREAMS_APPLY_READER動的パフォーマンス・ビューを問い合せることによって表示できます。リーダー・サーバーの状態は次のいずれかになります。

� IDLE: 実行中の作業なし

� DEQUEUE MESSAGES: 適用プロセスのキューからイベントをデキュー中

� SCHEDULE MESSAGES: イベント間の依存性を計算して、イベントをトランザクションにアセンブル中

コーディネータ・プロセスの状態コーディネータ・プロセスの状態コーディネータ・プロセスの状態コーディネータ・プロセスの状態コーディネータ・プロセスの状態は、コーディネータ・プロセスが現在行っていることを示します。コーディネータ・プロセスの状態は、V$STREAMS_APPLY_COORDINATOR動的パフォーマンス・ビューを問い合せることによって表示できます。コーディネータ・プロセスの状態は次のいずれかになります。

� INITIALIZING: 起動中

� APPLYING: 適用サーバーにトランザクションを引渡し中

� SHUTTING DOWN CLEANLY: 停止中（エラーなし）

� ABORTING: 適用エラーのために停止中

適用サーバーの状態適用サーバーの状態適用サーバーの状態適用サーバーの状態適用サーバーの状態は、適用サーバーが現在行っていることを示します。適用プロセスの各適用サーバーの状態は、V$STREAMS_APPLY_SERVER動的パフォーマンス・ビューを問い合せることによって表示できます。適用サーバーの状態は次のいずれかになります。

� IDLE: 実行中の作業なし

参照参照参照参照 : 適用プロセスのリーダー・サーバーの状態を表示する問合せについては、14-34 ページの「各適用プロセス用のリーダー・サーバーに関する情報の表示」を参照してください。

参照参照参照参照 : コーディネータ・プロセスの状態を表示する問合せについては、14-36 ページの「各コーディネータ・プロセスに関する一般情報の表示」を参照してください。



� RECORD LOW-WATERMARK: 適用の進捗に関する情報をメンテナンスする管理操作を実行中。この情報は、ALL_APPLY_PROGRESSおよび DBA_APPLY_PROGRESSデータ・ディクショナリ・ビューで使用されます。

� ADD PARTITION: 進行中のトランザクションに関する情報の記録に使用されるパーティションを追加する管理操作を実行中。

� DROP PARTITION: 進行中のトランザクションに関する情報の記録に使用されたパーティションを削除する管理操作を実行中。

� EXECUTE TRANSACTION: トランザクションを適用中。

� WAIT COMMIT: 小さいコミット SCN を持つ他のすべてのトランザクションが適用されるまで、トランザクションのコミットを待機中。COMMIT_SERIALIZATION適用プロセス・パラメータが none以外の値に設定され、PARALELLISM適用プロセス・パラメータが 1より大きい値に設定された場合にのみ、この状態は発生します。

� WAIT DEPENDENCY: 依存関係にある別のトランザクションが適用されるまで、トランザクション内の LCR の適用を待機中。PARALELLISM適用プロセス・パラメータが 1より大きい値に設定されている場合のみ、この状態は発生します。

� WAIT FOR NEXT CHUNK: 大規模なトランザクションの次の LCR のセットを待機中。

� TRANSACTION CLEANUP: 適用トランザクション（適用プロセス・キューからの LCR の削除も含む）のクリーンアップ中。

適用プロセスの作成適用プロセスの作成適用プロセスの作成適用プロセスの作成適用プロセスを作成するには、DBMS_STREAMS_ADMパッケージを使用する方法と、DBMS_APPLY_ADMパッケージを使用する方法があります。一部の構成オプションにはデフォルトが自動的に使用されるため、DBMS_STREAMS_ADMパッケージを使用して適用プロセスを作成する方が簡単です。

また、DBMS_STREAMS_ADMパッケージを使用すると、適用プロセスのルール・セットが作成され、自動的にそのルール・セットにルールが追加される場合があります。inclusion_ruleパラメータが true（デフォルト）に設定されている場合、そのルール・セットはポジティブ・ルール・セットです。inclusion_ruleパラメータが falseに設定されている場合、そのルール・セットはネガティブ・ルール・セットです。または、DBMS_APPLY_ADMパッケージを使用すると適用プロセスを柔軟に作成できます。また、1つ以上のルール・セットとルールの作成は、適用プロセスの作成前または作成後に行えます。

DBMS_STREAMS_ADMパッケージのプロシージャで作成した適用プロセスでイベントを適用できるのは、ローカル・データベースのみです。リモート・データベースでイベントを適用

参照参照参照参照 : 各適用プロセスの適用サーバーの状態を表示する問合せについては、14-40 ページの「各適用プロセス用の適用サーバーに関する情報の表示」を参照してください。



する適用プロセスを作成するには、DBMS_APPLY_ADMパッケージの CREATE_APPLYプロシージャを使用します。

DBMS_STREAMS_ADMパッケージで作成した適用プロセスによって適用される変更では、接続先データベースの REDO ログ内に値 00（2 つのゼロ）のタグが生成されます。ただし、CREATE_APPLYプロシージャを使用する場合は、このタグの値を設定できます。また、タグを設定するには、DBMS_APPLY_ADMパッケージの ALTER_APPLYプロシージャを使用する方法もあります。

DBMS_APPLY_ADMパッケージの CREATE_APPLYプロシージャを実行して適用プロセスを作成する場合は、apply_captured、apply_database_linkおよび apply_tagパラメータにデフォルト以外の値を指定できます。DBMS_STREAMS_ADMパッケージまたはDBMS_RULE_ADMパッケージのプロシージャを使用すると、適用プロセスのルール・セットにルールを追加できます。

データベースに複数の適用プロセスを作成すると、各適用プロセスは相互に依存しません。これらの適用プロセスは、同じソース・データベースからの LCR を適用する場合にも、相互に同期化されません。

適用プロセス用の適用プロセス用の適用プロセス用の適用プロセス用の Streams データ・ディクショナリデータ・ディクショナリデータ・ディクショナリデータ・ディクショナリソース・データベースでデータベース・オブジェクトがインスタンス化のために準備されると、取得プロセスによってオブジェクトの変更が取得されたデータベースで、Streams データ・ディクショナリが自動的に移入されます。Streams データ・ディクショナリは、ソース・データベースにある 1 次データ・ディクショナリ内の一部の情報のマルチバージョン・コピーです。Streams データ・ディクショナリでは、ソース・データベースからのオブジェクト番号、オブジェクトのバージョン情報および内部の列番号が、表名、列名および列のデータ型にマップされます。取得イベントでは通常は内部で名前ではなく番号を使用できるため、このマッピングによって各取得イベントが小サイズに保たれます。

参照参照参照参照 : 適用プロセスの作成に使用できる次のプロシージャの詳細は、『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

� DBMS_STREAMS_ADM.ADD_TABLE_RULES

� DBMS_STREAMS_ADM.ADD_SUBSET_RULES

� DBMS_STREAMS_ADM.ADD_SCHEMA_RULES

� DBMS_STREAMS_ADM.ADD_GLOBAL_RULES

� DBMS_STREAMS_ADM.ADD_MESSAGE_RULE

� DBMS_CAPTURE_ADM.CREATE_APPLY

Streams タグの詳細は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。



取得イベントが取得または伝播中にパラメータとしてルールベースの変換に渡されないかぎり、取得イベントを適用するデータベースで LCR の内容を解析するには、ソース・データベースの Streams データ・ディクショナリ内のマッピング情報が必要です。このマッピング情報を適用プロセスで使用できるように、Oracle は Streams の適用プロセスがある各接続先データベースでマルチバージョンの Streams データ・ディクショナリを自動的に移入します。ソース・データベースにある Streams データ・ディクショナリからの関連情報は、ソース・データベースからの取得イベントを適用する他のすべてのデータベースに自動的に伝播されます。

適用プロセスのパラメータ適用プロセスのパラメータ適用プロセスのパラメータ適用プロセスのパラメータ作成後の適用プロセスは無効化されているため、初めて起動する前に環境に合わせて適用プロセス・パラメータを設定できます。適用プロセス・パラメータでは、適用プロセスの動作を制御します。たとえば、time_limit適用プロセス・パラメータを使用すると、適用プロセスが自動的に停止するまでの実行時間を指定できます。適用プロセス・パラメータの設定後に、適用プロセスを開始します。

適用プロセスの並列性適用プロセスの並列性適用プロセスの並列性適用プロセスの並列性parallelism適用プロセス・パラメータでは、トランザクションを同時に適用できる適用サーバーの数を指定します。たとえば、parallelismを 5に設定すると、適用プロセスでは合計 5 つの適用サーバーが使用されます。また、リーダー・サーバーはパラレル実行サーバーです。そのため、データベースで 6 つのパラレル実行サーバーが使用可能な場合に、parallelismを 5に設定すると、適用プロセスでは合計 6 つのパラレル実行サーバーが使用されます。適用プロセスでは、常に 2 つ以上のパラレル実行サーバーが使用されます。


� 2-41 ページの「Streams データ・ディクショナリ」

� 3-20 ページの「伝播用の Streams データ・ディクショナリ」


� 11-14 ページの「適用プロセス・パラメータの設定」

� この項では、使用可能な適用プロセス・パラメータの一部のみを説明しています。すべての適用プロセス・パラメータの詳細は、『PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』のDBMS_APPLY_ADM.SET_PARAMETERプロシージャに関する説明を参照してください。



コミットのシリアライズコミットのシリアライズコミットのシリアライズコミットのシリアライズ適用サーバーが、ソース・データベースでのコミット順序とは異なる順序に従って、接続先データベースでトランザクションを適用する場合があります。ソース・データベースでのコミット順序とは異なる順序で適用できるのは、非依存トランザクションのみです。依存トランザクションは、常にソース・データベースでコミットされたのと同じ順序に従って、接続先データベースで適用されます。

commit_serialization適用パラメータを使用して、適用サーバーが異なる順序に従って接続先データベースで非依存トランザクションを適用できるかどうかを制御します。このパラメータの設定値は次のとおりです。

� full: 適用プロセスは、ソース・データベースでのコミット時と同じ順序に従って、適用済トランザクションをコミットします。この設定がデフォルトです。

� none: 適用プロセスは、任意の順序で非依存トランザクションをコミットできます。この値を指定すると、大限のパフォーマンスが得られます。

noneを指定すると、接続先データベースにソース・データベースとは異なる順序で変更がコミットされる可能性があります。たとえば、ソース・データベースでは、2 つの非依存トランザクションが次の順序でコミットされるとします。

1. トランザクション A

2. トランザクション B


� parallelismパラメータをリセットすると、適用プロセスは自動的に停止し、現在実行中のトランザクションが適用されるときに再起動されます。トランザクションのサイズによっては、この間に少し時間がかかる場合があります。

� parallelismパラメータを使用可能なパラレル実行サーバー数より大きい数に設定すると、適用プロセスが無効化される場合があります。parallelism適用プロセス・パラメータの設定時には、PROCESSESおよび PARALLEL_MAX_SERVERS初期化パラメータが適切に設定されているかどうかを確認してください。


� 適用サーバーとリーダー・サーバーの詳細は、4-13 ページの「適用プロセスのコンポーネント」を参照してください。

� パラレル実行サーバーの管理については、『Oracle Database 管理者ガイド』を参照してください。



接続先データベースでは、これらのトランザクションが逆の順序でコミットされる可能性があります。

1. トランザクション B

2. トランザクション A

適用プロセスの自動再起動適用プロセスの自動再起動適用プロセスの自動再起動適用プロセスの自動再起動適用プロセスは、事前定義済の特定の上限に達した時点で自動的に停止するように構成できます。time_limit適用プロセス・パラメータで適用プロセスの実行時間を指定し、transaction_limit適用プロセス・パラメータで適用プロセスが適用できるトランザクションの数を指定します。適用プロセスは、これらの上限に達した時点で自動的に停止します。

disable_on_limitパラメータでは、適用プロセスが上限に達した時点で無効化されるか、再起動するかを制御します。disable_on_limitパラメータを yに設定すると、適用プロセスは上限に達した時点で無効化され、明示的に指定するまで再起動されません。ただし、disable_on_limitパラメータを nに設定すると、適用プロセスは上限に達した時点で自動的に停止し、再起動します。

再起動された適用プロセスは新規のセッション識別子を取得し、適用プロセスに関連付けられているパラレル実行サーバーも新規のセッション識別子を取得します。ただし、コーディネータ・プロセス番号（annn）は変わりません。

エラー発生時の停止または継続エラー発生時の停止または継続エラー発生時の停止または継続エラー発生時の停止または継続disable_on_error適用プロセス・パラメータを使用すると、適用プロセスをエラー発生時に無効化するか、エラー発生後も引き続きトランザクションの適用を許可するかを指定できます。

データベースの再起動時における適用プロセスの永続的状態データベースの再起動時における適用プロセスの永続的状態データベースの再起動時における適用プロセスの永続的状態データベースの再起動時における適用プロセスの永続的状態適用プロセスを実行しているデータベースが停止され、再起動されても、適用プロセスは永続的状態を保ちます。たとえば、データベースの停止時に適用プロセスを有効にすると、その適用プロセスはデータベースの再起動時に自動的に開始されます。同様に、データベースの停止時に適用プロセスを無効化または異常終了させると、その適用プロセスはデータベースが再起動されても開始されず、無効または異常終了の状態のままとなります。

エラー・キューエラー・キューエラー・キューエラー・キューエラー・キューには、データベースの現行のすべての適用エラーが含まれます。データベースに複数の適用プロセスが存在する場合、エラー・キューには各適用プロセスの適用エラーが含まれます。適用エラーに関する情報を表示するには、DBA_APPLY_ERRORデータ・ディクショナリ・ビューを問い合せます。

参照参照参照参照 : 4-19 ページの「エラー・キュー」



エラー・キューには、データベースで実行中の適用プロセスによって正常に適用できなかったトランザクションに関する情報が格納されます。トランザクションには多数のイベントが含まれる場合があり、適用中に未処理エラーが発生すると、適用プロセスでそのルール・セットを満たすトランザクション内のすべてのイベントがエラー・キューに自動的に移されます。

エラーの原因となった条件を訂正し、エラーになったトランザクションを再実行できます。たとえば、表の 1 行を変更して、エラーの原因となった条件を訂正できます。エラーの原因となった条件を訂正した後、EXECUTE_ERRORまたは EXECUTE_ALL_ERRORSプロシージャを使用してエラー・キュー内でトランザクションを再実行するか、または DELETE_ERRORや DELETE_ALL_ERRORSプロシージャを使用してエラー・キューからトランザクションを削除できます。これらのプロシージャは、DBMS_APPLY_ADMパッケージに含まれています。

エラー・キュー内のトランザクションを再実行する場合に、そのトランザクションを実行するユーザーとして、初にエラー・キューにエラーを置いたユーザーを指定する方法と、トランザクションを再実行するユーザーを指定する方法があります。また、エラー・キュー内のトランザクションを再実行する場合は、適用プロセスの現行の Streams タグが使用されます。

再実行されたトランザクションでは、関連する適用ハンドラと競合解消ハンドラが使用されます。エラーを解決するためにエラー・キュー内の行 LCR を実行前に変更する必要がある場合は、エラー・キュー内でエラーの原因となった行 LCR を処理するように DML ハンドラを構成できます。この場合、DML ハンドラはなんらかの方法で行 LCR を変更し、同じエラーの繰返しを回避できます。DBMS_APPLY_ADMパッケージの EXECUTE_ERRORまたはEXECUTE_ALL_ERRORS プロシージャを使用して、行 LCR を含むエラーを再実行すると、行 LCR が DML ハンドラに渡されます。

エラー・キューには、ローカル接続先データベースで発生したエラーに関する情報のみが格納されます。Streams 環境内の他のデータベースで実行中の適用プロセスに関するエラー情報は格納されません。

エラー・キューは、データベースの例外キューを使用します。DBMS_STREAMS_ADMパッケージの SET_UP_QUEUEプロシージャを使用して SYS.AnyDataキューを作成するとき、キューのキュー表が存在しない場合は、プロシージャによって作成されます。キュー表が作成されると、キュー表の例外キューが自動的に作成されます。複数のキューが 1 つのキュー表を使用する場合があります。また、各キュー表には 1 つの例外キューがあります。したがって、1 つの例外キューは、複数のキューおよび複数の適用プロセスのエラーを格納できます。

例外キューは自身のキュー表の適用エラーのみを格納しますが、Streams エラー・キューはデータベースの各例外キュー内のすべての適用エラーに関する情報を格納します。Streams適用エラーを管理するには、DBMS_APPLY_ADMパッケージ内のプロシージャを使用する必要があります。例外キューから適用エラーを直接デキューしないでください。



注意注意注意注意 : メッセージ・クライアントは、メッセージのデキュー時にエラーが発生すると、自身のキュー表に関連付けられている例外キューにこれらのメッセージを移します。ただし、メッセージ・クライアントのエラーに関する情報は、エラー・キューに格納されません。適用プロセスのエラーに関する情報のみが、エラー・キューに格納されます。


� 11-29 ページの「適用エラーの管理」

� 14-44 ページの「適用エラーのチェック」

� 14-45 ページの「適用エラーの詳細情報の表示」

� 11-23 ページの「エラー・ハンドラの管理」


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

� DBA_APPLY_ERRORデータ・ディクショナリ・ビューの詳細は、『Oracle Database リファレンス』を参照してください。




ル

5
ルールルールルールルール
この章では、ルールに関連する概念について説明します。


� ルールの構成要素

� ルール・セットの評価

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



� 第 12 章「ルールおよびルールベースの変換の管理」

� 第 17 章「ルールベースのアプリケーションの例」

ール 5-1

ルールの構成要素

ルールの構成要素ルールの構成要素ルールの構成要素ルールの構成要素ルールルールルールルールとは、イベントの発生時に条件が満たされている場合に、クライアントでアクションを実行できるようにするデータベース・オブジェクトです。ルールは、Oracle の組込み部分であるルール・エンジンルール・エンジンルール・エンジンルール・エンジンによって評価されます。ユーザー作成アプリケーションと Streamsなどの Oracle の機能の両方が、ルール・エンジンのクライアントとなることができます。

ルールの構成要素は、次のとおりです。

� ルール条件

� ルール評価コンテキスト（オプション）

� ルール・アクション・コンテキスト（オプション）

各ルールは、SQL 問合せの WHERE句の条件と同様の条件として指定します。関連するルールをグループ化してルール・セットルール・セットルール・セットルール・セットを作成できます。1 つのルールを 1 つ以上のルール・セットに含めることができます。また、どのルール・セットにも含めなくてもかまいません。

ルール条件ルール条件ルール条件ルール条件ルール条件ルール条件ルール条件ルール条件は、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 つの結果を生成します。または、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 アプリケーション開発者ガイド - オブジェクト・リレーショナル機能』を参照してください。

ルール 5-3


単純ルール条件単純ルール条件単純ルール条件単純ルール条件単純ルール条件とは、次のいずれかの形式で表される条件を指します。

� simple_rule_expression condition constant

� constant condition simple_rule_expression

単純ルール条件では、simple_rule_expressionは次のいずれかです。

� 表の列

� 変数

� 変数の属性

� 引数を取らないメソッドの結果。メソッドの結果は変数メソッド・ファンクションから戻すことができるため、式は数値または文字型です。

表の列、変数、および変数の属性については、すべての数値型（NUMBER、FLOAT、DOUBLE、INTEGER）と文字型（CHAR、VARCHAR2）がサポートされます。他の型の式を使用すると、単純ルール条件ではなくなります。

単純ルール条件では、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

単純ルール条件を含むルールは、単純なルールと呼ばれます。論理条件 ANDおよび ORを使用して 2 つ以上の単純な条件を結合したルールも、単純なルールです。たとえば、次の条件を含むルールは単純なルールです。

� tab1.col = 5 AND :v1 > 'aaa'

� tab1.col = 5 OR :v1 > 'aaa'

ただし、ルールの条件内で NOT論理条件を使用すると、単純なルールではなくなります。

単純なルールは、次の理由で重要です。

� 単純なルールは、ルール・エンジンによって内部的に索引を付けられます。

� 単純なルールは、SQL を実行せずに評価できます。

� 単純なルールは、部分データを使用して評価できます。

クライアントが DBMS_RULE.EVALUATEを使用してイベントを評価する場合、クライアントは、simple_rules_onlyパラメータに TRUEを指定すると、単純なルールのみを評価するように指定できます。

ルール評価コンテキストルール評価コンテキストルール評価コンテキストルール評価コンテキストルール評価コンテキストルール評価コンテキストルール評価コンテキストルール評価コンテキストは、ルール条件内で参照できる外部データを定義するデータベース・オブジェクトです。外部データは、変数または表データ、あるいはその両方として存在します。次のように類推するとわかりやすくなります。ルール条件が SQL 問合せの WHERE句であると考えると、ルール評価コンテキスト内の外部データは、その問合せの FROM句で参照される表およびバインド変数です。つまり、有効な WHERE句を作成するには、ルール条件内の式が評価コンテキスト内の表、表の別名および変数を参照する必要があります。

ルール評価コンテキストは、外部データを参照するルール条件の解析と評価に必要な情報を提供します。たとえば、ルールで変数を参照する場合、ルール評価コンテキスト内の情報には変数の型を含める必要があります。また、ルールで表の別名を参照する場合、評価コンテキストには表の別名を定義する情報を含める必要があります。

ルールによって参照されるオブジェクトは、そのルールに関連付けられたルール評価コンテキストによって決定されます。ルール所有者は、表に対する SELECT権限や型に対するEXECUTE権限など、これらのオブジェクトへのアクセスに必要な権限を持つ必要があります。ルール条件は、評価コンテキストを所有するスキーマ内で解決されます。

参照参照参照参照 : 条件および論理条件の詳細は、『Oracle Database SQL リファレンス』を参照してください。

ルール 5-5


たとえば、次の情報を含むルール評価コンテキスト 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プロシージャのコール元は、変数に関する情報を認識する必要がありません。このため、ルール・エンジンを使用するアプリケーションの複雑さを軽減できる場合があります。たとえば、変数では、評価対象のデータに基づいて値を戻すファンクションをコールできます。

� コール元には、変数値のファンクションに対する実行権限がなくてもかまいません。



� 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になっています。暗黙的変数の場合、このフィールドにはその変数によってコールされるファンクションの名前が含まれます。

評価コンテキストとルール・セットおよびルールとの関連付け評価コンテキストとルール・セットおよびルールとの関連付け評価コンテキストとルール・セットおよびルールとの関連付け評価コンテキストとルール・セットおよびルールとの関連付け1 つのルール評価コンテキストを、複数のルールまたはルール・セットに関連付けることができます。次のリストに、ルールが評価されるときに使用される評価コンテキストを示します。

� 評価コンテキストがルールに関連付けられている場合は、ルールが評価されるたびにその評価コンテキストが使用され、評価対象のルール・セットに関連付けられている評価コンテキストは無視されます。

� ルールに評価コンテキストがなくても、DBMS_RULE_ADMパッケージの ADD_RULEプロシージャを使用してルール・セットに追加するときに、ルール用の評価コンテキストを指定した場合、ルール・セットが評価されるときには、ADD_RULEプロシージャで指定した評価コンテキストがルールに使用されます。

� ルール評価コンテキストがルールに関連付けられておらず、ADD_RULEプロシージャでも指定されていない場合、ルール・セットが評価されるときには、ルール・セットの評価コンテキストがルールに使用されます。


� DBMS_RULEおよび DBMS_RULE_ADMパッケージと、Oracle が提供するルールのタイプの詳細は、『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

� DBA_EVALUATION_CONTEXT_VARSデータ・ディクショナリ・ビューの詳細は、『Oracle Database リファレンス』を参照してください。

ルール 5-7


評価ファンクション評価ファンクション評価ファンクション評価ファンクションルール評価コンテキストで実行する評価ファンクションを作成できるようにオプションが用意されています。次のような理由で、評価ファンクションの使用を選択する場合があります。

� ルール・エンジンをバイパスし、かわりに評価ファンクションを使用してイベントを評価する場合

� イベントをフィルタ処理して、一部のイベントは評価ファンクションを使用して評価し、他のイベントはルール・エンジンを使用して評価する場合

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を戻します。

注意注意注意注意 : ルールに評価コンテキストがない場合に、そのルールを評価コンテキストのないルール・セットに追加しようとすると、ADD_RULEプロシージャの実行時に評価コンテキストを指定しないかぎりエラーが発生します。



評価コンテキストに対して評価ファンクションを指定していると、その評価コンテキストがルール・セットまたはルールによって使用される場合、評価中にその評価ファンクションが実行されます。

ルール・アクション・コンテキストルール・アクション・コンテキストルール・アクション・コンテキストルール・アクション・コンテキストルール・アクション・コンテキストルール・アクション・コンテキストルール・アクション・コンテキストルール・アクション・コンテキストには、イベントのルールの評価時にルール・エンジンのクライアントによって解析されるルールに関連付けられたオプションの情報が含まれています。ルール・エンジンのクライアントは、ユーザー作成アプリケーション、または Streamsなどの Oracle の内部機能です。各ルールのアクション・コンテキストは 1 つのみです。アクション・コンテキスト内の情報は、名前 / 値ペアの配列を含む型であるSYS.RE$NV_LIST型です。

ルール・アクション・コンテキスト情報は、ルールが TRUEまたは MAYBEに評価される場合に、ルール・エンジンのクライアントによって実行されるアクションのコンテキストを提供します。ルール・エンジンは、アクション・コンテキストを解析しません。かわりに、ルール・エンジンはアクション・コンテキストを戻し、ルール・エンジンのクライアントがアクション・コンテキスト情報を解析できます。

たとえば、イベントが会社への新規従業員の追加として定義されているとします。従業員情報が hr.employees表に格納されている場合は、この表に行が挿入されるたびにイベントが発生します。会社は、新規従業員を追加するときに多数のアクションが実行されるように指定する必要がありますが、アクションは従業員の所属部門に応じて異なります。これらのアクションの 1 つは、従業員を部門関連のコースに登録することです。

この使用例では、会社は適切なアクション・コンテキストを使用して、各部門用のルールを作成できます。この場合、ルールが TRUEと評価された場合に戻されるアクション・コンテキストでは、従業員が参加する必要のあるコースの番号を指定します。3 つの部門がある場合のルール条件の一部およびアクション・コンテキストを次に示します。

これらのアクション・コンテキストでは、クライアント・アプリケーションに次の指示が戻されます。

参照参照参照参照 : DBMS_RULE_ADM.CREATE_EVALUATION_CONTEXTプロシージャ内に指定する評価ファンクションの詳細およびオーバーロードされたDBMS_RULE.EVALUATEプロシージャの詳細は、『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

ルール名ルール名ルール名ルール名ルール条件の一部ルール条件の一部ルール条件の一部ルール条件の一部アクション・コンテキストの名前アクション・コンテキストの名前アクション・コンテキストの名前アクション・コンテキストの名前 / 値ペア値ペア値ペア値ペア

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

ルール 5-9


� rule_dep_10ルールのアクション・コンテキストはクライアント・アプリケーションに対して、新規従業員をコース番号 1057に登録するように指示します。

� rule_dep_20ルールのアクション・コンテキストはクライアント・アプリケーションに対して、新規従業員をコース番号 1215に登録するように指示します。

� rule_dep_30ルールの NULLアクション・コンテキストはクライアント・アプリケーションに対して、新規従業員をどのコースにも登録しないように指示します。

各アクション・コンテキストには、0 個以上の名前 / 値ペアを含めることができます。アクション・コンテキストに複数の名前 / 値ペアが含まれている場合、リスト内のそれぞれの名前は一意である必要があります。この例では、ルール・エンジンからアクション・コンテキストが戻されるクライアント・アプリケーションでは、戻されたコース番号を持つコースに新規従業員が登録されます。NULLアクション・コンテキストが戻される場合や、アクション・コンテキストにコース番号が含まれていない場合、クライアント・アプリケーションでは従業員はコースに登録されません。

複数のクライアントで同じルールを使用する場合や、アクション・コンテキストから複数の名前 / 値ペアが戻されるようにする必要がある場合は、1 つのアクション・コンテキストで複数の名前 / 値ペアをリストできます。たとえば、会社が新規従業員を部門の電子メール・リストにも追加する場合を考えます。この場合、rule_dep_10ルールのアクション・コンテキストに次の 2 つの名前 / 値ペアを含めることができます。

名前 / 値ペアで指定する名前については、次のことを考慮する必要があります。

� 異なるアプリケーションで同じアクション・コンテキストを使用する場合は、異なる名前または名前の接頭辞を使用してネーミングの競合を回避してください。

� Oracle が提供するアクション・コンテキスト名との競合を回避するために、名前には $と # を使用しないでください。

RE$NV_LIST型の ADD_PAIRメンバー・プロシージャを使用すると、アクション・コンテキストに名前 / 値ペアを追加できます。RE$NV_LIST型の REMOVE_PAIRメンバー・プロシージャを使用すると、アクション・コンテキストから名前 / 値ペアを削除できます。アクション・コンテキスト内の既存の名前 / 値ペアを変更する場合は、初に REMOVE_PAIRメンバー・プロシージャを使用して削除してから、ADD_PAIRメンバー・プロシージャを使用して適切な名前 / 値ペアを追加する必要があります。

アクション・コンテキストには、次のデータ型の情報を含めることはできません。

� CLOB

� NCLOB

名前名前名前名前値値値値

course_number 1057

dist_list admin_list


ルール・セットの評価

� BLOB

� LONG

� LONG RAW

また、アクション・コンテキストには、これらのデータ型の属性を持つオブジェクト型、および型進化や型継承を使用するオブジェクト型を含めることはできません。

ルール・セットの評価ルール・セットの評価ルール・セットの評価ルール・セットの評価ルール・エンジンは、イベントに対してルール・セットを評価します。イベントとは、ルール・エンジンのクライアントによって定義された状態変化です。クライアントは、DBMS_RULE.EVALUATEプロシージャをコールして、イベントの評価を開始します。このプロシージャを使用すると、クライアントは、イベントに関するなんらかの情報をルール・セットの評価用のルール・エンジンに送信できます。イベント自体には、クライアントがルール・エンジンに送信する情報以外の情報が含まれる場合があります。

DBMS_RULE.EVALUATEプロシージャのコール時にクライアントによって指定される情報には、次の項目が含まれます。

� イベントの評価に使用するルールを含むルール・セットの名前。

� 評価に使用する評価コンテキスト。指定した評価コンテキストを使用するルールのみが評価されます。

注意注意注意注意 : Streams では、ルールベースの変換にアクション・コンテキストが使用されます。サブセット・ルールが指定されている場合は、UPDATE操作を含む LCR で必要な内部変換にも、アクション・コンテキストが使用されます。また、Streams では、アクション・コンテキストを使用して、適用プロセスがルールを満たすイベントをエンキューする宛先キューを指定します。さらに、Streams では、アクション・コンテキストを使用して、適用プロセスのルールを満たすイベントを適用プロセスで実行するかどうかを指定します。


� 6-45 ページの「Streams とアクション・コンテキスト」

� 名前 / 値ペアを追加および変更する例については、12-5 ページの「アクション・コンテキストを持つルールの作成」および 12-6 ページの

「ルールの変更」を参照してください。

� RE$NV_LIST型の詳細は、『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

ルール 5-11


� 表の値および変数値。表の値にはその表の行のデータを参照する ROWID が含まれ、変数値には明示的変数のデータが含まれます。暗黙的変数に指定された値は、変数値のファンクションを使用して取得される値をオーバーライドします。指定された変数に属性がある場合、クライアントはその変数全体に対する 1 つの値を送信するか、またはその変数の任意の数の属性の値を送信できます。ただし、変数全体に対する値が指定されている場合は、クライアントは属性の値を指定できません。

� オプションのイベント・コンテキストイベント・コンテキストイベント・コンテキストイベント・コンテキスト。イベント・コンテキストは、名前 / 値ペアを含む SYS.RE$NV_LIST型の配列で、イベントに関する情報を含みます。このオプションの情報がルール・エンジンによって直接使用または解析されることはありません。かわりに、評価ファンクション、変数値のファンクション（暗黙的変数用）、変数メソッド・ファンクションなど、クライアントのコールバックに渡されます。

また、クライアントは、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 つずつ戻されます。



ルール・セットの評価プロセスルール・セットの評価プロセスルール・セットの評価プロセスルール・セットの評価プロセス図 5-1 に、ルール・セットの評価プロセスを示します。

1. クライアント定義のイベントが発生します。

2. クライアントは、DBMS_RULE.EVALUATEプロシージャを使用してイベントに関する情報をルール・エンジンに送信し、ルール・セットの評価を開始します。

3. ルール・エンジンが、関連する評価コンテキストを使用してイベントのルール・セットを評価します。クライアントが、DBMS_RULE.EVALUATEプロシージャのコールでルール・セットと評価コンテキストの両方を指定します。評価に使用されるのは、指定されたルール・セット内に存在し、指定された評価コンテキストを使用するルールのみです。

4. ルール・エンジンが評価の結果を取得します。各ルールは、TRUE、FALSEまたは NULL（不明）と評価されます。

5. ルール・エンジンが、TRUEと評価されたルールを完全なリストで、または 1 つずつクライアントに戻します。各ルールとともにアクション・コンテキスト全体が戻されます。アクション・コンテキストには、情報が含まれている場合と NULLの場合があります。

6. クライアントが、ルール・エンジンから戻された結果に基づいてアクションを実行します。ルール・エンジンでは、ルール評価に基づくアクションは実行されません。

図図図図 5-1 ルール・セットの評価ルール・セットの評価ルール・セットの評価ルール・セットの評価

ルール 5-13


部分評価部分評価部分評価部分評価部分評価は、指定された評価コンテキストのすべての表および変数にデータがない状態でDBMS_RULE.EVALUATEプロシージャが実行される場合に発生します。部分評価の実行中に、使用不可能な列、変数または属性を参照するルールもあれば、使用可能なデータのみを参照するルールもあります。

例として、評価中に使用可能なデータが次のものにかぎられる場合を考えます。

� 列 tab1.col = 7

� 属性 v1.a1 = 'ABC'

次のルールが評価に使用されます。

� ルール R1には、次の条件があります。

(tab1.col = 5)


(:v1.a2 > 'aaa')


(:v1.a1 = 'ABC') OR (:v2 = 5)


(:v1.a1 = UPPER('abc'))

この使用例では、R1および R4は使用可能なデータを、R2は使用不可能なデータを、R3は使用可能なデータおよび使用不可能なデータを参照します。

部分評価は常に、ルール内の単純な条件のみを評価します。ルール条件に単純でない部分が含まれている場合は、データがどの程度使用可能であるかに応じて、ルールが完全に評価される場合と評価されない場合があります。ルールが完全に評価されない場合、それを MAYBEルールとして戻すことができます。

たとえば、前述の使用例では、R1と、R3の初の部分が評価されますが、R2および R4は評価されません。クライアントには次の結果が戻されます。


� DBMS_RULE.EVALUATEプロシージャの詳細は、『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

� Streams クライアントおよび maybe_rulesの詳細は、6-54 ページの「NULL と評価される未定義変数を伴うルール条件」を参照してください。


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

� 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

これらの権限と後述する権限は、ユーザーに直接付与するか、ロールを介して付与できます。

参照参照参照参照 : 5-4 ページの「単純ルール条件」

ルール 5-15


ルール関連のデータベース・オブジェクトを作成するための権限ルール関連のデータベース・オブジェクトを作成するための権限ルール関連のデータベース・オブジェクトを作成するための権限ルール関連のデータベース・オブジェクトを作成するための権限ユーザーがスキーマ内で評価コンテキスト、ルールまたはルール・セットを作成するには、次の条件を少なくとも 1 つは満たしている必要があります。

� スキーマがユーザー独自のスキーマであり、作成するデータベース・オブジェクトの型に対する CREATE システム権限を付与されていること。たとえば、ユーザーが独自スキーマ内でルール・セットを作成するには、CREATE_RULE_SET_OBJシステム権限を付与されている必要があります。

� 作成するデータベース・オブジェクトの型に対する CREATE ANY システム権限を付与されていること。たとえば、ユーザーが任意のスキーマ内で評価コンテキストを作成するには、CREATE_ANY_EVALUATION_CONTEXTシステム権限を付与されている必要があります。

注意注意注意注意 : ANYオブジェクト（ALTER_ANY_RULEなど）に対する権限を付与する場合に、初期化パラメータ O7_DICTIONARY_ACCESSIBILITYをfalseに設定すると、SYSスキーマを除くすべてのスキーマに含まれる指定した型のオブジェクトへのアクセス権をユーザーに付与できます。デフォルトでは、初期化パラメータ O7_DICTIONARY_ACCESSIBILITYはfalseに設定されます。

SYSスキーマ内のオブジェクトへのアクセス権を付与する必要がある場合は、オブジェクトに対するオブジェクト権限を明示的に付与できます。または、O7_DICTIONARY_ACCESSIBILITY初期化パラメータを trueに設定することもできます。この場合、ANYオブジェクトについて付与される権限では、SYSを含むすべてのスキーマへのアクセスが許可されます。


� これらのデータベース・オブジェクトの詳細は、5-2 ページの「ルールの構成要素」を参照してください。

� これらのデータベース・オブジェクトに対するシステム権限とオブジェクト権限の詳細は、『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

� ユーザー権限の概要は、『Oracle Database 概要』および『Oracle Database セキュリティ・ガイド』を参照してください。

� DBMS_STREAMS_ADMパッケージを使用してルールとルール・セットを間接的に作成する方法の詳細は、第 6 章「Streams でのルールの使用方法」を参照してください。



ルール関連のデータベース・オブジェクトを変更するための権限ルール関連のデータベース・オブジェクトを変更するための権限ルール関連のデータベース・オブジェクトを変更するための権限ルール関連のデータベース・オブジェクトを変更するための権限ユーザーが評価コンテキスト、ルールまたはルール・セットを変更するには、次の条件を少なくとも 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権限を付与されている必要があります。

注意注意注意注意 : 評価コンテキストを伴うルールを作成する場合、ルール所有者は、評価コンテキストによってアクセスされるすべてのオブジェクトに対する権限を持っている必要があります。

ルール 5-17


� ルールに対する 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システム権限を付与されていること。

ルール 5-19



Streams でのルールの使用

6
Streams でのルールの使用方法でのルールの使用方法でのルールの使用方法でのルールの使用方法
この章では、Streams でのルールの使用方法について説明します。


� Streams でのルールの使用方法の概要

� ルール・セットとイベントのルール評価

� システム作成ルール

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

� Streams とイベント・コンテキスト

� Streams とアクション・コンテキスト

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

� ルールベースの変換


� ルールの詳細は、第 5 章「ルール」を参照してください。


方法 6-1

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

Streams でのルールの使用方法の概要でのルールの使用方法の概要でのルールの使用方法の概要でのルールの使用方法の概要Streams では、次の各メカニズムが 1 つ以上のルール・セットに関連付けられている場合、それらはルール・エンジンのクライアントとなります。

� 取得プロセス

� 伝播

� 適用プロセス

� メッセージ・クライアント

これらの各クライアントは、2 つ以下のルール・セット（ポジティブ・ルール・セットおよびネガティブ・ルール・セット）に関連付けることができます。1 つのルール・セットを同じデータベース内の複数の取得プロセス、伝播、適用プロセスおよびメッセージ・クライアントで使用できます。また、1 つのルール・セットを、1 つの Streams クライアントのポジティブ・ルール・セットと別の Streams クライアントのネガティブ・ルール・セットで使用することもできます。図 6-1 に、1 つのルール・セットをルール・エンジンの複数のクライアントで使用する方法を示します。

図図図図 6-1 1 つのルール・セットをルール・エンジンの複数のクライアントで使用可能つのルール・セットをルール・エンジンの複数のクライアントで使用可能つのルール・セットをルール・エンジンの複数のクライアントで使用可能つのルール・セットをルール・エンジンの複数のクライアントで使用可能

イベントが Streams クライアントのルール・セットを満たしている場合、そのクライアントはタスクを実行します。通常、イベントについて TRUEと評価されるルールがネガティブ・ルール・セットに含まれず、ポジティブ・ルール・セットに 1 つ以上含まれる場合、そのイベントは Streams クライアントのルール・セットを満たしていることになります。イベントが Streams クライアントのルール・セットを満たす場合の詳細（1 つ以上のルール・セットが指定されていない場合の Streams クライアントの動作も含む）は、6-4 ページの「ルール・セットとイベントのルール評価」を参照してください。

特に、Streams でルール・セットを使用すると次のことができます。

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


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

� 伝播で、あるキューから別のキューに伝播または廃棄されるイベントを指定します。キュー内のイベントが伝播のルール・セットを満たしている場合、伝播でそのイベントが伝播されます。キュー内のイベントが伝播のルール・セットを満たしていない場合、伝播でそのイベントが廃棄されます。

� 適用プロセスで、キューから取出しまたは廃棄するイベントを指定します。キュー内のイベントが適用プロセスのルール・セットを満たしている場合、そのイベントが適用プロセスによってデキューされ、処理されます。キュー内のイベントが適用プロセスのルール・セットを満たしていない場合、適用プロセスはそのイベントを廃棄します。

� メッセージ・クライアントで、キューからデキューまたは廃棄するユーザー・エンキュー・イベントを指定します。キュー内のユーザー・エンキュー・イベントがメッセージ・クライアントのルール・セットを満たしている場合、メッセージ・クライアントを使用しているユーザーまたはアプリケーションはそのイベントをデキューします。キュー内のユーザー・エンキュー・イベントがメッセージ・クライアントのルール・セットを満たしていない場合、メッセージ・クライアントを使用しているユーザーまたはアプリケーションはそのイベントを廃棄します。

伝播または適用プロセスの場合、ルール・セットに対して評価されるイベントは、取得イベントまたはユーザー・エンキュー・イベントのいずれかです。

競合するルールを含むポジティブ・ルール・セットがクライアントに関連付けられている場合は、どちらかのルールが TRUEと評価されると、そのクライアントはタスクを実行します。たとえば、取得プロセスのポジティブ・ルール・セットに、hr.employees表に対するデータ操作言語（DML）変更の結果を取得するように取得プロセスに指示する 1 つのルールが含まれている場合、同じルール・セットに hr.employees表に対する DML 変更の結果を取得しないように取得プロセスに指示する別のルールが含まれていても、取得プロセスではこれらの変更が取得されます。

同様に、競合するルールを含むネガティブ・ルール・セットがクライアントに関連付けられている場合は、どちらかのルールがイベントについて TRUEと評価されると、そのクライアントはイベントを廃棄します。たとえば、取得プロセスのネガティブ・ルール・セットに、hr.departments表に対する DML 変更の結果を廃棄するように取得プロセスに指示する 1つのルールが含まれている場合、同じルール・セットに hr.departments表に対するDML 変更の結果を廃棄しないように取得プロセスに指示する別のルールが含まれていても、取得プロセスではこれらの変更が廃棄されます。

参照参照参照参照 : メッセージ・クライアントの詳細は、次の項を参照してください。


� 3-4 ページの「キュー間でのイベントの伝播」


� 3-10 ページの「メッセージ・クライアント」

Streams でのルールの使用方法 6-3

ルール・セットとイベントのルール評価

ルール・セットとイベントのルール評価ルール・セットとイベントのルール評価ルール・セットとイベントのルール評価ルール・セットとイベントのルール評価Streams クライアントでは、ルールに基づいて次のタスクが実行されます。

� 取得プロセスでは、REDO ログ内の変更を取得し、取得した変更を論理変更レコード（LCR）イベントに変換して、これらのイベントを取得プロセスのキューにエンキューします。

� 伝播では、ソース・キューから宛先キューに取得イベントまたはユーザー・エンキュー・イベント（あるいはその両方）を伝播します。

� 適用プロセスでは、キューから取得イベントまたはユーザー・エンキュー・イベントのいずれかをデキューし、これらのイベントを直接適用するか、または適用ハンドラに送信します。

� メッセージ・クライアントでは、ユーザー・エンキュー・イベントをそのキューからデキューします。

これらすべての Streams クライアントは、ルール・エンジンのクライアントです。イベントが Streams クライアントで使用されるルール・セットを満たしている場合、Streams クライアントはそのイベントに対してタスクを実行します。Streams クライアントには、ルール・セットが存在しない場合、ポジティブ・ルール・セットのみが存在する場合、ネガティブ・ルール・セットのみが存在する場合、またはポジティブ・ルール・セットとネガティブ・ルール・セットの両方が存在する場合があります。ここでは、次のそれぞれの場合のルール評価について説明します。

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

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

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

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

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

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

Streams クライアントにルール・セットが存在しない場合クライアントにルール・セットが存在しない場合クライアントにルール・セットが存在しない場合クライアントにルール・セットが存在しない場合Streams クライアントにルール・セットが存在しない場合、発生したすべてのイベントに対してタスクが実行されます。ルール・セットが空である場合と、ルール・セットが存在しない場合とは異なります。

参照参照参照参照 : 6-5 ページの「Streams クライアントに空のルール・セットが 1 つ以上存在する場合」


ルール・セットとイベントのルール評価

Streams クライアントにポジティブ・ルール・セットのみが存在する場合クライアントにポジティブ・ルール・セットのみが存在する場合クライアントにポジティブ・ルール・セットのみが存在する場合クライアントにポジティブ・ルール・セットのみが存在する場合Streams クライアントにポジティブ・ルール・セットのみが存在し、ネガティブ・ルール・セットが存在しない場合、ポジティブ・ルール・セットのいずれかのルールがイベントについて TRUEと評価されれば、そのイベントに対してタスクが実行されます。ただし、ポジティブ・ルール・セットのすべてのルールがイベントについて FALSEと評価された場合、Streams クライアントによってそのイベントは廃棄されます。

Streams クライアントにネガティブ・ルール・セットのみが存在する場合クライアントにネガティブ・ルール・セットのみが存在する場合クライアントにネガティブ・ルール・セットのみが存在する場合クライアントにネガティブ・ルール・セットのみが存在する場合Streams クライアントにネガティブ・ルール・セットのみが存在し、ポジティブ・ルール・セットが存在しない場合、ネガティブ・ルール・セットのいずれかのルールがイベントについて TRUEと評価されれば、そのイベントは廃棄されます。ただし、ネガティブ・ルール・セットのすべてのルールがイベントについて FALSEと評価された場合、そのイベントに対して Streams クライアントのタスクが実行されます。

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

Streams クライアントにポジティブ・ルール・セットとネガティブ・ルール・セットの両方が存在する場合、初にネガティブ・ルール・セットがイベントについて評価されます。ネガティブ・ルール・セットのいずれかのルールがイベントについて TRUEと評価されれば、そのイベントは廃棄され、ポジティブ・ルール・セットでの評価は行われません。

ただし、ネガティブ・ルール・セットのすべてのルールがイベントについて FALSEと評価された場合は、ポジティブ・ルール・セットでの評価が行われます。この場合の動作は、Streams クライアントにポジティブ・ルール・セットのみが存在する場合の動作と同じです。ポジティブ・ルール・セットのいずれかのルールがイベントについて TRUEと評価されれば、そのイベントに対して Streams クライアントのタスクが実行されます。ポジティブ・ルール・セットのすべてのルールがイベントについて FALSEと評価された場合、Streams クライアントによってそのイベントは廃棄されます。

Streams クライアントに空のルール・セットがクライアントに空のルール・セットがクライアントに空のルール・セットがクライアントに空のルール・セットが 1 つ以上存在する場合つ以上存在する場合つ以上存在する場合つ以上存在する場合Streams クライアントに空のルール・セットが 1 つ以上存在する場合があります。その場合、Streams クライアントは次のように動作します。

� Streams クライアントにポジティブ・ルール・セットが存在せず、空のネガティブ・ルール・セットが存在する場合、すべてのイベントに対してタスクが実行されます。

� Streams クライアントにポジティブ・ルール・セットとネガティブ・ルール・セットの両方が存在し、ネガティブ・ルール・セットのみが空である場合、ポジティブ・ルール・セットのルールに基づいてタスクが実行されます。

� Streams クライアントに空のポジティブ・ルール・セットが存在する場合、ネガティブ・ルール・セットの状態に関係なく、すべてのイベントが廃棄されます。


システム作成ルール

ルール・セットとルール・セットとルール・セットとルール・セットと Streams クライアントの動作のまとめクライアントの動作のまとめクライアントの動作のまとめクライアントの動作のまとめ表 6-1 に、前項で説明した Streams クライアントの動作のまとめを示します。

システム作成ルールシステム作成ルールシステム作成ルールシステム作成ルールイベントが Streams クライアントのルール・セットを満たしている場合、そのクライアントはイベントに対してタスクを実行します。システム作成ルールでは、粒度レベルとして表、スキーマまたはグローバルのいずれかを指定できます。この項では、各レベルについて説明します。特定のタスクに複数のレベルを指定できます。たとえば、1 つの適用プロセスに対して、oeスキーマ内で特定の表に表レベルの適用を実行し、hrスキーマ全体にスキーマ・レベルの適用を実行するように指示できます。また、1 つのルールは、データ操作言語

（DML）変更またはデータ定義言語（DDL）変更の結果のいずれかに関連しています。そのため、たとえば、特定の表に対するすべての変更を含めるには、DML 変更の結果用に 1 つと DDL 変更の結果用に 1 つの、少なくとも 2 つのシステム作成ルールが必要です。DML 変更の結果とは、DML 変更のために REDO ログに記録される行変更、または各行の変更をカプセル化するキュー内の行 LCR です。

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

ネガティブ・ルーネガティブ・ルーネガティブ・ルーネガティブ・ルール・セットル・セットル・セットル・セット

ポジティブ・ルーポジティブ・ルーポジティブ・ルーポジティブ・ルール・セットル・セットル・セットル・セット Streams クライアントの動作クライアントの動作クライアントの動作クライアントの動作

なしなしすべてのイベントに対してタスクを実行します。

なしあり（ルールを含む）ポジティブ・ルール・セットで TRUEと評価さ

れたイベントに対してタスクを実行します。

あり（ルールを含む）なしネガティブ・ルール・セットで TRUEと評価さ

れたイベントを廃棄し、それ以外のすべてのイベントに対してタスクを実行します。

あり（ルールを含む）あり（ルールを含む）ネガティブ・ルール・セットで TRUEと評価さ

れたイベントを廃棄し、残りのイベントのうち、ポジティブ・ルール・セットで TRUEと評価さ

れたものに対してタスクを実行します。初にネガティブ・ルール・セットが評価されます。

あり（空）なしすべてのイベントに対してタスクを実行します。

あり（空）あり（ルールを含む）ポジティブ・ルール・セットで TRUEと評価さ

れたイベントに対してタスクを実行します。

なしあり（空）すべてのイベントを廃棄します。

あり（空）あり（空）すべてのイベントを廃棄します。

あり（ルールを含む）あり（空）すべてのイベントを廃棄します。



表 6-2 に、各 Streams タスクに対して各レベルのルールが持つ意味について説明します。ネガティブ・ルール・セットがポジティブ・ルール・セットの前に評価されることに注意してください。

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

タスクタスクタスクタスク表ルール表ルール表ルール表ルールスキーマ・ルールスキーマ・ルールスキーマ・ルールスキーマ・ルールグローバル・ルールグローバル・ルールグローバル・ルールグローバル・ルール

取得プロセスを使用した取得

ネガティブ・ルール・セットに含まれる場合、指定した表について REDO ログ内

の変更を廃棄します。

ポジティブ・ルール・セットに含まれる場合、指定した表について REDO ログ内

のすべての変更または変更のサブセットを取得し、論理変更レコード（LCR）に

変換してエンキューします。

ネガティブ・ルール・セットに含まれる場合、スキーマ自体および指定したスキーマ内のデータベース・オブジェクトについて REDOログ内の変更を廃棄します。

ポジティブ・ルール・セットに含まれる場合、スキーマ自体および指定したスキーマ内のデータベース・オブジェクトについて REDOログ内の変更を取得し、LCR に変

換してエンキューします。

ネガティブ・ルール・セットに含まれる場合、データベース内のすべてのデータベース・オブジェクトに対する変更を廃棄します。

ポジティブ・ルール・セットに含まれる場合、データベース内のすべてのデータベース・オブジェクトに対する変更を取得し、LCR に

変換してエンキューします。

伝播を使用した伝播

ネガティブ・ルール・セットに含まれる場合、ソース・キュー内の指定した表に関連する LCR を廃棄します。

ポジティブ・ルール・セットに含まれる場合、ソース・キュー内の指定した表に関連する LCR のすべてまたは

サブセットを、宛先キューに伝播します。

ネガティブ・ルール・セットに含まれる場合、ソース・キュー内の指定したスキーマ自体およびスキーマ内のデータベース・オブジェクトに関連する LCR を廃棄し

ます。

ポジティブ・ルール・セットに含まれる場合、ソース・キュー内の指定したスキーマ自体およびスキーマ内のデータベース・オブジェクトに関連する LCR を、宛先

キューに伝播します。

ネガティブ・ルール・セットに含まれる場合、ソース・キュー内のすべての LCR を

廃棄します。

ポジティブ・ルール・セットに含まれる場合、ソース・キューにあるすべての LCRを宛先キューに伝播します。

適用プロセスを使用した適用

ネガティブ・ルール・セットに含まれる場合、指定した表に関連するキュー内のLCR を廃棄します。

ポジティブ・ルール・セットに含まれる場合、指定した表に関連するキュー内のLCR のすべてまたはサブ

セットを適用します。

ネガティブ・ルール・セットに含まれる場合、指定したスキーマ自体およびスキーマ内のデータベース・オブジェクトに関連するキュー内の LCR を廃棄します。

ポジティブ・ルール・セットに含まれる場合、指定したスキーマ自体およびスキーマ内のデータベース・オブジェクトに関連するキュー内の LCR を適用します。

ネガティブ・ルール・セットに含まれる場合、キュー内のすべての LCR を廃棄し

ます。

ポジティブ・ルール・セットに含まれる場合、キュー内のすべての LCR を適用し

ます。



DBMS_STREAMS_ADMパッケージのプロシージャを使用して、これらの各レベルでルールを作成できます。システム作成ルールには、表 6-2 で説明されている以外にも、Streams クライアントの動作を変更する条件を含めることができます。たとえば、LCR に対して特定のソース・データベースを指定できるルールがあります。この場合、このルールは、LCR が指定されたソース・データベースで発生した場合にのみ TRUEと評価します。表 6-3 に、DBMS_STREAMS_ADMパッケージによって作成されるルール内に指定できるシステム作成ルールの条件のタイプを示します。

メッセージ・クライアントを使用したデキュー

ネガティブ・ルール・セットに含まれる場合、メッセージ・クライアントの起動時に、キュー内の指定した表に関連するユーザー・エンキュー LCR を廃棄しま

す。

ポジティブ・ルール・セットに含まれる場合、メッセージ・クライアントの起動時に、キュー内の指定した表に関連するすべてのユーザー・エンキュー LCRまたはユーザー・エンキュー LCR のサブセットを

デキューします。

ネガティブ・ルール・セットに含まれる場合、メッセージ・クライアントの起動時に、キュー内の指定したスキーマ自体およびスキーマ内のデータベース・オブジェクトに関連するユーザー・エンキュー LCR を廃棄します。

ポジティブ・ルール・セットに含まれる場合、メッセージ・クライアントの起動時に、キュー内の指定したスキーマ自体およびスキーマ内のデータベース・オブジェクトに関連するユーザー・エンキュー LCR をデキューします。

ネガティブ・ルール・セットに含まれる場合、メッセージ・クライアントの起動時に、キュー内のすべてのユーザー・エンキューLCR を廃棄します。

ポジティブ・ルール・セットに含まれる場合、メッセージ・クライアントの起動時に、キュー内のすべてのユーザー・エンキューLCR をデキューします。

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

ルールの条件がルールの条件がルールの条件がルールの条件が TRUE に評価される対象に評価される対象に評価される対象に評価される対象 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

表表表表 6-2 タスクのタイプとルールのレベルタスクのタイプとルールのレベルタスクのタイプとルールのレベルタスクのタイプとルールのレベル（続き）（続き）（続き）（続き）

タスクタスクタスクタスク表ルール表ルール表ルール表ルールスキーマ・ルールスキーマ・ルールスキーマ・ルールスキーマ・ルールグローバル・ルールグローバル・ルールグローバル・ルールグローバル・ルール



特定の表に対する、REDO ログに記録される

すべての DDL 変更

取得プロセス ADD_TABLE_RULES

特定の表内の行のサブセットに対する DML 変

更のために REDO ログに記録されるすべての

行変更

取得プロセス 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

表表表表 6-3 DBMS_STREAMS_ADM パッケージによって作成されるシステム作成ルールの条件パッケージによって作成されるシステム作成ルールの条件パッケージによって作成されるシステム作成ルールの条件パッケージによって作成されるシステム作成ルールの条件（続き）（続き）（続き）（続き）




表 6-3 に示した各プロシージャでは、次の操作が実行されます。

� 取得プロセス、伝播、適用プロセスまたはメッセージ・クライアントは、存在しない場合には作成されます。

� 指定した取得プロセス、伝播、適用プロセスまたはメッセージ・クライアントのルール・セットは、存在しない場合には作成されます。ルール・セットはポジティブ・ルール・セットまたはネガティブ・ルール・セットになります。プロシージャを 2 回以上実行して、各タイプのルール・セットを作成できます。

� 0 個以上のルールが作成され、指定の取得プロセス、伝播、適用プロセスまたはメッセージ・クライアントのルール・セットに追加されます。これらのプロシージャのいず

ユーザー指定のルール条件を満たす指定したタイプの適用プロセスのキューのすべてのユーザー・エンキュー・イベント

適用プロセス 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

表表表表 6-3 DBMS_STREAMS_ADM パッケージによって作成されるシステム作成ルールの条件パッケージによって作成されるシステム作成ルールの条件パッケージによって作成されるシステム作成ルールの条件パッケージによって作成されるシステム作成ルールの条件（続き）（続き）（続き）（続き）




れかを実行すると、ユーザーによって設定された仕様に基づいて、ポジティブ・ルール・セットまたはネガティブ・ルール・セットにルールが追加されます。

ADD_MESSAGE_RULEおよび ADD_MESSAGE_PROPAGATION_RULEを除き、前述のプロシージャによって作成されたルール・セットでは、Streams 環境用に Oracle が提供する評価コンテキスト SYS.STREAMS$_EVALUATION_CONTEXTが使用されます。また、グローバル・ルール、スキーマ・ルール、表ルールおよびサブセット・ルールでは、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 つのルールが作成されます。Streams タスクを DML 変更または DDL 変更によって発生する行変更についてのみ実行する場合は、ルールを 1 つのみ作成します。ただし、Streams タスクを DML 変更と DDL 変更の結果の両方について実行する場合は、ルールを個別に作成します。ここで表の 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 変更の結果のルールは作成されません。

取得イベントの伝播ルールを作成する場合は、変更のソース・データベースを指定することをお薦めします。適用プロセスでは、トランザクション制御イベントを使用して、取得イベントがコミット済トランザクションにアセンブルされます。COMMITや ROLLBACKなどのトランザクション制御イベントには、イベントが発生したソース・データベースの名前が含まれています。これらのイベントが意図に反して循環してしまうことを避けるには、伝播ルールにソース・データベースを指定して条件を含める必要があります。そのためには、伝播ルールを作成するときにソース・データベースを指定します。



次の項では、システム作成ルールについて詳しく説明します。

� グローバル・ルール

� スキーマ・ルール

� 表ルール

� サブセット・ルール

� メッセージ・ルール

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

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


� NOTまたは OR論理条件を使用するルールなど、より複雑なルール条件を指定してルールを作成するには、DBMS_STREAMS_ADMパッケージの一部のプロシージャで使用可能な and_conditionパラメータを使用するか、DBMS_RULE_ADMパッケージを使用します。

� この項で説明する各例は、特に明記されていないかぎり、適切な権限を付与されている Streams 管理者が完了する必要があります。

� この項の例を実行するには前提条件が必要です。たとえば、プロシージャ・パラメータで指定されたキューが存在している必要があります。


� イベントが Streams クライアントのルール・セットを満たす場合の詳細は、6-4 ページの「ルール・セットとイベントのルール評価」を参照してください。

� DBMS_STREAMS_ADMパッケージと DBMS_RULE_ADMパッケージの詳細は、『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

� 6-40 ページの「Streams で使用される評価コンテキスト」

� 2-2 ページの「論理変更レコード（LCR）」

� 6-51 ページの「複合ルール条件」



グローバル・ルールグローバル・ルールグローバル・ルールグローバル・ルールルールを使用してデータベース全体またはキュー全体に関連する Streams タスクを指定するときには、グローバル・ルールを指定します。DML 変更に関するグローバル・ルール、DDL 変更に関するグローバル・ルールまたは各タイプの変更に関する 2 つのルールを指定できます。

取得プロセスの場合、ポジティブ・ルール・セットに 1 つのグローバル・ルールを含めると、ソース・データベースに対するすべての DML 変更またはすべての DDL 変更の結果を取得することを意味します。取得プロセスの場合、ネガティブ・ルール・セットに 1 つのグローバル・ルールを含めると、ソース・データベースに対するすべての DML 変更またはすべての DDL 変更の結果を廃棄することを意味します。

伝播の場合、ポジティブ・ルール・セットに 1 つのグローバル・ルールを含めると、ソース・キュー内のすべての行 LCR またはすべての DDL LCR を宛先キューに伝播させることを意味します。ネガティブ・ルール・セットに含めると、ソース・キュー内のすべての行LCR またはすべての DDL LCR を廃棄することを意味します。

適用プロセスの場合、ポジティブ・ルール・セットに 1 つのグローバル・ルールを含めると、指定したソース・データベースについて、キュー内にあるすべての行 LCR またはすべての DDL LCR を適用することを意味します。ネガティブ・ルール・セットに含めると、指定したソース・データベースについて、キュー内にあるすべての行 LCR またはすべてのDDL LCR を廃棄することを意味します。

グローバル・ルールを使用する場合、Streams ではサポートされていないデータベース・オブジェクトに対する変更を回避するには、DBMS_RULE_ADMパッケージを使用してルールを作成し、サポートされていない変更を廃棄します。

グローバル・ルールの例グローバル・ルールの例グローバル・ルールの例グローバル・ルールの例DBMS_STREAMS_ADMパッケージの ADD_GLOBAL_RULESプロシージャを使用し、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);

参照参照参照参照 : 6-50 ページの「サポートされていない LCR を廃棄するようにStreams クライアントに指示するルール条件」



END;/

inclusion_ruleパラメータが trueに設定されていることに注意してください。この設定によって、システム作成ルールが取得プロセスのポジティブ・ルール・セットに追加されます。

ローカルの取得プロセス用のルールが作成中であるため、source_databaseパラメータにNULLを指定できます。また、ローカル・データベースのグローバル名を指定することもできます。ADD_GLOBAL_RULESを使用してダウンストリーム取得プロセスまたは適用プロセスのルールを作成する場合は、ソース・データベース名を指定します。

ADD_GLOBAL_RULESプロシージャによって、行 LCR（DML 変更の結果を含む）用に 1 つと DDL LCR 用に 1 つ、合計 2 つのルールが作成されます。

行 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 変更がすべて取得されます。



システム作成グローバル・ルールにおける空のルール条件の自動回避システム作成グローバル・ルールにおける空のルール条件の自動回避システム作成グローバル・ルールにおける空のルール条件の自動回避システム作成グローバル・ルールにおける空のルール条件の自動回避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.get_source_database_name()>=' ' OR :ddl.get_source_database_name()<=' ') )

システム作成グローバル・ルールに含まれるこれらの条件によって、すべての行 LCR および DDL LCR が TRUEと評価されます。

これらのルール条件は、ルールに対する NULLのルール条件を回避するように指定されています。NULLのルール条件はサポートされません。この場合、変更の取得時にルールベースの変換を使用せずに、データベースに対するすべての DML 変更および DDL 変更を取得するには、グローバル・ルールを指定するかわりにポジティブ・ルール・セットを持たない取得プロセスを実行します。



スキーマ・ルールスキーマ・ルールスキーマ・ルールスキーマ・ルールルールを使用してスキーマに関連する Streams タスクを指定するときには、スキーマ・ルールを指定します。DML 変更に関するスキーマ・ルール、DDL 変更に関するスキーマ・ルールまたはスキーマに対する各タイプの変更に関する 2 つのルールを指定できます。

取得プロセスの場合、ポジティブ・ルール・セットに 1 つのスキーマ・ルールを含めると、スキーマに対する DML 変更または DDL 変更を取得することを意味します。ネガティブ・ルール・セットに含めると、スキーマに対する DML 変更または DDL 変更を廃棄することを意味します。

伝播の場合、ポジティブ・ルール・セットに 1 つのスキーマ・ルールを含めると、スキーマに対する変更を含むソース・キュー内の行 LCR または DDL LCR を伝播することを意味します。ネガティブ・ルール・セットに含めると、スキーマに対する変更を含むソース・キュー内の行 LCR または DDL LCR を廃棄することを意味します。


� DBMS_STREAMS_ADMパッケージのプロシージャを使用して取得プロセスを作成し、取得プロセスの 1 つ以上のルールを生成する場合、変更が取得されるオブジェクトは自動的にインスタンス化用に準備されます。ただし、その取得プロセスがダウンストリーム取得プロセスで、ダウンストリーム・データベースからソース・データベースへのデータベース・リンクが存在しない場合は除きます。

� 取得プロセスは、一部の DML 変更や DDL 変更は取得せず、SYS、SYSTEMまたは SYSTEMスキーマ内で行われた変更も取得しません。


� 取得プロセスのルールおよびインスタンス化のための準備の詳細は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。

� 取得プロセスと、取得プロセスによって取得される DML 文およびDDL 文の詳細は、第 2 章「Streams の取得プロセス」を参照してください。

� 条件内の変数の詳細は、第 5 章「ルール」を参照してください。


� ポジティブ・ルール・セットを持たない取得プロセスを実行する方法については、6-4 ページの「ルール・セットとイベントのルール評価」を参照してください。



適用プロセスの場合、ポジティブ・ルール・セットに 1 つのスキーマ・ルールを含めると、スキーマに対する変更を含むキュー内の行 LCR または DDL LCR を適用することを意味します。ネガティブ・ルール・セットに含めると、スキーマに対する変更を含むキュー内の行LCR または DDL LCR を廃棄することを意味します。

スキーマ・ルールを使用する場合、Streams ではサポートされていないスキーマ内のデータベース・オブジェクトに対する変更を回避するには、DBMS_RULE_ADMパッケージを使用してルールを作成し、サポートされていない変更を廃棄します。

スキーマ・ルールの例スキーマ・ルールの例スキーマ・ルールの例スキーマ・ルールの例DBMS_STREAMS_ADMパッケージの ADD_SCHEMA_PROPAGATION_RULESプロシージャを使用し、Streams 伝播に対して、hrスキーマに関連する行 LCR および DDL LCR を、dbs1.netデータベースのキューから dbs2.netデータベースのキューに伝播させるように指示する場合を考えます。

dbs1.netで 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 => '[email protected]', include_dml => true, include_ddl => true, include_tagged_lcr => false, source_database => 'dbs1.net', inclusion_rule => true);END;/

inclusion_ruleパラメータが trueに設定されていることに注意してください。この設定によって、システム作成ルールが伝播のポジティブ・ルール・セットに追加されます。

ADD_SCHEMA_PROPAGATION_RULESプロシージャによって、行 LCR（DML 変更の結果を含む）用に 1 つと DDL LCR 用に 1 つ、合計 2 つのルールが作成されます。

行 LCR のルールで使用されるルール条件を次に示します。

((:dml.get_object_owner() = 'HR') and :dml.is_null_tag() = 'Y' and :dml.get_source_database_name() = 'DBS1.NET' )

参照参照参照参照 : 6-50 ページの「サポートされていない LCR を廃棄するようにStreams クライアントに指示するルール条件」




((: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.NET' )

DDL LCR のルールでは、GET_BASE_TABLE_OWNERメンバー・ファンクションが使用されます。これは、オブジェクトの所有者ではないユーザーがそのオブジェクトに対する DDL変更を行う場合、GET_OBJECT_OWNERファンクションが NULLを戻す場合があるためです。

次のリストに、これらのルールを伝播のポジティブ・ルール・セットで使用した場合に伝播される変更の例を示します。

� hr.countries表への 1 行の挿入

� hr.loc_city_ix索引の変更

� hr.employees表の切捨て

� hr.countries表への 1 列の追加

� hr.update_job_historyトリガーの変更

� hrスキーマ内での新規表 candidatesの作成

� hr.candidates表への 20 行の挿入

伝播では、前述のすべての変更を含む LCR が、ソース・キューから宛先キューに伝播されます。

ここで、同じルールを使用して、oe.inventories表に 1 行が挿入される場合を考えます。oeスキーマはスキーマ・ルールで指定されておらず、oe.inventories表は表ルールで指定されていないため、この変更は無視されます。

表ルール表ルール表ルール表ルールルールを使用して個々の表にのみ関連する Streams タスクを指定するときには、表ルールを指定します。特定の表に対する DML 変更に関する表ルール、DDL 変更に関する表ルールまたは各タイプの変更に関する 2 つのルールを指定できます。

取得プロセスの場合、ポジティブ・ルール・セットに 1 つの表ルールを含めると、表に対する DML 変更または DDL 変更の結果を取得することを意味します。ネガティブ・ルール・セットに含めると、表に対する DML 変更または DDL 変更の結果を廃棄することを意味します。

伝播の場合、ポジティブ・ルール・セットに 1 つの表ルールを含めると、表に対する変更を含むソース・キュー内の行 LCR または DDL LCR を伝播することを意味します。ネガティブ・ルール・セットに含めると、表に対する変更を含むソース・キュー内の行 LCR またはDDL LCR を廃棄することを意味します。

適用プロセスの場合、ポジティブ・ルール・セットに 1 つの表ルールを含めると、表に対する変更を含むキュー内の行 LCR または DDL LCR を適用することを意味します。ネガティ



ブ・ルール・セットに含めると、表に対する変更を含むキュー内の行 LCR または DDL LCRを廃棄することを意味します。

表ルールの例表ルールの例表ルールの例表ルールの例DBMS_STREAMS_ADMパッケージの ADD_TABLE_RULESプロシージャを使用し、Streams の適用プロセスの動作を次のように指示する場合を考えます。

� hr.locations 表に関連するすべての行 LCR の適用

� hr.countries 表に関連するすべての DDL LCR の適用

hr.locations 表に関連するすべての行表に関連するすべての行表に関連するすべての行表に関連するすべての行 LCR の適用の適用の適用の適用これらの行 LCR の変更が dbs1.netソース・データベースで発生したとします。

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.net', 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.NET' )

hr.countries 表に関連するすべての表に関連するすべての表に関連するすべての表に関連するすべての DDL LCR の適用の適用の適用の適用これらの DDL LCR の変更が dbs1.netソース・データベースで発生したとします。


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.net', inclusion_rule => true);END;/



(((: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.NET' )

DDL LCR のルールでは、GET_BASE_TABLE_OWNERおよび GET_BASE_TABLE_NAMEメンバー・ファンクションが使用されます。これは、オブジェクトの所有者ではないユーザーがそのオブジェクトに対する DDL 変更を行う場合、GET_OBJECT_OWNERおよびGET_OBJECT_NAMEファンクションが NULLを戻す場合があるためです。

ルールのまとめルールのまとめルールのまとめルールのまとめこの例では、次の表ルールを定義しました。

� 行 LCR に hr.locations表に対する DML 操作によって発生した行変更が含まれていると TRUEと評価される表ルール。

� DDL LCRにhr.countries表に対して実行されたDDL変更が含まれているとTRUEと評価される表ルール。

次のリストに、これらのルールを使用した場合に適用プロセスによって適用される変更の例を示します。

� hr.locations表への 1 行の挿入

� hr.locations表からの 5 行の削除

� hr.countries表への 1 列の追加

適用プロセスでは、関連付けられたキューからこれらの変更を含む LCR がデキューされ、接続先データベースのデータベース・オブジェクトに適用されます。



次のリストに、前述と同じルールを使用した場合に適用プロセスによって無視される変更の例を示します。

� hr.employees表への 1 行の挿入。hr.employees表に対する変更はどのルールも満たしていないため、この変更は適用されません。

� hr.countries表の 1 行の更新。これは、DDL 変更ではなく DML 変更です。hr.countries表のルールは DDL 変更のみを対象としているため、この変更は適用されません。

� hr.locations表への 1 列の追加。これは、DML 変更ではなく DDL 変更です。hr.locations表のルールは DML 変更のみを対象としているため、この変更は適用されません。

サブセット・ルールサブセット・ルールサブセット・ルールサブセット・ルールサブセット・ルールは DML 変更に関する特殊な表ルールです。ADD_SUBSET_RULESプロシージャを使用すると、取得プロセス、適用プロセスおよびメッセージ・クライアントのサブセット・ルールを作成できます。また、ADD_SUBSET_PROPAGATION_RULESプロシージャを使用すると、伝播のサブセット・ルールを作成できます。これらのプロシージャを使用すると、SELECT文の WHERE句と同様の条件によって次のように指定できます。

� 取得プロセスで、特定の表に対する DML 変更によって発生する行変更のサブセットのみを取得します。

� 伝播で、特定の表に関連する行 LCR のサブセットのみを伝播します。

� 適用プロセスで、特定の表に関連する行 LCR のサブセットのみを適用します。

� メッセージ・クライアントで、特定の表に関連する行 LCR のサブセットのみをデキューします。

ADD_SUBSET_RULESプロシージャおよび ADD_SUBSET_PROPAGATION_RULESプロシージャでは、Streams クライアントのポジティブ・ルール・セットにのみサブセット・ルールを追加できます。これらのプロシージャでは、Streams クライアントのネガティブ・ルール・セットにサブセット・ルールを追加できません。

ここでは、サブセット・ルールについて詳しく説明します。

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

� 行の移行とサブセット・ルール

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

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

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



サブセット・ルールの例サブセット・ルールの例サブセット・ルールの例サブセット・ルールの例次の例では、Streams の適用プロセスに対して、region_idが 2になっているhr.regions表に関連する行 LCR のサブセットを適用するように指示します。これらの変更が dbs1.netソース・データベースで発生したとします。

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.net');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.NET' 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 NOT EXISTS (SELECT 1 FROM SYS.DUAL WHERE (:dml.get_value('OLD','"REGION_ID"').AccessNumber()=2))))


� 1 つ以上の LOB 列、LONG列、LONG RAW列またはユーザー定義型の列を含む表に対するサブセット・ルールの作成は、サポートされていません。

� 取得プロセス、伝播およびメッセージ・クライアントのサブセット・ルールは Oracle Database 10g を実行中のデータベースでのみ指定できますが、適用プロセスのサブセット・ルールは Oracle9i リリース 2

（9.2）以上を実行中のデータベースで指定できます。



このルール条件に基づいて、行 LCR が次のように評価されます。

� 挿入の場合は、行 LCR 内で region_idの新規の値が 2であれば、挿入が適用されます。

� 挿入の場合は、行 LCR 内で region_idの新規の値が 2でないか、または NULLであれば、挿入がフィルタで除外されます。

� 更新の場合は、行 LCR 内で region_idの古い値が 2でないか、または NULLであり、新しい値が 2であれば、更新は挿入に変換されてから適用されます。この自動変換は、行の移行と呼ばれます。詳細は、6-24 ページの「行の移行とサブセット・ルール」を参照してください。

更新ルールで使用されるルール条件を次に示します。

:dml.get_object_owner()='HR' AND :dml.get_object_name()='REGIONS' AND :dml.is_null_tag()='Y' AND :dml.get_source_database_name()='DBS1.NET' 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 内で 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.NET' 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 NOT EXISTS (SELECT 1 FROM SYS.DUAL WHERE (:dml.get_value('NEW','"REGION_ID"').AccessNumber()=2))))


� 削除の場合は、行 LCR 内で region_idの古い値が 2であれば、削除が適用されます。

� 削除の場合は、行 LCR 内で region_idの古い値が 2でないか、または NULLであれば、削除はフィルタで除外されます。



� 更新の場合は、行 LCR 内で region_idの古い値が 2で、かつ、新規の値が 2以外の値または NULLであれば、更新は削除に変換されてから適用されます。この自動変換は、行の移行と呼ばれます。詳細は、6-24 ページの「行の移行とサブセット・ルール」を参照してください。

次のリストに、これらのサブセット・ルールを使用した場合に適用プロセスによって適用される変更の例を示します。

� hr.regions表の 1 行の更新。この場合、region_idの古い値は 4で、region_idの新規の値は 2です。この更新は挿入に変換されます。

� hr.regions表の 1 行の更新。この場合、region_idの古い値は 2で、region_idの新規の値は 1です。この更新は削除に変換されます。

適用プロセスでは、関連付けられたキューからこれらの変更を含む行 LCR がデキューされ、接続先データベースの hr.regions表に適用されます。

次のリストに、前述と同じサブセット・ルールを使用した場合に適用プロセスによって無視される変更の例を示します。

� hr.employees表への 1 行の挿入。hr.employees表に対する変更はサブセット・ルールを満たしていないため、この変更は適用されません。

� hr.regions表の 1 行の更新。この場合、更新前の region_idは 1で、更新後も 1のままです。hr.regions表のサブセット・ルールが TRUEと評価されるのは、region_idの新旧いずれか（またはその両方）の値が 2の場合のみであるため、この変更は適用されません。

行の移行とサブセット・ルール行の移行とサブセット・ルール行の移行とサブセット・ルール行の移行とサブセット・ルールサブセット・ルールを使用すると、更新操作が、取得、伝播、適用またはデキューされるときに挿入操作または削除操作に変換されることがあります。この自動変換は行の移行行の移行行の移行行の移行と呼ばれ、サブセット・ルールのアクション・コンテキストで自動的に指定された内部変換によって実行されます。ここでは、取得、伝播、適用およびデキュー中の行の移行について説明します。

注意注意注意注意 : サブセット・ルールはポジティブ・ルール・セットにのみ存在する必要があります。ネガティブ・ルール・セットにはサブセット・ルールを追加しないでください。ネガティブ・ルール・セットで廃棄されないLCR では行の移行が行われないため、予測できない結果が発生する可能性があります。また、ネガティブ・ルール・セットで TRUEと評価されたために廃棄される LCR でも、行の移行は行われません。



取得中の行の移行取得中の行の移行取得中の行の移行取得中の行の移行サブセット・ルールが取得プロセスのルール・セットにある場合、サブセット・ルールを満たす更新は、取得時に挿入または削除に変換されることがあります。

たとえば、サブセット・ルールを使用してサブセット条件 department_id = 50を指定し、従業員の department_idが 50の場合に、hr.employees表に対する変更を取得プロセスで取得するように指定する場合を考えます。ソース・データベースの表に、すべての部門の従業員のレコードが含まれていると想定します。DML 操作によって従業員のdepartment_idが 80から 50に変更される場合、このサブセット・ルールを持つ取得プロセスは更新操作を挿入操作に変換し、変更を取得します。したがって、INSERTを含む行LCR が取得プロセスのキューにエンキューされます。この例は、図 6-2 を参照してください。

図図図図 6-2 取得中の行の移行取得中の行の移行取得中の行の移行取得中の行の移行

同様に、取得された更新によって従業員の department_idが 50から 20に変更される場合、このサブセット・ルールを持つ取得プロセスは更新操作を DELETE操作に変換します。



伝播中の行の移行伝播中の行の移行伝播中の行の移行伝播中の行の移行サブセット・ルールが伝播のルール・セットにある場合、更新操作は、行 LCR の伝播時に挿入または削除操作に変換されることがあります。

たとえば、サブセット・ルールを使用してサブセット条件 department_id = 50を指定し、従業員の department_idが 50の場合に、hr.employees表に対する変更を伝播で伝播するように指定する場合を考えます。伝播のソース・キューが更新操作を伴う行 LCR を含み、その更新操作によって hr.employees表の従業員の department_idが 50から 80に変更される場合、このサブセット・ルールを持つ伝播は更新操作を削除操作に変換し、行LCR を宛先キューに伝播します。したがって、DELETEを含む行 LCR が宛先キューにエンキューされます。この例は、図 6-3 を参照してください。

図図図図 6-3 伝播中の行の移行伝播中の行の移行伝播中の行の移行伝播中の行の移行



同様に、取得された更新によって従業員の department_idが 80から 50に変更される場合、このサブセット・ルールを持つ伝播は更新操作を INSERT操作に変換します。

適用中の行の移行適用中の行の移行適用中の行の移行適用中の行の移行サブセット・ルールが適用プロセスのルール・セットにある場合、更新操作は、行 LCR の適用時に挿入または削除操作に変換されることがあります。

たとえば、サブセット・ルールを使用してサブセット条件 department_id = 50を指定し、従業員の department_idが 50の場合に、hr.employees表に対する変更を適用プロセスで適用するように指定する場合を考えます。接続先データベースの表が、department_idが 50である従業員のレコードのみが含まれるサブセット表であると想定します。ソース・データベースが従業員に対する変更を取得し、それが従業員のdepartment_idを 80から 50に変更するというものであれば、接続先データベースにサブセット・ルールを持つ適用プロセスは、更新操作を挿入操作に変換してこの変更を適用します。この変換が必要となるのは、従業員の行が宛先の表に存在しないためです。この例は、図 6-4 を参照してください。

図図図図 6-4 適用中の行の移行適用中の行の移行適用中の行の移行適用中の行の移行



同様に、取得された更新によって従業員の department_idが 50から 20に変更される場合、このサブセット・ルールを持つ適用プロセスは更新操作を DELETE操作に変換します。

メッセージ・クライアントによるデキュー中の行の移行メッセージ・クライアントによるデキュー中の行の移行メッセージ・クライアントによるデキュー中の行の移行メッセージ・クライアントによるデキュー中の行の移行サブセット・ルールがメッセージ・クライアントのルール・セットにある場合、更新操作は、行 LCR のデキュー時に挿入または削除操作に変換されることがあります。

たとえば、サブセット・ルールを使用してサブセット条件 department_id = 50を指定し、従業員の department_idが 50の場合にメッセージ・クライアントで変更をhr.employees表にデキューするように指定する場合を考えます。メッセージ・クライアントのキューが更新操作を伴うユーザー・エンキュー行 LCR を含み、その更新操作によって hr.employees表の従業員の department_idが 50から 90に変更される場合、ユーザーまたはアプリケーションがこのサブセット・ルールを持つメッセージ・クライアントを起動すると、メッセージ・クライアントは更新操作を削除操作に変換し、行 LCR をデキューします。したがって、DELETEを含む行 LCR がデキューされます。メッセージ・クライアントではこの行 LCR をカスタマイズされた方法で処理できます。たとえば、行 LCR をカスタム・アプリケーションに送信できます。この例は、図 6-5 を参照してください。

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



同様に、ユーザー・エンキュー行 LCR に含まれる更新によって従業員の department_idが 90から 50に変更される場合、このサブセット・ルールを持つメッセージ・クライアントは、デキュー中に UPDATE操作を INSERT操作に変換します。

サブセット・ルールとサプリメンタル・ロギングサブセット・ルールとサプリメンタル・ロギングサブセット・ルールとサプリメンタル・ロギングサブセット・ルールとサプリメンタル・ロギング取得、伝播または適用のために表のサブセット・ルールを指定する場合は、サブセット条件に含まれるすべての列と、これらの変更を適用する接続先データベースにある表のすべての列について、ソース・データベースで無条件のサプリメンタル・ログ・グループを指定する必要があります。場合によっては、サブセット・ルールを指定すると、更新が挿入に変換される場合があり、この場合は一部またはすべての列に補足情報が必要になることがあります。

たとえば、データベース dbs2.net上で hr.locations表の postal_code列に対する適用プロセスのサブセット・ルールを指定し、さらにこの表に対する変更のソース・データベースが dbs1.netの場合は、dbs2.netの hr.locations表に存在するすべての列、および postal_code列（この列が接続先データベースの表に存在しない場合も含む）について、dbs1.netのサプリメンタル・ロギングを指定します。

サブセット・ルールを使用する際のガイドラインサブセット・ルールを使用する際のガイドラインサブセット・ルールを使用する際のガイドラインサブセット・ルールを使用する際のガイドラインここでは、サブセット・ルールを使用する際のガイドラインについて説明します。

� 取得のサブセット・ルールの使用（すべての接続先で変更のサブセットのみが必要な場合）

� 伝播または適用のサブセット・ルールの使用（サブセットを必要とする接続先がある場合）

� サブセットの行 LCR が適用される表がサブセット表であることの確認

取得のサブセット・ルールの使用（すべての接続先で変更のサブセットのみが必要な場合）取得のサブセット・ルールの使用（すべての接続先で変更のサブセットのみが必要な場合）取得のサブセット・ルールの使用（すべての接続先で変更のサブセットのみが必要な場合）取得のサブセット・ルールの使用（すべての接続先で変更のサブセットのみが必要な場合）取得プロセスのすべての接続先データベースで、表のサブセット条件を満たす行変更のみが必要な場合、取得プロセスでサブセット・ルールを使用する必要があります。この場合、取得プロセスは表に対する DML 変更のサブセットを取得し、1 つ以上の伝播がこれらの変更を行 LCR の形式で 1 つ以上の接続先データベースに伝播します。各接続先データベースでは、適用プロセスで、すべての行が取得プロセスのサブセット・ルールのサブセット条件を満たしているサブセット表にこれらの行 LCR が適用されます。表に対して行われるすべての DML 変更が必要な接続先データベースは存在しません。ローカルの取得プロセスのサブセット・ルールを使用する場合、ソース・データベースを実行しているサイトでは、行の移行を行うときにオーバーヘッドが増加します。

参照参照参照参照 : サプリメンタル・ロギングの詳細は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。



伝播または適用のサブセット・ルールの使用（サブセットを必要とする接続先がある場合）伝播または適用のサブセット・ルールの使用（サブセットを必要とする接続先がある場合）伝播または適用のサブセット・ルールの使用（サブセットを必要とする接続先がある場合）伝播または適用のサブセット・ルールの使用（サブセットを必要とする接続先がある場合）環境に、取得される DML 変更のサブセットのみを必要とする接続先がある場合、伝播または適用プロセスでサブセット・ルールを使用する必要があります。次にこのような環境の例を示します。

� 表に対する DML 変更が取得される接続先データベースのほとんどで、これらの変更の別のサブセットが必要な場合

� 表に対する DML 変更のうち、ほとんどの接続先データベースでは取得されたすべての変更が必要だが、一部の接続先データベースではこれらの変更のサブセットのみが必要な場合

このような環境では、取得プロセスによって表に対する変更をすべて取得する必要があります。ただし、伝播および適用プロセスでサブセット・ルールを使用すると、接続先データベースのサブセット表が、取得された DML 変更の正しいサブセットのみを適用できます。

このような環境で伝播にサブセット・ルールを使用する場合、次の要素を考えます。

� ネットワークを介して伝播される行 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を持つ従業員の行を挿入すると、この行は表に残り、適用プロセスでは削除されません。同様に、ユーザーまたはアプリケーションが 1 行をローカルに更新して department_idを 30に変更した場合、この行も表に残ります。

サブセット・ルールの制限サブセット・ルールの制限サブセット・ルールの制限サブセット・ルールの制限取得プロセス、伝播、適用プロセスまたはメッセージ・クライアントのポジティブ・ルール・セットに含まれるサブセット・ルールには、次の制限が適用されます。

� サブセット・ルールで参照される表名を持つ表は、サブセット・ルールと同じデータベースに存在する必要があります。また、この表は、サブセット・ルールの表に関して参照されるスキーマと同じスキーマに存在する必要があります。

� サブセット・ルールが取得プロセスのポジティブ・ルール・セットにある場合、表には、ルールのサブセット条件で指定した列が含まれている必要があります。これらの各列のデータ型はソース・データベースの対応する列のデータ型と一致する必要があります。

� サブセット・ルールが伝播または適用プロセスのポジティブ・ルール・セットに含まれる場合、表には、ルールのサブセット条件で指定した列が含まれている必要があります。各列のデータ型は、サブセット・ルールで TRUEと評価された行 LCR の対応する列のデータ型と一致する必要があります。

メッセージ・ルールメッセージ・ルールメッセージ・ルールメッセージ・ルールルールを使用して、特定のメッセージ型のユーザー・エンキュー・イベントにのみ関連するStreams タスクを指定するときには、メッセージ・ルールを指定します。メッセージ・ルールは、伝播、適用プロセスおよびメッセージ・クライアントに指定できます。

伝播の場合、ポジティブ・ルール・セットに 1 つのメッセージ・ルールを含めると、ルール条件を満たすソース・キュー内のメッセージ型のユーザー・エンキュー・イベントが伝播されます。ネガティブ・ルール・セットに含めると、ルール条件を満たすソース・キュー内のメッセージ型のユーザー・エンキュー・イベントが廃棄されます。



適用プロセスの場合、ポジティブ・ルール・セットに 1 つのメッセージ・ルールを含めると、ルール条件を満たすメッセージ型のユーザー・エンキュー・イベントがデキューされます。これらのユーザー・エンキュー・イベントは適用プロセスのメッセージ・ハンドラに送信されます。ネガティブ・ルール・セットに含めると、ルール条件を満たすキュー内のメッセージ型のユーザー・エンキュー・イベントが廃棄されます。

メッセージ・クライアントの場合、ポジティブ・ルール・セットに 1 つのメッセージ・ルールを含めると、ユーザーまたはアプリケーションがメッセージ・クライアントを使用して、ルール条件を満たすメッセージ型のユーザー・エンキュー・イベントをデキューできます。ネガティブ・ルール・セットに含めると、ルール条件を満たすキュー内のメッセージ型のユーザー・エンキュー・イベントが廃棄されます。伝播および適用プロセスでは実行時にイベントが自動的に伝播または適用されるのに対して、メッセージ・クライアントではイベントは自動的にデキューまたは廃棄されません。かわりに、ユーザーまたはアプリケーションがメッセージ・クライアントを使用して、イベントをデキューまたは廃棄する必要があります。

メッセージ・ルールの例メッセージ・ルールの例メッセージ・ルールの例メッセージ・ルールの例DBMS_STREAMS_ADMパッケージの ADD_MESSAGE_RULEプロシージャを使用し、Streamsクライアントの動作を次のように指示する場合を考えます。

� 地域が EUROPE で優先度が 1 の場合におけるユーザー・エンキュー・イベントのデキュー

� 地域が AMERICAS で優先度が 2 の場合におけるメッセージ・ハンドラへのユーザー・エンキュー・イベントの送信

前述の初の方法はメッセージ・クライアントに関連し、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$で始まる変数は、ルールのシステム生成評価コンテキストで指定される変数です。

地域が地域が地域が地域が 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に設定されていることにも注意してください。この設定によって、システム作成ルールがメッセージ・クライアントのポジティブ・ルール・セットに追加されます。

参照参照参照参照 : 6-40 ページの「Streams で使用される評価コンテキスト」



ADD_MESSAGE_RULEプロシージャでは、次のようなルール条件を持つルールが作成されます。

:"VAR$_56".region = 'AMERICAS' AND :"VAR$_56".priority = '2'

ルール条件内の VAR$で始まる変数は、ルールのシステム生成評価コンテキストで指定される変数です。

ルールのまとめルールのまとめルールのまとめルールのまとめこの例では、次のメッセージ・ルールを定義しました。

� メッセージの地域が EUROPE、優先度が 1の場合に TRUEと評価される、メッセージ・クライアント msg_clientのメッセージ・ルール。このルールが存在する場合、ユーザーまたはアプリケーションはメッセージ・クライアントを使用して、ルール条件を満たす region_pri_msg型のメッセージをデキューできます。

� メッセージの地域が AMERICAS、優先度が 2の場合に TRUEと評価される、適用プロセス apply_msgのメッセージ・ルール。このルールが存在する場合、適用プロセスはルール条件を満たす region_pri_msg型のメッセージをデキューし、これらのメッセージをメッセージ・ハンドラに送信するか、または指定のキューに再エンキューします。

システム作成ルールとネガティブ・ルール・セットシステム作成ルールとネガティブ・ルール・セットシステム作成ルールとネガティブ・ルール・セットシステム作成ルールとネガティブ・ルール・セットシステム作成ルールをネガティブ・ルール・セットに追加すると、Streams クライアントがそれらのルールを満たす変更に対してタスクを実行しないように指定できます。特に、システム作成ルールがネガティブ・ルール・セットに含まれる場合、各タイプの Streams クライアントは次のように動作します。

� 取得プロセスでは、ルールを満たす変更が廃棄されます。

� 伝播では、ルールを満たすソース・キュー内のイベントが廃棄されます。

� 適用プロセスでは、ルールを満たすキュー内のイベントが廃棄されます。

� メッセージ・クライアントでは、ルールを満たすキュー内のイベントが廃棄されます。

参照参照参照参照 : 6-40 ページの「Streams で使用される評価コンテキスト」


� 4-7 ページの「LCR 以外のユーザー・メッセージの処理」

� 6-46 ページの「適用時のイベントのエンキューの宛先」



Streams クライアントにネガティブ・ルール・セットが存在しない場合は、次のいずれかのプロシージャを実行して inclusion_ruleパラメータを falseに設定すると、ネガティブ・ルール・セットを作成してルールを追加できます。





� 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

Streams クライアントにネガティブ・ルール・セットがすでに存在している場合に、これらのいずれかのプロシージャを実行すると、既存のネガティブ・ルール・セットにシステム作成ルールが追加されます。

また、次のいずれかのプロシージャを実行し、negative_rule_set_nameパラメータにNULL以外の値を指定することで、Streams クライアントの作成時にネガティブ・ルール・セットを作成することもできます。

� DBMS_CAPTURE_ADM.CREATE_CAPTURE

� DBMS_PROPAGATION_ADM.CREATE_PROPAGATION

� DBMS_APPLY_ADM.CREATE_APPLY

また、クライアントを変更することで、既存の Streams クライアントにネガティブ・ルール・セットを指定することもできます。たとえば、既存の取得プロセスにネガティブ・ルール・セットを指定するには、DBMS_CAPTURE_ADM.ALTER_CAPTUREプロシージャを使用します。Streams クライアントにネガティブ・ルール・セットを指定した後、前述のDBMS_STREAM_ADMパッケージのプロシージャを使用して、ネガティブ・ルール・セットにシステム作成ルールを追加できます。

ネガティブ・ルール・セットにルールを追加するかわりに、次のような方法で特定の表またはスキーマに対する変更を除外することもできます。

� 表またはスキーマのシステム作成ルールを、Streams クライアントのポジティブ・ルール・セットに追加しないようにします。たとえば、1 つの表を除き、特定のスキーマに存在するすべての表に対する DML 変更を取得するには、除外する表以外のスキーマの各表に対する DML 表ルールを、取得プロセスのポジティブ・ルール・セットに追加します。この方法のデメリットは、スキーマには多くの表が存在する場合があり、その各表に個別の DML ルールが必要であるという点です。また、スキーマに新規の表を追加して、その表に対する変更を取得する場合、この表用の新規 DML ルールを取得プロセスのポジティブ・ルール・セットに追加する必要があります。



� 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 を適用するように、Streams の適用プロセスに指示します。この場合、プロシージャによってスキーマ・ルールが作成され、適用プロセスのポジティブ・ルール・セットにルールが追加されます。

DBMS_STREAMS_ADMパッケージの ADD_TABLE_RULESプロシージャを使用して、hr.job_history表に対する DML 変更の結果を含む行 LCR を廃棄するように、Streamsの適用プロセスに指示できます。この場合、プロシージャによって表ルールが作成され、適用プロセスのネガティブ・ルール・セットにルールが追加されます。



� and_conditionパラメータの詳細は、6-39 ページの「システム作成ルールへのユーザー定義条件の追加」を参照してください。



ここでは、これらのプロシージャの実行方法について説明します。

� hr スキーマの表に対するすべての DML 変更の適用

� hr.job_history 表に対する DML 変更を含む行 LCR の廃棄

hr スキーマの表に対するすべてのスキーマの表に対するすべてのスキーマの表に対するすべてのスキーマの表に対するすべての DML 変更の適用変更の適用変更の適用変更の適用これらの変更が dbs1.netソース・データベースで発生したとします。

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.net', inclusion_rule => true);END;/


ADD_SCHEMA_RULESプロシージャでは、次のようなルール条件を持つルールが作成されます。

((:dml.get_object_owner() = 'HR') and :dml.is_null_tag() = 'Y' and :dml.get_source_database_name() = 'DBS1.NET' )

hr.job_history 表に対する表に対する表に対する表に対する DML 変更を含む行変更を含む行変更を含む行変更を含む行 LCR の廃棄の廃棄の廃棄の廃棄これらの変更が dbs1.netソース・データベースで発生したとします。


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.net', inclusion_rule => false);END;/

inclusion_ruleパラメータが falseに設定されていることに注意してください。この設定によって、システム作成ルールが適用プロセスのネガティブ・ルール・セットに追加されます。

また、include_tagged_lcrパラメータが trueに設定されていることにも注意してください。この設定によって、表に対するすべての変更（他のすべてのルール条件を満たすタグ付き LCR を含む）が廃棄されます。ほとんどの場合、inclusion_ruleパラメータがfalseに設定されているときは、include_tagged_lcrパラメータを trueに指定します。


(((:dml.get_object_owner() = 'HR' and :dml.get_object_name() = 'JOB_HISTORY')) and :dml.get_source_database_name() = 'DBS1.NET' )

ルールのまとめルールのまとめルールのまとめルールのまとめこの例では、次のルールを定義しました。

� 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.net、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.net', 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.NET' )) 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.NET' )) and (:ddl.get_tag() = HEXTORAW('02')))

指定した条件の :lcrが、生成中のルールによって、:dmlまたは :ddlに変換されることに注意してください。LCR タイプ（行または DDL）に依存する LCR メンバー・サブプログラムを指定している場合は、このプロシージャによって適切なルールのみが生成されている

参照参照参照参照 : 「ルール・セットとイベントのルール評価」6-4 ページ


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

ことを確認します。特に、行 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に指定します。

Streams で使用される評価コンテキストで使用される評価コンテキストで使用される評価コンテキストで使用される評価コンテキストこの項では、Streams で使用されるシステム作成評価コンテキストについて説明します。

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

グローバル・ルール、スキーマ・ルール、表ルールおよびサブセット・ルールを作成する際、システム作成のルール・セットおよびルールでは、SYSスキーマ内のSTREAMS$_EVALUATION_CONTEXTという組込み評価コンテキストが使用されます。PUBLICには、この評価コンテキストの EXECUTE権限が付与されます。グローバル・ルール、スキーマ・ルール、表ルールおよびサブセット・ルールは、取得プロセス、伝播、適用プロセスおよびメッセージ・クライアントで使用できます。

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')); DBMS_RULE_ADM.CREATE_EVALUATION_CONTEXT( evaluation_context_name => 'SYS.STREAMS$_EVALUATION_CONTEXT',


� LCR メンバー・サブプログラムの詳細は、『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。




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

ROW_VARIABLE_VALUE_FUNCTIONでは、SYS.LCR$_ROW_RECORDインスタンスをカプセル化する SYS.AnyDataペイロードが SYS.LCR$_ROW_RECORDインスタンスに変換されてから、データに対するルールが評価されます。

DDL_VARIABLE_VALUE_FUNCTIONでは、SYS.LCR$_DDL_RECORDインスタンスをカプセル化する SYS.AnyDataペイロードが SYS.LCR$_DDL_RECORDインスタンスに変換されてから、データに対するルールが評価されます。

EVALUATION_CONTEXT_FUNCTIONは、CREATE_EVALUATION_CONTEXTプロシージャのコールで evaluation_functionとして指定されます。このファンクションによって、取得イベントの通常のルール評価が補足されます。取得プロセスは行 LCR と DDL LCR をキューにエンキューし、このファンクションによって、コミット、ロールバック、データ・ディクショナリ変更などの他の内部イベントのエンキューが可能になります。この情報は、伝播や適用プロセスのルール評価中にも使用されます。

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

DBMS_STREAMS_ADMパッケージを使用して作成したルールでは、ADD_SUBSET_RULESまたは ADD_SUBSET_PROPAGATION_RULESプロシージャを使用して作成したサブセット・ルールの場合を除き、ROW_FAST_EVALUATION_FUNCTIONまたはDDL_FAST_EVALUATION_FUNCTIONが使用されます。

メッセージ・ルールの評価コンテキストメッセージ・ルールの評価コンテキストメッセージ・ルールの評価コンテキストメッセージ・ルールの評価コンテキストADD_MESSAGE_RULEまたは ADD_MESSAGE_PROPAGATION_RULEプロシージャを使用してメッセージ・ルールを作成する場合は、ルールの作成時に指定したユーザー定義のメッセージ型が使用されます。このようなシステム作成メッセージ・ルールでは、システム作成評価コンテキストが使用されます。システム作成評価コンテキスト名は、メッセージ・ルールの作成に使用されるメッセージ型によって異なります。このような評価コンテキストはシステム生成名を持ち、ルールを所有するスキーマ内で作成されます。評価コンテキストを所有するユーザーにのみ、それに対する EXECUTE権限が付与されます。

注意注意注意注意 : 前述の内部ファンクションに関する情報は、あくまでも参考用です。これらのファンクションは直接実行しないでください。

参照参照参照参照 : LCR とそのメンバー・ファンクションの詳細は、『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。



このタイプのメッセージ・ルールの評価コンテキストには、メッセージ型と同じ型の変数が含まれます。この変数の名前は 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内部ファンクションの参照も含まれています。このファンクションでは、メッセージ・インスタンスをカプセル化する SYS.AnyDataペイロードが変数と同じ型のインスタンスに変換されてから、データに対するルールが評価されます。たとえば、変数の型が strmadmin.region_pri_msgである場合、


Streams とイベント・コンテキスト

MSG_VARIABLE_VALUE_FUNCTIONでは、メッセージ・ペイロードが SYS.AnyDataペイロードから strmadmin.region_pri_msgペイロードに変換されます。

異なるメッセージ型のルールを作成する場合、Oracle では、それぞれのメッセージ型で異なる評価コンテキストが作成されます。既存のルールと同じメッセージ型の新規ルールを作成する場合、新規ルールでは既存のルールの評価コンテキストが使用されます。また、ADD_MESSAGE_RULEまたは ADD_MESSAGE_PROPAGATION_RULEによってメッセージ・クライアントまたは適用プロセスのルール・セットを作成する場合、新規のルール・セットは評価コンテキストを持ちません。

Streams とイベント・コンテキストとイベント・コンテキストとイベント・コンテキストとイベント・コンテキストStreams において、取得プロセスとメッセージ・クライアントではイベント・コンテキストは使用されませんが、伝播と適用プロセスでは使用されます。取得イベントとユーザー・エンキュー・イベントの両方がキュー内でステージングされます。イベントがキュー内でステージングされると、伝播または適用プロセスでは、イベントとイベント・コンテキストを評価のためにルール・エンジンへ送信可能となります。イベント・コンテキストは常に次の名前 / 値ペアを持ちます。この場合、AQ$_MESSAGEが名前で、Streams イベント自体が値です。

カスタム評価コンテキストを作成すると、暗黙的変数を使用して、Streams イベントを参照する伝播と適用プロセス・ルールを作成できます。各暗黙的変数に対する変数値のファンクションでは、AQ$_MESSAGEという名前のイベント・コンテキストをチェックできます。この名前と一致するイベント・コンテキストが検出されると、変数値のファンクションからイベント自体に基づいて値が戻されます。イベント・コンテキストは、評価ファンクションと変数メソッド・ファンクションにも渡すことができます。


� 6-31 ページの「メッセージ・ルール」

� 6-40 ページの「グローバル・ルール、スキーマ・ルール、表ルールおよびサブセット・ルールの評価コンテキスト」


� イベント・コンテキストの詳細は、5-11 ページの「ルール・セットの評価」を参照してください。

� 変数値のファンクションの詳細は、5-6 ページの「明示的変数と暗黙的変数」を参照してください。

� 5-8 ページの「評価ファンクション」


Streams とアクション・コンテキスト

Streams とアクション・コンテキストとアクション・コンテキストとアクション・コンテキストとアクション・コンテキストここでは、Streams でのアクション・コンテキストの用途と、特定のルール条件についてTRUEと評価できるルールがルール・セット内に 1 つのみであることの重要性について説明します。

Streams でのアクション・コンテキストの用途でのアクション・コンテキストの用途でのアクション・コンテキストの用途でのアクション・コンテキストの用途Streams でのアクション・コンテキストの用途は、次のとおりです。

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

� ユーザー定義のルールベースの変換

� 適用時のイベントのエンキューの宛先

� 適用時のイベントの実行ディレクティブ

それぞれの用途に対し、ルールのアクション・コンテキストには異なる名前 / 値ペアが存在する場合があります。ルールのアクション・コンテキストに複数の名前 / 値ペアが含まれる場合、名前 / 値ペアで指定されたアクションは、次の順序で実行されます。

1. サブセットの変換を実行します。

2. ユーザー定義のルールベースの変換を実行します。

3. 実行ディレクティブに従います。実行ディレクティブで実行が指示されている場合は、指示を実行します（適用のみ）。

4. 宛先キューにエンキューします（適用のみ）。

サブセット・ルール内部のサブセット・ルール内部のサブセット・ルール内部のサブセット・ルール内部の LCR 変換変換変換変換サブセット・ルールを使用すると、更新操作が、取得、伝播、適用またはデキューされるときに挿入操作または削除操作に変換されることがあります。この自動変換は行の移行と呼ばれ、サブセット・ルールが TRUEと評価されたときに、サブセット・ルールのアクション・コンテキストで指定された内部変換によって実行されます。サブセットの変換に関する名前/ 値ペアでは、STREAMS$_ROW_SUBSETが名前で、INSERTまたは DELETEのいずれかが値となります。

注意注意注意注意 : ルールのアクション・コンテキストで指定されたアクションは、ルールが取得プロセス、伝播、適用プロセスまたはメッセージ・クライアントのポジティブ・ルール・セットに含まれる場合にのみ実行されます。ルールがネガティブ・ルール・セットに含まれる場合、これらの 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と評価される


� 6-21 ページの「サブセット・ルール」

� サブセット・ルールでルールベースの変換を使用する方法については、12-16 ページの「ルールベースの変換の管理」を参照してください。




参照参照参照参照 : 11-21 ページの「適用プロセスの実行ディレクティブの指定」

参照参照参照参照 : 11-19 ページの「適用プロセスによるイベントのエンキューの指定」



場合も、戻されるルールは 1 つのみであり、これによって予測できない結果が発生する可能性があります。

たとえば、2 つのルールがあり、どちらも hr.employees表に対する DML 変更が LCR に含まれている場合に TRUEと評価されるとします。初のルールには NULLアクション・コンテキストがあります。第 2 のルールには、ルールベースの変換を指定するアクション・コンテキストがあります。hr.employees表に対する DML 変更があると、どちらのルールも変更について TRUEと評価されますが、戻されるルールは 1 つのみです。この場合、どちらのルールが戻されるかに応じて、変換が発生する場合と発生しない場合があります。

いずれかのルールに NULL以外のアクション・コンテキストがあるかどうかに関係なく、TRUEと評価できるルールがどの条件についてもポジティブ・ルール・セット内で 1 つのみになるようにする必要があります。このガイドラインに従うと、NULL以外のアクション・コンテキストが将来ルールに追加される場合なども、予測できない結果を回避できます。

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

スキーマ・ルールまたはグローバル・ルールに、ルールベースの変換、エンキューの宛先、または実行ディレクティブのためのアクション・コンテキストを使用する場合、アクション・コンテキストによって指定されたアクションは、イベントでスキーマ・ルールまたはグローバル・ルールが trueと評価された場合にのみ、イベントに対して実行されます。たとえば、ルールベースの変換を指定するアクション・コンテキストがスキーマ・ルールに存在する場合、スキーマ内の表の LCR が変換されます。

スキーマ・ルールまたはグローバル・ルールにアクション・コンテキストを使用するが、アクション・コンテキストによって実行されるアクションから LCR のサブセットを除外する場合があります。たとえば、hrスキーマ内の job_history表を除くすべての表に対してルールベースの変換を実行する場合は、表が job_historyの場合に変換ファンクションが元の LCR を戻すことを確認します。

hrスキーマ内の job_history表を除くすべての表にエンキューの宛先または実行ディレクティブを設定する場合は、スキーマ・ルールを使用して、次の条件を追加できます。

:dml.get_object_name() != 'JOB_HISTORY'

この場合、job_history表の LCR が trueと評価されても、エンキューの宛先または実行ディレクティブを実行しない場合は、表ルールをポジティブ・ルール・セットに追加できます。つまり、スキーマ・ルールはエンキューの宛先または実行ディレクティブを所有できますが、表ルールは所有できません。


参照参照参照参照 : スキーマ・ルールとグローバル・ルールの詳細は、6-6 ページの「システム作成ルール」を参照してください。


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

ユーザー作成ルール、ルール・セットおよび評価コンテキストユーザー作成ルール、ルール・セットおよび評価コンテキストユーザー作成ルール、ルール・セットおよび評価コンテキストユーザー作成ルール、ルール・セットおよび評価コンテキストDBMS_STREAMS_ADMパッケージでは、システム作成ルールおよびルール・セットが生成されます。また、ルールおよびルール・セットに対し、Oracle が提供する評価コンテキストが指定されるか、システム作成評価コンテキストが生成されます。DBMS_STREAMS_ADMパッケージでは作成できないルール、ルール・セットまたは評価コンテキストを作成する必要がある場合、DBMS_RULE_ADMパッケージを使用してそれらを作成できます。

次のような場合に、DBMS_RULE_ADMパッケージの使用が必要になることがあります。

� 特定タイプの操作に関するルール条件や、LIKE条件を使用するルール条件など、DBMS_STREAMS_ADMパッケージでは作成できないルール条件を持つルールを作成する必要がある場合。

� Streams 環境でルールのカスタム評価コンテキストを作成する必要がある場合。

DBMS_RULE_ADMパッケージを使用してルール・セットを作成し、それを取得プロセス、伝播、適用プロセスまたはメッセージ・クライアントに関連付けることができます。このようなルール・セットは、Streams クライアントのポジティブ・ルール・セットまたはネガティブ・ルール・セットで使用できます。また、1 つのルール・セットを、1 つの Streams クライアントのポジティブ・ルール・セットと別の Streams クライアントのネガティブ・ルール・セットで使用することもできます。


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

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

ユーザー作成ルールとルール・セットユーザー作成ルールとルール・セットユーザー作成ルールとルール・セットユーザー作成ルールとルール・セットここでは、DBMS_RULE_ADMパッケージを使用して作成可能なルールおよびルール・セットのタイプについて説明します。

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

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

� 複合ルール条件

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


� 9-26 ページの「取得プロセスのルール・セットの指定」

� 10-13 ページの「伝播のルール・セットの指定」

� 11-10 ページの「適用プロセスのルール・セットの指定」



� :dml および :ddl 変数をルール条件のファンクション・パラメータとして使用することの回避

特定タイプの操作に関するルール条件特定タイプの操作に関するルール条件特定タイプの操作に関するルール条件特定タイプの操作に関するルール条件特定タイプの操作のみを含む変更の取得、伝播、適用またはデキューが必要になることがあります。たとえば、特定の表に対する挿入操作のみを含み、更新や削除などの他の操作を含まない変更を適用する場合などです。

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パッケージの一部のプロシージャで使用可能な and_conditionパラメータを使用して、ユーザー定義条件をシステム作成ルールに追加できます。DBMS_RULE_ADMパッケージでルールを作成するよりも、and_conditionパラメータを使用する方が簡単です。

参照参照参照参照 : and_conditionパラメータの詳細は、6-39 ページの「システム作成ルールへのユーザー定義条件の追加」を参照してください。



前述の例のルール条件はすべて単純ルール条件です。ただし、カスタム条件をシステム作成条件に追加する場合、条件全体は単純ルール条件ではなく、単純ルールでないルールは効率的に評価されません。通常、ルール評価のパフォーマンスを改善するために、可能な場合は常に単純ルール条件を使用する必要があります。DBMS_STREAMS_ADMパッケージを使用して作成され、カスタム条件が追加されていない条件は常に単純です。

サポートされていないサポートされていないサポートされていないサポートされていない LCR を廃棄するようにを廃棄するようにを廃棄するようにを廃棄するように Streams クライアントに指クライアントに指クライアントに指クライアントに指示するルール条件示するルール条件示するルール条件示するルール条件サポートされていない変更をカプセル化する LCR を廃棄するように Streams クライアントに指示するには、ルール条件で次のファンクションを使用できます。

� LCR 用の GET_COMPATIBLEメンバー・ファンクション。このファンクションは、LCRをサポートするために必要なデータベースの小互換レベルを戻します。

� DBMS_STREAMSパッケージの COMPATIBLE_9_2ファンクションおよびCOMPATIBLE_10_1ファンクション。これらのファンクションは、それぞれデータベースの互換レベル 9.2.0 と 10.1.0 に対応する定数の値を戻します。Oracle データベースの互換性を制御するには、COMPATIBLE初期化パラメータを使用します。

たとえば、次のルールを考えます。

BEGIN DBMS_RULE_ADM.CREATE_RULE( rule_name => 'strmadmin.dml_compat_9_2', condition => ':dml.GET_COMPATIBLE() > DBMS_STREAMS.COMPATIBLE_9_2()');END;/

Streams クライアント（取得プロセス、伝播、適用プロセスなど）のネガティブ・ルール・セットにこのルールが含まれる場合、Streams クライアントでは、Oracle9i リリース 2（9.2）と互換性を持たないすべての行 LCR が廃棄されます。

ポジティブ・ルール・セットの場合のより適切な例を次に示します。

BEGIN DBMS_RULE_ADM.CREATE_RULE( rule_name => 'strmadmin.dml_compat_9_2', condition => ':dml.GET_COMPATIBLE() <= DBMS_STREAMS.COMPATIBLE_10_1()');END;/


� 5-4 ページの「単純ルール条件」




Streams クライアントのポジティブ・ルール・セットにこのルールが含まれる場合、Streamsクライアントでは、Oracle Database10g リリース 1（10.1）以下と互換性を持たないすべての行 LCR が廃棄されます。つまり、Streams クライアントでは、リリース 2（9.2）またはリリース 1（10.1）と互換性を持ち、ルール・セットのその他のルールを満たすすべての行LCR は処理されますが、これらのリリースと互換性を持たないすべての行 LCR は廃棄されます。

前述の例のルールは両方とも効率的に評価されます。DBMS_STREAMS_ADMパッケージで作成したスキーマ・ルールまたはグローバル・ルールを使用して LCR を取得、伝播、適用またはデキューする場合は、このルールを使用して、特定のデータベースでサポートされていない LCR を廃棄できます。

複合ルール条件複合ルール条件複合ルール条件複合ルール条件複合ルール条件とは、5-4 ページの「単純ルール条件」で説明した単純ルール条件の要件を満たしていないルール条件です。Streams 環境では、DBMS_STREAMS_ADMパッケージで作成されるルールは単純ルール条件のみを持ち、システム作成ルールにはカスタム条件が追加されていないことが想定されます。DBMS_STREAMS_ADMパッケージで作成できるシステム作成ルール条件のタイプについては、6-8 ページの表 6-3 を参照してください。複雑な条件を伴うルールを作成する必要がある場合は、DBMS_RULE_ADMパッケージを使用します。


� DBA_STREAMS_UNSUPPORTEDデータ・ディクショナリ・ビューを問い合せると、Streams でサポートされていないデータベースのデータベース・オブジェクトを判断できます。

� DBMS_RULE_ADMパッケージを使用して GET_COMPATIBLE条件付きのルールを作成するかわりに、DBMS_STREAMS_ADMパッケージのいずれかのプロシージャを使用して、AND_CONDITIONパラメータにGET_COMPATIBLE条件を指定すると、このようなルールを作成できます。

� DDL LCR は常に DBMS_STREAMS.COMPATIBLE_9_2を戻します。


� 14-68 ページの「Streams 環境での互換性の監視」

� 6-13 ページの「グローバル・ルールの例」、6-17 ページの「スキーマ・ルールの例」および 6-39 ページの「システム作成ルールへのユーザー定義条件の追加」

� COMPATIBLE初期化パラメータの詳細は、『Oracle Database リファレンス』および『Oracle Database アップグレード・ガイド』を参照してください。



様々な複合ルール条件があります。ここでは、複合ルール条件の例をいくつか示します。

NOT 論理条件を使用してオブジェクトを除外するルール条件論理条件を使用してオブジェクトを除外するルール条件論理条件を使用してオブジェクトを除外するルール条件論理条件を使用してオブジェクトを除外するルール条件 NOT論理条件を使用すると、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パッケージを使用してこれらのルールを作成すると、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;/

この場合、ルールはルール・セットから Streams の評価コンテキストを継承します。

LIKE 条件を使用するルール条件条件を使用するルール条件条件を使用するルール条件条件を使用するルール条件 LIKE条件を使用すると、ルールの条件が特定のパターンと一致する場合に TRUEと評価される複合ルールを作成できます。たとえば、JOBというパターンで始まる hrスキーマ内のすべてのデータベース・オブジェクトに対するすべてのDML および DDL 変更について、TRUEと評価されるルール条件を指定する必要があるとし

注意注意注意注意 : ほとんどの場合、DBMS_STREAMS_ADMパッケージを使用してStreams クライアントのネガティブ・ルール・セットにルールを追加すれば、NOT論理条件を持つ複合ルールを使用する必要はありません。

参照参照参照参照 : 6-34 ページの「システム作成ルールとネガティブ・ルール・セット」



ます。LIKE条件を使用すると、DML 変更用に 1 つと DDL 変更用に 1 つ、合計 2 つのルールを使用して、このルール条件を指定できます。これらのルールのルール条件を次に示します。

(: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プロシージャの実行時にクライアントからルール・エンジンへ、変数の値または属性の少なくとも 1 つが送信されないと、変数は未定義となります。たとえば、変数 xが属性 aと bを持つ場合、クライアントから xの値が送信されず、aの値も bの値も送信されない場合には、変数は未定義となります。ただし、クライアントから少なくとも 1 つの属性の値が送信される場合、変数は定義されます。この場合では、クライアントから aの値が送信され、bの値が送信されない場合、変数は定義されます。

ルール条件内の未定義変数は、取得プロセス、伝播、適用プロセスとメッセージ・クライアントを含む、ルール・エンジンの Streams クライアントに対して NULLと評価されます。これに対して、ルール・エンジンの Streams 以外のクライアントでは、ルール条件内の未定義変数が原因で、ルール・エンジンから maybe_rulesがクライアントに戻される場合があります。ルール・セットの評価時に、さらに情報を与えると TRUEと評価される可能性があるルールが maybe_rulesです。

Streams クライアントに戻される maybe_rulesの数は、未定義変数をそれぞれ NULLとして扱うと減少します。maybe_rulesの数が減少すると、イベント発生時のルール・セットの評価が効率的に実行される場合にパフォーマンスを改善できます。Streams 以外のクライアントに maybe_rulesを戻すルールは、次の例で示されるように、Streams クライアントでは TRUEまたは FALSEルールとなる可能性があります。

未定義変数が未定義変数が未定義変数が未定義変数が Streams クライアントに対するクライアントに対するクライアントに対するクライアントに対する TRUE ルールとなる例ルールとなる例ルールとなる例ルールとなる例次のユーザー定義のルール条件を考えます。

:m IS NULL

評価中に変数 mの値が定義されない場合、ルール・エンジンの Streams 以外のクライアントに maybe ルールが発生します。ただし、Streams クライアントについては、未定義変数 mがNULLとして扱われるため、この条件は TRUEと評価されます。このようなルールが Streamsクライアントのルール・セットに追加されされないように注意する必要があります。このようなルールは、すべてのイベントに対して TRUEと評価されるためです。そのため、たとえ



ば、取得プロセスのポジティブ・ルール・セットにそのようなルールが含まれていると、取得の対象外とされているイベントが取得プロセスによって取得される場合があります。

次に、Streams の :dml変数を使用している別のユーザー指定のルール条件を示します。

:dml.get_object_owner() = 'HR' AND :m IS NULL

Streams クライアントでは、イベントが hrスキーマ内の表に対する行の変更で構成されており、かつ、変数 mの値が評価時に不明の場合、未定義変数 mが NULLとして扱われるため、この条件は TRUEと評価されます。

未定義変数が未定義変数が未定義変数が未定義変数が Streams クライアントに対するクライアントに対するクライアントに対するクライアントに対する FALSE ルールとなる例ルールとなる例ルールとなる例ルールとなる例次のユーザー定義のルール条件を考えます。

:m = 5

評価中に変数 mの値が定義されない場合、ルール・エンジンの Streams 以外のクライアントに maybe ルールが発生します。ただし、Streams クライアントについては、未定義変数 mがNULLとして扱われるため、この条件は FALSEと評価されます。

Streams の :dml変数を使用する別のユーザー指定のルール条件を考えます。

:dml.get_object_owner() = 'HR' AND :m = 5

Streams クライアントでは、イベントが hrスキーマ内の表に対する行の変更で構成されており、かつ、変数 mの値が評価時に不明の場合、未定義変数 mが NULLとして扱われるため、この条件は FALSEと評価されます。

:dml およびおよびおよびおよび :ddl 変数をルール条件のファンクション・パラメータとして変数をルール条件のファンクション・パラメータとして変数をルール条件のファンクション・パラメータとして変数をルール条件のファンクション・パラメータとして使用することの回避使用することの回避使用することの回避使用することの回避ルール条件のファンクション・パラメータとして :dmlと :ddl変数を使用しないことをお薦めします。次の例では、ファンクション my_functionのパラメータとして :dml変数が使用されています。

my_function(:dml) = 'Y'

このようなルール条件は、ルール評価のパフォーマンスを低下させ、誤った Streams データ・デクショナリ情報が取得または伝播される原因となります。

参照参照参照参照 : 5-11 ページの「ルール・セットの評価」

参照参照参照参照 : 2-41 ページの「Streams データ・ディクショナリ」


ルールベースの変換

ユーザー作成評価コンテキストユーザー作成評価コンテキストユーザー作成評価コンテキストユーザー作成評価コンテキスト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を指定してください。

評価コンテキストに関する情報は、次のデータ・ディクショナリ・ビューで検索できます。

� ALL_EVALUATION_CONTEXT_TABLES

� ALL_EVALUATION_CONTEXT_VARS

� ALL_EVALUATION_CONTEXTS

必要な場合は、これらのデータ・ディクショナリ・ビューの情報を使用し、SYS.STREAMS$_EVALUATION_CONTEXTに基づいて新規の評価コンテキストを作成できます。

ルールベースの変換ルールベースの変換ルールベースの変換ルールベースの変換Streams では、ルールベースの変換ルールベースの変換ルールベースの変換ルールベースの変換は、ポジティブ・ルール・セットのルールが TRUEに評価される場合に発生するイベントのユーザー定義の変更です。ルールベースの変換を使用すると、取得イベントとユーザー・エンキュー・イベントの両方を変更できます。これらのイベントは、LCR でもユーザー・メッセージでもかまいません。変換は、入力としてSYS.AnyDataオブジェクトを取って SYS.AnyDataオブジェクトを戻す PL/SQL ファンクションとして定義する必要があります。ルールベースの変換でサポートされるのは、1 対 1の変換のみです。

たとえば、表の特定の列のデータ型が 2 つのデータベース間で異なる場合は、ルールベースの変換を使用できます。このような列は、ソース・データベースでは NUMBER列、接続先データベースでは VARCHAR2列の場合があります。この場合の変換は、入力として列のNUMBERデータ型の行 LCR を含む SYS.AnyDataオブジェクトを取り、同じ列のVARCHAR2データ型の行 LCR を含む SYS.AnyDataオブジェクトを戻します。

注意注意注意注意 : Oracle が提供する評価コンテキストの変数との競合を回避するために、$ や # などの特殊文字を含む変数名は使用しないでください。

参照参照参照参照 : これらのデータ・ディクショナリ・ビューの詳細は、『Oracle Database リファレンス』を参照してください。



イベントのその他の変換例は次のとおりです。

� データベース・オブジェクトの所有者名の変更

� データベース・オブジェクト名の変更

� 列名の変更または列の削除

� 複数列への列の分割

� 複数列から 1 列への結合

� 列の内容の変更

� ユーザー・メッセージのペイロードの変更

ルールベースの変換を伴う取得 LCR は変更できますが、取得 LCR に対して実行されるルールベースの変換で、新規 LCR を構成してそれを戻すことはできません。ルールベースの変換では、受信したものと同じ取得 LCR を戻す必要があります。ただし、ユーザー・エンキュー・イベントを受信するルールベースの変換では、新規イベントを構成してそれを戻すことができます。この場合、戻されるイベントは、ルールベースの変換によって構成されたLCR である場合があります。

DBMS_STREAMS_ADMパッケージの SET_RULE_TRANSFORM_FUNCTIONプロシージャを使用して、ルールのルールベースの変換を指定します。このプロシージャは、ルールのアクション・コンテキストを変更して、変換を指定します。ルール・アクション・コンテキストはルールに関連付けられたオプションの情報であり、イベントのルールが TRUEに評価された後でルール・エンジンのクライアントによって解析されます。ルール・エンジンのクライアントは、ユーザー作成アプリケーション、または Streams などの Oracle の内部機能です。アクション・コンテキスト内の情報は、名前 / 値ペアのリストで構成されるSYS.RE$NV_LIST型のオブジェクトです。

Streams では、ルールベースの変換は常に、アクション・コンテキスト内の次の名前 / 値ペアで構成されます。

� 名前は STREAMS$_TRANSFORM_FUNCTIONです。

� 値は、VARCHAR2として指定された PL/SQL ファンクションの名前を含むSYS.AnyDataインスタンスです。このファンクションによって変換が実行されます。

DBA_STREAMS_TRANSFORM_FUNCTIONデータ・ディクショナリ・ビューを問い合せると、データベースに存在する既存のルールベースの変換を表示できます。

変換ファンクションをコールするユーザーは、そのファンクションの EXECUTE権限を持っている必要があります。次のリストに、変換ファンクションをコールするユーザーを示します。

� 取得プロセスで使用されるルール用の変換が指定されている場合、変換ファンクションをコールするユーザーは、その取得プロセスの取得ユーザーです。

� 伝播で使用されるルール用の変換が指定されている場合、変換ファンクションをコールするユーザーは、その伝播のソース・キューの所有者です。



� 適用プロセスで使用されるルール用の変換が指定されている場合、変換ファンクションをコールするユーザーは、その適用プロセスの適用ユーザーです。

� メッセージ・クライアントで使用されるルール用の変換が指定されている場合、変換ファンクションをコールするユーザーは、そのメッセージ・クライアントを起動するユーザーです。

Streams 環境でポジティブ・ルール・セット内のルールがイベントについて TRUEと評価され、名前が STREAMS$_TRANSFORM_FUNCTIONの名前 / 値ペアを含むアクション・コンテキストが戻されると、入力パラメータにイベントを使用して PL/SQL ファンクションが実行されます。アクション・コンテキスト内で STREAMS$_で始まるその他の名前は Oracle によって内部的に使用され、直接追加、変更または削除することはできません。Streams では、STREAMS$_または APPLY$_以外で始まる名前 / 値ペアは無視されます。

Streams 環境でイベントのルールが FALSEと評価されると、そのルールはクライアントに戻されず、アクション・コンテキスト内の名前 / 値ペアに示されている PL/SQL ファンクションは実行されません。様々なルールに同じ変換または異なる変換を使用できます。たとえば、イベントの取得、伝播、適用またはデキュー対象となる様々な操作タイプ、表またはスキーマに、異なる変換を関連付けることができます。

ルールベースの変換での考慮事項は、次のとおりです。

� Streams クライアントでルールベースの変換を実行する場合、ルールは Streams クライアントのポジティブ・ルール・セットに含まれる必要があります。ルールが Streams クライアントのネガティブ・ルール・セットに含まれる場合、Streams クライアントではルールベースの変換が無視されます。

� ルールベースの変換は、DBMS_TRANSFORMパッケージを使用して実行する変換とは異なります。この項では、DBMS_TRANSFORMパッケージを使用して実行する変換については説明しません。

� 適用の並列性が 2 以上であれば DML ハンドラをパラレルで実行できるため、環境で多数の行 LCR を変換したり、行 LCR で高コストの変換を行う必要がある場合は、かわりに DML ハンドラ内でこれらの変更を実行することを考慮してください。

� DDL LCR に対してルールベースの変換を実行する場合は、他の変更と一致するようにDDL LCR 内で DDL テキストの変更が必要になることがあります。たとえば、ルールベースの変換によって DDL LCR 内の表名が変更になる場合は、DDL テキスト内の表名も同様に変更する必要があります。

� ルールベースの変換を使用して LCR イベントを非 LCR イベントには変換できません。この制限は、取得 LCR とユーザー・エンキュー LCR に適用されます。

次の項では、Streams クライアントのタイプごとに、ルールベースの変換の詳細を説明します。

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

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

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



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

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

ルールベースの変換と取得プロセスルールベースの変換と取得プロセスルールベースの変換と取得プロセスルールベースの変換と取得プロセス取得プロセスでポジティブ・ルール・セットを使用する場合、取得中に変換を実行するには次の両方の条件を満たす必要があります。

� REDO ログ内で検出された特定の変更について、ポジティブ・ルール・セット内のルールが TRUEと評価されること。

� ルールの評価時に、名前が STREAMS$_TRANSFORM_FUNCTIONの名前 / 値ペアを含むアクション・コンテキストが取得プロセスに戻されること。

これらの条件を満たしている場合は、取得プロセスで次の手順が実行されます。

1. REDO ログ内の変更が LCR 形式でフォーマットされます。

2. LCR が SYS.AnyDataオブジェクトに変換されます。

3. 名前 / 値ペアに含まれる PL/SQL ファンクションが実行され、SYS.AnyDataオブジェクトが変換されます。

4. 変換済の SYS.AnyDataオブジェクトが、取得プロセスに関連付けられているキューにエンキューされます。



� 5-9 ページの「ルール・アクション・コンテキスト」

� DBMS_TRANSFORMパッケージの詳細は、『Oracle Streams アドバンスト・キューイング・ユーザーズ・ガイドおよびリファレンス』および

『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

� DML ハンドラの詳細は、4-3 ページの「適用プロセスによるイベント処理」を参照してください。



すべてのアクションは取得ユーザーで実行されます。図 6-6 に、取得中の変換を示します。

図図図図 6-6 取得中の変換取得中の変換取得中の変換取得中の変換

たとえば、LCR イベントが取得中に変換されると、変換済 LCR イベントは取得プロセスで使用されるキューにエンキューされます。したがって、このような取得 LCR イベントがdbs1.netデータベースから dbs2.netおよび dbs3.netデータベースへと伝播すると、伝播後には dbs2.netおよび dbs3.netにあるキューに変換済 LCR イベントが含まれることになります。

取得中に変換を実行するメリットは、次のとおりです。

� 変換によってプライベート情報が削除または変更されても、このプライベート情報はソース・キューに表示されず、宛先キューにも伝播しないため、セキュリティを向上できます。

� 実行される変換のタイプによっては、領域消費が減少する場合があります。たとえば、データ量を減少させる変換では、エンキュー、伝播および適用されるデータが減少します。



� 変換は複数の宛先で実行されるのではなくソース側で 1 回だけ実行されるため、変換済LCR イベントに複数の宛先がある場合に変換によるオーバーヘッドが減少します。

取得中に変換を実行する場合に考えられるデメリットは、次のとおりです。

� 取得プロセスがローカルの取得プロセスである場合、ソース・データベースに変換によるオーバーヘッドが発生します。ただし、取得プロセスがダウンストリーム取得プロセスである場合、このオーバーヘッドはソース・データベースではなくダウンストリーム・データベースで発生します。

� すべてのサイトで変換済 LCR イベントが受信されます。

取得中のルールベースの変換のエラー取得中のルールベースの変換のエラー取得中のルールベースの変換のエラー取得中のルールベースの変換のエラー取得中に変換ファンクションの実行エラーが発生すると、変更は取得されず、取得プロセスにエラーが戻され、取得プロセスは無効化されます。エラーを回避するために、取得プロセスを有効化する前に、ルールベースの変換を変更または削除する必要があります。

ルールベースの変換と伝播ルールベースの変換と伝播ルールベースの変換と伝播ルールベースの変換と伝播伝播でポジティブ・ルール・セットを使用する場合、伝播中に変換を実行するには次の両方の条件を満たす必要があります。

� 伝播のソース・キュー内のイベントについて、ポジティブ・ルール・セット内のルールが TRUEと評価されること。このイベントは、取得イベントの場合とユーザー・エンキュー・イベントの場合があります。

� ルールの評価時に、名前が STREAMS$_TRANSFORM_FUNCTIONの名前 / 値ペアを含むアクション・コンテキストが伝播に戻されること。

これらの条件を満たしている場合は、伝播プロセスで次の手順が実行されます。

1. 伝播によってソース・キューからのイベントのデキューが開始されます。

2. ソース・キューの所有者によって名前 / 値ペアに含まれる PL/SQL ファンクションが実行され、イベントが変換されます。

3. 伝播で、変換済イベントのデキューが完了します。

4. 伝播によって変換済イベントが宛先キューに伝播されます。

注意注意注意注意 : 取得プロセスでルールベースの変換を使用して、Streams でサポートされていないデータ型の列を変更または削除できません。2-7 ページの「取得されるデータ型」を参照してください。

参照参照参照参照 : 3-3 ページの「取得イベントとユーザー・エンキュー・イベント」



図 6-7 に、伝播中の変換を示します。

図図図図 6-7 伝播中の変換伝播中の変換伝播中の変換伝播中の変換

たとえば、dbs1.netデータベースから dbs2.netデータベースへのイベントの伝播にルールベースの変換を使用し、dbs1.netデータベースから dbs3.netデータベースへのイベントの伝播にはルールベースの変換を使用しない場合を考えます。

この場合、dbs1.netのキューにあるイベントは dbs2.netに伝播する前に変換できますが、それと同じイベントを dbs3.netに伝播するときにはオリジナルのままで伝播できます。この場合、伝播後は、dbs2.netのキューには変換済イベントが含まれ、dbs3.netのキューにはオリジナルのイベントが含まれます。

伝播中に変換を実行するメリットは、次のとおりです。

� イベントが伝播される前に変換によってプライベート情報が削除または変更されると、セキュリティを向上できます。

� 一部の宛先キューは変換済イベントを受信でき、他の宛先キューはオリジナルのイベントを受信できます。

� 様々な宛先が同じイベントの異なるバリエーションを受信できます。

伝播中に変換を実行する場合に考えられるデメリットは、次のとおりです。

� イベントが変換されると、初の伝播後に伝播先となるデータベースは変換済イベントを受信します。たとえば、イベントが dbs2.netから dbs4.netに伝播する場合、dbs4.netは変換済イベントを受信します。

� 有向ネットワークでは、初の伝播によって変換が実行され、イベントを取得した取得プロセスがローカルの場合、ソース・データベース上で変換によるオーバーヘッドが発



生します。ただし、取得プロセスがダウンストリーム取得プロセスである場合、このオーバーヘッドはソース・データベースではなくダウンストリーム・データベースで発生します。

� 複数の接続先データベースが同じ変換を必要とする場合は、同じ変換が 2 回以上実行される可能性があります。

伝播中のルールベースの変換のエラー伝播中のルールベースの変換のエラー伝播中のルールベースの変換のエラー伝播中のルールベースの変換のエラー伝播中に変換ファンクションの実行エラーが発生すると、エラーの原因となったイベントはデキューも伝播もされず、伝播にエラーが戻されます。エラーを回避するために、イベントを伝播させる前に、ルールベースの変換を変更または削除する必要があります。

ルールベースの変換と適用プロセスルールベースの変換と適用プロセスルールベースの変換と適用プロセスルールベースの変換と適用プロセス適用プロセスでポジティブ・ルール・セットを使用する場合、適用中に変換を実行するには次の両方の条件を満たす必要があります。

� 適用プロセスに関連付けられたキュー内のイベントについて、ポジティブ・ルール・セット内のルールが TRUEと評価されること。このイベントは、取得イベントの場合とユーザー・エンキュー・イベントの場合があります。

� ルールの評価時に、名前が STREAMS$_TRANSFORM_FUNCTIONの名前 / 値ペアを含むアクション・コンテキストが適用プロセスに戻されること。

これらの条件を満たしている場合は、適用プロセスで次の手順が実行されます。

1. キューからのイベントのデキューが開始されます。

2. 名前 / 値ペアに含まれる PL/SQL ファンクションが実行され、デキュー中にイベントが変換されます。

3. 変換済イベントのデキューが完了します。

4. 変換済イベントを適用します。接続先データベースのデータベース・オブジェクトの変更、または適用ハンドラへの変換済イベントの送信を行う場合があります。

参照参照参照参照 : 3-3 ページの「取得イベントとユーザー・エンキュー・イベント」



すべてのアクションは適用ユーザーで実行されます。図 6-8 に、適用中の変換を示します。

図図図図 6-8 適用中の変換適用中の変換適用中の変換適用中の変換

たとえば、dbs1.netデータベースから dbs2.netデータベースにイベントがオリジナルの形式で伝播する場合を考えます。適用プロセスによって dbs2.netのキューからデキューされるときに、イベントが変換されます。

適用中に変換を実行する場合に考えられるメリットは、次のとおりです。

� 初の伝播後にイベントの伝播先となるデータベースは、イベントをオリジナルの形式で受信できます。たとえば、イベントが dbs2.netから dbs4.netに伝播する場合、dbs4.netはオリジナルのイベントを受信できます。

� ソース・データベースと接続先データベースが異なる場合、ソース・データベース上では変換によるオーバーヘッドは発生しません。

適用中に変換を実行する場合に考えられるデメリットは、次のとおりです。

� イベントの伝播先となるデータベースすべてがオリジナルのイベントを受信するため、イベントにプライベート情報が含まれている場合はセキュリティが問題になる可能性があります。


注意注意注意注意 : 適用プロセスの 1 つ以上のルールを変更する前に、適用プロセスを停止する必要があります。



適用プロセスによるデキュー中のルールベースの変換のエラー適用プロセスによるデキュー中のルールベースの変換のエラー適用プロセスによるデキュー中のルールベースの変換のエラー適用プロセスによるデキュー中のルールベースの変換のエラー適用プロセスによるデキュー中に変換ファンクションの実行エラーが発生すると、エラーの原因となったイベントはデキューされず、そのイベントを含むトランザクションは適用されず、適用プロセスにエラーが戻されます。また、適用プロセスは無効化されます。エラーを回避するために、適用プロセスを有効化する前に、ルールベースの変換を変更または削除する必要があります。

変換済イベントの適用エラー変換済イベントの適用エラー変換済イベントの適用エラー変換済イベントの適用エラートランザクションに適用エラーが発生し、そのトランザクションで一部のイベントがルールベースの変換によって変換済の場合、変換済イベントはトランザクション内の他のすべてのイベントとともにエラー・キューに移動されます。DBMS_APPLY_ADMパッケージのEXECUTE_ERRORプロシージャを使用して、変換済イベントを含むエラー・キュー内のトランザクションを再実行すると、ルールを含む適用プロセスのルール・セットは再評価されないため、イベントの変換は再実行されません。

ルールベースの変換とメッセージ・クライアントルールベースの変換とメッセージ・クライアントルールベースの変換とメッセージ・クライアントルールベースの変換とメッセージ・クライアントメッセージ・クライアントでポジティブ・ルール・セットを使用する場合、メッセージ・クライアントがキューからイベントをデキューする際に変換を実行するには、次の両方の条件を満たす必要があります。

� メッセージ・クライアントのポジティブ・ルール・セットにあるルールが、イベントについて TRUEと評価されること。このイベントは、ユーザー・エンキュー LCR の場合とユーザー・エンキュー・メッセージの場合があります。

� ルールの評価時に、名前が STREAMS$_TRANSFORM_FUNCTIONの名前 / 値ペアを含むアクション・コンテキストがメッセージ・クライアントに戻されること。

これらの条件を満たしている場合は、メッセージ・クライアントで次の手順が実行されます。

1. キューからのイベントのデキューが開始されます。

2. 名前 / 値ペアに含まれる PL/SQL ファンクションが実行され、デキュー中にイベントが変換されます。

3. 変換済イベントのデキューが完了します。



すべてのアクションはメッセージ・クライアントを起動するユーザーで実行されます。図6-9 に、メッセージ・クライアントのデキュー中の変換を示します。

図図図図 6-9 メッセージ・クライアントによるデキュー中の変換メッセージ・クライアントによるデキュー中の変換メッセージ・クライアントによるデキュー中の変換メッセージ・クライアントによるデキュー中の変換

たとえば、dbs1.netデータベースから dbs2.netデータベースにイベントがオリジナルの形式で伝播する場合を考えます。メッセージ・クライアントによって dbs2.netのキューからデキューされるときに、イベントが変換されます。

メッセージ環境でデキュー中に変換を実行する場合に考えられる 1 つのメリットは、初の伝播後にイベントの伝播先となるデータベースが、イベントをオリジナルの形式で受信できることです。たとえば、イベントが dbs2.netから dbs4.netに伝播する場合、dbs4.netはオリジナルのイベントを受信できます。

メッセージ環境でデキュー中に変換を実行する場合に考えられるデメリットは、次のとおりです。

� イベントの伝播先となるすべてのデータベースがオリジナルのイベントを受信するため、イベントにプライベート情報が含まれている場合はセキュリティが問題になる可能性があります。


メッセージ・クライアントによるデキュー中のルールベースの変換のエメッセージ・クライアントによるデキュー中のルールベースの変換のエメッセージ・クライアントによるデキュー中のルールベースの変換のエメッセージ・クライアントによるデキュー中のルールベースの変換のエラーラーラーラーメッセージ・クライアントによるデキュー中に変換ファンクションの実行エラーが発生すると、エラーの原因となったイベントはデキューされず、メッセージ・クライアントにエラーが戻されます。エラーを回避するために、メッセージ・クライアントによってイベントをデキューする前に、ルールベースの変換を変更または削除する必要があります。



ルールベースの複数の変換ルールベースの複数の変換ルールベースの複数の変換ルールベースの複数の変換取得、伝播、適用、デキューまたはその任意の組合せの実行中に、イベントを変換できます。たとえば、機密データをすべての受信者に対して非表示にする必要がある場合は、取得中にイベントを変換できます。一部の受信者には追加のカスタム変換が必要な場合は、以前に変換済のイベントを伝播、適用またはデキュー中に変換できます。




Streams 高可用性

7
Streams 高可用性環境高可用性環境高可用性環境高可用性環境
この章では、Streams 高可用性環境に関連する概念を説明します。


� Streams 高可用性環境の概要

� 障害からの保護

� Streams 高可用性環境の良の実施例

環境 7-1

Streams 高可用性環境の概要

Streams 高可用性環境の概要高可用性環境の概要高可用性環境の概要高可用性環境の概要高可用性ソリューションの構成には、念入りな計画と障害発生時の使用例の分析が必要です。データベース・バックアップとフィジカル・スタンバイ・データベースでは、フェイルオーバー保護用にソース・データベースの物理コピーが提供されます。Oracle Data Guardには、SQL Apply モードの場合、高可用性環境にロジカル・スタンバイ・データベースが実装されます。Oracle Data Guard は高可用性環境用に設計されているため、ほとんどの障害発生例に対応します。ただし、一部の環境で、Oracle Streams によって実現された柔軟性が必要になる場合には、Streams によって提供される拡張機能セットが使用可能です。

この章では、Streams ベースのソリューションが適している使用例と、高可用性環境で発生する Streams 固有の問題を説明します。また、クラスタ内のハードウェア・フェイルオーバー、Oracle Real Application Clusters（RAC）クラスタ内のインスタンス・フェイルオーバー、およびレプリカ間のフェイルオーバーとスイッチオーバーを含め、Streams を高可用性環境に配置する良の実施例も説明します。

障害からの保護障害からの保護障害からの保護障害からの保護インスタンスまたはシステム障害からの保護策には、Oracle RAC が適しています。障害が発生すると、クラスタ内にある障害の発生していない方のノードによってサービスが提供されます。ただし、クラスタ化では、ユーザー・エラー、メディア障害および障害からは保護されません。このような障害には、データベースの重複コピーが必要です。データベースの物理コピーと論理コピーの両方を作成できます。

物理コピーはブロック単位でソース・データベースと同一になるように行われるもので、データ保護に適した方法です。物理コピーにはデータベース・バックアップ、ミラー化または多重データベース・ファイル、フィジカル・スタンバイ・データベースの 3 タイプがあります。

論理コピーにはソース・データベースと同じ情報が含まれますが、情報はデータベース内に異なる形式で格納される場合があります。データベースの論理コピーを作成することには、多くのメリットがあります。ただし、論理コピーの作成は、常に物理コピーも作成したうえで行う必要があります。物理コピーの代替として作成しないでください。

論理コピーには、次のようなメリットがあります。

� 更新中に論理コピーを開くことができます。このため、論理コピーはほぼリアル・タイムのレポートに役立ちます。


� Oracle Data Guard の詳細は、『Oracle Data Guard 概要および管理』を参照してください。

� 『Oracle Real Application Clusters 管理』


障害からの保護

� 論理コピーに様々な物理レイアウトを指定し、目的に応じて適化できます。たとえば、追加の索引を含めることができ、その結果として論理コピーを利用したレポート・アプリケーションのパフォーマンスが改善されます。

� 論理コピーによって、破損からの保護が強化されます。データは論理的に取得および適用されるため、物理的な破損がデータベースの論理コピーに伝播することはほとんど考えられません。

データベースの論理コピーには 3 タイプあります。

� ロジカル・スタンバイ・データベース

� Streams レプリカ・データベース

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

ロジカル・スタンバイ・データベースは、SQL Apply モードの Oracle Data Guard を使用した場合に適な状態でメンテナンスされます。この章の後半では、Streams レプリカ・データベースとアプリケーションによるコピーのメンテナンスを説明します。

Streams レプリカ・データベースレプリカ・データベースレプリカ・データベースレプリカ・データベースSQL Apply モードの Oracle Data Guard と同様に、Oracle Streams を使用して、データベース変更を取得して接続先に伝播し、変更をこれらの接続先に適用できます。Streams は、データのレプリケートのために適化されます。Streams では、記録中のオンライン REDOログの変更がローカルに取得され、取得された変更がレプリカ・データベースへ非同期に伝播できます。この適化によって待機時間を短縮し、レプリカのプライマリ・データベースからの遅れを数秒以内に抑えることができます。

それでもなお、本番データベースの論理コピーの構成およびメンテナンスに Streams の使用を選択する場合があります。Streams を使用すると追加の作業が必要になりますが、固有のビジネス要件を満たすために必要な優れた柔軟性が提供されます。Streams を使用して構成およびメンテナンスされる論理コピーでは、通常定義のスタンバイ・データベースの有効範囲を超える多くの機能が提供されるため、ロジカル・スタンバイではなくレプリカと呼ばれます。Oracle Streams レプリカの使用が適した要件の一部を次の項に示します。


� データベース・バックアップと、データベース・ファイルのミラー化または多重化の詳細は、『Oracle Database バックアップおよびリカバリ基礎』および『Oracle Database バックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』を参照してください。

� フィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースの詳細は、『Oracle Data Guard 概要および管理』を参照してください。

Streams 高可用性環境 7-3


レプリカ・データベースの更新レプリカ・データベースの更新レプリカ・データベースの更新レプリカ・データベースの更新レプリカ・データベースとスタンバイ・データベースの大の違いは、レプリカ・データベースが更新可能であるのに対し、スタンバイ・データベースは更新不可である点です。ジョブ・キューや、レポート・アクティビティをログに記録するレポート・アプリケーションなど、データの更新が必要なアプリケーションをレプリカに対して実行できます。また、レプリカ・データベースでは、ローカル・アプリケーションを Wide Area Network（WAN）の障害から保護し、データベース操作の待機時間を減少させながら、自律的に実行できます。

異機種間プラットフォームのサポート異機種間プラットフォームのサポート異機種間プラットフォームのサポート異機種間プラットフォームのサポート本番データベースとレプリカ・データベースは、同じプラットフォーム上で稼働している必要はありません。そのため、コンピュータ資産の使用が柔軟になり、プラットフォーム間の移行が容易になります。

複数キャラクタ・セット複数キャラクタ・セット複数キャラクタ・セット複数キャラクタ・セットStreams レプリカでは、本番データベースとは異なるキャラクタ・セットを使用できます。データは、適用される前に、1 つのキャラクタ・セットから別のキャラクタ・セットに自動的に変換されます。グローバル操作を使用していて、データを複数の国に配布する必要がある場合に、この機能はきわめて重要です。

オンラインオンラインオンラインオンライン REDO ログのマイニングによる待機時間の最小化ログのマイニングによる待機時間の最小化ログのマイニングによる待機時間の最小化ログのマイニングによる待機時間の最小化レプリカをほぼリアル・タイムのレポートに使用すると、Streams の本番データベースからの遅れが数秒以内に抑えられ、新で正確な問合せが提供できます。変更は、アーカイブ後の REDO ログからではなく、記録中のオンライン REDO ログから読取り可能です。

11 以上のデータ・コピー以上のデータ・コピー以上のデータ・コピー以上のデータ・コピーStreams では、無制限の数のレプリカがサポートされます。その柔軟なルーティング・アーキテクチャではハブ・アンド・スポーク構成が考慮されおり、データを何百ものレプリカに効率的に伝播できます。組織の多くのローカル・オフィスで自律型運用を行う必要がある場合、この機能が重要になることがあります。これに対して、Oracle Data Guard によって構成されるスタンバイ・データベースでは LOG_ARCHIVE_DEST_n 初期化パラメータを使用して接続先を指定するため、Oracle Data Guard を使用するとコピーの数が 10 に制限されます。

参照参照参照参照 : Streams を使用してデータベース変更をレプリケートする方法の詳細は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。



高速フェイルオーバー高速フェイルオーバー高速フェイルオーバー高速フェイルオーバーStreams レプリカは、常に読取り / 書込み操作用にオープンされています。プライマリ・データベースに障害が発生した場合、Streams レプリカですぐに処理を再開できます。少量のデータがプライマリ・データベースに残る場合がありますが、このデータはプライマリ・データベースがリカバリされると自動的に適用されます。データの消失を防ぐよりもリカバリ時間の短縮を重視する場合、この機能が重要になることがあります。終的にプライマリ・データベースをリカバリできるとすると、データが使用不可能になるのは一時的なものにすぎません。

複数接続先への単一の取得複数接続先への単一の取得複数接続先への単一の取得複数接続先への単一の取得複合環境では、変更の取得は 1 回のみ必要です。これらの変更は複数の接続先に送信できます。この機能によって、REDO ログで変更をマイニングするために必要なリソースをさらに効率的に使用できます。

Streams を使用しない場合を使用しない場合を使用しない場合を使用しない場合前述のように、一部の高可用性の要件を満たすために Streams の使用を選択する使用例があります。高可用性のルールの 1 つは、単純さの保持です。Oracle Data Guard は高可用性のために設計されており、Streams ベースの高可用性ソリューションよりも実装が容易です。Streams によって提供される柔軟性を利用する場合は、Streams ベースのソリューションを強固にするために必要な専門技術と計画に投資する準備が必要です。つまり、Oracle Data Guard で提供される自動化および管理ツールのほとんどを、スクリプトを作成して実装する必要があります。

アプリケーションによるコピーのメンテナンスアプリケーションによるコピーのメンテナンスアプリケーションによるコピーのメンテナンスアプリケーションによるコピーのメンテナンスデータの論理コピーのメンテナンスをアプリケーションで直接実行するように設計すると、可用性を大限にできます。重要なデータやデータ消失を防ぐためオフサイトに即時移動する必要のあるデータは、アプリケーションで認識されています。また、重要なデータは同期式にレプリケートでき、それほど重要でないデータは非同期式にレプリケートできます。アプリケーションでは、別のデータの論理コピーを管理する他のアプリケーションにデータを同期式または非同期式に送信することによって、データのコピーがメンテナンスされます。同期操作は、分散 SQL またはデータベースのリモート・プロシージャ機能を使用して実行されます。非同期操作は、アドバンスト・キューイングを使用して実行されます。アドバンスト・キューイングは、Oracle Streams に備えられているデータベース・メッセージ・キューイング機能です。

アプリケーションによるデータ・コピーのメンテナンスでは、高レベルの可用性が実現可能ですが、大限の注意が必要です。通常、多くのカスタム開発が必要になります。Oracle Data Guard や Streams レプリケーションなどのソリューションによって分析および解決されてきた難しい境界条件の多くを、カスタム・アプリケーションの開発者が再分析し解決する必要があります。また、Oracle Data Guard や Streams レプリケーションのような標準ソリューションは、オラクル社と顧客の両方による厳密なテストを通過しています。カスタム開発のソリューションが同じ程度の完成度を示すまでには、大変な労力が必要です。これら


Streams 高可用性環境の最良の実施例

の理由から、アプリケーションによるコピーのメンテナンス機能を持つ高可用性ソリューションの構築は、時間と専門技術が十分にある組織のみが行うようにします。

Streams 高可用性環境の最良の実施例高可用性環境の最良の実施例高可用性環境の最良の実施例高可用性環境の最良の実施例高可用性環境に Streams を実装するには、発生する可能性のある障害とリカバリでの使用例を考慮し、障害発生後にも Streams で引き続き変更を取得、伝播および適用できるプロシージャを実装する必要があります。次の項目を確認します。

� 高可用性のための Streams の構成

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

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

� Streams を使用した Oracle Real Application Clusters の構成

� Streams を使用したローカル取得またはダウンストリーム取得

� 障害からのリカバリ

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

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

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

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

ここでは、これらの項目を説明します。

高可用性のための高可用性のための高可用性のための高可用性のための Streams の構成の構成の構成の構成Streams を使用したソリューションを構成する場合、障害を予想し、アーキテクチャ内に可用性を組み込んで設計することが重要です。分散システム内の各データベースを調べ、そのデータベースに障害が発生した場合のリカバリ・プランを設計する必要があります。データベース障害の影響する対象が、そのデータベースのデータにアクセスするサービスのみの場合もあれば、他のデータベースにも影響して、障害が拡大する場合もあります。

データベースとその他の各データベースとの直接接続データベースとその他の各データベースとの直接接続データベースとその他の各データベースとの直接接続データベースとその他の各データベースとの直接接続分散システム内の各データベースがその他すべてのデータベースと個々に直接接続した構成では、1 つのデータベースに障害が発生しても他のデータベースでの操作または通信を妨げないため、障害に対しても耐性があります。すべてのデータがレプリケートされていれば、障害の発生したデータベースを使用していたサービスは、障害の発生していないレプリカに接続できます。

参照参照参照参照 : アドバンスト・キューイングを使用したアプリケーション開発の詳細は、『Oracle Streams アドバンスト・キューイング・ユーザーズ・ガイドおよびリファレンス』を参照してください。



ハブ・アンド・スポーク構成の作成ハブ・アンド・スポーク構成の作成ハブ・アンド・スポーク構成の作成ハブ・アンド・スポーク構成の作成各データベースがその他すべてのデータベースと個々に直接接続された構成では、高の高可用性特性が提供されますが、データベースの数が増加すると管理が困難になります。この管理上の問題は、ハブ・アンド・スポーク構成で、多くのデータベースからの変更をハブ・データベースを介してから他のハブ・データベースまたは他のスポーク・データベースに伝播することによって解決されます。新規ソースまたは接続先の追加は、データベースごとに接続を確立するのではなく、ハブ・データベースへの接続を行うのみです。

ただし、ハブは分散環境において非常に重要なノードになります。それに障害が発生すると、ハブを介して行われるすべての通信に障害が発生します。ハブを介して伝播するイベントは非同期な性質を持つため、あるハブから別のハブにストリームをリダイレクトすることは非常に困難です。適切なアプローチとは、ハブを障害に対して耐性がある状態にすることです。

単一データベースを障害に対して耐性がある状態にするために使用した手法は、分散ハブ・データベースにも適用されます。インスタンスおよびノードの障害からの保護には、Oracle RAC を使用することをお薦めします。障害とデータ・エラーから保護するためには、この構成を損失のないフィジカル・スタンバイ・データベースと結合する必要があります。障害とデータ・エラーからの保護方法として Streams レプリカのみを使用することは、お薦めしません。

Streams を使用したを使用したを使用したを使用した Oracle Real Application Clusters の構成の構成の構成の構成Oracle RAC を Streams と併用する場合、いくつかの重要な考慮事項があります。取得プロセスは、Oracle RAC クラスタ内での実行時に、取得された論理変更レコード（LCR）を受信中のキューを所有しているインスタンス上で実行されます。ジョブ・キューはすべてのインスタンス上で実行されている必要があり、インスタンス上で実行中の伝播ジョブによって、インスタンスで所有されているキューの LCR が宛先キューに伝播されます。適用プロセスは、適用プロセスによってイベントがデキューされるキューを所有しているインスタンス上で実行されます。取得が実行されるキューと同じ場合と、同じでない場合があります。

Oracle RAC を実行中のデータベースへの伝播は、データベース・リンクを介して行われます。データベース・リンクは、イベントを受信予定のキューを所有している宛先インスタンスに接続するように構成する必要があります。

システム障害からの保護には、Oracle RAC ではなくコールド・フェイルオーバー・クラスタを使用できます。コールド・フェイルオーバー・クラスタは Oracle Real Application


� このような環境の詳細な例は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。

� 3-7 ページの「キューによる転送と適用による転送」

参照参照参照参照 : このような環境の詳細な例は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。



Clusters ではありません。かわりに、コールド・フェイルオーバー・クラスタでは、初のノードに障害が発生すると、2 番目のノードを使用してデータベースがマウントおよびリカバリされます。

Streams を使用したローカル取得またはダウンストリーム取得を使用したローカル取得またはダウンストリーム取得を使用したローカル取得またはダウンストリーム取得を使用したローカル取得またはダウンストリーム取得Oracle Database 10g では、Streams を使用して、ローカル・ソース・データベース、または異なるサイトのダウンストリーム・データベースに存在する REDO ログ内の変更を取得できます。ローカル取得またはダウンストリーム取得の選択は、可用性に影響を及ぼします。ソース・データベースに障害が発生した場合、一部の変更は取得されていない場合があります。ローカル取得の場合、それらの変更はソース・データベースがリカバリされるまで取得できない場合があります。突発的な障害が発生した場合、変更が失われる場合があります。

リモート・データベースでダウンストリーム取得を実行すると、障害発生時のデータ消失の可能性が減少します。構成によっては、ダウンストリーム取得を使用して、ソース・データベースでコミットされたすべての変更が安全にリモート・サイトにコピーされることを保証できます。リモート・サイトでは、それらの変更を他のデータベースやアプリケーションに取得および伝播できます。Streams は、Oracle Data Guard と同じメカニズムを使用してリモートの接続先にログ・ファイルをコピーし、大限の保護、大の可用性、大限のパフォーマンスなどの、同じ操作モードをサポートします。

障害からのリカバリ障害からのリカバリ障害からのリカバリ障害からのリカバリここでは、障害からのリカバリの良の実施例を説明します。

フェイルオーバー後の取得プロセスの自動的な再起動フェイルオーバー後の取得プロセスの自動的な再起動フェイルオーバー後の取得プロセスの自動的な再起動フェイルオーバー後の取得プロセスの自動的な再起動障害発生後に単一ノードのデータベースが再起動されるか、または障害発生後にコールド・フェイルオーバー・クラスタ内の別のノード上にあるデータベースが再起動されると、取得プロセスは障害発生時の状態に自動的に戻ります。つまり、障害発生時に取得プロセスが実行中であった場合は、再起動の必要はありません。

同様に、Oracle RAC 環境内で実行されている取得プロセスについては、取得プロセスを実行しているインスタンスに障害が発生した場合、取得された LCR を受信するキューはクラスタ内の別のノードに割り当てられ、取得プロセスは自動的に再起動されます。現在の所有



� 3-13 ページの「SYS.AnyData キューと Oracle Real Application Clusters」


参照参照参照参照 : 2-14 ページの「ローカル取得とダウンストリーム取得」



者インスタンスが使用不可能になった場合、取得プロセスは別のインスタンスに対するキューに従い、そのキュー自体はプライマリ・インスタンスおよびセカンダリ・インスタンスの所有権に関するルールに従います。

フェイルオーバー後のデータベース・リンクの再確立フェイルオーバー後のデータベース・リンクの再確立フェイルオーバー後のデータベース・リンクの再確立フェイルオーバー後のデータベース・リンクの再確立接続先データベースのインスタンスで障害が発生した後も、伝播が引き続き機能することは重要です。障害発生後、伝播ジョブでは接続が再確立されるまでデータベース・リンクが 16回再試行されます（再試行と次の再試行との間隔は徐々に長くなります）。16 回目の再試行後も接続が再確立されない場合、伝播スケジュールは無効になります。

データベースが同じノード、またはコールド・フェイルオーバー・クラスタ内の別のノードで再起動された場合、接続の再確立が必要になります。状況によってはデータベース・リンクが読取りまたは書込みを待機している場合があり、冗長なタイムアウトが期限切れになるまで、障害は検出されません。タイムアウトは、TCP_KEEPALIVE_INTERVAL TCP/IP パラメータによって制御されます。このような場合は、データベース・リンクを一度削除してから再作成し、通信が迅速に再確立されるようにする必要があります。

Oracle RAC クラスタ内の 1 つのインスタンスに障害が発生した場合、そのインスタンスはクラスタ内の別のノードによってリカバリされます。障害の発生したインスタンスで以前所有されていた各キューは、新規インスタンスに割り当てられます。障害発生インスタンスに、伝播に関する 1 つ以上の宛先キューが含まれる場合、インバウンド・データベース・リンクを削除して、宛先キューを所有している新規インスタンスを指すように再確立する必要があります。再作成されたデータベース・リンクを使用する伝播を変更する必要はありません。

高可用性環境では、必要なデータベース・リンクすべてを削除および再作成するスクリプトを準備することが考えられます。フェイルオーバー後、これらのスクリプトを実行し、Streams で伝播を再開できます。



� 9-24 ページの「取得プロセスの起動」

� キューに対するプライマリ・インスタンスおよびセカンダリ・インスタンスの所有権の詳細は、3-13 ページの「SYS.AnyData キューとOracle Real Application Clusters」を参照してください。



フェイルオーバー後の伝播ジョブの再起動フェイルオーバー後の伝播ジョブの再起動フェイルオーバー後の伝播ジョブの再起動フェイルオーバー後の伝播ジョブの再起動イベントをソース・キューから宛先キューに伝播させるには、ソース・キューを所有しているインスタンス上で伝播ジョブを実行する必要があります。単一ノードのデータベースまたはコールド・フェイルオーバー・クラスタでは、単一データベース・インスタンスが再起動されると伝播が再開されます。

Oracle RAC 環境では、伝播ジョブは、宛先キューにイベントを送信するソース・キューを所有するインスタンス上で実行されます。伝播ジョブの所有者インスタンスが停止した場合、伝播ジョブは新しい所有者インスタンスに自動的に移行されます。Streams 伝播ジョブのインスタンス・アフィニティは Streams によって自動的に管理されるため、変更しないでください。また、インスタンス上で実行されるジョブについて、そのインスタンスの変更可能な初期化パラメータ JOB_QUEUE_PROCESSESを 0（ゼロ）より大きい値に設定する必要があります。

フェイルオーバー後の適用プロセスの自動的な再起動フェイルオーバー後の適用プロセスの自動的な再起動フェイルオーバー後の適用プロセスの自動的な再起動フェイルオーバー後の適用プロセスの自動的な再起動障害発生後に、単一ノードのデータベースが再起動されるか、またはコールド・フェイルオーバー・クラスタ内の別のノード上にあるデータベースが再起動されると、適用プロセスは障害発生時の状態に自動的に戻ります。つまり、障害発生時に適用プロセスが実行中であった場合は、再起動の必要はありません。

同様に、Oracle RAC クラスタ内では、適用プロセスをホスティングするインスタンスに障害が発生した場合、適用プロセスによってイベントがデキューされるキューはクラスタ内の別のノードに割り当てられ、適用プロセスは自動的に再起動されます。現在の所有者インスタンスが使用不可能になった場合、適用プロセスは別のインスタンスに対するキューに従い、そのキュー自体はプライマリ・インスタンスおよびセカンダリ・インスタンスの所有権に関するルールに従います。


� Streams 環境でデータベース・リンクを作成する方法の詳細は、8-11ページの「ネットワーク接続性とデータベース・リンクの構成」を参照してください。

� RAC 環境のデータベース・リンクの詳細は、3-13 ページの「SYS.AnyData キューと Oracle Real Application Clusters」を参照してください。

参照参照参照参照 : 3-13 ページの「SYS.AnyData キューと Oracle Real Application Clusters」





� 11-9 ページの「適用プロセスの起動」

� キューに対するプライマリ・インスタンスおよびセカンダリ・インスタンスの所有権の詳細は、3-13 ページの「SYS.AnyData キューとOracle Real Application Clusters」を参照してください。




第第第第 II 部部部部
Streams の管理の管理の管理の管理
第 II 部では、構成、管理、監視およびトラブルシューティングの手順など、Streams 環境の管理について説明します。第 II 部の構成は、次のとおりです。

� 第 8 章「Streams 環境の準備」

� 第 9 章「取得プロセスの管理」

� 第 10 章「ステージングと伝播の管理」

� 第 11 章「適用プロセスの管理」


� 第 13 章「その他の Streams 管理タスク」

� 第 14 章「Streams 環境の監視」

� 第 15 章「Streams 環境のトラブルシューティング」

Streams 環境の

8
Streams 環境の準備環境の準備環境の準備環境の準備
この章では、Streams を使用するためにデータベースまたは分散データベース環境を準備する手順と、Streams 環境を構成する手順について説明します。


� Streams 管理者の構成

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

� Streams の取得プロセスを実行するためのデータベースの準備

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

準備 8-1

Streams 管理者の構成

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

次の手順に従って、Streams を使用する環境内の各データベースで Streams 管理者を構成します。

1. SQL*Plus で、ユーザーの作成、権限の付与および表領域の作成を行うことができる管理ユーザーとして接続します。これ以降のすべての手順は、この管理ユーザーとして接続したままで実行します。

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

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

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

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

4. Streams 管理者に CONNECTおよび RESOURCEロールを付与し、この管理者がデータベースへ接続して自分のスキーマ内の様々な型のデータベース・オブジェクトを管理できるようにします。また、Streams 管理者に DBAロールを付与します。

GRANT CONNECT, RESOURCE, DBA TO strmadmin;

5. オプションで、DBMS_STREAMS_AUTHパッケージの GRANT_ADMIN_PRIVILEGEプロシージャを実行します。次の条件が満たされている場合は、手順 3 で作成した Streams管理者に対してこのプロシージャを実行できます。

� Streams 管理者が、Streams に関連付けられた Oracle 提供パッケージのサブプログラムを実行するユーザー作成サブプログラムを実行する。例としては、DBMS_STREAMS_ADMパッケージのプロシージャを実行するユーザー作成ストアド・プロシージャがあります。

注意注意注意注意 : セキュリティを確保するために、Streams 管理者にはstrmadminpw以外のパスワードを使用してください。



� Streams 管理者が、Streams に関連付けられたデータ・ディクショナリ・ビューを問い合せるサブプログラムを実行するユーザー作成サブプログラムを実行する。例としては、DBA_APPLY_ERRORデータ・ディクショナリ・ビューを問い合せるユーザー作成ストアド・プロシージャがあります。

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

GRANT_ADMIN_PRIVILEGEプロシージャのパラメータの設定に応じて、Streams 管理者として作業を行うために必要な権限が直接付与されるか、またはこれらの権限を付与するために編集および実行可能なスクリプトが生成されます。

GRANT_ADMIN_PRIVILEGEプロシージャを使用した権限の直接付与プロシージャを使用した権限の直接付与プロシージャを使用した権限の直接付与プロシージャを使用した権限の直接付与 :

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

GRANT_ADMIN_PRIVILEGEプロシージャを使用したスクリプトの生成プロシージャを使用したスクリプトの生成プロシージャを使用したスクリプトの生成プロシージャを使用したスクリプトの生成 :

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

CREATE DIRECTORY admin_dir AS '/usr/admin';

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

BEGIN DBMS_STREAMS_AUTH.GRANT_ADMIN_PRIVILEGE( grantee => 'strmadmin', grant_privileges => false, file_name => 'grant_strms_privs.sql', directory_name => 'admin_dir');

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

Streams 環境の準備 8-3


END;/

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

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

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

SET ECHO ONSPOOL grant_strms_privs.out@/usr/admin/grant_strms_privs.sqlSPOOL OFF

e. スプール・ファイルをチェックして、すべての権限付与が正常に実行されたことを確認します。エラーが発生した場合、スクリプトを編集してエラーを修正した後で、スクリプトを再実行します。

6. 必要に応じて、Streams 管理者に次の権限を付与します。

� Streams 以外のデータ・ディクショナリ・ビューを問い合せるためのユーザー権限を付与する場合は、SELECT_CATALOG_ROLE。

� Oracle Enterprise Manager コンソールの Streams ツールを使用する予定の場合は、SELECT ANY DICTIONARY権限。

� 適用プロセスの適用ユーザーを指定しない場合は、他のユーザーが所有する適用オブジェクトに対して DML 変更と DDL 変更を実行するために必要な権限。適用ユーザーを指定する場合、適用ユーザーにはこれらの権限が必要です。

� 適用プロセスの適用ユーザーを指定しない場合は、Streams の適用プロセスで実行される他のユーザー所有の PL/SQL プロシージャの EXECUTE権限。これらのプロシージャは、適用ハンドラまたはエラー・ハンドラで使用できます。適用ユーザーを指定する場合、適用ユーザーにはこれらの権限が必要です。

� Streams の取得プロセス、伝播、適用プロセスまたはメッセージ・クライアントで使用されるルールについてルールベースの変換で指定されている、他のユーザー所有の PL/SQL ファンクションの EXECUTE権限。取得プロセスの取得ユーザーを指定する場合、その取得ユーザーにはこれらの権限が必要です。適用プロセスの適用ユーザーを指定する場合、その適用ユーザーにはこれらの権限が必要です。

� 必要に応じてデータベース・オブジェクトを変更するための権限。たとえば、Streams 管理者が別のスキーマ内の表のサプリメンタル・ログ・グループを作成する必要がある場合、Streams 管理者は、表を変更するために必要な権限を持っている必要があります。


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

� Streams 管理者が Streams の取得プロセス、伝播、適用プロセスまたはメッセージ・クライアントで使用されるキューを所有しておらず、キューの作成時にそのキューのキュー・ユーザーとして指定されていない場合、Streams 管理者がキューのイベントをエンキューまたはデキューできるようにするには、Streams 管理者をキューの保護キュー・ユーザーとして構成する必要があります。また、Streams 管理者には、キューの ENQUEUE権限または DEQUEUE権限、あるいはその両方が必要になる場合があります。手順については、10-3 ページの「保護キューでのユーザー操作の有効化」を参照してください。

� Streams 管理者によるアクセスが必要となる可能性があるすべてのオブジェクト型の EXECUTE権限。

7. 前述のすべての手順を、Streams を使用する環境内のデータベースごとに繰り返します。

Streams に関連する初期化パラメータの設定に関連する初期化パラメータの設定に関連する初期化パラメータの設定に関連する初期化パラメータの設定表 8-1 に、Streams 環境の操作、信頼性およびパフォーマンスに重要な初期化パラメータを示します。これらのパラメータを、Streams 環境に合わせて適切に設定してください。この表では、各パラメータが変更可能かどうかを示します。変更可能な初期化パラメータは、インスタンスの実行中に ALTER SESSION文または ALTER SYSTEM文を使用して変更できます。

参照参照参照参照 : 14-4 ページの「Streams 管理者およびその他の Streams ユーザーの監視」

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

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

パラメータパラメータパラメータパラメータ値値値値説明説明説明説明

COMPATIBLE デフォルトデフォルトデフォルトデフォルト : 9.2.0

範囲範囲範囲範囲 : 9.2.0～現行リリース番号

変更変更変更変更 : 不可能

このパラメータでは、Oracle サーバーが

互換性を維持する必要のあるリリースを指定します。互換レベルの異なる Oracleサーバーを相互運用できます。

Oracle Database 10g で導入された

Streams の新機能を使用するには、この

パラメータを 10.1.0以上に設定する必

要があります。ダウンストリーム取得を使用するには、ソース・データベースとダウンストリーム・データベースの両方で、このパラメータを 10.1.0以上に設

定する必要があります。



GLOBAL_NAMES デフォルトデフォルトデフォルトデフォルト : false

範囲範囲範囲範囲 : trueまたは false

変更変更変更変更 : 可能

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

Streams を使用してデータベース間で情

報を共有するには、Streams 環境の各

データベースでこのパラメータを trueに設定します。

JOB_QUEUE_PROCESSES デフォルトデフォルトデフォルトデフォルト : 0

範囲範囲範囲範囲 : 0～ 1000


各インスタンス（J000 ... J999）用の

Jn ジョブ・キュー・プロセスの数を指

定します。ジョブ・キュー・プロセスでは、DBMS_JOBによって作成された要求

が処理されます。

このパラメータは、Streams 環境でイベ

ントを伝播する各データベースで 2以上

に設定し、同時に実行できる大ジョブ数に 2 を加えた値に設定する必要があり

ます。

LOG_ARCHIVE_DEST_n デフォルトデフォルトデフォルトデフォルト : なし

範囲範囲範囲範囲 : なし


10 以下のログ・アーカイブの宛先を定義

します（nは 1、2、3 ... 10）。

ダウンストリーム取得を使用したり、ログ転送サービスを使用して REDO ログ・

ファイルをダウンストリーム・データベースへコピーするには、ダウンストリーム取得プロセスを実行しているサイトに、1 つ以上のログ・アーカイブの宛

先が存在する必要があります。

参照参照参照参照 : 『Oracle Data Guard 概要および

管理』

LOG_ARCHIVE_DEST_STATE_n デフォルトデフォルトデフォルトデフォルト : enable

範囲範囲範囲範囲 : 次のいずれか :

� alternate

� reset

� defer

� enable


対応する宛先の使用状態を指定します。パラメータ接尾辞（1～ 10）で、対応す

る 10 の LOG_ARCHIVE_DEST_n 宛先パ

ラメータのいずれかを指定します。


ファイルをダウンストリーム・データベースへコピーするには、ダウンストリーム・データベースのLOG_ARCHIVE_DEST_nの宛先に対応す

る宛先が、enableに設定されているこ

とを確認してください。

表表表表 8-1 Streams に関連する初期化パラメータに関連する初期化パラメータに関連する初期化パラメータに関連する初期化パラメータ（続き）（続き）（続き）（続き）




OPEN_LINKS デフォルトデフォルトデフォルトデフォルト : 4



1 つのセッション中のリモート・データ

ベースへの同時オープン接続の大数を指定します。これらの接続には、データベース・リンク、外部プロシージャおよび外部カートリッジが含まれ、それぞれが別個のプロセスを使用します。

Streams 環境では、このパラメータがデ

フォルト値の 4以上に設定されているこ

とを確認してください。

PARALLEL_MAX_SERVERS デフォルトデフォルトデフォルトデフォルト : 次のパラメータの値から

導出

CPU_COUNT

PARALLEL_ADAPTIVE_MULTI_USER

PARALLEL_AUTOMATIC_TUNING



1 インスタンスのパラレル実行プロセス

とパラレル・リカバリ・プロセスの大数を指定します。Oracle では、必要に応

じて、プロセス数がインスタンス起動時に作成された数からこの値まで増やされます。

Streams 環境では、各取得プロセスと適

用プロセスが複数のパラレル実行サーバーを使用できます。十分な数のパラレル実行サーバーを使用できるように、この初期化パラメータを適切な値に設定してください。

PROCESSES デフォルトデフォルトデフォルトデフォルト : PARALLEL_MAX_SERVERSから導出

範囲範囲範囲範囲 : 6～オペレーティング・システ

ム依存の上限


Oracle に同時に接続できるオペレーティ

ング・システムのユーザー・プロセスの大数を指定します。

このパラメータの値が、ロック、ジョブ・キュー・プロセス、パラレル実行プロセスなど、すべてのバックグラウンド・プロセスを見込んでいることを確認してください。Streams では、取得プロ

セスと適用プロセスはバックグラウンド・プロセスとパラレル実行プロセスを使用し、伝播ジョブはジョブ・キュー・プロセスを使用します。

REMOTE_ARCHIVE_ENABLE デフォルトデフォルトデフォルトデフォルト : true



リモートの宛先へのアーカイブ REDO の

送信、およびアーカイブ REDO ログのリ

モート受信を可能にするかどうかを指定します。


ファイルをダウンストリーム・データベースへコピーするには、ソース・データベースとダウンストリーム・データベースの両方で、このパラメータをtrueに設定する必要があります。





SESSIONS デフォルトデフォルトデフォルトデフォルト : 次の式から導出

(1.1 * PROCESSES) + 5



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

1 つのデータベース上で 1 つ以上の取得

プロセスまたは適用プロセスを実行するには、このパラメータの値の増加が必要になることがあります。データベースの各バックグラウンド・プロセスにはセッションが必要です。

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

イズ

範囲範囲範囲範囲 : 0～オペレーティング・システ

ム依存の上限


データベース・インスタンスの存続期間中における SGA の大サイズを指定し

ます。

1 つのデータベース上で複数の取得プロ

セスを実行するには、このパラメータの値の増加が必要になることがあります。

SHARED_POOL_SIZE デフォルトデフォルトデフォルトデフォルト :

32 ビット・プラットフォームの場合 : 32MB、近似のグラニュル・サイズ

に切上げ

64 ビット・プラットフォームの場合 : 84MB、近似のグラニュル・サイズ

に切上げ

範囲範囲範囲範囲 :

小値 : グラニュル・サイズ

大値 : オペレーティング・システム

依存


共有プールのサイズ（バイト単位）を指定します。共有プールには、共有カーソル、ストアド・プロシージャ、制御構造およびその他の構造が格納されます。

STREAMS_POOL_SIZE初期化パラメー

タが 0（ゼロ）に設定されている場合、

Streams は、共有プールの大 10% まで

使用できます。





STREAMS_POOL_SIZE デフォルトデフォルトデフォルトデフォルト : 0

範囲範囲範囲範囲 :

小値 : 0

大値 : オペレーティング・システム

依存


Streams プールのサイズ（バイト単位）

を指定します。Streams プールには、取

得イベントが格納されます。また、Streams プールは、パラレル取得および

パラレル適用中の内部通信に使用されます。

Streams プールのサイズが 0（ゼロ）よ

り大きい場合、Streams によって使用さ

れる SGA メモリーは Streams プールか

ら割り当てられます。Streams プールの

サイズが 0（ゼロ）に設定されている場

合、Streams によって使用される SGA メ

モリーは共有プールから割り当てられます（共有プールの大 10% まで使用でき

ます）。

このパラメータは変更可能です。ただし、インスタンス起動時にこのパラメータが 0（ゼロ）に設定されている場合、

パラメータに 0（ゼロ）より大きい値を

設定しても、現行のインスタンスには影響しません。これは、現行のインスタンスは、Streams の割当てに共有プールを

使用しているためです。また、インスタンス起動時にこのパラメータが 0（ゼロ）

より大きい値に設定されており、その後、インスタンスの実行中に 0（ゼロ）

に設定された場合、Streams のプロセス

およびジョブは実行されません。

次の各要素に対して、Streams プールの

サイズを増加する必要があります。

� 取得プロセスの各並列性に対して10MB

� 適用プロセスの各並列性に対して1MB

� 取得イベントをステージングする各キューに対して 10MB 以上

たとえば、取得プロセスの並列性が 3に

設定されている場合、Streams プールを

30MB 増加します。適用プロセスの並列

性が 5に設定されている場合、Streamsプールを 5MB 増加します。





TIMED_STATISTICS デフォルトデフォルトデフォルトデフォルト :

STATISTICS_LEVELの設定が

TYPICALまたは ALLの場合は true

STATISTICS_LEVELの設定が

BASICの場合は false

STATISTICS_LEVELのデフォルトはTYPICAL



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

Streams に関連する動的パフォーマン

ス・ビューの経過時間の統計を収集するには、このパラメータを trueに設定し

ます。経過時間の統計を含むビューにはV$STREAMS_CAPTURE、V$STREAMS_APPLY_COORDINATOR、V$STREAMS_APPLY_READERおよび

V$STREAMS_APPLY_SERVERが含まれ

ます。

UNDO_RETENTION デフォルトデフォルトデフォルトデフォルト : 900

範囲範囲範囲範囲 : 0～ 232-1（32 ビットで表され

る大値）


データベースに保持する、コミット済のUNDO 情報の量（秒単位）を指定しま

す。

1 つ以上の取得プロセスを実行している

データベースの場合、このパラメータに適切な UNDO 保持期間を指定している

ことを確認してください。

1 つ以上の取得プロセスを実行中に設定

が適切かどうかを確認できない場合は、このパラメータを 3600以上に設定しま

す。スナップショットが古すぎるというエラーが発生した場合は、そのエラーが発生しなくなるまでこのパラメータの設定値を増加します。UNDO 表領域に、

UNDO_RETENTION設定に対応できる十

分な領域があることを確認してください。

参照参照参照参照 : 保持期間および UNDO 表領域の

詳細は、『Oracle Database 管理者ガイ

ド』を参照してください。




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

Streams の取得プロセスを実行するためのデータベースの準備の取得プロセスを実行するためのデータベースの準備の取得プロセスを実行するためのデータベースの準備の取得プロセスを実行するためのデータベースの準備取得プロセスによって取得される REDO ログ情報を生成するすべてのソース・データベースは、ARCHIVELOGモードで実行する必要があります。また、取得プロセスを実行するすべてのデータベース上で初期化パラメータが適切に設定されていることを確認してください。

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

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

� Oracle 以外のデータベースの場合は、Oracle ゲートウェイを Oracle データベースとOracle 以外のデータベースとの通信用に構成します。

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

たとえば、Streams 管理者 strmadminとして接続するデータベース dbs2.netへのデータベース・リンクを作成するには、次の文を実行します。

CREATE DATABASE LINK dbs2.net CONNECT TO strmadmin IDENTIFIED BY strmadminpw USING 'dbs2.net';


� 2-42 ページの「ARCHIVELOG モードと取得プロセス」

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


参照参照参照参照 : 『Oracle Net Services 管理者ガイド』

参照参照参照参照 : 『Oracle Database Heterogeneous Connectivity 管理者ガイド』

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


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


取得プロセスの

9
取得プロセスの管理取得プロセスの管理取得プロセスの管理取得プロセスの管理
取得プロセスは、REDO ログ内の変更を取得し、取得した変更を論理変更レコード（LCR）形式で再フォーマットして、LCR を SYS.AnyDataキューにエンキューします。


� 取得プロセスの作成

� 取得プロセスの起動、停止および削除

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

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

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

� ソース・データベースでのサプリメンタル・ロギングの指定

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

� 既存の取得プロセスの SCN 値の設定

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

� 取得 LCR 内の追加の属性の管理

この章で説明する各タスクは、特に明記されていないかぎり、適切な権限を付与されているStreams 管理者が完了する必要があります。



� 8-2 ページの「Streams 管理者の構成」

管理 9-1

取得プロセスの作成

取得プロセスの作成取得プロセスの作成取得プロセスの作成取得プロセスの作成ローカルのソース・データベースの変更を取得する取得プロセス、またはダウンストリーム・データベースで変更をリモートに取得する取得プロセスを作成できます。取得プロセスがダウンストリーム・データベースで実行される場合、ソース・データベースの REDO ログ・ファイルはダウンストリーム・データベースにコピーされ、取得プロセスが、そのダウンストリーム・データベースでこれらの REDO ログ・ファイル内の変更を取得します。

次のどのプロシージャでも、ローカルの取得プロセスを作成できます。





� DBMS_CAPTURE_ADM.CREATE_CAPTURE

DBMS_STREAMS_ADMパッケージの各プロシージャでは、指定した名前の取得プロセスが存在しない場合は取得プロセスが作成され、取得プロセスにポジティブ・ルール・セットまたはネガティブ・ルール・セットが存在しない場合はそのいずれかのルール・セットが作成されます。また、ルール・セットに表ルール、スキーマ・ルールまたはグローバル・ルールを追加できます。

CREATE_CAPTUREプロシージャでは、取得プロセスは作成されますが、そのルール・セットやルールは作成されません。ただし、CREATE_CAPTUREプロシージャを使用すると、取得プロセスにポジティブ・ルール・セットまたはネガティブ・ルール・セットのいずれかとして関連付ける既存のルール・セットと、取得プロセスの先頭 SCN および開始 SCN を指定できます。ダウンストリーム取得を実行する取得プロセスを作成するには、CREATE_CAPTUREプロシージャを使用する必要があります。

注意注意注意注意 : 取得プロセスを起動または再起動する場合、開始 SCN 以下のFIRST_CHANGE#値が含まれる REDO ログ・ファイルをスキャンする必要があります。必要な REDO ログ・ファイルを取得プロセスがスキャンする前に削除すると、取得プロセスが異常終了します。先頭 SCN、開始SCN および必須チェックポイント SCN を判別するには、DBA_CAPTUREデータ・ディクショナリ・ビューを問い合せます。取得プロセスには、必須チェックポイント SCN が含まれる REDO ログ・ファイルおよびすべての後続の REDO ログ・ファイルが必要です。取得プロセスの先頭 SCN および開始 SCN の詳細は、2-29 ページの「取得プロセスの作成」を参照してください。



取得プロセスを作成する前に、次のタスクを完了する必要があります。

� 8-11 ページの「Streams の取得プロセスを実行するためのデータベースの準備」で説明したタスクを完了します。

� 存在しない場合は、取得プロセスに関連付ける SYS.AnyDataキューを作成します。手順については、10-2 ページの「SYS.AnyData キューの作成」を参照してください。


� ローカルの取得プロセスの作成

� ログ・ファイルを暗黙的に割り当てるダウンストリーム取得プロセスの作成

� ログ・ファイルを明示的に割り当てるダウンストリーム取得プロセスの作成

� NULL 以外の開始 SCN を持つローカルの取得プロセスの作成

ローカルの取得プロセスの作成ローカルの取得プロセスの作成ローカルの取得プロセスの作成ローカルの取得プロセスの作成この項では、DBMS_STREAMS_ADMパッケージおよび DBMS_CAPTURE_ADMパッケージを使用してローカルの取得プロセスを作成する方法について説明します。


� 取得プロセスを作成した後は、その取得プロセスのソース・データベースの DBIDまたはグローバル名を変更しないでください。ソース・データベースの DBIDまたはグローバル名のいずれかを変更した場合、その取得プロセスを削除して再作成する必要があります。

� 取得プロセスを作成するには、ユーザーに DBAロールが付与されている必要があります。




� ソース・データベースの DBID またはグローバル名の変更については、『Oracle Streams レプリケーション管理者ガイド』を参照してください。

取得プロセスの管理 9-3


DBMS_STREAMS_ADM を使用したローカルの取得プロセスの作成例を使用したローカルの取得プロセスの作成例を使用したローカルの取得プロセスの作成例を使用したローカルの取得プロセスの作成例ここでは、DBMS_STREAMS_ADMパッケージの ADD_TABLE_RULESプロシージャを実行してローカルの取得プロセスを作成する例について説明します。

BEGIN DBMS_STREAMS_ADM.ADD_TABLE_RULES( table_name => 'hr.employees', streams_type => 'capture', streams_name => 'strm01_capture', queue_name => 'strm01_queue', include_dml => true, include_ddl => true, include_tagged_lcr => false, source_database => NULL, inclusion_rule => true);END;/

このプロシージャを実行すると、次のアクションが実行されます。

� 取得プロセス strm01_captureが作成されます。この取得プロセスが作成されるのは、それが存在しない場合のみです。新規の取得プロセスが作成される場合、このプロシージャでは開始 SCN も作成時点に設定されます。

� 取得プロセスが、既存のキュー strm01_queueに関連付けられます。

� inclusion_ruleパラメータが trueに設定されているため、取得プロセスにポジティブ・ルール・セットが存在しない場合は、ポジティブ・ルール・セットが作成され、取得プロセスに関連付けられます。このルール・セットでは、SYS.STREAMS$_EVALUATION_CONTEXT評価コンテキストが使用されます。ルール・セット名は、システムによって指定されます。

� 2 つのルールが作成されます。一方のルールは hr.employees表に対する DML 変更について TRUEと評価され、他方のルールは hr.employees表に対する DDL 変更について TRUEと評価されます。ルール名は、システムによって指定されます。

� この 2 つのルールが、取得プロセスに関連付けられたポジティブ・ルール・セットに追加されます。これらのルールがポジティブ・ルール・セットに追加されるのは、inclusion_ruleパラメータが trueに設定されているためです。

� include_tagged_lcrパラメータが falseに設定されているため、変更に NULLタグが付いている場合にのみ、取得プロセスで REDO ログ内の変更を取得するように指定されます。この動作は、取得プロセスのシステム作成ルールを介して実行されます。

� source_databaseパラメータが NULLに設定されているため、ソース・データベースのローカルの変更を取得する取得プロセスが作成されます。ローカルの取得プロセスでは、このパラメータに対するローカル・データベースのグローバル名も指定できます。

� hr.employees表がインスタンス化のために準備されます。



DBMS_CAPTURE_ADM を使用したローカルの取得プロセスの作成例を使用したローカルの取得プロセスの作成例を使用したローカルの取得プロセスの作成例を使用したローカルの取得プロセスの作成例ここでは、DBMS_CAPTURE_ADMパッケージの CREATE_CAPTUREプロシージャを実行してローカルの取得プロセスを作成する例について説明します。

BEGIN DBMS_CAPTURE_ADM.CREATE_CAPTURE( queue_name => 'strm02_queue', capture_name => 'strm02_capture', rule_set_name => 'strmadmin.strm01_rule_set', start_scn => NULL, source_database => NULL, use_database_link => false, first_scn => NULL);END;/


� 取得プロセス strm02_captureが作成されます。同じ名前の取得プロセスは存在できません。


� 取得プロセスが、既存のルール・セット strm01_rule_setに関連付けられます。このルール・セットは、取得プロセスのポジティブ・ルール・セットです。


� start_scnパラメータおよび first_scnパラメータが NULLに設定されているため、Oracle データベースによって取得プロセスの開始 SCN および先頭 SCN が決定されるように指定されます。

� ローカル・データベース上で、ローカルの変更を取得する他の取得プロセスが実行されていない場合、DBMS_CAPTURE_ADMパッケージの BUILDプロシージャが自動的に実行されます。このプロシージャが実行されると、データ・ディクショナリが REDO ログに抽出され、取得プロセスが初めて起動されるときに LogMiner データ・ディクショナリが作成されます。



� 6-6 ページの「システム作成ルール」




ログ・ファイルを暗黙的に割り当てるダウンストリーム取得プロセスの作成ログ・ファイルを暗黙的に割り当てるダウンストリーム取得プロセスの作成ログ・ファイルを暗黙的に割り当てるダウンストリーム取得プロセスの作成ログ・ファイルを暗黙的に割り当てるダウンストリーム取得プロセスの作成ダウンストリーム取得を実行する取得プロセスを作成するには、CREATE_CAPTUREプロシージャを使用する必要があります。ここでは、ソース・データベースへのデータベース・リンクを使用するダウンストリーム取得プロセス、およびそのリンクを使用しないダウンストリーム取得プロセスを作成する方法について説明します。どちらの例の場合にも、次のことを想定しています。

� ソース・データベースは dbs1.netで、ダウンストリーム・データベースは dbs2.netです。

� dbs2.netで作成される取得プロセスは、strm03_queueを使用します。

� この取得プロセスは、hr.departments表に対する DML 変更を取得します。

� この取得プロセスは、ログ・ファイルを暗黙的に割り当てます。ダウンストリーム取得プロセスでは、ソース・データベースからダウンストリーム・データベースにログ転送サービスによって追加されたか、または手動で追加された、すべての REDO ログ・ファイルが自動的にスキャンされます。

ダウンストリーム取得のためのダウンストリーム取得のためのダウンストリーム取得のためのダウンストリーム取得のための REDO ログ・ファイルのコピーの準備ログ・ファイルのコピーの準備ログ・ファイルのコピーの準備ログ・ファイルのコピーの準備ダウンストリーム・データベースからソース・データベースへのデータベース・リンクが使用されているかどうかに関係なく、次の手順に従って、ソース・データベースの REDO ログ・ファイルをダウンストリーム・データベースにコピーするための準備、およびダウンストリーム・データベースでそれらの REDO ログ・ファイルを受け入れるための準備を行う必要があります。

1. Oracle Net を、ソース・データベースがダウンストリーム・データベースと通信できるように構成します。

2. ログ転送サービスによってソース・データベースからダウンストリーム・データベースに REDO ログ・ファイルがコピーされるように、次の初期化パラメータを設定します。

� ソース・データベースの LOG_ARCHIVE_DEST_n初期化パラメータで、1 つ以上のアーカイブ・ログの格納場所を、ダウンストリーム・データベースが実行されているコンピュータ・システム上のディレクトリに設定します。これを行うには、このパラメータの次の属性を設定します。

– SERVICE: ダウンストリーム・データベースのネットワーク・サービス名を指定します。



� 2-21 ページの「取得プロセスに関連する SCN 値」

参照参照参照参照 : 『Oracle Net Services 管理者ガイド』



– ARCHまたは LGWR ASYNC: ARCH（デフォルト）を指定すると、アーカイブ・プロセス（ARCn）によって、REDO ログ・ファイルがダウンストリーム・データベースにアーカイブされます。LGWR ASYNCを指定すると、ログ・ライター・プロセス（LGWR）によって、REDO ログ・ファイルがダウンストリーム・データベースにアーカイブされます。ダウンストリーム・データベースへのコピーでは、ARCHまたは LGWR ASYNCのいずれかを指定できます。

– MANDATORY または OPTIONAL: MANDATORYを指定すると、ダウンストリーム・データベースへの REDO ログ・ファイルのアーカイブが正常に実行された後で、ソース・データベースの対応するオンライン REDO ログが上書きされます。OPTIONALを指定すると、ダウンストリーム・データベースへのREDO ログ・ファイルのアーカイブは必要なく、ソース・データベースの対応するオンライン REDO ログが上書きされます。ダウンストリーム・データベースへのコピーでは、MANDATORYまたは OPTIONALのいずれかを指定できます。

– NOREGISTER: この属性を指定すると、ダウンストリーム・データベースの位置が、ダウンストリーム・データベースの制御ファイルに記録されません。

– REOPEN: アーカイブ・プロセス（ARCn）によるダウンストリーム・データベース位置へのアクセスが失敗した場合、この位置へのアクセスを再試行するまでアーカイブ・プロセスが待機する小秒数を指定します。

– TEMPLATE: ダウンストリーム・データベースでのアーカイブ REDO ログ用のディレクトリおよびフォーマット・テンプレートを指定します。TEMPLATE属性は、ダウンストリーム・データベースの LOG_ARCHIVE_FORMAT初期化パラメータ設定をオーバーライドします。TEMPLATE属性は、リモートの接続先でのみ有効です。各ソース・データベースで、フォーマットに %t、%sおよび%rのすべての変数を使用していることを確認します。

ダウンストリーム・データベースを指定する LOG_ARCHIVE_DEST_n設定の例を次に示します。

LOG_ARCHIVE_DEST_2='SERVICE=DBS2.NET ARCH OPTIONAL NOREGISTER REOPEN=60 TEMPLATE=/usr/oracle/log_for_dbs1/dbs1_arch_%t_%s_%r.log'

他のソース・データベースによってログ・ファイルがこのダウンストリーム・データベースに転送される場合、そのソース・データベースの初期化パラメータ・ファイルで TEMPLATE属性を指定して、このダウンストリーム・データベースの別のディレクトリおよびフォーマットをそのログ・ファイル用に指定できます。これによって、各ソース・データベースからのログ・ファイルを、ダウンストリーム・データベースに個別に格納できます。

� ソース・データベースで、ダウンストリーム・データベースのLOG_ARCHIVE_DEST_nパラメータに対応する LOG_ARCHIVE_DEST_STATE_n初期化パラメータを enableに設定します。



たとえば、LOG_ARCHIVE_DEST_2初期化パラメータがダウンストリーム・データベース用に設定されている場合、1 つの LOG_ARCHIVE_DEST_STATE_2パラメータを次のとおり設定します。

LOG_ARCHIVE_DEST_STATE_2=enable

� ソース・データベースとダウンストリーム・データベースの両方で、REMOTE_ARCHIVE_ENABLE初期化パラメータを trueに設定します。

3. 手順 2 で、データベース上でインスタンスを実行中に初期化パラメータをリセットした場合、データベースが再起動されたときに新しい値が保持されるように、それらのパラメータを初期化パラメータ・ファイルでもリセットする必要があります。

手順 2 で、インスタンスの実行中に初期化パラメータをリセットせず、初期化パラメータ・ファイルでリセットした場合は、データベースを再起動します。ソース・データベースからダウンストリーム・データベースに REDO ログ・ファイルを送信するには、ソース・データベースがオープンされている必要があります。これは、ソース・データベースのグローバル名は、ソース・データベースがオープンである場合にのみダウンストリーム・データベースに送信されるためです。

4. ソース・データベース dbs1.netで、hr.departments表に主キーのサプリメンタル・ロギングを指定します。

ALTER TABLE hr.departments ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;

この項の例では hr.departmentsに対する変更を取得する取得プロセスを作成するため、この表の主キーのサプリメンタル・ロギングが必要です。

5. ダウンストリーム・データベースからソース・データベースへのデータベース・リンクを使用するかどうかに応じて、次のいずれかの項の手順を実行します。

� 9-8 ページの「データベース・リンクを使用するダウンストリーム取得プロセスの作成」

� 9-12 ページの「データベース・リンクを使用しないダウンストリーム取得プロセスの作成」

データベース・リンクを使用するダウンストリーム取得プロセスの作成データベース・リンクを使用するダウンストリーム取得プロセスの作成データベース・リンクを使用するダウンストリーム取得プロセスの作成データベース・リンクを使用するダウンストリーム取得プロセスの作成ここでは、DBMS_CAPTURE_ADMパッケージの CREATE_CAPTUREプロシージャを実行して、dbs1.netソース・データベースに対する変更を取得する取得プロセスを dbs2.netダウンストリーム・データベースに作成する例について説明します。この例の取得プロセスでは、管理用の dbs1.netへのデータベース・リンクが使用されます。

参照参照参照参照 : これらの初期化パラメータの詳細は、『Oracle Database リファレンス』および『Oracle Data Guard 概要および管理』を参照してください。



ダウンストリーム・データベース dbs2.netに Streams 管理者として接続し、次の手順を完了します。

1. dbs2.netから dbs1.netへのデータベース・リンクを作成します。たとえば、strmadminユーザーが両方のデータベースの Streams 管理者である場合、次のデータベース・リンクを作成します。

CONNECT strmadmin/[email protected]


この例では、Streams 管理者がソース・データベース dbs1.netに存在していることを想定しています。ソース・データベースに Streams 管理者が存在しない場合、ダウンストリーム・データベースの Streams 管理者が、Streams 管理者によるリモート・アクセスを許可するユーザーに接続する必要があります。任意のユーザーに対するリモート・アクセスを有効にするには、ソース・データベースで DBMS_STREAMS_AUTHパッケージの GRANT_REMOTE_ADMIN_ACCESSプロシージャを実行するときにそのユーザーを権限受領者に指定します。

2. 取得プロセスのキューが存在しない場合は作成します。

BEGIN DBMS_STREAMS_ADM.SET_UP_QUEUE( queue_table => 'strmadmin.strm03_queue_table',

queue_name => 'strmadmin.strm03_queue');END;/

3. CREATE_CAPTUREプロシージャを実行して取得プロセスを作成します。

BEGIN DBMS_CAPTURE_ADM.CREATE_CAPTURE( queue_name => 'strm03_queue', capture_name => 'strm03_capture', rule_set_name => NULL, start_scn => NULL, source_database => 'dbs1.net', use_database_link => true, first_scn => NULL, logfile_assignment => 'implicit');END;/


� ダウンストリーム・データベース dbs2.netで、取得プロセス strm03_captureが作成されます。同じ名前の取得プロセスは存在できません。



� 取得プロセスが、dbs2.net上の既存のキュー strm03_queueに関連付けられます。

� 取得プロセスによって変更が取得されるソース・データベースとして dbs1.netが指定されます。

� 取得プロセスが、ソース・データベースで管理操作を実行するためのソース・データベース・グローバル名と同じ名前を持つデータベース・リンクを使用するように指定されます。

� 取得プロセスが、新しい REDO ログ・ファイルを dbs1.netから暗黙的に受け入れるように指定されます。これによって、dbs1.netから dbs2.netにコピーされたすべての新しいログ・ファイルに取得する必要がある変更が含まれるかどうかが取得プロセスによってスキャンされます。これらのログ・ファイルは、ログ転送サービスによって自動的に、または次の DDL 文を使用して手動で取得プロセスに追加できます。

ALTER DATABASE REGISTER LOGICAL LOGFILE file_name FOR capture_process;

ここでは、file_nameは REDO ログ・ファイルの名前で、capture_processはダウンストリーム・データベースの REDO ログ・ファイルを使用する取得プロセスの名前です。REDO ログ・ファイルを手動で追加する必要があるのは、logfile_assignmentパラメータが explicitに設定されている場合のみです。

この手順では、取得プロセス strm03_captureはルール・セットとは関連付けられません。ルール・セットの作成および取得プロセスとの関連付けは、次の手順で行います。

dbs2.netで、他の取得プロセスによって dbs1.netソース・データベースから変更が取得されていない場合、データベース・リンクを使用して、dbs1.netでDBMS_CAPTURE_ADM.BUILDプロシージャが自動的に実行されます。このプロシージャが実行されると、dbs1.netのデータ・ディクショナリが REDO ログに抽出され、取得プロセス strm03_captureが dbs2.netで初めて起動されるときに、dbs1.net用の LogMiner データ・ディクショナリが dbs2.netに作成されます。

dbs2.netで、複数の取得プロセスによって dbs1.netソース・データベースから変更が取得されている場合、新しい取得プロセス strm03_captureでは、既存のいずれかの取得プロセスと同じ dbs1.net用の LogMinger データ・ディクショナリが使用されます。Streams では、新しい取得プロセスと共有される LogMiner データ・ディクショナリが自動的に選択されます。



� ALTER DATABASE文の詳細は、『Oracle Database SQL リファレンス』を参照してください。

� REDO ログ・ファイルを登録する方法の詳細は、『Oracle Data Guard概要および管理』を参照してください。



4. 取得プロセスのポジティブ・ルール・セットを作成し、ルールを追加します。

BEGIN DBMS_STREAMS_ADM.ADD_TABLE_RULES( table_name => 'hr.departments', streams_type => 'capture', streams_name => 'strm03_capture', queue_name => 'strm03_queue', include_dml => true, include_ddl => false, include_tagged_lcr => false, source_database => 'dbs1.net', inclusion_rule => true);END;/


� dbs2.netで、取得プロセス strm03_capture用のルール・セットが作成されます。ルール・セット名は、システムによって生成されます。inclusion_ruleパラメータが trueに設定されているため、このルール・セットは、取得プロセスのポジティブ・ルール・セットになります。

� hr.departments表に対する DML 変更を取得するルールが作成され、そのルールが取得プロセスのポジティブ・ルール・セットに追加されます。ルール名は、システムによって生成されます。inclusion_ruleパラメータが trueに設定されているため、このルールは、取得プロセスのポジティブ・ルール・セットに追加されます。

� 手順 1 で作成したデータベース・リンクを使用して、dbs1.netのhr.departments表がインスタンス化のために準備されます。

これで、strm03_capture取得プロセスによって取得された LCR の伝播または適用（あるいはその両方）を構成できます。

この例では、適用プロセスを使用してダウンストリーム・データベース dbs2.netで LCRを適用する場合、dbs2.netの hr.departments表にインスタンス化 SCN を設定します。この表が dbs2.netに存在しない場合、dbs2.netの表をインスタンス化します。

たとえば、hr.departments表が dbs2.netに存在する場合、接続先データベースdbs2.netで次のプロシージャを実行して、dbs2.netの hr.departments表にインスタンス化 SCN を設定します。

DECLARE iscn NUMBER; -- Variable to hold instantiation SCN valueBEGIN iscn := [email protected]; DBMS_APPLY_ADM.SET_TABLE_INSTANTIATION_SCN( source_object_name => 'hr.departments',



source_database_name => 'dbs1.net', instantiation_scn => iscn);END;/

インスタンス化 SCN を設定した後、strm03_queueキューから、hr.departments表にLCR を適用するための適用プロセスを構成できます。データベースのオブジェクトへのインスタンス化 SCN の設定は、適用プロセスによってそのオブジェクトに LCR が適用される場合にのみ必要です。

データベース・リンクを使用しないダウンストリーム取得プロセスの作成データベース・リンクを使用しないダウンストリーム取得プロセスの作成データベース・リンクを使用しないダウンストリーム取得プロセスの作成データベース・リンクを使用しないダウンストリーム取得プロセスの作成ここでは、DBMS_CAPTURE_ADMパッケージの CREATE_CAPTUREプロシージャを実行して、dbs1.netソース・データベースに対する変更を取得する取得プロセスを dbs2.netダウンストリーム・データベースに作成する例について説明します。この例の取得プロセスでは、dbs1.netへのデータベース・リンクは使用されません。

この操作の手順は次のとおりです。

1. ソース・データベース dbs1.netに Streams 管理者として接続します。たとえば、Streams 管理者が strmadminである場合、次の文を発行します。


ダウンストリーム・データベースからソース・データベースへのデータベース・リンクを使用しない場合、Streams 管理者はソース・データベースに存在している必要があります。

2. dbs1.netから変更を取得する取得プロセスが dbs2.netに存在しない場合、REDOログに dbs1.netデータ・ディクショナリを作成します。dbs2.netの取得プロセスが dbs1.netソース・データベースから変更を取得するように構成済である場合、この手順はオプションです。

SET SERVEROUTPUT ONDECLARE scn NUMBER;

注意注意注意注意 : データベース・オブジェクトをソース・データベースと接続先データベースで同期化する必要がある場合、接続先データベースでインスタンス化 SCN を設定するときに、データベース・オブジェクトに一貫性があることを確認する必要があります。前述の例では、インスタンス化SCN を設定するときに、ソース・データベースと接続先データベースでhr.departments表の一貫性がある必要があります。

参照参照参照参照 : インスタンス化の詳細は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。



BEGIN DBMS_CAPTURE_ADM.BUILD( first_scn => scn); DBMS_OUTPUT.PUT_LINE('First SCN Value = ' || scn);END;/First SCN Value = 409391

このプロシージャによって、dbs2.netで作成される取得プロセスの有効な先頭 SCN値が表示されます。戻された SCN 値をメモします。この値は、dbs2.netで取得プロセスを作成するときに使用します。

このプロシージャを実行して REDO ログにデータ・ディクショナリを作成した場合、取得プロセスが dbs2.netで初めて起動されるときに、REDO ログのデータ・ディクショナリ情報を使用して LogMiner データ・ディクショナリが作成されます。

プロシージャの完了時に有効な先頭 SCN 値を表示しないでデータ・ディクショナリを作成する場合、V$ARCHIVED_LOG動的パフォーマンス・ビューを問い合せて、dbs2.netで作成される取得プロセスの有効な先頭 SCN 値を判断できます。

SELECT DISTINCT FIRST_CHANGE# FROM V$ARCHIVED_LOG WHERE DICTIONARY_BEGIN = 'YES';

出力は次のようになります。

FIRST_CHANGE#------------- 409391

2 つ以上の値が戻された場合、も大きい値をメモします。

3. hr.departments表をインスタンス化のために準備します。

BEGIN DBMS_CAPTURE_ADM.PREPARE_TABLE_INSTANTIATION( table_name => 'hr.departments');END;/

4. ダウンストリーム・データベース dbs2.netに Streams 管理者として接続します。たとえば、Streams 管理者が strmadminである場合、次の文を発行します。




5. 取得プロセスのキューが存在しない場合は作成します。


queue_name => 'strmadmin.strm03_queue');END;/

6. CREATE_CAPTUREプロシージャを実行して取得プロセスを作成し、手順 2 でメモした値を first_scnパラメータに指定します。

BEGIN DBMS_CAPTURE_ADM.CREATE_CAPTURE( queue_name => 'strm03_queue', capture_name => 'strm04_capture', rule_set_name => NULL, start_scn => NULL, source_database => 'dbs1.net', use_database_link => false, first_scn => 409391, -- Use value from Step 2 logfile_assignment => 'implicit');END;/





� 取得プロセスの先頭 SCN として 409391が指定されます。これは、手順 2 で戻された値です。先頭 SCN は、取得プロセスが変更を取得できる小 SCN です。先頭SCN が指定されているため、同じソース・データベースに LogMiner データ・ディクショナリが存在しているかどうかにかかわらず、取得プロセスが初に起動されたときにその取得プロセスによって新しい LogMiner データ・ディクショナリが作成されます。



� 取得プロセスが、新しい REDO ログ・ファイルを dbs1.netから暗黙的に受け入れるように指定されます。これによって、dbs1.netから dbs2.netにコピーされたすべての新しいログ・ファイルに取得する必要がある変更が含まれるかどうかが取得プロセスによってスキャンされます。これらのログ・ファイルは、ログ転送サービスによって自動的に、または次の DDL 文を使用して手動で取得プロセスに追加する必要があります。


ここでは、file_nameは REDO ログ・ファイルの名前で、capture_processはダウンストリーム・データベースの REDO ログ・ファイルを使用する取得プロセスの名前です。REDO ログ・ファイルを手動で追加する必要があるのは、logfile_assignmentパラメータが explicitに設定されている場合のみです。



BEGIN DBMS_STREAMS_ADM.ADD_TABLE_RULES( table_name => 'hr.departments', streams_type => 'capture', streams_name => 'strm04_capture', queue_name => 'strm03_queue', include_dml => true, include_ddl => false, include_tagged_lcr => false, source_database => 'dbs1.net', inclusion_rule => true );END;/










� hr.departments表に対する DML 変更を取得するルールが作成され、そのルールが取得プロセスのルール・セットに追加されます。ルール名は、システムによって生成されます。inclusion_ruleパラメータが trueに設定されているため、このルールは、取得プロセスのポジティブ・ルール・セットに追加されます。



たとえば、hr.departments表が dbs2.netに存在する場合、ソース・データベースdbs1.netで次のプロシージャを実行して、dbs2.netの hr.departments表にインスタンス化 SCN を設定します。


DECLARE iscn NUMBER; -- Variable to hold instantiation SCN valueBEGIN iscn := DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER(); [email protected]( source_object_name => 'hr.departments', source_database_name => 'dbs1.net', instantiation_scn => iscn);END;/




ログ・ファイルを明示的に割り当てるダウンストリーム取得プロセスの作成ログ・ファイルを明示的に割り当てるダウンストリーム取得プロセスの作成ログ・ファイルを明示的に割り当てるダウンストリーム取得プロセスの作成ログ・ファイルを明示的に割り当てるダウンストリーム取得プロセスの作成ダウンストリーム取得を実行する取得プロセスを作成するには、CREATE_CAPTUREプロシージャを使用する必要があります。この項では、REDO ログ・ファイルを明示的に割り当てるダウンストリーム取得プロセスを作成する方法について説明します。DBMS_FILE_TRANSFERパッケージ、FTP またはその他の方法を使用してソース・データベースからダウンストリーム・データベースに REDO ログ・ファイルを転送し、これらのREDO ログ・ファイルをダウンストリーム取得プロセスに手動で登録する必要があります。

この例では、次のことを想定しています。

� ソース・データベースは dbs1.netで、ダウンストリーム・データベースは dbs2.netです。

� dbs2.netで作成される取得プロセスは、strm03_queueを使用します。

� この取得プロセスは、hr.departments表に対する DML 変更を取得します。

� この取得プロセスでは、管理操作用のソース・データベースへのデータベース・リンクは使用されません。

この操作の手順は次のとおりです。

1. ソース・データベース dbs1.netに hrユーザーとして接続します。

CONNECT hr/[email protected]

2. hr.departments表に主キーのサプリメンタル・ロギングを指定します。

ALTER TABLE hr.departments ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;


� 前述の例を使用してインスタンス化 SCN を設定するには、ソース・データベースから接続先データベースへのデータベース・リンクが必要です。

� データベース・オブジェクトをソース・データベースと接続先データベースで同期化する必要がある場合、接続先データベースでインスタンス化 SCN を設定するときに、データベース・オブジェクトに一貫性があることを確認する必要があります。前述の例では、インスタンス化 SCN を設定するときに、ソース・データベースと接続先データベースで hr.departments表の一貫性がある必要があります。




この例では hr.departments表に対する変更を取得する取得プロセスを作成するため、この表の主キーのサプリメンタル・ロギングが必要です。

3. ソース・データベース dbs1.netに Streams 管理者として接続します。たとえば、Streams 管理者が strmadminである場合、次の文を発行します。


ダウンストリーム・データベースからソース・データベースへのデータベース・リンクを使用しない場合、Streams 管理者はソース・データベースに存在している必要があります。

4. dbs1.netから変更を取得する取得プロセスが dbs2.netに存在しない場合、REDOログに dbs1.netデータ・ディクショナリを作成します。dbs2.netの取得プロセスが dbs1.netソース・データベースから変更を取得するように構成済である場合、この手順はオプションです。

SET SERVEROUTPUT ONDECLARE scn NUMBER;BEGIN DBMS_CAPTURE_ADM.BUILD( first_scn => scn); DBMS_OUTPUT.PUT_LINE('First SCN Value = ' || scn);END;/First SCN Value = 409391

このプロシージャによって、dbs2.netで作成される取得プロセスの有効な先頭 SCN値が表示されます。戻された SCN 値をメモします。この値は、dbs2.netで取得プロセスを作成するときに使用します。

このプロシージャを実行して REDO ログにデータ・ディクショナリを作成した場合、取得プロセスが dbs2.netで初めて起動されるときに、REDO ログのデータ・ディクショナリ情報を使用して LogMiner データ・ディクショナリが作成されます。

5. hr.departments表をインスタンス化のために準備します。

BEGIN DBMS_CAPTURE_ADM.PREPARE_TABLE_INSTANTIATION( table_name => 'hr.departments');END;/

6. ダウンストリーム・データベース dbs2.netに Streams 管理者として接続します。たとえば、Streams 管理者が strmadminである場合、次の文を発行します。




7. CREATE_CAPTUREプロシージャを実行して取得プロセスを作成し、手順 2 でメモした値を first_scnパラメータに指定します。

BEGIN DBMS_CAPTURE_ADM.CREATE_CAPTURE( queue_name => 'strm03_queue', capture_name => 'strm05_capture', rule_set_name => NULL, start_scn => NULL, source_database => 'dbs1.net', use_database_link => false, first_scn => 409391, -- Use value from Step 2 logfile_assignment => 'explicit');END;/





� 取得プロセスの先頭 SCN として 409391が指定されます。これは、手順 2 で戻された値です。先頭 SCN は、取得プロセスが変更を取得できる小 SCN です。先頭SCN が指定されているため、同じソース・データベースに LogMiner データ・ディクショナリが存在しているかどうかにかかわらず、取得プロセスが初に起動されたときにその取得プロセスによって新しい LogMiner データ・ディクショナリが作成されます。

� dbs1.netからの新しい REDO ログ・ファイルが取得プロセスに明示的に割り当てられるように指定されます。ダウンストリーム・データベースが実行されているコンピュータに REDO ログ・ファイルが転送された後、次の DDL 文を使用して、そのログ・ファイルを取得プロセスに明示的に割り当てます。


ここでは、file_nameは REDO ログ・ファイルの名前で、capture_processはダウンストリーム・データベースの REDO ログ・ファイルを使用する取得プロセスの名前です。logfile_assignmentパラメータが explicitに設定されている場合、REDO ログ・ファイルを手動で追加する必要があります。





BEGIN DBMS_STREAMS_ADM.ADD_TABLE_RULES( table_name => 'hr.departments', streams_type => 'capture', streams_name => 'strm05_capture', queue_name => 'strm03_queue', include_dml => true, include_ddl => false, include_tagged_lcr => false, source_database => 'dbs1.net', inclusion_rule => true );END;/



� hr.departments表に対する DML 変更を取得するルールが作成され、そのルールが取得プロセスのルール・セットに追加されます。ルール名は、システムによって生成されます。inclusion_ruleパラメータが trueに設定されているため、このルールは、取得プロセスのポジティブ・ルール・セットに追加されます。

9. ダウンストリーム取得プロセスの先頭 SCN を含むソース・データベース dbs1.netのREDO ログ・ファイルがアーカイブされた後、その REDO ログ・ファイルをダウンストリーム・データベースが実行されているコンピュータに転送します。手順 4 の BUILDプロシージャによって、ダウンストリーム取得プロセスの先頭 SCN が判別されていま








す。REDO ログ・ファイルがアーカイブされていない場合、データベースで ALTER SYSTEM SWITCH LOGFILE文を実行してアーカイブする必要があります。

dbs1.netで次の問合せを実行すると、ダウンストリーム取得プロセスの先頭 SCN を含むアーカイブ REDO ログ・ファイルを識別できます。

COLUMN NAME HEADING 'Archived Redo Log|File Name' FORMAT A50COLUMN FIRST_CHANGE# HEADING 'First SCN' FORMAT 999999999

SELECT NAME, FIRST_CHANGE# FROM V$ARCHIVED_LOG WHERE FIRST_CHANGE# IS NOT NULL AND DICTIONARY_BEGIN = 'YES';

手順 4 で戻された先頭 SCN をダウンストリーム取得プロセスが実行されているコンピュータと一致させる FIRST_CHANGE#を使用して、アーカイブ REDO ログ・ファイルを転送します。

10. ダウンストリーム・データベース dbs2.netで、管理ユーザーとして接続し、転送された REDO ログ・ファイルを取得プロセスに割り当てます。たとえば、REDO ログ・ファイルが /oracle/logs_from_dbs1/1_10_486574859.dbfである場合、次の文を発行します。

ALTER DATABASE REGISTER LOGICAL LOGFILE '/oracle/logs_from_dbs1/1_10_486574859.dbf' FOR 'strm05_capture';



たとえば、hr.departments表が dbs2.netに存在する場合、ソース・データベースdbs1.netで次のプロシージャを実行して、dbs2.netの hr.departments表にインスタンス化 SCN を設定します。


DECLARE iscn NUMBER; -- Variable to hold instantiation SCN valueBEGIN iscn := DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER(); [email protected]( source_object_name => 'hr.departments', source_database_name => 'dbs1.net', instantiation_scn => iscn);END;/




NULL 以外の開始以外の開始以外の開始以外の開始 SCN を持つローカルの取得プロセスの作成を持つローカルの取得プロセスの作成を持つローカルの取得プロセスの作成を持つローカルの取得プロセスの作成この例では、DBMS_CAPTURE_ADMパッケージの CREATE_CAPTUREプロシージャを実行して、開始 SCN が 223525に設定されたローカルの取得プロセスを作成します。この例では、データベースに 1 つ以上のローカル取得プロセスがあり、この取得プロセスは 1 つ以上のチェックポイントを取得済であると想定しています。常に、新しい取得プロセスに対し、ソース・データベースの現行の SCN 以上の開始 SCN を指定できます。データベースの現行の SCN より小さい開始 SCN を指定する場合、この SCN には 1 回以上正常に起動されたことがあり、1 つ以上のチェックポイントを取得済である既存のローカル取得プロセスの小先頭 SCN より大きい値を指定する必要があります。

既存の取得プロセスの先頭 SCN を判別し、これらの取得プロセスがチェックポイントを取得済であるかどうかを判別するには、次の問合せを使用します。

SELECT CAPTURE_NAME, FIRST_SCN, MAX_CHECKPOINT_SCN FROM DBA_CAPTURE;


CAPTURE_NAME FIRST_SCN MAX_CHECKPOINT_SCN------------------------------ ---------- ------------------CAPTURE_SIMP 223522 230825

この結果では、capture_simp取得プロセスの先頭 SCN は 223522であることを示しています。また、この取得プロセスは、MAX_CHECKPOINT_SCNの値が NULLでないため、


� 前述の例を使用してインスタンス化 SCN を設定するには、ソース・データベースから接続先データベースへのデータベース・リンクが必要です。

� データベース・オブジェクトをソース・データベースと接続先データベースで同期化する必要がある場合、接続先データベースでインスタンス化 SCN を設定するときに、データベース・オブジェクトに一貫性があることを確認する必要があります。前述の例では、インスタンス化 SCN を設定するときに、ソース・データベースと接続先データベースで hr.departments表の一貫性がある必要があります。




チェックポイントを取得済であることを示しています。したがって、新しい取得プロセスの開始 SCN は、223522以上に設定できます。

次のプロシージャを実行して取得プロセスを作成します。

BEGIN DBMS_CAPTURE_ADM.CREATE_CAPTURE( queue_name => 'strm01_queue', capture_name => 'strm05_capture', rule_set_name => 'strmadmin.strm01_rule_set', start_scn => 223525, source_database => NULL, use_database_link => false, first_scn => NULL);END;/


� 取得プロセス strm05_captureが作成されます。同じ名前の取得プロセスは存在できません。


� 取得プロセスが、既存のルール・セット strm01_rule_setに関連付けられます。このルール・セットは、取得プロセスのポジティブ・ルール・セットです。

� 取得プロセスの開始 SCN として 223525が指定されます。新しい取得プロセスでは、既存のいずれかの取得プロセスと同じ LogMiner データ・ディクショナリが使用されます。Streams では、新しい取得プロセスと共有される LogMiner データ・ディクショナリが自動的に選択されます。first_scnパラメータが NULLに設定されていたため、新しい取得プロセスの先頭 SCN は、共有される LogMiner データ・ディクショナリを持つ既存の取得プロセスの先頭 SCN と同じになります。この例では、既存の取得プロセスは、capture_simpです。


注意注意注意注意 : この例のプロシージャの実行時にローカルの取得プロセスが存在しない場合、取得プロセスの作成中に DBMS_CAPTURE_ADM.BUILDプロシージャが自動的に実行され、データ・ディクショナリが REDO ログに抽出されます。新しい取得プロセスが初めて起動されるときに、このREDO ログ情報を使用して LogMiner データ・ディクショナリが作成されます。この場合、start_scnパラメータには、現行データベースの SCN以上の値を指定する必要があります。


取得プロセスの起動、停止および削除

取得プロセスの起動、停止および削除取得プロセスの起動、停止および削除取得プロセスの起動、停止および削除取得プロセスの起動、停止および削除この項では、取得プロセスを起動、停止および削除する手順について説明します。この項の内容は、次のとおりです。

� 取得プロセスの起動

� 取得プロセスの停止

� 取得プロセスの削除

取得プロセスの起動取得プロセスの起動取得プロセスの起動取得プロセスの起動既存の取得プロセスを起動するには、DBMS_CAPTURE_ADMパッケージの START_CAPTUREプロシージャを実行します。たとえば、次のプロシージャでは、取得プロセスstrm01_captureが起動されます。

BEGIN DBMS_CAPTURE_ADM.START_CAPTURE( capture_name => 'strm01_capture');END;/

取得プロセスの停止取得プロセスの停止取得プロセスの停止取得プロセスの停止既存の取得プロセスを停止するには、DBMS_CAPTURE_ADMパッケージの STOP_CAPTUREプロシージャを実行します。たとえば、次のプロシージャでは、取得プロセスstrm01_captureが停止されます。

BEGIN DBMS_CAPTURE_ADM.STOP_CAPTURE( capture_name => 'strm01_capture');END;/




注意注意注意注意 : 新しい取得プロセスで新しい LogMiner データ・ディクショナリが使用される場合、新しい取得プロセスを初めて起動するときに、新しいLogMiner データ・ディクショナリの移入に時間がかかる場合があります。新しい LogMiner データ・ディクショナリは、取得プロセスの作成時にNULL以外の先頭 SCN 値を指定した場合に作成されます。


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

取得プロセスの削除取得プロセスの削除取得プロセスの削除取得プロセスの削除既存の取得プロセスを削除するには、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で使用されているすべてのルール・セットも削除されます（ルール・セットが他の Streams クライアントによって使用されている場合を除く）。drop_unused_rule_setsパラメータが trueに設定されている場合、取得プロセスのポジティブ・ルール・セットとネガティブ・ルール・セットの両方を削除できます。このプロシージャによってルール・セットが削除された場合、そのルール・セット内のルールのうち、他のルール・セットに含まれていないルールも削除されます。

取得プロセスのルール・セットの管理取得プロセスのルール・セットの管理取得プロセスのルール・セットの管理取得プロセスのルール・セットの管理この項では、次のタスクの手順について説明します。

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

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

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

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

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

注意注意注意注意 : 取得プロセスは、削除する前に停止する必要があります。






取得プロセスのルール・セットの指定取得プロセスのルール・セットの指定取得プロセスのルール・セットの指定取得プロセスのルール・セットの指定取得プロセスには、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;/






取得プロセスのルール・セットへのルールの追加取得プロセスのルール・セットへのルールの追加取得プロセスのルール・セットへのルールの追加取得プロセスのルール・セットへのルールの追加既存の取得プロセスのルール・セットにルールを追加するには、次のいずれかのプロシージャを使用して既存の取得プロセスを指定できます。





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 => 'strm01_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表がインスタンス化のために準備されます。取得プロセスによってダウンストリーム取得が実行される場合、そのダウンストリーム取得プロセ

参照参照参照参照 : 6-6 ページの「システム作成ルール」



スでソース・データベースへのデータベース・リンクが使用される場合にのみ、表がインスタンス化のために準備されます。ダウンストリーム取得プロセスでソース・データベースへのデータベース・リンクが使用されない場合、手動で表をインスタンス化のために準備する必要があります。

取得プロセスのネガティブ・ルール・セットへのルールの追加取得プロセスのネガティブ・ルール・セットへのルールの追加取得プロセスのネガティブ・ルール・セットへのルールの追加取得プロセスのネガティブ・ルール・セットへのルールの追加ここでは、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 => 'strm01_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 つのルールは、取得プロセスに関連付けられたネガティブ・ルール・セットに追加されます。

取得プロセスのルール・セットからのルールの削除取得プロセスのルール・セットからのルールの削除取得プロセスのルール・セットからのルールの削除取得プロセスのルール・セットからのルールの削除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を指定します。

取得プロセスのルール・セットの削除取得プロセスのルール・セットの削除取得プロセスのルール・セットの削除取得プロセスのルール・セットの削除既存の取得プロセスからルール・セットを削除するように指定するには、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パラメータが 3に設定されます。

BEGIN DBMS_CAPTURE_ADM.SET_PARAMETER( capture_name => 'strm01_capture', parameter => 'parallelism', value => '3');END;/

取得プロセスの取得ユーザーの設定取得プロセスの取得ユーザーの設定取得プロセスの取得ユーザーの設定取得プロセスの取得ユーザーの設定取得ユーザーは、取得プロセスのルール・セットを満たすすべての DML 変更および DDL変更を取得するユーザーです。取得プロセスの取得ユーザーを設定するには、DBMS_CAPTURE_ADMパッケージの ALTER_CAPTUREプロシージャで capture_userパラメータを使用します。

取得ユーザーを変更するには、ALTER_CAPTUREプロシージャを起動するユーザーに DBAロールが付与されている必要があります。SYSユーザーのみが、capture_userを SYSに設定できます。


� parallelismパラメータを設定すると、取得プロセスが自動的に停止され、再起動されます。

� valueパラメータは、パラメータ値が数値の場合にも、常にVARCHAR2として入力されます。


� 2-43 ページの「取得プロセスのパラメータ」

� 取得プロセス・パラメータの詳細は、『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』のDBMS_CAPTURE_ADM.SET_PARAMETERプロシージャに関する説明を参照してください。


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

たとえば、次のプロシージャでは、取得プロセス strm01_captureの取得ユーザーが hrに設定されます。

BEGIN DBMS_CAPTURE_ADM.ALTER_CAPTURE( capture_name => 'strm01_capture', capture_user => 'hr');END;/

このプロシージャを実行すると、新しい取得ユーザーに、取得プロセスで使用するキューのエンキュー権限が付与され、そのユーザーがキューの保護キュー・ユーザーとして構成されます。また、取得ユーザーが次の権限を持っていることを確認する必要があります。

� 取得プロセスで使用するルール・セットの実行権限

� ルール・セットで使用するすべてのルールベースの変換ファンクションの実行権限

これらの権限は、取得ユーザーに直接付与する必要があります。これらの権限は、ロールを介しては付与できません。

ソース・データベースでのサプリメンタル・ロギングの指定ソース・データベースでのサプリメンタル・ロギングの指定ソース・データベースでのサプリメンタル・ロギングの指定ソース・データベースでのサプリメンタル・ロギングの指定列に対する変更が接続先データベースで正常に適用されるように、ソース・データベースで特定の列のサプリメンタル・ロギングを指定する必要があります。通常、サプリメンタル・ロギングは Streams レプリケーション環境で必要ですが、適用プロセスとともに取得イベントが処理される環境でも必要になる場合があります。データベースのすべての表にサプリメンタル・ロギングを指定するには、ALTER DATABASE文を使用します。特定の表にサプリメンタル・ロギングを指定するには、ALTER TABLE文を使用します。

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

取得プロセスにアーカイブ REDO ログ・ファイルを手動で追加するには、次の文を使用します。


ここでは、file_nameは追加するアーカイブ REDO ログ・ファイルの名前で、capture_processはダウンストリーム・データベースの REDO ログ・ファイルを使用する取得プロセスの名前です。capture_processは、logminer_session_nameと等価で

参照参照参照参照 : サプリメンタル・ロギングを指定する方法の詳細は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。


既存の取得プロセスの SCN 値の設定

あり、指定する必要があります。取得プロセスが実行されるサイトには、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';

既存の取得プロセスの既存の取得プロセスの既存の取得プロセスの既存の取得プロセスの SCN 値の設定値の設定値の設定値の設定この項の内容は、次のとおりです。

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

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

既存の取得プロセスの先頭既存の取得プロセスの先頭既存の取得プロセスの先頭既存の取得プロセスの先頭 SCN の設定の設定の設定の設定既存の取得プロセスの先頭 SCN を設定するには、DBMS_CAPTURE_ADMパッケージのALTER_CAPTUREプロシージャを使用します。指定する先頭 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 ログ・ファイルは、取得プロセスでは必要ありません。

参照参照参照参照 : ALTER DATABASE文の詳細は、『Oracle Database SQL リファレンス』を参照してください。REDO ログ・ファイルを登録する方法の詳細は、『Oracle Data Guard 概要および管理』を参照してください。


既存の取得プロセスの SCN 値の設定

たとえば、次のプロシージャでは、取得プロセス strm01_captureの先頭 SCN が 351232に設定されます。

BEGIN DBMS_CAPTURE_ADM.ALTER_CAPTURE( capture_name => 'strm01_capture', first_scn => 351232);END;/

既存の取得プロセスの開始既存の取得プロセスの開始既存の取得プロセスの開始既存の取得プロセスの開始 SCN の設定の設定の設定の設定既存の取得プロセスの開始 SCN を設定するには、DBMS_CAPTURE_ADMパッケージのALTER_CAPTUREプロシージャを使用します。通常、取得プロセスの開始 SCN をリセットするのは、取得プロセスから変更を受信する接続先データベースの 1 つで Point-in-Time リカバリを実行する必要がある場合です。


� 指定した先頭 SCNが取得プロセスの現行の開始 SCNより大きい場合、その開始 SCN は、新しい先頭 SCN の値に自動的に設定されます。

� 過去のある時点からの REDO ログ内の変更を取得する必要がある場合、新しい取得プロセスを作成し、REDO ログに作成された以前のデータ・ディクショナリに対応する先頭 SCN を指定できます。REDO ログにデータ・ディクショナリを作成するには、DBMS_CAPTURE_ADMパッケージの BUILDプロシージャを使用します。

� DBA_LOGMNR_PURGED_LOGデータ・ディクショナリ・ビューを問い合せて、取得プロセスで不要な REDO ログ・ファイルを判別できます。



� 2-30 ページの「取得プロセスの LogMiner データ・ディクショナリ」


� 14-11 ページの「取得プロセスでは不要な REDO ログ・ファイルの表示」


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

指定する開始 SCN は、取得プロセスの先頭 SCN 以上である必要があります。データベース内の各取得プロセスの先頭 SCN を判別するには、次の問合せを使用します。

SELECT CAPTURE_NAME, FIRST_SCN FROM DBA_CAPTURE;

また、取得プロセスの開始 SCN をリセットする場合は、必須 REDO ログ・ファイルがその取得プロセスで使用できる必要があります。

たとえば、次のプロシージャでは、取得プロセス strm01_captureの開始 SCN が 750338に設定されます。

BEGIN DBMS_CAPTURE_ADM.ALTER_CAPTURE( capture_name => 'strm01_capture', start_scn => 750338);END;/

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

既存のダウンストリーム取得プロセスで、ソース・データベースへの管理用のデータベース・リンクを使用するかどうかを指定するには、DBMS_CAPTURE_ADMパッケージのALTER_CAPTUREプロシージャを使用します。ダウンストリーム取得プロセスでデータベース・リンクを使用するように指定するには、use_database_linkパラメータを trueに設定します。ダウンストリーム取得プロセスでデータベース・リンクを使用しないように指定するには、use_database_linkパラメータを falseに設定します。

現在データベース・リンクを使用していない取得プロセスでデータベース・リンクを使用するようにするには、use_database_linkパラメータを trueに設定します。この場合、ソース・データベースのグローバル名と同じ名前を持つデータベース・リンクが、ダウンストリーム・データベースに存在する必要があります。

現在データベース・リンクを使用している取得プロセスでデータベース・リンクを使用しないようにするには、use_database_linkパラメータを falseに設定します。この場合、取得プロセスの変更後に、いくつかの管理操作を手動で行う必要があります。たとえば、DBMS_STREAMS_ADMパッケージを使用して新しい取得プロセスを追加する場合、ソース・データベースで、そのルールに関連付けられたオブジェクトのインスタンス化の準備を手動で行う必要があります。



� Streams 環境において、接続先データベースで Point-in-Time リカバリを実行する方法の詳細は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。


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

use_database_linkパラメータを NULLに設定した場合、取得プロセスに対するこのパラメータの現行の値は変更されません。

9-12 ページの「データベース・リンクを使用しないダウンストリーム取得プロセスの作成」の例では、取得プロセス strm04_captureが作成され、この取得プロセスがデータベース・リンクを使用しないように指定されました。ソース・データベース dbs1.netへのデータベース・リンクを作成し、この取得プロセスがデータベース・リンクを使用するように指定するには、次のアクションを実行します。


BEGIN DBMS_CAPTURE_ADM.ALTER_CAPTURE( capture_name => 'strm04_capture', use_database_link => true);END;/

取得取得取得取得 LCR 内の追加の属性の管理内の追加の属性の管理内の追加の属性の管理内の追加の属性の管理1 つ以上の追加の属性を取得するように取得プロセスに指示するには、DBMS_CAPTURE_ADMパッケージの INCLUDE_EXTRA_ATTRIBUTEプロシージャを使用します。また、このプロシージャを使用して、現在取得している追加の属性を排除するように取得プロセスに指示することもできます。

追加の属性は次のとおりです。

� row_id（行 LCR のみ）

� serial#

� session#

� thread#

� tx_name

� username

この項では、次のタスクの手順について説明します。

� 取得 LCR への追加の属性の包含

� 取得 LCR からの追加の属性の排除

参照参照参照参照 : 2-14 ページの「ローカル取得とダウンストリーム取得」


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

取得取得取得取得 LCR への追加の属性の包含への追加の属性の包含への追加の属性の包含への追加の属性の包含各取得 LCR にトランザクション名を含めるように取得プロセス strm01_captureに指示するには、次のプロシージャを実行します。

BEGIN DBMS_CAPTURE_ADM.INCLUDE_EXTRA_ATTRIBUTE( capture_name => 'strm01_capture', attribute_name => 'tx_name', include => true);END;/

取得取得取得取得 LCR からの追加の属性の排除からの追加の属性の排除からの追加の属性の排除からの追加の属性の排除各取得 LCR にトランザクション名を含めないように取得プロセス strm01_captureに指定するには、次のプロシージャを実行します。

BEGIN DBMS_CAPTURE_ADM.INCLUDE_EXTRA_ATTRIBUTE( capture_name => 'strm01_capture', attribute_name => 'tx_name', include => false);END;/


� 2-5 ページの「LCR 内の追加情報」

� 14-15 ページの「各取得プロセスで取得された追加の属性の表示」



ステージング

10
ステージングと伝播の管理ステージングと伝播の管理ステージングと伝播の管理ステージングと伝播の管理
この章では、SYS.AnyDataキュー、伝播およびメッセージ環境の管理手順について説明します。


� SYS.AnyData キューの管理

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

� Streams メッセージ環境の管理





と伝播の管理 10-1

SYS.AnyData キューの管理

SYS.AnyData キューの管理キューの管理キューの管理キューの管理SYS.AnyDataキューでは、SYS.AnyData型のペイロードを伴うイベントがステージングされます。したがって、SYS.AnyDataキューでは、ペイロードが SYS.AnyDataラッパーにラップされていれば、ほぼすべての型のペイロードを伴うイベントをステージングできます。Streams の各取得プロセスと適用プロセスは 1 つの SYS.AnyDataキューに関連付けられ、Streams の各伝播は 1 つの Streams ソース・キューと 1 つの SYS.AnyData宛先キューに関連付けられます。

この項では、SYS.AnyDataキューに関連する次のタスクの手順について説明します。

� SYS.AnyData キューの作成

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

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

� SYS.AnyData キューの削除

SYS.AnyData キューの作成キューの作成キューの作成キューの作成SYS.AnyDataキューを作成するには、DBMS_STREAMS_ADMパッケージの SET_UP_QUEUEプロシージャを使用します。このプロシージャを使用すると、作成する SYS.AnyDataキューについて次の要素を指定できます。

� キューのキュー表

� キュー表の STORAGE 句

� キュー名

� キューの保護キュー・ユーザーとして構成され、キューに対する ENQUEUEおよびDEQUEUE権限が付与されるキュー・ユーザー

� キューに関するコメント

このプロシージャでは、保護キューとトランザクション型のキューを兼ねるキューが作成され、そのキューが起動されます。

たとえば、キュー表 strm01_queue_tableを持つ SYS.AnyDataキュー strm01_queueを strmadminスキーマ内に作成し、このキューとの間でイベントのエンキューとデキューを行うために必要な権限を hrユーザーに付与するには、次のプロシージャを実行します。


queue_name => 'strmadmin.strm01_queue', queue_user => 'hr');END;/



また、DBMS_AQADMパッケージのプロシージャを使用すると、SYS.AnyDataキューを作成できます。

保護キューでのユーザー操作の有効化保護キューでのユーザー操作の有効化保護キューでのユーザー操作の有効化保護キューでのユーザー操作の有効化ユーザーが保護キューでエンキューやデキューなどのキュー操作を実行できるように、そのユーザーをキューの保護キュー・ユーザーとして構成する必要があります。DBMS_STREAMS_ADMパッケージの SET_UP_QUEUEプロシージャを使用して保護キューを作成すると、キュー所有者と queue_userパラメータで指定したユーザーが自動的にキューの保護ユーザーとして構成されます。他のユーザーに対してキュー操作の実行を許可する必要がある場合は、そのユーザーを次のいずれかの方法で構成できます。

� SET_UP_QUEUEを実行して queue_userを指定します。キューが存在する場合、その作成はスキップされますが、新規キュー・ユーザーを指定した場合はそのユーザーが構成されます。

� ユーザーを AQ エージェントに手動で関連付けます。

次の例に、ユーザーを AQ エージェントに手動で関連付ける手順を示します。oeユーザーに対して、10-2 ページの「SYS.AnyData キューの作成」で作成した strm01_queueに対するキュー操作の実行を許可する必要があるとします。次の手順に従って、oeユーザーをstrm01_queueの保護キュー・ユーザーとして構成します。

1. AQ エージェントを作成してユーザーを変更できる管理ユーザーとして接続します。

2. 次のように入力してエージェントを作成します。

EXEC DBMS_AQADM.CREATE_AQ_AGENT(agent_name => 'strm01_queue_agent');


� キュー名およびキュー表名は、大 24 バイトです。

� イベントは、デキューできるサブスクライバが構成されるまで、キューにエンキューできません。


� DBMS_AQADMパッケージのプロシージャを使用して SYS.AnyDataキューを作成する例については、10-19 ページの「SYS.AnyData ラッパーでのユーザー・メッセージ・ペイロードのラップおよびエンキュー」を参照してください。

� 3-17 ページの「保護キュー」

� 3-20 ページの「トランザクション型のキューと非トランザクション型のキュー」

ステージングと伝播の管理 10-3


3. ユーザーにキューからイベントをデキューする操作を許可する必要がある場合は、エージェントを保護キューのサブスクライバにします。

DECLARE subscriber SYS.AQ$_AGENT;BEGIN subscriber := SYS.AQ$_AGENT('strm01_queue_agent', NULL, NULL); DBMS_AQADM.ADD_SUBSCRIBER( queue_name => 'strmadmin.strm01_queue', subscriber => subscriber, rule => NULL, transformation => NULL);END;/

4. ユーザーをエージェントに関連付けます。

BEGIN DBMS_AQADM.ENABLE_DB_ACCESS( agent_name => 'strm01_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ユーザーは strm01_queueキューの保護ユーザーとなり、このキューの操作を実行できます。ただし、エンキュー権限やデキュー権限など、キュー操作を実行するための特定の権限もユーザーに付与する必要があります。






保護キューでのユーザー操作の無効化保護キューでのユーザー操作の無効化保護キューでのユーザー操作の無効化保護キューでのユーザー操作の無効化ユーザーに対して、次のような理由で保護キューのキュー操作を禁止することが必要になる場合があります。

� 取得プロセスを削除したが、その取得プロセスで使用されていたキューを削除しておらず、取得ユーザーであったユーザーには残りの保護キューの操作を禁止する必要がある場合。

� 適用プロセスを削除したが、その適用プロセスで使用されていたキューを削除しておらず、適用ユーザーであったユーザーには残りの保護キューの操作を禁止する必要がある場合。

� DBMS_APPLY_ADMパッケージの ALTER_APPLYプロシージャを使用して適用プロセスの apply_userを変更しており、変更前の apply_userには適用プロセスのキューの操作を禁止する必要がある場合。

� 10-3 ページの保護キューでのユーザー操作の有効化で説明した手順に従って、ユーザーに保護キューの操作を許可したが、このユーザーに保護キューの操作を禁止する必要がある場合。

保護キュー・ユーザーを無効化するには、ユーザーからキューに対する ENQUEUEおよびDEQUEUE権限を取り消す方法と、DBMS_AQADMパッケージの DISABLE_DB_ACCESSプロシージャを実行する方法があります。たとえば、oeユーザーに対して、10-2 ページの

「SYS.AnyData キューの作成」で作成した strm01_queueのキュー操作を禁止する必要があるとします。

1. 次のプロシージャを実行し、oeユーザーに対して保護キュー strm01_queueのキュー操作を禁止します。

BEGIN DBMS_AQADM.DISABLE_DB_ACCESS( agent_name => 'strm01_queue_agent', db_username => 'oe');END;/

2. 不要になったエージェントは削除できます。

BEGIN DBMS_AQADM.DROP_AQ_AGENT( agent_name => 'strm01_queue_agent');

注意注意注意注意 : 複数の保護キューに AQ エージェントを使用している場合は、そのエージェントに対して DISABLE_DB_ACCESSを実行すると、そのエージェントに関連付けられているユーザーがこれらすべてのキューに対する操作を実行できなくなります。



END;/

3. キューに対するユーザーの権限が不要になった場合は、その権限を取り消します。

BEGIN DBMS_AQADM.REVOKE_QUEUE_PRIVILEGE ( privilege => 'ALL', queue_name => 'strmadmin.strm01_queue', grantee => 'oe');END;/

SYS.AnyData キューの削除キューの削除キューの削除キューの削除既存の SYS.AnyDataキューを削除するには、DBMS_STREAMS_ADMパッケージのREMOVE_QUEUEプロシージャを使用します。REMOVE_QUEUEプロシージャを実行すると、キューの既存のイベントがコンシュームされるまで、プロシージャが待機します。その後、プロシージャによってキューが停止され、キューに対するエンキューまたはデキューが禁止されます。停止したキューは、プロシージャによって削除されます。

キューのキュー表が空で、他のキューに使用されていない場合、キュー表も削除できます。これを行うには、drop_unused_queue_tableパラメータに true（デフォルト）を指定します。

また、cascadeパラメータを trueに設定すると、そのキューを使用するすべての Streamsクライアントを削除できます。デフォルトでは、cascadeパラメータは falseに設定されています。

たとえば、strmadminスキーマ内の SYS.AnyDataキュー strm01_queueを削除して、その空のキュー表を削除するには、次のプロシージャを実行します。

BEGIN DBMS_STREAMS_ADM.REMOVE_QUEUE(

queue_name => 'strmadmin.strm01_queue', cascade => false, drop_unused_queue_table => true);END;/





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

この場合、cascadeパラメータが falseに設定されているため、Streams クライアントがstrm01_queueを使用していない場合のみ、このプロシージャはそのキューを削除します。cascadeパラメータが falseに設定されており、Streams クライアントがそのキューを使用している場合、エラーが発生します。

Streams の伝播および伝播ジョブの管理の伝播および伝播ジョブの管理の伝播および伝播ジョブの管理の伝播および伝播ジョブの管理伝播では、Streams ソース・キューから Streams 宛先キューにイベントが伝播されます。この項では、次のタスクの手順について説明します。

� 伝播の作成

� 伝播ジョブの有効化

� 伝播ジョブのスケジューリング

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

� 伝播ジョブのスケジュール解除

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

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

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

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

� 伝播ジョブの無効化

� 伝播の削除

また、Streams の伝播は、Oracle Advanced Queuing（AQ）の機能を使用して管理することもできます。

伝播の作成伝播の作成伝播の作成伝播の作成次のどのプロシージャでも、伝播を作成できます。


� DBMS_STREAMS_ADM.ADD_SUBSET_PROPAGATION_RULES



� DBMS_PROPAGATION_ADM.CREATE_PROPAGATION

参照参照参照参照 : AQ の機能を使用して伝播を管理する方法の詳細は、『Oracle Streams アドバンスト・キューイング・ユーザーズ・ガイドおよびリファレンス』を参照してください。



DBMS_STREAMS_ADMパッケージの各プロシージャでは、指定した名前の伝播が存在しない場合は伝播が作成され、伝播にポジティブ・ルール・セットまたはネガティブ・ルール・セットが存在しない場合はそのいずれかのルール・セットが作成されます。また、ルール・セットに表ルール、スキーマ・ルールまたはグローバル・ルールを追加できます。CREATE_PROPAGATIONプロシージャでは、伝播は作成されますが、そのルール・セットまたはルールは作成されません。ただし、CREATE_PROPAGATIONプロシージャを使用すると、既存のルール・セットを指定して、ポジティブ・ルール・セットまたはネガティブ・ルール・セットのいずれかとして伝播に関連付けできます。すべての伝播は、作成すると自動的に起動します。

伝播を作成する前に、次のタスクを完了する必要があります。

� 伝播のソース・キューと宛先キューが存在しない場合は、これらのキューを作成します。手順については、10-2 ページの「SYS.AnyData キューの作成」を参照してください。

� ソース・キューを含むデータベースと宛先キューを含むデータベースの間のデータベース・リンクを作成します。詳細は、8-11 ページの「ネットワーク接続性とデータベース・リンクの構成」を参照してください。

DBMS_STREAMS_ADM を使用した伝播の作成例を使用した伝播の作成例を使用した伝播の作成例を使用した伝播の作成例ここでは、DBMS_STREAMS_ADMパッケージの ADD_TABLE_PROPAGATION_RULESプロシージャを実行して伝播を作成する例について説明します。

BEGIN DBMS_STREAMS_ADM.ADD_TABLE_PROPAGATION_RULES( table_name => 'hr.departments', streams_name => 'strm01_propagation', source_queue_name => 'strmadmin.strm01_queue', destination_queue_name => '[email protected]', include_dml => true, include_ddl => true, include_tagged_lcr => false, source_database => 'dbs1.net', inclusion_rule => true);END;/


� 伝播 strm01_propagationが作成されます。この伝播が作成されるのは、それが存在しない場合のみです。

� 伝播で現行のデータベース内の strm01_queueから dbs2.netデータベース内のstrm02_queueに LCR を伝播するように指定されます。

� destination_queue_nameパラメータに @dbs2.netが指定されているため、伝播でdbs2.netデータベース・リンクを使用して LCR を伝播するように指定されます。



� inclusion_ruleパラメータが trueに設定されているため、ポジティブ・ルール・セットが作成され、伝播に関連付けられます。このルール・セットでは、評価コンテキスト SYS.STREAMS$_EVALUATION_CONTEXTが使用されます。ルール・セット名は、システムによって指定されます。

� 2 つのルールが作成されます。一方のルールは hr.departments表に対する DML 変更の結果を含む行 LCR について TRUEと評価され、他方のルールは hr.departments表に対する DDL 変更を含む DDL LCR について TRUEと評価されます。ルール名は、システムによって指定されます。

� この 2 つのルールが、伝播に関連付けられたポジティブ・ルール・セットに追加されます。これらのルールがポジティブ・ルール・セットに追加されるのは、inclusion_ruleパラメータが trueに設定されているためです。

� include_tagged_lcrパラメータが falseに設定されているため、NULLタグがある場合にのみ伝播で LCR を伝播するように指定されます。この動作は、伝播のシステム作成ルールを介して実行されます。

� 伝播される LCR のソース・データベースとして dbs1.netが指定されます。このデータベースは、現行のデータベースでなくてもかまいません。この伝播では、ソース・キュー内の、ソース・データベースが異なる LCR は伝播されません。

� 指定したデータベース・リンクに伝播ジョブが存在しない場合は、伝播ジョブが作成されます。

DBMS_PROPAGATION_ADM を使用した伝播の作成例を使用した伝播の作成例を使用した伝播の作成例を使用した伝播の作成例ここでは、DBMS_PROPAGATION_ADMパッケージの CREATE_PROPAGATIONプロシージャを実行して伝播を作成する例について説明します。

BEGIN DBMS_PROPAGATION_ADM.CREATE_PROPAGATION( propagation_name => 'strm02_propagation', source_queue => 'strmadmin.strm03_queue', destination_queue => 'strmadmin.strm04_queue', destination_dblink => 'dbs2.net', rule_set_name => 'strmadmin.strm01_rule_set');END;/








� 伝播 strm02_propagationが作成されます。同じ名前の伝播が存在することはできません。

� 伝播で現行のデータベース内の strm03_queueから dbs2.netデータベース内のstrm04_queueにイベントを伝播するように指定されます。伝播されるイベントは、伝播のルール・セット内のルールに応じて、取得イベントまたはユーザー・エンキュー・イベント、あるいはその両方です。

� 伝播で dbs2.netデータベース・リンクを使用してイベントを伝播するように指定されます。

� 伝播が、既存のルール・セット strm01_rule_setに関連付けられます。このルール・セットは、伝播のポジティブ・ルール・セットです。

� 指定したデータベース・リンクに伝播ジョブが存在しない場合は、伝播ジョブが作成されます。

伝播ジョブの有効化伝播ジョブの有効化伝播ジョブの有効化伝播ジョブの有効化デフォルトでは、伝播ジョブは作成時に有効化されます。伝播ジョブを無効化した後に有効化する場合は、DBMS_AQADMパッケージの ENABLE_PROPAGATION_SCHEDULEプロシージャを使用します。

たとえば、dbs2.netデータベース・リンクを使用して strmadmin.strm01_queueソース・キューからイベントを伝播させる伝播ジョブを有効化するには、次のプロシージャを実行します。

BEGIN DBMS_AQADM.ENABLE_PROPAGATION_SCHEDULE( queue_name => 'strmadmin.strm01_queue', destination => 'dbs2.net');END;/


� 3-3 ページの「取得イベントとユーザー・エンキュー・イベント」


注意注意注意注意 : このタスクを完了すると、ソース・キューから dbs2.netデータベース・リンクを使用するすべての宛先キューにイベントを伝播するすべての伝播に影響します。



伝播ジョブのスケジューリング伝播ジョブのスケジューリング伝播ジョブのスケジューリング伝播ジョブのスケジューリングDBMS_AQADMパッケージの SCHEDULE_PROPAGATIONプロシージャを使用すると、伝播ジョブをスケジュールできます。伝播ジョブに問題がある場合は、そのジョブをスケジュール解除してから再スケジュールすると、問題を解決できることがあります。

たとえば、次のプロシージャでは、dbs2.netデータベース・リンクを使用してstrmadmin.strm01_queueソース・キューからイベントを伝播させる伝播ジョブがスケジュールされます。

BEGIN DBMS_AQADM.SCHEDULE_PROPAGATION( queue_name => 'strmadmin.strm01_queue', destination => 'dbs2.net'); END;/

伝播ジョブのスケジュールの変更伝播ジョブのスケジュールの変更伝播ジョブのスケジュールの変更伝播ジョブのスケジュールの変更DBMS_AQADMパッケージの ALTER_PROPAGATION_SCHEDULEプロシージャを使用すると、既存の伝播ジョブのスケジュールを変更できます。

たとえば、dbs2.netデータベース・リンクを使用して strmadmin.strm01_queueソース・キューからイベントを伝播させる伝播ジョブについて、スケジュールを変更する必要が


� ENABLE_PROPAGATION_SCHEDULEプロシージャの使用方法の詳細は、『Oracle Streams アドバンスト・キューイング・ユーザーズ・ガイドおよびリファレンス』を参照してください。

� 3-16 ページの「伝播ジョブ」



� 10-12 ページの「伝播ジョブのスケジュール解除」

� SCHEDULE_PROPAGATIONプロシージャの使用方法の詳細は、『Oracle Streams アドバンスト・キューイング・ユーザーズ・ガイドおよびリファレンス』を参照してください。




あるとします。次のプロシージャでは、イベントを 15 分（900 秒）ごとに 300 秒の継続期間で伝播させ、25 秒待機してから、完全に伝播されたキュー内の新規イベントを伝播させるように、伝播ジョブが設定されます。

BEGIN DBMS_AQADM.ALTER_PROPAGATION_SCHEDULE( queue_name => 'strmadmin.strm01_queue', destination => 'dbs2.net', duration => 300, next_time => 'SYSDATE + 900/86400', latency => 25); END;/

伝播ジョブのスケジュール解除伝播ジョブのスケジュール解除伝播ジョブのスケジュール解除伝播ジョブのスケジュール解除DBMS_AQADMパッケージの UNSCHEDULE_PROPAGATIONプロシージャを使用すると、伝播ジョブをスケジュール解除できます。伝播ジョブに問題がある場合は、そのジョブをスケジュール解除してから再スケジュールすると、問題を解決できることがあります。

たとえば、次のプロシージャでは、dbs2.netデータベース・リンクを使用してstrmadmin.strm01_queueソース・キューからイベントを伝播させる伝播ジョブがスケジュール解除されます。

BEGIN DBMS_AQADM.UNSCHEDULE_PROPAGATION( queue_name => 'strmadmin.strm01_queue', destination => 'dbs2.net'); END;/



� ALTER_PROPAGATION_SCHEDULEプロシージャの使用方法の詳細は、『Oracle Streams アドバンスト・キューイング・ユーザーズ・ガイドおよびリファレンス』を参照してください。




伝播のルール・セットの指定伝播のルール・セットの指定伝播のルール・セットの指定伝播のルール・セットの指定伝播には、1 つのポジティブ・ルール・セットおよび 1 つのネガティブ・ルール・セットを指定できます。伝播では、イベントは、ポジティブ・ルール・セットの 1 つ以上のルールがTRUEと評価される場合は伝播され、ネガティブ・ルール・セットの 1 つ以上のルールがTRUEと評価される場合は破棄されます。ネガティブ・ルール・セットは、ポジティブ・ルール・セットの前に評価されます。

伝播のポジティブ・ルール・セットの指定伝播のポジティブ・ルール・セットの指定伝播のポジティブ・ルール・セットの指定伝播のポジティブ・ルール・セットの指定既存のルール・セットを既存の伝播のポジティブ・ルール・セットとして指定するには、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;/



� 10-11 ページの「伝播ジョブのスケジューリング」

� UNSCHEDULE_PROPAGATIONプロシージャの使用方法の詳細は、『Oracle Streams アドバンスト・キューイング・ユーザーズ・ガイドおよびリファレンス』を参照してください。







伝播のネガティブ・ルール・セットの指定伝播のネガティブ・ルール・セットの指定伝播のネガティブ・ルール・セットの指定伝播のネガティブ・ルール・セットの指定既存のルール・セットを既存の伝播のネガティブ・ルール・セットとして指定するには、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_SUBSET_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.strm01_queue', destination_queue_name => '[email protected]', include_dml => true, include_ddl => true, source_database => 'dbs1.net', inclusion_rule => true);END;/


� 2 つのルールが作成されます。一方のルールは hr.locations表に対する DML 変更の結果を含む行 LCR について TRUEと評価され、他方のルールは hr.locations表に対する DDL 変更を含む DDL LCR について TRUEと評価されます。ルール名は、システムによって指定されます。

� どちらのルールも、dbs1.netソース・データベースで変更が発生した 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.strm01_queue', destination_queue_name => '[email protected]', include_dml => true, include_ddl => true, source_database => 'dbs1.net', inclusion_rule => false);END;/


� 2 つのルールが作成されます。一方のルールは hr.departments表に対する DML 変更の結果を含む行 LCR について TRUEと評価され、他方のルールは hr.departments表に対する DDL 変更を含む DDL LCR について TRUEと評価されます。ルール名は、システムによって指定されます。



� どちらのルールも、dbs1.netソース・データベースで変更が発生した 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;/


inclusion_ruleパラメータが falseに設定されている場合、REMOVE_RULEプロシージャによって、伝播のポジティブ・ルール・セットではなくネガティブ・ルール・セットからルールが削除されます。

また、伝播のルール・セットからすべてのルールを削除する必要がある場合は、REMOVE_RULEプロシージャの実行時に rule_nameパラメータに NULLを指定します。

伝播のルール・セットの削除伝播のルール・セットの削除伝播のルール・セットの削除伝播のルール・セットの削除伝播からルール・セットを削除するように指定するには、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_AQADMパッケージのDISABLE_PROPAGATION_SCHEDULEプロシージャを使用します。

たとえば、dbs2.netデータベース・リンクを使用して strmadmin.strm01_queueソース・キューからイベントを伝播させる伝播ジョブを停止するには、次のプロシージャを実行します。

BEGIN DBMS_AQADM.DISABLE_PROPAGATION_SCHEDULE( queue_name => 'strmadmin.strm01_queue', destination => 'dbs2.net');END;/

注意注意注意注意 : 伝播にポジティブ・ルール・セットまたはネガティブ・ルール・セットを指定していない場合、その伝播では、ソース・キューのすべてのイベントが宛先キューに伝播されます。


� このタスクを完了すると、ソース・キューから dbs2.netデータベース・リンクを使用するすべての宛先キューにイベントを伝播するすべての伝播に影響します。

� DISABLE_PROPAGATION_SCHEDULEを実行すると、伝播ジョブが即時に無効化されます。現行の継続時間の終了は待機されません。

参照参照参照参照 : DISABLE_PROPAGATION_SCHEDULEプロシージャの使用方法の詳細は、『Oracle Streams アドバンスト・キューイング・ユーザーズ・ガイドおよびリファレンス』を参照してください。


Streams メッセージ環境の管理

伝播の削除伝播の削除伝播の削除伝播の削除既存の伝播を削除するには、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で使用されているすべてのルール・セットも削除されます。ただし、他の Streams クライアントで使用されているルール・セットは削除されません。drop_unused_rule_setsパラメータが trueに設定されている場合、伝播のポジティブ・ルール・セットとネガティブ・ルール・セットの両方を削除できます。このプロシージャによってルール・セットが削除された場合、そのルール・セット内のルールのうち、他のルール・セットに含まれていないルールも削除されます。

Streams メッセージ環境の管理メッセージ環境の管理メッセージ環境の管理メッセージ環境の管理Streams では、SYS.AnyData型のキューを使用したメッセージングが可能です。これらのキューでは、SYS.AnyData型のペイロードを伴うユーザー・メッセージがステージングされます。また、SYS.AnyDataペイロードは、様々なデータ型のペイロードのラッパーとして使用できます。


� SYS.AnyData ラッパーでのユーザー・メッセージ・ペイロードのラップおよびエンキュー

� SYS.AnyData ペイロードにラップされているペイロードのデキュー

� メッセージ・クライアントおよびメッセージ通知の構成

注意注意注意注意 : 伝播を削除すると、その伝播で使用されていた伝播ジョブを使用する伝播が他にない場合、その伝播ジョブは自動的に削除されます。

注意注意注意注意 : この項の例は、各データベースで Streams 管理者を構成している場合を想定しています。



SYS.AnyData ラッパーでのユーザー・メッセージ・ペイロードのラップおラッパーでのユーザー・メッセージ・ペイロードのラップおラッパーでのユーザー・メッセージ・ペイロードのラップおラッパーでのユーザー・メッセージ・ペイロードのラップおよびエンキューよびエンキューよびエンキューよびエンキュー

ほぼすべての型のペイロードは、SYS.AnyDataペイロードでラップできます。ここでは、SYS.AnyDataキューとの間でメッセージのエンキューとデキューを行う例について説明します。

次の手順に、SYS.AnyDataペイロードに様々な型のペイロードをラップする方法を示します。

1. dbs1.netデータベースでユーザーの作成、権限の付与、表領域の作成およびユーザーの変更を行うことができる管理ユーザーとして接続します。

2. oeユーザーが DBMS_AQパッケージの ENQUEUEおよび DEQUEUEプロシージャを実行できるように、DBMS_AQパッケージの EXECUTE権限を付与します。

GRANT EXECUTE ON DBMS_AQ TO oe;

3. 次の例のように、Streams 管理者として接続します。


4. SYS.AnyDataキューが存在しない場合は、これを作成します。

BEGIN DBMS_STREAMS_ADM.SET_UP_QUEUE( queue_table => 'oe_q_table_any', queue_name => 'oe_q_any', queue_user => 'oe');END;/

oeユーザーは、oe_q_anyキューの保護キュー・ユーザーとして自動的に構成され、このキューに対する ENQUEUEおよび DEQUEUE権限が付与されます。また、oeというAQ エージェントが構成され、oeユーザーと関連付けられます。ただし、メッセージ


� Streams でのメッセージングの概要は、3-11 ページの「SYS.AnyData型のキューとユーザー・メッセージ」を参照してください。


� AQ の詳細は、『Oracle Streams アドバンスト・キューイング・ユーザーズ・ガイドおよびリファレンス』を参照してください。

� SYS.AnyData型の詳細は、『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。



は、デキューできるサブスクライバが構成されるまで、キューにエンキューできません。

5. oe_q_anyキューにサブスクライバを追加します。このサブスクライバによって、イベントの明示的なデキューが実行されます。

DECLARE subscriber SYS.AQ$_AGENT;BEGIN subscriber := SYS.AQ$_AGENT('OE', NULL, NULL); SYS.DBMS_AQADM.ADD_SUBSCRIBER( queue_name => 'strmadmin.oe_q_any', subscriber => subscriber);END;/

6. oeユーザーとして接続します。

CONNECT oe/[email protected]

7. 入力パラメータとして SYS.AnyData型のオブジェクトを取り、ペイロードを含むメッセージを既存の SYS.AnyDataキューにエンキューするプロシージャを作成します。

CREATE OR REPLACE PROCEDURE oe.enq_proc (payload SYS.AnyData) IS enqopt DBMS_AQ.ENQUEUE_OPTIONS_T; mprop DBMS_AQ.MESSAGE_PROPERTIES_T; enq_msgid RAW(16);BEGIN mprop.SENDER_ID := SYS.AQ$_AGENT('OE', NULL, NULL); DBMS_AQ.ENQUEUE( queue_name => 'strmadmin.oe_q_any', enqueue_options => enqopt, message_properties => mprop, payload => payload, msgid => enq_msgid);END;/

8. 適切な Convertdata_typeファンクションを指定して、手順 7 で作成したプロシージャを実行します。次のコマンドでは、様々な型のメッセージがエンキューされます。

VARCHAR2型 :

EXEC oe.enq_proc(SYS.AnyData.ConvertVarchar2('Chemicals - SW'));COMMIT;



NUMBER型 :

EXEC oe.enq_proc(SYS.AnyData.ConvertNumber('16'));COMMIT;

ユーザー定義型 :

BEGIN oe.enq_proc(SYS.AnyData.ConvertObject(oe.cust_address_typ( '1646 Brazil Blvd','361168','Chennai','Tam', 'IN')));END;/COMMIT;

SYS.AnyData ペイロードにラップされているペイロードのデキューペイロードにラップされているペイロードのデキューペイロードにラップされているペイロードのデキューペイロードにラップされているペイロードのデキュー次の手順に、SYS.AnyDataペイロードにラップされているペイロードをデキューする方法を示します。この例では、10-19 ページの「SYS.AnyData ラッパーでのユーザー・メッセージ・ペイロードのラップおよびエンキュー」の手順を完了していることを想定しています。

メッセージをデキューするには、メッセージのコンシューマを知る必要があります。キュー内のメッセージのコンシューマを検索するには、そのキューの所有者として接続し、AQ$queue_table_nameを問い合せます。この場合、queue_table_nameはキュー表名です。たとえば、oe_q_anyキュー内のメッセージのコンシューマを検索するには、次の問合せを実行します。


SELECT MSG_ID, MSG_STATE, CONSUMER_NAME FROM AQ$OE_Q_TABLE_ANY;


CONNECT oe/[email protected]

2. デキューするメッセージのコンシューマを入力として取るプロシージャを作成します。次の例のプロシージャでは、oe.cust_address_typのメッセージがデキューされ、その内容が出力されます。

CREATE OR REPLACE PROCEDURE oe.get_cust_address (consumer IN VARCHAR2) AS address OE.CUST_ADDRESS_TYP; deq_address SYS.AnyData; msgid RAW(16); deqopt DBMS_AQ.DEQUEUE_OPTIONS_T; mprop DBMS_AQ.MESSAGE_PROPERTIES_T;

参照参照参照参照 : これらのエンキューされたメッセージの内容を表示する方法については、14-23 ページの「キュー内のユーザー・エンキュー・イベントの内容の表示」を参照してください。



new_addresses BOOLEAN := true; next_trans EXCEPTION; no_messages EXCEPTION; pragma exception_init (next_trans, -25235); pragma exception_init (no_messages, -25228); num_var pls_integer;BEGIN deqopt.consumer_name := consumer; deqopt.wait := 1; WHILE (new_addresses) LOOP BEGIN DBMS_AQ.DEQUEUE( queue_name => 'strmadmin.oe_q_any', dequeue_options => deqopt, message_properties => mprop, payload => deq_address, msgid => msgid);

deqopt.navigation := DBMS_AQ.NEXT; DBMS_OUTPUT.PUT_LINE('****'); IF (deq_address.GetTypeName() = 'OE.CUST_ADDRESS_TYP') THEN DBMS_OUTPUT.PUT_LINE('Message TYPE is: ' || deq_address.GetTypeName()); num_var := deq_address.GetObject(address); DBMS_OUTPUT.PUT_LINE(' **** CUSTOMER ADDRESS **** '); DBMS_OUTPUT.PUT_LINE(address.street_address); DBMS_OUTPUT.PUT_LINE(address.postal_code); DBMS_OUTPUT.PUT_LINE(address.city); DBMS_OUTPUT.PUT_LINE(address.state_province); DBMS_OUTPUT.PUT_LINE(address.country_id); ELSE DBMS_OUTPUT.PUT_LINE('Message TYPE is: ' || deq_address.GetTypeName()); END IF; COMMIT; EXCEPTION WHEN next_trans THEN deqopt.navigation := DBMS_AQ.NEXT_TRANSACTION; WHEN no_messages THEN new_addresses := false; DBMS_OUTPUT.PUT_LINE('No more messages'); END; END LOOP; END;/



3. 手順 1 で作成したプロシージャを実行し、次の例のようにデキューするメッセージのコンシューマを指定します。

SET SERVEROUTPUT ON SIZE 100000EXEC oe.get_cust_address('OE');

メッセージ・クライアントおよびメッセージ通知の構成メッセージ・クライアントおよびメッセージ通知の構成メッセージ・クライアントおよびメッセージ通知の構成メッセージ・クライアントおよびメッセージ通知の構成この項では、データベースの次の要素を構成する手順について説明します。

� データベースの SYS.AnyDataキューにメッセージをエンキューするエンキュー・プロシージャ。次の例では、エンキュー・プロシージャでトリガーを使用して、oe.orders表に行が挿入されるたびにメッセージをエンキューします。

� ルールに基づいてユーザー・エンキュー・イベントをデキュー可能なメッセージ・クライアント。次の例では、メッセージ・クライアントはルールを使用して、oe.orders表を含むメッセージのみをデキューします。また、メッセージ・クライアントは、DBMS_STREAMS_MESSAGINGの DEQUEUEプロシージャを使用して、メッセージを 1 つずつデキューし、注文の注文番号を表示します。

� メッセージ・クライアントに対するメッセージ通知。次の例では、メッセージがメッセージ・クライアントによって使用されているキューにエンキューされると、通知が電子メール・アドレスに送信されます。また、メッセージがメッセージ・クライアントのルール・セットを満たしているため、メッセージ・クライアントはメッセージをデキューできます。

DBA_STREAMS_MESSAGE_CONSUMERSデータ・ディクショナリ・ビューに対して、既存のメッセージ・クライアントおよび通知に関する情報を問合せできます。

次の手順に従って、メッセージ・クライアントおよびメッセージ通知を構成します。

1. 権限を付与でき、提供されているパッケージ内のサブプログラムを実行できる管理ユーザーとして接続します。

2. DBMS_AQELMパッケージを使用して、電子メールの送信に使用するホスト名、メール・ポート、および電子メール通知の電子メール・メッセージを送信する電子メール・アカウントを設定します。次の例では、メール・ホスト名が smtp.mycompany.com、メール・ポートが 25、電子メール・アカウントが [email protected]に設定されます。

BEGIN DBMS_AQELM.SET_MAILHOST('smtp.mycompany.com') ; DBMS_AQELM.SET_MAILPORT(25) ; DBMS_AQELM.SET_SENDFROM('[email protected]');END;/

データベースの現行のメール・ホスト、メール・ポート、および送信元の設定を判断するには、DBMS_AQELMパッケージのプロシージャを使用してこれらの情報を取得しま



す。たとえば、データベースの現行のメール・ホストを判断するには、DBMS_AQELM.GET_MAILHOSTプロシージャを使用します。

3. メッセージ・クライアントの作成、メッセージのエンキューとデキュー、およびメッセージ通知の指定を行うユーザーに、必要な権限を付与します。この例では、oeユーザーがこれらすべてのタスクを実行します。

GRANT EXECUTE ON DBMS_AQ TO oe;GRANT EXECUTE ON DBMS_STREAMS_ADM TO oe;GRANT EXECUTE ON DBMS_STREAMS_MESSAGING TO oe;

BEGIN DBMS_RULE_ADM.GRANT_SYSTEM_PRIVILEGE( privilege => DBMS_RULE_ADM.CREATE_RULE_SET_OBJ, grantee => 'oe', grant_option => false);END;/

BEGIN DBMS_RULE_ADM.GRANT_SYSTEM_PRIVILEGE( privilege => DBMS_RULE_ADM.CREATE_RULE_OBJ, grantee => 'oe', grant_option => false);END;/

BEGIN DBMS_RULE_ADM.GRANT_SYSTEM_PRIVILEGE( privilege => DBMS_RULE_ADM.CREATE_EVALUATION_CONTEXT_OBJ, grantee => 'oe', grant_option => false);END;/


CONNECT oe/oe

5. 次の例のように、SET_UP_QUEUEを使用して SYS.AnyDataキューを作成します。

BEGIN DBMS_STREAMS_ADM.SET_UP_QUEUE( queue_table => 'oe.notification_queue_table',

queue_name => 'oe.notification_queue');END;/



6. 次の例のように、ユーザー・エンキュー・メッセージ用の型を作成します。

CREATE TYPE oe.user_msg AS OBJECT( object_name VARCHAR2(30), object_owner VARCHAR2(30), message VARCHAR2(50));/

7. 次の例のように、注文が oe.orders表に挿入されるたびにメッセージをキューにエンキューするトリガーを作成します。

CREATE OR REPLACE TRIGGER oe.order_insert AFTER INSERTON oe.orders FOR EACH ROWDECLARE msg oe.user_msg; str VARCHAR2(2000);BEGIN str := 'New Order - ' || :NEW.ORDER_ID || ' Order ID'; msg := oe.user_msg( object_name => 'ORDERS', object_owner => 'OE', message => str); DBMS_STREAMS_MESSAGING.ENQUEUE ( queue_name => 'oe.notification_queue', payload => SYS.AnyData.CONVERTOBJECT(msg));END;/

8. 次の例のように、キューからメッセージをデキューするメッセージ・クライアント、およびそのメッセージ・クライアントがデキューするメッセージを判断するために使用するルールを作成します。

BEGIN DBMS_STREAMS_ADM.ADD_MESSAGE_RULE ( message_type => 'oe.user_msg', rule_condition => ' :msg.OBJECT_OWNER = ''OE'' AND ' || ' :msg.OBJECT_NAME = ''ORDERS'' ', streams_type => 'dequeue', streams_name => 'oe', queue_name => 'oe.notification_queue');END;/



9. 次の例のように、メッセージ・クライアントがデキュー可能なメッセージのエンキュー時に電子メールを送信するように、メッセージ通知を設定します。

BEGIN DBMS_STREAMS_ADM.SET_MESSAGE_NOTIFICATION ( streams_name => 'oe', notification_action => '[email protected]', notification_type => 'MAIL', include_notification => true, queue_name => 'oe.notification_queue');END;/

10. 次の例のように、メッセージ・クライアントを使用してメッセージをデキューするPL/SQL プロシージャを作成します。

CREATE OR REPLACE PROCEDURE oe.deq_notification(consumer IN VARCHAR2) AS msg SYS.AnyData; user_msg oe.user_msg; num_var PLS_INTEGER; more_messages BOOLEAN := true; navigation VARCHAR2(30);BEGIN navigation := 'FIRST MESSAGE'; WHILE (more_messages) LOOP BEGIN DBMS_STREAMS_MESSAGING.DEQUEUE( queue_name => 'oe.notification_queue', streams_name => consumer, payload => msg, navigation => navigation, wait => DBMS_STREAMS_MESSAGING.NO_WAIT); IF msg.GETTYPENAME() = 'OE.USER_MSG' THEN num_var := msg.GETOBJECT(user_msg); DBMS_OUTPUT.PUT_LINE(user_msg.object_name); DBMS_OUTPUT.PUT_LINE(user_msg.object_owner); DBMS_OUTPUT.PUT_LINE(user_msg.message); END IF; navigation := 'NEXT MESSAGE'; COMMIT; EXCEPTION WHEN SYS.DBMS_STREAMS_MESSAGING.ENDOFCURTRANS THEN navigation := 'NEXT TRANSACTION'; WHEN DBMS_STREAMS_MESSAGING.NOMOREMSGS THEN more_messages := false; DBMS_OUTPUT.PUT_LINE('No more messages.'); WHEN OTHERS THEN RAISE; END;



END LOOP;END;/

11. 次の例のように、oe.orders表に行を挿入します。

INSERT INTO oe.orders VALUES(2521, 'direct', 144, 0, 922.57, 159, NULL);INSERT INTO oe.orders VALUES(2522, 'direct', 116, 0, 1608.29, 153, NULL);COMMIT;INSERT INTO oe.orders VALUES(2523, 'direct', 116, 0, 227.55, 155, NULL);COMMIT;

メッセージがエンキューされるたびに、メッセージ通知によって、手順 9 で指定した電子メール・アドレスにメッセージが送信されます。各通知は AQXmlNotificationです。これには、次の内容が含まれています。

� notification_options: これには次の内容が含まれています。

� destination: メッセージがデキューされた宛先キュー

� consumer_name: メッセージをデキューしたメッセージ・クライアントの名前

� message_set: メッセージのプロパティのセット

次に、電子メール通知で送信される AQXmlNotificationの書式の例を示します。

<?xml version="1.0" encoding="UTF-8"?><Envelope xmlns="http://ns.oracle.com/AQ/schemas/envelope"> <Body> <AQXmlNotification xmlns="http://ns.oracle.com/AQ/schemas/access"> <notification_options> <destination>OE.NOTIFICATION_QUEUE</destination> <consumer_name>OE</consumer_name> </notification_options> <message_set> <message> <message_header> <message_id>CB510DDB19454731E034080020AE3E0A</message_id> <expiration>-1</expiration> <delay>0</delay> <priority>1</priority> <delivery_count>0</delivery_count> <sender_id> <agent_name>OE</agent_name> <protocol>0</protocol> </sender_id> <message_state>0</message_state> </message_header> </message> </message_set> </AQXmlNotification>



</Body></Envelope>

oe.deq_notificationプロシージャを実行すると、この例でエンキューされたメッセージをデキューできます。

SET SERVEROUTPUT ON SIZE 100000EXEC oe.deq_notification('OE');


� 14-20 ページの「データベース内のメッセージ・クライアントの表示」

� 14-21 ページの「メッセージ通知の表示」


� メッセージ通知および XML の詳細は、『Oracle Streams アドバンスト・キューイング・ユーザーズ・ガイドおよびリファレンス』および

『Oracle XML DB 開発者ガイド』を参照してください。


適用プロ

11
適用プロセスの管理適用プロセスの管理適用プロセスの管理適用プロセスの管理
Streams の適用プロセスでは、特定のキューから論理変更レコード（LCR）とユーザー・メッセージがデキューされ、それが直接適用されるか、ユーザー定義プロシージャにパラメータとして渡されます。


� 適用プロセスの作成、起動、停止および削除

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

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

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

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

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

� 適用プロセスによるイベントのエンキューの指定

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

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

� 適用エラーの管理





� 適用プロセスの DML ハンドラ、DDL ハンドラおよび Streams タグの管理の詳細は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。

セスの管理 11-1

適用プロセスの作成、起動、停止および削除

適用プロセスの作成、起動、停止および削除適用プロセスの作成、起動、停止および削除適用プロセスの作成、起動、停止および削除適用プロセスの作成、起動、停止および削除この項では、適用プロセスを作成、起動、停止および削除する手順について説明します。この項の内容は、次のとおりです。

� 適用プロセスの作成

� 適用プロセスの起動

� 適用プロセスの停止

� 適用プロセスの削除

適用プロセスの作成適用プロセスの作成適用プロセスの作成適用プロセスの作成次のどのプロシージャでも、適用プロセスを作成できます。






� DBMS_APPLY_ADM.CREATE_APPLY

DBMS_STREAMS_ADMパッケージの各プロシージャでは、指定した名前の適用プロセスが存在しない場合は適用プロセスが作成され、適用プロセスにポジティブ・ルール・セットまたはネガティブ・ルール・セットが存在しない場合はそのいずれかのルール・セットが作成されます。また、ルール・セットに表ルール、スキーマ・ルール、グローバル・ルールまたはメッセージ・ルールを追加できます。

DBMS_APPLY_ADMパッケージの CREATE_APPLYプロシージャでは、適用プロセスは作成されますが、そのルール・セットやルールは作成されません。ただし、CREATE_APPLYプロシージャを使用すると、ポジティブ・ルール・セットまたはネガティブ・ルール・セットとして適用プロセスに関連付ける既存のルール・セットを指定できます。また、適用ハンドラ、適用ユーザー、適用タグ、取得イベントとユーザー・エンキュー・イベントのどちらを適用するかなど、他の多数のオプションを指定できます。

適用プロセスに関連付ける SYS.AnyDataキューが存在しない場合は、先にそのキューを作成してから、適用プロセスを作成します。



DBMS_STREAMS_ADM を使用した適用プロセスの作成例を使用した適用プロセスの作成例を使用した適用プロセスの作成例を使用した適用プロセスの作成例この項の初の例では、取得イベントを適用する適用プロセスが作成され、2 番目の例ではユーザー・エンキュー・イベントを適用する適用プロセスが作成されます。1 つの適用プロセスで取得イベントとユーザー・エンキュー・イベントの両方を適用することはできません。

� DBMS_STREAMS_ADM を使用した取得イベント用の適用プロセスの作成例

� DBMS_STREAMS_ADM を使用したユーザー・エンキュー・イベント用の適用プロセスの作成例


� 作成する適用プロセスの構成によっては、適用プロセスで変更を適用する表の列について、ソース・データベースでサプリメンタル・ロギングが必要になる場合があります。

� 適用プロセスを作成するには、ユーザーに DBAロールが付与されている必要があります。


� 10-2 ページの「SYS.AnyData キューの作成」

� サプリメンタル・ロギングが必要な場合については、2-13 ページの「Streams 環境内のサプリメンタル・ロギング」を参照してください。

� 9-31 ページの「ソース・データベースでのサプリメンタル・ロギングの指定」


� 4-15 ページの「適用プロセスの作成」



適用プロセスの管理 11-3


DBMS_STREAMS_ADM を使用した取得イベント用の適用プロセスの作成例を使用した取得イベント用の適用プロセスの作成例を使用した取得イベント用の適用プロセスの作成例を使用した取得イベント用の適用プロセスの作成例ここでは、DBMS_STREAMS_ADMパッケージの ADD_SCHEMA_RULESプロシージャを実行して、取得イベントを適用する適用プロセスを作成する例について説明します。

BEGIN DBMS_STREAMS_ADM.ADD_SCHEMA_RULES( schema_name => 'hr', streams_type => 'apply', streams_name => 'strm01_apply', queue_name => 'strm01_queue', include_dml => true, include_ddl => false, include_tagged_lcr => false, source_database => 'dbs1.net', inclusion_rule => true);END;/


� 取得イベントをローカル・データベースに適用する適用プロセス strm01_applyが作成されます。この適用プロセスが作成されるのは、それが存在しない場合のみです。

� 適用プロセスが、既存のキュー strm01_queueに関連付けられます。

� inclusion_ruleパラメータが trueに設定されているため、適用プロセスにポジティブ・ルール・セットが存在しない場合は、ポジティブ・ルール・セットが作成され、適用プロセスに関連付けられます。このルール・セットでは、SYS.STREAMS$_EVALUATION_CONTEXT評価コンテキストが使用されます。ルール・セット名は、システムによって指定されます。

� ルールが 1 つ作成されます。このルールは、hrスキーマ内のデータベース・オブジェクトに対する DML 変更の結果を含む行 LCR について、TRUEと評価されます。ルール名は、システムによって指定されます。

� inclusion_ruleパラメータが trueに設定されているため、そのルールは適用プロセスに関連付けられたポジティブ・ルール・セットに追加されます。

� 適用プロセスの apply_tagが、'00'（2 つのゼロ）と等価の 16 進値に設定されます。適用プロセスで生成される REDO エントリのタグは、この値になります。

� include_tagged_lcrパラメータが falseに設定されているため、NULLタグがある場合にのみ適用プロセスで行 LCR を適用するように指定されます。この動作は、適用プロセスのシステム作成ルールを介して実行されます。

� 適用プロセスによって適用された LCR が dbs1.netソース・データベースで発生するように指定されます。適用プロセス・ルール内のルールによって、適用プロセスでデキューするイベントが決定されます。適用プロセスでは、dbs1.net以外のソース・データベースが指定されている LCR をデキューすると、エラーが発生します。



DBMS_STREAMS_ADM を使用したユーザー・エンキュー・イベント用の適用プロセスの作成を使用したユーザー・エンキュー・イベント用の適用プロセスの作成を使用したユーザー・エンキュー・イベント用の適用プロセスの作成を使用したユーザー・エンキュー・イベント用の適用プロセスの作成例例例例ここでは、DBMS_STREAMS_ADMパッケージの ADD_MESSAGE_RULEプロシージャを実行して、適用プロセスを作成する例について説明します。

BEGIN DBMS_STREAMS_ADM.ADD_MESSAGE_RULE( message_type => 'oe.order_typ', rule_condition => ':msg.order_status = 1', streams_type => 'apply', streams_name => 'strm02_apply', queue_name => 'strm02_queue', inclusion_rule => true);END;/


� oe.order_typ型のユーザー・エンキュー・イベントをデキューする適用プロセスstrm02_applyが作成され、適用プロセスのメッセージ・ハンドラに送信されます。この適用プロセスが作成されるのは、それが存在しない場合のみです。


� inclusion_ruleパラメータが trueに設定されているため、適用プロセスにポジティブ・ルール・セットが存在しない場合は、ポジティブ・ルール・セットが作成され、適用プロセスに関連付けられます。ルール・セット名はシステムによって指定され、そのルール・セットでは評価コンテキストは使用されません。

� ルール条件を満たすユーザー・エンキュー・イベントが TRUEと評価される 1 つのルールが作成されます。そのルールでは、メッセージ型用のシステム作成評価コンテキストが使用されます。ルール名および評価コンテキスト名は、システムによって指定されます。


� 適用プロセスの apply_tagが、'00'（2 つのゼロ）と等価の 16 進値に設定されます。メッセージ・ハンドラが生成する REDO エントリなど、適用プロセスで生成されるREDO エントリのタグは、この値になります。

注意注意注意注意 : 適用プロセスのメッセージ・ハンドラを指定するには、DBMS_APPLY_ADMパッケージの ALTER_APPLYプロシージャを使用します。



DBMS_APPLY_ADM を使用した適用プロセスの作成例を使用した適用プロセスの作成例を使用した適用プロセスの作成例を使用した適用プロセスの作成例この項の初の例では、取得イベントを適用する適用プロセスが作成され、2 番目の例ではユーザー・エンキュー・イベントを適用する適用プロセスが作成されます。1 つの適用プロセスで取得イベントとユーザー・エンキュー・イベントの両方を適用することはできません。

� DBMS_APPLY_ADM を使用した取得イベント用の適用プロセスの作成例

� DBMS_APPLY_ADM を使用したユーザー・エンキュー・イベント用の適用プロセスの作成例

DBMS_APPLY_ADM を使用した取得イベント用の適用プロセスの作成例を使用した取得イベント用の適用プロセスの作成例を使用した取得イベント用の適用プロセスの作成例を使用した取得イベント用の適用プロセスの作成例ここでは、DBMS_APPLY_ADMパッケージの CREATE_APPLYプロシージャを実行して、取得イベントを適用する適用プロセスを作成する例について説明します。

BEGIN DBMS_APPLY_ADM.CREATE_APPLY( queue_name => 'strm03_queue', apply_name => 'strm03_apply', rule_set_name => 'strmadmin.strm03_rule_set', message_handler => NULL, ddl_handler => 'strmadmin.history_ddl', apply_user => 'hr', apply_database_link => NULL, apply_tag => HEXTORAW('5'), apply_captured => true, precommit_handler => NULL, negative_rule_set_name => NULL,


� 6-32 ページの「メッセージ・ルールの例」

� 6-42 ページの「メッセージ・ルールの評価コンテキスト」


� 4-15 ページの「適用プロセスの作成」

� 適用ハンドラの詳細は、4-4 ページの「適用プロセスによるイベント処理オプション」を参照してください。


� apply_database_linkパラメータを使用して、Oracle 以外のデータベースにイベントを適用するように適用プロセスを構成する方法については、『Oracle Streams レプリケーション管理者ガイド』を参照してください。



source_database => 'dbs1.net');END;/


� 適用プロセス strm03_applyが作成されます。同じ名前の適用プロセスは存在できません。


� 適用プロセスが、既存のルール・セット strm03_rule_setに関連付けられます。このルール・セットは、適用プロセスのポジティブ・ルール・セットです。

� 適用プロセスではメッセージ・ハンドラを使用しないように指定されます。

� DDL ハンドラとして strmadminスキーマ内の history_ddl PL/SQL プロシージャが指定されます。CREATE_APPLYプロシージャを実行するユーザーは、history_ddl PL/SQL プロシージャの EXECUTE権限を持っている必要があります。このプロシージャの作成例は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。

� 変更を適用するユーザーとして、CREATE_APPLYプロシージャを実行中のユーザー（Streams 管理者）ではなく hrが指定されます。

� apply_database_linkパラメータが NULLに設定されているため、適用プロセスではローカル・データベースに変更を適用するように指定されます。

� 適用プロセスで生成される各 REDO エントリのタグとして、'5'と等価の 16 進値が指定されます。

� 適用プロセスではユーザー・エンキュー・イベントではなく取得された LCR を適用するように指定されます。したがって、取得プロセスではなくユーザー・アプリケーションによって構成された LCR が適用プロセス用のキュー内でステージングされても、この適用プロセスでは LCR は適用されません。

� 適用プロセスではプリコミット・ハンドラを使用しないように指定されます。

� 適用プロセスではネガティブ・ルール・セットを使用しないように指定されます。

� 適用プロセスによって適用された LCR が dbs1.netソース・データベースで発生するように指定されます。適用プロセス・ルール内のルールによって、適用プロセスでデキューするイベントが決定されます。適用プロセスでは、dbs1.net以外のソース・データベースが指定されている LCR をデキューすると、エラーが発生します。



DBMS_APPLY_ADM を使用したユーザー・エンキュー・イベント用の適用プロセスの作成例を使用したユーザー・エンキュー・イベント用の適用プロセスの作成例を使用したユーザー・エンキュー・イベント用の適用プロセスの作成例を使用したユーザー・エンキュー・イベント用の適用プロセスの作成例ここでは、DBMS_APPLY_ADMパッケージの CREATE_APPLYプロシージャを実行して、ユーザー・エンキュー・イベントを適用する適用プロセスを作成する例について説明します。

BEGIN DBMS_APPLY_ADM.CREATE_APPLY( queue_name => 'strm04_queue', apply_name => 'strm04_apply', rule_set_name => 'strmadmin.strm04_rule_set', message_handler => 'strmadmin.mes_handler', ddl_handler => NULL, apply_user => NULL, apply_database_link => NULL, apply_tag => NULL, apply_captured => false, precommit_handler => NULL, negative_rule_set_name => NULL);END;/


� 適用プロセス strm04_applyが作成されます。同じ名前の適用プロセスは存在できません。


� 適用プロセスが、既存のルール・セット strm04_rule_setに関連付けられます。このルール・セットは、適用プロセスのポジティブ・ルール・セットです。

� メッセージ・ハンドラとして strmadminスキーマ内の mes_handler PL/SQL プロシージャが指定されます。CREATE_APPLYプロシージャを実行するユーザーは、mes_handler PL/SQL プロシージャの EXECUTE権限を持っている必要があります。

� 適用プロセスでは DDL ハンドラを使用しないように指定されます。

� apply_userパラメータが NULLに設定されているため、CREATE_APPLYプロシージャを実行するユーザーが変更を適用するユーザーとして指定されます。

� apply_database_linkパラメータが NULLに設定されているため、適用プロセスではローカル・データベースに変更を適用するように指定されます。

� 適用プロセスで生成される各 REDO エントリが NULLタグを持つように指定されます。

� 適用プロセスでは取得イベントではなくユーザー・エンキュー・イベントを適用するように指定されます。

� 適用プロセスではプリコミット・ハンドラを使用しないように指定されます。

� 適用プロセスではネガティブ・ルール・セットを使用しないように指定されます。



適用プロセスの起動適用プロセスの起動適用プロセスの起動適用プロセスの起動既存の適用プロセスを起動するには、DBMS_APPLY_ADMパッケージの START_APPLYプロシージャを実行します。たとえば、次のプロシージャでは、適用プロセス strm01_applyが起動されます。

BEGIN DBMS_APPLY_ADM.START_APPLY( apply_name => 'strm01_apply');END;/

適用プロセスの停止適用プロセスの停止適用プロセスの停止適用プロセスの停止既存の適用プロセスを停止するには、DBMS_APPLY_ADMパッケージの STOP_APPLYプロシージャを実行します。たとえば、次のプロシージャでは、適用プロセス strm01_applyが停止されます。

BEGIN DBMS_APPLY_ADM.STOP_APPLY( apply_name => 'strm01_apply');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で使用されているすべてのルール・セットも削除されます（ルール・セットが他の Streams クライアントによって使用されている場合を除く）。drop_unused_rule_setsパラメータが trueに設定されている場合、適用プロセスのポジティブ・ルール・セットとネガティブ・ルール・セットの両方を削除できます。このプロシージャがルール・セットを削除する場合、そのルール・セット内のルールで、他のルール・セットに含まれていないルールも削除します。


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

適用プロセスの削除を試行する場合、指定した適用プロセスのエラー・キューにエラーが存在すると、エラーが発生します。したがって、適用プロセスのエラー・キューにエラーが存在する場合は、適用プロセスを削除する前にエラーを削除します。

適用プロセスのルール・セットの管理適用プロセスのルール・セットの管理適用プロセスのルール・セットの管理適用プロセスのルール・セットの管理この項では、次のタスクの手順について説明します。

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

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

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

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

適用プロセスのルール・セットの指定適用プロセスのルール・セットの指定適用プロセスのルール・セットの指定適用プロセスのルール・セットの指定適用プロセスには、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;/

参照参照参照参照 : 11-29 ページの「適用エラーの管理」






適用プロセスのネガティブ・ルール・セットの指定適用プロセスのネガティブ・ルール・セットの指定適用プロセスのネガティブ・ルール・セットの指定適用プロセスのネガティブ・ルール・セットの指定既存のルール・セットを既存の適用プロセスのネガティブ・ルール・セットとして指定するには、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;/

適用プロセスのルール・セットへのルールの追加適用プロセスのルール・セットへのルールの追加適用プロセスのルール・セットへのルールの追加適用プロセスのルール・セットへのルールの追加適用プロセスのルール・セットにルールを追加するには、次のいずれかのプロシージャを実行します。





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 => 'strm01_queue', include_dml => true, include_ddl => true,




source_database => 'dbs1.net', inclusion_rule => true);END;/


� ルールが 1 つ作成されます。このルールは、hr.departments表に対する DML 変更の結果を含む行 LCR について TRUEと評価されます。ルール名は、システムによって指定されます。

� ルールが 1 つ作成されます。このルールは、hr.departments表に対する DDL 変更を含む DDL LCR について TRUEと評価されます。ルール名は、システムによって指定されます。

� どちらのルールも dbs1.netソース・データベースで変更が発生した LCR についてのみ 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 => 'strm01_queue', include_dml => true, include_ddl => true, source_database => 'dbs1.net', inclusion_rule => false);END;/


� ルールが 1 つ作成されます。このルールは、hr.regions表に対する DML 変更の結果を含む行 LCR について TRUEと評価されます。ルール名は、システムによって指定されます。

� ルールが 1 つ作成されます。このルールは、hr.regions表に対する DDL 変更を含むDDL LCR について TRUEと評価されます。ルール名は、システムによって指定されます。



� どちらのルールも dbs1.netソース・データベースで変更が発生した 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;/


inclusion_ruleパラメータが falseに設定されている場合、REMOVE_RULEプロシージャによって、適用プロセスのポジティブ・ルール・セットではなくネガティブ・ルール・セットからルールが削除されます。

また、適用プロセスのルール・セットからすべてのルールを削除する必要がある場合は、REMOVE_RULEプロシージャの実行時に rule_nameパラメータに NULLを指定します。

適用プロセスのルール・セットの削除適用プロセスのルール・セットの削除適用プロセスのルール・セットの削除適用プロセスのルール・セットの削除既存の適用プロセスからルール・セットを削除するように指定するには、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;/

適用プロセス・パラメータの設定適用プロセス・パラメータの設定適用プロセス・パラメータの設定適用プロセス・パラメータの設定適用プロセスのパラメータを設定するには、DBMS_APPLY_ADMパッケージのSET_PARAMETERプロシージャを使用します。適用プロセス・パラメータでは、適用プロセスの動作を制御します。

たとえば、次のプロシージャでは、適用プロセス strm01_applyのcommit_serializationパラメータが noneに設定されます。commit_serializationパラメータをこの値に設定すると、適用プロセスではトランザクションを任意の順序でコミットできます。

BEGIN DBMS_APPLY_ADM.SET_PARAMETER( apply_name => 'strm01_apply', parameter => 'commit_serialization', value => 'none');END;/

注意注意注意注意 : 取得イベントを適用する適用プロセスにポジティブ・ルール・セットまたはネガティブ・ルール・セットを指定していない場合、適用プロセスで、キュー内のすべての取得イベントが適用されます。同様に、ユーザー・エンキュー・イベントを適用する適用プロセスにポジティブ・ルール・セットまたはネガティブ・ルール・セットを指定していない場合、適用プロセスで、キュー内のすべてのユーザー・エンキュー・イベントが適用されます。


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

適用プロセスの適用ユーザーの設定適用プロセスの適用ユーザーの設定適用プロセスの適用ユーザーの設定適用プロセスの適用ユーザーの設定適用ユーザーは、適用プロセスのルール・セットを満たすすべての DML 変更および DDL変更を適用し、ユーザー定義の適用ハンドラを実行するユーザーです。適用プロセスの適用ユーザーを設定するには、DBMS_APPLY_ADMパッケージの ALTER_APPLYプロシージャでapply_userパラメータを使用します。

適用ユーザーを変更するには、ALTER_APPLYプロシージャを起動するユーザーに DBAロールが付与されている必要があります。SYSユーザーのみが、apply_userを SYSに設定できます。

たとえば、次のプロシージャでは、適用プロセス strm03_applyの適用ユーザーが hrに設定されます。

BEGIN DBMS_APPLY_ADM.ALTER_APPLY( apply_name => 'strm03_apply', apply_user => 'hr');END;/


� valueパラメータは、パラメータ値が数値の場合にも、常にVARCHAR2として入力されます。

� parallelism適用プロセス・パラメータを 1よりも大きい値に設定する場合は、適用プロセスで変更が適用される表のすべての一意キー列と外部キー列について、ソース・データベースで条件付きのサプリメンタル・ログ・グループを指定する必要があります。構成によっては、これらの表の他の列についてもサプリメンタル・ロギングが必要になる場合があります。


� 4-17 ページの「適用プロセスのパラメータ」

� 適用プロセス・パラメータの詳細は、『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』のDBMS_APPLY_ADM.SET_PARAMETERプロシージャに関する説明を参照してください。

� 9-31 ページの「ソース・データベースでのサプリメンタル・ロギングの指定」


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

このプロシージャを実行すると、新しい適用ユーザーに、適用プロセスで使用するキューのデキュー権限が付与され、そのユーザーがキューの保護キュー・ユーザーとして構成されます。また、適用ユーザーが次の権限を持っていることを確認する必要があります。

� 適用プロセスで使用するルール・セットの実行権限

� ルール・セットで使用するすべてのルールベースの変換ファンクションの実行権限

� すべての適用ハンドラ・プロシージャの実行権限

これらの権限は、適用ユーザーに直接付与する必要があります。これらの権限は、ロールを介しては付与できません。

適用プロセスのメッセージ・ハンドラの管理適用プロセスのメッセージ・ハンドラの管理適用プロセスのメッセージ・ハンドラの管理適用プロセスのメッセージ・ハンドラの管理この項では、適用プロセスのメッセージ・ハンドラを設定する手順と削除する手順について説明します。

適用プロセスのメッセージ・ハンドラの設定適用プロセスのメッセージ・ハンドラの設定適用プロセスのメッセージ・ハンドラの設定適用プロセスのメッセージ・ハンドラの設定適用プロセスのメッセージ・ハンドラを設定するには、DBMS_APPLY_ADMパッケージのALTER_APPLYプロシージャで message_handlerパラメータを使用します。たとえば、次のプロシージャでは、適用プロセス strm03_applyのメッセージ・ハンドラに、strmadminスキーマ内の mes_handlerプロシージャが設定されます。

BEGIN DBMS_APPLY_ADM.ALTER_APPLY( apply_name => 'strm03_apply', message_handler => 'strmadmin.mes_handler');END;/

ALTER_APPLYプロシージャを実行するユーザーは、指定したメッセージ・ハンドラのEXECUTE権限を持っている必要があります。


� 4-3 ページの「適用プロセスによるイベント処理」

� メッセージ・ハンドラの作成例については、『Oracle Streams アドバンスト・キューイング・ユーザーズ・ガイドおよびリファレンス』を参照してください。


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

適用プロセスのメッセージ・ハンドラの削除適用プロセスのメッセージ・ハンドラの削除適用プロセスのメッセージ・ハンドラの削除適用プロセスのメッセージ・ハンドラの削除適用プロセスのメッセージ・ハンドラを削除するには、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 の場合、コミット・ディレクティブにソース・データベースからのトランザクションのコミット SCN が含まれますが、ユーザー・エンキュー・イベントの場合、コミット 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表に行を挿入します。この例で作成されるプリコミット・ハンドラは、トランザクションのコミット時に strmadmin.history_row_lcrs表に行を挿入します。

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;/


� 4-8 ページの「プリコミット・ハンドラを使用したイベントのコミット情報の監査」

� この例で言及した DML ハンドラの詳細は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。


適用プロセスによるイベントのエンキューの指定

適用プロセスのプリコミット・ハンドラの設定適用プロセスのプリコミット・ハンドラの設定適用プロセスのプリコミット・ハンドラの設定適用プロセスのプリコミット・ハンドラの設定プリコミット・ハンドラでは、適用プロセスによってデキューされたすべてのコミット・ディレクティブが処理されます。適用プロセスのプリコミット・ハンドラを設定するには、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プロシージャを使用して適用プロセスを作成する際に、プリコミット・ハンドラを指定できます。

適用プロセスのプリコミット・ハンドラの削除適用プロセスのプリコミット・ハンドラの削除適用プロセスのプリコミット・ハンドラの削除適用プロセスのプリコミット・ハンドラの削除適用プロセスのプリコミット・ハンドラを削除するには、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;/

適用プロセスによるイベントのエンキューの指定適用プロセスによるイベントのエンキューの指定適用プロセスによるイベントのエンキューの指定適用プロセスによるイベントのエンキューの指定この項では、ポジティブ・ルール・セットの指定のルールを使用する適用プロセスで、ルールを満たすイベントがエンキューされる宛先キューを設定する手順について説明します。また、宛先キューの設定を削除する手順についても説明します。

参照参照参照参照 : 14-43 ページの「適用時に宛先キューを指定するルールの表示」


適用プロセスによるイベントのエンキューの指定

ルールを満たすイベントの宛先キューの設定ルールを満たすイベントの宛先キューの設定ルールを満たすイベントの宛先キューの設定ルールを満たすイベントの宛先キューの設定特定のルールを満たすイベントの宛先キューを設定するには、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に設定して作成された適用プロセスによる適用、または他のキューへの伝播を実行できます。

注意注意注意注意 : 指定したルールは、適用プロセスのポジティブ・ルール・セットに含まれている必要があります。ルールが適用プロセスのネガティブ・ルール・セットに含まれている場合、適用プロセスはイベントを宛先キューにエンキューしません。


� 10-3 ページの「保護キューでのユーザー操作の有効化」

� 指定したルールのアクション・コンテキストをSET_ENQUEUE_DESTINATIONプロシージャで変更する方法の詳細は、6-46 ページの「適用時のイベントのエンキューの宛先」を参照してください。


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

ルールの宛先キュー設定の削除ルールの宛先キュー設定の削除ルールの宛先キュー設定の削除ルールの宛先キュー設定の削除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;/

参照参照参照参照 : 14-43 ページの「適用時に実行の回避を指定するルールの表示」


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

このプロシージャは、指定したルールのアクション・コンテキストを変更して、実行ディレクティブを指定します。ポジティブ・ルール・セットに departments8ルールが含まれるローカル・データベースのすべての適用プロセスで、departments8ルールを満たすイベントは実行されません。イベントが LCR の場合、適用プロセスでは、LCR の変更が、関連するデータベース・オブジェクトに対して適用されません。また、適用プロセスでは、このルールを満たすイベントは適用ハンドラに送信されません。

ルールを満たすイベントの実行の指定ルールを満たすイベントの実行の指定ルールを満たすイベントの実行の指定ルールを満たすイベントの実行の指定DBMS_APPLY_ADMパッケージの SET_EXECUTEプロシージャを使用して、適用プロセスが、特定のルールを満たすイベントを実行するように指定できます。具体的には、このプロシージャで、ルールの executeパラメータを trueに設定します。デフォルトでは、イベントが適用プロセスのネガティブ・ルール・セットのルールを満たしていないことを想定して、適用プロセスのポジティブ・ルール・セットのルールを満たすイベントが各適用プロセスで実行されます。したがって、ルールの executeパラメータが以前 falseに設定されていた場合にのみ、ルールのこのパラメータを trueに設定する必要があります。


� 適用プロセスが実行ディレクティブに従うには、指定したルールが適用プロセスのポジティブ・ルール・セットに含まれている必要があります。ルールが適用プロセスのネガティブ・ルール・セットに含まれている場合、適用プロセスはルールの実行ディレクティブを無視します。

� 特定のルールを満たすイベントを、実行せずに宛先キューにエンキューする必要がある場合は、SET_EXECUTEプロシージャとSET_ENQUEUE_DESTINATIONプロシージャを併用できます。SET_ENQUEUE_DESTINATIONプロシージャを使用してイベントをエンキューすると、そのイベントは宛先キューのユーザー・エンキュー・イベントになります。したがって、そのイベントに対して、手動のデキュー、適用プロセスによる適用、または他のキューへの伝播を実行できます。


� 指定したルールのアクション・コンテキストを SET_EXECUTEプロシージャで変更する方法の詳細は、6-46 ページの「適用時のイベントの実行ディレクティブ」を参照してください。



エラー・ハンドラの管理

たとえば、適用プロセスがルール departments8を満たすイベントを実行するように指定するには、次のプロシージャを実行します。

BEGIN DBMS_APPLY_ADM.SET_EXECUTE( rule_name => 'departments8', execute => true);END;/

ポジティブ・ルール・セットに departments8ルールが含まれるローカル・データベースのすべての適用プロセスで、departments8ルールを満たすイベントが実行されます。イベントが LCR の場合、適用プロセスでは、LCR の変更が、関連するデータベース・オブジェクトに対して適用されます。また、適用プロセスでは、このルールを満たすイベントは適用ハンドラに送信されます（適用プロセスをそのように構成している場合）。

エラー・ハンドラの管理エラー・ハンドラの管理エラー・ハンドラの管理エラー・ハンドラの管理この項では、エラー・ハンドラを作成、設定および削除する手順について説明します。

エラー・ハンドラの作成エラー・ハンドラの作成エラー・ハンドラの作成エラー・ハンドラの作成エラー・ハンドラを作成するには、DBMS_APPLY_ADMパッケージの SET_DML_HANDLERプロシージャを実行して、error_handlerパラメータを trueに設定します。

エラー・ハンドラには、次のシグネチャが必要です。

PROCEDURE user_procedure ( message IN SYS.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 文字以上のユーザー定義配列を指定する必要があります。

参照参照参照参照 : 4-3 ページの「適用プロセスによるイベント処理」

注意注意注意注意 : エラー・ハンドラについては、SET_DML_HANDLERで指定されたユーザー・プロシージャに関する特定の制限に従う必要があります。これらの制限の詳細は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。



エラー・ハンドラの実行結果は、次のいずれかになります。

� エラー・ハンドラによってエラーが正常に解決され、該当する場合は行 LCR が適用され、制御が適用プロセスに戻されます。

� エラー・ハンドラがエラーの解決に失敗し、エラーが発生します。エラーが発生すると、トランザクションがロールバックされ、エラー・キューに置かれます。

DML 操作を再試行する必要がある場合は、エラー・ハンドラ・プロシージャで LCR 用のEXECUTEメンバー・プロシージャを実行します。

次の例では、hr.regions表の主キー違反を解決するエラー・ハンドラregions_pk_errorを作成します。接続先データベースで、ユーザーが hr.regions表に行を挿入し、リモート・ソース・データベースの取得プロセスによって発生したhr.regions表に対する変更が、適用プロセスによって適用されるとします。この環境では、接続先データベースのユーザーが、ソース・データベースから適用される挿入行 LCRと同じ主キー値を持つ行を挿入すると、エラーが発生する可能性があります。

この例では、hr.regions表の主キー違反エラーごとに次の情報を記録するために、strmadminスキーマに表 errorlogを作成します。

� エラー発生時のタイムスタンプ。

� エラーが発生した適用プロセスの名前。

� エラーの原因となったユーザー（送信者）。これは、取得された LCR の場合は取得プロセス名、ユーザーがエンキューした LCR の場合は 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. hrユーザーとして接続して次の文を実行し、エラー・ハンドラで新規の主キー値を割り当てるために使用される順序を作成します。

CONNECT hr/hr

CREATE SEQUENCE hr.reg_exception_s START WITH 9000;

この例では、接続先データベースのユーザーは region_idが 9000以上の行をhr.regions表に挿入しないと仮定します。

2. Streams 管理者に、この順序に対する ALL権限を付与します。

GRANT ALL ON reg_exception_s TO strmadmin;

3. Streams 管理者として接続して次の文を実行し、errorlog表を作成します。

CONNECT strmadmin/strmadminpw

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);

4. 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 SYS.ANYDATA, error_stack_depth IN NUMBER,



error_numbers IN DBMS_UTILITY.NUMBER_ARRAY, error_messages IN EMSG_ARRAY);END errors_pkg ;/

5. regions_pk_errorプロシージャを含むパッケージ本体を作成します。

CREATE OR REPLACE PACKAGE BODY errors_pkg AS PROCEDURE regions_pk_error ( message IN SYS.ANYDATA, error_stack_depth IN NUMBER, error_numbers IN DBMS_UTILITY.NUMBER_ARRAY, error_messages IN EMSG_ARRAY ) IS reg_id NUMBER; ad SYS.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 := Sys.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;/

エラー・ハンドラの設定エラー・ハンドラの設定エラー・ハンドラの設定エラー・ハンドラの設定エラー・ハンドラでは、適用プロセスによってデキューされた、特定の表に対する特定の操作を含む行 LCR によって発生するエラーが処理されます。同じ表に複数のエラー・ハンドラを指定して、その表に対する異なる操作によって発生するエラーを処理できます。エラー・ハンドラを特定の適用プロセスに設定するか、指定の操作を指定の表に適用するすべての適用プロセスで使用される汎用エラー・ハンドラとして設定することができます。


� 変更があった行に対する以降の変更が正常に適用されるように、2 つのデータベースでできるだけ迅速に行を収束させる必要があります。つまり、ソース・データベースと接続先データベースで、行のregion_idを一致させる必要があります。この手動変更がデータベースで再取得されないようにする必要がある場合は、DBMS_STREAMSパッケージの SET_TAGプロシージャを使用して、値の変更が取得されないようにするセッション用のタグを設定します。

� この例のエラー・ハンドラでは、LCR に対して GET_VALUESメンバー・ファンクションと SET_VALUESメンバー・プロシージャを使用しています。ただし、LCR 内で変更する値が 1 つのみの場合は、GET_VALUEメンバー・ファンクションと SET_VALUEメンバー・プロシージャを使用する方が簡単で効率的な場合があります。

参照参照参照参照 : 現行セッションで生成されるタグ値の設定の詳細は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。



エラー・ハンドラは、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;/

エラー・ハンドラの設定解除エラー・ハンドラの設定解除エラー・ハンドラの設定解除エラー・ハンドラの設定解除エラー・ハンドラの設定を解除するには、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;/


適用エラーの管理

適用エラーの管理適用エラーの管理適用エラーの管理適用エラーの管理この項では、適用エラーを再試行する手順と削除する手順について説明します。

適用エラー・トランザクションの再試行適用エラー・トランザクションの再試行適用エラー・トランザクションの再試行適用エラー・トランザクションの再試行ここでは、特定のエラー・トランザクションを再試行する方法と、適用プロセスのすべてのエラー・トランザクションを再試行する方法について説明します。適用エラー・トランザクションを再試行する前に、データベース・オブジェクトに DML または DDL 変更を加えて、1 つ以上の適用エラーの原因となった条件を訂正する必要がある場合があります。また、同じデータベース・オブジェクトに対する変更を取得するように、1 つ以上の取得プロセスを構成できます。ただし、場合によっては変更を取得しないようにすることもできます。この場合は、変更を加えるセッションのタグを取得されない値に設定できます。

特定の適用エラー・トランザクションの再試行特定の適用エラー・トランザクションの再試行特定の適用エラー・トランザクションの再試行特定の適用エラー・トランザクションの再試行適用エラーの原因となった条件を訂正した後に、DBMS_APPLY_ADMパッケージのEXECUTE_ERRORプロシージャを実行してトランザクションを再試行できます。たとえば、トランザクション識別子 5.4.312を持つトランザクションを再試行するには、次のプロシージャを実行します。

BEGIN DBMS_APPLY_ADM.EXECUTE_ERROR( local_transaction_id => '5.4.312', execute_as_user => false);END;/

execute_as_userが trueの場合、適用プロセスでは現行ユーザーのセキュリティ・コンテキスト内でトランザクションが再実行されます。execute_as_userが falseの場合、

注意注意注意注意 : error_handlerパラメータを指定する必要はありません。


� 4-19 ページの「エラー・キュー」



� 適用エラーに考えられる原因については、『Oracle Streams レプリケーション管理者ガイド』を参照してください。

参照参照参照参照 : 現行セッションで生成されるタグ値の設定の詳細は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。



適用プロセスではトランザクションの元の受信者のセキュリティ・コンテキスト内でトランザクションが再実行されます。元の受信者とは、エラーの発生時にトランザクションを処理していたユーザーです。

どちらの場合も、トランザクションを実行するユーザーには、適用オブジェクトに対するDML 変更および DDL 変更を実行するための権限と、任意の適用ハンドラを実行するための権限が必要です。また、ユーザーには適用プロセスで使用されるキューに対するデキュー権限も必要です。

適用プロセスのすべてのエラー・トランザクションの再試行適用プロセスのすべてのエラー・トランザクションの再試行適用プロセスのすべてのエラー・トランザクションの再試行適用プロセスのすべてのエラー・トランザクションの再試行適用プロセスについて、すべての適用エラーの原因となった条件を訂正した後に、DBMS_APPLY_ADMパッケージの EXECUTE_ALL_ERRORSプロシージャを実行して、すべてのエラー・トランザクションを再試行できます。たとえば、適用プロセス strm01_applyのすべてのエラー・トランザクションを再試行するには、次のプロシージャを実行します。

BEGIN DBMS_APPLY_ADM.EXECUTE_ALL_ERRORS( apply_name => 'strm01_apply', execute_as_user => false);END;/

適用エラー・トランザクションの削除適用エラー・トランザクションの削除適用エラー・トランザクションの削除適用エラー・トランザクションの削除ここでは、特定のエラー・トランザクションを削除する方法と、適用プロセスのすべてのエラー・トランザクションを削除する方法について説明します。

特定の適用エラー・トランザクションの削除特定の適用エラー・トランザクションの削除特定の適用エラー・トランザクションの削除特定の適用エラー・トランザクションの削除エラー・トランザクションを適用しない場合は、DBMS_APPLY_ADMパッケージのDELETE_ERRORプロシージャを使用して、そのトランザクションをエラー・キューから削除できます。たとえば、トランザクション識別子 5.4.312を持つトランザクションを削除するには、次のプロシージャを実行します。

EXEC DBMS_APPLY_ADM.DELETE_ERROR(local_transaction_id => '5.4.312');

注意注意注意注意 : apply_nameパラメータに NULLを指定した場合に、複数の適用プロセスが存在すると、すべての適用プロセスのすべての適用エラーが再試行されます。



適用プロセスのすべてのエラー・トランザクションの削除適用プロセスのすべてのエラー・トランザクションの削除適用プロセスのすべてのエラー・トランザクションの削除適用プロセスのすべてのエラー・トランザクションの削除すべてのエラー・トランザクションを適用しない場合は、DBMS_APPLY_ADMパッケージのDELETE_ALL_ERRORSプロシージャを実行して、すべてのエラー・トランザクションを削除できます。たとえば、適用プロセス strm01_applyのすべてのエラー・トランザクションを削除するには、次のプロシージャを実行します。

EXEC DBMS_APPLY_ADM.DELETE_ALL_ERRORS(apply_name => 'strm01_apply');

注意注意注意注意 : apply_nameパラメータに NULLを指定した場合に、複数の適用プロセスが存在すると、すべての適用プロセスのすべての適用エラーが削除されます。




ルールおよびルールベースの

12
ルールおよびルールベースの変換の管理ルールおよびルールベースの変換の管理ルールおよびルールベースの変換の管理ルールおよびルールベースの変換の管理
Streams 環境では、ルールを使用して、取得プロセス、伝播、適用プロセスおよびメッセージ・クライアントの動作を制御します。また、Streams 環境では、ルールベースの変換を使用して、ルールが TRUEに評価される場合に発生するイベントが変更されます。変換は、イベントの取得中、伝播中、適用中またはデキュー中に実行できます。また、ルール・エンジンのクライアントであるカスタム・アプリケーションも作成できます。この章では、ルール・セット、ルールおよびルールベースの変換の管理手順について説明します。


� ルール・セットとルールの管理

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

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


注意注意注意注意 : この章では、評価コンテキストの作成例およびDBMS_RULE.EVALUATEプロシージャを使用したイベントの評価例は説明していません。これらの例については、第 17 章「ルールベースのアプリケーションの例」を参照してください。






変換の管理 12-1

ルール・セットとルールの管理

ルール・セットとルールの管理ルール・セットとルールの管理ルール・セットとルールの管理ルール・セットとルールの管理ルールまたはルール・セットの変更は、そのルールまたはルール・セットを使用するStreams の取得プロセス、伝播および適用プロセスを停止せずに行うことができます。Streams はコミットされた直後の変更を検出します。新規バージョンのルールまたはルール・セットが使用されるイベントについて厳密に制御する必要がある場合は、関連する取得プロセスおよび適用プロセスを停止し、関連する伝播ジョブを無効化したうえで、ルールまたはルール・セットを変更し、停止したプロセスおよび伝播ジョブを再起動する必要があります。


� ルール・セットの作成

� ルールの作成

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

� ルールの変更

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

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

� ルールの削除

� ルール・セットの削除

ルール・セットの作成ルール・セットの作成ルール・セットの作成ルール・セットの作成ここでは、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が作成されます。同じ名前と所有者を持つルール・セットは、存在できません。


� 9-24 ページの「取得プロセスの停止」

� 10-17 ページの「伝播ジョブの無効化」

� 11-9 ページの「適用プロセスの停止」



� ルール・セットが、SYS.STREAMS$_EVALUATION_CONTEXT評価コンテキストに関連付けられます。これは、Oracle が提供する Streams 用の評価コンテキストです。

また、DBMS_STREAMS_ADMパッケージの次のプロシージャを使用すると、Streams の取得プロセス、伝播、適用プロセスまたはメッセージ・クライアントにルール・セットが存在しない場合に自動的にルール・セットを作成できます。

� ADD_MESSAGE_PROPAGATION_RULE


� ADD_TABLE_PROPAGATION_RULES

� ADD_TABLE_RULES

� ADD_SUBSET_PROPAGATION_RULES


� ADD_SCHEMA_PROPAGATION_RULES


� ADD_GLOBAL_PROPAGATION_RULES


ADD_SUBSET_PROPAGATION_RULESおよび ADD_SUBSET_RULESを除き、前述のプロシージャは、Streams クライアントのポジティブ・ルール・セットまたはネガティブ・ルール・セットを作成できます。ADD_SUBSET_PROPAGATION_RULESおよび ADD_SUBSET_RULESは、Streams クライアントのポジティブ・ルール・セットのみを作成できます。

ルールの作成ルールの作成ルールの作成ルールの作成ここでは、DBMS_RULE_ADMパッケージの CREATE_RULEプロシージャを実行して、アクション・コンテキストを持たないルールを作成する例およびアクション・コンテキストを持つルールを作成する例について説明します。


� 9-4 ページの「DBMS_STREAMS_ADM を使用したローカルの取得プロセスの作成例」

� 10-8 ページの「DBMS_STREAMS_ADM を使用した伝播の作成例」

� 11-4 ページの「DBMS_STREAMS_ADM を使用した取得イベント用の適用プロセスの作成例」

ルールおよびルールベースの変換の管理 12-3


アクション・コンテキストを持たないルールの作成アクション・コンテキストを持たないルールの作成アクション・コンテキストを持たないルールの作成アクション・コンテキストを持たないルールの作成アクション・コンテキストを持たないルールを作成するには、次の例のように、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_TABLE_RULES







ADD_SUBSET_PROPAGATION_RULESおよび ADD_SUBSET_RULESを除き、前述のプロシージャは、Streams クライアントのポジティブ・ルール・セットまたはネガティブ・ルール・セットにルールを追加できます。ADD_SUBSET_PROPAGATION_RULESおよび



ADD_SUBSET_RULESは、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', SYS.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の名前 / 値ペアを持つアクション・コンテキストが作成されます。


� 9-4 ページの「DBMS_STREAMS_ADM を使用したローカルの取得プロセスの作成例」

� 10-8 ページの「DBMS_STREAMS_ADM を使用した伝播の作成例」

� 11-4 ページの「DBMS_STREAMS_ADM を使用した取得イベント用の適用プロセスの作成例」



ルール・セットへのルールの追加ルール・セットへのルールの追加ルール・セットへのルールの追加ルール・セットへのルールの追加ここでは、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パラメータをその評価コンテキストに設定できます。

ルールの変更ルールの変更ルールの変更ルールの変更DBMS_RULE_ADMパッケージの ALTER_RULEプロシージャを使用すると、既存のルールを変更できます。特に、このプロシージャを使用すると次のことができます。

� ルールの条件の変更

� ルールの評価コンテキストの変更

� ルールの評価コンテキストの削除

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

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

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

� ルールに関するコメントの変更

� ルールに関するコメントの削除

ここでは、これらの変更の例をいくつか示します。

参照参照参照参照 : アクション・コンテキストにこのような名前 / 値ペアを使用する例については、5-9 ページの「ルール・アクション・コンテキスト」を参照してください。



ルールの条件の変更ルールの条件の変更ルールの条件の変更ルールの条件の変更ALTER_RULEプロシージャの conditionパラメータを使用すると、既存のルールの条件を変更できます。たとえば、12-3 ページの「ルールの作成」で作成したルールの条件を変更する必要がある場合を考えます。既存の 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;/

ルールのアクション・コンテキストの名前ルールのアクション・コンテキストの名前ルールのアクション・コンテキストの名前ルールのアクション・コンテキストの名前 / 値ペアの変更値ペアの変更値ペアの変更値ペアの変更ルールのアクション・コンテキストの名前 / 値ペアを変更するには、初にルールのアクション・コンテキストから名前 / 値ペアを削除し、次にルールのアクション・コンテキストに異なる名前 / 値ペアを追加します。

この例では、rule_dep_10ルールについて名前 / 値ペアを変更します。そのために、初にこのルールのアクション・コンテキストから course_name名を持つ名前 / 値ペアを削除し、次に名前は同じ（course_name）で値は異なる名前 / 値ペアを追加します。この変更される名前 / 値ペアは、12-5 ページの「アクション・コンテキストを持つルールの作成」の例でルールに追加したものです。

アクション・コンテキストに、変更する名前 / 値ペアの他にも名前 / 値ペアが含まれている場合、アクション・コンテキストを変更するときには、他の名前 / 値ペアを変更または削除しないように注意してください。


� ルールの条件を変更すると、そのルールを含むすべてのルール・セットに影響します。

� ルールのアクション・コンテキストを保持しながらルールを変更するには、ALTER_RULEプロシージャの action_contextパラメータにNULLを指定します。NULLは、action_contextパラメータのデフォルト値です。



次の手順に従って、アクション・コンテキストの名前 / 値ペアを変更します。

1. 次の問合せを実行すると、ルールのアクション・コンテキスト内の名前 / 値ペアを表示できます。

COLUMN ACTION_CONTEXT_NAME HEADING 'Action Context Name' FORMAT A25COLUMN 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, SYS.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, SYS.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 A25COLUMN AC_VALUE_NUMBER HEADING 'Action Context|Number Value' FORMAT 9999COLUMN 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 ContextAction Context Name Number Value Text Value------------------------- -------------- -------------------------course_number 1088dist_list admin_list

ルールのアクション・コンテキストからの名前ルールのアクション・コンテキストからの名前ルールのアクション・コンテキストからの名前ルールのアクション・コンテキストからの名前 / 値ペアの削除値ペアの削除値ペアの削除値ペアの削除RE$NV_LIST型の REMOVE_PAIRメンバー・プロシージャを使用して、ルールのアクション・コンテキストから名前 / 値ペアを削除できます。他のユーザーが同時にアクション・コンテキストを変更中でないことを確認してください。

名前 / 値ペアを削除すると、ルールのアクション・コンテキストが変更されます。アクション・コンテキストに、削除する名前 / 値ペアの他にも名前 / 値ペアが含まれている場合、アクション・コンテキストを変更するときには、他の名前 / 値ペアを変更または削除しないように注意してください。

この例では、rule_dep_10ルールに次の名前 / 値ペアが含まれていることを想定しています。

参照参照参照参照 : アクション・コンテキストに同様の名前 / 値ペアを使用する例については、5-9 ページの「ルール・アクション・コンテキスト」を参照してください。

名前名前名前名前値値値値

course_number 1088

dist_list admin_list

参照参照参照参照 : 次の項の例を完了した場合、rule_dep_10ルールにこれらの名前 / 値ペアが追加されています。

� 12-5 ページの「アクション・コンテキストを持つルールの作成」

� 12-7 ページの「ルールのアクション・コンテキストの名前 / 値ペアの変更」

� 12-9 ページの「ルールのアクション・コンテキストへの名前 / 値ペアの追加」



この例では、既存のアクション・コンテキストを選択して変数に挿入し、名前が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 A25COLUMN AC_VALUE_NUMBER HEADING 'Action Context|Number Value' FORMAT 9999COLUMN 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 ContextAction Context Name Number Value Text Value------------------------- -------------- -------------------------course_number 1108



システム作成ルールの変更システム作成ルールの変更システム作成ルールの変更システム作成ルールの変更システム作成ルールとは、DBMS_STREAMS_ADMパッケージのプロシージャを実行して作成するルールです。システム作成ルールにルールベースの変換を使用する必要がある場合は、DBMS_STREAMS_ADMパッケージの SET_RULE_TRANSFORM_FUNCTIONプロシージャを使用できます。

また、DBMS_STREAMS_ADMパッケージでは必要なルール条件を持つルールを作成できない場合は、次の一般的な手順に従って、システム作成ルールに基づく条件を持つ新規ルールを作成できます。

1. システム作成ルールのルール条件をコピーします。DBA_STREAMS_RULESデータ・ディクショナリ・ビューを問い合せると、システム作成ルールのルール条件を表示できます。

2. 条件を変更します。

3. 変更した条件を持つ新規ルールを作成します。

4. 新規ルールを Streams の取得プロセス、伝播、適用プロセスまたはメッセージ・クライアントのルール・セットに追加します。

5. 元のルールが不要になった場合は、DBMS_STREAMS_ADMパッケージの REMOVE_RULEプロシージャを使用して削除します。

ルール・セットからのルールの削除ルール・セットからのルールの削除ルール・セットからのルールの削除ルール・セットからのルールの削除ここでは、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プロシージャの実行後も、ルールはデータベース内に存在し、他のルール・セットに含まれていた場合は、そのルール・セットに残ります。



� Streams に関連するデータ・ディクショナリ・ビューの詳細は、第 14章「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に設定されている場合は、ルールがデータベースから削除され、それを含むルール・セットから自動的に削除されます。

ルール・セットの削除ルール・セットの削除ルール・セットの削除ルール・セットの削除ここでは、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 つ以上のルール・セットにも含まれている場合、そのルールは削除されません。


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

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


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

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

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

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

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

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ユーザーはこのシステム権限を他のユーザーに付与できます。


� 5-15 ページの「ルールに関連するデータベース・オブジェクトと権限」

� 『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』の、DBMS_RULE_ADMパッケージの GRANT_SYSTEM_PRIVILEGEおよびGRANT_OBJECT_PRIVILEGEプロシージャに関する説明を参照してください。


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

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

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;/

ルールベースの変換の管理ルールベースの変換の管理ルールベースの変換の管理ルールベースの変換の管理Streams では、ルールベースの変換は、ポジティブ・ルール・セットのルールが TRUEに評価される場合に発生するイベントの変更です。DBMS_STREAMS_ADMパッケージのSET_RULE_TRANSFORM_FUNCTIONプロシージャを使用すると、ルールに対してルールベースの変換を追加、変更または削除できます。このプロシージャは、ルールのアクション・コンテキストを変更して、ルールベースの変換を指定します。


� ルールベースの変換の作成

� ルールベースの変換の変更

� ルールベースの変換の削除

注意注意注意注意 : LCR の LONG、LONG RAWまたは LOB 列のデータは変更しないでください。ルールベースの変換ファンクション、DML ハンドラおよびエラー・ハンドラが含まれるためです。



ルールベースの変換の作成ルールベースの変換の作成ルールベースの変換の作成ルールベースの変換の作成ルールベースの変換に含まれるファンクションには、次のシグネチャが必要です。

FUNCTION user_function ( parameter_name IN SYS.AnyData)RETURN SYS.AnyData;

user_functionはファンクション名で、parameter_nameはファンクションに渡されるパラメータの名前です。ファンクションに渡されるパラメータはイベントを SYS.AnyDataにカプセル化したもので、ファンクションではそれを戻す必要があります。

次の手順では、ルールベースの変換を作成する一般的な手順について説明します。

1. 変換を実行する PL/SQL ファンクションを作成します。


� ルールのアクション・コンテキストには、自動ロック・メカニズムはありません。したがって、アクション・コンテキストが同時に複数のセッションで更新されないことを確認してください。

� DDL LCR に対してルールベースの変換を実行する場合は、他の変更と一致するように DDL LCR 内で DDL テキストの変更が必要になることがあります。たとえば、ルールベースの変換によって DDL LCR内の表名が変更になる場合は、DDL テキスト内の表名も同様に変更する必要があります。

� ルールがポジティブ・ルール・セットに含まれる場合にのみ、ルールに指定した変換が実行されます。ルールが取得プロセス、伝播、適用プロセスまたはメッセージ・クライアントのネガティブ・ルール・セットに含まれる場合、これらの Streams クライアントではルールベースの変換が無視されます。


注意注意注意注意 : 変換ファンクションが決定的であることを確認します。決定的なファンクションは、入力された引数値の特定のセットに対して、常に同じ値を戻します。また、変換ファンクションで例外が呼び出されないことを確認してください。例外が呼び出されると、取得プロセス、伝播または適用プロセスが無効化される場合があり、それらを進行させるために変換ファンクションの訂正が必要になります。メッセージ・クライアントのルールベースの変換で例外が呼び出されると、メッセージ・クライアントがイベントをデキューできない場合があります。



次の例では、hrスキーマ内に、departments表の department_name列の値をExecutiveから Managementに変更するファンクションexecutive_to_managementが作成されます。会社の事業所の 1 つがこの部門に異なる名称を使用している場合に、このような変換が必要になることがあります。

CONNECT hr/hr

CREATE OR REPLACE FUNCTION hr.executive_to_management(in_any IN SYS.AnyData) RETURN SYS.AnyDataIS lcr SYS.LCR$_ROW_RECORD; rc NUMBER; ob_owner VARCHAR2(30); ob_name VARCHAR2(30); dep_value_anydata SYS.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', SYS.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', SYS.ANYDATA.CONVERTVARCHAR2('Management'));



END IF; END IF; RETURN SYS.ANYDATA.CONVERTOBJECT(lcr); END IF; END IF;RETURN in_any;END;/

2. Streams 管理者に hr.executive_to_managementファンクションの EXECUTE権限を付与します。

GRANT EXECUTE ON hr.executive_to_management TO strmadmin;

3. hr.departments表の DML 操作についてサブセット・ルールを作成します。このサブセット・ルールでは、手順 1 で作成した変換を使用します。

ルールベースの変換を使用する場合、サブセット・ルールは不要です。この例では、複数の名前 / 値ペアを持つアクション・コンテキストの具体例を示すために、サブセット・ルールを使用しています。この例では、データベース dbs1.netに適用プロセスのサブセット・ルールが作成されます。これらのルールが TRUEと評価されるのは、LCRに hr.departments表のうち location_idが 1700の 1 行に対する DML 変更が含まれている場合です。この例では、SYS.AnyDataキュー strm01_queueがデータベースに存在することを想定しています。

これらのルールを作成するには、Streams 管理者として接続して次の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 => 'strm01_queue',

include_tagged_lcr => false, source_database => 'dbs1.net');END;/



4. 次の問合せを実行して、システム作成ルールの名前を判断します。

SELECT RULE_NAME, SUBSETTING_OPERATION FROM DBA_STREAMS_RULES WHERE OBJECT_NAME='DEPARTMENTS' AND DML_CONDITION='location_id=1700';


RULE_NAME SUBSET------------------------------ ------DEPARTMENTS5 INSERTDEPARTMENTS6 UPDATEDEPARTMENTS7 DELETE

これらはサブセット・ルールであるため、そのうちの 2 つには内部変換を実行する非NULLのアクション・コンテキストが含まれています。

� サブセット化条件 INSERTを持つルールには、更新によって location_id列の値が他の値から 1700に変更される場合に、更新を挿入に変換する内部変換が含まれています。内部変換は、挿入には影響しません。

� サブセット化条件 DELETEを持つルールには、更新によって location_id列の値が 1700から他の値に変更される場合に、更新を削除に変換する内部変換が含まれています。内部変換は、削除には影響しません。


� 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プロシージャは、適用プロセスのポジティブ・ルール・セットにサブセット・ルールを追加します。

注意注意注意注意 : この情報を取得するには、ADD_SUBSET_RULESを実行するときに OUTパラメータを使用する方法もあります。



この例では、次の問合せを実行すると、ルール DEPARTMENTS5および DEPARTMENTS7が非 NULLのアクション・コンテキストを持ち、ルール DEPARTMENTS6が NULLのアクション・コンテキストを持つことを確認できます。

COLUMN RULE_NAME HEADING 'Rule Name' FORMAT A13COLUMN ACTION_CONTEXT_NAME HEADING 'Action Context Name' FORMAT A27COLUMN ACTION_CONTEXT_VALUE HEADING 'Action Context Value' FORMAT A26

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 INSERTDEPARTMENTS7 STREAMS$_ROW_SUBSET DELETE

DEPARTMENTS6ルールは、アクション・コンテキストが NULLであるため出力には表示されません。

5. 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 ファンクションの名前を含む SYS.AnyDataインスタンスを値として指定する各ルールのアクション・コンテキストに、名前 / 値ペアが追加されます。この場合、変換ファンクションは hr.executive_to_managementです。



これらのルールのアクション・コンテキスト内の名前 / 値ペアを表示する問合せを実行すると、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 INSERTDEPARTMENTS5 STREAMS$_TRANSFORM_FUNCTION hr.executive_to_managementDEPARTMENTS6 STREAMS$_TRANSFORM_FUNCTION hr.executive_to_managementDEPARTMENTS7 STREAMS$_ROW_SUBSET DELETEDEPARTMENTS7 STREAMS$_TRANSFORM_FUNCTION hr.executive_to_management

また、DBA_STREAMS_TRANSFORM_FUNCTIONデータ・ディクショナリ・ビューを使用して、変換ファンクションを表示できます。

ルールベースの変換の変更ルールベースの変換の変更ルールベースの変換の変更ルールベースの変換の変更ルールベースの変換を変更するには、変換ファンクションを編集するか、またはSET_RULE_TRANSFORM_FUNCTIONプロシージャを実行して異なる変換ファンクションを指定します。この例では、SET_RULE_TRANSFORM_FUNCTIONプロシージャを実行して異なる変換ファンクションを指定します。SET_RULE_TRANSFORM_FUNCTIONプロシージャは、指定したルールのアクション・コンテキストを変更して、異なる変換ファンクションが実行されるようにします。変換ファンクション自体を編集する場合、このプロシージャを実行する必要はありません。

この例では、変換ファンクションを hr.execute_to_managementからhr.executive_to_leadに変更して、ルール DEPARTMENTS5のルールベースの変換を変

注意注意注意注意 : SET_RULE_TRANSFORM_FUNCTIONでは、指定した変換ファンクションが存在するかどうかは検証されません。そのファンクションが存在しない場合、Streams のプロセスまたはジョブで変換ファンクションの起動が試行されるときにエラーが発生します。

参照参照参照参照 : この例に使用したルールのタイプの詳細は、『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。



更します。このルールベースの変換は、12-17 ページの「ルールベースの変換の作成」の例で DEPARTMENTS5ルールに追加したものです。

Streams の場合、サブセット・ルールではアクション・コンテキスト内の名前 / 値ペアを使用して、特定の状況で UPDATE操作を INSERTおよび DELETE操作に変換する内部変換が実行されます。このような変換は、行の移行と呼ばれます。SET_RULE_TRANSFORM_FUNCTIONプロシージャでは、行の移行を実行する名前 / 値ペアが保持されます。

次の手順に従って、ルールベースの変換を変更します。

1. 次の問合せを実行すると、ルールのアクション・コンテキスト内のすべての名前 / 値ペアを表示できます。

COLUMN ACTION_CONTEXT_NAME HEADING 'Action Context Name' FORMAT A30COLUMN ACTION_CONTEXT_VALUE HEADING 'Action Context Value' FORMAT A26

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 INSERTSTREAMS$_TRANSFORM_FUNCTION hr.executive_to_management

2. SET_RULE_TRANSFORM_FUNCTIONプロシージャを実行して、変換ファンクションをexecutive_to_leadに設定します。この例では、新規の変換ファンクションがhr.executive_to_leadで、strmadminユーザーにはその EXECUTE権限が付与されていると想定しています。

次のプロシージャを実行して、ルール DEPARTMENTS5のルールベースの変換をhr.executive_to_leadに設定します。

BEGIN DBMS_STREAMS_ADM.SET_RULE_TRANSFORM_FUNCTION( rule_name => 'departments5', transform_function => 'hr.executive_to_lead');END;/

参照参照参照参照 : 行の移行の詳細は、6-24 ページの「行の移行とサブセット・ルール」を参照してください。



変換ファンクションが正しく変更されたかどうかを確認するには、手順 1 の問合せを再実行します。3 つのサブセット・ルールの一貫性を保つために、DEPARTMENTS6およびDEPARTMENTS7ルールのアクション・コンテキストも同様に変更する必要があります。

ルールベースの変換の削除ルールベースの変換の削除ルールベースの変換の削除ルールベースの変換の削除ルールベースの変換をルールから削除するには、SET_RULE_TRANSFORM_FUNCTIONプロシージャを実行して、変換ファンクションに NULLを指定します。NULLを指定すると、ルールのアクション・コンテキストでルールベースの変換を指定する名前 / 値ペアが削除されます。この例では、ルール DEPARTMENTS5からルールベースの変換を削除します。このルールベースの変換は、12-17 ページの「ルールベースの変換の作成」の例でDEPARTMENTS5ルールに追加したものです。

Streams の場合、サブセット・ルールではアクション・コンテキスト内の名前 / 値ペアを使用して、特定の状況で UPDATE操作を INSERTおよび DELETE操作に変換する内部変換が実行されます。このような変換は、行の移行と呼ばれます。SET_RULE_TRANSFORM_FUNCTIONプロシージャでは、行の移行を実行する名前 / 値ペアが保持されます。

次のプロシージャを実行して、ルール DEPARTMENTS5からルールベースの変換を削除します。

BEGIN DBMS_STREAMS_ADM.SET_RULE_TRANSFORM_FUNCTION( rule_name => 'departments5', transform_function => NULL);END;/

変換ファンクションが削除されたかどうかを確認するには、12-23 ページの手順 1 の問合せを実行します。3 つのサブセット・ルールの一貫性を保つために、DEPARTMENTS6およびDEPARTMENTS7ルールのアクション・コンテキストも同様に変更する必要があります。

注意注意注意注意 : SET_RULE_TRANSFORM_FUNCTIONでは、指定した変換ファンクションが存在するかどうかは検証されません。そのファンクションが存在しない場合、Streams のプロセスまたはジョブで変換ファンクションの起動が試行されるときにエラーが発生します。




その他の Stream

13
その他のその他のその他のその他の Streams 管理タスク管理タスク管理タスク管理タスク
この章では、Streams 環境で全データベースのエクスポート / インポートを実行する手順について説明します。また、Streams 構成を削除する手順について説明します。


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

� Streams 構成の削除



s 管理タスク 13-1

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

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

この項では、1 つ以上の Streams 取得プロセス、伝播または適用プロセスが動作するデータベースで、全データベースのエクスポート / インポートを実行する方法について説明します。ここでは、インポート・データベースおよびエクスポート・データベースが異なるコンピュータ上で動作しており、エクスポート・データベースがインポート・データベースで置き換えられる全データベースのエクスポート / インポートに関して説明しています。インポート・データベースのグローバル名とエクスポート・データベースのグローバル名は一致する必要があります。ここに示す手順では、両方のデータベースがすでに存在していると想定しています。この項で説明するエクスポート / インポートは、Data Pump Export/Importユーティリティまたはオリジナルのエクスポート / インポート・ユーティリティを使用して実行できます。

次の手順に従って、Streams を使用したデータベースで全データベースのエクスポート / インポートを実行します。

1. エクスポート・データベースに、他のデータベースからの伝播に関する宛先キューが含まれる場合、エクスポート・データベースにイベントを伝播させる各伝播ジョブを無効化します。DBMS_AQADMパッケージの DISABLE_PROPAGATION_SCHEDULEプロシージャを使用すると、伝播ジョブを無効化できます。

2. 手順 1 で無効化した伝播ジョブで使用されていたデータベース・リンクが、インポート・データベースが動作するコンピュータを指し示すように、ネットワーク構成に必要な変更を加えます。

この手順を実行するには、これらの伝播ジョブで使用されていたデータベース・リンクを再作成するか、またはソース・キューが含まれるデータベースで Oracle ネットワーキング・ファイルを変更する必要がある場合があります。

注意注意注意注意 : 既存の Streams 環境にデータベースを追加する場合、この項の指示には従わないでください。かわりに、『Oracle Streams レプリケーション管理者ガイド』を参照してください。


� Streams に関連するエクスポート / インポートのパラメータの詳細は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。

� 全データベースのエクスポート / インポートを実行する方法の詳細は、『Oracle Database ユーティリティ』を参照してください。



3. エクスポート・データベースに対するデータ操作言語（DML）およびデータ定義言語（DDL）変更を中止するようすべてのユーザーに通知し、これらの変更が中止されるまで待機します。

4. エクスポート・データベースの現行のシステム変更番号（SCN）をメモします。DBMS_FLASHBACKパッケージの GET_SYSTEM_CHANGE_NUMBERファンクションを使用して、現行の SCN を決定できます。次に例を示します。

SET SERVEROUTPUT ON SIZE 1000000DECLARE current_scn NUMBER;BEGIN current_scn:= DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER; DBMS_OUTPUT.PUT_LINE('Current SCN: ' || current_scn);END;/

この例では、戻される現行の SCN 値を 7000000とします。

この手順を実行した後は、エクスポート・データベースで実行中の取得プロセスを停止しないでください。手順 7c では、V$STREAMS_CAPTURE動的パフォーマンス・ビューを使用して、手順 3 の後にデータベースに対し DML または DDL 変更が加えられていないことを確認するよう指示しています。取得プロセスが停止および再起動された場合、このビューの取得プロセスに関する情報がリセットされます。

手順 7c のチェックを有効にするには、取得プロセスでこの情報がリセットされないことが必要です。取得プロセスの自動停止を防止するには、取得プロセスのmessage_limitおよび time_limitパラメータが infinite以外の値に設定されている場合、これらのパラメータを infinite に設定する必要があります。

5. ダウンストリーム取得プロセスによってエクスポート・データベースで発生した変更が取得されている場合は、手順 4 で決定した SCN を含むログ・ファイルがダウンストリーム・データベースに転送され、取得プロセス・セッションに追加済であることを確認します。この情報を決定する問合せについては、14-5 ページの「Streams の取得プロセスの監視」を参照してください。

6. エクスポート・データベースで適用プロセスが実行されておらず、ユーザー・エンキュー・イベントが伝播されていない場合、この時点で全データベースのエクスポートを開始します。必要な Streams メタデータがエクスポートされるよう、FULLエクスポート・パラメータが yに設定されていることを確認します。

エクスポート・データベースで 1 つ以上の適用プロセスが実行されているか、またはユーザー・エンキュー・イベントが伝播されている場合、エクスポートを開始せずに次の手順に進みます。

その他の Streams 管理タスク 13-3


7. エクスポート・データベースが任意の取得プロセスによって取得された変更のソース・データベースの場合、各取得プロセスに対して次の手順を実行します。

a. 取得プロセスによって、手順 4 で決定した SCN に対応する REDO レコードがスキャンされるまで待機します。取得プロセスで後にスキャンされた REDO レコードの SCN は、V$STREAMS_CAPTURE動的パフォーマンス・ビューのCAPTURE_MESSAGE_NUMBER列を問い合せることによって表示できます。次の手順に進む前に、CAPTURE_MESSAGE_NUMBERの値が、手順 4 で決定した SCN 以上であることを確認します。

b. 適用プロセスが、取得データベースからのすべての変更を接続先データベースに適用するまで、Streams 環境を監視します。たとえば、取得プロセスの名前がcapture、適用プロセスの名前が apply、接続先データベースのグローバル名がdest.net、手順 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 [email protected] reader, [email protected] 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列を問い合せて、環境の Streams クライアントが有効かどうかを確認します。14-26 ページの「伝播ジョブのスケジュールの表示」にある問合せを実行して、伝播の状態を確認できます。

Streams クライアントが無効な場合は、再起動します。Streams クライアントが再起動されない場合は、第 15 章「Streams 環境のトラブルシューティング」を参照して、環境に対するトラブルシューティングを実行します。

この問合せでは、取得データベースと接続先データベース間に、Streams 管理者にアクセスできるデータベース・リンクが存在すると想定しています。該当するデー



タベース・リンクが存在しない場合は、SCN 値を判別するために、取得データベースおよび接続先データベースで 2 つの問合せを個別に実行できます。

c. 各取得プロセスのエンキュー・メッセージ番号が、手順 4 で決定した SCN 以下であるかどうか検証します。各取得プロセスのエンキュー・メッセージ番号を表示するには、V$STREAMS_CAPTURE動的パフォーマンス・ビューのENQUEUE_MESSAGE_NUMBER列を問い合せます。

各取得プロセスのエンキュー・メッセージ番号が、手順 4 で決定した SCN 以下である場合、手順 9 に進みます。

ただし、いずれかの取得プロセスのエンキュー・メッセージ番号が手順 4 で決定した SCN を超えている場合、手順 4 で決定した SCN より後に 1 つ以上の DML または DDL 変更が加えられており、これらの変更は取得プロセスによって取得およびエンキューされています。この場合、13-2 ページの手順 1 から、この項のすべての手順を再実行します。

8. ダウンストリーム取得プロセスがエクスポート・データベースで発生した変更を取得した場合は、これらのダウンストリーム取得プロセスを削除します。ダウンストリーム取得プロセスは手順 14a で再作成します。

9. エクスポート・データベースに、ユーザー・エンキュー・イベントを伝播させている伝播ジョブが存在する場合、DBMS_AQADMパッケージのDISABLE_PROPAGATION_SCHEDULEプロシージャを使用して、これらの伝播ジョブを無効化します。

10. エクスポート・データベースで 1 つ以上の適用プロセスが実行されているか、またはユーザー・エンキュー・イベントが伝播されている場合、この時点で全データベースのエクスポートを開始します。必要な Streams メタデータがエクスポートされるよう、FULLエクスポート・パラメータが yに設定されていることを確認します。手順 6 ですでにエクスポートを開始した場合、手順 11 に進みます。

11. エクスポートが完了した後、インポート・データベースが動作しているコンピュータにエクスポート・ダンプ・ファイルを送信します。

12. 全データベースのインポートを実行します。必要な Streams メタデータがインポートされるように、STREAMS_CONFIGURATIONと FULLインポート・パラメータの両方が yに設定されていることを確認します。STREAMS_CONFIGURATIONインポート・パラメータのデフォルト設定は yです。また、インポート中は、インポート・データベースに対する DML または DDL 変更が行われないことを確認してください。

13. ダウンストリーム取得プロセスによってデータベースで発生した変更が取得されている場合は、ログ・ファイルがインポート・データベースからダウンストリーム・データベースに転送されるように、必要な変更を行います。手順については、9-6 ページの

注意注意注意注意 : この検証を有効にするため、手順 4 以降は各取得プロセスが途切れずに実行されている必要があります。



「ダウンストリーム取得のための REDO ログ・ファイルのコピーの準備」を参照してください。

14. ダウンストリーム取得プロセスを再作成します。

a. 必要に応じて、手順 8 で削除したダウンストリーム取得プロセスを再作成します。削除したこれらのダウンストリーム取得プロセスでは、エクスポート・データベースで発生した変更が取得されていました。インポート・データベースで発生した変更を取得するように、再作成したダウンストリーム取得プロセスを構成します。

b. 必要に応じて、エクスポート・データベースで実行していたダウンストリーム取得プロセスをインポート・データベースに再作成します。エクスポート・データベースに存在していたダウンストリーム取得プロセスはエクスポートされていません。

15. ローカル取得プロセスまたはダウンストリーム取得プロセスがデータベースで発生する変更を取得する場合、インスタンス化のために変更が取得されるデータベース・オブジェクトをインポート・データベースに用意します。データベース・オブジェクトをインスタンス化のために準備する方法は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。

16. ユーザーに対しインポート・データベースへのアクセスを許可し、エクスポート・データベースをシャットダウンします。

17. 手順 1 および 9 で無効化した伝播ジョブを有効化します。

18. 手順 4 で取得プロセスの message_limitまたは time_limitパラメータの値をリセットした場合、インポート・データベースでそのパラメータを元の設定にリセットします。

参照参照参照参照 : ダウンストリーム取得プロセスの作成方法は、9-2 ページの「取得プロセスの作成」を参照してください。


Streams 構成の削除

Streams 構成の削除構成の削除構成の削除構成の削除DBMS_STREAMS_ADMパッケージの REMOVE_STREAMS_CONFIGURATIONプロシージャを実行して、ローカル・データベースの Streams 構成を削除できます。

ローカル・データベースの Streams 構成を削除するには、次のプロシージャを実行します。

EXEC DBMS_STREAMS_ADM.REMOVE_STREAMS_CONFIGURATION();

注意注意注意注意 : このプロシージャを実行する場合は注意してください。データベースの Streams 構成全体を削除する必要がある場合にのみ、このプロシージャを実行してください。

参照参照参照参照 : REMOVE_STREAMS_CONFIGURATIONプロシージャで実行されるアクションの詳細は、『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。


Streams 構成の削除


Stream

14
Streams 環境の監視環境の監視環境の監視環境の監視
この章では、Streams に関連する静的データ・ディクショナリ・ビューと動的パフォーマンス・ビューについて説明します。これらのビューを使用して、Streams 環境を監視できます。また、この章には、Streams 環境の監視に使用できる問合せの例も記載されています。


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

� Streams の動的パフォーマンス・ビューの概要

� Streams 管理者およびその他の Streams ユーザーの監視

� Streams の取得プロセスの監視

� SYS.AnyData キューおよびメッセージの監視

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

� Streams の適用プロセスの監視

� ルールおよびルールベースの変換の監視

� Streams 環境での互換性の監視

� Statspack を使用した Streams のパフォーマンスの監視

注意注意注意注意 : Oracle Enterprise Manager コンソールの Streams ツールも、Streams 環境を監視するための優れた手段です。詳細は、Streams ツールのオンライン・ヘルプを参照してください。


� この章で説明するデータ・ディクショナリ・ビューの詳細は、『Oracle Database リファレンス』を参照してください。

� Streams レプリケーション環境の監視の詳細は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。

s 環境の監視 14-1

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

Streams の静的データ・ディクショナリ・ビューの概要の静的データ・ディクショナリ・ビューの概要の静的データ・ディクショナリ・ビューの概要の静的データ・ディクショナリ・ビューの概要次の表に、Streams の静的データ・ディクショナリ・ビューを示します。

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

ALL_ ビュービュービュービュー DBA_ ビュービュービュービュー USER_ ビュービュービュービュー

ALL_APPLY DBA_APPLY なし

ALL_APPLY_CONFLICT_COLUMNS DBA_APPLY_CONFLICT_COLUMNS なし

ALL_APPLY_DML_HANDLERS DBA_APPLY_DML_HANDLERS なし

ALL_APPLY_ENQUEUE DBA_APPLY_ENQUEUE なし

ALL_APPLY_ERROR DBA_APPLY_ERROR なし

ALL_APPLY_EXECUTE DBA_APPLY_EXECUTE なし

なし DBA_APPLY_INSTANTIATED_GLOBAL なし

なし DBA_APPLY_INSTANTIATED_OBJECTS なし

なし DBA_APPLY_INSTANTIATED_SCHEMAS なし

ALL_APPLY_KEY_COLUMNS DBA_APPLY_KEY_COLUMNS なし

ALL_APPLY_TABLE_COLUMNS DBA_APPLY_TABLE_COLUMNS なし

ALL_APPLY_PARAMETERS DBA_APPLY_PARAMETERS なし

ALL_APPLY_PROGRESS DBA_APPLY_PROGRESS なし

ALL_CAPTURE DBA_CAPTURE なし

ALL_CAPTURE_EXTRA_ATTRIBUTES DBA_CAPTURE_EXTRA_ATTRIBUTES なし

ALL_CAPTURE_PARAMETERS DBA_CAPTURE_PARAMETERS なし

ALL_CAPTURE_PREPARED_DATABASE DBA_CAPTURE_PREPARED_DATABASE なし

ALL_CAPTURE_PREPARED_SCHEMAS DBA_CAPTURE_PREPARED_SCHEMAS なし

ALL_CAPTURE_PREPARED_TABLES DBA_CAPTURE_PREPARED_TABLES なし

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_PROPAGATION DBA_PROPAGATION なし

なし DBA_REGISTERED_ARCHIVED_LOG なし

ALL_RULE_SET_RULES DBA_RULE_SET_RULES USER_RULE_SET_RULES

ALL_RULE_SETS DBA_RULE_SETS USER_RULE_SETS


Streams の動的パフォーマンス・ビューの概要

Streams の動的パフォーマンス・ビューの概要の動的パフォーマンス・ビューの概要の動的パフォーマンス・ビューの概要の動的パフォーマンス・ビューの概要次のリストに、Streams の動的パフォーマンス・ビューを示します。

� V$BUFFERED_QUEUES

� V$BUFFERED_PUBLISHERS

� V$BUFFERED_SUBSCRIBERS

� 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

ALL_RULES DBA_RULES USER_RULES

なし DBA_STREAMS_ADMINISTRATOR なし

ALL_STREAMS_GLOBAL_RULES DBA_STREAMS_GLOBAL_RULES なし

ALL_STREAMS_MESSAGE_CONSUMERS DBA_STREAMS_MESSAGE_CONSUMERS なし

ALL_STREAMS_MESSAGE_RULES DBA_STREAMS_MESSAGE_RULES なし

ALL_STREAMS_NEWLY_SUPPORTED DBA_STREAMS_NEWLY_SUPPORTED なし

ALL_STREAMS_RULES DBA_STREAMS_RULES

ALL_STREAMS_SCHEMA_RULES DBA_STREAMS_SCHEMA_RULES なし

ALL_STREAMS_TABLE_RULES DBA_STREAMS_TABLE_RULES なし

ALL_STREAMS_TRANSFORM_FUNCTION DBA_STREAMS_TRANSFORM_FUNCTION なし

ALL_STREAMS_UNSUPPORTED DBA_STREAMS_UNSUPPORTED なし

注意注意注意注意 : これらの動的パフォーマンス・ビューの経過時間の統計を収集するには、TIMED_STATISTICS初期化パラメータを trueに設定します。

表表表表 14-1 Streams の静的データ・ディクショナリ・ビュー（続き）の静的データ・ディクショナリ・ビュー（続き）の静的データ・ディクショナリ・ビュー（続き）の静的データ・ディクショナリ・ビュー（続き）

ALL_ ビュービュービュービュー DBA_ ビュービュービュービュー USER_ ビュービュービュービュー

Streams 環境の監視 14-3

Streams 管理者およびその他の Streams ユーザーの監視

Streams 管理者およびその他の管理者およびその他の管理者およびその他の管理者およびその他の Streams ユーザーの監視ユーザーの監視ユーザーの監視ユーザーの監視ここでは、Streams 管理者、およびリモート Streams 管理者からのアクセスを許可する他のユーザーをリスト表示する問合せについて説明します。

� ローカル Streams 管理者のリスト表示

� リモート Streams 管理者からのアクセスを許可するユーザーのリスト表示

ローカルローカルローカルローカル Streams 管理者のリスト表示管理者のリスト表示管理者のリスト表示管理者のリスト表示オプションでローカル Streams 管理者に権限を付与するには、DBMS_STREAMS_AUTHパッケージの GRANT_ADMIN_PRIVILEGEプロシージャを実行します。DBA_STREAMS_ADMINISTRATORデータ・ディクショナリ・ビューには、ユーザーに対してGRANT_ADMIN_PRIVILEGEプロシージャを実行する際に grant_privilegesパラメータを trueに設定して作成したローカル Streams 管理者のみが含まれます。生成されたスクリプトを使用して Streams 管理者を作成し、ユーザーに対して GRANT_ADMIN_PRIVILEGEプロシージャを実行する際に grant_privilegesパラメータを falseに設定した場合、DBA_STREAMS_ADMINISTRATORデータ・ディクショナリ・ビューには、ユーザーがStreams 管理者としてリスト表示されません。

GRANT_ADMIN_PRIVILEGEプロシージャの実行時に grant_privilegesパラメータをtrueに設定して作成したローカル Streams 管理者をリスト表示するには、次の問合せを実行します。

COLUMN USERNAME HEADING 'Local Streams Administrator' FORMAT A30

SELECT USERNAME FROM DBA_STREAMS_ADMINISTRATOR WHERE LOCAL_PRIVILEGES = 'YES';


Local Streams Administrator------------------------------STRMADMIN

GRANT_ADMIN_PRIVILEGEは、Streams 管理者となっているユーザーで実行されていない場合があります。このような管理者は、この項の問合せでは戻されません。また、ユーザーに対して GRANT_ADMIN_PRIVILEGEプロシージャを実行した後に、リスト表示されたユーザーの権限を変更できます。DBA_STREAMS_ADMINISTRATORビューでこれらの変更を追跡するには、DBMS_STREAMS_AUTHパッケージを使用する必要があります。たとえば、REVOKE SQL 文を使用すると、GRANT_ADMIN_PRIVILEGEプロシージャによって特定のユーザーに付与された権限を取り消すことができます。ただし、

参照参照参照参照 : DBMS_STREAMS_AUTHパッケージを使用して Streams 管理者および他の Streams ユーザーを構成する方法の詳細は、『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。


Streams の取得プロセスの監視

DBA_STREAMS_ADMINISTRATORビューを問い合せると、このユーザーがリスト表示されます。

REVOKE_ADMIN_PRIVILEGEプロシージャを使用してユーザーの権限を取り消すことをお薦めします。このプロシージャを使用してユーザーの権限を取り消すと、そのユーザーはDBA_STREAMS_ADMINISTRATORビューから削除されます。

リモートリモートリモートリモート Streams 管理者からのアクセスを許可するユーザーのリスト表示管理者からのアクセスを許可するユーザーのリスト表示管理者からのアクセスを許可するユーザーのリスト表示管理者からのアクセスを許可するユーザーのリスト表示リモート Streams 管理者からのアクセスを許可するユーザーを構成するには、DBMS_STREAMS_AUTHパッケージの GRANT_REMOTE_ADMIN_ACCESSプロシージャを実行します。このようなユーザーは、リモート Streams 管理者がデータベース・リンクを使用してローカル・データベースで管理操作を実行することを許可します。

通常、ローカル・ソース・データベースで発生した変更がダウンストリーム取得プロセスによって取得された場合に、ローカル・ソース・データベースでこのようなユーザーを構成します。ダウンストリーム取得データベースの Streams 管理者は、この接続を使用してソース・データベースを管理します。

リモート 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

Streams の取得プロセスの監視の取得プロセスの監視の取得プロセスの監視の取得プロセスの監視ここでは、取得プロセス情報を表示するために実行できる問合せについて説明します。

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

� 各取得プロセスに関する一般情報の表示

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

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

� 取得プロセスでは不要な REDO ログ・ファイルの表示

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




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

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

� 各取得プロセスで取得された追加の属性の表示

� データベースにおける全取得プロセスの適用済 SCN の判断

� 各取得プロセスに関する REDO ログのスキャン待機時間の判断

� 各取得プロセスに関するイベントのエンキュー待機時間の判断

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

各取得プロセスのキュー、ルール・セットおよび状態の表示各取得プロセスのキュー、ルール・セットおよび状態の表示各取得プロセスのキュー、ルール・セットおよび状態の表示各取得プロセスのキュー、ルール・セットおよび状態の表示この項で説明する問合せを実行すると、データベース内の各取得プロセスに関する次の一般情報を表示できます。

� 取得プロセス名

� 取得プロセスで使用されるキューの名前

� 取得プロセスで使用されるポジティブ・ルール・セットの名前

� 取得プロセスで使用されるネガティブ・ルール・セットの名前

� 取得プロセスの状態（ENABLED、DISABLEDまたは ABORTED）

この一般情報をデータベース内の取得プロセスごとに表示するには、次の問合せを実行します。

COLUMN CAPTURE_NAME HEADING 'Capture|Process|Name' FORMAT A15COLUMN QUEUE_NAME HEADING 'Capture|Process|Queue' FORMAT A15COLUMN RULE_SET_NAME HEADING 'Positive|Rule Set' FORMAT A15COLUMN NEGATIVE_RULE_SET_NAME HEADING 'Negative|Rule Set' FORMAT A15COLUMN 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 CaptureProcess Process Positive Negative ProcessName Queue Rule Set Rule Set Status--------------- --------------- --------------- --------------- ---------------STRM01_CAPTURE STRM01_QUEUE RULESET$_25 RULESET$_36 ENABLED

取得プロセスの状態が ABORTEDの場合、DBA_CAPTUREデータ・ディクショナリ・ビューの ERROR_NUMBER列および ERROR_MESSAGE列を問い合せて、エラーを判別できます。

各取得プロセスに関する一般情報の表示各取得プロセスに関する一般情報の表示各取得プロセスに関する一般情報の表示各取得プロセスに関する一般情報の表示この項で説明する問合せを実行すると、データベース内の各取得プロセスに関する次の一般情報が表示されます。

� 取得プロセスの名前

� 取得プロセス番号（cnnn）

� セッション識別子

� セッションのシリアル番号

� 取得プロセスの現在の状態（INITIALIZING、WAITING FOR DICTONARY REDO、DICTIONARY INITIALIZATION、MINING、LOADING、CAPTURING CHANGES、WAITING FOR REDO、EVALUATING RULE、CREATING LCR、ENQUEUING MESSAGE、PAUSED FOR FLOW CONTROLまたは SHUTTING DOWN）

� スキャンされた REDO エントリの合計数

� エンキューされた LCR の合計数

この情報をデータベース内の取得プロセスごとに表示するには、次の問合せを実行します。

COLUMN CAPTURE_NAME HEADING 'Capture|Name' FORMAT A10COLUMN PROCESS_NAME HEADING 'Capture|Process|Number' FORMAT A7COLUMN SID HEADING 'Session|ID' FORMAT 9999COLUMN SERIAL# HEADING 'Session|Serial|Number' FORMAT 9999COLUMN STATE HEADING 'State' FORMAT A27COLUMN TOTAL_MESSAGES_CAPTURED HEADING 'Redo|Entries|Scanned' FORMAT 9999999COLUMN TOTAL_MESSAGES_ENQUEUED HEADING 'Total|LCRs|Enqueued' FORMAT 999999

SELECT c.CAPTURE_NAME, SUBSTR(s.PROGRAM,INSTR(S.PROGRAM,'(')+1,4) PROCESS_NAME, c.SID,

参照参照参照参照 : 取得プロセスが異常終了した場合に、エラー番号およびエラー・メッセージを表示する問合せ例は、15-2 ページの「取得プロセスが有効化されているかどうか」を参照してください。



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#;


Capture Session Redo TotalCapture Process Session Serial Entries LCRsName Number ID Number State Scanned Enqueued---------- ------- ------- ------- --------------------------- -------- --------CAPTURE C001 15 9 CAPTURING CHANGES 14276 51

スキャンされた REDO エントリの数は、取得プロセスで取得された DML と DDL の REDOエントリの数より多い場合があります。取得プロセスのキューには、取得プロセスで取得された DML と DDL の REDO エントリのみがエンキューされます。また、エンキューされたLCR の合計数には、トランザクション制御文を含む LCR が算入されます。これらの行 LCRには、COMMITや ROLLBACKなどのディレクティブが含まれています。したがって、エンキューされた LCR の合計数は、取得プロセスによってエンキューされた行変更と DDL 変更の数より多くなります。

各ダウンストリーム取得プロセスに関する情報の表示各ダウンストリーム取得プロセスに関する情報の表示各ダウンストリーム取得プロセスに関する情報の表示各ダウンストリーム取得プロセスに関する情報の表示ダウンストリーム取得は、ソース・データベース以外のデータベース上で実行される取得プロセスです。この項で説明する問合せを実行すると、データベース内の各ダウンストリーム取得プロセスに関する次の一般情報を表示できます。

� 取得プロセス名

� 取得プロセスで取得された変更のソース・データベース

� 取得プロセスで使用されるキューの名前

� 取得プロセスの状態（ENABLED、DISABLEDまたは ABORTED）

� ダウンストリーム取得プロセスが、ソース・データベースへのデータベース・リンクを使用して管理操作を実行するかどうか

この情報をデータベース内のダウンストリーム取得プロセスごとに表示するには、次の問合せを実行します。


� トランザクション制御文の詳細は、2-3 ページの「行 LCR」を参照してください。




COLUMN CAPTURE_NAME HEADING 'Capture|Process|Name' FORMAT A15COLUMN SOURCE_DATABASE HEADING 'Source|Database' FORMAT A15COLUMN QUEUE_NAME HEADING 'Capture|Process|Queue' FORMAT A15COLUMN STATUS HEADING 'Capture|Process|Status' FORMAT A15COLUMN 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 UsesProcess Source Process Process DatabaseName Database Queue Status Link?--------------- --------------- --------------- --------------- --------STRM03_CAPTURE DBS1.NET STRM03_QUEUE ENABLED YES

この場合、取得プロセスのソース・データベースは dbs1.netですが、この取得プロセスを実行しているローカル・データベースは dbs1.netではありません。また、この問合せで戻される取得プロセスは、ソース・データベースへのデータベース・リンクを使用して管理操作を実行します。データベース・リンク名はソース・データベースのグローバル名と同じです（この場合は dbs1.net）。

取得プロセスの状態が ABORTEDの場合、DBA_CAPTUREデータ・ディクショナリ・ビューの ERROR_NUMBER列および ERROR_MESSAGE列を問い合せて、エラーを判別できます。

各取得プロセスの登録済各取得プロセスの登録済各取得プロセスの登録済各取得プロセスの登録済 REDO ログ・ファイルの表示ログ・ファイルの表示ログ・ファイルの表示ログ・ファイルの表示この項で説明する問合せを実行すると、データベース内の取得プロセスごとに登録されたアーカイブ REDO ログ・ファイルに関する情報を表示できます。この問合せでは、ローカル取得プロセスとダウンストリーム取得プロセスの両方のアーカイブ REDO ログ・ファイルに関する情報が表示されます。


� 2-14 ページの「ローカル取得とダウンストリーム取得」

� 9-6 ページの「ログ・ファイルを暗黙的に割り当てるダウンストリーム取得プロセスの作成」

� 取得プロセスが異常終了した場合に、エラー番号およびエラー・メッセージを表示する問合せ例は、15-2 ページの「取得プロセスが有効化されているかどうか」を参照してください。



また、登録済の各アーカイブ REDO ログ・ファイルに関する次の情報が表示されます。

� ファイルが使用される取得プロセスの名前

� ファイルのソース・データベース

� ファイルの順序番号

� ローカル・サイトでのファイルの名前および場所

� 作成されたデータ・ディクショナリの初の部分がファイルに含まれるかどうか

� 作成されたデータ・ディクショナリの後の部分がファイルに含まれるかどうか

この情報をデータベース内の登録済アーカイブ REDO ログ・ファイルごとに表示するには、次の問合せを実行します。

COLUMN CONSUMER_NAME HEADING 'Capture|Process|Name' FORMAT A15COLUMN SOURCE_DATABASE HEADING 'Source|Database' FORMAT A10COLUMN SEQUENCE# HEADING 'Sequence|Number' FORMAT 99999COLUMN NAME HEADING 'Archived Redo Log|File Name' FORMAT A20COLUMN DICTIONARY_BEGIN HEADING 'Dictionary|Build|Begin' FORMAT A10COLUMN 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 DictionaryProcess Source Sequence Archived Redo Log Build BuildName Database Number File Name Begin End--------------- ---------- -------- -------------------- ---------- ----------STRM02_CAPTURE DBS2.NET 15 /orc/dbs/log/arch2_1 NO NO _15_478347508.arcSTRM02_CAPTURE DBS2.NET 16 /orc/dbs/log/arch2_1 NO NO _16_478347508.arc STRM03_CAPTURE DBS1.NET 45 /remote_logs/arch1_1 YES YES _45_478347335.arcSTRM03_CAPTURE DBS1.NET 46 /remote_logs/arch1_1 NO NO _46_478347335.arcSTRM03_CAPTURE DBS1.NET 47 /remote_logs/arch1_1 NO NO _47_478347335.arc



この問合せが dbs2.netデータベースで実行され、strm02_captureがローカル取得プロセスであり、strm03_captureがダウンストリーム取得プロセスであると想定します。この strm03_captureダウンストリーム取得プロセスのソース・データベースは dbs1.netです。この問合せを実行すると、strm02_captureの 2 つの登録済アーカイブ REDO ログ・ファイル、strm03_captureの 3 つの登録済アーカイブ REDO ログ・ファイルが表示され、ローカル・サイトのファイル・システムにおけるこれらの各ファイルの名前と場所が表示されます。

取得プロセスには、必須チェックポイント SCN が含まれる REDO ログ・ファイルおよびすべての後続の REDO ログ・ファイルが必要です。DBA_CAPTUREデータ・ディクショナリ・ビューの REQUIRED_CHECKPOINT_SCN列を問い合せて、取得プロセスの必須チェックポイント SCN を判別することができます。必須チェックポイント SCN を含む前の REDO ログ・ファイルは、取得プロセスには必要ありません。これらの REDO ログ・ファイルが他の用途でも必要ない場合は、オフラインで格納できます。将来、取得プロセスの開始 SCN をより小さな値にリセットする場合、これらの REDO ログ・ファイルが必要となる場合もあります。

取得プロセスでは不要な取得プロセスでは不要な取得プロセスでは不要な取得プロセスでは不要な REDO ログ・ファイルの表示ログ・ファイルの表示ログ・ファイルの表示ログ・ファイルの表示DBA_LOGMNR_PURGED_LOGデータ・ディクショナリ・ビューには、ローカル・データベースのいずれの取得プロセスでも不要な REDO ログ・ファイルがリストされます。これらのREDO ログ・ファイルを削除しても、ローカル・データベースの既存の取得プロセスには影響を与えません。

取得プロセスで不要な REDO ログ・ファイルを表示するには、次の問合せを実行します。

SELECT * FROM DBA_LOGMNR_PURGED_LOG;


FILE_NAME--------------------------------------------------------------------/private1/ARCHIVE_LOGS/1_6_262829418.dbf


� データ・ディクショナリを作成する方法の詳細は、2-30 ページの「取得プロセスの LogMiner データ・ディクショナリ」を参照してください。



� 2-42 ページの「ARCHIVELOG モードと取得プロセス」

参照参照参照参照 : 2-42 ページの「ARCHIVELOG モードと取得プロセス」



取得プロセスで使用される各取得プロセスで使用される各取得プロセスで使用される各取得プロセスで使用される各 REDO ログ・ファイルのログ・ファイルのログ・ファイルのログ・ファイルの SCN 値の表示値の表示値の表示値の表示この項で説明する問合せを実行すると、データベース内の取得プロセスごとに登録されたアーカイブ REDO ログ・ファイルの SCN 値に関する情報を表示できます。この問合せでは、ローカル取得プロセスとダウンストリーム取得プロセスの両方のアーカイブ REDO ログ・ファイルの SCN 値に関する情報が表示されます。

また、登録済の各アーカイブ REDO ログ・ファイルに関する次の情報が表示されます。

� ファイルが使用される取得プロセスの名前

� ローカル・サイトでのファイルの名前および場所

� REDO ログ・ファイルに含まれる情報の小 SCN 値

� 連続する次の REDO ログ・ファイルの小 SCN 値

この情報をデータベース内の登録済アーカイブ REDO ログ・ファイルごとに表示するには、次の問合せを実行します。

COLUMN CONSUMER_NAME HEADING 'Capture|Process|Name' FORMAT A15COLUMN NAME HEADING 'Archived Redo Log|File Name' FORMAT A35COLUMN FIRST_SCN HEADING 'First SCN' FORMAT 99999999999COLUMN NEXT_SCN HEADING 'Next SCN' FORMAT 99999999999

SELECT r.CONSUMER_NAME, r.NAME, r.FIRST_SCN, r.NEXT_SCN FROM DBA_REGISTERED_ARCHIVED_LOG r, DBA_CAPTURE c WHERE r.CONSUMER_NAME = c.CAPTURE_NAME;


CaptureProcess Archived Redo LogName File Name First SCN Next SCN--------------- -------------------- ------------ ------------CAPTURE /private1/ARCHIVE_LO 202088 202112 GS/1_3_502628294.dbf

CAPTURE /private1/ARCHIVE_LO 202112 203389 GS/1_4_502628294.dbf






各取得プロセスで使用可能な最後のアーカイブ各取得プロセスで使用可能な最後のアーカイブ各取得プロセスで使用可能な最後のアーカイブ各取得プロセスで使用可能な最後のアーカイブ REDO エントリの表示エントリの表示エントリの表示エントリの表示ローカル取得プロセスで使用可能な後のアーカイブ REDO エントリは、アーカイブ・ログ・ファイルに書き込まれたオンライン REDO ログからの後のエントリです。ダウンストリーム取得プロセスで使用可能な後のアーカイブ REDO エントリは、取得プロセスで使用される LogMiner セッションに追加された後のアーカイブ・ログ・ファイル内の新の SCN を持つ REDO エントリです。

この項で説明する問合せを実行すると、各取得プロセスで使用可能にされた後の REDOエントリに関する次の情報を表示できます。

� 取得プロセスの名前

� 取得プロセスで使用される LogMiner セッションの識別番号

� 取得プロセスで使用可能な後の REDO エントリの SCN

� 後の REDO エントリが取得プロセスで使用可能となった時間

この問合せで表示される情報は、有効な取得プロセスにのみ有効です。

次の問合せを実行すると、各取得プロセスに関して前述の情報が表示されます。

COLUMN CAPTURE_NAME HEADING 'Capture|Name' FORMAT A20COLUMN LOGMINER_ID HEADING 'LogMiner ID' FORMAT 9999COLUMN AVAILABLE_MESSAGE_NUMBER HEADING 'Last Redo SCN' FORMAT 9999999999COLUMN AVAILABLE_MESSAGE_CREATE_TIME HEADING 'Time of|Last Redo 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;


Capture Time ofName LogMiner ID Last Redo SCN Last Redo SCN-------------------- ----------- ------------- -----------------STREAMS_CAPTURE 1 322953 11:33:20 10/16/03



各取得プロセスのパラメータ設定のリスト表示各取得プロセスのパラメータ設定のリスト表示各取得プロセスのパラメータ設定のリスト表示各取得プロセスのパラメータ設定のリスト表示次の問合せを実行すると、データベース内の取得プロセスごとの各取得プロセス・パラメータについて現行の設定が表示されます。

COLUMN CAPTURE_NAME HEADING 'Capture|Process|Name' FORMAT A15COLUMN PARAMETER HEADING 'Parameter' FORMAT A20COLUMN VALUE HEADING 'Value' FORMAT A20COLUMN SET_BY_USER HEADING 'Set by User?' FORMAT A20

SELECT CAPTURE_NAME, PARAMETER, VALUE, SET_BY_USER FROM DBA_CAPTURE_PARAMETERS;


CaptureProcessName Parameter Value Set by User?--------------- -------------------- -------------------- --------------------CAPTURE DISABLE_ON_LIMIT N NOCAPTURE MAXIMUM_SCN INFINITE NOCAPTURE MESSAGE_LIMIT INFINITE NOCAPTURE PARALLELISM 3 YESCAPTURE STARTUP_SECONDS 0 NOCAPTURE TIME_LIMIT INFINITE NOCAPTURE TRACE_LEVEL 0 NOCAPTURE WRITE_ALERT_LOG Y NO

注意注意注意注意 : パラメータの Set by User?列が NOの場合、そのパラメータはデフォルト値に設定されています。パラメータの Set by User?列が YESの場合は、そのパラメータはデフォルト値に設定されている場合と、設定されていない場合があります。


� 2-43 ページの「取得プロセスのパラメータ」




各取得プロセスで取得された追加の属性の表示各取得プロセスで取得された追加の属性の表示各取得プロセスで取得された追加の属性の表示各取得プロセスで取得された追加の属性の表示1 つ以上の追加の属性を REDO ログから取得するように取得プロセスに指示するには、DBMS_CAPTURE_ADMパッケージの INCLUDE_EXTRA_ATTRIBUTEプロシージャを使用します。次の問合せを実行すると、ローカル・データベース内の各取得プロセスで取得されたLCR に含まれる追加の属性が表示されます。

COLUMN CAPTURE_NAME HEADING 'Capture Process' FORMAT A20COLUMN ATTRIBUTE_NAME HEADING 'Attribute Name' FORMAT A15COLUMN 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 Attribute Name Include Attribute in LCRs?-------------------- --------------- ------------------------------STREAMS_CAPTURE ROW_ID NOSTREAMS_CAPTURE SERIAL# NOSTREAMS_CAPTURE SESSION# NOSTREAMS_CAPTURE THREAD# NOSTREAMS_CAPTURE TX_NAME YESSTREAMS_CAPTURE USERNAME NO

この出力に基づいて取得プロセス streams_captureが取得した LCR には、トランザクション名（tx_name）が含まれますが、その他の追加の属性は含まれません。

データベースにおける全取得プロセスの適用済データベースにおける全取得プロセスの適用済データベースにおける全取得プロセスの適用済データベースにおける全取得プロセスの適用済 SCN の判断の判断の判断の判断取得プロセスの適用済システム変更番号（SCN）は、関連適用プロセスによってデキューされた新イベントの SCN です。この適用済 SCN より小さい番号のすべての変更は、取得プロセスで取得された変更を適用するすべての適用プロセスによってデキューされています。


� 2-5 ページの「LCR 内の追加情報」

� 9-35 ページの「取得 LCR 内の追加の属性の管理」




データベース内のすべての取得プロセスの適用済 SCN を表示するには、次の問合せを実行します。

COLUMN CAPTURE_NAME HEADING 'Capture Process Name' FORMAT A30COLUMN 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）の変更によって、新の取得イベントに関する REDO 情報が生成された時刻です。

この問合せで表示される情報は、有効化されている取得プロセスにのみ有効です。

次の問合せを実行すると、各取得プロセスに関する REDO のスキャン待機時間を判断できます。

COLUMN CAPTURE_NAME HEADING 'Capture|Process|Name' FORMAT A10COLUMN LATENCY_SECONDS HEADING 'Latency|in|Seconds' FORMAT 999999COLUMN LAST_STATUS HEADING 'Seconds Since|Last Status' FORMAT 999999COLUMN CAPTURE_TIME HEADING 'Current|Process|Time'COLUMN CREATE_TIME HEADING 'Event|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 CurrentProcess in Seconds Since Process EventName Seconds Last Status Time Creation Time---------- ------- ------------- ----------------- -----------------CAPTURE 4 4 12:04:13 03/01/02 12:04:13 03/01/02

この問合せで戻される Latency in Secondsは、現在の時刻（SYSDATE）と Event Creation Timeの差です。この問合せで戻される Seconds Since Last Statusは、現在の時刻（SYSDATE）と Current Process Timeの差です。

各取得プロセスに関するイベントのエンキュー待機時間の判断各取得プロセスに関するイベントのエンキュー待機時間の判断各取得プロセスに関するイベントのエンキュー待機時間の判断各取得プロセスに関するイベントのエンキュー待機時間の判断この項で説明する問合せを実行すると、各取得プロセスに関する次の情報を検索できます。

� イベントのエンキュー待機時間。この時間は、イベントが REDO ログに記録されてから取得プロセスでエンキューされるまでの秒数を示します。

� イベント作成時刻。これは、データ操作言語（DML）またはデータ定義言語（DDL）の変更によって、新のエンキュー済イベントに関する REDO 情報が生成された時刻です。

� エンキュー時刻。これは、取得プロセスによってイベントがキューにエンキューされた時刻です。

� エンキューされたイベントのメッセージ番号。


次の問合せを実行すると、各取得プロセスに関するイベントの取得待機時間を判断できます。

COLUMN CAPTURE_NAME HEADING 'Capture|Process|Name' FORMAT A10COLUMN LATENCY_SECONDS HEADING 'Latency|in|Seconds' FORMAT 999999COLUMN CREATE_TIME HEADING 'Event Creation|Time' FORMAT A20COLUMN ENQUEUE_TIME HEADING 'Enqueue Time' FORMAT A20COLUMN ENQUEUE_MESSAGE_NUMBER HEADING 'Message|Number' FORMAT 999999

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 LatencyProcess in Event Creation MessageName 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と Event Creation Timeの差です。

各取得プロセスのルールの評価に関する情報の表示各取得プロセスのルールの評価に関する情報の表示各取得プロセスのルールの評価に関する情報の表示各取得プロセスのルールの評価に関する情報の表示この項で説明する問合せを実行すると、各取得プロセスのルールの評価に関する次の情報を表示できます。

� 取得プロセスの名前。

� 取得プロセスが後に起動されてから事前フィルタ処理中に破棄されたイベント数。取得プロセスによって、これらのイベントが取得プロセスのルール・セットを完全に満たしていないと事前フィルタ処理中に判定されています。

� 取得プロセスが後に起動されてから事前フィルタ処理中に保持されたイベント数。取得プロセスによって、これらのイベントが取得プロセスのルール・セットを完全に満たしていると事前フィルタ処理中に判定されています。このようなイベントは LCR に変換され、取得プロセス・キューにエンキューされます。

� 取得プロセスが後に起動されてからの事前フィルタ処理評価の合計数。

� 取得プロセスが後に起動されてから事前フィルタ処理後に判定されていないイベント数。これらのイベントは、取得プロセスのルール・セットを満たしている場合も満たしていない場合もあります。イベントには、取得プロセスのルール・セットを満たしているかどうかを判定するのに完全評価が必要なイベントもありますが、要求されている完全評価を実行せずに、事前フィルタ処理後に実行するフィルタ処理で除外できるイベントもあります。

� 取得プロセスが後に起動されてからの完全評価の数。完全評価を実行するとコストが高くなる場合があります。したがって、取得プロセスのパフォーマンスは、この数が比較的小さい場合に大となります。


次の問合せを実行すると、各取得プロセスに関して前述の情報が表示されます。

COLUMN CAPTURE_NAME HEADING 'Capture|Name' FORMAT A15COLUMN TOTAL_PREFILTER_DISCARDED HEADING 'Prefilter|Events|Discarded' FORMAT 9999999999COLUMN TOTAL_PREFILTER_KEPT HEADING 'Prefilter|Events|Kept' FORMAT 9999999999COLUMN TOTAL_PREFILTER_EVALUATIONS HEADING 'Prefilter|Evaluations' FORMAT 9999999999


SYS.AnyData キューおよびメッセージの監視

COLUMN UNDECIDED HEADING 'Undecided|After|Prefilter' FORMAT 9999999999COLUMN 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 UndecidedCapture Events Events Prefilter After FullName Discarded Kept Evaluations Prefilter Evaluations--------------- ----------- ----------- ----------- ----------- -----------STREAMS_CAPTURE 68485 0 68570 85 27

事前フィルタ処理評価の合計数は、事前フィルタ処理で破棄されたイベント、保持されたイベントおよび判定されなかったイベントの合計と等しくなります。

SYS.AnyData キューおよびメッセージの監視キューおよびメッセージの監視キューおよびメッセージの監視キューおよびメッセージの監視ここでは、SYS.AnyDataキューに関する情報を表示するために実行できる問合せについて説明します。

� データベース内の SYS.AnyData キューの表示

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

� メッセージ通知の表示

� キュー内の各ユーザー・エンキュー・イベントのコンシューマの判断

� キュー内のユーザー・エンキュー・イベントの内容の表示

参照参照参照参照 : 2-44 ページの「取得プロセス・ルールの評価」






データベース内のデータベース内のデータベース内のデータベース内の SYS.AnyData キューの表示キューの表示キューの表示キューの表示データベース内のすべての SYS.AnyDataキューを表示するには、次の問合せを実行します。

COLUMN OWNER HEADING 'Owner' FORMAT A10COLUMN NAME HEADING 'Queue Name' FORMAT A28COLUMN QUEUE_TABLE HEADING 'Queue Table' FORMAT A22COLUMN 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---------- ---------------------------- ---------------------- ---------------SYS AQ$_SCHEDULER$_JOBQTAB_E SCHEDULER$_JOBQTAB exception queueSYS SCHEDULER$_JOBQ SCHEDULER$_JOBQTAB Scheduler job q ueueSYS AQ$_DIR$EVENT_TABLE_E DIR$EVENT_TABLE exception queueSYS DIR$EVENT_QUEUE DIR$EVENT_TABLESYS AQ$_DIR$CLUSTER_DIR_TABLE_E DIR$CLUSTER_DIR_TABLE exception queueSYS DIR$CLUSTER_DIR_QUEUE DIR$CLUSTER_DIR_TABLESTRMADMIN AQ$_STREAMS_QUEUE_TABLE_E STREAMS_QUEUE_TABLE exception queueSTRMADMIN STREAMS_QUEUE STREAMS_QUEUE_TABLE

SYS.AnyDataキューを作成すると、例外キューが自動的に作成されます。

データベース内のメッセージ・クライアントの表示データベース内のメッセージ・クライアントの表示データベース内のメッセージ・クライアントの表示データベース内のメッセージ・クライアントの表示DBA_STREAMS_MESSAGE_CONSUMERSデータ・ディクショナリ・ビューを問い合せると、データベース内のメッセージ・クライアントを表示できます。この項で説明する問合せを実行すると、各メッセージ・クライアントに関する次の情報が表示されます。

� メッセージ・クライアントの名前

� メッセージ・クライアントで使用されるキュー

� メッセージ・クライアントで使用されるポジティブ・ルール・セット

� メッセージ・クライアントで使用されるネガティブ・ルール・セット

参照参照参照参照 : 10-2 ページの「SYS.AnyData キューの管理」



次の問合せを実行すると、メッセージ・クライアントに関するこの情報が表示されます。

COLUMN STREAMS_NAME HEADING 'Messaging|Client' FORMAT A25COLUMN QUEUE_OWNER HEADING 'Queue Owner' FORMAT A10COLUMN QUEUE_NAME HEADING 'Queue Name' FORMAT A18COLUMN RULE_SET_NAME HEADING 'Positive|Rule Set' FORMAT A11COLUMN 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 Positive NegativeClient Queue Owne Queue Name Rule Set Rule Set------------------------- ---------- ------------------ ----------- -----------SCHEDULER_PICKUP SYS SCHEDULER$_JOBQ RULESET$_8SCHEDULER_COORDINATOR SYS SCHEDULER$_JOBQ RULESET$_4HR STRMADMIN STREAMS_QUEUE RULESET$_15

メッセージ通知の表示メッセージ通知の表示メッセージ通知の表示メッセージ通知の表示メッセージ・クライアントによってデキュー可能なメッセージがキューにエンキューされる際に通知が送信されるようにメッセージ通知を構成することができます。通知は、電子メール・アドレス、HTTP URL または PL/SQL プロシージャに送信できます。次の問合せを実行すると、データベース内で構成されたメッセージ通知が表示されます。

COLUMN STREAMS_NAME HEADING 'Messaging|Client' FORMAT A10COLUMN QUEUE_OWNER HEADING 'Queue|Owner' FORMAT A5COLUMN QUEUE_NAME HEADING 'Queue Name' FORMAT A20COLUMN NOTIFICATION_TYPE HEADING 'Notification|Type' FORMAT A15COLUMN 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;

参照参照参照参照 : メッセージ・クライアントの詳細は、第 3 章「Streams のステージングと伝播」を参照してください。




Messaging Queue Notification NotificationClient Owner Queue Name Type Action---------- ----- -------------------- --------------- -------------------------OE OE NOTIFICATION_QUEUE MAIL [email protected]

キュー内の各ユーザー・エンキュー・イベントのコンシューマの判断キュー内の各ユーザー・エンキュー・イベントのコンシューマの判断キュー内の各ユーザー・エンキュー・イベントのコンシューマの判断キュー内の各ユーザー・エンキュー・イベントのコンシューマの判断キュー内の各ユーザー・エンキュー・イベントのコンシューマを判断するには、キュー所有者のスキーマ内で AQ$queue_table_nameを問い合せます。この場合、queue_table_nameはキュー表名です。たとえば、oe_q_table_anyキュー表内のユーザー・エンキュー・イベントのコンシューマを検索するには、次の問合せを実行します。

COLUMN MSG_ID HEADING 'Message ID' FORMAT 9999COLUMN MSG_STATE HEADING 'Message State' FORMAT A13COLUMN 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 OEB79AC412AE6F08CAE034080020AE3E0A PROCESSED OEB79AC412AE7008CAE034080020AE3E0A PROCESSED OE

参照参照参照参照 : 10-23 ページの「メッセージ・クライアントおよびメッセージ通知の構成」

注意注意注意注意 : この問合せを実行すると、取得イベントではなくユーザー・エンキュー・イベントのみが表示されます。

参照参照参照参照 : SYS.AnyDataキューにメッセージをエンキューする例については、『Oracle Streams アドバンスト・キューイング・ユーザーズ・ガイドおよびリファレンス』を参照してください。



キュー内のユーザー・エンキュー・イベントの内容の表示キュー内のユーザー・エンキュー・イベントの内容の表示キュー内のユーザー・エンキュー・イベントの内容の表示キュー内のユーザー・エンキュー・イベントの内容の表示SYS.AnyDataキュー内で、SYS.AnyDataペイロードにカプセル化されているペイロードの内容を表示するには、SYS.AnyData型の Accessdata_type静的ファンクションを使用してキュー表を問い合せます。この場合、data_typeは表示するペイロードの型です。

たとえば、キュー表 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のペイロードの内容を表示するには、Streams 管理者として接続し、次のようなファンクションを作成します。

CONNECT oe/oe

CREATE OR REPLACE FUNCTION oe.view_cust_address_typ(in_any IN SYS.AnyData) RETURN oe.cust_address_typIS address oe.cust_address_typ; num_var NUMBER;

参照参照参照参照 : この項の問合せで表示されるイベントを SYS.AnyDataキューにエンキューする例については、10-19 ページの「SYS.AnyData ラッパーでのユーザー・メッセージ・ペイロードのラップおよびエンキュー」を参照してください。


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

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')

Streams 伝播および伝播ジョブの監視伝播および伝播ジョブの監視伝播および伝播ジョブの監視伝播および伝播ジョブの監視ここでは、伝播および伝播ジョブの情報を表示するために実行できる問合せについて説明します。

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

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

� 伝播ジョブのスケジュールの表示

� 各伝播によって伝播されたイベントの合計数とバイト数の判断



� 10-7 ページの「Streams の伝播および伝播ジョブの管理」



各伝播のソース・キューと宛先キューの判断各伝播のソース・キューと宛先キューの判断各伝播のソース・キューと宛先キューの判断各伝播のソース・キューと宛先キューの判断各伝播のソース・キューおよび宛先キューを判断するには、DBA_PROPAGATIONデータ・ディクショナリ・ビューを問い合せます。このビューには、ローカル・データベースにソース・キューを含む各伝播に関する情報が表示されます。

たとえば、次の問合せを実行すると、伝播 dbs1_to_dbs2に関して次の情報が表示されます。

� ソース・キューの所有者

� ソース・キュー名

� ソース・キューを含むデータベース

� 宛先キューの所有者

� 宛先キュー名

� 伝播で使用されるデータベース・リンク

COLUMN 'Source Queue' FORMAT A35COLUMN '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;


Source Queue Destination Queue----------------------------------- -----------------------------------STRMADMIN.STREAMS_QUEUE@DBS1.NET [email protected][email protected] [email protected]

各伝播のルール・セットの判断各伝播のルール・セットの判断各伝播のルール・セットの判断各伝播のルール・セットの判断次の問合せを実行すると、各伝播に関する次の情報が表示されます。

� 伝播の名前

� 伝播のポジティブ・ルール・セットの所有者

� 伝播で使用されるポジティブ・ルール・セットの名前

� 伝播で使用されるネガティブ・ルール・セットの名前

� 伝播で使用されるネガティブ・ルール・セットの名前



この一般情報をデータベース内の伝播ごとに表示するには、次の問合せを実行します。

COLUMN PROPAGATION_NAME HEADING 'Propagation|Name' FORMAT A20COLUMN RULE_SET_OWNER HEADING 'Positive|Rule Set|Owner' FORMAT A10COLUMN RULE_SET_NAME HEADING 'Positive Rule|Set Name' FORMAT A15COLUMN NEGATIVE_RULE_SET_OWNER HEADING 'Negative|Rule Set|Owner' FORMAT A10COLUMN 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 NegativePropagation Rule Set Positive Rule Rule Set Negative RuleName Owner Set Name Owner Set Name-------------------- ---------- --------------- ---------- ---------------STRM01_PROPAGATION STRMADMIN RULESET$_22 STRMADMIN RULESET$_31

伝播ジョブのスケジュールの表示伝播ジョブのスケジュールの表示伝播ジョブのスケジュールの表示伝播ジョブのスケジュールの表示この項で説明する問合せを実行すると、伝播 dbs1_to_dbs2で使用される伝播ジョブの伝播スケジュールに関して次の情報が表示されます。

� 伝播スケジュールの開始日時。

� 伝播ジョブの継続時間。これは、再起動前にジョブによってイベントが伝播される期間です。

� 伝播ジョブの待機時間。これは、継続時間中にキューにある他のすべてのメッセージが宛先に伝播された場合に、次のメッセージが伝播されるまでの大待機時間です。

� 伝播ジョブが有効化されているかどうか。

� 後にスケジュールを実行したプロセスの名前。

� スケジュールの実行に失敗した場合の連続失敗回数。連続して 16 回失敗すると、伝播ジョブは自動的に無効化されます。

ソース・キューを含むデータベースで、次の問合せを実行します。

COLUMN START_DATE HEADING 'Start Date'COLUMN PROPAGATION_WINDOW HEADING 'Duration|in Seconds' FORMAT 99999COLUMN NEXT_TIME HEADING 'Next|Time' FORMAT A8COLUMN LATENCY HEADING 'Latency|in Seconds' FORMAT 99999COLUMN SCHEDULE_DISABLED HEADING 'Status' FORMAT A8



COLUMN PROCESS_NAME HEADING 'Process' FORMAT A8COLUMN FAILURES HEADING 'Number of|Failures' FORMAT 99

SELECT TO_CHAR(s.START_DATE, 'HH24:MI:SS MM/DD/YY') START_DATE, s.PROPAGATION_WINDOW, s.NEXT_TIME, s.LATENCY, DECODE(s.SCHEDULE_DISABLED, 'Y', 'Disabled', 'N', 'Enabled') SCHEDULE_DISABLED, s.PROCESS_NAME, s.FAILURES FROM DBA_QUEUE_SCHEDULES s, DBA_PROPAGATION p WHERE p.PROPAGATION_NAME = 'DBS1_TO_DBS2' AND p.DESTINATION_DBLINK = s.DESTINATION AND s.SCHEMA = p.SOURCE_QUEUE_OWNER AND s.QNAME = p.SOURCE_QUEUE_NAME;


Duration Next Latency Number ofStart Date in Seconds Time in Seconds Status Process Failures----------------- ---------- -------- ---------- -------- -------- ---------15:23:40 03/02/02 5 Enabled J002 0

この伝播ジョブでは、Streams の伝播ジョブのデフォルト・スケジュールが使用されています。つまり、継続時間と次回実行時刻はどちらも NULLで、待機時間は 5 秒です。継続時間が NULLの場合、ジョブでは変更が伝播されますが、ジョブが自動的に再起動されることはありません。次回実行時刻が NULLの場合、伝播ジョブは現在実行中です。


� Streams の伝播ジョブのデフォルト伝播スケジュールの詳細は、3-16ページの「伝播のスケジューリングと Streams 伝播」を参照してください。

� 伝播ジョブが無効化されている場合は、15-8 ページの「伝播で使用される伝播ジョブが有効化されているか」を参照してください。

� DBA_QUEUE_SCHEDULESデータ・ディクショナリ・ビューの詳細は、『Oracle Streams アドバンスト・キューイング・ユーザーズ・ガイドおよびリファレンス』および『Oracle Database リファレンス』を参照してください。



各伝播によって伝播されたイベントの合計数とバイト数の判断各伝播によって伝播されたイベントの合計数とバイト数の判断各伝播によって伝播されたイベントの合計数とバイト数の判断各伝播によって伝播されたイベントの合計数とバイト数の判断同じデータベース・リンクを共有するソース・キューからのすべての伝播ジョブには、1 つの伝播スケジュールが使用されます。この項で説明する問合せを実行すると、各伝播に関する次の情報が表示されます。

� 伝播の名前

� 伝播スケジュールを実行するシステムによって消費された合計時間

� 伝播スケジュールに従って伝播されたイベントの合計数

� 伝播スケジュールに従って伝播された合計バイト数

次の問合せを実行すると、ソース・キューがローカル・データベースに含まれる伝播ごとにこの情報が表示されます。

COLUMN PROPAGATION_NAME HEADING 'Propagation|Name' FORMAT A20COLUMN TOTAL_TIME HEADING 'Total Time|Executing|in Seconds' FORMAT 999999COLUMN TOTAL_NUMBER HEADING 'Total Events|Propagated' FORMAT 999999999COLUMN 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 p.DESTINATION_DBLINK = s.DESTINATION AND s.SCHEMA = p.SOURCE_QUEUE_OWNER AND s.QNAME = p.SOURCE_QUEUE_NAME;


Total TimePropagation Executing Total Events Total BytesName in Seconds Propagated Propagated-------------------- ---------- ------------ --------------MULT3_TO_MULT1 351 872 875252MULT3_TO_MULT2 596 872 875252

参照参照参照参照 : DBA_QUEUE_SCHEDULESデータ・ディクショナリ・ビューの詳細は、『Oracle Streams アドバンスト・キューイング・ユーザーズ・ガイドおよびリファレンス』および『Oracle Database リファレンス』を参照してください。


Streams の適用プロセスの監視

Streams の適用プロセスの監視の適用プロセスの監視の適用プロセスの監視の適用プロセスの監視ここでは、適用プロセス情報を表示するために実行できる問合せについて説明します。

� 各適用プロセスのキュー、ルール・セットおよび状態の表示

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

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

� 適用ハンドラに関する情報の表示

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

� イベントが取得されてからデキューされるまでの待機時間の判断

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

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

� 各適用プロセスのイベントが取得されてから適用されるまでの待機時間の判断

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

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

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

� 適用時に実行の回避を指定するルールの表示

� 適用エラーのチェック

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

各適用プロセスのキュー、ルール・セットおよび状態の表示各適用プロセスのキュー、ルール・セットおよび状態の表示各適用プロセスのキュー、ルール・セットおよび状態の表示各適用プロセスのキュー、ルール・セットおよび状態の表示この項で説明する問合せを実行すると、データベース内の各適用プロセスに関する次の情報が表示されます。

� 適用プロセス名

� 適用プロセスで使用されるキューの名前

� 適用プロセスで使用されるポジティブ・ルール・セットの名前

� 適用プロセスで使用されるネガティブ・ルール・セットの名前

� 適用プロセスの状態（ENABLED、DISABLEDまたは ABORTED）






この一般情報をデータベース内の適用プロセスごとに表示するには、次の問合せを実行します。

COLUMN APPLY_NAME HEADING 'Apply|Process|Name' FORMAT A15COLUMN QUEUE_NAME HEADING 'Apply|Process|Queue' FORMAT A15COLUMN RULE_SET_NAME HEADING 'Positive|Rule Set' FORMAT A15COLUMN NEGATIVE_RULE_SET_NAME HEADING 'Negative|Rule Set' FORMAT A15COLUMN 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 ApplyProcess Process Positive Negative ProcessName Queue Rule Set Rule Set Status--------------- --------------- --------------- --------------- ---------------STRM01_APPLY STRM01_QUEUE RULESET$_36 ENABLEDAPPLY_EMP STREAMS_QUEUE RULESET$_16 DISABLEDAPPLY STREAMS_QUEUE RULESET$_21 RULESET$_23 ENABLED

適用プロセスの状態が ABORTEDの場合、DBA_APPLYデータ・ディクショナリ・ビューのERROR_NUMBER列および ERROR_MESSAGE列を問い合せて、エラーを判別できます。

各適用プロセスに関する一般情報の表示各適用プロセスに関する一般情報の表示各適用プロセスに関する一般情報の表示各適用プロセスに関する一般情報の表示この項で説明する問合せを実行すると、データベース内の各適用プロセスに関する次の一般情報を表示できます。

� 適用プロセス名。

� 適用プロセスによって適用されるイベントのタイプ。適用プロセスでは、取得プロセスで取得されたイベント、またはユーザーやアプリケーションによってエンキューされたイベントを適用できます。

� 適用ユーザー。

参照参照参照参照 : 適用プロセスの状態が ABORTEDの場合、適用エラーの有無をチェックするには、14-44 ページの「適用エラーのチェック」を参照してください。



この一般情報をデータベース内の適用プロセスごとに表示するには、次の問合せを実行します。

COLUMN APPLY_NAME HEADING 'Apply Process Name' FORMAT A20COLUMN APPLY_CAPTURED HEADING 'Type of Events Applied' FORMAT A15COLUMN APPLY_USER HEADING 'Apply User' FORMAT A30

SELECT APPLY_NAME, DECODE(APPLY_CAPTURED, 'YES', 'Captured', 'NO', 'User-Enqueued') APPLY_CAPTURED, APPLY_USER FROM DBA_APPLY;


Apply Process Name Type of Events Apply User-------------------- --------------- ------------------------------STRM01_APPLY Captured STRMADMINAPPLY_OE User-Enqueued STRMADMINAPPLY Captured HR

各適用プロセスのパラメータ設定のリスト表示各適用プロセスのパラメータ設定のリスト表示各適用プロセスのパラメータ設定のリスト表示各適用プロセスのパラメータ設定のリスト表示次の問合せを実行すると、データベース内の適用プロセスごとの各適用プロセス・パラメータについて現行の設定が表示されます。

COLUMN APPLY_NAME HEADING 'Apply Process|Name' FORMAT A15COLUMN PARAMETER HEADING 'Parameter' FORMAT A20COLUMN VALUE HEADING 'Value' FORMAT A20COLUMN SET_BY_USER HEADING 'Set by User?' FORMAT A20

SELECT APPLY_NAME, PARAMETER, VALUE, SET_BY_USER FROM DBA_APPLY_PARAMETERS;


Apply ProcessName Parameter Value Set by User?--------------- -------------------- -------------------- --------------------STRM01_APPLY COMMIT_SERIALIZATION FULL NOSTRM01_APPLY DISABLE_ON_ERROR Y YESSTRM01_APPLY DISABLE_ON_LIMIT N NOSTRM01_APPLY MAXIMUM_SCN INFINITE NOSTRM01_APPLY PARALLELISM 1 NO



STRM01_APPLY STARTUP_SECONDS 0 NOSTRM01_APPLY TIME_LIMIT INFINITE NOSTRM01_APPLY TRACE_LEVEL 0 NOSTRM01_APPLY TRANSACTION_LIMIT INFINITE NOSTRM01_APPLY WRITE_ALERT_LOG Y NO

適用ハンドラに関する情報の表示適用ハンドラに関する情報の表示適用ハンドラに関する情報の表示適用ハンドラに関する情報の表示この項では、適用プロセスのメッセージ・ハンドラおよびエラー・ハンドラに関する情報を表示する問合せについて説明します。

ローカルの適用に関するすべてのエラー・ハンドラの表示ローカルの適用に関するすべてのエラー・ハンドラの表示ローカルの適用に関するすべてのエラー・ハンドラの表示ローカルの適用に関するすべてのエラー・ハンドラの表示接続先データベースで DBMS_APPLY_ADMパッケージの SET_DML_HANDLERプロシージャを使用してローカルのエラー・ハンドラを指定すると、適用プロセスでエラーが発生した場合、特定の適用プロセスに対してハンドラを実行するか、変更をローカルに適用するデータベース内のすべての適用プロセスに対して実行する汎用ハンドラを実行するかを指定できます。特定のエラー・ハンドラは、汎用エラー・ハンドラより優先されます。エラー・ハンドラは、特定の表への指定した操作に対して実行されます。

データベース内で変更をローカルに適用する各適用プロセスについてエラー・ハンドラを表示するには、次の問合せを実行します。

COLUMN OBJECT_OWNER HEADING 'Table|Owner' FORMAT A5COLUMN OBJECT_NAME HEADING 'Table Name' FORMAT A10COLUMN OPERATION_NAME HEADING 'Operation' FORMAT A10COLUMN USER_PROCEDURE HEADING 'Handler Procedure' FORMAT A30COLUMN APPLY_NAME HEADING 'Apply Process|Name' FORMAT A15

注意注意注意注意 : パラメータの Set by User?列が NOの場合、そのパラメータはデフォルト値に設定されています。パラメータの Set by User?列が YESの場合は、そのパラメータはデフォルト値に設定されている場合と、設定されていない場合があります。


� 4-17 ページの「適用プロセスのパラメータ」



� 4-3 ページの「適用プロセスによるイベント処理」

� DML ハンドラおよび DDL ハンドラを監視する方法の詳細は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。



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 ProcessOwner 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 A20COLUMN 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 "HR"."MES_PROC"

参照参照参照参照 : 11-23 ページの「エラー・ハンドラの管理」

参照参照参照参照 : 11-16 ページの「適用プロセスのメッセージ・ハンドラの管理」



各適用プロセスのプリコミット・ハンドラの表示各適用プロセスのプリコミット・ハンドラの表示各適用プロセスのプリコミット・ハンドラの表示各適用プロセスのプリコミット・ハンドラの表示データベース内の各プリコミット・ハンドラを表示するには、次の問合せを実行します。

COLUMN APPLY_NAME HEADING 'Apply Process Name' FORMAT A20COLUMN PRECOMMIT_HANDLER HEADING 'Precommit Handler' FORMAT A30COLUMN APPLY_CAPTURED HEADING 'Type of|Events|Applied' FORMAT A15

SELECT APPLY_NAME, PRECOMMIT_HANDLER, DECODE(APPLY_CAPTURED, 'YES', 'Captured', 'NO', 'User-Enqueued') APPLY_CAPTURED FROM DBA_APPLY WHERE PRECOMMIT_HANDLER IS NOT NULL;


Type of EventsApply Process Name Precommit Handler Applied-------------------- ------------------------------ ---------------STRM01_APPLY "STRMADMIN"."HISTORY_COMMIT" Captured

各適用プロセス用のリーダー・サーバーに関する情報の表示各適用プロセス用のリーダー・サーバーに関する情報の表示各適用プロセス用のリーダー・サーバーに関する情報の表示各適用プロセス用のリーダー・サーバーに関する情報の表示適用プロセス用のリーダー・サーバーによって、キューからイベントがデキューされます。リーダー・サーバーはパラレル実行サーバーであり、LCR 間の依存性を計算してイベントをトランザクションにアセンブルします。次に、アセンブルしたトランザクションをコーディネータに戻すと、コーディネータはそれをアイドル状態の適用サーバーに割り当てます。

この項で説明する問合せを実行すると、各適用プロセス用のリーダー・サーバーに関して次の情報が表示されます。

� 適用プロセスの名前

� リーダー・サーバーによってデキューされるイベントのタイプ（取得された LCR またはユーザーがエンキューしたメッセージ）

� リーダー・サーバーで使用されるパラレル実行サーバーの名前

� リーダー・サーバーの現在の状態（IDLE、DEQUEUE MESSAGESまたは SCHEDULE MESSAGES）

� 適用プロセスの前回の起動時刻以降にリーダー・サーバーによってデキューされたイベントの合計数

参照参照参照参照 : 11-17 ページの「適用プロセスのプリコミット・ハンドラの管理」



この問合せで表示される情報は、有効化されている適用プロセスにのみ有効です。

次の問合せを実行すると、各適用プロセスに関して前述の情報が表示されます。

COLUMN APPLY_NAME HEADING 'Apply Process|Name' FORMAT A17COLUMN APPLY_CAPTURED HEADING 'Apply Type' FORMAT A22COLUMN PROCESS_NAME HEADING 'Process|Name' FORMAT A7COLUMN STATE HEADING 'State' FORMAT A17COLUMN TOTAL_MESSAGES_DEQUEUED HEADING 'Total Events|Dequeued' FORMAT 99999999

SELECT r.APPLY_NAME, DECODE(ap.APPLY_CAPTURED, 'YES','Captured LCRS', 'NO','User-enqueued messages','UNKNOWN') 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 Process Total EventsName Apply Type Name State Dequeued----------------- ---------------------- ------- ----------------- ------------APPLY_FROM_MULT2 Captured LCRS P000 DEQUEUE MESSAGES 3803APPLY_FROM_MULT1 Captured LCRS P001 DEQUEUE MESSAGES 2754

イベントが取得されてからデキューされるまでの待機時間の判断イベントが取得されてからデキューされるまでの待機時間の判断イベントが取得されてからデキューされるまでの待機時間の判断イベントが取得されてからデキューされるまでの待機時間の判断この項で説明する問合せを実行すると、各適用プロセスによってデキューされた後のイベントに関して次の情報が表示されます。

� 適用プロセスの名前。

� 待機時間。取得イベントにおける待機時間とは、ソース・データベースでイベントが作成されてから、適用プロセスでデキューされるまでの時間です。ユーザー・エンキュー・イベントにおける待機時間とは、ローカル・データベースでイベントがエンキューされてから、適用プロセスでデキューされるまでの時間です。

� イベント作成時刻。取得イベントの場合、イベント作成時刻は、データ操作言語（DML）またはデータ定義言語（DDL）の変更によって、ソース・データベースでイベントに関する REDO 情報が生成された時刻です。ユーザー・エンキュー・イベントの場合、イベント作成時刻はイベントが後にエンキューされた時刻です。ユーザー・エ

参照参照参照参照 : 4-14 ページの「リーダー・サーバーの状態」



ンキュー・イベントは、適用プロセスに到達する前に、伝播によってさらに 1 回以上エンキューされる場合があります。

� イベントが適用プロセスによってデキューされた時刻。

� 適用プロセスによって後にデキューされたイベントのメッセージ番号。



COLUMN APPLY_NAME HEADING 'Apply Process|Name' FORMAT A17COLUMN LATENCY HEADING 'Latency|in|Seconds' FORMAT 9999COLUMN CREATION HEADING 'Event Creation' FORMAT A17COLUMN LAST_DEQUEUE HEADING 'Last Dequeue Time' FORMAT A20COLUMN DEQUEUED_MESSAGE_NUMBER HEADING 'Dequeued|Message Number' FORMAT 999999

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;


LatencyApply Process in DequeuedName Seconds Event Creation Last Dequeue Time Message Number----------------- ------- ----------------- -------------------- --------------APPLY_FROM_MULT1 36 10:56:51 02/27/03 10:57:27 02/27/03 253962APPLY_FROM_MULT2 18 13:13:04 02/28/03 13:13:22 02/28/03 633043

各コーディネータ・プロセスに関する一般情報の表示各コーディネータ・プロセスに関する一般情報の表示各コーディネータ・プロセスに関する一般情報の表示各コーディネータ・プロセスに関する一般情報の表示コーディネータ・プロセスは、リーダー・サーバーからトランザクションを取得して適用サーバーに渡します。コーディネータ・プロセス名は apnnで、nnはコーディネータ・プロセス番号です。

この項で説明する問合せを実行すると、各適用プロセス用のコーディネータ・プロセスに関して次の情報が表示されます。


� プロセス名のコーディネータ番号（apnn）

� コーディネータ・セッションのセッション識別子

� コーディネータ・セッションのシリアル番号



� コーディネータの現在の状態（INITIALIZING、APPLYING、SHUTTING DOWN CLEANLYまたは ABORTING）



COLUMN APPLY_NAME HEADING 'Apply Process|Name' FORMAT A17COLUMN PROCESS_NAME HEADING 'Coordinator|Process|Name' FORMAT A11COLUMN SID HEADING 'Session|ID' FORMAT 9999COLUMN SERIAL# HEADING 'Session|Serial|Number' FORMAT 9999COLUMN 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 SessionApply Process Process Session SerialName Name ID Number State----------------- ----------- ------- ------- ---------------------APPLY_FROM_MULT1 A001 16 1 APPLYINGAPPLY_FROM_MULT2 A002 18 1 APPLYING

受信および適用されたトランザクションに関する情報の表示受信および適用されたトランザクションに関する情報の表示受信および適用されたトランザクションに関する情報の表示受信および適用されたトランザクションに関する情報の表示この項で説明する問合せを実行すると、各適用プロセスによって受信および適用されたトランザクションと、現在適用されているトランザクションに関して次の情報が表示されます。


� 適用プロセスが後に起動されてからコーディネータ・プロセスが受信したトランザクションの合計数

� 適用プロセスが後に起動されてから、その適用プロセスで正常に適用されたトランザクションの合計数

� 適用プロセスが後に起動されてから、適用プロセスで適用されて適用エラーとなったトランザクションの数

参照参照参照参照 : 4-14 ページの「コーディネータ・プロセスの状態」



� 適用プロセスによって現在適用されているトランザクションの合計数

� 適用プロセスによってトランザクションが適用されていたため、適用プロセスが後に起動されてからコーディネータ・プロセスが受信しても無視したトランザクションの合計数


たとえば、適用プロセス applyに関して前述の情報を表示するには、次の問合せを実行します。

COLUMN APPLY_NAME HEADING 'Apply Process Name' FORMAT A25COLUMN TOTAL_RECEIVED HEADING 'Total|Trans|Received' FORMAT 99999999COLUMN TOTAL_APPLIED HEADING 'Total|Trans|Applied' FORMAT 99999999COLUMN TOTAL_ERRORS HEADING 'Total|Apply|Errors' FORMAT 9999COLUMN BEING_APPLIED HEADING 'Total|Trans Being|Applied' FORMAT 99999999COLUMN 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, TOTAL_IGNORED FROM V$STREAMS_APPLY_COORDINATOR;


Total Total Total Total Total Trans Trans Apply Trans Being TransApply Process Name Received Applied Errors Applied Ignored------------------------- --------- --------- ------ ----------- ---------APPLY_FROM_MULT1 81 73 2 6 0APPLY_FROM_MULT2 114 96 0 14 4

各適用プロセスのイベントが取得されてから適用されるまでの待機時間の各適用プロセスのイベントが取得されてから適用されるまでの待機時間の各適用プロセスのイベントが取得されてから適用されるまでの待機時間の各適用プロセスのイベントが取得されてから適用されるまでの待機時間の判断判断判断判断

この項では、特定のイベントについて取得から適用までの待機時間を表示する、2 つの異なる問合せについて説明します。つまり、取得イベントの場合、この 2 つの問合せでは、ソース・データベースでイベントが作成されてから、適用プロセスで適用されるまでの時間が表示されます。一方の問合せでは V$STREAMS_APPLY_COORDINATOR動的パフォーマンス・ビューが使用され、他方の問合せでは DBA_APPLY_PROGRESS静的データ・ディクショナリ・ビューが使用されます。



この 2 つの問合せには、次の重要な違いがあります。

� V$STREAMS_APPLY_COORDINATORビューの問合せを実行する場合は、適用プロセスが有効化されている必要がありますが、DBA_APPLY_PROGRESSビューの問合せを実行する場合は、適用プロセスが無効化されていてもかまいません。

� V$STREAMS_APPLY_COORDINATORビューの問合せでは、DBA_APPLY_PROGRESSビューの問合せよりも新しいトランザクションの待機時間を表示できます。

いずれの問合せを実行しても、各適用プロセスによって適用されたイベントに関する次の情報が表示されます。

� 適用プロセス名。

� イベントの取得から適用までの待機時間。

� イベント作成時刻。取得イベントの場合、イベント作成時刻は、データ操作言語（DML）またはデータ定義言語（DDL）の変更によって、ソース・データベースでイベントに関する REDO 情報が生成された時刻です。

� イベントが適用プロセスによって適用された時刻。

� イベントのメッセージ番号。

待機時間に関する待機時間に関する待機時間に関する待機時間に関する V$STREAMS_APPLY_COORDINATOR の問合せ例の問合せ例の問合せ例の問合せ例V$STREAMS_APPLY_COORDINATORビューを使用して次の問合せを実行すると、各適用プロセスのイベントの取得から適用までの待機時間が表示されます。

COLUMN APPLY_NAME HEADING 'Apply Process|Name' FORMAT A17COLUMN 'Latency in Seconds' FORMAT 999999COLUMN 'Event Creation' FORMAT A17COLUMN 'Apply Time' FORMAT A17COLUMN HWM_MESSAGE_NUMBER HEADING 'Applied|Message|Number' FORMAT 999999

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') "Event Creation", TO_CHAR(HWM_TIME,'HH24:MI:SS MM/DD/YY') "Apply Time", HWM_MESSAGE_NUMBER FROM V$STREAMS_APPLY_COORDINATOR;

注意注意注意注意 : これらの問合せでは、適用プロセスでユーザー・エンキュー・イベントではなく取得イベントが適用されることを想定しています。




AppliedApply Process MessageName Latency in Seconds Event Creation Apply Time Number----------------- ------------------ ----------------- ----------------- -------APPLY_FROM_MULT1 781 14:05:29 02/28/03 14:18:30 02/28/03 638609APPLY_FROM_MULT2 381 13:13:04 02/28/03 13:19:25 02/28/03 633043

待機時間に関する待機時間に関する待機時間に関する待機時間に関する DBA_APPLY_PROGRESS の問合せ例の問合せ例の問合せ例の問合せ例DBA_APPLY_PROGRESSビューを使用して次の問合せを実行すると、各適用プロセスのイベントの取得から適用までの待機時間が表示されます。

COLUMN APPLY_NAME HEADING 'Apply Process|Name' FORMAT A17COLUMN 'Latency in Seconds' FORMAT 999999COLUMN 'Event Creation' FORMAT A17COLUMN 'Apply Time' FORMAT A17COLUMN APPLIED_MESSAGE_NUMBER HEADING 'Applied|Message|Number' FORMAT 999999

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') "Event Creation", TO_CHAR(APPLY_TIME,'HH24:MI:SS MM/DD/YY') "Apply Time", APPLIED_MESSAGE_NUMBER FROM DBA_APPLY_PROGRESS;


AppliedApply Process MessageName Latency in Seconds Event Creation Apply Time Number----------------- ------------------ ----------------- ----------------- -------APPLY_FROM_MULT1 219 14:05:23 02/28/03 14:09:02 02/28/03 638607APPLY_FROM_MULT2 2641 12:29:21 02/28/03 13:13:22 02/28/03 617393

各適用プロセス用の適用サーバーに関する情報の表示各適用プロセス用の適用サーバーに関する情報の表示各適用プロセス用の適用サーバーに関する情報の表示各適用プロセス用の適用サーバーに関する情報の表示適用プロセスでは、1 つ以上の適用サーバーを使用できます。適用サーバーによって、LCRが DML 文または DDL 文としてデータベース・オブジェクトに適用されるか、適切なハンドラに渡されます。LCR 以外のメッセージの場合、適用サーバーはイベントをメッセージ・ハンドラに渡します。各適用サーバーは、パラレル実行サーバーです。



この項で説明する問合せを実行すると、各適用プロセス用の適用サーバーに関して次の情報が表示されます。

� 適用プロセスの名前。

� パラレル実行サーバーのプロセス名（順番に表示）。

� 各適用サーバーの現在の状態（IDLE、RECORD LOW-WATERMARK、ADD PARTITION、DROP PARTITION、EXECUTE TRANSACTION、WAIT COMMIT、WAIT DEPENDENCY、WAIT FOR NEXT CHUNKまたは TRANSACTION CLEANUP）。これらの各状態の詳細は、

『Oracle Database リファレンス』の「V$STREAMS_APPLY_SERVER」を参照してください。

� 適用プロセスが後に起動されてから、各適用サーバーに割り当てられたトランザクションの合計数。トランザクションには、複数のイベントが含まれている場合があります。

� 適用プロセスが後に起動されてから、各適用サーバーによって適用されたイベントの合計数。


次の問合せを実行すると、各適用プロセス用の適用サーバーに関する情報が表示されます。

COLUMN APPLY_NAME HEADING 'Apply Process Name' FORMAT A22COLUMN PROCESS_NAME HEADING 'Process Name' FORMAT A12COLUMN STATE HEADING 'State' FORMAT A17COLUMN TOTAL_ASSIGNED HEADING 'Total|Transactions|Assigned' FORMAT 99999999COLUMN TOTAL_MESSAGES_APPLIED HEADING 'Total|Events|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.SERVER_ID;


Total Total Transactions EventsApply Process Name Process Name State Assigned Applied---------------------- ------------ ----------------- ------------ ---------APPLY P001 IDLE 94 2141APPLY P002 IDLE 12 276APPLY P003 IDLE 0 0



適用プロセスに有効な適用並列性の表示適用プロセスに有効な適用並列性の表示適用プロセスに有効な適用並列性の表示適用プロセスに有効な適用並列性の表示環境によっては、適用プロセスで使用可能なすべての適用サーバーを使用できない場合があります。たとえば、適用プロセスの並列性は 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 99COLUMN TOTAL_MESSAGES_APPLIED HEADING 'Total Events 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 Events Applied--------------- -------------------- 1 2141 2 276 3 0

この場合、適用プロセスでは、適用サーバー 3 が後に起動されてから使用されていません。適用プロセスの parallelismがその有効な並列性より大きい値に設定されている場合は、parallelismを小さい値に設定することを考慮してください。

参照参照参照参照 : 4-14 ページの「適用サーバーの状態」



適用時に宛先キューを指定するルールの表示適用時に宛先キューを指定するルールの表示適用時に宛先キューを指定するルールの表示適用時に宛先キューを指定するルールの表示ルールの宛先キューを指定するには、DBMS_APPLY_ADMパッケージのSET_ENQUEUE_DESTINATIONプロシージャを使用します。適用時に宛先キューを指定するルールが適用プロセスのポジティブ・ルール・セットに含まれ、イベントがそのルールを満たす場合、このイベントは適用プロセスによって宛先キューにエンキューされます。

ルールに対する宛先キューの設定を表示するには、次の問合せを実行します。

COLUMN RULE_OWNER HEADING 'Rule Owner' FORMAT A15COLUMN RULE_NAME HEADING 'Rule Name' FORMAT A15COLUMN 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 A20COLUMN RULE_NAME HEADING 'Rule Name' FORMAT A20

SELECT RULE_OWNER, RULE_NAME FROM DBA_APPLY_EXECUTE WHERE EXECUTE_EVENT = 'NO';



� 6-46 ページの「適用時のイベントのエンキューの宛先」




Rule Owner Rule Name-------------------- --------------------STRMADMIN DEPARTMENTS18

適用エラーのチェック適用エラーのチェック適用エラーのチェック適用エラーのチェック適用エラーの有無をチェックするには、次の問合せを実行します。

COLUMN APPLY_NAME HEADING 'Apply|Process|Name' FORMAT A10COLUMN SOURCE_DATABASE HEADING 'Source|Database' FORMAT A10COLUMN LOCAL_TRANSACTION_ID HEADING 'Local|Transaction|ID' FORMAT A11COLUMN ERROR_NUMBER HEADING 'Error Number' FORMAT 99999999COLUMN ERROR_MESSAGE HEADING 'Error Message' FORMAT A20COLUMN MESSAGE_COUNT HEADING 'Events 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 Events inProcess Source Transaction ErrorName Database ID Error Number Error Message Transaction---------- ---------- ----------- ------------ -------------------- -----------APPLY_FROM MULT3.NET 1.62.948 1403 ORA-01403: データが 1_MULT3 見つかりません。

APPLY_FROM MULT2.NET 1.54.948 1403 ORA-01403: データが 1_MULT2 見つかりません。

適用エラーがある場合は、エラーが発生したトランザクションを再実行するか、そのトランザクションを削除できます。エラーが発生したトランザクションを再実行する場合は、まずトランザクションでエラーが発生する原因となった条件を訂正します。


� 11-21 ページの「適用プロセスの実行ディレクティブの指定」

� 6-46 ページの「適用時のイベントの実行ディレクティブ」



エラーが発生したトランザクションを削除する場合に、複数のデータベース間でデータを共有していると、手動によるデータの再同期化が必要になることがあります。データを手動で再同期化する場合は、必要に応じて適切なセッション・タグを設定してください。

適用エラーの詳細情報の表示適用エラーの詳細情報の表示適用エラーの詳細情報の表示適用エラーの詳細情報の表示この項では、データベースのエラー・キューにあるエラー・トランザクションの詳細情報を表示するために使用できる SQL スクリプトについて説明します。これらのスクリプトはLCR イベント情報を表示するように設計されていますが、環境で使用される非 LCR イベント情報を表示するように拡張できます。

これらのスクリプトを使用するには、次の手順を実行します。

1. DBA_APPLY_ERROR ビューの明示的な SELECT 権限の付与

2. SYS.AnyData オブジェクト内の値を出力するプロシージャの作成

3. 指定した LCR を出力するプロシージャの作成

4. エラー・キューにある全 LCR を出力するプロシージャの作成

5. 特定のトランザクションに関するすべてのエラー LCR を出力するプロシージャの作成

手順手順手順手順 1 DBA_APPLY_ERROR ビューの明示的なビューの明示的なビューの明示的なビューの明示的な SELECT 権限の付与権限の付与権限の付与権限の付与

ここで説明する print_errorsおよび print_transactionプロシージャを作成して実行するユーザーには、DBA_APPLY_ERRORデータ・ディクショナリ・ビューに対する明示的な SELECT権限を付与する必要があります。この権限は、ロールを介しては付与できません。ユーザーに対して DBMS_STREAMS_AUTHパッケージの GRANT_ADMIN_PRIVILEGEプロシージャを実行して付与します。


� 4-19 ページの「エラー・キュー」


� 適用エラーに考えられる原因については、『Oracle Streams レプリケーション管理者ガイド』を参照してください。

� 現行セッションで生成されるタグ値の設定の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。

注意注意注意注意 : これらのスクリプトでは、LCR イベントにおける VARCHAR2値の初の 253 文字のみが表示されます。



ユーザーに直接この権限を付与するには、次の手順を実行します。

1. 権限を付与できる管理ユーザーとして接続します。

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 で権限を付与したユーザーとしてデータベースに接続します。

手順手順手順手順 2 SYS.AnyData オブジェクト内の値を出力するプロシージャの作成オブジェクト内の値を出力するプロシージャの作成オブジェクト内の値を出力するプロシージャの作成オブジェクト内の値を出力するプロシージャの作成

次のプロシージャを実行すると、選択したデータ型について指定した SYS.AnyDataオブジェクト内の値が出力されます。必要に応じて、このプロシージャに他のデータ型を追加できます。

CREATE OR REPLACE PROCEDURE print_any(data IN SYS.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.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 が出力されます。このプロシージャでは、14-46 ページの「SYS.AnyData オブジェクト内の値を出力するプロシージャの作成」で作成した print_anyプロシージャがコールされます。

CREATE OR REPLACE PROCEDURE print_lcr(lcr IN SYS.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 SYS.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 が出力されます。このプロシージャでは、14-47 ページの「指定した 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(255);



lcr SYS.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 が出力されます。このプロシージャでは、14-47 ページの「指定した 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(128);


ルールおよびルールベースの変換の監視

lcr SYS.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')

ルールおよびルールベースの変換の監視ルールおよびルールベースの変換の監視ルールおよびルールベースの変換の監視ルールおよびルールベースの変換の監視ここでは、ルールおよびルールベースの変換に関する情報を表示するために実行できる問合せについて説明します。

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

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

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

� Streams ルールの変更されたルール条件の表示

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

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



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

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

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

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

� ルールベースの変換の表示

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

� ルール・セット評価に関する一般情報の表示

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

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

すべてのすべてのすべてのすべての Streams クライアントによって使用されるすべてのルールの表示クライアントによって使用されるすべてのルールの表示クライアントによって使用されるすべてのルールの表示クライアントによって使用されるすべてのルールの表示Streams ルールは、DBMS_STREAMS_ADMパッケージまたは Oracle Enterprise Manager コンソールの Streams ツールを使用して作成されたルールです。ルール・セット内の Streams クライアントに対する Streams ルールによって、Streams クライアントの動作が決定されます。Streams クライアントには、取得プロセス、伝播、適用プロセスおよびメッセージ・クライアントが含まれます。Streams クライアントのルール・セットには、DBMS_RULE_ADMパッケージを使用して作成されたルールも含まれる場合があり、これらのルールによってもStreams クライアントの動作が決定されます。

たとえば、hr.employees表に対する DML 変更について、取得プロセスのポジティブ・ルール・セット内のルールが TRUEと評価されると、取得プロセスでこの表に対する DML変更が取得されます。ただし、hr.employees表に対する DML 変更について、取得プロセスのネガティブ・ルール・セット内のルールが TRUEと評価されると、取得プロセスでこの表に対する DML 変更が廃棄されます。





� ルールのアクション・コンテキストを表示する方法の詳細は、12-7ページの「ルールのアクション・コンテキストの名前 / 値ペアの変更」を参照してください。



次のデータ・ディクショナリ・ビューを問い合せると、Streams クライアントのルール・セット内のすべてのルール（Streams のルールおよび DBMS_RULE_ADMパッケージを使用して作成されたルールを含む）が表示されます。

� ALL_STREAMS_RULES

� DBA_STREAMS_RULES

また、これらの 2 つのビューを実行すると、各ルールの現行のルール条件、およびこれらのルール条件が変更されたかどうかが表示されます。

この項で説明する問合せを実行すると、データベース内で Streams クライアントによって使用されるすべてのルールに関して次の情報が表示されます。

� ルールを使用する各 Streams クライアントの名前

� ルールを使用する各 Streams クライアントの型（取得プロセスの CAPTURE、伝播のPROPAGATION、適用プロセスの APPLY またはメッセージ・クライアントのDEQUEUE）

� ルール名

� Streams クライアントのルールを含むルール・セットの型（POSITIVE またはNEGATIVE）

� Streams ルールのレベル（GLOBAL、SCHEMA または TABLE）

� スキーマ・ルールおよび表ルールのスキーマ名（Streams ルールの場合）

� 表ルールの表の名前（Streams ルールの場合）

� ルール型（DML または DDL）（Streams ルールの場合）

次の問合せを実行すると、前述の情報が表示されます。

COLUMN STREAMS_NAME HEADING 'Streams|Name' FORMAT A14COLUMN STREAMS_TYPE HEADING 'Streams|Type' FORMAT A11COLUMN RULE_NAME HEADING 'Rule|Name' FORMAT A12COLUMN RULE_SET_TYPE HEADING 'Rule Set|Type' FORMAT A8COLUMN STREAMS_RULE_TYPE HEADING 'Streams|Rule|Level' FORMAT A7COLUMN SCHEMA_NAME HEADING 'Schema|Name' FORMAT A6COLUMN OBJECT_NAME HEADING 'Object|Name' FORMAT A11COLUMN 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;




StreamsStreams Streams Rule Rule Set Rule Schema Object RuleName Type Name Type Level Name Name Type-------------- ----------- ------------ -------- ------- ------ ----------- ----STRM01_CAPTURE CAPTURE JOBS4 POSITIVE TABLE HR JOBS DMLSTRM01_CAPTURE CAPTURE JOBS5 POSITIVE TABLE HR JOBS DDLDBS1_TO_DBS2 PROPAGATION HR18 POSITIVE SCHEMA HR DDLDBS1_TO_DBS2 PROPAGATION HR17 POSITIVE SCHEMA HR DMLAPPLY APPLY HR20 POSITIVE SCHEMA HR DMLAPPLY APPLY JOB_HISTORY2 NEGATIVE TABLE HR JOB_HISTORY DMLOE DEQUEUE RULE$_28 POSITIVE

この出力では、データベース内で 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ビューには、Streams クライアントによって使用されるルール・セットに関する情報、Streams ルールの現行および元のルール条件、ルール条件が変更されたかどうか、各 Streams サブセット・ルールのサブセット化操作および DML 条件、各 Streams ルールに指定されたソース・データベース、およびStreams メッセージ・ルールのメッセージ型およびメッセージ変数に関する情報も含まれます。

次のデータ・ディクショナリ・ビューを問い合せても、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

これらのビューには、Streams ルールのみが表示されます。DBMS_RULE_ADMパッケージによってこれらのルールに対して手動で行われた変更や、DBMS_RULE_ADMパッケージを使用して作成されたルールは、表示されません。また、これらのビューには、各ルールの元のルール条件のみが表示されます。ルールの作成後にルール条件が変更された場合、現行のルール条件は表示されません。

特定の特定の特定の特定の Streams クライアントによって使用されるクライアントによって使用されるクライアントによって使用されるクライアントによって使用される Streams ルールの表示ルールの表示ルールの表示ルールの表示特定の Streams クライアントによって使用されているルール・セット内のルールを判別するには、DBA_STREAMS_RULESデータ・ディクショナリ・ビューを問い合せます。たとえば、データベースで適用プロセス strm01_applyが実行中である場合を考えます。ここでは、この適用プロセス用のポジティブ・ルール・セットおよびネガティブ・ルール・セット内のルールを判別する方法について説明します。

Streams クライアント用のポジティブ・ルール・セット内のルールの判別クライアント用のポジティブ・ルール・セット内のルールの判別クライアント用のポジティブ・ルール・セット内のルールの判別クライアント用のポジティブ・ルール・セット内のルールの判別次の問合せを実行すると、適用プロセス strm01_apply用のポジティブ・ルール・セットに含まれるすべてのルールが表示されます。

COLUMN RULE_OWNER HEADING 'Rule Owner' FORMAT A10COLUMN RULE_NAME HEADING 'Rule|Name' FORMAT A12COLUMN STREAMS_RULE_TYPE HEADING 'Streams|Rule|Level' FORMAT A7COLUMN SCHEMA_NAME HEADING 'Schema|Name' FORMAT A6COLUMN OBJECT_NAME HEADING 'Object|Name' FORMAT A11COLUMN RULE_TYPE HEADING 'Rule|Type' FORMAT A4COLUMN SOURCE_DATABASE HEADING 'Source' FORMAT A10COLUMN 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 を適用します。


Streams Apply Rule Rule Schema Object Rule TaggedRule Owner Name Level Name Name Type Source LCRs?---------- --------------- ------- ------ ----------- ---- ---------- ---------STRMADMIN HR20 SCHEMA HR DML DBS1.NET NOSTRMADMIN HR21 SCHEMA HR DDL DBS1.NET NO

この問合せで戻された Streams ルールのルール条件は変更されていないと想定すると、これらの結果は、hrスキーマに対して dbs1.netデータベースで発生した DML 変更およびDDL 変更を含む LCR が、適用プロセスによって適用されることを示します。これらの LCRを適用するように適用プロセスに指示するポジティブ・ルール・セット内のルールは、所有者が strmadminで、名前は hr20および hr21です。また、適用プロセスではこれらのルールの 1 つを満たす LCR が適用されますが、LCR 内のタグが NULLの場合にかぎります。

Streams ルールのルール条件が変更されている場合、そのルールの現行のルール条件をチェックして、ルールが Streams クライアントに及ぼす影響を判断する必要があります。変更されたルール条件を持つ Streams ルールでは、SAME_RULE_CONDITION列に NOが表示されます。

Streams クライアント用のネガティブ・ルール・セット内のルールの判別クライアント用のネガティブ・ルール・セット内のルールの判別クライアント用のネガティブ・ルール・セット内のルールの判別クライアント用のネガティブ・ルール・セット内のルールの判別次の問合せを実行すると、適用プロセス strm01_apply用のネガティブ・ルール・セットに含まれるすべてのルールが表示されます。

COLUMN RULE_OWNER HEADING 'Rule Owner' FORMAT A10COLUMN RULE_NAME HEADING 'Rule|Name' FORMAT A15COLUMN STREAMS_RULE_TYPE HEADING 'Streams|Rule|Level' FORMAT A7COLUMN SCHEMA_NAME HEADING 'Schema|Name' FORMAT A6COLUMN OBJECT_NAME HEADING 'Object|Name' FORMAT A11COLUMN RULE_TYPE HEADING 'Rule|Type' FORMAT A4COLUMN SOURCE_DATABASE HEADING 'Source' FORMAT A10COLUMN 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,

参照参照参照参照 : 14-58 ページの「Streams ルールの変更されたルール条件の表示」



INCLUDE_TAGGED_LCR FROM DBA_STREAMS_RULES WHERE STREAMS_NAME = 'APPLY' AND RULE_SET_TYPE = 'NEGATIVE';

この問合せで行が戻された場合、適用プロセスは、ルールが TRUEと評価される変更を含むLCR を廃棄します。


Streams Apply Rule Rule Schema Object Rule TaggedRule Owner Name Level Name Name Type Source LCRs?---------- --------------- ------- ------ ----------- ---- ---------- ---------STRMADMIN JOB_HISTORY22 TABLE HR JOB_HISTORY DML DBS1.NET YESSTRMADMIN JOB_HISTORY23 TABLE HR JOB_HISTORY DDL DBS1.NET YES

この問合せで戻された Streams ルールのルール条件は変更されていないと想定すると、これらの結果は、hr.job_history表に対して dbs1.netデータベースで発生した DML 変更および DDL 変更を含む LCR が、適用プロセスによって廃棄されることを示します。これらの LCR を廃棄するように適用プロセスに指示するネガティブ・ルール・セット内のルールは、所有者が strmadminで、名前は job_history22および job_history23です。また、LRC 内のタグ値にかかわらず、適用プロセスではこれらのルールの 1 つを満たす LCRが廃棄されます。

Streams ルールのルール条件が変更されている場合、そのルールの現行のルール条件をチェックして、ルールが Streams クライアントに及ぼす影響を判断する必要があります。変更されたルール条件を持つ Streams ルールでは、SAME_RULE_CONDITION列に NOが表示されます。

ルールの現行の条件の表示ルールの現行の条件の表示ルールの現行の条件の表示ルールの現行の条件の表示ルール名がわかっている場合は、そのルール条件を表示できます。たとえば、14-55 ページの「特定の Streams クライアントによって使用される Streams ルールの表示」の問合せで戻されるルールを考えます。ルールの名前は hr1で、次の問合せを実行するとその条件を表示できます。

SET LONG 8000SET PAGES 8000SELECT RULE_CONDITION "Current Rule Condition" FROM DBA_STREAMS_RULES WHERE RULE_NAME = 'HR1' AND RULE_OWNER = 'STRMADMIN';

参照参照参照参照 : 14-58 ページの「Streams ルールの変更されたルール条件の表示」




Current Rule Condition-----------------------------------------------------------------(:dml.get_object_owner() = 'HR' and :dml.is_null_tag() = 'Y' and :dml.get_source_database_name() = 'DBS1.NET' )

Streams ルールの変更されたルール条件の表示ルールの変更されたルール条件の表示ルールの変更されたルール条件の表示ルールの変更されたルール条件の表示Streams ルールのルール条件は変更できます。ルール条件を変更すると、Streams ルールを使用する Streams クライアントの動作が変化する場合があります。また、変更によっては、ルール評価のパフォーマンスが低下する場合もあります。

次の問合せを実行すると、条件が変更された各 Streams ルールのルール名、元のルール条件および現行のルール条件が表示されます。

COLUMN RULE_NAME HEADING 'Rule Name' FORMAT A12COLUMN ORIGINAL_RULE_CONDITION HEADING 'Original Rule Condition' FORMAT A33COLUMN RULE_CONDITION HEADING 'Current Rule Condition' FORMAT A33

SET LONG 8000SET PAGES 8000SELECT 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 と評価されます。


� 5-2 ページの「ルール条件」




各ルール・セットの評価コンテキストの表示各ルール・セットの評価コンテキストの表示各ルール・セットの評価コンテキストの表示各ルール・セットの評価コンテキストの表示次の問合せを実行すると、データベース内のルール・セットごとにデフォルトの評価コンテキストが表示されます。

COLUMN RULE_SET_OWNER HEADING 'Rule Set|Owner' FORMAT A10COLUMN RULE_SET_NAME HEADING 'Rule Set Name' FORMAT A20COLUMN RULE_SET_EVAL_CONTEXT_OWNER HEADING 'Eval Context|Owner' FORMAT A12COLUMN 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 ContextOwner Rule Set Name Owner Eval Context Name---------- -------------------- ------------ ------------------------------STRMADMIN RULESET$_2 SYS STREAMS$_EVALUATION_CONTEXTSTRMADMIN STRM02_QUEUE_R STRMADMIN AQ$_STRM02_QUEUE_TABLE_VSTRMADMIN APPLY_OE_RS STRMADMIN OE_EVAL_CONTEXTSTRMADMIN OE_QUEUE_R STRMADMIN AQ$_OE_QUEUE_TABLE_VSTRMADMIN AQ$_1_RE STRMADMIN AQ$_OE_QUEUE_TABLE_VSUPPORT RS SUPPORT EVALCTXOE NOTIFICATION_QUEUE_R OE AQ$_NOTIFICATION_QUEUE_TABLE_V

注意注意注意注意 : この項で説明する問合せは、Streams ルールのみに使用できます。DBMS_RULE_ADMパッケージを使用して作成されたルールには使用できません。これらのルールでは常に、ORIGINAL_RULE_CONDITION列にNULL、SAME_RULE_CONDITION列に NULLが表示されるためです。





� 5-5 ページの「ルール評価コンテキスト」

� 6-40 ページの「Streams で使用される評価コンテキスト」



評価コンテキストで使用される表に関する情報の表示評価コンテキストで使用される表に関する情報の表示評価コンテキストで使用される表に関する情報の表示評価コンテキストで使用される表に関する情報の表示次の問合せを実行すると、supportユーザーが所有する評価コンテキスト evalctxで使用される表に関する情報が表示されます。

COLUMN TABLE_ALIAS HEADING 'Table Alias' FORMAT A20COLUMN 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 A15COLUMN VARIABLE_TYPE HEADING 'Variable Type' FORMAT A15COLUMN VARIABLE_VALUE_FUNCTION HEADING 'Variable Value|Function' FORMAT A20COLUMN 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 MethodVariable Name Variable Type Function Function--------------- --------------- -------------------- --------------------CURRENT_TIME DATE timefunc

参照参照参照参照 : 5-5 ページの「ルール評価コンテキスト」

参照参照参照参照 : 5-5 ページの「ルール評価コンテキスト」



ルール・セットの全ルールの表示ルール・セットの全ルールの表示ルール・セットの全ルールの表示ルール・セットの全ルールの表示この項で説明する問合せを実行すると、ルール・セット内の全ルールに関する情報が表示されます。

� ルールの所有者。

� ルール名。

� 存在する場合は、ルールの評価コンテキスト。ルールに評価コンテキストがなく、そのルールをルール・セットに追加するときに ADD_RULEプロシージャで評価コンテキストが指定されていない場合は、ルール・セットの評価コンテキストが継承されます。

� ルールに評価コンテキストがある場合は、評価コンテキストの所有者。

たとえば、ユーザー strmadminが所有するルール・セット oe_queue_r内の各ルールについて前述の情報を表示するには、次の問合せを実行します。

COLUMN RULE_OWNER HEADING 'Rule Owner' FORMAT A10COLUMN RULE_NAME HEADING 'Rule Name' FORMAT A20COLUMN RULE_EVALUATION_CONTEXT_NAME HEADING 'Eval Context Name' FORMAT A27COLUMN 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 ContexRule Owner Rule Name Eval Context Name Owner---------- -------------------- --------------------------- -----------STRMADMIN HR1 STREAMS$_EVALUATION_CONTEXT SYSSTRMADMIN APPLY_LCRS STREAMS$_EVALUATION_CONTEXT SYSSTRMADMIN OE_QUEUE$3STRMADMIN APPLY_ACTION



ルール・セット内の各ルールの条件の表示ルール・セット内の各ルールの条件の表示ルール・セット内の各ルールの条件の表示ルール・セット内の各ルールの条件の表示次の問合せを実行すると、ユーザー strmadminが所有するルール・セット hr_queue_r内の各ルールの条件が表示されます。

SET LONGCHUNKSIZE 4000SET LONG 4000COLUMN RULE_OWNER HEADING 'Rule Owner' FORMAT A15COLUMN RULE_NAME HEADING 'Rule Name' FORMAT A15COLUMN 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 A30COLUMN 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 DEPARTMENTS4STRMADMIN DEPARTMENTS5STRMADMIN DEPARTMENTS6

ルールベースの変換の表示ルールベースの変換の表示ルールベースの変換の表示ルールベースの変換の表示ルールベースの変換は、ポジティブ・ルール・セットのルールが TRUEに評価される場合に発生するイベントの変更です。この変更を実行する PL/SQL ファンクションを指定します。

次の問合せを実行すると、データベースで指定されたルールベースの各変換が表示されます。

COLUMN RULE_OWNER HEADING 'Rule Owner' FORMAT A20COLUMN RULE_NAME HEADING 'Rule Name' FORMAT A20COLUMN TRANSFORM_FUNCTION_NAME HEADING 'Transformation Function' FORMAT A30

SELECT RULE_OWNER, RULE_NAME, TRANSFORM_FUNCTION_NAME FROM DBA_STREAMS_TRANSFORM_FUNCTION;


Rule Owner Rule Name Transformation Function-------------------- -------------------- ------------------------------STRMADMIN DEPARTMENTS17 hr.executive_to_managementSTRMADMIN DEPARTMENTS18 hr.executive_to_managementSTRMADMIN DEPARTMENTS19 hr.executive_to_management

注意注意注意注意 : 変換ファンクション名は VARCHAR2型にする必要があります。VARCHAR2 型でない場合は、TRANSFORM_FUNCTION_NAMEの値がNULLになります。DBA_STREAMS_TRANSFORM_FUNCTIONビューのVALUE_TYPE列には、変換ファンクション名の型が表示されます。






すべてのルール・セット評価の総合統計の表示すべてのルール・セット評価の総合統計の表示すべてのルール・セット評価の総合統計の表示すべてのルール・セット評価の総合統計の表示データベース・インスタンスが後に起動された後に実行されたすべてのルール・セット評価の統計を表示するには、V$RULE_SET_AGGREGATE_STATS動的パフォーマンス・ビューを問い合せます。

この項で説明する問合せを実行すると、ルール・セット評価に関する次の情報が表示されます。

� ルール・セット評価の数。

� 初の実行で停止するように指示されたルール・セット評価の数。

� 単純なルールのみを評価するように指示されたルール・セット評価の数。

� ルール・セットが SQL を発行せずに評価された回数。一般的に、SQL を発行してルールを評価すると、発行しない場合よりコストが高くなります。

� ルール・セット評価にかかった CPU タイム（センチセカンド）。

� ルール・セット評価にかかった時間（センチセカンド）。

� ルール・セット内のルールを評価するために発行された SQL の数。

� ルール・セット評価中に処理されたルール条件の数。

� ルール・エンジン・クライアントに戻された TRUEルールの数。

� ルール・エンジン・クライアントに戻された MAYBEルールの数。

� ルール・セット評価中に、変数値ファンクション、変数メソッド・ファンクションおよび評価ファンクションがコールされた回数。

次の問合せを実行すると、前述の情報が表示されます。

COLUMN NAME HEADING 'Name of Statistic' FORMAT A55COLUMN VALUE HEADING 'Value' FORMAT 999999999

SELECT NAME, VALUE FROM V$RULE_SET_AGGREGATE_STATS;


Name of Statistic Value------------------------------------------------------- ----------rule set evaluations (all) 5584rule set evaluations (first_hit) 5584rule set evaluations (simple_rules_only) 3675rule set evaluations (SQL free) 5584rule set evaluation time (CPU) 179rule set evaluation time (elapsed) 1053rule set SQL executions 0rule set conditions processed 11551rule set true rules 10



rule set maybe rules 328rule set user function calls (variable value function) 182rule set user function calls (variable method function) 12794rule set user function calls (evaluation function) 3857

ルール・セット評価に関する一般情報の表示ルール・セット評価に関する一般情報の表示ルール・セット評価に関する一般情報の表示ルール・セット評価に関する一般情報の表示データベース・インスタンスが後に起動された後に実行されたすべてのルール・セット評価に関する一般情報を表示するには、V$RULE_SET動的パフォーマンス・ビューを問い合せます。この項で説明する問合せを実行すると、データベース内の各ルール・セットに関する次の情報が表示されます。

� ルール・セットの所有者。

� ルール・セット名。

� データベース・インスタンスが後に起動された後に実行されたルール・セット評価の合計数。

� データベース・インスタンスが後に起動されてから、ルールを評価するために SQL が実行された回数。一般的に、SQL を発行してルールを評価すると、発行しない場合よりコストが高くなります。

� データベース・インスタンスが後に起動されてから、SQL を発行せずに実行されたルール・セット評価の合計数。

� データベース・インスタンスが後に起動されてから、ルール・セットを使用してルール・エンジン・クライアントに戻された TRUEルールの合計数。

� データベース・インスタンスが後に起動されてから、ルール・セットを使用してルール・エンジン・クライアントに戻された MAYBEルールの合計数。

次の問合せを実行すると、データベース内の各ルール・セットに関する前述の情報が表示されます。

COLUMN OWNER HEADING 'Rule Set|Owner' FORMAT A9COLUMN NAME HEADING 'Rule Set|Name' FORMAT A11COLUMN EVALUATIONS HEADING 'Total|Evaluations' FORMAT 999999COLUMN SQL_EXECUTIONS HEADING 'SQL|Executions' FORMAT 999999COLUMN SQL_FREE_EVALUATIONS HEADING 'SQL Free|Evaluations' FORMAT 999999COLUMN TRUE_RULES HEADING 'True|Rules' FORMAT 999999COLUMN MAYBE_RULES HEADING 'Maybe|Rules' FORMAT 999999

SELECT OWNER,

注意注意注意注意 : センチセカンドは、100 分の 1 秒です。したがって、前述の出力では、CPU タイムが 1.79 秒、経過時間が 10.53 秒です。



NAME, EVALUATIONS, SQL_EXECUTIONS, SQL_FREE_EVALUATIONS, TRUE_RULES, MAYBE_RULES FROM V$RULE_SET;


Rule Set Rule Set Total SQL SQL Free True MaybeOwner Name Evaluations Executions Evaluations Rules Rules--------- ----------- ----------- ---------- ----------- ------- -------STRMADMIN RULESET$_18 403 0 403 0 200STRMADMIN RULESET$_9 3454 0 3454 5 64

各ルール・セットの評価に使用されたリソースの判断各ルール・セットの評価に使用されたリソースの判断各ルール・セットの評価に使用されたリソースの判断各ルール・セットの評価に使用されたリソースの判断データベース・インスタンスが後に起動された後のルール・セット評価に使用されたリソースを判断するには、V$RULE_SET動的パフォーマンス・ビューを問い合せます。データベース・インスタンスが後に起動されてからルール・セットが複数回評価されている場合、CPU タイム、評価時間、使用された共有メモリー（バイト）などの一部の統計は累積されます。

この項で説明する問合せを実行すると、データベース内の各ルール・セットに関する次の情報が表示されます。

� ルール・セットの所有者。

� ルール・セット名。

� データベース・インスタンスが後に起動された後のルール・セット評価に使用された合計 CPU タイム（秒）。

� データベース・インスタンスが後に起動された後のルール・セット評価に使用された合計時間（秒）。

� データベース・インスタンスが後に起動された後のルール・セット評価に使用された共有メモリーの合計量（バイト）。

次の問合せを実行すると、データベース内の各ルール・セットに関する前述の情報が表示されます。

COLUMN OWNER HEADING 'Rule Set|Owner' FORMAT A15COLUMN NAME HEADING 'Rule Set Name' FORMAT A15COLUMN CPU_SECONDS HEADING 'Seconds|of CPU|Time' FORMAT 999999.999COLUMN ELAPSED_SECONDS HEADING 'Seconds of|Evaluation|Time' FORMAT 999999.999COLUMN 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 BytesRule Set of CPU Evaluation of SharedOwner Rule Set Name Time Time Memory--------------- --------------- ----------- ----------- ----------STRMADMIN RULESET$_18 .840 8.550 444497STRMADMIN RULESET$_9 .700 1.750 444496

ルールの評価統計の表示ルールの評価統計の表示ルールの評価統計の表示ルールの評価統計の表示データベース・インスタンスが後に起動された後に実行された特定ルールの評価統計を表示するには、V$RULE動的パフォーマンス・ビューを問い合せます。この項で説明する問合せを実行すると、データベース内の各ルール・セットに関する次の情報が表示されます。

� データベース・インスタンスが後に起動されてから、ルールが TRUEと評価された合計回数。

� データベース・インスタンスが後に起動されてから、ルールが MAYBEと評価された合計回数。

� データベース・インスタンスが後に起動されてから、SQL を発行したルール評価の合計数。一般的に、SQL を発行してルールを評価すると、発行しない場合よりコストが高くなります。

たとえば、次の問合せを実行すると、strmadminスキーマの locations25ルールに関する前述の情報が表示されます。

COLUMN TRUE_RULES HEADING 'True Evaluations' FORMAT 999999COLUMN MAYBE_RULES HEADING 'Maybe Evaluations' FORMAT 999999COLUMN SQL_EVALUATIONS HEADING 'SQL Evaluations' FORMAT 999999

SELECT TRUE_HITS, MAYBE_HITS, SQL_EVALUATIONS FROM V$RULE WHERE RULE_OWNER = 'STRMADMIN' AND RULE_NAME = 'LOCATIONS25';


Streams 環境での互換性の監視

Streams 環境での互換性の監視環境での互換性の監視環境での互換性の監視環境での互換性の監視ここで説明する問合せを実行すると、ローカル・データベース内の表に対する Streams の互換性が表示されます。

� Streams と互換性のないデータベース・オブジェクトのリスト表示

� 近のリリースで Streams との互換性を持ったデータベース・オブジェクトのリスト表示

Streams と互換性のないデータベース・オブジェクトのリスト表示と互換性のないデータベース・オブジェクトのリスト表示と互換性のないデータベース・オブジェクトのリスト表示と互換性のないデータベース・オブジェクトのリスト表示取得プロセスでデータベース・オブジェクトに対する変更を取得できない場合は、そのデータベース・オブジェクトに Streams との互換性がありません。この項で説明する問合せを実行すると、Streams と互換性のないオブジェクトに関して次の情報が表示されます。

� オブジェクトの所有者

� オブジェクト名

� オブジェクトと Streams に互換性がない理由

� オブジェクトに対する変更が取得プロセスによって自動的にフィルタ処理で除外されるかどうか（AUTO_FILTERED列）

オブジェクトに対する変更が取得プロセスによって自動的にフィルタ処理で除外される場合は、取得プロセスでルール・セットを使用して明示的にフィルタ処理で除外する必要はありません。たとえば、マテリアライズド・ビュー・ログに対する変更は、取得プロセスによって自動的にフィルタ処理で除外されます。ただし、互換性のないオブジェクトに対する変更は自動的にフィルタ処理で除外されないため、エラーを回避するには、各取得プロセスでルール・セットを使用してフィルタ処理で除外する必要があります。

たとえば、取得プロセスでは、ルール・セットによって、特定のスキーマに対して行われたすべての変更を取得するように指示されているにもかかわらず、この項の問合せでは、このスキーマ内の 1 つのオブジェクトが Streams と互換性がなく、そのオブジェクトに対する変更が自動的にはフィルタ処理で除外されないことが示されている場合は、取得プロセスのネガティブ・ルール・セットにルールを追加して互換性のないオブジェクトに対する変更をフィルタ処理で除外できます。

AUTO_FILTERED列は、取得プロセスにのみ関連しています。Streams と互換性のないオブジェクトの AUTO_FILTERED列に YESを指定しても、適用プロセスでは、そのオブジェクトに対する変更をカプセル化する LCR は自動的にはフィルタ処理で除外されません。このような変更を適用プロセスでデキューすると、適用エラーが発生します。

Streams と互換性のない、ローカル・データベース内のオブジェクトをリスト表示するには、次の問合せを実行します。

COLUMN OWNER HEADING 'Object|Owner' FORMAT A8COLUMN TABLE_NAME HEADING 'Object Name' FORMAT A30COLUMN 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 AutoOwner Object Name Reason Filtered?-------- ------------------------------ ------------------------------ ---------HR MLOG$_COUNTRIES materialized view log YESHR MLOG$_DEPARTMENTS materialized view log YESHR MLOG$_EMPLOYEES materialized view log YESHR MLOG$_JOBS materialized view log YESHR MLOG$_JOB_HISTORY materialized view log YESHR MLOG$_LOCATIONS materialized view log YESHR MLOG$_REGIONS materialized view log YESIX AQ$_ORDERS_QUEUETABLE_G IOT with overflow NOIX AQ$_ORDERS_QUEUETABLE_H unsupported column exists NOIX AQ$_ORDERS_QUEUETABLE_I unsupported column exists NOIX AQ$_ORDERS_QUEUETABLE_S AQ queue table NOIX AQ$_ORDERS_QUEUETABLE_T AQ queue table NOIX ORDERS_QUEUETABLE column with user-defined type NOOE CATEGORIES_TAB column with user-defined type NOOE CUSTOMERS column with user-defined type NOOE PRODUCT_REF_LIST_NESTEDTAB column with user-defined type NOOE SUBCATEGORY_REF_LIST_NESTEDTAB column with user-defined type NOOE WAREHOUSES column with user-defined type NOPM ONLINE_MEDIA column with user-defined type NOPM PRINT_MEDIA column with user-defined type NOPM TEXTDOCS_NESTEDTAB column with user-defined type NOSH MVIEW$_EXCEPTIONS unsupported column exists NOSH SALES_TRANSACTIONS_EXT external table NO

oe.mlog$_ordersマテリアライズド・ビュー・ログの AUTO_FILTERED列に YESが指定されていることに注意してください。各取得プロセスは、ルール・セットによってこのオブジェクトに対する変更を取得するように指示されている場合でも、このオブジェクトに対する変更を自動的にフィルタ処理で除外します。

出力例に表示されている他のオブジェクトの AUTO_FILTERED列には NOが指定されているため、これらのオブジェクトは、取得プロセスによって自動的にはフィルタ処理で除外されません。取得プロセスで、これらのサポートされていないオブジェクトに対する LCR を処理しようとすると、エラーが発生します。ただし、これらのエラーは、これらのサポートされていないオブジェクトに対する変更を取得しないように取得プロセスに指示するルール・セットを構成して回避できます。



最近のリリースで最近のリリースで最近のリリースで最近のリリースで Streams との互換性を持ったデータベース・オブジェクとの互換性を持ったデータベース・オブジェクとの互換性を持ったデータベース・オブジェクとの互換性を持ったデータベース・オブジェクトのリスト表示トのリスト表示トのリスト表示トのリスト表示

この項で説明する問合せを実行すると、Oracle の近のリリースで Streams との互換性を持つようになったデータベース・オブジェクトに関する次の情報が表示されます。

� オブジェクトの所有者

� オブジェクト名

� Oracle の以前のリリースで、オブジェクトが Streams との互換性を持たなかった理由

� オブジェクトが Streams との互換性を持った Oracle のリリース

次の問合せを実行すると、ローカル・データベースに関して前述の情報が表示されます。

COLUMN OWNER HEADING 'Owner' FORMAT A10COLUMN TABLE_NAME HEADING 'Object Name' FORMAT A20COLUMN REASON HEADING 'Reason' FORMAT A30COLUMN 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.1OUTLN OL$ unsupported column exists 10.1SH CAL_MONTH_SALES_MV unsupported column exists 10.1SH FWEEK_PSCAT_SALES_MV unsupported column exists 10.1SH PLAN_TABLE unsupported column exists 10.1

注意注意注意注意 : この項で説明する問合せの結果は、データベースの互換レベルによって異なります。互換レベルが低くなると、Streams と互換性のないデータベース・オブジェクトの数が多くなります。データベースの互換レベルは、COMPATIBLE初期化パラメータによって制御されます。





Statspack を使用した Streams のパフォーマンスの監視

COMPATIBLE列には、Streams がオブジェクトをサポートするために必要なデータベースの小互換レベルが表示されます。ローカル・データベースの互換レベルがオブジェクトの

COMPATIBLE列の値以上である場合、取得プロセスおよび適用プロセスによって、オブジェクトへの変更が正常に処理されます。COMPATIBLE初期化パラメータで、Oracle データベースの互換性を制御します。

Streams 環境に、異なるバージョンの Oracle データベースを実行しているデータベースが含まれている場合は、LCR の GET_COMPATIBLEメンバー・ファンクションを使用して、特定のデータベースと互換性のない LCR をフィルタ処理で除外するルールを構成できます。取得プロセス、伝播および適用プロセスのルール・セットにこれらのルールを追加して、ストリーム内の必要な場所で、互換性のない LCR をフィルタ処理で除外できます。

Statspack を使用したを使用したを使用したを使用した Streams のパフォーマンスの監視のパフォーマンスの監視のパフォーマンスの監視のパフォーマンスの監視Statspack パッケージを使用して、Streams に関連するパフォーマンスの統計を監視できます。Statspack のインストール方法および使用方法に関する新の手順および情報は、データベースとともにインストールした spdoc.txtファイルに含まれています。Statspack については、このファイルを参照してください。このファイルは、UNIX システムでは、ORACLE_HOME/rdbms/adminディレクトリにあります。また、Windows システムでは、ORACLE_HOME¥rdbms¥adminディレクトリにあります。



� LCR の GET_COMPATIBLEメンバー・ファンクションを使用するルールの作成方法の詳細は、6-50 ページの「サポートされていない LCRを廃棄するように Streams クライアントに指示するルール条件」を参照してください。

� Streams と互換性のないオブジェクトの詳細は、14-68 ページの「Streams と互換性のないデータベース・オブジェクトのリスト表示」を参照してください。


Statspack を使用した Streams のパフォーマンスの監視


Streams 環境のトラブルシュ

15
Streams 環境のトラブルシューティング環境のトラブルシューティング環境のトラブルシューティング環境のトラブルシューティング
この章では、Streams 環境で一般的な問題を識別して解決する方法について説明します。


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

� 伝播に関する問題のトラブルシューティング

� 適用に関する問題のトラブルシューティング

� ルールおよびルールベースの変換に関する問題のトラブルシューティング

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

参照参照参照参照 : Streams レプリケーション環境のトラブルシューティングの詳細は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。

ーティング 15-1

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

取得に関する問題のトラブルシューティング取得に関する問題のトラブルシューティング取得に関する問題のトラブルシューティング取得に関する問題のトラブルシューティング取得プロセスで予期したとおりに変更が取得されない場合や、取得プロセスに他の問題が発生する場合は、次のチェックリストを使用して問題を識別し、解決します。

� 取得プロセスが有効化されているかどうか

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

� 必要な REDO ログ・ファイルが欠落していないかどうか

� ダウンストリーム取得プロセスが REDO ログ・ファイルを待機しているかどうか

� DBMS_STREAMS_ADM を使用してダウンストリーム取得を構成しているかどうか

� データベース・リンクなしのダウンストリーム取得に追加の操作が必要かどうか

取得プロセスが有効化されているかどうか取得プロセスが有効化されているかどうか取得プロセスが有効化されているかどうか取得プロセスが有効化されているかどうか変更が取得されるのは、取得プロセスが有効化されている場合のみです。取得プロセスが有効化されているか、無効化されているか、異常終了しているかは、DBA_CAPTUREデータ・ディクショナリ・ビューを問い合せるとチェックできます。

たとえば、取得プロセス CAPTUREが有効化されているかどうかをチェックするには、次の問合せを実行します。

SELECT STATUS FROM DBA_CAPTURE WHERE CAPTURE_NAME = 'CAPTURE';

取得プロセスが無効化されている場合、出力は次のようになります。

STATUS--------DISABLED

取得プロセスが無効化されている場合は、再起動します。取得プロセスが異常終了している場合は、再起動する前にエラーを解決する必要がある場合があります。取得プロセスが異常終了した理由を判断するには、DBA_CAPTUREデータ・ディクショナリ・ビューを問い合せるか、または取得プロセスのトレース・ファイルをチェックします。




� 14-5 ページの「Streams の取得プロセスの監視」



次の問合せを実行すると、取得プロセスが異常終了した時間および異常終了の原因となったエラーが表示されます。

COLUMN CAPTURE_NAME HEADING 'Capture|Process|Name' FORMAT A10COLUMN STATUS_CHANGE_TIME HEADING 'Abort Time'COLUMN ERROR_NUMBER HEADING 'Error Number' FORMAT 99999999COLUMN ERROR_MESSAGE HEADING 'Error Message' FORMAT A40

SELECT CAPTURE_NAME, STATUS_CHANGE_TIME, ERROR_NUMBER, ERROR_MESSAGE FROM DBA_CAPTURE WHERE STATUS='ABORTED';

現行の取得プロセスかどうか現行の取得プロセスかどうか現行の取得プロセスかどうか現行の取得プロセスかどうか取得プロセスで近の変更が取得されていない場合は、遅延が原因となっていることがあります。遅延の有無をチェックするには、V$STREAMS_CAPTURE動的パフォーマンス・ビューを問い合せます。取得プロセスの待機時間が長い場合は、parallelism取得プロセス・パラメータの設定を調整すると、パフォーマンスを改善できることがあります。


� 9-24 ページの「取得プロセスの起動」

� 15-25 ページの「トレース・ファイルとアラート・ログでの問題のチェック」

� Oracle Real Application Clusters 環境で取得プロセスを再起動する方法については、2-24 ページの「Streams の取得プロセスと Oracle Real Application Clusters」を参照してください。


� 14-16 ページの「各取得プロセスに関する REDO ログのスキャン待機時間の判断」

� 14-17 ページの「各取得プロセスに関するイベントのエンキュー待機時間の判断」

� 2-43 ページの「取得プロセスの並列性」


Streams 環境のトラブルシューティング 15-3


必要な必要な必要な必要な REDO ログ・ファイルが欠落していないかどうかログ・ファイルが欠落していないかどうかログ・ファイルが欠落していないかどうかログ・ファイルが欠落していないかどうか取得プロセスを起動または再起動する場合、開始 SCN を含むログ・ファイルの前に生成された REDO ログ・ファイルをスキャンする必要があります。取得プロセスでは、これらのレコードをスキャンして、データベース・オブジェクトに対して行った DDL 変更を追跡する必要があります。取得プロセスの先頭 SCN および開始 SCN を判別するには、DBA_CAPTUREデータ・ディクショナリ・ビューを問い合せます。必要な REDO ログ・ファイルを取得プロセスでスキャンする前に削除すると、取得プロセスが異常終了し、取得プロセスのトレース・ファイルで次のエラーが発生します。

ORA-01291: ログ・ファイルがありません。

このエラーが表示された場合は、欠落している REDO ログ・ファイルをリストアして取得プロセスを再起動します。V$LOGMNR_LOGS動的パフォーマンス・ビューを調べて、欠落している SCN の範囲を確認し、関連する REDO ログ・ファイルを追加できます。取得プロセスには、必須チェックポイント SCN が含まれる REDO ログ・ファイルおよびすべての後続の REDO ログ・ファイルが必要です。DBA_CAPTUREデータ・ディクショナリ・ビューのREQUIRED_CHECKPOINT_SCN列を問い合せて、取得プロセスの必須チェックポイントSCN を判別することができます。

ダウンストリーム取得プロセスがダウンストリーム取得プロセスがダウンストリーム取得プロセスがダウンストリーム取得プロセスが REDO ログ・ファイルを待機しているかログ・ファイルを待機しているかログ・ファイルを待機しているかログ・ファイルを待機しているかどうかどうかどうかどうか

ダウンストリーム取得プロセスによって変更が取得されない場合は、スキャンする REDOログ・ファイルを待機している場合があります。REDO ログ・ファイルは、ダウンストリーム取得プロセスに暗黙的または明示的に登録されている場合があります。REDO ログ・ファイルが暗黙的に登録されている場合は、通常、REDO ログ・ファイルがログ転送サービスによってソース・データベースからダウンストリーム・データベースに送信されます。REDOログ・ファイルが明示的に登録されている場合は、手動で REDO ログ・ファイルをダウンストリーム・データベースに送信し、ダウンストリーム取得プロセスに登録する必要があります。いずれの場合も、ダウンストリーム取得プロセスにソース・データベースへの変更を取得させるには、適切な REDO ログ・ファイルをダウンストリーム取得プロセスに登録する必要があります。

ダウンストリーム取得プロセスが REDO ログ・ファイルを待機しているかどうかを判断するには、V$STREAMS_CAPTURE動的パフォーマンス・ビューを問い合せます。たとえば、ダウンストリーム取得プロセス strm05_captureに対して次の問合せを実行します。

SELECT STATE FROM V$STREAMS_CAPTURE WHERE CAPTURE_NAME='STRM05_CAPTURE';



� 14-9 ページの「各取得プロセスの登録済 REDO ログ・ファイルの表示」



取得プロセスの状態が WAITING FOR DICTIONARY REDOまたは WAITING FOR REDOのいずれかの場合、REDO ログ・ファイルがダウンストリーム取得プロセスに登録されていることを確認するには、DBA_REGISTERED_ARCHIVED_LOGおよび DBA_CAPTUREデータ・ディクショナリ・ビューを問い合せます。たとえば、次の問合せを実行すると、現在strm05_captureダウンストリーム取得プロセスに登録されている REDO ログ・ファイルがリスト表示されます。

COLUMN SOURCE_DATABASE HEADING 'Source|Database' FORMAT A15COLUMN SEQUENCE# HEADING 'Sequence|Number' FORMAT 9999999COLUMN NAME HEADING 'Archived Redo Log|File Name' FORMAT A30COLUMN DICTIONARY_BEGIN HEADING 'Dictionary|Build|Begin' FORMAT A10COLUMN 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 ログ・ファイルがソース・データベースからダウンストリーム・データベースに送信されるように構成した場合は、ログ転送サービスが適切に構成されていることを確認します。ログ転送サービスを適切に構成した後、ソース・データベースで ALTER SYSTEM ARCHIVE LOG CURRENT文を実行してログ・ファイルをアーカイブします。ログ転送サービスによってログ・ファイルが送信されるように構成しなかった場合は、ログ・ファイルの送信および登録に使用しているメソッドが適切に動作していることを確認します。ログ・ファイルは、ALTER DATABASE REGISTER LOGICAL LOGFILE文を使用して明示的に登録できます。

また、ダウンストリーム取得プロセスを使用して履歴データに対する変更を取得する場合は、さらに次の項目について考慮します。

� REDO ログ・ファイルを生成するソース・データベースとダウンストリーム取得プロセスを実行するデータベースの両方が Oracle Database 10g データベースである必要があります。

� 作成されたデータ・ディクショナリの先頭が、も早く追加された REDO ログに存在している必要があります。また、取得プロセスが、作成されたデータ・ディクショナリの先頭と一致する先頭 SCN で構成されている必要があります。

� 取得プロセスによって変更を取得されるデータベース・オブジェクトが、ダウンストリーム・データベースではなく、ソース・データベースでインスタンス化のために準備されている必要があります。また、インスタンス化のためにオブジェクトを準備する場合、過去の時刻は指定できません。オブジェクトは、常に、現行のデータベース SCNでインスタンス化のために準備されるため、取得プロセスでは、インスタンス化のため



にオブジェクトを準備した後に発生したデータベース・オブジェクトへの変更のみを取得できます。

DBMS_STREAMS_ADM を使用してダウンストリーム取得を構成しているかを使用してダウンストリーム取得を構成しているかを使用してダウンストリーム取得を構成しているかを使用してダウンストリーム取得を構成しているかどうかどうかどうかどうか

ダウンストリーム取得プロセスを作成するには、DBMS_CAPTURE_ADMパッケージのCREATE_CAPTUREプロシージャを使用する必要があります。DBMS_STREAMS_ADMパッケージのプロシージャを使用して取得プロセスを作成する場合、ローカル・データベースのグローバル名と一致しないソース・データベース名を指定すると、次のエラーが戻されます。

ORA-26678: 初にストリーム取得プロセスを作成する必要があります

この問題を解決するには、DBMS_CAPTURE_ADMパッケージの CREATE_CAPTUREプロシージャを使用してダウンストリーム取得プロセスを作成します。

DBMS_STREAMS_ADMパッケージのプロシージャを使用してローカルの取得プロセスを作成しているときにこのエラーが発生した場合は、実行しているプロシージャのsource_databaseパラメータに指定されているデータベース名がローカル・データベースのグローバル名と一致していることを確認します。

データベース・リンクなしのダウンストリーム取得に追加の操作が必要かデータベース・リンクなしのダウンストリーム取得に追加の操作が必要かデータベース・リンクなしのダウンストリーム取得に追加の操作が必要かデータベース・リンクなしのダウンストリーム取得に追加の操作が必要かどうかどうかどうかどうか

ダウンストリーム取得がデータベース・リンク付きで構成されている場合は、そのデータベース・リンクを使用してソース・データベースでの操作を実行し、ソース・データベースから情報を自動的に取得できます。ダウンストリーム取得がデータベース・リンクなしで構成されている場合は、これらの操作を手動で実行して、情報を手動で取得する必要があります。これらの操作を手動で実行しないでダウンストリーム取得プロセスを作成しようとすると、エラーが発生します。





� 9-17 ページの「ログ・ファイルを明示的に割り当てるダウンストリーム取得プロセスの作成」

参照参照参照参照 : 9-2 ページの「取得プロセスの作成」


伝播に関する問題のトラブルシューティング

具体的には、データベース・リンクなしでダウンストリーム取得を構成した場合、次の操作を手動で実行する必要があります。

� 特定の状況では、ソース・データベースで DBMS_CAPTURE_ADM.BUILDプロシージャを実行して、取得プロセスの作成時にソース・データベースのデータ・ディクショナリを REDO ログに抽出する必要があります。

� ソース・データベース・オブジェクトをインスタンス化のために準備する必要があります。

� DBMS_CAPTURE_ADMパッケージの CREATE_CAPTUREプロシージャを使用して取得プロセスを作成する場合は、ダウンストリーム取得プロセスの先頭 SCN を取得し、first_scnを使用して先頭 SCN を指定する必要があります。

伝播に関する問題のトラブルシューティング伝播に関する問題のトラブルシューティング伝播に関する問題のトラブルシューティング伝播に関する問題のトラブルシューティング伝播で予期したとおりに変更が伝播されない場合は、次のチェックリストを使用して伝播の問題を識別して解決します。

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

� 伝播で使用される伝播ジョブが有効化されているか

� 十分な数のジョブ・キュー・プロセスがあるか

� SYS.AnyData キューのセキュリティは適切に構成されているか

伝播には適切なソース・キューと宛先キューが使用されているか伝播には適切なソース・キューと宛先キューが使用されているか伝播には適切なソース・キューと宛先キューが使用されているか伝播には適切なソース・キューと宛先キューが使用されているか伝播の宛先キューにイベントが予期したとおりに表示されない場合、その伝播は適切なソース・キューから適切な宛先キューにイベントを伝播させるように構成されていない可能性があります。

たとえば、伝播 dbs1_to_dbs2のソース・キューと宛先キューをチェックするには、次の問合せを実行します。

COLUMN SOURCE_QUEUE HEADING 'Source Queue' FORMAT A35COLUMN DESTINATION_QUEUE HEADING 'Destination Queue' FORMAT A35

参照参照参照参照 : 9-12 ページの「データベース・リンクを使用しないダウンストリーム取得プロセスの作成」




� 14-24 ページの「Streams 伝播および伝播ジョブの監視」



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.STREAMS_QUEUE@DBS1.NET [email protected]

伝播に適切なキューが使用されていない場合は、新規の伝播を作成してください。既存の伝播が環境に適切でない場合は、その削除が必要になることがあります。

伝播で使用される伝播ジョブが有効化されているか伝播で使用される伝播ジョブが有効化されているか伝播で使用される伝播ジョブが有効化されているか伝播で使用される伝播ジョブが有効化されているか伝播ジョブでイベントを伝播させるには、その伝播ジョブの伝播スケジュールを有効化する必要があります。伝播でイベントが予期したとおりに伝播されていない場合は、この伝播の伝播ジョブ・スケジュールが有効化されていない可能性があります。

この項で説明する問合せを実行すると、伝播ジョブのスケジュールに関する次の情報を検索できます。

� ソース・キューから宛先キューへのイベントの伝播に使用されたデータベース・リンク。

� 伝播スケジュールが有効化されているか、無効化されているか。

� 終イベントの伝播に使用されたジョブ・キュー・プロセス。

� 伝播スケジュールの実行が試行されたときの連続失敗回数。この数が 16 に達すると、スケジュールは自動的に無効化されます。

� 伝播エラーがある場合は、後のエラーの発生時刻。

� 伝播エラーがある場合は、後のエラーのエラー・メッセージ。

たとえば、伝播 dbs1_to_dbs2で使用される伝播ジョブが有効化されているかどうかをチェックするには、次の問合せを実行します。

COLUMN DESTINATION_DBLINK HEADING 'Destination|DB Link' FORMAT A15COLUMN SCHEDULE_DISABLED HEADING 'Schedule' FORMAT A8COLUMN PROCESS_NAME HEADING 'Process' FORMAT A7

参照参照参照参照 : 10-7 ページの「伝播の作成」



COLUMN FAILURES HEADING 'Number of|Failures' FORMAT 9999COLUMN LAST_ERROR_TIME HEADING 'Last Error Time' FORMAT A15COLUMN LAST_ERROR_MSG HEADING 'Last Error Message' FORMAT A18

SELECT p.DESTINATION_DBLINK, DECODE(s.SCHEDULE_DISABLED, 'Y', 'Disabled', 'N', 'Enabled') SCHEDULE_DISABLED, s.PROCESS_NAME, s.FAILURES, s.LAST_ERROR_TIME, s.LAST_ERROR_MSG FROM DBA_QUEUE_SCHEDULES s, DBA_PROPAGATION p WHERE p.PROPAGATION_NAME = 'DBS1_TO_DBS2' AND p.DESTINATION_DBLINK = s.DESTINATION AND s.SCHEMA = p.SOURCE_QUEUE_OWNER AND s.QNAME = p.SOURCE_QUEUE_NAME;

この伝播ジョブのスケジュールが現在は有効化されている場合、出力は次のようになります。

Destination Number ofDB Link Schedule Process Failures Last Error Time Last Error Message--------------- -------- ------- --------- --------------- ------------------DBS2.NET Enabled J001 0

問題が発生した場合は、その問題を解決するために次の操作を行います。

� 伝播ジョブが無効化されていて、まだ DBMS_AQADMパッケージのENABLE_PROPAGATION_SCHEDULEプロシージャを実行していない場合は、このプロシージャを使用して有効化できます。

� 伝播ジョブが無効化されており、その原因が不明の場合は、イベントを後に伝播したプロセスのトレース・ファイルをチェックします。前述の出力では、このプロセスはJ001です。

� 伝播ジョブは有効化されているが、イベントを伝播していない場合は、そのスケジュールを解除してから再設定してください。



十分な数のジョブ・キュー・プロセスがあるか十分な数のジョブ・キュー・プロセスがあるか十分な数のジョブ・キュー・プロセスがあるか十分な数のジョブ・キュー・プロセスがあるか伝播ジョブでは、ジョブ・キュー・プロセスを使用してイベントが伝播されます。伝播を実行する各データベース・インスタンス内で、JOB_QUEUE_PROCESSES初期化パラメータが2以上に設定されていることを確認してください。同時に実行されるすべてのジョブに十分に対応できる値に設定する必要があります。

SYS.AnyData キューのセキュリティは適切に構成されているかキューのセキュリティは適切に構成されているかキューのセキュリティは適切に構成されているかキューのセキュリティは適切に構成されているかSYS.AnyDataキューは保護キューであり、ユーザーがその操作を実行できるようにセキュリティを適切に構成する必要があります。DBMS_STREAMS_ADMパッケージのSET_UP_QUEUEプロシージャを使用して保護キュー SYS.AnyDataを構成する場合、SET_UP_QUEUEが作成しようとするエージェントがすでに存在し、このプロシージャのqueue_userで指定されているユーザー以外のユーザーに関連付けられていると、エラーが発生します。この場合は、DBMS_AQADMパッケージの ALTER_AQ_AGENTまたはDROP_AQ_AGENTプロシージャを使用して、それぞれ既存のエージェントの名前を変更するか、削除する必要があります。次に、SET_UP_QUEUEを再試行してください。


� 10-10 ページの「伝播ジョブの有効化」


� 10-12 ページの「伝播ジョブのスケジュール解除」

� 10-11 ページの「伝播ジョブのスケジューリング」

� 14-26 ページの「伝播ジョブのスケジュールの表示」



� 伝播ジョブを使用する場合の JOB_QUEUE_PROCESSES初期化パラメータ設定の詳細は、『Oracle Streams アドバンスト・キューイング・ユーザーズ・ガイドおよびリファレンス』の伝播機能の説明を参照してください。

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

� ジョブ・キューの詳細は、『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。



また、SYS.AnyDataキューのセキュリティが適切に構成されていないと、次のいずれかのエラーが発生する可能性があります。

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

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

ORA-24093: AQ エージェントはデータベース・ユーザーの権限を付与さエージェントはデータベース・ユーザーの権限を付与さエージェントはデータベース・ユーザーの権限を付与さエージェントはデータベース・ユーザーの権限を付与されていません。れていません。れていません。れていません。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 OEAPPLY_OE OEEXPLICIT_DQ OE

参照参照参照参照 : 3-17 ページの「保護キュー」

参照参照参照参照 : エージェントに対する権限付与の詳細例については、10-3 ページの「保護キューでのユーザー操作の有効化」を参照してください。


適用に関する問題のトラブルシューティング

ORA-25224: 保護キューにエンキューするために送信者名を指定する必要保護キューにエンキューするために送信者名を指定する必要保護キューにエンキューするために送信者名を指定する必要保護キューにエンキューするために送信者名を指定する必要があります。があります。があります。があります。保護キューにエンキューするには、メッセージ・プロパティで SENDER_IDをそのキューに対する保護キュー権限を持つ AQ エージェントに設定する必要があります。

適用に関する問題のトラブルシューティング適用に関する問題のトラブルシューティング適用に関する問題のトラブルシューティング適用に関する問題のトラブルシューティング適用プロセスで予期したとおりに変更が適用されない場合は、次のチェックリストを使用して適用の問題を識別して解決します。

� 適用プロセスが有効化されているかどうか

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

� 適用プロセスで取得イベントとユーザー・エンキュー・イベントのどちらが適用されるか

� 適用するイベントを適用プロセスのキューが受信しているか

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

� AQ_TM_PROCESSES 初期化パラメータが 0（ゼロ）に設定されていないかどうか

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

適用プロセスが有効化されているかどうか適用プロセスが有効化されているかどうか適用プロセスが有効化されているかどうか適用プロセスが有効化されているかどうか変更が適用されるのは、適用プロセスが有効化されている場合のみです。適用プロセスが有効化されているか、無効化されているか、異常終了しているかは、DBA_APPLYデータ・ディクショナリ・ビューを問い合せるとチェックできます。

たとえば、適用プロセス APPLYが有効化されているかどうかをチェックするには、次の問合せを実行します。

SELECT STATUS FROM DBA_APPLY WHERE APPLY_NAME = 'APPLY';

参照参照参照参照 : エンキュー用の SENDER_IDの設定例については、10-19 ページの「SYS.AnyData ラッパーでのユーザー・メッセージ・ペイロードのラップおよびエンキュー」を参照してください。




� 14-29 ページの「Streams の適用プロセスの監視」



適用プロセスが無効化されている場合、出力は次のようになります。

STATUS--------DISABLED

適用プロセスが無効化されている場合は、再起動します。適用プロセスが異常終了している場合は、再起動する前にエラーを解決する必要がある場合があります。適用プロセスが異常終了した理由を判断するには、DBA_APPLYデータ・ディクショナリ・ビューを問い合せるか、または適用プロセスのトレース・ファイルをチェックします。

次の問合せを実行すると、適用プロセスが異常終了した時間および異常終了の原因となったエラーが表示されます。

COLUMN APPLY_NAME HEADING 'APPLY|Process|Name' FORMAT A10COLUMN STATUS_CHANGE_TIME HEADING 'Abort Time'COLUMN ERROR_NUMBER HEADING 'Error Number' FORMAT 99999999COLUMN ERROR_MESSAGE HEADING 'Error Message' FORMAT A40

SELECT APPLY_NAME, STATUS_CHANGE_TIME, ERROR_NUMBER, ERROR_MESSAGE FROM DBA_APPLY WHERE STATUS='ABORTED';

現行の適用プロセスかどうか現行の適用プロセスかどうか現行の適用プロセスかどうか現行の適用プロセスかどうか適用プロセスで近の変更が適用されていない場合は、遅延が原因となっていることがあります。適用プロセスの待機時間は、V$STREAMS_APPLY_COORDINATOR動的パフォーマンス・ビューを問い合せてチェックできます。適用プロセスの待機時間が長い場合は、parallelism適用プロセス・パラメータの設定を調整すると、パフォーマンスを改善できることがあります。


� 11-9 ページの「適用プロセスの起動」



� Oracle Real Application Clusters 環境で適用プロセスを再起動する方法については、4-11 ページの「Streams の適用プロセスと Oracle Real Application Clusters」を参照してください。



適用プロセスで取得イベントとユーザー・エンキュー・イベントのどちら適用プロセスで取得イベントとユーザー・エンキュー・イベントのどちら適用プロセスで取得イベントとユーザー・エンキュー・イベントのどちら適用プロセスで取得イベントとユーザー・エンキュー・イベントのどちらが適用されるかが適用されるかが適用されるかが適用されるか

適用プロセスで適用できるのは、取得イベントまたはユーザー・エンキュー・イベントのどちらか一方のみです。両方は適用できません。適用プロセスが特定の型のイベントを適用していない場合は、他の型のイベントを適用するように構成されていることが原因の可能性があります。適用プロセスで適用されるイベントの型は、DBA_APPLYデータ・ディクショナリ・ビューを問い合せてチェックできます。

たとえば、適用プロセス APPLYで取得イベントとユーザー・エンキュー・イベントのどちらが適用されるかをチェックするには、次の問合せを実行します。

COLUMN APPLY_CAPTURED HEADING 'Type of Events Applied' FORMAT A25

SELECT DECODE(APPLY_CAPTURED, 'YES', 'Captured', 'NO', 'User-Enqueued') APPLY_CAPTURED FROM DBA_APPLY WHERE APPLY_NAME = 'APPLY';

適用プロセスで取得イベントが適用される場合、出力は次のようになります。

Type of Events Applied-------------------------Captured

適用プロセスで予期した型のイベントが適用されていない場合は、その型のイベントを適用する新規適用プロセスの作成が必要になることがあります。


� 14-38 ページの「各適用プロセスのイベントが取得されてから適用されるまでの待機時間の判断」

� 4-17 ページの「適用プロセスの並列性」



� 3-3 ページの「取得イベントとユーザー・エンキュー・イベント」




適用するイベントを適用プロセスのキューが受信しているか適用するイベントを適用プロセスのキューが受信しているか適用するイベントを適用プロセスのキューが受信しているか適用するイベントを適用プロセスのキューが受信しているか適用プロセスでは、キュー内でイベントを受信しなければ、そのイベントを適用できません。したがって、適用プロセスで取得イベントを適用している場合は、そのイベントを取得する取得プロセスを有効化し、適切に構成する必要があります。同様に、イベントが適用プロセスに到達する前に 1 つ以上のデータベースから伝播される場合は、各伝播を有効化し、適切に構成する必要があります。適用プロセスが依存する取得プロセスまたは伝播が有効化されていないか、または適切に構成されていないと、イベントが適用プロセスのキューに到達しない可能性があります。

適用プロセスおよび伝播を含むすべての Streams クライアントで使用されるルール・セットによって、これらの Streams クライアントの動作が決定されます。したがって、適用プロセスが依存する取得プロセスまたは伝播に適切なルールが含まれていることを確認してください。これらの Streams クライアントのルールが適切に構成されていない場合、適用プロセスのキューは適切なイベントを受信しない可能性があります。また、ストリームを介して送受信されるイベントは、パスに沿って実行されたすべての変換で構成されます。たとえば、イベントの取得中に取得プロセスがサブセット・ルールを使用して行の移行を実行し、伝播がイベントにルールベースの変換を実行して表の名前を変更した場合、イベントが適用プロセスに到達したときに、適用プロセスのルールでこれらの変換を考慮する必要があります。

取得プロセスが複数のデータベースに伝播されて適用される変更を取得する環境では、次のガイドラインに従って、問題の原因は適用プロセスが依存する取得プロセスや伝播にあるのか、または適用プロセス自体にあるのかを判断できます。

� 取得プロセスの他の接続先データベースがその取得プロセスからの変更を適用していない場合、問題の原因はおそらく取得プロセスまたはその取得プロセス付近の伝播にあると思われます。この場合、まず取得プロセスが有効化され適切に構成されていることを確認し、次にその取得プロセスにも近い伝播が有効化され適切に構成されていることを確認します。

� 取得プロセスの他の接続先データベースがその取得プロセスからの変更を適用している場合、おそらく問題の原因は適用プロセス自体にあるか、その適用プロセス付近の伝播にあると思われます。この場合、まず適用プロセスが有効化され適切に構成されていることを確認し、次にその適用プロセスにも近い伝播が有効化され適切に構成されていることを確認します。


� 15-2 ページの「取得に関する問題のトラブルシューティング」

� 15-7 ページの「伝播に関する問題のトラブルシューティング」

� 15-17 ページの「ルールおよびルールベースの変換に関する問題のトラブルシューティング」



カスタム適用ハンドラが指定されているかどうかカスタム適用ハンドラが指定されているかどうかカスタム適用ハンドラが指定されているかどうかカスタム適用ハンドラが指定されているかどうかPL/SQL プロシージャを使用すると、適用プロセスでデキューされるイベントをカスタマイズされた方法で処理できます。このようなハンドラには、DML ハンドラ、DDL ハンドラ、プリコミット・ハンドラおよびメッセージ・ハンドラがあります。適用プロセスが予期したとおりに動作していない場合は、その適用プロセスで使用されるハンドラ・プロシージャをチェックして、不備を訂正します。これらのプロシージャの名前は、DBA_APPLY_DML_HANDLERSおよび DBA_APPLYデータ・ディクショナリ・ビューを問い合せて検索できます。適用に関する問題を解決するには、ハンドラ・プロシージャの変更または削除が必要になることがあります。

AQ_TM_PROCESSES 初期化パラメータが初期化パラメータが初期化パラメータが初期化パラメータが 0（ゼロ）に設定されていないかど（ゼロ）に設定されていないかど（ゼロ）に設定されていないかど（ゼロ）に設定されていないかどうかうかうかうか

適用プロセス・ルール・セットに準拠しているイベントが適用プロセス・キューに存在しているにもかかわらず、適用プロセスによってイベントが適用されていない場合は、接続先データベースで AQ_TM_PROCESSES初期化パラメータが 0（ゼロ）に設定されていないかどうかを確認します。このパラメータが 0（ゼロ）に設定されている場合は、その設定を解除するか、または 0（ゼロ）以外の値を設定し、イベントの適用が開始されるかどうかを確認するために適用プロセスを監視します。

AQ_TM_PROCESSES初期化パラメータは、キュー・メッセージに対する時間の監視、および遅延プロパティと期限切れプロパティが指定されたメッセージの処理を制御します。Oracle Database 10g では、AQ_TM_PROCESSES初期化パラメータが設定されていない場合、データベースでこれらのアクションが自動的に制御されます。

バッファ・キューに取得されたイベントが存在するかどうかを確認するには、V$BUFFERED_QUEUESおよび V$BUFFERED_SUBSCRIBERS動的パフォーマンス・ビューを問い合せます。キューにユーザー・エンキュー・イベントが存在するかどうかを確認するには、キュー用のキュー表を問い合せます。


� 適用ハンドラの概要は、4-4 ページの「適用プロセスによるイベント処理オプション」を参照してください。

� 適用ハンドラの管理については、第 11 章「適用プロセスの管理」を参照してください。

� 適用ハンドラに関する情報を表示する問合せについては、14-32 ページの「適用ハンドラに関する情報の表示」を参照してください。


ルールおよびルールベースの変換に関する問題のトラブルシューティング

エラー・キューに適用エラーがあるかエラー・キューに適用エラーがあるかエラー・キューに適用エラーがあるかエラー・キューに適用エラーがあるか適用プロセスでイベントが適用できない場合は、そのイベントおよび同じトランザクション内の他のすべてのイベントが、エラー・キューに移動します。適用エラーを定期的にチェックして、適用できなかったトランザクションの有無を確認する必要があります。適用エラーの有無は、DBA_APPLY_ERRORデータ・ディクショナリ・ビューを問い合せてチェックできます。また、エラー・キューまたはエラー・キュー内のすべてのトランザクションから、特定のトランザクションを再実行できます。

ルールおよびルールベースの変換に関する問題のトラブルルールおよびルールベースの変換に関する問題のトラブルルールおよびルールベースの変換に関する問題のトラブルルールおよびルールベースの変換に関する問題のトラブルシューティングシューティングシューティングシューティング

取得プロセス、伝播、適用プロセスまたはメッセージ・クライアントが予期したとおりに動作しない場合は、Streams クライアントのルールまたはルールベースの変換が適切に構成されていないことが問題となっている可能性があります。次のチェックリストを使用し、ルールおよびルールベースの変換の問題を識別して解決します。

� ルールは Streams クライアント用に適切に構成されているか

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


� 14-23 ページの「キュー内のユーザー・エンキュー・イベントの内容の表示」

� バッファ・キューを監視する方法の詳細は、『Oracle Streams レプリケーション管理者ガイド』を参照してください。

� AQ_TM_PROCESSES初期化パラメータについては、『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドおよびリファレンス』を参照してください。










ルールはルールはルールはルールは Streams クライアント用に適切に構成されているかクライアント用に適切に構成されているかクライアント用に適切に構成されているかクライアント用に適切に構成されているか取得プロセス、伝播、適用プロセスまたはメッセージ・クライアントが予期したとおりに動作しない場合は、Streams クライアントのポジティブ・ルール・セットまたはネガティブ・ルール・セットのいずれかのルールが適切に構成されていないことが問題となっている可能性があります。たとえば、取得プロセスで特定の表に対する変更が取得されることを予期していたが、取得プロセスによってこれらの変更が取得されない場合は、取得プロセスで使用されるルール・セット内のルールが、表に対する変更を取得するように取得プロセスに指示していないことが原因となっている可能性があります。

特定の Streams クライアントのルールをチェックするには、DBA_STREAMS_RULESデータ・ディクショナリ・ビューを問い合せます。Streams 環境でポジティブ・ルール・セットとネガティブ・ルール・セットの両方を使用する場合、このビューで戻されるルールが、特定のStreams クライアントのポジティブ・ルール・セットまたはネガティブ・ルール・セットのどちらに含まれるかを知っておくことが重要です。Streams クライアントは、そのルール・セットを満たすイベントに対して取得、伝播、適用、デキューなどのアクションを実行します。通常、イベントについて TRUEと評価されるルールがネガティブ・ルール・セットに含まれず、ポジティブ・ルール・セットに 1 つ以上含まれる場合、そのイベントは Streams クライアントのルール・セットを満たしていることになります。イベントが Streams クライアントのルール・セットを満たす場合の詳細（1 つ以上のルール・セットが指定されていない場合の Streams クライアントの動作も含む）は、6-4 ページの「ルール・セットとイベントのルール評価」を参照してください。


� スキーマ・ルールとグローバル・ルールのチェック

� 表ルールのチェック

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

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

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

スキーマ・ルールとグローバル・ルールのチェックスキーマ・ルールとグローバル・ルールのチェックスキーマ・ルールとグローバル・ルールのチェックスキーマ・ルールとグローバル・ルールのチェックStreams クライアントのポジティブ・ルール・セットに含まれるスキーマ・ルールとグローバル・ルールは、それぞれ特定のスキーマまたはデータベースに関連するすべてのイベントに対するタスクを実行するように Streams クライアントに指示します。Streams クライアントのネガティブ・ルール・セットに含まれるスキーマ・ルールとグローバル・ルールは、それぞれ特定のスキーマまたはデータベースに関連するすべてのイベントを廃棄するようにStreams クライアントに指示します。Streams クライアントが予期したとおりに動作してい


� 14-51 ページの「ルールおよびルールベースの変換の監視」

� 6-4 ページの「ルール・セットとイベントのルール評価」



ない場合は、スキーマ・ルールまたはグローバル・ルールが Streams クライアント用に適切に構成されていないことが原因である可能性があります。

たとえば、データベースで適用プロセス strm01_applyが実行され、この適用プロセスでhrスキーマに対する変更を含む LCR を適用すると想定します。適用プロセスでネガティブ・ルール・セットを使用する場合は、このスキーマに対して TRUEと評価されるスキーマ・ルールがネガティブ・ルール・セットに含まれないことを確認します。このようなルールが含まれると、スキーマに対する変更を含む LCR が適用プロセスで廃棄される可能性があります。このようなルールを表示する問合せの例は、14-56 ページの「Streams クライアント用のネガティブ・ルール・セット内のルールの判別」を参照してください。

この問合せを実行してこのようなルールが戻された場合、スキーマに対する変更が適用プロセスによって廃棄される可能性があります。この問合せを実行しても行が戻されない場合は、このスキーマに対して TRUEと評価されるスキーマ・ルールが適用プロセスのポジティブ・ルール・セットに含まれていることを確認してください。このようなルールを表示する問合せの例は、14-55 ページの「Streams クライアント用のポジティブ・ルール・セット内のルールの判別」を参照してください。

表ルールのチェック表ルールのチェック表ルールのチェック表ルールのチェックStreams クライアントのポジティブ・ルール・セットに含まれる表ルールは、1 つ以上の特定の表に関連するイベントに対するタスクを実行するように Streams クライアントに指示します。Streams クライアントのネガティブ・ルール・セットに含まれる表ルールは、1 つ以上の特定の表に関連するイベントを廃棄するように Streams クライアントに指示します。

Streams クライアントが特定の表に対して予期したとおりに動作しない場合は、次のいずれかの原因が考えられます。

� 表が特定のデータベースに含まれているため、Streams クライアントのルール・セットに含まれる 1 つ以上のグローバル・ルールが、表に関連するイベントに対して特定の方法で動作するように Streams クライアントに指示しています。Streams クライアントのネガティブ・ルール・セットに含まれるグローバル・ルールが、表を含むソース・データベースからのすべてのイベントを廃棄するように Streams クライアントに指示しているか、または Streams クライアントのポジティブ・ルール・セットに含まれるグローバル・ルールが、表を含むソース・データベースからのすべてのイベントに対するタスクを実行するように Streams クライアントに指示している可能性があります。

� 表が特定のスキーマに含まれているため、Streams クライアントのルール・セットに含まれる 1 つ以上のスキーマ・ルールが、表に関連するイベントに対して特定の方法で動作するように Streams クライアントに指示しています。Streams クライアントのネガティブ・ルール・セットに含まれるスキーマ・ルールが、スキーマ内のデータベース・オブジェクトに関連するすべてのイベントを廃棄するように Streams クライアントに指示しているか、または Streams クライアントのポジティブ・ルール・セットに含まれるスキーマ・ルールが、スキーマ内のデータベース・オブジェクトに関連するすべてのイベントに対するタスクを実行するように Streams クライアントに指示している可能性があります。



� Streams クライアントのルール・セットに含まれる 1 つ以上の表ルールが、表に関連するイベントに対して特定の方法で動作するように Streams クライアントに指示しています。

予期しない動作の原因がグローバル・ルールまたはスキーマ・ルールでないと確信できる場合は、Streams クライアントのルール・セットに含まれる表ルールをチェックします。たとえば、取得プロセスで特定の表に対する変更が取得されることを予期していたが、これらの変更が取得されない場合は、取得プロセスのポジティブ・ルール・セットおよびネガティブ・ルール・セット内のルールが、表に対する変更を取得するように取得プロセスに指示していないことが原因となっている可能性があります。

データベースで取得プロセス strm01_captureが実行され、この取得プロセスでhr.departments表に対する変更を取得すると想定します。取得プロセスでネガティブ・ルール・セットを使用する場合は、この表に対して TRUEと評価される表ルールがネガティブ・ルール・セットに含まれないことを確認します。このようなルールが含まれると、表に対する変更が取得プロセスで廃棄される可能性があります。このようなルールを表示する問合せの例は、14-56 ページの「Streams クライアント用のネガティブ・ルール・セット内のルールの判別」を参照してください。

この問合せを実行してこのようなルールが戻された場合、表に対する変更が取得プロセスによって廃棄される可能性があります。この問合せを実行してもルールが戻されない場合は、この表に対して TRUEと評価される 1 つ以上の表ルールが取得プロセスのポジティブ・ルール・セットに含まれていることを確認してください。このようなルールを表示する問合せの例は、14-55 ページの「Streams クライアント用のポジティブ・ルール・セット内のルールの判別」を参照してください。

サブセット・ルールのチェックサブセット・ルールのチェックサブセット・ルールのチェックサブセット・ルールのチェックサブセット・ルールは、取得プロセス、伝播、適用プロセスまたはメッセージ・クライアントで使用されるルール・セットに含めることができます。サブセット・ルールが TRUEと評価されるのは、表の特定の行サブセットに対する変更が DML 操作に含まれている場合のみです。たとえば、hr.departments表に対する変更があるときに、適用プロセスstrm01_applyについて TRUEと評価される表ルールをチェックするには、次の問合せを実行します。

COLUMN RULE_NAME HEADING 'Rule Name' FORMAT A20COLUMN RULE_TYPE HEADING 'Rule Type' FORMAT A20COLUMN DML_CONDITION HEADING 'Subset Condition' FORMAT A30

SELECT RULE_NAME, RULE_TYPE, DML_CONDITION FROM DBA_STREAMS_RULES

参照参照参照参照 : 15-18 ページの「スキーマ・ルールとグローバル・ルールのチェック」

参照参照参照参照 : 表ルールを指定する方法の詳細は、6-19 ページの「表ルールの例」を参照してください。



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=1700DEPARTMENTS6 DML location_id=1700DEPARTMENTS7 DML location_id=1700

この問合せでは、出力結果で「Subset Condition」というラベルが付いた DML_CONDITION列に表のサブセット条件が戻されることに注意してください。この例では、hr.departments表のサブセット・ルールが指定されています。これらのサブセット・ルールは、location_idが 1700の 1 行が関係する変更が LCR に含まれている場合にのみ、TRUEと評価されます。そのため、適用プロセスですべての変更を表に適用することを予期していても、これらのサブセット・ルールが原因で、適用プロセスでは location_idが 1700でない行が関係する変更は廃棄されます。

メッセージ・ルールのチェックメッセージ・ルールのチェックメッセージ・ルールのチェックメッセージ・ルールのチェックメッセージ・ルールは、伝播、適用プロセスまたはメッセージ・クライアントで使用されるルール・セットに含めることができます。メッセージ・ルールは、取得イベントではなく、指定したメッセージ型のユーザー・エンキュー・イベントにのみ関連します。メッセージ・ルールが TRUEと評価されるのは、キュー内のユーザー・エンキュー・イベントの型がメッセージ・ルールで指定されている型と同じであり、このイベントがメッセージ・ルールのルール条件を満たしている場合です。

伝播、適用プロセスまたはメッセージ・クライアントで特定のユーザー・エンキュー・イベントに対するタスクが実行されることを予期していたが、Streams クライアントによってこれらのイベントに対するタスクが実行されていない場合は、Streams クライアントのポジティブ・ルール・セットおよびネガティブ・ルール・セット内のルールが、これらのイベントに対するタスクを実行するように Streams クライアントに指示していないことが原因となっている可能性があります。同様に、伝播、適用プロセスまたはメッセージ・クライアントで特定のユーザー・エンキュー・イベントが廃棄されることを予期していたが、Streams

注意注意注意注意 : サブセット・ルールはポジティブ・ルール・セットにのみ存在する必要があります。


� サブセット・ルールを指定する方法の詳細は、6-19 ページの「表ルールの例」を参照してください。

� 6-24 ページの「行の移行とサブセット・ルール」



クライアントによってこれらのイベントが廃棄されていない場合は、Streams クライアントのポジティブ・ルール・セットおよびネガティブ・ルール・セット内のルールが、これらのイベントを廃棄するように Streams クライアントに指示していないことが原因となっている可能性があります。

たとえば、メッセージ・クライアント oe で、次の条件を満たす oe.user_msg型のメッセージをデキューすると想定します。

:"VAR$_2".OBJECT_OWNER = 'OE' AND :"VAR$_2".OBJECT_NAME = 'ORDERS'

メッセージ・クライアントでネガティブ・ルール・セットを使用する場合は、このメッセージ型に対して TRUEと評価されるメッセージ・ルールが含まれないことを確認します。このようなルールが含まれると、これらのメッセージがメッセージ・クライアントで廃棄される可能性があります。たとえば、このようなルールがメッセージ・クライアントのネガティブ・ルール・セットに含まれているかどうかを判断するには、次の問合せを実行します。

COLUMN RULE_NAME HEADING 'Rule Name' FORMAT A30COLUMN 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 A35COLUMN 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と評価されるルールが含まれています。

ルールに関する問題の解決ルールに関する問題の解決ルールに関する問題の解決ルールに関する問題の解決Streams の取得プロセス、伝播、適用プロセスまたはメッセージ・クライアントが予期したとおりに動作していないのは、Streams クライアントのルール・セットに 1 つ以上のルールが欠落しているためであると判断した場合は、DBMS_STREAMS_ADMパッケージの次のいずれかのプロシージャを使用して適切なルールを追加できます。








� ADD_TABLE_RULES




� メッセージ・ルールを指定する方法の詳細は、6-32 ページの「メッセージ・ルールの例」を参照してください。

� この項で説明されたルールの作成方法の例については、10-23 ページの「メッセージ・クライアントおよびメッセージ通知の構成」を参照してください。



DBMS_RULE_ADMパッケージを使用すると、必要に応じてカスタマイズされたルールを追加できます。

また、Streams の取得プロセス、伝播、適用プロセスまたはメッセージ・クライアントが予期したとおりに動作していないのは、1 つ以上のルールの変更やルール・セットからの削除が必要なためである可能性もあります。

適切なルールがあっても、関連するイベントが Streams の取得プロセス、伝播または適用プロセスによってフィルタで除外される場合は、トレース・ファイルとアラート・ログをチェックして、Streams のデータ・ディクショナリであるマルチバージョン・データ・ディクショナリの欠落に関するアラートの有無を確認します。このようなアラート・メッセージには、次の情報が含まれている場合があります。

� gdbnm: 欠落しているオブジェクトのソース・データベースのグローバル名

� scn: 欠落しているトランザクションの SCN

このようなメッセージが見つかった場合は、新規の接続先データベース用にカスタム取得プロセス・ルールを使用するか、既存の取得プロセス・ルールを再利用して、インスタンス化の準備のために適切なプロシージャを実行してください。

� PREPARE_TABLE_INSTANTIATION

� PREPARE_SCHEMA_INSTANTIATION

� PREPARE_GLOBAL_INSTANTIATION

また、ソース・データベースから接続先データベースに伝播が実行されていることを確認します。Streams データ・ディクショナリの情報は接続先データベースに伝播され、接続先データベースのディクショナリにロードされます。


� 12-6 ページの「ルールの変更」

� 12-12 ページの「ルール・セットからのルールの削除」


� Streams のデータ・ディクショナリの詳細は、2-41 ページの「Streamsデータ・ディクショナリ」を参照してください。


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

ルールベースの変換が適切に構成されているかルールベースの変換が適切に構成されているかルールベースの変換が適切に構成されているかルールベースの変換が適切に構成されているかルールベースの変換は、ポジティブ・ルール・セットのルールが TRUEに評価される場合に発生するイベントのユーザー定義の変更です。ルールベースの変換はルールのアクション・コンテキスト内で指定されます。また、これらのアクション・コンテキストに含まれる名前/ 値ペアでは、名前に STREAMS$_TRANSFORM_FUNCTION、値にユーザー作成ファンクションが指定されます。このユーザー作成ファンクションによって変換が実行されます。ユーザー定義ファンクションに不備があると、予期しない動作が発生する可能性があります。

Streams の取得プロセス、伝播、適用プロセスまたはメッセージ・クライアントが予期したとおりに動作しない場合は、Streams クライアントに指定したルールベースの変換ファンクションをチェックして不備を訂正します。DBA_STREAMS_TRANSFORM_FUNCTIONデータ・ディクショナリ・ビューを問い合せると、これらのファンクションの名前を検索できます。問題を解決するには、変換ファンクションの変更やルールベースの変換の削除が必要になる場合があります。ファンクション名が正しく入力されていることを確認してください。

ルールベースの変換が実行される前に、ルールが評価されます。たとえば、表名を empsから employeesに変更する変換がある場合は、その変換を使用する各ルールのルール条件で、表名 employeesではなく empsが指定されていることを確認してください。

トレース・ファイルとアラート・ログでの問題のチェックトレース・ファイルとアラート・ログでの問題のチェックトレース・ファイルとアラート・ログでの問題のチェックトレース・ファイルとアラート・ログでの問題のチェック各取得プロセス、伝播ジョブおよび適用プロセスに関するメッセージは、そのプロセスまたは伝播ジョブを実行しているデータベースのトレース・ファイルに記録されます。ローカルの取得プロセスはソース・データベースで実行され、ダウンストリーム取得プロセスはダウンストリーム・データベースで実行されます。また、伝播ジョブは伝播のソース・キューを含むデータベース上で実行され、適用プロセスは接続先データベース上で実行されます。これらのトレース・ファイル・メッセージは、Streams 環境での問題を識別して解決するために役立ちます。

バックグラウンド・プロセスのすべてのトレース・ファイルは、初期化パラメータBACKGROUND_DUMP_DESTで指定した接続先ディレクトリに書き込まれます。トレース・ファイル名はオペレーティング・システム固有ですが、通常、各ファイルにはそれを書き込むプロセスの名前が含まれています。


� 取得プロセスで使用されるルール・セットを表示する問合せについては、14-6 ページの「各取得プロセスのキュー、ルール・セットおよび状態の表示」を参照してください。

� ルール・セット内のルールに指定されているルールベースの変換ファンクションを表示する問合せについては、14-63 ページの「ルールベースの変換の表示」を参照してください。

� ルールベースの変換を変更または削除する方法については、12-16ページの「ルールベースの変換の管理」を参照してください。



たとえば、一部のオペレーティング・システムでは、プロセスのトレース・ファイル名はsid_xxxxx_iiiii.trcとなり、意味は次のようになります。

� sidはデータベースのシステム識別子です。

� xxxxxはプロセス名です。

� iiiiiはオペレーティング・システムのプロセス番号です。

また、write_alert_logパラメータを、取得プロセスと適用プロセスの両方について yに設定できます。このパラメータをにデフォルト設定である yに設定すると、データベースのアラート・ログには取得プロセスまたは適用プロセスの停止理由を示すメッセージが書き込まれます。

トレース・ファイル内の情報を制御するには、DBMS_CAPTURE_ADMおよびDBMS_APPLY_ADMパッケージの SET_PARAMETERプロシージャを使用して、trace_level取得プロセスまたは適用プロセス・パラメータを設定します。

次のチェックリストを使用して、Streams に関連するトレース・ファイルをチェックします。

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

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

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

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

取得プロセスは、Oracle バックグラウンド・プロセス cnnnです。この場合、nnnは取得プロセス番号です。たとえば、一部のオペレーティング・システムでは、取得プロセスを実行しているデータベースのシステム識別子が hqdbで、取得プロセス番号が 01であれば、その取得プロセスのトレース・ファイル名は hqdb_c001で始まります。


� トレース・ファイルとアラート・ログおよびこれらの名前と位置の詳細は、『Oracle Database 管理者ガイド』を参照してください。

� trace_level取得プロセス・パラメータおよび trace_level適用プロセス・パラメータの設定方法の詳細は、『PL/SQL パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

� トレース・ファイルの名前と位置の詳細は、オペレーティング・システム固有の Oracle マニュアルを参照してください。

参照参照参照参照 : 取得プロセスの取得プロセス番号を表示する問合せについては、14-7 ページの「各取得プロセスに関する一般情報の表示」を参照してください。



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

それぞれの伝播には、ジョブ・キュー・コーディネータ・プロセスとジョブ・キュー・プロセスに依存する伝播ジョブが使用されます。ジョブ・キュー・コーディネータ・プロセス名は cjqnnで、nnはジョブ・キュー・コーディネータ・プロセス番号です。ジョブ・キュー・プロセス名は jnnnで、nnnはジョブ・キュー・プロセス番号です。

たとえば、一部のオペレーティング・システムでは、伝播ジョブを実行しているデータベースのシステム識別子が hqdbで、ジョブ・キュー・コーディネータ・プロセスが 01であれば、そのジョブ・キュー・コーディネータ・プロセスのトレース・ファイル名はhqdb_cjq01で始まります。同様に、前述のデータベース上で、ジョブ・キュー・プロセスが 001であれば、そのトレース・ファイル名は hqdb_j001で始まります。プロセス名は、DBA_QUEUE_SCHEDULESデータ・ディクショナリ・ビューの PROCESS_NAME列を問い合せるとチェックできます。

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

適用プロセスは、Oracle バックグラウンド・プロセス annnです。この場合、nnnは適用プロセス番号です。たとえば、一部のオペレーティング・システムでは、適用プロセスを実行しているデータベースのシステム識別子が hqdbで、適用プロセス番号が 001であれば、その適用プロセスのトレース・ファイル名は hqdb_a001で始まります。

また、適用プロセスではパラレル実行サーバーも使用されます。適用プロセスに関する情報は、1 つ以上のパラレル実行サーバーのトレース・ファイルに記録される場合があります。パラレル実行サーバーのプロセス名は pnnnで、nnnはプロセス番号です。そのため、一部のオペレーティング・システムでは、適用プロセスを実行しているデータベースのシステム識別子が hqdbで、プロセス番号が 001であれば、その適用プロセスで使用されるパラレル実行サーバーに関する情報を含むトレース・ファイルの名前は hqdb_p001で始まります。

参照参照参照参照 : 伝播ジョブで使用されるジョブ・キュー・プロセスを表示する問合せについては、15-8 ページの「伝播で使用される伝播ジョブが有効化されているか」を参照してください。




� 適用プロセスの適用プロセス番号を表示する問合せについては、14-36ページの「各コーディネータ・プロセスに関する一般情報の表示」を参照してください。

� 適用プロセスのリーダー・サーバーで使用されるパラレル実行サーバーを表示する問合せについては、14-34 ページの「各適用プロセス用のリーダー・サーバーに関する情報の表示」を参照してください。

� 適用プロセスの適用サーバーで使用されるパラレル実行サーバーを表示する問合せについては、14-36 ページの「各適用プロセス用の適用サーバーに関する情報の表示」を参照してください。


第第第第 III部部部部
環境とアプリケーションの例環境とアプリケーションの例環境とアプリケーションの例環境とアプリケーションの例
第 III 部には、次の詳細例が記載されています。

� 第 16 章「単一データベースの取得および適用の例」

� 第 17 章「ルールベースのアプリケーションの例」

単一データベースの取得およ

16
単一データベースの取得および適用の例単一データベースの取得および適用の例単一データベースの取得および適用の例単一データベースの取得および適用の例
この章では、単一データベースの例を説明します。例では、表に対する変更を取得し、取得された変更をキューに再エンキューします。その後、適用中に DML ハンドラを使用して、変更のサブセットを異なる表に挿入します。


� 単一データベースの取得および適用の例の概要

� 前提条件

注意注意注意注意 : より広範囲な例は、この章の PDF バージョンではなく HTMLバージョンに含まれています。

び適用の例 16-1

単一データベースの取得および適用の例の概要

単一データベースの取得および適用の例の概要単一データベースの取得および適用の例の概要単一データベースの取得および適用の例の概要単一データベースの取得および適用の例の概要この章の例では、Streams を使用して、単一データベース cpap.netでデータ操作言語

（DML）の変更を取得および適用する方法を示します。具体的には、hrスキーマでのemployees表に対する DML 変更の例が取得されます。ここでは、行の論理変更レコード

（LCR）がキュー streams_queueに含められます。次に、適用プロセスによってこれらの行 LCR は同一のキューからデキューされ、このキューに再エンキューされてから DML ハンドラに送られます。

行 LCR は、取得されるとバッファ・キューに存在することになり、明示的にはデキューできません。行 LCR が適用中に再エンキューされると、アプリケーションで明示的にデキュー可能になります。この例では、これらの行 LCR をデキューするアプリケーションは作成されません。

この例では、削除された従業員のレコードを hrスキーマの emp_del表に挿入する DML ハンドラについて説明します。この例では、すべての削除された従業員のレコードを保持するために、emp_del表が使用されることを想定しています。DML ハンドラは、各行 LCR にDELETE文が含まれるかどうかを判別するために使用されます。行 LCR に DELETE文が含まれることが DML ハンドラで検出されると、DML ハンドラによって、emp_del表に対する DELETE文が INSERT文に変換され、行が挿入されます。


前提条件

図 16-1 に、この環境の概要を示します。

図図図図 16-1 単一データベースの取得および適用の例単一データベースの取得および適用の例単一データベースの取得および適用の例単一データベースの取得および適用の例

前提条件前提条件前提条件前提条件この章の例を開始する前に、前提条件となる次の作業を完了する必要があります。

� 環境内のすべてのデータベースについて、次の初期化パラメータを指定の値に設定します。

– COMPATIBLE初期化パラメータを 10.1.0以上に設定します。

– STREAMS_POOL_SIZE: オプションで、このパラメータを適切な値に設定します。このパラメータでは、Streams プールのサイズを指定します。Streams プールには、取得イベントが格納されます。また、Streams プールは、パラレル取得およびパラ



� DML ハンドラの詳細は、4-4 ページの「LCR イベントの処理」を参照してください。

単一データベースの取得および適用の例 16-3

前提条件

レル適用中の内部通信に使用されます。STREAMS_POOL_SIZEが 0（ゼロ）（デフォルト）に設定されている場合、Streams によって共有プールが使用されます。この場合、共有プールのサイズを増加する必要がある場合があります。

� ARCHIVELOGモードで実行されるようにデータベースを設定します。取得される変更を生成するデータベースは、ARCHIVELOGモードで実行されている必要があります。

� この例では、新規ユーザーが Streams 管理者（strmadmin）として作成され、このユーザーのデータに使用する表領域の指定を求めるプロンプトが表示されます。この例を開始する前に、新規の表領域を作成するか、既存の表領域を Streams 管理者用に識別してください。SYSTEM表領域は、Streams 管理者用にしないでください。

参照参照参照参照 : Streams 環境で重要な他の初期化パラメータについては、8-5 ページの「Streams に関連する初期化パラメータの設定」を参照してください。

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


ルールベースのアプリケ

17
ルールベースのアプリケーションの例ルールベースのアプリケーションの例ルールベースのアプリケーションの例ルールベースのアプリケーションの例
この章では、Oracle ルール・エンジンを使用するルールベースのアプリケーションについて説明します。

この章の例は、Streams から独立しています。つまりこれらの例では、Streams の取得プロセス、伝播、適用プロセスまたはメッセージ・クライアントはルール・エンジンのクライアントではなく、またキューは使用されません。


� ルールベースのアプリケーションの概要

注意注意注意注意 : より広範囲な例は、この章の PDF バージョンではなく HTMLバージョンに含まれています。




� 14-51 ページの「ルールおよびルールベースの変換の監視」

ーションの例 17-1

ルールベースのアプリケーションの概要

ルールベースのアプリケーションの概要ルールベースのアプリケーションの概要ルールベースのアプリケーションの概要ルールベースのアプリケーションの概要この章の各例では、顧客の問題を処理するルールベースのアプリケーションを作成します。アプリケーションではルールを使用し、新規の問題がレポートされた場合は、その優先度に基づいて、完了する必要のあるアクションを判断します。たとえば、アプリケーションでは、それぞれの問題をその優先度に基づいて社内の特定のセンターに割り当てます。

アプリケーションでは、これらのルールがルール・エンジンを使用して規定されます。サポートの問題に関連する情報を定義するために、評価コンテキスト evalctxが作成されます。ルールは前述の要件に基づいて作成され、ルール・セット rsに追加されます。

問題を割り当てるタスクは、ユーザー定義プロシージャ problem_dispatchによって実行されます。このプロシージャはルール・エンジンをコールしてルール・セット rs内のルールを評価し、TRUEと評価されるルールに基づいて適切なアクションを実行します。


第第第第 IV部部部部
付録付録付録付録
第 IV 部の構成は、次のとおりです。

� 付録 A「LCR 用の XML Schema」

� 付録 B「Streams を使用したオンラインでのデータベースのアップグレードおよびメンテナンス」

LCR 用の XML Sc

A
LCR 用の用の用の用の XML Schema
この付録で説明する XML Schema では、論理変更レコード（LCR）のフォーマットが定義されます。

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

� LCR 用の XML Schema 定義

このスキーマ用の名前空間は、次の場合に記載されています。

http://xmlns.oracle.com/streams/schemas/lcr

スキーマは、次の場合に記載されています。

http://xmlns.oracle.com/streams/schemas/lcr/streamslcr.xsd

このスキーマ定義は、SQL*Plus で SYSとして接続して次のファイルを実行すると、データベースにロードできます。

rdbms/admin/catxlcr.sql

rdbmsディレクトリは Oracle ホームにあります。

hema A-1

LCR 用の XML Schema 定義

LCR 用の用の用の用の XML Schema 定義定義定義定義LCR 用の XML Schema 定義は、次のとおりです。

'<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>

 <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"/>

 <element name="char" type = "string" xdb:SQLType="CLOB" nillable="true"/> <element name="nchar" type = "string" xdb:SQLType="NCLOB" nillable="true"/>

A-2 Oracle Streams 概要および管理


<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"/>

 <element name="interval_ym" type = "string" nillable="true"/>

 <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>

LCR 用の XML Schema A-3


</complexType>

<element name = "ROW_LCR"> <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"> <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>';

LCR 用の XML Schema A-5



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

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

この付録では、Oracle データベースをわずかな停止時間でメンテナンスする操作について説明します。これらのメンテナンス操作には、新しいバージョンの Oracle データベースへのアップグレード、異なるオペレーティング・システムまたはキャラクタ・セットへの Oracleデータベースの移行、ユーザー作成アプリケーションのアップグレードおよび Oracle データベース・パッチの適用が含まれます。この付録で説明するメンテナンス操作では、わずかな停止時間でデータベースをメンテナンスするために、Oracle Streams の機能を使用します。

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

� Streams を使用したデータベースのメンテナンス・プロセスの概要

� Streams を使用したデータベースのバージョン・アップグレードの実行

� Streams を使用したデータベースのメンテナンス操作の実行

� データベースのメンテナンス操作の完了

ンス B-1

Streams を使用したデータベースのメンテナンス・プロセスの概要

Streams を使用したデータベースのメンテナンス・プロセスのを使用したデータベースのメンテナンス・プロセスのを使用したデータベースのメンテナンス・プロセスのを使用したデータベースのメンテナンス・プロセスの概要概要概要概要

通常、次の操作を実行するには、長時間、データベースを停止する必要があります。

� データベースのバージョンのアップグレード

� 異なるオペレーティング・システムへのデータベースの移行

� 異なるキャラクタ・セットへのデータベースの移行

� ユーザー作成アプリケーションにアップグレードするためのデータベース・スキーマ・オブジェクトの変更

� Oracle ソフトウェア・パッチの適用

Oracle Streams の機能を使用することで、わずかな停止時間でこれらのメンテナンス操作を実行できます。そのためには、Oracle Streams を使用して、単一のソース・レプリケーション環境を構成します。その環境では、元のデータベースがソース・データベースで、データベースのコピーがソースで行われた変更の接続先データベースです。

次の一般的な手順で、データベースがオンラインの状態でメンテナンス操作を実行できます。

1. 空の接続先データベースを作成します。

2. Oracle Streams の単一ソース・レプリケーション環境を構成します。その環境では、元のデータベースがソース・データベースで、データベースのコピーがソースで行われた変更の接続先データベースです。

3. 接続先データベースに対してメンテナンス操作を実行します。このとき、元のソース・データベースはオンラインで使用可能です。

4. Oracle Streams を使用して、ソース・データベースで行われた変更を接続先データベースに適用します。

5. ソース・データベースで行われた変更を接続先データベースに適用した後、ソース・データベースをオフラインにして、アプリケーションおよびユーザーが接続先データベースを使用できるようにします。

この付録で説明するアップグレード手順は、アップグレード対象のデータベースが次の条件を満たしていることを前提としています。

� Streams でサポートされていない DML または DDL 文は、アップグレード・プロセス全体で実行されない。

� データベースは、既存の Oracle Streams 環境に含まれない。

� データベースは、既存のロジカル・スタンバイ環境に含まれない。

� データベースは、既存の Advanced Replication 環境に含まれない。

� アップグレード・プロセス中、ジョブ・キューは作成、変更または削除されない。

B-2 Oracle Streams 概要および管理

Streams を使用したデータベースのバージョン・アップグレードの実行

� データベースには、他のデータベースのマテリアライズド・ビューのマスター表である表は存在しない。

� ユーザー作成キューは、アップグレード・プロセス中は読取り専用である。

� Oracle が提供する PL/SQL パッケージのサブプログラムは、ユーザー・データとディクショナリ・メタデータを同時に変更するアップグレード・プロセス中には起動されない。

この項では、それぞれのメンテナンス操作の実行手順について説明します。

� B-3 ページの「Streams を使用したデータベースのバージョン・アップグレードの実行」

� B-13 ページの「Streams を使用したデータベースのメンテナンス操作の実行」

Streams を使用したデータベースのバージョン・アップグレーを使用したデータベースのバージョン・アップグレーを使用したデータベースのバージョン・アップグレーを使用したデータベースのバージョン・アップグレードの実行ドの実行ドの実行ドの実行

データベースのバージョン・アップグレードに Streams を使用するには、データベースはOracle9i リリース 2（9.2）である必要があります。データベースのバージョン・アップグレードを始める前に、操作中に接続先データベースをインスタンス化するために、オリジナルのエクスポート / インポート・ユーティリティを使用するか、Recovery Manager

（RMAN）ユーティリティを使用するかを決定します。アップグレード対象の既存のデータベースは、接続先データベースに置き換えられます。

接続先データベースのインスタンス化にどちらのユーティリティを使用するかを決定するには、次の事項を考慮します。

� オリジナルのエクスポート / インポートを使用すると、操作の初で、接続先データベースを Oracle Database 10g データベースにできます。つまり、インスタンス化の後、接続先データベースをアップグレードする必要はありません。

� Recovery Manager を使用すると、特に、データベースが大規模な場合は、オリジナルのエクスポート / インポートよりインスタンス化の処理が速くなります。ただし、データベースのバージョンは、Recovery Manager のインスタンス化の場合と同じである必要があります。つまり、インスタンス化を実行する際の接続先データベースは Oracle9iリリース 2（9.2）データベースです。インスタンス化の後、接続先データベースをアップグレードする必要があります。

また、分散トランザクションが可能な環境でインスタンス化を行う場合は、Recovery Manager を使用しないことをお薦めします。そのような環境で Recovery Manager を使用すると、手動での修正が必要なインダウント・トランザクションが実行される場合があります。

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


インスタンス化に使用するユーティリティを決定した後、次のいずれかの項の手順を実行します。

� Streams とオリジナルのエクスポート / インポートを使用したデータベースのバージョン・アップグレードの実行

� Streams と Recovery Manager を使用したデータベースのバージョン・アップグレードの実行

Streams とオリジナルのエクスポートとオリジナルのエクスポートとオリジナルのエクスポートとオリジナルのエクスポート / インポートを使用したデータベースインポートを使用したデータベースインポートを使用したデータベースインポートを使用したデータベースのバージョン・アップグレードの実行のバージョン・アップグレードの実行のバージョン・アップグレードの実行のバージョン・アップグレードの実行

次の手順に従って、エクスポート / インポートおよび Oracle Streams を使用したデータベースのバージョン・アップグレードを実行します。

1. 空の Oracle Database 10g データベースを作成します。このデータベースは、アップグレード・プロセス中の接続先データベースとなります。この接続先データベースは、アップグレード対象のソース・データベースとは異なるオペレーティング・システムおよびキャラクタ・セットを使用する場合があります。

Oracle をインストールする必要がある場合は、ご使用のオペレーティング・システムのOracle インストレーション・ガイドを参照してください。また、データベースの作成については、『Oracle Database 管理者ガイド』を参照してください。

接続先データベースのグローバル名がソース・データベースとは異なることを確認してください。ここでは、ソース・データベースのグローバル名が orcl.net、アップグレードで使用する接続先データベースのグローバル名が stms.netであると想定しています。接続先データベースのグローバル名は、アップグレード・プロセスの後で、接続先データベースがソース・データベースと置き換わるときに変更されます。

2. ソース・データベースで、Oracle9i リリース 2（9.2）の Streams ではサポートされていなかったデータベース・オブジェクトを読取り専用にします。Oracle9i の Streams では、データ型が NCLOB、LONG、LONG RAW、BFILE、ROWID、UROWIDの列を持つ表、およびユーザー定義型（オブジェクト型、REF、VARRAY、ネストした表）の列を持つ表はサポートされていませんでした。また、Streams では、一次表、索引構成表またはオブジェクト表はサポートされていませんでした。サポートされていないデータベース・オブジェクトについては、『Oracle9i Streams』を参照してください。

3. ソース・データベースで、Streams 管理者を構成します。手順については、『Oracle9i Streams』を参照してください。ここでは、ソース・データベースの Streams 管理者の名前が strmadminであると想定しています。この Streams 管理者は、インスタンス化中に、自動的に接続先データベースにコピーされます。



4. ソース・データベースで、SQL*Plus に管理ユーザーとして接続し、すべての更新に対して主キーまたは一意索引（主キーがない場合）のデータベース・サプリメンタル・ロギングを指定します。次に例を示します。

CONNECT SYSTEM/[email protected]

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY, UNIQUE INDEX) COLUMNS;

5. ソース・データベースで、SQL*Plus に Streams 管理者として接続し、アップグレード・プロセス中にソース・データベースに対して行われた変更をステージングするSYS.AnyDataキューを作成します。次に例を示します。


EXEC DBMS_STREAMS_ADM.SET_UP_QUEUE();

6. ソース・データベースで、SQL*Plus に Streams 管理者として接続し、ソース・データベースへのすべてのサポートされている変更を取得するローカル取得プロセスを構成し、手順 5 で作成したキューにこれらの変更をステージングします。次に例を示します。


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 => true, source_database => NULL);END;/

取得プロセスは開始しないでください。

7. 次の手順で、オリジナルのエクスポート / インポートを使用して、接続先データベースをインスタンス化します。

a. ソース・データベースのコマンドラインから、CONSISTENTエクスポート・パラメータを yに設定して、全データベースのエクスポートを実行します。

exp SYSTEM/password FULL=y FILE=instant.dmp GRANTS=y ROWS=y CONSISTENT=y

b. ソースおよび接続先データベースが異なるコンピュータ・システムにある場合は、接続先データベースを実行しているコンピュータ・システムにエクスポート・ダンプ・ファイルを転送します。



c. 接続先データベースのコマンドラインから、ダンプ・ファイルが格納されているディレクトリで、STREAMS_INSTANTIATIONインポート・パラメータを y、STREAMS_CONFIGURATIONインポート・パラメータを nに設定して、全データベースのインポートを実行します。

imp SYSTEM/password FULL=y FILE=instant.dmp COMMIT=y LOG=import.log STREAMS_INSTANTIATION=y STREAMS_CONFIGURATION=n

オリジナルのエクスポート / インポート・ユーティリティを使用したエクスポート / インポートの実行については、『Oracle Database ユーティリティ』を参照してください。

8. 接続先データベースで、ソース・データベースからレプリケートされるデータを変更するインポート済のジョブを無効にします。DBA_JOBSデータ・ディクショナリ・ビューを問い合せて、ジョブを表示します。

9. 接続先データベースで、SQL*Plus に Streams 管理者として接続し、インポートされたSYS.AnyDataキューを削除します。次に例を示します。



queue_name => 'strmadmin.streams_queue', cascade => false, drop_unused_queue_table => true);END;/

10. 接続先データベースで、SQL*Plus に Streams 管理者として接続し、SYS.AnyDataキューを再作成します。このキューは、ソース・データベースから伝播された変更をステージングします。次に例を示します。



11. ソース・データベースが接続先データベースと通信できるように、ネットワークおよびOracle Net を構成します。手順については、『Oracle Net Services 管理者ガイド』を参照してください。

12. ソース・データベースで、SQL*Plus に Streams 管理者として接続し、接続先データベースへのデータベース・リンクを作成します。次に例を示します。


CREATE DATABASE LINK stms.net CONNECT TO strmadmin IDENTIFIED BY strmadminpw USING 'stms.net';



13. ソース・データベースで、SQL*Plus に Streams 管理者として接続し、手順 5 で作成したソース・キューからのすべての変更を、手順 10 で作成した宛先キューに伝播する伝播を作成します。次に例を示します。


BEGIN DBMS_STREAMS_ADM.ADD_GLOBAL_PROPAGATION_RULES(

streams_name => 'orcl_to_stms',source_queue_name => 'strmadmin.streams_queue',destination_queue_name => '[email protected]', include_dml => true, include_ddl => true,

include_tagged_lcr => true, source_database => 'orcl.net');END;/

14. 接続先データベースで、SQL*Plus に Streams 管理者として接続し、手順 10 で作成したキューにすべての変更を適用する適用プロセスを作成します。次に例を示します。


BEGIN DBMS_STREAMS_ADM.ADD_GLOBAL_RULES( streams_type => 'apply',

streams_name => 'apply',queue_name => 'strmadmin.streams_queue', include_dml => true, include_ddl => true,


15. B-26 ページの「データベースのメンテナンス操作の完了」の手順を完了します。

Streams とととと Recovery Manager を使用したデータベースのバージョン・アップを使用したデータベースのバージョン・アップを使用したデータベースのバージョン・アップを使用したデータベースのバージョン・アップグレードの実行グレードの実行グレードの実行グレードの実行

次の手順に従って、Recovery Manager（RMAN）および Oracle Streams を使用したデータベースのバージョン・アップグレードを実行します。

1. 空の Oracle9i リリース 2（9.2）データベースを作成します。このデータベースは、アップグレード・プロセス中の接続先データベースとなります。この接続先データベースは、アップグレード対象のソース・データベースとは異なるオペレーティング・システムおよびキャラクタ・セットを使用する場合があります。アップグレード・プロセスを



開始する場合、アップグレード対象のソース・データベースと接続先データベースの両方が Oracle9i リリース 2（9.2）データベースである必要があります。

Oracle をインストールする必要がある場合は、ご使用のオペレーティング・システムのOracle インストレーション・ガイドを参照してください。また、データベースの作成については、『Oracle9i データベース管理者ガイド』を参照してください。

接続先データベースのグローバル名がソース・データベースとは異なることを確認してください。ここでは、ソース・データベースのグローバル名が orcl.net、アップグレードで使用する接続先データベースのグローバル名が updb.netであると想定しています。接続先データベースのグローバル名は、アップグレード・プロセスの後で、接続先データベースがソース・データベースと置き換わるときに変更されます。

2. ソース・データベースで、Oracle9i リリース 2（9.2）の Streams ではサポートされていなかったデータベース・オブジェクトを読取り専用にします。Oracle9i リリース 2

（9.2）の Streams では、データ型が NCLOB、LONG、LONG RAW、BFILE、ROWID、UROWIDの列を持つ表、およびユーザー定義型（オブジェクト型、REF、VARRAY、ネストした表）の列を持つ表はサポートされていませんでした。また、Streams では、一次表、索引構成表またはオブジェクト表はサポートされていませんでした。サポートされていないデータベース・オブジェクトについては、『Oracle9i Streams』を参照してください。

3. ソース・データベースで、Streams 管理者を構成します。手順については、『Oracle9i Streams』を参照してください。ここでは、ソース・データベースの Streams 管理者の名前が strmadmin、ソース・データベースのグローバル名が orcl.netであると想定しています。

4. ソース・データベースで、SQL*Plus に管理ユーザーとして接続し、すべての更新に対して主キーおよび一意索引（主キーがない場合）のデータベース・サプリメンタル・ロギングを指定します。次に例を示します。


ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY, UNIQUE INDEX) COLUMNS;

5. ソース・データベースで、SQL*Plus に Streams 管理者として接続し、アップグレード・プロセス中にソース・データベースに対して行われた変更をステージングするSYS.AnyDataキューを作成します。次に例を示します。







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 => true, source_database => NULL);END;/


7. 次の手順で、Recovery Manager の DUPLICATEコマンドを使用して、接続先データベースをインスタンス化します。ここで示すのは、Recovery Manager を使用してデータベースを複製する手順の概略です。Recovery Manager の使用方法の詳細は、

『Oracle9i Recovery Manager ユーザーズ・ガイド』を参照してください。

a. バックアップがまだの場合は、ソース・データベースのバックアップを作成します。Recovery Manager では、複製に有効なバックアップが必要です。ここでは、バックアップがまだの場合は、orcl.netのバックアップを作成します。

b. ソース・データベースで、SQL*Plus に管理ユーザーとして接続し、Recovery Manager の DUPLICATEコマンドの終了 SCN を決定します。次に例を示します。


SET SERVEROUTPUT ON SIZE 1000000DECLARE until_scn NUMBER;BEGIN until_scn:= DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER; DBMS_OUTPUT.PUT_LINE('Until SCN: ' || until_scn);END;/

終了 SCN 値を書き留めます。ここでは、終了 SCN 値を 439882としています。手順 e で Recovery Manager を使用してデータベースを複製するときに、UNTIL SCNオプションをこの値に設定します。



c. ソース・データベースで、SQL*Plus に管理ユーザーとして接続し、現行のオンライン REDO ログをアーカイブします。次に例を示します。


ALTER SYSTEM ARCHIVE LOG CURRENT;

d. データベースの複製用に環境を準備します。接続先データベースを複製の補助インスタンスとして準備します。手順については、『Oracle9i Recovery Manager ユーザーズ・ガイド』の Recovery Manager を使用したデータベースの複製に関する章を参照してください。

e. Recovery Manager の DUPLICATEコマンドを使用して、接続先データベースでソース・データベースをインスタンス化します。UNTIL SCN句を使用して、複製のSCN を指定できます。この句には、手順 b で決定した終了 SCN を使用します。終了 SCN および上位 SCN 値に対して、アーカイブ REDO ログが使用可能である必要があります。そのために、手順 c で終了 SCN を含む REDO ログをアーカイブしました。

複製データベースの名前を指定するには、DUPLICATEコマンドで TO database_nameを使用します。ここでは、複製データベースを stms.netとします。つまり、この例の DUPLICATEコマンドには、TO stms.netが含まれます。

次に、Recovery Manager の DUPLICATEコマンドの例を示します。

rmanRMAN> CONNECT TARGET SYS/[email protected]> CONNECT AUXILIARY SYS/[email protected]> RUN { SET UNTIL SCN 439882; ALLOCATE AUXILIARY CHANNEL updb DEVICE TYPE sbt; DUPLICATE TARGET DATABASE TO updb NOFILENAMECHECK; }

f. 接続先データベースで、SQL*Plus に管理ユーザーとして接続し、ALTER SYSTEM文を使用して RESTRICTED SESSIONを無効にします。

CONNECT SYSTEM/MANAGER

ALTER SYSTEM DISABLE RESTRICTED SESSION;

8. 接続先データベースで、ソース・データベースからレプリケートされるデータを変更するジョブを無効にします。DBA_JOBSデータ・ディクショナリ・ビューを問い合せて、ジョブを表示します。

9. 接続先データベースで、SQL*Plus に管理ユーザーとして接続し、データベースのグローバル名を変更します。Recovery Manager の DUPLICATEコマンドを実行すると、



接続先データベースとソース・データベースのグローバル名が同じになります。次に例を示します。


ALTER DATABASE RENAME GLOBAL_NAME TO stms.net;


11. 接続先データベースを Oracle Database 10g にアップグレードします。手順については、『Oracle Database アップグレード・ガイド』を参照してください。

12. 接続先データベースで、SYSDBA権限を持つ管理ユーザーとして接続し、次のプロシージャを実行します。

CONNECT SYS/[email protected] AS SYSDBA


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

13. 接続先データベースで、SQL*Plus に Streams 管理者として接続し、ソース・データベースへのデータベース・リンクを作成します。次に例を示します。


CREATE DATABASE LINK orcl.net CONNECT TO strmadmin IDENTIFIED BY strmadminpw USING 'orcl.net';

14. 接続先データベースで、SQL*Plus に Streams 管理者として接続し、データベース全体およびすべてのデータベース・オブジェクトのインスタンス化 SCN を設定します。Recovery Manager の DUPLICATEコマンドは、UNTIL SCN句で指定した SCN 値より 1少ない SCN までデータベースを複製します。つまり、手順 7e で DUPLICATEコマンドを実行したときに指定した終了 SCN 値から 1 を引きます。この場合、終了 SCN 値は439882でした。つまり、インスタンス化 SCN は、439882 - 1で 439881となります。


BEGIN

注意注意注意注意 : このプロシージャを実行するときは、ソース・データベースではなく、接続先データベースに接続していることを確認してください。このプロシージャでは、ローカルの Streams 構成が削除されるためです。



DBMS_APPLY_ADM.SET_GLOBAL_INSTANTIATION_SCN( source_database_name => 'orcl.net', instantiation_scn => 439881, recursive => true);END;/














streams_name => 'orcl_to_stms',source_queue_name => 'strmadmin.streams_queue',destination_queue_name => '[email protected]', include_dml => true,


Streams を使用したデータベースのメンテナンス操作の実行

include_ddl => true, include_tagged_lcr => true, source_database => 'orcl.net');END;/







Streams を使用したデータベースのメンテナンス操作の実行を使用したデータベースのメンテナンス操作の実行を使用したデータベースのメンテナンス操作の実行を使用したデータベースのメンテナンス操作の実行この項では、Oracle Database 10g データベースで実行する次のいずれかのメンテナンス操作について説明します。

� 異なるオペレーティング・システムへのデータベースの移行

� 異なるキャラクタ・セットへのデータベースの移行



Streams を使用すると、わずかな停止時間でこれらの操作を実行できます操作中、ソース・データベースは、データベースのメンテナンスを実行している既存のデータベースです。接続先データベースは、操作の後で、ソース・データベースと置き換えられるデータベースです。



ユーザー作成アプリケーションへのアップグレード準備ユーザー作成アプリケーションへのアップグレード準備ユーザー作成アプリケーションへのアップグレード準備ユーザー作成アプリケーションへのアップグレード準備ユーザー作成アプリケーションをアップグレードする場合は、通常、データベースのスキーマ・オブジェクトを、アップグレード後のアプリケーションをサポートするように変更します。Streams では、行 LCR に、DML 文の実行結果である行変更の情報が含まれます。DMLハンドラは、ソース・データベースで実行した DML 文によって発生した行 LCR を処理するユーザー・プロシージャです。Streams の適用プロセスが行 LCR を DML ハンドラに渡し、DML ハンドラが、ソース・データベースと接続先データベースの差異を考慮するように行LCR を変更できます。

Streams を使用してユーザー作成アプリケーションをアップグレードするプロセスには、インスタンス化後に接続先データベースで行うスキーマ・オブジェクトの変更および作成が含まれます。接続先データベースで 1 つ以上の DML ハンドラを使用して、ソース・データベースからの変更が、変更済のスキーマ・オブジェクトに正確に適用されるように、それらの変更を処理できます。

データベースのメンテナンス操作を開始する前に、次のことを行って、DML ハンドラを準備する必要があります。

� DML ハンドラについて理解します。4-4 ページの「適用プロセスによるイベント処理オプション」を参照してください。

� 接続先データベースで必要になる DML ハンドラを決定します。アップグレードしたアプリケーションで必要なスキーマ・オブジェクトへの変更によって、決定する DML ハンドラは異なります。

� データベースのメンテナンス操作の DML ハンドラで使用する PL/SQL プロシージャを作成します。PL/SQL プロシージャの作成については、『Oracle Streams レプリケーション管理者ガイド』を参照してください。

インスタンス化で使用するユーティリティの決定インスタンス化で使用するユーティリティの決定インスタンス化で使用するユーティリティの決定インスタンス化で使用するユーティリティの決定データベースのメンテナンス操作を始める前に、操作中に接続先データベースをインスタンス化するために、エクスポート / インポート・ユーティリティ（Data Pump またはオリジナル）を使用するか、Recovery Manager（RMAN）ユーティリティを使用するかを決定します。接続先データベースのインスタンス化にどちらのユーティリティを使用するかを決定するには、次の事項を考慮します。

� データベースを異なるオペレーティング・システムに移行する場合は、エクスポート /インポートを使用する必要があります。インスタンス化で Recovery Manager のDUPLICATEコマンドを使用しても、データベースを異なるオペレーティング・システムに移行できません。

� データベースを異なるキャラクタ・セットに移行する場合は、エクスポート / インポートを使用する必要があります。インスタンス化で Recovery Manager の DUPLICATEコマンドを使用しても、データベースを異なるキャラクタ・セットに移行できません。



� Recovery Manager を使用できる場合は、特にデータベースが大きい場合に、Recovery Manager を使用する方が、エクスポート / インポートを使用するより速くインスタンス化を実行できます。

� 分散トランザクションが可能な環境でインスタンス化を行う場合は、Recovery Managerを使用しないことをお薦めします。そのような環境で Recovery Manager を使用すると、手動での修正が必要なインダウント・トランザクションが実行される場合があります。

インスタンス化に使用するユーティリティを決定した後、次のいずれかの項の手順を実行します。

� B-15 ページの「エクスポート / インポートおよび Streams を使用したメンテナンス操作の実行」

� B-19 ページの「Recovery Manager および Streams を使用したメンテナンス操作の実行」

エクスポートエクスポートエクスポートエクスポート / インポートおよびインポートおよびインポートおよびインポートおよび Streams を使用したメンテナンス操作のを使用したメンテナンス操作のを使用したメンテナンス操作のを使用したメンテナンス操作の実行実行実行実行

Data Pump Export/Import またはオリジナルのエクスポート / インポートを使用して、データベースのメンテナンス操作中にデータベースをインスタンス化します。オリジナルのエクスポート / インポートを使用するより速くインスタンス化を実行できるため、Data Pumpを使用することをお薦めします。

次の手順に従って、エクスポート / インポートおよび Oracle Streams を使用したメンテナンス操作を実行します。

1. 空の Oracle Database 10g データベースを作成します。このデータベースは、メンテナンス操作中の接続先データベースとなります。データベースを異なるオペレーティング・システムに移行する場合は、このオペレーティング・システムを実行しているコンピュータ・システムにデータベースを作成します。データベースを異なるキャラクタ・セットに移行する場合は、このキャラクタ・セットを使用するデータベースを作成します。


接続先データベースのグローバル名がソース・データベースとは異なることを確認してください。ここでは、ソース・データベースのグローバル名が orcl.net、メンテナンス操作で使用する接続先データベースのグローバル名が stms.netであると想定しています。接続先データベースのグローバル名は、メンテナンス操作の後で、接続先データベースがソース・データベースと置き換わるときに変更されます。

注意注意注意注意 : 次の項で説明する手順は、ソース・データベースと接続先データベースの両方が、Oracle Database 10g を実行していることを前提としてます。



2. ソース・データベースで、Oracle Database 10g の Streams ではサポートされていないデータベース・オブジェクトを読取り専用にします。サポートされていないオブジェクトについては、2-7 ページの「取得されるデータ型」および 2-9 ページの「取得される変更のタイプ」を参照してください。

3. ソース・データベースで、Streams 管理者を構成します。手順については、8-2 ページの「Streams 管理者の構成」を参照してください。ここでは、ソース・データベースの

Streams 管理者の名前が strmadminであると想定しています。この Streams 管理者は、インスタンス化中に、自動的に接続先データベースにコピーされます。

4. ソース・データベースで、SQL*Plus に管理ユーザーとして接続し、すべての更新に対して主キーまたは一意索引（主キーがない場合）のソース・データベースのサプリメンタル・ロギングを指定します。


ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY, UNIQUE, FOREIGN KEY) COLUMNS;

5. ユーザー作成アプリケーションをアップグレードする場合は、接続先データベースのDML ハンドラで起動されるソース・データベースで任意の列を補助的に記録します。これらの列は、ソース・データベースで無条件に記録される必要があります。これらの列に対する無条件のサプリメンタル・ログ・グループの指定については、『Oracle Streams レプリケーション管理者ガイド』を参照してください。

6. ソース・データベースで、SQL*Plus に Streams 管理者として接続し、メンテナンス操作中にソース・データベースに対して行われた変更をステージングする SYS.AnyDataキューを作成します。次に例を示します。





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 => true, source_database => NULL);



END;/


8. Oracle Data Pump またはオリジナルのエクスポート / インポートを使用して、接続先データベースをインスタンス化します。手順については、『Oracle Streams レプリケーション管理者ガイド』を参照してください。どちらを使用する場合も、次のパラメータが適切な値に設定されていることを確認してください。

� CONSISTENTエクスポート・パラメータを yに設定します。

� STREAMS_CONFIGURATIONインポート・パラメータを nに設定します。

� オリジナルのエクスポート / インポートを使用する場合は、STREAMS_INSTANTIATIONインポート・パラメータを yに設定します。このパラメータは、Data Pump でのインポートには適用されません。

9. 接続先データベースで、ソース・データベースからレプリケートされるデータを変更するインポート済のジョブを無効にします。DBA_JOBSデータ・ディクショナリ・ビューを問い合せて、ジョブを表示します。

10. パッチはここで適用します。パッチに付属の手順に従います。
























17. ユーザー作成アプリケーションをアップグレードする場合は、接続先データベースで、次の手順を実行します。

a. データベースのスキーマ・オブジェクトを、アップグレード後のユーザー・アプリケーションをサポートするように変更します。



b. ソース・データベースからの行 LCR が、適用プロセスによって変更済のスキーマ・オブジェクトに正確に適用されるように、これらの行 LCR を変更する 1 つ以上のDML ハンドラを構成します。たとえば、アップグレード済のユーザー作成アプリケーションをサポートするように列名が変更された場合、DML ハンドラは、列を含む行 LCR で列の名前を変更する必要があります。

DML ハンドラの構成については、『Oracle Streams レプリケーション管理者ガイド』を参照してください。


Recovery Manager およびおよびおよびおよび Streams を使用したメンテナンス操作の実行を使用したメンテナンス操作の実行を使用したメンテナンス操作の実行を使用したメンテナンス操作の実行Recovery Manager を使用して、データベースの次のメンテナンス操作中にデータベースをインスタンス化します。



ただし、データベースを異なるオペレーティング・システムまたはキャラクタ・セットに移行する場合は、エクスポート / インポートを使用してインスタンス化する必要があります。

次の手順に従って、Recovery Manager および Oracle Streams を使用して、データベースの移行を実行するか、パッチを適用します。

1. 空の Oracle Database 10g データベースを作成します。このデータベースは、データベースのメンテナンス操作中の接続先データベースとなります。データベースのメンテナンス操作を始める際、ソース・データベースと接続先データベースの両方が Oracle Database 10g データベースである必要があります。


接続先データベースのグローバル名がソース・データベースとは異なることを確認してください。ここでは、ソース・データベースのグローバル名が orcl.net、メンテナンス操作で使用する接続先データベースのグローバル名が stms.netであると想定しています。接続先データベースのグローバル名は、メンテナンス操作の後で、接続先データベースがソース・データベースと置き換わるときに変更されます。

参照参照参照参照 : データベースを異なるオペレーティング・システムまたはキャラクタ・セットに移行する場合は、B-15 ページの「エクスポート / インポートおよび Streams を使用したメンテナンス操作の実行」を参照してください。



2. ソース・データベースで、Oracle Database 10g の Streams ではサポートされていないデータベース・オブジェクトを読取り専用にします。サポートされていないオブジェクトについては、2-7 ページの「取得されるデータ型」および 2-9 ページの「取得される変更のタイプ」を参照してください。

3. ソース・データベースで、Streams 管理者を構成します。手順については、8-2 ページの「Streams 管理者の構成」を参照してください。ここでは、ソース・データベースの

Streams 管理者の名前が strmadminであると想定しています。この Streams 管理者は、インスタンス化中に、自動的に接続先データベースにコピーされます。

4. ソース・データベースで、SQL*Plus に管理ユーザーとして接続し、すべての更新に対して主キーまたは一意索引（主キーがない場合）のソース・データベースのサプリメンタル・ロギングを指定します。


ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY, UNIQUE, FOREIGN KEY) COLUMNS;

5. ユーザー作成アプリケーションをアップグレードする場合は、接続先データベースのDML ハンドラで起動されるソース・データベースで任意の列を補助的に記録します。これらの列は、ソース・データベースで無条件に記録される必要があります。これらの列に対する無条件のサプリメンタル・ログ・グループの指定については、『Oracle Streams レプリケーション管理者ガイド』を参照してください。

6. ソース・データベースで、SQL*Plus に Streams 管理者として接続し、データベースのメンテナンス操作中にソース・データベースに対して行われた変更をステージングするSYS.AnyDataキューを作成します。次に例を示します。





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 => true, source_database => NULL);



END;/


8. 次の手順で、Recovery Manager の DUPLICATEコマンドを使用して、接続先データベースをインスタンス化します。ここで示すのは、Recovery Manager を使用してデータベースを複製する手順の概略です。Recovery Manager の使用方法の詳細は、『Oracle Database バックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』を参照してください。

a. バックアップがまだの場合は、ソース・データベースのバックアップを作成します。Recovery Manager では、複製に有効なバックアップが必要です。ここでは、バックアップがまだの場合は、orcl.netのバックアップを作成します。

b. ソース・データベースで、SQL*Plus に管理ユーザーとして接続し、Recovery Manager の DUPLICATEコマンドの終了 SCN を決定します。次に例を示します。


SET SERVEROUTPUT ON SIZE 1000000DECLARE until_scn NUMBER;BEGIN until_scn:= DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER; DBMS_OUTPUT.PUT_LINE('Until SCN: ' || until_scn);END;/

終了 SCN 値を書き留めます。ここでは、終了 SCN 値を 748045としています。手順 e で Recovery Manager を使用してデータベースを複製するときに、UNTIL SCNオプションをこの値に設定します。

c. ソース・データベースで、SQL*Plus に管理ユーザーとして接続し、現行のオンライン REDO ログをアーカイブします。次に例を示します。


ALTER SYSTEM ARCHIVE LOG CURRENT;

d. データベースの複製用に環境を準備します。接続先データベースを複製の補助インスタンスとして準備します。手順については、『Oracle Database バックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』を参照してください。

e. Recovery Manager の DUPLICATEコマンドに OPEN RESTRICTEDオプションを指定して、接続先データベースでソース・データベースをインスタンス化します。OPEN RESTRICTEDオプションは必須です。このオプションを指定して SQL 文ALTER SYSTEM ENABLE RESTRICTED SESSIONを発行することで、複製データ



ベースの制限付きのセッションが有効になります。Recovery Manager は、複製データベースのオープン直後にこの文を発行します。

UNTIL SCN句を使用して、複製の SCN を指定できます。この句には、手順 b で決定した終了 SCN を使用します。終了 SCN および上位 SCN 値に対して、アーカイブ REDO ログが使用可能である必要があります。そのために、手順 c で終了 SCNを含む REDO ログをアーカイブしました。

複製データベースの名前を指定するには、DUPLICATEコマンドで TO database_nameを使用します。ここでは、複製データベースを stms.netとします。つまり、この例の DUPLICATEコマンドには、TO stms.netが含まれます。

次に、Recovery Manager の DUPLICATEコマンドの例を示します。

rmanRMAN> CONNECT TARGET SYS/[email protected]> CONNECT AUXILIARY SYS/[email protected]> RUN { SET UNTIL SCN 748045; ALLOCATE AUXILIARY CHANNEL mgdb DEVICE TYPE sbt; DUPLICATE TARGET DATABASE TO mgdb NOFILENAMECHECK OPEN RESTRICTED; }

f. 接続先データベースで、SQL*Plus に管理ユーザーとして接続し、ALTER SYSTEM文を使用して RESTRICTED SESSIONを無効にします。


ALTER SYSTEM DISABLE RESTRICTED SESSION;

9. 接続先データベースで、SYSDBA権限を持つ管理ユーザーとして接続し、次のプロシージャを実行します。

CONNECT SYS/CHANGE_ON_INSTALL AS SYSDBA


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

注意注意注意注意 : このプロシージャを実行するときは、ソース・データベースではなく、接続先データベースに接続していることを確認してください。このプロシージャでは、ローカルの Streams 構成が削除されるためです。



10. 接続先データベースで、ソース・データベースからレプリケートされるデータを変更するジョブを無効にします。DBA_JOBSデータ・ディクショナリ・ビューを問い合せて、ジョブを表示します。

11. 接続先データベースで、SQL*Plus に管理ユーザーとして接続し、データベースのグローバル名を変更します。Recovery Manager の DUPLICATEコマンドを実行すると、接続先データベースとソース・データベースのグローバル名が同じになります。次に例を示します。


ALTER DATABASE RENAME GLOBAL_NAME TO stms.net;


13. ここで、パッチを接続先データベースに適用します。パッチに付属の手順に従います。

14. 接続先データベースで、SQL*Plus に Streams 管理者として接続し、ソース・データベースへのデータベース・リンクを作成します。次に例を示します。


CREATE DATABASE LINK orcl.net CONNECT TO strmadmin IDENTIFIED BY strmadminpw USING 'orcl.net';

15. 接続先データベースで、SQL*Plus に Streams 管理者として接続し、データベース全体およびすべてのデータベース・オブジェクトのインスタンス化 SCN を、手順 8b で決定した終了 SCN に設定します。

16. 接続先データベースで、SQL*Plus に Streams 管理者として接続し、データベース全体およびすべてのデータベース・オブジェクトのインスタンス化 SCN を設定します。Recovery Manager の DUPLICATEコマンドは、UNTIL SCN句で指定した SCN 値より 1少ない SCN までデータベースを複製します。つまり、手順 7e で DUPLICATEコマンドを実行したときに指定した終了 SCN 値から 1 を引きます。この場合、終了 SCN 値は748045でした。つまり、インスタンス化 SCN は、748045 - 1で 748044となります。


BEGIN DBMS_APPLY_ADM.SET_GLOBAL_INSTANTIATION_SCN( source_database_name => 'orcl.net', instantiation_scn => 748044, recursive => true);END;/

























22. ユーザー作成アプリケーションをアップグレードする場合は、接続先データベースで、次の手順を実行します。

a. データベースのスキーマ・オブジェクトを、アップグレード後のユーザー・アプリケーションをサポートするように変更します。

b. ソース・データベースからの行 LCR が、適用プロセスによって変更済のスキーマ・オブジェクトに正確に適用されるように、これらの行 LCR を変更する 1 つ以上のDML ハンドラを構成します。行 LCR には、DML 文の実行結果である行変更の情報が含まれます。たとえば、アップグレード済のユーザー作成アプリケーションをサポートするように列名が変更された場合、DML ハンドラは、列を含む行 LCR で列の名前を変更する必要があります。

DML ハンドラの構成については、『Oracle Streams レプリケーション管理者ガイド』を参照してください。



データベースのメンテナンス操作の完了

データベースのメンテナンス操作の完了データベースのメンテナンス操作の完了データベースのメンテナンス操作の完了データベースのメンテナンス操作の完了次の手順を実行して、データベースのメンテナンス操作を完了します。

1. 接続先データベースで、SQL*Plus に Streams 管理者として接続し、適用プロセスを開始します。次に例を示します。


BEGIN DBMS_APPLY_ADM.START_APPLY( apply_name => 'apply');END;/

2. ソース・データベースで、SQL*Plus に Streams 管理者として接続し、取得プロセスを開始します。次に例を示します。


BEGIN DBMS_CAPTURE_ADM.START_CAPTURE( capture_name => 'capture');END;/

この手順は、接続先データベースのインスタンス化中に、ソース・データベースに対して行われた変更をレプリケートするプロセスを開始します。

3. 適用プロセスが、ソース・データベースからのほとんどの変更を接続先データベースに適用するまで、Streams 環境を監視します。たとえば、取得プロセスの名前がcapture、適用プロセスの名前が applyの場合は、ソース・データベースで次の問合せを実行します。


COLUMN ENQUEUE_MESSAGE_NUMBER HEADING 'Captured SCN' FORMAT 99999999999COLUMN LWM_MESSAGE_NUMBER HEADING 'Applied SCN' FORMAT 99999999999

SELECT c.ENQUEUE_MESSAGE_NUMBER, a.LWM_MESSAGE_NUMBER FROM V$STREAMS_CAPTURE c, [email protected] a WHERE CAPTURE_NAME = 'CAPTURE' AND APPLY_NAME = 'APPLY';

この問合せで戻される 2 つの SCN 値がほぼ同じ場合は、ソース・データベースからのほとんどの変更が接続先データベースに適用済で、次の手順に進むことができます。この時点では、ソース・データベースがまだ変更可能であるため、この問合せで同じ値が戻されることはありません。



この問合せで結果が戻されない場合は、ソース・データベースの DBA_CAPTUREビューおよび接続先データベースの DBA_APPLYビューの STATUS列を問い合せて、環境のStreams クライアントが有効かどうかを確認します。14-26 ページの「伝播ジョブのスケジュールの表示」にある問合せを実行して、伝播の状態を確認できます。

Streams クライアントが無効な場合は、再起動します。Streams クライアントが再起動されない場合は、第 15 章「Streams 環境のトラブルシューティング」を参照して、環境に対するトラブルシューティングを実行します。

4. 接続先データベースで、SQL*Plus に Streams 管理者として接続し、次の問合せを実行して、適用エラーがないことを確認します。


SELECT COUNT(*) FROM DBA_APPLY_ERROR;

この問合せで 0（ゼロ）が戻されたら、次の手順に進みます。この手順でエラー・キューにエラーが表示される場合は、エラーを解決してから次の手順に進みます。手順については、11-29 ページの「適用エラーの管理」を参照してください。

5. ソース・データベースから、すべてのアプリケーションとユーザーの接続を切断します。

6. ソース・データベースで、SQL*Plus に管理ユーザーとして接続し、データベースへのアクセスを制限します。次に例を示します。


ALTER SYSTEM ENABLE RESTRICTED SESSION;

7. ソース・データベースで、SQL*Plus に管理ユーザーとして接続し、手順 3 で実行した問合せを再度実行します。この問合せで戻される 2 つの SCN 値が同じ場合は、ソース・データベースからのすべての変更が接続先データベースに適用済で、次の手順に進むことができます。

8. 接続先データベースで、SQL*Plus に Streams 管理者として接続し、手順 4 で実行した問合せを再度実行します。この問合せで 0（ゼロ）が戻されたら、次の手順に進みます。この手順でエラー・キューにエラーが表示される場合は、エラーを解決してから次の手順に進みます。手順については、11-29 ページの「適用エラーの管理」を参照してください。

9. ソース・データベースを停止します。

10. 接続先データベースで、SYS.AnyDataキュー、適用プロセス、サプリメンタル・ロギングの指定、Streams 管理者を含む、不要になった Streams コンポーネントを削除します。手順については、次の項を参照してください。

� 10-6 ページの「SYS.AnyData キューの削除」

� 11-9 ページの「適用プロセスの削除」



データベース・サプリメンタル・ロギングが不要になった場合は、接続先データベースで、SQL*Plus に管理ユーザーとして接続し、次の文を実行して、不要になったサプリメンタル・ロギングを削除します。


ALTER DATABASE DROP SUPPLEMENTAL LOG DATA (PRIMARY KEY, UNIQUE, FOREIGN KEY) COLUMNS;

また、次の文では、ユーザー名 strmadminが削除されます。

DROP USER strmadmin CASCADE;

11. 接続先データベースで、SQL*Plus に管理ユーザーとして接続し、データベースのグローバル名をソース・データベースと一致するように変更します。次に例を示します。


ALTER DATABASE RENAME GLOBAL_NAME TO orcl.net;

12. 接続先データベースで、以前に無効にしたジョブを有効にします。

13. 接続先データベースを、アプリケーションおよびユーザーからアクセスできるようにします。ソース・データベースに接続していたアプリケーションおよびユーザーを、接続先データベースにリダイレクトします。必要に応じて、ソース・データベースと通信していたシステムが接続先データベースと通信できるように、ネットワークおよび Oracle Net を構成します。手順については、『Oracle Net Services 管理者ガイド』を参照してください。


索引索引索引索引

AADD_GLOBAL_RULES プロシージャ，6-13ADD_MESSAGE_RULE プロシージャ，10-25ADD_PAIR メンバー・プロシージャ，12-7，12-9，

12-21，12-23ADD_RULE プロシージャ，5-7，12-6ADD_SCHEMA_PROPAGATION_RULES プロシー

ジャ，6-16ADD_SUBSCRIBER プロシージャ，10-3ADD_SUBSET_PROPAGATION_RULES プロシージャ

行の移行，6-24ADD_SUBSET_RULES プロシージャ，6-11，6-21

行の移行，6-24ADD_TABLE_RULES プロシージャ，6-18ALTER_APPLY プロシージャ

適用ユーザーの設定，11-15プリコミット・ハンドラの削除，11-19プリコミット・ハンドラの設定，11-19メッセージ・ハンドラの削除，11-17メッセージ・ハンドラの設定，11-16ルール・セットの削除，11-13ルール・セットの指定，11-10

ALTER_CAPTURE プロシージャ

取得ユーザーの設定，9-30先頭 SCN の設定，9-32，9-33データベース・リンクの使用の指定，9-34ルール・セットの削除，9-29ルール・セットの指定，9-26

ALTER_PROPAGATION_SCHEDULE プロシージャ，

10-11ALTER_PROPAGATION プロシージャ

ルール・セットの削除，10-16ルール・セットの指定，10-13

ALTER_RULE プロシージャ，12-6

AnyData データ型キュー，3-11，10-19

エンキュー，10-19監視，14-19削除，10-6作成，10-2デキュー，10-21

メッセージ用のラッパー，3-11，10-19AQ_TM_PROCESSES 初期化パラメータ

Streams の適用プロセス，15-16ARCHIVELOG モード

取得プロセス，2-42，8-11，16-4

BBUILD プロシージャ，2-21，2-30

CCOMPATIBLE_10_1 ファンクション，6-50COMPATIBLE_9_2 ファンクション，6-50COMPATIBLE 初期化パラメータ，8-5，16-3CREATE_APPLY プロシージャ，4-15，11-2CREATE_CAPTURE プロシージャ，2-29，9-2，9-5CREATE_PROPAGATION プロシージャ，10-7CREATE_RULE_SET プロシージャ，12-2CREATE_RULE プロシージャ，12-3

DDBA_APPLY_DML_HANDLERS ビュー，14-32DBA_APPLY_ENQUEUE ビュー，14-43DBA_APPLY_ERROR ビュー，14-44，14-45，14-49，

14-50DBA_APPLY_EXECUTE ビュー，14-43

索引索引索引索引 -1

DBA_APPLY_PARAMETERS ビュー，14-31DBA_APPLY_PROGRESS ビュー，14-38DBA_APPLY ビュー，14-29，14-30，14-33，14-34，

14-40，15-12，15-14DBA_CAPTURE_EXTRA_ATTRIBUTES ビュー，14-15DBA_CAPTURE_PARAMETERS ビュー，14-14DBA_CAPTURE ビュー，14-6，14-8，14-9，14-12，

14-15，15-2DBA_EVALUATION_CONTEXT_TABLES ビュー，

14-60DBA_EVALUATION_CONTEXT_VARS ビュー，14-60DBA_LOGMNR_PURGED_LOG ビュー，2-22，2-42，

14-11DBA_PROPAGATION ビュー，14-25，14-26，14-28，

15-7，15-8DBA_QUEUE_SCHEDULES ビュー，14-26，14-28，

15-8DBA_QUEUE_TABLES ビュー，14-20DBA_QUEUES ビュー，14-20DBA_REGISTERED_ARCHIVED_LOG ビュー，14-9，

14-12DBA_RULE_SET_RULES ビュー，14-61，14-62DBA_RULE_SETS ビュー，14-59DBA_RULES ビュー，14-61，14-62DBA_STREAMS_NEWLY_SUPPORTED ビュー，14-70DBA_STREAMS_RULES ビュー，14-57，15-18DBA_STREAMS_TRANSFORM_FUNCTION ビュー，

14-63DBA_STREAMS_UNSUPPORTED ビュー，14-68DBID（データベース識別子）

取得プロセス，2-30，9-3DBMS_APPLY_ADM パッケージ，11-1DBMS_CAPTURE_ADM パッケージ，9-1DBMS_PROPAGATION_ADM パッケージ，10-1DBMS_RULE_ADM パッケージ，12-1，12-2，17-1DBMS_RULE パッケージ，5-11，17-1DBMS_STREAMS_ADM パッケージ，6-6，9-1，10-1，

11-1取得プロセスの作成，2-29，9-2適用プロセスの作成，4-15，11-2伝播の作成，10-7

DDL ハンドラ，4-4DELETE_ALL_ERRORS プロシージャ，11-31DELETE_ERROR プロシージャ，4-19，11-30DEQUEUE プロシージャ，10-21，10-26DISABLE_DB_ACCESS プロシージャ，10-5

DISABLE_PROPAGATION_SCHEDULE プロシージャ，10-17

DML ハンドラ，4-4DROP_APPLY プロシージャ，11-9DROP_CAPTURE プロシージャ，9-25DROP_PROPAGATION プロシージャ，10-18DROP_RULE_SET プロシージャ，12-13DROP_RULE プロシージャ，12-13

EENABLE_DB_ACCESS プロシージャ，10-3ENABLE_PROPAGATION_SCHEDULE プロシー

ジャ，10-10ENQUEUE プロシージャ，10-20，10-25EVALUATE プロシージャ，5-11EXECUTE_ALL_ERRORS プロシージャ，11-30EXECUTE_ERROR プロシージャ，4-19，11-29EXECUTE メンバー・プロシージャ，11-26

GGET_COMMAND_TYPE メンバー・ファンクション，

11-26，14-47GET_COMPATIBLE メンバー・ファンクション，6-50GET_DDL_TEXT メンバー・ファンクション，14-47GET_ERROR_MESSAGE ファンクション，14-49，

14-50GET_EXTRA_ATTRIBUTE メンバー・ファンクション，

14-47GET_INFORMATION ファンクション，11-26GET_NEXT_HIT ファンクション，5-12GET_OBJECT_NAME メンバー・ファンクション，

11-26，12-18，14-47GET_OBJECT_OWNER メンバー・ファンクション，

12-18，14-47GET_SOURCE_DATABASE_NAME メンバー・ファン

クション，14-47GET_STREAMS_NAME ファンクション，11-26GET_VALUES メンバー・ファンクション，11-26，

14-47GET_VALUE メンバー・ファンクション

LCR，12-18GLOBAL_NAMES 初期化パラメータ，8-6，16-3GLOBAL_NAMES ビュー，14-8，15-7GRANT_ADMIN_PRIVILEGE プロシージャ，8-2GRANT_OBJECT_PRIVILEGE プロシージャ，5-15


GRANT_REMOTE_ADMIN_ACCESS プロシージャ，9-9

GRANT_SYSTEM_PRIVILEGE プロシージャ，5-15

IINCLUDE_EXTRA_ATTRIBUTE プロシージャ，2-5，

9-35IS_NULL_TAG メンバー・ファンクション，14-47

JJOB_QUEUE_PROCESSES 初期化パラメータ，8-6，

16-3伝播，15-10

LLCR,「論理変更レコード」を参照LOG_ARCHIVE_DEST_n 初期化パラメータ，8-6LOG_ARCHIVE_DEST_STATE_n 初期化パラメータ，

8-6LogMiner

取得プロセス，2-28複数セッション，2-28

NNOLOGGING モード

取得プロセス，2-11

OOPEN_LINKS 初期化パラメータ，8-7ORA-01291 エラー，15-4ORA-24093 エラー，15-11ORA-25224 エラー，15-12ORA-26678 エラー，15-6Oracle Enterprise Manager コンソール

Streams ツール，1-24Oracle Real Application Clusters

Oracle Streams との相互運用性，2-24，3-13，4-11Oracle Streams

AnyData キュー，10-19Data Pump，2-14LogMiner データ・ディクショナリ，2-30Streams ツール，1-24

Streams データ・ディクショナリ，2-41Streams プール，3-15アラート・ログ，15-25インスタンス化，2-13インポート・ユーティリティ，2-14，13-2エクスポート・ユーティリティ，2-14，13-2オンラインでのアップグレード，B-3概要，1-2環境の例

単一データベース，16-1監視，14-1管理者

監視，14-4構成，8-2

高可用性，7-1互換性，6-50，14-68サプリメンタル・ロギング，2-13取得プロセス，2-1準備，8-1初期化パラメータ，8-5，16-3新機能，xxiiiステージング，3-1

Oracle Real Application Clusters，3-13相互運用性，14-70タグ，1-16データ・ディクショナリ，3-20，4-16，14-1データベースのメンテナンス，B-1データベース・リンク，8-11適用プロセス，4-1伝播，3-1

Oracle Real Application Clusters，3-13トラブルシューティング，15-1トレース・ファイル，15-25ネットワーク接続性，8-11パッケージ，1-22変換

ルールベース，6-56メッセージ・クライアント，3-10メッセージング，3-11，10-18有向ネットワーク，3-7ユーザー・メッセージ，3-2ルール，6-1

アクション・コンテキスト，6-45イベント・コンテキスト，6-44サブセット・ルール，6-11，6-21システム作成，6-6評価コンテキスト，6-10，6-40


論理変更レコード（LCR），2-2XML Schema，A-1

PPARALLEL_MAX_SERVERS 初期化パラメータ，8-7PROCESSES 初期化パラメータ，8-7

RRE$NV_LIST 型，5-11

ADD_PAIR メンバー・プロシージャ，12-7，12-9，12-21，12-23

REMOVE_PAIR メンバー・プロシージャ，12-7，12-10，12-23，12-24

REDO ログ

取得プロセス，2-2REMOTE_ARCHIVE_ENABLE 初期化パラメータ，8-7REMOVE_PAIR メンバー・プロシージャ，12-7，

12-10，12-23，12-24REMOVE_QUEUE プロシージャ，10-6REMOVE_RULE プロシージャ，9-28，10-16，11-13，

12-12RESTRICTED SESSION システム権限

取得プロセス，2-24適用プロセス，4-11伝播ジョブ，3-17

REVOKE_OBJECT_PRIVILEGE プロシージャ，5-15REVOKE_SYSTEM_PRIVILEGE プロシージャ，5-15

SSCHEDULE_PROPAGATION プロシージャ，10-11SESSIONS 初期化パラメータ，8-8SET_DML_HANDLER プロシージャ，4-6

エラー・ハンドラの設定，11-27エラー・ハンドラの設定解除，11-28

SET_ENQUEUE_DESTINATION プロシージャ，11-19SET_EXECUTE プロシージャ，11-21SET_MESSAGE_NOTIFICATION プロシージャ，10-26SET_PARAMETER プロシージャ

取得プロセス，9-30適用プロセス，11-14

SET_RULE_TRANSFORM_FUNCTION プロシージャ，

12-16SET_UP_QUEUE プロシージャ，10-2SET_VALUES メンバー・プロシージャ，11-26

SET_VALUE メンバー・プロシージャLCR，12-18

SGA_MAX_SIZE 初期化パラメータ，2-28，8-8SHARED_POOL_SIZE 初期化パラメータ，8-8SQL*Loader

取得プロセス，2-12START_APPLY プロシージャ，11-9START_CAPTURE プロシージャ，9-24Statspack

Oracle Streams，14-71STOP_APPLY プロシージャ，11-9STOP_CAPTURE プロシージャ，9-24STREAMS$_EVALUATION_CONTEXT，6-10，6-40STREAMS$_TRANSFORM_FUNCTION，6-57STREAMS_POOL_SIZE 初期化パラメータ，3-15，8-9Streams,「Oracle Streams」を参照

Streams ツール，1-24Streams データ・ディクショナリ，2-41，3-20，4-16Streams プール，3-15SYS.AnyData，「AnyData データ型」を参照

TTIMED_STATISTICS 初期化パラメータ，8-10

UUNDO_RETENTION 初期化パラメータ，8-10UNRECOVERABLE キーワード

取得プロセス，2-11UNRECOVERABLE 句

SQL*Loader取得プロセス，2-12

UNSCHEDULE_PROPAGATION プロシージャ，10-12

VV$ARCHIVED_LOG ビュー，2-21V$RULE_SET_AGGREGATE_STATS ビュー，14-64V$RULE_SET ビュー，14-65，14-66V$RULE ビュー，14-67V$SESSION ビュー，14-7，14-34，14-35，14-36，

14-40V$STREAMS_APPLY_COORDINATOR ビュー，4-14，

14-36，14-37，14-38V$STREAMS_APPLY_READER ビュー，4-14，14-34，

14-35


V$STREAMS_APPLY_SERVER ビュー，4-14，14-40，14-42

V$STREAMS_CAPTURE ビュー，2-27，14-7，14-13，14-16，14-17，14-18，15-3

XXML Schema

LCR 用，A-1

ああああ

アクション・コンテキスト，5-9システム作成ルール，6-45問合せ，12-20名前 / 値ペア

削除，12-10，12-23追加，12-9，12-21，12-23変更，12-7

アップグレード

Streams を使用したオンライン，B-3宛先キュー，3-2アプリケーション

アップグレード

Streams の使用，B-13アラート・ログ

Oracle Streams のエントリ，15-25暗黙的取得，1-2

いいいい

移行

異なるオペレーティング・システムStreams の使用，B-13

異なるキャラクタ・セットStreams の使用，B-13

イベントエンキュー，3-3取得，3-3デキュー，3-3適用プロセス，4-3伝播，3-4ユーザー・エンキュー，3-3

イベント・コンテキスト

システム作成ルール，6-44インスタンス化

Streams，2-13

エクスポート / インポートData Pump およびオリジナル，2-14

インポートOracle Streams，13-2

ええええ

エクスポート

Oracle Streams，13-2エラー・キュー，4-19

エラーの削除，11-30エラーの実行，11-29監視，14-44，14-45適用プロセス，15-17

エラー・ハンドラ監視，14-32作成，11-23設定，11-27設定解除，11-28

おおおお

オペレーティング・システム移行

Streams の使用，B-13

かかかか

開始 SCN，2-21監視

AnyData データ型のキュー，14-19イベントのコンシューマ，14-22イベントの内容の表示，14-23

Oracle Streams，14-1パフォーマンス，14-71

取得プロセス，14-5互換性のある表，14-68待機時間，14-16，14-17適用済 SCN，14-15ルールの評価，14-18

適用プロセス，14-29エラー・キュー，14-44，14-45エラー・ハンドラ，14-32互換性のある表，14-68適用ハンドラ，14-32メッセージ・ハンドラ，14-33

伝播，14-24


伝播ジョブ，14-24ルール，14-51ルールベースの変換，14-63

きききき

キャラクタ・セット移行

Streams の使用，B-13キュー

AnyData，3-11，10-19削除，10-6作成，10-2

型付き，3-11トランザクション型，3-20非トランザクション型，3-20保護，3-17

ユーザー，3-18ユーザー・アクセスの無効化，10-5ユーザー・アクセスの有効化，10-3

キューによる転送，3-7行の移行，6-24

くくくく

グローバル名

取得プロセス，2-30，9-3

けけけけ

権限Oracle Streams 管理者，8-2

監視，14-4ルール，5-15

ここここ

高可用性

Streams，7-1良の実施例，7-6

取得，7-8データベース・リンク，7-9適用，7-10伝播，7-10メリット，7-3

ささささ

再エンキュー

取得イベント，16-1大チェックポイント SCN，2-28，2-33

索引構成表取得プロセス，2-9

サプリメンタル・ロギング行のサブセット化，6-29指定，9-31取得プロセス，2-13

しししし

システム変更番号（SCN）取得プロセスの開始 SCN，2-21取得プロセスの大チェックポイント SCN，2-28取得プロセスの取得済 SCN，2-21取得プロセスの先頭 SCN，2-21取得プロセスの適用済 SCN，2-21，14-15取得プロセスの必須チェックポイント SCN，2-28

取得済 SCN，2-21取得プロセス，2-1

ARCHIVELOG モード，2-42，8-11，16-4DBID，2-30，9-3LogMiner，2-28

複数セッション，2-28LogMiner データ・ディクショナリ，2-30Oracle Real Application Clusters，2-24REDO ログ，2-2

欠落しているファイル，15-4手動での追加，9-31

RESTRICTED SESSION，2-24SGA_MAX_SIZE 初期化パラメータ，2-28SYSTEM スキーマ，2-6，2-9SYS スキーマ，2-6，2-9アーキテクチャ，2-25永続的状態，2-48開始 SCN，2-21監視，14-5

互換性のある表，14-68後の REDO エントリ，14-13

待機時間，14-16，14-17ダウンストリーム取得，14-8適用済 SCN，14-15登録済ログ・ファイル，14-9，14-12古いログ・ファイル，14-11


ルールの評価，14-18管理，9-1起動，9-24グローバル名，2-30，9-3

大チェックポイント SCN，2-28，2-33索引構成表，2-9削除，9-25作成，2-29，9-2サプリメンタル・ロギング，2-13

指定，9-31自動再起動，2-44取得イベント，3-3取得されるデータ型，2-7取得される変更，2-9

DDL 変更，2-10DML 変更，2-9NOLOGGING キーワード，2-11SQL*Loader の UNRECOVERABLE 句，2-12UNRECOVERABLE キーワード，2-11

取得済 SCN，2-21取得ユーザー

設定，9-30保護キュー，3-18

準備，8-11状態，2-27先頭 SCN，2-21

設定，9-32，9-33ダウンストリーム取得，2-14

監視，14-8作成，9-2データベース・リンク，2-19，9-34メリット，2-19リモート・アクセスの監視，14-5

チェックポイント，2-28必須チェックポイント SCN，2-42

停止，9-24適用済 SCN，2-21，14-15トラブルシューティング，15-2

状態のチェック，15-2進捗のチェック，15-3

トレース・ファイル，15-26パラメータ，2-43

disable_on_limit，2-44message_limit，2-44time_limit，2-44設定，9-30並列性，2-43

必須チェックポイント SCN，2-28ビルダー・サーバー，2-26プリペアラ・サーバー，2-26変換

ルールベース，6-59リーダー・サーバー，2-26ルール，2-6，6-2

削除，9-28追加，9-27

ルール・セット

削除，9-29指定，9-26

ルールの評価，2-44ローカル取得，2-14

メリット，2-15ログ転送サービス，2-14

条件ルール，5-2

初期化パラメータAQ_TM_PROCESSES

Streams の適用プロセス，15-16COMPATIBLE，8-5GLOBAL_NAMES，8-6JOB_QUEUE_PROCESSES，8-6LOG_ARCHIVE_DEST_n，8-6LOG_ARCHIVE_DEST_STATE_n，8-6OPEN_LINKS，8-7Oracle Streams，8-5PARALLEL_MAX_SERVERS，8-7PROCESSES，8-7REMOTE_ARCHIVE_ENABLE，8-7SESSIONS，8-8SGA_MAX_SIZE，8-8SHARED_POOL_SIZE，8-8STREAMS_POOL_SIZE，3-15，8-9TIMED_STATISTICS，8-10UNDO_RETENTION，8-10

ジョブ・キュー・プロセス

伝播ジョブ，3-16新機能，xxiii

すすすす

ステージング，3-1アーキテクチャ，3-14イベント，3-3管理，10-1


バッファ・キュー，3-15保護キュー，3-17

ユーザー・アクセスの無効化，10-5ユーザー・アクセスの有効化，10-3

せせせせ

先頭 SCN，2-21

そそそそ

相互運用性

Streams，14-70ソース・キュー，3-2

たたたた

ダイレクト・パス・ロード

取得プロセス，2-12タグ，1-16

てててて

データ型

取得，2-7適用，4-10

データベースのメンテナンスStreams の使用，B-1

データベース・リンクOracle Streams，8-11

適用済 SCN，2-21，14-15適用による転送，3-7適用ハンドラ，4-5適用プロセス，4-1

DDL ハンドラ，4-4DML ハンドラ，4-4Oracle Real Application Clusters，4-11RESTRICTED SESSION，4-11アーキテクチャ，4-12イベント，4-3

取得，4-3ユーザー・エンキュー，4-3

イベントのエンキュー，11-19監視，14-43

永続的状態，4-19エラー・キュー，4-19

監視，14-44，14-45

エラー・ハンドラ監視，14-32作成，11-23設定，11-27

オプション，4-4監視，14-29

互換性のある表，14-68待機時間，14-35，14-38適用ハンドラ，14-32トランザクション，14-37

管理，11-1起動，11-9行のサブセット化，6-11

サプリメンタル・ロギング，6-29コーディネータ・プロセス，4-13

状態，4-14削除，11-9作成，4-15，11-2実行の指定，11-21

監視，14-43自動再起動，4-19停止，11-9適用サーバー，4-13

状態，4-14適用されるデータ型，4-10適用による転送，3-7適用ハンドラ，4-5

Java ストアド・プロシージャ，4-10適用ユーザー，4-2

設定，11-15保護キュー，3-18

トラブルシューティング，15-12イベント型のチェック，15-14エラー・キュー，15-17状態のチェック，15-12適用ハンドラのチェック，15-16

トレース・ファイル，15-27パラメータ，4-17

commit_serialization，4-18disable_on_error，4-19disable_on_limit，4-19time_limit，4-19transaction_limit，4-19設定，11-14並列性，4-17

非 LCR イベント，4-7


プリコミット・ハンドラ，4-8監視，14-34削除，11-19作成，11-17設定，11-19

並列性，14-42変換

ルールベース，6-63メッセージ・ハンドラ，4-4

監視，14-33削除，11-17設定，11-16

リーダー・サーバー，4-13状態，4-14

ルール，4-2，6-2削除，11-13追加，11-11

ルール・セット

削除，11-13指定，11-10

論理変更レコード（LCR），4-4伝播，3-1

アーキテクチャ，3-14宛先キュー，3-2監視，14-24管理，10-7キュー，3-4削除，10-18作成，10-7ソース・キュー，3-2トラブルシューティング，15-7

キューのチェック，15-7セキュリティ，15-10

バイナリ・ファイル，3-9バッファ・キュー，3-15変換

ルールベース，6-61保証付きの配信，3-6有向ネットワーク，3-7ルール，3-5，6-2

削除，10-16追加，10-14

ルール・セット削除，10-16指定，10-13

伝播ジョブ，3-16RESTRICTED SESSION，3-17監視，14-24管理，10-7ジョブ・キュー・プロセス，3-16スケジューリング，3-16，10-11スケジュール解除，10-12トラブルシューティング，15-7

状態のチェック，15-8ジョブ・キュー・プロセス，15-10

トレース・ファイル，15-27変更，10-11無効化，10-17有効化，10-10

とととと

トラブルシューティング

Oracle Streams，15-1取得プロセス，15-2

状態のチェック，15-2進捗のチェック，15-3

適用プロセス，15-12イベント型のチェック，15-14エラー・キュー，15-17状態のチェック，15-12適用ハンドラのチェック，15-16

伝播，15-7キューのチェック，15-7セキュリティ，15-10

伝播ジョブ，15-7状態のチェック，15-8ジョブ・キュー・プロセス，15-10

ルール，15-17ルールベースの変換，15-25

トレース・ファイル

Oracle Streams，15-25

はははは

パッチ適用

Streams の使用，B-13バッファ・キュー，3-15


ひひひひ

必須チェックポイント SCN，2-28，2-42評価コンテキスト，5-5

オブジェクト権限

取消し，12-16付与，12-15

システム権限取消し，12-15付与，12-14

評価ファンクション，5-8変数，5-6ユーザー作成，6-48，6-56ルール・セットとの関連付け，5-7ルールとの関連付け，5-7

ふふふふ

プリコミット・ハンドラ，4-8監視，14-34削除，11-19作成，11-17設定，11-19

へへへへ

変換Oracle Streams，6-56ルールベース，6-56

STREAMS$_TRANSFORM_FUNCTION，6-57アクション・コンテキスト，6-56管理，12-16削除，12-24作成，12-17取得中のエラー，6-61取得プロセス，6-59デキュー中のエラー，6-66適用中のエラー，6-65適用プロセス，6-63伝播，6-61伝播中のエラー，6-63トラブルシューティング，15-25複数，6-67変更，12-22メッセージ・クライアント，6-65

ほほほほ

保護キュー，3-17Streams クライアント

ユーザー，3-18伝播，15-10ユーザー・アクセスの無効化，10-5ユーザー・アクセスの有効化，10-3

めめめめ

明示的取得，1-2メッセージ・クライアント，3-10

変換

ルールベース，6-65メッセージ・クライアント・ユーザー

保護キュー，3-18メッセージ・ハンドラ，4-4

監視，14-33メッセージング，3-11，10-18

AnyData キュー，10-19エンキュー，10-23通知

管理，10-23デキュー，10-23メッセージ・クライアント

管理，10-23

ゆゆゆゆ

有向ネットワーク，3-7キューによる転送，3-7適用による転送，3-7

ユーザー・メッセージ，3-2

るるるる

ルール，5-1ADD_RULE プロシージャ，5-7DBMS_RULE_ADM パッケージ，12-1DBMS_RULE パッケージ，5-11EVALUATE プロシージャ，5-11maybe_rules，5-11MAYBE ルール，5-11rule_hits，5-11TRUE ルール，5-11


アクション・コンテキスト，5-9名前 / 値ペアの削除，12-7，12-10，12-23，

12-24名前 / 値ペアの追加，12-7，12-9，12-21，12-23変換，6-56変更，12-7

アプリケーション例，17-1暗黙的変数，5-6イベント・コンテキスト，5-11オブジェクト権限

取消し，12-16付与，12-15

監視，14-51管理，12-2権限，5-15

管理，12-14構成要素，5-2削除，12-13作成，12-3サブセット，6-21

アクション・コンテキストの問合せ，12-20名前の問合せ，12-20

システム権限取消し，12-15付与，12-14

システム作成，6-1，6-6and_condition パラメータ，6-39DDL ルール，6-20，6-38DML ルール，6-14STREAMS$EVALUATION_CONTEXT，6-10，

6-40アクション・コンテキスト，6-45イベント・コンテキスト，6-44行の移行，6-24グローバル，6-13サブセット，6-11，6-21スキーマ，6-16表，6-18評価コンテキスト，6-10，6-40変更，12-12

取得プロセス，2-6，6-2単純なルール，5-4適用プロセス，4-2，6-2伝播，3-5，6-2トラブルシューティング，15-17反復的に戻される結果，5-11

評価，5-11イテレータ，5-12取得プロセス，2-44部分，5-14

評価コンテキスト，5-5評価ファンクション，5-8変数，5-6ユーザー作成，6-56

部分評価，5-14変更，12-6変数，5-6明示的変数，5-6ユーザー作成，6-48ルール条件，5-2，6-18，6-21

NOT の使用，6-52Streams の互換性，6-50暗黙的変数，5-6操作のタイプ，6-49パターンの検索，14-62複合，6-51変数，6-14未定義変数，6-54明示的変数，5-6

ルール・セット，5-2オブジェクト権限

取消し，12-16付与，12-15

削除，12-13作成，12-2システム権限

取消し，12-15付与，12-14

ネガティブ，6-4評価，5-11

部分，5-14ポジティブ，6-4ルールの削除，12-12ルールの追加，12-6

ルールベースの変換，6-56

ろろろろ

論理変更レコード（LCR），2-2DDL LCR，2-4

ルール，6-20，6-38XML Schema，A-1


行 LCR，2-3ルール，6-14列の値リストの取得，11-26列の値リストの設定，11-26

互換性情報の取得，6-50情報の取得，12-18，14-47制約の取得，11-26送信者の取得，11-26追加の属性，2-5

監視，14-15管理，9-35

適用プロセス，4-4

Documents

Oracle Streams概要および管理, 10gリリース1（10.ഀㇿotndnld.oracle.co.jp/.../doc_v12/server.101/B12438-01.pdfOracle Streams 概要および管理, 10g リリース1（10.1）