ANYDATAキュー(ANYDATA queue)
タイプがANYDATA
のキュー。このキューは、ANYDATA
ラッパーでラップされた様々なタイプのメッセージをステージングできます。
「型付きキュー」も参照。
LOBアセンブリ(LOB assembly)
DMLハンドラおよびエラー・ハンドラのオプションで、LOB列のある単一の行に対する変更により発生した複数の行LCRを単一の行LCRにアセンブルします。LOBアセンブリにより、DMLハンドラおよびエラー・ハンドラでLOB列のある行LCRの処理が簡略化されます。
LogMinerデータ・ディクショナリ(LogMiner data dictionary)
取得中の変更の詳細を確認するために、取得プロセスにより使用される個別のデータ・ディクショナリです。ソース・データベースのプライマリ・データ・ディクショナリは、取得プロセスによりスキャンされたREDOデータと同期していない可能性があるため、LogMinerデータ・ディクショナリが必要です。
Oracle Streamsクライアント(Oracle Streams client)
Oracle Streams環境で作業を実行するメカニズムで、ルール・エンジンのクライアントです(メカニズムが1つ以上のルール・セットに関連している場合)。Oracle Streams クライアントには、取得プロセス、伝播、適用プロセスおよびメッセージ・クライアントが含まれます。
Oracle Streamsデータ・ディクショナリ(Streams data dictionary)
特定のソース・データベースからのデータベース・オブジェクトを追跡するために、伝播および適用プロセスにより使用される個別のデータ・ディクショナリです。
Oracle Streamsのトポロジ(Oracle Streams topology)
Oracle Streams環境のデータベース、データベースで構成されるOracle Streamsコンポーネント、およびコンポーネント間のメッセージ・フローの表現。
Oracle Streamsプール(Oracle Streams pool)
Oracle Streamsで使用されるシステム・グローバル領域(SGA)にあるメモリーです。Oracle Streamsプールは、バッファ・キューのメッセージをメモリーに格納し、取得プロセスと適用プロセスにメモリーを提供します。
アーカイブ・ログ・ダウンストリーム取得プロセス(archived-log downstream capture process)
ソース・データベースからダウンストリーム・データベースにコピーされたアーカイブREDOログ・ファイルの変更を取得するダウンストリーム取得プロセスです。
宛先データベース(destination database)
メッセージがコンシュームされるデータベースです。メッセージがコンシュームされるのは、伝播または適用プロセスにより暗黙的にキューからデキューされた場合か、アプリケーション、メッセージ・クライアントまたはユーザーにより明示的にデキューされた場合です。
「コンシューム」も参照。
インスタンス化(instantiation)
ソース・データベースでインスタンス化するためにデータベース・オブジェクトを準備するプロセス。オプションで、ソース・データベースから宛先データベースへのデータベース・オブジェクトのコピーや、インスタンス化された各データベース・オブジェクトのインスタンス化SCNの設定が可能です。
インスタンス化SCN(instantiation SCN)
ソース・データベースでそのSCNの後にコミットされた変更のみが適用プロセスにより適用されることを指定する、表のシステム変更番号(SCN)です。
永続ユーザー・メッセージ(persistent user message)
永続キューにエンキューされるユーザー定義型のLCR以外のメッセージ。永続ユーザー・メッセージは次のいずれかの方法でエンキューできます。
アプリケーションによる明示的な作成およびエンキュー
適用プロセスによるデキュー、および同じ適用プロセスによるDBMS_APPLY_ADM
パッケージ内のSET_ENQUEUE_DESTINATION
プロシージャを使用したエンキュー
永続ユーザー・メッセージはANYDATAキューまたは型付きキューの永続キュー部分にエンキューできます。
エラー・ハンドラ(error handler)
適用エラーの解決を試行する適用ハンドラです。エラー・ハンドラは、行論理変更レコード(行LCR)で適用プロセスのエラーが発生した場合にのみ起動されます。競合ハンドラが指定されていない場合や、更新の競合ハンドラが競合を解決できない場合に、競合に起因するそのようなエラーが発生する可能性があります。
カスタム適用(custom apply)
適用プロセスにより、LCRがユーザー・プロシージャにパラメータとして渡され、処理されます。ユーザー・プロシージャは、カスタマイズした方法でLCRを処理できます。
「論理変更レコード(LCR)」も参照。
カスタム・ルールベースの変換(custom rule-based transformation)
変換の実行にユーザー定義のPL/SQLファンクションが必要なルールベースの変換です。
「宣言ルールベースの変換」も参照。
キューによる転送(queue forwarding)
中間データベースで転送されるメッセージが、中間データベースに受信されるメッセージである有向ネットワークです。そのため、この有向ネットワークでは、メッセージのソース・データベースはメッセージが発生したデータベースです。
「適用による転送」も参照。
競合(conflict)
LCRの古い値と表の予期したデータ間の不一致を意味します。競合は、適用プロセスがLCRの適用を試行する際に検出されます。競合は、表のデータを共有している2つの異なるデータベースが、ほぼ同時に表の同じ行を変更する場合に発生します。
「論理変更レコード(LCR)」も参照。
行の移行(row migration)
サブセット・ルールがTRUE
に評価される際に、内部のルールベースの変換によって実行される自動変換です。自動変換では、UPDATE
操作がINSERT
またはDELETE
操作に変換されます。
行論理変更レコード(行LCR)(row logical change record)
単一行のデータへの変更、または単一のLONG
、LONG
RAW
または行のLOB列への変更を記述する論理変更レコード(LCR)で、LOBに対するデータ操作言語(DML)文またはピース単位更新によって発生します。1つのDML文により、複数の行LCRが発生する可能性があります。
近似コミット・システム変更番号(近似CSCN)(approximate commit system change number)
メッセージをコミット時間キューにエンキューしたトランザクションがコミットされる際のデータベースの現行のSCNに基づいたSCN値。
コーディネータ・プロセス(coordinator process)
適用プロセスのコンポーネント。Oracleバックグラウンド・プロセスであり、リーダー・サーバーからトランザクションを取得して適用サーバーに渡します。
サプリメンタル・ロギング(supplemental logging)
操作が実行されるたびにREDOログに配置される追加の列データです。取得プロセスはこの追加の情報を取得してLCRに含めます。追加の情報は、適用プロセスが宛先データベースでLCRを適切に適用するために必要です。
「論理変更レコード(LCR)」も参照。
取得LCR(captured LCR)
取得プロセスによって暗黙的に取得され、ANYDATAキューのバッファ・キュー部分にエンキューされた論理変更レコード(LCR)。
「ユーザー・メッセージ」も参照。
取得プロセス(capture process)
オプションのOracleバックグラウンド・プロセス。データベースのREDOログをスキャンして、データベース・オブジェクトに対するDML変更とDDL変更を取得します。取得プロセスはOracle Streamsクライアントです。
取得ユーザー(capture user)
このユーザーのセキュリティ・ドメインで、取得プロセスがルール・セットを満たす変更を取得し、取得プロセスのルールで構成されたカスタム・ルールベースの変換を実行します。または、同期取得がルール・セットを満たす変更を取得し、同期取得のルールで構成されたカスタム・ルールベースの変換を実行します。
条件付きログ・グループ(conditional log group)
サプリメンタル・ログ・グループで少なくとも1列が変更された場合に、指定されたすべての列のビフォア・イメージのみを記録するサプリメンタル・ログ・グループです。
「無条件ログ・グループ」も参照。
宣言ルールベースの変換(declarative rule-based transformation)
行LCRに対する共通の変換シナリオ・セットの1つを扱うルールベースの変換です。宣言ルールベースの変換は、PL/SQLを使用せずに内部的に実行されます。
タグ(tag)
各REDOエントリおよびLCRに含まれるRAW
データ型のデータ。タグは、Oracle Streamsクライアントの動作の変更やLCRの追跡に使用されます。また、変更の循環の回避にも使用できます。
「論理変更レコード(LCR)」も参照。
データベース・サプリメンタル・ロギング(database supplemental logging)
データベース全体の主キー、外部キーおよび一意のキー列に適用されるサプリメンタル・ロギングの一種です。
適用サーバー(apply servers)
適用プロセスのコンポーネント。LCRをDML文またはDDL文としてデータベース・オブジェクトに適用するか、LCRを適切な適用ハンドラに渡す、1つ以上のプロセスが含まれます。ユーザー・メッセージの場合、メッセージはメッセージ・ハンドラに渡されます。適用サーバーは、DBMS_APPLY_ADM.SET_ENQUEUE_DESTINATION
プロシージャで指定された論理変更レコード(LCR)メッセージとLCR以外のメッセージをエンキューすることもできます。適用サーバーにエラーが発生すると、ユーザー指定のエラー・ハンドラを使用してエラーの解決を試行します。エラーを解決できない場合は、すべてのLCRを含めてトランザクション全体をエラー・キューに置きます。
「論理変更レコード(LCR)」も参照。
適用済SCN(applied SCN)
取得プロセスに関連するシステム変更番号(SCN)。この番号は、取得プロセスで取得された変更を適用する適用プロセスによりデキューされた最新のメッセージに対応します。
適用による転送(apply forwarding)
中間データベースで転送されるメッセージが、適用プロセスにより最初に処理される有向ネットワークです。それらのメッセージは、中間データベースで取得プロセスに再度取得され、転送されます。
「キューによる転送」も参照。
適用ハンドラ(apply handler)
メッセージの処理をカスタマイズするために適用プロセスで使用されるユーザー定義プロシージャです。適用ハンドラには、メッセージ・ハンドラ、DMLハンドラ、DDLハンドラ、プリコミット・ハンドラおよびエラー・ハンドラが含まれます。
適用プロセス(apply process)
オプションのOracleバックグラウンド・プロセス。メッセージを特定のキューからデキューし、各メッセージを直接適用するか、廃棄するか、適用ハンドラにパラメータとして渡すか、または再エンキューします。適用プロセスはOracle Streamsクライアントです。
「論理変更レコード(LCR)」も参照。
適用ユーザー(apply user)
このユーザーのセキュリティ・ドメインで、適用プロセスがルール・セットを満たすメッセージをデキューし、メッセージをデータベース・オブジェクトに直接適用し、適用プロセスのルールで構成されたカスタム・ルールベースの変換を実行し、適用プロセスに構成された適用ハンドラを実行します。
トランザクション・キュー(transactional queue)
このキューでは、メッセージを、1つのトランザクションとして適用されるセットにグループ化できます。
「非トランザクション・キュー」も参照。
ネガティブ・ルール・セット(negative rule set)
Oracle Streamsクライアントのルール・セット。このルール・セットでは、ルールがメッセージをTRUE
と評価すると、Oracle Streamsクライアントがメッセージを破棄します。Oracle Streamsクライアントのネガティブ・ルール・セットは、常にポジティブ・ルール・セットよりも前に評価されます。
バッファ・キュー(buffered queue)
メモリーへのメッセージの格納にOracle Streamsプールを使用し、メモリーからオーバーフローしたメッセージの格納にキュー表を使用するキューの一部です。
バッファ・ユーザー・メッセージ(buffered user message)
アプリケーションによって明示的に作成され、バッファ・キューにエンキューされるユーザー定義型のLCR以外のメッセージ。バッファ・ユーザー・メッセージは、ANYDATAキューまたは型付きキューのバッファ・キュー部分にエンキューできます。
バリア・トランザクション(barrier transaction)
行論理変更レコード(行LCR)を含むトランザクションまたはDDLトランザクションです。適用プロセスは、バリア・トランザクションに対して、宛先データベースのデータ・ディクショナリや仮想依存性定義を使用して、表の行またはデータベース・オブジェクトを識別することはできません。
非永続キュー(nonpersistent queue)
非永続キューは、メッセージをメモリーに格納します。現在接続しているすべてのユーザーに、通知を送信するための非同期メカニズムを実現するために使用されます。非永続キューはOracle Database 10gリリース2で非推奨となりました。バッファ・メッセージを使用することをお薦めします。
評価コンテキスト(evaluation context)
ルール条件で参照される可能性のある外部データを定義するデータベース・オブジェクト。外部データは、変数、表データ、あるいはその両方として存在します。
ビルダー・サーバー(builder server)
取得プロセスのコンポーネント。プリペアラ・サーバーからのREDOレコードをマージするプロセスです。これらのREDOレコードには、部分評価の実行中にTRUE
と評価されたものと、部分評価で結果が生成されていないものがあります。ビルダー・サーバーは、これらのREDOレコードのシステム変更番号(SCN)の順序を保持し、マージされたREDOレコードを取得プロセスに渡します。
ファイル(file)
ファイル・グループに関して、ハード・ディスクに格納されているファイルを意味します。ファイルは、ファイル名、ディレクトリ・オブジェクトおよびファイル・タイプで構成されます。ディレクトリ・オブジェクトは、ファイルがハード・ディスクで格納されているディレクトリです。
プリペアラ・サーバー(preparer server)
取得プロセスのコンポーネント。リーダー・サーバーによって定義された領域をスキャンし、REDOログ内で検出された変更の事前フィルタ処理を実行します。リーダー・サーバーはプロセスで、複数のリーダー・サーバーをパラレルで実行できます。事前フィルタ処理では、変更に関する部分的な情報(変更のスキーマ名やオブジェクト名など)が評価のためにルール・エンジンに送信され、評価の結果が受信されます。
変更の循環(change cycling)
変更が発生元のデータベースに再送されることです。通常、タグの使用や、ルール条件におけるLCRメンバー関数のGET_SOURCE_DATABASE_NAME
の使用により情報を共有している環境では、変更の循環は回避する必要があります。
「論理変更レコード(LCR)」も参照。
保護キュー(secure queue)
このキューに対しては、Oracle Streamsアドバンスト・キューイング(AQ)エージェントが、エンキューやデキューなどのキュー操作を実行できる1人以上のデータベース・ユーザーに明示的に関連付けられている必要があります。
ポジティブ・ルール・セット(positive rule set)
Oracle Streamsクライアントのルール・セット。このルール・セットでは、ルールがメッセージをTRUE
と評価すると、Oracle Streamsクライアントがメッセージのタスクを実行します。Oracle Streamsクライアントのネガティブ・ルール・セットは、常にポジティブ・ルール・セットよりも前に評価されます。
無条件ログ・グループ(unconditional log group)
指定された列に影響する変更かどうかにかかわらず、表が変更された場合に、指定された列のビフォア・イメージを記録するサプリメンタル・ログ・グループです。
「条件付きログ・グループ」も参照。
明示的コンシューム(explicit consumption)
キューのメッセージが、ユーザーまたはアプリケーションで起動されたメッセージ・クライアントによってデキューされます。あるいは、アプリケーションまたはユーザーによって直接デキューされます。
メッセージ・クライアント(messaging client)
アプリケーションまたはユーザーによって起動された際に永続LCRまたは永続ユーザー・メッセージをデキューするオプションのOracle Streamsクライアント。
最も古いSCN(oldest SCN)
実行中の適用プロセスの場合は、現在デキューおよび適用されているトランザクションの最も若いシステム変更番号(SCN)です。停止した適用プロセスの場合、最も古いSCNは、適用プロセスが停止した際に適用されていたトランザクションの最も若いSCNです。
ユーザー・メッセージ(user message)
ユーザー定義型のLCR以外のメッセージ。ユーザー・メッセージは、バッファ・ユーザー・メッセージまたは永続ユーザー・メッセージです。
「論理変更レコード(LCR)」も参照。
リアルタイム・ダウンストリーム取得プロセス(real-time downstream capture process)
変更がアーカイブREDOログ・ファイルにアーカイブされる前に、ソース・データベースで行われた変更を取得できるダウンストリーム取得プロセスです。
リーダー・サーバー(reader server)
取得プロセスのコンポーネント。REDOログを読み取って複数の領域に分割するプロセスです。
メッセージをデキューする適用プロセスのコンポーネント。リーダー・サーバーはプロセスであり、LCR間の依存性を計算してメッセージをトランザクションにアセンブルします。リーダー・サーバーが、アセンブルしたトランザクションをコーディネータ・プロセスに返すと、コーディネータ・プロセスがアイドル状態の適用サーバーにトランザクションを割り当てます。
「論理変更レコード(LCR)」も参照。