JPH0310343A - ホットスポットデータ管理処理方式 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 〔概要〕 バス結合される共用メモリを備えたマルチプロセッサシ
ステムによるデータベース処理におけるホットスポット
データ管理処理方式に関し頻繁に更新されるデータベー
スのリソースについて、異常があった場合に、そのリカ
バリ処理時間を短縮する手段を提供することを目的とし
。

データベースの各リソースに対するアクセス状況が登録
されるデータベースアクセス状況表と。

データベースアクセス状況表に登録されたアクセス状況
により、ホットスポットデータを判定するホットスポッ
トデータ判定部と、ホットスポットデータと判定された
データが格納される上記共用メモリ内に設けられるホラ
１−スポント用バッファとを備え、アクセス頻度が多い
データまたはローカルメモリに長時間滞在するデータに
ついて、ポットスポットデータとして、共用メモリ上に
配置するように構成する。

〔産業上の利用分野］ 本発明は、バス結合される共用メモリを備えたマルチプ
ロセッサシステムによるデータベース処理におけるホッ
トスポットデータ管理処理方式に関する。

マルチプロセッサシステムは、密結合マルチプロセッサ
システムと、疎結合マルチプロセッサシステムとに大別
されるが、さらにこれらを複合させたものや、密結合と
疎結合との中間的なものなど、多種多様のシステム構成
が、実用化されてきている。

一方、データベース管理システムを、１つのプロセッサ
上で実現するには、レスポンスにある程度の限界がある
という問題や、プロセッサ異常時からの回復に時間がか
かるという問題から、複数のプロセッサを上手に組み合
わせて処理する技術が必要とされている。

〔従来の技術〕 第９図は従来技術の例を示す。

第９図（イ）は従来のマルチプロセッサによるデータベ
ース処理システムの例を示している。各プロセッサモジ
ュール１１は、それぞれＣＰＵおよびローカルメモリ２
４を持つ処理装置であり。

これらのプロセッサモジュール１１は、バス結合され、
プロセッサ間通信が可能になっている。

データベースのリソース（資源）２７は２通常。

データベース中のあるデータ集合の単位で、アクセスが
管理される。この単位は１例えばファイルレベルのこと
もあり、レコードレベルのことモする。

このリソース２７に対するアクセスでは、アクセス競合
によるデータ矛盾の発生防止や、障害発生時における復
旧など、データの完全性を維持するためのインテグリテ
イ保証を行わなければならない。

従来、第９図（イ）に示すようなシステムでは二次記憶
のデータベース実体格納部１３に格納されたデータにつ
いて、各プロセッサモジュール１１の担当するリソース
２７が、あらかじめ静的にまたは負荷状況に応じて動的
に決められ、その各リソース２７に対するインテグリテ
イ保証を、各プロセッサモジュール１１が局所的に行う
ようになっている。

各プロセッサモジュール１１では、第９図（ロ）に示す
ように、ローカルメモリ２４内にデータベースバッファ
２６を設け、データベースに対する参照・更新要求があ
ると、データベースアクセスモジュール５１が、要求さ
れたデータを、データベースバッファ２６に読み出す。

データベースパンツ７２６の領域は２例えばＬＲＵによ
る管理が行われる。データベースバッファ２６内のデー
タに対する更新があると、異常時におけるすカバリのだ
めに、ログ管理部５２により、更新前データま、たは更
新後データのログデータＬｌ、Ｌ２．・・・を採取する
。（参考文献１　：　Ｇｒａｙ、　Ｊ、Ｎ、　［１９７
８コ。

”Ｎｏｔｅｓ　　ｏｎ　　ｄａｔａ　　ｂａｓｅ　　ｏ
ｐｅｒａｔｉｎｇ　　ｓｙｓｔｅｍｓ”　　ＲＪ２１８
８ＩＢＭ＋　Ｓａｎ　Ｊｏｓｅ、　Ｃａ１ｉｆ、）。

なお、データベース実体格納部１３から読み出したリソ
ース２７を、各プロセッサモジュール１１がアクセス可
能な共用メモリ（図示省略）上に置き、排他制御、バッ
ファ制御などの処理を、システム全体で共通に行うこと
により、すなわち。

各プロセンサモジュール１１がシンメトリックに行うこ
とにより、共用処理としてのインテグリテイ保証を実現
するシステムも考えられているがログ管理等については
、第９図（ロ）に示す例と同様である。

〔発明が解決しようとする課題〕

第９図（ロ）に示すデータベースバッファ２６において
、データの格納領域についてＬＲＵ管理を行っているよ
うな場合には、高いアクセス頻度を持つデータは、なる
べくローカルメモリ２４内に配置することにより、高速
なアクセスが期待できる。このような特に参照・更新の
頻度が高い特定のデータを、ホットスポットデータとい
う。

ホットスポットデータは、データベース実体格納部１３
に反映され難いという特性を持つことから、このままの
状態が長時間にわたると、データベース実体格納部１３
のデータは、かなり以前の古い状態のままであるため、
システムクラッシュなどのシステムの異常に備えて、デ
ータベースを復旧するために保持する更新ログのログデ
ータＬ１、Ｌ２．・・・が数多く蓄積されることになる
。実際、このような状態で、システムクラッシュが発生
ずると、その復旧のためのリカバリ処理時間が非常に長
くなり、迅速なリカバリができなくなる。

しかし、システムクランシュに備えて頻繁にデータベー
ス実体格納部１３への反映を行うことが必要となるが、
これは、Ｉ１０アクセスがネックとなって、システム全
体の性能が低下するという欠点を持つ。

本発明は上記問題点の解決を図り、共用メモリを利用す
ることにより、頻繁に更新されるデータベースのリソー
スについて、異常があった場合に。

そのリカバリ処理時間を短縮する手段を提供することを
目的としている。

〔課題を解決するための手段〕

第１図は本発明の構成例を示す。

第１図において、１０は共用メモリ、１１−１゜１１−
２．・・・はプロセッサモジュール（ＰＭ）１２は各プ
ロセッサモジュール１１と共用メモリ１０とを接続する
バス、１３はデータベース実体格納部、１４はＩ１０バ
ス、２０はホットスポットデータを格納するホットスポ
ット用バッファ。

２２はホットスポット管理部、２３はホットスポット判
定部２２４は各プロセッサモジュールが持つローカルメ
モリ、２５はデータベースのアクセス状況が登録される
データベースアクセス状況表。

２６はデータベースハソファ、２７はデータベースのあ
る単位であるリソースを表す。

各プロセッサモジュール１１−１．１１−２゜・・・ば
、それぞれローカルメモリ２４を持ち、また共用メモリ
１０にバス結合されている。さらにこのシステムでは、
各プロセッサモジュールにデータベース実体格納部１３
が９例えばＩ１０バス１４を介して接続され、データベ
ース実体格納部１３に格納されたデータを、各プロセッ
サモジュールから同等にアクセスできるようになってい
る。なお、２つのバス１２．１４を１つのバスで構成し
てもよい。また、Ｉ／○バス１４の代わりに、各プロセ
ッサモジュールからコントロール可能になっているもの
を用いてもよい。

本発明では、データベースの各リソース２７に対するア
クセス回数等のアクセス状況が登録されるデータベース
アクセス状況表２５が、ローカルメモリ２４または共用
メモリ１０内に設けられる。

データベースに対するアクセスがあると、ホットスポッ
ト管理部２２により、そのリソース２７に対するアクセ
ス状況を、データベースアクセス状況表２５に登録する
。

ホットスポット判定部２３は、データベースアクセス状
況表２５に登録されたアクセス状況を参照し、アクセス
頻度が所定の基準値よりも多いデータまたはローカルメ
モリ２４に長時間滞在するデータを調べ、そのリソース
２７を、ホットスポットデータとして認識する処理を行
う。

ホットスポットデータとして認識されたリソース２７は
、共用メモリ１０内に設けられたホントスポット用バッ
ファ２０へ転送され、共用メモリ１０内に配置される。

〔作用〕

第２図は本発明の作用説明図である。

本発明では、ホントスポット制御が、第２図（ａ）〜（
Ｃ１に示す処理により実現される。

（ａ）　　ローカルなプロセッサモジュールにおけるデ
ータベースバソファ２６上でのアクセスに対して対応す
るリソース２７に対する更新回数またはバッファ上での
滞在期間等のアクセス状況を、データベースアクセス状
況表２５に登録する。

（ｂｌ　　リソース２７に対するアクセスの都度、また
は所定の時間周期で、データベースアクセス状況表２５
をチエツクし、更新が多いリソース２７゜または更新が
あってデータベースバッファ２６に長時間存在するリソ
ース２７を、ボットスポットデータと認識する。

ｆｃ）　　ホットスポットデータと判断されたリソース
２７を、データベースバッファ２６から共用メモリ１０
内のホントスポット用バッファ２０へ移す。

この時点で、ホットスポットデータは、プロセッサモジ
ュールのクラッシュに対しても消去されることのない安
定したデータとなったため、これ以降、改めてデータの
アクセス状況を管理することになる。ここで、データベ
ースアクセス状況表２５の情報は初期化する。また、同
じ理由で、このデータを復旧するためのログデータは不
要となったため、消去してもよい。

頻繁にアクセスされるデータであるホットスポットデー
タが、共用メモリ１０内に存在することにより５例えば
プロセ・７サモジユール１１−１がダウンして、ローカ
ルメモリ２４内のリソース２７が失われても、データベ
ースバッファ２６に読み出したときからの全ログデータ
によるリカバリを行うことな（、ホットスポット用バッ
ファ２０により、復旧させることができる。したがって
。

迅速なリカバリが可能になる。

また、ホットスポットデータを共用メモリ１０内に配置
することにより、以後のアクセスに対して５ホントスポ
ツト用バッファ２０の内容を直接更新することもでき、
その場合には、更新データの最新性が、共用メモリ１０
により保証されることになる。

ホットスポットデータに対する排他制御ではアクセスの
単位となるグラニユールを小さくするということで、コ
ンカレンシーを向上させることができるが、この排他制
御については、前述した参考文献１などに示されている
周知技術等の応用により１種々の方式による実現が可能
である。

〔実施例〕

１ 第３図は本発明の一実施例によるシステム構成例、第４
図は本発明の一実施例で用いる管理用データ説明図、第
５図は本発明の一実施例に係るホットスポット管理の例
、第６図は本発明の一実施例に係るホットスポットデー
タの管理形態の例第７図は本発明の一実施例における共
用・局所変更制御の例、第８図は本発明の一実施例によ
る処理動作説明図を示す。

本発明は２例えば第３図に示すようなマルヂプロセソサ
システム上で実施される。第３図において、ＳＳＵは共
用メモリ装置（Ｓｈａｒｅｄ　Ｓｔｏｒａｇｅ　ＩＪｎ
ｉｔ）、　　ＳＣＡはＩ１０インタフェースアダプタ（
ＳＣ５Ｉ　Ｃｏｎｔｒｏｌ　Ａｄａｐｔｅｒ）、　　Ｄ
Ｋはディスク記ｔａ装置ＤＬＰはデータリンクプロセッ
サ、ＤＲＣは回線制御を行うドライバ・レシーバ・カー
ドラ表ス。

各プロセッサモジュール１１は、１台または複数台のＣ
ＰＵとローカルメモリ２４とを持っている。ローカルメ
モリ２４に対しては、キャッシュメモリのような利用の
仕方でＩｌｏの削減が可能である。また、各プロセッサ
モジュール１１は２ バスコントローラ（図示省略）による制御のもとに、高
速のバス１２を介して、共用メモリ装置ＳＳＵに対する
アクセスを行うことができるようになっている。

バスオペレーションの高速化と障害対策のため。

高速のバス１２やＩ１０バス１４などは、多重化されて
いる。もちろん、−重でもよい。

各プロセッサモジュール１１は、あるプロセッサモジュ
ール１１の処理を、他のプロセッサモジュール１１が代
わりに行うことができるように構成される。したがって
、プロセッサモジュール１１の障害時には、その障害装
置をシステムから切り離して、残りのプロセッサモジュ
ールＩＩにより、サービスを続行することができるよう
になっている。

データベースの実体は、光ディスクや磁気ディスクなど
のディスク記憶装置ＤＫ等に格納され。

どのプロセッサモジュール１１からも、Ｉ１０バス１４
およびアダプタＳＣＡを介してアクセスできるようにな
っている。

このようなシステムに類似したシステムとして日経ＢＰ
社発行の「日経エレクトロニクス南４６１１９８８年１
１月２８日号Ｊ、ＰＩＩＯ〜Ｐ１１５に示されているよ
うな各種のシステムが知られているが、これらに限らず
、共用メモリをバス結合した種々のマルチプロセッサア
ーキテクチャ上で２本発明を実現することが可能である
。

本実施例では、データベースのリソースに対するアクセ
ス制御を、各プロセッサモジュール１１がジンメトリン
クに行う共用処理と、非シンメトリックに行う局所処理
とを、各リソースごとに。

静的または動的に使い分けることができるようになって
いる。詳細については、後述する。

ホットスポットデータの管理および共用／局所処理の管
理のために使用する管理用データとして例えば第４図に
示すようなデータが用意される。

第４図に示すスペース管理表３０は、データベースを管
理する空間管理情報を保持するテーブルである。本実施
例では、１つのプロセッサモジュール内に複数のアドレ
ス空間を持つことができ。

各空間に共通のカーネル（核）部によって、その空間お
よびデータベースの管理を行うようになっている。空間
異常時には、相互にバンクアンプ可能である。スペース
管理表３０は、データベース属性表３１へのポインタを
持つ。

データベース属性表３１は、リソースごとに次のような
情報を持つ。

（ａｌ　　リソース名：データベースのリソースの管理
単位ごとに付加される名前である。この名前により、実
際に配置されているデータベースのリソース２７が識別
できるようになっている。すなわち、バッファ管理情報
３２を介して、共用バ・７フアまたはローカルメモリ内
のバッファで管理されているデータとの対応がとれるよ
うになっている。

（ｂｌ　　共用／局所表示二対応するリソース２７が。

共用型で制御されているのか２局所（偏在）型で制御さ
れているのかを示すフラグ等による表示である。この表
示に従って、リソース２７やその管理情報を、共用メモ
リに配置するか否か５ などが決定される。

ｆｃｌ　　アクセス状況ポインタ：データベースアクセ
ス状況表２５をポイントする。

（ｄ）　　データベース配置情報二局所型の場合に、そ
のインテグリテイを保証するプロセッサモジュールの識
別子を持つ。

データベースアクセス状況表２５は、各リソースごとの
アクセス状況の管理のために、各プロセッサモジュール
が何回そのリソースにアクセスしたかを示す次のような
情報を持つ。

ｆａ）　　ＰＭ−ＩＤ：そのリソースに直接またはアク
セス依願により間接的にアクセスしたプロセッサモジュ
ールの識別子である。

（ｂｌ　　参照回数・更新回数：プロセッサモジュール
ごとの参照または更新のアクセス回数である。

第４図に示す管理用データの制御表は、共用メモリ内や
プロセッサモジュール内のローカルメモリに配置されて
いる。

リソースが局所型の場合、データベース属性表３１、デ
ータベースアクセス状況表２５は、その　１６ 局所制御を行っているプロセッサモジュールのローカル
メモリに存在する。

リソースが共用型の場合、データベース属性表３１は、
共用メモリ上にあるが、データベースアクセス状況表２
５は、共用メモリ上と各プロセッサモジュール内のロー
カルメモリ上に配置されプロセッサモジュールは、その
プロセッサモジュールのアクセス状況だけの情報を更新
している。

共用メモリ上には、ある時間間隔で、各プロセッサモジ
ュールから、アクセス状況のデータが収集されるように
なっている。

ホットスポットデータの認識では、特にデータベースア
クセス状況表２５に記録された更新回数などを判定の基
準に用いる。

データベースアクセス状況表２５に対するアクセス状況
の登録は２例えば第５図（イ）に示すように行う。

データに対するアクセス要求があると、データベースバ
ッファ管理部５０は、ホントスポット管理部２２へ、リ
ソース名、アクセス・モードなどを通知する。ホントス
ポット管理部２２は、対応するリソースのデータベース
アクセス状況表２５におけるアクセス回数を更新する。

ログ量の観点から、異常時における対応する復旧時間を
短くするために、更新回数のカウントは、そのデータが
データバッファ上に読み込まれた時点から開始する。ま
たは、データバッファ上における滞在時間を登録しても
よい。

アクセス状況によるホントスポンドデータの認識は、第
５図（ロ）〜（ニ）に示すいずれの契機に行うことも可
能である。

第５図（ロ）は、データベースのアクセス時にホットス
ポットデータをチエツクする例を示す。

データベースアクセスモジュール５１に、アクセス依願
があると、更新の場合に、ログ管理部５２により、ログ
データを採取するとともに、データベース格納アクセス
管理部５３に、アクセスを依願する。データベース格納
アクセス管理部５３は、データベースバッファ管理部５
０に対し、アクセス要求を出す。データベースハソファ
管理部５０からの通知により、ホットスポット管理部２
２は、ホットスポット判定部２３によって、ホットスポ
ットデータのチエツクを行う。

第５図（ハ）は、ログのデータ量が、ある水準以上にな
ったときをトリガとして、ホットスポットデータの判定
を行う例を示している。

ログのデータ量がリカバリ処理時間に影響するため、そ
れまでのログデータ量またはログ取得の時間が長いかど
うかでも、リカバリ処理効率の判定になる。そのため、
ログデータの取得契機（例えば各トランザクションの終
了時）に、ログ管理部５２が、ログデータ量等をチエツ
クし、ある基準値を超える場合に、そのリソースをホッ
トスポットデータの候補として、ホントスポット管理部
２２に通知する。これを契機として、ホントスポット判
定部２３により、ホットスポットデータの判定を行う。

その処理は１例えば第５図（ホ）に示すようになる。第
５図（ホ）に示すように、定常時にログ領域がオーバフ
ローすることを防くため、使用可１９〜 能な闇値の設定を行う。システムの起動時に省略値を設
定しておいてもよい。次に、トランザクションのコミッ
ト時などのログ領域を使用する段階等で、使用中のログ
量を算出する。そして、ログ量と闇値との大小を調べ、
ポットスポットの判定処理を起動するか、ポットスポッ
トに関する処理を行わないかを決定する。

第５図（ニ）は、所定の時間間隔で、ホットスポットデ
ータのチエツクを行う例である。

ホットスポット管理部２２を、タイマ等により所定の周
期で起動するようにしておき、定期的にホントスポット
判定部２３によって、アクセス状況に基づくホットスポ
ットデータの検出を行う。

その処理は２例えば第５図（へ）に示すようになる。ま
ず、ホントスポット判定時間間隔を設定する。これは、
システム起動時に省略値を設定しシステム利用者からの
指定やログ量の状況により。

その値を変更する。

そして９時間監視により、所定の時間が経過したかどう
かを判定し、ホットスポットの判定処理０ を起動するかホントスポットに関する処理は行わないか
を決定する。

ホットスポットデータは、共用メモリ１０またはローカ
ルメモリ２４を利用したデータベースバッファの配置に
依存して、その管理方式が変化する。次に５それらの各
種管理形態の例を、第６図に従って説明する。

第６図（イ）は、共用メモリだけに、データベースバッ
ファを配置する場合の例である。

共用型によりリソースを管理する場合であって。

各プロセッサモジュールＰＭＩ、ＰＭ２等からのアクセ
ス頻度が高い場合に、この形態となる。特に、全体がホ
ントスポンドという位置付けであり。

各プロセッサモジュールは、共用メモリ上のバッファに
直接アクセスする。トランザクション途中の更新に応じ
て、ログデータを取得する。

第６図（ロ）は、共用メモリにリソース（Ｒ１）の原型
を置き、ローカルメモリにリソース（Ｒ１）のコピーを
配置する場合の例である。

リソースのコピーが、各ローカルメモリにあるため、各
プロセッサモジュールにおける高速アクセスが可能であ
る。したがって、長時間、ローカルメモリ内に滞在する
ページ（データの単位）が出てくるが、ホットスポット
管理による定期的な非同期の転送により、更新内容を共
用メモリ上のバッファに書き出し、対応するログデータ
を少なくする。

第６図（ハ）は、共用メモリにはデータベースバッファ
がなく、ローカルメモリにのみ、各々がリソース（Ｒ１
）のコピーを持つ場合の例である。

ローカルメモリ上で高速なアクセスを行う。したがって
、長時間、ローカルメモリ上に滞在するページが出てく
る。これについて、二次記憶上に追い出す代わりに、共
用メモリを使用し、ホットスポットデータとして、非同
期的に共用メモリへの転送を行う。

第６図（ニ）は、アクセスが特定のプロセッサモジュー
ルに偏在する局所処理データについて。

その各々のリソースを、特定のプロセッサモジュールに
おけるローカルメモリにのみ配置させる場合の例である
。

ログデータ量を効率よく減らし、リカバリ処理時間を短
縮するために、ホットスポットデータについて、共用メ
モリ上に退避する。

局所処理データが、複数のプロセッサモジュールにおけ
るローカルメモリにコピーされている場合にも、第６図
（ニ）示す形態と同様である。

第６図（ハ）および（ニ）に示す形態は、共用メモリを
いわばハックアップ用の記憶装置として使用した形にな
る。

本実施例では、リソース管理について、共用処理管理と
局所処理管理ができるようになっているが、以下、その
動的な変更制御について、第７図に従って説明する。

局所処理の場合、リソースに対するアクセスのための排
他制御やバッファ制御を、そのリソースを管理する特定
のプロセッサモジュールが行う。

リソースに対するアクセスが、特定のプロセッサモジュ
ールに偏在している場合、排他制御やバ・ソファ制御を
局所的に行うことにより、大部分のア３ クセス制御を高速化することが可能になる。

共用処理の場合、インテグリテイ保証をシステム全体に
ついて行う。アクセスが特定のプロセッサモジュールに
偏在することなく、各々のプロセッサから均等にアクセ
スされるようなリソースについては、特定のプロセッサ
モジュールに対する負荷の集中を回避し、また、特定の
プロセッサに対するアクセス依頼などの通信コストの増
大を防ぐことが可能になり、システム全体としてのスル
ープットを向上させることができる。

そこで、第７図に示すように、アクセスが特定のプロセ
ッサモジュールに偏在する場合１局所処理管理とし、偏
在傾向が解消した場合、共用処理管理とするように動的
に変更制御を行う。これにより、リソースのアクセス状
況に応じた最適なアクセス管理を行うことができるよう
になる。

共用処理管理を行うか２局所処理管理を行うかなどによ
って、第６図に示す各種ホットスポットデータの管理形
態のパターンが選択されることになる。

４ 以下、その処理動作について、第８図に従って説明する
。以下の説明における■〜■は、第８図に示す■〜■に
対応する。

■　共用・局所管理部６０は、データベースアクセス状
況表２５を参照し、リソースに対するアクセスが、特定
のプロセッサモジュールに偏在するかどうかを検査し、
リソースに対する共用型／局所型を決定する。共用／局
所を変更する場合には。

データベース属性表３１の共用／局所表示を変更する。

■　データベースパソファ管理部５０は、リソースが共
用型であるか局所（偏在）型であるかによって、データ
ベースバッファの配置を決める。ローカルメモリにコピ
ーを持つかどうかは、該当ページのアクセス時に決定す
る。基本的にはコピーを持つものとする。

■　データベースに対するアクセスに対して、ホットス
ポット管理部２２を介して、または直接的にデータベー
スアクセス状況表２５にアクセス状況を登録する。

■　ホントスポット判定部２３は、データベースアクセ
ス状況表２５を参照し、ボットスボッｉ・データである
かどうかを決定する。その結果を、再度アクセス状況と
して登録する。

■　データベースハソファ管理部５０は、データベース
アクセス状況表２５に従って、ホットスポットデータの
管理を、ホントスポット管理部２２に依頼する。

なお１本発明の実施にあたって、ホットスポットデータ
の管理を行う場合に、前述した第６図に示す形態のすべ
てを採用する必要はなく２例えば。

局所型のものについてだけ適用するようにしてもよい。

〔発明の効果〕

以上説明したように１本発明によれば、マルチプロセッ
サアーキテクチャの特性を活かし、頻繁に更新されるよ
うなデータベースのリソースについて、共用メモリを利
用することにより、ログデータ量を少なくシ、異常発生
時におけるすカバリ処理時間を短縮することが可能にな
る。

【図面の簡単な説明】

第１図は本発明の構成例。 第２図は本発明の作用説明図 第３図は本発明の一実施例によるシステム構成例。 第４図は本発明の一実施例で用いる管理用データ説明図
。 第５図は本発明の一実施例に係るホットスポット管理の
例。 第６図は本発明の一実施例に係るホットスボッ！・デー
タの管理形態の例 第７図は本発明の一実施例における共用・局所変更制御
の例。 第８図は本発明の一実施例による処理動作説明図 第９図は従来技術の例を示す。 図中、１０は共用メモリ、１１−Ｌ　　１１−２・・は
プロセッサモジュール、１２はバス、１３は７ データベース実体格納部、１４はＩ１０バス、２０はホ
ントスポット用ハソファ、２２はホットスポット管理部
、２３はホントスポット判定部、２４はローカルメモリ
、２５はデータベースアクセス状況表、２６はデータベ
ースハソファ、２７はリソースを表す。 ８

Claims (1)

1. 【特許請求の範囲】 それぞれローカルメモリ（２４）を持つ複数のプロセッ
   サモジュール（１１−ｉ）と、これらの各プロセッサモ
   ジュールにバス結合される共用メモリ（１０）とを備え
   たマルチプロセッサシステムによるデータベース処理に
   おけるホットスポットデータ管理処理方式であって、 データベースの各リソースに対するアクセス状況が登録
   されるデータベースアクセス状況表（２５）と、 データベースアクセス状況表に登録されたアクセス状況
   により、ホットスポットデータを判定するホットスポッ
   トデータ判定部（２３）と、ホットスポットデータと判
   定されたデータが格納される上記共用メモリ内に設けら
   れるホットスポット用バッファ（２０）とを備え、 アクセス頻度が多いデータまたはローカルメモリに長時
   間滞在するデータについて、ホットスポットデータとし
   て、共用メモリ上に配置するようにしたことを特徴とす
   るホットスポットデータ管理処理方式。