JP2002540502A - データベースシステムにおけるバーチャルメモリマッピングとトランザクションマネージメントのポインターリロケーションオプチミゼーションの方法及び装置 - Google Patents

Abstract

(57)【要約】 オブジェクト型のデータベースシステムに使用する装置であって、バーチャルメモリマッピングとトランザクションマネージメントを行うものであり、少なくとも１つの永久保存と少なくとも１つのデータベースと、少なくとも１つのキャッシュと、処理ユニットとを含んでいる。この処理ユニットはバーチャルアドレスを利用してキャッシュのデータにアクセスする手段と、バーチャルを物理的アドレスにマッピングする手段と、トランザクション後にキャッシュデータを保持する手段とを備えている。一般的に保持されたデータはさらなる翻訳を不要としている。キャッシュデータをトランザクションで使用可能とすることはリロケーション最良化と呼称される。この方法は使用の最近度の順序で並べられたエンティティを含んだ列を使用し、古いバインディングのアドレススペースをリサイクルし、クライエントアプリケーションの適正なファンクションに必要なバインディングの有効性を保存する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する分野】

本願発明はコンピュータシステムに関し、特にはパーシステントデータ(persi
stent data)を有した複数のキャッシュ部(cache)を有したバーチャルメモリマッ
ピングを使用したデータベースシステムのポインターマネージメントに関する。

【０００２】 関連出願の解説 本願は１９９９年３月２５日出願の米国仮特許願第６０/１２６１０３号の優
先権を主張する。

【０００３】

【従来の技術】

オブジェクト(object-oriented)型データベースシステムにおいて、並びに多
数の相互関連オブジェクトを有した他のシステムにおいては、ポインター(point
er)とも呼称されるインターオブジェクトリファレンス(inter-object reference
)は保存されたオブジェクトにアクセスを提供する複雑な構造を提供する。オブ
ジェクト型データベースにアクセスする際にアプリケーションプログラムは、デ
ータベースの関連クウェリー(query)とダイレクトトラバーサル(direct travers
al)を使用してオブジェクト間の複雑な接続を利用してオブジェクトにアクセス
して更新し、各オブジェクトがアクセスされるときに計算を実行することで時間
をかける。

【０００４】 オブジェクト型データベースの典型的なアプリケーション領域はコンピュータ
エイドデザイン、製造、エンジニアリング、ソフトウェア開発、電子パブリケー
ション、マルチメディアオフィースオートメーション、及び地理的インフォメー
ションシステムである。これらアプリケーション環境はオブジェクト型データベ
ースシステムが迅速であることを要求する。

【０００５】 典型的なオブジェクト型データベースシステムはサーバーを介してオブジェク
ト型データベースに接続された多数のワークステーションや他のタイプのクライ
エントコンピュータを有している。各クライエントコンピュータは自身のキャッ
シュメモリを有しており、クライエントアプリケーションプログラムが要求する
データが配置される。

【０００６】 全てのオブジェクト型データベースシステムはオブジェクトを識別する方法を
有している。現在、システムによっては“オブジェクトアイデンティファイヤー
”（ＯＩＤ）を使用する。これはレフェレンスをオブジェクトに具現化する。シ
ステムによってはポインターを使用する。“デレフェレンス処理”と呼ばれるオ
ペレーションはポインターをオブジェクトに従わせ、オブジェクトをリクエスト
するアプリケーションに利用可能にすることでオブジェクトを発見する。

【０００７】 データベースのデータへのアクセスはクライエントシステムのキャッシュメモ
リにデータをコピーすることが関与する。現行システムのキャッシュデータはト
ランザクションの完了後にしばしば放棄される。なぜなら、キャッシュデータを
レフェレンスするポインターは時代遅れだからである。キャッシュデータの放棄
はデータの整合性を確実にするが、クライエントとサーバーコンピュータとの間
のコミュニケーションを増加させる。またキャッシュの使用を促すローカリティ
(locality)の原理を利用させない。しかし、キャッシュのパーシステントなデー
タは、データとデータをレフェレンスするポインターとをデータベースと整合状
態に保つ方法を必要とする。

【０００８】 パーシステントなデータのキャッシュ処理を、デレフェレンスオペレーション
が高速で行えるような形態にするために、データレフェレンスポインターを更新
する方法を有することが望ましい。

【０００９】 本願発明の１目的は、オブジェクト型データベースシステムにおいてデータを
パーシステントにキャッシュ処理する方法と装置の提供である。

【００１０】 本願発明の別目的はキャッシュ処理されたデータのための最良ポインターリロ
ケーションを有する方法と装置の提供である。

【００１１】 本願発明の別目的はオブジェクト型データベースシステムのためのバーチャル
メモリマッピングアーキテクチャにおける最良ポインターリロケーションのため
の方法と装置の提供である。

【００１２】

【発明が解決しようとする課題】

パーシステントキャッシュ処理データのためのポインターリロケーション最良
化の問題は、データベースシステムにおけるバーチャルメモリマッピングとトラ
ンザクションマネージメントのポインターリロケーション最良化のための本願発
明の方法と装置により解消される。

【００１３】

【課題を解決するための手段】

データを保存する少なくとも１つの永久保存手段と少なくとも１つのデータベ
ースと、物理的アドレスでアドレスされたローカルにデータを保存する少なくと
も１つのキャッシュメモリと、キャッシュメモリ内のデータをアクセスするため
にバーチャルアドレスを利用してデータをリクエストする手段と、バーチャルア
ドレスを物理的アドレスにマッピングする手段と、トランザクションの終了後に
キャッシュデータを維持する手段とを含んだ処理ユニットとを有したオブジェク
ト型データベースシステムのためのバイチャルメモリマッピングとトランザクシ
ョンマネージメントのための装置と方法とが提供される。典型的には、このシス
テムは複数のクライエントコンピュータを有している。それぞれはネットワーク
で接続されたキャッシュメモリを有しており、各永久保存手段はサーバーコンピ
ュータを有している。１つのコンピュータはクライエントコンピュータとサーバ
ーコンピュータとして作用することができる。クライエントアプリケーションに
効率的なデレフェレンスオペレーションを提供するために装置はポインターをキ
ャッシュデータにリロケートすることで作動する。装置はさらにリロケートされ
たポインターをキャッシュに維持されたデータに対して連続的トランザクション
に維持することで作動する。ポインターリロケーション維持オペレーションの頻
度を最低に減少させることで装置はその最良利益を達成する。

【００１４】 リロケーションオペレーションは３つのカテゴリーに分割できる。すなわち、
インバウンドリロケーションと、フォーワードリロケーションと、アウトバウン
ドリロケーションである。インバウンドリロケーションには外部フォーマットか
らクライエントアプリケーションで使用できるフォーマットとステートへのペー
ジのポインターの翻訳が関与する。インバウンドリロケーションはクライエント
キャッシュに入るデータベースのリロケーションの発生ごとに発生する。フォー
ワードリロケーションはインバウンドリロケーションまたは前のフォーワードリ
ロケーションによって創出されたステートからのページのポインターの翻訳が関
与する。これはクライエントアプリケーションによって、現行的に利用できるス
テートには直ちに使用できない。特定のページのフォーワードリロケーションは
、ページがキャッシュに入るトランザクションではなく、ページが読み取りまた
は改正されるトランザクションの発生ごとに発生する。アウトバウンドリロケー
ションはクライエントアプリケーションによって使用が可能な形態から外部フォ
ームへの翻訳が関与する。特定ページのアウトバウンドリロケーションは連続的
なトランザクションの終了部で発生する。ここではページは変更される。あるい
は、変更ページはキャッシュから他の手段で取り戻されなければならない。本願
発明の利点はクライエントアプリケーションにより使用されるアドレスのマネー
ジメントであり、連続的トランザクションに必要なフォーワードリロケーション
の数を減少させることである。

【００１５】 本願発明は以下の解説からさらに理解されよう。

【本発明の実施の態様】

好適実施例の詳細な説明 図１から４はベーシックコンピュータシステムを表す。ここで本願発明のバー
チャルメモリマッピング方法と装置のためのポインターリロケーション最良化が
利用できる。

【００１６】 図１は複数のクライエントコンピュータ４０、クライエントとサーバコンピュ
ータ４２及びサーバコンピュータ４４がコンピュータネットワーク４６またはコ
ンピュータバス等の他のコンピュータ通信通路で接続されているシステムを図示
している。クライエントコンピュータ４０はユーザによって使用され、種々なア
プリケーションソフトをランする。サーバコンピュータ４４はデータベースで維
持されるデータの永久レポジトリとして作用する。一般的に、クライエントコン
ピュータ４０はサーバーコンピュータ４４に保存されたデータにアクセスできる
。コンピュータ４２はクライエントコンピュータとサーバーコンピュータとして
作用する。このようなコンピュータ４２は自身が保存するデータにアクセスでき
、他のサーバーコンピータ４４のデータにもアクセスできる。他のクライエント
コンピュータ４０はクライエントとサーバーのコンピュータ４２のデータにもア
クセスできる。本願発明のデータベース方法と装置は、少なくとも１つのクライ
エントとサーバーコンピュータ４２または少なくとも１つづつのクライエントコ
ンピュータ４０とサーバーコンピュータ４４をコンピュータネットワークまたは
通信通路４６で接続したシステムで使用できる。簡単にするため、クライエント
コンピュータ４０または、クライエントコンピュータとして作用するコンピュー
タ４２を“クライエント”と呼称し、サーバーコンピュータ４４またはサーバー
として作用するコンピュータ４２を“サーバー”と呼称する。

【００１７】 図２は単純化されたシステムの詳細図である。サーバーコンピュータ４４はデ
ィスクまたは他の大量保存媒体５２に接続されたＣＰＵ５０を含んでいる。これ
はデータの永久レポジトリである。ＣＰＵ５０はデータをディスク５２とネット
ワーク４６との間で移動させる。ＣＰＵ５４はキャッシュ５６の物理アドレスに
マップされたバーチャルアドレススペースをコントロールする。クライエントコ
ンピュータ４０で作動するアプリケーションはキャッシュメモリ５６内のデータ
の読み取り、書き込み、創出及び削除によってデータベースのデータを操作する
。クライエント４０は、キャッスメモリ５６のデータの全ての操作を行う。標準
データベースシステムでのようにサーバーコンピュータ４４に保存されたデータ
に対してコンピュータネットワーク４６でトラザクションを行うのではない。ト
ランザクションがキャッシュメモリ５６のデータに対してクライエントコンピュ
ータ４０で完了すると、このトランザクションの結果はネットワーク４６を介し
て永久レポジトリ、すなわちサーバーコンピュータ４４のディスク５２に伝達さ
れる。クライエントコンピュータ４０とサーバーコンピュータ４４の間の相互作
用の方法は通信ネットワーク上のサーバーコンピュータ４４とクライエントコン
ピュータ４０の数とに無関係で同じである。

【００１８】 図３は組み合わされたクライエントとサーバーコンピュータ４２の特殊なケー
スを図示する。このようなコンピュータは図２のクライエントコンピュータ４０
またはサーバーコンピュータ４４のいずれかとして使用できる。このようなコン
ピュータは典型的なコンピューｔｑ４４として、及び典型的なクライエントコン
ピュータ４０として図２に関連して説明するモードで作用する。

【００１９】 クライエントとサーバーコンピュータ４２はキャッシュメモリと永久データレ
ポジトリ５２の間での相互作用をもＣＰＵ６０を介して扱う。この相互作用はサ
ーバーコンピュータＣＰＵ５０、クライエントコンピュータＣＰＵ５４及び通信
ネットワーク４６の組み合わせ５８（図２）の相互作用と類似している。クライ
エントとサーバーコンピュータ４２のキャッシュメモリ５６は典型的なクライエ
ントコンピュータ４０のキャッシュメモリ５６として機能する。

【００２０】 図４はバーチャルメモリマッピングデータベース（ＶＭＭＤＢ）のモジュレー
ションと相互作用を図示する。クライエントコンピュータ４０またはクライエン
トとサーバーコンピュータ４２のＶＭＭＤＢ６６はそのオペレーションシステム
６８により提供されるサービスを利用する。ＶＭＭＤＢ６６はアプリケーション
プログラム６４で使用されるサービスを供給する。サーバーコンピュータ４４で
ＶＭＭＤＢ６６はオペレーションシステム６８と相互作用し、クライエントコン
ピュータからのリードとライトリクエストを扱い、データページのオーナーシッ
プをモニターする。

【００２１】 図５は少なくとも１つのデータベース７０へのデータ５２の永久レポジトリの
分割を図示する。各データベース７０は少なくとも１つのセグメント７４に分割
される。各セグメント７４は少なくとも１つのクラスター７３に分割される。各
クラスター７３は多数のページ７２を含んでいる。これらページはクラスター７
３から始まるページ数７１によりアドレスできる。各ページはページの最初から
オフセットによりアドレスされた多数のアドレス可能なロケーション（個々のバ
イト）を含んでいる。これらアドレス可能なロケーションはクラスターの最初か
らオフセットでアドレスされていると考えられる。そこで、このオフセットはペ
ージ内のアドレス可能なロケーション数をページ数に掛け算し、ページ内でオフ
セットを足し算することで計算される。すなわち、データベース内の各アドレス
可能なロケーションは次のアドレスを有している：［データベース、スグメント
、クラスター、オフセット］。アドレス可能なロケーション７２の配列はデータ
ベースアドレスに対応する値またはポインターを含むことができる。ポインター
は同一データベースの現行または他のページあるいは他のデータベースの他のペ
ージ内にポイントできる。クライエントアプリケーションがデータベースにアク
セスすると、ＶＭＭＤＢはクライエントアプリケーションがアクセスする必要が
あるデータベースのページにクライエントのバーチャルアドレススペースからバ
ーチャルアドレスを指定する。

【００２２】 図６はパーシステントリロケーションマップ（ＰＲＭ）１４０と、関連データ
ベースページ１４４のポインター１４２内へのＰＲＭ１４０のインデックス処理
を図示する。各ページはメタデータ構造と呼ばれる関連構造を有している。ペー
ジとメタデータ構造はページがアクセスされたときにはサーバーとクライエント
との間で通信される。サーバーはメタデータ構造とページとの組み合わせを維持
する。メタデータ構造はＰＲＭと様々なタッグを含んでいる。ＰＲＭとタッグは
ページのポインターのロケーションと翻訳とを解説する。ＰＲＭ１４０は複数の
エントリー（ＰＭＲＥ）１４６，１４８を有しており、それぞれデータページの
ページ内にインデックス処理する。データベースページのポインター１４２は４
バイト値（８バイト値も同様に利用可能）だる。ポインター１４２は２つのフィ
ールドに分割される。インデックスフィールド１５０とローオフセットフィール
ド１５２である。インデックスフィールド１５０は同じＰＲＭＥを有したページ
に次のポインターをインデックスするフィールドである。ローオフセットフィー
ルド１５２の機能は可能なアドレス可能ロケーションレフェレンセを１ＰＲＭＥ
で区別することである。これはターゲットクラスター内にて４メガバイトでアド
レスできる。ローオフセットフィールドはＰＲＭＥのハイオフセットフィールド
に加えられ、ターゲットクラスター内で使用する１つのオフセットを提供する。

【００２３】 各ＰＲＭＳ１４６、１４８はフラッグフィールド１５４、ハイオフセットフィ
ールド１５６、ナンバーフィールド１５８、インデックスフィールド１６０を有
している。フラッグは、新データベースインデックスフラッグ、新セグメントＩ
Ｄフラッグ、新クラスターＩＤフラッグ、及び新マッピンググラニュラーフラッ
グである。これらフラッグはどのフィールドがＰＲＭＥのヘッドワードに続くか
を示す。ヘッドワードのみを有するショートエントリーＰＲＭＥ１４６はナンバ
ーフィールド１５８の内容と等しいターゲットクラスターＩＤとなる。このナン
バーフィールド１５８は、ＰＲＭ、または、前のＰＲＭＥが存在しないときには
、現在アクセスされているページのクラスターＩＤを構成するＰＲＭＥの配列内
の前のＰＲＭＥのターゲットクラスターＩＤに加えられたものである。長いエン
トリーＰＲＭＥ１４８はヘッドワードと、続くフィールドを有している。これら
の追加フィールドはデータベースフィールド１６２、セグメントＩＤフィールド
１６４、クラスターＩＤフィールド１６６、及びマッピンググラニュラーフィー
ルド１６８である。これら追加フィールドはＰＲＭＥヘッドワードのナンバーフ
ィールド１５８と共にターゲットデータベース、セグメント、クラスターまたは
マッピンググラニュラーが配列の前のＰＲＭＥとどのように異なるのかを示す（
前のＰＲＭＥが存在しなければ現行のページ）。これら追加フィールドのそれぞ
れは、ＰＲＭ677\\\00Ｅヘッドワードの対応するフラッグが示すときのみ存在す
る。ＰＲＭエントリーがソーティングされ、類似ＰＲＭＥが並んでいるかぎり、
短いエントリーが使用できる。ＰＲＭＥヘッドワード内のヘッドポインターイン
デックス１６０から開始し、ポインターのインデックスフィールド１５０に進む
リストの各ポインターはターゲットデータベース、セグメント、クラスター、及
びマッピンググラニュラーをとり、ＰＲＭＥヘッドワードのハイオフセットフィ
ールド１５６と各ポインターのローオフセットフィールド１５２を組み合わせる
ことで計算される。グラニュラーフィールド１６８のマッピングの目的は６４ｋ
バイト、たとえば、１ｘ６４ｋ、２ｘ６４ｋ等々のユニットでターゲットによっ
て必要なアドレススペースの掛け算を示すことである。

【００２４】 図７はデータベースのクラスターを図示している。データベース７０の各クラ
スターはページに分割される。各ページはページの内容を説明するデータを含ん
だメタデータの構造と関連付けさせており、ページの各オブジェクトのタイプを
特定するタッグリストを含んでいる。オブジェクトはページでのみ発見される。
アプリケーションプログラムはページと直接アクセスし、メタデータとはアクセ
スしない。ベタデータがＶＭＭＤＢによってのみ使用される内部データ構造を維
持する。各クラスターは少なくとも１ページ８０に分割される。ページ８０のサ
イズはコンピュータハードウェアにより決定され、典型的には４０９６、８１９
２、または１６３８４バイトである。この場合、４０９６バイトページを想定し
ている。さらに大きなページは複数の４０９６バイトページにサブ分割できる。
クラスター７６内では典型的には３タイプの保存オブジェクトが存在する：シン
グルオブジェクト８２、オブジェクトのベクトル８４及びフリースペース８６で
ある。オブジェクトはポインターを示すことができる値を含むことができる。フ
リースペース８６は特別可変サイズオブジェクトとして理解できる。３タイプ以
上のオブジェクトが使用可能であるが、それら３つは代表例であり、本願発明の
実行には充分である。各オブジェクトに対して、タッグがページに関連する対応
メタデータ構造に配置される。シングルオブジェクト８２は対応するオブジェク
トタッグ８８を有している。オブジェクトのベクトル８８は対応するベクトルタ
ッグ９０を有するであろう。最後に、フリースペースオブジェクト８６は対応す
るフリースペースタッグ９２を有するであろう。

【００２５】 図８Ａから８Ｃは図７の各タッグの詳細を示す。オブジェクトタッグ８８（図
８Ａ）はタッグがシングルオブジェクトであることを示すフラッグフィールド１
００とタイプコードフィールド１０２を有している。タイプコードはオブジェク
トの特別な特性を説明し、多様なシングルオブジェクトを有することを可能にす
る。核タイプは自身の特徴を有する。タイプコードは図９と図１０に関してさら
に詳細に解説する。ベクトルタッグ９０（図８Ｂ）はタッグがベクトルに対する
ものであることを示すフラッグタッグ１０４と、タイプコード１０２に類似した
タイプコード１０６と、ベクトルの長さを示すレングスフィールド１０８とを有
している。最後に、フリースペースタッグ９２（図８Ｃ）はタッグがフリースペ
ース用であることを示すフラッグフィールド１１０と、フリースペースの長さを
示すレングスフィールド１１２を有している。

【００２６】 本願発明の好適実施例ではシングルオブジェクトフラッグ８８は２バイト長で
ある。ベクトルタッグ９０は６バイト長であり、追加４バイトはベクトルにその
数の要素を含んでいる。フリースペースタッグ９２は２バイト長である。本願発
明の実行に使用されるオブジェクトタイプとタッグの数は使用されるデータベー
スの種類と実行される操作のタイプに依存し、前述の例には限定されない。

【００２７】 図７に示すタッグテーブル９４はリロケーションが必要なデータベースアドレ
スを含んだページ内のロケーションの発見に使用される。タッグテーブルは各ペ
ージの内容がオブジェクトのエンドツーエンド配列を含んでいるという原理に基
づいている。これはクラスターの前及び/又は次のページにオーバーラップする
かも知れず、各オブジェクトは知られた数のタイプの１つである。この例では、
３タイプが存在する：（１）シンプルオブジェクト、（２）オブジェクトのベク
トル平面配列）、（３）フリースペースである。タッグテーブルはページ上のオ
ブジェクトの配列に直接対応するタッグの配列を含んだデータ構造とも言える。
ページの最初のオブジェクトが前のページにオーバーラップすれば、ページのメ
タデータのフィールドはオブジェクトのヘッドからページのヘッドまでのバイト
による距離を示すように私用される。

【００２８】 図９に示すデータベースの一部であるスキーマと呼ばれるデータ構造はタイプ
解説のセットを含んでいる。データベースの特定のオブジェクトタイプごとに１
つである。スキーマはバイトコード１０２と１０６（図８Ａから図８Ｃ）でイン
デックスされる。タイプ解説はオブジェクト内のポインター値のオブジェクトの
サイズとロケーションを示す。スキーマはデータベース内の自身のクラスターに
配分される。スキーマ１２０は対応するデータベースに含まれる各異なるオブジ
ェクトタイプ（タイプコードで指示）に対してタイプ解説１２２を含んでいる。
各タイプ解説１２２は１つのオブジェクトタイプを説明し、ユニークタイプコー
ド値がそれぞれに割り当てられている。オブジェクトタッグからのタイプコード
値１０２、１０６に対しては、ＶＭＭＤＢがタイプコードを使用してそのタイプ
に対応するタイプ解説１２２に対してスキーマ１２０にインデックスすることが
できる。

【００２９】 ページのメタデータはタッグテーブル９４とスキーマ１２０（タイプ解説１２
２を含む）を介してページ内の全てのポインターを追尾する。メタデータはパー
システントリロケーションマップでパーシステントアドレススペースのページ特
定配分をも追尾する。

【００３０】 図１０はタイプ解説１２２の内容を図示する。タイプ解説１２２はタイプコー
ドフィールド１２４でインデックスされており、そのタイプのオブジェクトのサ
イズを含むサイズフィールド１２８と、ポインターを含むそのタイプのオブジェ
クト内のどのロケーションかを示すフィールドセット１２８を含む。これらフィ
ールド１２８はＶＭＭＤＢより解釈され、オブジェクト内でポインターのロケー
ションを発見するインストラクション１３０のセットである。それらはハードウ
ェアＣＰＵが直接理解する機械インストラクションではない。

【００３１】 これらインストラクションの２種類が存在する：１つはポインターがオブジェ
クトタイプ内の特定オフセットに存在することを示し、他方はバーチャルファン
クションテーブルポインター（ＶＴＢＬ）がオブジェクトタイプの特定オフセッ
トで発見されたことを示す。（ＶＴＢＬポインターはＣ++言語の実行の一部であ
り、ＶＭＭＤＢがリロケーションを実行する特定タイプのポインターである。Ｖ
ＴＢＬはアプリケーションがバーチャルファンクションのコールに使用するファ
ンクションポインターのテーブルをポイントする。）

【００３２】 図１１はタイプ解説１２２からのインストラクション１３０（図１０）のフォ
ーマットである。それぞれのインストラクションはこのポイントがＶＴＢＬポイ
ンターであるか、リロケーションすべきポインターであるかを示すフィールド１
３２を有している。フィールド１３４はポインターが存在するオブジェクトの開
始からのオフセットを示す。

【００３３】 図１２はクライエントコンピュータ４０のキャッシュメモリ５６の構造と、キ
ャッシュメモリステータスをモニターするためのクライエントコンピュータＣＰ
Ｕ５４により使用されるキャッシュディレクトリと呼ばれる構造を図示する。ク
ライエントキャッシュメモリ５６はクライエントディスクの物理的キャッシュフ
ァイル内のページフレーム１７０のセットを含んでいる。またはクライエントデ
ィスクの作動システムのスワップファイルの一部内に存在するものである。各ペ
ージフレーム１７０はフリーであるか、データベースのページを有している。ク
ライエントコンピュータはキャッシュディレクトリを維持する。これはどのペー
ジフレーム１７０がデータベースページを含み、どのページがフリーであるのか
モニターする。２つのフレームは同じページを保持しない。データベースのペー
ジ、例えばページ“５”、クラスター“ｎ”、セグメント“４”、データベース
“/Ａ/Ｂ/Ｃ”を与えられると、ＶＭＭＤＢはキャッシュディレクトリ１８０を
使用してページ（ページの物理的ロケーション）を保持するページフレーム１７
０を効率的に決定し、またはそのページがキャッシュには存在しないことを決定
する。この目的で、キャッシュディレクトリ１８０はフレームフィールド１７２
を含む。これはページフレームの番号、及びクラスターＩＤ、セグメントＩＤ、
データベースインデックスによるフレーム内のページを特定するコンテンツフィ
ールド１７４を示す。ページがキャッシュになければエントリーはない。

【００３４】 キャッシュディレクトリ１８０の各ページフレーム１７０は４ステート値を有
している。最初の２つはキャッシュステート１７６とロックステート１７８を示
す。キャッシュステートは“リードのためにエンキャッシュ（ＥＲ）”でき、あ
るいは“ライトのためにエンキャッシュ（ＥＷ）”できる。ロックステートは“
アンロック（Ｕ）”、“リードのためにロック（ＬＲ）”、または“ライトのた
めにロック（ＬＷ）”できる。ページのステートがＥＷＬＲであると言うことは
それがライトのためにエンキャッシュされており、リードのためにロックされて
いることを意味する。ページがＥＲのステートであることは、リードのためにエ
ンキャッシュされており、アンロックされていることである。キャッシュディレ
クトリエントリの他の２つのフラッグは“ダンされたときにダウングレード”１
８２及び“ダンされたときにエビクト”と呼ばれる。これらフィールドの目的は
オペレーションのフローチャートに関して後述する。

【００３５】 図１３はオーナーシップテーブルを示す。サーバー４４はどのクライエント４
０がデータベースからページのコピーを有しているか、そのページはリードのた
め、またはライトのためにエンキャッシュされているかの追尾を行う。サーバー
はオーナーシップテーブルでデータベースの使用をモニターする。オーナーシッ
プテーブル１９０は３フィールドを含んだエントリー１９２を含んでいる。コン
テンツフィールド１９４はページ、クラスター番号、セグメント番号及びデータ
ベースネームを示す。オーナーフィールド１９６はどのクライエントが現在その
ページを使用しているか示す。オーナーフィールドは好適にはクライエントネー
ムのアレイである。ステータスフィールド１９８はページがリードまたはライト
のためにエンキャッシュされているかどうかを示す。１つの値のみの保存が必要
である。なぜなら、全てのクライエントはリードのためにエンキャッシュされた
ページを有するか、１つのクライエントがライトのためにエンキャッシュされた
ページを有するからである。

【００３６】 キャッシュディレクトリ１８０とオーナーシップテーブル１９０の組み合わせ
はキャッシュコヒーレンシーを維持する。クライエントプロセスは、ページを有
するページフレームがクライエントによるライトのためにロックされているなら
、ページの内容を修正することができるだけである。ページフレームはライトの
ためにエンキャッシュされているならライトのためにロックできるだけである。
このステータスの確認とロッキングはクライエントでキャッシュディレクトリを
使用して実行される。クライエントがライトのためにエンキャッシュされたペー
ジフレームを有していれば、他のクライエントコンピュータはそのキャッシュに
同じページを有することができる。多くのクライエントがリードのためにエンキ
ャッシュされたページのコピーを有することは可能であるが、一時に１クライエ
ントのみがライトのためにエンキャッシュされたページのコピーを有することが
できる。エンキャッシュされたステータスの確認はオーナーシップテーブルを使
用してサーバーにより実行される。クライエントコンピュータでトランザクショ
ンが進行していなければ、キャッシュの全ページフレームはアンロックされる。
トランザクションが進行中であれば、ロックされたページはアンロックできない
。ライトのためにロックされたページはリードのためにロックできない。すなわ
ち、ページはリードからライトにロックまたはアップグレードできる。ロックは
トランザクションがコミットするときにリリースされる。このルールはデータベ
ース用の標準２フェーズロッキングルールに対応する。

【００３７】 ２フェーズロッキングの形態の利点は、サーバーコンピュータではなくクライ
エントコンピュータでロックのモニターをする点である。さらに、データはサー
バーではなくてクライエントでキャッシュされ、使用される。ロッキング情報の
サーバーへの送付のオーバーヘッドは低減される。よって、データはサーバーへ
のエクストラコールなしで１トランザクション以上に使用できる。すなわち、こ
のキャッシュ戦略はトランザクションのクライエント内でのページを維持するこ
とを可能にする。ページアドレス方法の追加はクライエントに残るページのアク
セスを高速にする。これが本願発明の主たる利点である。２フェーズロックの標
準特徴は全てのデータが利用可能になるまでのライトロックの妨害を含んで使用
可能である。

【００３８】 ページがクライエントキャッシュメモリ５６に入れられた後、そのページの全
てのポインターのターゲットは図１４に示すようにクライエントコンピュータＣ
ＰＵのバーチャルアドレススペース２００のローケーションを割り当てられなけ
ればならない。ポインターは、そのデータがバーチャルメモリにマップされ、ク
ライエントアプリケーションで使用される前に翻訳されなければならない。この
プロセスはインバウンドリロケーションと呼ばれる。この割り当てはバーチャル
アドレスマップ（ＶＡＭ）と呼ばれる現在のアドレスバインディングセット２１
０を使用して、どのデータベース、セグメント、クラスター、オフセット、レン
グスがクライエントのバーチャルアドレススペースの特定部分に割り当てられた
かを示すエントリー２１２で管理される。インバウンドリロケーション中のポイ
ンターの翻訳は、ポインターのターゲットに対して１つが存在するなら存在する
バーチャルアドレスマップエントリーの使用を必要とする。または、ターゲット
の新ＶＡＭＥの構築とＶＡＭへのＶＡＭＥの採用を必要とする。翻訳はさらに、
クライエントのバーチャルアドレススペースの領域がＶＡＭＥに割り当てられる
ことも要求する。ポインターの翻訳は、ポインターのローオフセットフィールド
とＰＲＭＥナンバーフィールド、ハイオフセット及び/又はクラスター内でオフ
セットフィールドからＶＡＭＥのオフセットを差し引いたものに等しいバーチャ
ルアドレススペースの割り当てられた領域のトップからのオフセットとして計算
されたポインターのためのバーチャルアドレスのポインターへの書き込みができ
る。

【００３９】 バウンドまたは割り当てられたＤＳＣＯハンドルとも呼ばれるバーチャルアド
レスマップエントリー（ＶＡＭＥ）２１２はパーシステントリロケーションマッ
プ１４０（図６）のエントリー１４６、１４８に類似している。バーチャルアド
レスマップ２１０はバーチャルアドレススペース２００の領域を示す。これはデ
ータベース領域が割り当てられたところである。パーシステントリロケーション
マップ１４０はデータベースアドレススペースの領域を示す。各ＶＡＭエントリ
ー２１２はデータベース２１４を含む。これは領域が存在し、領域がロケーショ
ンされるセグメントを示すセグメントフィールド２１６を示すデータベースを示
す。さらに、クラスターを示すクラスターフィールド２１７とオフセットフィー
ルド２１８が含まれる。サイズフィールド２２０とアドレスフィールド２２２も
含まれる。

【００４０】 キャッシュ内のデータページにアクセスためのアプリケーションでは、データ
を仮想メモリーにマッピング処理する必要がある。図１５には、顧客コンピュー
タによるマッピング処理の後での、（顧客ディスク上の別のファイルとして、あ
るいは、顧客のスワップファイルの一部として一般的に実行される）キャッシュ
５６に対する仮想アドレス域２００の関係が図示されている。仮想メモリーマッ
プ２２４は、ほとんどのコンピュータシステムにおける標準方法で、顧客コンピ
ュータのオペレーションシステム６８により作成できる。その仮想メモリーマッ
プには、仮想アドレスがマッピングされるキャッシュファイルアドレスが示され
ている。仮想メモリーマップは、普通、各ベージの仮想アドレス２２５、長さ２
２６、対応するキャッシュファイル位置２２８、読取書込み保護状態２２７を含
む各ページの内容を有する。

【００４１】 図１６Ａ−１６Ｃは、キャッシュディレクトリー、仮想アドレスマップ、オペ
レーションシステムの仮想メモリーマップの相互関係を示す。キャッシュディレ
クトリ１８０（図１２）は、キャッシュメモリー５６のデータベースページが内
包されているキャッシュファイルアドレス（ページフレーム）を示している。仮
想アドレスマップ２１０（図１４）は、データベースページが割当てられる仮想
アドレス、つまり、アプリケーションで利用する場合にマッピング処理される仮
想アドレスを示している。仮想メモリーマップ２２４（図１５）は、キャッシュ
ディレクトリ１８０と仮想アドレスマップ２１０からＶＭＭＤＢに与えられた情
報からオペレーションシステムが作成したものである。ＶＭＭＤＢにより、オペ
レーションシステムが、仮想メモリー内にデータベースページをマッピングし、
マッピングされるキャッシュディレクトリ１８０と仮想アドレスマップ２１０か
ら、キャッシュファイルアドレスに送ってデータベースページが設定される。 データベースページを、最初に、仮想メモリーにマッピングするより前にキャ
ッシュに送るときには、ページのポインタはＰＲＭへのスレッドポインタとして
外部表示されている。ページを仮想メモリーにマッピングすると、それらポイン
タは、そのデータがアプリーケーションで使用される前に、その外部様式から対
応する仮想アドレスへと変換しなければならない。「インバウンド再配置」とも
呼ばれるこの変換操作は、図１７に概略図示されている。

【００４２】 ページの外部フォーマットを構成するスレッドポインタとページのＰＲＭの組
み合わせにより、ページの各ポインタのターゲットデータベース、セグメント、
クラスタ、オフセットが符号化される。データベース、セグメント、クラスタ、
オフセットは、それから正しい仮想アドレス２３２が得られる仮想アドレ再配置
マップ２１０内の対応入力を検索するため利用されるものである。 図１８は、前記のインバウンド再配置の詳細を示す。ページのＰＲＭ内のＰＲ
ＭＥはシーケンス処理され、少なくとも１つが存在する、あるいは、ページの内
包クラスタに含まれる、１つ前のＰＲＭＥのターゲットに対応して各ＰＲＭＥが
ターゲットを符号化できる。図６を再度参照してみると、各シーケンスＰＲＭＥ
では、ＰＲＭＥのターゲットの４メガバイト範囲は、そのnumフィールド１５８
、ハイオフセットフィールド１５６、頭文字に続く４つの追加フィールドのうち
いずれかを演算することで得られる。これらの追加フィールドとは、データベー
スフィールド１６２、セグメントIDフィールド１６４、クラスターIDフィールド
１６６、マッピング粒状度フィールド１６８である。この演算は以下のように実
行される。ＰＲＭＥにデータベースインデックスフィールドが備わっていれば、
そのターゲットデータベースは、ページのソースデータベースに格納されたテー
ブルを使用するインデックスの変換により確定される。ＰＲＭＥにデータベース
インデックスフィールドが備わっていなければ、そのＰＥＭＥのターゲットデー
タベースは、以前に処理された該ページのＰＲＭＥのターゲットデータベースが
存在すれば、それと同じであるか、該ページ自体のソースデータベースである。
ＰＲＭＥにセグメントＩＤフィールドが備わっていれば、ターゲットセグメント
はそのＩＤによって指示される。ＰＲＭＥにセグメントＩＤフィールドが無く、
データベースインデックスフィールドが備わっていれば、そのターゲットセグメ
ントは、セグメントＩＤとしてnumフィールド１５８の値を使用することで指示
される。ＰＲＭＥが、データベースインデックスフィールドとセグメントＩＤフ
ィールドの何れも備えていなければ、そのターゲットセグメントは、以前に処理
された該ページのＰＲＭＥのターゲットデータベースが存在すれば、それと同じ
であるか、該ページ自体のソースセグメントである。ＰＲＭＥにクラスターＩＤ
フィールドが備わっていれば、ターゲットクラスターはそのＩＤによって指示さ
れる。ＰＲＭＥにクラスターＩＤがなく、データベースインデックスフィールド
か、セグメントＩＤフィールドの一方、またはその両方が備わっていれば、その
ターゲットクラスターは、クラスターＩＤの代わりにnumフィールド１５８の値
を使用することで指示される。ＰＲＭＥが、データベースインデックス、セグメ
ントID、クラスターIDフィールドの何れも備えていなければ、そのクラスターID
は、numフィールド１５８の値を、以前に処理された該ページのＰＲＭＥのクラ
スターＩＤが存在すればその値に加えるか、あるいは、該ページ自体のソースク
ラスターのＩＤに加えることで算出される。ＰＲＭＥのマッピング粒状度フィー
ルドが存在する場合は、ターゲットデータベース、セグメント、クラスターによ
ってそれまで指示されてきたターゲット範囲へのアドレス域の一連の割当て操作
に必要な、アドレス域の量を指示する。ＰＲＭＥのマッピング粒状度フィールド
が存在しない代わりに、データベースインデックスフィールドか、セグメントＩ
Ｄフィールドがある場合は、ターゲットのマッピング粒状度は、６４キロバイト
のデフォルト値に設定される。もし、マッピング粒状度フィールド、データベー
スインデックスフィールド、セグメントＩＤフィールドのいずれも存在しなけれ
ば、ターゲットのマッピング粒状度は、以前に処理された該ページのＰＲＭＥが
存在すればその値か、６３キロバイトのデフォルト値である。変換処理によって
、これまで、ターゲット範囲のターゲットデータベース、セグメント、クラスタ
ー、マッピング粒状度を作成してきた。

【００４３】 上記のＰＲＭＥの変換処理に従って、ＰＲＭＥのヘッドポインターインデック
スフィールド１６０は、そのターゲットを符号化するために、低オフセットフィ
ールド１５２と複合してＰＲＭＥを使用するページの第１ポインターを検索する
ようトラバース処理される。後続のポインターは、図６に示すように、インデッ
クスフィールド１５０を介してリンクされる。ＰＲＭＥのヘッドポインターイン
デックスフィールド１６０から到達可能な全てのポインターは、同じターゲット
データベース、セグメント、クラスターを共有し、上述のＰＲＭＥ変換処理によ
り生成された値を備える。これらのポインターの実際のターゲットは、ターゲッ
トクラスター内のオフセットによってのみ、異なることになる。このような各ポ
インターのオフセット値は、ＰＲＭＥのハイオフセットフィールド１５６を、各
ポインターの低オフセットフィールド１５２と複合することで算出される。 前記のデータベース、セグメント、オフセットは次に、対応する仮想アドレス
マップエントリ（ＶＡＭＥ）２１２、または割当てＤＳＣＯハンドルとも称され
る、を検索するために使用される。この対応ＶＡＭＥは、ターゲットオフセット
が、オフセットフィールド２１８のＰ値以上であって、前記オフセットＰと前記
エントリのレングスフィールド２２０のＱ値の合計未満である。（ターゲットオ
フセット<Ｐ+Ｑ）。前記ポインターのターゲットの仮想アドレスは、Ｐ−ターゲ
ットオフセット値の差値をＲ（ＶＡＭＥの第１仮想アドレス）に加算して算定で
きる。アウトバウンド再配置中に、ポインターの仮想アドレスを外部フォーマッ
トへ変換するには、これとは逆の工程を実行すればよい。

【００４４】 データのページをデータベースから取り出し、キャッシュへ格納する場合、こ
のページは内向けに再配置される。つまり、前記ページ内のポインターは、その
外部フォーマットから仮想アドレスへ変換されるのである。データのページをサ
ーバへ返送する工程を、アウトバウンド再配置と呼ぶ。この情報がアドレス域作
成で必要なくなった後のキャッシュ内に残っているデータページのポインタ情報
を更新する工程を、前方再配置と呼ぶ。

【００４５】 図１９には、本発明の再配置最適化方法で使用するデータ構成の再配置最適化
列（リロプトキュー）が図示してある。ここでいう再配置最適化とは、前向き再
配置の頻度を減らす操作をいう。キャッシュデータの保全は、リロプトキューを
使って実行できる。リロプトキューにより、アドレス域作成が一般的には単独の
トランスアクション、または、トランスアクションの一部あるいは連続するトラ
ンスアクション群であるような、連続アドレス域作成におけるＰＳＲ内の仮想ア
ドレス域が管理およびインデックス処理される。

【００４６】 図２３には、持続位置へのポインタの全ターゲットを取り囲む、キャッシュ内
のページがアプリケーションにアクセス可能であるＰＳＲ（持続記憶域）セクシ
ョンを含むヒープとスタックの処理アドレス域を示す。顧客アプリケーションが
データベースにアクセスすると、顧客アプリケーションは、仮想アドレス域のＰ
ＳＲ部内の仮想アドレスを、アプリケーションがアクセスするページに割当てる
。この仮想アドレスの割当ては、アクセスする特定のページの領域、および、特
定ページが指示するページの領域についてのみ実行される。仮想アドレス割当て
はデータベースへ各顧客のアクセス操作内に制限されるので、顧客はそれ自身の
仮想アドレス割当てを保有できるのである。標準的なＰＳＲの大きさは１２８メ
ガバイトであるが、アプリケーションに応じて変更しても構わない。各セッショ
ンにおいて、１個のＰＳＲを使う。

【００４７】 前記のアドレス域作成の期間は、顧客アプリケーションで管理でき、顧客アプ
リケーション要件により決まることができ、読取および/またはトラバースのＰ
ＳＲ内のポインタ組は、演算における特異点に達するまで変更してはいけない。
それら特異点は、顧客アプリケーションで指示される場合、アドレス域作成の範
囲を決める。

【００４８】 １セッションにつき１リロプトキューが提供される。システムの各顧客につき
１セッションが与えられる（ただし、１つのアプリケーション処理には、複数の
顧客、つまり、複数のセッションを含むことができる）ので、顧客とセッション
の用語は、リロプトキューの説明においては相互交換して使っても構わない。

【００４９】 前記の本発明の実施例では、リロプトキューを、必要に応じてオブジェクトを
列のどこにでも挿入や除去ができるよう、ダブルリンクリストとして実行する。
列の一方の端はヘッド部であり、他方の端がテイル部である。リロプトキューを
図示した図面において、右側がヘッド部側である。列の要素の順序は、relopt機
構の機能のため、ヘッド部に近いほうを最近利用（ＭＲＵ）要素とし、テイル部
に理解ほうを最遠利用（ＬＲＵ）要素として説明する。リロプトキューを説明す
るのに使うことができる別の非公式だが便利な順序として、新しいとか古いとい
う用語は確立された年代順序法を意味するものではないが、ヘッド部に近いほう
を新しい要素とし、テイル部に近いほうを古い要素とみなすことも可能である。
リロプトキュー内のオブジェクトには、それぞれ下記に詳細に説明するような、
フィンガー、データベースセグメントクラスタオフセット（ＤＳＣＯ）、ハンド
ル、ページハンドル、変位アドレスバインドセット（ＤＡＢＳ）などが含まれる
。 フィンガーは、再配置最適化法の機能に対して重要な再プロット列で位置を示
す要素である。基本的な再配置最適化法では、さまざまなフィンガーがあり、挿
入フィンガー、走査されるフィンガー、移動フィンガー、削除フィンガー、およ
び係数フィンガーとなる。高度な再配置最適化法では、複数の挿入フィンガーを
使用することができる。

【００５０】 基本的な再配置最適化法では、挿入フィンガーは列の「最も新しい」端でもあ
る列の先頭に固定される。この挿入フィンガーは、ページ・ハンドルやデータベ
ース・セグメント・フラスター・オフセット（Ｄａｔａｂａｓｅ Ｓｅｇｍｅｎ
ｔ Ｃｌｕｓｔｅｒ Ｏｆｆｓｅｔ， ＤＳＣＯ）ハンドルが列に挿入される場
所である、列の唯一の点を示す。

【００５１】 挿入フィンガーの左にあるフィンガーは走査されるフィンガーである。走査さ
れるフィンガーは、定義上挿入フィンガーよりも古く、移動フィンガーや削除フ
ィンガーよりも新しい。走査されるフィンガーと挿入フィンガー列のセグメント
に境界を設け、その中でページ・ハンドルは、すべてのポインタが有効で、かつ
、それ以上の処理を必要とすることなく、現行のアドレス空間生成の間有効であ
り続けると保証されるページに対応している。走査されるフィンガーの位置は、
新しいアドレス空間生成が開始されるまで、再プロット列に固定され、そこで、
走査されるフィンガーは再プロットの先頭に移動し、挿入フィンガーよりも古く
なる。走査されるフィンガーは生成番号が現行の生成であり、走査フラグが設定
されている最も古いページ・ハンドルよりも古い。生成番号と走査フラグについ
ては後に述べる。

【００５２】 前方への再配置の目的は、顧客アプリケーションが、一連のアドレス空間生成
にわたり、任意の一時にプロセッサ状態レジスタ（Ｐｒｏｃｅｓｓｏｒ Ｓｔａ
ｔｅ Ｒｅｇｉｓｔｅｒ， ＰＳＲ）に差し込むことができる分を越えた大量の
永続データにアクセスできるようにすることである。システムによっては、前方
への再配置は出の再配置とインバウンド再配置との組み合わせで置き換えられる
。しかしこの置き換えは、本発明に関しては、重要な違いではなく、独自の前方
への再配置でも出とインバウンド再配置の組み合わせでも、同様に機能する。同
じ作業を行うのに出とインバウンド再配置の組み合わせのコストの半分以下のコ
ストで済むため、前方への再配置が好ましい方法である。

【００５３】 本発明の第一の目的は、顧客アプリケーションに分かりやすい方法で、前方へ
の再配置（あるいは前述のような同様の機能をおこなう代わりのもの）の頻度を
減らすことである。これにより、顧客アプリケーションと仮想メモリ・マッピン
グ・データベース（Ｖｉｓｕａｌ Ｍｅｍｏｒｙ Ｍａｐｐｉｎｇ Ｄａｔａｂ
ａｓｅ， ＶＭＭＤＢ）の組み合わさったシステムの性能全体を向上させる。組
み合わせシステムが、本発明が適応されない場合に前方への再配置を要求しない
という利益を実現した場合は常に、このシステムは再配置最適化あるいは再プロ
ットの恩恵を受けたと言われる。

【００５４】 リロプトキューは、本発明における構造であって、その目的はアドレス空間の
バインディングをこれらバインディングが一番最近に使用されたもの（ＭＲＵ）
がキューの先頭に最も近くなるようにする等、使用の最近性によって大まかに順
番付けられるように整理することにある。 ＰＳＲ内における全ての利用可能な
仮想アドレス空間がバインディングによって占められた場合、現時点のアドレス
空間の生成において使用されていない以前の（ＬＲＵ）バインディングは置換さ
れることが可能であり、よってこれらが占めていた仮想アドレス空間が利用でき
るようにする。以前のバインディングの置換を優先させ、新しいバインディング
が利用できるように空間を作るために必要に応じてのみこのような置換を行うこ
とによって、ほとんどの顧客アプリケーションにとって典型的である一時的なロ
ーカリティプロパティと本発明とを組み合わせた場合に、その顧客アプリケーシ
ョンが次回使用された場合に顧客キャッシュのページに無効であるポインタが含
まれているという状態の頻度を低減することが可能となる。このようなページの
みが前方再配置を必要とするため、前方再配置の頻度が低減され得る。

【００５５】 前述のように、リロプトキューにおいてはアドレス空間のバインディングが整
理される。これらバインディングは、キュー内においてＤＳＣＯハンドルと称さ
れるオブジェクトによって表されるものであり、ＤＳＣＯとはデータベース、セ
グメント、クラスターおよびオフセットの略である。ＤＳＣＯハンドルは、さら
に仮想アドレスマップにおけるエントリーでもある。各ＤＳＣＯハンドルは、ク
ラスターが６４キロバイトのデフォルトマッピング粒状度のみを必要とする場合
にデータベース、セグメント、クラスター、オフセットあるいはサイズによって
画定される継続的な領域に不動的に基準とするものである。ＤＳＣＯハンドルの
第２の、類似した種類としては、６４キロバイト以上のマッピング粒状度を有す
るクラスターを基準とするものであり、この場合、本発明の機能にとってはさし
て重要でない簡素化のための実施上の決定事項としてこれらクラスターのマッピ
ング粒状度とサイズとは一致するものとされている。特に明記しない限り本文に
おいてＤＳＣＯハンドルについて述べる場合にはいずれかの種類について述べて
いるものとする。ＤＳＣＯハンドルはデータベース、セグメント、クラスターお
よびオフセットのために別個のフィールドを備えるものではない。むしろクラス
ターハンドルを基準とする唯一のフィールドを含むものであって、このようなク
ラスターハンドルとは特定のデータベースにおける特定のセグメント内の特定の
クラスターを基準とするものとする。したがって同一のクラスターを基準とする
ＤＳＣＯハンドルは同一のクラスターハンドルを共有するものであり得る（この
ことはＤＳＣＯハンドルのサイズを低減するための実施上の決定事項であって、
本発明の機能に対して格別重要なことではない）。またＤＳＣＯハンドルは、ゼ
ロであってもＰＳＲ内における仮想アドレスの値であってもよい仮想アドレスフ
ィールドを含むものである。このフィールドがゼロである場合、ＤＳＣＯハンド
ルは割り当てられていないあるいは限定されていないと称される状態にある。こ
のフィールドがゼロでない場合、このＤＳＣＯハンドルは割り当てられているあ
るいは限定されていると称される状態にあり、限定されているＤＳＣＯハンドル
はさらにＶＡＭＥとも称される。このフィールドに含まれるアドレスから開始さ
れ、このサイズフィールドの値と等しいバイト数分連続する仮想アドレス空間領
域は、継続的な領域内におけるターゲットとこの継続的な領域内における継続的
なデータを構成するページとに関する両方のポインタによって使用されるべく制
限されているとみなされる。この仮想アドレス空間領域は、ＤＳＣＯハンドルに
対して割り当てられているあるいは限定されているとも称される。ＤＳＣＯハン
ドルが割り当てられている間、これに対して割り当てられている仮想アドレス空
間領域は他のいかなるＤＳＣＯハンドルに対しても割り当てられ得ない。限定さ
れているＤＳＣＯハンドルは、ＰＳＲ内における処理アドレス空間の連続する領
域と継続的なアドレス空間の同等のサイズを有する連続する領域との間の双方向
的なマッピングである。置換フィンガーと挿入フィンガーとの間における全ての
ＤＳＣＯハンドルのサイズの合計は、ＰＳＲのサイズによって限定されている。

【００５６】 限定されたＤＳＣＯハンドルのみがＶＭＭＤＢシステムによって管理されてい
る、仮想アドレスによってインデックスされる仮想アドレスマップ上にてエント
リーとして現れる。顧客内において現存する全てのＤＳＣＯハンドルが、データ
ベース、セグメント、クラスターおよびオフセットにてインデックスされる、Ｄ
ＳＣＯマップと称される別の表においてエントリーとして現れる。このＤＳＣＯ
マップは、ポインタのターゲットとされるデータベース、セグメント、クラスタ
ーおよびオフセットが識別できるまでにＰＲＭＥとポインタの組み合わせとの変
換が完成した場合、主にインバウンド再配置によって使用される。インバウンド
再配置においてＤＳＣＯマップが使用されることに関しては後に詳述する。

【００５７】 顧客内において現存する全てのＤＳＣＯハンドルは、限定されているものであ
ろうとなかろうと、リロプトキュー内における要素である。

【００５８】 ＤＳＣＯハンドルに加え、リロプトキューにおいてはページハンドルと称され
る要素が含まれるものである。顧客のキャッシュに現存し、アウトバウンド再配
置よりも最近にインバウンド再配置が行われた全てのページに対して個別のペー
ジハンドルが存在する。リロプトキュー内におけるＤＳＣＯハンドルに関連して
ページハンドルを位置付けることは、ページハンドルは常にリロプトキューにお
いて対応するページに含まれるポインタによって参照される継続的な領域に対応
するＤＳＣＯハンドル、およびページハンドルによって表されるページが所属す
る継続的な領域に対応するＤＳＣＯハンドルよりも古い位置にあらねばならない
、としている不変式に従っているものである。この不変式の目的は、各ページが
リロプトキューをページハンドルの位置に関連する２つの領域に分割することを
可能にすることにある。ページハンドルよりも古い領域は、顧客アプリケーショ
ンがページに対して有効にアクセスできるように限定されねばならないＤＳＣＯ
ハンドルを含むものではない。ページハンドルよりも若い領域は、顧客アプリケ
ーション（およびその他大勢）がページに対して有効にアクセスできるように限
定されねばならない全てのＤＳＣＯハンドルを含むものである。この分割によっ
て仮想アドレス空間を利用可能にする目的のために限定されたＤＳＣＯハンドル
を置換することによって、置換されるＤＳＣＯハンドルよりもより古い位置にお
けるページハンドルによって表されるページの有効性のみが影響されることが保
証される。

【００５９】 リロプトキューにおいてはその他の要素も存在している。このような集合的に
はフィンガーと称される要素の一つのクラスは、リロプトキューのセグメントの
範囲を定めるために用いられる。本発明の基本的な方法において、各リロプトキ
ューに対してこのようなフィンガーが５つ存在する。

【００６０】 第１のフィンガーは、挿入フィンガーと称される。これは常にリロプトキュー
の先頭に固定されているため、先頭と同義である。本発明の発展例においては、
複数の挿入フィンガーが存在し得るものであるが、１つ以外はキューの先頭には
固定されていない。このような発展例は後に詳述される。

【００６１】 第２のフィンガーは、走査されるフィンガーと称される。走査されるフィンガ
ーと挿入フィンガーとの間のキューのセクションには走査されるセクションが存
在する。アドレス空間生成の開始時において走査されるフィンガーを挿入フィン
ガーの直古の位置に移動させることによってこの走査されるセクションは空にさ
れる。アドレス空間生成において、この走査されるセクションには要素が加えら
れる。走査されるセクション内における要素の有効性は、アドレス空間生成を持
続する方法によって保存される、すなわち走査されるセクション内のＤＳＣＯハ
ンドルは置換されず、よって走査されるセクション内のページハンドルに対応す
るページに含まれる全てのポインタはアドレス空間生成が持続する間有効で在り
続ける。

【００６２】 第３のフィンガーは、置換フィンガーと称される。この置換フィンガーは常に
走査されるフィンガーよりも古い位置に存在する。置換フィンガーと走査される
フィンガーとの間のキューのセクションには走査されないセクションが存在する
。

【００６３】 第４のフィンガーは、削除フィンガーと称される。これは常にリロプトキュー
の末尾に固定されるため、末尾と同義である。削除フィンガーと置換フィンガー
との間のセクションには置換されたセクションが存在する。全ての限定されてい
ないＤＳＣＯハンドルは、置換されたセクション内にある。全ての現在では無効
であるポインタを含むページを表す全てのページハンドルもまた、この置換され
たセクション内にある。なお、顧客キャッシュ内にある間、再び顧客アプリケー
ションによって使用され得るために前方再配置を必要とする無効であるポインタ
を含むのはこれらのページのみであることに注意されたい。

【００６４】 データベースアプリケーションを開始する際に、すなわち時間ｔ０において、
削除、置換、走査および挿入フィンガーのすべてがキュー内において隣接して配
置され、図２０において図示されるようにリロプトキューにはその他の要素が存
在しない。

【００６５】 第５のフィンガーは、絶対値フィンガーと称される。その他のフィンガーとは
違ってこの絶対値フィンガーは、キューのセクションの範囲を定めるために用い
られるものではない。これはアドレス空間生成数の演算において整数のオーバー
フローをオフセットするための技術として用いられるものである。絶対値フィン
ガーの機能は、この方法のその他の機能とは別個であるため、後に詳述される。 リロプトキューにおいて存在する最後の要素のクラスは置換されたアドレスバ
インディングのセットである、それぞれの置換されたアドレスバインディングの
セット（ＤＡＢＳ）は、現在のアドレスバインディングのセットと同様の構造を
有する仮想アドレスからＤＳＣＯハンドルへのマップである。各顧客に対して複
数のＤＡＢＳが存在し得、その最初のものはＤＳＣＯハンドルの第１の置換にお
いて生成される。ＤＡＢＳの機能は、ＤＳＣＯハンドルにおける以前のバインデ
ィングから仮想アドレスへの情報の経路を追うことにある。これらＤＡＢＳは、
前方再配置において用いられる。各ＤＡＢＳは、リロプトキューにおいて存在す
るとすれば次のより若いＤＡＢＳに対するリンクをも有するものである。

【００６６】 その作動を行っている間、顧客アプリケーションは一連の処理を送出する。顧
客アプリケーションはまた、デフォルト設定によって処理に正確に対応するもの
であっても、顧客アプリケーションのより精密な制御を行うことによって個々の
あるいは一連の処理の一部分に対応するものであってもよい一連のアドレス空間
生成をも送出するものである。処理の間、顧客アプリケーションは継続するデー
タに関するページに対してＶＭＭＤＢの顧客コンポーネントに対してリクエスト
を発行する。要求されたページが既に顧客のキャッシュに存在する場合、ＶＭＭ
ＤＢの顧客コンポーネントは、そのページがさらなる変換（前方再配置）を必要
とするか否かを判断し、必要であればそのような変換を行い、その後ＶＭＭＤＢ
はそのページをＰＳＲにマッピングし、所望されるアクセスのために適宜保護し
、対応するページハンドルとキャッシュディレクトリエントリーとの状態を適宜
更新することによって顧客アプリケーションがそのページを利用できるようにす
る。要求されたページが既に顧客のキャッシュになければ、ＶＭＭＤＢの顧客コ
ンポーネントがサーバコンポーネントに対してリクエストを送出する。あるペー
ジに関してサーバコンポーネントに要求を出すと言うことは、多くの場合同時に
同じ継続的なデータに対して処理を行うその他の顧客に対して項目をロックする
ことを含むものであるが、このような項目は標準的な二相式ロッキングデータベ
ースモデルにおける項目と同等であると理解され得るため、ここでは考察されな
い。サーバが顧客の要求に一旦応答した場合、そのページは顧客のキャッシュ内
に配されてそれに対するページハンドルとキャッシュディレクトリエントリーと
が生成され、正しく初期化された場合、そのページはインバウンド再配置され、
その後ＶＭＭＤＢはそれをＰＳＲにマッピングして所望されるアクセスに対して
適宜保護することによって顧客アプリケーションがそのページを利用できるよう
にする。したがってインバウンドおよび前方再配置のいずれもが顧客アプリケー
ションの継続するデータのページにアクセスしたいという要求によって誘発され
るものであり、その違いは前方再配置が顧客のキャッシュに既に存在するページ
に対して行われるものであるのに対して、インバウンド再配置が常に現在そこに
存在しない場合であって顧客のキャッシュにページが導入される場合に行われる
という点にある。

【００６７】 図２１はページの最初のインバウンド再配置に続く典型的な再プロット列を示
している。インバウンド再配置の間に、ページＰ１に対応するページハンドルが
挿入フィンガーより降る委細プロット列に置かれ、そのページについてのＰＲＭ
が前述のページに含まれるポインタに沿って処理される。 このプロセスにより
変換される、その目標を有するそれぞれのポインタについて言うと、その目標は
ＤＳＣＯマップの中でルックアップされる。このルックアップに関しては３つの
結果が可能性のあるものとして考えられる。すなわち、その目標を取り囲む領域
について連結済みのＤＳＣＯハンドルがある場合か、その目標を取り囲む領域に
ついて連結されていないＤＳＣＯハンドルがある場合か、あるいは、その目標を
取り囲む領域についてのＤＳＣＯハンドルがない場合か、である。その目標を取
り囲む領域について連結済みのＤＳＣＯハンドルがある場合、その場合には、そ
の仮想アドレスは、ポインタの目標オフセットとＤＳＣＯハンドルの領域オフセ
ットとの間の差異に加えられるとき、そのポインタについての仮想アドレス変換
値を産出する。この値はそのポインタの外部形態に上書きされる。その目標を取
り囲む領域について連結されていないＤＳＣＯハンドルがある場合、その場合は
、そのポインタ変換が進行することができる前にまず連結されならなければなら
ない。連結されていなかったＤＳＣＯハンドルを連結するプロセスは以下に詳細
に論議される。一旦そのＤＳＣＯハンドルが連結されると、その連結済みＤＳＣ
Ｏハンドルに対して行ったように、ポインタ変換処理が継続する。その目標を取
り囲む領域についてＤＳＣＯハンドルがない場合、ＤＳＣＯハンドルが作成され
、仮想アドレスマップの中に置かれ、連結されて、また連結済みＤＳＣＯハンド
ルに対して行ったように、そのポインタ変換処理が再び継続する。３つすべての
場合で、ＤＳＣＯハンドルはその後、挿入フィンガーよりもちょっと古いリロプ
ト待ち行列の中に置かれるが、それが作成されなかった場合は、リロプト待ち行
列の中のその以前の位置からまずそれを取り出す。ページ上のすべてのポインタ
が変換されるまで、インバウンド再配置はこのように進む。図２１の中にある実
施例では、リロプト待ち行列にこのように加えられたＤＳＣＯハンドルは、ＤＳ
ＣＯ１、ＤＳＣＯ２、ＤＳＣＯ３およびＤＳＣＯ４となる。インバウンド再配置
はその後に、そのページに対応するページハンドルの状態を「使用中ならびにス
キャンされている」状態に設定し、その後、適切な保護を備えた適切なアドレス
でＰＳＲの中にそのページをマップし、そのページを顧客アプリケーションに対
してアクセス可能にし、そしてその顧客アプリケーションに制御権を戻す。

【００６８】 図２２は、第２ページＰ２が持ち込まれ、またそのページがＤＳＣＯ２により
カバーされる範囲にある場合、また、ＤＳＣＯ１と新たなＤＳＣＯハンドルであ
るＤＳＣＯ５−（その他の４つのＤＳＣＯハンドルに関して行われたように、作
成され、割り当てられ、そしてＤＳＣＯマップとＣＡＢＳの中に置かれる）によ
りカバーされた目標を有するポインタを含み、そのページがインバウンド再配置
を行い、挿入フィンガーに挿入され、そしてその後にＤＳＣＯ１、ＤＳＣＯ５、
およびＤＳＣＯ２がその挿入フィンガーに挿入される場合に、何が起こるのかを
図示することにより、図２０と２１の実施例を継承している。

【００６９】 ページハンドルの状態には、「使用中ならびにスキャンされている」、「使用
中だがスキャンはされていない」、「使用中ではない」そして、「使用中ではな
く、変位した」がある。最初の２つの状態の両方ともでみられる「使用中」とい
う指定は、現行アドレススペース生成時に顧客アプリケーションにアクセス可能
であるページのページハンドルに対応している。「スキャンされている」という
指定は、リロプト待ち行列のスキャンされたセクションの中にあるページハンド
ルに対応している。「変位した」という指定は、リロプト待ち行列の変位された
セクションの中にあるページハンドルに対応している。なお、スキャンされたペ
ージはすべて使用中であり、変位したページハンドルはすべて使用中ではない。
「使用中だが、スキャンされてはいない」および「使用中ではない」状態は、リ
ロプト待ち行列のスキャンされていないセクションの中にあるページハンドルに
対応している。

【００７０】 顧客アプリケーションによりページに対するリクエストが進められると、ペー
ジハンドルは個別に使用中にされる。その顧客アプリケーションが現行アドレス
スペース生成が終了したことを指示するときには、ページハンドルは全部まとめ
て使用から取り外される。

【００７１】 前に述べたように、図２４の継承実施例の中で図示されているように、挿入フ
ィンガーよりもちょっと古い位置にスキャンされたフィンガーを移動することに
より現行アドレススペース生成は終了する。スキャンされたフィンガーをこのよ
うに移動させるだけでは、ページハンドルが使用外の状態に変わることはない。
数多くのページハンドルを同時に使用外にするプロセスをスピードアップするた
めには、本発明は、各ページハンドルにおけるアドレススペース生成フィールド
と一緒に顧客に関する単一大域現行スペース生成カウンタを使用する。大域カウ
ンタとフィールドの両方とも、３２ビット幅である。大域カウンタは、１〜２３
２−１という包含的範囲にある値をとり、一方、フィードは０〜２３２−１とい
う包含的範囲にある値をとる。現行アドレススペース生成がいつ終了しても、大
域カウンタは増分され、またそれが０にオーバーフローする場合は、即座に１に
設定される。ページハンドルが「使用中ならびにスキャンされている」あるいは
「使用中であるが、スキャンはされていない」状態のいずれかにされている場合
は、そのページハンドルのアドレススペース生成フィールドはその大域現行アド
レススペース生成数の値に設定される。このように、ページハンドルのアドレス
スペース生成フィールドの値が、大域現行アドレススペース生成カウンタの値と
等しい場合は、そのページハンドルは使用中と指定される。フィールドの値が大
域カウンタの値に等しくない場合、その場合は、そのページハンドルは、リロプ
ト待ち行列のなかのその位置により、「使用中ではない」あるいは「変位した」
状態のいずれかである。このように、アドレススペース生成の終了時には大域カ
ウンタを増分するという単一動作により、各ページハンドルが順次スキャンされ
ることは要求されずにそのアドレススペース生成時に使用中であったすべてのペ
ージハンドルの状態は有効に変化する。

【００７２】 このプロセスは、大域カウンタが前の値よりも小さい値に設定される場合には
、整数オーバーフローのため、エラーしやすくなる。ここで可能性のあるエラー
とは、この低値をそのフィールドの値として有し、何らかの以前のアドレススペ
ース生成時に設定されたページハンドルが存在し、しかも、そのページハンドル
が使用中であるということを意味するように、そのフィールドが現在大域カウン
タに等しいという事実を解釈して間違ってしまうことである。これが、２３２−
１生成よりも小さい数から０まで以内にある使用中状態の中に入れられていなか
ったすべてのページハンドルのアドレススペース生成フィールドを設定すること
より、このエラーしやすい状態が生起するのを防ぐ、本発明の内にあるこの法フ
ィンガーの機能である。この法フィンガーは、アドレススペース生成毎にリロプ
ト待ち行列の中にある１つの構成要素を移動して通過していき（古い位置から新
しい位置へと）、それがヘッドを通過すると、末尾にループバックすることによ
り、このタスクを達成する。本発明は、この移動をアドレススペース生成の終了
時に実施するが、しかし、いずれのときにそれを実施しても十分足りる。法フィ
ンガーにより移動通過されられるその構成要素がページハンドルであって、また
そのアドレススペース生成フィールドが大域現行アドレススペース生成カウンタ
に現在は等しくない場合、その場合は、フィールドは０に設定され、それは、大
域カウンタの値が少なくとも１に常に維持されているため、整数オーバーフロー
には無関係に、大域カウンタに等しくはならない値となる。このプロセスが正確
であるのは、リロプト待ち行列には２３２−１構成要素よりも少ない数の構成要
素しかないという制限に基づいている。この制限はメモリ消費上のコンピュータ
ハードウエアの制限により間接的に課せられており、そのため、本発明により直
接課せる必要はない。

【００７３】 アンバウンドＤＳＣＯをバイドするため、この方法は、他のＤＳＣＯハンドル
にバインドされていないＤＳＣＯハンドルのフィールドんじょサイズと等しいか
それより大きなサイズのバーチャルアドレスフィールドを見付けなければならな
い。バーチャルアドレスマップはそのような領域が存在するかどうかを決定する
ように質問できる。もし適当な領域が存在すれば、その領域はリクエストされた
サイズであり、ＤＳＣＯハンドルにバウンドされている。適用な領域が存在し、
サイズがリクエストされたものより大きければ、サイズが等しい領域の一部はＤ
ＳＣＯハンドルにバイドされており、残りはバインドされていない。もし、適当
な領域が存在しなければ、現在のアドレススペース発生で使用されているページ
ハンドルで必要とされない他のバウンドＤＳＣＯハンドルをアンバインドするこ
とで創出できる。本願発明はディスプレースフィンガーを使用し、次のディスプ
レース手法でそれらをアンバイドする。ディスプレースフィンガーよりも若い要
素が調べられる。要素がＤＳＣＯハンドルであれば、ＤＳＣＯハンドルにバウン
ドされなければならない。なぜなら、全てのアンバウンドＤＳＣＯハンドルはデ
ィスプレースフィンガーの古い側へのディスプレースセクションに存在するから
である。このように発見されたＤＳＣＯハンドルはアンバウンドされ、バーチャ
ルアドレスフィールドは０にセットされ、バーチャルアドレスマップの対応エン
トリーは変性されて。ＤＳＣＯハンドルに前にバウンドされたバーチャルアドレ
ス領域がフリーであることを示す。ＤＳＣＯハンドルをリフェレンスするエント
リーは最も若いＤＡＢＳハンドルに加えられる。それは、ＤＳＣＯハンドルに前
にバウンドされたバーチャルアドレス領域のアドレスによりインデックス可能な
方法で行われ、バーチャルアドレス領域が決定される。ＤＳＣＯハンドルはディ
スプレースメントフィンガーの古い側に配置される。もし、この方法でフリーと
なったバーチャルアドレススペース領域のサイズがスペースに対するリクエスト
を満たすに充分であれば、リクエストは充足される。もし、フリー領域が充分に
大きくなければ、ディスプレースメント手法は次の要素を検査する。

【００７４】 この手法で検査された要素がスキャンされたフィンガーであれば、全ての残っ
たバウンドされたＤＳＣＯハンドルはスキャンされたセクション内で存在しなけ
ればならない。全てのそのようなバウンドされたＤＳＣＯハンドルは現在のアド
レスのスペース発生の時間だけ現行バインディングを維持しなければならないの
で、他のＤＳＣＯハンドルによって消費されるフリーバーチャルアドレススペー
スを提供するようにアンバウンドされるものはない。このような場合に、クライ
エントはバーチャルアドレススペースを消費し、この状態はクライエントアプリ
ケーションに信号される。クライエントアプリケーションは現行のアドレススペ
ース発生を終了させるように選択することができる。また、継続させたり、リク
エストされたページを終了させることができる。

【００７５】 もしディスプレース手法により検査される要素がページハンドルであれば、こ
のページハンドルは“私用中でスキャンされていない”か“非使用”でなければ
ならない。なぜなら、ディスプレースステートの全てのページハンドルはキュー
のディスプレースフィンガーの古い側にあるからである。また、“使用中でスキ
ャンされている”ステートはスキャンされているフィンガーよりも新しく、ディ
スプレース手法では到達できない。もし、検査されるページが“非使用”であれ
ば、ディスプレースフィンガーよりも古く、そのヘッドＤＡＢＳフィールドが現
行のもっとも新しいＤＡＢＳにリファーするようにセットされ、ディスプレース
ステートとなるようにセットされる。ページハンドルが“使用中でスキャンされ
ていない”ステートであれば、さらなる処理が必要で、ページハンドルをディス
プレース手法から外して、バウンドＤＳＣＯハンドルを発見しなければならない
。このプロセスはスキャニングである。リロケーションとは異なり、ポインター
値はスキャニングで変化しない。その代わりに、バーチャルアドレスマップにイ
ンデックスするのに使用され、ポインターのターゲットに対応するバウンドＤＳ
ＣＯハンドルを発見する。まず、ページハンドル自身がキューのヘッドに移動さ
れる。次にスキャニング中にページの各ポインターはバーチャルアドレスマップ
へのインデックスに使用され、対応するバウンドＤＳＣＯハンドルを発見する。
発見された各ＤＳＣＯハンドルはキューのヘッドに移動される。ページが番号で
ある領域に対応するＤＳＣＯハンドルも同様に移動される。スキャニングはペー
ジハンドルをディスプレース手法から外す。

【００７６】 クライエントアプリケーションによるページのリクエストがどのように行われ
るかを再び解説する。ページハンドルは使用中ステートではあり得ない。ページ
ハンドルが“非使用”ステートであれば、リロプトキューの非スキャンセクショ
ン内に存在しなければならない。リロプトキューのポジション変数は全ＤＳＣＯ
ハンドルがページよりも若いことを保証し、バウンドされていなければならない
。さらに、これらＤＳＣＯハンドルはアンバウンドできない。本願発明はこのペ
ージのステートを“非使用”から“使用中だが未スキャン”のステートの変更さ
せる。この能力は本願発明の利点である。本願発明はさらにこのページ部分が実
質的な部分とする。

【００７７】 クライエントアプリケーションでリクエストされたページのページハンドルが
ディスプレースステートであるなら、ポインターは有効ではない。このステート
のページはクライエントアプリケーションにアクセス可能とされる前にフォーワ
ードリロケーションされなければならない。フォワードリロケーションはページ
のメタデータ内のオブジェキトタッグを使用してポインターをページ内でロケー
トする。インバウンドリロケーションまたはスキャニングとは異なり、これらポ
インターのターゲットはＰＲＭからの翻訳では発見されない。フォワードリロケ
ーションはＤＡＢＳを使用してポインターを翻訳する。図２５はリロプトキュー
を示す。ページハンドルはキューのヘッドに移動される。各ポインターに対して
ポインターの値はＤＡＢＳへのインデックスに使用される。エントリーがＤＡＢ
Ｓで発見されると、ＤＳＣＯハンドルは３ステートの１つとなる。ＤＳＣＯハン
ドルはＤＡＢＳに加えられた直前にバウンドされた同じアドレス領域にバウンド
可能である。この場合、ポインターの値は有効で、翻訳は不要である。ＤＳＣＯ
ハンドルは非バウンド状態となり得る。この場合、ＤＳＣＯハンドルはバウンド
されなければならない。

【００７８】 もしＤＡＢＡが適当なエントリーを持たない場合、次のＤＡＢＳが次に質問さ
れる。この手順はＤＳＣＯハンドルが発見されるか、ＤＡＢＳチェインの端部に
到達するまで反復される。

【００７９】 ベーシックバージョンと進歩したバージョンとの最も大きな相違点は、進歩し
たバージョンは、列の先頭位置に１つだけ固定された複数の挿入フィンガーを有
していることである。さらに、挿入フィンガーは、位置変更フィンガーのより若
い側のどこにでも現れることができる。スキャンされたフィンガーの若い側への
挿入フィンガーは、活性状態と判断され、スキャンされたフィンガーの古い側へ
のものは、不活性状態と判断される。よって、挿入フィンガーのフラッグは、新
しい挿入フィンガーについては活性状態であり、対応するネストされたアドレス
スペースの生成が終了すると、不活性にセットされることで、活性状態／不活性
状態を追跡する。グローバルアドレススペース生成カウンターは、この進歩した
バージョンにおいては無い。アドレススペース生成領域に代えて、各ページハン
ドルは、挿入フィンガー又はゼロを意味する挿入フィンガー領域を有している。
ページハンドルの「使用中」の表示は、挿入フィンガー領域を審査することで決
定される。もし、領域がゼロであれば、ページハンドルは使用中ではない。もし
、領域がゼロでなければ、リファレンスされた挿入フィンガーがカレントである
場合においてのみ、ページハンドルは使用中である。ページハンドルは、その挿
入フィンガー領域を、最も内側の活性状態のネストされたアドレススペース生成
のための挿入フィンガーに言及するようにセットすることで使用される。モジュ
ラスフィンガーは、進歩したバージョンでは必要ではない。

【００８０】 既に存在しない現在のアドレススペース生成領域をセットする代わりに、ペー
ジハンドルの位置の変更は、挿入フィンガーの領域をゼロにセットする。位置の
変更処理が挿入フィンガーに遭遇すると、挿入フィンガーは消去される。このよ
うにして、リロップト列内の挿入フィンガーの数は、境界（ｂｏｕｎｄ）無く増
加することはない。不活性状態の挿入フィンガーのより早い消去は、リファレン
ス計数手続を用いることで可能である。

【００８１】 ネストされた又は外方の、アドレススペースの生成が終了すると、スキャンさ
れた領域は、挿入領域より１つ若い位置へ移動される。当該挿入領域はエンディ
ングアドレススペースの生成と対応し、その挿入フィンガーの状態は、不活性に
セットされる。ネストされた又は外方の、アドレススペースの生成が始まると、
新しい挿入フィンガーが生成され、それは、当該スキャンされたフィンガーより
も１つだけ若い位置のリロップト列へ置かれる。前記挿入フィンガーは、ネスト
されたレベルを表示する領域を有しており、それは、新しい挿入フィンガーが生
成された時点において、最も内側のネストされた活性状態の挿入フィンガーのネ
ストされたレベルより１つ大きく、一番外側のレベルが０となる。従って、引き
続いてネストされたアドレススペースの生成は、連続的により高いネストされた
レベルの連続的に古い挿入フィンガーと対応することになる。活性状態の挿入フ
ィンガーの間のリロップト列のセクションは、マルチスキャンされたセクション
として言及され、それは、セクションのオーナーとなるそのようなセクションよ
りも若い活性状態の挿入フィンガーを有する。

【００８２】 挿入フィンガー領域は、ＤＳＣＯハンドルにも加えられる。この領域は、ＤＳ
ＣＯハンドルを移動させるいかなる操作の間においても、ＤＳＣＯハンドルが移
動されるスキャンされたセクションを有する挿入フィンガーにセットされる。 挿入フィンガーの領域を審査するために、ページ又はＤＳＣＯハンドルのネス
トされたレベルが決定される。領域が「ゼロ」であるか、又は、不活性の挿入フ
ィンガーに言及していれば、ネストされたレベルは、無限にポジティブであると
みなされる。さもなければ、ネストされたレベルは、当該活性状態の挿入フィン
ガーのレベルである。ページ及びＤＳＣＯハンドルのネストされたレベルは、新
しい「ｉｎｖａｒｉａｎｔ」を確認するために用いられる。ページ又はＤＳＣＯ
ハンドルは、現在のネストされたレベルよりも高いネストされたレベルを受ける
領域には決して移動されることはない。このようにして、位置変更又はスキャン
の間に、ＤＳＣＯハンドルを移動している間に、ＤＳＣＯハンドルはそのあらゆ
る移動に先立ってその現在のネストされたレベルが審査され、ＤＳＣＯハンドル
は、挿入フィンガーがＤＳＣＯハンドルのネストされたレベルと同等又はそれ以
下のレベルへ移動された場合にのみ移動される。

【００８３】 トランザクションの間においては、常に１つの最も内側のアドレススペースが
生成され、対応する１つの最も内側の活性挿入フィンガー、その挿入フィンガー
は、アドレススペース生成の変更であり、現在の最も内側の活性挿入フィンガー
を追跡して１つのグローバルな可変に始まり終了する。ベーシックバージョンの
ページハンドルの動作とＤＳＣＯハンドルは、動作が常にリロップト列の中への
挿入という結果となるように変更される。その列の位置は、この挿入フィンガー
よりも１つだけ古く、そのように移動されるページ又はＤＳＣＯハンドルの挿入
フィンガーは、この挿入フィンガーに言及するようにセットされる。

【００８４】 アドレススペースの生成が終了すると、対応する挿入フィンガーの状態が不活
性にセットされ、スキャンされたフィンガーは、それよりも１つ若い位置へ移動
される。アドレススペースの生成は、スキャンされたフィンガーが活性状態の挿
入フィンガーより若い位置に移動されることが決してないように、最も内側から
最も外側へと順次終了することとなる。アドレススペースの生成が終了すると、
対応する挿入フィンガーと、スキャンされたセクションの内容とは、スキャンさ
れたフィンガーのこの移動のためにスキャンされていないセクションのエレメン
トとなる。従って、それらのエレメントは、位置の変更が可能となり、活性状態
の挿入フィンガーのスキャンされたセクション内にまだ存在しているエレメント
よりも速く位置が変更されるようになる。この位置変更可能な手順は、クライア
ントのアプリケーションにとって目に見えて快適（ｎｅｓｔｉｎｇ）なものとな
る。

【００８５】 上記の実施例は、単に本発明の趣旨を示したに過ぎないものである。本発明の
趣旨に沿った他の変更は当業者にとって可能であり、それらも本発明の範囲内の
ものである。

【００８６】

【図面の簡単な説明】

【図１】 図１は本願発明が利用される典型的なディストリビュートされたデ
ータベースシステムの形態のブロック図である。

【図２】 図２は図１のシステムの一部の詳細なブロック図であり、サーバー
コンピュータとクライエントコンピュータでの別々のデータレポジトリーを有し
ている。

【図３】 図３はシステムの一部のさらに詳細なブロック図であり、１つのコ
ンピュータにデータとクライエントの永久レポジトリを有している。

【図４】 図４は本願発明のシステムがコンピュータの他のプロセスと相互作
用する様子を示す。

【図５】 データの永久レポジトリの図であり、データベース、セグメント、
クラスター、及びページへの分割を図示している。

【図６】 パーシステントリロケーションマップと関連データベースページと
の図である。

【図７】 さらに詳細なメモリ図であり、データベースに保存されたクラスタ
ーのデータ構造を示している。

【図８】 図８Ａから８Ｃは３つの異なるオブジェクトタッグのデータ構造を
示す図である。

【図９】 図９はスキーマのためのデータ構造を示す図である。

【図１０】図１０は図９のスキーマへのタイプエントリーのデータ構造を示す
図である。

【図１１】図１１はタイプデスクリプションディクショナリエントリーのイン
ストラクション用データ構造の図である。

【図１２】図１２はクライエントキャッシュのモニターのためのクライエント
コンピュータのデータ構造の図である。

【図１３】図１３はデータベースページのオーナーシップステータスをモニタ
ーするためのサーバーコンピュータのデータ構造の図である。

【図１４】図１４はデータベースセグメントに対するバーチャルアドレススペ
ースの指定を示す図である。

【図１５】図１５はバーチャルメモリ（キャッシュのバーチャルアドレスの物
理的アドレス）へのマッピングデータを示す図である。

【図１６】図１６Ａ-図１６Ｃはキャッシュディレクトリと、バーチャルメモ
リマップとバーチャルアドレスマップの間の関係を示す図である。

【図１７】図１７はバーチャルアドレスへのレジスタンスアドレスのリロケー
ション方法を示す図である。

【図１８】図１８はバーチャルアドレスへのパーシステントアドレスのマッピ
ングの詳細なリロケーションである。

【図１９】図１９は本願発明の原理に従った第１リロプトキュー(relopt queu
e)である。

【図２０】図２０は本願発明の原理に従った第２リロプトキュートである。

【図２１】図２１はデータの第１ページのインバウンドリロケーション後の図
２０のリロプトキューである。

【図２２】図２２はデータの第２ページのインバウンドリロケーション後の図
２１のリロプトキューである。

【図２３】図２３は本願発明の原理に従ったＰＳＲスペースの図である。

【図２４】図２４はトランザクション後の図２２のリロプトキューである。

【図２５】図２５は本願発明の原理に従ったキュー要素間の鎖ＤＡＢＳ構造を
有した第３リロプトキューである。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ，ＺＷ )，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ， ＴＪ，ＴＭ)，ＡＥ，ＡＧ，ＡＬ，ＡＭ，ＡＴ，ＡＵ， ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，Ｃ Ｎ，ＣＲ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＤＭ，ＤＺ，ＥＥ ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ， ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，Ｋ Ｐ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ ，ＬＶ，ＭＡ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ， ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，Ｓ Ｇ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＴＺ ，ＵＡ，ＵＧ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷ

Claims (1)

【特許請求の範囲】
1. 【請求項１】 データベースシステム内のキャッシュにおけるデータを分離する
   方法であって、前記キャッシュ内のポインターが、永続的なアドレスポインター
   からトランスレートされたバーチャルアドレスポインターであり、以下のステッ
   プからなる。 ａ）リロケーション最適化列（キュー）を提供し、当該列は、当該列内の位置
   を指定する複数のフィンガーと、キャッシュ内のキャッシュデータと対応する複
   数のエントリーとを有し、 ｂ）前記列を前記フィンガーを有する複数のセクションに区画し、第一のセク
   ションはクライアントのアプリケーションによる現在のトランザクションにて使
   用されているデータのためのエントリーを含み、第二のセクションは、ポインタ
   ーを更新することなく前記クライアントのアプリケーションによって使用可能な
   エントリーを含み、第三のセクションは、ポインターを更新することなく前記ク
   ライアントのアプリケーションによって使用することができないエントリーを含
   み、 ｃ）前記キャッシュ内のデータ及び未だ前記キャッシュ内にないデータに対す
   る、前記クライアントのアプリケーションからのアクセス要求に応じ、 ｄ）未だ前記キャッシュ内にないデータを前記キャッシュ内へ組み入れ、前記
   列内に組み入れられた前記データを反映するように、ポインター情報を更新する
   ために、前記列内のポインターをトランスレートし、 ｅ）前記クライアントのアプリケーションから要求されることのなくなったデ
   ータを前記キャッシュ内から取り除き、前記列内の当該取り除かれたデータを反
   映するポインター情報を更新するために、前記ポインターをトランスレートし、 ｆ）前記列内の第三のセクション内の前記エントリーと対応するデータへのア
   クセスを提供する際にポインターを更新し、それによって前記列の前記第一及び
   第二のセクションに対応する前記キャッシュ内のデータへの迅速なアクセスを提
   供する。