JP4224126B1 - データベース管理サーバ装置、データベース管理システム、データベース管理方法およびデータベース管理プログラム - Google Patents

Abstract

【課題】 更新の一貫性が保たれ、かつ、更新処理の待ち時間の発生を抑えることのできるデータベース管理サーバ装置を提供する。
【解決手段】 データベース管理システム１のサーバ装置３は、クライアント装置２からの更新要求に基づいてデータベースの更新を非破壊で行うことにより、世代管理型のデータベース管理を行う機能を有する。主記憶部４には、複数のデータベースの実体がデータベースの版ごとに記憶されており、版作成部５は、クライアント装置からの更新要求に基づいてデータベースの新しい版を作成する。要求受付部１１は、新しい版の作成中であるか否かに係らず、次の版に対する更新要求を受け付ける。受付管理部１３は、その更新要求に応じて次の版に対する更新要求の受付期間を開始し、所定時間の経過後に受付期間を終了する。そして、版作成部５は、受付期間中に受け付けた更新要求に基づいて次の版を作成する。
【選択図】 図１

Description

本発明は、世代管理型のデータベース管理を行う機能を備えたデータベース管理サーバ装置に関するものである。

近年、電子計算機やネットワークの高性能化・低価格化や、インターネット通信環境の整備・普及等に伴って、情報技術の利用が盛んになってきている。その中でも、リレーショナルデータベースや文書データベースを管理するデータベース管理システムは、各種の応用システムから独立した形で各種のデータを維持・管理し、データの一貫性の保持や障害時の復旧、高速で高機能な検索処理などを容易に実現できるミドルウエアとして、各種の情報システムの中核として盛んに利用されている。

このようなデータベース管理システムの中には、データベースの「世代」という概念を導入し、データベースの世代管理を行うものがある（例えば、特許文献１および非特許文献１参照）。
特開２００２−３６６５４７号公報 Narayanan.Shivakumar and Hector G. Molina: "Wave-Indices: Indexing Evolving Databases", AMCSIGMOD '97, pp.381, ACM, 1997

このような世代管理型のデータベース管理システムでは、データベースの更新処理が非破壊で行われる。つまり、現在のデータベースの実体を変更せずに次のデータベースが作成される）。そのため、世代管理型のデータベース管理システムは、破壊的な更新を行うデータベース管理システムに比べて、例えば下記（１）〜（３）等の優れた特徴をもっている。
（１）更新処理の途中で、地震や停電といった機械的・電気的な事故や、記憶装置が満杯になる、といったさまざまな障害があっても、更新前の、現在のデータベースの内容が破壊されない可能性が高いため、対障害性に優れている。
（２）データベースを更新中でも、指定した世代で検索処理を行う限り、更新処理の影響を受けないため、複数の関連した検索要求の間での検索処理の一貫性を容易に実現できる。
（３）更新処理中でも検索性能の低下が少ない。

従来の世代管理型のデータベース管理システムでは、更新の一貫性が保たれており、更新に成功したデータが更新完了後に検索できない等の問題の発生が防がれている。しかし、更新の一貫性を保とうとすると、検索処理や更新処理に待ち時間が発生することになる。例えば、あるクライアント装置からのデータベース更新要求の処理中は、「次の世代の作成中」の状態となり、別のクライアント装置からの更新要求が待たされることになる。そこで、クライアント装置が更新要求を送信してから、更新完了の通知を受け取るまでの時間を短縮することが望まれていた。

また、従来のデータベース管理システムでは、仮に上記のような待ち時間が発生しない場合であっても、データベースの更新処理が非破壊で行われるため、破壊型の更新処理（つまり、世代管理を行わない更新処理）に比べて更新処理のオーバーヘッドが大きく、クライアント装置からみたときの更新時間が比較的長くなる。そこで、クライアント装置からみたときの更新時間を短縮することが望まれていた。

本発明は、上記従来の課題を解決するためになされたもので、更新の一貫性が保たれており、かつ、更新処理の待ち時間の発生を抑えることができるデータベース管理サーバ装置を提供することを目的とする。

本発明のデータベース管理サーバ装置は、クライアント装置からの更新要求に基づいてデータベースの更新を非破壊で行うことにより、世代管理型のデータベース管理を行う機能を有するデータベース管理サーバ装置であって、前記データベース管理サーバ装置は、複数のデータベースの実体を、データベースの版ごとに記憶する版記憶手段と、前記クライアント装置からの更新要求に基づいて、データベースの新しい版を作成する版作成手段と、前記新しい版の作成中であるか否かに係らず、前記クライアント装置からのデータベースの次の版に対する更新要求を受け付ける更新要求受付手段と、前記クライアント装置からの更新要求に応じて前記次の版に対する更新要求の受付期間を開始し、所定時間の経過に応じて前記次の版に対する更新要求の受付期間を終了する受付管理手段と、を備え、前記版作成手段は、前記受付期間中に受け付けた前記次の版に対する更新要求に基づいて、前記データベースの次の版を作成する構成を有している。

この構成により、クライアント装置からの更新要求があったときには、データベースの新しい版（例えば、版Ｘ）の作成中であっても、その次の版（例えば、版Ｘ＋１）に対する更新要求が受け付けられ、次の版に対する更新要求の受付期間が開始される。その後、所定時間が経過すると更新要求の受付期間が終了し、その受付期間中に受け付けた更新要求がまとめられて次の版が作成される。これにより、更新処理の待ち時間（更新要求の受付までの待ち時間）の発生を抑えることができる。また、この場合、世代管理型のデータベース管理により、更新の一貫性が保たれる。なお、ここで、データベースの次の版に対する更新要求とは、データベースの次の版において更新が反映されることを要求するものをいう。

また、本発明のデータベース管理サーバ装置は、前記受付期間中の前記クライアント装置からの更新要求と、過去に受け付けた更新要求との衝突の有無を判定する更新衝突判定手段と、更新衝突が無であると判定された場合に、前記クライアント装置からの更新要求の受付完了通知として、前記クライアント装置へデータベースの予定版名を通知する予定版名通知手段と、を備えた構成を有している。

この構成により、受付期間中のクライアント装置からの更新要求と、過去に受け付けた更新要求との衝突の有無の判定が行われる。そして、更新衝突が無であると判定されると、更新要求の受付完了通知として予定版名が通知される。このように、更新要求の受付完了通知として予定版名を利用することにより、更新要求を送ったクライアント装置は、その更新要求が受け付けられたか否かを確認することができ、また、その更新要求が反映されるであろう版を知ることができる。

また、本発明のデータベース管理サーバ装置では、前記予定版名通知手段は、前記クライアント装置からの更新要求に対する応答として、前記クライアント装置へ前記データベースの予定版名を通知する構成を有している。

この構成により、クライアント装置からの更新要求に対する応答として、予定版名が通知される。したがって、更新要求を送ったクライアント装置は、その更新要求が受け付けられたか否かを早く確認することができ、また、その更新要求が反映されるであろう版をすぐに知ることができる。そのため、例えば、更新要求を送った後に、データベース管理サーバ装置に障害が発生した場合であっても、その障害からの復旧処理が行われた後に、更新要求が受け付けられたか否か、あるいは、その更新要求が反映されたか否かを容易に確認することができる。

また、本発明のデータベース管理サーバ装置は、前記データベースの更新ログとして、前記データベースの版ごとの更新状態を記憶する更新ログ記憶手段と、クライアント装置からの確認要求に応じて、前記データベースの版の更新状態を通知する更新状態通知手段と、前記データベースの新しい版の作成が完了したときに、前記更新ログに前記新しい版の作成完了を記録する作成ログ記録手段と、前記データベース管理サーバ装置の障害からの復旧処理を行うときに、前記障害の発生時に前記更新ログに作成完了の記録が行われていない作成途中の版を破棄する破棄処理手段と、を備えた構成を有している。

この構成により、データベースの新しい版の作成が完了すると、更新ログにその版の作成完了が記録される。データベース管理サーバ装置に障害が発生した場合、その障害からの復旧処理が行われるときに、更新ログに作成完了の記録が行われていない作成途中の版が破棄される。このようなデータベースの版の更新状態（「作成完了」または「破棄」などの状態）は、クライアント装置からの確認要求に応じて通知される。したがって、クライアント装置は、データベース管理サーバ装置に障害が発生したときに、以前に送った更新要求が反映された版が作成されたか否か、すなわち、以前に送った更新要求を再度送る必要があるか否かを、容易に確認することができる。なお、新しい版の作成が完了すると、その版は検索可能になる。したがって、版の作成完了状態は、版の検索可能状態であるともいえる。また、版の更新状態には、上記の作成完了状態（検索可能状態）のほかに、例えば受付状態や作成中状態などが含まれる。

また、本発明のデータベース管理サーバ装置は、前記データベースの版の削除を行う版削除手段と、前記版の削除が行われたときに、前記データベースの更新ログとして、削除したデータベースの版名を残す削除ログ記録手段と、を備えた構成を有している。

この構成により、データベースの版の削除が行われた場合であっても、更新ログにその版名（予定版名）が残される。したがって、データベースの版が削除された後であっても、ある版名をもつデータベースの版が過去に存在していたか否か、例えば、自分が過去に送った更新要求が反映されたか否かを容易に確認することができる。この場合、データベースの版名は、データベースの実体に比べてデータ量がはるかに小さくて済む。

また、本発明のデータベース管理サーバ装置では、前記受付管理手段は、前記新しい版の作成中に前記クライアント装置から前記次の版に対する更新要求を受け付けた場合に、前記更新要求の受付期間の終了時を前記新しい版の作成完了時以後に設定する構成を有している。

この構成により、更新要求の受付期間の終了時は、新しい版の作成完了時以後に設定される。この場合、新しい版（作成中の版）の作成が完了するまでは、次の版（受け付けた更新要求を反映する版）の作成を開始することができない。したがって、新しい版の作成が完了するのを待って、次の版に対する更新要求の受付を終了するようにする。これにより、更新受付の時間的な効率を向上することができる。

また、本発明のデータベース管理サーバ装置では、前記受付管理手段は、前記新しい版の作成中に前記クライアント装置から前記次の版に対する更新要求を受け付けた場合に、前記更新要求の受付期間の終了時を前記更新要求の受付数により決定する構成を有している。

この構成により、更新要求の受付期間の終了時が、更新要求の受付数に基づいて決定される。例えば、更新要求の受付数がある一定数以上になった場合に、更新要求の受付期間を終了するようにする。これにより、更新要求の受付期間を適切な長さに制御することができる。

本発明のデータベース管理システムは、データベースの更新要求を送る機能を有するクライアント装置と、前記クライアント装置からの更新要求に基づいてデータベースの更新を非破壊で行うことにより、世代管理型のデータベース管理を行う機能を有するデータベース管理サーバ装置と、を備えたデータベース管理システムであって、前記データベース管理サーバ装置は、複数のデータベースの実体を、データベースの版ごとに記憶する版記憶手段と、前記クライアント装置からの更新要求に基づいて、データベースの新しい版を作成する版作成手段と、前記新しい版の作成中であるか否かに係らず、前記クライアント装置からのデータベースの次の版に対する更新要求を受け付ける更新要求受付手段と、前記クライアント装置からの更新要求に応じて前記次の版に対する更新要求の受付期間を開始し、所定時間の経過に応じて前記次の版に対する更新要求の受付期間を終了する受付管理手段と、を備え、前記版作成手段は、前記受付期間中に受け付けた前記次の版に対する更新要求に基づいて、前記データベースの次の版を作成する構成を有している。

このシステムによれば、クライアント装置からの更新要求があったときには、データベースの新しい版（例えば、版Ｘ）の作成中であっても、その次の版（例えば、版Ｘ＋１）に対する更新要求が受け付けられ、次の版に対する更新要求の受付期間が開始される。その後、所定時間が経過すると更新要求の受付期間が終了し、その受付期間中に受け付けた更新要求がまとめられて次の版が作成される。これにより、更新処理の待ち時間（更新要求の受付までの待ち時間）の発生を抑えることができる。また、この場合、世代管理型のデータベース管理により、更新の一貫性が保たれる。

本発明のデータベース管理方法は、クライアント装置からの更新要求に基づいてデータベースの更新を非破壊で行うことにより、世代管理型のデータベース管理を行う機能を有するデータベース管理サーバ装置で用いられるデータベース管理方法であって、前記データベース管理サーバ装置には、複数のデータベースの実体が、データベースの版ごとに記憶されており、前記データベース管理サーバ装置は、前記クライアント装置からの更新要求に基づいて、データベースの新しい版を作成する機能を有しており、前記データベース管理方法は、前記新しい版の作成中であるか否かに係らず、前記クライアント装置からのデータベースの次の版に対する更新要求を受け付けることと、前記クライアント装置からの更新要求に応じて前記次の版に対する更新要求の受付期間を開始し、所定時間の経過に応じて前記次の版に対する更新要求の受付期間を終了することと、前記受付期間中に受け付けた前記次の版に対する更新要求に基づいて、前記データベースの次の版を作成することと、を含むものである。

この方法によっても、クライアント装置からの更新要求があったときには、データベースの新しい版（例えば、版Ｘ）の作成中であっても、その次の版（例えば、版Ｘ＋１）に対する更新要求が受け付けられ、次の版に対する更新要求の受付期間が開始される。その後、所定時間が経過すると更新要求の受付期間が終了し、その受付期間中に受け付けた更新要求がまとめられて次の版が作成される。これにより、更新処理の待ち時間（更新要求の受付までの待ち時間）の発生を抑えることができる。また、この場合、世代管理型のデータベース管理により、更新の一貫性が保たれる。

本発明のデータベース管理プログラムは、クライアント装置からの更新要求に基づいてデータベースの更新を非破壊で行うことにより、世代管理型のデータベース管理を行う機能を有するデータベース管理サーバ装置で実行されるデータベース管理プログラムであって、前記データベース管理サーバ装置には、複数のデータベースの実体が、データベースの版ごとに記憶されており、前記データベース管理サーバ装置は、前記クライアント装置からの更新要求に基づいて、データベースの新しい版を作成する機能を有しており、前記データベース管理プログラムは、コンピュータに、前記新しい版の作成中であるか否かに係らず、前記クライアント装置からのデータベースの次の版に対する更新要求を受け付ける処理と、前記クライアント装置からの更新要求に応じて前記次の版に対する更新要求の受付期間を開始し、所定時間の経過に応じて前記次の版に対する更新要求の受付期間を終了する処理と、前記受付期間中に受け付けた前記次の版に対する更新要求に基づいて、前記データベースの次の版を作成する処理と、を実行させるものである。

このプログラムによっても、クライアント装置からの更新要求があったときには、データベースの新しい版（例えば、版Ｘ）の作成中であっても、その次の版（例えば、版Ｘ＋１）に対する更新要求が受け付けられ、次の版に対する更新要求の受付期間が開始される。その後、所定時間が経過すると更新要求の受付期間が終了し、その受付期間中に受け付けた更新要求がまとめられて次の版が作成される。これにより、更新処理の待ち時間（更新要求の受付までの待ち時間）の発生を抑えることができる。また、この場合、世代管理型のデータベース管理により、更新の一貫性が保たれる。

本発明は、新しい版の作成中であるか否かに係らずクライアント装置からの更新要求を受け付ける更新要求手段と、その更新要求に応じて開始された受付期間中に受け付けた更新要求に基づいて次の版を作成する版作成手段とを設けることにより、更新の一貫性が保たれ、かつ、更新処理の待ち時間の発生を抑えることができるという効果を有するデータベース管理サーバ装置を提供することができるものである。

以下、本発明の実施の形態のデータベース管理システムについて、図面を用いて説明する。ここでは、まず、図１および図２を参照して、本実施の形態のデータベース管理システムの構成について説明する。

図１は、本実施の形態のデータベース管理システムの構成を示すブロック図である。図１に示すように、データベース管理システム１は、検索要求や更新要求を送るクライアント装置２と、検索要求や更新要求に対する応答として検索結果や更新結果を送り返すデータベース管理サーバ装置３（単にサーバ装置３ともいう）で構成されている。なお、図１の例では、説明の便宜のため、３つのクライアント装置２（クライアント装置Ａ〜Ｃ）と１つのサーバ装置３のみが図示されているが、クライアント装置２やサーバ装置３の数はこれに限定されるものではない。

本実施の形態のサーバ装置３は、後述するように、クライアント装置２からの更新要求に基づいて、データベースの更新を非破壊で行うことにより、世代管理型のデータベース管理を行う機能を備えている。この機能は、サーバ装置３のメモリ等（図示せず）に記憶されたプログラムによって実行される。

図１に示すように、サーバ装置３は、複数のデータベースの実体（ディレクトリやファイルなど）を、データベースの版ごとに記憶する主記憶部４を備えている。図１の例では、４つの版（版１〜版４）が主記憶部４に記憶されている。また、この主記憶部４には、データベースの版更新ログが記憶されている。この版更新ログは、データベースの版の更新状態（受付状態、作成中状態、検索可能状態（作成完了状態）など）を示すものである。ここでは、この主記憶部４が、本発明の版記憶手段および更新ログ記憶手段に相当する。

サーバ装置３は、データベースの新たな版を主記憶部４に記憶する版作成部５と、主記憶部４に記憶されている既存の版を削除する版削除部６を備えている。版作成部５は、クライアント装置２からの更新要求に基づいて、データベースの新しい版を作成する機能を有している。後述するように、この版作成部５は、所定の受付期間中に受け付けた次の版に対する更新要求に基づいて、データベースの次の版を作成する機能を有している。この版作成部５が、本発明の版作成手段に相当する。

また、サーバ装置３は、主記憶部４に記憶されているデータベースの版（作成済みの版）の実体を、検索や参照などの作業のために一時的に記憶しておく作業用記憶部７を備えている。なお、ここでは、作業用記憶部７に一時的に記憶することを「ロード」といい、作業用記憶部７から削除することを「アンロード」という。

このサーバ装置３は、主記憶部４に記憶されているデータベースの版（作成済みの版）の実体を作業用記憶部７にロードする版ロード部８と、作業用記憶部７から版の実体をアンロードする版アンロード部９を備えている。図１の例では、２つの版（版２と版３）が作業用記憶部７にロードされており、参照する必要がなくなった古い版（版１）は作業用記憶部７からアンロードされている。さらに、このサーバ装置３には、作業用記憶部７にロードされているデータベースの版を検索する版検索部１０が備えられている。

図１に示すように、サーバ装置３は、クライアント装置２からの検索要求や更新要求を受け付ける要求受付部１１と、検索要求や更新要求に対する応答として検索結果や更新結果をクライアント装置２に通知する結果通知部１２を備えている。この要求受付部１１は、版作成部５が新しい版の作成中であるか否かに係らず、クライアント装置２から次の版に対する更新要求を受け付けることができる。ここでは、この要求受付部１１が、本発明の更新要求受付手段に相当する。

また、サーバ装置３は、クライアント装置２からの更新要求を受け付けたときに更新要求の受付期間を開始して、所定の一定時間が経過したときに受付期間を終了する受付管理部１３を備えている。この受付管理部１３は、新しい版（例えば、版２）の作成中にクライアント装置２からの更新要求を受け付けたときに、次の版（例えば、版３）に対する更新要求の受付期間を開始する。そして、その次の版（版３）に対する更新要求の受付期間の終了時は、新しい版（版２）の作成完了時以後に設定される（図３など参照）。なお、更新要求の受付開始後、多くの更新要求が来たような場合は一定数の更新要求数で受付期間を終了しても良い。いずれの場合も、この受付管理部１３が、本発明の受付管理手段に相当する。

そして、このサーバ装置３は、上記の版作成部５・版削除部６・版ロード部８・版アンロード部９などを制御して、データベースの版の更新制御を行う版更新制御部１４を備えている。以下、版更新制御部１４の機能について、図２を参照して詳細に説明する。

図２は、版更新制御部１４の機能を説明するためのブロック図である。図２に示すように、版更新制御部１４は、受付期間中のクライアント装置２からの更新要求と、過去に受け付けた更新要求との衝突の有無を判定する更新衝突判定部１５を備えている。

この更新衝突判定部１５は、クライアント装置２からの更新要求に含まれる更新データと、過去に受け付けた更新要求に含まれる更新データ（その受付期間中に先に受け付けた更新要求に含まれる更新データや、作成中の版の更新データ、作成済みの版の更新データなど）との整合性を検査する。具体的には、クライアント装置２からの更新要求に含まれる更新データのＩＤが、過去に受け付けた更新要求に含まれる更新データのＩＤのいずれかと一致するか否かが判定される。

更新衝突判定部１５での判定の結果、更新要求の衝突が無である（更新データのＩＤが一致しない）と判定された場合には、クライアント装置２からの更新要求の受付完了通知として、結果通知部１２からクライアント装置２へデータベースの予定版名が通知される。ここでは、更新衝突判定部１５が、本発明の更新衝突判定手段に相当し、結果通知部１２が、本発明の予定版名通知手段に相当する。

なお、データベースの予定版名とは、次に作成されるであろうデータベースの版名である。例えば、「版２」という版名のデータベースの新しい版が作成中である場合には、データベースの次の版の版名（予定版名）は「版３」である。また、この版名には、クライアント装置２からの更新要求の受付時刻が利用されてもよい。例えば、ＹＹＹＹ年ＭＭ月ＤＤ日の１２時３４分５６秒にクライアント装置２からの更新要求を受け付けた場合には、次の版の版名（予定版名）は、「版ＹＹＹＹＭＭＤＤ１２３４５６」である。

また、図２に示すように、版更新制御部１４は、作成ログ記録部１６と破棄処理部１７を備えている。作成ログ記録部１６は、データベースの新しい版の作成が完了したときに、その新しい版の更新状態として、版更新ログに新しい版の「作成完了」を記録する機能を備えている。また、破棄処理部１７は、サーバ装置３に何らかの障害が発生した場合、その障害から復旧処理を行うときに（再起動を行うときに）、障害の発生時に上記の版更新ログに「作成完了」が記録されていない版（作成途中の版）を破棄する機能を備えている。

例えば、サーバ装置３に障害が発生した時に「版３」の作成は完了していたが「版４」の作成は完了していなかった場合、版更新ログには「版３」の「作成完了」は記録されているので、障害からの復旧処理の際に「版３」は破棄されない。したがって、その後にクライアント装置２から「版３」についての確認要求があった場合には、「版３」の更新状態として、サーバ装置３の結果通知部１２からそのクライアント装置２へ「作成完了」が通知される（図５など参照）。

一方、この場合、版更新ログには「版４」の「作成完了」は記録されていないので、障害からの復旧処理の際に「版４」は破棄される。したがって、その後にクライアント装置２から「版４」についての確認要求があった場合には、「版４」の更新状態として、サーバ装置３の結果通知部１２からそのクライアント装置２へ「破棄」が通知される（図５など参照）。ここでは、作成ログ記録部１６が、本発明の作成ログ記録手段に相当し、破棄処理部１７が、本発明の破棄処理手段に相当する。また、結果通知部１２が、本発明の更新状態通知手段に相当するといえる。

さらに、図２に示すように、版更新制御部１４は、削除ログ記録部１８を備えている。削除ログ記録部１８は、版削除部６がデータベースの版の削除を行ったときに、データベースの版更新ログとして、削除したデータベースの予定版名を残す機能を備えている。例えば、主記憶部４から「版１」を削除する場合には、この「版１」という版名が版更新ログに記録される（図１参照）。この削除ログ記録部１８は、本発明の削除ログ記録手段に相当する。

以上のように構成されたデータベース管理システム１について、図３〜図９を用いてその動作を説明する。

ここでは、まず、図３および図４を参照して、データベース管理システム１の通常の動作（障害が発生しないときの動作）について説明する。図３は、非同期型のデータベース管理システム１の動作の説明図である。ここで、「非同期型」のシステムとは、クライアント装置２からの更新要求に対して、その更新要求が反映されていないにも係らず、そのクライアント装置２に予定版名（その更新要求が反映されるであろう版名）を通知するシステムをいう。

図３では、サーバ装置３において４つのデータベースの版（版１〜版４）が並列的に（パイプライン的に）管理されており、３つのクライアント装置２（クライアント装置Ａ〜Ｃ）からの更新要求や確認要求に対する処理が行われる例が示されている。

まず、サーバ装置３では、データベースの「版１」の作成が完了してロードされている。すなわち、「版１」は「検索可能」な状態になっている。このとき、クライアント装置Ｂからサーバ装置３に検索要求ｂが送られると、サーバ装置３では「版１」を用いて検索処理が実行され、その検索結果ｂがクライアント装置Ｂに通知される。

つぎに、クライアント装置Ａからサーバ装置３に更新要求ａが送られる。このとき、サーバ装置３では、データベースの「版２」に対する更新要求の受付期間は終了しており、「版２」は作成中になっている。このような場合、サーバ装置３は、クライアント装置Ａからの更新要求ａに応じて、その次の版である「版３」に対する更新要求の受付期間を開始する。そして、この更新要求ａに対する応答として「版３」という版名がクライアント装置Ａに通知される。

つづいて、クライアント装置Ｂからサーバ装置３に更新要求ｂが送られる。この場合、サーバ装置３では、「版２」の作成が完了していないので、「版３」に対する更新要求の受付期間は終了していない。したがって、サーバ装置３では、クライアント装置Ｂからの更新要求ｂとこの受付期間中に受け付けた更新要求ａとの衝突の有無が判定され、衝突が無であると判定されると、その結果として「版３」という版名がクライアント装置Ｂに通知される。

その後「版２」の作成が完了すると、サーバ装置３では「版３」の受付期間を締め切り、「版３」の作成が開始される。このとき、クライアント装置Ａからサーバ装置３に「版３」の更新状態の確認要求が送られると、その確認要求に対する応答として「作成中」という更新状態がクライアント装置Ａに通知される。

つぎに、クライアント装置Ｃからサーバ装置３に更新要求ｃが送られる。上述の場合と同様、サーバ装置３では、データベースの「版３」に対する更新要求の受付期間は終了しており、「版３」は作成中になっている。したがって、サーバ装置３は、クライアント装置Ｃからの更新要求ｃに応じて、その次の版である「版４」に対する更新要求の受付期間を開始する。そして、この更新要求ｃに対する応答として「版４」という版名がクライアント装置Ｃに通知される。

「版３」の作成が完了してロードされた後に、クライアント装置ＡおよびＢからサーバ装置３に「版３」の更新状態の確認要求が送られると、その確認要求に対する応答として「作成完了」という更新状態がクライアント装置ＡおよびＢに通知される。

そして、クライアント装置Ａからサーバ装置３に検索要求ａが送られると、サーバ装置３では「版３（クライアント装置Ａからの更新要求ａが反映された版）」を用いて検索処理が実行され、その検索結果ａがクライアント装置Ａに通知される。

また、「版３」の作成が完了すると、上述の場合と同様に、サーバ装置３では「版４」の受付期間を締め切り、「版４」の作成が開始される。このとき、クライアント装置Ｃからサーバ装置３に「版４」の更新状態の確認要求が送られると、その確認要求に対する応答として「作成中」という更新状態がクライアント装置Ｃに通知される。そして、「版４」の作成が完了してロードされた後に、クライアント装置Ｃからサーバ装置３に「版４」の更新状態の確認要求が送られると、その確認要求に対する応答として「作成完了」という更新状態がクライアント装置Ｃに通知される。

ここで、図３を参照して、データベースの版の更新状態について説明すると、データベースの版は、まず、クライアント装置２からの更新要求があったときに版名（予定版名）が決定され、受付期間が開始されて「受付」状態となる。その後、受付期間が終了すると、版の作成が開始されて「作成中」の状態となる。そして、その版の作成が完了して作業用記憶部７にロードされると「検索可能」状態になる。古くなり参照する必要がなくなった版は作業用記憶部７からアンロードされる。アンロードされた版は、すぐに主記憶部４から削除されるわけではなく、主記憶部４に「保持」された状態になる。その後、一定の期間が経過すると、その版の実体は主記憶部４から削除されるが、その版名は版更新ログに記録される。

図４は、同期型のデータベース管理システム１の動作の説明図である。ここで、「同期型」のシステムとは、クライアント装置２からの更新要求に対して、その更新要求が反映されたときに、そのクライアント装置２に版名（その更新要求が反映された版名）を通知するシステムをいう。

ここでは、図４のシステムの動作が、図３のシステムの動作と相違する点を中心に説明する。したがって、ここで特に言及しない限り、図４のシステムの動作は、図３のシステムの動作と同様である。

図４に示すように、同期型のシステムでは、クライアント装置Ａからサーバ装置３に更新要求ａが送られたときに、この更新要求ａに対する応答として「版３」という版名がサーバ装置３からクライアント装置Ａに送られるが、この版名はクライアント装置Ａのアプリケーション制御層までは届かない。この場合、「版３」の作成が完了してロードされたときに、「版３」の「作成完了」がクライアント装置Ａに通知される。

同様に、クライアント装置Ｂからサーバ装置３に更新要求ｂが送られたときに、この更新要求ｂに対する応答として「版３」という版名がサーバ装置３からクライアント装置Ｂに送られるが、この版名はクライアント装置Ｂのアプリケーション制御層までは届かない。この場合、「版３」の作成が完了してロードされたときに、「版３」の「作成完了」がクライアント装置Ｂに通知される。

また、同様に、クライアント装置Ｃからサーバ装置３に更新要求ｃが送られたときに、この更新要求ｃに対する応答として「版４」という版名がサーバ装置３からクライアント装置Ｃに送られるが、この版名はクライアント装置Ｃのアプリケーション制御層までは届かない。この場合、「版４」の作成が完了してロードされたときに、「版４」の「作成完了」がクライアント装置Ｃに通知される。

つぎに、図５および図６を参照して、サーバ装置３に障害が発生したときの動作について説明する。図５は、非同期型のシステムでサーバ障害が発生したときの動作の説明図である。ここでは、システムのサーバ装置３に障害が発生したときの動作が、図３の通常の動作と相違する点を中心に説明する。

図５の例では、クライアント装置ＡおよびＢから「版３」に対する更新要求がサーバ装置３に送られており、クライアント装置Ｃから「版４」に対する更新要求がサーバ装置３に送られている。そして、サーバ装置３に障害が発生したときに、「版３」は「検索可能」な状態であり、「版４」は「受付」の状態である。したがって、この場合、版更新ログには、「版３」の「作成完了」が記録される。

図５に示すように、サーバ装置３に障害が発生すると、まず、更新要求を送ってきたクライアント装置２に対して、障害通知として、その更新要求に対する版名を含む障害通知が送られる。この場合、クライアント装置ＡおよびＢには「版３」という版名を含む障害通知が送られ、クライアント装置Ｃには「版４」という版名を含む障害通知が送られる。なお、非同期のシステムでは、クライアント装置２はすでにサーバ装置３から版名通知が送られているため、必ずしも障害通知に版名を含める必要はない。

サーバ装置３が障害から復旧して再起動の処理をするときには、版更新ログに「作成完了」が記録されている「版３」をロードして「検索可能」な状態にする。一方、版更新ログに「作成完了」が記録されていない「版４」については、サーバ装置３の再起動の際に作成途中の版を破棄し、版更新ログに「破棄」を記録する。

その後、クライアント装置ＡおよびＢからサーバ装置３に「版３」の更新状態の確認要求が送られると、その確認要求に対する応答として「作成完了」という更新状態がクライアント装置ＡおよびＢに通知される。

一方、クライアント装置Ｃからサーバ装置３に「版４」の更新状態の確認要求が送られた場合、その確認要求に対する応答として「破棄」という更新状態がクライアント装置Ｃに通知される。このようにして、クライアント装置Ｃは、サーバ装置３の障害により、「版４」に対する更新要求ｃが反映されなかったことを確認することができ、更新要求ｃを再度送る必要があることを認識することができる。なお、図５の例では、クライアント装置Ｃは、更新要求ｃをサーバ装置３に再送しており、この場合、二度目の更新要求ｃに対する版名は「版５」である。

図６は、同期型のシステムでサーバ障害が発生したときの動作の説明図である。ここでは、システムのサーバ装置３に障害が発生したときの動作が、図４の通常の動作と相違する点を中心に説明する。

図６の例では、クライアント装置ＡおよびＢから「版３」に対する更新要求がサーバ装置３に送られており、クライアント装置Ｃから「版４」に対する更新要求がサーバ装置３に送られている。そして、図５の例と同様、サーバ装置３に障害が発生したときに、「版３」は「検索可能」な状態であり、「版４」は「受付」の状態である。したがって、この場合、版更新ログには、「版３」の「作成完了」が記録される。

図６に示すように、サーバ装置３に障害が発生すると、まず、更新要求を送ってきたクライアント装置２に対して、障害通知として、その更新要求に対する版名を含む障害通知が送られる。この場合、クライアント装置ＡおよびＢには「版３」という版名を含む障害通知が送られ、クライアント装置Ｃには「版４」という版名を含む障害通知が送られる。

そして、図５と同様、サーバ装置３が障害から復旧して再起動の処理をするときには、版更新ログに「作成完了」が記録されている「版３」をロードして「検索可能」な状態にする。一方、版更新ログに「作成完了」が記録されていない「版４」については、サーバ装置３の再起動の際に作成途中の版を破棄し、版更新ログに「破棄」を記録する。

その後、クライアント装置ＡおよびＢからサーバ装置３に「版３」の更新状態の確認要求が送られると、その確認要求に対する応答として「作成完了」という更新状態がクライアント装置ＡおよびＢに通知される。

一方、クライアント装置Ｃからサーバ装置３に「版４」の更新状態の確認要求が送られた場合、その確認要求に対する応答として「破棄」という更新状態がクライアント装置Ｃに通知される。このようにして、クライアント装置Ｃは、サーバ装置３の障害により、「版４」に対する更新要求ｃが反映されなかったことを確認することができ、更新要求ｃを再度送る必要があることを認識することができる。なお、図６の例でも、図５と同様に、クライアント装置Ｃは、更新要求ｃをサーバ装置３に再送しており、この場合、二度目の更新要求ｃに対する版名は「版５」である。

つづいて、図７〜図９を参照して、サーバ装置３における各処理の流れについて説明する。図７は、更新要求の受付処理の流れを示すフロー図である。図７に示すように、サーバ装置３は、クライアント装置２から更新要求を受け付けると（Ｓ１０）、現在、作成中の版（例えば、版Ｘ）があるか否かを判断する（Ｓ１１）。作成中の版がある場合には、その版との更新データのＩＤの衝突があるか否かを判断する（Ｓ１２）。更新データのＩＤの衝突がある場合には、その更新要求を却下して、クライアント装置２にその旨のエラー通知を送り返す（Ｓ１３）。

更新データのＩＤの衝突がない場合には、現在、受付中の版（例えば、版Ｘ＋１）があるか否かを判断する（Ｓ１４）。受付中の版がある場合には、その版との更新データのＩＤの衝突があるか否かを判断する（Ｓ１５）。更新データのＩＤの衝突がある場合には、その更新要求を却下して、クライアント装置２にその旨のエラー通知を送り返す（Ｓ１３）。受付中の版がない場合には、その予定版名「Ｘ＋１」を版名として決定し（Ｓ１６）、その版（版Ｘ＋１）を受付状態にする（Ｓ１７）。

そして、更新要求を版Ｘ＋１に反映させて（Ｓ１８）、更新要求の受付を終了し、版名Ｘ＋１をクライアント装置２へ送り返す（Ｓ１９）。このようにして、更新要求が受理される。

図８は、確認要求の受付処理の流れを示すフロー図である。図８に示すように、サーバ装置３は、クライアント装置２からある版（例えば、版Ｘ）の確認要求を受け付けると（Ｓ２０）、版更新ログを参照して、その版Ｘが現在受付中であるか否かを判定する（Ｓ２１）。そして、受付中であると判定された場合には、クライアント装置２に「受付中」である旨を通知する（Ｓ２２）。

その版Ｘが現在受付中でないと判定された場合には、版更新ログを参照して、その版Ｘが現在作成中であるか否かを判定する（Ｓ２３）。そして、作成中であると判定された場合には、クライアント装置２に「作成中」である旨を通知する（Ｓ２４）。

その版Ｘが現在作成中でないと判定された場合には、版更新ログを参照して、その版Ｘが現在ロード中であるか否かを判定する（Ｓ２５）。そして、ロード中であると判定された場合には、クライアント装置２に「作成完了」を通知する（Ｓ２６）。

その版Ｘが現在ロード中でないと判定された場合には、版更新ログを参照して、その版Ｘが現在保持中であるか否かを判定する（Ｓ２７）。そして、保持中であると判定された場合には、クライアント装置２に「作成完了」を通知する（Ｓ２６）。

その版Ｘが現在保持中でないと判定された場合には、その版Ｘを作成した記録が版更新ログにあるか否かを判定する（Ｓ２８）。そして、版更新ログに記録があると判定された場合には、クライアント装置２に「作成完了」を通知する（Ｓ２６）。一方、版更新ログに記録がないと判定された場合には、クライアント装置２に「破棄」を通知する（Ｓ２９）。

図９は、サーバ障害からの復旧（再起動）処理の流れを示すフロー図である。図９に示すように、サーバ装置３が障害からの復旧（再起動）の処理を開始すると（Ｓ３０）、まず、主記憶部４に記憶されている版（例えば、版Ｘ）を一つ選択する（Ｓ３１）。そして、その版Ｘが、版更新ログに記録がある版であるか否かを判定する（Ｓ３２）。

版更新ログに記録があると判定された場合には、その版Ｘをロードする（Ｓ３３）。一方、版更新ログに記録がないと判定された場合には、その版Ｘを破棄する（Ｓ３４）。そして、上記の処理を、主記憶部４に記憶されているすべての版について行った場合に（Ｓ３６）、サーバ装置３の再起動の処理を終了する（Ｓ３７）。

このような本発明の実施の形態によれば、データベース管理サーバ装置３に、新しい版の作成中であるか否かに係らずクライアント装置２からの更新要求を受け付ける更新要求部と、その更新要求に応じて開始された受付期間中に受け付けた更新要求に基づいて次の版を作成する版作成部５とを設けることにより、更新の一貫性が保たれ、かつ、更新処理の待ち時間の発生を抑えることができる。

すなわち、本実施の形態では、クライアント装置２からの更新要求があったときには、データベースの新しい版（例えば、版Ｘ）の作成中であっても、その次の版（例えば、版Ｘ＋１）に対する更新要求が受け付けられ、次の版に対する更新要求の受付期間が開始される。その後、所定時間が経過すると更新要求の受付期間が終了し、その受付期間中に受け付けた更新要求がまとめられて次の版が作成される。これにより、更新処理の待ち時間（更新要求の受付までの待ち時間）の発生を抑えることができる。また、この場合、世代管理型のデータベース管理により、更新の一貫性が保たれる。

また、本実施の形態では、受付期間中のクライアント装置２からの更新要求と、過去に受け付けた更新要求との衝突の有無の判定が行われる。そして、更新衝突が無であると判定されると、更新要求の受付完了通知として予定版名が通知される。このように、更新要求の受付完了通知として予定版名を利用することにより、更新要求を送ったクライアント装置２は、その更新要求が受け付けられたか否かを確認することができ、また、その更新要求が反映されるであろう版を知ることができる。

また、本実施の形態では、クライアント装置２からの更新要求に対する応答として、予定版名が通知される。したがって、更新要求を送ったクライアント装置２は、その更新要求が受け付けられたか否かを早く確認することができ、また、その更新要求が反映されるであろう版をすぐに知ることができる。そのため、例えば、更新要求を送った後に、データベース管理サーバ装置３に障害が発生した場合であっても、その障害からの復旧処理が行われた後に、更新要求が受け付けられたか否か、あるいは、その更新要求が反映されたか否かを容易に確認することができる。

また、本実施の形態では、データベースの新しい版の作成が完了すると、更新ログにその版の作成完了が記録される。データベース管理サーバ装置３に障害が発生した場合、その障害からの復旧処理が行われるときに、更新ログに作成完了の記録が行われていない作成途中の版が破棄される。このようなデータベースの版の更新状態（「作成完了」または「破棄」などの状態）は、クライアント装置２からの確認要求に応じて通知される。したがって、クライアント装置２は、データベース管理サーバ装置３に障害が発生したときに、以前に送った更新要求が反映された版が作成されたか否か、すなわち、以前に送った更新要求を再度送る必要があるか否かを、容易に確認することができる。

また、本実施の形態では、データベースの版の削除が行われた場合であっても、更新ログにその版名（予定版名）が残される。したがって、データベースの版が削除された後であっても、ある版名をもつデータベースの版が過去に存在していたか否か、例えば、自分が過去に送った更新要求が反映されたか否かを容易に確認することができる。この場合、データベースの版名は、データベースの実体に比べてデータ量がはるかに小さくて済む。

また、本実施の形態では、更新要求の受付期間の終了時は、新しい版の作成完了時以後に設定される。この場合、新しい版（作成中の版）の作成が完了するまでは、次の版（受け付けた更新要求を反映する版）の作成を開始することができない。したがって、新しい版の作成が完了するのを待って、次の版に対する更新要求の受付を終了するようにする。これにより、更新受付の時間的な効率を向上することができる。

また、本実施の形態では、更新要求の受付期間の終了時が、更新要求の受付数に基づいて決定される。例えば、更新要求の受付数がある一定数以上になった場合に、更新要求の受付期間を終了するようにする。これにより、更新要求の受付期間を適切な長さに制御することができる。

以上、本発明の実施の形態を例示により説明したが、本発明の範囲はこれらに限定されるものではなく、請求項に記載された範囲内において目的に応じて変更・変形することが可能である。

以上のように、本発明にかかるデータベース管理システムは、更新の一貫性が保たれ、かつ、更新処理の待ち時間の発生を抑えることができるという効果を有し、世代管理型のデータベース管理等に利用され、有用である。

本発明の実施の形態におけるデータベース管理システムの構成を示すブロック図 版更新制御部の構成を示すブロック図 本発明の実施の形態におけるデータベース管理システム（非同期型）の動作の説明図 本発明の実施の形態におけるデータベース管理システム（同期型）の動作の説明図 障害からの復旧処理を行うときのデータベース管理システム（非同期型）の動作の説明図 障害からの復旧処理を行うときのデータベース管理システム（同期型）の動作の説明図 更新要求の受付処理の動作説明のためのフロー図 確認要求の受付処理の動作説明のためのフロー図 障害からの復旧（再起動）処理の動作説明のためのフロー図

符号の説明

１ データベース管理システム
２ クライアント装置
３ データベース管理サーバ装置
４ 主記憶部
５ 版作成部
６ 版削除部
７ 作業用記憶部
８ 版ロード部
９ 版アンロード部
１０ 版検索部
１１ 要求受付部
１２ 結果通知部
１３ 受付管理部
１４ 版更新制御部
１５ 更新衝突判定部
１６ 作成ログ記録部
１７ 破棄処理部
１８ 削除ログ記録部

Claims (10)

1. クライアント装置からの更新要求に基づいてデータベースの更新を非破壊で行うことにより、世代管理型のデータベース管理を行う機能を有するデータベース管理サーバ装置であって、
   前記データベース管理サーバ装置は、
   複数のデータベースの実体を、データベースの版ごとに記憶する版記憶手段と、
   前記クライアント装置からの更新要求に基づいて、データベースの新しい版を作成する版作成手段と、
   以前に受け付けた前記更新要求に基づいて前記新しい版の作成中であるか否かに係らず、前記クライアント装置からの別の更新要求を、前記新しい版の次の版に対する更新要求として受け付けることができる更新要求受付手段と、
   前記クライアント装置からの別の更新要求に応じて前記新しい版の次の版に対する更新要求としての受け付けを行う受付期間を開始し、所定時間の経過に応じて前記受付期間を終了する受付管理手段と、
   を備え、
   前記版作成手段は、前記受付期間中に前記新しい版の次の版に対する更新要求として受け付けた更新要求に基づいて、前記データベースの次の版を作成することを特徴とするデータベース管理サーバ装置。
2. 前記受付期間中の前記クライアント装置からの更新要求と、過去に受け付けた更新要求との衝突の有無を判定する更新衝突判定手段と、
   更新衝突が無であると判定された場合に、前記クライアント装置からの更新要求の受付完了通知として、前記クライアント装置へデータベースの予定版名を通知する予定版名通知手段と、
   を備えたことを特徴とする請求項１に記載のデータベース管理サーバ装置。
3. 前記予定版名通知手段は、前記クライアント装置からの更新要求に対する応答として、前記クライアント装置へ前記データベースの予定版名を通知することを特徴とする請求項２に記載のデータベース管理サーバ装置。
4. 前記データベースの更新ログとして、前記データベースの版ごとの更新状態を記憶する更新ログ記憶手段と、
   クライアント装置からの確認要求に応じて、前記データベースの版の更新状態を通知する更新状態通知手段と、
   前記データベースの新しい版の作成が完了したときに、前記更新ログに前記新しい版の作成完了を記録する作成ログ記録手段と、
   前記データベース管理サーバ装置の障害からの復旧処理を行うときに、前記障害の発生時に前記更新ログに作成完了の記録が行われていない作成途中の版を破棄する破棄処理手段と、
   を備えたことを特徴とする請求項１ないし請求項３のいずれかに記載のデータベース管理サーバ装置。
5. 前記データベースの版の削除を行う版削除手段と、
   前記版の削除が行われたときに、前記データベースの更新ログとして、削除したデータベースの版名を残す削除ログ記録手段と、
   を備えたことを特徴とする請求項１ないし請求項４のいずれかに記載のデータベース管理サーバ装置。
6. 前記受付管理手段は、前記新しい版の作成中に前記新しい版の次の版に対する更新要求として更新要求を受け付けた場合に、前記更新要求の受付期間の終了時を前記新しい版の作成完了時以後に設定することを特徴とする請求項１ないし請求項５のいずれかに記載のデータベース管理サーバ装置。
7. 前記受付管理手段は、前記新しい版の作成中に前記新しい版の次の版に対する更新要求として更新要求を受け付けた場合に、前記更新要求の受付期間の終了時を前記更新要求の受付数により決定することを特徴とする請求項１ないし請求項５のいずれかに記載のデータベース管理サーバ装置。
8. データベースの更新要求を送る機能を有するクライアント装置と、
   前記クライアント装置からの更新要求に基づいてデータベースの更新を非破壊で行うことにより、世代管理型のデータベース管理を行う機能を有するデータベース管理サーバ装置と、
   を備えたデータベース管理システムであって、
   前記データベース管理サーバ装置は、
   複数のデータベースの実体を、データベースの版ごとに記憶する版記憶手段と、
   前記クライアント装置からの更新要求に基づいて、データベースの新しい版を作成する版作成手段と、
   以前に受け付けた前記更新要求に基づいて前記新しい版の作成中であるか否かに係らず、前記クライアント装置からの別の更新要求を、前記新しい版の次の版に対する更新要求として受け付けることができる更新要求受付手段と、
   前記クライアント装置からの別の更新要求に応じて前記新しい版の次の版に対する更新要求としての受け付けを行う受付期間を開始し、所定時間の経過に応じて前記受付期間を終了する受付管理手段と、
   を備え、
   前記版作成手段は、前記受付期間中に前記新しい版の次の版に対する更新要求として受け付けた更新要求に基づいて、前記データベースの次の版を作成することを特徴とするデータベース管理システム。
9. クライアント装置からの更新要求に基づいてデータベースの更新を非破壊で行うことにより、世代管理型のデータベース管理を行う機能を有するデータベース管理サーバ装置で用いられるデータベース管理方法であって、
   前記データベース管理サーバ装置には、複数のデータベースの実体が、データベースの版ごとに記憶されており、前記データベース管理サーバ装置は、前記更新要求に基づいて、データベースの新しい版を作成する機能を有しており、
   前記データベース管理方法は、
   以前に受け付けた前記更新要求に基づいて前記新しい版の作成中であるか否かに係らず、前記クライアント装置からの別の更新要求を、前記新しい版の次の版に対する更新要求として受け付けることと、
   前記クライアント装置からの別の更新要求に応じて前記新しい版の次の版に対する更新要求としての受け付けを行う受付期間を開始し、所定時間の経過に応じて前記受付期間を終了することと、
   前記受付期間中に前記新しい版の次の版に対する更新要求として受け付けた更新要求に基づいて、前記データベースの次の版を作成することと、
   を含むことを特徴とするデータベース管理方法。
10. クライアント装置からの更新要求に基づいてデータベースの更新を非破壊で行うことにより、世代管理型のデータベース管理を行う機能を有するデータベース管理サーバ装置で実行されるデータベース管理プログラムであって、
    前記データベース管理サーバ装置には、複数のデータベースの実体が、データベースの版ごとに記憶されており、前記データベース管理サーバ装置は、前記クライアント装置からの更新要求に基づいて、データベースの新しい版を作成する機能を有しており、
    前記データベース管理プログラムは、
    コンピュータに、
    以前に受け付けた前記更新要求に基づいて前記新しい版の作成中であるか否かに係らず、前記クライアント装置からの別の更新要求を、前記新しい版の次の版に対する更新要求として受け付ける処理と、
    前記クライアント装置からの別の更新要求に応じて前記新しい版の次の版に対する更新要求としての受け付けを行う受付期間を開始し、所定時間の経過に応じて前記受付期間を終了する処理と、
    前記受付期間中に前記新しい版の次の版に対する更新要求として受け付けた更新要求に基づいて、前記データベースの次の版を作成する処理と、
    を実行させることを特徴とするデータベース管理プログラム。

Images