(57)【要約】  【課題】データベースアクセス要求に応じて適切なロックの階層を選択する排他制御方法を提供する。  【解決手段】データベースを構成する論理的な階層資源に対して排他制御を行う場合、データベースアクセス中に発生するロック・エスカレーションをデータベース・アクセス方法及び選択率により予測して、エスカレーションの可能性がある場合にはあらかじめ細分性の大きい資源に対してロックを割当て、エスカレーション前のロックのオーバヘッドを軽減する。【選択図】図１
2004253003.tif 000002
【特許請求の範囲】
【請求項１】
データベースを構成する論理的な階層資源に対して上位層、すなわち、細分性の大きい資源からロックを取得していく排他制御方法において、前記データベースに対するアクセス要求より決定したアクセス対象となる表のアクセス方法に応じて、前記階層資源の中から適切な細分性の小さい排他資源を決定し、前記決定された排他資源に対して割当可能なロックの数の限界を設定し、前記排他資源に対して割り当てられたロックの数が前記設定されたロックの数の限界に達した時、細分性の小さなロックを撤回し、資源上の細分性の大きなロックに昇格することを特徴とする排他制御方法。
【請求項２】
データベースを構成する論理的な階層資源に対してロックを取得していく排他制御方法において、前記データベースに対するアクセス要求より最適化処理で決定したアクセス対象となる表のアクセス方法に応じて、前記階層資源の中から適切な細分性の小さい排他資源を決定し、前記決定された排他資源に対して割当可能なロックの数の限界を設定し、前記排他資源に対して割り当てられたロックの数が前記設定されたロックの数の限界に達した時、細分性の小さなロックを撤回し、資源上の細分性の大きなロックに昇格することを特徴とする排他制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は多重処理環境内での資源及びロックの管理方法に係り、特に、階層的な構造をなす資源に対するロックの細分性を選択し、ロック・エスカレーションの管理方法に関する。
【背景技術】
【０００２】
多重処理環境におけるオペレーティングシステムおよびデータベース管理システムのロック管理部分は、処理のための資源に対してロックの割当および解放を行う。
【０００３】
データベース管理システム、特に、リレーショナル・データベース管理システム（ＲＤＢＭＳ）は、データベース，スキーマ，表，行といったように論理的に階層的な資源で構成される。表と行との間には、物理的に行を格納するための記憶装置である磁気ディスクなどの場合、行を物理的に固定長のブロックあるいはページという単位に格納される。この場合、管理資源は、表と行との間にページが資源として管理されることになる。
【０００４】
データベースをアクセスする場合、ユーザは一般にＳＱＬ(ＩＳＯ  ９０８５)というデータベース問い合わせ言語を利用して行う。ユーザは、ＳＱＬにおいてアクセスしたい表を指定し、表を構成する複数の列に対して探索条件を指定することによって、検索を行ったり、更新を行ったりすることができる。その場合、ＲＤＢＭＳは指定された表に対して細分性の大きい資源（表）から小さい資源（ページまたは行）に対して階層的にロックを割り当てていく。もし、ある階層の資源に対して排他的なロックが割り当てられていれば、その資源に対する排他的ロックが解放されるまで待たされるか処理が禁止されることになる。
【０００５】
したがって、検索のような処理の場合には、ロックのモードは参照が主体であるから共用モードでのロックとなり、同じ他の検索を行う処理とは同時実行性が向上する。ただし、同じ表に対するアクセスに検索を行う処理と更新を行う処理とが混在する場合には、表単位でロックを行ってしまうと同時実行性が損なわれることになるので、できるだけ細分性の小さい資源に対してロックを割り当てることによって同時実行性を向上できる。
【０００６】
しかし、ロックを管理するための情報を管理するためにもある程度のメモリを要するため、細分性の小さい資源に対して一定のロックが割り当てられた場合には、細分性の大きい資源にロックをエスカレーションすることによってメモリを節約する手段がとられる。これらのロック管理方法およびロック・エスカレーションに関しては、非特許文献１に記述されている。ロックをエスカレーションさせる場合、たとえばあるユーザがある表内の多くの行のロックを割り当てると、行のロックを表のロックにエスカレーションさせることになる。しかし、この方法ではエスカレーションさせるためのロックの数の限界値が大きく設定されていれば同時実行性は向上する見込みがあるが、限界値を小さく設定してしまうとエスカレーションしてしまうことによって他ユーザの処理が受け入れられなくなってしまうという問題を持つ。又、限界値を大きく設定してしまうと、ロックを管理するためのロック管理テーブルに要するメモリ量が増大することにもなるという問題を持つ。
【０００７】
一方、ＲＤＢＭＳでは、ユーザから与えられたデータベース問い合わせ言語（ＳＱＬ）を解析し、最適なアクセス・パスを選択し、効率よくデータベースにアクセスするようにする。このとき、ＲＤＢＭＳは、最適なアクセスパスを選択するために、アクセス対象となる表に指定された探索条件中の列のデータの分布情報を基にデータベースを高速にアクセスするためのインデクスを利用するか否かを決定することができる。列のデータの分布情報の取得方法については、非特許文献２に記述されている。また、こういったデータの分布情報を使用しない場合でも、アクセスパスは様々な手法がとられる。もし、選択したアクセスパスが表の順次スキャンを行う場合には、前述したように取り出した行に対してロックを取得していくため、ロックの数の限界値に達成すると表のロックにエスカレーションしてしまうことになる。このとき、他ユーザが同じ表に対して小量のデータの更新を
行いたい場合には、エスカレーションされてしまうと検索を行っているユーザが処理を終了しない限り処理を待たされるか処理を中断されてしまうことになり、同時実行性が損なわれる。
【０００８】
【非特許文献１】モルガン  カウフマン  パブリッシャ（MORGAN KAUFMANN    PUBLISHERS）発行のジム  グレイ，アンドレアス  ロイター著，「トランザクション  プロセッシング：コンセプト  アンド  テクニックス（JIM GRAY,ANDREAS REUTER著「TRANSACTION PROCESSING：CONCEPTS AND TECHNIQUES」,pp419−421，1993年）
【非特許文献２】グレゴリ，ピアテツキ，シャピロ（Gregory Piatetsky Shapiro 等による１９８４年ＡＣＭ−ＳＩＧＭＯＤ国際会議資料  アキュレート  エスティメーション  オブザ  ナンバーオブ  タプルス  サティスファイイング  ア  コンディション  『ACCURATE ESTIMATION OF THE NUMBER OF TUPLES SATISFYING A CONDITION』
【発明の開示】
【発明が解決しようとする課題】
【０００９】
本発明の目的は、非同期並行処理の実行を支援するシステムのスループットを増大させることにある。また、非同期並行処理および共用可能な資源間で同時実行性およびロック細分性を効率的に管理するための方法を提供することにある。
特に、リレーショナルデータベース管理システム内でのロック管理による同時実行性を向上するための方法を提供することにある。
【課題を解決するための手段】
【００１０】
上記目的を達成するために、本発明の排他制御方法では、データベースを構成する論理的な階層資源に対して上位層すなわち細分性の大きい資源からロックを取得していく排他制御方法において、データベースに対するアクセス要求を基に決定したアクセス方法に応じて、前記階層資源の中から適切な細分性の小さい排他資源を決定し、前記決定された排他資源に対して割当可能なロックの数の限界を設定し、前記排他資源に対して割り当てられたロックの数が前記設定されたロックの数の限界に達した時、細分性の小さなロックを撤回し、資源上の細分性の大きなロックに昇格することを特徴とする排他制御管理方法によって解決される。
【００１１】
また、異なる別の手段は、データベースを構成する論理的な階層資源に対して上位層からロックを取得していく排他制御方法において、データベースに対するアクセス要求解析時にデータベース・アクセス選択率に応じて、前記階層資源の中から適切な細分性の小さい排他資源を決定し、前記決定された排他資源に対して割当可能なロックの数の限界を設定し、前記排他資源に対して割り当てられたロックの数が前記設定されたロックの数の限界に達した時、細分性の小さなロックを撤回し、資源上の細分性の大きなロックに昇格することを特徴とする排他制御管理方法によっても達成される。
【００１２】
ＲＤＢＭＳでは、データベース問い合わせ言語によりある表に対する検索要求がなされると、その問い合わせ要求に応じたアクセス・パス決定時に決定したアクセス・パスに応じてロックの細分性（行，ページまたは表）を決定する。決定されたロックの細分性に応じてロックを取得していき、ロックの細分性に達した時点で当該トランザクションのロックの数が限界値に達すると上位のロックの細分性に昇格する。たとえば、ロックの細分性をページに決定すると処理ではページより細分性の小さい行に対するロックは取得せず、ページのロックまで取得し、ページに対するロックを取得していき、ページ・ロックの数が限界値に達すると上位の細分性の資源である表にロックをエスカレーションさせる。これにより、処理ではより細分性の小さい資源である行に対してロックを取得しないのでロ
ック管理テーブルのメモリ量を圧迫しなくて済む。
【００１３】
また、データベース問い合わせ言語によりある表に対する検索要求がなされると、その問い合わせ要求に応じたアクセス・パス決定時にデータの分布情報からヒット率を予測し、予測されるヒット率に応じてロックの細分性（行，ページまたは表）を決定する。決定されたロックの細分性に応じてロックを取得していき、ロックの細分性に達した時点でトランザクションのロックの数が限界値に達すると上位のロックの細分性に昇格する。たとえば、ロックの細分性をページに決定すると処理ではページより細分性の小さい行に対するロックは取得せず、ページのロックまで取得し、ページに対するロックを取得していき、ページ・ロックの数が限界値に達すると上位の細分性の資源である表にロックをエスカレーションさせる。もし、ヒット率が低いと予測される場合には、ロックの細分性を行に
決定することによって、処理では行に対するロックを取得していく。ここで、ヒット率の予測を過ったとしても行のロックの数が限界値に達するとページ・ロックにエスカレーションさせることができる。
【発明の効果】
【００１４】
本発明によれば、データベース管理システムのように多重処理による同時実行性が要求されるシステムではあらかじめロック・エスカレーションが予測される処理要求に対してロックサイズを大きくすることにより、共用される資源のロックを管理するための情報が必要とするメモリ量を抑えるので、システム全体のスループット向上を損なうのを抑制できる。また、ロックサイズを複数用意しておけば、ロックの細分性の小さい資源から大きい資源へのエスカレーションを多段階にできるため同時実行性を損なうのを抑制できることにもなる。
【発明を実施するための最良の形態】
【００１５】
図２は、本発明の一実施例にかかるデータベースシステムの構成を示す。図２において、１はＣＰＵ、２は主記憶装置、３は磁気ディスク等の外部記憶装置である。主記憶装置２上には、データベース管理システム２０が置かれ、外部記憶装置３上にはデータベース管理システム２０が管理するデータベース３０が格納される。
【００１６】
データベース３０には、図３に示すようにユーザが作成した表３１があって、表３１は物理的に固定長の複数のページ３２の集合をなしており、ページ３２には複数の行３３が格納される。また、データベース３０中にはこれらの表定義情報や表のある特定の列に関するデータの分布情報を管理するディクショナリ情報が格納される。
【００１７】
データベース管理システム２０では、ユーザからのデータベース問い合わせ要求であるＳＱＬを受け取り、構文解析意味解析処理を通してデータベースアクセスの最適なアクセス経路を決定する最適化処理が行われ、決定したアクセス経路に基づいてデータベース処理用の内部処理コードが生成される。こうして生成された内部処理コードを基にデータベース・アクセスを行う。データベース・アクセス時には、外部記憶装置３上に格納されたデータベース３０中の表３１からデータを主記憶装置２上に入力して処理を行う。データベース処理では、複数のユーザからのデータベース・アクセス要求に対応するため、処理対象となるデータベース資源である表や行に対する排他制御が行われる。
【００１８】
排他制御処理は、基本的にユーザからのデータベース・アクセス要求に応じて、排他制御モードが設定される。例えば、ＳＱＬによってＳＥＬＥＣＴ文が指定されたならば設定される排他モードは共用モードであり、ＩＮＳＥＲＴ，UPDATE，ＤＥＬＥＴＥ文が指定されたならば排他モードが設定される。例外的には、ＳＱＬのＬＯＣＫ文を使えば、たとえ要求されたデータベース処理要求がSELECT文のような検索処理要求でも排他モードにすることが可能である。
【００１９】
排他制御モードには、これらの他に意図共用モードおよび意図排他モードが用意されていることが多い。意図共用モードや意図排他モードは、表に対する複数のユーザからのデータベース処理要求に検索処理と更新処理が混在する場合に同時実行性を上げるために使用される。例えば、あるユーザが表Ｔ１中の特定の行のみを更新する場合、他のユーザに更新対象となっている行以外の行は参照を許したいならば表に対して意図排他モードによるロックを割当て、他のユーザが検索処理を行いたい場合は意図共用モードで表にロックを割り当てることができる。
【００２０】
したがって、実際に処理対象となる行には共用モードあるいは排他モードのように意図共用モードおよび意図排他モードより強いモードでロックを割り当てることになる。もし、万一先に有るユーザのデータベース処理要求によってある行に対して排他モードが割り当てられると後から異なるユーザのデータベース処理要求によって同じ行に対して共用モードあるいは排他モードを割り当てようとするとロック待ちとなるか処理が禁止されることになる。これらの、排他制御モードによる同時実行性を図４に示す。
【００２１】
図１は、本発明によるユーザからのデータベース処理要求をデータベース管理システム２０が解析し、アクセス・パス選択時にデータベース処理要求でアクセスする表に対してロックの細分性（ロック・サイズという）を決定する処理のデータフローを示す。まず、アクセス・パス決定を行う最適化処理で決定したアクセス方法（スキャンタイプという）を判定する（ステップ２１）。
【００２２】
スキャン・タイプがテーブル・スキャンの場合、すなわち、表のデータを、順次、検索する場合、ロックサイズを表にする（ステップ２２）。ロックサイズを表にすることによって、実際のデータベース・アクセス時には、表よりロックの細分性の小さい資源である行にはロックを割り当てないようにする。
【００２３】
また、スキャン・タイプがテーブル・スキャン以外の場合、すなわち、インデクスを利用した検索を行うような場合にはロック・サイズを行にする（ステップ２３）。ロックサイズを行にすることによって、実際のデータベース・アクセス時には、表よりロックの細分性の小さい資源である行にロックを割り当てるようにする。この場合、表に対しては意図共用モードまたは意図排他モードのロックを割り当てるようにする。
【００２４】
図１に示したロックサイズ決定処理により決定したロックサイズによって、データベース処理がどのように行われるかについて図５に概略処理フローチャートを示す。
【００２５】
データベース処理が開始されると、まず処理対象となる表に対するロックサイズを判定する（ステップ４１）。
【００２６】
ロックサイズが表に設定されている場合は、表に対して指定された排他制御モードによって共用モードまたは排他モードを割り当てる（ステップ４２）。もし、ロックサイズが表でない場合、すなわち、ロックサイズが行である場合には、表に対して意図共用モードまたは意図排他モードを割り当てる(ステップ４３)。
【００２７】
こうして、表に対して適切なロックが割り当てられると処理対象となる行の入力を行う（ステップ４４）。
【００２８】
行の入力を行うと再度ロックサイズを判定し（ステップ４５）、ロックサイズが行の場合は処理対象となる行に対してロックを割り当てるためロック要求を行う（ステップ４６）。
【００２９】
行にロックを割り当てる場合、表に対して意図共用モードでロックを割り当てていれば共用モードでロックを割り当て、表に対して意図排他モードでロックを割り当てていれば排他モードでロックを割り当てる。そして、行に対してロックが割り当てられると、現在処理中のトランザクションが表に対して割り当てた行のロック数がロック割り当ての上限を越えたか否かを判定する(ステップ４７)。
【００３０】
もし、まだロック数が上限を越えていなければロック数を１増加させる（ステップ４８）。
【００３１】
割り当てたロック数が上限を越えたならば、ロックをロックの細分性の大きい表にエスカレーションさせる（ステップ４９）。
【００３２】
ただし、いかなる場合でもロックをエスカレーションできるわけではない。現在処理中の表に対して他ユーザの処理によってある行に排他モードでロックが割り当てられているような場合には、ロックをエスカレーションできない。ここでは、ロックが表にエスカレーションされた場合、ロック・サイズは行から表に変更される。
【００３３】
こうして、行に対してロックが割り当てられると行の参照あるいは更新処理が行われる（ステップ５０）。ステップ４５によるロックサイズの判定により、ロックサイズが表である場合、行に対するロックは割り当てずに行の参照あるいは更新処理を行う（ステップ５０）。
【００３４】
ある行に対して処理が終了すると処理対象となる表中のすべての対象となる行の処理を終了したか否かを判定し（ステップ５１）、まだ終了していなければステップ４４に戻る。処理が終了すると、データベース処理が終了し、コミットされるまでロックが保持され、コミットされるとロックを解放する。
【００３５】
本発明による第二のロックサイズ決定処理の実施例を図６に示す。図６は、ユーザからのデータベース処理要求をデータベース管理システム２０が解析し、アクセス・パス選択時に当該データベース処理要求でアクセスする表に対してロックの細分性（ロック・サイズという）を決定する処理のデータフローを示す。
【００３６】
まず、アクセス・パス決定を行う最適化処理では、処理対象となる表に対する探索条件中に指定された列のデータ分布情報をデータベース中のディクショナリ情報から取得し、ヒット率が高いか低いかを判定しながらインデクス利用の可否を決定する。その際、決定されたアクセスパス情報を基にロックサイズを決定する。データ分布情報を基に決定したアクセス方法を判定する（ステップ２４）。
【００３７】
決定したアクセス方法によりヒット率が大きい場合、ロックサイズを表にする（ステップ２５）。
【００３８】
ロックサイズを表にすることによって、実際のデータベース・アクセス時には、表よりロックの細分性の小さい資源である行にはロックを割り当てないようにする。また、決定したアクセス方法によりヒット率が小さい場合、ロック・サイズを行にする（ステップ２６）。
【００３９】
ロックサイズを行にすることによって、実際のデータベース・アクセス時には、表よりロックの細分性の小さい資源である行にロックを割り当てるようにする。この場合、表に対しては意図共用モードまたは意図排他モードのロックを割り当てるようにする。
【００４０】
このように、データベース管理システムではデータベース処理要求に応じてロックサイズをあらかじめ決定しておくので、いずれロック・エスカレーションする可能性のある問い合わせ要求に対し、不必要なロックを割り当てることがなくなる。
【００４１】
以上、本発明を実施例に基づき具体的に説明したが、本発明はこれら実施例に限定されるものではない。たとえば、本実施例では、ロックサイズの設定として表と行を取り上げたが、表とページをロックサイズとしても差し支えない。また、ロックサイズをさらに複数用意し、表，ページ，行あるいは表を格納するための論理的なデータベース領域等を含めた方法にも適用可能である。
【００４２】
また、本発明ではロック・サイズの指定をデータベース管理システムが自動的に決定するが、データベース利用者にとっては自動的に決定されるだけではなく、データベース利用者の指定によってある表に対するアクセス方法がどのように設定されるかによってロック・サイズを決定させる方法をとることも可能である。
【図面の簡単な説明】
【００４３】
【図１】本発明の一実施例のロック・サイズ決定処理の概略処理フローチャート。
【図２】本発明の一実施例の特徴的なシステム構成を示すブロック図。
【図３】本発明の一実施例によるデータベースを構成する資源を示す説明図。
【図４】本発明の一実施例における排他制御の同時実行性のマトリクスを示す説明図。
【図５】本発明の一実施例におけるデータベース管理システムのデータベース処理フローチャート。
【図６】本発明の他の実施例のロック・サイズ決定処理の概略処理フローチャート。
【符号の説明】
【００４４】
１…ＣＰＵ、２…主記憶装置、３…外部記憶装置、２０…データベース管理シ
ステム、３０…データベース、３１…表、３２…ページ、３３…行。
【図１】
2004253003.tif 000003
【図２】
2004253003.tif 000004
【図３】
2004253003.tif 000005
【図４】
2004253003.tif 000006
【図５】
2004253003.tif 000007
【図６】
2004253003.tif 000008