(57)【要約】【課題】データベース管理システムにおける更新処理や検索処理が並列に実行されＤＢバッファのアクセスが集中した場合、ＤＢバッファの整合性を保つため、シリアライズ処理を施す。このため、大量の並列実行によるＤＢバッファのアクセスが発生した場合、このシリアライズ処理の競合によって、ＤＢアクセスの性能に影響を及ぼす。【解決手段】検索処理におけるＤＢバッファのアクセスで、検索プロセス毎にローカライズされた固有バッファを割り当て、そのバッファ上にＤＢバッファの内容をコピーし、検索要求時の同一ページアクセスでは、固有バッファの内容を参照しＤＢアクセス（参照）を実現する。これにより、検索要求毎に発生したＤＢバッファのアクセスが、入力ページ単位でのアクセスになり、ＤＢバッファのアクセス回数が削減されることで、ＤＢバッファ参照時のシリアライズ処理の競合によるアクセス性能の劣化の軽減を実現する。【選択図】　図１
2004030487.tif 000002
【特許請求の範囲】
【請求項１】
データベースを格納する複数の格納領域と、該格納領域単位でデータが読み出されて格納され、該格納されたデータをデータ操作する複数のプログラムによりアクセスされる共有メモリとを備えるデータベース管理システムにおけるデータベース管理方法において、
上記プログラムは、上記共有メモリがロックされていない場合に上記共有メモリをロックし、同じ上記格納領域に格納されておりデータ操作する対象であるデータを読み込んで保持し、上記ロックした共有メモリのロックを解放して上記保持したデータについて上記データ操作を処理することを特徴とするデータベース管理方法。
【請求項２】
上記共有メモリからデータ操作する対象となるデータを読み込む場合、同じ上記領域内に格納されているデータのうち上記データベース上でロックされているか否かを判定し、ロックされていないデータを読み込んで保持することを特徴とする請求項１記載のデータベース管理方法。
【請求項３】
同じ上記領域内に格納されているデータのうち上記データベース上でロックがかかっているか否かを判定し、ロックされている場合はロックされているデータについてデータを特定する識別情報を保持し、ロックの解放後に上記識別情報に対応するデータを共有メモリから読み込んでデータ操作することを特徴とする請求項２記載のデータベース管理方法。
【請求項４】
上記データ操作は、検索、選択および検索結果送出の少なくともいずれかであることを特徴とする請求項１から３記載のいずれかのデータベース管理方法。
【請求項５】
データベースを格納する複数の格納領域と、該格納領域単位でデータが読み出されて格納され、該格納されたデータをデータ操作する複数のプロセッサによりアクセスされる共有メモリとを備えるデータベース管理システムにおいて、
上記プロセッサは、上記共有メモリがロックされていない場合に上記共有メモリをロックして同じ上記格納領域に格納されておりデータ操作する対象となるデータを読み込んで保持する手段と、上記ロックした共有メモリのロックを解放して上記保持したデータについて上記データ操作を処理する手段とを備えることを特徴とするデータベース管理システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、複数のプログラムもしくはプロセッサでデータ操作処理する場合のデータベース管理方法およびシステムに関するものである。
【０００２】
【従来の技術】
データベース管理システムにおいて、更新要求や検索要求によるＤＢの参照、更新を行う場合、データベース管理システムで共有するＤＢバッファを用いてディスクの内容を参照する。更新要求や検索要求によって参照するページが、ＤＢバッファ上に存在する場合、ＤＢバッファの内容を読むことでディスクのＩ／Ｏ回数を軽減する一般的な手段である。しかし、
ＤＢバッファは、データベース管理システムで共有し、その内容を他のプロセスからのＤＢバッファ参照要求に対して整合性を確保するためシリアライズする手段をとる。
【０００３】
例えば、検索要求におけるＤＢバッファの参照要求で、ＤＢ内の要求ページをＤＢバッファに載せる場合、ＤＢバッファの内容や管理情報を更新するため、ＤＢバッファ全体の整合性を確保するまでの間、ＤＢバッファ全体に対してロック、アンロックを行い、他のＤＢバッファの参照要求との整合性を確保している。更に、１回の検索要求におけるレコードの走査では、少なくとも、１回のＤＢバッファにアクセスを行い、探索条件を満たす１件のレコードを取り出している。その結果、大量にレコードを取り出す検索要求では、大量のＤＢバッファのアクセスが発生している。
【０００４】
【発明が解決しようとする課題】
こうしたＤＢバッファアクセスのシリアライズ手法は、大量に並列実行されることで競合が発生し、ＤＢアクセスの性能に影響を及ぼす。検索要求のたびにシリアライズを伴うＤＢバッファアクセスを大量に並列実行した場合、競合が発生し著しくＤＢの検索性能に影響を及ぼす。
【０００５】
本発明は検索要求における並列実行での競合を回避し、性能を得ることを目的としている。
【０００６】
【課題を解決するための手段】
上記目的を達成するために、検索要求のプロセス単位に検索要求に該当するＤＢバッファの内容を載せるローカライズされた固有バッファを設け、検索要求に該当するＤＢバッファ上のページ内のレコードのうち、検索要求の条件を満たす全てのレコードを１回のＤＢバッファアクセスで、固有バッファにコピーし参照する。次回の検索要求が同一ページに対するものであれば、固有バッファを参照することによって、ＤＢバッファの参照を行わずに検索要求に該当するレコードの参照を可能にする。更に、検索要求プロセスの固有バッファに載せたレコードが、他の更新要求の並列実行によってレコードの内容が書き替えられた場合、固有バッファの内容とＤＢバッファの内容が不整合な状態になる。これをページ内のレコードに対する排他制御によって検知する。固有バッファ上に検索要求を満たすレコードを載せ、そのレコードに対して排他制御することによって、そのレコードが更新されたか否かを検知する。ただし、排他制御で更新を検知したレコードはその時点で排他待ちを行うのではなく、まず、固有バッファ上に既にコピーしたレコードを検索結果として返し、検索結果を返すレコードが、排他制御によって更新を検知したレコードになった時点で改めて排他待ちする。排他待ち解除の後、もう一度、該当レコードからＤＢバッファの内容を固有バッファに載せ、ＤＢバッファと固有バッファの内容の整合性を保つ。
【０００７】
【発明の実施の形態】
以下、本発明を実施する場合の一形態を図面を参照して具体的に説明する。
図１は本発明を実施する場合の情報検索装置を示したブロック図である。
情報検索装置は、各検索プロセス１０２ごとにローカライズされた固有バッファ１０３を割当て、検索要求１０１を受けて固有バッファ１０３を初期化し、ＤＢバッファ１０４の内容を走査し、該当するページ内の検索要求の条件を満たす全てのレコードを固有バッファ１０３上にコピーし、更に、固有バッファ１０３上を走査し検索要求１０１に検索結果を返す検索装置と、各プロセスからの要求に該当するページの内容をデータベース管理システムで共用するＤＢバッファ１０４と、ＤＢの内容をファイル格納するディスク装置１０５からなる。
固有バッファ１０３には、固有バッファ内の領域管理、レコード位置の管理、ＤＢバッファのページの該当レコードのコピーを中断したレコード情報を管理する管理情報を有するものである。データベースはディスク装置上に設けられた複数のページ（格納領域）に分割されて格納されている。ページ内のデータがアクセスされた場合、ＤＢバッファへは、そのアクセスされたデータを含むページが格納されることになる。
【０００８】
図２は検索中のページに対して他の更新処理によって更新されたレコードが存在するときに、検索プロセスの固有バッファの内容とＤＢバッファのページの内容を示したブロック図である。検索対象レコードの他のトランザクションによる更新検知は、該当レコードの排他制御によって行う。排他制御には同一排他資源への排他要求に対し、排他待ちを検知できるモード（以下ＴＥＳＴモード）を使用し、排他待ちの検知によって該当レコードの更新を検知する。ＤＢバッファのページ２０１の検索対象レコードを固有バッファ２０２にコピー中に、レコードの更新を検知したら（２０５）、レコードのコピーは一時中断し、それまでにコピーした固有バッファ内のレコードの検索を行う（２０３）。固有バッファ内の全てのレコードの検索が完了したら、中断したレコード２０４に対して同一排他資源への排他要求に対して排他待ちを行う排他モード（以下ＷＡＩＴモード）で排他制御を行う。該当レコードの排他待ちが解除されたら、固有バッファの初期化２０６を行い、中断したレコード２０４から固有バッファ２０２へのレコードのコピーを実施し、後続の検索対象のレコードのコピーを行う。ＤＢバッファのページ内の検索対象のレコードを全てコピーが完了したら、固有バッファのレコードをコピーした順に取出し検索結果を返す（２０７）。本例では、レコード単位の処理で説明しているが、レコード内の特定カラムのデータでも同様であり、複数カラムのデータでも適用可能であり、レコードに限定されるものではない。
【０００９】
図３は検索中のページに対して他の更新処理によって更新されたレコードが存在するときに、検索プロセスの固有バッファの内容とＤＢバッファの整合性を維持する流れの一例を示した図である。図２は、検索要求の探索条件を満たす３件のレコード格納されているページがＤＢバッファ上に存在している状態で、検索を実行したときに、２件目にヒットするレコードＲ２が別の更新トランザクションによって、内容を変更されることを示している。
【００１０】
３０１は更新トランザクションの期間と更新処理内容を、３０２は更新トランザクションが掛けるページ内のレコードＲ２に掛ける排他期間を示している。３０３は検索トランザクションの期間と検索処理内容を、３０４、３０５、３０６はそれぞれ検索トランザクションが掛けるページ内のレコードＲ１、レコードＲ２、レコードＲ３の排他期間を示している。検索トランザクションは、固有バッファとコピー中断のレコード情報の割当てと初期化を行う（３１０，３１１）。次にページ３１２の内容を参照しレコードＲ１にＴＥＳＴモード排他を掛け、レコードＲ１を固有バッファにコピーする（３１４）。検索トランザクションがレコードＲ２を参照する前に、更新トランザクションがレコードＲ２に対して排他を掛け（３０２）、レコードＲ２の内容を更新する（３１６）。検索トランザクションは、レコードＲ２を参照し、ＴＥＳＴモードで排他を掛けるが、排他待ちを検知する（３０７）。排他待ちを検知したレコードＲ２の情報は、コピー中断のレコード情報に登録し（３１５）、固有バッファへのコピーを一時中断する。排他が掛かっているＤＢバッファーのページの排他を解放する（３２８）。
【００１１】
次に、固有バッファ内の検索を行う。固有バッファにコピーしたレコードＲ１を検索結果として検索要求に返す（３１７）。次回の検索要求からは、固有バッファ内の検索を行う。固有バッファにコピーした、全てのレコードを検索結果として検索要求に返したら、コピー中断のレコード情報が登録されているか判定する。コピー中断のレコード情報にはレコードＲ２が登録されているので、レコードＲ２に排他制御を行う。このとき、コピー中断のレコードには、ＷＡＩＴモードで排他待ちさせる（３０８）。排他が掛かっているＤＢバッファーのページの排他が解放される（３２９）。レコードＲ２の排他待ちが更新トランザクションのコミットで解除されたら（３０９）、固有バッファの初期化（３１９）とコピー中断のレコード情報の初期化（３１９）を行い、中断したレコードＲ２から固有バッファへレコードコピーを再開する（３２０，３２１）。レコードＲ３に排他を掛け、固有バッファにコピーが完了（３２２，３２３）し、ＤＢバッファのページ内の全てのレコードをコピーする。排他が掛かっているＤＢバッファーのページの排他を解放する（３３０）。次に、固有バッファ内を検索しレコードＲ２を検索結果として検索要求に返す（２２４）。次回の検索要求では、次のレコードＲ３を検索結果に返し（２２５）、固有バッファと、コピー中断のレコード情報を解放（２２６，２２７）して検索を終了する。このように、ＤＢバッファから検索してヒットしたレコードを固有バッファにコピーする処理をまとめて行い、ＤＢバッファを解放して検索結果を返しているので、ＤＢバッファの占有時間を短縮することができる。
【００１２】
図２，図３が示すように、ページの内容を１回のＤＢバッファアクセスで、可能な限り固有バッファに複数レコードをコピーし、検索する。しかし、途中で他のトランザクションによるレコードの更新を検知したら、そのレコードが検索要求の対象になるまでは、排他待ちせず、固有バッファ内に貯めたレコードを先に返し、固有バッファ内の全てのレコードの検索が完了した後で排他待ちして整合性を保持する。
【００１３】
図４は検索要求を受けた情報検索装置の処理手順を示すフロ−チャ−トである。検索要求でページへのアクセスが１回目のアクセスなら（ステップ４０１）、固有バッファの初期化を行う（ステップ４０２）。次に検索要求に該当するＤＢバッファ内の検索要求ページにアクセスし（ステップ４０３）、ＤＢバッファ上のページの内容を参照しレコードがコピー中断のレコードか判断する（ステップ４０５）。該当レコードがコピー中断のレコードではない場合、該当レコード検索要求の条件を満たすか判断する（ステップ４０６）。該当レコードが検索要求の条件を満たすのであれば、そのレコードに対し排他制御をＴＥＳＴモードで行い（ステップ４０７）、ＴＥＳＴモード排他の結果（ステップ４０８）排他待ちを検知しなければ、該当レコードを固有バッファにコピーを行う（ステップ４０９）。また、該当レコードが検索要求の条件を満たさないのであれば、該当レコードは固有バッファ上にコピーしない。これを該当ページ内に存在するの全てのレコードに対して行う（ステップ４１０）。これらの処理を該当ページ内の全てのレコードに対して行った後、該当ページの解放を行う（ステップ４１２）。次に固有バッファ内のレコードの取出しを行う（ステップ４１４）。固有バッファのレコードの取出しは固有バッファにコピーした順番に取り出す。レコード取出しの結果を判定し（ステップ４１４）、固有バッファ内に取り出すレコードが存在すれば、取り出したレコードを検索結果に設定しを検索要求に返す（ステップ４１７）。
【００１４】
２回目の検索要求でページへの２回目以降アクセスになる場合（ステップ４０１）では、固有バッファを参照し、次のレコードの取り出しを行う（ステップ４１３）。この結果、次のレコードが固有バッファに存在する場合（ステップ４１４）は、次のレコードを検索結果に設定して検索要求に返す（ステップ４１７）。固有バッファに検索結果を返すレコードが存在する間は、固有バッファの内容を参照しレコードを取り出し、検索結果の設定を繰返し返す。固有バッファ上の全てのレコードを読み終えたら（ステップ４１４）、コピー中断のレコード情報の存在をチェックし（ステップ４１５）、情報がなければ次の検索対象となるページの存在をチェックし（ステップ４１８）、なければ、検索を終了し、あれば、検索対象となるページを設定しステップ４０１判定から検索を続行する。こうして、検索要求に該当するレコードの参照におけるＤＢバッファへのアクセス要求は、ページに格納されているレコードの数に依存することなく、１ページあたり１回になる。また、ステップ４０７、ステップ４０８のＴＥＳＴモードの排他制御で排他待ちを検知した場合、該当レコードは、固有バッファにコピーを行なわず、固有バッファへのレコードのコピーはそこで一時中断する。このとき、中断したレコードの情報は固有バッファ内のコピー中断のレコード情報に覚えておき（ステップ４１１）、取得中のＤＢバッファを解放し、固有バッファのレコードの取出しを行う（ステップ４１４）。ここで、固有バッファにレコードが存在をチェックし（ステップ４１４）存在すれば、取り出したレコードを検索結果に設定して検索要求に返す。
【００１５】
固有バッファにレコードが存在をチェックし（ステップ４１４）、存在しなければ、コピー中断のレコード情報をチェックする（ステップ４１５）。この結果、コピー中断のレコード情報が設定されていなければ、次の検索対象となるページが、存在するかチェックし（ステップ４１８）、存在しなければ検索を終了、存在すれば次ぎの検索対象ページの検索を行う。コピー中断のレコード情報のチェック（ステップ４１５）の結果、情報が設定されていれば、コピー中断のレコードに対してＷＡＩＴモードで排他を掛け（ステップ４１６）、他のトランザクションの排他解除まで排他待ちになる。排他待ちが解除されれば、再度固有バッファの初期化を行い（ステップ４０２）以下ＤＢバッファのアクセスを行う。このとき、ステップ４０５の判定においてコピー中断のレコードを検知した場合、該当レコードは既に検索要求の条件を満たし、排他済の状態にあるため、ステップ４０６からステップ４０８の処理は行わず、該当レコードは固有バッファにコピー（ステップ４０９）を行う。
【００１６】
さらに、コピー中断したレコードの後にレコードが存在すれば、レコードの参照、条件の判定、排他制御を行い、ページ内のレコードを固有バッファにコピーのループを繰り返す。ページ内のコピーが完了し、固有バッファのレコードを取り出すときは、コピーを行った順に取り出す。すなわち、コピー中断したレコードから取り出すことになる。ぺージ内のレコードのコピーが全て完了してループを抜けている場合は、固有バッファのレコードを全て検索結果に返した後、次の検索対象ページのアクセス、または、検索終了となるが、コピー中断によってループを抜けた場合は、再度、ＷＡＩＴモードの排他で排他待ちして、ステップ４０２の固有バッファの初期化から処理を繰り返す。
【００１７】
このように、排他制御でレコードの更新中を検知し、レコードに対する排他解除待ちすることで、固有バッファの整合性を保つことができる。また、ロックがかかっていないレコードをまとめて処理できるため、ＤＢバッファのアクセスに伴うデータベースが格納されたディスクへのアクセスを減らすことが可能となる。
【００１８】
【発明の効果】
以上、説明したように、本発明によれば、検索要求の並行実行時のＤＢバッファの競合が軽減され性能向上を実現できる。
【図面の簡単な説明】
【図１】本発明の実施の一形態の情報検索装置の構成を示すブロック図、
【図２】検索中のページに対して他の更新処理によって更新されたレコードが存在した場合のレコードコピー方法を示したブロック図、
【図３】検索中のページに対して他の更新処理によって更新されたレコードが存在するときに、検索プロセスの固有バッファの内容とＤＢバッファの整合性を維持する流れの一例を示した図
【図４】検索要求を受けた情報検索装置の処理手順を示すフロ−チャ−ト、
【符号の説明】
１０１・・・検索要求、１０２・・・検索プロセス、１０３・・・固有バッファ、１０４・・・ＤＢバッファ、１０５・・・ＤＩＳＫ装置、２０１・・・ＤＢバッファ、２０２・・・固有バッファ、２０３・・・固有バッファ内の検索、２０４・・・更新を検知したレコード、２０５・・・レコードコピーの中断、２０６・・・固有バッファの初期化、２０７・・・固有バッファ内の再検索、３０１・・・更新トランザクションの期間、３０２・・・更新トランザクションが掛けるＲ２の排他期間、３０３・・・検索トランザクションの期間、３０４・・・検索トランザクションが掛けるＲ１の排他期間、３０５・・・検索トランザクションが掛けるＲ２の排他期間、３０６・・・検索トランザクションが掛けるＲ３の排他期間、３０７・・・排他待ちを検知しコピー中断のレコード情報の登録、３０８・・・Ｒ２の排他で排他待ちが発生している、３０９・・・更新トランザクションの排他解除でＲ２の排他待ちが解除され検索トランザクションがＲ２の排他を掛ける、３１０、３１５、３１９、３２６・・・固有バッファのコピー中断レコード情報の内容　、３１１、３１４，４１７，３１８，３２１，３２３，３２７・・・固有バッファのレコードの内容、３１２、３１６、３２０、３２２・・・ＤＢバッファの検索対象となるページの内容、３２４，３２５・・・固有バッファからレコードの取出し
【図１】
2004030487.tif 000003
【図２】
2004030487.tif 000004
【図３】
2004030487.tif 000005
【図４】
2004030487.tif 000006