JP2004295790A - 記憶装置のキャッシュ管理方法 - Google Patents
記憶装置のキャッシュ管理方法 Download PDFInfo
- Publication number
- JP2004295790A JP2004295790A JP2003090360A JP2003090360A JP2004295790A JP 2004295790 A JP2004295790 A JP 2004295790A JP 2003090360 A JP2003090360 A JP 2003090360A JP 2003090360 A JP2003090360 A JP 2003090360A JP 2004295790 A JP2004295790 A JP 2004295790A
- Authority
- JP
- Japan
- Prior art keywords
- cache
- data
- information
- storage device
- amount
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
- G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
- G06F12/0866—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches for peripheral storage systems, e.g. disk cache
- G06F12/0871—Allocation or management of cache space
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
- G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
- G06F12/0866—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches for peripheral storage systems, e.g. disk cache
- G06F12/0873—Mapping of cache memory to specific storage devices or parts thereof
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
- G06F12/12—Replacement control
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
- G06F2212/28—Using a specific disk cache architecture
- G06F2212/282—Partitioned cache
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
- Y10S707/99953—Recoverability
Abstract
【課題】データベース管理システム（ＤＢＭＳ）が稼動する計算機システムにおける記憶装置のキャッシュ量の設定を好適化する。
【解決手段】設計情報として与えられるＤＢＭＳで実施される処理に関する情報を取得し、それを基にデータ毎に利用するキャッシュ量を設定する。例えば、ＤＢＭＳの異常終了後の処理の再実行時間を考慮して、ＤＢＭＳが書き出すログに対するキャッシュ量を調整する。また他の例では、処理内容とデータのおよそのアクセス特性から、表・索引データに対するキャッシュ量の初期割り当てを好適化する。更に他の例では、処理の事前解析結果と稼動統計情報と組み合わせてキャッシュ量チューニングによる処理時間の変化を見積り、キャッシュ効果を向上させる。
【選択図】 図１
【解決手段】設計情報として与えられるＤＢＭＳで実施される処理に関する情報を取得し、それを基にデータ毎に利用するキャッシュ量を設定する。例えば、ＤＢＭＳの異常終了後の処理の再実行時間を考慮して、ＤＢＭＳが書き出すログに対するキャッシュ量を調整する。また他の例では、処理内容とデータのおよそのアクセス特性から、表・索引データに対するキャッシュ量の初期割り当てを好適化する。更に他の例では、処理の事前解析結果と稼動統計情報と組み合わせてキャッシュ量チューニングによる処理時間の変化を見積り、キャッシュ効果を向上させる。
【選択図】 図１
Description
【０００１】
【発明の属する技術分野】
本発明は記憶装置のキャッシュ管理方法に係り、特にデータベース管理システム（ＤＢＭＳ）が稼動する計算機システムにおける記憶装置のキャッシュ量の設定管理に関する。
【０００２】
【従来の技術】
サーバ計算機上で実行されるアプリケーションプログラム（ＡＰプログラム）のソフトウェア構成を調べると、データベース（ＤＢ）を基盤として利用するものが多数を占め、ＤＢに関する一連の処理・管理を行うソフトウェアであるデータベース管理システム（ＤＢＭＳ）は極めて重要なものとなっている。
【０００３】
ＡＰプログラムの利用に際し、業務毎に定まる要求性能が存在し、それを守ることが強く求められており、それは計算機システム管理の中で極めて重要なものとなっている。ＤＢＭＳの性能は、データへのアクセス性能から多大な影響を受ける。
そのため、記憶装置へのアクセス性能の向上が極めて重要である。
【０００４】
一般的に、ディスク装置を多数保持する記憶装置においては、記憶装置内にデータを一時的に保管する高速アクセス可能なデータキャッシュを用意し、データリード時にデータがキャッシュに存在している状態（ヒット）を作り出すことによりアクセス性能を向上させる手法を用いる。米国特許第５，４３４，９９２号明細書（特許文献１）では、データ種類毎に区分化されたキャッシュ領域を持つ場合に、その領域割り当てを最適化してキャッシュヒット率を向上させる技術について開示している。ＬＲＵ置換アルゴリズムによるキャッシュデータ置換制御を行うシステムで、キャッシュヒット時にＬＲＵ管理リスト中のどの位置に存在するかの情報を取得し、その情報を用いて領域割り当て変更時のキャッシュヒット率の見積を行い、領域分割の最適化を行う。
【０００５】
また、一般に、ファイルキャッシュ等の形で計算機上にもキャッシュが存在する。論文（非特許文献１）においては、計算機上のファイルキャッシュと記憶装置上のデータキャッシュを排他的に利用することにより、データへのアクセス性能を向上させる技術について論じている。この技術では、計算機上で保持されなくなったデータを記憶装置でキャッシュ化させる機構を利用する。記憶装置は、原則ＬＲＵ置換アルゴリズムによりキャッシュデータ置換制御を行うが、記憶装置内のディスク装置から読み出したデータはＬＲＵ管理リスト中のＬＲＵ端に挿入し、そのデータが記憶装置のデータキャッシュに留まらないように制御する。更に、キャッシュヒット率をより一層向上させるため、ディスク装置から読み出されたデータと計算機から与えられたデータのそれぞれに関して、ゴーストＬＲＵキャッシュと称するそれぞれ独立したＬＲＵ管理リストを用いることにより、全体を管理するＬＲＵ管理リスト中の初期挿入位置を最適化する方法についても論じている。
【０００６】
【特許文献１】
米国特許 第５，４３４，９９２号明細書
【非特許文献１】
Ｔｈｅｏｄｏｒｅ Ｍ． Ｗｏｎｇ ａｎｄ Ｊｏｈｎ Ｗｉｌｋｅｓ、 溺ｙ ｃａｃｈｅ ｏｒ ｙｏｕｒｓ？ Ｍａｋｉｎｇ ｓｔｏｒａｇｅ ｍｏｒｅ ｅｘｃｌｕｓｉｖｅ ＵＳＥＮＩＸ Ａｎｎｕａｌ Ｔｅｃｈｎｉｃａｌ Ｃｏｎｆｅｒｅｎｃｅ （ＵＳＥＮＩＸ ２００２）， ｐｐ． １６１−１７５、 １０−１５ Ｊｕｎｅ ２００２
【０００７】
【発明が解決しようとする課題】
一般的に、ＤＢＭＳにより管理されるデータは、その内容や利用目的により明確に分類される。それらは、それぞれでアクセスの特性が大きくなる。データの中には、必要とされる特性を事前に明確化することができるものもある。しかし、従来の技術では、それらの特徴を必ずしも考慮していない。
【０００８】
特許文献１の技術では、キャッシュを分割化し、データの種類により独立した領域を割り当てるため、データ毎のアクセス特性の差を扱うことができるが、データや処理の内容までは考慮されていない。非特許文献１の技術では、データ毎のアクセス特性の差を扱うことについては特に何も考慮されていない。
【０００９】
本発明の目的は、ＤＢＳＭが稼動する計算機システムにおいて、記憶装置のキャッシュ量を最適に設定し、性能管理コストを削減することである。
【００１０】
本発明の他の目的は、データの利用目的や処理内容等から生じるデータのアクセス特性の違いに基づいて記憶装置のデータキャッシュを効果的に割当てることにある。
【００１１】
本発明の更に他の目的は、データキャッシュのアクセスに関する稼動の統計情報に基づいて、データキャッシュの量をチューニングすることにより、キャッシュの効果を向上させることにある。
【００１２】
【課題を解決するための手段】
本発明は、設計情報として与えられるＤＢＭＳで実行される処理に関する情報を取得し、それを基にデータ毎に利用するキャッシュ量を設定するものである。
【００１３】
そのために本発明は、ＤＢＭＳが書き出すログに対するキャッシュ量を調整する。
ログは、ＤＢＭＳが異常終了した後の再起動時に処理の再実行（Ｒｅ−Ｒｕｎ）や取り消し（Ｕｎｄｏ）を実施するためにＤＢＭＳが出力する情報である。それらの処理を高速に実施する必要がある場合に、その際に利用されるログは全て記憶装置のキャッシュ上に存在するようにし、ログの読み出しを高速化する。Ｒｅ−Ｒｕｎ処理時間（Ｕｎｄｏ処理時間も含む）への要求値を基に読み出されるべきログの量を把握し、その分のログは記憶装置のキャッシュ上に存在することができるようなキャッシュ量を設定する。
【００１４】
本発明はまた、表・索引データに対するキャッシュ量の初期割り当てを好適化する。ＤＢＭＳで実施される処理の組があらかじめ明確になっている場合、処理内容の解析からあるデータ全体へのアクセス量はおおよその見当がつく。データ内でのおおよそのアクセス特性を与え、それと処理内容の解析結果を基に、ある量のキャッシュを割り当てた場合のキャッシュヒット率の概算値を求め、データに対して割り当てるキャッシュ量を決定する。
【００１５】
本発明はまた、稼動統計情報と組み合わせたキャッシュ量チューニングによるキャッシュ効果の向上である。事前解析により得た処理が利用するデータページ数の期待値と処理実行時の稼動統計情報を組み合わせることにより、問題と判断された処理や処理全体におけるキャッシュ量変更時の処理時間の変化を見積り、それを基に好適なキャッシュの割り当て方法を提供する。
なお、上記発明において、データ毎のアクセス特性の差を扱うため、記憶装置のキャッシュを区分化し、データ毎に独立したキャッシュ領域を割り当てる。
【００１６】
【発明の実施の形態】
以下、本発明の実施の形態を説明する。なお、これにより本発明が限定されるものではない。
・第一の実施の形態
第一の実施の形態は、ＤＢＭＳで実施される処理の設計情報からＤＢＭＳが書き出すログに対するキャッシュ量を調整するものである。ここで、処理とはＤＢＭＳにより実施される処理である。また設計情報とは、ＤＢＭＳに求められている機能や性能を実現するための情報であって、ＤＢＭＳに実行させる処理の内容を規定する情報や、ＤＢＭＳじ実行させる処理の実行条件を規定する情報のことを言う。例えば設計によりそれぞれの処理に対応するＳＱＬ文が作成され、複数のＳＱＬ文により１つの処理が実施されるが、これらはその処理の詳細を設計する際に見積もられる。またログは、ＤＢＭＳが異常終了した後の再起動時に処理のＲｅ−ＲｕｎやＵｎｄｏを実施するためにＤＢＭＳが出力する情報である。それらの処理を高速にする必要がある場合に、その際に利用されるログは全て記憶装置のキャッシュ上に存在するようにし、ログの読み出しを高速化する。Ｒｅ−Ｒｕｎ処理時間（Ｕｎｄｏ処理時間も含む）への要求値を基に読み出されるべきログの量を把握し、その分のログは記憶装置のキャッシュ上に存在することができるようなキャッシュ量の設定を実現する。
【００１７】
図１は、本発明の一実施形態による計算機システムの構成を示す図である。
計算機システムは、記憶装置４０、記憶装置４０を使用する計算機（以下「サーバ」）７０、システム管理を行う計算機（以下「管理サーバ」）１２０、及び記憶領域の仮想化処理を行う仮想化スイッチ６０を有して構成される。各々の装置はネットワークインタフェース（ネットワーックＩ／Ｆと略す）２２を有し、それらのＩ／Ｆを介してネットワーク２４に接続され、相互に通信可能である。
【００１８】
サーバ７０、仮想化スイッチ６０、及び記憶装置４０は各々Ｉ／ＯパスＩ／Ｆ ３２を有し、それを介して通信線（以下「Ｉ／Ｏパス」）３４により接続される。サーバ７０と記憶装置４０間のＩ／Ｏ処理はＩ／Ｏパス３４を用いて行われる。尚、Ｉ／Ｏパス３４は、装置間で異なる物理媒体や異なるプロトコルでデータ転送を行う通信線が用いられてもよい。また、ネットワーク２４とＩ／Ｏパス３４が同一の通信線でもよい。
【００１９】
記憶装置４０は、ＣＰＵ １２、メモリ１４、ディスク装置（以下「ＨＤＤ」）１６、ネットワークＩ／Ｆ ２２、Ｉ／ＯパスＩ／Ｆ ３２を有し、それらは内部バス１８で接続される。なお、ＨＤＤ １６は例えばＲＡＩＤ構成のディスク装置が好ましいが、必ずしもＲＡＩＤ構成でなくても良いし、単体又は複数のＨＤＤでも良い。メモリ１４は不揮発領域と高性能領域を有する。
【００２０】
記憶装置４０を制御するプログラムである制御プログラム４４はメモリ１４の不揮発領域に記憶され、起動時にメモリ１４の高性能領域へ移された後にＣＰＵ １２により実行される。記憶装置４０が有する機能は、全て制御プログラム４４により制御されて、実現される。メモリ１４には制御プログラム４４が記憶装置４０を制御、管理するために利用する管理情報４６が記憶される。更に、メモリ１４の一部は外部装置からアクセス要求のあったデータを一時的に記憶しておく領域であるデータキャッシュ４２に割り当てられる。
【００２１】
記憶装置４０は、ＨＤＤ １６が有する物理記憶領域を仮想化して１又は複数の論理ディスク装置（以下、「ＬＵ」と称す） ２０８（詳細説明は図２参照）を外部装置に対して提供する。ＬＵ ２０８は、ＨＤＤ １６と一対一に対応してもよいし、複数のＨＤＤ １６から構成される記憶領域と対応してもよい。また、１つのＨＤＤ１６が複数のＬＵ２０８に対応してもよい。その対応関係は管理情報４６中に領域マッピング情報３００の形で保持される。
【００２２】
記憶装置４０では、ＬＵ ２０８を単位として記憶領域のグループ化が行われ、そのグループ毎に独立したデータキャッシュ４２内の領域が割り当てられる。以下、このＬＵ ２０８のグループを「キャッシュグループ」と称する。その構成は、管理情報４６中にキャッシュグループ情報４６０の形で保持される。キャッシュグループの作成・削除や、それに所属するＬＵ２０８の追加・削除は動的（以下「他の処理を停止させることなく実施される」の意味で利用）に行える。また、キャッシュグループへのデータキャッシュ４２の割当量を動的に変更する機能を有する。
【００２３】
記憶装置４０は、外部からの要求に応じて、領域マッピング情報３００（詳細は図３参照）やキャッシュグループ情報４６０（詳細は図４参照）、その他記憶装置４０の構成情報を、ネットワーク２４を介して外部に送信する機能を有する。また、外部装置からネットワーク２４を介して外部から受信した指示に従い、前述の各種機能を実行する機能を有する。
【００２４】
仮想化スイッチ６０は、ＣＰＵ １２、メモリ１４、ネットワークＩ／Ｆ ２２、Ｉ／ＯパスＩ／Ｆ ３２を有し、それらは内部バス１８で接続される。メモリ１４は不揮発領域と高性能領域を有する。
【００２５】
仮想化スイッチ６０を制御するプログラムである制御プログラム６４はメモリ１４の不揮発領域に記憶され、起動時にメモリ１４の高性能領域へ移された後にＣＰＵ １２により実行される。仮想化スイッチ６０が提供する機能は、全て制御プログラム６４により制御される。また、メモリ１４には制御プログラム６４が仮想化スイッチ６０を制御、管理するために利用する管理情報６６が記憶される。
【００２６】
仮想化スイッチ６０は、本装置に接続された記憶装置４０から提供されるＬＵ ２０８を認識し、その記憶領域を仮想化して仮想ボリューム２０６を外部装置（例えばサーバ７０や他の仮想化スイッチ６０）に提供する。尚、仮想化スイッチ６０が多段接続された場合には、他の仮想スイッチ６０が提供する仮想ボリューム２０６を記憶装置４０から提供されるＬＵ ２０８と等価に扱い、その記憶領域を仮想化して仮想ボリューム２０６を外部装置に提供する。その対応関係は管理情報６６中に領域マッピング情報３００の形で保持される。仮想化スイッチ６０は、外部からの要求に応じて、領域マッピング情報３００やその他構成情報を、ネットワーク２４を介して外部に送信する機能を有する。
サーバ７０は、ＣＰＵ１２、メモリ１４、ＨＤＤ１６、ネットワークＩ／Ｆ ２２、Ｉ／ＯパスＩ／Ｆ ３２を有し、それらは内部バス１８で接続される。メモリ１４上には、オペレーティングシステム（ＯＳ）７２と管理エージェント１４４がＨＤＤ１６から読み込まれ、ＣＰＵ１２により実行される。
【００２７】
ＯＳ７２は、サーバ７０上で実行されるプログラム対して、ネットワークＩ／Ｆ ２２、Ｉ／ＯパスＩ／Ｆ ３２等のハードウェア制御や、ネットワーク２４を介した他の装置との通信、Ｉ／Ｏパス３４を通してのデータ転送処理、複数プログラム間の実行制御等、基本的な処理機能を提供するプログラム群であり、ボリュームマネージャ７８、ファイルシステム８０を含む。メモリ１４上に読み込まれたＯＳ７２は、それらや他のＯＳ７２を構成するプログラムが利用する管理情報であるＯＳ管理情報７４を有する。ＯＳ管理情報７４は、サーバ７０のハードウェア構成の情報を含む。ＯＳ７２は、ＯＳ管理情報７４中に記憶されている情報を外部プログラムが読むためのソフトウェアインターフェイスを有する。なお、本図では、サーバ７０は１つのファイルシステム８０しか有していないが、複数のファイルシステム８０を有してもよい。
【００２８】
ボリュームマネージャ７８は、記憶装置４０から提供されるＬＵ ２０８や仮想化スイッチ６０から提供される仮想ボリューム２０６の記憶領域を仮想化し、論理ボリューム２０４をファイルシステム８０に提供するプログラムである。その対応関係はＯＳ管理情報７４中に領域マッピング情報３００の形で保持される。また、ボリュームマネージャ７８は複数Ｉ／Ｏパス３４を利用したＩ／Ｏ処理の負荷分散機能を有してもよい。
【００２９】
ファイルシステム８０は、記憶装置４０から提供されるＬＵ ２０８や仮想化スイッチ６０から提供される仮想ボリューム２０６、ボリュームマネージャ７８から提供される論理ボリューム２０４の記憶領域を仮想化し、ファイル２０２を他のプログラムに提供するプログラムである。その対応関係はＯＳ管理情報７４中に領域マッピング情報３００の形で保持される。なお、ファイル２０２と同じソフトウェアインターフェイスで、論理ボリューム２０４、仮想ボリューム２０６、ＬＵ ２０８の記憶領域に直接アクセスする機能であるローデバイス機能も、ファイルシステム８０により提供されるとする。
【００３０】
管理エージェント１４４は、管理サーバ１２０上で実行されるシステム管理プログラム１４０からネットワーク２４を介して受け付けた処理要求をサーバ７０で実行し、必要に応じてその結果を、ネットワーク２４を介してシステム管理プログラム１４０に返信するプログラムである。管理エージェント１４４が行う処理は、
（１）ＯＳ管理情報７４中に記憶されている情報の読み出し、（２）ＤＢＭＳ管理情報９２中に記憶されている情報の読み出し、等である。
【００３１】
ＤＢＭＳ９０は、ＤＢに関する一連の処理・管理を実行するサーバ７０上で実行されるプログラムである。本プログラムは、ＨＤＤ１６もしくは記憶装置４０からメモリ１４に読み出されてＣＰＵ１２により実行される。メモリ１４上に読み込まれたＤＢＭＳ９０は、それが利用・管理する表・索引・ログ等（以下、まとめて「データ構造」と称する）の記憶領域の管理情報であるデータ記憶領域情報３４２を含む、ＤＢＭＳ９０の管理情報であるＤＢＭＳ管理情報９２を有する。ＤＢＭＳ９０は、ＤＢＭＳ管理情報９２を外部プログラムが読むためのソフトウェアインターフェイスを有する。ＤＢＭＳ９０は、１台のサーバ７０上で複数同時に実行することができる。
【００３２】
ＯＳ７２やＤＢＭＳ９０、管理エージェント１４４はＣＤ−ＲＯＭ（記憶媒体）に記憶されている。ＣＤ−ＲＯＭの内容は、管理サーバ１２０が有するＣＤ−ＲＯＭドライブ２０によって読み出され、ネットワーク２４を介してサーバ７０内のＨＤＤ１６もしくは記憶装置４０にインストールされる。
【００３３】
管理サーバ１２０は、ＣＰＵ１２、メモリ１４、ＨＤＤ１６、ＣＤ−ＲＯＭドライブ２０、ネットワークＩ／Ｆ ２２を有し、それらは内部バス１８で接続される。
【００３４】
メモリ１４上には、ＯＳ７２とシステム管理プログラム１４２がＨＤＤ１６から読み込まれ、ＣＰＵ１２により実行される。ＣＤ−ＲＯＭドライブ２０は、各種プログラムのインストールに用いられる。
【００３５】
管理サーバ１２０には、キーボード・マウス等の入力装置１１２および表示画面１１４を有する管理端末１１０がネットワーク２４を介して接続される。この接続は、ネットワーク２４とは異なる通信線を用いてもよく、管理サーバ７２と管理端末１１０が一体で構成されてもよい。管理者は、通常管理端末１１０を用いて情報の入出力を行うが、必要に応じてＣＤ−ＲＯＭドライブ２０を用いることもある。
【００３６】
システム管理プログラム１４０は、管理サーバ１２０が有する、システム管理機能を実現するプログラムである。ＨＤＤ１６からメモリ１４上に読み込まれ、ＣＰＵ１２により実行される。システム管理プログラム１４０は、その機能を実現するために必要な管理情報であるシステム管理情報１４２を有する。本プログラムはＣＤ−ＲＯＭに記憶されており、その内容は管理サーバ１２０が有するＣＤ−ＲＯＭドライブ２０によって読み出され、ＨＤＤ１６にインストールされる。
【００３７】
システム管理プログラム１４０は、他の装置から種々の情報を取得する。このとき、記憶装置４０と仮想化スイッ６０が保持する情報に関しては、ネットワーク２４を介して直接情報の送信要求を発行し、情報を取得する。また、サーバ７０上で実行されるプログラムが保持する情報に関しては、ネットワーク２４を介して管理エージェント１４４に対して情報の読み出し要求を発行し、それが必要な情報を読み出すことにより情報を収集する。
【００３８】
システム管理プログラム１４０は、記憶装置４０、仮想化スイッチ６０、ボリュームマネージャ７８、ファイルシステム８０（以下、これらをまとめて「仮想化機構」と称する）が保持する領域マッピング情報３００を、ＤＢＭＳ９０からデータ記憶領域情報３４２を、記憶装置４０からキャッシュグループ情報４６０を取得し、それらを取得元の識別子とともにマッピング集約情報としてシステム管理情報１４２中に記憶する。
【００３９】
また、システム管理プログラム１４０は、記憶装置４０のキャッシュグループの管理において、ある特定のキャッシュグループをキャッシュ割当量の調整で優先的に削減対象とする「フリーキャッシュグループ」として扱う。特にキャッシュ量の割り当て要求がないＬＵ２０８は、フリーキャッシュグループに属するとして制御する。
【００４０】
なお、図１では、システム管理プログラム１４０は管理サーバ１２０上で実行されているが、任意のサーバ７０、仮想化スイッチ６０、記憶装置４０上で実行されてもよい。このとき、サーバ７０ではシステム管理プログラム１４０はＨＤＤ１６に記憶され、メモリ１４に読み出された後にＣＰＵ１２により実行される。仮想化スイッチ６０、記憶装置４０ではメモリ１４の不揮発領域に記憶され、メモリ１４の高性能領域に移された後にＣＰＵ１２により実行される。
【００４１】
図２は、本実施の形態におけるＤＢＭＳ９０が管理するデータのデータマッピングの階層構成を示す図である。
図２を参照してサーバ７０と記憶装置４０との間に１つの仮想化スイッチ６０が存在する場合を説明する。以下、ある２つの階層について、ＤＢＭＳ９０に近い方を上位、ＨＤＤ１６に近い方を下位の階層と称する。ファイル２０２、論理ボリューム２０４、仮想ボリューム２０６、ＬＵ ２０８をまとめて「仮想構造」と称し、更に、仮想構造にＨＤＤ１６を加えたものをまとめて「管理構造」と称する。
【００４２】
図２では、ＤＢＭＳ９０は、それが管理しているデータ構造２００を記憶しているファイルシステム８０が提供するファイル２０２に対してアクセスを行う。ファイルシステム８０は、ファイル２０２に対するアクセスを対応する論理ボリューム２０４の領域へのアクセスに変換する。ボリュームマネージャ７８は、論理ボリューム２０４に対するアクセスを対応する仮想ボリューム２０６の領域へのアクセスに変換する。仮想化スイッチ６０は、仮想ボリューム２０６に対するアクセスを対応するＬＵ ２０８の領域へのアクセスに変換する。記憶装置４０は、ＬＵ ２０８に対するアクセスを、対応するＨＤＤ１６に対するアクセスに変換する。このように、仮想化機構は、それが上位階層に提供する仮想構造のデータを下位階層に存在する１つ以上の管理構造の記憶領域にマッピングする。
【００４３】
また、図示しないが、ある仮想構造のデータの同一部分が複数の下位階層の管理構造にマッピングされてもよい。また、ある仮想構造のデータがＨＤＤ１６にマッピングされる経路が複数存在してもよい。これらの場合には、仮想化機構が、そのようなマッピングであることを領域マッピング情報３００中に保持しておく。
【００４４】
ある管理構造が複数のサーバ７０に共有されるマッピングを有してもよい。これは、フェイルオーバ構成をとるサーバ７０とその上で実行されるＤＢＭＳ９０において利用される。
【００４５】
本実施の形態では、論理層２１２における管理構造間のデータの対応関係が明確化されればよく、サーバ７０でボリュームマネージャ７８が使用されなくてもよい。仮想化スイッチ６０は複数段存在してもよいし、仮想化スイッチ６０が存在せずにサーバ７０と記憶装置４０がＩ／Ｏパス３４により直結されてもよい。仮想化スイッチ６０に相当するスイッチが記憶領域の仮想化機能を有しなくてもよく、この場合、仮想化スイッチ６０が下位階層から提供された管理構造をそのまま上位階層へ仮想構造として提供していると考える。
【００４６】
必須事項ではないものの、後述する記憶装置４０におけるキャッシュ量の調整においては、１つのＬＵ ２０８に１つのデータ構造２０８のみが記憶されるようにマッピングを作成すると、異なるデータを同一のキャッシュグループに混在させずに済み、その効果を高めることができる。
【００４７】
以下、各装置やプログラムが保持するデータ構造に関して説明する。
【００４８】
図３は、領域マッピング情報３００のデータ構造を示す図である。領域マッピング情報３００は、仮想化機構が提供する仮想構造の領域と、それが利用する管理構造の領域の対応を保持するものであり、エントリ３０２、３０４を有する。エントリ３０２は、仮想化機構が上位階層に提供する仮想構造の領域に関する情報であり、仮想構造の識別子である仮想構造ＩＤ ３０６を保持するエントリ、その構造内の領域を示すエントリ、その領域が下位階層の複数の仮想構造へ記憶されたり、異なる経路でＨＤＤ１６に対応している場合に、それらを識別するための多重化方法を示すエントリの組を有する。エントリ３０４は、エントリ３０２に対応する下位階層の管理構造の領域に関する情報であり、管理構造を提供する仮想化機構の識別子である仮想化機構ＩＤ ３０８を保持するエントリ、管理構造の識別子である管理構造ＩＤ ３１０を保持するエントリ、その構造内領域を示すエントリの組を有する。なお、記憶装置４０においては、仮想化機構ＩＤ ３０８を有するエントリを保持しない。
【００４９】
前述のように、異なる仮想構造が同一の管理構造の記憶領域を利用することが許される。また、仮想化機構ＩＤ ３０８、仮想構造ＩＤ ３０６、管理構造ＩＤ ３１０はシステム内で一意に定まる識別子であるとする。そうでない場合でも、装置の識別子を付加することによりシステム内で一意に定まるようにすることができる。
【００５０】
図４は、キャッシュグループ情報４６０のデータ構造を示す図である。キャッシュグループ情報４６０は記憶装置４０がキャッシュグループの管理に用いる情報で、キャッシュグループの識別子であるキャッシュグループＩＤ ４６２を保持するエントリと、そのキャッシュグループに対して割り当てられるキャッシュ量の情報であるキャッシュ量４６６を保持するエントリ、そのキャッシュグループに属するＬＵ ２０８の識別子であるＬＵ ＩＤ ３６４を保持するエントリの組を有する。
【００５１】
図５は、データ記憶領域情報３４２のデータ構造を示す図である。データ記憶領域情報３４２は、ＤＢＭＳ９０が管理するデータの記憶領域管理に用いる情報で、データ構造の名前であるデータ構造名３４６を保持するエントリ、対応するデータ構造がファイル２０２のどの位置に記憶されているかの情報であるデータ記憶位置３４８を保持するエントリの組からなる。なお、データ構造名３４６は、ＤＢＭＳ９０内で一意に定まる名前であるとし、ＤＢＭＳ９０内でＤＢ毎に同じ名前が許される場合には、ＤＢの識別子も含めたものを利用する。
【００５２】
本実施の形態においては、ＤＢＭＳ９０は、データ構造が表である場合その属性が記憶される際の最大データサイズに関する情報である属性サイズ情報３５０をＤＢＭＳ管理情報９２中に有する。
【００５３】
図６は、属性サイズ情報３５０のデータ構造を示す図であり、表の名前であるデータ構造名３４６を保持するエントリ、対応する表の属性の名前である属性名３５２を保持するエントリ、そのエントリの記憶領域における最大サイズ３５４を保持するエントリの組からなる。
【００５４】
図７は、ＤＢＭＳ情報４２０のデータ構造を示す図である。
システム管理プログラム１４０は、計算機システム内で実行されるＤＢＭＳ９０に関する情報を、ＤＢＭＳ情報４２０としてシステム管理情報１４２中に保持する。この情報は、ＤＢＭＳ９０の識別子であるＤＢＭＳ ＩＤ ５８２を保持するエントリと、それが実行されるサーバ７０の識別子であるサーバＩＤ ４２２を保持するエントリ、対応するＤＢＭＳ９０のデータ内部管理方法情報４２６を保持するエントリの組を含む。データ内部管理方法情報４２６は、ＤＢＭＳ９０の型式により定まる、ログの出力フォーマットに関する情報を含む。
【００５５】
以下、本実施の形態において、ログに対して割り当てる記憶装置４０におけるデータキャッシュ４２の量を定める処理について説明する。この処理は、システム管理プログラム１４０が行う。
【００５６】
図８は、本処理開始時にシステム管理プログラム１４０に対して与えられる、処理設計情報８５０のデータ構造を示す図である。処理設計情報８５０は、処理を実施するＤＢＭＳ９０のＤＢＭＳ ＩＤ ５８２を保持するエントリ、処理が実施されるＤＢの識別子であるＤＢ ＩＤ ８５４を保持するエントリ、ログを用いて実行するＲｅ−Ｒｕｎ／Ｕｎｄｏ処理の処理性能に関する情報であるＲｅ−Ｒｕｎ性能８５６を保持するエントリ、Ｒｅ−Ｒｕｎ／Ｕｎｄｏ処理実施時の最大所要時間の設計情報であるＲｅ−Ｒｕｎ最大所要時間８５８を保持するエントリ、実行される処理の情報として、処理の識別子である処理ＩＤ ４３２を保持するエントリ、 その処理が実施される比率に関する情報である実行比率８６２を保持するエントリ、その処理において実施されるＳＱＬ文である実行ＳＱＬ文８６０を保持するエントリ、処理内でそのＳＱＬ文が何回実行されるかの期待値を示す期待回数８６４を保持するエントリの組を含む。
【００５７】
本実施の形態においては、Ｒｅ−Ｒｕｎ性能８５６は、Ｒｅ−Ｒｕｎ時に単位時間あたりに処理可能なログに記憶された処理の件数を示し、システムにおける実測値や、サーバ７０の性能とＤＢＭＳ９０の論理的処理性能から求めた論理値、システム設計時の設定値等を与える。１つの処理で複数のＳＱＬ文が実施される可能性があり、処理ＩＤ ４３２に対応する実行ＳＱＬ文８６０は複数存在しても良い。実行ＳＱＬ文８６０が繰り返し実行される場合には、期待回数８６４にそれぞれ独立したものとしてカウントする。同じ処理に含まれるＳＱＬ文でも各種条件により実施されるＳＱＬ文が異なる可能性があり、実行ＳＱＬ文８６０毎に異なる値を取り得る。なお、実行比率８６２や期待回数８６４は、設計値でもよいし、実測値でも良い。
【００５８】
図９は、ログのキャッシュ量を定める処理の処理フローである。前述のように、処理開始時に処理設計情報８５０が与えられる。また、処理により利用されるＤＢやその記憶領域は既に定義されているものとして説明する。ただし、対応するＤＢＭＳ９０や仮想化機構から取得する情報を別途設計情報として管理者が与えることにより、それらが定義されていなくても本処理を実施できる。（ステップ１１０１）
処理設計情報８５０を参照し、Ｒｅ−Ｒｕｎ性能８５６とＲｅ−Ｒｕｎ最大所要時間８５８からＲｅ−Ｒｕｎ時に処理可能な処理の最大処理件数を求める。（ステップ１１０２）
処理設計情報８５０中の実行ＳＱＬ文８６０を参照し、それらの中からＩＮＳＥＲＴ／ＵＰＤＡＴＥを実施するＳＱＬ文と、その期待回数８６４を求める。（ステップ１１０３）
ステップ１１０３で求めたＩＮＳＥＲＴ／ＵＰＤＡＴＥを行う実行ＳＱＬ文８６０を１回実行した際に出力されるログの最大量を把握する。まず、対象となる実行ＳＱＬ文８６０からデータの挿入／更新が行われる表とその属性の名前をそれぞれ把握する。そして、属性サイズ情報３５０を参照してそれらの最大サイズ３５４を求める。また、ＤＢＭＳ情報４２０中のデータ内部管理方法情報４２６からログの出力フォーマットの情報を取得し、それらから各実行ＳＱＬ文８６０においてログとして出力される最大データ量を把握する。（ステップ１１０４）
ステップ１１０３とステップ１１０４で求めた値を用いて、ログを出力する各処理の１件あたりのログ出力量を計算する。この値は、ある処理に属するＩＮＳＥＲＴ／ＵＰＤＡＴＥを行う実行ＳＱＬ文８６０によるログの最大データ量と期待回数８６４の積の値の和として求める。更に、ＤＢＭＳ情報４２０中のデータ内部管理方法情報４２６からログのヘッダや処理がコミットされたときに出力されるデータ等の出力フォーマットに関する情報を把握し、その分もログ出力量に加える。最後に、求めた値を、記憶装置のブロックサイズ（５１２ｂｙｔｅ）を単位として切り上げ処理を実施する。（ステップ１１０５）
ステップ１１０５で求めたログを出力する処理１件あたりのログ出力量と、処理設計情報８５０中の各処理における実行比率８６２から、ログを出力する処理１件あたりの平均ログ出力量を求める。そして、この値とステップ１１０２で求めたＲｅ−Ｒｕｎ時に処理可能な最大処理件数の積の値に、事前に定めた余裕分を加えた量をＲｅ−Ｒｕｎ時に必要となるログ量とする。（ステップ１１０６）
ステップ１１０６で求めた量のログが記憶装置４０上に常に存在するようなキャッシュ量の設定を求める。ＤＢＭＳ９０のログがどの記憶装置４０に記憶され、更に、そのログがどのＬＵ２０８上に記憶され、そのＬＵ２０８がどのキャッシュグループに存在するか、マッピング集約情報から把握する。求めたキャッシュグループに対し、ステップ１１０５で求めたＲｅ−Ｒｕｎ時に必要となるログ量以上のキャッシュを割り当てる。なお、記憶装置４０が書き込まれたデータを２重化する場合には、必要に応じてログ量に対して２倍のキャッシュ量が必要であるとする。
【００５９】
ログが記憶されるＬＵ２０８がフリーキャッシュグループに属する場合には、それらのみのキャッシュグループを定義し、そこにＲｅ−Ｒｕｎ時に必要となるログ量を割り当てることとする。複数のＬＵ２０８に分割されてログが記憶され、かつ、それらが異なるキャッシュグループに属する場合には、それぞれにＲｅ−Ｒｕｎ時に必要となるログ量を割り当てる。ログが記憶されるＬＵ２０８が属するキャッシュグループに他のデータも記憶されるマッピングがマッピング集約情報から得られた場合、例えば、以前のキャッシュグループの設定値から他のデータが記憶される分のキャッシュ量を別途求め、その値にＲｅ−Ｒｕｎ時に必要となるログ量を加算した値をそのキャッシュグループのキャッシュ量とする。（ステップ１１０７）
ステップ１１０６で求めたキャッシュグループとそのキャッシュ量の設定を、記憶装置４０に対して発行する。処理に利用されるＤＢがＤＢＭＳ９０でまだ定義されていない場合には、その定義と記憶領域を確保した後にこのステップを実施する。（ステップ１１０８）
そして、処理を完了する。（ステップ１１０９）
これまで、記憶装置４０はＬＵ２０８を外部装置に提供し、それはＩ／Ｏパス３４を経由してアクセスされるとしてきた。記憶装置４０がファイル２０２を外部装置に提供し、そのファイル２０２がネットワークファイルシステムプロトコルを用いてネットワーク２４経由でアクセスされてもよい。
【００６０】
図１０は、上述した第一の実施形態の変形例であり、記憶装置４０がファイル２０２を外部装置に提供する場合の計算機システムの構成を示す図である。その場合には、以下のような違いがある。
【００６１】
サーバ７０はＩ／ＯパスＩ／Ｆ ３２を有さなくともよい。ＯＳ７２は外部装置が提供するファイル２０２を、ネットワークファイルシステムプロトコルを用いてネットワークＩ／Ｆ ２２、ネットワーク２４経由でアクセスするネットワークファイルシステム８２を含み、ボリュームマネージャ７８やファイルシステム８０を有さなくともよい。ネットワークファイルシステムは領域マッピング情報３００をＯＳ管理情報７４中に有する。ＤＢＭＳ９０により認識されるファイル２０２と記憶装置４０から提供されるファイル２０２があるルールに従って対応する場合、その対応関係を定めるルールの情報のみがＯＳ管理情報７４中に保持されても良い。この場合には、システム管理プログラム１４０は対応関係を定める情報を取得し、それから領域マッピング情報３００を作成し、マッピング集約情報中に記憶する。
【００６２】
記憶装置４０はＩ／ＯパスＩ／Ｆ ３２を持たなくてもよく、ファイルを外部装置に対して提供する。記憶装置４０の制御プログラム４４はファイルシステム８０が提供する機能を有し、記憶装置４０内に存在するＬＵ２０８の記憶領域を仮想化し、ファイル２０２を提供する。また、制御プログラム４４は１つ以上のネットワークファイルシステムプロトコルを解釈し、ネットワーク２４、ネットワークＩ／Ｆ ２２経由で外部装置からそのプロトコルを用いて要求されるファイルアクセス処理を実施する。この記憶装置４０では、キャッシュグループのメンバの管理単位がＬＵ２０８ではなくファイル２０２を単位とする。
【００６３】
データのマッピングに関しては、図２で説明したデータのマッピング階層構成において、ファイル２０２以下が全て記憶装置４０により提供されるようになり、サーバ７０はＯＳ７２内のネットワークファイルシステム８２を用いて記憶装置４０上にあるファイル２０２をアクセスする。
記憶装置４０がファイル２０２を外部装置に提供する場合、本実施の形態において実施する処理においては、ＬＵ２０８を考えている部分を記憶装置４０上のファイル２０２に対応させる。
【００６４】
・第二の実施の形態
第二の実施の形態では、ＤＢＭＳで実施される処理の設計情報から表・索引データに対するキャッシュ量の初期割り当てを好適化する。ＤＢＭＳで実施される処理の組があらかじめ明確になっている場合、処理内容の解析からあるデータ全体へのアクセス量はおおよその見当がつく。データ内でのおおよそのアクセス特性を与え、それと処理内容の解析結果を基に、ある量のキャッシュを割り当てた場合のキャッシュヒット率の概算値を求め、データに対して割り当てるキャッシュ量を決定する。本実施の形態では、計算機システムが、ＤＢＭＳのキャッシュと記憶装置のデータキャッシュを１つのキャッシュ領域とみなして管理するための機構を有し、双方で記憶データの重複がほとんどないことを前提とする。
【００６５】
図１１は、第二の実施形態による計算機システムの構成を示す図である。第二の形態における計算機システムの構成は、第一の形態のものと基本的に同じである。以下、第一の形態との差異を中心にして第二の実施形態について説明する。
【００６６】
ＤＢＭＳ９０は、メモリ１４上の領域をキャッシュ９４として利用し、ＤＢＭＳ管理情報９２中に表データ量情報７００とＢ−Ｔｒｅｅ索引情報７１０を含むＤＢＭＳ９０ｂとなる。ＤＢＭＳ９０ｂは属性サイズ情報３５０を保持する必要はない。ＤＢＭＳ９０ｂは、データ構造毎にキャッシュ９４の利用量を管理する機能を有し、その設定情報は表データ量情報７００やＢ−Ｔｒｅｅ索引情報７１０に含まれる。ＤＢＭＳ９０ｂは、データ構造毎のキャッシュ９４の利用量を動的に変更するためのソフトウェアインターフェイスを有する。
【００６７】
管理エージェント１４４がシステム管理プログラム１４０からの指示に従って実行する処理に、データ構造毎のキャッシュ９４の利用量の変更をＤＢＭＳ９０ｂに指示することが加わる。システム管理プログラム１４０は、システム管理情報１４２中に保持するＤＢＭＳ情報４２０にデータ内部管理方法情報４２６を有する必要はない。
【００６８】
更に大きな違いとして、Ｉ／Ｏパス３４を通してキャッシュ化要求９５４とキャッシュ化要求付ライト要求９５８が伝達される。キャッシュ化要求９５４は、記憶装置４０ｂ内に格納されているデータをデータキャッシュ４２に保持することを求める要求であり、通常のリード要求９５０と同様の形式でデータが指定される。キャッシュ化要求付ライト要求９５８は書き込まれたデータを記憶装置４０ｂ内でデータキャッシュ４２に保持することを求める要求である。
【００６９】
キャッシュ化要求９５４とキャッシュ化要求付ライト要求９５８を使用した例として、Ｉ／Ｏパス３４上でのデータ転送プロトコルとしてＳＣＳＩ（Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ）を基にしたものを利用する場合について説明する。第一の方法としては、キャッシュ化要求９５４とキャッシュ化要求付ライト要求９５８に対応するオペレーションコードを新規に作成する。第二の方法としては、既存のプリフェッチとライトのオペレーションコードを利用し、コマンド中のコントロールバイトのベンダ依存ビットにキャッシュヒントを意味するビットを定義し、その値が“０”の時には通常の処理を、その値が“１”のときに、オペレーションコードがプリフェッチコマンドの場合にはキャッシュ化要求９５４、オペレーションコードがライトのときにはキャッシュ化要求付ライト要求９５８として処理する。なお、他のデータ転送プロトコルを用いても同様の方法で実現可能である。
【００７０】
本実施の形態においては、仮想化スイッチ６０は、仮想ボリューム２０６へのキャッシュ化要求９５４とキャッシュ化要求付ライト要求９５８を、対応する管理構造へのキャッシュ化要求９５４やキャッシュ化要求付ライト要求９５８に変換する機能を制御プログラム６４により実現する仮想スイッチ６０ｂとなる。サーバ７０上のＯＳ７２は、上位プログラムからのキャッシュ化要求９５４とキャッシュ化要求付ライト要求９５８をＩ／Ｏパス３４を通して送出可能なＯＳ７２ｂに変更される。ＤＢＭＳ９０ｂはキャッシュ化要求９５４とキャッシュ化要求付ライト要求９５８を送出する機能を有する。記憶装置４０は、制御プログラム４４によりキャッシュ化要求９５４とキャッシュ化要求付ライト要求９５８が解釈可能な記憶装置４０ｂとなる。
【００７１】
本実施の形態において、記憶装置４０のキャッシュグループ情報４６０は記憶装置４０ｂではキャッシュグループ情報４６０ｂとなる。キャッシュグループ情報４６０ｂ中のヒント機能４６８の値が“ＯＮ”であるキャッシュグループに属するＬＵ２０８内のデータに対してキャッシュ化要求９５４やキャッシュ化要求付ライト要求９５８を受け取った場合、それらにより指示されたデータに関しては長時間データキャッシュ４２に保持するようにする。例えば、記憶装置４０ｂがキャッシュグループ内のデータ領域の管理を、ＬＲＵ置換アルゴリズムを用いて行う場合、要求データをＭＲＵデータ化する。なお、キャッシュ化要求９５４を受け取り、それで指示されたデータがデータキャッシュ４２内に存在しない場合、そのデータをＨＤＤ１６から読み出してデータキャッシュ４２上に格納する。そのＬＵ２０８に対してリード要求９５０やライト要求９５６があった場合、その要求を完了後、そのデータは原則データキャッシュ４２には保持しない。記憶装置４０ｂの内部制御の都合上、データキャッシュ４２に保持する必要がある場合でも、保持する必要がなくなったら、そのデータを保持する領域がすぐに再利用されるようにする。（前述の例ではその時点のＬＲＵデータとして扱う。）
図１２は、キャッシュ化要求９５４とキャッシュ化要求付ライト要求９５８を用いた際の、ＤＢＭＳ９０ｂと記憶装置４０ｂとの間のデータ制御を説明した図である。各領域での処理開始時にＤＢＭＳ９０ｂや記憶装置４０ｂはそのデータをキャッシュ９４やデータキャッシュ４２上に保持していない。なお、図を簡略化するため、処理の受諾や完了の応答は図から省いてある。
【００７２】
領域９６２は、ＤＢＭＳ９０ｂがデータの読み出しのみを行った際のデータ制御を示す。
まず、ＤＢＭＳ９０ｂがリード要求９５０を記憶装置４０ｂに発行し、それに応答して記憶装置４０ｂがＤＢＭＳ９０ｂに要求されたデータを転送する（データ転送９５２）。記憶装置４０ｂはデータを転送した後、そのデータをデータキャッシュ４２に保持しない。ＤＢＭＳ９０ｂは転送されたデータをキャッシュ９４に格納する。ＤＢＭＳ９０ｂは、データをキャッシュ９４から破棄する際に、リード要求９５０と同様の方法でキャッシュ化要求９５４を記憶装置４０ｂに送出する。キャッシュ化要求９５４を受け取った記憶装置４０ｂは要求データをＨＤＤ１６から読み出し、データキャッシュ４２上に保持する。
【００７３】
領域９６４は、ＤＢＭＳ９０ｂがデータの更新を行う際の第一のデータ制御を示す。ＤＢＭＳ９０ｂがデータをキャッシュ９４上に読み出すまでは領域９６２と同様である。その後、ＤＢＭＳ９０ｂはキャッシュ９４上のデータを更新し、更新したデータを記憶装置４０ｂに書き込む（ライト要求９５６＋データ転送９５２）。記憶装置４０ｂは、受領したデータを対応するＨＤＤ１６に書き込み、データキャッシュ４２上にそのデータを保持しない。
その後、ＤＢＭＳ９０ｂは、データをキャッシュ９４から破棄する際に、キャッシュ化要求９５４を記憶装置４０ｂに送出する。キャッシュ化要求９５４を受け取った記憶装置４０ｂは要求データをＨＤＤ１６から読み出し、データキャッシュ４２上に保持する。
【００７４】
領域９６６は、ＤＢＭＳ９０ｂがデータの更新を行う際の第二のデータ制御を示す。ＤＢＭＳ９０ｂがデータをキャッシュ９４上で更新するまでは領域９６４と同様である。データ更新後、本制御では、キャッシュ９４上からデータを破棄するまで記憶装置４０ｂへのデータ書き込みを行わない。データをキャッシュ９４から破棄する際に、ＤＢＭＳ９０ｂは、更新したデータを記憶装置４０ｂに書き込むと同時にキャッシュ化要求を行う（キャッシュ化要求付ライト要求９５８＋データ転送９５２）。キャッシュ化要求付ライト要求９５８を受け取った記憶装置４０ｂは書き込まれたデータをデータキャッシュ４２上に保持する。データのＨＤＤ１６への書き込みは適宜行う。
【００７５】
なお、これまでの説明はキャッシュ化要求９５４を用いた方法で説明してきたが、ＤＢＭＳ９０ｂがデータ破棄時に常にキャッシュ化要求付ライト要求９５８を発行しても良い。この場合、各装置はキャッシュ化要求９５４を処理できる必要はない。
【００７６】
図１３は、キャッシュグループ情報４６０ｂのデータ構造を示す図である。第一の実施の形態と比較して、キャッシュグループＩＤ ４６２を保持するエントリ毎にヒント機能４６８を保持するエントリが付加される。ヒント機能４６８はキャッシュヒント機能が有効か無効かを示す情報で、有効な場合は“ＯＮ”が、無効な場合には“ＯＦＦ”がその値として記憶される。ヒント機能４６８の値が“ＯＮ”のときの制御は前述の通りである。その値が“ＯＦＦ”の場合は、一般的なキャッシュのデータ管理手法を用いる。例えば、データキャッシュ４２内に保持されるデータをＬＲＵ置換アルゴリズムで管理し、アクセスされたデータはその種別に関わらず全てその時点でＭＲＵデータ化する。
【００７７】
図１４は、表データ量情報７００のデータ構造を示す図である。表データ量情報７００は、表のデータ構造名３４６を保持するエントリと、その表におけるデータページの大きさに関する情報であるデータページサイズ７０２を保持するエントリとその表が利用しているデータページ数７０４を保持するエントリ、そのデータが利用可能なキャッシュ９４の量に関する情報であるキャッシュ量４６６を保持するエントリを有する。
【００７８】
図１５は、Ｂ−Ｔｒｅｅ索引情報７１０のデータ構造を示す図である。Ｂ−Ｔｒｅｅ索引情報７１０は、索引のデータ構造名３４６を保持するエントリと、その索引が付加された表のデータ構造名３４６である対応表名７１２を保持するエントリ、データページサイズ７０２を保持するエントリ、データページ数７０４を保持するエントリ、データページのうち、Ｂ−Ｔｒｅｅ索引のリーフノードのデータを保持しているデータページ数であるＬｅａｆノードページ数７１４を保持するエントリ、その索引のキャッシュ量４６６を保持するエントリ、その索引を利用して検索が行われる属性の属性名３５２の組である検索属性７１６を保持するエントリ、検索属性７１６における１回の検索で得られると期待されるタプル数の情報である期待タプル数７１８を保持するエントリの組からなる。なお、１つの索引に複数の検索属性７１６とそれに対応する期待タプル数７１８が存在することがある。また、期待タプル数７１８は、対応する表のデータ解析により得られる値で、平均値や最頻値、あるいは各種指標から計算した値が用いられる。
【００７９】
以下、本実施の形態において、ＤＢＭＳ９０ｂや記憶装置４０ｂにおけるキャッシュ量を設定する処理を説明する。本処理は、システム管理プログラム１４０が行う。
【００８０】
図１６は、キャッシュ量情報７２０のデータ構造を示す図である。キャッシュ量情報７２０は、処理開始時にシステム管理プログラム１４０に対して与えられる、ＤＢＭＳ９０ｂや記憶装置４０ｂにおいて利用可能なキャッシュ量に関する情報であり、処理が実施されるＤＢＭＳ９０ｂのＤＢＭＳ ＩＤ ５８２を保持するエントリとそのＤＢＭＳ９０ｂで利用可能なキャッシュ９４の量に関する情報であるキャッシュ量７２２を保持するエントリの組と、処理に利用されるデータを保持する記憶装置４０ｂ（装置）の識別子である装置ＩＤ ５７２を保持するエントリとそこで利用可能なデータキャッシュ４２の量であるキャッシュ量７２２を保持するエントリの組を含む。
【００８１】
図１７は、処理開始時にシステム管理プログラム１４０に対して与えられる情報である、表アクセス分布情報７３０のデータ構造を示す図である。表アクセス分布情報７３０には、処理に利用される表のデータ構造名３４６を保持するエントリと、その表におけるデータページへのアクセス頻度の分布に関する情報であるアクセス分布７３２を保持するエントリの組を含む。アクセス分布７３２は、アクセス頻度が高い順に並び替えられているとし、理論値／実測値のどちらでもよい。その分布がわからない場合には一般化されたＺｉｐｆ分布に従うとし、ｋ番目に高いアクセス確率を持つデータページへのアクセス確率をＦ（ｋ）としたときに、Ｆ（ｋ） ＝ Ｃ／ｋα （α：パラメータ（０＜＝α）、Ｃ：補正係数（Ｃ＝１／Σ（１／ ｃα）））である仮定する。このとき、データページ数が少ない場合にはαを０に近い値（例えば０．２５程度）とし、データページ数が多い場合にはαを１に近い値（例えば０．７５程度）とする。また、データのＩＮＳＥＲＴが行われる、ＩＮＳＥＲＴされたデータがある程度の時間経過後に更新される、等の時間的局所性を有する処理が行われる場合には、それによりアクセスされる領域が限られ、データページの一定割合（例えば８割）はデータアクセスがされない（アクセス確率が０）としてもよい。
【００８２】
図１８は、システム管理プログラム１４０がシステム管理情報１４２中に保持する期待アクセスページ数情報７８０のデータ構造を示す図である。期待アクセスページ数情報７８０は、処理ＩＤ ４３２を保持するエントリ、その処理によりアクセスされるデータ構造のデータ構造名３４６を保持するエントリと、そのデータ構造に対して処理あたり幾つの異なるデータページが利用されると期待されるかの情報を示す期待アクセスデータページ数７８４を保持するエントリの組からなる。期待アクセスデータページ数７８４は、参照と更新（データの挿入を含む）の双方を含めてアクセスされるデータページ数の総計値を保持するエントリと、更新が行われる（参照のみを除いた）データページ数が保持されるエントリを有する。
【００８３】
期待アクセスページ数情報７８０は設計情報として管理者が与えてもよいし、また、キャッシュ量を設定する処理を開始する前に、システム管理プログラム１４０に処理設計情報８５０を与え、それから以下のように作成してもよい。なお、この場合の処理設計情報８５０には、Ｒｅ−Ｒｕｎ性能８５６とＲｅ−Ｒｕｎ最大所要時間８５８を保持するエントリが含まれなくともよい。
【００８４】
まず、処理設計情報８５０から実行ＳＱＬ文８６０を参照し、それぞれのＳＱＬ実行計画をＤＢＭＳ９０ｂから取得、各処理ステップでアクセスされるデータ構造とそのアクセス方法（データの挿入／更新を含む）を把握する。その結果と、ＤＢＭＳ９０ｂから取得するＢ−Ｔｒｅｅ索引情報７１０を利用し、ＳＱＬ実行計画中の各処理ステップにおいて処理するデータ量（タプル数）を把握する。求めたアクセスされるデータ構造と、そのアクセス方法と、各処理ステップにおける処理データ量から、アクセスされるデータページ数とアクセス内容（参照／更新）を把握する。このとき、基本的に、各タプルは異なるデータページに存在すると考える。ただし、あるＢ−Ｔｒｅｅ索引により検索されるタプルがどのようにデータページに分散されるかの情報をＢ−Ｔｒｅｅ索引情報７１０中に含めておき、それを利用してアクセスされるデータページ数をより詳細に求めてもよい。この処理の全部／一部として、ＤＢＭＳ９０ｂでＳＱＬ実行計画を作成するときに内部的に見積られた値をＳＱＬ実行計画と同時に出力させ、その値を利用してもよい。求めた値に、実行ＳＱＬ文８６０に対応する期待回数８６４を乗じた値を期待アクセスページ数情報７８０に設定する。
【００８５】
図１９は、ＤＢＭＳ９０ｂや記憶装置４０ｂにおけるキャッシュ量を設定する処理の処理フローである。本処理においては、各データ構造毎に、ＤＢＭＳ９０ｂと各記憶装置４０ｂにおけるキャッシュ量の割り当てを求めるものとする。処理開始前に期待アクセスページ数情報７８０がシステム管理情報１４２中に保持される。処理開始時、処理設計情報８５０ｂ、キャッシュ量情報７２０、表アクセス分布情報７３０が与えられる。なお、処理設計情報８５０ｂは、処理設計８５０から実行ＳＱＬ文８６０と期待回数８６４を保持するエントリが除かれたものである。ここでは、処理により利用されるＤＢやその記憶領域は既に定義されているものとして説明する。ただし、対応するＤＢＭＳ９０ｂや仮想化機構から取得する情報を別途設計情報として管理者が与えることにより、それらが定義されていなくても本処理を実施できる。（ステップ１４０１）
まず、表・索引の各データ構造に対して、処理を実施する際に必要となる最小限の量として、ＤＢＭＳ９０ｂにおけるキャッシュ９４と各記憶装置４０ｂにおけるデータキャッシュ４２での利用量を、それぞれ事前に定められる一定量分割り当てる。
【００８６】
なお、本処理の全てのステップにおいて、データの記憶先の記憶装置４０ｂは、システム管理情報１４２中に保持されているマッピング集約情報から把握する。複数の記憶装置４０ｂに対してデータが記憶されている場合には、特に断らない限り、マッピング集約情報から各記憶装置４０ｂ毎のデータの記憶比率を把握し、それに比例したキャッシュ量をそれぞれに割り当てる。ＤＢＭＳ９０ｂや記憶装置４０ｂにおいて、キャッシュ量情報７２０中にキャッシュ量７２２として与えられたキャッシュの利用量の上限を超えた量を要求する場合にはエラーとして処理を終了する。（ステップ１４０２）
次に、ＤＢＭＳ９０ｂからＢ−Ｔｒｅｅ索引情報７１０を取得する。その後、各索引毎に、取得した情報中のデータページ数７０４とＬｅａｆノードページ数７１４の差とデータページサイズ７０２から、リーフノード以外のデータを記憶するデータページの量を把握し、それと同量のキャッシュ９４の利用量を割り当てる。（ステップ１４０３）
続いて、各索引毎に、Ｌｅａｆノードページ数７１４とデータページサイズ７０２からリーフノードのデータ量を把握し、それと同量のデータキャッシュ４２の利用量と、それに対して事前に定められた比率（例えば２０％）分のキャッシュ９４の利用量を割り当てる。（ステップ１４０４）
各表毎にキャッシュ効果関数を指定し、ステップ１６０１から始まる処理を実施し、各表のデータに対してキャッシュ９４の利用量を指定する。ここで、キャッシュ効果関数Ｅ（ｉ）は「あるデータ構造における、データを利用するときに既にそのデータがキャッシュ上に存在する（キャッシュヒットする）確率の、キャッシュ上に保持可能なデータページ数をｉ−１からｉに増加させたときの増分」と定義する。
従って、ΣＥ（ｉ）＝１である。ここでは、近似として表アクセス分布情報７３０で与えられるアクセス分布７３２をそのまま与える。ただし、アクセス分布７３２をベースにキャッシュ効果関数を別途定義してもよい。（ステップ１４０５）
記憶装置４０ｂにおいて、データキャッシュ４２がライトキャッシュとしても利用される場合に、各データ構造にその利用分を考慮したデータキャッシュ４２を割り当てる。まず、処理設計情報８５０ｂ中の期待アクセスページ数情報７２０を参照し、期待アクセスデータページ数７８４の更新データページ数の値が０でないデータ構造を有する処理を求める。それらの処理のうちどれか１つが実施された際の各データ構造毎の期待データページ更新数を、処理設計情報８５０ｂ中の処理の実行比率８６２による重み付けを考慮しながら期待アクセスデータページ数７８４の更新データページ数から求める。次に、処理設計情報８５０ｂ中のＲｅ−Ｒｕｎ性能８５６とＲｅ−Ｒｕｎ最大所要時間８５８からＲｅ−Ｒｕｎ時に処理可能な処理の最大処理件数を求め、それと既に求めた更新が行われる処理あたりの各データ構造毎の期待データページ更新数の積を求める。
【００８７】
求めた値と、データ構造における現在のキャッシュ９４の割り当て量に事前に定めた割合（例えば７０％）を乗じた値を比較し、そのうち値が小さな方をデータ構造に対するライトキャッシュ必要量とする。データキャッシュ４２の割当量がその値未満のデータ構造に対して、その量に達するようにデータキャッシュ４２の割り当てを行う。なお、ある記憶装置４０ｂが書き込まれたデータを２重化する場合には、必要に応じて求めた値の２倍のキャッシュ量が必要であるとする。
【００８８】
なお、本ステップは必ずしも実施される必要はない。この場合、処理設計情報８５０ｂ中にＲｅ−Ｒｕｎ性能８５６やＲｅ−Ｒｕｎ最大所要時間８５８が保持される必要はない。（ステップ１４０６）
各表毎にキャッシュ効果関数を指定し、ステップ１６０１から始まる処理を実施し、各表のデータに対してデータキャッシュ４２を割り当てる。ここでも、キャッシュ効果関数は、近似として表アクセス分布情報７３０で与えられるアクセス分布７３２をそのまま与える。ただし、アクセス分布７３２をベースにキャッシュ効果関数を別途に定義してもよい。特に、ＤＢＭＳ９０ｂでのキャッシュ９４の制御方法、記憶装置４０ｂにおけるデータキャッシュ４２の制御方法の違いを考慮して、ステップ１４０５と異なる関数を用いてもよい。（ステップ１４０７）
これまでに求めたキャッシュ量の設定を、ＤＢＭＳ９０ｂや記憶装置４０ｂに対して発行する。処理に利用されるＤＢがＤＢＭＳ９０ｂでまだ定義されていない場合には、その定義と記憶領域の確保と同時、もしくは確保後にこのステップを実施する。
【００８９】
記憶装置４０ｂへのキャッシュ量の指示は以下のように行う。マッピング集約情報を参照し、処理で利用されるデータ構造のデータを保持するＬＵ２０８を確認し、それがフリーキャッシュグループに属している場合には、同じデータ構造のデータが記憶されるＬＵ２０８をメンバとするキャッシュグループを作成するように記憶装置９０ｂに対して指示を出す。その後に各データ構造を記憶するＬＵ２０８が属するキャッシュグループに対して求めたキャッシュ量の設定を行う。なお、あるデータ構造のデータが異なるキャッシュグループに属する複数のＬＵ２０８上に記憶される場合には、マッピング集約情報からそれぞれに記憶されているデータ量を把握し、それに比例するように割当を行う。マッピング集約情報から、データ構造のデータが他のデータと同一のキャッシュグループに属することになる場合には、それらのデータ構造に対して割りあてられた量の和としてキャッシュグループのキャッシュ量を設定する。このとき、本処理によるキャッシュ量の割当とは別に割り当てが行われている場合には、必要に応じて、以前のキャッシュグループの設定値から他のデータが記憶される分のキャッシュ量を別途求める。（ステップ１４０８）
そして、処理を完了する。（ステップ１４０９）
なお、本処理は、記憶装置４０ｂのデータキャッシュ４２の割当のみを実施する場合に実行しても良い。この場合、ＤＢＭＳ９０ｂにおける各データ構造へのキャッシュ９４の割当が処理開始時に与えられる。そして、ステップ１４０２からステップ１４０５までと、ステップ１４０８におけキャッシュ９４に関する処理は実施しない。
【００９０】
図２０は、キャッシュ効果関数を利用してキャッシュ量の割り当てを行う処理の処理フローを示す。本処理はステップ１４０１から始まる処理の一部であり、その処理が利用可能な情報は全て利用できる。以下、説明のため、処理に利用される表に通番ｔを付加し、各表毎に定まる定数や関数等は、この通番を利用してそれぞれのものとして識別する。本処理の開始時、各表毎にキャッシュ効果関数Ｅｔ（ｉ）と割り当てを行うキャッシュがＤＢＭＳ９０ｂのキャッシュ９４か記憶装置４０ｂのデータキャッシュ４２かに関する指定が与えられる。また、必要に応じて、現在のキャッシュ割当量を求める方法も指定される。（ステップ１６０１）
現在までに割り当てられたキャッシュ量を各表毎に求め、それをデータページ数に換算した値をｎｔに設定する。このとき、処理開始時に特に指定がない限り、キャッシュ９４とデータキャッシュ４２のそれぞれに割り当てられた値の総計としてキャッシュ量を求める。（ステップ１６０２）
次に、各表毎に以下の値を計算する。
【００９１】
Ａｔ ＝ Σ（（表に対する処理の期待アクセスページ数（総計値））×（処理の実行比率））
ここで、Σは処理に関して総和を取ることを示す。表に対する処理の期待アクセスページ数は期待アクセスページ数情報７８０から求めることができ、処理の実行比率は処理設計情報８５０ｂから求めることができる。（ステップ１６０３）
次に、各表毎に指定されたキャッシュ効果関数を用いて以下の値を計算する。
【００９２】
Ｗｔ（ｎｔ） ＝ Ａｔ×Ｅｔ（ｎｔ）
（ステップ１６０４）
ステップ１６０４で求めたＷｔ（ｎｔ）の値が一番大きな表を選択し、その表に対して１データページ分キャッシュを割り当てる。
【００９３】
データキャッシュ４２の割り当ての場合には、Ｗｔ（ｎｔ）の選択後に以下の処理も行う。マッピング集約情報を参照して、その表のデータがどの記憶装置４０ｂにどれだけの量が記憶されているかを求め、その量に比例して追加されたデータキャッシュ４２の割り当て量を記憶装置４０ｂ間で分配する。このとき、特定の記憶装置４０ｂにおける、各データ構造に対するデータキャッシュ４２の割当量の和がキャッシュ量情報７２０中にキャッシュ量７２２として与えられた値に達している場合には、そこへの割り当ては不可能とし、他の記憶装置４０ｂのみを考えて追加されたキャッシュ量の分配を行う。選択された表において、そのデータを保持する全ての記憶装置４０ｂでデータキャッシュ４２の割り当てが不可能と判断される場合、その表に対するキャッシュの割り当ては行わず、次にＷｔ（ｎｔ）の値が大きな表をキャッシュの割り当て対象とし、同様の確認を繰り返す。
【００９４】
そして、選択された表のｎｔの値に１を加える。（ステップ１６０５）
キャッシュが全て割り当てられたか確認し、まだ割り当て可能な未割り当て分が存在する場合にはステップ１６０４に戻る。割り当てが完了した（これ以上割り当てを続行できない）場合には、ステップ１６０７に進み、処理を完了する。（ステップ１６０６）
ここで、処理を完了する。（ステップ１６０７）
これまで、記憶装置４０ｂはＬＵ２０８を外部装置に提供し、それはＩ／Ｏパス３４を経由してアクセスされるとしてきた。第一の実施の形態と同様に、記憶装置４０ｂがファイル２０２を外部装置に提供し、そのファイル２０２がネットワークファイルシステムプロトコルを用いてネットワーク２４経由でアクセスされてもよい。この場合、第一の実施の形態と同様の対応関係がとられる。
【００９５】
主な相違点として、記憶装置４０ｂでは、キャッシュグループのメンバの管理単位が、ファイル２０２が単位となり、本実施の形態において実施する処理においては、ＬＵ２０８の部分が記憶装置４０ｂ上のファイル２０２に対応するようになる。
・第三の実施の形態
第三の実施の形態は、第二の実施の形態において利用されていたキャッシュ化要求９５４とキャッシュ化要求付ライト要求９５８が利用されない条件の下、ＤＢＭＳで実施される処理の設計情報から表・索引データに対するキャッシュ量の初期割り当てを好適化する。つまり、本実施の形態では、ＤＢＭＳのキャッシュと記憶装置のデータキャッシュがそれぞれ独立に管理され、双方の間でキャッシュ上に保持されるデータが一部重複することを前提とする点が第二の実施の形態と異なる。
【００９６】
第三の実施における計算機システムの構成は、基本的に第二の実施形態のものと似ている。以下、本実施の形態について第二の実施形態との違いを中心にして説明する。
【００９７】
前述のように、本実施の形態においては、キャッシュ化要求９５４とキャッシュ化要求付ライト要求９５８が利用されない。そのため、記憶装置４０ｂ、仮想化スイッチ６０ｂ、ＯＳ７２ｂは、第一の実施の形態と同じ記憶装置４０、仮想化スイッチ６０、ＯＳ７２となる。また、ＤＢＭＳ９０ｂは、キャッシュ化要求９５４とキャッシュ化要求付ライト要求９５８を送出する機能を有さないＤＢＭＳ９０ｃになる。
【００９８】
記憶装置４０では、データキャッシュ４２内のデータ管理に関し、一般的な手法を用いる。例えば、データキャッシュ４２内に保持されるデータをＬＲＵ置換アルゴリズムで管理し、アクセスされたデータはその種別に関わらず全てその時点でＭＲＵデータ化する。
【００９９】
本実施の形態では、ステップ１４０１から始まるキャッシュ量を設定する処理がステップ１４０１ｂから始まる処理に変更される。図２１は、ステップ１４０１ｂから始まるＤＢＭＳ９０ｃや記憶装置４０におけるキャッシュ量を設定する処理の処理フローである。ステップ１４０１ｂから始まる処理では、ステップ１４０１から始まる場合に実行されるステップ１４０７がステップ１４２１からステップ１４２３までの処理に変更される。なお、本処理は、第二の実施の形態と同様にして、記憶装置４０のデータキャッシュ４２の割当のみを実施する場合に実行しても良い。
【０１００】
表のデータ量を表データ量情報７００から求め、その値の一定割合（例えば９０％）以上の量のキャッシュ９４が割り当てられた表を、以降の記憶装置４０のデータキャッシュ４２の割り当て対象から除く選択処理を行う。（ステップ１４２１）
次に、ステップ１４０７と同様に、各表毎にキャッシュ効果関数を指定し、ステップ１６０１から始まる処理を実施し、各表のデータに対してデータキャッシュ４２の利用量を割り当てる。このとき、ステップ１６０２で設定する現在までに割り当てられたキャッシュ量は、記憶装置９０におけるデータキャッシュ４２の割当量のみを考慮するように指示する。キャッシュ効果関数は、キャッシュ９４とデータキャッシュ４２の間でのデータの重複を考慮しないものを与えるとし、近似として表アクセス分布情報７３０で与えられるアクセス分布７３２をそのまま与える。また、別途キャッシュ効果関数を定義してもよい。なお、本ステップで割り当てたデータキャッシュ４２の量は、全体の割当量とは別に記憶する。（ステップ１４２２）
ステップ１４２２で割り当てたデータキャッシュ４２に関し、キャッシュ９４とデータキャッシュ４２の間でのデータ重複によるデータキャッシュ４２のキャッシュ効果低減分を考慮する、データキャッシュ４２の割り当ての再調整を行う。本実施の形態では、現在のキャッシュ９４の利用量に一定割合（例えば８０％）を乗じた値（以下、Ｎｔと表記）未満の領域では、データキャッシュ４２を利用してもその効果がないと判断する。まず、ステップ１４２２でデータキャッシュ４２が割り当てられなかった表を再調整の対象から外す。
【０１０１】
次に、ステップ１４２２でデータキャッシュ４２が割り当てらてたものに対してキャッシュ効果があるか確認する。調整対象の各表において、ｎｔを現時点でのデータキャッシュ４２の割当量から求めたデータページ数としたとき、確認指標としてｎｔ−Ｎｔ＜０を用い、それ満たす表が存在する場合には、その値が最も小さな表のステップ１４２２以降で割り当てたデータキャッシュ４２を全て開放し、調整対象から外す。そして、ステップ１４２２で行ったデータキャッシュ４２の割当処理を再度実行する。以下、確認指標を満たす表が存在する間この確認と再割当処理を繰り返す。この確認で、全ての表でステップ１４２２で割り当てたデータキャッシュ４２を開放することになった場合は、エラー発生として処理を終了する。なお、確認指標にキャッシュ効果より強く反映させるために、ｎｔ−Ｎｔ＜０の代わりに（ｎｔ−Ｎｔ）／Ｗｔ（Ｎｔ）＜０（Ｗｔ（ｉ）はステップ１６０４での定義を利用）を用いてもよいし、その他の確認指標を用いてもよい。
【０１０２】
更に、キャッシュ効果を高めるため、調整対象の全ての表でｎｔ−Ｎｔ＞０を満たす場合に、キャッシュ効果を考慮した割当の調整を行う。調整対象の各表においてＶｔ＝ΣＷｔ（ｉ）（ただしΣはＮｔ＜＝ｉ＜＝ｎｔの和を取ることを意味する）を計算し、その値が最も小さな表を選択する。その表に対してステップ１４２２以降で割り当てられたデータキャッシュ４２を開放した場合に、他の調整対象の表に割り当てる方法をステップ１４２２と同様にして求める。ここで、新規割当先に対応するＷｔ（ｉ）の値の和を計算し、その値がデータキャッシュ４２を開放した表におけるＶｔよりも大きな値の場合、求めたキャッシュ割当の再調整を実施するとする。以下、この確認を再調整を実施しないと判断されるまで繰り返す。（ステップ１４２３）
これまで、記憶装置４０はＬＵ２０８を外部装置に提供し、それはＩ／Ｏパス３４を経由してアクセスされるとしてきた。第一の実施の形態と同様に、記憶装置４０がファイル２０２を外部装置に提供し、そのファイル２０２がネットワークファイルシステムプロトコルを用いてネットワーク２４経由でアクセスされてもよい。この場合、第一の実施の形態と同様の対応関係がとられる。
【０１０３】
主な相違点として、記憶装置４０では、キャッシュグループのメンバの管理単位がファイル２０２単位となり、本実施の形態において実施する処理においては、ＬＵ２０８の部分が記憶装置４０上のファイル２０２に対応するようになる。
・第四の実施の形態
第四の実施の形態では、ＤＢＭＳで実施される処理の設計情報と稼動統計情報と組み合わせ、記憶装置におけるデータキャッシュ量のチューニングによりキャッシュ効果を向上させる。事前解析により得た処理のデータページ数の期待値と処理実行時の稼動統計情報を組み合わせることにより、問題と判断された処理や処理全体におけるキャッシュ量変更時の処理時間の変化を見積り、それを基に好適なキャッシュの割り当て方法を発見する。
【０１０４】
図２２は、第四の実施形態による計算機システムの構成を示す図である。第四の実施における計算機システムの構成は、基本的に第一の実施の形態とものと似ている。以下、本実施の形態について、第一の実施形態との相違点を中心にして説明する。
【０１０５】
本実施の形態においては、記憶装置４０がデータキャッシュ４２における稼動統計情報を取得する記憶装置４０ｄとなる。記憶装置４０ｄにおいて、キャッシュグループにおけるキャッシュデータ置換制御は、それぞれ独立にＬＲＵ置換アルゴリズムを用いてわれる。前記アルゴリズムによるデータ置換によりデータキャッシュ４２に存在しなくなったデータの記憶領域に関しても、データ置換後も一定量分は仮想管理領域としてＬＲＵ置換アルゴリズムの管理リスト中にその情報を記憶し、稼動状況の計測に利用する。制御プログラム４４は、データキャッシュ４２の稼動状況を計測し、管理情報４６中にキャッシュモニタ情報３６２として保持する。このとき、ＬＲＵ置換アルゴリズムのキャッシュセグメント（データキャッシュ４２の領域管理単位）管理リストを等サイズの複数領域に分割し、分割領域毎にヒット数を計測する。更に、仮想管理領域に関しても実管理領域（実際にデータに対してキャッシュセグメントが割り当てられている領域）と等サイズの領域に分割して実管理領域と同様にヒット数を計測する。また、記憶装置４０ｄは、外部からの要求に応じて、キャッシュモニタ情報３６２をネットワーク２４を介して外部に送信する機能を有する。
【０１０６】
ＤＢＭＳ９０は、メモリ１４上の領域をキャッシュ９４として利用するＤＢＭＳ９０ｄとなる。
また、ＤＢＭＳ９０ｄは、内部で利用されるソフトウェア機能や各データ構造のデータページ等の内部リソースに関して、それを利用する際に待ちが何回発生したかに関する稼動統計情報を収集し、それをＤＢＭＳ管理情報９２中にＤＢＭＳモニタ情報４１０として保持する。特に、本実施の形態においては、各データ構造毎にそのデータページを利用しようとした際に何回待ちが発生したかの累積値を保持する。
【０１０７】
サーバ７０上では、ＤＢＭＳ９０ｄの他にＡＰプログラム１００が実行される。ＡＰプログラム１００は、ユーザが行う業務のためにサーバ７０上で実行されるプログラムであり、ＤＢＭＳ９０ｄに対して処理要求を発行するものとする。ＡＰプログラム１００は、ＨＤＤ１６もしくは記憶装置４０からメモリ１４に読み出されてＣＰＵ１２により実行される。メモリ１４上に読み込まれたＡＰプログラム１００は、その管理情報であるＡＰプログラム管理情報１０２を有する。
【０１０８】
本実施の形態におけるＡＰプログラム１００は、１つ以上の処理の組として実現され、それぞれに処理ＩＤ ４３２が付加されている。ユーザはそのいずれかの処理実行を要求し、ＡＰプログラム１００はそれに応じて処理を実施する。ＡＰプログラム１００は受け付けた処理要求のキューイング制御を実施し、ＡＰプログラム１００からＤＢＭＳ９０ｄに対して処理要求を発行した場合には、ＤＢＭＳ９０ｄで即座に処理を開始できるものとする。ＡＰプログラム１００は処理に関する実行統計情報を取得し、それをオンラインＪｏｂモニタ情報４３０としてＡＰプログラム管理情報１０２中に保持する。ＡＰプログラム１００は、ＡＰプログラム管理情報１０２を外部プログラムが読むためのソフトウェアインターフェイスを有する。
【０１０９】
ＤＢＭＳ９０ｄとＡＰプログラム１００が１台のサーバ７０上で複数同時に実行されてもよい。また、ＤＢＭＳ９０ｄとＡＰプログラム１００が異なるサーバ７０上で実行されてもよく、その場合には、ＡＰプログラム１００はネットワーク２４を経由してＤＢＭＳ９０ｄに処理要求を伝達する。
管理エージェント１４４がシステム管理プログラム１４０からの指示に従って実行する処理に、ＡＰプログラム管理情報１０２中に記憶されている情報の読み出しが加わる。
システム管理プログラム１４０は、システム管理情報１４２中に保持するＤＢＭＳ情報４２０にデータ内部管理方法情報４２６を有する必要はない。その代わり、システム管理情報１４２中にＨＤＤ性能情報６１２を保持する。
【０１１０】
図２３は、キャッシュモニタ情報３６２のデータ構造を示す図である。
キャッシュモニタ情報３６２は、ＬＵ ２０８が外部装置からアクセスされた場合にどのキャッシュ領域にヒットしたかに関する稼動統計情報であり、実管理領域の分割数を示す実領域分割数５０２と、実管理領域の分割後のサイズを単位とした仮想管理領域の保持量を示す仮想管理領域数５０４を含む。また、ＬＵ ２０８毎のキャッシュヒット数の統計値として、ＬＵ ＩＤ ３６４を保持するエントリと、それに対応するリード／ライトのＩ／Ｏ種別３６６を保持するエントリ、それに対応するＩ／Ｏ処理の累積実行回数３６８を保持するエントリ、そのときにヒットした回数を示すキャッシュヒット回数累計３７０を保持するエントリの組を保持する。なお、キャッシュヒット回数累計３７０は、実管理領域でのヒット数の総累計値と、実管理領域と仮想管理領域の双方で分割された各領域でのヒット数の累計値を保持する。本実施の形態では、実管理領域と仮想管理領域を統合して分割された領域に通番を付加し、最も最近利用されたデータが存在する領域を第１領域、以下小さい通番の領域ほど最近利用されたデータを有する領域であるとする。
【０１１１】
図２４は、ＤＢＭＳモニタ情報４１０のデータ構造を示す図である。ＤＢＭＳモニタ情報４１０は、ソフトウエア機能や各データ構造等の名前であるＤＢＭＳリソース名４１２を保持するエントリと、そのリソースを利用する際に発生した待ちの回数累積値である累積待ち回数４１４を保持するエントリの組を有する。
【０１１２】
図２５は、オンラインＪｏｂ情報４３０のデータ構造を示す図である。オンラインＪｏｂ情報４３０は、ＡＰプログラム１００が取得する実行統計情報であり、処理ＩＤ ４３２を保持するエントリ、対応する処理の累積実行回数３６８を保持するエントリ、その処理をＤＢＭＳ９０ｄに対して発行した際の累積処理時間３９６（処理の待ち時間を含まない）を保持するエントリの組を有する。
【０１１３】
図２６は、ＨＤＤ性能情報６１２のデータ構造を示す図である。ＨＤＤ性能情報６１２はＨＤＤ１６のアクセス性能に関する情報であり、記憶装置４０ｄの識別子である装置ＩＤ ５７２を保持するエントリとＨＤＤ１６の識別子であるＨＤＤ ＩＤ ３９４を保持するエントリ、それに対応するＨＤＤ１６が有するアクセス性能に関する情報であるアクセス性能情報６１４を含むエントリの組を有する。アクセス性能情報６１４は、ランダムアクセス時のリードでキャッシュヒットした／しない（ミスした）場合、ライトでキャッシュヒットした／しない場合のそれぞれの平均応答時間を保持する。この情報は、記憶装置４０ｄでのＨＤＤ１６の型式を取得し、それと事前に与えられた型式毎の性能情報と組み合わせて作成する。
【０１１４】
以下、本実施の形態における、ＤＢＭＳ９０ｄで実施される処理の設計情報と各要素の稼動統計情報と組み合わせたデータキャッシュ４２のキャッシュ量チューニング処理の説明を行う。この処理は、システム管理プログラム１４０が行う。
【０１１５】
まず、システム管理プログラム１４０は、記憶装置４０ｄ、ＤＢＭＳ９０ｄ、ＡＰプログラム１００から、それぞれキャッシュモニタ情報３７０、ＤＢＭＳモニタ情報４１０、オンラインＪｏｂモニタ情報４３０（以下これらをまとめて「モニタ情報」と称す）を取得し、それを適当な形に編集した情報をシステム管理情報１４２中にモニタ履歴情報５１０として保持する。
【０１１６】
図２７は、モニタ履歴情報５１０のデータ構造を示す図である。稼動状況がモニタされている部位（キャッシュモニタ情報３６２ではアクセス先のＬＵ２０８も含む）に関して、システム内で一意に定まるモニタ部位ＩＤ ５１４が付加される。モニタ履歴情報５１０は、モニタ部位ＩＤ ５１４を保持するエントリとそのモニタ内容５１６を示す情報を保持するエントリと、対応する前回取得情報５１８を保持するエントリと、履歴情報５２０を保持するエントリの組を有する。
【０１１７】
モニタ内容５１６としては、モニタ情報のデータ構造を説明する際に説明した通りである。前回取得情報５１８は、前回モニタ情報の値を取得した日時のエントリとその取得値のエントリを有する。履歴情報５２０は、履歴として集計・記憶される値の内容を示す履歴内容５２２を保持するエントリと、ある期間のモニタ値であるサンプル５２４を保持する複数のエントリからなる。本実施の形態で利用する履歴内容５２２としては、キャッシュモニタ情報３６２からＬＵ２０８におけるリード／ライト毎の平均実行回数と平均実ヒット率と、リードの領域毎の平均ヒット率（期間内の領域でのリードヒット回数／期間内のＬＵ２０８へのリード実行回数）、ＤＢＭＳモニタ情報４１０からとして各データ構造における平均待ち発生回数、オンラインＪｏｂモニタ情報４３０からとしてＡＰプログラム１００における各処理毎の平均実行回数と平均処理時間がある。サンプル５２４は、そこに記憶されたデータがいつの期間のモニタ値かを示すエントリと、その期間における集計値である平均値と最大値をそれぞれ保持するエントリからなる。
【０１１８】
モニタ履歴情報５１０への値の設定は以下のように行う。まず、システム管理プログラム１４０は、モニタ情報を取得している記憶装置４０ｄ、ＤＢＭＳ９０ｄ、ＡＰプログラム１００からその値を一定間隔で取得する。データ取得後、対応する前回取得情報５１８のエントリ中に保存されている前回のデータ取得日時と取得値から、データの取得期間とその期間内の履歴内容５２２として指示される値を計算し、それをサンプル５２４に保存し、今回取得した値を対応する前回取得情報５１８に保存する。以下、これを繰り返す。なお、システム管理プログラム１４０は、連続した期間に対応するサンプル５２４の値をまとめたり、特に古い期間のデータを保持するサンプル５２４を削除する処理を適宜実施する。
【０１１９】
以下、システム管理プログラム１４０により行われるデータキャッシュ量チューニング処理に関して説明する。この処理は、例えば、ＡＰプログラム１００の平均応答時間が定められた値を下回った場合に実施され、基本的には、他の部位がボトルネックかどうかの確認を、別途取得している実行稼動統計情報を用いて行った後に、そのような部位が存在しない場合に実施される。
【０１２０】
図２８は、データキャッシュ量チューニングのメイン処理の処理フローである。
外部からの指示に応じてこの処理は開始される。このとき、チューニング対象に関する情報として、対象となる処理が実施されているＤＢＭＳ９０ｄのＤＢＭＳ ＩＤ ５８２と利用されるＤＢのＤＢ ＩＤ ８５４、処理の事前解析結果として期待アクセスページ数情報７８０を与える。なお、期待アクセスページ数情報７８０の代わりに処理設計情報８５０を与え、それから第二の実施形態の場合と同様の方法で期待アクセスページ数情報７８０を求めてもよい。また、期待アクセスページ数情報７８０中の期待アクセスページ数７８４は、各処理に求められるデータ整合性のレベルやデータのロック粒度から定まる、データへのロック取得方法の差を考慮して補正した値を用いても良い。（ステップ１８０１）
まず、ＤＢＭＳ９０ｄ内の各データ構造におけるデータページを利用しようとした際に、待ちが多数発生しているかを確認する。期待アクセスページ数情報７８０から処理に利用されるデータ構造を把握し、それらのデータ構造での平均待ち発生回数をモニタ履歴情報５１０中の履歴情報５２０の対応する最新の値を保持するエントリ５２４から把握し、あるデータ構造におけるその値が事前に定められている閾値以上の場合には、待ちが多数発生しているとしてステップ１８０３に進む。全てのデータ構造でその値が閾値未満の場合には、待ちが多数発生していないとしてステップ１８１１に進む。（ステップ１８０２）
ここでは、ステップ１８０２で待ちが多数発生していると判断されたデータ構造を利用する処理とそのデータ構造への期待アクセスデータページ数（総計値）を期待アクセスページ数情報７８０を参照して把握する。（ステップ１８０３）
続いて、ステップ１８０３で求めた処理の中で、処理時間が長く、かつ、待ちが多数発生しているデータ構造を多数回アクセスするものがないか確認する。処理における平均実行回数と平均処理時間をモニタ履歴情報５１０中の履歴情報５２０の対応する最新の値を保持するエントリ５２４から把握し、それらの値とステップ１８０３で求めたそのデータ構造への期待アクセスデータページ数との積をステップ１８０３で求めた処理に関して計算する。他の処理と比較したとき、常にその計算値が他の処理の値よりもある事前に定められた倍率（例えば４倍）となる処理が存在する場合に、その処理が、処理時間が長く、待ちが多数発生しているデータ構造を多数回利用する処理と判断し、ステップ１８０５に進む。そのような処理が存在しない場合にはステップ１８１１に進む。（ステップ１８０４）
ここでは、ステップ１８０４で求めた処理の処理時間が短くなるように、その処理が利用するデータのキャッシュヒット率を向上させるキャッシュ割当の変更方法を求める。ここでは、処理時間を短くしたい処理の処理ＩＤ ４３２を指定してステップ２７０１から開始される処理を実施する。（ステップ１８０５）
ここでは、各処理を全体としてみたときに処理時間の総和が小さくなるように、各処理が利用するデータのキャッシュヒット率を向上させるキャッシュ割当の変更方法を求める。ここでは、特に何も指定せずにステップ２７０１から開始される処理を実施する。（ステップ１８１１）
ステップ１８０５やステップ１８１１で求めたキャッシュ割当の変更方法に従って記憶装置４０ｄにデータキャッシュ４２の割当の変更を指示する。マッピング集約情報を参照し、処理で利用されるデータ構造のデータを保持するＬＵ２０８とそれが属するキャッシュグループを把握し、そのキャッシュグループに対して求めたキャッシュ割当の変更方法に従ってキャッシュ量の変更指示を出す。なお、あるデータ構造のデータが異なるキャッシュグループに属する複数のＬＵ２０８上に記憶される場合には、マッピング集約情報からそれぞれに記憶されているデータ量を把握し、それに比例するように割当の変更指示を出す。（ステップ１８２１）
ここで、処理を完了する。（ステップ１８２２）
図２９は、モニタ情報を基にしたデータキャッシュ４２の割当量をチューニングする処理の処理フローである。処理開始時に、特定の処理の処理時間を短くしたい場合には、その処理の処理ＩＤ ４３２が与えられる。それが与えられなかった場合には、各処理全体として処理時間を短くするとする。なお、本処理はステップ１８０１から始まる処理の一部であり、その処理が利用可能な情報は全て利用できる。（ステップ２７０１）
まず、期待アクセスページ数情報７８０とマッピング集約情報を参照し、処理が利用するデータ構造を保持する記憶装置４０ｄ、ＬＵ２０８、キャッシュグループと、そのキャッシュグループにおけるデータキャッシュ４２の割当量を各処理毎に求める。（ステップ２７０２）
続いて、キャッシュ量を変更した際のキャッシュヒット率の変化量を計算する。ここで、記憶装置４０ｄにおける実領域分割数５０２と仮想管理領域数５０４の値がそれぞれＲとＶであるとする。ＬＵ２０８が属するキャッシュグループの現在のキャッシュ量をＣとしたとき、キャッシュモニタ情報３６２中のキャッシュヒット回数累計３７０における第ｉ領域（０＜ｉ＜＝Ｒ）のヒット数は、そのＬＵ２０８が属するキャッシュグループのキャッシュ量をｉＣ／Ｒから（ｉ−１）Ｃ／Ｒに削減したときにヒットしなくなる回数、第ｉ領域（Ｒ＜ｉ＜＝Ｒ＋Ｖ）のヒット数は、キャッシュ量を（ｉ−１）Ｃ／ＲからｉＣ／Ｒに増加させたときにヒットするようになる回数と考えられる。キャッシュ量をＣからＣ／Ｒ減らしたときの平均実ヒット率の削減分が第Ｒ領域における平均ヒット率であるから、ＬＵ２０８におけるキャッシュ量が（ｉ−１）Ｃ／ＲからｉＣ／Ｒの範囲（０＜ｉ＜＝Ｒ）での単位キャッシュ量あたりの平均ヒット率削減分は（第ｉ領域での平均ヒット率）ｘＲ／Ｃとして近似可能である。同様に、キャッシュ量が（ｉ−１）Ｃ／ＲからｉＣ／Ｒの範囲（Ｒ＜ｉ＜＝Ｒ＋Ｖ）での単位キャッシュ量あたりの平均ヒット率増加分は（第ｉ領域での平均ヒット率）ｘＲ／Ｃとして近似可能である。なお、各ＬＵ２０８毎のリードアクセス実行時の第ｉ領域（０＜ｉ＜＝Ｒ＋Ｖ）での平均ヒット率はモニタ履歴情報５１０に保持されている。記憶装置４０ｄにおける実領域分割数５０２と仮想管理領域数５０４は記憶装置４０ｄのキャッシュモニタ情報３６２中に保持されているものを記憶装置４０ｄから取得することができる。
【０１２１】
この値を各処理が利用するデータ構造を保持するＬＵ２０８について全て計算し、ヒット率変化率とする。なお、以下のステップを含めてモニタ履歴情報５１０からは最も直近のサンプル５２４による値、もしくは、事前に定められた直近のある期間の平均値を取得するものとする。（ステップ２７０３）
次に、マッピング集約情報を用いて、各処理が利用するデータ構造を保持するＬＵ２０８に対応するＨＤＤ１６を把握する。そして、ＨＤＤ性能情報６１２のＨＤＤ１６のアクセス性能情報６１４を参照してＨＤＤ１６のリードヒット時の平均応答時間とリードミス時の平均応答時間を求め、（リードミス時の平均応答時間）−（リードヒット時の平均応答時間）を計算しＬＵ２０８の応答時間変化量とする。なお、ＬＵ２０８中のデータが性能の異なるＨＤＤ１６に分割されて記憶される場合には、ＨＤＤ１６毎に応答時間変化量を求め、ＨＤＤ１６に記憶されるデータ量で重み付き平均を計算した値をＬＵ２０８の応答時間変化量とする。（ステップ２７０４）
記憶装置４０ｄ毎に、
Ｉ ＝ Σ（ＬＵ処理時間変化の平均） ただし、 （ＬＵ処理時間変化の平均）＝（応答時間変化量）×（ＬＵの平均リードＩ／Ｏ回数）×（ヒット率変化量）
の値を増加させるようにキャッシュ割当の変更方法を求める。応答時間変化量はステップ２７０４で求めたものを用いる。ヒット率変化量はステップ２７０３で求めたヒット率変化率とキャッシュ割当の変更量から求めることができる。このとき、ヒット率変化率は、キャッシュグループのキャッシュ量により変化することに注意する。
【０１２２】
各処理全体の処理時間を考慮し、それを短くする（処理開始時に特定の処理ＩＤ ４３２が与えられなかった）場合、Σは、記憶装置４０ｄにおいて各処理が利用するのデータ構造を保持するＬＵ２０８に関して総和を取ることを意味する。ＬＵ２０８の平均リードＩ／Ｏ回数はモニタ履歴情報５１０から取得可能であり、取得値をそのまま用いる。
【０１２３】
処理時間を短くしたい処理の処理ＩＤ ４３２が与えられた場合には、Σは、記憶装置４０ｄにおいて指定処理が利用するデータ構造を保持するＬＵ２０８に関して総和を取ることを意味する。ＬＵ２０８の平均リードＩ／Ｏ回数は、指定処理への寄与分のみを考える。各処理によるＬＵ２０８へのリード処理回数は、処理における期待アクセスページ数情報７８０中の期待アクセスデータページ数７８４の総計値に比例しているとして指定処理に関連するリードＩ／Ｏの割合を計算し、モニタ履歴情報５１０から取得した平均リードＩ／Ｏ回数にその割合を乗じた値をＩの計算に用いる。
【０１２４】
Ｉを用いたキャッシュ割当の変更方法決定には、例えば以下のアルゴリズムを用いる。まず、各処理が利用するデータ構造を保持するＬＵ２０８が属するキャッシュグループに対して、単位キャッシュ量を増やした場合と減らした場合のＩを計算する。そして、キャッシュ量を減らした場合に最もＩが大きい（影響が小さい）キャッシュグループから最もＩの値が大きい（効果が高い）キャッシュグループへ単位量分キャッシュ割当を変更したとした場合のＩの値を計算し、それがある閾値以上のときに効果ありとしてキャッシュ割当の変更を行うとする。なお、処理時間を短くしたい処理の処理ＩＤ ４３２が与えられた場合には、上記で求めたキャッシュ割当の変更により、各処理全体の処理時間を考慮した場合のＩの値の変化も同時に確認し、その値が別の０以下のある閾値より小さい（処理全体として処理時間が悪化する）場合には、そのキャッシュ割当の変更は不可として別のキャッシュ割当変更方法を求める。
【０１２５】
以下、キャッシュ割当の変更が行われたとして上記確認を繰り返し実施し、更に割当変更を行うことに効果なしと判断されるか、もしくは、事前に定められる量（例えば、記憶装置４０ｄで利用しているキャッシュ量の一定割合）の割当変更を行った場合に、この確認の繰り返しを終了させる。（ステップ２７０５）
そして、処理を完了する。（ステップ２７０６）
これまで、記憶装置４０ｄはＬＵ２０８を外部装置に提供し、それはＩ／Ｏパス３４を経由してアクセスされるとしてきた。第一の実施の形態と同様に、記憶装置４０ｄがファイル２０２を外部装置に提供し、そのファイル２０２がネットワークファイルシステムプロトコルを用いてネットワーク２４経由でアクセスされてもよい。この場合、第一の実施の形態と同様の対応関係がとられる。
【０１２６】
主要な相違点としては、記憶装置４０ｄでは、キャッシュグループのメンバの管理単位がファイル２０２単位となり、本実施の形態における処理においては、ＬＵ２０８の部分が記憶装置４０ｄ上のファイル２０２に対応するようになる。
【０１２７】
【発明の効果】
本発明によれば、ＤＢＭＳが稼動する計算機システムにおいて、データの利用目的や処理内容から生じるデータの特性を考慮したキャッシュ量の設定を行うことができる。これにより記憶装置のデータキャッシュが一層有効に活用され、好適な性能を得ることができる。
また、記憶装置のキャッシュ量の設定やそのチューニングを自動的に行うことができ、計算機システムの性能管理コストが削減される。
【図面の簡単な説明】
【図１】第一の実施の形態による計算機システムの構成を示す。
【図２】第一の実施の形態におけるデータマッピングの階層構成の概念を示す。
【図３】領域マッピング情報３００のデータ構造を示す。
【図４】キャッシュグループ情報４６０のデータ構造を示す。
【図５】データ記憶領域情報３４２のデータ構造を示す。
【図６】属性サイズ情報３５０のデータ構造を示す。
【図７】ＤＢＭＳ情報４２０のデータ構造を示す。
【図８】処理設計情報８５０のデータ構造を示す。
【図９】ログのキャッシュ量を定める処理の処理フローを示す。
【図１０】第一の実施の形態の変形例を説明に供する計算機システムの構成を示す。
【図１１】第二の実施の形態による計算機システムの構成を示す。
【図１２】キャッシュ化要求９５４とキャッシュ化要求付ライト要求９５８を用いた際の、ＤＢＭＳ９０ｂと記憶装置４０ｂとの間のデータ制御を示す。
【図１３】キャッシュグループ情報４６０ｂのデータ構造を示す。
【図１４】表データ量情報７００のデータ構造を示す。
【図１５】Ｂ−Ｔｒｅｅ索引情報７１０のデータ構造を示す。
【図１６】キャッシュ量情報７２０のデータ構造を示す。
【図１７】表アクセス分布情報７３０のデータ構造を示す。
【図１８】期待アクセスページ数情報７８０のデータ構造を示す。
【図１９】第二の実施の形態による、ＤＢＭＳ９０ｂ及び記憶装置４０ｂにおけるキャッシュ量を設定する処理の処理フローを示す。
【図２０】キャッシュ効果関数を利用してキャッシュ量の割り当てを行う処理の処理フローを示す。
【図２１】第三の実施の形態による、ＤＢＭＳ９０ｃや記憶装置４０におけるキャッシュ量を設定する処理の処理フローを示す。
【図２２】第四の実施の形態による計算機システムの構成を示す。
【図２３】キャッシュモニタ情報３６２のデータ構造を示す。
【図２４】ＤＢＭＳモニタ情報４１０のデータ構造を示す。
【図２５】オンラインＪｏｂ情報４３０のデータ構造を示す。
【図２６】ＨＤＤ性能情報６１２のデータ構造を示す。
【図２７】モニタ履歴情報５１０のデータ構造を示す。
【図２８】データキャッシュ量チューニングのメイン処理の処理フローを示す。
【図２９】モニタ情報を基にしたデータキャッシュ４２の割当量をチューニングする処理の処理フローを示す。
【符号の説明】
１６…ＨＤＤ、 ２２…ネットワークＩ／Ｆ、
２４…ネットワーク、 ３２…Ｉ／ＯパスＩ／Ｆ、
３４…Ｉ／Ｏパス、 ４０、４０ｂ、４０ｄ…記憶装置、
６０、６０ｂ…仮想化スイッチ、 ７０…サーバ、
９０、９０ｂ、９０ｃ、９０ｄ…ＤＢＭＳ、 １００…ＡＰプログラム、
１２０…管理サーバ、 １４０…システム管理プログラム
【発明の属する技術分野】
本発明は記憶装置のキャッシュ管理方法に係り、特にデータベース管理システム（ＤＢＭＳ）が稼動する計算機システムにおける記憶装置のキャッシュ量の設定管理に関する。
【０００２】
【従来の技術】
サーバ計算機上で実行されるアプリケーションプログラム（ＡＰプログラム）のソフトウェア構成を調べると、データベース（ＤＢ）を基盤として利用するものが多数を占め、ＤＢに関する一連の処理・管理を行うソフトウェアであるデータベース管理システム（ＤＢＭＳ）は極めて重要なものとなっている。
【０００３】
ＡＰプログラムの利用に際し、業務毎に定まる要求性能が存在し、それを守ることが強く求められており、それは計算機システム管理の中で極めて重要なものとなっている。ＤＢＭＳの性能は、データへのアクセス性能から多大な影響を受ける。
そのため、記憶装置へのアクセス性能の向上が極めて重要である。
【０００４】
一般的に、ディスク装置を多数保持する記憶装置においては、記憶装置内にデータを一時的に保管する高速アクセス可能なデータキャッシュを用意し、データリード時にデータがキャッシュに存在している状態（ヒット）を作り出すことによりアクセス性能を向上させる手法を用いる。米国特許第５，４３４，９９２号明細書（特許文献１）では、データ種類毎に区分化されたキャッシュ領域を持つ場合に、その領域割り当てを最適化してキャッシュヒット率を向上させる技術について開示している。ＬＲＵ置換アルゴリズムによるキャッシュデータ置換制御を行うシステムで、キャッシュヒット時にＬＲＵ管理リスト中のどの位置に存在するかの情報を取得し、その情報を用いて領域割り当て変更時のキャッシュヒット率の見積を行い、領域分割の最適化を行う。
【０００５】
また、一般に、ファイルキャッシュ等の形で計算機上にもキャッシュが存在する。論文（非特許文献１）においては、計算機上のファイルキャッシュと記憶装置上のデータキャッシュを排他的に利用することにより、データへのアクセス性能を向上させる技術について論じている。この技術では、計算機上で保持されなくなったデータを記憶装置でキャッシュ化させる機構を利用する。記憶装置は、原則ＬＲＵ置換アルゴリズムによりキャッシュデータ置換制御を行うが、記憶装置内のディスク装置から読み出したデータはＬＲＵ管理リスト中のＬＲＵ端に挿入し、そのデータが記憶装置のデータキャッシュに留まらないように制御する。更に、キャッシュヒット率をより一層向上させるため、ディスク装置から読み出されたデータと計算機から与えられたデータのそれぞれに関して、ゴーストＬＲＵキャッシュと称するそれぞれ独立したＬＲＵ管理リストを用いることにより、全体を管理するＬＲＵ管理リスト中の初期挿入位置を最適化する方法についても論じている。
【０００６】
【特許文献１】
米国特許 第５，４３４，９９２号明細書
【非特許文献１】
Ｔｈｅｏｄｏｒｅ Ｍ． Ｗｏｎｇ ａｎｄ Ｊｏｈｎ Ｗｉｌｋｅｓ、 溺ｙ ｃａｃｈｅ ｏｒ ｙｏｕｒｓ？ Ｍａｋｉｎｇ ｓｔｏｒａｇｅ ｍｏｒｅ ｅｘｃｌｕｓｉｖｅ ＵＳＥＮＩＸ Ａｎｎｕａｌ Ｔｅｃｈｎｉｃａｌ Ｃｏｎｆｅｒｅｎｃｅ （ＵＳＥＮＩＸ ２００２）， ｐｐ． １６１−１７５、 １０−１５ Ｊｕｎｅ ２００２
【０００７】
【発明が解決しようとする課題】
一般的に、ＤＢＭＳにより管理されるデータは、その内容や利用目的により明確に分類される。それらは、それぞれでアクセスの特性が大きくなる。データの中には、必要とされる特性を事前に明確化することができるものもある。しかし、従来の技術では、それらの特徴を必ずしも考慮していない。
【０００８】
特許文献１の技術では、キャッシュを分割化し、データの種類により独立した領域を割り当てるため、データ毎のアクセス特性の差を扱うことができるが、データや処理の内容までは考慮されていない。非特許文献１の技術では、データ毎のアクセス特性の差を扱うことについては特に何も考慮されていない。
【０００９】
本発明の目的は、ＤＢＳＭが稼動する計算機システムにおいて、記憶装置のキャッシュ量を最適に設定し、性能管理コストを削減することである。
【００１０】
本発明の他の目的は、データの利用目的や処理内容等から生じるデータのアクセス特性の違いに基づいて記憶装置のデータキャッシュを効果的に割当てることにある。
【００１１】
本発明の更に他の目的は、データキャッシュのアクセスに関する稼動の統計情報に基づいて、データキャッシュの量をチューニングすることにより、キャッシュの効果を向上させることにある。
【００１２】
【課題を解決するための手段】
本発明は、設計情報として与えられるＤＢＭＳで実行される処理に関する情報を取得し、それを基にデータ毎に利用するキャッシュ量を設定するものである。
【００１３】
そのために本発明は、ＤＢＭＳが書き出すログに対するキャッシュ量を調整する。
ログは、ＤＢＭＳが異常終了した後の再起動時に処理の再実行（Ｒｅ−Ｒｕｎ）や取り消し（Ｕｎｄｏ）を実施するためにＤＢＭＳが出力する情報である。それらの処理を高速に実施する必要がある場合に、その際に利用されるログは全て記憶装置のキャッシュ上に存在するようにし、ログの読み出しを高速化する。Ｒｅ−Ｒｕｎ処理時間（Ｕｎｄｏ処理時間も含む）への要求値を基に読み出されるべきログの量を把握し、その分のログは記憶装置のキャッシュ上に存在することができるようなキャッシュ量を設定する。
【００１４】
本発明はまた、表・索引データに対するキャッシュ量の初期割り当てを好適化する。ＤＢＭＳで実施される処理の組があらかじめ明確になっている場合、処理内容の解析からあるデータ全体へのアクセス量はおおよその見当がつく。データ内でのおおよそのアクセス特性を与え、それと処理内容の解析結果を基に、ある量のキャッシュを割り当てた場合のキャッシュヒット率の概算値を求め、データに対して割り当てるキャッシュ量を決定する。
【００１５】
本発明はまた、稼動統計情報と組み合わせたキャッシュ量チューニングによるキャッシュ効果の向上である。事前解析により得た処理が利用するデータページ数の期待値と処理実行時の稼動統計情報を組み合わせることにより、問題と判断された処理や処理全体におけるキャッシュ量変更時の処理時間の変化を見積り、それを基に好適なキャッシュの割り当て方法を提供する。
なお、上記発明において、データ毎のアクセス特性の差を扱うため、記憶装置のキャッシュを区分化し、データ毎に独立したキャッシュ領域を割り当てる。
【００１６】
【発明の実施の形態】
以下、本発明の実施の形態を説明する。なお、これにより本発明が限定されるものではない。
・第一の実施の形態
第一の実施の形態は、ＤＢＭＳで実施される処理の設計情報からＤＢＭＳが書き出すログに対するキャッシュ量を調整するものである。ここで、処理とはＤＢＭＳにより実施される処理である。また設計情報とは、ＤＢＭＳに求められている機能や性能を実現するための情報であって、ＤＢＭＳに実行させる処理の内容を規定する情報や、ＤＢＭＳじ実行させる処理の実行条件を規定する情報のことを言う。例えば設計によりそれぞれの処理に対応するＳＱＬ文が作成され、複数のＳＱＬ文により１つの処理が実施されるが、これらはその処理の詳細を設計する際に見積もられる。またログは、ＤＢＭＳが異常終了した後の再起動時に処理のＲｅ−ＲｕｎやＵｎｄｏを実施するためにＤＢＭＳが出力する情報である。それらの処理を高速にする必要がある場合に、その際に利用されるログは全て記憶装置のキャッシュ上に存在するようにし、ログの読み出しを高速化する。Ｒｅ−Ｒｕｎ処理時間（Ｕｎｄｏ処理時間も含む）への要求値を基に読み出されるべきログの量を把握し、その分のログは記憶装置のキャッシュ上に存在することができるようなキャッシュ量の設定を実現する。
【００１７】
図１は、本発明の一実施形態による計算機システムの構成を示す図である。
計算機システムは、記憶装置４０、記憶装置４０を使用する計算機（以下「サーバ」）７０、システム管理を行う計算機（以下「管理サーバ」）１２０、及び記憶領域の仮想化処理を行う仮想化スイッチ６０を有して構成される。各々の装置はネットワークインタフェース（ネットワーックＩ／Ｆと略す）２２を有し、それらのＩ／Ｆを介してネットワーク２４に接続され、相互に通信可能である。
【００１８】
サーバ７０、仮想化スイッチ６０、及び記憶装置４０は各々Ｉ／ＯパスＩ／Ｆ ３２を有し、それを介して通信線（以下「Ｉ／Ｏパス」）３４により接続される。サーバ７０と記憶装置４０間のＩ／Ｏ処理はＩ／Ｏパス３４を用いて行われる。尚、Ｉ／Ｏパス３４は、装置間で異なる物理媒体や異なるプロトコルでデータ転送を行う通信線が用いられてもよい。また、ネットワーク２４とＩ／Ｏパス３４が同一の通信線でもよい。
【００１９】
記憶装置４０は、ＣＰＵ １２、メモリ１４、ディスク装置（以下「ＨＤＤ」）１６、ネットワークＩ／Ｆ ２２、Ｉ／ＯパスＩ／Ｆ ３２を有し、それらは内部バス１８で接続される。なお、ＨＤＤ １６は例えばＲＡＩＤ構成のディスク装置が好ましいが、必ずしもＲＡＩＤ構成でなくても良いし、単体又は複数のＨＤＤでも良い。メモリ１４は不揮発領域と高性能領域を有する。
【００２０】
記憶装置４０を制御するプログラムである制御プログラム４４はメモリ１４の不揮発領域に記憶され、起動時にメモリ１４の高性能領域へ移された後にＣＰＵ １２により実行される。記憶装置４０が有する機能は、全て制御プログラム４４により制御されて、実現される。メモリ１４には制御プログラム４４が記憶装置４０を制御、管理するために利用する管理情報４６が記憶される。更に、メモリ１４の一部は外部装置からアクセス要求のあったデータを一時的に記憶しておく領域であるデータキャッシュ４２に割り当てられる。
【００２１】
記憶装置４０は、ＨＤＤ １６が有する物理記憶領域を仮想化して１又は複数の論理ディスク装置（以下、「ＬＵ」と称す） ２０８（詳細説明は図２参照）を外部装置に対して提供する。ＬＵ ２０８は、ＨＤＤ １６と一対一に対応してもよいし、複数のＨＤＤ １６から構成される記憶領域と対応してもよい。また、１つのＨＤＤ１６が複数のＬＵ２０８に対応してもよい。その対応関係は管理情報４６中に領域マッピング情報３００の形で保持される。
【００２２】
記憶装置４０では、ＬＵ ２０８を単位として記憶領域のグループ化が行われ、そのグループ毎に独立したデータキャッシュ４２内の領域が割り当てられる。以下、このＬＵ ２０８のグループを「キャッシュグループ」と称する。その構成は、管理情報４６中にキャッシュグループ情報４６０の形で保持される。キャッシュグループの作成・削除や、それに所属するＬＵ２０８の追加・削除は動的（以下「他の処理を停止させることなく実施される」の意味で利用）に行える。また、キャッシュグループへのデータキャッシュ４２の割当量を動的に変更する機能を有する。
【００２３】
記憶装置４０は、外部からの要求に応じて、領域マッピング情報３００（詳細は図３参照）やキャッシュグループ情報４６０（詳細は図４参照）、その他記憶装置４０の構成情報を、ネットワーク２４を介して外部に送信する機能を有する。また、外部装置からネットワーク２４を介して外部から受信した指示に従い、前述の各種機能を実行する機能を有する。
【００２４】
仮想化スイッチ６０は、ＣＰＵ １２、メモリ１４、ネットワークＩ／Ｆ ２２、Ｉ／ＯパスＩ／Ｆ ３２を有し、それらは内部バス１８で接続される。メモリ１４は不揮発領域と高性能領域を有する。
【００２５】
仮想化スイッチ６０を制御するプログラムである制御プログラム６４はメモリ１４の不揮発領域に記憶され、起動時にメモリ１４の高性能領域へ移された後にＣＰＵ １２により実行される。仮想化スイッチ６０が提供する機能は、全て制御プログラム６４により制御される。また、メモリ１４には制御プログラム６４が仮想化スイッチ６０を制御、管理するために利用する管理情報６６が記憶される。
【００２６】
仮想化スイッチ６０は、本装置に接続された記憶装置４０から提供されるＬＵ ２０８を認識し、その記憶領域を仮想化して仮想ボリューム２０６を外部装置（例えばサーバ７０や他の仮想化スイッチ６０）に提供する。尚、仮想化スイッチ６０が多段接続された場合には、他の仮想スイッチ６０が提供する仮想ボリューム２０６を記憶装置４０から提供されるＬＵ ２０８と等価に扱い、その記憶領域を仮想化して仮想ボリューム２０６を外部装置に提供する。その対応関係は管理情報６６中に領域マッピング情報３００の形で保持される。仮想化スイッチ６０は、外部からの要求に応じて、領域マッピング情報３００やその他構成情報を、ネットワーク２４を介して外部に送信する機能を有する。
サーバ７０は、ＣＰＵ１２、メモリ１４、ＨＤＤ１６、ネットワークＩ／Ｆ ２２、Ｉ／ＯパスＩ／Ｆ ３２を有し、それらは内部バス１８で接続される。メモリ１４上には、オペレーティングシステム（ＯＳ）７２と管理エージェント１４４がＨＤＤ１６から読み込まれ、ＣＰＵ１２により実行される。
【００２７】
ＯＳ７２は、サーバ７０上で実行されるプログラム対して、ネットワークＩ／Ｆ ２２、Ｉ／ＯパスＩ／Ｆ ３２等のハードウェア制御や、ネットワーク２４を介した他の装置との通信、Ｉ／Ｏパス３４を通してのデータ転送処理、複数プログラム間の実行制御等、基本的な処理機能を提供するプログラム群であり、ボリュームマネージャ７８、ファイルシステム８０を含む。メモリ１４上に読み込まれたＯＳ７２は、それらや他のＯＳ７２を構成するプログラムが利用する管理情報であるＯＳ管理情報７４を有する。ＯＳ管理情報７４は、サーバ７０のハードウェア構成の情報を含む。ＯＳ７２は、ＯＳ管理情報７４中に記憶されている情報を外部プログラムが読むためのソフトウェアインターフェイスを有する。なお、本図では、サーバ７０は１つのファイルシステム８０しか有していないが、複数のファイルシステム８０を有してもよい。
【００２８】
ボリュームマネージャ７８は、記憶装置４０から提供されるＬＵ ２０８や仮想化スイッチ６０から提供される仮想ボリューム２０６の記憶領域を仮想化し、論理ボリューム２０４をファイルシステム８０に提供するプログラムである。その対応関係はＯＳ管理情報７４中に領域マッピング情報３００の形で保持される。また、ボリュームマネージャ７８は複数Ｉ／Ｏパス３４を利用したＩ／Ｏ処理の負荷分散機能を有してもよい。
【００２９】
ファイルシステム８０は、記憶装置４０から提供されるＬＵ ２０８や仮想化スイッチ６０から提供される仮想ボリューム２０６、ボリュームマネージャ７８から提供される論理ボリューム２０４の記憶領域を仮想化し、ファイル２０２を他のプログラムに提供するプログラムである。その対応関係はＯＳ管理情報７４中に領域マッピング情報３００の形で保持される。なお、ファイル２０２と同じソフトウェアインターフェイスで、論理ボリューム２０４、仮想ボリューム２０６、ＬＵ ２０８の記憶領域に直接アクセスする機能であるローデバイス機能も、ファイルシステム８０により提供されるとする。
【００３０】
管理エージェント１４４は、管理サーバ１２０上で実行されるシステム管理プログラム１４０からネットワーク２４を介して受け付けた処理要求をサーバ７０で実行し、必要に応じてその結果を、ネットワーク２４を介してシステム管理プログラム１４０に返信するプログラムである。管理エージェント１４４が行う処理は、
（１）ＯＳ管理情報７４中に記憶されている情報の読み出し、（２）ＤＢＭＳ管理情報９２中に記憶されている情報の読み出し、等である。
【００３１】
ＤＢＭＳ９０は、ＤＢに関する一連の処理・管理を実行するサーバ７０上で実行されるプログラムである。本プログラムは、ＨＤＤ１６もしくは記憶装置４０からメモリ１４に読み出されてＣＰＵ１２により実行される。メモリ１４上に読み込まれたＤＢＭＳ９０は、それが利用・管理する表・索引・ログ等（以下、まとめて「データ構造」と称する）の記憶領域の管理情報であるデータ記憶領域情報３４２を含む、ＤＢＭＳ９０の管理情報であるＤＢＭＳ管理情報９２を有する。ＤＢＭＳ９０は、ＤＢＭＳ管理情報９２を外部プログラムが読むためのソフトウェアインターフェイスを有する。ＤＢＭＳ９０は、１台のサーバ７０上で複数同時に実行することができる。
【００３２】
ＯＳ７２やＤＢＭＳ９０、管理エージェント１４４はＣＤ−ＲＯＭ（記憶媒体）に記憶されている。ＣＤ−ＲＯＭの内容は、管理サーバ１２０が有するＣＤ−ＲＯＭドライブ２０によって読み出され、ネットワーク２４を介してサーバ７０内のＨＤＤ１６もしくは記憶装置４０にインストールされる。
【００３３】
管理サーバ１２０は、ＣＰＵ１２、メモリ１４、ＨＤＤ１６、ＣＤ−ＲＯＭドライブ２０、ネットワークＩ／Ｆ ２２を有し、それらは内部バス１８で接続される。
【００３４】
メモリ１４上には、ＯＳ７２とシステム管理プログラム１４２がＨＤＤ１６から読み込まれ、ＣＰＵ１２により実行される。ＣＤ−ＲＯＭドライブ２０は、各種プログラムのインストールに用いられる。
【００３５】
管理サーバ１２０には、キーボード・マウス等の入力装置１１２および表示画面１１４を有する管理端末１１０がネットワーク２４を介して接続される。この接続は、ネットワーク２４とは異なる通信線を用いてもよく、管理サーバ７２と管理端末１１０が一体で構成されてもよい。管理者は、通常管理端末１１０を用いて情報の入出力を行うが、必要に応じてＣＤ−ＲＯＭドライブ２０を用いることもある。
【００３６】
システム管理プログラム１４０は、管理サーバ１２０が有する、システム管理機能を実現するプログラムである。ＨＤＤ１６からメモリ１４上に読み込まれ、ＣＰＵ１２により実行される。システム管理プログラム１４０は、その機能を実現するために必要な管理情報であるシステム管理情報１４２を有する。本プログラムはＣＤ−ＲＯＭに記憶されており、その内容は管理サーバ１２０が有するＣＤ−ＲＯＭドライブ２０によって読み出され、ＨＤＤ１６にインストールされる。
【００３７】
システム管理プログラム１４０は、他の装置から種々の情報を取得する。このとき、記憶装置４０と仮想化スイッ６０が保持する情報に関しては、ネットワーク２４を介して直接情報の送信要求を発行し、情報を取得する。また、サーバ７０上で実行されるプログラムが保持する情報に関しては、ネットワーク２４を介して管理エージェント１４４に対して情報の読み出し要求を発行し、それが必要な情報を読み出すことにより情報を収集する。
【００３８】
システム管理プログラム１４０は、記憶装置４０、仮想化スイッチ６０、ボリュームマネージャ７８、ファイルシステム８０（以下、これらをまとめて「仮想化機構」と称する）が保持する領域マッピング情報３００を、ＤＢＭＳ９０からデータ記憶領域情報３４２を、記憶装置４０からキャッシュグループ情報４６０を取得し、それらを取得元の識別子とともにマッピング集約情報としてシステム管理情報１４２中に記憶する。
【００３９】
また、システム管理プログラム１４０は、記憶装置４０のキャッシュグループの管理において、ある特定のキャッシュグループをキャッシュ割当量の調整で優先的に削減対象とする「フリーキャッシュグループ」として扱う。特にキャッシュ量の割り当て要求がないＬＵ２０８は、フリーキャッシュグループに属するとして制御する。
【００４０】
なお、図１では、システム管理プログラム１４０は管理サーバ１２０上で実行されているが、任意のサーバ７０、仮想化スイッチ６０、記憶装置４０上で実行されてもよい。このとき、サーバ７０ではシステム管理プログラム１４０はＨＤＤ１６に記憶され、メモリ１４に読み出された後にＣＰＵ１２により実行される。仮想化スイッチ６０、記憶装置４０ではメモリ１４の不揮発領域に記憶され、メモリ１４の高性能領域に移された後にＣＰＵ１２により実行される。
【００４１】
図２は、本実施の形態におけるＤＢＭＳ９０が管理するデータのデータマッピングの階層構成を示す図である。
図２を参照してサーバ７０と記憶装置４０との間に１つの仮想化スイッチ６０が存在する場合を説明する。以下、ある２つの階層について、ＤＢＭＳ９０に近い方を上位、ＨＤＤ１６に近い方を下位の階層と称する。ファイル２０２、論理ボリューム２０４、仮想ボリューム２０６、ＬＵ ２０８をまとめて「仮想構造」と称し、更に、仮想構造にＨＤＤ１６を加えたものをまとめて「管理構造」と称する。
【００４２】
図２では、ＤＢＭＳ９０は、それが管理しているデータ構造２００を記憶しているファイルシステム８０が提供するファイル２０２に対してアクセスを行う。ファイルシステム８０は、ファイル２０２に対するアクセスを対応する論理ボリューム２０４の領域へのアクセスに変換する。ボリュームマネージャ７８は、論理ボリューム２０４に対するアクセスを対応する仮想ボリューム２０６の領域へのアクセスに変換する。仮想化スイッチ６０は、仮想ボリューム２０６に対するアクセスを対応するＬＵ ２０８の領域へのアクセスに変換する。記憶装置４０は、ＬＵ ２０８に対するアクセスを、対応するＨＤＤ１６に対するアクセスに変換する。このように、仮想化機構は、それが上位階層に提供する仮想構造のデータを下位階層に存在する１つ以上の管理構造の記憶領域にマッピングする。
【００４３】
また、図示しないが、ある仮想構造のデータの同一部分が複数の下位階層の管理構造にマッピングされてもよい。また、ある仮想構造のデータがＨＤＤ１６にマッピングされる経路が複数存在してもよい。これらの場合には、仮想化機構が、そのようなマッピングであることを領域マッピング情報３００中に保持しておく。
【００４４】
ある管理構造が複数のサーバ７０に共有されるマッピングを有してもよい。これは、フェイルオーバ構成をとるサーバ７０とその上で実行されるＤＢＭＳ９０において利用される。
【００４５】
本実施の形態では、論理層２１２における管理構造間のデータの対応関係が明確化されればよく、サーバ７０でボリュームマネージャ７８が使用されなくてもよい。仮想化スイッチ６０は複数段存在してもよいし、仮想化スイッチ６０が存在せずにサーバ７０と記憶装置４０がＩ／Ｏパス３４により直結されてもよい。仮想化スイッチ６０に相当するスイッチが記憶領域の仮想化機能を有しなくてもよく、この場合、仮想化スイッチ６０が下位階層から提供された管理構造をそのまま上位階層へ仮想構造として提供していると考える。
【００４６】
必須事項ではないものの、後述する記憶装置４０におけるキャッシュ量の調整においては、１つのＬＵ ２０８に１つのデータ構造２０８のみが記憶されるようにマッピングを作成すると、異なるデータを同一のキャッシュグループに混在させずに済み、その効果を高めることができる。
【００４７】
以下、各装置やプログラムが保持するデータ構造に関して説明する。
【００４８】
図３は、領域マッピング情報３００のデータ構造を示す図である。領域マッピング情報３００は、仮想化機構が提供する仮想構造の領域と、それが利用する管理構造の領域の対応を保持するものであり、エントリ３０２、３０４を有する。エントリ３０２は、仮想化機構が上位階層に提供する仮想構造の領域に関する情報であり、仮想構造の識別子である仮想構造ＩＤ ３０６を保持するエントリ、その構造内の領域を示すエントリ、その領域が下位階層の複数の仮想構造へ記憶されたり、異なる経路でＨＤＤ１６に対応している場合に、それらを識別するための多重化方法を示すエントリの組を有する。エントリ３０４は、エントリ３０２に対応する下位階層の管理構造の領域に関する情報であり、管理構造を提供する仮想化機構の識別子である仮想化機構ＩＤ ３０８を保持するエントリ、管理構造の識別子である管理構造ＩＤ ３１０を保持するエントリ、その構造内領域を示すエントリの組を有する。なお、記憶装置４０においては、仮想化機構ＩＤ ３０８を有するエントリを保持しない。
【００４９】
前述のように、異なる仮想構造が同一の管理構造の記憶領域を利用することが許される。また、仮想化機構ＩＤ ３０８、仮想構造ＩＤ ３０６、管理構造ＩＤ ３１０はシステム内で一意に定まる識別子であるとする。そうでない場合でも、装置の識別子を付加することによりシステム内で一意に定まるようにすることができる。
【００５０】
図４は、キャッシュグループ情報４６０のデータ構造を示す図である。キャッシュグループ情報４６０は記憶装置４０がキャッシュグループの管理に用いる情報で、キャッシュグループの識別子であるキャッシュグループＩＤ ４６２を保持するエントリと、そのキャッシュグループに対して割り当てられるキャッシュ量の情報であるキャッシュ量４６６を保持するエントリ、そのキャッシュグループに属するＬＵ ２０８の識別子であるＬＵ ＩＤ ３６４を保持するエントリの組を有する。
【００５１】
図５は、データ記憶領域情報３４２のデータ構造を示す図である。データ記憶領域情報３４２は、ＤＢＭＳ９０が管理するデータの記憶領域管理に用いる情報で、データ構造の名前であるデータ構造名３４６を保持するエントリ、対応するデータ構造がファイル２０２のどの位置に記憶されているかの情報であるデータ記憶位置３４８を保持するエントリの組からなる。なお、データ構造名３４６は、ＤＢＭＳ９０内で一意に定まる名前であるとし、ＤＢＭＳ９０内でＤＢ毎に同じ名前が許される場合には、ＤＢの識別子も含めたものを利用する。
【００５２】
本実施の形態においては、ＤＢＭＳ９０は、データ構造が表である場合その属性が記憶される際の最大データサイズに関する情報である属性サイズ情報３５０をＤＢＭＳ管理情報９２中に有する。
【００５３】
図６は、属性サイズ情報３５０のデータ構造を示す図であり、表の名前であるデータ構造名３４６を保持するエントリ、対応する表の属性の名前である属性名３５２を保持するエントリ、そのエントリの記憶領域における最大サイズ３５４を保持するエントリの組からなる。
【００５４】
図７は、ＤＢＭＳ情報４２０のデータ構造を示す図である。
システム管理プログラム１４０は、計算機システム内で実行されるＤＢＭＳ９０に関する情報を、ＤＢＭＳ情報４２０としてシステム管理情報１４２中に保持する。この情報は、ＤＢＭＳ９０の識別子であるＤＢＭＳ ＩＤ ５８２を保持するエントリと、それが実行されるサーバ７０の識別子であるサーバＩＤ ４２２を保持するエントリ、対応するＤＢＭＳ９０のデータ内部管理方法情報４２６を保持するエントリの組を含む。データ内部管理方法情報４２６は、ＤＢＭＳ９０の型式により定まる、ログの出力フォーマットに関する情報を含む。
【００５５】
以下、本実施の形態において、ログに対して割り当てる記憶装置４０におけるデータキャッシュ４２の量を定める処理について説明する。この処理は、システム管理プログラム１４０が行う。
【００５６】
図８は、本処理開始時にシステム管理プログラム１４０に対して与えられる、処理設計情報８５０のデータ構造を示す図である。処理設計情報８５０は、処理を実施するＤＢＭＳ９０のＤＢＭＳ ＩＤ ５８２を保持するエントリ、処理が実施されるＤＢの識別子であるＤＢ ＩＤ ８５４を保持するエントリ、ログを用いて実行するＲｅ−Ｒｕｎ／Ｕｎｄｏ処理の処理性能に関する情報であるＲｅ−Ｒｕｎ性能８５６を保持するエントリ、Ｒｅ−Ｒｕｎ／Ｕｎｄｏ処理実施時の最大所要時間の設計情報であるＲｅ−Ｒｕｎ最大所要時間８５８を保持するエントリ、実行される処理の情報として、処理の識別子である処理ＩＤ ４３２を保持するエントリ、 その処理が実施される比率に関する情報である実行比率８６２を保持するエントリ、その処理において実施されるＳＱＬ文である実行ＳＱＬ文８６０を保持するエントリ、処理内でそのＳＱＬ文が何回実行されるかの期待値を示す期待回数８６４を保持するエントリの組を含む。
【００５７】
本実施の形態においては、Ｒｅ−Ｒｕｎ性能８５６は、Ｒｅ−Ｒｕｎ時に単位時間あたりに処理可能なログに記憶された処理の件数を示し、システムにおける実測値や、サーバ７０の性能とＤＢＭＳ９０の論理的処理性能から求めた論理値、システム設計時の設定値等を与える。１つの処理で複数のＳＱＬ文が実施される可能性があり、処理ＩＤ ４３２に対応する実行ＳＱＬ文８６０は複数存在しても良い。実行ＳＱＬ文８６０が繰り返し実行される場合には、期待回数８６４にそれぞれ独立したものとしてカウントする。同じ処理に含まれるＳＱＬ文でも各種条件により実施されるＳＱＬ文が異なる可能性があり、実行ＳＱＬ文８６０毎に異なる値を取り得る。なお、実行比率８６２や期待回数８６４は、設計値でもよいし、実測値でも良い。
【００５８】
図９は、ログのキャッシュ量を定める処理の処理フローである。前述のように、処理開始時に処理設計情報８５０が与えられる。また、処理により利用されるＤＢやその記憶領域は既に定義されているものとして説明する。ただし、対応するＤＢＭＳ９０や仮想化機構から取得する情報を別途設計情報として管理者が与えることにより、それらが定義されていなくても本処理を実施できる。（ステップ１１０１）
処理設計情報８５０を参照し、Ｒｅ−Ｒｕｎ性能８５６とＲｅ−Ｒｕｎ最大所要時間８５８からＲｅ−Ｒｕｎ時に処理可能な処理の最大処理件数を求める。（ステップ１１０２）
処理設計情報８５０中の実行ＳＱＬ文８６０を参照し、それらの中からＩＮＳＥＲＴ／ＵＰＤＡＴＥを実施するＳＱＬ文と、その期待回数８６４を求める。（ステップ１１０３）
ステップ１１０３で求めたＩＮＳＥＲＴ／ＵＰＤＡＴＥを行う実行ＳＱＬ文８６０を１回実行した際に出力されるログの最大量を把握する。まず、対象となる実行ＳＱＬ文８６０からデータの挿入／更新が行われる表とその属性の名前をそれぞれ把握する。そして、属性サイズ情報３５０を参照してそれらの最大サイズ３５４を求める。また、ＤＢＭＳ情報４２０中のデータ内部管理方法情報４２６からログの出力フォーマットの情報を取得し、それらから各実行ＳＱＬ文８６０においてログとして出力される最大データ量を把握する。（ステップ１１０４）
ステップ１１０３とステップ１１０４で求めた値を用いて、ログを出力する各処理の１件あたりのログ出力量を計算する。この値は、ある処理に属するＩＮＳＥＲＴ／ＵＰＤＡＴＥを行う実行ＳＱＬ文８６０によるログの最大データ量と期待回数８６４の積の値の和として求める。更に、ＤＢＭＳ情報４２０中のデータ内部管理方法情報４２６からログのヘッダや処理がコミットされたときに出力されるデータ等の出力フォーマットに関する情報を把握し、その分もログ出力量に加える。最後に、求めた値を、記憶装置のブロックサイズ（５１２ｂｙｔｅ）を単位として切り上げ処理を実施する。（ステップ１１０５）
ステップ１１０５で求めたログを出力する処理１件あたりのログ出力量と、処理設計情報８５０中の各処理における実行比率８６２から、ログを出力する処理１件あたりの平均ログ出力量を求める。そして、この値とステップ１１０２で求めたＲｅ−Ｒｕｎ時に処理可能な最大処理件数の積の値に、事前に定めた余裕分を加えた量をＲｅ−Ｒｕｎ時に必要となるログ量とする。（ステップ１１０６）
ステップ１１０６で求めた量のログが記憶装置４０上に常に存在するようなキャッシュ量の設定を求める。ＤＢＭＳ９０のログがどの記憶装置４０に記憶され、更に、そのログがどのＬＵ２０８上に記憶され、そのＬＵ２０８がどのキャッシュグループに存在するか、マッピング集約情報から把握する。求めたキャッシュグループに対し、ステップ１１０５で求めたＲｅ−Ｒｕｎ時に必要となるログ量以上のキャッシュを割り当てる。なお、記憶装置４０が書き込まれたデータを２重化する場合には、必要に応じてログ量に対して２倍のキャッシュ量が必要であるとする。
【００５９】
ログが記憶されるＬＵ２０８がフリーキャッシュグループに属する場合には、それらのみのキャッシュグループを定義し、そこにＲｅ−Ｒｕｎ時に必要となるログ量を割り当てることとする。複数のＬＵ２０８に分割されてログが記憶され、かつ、それらが異なるキャッシュグループに属する場合には、それぞれにＲｅ−Ｒｕｎ時に必要となるログ量を割り当てる。ログが記憶されるＬＵ２０８が属するキャッシュグループに他のデータも記憶されるマッピングがマッピング集約情報から得られた場合、例えば、以前のキャッシュグループの設定値から他のデータが記憶される分のキャッシュ量を別途求め、その値にＲｅ−Ｒｕｎ時に必要となるログ量を加算した値をそのキャッシュグループのキャッシュ量とする。（ステップ１１０７）
ステップ１１０６で求めたキャッシュグループとそのキャッシュ量の設定を、記憶装置４０に対して発行する。処理に利用されるＤＢがＤＢＭＳ９０でまだ定義されていない場合には、その定義と記憶領域を確保した後にこのステップを実施する。（ステップ１１０８）
そして、処理を完了する。（ステップ１１０９）
これまで、記憶装置４０はＬＵ２０８を外部装置に提供し、それはＩ／Ｏパス３４を経由してアクセスされるとしてきた。記憶装置４０がファイル２０２を外部装置に提供し、そのファイル２０２がネットワークファイルシステムプロトコルを用いてネットワーク２４経由でアクセスされてもよい。
【００６０】
図１０は、上述した第一の実施形態の変形例であり、記憶装置４０がファイル２０２を外部装置に提供する場合の計算機システムの構成を示す図である。その場合には、以下のような違いがある。
【００６１】
サーバ７０はＩ／ＯパスＩ／Ｆ ３２を有さなくともよい。ＯＳ７２は外部装置が提供するファイル２０２を、ネットワークファイルシステムプロトコルを用いてネットワークＩ／Ｆ ２２、ネットワーク２４経由でアクセスするネットワークファイルシステム８２を含み、ボリュームマネージャ７８やファイルシステム８０を有さなくともよい。ネットワークファイルシステムは領域マッピング情報３００をＯＳ管理情報７４中に有する。ＤＢＭＳ９０により認識されるファイル２０２と記憶装置４０から提供されるファイル２０２があるルールに従って対応する場合、その対応関係を定めるルールの情報のみがＯＳ管理情報７４中に保持されても良い。この場合には、システム管理プログラム１４０は対応関係を定める情報を取得し、それから領域マッピング情報３００を作成し、マッピング集約情報中に記憶する。
【００６２】
記憶装置４０はＩ／ＯパスＩ／Ｆ ３２を持たなくてもよく、ファイルを外部装置に対して提供する。記憶装置４０の制御プログラム４４はファイルシステム８０が提供する機能を有し、記憶装置４０内に存在するＬＵ２０８の記憶領域を仮想化し、ファイル２０２を提供する。また、制御プログラム４４は１つ以上のネットワークファイルシステムプロトコルを解釈し、ネットワーク２４、ネットワークＩ／Ｆ ２２経由で外部装置からそのプロトコルを用いて要求されるファイルアクセス処理を実施する。この記憶装置４０では、キャッシュグループのメンバの管理単位がＬＵ２０８ではなくファイル２０２を単位とする。
【００６３】
データのマッピングに関しては、図２で説明したデータのマッピング階層構成において、ファイル２０２以下が全て記憶装置４０により提供されるようになり、サーバ７０はＯＳ７２内のネットワークファイルシステム８２を用いて記憶装置４０上にあるファイル２０２をアクセスする。
記憶装置４０がファイル２０２を外部装置に提供する場合、本実施の形態において実施する処理においては、ＬＵ２０８を考えている部分を記憶装置４０上のファイル２０２に対応させる。
【００６４】
・第二の実施の形態
第二の実施の形態では、ＤＢＭＳで実施される処理の設計情報から表・索引データに対するキャッシュ量の初期割り当てを好適化する。ＤＢＭＳで実施される処理の組があらかじめ明確になっている場合、処理内容の解析からあるデータ全体へのアクセス量はおおよその見当がつく。データ内でのおおよそのアクセス特性を与え、それと処理内容の解析結果を基に、ある量のキャッシュを割り当てた場合のキャッシュヒット率の概算値を求め、データに対して割り当てるキャッシュ量を決定する。本実施の形態では、計算機システムが、ＤＢＭＳのキャッシュと記憶装置のデータキャッシュを１つのキャッシュ領域とみなして管理するための機構を有し、双方で記憶データの重複がほとんどないことを前提とする。
【００６５】
図１１は、第二の実施形態による計算機システムの構成を示す図である。第二の形態における計算機システムの構成は、第一の形態のものと基本的に同じである。以下、第一の形態との差異を中心にして第二の実施形態について説明する。
【００６６】
ＤＢＭＳ９０は、メモリ１４上の領域をキャッシュ９４として利用し、ＤＢＭＳ管理情報９２中に表データ量情報７００とＢ−Ｔｒｅｅ索引情報７１０を含むＤＢＭＳ９０ｂとなる。ＤＢＭＳ９０ｂは属性サイズ情報３５０を保持する必要はない。ＤＢＭＳ９０ｂは、データ構造毎にキャッシュ９４の利用量を管理する機能を有し、その設定情報は表データ量情報７００やＢ−Ｔｒｅｅ索引情報７１０に含まれる。ＤＢＭＳ９０ｂは、データ構造毎のキャッシュ９４の利用量を動的に変更するためのソフトウェアインターフェイスを有する。
【００６７】
管理エージェント１４４がシステム管理プログラム１４０からの指示に従って実行する処理に、データ構造毎のキャッシュ９４の利用量の変更をＤＢＭＳ９０ｂに指示することが加わる。システム管理プログラム１４０は、システム管理情報１４２中に保持するＤＢＭＳ情報４２０にデータ内部管理方法情報４２６を有する必要はない。
【００６８】
更に大きな違いとして、Ｉ／Ｏパス３４を通してキャッシュ化要求９５４とキャッシュ化要求付ライト要求９５８が伝達される。キャッシュ化要求９５４は、記憶装置４０ｂ内に格納されているデータをデータキャッシュ４２に保持することを求める要求であり、通常のリード要求９５０と同様の形式でデータが指定される。キャッシュ化要求付ライト要求９５８は書き込まれたデータを記憶装置４０ｂ内でデータキャッシュ４２に保持することを求める要求である。
【００６９】
キャッシュ化要求９５４とキャッシュ化要求付ライト要求９５８を使用した例として、Ｉ／Ｏパス３４上でのデータ転送プロトコルとしてＳＣＳＩ（Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ）を基にしたものを利用する場合について説明する。第一の方法としては、キャッシュ化要求９５４とキャッシュ化要求付ライト要求９５８に対応するオペレーションコードを新規に作成する。第二の方法としては、既存のプリフェッチとライトのオペレーションコードを利用し、コマンド中のコントロールバイトのベンダ依存ビットにキャッシュヒントを意味するビットを定義し、その値が“０”の時には通常の処理を、その値が“１”のときに、オペレーションコードがプリフェッチコマンドの場合にはキャッシュ化要求９５４、オペレーションコードがライトのときにはキャッシュ化要求付ライト要求９５８として処理する。なお、他のデータ転送プロトコルを用いても同様の方法で実現可能である。
【００７０】
本実施の形態においては、仮想化スイッチ６０は、仮想ボリューム２０６へのキャッシュ化要求９５４とキャッシュ化要求付ライト要求９５８を、対応する管理構造へのキャッシュ化要求９５４やキャッシュ化要求付ライト要求９５８に変換する機能を制御プログラム６４により実現する仮想スイッチ６０ｂとなる。サーバ７０上のＯＳ７２は、上位プログラムからのキャッシュ化要求９５４とキャッシュ化要求付ライト要求９５８をＩ／Ｏパス３４を通して送出可能なＯＳ７２ｂに変更される。ＤＢＭＳ９０ｂはキャッシュ化要求９５４とキャッシュ化要求付ライト要求９５８を送出する機能を有する。記憶装置４０は、制御プログラム４４によりキャッシュ化要求９５４とキャッシュ化要求付ライト要求９５８が解釈可能な記憶装置４０ｂとなる。
【００７１】
本実施の形態において、記憶装置４０のキャッシュグループ情報４６０は記憶装置４０ｂではキャッシュグループ情報４６０ｂとなる。キャッシュグループ情報４６０ｂ中のヒント機能４６８の値が“ＯＮ”であるキャッシュグループに属するＬＵ２０８内のデータに対してキャッシュ化要求９５４やキャッシュ化要求付ライト要求９５８を受け取った場合、それらにより指示されたデータに関しては長時間データキャッシュ４２に保持するようにする。例えば、記憶装置４０ｂがキャッシュグループ内のデータ領域の管理を、ＬＲＵ置換アルゴリズムを用いて行う場合、要求データをＭＲＵデータ化する。なお、キャッシュ化要求９５４を受け取り、それで指示されたデータがデータキャッシュ４２内に存在しない場合、そのデータをＨＤＤ１６から読み出してデータキャッシュ４２上に格納する。そのＬＵ２０８に対してリード要求９５０やライト要求９５６があった場合、その要求を完了後、そのデータは原則データキャッシュ４２には保持しない。記憶装置４０ｂの内部制御の都合上、データキャッシュ４２に保持する必要がある場合でも、保持する必要がなくなったら、そのデータを保持する領域がすぐに再利用されるようにする。（前述の例ではその時点のＬＲＵデータとして扱う。）
図１２は、キャッシュ化要求９５４とキャッシュ化要求付ライト要求９５８を用いた際の、ＤＢＭＳ９０ｂと記憶装置４０ｂとの間のデータ制御を説明した図である。各領域での処理開始時にＤＢＭＳ９０ｂや記憶装置４０ｂはそのデータをキャッシュ９４やデータキャッシュ４２上に保持していない。なお、図を簡略化するため、処理の受諾や完了の応答は図から省いてある。
【００７２】
領域９６２は、ＤＢＭＳ９０ｂがデータの読み出しのみを行った際のデータ制御を示す。
まず、ＤＢＭＳ９０ｂがリード要求９５０を記憶装置４０ｂに発行し、それに応答して記憶装置４０ｂがＤＢＭＳ９０ｂに要求されたデータを転送する（データ転送９５２）。記憶装置４０ｂはデータを転送した後、そのデータをデータキャッシュ４２に保持しない。ＤＢＭＳ９０ｂは転送されたデータをキャッシュ９４に格納する。ＤＢＭＳ９０ｂは、データをキャッシュ９４から破棄する際に、リード要求９５０と同様の方法でキャッシュ化要求９５４を記憶装置４０ｂに送出する。キャッシュ化要求９５４を受け取った記憶装置４０ｂは要求データをＨＤＤ１６から読み出し、データキャッシュ４２上に保持する。
【００７３】
領域９６４は、ＤＢＭＳ９０ｂがデータの更新を行う際の第一のデータ制御を示す。ＤＢＭＳ９０ｂがデータをキャッシュ９４上に読み出すまでは領域９６２と同様である。その後、ＤＢＭＳ９０ｂはキャッシュ９４上のデータを更新し、更新したデータを記憶装置４０ｂに書き込む（ライト要求９５６＋データ転送９５２）。記憶装置４０ｂは、受領したデータを対応するＨＤＤ１６に書き込み、データキャッシュ４２上にそのデータを保持しない。
その後、ＤＢＭＳ９０ｂは、データをキャッシュ９４から破棄する際に、キャッシュ化要求９５４を記憶装置４０ｂに送出する。キャッシュ化要求９５４を受け取った記憶装置４０ｂは要求データをＨＤＤ１６から読み出し、データキャッシュ４２上に保持する。
【００７４】
領域９６６は、ＤＢＭＳ９０ｂがデータの更新を行う際の第二のデータ制御を示す。ＤＢＭＳ９０ｂがデータをキャッシュ９４上で更新するまでは領域９６４と同様である。データ更新後、本制御では、キャッシュ９４上からデータを破棄するまで記憶装置４０ｂへのデータ書き込みを行わない。データをキャッシュ９４から破棄する際に、ＤＢＭＳ９０ｂは、更新したデータを記憶装置４０ｂに書き込むと同時にキャッシュ化要求を行う（キャッシュ化要求付ライト要求９５８＋データ転送９５２）。キャッシュ化要求付ライト要求９５８を受け取った記憶装置４０ｂは書き込まれたデータをデータキャッシュ４２上に保持する。データのＨＤＤ１６への書き込みは適宜行う。
【００７５】
なお、これまでの説明はキャッシュ化要求９５４を用いた方法で説明してきたが、ＤＢＭＳ９０ｂがデータ破棄時に常にキャッシュ化要求付ライト要求９５８を発行しても良い。この場合、各装置はキャッシュ化要求９５４を処理できる必要はない。
【００７６】
図１３は、キャッシュグループ情報４６０ｂのデータ構造を示す図である。第一の実施の形態と比較して、キャッシュグループＩＤ ４６２を保持するエントリ毎にヒント機能４６８を保持するエントリが付加される。ヒント機能４６８はキャッシュヒント機能が有効か無効かを示す情報で、有効な場合は“ＯＮ”が、無効な場合には“ＯＦＦ”がその値として記憶される。ヒント機能４６８の値が“ＯＮ”のときの制御は前述の通りである。その値が“ＯＦＦ”の場合は、一般的なキャッシュのデータ管理手法を用いる。例えば、データキャッシュ４２内に保持されるデータをＬＲＵ置換アルゴリズムで管理し、アクセスされたデータはその種別に関わらず全てその時点でＭＲＵデータ化する。
【００７７】
図１４は、表データ量情報７００のデータ構造を示す図である。表データ量情報７００は、表のデータ構造名３４６を保持するエントリと、その表におけるデータページの大きさに関する情報であるデータページサイズ７０２を保持するエントリとその表が利用しているデータページ数７０４を保持するエントリ、そのデータが利用可能なキャッシュ９４の量に関する情報であるキャッシュ量４６６を保持するエントリを有する。
【００７８】
図１５は、Ｂ−Ｔｒｅｅ索引情報７１０のデータ構造を示す図である。Ｂ−Ｔｒｅｅ索引情報７１０は、索引のデータ構造名３４６を保持するエントリと、その索引が付加された表のデータ構造名３４６である対応表名７１２を保持するエントリ、データページサイズ７０２を保持するエントリ、データページ数７０４を保持するエントリ、データページのうち、Ｂ−Ｔｒｅｅ索引のリーフノードのデータを保持しているデータページ数であるＬｅａｆノードページ数７１４を保持するエントリ、その索引のキャッシュ量４６６を保持するエントリ、その索引を利用して検索が行われる属性の属性名３５２の組である検索属性７１６を保持するエントリ、検索属性７１６における１回の検索で得られると期待されるタプル数の情報である期待タプル数７１８を保持するエントリの組からなる。なお、１つの索引に複数の検索属性７１６とそれに対応する期待タプル数７１８が存在することがある。また、期待タプル数７１８は、対応する表のデータ解析により得られる値で、平均値や最頻値、あるいは各種指標から計算した値が用いられる。
【００７９】
以下、本実施の形態において、ＤＢＭＳ９０ｂや記憶装置４０ｂにおけるキャッシュ量を設定する処理を説明する。本処理は、システム管理プログラム１４０が行う。
【００８０】
図１６は、キャッシュ量情報７２０のデータ構造を示す図である。キャッシュ量情報７２０は、処理開始時にシステム管理プログラム１４０に対して与えられる、ＤＢＭＳ９０ｂや記憶装置４０ｂにおいて利用可能なキャッシュ量に関する情報であり、処理が実施されるＤＢＭＳ９０ｂのＤＢＭＳ ＩＤ ５８２を保持するエントリとそのＤＢＭＳ９０ｂで利用可能なキャッシュ９４の量に関する情報であるキャッシュ量７２２を保持するエントリの組と、処理に利用されるデータを保持する記憶装置４０ｂ（装置）の識別子である装置ＩＤ ５７２を保持するエントリとそこで利用可能なデータキャッシュ４２の量であるキャッシュ量７２２を保持するエントリの組を含む。
【００８１】
図１７は、処理開始時にシステム管理プログラム１４０に対して与えられる情報である、表アクセス分布情報７３０のデータ構造を示す図である。表アクセス分布情報７３０には、処理に利用される表のデータ構造名３４６を保持するエントリと、その表におけるデータページへのアクセス頻度の分布に関する情報であるアクセス分布７３２を保持するエントリの組を含む。アクセス分布７３２は、アクセス頻度が高い順に並び替えられているとし、理論値／実測値のどちらでもよい。その分布がわからない場合には一般化されたＺｉｐｆ分布に従うとし、ｋ番目に高いアクセス確率を持つデータページへのアクセス確率をＦ（ｋ）としたときに、Ｆ（ｋ） ＝ Ｃ／ｋα （α：パラメータ（０＜＝α）、Ｃ：補正係数（Ｃ＝１／Σ（１／ ｃα）））である仮定する。このとき、データページ数が少ない場合にはαを０に近い値（例えば０．２５程度）とし、データページ数が多い場合にはαを１に近い値（例えば０．７５程度）とする。また、データのＩＮＳＥＲＴが行われる、ＩＮＳＥＲＴされたデータがある程度の時間経過後に更新される、等の時間的局所性を有する処理が行われる場合には、それによりアクセスされる領域が限られ、データページの一定割合（例えば８割）はデータアクセスがされない（アクセス確率が０）としてもよい。
【００８２】
図１８は、システム管理プログラム１４０がシステム管理情報１４２中に保持する期待アクセスページ数情報７８０のデータ構造を示す図である。期待アクセスページ数情報７８０は、処理ＩＤ ４３２を保持するエントリ、その処理によりアクセスされるデータ構造のデータ構造名３４６を保持するエントリと、そのデータ構造に対して処理あたり幾つの異なるデータページが利用されると期待されるかの情報を示す期待アクセスデータページ数７８４を保持するエントリの組からなる。期待アクセスデータページ数７８４は、参照と更新（データの挿入を含む）の双方を含めてアクセスされるデータページ数の総計値を保持するエントリと、更新が行われる（参照のみを除いた）データページ数が保持されるエントリを有する。
【００８３】
期待アクセスページ数情報７８０は設計情報として管理者が与えてもよいし、また、キャッシュ量を設定する処理を開始する前に、システム管理プログラム１４０に処理設計情報８５０を与え、それから以下のように作成してもよい。なお、この場合の処理設計情報８５０には、Ｒｅ−Ｒｕｎ性能８５６とＲｅ−Ｒｕｎ最大所要時間８５８を保持するエントリが含まれなくともよい。
【００８４】
まず、処理設計情報８５０から実行ＳＱＬ文８６０を参照し、それぞれのＳＱＬ実行計画をＤＢＭＳ９０ｂから取得、各処理ステップでアクセスされるデータ構造とそのアクセス方法（データの挿入／更新を含む）を把握する。その結果と、ＤＢＭＳ９０ｂから取得するＢ−Ｔｒｅｅ索引情報７１０を利用し、ＳＱＬ実行計画中の各処理ステップにおいて処理するデータ量（タプル数）を把握する。求めたアクセスされるデータ構造と、そのアクセス方法と、各処理ステップにおける処理データ量から、アクセスされるデータページ数とアクセス内容（参照／更新）を把握する。このとき、基本的に、各タプルは異なるデータページに存在すると考える。ただし、あるＢ−Ｔｒｅｅ索引により検索されるタプルがどのようにデータページに分散されるかの情報をＢ−Ｔｒｅｅ索引情報７１０中に含めておき、それを利用してアクセスされるデータページ数をより詳細に求めてもよい。この処理の全部／一部として、ＤＢＭＳ９０ｂでＳＱＬ実行計画を作成するときに内部的に見積られた値をＳＱＬ実行計画と同時に出力させ、その値を利用してもよい。求めた値に、実行ＳＱＬ文８６０に対応する期待回数８６４を乗じた値を期待アクセスページ数情報７８０に設定する。
【００８５】
図１９は、ＤＢＭＳ９０ｂや記憶装置４０ｂにおけるキャッシュ量を設定する処理の処理フローである。本処理においては、各データ構造毎に、ＤＢＭＳ９０ｂと各記憶装置４０ｂにおけるキャッシュ量の割り当てを求めるものとする。処理開始前に期待アクセスページ数情報７８０がシステム管理情報１４２中に保持される。処理開始時、処理設計情報８５０ｂ、キャッシュ量情報７２０、表アクセス分布情報７３０が与えられる。なお、処理設計情報８５０ｂは、処理設計８５０から実行ＳＱＬ文８６０と期待回数８６４を保持するエントリが除かれたものである。ここでは、処理により利用されるＤＢやその記憶領域は既に定義されているものとして説明する。ただし、対応するＤＢＭＳ９０ｂや仮想化機構から取得する情報を別途設計情報として管理者が与えることにより、それらが定義されていなくても本処理を実施できる。（ステップ１４０１）
まず、表・索引の各データ構造に対して、処理を実施する際に必要となる最小限の量として、ＤＢＭＳ９０ｂにおけるキャッシュ９４と各記憶装置４０ｂにおけるデータキャッシュ４２での利用量を、それぞれ事前に定められる一定量分割り当てる。
【００８６】
なお、本処理の全てのステップにおいて、データの記憶先の記憶装置４０ｂは、システム管理情報１４２中に保持されているマッピング集約情報から把握する。複数の記憶装置４０ｂに対してデータが記憶されている場合には、特に断らない限り、マッピング集約情報から各記憶装置４０ｂ毎のデータの記憶比率を把握し、それに比例したキャッシュ量をそれぞれに割り当てる。ＤＢＭＳ９０ｂや記憶装置４０ｂにおいて、キャッシュ量情報７２０中にキャッシュ量７２２として与えられたキャッシュの利用量の上限を超えた量を要求する場合にはエラーとして処理を終了する。（ステップ１４０２）
次に、ＤＢＭＳ９０ｂからＢ−Ｔｒｅｅ索引情報７１０を取得する。その後、各索引毎に、取得した情報中のデータページ数７０４とＬｅａｆノードページ数７１４の差とデータページサイズ７０２から、リーフノード以外のデータを記憶するデータページの量を把握し、それと同量のキャッシュ９４の利用量を割り当てる。（ステップ１４０３）
続いて、各索引毎に、Ｌｅａｆノードページ数７１４とデータページサイズ７０２からリーフノードのデータ量を把握し、それと同量のデータキャッシュ４２の利用量と、それに対して事前に定められた比率（例えば２０％）分のキャッシュ９４の利用量を割り当てる。（ステップ１４０４）
各表毎にキャッシュ効果関数を指定し、ステップ１６０１から始まる処理を実施し、各表のデータに対してキャッシュ９４の利用量を指定する。ここで、キャッシュ効果関数Ｅ（ｉ）は「あるデータ構造における、データを利用するときに既にそのデータがキャッシュ上に存在する（キャッシュヒットする）確率の、キャッシュ上に保持可能なデータページ数をｉ−１からｉに増加させたときの増分」と定義する。
従って、ΣＥ（ｉ）＝１である。ここでは、近似として表アクセス分布情報７３０で与えられるアクセス分布７３２をそのまま与える。ただし、アクセス分布７３２をベースにキャッシュ効果関数を別途定義してもよい。（ステップ１４０５）
記憶装置４０ｂにおいて、データキャッシュ４２がライトキャッシュとしても利用される場合に、各データ構造にその利用分を考慮したデータキャッシュ４２を割り当てる。まず、処理設計情報８５０ｂ中の期待アクセスページ数情報７２０を参照し、期待アクセスデータページ数７８４の更新データページ数の値が０でないデータ構造を有する処理を求める。それらの処理のうちどれか１つが実施された際の各データ構造毎の期待データページ更新数を、処理設計情報８５０ｂ中の処理の実行比率８６２による重み付けを考慮しながら期待アクセスデータページ数７８４の更新データページ数から求める。次に、処理設計情報８５０ｂ中のＲｅ−Ｒｕｎ性能８５６とＲｅ−Ｒｕｎ最大所要時間８５８からＲｅ−Ｒｕｎ時に処理可能な処理の最大処理件数を求め、それと既に求めた更新が行われる処理あたりの各データ構造毎の期待データページ更新数の積を求める。
【００８７】
求めた値と、データ構造における現在のキャッシュ９４の割り当て量に事前に定めた割合（例えば７０％）を乗じた値を比較し、そのうち値が小さな方をデータ構造に対するライトキャッシュ必要量とする。データキャッシュ４２の割当量がその値未満のデータ構造に対して、その量に達するようにデータキャッシュ４２の割り当てを行う。なお、ある記憶装置４０ｂが書き込まれたデータを２重化する場合には、必要に応じて求めた値の２倍のキャッシュ量が必要であるとする。
【００８８】
なお、本ステップは必ずしも実施される必要はない。この場合、処理設計情報８５０ｂ中にＲｅ−Ｒｕｎ性能８５６やＲｅ−Ｒｕｎ最大所要時間８５８が保持される必要はない。（ステップ１４０６）
各表毎にキャッシュ効果関数を指定し、ステップ１６０１から始まる処理を実施し、各表のデータに対してデータキャッシュ４２を割り当てる。ここでも、キャッシュ効果関数は、近似として表アクセス分布情報７３０で与えられるアクセス分布７３２をそのまま与える。ただし、アクセス分布７３２をベースにキャッシュ効果関数を別途に定義してもよい。特に、ＤＢＭＳ９０ｂでのキャッシュ９４の制御方法、記憶装置４０ｂにおけるデータキャッシュ４２の制御方法の違いを考慮して、ステップ１４０５と異なる関数を用いてもよい。（ステップ１４０７）
これまでに求めたキャッシュ量の設定を、ＤＢＭＳ９０ｂや記憶装置４０ｂに対して発行する。処理に利用されるＤＢがＤＢＭＳ９０ｂでまだ定義されていない場合には、その定義と記憶領域の確保と同時、もしくは確保後にこのステップを実施する。
【００８９】
記憶装置４０ｂへのキャッシュ量の指示は以下のように行う。マッピング集約情報を参照し、処理で利用されるデータ構造のデータを保持するＬＵ２０８を確認し、それがフリーキャッシュグループに属している場合には、同じデータ構造のデータが記憶されるＬＵ２０８をメンバとするキャッシュグループを作成するように記憶装置９０ｂに対して指示を出す。その後に各データ構造を記憶するＬＵ２０８が属するキャッシュグループに対して求めたキャッシュ量の設定を行う。なお、あるデータ構造のデータが異なるキャッシュグループに属する複数のＬＵ２０８上に記憶される場合には、マッピング集約情報からそれぞれに記憶されているデータ量を把握し、それに比例するように割当を行う。マッピング集約情報から、データ構造のデータが他のデータと同一のキャッシュグループに属することになる場合には、それらのデータ構造に対して割りあてられた量の和としてキャッシュグループのキャッシュ量を設定する。このとき、本処理によるキャッシュ量の割当とは別に割り当てが行われている場合には、必要に応じて、以前のキャッシュグループの設定値から他のデータが記憶される分のキャッシュ量を別途求める。（ステップ１４０８）
そして、処理を完了する。（ステップ１４０９）
なお、本処理は、記憶装置４０ｂのデータキャッシュ４２の割当のみを実施する場合に実行しても良い。この場合、ＤＢＭＳ９０ｂにおける各データ構造へのキャッシュ９４の割当が処理開始時に与えられる。そして、ステップ１４０２からステップ１４０５までと、ステップ１４０８におけキャッシュ９４に関する処理は実施しない。
【００９０】
図２０は、キャッシュ効果関数を利用してキャッシュ量の割り当てを行う処理の処理フローを示す。本処理はステップ１４０１から始まる処理の一部であり、その処理が利用可能な情報は全て利用できる。以下、説明のため、処理に利用される表に通番ｔを付加し、各表毎に定まる定数や関数等は、この通番を利用してそれぞれのものとして識別する。本処理の開始時、各表毎にキャッシュ効果関数Ｅｔ（ｉ）と割り当てを行うキャッシュがＤＢＭＳ９０ｂのキャッシュ９４か記憶装置４０ｂのデータキャッシュ４２かに関する指定が与えられる。また、必要に応じて、現在のキャッシュ割当量を求める方法も指定される。（ステップ１６０１）
現在までに割り当てられたキャッシュ量を各表毎に求め、それをデータページ数に換算した値をｎｔに設定する。このとき、処理開始時に特に指定がない限り、キャッシュ９４とデータキャッシュ４２のそれぞれに割り当てられた値の総計としてキャッシュ量を求める。（ステップ１６０２）
次に、各表毎に以下の値を計算する。
【００９１】
Ａｔ ＝ Σ（（表に対する処理の期待アクセスページ数（総計値））×（処理の実行比率））
ここで、Σは処理に関して総和を取ることを示す。表に対する処理の期待アクセスページ数は期待アクセスページ数情報７８０から求めることができ、処理の実行比率は処理設計情報８５０ｂから求めることができる。（ステップ１６０３）
次に、各表毎に指定されたキャッシュ効果関数を用いて以下の値を計算する。
【００９２】
Ｗｔ（ｎｔ） ＝ Ａｔ×Ｅｔ（ｎｔ）
（ステップ１６０４）
ステップ１６０４で求めたＷｔ（ｎｔ）の値が一番大きな表を選択し、その表に対して１データページ分キャッシュを割り当てる。
【００９３】
データキャッシュ４２の割り当ての場合には、Ｗｔ（ｎｔ）の選択後に以下の処理も行う。マッピング集約情報を参照して、その表のデータがどの記憶装置４０ｂにどれだけの量が記憶されているかを求め、その量に比例して追加されたデータキャッシュ４２の割り当て量を記憶装置４０ｂ間で分配する。このとき、特定の記憶装置４０ｂにおける、各データ構造に対するデータキャッシュ４２の割当量の和がキャッシュ量情報７２０中にキャッシュ量７２２として与えられた値に達している場合には、そこへの割り当ては不可能とし、他の記憶装置４０ｂのみを考えて追加されたキャッシュ量の分配を行う。選択された表において、そのデータを保持する全ての記憶装置４０ｂでデータキャッシュ４２の割り当てが不可能と判断される場合、その表に対するキャッシュの割り当ては行わず、次にＷｔ（ｎｔ）の値が大きな表をキャッシュの割り当て対象とし、同様の確認を繰り返す。
【００９４】
そして、選択された表のｎｔの値に１を加える。（ステップ１６０５）
キャッシュが全て割り当てられたか確認し、まだ割り当て可能な未割り当て分が存在する場合にはステップ１６０４に戻る。割り当てが完了した（これ以上割り当てを続行できない）場合には、ステップ１６０７に進み、処理を完了する。（ステップ１６０６）
ここで、処理を完了する。（ステップ１６０７）
これまで、記憶装置４０ｂはＬＵ２０８を外部装置に提供し、それはＩ／Ｏパス３４を経由してアクセスされるとしてきた。第一の実施の形態と同様に、記憶装置４０ｂがファイル２０２を外部装置に提供し、そのファイル２０２がネットワークファイルシステムプロトコルを用いてネットワーク２４経由でアクセスされてもよい。この場合、第一の実施の形態と同様の対応関係がとられる。
【００９５】
主な相違点として、記憶装置４０ｂでは、キャッシュグループのメンバの管理単位が、ファイル２０２が単位となり、本実施の形態において実施する処理においては、ＬＵ２０８の部分が記憶装置４０ｂ上のファイル２０２に対応するようになる。
・第三の実施の形態
第三の実施の形態は、第二の実施の形態において利用されていたキャッシュ化要求９５４とキャッシュ化要求付ライト要求９５８が利用されない条件の下、ＤＢＭＳで実施される処理の設計情報から表・索引データに対するキャッシュ量の初期割り当てを好適化する。つまり、本実施の形態では、ＤＢＭＳのキャッシュと記憶装置のデータキャッシュがそれぞれ独立に管理され、双方の間でキャッシュ上に保持されるデータが一部重複することを前提とする点が第二の実施の形態と異なる。
【００９６】
第三の実施における計算機システムの構成は、基本的に第二の実施形態のものと似ている。以下、本実施の形態について第二の実施形態との違いを中心にして説明する。
【００９７】
前述のように、本実施の形態においては、キャッシュ化要求９５４とキャッシュ化要求付ライト要求９５８が利用されない。そのため、記憶装置４０ｂ、仮想化スイッチ６０ｂ、ＯＳ７２ｂは、第一の実施の形態と同じ記憶装置４０、仮想化スイッチ６０、ＯＳ７２となる。また、ＤＢＭＳ９０ｂは、キャッシュ化要求９５４とキャッシュ化要求付ライト要求９５８を送出する機能を有さないＤＢＭＳ９０ｃになる。
【００９８】
記憶装置４０では、データキャッシュ４２内のデータ管理に関し、一般的な手法を用いる。例えば、データキャッシュ４２内に保持されるデータをＬＲＵ置換アルゴリズムで管理し、アクセスされたデータはその種別に関わらず全てその時点でＭＲＵデータ化する。
【００９９】
本実施の形態では、ステップ１４０１から始まるキャッシュ量を設定する処理がステップ１４０１ｂから始まる処理に変更される。図２１は、ステップ１４０１ｂから始まるＤＢＭＳ９０ｃや記憶装置４０におけるキャッシュ量を設定する処理の処理フローである。ステップ１４０１ｂから始まる処理では、ステップ１４０１から始まる場合に実行されるステップ１４０７がステップ１４２１からステップ１４２３までの処理に変更される。なお、本処理は、第二の実施の形態と同様にして、記憶装置４０のデータキャッシュ４２の割当のみを実施する場合に実行しても良い。
【０１００】
表のデータ量を表データ量情報７００から求め、その値の一定割合（例えば９０％）以上の量のキャッシュ９４が割り当てられた表を、以降の記憶装置４０のデータキャッシュ４２の割り当て対象から除く選択処理を行う。（ステップ１４２１）
次に、ステップ１４０７と同様に、各表毎にキャッシュ効果関数を指定し、ステップ１６０１から始まる処理を実施し、各表のデータに対してデータキャッシュ４２の利用量を割り当てる。このとき、ステップ１６０２で設定する現在までに割り当てられたキャッシュ量は、記憶装置９０におけるデータキャッシュ４２の割当量のみを考慮するように指示する。キャッシュ効果関数は、キャッシュ９４とデータキャッシュ４２の間でのデータの重複を考慮しないものを与えるとし、近似として表アクセス分布情報７３０で与えられるアクセス分布７３２をそのまま与える。また、別途キャッシュ効果関数を定義してもよい。なお、本ステップで割り当てたデータキャッシュ４２の量は、全体の割当量とは別に記憶する。（ステップ１４２２）
ステップ１４２２で割り当てたデータキャッシュ４２に関し、キャッシュ９４とデータキャッシュ４２の間でのデータ重複によるデータキャッシュ４２のキャッシュ効果低減分を考慮する、データキャッシュ４２の割り当ての再調整を行う。本実施の形態では、現在のキャッシュ９４の利用量に一定割合（例えば８０％）を乗じた値（以下、Ｎｔと表記）未満の領域では、データキャッシュ４２を利用してもその効果がないと判断する。まず、ステップ１４２２でデータキャッシュ４２が割り当てられなかった表を再調整の対象から外す。
【０１０１】
次に、ステップ１４２２でデータキャッシュ４２が割り当てらてたものに対してキャッシュ効果があるか確認する。調整対象の各表において、ｎｔを現時点でのデータキャッシュ４２の割当量から求めたデータページ数としたとき、確認指標としてｎｔ−Ｎｔ＜０を用い、それ満たす表が存在する場合には、その値が最も小さな表のステップ１４２２以降で割り当てたデータキャッシュ４２を全て開放し、調整対象から外す。そして、ステップ１４２２で行ったデータキャッシュ４２の割当処理を再度実行する。以下、確認指標を満たす表が存在する間この確認と再割当処理を繰り返す。この確認で、全ての表でステップ１４２２で割り当てたデータキャッシュ４２を開放することになった場合は、エラー発生として処理を終了する。なお、確認指標にキャッシュ効果より強く反映させるために、ｎｔ−Ｎｔ＜０の代わりに（ｎｔ−Ｎｔ）／Ｗｔ（Ｎｔ）＜０（Ｗｔ（ｉ）はステップ１６０４での定義を利用）を用いてもよいし、その他の確認指標を用いてもよい。
【０１０２】
更に、キャッシュ効果を高めるため、調整対象の全ての表でｎｔ−Ｎｔ＞０を満たす場合に、キャッシュ効果を考慮した割当の調整を行う。調整対象の各表においてＶｔ＝ΣＷｔ（ｉ）（ただしΣはＮｔ＜＝ｉ＜＝ｎｔの和を取ることを意味する）を計算し、その値が最も小さな表を選択する。その表に対してステップ１４２２以降で割り当てられたデータキャッシュ４２を開放した場合に、他の調整対象の表に割り当てる方法をステップ１４２２と同様にして求める。ここで、新規割当先に対応するＷｔ（ｉ）の値の和を計算し、その値がデータキャッシュ４２を開放した表におけるＶｔよりも大きな値の場合、求めたキャッシュ割当の再調整を実施するとする。以下、この確認を再調整を実施しないと判断されるまで繰り返す。（ステップ１４２３）
これまで、記憶装置４０はＬＵ２０８を外部装置に提供し、それはＩ／Ｏパス３４を経由してアクセスされるとしてきた。第一の実施の形態と同様に、記憶装置４０がファイル２０２を外部装置に提供し、そのファイル２０２がネットワークファイルシステムプロトコルを用いてネットワーク２４経由でアクセスされてもよい。この場合、第一の実施の形態と同様の対応関係がとられる。
【０１０３】
主な相違点として、記憶装置４０では、キャッシュグループのメンバの管理単位がファイル２０２単位となり、本実施の形態において実施する処理においては、ＬＵ２０８の部分が記憶装置４０上のファイル２０２に対応するようになる。
・第四の実施の形態
第四の実施の形態では、ＤＢＭＳで実施される処理の設計情報と稼動統計情報と組み合わせ、記憶装置におけるデータキャッシュ量のチューニングによりキャッシュ効果を向上させる。事前解析により得た処理のデータページ数の期待値と処理実行時の稼動統計情報を組み合わせることにより、問題と判断された処理や処理全体におけるキャッシュ量変更時の処理時間の変化を見積り、それを基に好適なキャッシュの割り当て方法を発見する。
【０１０４】
図２２は、第四の実施形態による計算機システムの構成を示す図である。第四の実施における計算機システムの構成は、基本的に第一の実施の形態とものと似ている。以下、本実施の形態について、第一の実施形態との相違点を中心にして説明する。
【０１０５】
本実施の形態においては、記憶装置４０がデータキャッシュ４２における稼動統計情報を取得する記憶装置４０ｄとなる。記憶装置４０ｄにおいて、キャッシュグループにおけるキャッシュデータ置換制御は、それぞれ独立にＬＲＵ置換アルゴリズムを用いてわれる。前記アルゴリズムによるデータ置換によりデータキャッシュ４２に存在しなくなったデータの記憶領域に関しても、データ置換後も一定量分は仮想管理領域としてＬＲＵ置換アルゴリズムの管理リスト中にその情報を記憶し、稼動状況の計測に利用する。制御プログラム４４は、データキャッシュ４２の稼動状況を計測し、管理情報４６中にキャッシュモニタ情報３６２として保持する。このとき、ＬＲＵ置換アルゴリズムのキャッシュセグメント（データキャッシュ４２の領域管理単位）管理リストを等サイズの複数領域に分割し、分割領域毎にヒット数を計測する。更に、仮想管理領域に関しても実管理領域（実際にデータに対してキャッシュセグメントが割り当てられている領域）と等サイズの領域に分割して実管理領域と同様にヒット数を計測する。また、記憶装置４０ｄは、外部からの要求に応じて、キャッシュモニタ情報３６２をネットワーク２４を介して外部に送信する機能を有する。
【０１０６】
ＤＢＭＳ９０は、メモリ１４上の領域をキャッシュ９４として利用するＤＢＭＳ９０ｄとなる。
また、ＤＢＭＳ９０ｄは、内部で利用されるソフトウェア機能や各データ構造のデータページ等の内部リソースに関して、それを利用する際に待ちが何回発生したかに関する稼動統計情報を収集し、それをＤＢＭＳ管理情報９２中にＤＢＭＳモニタ情報４１０として保持する。特に、本実施の形態においては、各データ構造毎にそのデータページを利用しようとした際に何回待ちが発生したかの累積値を保持する。
【０１０７】
サーバ７０上では、ＤＢＭＳ９０ｄの他にＡＰプログラム１００が実行される。ＡＰプログラム１００は、ユーザが行う業務のためにサーバ７０上で実行されるプログラムであり、ＤＢＭＳ９０ｄに対して処理要求を発行するものとする。ＡＰプログラム１００は、ＨＤＤ１６もしくは記憶装置４０からメモリ１４に読み出されてＣＰＵ１２により実行される。メモリ１４上に読み込まれたＡＰプログラム１００は、その管理情報であるＡＰプログラム管理情報１０２を有する。
【０１０８】
本実施の形態におけるＡＰプログラム１００は、１つ以上の処理の組として実現され、それぞれに処理ＩＤ ４３２が付加されている。ユーザはそのいずれかの処理実行を要求し、ＡＰプログラム１００はそれに応じて処理を実施する。ＡＰプログラム１００は受け付けた処理要求のキューイング制御を実施し、ＡＰプログラム１００からＤＢＭＳ９０ｄに対して処理要求を発行した場合には、ＤＢＭＳ９０ｄで即座に処理を開始できるものとする。ＡＰプログラム１００は処理に関する実行統計情報を取得し、それをオンラインＪｏｂモニタ情報４３０としてＡＰプログラム管理情報１０２中に保持する。ＡＰプログラム１００は、ＡＰプログラム管理情報１０２を外部プログラムが読むためのソフトウェアインターフェイスを有する。
【０１０９】
ＤＢＭＳ９０ｄとＡＰプログラム１００が１台のサーバ７０上で複数同時に実行されてもよい。また、ＤＢＭＳ９０ｄとＡＰプログラム１００が異なるサーバ７０上で実行されてもよく、その場合には、ＡＰプログラム１００はネットワーク２４を経由してＤＢＭＳ９０ｄに処理要求を伝達する。
管理エージェント１４４がシステム管理プログラム１４０からの指示に従って実行する処理に、ＡＰプログラム管理情報１０２中に記憶されている情報の読み出しが加わる。
システム管理プログラム１４０は、システム管理情報１４２中に保持するＤＢＭＳ情報４２０にデータ内部管理方法情報４２６を有する必要はない。その代わり、システム管理情報１４２中にＨＤＤ性能情報６１２を保持する。
【０１１０】
図２３は、キャッシュモニタ情報３６２のデータ構造を示す図である。
キャッシュモニタ情報３６２は、ＬＵ ２０８が外部装置からアクセスされた場合にどのキャッシュ領域にヒットしたかに関する稼動統計情報であり、実管理領域の分割数を示す実領域分割数５０２と、実管理領域の分割後のサイズを単位とした仮想管理領域の保持量を示す仮想管理領域数５０４を含む。また、ＬＵ ２０８毎のキャッシュヒット数の統計値として、ＬＵ ＩＤ ３６４を保持するエントリと、それに対応するリード／ライトのＩ／Ｏ種別３６６を保持するエントリ、それに対応するＩ／Ｏ処理の累積実行回数３６８を保持するエントリ、そのときにヒットした回数を示すキャッシュヒット回数累計３７０を保持するエントリの組を保持する。なお、キャッシュヒット回数累計３７０は、実管理領域でのヒット数の総累計値と、実管理領域と仮想管理領域の双方で分割された各領域でのヒット数の累計値を保持する。本実施の形態では、実管理領域と仮想管理領域を統合して分割された領域に通番を付加し、最も最近利用されたデータが存在する領域を第１領域、以下小さい通番の領域ほど最近利用されたデータを有する領域であるとする。
【０１１１】
図２４は、ＤＢＭＳモニタ情報４１０のデータ構造を示す図である。ＤＢＭＳモニタ情報４１０は、ソフトウエア機能や各データ構造等の名前であるＤＢＭＳリソース名４１２を保持するエントリと、そのリソースを利用する際に発生した待ちの回数累積値である累積待ち回数４１４を保持するエントリの組を有する。
【０１１２】
図２５は、オンラインＪｏｂ情報４３０のデータ構造を示す図である。オンラインＪｏｂ情報４３０は、ＡＰプログラム１００が取得する実行統計情報であり、処理ＩＤ ４３２を保持するエントリ、対応する処理の累積実行回数３６８を保持するエントリ、その処理をＤＢＭＳ９０ｄに対して発行した際の累積処理時間３９６（処理の待ち時間を含まない）を保持するエントリの組を有する。
【０１１３】
図２６は、ＨＤＤ性能情報６１２のデータ構造を示す図である。ＨＤＤ性能情報６１２はＨＤＤ１６のアクセス性能に関する情報であり、記憶装置４０ｄの識別子である装置ＩＤ ５７２を保持するエントリとＨＤＤ１６の識別子であるＨＤＤ ＩＤ ３９４を保持するエントリ、それに対応するＨＤＤ１６が有するアクセス性能に関する情報であるアクセス性能情報６１４を含むエントリの組を有する。アクセス性能情報６１４は、ランダムアクセス時のリードでキャッシュヒットした／しない（ミスした）場合、ライトでキャッシュヒットした／しない場合のそれぞれの平均応答時間を保持する。この情報は、記憶装置４０ｄでのＨＤＤ１６の型式を取得し、それと事前に与えられた型式毎の性能情報と組み合わせて作成する。
【０１１４】
以下、本実施の形態における、ＤＢＭＳ９０ｄで実施される処理の設計情報と各要素の稼動統計情報と組み合わせたデータキャッシュ４２のキャッシュ量チューニング処理の説明を行う。この処理は、システム管理プログラム１４０が行う。
【０１１５】
まず、システム管理プログラム１４０は、記憶装置４０ｄ、ＤＢＭＳ９０ｄ、ＡＰプログラム１００から、それぞれキャッシュモニタ情報３７０、ＤＢＭＳモニタ情報４１０、オンラインＪｏｂモニタ情報４３０（以下これらをまとめて「モニタ情報」と称す）を取得し、それを適当な形に編集した情報をシステム管理情報１４２中にモニタ履歴情報５１０として保持する。
【０１１６】
図２７は、モニタ履歴情報５１０のデータ構造を示す図である。稼動状況がモニタされている部位（キャッシュモニタ情報３６２ではアクセス先のＬＵ２０８も含む）に関して、システム内で一意に定まるモニタ部位ＩＤ ５１４が付加される。モニタ履歴情報５１０は、モニタ部位ＩＤ ５１４を保持するエントリとそのモニタ内容５１６を示す情報を保持するエントリと、対応する前回取得情報５１８を保持するエントリと、履歴情報５２０を保持するエントリの組を有する。
【０１１７】
モニタ内容５１６としては、モニタ情報のデータ構造を説明する際に説明した通りである。前回取得情報５１８は、前回モニタ情報の値を取得した日時のエントリとその取得値のエントリを有する。履歴情報５２０は、履歴として集計・記憶される値の内容を示す履歴内容５２２を保持するエントリと、ある期間のモニタ値であるサンプル５２４を保持する複数のエントリからなる。本実施の形態で利用する履歴内容５２２としては、キャッシュモニタ情報３６２からＬＵ２０８におけるリード／ライト毎の平均実行回数と平均実ヒット率と、リードの領域毎の平均ヒット率（期間内の領域でのリードヒット回数／期間内のＬＵ２０８へのリード実行回数）、ＤＢＭＳモニタ情報４１０からとして各データ構造における平均待ち発生回数、オンラインＪｏｂモニタ情報４３０からとしてＡＰプログラム１００における各処理毎の平均実行回数と平均処理時間がある。サンプル５２４は、そこに記憶されたデータがいつの期間のモニタ値かを示すエントリと、その期間における集計値である平均値と最大値をそれぞれ保持するエントリからなる。
【０１１８】
モニタ履歴情報５１０への値の設定は以下のように行う。まず、システム管理プログラム１４０は、モニタ情報を取得している記憶装置４０ｄ、ＤＢＭＳ９０ｄ、ＡＰプログラム１００からその値を一定間隔で取得する。データ取得後、対応する前回取得情報５１８のエントリ中に保存されている前回のデータ取得日時と取得値から、データの取得期間とその期間内の履歴内容５２２として指示される値を計算し、それをサンプル５２４に保存し、今回取得した値を対応する前回取得情報５１８に保存する。以下、これを繰り返す。なお、システム管理プログラム１４０は、連続した期間に対応するサンプル５２４の値をまとめたり、特に古い期間のデータを保持するサンプル５２４を削除する処理を適宜実施する。
【０１１９】
以下、システム管理プログラム１４０により行われるデータキャッシュ量チューニング処理に関して説明する。この処理は、例えば、ＡＰプログラム１００の平均応答時間が定められた値を下回った場合に実施され、基本的には、他の部位がボトルネックかどうかの確認を、別途取得している実行稼動統計情報を用いて行った後に、そのような部位が存在しない場合に実施される。
【０１２０】
図２８は、データキャッシュ量チューニングのメイン処理の処理フローである。
外部からの指示に応じてこの処理は開始される。このとき、チューニング対象に関する情報として、対象となる処理が実施されているＤＢＭＳ９０ｄのＤＢＭＳ ＩＤ ５８２と利用されるＤＢのＤＢ ＩＤ ８５４、処理の事前解析結果として期待アクセスページ数情報７８０を与える。なお、期待アクセスページ数情報７８０の代わりに処理設計情報８５０を与え、それから第二の実施形態の場合と同様の方法で期待アクセスページ数情報７８０を求めてもよい。また、期待アクセスページ数情報７８０中の期待アクセスページ数７８４は、各処理に求められるデータ整合性のレベルやデータのロック粒度から定まる、データへのロック取得方法の差を考慮して補正した値を用いても良い。（ステップ１８０１）
まず、ＤＢＭＳ９０ｄ内の各データ構造におけるデータページを利用しようとした際に、待ちが多数発生しているかを確認する。期待アクセスページ数情報７８０から処理に利用されるデータ構造を把握し、それらのデータ構造での平均待ち発生回数をモニタ履歴情報５１０中の履歴情報５２０の対応する最新の値を保持するエントリ５２４から把握し、あるデータ構造におけるその値が事前に定められている閾値以上の場合には、待ちが多数発生しているとしてステップ１８０３に進む。全てのデータ構造でその値が閾値未満の場合には、待ちが多数発生していないとしてステップ１８１１に進む。（ステップ１８０２）
ここでは、ステップ１８０２で待ちが多数発生していると判断されたデータ構造を利用する処理とそのデータ構造への期待アクセスデータページ数（総計値）を期待アクセスページ数情報７８０を参照して把握する。（ステップ１８０３）
続いて、ステップ１８０３で求めた処理の中で、処理時間が長く、かつ、待ちが多数発生しているデータ構造を多数回アクセスするものがないか確認する。処理における平均実行回数と平均処理時間をモニタ履歴情報５１０中の履歴情報５２０の対応する最新の値を保持するエントリ５２４から把握し、それらの値とステップ１８０３で求めたそのデータ構造への期待アクセスデータページ数との積をステップ１８０３で求めた処理に関して計算する。他の処理と比較したとき、常にその計算値が他の処理の値よりもある事前に定められた倍率（例えば４倍）となる処理が存在する場合に、その処理が、処理時間が長く、待ちが多数発生しているデータ構造を多数回利用する処理と判断し、ステップ１８０５に進む。そのような処理が存在しない場合にはステップ１８１１に進む。（ステップ１８０４）
ここでは、ステップ１８０４で求めた処理の処理時間が短くなるように、その処理が利用するデータのキャッシュヒット率を向上させるキャッシュ割当の変更方法を求める。ここでは、処理時間を短くしたい処理の処理ＩＤ ４３２を指定してステップ２７０１から開始される処理を実施する。（ステップ１８０５）
ここでは、各処理を全体としてみたときに処理時間の総和が小さくなるように、各処理が利用するデータのキャッシュヒット率を向上させるキャッシュ割当の変更方法を求める。ここでは、特に何も指定せずにステップ２７０１から開始される処理を実施する。（ステップ１８１１）
ステップ１８０５やステップ１８１１で求めたキャッシュ割当の変更方法に従って記憶装置４０ｄにデータキャッシュ４２の割当の変更を指示する。マッピング集約情報を参照し、処理で利用されるデータ構造のデータを保持するＬＵ２０８とそれが属するキャッシュグループを把握し、そのキャッシュグループに対して求めたキャッシュ割当の変更方法に従ってキャッシュ量の変更指示を出す。なお、あるデータ構造のデータが異なるキャッシュグループに属する複数のＬＵ２０８上に記憶される場合には、マッピング集約情報からそれぞれに記憶されているデータ量を把握し、それに比例するように割当の変更指示を出す。（ステップ１８２１）
ここで、処理を完了する。（ステップ１８２２）
図２９は、モニタ情報を基にしたデータキャッシュ４２の割当量をチューニングする処理の処理フローである。処理開始時に、特定の処理の処理時間を短くしたい場合には、その処理の処理ＩＤ ４３２が与えられる。それが与えられなかった場合には、各処理全体として処理時間を短くするとする。なお、本処理はステップ１８０１から始まる処理の一部であり、その処理が利用可能な情報は全て利用できる。（ステップ２７０１）
まず、期待アクセスページ数情報７８０とマッピング集約情報を参照し、処理が利用するデータ構造を保持する記憶装置４０ｄ、ＬＵ２０８、キャッシュグループと、そのキャッシュグループにおけるデータキャッシュ４２の割当量を各処理毎に求める。（ステップ２７０２）
続いて、キャッシュ量を変更した際のキャッシュヒット率の変化量を計算する。ここで、記憶装置４０ｄにおける実領域分割数５０２と仮想管理領域数５０４の値がそれぞれＲとＶであるとする。ＬＵ２０８が属するキャッシュグループの現在のキャッシュ量をＣとしたとき、キャッシュモニタ情報３６２中のキャッシュヒット回数累計３７０における第ｉ領域（０＜ｉ＜＝Ｒ）のヒット数は、そのＬＵ２０８が属するキャッシュグループのキャッシュ量をｉＣ／Ｒから（ｉ−１）Ｃ／Ｒに削減したときにヒットしなくなる回数、第ｉ領域（Ｒ＜ｉ＜＝Ｒ＋Ｖ）のヒット数は、キャッシュ量を（ｉ−１）Ｃ／ＲからｉＣ／Ｒに増加させたときにヒットするようになる回数と考えられる。キャッシュ量をＣからＣ／Ｒ減らしたときの平均実ヒット率の削減分が第Ｒ領域における平均ヒット率であるから、ＬＵ２０８におけるキャッシュ量が（ｉ−１）Ｃ／ＲからｉＣ／Ｒの範囲（０＜ｉ＜＝Ｒ）での単位キャッシュ量あたりの平均ヒット率削減分は（第ｉ領域での平均ヒット率）ｘＲ／Ｃとして近似可能である。同様に、キャッシュ量が（ｉ−１）Ｃ／ＲからｉＣ／Ｒの範囲（Ｒ＜ｉ＜＝Ｒ＋Ｖ）での単位キャッシュ量あたりの平均ヒット率増加分は（第ｉ領域での平均ヒット率）ｘＲ／Ｃとして近似可能である。なお、各ＬＵ２０８毎のリードアクセス実行時の第ｉ領域（０＜ｉ＜＝Ｒ＋Ｖ）での平均ヒット率はモニタ履歴情報５１０に保持されている。記憶装置４０ｄにおける実領域分割数５０２と仮想管理領域数５０４は記憶装置４０ｄのキャッシュモニタ情報３６２中に保持されているものを記憶装置４０ｄから取得することができる。
【０１２１】
この値を各処理が利用するデータ構造を保持するＬＵ２０８について全て計算し、ヒット率変化率とする。なお、以下のステップを含めてモニタ履歴情報５１０からは最も直近のサンプル５２４による値、もしくは、事前に定められた直近のある期間の平均値を取得するものとする。（ステップ２７０３）
次に、マッピング集約情報を用いて、各処理が利用するデータ構造を保持するＬＵ２０８に対応するＨＤＤ１６を把握する。そして、ＨＤＤ性能情報６１２のＨＤＤ１６のアクセス性能情報６１４を参照してＨＤＤ１６のリードヒット時の平均応答時間とリードミス時の平均応答時間を求め、（リードミス時の平均応答時間）−（リードヒット時の平均応答時間）を計算しＬＵ２０８の応答時間変化量とする。なお、ＬＵ２０８中のデータが性能の異なるＨＤＤ１６に分割されて記憶される場合には、ＨＤＤ１６毎に応答時間変化量を求め、ＨＤＤ１６に記憶されるデータ量で重み付き平均を計算した値をＬＵ２０８の応答時間変化量とする。（ステップ２７０４）
記憶装置４０ｄ毎に、
Ｉ ＝ Σ（ＬＵ処理時間変化の平均） ただし、 （ＬＵ処理時間変化の平均）＝（応答時間変化量）×（ＬＵの平均リードＩ／Ｏ回数）×（ヒット率変化量）
の値を増加させるようにキャッシュ割当の変更方法を求める。応答時間変化量はステップ２７０４で求めたものを用いる。ヒット率変化量はステップ２７０３で求めたヒット率変化率とキャッシュ割当の変更量から求めることができる。このとき、ヒット率変化率は、キャッシュグループのキャッシュ量により変化することに注意する。
【０１２２】
各処理全体の処理時間を考慮し、それを短くする（処理開始時に特定の処理ＩＤ ４３２が与えられなかった）場合、Σは、記憶装置４０ｄにおいて各処理が利用するのデータ構造を保持するＬＵ２０８に関して総和を取ることを意味する。ＬＵ２０８の平均リードＩ／Ｏ回数はモニタ履歴情報５１０から取得可能であり、取得値をそのまま用いる。
【０１２３】
処理時間を短くしたい処理の処理ＩＤ ４３２が与えられた場合には、Σは、記憶装置４０ｄにおいて指定処理が利用するデータ構造を保持するＬＵ２０８に関して総和を取ることを意味する。ＬＵ２０８の平均リードＩ／Ｏ回数は、指定処理への寄与分のみを考える。各処理によるＬＵ２０８へのリード処理回数は、処理における期待アクセスページ数情報７８０中の期待アクセスデータページ数７８４の総計値に比例しているとして指定処理に関連するリードＩ／Ｏの割合を計算し、モニタ履歴情報５１０から取得した平均リードＩ／Ｏ回数にその割合を乗じた値をＩの計算に用いる。
【０１２４】
Ｉを用いたキャッシュ割当の変更方法決定には、例えば以下のアルゴリズムを用いる。まず、各処理が利用するデータ構造を保持するＬＵ２０８が属するキャッシュグループに対して、単位キャッシュ量を増やした場合と減らした場合のＩを計算する。そして、キャッシュ量を減らした場合に最もＩが大きい（影響が小さい）キャッシュグループから最もＩの値が大きい（効果が高い）キャッシュグループへ単位量分キャッシュ割当を変更したとした場合のＩの値を計算し、それがある閾値以上のときに効果ありとしてキャッシュ割当の変更を行うとする。なお、処理時間を短くしたい処理の処理ＩＤ ４３２が与えられた場合には、上記で求めたキャッシュ割当の変更により、各処理全体の処理時間を考慮した場合のＩの値の変化も同時に確認し、その値が別の０以下のある閾値より小さい（処理全体として処理時間が悪化する）場合には、そのキャッシュ割当の変更は不可として別のキャッシュ割当変更方法を求める。
【０１２５】
以下、キャッシュ割当の変更が行われたとして上記確認を繰り返し実施し、更に割当変更を行うことに効果なしと判断されるか、もしくは、事前に定められる量（例えば、記憶装置４０ｄで利用しているキャッシュ量の一定割合）の割当変更を行った場合に、この確認の繰り返しを終了させる。（ステップ２７０５）
そして、処理を完了する。（ステップ２７０６）
これまで、記憶装置４０ｄはＬＵ２０８を外部装置に提供し、それはＩ／Ｏパス３４を経由してアクセスされるとしてきた。第一の実施の形態と同様に、記憶装置４０ｄがファイル２０２を外部装置に提供し、そのファイル２０２がネットワークファイルシステムプロトコルを用いてネットワーク２４経由でアクセスされてもよい。この場合、第一の実施の形態と同様の対応関係がとられる。
【０１２６】
主要な相違点としては、記憶装置４０ｄでは、キャッシュグループのメンバの管理単位がファイル２０２単位となり、本実施の形態における処理においては、ＬＵ２０８の部分が記憶装置４０ｄ上のファイル２０２に対応するようになる。
【０１２７】
【発明の効果】
本発明によれば、ＤＢＭＳが稼動する計算機システムにおいて、データの利用目的や処理内容から生じるデータの特性を考慮したキャッシュ量の設定を行うことができる。これにより記憶装置のデータキャッシュが一層有効に活用され、好適な性能を得ることができる。
また、記憶装置のキャッシュ量の設定やそのチューニングを自動的に行うことができ、計算機システムの性能管理コストが削減される。
【図面の簡単な説明】
【図１】第一の実施の形態による計算機システムの構成を示す。
【図２】第一の実施の形態におけるデータマッピングの階層構成の概念を示す。
【図３】領域マッピング情報３００のデータ構造を示す。
【図４】キャッシュグループ情報４６０のデータ構造を示す。
【図５】データ記憶領域情報３４２のデータ構造を示す。
【図６】属性サイズ情報３５０のデータ構造を示す。
【図７】ＤＢＭＳ情報４２０のデータ構造を示す。
【図８】処理設計情報８５０のデータ構造を示す。
【図９】ログのキャッシュ量を定める処理の処理フローを示す。
【図１０】第一の実施の形態の変形例を説明に供する計算機システムの構成を示す。
【図１１】第二の実施の形態による計算機システムの構成を示す。
【図１２】キャッシュ化要求９５４とキャッシュ化要求付ライト要求９５８を用いた際の、ＤＢＭＳ９０ｂと記憶装置４０ｂとの間のデータ制御を示す。
【図１３】キャッシュグループ情報４６０ｂのデータ構造を示す。
【図１４】表データ量情報７００のデータ構造を示す。
【図１５】Ｂ−Ｔｒｅｅ索引情報７１０のデータ構造を示す。
【図１６】キャッシュ量情報７２０のデータ構造を示す。
【図１７】表アクセス分布情報７３０のデータ構造を示す。
【図１８】期待アクセスページ数情報７８０のデータ構造を示す。
【図１９】第二の実施の形態による、ＤＢＭＳ９０ｂ及び記憶装置４０ｂにおけるキャッシュ量を設定する処理の処理フローを示す。
【図２０】キャッシュ効果関数を利用してキャッシュ量の割り当てを行う処理の処理フローを示す。
【図２１】第三の実施の形態による、ＤＢＭＳ９０ｃや記憶装置４０におけるキャッシュ量を設定する処理の処理フローを示す。
【図２２】第四の実施の形態による計算機システムの構成を示す。
【図２３】キャッシュモニタ情報３６２のデータ構造を示す。
【図２４】ＤＢＭＳモニタ情報４１０のデータ構造を示す。
【図２５】オンラインＪｏｂ情報４３０のデータ構造を示す。
【図２６】ＨＤＤ性能情報６１２のデータ構造を示す。
【図２７】モニタ履歴情報５１０のデータ構造を示す。
【図２８】データキャッシュ量チューニングのメイン処理の処理フローを示す。
【図２９】モニタ情報を基にしたデータキャッシュ４２の割当量をチューニングする処理の処理フローを示す。
【符号の説明】
１６…ＨＤＤ、 ２２…ネットワークＩ／Ｆ、
２４…ネットワーク、 ３２…Ｉ／ＯパスＩ／Ｆ、
３４…Ｉ／Ｏパス、 ４０、４０ｂ、４０ｄ…記憶装置、
６０、６０ｂ…仮想化スイッチ、 ７０…サーバ、
９０、９０ｂ、９０ｃ、９０ｄ…ＤＢＭＳ、 １００…ＡＰプログラム、
１２０…管理サーバ、 １４０…システム管理プログラム
Claims (24)
- データベース管理システムが動作する計算機と、キャッシュを備えかつ前記データベース管理システムが管理するデータベースのデータを格納する記憶装置と、該計算機及び記憶装置を管理する管理装置とが夫々ネットワークを介して接続されてなるデータ処理システムにおけるキャッシュ量設定のための装置であって、
該データベース管理システムで実行される処理の内容に関する情報を取得する手段と、
該計算機及び該記憶装置からデータのマッピングに関する情報を取得する手段と、
該取得情報を用いて前記記憶装置のキャッシュ量設定案を作成する手段と、
該記憶装置に対してキャッシュ量設定案に従ってキャッシュ量の設定を指示する手段とを有することを特徴とするキャッシュ量設定のための装置。 - 前記夫々の手段は、管理装置内に備えられるシステム管理プログラムによって実現される機能であることを特徴とする請求項１記載の装置。
- 前記計算機と前記記憶装置に接続され、両者間のデータの転送を制御する記憶制御手段と、
該記憶制御手段において該データベースのデータに対するマッピングを規定するマッピング手段と、
該マッピング手段からデータベースのデータのマッピングに関する情報を取得する手段を有することを特徴とする請求項１記載の装置。 - 前記夫々の手段は、前記計算機、前記記憶装置、又は前記記憶制御手段内で実現される機能であることを特徴とする請求項１又は３記載の装置。
- 前記管理装置は、前記データベース管理システムで実行される前記処理の内容に関する情報として、前記処理で実行されるＳＱＬ文と、前記ＳＱＬ文が実行される期待回数とを取得する手段を有することを特徴とする請求項１記載の装置。
- 前記管理装置が、前記データベース管理システムで実行される前記処理の内容に関する情報として、更に、前記処理が実行される比率を取得する手段を有することを特徴とする請求項５記載の装置。
- 前記管理装置は、前記取得情報として、更に、前記データベース管理システムの異常終了後の処理の再実行時の性能に関する情報と、前記データベース管理システムの異常終了後の処理の再実行時間設定に関する情報を取得する手段と、
前記記憶装置の前記キャッシュ量設定案として、前期データベース管理システムが出力するログに対するキャッシュ量の設定案を作成する手段とを有することを特徴とする請求項２又は６記載の装置。 - 前記管理装置は、前記データベース管理システムで実行される前記処理の内容に関する情報として、更に、前記処理が利用するデータのデータ量に関する情報と、前記処理が利用するデータへのアクセス分布に関する情報と、前記データベース管理システムと前記記憶装置で利用可能なキャッシュ量に関する情報を取得する手段と、
前記記憶装置の前記キャッシュ量設定案として、前期データベース管理システムが管理するデータである表や索引のキャッシュ量の設定案を作成する手段とを有することを特徴とする請求項２又は７記載の装置。 - 前記記憶装置は、前記キャッシュのアクセスに関する稼動統計情報を取得する手段を有すると共に、前記データベース管理システムは、該データベース管理システムが管理する表・索引を利用する際の待ち発生に関する稼動統計情報を取得する手段とを有し、
前記管理装置は、前記取得情報として、更に、前記キャッシュアクセスの稼動統計情報と前記表・索引を利用する際の待ち発生に関する稼動統計情報を取得する手段と、前記記憶装置の前記キャッシュ量設定案として、前記データベース管理システムが管理する表や索引のキャッシュ量の設定の変更案を作成する手段とを有することを特徴とする請求項１又は５記載の装置。 - 前記管理装置は、前記データベース管理システムで実行される前記処理の内容に関する情報として、前記処理における前記データベース管理システムが管理するデータである表・索引への期待データページアクセス数を取得する手段を有することを特徴とする請求項１記載の装置。
- 前記管理装置は、前記データベース管理システムで実行される前記処理の内容に関する情報として、更に、前記処理が実行される比率と、前記処理が利用するデータのデータ量に関する情報と、前記処理が利用するデータへのアクセス分布に関する情報と、前記データベース管理システムと前記記憶装置で利用可能なキャッシュ量に関する情報を取得する手段と、
前記記憶装置の前記キャッシュ量設定案として、前期データベース管理システムが管理するデータである表や索引のキャッシュ量の設定案を作成する手段と、を有することを特徴とする請求項１０記載の装置。 - 前記記憶装置は、前記キャッシュのアクセスに関する稼動統計情報を取得する手段を有すると共に、前記データベース管理システムは、該データベース管理システムが管理する前記表・索引を利用する際の待ち発生に関するの稼動統計情報を取得する手段とを有し、
前記管理装置は、前記取得情報として、更に、前記キャッシュアクセスの稼動統計情報と前記表・索引を利用する際の待ち発生に関するの稼動統計情報とを取得する手段と、前期データベース管理システムが管理する表や索引のキャッシュ量の設定を変更する案を作成する手段とを有することを特徴とする請求項１０記載の装置。 - データベース管理システムが実行される計算機と、該データベース管理システムにより管理されてデータを記憶するデータベース、及びデータベースのデータを一時的に格納するデータキャッシュを有する記憶装置とを含むデータ処理システムにおいて実行されるキャッシュの量を設定するためのプログラムであって、該データベース管理システムで実行される処理の内容に関する情報を取得する手段と、
該計算機及び該記憶装置からデータのマッピングに関する情報を取得する手段と、
取得された情報を用いて該記憶装置のキャッシュ量を設定する案を作成する手段と、
該記憶装置に対してキャッシュ量の設定案に従ってキャッシュ量の設定を指示する手段とを有することを特徴とするキャッシュ量を設定するためのプログラム。 - データを記憶するディスク装置、及び該ディスク装置に記憶されるデータの少なくとも一部を一時的に記憶するデータキャッシュを有する記憶装置と、該記憶装置に対するデータ記憶の管理を行うデータベース管理システム（ＤＢＭＳ）プログラムが実行されてデータ処理を行う計算機と、該計算機及び該記憶装置を監視、管理するためのシステム管理プログラムを備える管理用の装置とが夫々ネットワークを介して接続されるデータ処理システムにおける該データキャッシュの最適な管理方法であって、
処理設計情報を参照して、Ｒｅ−Ｒｕｎ時における処理可能な処理の最大処理件数を求めるステップと、
各処理からＩＮＳＥＲＴ／ＵＰＤＡＴＥを実行するＳＱＬ文と、ＳＱＬ文の期待回数を求めるステップと、
該ＩＮＳＥＲＴ／ＵＰＤＡＴＥを実行するＳＱＬ文から出力されるログの最大データ量を求めるステップと、
ログの最大データ量から各処理当りのログのデータ量を計算するステップと、
各処理あたりのログのデータ量と、Ｒｅ−Ｒｕｎ時に処理可能な最大処理件数に基づいて必要なログの量を見積るステップと、
Ｒｅ−Ｒｕｎ時に必要以上のログ量がデータキャッシュに存在するようにキャッシュの量を求めるステップと、
この求められたキャッシュの量に従ってキャッシュの記憶領域の割当てを行うステップと、を有することを特徴とするキャッシュの管理方法。 - ログが記憶される論理ディスク装置がフリーのキャッシュグループに属する場合、該フリーのキャッシュグループを定義し、そのキャッシュグループにＲｅ−Ｒｕｎ時に必要となるログ量を割り当てるステップと有する請求項１４記載のキャッシュの管理方法。
- 夫々ネットワークに接続された、データを記憶するディスク装置及び該ディスク装置に記憶されるデータの少なくとも一部を一時的に記憶するデータキャッシュを有する記憶装置と、キャッシュを有すると共に該記憶装置に対するデータ記憶の管理を行うデータベース管理システム（ＤＢＭＳ）プログラムが実行される計算機と、該計算機及び該記憶装置を監視、管理するためのシステム管理プログラムを備える管理用の装置とを有するデータ処理システムにおける該データキャッシュの最適な管理方法であって、
各データ構造に対して、該ＤＢＭＳのキャッシュと該記憶装置のデータキャッシュの一定量をそれぞれ割り当てるステップと、
各データ構造にキャッシュ効果関数を指定し、それを用いて各データ構造に対して該ＤＢＭＳのキャッシュの量を割り当てるステップと、
各データ構造にキャッシュ効果関数を指定し、それを用いて各データ構造に対してデータキャッシュの量を割り当てるステップと。
該ＤＢＭＳ及び又は記憶装置に対して、求めたキャッシュ量の割り当てを指示するステップと、を有することを特徴とするキャッシュの管理方法。 - 各データ構造に対して、リーフノード以外のデータを記憶するデータページの量を把握し、その量と関連させて該ＤＢＭＳのキャッシュの利用量を割り当てるステップと、
各データ構造に対して、リーフノードを格納するデータぺージの量を基に、その量の該記憶装置におけるデータキャッシュと一定比率分のＤＢＭＳのキャッシュを割当てるステップと、を更に有する請求項１６記載のキャッシュの管理方法。 - 前記データ処理システムにおいて、
前記ディスク装置を複数の論理ディスク装置として仮想化するステップと、
該論理ディスク装置を単位として該データキャッシュの記憶領域のグルーピングを行うステップと、
ログが記憶される論理ディスク装置、及び該論理ディスク装置が存在するキャッシュグループをマッピング情報から求めるステップと、
求められたキャッシュグループと該グループに対応する記憶領域のキャッシュ量の設定を記憶装置に対して指示するステップと、を有することを特徴とする請求項１４又は１６記載のキャッシュの管理方法。 - データ構造として表、索引データを用いることを特徴とする請求項１６記載のキャッシュの管理方法。
- 該ＤＢＭＳは、ＤＢＭＳのキャッシュと該記憶装置のデータキャッシュを１つのキャッシュと見なして管理することを特徴とする請求項１６記載のキャッシュの管理方法。
- 該ＤＢＭＳから該記憶装置に対して該記憶装置内に格納されているデータを該データキャッシュに保持することを求めるキャッシュ化要求を発するステップと、
該ＤＢＭＳ内のキャッシュに書き込まれたデータを該記憶装置内のデータキャッシュに保持することを求めるキャッシュ化要求付ライト要求を発するステップとを有することを特徴とする請求項２０記載のキャッシュの管理方法。 - 夫々ネットワークに接続された、データを記憶するディスク装置及び該ディスク装置に記憶されるデータの少なくとも一部を一時的に記憶するデータキャッシュを有する記憶装置と、該記憶装置に対するデータ記憶の管理を行うデータベース管理システム（ＤＢＭＳ）プログラムが実行される計算機と、該計算機及び該記憶装置を監視、管理するためのシステム管理プログラムを備える管理用の装置とを有するデータ処理システムにおける該データキャッシュの最適な管理方法であって、
ＤＢＭＳ内の各データ構造におけるデータページを利用待ちの発生状況を確認するステップと、
待ちが多く発生していると判断されたデータ構造を利用する処理と、そのデータ構造への期待アクセスデータページ数を把握するステップと、
データ構造を利用する処理の中で、処理時間が長く、待ちが多く発生しているデータ構造を多数回アクセスするものがないか確認するステップと、
処理時間が短くなるように、その処理が利用するデータのキャッシュヒット率を向上させるキャッシュ割当の変更を求めるステップと、
キャッシュ割当の変更に従って該記憶装置にデータキャッシュの割当の変更を指示するステップと、を有することを特徴とするキャッシュの管理方法。 - 各処理を全体としてみたときに処理時間の総和が小さくなるように、各処理が利用するデータのキャッシュヒット率を向上させるようにキャッシュ割当の変更を求めるステップを更に有することを特徴とする請求項２２記載のキャッシュの管理方法。
- 前記取得手段は、該計算機が有する前記データベース管理システム、ファイルシステム及びボリュームマネージャからのデータマッピング情報を取得することを特徴とする請求項１記載の装置。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003090360A JP4313068B2 (ja) | 2003-03-28 | 2003-03-28 | 記憶装置のキャッシュ管理方法 |
| US10/646,699 US6944711B2 (en) | 2003-03-28 | 2003-08-25 | Cache management method for storage device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003090360A JP4313068B2 (ja) | 2003-03-28 | 2003-03-28 | 記憶装置のキャッシュ管理方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004295790A true JP2004295790A (ja) | 2004-10-21 |
| JP4313068B2 JP4313068B2 (ja) | 2009-08-12 |
Family
ID=32985279
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003090360A Expired - Fee Related JP4313068B2 (ja) | 2003-03-28 | 2003-03-28 | 記憶装置のキャッシュ管理方法 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6944711B2 (ja) |
| JP (1) | JP4313068B2 (ja) |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006227688A (ja) * | 2005-02-15 | 2006-08-31 | Hitachi Ltd | ストレージシステム |
| JP2007026064A (ja) * | 2005-07-15 | 2007-02-01 | Hitachi Ltd | 計算機システム、管理計算機及びデータベース管理システムの制御方法 |
| JP2007140635A (ja) * | 2005-11-15 | 2007-06-07 | Hitachi Ltd | 記憶システム及びアンドゥ処理方法 |
| US7693816B2 (en) | 2004-11-01 | 2010-04-06 | Hitachi, Ltd. | Computer system, computer, data access method and database system |
| JP5450803B2 (ja) * | 2010-04-22 | 2014-03-26 | 株式会社日立製作所 | データ処理方法、データ処理装置及びデータ処理プログラム |
| US9594785B2 (en) | 2010-12-16 | 2017-03-14 | Nec Corporation | Database management device and database management method |
| WO2017141408A1 (ja) * | 2016-02-18 | 2017-08-24 | 株式会社日立製作所 | 方法、媒体及び計算機システム |
Families Citing this family (76)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7188145B2 (en) * | 2001-01-12 | 2007-03-06 | Epicrealm Licensing Llc | Method and system for dynamic distributed data caching |
| US7035911B2 (en) | 2001-01-12 | 2006-04-25 | Epicrealm, Licensing Llc | Method and system for community data caching |
| US20040230753A1 (en) * | 2003-05-16 | 2004-11-18 | International Business Machines Corporation | Methods and apparatus for providing service differentiation in a shared storage environment |
| JP4437650B2 (ja) * | 2003-08-25 | 2010-03-24 | 株式会社日立製作所 | ストレージシステム |
| JP4258332B2 (ja) * | 2003-09-30 | 2009-04-30 | ティアック株式会社 | 光ディスク装置 |
| JP4257783B2 (ja) | 2003-10-23 | 2009-04-22 | 株式会社日立製作所 | 論理分割可能な記憶装置及び記憶装置システム |
| JP4117656B2 (ja) * | 2003-11-26 | 2008-07-16 | 株式会社日立製作所 | アクセスパターンを学習する記憶装置 |
| JP4435588B2 (ja) * | 2004-01-30 | 2010-03-17 | 株式会社日立製作所 | ストレージシステム |
| JP4141391B2 (ja) * | 2004-02-05 | 2008-08-27 | 株式会社日立製作所 | ストレージサブシステム |
| US7346620B2 (en) * | 2004-02-12 | 2008-03-18 | International Business Machines Corporation | Adjusting log size in a static logical volume |
| JP2005267008A (ja) | 2004-03-17 | 2005-09-29 | Hitachi Ltd | ストレージ管理方法およびストレージ管理システム |
| JP4147198B2 (ja) * | 2004-03-23 | 2008-09-10 | 株式会社日立製作所 | ストレージシステム |
| JP4631301B2 (ja) * | 2004-03-31 | 2011-02-16 | 株式会社日立製作所 | 記憶装置のキャッシュ管理方法 |
| US8612208B2 (en) | 2004-04-07 | 2013-12-17 | Oracle Otc Subsidiary Llc | Ontology for use with a system, method, and computer readable medium for retrieving information and response to a query |
| US7747601B2 (en) | 2006-08-14 | 2010-06-29 | Inquira, Inc. | Method and apparatus for identifying and classifying query intent |
| US8082264B2 (en) * | 2004-04-07 | 2011-12-20 | Inquira, Inc. | Automated scheme for identifying user intent in real-time |
| US7590803B2 (en) * | 2004-09-23 | 2009-09-15 | Sap Ag | Cache eviction |
| US7418560B2 (en) | 2004-09-23 | 2008-08-26 | Sap Ag | Centralized cache storage for runtime systems |
| US20060112155A1 (en) * | 2004-11-24 | 2006-05-25 | Agami Systems, Inc. | System and method for managing quality of service for a storage system |
| US20060143398A1 (en) * | 2004-12-23 | 2006-06-29 | Stefan Rau | Method and apparatus for least recently used (LRU) software cache |
| US7512737B2 (en) * | 2004-12-28 | 2009-03-31 | Sap Ag | Size based eviction implementation |
| US7694065B2 (en) | 2004-12-28 | 2010-04-06 | Sap Ag | Distributed cache architecture |
| US7971001B2 (en) | 2004-12-28 | 2011-06-28 | Sap Ag | Least recently used eviction implementation |
| US7451275B2 (en) * | 2004-12-28 | 2008-11-11 | Sap Ag | Programming models for storage plug-ins |
| US7523263B2 (en) * | 2004-12-28 | 2009-04-21 | Michael Wintergerst | Storage plug-in based on shared closures |
| US20060143256A1 (en) | 2004-12-28 | 2006-06-29 | Galin Galchev | Cache region concept |
| US7552284B2 (en) * | 2004-12-28 | 2009-06-23 | Sap Ag | Least frequently used eviction implementation |
| US8204931B2 (en) | 2004-12-28 | 2012-06-19 | Sap Ag | Session management within a multi-tiered enterprise network |
| JP2006185335A (ja) * | 2004-12-28 | 2006-07-13 | Toshiba Corp | 情報処理装置及びこの情報処理装置の制御方法 |
| US7437516B2 (en) * | 2004-12-28 | 2008-10-14 | Sap Ag | Programming models for eviction policies |
| US7539821B2 (en) | 2004-12-28 | 2009-05-26 | Sap Ag | First in first out eviction implementation |
| US7831634B2 (en) * | 2005-04-29 | 2010-11-09 | Sap Ag | Initializing a cache region using a generated cache region configuration structure |
| US7581066B2 (en) * | 2005-04-29 | 2009-08-25 | Sap Ag | Cache isolation model |
| US7966412B2 (en) | 2005-07-19 | 2011-06-21 | Sap Ag | System and method for a pluggable protocol handler |
| US20070022148A1 (en) * | 2005-07-20 | 2007-01-25 | Akers David G | Reserving an area of a storage medium for a file |
| US8346740B2 (en) | 2005-07-22 | 2013-01-01 | Hewlett-Packard Development Company, L.P. | File cache management system |
| US7809882B1 (en) | 2006-01-24 | 2010-10-05 | Verizon Services Corp. | Session independent backend data cache system |
| US7693883B2 (en) * | 2006-01-30 | 2010-04-06 | Sap Ag | Online data volume deletion |
| US8117153B2 (en) * | 2006-03-28 | 2012-02-14 | Oracle America, Inc. | Systems and methods for a distributed cache |
| US7921099B2 (en) * | 2006-05-10 | 2011-04-05 | Inquira, Inc. | Guided navigation system |
| US8781813B2 (en) | 2006-08-14 | 2014-07-15 | Oracle Otc Subsidiary Llc | Intent management tool for identifying concepts associated with a plurality of users' queries |
| US7788243B2 (en) * | 2006-09-08 | 2010-08-31 | Sybase, Inc. | System and methods for optimizing data transfer among various resources in a distributed environment |
| US20080077638A1 (en) * | 2006-09-21 | 2008-03-27 | Microsoft Corporation | Distributed storage in a computing environment |
| US8095476B2 (en) * | 2006-11-27 | 2012-01-10 | Inquira, Inc. | Automated support scheme for electronic forms |
| US7831772B2 (en) * | 2006-12-12 | 2010-11-09 | Sybase, Inc. | System and methodology providing multiple heterogeneous buffer caches |
| US8055645B1 (en) * | 2006-12-15 | 2011-11-08 | Packeteer, Inc. | Hierarchical index for enhanced storage of file changes |
| US7599969B2 (en) * | 2006-12-20 | 2009-10-06 | International Business Machines Corporation | Method and system for scheduling workload in databases |
| US7996609B2 (en) * | 2006-12-20 | 2011-08-09 | International Business Machines Corporation | System and method of dynamic allocation of non-volatile memory |
| JP2008181243A (ja) * | 2007-01-23 | 2008-08-07 | Hitachi Ltd | ストレージシステムのキャッシュパーティション領域の設定を制御するデータベース管理システム |
| US8015367B1 (en) * | 2007-02-16 | 2011-09-06 | Vmware, Inc. | Memory management methods in a computer system with shared memory mappings |
| US7921085B2 (en) * | 2007-03-26 | 2011-04-05 | International Business Machines Corporation | Method and system for quantifying a data page repetition pattern for a database index in a database management system |
| US7882285B2 (en) * | 2007-12-18 | 2011-02-01 | International Business Machines Corporation | Buffer cache management to prevent deadlocks |
| JP5408600B2 (ja) | 2008-05-28 | 2014-02-05 | インターナショナル・ビジネス・マシーンズ・コーポレーション | 決定装置、データベース装置、プログラムおよび決定方法 |
| US8108587B2 (en) * | 2009-05-26 | 2012-01-31 | Microsoft Corporation | Free-space reduction in cached database pages |
| US8990166B2 (en) * | 2011-03-25 | 2015-03-24 | Sap Se | Variable page sizing for improved physical clustering |
| WO2014141419A1 (ja) * | 2013-03-14 | 2014-09-18 | 株式会社日立製作所 | 仮想計算機システムおよびスケジューリング方法 |
| US9396128B2 (en) * | 2013-06-13 | 2016-07-19 | Samsung Electronics Co., Ltd. | System and method for dynamic allocation of unified cache to one or more logical units |
| KR102149468B1 (ko) * | 2013-06-13 | 2020-08-28 | 삼성전자 주식회사 | 통합 캐시를 하나 또는 복수의 논리 유닛에 동적 할당하는 시스템 및 방법 |
| US9235517B2 (en) * | 2013-08-12 | 2016-01-12 | Globalfoundries Inc. | Implementing dynamic cache enabling and disabling based upon workload |
| IN2013MU04016A (ja) | 2013-12-23 | 2015-08-07 | Tata Consultancy Services Ltd | |
| US9208086B1 (en) * | 2014-01-09 | 2015-12-08 | Pure Storage, Inc. | Using frequency domain to prioritize storage of metadata in a cache |
| US9842152B2 (en) | 2014-02-19 | 2017-12-12 | Snowflake Computing, Inc. | Transparent discovery of semi-structured data schema |
| US9646012B1 (en) * | 2014-03-06 | 2017-05-09 | Veritas Technologies Llc | Caching temporary data in solid state storage devices |
| CN104281517B (zh) * | 2014-10-16 | 2017-05-17 | 浙江宇视科技有限公司 | 一种基于日志方式的存储空间管理方法和装置 |
| US9824030B2 (en) | 2015-10-30 | 2017-11-21 | International Business Machines Corporation | Adjusting active cache size based on cache usage |
| US9811474B2 (en) | 2015-10-30 | 2017-11-07 | International Business Machines Corporation | Determining cache performance using a ghost cache list indicating tracks demoted from a cache list of tracks in a cache |
| KR102456109B1 (ko) | 2015-12-03 | 2022-10-18 | 삼성전자주식회사 | 비휘발성 메인 메모리 시스템의 메모리 맵핑 관리 방법 |
| KR101887741B1 (ko) * | 2016-04-11 | 2018-09-11 | 전자부품연구원 | 적응적 블록 캐시 운용 방법 및 이를 적용한 dbms |
| CN106055640A (zh) * | 2016-05-31 | 2016-10-26 | 乐视控股（北京）有限公司 | 缓存的管理方法及系统 |
| US10437822B2 (en) * | 2017-03-06 | 2019-10-08 | Sap Se | Grouping tables in a distributed database |
| US10540295B2 (en) | 2017-06-21 | 2020-01-21 | International Business Machines Corporation | Processing cache miss rates to determine memory space to add to an active cache to reduce a cache miss rate for the active cache |
| KR20190085359A (ko) * | 2018-01-10 | 2019-07-18 | 에스케이하이닉스 주식회사 | 데이터 저장 장치 및 그것의 동작 방법 |
| CN110300134B (zh) * | 2018-03-22 | 2022-10-04 | 杭州海康威视系统技术有限公司 | 云存储资源池的存储空间调整方法、装置及云存储系统 |
| US11372761B1 (en) * | 2020-12-11 | 2022-06-28 | International Business Machines Corporation | Dynamically adjusting partitioned SCM cache memory to maximize performance |
| US11755251B2 (en) * | 2021-06-02 | 2023-09-12 | Samsung Electronics Co., Ltd. | Virtual computational storage devices |
| CN114296635B (zh) * | 2021-12-03 | 2023-11-03 | 北京易捷思达科技发展有限公司 | 缓存数据的缓存淘汰方法、装置、终端及存储介质 |
Family Cites Families (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4463424A (en) * | 1981-02-19 | 1984-07-31 | International Business Machines Corporation | Method for dynamically allocating LRU/MRU managed memory among concurrent sequential processes |
| US4947319A (en) | 1988-09-15 | 1990-08-07 | International Business Machines Corporation | Arbitral dynamic cache using processor storage |
| EP0389151A3 (en) | 1989-03-22 | 1992-06-03 | International Business Machines Corporation | System and method for partitioned cache memory management |
| US5434992A (en) | 1992-09-04 | 1995-07-18 | International Business Machines Corporation | Method and means for dynamically partitioning cache into a global and data type subcache hierarchy from a real time reference trace |
| US5918225A (en) * | 1993-04-16 | 1999-06-29 | Sybase, Inc. | SQL-based database system with improved indexing methodology |
| US5537635A (en) | 1994-04-04 | 1996-07-16 | International Business Machines Corporation | Method and system for assignment of reclaim vectors in a partitioned cache with a virtual minimum partition size |
| US5675797A (en) | 1994-05-24 | 1997-10-07 | International Business Machines Corporation | Goal-oriented resource allocation manager and performance index technique for servers |
| US5680573A (en) | 1994-07-12 | 1997-10-21 | Sybase, Inc. | Method of buffering data objects in a database |
| US5566315A (en) | 1994-12-30 | 1996-10-15 | Storage Technology Corporation | Process of predicting and controlling the use of cache memory in a computer system |
| US6119118A (en) * | 1996-05-10 | 2000-09-12 | Apple Computer, Inc. | Method and system for extending file system metadata |
| US6021408A (en) * | 1996-09-12 | 2000-02-01 | Veritas Software Corp. | Methods for operating a log device |
| US5918249A (en) * | 1996-12-19 | 1999-06-29 | Ncr Corporation | Promoting local memory accessing and data migration in non-uniform memory access system architectures |
| US5852818A (en) * | 1996-12-23 | 1998-12-22 | Oracle Corporation | Non-recursive method for parameter evaluation within an information management system |
| US5897634A (en) * | 1997-05-09 | 1999-04-27 | International Business Machines Corporation | Optimized caching of SQL data in an object server system |
| US6035306A (en) * | 1997-11-24 | 2000-03-07 | Terascape Software Inc. | Method for improving performance of large databases |
| US6370619B1 (en) | 1998-06-22 | 2002-04-09 | Oracle Corporation | Managing partitioned cache |
| US6421761B1 (en) | 1999-11-09 | 2002-07-16 | International Business Machines Corporation | Partitioned cache and management method for selectively caching data by type |
| US6493810B1 (en) * | 2000-04-28 | 2002-12-10 | Microsoft Corporation | Method and system for allocating cache memory for a network database service |
| JP4162183B2 (ja) | 2001-11-12 | 2008-10-08 | 株式会社日立製作所 | データベース管理システムの静的な情報を取得する手段を有する記憶装置 |
| JP4162184B2 (ja) | 2001-11-14 | 2008-10-08 | 株式会社日立製作所 | データベース管理システムの実行情報を取得する手段を有する記憶装置 |
-
2003
- 2003-03-28 JP JP2003090360A patent/JP4313068B2/ja not_active Expired - Fee Related
- 2003-08-25 US US10/646,699 patent/US6944711B2/en not_active Expired - Fee Related
Cited By (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7693816B2 (en) | 2004-11-01 | 2010-04-06 | Hitachi, Ltd. | Computer system, computer, data access method and database system |
| JP2006227688A (ja) * | 2005-02-15 | 2006-08-31 | Hitachi Ltd | ストレージシステム |
| US8612716B2 (en) | 2005-02-15 | 2013-12-17 | Hitachi, Ltd. | Storage system having partition size set in accordance with drive type |
| US8832380B2 (en) | 2005-02-15 | 2014-09-09 | Hitachi, Ltd. | Storage system having cache partition size set based on drive type |
| JP2007026064A (ja) * | 2005-07-15 | 2007-02-01 | Hitachi Ltd | 計算機システム、管理計算機及びデータベース管理システムの制御方法 |
| US7395371B2 (en) | 2005-07-15 | 2008-07-01 | Hitachi, Ltd. | Method of controlling a database management system by changing allocation of cache memory |
| JP2007140635A (ja) * | 2005-11-15 | 2007-06-07 | Hitachi Ltd | 記憶システム及びアンドゥ処理方法 |
| JP4700478B2 (ja) * | 2005-11-15 | 2011-06-15 | 株式会社日立製作所 | 記憶システム及びアンドゥ処理方法 |
| JP5450803B2 (ja) * | 2010-04-22 | 2014-03-26 | 株式会社日立製作所 | データ処理方法、データ処理装置及びデータ処理プログラム |
| US9594785B2 (en) | 2010-12-16 | 2017-03-14 | Nec Corporation | Database management device and database management method |
| WO2017141408A1 (ja) * | 2016-02-18 | 2017-08-24 | 株式会社日立製作所 | 方法、媒体及び計算機システム |
Also Published As
| Publication number | Publication date |
|---|---|
| JP4313068B2 (ja) | 2009-08-12 |
| US6944711B2 (en) | 2005-09-13 |
| US20040193803A1 (en) | 2004-09-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4313068B2 (ja) | 記憶装置のキャッシュ管理方法 | |
| US7689573B2 (en) | Prefetch appliance server | |
| JP4631301B2 (ja) | 記憶装置のキャッシュ管理方法 | |
| US7694070B2 (en) | Computer system for managing performances of storage apparatus and performance management method of the computer system | |
| US6928451B2 (en) | Storage system having means for acquiring execution information of database management system | |
| JP4288978B2 (ja) | データ先読み方法 | |
| JP2008181243A (ja) | ストレージシステムのキャッシュパーティション領域の設定を制御するデータベース管理システム | |
| JP2002082775A (ja) | 計算機システム | |
| WO2022063059A1 (zh) | 键值存储系统的数据管理方法及其装置 | |
| US11816029B2 (en) | Adjustment of garbage collection parameters in a storage system | |
| US11409454B1 (en) | Container ownership protocol for independent node flushing | |
| US7882086B1 (en) | Method and system for portset data management | |
| US11921695B2 (en) | Techniques for recording metadata changes | |
| JP5261809B2 (ja) | 計算機システム及びデータベース管理システムプログラム | |
| WO2015029188A1 (ja) | 計算機及びデータ読み出し方法 | |
| JP5098120B2 (ja) | 計算機システム及びデータベース管理システムプログラム | |
| CN112214460A (zh) | 基于分布式大容量分片高性能的存储控制方法 | |
| US11709839B2 (en) | Database system and query execution method | |
| US20230325324A1 (en) | Caching techniques | |
| US11853574B1 (en) | Container flush ownership assignment | |
| US20240111429A1 (en) | Techniques for collecting and utilizing activity metrics |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050808 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20050808 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20081021 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20081222 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090127 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090327 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090421 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090514 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120522 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120522 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130522 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130522 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |