JP2000501532A - データベースアクセス - Google Patents

Abstract

(57)【要約】 マスターデータベース126を動作させるファイルサーバ100とキャッシュデータベース136を支持するクライアント130とを有するクライアント／サーバ環境において、不一致のデータの書込みアクセスが１人のクライアント130により要求された更新処理の過程中データをロックするデータロック技術を使用することによって阻止される。これは他のクライアントによる同じデータに対するアクセスを阻止する。データの一致は書込みアクセスに先立って、各キャッシュデータベースエントリと関係する時間スタンプとマスターデータベース中の対応するデータエントリに対するインデックスと関係する時間スタンプとを比較することによって検査される。時間スタンプ等価物はマスターデータベース126にアクセスする必要をなくし、またはクライアント／サーバ通信ネットワーク140を横切ってデータを転送させる必要をなくすことができる。

Description

【発明の詳細な説明】 データベースアクセス 本発明は、一般的にデータベースアクセス技術に関する。特に、本発明はキャ ッシュ記憶を支援するファイルサーバならびにキャッシュ記憶の一致性を確保す る方法および装置に関する。 今日の情報時代において、データベース中に保持されているデータに迅速にア クセスする能力は、データに依存するビジネスを行う企業や組織にとって最も重 要なものである。 遠隔地の装置またはクライアントがデータベースのデータにアクセスすること のできる速度は２つの主要な要因に依存している。第１の要因は、データベース のファイルサーバが一般的にハードディスク駆動装置のような同じ位置の外部記 憶装置からデータを読取ることができる速度である。この要因は、中央処理装置 （ＣＰＵ）の速度とファイルサーバのディスクアクセス速度とに依存している。 第２の要因は、クライアントとファイルサーバとの間の通信リンクの容量または 帯域幅である。 システム全体の性能に非常に大きく影響する、データベースアクセス速度に影 響する第３の要因は、システムにおけるローディングである。ローディングは一 般にデータベースへのアクセスを要求するクライアントの数に比例している。Ｃ ＰＵによって行われる動作の数と通信リンクを通って伝送される必要のあるデー タの量の両者はデータベースへのアクセスを要求するクライアントの数が増加す るにしたがって増加する。明らかに、ファイルサーバおよび通信リンクに対して 求められる需要が最適容量を越える点が存在し、その点を越えるとシステムの性 能は低下する。 システムの性能はファイルサーバの速度および通信リンクの帯域幅を増加させ ることによって改善される。しかしながら、関連するコストは常に妥当なもので あるとは限らない。また、現在の技術で動作することのできる速度には常に限界 がある。 データベースＣＰＵおよび通信リンクロードを減少させることによってより良 好なシステム性能を得る別の方法ではデータのキャッシュコピーを使用する。キ ャッシュコピーは一般的にクライアントに物理的に近い位置、またはクライアン トのシステム自体の中に配置されている。事実、この技術は“ミラーサイト”に 置かれたデータのキャッシュコピーを含むインターネットファイルサーバを使用 することによって広くインターネットに採用されている。例えば米国内に位置す るインターネットファイルサーバからアクセス可能なマスターデータは英国のミ ラーサイトに配置されたファイルサーバにコピーまたは記憶され、そこからヨー ロッパの大部分のユーザはデータを読取ることができることが好ましい。したが って、大西洋横断通信リンクに対するデータ伝送オーバーヘッドおよびマスター インターネットファイルサーバに対して求められる需要は減少し、全体的に知覚 されたインターネット特性は改善される。特に、ヨーロッパのユーザは英国のミ ラーサイトにアクセスすることにより遥かに良好なデータベースアクセス性能を 得ることが期待される。 キャッシュ記憶されたデータの使用はデータの一致性に関して重要な問題を生 じている。すなわち、キャッシュ記憶されたデータが元のマスターデータと同じ であるか否かを知ることが困難な場合があり、マスターデータはキャッシュコピ ーが生成された後で色々の方法で変化する可能性がある。例えば、インターネッ トの場合に、現在ではマスターデータと記憶されたデータとの間の一致性の欠如 はそれ程大きいものではなく、もしも著しく大きい場合には通常マスターデータ ベースから遅い速度であるがマスターデータの検索を選択することが可能である 。 しかしながら、記憶されたデータの一致性または一貫性は、記憶された、また はマスターのデータがビジネスにおける決定の基礎となっているような商業環境 では非常に重要である。不一致のデータ、或いはアクセスに非常に長い時間を必 要とするデータは結果的に収入を減少させることを避けることはできない。その ような環境の簡単な１例は航空券の予約購入であり、その場合に、例えばマスタ ーフライトデータは英国にあるデータベース中に保持されており、ヨーロッパ区 域の旅行代理店はキャッシュメモリに記憶されたデータに基づいてフライトの座 席を予約する。この例では多くの場合にキャッシュ記憶されたデータはマスター データと一致していることが重要である。 同様の考慮は一般的に多数のユーザのシステム、例えば、クライアント／サー バまたは分布されたデータベースに基づいたもの等のネットワークされた環境で は重要である。この場合に、ＣＰＵ、データアクセス、マスターデータベースフ ァイルサーバに課せられたデータ転送オーバーヘッド、および全体のネットワー クトラフィックを最小にするために、ユーザはキャッシュ記憶されたデータにで きるならばいつも依存することになる。 例えば、単一のマスターデータベースファイルサーバにアクセスする多数のク ライアントを有するクライアント／サーバ環境では、各クライアントが最近読取 ったデータの大きいキャッシュを維持することが一般にかなり存在する。キャッ シュはマスターデータベースからのデータの再度の読取りを避けるために処理の 実行中に使用されることができる。しかしながら、データがクライアントにおい て記憶され、マスターデータベース中のデータが変化不能でないにもかかわらず 、クライアントが後でそのデータを再度アクセスすることを必要とする場合には 、異なっていることを知る方法がないためにキャッシュのデータは不一致である と仮定されなければならない。したがって、少なくともマスターデータベース中 のデータの現在の状態をキャッシュのデータベース中のデータと比較するために さらにマスターデータベースのアクセスが必要とされる。 データキャッシュ記憶を使用するかしないかの判定は、一般にアクセスされる データの形式に依存している。データの３つの通常のカテゴリーについて以下説 明する。 静的なデータ、すなわちほとんど変化しないデータはクライアントのキャッシ ュメモリのデータベースに保持される最重要候補である。データは常に現在のも のであると仮定することができる。しかしながら、通常、静的なデータに対する 変化が全てのクライアントのキャッシュに伝達されることを確実にするための作 業が行われなければならない。これは通常夜間のバッチ処理を使用して行われる 。静的なデータに対しては一致性を維持するための実時間処理は必要ない。 高度に動的なデータは一致状態に維持することが非常に困難である。その基本 的な理由は、データが非常に頻繁に変化する場合には多数のクライアントキャッ シュの更新がもたらすネットワークおよびプロセッサの衝撃はクライアント／サ ーバ環境では可成のものとなる。場合によっては、処理のオーバーヘッドおよび キャッシュを維持するネットワーク帯域幅で見たコストは、データが要求される 都度、各クライアントが直接マスターデータベースにアクセスするコストを越え る可能性がある。したがって、このカテゴリーのデータは一般にキャッシュ記憶 されない。 静的なデータと高度に動的なデータとの間には、静的ではないが、高度に動的 なデータと比較するとそれ程変化が頻繁ではないデータが存在する。一般に、こ の場合に、データは例えば旅行代理店においては航空機のフライトの問合わせと 航空機の座席券発行動作中にのみクライアントのキャッシュメモリのデータベー ス中に記憶されてもよい。その場合、動作中データが一致した状態を維持してい ことには高度の確実性があることになる。しかしながら、第１のクライアントが 動作を開始してから動作を完了するまでの間に別のクライアントまたは旅行代理 店が同時にその航空機で残っている座席の券を発行する可能性があるから絶対的 な確実性は決して存在しない。 上述の航空券の発行動作の例においてデータの不一致を阻止する最も簡単な方 法は、１人のクライアントによってアクセスされているマスターデータベースの 全てのデータをロックして、したがって他のクライアントに対しては動作の全期 間にわたってデータをアクセスできないようにするか、または少なくとも読取り 可能なだけにすることである。これは‘悲観的ロック”と呼ばれている。代表的 なものでは、アクセスまたは書込みされることができないロックされたデータの 識別子を保持しているロックテーブルがマスターファイルサーバによって生成さ れる。そのようなシステムは、アクセスまたは書込みが許可または否認される前 にクライアントによって行われた全てのアクセス要求がファイルサーバ上のロッ クテーブルのサーチを呼出すことを必要とする。 しかしながら、同じデータが例えば航空券の発行の目的に対して複数のクライ アントによってアクセスされ、または更新されることが必要である場合には、悲 観的ロックは許容できないロッキングオーバーヘッドを伴う動作不能の解を意味 する。 キャッシュデータとマスターデータとの間で生じる可能な不一致を処理する別 の方法は、Gray JおよびReuterによる文献（“Transaction Processing-Concept s and Techniques”434〜435頁、1933年、Morgan Kaufman発行）に記載されてい る。その方法は“楽観的ロッキング”を含む。 楽観的ロッキングはファイルサーバに接続されたクライアントが任意の時間に 読取りのために記憶されたデータを使用することを可能にするが、例えば航空機 の座席の券の発行処理が開始されると直ちにキャッシュデータはデータの一致を 確保するためにマスターデータと比較され、マスターデータは実際の処理の期間 中（この例では処理は実際のデータベースにアクセスして書き込む手順である） のみロックされる。これは処理期間中に他のクライアントによるマスターデータ の変更を阻止する。もしも、処理の開始後にキャッシュデータベース中のデータ がマスターデータベース中の対応するデータと不一致であることが発見されたな らば、キャッシュデータベースは最新のマスターデータにより更新され、クライ アントは不一致を生じたことを注意され、問題の解決が残される。 この楽観的ロッキングの利点は、マスターデータが実際の処理を行うための例 えば１秒以下のような非常に短い時間しかロックされないことである。これに対 して悲観的ロックは例えば問合わせおよび処理の全期間のような動作の全期間に わたってロックされることを必要とし、それは何分もの時間をとることになる。 それ故、楽観的ロッキングはクライアントおよびファイルサーバの両者による 余分の処理を必要とするけれども、その技術は多数のクライアントによってアク セスされる必要がある比較的動的なデータを処理するためにはより適したもので あることが認められる。 楽観的ロッキングを実行するとき、場合によってはデータが最後に更新された 時間でマスターデータベース中のデータの行にマークをつける時間スタンプを使 用することが知られている。このようにして、もしもキャッシュメモリ中に保持 されているデータの特定の行に対する時間スタンプがマスターデータベースのそ の行と同じであるならば、ファイルサーバはキャッシュメモリに入れたデータが 現在のものであり、ネットワークを通ってクライアントにそのデータ行を再送信 する必要はないことを認める。したがってネットワーク帯域幅はキャッシュメモ リに記憶されたコピーが現在のものであることが発見された場合には保存される 。 第１の特徴によると、本発明は、キャッシュデータベース中のデータのアイテ ムと関連して記憶された第１のキーとマスターデータベース中のデータの各アイ テムに対するインデックスエントリーと関連して記憶された第２のキーとを比較 することによりマスターデータベース中のデータの各アイテムによりキャッシュ データベース中のデータのアイテムの一致性を検査する方法を提供する。 第２の特徴によると、本発明は、キャッシュまたはマスターデータベースの１ つからのデータのアイテムを検索する方法を提供する。マスターデータベースは マスターデータの複数のアイテムおよびマスターデータの１または複数のアイテ ムに対応するエントリを含むインデックスを含み、キャッシュデータベースはマ スターデータの１または複数のアイテムのキャッシュメモリに記憶されたコピー を含む。この方法は、 キャッシュデータベースからデータの要求されたアイテムの、キャッシュに記 憶されたコピーに関連して記憶された第１のキーを読取り、 マスターデータベースからマスターデータの各アイテムに対するインデックス エントリに関連して記憶された第２のキーを読取り、 第１のキーと第２のキーとを比較し、 第１のキーと第２のキーとが同じ場合にはデータのアイテムのキャッシュに記 憶されたコピーを検索し、第１のキーと第２のキーとが異なる場合にはマスター データの各アイテムを検索するステップを含んでいる。 本発明の第３の特徴によれば、本発明はデータベースファイルサーバ装置を提 供する。そのデータベースファイルサーバ装置は、 データベース中に記憶されたデータのアイテムに対してそのデータのアイテム の前に検索されたコピーからの第１のキーを含む条件読取り要求を受信する入力 手段と、 データベースのインデックスにアクセスし、情報の記憶されたアイテムに対す る第２のキーを含むデータの要求されたアイテムに対するインデックスエントリ を読取る手段と、 第１のキーと第２のキーとを比較する手段と、 第１のキーと第２のキーとが同じ場合にはデータのアイテムの前に検索された コピーが一致していることの指示を戻し、第１のキーと第２のキーとが異なる場 合にはデータベースから読取り、データのアイテムのコピーを戻す手段とを具備 している。 本発明の第４の特徴によれば、本発明はデータベースインデックスを提供する 。それにおいてインデックス中の１以上のインデックスエントリは、 データベース中のデータのアイテムを識別する識別情報と、 データベースのアイテムのデータベース中の位置を指示する位置情報と、 データベース中の各データが変化する都度変化するバージョン情報とを少なく とも含んでいる。 本発明の実施形態は例えばクライアント／サーバ環境のような多数のユーザを 有するコンピュータ環境において使用するのに特に適している。 キーまたはバージョン情報は時間スタンプであることが好ましく、この時間ス タンプは各データが更新された最後の時間に関係している。しかしながら、その 代りにキーは各データが変化する都度変化する他の指示子であってもよい。例え ばキーは各データが訂正されるときにインクレメントされるインクレメントカウ ンタにより発生されるバージョン番号で構成されてもよい。 マスターデータベースのインデックス中のエントリと関係するキーを有するこ とによって、実際のマスターデータを読取る必要をなくすことができる。従来時 間スタンプのようなキーの使用はそのインデックスエントリとではなく実際のマ スターデータを有する関連するキーに限定されている。それ故、キーが同じであ るか否かに関係なく、データは比較のためにマスターデータベースから読取る必 要があった。 幾つかの実施形態では、マスターデータベースは外部記憶装置中およびファイ ルサーバの主メモリ中の両者に記憶される。 本発明の実施形態が以下添付図面を参照にして例示として説明される。 図１は、本発明の１実施形態を構成するのに適した例示的な２段のクライアン ト／サーバコンピュータ環境のブロック図である。 図２は、データベースシステムのための代表的なデータ構造を示した図である 。 図３ａ乃至３ｃは、２つの従来のシステムおよび本発明の１実施形態に対する データベースの行およびインデックス構造を示した図である。 図４は、代表的なデータベース処理を示したフローチャートである。 図５は、代表的なデータベース読取り処理を示したフローチャートである。 図６は、本発明の１実施形態によるラインにおいて変更されたデータベース読 取り処理を示したフローチャートである。 図７は、データベース書込み処理を示したフローチャートである。 図８は、本発明の１実施形態が実施される３段のアーキテクチュアを示す図で ある。 図９は、図８の別の構成である。 図１０ａは、本発明の１実施形態の特性を試験するためのシステムを示す図で ある。 図１０ｂは、１組のベース特性を設定するシステムを示す図である。 図１１は、異なったキャッシュまたはキャッシュのないシナリオに対するＣＰ Ｕオーバーヘッドを示すグラフである。 図１２は、異なったキャッシュまたはキャッシュのないシナリオに対する通信 処理のみに対するＣＰＵオーバーヘッドを示すグラフである。 図１３は、異なったキャッシュまたはキャッシュのないシナリオに対するデー タベースアクセスのみに対するＣＰＵオーバーヘッドを示すグラフである。 図１４は、異なったキャッシュまたはキャッシュのないシナリオに対するデー タベースからデータを検索するために要求される読取りアクセスの数を示すグラ フである。 図１５は、外部記憶装置ではなく主メモリ中にインデックスデータを維持する ことによりデータベースアクセス性能がどのように改善されるか示すグラフであ る。 図１は、本発明の１実施形態を構成する例示的な２段のクライアント／サーバ コンピュータ環境のブロック図を示している。 例えばＵＮＩＸオペレーティングシステムを動作させる計算プラットホームで あるファイルサーバ100は、ネットワーク140とそのネットワーク140により複 数のクライアント130に遠隔データベースアクセスを与えるのに適したデータベ ース管理システム（ＤＢＭＳ）ソフトウエアをランさせる。この説明において、 他の表現もされているが、用語“クライアント”はネットワーク140に接続され ている物理的なコンピュータ130およびコンピュータのオペレータの両者を示す ために使用される。ローカルエリアネットワークの場合には、適切なネットワー クはＴＣＰ／ＩＰソフトウエアを動作させるイーサネットネットワークであり、 適切なＤＢＭＳソフトウエアはオラクル(Oracle)バージョン７であってもよい。 ＤＢＭＳソフトウエアは複雑なデータベースシステムの生成および制御を可能に し、適切な構成化問合わせ言語（ＳＱＬ）呼によってそこにあるデータにアクセ スする。このようなシステムについてのさらに別の情報については、読者は広く 入手可能なデータベースシステムに関する多数のテキストおよび基準マニュアル を参照されたい。 ファイルサーバ100は、適当なデータおよびアドレスバス108により接続されて いるプロセッサ102、主メモリ104、および入力／出力（Ｉ／Ｏ）ハードウエア10 6のような標準的なコンピュータ部品で構成されている。ファイルサーバ100は一 般にハードディスク120のような大容量の（例えば１０ギガバイト）外部記憶装 置を支持し、それにマスターデータベース中の実質的に全ての情報が記憶されて いる。 ファイルサーバの主メモリ104は標準的なプログラムとデータを記憶するため の区域に分割されている。また、オラクルデータベースソフトウエアの動作の例 に対しては、主メモリはシステムグローバル区域（ＳＧＡ）105として知られて いる大きいメモリ区域を含んでおり、その目的については以下説明する。この説 明において、用語“ファイルサーバ”、“データベース”、および“ＤＢＭＳ” は交換可能に使用され、全て一般にクライアントがデータアクセスを行うマスタ ーデータ記憶システムを示すものである。 クライアント130は、例えばＩＢＭパーソナルコンピュータのような標準的な コンピュータシステムであり、１００メガバイト程度の記憶容量を有する標準的 なハードディスク駆動装置135を備えている。クライアント130はＳＱＬ質問を使 用してデータベース中に記憶されている（読取りおよび書込み）データにアク セスするのに適した、例えばマイクロソフト・ウインドウズ方式のようなソフト ウエアでランし、それのＳＱＬ質問はＤＢＭＳソフトウエアにより翻訳され、処 理される。ハードディスク駆動装置135は、キャッシュデータベース136に対する 記憶領域を有し、そこにマスターデータベース126からのデータがコピーされ、 必要に応じてアクセスされる。 図２に示されるように、典型的にマスターデータベース126は２つの物理的領 域から構成されている。第１の領域はデータベーステーブル204を保持し、そこ にデータベースのデータが記憶される。データベーステーブル204は通常関係す るデータのグループから構成されている。例えばテーブル204は来年のヨーロッ パ周辺の旅客航空機の全飛行スケジュールについての情報を保持することができ る。テーブルは頁215またはブロックに分割され、この例ではそれは１つの行210 が１つの特定されたフライトを表している。各フライトについてのデータは各行 210中のフィールド305またはカラム（図３ａに示される）中に保持されている。 特定のフライトに対する例示的なフィールド305には次のようなものが含まれて いる。 目的地 ３バイト 出発地 ３バイト 週の開始 ２バイト 日付 ８バイト 時間 ５バイト 座席利用可能性 ３バイト フライト番号 ８バイト １座席当りの価格 ８バイト 合計 １２０バイト データベース中の第２の領域は、インデックスページ220を有するインデック ス206である。インデックスページ220は、データテーブル204中の各行210に対す るインデックスエントリ225を含んでいる。インデックスエントリ225は通常イン デックスフィールドを備え、その１つはデータテーブル215中の特定のデータ行 に関係している。オラクルの場合、インデックスは通常、インデックスの サーチを迅速にするためにＢツリー（２進ツリー）として（内部に）配置されて いる。Ｂツリーのサーチに使用される機構は広く知られているが、本発明の技術 の説明には関係がない。従って、説明の便宜上および簡単化する目的のためだけ に、インデックスはデータテーブルの簡単なサブセットとして扱われる。 図３ａにおいて示されているように、インデックスエントリ225は、例えば目 的地等を含んでいる第１のインデックスフィールド310と、例えば週の開始の値 を含んでいる第２のインデックスフィールド311と、対応するデータ行210がデー タテーブル204中で保持されている場所を示すポインタである第３のインデック スフィールド312とを含んでいる。それ故、この例において、フライトは目的地 によってその年の特定の週についてサーチできる。例示的なサーチの照会によっ て、その年の第２５週目のパリ行きの全てのフライトが特定される。これに応答 して、ＤＢＭＳは、１９９５年１２月１０日に開始する週のパリ行きの全てのフ ライトのインデックスをサーチし、対応する行を要求しているクライアントに送 り返す。明らかに、例えば特定の日等による別のサーチ基準の場合、インデック スは週の開始フィールドの代りに特定のデータフィールドを有する必要がある。 一般的に、それぞれ異なる潜在的なサーチ基準に対して異なるインデックスが通 常必要とされる。 キャッシュデータベース136は、キャッシュ記憶されたデータのための記憶領 域230を備えている。キャッシュ記憶されたデータは、一般にマスターデータベ ース126からコピーされたデータ行235を有している。通常、行235それ自体はデ ータテーブル204中の行210の正確なコピーであるが、この場合にはそうである必 要はない。従って、図３ａに示された行の構成は、キャッシュおよびマスターデ ータベースのデータ行の両方に共通である。 キャッシュのデータベース136は、キャッシュデータベースの大きさおよび許 容可能なアクセス速度に依存して、対応するインデックスを有していても有して いなくてもよい。本発明の目的のために、キャッシュデータベースはインデック スを有しておらず、それ故順次のアクセスによってサーチされると仮定する。 ファイルサーバ100上のＳＧＡメモリ105は、主に主メモリ104に位置されてい るか、あるいは、全体的に十分調整されたシステム中に位置されていることが 好ましい。ＳＧＡ105は、クライアント130へのマスターデータベースのアクセス の速度を上昇するためにオラクルによって使用される内部キャッシュの一形態で ある。ＳＧＡ105の存在および動作は一般にシステムのユーザあるいはクライア ントには見えないものである。オラクル以外のＤＢＭは類似した方式を実行する 。 クライアントがデータのアイテムを要求すると、ファイルサーバ100は最初に ＳＧＡ105において、次にマスターデータベース126においてそれぞれのインデッ クスエントリーを捜し、その後、ＳＧＡにおいて、続いてマスターベースにおい てデータ行のコピーを捜す。インデックスエントリーあるいはそれぞれのマスタ ーデータのいずれかがＳＧＡ105中にない場合、ファイルサーバはマスターデー タベース126にアクセスし、インデックスエントリーあるいはデータをＳＧＡ105 にコピーする。行がマスターデータベース126からＳＧＡ105にコピーされる必要 があるとき、実際にはその行を含んでいるページ全体あるいはブロックがＳＧＡ 105にコピーされる。要求された行への任意のアクセスは、そこからＳＧＡ105を 介して行われる。この方法において、時間の経過と共に、最も一般的にアクセス されたアンド／オア・ダイナミックデータがＳＧＡ105中に存在する傾向があり 、主メモリ104へのアクセスはハードディスク120にアクセスする速度よりも１桁 以上速くすることができるので、データベースへの全体的な平均アクセス時間が 減少される。本発明の実施形態において、説明を簡単にするためだけに、ページ ではなくむしろ特定の行だけが記憶されるものとする。 現在、主メモリの容量は、外部メモリの記憶容量よりはるかに低く制限されて いる。それ故、ＳＧＡ105は、最も最近に使用されたデータだけを含んでいる。 また、主メモリ104は揮発性のＲＡＭを備えていることが多いので、データベー スはＳＧＡ105中に保持されたデータに対する任意の変更で定期的に（例えば一 日のベースで）更新される必要がある。実際に、ＳＧＡ105は、マスターデータ ベースの集約部分を形成し、更新されたデータがディスク駆動装置120上のマス ターデータベースに周期的に書戻される限りにおいて類似した方法でキャッシュ に書戻される 既に述べられているように、キャッシュデータベース136は通常、マスターデ ータベース126からそれぞれのデータ行のコピーであるデータ行235を保持するよ うに配置されたキャッシュテーブルを有している。 理解を簡単にするために、以下の説明において、データへのアクセスあるいは 書き込みの拒否は（上に手短に説明された）ロックの存在のために考慮されない 。しかしながら、実際には、ロックはファイルサーバ上で所望のデータアクセス を阻止し、また、通常ＤＢＭは例えば拒否されたクライアントの動作をロックの 解除まで凍結する等の適当な方法でそのような状況に対処することを思い出すべ きである。 データベース環境においてクライアントによって実行される２つの主要な処理 は、データの“読取り”およびデータの“更新”あるいは“書込み”であり、デ ータの生成あるいは書込みは、本発明の目的の場合にはデータの更新と同じ方法 で処理される。読取りおよび書込みを組合わせることによって、一般にクライア ント／サーバのデータベースの処理のための基礎が形成される。 基本的なデータベースの動作の一例において、データの記憶を行わない状況が 図４においてフローチャートで示されている。 図４において、クライアント130は、マスターデータベース126からデータを読 取るためにステップ400において質問を送信する。ステップ410において、ファイ ルサーバ100は質問を受取る。ファイルサーバ100はステップ420においてクライ アント130に情報を戻す。その後、クライアントは、ステップ430において戻され たデータに基づいて判断を行う。判断の一例は、パリ行きの多数の利用可能なフ ライトのうち、どのフライトを予約するかを値段を基準にして判断することであ る。ステップ440において、ファイルサーバ100に適切なデータを伝送することに よって特定のフライトでの座席を予約するための処理がクライアント130によっ て開始される。データは、例えばパリ行きのフライトの座席を予約したいクライ アントの詳細なクライアント情報ならびにそのフライトでの座席の利用可能性を 減少させるための書込み要求等を含んでいる。データを受取ると、ステップ450 においてファイルサーバ100は、ロックテーブルにおいてエントリを生成するこ とによって、更新されるデータをサーチしてロックする。次に、ステップ460に おいて、ファイルサーバ100は、可能であるならばデータテーブルか ら読取られたフライトデータを更新する。ステップ470において、ファイルサー バ100は更新されたフライトデータおよび新しいクライアントデータをデータベ ース中のそれぞれのデータテーブルに記録する。そのデータはステップ480にお いてロックテーブルのエントリを除去することによってロックを解除され、それ によって別のクライアントがデータにアクセスすることを許容する。最後に、ス テップ490において、ファイルサーバ100は、クライアントに応答して処理が成功 したという状態を送信する。 図５および図６は、インデックスエントリにおいて時間スタンプを使用しない で動作するシステムおよび時間スタンプを使用して動作するシステムに対する適 切な読取り質問によって励起されたデータベースのキャッシュ記憶を考慮して、 それぞれのデータベース読取り手順をフローチャートで表したものである。両方 の例において、要求されるデータ行はただ１つであるが、多数の行に対する質問 も可能であることが理解されるであろう。また、データのキャッシュコピーはす でにキャッシュデータベース136中に存在しており、データのキャッシュコピー およびデータのマスターコピーの両者は、それぞれのデータに対する最後の更新 の時間を表す時間スタンプを含んでいると仮定される。 図５に示されたプロセスについての以下の説明において、データ行およびイン デックスのエントリが図３ｂに示された構造を有していると仮定する。 図５において、ステップ500において、クライアント130はネットワーク140を 通ってファイルサーバ100に質問を送信し、ファイルサーバからデータを読取る 。質問は、要求されたデータ行に対する識別子およびそれぞれの時間スタンプを 含んでいる。ステップ505において、ファイルサーバ100は質問を受取る。ファイ ルサーバ100は、ステップ510において、質問中に関係のあるデータのインデック ス225を捜してＳＧＡ105にアクセスし、それが存在する場合にはインデックスを 検索する。ステップ515において、インデックス225がＳＧＡ105中にある場合、 インデックスの値に基づいて、ファイルサーバ100はマスターデータベース126の データテーブル204にアクセスし、ステップ523において行210を含んでいる（Ｓ ＧＡ中あるいは外部記憶装置上に存在している）データページ215を検索する。 他方、インデックス225がＳＧＡ105中にない場合、ステップ520においてファイ ルサーバ100は外部記憶装置上のインデックス220にアクセスし、ＳＧＡ1O5へそ のインデックスエントリをコピーする。その後、ステップ523において、ファイ ルサーバ100はマスターデータベース126の各データページ215にアクセスし、デ ータを検索する。全ての段階において、ＳＧＡ中に存在していないアクセスされ た任意のデータはＳＧＡにコピーされる。ステップ525において、ファイルサー バ100は記憶されたデータ行の時間スタンプを要求されたマスターデータ行と比 較する。時間スタンプが同じであれば、ステップ540にお いて、ファイルサーバ100はキャッシュ記憶されたデータが依然として有効であ るという返答をクライアント130に送り、時間スタンプが異なっている場合、ス テップ535においてファイルサーバ100はデータ行210全体（あるいはデータ行の 要求されたカラムだけ）をクライアント130に送り、キャッシュデータベース136 を更新する。ステップ545において、クライアントは返答を受取り、それに応じ て動作する。 図６に示されたプロセスについての以下の説明において、データ行およびイン デックスエントリは図３ｃに示された構造を有しているものと仮定する。 図６において、ステップ600乃至620は図５のステップ500乃至520と等しい。ス テップ625において、ファイルサーバ100はインデックスエントリにおける時間ス タンプを質問の時間スタンプと比較する。時間スタンプが同じである場合、ステ ップ640においてファイルサーバ100はキャッシュコピーが依然として有効である というメッセージをクライアント130に送信する。他方、時間スタンプが同じで ない場合、ファイルサーバ100はステップ630においてマスターデータベース126 にアクセスし、現在のデータ行を検索する。その後、現在のデータ行はクライア ント130に戻され、ステップ635においてキャッシュデータベース136を更新する 。ステップ645において、クライアント130は、ファイルサーバ100によって戻さ れたデータを受取り、それに応じて動作する。 本発明の方法およびデータベース構成の利点および欠点は、図５および図６の フローチャートを比較し、また図３ａ乃至図３ｃに示されたフィールドの長さを 考慮することによって理解できる。 明らかに、図３ａに示された行の構成を使用すると、データの一致性を検査す るために潜在的にデータの行全体をクライアント130からファイルサーバ100に送 る必要があるという欠点がある。しかしながら、図３ｂの構成を使用すると、要 求された行を示す参照記号および時間スタンプだけの送信が要求される。従って 、理論的に、図３ａと図３ｂとの間の伝送オーバーヘッドは、１０７バイトだけ カットされる（すなわちそれは、１２０バイトの行全体と参照記号との間の差で あり、その参照記号には３バイトの目的地フィールドと、２バイトの週の開始フ ィールドと、８バイトの時間スタンプフィールドが含まれており、１２０−１ ３＝１０７バイトである）。図３ｂおよび図３ｃのデータ構成をそれぞれ使用す る図５および図６を参照すると、クライアント130からファイルサーバへの伝送 オーバーヘッドは最初は同じである。すなわち、ステップ500乃至520およびステ ップ600乃至620は等しい。第１の違いはステップ525と625である。ステップ525 において、ファイルサーバ100は、要求されたデータ行を含むデータページ全体 をデータ表204から読取り、それによってデータ行210の時間スタンプを質問にお ける時間スタンプと比較できるようにする。それ故、図５において、ファイルサ ーバ100は、時間スタンプの比較を可能にするために要求された行を含むページ 全体を読取らなければならない。 対照的に、ステップ625においては、ファイルサーバ100は質問の時間スタンプ をインデックスエントリの時間スタンプと比較する。ファイルサーバ100は、時 間スタンプが異なる場合にはその行を含んでいるデータページ全体を読取る必要 があるだけである。結果的に、外部記憶装置120のアクセスは、時間スタンプが 同じであり、質問中のインデックスエントリがＳＧＡ105中にある場合には一般 的に要求されない。それ故、理論的に、データベースのアクセス時間およびファ イルサーバ100の処理オーバーヘッドが減少されることができ、クライアント130 に対する応答時間を減少させることができる。 提唱された方法の欠点は、インデックスのためにサイズが増加されることであ る。図３ｂおよび図３ｃのインデックス構成を考慮すると、インデックスのサイ ズが約７０％増加する。それ故、理論上、インデックスのサイズは約７０％増加 し、それに比例してサーチ時間も増加する。しかしながら、実際にはインデック スはより複雑であり、よりフレキシブルな質問のオプションを許容するために通 常はより多数のインデックスエントリを含んでいる。例えば、代表的なインデッ クスによって、目的地および週の開始と一緒にデータおよびフライト番号につい て行を探索できることになろう。従って、時間スタンプを加えてもあまり大きな オーバーヘッドは生じない。一般的に、インデックスへの時間スタンプの付加の オーバーヘッドは、インデックスのサイズおよび複雑さに依存している。 幾つかの実施形態において、例えばフライト座席利用可能性等の動的データと して分別されたデータへのインデックスエントリに時間スタンプを加えることだ けが必要とされる。従って、時間スタンプを例えばフライト番号および出発日の データ等の静的データに対するインデックスエントリに加えることは必要でない 。この方法において、インデックス中の時間スタンプのオーバーヘッドは減少さ れる。明らかに、ＳＱＬソフトウェアおよびＤＢＭＳは両方の可能性を扱う必要 がある。 時間スタンプを使用する例が詳細に説明されてきたが、データの一致性の比較 を可能にするためにデータ行にマークを付ける別の方法も可能であることが認め られよう。例えば、増分カウンタフィールドが時間スタンプの代りに使用されて もよい。データ行が修正される度に、フィールド中のカウント値はファイルサー バ上の処理によって増分される。従って、キャッシュデータ行の増分値とマスタ ーデータ行のインデックスエントリの増分値とを比較すると、マスターデータ行 に対する任意の変化が強調され、従ってキャッシュデータベース行との不一致も 強調される。例えば符号化を使用して行の特定の状態を表す特有のコードを生成 する等の不一致データを識別する別の比較方法は、この説明を読んだ当業者には 明らかであろう。 本発明の幾つかの実施形態において、ＳＧＡ105は、少なくともインデックス2 06を永久的に含むのに十分な大きさである。これは非常に望ましいことであり、 それは読取りあるいは書込みのために行う全てのインデックスへのアクセスは主 メモリ104へのアクセスだけを使用し、外部記憶装置120中のインデックス220へ アクセスする必要がないからである。これは将来、メモリがより廉価になり、Ｓ ＧＡのサイズが増加したときには普通になると思われる。それ故、ＳＧＡの領域 中に全て保持されたインデックスエントリの時間スタンプは効率を一層増加させ る。 データがクライアントによって修正されることを許容する任意のデータベース システムにおいて、必要であれば、処理を実行するために、別のクライアントが 更新されたデータにアクセスできることが重要である。これは上述のフライト予 約シナリオの場合に確実に当てはまる。しかしながら、幾つかのシナリオにおい て、現在のデータ値を得ることはそれ程重要でない。これは、例えば自動的な在 庫の監視および注文を容易にするためにスーパーマーケットのデータベースに全 ての商品の売り上げを記録するレジ（ＰＯＳ）端末あるいはティル（現金入れ引 出し）を使用するスーパーマーケットにおいて当てはまる。この場合において、 豆の缶詰が売れる度に、ティルはデータベースに売り上げを記録し、それはスー パーマーケットのチェーン店の本部のマスターデータベースに対するキャッシュ データベースとして動作する。各ティルがスーパーマーケットに残っている豆の 缶詰の数あるいはスーパーマーケットのチェーン店の豆の缶詰の在庫の数を知る ことは重要でない。それ故、キャッシュデータベースと本部のマスターデータベ ースとの間の更新データの一致性は不必要である。全てのデータは日毎に（キャ ッシュデータベースからマスターデータベースに）戻されて書込まれることがで き、それはスーパーマーケットのチェーン店に対する在庫の調整に適応させるの に適している。 しかしながら、本発明の目的に対しては、例えばフライト予約システム等の一 致するデータを要求するシステムだけが更新データに関連して考慮される。 データの一致性を確実にする１つの解決法は、全ての変更をそれらが行われて 直ぐにマスターデータベースに戻すことである。データの更新処理は、図７のフ ローチャートに関して以下に説明される。 図７によれば、ステップ700において、クライアント130は、特定のデータ行を 更新するためにファイルサーバ100に書込み要求を送信する。その要求は、新し い更新された行のコピーと、先に記憶された行のコピーの時間スタンプとを含ん でいる。ファイルサーバ100は、ステップ705において要求を受取る。ステップ71 0において、ファイルサーバ100は、ロックテーブル中に行のためのエントリを配 置することによってそのデータ行を別のクライアントによるアクセスからロック する。ステップ715において、ファイルサーバ100は、特定の行に対するインデッ クスエントリの時間スタンプを質問における時間スタンプと比較する。両方の時 間スタンプが同じである場合、マスターデータ行は行の更新されたバージョンに より重ね書きすることができ、それは明らかに元の記憶されたコピーが作られた ときからマスターデータ行に変更がないからである。反対に、時間スタンプが異 なっている場合、マスターデータ行は通常重ね書きすることができず、それは明 らかに元のキャッシュメモリに記憶されたコピーが生成されたときから マスターデータ行が変更されているからであり、従って、キャッシュ記憶された データ行への更新は、不一致データに基づいて行われる。 しかしながら、場合によっては、時間スタンプが異なっている場合でもマスタ ーデータ上に更新されたデータを重ね書きすることが依然として有効であること もある。キャッシュ記憶されたデータが現在のものでない場合でも更新が可能で ある場合の１つの例は、クライアントがフライトにおいて４つの座席を予約した い場合、キャッシュデータベース136は１００席の座席が利用可能であることを 知らせるが、マスターデータベース126が９０席しか空席でないと知らせた場合 であり、その場合、記憶されたデータが不一致であっても処理は依然として可能 である。しかしながら、クライアントがフライトにおいて１０席予約したい場合 、キャッシュデータベース136が１２席が利用可能であることを知らせ、マスタ ーデータベース126が３席しか残っていないと知らせた場合、処理は完了するこ とができない。実際には、ＤＢＭSソフトウェアは、処理が可能かどうかを見る ために試験を行う。 ステップ715において、マスターデータ行が有効に重ね書きできるとファイル サーバ100が判断した場合、ステップ720において行が重ね書きされ、その行に対 する新しい時間スタンプが発生され、取入れられる。その後、ステップ725にお いて、対応するインデックス中の時間スタンプは同じ値に修正される。ステップ 730において、修正された行およびインデックスはマスターデータベースのＳＧ Ａ105に記録される（周期的に、あるいはＳＧＡ105が一杯にされたとき、新しい マスターデータ行およびインデックスエントリは外部記憶装置120に戻されて書 込まれる。）ステップ735において、データ行は、ロックテーブルのエントリを 除去することによってロックを解除され、それによって別のクライアントによる アクセスに対して使用可能にされる。その後、ステップ740において、ファイル サーバ100は処理が完了したことをクライアントに知らせるためにクライアント に回答を送る。その回答は、修正された行およびインデックスの適切に割当てら れた時間スタンプと整合する時間スタンプ値を含んでいる。ステップ745におい てクライアントは回答を受取り、ステップ750において行を修正し、行の時間ス タンプを新しい時間スタンプで更新する。ステップ755において、クライア ント130はキャッシュデータベース136にその行を書込む。 ステップ715において要求された修正が行われることができない場合、ステッ プ760において、ファイルサーバ100は行のロックを解除し、ステップ765におい て適切な回答をクライアント130に送信する。現在のマスター行のコピーが応答 の中に含まれている。ステップ770においてクライアントは応答を受取り、ステ ップ775においてキャッシュデータベース136を現在の行で更新する。ステップ78 0において、クライアントには不一致を処理する作業が残されている。 上述の書込み手順によって、全てのクライアント130は、必要であれば現在の データにアクセスすることができる。しかしながら、この手順は、ファイルサー バ100上で従来のシステムにおいて通常要求されるものよりも余分な処理オーバ ーヘッドを生じる。余分なオーバーヘッドはステップ725において生じ、そこに おいてファイルサーバ100はインデックスの時間スタンプを更新するためにイン デックス220に書込まなければならない。通常は、インデックス220は、例えば新 しい記録の生成あるいは古い記録の削除等の幾つかの理由のために、データ表21 5における行データが再構成された場合にのみ書込まれる。 しかしながら、ＳＧＡのサイズが増加し、より多くのインデックスエントリが ＳＧＡ中に記憶されたとき、このオーバーヘッドは著しく減少する。 幾つかの実施形態において、データの行は、データベースの1または複数のペ ージ中に記憶された１つの組に配置されてもよい。これは、一般的にクライアン トが規則的に同時に幾つかのデータ行を扱う場合に当てはまる。その後、クライ アントは、毎度各行に対して別個の質問を要求するというよりもむしろ行の組を 読取る単一の質問を決定する。ファイルサーバ100は、この機能を支持するため に整合する組の定義を有している。組内の各行は、それ自体の時間スタンプを有 している。従って、その組の時間スタンプ全体が組の中の任意の行の最新の時間 スタンプであるとすることができる。この方法において、データベースシステム は、データが現在のものであるかどうかを判断するために各行の時間スタンプの 代りに組の時間スタンプを比較することが必要とされるだけである。しかしなが ら、これによって別のクライアントが別のクライアントの組に含まれた行を削除 した場合に最新の時間スタンプが登録されないという問題が生じ、行が除去され ると、時間スタンプが行く所がなくなる。それ故、組の時間スタンプは、その組 が（削除によって）修正されても同じままである。 この問題に対する１つの解決方法は、幾つかの形態の循環的冗長検査（ＣＲＣ ）アルゴリズムを使用して、組の中の行の何がしかの性質（プロパティ）のＣＲ Ｃあるいは組の中の行へのインデックスエントリが変更しないことを確実にする ことである。コードは、時間スタンプフィールドそれ自体あるいは特定のフィー ルドに組込める。例えば、３２ビットのＣＲＣ検査では、4,294,967,296分の１ の割合で検出されないエラーを生じる。 今までのところ、この説明において本発明は複数のクライアントがマスターデ ータベースにアクセスするいわゆる２層計算環境に関連して説明されてきた。し かしながら、本発明は決してそのようなシステムにおける使用に限定されるもの ではない。例えば、本発明は多重層システムにおいて実行されることができる。 そのような多重層システムの１つが図８に示されている。 図８において、バックエンドファイルサーバ800は、ハードディスク駆動装置8 05上でマスターデータベースを支持する。ファイルサーバ800の動作は図１にお けるファイルサーバ100と等しい。ファイルサーバは、ＩＢＭメインフレームコ ンピュータであってもよい。バックエンドファイルサーバ800は、キャッシュデ ータベースのための記憶領域を含んでいるハードディスク駆動装置820をそれぞ れが有している中間層ファイルサーバ815にネットワーク810によって接続されて いる。中間層ファイルサーバは、ＵＮＩＸベースの計算プラットフォームであっ てもよい。ネットワーク810は、ＡＴＭプロトコルを支持する個人回路接続を具 備している国際的なネットワークである。中間層ファイルサーバ815は、図１の クライアント130に類似した方法でバックエンドファイルサーバ800に関して動作 する。 各中間層ファイルサーバ815には適切なネットワーク825を介して１以上のクラ イアント830が所属している。適切なネットワークは、例えばパケット交換デー タネットワーク等の国のネットワークを含んでいてもよい。クライアントは、例 えばＩＢＭ互換性ＰＣであってもよい。 この例において、クライアント830は、中間層ファイルサーバ815を介してバ ックエンドファイルサーバ800中のデータにアクセスする。クライアント830は、 中間層ファイルサーバ815とバックエンドファイルサーバ800との間の関係が見え ず、すなわち、その関係はクライアントには透明であると言われている。 そのようなシステムがいつ実行されるかについての一例は、ロンドンにローカ ルメインオフィス（中間層ファイルサーバＡ）を、香港にローカルメインオフィ ス（中間層ファイルサーバＢ）を、およびミュンヘンに本部（中間層ファイルサ ーバＣおよびバックエンドファイルサーバ800）を有する国際企業に関して説明 される。クライアント835は、国内ネットワーク825を介してローカルメインオフ ィスに接続されたそれぞれの地域的なオフィスに位置している。 この例において、企業のマスターデータベースは、本部におけるバックエンド ファイルサーバ800上に保持されている。従って、クライアント830による静的デ ータへのアクセスは中間ファイルサーバ820のキャッシュデータベースから導か れ、必要なデータが定期的（例えば１日のベース）あるいは要求されたときにア ップロードされる。より動的なデータへのアクセスは、図６および図７それぞれ に関連して説明された読取りおよび書込み処理を使用して、中間層ファイルサー バ815を介してバックエンドファイルサーバ800から行われる。従って、クライア ント830によるバックエンドファイルサーバ800への他の国との間の直接のアクセ スは、動的データが重大な関与をする形で取引が行われることを求められるもの に限定される。再び、フライトの予約がそのような処理の例として挙げられる。 本発明が実行される別の可能なシステムが図９に示されている。 図９に示された構成は図８を変更したものである。異なっている点は中間シス テム908を含んでいることである。中間システム908は事実上、バックエンドファ イルサーバ900データベースと中間層ファイルサーバ915との間のインターフェイ スである。中間システム908は、通常ファイルサーバ900への別個の計算プラット フォーム上に存在している。中間システム908は、例えばレガシー（legacy）デ ータベースシステム等のバックエンドデータベースから得られるデータの形式を 中間層ファイルサーバ915およびそれらのクライアント930によって読取り可能な データの形式に変換する。そのような構成はまた、中間層あるいはクラ イアントのシステムの技術によって必要とされるデータが変更した場合にも有効 である。その後、一般的に非常に高価で複雑なバックエンドデータベースシステ ムをアップグレードする必要があるというよりも、むしろ変化に適合するために 中間システムだけがアップグレードされる必要がある。 図８に示されたシステムにおける別の変形は、中間システムを各中間層ファイ ルサーバ上の処理として取入れることである。これは専用の中間計算プラットフ ォームの必要を除去するという利点があるが、アップグレードの場合には１以上 の中間処理を修正する必要があるという欠点を有している。 図８および図９に示されたシステムにおけるさらに別の変更は、１以上のクラ イアント830および930が自分のハードディスク駆動装置835および935上に自分の キャッシュデータベースを有していることである。この方法において、クライア ントは、中間層あるいはバックエンドデータベースからの一般に静的データであ るデータのコピーを保持することができる。しかしながら、キャッシュの一致性 が維持される限り、動的データは例えば図６および図７にそれぞれ示された読取 りおよび書込み手順等を使用することによってクライアントのキャッシュデータ ベース中に記憶されることができる。 図１０ａは、本発明の３層の実施形態を試験するための試験ハーネスを示して いる。ハーネスは、外部ディスク駆動装置上に記憶されたマスターオラクルデー タベース1010を支持するバックエンドファイルサーバ1000を備えており、全ての マスターデータベースへのアクセスは、バックエンドファイルサーバ1000によっ て制御されている。マスターデータベース1010は、データのマスターバージョン を保持している。中間層ファイルサーバ1020は、１０メガビット／秒の８０２． ３ １０ベースＴ通信リンクを介してバックエンドファイルサーバに接続されて いる。中間層ファイルサーバ1020は、外部ディスク駆動装置上に永続的にデータ を記憶するオラクルキャッシュデータベース1030を支持するが、それはまた主メ モリにおける最近使用されたデータも記憶する。クライアント1040は中間層ファ イルサーバ1020に接続されており、試験結果記録装置1050を有している。クライ アント1040は論理的に別個に示されているが、実際には試験の目的のために中間 層ファイルサーバ上に置かれている。 中間層ファイルサーバ1020は、記憶プロセスおよびバックエンドファイルサー バ1000へのアクセスの両方を制御する。クライアント1040は、以下に説明される 性能試験を制御し、累積された試験結果を照合して記憶する。 試験ハーネスは、バックエンドファイルサーバ1000と中間層ファイルサーバ10 20との間で情報を搬送するための通信機構としてオービックス(Orbix)（ＴＭ） を使用する。中間層ファイルサーバ1020およびバックエンドファイルサーバ1000 は両方ともＳＵＮ（ＴＭ）ＳＰＡＲＣステーション20コンピュータシステムであ る。しかしながら、実際には、中間層ファイルサーバ1020はＳＰＡＲＣステーシ ョン20であってもよいが、バックエンドファイルサーバ1000は大きいＵｎｉｘ（ ＴＭ）ベースのファイルサーバあるいはＩＢＭメインフレームファイルサーバで あるほうがより好ましい。中間層ファイルサーバ1030およびバックエンドファイ ルサーバ1000は、オラクル(Orac1e)（ＴＭ）とＣおよびＣ⁺⁺プログラミング言語 で書込まれたソフトウェアルーチンであるキャッシュ制御機構との間のインター フェイスとしてＰｒｏＣ（ＴＭ）を使用する。バックエンドファイルサーバ1000 は、バーチャルメモリ中に保持されたＳＧＡ（図示されていない）を有しており 、それは通常、十分に同調されたシステム中の主メモリ（ＲＡＭ）において使用 される。マスターデータベースに対して行われたそれぞれの読取りアクセスは、 マスターデータベースから読取られたデータがＳＧＡに存在していない場合、そ れをＳＧＡにコピーする効果がある。この関係はより詳細に説明される。 全ての試験はマスターデータベース910中に記憶された５０ＭＢの表に基づい ている。この表は２５０，０００行のデータを含んでいた。各行は以下のように 配置されていた。 各行は、８桁の数字のアイデンティティ（ＩＤ）、８桁の数字のバージョンお よび２００個のデータカラムを有しており、各データカラムは１つのキャラクタ を含んでいた。 各行は対応するインデックスエントリを有していたが、既に言及されているよ うに、オラクルのためのインデックスは、データ行における“キー”フィールド 上で迅速にサーチするために最適にされたＢツリーとして構成されてもよい。Ｂ ツリーによる方法の１つの利点は、サーチ時間がインデックスをつけられた表の サイズと共に急速に増加しないことである。 インデックスは、照会された各行に対してインデックスが行のアドレスおよび バージョン番号（あるいは時間スタンプ）の両方を含むように生成される。この 構成の効果は、クライアント（すなわち、中間層ファイルサーバ）がマスターデ ータベース中に記憶された行のバージョン番号を要求するときにはいつでも、バ ックエンドファイルサーバがその行に対するインデックスを検索し、それをして いる際にインデックス内の行のバージョン番号を見つけることである。インデッ クス中のバージョン番号を認識すると、バックエンドファイルサーバはインデッ クスを検索するために実際のデータの行にアクセスすることはない。 試験は、１乃至２００個の範囲の様々な数のカラムを１０段階で検索するため に無作為に表にアクセスすることによって実行された。ランダムなアクセスは、 それが比較的現実的であると考えられるために選択されたものであり、その理由 は、特に順次のアクセスに基づいた統計がオラクル（ＴＭ）の内部ＳＧＡキャッ シュ機構によって歪まされるためである。 試験は、以下のシナリオ内で実行される。 キャッシュ記憶せず； 空のキャッシュデータベースにキャッシュ記憶し； 充満したキャッシュデータベースにＳＧＡ中の未知のデータをキャッシュ記憶 し； 充満したキャッシュデータベースにＳＧＡ中のオラクル（ＴＭ）インデックス をキャッシュ記憶する。 図１０ｂにおける構成は、クライアントをファイルサーバ試験に導くための基 本となるものである。この構成は、マスターデータベース1070を有するファイル サーバ1060を備えている。ファイルサーバ1060は、オービックス（ＴＭ）ベース の通信リンクを介してクライアント1080に接続される。クライアント1080は、試 験結果記録1090を有している。このシナリオにおいて、キャッシュ記憶技術は、 クライアントがアクセスするためのキャッシュ記憶されたデータを有していない ために使用されない。代りに、クライアント1080による通信およびデータの検索 は常にファイルサーバ1060へおよびファイルサーバ1060から導かれ、そこにおい てファイルサーバはマスターデータベース1070におけるクライアントによって要 求されたデータにアクセスする。それ故、マスターデータベース1070中のデータ は、クライアント1080がデータを要求する毎にアクセスされる。この試験シナリ オから得られた結果は、以下に説明されるキャッシュ記憶を使用するシナリオに よる試験結果と比較するためのベースラインとして使用される。 第２の試験シナリオはキャッシュを使用するが、キャッシュデータベース1030 中には記憶されたデータがない状態で開始される。従って、中間層ファイルサー バ1020は、バックエンドファイルサーバ1020からの全てのデータを検索しなけれ ばならない。これはキャッシュ技術にとって最悪な場合のシナリオである。その ような場合、データはバックエンドファイルサーバ1000から検索され、キャッシ ュデータベース1030に書込まなければならない。これは、データがキャッシュデ ータベース1030にない場合、あるいはキャッシュデータベース中のデータが一致 しない場合のいずれかにおいて生じる。 第３のシナリオは、キャッシュデータベース1030がマスターデータベース1010 上に保持されたデータと同一のデータを含むように構成された。しかしながら、 このシナリオにおいて、バックエンドファイルサーバ1000のＳＧＡにおいて開始 されるデータへの制御はなかった。すなわち、ＩＤおよび各データベース表の行 のバージョンを含んでいるインデックスは、バックエンドファイルサーバ1000の 主メモリに固定されていなかった。それ故、潜在的に、バックエンドファイルサ ーバ1000は要求されたデータおよびそれぞれのインデックスをマスターデータべ ース1010から検索し、それらを各試験中に数回にわたってＳＧＡに位置させる必 要があった。 最後のシナリオにおいて、先のシナリオのように、中間層ファイルサーバ1020 上のキャッシュデータベース1030は、マスターデータベース1010上に保持された データと同一のデータを含んでいた。しかしながら今回、インデックスはバック エンドファイルサーバ1000上のＳＧＡに意図的に配置された。これは、試験が実 行される前にバックエンドファイルサーバ1000から順次ＩＤおよびマスターデー タベース1010上のマスターデータの各行の時間スタンプ（しかしながらデータそ れ自体ではない）にアクセスすることによって達成された。これは、データベー ス表からアクセスされた各データベース行に対してＳＡＧ中にインデックスエン トリを生成する効果があった。インデックス全体をＳＧＡにコピーすると、イン デックスがＳＧＡ中にない場合、あるいはインデックスが部分的にしかＳＧＡ中 にない場合に比較して、インデックスはマスターデータのバージョンと記憶され た中間層データのバージョンとをより迅速により効果的に比較するためにアクセ スされることができる。すなわち、インデックスがＳＧＡ中にある場合、ファイ ルサーバは、ディスクをマスターデータベース1010にアクセスさせる必要がある 代りに、バージョンを比較するために主メモリをアクセスさせる必要があるだけ である。 試験から得られた結果は、バックエンドファイルサーバ1000上でのＣＰＵの使 用およびバックエンドファイルサーバ1000とマスターデータベース1010との間の 入力／出力（Ｉ／Ｏ）との関係を調べられた。ＣＰＵの使用は、呼を生成するプ ロセスによって使用されたＣＰＵ時間を測定するＵＮＩＸ“クロック”システム の呼を使用して測定された。Ｉ／Ｏは、試験のために使用されたオラクル（ＴＭ ）表のスペースにおけるＩ／Ｏの活動の測定をエネーブルにするオラクル（ＴＭ ）ビュー、“ｖ＄ファイルスタット”(filestat)を使用して測定された。 図１１は、キャッシュを使用しないシナリオ、フルキャッシュを利用するシナ リオ、および空のキャッシュを利用するシナリオに対するＣＰＵの利用の比較を 示すグラフである。グラフは、直接的なクライアント／サーバの場合（キャッシ ュがない場合）と比較して、キャッシュが十分に利用された場合にはＣＰＵの利 用が著しく良好であることを示している。利用は、検索されたデータの複雑さ（ 読取られたカラムの数）が低いときには類似している。しかしながら、複雑さが 増加すると、フルキャッシュの構成の利点が明らかとなる。グラフからわかるよ うに、データがバックエンドファイルサーバ1000から検索されなければならない とき、キャッシュが空あるいは不一致の場合にはぺナルティが課せられる。これ らの結果は、インデックス中にバージョンあるいは時間スタンプを取入れること によって、インデックスエントリがＳＧＡあるいはマスターデータベース中にあ るか否かに関係なく、ＣＰＵ処理オーバーヘッドが大幅に減少されるということ を示している。明らかに、多数の中間層ファイルサーバあるいはクライアントが ほぼ同時にファイルサーバにアクセスしようとしている場合には、性能における この改良は特に著しい。 実験を実行する際に、図１１においてグラフで示された結果がオービックス（ ＴＭ）とオラクル（ＴＭ）のＣＰＵの利用を組合わせたものを示していることは 本発明の発明者によって認識されている。以下に示されているように、データベ ースにアクセスするためだけにオラクル（ＴＭ）を使用してＣＰＵを利用するこ とが種々のキャッシュを使用するおよびキャッシュのない構成によってどのよう に影響を受けるかを決定するためにさらに試験が行われた。 図１２は、処理のオービックス（ＴＭ）部分だけに対するＣＰＵの利用が示さ れている。図１３は、オラクル（ＴＭ）データベース処理だけのためのファイル サーバ上でのＣＰＵの利用を示している。図１２および図１３においてグラフで 示された組み合わされたデータは、図１１においてグラフで示されたデータに厳 密に整合し、それは別個の試験が正確に構成されているかどうかの良好なレベル となる。 図１３にグラフで示されたデータは、充満した一致したキャッシュの状況とキ ャッシュなし、または空のキャッシュあるいは不一致のキャッシュの状況との間 の違いをより一層明らかに示している。複雑さの程度が高い場合、中間層におい てキャッシュに記憶されたデータを使用することによってＣＰＵの利用を４倍減 少できることが示されている。 また、図１３から明らかなように、データがファイルサーバにおけるマスター データベースから検索されなければならないとき、キャッシュ記憶技術の使用に おいて固定されたオーバーヘッドが存在する。データの複雑さの程度が低いとき 、オーバーヘッドは時間全体のかなりの割合を占めるが、複雑さの程度が増加す るにつれ、オーバーヘッドは全体の割合において減少する。すなわち、１つのデ ータカラムに対してオーバーヘッドはアクセス時間全体の約１／２であり、２０ ０のデータカラムに対してオーバーヘッドは全アクセス時間の約１／６である。 この情報に基づいて、オービックスがＣＰＵの時間を高い割合で使用している ことは明らかである。実際、オービックスは、高いＣＰＵオーバーヘッドを生じ る複雑な通信機構であることで知られている。それ故、例えばＵｎｉｘの“ソケ ット”方式等のより簡単な通信機構を使用することによって、ＣＰＵオーバーヘ ッドは通信処理に関して著しく減少されることができ、それによってＣＰＵ全体 の効率が大幅に向上すると考えられる。 キャッシュ記憶技術の使用によって、データが中間層ファイルサーバ中に正確 に記憶される場合にＩ／Ｏに著しく利益が与えられることが予想される。図１４ のグラフは、読取りの複雑さに対する読取りの数を表している。このグラフは、 クライアント／サーバが直接アクセスする場合と、キャッシュが空あるいは不一 致である場合の両方について、読取りが複雑さとは関係なく顕著なレベルで動作 することを示している。他方、キャッシュが充満し、一致している場合、読取り は複雑さと共に減少する。しかしながら、これは使用された実験方法による人為 的なものである。上述の説明の要点を述べると、充満したキャッシュの場合、イ ンデックスだけがアクセスされ、インデックスは約６ＭＢの大きさである。表か らの行あるいはインデックスエントリが読取られる毎に、行あるいはエントリを 含んでいるブロックあるいはページ全体がデータバッファキャッシュと呼ばれる ＳＧＡ中の領域に実際上移される。ブロックは典型的に２０４８バイトの大きさ であり、それ故おおよそ１０個のデータ行を含んでいる。データバッファキャッ シュの大きさは約８ＭＢである。それ故、より多くのインデックスエントリが読 取られるにつれ、高い割合でインデックスがデータバッファキャッシュ中で見つ けられ、また、それぞれ高い割合でインデックスを検索するには、主メモリへア クセスするだけで十分である。制限内でインデックス全体が読取られ、別の処理 がマスターデータベースから読取られないあるいはそこへ書込まれない場合、イ ンデックス全体がＳＧＡのデータバッファキャッシュ領域にコピーされる。その 時、Ｉ／Ｏは要求されない。図１５は、この理論が正しいことを示す試験結果を 表したグラフである。グラフからわかるように、完全なインデックスがＳＧＡ中 にあるときには読取りはなく、インデックスが初めにＳＧＡ中にないときには読 取りは減少する。 全体的な結果は、キャッシュ技術によって、インデックスエントリ中にバージ ョン番号を有した結果ＣＰＵオーバーヘッドが減少することを示している。また 、読取りオーバーヘッドは、より多くのインデックスエントリがＳＧＡに移動す るにつれ減少する。クライアントが多数いる状況の下では詳細な検査は行われな かったが、ＣＰＵオーバーヘッドおよび読取りの要求の両方が減少すると、ファ イルサーバの性能およびクライアントに対する応答時間が改良されると仮定する のが妥当である。実際に、性能の改良は、より多くのクライアントあるいは中間 層ファイルサーバがファイルサーバに接続されてバックエンドのマスターデータ ベースにアクセスするとき、一層顕著となる。また、例えばユーザの認証あるい はデータベースのハウスキーピング等の、ファイルサーバによって制御された別 の手順によってもＣＰＵおよびデータベースへのアクセス動作の両方が増加する ことから利益を得ることができる。 最後に、上述の新しいキャッシュ記憶技術から最大の利益を得るために、高性 能の通信機構を選択することが重要であることもこの結果から示される。 本発明がキャッシュデータベースを備えた任意の環境あるいはそれに相当する ものに適用可能であることは当業者によって理解されるであろう。本発明の使用 の判断は、純粋に本発明が性能に関して最適なシステムを提供するかどうかに依 存している。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｇ０６Ｆ 15/40 ３５０Ｂ

Claims (1)

1. 【特許請求の範囲】 １．キャッシュデータベース中のデータアイテム関連して記憶された第１のキー と、マスターデータベース中のデータの各アイテムに対するインデックスエント リーと関連して記憶された第２のキーとを比較することによりマスターデータベ ース中のデータの各アイテムとキャッシュデータベース中のデータのアイテムの 一致性を検査する検査方法。 ２．キャッシュまたはマスターデータベースの１つからのデータアイテムを検索 する方法において、マスターデータベースはマスターデータの複数のアイテムか ら構成され、インデックスはマスターデータの１以上のアイテムに対応するエン トリを含み、キャッシュデータベースはマスターデータの１以上のアイテムのキ ャッシュに記憶されたコピーを含み、 キャッシュデータベースからデータの要求されたアイテムのキャッシュに記憶 されたコピーに関連して記憶された第１のキーを読取り、 マスターデータベースからマスターデータの各アイテムに対するインデックス エントリに関連して記憶された第２のキーを読取り、 第１のキーと第２のキーとを比較し、 第１のキーと第２のキーとが同じ場合にデータのアイテムのキャッシュに記憶 されたコピーを検索し、第１のキーと第２のキーとが異なる場合にマスターデー タの各アイテムを検索するステップを含んでいるデータアイテムの検索方法。 ３．第１および第２のキーが時間スタンプである請求項１または２記載の方法。 ４．クライアント／サーバシステムにおける請求項１または２記載の方法の使用 。 ５．データベース中に記憶されたデータのアイテムに対するそのデータのアイテ ムの前に検索されたコピーからの第１のキーを含む条件読取り要求を受信する入 力手段と、 データベースのインデックスにアクセスし、情報の記憶されたアイテムに対す る第２のキーを含むデータの要求されたアイテムに対するインデックスエントリ を読取る手段と、 第１のキーと第２のキーとを比較する手段と、 第１のキーと第２のキーとが同じ場合にデータのアイテムの前に検索されたコ ピーが一致していることの指示を戻し、第１のキーと第２のキーとが異なる場合 にデータベースから読取り、データのアイテムのコピーを戻す手段とを具備して いるデータベースファイルサーバ装置。 ６．インデックス中の少なくとも１つのインデックスエントリが、 データベース中の情報のアイテムを識別する識別情報と、 情報のアイテムのデータベース中の位置を示す位置情報と、 データベース中の各情報が変化する都度変化するバージョン情報とを少なくと も含んでいるデータベースインデックス。