JP2008181243A - ストレージシステムのキャッシュパーティション領域の設定を制御するデータベース管理システム - Google Patents

Abstract

【課題】ストレージキャッシュ分割技術とＤＢバッファ技術の両方が採用されたコンピュータシステムにおいてストレージキャッシュの利用効率の低下を抑える。
【解決手段】データベース管理システムに、設定処理部と、指示送信部とを備える。設定処理部は、各データベースバッファに関するサイズを基に、該各データベースバッファに対応付ける各キャッシュパーティション領域に関するサイズを決定する。そして、設定処理部は、パーティション設定指示、具体的には、上記決定したサイズで該各キャッシュパーティション領域に関する設定を行うことの指示を作成する。指示送信部は、作成されたパーティション設定指示を送信する。
【選択図】図２

Description

本発明は、ストレージシステムのキャッシュメモリの論理分割に関する。

ストレージシステムは、一般に、複数の記憶装置を備え、ホストコンピュータから送信されたアクセスコマンド（ライトコマンド或いはリードコマンド）に従って、それら複数の記憶装置のうちの少なくとも一つに対してデータのアクセスを行う。この種のストレージシステムは、通常、そのデータを一時的に記憶するためのキャッシュメモリを備える。キャッシュメモリの管理に関する技術として、例えば、以下の特許文献１〜５に開示の技術がある。

特開２００４−０３００９０号公報 特開２００４−２９５７９０号公報 特開２００５−２８５０５８号公報 米国特許５４３４９９２号公報 特開２００６−２２７６８８号公報

ところで、ストレージシステム及びホストコンピュータを備えたコンピュータシステムとして、例えば、ストレージシステムがデータベース（以下、ＤＢ）を記憶し、該ＤＢを管理するシステム（以下、ＤＢＭＳ）がホストコンピュータ上で稼動するシステムがある。このコンピュータシステムでは、ＤＢに対するＤＢＭＳによるアクセスの性能（例えば速度）が高いことが望ましい。

ＤＢに対するアクセスの性能を向上するための方法として、例えば、ストレージシステムのキャッシュメモリ（以下、ストレージキャッシュ）を論理的に分割する技術を採用することが考えられる。この技術によれば、ストレージキャッシュへのアクセス干渉（競合）を抑えることができる。この種の技術は、例えば、上述した特許文献１乃至５のうちの例えば特許文献５に開示されている。以下、この種の技術を、「ストレージキャッシュ分割技術」と呼ぶ。また、論理的な分割により得られた各領域を「キャッシュパーティション領域」と呼ぶ。キャッシュパーティション領域は、同サイズのサブ領域の集合で構成される。以下、そのサブ領域を「セグメント」と呼ぶ。セグメントは、ストレージキャッシュに対する一アクセスのデータサイズ単位（アクセス単位）である。ストレージキャッシュ分割技術では、各キャッシュパーティション領域毎に、セグメントのサイズを違えることができる。

また、別の方法として、例えば、ＤＢＭＳが、主に、ホストコンピュータ内のＤＢバッファにアクセスし、必要がある場合に、ストレージシステム内のＤＢにアクセスするためのアクセスコマンドをストレージシステムに発行する技術を採用する方法も考えられる。ここで、ＤＢバッファとは、ＤＢＭＳによるアクセスの対象となるデータ（ＤＢに書込まれるデータ、或いは、ＤＢから読み出されるデータ）を記憶するための記憶領域であって、ホストコンピュータ内のメモリに設定された領域である。この技術によれば、ストレージシステムにアクセスコマンドを発行する回数を抑えることができる。以下、この技術を、「ＤＢバッファ技術」と呼ぶ。ＤＢＭＳは、表やインデクスなどの複数のオブジェクト（ＤＢオブジェクト）にそれぞれ対応した複数の論理的な記憶領域（以下、ＤＢ領域）を管理することができる。ＤＢバッファ技術では、それら複数のＤＢ領域のそれぞれに対応する複数のＤＢバッファを設定することができる。ＤＢバッファは、同サイズのサブ領域の集合で構成される。以下、そのサブ領域を「ページ」と呼ぶ。ページは、ＤＢバッファに対する一アクセスのデータサイズ単位（アクセス単位）である。ＤＢバッファ技術では、各ＤＢバッファ毎に、ページのサイズを違えることができる。

ＤＢに対するアクセスの性能をなるべく向上させるためには、ストレージキャッシュ分割技術及びＤＢバッファ技術のいずれか一方ではなく両方を採用することが望ましいと考えられる。なぜなら、ＤＢバッファ技術により、ストレージシステムにアクセスコマンドを発行する回数を抑えることができるし、ストレージシステムにアクセスコマンドが発行されても、ストレージキャッシュへのアクセス干渉を抑えることができるからである。

しかし、それらの技術の両方を単純に採用したのでは、ストレージキャッシュの利用効率の問題が生じると考えられる。なぜなら、ストレージキャッシュ分割技術では、各ストレージキャッシュパーティション領域毎に、セグメントのサイズを違えることができ、一方、ＤＢバッファ技術でも、各ＤＢバッファ毎に、ページのサイズを違えることができ、セグメントとページの各々が独立しているからである。

従って、本発明の目的は、ストレージキャッシュ分割技術とＤＢバッファ技術の両方が採用されたコンピュータシステムにおいてストレージキャッシュの利用効率の低下を抑えることにある。

データベース管理システムに、設定処理部と、指示送信部とを備える。設定処理部は、各データベースバッファに関するサイズを基に、該各データベースバッファに対応付ける各キャッシュパーティション領域に関するサイズを決定する。そして、設定処理部は、パーティション設定指示、具体的には、上記決定したサイズで該各キャッシュパーティション領域に関する設定を行うことの指示を作成する。指示送信部は、作成されたパーティション設定指示を送信する。パーティション設定指示が最終的にストレージシステムで受信できれば、パーティション設定指示は、ストレージシステムに直接送信されても良いし、管理コンピュータなどの他のコンピュータを経由してストレージシステムに送信されても良い。

上述した各部は、ハードウェア（例えば回路）、コンピュータプログラム、或いはそれらの組み合わせ（例えば、コンピュータプログラムを読み込んで実行する一又は複数のＣＰＵ）によって実現することもできる。各コンピュータプログラムは、コンピュータマシンに備えられる記憶資源（例えばメモリ）から読み込むことができる。その記憶資源には、ＣＤ−ＲＯＭやＤＶＤ（Digital Versatile Disk）等の記録媒体を介してインストールすることもできるし、インターネットやＬＡＮ等の通信ネットワークを介してダウンロードすることもできる。

本発明によれば、ストレージキャッシュ分割技術とＤＢバッファ技術の両方が採用されたコンピュータシステムにおいてストレージキャッシュの利用効率の低下を抑えることができる。

本発明の一つの実施の形態の概念を説明する。

データベース管理システム（ＤＢＭＳ）に、ＤＢ設定処理部と、ストレージキャッシュ調整処理部とを備える。ＤＢ設定処理部は、各データベースバッファ（ＤＢバッファ）に関するサイズを基に、該各ＤＢに対応付ける各キャッシュパーティション領域に関するサイズを決定することができる。そして、ＤＢ設定処理部は、パーティション設定指示、具体的には、上記決定したサイズで該各キャッシュパーティション領域に関する設定を行うことの指示を作成する。ＤＢ設定処理部は、ストレージキャッシュ調整処理部を呼び出すことにより、作成されたパーティション設定指示を送信することができる。

各ＤＢバッファに関するサイズとは、該各ＤＢバッファについて、ページのサイズとすることができるし、更に、ＤＢバッファそれ自体のサイズであるバッファサイズとすることもできる。一方、各キャッシュパーティション領域に関するサイズとは、該各キャッシュパーティション領域について、セグメントのサイズとすることもできるし、キャッシュパーティション領域それ自体のサイズであるパーティションサイズとすることもできる。

ＤＢ設定処理部は、各キャッシュパーティション領域のセグメントサイズを、該各キャッシュパーティション領域に対応付けられる各データベースバッファのページサイズと同じサイズとすることができる。また、後述するＤＢ初期設定フェーズにおいては、各キャッシュパーティション領域のパーティションサイズを、該各キャッシュパーティション領域に対応付けられる各データベースバッファのバッファサイズと同じサイズにすることもできる。

ＤＢＭＳで管理される複数のデータベース領域（ＤＢ領域）に、複数のＤＢバッファがそれぞれ対応付けられる。また、複数のＤＢ領域には、ストレージシステム内の複数の記憶装置をそれぞれ対応付けられる。ここで言う記憶装置は、論理的な記憶装置（例えば後述の論理ユニット）であっても良いし、物理的な記憶装置（例えば後述のディスク装置）であっても良い。

ＤＢＭＳが、各ＤＢ領域へのアクセスを実行するアクセス制御部を更に備える。該アクセス制御部は、或るＤＢ領域へのアクセスを実行する場合、該或るＤＢ領域に対応したＤＢバッファである当該ＤＢバッファでバッファヒットした場合には、バッファヒットで確保された領域にアクセスすることができる。バッファヒットしなった場合に、当該ＤＢバッファに対応付けられたキャッシュパーティション領域に割当てられている記憶装置を指定したアクセスコマンドがホストコンピュータからストレージシステムに送信される。この場合、ストレージシステムが、該アクセスコマンドに従うデータを、該アクセスコマンドで指定されている記憶装置が割当てられたキャッシュパーティション領域の、キャッシュヒットにより確保された領域に一時格納することができる。

上述したアクセス制御部は、各ＤＢバッファについて、ＤＢバッファへのアクセス回数のうちのバッファヒットした回数を表すバッファヒット率を算出することができる。ＤＢ設定処理部は、各ＤＢバッファのバッファヒット率に基づいて、パーティション設定指示として、複数のキャッシュパーティション領域のうちの少なくとも一つに関するサイズの設定変更を意味する指示を作成することができる。具体的には、例えば、バッファヒット率が所定閾値以上のデータベースバッファに対応付けられたキャッシュパーティション領域の全部又は一部を前記キャッシュメモリから削除することの意味である削除意味を含んだ指示を作成することができる。また、削除される領域サイズ分の領域を複数のキャッシュパーティション領域のうちの他のキャッシュパーティション領域に追加することの意味である追加意味を含んだ指示を作成することができる。削除意味と追加意味は、一つのパーティション設定指示に含まれても良いし、複数のパーティション設定指示に分けられても良い。

前述した設定変更の意味、その意味の具体例である削除意味及び追加意味のうちの少なくとも一つとは、その意味することが実行されるようになっていれば、どのような態様であっても良い。例えば、どのキャッシュパーティション領域を削除するかや、どのキャッシュパーティション領域に関するサイズを変更後はどんなサイズにするかが、パーティション設定指示に含まれて良い。

以下、具体的に幾つかの実施形態を説明する。

＜第一の実施形態＞。

図１は、本発明の第一の実施形態に係るシステム全体の構成を示す。

ホストコンピュータ１１が、第一通信ネットワーク（例えばＬＡＮ（Local Area
Network））１０を介してクライアントコンピュータ１に接続され、第二通信ネットワーク（例えばＳＡＮ（Storage Area Network）２０を介してストレージシステム３１に接続され、第三通信ネットワーク（例えばＬＡＮ）４０を介して管理コンピュータ４１に接続される。管理コンピュータ４１は、ホストコンピュータ１１及びストレージシステム３１の両方を管理するコンピュータである。

ストレージサブシステム３１は、複数のディスク装置（例えばハードディスクドライブ（ＨＤＤ）、フラッシュメモリ等の他種の物理的な記憶装置であっても良い）３７と、ディスク装置３７へのアクセスを制御する制御装置３４とを備える。制御装置３４は、例えば、第二通信ネットワーク２０を介してホストコンピュータ１１と通信するインタフェース装置（例えば通信ポート、以下、ホストＩ／Ｆ）３２と、第三通信ネットワーク４０を介して管理コンピュータ４１と通信するインタフェース装置（例えば通信ポート、以下、管理Ｉ／Ｆ）３８と、ディスク装置３７と通信するインタフェース装置（例えば通信ポート、以下、ディスクＩ／Ｆ）３６と、ＣＰＵ３３と、メモリ３５とを備える。メモリ３５に、後述するストレージキャッシュであるキャッシュメモリが含まれている。そのキャッシュメモリは、一又は複数のメモリ、或いは、それらに設けられた論理的な記憶領域とすることができる。

ホストコンピュータ１１は、ＣＰＵ１３や、記憶資源１５や、第一通信ネットワーク１０に接続されるインタフェース装置（例えば通信ポート）１８や、第二通信ネットワーク２０に接続されるインタフェース装置（例えば通信ポート）１９や、第三通信ネットワーク４０に接続されるインタフェース装置（例えば通信ポート）１４を備えることができる。記憶資源１５、例えば、メモリ及び補助記憶装置（例えばＨＤＤ）の一方或いはその組み合わせである。記憶資源１５は、例えば、コンピュータプログラムとして、データベース管理システム（以下、ＤＢＭＳ）１７を記憶することができる。ＣＰＵ１３は、ＤＢＭＳ１７を読み込んで実行することができる。ＤＢＭＳ１７は、クライアントコンピュータ１からの要求（例えばＳＱＬ（Structured Query Language）文）を解析し、該解析の結果に基づく処理を実行する。以下、ＣＰＵがコンピュータプログラムを読み込んで実行することにより行われる処理の主体を、説明を分かりやすくするために、ＣＰＵではなくコンピュータプログラムとする場合がある。

上記の構成において、第一通信ネットワーク１０、第二通信ネットワーク２０及び第三通信ネットワーク４０は、それのうちの少なくとも二つが一体となっていても良いし、それらのうちの少なくとも一つがメインフレーム系のネットワークであっても良い。また、クライアントコンピュータ１、ホストコンピュータ１１、ストレージシステム３１の少なくとも一つが、一つの装置に仮想的に生成されたもの（例えばいわゆる仮想コンピュータ）であっても良い。また、制御装置３４の上述した構成は一例であり、他の構成を採用することもできる。

図２は、ホストコンピュータ１１、ストレージシステム３１及び管理コンピュータ４１の機能説明図である。

管理コンピュータ４１のＣＰＵで実行されるコンピュータプログラムとして、ストレージ管理部１４１がある。ストレージ管理部１４１は、ＤＢＭＳ１７から指示を受信し、該指示が所定種類の指示であれば、該所定種類の指示を、制御装置３４に送信することができる。

ＤＢＭＳ１７には、ＤＢバッファ技術が採用されており、ストレージシステム３１には、ストレージキャッシュ分割技術が採用されている。

ＤＢＭＳ１７は、ＤＢアクセス制御部１１１と、ＤＢ設定処理部１１５と、ストレージキャッシュ調整処理部１１７とを有する。ホストコンピュータ１１Ａの記憶資源１５（例えばメモリ）には、一以上のＤＢバッファ１１４で構成されるＤＢバッファ群１１３が用意される。また、その記憶資源１５（例えばメモリ）には、ログバッファ１１９が用意され、且つ、テーブル群１２１が記憶される。なお、このテーブル群１２１に含まれる各テーブルは、ＤＢオブジェクトとしてのテーブル（つまりＤＢを管理するためのテーブル）ではなく、例えば、ＤＢバッファ１１４でのバッファヒット率を管理するための後述のバッファヒット管理テーブル５０１（図１３Ａ及び図１３Ｂ参照）や、ＤＢバッファと論理ディスクとのマッピングを管理するための後述のＤＢバッファ−ディスクマッピングテーブル４０１（図８Ａ参照）である。

ＤＢアクセス制御部１１１は、ＤＢへのアクセス処理（例えばデータの更新或いは参照）を実行したり、そのアクセス処理のログを作成してログバッファ（ログを格納するためのバッファ）１１９に格納したりする。このＤＢＭＳ１７ではＤＢバッファ技術が採用されているので、ＤＢへのアクセス処理では、ＤＢアクセス制御部１１１は、主に、ＤＢバッファ群１１３におけるＤＢバッファ１１４にアクセスし、必要がある場合に、ストレージシステム３１へのアクセスが行われる。

ＤＢ設定処理部１１５は、ＤＢ初期設定フェーズにおいてＤＢアクセス環境の構築を行う。本実施形態で言うＤＢアクセス環境とは、ＤＢＭＳ１７がストレージシステム３１内のＤＢにアクセスするのに必要な複数の物理的或いは論理的な環境要素で構成された環境を意味する。ＤＢアクセス環境の構築とは、複数の環境要素のうちの二以上の環境要素を関連付けることを意味する（構築されたＤＢアクセス環境の具体例については図６を参照して後に説明する）。また、ＤＢ初期設定フェーズとは、この実施形態に係るシステムを稼動させるために必要な種々の初期設定（言い換えれば、ＤＢＭＳ１７がＤＢにアクセスできるようにするために必要な種々の初期設定）をホストコンピュータ１１やストレージシステム３１に行うフェーズである。すなわち、本実施形態では、ＤＢ初期設定フェーズとシステム稼動フェーズといった少なくとも２つのフェーズがあり、ＤＢ初期設定フェーズにおいて必要な初期設定が終了した場合に、システム稼動フェーズとなる。システム稼動フェーズには、種々の稼動フェーズ、例えば、試験的にシステムを稼動し初期設定が適切かどうかを判断し必要に応じて初期設定をチューニングするためのフェーズであるテスト稼動フェーズと、所定の業務を稼動する等の理由により正式にシステムを稼動するフェーズである正式稼動フェーズとが含まれても良い。

ストレージキャッシュ調整処理部１１７は、ストレージキャッシュ３１１の調整に関する処理を行う。具体的には、例えば、ストレージキャッシュ調整処理部１１７は、ストレージキャッシュ３１１の論理的な構成に関する設定を実行させるための指示（以下、ストレージキャッシュ設定指示、例えば、後述するキャッシュグループ初期割当指示や後述するパーティション変更指示）をストレージシステム３１に送信する。そのストレージキャッシュ設定指示は、ストレージシステム３１において、後述するホストＩ／Ｆ制御部３２３が受信し、キャッシュパーティション管理部３２５が解析して処理する。すなわち、本実施形態では、ＤＢＭＳ１７が、ストレージキャッシュ３１１の論理的な構成に関する設定をストレージシステム３１に実行させるためのインタフェースとしてストレージキャッシュ調整処理部１１７を備え、一方、ストレージシステム３１が、そのインタフェースからストレージキャッシュ設定指示を受け付けるインタフェースとしてホストＩ／Ｆ制御部３２３を備える。

ストレージシステム３１の制御装置３４には、前述したように、ストレージキャッシュ３１１が備えられている。この制御装置３４のＣＰＵ３３で実行されるコンピュータプログラム（例えばメモリ３５に記憶されるコンピュータプログラム）として、例えば、各ディスク装置３７へのアクセスを制御するディスクアクセス制御部３２７と、ＤＢＭＳ１７からのアクセスコマンドの処理やストレージキャッシュ３１１の論理的な構成に関する設定などを行うディスク制御部３１５とがある。ディスク制御部３１５は、ホストＩ／Ｆ制御部３２３と、データ転送制御部３２１と、キャッシュパーティション管理部３２５とを有する。

ホストＩ／Ｆ制御部３２３は、ホストコンピュータ１１に対するインタフェースとして機能するコンピュータプログラムである。ホストＩ／Ｆ制御部３２３は、ホストコンピュータ１１からコマンドを受け付け、コマンドを受けた場合には、受けたコマンドの種類を判別し、判別されたコマンドの種類に応じて、該受けたコマンドを、そのコマンドを処理できる他の部３２１或いは３２５に転送することができる。具体的には、例えば、ホストＩ／Ｆ制御部３２３は、受けたコマンドがアクセスコマンドであれば、該アクセスコマンドをデータ転送制御部３２１に転送し、受けたコマンドがストレージキャッシュ設定指示であれば、該ストレージキャッシュ設定指示をキャッシュパーティション管理部３２５に転送する。

データ転送制御部３２１は、アクセスコマンドの処理を実行するコンピュータプログラムである。データ転送制御部３２１は、ホストＩ／Ｆ制御部３２３からアクセスコマンドを受信し、該アクセスコマンドを解析し、該アクセスコマンドに従うアクセスをディスクアクセス制御部３２７に実行させることができる。

キャッシュパーティション管理部３２５は、キャッシュパーティション領域を管理するコンピュータプログラムである。キャッシュパーティション管理部３２５は、ホストＩ／Ｆ制御部３２３からストレージキャッシュ設定指示を受信し、該指示を解析し、該指示に従って、キャッシュパーティション領域に関する設定を実行することができる。

図３は、キャッシュパーティション領域の物理構成と論理構成の対応関係を示している。

ストレージキャッシュ３１１における各一以上のブロックを各キャッシュパーティション領域に割り当てることで、ストレージキャッシュ３１１に複数のキャッシュパーティション領域に論理的に分割することができる。ここで、ブロックとは、連続した複数のセグメントで構成される領域である。一つのキャッシュパーティション領域に割り当てられる複数のブロックは、ストレージキャッシュ３１１上で連続した領域となっている必要は無く、それぞれが離れた位置にあっても良い。その一例として、図３では、離れた位置にある複数のブロック“ＢＬＫ♯０”、“ＢＬＫ♯９”、“ＢＬＫ♯２５”及び“ＢＬＫ♯２７”が、一つのキャッシュパーティション領域“DBBuff1”にマッピングされていることを表している。

このように、ストレージキャッシュ３１１の論理分割を、ブロックのマッピングによって実現することにより、キャッシュパーティション領域のサイズの変更は、ブロックのマッピング変更によって対応することができる。

図４は、セグメントと親サブセグメント管理ブロック及び子サブセグメント管理ブロックとの対応関係を示している。

本実施形態では、セグメントは、単一又は複数のサブセグメントから構成されており、セグメントを構成するサブセグメントの個数を調整することで、セグメントのサイズが調整される。サブセグメントのサイズは、例えば、予め固定サイズに設定されている。複数のサブセグメントからセグメントを構成する場合、当該セグメントにおいて、最初にアクセスされたサブセグメントを「親サブセグメント」と称し、２番目以降にアクセスされたサブセグメントを「子サブセグメント」と称する。親サブセグメントと子サブセグメントを区別しない場合には、単に、「サブセグメント」と称する。すなわち、本実施形態では、サブセグメントが、ストレージキャッシュ３１１での物理的な管理単位であって、セグメントが、ストレージキャッシュ３１１に対する一アクセスでのデータサイズ単位（つまり入出力単位）である。

同図において、ＳＳＥＧ１〜ＳＳＥＧ８は、アクセスされたサブセグメントを、そのアクセス順番とともに示している。サブセグメントのサイズが１６ＫＢにデフォルト設定されている場合、セグメントサイズを６４ＫＢにするには、サブセグメントを４つ集めてセグメントを構成する必要がある。例えば、ＳＳＥＧ１を親サブセグメントとし、その後に続く３つのサブセグメントＳＳＥＧ２〜ＳＳＥＧ４を子サブセグメントとして、互いに論理的に関連付けることにより、一つのセグメントを構成することができる。同様に、ＳＳＥＧ５を親サブセグメントとし、その後に続く３つのサブセグメントＳＳＥＧ６〜ＳＳＥＧ８を子サブセグメントとして、互いに論理的に関連付けることにより、一つのセグメントを構成することができる。

尚、親サブセグメントと子サブセグメントは、必ずしも連続した記憶領域上に配置されている必要はなく、キャッシュメモリ上の各所に離散的に点在していてもよい。

親サブセグメント管理ブロック８０は、親サブセグメントアドレス８１、順方向ポインタ８２、逆方向ポインタ８３、子サブセグメントポインタ８４、及び親サブセグメント管理情報８５を含む。親サブサブセグメントアドレス８１は、親サブセグメント管理ブロック８０が管理する親サブセグメントの位置を示す。順方向ポインタ８２は、最も古くアクセスされた順番に親サブセグメント管理ブロック８０を指し示す。逆方向ポインタ８３は、最も新しくアクセスされた順番に親サブセグメント管理ブロック８０を指し示す。子サブセグメントポインタ８４は、子サブセグメント管理ブロック９０を指し示す。親サブセグメント管理情報８５には、親サブセグメントのステータス（ダーティ／クリーン／フリー）等が格納される。親サブセグメント内にダーティデータとクリーンデータが混在する場合には、ビットマップ情報によって、そのステータスが管理される。ちなみに、ダーティデータとは、ディスク装置３７に未だ格納されていないデータを意味し、クリーンデータとは、ディスク装置３７に格納済みのデータを意味する（ディスク装置３７に同じデータがあることを意味する）。

子サブセグメント管理ブロック９０は、子サブセグメントアドレス９１、順方向ポインタ９２、及び子サブセグメント管理情報９３を含む。子サブサブセグメントアドレス９１は、子サブセグメント管理ブロック９０が管理する子サブセグメントの位置を示す。順方向ポインタ９２は、最も古くアクセスされた順番に子サブセグメント管理ブロック９０を指し示す。子サブセグメント管理情報９３には、子サブセグメントのステータス等が格納される。子サブセグメント内にダーティデータとクリーンデータが混在する場合には、ビットマップ情報によって、そのステータスが管理される。

先頭ポインタ１０１は、順方向ポインタ８１の最後尾を指し示し、後方ポインタ１０２は、先頭の逆方向ポインタ８２によって指し示される。

このようにして、キュー管理される親サブセグメント管理ブロック８０と、子サブセグメント管理ブロック９０は、ステータスがダーティデータの場合には、ダーティーキューとして管理され、ステータスがクリーンデータの場合には、クリーンキューとして管理される。親サブセグメントと複数の子サブセグメントを論理的に関連付けてセグメントを構成することにより、親サブセグメントが状態遷移すると、子サブセグメントも状態遷移するので、デステージング処理を高速化できる。

ちなみに、キャッシュパーティション領域のサイズ、或いはキャッシュパーティション領域のセグメントのサイズの設定変更は、例えば、管理コンピュータ４１のストレージ管理部１４１を管理者が操作することにより、図５Ａに例示するＧＵＩ（Graphical User Interface）を表示させ、更に、管理者が、そのＧＵＩ上で“パーティーション”という文字列を指定することで図５Ｂに例示するＧＵＩを表示させ、該ＧＵＩを操作することで、行うことができる。

図６は、ＤＢアクセス環境の構成例を示す。

この図には、４つのＤＢアクセス環境、すなわち、表Ｔ１というＤＢオブジェクトのデータにアクセスするための第一のＤＢアクセス環境と、表Ｔ２というＤＢオブジェクトのデータにアクセスするための第二のＤＢアクセス環境と、インデクスＩ１というＤＢオブジェクトのデータにアクセスするための第三のＤＢアクセス環境と、インデクスＩ２というＤＢオブジェクトのデータにアクセスするための第四のＤＢアクセス環境とが例示されている。いずれのＤＢアクセス環境も、一つのＤＢオブジェクトに、一つのＤＢ領域が関連付けられ、その一つのＤＢ領域に、一つのＤＢバッファ１１４が関連付けられ、その一つのＤＢバッファ１１４に、一つのファイルが関連付けられ、一つのファイルに、一つの論理ボリュームが関連付けられ、一つの論理ボリュームに、一つの論理ディスクが関連付けられ、一つの論理ディスクに、一つのキャッシュパーティション領域が関連付けられ、一つのキャッシュパーティション領域に、一つの論理ユニット（ＬＵ）が関連付けられた構成となっている。

ちなみに、図示のＤＢアクセス環境において、ＤＢオブジェクトから論理ディスクまでが、ホストコンピュータ１１内で管理されており、キャッシュパーティション領域及びＬＵが、ストレージシステム３１内で管理されている。ホストコンピュータ１１のオペレーティングシステム（ＯＳ）には、複数のコンピュータプログラム（図示せず）として、例えば、デバイスマネージャ、ボリュームマネージャ及びファイルシステムが含まれる。論理ディスクは、ストレージシステム３１から提供されるＬＵを基にデバイスマネージャにより作成された論理的なディスク装置である。論理ボリュームは、論理ディスクを基にボリュームマネージャにより作成された論理的な記憶資源である。ファイルは、ファイルシステムで管理される資源である。ＤＢ領域とは、ＤＢＭＳ１７で管理されている論理的な記憶領域である。また、図示の各ＤＢアクセス環境において、ＤＢ領域を表す図形上の文字列（例えばDBArea1）は、ＤＢ領域名を表し、ＤＢバッファを表す図形近傍に書いてある文字列（例えばDBBuff1）は、ＤＢバッファ名を表し、ファイルを表す図形上の文字列（例えば/DB/DB1）は、ファイル名を表し、論理ボリュームを表す図形上の文字列（例えばLVOL1）は、論理ボリューム名を表し、論理ディスクを表す図形上の文字列（例えば/dev/dsik1）は、論理ディスク名を表す。また、キャッシュパーティション領域を表す図形近傍の文字列（例えばDBBuff1）は、キャッシュパーティション領域の名称（パーティション名）を表し、論理ユニットを表す図形上の文字列（例えばＬＵＮ１）のうちの数字は、ＬＵＮ（Logical Unit Number）を表す。

以上の各ＤＢアクセス環境が、ＤＢ初期設定フェーズにおいて構築される。ＤＢ初期設定フェーズでは、例えば、ＤＢＭＳ１７が、クライアントコンピュータ１から、図７Ａに例示するＤＢ領域定義文と図７Ｂに例示するＤＢバッファ定義文とを受信する。ＤＢ領域定義文及びＤＢバッファ定義文のうちの少なくとも一方は、例えば、クライアントコンピュータ１のユーザによって作成された文である。ＤＢ領域定義文には、作成する各ＤＢ領域毎に、そのＤＢ領域に関する情報として、例えば、ＤＢ領域名、そのＤＢ領域に対応付けるファイルのファイル名、そのＤＢ領域のサイズ、及びそのＤＢ領域に対応付けるＤＢバッファのページのサイズが記録されている。一方、ＤＢバッファ定義文には、各ＤＢバッファ毎に、そのＤＢバッファに関する情報として、例えば、ＤＢバッファ名、ＤＢバッファのサイズ（図示の例ではページ数で指定されている）、及び対応先となるＤＢ領域のＤＢ領域名が記録される。ＤＢ設定処理部１１５は、ＤＢ領域定義文及びＤＢバッファ定義文を解析し、各ＤＢアクセス環境の構成を表す情報として、例えば、図８Ａに例示するＤＢバッファ−ディスクマッピングテーブル４０１を作成する。このテーブル４０１によれば、ＤＢ領域、ＤＢバッファ、ファイル、論理ボリューム及び論理ディスクの対応関係がわかる。また、このテーブル４０１には、ページサイズ及びＤＢバッファサイズも記録されるので、どのＤＢバッファはどんなサイズであってそのＤＢバッファにおけるページはどんなサイズであるかもわかる。ＤＢバッファに対するファイル、論理ボリューム及び論理ディスクの対応付けは、例えばＤＢ設定処理部１１５がＯＳの所定のコンピュータプログラムを呼び出すことでＯＳに実行させ、ＯＳとのやり取りにより、上記テーブル４０１を作成することができる。

以上のようにして構築されたＤＢアクセス環境では、例えば以下の流れによって、ＤＢに対するアクセスが行われる。以下、表Ｔ１の更新が行われる場合を例に採って説明する。なお、以下の説明でも使用するが、本実施形態において、“バッファヒット”とは、書込みの場合には、データの書込み先となるページを確保できたことを意味し、読み出しの場合には、読み出し対象のデータを記憶したページを見つけたことを意味する。同様に、“キャッシュヒット”とは、書込みの場合には、データの書込み先となるセグメントを確保できたことを意味し、読み出しの場合には、読み出し対象のデータを記憶したセグメントを見つけたことを意味する。バッファヒット率が高いほど、ストレージシステム３１に対してアクセスコマンドを発行させる回数が少ない。また、キャッシュヒット率が高いほど、ストレージシステム３１内でのアクセス性能の向上が期待できる。

ＤＢアクセス制御部１１１が、表Ｔ１に対応するＤＢ領域“DBArea1”に対する書込みを実行する。具体的には、ＤＢアクセス制御部１１１は、ＤＢ領域“DBArea1”に対応したＤＢバッファ“BBuff1”でバッファヒットとなった場合、バッファヒットの対象である一以上のページ（ＤＢバッファ“BBuff1”上のページ）にデータを書き込み、ストレージシステム３１のＬＵ“LU#1”にライトコマンドが発行されることなく、表Ｔ１の更新が終了となる。一方、バッファヒットしなかった場合、ＤＢアクセス制御部１１１は、ファイル“/DB/DB1”に対する書込みを実行する。それにより、ファイル“/DB/DB1”、論理ボリューム“LVOL1”、論理ディスク“/dev/dsik1”及びＬＵＮ“1”の対応付け（この対応付けは、例えばＯＳで管理されている）を基に、ＬＵＮ“1”を指定したライトコマンドがホストコンピュータ１１からストレージシステム３１に送信される。ストレージシステム３１では、データ転送制御部３２１が、そのライトコマンドでＬＵＮ“１”が指定されているので、ＬＵＮ“１”に対応したキャッシュパーティション領域“DBBuff1”における、キャッシュヒットしたセグメントに、該ライトコマンドに従うデータを書く。そして、データ転送制御部３２１は、そのデータをそのキャッシュパーティション領域“DBBuff1”から読み出し、読み出したデータを、ディスクアクセス制御部３２７を呼び出して、ＬＵＮ“１”のＬＵに書く。それにより、そのデータが、ディスクアクセス制御部３２７により、そのＬＵに対応したディスク装置３７に書き込まれる。

本実施形態では、説明を分かり易くするために、ＤＢアクセス環境の構成として上記のような構成としているが、その構成は、上記の構成に限らず、運用形態に応じて様々な構成が採られ得る。例えば、複数のファイルに一つの論理ボリュームが関連付けられても良いし、一つの論理ボリュームに複数の論理ディスクが関連付けられても良い。また、例えば、ストレージシステム３１がＮＡＳ（Network Attached Storage）としての機能を有しても良く、その場合、図示のファイルシステムは、ホストコンピュータ１１とストレージシステム３１の両方にあるイメージとなる。

この図６では、ＤＢバッファを表す図形内の各マスが、各ページを意味しており、キャッシュパーティションを表す図形内の各マスが、各セグメントを意味している。ＤＢアクセス環境がどのような構成であれ、この図で大事な点の一つは、ＤＢ初期設定フェーズにおいて、ＤＢバッファのＤＢバッファサイズ及びページサイズに、そのＤＢバッファに対応するキャッシュパーティション領域のパーティションサイズ及びセグメントサイズが一致させられる点にある。パーティションサイズ及びセグメントサイズは、ＤＢＭＳ１７からのストレージキャッシュ設定指示で指定される。具体的には、例えば、ＤＢ初期設定フェーズでは、ＤＢ設定処理部１１５により、図８Ｂに例示するストレージキャッシュ制御指示テーブル４０３が作成される。ストレージキャッシュ制御指示テーブル４０３には、各ＤＢバッファに対応付けられる各キャッシュパーティション領域毎に、そのキャッシュパーティション領域に対応付けるＬＵのＬＵＮと、そのキャッシュパーティション領域のセグメントサイズ、パーティション名及びパーティションサイズ（キャッシュパーティション領域それ自体のサイズ）が記録される。セグメントサイズ及びパーティションサイズは、対応するＤＢバッファのページサイズ及びＤＢバッファサイズと同じ値にされる。このストレージキャッシュ制御指示テーブル４０３がストレージシステム３１に送信されることで、キャッシュパーティション管理部３２５により、図９に例示するストレージキャッシュ−ディスクマッピングテーブル４０５が作成され、メモリ３５に格納される。ストレージキャッシュ−ディスクマッピングテーブル４０５には、例えば、どのＬＵにどのキャッシュパーティション領域が対応付けられ、そのキャッシュパーティション領域のパーティションサイズ及びセグメントサイズがどのぐらいであるかが記録される。ストレージシステム３１内では、例えば図３及び図４を参照して説明した方法により、各キャッシュパーティション領域が管理される。

以下、本実施形態で行われる処理流れを説明する。その説明は、ＤＢ初期設定フェーズとシステム稼動フェーズとに分けることにする。また、以下の説明では、ストレージキャッシュ設定指示は、ＤＢＭＳ１７から管理コンピュータ４１のストレージ管理部１４１を経由することなくストレージシステム３１に送信されるが、ストレージキャッシュ設定指示は、ＤＢＭＳ１７からストレージ管理部１４１に送信され、ストレージ管理部１４１からストレージシステム３１に送信されても良い。

＜＜ＤＢ初期設定フェーズ＞＞。

図１０は、ＤＢ初期設定フェーズにおいてＤＢＭＳ１７で実行されるＤＢバッファ構築処理の流れの一例を示す。なお、図では、ステップを「Ｓ」と略記している。

ステップ１０１で、ＤＢ設定処理部１１５が、クライアントコンピュータ１からのＤＢ領域定義文（図７Ａ参照）及びＤＢバッファ定義文（図７Ｂ参照）を解析する。これにより、例えば、用意すべきＤＢバッファのページサイズやページ数が特定される。

ステップ１０２で、ＤＢ設定処理部１１５が、ＤＢバッファ総サイズを初期値として０（ゼロ）を設定する。

ステップ１０３で、ＤＢ設定処理部１１５が、ＤＢ領域定義文及びＤＢバッファ定義文の解析により特定された或るＤＢバッファについてページサイズにページ数を掛けることにより、ＤＢバッファサイズを算出し、算出されたＤＢバッファサイズを上記ＤＢバッファ総サイズに加算する。これにより、ＤＢバッファ総サイズが更新される。

ステップ１０４で、ＤＢ設定処理部１１５が、その或るＤＢバッファに対応したキャッシュパーティション領域に関する情報を、ストレージキャッシュ制御指示テーブル４０３に登録する。具体的には、その或るＤＢバッファのＤＢバッファ名と同じ名前のパーティション名、その或るＤＢバッファのページサイズと同じ値のセグメントサイズ、その或るＤＢバッファのＤＢバッファサイズと同じ値のパーティションサイズ、及び、その或るＤＢバッファに対応した論理ディスクに対応するＬＵＮ（例えばＯＳから取得されるＬＵＮ）が登録される。なお、このステップ１０４の段階で、ＤＢバッファ−ディスクマッピングテーブル４０１の或る行に、その或るＤＢバッファに関する情報を登録して良い。

ステップ１０５で、ＤＢ設定処理部１１５が、ＤＢ領域定義文及びＤＢバッファ定義文の解析により特定された全てのＤＢバッファにそれぞれ対応する全てのキャッシュパーティション領域についてステップ１０３及び１０４を実行したかどうかを判断する。実行していれば、ステップ１０６にすすみ、実行していなければ、未処理のＤＢバッファについてステップ１０３を実行する。なお、そのステップ１０３においてＤＢバッファサイズが加算されるＤＢバッファ総サイズは、前回のステップ１０３での更新後のＤＢバッファ総サイズである。

ステップ１０６で、ＤＢ設定処理部１１５が、キャッシュグループ初期割当指示を準備し、ストレージキャッシュ調整処理部１１７を呼び出すことで、ストレージキャッシュ調整処理部１１７により、キャッシュグループ初期割当指示をストレージシステム３１に送信させる。その際、上記作成されたストレージキャッシュ制御指示テーブル４０３も送信させる。なお、本実施形態において、キャッシュグループとは、一つのＤＢＭＳ１７に対応する一以上のキャッシュパーティション領域の集合を言う。すなわち、本実施形態では、図１６Ａに例示するように、一つのＤＢＭＳ１７につき、一つのパーティション領域（キャッシュグループ）が用意され、その一つのパーティション領域が、その一つのＤＢＭＳ１７が管理する複数のＤＢバッファにそれぞれ対応した複数のサブパーティション領域（キャッシュパーティション領域）が形成される。しかし、キャッシュグループという概念の無い形態、例えば、図１６Ｂに示すように、単に、各ＤＢバッファ毎にキャッシュパーティション領域が形成されても良い。

ステップ１０７で、ストレージキャッシュ調整処理部１１７が、エラー報告を受信した場合、ステップ１０７でＹＥＳとなり、エラー報告を受信したことをＤＢ設定処理部１１５に通知してステップ１０８に進み、完了報告を受信した場合、終了となる。

ステップ１０８で、ＤＢ設定処理部１１５が、ストレージキャッシュ制御指示テーブル更新処理を実行する。すなわち、ステップ１０６で送信されたストレージキャッシュ制御指示テーブルを更新する。エラー報告を受信する理由としては、後の図１１の説明からわかるように、ストレージキャッシュ制御指示テーブル４０３に記録した一以上のパーティションサイズの合計以上のサイズの空き領域がストレージキャッシュ３１１に無いということなので、そのテーブル４０３の更新方法としては、例えば、以下の（方法１）〜（方法３）が考えられる。以下の方法において、キャッシュパーティション領域の数或いはサイズの変更が行われる場合には、対応するＤＢバッファの数或いはサイズの変更が行われても良い。バッファサイズとパーティションサイズは互いに対応しており、また、ページサイズとセグメントサイズも互いに対応しているためである。以下の（方法１）〜（方法３）に限らず他の方法が採用されても良い。
（方法１）ＤＢ設定処理部１１５が、或る削減率を各ＤＢバッファサイズ及び各パーティションサイズに乗ずる。その削減率は、予め決められていても良いし、どのぐらい空き領域サイズが足りなかった（つまり不足空き領域サイズ）がエラー報告に含められている場合には、不足空き領域サイズを基にＤＢ設定処理部１１５により削減率が決定されても良い。
（方法２）ＤＢ設定処理部１１５が、同じセグメントサイズのキャッシュパーティション領域を一つにまとめ、且つ、或る削減率を、一つにまとめられたキャッシュパーティション領域のパーティションサイズに乗ずる。それにより、パーティション数およびパーティションサイズを削減することができる。
（方法３）ＤＢ設定処理部１１５が、ストレージキャッシュ３１１の論理分割の実行を中止する。

図１１は、キャッシュグループ初期割当指示を受信したストレージシステム３１において実行される処理の流れの一例を示す。

ステップ１１１で、キャッシュパーティション管理部３２５は、キャッシュグループ初期割当指示と共にストレージキャッシュ制御指示テーブル４０３を受信し、そのテーブル４０３を解析する。

ステップ１１２で、キャッシュパーティション管理部３２５は、現在の空き領域サイズ（ストレージキャッシュ３１１における空き領域のサイズ）がストレージキャッシュ制御指示テーブル４０３のうちの或るパーティションサイズ以上か否かを判断する。現在の空き領域サイズがそのパーティションサイズ未満であれば、ステップ１１２でＮＯとなり、ステップ１１３に進む。現在の空き領域サイズがそのパーティションサイズ以上であれば、ステップ１１２でＹＥＳとなり、ステップ１１４に進む。

ステップ１１３で、キャッシュパーティション管理部３２５は、ホストＩ／Ｆ制御部３２３を通じて、エラー報告を送信する。そのエラー報告には、例えば、現在の空き領域サイズとストレージキャッシュ制御指示テーブル４０３における一以上のパーティションサイズの合計との差分、つまり不足空き領域サイズが含められても良い。

ステップ１１４で、キャッシュパーティション管理部３２５は、空き領域サイズ変更処理を行う。具体的には、空き領域サイズから、上記或るパーティションサイズを減じる。

ステップ１１５で、キャッシュパーティション管理部３２５は、パーティション設定処理（図１２参照）というサブルーチンを実行する。例えば、キャッシュパーティション管理部３２５は、パーティション／ＬＵ初期割当指示を受け付け（ステップ１２１）、内部的に（自分に対して）、パーティション／ＬＵ初期割当指示を発行する。その指示では、例えば、ストレージキャッシュ制御指示テーブル４０３に記録されているＬＵＮ、セグメントサイズ、パーティション名及びパーティションサイズが指定されている。ここでは、そのＬＵＮに対応したＬＵを「対象ＬＵ」と呼ぶ。キャッシュパーティション管理部３２５は、その指示に応答して、対象ＬＵへのアクセス（Ｉ／Ｏ）を抑制することをホストＩ／Ｆ制御部３２３に実行させ（ステップ１２２）、対象ＬＵに割り当てるキャッシュパーティション領域を初期化（例えば図４の管理を初期化）する（ステップ１２３）。このステップ１２３において、例えば、ストレージキャッシュ−ディスクマッピングテーブル４０５（図９参照）に、対象ＬＵにつき、ＬＵＮ、セグメントサイズ、パーティション名及びパーティションサイズを登録することができる。ステップ１２３の後、キャッシュパーティション管理部３２５は、アクセスの抑止をホストＩ／Ｆ制御部３２３に解除させ（ステップ１２４）、完了報告を内部的に発行する（ステップ１２５）。これにより、このサブルーチンから抜ける。

ステップ１１６で、キャッシュパーティション管理部３２５は、ストレージキャッシュ制御指示テーブル４０３で表されている全てのキャッシュパーティション領域を設定したか否かを判断する。設定していないと判断した場合、ステップ１１６でＮＯとなり、別のキャッシュパーティション領域についてステップ１１２を行う。設定したと判断した場合、ステップ１１６でＹＥＳとなり、ステップ１１７に進む。

ステップ１１７では、キャッシュパーティション管理部３２５は、ホストＩ／Ｆ制御部３２３を通じて、完了報告を送信する。

＜＜システム稼動フェーズ＞＞。

ＤＢＭＳ１７が、クライアントコンピュータ１からデータベース操作要求（例えばＳＱＬ文）を受け付け、該データベース操作要求に従って、ＤＢオブジェクトに対するアクセス（Ｉ／Ｏ）を実行することができる。その際、ＤＢＭＳ１７は、そのＤＢオブジェクトに対応するＤＢバッファでバッファヒットした場合には、バッファヒットしたページに対するアクセスにより、ＤＢオブジェクトに対するアクセスを終了し、バッファヒットしなかった場合に、該ＤＢバッファに対応するＬＵＮを指定したアクセスコマンドがストレージシステム３１に発行される。ＤＢアクセス制御部１１１は、ＤＢバッファに対するアクセスの都度にバッファヒットしたか否かをホストコンピュータ１１内の記憶資源１５に蓄積することで、ＤＢバッファ毎にバッファヒット率を算出することができる。バッファヒット率とは、例えば、ＤＢバッファへのアクセス回数を１００とした場合のバッファヒット回数を表す。ＤＢアクセス制御部１１１は、ＤＢバッファ毎に、算出したバッファヒット率や、ＤＢバッファへのアクセスの種類（ライトであるかリードであるか）に応じたアクセス回数（リード回数及びライト回数）を、バッファヒット管理テーブル５０１に登録する。これにより、図１３Ａに示すように、ＤＢ初期設定フェーズ終了直後は、どのＤＢバッファにもアクセスが発生していないので、バッファヒット率、リード回数及びライト回数は０（ゼロ）であるが、システム稼動フェーズとなりＤＢバッファへのアクセスが発生すると、バッファヒット率、リード回数及びライト回数は更新される。図１３Ｂは、或る時刻Ｔにおけるバッファヒット管理テーブル５０１を示す。

図１４は、システム稼動フェーズでＤＢＭＳ１７により実行される処理の流れの一例を示す。

ステップ１３１で、ＤＢ設定処理部１１５は、パーティション変更指示を受け付ける。パーティション変更指示は、クライアントユーザの操作によりクライアントコンピュータ１１から送信されるか、或いは、管理者の操作により管理コンピュータ４１内のストレージ管理部１４１から送信される。パーティション変更指示を受信した場合、ステップ１３２に進む。

ステップ１３２では、ＤＢ設定処理部１１５は、バッファヒット管理テーブル５０１を解析する。そして、バッファヒット管理テーブル５０１の或る行に対応したＤＢバッファ（以下、当該ＤＢバッファ）について、ステップ１３３〜１３５が実行される。

ステップ１３３では、ＤＢ設定処理部１１５は、当該ＤＢバッファにキャッシュパーティション領域が割り当けられているかどうか（以下、パーティション割当有無）を判断する。これは、種々の方法で実行可能である。例えば、当該ＤＢバッファのＤＢバッファ名と同じ名前のパーティション名の有無をストレージシステム３１に問い合わせ、その問合せに対する回答を解析することにより、パーティション割当有無が判断されても良い。別の方法として、例えば、ストレージシステム３１に送信したストレージキャッシュ制御指示テーブル４０３（図８Ｂ参照）を、ホストコンピュータ１１の記憶資源１５に蓄積しておき、そのテーブル４０３を参照することで、パーティション割当有無が判断されても良い。また別の方法として、ＤＢバッファ−ディスクマッピングテーブル４０１に、パーティション割当有無を意味するフラグのカラムを用意し、ＤＢ設定処理部１１５が、例えば図１０のステップ１０７で完了報告を受信した場合にそのフラグを設定する構成となっている場合に、そのマッピングテーブル４０１を参照することで、パーティション割当有無が判断されても良い。パーティション割当が有りと判断された場合、ステップ１３３でＹＥＳとなり、ステップ１３４にすすむ。パーティション割当が無しと判断された場合、ステップ１３３でＮＯとなり、ステップ１３６に進む。

ステップ１３４では、ＤＢ設定処理部１１５が、当該ＤＢバッファのバッファヒット率（バッファヒット管理テーブル５０１に記録されているバッファヒット率）が所定の閾値（例えば１００）以上であるか否かを判断する。所定の閾値以上と判断された場合、ステップ１３４でＹＥＳとなり、ステップ１３５に進む。所定の閾値未満と判断された場合、ステップ１３４でＮＯとなり、ステップ１３６に進む。

ステップ１３５では、ＤＢ設定処理部１１５が、当該ＤＢバッファに対するキャッシュパーティション領域の割り当ての解除を意味する要求（以下、パーティション割当解除要求）を作成し、作成したパーティション割当解除要求を記憶資源１５に蓄積する。

ステップ１３６では、バッファヒット管理テーブル５０１に記録されている全てのＤＢバッファについてステップ１３３以降の処理が完了したか否かを判断する。完了していないと判断した場合、ステップ１３６でＮＯとなり、そのテーブル５０１上の別の行に対応するＤＢバッファを当該ＤＢバッファとしてステップ１３３以降が行われる。一方、完了したと判断された場合、ステップ１３６でＹＥＳとなり、ステップ１３７に進む。

ステップ１３７では、ＤＢ設定処理部１１５が、記憶資源１５に蓄積されている一以上のパーティション割当解除要求を含んだパーティション変更指示を準備し、ストレージキャッシュ調整処理部１１７を呼び出すことで、ストレージキャッシュ調整処理部１１７に、該パーティション変更指示をストレージシステム３１に送信させる。

ステップ１３８では、ＤＢ設定処理部１１５が、ストレージシステム３１からストレージキャッシュ調整処理部１１７を通じて完了報告を受信する。完了報告では無く例えばエラー報告を受信した場合、パーティション変更失敗を、ステップ１３１で受信したパーティション変更指示の送信元に通知しても良い。

以上が、ＤＢＭＳ１７で行われる処理の流れの一例である。なお、この流れは、クライアントコンピュータ１１或いは管理コンピュータ４１からの指示を契機に開始されているが、それに代えて、ＤＢＭＳ１７が、定期的に又は不定期的に、バッファヒット管理テーブル５０１を参照して、バッファヒット率が所定閾値を超えているＤＢバッファがあるかどうかを調べ、ある場合には、所定閾値を超えている全てのＤＢバッファについて、ステップ１３５及びステップ１３７を実行しても良い。

図１５は、パーティション変更指示を受信したストレージシステム３１において行われる処理の流れの一例を示す。

ステップ１４１で、キャッシュパーティション管理部３２５が、ホストＩ／Ｆ制御部３２３を介して、パーティション変更指示を受け付ける。パーティション変更指示を受けた場合、そのパーティション変更指示中の一以上のパーティション割当解除要求（以下、当該解除要求）について、ステップ１４２以降の処理を行う。

ステップ１４２で、キャッシュパーティション管理部３２５が、当該解除要求に対応したキャッシュパーティション領域にダーティデータがあれば、そのダーティデータをデステージする（すなわち、キャッシュパーティション領域に対応したＬＵを構成するディスク装置３７にそのダーティデータを書く）。

ステップ１４３で、キャッシュパーティション管理部３２５が、変更先キャッシュパーティション領域のセグメントサイズが最小サイズ（サブセグメントサイズ）であるか否かをチェックする。ここで、変更先キャッシュパーティション領域とは、例えば、どのＤＢバッファにも対応付けられていない領域（以下、共有キャッシュ領域）である。つまり、この図１５に示す流れは、キャッシュパーティション領域を単に解放するだけでなく、該キャッシュパーティション領域を共有キャッシュ領域に含めることを例に採った流れとなっている。変更先パーティションのセグメントサイズが最小サイズでない場合には、ステップ１４３でＮＯとなり、ステップ１４４にすすみ、最小サイズである場合には、ステップ１４３でＹＥＳとなり、ステップ１４６に進む。

ステップ１４４で、キャッシュパーティション管理部３２５が、ステップ１４４で、ＣＰＵ２１は、親サブセグメントに子サブセグメントが接続されるように、親サブセグメント管理ブロック８０と子サブセグメント管理ブロック９０のキュー管理を再編成する。この再編成処理を子サブセグメント数分繰り返すことで（ステップ１４５）、変更元パーティションから変更先キャッシュパーティション領域に移動するブロックのセグメントサイズを変更先キャッシュパーティション領域のセグメントサイズに一致させることができる。

ステップ１４６で、キャッシュパーティション管理部３２５が、親サブセグメント同士が接続されるように、親サブセグメント管理ブロック８０のキュー管理を再編成する。

ステップ１４７で、キャッシュパーティション管理部３２５が、ステップ１４１で受けたパーティション変更指示中の全てのパーティション割当解除要求について、ステップ１４２以降の処理を行ったか否かを判断する。行っていなければ、ステップ１４７でＮＯとなり、他のパーティション割当解除要求を当該解除要求としてステップ１４２を実行し、行っていれば、ステップ１４７でＹＥＳとなり、ステップ１４８にすすむ。

ステップ１４８で、キャッシュパーティション管理部３２５が、ホストＩ／Ｆ制御部３２３を通じて、完了報告をＤＢＭＳ１７に送信する。

以上、上述した第一の実施形態によれば、ＤＢ初期設定フェーズにおいて、ＤＢＭＳ１７が、作成したＤＢバッファのページサイズと同じセグメントサイズのキャッシュパーティション領域を、そのＤＢバッファに対応したキャッシュパーティション領域としてストレージシステム３１に作成させる。その際、バッファサイズとパーティションサイズも一致させる。システム稼動フェーズになれば、ＤＢバッファやそれに対応付けられたキャッシュパーティション領域に対してアクセスが発生するが、ページサイズ及びセグメントサイズが一致しており、バッファサイズ及びパーティションサイズも一致しているので、キャッシュパーティション領域の利用効率の低下を抑えることができる。

また、上述した第一の実施形態によれば、バッファヒット率が所定閾値（例えば１００）以上のＤＢバッファに対応したキャッシュパーティション領域が削除される。削除されたキャッシュパーティション領域は、例えば、前述した共有キャッシュ領域に割当てられる。これにより、共有キャッシュ領域でのキャッシュヒット率の向上が期待できる。なお、キャッシュパーティション領域の削除とは、キャッシュパーティション領域の全てを削除（解放）するのであっても良いし、その一部を削除するのであっても良い（つまり縮小であっても良い）。つまり、縮小率は、所定の方法でＤＢ設定処理部１１５によって決定されても良い。例えば、縮小率は、バッファヒット率を１００で割った値とされても良い。

＜第二の実施形態＞。

以下、本発明の第二の実施形態を説明する。その際、第一の実施形態との相違点を主に説明し、第一の実施形態との共通点については、説明を省略或いは簡略する。

図１７は、第二の実施形態において、キャッシュグループ初期割当指示を受信したストレージシステム３１において実行される処理の流れの一例を示す。なお、第一の実施形態のそれと同じ部分については、同一の参照番号が付してある。

第二の実施形態では、ステップ１１２でＮＯとなった場合に、エラー報告が送信されるのではなく、以下のステップ２０１〜２０３が実行される。

ステップ２０１で、キャッシュパーティション管理部３２５が、割り当て要求サイズとして、空き領域サイズを、メモリ３５に記憶させる。つまり、ここでは、ＤＢバッファ総サイズを現在の空き領域サイズにまで減らせば良いとする。

ステップ２０２で、キャッシュパーティション管理部３２５が、割り当て要求削減率として、空き領域サイズをＤＢバッファ総サイズで割った値を、メモリ３５に記憶させる。

ステップ２０３で、キャッシュパーティション管理部３２５が、ストレージキャッシュ制御指示テーブル４０３に書かれている各パーティションサイズに、ステップ２０２で算出され記憶された割り当て要求削減率を乗ずる。

その後、ステップ１１４以降が行われる。これにより、ストレージキャッシュ３１１に設定される各キャッシュパーティション領域のパーティションサイズは、ＤＢバッファサイズを上記割り当て要求削減率分縮小されたサイズとなる。

以上が、第二の実施形態についての説明である。なお、上記説明では、全てのキャッシュパーティション領域が一律に縮小されるが、それに代えて、ＤＢオブジェクトの属性など所定の情報を基に、各キャッシュパーティション領域の縮小率（割り当て要求削減率）が違っても良い。

この第二の実施形態によれば、ストレージキャッシュ３１１での空き領域サイズが要求パーティションサイズ（ＤＢバッファ総サイズ）に満たない場合には、要求パーティションサイズを空き領域サイズ以下に縮小して各キャッシュパーティション領域が設定され、エラー報告がＤＢＭＳ１７に変えらないようにする。これにより、ＤＢＭＳ１７でエラー報告に対処する必要をなくすことができる。

なお、ユーザ或いは管理者によっては、各ＤＢバッファサイズに対応した各パーティションサイズのキャッシュパーティション領域が用意されないのであればキャッシュパーティション領域を必要としない等、ユーザ或いは管理者のニーズは様々であるかもしれないので、この第二の実施形態では、ＤＢＭＳ１７が、エラー報告を必要とするか不要とするかをユーザ或或いは管理者から受け付けても良い。ＤＢＭＳ１７は、エラー報告の要否を表す情報（以下、エラー報告要否情報）を、キャッシュグループ初期割当指示に含めて送信しても良い。この場合、キャッシュパーティション管理部３２５は、キャッシュグループ初期割当指示を解析し、エラー報告要否情報がエラー報告を必要とすることを表していれば、ステップ１１２でＮＯの場合に図１１のステップ１１３を実行し（つまりエラー報告を送信し）、エラー報告要否情報がエラー報告を不要とすることを表していれば、ステップ１１２でＮＯの場合に図１７のステップ２０１以降を実行してもよい。

＜第三の実施形態＞。

この第三の実施形態では、バッファヒット率が所定閾値以上のＤＢバッファに割り当てられているキャッシュパーティション領域を解放するだけでなく、解放されたキャッシュパーティション領域の全部又は一部を、バッファヒット率が所定閾値未満のＤＢバッファに割り当てられているキャッシュパーティション領域（以下、拡張対象パーティション領域）に追加され、より大サイズのキャッシュパーティション領域とされる。これにより、バッファヒット率が所定閾値未満のＤＢバッファに割り当てられているキャッシュパーティション領域についてキャッシュヒット率の向上が期待できる。以下、具体的に説明する。その際、バッファヒット率が所定閾値以上のＤＢバッファに割り当てられているキャッシュパーティション領域を、「削除対象パーティション領域」と称し、バッファヒット率が所定閾値未満のＤＢバッファに割り当てられているキャッシュパーティション領域を、「拡張対象パーティション領域」と称する。

図１８は、第三の実施形態のシステム稼動フェーズでＤＢＭＳ１７により実行される処理の流れの一例を示す。

全ての削除対象パーティション領域についてパーティション割当て解除要求が作成された後に、全ての拡張対象パーティション領域についてパーティションサイズ拡張要求が作成され、作成されたパーティション割当て解除要求及びパーティションサイズ拡張要求を含んだパーティション変更指示が、ＤＢＭＳ１７からストレージシステム３１に送信される。

すなわち、ステップ１３５の後に、ステップ３０１が行われる。

ステップ３０１で、ＤＢ設定処理部１１５が、削除サイズとして、現在の削除サイズ（初めての場合は０（ゼロ））に、当該パーティション領域サイズ（ステップ１３５で作成されたパーティション割り当て解除要求で指定されている削除対象パーティション領域）のパーティションサイズを加算した値を、記憶資源１５に記憶させる。このステップ３０１は、バッファヒット率が所定閾値以上である全てのＤＢバッファについて実行される。

バッファヒット率が所定閾値以上である全てのＤＢバッファについてステップ３０１まで実行された場合、ステップ１３６でＹＥＳとなり、ステップ３０２にすすむ。

ステップ３０２で、ＤＢ設定処理部１１５が、ＤＢバッファ−ディスクマッピングテーブル４０１及びバッファヒット管理テーブル５０１を解析し、後述のステップ３０３での判断に必要な情報を得る。

ステップ３０３で、ＤＢ設定処理部１１５が、当該ＤＢバッファ（バッファヒット率が所定閾値未満である或るＤＢバッファ）にキャッシュパーティション領域が割当てられていて且つそのキャッシュパーティション領域が削除対象であるか否かを判断する。肯定的な判断結果になれば、ステップ３０３でＹＥＳとなり、ステップ３０６にすすみ、否定的な判断結果になれば、ステップ３０３でＮＯとなり、ステップ３０４にすすむ。

ステップ３０４で、ＤＢ設定処理部１１５が、パーティションサイズ拡張要求を作成し、記憶資源１５に記憶させる。そのパーティションサイズ拡張要求には、例えば、拡張対象パーティション領域のパーティション名と、拡張サイズとが含まれる。ここでの拡張対象パーティション領域は、例えば、バッファヒット率が所定閾値未満である一以上のＤＢバッファの中から選択したＤＢバッファに割当てられているキャッシュパーティション領域である。拡張サイズは、そのキャッシュパーティション領域に追加するパーティションサイズである。拡張サイズは予め設定された法則に基づいてＤＢ設定処理部１１５により決定される。

ステップ３０５で、ＤＢ設定処理部１１５が、削除サイズとして、現時点の削除サイズ（初めてのステップ３０５では、全ての削除対象パーティション領域のパーティションサイズの合計）から上記拡張サイズを減じた値を、記憶資源１５に記憶させる。

ステップ３０６で、ＤＢ設定処理部１１５が、全てのＤＢバッファについてステップ３０３以降の処理を行ったか否かを判断する。行っていれば、ステップ３０６でＹＥＳとなり、ステップ１３７に進み、行っていなければ、ステップ３０でＮＯとなり、未処理のＤＢバッファについてステップ３０３が実行される。

ステップ１３７で、ＤＢ設定処理部１１５が、パーティション変更指示を準備し、ストレージキャッシュ調整処理部１１７を呼び出すことで、ストレージキャッシュ調整処理部１１７に、パーティション変更指示をストレージシステム３１に送信させる。そのパーティション変更指示には、記憶資源１５に蓄積された全てのパーティション割り当て解除要求と全てのパーティションサイズ拡張要求とが含まれる。

以上が、第三の実施形態のシステム稼動フェーズでＤＢＭＳ１７が実行する処理の説明である。なお、パーティション割り当て解除要求とパーティションサイズ拡張要求とを別々に作成することに代えて、どの削除対象パーティション領域をどの拡張対象パーティション領域に追加するかを指定した要求が作成されても良い。具体的には、例えば、図１９に例示するように、ＤＢ初期設定フェーズでは、上側のストレージキャッシュ制御指示テーブル４０３が送信されたが、システム稼動フェーズでは、下側のストレージキャッシュ制御指示テーブル４０３が、パーティション変更指示と共に送信されても良い。この例によれば、削除対象パーティション領域“DBBuff3”（図１３によれば、バッファヒット率１００のＤＢバッファ“DBBuff3”に対応付けられているキャッシュパーティション領域）のパーティションサイズ３２ＭＢ（メガバイト）のうちの３１ＭＢと、削除対象パーティション領域“DBBuff4”（図１３によれば、バッファヒット率１００のＤＢバッファ“DBBuff4”に対応付けられているキャッシュパーティション領域）のパーティションサイズ４８ＭＢのうちの４７ＭＢとを（つまり合計７８ＭＢを）、拡張対象パーティション領域“DBBuff1”のパーティションサイズ１００ＭＢに加えることにより、その拡張対象パーティション領域“DBBuff1”のパーティションサイズを１７８ＭＢに拡張することが、ＤＢＭＳ１７からストレージシステム３１に指示される。

ストレージシステム３１では、キャッシュパーティション管理部３２５が、そのパーティション変更指示を受けて、図１５を参照して説明したステップ１４２以降の処理を行う。その処理では、例えば、ステップ１４２において、拡張対象パーティション領域については、拡張サイズ分のブロックを確保する処理を実行することができる。また、例えば、全てのパーティション割り当て解除要求に従う処理の後で、各パーティションサイズ拡張要求に従う処理を実行しても良いし、削除対象パーティション領域の削除と並行してパーティションサイズ拡張要求を処理しても良い。別の言い方をすれば、削除対象パーティション領域を、どのＤＢバッファにも割り当てられていない領域（共有キャッシュ領域）に加えた後に、共有キャッシュ領域から拡張サイズ分を拡張対象パーティション領域に加えても良いし、共有キャッシュ領域に加えることなく直接、削除対象パーティション領域の拡張サイズ分（足りなければ、他の削除対象パーティション領域の全部又は一部を含めて）、拡張対象パーティション領域に加えても良い。これによれは、変更対象パーティション領域として、削除対象パーティション領域或いは共有キャッシュ領域となり、変更先パーティション領域として、共有キャッシュ領域或いは拡張対象パーティション領域となる。

変更対象パーティション領域を変更先パーティション領域に追加する場合、変更対象パーティション領域のセグメントサイズと変更先パーティション領域のセグメントサイズとが異なる場合がある。この場合には、所定のタイミング（例えば、ステップ１４２とステップ１４３の間）で、変更対象パーティション領域のセグメントサイズを変更先パーティション領域のセグメントサイズに変更するセグメント変更処理を実行することができる。そのセグメント変更処理では、例えば、変更対象パーティション領域の各セグメントを構成するサブセグメントの数を、変更後のセグメントサイズを基に減らし或いは増やすことで、変更対象パーティション領域のセグメントサイズを変更先パーティション領域のセグメントサイズに一致させることができる。より具体的には、例えば、文献５に開示の技術を応用しても良い。

以上の一連の処理により、システム稼動フェーズでは、削除対象パーティション領域を拡張対象パーティション領域に追加することができる。これにより、拡張対象パーティション領域でのキャッシュヒット率を向上させることができる。

なお、ＤＢＭＳ１７が削除サイズ分（一以上の削除対象パーティション領域の各削除分の合計）の領域を一以上の拡張対象パーティション領域にどう割り振らせるかは様々な態様を採り得る。例えば、削除サイズ分の領域を一つの拡張対象パーティション領域（例えば、バッファヒット率が最も低いＤＢバッファに対応したパーティション領域）に割り振っても良いし、削除サイズ分の領域を均等に複数の拡張対象パーティションに割り振っても良いし、削除サイズ分の領域を各バッファヒット率に基づく比率で複数の拡張対象パーティションに割り振っても良い。「各バッファヒット率に基づく比率」としては、例えば、バッファヒット率の逆数の比を基にした比率として良い。具体的には、例えば、第一の拡張対象パーティション領域に対応したバッファヒット率が８０であり、第二の拡張対象パーティション領域に対応したバッファヒット率が４０の場合、バッファヒット率の比は２：１のため、逆数の比は、１：２となる。削除サイズを９０とした場合、９０×１／３＝３０が、第一の拡張対象パーティション領域に割り振られ、９０×２／３＝６０が、第二の拡張対象パーティション領域に割り振られる。こうすることで、バッファヒット率が低いＤＢバッファに対応した拡張対象パーティション領域には、バッファヒット率が高いＤＢバッファに対応した拡張対象パーティション領域に比してより多くの領域が割当てられるので、キャッシュヒット率の低下を抑えることが期待できる。

＜第四の実施形態＞。

第四実施形態では、複数のＤＢ領域及びそれにそれぞれ対応する複数のＬＵに一つのＤＢバッファが対応付けられる。この場合、ＤＢバッファ−ディスクマッピングテーブル４０１は、例えば図２０Ａに例示するテーブルになり、ストレージキャッシュ制御指示テーブル４０３は、例えば図２０Ｂに例示するテーブルになる。図２０Ａ及び図２０Ｂでは、上記一つのＤＢバッファは、ＤＢバッファ“DBBuff5”である。

これは、例えば、図２０Ｃに例示するＤＢバッファ定義文により定義することができる。すなわち、ＤＢバッファ“DBBuff5”に対して、ＤＢ領域のＤＢ領域名を記載するのではなく、明示的に指定されないＤＢ領域を指定することを意味する文字列（例えば“Others”）を記載することで、定義することができる。ＤＢ設定処理部１１５は、その文字列を検出した場合には、その文字列に対応したＤＢバッファに、ＤＢ領域定義文には記述されているがＤＢバッファ定義文には記述されていない全てのＤＢ領域名のＤＢ領域を対応付けることができる。

なお、一つのキャッシュパーティション領域には、一つのＬＵが割当てられるが（言い換えれば、例えば、複数のＬＵのそれぞれ対して複数のキャッシュパーティション領域が排他的に割当てられるが）、この第四の実施形態では、複数のＤＢ領域が対応付けられるキャッシュパーティション領域には、複数のＬＵが割当てられる。

以上、本発明の幾つかの実施形態を説明したが、これらは本発明の説明のための例示であって、本発明の範囲をこれらの実施形態にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実施することが可能である。例えば、ＤＢＭＳ１７からストレージ管理部１４１を経由して或いは経由しないでストレージシステム３１が受信した各指示は、一旦、ストレージシステム３１における記憶資源に設けられた専用の記憶域（例えば、ＬＵ或いはメモリ領域）に蓄積し、該専用の記憶域から取得して解析しても良い。また、例えば、ホストコンピュータ１１は、いわゆるブレードサーバとしてストレージシステム３１に搭載されてもよい。

図１は、本発明の第一の実施形態に係るシステム全体の構成を示す。 図２は、ホストコンピュータ１１、ストレージシステム３１及び管理コンピュータ４１の機能説明図である。 図３は、キャッシュパーティション領域の物理構成と論理構成の対応関係を示している。 図４は、セグメントと親サブセグメント管理ブロック及び子サブセグメント管理ブロックとの対応関係を示している。 図５Ａは、ストレージ管理部１４１が表示する第一のＧＵＩを示す。図５Ｂは、第一のＧＵＩで所定の操作がされた場合にストレージ管理部１４１が表示する第二のＧＵＩを示す。 図６は、ＤＢアクセス環境の構成例を示す。 図７Ａは、ＤＢ領域定義文の一例を示す。図７Ｂは、ＤＢバッファ定義文の一例を示す。 図８Ａは、ＤＢバッファ−ディスクマッピングテーブル４０１の構成例を示す。図８Ｂは、ストレージキャッシュ制御指示テーブル４０３の構成例を示す。 図９は、ストレージキャッシュ−ディスクマッピングテーブルの構成例を示す。 図１０は、ＤＢ初期設定フェーズにおいてＤＢＭＳ１７で実行されるＤＢバッファ構築処理の流れの一例を示す。 図１１は、キャッシュグループ初期割当指示を受信したストレージシステム３１において実行される処理の流れの一例を示す。 図１２は、パーティション設定処理の流れの一例を示す。 図１３は、初期設定時でのバッファヒット管理テーブル５０１の例と、時刻Ｔの時点でのバッファヒット管理テーブル５０１の例を示す。 図１４は、システム稼動フェーズでＤＢＭＳ１７により実行される処理の流れの一例を示す。 図１５は、パーティション変更指示を受信したストレージシステム３１において行われる処理の流れの一例を示す。 図１６Ａは、ストレージキャッシュ３１１の論理分割の第一の例を示す。図１６Ｂは、ストレージキャッシュ３１１の論理分割の第二の例を示す。 図１７は、第二の実施形態において、キャッシュグループ初期割当指示を受信したストレージシステム３１において実行される処理の流れの一例を示す。 図１８は、第三の実施形態のシステム稼動フェーズでＤＢＭＳ１７により実行される処理の流れの一例を示す。 図１９は、パーティションサイズの変更前と変更後のそれぞれのストレージキャッシュ制御指示テーブル４０３の例を示す。 図２０Ａは、本発明の第四の実施形態でのＤＢバッファ−ディスクマッピングテーブル４０１の例を示す。図２０Ｂは、第四の実施形態でのストレージキャッシュ制御指示テーブル４０３の例を示す。図２０Ｃは、第四の実施形態でのＤＢバッファ定義文の例を示す。

符号の説明

１１…ホストコンピュータ １７…ＤＢＭＳ ４１…管理コンピュータ １１１…ＤＢアクセス制御部 １１３…ＤＢバッファ群 １１４…ＤＢバッファ １１５…ＤＢ設定処理部 １１７…ストレージキャッシュ調整処理部 １４１…ストレージ管理部 ３１１…ストレージキャッシュ ３１５…ディスク制御部 ３２１…データ転送制御部 ３２３…ホストＩ／Ｆ制御部 ３２５…キャッシュパーティション管理部

Claims (19)

1. キャッシュメモリを論理的に分割することにより得られた複数のキャッシュパーティション領域の各々を複数の記憶装置の各々に対して割り当てることを外部からのパーティション設定指示に応答して実行するストレージシステムに接続されたホストコンピュータで動作するデータベース管理システムであって、
   各データベースバッファに関するサイズを基に、該各データベースバッファに対応付ける各キャッシュパーティション領域に関するサイズを決定し、決定したサイズで該各キャッシュパーティション領域に関する設定を行うことのパーティション設定指示を作成する設定処理部と、
   前記作成されたパーティション設定指示を送信する指示送信部と
   を備えるデータベース管理システム。
2. 前記各データベースバッファに関するサイズとは、該各データベースバッファについて、データベースバッファを構成する記憶領域でありアクセス単位であるページのサイズであり、
   前記各キャッシュパーティション領域に関するサイズとは、該各キャッシュパーティション領域について、キャッシュパーティション領域を構成する記憶領域でありアクセス単位であるセグメントのサイズであり、
   前記設定処理部は、前記各キャッシュパーティション領域のセグメントサイズを、該各キャッシュパーティション領域に対応付けられる各データベースバッファのページサイズと同じサイズに決定する、
   請求項１記載のデータベース管理システム。
3. 前記各データベースバッファに関するサイズとは、更に、該各データベースバッファについて、データベースバッファそれ自体のサイズであるバッファサイズであり、
   前記各キャッシュパーティション領域に関するサイズとは、更に、該各キャッシュパーティション領域について、キャッシュパーティション領域それ自体のサイズであるパーティションサイズであり、
   前記設定処理部は、初期設定の際、前記各キャッシュパーティション領域のパーティションサイズを、該各キャッシュパーティション領域に対応付けられる各データベースバッファのバッファサイズと同じサイズに決定する、
   請求項２記載のデータベース管理システム。
4. 前記ストレージシステムは、前記パーティション設定指示を受信した場合、該パーティション設定指示で指定されている複数のパーティションサイズの合計よりも前記キャッシュメモリにおける空き領域サイズが少ない場合には、エラー報告を、該パーティション設定指示の送信元に返信するよう構成されており、
   前記設定処理部は、前記エラー報告を受信した場合には、前記複数のパーティションサイズの合計が前記空き領域サイズ以下になるようキャッシュパーティション領域の数及びサイズのうちの少なくとも一方を調整したパーティション設定指示を新たに作成し、
   前記指示送信部が、前記新たに作成されたパーティション設定指示を送信する、
   請求項３記載のデータベース管理システム。
5. 前記設定処理部は、前記複数のパーティションサイズをそれぞれ同じ縮小率で縮小することにより該複数のパーティションサイズの合計を前記空き領域サイズ以下になるよう調整する、
   請求項４記載のデータベース管理システム。
6. 前記ストレージシステムは、前記パーティション設定指示を受信した場合、該パーティション設定指示で指定されている複数のパーティションサイズの合計よりも前記キャッシュメモリにおける空き領域サイズが少ない場合には、エラー報告を、該パーティション設定指示の送信元に返信するよう構成されており、
   前記設定処理部は、エラー報告の要否をユーザから受け付け、エラー報告を必要とするか否かを表すエラー要否情報を前記パーティション設定指示に含める、
   請求項３記載のデータベース管理システム。
7. 前記データベース管理システムで管理される複数のデータベース領域に前記複数のデータベースバッファがそれぞれ対応付けられており、前記データベース管理システムが、各データベース領域へのアクセスを実行するアクセス制御部を更に備え、該アクセス制御部は、或るデータベース領域へのアクセスを実行する場合、該或るデータベース領域に対応したデータベースバッファである当該データベースバッファでバッファヒットした場合には、バッファヒットで確保された領域にアクセスし、バッファヒットしなった場合に、前記当該データベースバッファに対応付けられたキャッシュパーティション領域に割当てられている記憶装置を指定したアクセスコマンドが前記ホストコンピュータから前記ストレージシステムに送信され、前記ストレージシステムが、該アクセスコマンドに従うデータを、該アクセスコマンドで指定されている記憶装置が割当てられたキャッシュパーティション領域に一時格納するようになっており、
   前記アクセス制御部が、各データベースバッファについて、データベースバッファへのアクセス回数のうちのバッファヒットした回数を表すバッファヒット率を算出し、
   前記設定処理部が、各データベースバッファの前記算出されたバッファヒット率に基づいて、前記パーティション設定指示として、前記複数のキャッシュパーティション領域のうちの少なくとも一つに関するサイズの設定変更を意味する指示を作成する、
   請求項１記載のデータベース管理システム。
8. 前記設定処理部は、前記パーティション設定指示として、バッファヒット率が所定閾値以上のデータベースバッファに対応付けられたキャッシュパーティション領域の全部又は一部を前記キャッシュメモリから削除することの意味である削除意味を含んだ指示を作成する、
   請求項７記載のデータベース管理システム。
9. 前記設定処理部は、前記パーティション設定指示として、前記削除される領域サイズ分の領域を前記複数のキャッシュパーティション領域のうちの他のキャッシュパーティション領域に追加することの意味である追加意味を含んだ指示を作成する、
   請求項８記載のデータベース管理システム。
10. 前記設定処理部は、前記他のキャッシュパーティション領域として、最もバッファヒット率の低いデータベースバッファに対応付けられているキャッシュパーティション領域を、前記パーティション設定指示において指定する、
    請求項９記載のデータベース管理システム。
11. バッファヒット率が所定閾値未満である二以上のデータベースバッファにそれぞれ対応付けられた二以上のキャッシュパーティション領域の各々が、前記他のキャッシュパーティション領域であり、
    前記設定処理部は、前記二以上のデータベースバッファの各々のバッファヒット率を基に、前記二以上のキャッシュパーティション領域の各々に対応した割当て比率を決定し、前記追加意味として、各他のキャッシュパーティション領域について、前記削除される領域サイズ分の領域のうちの前記決定した割当て比率分の領域を追加することの意味を含める、
    請求項９記載のデータベース管理システム。
12. 前記設定処理部は、バッファヒット率が低いデータベースバッファに対応付けられているキャッシュパーティション領域の前記割当て比率を、バッファヒット率が高いデータベースバッファに対応付けられているキャッシュパーティション領域の前記割当て比率よりも高い比率にする、
    請求項１１記載のデータベース管理システム。
13. ストレージシステムとホストコンピュータとを備えたコンピュータシステムにおいて、
    前記ストレージシステムが、複数の記憶装置と、キャッシュメモリと、制御部とを有し、前記制御部が、前記キャッシュメモリを論理的に分割することで得られた複数のキャッシュパーティション領域が用意されている場合、前記ホストコンピュータから、前記複数の記憶装置のうちの或る記憶装置を指定したアクセスコマンドを受信したならば、前記複数のキャッシュパーティション領域のうちの該或る記憶装置が割当てられたキャッシュパーティション領域に、該アクセスコマンドでのアクセス対象となるデータを一時的に記憶させるよう構成されており、
    前記ホストコンピュータが、データベース管理システムを有し、
    前記データベース管理システムが、
    各データベースバッファに関するサイズを基に、該各データベースバッファに対応付ける各キャッシュパーティション領域に関するサイズを決定し、決定したサイズで該各キャッシュパーティション領域に関する設定を行うことのパーティション設定指示を作成する設定処理部と、
    前記作成されたパーティション設定指示を送信する指示送信部と
    を備え、
    前記ストレージシステムの前記制御部が、前記指示送信部から送信されたパーティション設定指示を受信し、該パーティション設定指示に従って、前記キャッシュメモリを論理的に分割することで複数のキャッシュパーティション領域を用意し、該複数のキャッシュパーティション領域の各々に前記複数の記憶装置のいずれかを割当てる、
    コンピュータシステム。
14. 前記各データベースバッファに関するサイズとは、該各データベースバッファについて、データベースバッファを構成する記憶領域でありアクセス単位であるページのサイズと、該各データベースバッファについて、データベースバッファそれ自体のサイズであるバッファサイズとの両方であり、
    前記各キャッシュパーティション領域に関するサイズとは、該各キャッシュパーティション領域について、キャッシュパーティション領域を構成する記憶領域でありアクセス単位であるセグメントのサイズと、キャッシュパーティション領域それ自体のサイズであるパーティションサイズとの両方であり、
    前記設定処理部は、前記各キャッシュパーティション領域のセグメントサイズを、該各キャッシュパーティション領域に対応付けられる各データベースバッファのページサイズと同じサイズに決定し、且つ、初期設定の際であれば、前記各キャッシュパーティション領域のパーティションサイズを、該各キャッシュパーティション領域に対応付けられる各データベースバッファのバッファサイズと同じサイズに決定する、
    請求項１３記載のコンピュータシステム。
15. 前記ストレージシステムの前記制御部は、前記パーティション設定指示を受信した場合、該パーティション設定指示で指定されている複数のパーティションサイズの合計よりも前記キャッシュメモリにおける空き領域サイズが少ない場合には、前記複数のパーティションサイズの合計が前記空き領域サイズ以下になるようキャッシュパーティション領域の数及びサイズのうちの少なくとも一方を調整し、調整後の数及び／又はサイズで二以上のキャッシュパーティション領域を用意する、
    請求項１４記載のコンピュータシステム。
16. 前記データベース管理システムで管理される複数のデータベース領域に前記複数のデータベースバッファがそれぞれ対応付けられており、前記データベース管理システムが、各データベース領域へのアクセスを実行するアクセス制御部を更に備え、該アクセス制御部は、或るデータベース領域へのアクセスを実行する場合、該或るデータベース領域に対応したデータベースバッファである当該データベースバッファでバッファヒットした場合には、バッファヒットで確保された領域にアクセスし、バッファヒットしなった場合に、前記当該データベースバッファに対応付けられたキャッシュパーティション領域に割当てられている記憶装置を指定したアクセスコマンドが前記ホストコンピュータから前記ストレージシステムに送信され、前記ストレージシステムが、該アクセスコマンドに従うデータを、該アクセスコマンドで指定されている記憶装置が割当てられたキャッシュパーティション領域の、キャッシュヒットにより確保された領域に一時格納するようになっており、
    前記アクセス制御部が、各データベースバッファについて、データベースバッファへのアクセス回数のうちのバッファヒットした回数を表すバッファヒット率を算出し、
    前記設定処理部が、各データベースバッファの前記算出されたバッファヒット率に基づいて、前記パーティション設定指示として、前記複数のキャッシュパーティション領域のうちの少なくとも一つに関するサイズの設定変更を意味する指示を作成し、
    前記ストレージシステムの前記制御部が、前記パーティション設定指示に従って、前記複数のキャッシュパーティション領域のうちの少なくとも一つに関するサイズの設定変更を行う、
    請求項１４記載のコンピュータシステム。
17. 前記ストレージシステムの前記制御部は、前記設定変更として、バッファヒット率が所定閾値以上のデータベースバッファに対応付けられたキャッシュパーティション領域の全部又は一部を前記キャッシュメモリから削除する、
    請求項１６記載のコンピュータシステム。
18. 前記ストレージシステムの前記制御部は、前記設定変更として、前記削除された領域サイズ分の領域を前記複数のキャッシュパーティション領域のうちの他のキャッシュパーティション領域に追加する、
    請求項１７記載のコンピュータシステム。
19. データベース管理システムが、各データベースバッファに関するサイズを基に、該各データベースバッファに対応付ける各キャッシュパーティション領域に関するサイズを決定し、
    データベース管理システムが、決定したサイズで該各キャッシュパーティション領域に関する設定を行うことのパーティション設定指示を作成し、
    データベース管理システムが、前記作成されたパーティション設定指示を送信し、
    ストレージシステムが、前記パーティション設定指示を受信し、該パーティション設定指示に従って、前記キャッシュメモリを論理的に分割することで複数のキャッシュパーティション領域を用意し、該複数のキャッシュパーティション領域の各々に前記複数の記憶装置のいずれかを割当てる、
    キャッシュ論理分割方法。

Images