(57)【要約】変更データの捕捉のための方法およびソフトウェアが説明され、変更データは単一のパスで修復ログから抽出され、変更テーブルなどの複数のデータベースオブジェクトに記憶される。変更データは複数のデータベースオブジェクトに対応する複数のソースオブジェクトで行なわれた修正を示す。好ましい実施例では、これは単一のマルチテーブル挿入ＳＱＬステートメントを用いて実現可能である。
2005527912.tif 000002
【特許請求の範囲】
【請求項１】
変更データの捕捉のための方法であって、
単一のパスで修復ログから変更データを抽出するステップと、
単一のパスで前記修復ログから抽出された前記変更データを複数のデータベースオブジェクトに記憶するステップとを含み、前記変更データは前記データベースオブジェクトに対応する複数のソースオブジェクトに対して行なわれた修正を示す、方法。
【請求項２】
前記データベースオブジェクトはそれぞれの変更テーブルを含み、前記変更テーブルの各々は対応する前記ソースオブジェクトで行なわれた修正を記憶する、請求項１に記載の方法。
【請求項３】
前記修正は、前記ソースオブジェクト間の第１のソースオブジェクト内の第１の列に対する第１の更新および前記ソースオブジェクト間の第２のソースオブジェクト内の第２の列に対する第２の更新を含み、
前記第１の列および前記第２の列は同じ名前を有する、請求項１に記載の方法。
【請求項４】
単一のパスで前記修復ログから前記変更データを抽出しかつ前記データベースオブジェクト内で前記変更データを記憶するために単一のデータベースステートメントを生成するステップと、
抽出および記憶の前記ステップを行なうために前記単一のデータベースステートメントを実行するステップとをさらに含む、請求項１に記載の方法。
【請求項５】
前記単一のデータベースステートメントは、マルチテーブル挿入ステートメントである、請求項４に記載の方法。
【請求項６】
変更データの捕捉のための命令を運ぶコンピュータ読取可能な媒体であって、前記命令は、実行されるときに１つまたは複数のプロセッサに請求項１に記載の方法のステップを行なわせるように格納される、コンピュータ読取可能な媒体。
【請求項７】
変更データの捕捉の方法であって、
単一のパスで修復ログから前記変更データを抽出するためにＳＱＬの単一のマルチテーブル挿入ステートメントを生成するステップと、
前記ＳＱＬステートメントを実行して、それによって単一のパスで前記修復ログから前記変更データを抽出しかつ前記修復ログからの前記変更データを複数の変更テーブルに記憶するステップとを含み、前記変更テーブルは複数の対応するソースオブジェクトに行なわれた少なくとも１つの修正を示す、方法。
【請求項８】
変更データの捕捉のための命令を運ぶコンピュータ読取可能な媒体であって、前記命令は、実行されるときに１つまたは複数のプロセッサに請求項１から７に記載の方法のステップを行なわせるように格納される、コンピュータ読取可能な媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
発明の分野
この発明はデータベースシステムに関し、特にデータウェアハウジングのための高性能の変更捕捉に関する。
【背景技術】
【０００２】
発明の背景
多くの企業およびその他の大きな組織では、今日、オンライントランザクション処理（ＯＬＴＰ）システムとして知られるリレーショナルデータベース管理システムを使用してビジネストランザクションを実行、記録している。たとえば、インターネット上で製品またはサービスを販売する企業は、ＯＬＴＰシステムを使用して、販売するための各製品についての価格情報、各購入者についての課金および出荷情報、ならびに購入者によって行なわれた各注文についての販売情報を記録することができる。ＯＬＴＰシステムを使用する企業の他の例は、航空会社、銀行、通信販売会社、スーパーマーケットおよび製造業者を含む。
【０００３】
ＯＬＴＰシステムで生成、記録されるデータは、大部分の企業にとって貴重である。なぜなら、企業はそのデータを集約、分析して、ある特定の月についての製品売上を把握し、製品の人気での変化する傾向を予測し、利益性のあるまたは利益性のない製品ラインを識別することができ、または他の形で企業の業務を評価することができるからである。しかしながら、このデータの集約および分析は、計算に負担がかかり、ＯＬＴＰシステム自身で行なわれると、ＯＬＴＰシステムの性能を低下させる。したがって、ＯＬＴＰシステムを用いる企業では、ＯＬＴＰデータベースに含まれる情報を収集、集約および分析するために「データウェアハウス」として一般に知られる別のコンピュータシステムを構築することが一般的となっている。データウェアハウスは、数ギガバイトから何テラバイトのデータ（数兆バイト）まで非常に大きくすることができる。ＯＬＴＰシステム内の元々のソースからデータウェアハウスにデータを移動する作業は、一般的に、データの抽出、移送およびロード（ＥＴＬ）と称される。
【０００４】
従来のデータ抽出、移送およびロードの機構は煩わしい。典型的な方法では、データベース管理者が一般にＯＬＴＰシステム内のテーブルの内容全体をフラットファイルに放出し、フラットファイルをステージングシステムに移送し、フラットファイル内のデータをデータウェアハウスにロードする。この方法では、たとえＯＬＴＰシステム上のデータの小さな割合のみが実際には新しいものであるとしても、抽出、移送およびロードされるデータの量はＯＬＴＰシステム内のデータの量と同じくらい莫大である。したがって、ＯＬＴＰシステムのデータベーステーブルに変更されたデータのみを捕捉することによって、抽出、移送およびロードされるデータの量を低減するための工夫された方法に大きな関心が寄せられている。
【０００５】
最近では、ＯＬＴＰシステムからデータウェアハウスにデータを抽出、移送およびロードするための非同期式の変更捕捉方法に関心が寄せられている。１つの非同期式の方法では、挿入、更新および削除された記録の形の変更データは、通常の動作でＯＬＴＰシステムによって生成される修復ログで捕捉される。これら修復ログはデータウェアハウスに送られ、そこで修復ログに記憶される変更データは、ＯＬＴＰシステムの性能に影響することなく、データウェアハウス上の変更テーブルへと抽出することができる。各変更テーブルは、ＯＬＴＰシステム上のソーステーブルに対応し、対応するソーステーブル内のどのレコードが更新されたかを識別することによって、履歴業務データを追跡しかつシステム
の履歴を提供するために使用することができる。
【０００６】
しかしながら、データウェアハウス側での高性能のデータの抽出、移送およびロードが依然として必要とされている。たとえば、非同期式の変更捕捉の一実現例では、修復ログから１２の異なる変更テーブルに変更を抽出するのに約８時間１１分必要だった。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
発明の概要
この発明は、非同期式の変更捕捉での遅延の主要な原因は、データが修復ログから抽出される度に起こるという認識に由来している。ある実現例では、各個々の変更テーブルに対して修復ログ内の変更データを抽出するために、別々のStructured Query Language（ＳＱＬ）ステートメント、すなわち、変更テーブルにつき１つのＳＱＬステートメントが使用され、各変更テーブルはＯＬＴＰシステム上のソーステーブルに対応するため、数十の変更テーブルがあり得る。したがって、とりわけ、高性能の必要性は、ディスク上で単一のパスで修復ログから変更データを抽出するが抽出された変更データを複数のテーブルに記憶することで、この発明によって対処される。この方法によって、１２の変更テーブルのために修復ログから変更データを処理するための時間は、約８時間１１分から４５分に低減される。
【課題を解決するための手段】
【０００８】
したがって、この発明の一局面は、変更データの捕捉のためのソフトウェアおよび方法に関し、変更データは単一のパスで修復ログから抽出され、変更テーブルなどの複数のデータベースオブジェクトに記憶される。変更データは、複数のデータベースオブジェクトに対応する複数のソースオブジェクトに行なわれた修正を示す。好ましい実施例では、これは単一のマルチテーブル挿入ＳＱＬステートメントを用いて実現することができる。
【０００９】
この発明の他の局面、特徴および利点は、この発明を実行するために企図される最良の形態を含む特定の実施例および実現例を示すことによって以下の詳細な説明から容易に明らかとなる。この発明は他の異なる実施例も可能であり、そのいくつかの詳細は、この発明の精神および範囲を離れることなく、さまざまな明らかな点において変形可能である。したがって、図面および説明は、本質的に例示的なものであって制限的なものではないとみなされるべきである。
【発明を実施するための最良の形態】
【００１０】
この発明は、同様の参照番号が同様の要素を示す添付の図面において、限定ではなく、例によって示される。
【００１１】
好ましい実施例の説明
高性能な変更の捕捉のためのシステム、方法およびソフトウェアが説明される。以下の説明では、説明のため、多くの具体的な詳細を示してこの発明を完全に理解できるようにしている。しかしながら、当業者には、この発明はこれらの具体的な詳細なしに、または同等の配置を用いて実現可能であることが明らかであろう。場合によっては、この発明を不必要にわかりにくくするのを避けるため、周知の構造および装置をブロック図の形で示す。
【００１２】
データベース管理システムでは、データは１つまたは複数のデータコンテナに記憶され、各コンテナはレコードを含み、各レコード内のデータは１つまたは複数のフィールドに組織される。リレーショナルデータベースシステムでは、データコンテナはテーブルと称され、レコードは行と称され、フィールドは列と称される。オブジェクト指向データベー
スでは、データコンテナはオブジェクトクラスと称され、レコードはオブジェクトと称され、フィールドは属性と称される。他のデータベースアーキテクチャは他の用語を使用することがある。
【００１３】
この発明を実現するシステムは、特定の種類のデータコンテナまたはデータベースアーキテクチャに限定されない。しかしながら、説明のため、ここで使用される用語および例は、典型的にはリレーショナルデータベースに関連付けられるものとなる。したがって、データコンテナ、レコードおよびフィールドをそれぞれ指すために「テーブル」、「行」および「列」という用語がここでは使用される。
【００１４】
アーキテクチャの概要
図１は、ソースシステム１１０およびステージングシステム１２０を含む、この発明の一実施例のアーキテクチャを示す。ソースシステム１１０は、典型的には企業のためにトランザクションを実行、記録するためのオンライントランザクション処理（ＯＬＴＰ）である。たとえば、ソースシステム１１０は、企業の従業員または顧客とやり取りするためのビジネスアプリケーション１１１をホストする。ビジネスアプリケーション１１１のユーザからのコマンドおよび照会に応答して、ビジネスアプリケーション１１１はＯＬＴＰデータベース１１３とやり取りしてデータを記憶、検索する。
【００１５】
この例ではデータウェアハウスとして機能して、ステージングシステム１２０が１つまたは複数の加入者アプリケーション１２１、１２３をホストする。一般性を失うことなく２つの加入者アプリケーション１２１、１２３が示されるが、この発明の実施例の動作中にいくつ作成されてもよい。加入者アプリケーション１２１、１２３は、ＯＬＴＰデータベース１１３から抽出され、ステージングシステム１２０に移送され、かつ分析データベース１２５にロードされた変更データを集約、分析するためのものである。フラットファイルを使用することなくＯＬＴＰデータベース１１３からデータを抽出するために、２つの機構のうちの１つを用いることが好ましい。これらの機構は、それぞれ「同期式抽出」および「非同期式抽出」と称される。
【００１６】
同期式抽出機構では、変更が行なわれるときにＯＬＴＰデータベース１１３に各変更を捕捉し、変更をステージングシステム１２０に移送するためにトリガ１１５が用いられる。ステージングシステム１２０では、これらの変更は、発行者プロセス１２７によって、分析データベース１２５の変更テーブル（図示せず）に統合、ロードされる。同期式抽出機構は、William D. Norcottによって２００１年５月２４日に出願された「データベースシステムにおける同期式変更データ捕捉（SYNCHRONOUS CHANGE DATA CAPTURE IN A DATABASE SYSTEM）」と題される、本発明の譲受人に譲渡された同時係属中の米国特許出願連続番号第０９／８６３，４２２号にさらに詳細に説明され、この内容をここに引用により援用する。
【００１７】
以下に詳細に説明される非同期式抽出機構では、通常の動作中にＯＬＴＰデータベース１１３によって作られる修復ログ１１７をログシッパー１１９が定期的にコピーする。修復ログ１１７は、ＯＬＴＰデータベース１１３に適用されたすべての変更を含み、ＯＴＰデータベース１１３内のデータをバックアップするためおよびシステムクラッシュの場合にデータを復旧するために使用される。ログシッパー１１９は、変更ソース１３１と呼ばれるステージングシステム１２０の或る領域に修復ログ１１７をコピーし、これはオペレーティングシステムのディレクトリとして実現可能である。発行者１２７は、修復ログの内部のインプリメンテーションの詳細を知る必要なく、変更ソース１２９内の送られた修復ログから変更データを獲得するためにログビューワプロセス１２９とやり取りする。発行者１２７は、加入者アプリケーション１２１、１２３によって使用するために、ログビューワプロセス１２９を介して獲得された変更データを分析データベース１２５内の変更
テーブルにロードする。加入者アプリケーション１２１、１２３と変更テーブルとのやり取りは、William D. Norcottらによって２００２年５月９日に出願された「変更データ捕捉のための方法および装置（METHOD AND APPARATUS FOR CHANGE DATA CAPTURE）」と題される、本発明の譲受人に譲渡された同時係属中の米国特許出願連続番号第１０／１４０，８１８号に説明され、この内容をここに引用により援用する。
【００１８】
変更データを管理するためのオブジェクト
この発明の一局面によると、ＯＬＴＰデータベース１１３から抽出された変更データは、フラットファイルではなく、データベース管理システム、たとえば、分析データベース１２３の制御下で、「変更テーブル」とここでは称される１つまたは複数のデータベースオブジェクトで維持される。データベース管理システムはセキュリティのためのクラッシュ復旧および性能に対するインデックスなどの特徴を提供するため、変更データを都合よくに保持するためにデータベースを使用することで、フラットファイルの使用と比較して付加的なプログラミングなく、これらの有利な特徴が得られる。
【００１９】
一例として図２を参照すると、変更データ捕捉の影響を受けるＯＬＴＰデータベース１１３上の各ソーステーブルまたはデータベースオブジェクトは、分析データベース１２３内の対応する変更テーブル２１１、２１３、２２１、２２３、２２５と関連付けられる。トランザクションの一貫性のため、変更テーブル２１１、２１３、２２１、２２３、２２５は、１つまたは複数の「変更セット」２１０、２２０のセットにグループ分けされ、発行者１２５は、確実に同じ変更セット内の変更テーブル（たとえば、変更セット２１０の変更テーブル２１１、２１３）に加えられたすべての新しい変更データが同時に加えられるように、たとえば、これら変更テーブルへの修正が同じトランザクションで行なわれコミットされるようにする。図２に示される例では、変更セット２１０および変更セット２２０の２つの変更セットがある。変更セット２１０は、ＯＬＴＰデータベース１１３上のそれぞれのテーブル（図示せず）に対応する変更テーブル２１１および変更テーブル２１３を含む。同様に、変更セット２２０は、これもＯＬＴＰデータベース１１３上のそれぞれのテーブル（図示せず）に対応する変更テーブル２２１、変更テーブル２２３および変更テーブル２２５を含む。変更セット２１０、２２０および変更テーブル２１１、２１３、２２１、２２３、２２５の構造を規定する情報は、システムメタデータ２３０に維持される。
【００２０】
各変更テーブルは、ＯＬＴＰデータベース１１３内の対応するソーステーブル列からその値が抽出、移送およびロードされたソーステーブル列に加え、いくつかの制御列を用いる。図２の例では、変更テーブル２２５は、ソーステーブル列２３１および制御列ＳＣＮ２３３、時間２３５、ＯＰ２３７および行２３９のセットを有するものとして示される。ソーステーブル列２３１は、対応するソーステーブル内の列のすべてまたはサブセットを含んでもよい。さまざまな実現例では、制御列は、ソーステーブル列または平行な関連付けられるデータオブジェクトの一部を含む同じデータベースオブジェクトの一部であってもよく、これはソーステーブル列と結合することができる（たとえば、行識別子または主キーによって）。
【００２１】
制御列ＳＣＮ２３３、時間２３５、ＯＰ２３７、および行２３９は、顧客が自分自身の列に使用することのできない予約された名前、たとえば、ドル記号（＄）などの予約された文字を用いた名前を有することが好ましい。当然のことながら、予約された名前は有効な文字列であればどのようなものであってもよく、この例では、記憶を助ける理由のためＳＣＮ２３３、時間２３５、ＯＰ２３７、および行２３９と名付けられる。
【００２２】
ＳＣＮ２３３列は、変更データを生じさせたＯＬＴＰデータベース１１３上のトランザクションに対するコミットのシステム変更番号を保持する。システム変更番号は、たとえ
ば、更新、挿入、削除およびコミットなどのデータベースシステム上で行なわれたすべての動作を識別する単調に増加する番号であり、データベースシステムで行なわれた動作を順序付けるために使用可能である。この発明は、システム変更番号の何らかの特定の実現例に限定されず、ここに説明される概念は、タイムスタンプ、増分連続番号等と共に有利に用いることができる。
【００２３】
時間２３５列は、変更データを生じさせたトランザクションのコミット時間を含む。この列は、加入者アプリケーション１２１がある特定の時間に起こる変更データを選択または閲覧する助けとなる。
【００２４】
ＯＰ２３７列は、変更データに繋がった動作の種類を示すコードを含む。たとえば、ＯＰ２３７列が記号「Ｉ」を含む場合、動作は挿入動作であり、ソーステーブル列２３１内の変更データは挿入されたデータを含む。ＯＰ２３７列が記号「Ｄ」を含む場合、動作は削除動作であり、ソーステーブル列２３１内の変更データは削除されたデータを含む（これによって、加入者アプリケーション１２１によって要約を適切に再調節することができる）。ＯＰ２３７列が記号「ＵＯ」を含む場合、動作は更新動作であり、ソーステーブル列２３１内の変更データは修正された古いデータを含み、同様に、ＯＰ２３７列が記号「ＵＮ」を含む場合、動作は更新動作であり、ソーステーブル列２３１内の変更データは修正された新しいデータを含む。したがって、ソーステーブルでの更新動作は、１つは古いデータのため、もう１つは新しいデータのための変更テーブルにおける２つのエントリに繋がり、加入者アプリケーション１２１はＯＬＴＰデータのそれらの要約を再調節するために十分な情報を有する。状況によっては、ソーステーブルは図形および絵などの「ラージオブジェクト」（ＬＯＢ）を含んでもよい。このＬＯＢは典型的には要約されないため、メモリを節約するために、（ＯＰ２３７列の記号「ＵＬ」と共に）新しいＬＯＢのみが変更テーブルに記録される。ＯＰ２３７列内のこれらの記号（「Ｉ」、「Ｄ」、「ＵＯ」、「ＵＮ」、「ＵＬ」）は、記憶を助けるために選ばれており、この発明の範囲を離れることなく、他の記号に任意で一意の値を割当ててもよい（たとえば、番号）。
【００２５】
行２３９列は、変更テーブル内の変更に対する一意の行連続番号を含む。この列は、加入者アプリケーション１２１が同じトランザクション内でコミットされた動作を順序付ける手助けをする。さらに、古い更新された値のためのレコード（「ＵＯ」を備えたＯＰ２３７列）および新しい更新された値のためのレコード（「ＵＮ」を備えたＯＰ２３７列）は共に同じ行連続番号を有することになる。なぜなら、これらの２つのレコードはＯＬＴＰデータベース１１３上での同じ変更動作（更新動作）に対するものであるからである。
【００２６】
図２には示されないが、この発明の実施例の実現を容易にするために、付加的な制御列を設けてもよい。たとえば、どの列が変更されたかを素早く識別するために、更新された列のビットマスクを使用可能である。別の例としては、動作を生じさせるユーザ名を制御列に記憶可能である。ソーステーブル内の対象の行の行識別子を制御列に含めることも可能である。
【００２７】
図１の加入者アプリケーション１２１、１２３は、しかしながら、変更テーブルのすべての内容を見る必要はない。具体的には、加入者アプリケーション１２１、１２３がそれぞれの加入者の眺めで見る行の範囲は、以下に詳しく説明されるように制限され、注意深く制御されるため、変更データは失われることがなく、加入者アプリケーション１２１、１２３に対して二重に数えられることもない。図２の例では、２つの加入者の眺め２４１、２４３が示されるが、この発明の実施例の動作中にいくつの加入者の眺めが作られてもよい。加入者の眺め２４１、２４３の使用によって、それぞれの加入者アプリケーション１２１、１２３を変更テーブル２２５のインプリメンテーションの詳細から分離することができ有利である。一部の先行技術の方法とは異なり、ＯＬＴＰデータベース１１３上の
ソーステーブル自身に制御列または情報を付加する必要はない。分析１２０上の変更テーブルに対して制御列を設けることで十分である。結果として、この特徴によって、ＯＬＴＰデータベース１１３のスキーマを変更することなく、変更データの捕捉を行なうことができ、これは多くのターンキー方式のＯＬＴＰデータベースにとって望ましい。
【００２８】
高性能な変更データの捕捉
図３を参照すると、ステップ３１０では、修復ログ１１７は、ソースシステム１１０から、オペレーティングシステムのディレクトリであり得る変更ソース１３１と呼ばれるステージングシステム１２０上の或る場所に送られる。「やり直しログ」としても知られる修復ログ１１７は、ユーザが（たとえば、トランザクションロールバックで）トランザクションを元に戻し、システムクラッシュの後に修復を行なうことができるように、通常の動作中にＯＬＴＰデータベースシステム１１３によって作られる。したがって、修復ログ１１７は、トランザクションがコミットされる前にトランザクションを中止するための取消し方法を提供し、修復ログ１１７はリレーショナルデータベース管理システムの標準的な特徴である。ログシッパー１１９を実現するための１つの方法は、Mahesh Girkarらによって２００１年５月１０日に出願された「有界のデータの損失を伴う災害復旧（DISASTER RECOVERY WITH BOUNDED DATA LOSS）」と題される、本発明の譲受人に譲渡された同時係属中の米国特許出願連続番号第０９／８５２，００８号に説明され、この内容をここに引用により援用する。
【００２９】
データベース管理システムの中には、監査および報告のためにユーザが修復ログ１１７からデータを抽出できるようにログビューワ１２９を備えるものがある。この目的で使用されるとき、修復ログ１１７は、以前にＯＬＴＰデータベース１１３に行なわれた変更の監査の軌跡を構成する。この発明の一実施例によると、変更ソース１３１内の送られた修復ログ１１７は、以前に使用されたように監査の目的だけではなく、変更データ捕捉のために、送られた修復ログ１１７から情報を抽出できるようにログビューワ１２９に登録される。ログビューワ１２９の使用によって、修復ログ１１７のインプリメンテーションの詳細を発行者１２７から都合よく封じ込め、隠し、隔離することができ、これによって、発行者１２７の設計およびメンテナンスが簡略化される。さらに、ログビューワ１２９によって、異なるデータベースメーカによって開発され、内部のデータ構造、ファイルフォーマットおよびアルゴリズムの互換性のない異なる実装を用いる外部データベースシステムによって作られた修復ログ１１７から発行者１２７がデータを抽出することが可能になる。
【００３０】
ログビューワ１２９は、修復ログ１１７内のデータにリレーショナルデータベースインターフェイスを提供するように構成されることが好ましく、こうすると発行者１２７は、ＳＱＬ選択ステートメントを実行することによって変更データを獲得できる。なお、リレーショナルデータベースのインターフェイスはVIEWERと呼ばれる修復ログ１１７上の関係する眺めを通じて仲介され、これは少なくとも、そこから変更データが抽出されるべきソーステーブルの名前を含むTABLE_VIEWED、および修復ログ１１７内のトランザクションの各々のシステム変更番号を含むＳＣＮの列を含む。システム変更番号は、ＯＬＴＰデータベース１１３上で行なわれた動作を一意に識別するために使用される単調増加番号である。さらに、ＳＱＬ関数、EXTRACT()は修復ログ１１７から特定の列からデータを抽出するために設けられる。EXTRACT()は、そのデータが戻されるべき列の名前を渡される。
【００３１】
ステップ３０５では、structured query language（ＳＱＬ）が生成され、ログビューワ１２９によって設けられたリレーショナルデータベースのインターフェイスを介して単一で修復ログ１１７から変更データを抽出し、かつ抽出された変更データを複数の変更テーブルに挿入する。複数の変更テーブルは変更セットの一部であってもよく、これはトランザクションに関して一貫して保たれるべき関連する変更テーブルの論理グループである
。したがって、変更テーブルを更新するためのトランザクションは、変更セット内のすべての変更テーブルに対して始められ、関連する変更テーブルへのすべての変更が同時に加入者アプリケーション１２１、１２３に見えるようにするためにこのプロセスの終わりにコミットされる。
【００３２】
一実現例では、生成されるＳＱＬステートメントは以下の形のマルチテーブル挿入ステートメントである。
【００３３】
【数１】
2005527912.tif 000003
【００３４】
ＳＱＬステートメントの構造によって示されるように、ステートメントはマルチテーブル挿入を特定し、リレーショナルインターフェイスを介して修復ログからのデータの抽出を特定する単一のSELECT節、および変更データが挿入される各変更テーブルに対する複数のWHEN...THEN節がある。この例は２つの変更テーブルを備えたマルチテーブル挿入の使用を示すが、この発明はそのように限定されず、このステートメントは、SELECT節の前に付加的なWHEN...THEN節を付加する、およびWHERE節のIN述部に付加的なオブジェクト識別子を付加する可算数の変更テーブルを含むように拡張され得る。
【００３５】
このＳＱＬステートメントでは、「/*+PARALLEL*/」は、データが複数の変更テーブルのすべてのデータ区画に同時に挿入されるようにするためのヒントであるが、この発明の性能上の利点の多くはこのヒントなしに実現可能である。さらに、「VIEWER」は、ログビューワ１２９がリレーショナルインターフェイスとして発行者に提示する関係する眺めの名前であり、「ＳＣＮ」は変更データに繋がるトランザクションを識別する列である。イタリック体で設定されるＳＱＬステートメントの残りのスロットは、以下の作業例に関して説明される。
【００３６】
obj_id1およびobj_id2のスロットは、ＳＱＬステートメントによって供される２つの変更テーブルに対応するオブジェクト名を保持し、修復ログ１１７に示される。ct1およびct2のスロットは、２つのそれぞれの変更テーブルのスキーマ名を保持する。
【００３７】
WHEN...THEN節内のスロット「control_columns」は、各変更テーブルに挿入されるべき制御列、たとえば、ＳＣＮ２３３、時間２３５、ＯＰ２３７および行２３９などのリストである。「change_columns1」と示されるスロットは、第１のソーステーブル内の列、たとえば、ソーステーブル列２３１に対応する変更テーブルct1内の見える列の名前のリストであり、「aliased_columns1」のスロットは、変更テーブルct1の明確にされた列の名前を保持する。同様に、「change_columns2」と示されるスロットは、第２のソーステーブル内の列に対応する変更テーブルct2内の見える列の名前のリストであり、「aliased_columns2」スロットは、変更テーブルct2の明確にされた列の名前を保持する。「aliased_
columns1」および「aliased_columns2」のスロットの目的は、変更テーブルct1およびct2が同じ名前を備えた列を有する場合を処理するためである。
【００３８】
SELECT節内の「control_defs」のスロットは、各変更テーブルに挿入されるべき制御列、たとえば、ＳＣＮ２３３、時間２３５、ＯＰ２３７および行２３９に対する値の定義のリストである。これら列の値は修復ログ１１７から獲得され、ログビューワ１２９によって関係する形で列として提示される。「aliased_defs」のスロットは、ＳＱＬステートメントによって供されるすべての変更テーブルの見える列の定義のリストである。一実現例では、これら列の値は、ソーステーブル内の列の名前をパラメータとして使用して、ログビューワのファンクションコールによってログビューワ１２９から獲得される。各列は、たとえば、特定の変更テーブルに対応するオブジェクト名を前に付加することによって、変更セット内の他の列間で明確にするために別名を付けられる。
【００３９】
スロット「ft」は、現在の変更テーブルに対する第１の変更記録のトランザクション識別子を保持し、トランザクション識別子は一意の単調に増加するトランザクション番号またはシステム変更番号である。同様に、スロット「lt」は、現在の変更テーブルに対する最後の変更記録のトランザクション識別子である。この例では、「ft」のスロットは第１のトランザクションに対する１００１の値を有し、「lt」のスロットは最後のトランザクションに対する９００９の値を有してもよい。
【００４０】
ステップ３０７では、生成されたＳＱＬステートメントが実行され、ログビューワ１２９を介して送られた修復ログ１１７から変更データが取出され、対応する変更テーブルが更新される。マルチテーブル「INSERT...SELECT」ステートメントは、そのネイティブ言語がＳＱＬであるときに分析データベース１２５によって最適化することができる。結果として、分析データベース１２５は、分析データベース１２５のインデックス、区画分けおよび並列機能を利用することができる。さらに、この動作に標準のＳＱＬを使用することは、現代のリレーショナルデータベース管理システムの際立った特徴であるデータの整合性およびトランザクションの能力の利益を受ける。たとえば、マルチテーブル「INSERT...SELECT」のステートメントは、データロード動作全体が単一のトランザクションとして実行されるように変更セット当りの単一のトランザクションの一部にしてもよい。この方法は、たとえば、１つを除くすべての列がロードに成功した場合に起こるトランザクションの一貫性に影響する従来のフラットファイル方法を特徴付けるデータの整合性および修復の問題に対処する。
【００４１】
図４および図５は、単一の挿入のインプリメンテーション４０１に関する１つの複数の挿入のインプリメンテーション４０３による予期せぬ性能の向上を示す。図４では、単一の挿入のインプリメンテーション４０１の経過時間は、２つの変更テーブルについて５３分、１２の変更テーブルについて８時間１１分である。これらの時間は、２つの変更テーブルについて２６分、１２の変更テーブルについて４４分である複数の挿入のインプリメンテーション４０３についてのそれぞれの経過時間よりも一貫して長い。図５は、単一の挿入のインプリメンテーションに対する複数の挿入インプリメンテーションの２つ、４つ、８つおよび１２の変更テーブルを備えたランについての性能係数を示し、それぞれ、２．０、３．３、５．４および１１．２のスピードアップとなっている。
【００４２】
ハードウェアの概要
図６は、この発明による実施例を実現可能なコンピュータシステム６００を示す。コンピュータシステム６００は情報を通信するためのバス６０１または他の通信機構、および情報を処理するためのバス６０１に結合されるプロセッサ６０３を含む。コンピュータシステム６００は、プロセッサ６０３によって実行される情報および命令を記憶するためにバス６０１に結合されるランダムアクセスメモリ（ＲＡＭ）または他の動的記憶装置など
のメインメモリ６０５も含む。メインメモリ６０５はプロセッサ６０３による命令の実行中に変数または他の中間情報を記憶するために使用することもできる。コンピュータシステム６００は、プロセッサ６０３のための情報および命令を記憶するためにバス６０１に結合される読出し専用記憶装置（ＲＯＭ）６０７または他の静的記憶装置をさらに含んでもよい。磁気ディスクまたは光ディスクなどの記憶装置６０９は、情報および命令を永続的に記憶するためにバス６０１に結合される。
【００４３】
コンピュータシステム６００は、情報をコンピュータのユーザに表示するために、バス６０１を介してブラウン管（ＣＲＴ）、液晶ディスプレイ、アクティブマトリクスディスプレイまたはプラズマディスプレイなどのディスプレイ６１１に結合されてもよい。アルファベットキーおよび他のキーを含むキーボードなどの入力装置６１３は、情報およびコマンドの選択をプロセッサ６０３に通信するためにバス６０１に結合される。別の種類のユーザ入力装置は、マウス、トラックボールまたはカーソル方向キーなどのカーソル制御装置６１５であり、情報およびコマンドの選択をプロセッサ６０３に通信し、ディスプレイ６１１上のカーソルの動きを制御する。
【００４４】
この発明の一実施例によると、高性能な変更の捕捉は、プロセッサ６０３がメインメモリ６０５に含まれる命令の配置を実行することに応答してコンピュータシステム６００によって実現される。そのような命令は、記憶装置６０９などの別のコンピュータ読取可能な媒体からメインメモリ６０５に読込んでもよい。メインメモリ６０５に含まれる命令の配置の実行がここに説明されるプロセスのステップをプロセッサ６０３に実現させる。メインメモリ６０５に含まれる命令を実行するためにマルチプロセッシング配置の１つまたは複数のプロセッサを用いてもよい。代替の実施例では、この発明の実施例を実現するために、ソフトウェアの命令の代わりにまたはこれと組合せてハードウェアに組込みの回路を使用してもよい。別の例では、典型的にはその論理ゲートの機能性および接続のトポロジをメモリのルックアップテーブルをプログラミングすることによってランタイムにカスタマイズ可能である、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）などの再構成可能なハードウェアを使用してもよい。したがって、この発明の実施例はハードウェア回路およびソフトウェアの特定の組合せに限定されない。
【００４５】
コンピュータシステム６００はバス６０１に結合される通信インターフェイス６１７も含む。通信インターフェイス６１７は、ローカルネットワーク６２１に接続されるネットワークリンク６１９に結合する２方向のデータ通信を提供する。たとえば、通信インターフェイス６１７は、デジタル加入者回線（ＤＳＬ）カードまたはモデム、統合デジタル通信網（ＩＳＤＮ）カード、ケーブルモデル、電話モデム、または対応する種類の通信回線にデータ通信接続を提供する他の通信インターフェイスであってもよい。別の例として、通信インターフェイス６１７は、（たとえば、イーサネット（登録商標）または非同期式転送モデル（ＡＴＭ）ネットワークに対する）ローカルエリアネットワーク（ＬＡＮ）カードであって互換性ＬＡＮにデータ通信接続を提供してもよい。無線リンクを実現してもよい。そのような実現例では、通信インターフェイス６１７は、さまざまな種類の情報を表わすデジタルデータストリームを運ぶ電気信号、電磁気信号または光信号を授受する。さらに、通信インターフェイス６１７は、ユニバーサルシリアスバス（ＵＳＢ）インターフェイス、ＰＣＭＣＩＡ（Personal Computer Memory Card International Association）インターフェイス等の周辺インターフェイス装置を含み得る。図６には単一の通信インターフェイス６１７が示されるが、複数の通信インターフェイスを用いてもよい。
【００４６】
ネットワークリンク６１９は、典型的には１つまたは複数のネットワークを通じて他のデータ装置にデータ通信を提供する。たとえば、ネットワークリンク６１９は、ローカルネットワーク６２１を通じてホストコンピュータ６２３に接続を提供してもよく、これはネットワーク６２５（たとえば、ワイドエリアネットワーク（ＷＡＮ）または現在では一
般に「インターネット」と称されるグローバルパケットデータ通信ネットワーク）もしくはサービスプロバイダによって運営されるデータ装置への接続性を有する。ローカルネットワーク６２１およびネットワーク６２５は共に情報および命令を伝えるために電気信号、電磁気信号または光信号を使用する。さまざまなネットワークを通る信号およびネットワークリンク６１９上および通信インターフェイス６１７を通る信号はコンピュータシステム６００とデジタルデータを通信するが、これらは情報および命令を運ぶ搬送波の例示的な形である。
【００４７】
コンピュータシステム６００は、ネットワーク、ネットワークリンク６１９、および通信インターフェイス６１７を通じて、プログラムコードを含むメッセージを送り、データを受取る。インターネットの例では、サーバ（図示せず）は、この発明の実施例を実現するためにアプリケーションプログラムに属する要求されたコードをネットワーク６２５、ローカルネットワーク６２１および通信インターフェイス６１７を通じて送信し得る。プロセッサ６０３は受信されている送信されたコードを実行してもよく、および／または後に実行するために記憶装置６０９または他の不揮発性記憶装置にコードを記憶してもよい。このように、コンピュータシステム６００は搬送波の形でアプリケーションコードを獲得することができる。
【００４８】
ここで使用される「コンピュータ読取可能な媒体」という用語は、プロセッサ６０５に命令を提供して実行することに参加するあらゆる媒体を指す。そのような媒体は、不揮発性媒体、揮発性媒体および伝送媒体を含むがこれらに限らないさまざまな形をとり得る。たとえば、不揮発性媒体は記憶装置６０９などの光ディスクまたは磁気ディスクを含む。揮発性媒体はメインメモリ６０５などの動的メモリを含む。伝送媒体は、バス６０１を含むワイヤを含む、同軸ケーブル、銅線および光ファイバを含む。伝送媒体は、無線周波数（ＲＦ）および赤外線（ＩＲ）データ通信中に生成されるような音波、光波または電磁波の形をとり得る。コンピュータ読取可能な媒体の一般的な形は、たとえば、フロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、磁気テープ、他の磁気媒体、ＣＤ−ＲＯＭ、ＣＤＲＷ、ＤＶＤ、他の光媒体、パンチカード、紙テープ、光学式マークシート、孔または他の光学的に認識可能な印を備えた他の物理的な媒体、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭ、他のメモリチップまたはカートリッジ、搬送波、またはそこからコンピュータが読取ることのできる他の媒体を含む。
【００４９】
さまざまな形のコンピュータ読取可能な媒体がプロセッサに命令を提供して実行することに関わり得る。たとえば、この発明の少なくとも一部を実行するための命令は、当初、遠隔コンピュータの磁気ディスク上で運ばれてもよい。そのような場合、遠隔コンピュータは命令をメインメモリにロードし、モデムを使用して電話線上で命令を送信する。ローカルコンピュータシステムのモデムは電話線上でデータを受取り、赤外線送信機を使用してそのデータを赤外線信号に変換し、その赤外線信号を携帯用情報端末（ＰＤＡ）またはラップトップなどのポータブルコンピュータ装置に送信する。ポータブルコンピュータ装置上の赤外線検出器が赤外線信号によって運ばれる情報および命令を受取り、そのデータをバスに位置付ける。バスはデータをメインメモリに伝え、そこからプロセッサが命令を検索し実行する。メインメモリによって受取られる命令は、任意でプロセッサによる実行の前後に記憶装置に記憶してもよい。
【００５０】
この発明をいくつかの実施例および実現例に関して説明してきたが、この発明はそのように限定されず、特許請求の範囲内にあるさまざまな明らかな変形例および均等な配置を含む。
【図面の簡単な説明】
【００５１】
【図１】この発明の一実施例の高レベルのアーキテクチャの図である。
【図２】この発明の一実施例による変更オブジェクトを示す概略図である。
【図３】この発明の或る実施例のための高性能な変更データの捕捉を示すフローチャートである。
【図４】或る実施例による単一テーブル挿入ステートメントおよびマルチテーブル挿入ステートメントを使用する変更テーブルのための修復ログの処理の経過時間を示すグラフである。
【図５】或る実施例による単一テーブル挿入ステートメントおよびステートメントに対するマルチテーブル挿入ステートメントの相対的な性能を示す棒グラフである。
【図６】この発明のある実施例を実現するために使用可能なコンピュータシステムの図である。
【図１】
2005527912.tif 000004
【図２】
2005527912.tif 000005
【図３】
2005527912.tif 000006
【図４】
2005527912.tif 000007
【図５】
2005527912.tif 000008
【図６】
2005527912.tif 000009
【国際調査報告】
2005527912.tif 000010
2005527912.tif 000011
2005527912.tif 000012