JP2006501585A - 非同期情報共有システム - Google Patents

非同期情報共有システム Download PDF

Info

Publication number
JP2006501585A
JP2006501585A JP2005506083A JP2005506083A JP2006501585A JP 2006501585 A JP2006501585 A JP 2006501585A JP 2005506083 A JP2005506083 A JP 2005506083A JP 2005506083 A JP2005506083 A JP 2005506083A JP 2006501585 A JP2006501585 A JP 2006501585A
Authority
JP
Japan
Prior art keywords
database
information
changes
change
user
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2005506083A
Other languages
English (en)
Other versions
JP4384633B2 (ja
Inventor
ソウダー，ベニー
ゴーリック，ディーター
スタモス，ジム
ダウニング，アラン
アローラ，ニマー
スーブラマニアン，マヘーシュ
Original Assignee
オラクル・インターナショナル・コーポレイション
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US10/308,851 external-priority patent/US7031974B1/en
Priority claimed from US10/308,879 external-priority patent/US8374966B1/en
Application filed by オラクル・インターナショナル・コーポレイション filed Critical オラクル・インターナショナル・コーポレイション
Publication of JP2006501585A publication Critical patent/JP2006501585A/ja
Application granted granted Critical
Publication of JP4384633B2 publication Critical patent/JP4384633B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/273—Asynchronous replication or reconciliation
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99941—Database schema or data structure
    • Y10S707/99942—Manipulating data structure, e.g. compression, compaction, compilation
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99941—Database schema or data structure
    • Y10S707/99943—Generating database or data structure, e.g. via user interface
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99941—Database schema or data structure
    • Y10S707/99944—Object-oriented database structure
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99941—Database schema or data structure
    • Y10S707/99944—Object-oriented database structure
    • Y10S707/99945—Object-oriented database structure processing

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Storage Device Security (AREA)

Abstract

多種多様な状況で情報を共有するための技術を開示する。明示的な取得プロセスおよび暗黙的な取得プロセスのいずれもがステージングエリアに情報項目を追加することを可能にする情報共有システムを記載する。さらに、この情報共有システムは、上述のステージングエリアに記憶された情報項目の、暗黙的および明示的な消費の両方をサポートする。取得プロセスと、消費プロセスと、ステージングエリアから指定された宛先に情報を伝播する伝播プロセスとの挙動をカスタマイズする規則をユーザが作成および登録することを可能にするために、規則エンジンを提供する。項目のシーケンスの一度のみの処理を達成するための技術もまた記載する。ここでは、これらの項目が揮発性メモリに維持される。ＤＤＬ演算を記録するための技術、および、以前に実施されたＤＤＬ演算に基づいて演算を非同期式に実施するための技術も提供する。

Description

関連出願
この出願は、あらゆる目的で、各々の内容がこの明細書において完全に援用される以下の出願、すなわち、
２００２年８月１日に出願されて「分散した情報の共有における規則の使用（UTILIZING RULES IN DISTRIBUTED INFORMATION SHARING）」と題された米国仮特許出願第６０／４００，５３２号、および
２００２年９月１３日に出願されて「オラクルストリームズ（ORACLE STREAMS）」と題された米国仮特許出願第６０／４１０，８８３号
に関し、また、これらの出願の優先権を主張する。
発明の分野
この発明は、情報共有システムに関する。
発明の背景
容易にかつ適時に情報を共有する能力は、どのようなビジネス環境にとっても重要な要件である。したがって、情報の共有は、討議、郵便物、書籍、定期刊行物、およびコンピュータ技術等の多くの機構によりサポートされてきた。情報共有の目標、たとえば、報告書／諸表、複製、およびメッセージ送信を容易にするために、コンピュータベースの多くの技術が開発されてきた。
残念ながら、情報の共有は、殆どが依然としてアプリケーションを介して処理されている。アプリケーションは、情報共有サービスを提供するアプリケーションの開発、配備、運用、および維持に関するコストにより、相対的に費用のかかる解決策である。加えて、このようなアプリケーションが提供するサービスは、柔軟性に富んだ適時の送受だけでなく、特別な要求、カスタマイズ化に対するサポート等の所望の機能を欠いていることが多い。
データベース管理システムの重要な特徴は、複数のデータベースおよびアプリケーション間で情報を共有する能力である。これまで、この能力は、重複するさまざまな技術を用いてデータベースから情報を引出すユーザおよびアプリケーションを必要とした。今日、新規の効率性およびビジネスモデルは、より包括的で自動的な手法を必要とする。情報共有の多くの解決策は、情報共有の固有の問題に照準を合わせている。このような解決策は、このような解決策が差し向けられた情報共有の固有の問題を解決することはできても、他の情報共有の問題に適用することができず、これらの他の問題と相容れないこともあり得る。
上述の内容に基づき、問題に固有な現行の解決策よりも柔軟性に富んだ態様で電子情報を共有するためのシステムおよび技術を提供することが望ましい。
この発明は、同様の参照番号が同様の要素を指す添付の図面において、限定ではなく例として示される。
発明の詳細な説明
電子情報を共有するための方法およびシステムを説明する。以下の説明では、説明のために多数の特定の詳細を明示して、この発明の十分な理解を図る。しかしながら、これらの特定の詳細がなくてもこの発明を実施し得ることは明らかである。場合によっては周知の構造およびデバイスをブロック図の形で示し、この発明をむやみに不明瞭にすることを避ける。
トリガされた活動の連鎖
従来のデータベースシステムの技術は、しばしば、データの操作を単独のアクションとして扱う。しかしながら、実際の多くの状況ではこのことが当てはまらない。具体的に、データの操作は、しばしば、一連の活動または活動の「連鎖」をトリガする。このようにトリガされる活動は、以下のものに限定されないがそれらを含む、様々なカテゴリに入り得る。
・情報の作成、変更、削除、または時間の経過。このカテゴリ内の活動は、「ビジネスイベント」を構成し得る。
・情報要件の評価。ビジネスイベントに関して誰が通知を必要としている／希望しているかを判定する。
・所望の情報の作成。情報は、アプリケーション、ビュー、および／または変換を用いて、相互に合意したフォーマットで作成される。
・所望の移送による、所望の位置への情報の転送。
・ターゲット位置でのデータの変更。受信者の必要性に応じて編成されたターゲット環境における、新規の情報の吸収。
・新規の状態の通知。受信者またはプログラムに対する、低待ち時間の情報の提供。通知は、アプリケーションを起動することができる。
・情報へのアクセス。潜在的に、情報の作成および／または変更を行なう（そして、それによって別の「ビジネスイベント」を生じる）反応のためのものである。
一実施例に従い、さまざまな活動に対して規則を確立して、或るデータ変更イベントに対して所望される活動の連鎖を自動的に実行することができる。当然ながら、任意の所定のデータ操作イベントによりトリガされる活動の特定の連鎖は、イベントの特性と、確立された規則とに基づいて異なる。
機能上の概観
以下に、柔軟性に富んだ非同期の情報共有システムを説明する。このシステムは、単独でまたは組み合わせて用いられて多種多様な情報共有の問題を解決することのできる多数の特徴を提供する。一実施例に従い、情報共有システムは、共有されるべき情報を記憶するための１つ以上のステージングエリアを含む。この明細書で「取得プロセス」と呼ばれる１組のソフトウェアのプロセスは、ステージングエリアに情報を配置する。この明細書で「消費プロセス」と呼ばれる別の組のソフトウェアのプロセスは、ステージングエリアから情報を消費する。
一実施例に従い、ステージングエリアを介して実施される情報の共有は、非同期式であ
る。具体的に、取得プロセスが取得する変更を生成するプロセスは、取得プロセスによる変更の取得を待つために実行を休止しない。反対に、取得プロセスは、変更を生成したプロセスに報告し直す必要がない。同様に、取得プロセスは、取得プロセスがステージングエリアに追加する情報の、更に進んだ処理を待つために実行を休止しない。同様に、消費プロセスは、取得プロセスに実行の継続を促すために取得プロセスに報告し直す必要がない。
一局面に従い、情報共有システムは、暗黙的な取得プロセスおよび明示的な取得プロセスを含む多種多様な取得プロセスをサポートする。暗黙的な取得プロセスは，上述の暗黙的な取得プロセスに関連付けられたシステムで生じるイベントに基づき、１つ以上のステージングエリアに情報を追加するプロセスである。ログ取得プロセスは、暗黙的な取得プロセスの一例である。ログ取得プロセスは、データベースシステム内で生じるイベントに応答してデータシステムが生成するログ等のログを読み出し、そのログの内容に基づいてステージングエリア内に情報を配置する。明示的な取得プロセスは、ステージングエリアに関連付けられたＡＰＩ経由で明示的な関数呼出を行なってステージングエリアに情報を追加することにより、ステージングエリアに情報を追加するプロセスである。
別の局面に従い、情報共有システムは、適用プロセス、伝播プロセス、および明示的なデキュープロセスを含む多種多様な消費プロセスをサポートする。適用プロセスは、ステージングエリアに含まれる情報を自動的にデキューして、この情報に作用するプロセスである。伝播プロセスは、情報を自動的にデキューして、この情報を１つのステージングエリアから指定された宛先に移す。指定された宛先は、たとえば別のステージングエリアであり得る。明示的なデキュープロセスは、ステージングエリアに関連付けられたＡＰＩ経由で明示的な呼出を行なってステージングエリアから情報を検索することにより、ステージングエリアから情報を検索する。
消費プロセスは、消費プロセスが消費する情報を用いて多種多様な動作を実施するように設定され得る。たとえば、消費プロセスは、或る種の情報もしくはイベントを受信すること、またはそのような情報もしくはイベントに関する通知を受けることに対する関心を以前に登録していた「サブスクライバプロセス」に対し、キューから抽出されたメッセージを送出するように設定され得る。別の状況において、抽出された情報は、１つのデータベースシステム内で行なわれた変更を表わすことが考えられ、消費プロセスは、別のデータシステムで、対応する変更を行なうように設定され得る。
システムの概観
図１は、この情報の一実施例に従った、情報を非同期式に共有するためのシステム１００のブロック図である。図１を参照すると、図１は、複数のステージングエリア１０２、１０４、および１０６を含む。ステージングエリア１０２、１０４、および１０６の各々に対し、取得プロセス１１２、１１４、および１１６のそれぞれによって情報が追加される。ステージングエリア１０２、１０４、および１０６の各々から、消費プロセス１２２、１２４、および１２６のそれぞれによって情報が消費される。取得プロセス１１２、１１４、および１１６は、暗黙的な取得プロセスおよび／または明示的な取得プロセスを含み得る。消費プロセス１２２、１２４、および１２６は、適用プロセスおよび明示的なデキュープロセスを含み得る。
システム１００はさらに、１つのステージングエリア１０６から情報を抽出してその情報を別のステージングエリア１０２に追加するように設定される伝播プロセス１１８を含む。以下により詳細に説明するように、伝播プロセス１１８のソースおよびターゲットは、必ずしもステージングエリアである必要はない。たとえば、伝播プロセスは、ステージングエリアから選択的に情報を抽出し、そして、その抽出した情報を、その情報に関心を
示す別のプロセスに送信するように設定され得る。他のプロセスは、たとえば、システム１００に遠隔なシステムで稼動するプロセスであり得る。
一実施例に従い、ステージングエリア１０２、１０４、および１０６は、特定の型を対象としないキューとして実現される。ステージングエリア１０２、１０４、および１０６が特定の型を対象としないため、同じステージングエリアを用いて多数の異なる型のデータを記憶することができる。したがって、情報のさまざまな断片が異なる型のデータに対応するときでも、情報の断片間の関係を反映するシーケンスまたは配列で、それらの情報の断片をステージングエリア内にともに記憶することができる。代替的な実施例では、ステージングエリアが特定の型を対象とすることが考えられ、ここでは、各ステージングエリアが特定の型の情報項目を記憶するように設計される。
情報共有システム１００は、ユーザがデータおよびイベントを共有することを可能にする。情報共有システム１００は、１つのデータベース内において、または１つのデータベースから別のデータベースに、この情報を伝播することができる。情報共有システム１００は、指定された宛先に、指定された情報を経路指定する。その結果、イベントを取得および管理して他のデータベースおよびアプリケーションとそのイベントを共有するための従来の解決策よりも大きな機能性と柔軟性とを提供する新規の特徴が生じる。情報共有システム１００は、ユーザが、１つの解決策を得るために別の解決策を断念するというサイクルを断つことを可能にする。情報共有システム１００は、分散した事業およびアプリケーション、データウェアハウス、ならびに高可用性の解決策を構築して運用するのに必要な機能を提供する。ユーザは、情報共有システム１００の全機能を同時に用いることができる。ユーザは、変更が必要な場合、既存の機能を犠牲にすることなく情報共有システム１００の新規の機能を実現することができる。
ユーザは、情報共有システム１００を用いて、どの情報が情報共有システム１００内に挿入されるか、情報がステージングエリアからステージングエリアへ、またはデータベースからデータベースへとどのように流通または経路指定されるか、イベントが各データベース内に流入するのに伴って情報共有システム１００内のイベントに何が起こるか、および情報共有システム１００がどのように終了するかを制御する。ユーザは、情報共有システム１００の固有の機能を設定することにより、固有の要件をアドレス指定することができる。情報共有システム１００は、ユーザの指定に基づき、データベース内のイベントを自動的に取得、ステージング、および管理することができる。これらのイベントには、データ操作言語（Data Manipulation Language（ＤＭＬ））の変更およびデータ定義言語（Data Definition Language（ＤＤＬ））の変更が含まれるがこれらに限定されない。ユーザはまた、情報共有システム１００内にユーザが定義したイベントも挿入することができる。次に、情報共有システム１００は、他のデータベースまたはアプリケーションにこの情報を自動的に伝播することができる。情報共有システム１００はここでもまた、ユーザの指定に基づき、宛先のデータベースにおいてイベントを適用することができる。図２は、情報が情報共有システム１００を介して共有されている際に情報が一般に流通する段階を示す。
情報共有のオプション
上述のように、イベントに応答してシステム１００により実行され得る活動の連鎖は、多くの形態を取り得る。一般に、活動の連鎖は、データ取得、アウトバウンドのステージング、伝播、インバウンドのステージング、および消費の１つ以上を含み得る。一実施例に従い、システム１００は、さまざまな態様でこれらの活動の各々を実施するためのメカニズムを提供する。表１は、さまざまな活動の各々に関する特性のいくつかに対するさまざまなオプションを列挙する。
Figure 2006501585
情報が取得されるデータ型に関し、「スキーマ」オプションは、データのスキーマ指向のビューを指す。反対に、「Ｂ」のオプションは、データのビジネス文書指向のビューを指す。
表１に提示される活動、要素、および対応するオプションのリストは網羅的なものではない。この明細書に記載された情報共有のフレームワークは、他の多数の活動、要素、およびオプションを提供する態様で実現され得る。たとえば、伝播活動の送出要素に対する別のオプションは、「少なくとも一度」であり得る。したがって、表１は、この明細書に記載された情報共有システムの柔軟性を示すように意図されたものにすぎない。
表２は、この明細書に記載された情報システムの柔軟性を利用して、さまざまな状況下でどのように情報共有タスクを達成することができるかを示す。具体的に、表２は、情報の共有が望ましいか、または必要とされる状況を列挙しており、その状況でシステム１００を用いて情報共有活動を実行する際に用いられ得るオプションを列挙する。
Figure 2006501585
情報共有システム１００の動作上の概観
一実施例に従い、ユーザは情報共有システム１００を用いて、データベースにおいて変更を取得し、キュー内にイベントをエンキューし、１つのキューから別のキューにイベントを伝播し、イベントをデキューし、データベースにおいてイベントを適用し、ディレクテッド・ネットワークを実現し、自動的な、矛盾の検出および解決を実行し、変換を実行し、異質な情報の共有を実現することができる。
ユーザは、変更の取得に関し、テーブル、スキーマ、またはデータベース全体に対して行なわれた変更を取得するように、バックグラウンドのログ取得プロセスを設定することができる。一実施例に従い、ログ取得プロセスは、再実行ログから変更を取得して、取得した各変更を「論理変更記録」（ＬＣＲ）にフォーマット化する。変更が再実行ログ内で生じたデータベースは、ソースデータベースと呼ばれる。
キュー内にイベントを配置することに関し、少なくとも２つの種類のイベント、すなわち、ＬＣＲおよびユーザメッセージが、情報共有システム１００のキューにステージングされ得る。取得プロセスは、ユーザが指定するキュー内にイベントをエンキューする。それにより、このキューは、同じデータベース内で、または他のデータベースと、イベントを共有することができる。ユーザはまた、ユーザアプリケーションを用いてユーザイベントを明示的にエンキューすることもできる。明示的にエンキューされるこれらのイベントは、ＬＣＲまたはユーザメッセージであり得る。
１つのキューから別のキューへのイベントの伝播に関し、キューは、同じデータベース内または異なるデータベース内に存在し得る。
イベントのデキューに関し、バックグラウンドの適用プロセスは、イベントをデキューすることができる。ユーザはまた、ユーザアプリケーションを用いて、イベントを明示的にデキューすることもできる。
データベースにおいてイベントを適用することに関し、ユーザは、キュー内の全イベントか、またはユーザが指定するイベントのみを適用するように、適用プロセスを設定することができる。ユーザはまた、ユーザが作成したサブプログラム（ＰＬ／ＳＱＬ言語で記述されたサブプログラム等）を呼び出してイベントを処理するように適用プロセスを設定することもできる。イベントが適用されかつ他の種類のイベントが処理されるデータベースは、宛先データベースと呼ばれる。設定によっては、ソースデータベースと宛先データベースとが同一であることが考えられる。
情報共有システム１００の典型的なアプリケーション
情報共有システム１００は、情報共有における実質的に無数の目的を達成するのに十分な柔軟性を有する。したがって、情報共有システム１００が配置され得るアプリケーションの数も同様に多大である。情報共有システム１００の有用性および汎用性を示すために、情報共有システムをどのように適用してメッセージのキューイングおよびデータの複製を実現することができるかに関する詳細を提示する。
メッセージのキューイングに関し、情報共有システム１００は、ユーザのアプリケーションが、異なる型のメッセージをエンキューし、サブスクライブを行なっているキューにメッセージを伝播し、メッセージが消費される準備が完了したことをユーザアプリケーションに通知し、宛先データベースにおいてメッセージをデキューすることを可能にする。ログ取得プロセスとともに、規則ベースのメッセージ通知消費プロセスが用いられ得る。構成要素のこの組合せにより、取得プロセスは、データベースのログファイル内で反映されたイベントを反映するＬＣＲをステージングエリアに追加することができ、消費プロセスは、特定の種類のデータベースのイベントへの関心を示したサブスクライバに対し、通知を送信することができる。サブスクライバが関心を示した特定のイベントは、サブスクリプションデータとして記憶され得、これにより、１つ以上のＳＱＬステートメントを用いて、サブスクライバが関心を示すデータを識別することができる。重要な点は、このような通知が、サブスクライバに直接送信され得るか、遠隔ではあるが互換性を有するメッセージ送信システム経由でサブスクライバに送信され得るか、または、ＬＣＲが本来生成されたシステムとの互換性を有さないメッセージ送信システム経由でメッセージゲートウェイを介してサブスクライバに送信され得るということである。
一実施例に従い、情報共有システム１００は、SYS.AnyData型のメッセージをステージングする或る型のキューを用いるステージングエリア１０２、１０４、および１０６を実現する。ほとんどの型のメッセージが、SYS.AnyDataのラッパにラップされ得、SYS.AnyDataキューにステージングされ得る。情報共有システム１００は、マルチコンシューマ・キュー、パブリッシングおよびサブスクライビング、コンテンツベースの経路指定、インターネット伝播、変換、ならびに他のメッセージ送信サブシステムに対するゲートウェイを含むメッセージキューイングシステムの標準的な特徴のすべてをサポートするキューイングメカニズムと相互運用する。
データの複製に関し、情報共有システム１００は、データベースオブジェクトに対して行なわれたデータ操作言語（ＤＭＬ）の変更およびデータ定義言語（ＤＤＬ）の変更の両方を効率的に取得して、それらの変更を１つ以上の他のデータベースに複製することができる。取得プロセス（取得プロセス１１６等）は、ソースのデータベースオブジェクトに対して行なわれた変更を取得して、それらの変更をＬＣＲにフォーマット化する。そのＬＣＲは、（伝播プロセス１１８を介して等により）宛先のデータベースに伝播された後に
、適用プロセス（消費プロセス１２２等）により適用され得る。
宛先のデータベースは、同じデータベースオブジェクトに対するＤＭＬ変更およびＤＤＬ変更を許容することができ、これらの変更は、環境内の他のデータベースに伝播されてもよいし、されなくてもよい。すなわち、ユーザは、変更を伝播する１つのデータベースを有する情報共有システム１００を設定することができ、または、ユーザは、データベース間で変更が双方向に伝播される環境を設定することができる。また、データが共有されるテーブルは、すべてのデータベースにおいて同一のコピーである必要はない。これらのテーブルの構造および内容の両方がいずれも、異なるデータベースにおいて異なっていることが考えられ、これらのテーブル内の情報は、これらのデータベース間で共有され得る。
コアサービス
システム１００の構成要素は、１組のコアサービスを提供する。一実施例に従い、これらのコアサービスは、イベントの取得、イベントの配信、およびイベントの消費を含む。
イベントの取得は一般に、興味の対象となっているシステム内で生じるイベントの記録を確立することを指す。たとえば、興味の対象となっているシステムは、データベースシステムであることが考えられ、イベントの取得は、以下により詳細に説明するように、１組の取得プロセスによって実施され得る。
イベントの配信は一般に、イベントに関する情報を、そのイベントに関心を示すエンティティに配信することを指す。このようなエンティティは、興味の対象となっているイベントを生じたシステム内か、またはシステム外に存在し得る。たとえば、イベントの配信は、１つのデータベースシステム内で行なわれた変更に関する情報を、別のデータベースシステムに送信することを含み得る。
イベントの消費は一般に、取得したイベント情報を読出すことを指す。消費プロセスはしばしば、取得したイベントに基づき、何らかのアクションを実行するか、または活動の何らかの連鎖を開始する。たとえば、ソースのデータベースシステムから変更情報を受信したターゲットのデータベースシステムにおけるプロセスは、そのソースのデータベースシステムからの変更情報を読出して、ソースのデータベースシステム内で行なわれた対応する変更に基づき、ターゲットのデータベースシステムにおいて変更を開始することができる。
暗黙的な取得プロセスの例
上述のように、システム１００は、明示的および暗黙的な取得プロセスの両方をサポートする。ログ取得プロセスは、暗黙的な取得プロセスの一例である。一実施例に従い、ログ取得プロセスは、データベースサーバのログファイル内に記憶された情報を読出し、そして、ログファイル内の情報に基づいて１つ以上のステージングエリア内に情報を記憶するように設定されたプロセスである。このようなログファイルは、たとえば、データベースシステムが行なっている変更を記録するためにデータベースシステムが生成する再実行ログファイルを含み得る。
再実行ログファイルは、たとえば、データベースサーバが、特定の時点に、特定のテーブルにある特定の行の特定の列内の値をＸからＹに変更したことを示す再実行記録を含み得る。このような再実行記録に含まれる情報は一般に、コミットされた変更が故障発生時に失われないようにするために、データベースサーバにより用いられる。しかしながら、消費プロセスがアクセスすることのできる１つ以上のステージングエリアに情報を配置することによって再実行記録に含まれる情報を他のプロセスと選択的に共有するログ取得プ
ロセスを用いることにより、ログが本来作成された回復の目的を超越する多種多様な態様で、情報を用いることが可能になる。たとえば、消費プロセスは、ログを生成したデータベースサーバの外に存在するプロセスに対し、ステージングエリアからの変更情報を選択的に提供することができる。
一実施例に従い、ログ取得プロセスは、ログファイルから選択的に情報を取得する。たとえば、非同期トリガは、特定のテーブルに対して行なわれた特定の種類の変更に応答して始動するように規定され得る。したがって、トランザクションが特定のテーブルに対し特定の種類の変更を行なうと、(１）データベースサーバがその変更に応答して再実行記録を生成し、（２）トリガが始動して、取得プロセスが、新規の再実行記録を取得する。トリガが非同期式であるため、取得プロセスの実行は、変更を生じたトランザクションの一部として実行されない。したがって、トランザクションは、取得プロセスを待たずに先に進むことができ、取得プロセスは、変更が行なわれて何らかの時間が経過してから新規の再実行記録を取得することができる。
非同期のトリガの始動に応答して取得プロセスを実行することは、取得プロセスの動作の一例にすぎない。代替的に、ログ取得プロセスは、新規の記録に対する適切なログを定期的に検査するように単にプログラムされ得る。別の代替例として、ログ取得プロセスは、同期のトリガに応答して実行され得る。同期のトリガが用いられる場合、取得動作は、トリガを始動させた変更を行なったトランザクションの一部として、取得プロセスにより実施される。したがって、変更の取得は、変更を生じたトランザクションと「同期」である。しかしながら、この連鎖に関連付けられた活動の連鎖内の他の任意の活動（ステージング、伝播、消費等）は、そのトランザクションに対して依然として非同期式に実施され得る。
一実施例に従い、取得プロセスは、再実行ログから抽出された変更データを検索し、その変更データをＬＣＲにフォーマット化する。取得プロセスは、さらに処理を行なうためにステージングエリア内にＬＣＲを配置する。一実施例では、オンラインの再実行ログをホットマイニングすること、およびアーカイブされたログファイルをマイニングすることの両方に対するサポートが提供される。ホットマイニングが実施されると、データが書込まれたのと同時にそのデータを変更するために再実行ストリームがマイニングされ得、それによって取得の待ち時間を短縮する。
上述のように、一般的なデータベース内のデータベースオブジェクトに対して行なわれた変更は、再実行ログ内にログ記録されて、ユーザのエラーまたは媒体の故障の場合における回復可能性を保証する。一実施例において、暗黙的な取得プロセスは、バックグラウンドプロセスであり、データベースを管理して、かつ、データベースの再実行ログを読出してデータベースオブジェクトに行なわれたＤＭＬ変更およびＤＤＬ変更を取得するデータベースサーバ内で作動する。暗黙的な取得プロセスは、これらの変更をＬＣＲにフォーマット化した後に、これらの変更をステージングエリア内にエンキューする。
一実施例によると、いくつかの種類のＬＣＲが存在し、これらの種類は、ＤＭＬ演算から生じたテーブル内の行に対する変更に関する情報を含む行ＬＣＲと、データベースオブジェクトに対するＤＤＬ変更についての情報を含むＤＤＬ ＬＣＲとを含む。ユーザは規則を用い、どの変更が取得されるかを指定する。図３は、ＬＣＲを取得する暗黙的な取得プロセスを示す。
以下により詳細に説明するように、ユーザは、或るセッションまたは適用プロセスによって生成される再実行エントリに対し、「タグ」を指定することができる。それにより、これらのタグは、取得プロセスが取得したＬＣＲの一部となる。タグを用いて、再実行エ
ントリまたはＬＣＲが、ローカルなデータベースまたは異なるデータベースで生じた変更を含んでいるか否かを判定することができ、それによってユーザは、ＬＣＲが生じたデータベースにＬＣＲを送り返すことを回避することができる。タグは、他のＬＣＲの経過を追う目的でも用いることができる。ユーザはまた、タグを用いて、各ＬＣＲに対する宛先データベースの組を指定することもできる。ＬＣＲに関連付けられたタグ値は、情報共有システム１００のさまざまな構成要素に対して確立された規則に依存して、ＬＣＲがシステムを流通するのに伴い、さまざまな時点でセット、変更、および／または変換され得る。たとえば、ログファイル内で識別される変更に対して作成されたＬＣＲに対し、取得プロセスによってタグ値がセットされて、変更が生じたデータベースを示すことができる。別の例として、ＬＣＲに対するタグ値が伝播プロセスによりセットされて、伝播プロセスがそこからＬＣＲを伝播しているシステムを示すことができる。
変更に対するログをマイニングする取得プロセスは、ローカルな態様（そのログがマイニングされているシステム内において）、または遠隔の態様（そのログがマイニングされているシステム外において）のいずれかで存在し得る。取得プロセスが遠隔で作動する場合、ログは、ログを生成したシステムから、取得プロセスが作動するシステムにエクスポートされ得る。たとえば、取得プロセスは、第１のデータベースのログをマイニングし、そして、そのログに表わされるさまざまなイベントついてのＬＣＲをステージングエリア内に記憶するように設定され得る。この取得プロセスは、第２のデータベースシステムにおいて実際に作動し得る。この状況において、ログファイルは、第２のデータベースシステム内の取得プロセスによる処理のために、第１のデータベースシステムから第２のデータベースシステムに通信され得る。取得プロセスがＬＣＲを記憶するステージングエリアは、第２のデータベースシステム内にも存在し得る。この態様で、取得プロセスに関連付けられたオーバーヘッドを「オフロードする」能力は、負荷とリソースとの均衡を図るのに有用であることが考えられる。
ステージングエリア
図１に示すように、ステージングエリアは、情報の取得、配信、および消費間において情報を一時的に保持するために用いられ得る。情報を保持するために用いられるステージングエリアの特性は、その情報の特性と、その情報がトリガする活動の連鎖とに依存して変化し得る。たとえば、情報の取得、配信、および消費間において情報を保持するために用いられるステージングエリアは、以下の任意の形態を取り得る。
・なし。取得された情報は、伝播プロセスまたは消費プロセスに直接渡される。
・ジャーナル。回復ジャーナル内の情報を用いて、取得されたイベントを発見する。
・ベーシック。それ自体が回復メカニズムを提供しない記憶領域内に保持される。
・ＳＱＬ。情報は、ＳＱＬ等のデータベース言語を用いてクエリーされ得るデータコンテナ内に記憶されるが、必ずしも保存されるわけではない。
・文書化。情報がデータコンテナ内に保存されることを除き、ＳＱＬのオプションと同じである。
上述の特性を有するステージングエリアは、さまざまな態様で実現され得、この発明は、任意の特定の実現例に限定されない。たとえば、ＳＱＬおよび文書化のオプションは、オラクル・コーポレイション（Oracle Corporation）が現在利用することのできるオラクル９ｉＲ２データベースシステムにおける、アドバンスト・キューイング（Advanced Queuing）メカニズムを用いて実現され得る。さらに、同じくオラクル・コーポレイションが
利用することのできるオラクルワークフロー（Workflow）２．６とともにこのアドバンスト・キューイング機能を用いて、他のイベントのコンテキスト内のイベントを検査する能力を得ることができる。たとえば、明示的なイベント（たとえば、ＡＰＩ経由でアプリケーションにより行なわれた呼出においてアプリケーションから受信したメッセージ）を、他の明示的なイベント（たとえば、同一のアプリケーションから受信した他のメッセージ）のコンテキスト内で見ることができる。同様に、暗黙的に取得されたイベント（たとえばデータベースサーバが管理するデータに対する変更）を、他の暗黙的に取得されたイベント（たとえば他のデータベースの変更）のコンテキスト内で見ることができる。
一実施例において、情報共有システム１００は、伝播または消費のためにイベントをステージングするためのキューを用いる。ユーザは、情報共有システム１００を用いて１つのキューから別のキューにイベントを伝播することができ、これらのキューは、同じデータベースまたは異なるデータベースに存在し得る。そこからイベントが伝播されるキューをソースキューと呼び、イベントを受信するキューを宛先キューと呼ぶ。ソースキューと宛先キューとの間には、１対多、多対１、または多対多の関係が存在し得る。
キューにステージングされるイベントは、１つ以上の消費プロセス、たとえば適用プロセスか、またはユーザが定義するサブプログラムにより消費され得る。ソースキューから宛先キューに変更を伝播するようにユーザが伝播プロセス（伝播プロセス１１８等）を設定した場合、ユーザは、規則を用いてどの変更が伝播されるかを指定することができる。図４は、ソースキューから宛先キューへの伝播を示す。
ディレクテッド・ネットワークの概観
情報共有システム１００は、ディレクテッド・ネットワークを介して変更が共有される環境をユーザが設定することを可能にする。ディレクテッド・ネットワークは、伝播されるイベントが１つ以上の中間データベースを通過してから宛先データベースに到達し得るネットワークである。イベントは、中間データベースで処理されてもよく、または処理されなくてもよい。ユーザは、情報共有システム１００を用いて、各宛先データベースにどのイベントが伝播されるかを選択することができ、ユーザは、ルートイベントが宛先データベースに向かう途中でトラバースすることを指定することができる。
図５は、ディレクテッド・ネットワーク環境の一例を示す。図５に示す例において、シカゴ（Chicago）にある中間データベースのキューは、ソースキューおよび宛先キューの両方である。
イベントの明示的なエンキューおよびデキュー
ユーザアプリケーションは、情報共有システム１００のステージングエリア内にイベントを明示的にエンキューすることができる。ユーザアプリケーションは、これらのイベントをＬＣＲとしてフォーマット化することができ、このことは、適用プロセスが、宛先データベースにおいてこれらのイベントを適用することを可能にする。代替的に、これらのイベントは、別のユーザアプリケーションによる消費のために、ユーザメッセージとしてフォーマット化され得、この別のユーザアプリケーションは、適用プロセスからのコールバックにより、これらのイベントを明示的にデキューするか、または処理する。キュー内に明示的にエンキューされたイベントは、同じキューから明示的にデキューされ得る。図６は、キュー内へのイベントの明示的なエンキューと、その同じキューからのイベントのデキューとを示す。
イベントがキュー間で伝播される際に、ソースキュー内に明示的にエンキューされたイベントは、ユーザアプリケーションにより、適用プロセスからの介入なしに宛先キューから明示的にデキューされ得る。図７は、ソースキュー内へのイベントの明示的なエンキュ
ー、宛先キューへの伝播、および宛先キューからのイベントの明示的なデキューを示す。
この明細書に提示した多くの例は、ＬＣＲの取得、伝播、および適用を含むが、これらの例に示した技術は、任意の形態の共有されたデータにも同様に適用され得る。共有されたこのようなデータは、たとえば、明示的にエンキューされたユーザメッセージか、または、暗黙的に取得されてＬＣＲとは異なるフォーマットで編成された情報の形さえも取り得る。
適用プロセスの概観
一実施例によると、適用プロセスは、データベースサーバ内で稼動するバックグラウンドプロセスであり、キューからイベントをデキューして、各イベントをデータベースオブジェクトに直接適用するか、または、ユーザが定義した、適用ハンドラと呼ばれるプロシージャにそのイベントをパラメータとして渡す。これらの適用ハンドラは、メッセージハンドラ、ＤＭＬハンドラ、およびＤＤＬハンドラを含み得る。
一実施例に従い、適用プロセスは、トランザクション境界を認識するように設計される。たとえば、適用プロセスは、適用プロセスが消費しているＬＣＲにおいて表される変更のうちのどれが、同じトランザクションの一部として最初に行なわれたかを認識する。適用プロセスは、それらの変更をトランザクションにアセンブルして、トランザクション間の従属性を考慮する態様でそれらの変更を適用する。一実施例に従い、適用プロセスは、トランザクション間の従属性が許容する範囲まで、並列してこれらの変更を適用する。
一般に、適用プロセスは、ローカルなデータベースにイベントを適用する。ローカルなデータベースにおいて、適用プロセスは、稼動しているものの異質なデータベース環境において稼動しており、ローカルなデータベースとは異なる種類のデータベースである遠隔のデータベースにおいてイベントを適用するように設定され得る。たとえば、ローカルなデータベースは、或る企業が生産したデータベースサーバにより作成されたデータベースであり得、遠隔のデータベースは、別の企業が生産したデータベースサーバにより作成されたデータベースであり得る。ユーザは、規則を用いて、キュー内のどのイベントが適用されるかを指定する。図８は、ＬＣＲおよびユーザメッセージを処理する適用プロセスを示す。
一実施例に従い、適用プロセスは、ＬＣＲを直接適用する際に、矛盾を自動的に検出する。矛盾は一般に、ソースデータベースおよび宛先データベース内の同じ行がほぼ同時に変更される際に生じる。矛盾が生じると、ユーザは、ユーザが指定したビジネス規則に従って矛盾が確実に解決されるようにするメカニズムを必要とする。一実施例に従い、情報共有システム１００は、事前に構築されたさまざまな矛盾解決ハンドラを含む。ユーザは、事前に構築されたこれらのハンドラを用いて、ユーザのデータベースの各々に対し、ユーザが指定したビジネス規則に従って矛盾を解決する矛盾解決システムを定義することができる。事前に構築された矛盾解決ハンドラが解決を行えないという一意の状況をユーザが有する場合、ユーザは、カスタム矛盾解決ハンドラを構築することができる。一実施例に従い、矛盾が解決されない場合、またはハンドラのプロシージャがエラーを生じた場合、エラーを生じたトランザクション内のすべてのイベントは、後の分析と再実行の可能性とに備え、例外キュー内に保管される。
上述のように、ＬＣＲは、適用プロセスが処理し得る、共有された情報の種類の一例にすぎない。適用プロセスは、明示的にエンキューされたユーザメッセージ、および自動的に取得されてＬＣＲとして編成されていないデータを含む、任意の形態の共有された情報を「適用する」ように設定され得る。
規則駆動型の情報共有
上で説明したように、活動の連鎖内の各活動は、さまざまな態様で実施され得る。たとえば、伝播は、「最善の努力」および「オープン」な特性、または「１度のみ」および「クローズド」の特性を伴って実施され得る。この発明の一実施例に従い、
・特定のイベントに応答して実施されるべき活動の連鎖、および
・活動の連鎖における各活動がどのように実施されるべきであるか
を指定する規則をユーザが登録することを可能にするために、規則登録メカニズムが提供される。
一実施例に従い、登録メカニズムはデータベースシステム内で実現される。情報共有規則がデータベースシステムに登録されると、データベースシステムは、その規則を反映するメタデータ（この明細書では「規則のメタデータ」と呼ぶ）を生成して記憶する。加えて、データベースシステムは、その規則を実行するのに必要とされる任意のメカニズムを生成する。たとえば、ユーザがシステム１００を用いて、ソースデータベースに存在するテーブルをターゲットデータベースに複製することを望むと仮定されたい。ユーザは、複製を実行するようにシステム１００をプログラムするために、
・複製されるべきデータベースのテーブルを識別し、
・ターゲットデータベースを識別し、
・複製を実施するためのデータの取得、ステージング、伝播、および消費のオプションを指定する、
１組の規則を登録することができる。
データベースシステムは、この１組の規則を受信することに応答してメタデータを生成して規則を記録し、任意のサポートメカニズムを生成して規則を実現する。このようなサポートメカニズムは、たとえば、データベースのテーブルに対して実施された変更に応答して取得プロセスの実行をトリガするための非同期トリガを含み得る。メタデータは、たとえば、（１）情報が由来するどのログを取得すべきか、どの情報を取得すべきか、使用されるべき取得のオプション、および、取得した情報をどこにステージングすべきか、について取得プロセスに指示するメタデータと、（２）どの情報が伝播されるべきか、情報が伝播の前にどのように変換されるべきか、データをどこに伝播すべきか等を伝播プロセスに指示するメタデータと、（３）伝播された情報をどこで受信すべきか、伝播された情報をどのように処理すべきか、伝播された情報内で反映された変更と同期して、伝播された情報をどのように適用してターゲットのデータベースシステム内のテーブルを維持すべきであるか等をターゲットのデータベースシステム内の適用プロセスに指示するメタデータとを含み得る。
規則の概観
情報共有システム１００は、どの情報が共有されるべきか、および、規則を用いてその情報をどこで共有すべきか、をユーザが制御できるようにする。規則は、ＳＱＬクエリーのＷＨＥＲＥ句内の条件と同様の条件として指定され、ユーザは、関連する規則を共にグループ化して規則セットにすることができる。一実施例に従い、規則は、規則条件、規則評価のコンテキスト、および規則アクションのコンテキストを含む。
規則条件は、１つ以上の式と演算子とを組合せてブール（Boolean）値を返す。ブール値は、イベントに基づいた、ＴＲＵＥ、ＦＡＬＳＥ、またはＮＵＬＬ（未知）の値である。
規則評価のコンテキストは、規則条件内で参照され得る外部データを定義する。外部データは、外部変数、テーブルデータ、またはそれらの両方として存在し得る。
規則アクションのコンテキストは、規則が評価される際に規則エンジンのクライアントによって解釈される規則に関連付けられた任意の情報である。
たとえば、以下の規則条件を情報共有システム１００内で用いて、テーブルを所有するスキーマ名が hr でなければならないこと、かつ、テーブル名が、ＴＲＵＥと評価するための条件に対する部門でなければならないことを指定することができる。
:dml.get_object_owner()='hr' ＡＮＤ :dml.get_object_name()='部門'
この規則条件は、情報共有システム１００内において以下の態様で、すなわち、
取得プロセスに、hr.部門のテーブルに対するＤＭＬ変更を取得するように指示し、
伝播に、hr.部門のテーブルに対するＤＭＬ変更を伝播するように指示し、
適用プロセスに、hr.部門のテーブルに対するＤＭＬ変更を適用するように指示する
ために用いられ得る。
情報共有システム１００は、規則に基づいてタスクを実施する。これらのタスクは、取得プロセスによる変更の取得、伝播による変更の伝播、および適用プロセスによる変更の適用を含む。一実施例に従い、ユーザは、３つの異なるレベル、すなわち、テーブル規則、スキーマ規則、およびグローバル規則において、これらのタスクに対する規則を定義することができる。
ユーザがテーブル規則を定義すると、ユーザが指定するテーブルに変更が行なわれる際にタスクが実施される。たとえば、ユーザは、取得プロセスに対し、hr.従業員のテーブルに対する変更を取得するように指示する規則を定義することができる。この規則の場合、hr.従業員のテーブルに行が挿入された場合に、取得プロセスは、この挿入を取得してＬＣＲにフォーマット化し、このＬＣＲをキュー内にエンキューする。
ユーザがスキーマ規則を定義すると、ユーザが指定するスキーマ内のデータベースオブジェクト、およびスキーマに今後追加されるべき任意のデータベースオブジェクトに対して変更が行なわれる際にタスクが実施される。たとえば、ユーザは、伝播に対し、hrスキーマに対するＤＭＬ変更およびＤＤＬ変更をソースキューから宛先キューに伝播するように指示する２つの規則を定義することができる。これらの規則の場合、ソースキューは、以下の変更を定義するＬＣＲを含むものと仮定されたい。
hr.loc city_ix インデックスを変更する。
hr.仕事のテーブルにおいて行を更新する。
伝播は、ソースキューから宛先キューにこれらの変更を伝播する。なぜなら、これらの変更がいずれも、hrスキーマ内のデータベースオブジェクトを対象とするためである。
ユーザがグローバル規則を定義すると、データベース内の任意のデータベースオブジェクトに変更が行なわれる際にタスクが実施される。グローバル規則がグローバルなＤＭＬ取得規則である場合、取得プロセスは、データベース内のデータベースオブジェクトに対するすべてのＤＭＬ変更を取得する。グローバル規則がグローバルなＤＤＬ伝播規則またはグローバルなＤＤＬ適用規則である場合、キュー内のすべてのＤＤＬ変更に対してタスクが実施される。
規則エンジン
上述のように、システム１００のさまざまな構成要素は、規則をシステム１００に登録することによって無効にされ得るデフォルト機能を有して設計され得る。規則が登録され
ると、システム１００内でメタデータが生成されてその規則を反映する。システム１００のさまざまな構成要素は、メタデータを呼出し、そして、そのメタデータ内で反映される任意の規則に従って構成要素自体の機能を変更するように設定される、この規則は、（１）構成要素に適用され、かつ、（２）構成要素が現在作動している状況に適用される。
たとえば、特定のユーザは、伝播されている項目が特定の型のメッセージである場合、デフォルトの「１度のみ」から新規の値である「最善の努力」へと伝播ポリシーを変更する規則を登録することができる。その特定の型のメッセージを伝播する責任を負うプロセスは、その特定のユーザに対する特定の型のメッセージを処理する際に、メタデータを呼出して「最善の努力」の伝播技術を用いるように設定される。しかしながら、伝播プロセスは、他のユーザに対する同じ型のメッセージを伝播する際に、デフォルトの「１度のみ」の技術を引続き用いることが考えられる。
規則は、構成要素のデフォルト機能を無効にすることに加え、機能を補足するためにも用いられ得る。たとえば、特定の取得プロセスは、或る種の情報を取得し、そして、その情報をステージングエリアに追加するように設定され得る。取得プロセスが、そのデフォルト機能によりアドレス指定されたタスクを実施する前、間、および／または後に実行するいくつかの追加のタスクを指定する規則を、システム１００に登録することができる。たとえば取得プロセスは、登録された規則に基づきステージングエリアに情報を追加する際に、たとえば、（１）情報にタグを追加してからその情報をステージングエリア内に配置する際に、および（２）ステージングエリア内に情報を配置してからさまざまなエンティティに通知を送信する際に、多数の追加のタスクを実施するように設定され得る。
システム１００の構成要素が使用する規則の登録および管理に関与するさまざまなプロセスを、この明細書では総称して「規則エンジン」と呼ぶ。
変換の概観
規則ベースの変換は、規則がＴＲＵＥと評価する際に生じる、イベントへの任意の変更である。たとえばユーザは、或るイベントに関し、テーブル内の特定の列のデータ型を変更したいときに規則ベースの変換を用いることができる。この場合、変換は、列に対してＮＵＭＢＥＲデータ型を有する論理変更記録（ＬＣＲ）を含むSYS.AnyDataオブジェクトを入力として取り、かつ、その同じ列に対してＶＡＲＣＨＡＲ２データ型を有するＬＣＲを含むSYS.AnyDataオブジェクトを返す、ＰＬ／ＳＱＬ関数であり得る。
一実施例に従い、変換は、以下の時間に生じ得る。
・イベントのエンキュー中。これは、すべての宛先データベースに適切な態様でイベントをフォーマット化するのに有用であることが考えられる。
・イベントの伝播中。これは、データが遠隔地に送信される前にデータをサブセット化するのに有用であることが考えられる。
・イベントのデキュー中。これは、特定の宛先データベースに適切な態様でイベントをフォーマット化するのに有用であることが考えられる。
図９は、適用中における規則ベースの変換を示す。
異質な情報の共有の概観
情報共有システム１００は、同じ企業が作成したデータベース間における情報の共有に加え、異なる企業からのデータベース間における情報の共有もサポートする。一般に、或
る企業が提供するデータベースシステムがサポートする特徴は、他の企業が提供するデータベースシステムがサポートする特徴とは異なる。したがって、２つの異なる種類のデータベースシステム間において情報を共有するタスクは、極めて困難なものであることが考えられる。以下により詳細に説明するように、情報共有システム１００を用いて、このような異質のデータベースシステム間における情報の共有を著しく容易にすることができる。
どのように情報共有システム１００を用いて異質なデータベース間でデータを共有することができるかを説明するために、オラクルのデータベースサーバと非オラクルのデータベースサーバとの間でデータが共有されるものと仮定されたい。しかしながら、この明細書に記載する技術は、このような状況に限定されない。したがって、これらの技術が適用される異質なシステム内におけるデータベースの実際の種類は、実現例ごとに異なり得る。
説明のため、この明細書では、他のデータベースシステムに通信されるべき情報を最初に生成するデータベースシステムを「ソース」データベースと呼ぶ。反対に、共有された情報を受信するデータベースシステムを「宛先」データベースと呼ぶ。オラクルのデータベースがソースであり、非オラクルのデータベースが宛先である場合、非オラクルのデータベースの宛先は一般に、情報共有システム１００の以下の構成要素、すなわち、イベントを受信するためのキュー、およびイベントをデキューして適用するための適用プロセスを有していない。
オラクルのデータベースは、オラクルのソースデータベースからのＤＭＬ変更を非オラクルの宛先データベースと共有するためにプロキシとして機能し、通常は宛先データベースで行なわれるステップのいくつかを実行する。すなわち、非オラクルの宛先データベースに振り向けることになっているイベントが、オラクルのデータベース自体にデキューされ、オラクルのデータベースの適用プロセスが、異質なサービスを用い、ゲートウェイ経由のネットワーク接続を介して非オラクルのデータベースにそのイベントを適用する。図１０は、オラクルのデータベースが非オラクルのデータベースとデータを共有していることを示す。
一実施例によると、変更を取得して、その変更を非オラクルのデータベースからオラクルのデータベースに伝播するためにカスタムアプリケーションが用いられる。このアプリケーションは、トリガまたは他の何らかの方法を用いてトランザクションログから読出しを行うことにより、非オラクルのデータベースに行なわれた変更を取得する。このアプリケーションは、トランザクションをアセンブルして順序付けし、各変更を論理変更記録（ＬＣＲ）に変換する。次に、アプリケーションは、ＰＬ／ＳＱＬインターフェイスを用いることによってオラクルのデータベース内のキューにＬＣＲをエンキューし、ここで、ＬＣＲは適用プロセスによって処理され得る。図１１は、非オラクルのデータベースがオラクルのデータベースとデータを共有していることを示す。
図１２は、情報共有システム１００が１つのデータベース内で情報を共有するようにどのように設定され得るかを示し、図１３Ａおよび図１３Ｂは、情報共有システム１００が２つの異なるデータベース間で情報を共有するようにどのように設定され得るかを示す。
図１３Ａおよび図１３Ｂに示す情報共有の動作に関わるさまざまな構成要素の各々が、規則エンジンに記憶された規則セットに従って機能し得ることに注目されたい。たとえば、ソースデータベースで行なわれる変更を取得するために用いられる取得プロセスは、ユーザが登録した規則に従って機能し得る。これらの規則は、特に、どの変更を取得すべきか、変更をどのように変換すべきか、および、それらの変更を表わすＬＣＲをどのように
生成してタグをつけるか、を規定することができる。同様に、伝播プロセス、適用プロセス、およびさまざまなハンドラのプロシージャもすべて、規則駆動型であり得る。
一実施例に従い、これらのさまざまな構成要素は、登録された規則セットが存在しない場合にこれらの構成要素が行なうデフォルト機能を備えて設計される。
複製の例
上述のように、データベースサーバ（以降「ソースサーバ」）の再実行ログからの情報は、取得プロセスにより、ステージングエリアに選択的に追加され得る。そして、消費プロセスは、ステージングエリアからソースサーバ外のプロセスにこの情報を選択的に提供することができる。変更情報は、たとえば、異なるデータベースサーバ（以降「ターゲット」データベースサーバ）内のプロセスに提供され得る。それにより、ターゲットデータベースサーバ内のプロセスは、ソースデータベースサーバからの変更情報を用いて、ターゲットデータベース内に存在する情報を、ソースデータベースサーバ内の対応する情報と同期させて維持することができる。たとえば、プロセスは、ソースデータベースサーバ内のテーブルＴ２に対して行なわれた変更に基づき、ターゲットデータベースサーバ内のテーブルＴ１を更新することができ、それによってＴ１は、Ｔ２の複製として働き得る。
再実行ログおよび取得プロセスのオラクルベースの例
オラクルのデータベースの各々は、２つ以上の再実行ログファイルからなる組を有する。データベース用の再実行ログファイルは、総称して、データベースの再実行ログとして公知である。再実行ログの主な機能は、データベースに対して行なわれたすべての変更を記録することである。
再実行ログは、ヒューマンエラーまたは媒体の故障の場合に回復性を保証するために用いられる。一実施例に従い、情報共有システム１００の取得プロセスは、データベースの再実行ログを読出し、そしてデータベースオブジェクトに対して行なわれたＤＭＬ変更およびＤＤＬ変更を取得する任意のオラクルバックグラウンドプロセスとして、実現される。取得プロセスが、再実行ログからの変更を取得するように設定されている場合、変更が生じたデータベースをソースデータベースと呼ぶ。
論理変更記録（ＬＣＲ）
取得プロセスは、再実行ログから取得した変更を、ＬＣＲに再フォーマット化する。ＬＣＲは、データベースの変更を記述するオブジェクトである。一実施例に従い、取得プロセスは、列ＬＣＲおよびＤＤＬ ＬＣＲを含む、複数の種類のＬＣＲを取得する。
取得プロセスは、ＬＣＲを取得した後に、ＬＣＲを含むイベントをキューにエンキューする。取得プロセスは、１つのSYS.AnyDataキューと常に関連付けられており、このキューにのみイベントをエンキューする。ユーザは、複数のキューを作成して、各キューに異なる取得プロセスを関連付けることができる。図３は、ＬＣＲを取得する取得プロセスを示す。
行ＬＣＲは、１つの行内のデータに対する変更か、または行内の１つのＬＯＢ列に対する変更を記述する。変更は、データ操作言語（ＤＭＬ）のステートメントか、またはＬＯＢへの区分的な更新から生じる。たとえば、ＤＭＬステートメントは、テーブル内に複数の行を挿入もしくはマージするか、テーブル内の複数の行を更新するか、またはテーブルから複数の行を削除することができる。したがって、１つのＤＭＬステートメントが複数の行ＬＣＲを生成することができる。すなわち、取得プロセスは、ＤＭＬステートメントにより変更された各行に対してＬＣＲを作成する。さらに、ＤＭＬステートメント自体は、多くのＤＭＬステートメントを含むトランザクションの一部であり得る。
取得された行ＬＣＲはまた、トランザクション制御のステートメントも含み得る。これらの行ＬＣＲは、ＣＯＭＭＩＴおよびＲＯＬＬＢＡＣＫ等の指示文を含む。これらの行ＬＣＲは、内部的なものであり、適用プロセスによって用いられてソースデータベースと宛先データベースとの間のトランザクションの整合性を維持する。
一実施例に従い、各行ＬＣＲは、以下の情報を含む。
・行の変更が生じたソースデータベースの名前。
・ＩＮＳＥＲＴ、ＵＰＤＡＴＥ、ＤＥＬＥＴＥ、ＬＯＢ ＥＲＡＳＥ、ＬＯＢ ＷＲＩＴＥ、またはＬＯＢ ＴＲＩＭのいずれかの変更を生じたＤＭＬステートメントの型。
・変更された行を有するテーブルを含むスキーマ名。
・変更された行を含むテーブルの名前。
・ＬＣＲの経過を追うために用いられ得る未処理のタグ。
・ＤＭＬステートメントが遂行されたトランザクションの識別子。
・変更が再実行ログに書込まれたときのシステム変更番号（ＳＣＮ）。
・変更に関連する古い値。ＤＭＬステートメントの型がＵＰＤＡＴＥまたはＤＥＬＥＴＥである場合、これらの古い値は、ＤＭＬステートメントの前の変更された行内の列のいくつかまたはすべてを含む。ＤＭＬステートメントの型がＩＮＳＥＲＴである場合、古い値は存在しない。
・変更に関連する新規の値。ＤＭＬステートメントの型がＵＰＤＡＴＥまたはＩＮＳＥＲＴのステートメントである場合、これらの新規の値は、ＤＭＬステートメントの後の変更された行内の列のいくつかまたはすべてを含む。ＤＭＬステートメントの型がＤＥＬＥＴＥである場合、新規の値は存在しない。
ＤＤＬ ＬＣＲは、データ定義言語（ＤＤＬ）の変更を記述する。ＤＤＬステートメントは、データベースの構造を変更する。たとえば、ＤＤＬステートメントは、データベースオブジェクトの作成、変更、またはドロップを行なうことができる。
一実施例に従い、各ＤＤＬ ＬＣＲは、以下の情報を含む。
・ＤＤＬの変更が生じたソースデータベースの名前。
・変更を生じたＤＤＬステートメントの型、たとえばＡＬＴＥＲ ＴＡＢＬＥまたはＣＲＥＡＴＥ ＩＮＤＥＸ。
・ＤＤＬステートメントが実行されたデータベースオブジェクトを所有するユーザのスキーマ名。
・ＤＤＬステートメントが実行されたデータベースオブジェクトの名前。
・ＤＤＬステートメントが実行されたデータベースオブジェクトの型、たとえばＴＡＢ
ＬＥまたはＰＡＣＫＡＧＥ。
・ＤＤＬステートメントのテキスト。
・そのセッションがＤＤＬステートメントを実行したユーザである、ログオンユーザ。
・ＤＤＬテキスト内のオブジェクトに対してスキーマが指定されていない場合に用いられるスキーマ。
・ベーステーブルの所有者。ＤＤＬステートメントがテーブルに従属している場合、ベーステーブルの所有者は、ＤＤＬステートメントが従属するテーブルの所有者である。
・ベーステーブルの名前。ＤＤＬステートメントがテーブルに従属している場合、ベーステーブルの名前は、ＤＤＬステートメントが従属するテーブルの名前である。
・ＬＣＲの経過を追うために用いられ得る未処理のタグ。
・ＤＤＬステートメントが実行されたトランザクションの識別子。
・変更が再実行ログに書込まれたときのＳＣＮ。
取得規則
一実施例に従い、情報共有システム１００内の取得プロセス（取得プロセス１１６等）は、ユーザが定義する規則に基づいて変更を取得する。各規則は、取得プロセスが変更を取得するデータベースオブジェクトと、取得すべき変更の種類とを指定する。一実施例において、ユーザは、以下のレベルにおいて取得規則を指定することができる。
・テーブル規則は、特定のテーブルに対するＤＭＬ変更またはＤＤＬ変更のいずれかを取得する。
・スキーマ規則は、特定のスキーマ内のデータベースオブジェクトに対するＤＭＬ変更またはＤＤＬ変更のいずれかを取得する。
・グローバル規則は、データベース内のすべてのＤＭＬ変更またはすべてのＤＤＬ変更のいずれかを取得する。
取得プロセスの規則評価
稼動中の取得プロセスは、変更を取得するための以下の一連のアクションを完了する。
１．再実行ログ内の変更を発見する。
２．再実行ログ内の変更のプレフィルタリングを実施する。取得プロセスは、このステップの間に、オブジェクトレベルおよびスキーマレベルにおけるその規則セット内の規則を評価して、再実行ログ内で発見した変更を、２つのカテゴリ、すなわち、ＬＣＲに変換されるべき変更と、ＬＣＲに変換されるべきではない変更とに分ける。
プレフィルタリングは、不完全な情報によって行なわれる安全な最適化である。このステップは、後に処理されるべき妥当な変更を識別し、それにより、
１つ以上の規則が変換後にＴＲＵＥと評価され得る場合、変更をＬＣＲに変換するようにし、
変換後にＴＲＵＥと評価する規則が何ら存在しないことを取得プロセスが保証できる場合、変更がＬＣＲに変換されないようにする。
３．１つ以上の規則にＴＲＵＥと評価させ得る変更を、プレフィルタリングに基づいて変換する。
４．ＬＣＲのフィルタリングを実施する。取得プロセスは、このステップの間に、各ＬＣＲ内の情報に関する規則を評価して、ＬＣＲを２つのカテゴリに、すなわち、エンキューされるべきＬＣＲと廃棄されるべきＬＣＲとに分ける。
５．規則に基づき、エンキューされるべきではないＬＣＲを廃棄する。
６．残りの取得したＬＣＲを、取得プロセスに関連付けられたキューにエンキューする。
たとえば、取得プロセスに対して以下の規則が定義されているものと仮定されたい。
部門-id ５０であるhr.従業員のテーブルに対する変更を取得する。
取得プロセスに対して他の規則は定義されず、取得プロセスに対する並列処理パラメータは１にセットされる。
この規則の場合、hr.従業員のテーブル上のＵＰＤＡＴＥステートメントが、テーブル内の５０行を変更するものと仮定されたい。取得プロセスは、各行の変更に対し、以下の一連のアクションを実施する。
１．再実行ログ内のＵＰＤＡＴＥステートメントから生じた次の変更を発見する。
２．ＵＰＤＡＴＥステートメントからhr.従業員のテーブルに生じた変更が取得されなければならないと判定する。この変更が異なるテーブルに対して行なわれた場合、取得プロセスはその変更を無視する。
３．変更を取得してその変更をＬＣＲに変換する。
４．ＬＣＲをフィルタリングして、部門idが５０である行をＬＣＲが含むかどうかを判定する。
５．部門-idが５０である行をＬＣＲが含む場合、取得プロセスに関連付けられたキューにそのＬＣＲをエンキューする。または、部門-idが５０ではないか、もしくは失われた行をＬＣＲが含む場合、そのＬＣＲを廃棄する。
イベントのステージングおよび伝播の概観
情報共有システム１００は、イベントをステージングするために、型SYS.AnyDataのキューを用いる。キューにステージングされ得る２種類のイベント、すなわち、論理変更記録（ＬＣＲ）と、ユーザメッセージとが存在する。ＬＣＲは、データベースオブジェクトに対する変更についての情報を含むオブジェクトであり、ユーザメッセージは、ユーザまたはアプリケーションによって作成されたカスタムメッセージである。両方の種類のイベントは、型SYS.AnyDataを有し、１つのデータベース内で、またはデータベース間において情報を共有するために用いられ得る。
ステージングされたイベントは、消費もしくは伝播され得、または、その両方が行なわ
れうる。これらのイベントは、適用プロセスか、またはそれらのイベントを明示的にデキューするユーザアプリケーションによって消費され得る。イベントが消費された後であっても、ユーザが、１つの以上の他のキューにイベントを伝播するように情報共有システム１００を設定している場合、または、メッセージの保存が指定されている場合、そのイベントはキュー内に残り得る。これらの他のキューは、同じデータベース内または異なるデータベース内に存在し得る。いずれの場合も、イベントがそこから伝播されるキューをソースキューと呼び、イベントを受信するキューを宛先キューと呼ぶ。ソースキューと宛先キューとの間には、１対多、多対１、または多対多の関係が存在し得る。図４は、ソースキューから宛先キューへの伝播を示す。
一実施例に従い、データ項目の伝播中に、情報項目の順序付けが維持される。順序の維持は、項目の順序が機能上の分派を有する際に特に有用である。たとえば、伝播されている項目が、データベースシステムに対して行なわれた変更である場合、伝播された変更が、それらが従属する伝播された変更の後にターゲットシステムにおいて行なわれるように順序を維持することが重要である。
ユーザは、伝播を生じ、変更し、ドロップすることができ、ユーザは、どのイベントが伝播されるべきかを制御する伝播規則を定義することができる。ソースキューを所有するユーザは、イベントを伝播するユーザである。このユーザは、イベントを伝播するために必要な特権を有していなければならない。これらの特権は、以下のものを含む。
・伝播が用いる規則セットに対する実行特権。
・規則セットで用いられるすべての変換関数に対する実行特権。
・宛先キューが同じデータベース内に存在する場合、宛先キューに対する実行特権。
取得されてユーザによりエンキューされたイベント
一実施例に従い、イベントは、以下の２つの態様でエンキューされ得る。
・取得プロセスは、ＬＣＲを含むイベントの形で、取得された変更をエンキューする。取得プロセスにより最初に取得されてエンキューされたＬＣＲを含むイベントを、取得されたイベントと呼ぶ。
・ユーザアプリケーションは、型SYS.AnyDataのユーザメッセージをエンキューする。これらのユーザメッセージは、ＬＣＲまたは他の任意の型のメッセージを含み得る。ユーザまたはアプリケーションによって明示的にエンキューされた任意のユーザメッセージを、ユーザがエンキューしたイベントと呼ぶ。適用プロセスから呼出されたユーザプロシージャによりエンキューされたイベントもまた、ユーザがエンキューしたイベントと呼ぶ。
したがって、取得されたイベントの各々はＬＣＲを含むが、ユーザがエンキューしたイベントは、ＬＣＲを含むか、または含まないことが考えられる。取得されたイベントまたはユーザがエンキューしたイベントを伝播することにより、宛先キュー内にイベントがエンキューされる。
一実施例に従い、イベントは以下の２つの態様でデキューされ得る。
・適用プロセスは、取得されたイベントか、またはユーザがエンキューしたイベントをデキューする。イベントがＬＣＲを含む場合、適用プロセスは、処理のために、そのイベントを直接適用することができ、または、ユーザが指定したプロシージャを呼出すことが
できる。イベントがＬＣＲを含んでいない場合、適用プロセスは、ユーザが指定した、メッセージハンドラと呼ばれるプロシージャを呼出して、イベントを処理することができる。
・ユーザアプリケーションは、ユーザがエンキューしたイベントを明示的にデキューして、それらのイベントを処理する。取得されたイベントは、ユーザアプリケーションによってデキューされ得ない。すなわち、取得されたイベントは、適用プロセスによってデキューされなければならない。しかしながら、適用プロセスが呼出したユーザプロシージャがイベントを明示的にエンキューする場合は、そのイベントが本来取得されたイベントである場合でも、そのイベントは、ユーザがエンキューしたイベントであり、明示的にデキューされ得る。
デキューされたイベントは、それらのイベントがデキューされた同じデータベースで発生したことが考えられ、または、異なるデータベースで発生したことが考えられる。
キュー間でのイベントの伝播
ユーザは、情報共有システム１００を用いて、異なるデータベース内に存在し得る２つのキュー間におけるイベントの伝播を設定することができる。情報共有システム１００は、ジョブキューを用いてイベントを伝播する。
一実施例に従い、伝播は、ソースキューと宛先キューとの間で生じる。伝播は２つのキュー間で生じるが、１つのキューが多くの伝播に関与し得る。すなわち、１つのソースキューが、複数の宛先キューにイベントを伝播することができ、１つの宛先キューが、複数のソースキューからイベントを受信することができる。一実施例によると、特定のソースキューと特定の宛先キューとの間で１つの伝播しか許容されない。また、１つのキューが或る伝播に対する宛先キューであり、また或る伝播に対するソースキューであることが考えられる。
伝播は、ソースキュー内のすべてのイベントを宛先キューに伝播することができ、または、伝播は、それらのイベントのサブセットのみを伝播することができる。また、１つの伝播は、取得されたイベントおよびユーザがエンキューしたイベントの両方を伝播することができる。ユーザは、規則を用いて、ソースキュー内のどのイベントが宛先キューに伝播されるべきかを制御することができる。
ユーザがどのように情報共有システム１００の環境をセットアップしたかに依存して、変更は、変更が発生したサイトに送り返され得る。ユーザは、変更が無限ループ内をサイクリングしないように、環境を確実に設定する必要がある。ユーザは、タグを用いて、このような変更のサイクルループを回避することができる。
伝播規則
伝播は、ユーザが定義した規則に基づいてイベントを伝播する。各規則は、イベントに対し、この伝播が変更を伝播するデータベースオブジェクトと、伝播すべき変更の種類とを指定する。ユーザは、以下のレベルにおいて、イベントに対する伝播規則を指定することができる。
・テーブル規則は、特定のテーブルに対するＤＭＬ変更またはＤＤＬ変更のいずれかを伝播する。
・スキーマ規則は、特定のスキーマ内のデータベースオブジェクトに対するＤＭＬ変更またはＤＤＬ変更のいずれかを伝播する。
・グローバル規則は、ソースキュー内のすべてのＤＭＬ変更またはすべてのＤＤＬ変更のいずれかを伝播する。
ユーザは、非ＬＣＲイベントおよび特別な必要性を備えたＬＣＲイベントに対し、独自の規則を作成して伝播を制御することができる。
条件を指定するキューのサブスクライバは、システムに規則を生成させる。キューのサブスクライバのすべてに対する規則セットは組み合わされて、システムが生成した１つの規則セットとなり、サブスクリプションをより高効率にする。
適用プロセスの概観
一実施例に従い、適用プロセスは、特定のキューからの論理変更記録（ＬＣＲ）およびユーザメッセージをデキューして、そしてその各々を直接適用するか、またはユーザが定義したプロシージャにパラメータとして渡す、バックグラウンドプロセスである。適用プロセスがデキューしたＬＣＲは、適用プロセスが宛先データベース内のデータベースオブジェクトに適用することのできる、データ操作言語（ＤＭＬ）の変更またはデータ定義言語（ＤＤＬ）の変更を含む。ユーザが定義して適用プロセスがデキューしたメッセージは、型SYS.AnyDataを有し、ユーザが作成したＬＣＲを含む任意のユーザメッセージを含み得る。
適用プロセスが適用したイベントは、適用ユーザによって適用される。適用ユーザは、すべてのＤＭＬステートメントおよびＤＤＬステートメントを適用し、かつ、ユーザが定義した適用ハンドラを実行するユーザである。
適用規則
適用プロセスは、ユーザが定義した規則に基づいて変更を適用する。各規則は、適用プロセスが変更を適用するデータベースオブジェクトと、適用すべき変更の種類とを指定する。ユーザは、以下のレベルにおいて適用規則を指定することができる。
・テーブル規則は、特定のテーブルに、ＤＭＬ変更またはＤＤＬ変更を適用する。サブセット規則は、特定のテーブルに対する変更のサブセットを含むテーブル規則である。
・スキーマ規則は、特定のスキーマ内のデータベースオブジェクトに、ＤＭＬ変更またはＤＤＬ変更のいずれかを適用する。
・グローバル規則は、適用プロセスに関連付けられたキューにおいて、すべてのＤＭＬ変更またはすべてのＤＤＬ変更のいずれかを適用する。
ユーザは、非ＬＣＲのイベントおよび特別な必要性を備えたＬＣＲのイベントに対して独自の規則を作成し、適用プロセスの機能を制御することができる。
適用プロセスによるイベント処理
適用プロセスは、キュー内のイベントを処理するための、柔軟性に富んだメカニズムである。ユーザは、読者の環境に対して１つ以上の適用プロセスをいつ設定するかを考慮するためのオプションを有する。この章では、適用プロセスが適用し得るイベントの種類と、適用プロセスがそれらのイベントを適用し得る態様とを論じる。
一実施例によると、１つの適用プロセスは、取得されたイベントまたはユーザがエンキューしたイベントのいずれかを適用することができるが、両方を適用することはできない
。宛先データベースのキューが、取得されたイベントおよびユーザがエンキューしたイベントの両方を含む場合、宛先データベースは、それらのイベントを処理するために、少なくとも２つの適用プロセスを有していなければならない。
一実施例に従い、ユーザが適用プロセスを作成すると、ユーザは、適用が取得したパラメータを用いて、取得されたイベントまたはユーザがエンキューしたイベントを適用プロセスが適用するか否かを指定する。
イベントが発生したデータベースは、取得されたイベントに対する適用プロセスには重要であるが、ユーザがエンキューしたイベントに対する適用プロセスには重要ではない。取得されたイベントにとって、ソースデータベースは、変更が再実行ログ内で生じたデータベースである。一実施例によると、ユーザがエンキューしたイベントに関し、適用プロセスは、そのイベントが、ユーザがエンキューしたＬＣＲであっても、イベントが発生したデータベースについての情報を無視する。１つの適用プロセスは、ユーザがエンキューし、かつ、異なるデータベースで生じたイベントを適用することができる。
イベント処理のオプション
イベント処理に対するオプションは、適用プロセスが受信したイベントの種類に依存する。図８は、適用プロセスに対するイベント処理のオプションを示す。
複数のデータベースからの取得されたＬＣＲは、１つの宛先キューに送信され得る。１つのキューが複数のデータベースから取得されたＬＣＲを含む場合、１つ以上の適用プロセスを用いて、これらのＬＣＲを検索することができる。複数の適用プロセスが用いられる場合、これらの適用プロセスの各々は、規則を用いて、厳密に１つのソースデータベースから取得されたＬＣＲを受信するように設定され得る。
ソースデータベース上で稼動する複数の取得プロセスが存在し、かつ、これらの取得プロセスの２つ以上からのＬＣＲが宛先データベースにおいて適用される場合、１つ以上の適用プロセスを用いてこれらの変更を適用することができる。
ユーザは、処理のために、イベントを直接適用するか、またはユーザプロシージャにパラメータとしてイベントを渡すか、のいずれかの態様で、ＬＣＲを含む、取得されたイベントまたはユーザがエンキューしたイベントを処理するように適用プロセスを設定することができる。以下の章では、これらのオプションを説明する。
ＬＣＲイベントを直接適用する。ユーザがこのオプションを用いる場合、適用プロセスは、ユーザプロシージャを実行せずにイベントを適用する。適用プロセスは、ＬＣＲにおける変更を成功裡にデータベースオブジェクトに適用し、または、矛盾エラーまたは適用エラーに遭遇した場合、矛盾ハンドラか、もしくはユーザが指定してエラーハンドラと呼ばれるプロシージャを用いて、エラーを解消しようとする。
矛盾ハンドラが矛盾を解決できる場合、適用プロセスは、ＬＣＲを適用するか、または、ＬＣＲ内の変更を廃棄する。エラーハンドラがエラーを解消できる場合、適用プロセスは、適切であればＬＣＲを適用すべきである。エラーハンドラは、ＬＣＲを適用する前にＬＣＲを変更することによってエラーを解消することができる。エラーハンドラがエラーを解消できない場合、適用プロセスは、トランザクションと、そのトランザクションに関連付けられたすべてのＬＣＲとを例外キュー内に配置する。
ユーザプロシージャを呼出してＬＣＲイベントを処理する。ユーザがこのオプションを用いる場合、適用プロセスは、処理のために、ユーザプロシージャにパラメータとしてイ
ベントを渡す。それにより、ユーザプロシージャは、カスタマイズされた態様でこのイベントを処理することができる。
ＤＭＬステートメントから生じた行ＬＣＲを処理するユーザプロシージャは、ＤＭＬハンドラと呼ばれ、ＤＤＬステートメントから生じたＤＤＬ ＬＣＲを処理するユーザプロシージャは、ＤＤＬハンドラと呼ばれる。適用プロセスは、多くのＤＭＬハンドラおよびＤＤＬハンドラを有し得る。
ユーザは、適用プロセスに関連付けられた各テーブルに対して別個のＤＭＬハンドラをセットして、行ＬＣＲ内の以下の種類の演算、すなわち、
ＩＮＳＥＲＴ ＵＰＤＡＴＥ ＤＥＬＥＴＥ ＬＯＢ ＵＰＤＡＴＥ
の各々を処理することができる。
たとえば、hr.従業員のテーブルは、ＩＮＳＥＲＴ演算を処理するための１つのＤＭＬハンドラと、ＵＰＤＡＴＥ演算を処理するための異なるＤＭＬハンドラとを有し得る。
ユーザプロシージャは、カスタマイズされたＬＣＲ処理のために用いられ得る。たとえば、ソースデータベースにおける特定のテーブル内への各挿入が、宛先データベースにおける複数のテーブル内への挿入を生じることをユーザが望む場合、ユーザは、テーブル上でＩＮＳＥＲＴ演算を処理するユーザプロシージャを作成して、このことを達成することができる。または、ユーザがＤＤＬ変更を適用する前にこのＤＤＬ変更のログを取ることを望む場合、ユーザは、ＤＤＬ演算を処理するユーザプロシージャを作成して、このことを達成することができる。
非ＬＣＲのユーザメッセージの処理
ユーザがエンキューしたイベントが、適用プロセスに対する規則セット内の少なくとも１つの規則を満たす場合、ユーザがエンキューしてＬＣＲを含まないイベントは、適用プロセスに対して指定されたメッセージハンドラによって処理される。メッセージハンドラは、読者の環境に対してカスタマイズされた態様で非ＬＣＲのユーザメッセージを処理することのできる、ユーザが定義したプロシージャである。
メッセージハンドラは、１つ以上の遠隔のデータベースを更新しなければならないか、または他の何らかの遠隔のアクションを実施しなければならないアプリケーションを有する任意の環境において、利点を提供する。これらのアプリケーションは、ローカルなデータベースにおけるキュー内にユーザメッセージをエンキューすることができ、情報共有システム１００は、宛先データベースにおける適切なキューに各ユーザメッセージを伝播することができる。複数の宛先が存在する場合、情報共有システム１００は、自動的な伝播と、これらの宛先におけるこれらのメッセージの処理とのためのインフラストラクチャを提供する。１つの宛先しか存在しない場合でも、情報共有システム１００は、ソースデータベースにおけるアプリケーションと宛先データベースにおけるアプリケーションとの間にレイヤを設ける。それにより、遠隔のデータベースにおけるアプリケーションが利用不可能になった場合でも、ソースデータベースにおけるアプリケーションは、引続き正常に機能することができる。
たとえば、メッセージハンドラは、ユーザメッセージを電子メールメッセージにフォーマット化することができる。この場合、ユーザメッセージは、電子メールメッセージにユーザが期待する属性、たとえば発信元、発信先、件名、メッセージのテキスト等を含み得る。メッセージハンドラは、これらのユーザメッセージを電子メールメッセージに変換することができ、電子メールのゲートウェイ経由でこれらの電子メールメッセージを送信することができる。
適用プロセスの構成要素
この発明の一実施例に従い、適用プロセスは、リーダサーバ、コーディネータプロセス、および１つ以上の適用サーバを含む。
リーダサーバは、イベントをデキューする。リーダサーバは、ＬＣＲ間の従属性を計算してイベントをトランザクションにアセンブルする並列実行サーバである。そして、リーダサーバは、アセンブルしたトランザクションをコーディネータに返し、コーディネータは、使用されていない適用サーバにそれらのトランザクションを割当てる。
コーディネータプロセスは、リーダからトランザクションを得て、それらのトランザクションを適用サーバに渡す。適用サーバは、ＤＭＬステートメントまたはＤＤＬステートメントとしてＬＣＲをデータベースオブジェクトに適用し、または、ＬＣＲをそれらの適切なハンドラに渡す。非ＬＣＲのメッセージの場合、適用サーバは、イベントをメッセージハンドラに渡す。各適用サーバは、並列実行サーバである。適用サーバがエラーに遭遇した場合、適用サーバは、ユーザが指定したエラーハンドラを用いてエラーを解消しようとする。適用サーバがエラーを解消できない場合、適用サーバはトランザクションをロールバックして、そのイベントのすべてを含む全トランザクションを例外キュー内に配置する。
適用サーバが、完成したトランザクションをコミットすると、このトランザクションは適用されたことになる。適用サーバが例外キューにトランザクションを配置してコミットすると、このトランザクションも適用されたことになる。
適用サーバが処理しているトランザクションが、適用されたと認識されていない別のトランザクションとの従属性を有する場合、適用サーバはコーディネータに接触して指示を待つ。コーディネータはすべての適用サーバを監視して、トランザクションが確実に正しい順序で適用されてコミットされるようにする。
たとえば、これらの２つのトランザクションを考えられたい。
１．行がテーブル内に挿入される。
２．この同じ行が更新されて、特定の列の値を変更する。
この場合、トランザクション２は、トランザクション１に従属する。なぜなら、行がテーブル内に挿入されて初めてその行が更新され得るためである。これらのトランザクションが、ソースデータベースにおける再実行ログから取得され、宛先データベースに伝播され、宛先データベースにおいて適用されるものと仮定されたい。適用サーバＡは挿入のトランザクションを処理し、適用サーバＢは更新のトランザクションを処理する。
適用サーバＡが挿入のトランザクションを適用する前に適用サーバＢが更新のトランザクションを適用する準備ができている場合、適用サーバＢはコーディネータからの指示を待つ。適用サーバＡが挿入のトランザクションを適用した後、コーディネータプロセスは、適用サーバＢに更新のトランザクションを適用するように指示する。
規則の構成要素
一実施例によると、規則は、イベントが生じて条件が満たされたときにクライアントによるアクションの実施を可能にするデータベースオブジェクトである。規則は、一実施例に従って情報共有システム１００を管理するデータベースサーバ内に構築された規則エン
ジンによって評価される。ユーザが作成したアプリケーションおよび情報共有システム１００はともに、規則エンジンのクライアントであり得る。一実施例に従い、規則は、以下の構成要素、すなわち、
・規則条件
・規則評価のコンテキスト（任意）
・規則アクションのコンテキスト（任意）
を含む。
各規則は、ＳＱＬクエリーのＷＨＥＲＥ句内の条件と同様の要件として指定される。ユーザは、関連する規則を共にグループ化して、規則セットにすることができる。１つの規則は、１つの規則セットもしくは複数の規則セット内に存在することが考えられ、または、規則セット内に存在しないことが考えられる。
規則条件は、１つ以上の式および演算子を組合せて、ＴＲＵＥ、ＦＡＬＳＥ、またはＮＵＬＬ（未知）の値であるブール値を返す。式は、或る値に評価する１つ以上の値と演算子との組合せである。値は、テーブル内のデータ、変数内のデータ、または、ＳＱＬ関数もしくはＰＬ／ＳＱＬ関数により返されたデータであり得る。たとえば、以下の条件は、２つの式（部門-idおよび３０）と演算子（−）とを含む。
部門 id = 30
この論理条件は、部門-id列が３０であると、所定の行についてＴＲＵＥと評価する。ここで、値は、テーブルの部門 id 列内のデータである。
１つの規則条件は、ＡＮＤ、ＯＲ、およびＮＯＴの条件付き演算子と組合された２つ以上の条件を含んで、複合条件を形成することができる。たとえば、以下の複合条件を考えられたい。
部門 id = 30 ＯＲ job_title = 'プログラマ'
この規則条件は、ＯＲ条件付き演算子により結合された２つの条件を含む。いずれかの条件がＴＲＵＥと評価した場合、規則条件は、ＴＲＵＥと評価する。条件付き演算子がＯＲではなくＡＮＤであれば、規則条件の全体がＴＲＵＥと評価するために、両方の条件がＴＲＵＥと評価しなければならなくなってしまう。
規則条件内の変数
規則条件は、変数を含み得る。一実施例に従い、規則条件内の変数の前にはコロン（：）が置かれる。以下は、規則条件内で用いられる変数の一例である。
:x = 55
変数は、テーブル内に記憶されていないデータをユーザが参照することを可能にする。変数はまた、一般に生じる式に取って代わることによってパフォーマンスを改善することもできる。パフォーマンスが改善し得るのは、同じ式を複数回評価する代わりに変数を一回評価するためである。
規則条件は、サブプログラムの呼出の評価も含み得る。これらの条件は、他の条件と同様の態様で評価される。すなわち、これらの条件は、ＴＲＵＥ、ＦＡＬＳＥ、または未知の値と評価される。以下は、is_Managerと名付けられた、従業員が管理職であるか否かを判定する単葉関数の呼出を含む条件の一例である。
is_manager(従業員 id) = 'Y'
ここで、従業員_idの値は、従業員_idが列であるテーブル内のデータにより求められる
。
ユーザは、変数に対し、ユーザが定義した型を用いることができる。したがって、変数は属性を有し得る。変数が属性を有するとき、各属性は、変数に対する部分的なデータを含む。規則条件において、ユーザは、ドット表記を用いて属性を指定する。たとえば以下の条件は、変数ｙにおける属性ｚの値が９である場合、ＴＲＵＥと評価する。
:y.z =9
単純な規則条件
単純な規則条件は、以下の形態のいずれかを有する条件である。
・単純な規則式 演算子 定数
・定数 演算子 単純な規則式
規則の構成要素
単純な規則条件において、単純な規則式は、以下のうちの１つである。
・テーブルの列、
・変数、
・変数の属性、および
・方法の結果。ここで、この方法は引き数を取らず、この方法の結果は、変数方法関数により返され得、それによって式は、数字型または文字型のいずれかとなる。
テーブルの列に対し、変数、変数の属性、すべての数値（ＮＵＭＢＥＲ、ＦＬＯＡＴ、ＤＯＵＢＬＥ、ＩＮＴＥＧＥＲ）および文字（ＣＨＡＲ、ＶＡＲＣＨＡＲ２）の型がサポートされる。他の型の式を用いることにより、非単純な規則条件が生じる。
単純な規則条件において、演算子は以下のうちの１つである。
＝，＜＝，または＞＝
他の演算子を用いることにより、非単純な規則条件が生じる。定数は固定値である。定数は、以下のものであり得る。
数、たとえば１２または５．４。
文字、たとえばｘまたは＄。
文字列、たとえば「this is a string」。したがって、以下の条件は、単純な規則条件、すなわち、tabl.col = 5である。
・ :vl>'aaa'
・ :v2.al<10.01
・ :v3.m() = 10
規則セットの評価
規則エンジンは、イベントに基づいて規則セットを評価する。イベントは、規則エンジンのクライアントが定義するオカレンスである。クライアントは、DBMS-RULE.EVALUATE プロシージャを呼出すことによってイベントの評価を開始する。クライアントがDBMS-RULE.EVALUATEプロシージャを呼出す際にクライアントが指定する情報は、以下のものを含む。
イベントを評価するために用いるための規則を含む規則セットの名前。評価のために用
いるための評価のコンテキスト。指定された評価のコンテキストを用いる規則のみが評価される。
テーブル値および変数値。テーブル値は、テーブルの行内のデータを指す行id を含み、変数値は、明示的な変数に対するデータを含む。暗黙的な変数に対して指定された値は、変数値評価関数を用いて得ることのできる値を無効にする。指定された変数が属性を有する場合、クライアントは、変数の全体に対する値を送ることができ、または、クライアントは、任意の数の変数の属性に対する値を送ることができる。しかしながら、クライアントは、変数全体の値が指定されていない場合、属性値を指定することができない。
任意のイベントのコンテキスト。イベントのコンテキストは、イベントに関する情報を含む名前−値の対を含む型SYS.RE＄NV_LISTの可変長アレイである。この任意の情報は、規則エンジンによって直接に使用または解釈されない。その代わりに、この任意の情報は、クライアントのコールバック、たとえば評価関数、変数値評価関数（暗黙的な変数用）、および変数方法関数に渡される。
クライアントは、イベントに関する他の情報について、および、DBMS-RULE.EVALUATEプロシージャを用いてイベントをどのように評価するかについての情報を送ることもできる。たとえば発呼者は、第１のＴＲＵＥ規則または第１のＭＡＹＢＥ規則（ＴＲＵＥ規則が存在しない場合）が発見されるとすぐに評価を停止しなければならないかどうかを指定することができる。
規則エンジンは、指定された規則セット内の規則を用いてイベントを評価する。そして、規則エンジンは、その結果をクライアントに返す。規則エンジンは、ＥＶＡＬＵＡＴＥプロシージャ内の２つのＯＵＴパラメータ、すなわち、true-rulesおよびmaybe_rulesを用いて規則を返す。すなわち、true rulesパラメータは、ＴＲＵＥと評価する規則を返し、任意に、maybe_rulesパラメータは、より多くの情報の場合にＴＲＵＥと評価し得る規則を返す。
図１４は、規則セットの評価プロセスを示す。
１．クライアントが定義したイベントが生じる。
２．クライアントは、DBMS_RULE.EVALUATEプロシージャを実行することにより、規則エンジンにイベントを送る。
３．規則エンジンは、規則セット内の規則および関連する評価のコンテキストに基づいてイベントを評価する。クライアントは、DBMS_RULE.EVALUATEプロシージャの呼出において、規則セットおよび評価のコンテキストの両方を指定する。指定された規則セット内に存在しかつ指定された評価のコンテキストを用いる規則のみが、評価に用いられる。
４．規則エンジンは、評価の結果を得る。各規則は、ＴＲＵＥ、ＦＡＬＳＥ、またはＮＵＬＬ（未知）のいずれかに評価する。
５．規則エンジンは、ＴＲＵＥと評価した規則をクライアントに返す。返された規則の各々は、情報を有し得るかまたはＮＵＬＬであり得るアクションのコンテキストの全体と共に返される。
６．クライアントは、規則エンジンが返した結果に基づいてアクションを実施する。規則エンジンは、規則の評価に基づいてアクションを実施しない。
情報共有システム１００内でどのように規則が用いられるかについての概観
情報共有システム１００において、以下のメカニズム、すなわち、取得プロセス、伝播、および適用プロセスの各々は、規則エンジンのクライアントであり、そのとき、このメカニズムは規則セットに関連付けられる。
一実施例において、これらのメカニズムの各々は、多くても１つの規則セットに関連付けられ得る。しかしながら、同じデータベース内の複数の取得プロセス、伝播、および適用プロセスにより、１つの規則セットが用いられ得る。図１５は、規則エンジンの複数のクライアントが１つの規則セットをどのように用い得るかを示す。
具体的に、ユーザは、情報共有システム１００内の規則セットを用いて、以下のことを行なう。
（１） 取得プロセスが再実行ログから取得する変更を指定する。すなわち、再実行ログ内で発見された変更が、取得プロセスに関連付けられた規則セット内の任意の規則にＴＲＵＥと評価させた場合、変更は取得プロセスにより取得される。
（２） 伝播が１つのキューから別のキューに伝播するイベントを指定する。すなわち、キュー内のイベントが、伝播に関連付けられた規則セット内の任意の規則にＴＲＵＥと評価させた場合、そのイベントは、伝播により伝播される。
（３） 適用プロセスがキューから検索するイベントを指定する。すなわち、キュー内のイベントが、適用プロセスに関連付けられた規則セット内の任意の規則にＴＲＵＥと評価させた場合、そのイベントは、適用プロセスにより検索されて処理される。
伝播または適用プロセスの場合、規則セットに照らして評価されたイベントは、取得されたイベントまたはユーザがエンキューしたイベントであり得る。
メカニズムに関連した、矛盾する規則が存在する場合、このメカニズムは、いずれかの規則がＴＲＵＥと評価する場合、タスクを実行する。たとえば、取得プロセスに関連付けられた規則セットが、hr.従業員のテーブルに対するＤＭＬ変更を取得するように取得プロセスに指示する１つの規則を含みつつ、hr.従業員のテーブルに対するＤＭＬ変更を取得しないように取得プロセスに指示する規則セット内の別の規則も含む場合、取得プロセスは、hr.従業員のテーブルに対するＤＭＬ変更を取得する。
システムが作成した規則
情報共有システム１００は、規則に基づき、３つのタスク、すなわち、取得プロセスを用いた変更の取得、伝播を用いた変更の伝播、および適用プロセスを用いた変更の適用を実施する。ユーザが作成した規則およびシステムが作成した規則の両方を用いて、これらのタスクの各々がどのように実施されるかを管理することができる。さらに、これらのタスクの任意の１つは、システムが作成した規則およびユーザが作成した規則の両方を含む１つの規則セットによって管理され得る。
システムが作成した規則は、タスクに対し、以下のレベルの細分性、すなわち、テーブル、スキーマ、またはグローバルの１つを指定する。この章では、これらのレベルの各々を説明する。ユーザは、特定のタスクに対して２つ以上のレベルを指定することができる。たとえば、ユーザは、oeスキーマ内の特定のテーブルに対してテーブルレベルの適用を実施し、かつ、hrスキーマの全体に対してスキーマレベルの適用を実施するように、１つの適用プロセスに指示することができる。
表６−１は、情報共有システム１００のタスクの各々に対して各レベルの規則がどのような意味を有するかを示す。
Figure 2006501585
規則ベースの変換および取得プロセス
取得プロセスが規則セットを用いる場合、取得中に変換が実施されるには以下の条件のいずれもが満たされなければならない。
規則が、再実行ログ内で発見された特定の変更についてＴＲＵＥと評価する。
アクションのコンテキストが、システムが認識する特定の名前を有する、名前−値の対を含む。
規則が評価されると、ＴＲＡＮＳＦＯＲＭ ＦＵＮＣＴＩＯＮが取得プロセスに返される。
これらの条件の場合、取得プロセスは、以下のステップを完了する。
１．再実行ログ内の変更をＬＣＲにフォーマット化する。
２．ＬＣＲをSYS.AnyDataオブジェクトに変換する。
３．名前−値の対においてＰＬ／ＳＱＬ関数を実行して、SYS.AnyDataオブジェクトを変換する。
４．変換したSYS.AnyDataオブジェクトを、取得プロセスに関連付けられたキュー内に
エンキューする。
図１６は、取得中の変換を示す。たとえば、イベントが取得中に変換された場合、変換されたイベントは、ソースキュー内にエンキューされる。したがって、取得されたこのようなイベントが、dbs1.netデータベースからdbs2.netおよびdbs3.netデータベースに伝播される場合、dbs2.netおよびdbs3.netにおけるキューは、伝播後に変換されたイベントを含む。
取得中に変換を実施する利点は、以下のようなものである。
変換が個人情報を除去または変更する場合、セキュリティが改善され得る。なぜなら、この個人情報は、ソースキューに出現せず、どのような宛先キューにも伝播されないためである。
実施される変換の種類に依存して、空間消費量を減らすことができる。たとえば、データ量を減らす変換により、エンキュー、伝播、および適用すべきデータが少なくなる。
変換されたイベントに複数の宛先が存在する場合に、変換のオーバーヘッドが少なくなる。なぜなら、変換が、複数の宛先ではなく１つのソースにおいてのみ実施されるためである。
取得中に変換を実施することについて考えられる欠点は、以下のようなものである。
・すべてのサイトが、変換されたイベントを受信する。
・変換のオーバーヘッドがソースデータベースで生じる。
・取得中における規則ベースの変換エラー。
取得中に変換関数が実行される際にエラーが生じた場合、変更は取得されず、エラーは取得プロセスに返され、取得プロセスは不能にされる。取得プロセスが可能にされ得る前に、ユーザはその規則ベースの変換を変更または除去してエラーを回避しなければならない。
規則ベースの変換および伝播
伝播が規則セットを用いる場合、伝播中に変換を実施するには以下の条件のいずれもが満たされなければならない。
・規則が、伝播のために、ソースキュー内のイベントについてＴＲＵＥと評価すること。このイベントは、取得されたイベントまたはユーザがエンキューしたイベントであり得る。
・アクションコンテキストが、システムに認識された特定の名前を有する、名前−値の対を含むこと。
・規則が評価されると、TRANSFORM-FUNCTIONが伝播に返されること。
これらの条件の場合、伝播は以下のステップを完了する。
１．ソースキューからのイベントのデキューを開始する。
２．名前−値の対においてＰＬ／ＳＱＬ関数を実行してイベントを変換する。
３．変換したイベントのデキューを完了する。
４．変換したイベントを、宛先キューに伝播する。
図１７は、伝播中の変換を示す。以下に提示するいくつかの例では、変換されている情報がＬＣＲの形を取っているが、上で説明したように、ＬＣＲは、システム１００を用いて共有され得る情報の一種に過ぎない。したがって、この明細書に記載する、規則ベースの変換を含むさまざまな技術は、共有される情報の形態に関係なく同様に適用される。
図１７を再び参照し、ユーザが、dbs1.netデータベースからdbs2.netデータベースへの伝播に規則ベースの変換を用いるものの、dbs1.netデータベースからdbs3.netデータベースへの伝播に規則ベースの変換を用いないものと仮定されたい。この場合、dbs1.netにおけるキュー内のイベントは、このイベントがdbs2.netに伝播される前に変換され得るが、その同じイベントは、dbs3.netに伝播される際にその本来の形のままであり得る。この場合、伝播後に、dbs2.netのキューは、変換されたイベントを含むが、dbs3.netのキューは、本来のイベントを含む。
伝播中に変換を実施する利点は以下のようなものである。
イベントが伝播される前に変換が個人情報を除去または変更する場合、セキュリティが改善され得る。
或る宛先キューは変換されたイベントを受信することができ、或る宛先キューは本来のイベントを受信することができる。
異なる宛先が、同じイベントの異なる変形物を受信し得る。伝播中に変換を実施することについて考えられる欠点は以下のようなものである。
イベントが一旦変換されると、第１の伝播後にイベントが伝播されるどのようなデータベースも、変換されたイベントを受信する。たとえば、dbs2.netがdbs4.netにイベントを伝播する場合、dbs4.netは、変換されたイベントを受信する。
ディレクテッド・ネットワークにおける第１の伝播が変換を実施する際に、変換のオーバーヘッドがソースデータベースに生じる。
複数の宛先データベースが同じ変換を必要とする際に、同じ変換が複数回行なわれ得る。
変換関数が伝播中に実行される際にエラーが生じた場合、エラーを生じたイベントはデキューされず、そのイベントは伝播されず、エラーが伝播に返される。そのイベントが伝播され得る前に、ユーザは規則ベースの変換を変更または除去してエラーを回避しなければならない。
規則ベースの変換および適用プロセス
適用プロセスが規則セットを用いる場合、適用中に変換が実施されるには以下の条件がいずれも満たされなければならない。
・規則が、適用プロセスに関連付けられたキュー内のイベントについてＴＲＵＥと評価すること。このイベントは、取得されたイベントまたはユーザがエンキューしたイベントであり得る。
・アクションのコンテキストが、システムに認識された特定の名前を有する、名前−値の対を含むこと。
・規則が評価されると、TRANSFORM_FUNCTIONが適用プロセスに返されること。
これらの条件の場合、適用プロセスは以下のステップを完了する。
１．キューからのイベントのデキューを開始する。
２．名前−値の対においてＰＬ／ＳＱＬ関数を実行して、デキュー中にイベントを変換する。
３．変換したイベントのデキューを完了する。
４．変換したイベントを適用する。
たとえば、イベントが、dbs1.netデータベースからdbs2.netに本来の形で伝播されるものと仮定されたい。適用プロセスが、dbs2.netにおけるキューからのイベントをデキューすると、イベントは変換される。
適用中に変換を実施することについて考えられる利点は以下のようなものである。
第１の伝播後にイベントが伝播されるどのようなデータベースも、その本来の形でイベントを受信し得る。たとえば、dbs2.netがdbs4.netにイベントを伝播する場合、dbs4.netは、本来のイベントを受信し得る。
ソースデータベースおよび宛先データベースが異なるとき、変換のオーバーヘッドがソースデータベースに生じない。
適用中に変換を実施することについて考えられる欠点は、以下のようなものである。
イベントが個人情報を含む場合、セキュリティが問題となり得る。なぜなら、イベントが伝播されるすべてのデータベースが本来のイベントを受信するためである。
複数の宛先データベースが同じ変換を必要とする際に、同じ変換が複数回行なわれ得る。
適用プロセスのデキュー中における規則ベースの変換エラー
適用プロセスのデキュー中に変換関数が実行される際にエラーが生じた場合、エラーを生じたイベントはデキューされず、そのイベントを含むトランザクションは適用されず、そのエラーは適用プロセスに返され、適用プロセスが不能にされる。適用プロセスが可能にされ得る前に、ユーザは、規則ベースの変換を変更または除去してエラーを回避しなければならない。
ゲートウェイとの統合
一実施例に従い、適用プロセスは、（１）ＬＣＲを読出してＬＣＲ内で反映された変更
を識別し、（２）所望の変更を生じるデータベースコマンド（ＳＱＬコマンド等）を構築し、（３）データベースに対してデータベースコマンドを実行することにより、データベースに１組のＬＣＲを「適用する」ように設定され得る。
一実施例に従い、適用プロセスは、ＬＣＲ内で反映される変更を本来行なったデータベース以外のデータベースに対して遠隔のＳＱＬステートメントを構築するように設定され得る。ＳＱＬステートメントは、遠隔のデータベース内で実行されると、所望の変更が遠隔のデータベースで行なわれるようにする。
このような遠隔のＳＱＬステートメントが一旦構築されると、このＳＱＬステートメントは、ゲートウェイ経由で遠隔のデータベースに送信される。ゲートウェイは、たとえば、遠隔のデータベースがソースデータベースとは異なる種類のデータベースである場合、必要に応じてクエリーを変換するように設定され得る。たとえば、オラクルのデータベースで行なわれた変更に応答して１組のＬＣＲを作成することができる。適用プロセスは、ＬＣＲに基づき、遠隔のＳＱＬクエリーを構築することができ、そのＳＱＬクエリーをゲートウェイに送信することができる。ゲートウェイは次に、必要に応じてそのＳＱＬを変換した後、非オラクルのデータ記憶装置にそのクエリーを転送することができる。そして、非オラクルのデータ記憶装置は、オラクルデータベースに対して行なわれ、かつ、ＬＣＲが本来基づいている変更に応答してクエリーを実行して、非同期式および遠隔の態様で変更を行なうことができる。
フラッシュバックとの統合
さまざまなデータベース言語、たとえば構造化クエリー言語（Structured Query Language（ＳＱＬ））は、この明細書で「カーソル」と呼ばれる特殊用途向けの構成体をサポートする。ＤＢＭＳは、特定のクエリーのステートメントの結果を検索する前に、そのステートメントに対して大量の事前作業、たとえば構文解析、意味解析、およびクエリープラン生成を実施することができる。カーソルは、この事前作業の多くの結果を記憶する。したがって、クエリーのステートメントが到着すると、ＤＢＭＳは最初に、そのステートメントと、カーソルが既に作成されたステートメントとの突合せを試みる。一致が発見された場合、カーソルは、そのクエリーのステートメントにより共有され、オーバーヘッド作業が回避される。
「フラッシュバックカーソル」は、過去のデータにアクセスするために用いられる特定の種類のカーソルである。フラッシュバックカーソルは、「フラッシュバッククエリー」を受信したことに応答して作成される。フラッシュバッククエリーは、従来のクエリーとは異なり、フラッシュバック時刻を指定して、指定したフラッシュバック時刻に存在していたデータを返す。フラッシュバッククエリーを処理するための１つの技術が、２０００年９月２９日に出願されて「細粒度履歴データベースアクセスを提供するためのシステムおよび方法（SYSTEM AND METHOD FOR PROVIDING FINE-GRAINED TEMPORAL DATABASE ACCESS）」と題された、ジョナサン Ｄ．クレイン（JONATHAN D. KLEIN）他による特許出願連続番号第０９／６７６，３０５号に記載されており、その内容は、この明細書において引用により援用される。
一実施例に従い、フラッシュバッククエリーおよびカーソルを情報共有システム１００とともに用いて、（１）変更に対して非同期であり、かつ、（２）変更の時刻におけるシステムの状態を考慮する態様でどのように変更を処理すべきかに関する決定を行なうことができる。
たとえば、時刻Ｔ１０において、ユーザがソースデータベースに変更を行なうと仮定されたい。この変更は、ソースデータベースにおける再実行ログにおいて反映される。その
結果、取得プロセスは、そのログを読出して、変更に対応するＬＣＲを生成する。このＬＣＲはその後、ステージングエリアに記憶される。
一実施例に従い、変更がソースデータベースにおいて永続的なものとなった（コミットされた）時刻がＬＣＲに記憶される。その結果、適用プロセスは、ＬＣＲを読出して、そのＬＣＲを更新ハンドラに渡す。システムの状態が、更新ハンドラがＬＣＲを受信する時刻までに、時刻Ｔ１０におけるシステムの状態から大きく変化していることが考えられる。更新ハンドラは、時刻Ｔ１０における変更をＬＣＲから読出すことができ、フラッシュバッククエリーを実行して、変更が本来行なわれた時刻（時刻Ｔ１０）においてデータベースシステムが存在していた状態を確認することができる。次に、更新ハンドラは、Ｔ１０におけるデータベースシステムの状況に基づいた変更に応答して、どのようなアクションを取るべきかを決定することができる。
フラッシュバッククエリーは一般に、標準的なクエリーと同じ種類の演算を指定することができる。したがって、システムの以前の状態を確認するために更新ハンドラが用いるフラッシュバッククエリーは、その以前の時刻に存在していた値を用いる複雑な演算の実施も伴い得る。たとえば、フラッシュバッククエリーは、複雑な結合および比較を実施することができ、それらのすべては、以前の時点で存在していたデータ値に対して実施され、以前の時点で行なわれた変更を識別するＬＣＲに応答してどのようなアクションを取るべきかを決定する。
タグおよびサイクルの回避
上述のように、情報共有システム１００のさまざまな構成要素は、特定のイベントが活動の複雑な連鎖を主に開始するように設定され得る。連鎖内の各活動（たとえば、１つのステージングエリアから別のステージングエリアへのイベントの伝播）自体が活動の別の連鎖を開始し得るため、サイクルが生じ得る。たとえば、情報共有システム１００に対する構成要素が、第１のデータベースに対して行なわれた変更を第２のデータベースに伝播して、かつ、第２のデータベースに対して行なわれた変更を第１のデータベースに伝播するように設定されるものと仮定されたい。この場合、第１のデータベース内の変更に関連付けられたイベントは、第２のデータベースに伝播されてそこで適用される。しかしながら、第２のデータベースにおけるイベントの適用は、第２のデータベースに対する変更を構成する。第２のデータベースにおけるその変更に対するイベントは、（サイクリングを回避するメカニズムなしに）第１のデータベースに再び伝播されて、そこで適用される。第２のデータベースにおけるイベントの適用は、第１のデータベースに対する「変更」を構成し、このことは、プロセス全体の、それ自体の繰返しを生じる。一実施例に従い、情報共有システム１００のさまざまな構成要素は、このようなサイクルが永続することを回避する態様でタグをセットして調べる。
タグ概論
一実施例によれば、再実行ログにおけるどの再実行エントリも、それに関連するタグを有する。タグのデータ型はＲＡＷである。デフォルトにより、ユーザまたはアプリケーションが再実行エントリを生成すると、タグの値は各再実行エントリについてＮＵＬＬであり、ＮＵＬＬタグは再実行エントリにおいて空間を消費しない。
ユーザが情報共有システム１００の構成要素を、情報共有動作のさまざまなステージで構成要素がどのように（１）タグ値をセットし、（２）タグ値を調べ、（３）タグ値を解釈して使用するかをカスタマイズするために設定できるようにするためのメカニズムが提供される。たとえば、タグは、ローカルデータベースにおいて、または異なるデータベースで生じた変更をＬＣＲが含むかどうかを判断するために使用可能であり、そのためユーザは変更サイクリング（ＬＣＲを、それが生じたデータベースに送り返すこと）を回避す
ることができる。タグは他のＬＣＲ追跡目的のためにも用いられてもよい。ユーザはまた、タグを用いて、各ＬＣＲ用の１組の宛先データベースを特定することもできる。
一実施例によれば、再実行ログにおいて生成されるタグの値をユーザが制御できるようにするために、さまざまなメカニズムが提供される。これらのメカニズムは、以下にSET_TAG、CREATE_APPLY、およびALTER_APPLYとして言及されるプロシージャを含むが、それらに限定されない。
SET_TAGプロシージャは、現在のセッションにおいて生成される再実行タグの値を特定するために使用される。データベース変更がセッションにおいて行なわれると、タグは、その変更を記録する再実行エントリの一部となる。異なるセッションが同じタグ設定、または異なるタグ設定を有することが可能である。
CREATE_APPLYおよびALTER_APPLYプロシージャは、適用プロセスが実行する際に生成される再実行タグの値を制御するために使用される。適用プロセスコーディネータによって調整されるセッションはすべて、このタグ設定を使用する。デフォルトにより、適用プロセスによって生成される再実行エントリは、‘００’（ダブルゼロ）に相当する１６進法のタグ値を有する。
これらのタグは、再実行ログから変更を検索する取得プロセスによって取得されるＬＣＲの一部となる。取得プロセスについての規則セットにおける規則に基づき、ある変更についての再実行エントリにおけるタグ値は、その変更が取得されているかどうかを判断してもよい。
同様に、一旦タグがＬＣＲの一部となると、タグの値は、伝播がＬＣＲを伝播しているかどうか、および適用プロセスがＬＣＲを適用しているかどうかを判断してもよい。変換、ＤＭＬハンドラまたはエラーハンドラの機能も、タグの値に従属可能である。加えて、ユーザは、既存のＬＣＲについてのタグ値を、そのＬＣＲについてのSET TAGメンバープロシージャを用いてセット可能である。たとえば、ユーザは変換中にタグをＬＣＲにセットしてもよい。
一実施例によれば、ユーザは規則を作成し、各規則はデフォルトにより、タグがＮＵＬＬの場合に限りＴＲＵＥと評価するという条件を含んでいる。ＤＭＬ規則では、条件は以下のとおりである。
Figure 2006501585
ＤＤＬ規則では、条件は以下のとおりである。
Figure 2006501585
単一の規則を有する規則セットを考慮し、その規則がそのような条件を含むと仮定されたい。この場合、取得プロセス、伝播、および適用プロセスは以下のように機能する：
・取得プロセスは、ある変更についての再実行ログにおけるタグがＮＵＬＬで、かつ、
規則条件の残りがその変更についてＴＲＵＥと評価する場合に限り、その変更を取得する
・伝播は、あるＬＣＲにおけるタグがＮＵＬＬで、かつ、規則条件の残りがそのＬＣＲについてＴＲＵＥと評価する場合に限り、そのＬＣＲを含むイベントを伝播する
・適用プロセスは、あるＬＣＲにおけるタグがＮＵＬＬで、かつ、規則条件の残りがそのＬＣＲについてＴＲＵＥと評価する場合に限り、そのＬＣＲを含むイベントを適用する。
すなわち、これらの条件のうちの１つをデフォルトにより含む規則を作成するために、以下のプロシージャが提供される。
Figure 2006501585
作成された規則がそのような条件を含むことをユーザが望まない場合、それらは、ユーザがこれらのプロシージャを実行すると、include_tagged_lcrパラメータを真にセットしてもよい。この設定は、タグに関連する条件が規則にないことをもたらす。したがって、ＬＣＲの規則評価はタグの値に従属しない。
たとえば、dbsl.netソースデータベースで生じたhr.locationsテーブルへのすべてのＤＭＬ変更についてＴＲＵＥと評価する、テーブルレベルの規則を考慮されたい。ADD_TABLE_RULESプロシージャがこの規則を生成するために実行されると仮定されたい。
Figure 2006501585
なお、include_tagged_lcrパラメータは偽にセットされており、それはデフォルトである。ADD-TABLE-RULESプロシージャは、以下と同様の規則条件を有する規則を生成する。
Figure 2006501585
取得プロセスがこの規則を含む規則セットを使用する場合、その規則は、再実行エントリにおける変更についてのタグが‘０’または‘１’といった非ＮＵＬＬ値である場合にＦＡＬＳＥと評価する。そのため、再実行エントリがhr.locationsテーブルへの行変更を含む場合、その変更は、再実行エントリについてのタグがＮＵＬＬである場合に限り取得される。
しかしながら、ADD_TABLE_RULESが実行されている際にinclude_tagged_lcrパラメータが真にセットされると仮定されたい。
Figure 2006501585
この場合、ADD_TABLE_RULESプロシージャは、以下と同様の規則条件を有する規則を生成する。
Figure 2006501585
なお、タグに関連する条件はない。取得プロセスがこの規則を含む規則セットを使用する場合、この規則は、hr.locationsテーブルへのＤＭＬ変更についての再実行エントリにおけるタグが‘０’または‘１’といった非ＮＵＬＬ値である場合にＴＲＵＥと評価する。この規則はまた、タグがＮＵＬＬである場合にもＴＲＵＥと評価する。そのため、再実行エントリがhr.locationsテーブルへのＤＭＬ変更を含む場合、その変更は、タグについての値にかかわらず取得される。
ユーザがデータベース全体についてＤＤＬ変更を取得し適用するためにグローバルな規則を使用している場合、オンラインバックアップステートメントが、デフォルトにより取
得され、伝播され、適用される。通常、データベースアドミニストレータらは、オンラインバックアップステートメントの複製を望まない。むしろ、彼らはそれらが元々実行されるデータベースで実行することしか望んでいない。オンラインバックアップステートメントの複製を避けるために、ユーザは以下の方策のうちの１つを使用できる：
・SET TAGプロシージャへの１つ以上の呼出をユーザのオンラインバックアッププロシージャに含めて、オンラインバックアップステートメントが取得プロセスに無視されるようにする値にセッションタグをセットする
・適用プロセス用のＤＤＬハンドラを使用して、オンラインバックアップステートメントの適用を回避する。
タグおよび適用プロセス
適用プロセスは、それがＤＭＬ変更またはＤＤＬ変更を適用する際に、宛先データベースの再実行ログにエントリを生成する。たとえば、適用プロセスがテーブルのある行を更新する変更を適用する場合、その変更は宛先データベースの再実行ログに記録される。ユーザは、DBMS_APPLY_ADMパッケージのCREATE_APPLYまたはALTER_APPLYプロシージャにおけるapply_tagパラメータをセットすることによって、これらの再実行エントリにおけるタグを制御できる。たとえば、適用プロセスは、‘０’（ゼロ）または‘１’の１６進法の値と同等の再実行タグを生成してもよい。
適用プロセスによって再実行ログに生成されるデフォルトタグ値は‘００’（ダブルゼロ）である。この値は、ユーザが適用プロセスを作成するプロシージャを用いる場合、適用プロセス用のデフォルトタグ値である。この値については、それが非ＮＵＬＬ値であるという以外に特別なことはない。それが非ＮＵＬＬ値であるということは重要である。なぜなら、あるプロシージャによって作成される規則はデフォルトにより、再実行エントリまたはＬＣＲにおいてタグがＮＵＬＬである場合に限りＴＲＵＥと評価するという条件を含むためである。ユーザは、ALTER_APPLYプロシージャを用いて、既存の適用プロセス用のタグ値を変更可能である。
ＤＭＬハンドラ、ＤＤＬハンドラまたはメッセージハンドラがSET_TAGプロシージャを呼出す場合、ハンドラによって生成される次のどの再実行エントリも、適用プロセス用のタグが異なる場合でも、SET_TAG呼出において特定されるタグを含む。ハンドラが存在する場合、適用プロセスによって生成される次のどの再実行エントリも、適用プロセス用に特定されたタグを有する。
タグを用いた変更サイクリングの回避
２つ以上のデータベース共有データを双方向的に含む環境では、ユーザはタグを用いて変更サイクリングを回避することができる。変更サイクリングとは、変更をそれが生じたデータベースに送り返すことを意味する。通常、変更サイクリングは回避されるべきである。なぜなら、それは、各変更が無限ループを通ってそれが生じたデータベースに戻ることをもたらす場合があるためである。そのようなループは、データベースに意図しないデータをもたらして、環境のネットワーキングおよびコンピュータ資源に負担をかける場合がある。
取得プロセス、伝播および適用プロセス用のタグおよび適切な規則を用いて、ユーザはそのような変更サイクルを回避できる。以下のセクションは、さまざまな環境、および、タグおよび規則がこれらの環境において変更サイクリングを回避するためにどのように使用可能かを記載している：
・各データベースは共有データ用のソースおよび宛先データベースである
・いくつかの２次データベースとデータを共有する１次データベース
・いくつかの拡張２次データベースとデータを共有する１次データベース。
各データベースは共有データ用のソースおよび宛先データベースである
このシナリオは、各データベースが他のすべてのデータベースにとってのソースデータベースであり、各データベースが他のすべてのデータベースの宛先データベースである環境に関与する。各データベースは他のすべてのデータベースと直接通信する。
たとえば、mult1.net、mult2.netおよびmult3.netという３つのオラクルのデータベース間でhrスキーマのデータベースオブジェクトおよびデータを複製するという環境を考慮されたい。hrスキーマのテーブルで行なわれるＤＭＬ変更およびＤＤＬ変更がこの環境における３つ全部のデータベースで取得され、この環境における他のデータベースの各々に伝播されて、そこで変更が適用される。図１８Ａ〜図１８Ｃは、各データベースがソースデータベースである例示的な環境を示している。
ユーザは、そのような環境を以下のように設定することによって、変更サイクルを回避できる。各ソースデータベースから変更用の非ＮＵＬＬ再実行タグを生成するよう、各データベースで１つの適用プロセスを設定する。ユーザがある適用プロセスを作成するプロシージャを使用した場合、その適用プロセスはデフォルトにより再実行ログに値‘００’を有する非ＮＵＬＬタグを生成する。この場合、適用プロセスが非ＮＵＬＬタグを生成するのにそれ以上のアクションは要求されない。
ユーザがCREATE_APPLYプロシージャを使用する場合、適用タグパラメータをセットしてはならない。ここでも、適用プロセスはデフォルトにより再実行ログに値‘００’を有する非ＮＵＬＬタグを生成し、それ以上のアクションは要求されない。
変更についての再実行エントリにおけるタグがＮＵＬＬである場合に限り変更を取得するよう、各データベースでの取得プロセスを設定する。ユーザは、取得プロセスによって使用される規則セットにおける各ＤＭＬ規則が以下の条件を有することを確実にすることによって、これを行なう。
Figure 2006501585
各ＤＤＬ規則は以下の条件を有するべきである。
Figure 2006501585
これらの規則条件は、ある変更についてのタグがＮＵＬＬである場合に限り取得プロセスがその変更を取得することを示している。
この設定は変更サイクリングを防止する。なぜなら、適用プロセスによって適用される変更がすべて、決して再取得されない（それらは元々ソースデータベースで取得されたものである）ためである。各データベースはhrスキーマへのその変更のすべてを他のすべてのデータベースに送信する。そのため、この環境では、変更は何ら失われず、すべてのデータベースは同期を取られる。図１９は、タグが多数ソース環境においてデータベースでどのように使用可能かを示している。
いくつかの２次データベースとデータを共有する１次データベース
このシナリオは、１つのデータベースが１次データベースで、この１次データベースがいくつかの２次データベースとデータを共有している情報共有システム１００環境に関与する。２次データベースは１次データベースとしかデータを共有しない。２次データベース同士は互いに直接データを共有することはないが、代わりに、１次データベースを介して互いに間接的にデータを共有する。この種の環境は時折「ハブアンドスポーク」環境と呼ばれ、１次データベースがハブ、２次データベースがスポークとなっている。
そのような環境では、変更は以下のように取得され、伝播され、適用される。
１次データベースは、共有されたデータへのローカルな変更を取得し、これらの変更をすべの２次データベースに伝播し、そこでこれらの変更は各２次データベースでローカルに適用される。
各２次データベースは、共有されたデータへのローカルな変更を取得し、これらの変更を１次データベースのみに伝播し、そこでこれらの変更は１次データベースでローカルに適用される。
１次データベースは各２次データベースからの変更をローカルに適用する。次に、これらの変更は１次データベースで取得され、変更が生じた２次データベースを除くすべての２次データベースに伝播される。各２次データベースは、他の２次データベースからの変更を、それらが１次データベースを経由した後にローカルに適用する。この設定は適用転送の一例である。
代替的なシナリオはキュー転送を使用してもよい。この環境がキュー転送を使用する場合、１次データベースで適用される２次データベースからの変更は、１次データベースで取得されない。代わりに、これらの変更は、１次データベースのキューから、変更が生じた２次データベースを除くすべての２次データベースに転送される。
たとえば、ps1.netという１つの主データベースと、ps2.net、ps3.netおよびps4.netという３つの２次データベースとの間でhrスキーマのデータベースオブジェクトおよびデータを複製するという環境を考慮されたい。hrスキーマのテーブルに対して行なわれるＤＭＬ変更およびＤＤＬ変更は、この環境において、１次データベースで、および３つの２次データベースで取得される。次に、これらの変更は前述のように伝播され、適用される。この環境は、２次データベース間で１次データベースを介してデータを共有するために、キュー転送ではなく適用転送を使用している。図２０は、１つの１次データベースと多数の２次データベースとを有する例示的な環境を示している。
ユーザは、環境を以下のように設定することによって変更サイクルを回避できる。１次データベースps1.netでの各取得プロセスを、それが変更を受取っているサイトを示す非ＮＵＬＬ再実行タグを生成するよう設定する。この環境で、１次データベースは、それが変更を受取る各２次データベースについて少なくとも１つの適用プロセスを有する。たとえば、１次データベースのある適用プロセスがps2.netという２次サイトから変更を受取る場合、この適用プロセスは、それが適用するすべての変更について１６進法の値‘２’と同等の未処理の値を生成してもよい。ユーザは、DBMS_APPLY_ADMパッケージのCREATE_APPLYまたはALTER_APPLYプロシージャにおける適用タグパラメータを非ＮＵＬＬ値にセットすることにより、これを行なう。
たとえば、１６進法の値‘２’と同等のタグを有する再実行エントリを生成する適用プ
ロセスを作成するために、以下のプロシージャを実行する。
Figure 2006501585
非ＮＵＬＬ再実行タグを生成するよう、各２次データベースでの適用プロセスを設定する。タグの正確な値は、それが非ＮＵＬＬである限り無関係である。この環境では、各２次データベースは、１次データベースからの変更を適用する１つの適用プロセスを有する。
ユーザがDBMS情報共有システム１００ADMパッケージのプロシージャを用いてある適用プロセスを作成する場合、その適用プロセスはデフォルトにより再実行ログに‘００’の値を有する非ＮＵＬＬタグを生成する。この場合、適用プロセスが非ＮＵＬＬタグを生成するのにそれ以上のアクションは要求されない。
たとえば、２次データベースに適用プロセスがないと仮定して、各２次データベースでADD_SCHEMA_RULESプロシージャを実行して、１６進法の値‘００’と同等のタグを有する非ＮＵＬＬ再実行エントリを生成する適用プロセスを作成する。
Figure 2006501585
共有データへの変更をタグにかかわらず取得するよう、１次データベースでの取得プロセスを設定する。ユーザは、取得規則を生成するプロシージャのうちの１つをユーザが実行する際にinclude_tagged_lcrパラメータを真にセットすることによって、これを行なう。ユーザが１次データベースでの取得プロセスについて規則を作成する場合、その規則がis_null_tag条件を含まないことを確認されたい。なぜなら、これらの条件は再実行ログにおけるタグに関与するためである。
たとえば、hrスキーマでの変更についてＴＲＵＥと評価する条件を各々有する１つのＤ
ＭＬ取得プロセス規則および１つのＤＤＬ取得プロセス規則を、変更についてのタグにかかわらず生成するために、１次データベースで以下のプロシージャを実行する。
Figure 2006501585
変更についての再実行エントリにおけるタグがＮＵＬＬである場合に限り変更を取得するよう、各２次データベースでの取得プロセスを設定する。ユーザは、２次データベースで取得プロセスによって使用される規則セットにおける各ＤＭＬ規則が以下の条件を有することを確実にすることによって、これを行なう。
Figure 2006501585
ＤＤＬ規則は以下の条件を有するべきである。
Figure 2006501585
これらの規則は、ある変更についてのタグがＮＵＬＬである場合に限り取得プロセスがその変更を取得することを示している。ユーザがDBMS情報共有システム１００ADMパッケージを用いて規則を生成する場合、各規則はデフォルトによりこれらの条件のうちの１つを有する。ユーザがDBMS RULE ADMパッケージを用いて２次データベースでの取得プロセスについて規則を作成する場合、各規則がこれらの条件のうちの１つを含むことを確認されたい。
１次データベースのキューから各２次データベースのキューへの１つの伝播を設定する。各伝播は、２次データベースで生じた変更を除き、１次データベースのキューにおけるすべてのＬＣＲを２次データベースのキューに伝播するよう、伝播に指示する規則を有する規則セットを用いるべきである。
たとえば、伝播が、そのタグが１６進法の値‘２’と同等の２次データベースps2.netに変更を伝播する場合、その伝播についての規則は、‘２’のタグを有するＬＣＲを除き、hrスキーマに関するすべてのＬＣＲを２次データベースに伝播すべきである。行ＬＣＲ
については、そのような規則は以下の条件を含むべきである。
Figure 2006501585
ＤＤＬ ＬＣＲについては、そのような規則は以下の条件を含むべきである。
Figure 2006501585
ユーザはCREATE_RULEプロシージャを用いて、これらの条件を有する規則を作成することができる。
各２次データベースのキューから１次データベースのキューへの１つの伝播を設定する。２次データベースのうちの１つにおけるキューは、その２次データベースでユーザセッションおよびアプリケーションによって行なわれたローカルな変更のみを含み、適用プロセスによって行なわれた変更は含まない。したがって、これらの伝播については、それ以上の設定は必要ではない。
この設定は以下のように変更サイクリングを防止する：
・ある２次データベースで生じた変更は決してその２次データベースに伝播し返されない
・１次データベースで生じた変更は決して１次データベースに伝播し返されない
・この環境における任意のデータベースで共有データに対して行なわれた変更はすべて、この環境における他のすべてのデータベースに伝播される。
そのため、この環境では、変更は失われず、すべてのデータベースが同期を取られている。
いくつかの拡張２次データベースとデータを共有する１次データベース
この環境では、１つの１次データベースがいくつかの２次データベースとデータを共有するが、２次データベースは、それらに接続された、遠隔２次データベースと呼ばれる他の２次データベースを有する。この環境は、「いくつかの２次データベースとデータを共有する１次データベース」で説明された環境の拡張である。
遠隔２次データベースは１次データベースと直接データを共有してはいないが、代わりに、２次データベースを介して１次データベースと間接的にデータを共有する。そのため、共有されたデータは、１次データベース、各２次データベース、および各遠隔２次データベースに存在する。これらのデータベースのいずれかで行なわれた変更は取得されて、他のデータベースのすべてに伝播される。図２３は、１つの１次データベースと多数の拡張２次データベースとを有する環境を示している。
そのような環境では、ユーザは以下のように変更サイクリングを回避することができる。
１次データベースを、それが「いくつかの２次データベースとデータを共有する１次データベース」で説明された例において設定されているのと同様に設定する。
各遠隔２次データベースを、「いくつかの２次データベースとデータを共有する１次データベース」で説明された例において各２次データベースが設定されているのと同様に設定する。唯一の違いは、遠隔２次データベースが、１次データベースとではなく、２次データベースと直接データを共有することである。
各２次データベースで、１６進法の値‘００’と同等の再実行タグ値を有する１次データベースからの変更を適用するために、１つの適用プロセスを設定する。この値は、適用プロセス用のデフォルトタグ値である。
各２次データベースで、その遠隔２次データベースの各々からの、その遠隔２次データベースにとって一意的な再実行タグ値を有する変更を適用するために、１つの適用プロセスを設定する。
再実行ログにおける共有データへの変更すべてを変更用のタグ値にかかわらず取得するために、各２次データベースでの取得プロセスを設定する。
各２次データベースのキューから１次データベースのキューへの１つの伝播を設定する。この伝播は、１次データベースで生じた変更を除き、２次データベースのキューにおけるすべてのＬＣＲを１次データベースのキューに伝播するために、伝播に指示する規則を有する規則セットを用いるべきである。ユーザは、ＬＣＲのタグが‘００’と等しくない場合に限りＴＲＵＥと評価するという条件を規則に追加することによって、これを行なう。たとえば、行ＬＣＲについて、以下と同様の条件を入力する。
Figure 2006501585
各２次データベースのキューから各遠隔２次データベースのキューへの１つの伝播を設定する。各伝播は、その遠隔２次データベースで生じた変更を除き、２次データベースのキューにおけるすべてのＬＣＲをその遠隔２次データベースのキューに伝播するために、伝播に指示する規則を有する規則セットを用いるべきである。ユーザは、ＬＣＲのタグが遠隔２次データベース用のタグ値と等しくない場合に限りＴＲＵＥと評価するという条件を規則に追加することによって、これを行なう。たとえば、ある遠隔２次データベースのタグ値が１６進法の値‘１９’と同等である場合、行ＬＣＲについて、以下と同様の条件を入力する。
Figure 2006501585
このように環境を設定することにより、ユーザは変更サイクリングを防止し、どのデータベースで生じる変更も失われない。
ディスクバックアップ、およびデータベース再実行ストリームから取得されたメッセージの回復を有するメモリ内ストリーミング
データベースは、たとえばフロッピー（登録商標）ディスク、ハードディスクまたはテープといった永続的な電子データ記憶媒体上に、整合した、かつ回復可能な態様で情報を記憶し、編成するために使用される。データベースはまた、それが記憶媒体に対して行なうすべての変更について、再実行および取消情報のストリームを生成する。再実行／取消ストリームは主として、クラッシュ後、データベースを一定の点まで回復させるために使用される。
しかしながら、上述のように、再実行および取消情報は他の目的のために使用されてもよい。たとえば、再実行ログは、データベース（またはデータベース内の選択されたオブジェクト）の複製を作成し、オリジナルのコピーと整合性のある複製を保持するために使用されてもよい。複製を作成する１つの理由は、オリジナルが破壊された場合に備えてバックアップを取ることであり得る。複製を作成する別の理由は、データを照会または修正するユーザに「より近接して」複製を作成することによって、データをより速くアクセス可能にすることである。
複製を作成するため、最初のコピーがオリジナルから作られ、その時点以降、オリジナルに対して行なわれたどの変更も、複製に移送されて適用される。変更は直接、または中間サイトを介して移送可能である。移送は通常、データネットワークを通してデータを電子的に転送することによって、または、場合によっては、記憶媒体を物理的に運ぶことによって行なわれる。同様に、複製に対して行なわれたどの変更も、オリジナルに移送されて適用される。異なるサイトにおけるデータ項目の同時修正により不一致が起こると、この不一致は、データベースに内蔵されるかまたはデータベースアドミニストレータによって提供される矛盾解決機能によって解決される必要がある。
オリジナルデータベースオブジェクトに対して行なわれた変更に基づいて複製を作成し更新することは、変更がどのように「適用」され得るかの単なる一例である。しかしながら、変更の適用は、任意の種類のアクションを伴ってもよく、または、長い一連のアクションを起動させてもよい。たとえば、変更の適用が、変更されたデータベースオブジェクトに関心のあるサブスクライバへのメッセージの生成を伴ってもよい。
データベースシステムは、変更が行なわれてログされるシステムの単なる一例である。ここに説明される手法はどの特定のタイプの変更生成システムにも限定されない。しかしながら、説明のため、最初に変更を生成したシステムと変更が適用されるシステムとの双方がデータベースである例を挙げる。
説明のため、変更が最初に行なわれるシステムをソースサイトと呼び、変更が適用されるシステムを宛先サイトと呼ぶ。しかしながら、変更は、その変更が最初に行なわれたのと同じシステムによって適用されてもよいことに留意すべきである。このような状況では、ソースサイトと宛先サイトとは同じサイトである。
通常、データベースオブジェクトに対して行なわれる変更は、その変更が宛先サイトで適用される前に、永続的な記憶媒体に記憶される。記憶は、ソースサイト、中間サイト、宛先サイト、または上述のすべてで行なわれ得る。残念ながら、変更を適用する前に変更を永続的に記憶することは、適用動作の性能を妨げる傾向がある。性能の低下は、コンピュータが発明されて以来、データの記憶および検索において永続的な記憶媒体が非常駐記憶媒体よりも通常１０〜１００倍遅いままである、という事実による。
変更を適用する前に変更を永続的に記憶することによって課される遅延を回避するため、以下に説明される手法により、変更は、それらがソースサイトで生成される時点とそれらが宛先サイトで適用される時点との間でＲＡＭメモリなどの非常駐記憶媒体に記憶されるようになる。
ソースサイトおよび宛先サイトがデータベースシステムである一実施例によれば、変更は、ソースデータベースシステムの再実行／取消ストリームを読出して、変更を非常駐ストレージに記憶することによって取得される。変更データは次に、別のデータベースシステム上の非常駐ストレージに移送され、そこでそれは適用されるか、さらに別のデータベースシステムに移送されるか、またはその双方が行なわれる。
非常駐ストレージの内容は先入れ先出し（ＦＩＦＯ）の態様で編成される。説明のため、この態様で変更データを記憶するために使用されるメモリの部分を、以下において「ＦＩＦＯバッファ」と呼ぶことにする。現在のコンピュータには多重処理装置（またはＣＰＵ）が搭載されている。説明のため、変更を取得するタスク、変更を伝播するタスク、および変更を適用するタスクに割当てられたＣＰＵを、それぞれ、取得エンジン、伝播エンジンおよび適用エンジンと呼ぶことにする。
図２４を参照すると、それは、１つの中間サイト２４０４を介した、ソースサイト２４００から宛先サイト２４０２への変更情報のメモリ内ストリーミングを示すブロック図である。上述のように、中間サイトはゼロであってもよく、またはいくつかあってもよい。このため、１つの中間サイト２４０４がある一実施例は単に説明のために示されている。
図２４に示すように、ソースサイト２４００のオリジナルテーブルへの更新は、変更を反映するデータをログファイルに挿入させる。取得エンジンはログファイルを読出して、ソースサイトの揮発性メモリ２４１０にストリーミングされる変更データを生成する。ソースサイトの揮発性メモリ２４１０から、伝播エンジン（図示せず）は変更データを中間サイト２４０４の揮発性メモリ２４１４に伝播する。中間サイト２４０４の揮発性メモリ２４１４から、伝播エンジン（図示せず）は変更データを宛先サイト２４０２の揮発性メモリ２４１２に伝播する。変更データは次に、宛先サイト２４０２の揮発性メモリ２４１２から適用エンジンによって読出され、宛先サイト２４０２で適用される。図２４に示すシナリオでは、変更データは、ソースサイトに位置するオリジナルテーブルに対して行なわれた更新に基づいて、宛先サイト２４０２に位置する複製を修正することによって適用される。
しばしば、変更が適用される順序は、変更が最初に行なわれた順序に基づくべきである。一実施例によれば、変更の順番が失われないことを確実にするために、図２４に示すさまざまな構成要素によって以下の処置が取られる：
・再実行ストリームの各変更には、ここで変更順序番号（またはＣＳＮ）と呼ばれる、一意的でかつ増加する番号が割当てられる
・取得エンジンは、変更をＦＩＦＯバッファにＣＳＮ順で追加する
・伝播エンジンは、変更を移送する間、ＣＳＮ順を保持する
・適用エンジンはこの順序を用いて、変更を適用する順番を決定する。
変更データは、変更データが生成される時点と変更データが適用プロセスによって消費される時点との間、永続的なメモリに記憶されないため、図示された複製動作の性能は著しく向上する。しかしながら、複製動作中に変更データを永続的なメモリに記憶させなかったことは、ある回復悪影響を有し、それを以下に説明することにする。
ＣＳＮを用いて「１回のみの」運転を達成する
残念ながら、非常駐メモリに記憶されている情報は、故障が起こるとそのメモリから永久に消去される場合がある。そのような情報損失は、変更が宛先サイトで１回のみ適用されることを必要とするシステムにおいて壊滅的な影響を与える場合がある。すなわち、何の予防措置も取られていない場合、取得エンジンも適用エンジンも、どの変更が故障の前に送信されたもののまだ適用されていなかったかがわからない。このため、既に適用された変更を、取得エンジンが再送し、適用エンジンが再適用する、という危険が大いにある。逆に、故障の前に送信されたもののまだ適用されていなかった変更を、取得エンジンが再送せず、適用エンジンが決して適用しない、という危険もある。
一実施例によれば、ＣＳＮは、正しい適用順を確実にすることに加え、変更が故障の後で１回のみ適用されることを確実にするために使用される。一実施例によれば、一回のみの運転は、最も直前に適用された変更のオリジナルＣＳＮを適用エンジンに永続的に記録させることによって達成される。図２４においてLAST-APPLIED CSN（最後に適用されるＣＳＮ）として示されるこの値は、新しい変更が適用されるにつれて、適用エンジンによって継続的に更新される。LAST-APPLIED CSNは不揮発性メモリに記憶されるため、それは故障の後でも、その故障がLAST-APPLIED CSNが記憶されたサイトに関与する場合ですら、利用可能である。以下により詳細に説明するように、故障の後でLAST-APPLIED CSNを発見する能力は、適用エンジンが以前に適用された変更を再適用しないことを確実にする。
一実施例によれば、適用エンジンは、LAST-APPLIED CSNを記憶することに加え、現在のLAST-APPLIED CSNを伝播エンジンに定期的に知らせる。この情報を通信するために使用されるメッセージはここで認証または「ＡＣＫ」と呼ばれる。図２４を参照すると、ＡＣＫは、宛先サイト２４０２から中間サイト２４０４に、および中間サイト２４０４からソースサイト２４００に送信されている。
ソースサイト２４００はこのようにLAST-APPLIED CSNについて知らされるが、ソースサイト２４００がＡＣＫを受信するまでに、ＡＣＫにおいて識別されるLAST-APPLIED CSN値は通常、古くなっている。言い換えれば、ＡＣＫメッセージがソースサイト２４００によって受信される時点までに、適用エンジンは既に、ＡＣＫメッセージにおいて指示されたLAST-APPLIED CSN値に関連する変更を超越する変更を適用している。
ソースサイト２４００で受信されるLAST-APPLIED CSN値は、古くなってはいるものの、そのＣＳＮ値までの全変更が適用エンジンによって既に適用されたと保証されていることをソースサイト２４００が理解するという点で、依然として価値がある。したがって、一実施例によれば、頻繁ではない間隔で、ソースサイト２４００は、それが最も直前にＡＣＫメッセージにおいて受信したＣＳＮ値を永続的に記憶する。このように記憶された最も直前のＣＳＮはここでLAST ACK CSN（最後のACK CSN）と呼ばれる。なぜなら、それは（１）サイトでＡＣＫメッセージにおいて受信され、（２）そのサイトで永続的に記憶される、最後のＣＳＮであるためである。頻繁なディスクアクセスに関連するオーバーヘッドを回避するため、LAST ACK CSNが永続的なストレージに記憶される頻度は、ＡＣＫメッセージが受信される頻度よりかなり少なくてもよい。このため、永続的に記憶されるLAST ACK CSNは、実際には、最も直前のＡＣＫメッセージにおいて受信されたＣＳＮではない場合がある。
故障が起こった場合、ソースサイト２４００は、ソースサイトで記憶されているLAST ACK CSN値よりも大きいＣＳＮ値を有する変更を再送するだけでよい。すなわち、取得データベースがクラッシュした場合、ＦＩＦＯバッファ２４１０の内容は失われる。この場合、取得エンジンは、ソースサイト２４００で記録されているLAST ACK CSNから始まる変更をＦＩＦＯバッファ２４１０に再度エンキューする。このため、取得エンジンは（１）以前に送信されたもののまだ適用されていなかったすべての変更を、そして潜在的には（２
）以前に送信され、適用されたいくつかの変更を再送する。しかしながら、第２のカテゴリに該当する変更の数は通常、非常に少ない。なぜなら、それは、適用された変更で、かつそのＣＳＮがソースサイトで記憶されているLAST ACK CSNよりも大きい変更しか含まないためである。
一実施例によれば、ソースサイトと宛先サイトとの間の中間サイトの１つ以上は、ソースサイトと同様の態様でLAST ACK CSNを記憶するよう設定されている。すなわち、ＡＣＫの転送に関与する伝播エンジンは、それらが受信するどのＡＣＫメッセージも上流に転送することに加え、頻繁ではない間隔で、ＡＣＫに含まれるＣＳＮを永続的に記録する。たとえば、図２４では、中間サイト２４０４がLAST ACK CSNを永続的に記憶するよう示されている。
LAST ACK CSNが中間サイトに記憶されている一実施例では、LAST ACK CSNは、中間サイトの故障に応じて行なわれるべき作業を限定するために用いられる。すなわち、中間サイト２４０４がクラッシュした場合、中間サイト２４０４は、中間サイト２４０４に記憶されたLAST ACK CSNを読出し、すぐ横に隣接する上流サイト（この場合、ソースサイト２４００）に、LAST ACK CSNの後の時点を表わす変更のみを再送するよう要求する。
上述のように、サイトが最後には、既に適用された変更を再び伝播するようになることが起こり得る。一実施例によれば、そのような複製ＣＳＮに関連する変更を、伝播および／または適用した最高ＣＳＮを覚えていることによって無視することは、下流サイトの責任である。たとえば、ソースサイト２４００が（１）３０というLAST ACK CSNを記録し、（２）ＣＳＮが５０の変更を中間サイト２４０４に伝播した後で、ソースサイト２４００がクラッシュしたと仮定されたい。さらに、ＣＳＮが５０の変更がゆくゆくは宛先サイト２４０２に伝播され、そこで適用されると仮定されたい。
このシナリオでは、ソースサイト２４００が再始動すると、ソースサイト２４００は、ＣＳＮ３０の後に始まる変更を再送し始める。このため、中間サイト２４０４は、ＣＳＮ３１〜ＣＳＮ５０に関連する変更を、これらの変更が既に伝播され適用された後で受信する。しかしながら、中間サイト２４０４はそれが伝播した最後の変更のＣＳＮを追跡しているため、中間サイト２４０４は、ＣＳＮ３１〜ＣＳＮ５０に関連する変更を再度伝播しない、ということを理解している。
別の例として、中間サイト２４０４が（１）３０というLAST ACK CSNを記録し、（２）ＣＳＮが５０の変更を宛先サイト２４０２に伝播した後で、中間サイト２４０４がクラッシュしたと仮定されたい。さらに、ＣＳＮが５０の変更が宛先サイト２４０２で適用されると仮定されたい。
このシナリオでは、中間サイト２４０４が再始動すると、中間サイト２４０４はソースサイト２４００に、ＣＳＮ３０の後に始まる変更を再送するよう要求する。中間サイト２４１４は、ＣＳＮ３１〜５０に関連する変更を、これらの変更が既に適用された後で受信し、宛先サイト２４０２に再送する。しかしながら、宛先サイト２４０２はLAST APPLIED
CSNを追跡しているため、宛先サイト２４０２は、ＣＳＮ３１〜ＣＳＮ５０に関連する変更を再度適用しない、ということを理解している。
一実施例によれば、宛先データベースが変更を、それらが着信し、かつメモリが不足してくるのと同じくらい速く適用することができない場合、宛先データベースは、永続的なストレージに変更を溢出するこれらの変更用にメモリを解放するために、ＣＰＵの別個のグループを割当てることができる。これらのＣＰＵはここで「溢出エンジン」と呼ばれる。変更はＣＳＮの昇順で溢出され、溢出されたＣＳＮは、それが適用されたかのように伝
播エンジンに認証される。これらの状況において、適用エンジンはまず、（永続的なキューが空でない場合）永続的なキューにおける変更を見て、次に、永続的なキューが一旦空になれば、ＦＩＦＯバッファから変更を適用する。
プロセス故障回復
いくつかの故障シナリオでは、揮発性メモリ内の全情報が失われるわけではない。たとえば、図２４に示すシステムでは、取得エンジンは、ソースサイト２４００の揮発性メモリに記録されている全データを失うことなく、故障するかもしれない。そのような故障から迅速に回復するために、LAST PROCESSED CSN（最後に処理されたＣＳＮ）が揮発性メモリに保持されていてもよい。あるエンジンによって記憶されているLAST PROCESSED CSNは、そのエンジンによって最も直前に処理された変更のＣＳＮを示す。たとえば、ソースサイト２４００上の取得プロセスは、適用エンジンが最も直前にＦＩＦＯバッファ２４１０に配置した変更のＣＳＮを示すLAST PROCESSED CSNを記憶していてもよい。同様に、中間サイト２４０４上の伝播エンジンは、宛先サイト２４０２に最も直前に伝播された変更のＣＳＮを示すLAST PROCESSED CSNを記憶していてもよい。
エンジンが対応するLAST PROCESSED CSNを失うことなく故障した場合、（一般にLAST ACK CSNよりも新しい）LAST PROCESSED CSNを用いて、エンジンが再始動時どこから作業を開始すべきかを判断してもよい。たとえば、ソースサイト２４００の取得エンジンは再始動されると、LAST PROCESSED CSNを調べて、どの変更が既にＦＩＦＯバッファ２４１０にエンキューされているかを判断してもよい。
「一回のみの」運動およびトランザクション
いくつかの環境では、取得、伝播および適用される変更は、トランザクションに属していてもよい。トランザクションとは、単一の原子動作として「永続的になる」１組の動作である。変更がトランザクションに属する環境では、さまざまなトランザクションについての変更が、ＣＳＮ順に関して互いにインタリーブされてもよい。たとえば、第１のトランザクションＴＸ１についての変更にＣＳＮ１０、１１、１５および１７が割当てられ、一方、第２のトランザクションＴＸ２についての変更にＣＳＮ１２、１３、１４、１６、１８および２０が割当てられてもよい。
大抵のシステムでは、トランザクション全体には、トランザクションが完了したと考えられる時点を示すＣＳＮが割当てられる。ここに「コミットＣＳＮ」と呼ばれる、トランザクションに割当てられるこの「完了時点」の番号は通常、トランザクションにおいて行なわれた最後の変更に関連するＣＳＮである。たとえば、トランザクションＴＸ１のコミットＣＳＮは１７で、一方、トランザクションＴＸ２のコミットＣＳＮは２０である。
一実施例によれば、適用エンジンによって永続的に記憶されるLAST APPLIED CSNは、適用エンジンによってコミットされる最後のトランザクションのコミットＣＳＮであり、単に適用エンジンによって適用される最後の変更のＣＳＮではない。このため、この状況では、LAST APPLIED CSNは、LAST COMMITTED CSN（最後にコミットされたＣＳＮ）と呼ばれてもよい。最後の変更のＣＳＮというよりもむしろ、LAST COMMITTED CSNのみを永続的に保持することにより、永続的に記憶された情報を更新すべき頻度は著しく減少する。
このため、適用エンジンがＴＸ１の実行を完了すると、適用エンジンは、ＣＳＮ１７を反映するよう、LAST COMMITTED CSNを更新する。しかしながら、適用エンジンは、ＣＳＮ１８に関連するＴＸ２の変更の適用後、LAST COMMITTED CSNを１８に更新しない。むしろ、LAST COMMITTED CSNは、ＴＸ２が一旦完全に適用されると１７から変更されるだけであり、その時点でLAST COMMITTED CSNは２０に変更される。
このようにLAST COMMITTED CSNを恒久的に保持する実施例では、LAST COMMITTED CSNは、適用エンジンによって完全に適用された最後のトランザクションのコミット時点を反映している。適用エンジンは、LAST COMMITTED CSNに加え、まだ完全には適用されていない各トランザクションについて、HIGHEST-SO-FAR CSN（現時点で最高のＣＳＮ）を揮発性メモリに保持してもよい。あるトランザクションについてのHIGHEST-SO-FAR CSNは、適用エンジンがそのトランザクションについて適用した最後の変更のＣＳＮである。このため、適用エンジンは、ＣＳＮ１８に関連するＴＸ２の変更の適用後、LAST COMMITTED CSNを１８に更新しないものの、適用エンジンは、ＣＳＮ１８に関連するＴＸ２の変更の適用後、ＴＸ２についてのHIGHEST-SO-FAR CSNを１８に更新する。
適用エンジンは、LAST APPLIED CSNおよびHIGHEST-SO-FAR CSNに基づいて、既に適用した変更のどの複製も容易に識別し、廃棄することができる。すなわち、適用エンジンは、（１）LAST COMMITTED CSNよりも小さいかまたはそれと等しいコミットＣＳＮを有するトランザクションに属する変更、および（２）変更が属するトランザクションのHIGHEST-SO-FAR CSNよりも小さいかまたはそれと等しいＣＳＮを有する変更を廃棄することによって、既に適用された変更を廃棄する。
たとえば、LAST COMMITTED CSNが１７であると仮定されたい。適用エンジンがＴＸ１およびＣＳＮ１５に関連する変更を受信する場合、ＴＸ１のコミットＣＳＮがLAST COMMITTED CSN（つまり１７）よりも大きくないため、適用エンジンはその変更を廃棄する。他方、ＴＸ２のコミットＣＳＮが２０で、かつ適用エンジンがＴＸ２およびＣＳＮ１２に関連する変更を受信する場合、適用エンジンは１２をＴＸ２のHIGHEST-SO-FAR CSNと比較する。ＴＸ２のHIGHEST-SO-FAR CSNが１２に等しいかまたは１２よりも大きい場合、適用エンジンはＣＳＮ１２に関連する変更を廃棄する。他方、ＴＸ２のHIGHEST-SO-FAR CSNが１２よりも小さい場合、適用エンジンは変更を適用する。
OLDEST CSN（最も古いＣＳＮ）
一実施例によれば、適用中の変更がトランザクションの一部である場合、適用エンジンによって上流に送信されるＡＣＫメッセージは、LAST APPLIED CSNというよりもむしろ、OLDEST CSN値を含む。OLDEST CSNとは、コミットされていないすべてのトランザクションの最も古い変更ＣＳＮである。一実施例によれば、OLDEST CSN値は、適用エンジンによって永続的に記憶され、ＡＣＫメッセージを用いて定期的に上流に通信される。
あるトランザクションについての最も古い変更ＣＳＮは通常、そのトランザクションによって行なわれた第１の変更と関連するＣＳＮである。OLDEST CSNを最新に保つために、適用エンジンは、現在のOLDEST CSNに関連するトランザクションが十分に適用されると、OLDEST CSNを「高める」。たとえば、以下の３つのトランザクションを考慮されたい：
ＣＳＮ１２、１３、１７、２０での変更を有するＴＸ１
ＣＳＮ１１、１４、１５、１８、１９および２３での変更を有するＴＸ２
ＣＳＮ１６、２１、２２、２４および２５での変更を有するＴＸ３。
ＴＸ１、ＴＸ２およびＴＸ３のみが、適用が変更を受信したコミットされていないトランザクションである場合、OLDEST CSNは１１である（コミットされていないどのトランザクションからも最も古い変更ＣＳＮ）。適用エンジンが最初にＴＸ１への適用を終了すると仮定されたい。その時点で、LAST COMMITTED CSNは２０に変更されるが、OLDEST CSNは変わらない。なぜなら、ＴＸ１はOLDEST CSNに関連するトランザクションではなかったためである。
適用エンジンが次にＴＸ２の適用を終了すると、OLDEST CSNは１６に更新される。なぜなら、コミットされていない唯一のトランザクションはＴＸ３であり、ＴＸ３の最も古い
変更ＣＳＮは１６であるためである。この時点で、LAST COMMITTED CSNも２３に変更される。
このようにOLDEST CSNを保持することにより、OLDEST CSN未満の変更ＣＳＮに関連する変更はすべて既に適用されたということが保証される。このため、故障の場合、適用エンジンが、永続的に記憶されているOLDEST CSNを読出して、上流の構成要素に、OLDEST CSNで始まる変更情報を再送するよう要求することが安全である。
トランザクションのばらばらの順番での適用
上述の説明では、トランザクションがそれらのコミットＣＳＮの順序で適用されると仮定された。このため、ある変更が、LAST COMMITTED CSNよりも大きいＣＳＮを有するトランザクションについてである場合、その変更はまだ適用されていないと仮定することができる。しかしながら、一実施例によれば、適用エンジンは変更を並行して、かつ、全トランザクションがそれらのコミットＣＳＮの順序で適用されることを保証せずに整合性を保証する順序で適用することができる。
たとえば、トランザクションＴＸ１、ＴＸ２およびＴＸ３がそれぞれコミットＣＳＮ１７、２０および２５を有すると仮定されたい。一実施例によれば、ＴＸ３がＴＸ２に従属していない場合、適用エンジンは、ＴＸ２をコミットする前にＴＸ１およびＴＸ３をコミットしてもよい。ＴＸ３がコミットすると、LAST COMMITTED CSNは２５に更新される。しかしながら、ＴＸ２はまだコミットされていない。したがって、クラッシュが起こると、ＴＸ２に関連する変更は、それらの変更がクラッシュ前にコミットされていなかったとしても、コミット後に廃棄される。
他方、ＴＸ３の適用後にクラッシュが起こらないと仮定されたい。むしろ、適用エンジンが続いてＴＸ２を適用し、次にクラッシュが起こると仮定されたい。ＴＸ２の適用後、LAST COMMITTED CSNは２０に更新される。なぜなら、２０は適用されるべき最後のトランザクション（ＴＸ２）のコミットされたＣＳＮであるためである。２０というLAST COMMITTED CSN、およびＴＸ３が２５というコミットＣＳＮを有するということに基づき、適用エンジンは、ＴＸ３がクラッシュ前に既に十分に適用されていたとしても、ＴＸ３をクラッシュ後に再び適用する。
このため、トランザクションがばらばらのコミットＣＳＮの順で適用され得る環境では、LAST COMMITTED CSNは、変更が適用されるべきかまたは廃棄されるべきかを適用エンジンが判断するのに十分な情報を提供しないかもしれない。このため、トランザクションがばらばらの順序で適用され得る一実施例によれば、LOW WATERMARK CSN（低ウォーターマークＣＳＮ）およびOLDEST CSNが保持される。これらの値の各々の意味および用途を、以下により詳細に説明することとする。
LOW WATERMARK CSN
一実施例によれば、LOW WATERMARK CSNは、LOW WATERMARK CSNよりも低いかまたはそれと等しいコミットＣＳＮを有するトランザクションがすべて適用済みであると保証されるようなＣＳＮである。トランザクションが常にＣＳＮコミット順で適用されるシステムでは、LOW WATERMARK CSNはLAST COMMITTED CSNと同じである。しかしながら、トランザクションが必ずしもＣＳＮコミット順で適用されるとは限らないシステムでは、LOW WATERMARK CSNが、最も直前に適用されたトランザクションのコミットＣＳＮよりも小さいということが起こり得る。
LOW WATERMARK CSNを最新に保つために、適用エンジンは、（１）適用エンジンが現在のLOW WATERMARK CSNを上回るコミットＣＳＮを有するトランザクションの適用を終了す
る場合、および（２）ちょうど適用されたばかりのトランザクションのコミットＣＳＮよりも低いコミットＣＳＮを有する、適用されていないトランザクションがない場合に、LOW WATERMARK CSNを「高める」。
たとえば、トランザクションＴＸ１、ＴＸ２およびＴＸ３がそれぞれコミットＣＳＮ１７、２０および２５を有すると仮定されたい。（１）ＴＸ１が既に適用され、（２）現在のLOW WATERMARK CSNが１７であり、（３）適用エンジンがＴＸ２の前にＴＸ３を適用する、と仮定されたい。ＴＸ３が十分に適用されると、LOW WATERMARK CSNは更新されない。なぜなら、適用されていないトランザクション（ＴＸ２）が、ＴＸ３のコミットＣＳＮよりも低いコミットＣＳＮを有するためである。ＴＸ２が適用された後で、LOW WATERMARK CSNは２５に更新される。なぜなら、コミット時点が２５またはそれを下回るトランザクションがすべて、既に適用されているためである。
ABOVE-MARK APPLIED（マークを上回る適用済）トランザクション
LOW WATERMARKを上回るコミットＣＳＮを有する、既に適用されたトランザクションを、ここにABOVE-MARK APPLIEDトランザクションと呼ぶ。上述の例では、ＴＸ３がＴＸの前に十分に適用された場合、ＴＸ３はABOVE-MARK APPLIEDトランザクションとなった。一実施例によれば、適用エンジンは、LOW WATERMARK CSNに加え、ABOVE-MARK APPLIEDトランザクションについての情報を永続的に記憶する。一実現化例によれば、ABOVE-MARK APPLIEDトランザクションについての情報は揮発性メモリのハッシュテーブルに保持され、ハッシュテーブルは永続的なストレージ上にバックアップされる。
LOW WATERMARK、OLDEST CSNおよびABOVE-MARK情報を用いて変更を廃棄するかどうかを判断する
永続的なストレージ上にLOW WATERMARK CSN、ABOVE-MARK APPLIEDトランザクションについての情報、およびOLDEST CSNを保持する一実施例では、適用エンジンは、（１）OLDEST CSNよりも低いＣＳＮに関連する変更、（２）LOW WATERMARK CSNよりも小さいコミットＣＳＮを有するトランザクションに属する変更、（３）変更が属するトランザクションのHIGHEST-SO-FAR CSNよりも小さいかまたはそれと等しいＣＳＮを有する変更、および（４）ABOVE-MARK APPLIEDトランザクションに属する変更を廃棄することによって、既に適用された変更を廃棄する。
たとえば、LOW WATERMARK CSNが１８で、（コミット時点が２５の）ＴＸ３がABOVE-MARK APPLIEDトランザクションであると仮定されたい。これらの状況では、適用エンジンは、１８よりも低いコミットＣＳＮを有するトランザクションに関連する変更はどれも廃棄する。同様に、ＴＸ３に関連する多くの変更が１８というLOW WATERMARK CSNを上回るＣＳＮと関連していても、ＴＸ３がABOVE-MARK APPLIEDトランザクションであるため、ＴＸ３に関連する変更はすべて廃棄される。他方、コミットされていないトランザクションＴＸ２に関連する変更を適用エンジンが受取り、その変更が１２というＣＳＮを有する場合、適用エンジンは１２をＴＸ２のHIGHEST-SO-FAR CSNと比較する。ＴＸ２のHIGHEST-SO-FAR CSNが１２と等しいかまたは１２より大きい場合、適用エンジンはＣＳＮ１２に関連する変更を廃棄する。他方、ＴＸ２のHIGHEST-SO-FAR CSNが１２よりも小さい場合、適用エンジンは変更を適用する。
適用エンジンが引続きトランザクションを適用するにつれて、LOW WATERMARKの値は高まる。LOW WATERMARK CSNが高まるにつれ、それは、以前にABOVE-MARK APPLIEDトランザクションであったトランザクションのコミットＣＳＮを渡してもよい。一実施例によれば、ABOVE-MARK APPLIEDトランザクションを追跡するために使用されるハッシュテーブルは、LOW WATERMARK CSNがその後それよりも高まったコミットＣＳＮを有する以前のABOVE-MARK APPLIEDトランザクションについての情報をすべて除去するために、周期的に取除か
れる。
OLDEST CSNを保持する実施例では、ＡＣＫメッセージはOLDEST CSNを上流のエンティティに運ぶ。たとえば、再度図２４を参照すると、宛先サイト２４０２から中間サイト２４０４に定期的に送信されるＡＣＫメッセージは、現在のOLDEST CSNを含む。中間サイト２４０４は定期的にこの情報を保存し、それをＡＣＫメッセージでソースサイト２４００に転送する。ソースサイト２４００もこの情報を永続的なストレージに定期的に保存する。
適用エンジン用フローチャート
図２５を参照すると、それは、永続的に記憶されるLOW WATERMARK、永続的に記憶されるOLDEST CSN、ABOVE-MARK APPLIEDトランザクションを識別する永続的に記憶されるデータ、および非永続的に記憶されるHIGHEST-SO-FAR CSNを用いて１回のみの運転を達成する、この発明の一実施例に従った適用エンジンによって実行されるステップを示すフローチャートである。
ステップ２５０２で、適用エンジンはある項目を受信する。その項目はあるＣＳＮを有し、あるトランザクションに属している。ステップ２５０３で、適用エンジンはその項目がOLDEST CSNよりも小さいＣＳＮを有するかどうかを判断する。その項目がOLDEST CSNよりも小さいＣＳＮを有する場合、その項目はステップ２５１０で廃棄される。他方、その項目がOLDEST CSNと等しいかまたはそれよりも大きいＣＳＮを有する場合、制御はステップ２５０４に進む。
ステップ２５０４で、適用エンジンは、その項目が現在のLOW WATERMARKよりも小さいかまたはそれと等しいコミット時点を有するトランザクションに属するかどうかを判断する。その項目が現在のLOW WATERMARKを下回るコミット時点を有するトランザクションに属する場合、その項目はステップ２５１０で廃棄される。他方、ＣＳＮが現在のLOW WATERMARKよりも大きいコミット時点を有するトランザクションに属する場合、制御はステップ２５０６に進む。
ステップ２５０６で、適用エンジンは、その項目がABOVE-MARK APPLIEDトランザクションに属するかどうかを判断する。その項目がABOVE-MARK APPLIEDトランザクションに属する場合、ステップ２５１０でその項目は廃棄される。その項目がABOVE-MARK APPLIEDトランザクションに属していない場合、制御はステップ２５０８に進む。
ステップ２５０８で、適用エンジンは、その項目のＣＳＮが、その項目が属するトランザクションについてのHIGHEST-SO-FAR CSNよりも小さいかまたはそれと等しいかどうかを判断する。その項目のＣＳＮが、その項目が属するトランザクションについてのHIGHEST-SO-FAR CSNよりも小さいかまたはそれと等しい場合、その項目はステップ２５１０で廃棄される。その項目のＣＳＮが、その項目が属するトランザクションについてのHIGHEST-SO-FAR CSNよりも大きい場合、その項目はステップ２５１２で適用される。
その項目が適用された後、ステップ２５１４で、適用エンジンはトランザクションについてのHIGHEST-SO-FAR CSNを更新する。ステップ２５１６で、適用エンジンは、その項目が属するトランザクションが完全に適用されたかどうかを判断する。項目が属するトランザクションが完全に適用された場合、制御はステップ２５１８に進む。その項目が属するトランザクションが完全には適用されていなかった場合、その項目の処理は終了する（ステップ２５２４）。
ステップ２５１８で、適用エンジンは、LOW WATERMARKが更新される必要があるかどうかを判断する。ちょうど適用されたばかりのトランザクションのコミットＣＳＮを下回る
コミットＣＳＮを有する、適用されていないトランザクションがない場合、LOW WATERMARKは更新される。制御はステップ２５２０に渡る。
ステップ２５２０で、適切な場合、OLDEST CSNが更新される。すなわち、ちょうど適用されたばかりのトランザクションが最も古い、まだ適用されていない変更を含んでいた場合、OLDEST CSNは、残りの適用されていないトランザクションの最も古い変更ＣＳＮを反映するよう、更新される。
ステップ２５２２で、適切な場合、ABOVE-MARK APPLIEDトランザクション情報が更新される。すなわち、ちょうど適用されたばかりのトランザクションが現在のLOW WATERMARKを上回った場合、および、ステップ２５１８でLOW WATERMARKがそのトランザクションのコミット時点にまで、またはそれより上に高められなかった場合には、そのトランザクションはABOVE-MARK APPLIEDトランザクションであり、ABOVE-MARK APPLIEDトランザクション情報はそのトランザクションを含むよう更新される。ABOVE-MARK APPLIEDトランザクション情報が更新された後で、その項目の処理は終了する（ステップ２５２４）。
前述の例は、適用エンジンが宛先サイトで、別のサイトから受取った変更情報に基づいて変更を行なうという状況で挙げられているが、ここに説明される手法はどの特定の状況にも限定されない。たとえば、適用エンジンによって受取られる「項目」は、１回のみ取扱われる必要があるどの形態の情報であってもよい。さらに、項目を「適用する」ために適用エンジンによって実行される実際のステップは、実現化例によって異なる。たとえば、「項目」は個々の項目に対する注文であってもよく、「トランザクション」は１組の項目注文を含む購入注文に対応していてもよく、項目の「適用」は、購入注文に対して請求書を作成することに関与していてもよい。
情報共有システム１００を用いたＤＤＬの複製
上述のように、データベースオブジェクトのいくつかのコピーを保持することが有益な多くの状況がある。上述の例の多くは、各複製に含まれるデータが、同じデータベースオブジェクトの他のすべてのデータに含まれるデータと整合性を保つことを確実にするために、情報共有システム１００がいかに用いられ得るか、について説明している。すなわち、情報共有システム１００は、複製のうちのいずれか１つに対して行なわれた変更を、他の複製の各々が存在するサイトに伝播し、適用するために使用されてもよい。
情報共有システム１００は、あるオブジェクトの複製に含まれるデータの整合性を保つことに加え、複製自体の構造の整合性を保つために使用されてもよい。すなわち、データ定義言語（ＤＤＬ）ステートメントは、テーブルなどのデータベースオブジェクトを定義し、その構造を変更し、ドロップするデータベースコマンドである。ＤＤＬステートメントがあるオブジェクトの１つの複製に対して実行されると、その複製の構造は変更され、同じオブジェクトの他の複製の構造と、もはや整合しない。一実施例によれば、情報共有システム１００は、他の複製の構造が変更された複製と整合したまま保たれるように、ＤＤＬステートメントを他の複製に伝播し、適用するために使用される。
さらに、情報共有システム１００は、複製の最初の作成を自動化するために使用されてもよい。たとえば、ユーザがデータベースＡにテーブルＴ１を作成するためにＤＤＬステートメントを発行すると仮定されたい。この発明の一実施例によれば、このＤＤＬステートメントの記録が生成され、データベースＡの再実行ログに記録される。データベースＡの再実行ログをマイニングするよう設定されている取得プロセスは、再実行ログからＤＤＬステートメントを取得し、ＤＤＬステートメントに基づいてイベントを生成する。このイベントは次に、ステージングエリアに記憶され、ゆくゆくは１つ以上の他のデータベースに伝播されてもよい。これらの他のデータベースの各々において、適用エンジンは、こ
れらのデータベース内で対応するＤＤＬステートメントを発行することによってイベントを「適用」するよう設定されてもよい。これらのＤＤＬステートメントの実行により、テーブルＴ１の複製の作成がデータベースの各々において作成される。
なお、このようにＤＤＬを複製することは、情報共有システム間でクェーシングを全く必要とせず、情報共有システムに対して実行可能な活動に制約はない。すなわち、このようにＤＤＬを複製することは、ＤＤＬの複雑性または性質にかかわらず、オブジェクト／システム上でのユーザ活動の停止を必要としない。
ＤＤＬ動作についての情報の生成
ＤＤＬ動作についての再実行情報を生成しないシステムでは、ＤＤＬ動作の結果として生成される再実行情報が依然として存在する場合がある。たとえば、ＤＤＬ動作がデータベース内でのテーブルの作成をもたらしたと仮定されたい。テーブルの作成は、データベースのさまざまなテーブルについてのメタデータを記憶するために使用される既存のシステムテーブルに、データの１つ以上の行を挿入するＤＭＬ動作を伴ってもよい。これらのシステムテーブル内のデータに対して行なわれた変更に応じて、ＤＭＬ再実行情報が生成されてもよい。しかしながら、システムテーブルの内容への変更をもたらした特定のＤＤＬ動作を、それらのシステムテーブルへの更新に応じて生成される再実行情報のみに基づいて再度構築しようとすることは、不可能ではないものの、極度に困難である。このため、それらのＤＤＬ動作について特定の情報を生成することは、ＤＤＬ動作の非同期的複製が望まれる状況において著しい利点を提供する。
一実施例によれば、ＤＤＬ動作について生成される再実行情報は、従属性情報（つまり、ＤＤＬに従属する／ＤＤＬによって影響されるオブジェクト）を含む。一般に、そのような従属性情報は、ＤＤＬ動作の結果生成されるＤＭＬ再実行からは再構築できない。
上述の例では、ＤＤＬ動作が最初に実行されたデータベース（「ソース」データベース）は、ＤＤＬ動作についての再実行情報を生成するよう設定されている。再実行はＤＤＬ動作について生成されていたため、ＤＤＬ動作は、ソースデータベースの再実行ログをマイニングする取得プロセスによって正確に取得され得る。ＤＤＬ動作は正確に取得されるため、それは所望のターゲットデータベースで正確に適用され得る。一実施例によれば、ＤＤＬ動作について生成される再実行情報は、とりわけ、ソースデータベースによって実行されたＤＤＬステートメントを反映する文字列を含む。
ＤＤＬ動作についての特定の情報を再実行ログ内に記憶することは、ＤＤＬ動作がどのようにソースデータベース内に記録され得るかの単なる一例である。ここに説明した複製手法はどの特定のＤＤＬ動作記録手法にも限定されない。ＤＤＬ動作の正確な記述が再構築可能である限り、情報共有システム１００は、ＤＤＬ変更を他のデータベースシステムに非同期的に伝播し、適用するために使用されてもよい。
多方向ＤＤＬ複製
情報共有システム１００は、情報を共有するために情報共有システム１００を使用するあらゆるシステム間でＤＤＬ複製を実行するために使用されてもよい。したがって、双方向および多方向ＤＤＬ複製が可能である。たとえば、情報共有システム１００は、５つのデータベースシステム間でＤＤＬを複製するのに、５つのデータベースシステムのうちのいずれか１つで実行されたＤＤＬステートメントが、他の４つのデータベースシステムで実行中の対応するＤＤＬステートメントをもたらすよう、設定されてもよい。
そのような５方向の複製シナリオでは、第１のデータベースシステムで作成されたテーブルは、第２のデータベースシステムでそれに追加された列を有する場合があり、第３の
データベースシステムでそれからドロップされた別の列を有する場合がある。これらの変更の各々が行なわれるにつれて、対応する変更が他の４つのデータベースシステムの各々で行なわれる。すなわち、第１のデータベースシステムにおけるテーブルの作成は、他の４つのデータベースシステムの各々におけるテーブルの複製の作成をもたらし得る。第２のデータベースシステムにおけるその後の列の追加は、対応する列が他の４つのデータベースシステムの各々におけるテーブルの複製に追加されることをもたらす。第３のデータベースシステムにおけるその後の列のドロップは、対応する列が他の４つのデータベースシステムの各々におけるテーブルの複製でドロップされることをもたらす。これらのＤＤＬ動作のすべてがさまざまなデータベース間で複製されている間、（ＤＤＬ動作およびＤＭＬ動作を含む）活動が引続きデータベース上で、さらにはＤＤＬ動作のターゲットであるテーブル上でですら、何の制約もなく起こり得る。
上述の５方向の複製シナリオでは、ＤＤＬ変更はすべて、変更が生じたデータベースシステム内で変更が実行されたのと全く同じように、データベースシステムの各々に伝播され、そこで実行される。しかしながら、いつもこうである必要はない。上に詳細に説明したように、取得エンジン、伝播エンジン、および適用エンジンを含む、複製プロセスに関与する構成要素の各々の動作は、規則を規則エンジンに登録することによってカスタマイズされてもよい。これらの規則は、構成要素の各々がいかに動作すべきであるかを細かいレベルの細分性で特定してもよい。たとえば、規則は選択基準を特定してもよく、その場合、選択基準を満たすＤＤＬ変更のみが取得、伝播および／または適用される。さらに、それらの規則は、ＤＤＬ変更情報に対して実行されるべき変換を特定してもよく、この場合、変換は、ＤＤＬ変更の取得、伝播および／またはアプリケーション中に適用されてもよい。
テーブル以外のオブジェクトのＤＤＬ複製
上述の例では、複製されたＤＤＬ動作は、テーブルに関する動作である。しかしながら、情報共有システム１００は、任意の形のＤＤＬ動作を複製するために使用されてもよい。たとえば、情報共有システム１００は、ユーザがある特定のデータベースシステムに追加されるのに応じて、１つ以上のデータベースシステムに新規ユーザを作成するために使用されてもよい。同様に、情報共有システム１００は、ユーザがある特定のデータベースシステムに追加されるのに応じて、１つ以上のデータベースシステムに新しい許可を作成するために使用されてもよい。
ＤＬＬコマンドによって作成および／または変更されるデータベースオブジェクトの他の種類は、ビュー、トリガ、プロシージャ、インデックス、順序、同義語、ロールバックセグメント、アウトライン、データベースリンク、具体化されたビュー、具体化されたビューログなどを含むが、これらに限定されない。ここに説明される手法は、これらの種類のオブジェクトのいずれかを作成または変更するために使用されるＤＤＬを複製するために用いられてもよい。上述のように、データベースオブジェクトのこれらの他の種類のいずれかについてＤＤＬが複製されている間、データベース活動に対する制約はない。
複製されたＤＤＬ変更の適用
（１）ＤＭＬ変更の第１の組がオブジェクトに対して行なわれ、次に（２）ＤＤＬ動作がそのオブジェクトに対して実行され、次に（３）ＤＭＬ変更の第２の組がそのオブジェクトに対して行なわれる、というシナリオを考慮されたい。オブジェクトへのＤＭＬ変更およびＤＤＬ変更の双方が複製中である場合には、宛先が、複製へのＤＤＬ変更の前にＤＭＬ変更の第１の組を適用し、複製へのＤＤＬ変更の後でＤＭＬ変更の第２の組を適用することが重要である。
一実施例によれば、ＤＭＬ変更とＤＤＬ変更との間の従属性を追跡するためのメカニズ
ムが提供される。たとえば、上に提示したシナリオでは、ＤＤＬ動作はＤＭＬ変更の第１の組に従属しており、ＤＭＬ変更の第２の組はＤＤＬ動作に従属している。この従属性情報を追跡し、ＤＭＬ変更およびＤＤＬ変更が複製される宛先サイトに従属性情報を運ぶことによって、宛先サイトは、変更が適切な順序で実行されることを確実にすることができる。
あるデータベースオブジェクトに対して実行されるＤＤＬは、別のデータベースオブジェクトに対して著しく影響を与える場合がある。これらの状況では、第２のオブジェクトは、第１のオブジェクトに対して従属性を有するといわれる。第２のオブジェクトに対して実行されるＤＭＬ動作は、第１のオブジェクトに対して実行されるＤＤＬ動作によって影響され得る。したがって、従属性追跡メカニズムは、オブジェクト間の従属性についての情報を用いて、ＤＤＬ動作とＤＭＬ動作との間の従属性を決定する。宛先サイトはこの情報を用いて、ＤＤＬ動作およびＤＭＬ動作が、従属性関係によって指示されるように、正しい順序で宛先サイトで適用されることを確実にする。加えて、この従属性情報は、他のどのアクションがＤＤＬ動作と同時に実行されるかを判断するために使用されてもよい。たとえば、データベースサーバは、複製されたＤＤＬ動作およびＤＭＬ動作といった動作を、動作間に従属性がない限り、並行して実行するよう設定されてもよい。
変更情報についてのＸＭＬスキーマ
上述の例の多くでは、情報共有システム１００は、１つの「ソース」システム内で行なわれた変更についての情報を、１つ以上の「宛先」システムと共有するために使用される。変更情報を運ぶために使用される記録の構造は、実現化例ごとに異なっていてもよい。ここに説明される手法は、記録用のどの特定の構造にも依存しない。
一実施例によれば、変更情報のさまざまな断片（セクション「論理変更記録」を参照）は、ＸＭＬスキーマに準拠する構造に記憶される。一実施例では、ＬＣＲの構造は以下のＸＭＬスキーマに準拠する。
Figure 2006501585
Figure 2006501585
Figure 2006501585
Figure 2006501585
この例示的なＸＭＬスキーマは、さまざまな種類の変更情報の各々についてのセクションを含む。たとえば、タグ＜element name=“DDL_LCR”＞の直後のセクションは、この発明の一実施例に従った、ＤＤＬ変更に関連する記録の構造を特定している。同様に、タグ＜element name=“ROW_LCR”＞の直後のセクションは、この発明の一実施例に従った、テーブルのある行へのＤＭＬ変更に関連する記録の構造を特定している。
ハードウェア概要
図２６は、この発明の一実施例が実現され得るコンピュータシステム２６００のブロック図を示す。コンピュータシステム２６００は、情報を通信するためのバス２６０２または他の通信メカニズムと、情報を処理するためにバス２６０２と結合されたプロセッサ２６０４とを含む。コンピュータシステム２６００はまた、プロセッサ２６０４により実行されるべき命令および情報を記憶するためにバス２６０２に結合された、ランダムアクセスメモリ（ＲＡＭ）または他のダイナミック記憶装置といったメインメモリ２６０６も含む。メインメモリ２６０６は、プロセッサ２６０４により実行されるべき命令の実行中に一時的な変数または他の中間情報を記憶するためにも使用されてもよい。コンピュータシステム２６００はさらに、プロセッサ２６０４用の命令およびスタティック情報を記憶するためにバス２６０２に結合された読出専用メモリ（ＲＯＭ）２６０８または他のスタティック記憶装置を含む。磁気ディスクまたは光ディスクといった記憶装置２６１０が、情報および命令を記憶するために提供され、バス２６０２に結合されている。
コンピュータシステム２６００は、情報をコンピュータユーザに表示するためのブラウン管（ＣＲＴ）などのディスプレイ２６１２に、バス２６０２を介して結合されていてもよい。英数字キーおよび他のキーを含む入力装置２６１４が、情報およびコマンド選択をプロセッサ２６０４に通信するためにバス２６０２に結合されている。ユーザ入力装置の別の種類は、方向情報およびコマンド選択をプロセッサ２６０４に通信し、ディスプレイ２６１２上のカーソルの動きを制御するための、マウス、トラックボール、またはカーソル方向キーといったカーソル制御２６１６である。この入力装置は通常、２つの軸、つまり第１の軸（たとえばｘ）および第２の軸（たとえばｙ）において２つの自由度を有しており、それによりこの装置は平面における場所を特定することができる。
この発明は、ここに説明された手法を実現するためのコンピュータシステム２６００の使用に関する。この発明の一実施例によれば、これらの手法は、プロセッサ２６０４がメインメモリ２６０６に含まれる１つ以上の命令の１つ以上のシーケンスを実行するのに応じて、コンピュータシステム２６００によって実行される。そのような命令は、記憶装置２６１０などの別のコンピュータ読み取り可能な媒体からメインメモリ２６０６に読込まれてもよい。メインメモリ２６０６に含まれる命令のシーケンスの実行により、プロセッ
サ２６０４は、ここに説明されたプロセスステップを実行するようになる。代替的な実施例では、この発明を実現するために、ソフトウェア命令の代わりに、またはソフトウェア命令と組合わせて、配線接続回路が使用されてもよい。このため、この発明の実施例は、配線接続回路とソフトウェアとのどの特定の組合せにも限定されない。
ここで用いられるような用語「コンピュータ読み取り可能な媒体」とは、プロセッサ２６０４に命令を実行用に提供することに関与するあらゆる媒体を指す。そのような媒体は、不揮発性媒体、揮発性媒体、および通信媒体を含むもののそれらに限定されない多くの形態を取り得る。不揮発性媒体はたとえば、記憶装置２６１０などの光ディスクまたは磁気ディスクを含む。揮発性媒体は、メインメモリ２６０６などのダイナミックメモリを含む。通信媒体は、バス２６０２を構成する配線を含む、同軸ケーブル、銅線および光ファイバを含む。通信媒体はまた、無線周波数および赤外線データ通信中に発生するものといった音波または光波の形も取り得る。
コンピュータ読み取り可能な媒体の一般的な形態は、たとえば、フロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、磁気テープ、または任意の他の磁気媒体、ＣＤ−ＲＯＭ、任意の他の光媒体、パンチカード、紙テープ、孔のパターンを有する任意の他の物理的媒体、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭ、任意の他のメモリチップまたはカートリッジ、以下に説明するような搬送波、または、コンピュータがそこから読み取り可能な任意の他の媒体を含む。
コンピュータ読み取り可能な媒体のさまざまな形態は、プロセッサ２６０４への１つ以上の命令の１つ以上のシーケンスを実行用に保持することに関与していてもよい。たとえば、命令はまず、遠隔コンピュータの磁気ディスク上に保持されてもよい。遠隔コンピュータは命令をそのダイナミックメモリにロードし、電話回線を通してモデムを用いて命令を送信することができる。コンピュータシステム２６００にとってローカルなモデムは、電話回線上のデータを受信し、赤外線送信機を用いてデータを赤外線信号に変換することができる。赤外線検出器は赤外線信号で搬送されたデータを受信でき、適切な回路がデータをバス２６０２上に配置することができる。バス２６０２はデータをメインメモリ２６０６に搬送し、そこからプロセッサ２６０４が命令を検索して実行する。メインメモリ２６０６によって受信された命令は、プロセッサ２６０４による実行の前または後のいずれかで、記憶装置２６１０上に随意に記憶されてもよい。
コンピュータシステム２６００はまた、バス２６０２に結合された通信インターフェイス２６１８も含む。通信インターフェイス２６１８は、ローカルネットワーク２６２２に接続されたネットワークリンク２６２０に双方向データ通信結合を提供する。たとえば、通信インターフェイス２６１８は、データ通信接続を対応する種類の電話回線に提供するデジタル相互サービス網（ＩＳＤＮ）カード、またはモデムであってもよい。別の例として、通信インターフェイス２６１８は、データ通信接続を互換性があるＬＡＭに提供するローカルエリアネットワーク（ＬＡＮ）カードであってもよい。無線リンクも実現され得る。任意のそのような実現化例では、通信インターフェイス２６１８は、さまざまな種類の情報を表わすデジタルデータ情報共有システム１００を搬送する電気信号、電磁信号、または光信号を送信および受信する。
ネットワークリンク２６２０は通常、１つ以上のネットワークを介して、他のデータ装置にデータ通信を提供する。たとえば、ネットワークリンク２６２０は、ローカルネットワーク２６２２を介して、ホストコンピュータ２６２４に、またはインターネットサービスプロバイダ（ＩＳＰ）２６２６により運営されるデータ装置に、接続を提供してもよい。ＩＳＰ２６２６は次に、現在一般に「インターネット」２６２８と呼ばれている全世界的パケットデータ通信ネットワークを介して、データ通信サービスを提供する。ローカル
ネットワーク２６２２およびインターネット２６２８は双方とも、デジタルデータ共有システム１００を搬送する電気信号、電磁信号または光信号を使用する。コンピュータシステム２６００へ、またはコンピュータシステム２６００からデジタルデータを搬送する、さまざまなネットワークを通る信号、ネットワークリンク２６２０上の信号、および通信インターフェイス２６１８を通る信号は、情報を運ぶ搬送波の例示的な形態である。
コンピュータシステム２６００は、ネットワーク、ネットワークリンク２６２０および通信インターフェイス２６１８を介して、メッセージを送信し、プログラムコードを含むデータを受信する。インターネットの例では、サーバ２６３０は、アプリケーションプログラム用の要求されたコードを、インターネット２６２８、ＩＳＰ２６２６、ローカルネットワーク２６２２、および通信インターフェイス２６１８を介して送信してもよい。
受信されたコードは、受信された際にプロセッサ２６０４によって実行されてもよく、および／または、後の実行用に記憶装置２６１０または他の不揮発性ストレージに記憶されてもよい。このように、コンピュータシステム２６００は、搬送波の形をしたアプリケーションコードを取得し得る。
前述の明細書において、この発明の実施例を、実現化例ごとに異なり得る多数の特定の詳細を参照して説明してきた。このため、この発明が何であるか、および出願人らによって何がこの発明となるよう意図されているかの唯一かつ排他的な指標は、この出願に由来する１組の請求項であり、それらは、任意のその後の補正を含む、そのような請求項が発行する特定の形をとっている。そのような請求項に含まれる用語についてここに特に述べられたどの定義も、そのような用語の意味を、請求項において使用されているように決定するものとする。このため、請求項に特に記載されていない限定、要素、特性、特徴、利点または属性はどれも、そのような請求項の範囲を決して限定してはならない。したがって、明細書および図面は、限定的な意味というよりもむしろ例示的な意味で考慮されるべきである。
この発明の一実施例に従って設定された情報共有システムのブロック図である。 この発明の一実施例に従った、データ項目が情報共有システムを流通するのに伴って経験する３つの一般的な段階を示すブロック図である。 この発明の一実施例に従った、データベース内の変更の自動的な取得を示すブロック図である。 この発明の一実施例に従った、ソースキューから宛先キューに伝播されるイベントを示すブロック図である。 この発明の一実施例に従って実現される、ディレクテッド・ネットワーク環境を示すブロック図である。 この発明の一実施例に従った、１つのキューにおけるイベントの明示的なエンキューおよびデキューを示すブロック図である。 この発明の一実施例に従った、イベントの明示的なエンキュー、伝播、およびデキューを示すブロック図である。 この発明の一実施例に従った適用プロセスを示すブロック図である。 この発明の一実施例に従った、適用動作中の変換を示すブロック図である。 オラクルのデータベースシステムから非オラクルのデータベースシステムへのデータの共有のための、情報共有システムの使用を示すブロック図である。 非オラクルのデータベースシステムからオラクルのデータベースシステムへのデータの共有のための、情報共有システムの使用を示すブロック図である。 この発明の一実施例に従った、１つのデータベース内で実現される情報共有システムを示すブロック図である。 この発明の一実施例に従った、複数のデータベース間で情報を共有するために用いられる情報共有システムを示すブロック図である。 この発明の一実施例に従った、複数のデータベース間で情報を共有するために用いられる情報共有システムを示すブロック図である。 この発明の一実施例に従った、規則セットの評価プロセスのステージを示すブロック図である。 この発明の一実施例に従い、１つの規則セットが規則エンジンの複数のクライアントにより使用され得ることを示すブロック図である。 この発明の一実施例に従った、取得中の変換を示すブロック図である。 この発明の一実施例に従った、伝播中の変換を示すブロック図である。 各データベースがソースデータベースおよび宛先データベースの両方である多ノードのシステムを示すブロック図である。 各データベースがソースデータベースおよび宛先データベースの両方である多ノードのシステムを示すブロック図である。 各データベースがソースデータベースおよび宛先データベースの両方である多ノードのシステムを示すブロック図である。 各データベースがソースおよび宛先データベースである場合の、タグの使用を示すブロック図である。 一次データベースがいくつかの二次データベースとデータを共有していることを示すブロック図である。 一次データベースで用いられるタグを示すブロック図である。 二次データベースで用いられるタグを示すブロック図である。 一次データベースといくつかの拡張二次データベースとを示すブロック図である。 この発明の一実施例に従った、１つの中間サイトを介した、ソースサイトから宛先サイトへの変更情報のメモリ内ストリーミングを示すブロック図である。 この発明の一実施例に従い、永続的に記憶されたLOW WATERMARKと、ABOVE-MARK APPLIEDトランザクションを識別する永続的に記憶されるデータと、非永続的に記憶されるHIGHEST SO FAR CSNとを用いて１回のみの運転を達成する適用エンジンによって実施されるステップを示すフロー図である。 この発明の実施例が実現され得るコンピュータシステムのブロック図である。

Claims (67)

  1. 情報を共有するための方法であって、
    明示的な取得プロセスが、ステージングエリアに関連するＡＰＩを介して明示的な呼出を行なうことにより、前記ステージングエリアに１つ以上の情報項目の第１の組を追加するステップと、
    暗黙的な取得プロセスが、前記暗黙的な取得プロセスに関連するシステムにおいて起こるイベントに基づいて、前記ステージングエリアに１つ以上の情報項目の第２の組を自動的に追加するステップと、
    消費プロセスが、前記ステージングエリアに記憶された情報項目を消費するステップとを含む、方法。
  2. １つ以上の情報項目の第２の組を自動的に追加する前記ステップは、データベースシステム内に生成されるログファイルの内容に基づいて、前記ステージングエリアに情報項目を挿入する取得プロセスによって実行される、請求項１に記載の方法。
  3. 前記ステージングエリアは前記データベースシステムによって管理される、請求項２に記載の方法。
  4. 前記ログは、前記データベースシステム内で行なわれた変更を識別し、１つ以上の情報項目の前記組は、１組の前記変更を反映する記録を含む、請求項２に記載の方法。
  5. 前記１組の前記変更は、前記ログに反映されるすべての変更のサブセットであり、
    前記取得プロセスは、前記データベースシステム内に記憶されたメタデータに示された規則に基づいて、前記記録においてどの変更を反映させるかを選択する、請求項４に記載の方法。
  6. 前記明示的な取得プロセス、前記暗黙的な取得プロセス、および前記消費プロセスは、情報共有システムの構成要素であり、
    前記方法はさらに、
    前記情報共有システムが、前記構成要素の少なくとも１つがどのように機能すべきかを示す１つ以上の規則を特定する規則データを受取るステップと、
    前記情報共有システム内に前記１つ以上の規則を表わすメタデータを記憶することによって、前記規則データを登録するステップと、
    前記少なくとも１つの構成要素が前記メタデータを読出し、前記メタデータにおいて特定される態様で機能するステップとを含む、請求項１に記載の方法。
  7. 前記規則データは、前記少なくとも１つの構成要素が前記情報項目をどのように変換すべきかを示す規則を含む、請求項６に記載の方法。
  8. 前記情報共有システムはデータベースシステムを含み、
    前記規則データを登録する前記ステップは、前記データベースシステム内に、前記１つ以上の規則を表わすメタデータを記憶するステップを含み、
    前記少なくとも１つの構成要素は、前記データベースシステム内で実行するプロセスである、請求項６に記載の方法。
  9. 前記暗黙的な取得プロセスが、１つ以上の情報項目の前記第２の組の各情報項目内に、前記情報項目が前記システムにおいて起こったイベントに対応していることを示すタグ値を記憶するステップと、
    さもなければ前記イベントが前記システム内で再度適用されることを引き起こすサイク
    ルを回避するために、前記タグ値を使用するステップとをさらに含む、請求項１に記載の方法。
  10. 前記情報項目を前記ステージングエリアから第２のシステムに伝播するステップと、
    前記第２のシステムにおいて前記情報項目に関連する前記イベントを適用することによって、前記第２のシステムにおいて変更を行なうステップとをさらに含み、
    前記第２のシステムは、前記第２のシステムにおける変更を前記第１のシステムに伝播するよう設定されており、
    サイクルを回避するために前記タグ値を使用する前記ステップは、前記情報項目における前記タグ値に基づいて、前記変更が前記第１のシステムに伝播されることを防止するステップを含む、請求項９に記載の方法。
  11. 前記システムは第１のシステムであり、
    前記暗黙的な取得プロセスは、前記第１のシステムに対して遠隔の第２のシステムにおいて実行される、請求項１に記載の方法。
  12. 前記第１のシステムから前記第２のシステムにログを通信するステップと、
    前記暗黙的な取得プロセスが、前記ログに含まれる情報に基づいて、情報項目の前記第２の組を生成するステップとをさらに含む、請求項１１に記載の方法。
  13. 前記第１のシステムは第１のデータベースシステムであり、
    前記第２のシステムは第２のデータベースシステムであり、
    前記ログは、前記第１のデータベースシステムにより生成される再実行ログであり、
    情報項目の前記第２の組は、前記第１のデータベースシステムにおいて行なわれた変更を識別する、請求項１２に記載の方法。
  14. 前記ステージングエリアは前記第２のデータベースシステム内にあり、
    前記方法はさらに、前記ステージングエリアから情報項目の前記第２の組を読出し、情報項目の前記第２の組に基づいて前記第２のデータベースシステムにおいて変更を行なうために、適用プロセスを使用するステップを含む、請求項１３に記載の方法。
  15. 情報を共有するための方法であって、
    取得プロセスが、前記取得プロセスに関連する第１のシステムにおいて起こるイベントに基づいて、前記ステージングエリアに１つ以上の情報項目の組を自動的に追加するステップと、
    前記取得プロセスが、１つ以上の情報項目の前記組の各情報項目内に、前記情報項目が前記第１のシステムにおいて起こったイベントに対応していることを示すタグ値を記憶するステップと、
    情報項目を前記ステージングエリアから第２のシステムに伝播するステップと、
    前記情報項目に関連する前記イベントを前記第２のシステムにおいて適用することによって、前記第２のシステムにおいて変更を行なうステップとを含み、
    前記第２のシステムは、前記第２のシステムにおける変更を前記第１のシステムに伝播するよう設定されており、前記方法はさらに、
    前記情報項目における前記タグ値に基づいて、前記変更が前記第１のシステムに伝播されることを防止することによってサイクルを回避するために、前記タグ値を使用するステップを含む、方法。
  16. 情報を共有するための方法であって、
    取得プロセスが、第１のデータベースシステムにおいて生成される再実行ログファイルを調べるステップと、前記再実行ログファイルにおいて示されるイベントに基づいて、ス
    テージングエリアに１つ以上の情報項目の組を追加するステップとを自動的に行なうステップと、
    消費プロセスが、前記再実行ログファイルに示されるイベントに基づいて、前記ステージングエリアの情報項目を読出し、第２のデータベースシステムにおいて変更が行なわれるようにすることによって、前記ステージングエリアから情報項目を自動的に処理するステップとを含む、方法。
  17. 前記第２のデータベースにおいて変更が行なわれるようにする前記ステップは、前記第１のデータベースシステムにおける１つ以上のデータベースオブジェクトの複製を前記第２のデータベースシステムに保持するステップを含み、前記１つ以上のデータベースオブジェクトは前記第１のデータベースシステムにおける複製可能なオブジェクトのサブセットである、請求項１６に記載の方法。
  18. 変更が行なわれるようにする前記ステップは、
    前記変更をもたらすためにデータベースコマンドを構築するステップと、
    前記データベースコマンドを前記第２のデータベースシステムに提出するステップとを含む、請求項１６に記載の方法。
  19. 前記第１のデータベースシステムは、前記第２のデータベースシステムとは異なる種類のデータベースシステムである、請求項１６に記載の方法。
  20. サブスクライバを示すサブスクリプションデータと、前記サブスクライバが関心を持つ情報とを受取るステップと、
    第２の消費プロセスが、前記ステージングエリアから情報項目を自動的に読出し、前記サブスクリプションデータに基づいて、前記情報項目に関連するイベントに関心があるサブスクライバに通知するステップとをさらに含む、請求項１６に記載の方法。
  21. 情報を共有するための方法であって、
    １組の取得規則をデータベースシステム内に登録するステップと、
    １組の伝播規則を前記データベースシステム内に登録するステップと、
    前記１組の取得規則に基づいて、前記データベースシステム内で起こるどのイベントが取得されるべきかを判断するステップと、
    前記イベントについての情報をステージングエリアに記憶することによって、前記イベントを取得するステップと、
    前記１組の伝播規則に基づいて、前記ステージングエリアから情報をどのように伝播するかを判断するステップと、
    前記１組の伝播規則に基づいて、前記ステージングエリアから情報を伝播するステップとを含む、方法。
  22. １組の適用規則を登録するステップと、
    前記ステージングエリアから伝播された前記情報を受取るステップと、
    前記１組の適用規則に基づいて、前記ステージングエリアから受取られた前記情報を適用するステップとをさらに含む、請求項２１に記載の方法。
  23. 前記イベントを取得する前記ステップは、前記データベースシステムによって生成されるログを読出すステップと、前記ログにおいて識別されたイベントについての情報を前記ステージングエリアに選択的に記憶するステップとを含む、請求項２１に記載の方法。
  24. 伝播の前記ステップは、前記情報を第２のステージングエリアに伝播するステップを含み、
    前記方法はさらに、前記第２のステージングエリアにおいて識別された変更を第２のデータベースシステムに適用するステップを含む、請求項２１に記載の方法。
  25. 前記方法はさらに、１組の適用規則を登録するステップを含み、
    変更を適用する前記ステップは、前記１組の適用規則に基づいて実行される、請求項２４に記載の方法。
  26. 前記方法はさらに、ユーザプロシージャを登録するステップを含み、
    変更を適用する前記ステップは、前記ユーザプロシージャに基づいて実行される、請求項２４に記載の方法。
  27. 情報を共有するための方法であって、
    取得プロセスが、１つ以上の情報項目の第１の組をステージングエリアに追加するステップと、
    適用プロセスが、前記ステージングエリアから情報項目を自動的に読出し、前記情報項目を選択的に消費するステップと、
    明示的なデキュープロセスが、前記ステージングエリアに関連するＡＰＩに明示的な呼出を行なうことによって、前記ステージングエリアから情報項目を消費するステップとを含む、方法。
  28. システムにおいて行なわれた変更に応じるための方法であって、
    前記変更に変更時点を割当てるステップと、
    前記変更の記録を生成するステップとを含み、前記記録を生成する前記ステップは、前記変更が行なわれるときに対して非同期的に実行され、前記方法はさらに、
    前記変更の前記記録を読出すステップを含み、前記記録を読出す前記ステップは、前記記録が生成されるときに対して非同期的に実行され、前記方法はさらに、
    フラッシュバッククエリーを実行するステップを含み、前記フラッシュバッククエリーは、前記変更時点に基づくアクセス時点で前記システムからのデータを処理し、前記方法はさらに、
    前記フラッシュバッククエリーの結果に基づいて、前記変更に応じて実行するアクションを決定するステップを含む、方法。
  29. 前記システムはデータベースシステムであり、
    記録を生成する前記ステップは、前記データベースシステムによって生成されるログファイルから読出される情報に基づいて実行される、請求項２８に記載の方法。
  30. 前記記録を生成する前記ステップは、前記記録を前記ステージングエリアに記憶させる取得プロセスによって実行され、
    前記記録を読出す前記ステップは、前記ステージングエリアに記憶された記録を消費する消費プロセスによって実行される、請求項２８に記載の方法。
  31. 項目の順序の１回のみの取扱いを達成するための方法であって、
    宛先サイトに他のサイトから到着する、項目の前記順序における各項目について、
    前記項目に関連する順序番号を読出すステップと、
    １組の条件が満たされているかどうかに基づいて、前記項目が既に処理されているかどうかを判断するステップとを実行し、前記１組の条件は、前記項目に関連する前記順序番号と永続的に記憶されたウォータマーク値との比較を必要とする条件を含んでおり、さらに、
    前記１組の条件が満たされている場合に限り前記項目を処理するステップを実行するステップと、
    前記項目が前記宛先サイトで処理されるにつれて、前記項目に関連する前記順序番号に基づいて、どの項目が処理されたかを示すために前記永続的に記憶されたウォータマーク値を繰返し更新するステップと、
    前記宛先サイトから前記他のサイトにメッセージを定期的に送信するステップとを含み、前記メッセージは、前記宛先サイトでどの項目が処理されたかを示す、方法。
  32. 前記項目はトランザクションの断片に対応しており、
    前記ウォータマーク値は、その変更が前記宛先サイトで完全に適用されたトランザクションのコミット時点を示している、請求項３１に記載の方法。
  33. 前記ウォータマーク値は、その変更が適用エンジンによって最も直前に適用されたトランザクションのコミット時点を示している、請求項３２に記載の方法。
  34. 前記ウォータマーク値はコミット時点を示しており、前記ウォータマーク値の、またはそれを下回るコミット時点を有するトランザクションはすべて、適用エンジンによって適用されたと保証される、請求項３２に記載の方法。
  35. 永続的に記憶されたウォータマーク値を繰返し更新する前記ステップは、前記宛先サイトで十分に適用されるべき最も直前のトランザクションのコミット時点を反映するよう、前記永続的に記憶されたウォータマーク値を繰返し更新するステップを含む、請求項３２に記載の方法。
  36. 前記項目はトランザクションの断片に対応しており、
    メッセージを定期的に送信する前記ステップは、その変更が前記宛先サイトで完全には適用されていないトランザクションの最も古い変更時点を示すメッセージを定期的に送信するステップを含む、請求項３１に記載の方法。
  37. 前記宛先サイトでまだ十分に適用されていない最も古いトランザクションの最も古い変更時点を反映するために、永続的に記憶されたOLDEST CSN値を繰返し更新するステップをさらに含む、請求項３６に記載の方法。
  38. 前記宛先サイトでの障害に応じて、前記永続的に記憶されたOLDEST CSN値を読出し、前記永続的に記憶されたOLDEST CSN値に基づいて、前記宛先サイトに再送されるべき項目を要求するステップをさらに含む、請求項３７に記載の方法。
  39. 前記宛先サイトでの障害に応じて、前記永続的に記憶されたウォータマーク値を読出し、前記永続的に記憶されたウォータマーク値に基づいて、前記宛先サイトに再送されるべき項目を要求するステップをさらに含む、請求項３１に記載の方法。
  40. 前記他のサイトはソースサイトであり、
    前記方法はさらに、
    前記ソースサイトが、前記メッセージにおいて受取られた情報を永続的なストレージに定期的に記憶するステップと、
    前記ソースサイトでの障害の後、前記ソースサイトが、永続的なストレージから前記情報を読出すステップ、および、前記情報に基づいて前記宛先サイトに項目を再送するステップを実行するステップとを含む、請求項３１に記載の方法。
  41. 前記他のサイトは、前記項目を第３のサイトから受取る中間サイトであり、
    前記方法はさらに、
    前記中間サイトが、前記メッセージにおいて受取られた情報を永続的なストレージに定
    期的に記憶するステップと、
    前記中間サイトでの障害の後、前記中間サイトが、永続的なストレージから前記情報を読出すステップ、および、前記情報に基づいて前記中間サイトに項目を再送するよう前記第３のサイトに要求するステップを実行するステップとを含む、請求項３１に記載の方法。
  42. 前記中間サイトは前記情報を前記第３のサイトに定期的に送信する、請求項４１に記載の方法。
  43. 前記項目は、第１のトランザクションの断片と第２のトランザクションの断片とを含み、前記第１のトランザクションは前記第２のトランザクションの前にコミットされており、
    前記永続的に記憶されたウォータマーク値を繰返し更新する前記ステップは、
    前記宛先サイトが前記第１のトランザクションの適用を終了する前に、前記宛先サイトが前記第２のトランザクションの適用を終了している場合には、前記宛先サイトは、前記永続的に記憶されたウォータマークを変更することなく、前記第２のトランザクションが十分に適用されていることを示す情報を永続的に記憶するステップと、
    前記宛先サイトが前記第２のトランザクションの適用を終了する前に、前記宛先サイトが前記第１のトランザクションの適用を終了しており、かつ、前記第１のトランザクションを下回るコミット時点を有するトランザクションがすべて、十分に適用されている場合には、前記第１のトランザクションに関連する順序番号に基づいて前記永続的に記憶されたウォータマークを更新するステップとを含む、請求項３１に記載の方法。
  44. 前記項目は、第１のデータベースにおいて実行されたトランザクションによって行なわれた変更を識別し、
    前記宛先サイトは、前記第１のデータベースとは異なる第２のデータベースに前記変更を反映させることによって、前記項目を処理する、請求項３１に記載の方法。
  45. 前記変更を反映させる前記ステップは、
    前記第１のデータベースにおいて実行されたある特定のトランザクションに関連する前記変更に基づいて、１つ以上のデータベースコマンドの組を構築するステップと、
    １つ以上のデータベースコマンドの前記組を、前記第２のデータベースにおけるトランザクションとして実行するステップとを含む、請求項４４に記載の方法。
  46. データベースオブジェクトに関連するＤＤＬ動作に応じるための方法であって、
    データベースオブジェクトに関連するＤＤＬステートメントの実行に応じて、前記ＤＤＬステートメントによって行なわれた変更を示す記録を生成するステップと、
    前記記録に基づいて、前記ＤＤＬの実行に対して非同期的なアクションを実行するステップとを含む、方法。
  47. 前記記録は従属性情報を含んでおり、
    前記方法はさらに、
    他のどのアクションが前記アクションに従属するかを判断するために前記従属性情報を使用するステップと、
    前記アクションに従属していない他のアクションと並行して前記アクションを実行するステップとを含む、請求項４６に記載の方法。
  48. アクションを実行する前記ステップは、対応する変更が行なわれるようにするステップを含み、
    前記対応する変更は、前記データベースオブジェクトの複製に対して行なわれる、請求
    項４６に記載の方法。
  49. 対応する変更が行なわれるようにする前記ステップは、前記データベースオブジェクトの複製に関与するどのデータベースもクェーシングすることなく実行される、請求項４８に記載の方法。
  50. 対応する変更が行なわれるようにする前記ステップは、前記データベースオブジェクトの複製に関与するどのデータベースにおいてもユーザ活動を制約することなく実行される、請求項４８に記載の方法。
  51. 前記ＤＤＬステートメントの前記実行は、前記データベースオブジェクトの作成をもたらし、前記対応する変更は前記複製の作成をもたらす、請求項４８に記載の方法。
  52. 前記ＤＤＬステートメントの実行は、前記データベースオブジェクトがどのように構成されるかを変更し、前記対応する変更は、前記複製の構成において変更をもたらす、請求項４８に記載の方法。
  53. 記録を生成する前記ステップは、再実行ログに情報を記憶するステップを含む、請求項４８に記載の方法。
  54. 対応する変更が行なわれるようにする前記ステップは、
    前記再実行ログから前記情報を読出すステップと、
    前記再実行ログからの前記情報に基づいて、前記データベースオブジェクトがどのように変更されたかを示す変更データを生成するステップと、
    前記変更データを前記複製に適用するステップとを含む、請求項５３に記載の方法。
  55. 前記変更データを生成する前記ステップは、前記ＤＤＬステートメントの実行に対して非同期的に実行される、請求項５４に記載の方法。
  56. 前記再実行ログは、前記データベースオブジェクト内のデータに行なわれた変更を識別する情報を含んでおり、
    前記方法はさらに、前記再実行ログからの情報に基づいて、前記複製に含まれるデータを変更するステップを含む、請求項５３に記載の方法。
  57. 前記変更データを前記複製に適用するステップの前に、前記変更データをステージングエリアに記憶するステップをさらに含む、請求項５４に記載の方法。
  58. 前記ステージングエリアから前記変更データを読出し、前記複製が位置するサイトに前記変更データを伝播するステップをさらに含む、請求項５７に記載の方法。
  59. 変更データを生成する前記ステップは、ユーザによって登録された規則セットに基づいて、取得エンジンにより実行される、請求項５４に記載の方法。
  60. 前記変更データを伝播する前記ステップは、ユーザによって登録された規則セットに基づいて、伝播エンジンにより実行される、請求項５８に記載の方法。
  61. 前記変更データを適用する前記ステップは、ユーザによって登録された規則セットに基づいて、適用エンジンにより実行される、請求項５４に記載の方法。
  62. 前記データベースオブジェクトは、データベースシステムの新規ユーザを確立するユー
    ザオブジェクトであり、
    前記ＤＤＬステートメントの実行は、前記ユーザオブジェクトを作成し、
    対応する変更が行なわれるようにする前記ステップは、前記新規ユーザを前記他のデータベースシステムの新規ユーザとなるように確立するために、別のデータベースシステムに複製ユーザオブジェクトを作成するステップを含む、請求項４８に記載の方法。
  63. 前記データベースオブジェクトは、データベースシステムのための１つ以上の許可の組であり、
    前記ＤＤＬステートメントの実行は、前記１つ以上の許可を作成し、
    対応する変更が行なわれるようにする前記ステップは、別のデータベースシステムに前記１つ以上の許可の複製を作成するステップを含む、請求項４８に記載の方法。
  64. 前記ＤＤＬステートメントは第１のデータベースにおいて実行され、
    前記複製は第２のデータベースに存在し、
    前記方法はさらに、
    前記複製に関連する第２のＤＤＬステートメントの実行に応じて、前記第２のＤＤＬステートメントによって行なわれた変更を示す第２の記録を生成するステップと、
    前記記録に基づいて、第２の対応する変更が行なわれるようにするステップとを含み、前記第２の対応する変更は、前記第１のデータベースにおける前記データベースオブジェクトに対して行なわれる、請求項４８に記載の方法。
  65. 前記データベースオブジェクトは、ビュー、トリガ、プロシージャ、インデックス、順序、同義語、ロールバックセグメント、アウトライン、データベースリンク、具体化されたビュー、および具体化されたビューログからなる組から選択される一種類のデータベースオブジェクトであり、
    前記ＤＤＬステートメントの実行は、前記選択された種類のデータベースオブジェクトを作成し、
    対応する変更が行なわれるようにする前記ステップは、前記種類のデータベースオブジェクトの複製を別のデータベースシステムに作成するステップを含む、請求項４８に記載の方法。
  66. 前記ＤＤＬステートメントは第１のデータベースシステムにおいて実行され、
    アクションを実行する前記ステップは、前記第１のデータベースシステムとは異なる第２のデータベースシステムにメッセージを送信するステップを含む、請求項４６に記載の方法。
  67. １つ以上のプロセッサによって実行される際、請求項１〜６６のいずれかに記載された方法をプロセッサに実行させる命令を記憶している、コンピュータ読み取り可能な媒体。
JP2005506083A 2002-08-01 2003-07-29 非同期情報共有システム Expired - Lifetime JP4384633B2 (ja)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US40053202P 2002-08-01 2002-08-01
US41088302P 2002-09-13 2002-09-13
US10/308,851 US7031974B1 (en) 2002-08-01 2002-12-02 Replicating DDL changes using streams
US10/308,879 US8374966B1 (en) 2002-08-01 2002-12-02 In memory streaming with disk backup and recovery of messages captured from a database redo stream
US10/308,924 US6889231B1 (en) 2002-08-01 2002-12-02 Asynchronous information sharing system
PCT/US2003/023747 WO2004013725A2 (en) 2002-08-01 2003-07-29 Asynchronous information sharing system

Publications (2)

Publication Number Publication Date
JP2006501585A true JP2006501585A (ja) 2006-01-12
JP4384633B2 JP4384633B2 (ja) 2009-12-16

Family

ID=31499648

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2005506083A Expired - Lifetime JP4384633B2 (ja) 2002-08-01 2003-07-29 非同期情報共有システム

Country Status (6)

Country Link
US (1) US7103612B2 (ja)
EP (1) EP1543442B1 (ja)
JP (1) JP4384633B2 (ja)
AU (1) AU2003252183B2 (ja)
CA (2) CA2495469C (ja)
WO (1) WO2004013725A2 (ja)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005284395A (ja) * 2004-03-26 2005-10-13 Sharp Corp 通信機器、通信システムの情報同期方法、通信機器の制御プログラム、記録媒体
JP2005309968A (ja) * 2004-04-23 2005-11-04 Kyosan Electric Mfg Co Ltd 最新情報表示システム及びそれを使用した列車運行状況表示システム
JP2010510590A (ja) * 2006-11-17 2010-04-02 マイクロソフト コーポレーション ソフトウェアトランザクションのコミット順序および競合の管理
US8010550B2 (en) 2006-11-17 2011-08-30 Microsoft Corporation Parallelizing sequential frameworks using transactions
US8024714B2 (en) 2006-11-17 2011-09-20 Microsoft Corporation Parallelizing sequential frameworks using transactions
JP4855538B2 (ja) * 2008-06-04 2012-01-18 株式会社アテナテレコムラボ データベースのデータ項目の平行編集方式
JP4855537B2 (ja) * 2008-06-04 2012-01-18 株式会社アテナテレコムラボ データベース並行編集方式

Families Citing this family (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7152076B2 (en) * 2003-01-23 2006-12-19 Microsoft Corporation System and method for efficient multi-master replication
CA2472887A1 (en) * 2003-06-30 2004-12-30 Gravic, Inc. Methods for ensuring referential integrity in multithreaded replication engines
US7873684B2 (en) * 2003-08-14 2011-01-18 Oracle International Corporation Automatic and dynamic provisioning of databases
US8311974B2 (en) 2004-02-20 2012-11-13 Oracle International Corporation Modularized extraction, transformation, and loading for a database
US8554806B2 (en) * 2004-05-14 2013-10-08 Oracle International Corporation Cross platform transportable tablespaces
US7571173B2 (en) * 2004-05-14 2009-08-04 Oracle International Corporation Cross-platform transportable database
US8949395B2 (en) 2004-06-01 2015-02-03 Inmage Systems, Inc. Systems and methods of event driven recovery management
US7430558B2 (en) * 2005-01-31 2008-09-30 International Business Machines Corporation Transfer of table instances between databases
US7610314B2 (en) * 2005-10-07 2009-10-27 Oracle International Corporation Online tablespace recovery for export
CA2626227C (en) * 2005-10-28 2016-07-05 Goldengate Software, Inc. Apparatus and method for creating a real time database replica
CN100405422C (zh) * 2005-12-31 2008-07-23 华工科技产业股份有限公司 一种双卡防伪标识及其制作方法
US8838528B2 (en) * 2006-05-22 2014-09-16 Inmage Systems, Inc. Coalescing and capturing data between events prior to and after a temporal window
US8909599B2 (en) * 2006-11-16 2014-12-09 Oracle International Corporation Efficient migration of binary XML across databases
US7627595B2 (en) * 2006-12-06 2009-12-01 Verizon Data Services Inc. Apparatus, method, and computer program product for synchronizing data sources
US9058571B2 (en) * 2007-08-31 2015-06-16 Red Hat, Inc. Tool for automated transformation of a business process definition into a web application package
US8423955B2 (en) * 2007-08-31 2013-04-16 Red Hat, Inc. Method and apparatus for supporting multiple business process languages in BPM
US8825713B2 (en) * 2007-09-12 2014-09-02 Red Hat, Inc. BPM system portable across databases
US8914804B2 (en) 2007-09-12 2014-12-16 Red Hat, Inc. Handling queues associated with web services of business processes
US8954952B2 (en) * 2007-11-30 2015-02-10 Red Hat, Inc. Portable business process deployment model across different application servers
EP2157518A1 (en) * 2008-08-19 2010-02-24 Tieto Oyj Method for delivering data
US11176111B2 (en) * 2013-03-15 2021-11-16 Nuodb, Inc. Distributed database management system with dynamically split B-tree indexes
US9128965B1 (en) * 2013-08-07 2015-09-08 Amazon Technologies, Inc. Configurable-capacity time-series tables
US20150149259A1 (en) * 2013-11-26 2015-05-28 Chang Bin Song Enterprise performance management planning model for an enterprise database
US9922300B2 (en) * 2013-11-26 2018-03-20 Sap Se Enterprise performance management planning operations at an enterprise database
US10546149B2 (en) 2013-12-10 2020-01-28 Early Warning Services, Llc System and method of filtering consumer data
US10769296B2 (en) 2013-12-10 2020-09-08 Early Warning Services, Llc System and method of permission-based data sharing
US9558078B2 (en) 2014-10-28 2017-01-31 Microsoft Technology Licensing, Llc Point in time database restore from storage snapshots
US11113320B2 (en) * 2014-12-19 2021-09-07 Here Global B.V. Versioned change propagation
US20170255663A1 (en) * 2016-03-07 2017-09-07 Researchgate Gmbh Propagation of data changes in a distributed system
CN106326376A (zh) * 2016-08-15 2017-01-11 东软集团股份有限公司 用于表结构变更后的信息复制方法和装置
US11347713B2 (en) * 2019-09-27 2022-05-31 Salesforce.Com, Inc. Version-based table locking

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4007450A (en) * 1975-06-30 1977-02-08 International Business Machines Corporation Data sharing computer network
JP3386823B2 (ja) * 1991-03-28 2003-03-17 株式会社日立製作所 ファイルの管理方法及び装置
US5613134A (en) * 1993-09-17 1997-03-18 Digital Equipment Corporation Document display system using documents having ephemeral attributes for sharing information regarding the location of the display of each document on multiple display devices
US5473696A (en) * 1993-11-05 1995-12-05 At&T Corp. Method and apparatus for combined encryption and scrambling of information on a shared medium network
US5742848A (en) * 1993-11-16 1998-04-21 Microsoft Corp. System for passing messages between source object and target object utilizing generic code in source object to invoke any member function of target object by executing the same instructions
US5680619A (en) * 1995-04-03 1997-10-21 Mfactory, Inc. Hierarchical encapsulation of instantiated objects in a multimedia authoring system
US6163813A (en) * 1995-06-07 2000-12-19 International Business Machines Corporation Pattern for instantiating objects of unknown type in object-oriented applications
US5948062A (en) * 1995-10-27 1999-09-07 Emc Corporation Network file server using a cached disk array storing a network file directory including file locking information and data mover computers each having file system software for shared read-write file access
US5758083A (en) * 1995-10-30 1998-05-26 Sun Microsystems, Inc. Method and system for sharing information between network managers
US5715413A (en) * 1996-06-25 1998-02-03 International Business Machines Corporation Dragging and dropping with an instantiation object
US6553428B1 (en) * 1996-11-18 2003-04-22 International Business Machines Corporation Distributed object instantiation of native objects in java
US6222840B1 (en) 1996-12-30 2001-04-24 Compaq Computer Corporation Method and system for performing concurrent read and write cycles in network switch
JP3319341B2 (ja) * 1997-06-20 2002-08-26 日本電気株式会社 データ共有システム
US6577634B1 (en) * 1998-07-01 2003-06-10 Hitachi, Ltd. Method for sharing network information and a router apparatus
US6405209B2 (en) * 1998-10-28 2002-06-11 Ncr Corporation Transparent object instantiation/initialization from a relational store
US6442568B1 (en) * 1998-12-11 2002-08-27 Compaq Computer Corporation Customer information control system application programming interface with transient data functions, in a loosely coupled data processing environment
US6453354B1 (en) * 1999-03-03 2002-09-17 Emc Corporation File server system using connection-oriented protocol and sharing data sets among data movers
EP1342170A4 (en) * 1999-11-29 2006-01-25 Interwoven Inc METHOD AND DEVICE TO MOVE DATA BETWEEN DATA FOR WEBSITE DEVELOPMENT AND MAINTENANCE
US20010047270A1 (en) * 2000-02-16 2001-11-29 Gusick David L. Customer service system and method
US20030182328A1 (en) * 2001-10-29 2003-09-25 Jules Paquette Apparatus and method for sharing data between multiple, remote sites of a data network
US7284032B2 (en) * 2001-12-19 2007-10-16 Thomson Licensing Method and system for sharing information with users in a network
US20030236823A1 (en) * 2002-06-19 2003-12-25 Robert Patzer Information sharing groups, server and client group applications, and methods therefor
US6691155B2 (en) * 2002-06-20 2004-02-10 Linda Gottfried Multimedia system for sharing brand information keeps history of modifications of production information by consumers to allow recreating multimedia interface in its previous formats

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005284395A (ja) * 2004-03-26 2005-10-13 Sharp Corp 通信機器、通信システムの情報同期方法、通信機器の制御プログラム、記録媒体
JP4481053B2 (ja) * 2004-03-26 2010-06-16 シャープ株式会社 通信機器、通信機器の制御方法、通信機器の制御プログラム
JP2005309968A (ja) * 2004-04-23 2005-11-04 Kyosan Electric Mfg Co Ltd 最新情報表示システム及びそれを使用した列車運行状況表示システム
JP2010510590A (ja) * 2006-11-17 2010-04-02 マイクロソフト コーポレーション ソフトウェアトランザクションのコミット順序および競合の管理
JP4698757B2 (ja) * 2006-11-17 2011-06-08 マイクロソフト コーポレーション ソフトウェアトランザクションのコミット順序および競合の管理
US8010550B2 (en) 2006-11-17 2011-08-30 Microsoft Corporation Parallelizing sequential frameworks using transactions
US8024714B2 (en) 2006-11-17 2011-09-20 Microsoft Corporation Parallelizing sequential frameworks using transactions
US8402447B2 (en) 2006-11-17 2013-03-19 Microsoft Corporation Parallelizing sequential frameworks using transactions
JP4855538B2 (ja) * 2008-06-04 2012-01-18 株式会社アテナテレコムラボ データベースのデータ項目の平行編集方式
JP4855537B2 (ja) * 2008-06-04 2012-01-18 株式会社アテナテレコムラボ データベース並行編集方式

Also Published As

Publication number Publication date
US20040034669A1 (en) 2004-02-19
CA2665951C (en) 2013-02-12
CA2495469C (en) 2012-07-10
AU2003252183B2 (en) 2008-08-28
US7103612B2 (en) 2006-09-05
EP1543442A4 (en) 2007-07-25
CA2495469A1 (en) 2004-02-12
WO2004013725A3 (en) 2004-07-15
EP1543442A2 (en) 2005-06-22
WO2004013725A2 (en) 2004-02-12
JP4384633B2 (ja) 2009-12-16
AU2003252183A1 (en) 2004-02-23
EP1543442B1 (en) 2020-01-22
CA2665951A1 (en) 2004-02-12

Similar Documents

Publication Publication Date Title
JP4384633B2 (ja) 非同期情報共有システム
US7031974B1 (en) Replicating DDL changes using streams
US8374966B1 (en) In memory streaming with disk backup and recovery of messages captured from a database redo stream
CN111417938B (zh) 针对客户端同步服务更新本地树
US7702741B2 (en) Configuring or reconfiguring a multi-master information sharing environment
US7680793B2 (en) Commit-time ordered message queue supporting arbitrary read and dequeue patterns from multiple subscribers
JP4856541B2 (ja) データベースの自動的および動的な提供
US8799213B2 (en) Combining capture and apply in a distributed information sharing system
US9009104B2 (en) Checkpoint-free in log mining for distributed information sharing
US20020165724A1 (en) Method and system for propagating data changes through data objects
US7613741B2 (en) Utilizing rules in a distributed information sharing system
US7565379B2 (en) Preventing change cycling using rules and redo tags in a redo log
US7899785B2 (en) Reconfiguring propagation streams in distributed information sharing
US7185005B1 (en) Nested transactions in a file system
US8005802B2 (en) Partial evaluation of rule sets
CN100550009C (zh) 异步信息共享系统
Masud et al. Transaction processing in a peer to peer database network
US9734185B2 (en) Mechanism for communication in a distributed database
Doraiswamy et al. Reweaving the tapestry: Integrating database and messaging systems in the wake of new middleware technologies
CN115170091A (zh) 一种业务待办已办系统及发送方法
Ashdown et al. Oracle Database XStream Guide, 11g Release 2 (11.2) E16545-07
Ashdown et al. Oracle Database XStream Guide, 11g Release 2 (11.2) E16545-09
Schelfaut Distributed systems (H04I4A)-summary (version 1)
Ashdown et al. Oracle Database XStream Guide, 11g Release 2 (11.2) E16545-04

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20060516

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090414

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20090714

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20090722

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090813

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20090908

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20090925

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20121002

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4384633

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20131002

Year of fee payment: 4

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

EXPY Cancellation because of completion of term