JP4764472B2 - データベース管理方法、データベース管理プログラム、および、データベース管理装置 - Google Patents

Description

本発明は、データベース管理方法、データベース管理プログラム、および、データベース管理装置の技術に関する。

情報化社会の発展に伴い、多くの企業がデータベースを含むシステムを利用し、様々なオンラインサービスを提供している。例えば、銀行のＡＴＭや航空券の販売システムがオンラインサービスの例として挙げられる。近年、企業間競争がますます激化する状況下で、各企業はオンラインサービス時間の拡大や、オンラインサービス内容の拡充等を行い他企業との差別化を図っている。

オンラインサービスのシステムを構築する際は、多種多様なハードウェアやミドルウェアを組み合わせることが多い。この場合、各ソフトウェアとハードウェアに対する保守とシステム全体に対する保守が必要となり、システム管理コストは非常に大きい。

システム管理コストは、システム稼動中常に発生するため、システム管理コストを削減して利益を確保することは、企業間競争を勝ち抜く上で重要となる。そのため、オンラインサービスの時間外の時間帯を有効活用することにより、システムを有効活用し、システム管理コストに見合った成果を得ることが期待できる。

データベース管理システムでは、オンライン業務によって蓄積されたデータをバッチ処理として一括処理することによって統計情報などを生成し、生成された統計情報を経営判断などに利用することがある。統計情報を生成するようなバッチ処理では、大量のデータにアクセスする必要があり、バッチ処理の実行中にはシステム負荷が増大しやすい。

特に、ディスクドライブなどの外部記憶媒体にデータが格納されている場合には、データの入出力による負荷が大きくなる。このため、バッチ処理は負荷が比較的小さくオンラインサービス時間外である夜間などに実行される場合が多い。

オンラインサービスの拡充やオンラインサービス利用者の増加に伴うデータ処理量の増加により、バッチ処理時間は長くなる傾向にある。しかし、各企業はオンラインサービス時間を拡大しており、バッチ処理に割り当てられる時間は短くなっている。よって、バッチ処理時間の短縮化が望まれている。

次に、データベース管理システムにおけるバッチ処理の運用について図１８〜図２０をもとに、説明する。なお、図１８〜図２０は、横軸を時間軸とするガントチャート形式の説明図である。

図１８は、バッチ処理ｂ１とバッチ処理ｂ２および各バッチ処理に対するバックアップ処理を示す説明図である。
複数のバッチ処理を実行する際、障害に備えて各バッチ処理終了時点（ｔ１，ｔ３）のデータベースのデータ内容をバックアップｃ１，ｃ２する。
従来の運用では、バックアップ中にバックアップ済みでないデータベース上のページが更新されること（データの上書き問題）を防ぐために、バッチ処理の実行後に、そのバッチ処理の処理結果のバックアップ処理を実行する。

図１９は、非特許文献１に開示されている、バッチ処理時間を短縮する方法の説明図である。
バッチ処理ｂ１の処理結果のバックアップｃ１と、バッチ処理ｂ２の処理とを、並列に実行する点が、図１８との違いである。
この方法では、バッチ処理を実行する際に、データベースの更新履歴である更新ログＬ１，Ｌ２を記録している。
そのため、バッチ処理ｂ２がデータベースのデータを上書きしても、上書き前の更新ログＬ２とバックアップデータｂｋ１とをデータベースに書き戻すことによって、障害発生時の回復処理を実現する（非特許文献２参照）。この回復処理により、データベースのデータ内容は、時刻ｔ１の時点のデータ内容に回復される。
ジム グレイ、アンドレアス ロイター著「トランザクション処理〈下〉―概念と技法」日経ＢＰ社、２００１年１０月、Ｐ．７４３ C.J.Date「Introduction to Database Systems (Systems Programming Series)」Addison-Wesley Pub、1982年7月、P.20

しかし、図１９に示した手法の運用において、バッチ処理を実行する際の更新ログ記録処理は、外部記憶装置との入出力によるシステム負荷が非常に大きい。

このシステム負荷を低減するため、外部記憶媒体に格納されたデータをメモリ上に記憶させ、メモリ上のデータを読み書きすることによって処理の高速化を図る処理（以後インメモリデータ処理と呼ぶ）を考える。インメモリデータ処理では、外部記憶装置にアクセスする必要がないため、システム負荷低減に大きな効果を得ることができる。

図２０では、まず時刻ｔ０で外部記憶媒体からデータを読み出してメモリに記憶する処理（以後、インメモリ化と呼ぶ）を実行する。その後、インメモリ化が完了すると、メモリ上のデータを読み書きすることで、バッチ処理ｂ１を実行する。時刻ｔ１でバッチ処理ｂ１が終了すると、メモリ上のデータを外部記憶媒体に書き出す処理（以後、ＤＢ同期と呼ぶ）を実行する。

時刻ｔ２でＤＢ同期が終了すると、バックアップｃ１において、外部記憶媒体に格納されたデータを読み出し、その読み出したデータを格納する記憶媒体にバックアップデータとして書き込む。このように、メモリ上のデータをバックアップするためにＤＢ同期を行い、ＤＢ同期終了後にバッチ処理ｂ２を実行する。

データの上書き問題に対して、バッチ処理ｂ１のＤＢ同期が終了するまでは、次のバッチ処理ｂ２の開始を待たせるように制御する必要がある。この待ち時間により、バッチ処理に関する全体時間（時刻ｔ０〜ｔ５）が増大してしまう。

そこで、本発明は、前記した問題を解決し、データベース管理システムにおいてバックアップを伴うバッチ処理の処理時間を短縮することを、主な目的とする。

前記課題を解決するため、本発明は、データベースに格納されたデータを管理するデータベース管理装置によるデータベース管理方法であって、
前記データベース管理装置が、データアクセス処理部と、バックアップ処理部と、を有し、
前記バックアップ処理部が、
記憶装置に格納される前記データベースの所定時刻におけるデータを、前記所定時刻後のうちのバックアップ計画データに従ったタイミングで前記データベースからバックアップデータとして書き出すこととし、そのバックアップ計画データは、前記データベースへのデータアクセスのうちの最終のバッチ処理に伴って発生したデータアクセスを除く既に作成されたデータアクセス履歴に格納されている過去のデータごとの実行時刻を参照し、実行時刻が先であるデータほど、先に前記バックアップデータとして書き出すタイミングを規定するデータであり、
前記データアクセス処理部が、
前記データベースへのデータアクセス要求に応じて、前記データベースへのデータアクセスを実行し、そのデータアクセス対象のデータのＩＤと、そのデータアクセスの実行時刻と、を対応づけて前記データアクセス履歴として作成して記憶装置に格納し、
前記所定時刻後のデータアクセス要求において、前記バックアップデータとして書き出されていないデータに対する更新要求が発生したときには、前記所定時刻におけるデータを前記データベースから前記バックアップデータとして書き出した後、前記更新要求に従って、前記データベースのデータを更新し、
前記データベース管理装置が、前記バックアップ処理部の処理と、前記データアクセス処理部の処理とを、並行に処理することを特徴とする。
その他の手段は、後記する。

本発明によれば、データベース管理システムにおいてバックアップを伴うバッチ処理の処理時間を短縮することができる。

以下、本発明が適用されるデータベース管理システムの一実施形態について、図面を参照しながら説明する。

図１は、データベース管理システムの構成を示す図である。データベース管理システムは、データベース管理装置１、ストレージ装置５０、端末７０、および、バックアップ装置８０が、ネットワーク６０を通じて互いに接続されるシステムである。

データベース管理装置１は、プロセッサ１０、メモリ２０、および、他装置と通信するための通信インタフェースを備えるコンピュータとして構成される。プロセッサ１０は、メモリ２０に記憶されたプログラムを処理することによって、各種処理を実行するための処理部を構成する。
メモリ２０には、ＤＢアクセス要求受付部２１、バックアップ要求受付部２２、回復要求受付部２３、インメモリ要求受付部２４、ＤＢアクセス処理部２５、バックアップ処理部２６、回復処理部２７、および、インメモリ処理部２８を構成するためのプログラムが記憶される。
メモリ２０には、データとして、バックアップ処理中フラグ２９、バックアップ管理テーブル３０、および、インメモリデータベース３１が記憶される。

端末７０は、ユーザからの入力を受け付ける入力手段などを介して、バッチ業務を実行するためのバッチ処理を受け付ける。そして、端末７０は、そのバッチ処理を実行するためのトランザクションをデータベース管理装置１との間に設け、バッチ処理の実行の過程でデータアクセスが必要になると、そのトランザクションを介して、データベース管理装置１にデータのアクセス要求などを送信する。アクセス要求は、例えば、ＳＱＬ（Structured Query Language）の文法に従って、記述される。

データベース管理装置１は、各データベース（データベース５２、インメモリデータベース３１）に格納されたデータを管理する。なお、インメモリデータベース３１は、データベース５２のデータ内容をインメモリ化（データの同一化）をしたものである。また、データベース管理装置１は、端末７０からのデータのアクセス要求を受け、管理対象のデータの読み書きを制御する。

ストレージ装置５０は、データベース管理装置１によって管理されるデータを、自装置内の記憶装置５１のデータベース５２に格納する。
ストレージ装置５０は、さらに、インメモリデータベース３１およびデータベース５２へのアクセス要求に伴うアクセスの履歴を、記憶装置５１内のＤＢアクセス履歴５３として格納する。
なお、ストレージ装置５０は、データベース５２およびＤＢアクセス履歴５３を記憶する記憶媒体について、ＨＤＤ（Hard disk drive）やＳＳＤ（Solid State Drive）などの記憶媒体が内蔵されている記憶装置５１として構成してもよいし、読み書き可能なＤＶＤ（Digital Versatile Disc）ドライブなどの記憶媒体が着脱可能な記憶装置５１として構成してもよい。

バックアップ装置８０は、データベース管理装置１によって管理されるインメモリデータベース３１のデータのバックアップデータ８２を記憶装置８１に格納する。バックアップ装置８０は、例えば、ストレージ装置であるが、データベース管理装置１に直接接続された外部記憶媒体であってもよいし、テープデバイスなどであってもよい。

データベース管理装置１のＤＢアクセス要求受付部２１は、端末７０などによって送信されたデータアクセス要求を受け付ける。ＤＢアクセス処理部２５は、ＤＢアクセス要求受付部２１が受け付けたデータアクセス要求に基づいて、インメモリデータベース３１に格納されたデータを読み書きする。
ＤＢアクセス処理部２５は、バッチ処理に伴うアクセス要求に対して、インメモリデータベース３１にデータアクセスする。このインメモリデータベース３１へのデータアクセスの内容により、インメモリデータベース３１のデータ内容が更新されたときには、同期または非同期のタイミングで、インメモリデータベース３１とデータベース５２とでデータ内容の同一化処理を実行する。

バックアップ要求受付部２２は、端末７０などによって送信されたバックアップ要求を受け付ける。バックアップ処理部２６は、バックアップ要求受付部２２が受け付けたバックアップ要求に基づいて、ストレージ装置５０に格納されたデータベース５２および、インメモリデータベース３１をバックアップする。

回復要求受付部２３は、端末７０などによって送信されたデータ回復要求を受け付ける。回復処理部２７は、回復要求受付部２３が受け付けたデータ回復要求に基づいて、バックアップデータ８２から回復に必要なバックアップデータを準備し、インメモリデータベース３１に反映して、インメモリデータベース３１を回復する。

インメモリ要求受付部２４は、インメモリデータ処理の実行または解除などのコマンドを受け付ける。インメモリ処理部２８は、インメモリ要求受付部２４が受け付けたコマンドに基づいて、インメモリデータ処理を制御する。
インメモリデータ処理とは、ストレージ装置５０に格納されている管理対象のデータをメモリ２０に記憶し、データのアクセス要求を受け付けた場合にはメモリ２０に記憶されているインメモリデータベース３１にアクセスするように制御する処理である。これにより、インメモリ処理部２８は、別装置であるストレージ装置５０（データベース５２）にアクセスする必要がなくなるため、データアクセスの応答性能を向上させることができる。

データベース管理装置１は、自装置が管理するインメモリデータベース３１のデータを、バックアップ装置８０のバックアップデータ８２に書き出すことで、バックアップを実行する。このバックアップ処理は、以下に示す２種類のいずれかの書き出し処理によって、実現される。

１種類目の「通常書き出し」は、バックアップ処理部２６によって実行される書き出し処理である。バックアップ処理部２６は、ＤＢアクセス処理部２５が所定のトランザクションについて、コミット処理（データ確定処理）を行ってからトランザクションを終了した後に、そのコミット処理によって確定されたデータを含む、インメモリデータベース３１のデータを、バックアップデータ８２として書き出す。
バックアップ処理部２６は、書き出すデータとその書き出し時刻について、例えば、トランザクションが終了した後に、バックアップの対象となるデータをページごとに書き出し時刻に対応づけるバックアップ計画データ（図４）を作成し、そのバックアップ計画データに従ったタイミングで、順次ページを書き出す。
一方、バックアップ処理部２６は、バックアップ計画データを事前に作成せずに、データベース管理装置１の負荷度合いを常時計測し、データベース管理装置１の負荷が少なくなったときをページの書き出し時刻と決定する、いわゆる動的なバックアップ制御を実行してもよい。

２種類目の「臨時書き出し」は、ＤＢアクセス処理部２５によって実行される書き出し処理である。バックアップデータ８２として書き出すデータは、最新のデータではなく、所定時点（例えば、所定のトランザクションの終了時点）のデータである。
一方、インメモリデータベース３１内において、データの書き出し処理が終わっていないページが、最新のトランザクションのデータアクセス処理によって、最新のデータ内容に書き換わってしまうことが発生する。
そこで、ＤＢアクセス処理部２５は、現在処理中のトランザクションにおいて、「通常書き出し」によるバックアップがなされていないページへのデータ更新が発生すると、更新前のページのデータをバックアップ処理部２６に代行して書き出すとともに、更新後のページのデータをインメモリデータベース３１に書き込む。

以上説明した「通常書き出し」および「臨時書き出し」によるバックアップ処理は、ともにインメモリデータベース３１からバックアップデータ８２へのデータ書き出し処理であるものの、その書き出し処理の動作主体がそれぞれ異なる（「通常書き出し」はバックアップ処理部２６が実行し、「臨時書き出し」はＤＢアクセス処理部２５が実行する）。
よって、データベース管理装置１は、ＤＢアクセス処理部２５とバックアップ処理部２６とのデータ書き出し処理間でのデータアクセス衝突の発生を抑制するため、以下に示す排他処理を実行する。
ＤＢアクセス処理部２５とバックアップ処理部２６とのうち、バックアップを実行する一方の処理部は、バックアップを実行する前に、他方の処理部がデータ書き出し処理を実行しているか否かを参照する。他方の処理部によるデータ書き出し処理が実行中であるときには、一方の処理部はその実行が終わるまで、一時的に待機する。

バックアップ処理中フラグ２９は、バックアップ処理中か否かを示すフラグであり、「処理中」または「未処理」のいずれかの値をとる。バックアップ処理中フラグ２９が「処理中」であるときは、バックアップ中であることを示す。バックアップ処理中フラグ２９が「未処理」であるときは、バックアップ中でないことを示す。
バックアップ処理中フラグ２９が「処理中」の場合、ＤＢアクセス処理部２５のデータ書き出し処理の必要有無を判定し、バックアップ処理中フラグ２９が「未処理」の場合は、ＤＢアクセス処理部２５のデータ書き出し処理の必要有無を判定しない。

また、「通常書き出し」および「臨時書き出し」によるバックアップ処理は、同じページについて、いずれか一方の書き出し処理が行われればよい。そこで、データベース管理装置１は、各ページのバックアップ処理の進捗状況をバックアップ管理テーブル３０に管理する。

図２は、インメモリデータベース３１、バックアップ管理テーブル３０、および、バックアップデータ８２の一例を示す説明図である。
インメモリデータベース３１およびバックアップデータ８２は、データベース５２に格納されるデータが記憶される記憶領域であり、ページを特定する「ページＩＤ」と、その「ページ内容」とを対応づけて管理する。

なお、インメモリデータベース３１、バックアップデータ８２、および、データベース５２の間でのデータ入出力は、ページ単位で実行される。
ここで、図２では、ページ内容として１ページに１つの整数値（例えば「５０」）としたが、これはあくまで説明用の一例であり、実際には１ページには固定長または可変長のデータベースが扱う各種データ（バイナリデータ、テキストデータなど）が記憶される。

バックアップ管理テーブル３０は、インメモリデータベース３１の各ページに対して、バックアップ済みか否かの情報を格納するためのテーブルであり、バックアップ対象のページを特定するための「ページＩＤ」と、バックアップ済みか否かの情報である「フラグ」とを対応づけて管理する。
「フラグ」は、既にバックアップを実行していることを示す「済」、または、まだバックアップを実行していないことを示す「未」のいずれかの値をとる。

ＤＢアクセス処理部２５およびバックアップ処理部２６のうちの片方の処理部は、フラグが「未」であるページのバックアップを実行した後に、そのフラグを「未」から「済」に書き換える。
もう片方の処理部は、バックアップをしようとするページに対応するフラグが「済」であるときには、そのページのバックアップを省略する。
これにより、片方の書き出し処理が実行された後に、もう片方の書き出し処理を重複して実行してしまう（二重バックアップ）ことを抑制できる。

図３は、ＤＢアクセス履歴５３の一例を示す構成図である。ＤＢアクセス履歴５３は、バッチ処理ＩＤと、ページＩＤと、更新時刻と、を対応づけて管理する。
ＤＢアクセス処理部２５は、バッチ処理に伴い、インメモリデータベース３１へのデータ更新を実行すると、そのバッチ処理のバッチ処理ＩＤと、データ更新の対象となるページＩＤと、そのデータ更新の更新時刻と、を対応づけてＤＢアクセス履歴５３に書き込む。

図４は、バックアップ処理部２６が作成する、バックアップ計画データの一例を示す構成図である。
バックアップ計画データは、バックアップの対象ページごとに、そのページＩＤと、そのページについての書き出し処理を行う予定の書き出し時刻と、を対応づけて構成される。
バックアップ処理部２６は、このバックアップ計画データに従ったタイミングで、各ページの通常書き出し処理を実行してもよいし、ページの書き出し時刻が早い順番に、順次ページを書き出してもよい。バックアップ計画データは、バックアップ処理部２６が作成してもよいし、端末７０などからあらかじめ入力されたデータとして構成してもよい。

なお、バックアップ計画データは、データベース管理装置１の処理負荷が時間経過によらず略均等になることが、望ましい。もし、特定の時間帯に大量のページのバックアップを実行すると、そのバックアップの処理負荷がＤＢアクセス処理部２５のデータアクセス処理を圧迫してしまい、トランザクションを処理するユーザに影響が及ぶためである。
また、ＤＢアクセス処理部２５の「臨時書き出し」の頻度が高くなると、トランザクションもしくはバッチの処理時間に影響を及ぼす。
そこで、バックアップ処理部２６は、例えば、以下に示す２種類の作成方法のいずれかを実行することにより、過去のＤＢアクセス履歴５３から現在および将来のデータアクセスを高精度で予測し、負荷分散効果の高いバックアップ計画データを作成する。

１種類目の作成方法は、ＤＢアクセス履歴５３から抽出したページの更新順序をもとに、バックアップ計画データを作成する方法である。
例えば、図３のＤＢアクセス履歴５３を参照すると、バッチ処理ＩＤ「ｂ１」の履歴は、その更新時刻が早い順に、ページＩＤ「ｐ１」→「ｐ２」→「ｐ４」→「ｐ３」となっている。そこで、図４のバックアップ計画データに示すように、バックアップ対象のページについて、同じ順序である「ｐ１」→「ｐ２」→「ｐ４」→「ｐ３」とする。ここで、図１０で後記するように、時刻「ｔ２」，「ｔ３」，「ｔ４」の順に遅い（より将来の）時刻を示す。
これにより、過去に書き出し時刻の早かったページ「ｐ１」は、将来のバックアップ処理においても優先的に実行され、過去に書き出し時刻の遅かったページ「ｐ３」は、将来のバックアップ処理においても後回しにされる。

２種類目の作成方法は、ＤＢアクセス履歴５３から抽出したページの更新順序の平均順序をもとに、バックアップ計画データを作成する方法である。例えば、ページ「ｐ１」から「ｐ４」について、ＤＢアクセス履歴５３から抽出した更新順序の平均順序が以下の通りであるとする。なお、１位とは、４つのページの中で一番早い（古い）時刻にバックアップ処理がなされたことを意味する。
ページ「ｐ１」：１．２位
ページ「ｐ２」：２．５位
ページ「ｐ３」：２．９位
ページ「ｐ４」：３．７位
バックアップ処理部２６は、この平均順序をもとに、平均順序がよい（値が低い）順に、ページＩＤ「ｐ１」→「ｐ２」→「ｐ３」→「ｐ４」の順序となるバックアップ計画データを作成する。

以上説明した２種類の作成方法により、各ページについて、「臨時書き出し」よりもバックアップ計画データに従った「通常書き出し」が実行される可能性が高くなる。
よって、ＤＢアクセス処理部２５は、「臨時書き出し」の頻度が低下することで、現在実行しているトランザクションの処理に多くの処理能力を割り当てることができる。

図５は、データベース管理システムが実行するバックアップ処理の概要を示す説明図である。以下、図５が示すバックアップ処理について、適宜図６〜図９を参照しつつ、説明する。なお、図５の説明図は、横軸を時間軸とするガントチャート形式で記述しており、図５の縦方向には、端末７０およびＤＢアクセス処理部２５が実行するバッチ処理ｂ１，ｂ２を実線矢印で、バックアップ処理部２６が実行するバックアップ処理ｂｋ１，ｂｋ２を点線矢印で、それぞれ示している。

バックアップ処理ｂｋ１は、バッチ処理ｂ１の終了時点（時刻ｔ１）でのインメモリデータベース３１のデータを、バックアップデータ８２に書き出す処理である。
バックアップ処理ｂｋ２は、バッチ処理ｂ２の終了時点（時刻ｔ６）でのインメモリデータベース３１のデータを、バックアップデータ８２に書き出す処理である。
なお、バックアップ処理部２６は、バックアップ処理ｂｋ１，ｂｋ２をそれぞれ実行する前に、バックアップ処理中フラグ２９を「処理中」にするとともに、その実行後に、バックアップ処理中フラグ２９を「未処理」にする。

時刻ｔ０において、端末７０はバッチ処理ｂ１を開始し、ＤＢアクセス処理部２５はインメモリデータベース３１のページを読み書きする。ここで、インメモリデータベース３１は、インメモリ化済みとする。

時刻ｔ１において、端末７０はバッチ処理ｂ１が終了する。そのとき、端末７０およびＤＢアクセス処理部２５は、次のバッチ処理ｂ２を開始するとともに、バックアップ処理部２６は、時刻ｔ１の時点でのインメモリデータベース３１のページ（ｐ１〜ｐ４）を、バックアップデータ８２に書き出すための、バックアップ計画データ（図４参照）を作成する。
バックアップ計画データは、例えば、バックアップ対象ページ（ｐ１、ｐ２、ｐ３、ｐ４）をバッチ処理ｂ１によって早く更新される順番（ｐ１→ｐ２→ｐ３→ｐ４）に並べ替えたデータである。

図６に示すように、バックアップ処理実行前の時刻ｔ１の時点では、インメモリデータベース３１のデータは、バックアップデータ８２に書き出されていない。バックアップ処理部２６は、バックアップ対象ページに対応するバックアップ管理テーブル３０の「フラグ」を、「未」に初期化する。

図７に示すように、時刻ｔ２において、バックアップ処理部２６は、バックアップ処理ｂｋ１の過程で、バックアップ計画データで指定されたページｐ１，ｐ２の書き出し時刻になったので、ページｐ１、ページｐ２の順番にインメモリデータベース３１からページｐ１，ｐ２のデータを読み出し、その読み出したデータをバックアップデータ８２に書き出す（通常書き出し）。バックアップ処理部２６は、この書き出し処理に伴い、バックアップ管理テーブル３０の該当ページ（ｐ１，ｐ２）のフラグを「済」に変更する。

図８に示すように、時刻ｔ３において、ＤＢアクセス処理部２５は、バッチ処理ｂ２の実行中に、まだバックアップされていないページｐ４へのデータ更新処理が端末７０から要求されたとする。
ＤＢアクセス処理部２５は、更新前のページｐ４のデータ「３５」をバックアップ処理部２６に代行してバックアップデータ８２に書き出す（臨時書き出し）とともに、更新後のデータ「５０」をインメモリデータベース３１に書き込む。この臨時書き出しに伴い、ＤＢアクセス処理部２５は、バックアップ管理テーブル３０のページｐ４のグラフを「済」に書き換える。

図９に示すように、時刻ｔ４において、バックアップ処理部２６は、バックアップ処理ｂｋ１の過程で、バックアップ計画データで指定されたページｐ３の書き出し時刻になったので、ページｐ１、ｐ２と同様に、バックアップデータ８２への通常書き出しを実行するとともに、バックアップ管理テーブル３０のフラグを更新する。

その後、時刻ｔ５において、バックアップ処理部２６は、バックアップ処理ｂｋ１の過程で、バックアップ計画データで指定されたページｐ４の書き出し時刻になったものの、ページｐ４は、既に時刻ｔ３で臨時書き出しが実行されたため、ページｐ４のバックアップ処理を省略して、バックアップ処理ｂｋ１を完了する。なお、バックアップ処理部２６は、バックアップ管理テーブル３０のページｐ４に対応するフラグが「済」であることにより、ページｐ４のバックアップ処理の省略を決定する。
以上説明したバックアップ処理ｂｋ１により、時刻ｔ１時点でのインメモリデータベース３１のデータ内容（図６参照）と、時刻ｔ４時点でのバックアップデータ８２のデータ内容（図９参照）とが、同一化される。

以上、インメモリデータベース３１からバックアップデータ８２へのバックアップ処理について、説明した。次に、回復処理部２７が実行する、バッチ処理に障害が発生したときの、バックアップデータ８２からインメモリデータベース３１へのデータ回復（データ書き戻し）処理について、２つのケースを順に説明する。
第１のケースは、図１０〜図１２が示す、バックアップ処理ｂｋ１の完了前に障害が発生したケースである。
第２のケースは、図１３〜図１５が示す、バックアップ処理ｂｋ１の完了後に障害が発生したケースである。

図１０は、第１のケースにおけるデータ回復処理の概要を示す説明図である。この説明図は、図５と同様に、横軸を時間軸とするガントチャート形式で記述される。

時刻ｔ０〜ｔ３の時間帯での処理は、図５と同じである。つまり、バックアップ処理部２６は、バックアップ計画データ（図４参照）に従って、ページｐ１，ｐ２の通常書き出しを実行する。そして、ＤＢアクセス処理部２５は、ページｐ４の更新に伴い、ページｐ４の臨時書き出しを実行する。

時刻ｔ１１において、バッチ処理ｂ２およびバックアップ処理ｂｋ１が並列に実行されているときに、バッチ処理ｂ２に障害が発生してしまう。バックアップ処理部２６は、ＤＢアクセス処理部２５から障害発生の通知を受け、バックアップ処理ｂｋ１を停止し、インメモリデータベース３１の回復処理ｒ１を行う。

図１１に示すように、時刻ｔ１１においては、バックアップデータ８２は、ページｐ１，ｐ２，ｐ４のデータを記憶している。バックアップ処理部２６は、バックアップ管理テーブル３０のフラグを参照し、「済」になっているページｐ１，ｐ２，ｐ４のデータを、回復対象のページとして特定する。

図１２に示すように、バックアップ処理部２６は、回復対象のページｐ１，ｐ２，ｐ４のデータを、バックアップデータ８２から読み出して、インメモリデータベース３１に書き戻す。
これにより、インメモリデータベース３１のデータ内容は、時刻ｔ１の時点へと回復する。図１０に戻って、回復処理ｒ１を終えた後、端末７０およびＤＢアクセス処理部２５は、バッチ処理ｂ２を再開し、バックアップ処理部２６は、バックアップ処理ｂｋ１を再開する。

図１３は、第２のケースにおけるデータ回復処理の概要を示す説明図である。

時刻ｔ０〜ｔ５の時間帯での処理は、図５と同じである。つまり、バックアップ処理部２６は、バックアップ計画データ（図４参照）に従って、ページｐ１，ｐ２，ｐ３の通常書き出しを実行する。そして、ＤＢアクセス処理部２５は、ページｐ４の更新に伴い、ページｐ４の臨時書き出しを実行する。さらに、バックアップ処理部２６は、ページｐ１〜ｐ４のバックアップが完了したので、バックアップ処理ｂｋ１を終了する。

図１４に示すように、時刻ｔ２１で、バッチ処理ｂ２に障害が発生した場合、端末７０およびＤＢアクセス処理部２５は、そのバッチ処理ｂ２を停止した後、バックアップ処理部２６に対して、インメモリデータベース３１の回復処理ｒ１を依頼する。

図１５に示すように、時刻ｔ２２において、バックアップ処理部２６は、時刻ｔ１の時点のバックアップデータ８２を、インメモリデータベース３１へと書き戻す。図１２と比較すると、バックアップ管理テーブル３０のフラグが全て「済」になっている点が異なる。

図１６は、バックアップ処理部２６が実行する、通常書き出しによるバックアップ処理を示すフローチャートである。

このフローチャートは、バックアップ対象ページが書き出し時刻になるたび、もしくはページを書き出す順番になるたびに、バックアップ対象ページごとに実行される。

Ｓ１０１において、バックアップ処理部２６は、バックアップ管理テーブル３０を参照して、バックアップ対象ページがバックアップ「済」であるときには（Ｓ１０１，Ｙｅｓ）、バックアップ処理を省略して、処理を終了する。

Ｓ１０２において、バックアップ処理部２６は、バックアップ「未」である（Ｓ１０１，Ｎｏ）ときには、バックアップ対象ページのデータ内容を、インメモリデータベース３１から読み取り、バックアップデータ８２として書き出す。

図１７は、ＤＢアクセス処理部２５が実行する、臨時書き出しによるバックアップ処理を示すフローチャートである。このフローチャートは、ＤＢアクセス処理部２５がバッチ処理に伴うデータアクセスにより、バックアップ対象ページの内容をバックアップの対象時刻のデータ内容から更新するときに、バックアップ対象ページごとに実行される。

Ｓ２０１において、ＤＢアクセス処理部２５は、バックアップ処理中フラグ２９を参照して、バックアップ処理部２６による通常書き出し処理が「処理中」のときには（Ｓ２０１，Ｙｅｓ）処理をＳ２０２へ進め、「未処理」のときには（Ｓ２０１，Ｎｏ）処理をＳ２０４へ進める。

Ｓ２０２において、ＤＢアクセス処理部２５は、バックアップ管理テーブル３０を参照して、バックアップ対象ページがバックアップ「済」であるときには（Ｓ２０２，Ｙｅｓ）、バックアップ処理を省略して、処理をＳ２０４に進める。

Ｓ２０３において、ＤＢアクセス処理部２５は、バックアップ「未」である（Ｓ２０２，Ｎｏ）ときには、バックアップ対象ページの更新前のデータ内容を、インメモリデータベース３１から読み取り、バックアップデータ８２として書き出す。

Ｓ２０４において、ＤＢアクセス処理部２５は、バックアップ対象ページの更新後のデータ内容を、インメモリデータベース３１に書き出す。

Ｓ２０５において、データベース管理装置１のプロセッサ１０は、Ｓ２０４のデータ更新処理の要求元がバッチ処理を実行する端末７０か否かを判定する。判定条件を満たすとき（Ｓ２０５，Ｙｅｓ）にはＳ２０６へ進み、満たさないとき（Ｓ２０５，Ｎｏ）には処理を終了する。

Ｓ２０６において、ＤＢアクセス処理部２５は、バッチ処理に伴い、Ｓ２０４でのインメモリデータベース３１へのデータ更新内容について、そのバッチ処理のバッチ処理ＩＤと、データ更新の対象となるページＩＤと、そのデータ更新の更新時刻と、を対応づけてＤＢアクセス履歴５３に書き込む。

以上により、本実施形態によれば、バックアップ処理と、バッチ処理とを並列に実行することによって、バッチ処理および運用業務の総所要時間を短縮することができる。
なお、バックアップ処理と、バッチ処理とを単に組み合わせて並列化しただけでは、データの上書き問題が発生してしまう。
そこで、本実施形態では、データの上書きが発生する状況下では、臨時書き出しを実行することにより、バックアップ対象ページの上書きによる消去を回避する。
さらに、本実施形態では、ＤＢアクセス履歴５３から抽出したデータアクセスの履歴内容をもとに、高精度なバックアップ計画データを作成することにより、バッチ処理に影響を与える臨時書き出しの実行頻度を低減させることができる。

本発明の一実施形態に関するデータベース管理システムの構成を示す構成図である。 本発明の一実施形態に関するデータベースなどのデータ内容の一例を示す説明図である。 本発明の一実施形態に関するＤＢアクセス履歴の一例を示す構成図である。 本発明の一実施形態に関するバックアップ処理部が作成する、バックアップ計画データの一例を示す構成図である。 本発明の一実施形態に関するデータベース管理システムが実行するバックアップ処理の概要を示す説明図である。 本発明の一実施形態に関する図５における所定時点でのデータ内容を示す説明図である。 本発明の一実施形態に関する図５における所定時点でのデータ内容を示す説明図である。 本発明の一実施形態に関する図５における所定時点でのデータ内容を示す説明図である。 本発明の一実施形態に関する図５における所定時点でのデータ内容を示す説明図である。 本発明の一実施形態に関する第１のケースにおけるデータ回復処理の概要を示す説明図である。 本発明の一実施形態に関する図１０における所定時点でのデータ内容を示す説明図である。 本発明の一実施形態に関する図１０における所定時点でのデータ内容を示す説明図である。 本発明の一実施形態に関する第２のケースにおけるデータ回復処理の概要を示す説明図である。 本発明の一実施形態に関する図１３における所定時点でのデータ内容を示す説明図である。 本発明の一実施形態に関する図１３における所定時点でのデータ内容を示す説明図である。 本発明の一実施形態に関するバックアップ処理部が実行する、通常書き出しによるバックアップ処理を示すフローチャートである。 本発明の一実施形態に関するＤＢアクセス処理部が実行する、臨時書き出しによるバックアップ処理を示すフローチャートである。 各バッチ処理に対するバックアップ処理を示す説明図である。 バッチ処理時間を短縮する方法を示す説明図である。 インメモリ化によるバックアップ処理を示す説明図である。

符号の説明

１ データベース管理装置
１０ プロセッサ
２０ メモリ
２１ ＤＢアクセス要求受付部
２２ バックアップ要求受付部
２３ 回復要求受付部
２４ インメモリ要求受付部
２５ ＤＢアクセス処理部
２６ バックアップ処理部
２７ 回復処理部
２８ インメモリ処理部
２９ バックアップ処理中フラグ
３０ バックアップ管理テーブル
３１ インメモリデータベース
５０ ストレージ装置
５１ 記憶装置
５２ データベース
５３ ＤＢアクセス履歴
６０ ネットワーク
７０ 端末
８０ バックアップ装置
８１ 記憶装置
８２ バックアップデータ

Claims (9)

1. データベースに格納されたデータを管理するデータベース管理装置によるデータベース管理方法であって、
   前記データベース管理装置は、データアクセス処理部と、バックアップ処理部と、を有し、
   前記バックアップ処理部は、
   記憶装置に格納される前記データベースの所定時刻におけるデータを、前記所定時刻後のうちのバックアップ計画データに従ったタイミングで前記データベースからバックアップデータとして書き出すこととし、そのバックアップ計画データは、前記データベースへのデータアクセスのうちの最終のバッチ処理に伴って発生したデータアクセスを除く既に作成されたデータアクセス履歴に格納されている過去のデータごとの実行時刻を参照し、実行時刻が先であるデータほど、先に前記バックアップデータとして書き出すタイミングを規定するデータであり、
   前記データアクセス処理部は、
   前記データベースへのデータアクセス要求に応じて、前記データベースへのデータアクセスを実行し、そのデータアクセス対象のデータのＩＤと、そのデータアクセスの実行時刻と、を対応づけて前記データアクセス履歴として作成して記憶装置に格納し、
   前記所定時刻後のデータアクセス要求において、前記バックアップデータとして書き出されていないデータに対する更新要求が発生したときには、前記所定時刻におけるデータを前記データベースから前記バックアップデータとして書き出した後、前記更新要求に従って、前記データベースのデータを更新し、
   前記データベース管理装置は、前記バックアップ処理部の処理と、前記データアクセス処理部の処理とを、並行に処理することを特徴とする
   データベース管理方法。
2. データベースに格納されたデータを管理するデータベース管理装置によるデータベース管理方法であって、
   前記データベース管理装置は、データアクセス処理部と、バックアップ処理部と、を有し、
   前記バックアップ処理部は、
   記憶装置に格納される前記データベースの所定時刻におけるデータを、前記所定時刻後のうちのバックアップ計画データに従ったタイミングで前記データベースからバックアップデータとして書き出すこととし、そのバックアップ計画データは、前記データベースへのデータアクセスのうちの最終のバッチ処理に伴って発生したデータアクセスを除く既に作成されたデータアクセス履歴に格納されている過去のデータごとの実行時刻を参照し、そのデータ間の実行時刻の平均順序を計算し、その平均順序が先であるデータほど、先に前記バックアップデータとして書き出すタイミングを規定するデータであり、
   前記データアクセス処理部は、
   前記データベースへのデータアクセス要求に応じて、前記データベースへのデータアクセスを実行し、そのデータアクセス対象のデータのＩＤと、そのデータアクセスの実行時刻と、を対応づけて前記データアクセス履歴として作成して記憶装置に格納し、
   前記所定時刻後のデータアクセス要求において、前記バックアップデータとして書き出されていないデータに対する更新要求が発生したときには、前記所定時刻におけるデータを前記データベースから前記バックアップデータとして書き出した後、前記更新要求に従って、前記データベースのデータを更新し、
   前記データベース管理装置は、前記バックアップ処理部の処理と、前記データアクセス処理部の処理とを、並行に処理することを特徴とする
   データベース管理方法。
3. 前記データベース管理装置は、
   データアクセスの対象となる前記データベースを、前記データベース管理装置内のメモリに配置するインメモリデータベースとし、
   前記バックアップデータとして書き出す先の記憶装置を、前記データベース管理装置からアクセス可能な記憶装置とすることを特徴とする
   請求項１または請求項２に記載のデータベース管理方法。
4. 前記データベース管理装置は、前記データベースのデータ毎にバックアップ済か否かを示すバックアップ管理データを記憶装置に格納し、
   前記バックアップ処理部および前記データアクセス処理部は、それぞれ
   前記バックアップデータとして書き出したデータについて、前記バックアップ管理データの該当データをバックアップ済とし、
   前記バックアップデータとして所定データを書き出す前に、前記バックアップ管理データの前記所定データがバックアップ済か否かを参照し、バックアップ済であるときには、前記所定データを書き出す処理を省略することを特徴とする
   請求項１ないし請求項３のいずれか１項に記載のデータベース管理方法。
5. 前記バックアップ処理部および前記データアクセス処理部のうち、バックアップを実行する一方の処理部は、前記バックアップデータとして前記所定データを書き出す前に、他方の処理部がデータ書き出し処理を実行しているか否かを参照し、
   前記他方の処理部によるデータ書き出し処理が実行中であるときには、前記一方の処理部はその実行が終わるまで、一時的に待機することを特徴とする
   請求項１ないし請求項４のいずれか１項に記載のデータベース管理方法。
6. 前記データベース管理装置は、さらに、回復処理部を有し、
   前記回復処理部は、前記所定時刻後に前記データベースへのデータ回復要求を受けると、前記バックアップ処理部および前記データアクセス処理部によってそれぞれ書き出された前記所定時刻時点での前記バックアップデータを、前記データベースへと書き戻すことを特徴とする
   請求項１ないし請求項５のいずれか１項に記載のデータベース管理方法。
7. 請求項１ないし請求項６のいずれか１項に記載のデータベース管理方法を、コンピュータである前記データベース管理装置に実行させるためのデータベース管理プログラム。
8. データベースに格納されたデータを管理するデータベース管理装置であって、
   前記データベース管理装置は、データアクセス処理部と、バックアップ処理部と、を有し、
   前記バックアップ処理部は、
   記憶装置に格納される前記データベースの所定時刻におけるデータを、前記所定時刻後のうちのバックアップ計画データに従ったタイミングで前記データベースからバックアップデータとして書き出すこととし、そのバックアップ計画データは、前記データベースへのデータアクセスのうちの最終のバッチ処理に伴って発生したデータアクセスを除く既に作成されたデータアクセス履歴に格納されている過去のデータごとの実行時刻を参照し、実行時刻が先であるデータほど、先に前記バックアップデータとして書き出すタイミングを規定するデータであり、
   前記データアクセス処理部は、
   前記データベースへのデータアクセス要求に応じて、前記データベースへのデータアクセスを実行し、そのデータアクセス対象のデータのＩＤと、そのデータアクセスの実行時刻と、を対応づけて前記データアクセス履歴として作成して記憶装置に格納し、
   前記所定時刻後のデータアクセス要求において、前記バックアップデータとして書き出されていないデータに対する更新要求が発生したときには、前記所定時刻におけるデータを前記データベースから前記バックアップデータとして書き出した後、前記更新要求に従って、前記データベースのデータを更新し、
   前記データベース管理装置は、前記バックアップ処理部の処理と、前記データアクセス処理部の処理とを、並行に処理することを特徴とする
   データベース管理装置。
9. データベースに格納されたデータを管理するデータベース管理装置であって、
   前記データベース管理装置は、データアクセス処理部と、バックアップ処理部と、を有し、
   前記バックアップ処理部は、
   記憶装置に格納される前記データベースの所定時刻におけるデータを、前記所定時刻後のうちのバックアップ計画データに従ったタイミングで前記データベースからバックアップデータとして書き出すこととし、そのバックアップ計画データは、前記データベースへのデータアクセスのうちの最終のバッチ処理に伴って発生したデータアクセスを除く既に作成されたデータアクセス履歴に格納されている過去のデータごとの実行時刻を参照し、そのデータ間の実行時刻の平均順序を計算し、その平均順序が先であるデータほど、先に前記バックアップデータとして書き出すタイミングを規定するデータであり、
   前記データアクセス処理部は、
   前記データベースへのデータアクセス要求に応じて、前記データベースへのデータアクセスを実行し、そのデータアクセス対象のデータのＩＤと、そのデータアクセスの実行時刻と、を対応づけて前記データアクセス履歴として作成して記憶装置に格納し、
   前記所定時刻後のデータアクセス要求において、前記バックアップデータとして書き出されていないデータに対する更新要求が発生したときには、前記所定時刻におけるデータを前記データベースから前記バックアップデータとして書き出した後、前記更新要求に従って、前記データベースのデータを更新し、
   前記データベース管理装置は、前記バックアップ処理部の処理と、前記データアクセス処理部の処理とを、並行に処理することを特徴とする
   データベース管理装置。

Images