JP2014241059A - オンラインバックアップ制御システム及びプログラム - Google Patents

Abstract

【課題】データベースを、複数のアプリケーションからみて整合性のとれた状態でオンラインバックアップできるようにする。【解決手段】データベースＩ／Ｏ部３０は、対応するアプリケーション１０ａ又は１０ｂからのデータベース２０への読み書きを制御する。オンラインバックアップの指示があるとステータス管理部３２内の各データベースＩ／Ｏ部３０の状態が「抑制依頼中」となる。抑制依頼中のデータベースＩ／Ｏ部３０は、既に更新を始めているセッションについては、アプリケーション１０から更新確定指示が来るまではデータベース２０への更新指示を受け付ける。更新確定指示が来た後はそのセッションについての新たな更新指示は受け付けない。すべてのデータベースＩ／Ｏ部３０がすべてのセッションについて更新指示を受け付けない状態となってから、オンラインバックアップトリガー部３４がオンラインバックアップ部２２に処理の開始を指示する。【選択図】図１

Description

本発明は、オンラインバックアップ制御システム及びプログラムに関する。

可用性向上（２４時間３６５日対応など）の実現などを目的として、データベースを起動した状態のままバックアップを取る機能（オンラインバックアップ機能と呼ばれる）を備えたデータベースが存在する。

このデータベースが有するオンラインバックアップ機能では、文書管理システム等のアプリケーションがデータベースに対して行う更新処理を確定するタイミングと、データベース側で行われるオンラインバックアップ処理のタイミングを完全に同期させることは保証されないため、バックアップデータがアプリケーションのデータとしては不正（想定外）の状態になる可能性がある。

この問題に対する解決策の一例として、特許文献１に開示された技術では、オンラインバックアップを実施する際に更新内容を更新リストに記録している。そして、リストア時に、バックアップデータと記録しておいた更新内容を比較し、バックアップデータに対して、更新してしまった内容を元に戻すための更新処理を実行したり、逆にバックアップデータに対して足りない更新処理を行ったりすることで、文書管理システムとして整合性のとれたデータに修正する。

特開２０１２−０５３６６０号公報

本発明は、複数のアプリケーションがデータベースに対して更新を行う場合において、データベースを、それら複数のアプリケーションのいずれからみても整合性のとれた状態で、オンラインバックアップできるようにすることを目的とする。

請求項１に係る発明は、複数のアプリケーションの各々の状態を記憶する状態記憶手段と、前記複数のアプリケーションのうちの少なくとも１つからデータベースの更新指示を受け取り、受け取った前記更新指示に応じて前記データベースを更新するか否かを制御する少なくとも１つの更新制御手段と、前記データベースのオンラインバックアップの開始条件が満たされた場合、前記状態記憶手段に記憶された前記複数のアプリケーションの状態をすべてあらかじめ定められた第１の状態とすると共に、前記状態記憶手段に記憶された前記複数のアプリケーションの状態がすべてあらかじめ定められた第２の状態となったことを検知すると、前記データベースのオンラインバックアップを開始するための制御を行うオンラインバックアップ制御手段と、を有し、前記更新制御手段は、受け取った前記更新指示を発したアプリケーションの状態が前記第１の状態である場合、当該更新指示に対応するセッションにおける当該アプリケーションからの他の更新指示に応じて前記データベースの更新を既に行っており且つ当該セッションについての更新確定指示を当該アプリケーションからまだ受け取っていなければ、前記更新指示に応じて前記データベースを更新し、受け取った前記更新指示に対応するセッションについての更新確定指示を当該アプリケーションから既に受け取っているか又は当該更新指示の前に当該セッションにおける他の更新指示に応じて前記データベースの更新を一度も行っていなければ、当該更新指示に応じた前記データベースの更新を少なくとも前記オンラインバックアップが完了するまでは取りやめると共に、前記第１の状態にある前記アプリケーションが実行しているすべてのセッションについて前記更新指示に応じた前記データベースの更新を取りやめた状態となると、前記状態記憶手段に記憶された当該アプリケーションの状態を前記第２の状態に変更する、ことを特徴とするオンラインバックアップ制御システムである。

請求項２に係る発明は、前記更新制御手段は、受け取った前記更新指示に対応するセッションについての更新確定指示を当該アプリケーションから既に受け取っているか又は当該更新指示の前に当該セッションにおける他の更新指示に応じて前記データベースの更新を一度も行っていなければ、当該更新指示を待機させると共に、前記オンラインバックアップが完了すると、待機させていた前記更新指示に応じて前記データベースの更新が行われるようにする、ことを特徴とする請求項１に記載のオンラインバックアップ制御システムである。

請求項３に係る発明は、コンピュータを、複数のアプリケーションの各々の状態を記憶する状態記憶手段、前記複数のアプリケーションのうちの少なくとも１つからデータベースの更新指示を受け取り、受け取った前記更新指示に応じて前記データベースを更新するか否かを制御する少なくとも１つの更新制御手段、前記データベースのオンラインバックアップの開始条件が満たされた場合、前記状態記憶手段に記憶された前記複数のアプリケーションの状態をすべてあらかじめ定められた第１の状態とすると共に、前記状態記憶手段に記憶された前記複数のアプリケーションの状態がすべてあらかじめ定められた第２の状態となったことを検知すると、前記データベースのオンラインバックアップを開始するための制御を行うオンラインバックアップ制御手段、として機能させるためのプログラムであって、前記更新制御手段は、受け取った前記更新指示を発したアプリケーションの状態が前記第１の状態である場合、当該更新指示に対応するセッションにおける当該アプリケーションからの他の更新指示に応じて前記データベースの更新を既に行っており且つ当該セッションについての更新確定指示を当該アプリケーションからまだ受け取っていなければ、前記更新指示に応じて前記データベースを更新し、受け取った前記更新指示に対応するセッションについての更新確定指示を当該アプリケーションから既に受け取っているか又は当該更新指示の前に当該セッションにおける他の更新指示に応じて前記データベースの更新を一度も行っていなければ、当該更新指示に応じた前記データベースの更新を少なくとも前記オンラインバックアップが完了するまでは取りやめると共に、前記第１の状態にある前記アプリケーションが実行しているすべてのセッションについて前記更新指示に応じた前記データベースの更新を取りやめた状態となると、前記状態記憶手段に記憶された当該アプリケーションの状態を前記第２の状態に変更する、ことを特徴とするプログラムである。

請求項１又は３に係る発明によれば、複数のアプリケーションがデータベースに対して更新を行う場合において、データベースを、それら複数のアプリケーションのいずれからみても整合性のとれた状態で、オンラインバックアップできる。

請求項２に係る発明によれば、第１の状態にあるアプリケーションから発せられた更新指示に応じたデータベースの更新を取りやめた場合において、オンラインバックアップが完了した後に、アプリケーションが再度その更新指示を発行しなくても、その更新指示に応じた更新を実行することができる。

実施形態のシステム構成の一例を示す図である。 Ｉ／Ｏステータス管理テーブルのデータ内容の一例を示す図である。 セッションステータス管理テーブルのデータ内容の一例を示す図である。 データベースＩ／Ｏ部の処理手順の一例を説明する。 オンラインバックアップトリガー部の処理手順の一例を説明する。 処理の進行に応じたＩ／Ｏステータス管理テーブルのデータ内容の変遷の例を示す図である。

以下、図面を参照して,本発明の実施形態を説明する。

まず、図１を参照して、本実施形態のシステム構成の一例を説明する。図１において、アプリケーション１０ａ、１０ｂは、文書管理などといった特定の目的のために使用されるソフトウエアである。アプリケーション１０ａ、１０ｂは、互いに別の目的のためのソフトウエアであってよい。

アプリケーション１０ａ、１０ｂは、それぞれ、自らの処理の実行の中で、データベース２０に対して読み書きを行う。アプリケーション１０ａ、１０ｂは、データベース２０に格納されたデータオブジェクトを参照する場合には、参照指示を発する。また、データベース２０内のオブジェクトを更新する場合には、更新指示を発する。ここで、データベース２０の「更新」には、データベース２０内にある既存のオブジェクトのデータ内容を変更する処理と、データベース２０に対して新規のオブジェクトを登録する処理との両方が含まれるものとする。また、更新指示に対応する更新が完了して、その更新結果を確定する場合は、更新確定指示を発する。

ここで、アプリケーション１０ａ、１０ｂは、データベース２０内の互いに関連する複数のデータオブジェクト（データ項目）を、１つのセッションの中でまとめて更新する。

すなわち、それら互いに関連する複数のデータオブジェクトは、データベース２０内では複数のオブジェクトに別れているが、アプリケーションからみれば、それら複数のオブジェクトの値の組合せが１つの意味を有している。したがって、アプリケーションがそれら互いに関連する複数のオブジェクトを更新する場合、それら複数のオブジェクトが全て更新前の状態であるか、全て更新後の状態であるかが、そのアプリケーションが想定している、意味のある状態である。データベース２０がこのようにアプリケーションが想定している状態にあることを、「データベースの整合性がとれている」状態と呼ぶ。逆に、それら複数のオブジェクトの中に更新済みのものと未更新のものとが混在する状態は、更新を指示したアプリケーションにとっては想定外の状態である。データベース２０がこのようにアプリケーションから見て想定外の状態にあることを、「データベースの整合性がとれていない」状態と呼ぶ。例えば、電子掲示板にメッセージを登録する際、そのメッセージの内容、投稿者及び投稿日時という３つのオブジェクトをデータベースに登録するが、それら３つのオブジェクトのうちの１つでも欠けると、電子掲示板のメッセージとしては完全なものではなくなる。これが「整合性がとれていない状態」である。逆に３つのオブジェクトが全部揃って更新された状態は、「整合性がとれている状態」である。

各アプリケーション１０ａ、１０ｂは、そのようにまとめて更新すべき１以上のオブジェクトを１つのセッション内でまとめて更新することで、データベース２０が常に「整合性がとれている状態」になるようにする。

アプリケーション１０ａ、１０ｂは、１つのデータベース更新セッションのなかで、更新（すなわちデータ内容の変更、又は新規登録）対象の各オブジェクトについての更新指示を順次（データベースＩ／Ｏ部３０経由で）データベース２０に送る。そして、アプリケーション１０ａ、１０ｂは、まとめて更新すべき互いに関連する複数のオブジェクトのすべてについて更新が完了した段階で、データベース２０に対して、それらすべてのオブジェクトの更新の確定を指示する。このように、まとめて更新すべき全オブジェクトの更新が完了し、これに応じてアプリケーションが更新確定指示を発すると、その指示を受けたデータベース２０がそれら全オブジェクトの更新結果を確定状態にする。この状態が、そのアプリケーションにとってデータベース２０の「整合性がとれている状態」である。逆に、まとめて更新すべきそれらオブジェクトのうちの一部のオブジェクトのみ更新され、残りが更新されていない状態は、アプリケーションが想定している整合状態ではない。このような不整合状態（前述の「整合性がとれていない状態」のこと）では、アプリケーション１０ａ、１０ｂは更新確定指示を出さないので、データベース２０が「整合性がとれていない状態」のまま更新が確定されることはない。

アプリケーション１０ａ、１０ｂは、１セッションの中で、まとめて更新すべき互いに関連するオブジェクトの組を複数組、更新するよう指示する場合もある。この場合、アプリケーション１０ａ、１０ｂは、データベース２０との間での読み書きのセッションを開始した後、そのセッションの中でまず第１の組に含まれる各オブジェクトについての更新指示を順に発し、それらオブジェクトのすべてについてデータ更新が完了した旨の応答をデータベース２０から受けると、第１の組についての更新確定指示を発する。続いて、そのセッションの中で、第２の組に含まれる各オブジェクトについて順に更新指示を発行し、それらオブジェクトのすべてについて更新が完了すると、第２の組についての更新確定指示を発する。このように、アプリケーションは、１セッションの中で、まとめて更新すべきオブジェクトの組ごとに更新確定指示を発するように構成されていてもよい。

さて、本実施形態では、アプリケーション１０ａ、１０ｂは、データベース２０に対して直接読み書きを行うのではなく、データベースＩ／Ｏ部３０を介して読み書きを行う。すなわち、アプリケーション１０ａ、１０ｂは、それぞれ、データベース２０に対する参照指示、更新指示、及び更新確定指示を、データベース２０に送るのではなく、対応するデータベースＩ／Ｏ部３０に対して送る。

アプリケーション１０ａ、１０ｂが発するそれら読み書きのための指示（参照指示、更新指示、及び更新確定指示）は、データベースＩ／Ｏ部３０が存在せず、アプリケーションとデータベースとが直接やりとりを行う従来構成において、アプリケーションがデータベースに対して発行する指示と同じものとしてもよい。

この実施形態では、アプリケーション１０ａ、１０ｂは、従来、データベース２０に対して直接送っていた読み書きのための指示を、データベースＩ／Ｏ部３０に送るようにしたものであり、その他の点では従来の同様のアプリケーションと同じでよい。

また、これらアプリケーション１０ａ、１０ｂは、互いに連携して１つの大きな目的を達成する機能を有していてもよい。例えば、アプリケーション１０ａが電子掲示板等を管理するメッセージングアプリケーションであり、アプリケーション１０ａが文書群を管理する文書管理システムアプリケーションである場合がその一例である。このケースでは、ユーザから前者に対してメッセージと添付文書がアップロードされた場合、１つのセッションの中で、前者は、メッセージをデータベース２０に書き込むと共に、後者に対して添付文書のデータベース２０への登録を依頼する。この結果、前者と後者がそれぞれデータベース２０の更新を行うこととなる。この例では、前者のメッセージ登録機能と後者の文書登録機能とが連携して、メッセージとそれに対応した添付文書とのデータベース登録という大きな目的を達成する。

ここで、複数のアプリケーションによる連携したデータベース更新は、１つのセッション内で行われる。上述の例で言えば、アプリケーション１０ａによるメッセージのデータベース２０への登録と、アプリケーション１０ｂによる添付文書のデータベースへの登録とは、それら２つのアプリケーションが連携した１つのセッションとして行われる。これにより、異なる複数のアプリケーションが、それぞれ互いに関連するオブジェクトの更新を行う際に、それらオブジェクト群が「整合性がとれている状態」になるよう一括して更新されるようにする。

図１には、２つのアプリケーション１０ａ、１０ｂを図示したが、データベース２０を利用するアプリケーションが３以上存在してももちろんよい。

データベース２０は、それらアプリケーションが利用するデータを保持しており、データベースＩ／Ｏ部３０を介した各アプリケーションからの指示に従い、保持しているデータをアプリケーションに提供したり、保持しているデータを新しい値に更新したりする。

アプリケーション１０ａ、１０ｂから、後述するデータベースＩ／Ｏ部３０経由で参照指示を受けた場合、データベース２０は、その指示の対象として指定されたオブジェクトのデータ内容を、指示元のアプリケーション宛に送信する。この参照処理では、対象となったオブジェクトは変更されない。また更新指示を受けた場合には、自分自身が保持するその更新指示の対象のオブジェクトを、その指示に応じたデータ内容に更新する（あるいは、更新指示が新たなオブジェクトの登録を指示するものである場合はその登録を行う）。データベース２０は、保持するオブジェクトごとにそのオブジェクトが確定状態であるか否かを示すフラグ情報を有しており、更新指示に応じてオブジェクトの更新を行った時点ではそのオブジェクトのフラグ情報は未確定状態を示す値にする。また、あるセッションの中でアプリケーション１０ａ、１０ｂから更新確定指示を受けた場合、データベース２０は、そのセッションにおいてこれまでに更新した、未確定状態のオブジェクトのフラグ情報を、確定状態を示す値に変更する。

データベース２０は、データベースＩ／Ｏ部３０経由で受け取ったアプリケーション１０ａ、１０ｂからの指示に対する応答を、そのデータベースＩ／Ｏ部３０経由でアプリケーション１０ａ、１０ｂに返す。すなわち、データベース２０は、アプリケーション１０ａ、１０ｂが発した更新指示等の指示を、データベースＩ／Ｏ部３０から受け取るので、その指示に対する応答は、その指示の発信元であるデータベースＩ／Ｏ部３０に返せばよい。その応答を受け取ったデータベースＩ／Ｏ部３０は、その応答を、その指示を指示元であるアプリケーション１０ａ又は１０ｂに転送する。

データベース２０は、物理的に１つのコンピュータ上に構築されてもよいし、複数の別々のコンピュータ上に分散されて構築されていてよい。

また、データベース２０は、例えば電子掲示板のメッセージ群とそれらメッセージに添付された文書ファイルのように、異なる種類のデータオブジェクト（この例ではメッセージ、文書ファイルがそれぞれオブジェクトである）を格納することができる。データベース２０は、そのような複数種類のオブジェクトを格納可能な論理的に１つのデータベースであってもよいし、個々の種類のオブジェクトを格納するための論理的なデータベースが複数集まった集合体であってもよい。

この実施形態では、データベース２０は、アプリケーション１０ａ、１０ｂからの指示を、データベースＩ／Ｏ部３０を介して受け取る。

データベース２０は、保持しているデータオブジェクトに対する読み書きの指示を、アプリケーション１０ａ、１０ｂから直接ではなく、データベースＩ／Ｏ部３０を介して受け取る点以外は、従来のデータベースと同様である。

データベースＩ／Ｏ部３０は、アプリケーション１０ａ、１０ｂとデータベース２０との間に介在し、アプリケーション１０ａ、１０ｂとデータベース２０との間の指示及びデータのやりとりを制御する。

図示例では、データベースＩ／Ｏ部３０は、１つ１つのアプリケーション１０ａ、１０ｂに対応して１つずつ設けられている。アプリケーション１０ａ、１０ｂは、データベース２０に対して読み書きを行う際、その読み書きのための指示を、対応するデータベースＩ／Ｏ部３０に送る。

データベースＩ／Ｏ部３０は、アプリケーション１０ａ、１０ｂとデータベース２０との間の指示、データのやりとりの制御の中で、後述するステータス管理部３２と連携して、オンラインバックアップ中にデータベース２０の更新（すなわちデータベース２０内に保存されたオブジェクトの更新）が行われないようにする。このオンラインバックアップ対応のための制御については、後で詳しく説明する。

ステータス管理部３２は、各アプリケーション１０ａ、１０ｂに対応する各データベースＩ／Ｏ部３０のステータス（状態）を保持し、管理する。データベースＩ／Ｏ部３０のステータスには、「通常」、「抑制依頼中」、「抑制完了」の３つがある。

ステータス「通常」は、対応するアプリケーション１０ａ又は１０ｂが当該データベースＩ／Ｏ部３０を介してデータベース２０に対して通常通り読み書きを行うことができる状態である。

ステータス「抑制依頼中」は、データベースＩ／Ｏ部３０が後述するオンラインバックアップトリガー部３４から「抑制依頼」を受けてから、その「抑制依頼」を受けた時点で既に実行中のすべてのデータベース更新セッションが完了（「更新確定」）されるまでの状態である。また、ステータス「抑制完了」とは、「抑制依頼中」状態にあるデータベースＩ／Ｏ部３０が実行していたすべてのデータベース更新セッションが「更新確定」された場合の遷移先の状態である。本実施形態では、すべてのデータベースＩ／Ｏ部３０が「抑制完了」状態となってはじめて、オンラインバックアップが実行される。そして、オンラインバックアップが完了すると、各データベースＩ／Ｏ部３０のステータスは、「抑制完了」状態から「通常」状態に変更される。

「抑制依頼」及び「抑制完了」というステータスの理解を助けるために、その技術的な意義を以下に説明する。

本実施形態では、データベース２０のオンラインバックアップを開始する前に、データベースＩ／Ｏ部３０が、対応するアプリケーション１０ａ又は１０ｂからのデータベース２０に対するデータベース更新指示を抑制する。すなわち、データベースＩ／Ｏ部３０がアプリケーション１０ａ及び１０ｂからの更新指示をデータベース２０に伝達しないことで、データベース２０が更新されない状態を作り出す。そして、このようにデータベース２０が更新されない状態を作り出した後で、データベース２０のオンラインバックアップを実行する。

ここで、オンラインバックアップの開始条件が満たされる（例えばユーザから明示的に開始指示があった場合や、規則により導かれる開始タイミングが到来した場合）と同時に各アプリケーション１０ａ及び１０ｂからの更新指示を完全に抑制したのでは、アプリケーションによる１つのデータベース更新セッションの途中でデータベース２０の更新が抑制されてしまう場合がある。この場合、アプリケーションがそのセッションでまとめて更新しようとしている複数のオブジェクトのうちの一部のみが更新され、残りが未更新のままとなってしまう。この状態は、そのアプリケーションからみて不整合状態（「整合性がとれていない状態」）であり、仮にこの状態のデータベース２０がオンラインバックアップされても、そのバックアップ結果は、そのアプリケーションが想定していない（すなわちそのアプリケーションがそのままでは正しく処理できない）ものとなる。このようにアプリケーションがそのままでは正しく処理できないようなバックアップデータを作成することは、有益であるとはいえない。

そこで、本実施形態では、オンラインバックアップの開始条件が満たされたときに即座にそのオンラインバックアップを実行するのではなく、データベース２０の状態がすべてのアプリケーション１０ａ及び１０ｂにとって「整合性がとれている状態」となるまで待ってからオンラインバックアップを実行する。すなわち、このようにデータベース２０がすべてのアプリケーション１０ａ及び１０ｂにとって「整合性がとれている状態」で、それらすべてのアプリケーション１０ａ及び１０ｂからの更新指示を待機させつつ、データベース２０のオンラインバックアップを行うことで、得られるバックアップはすべてのアプリケーション１０ａ及び１０ｂにとって「整合性がとれている状態」となる。

このように、データベース２０が「整合性のとれている状態」でオンラインバックアップが実行されるようにするために、本実施形態では、オンラインバックアップの開始条件が満たされた時点では、各データベースＩ／Ｏ部３０を「抑制依頼中」状態とする。この状態では、データベースＩ／Ｏ部３０は、まだデータベース更新を開始していないセッションや、データベース更新を確定済みであるセッションについては、対応するアプリケーション１０ａ又は１０ｂからの新たな更新指示をデータベース２０に取り次がずに待機させる。一方、この状態に入った時点で既にデータベース２０の更新を開始しており、まだ確定していないセッションについては、対応するアプリケーション１０ａ又は１０ｂから更新確定指示を発するまでは、そのアプリケーション１０ａ又は１０ｂからの更新指示をデータベース２０に取り次ぐ。そして、データベースＩ／Ｏ部３０が「抑制依頼中」状態となった時点でデータベース更新を開始しており、かつその更新が未確定であるすべてのセッションについて、対応するアプリケーション１０ａ又は１０ｂから更新確定指示を受け取ると、データベースＩ／Ｏ部３０は「抑制完了」状態に遷移する。「抑制完了」状態にあるデータベースＩ／Ｏ部３０は、すべてのアプリケーション１０ａ及び１０ｂからの更新指示を待機させる。

以上、「抑制依頼」及び「抑制完了」というステータスを設けた意義について説明した。

ステータス管理部３２は、各データベースＩ／Ｏ部３０のステータスを記憶したＩ／Ｏステータス管理テーブルを有する。そして、オンラインバックアップのための制御の進行に応じて、このテーブルに保持される情報を更新していく。

図２に、Ｉ／Ｏステータス管理テーブルのデータ内容の一例を示す。図２に例示したテーブルには、データベースＩ／Ｏ部３０ごとに、そのデータベースＩ／Ｏ部３０に対応するアプリケーション１０ａ又は１０ｂの識別情報（「アプリケーションＩＤ」）と、そのデータベースＩ／Ｏ部３０のステータス値とが保持されている。

また、ステータス管理部３２は、アプリケーション１０ａ及び１０からのデータベース２０に対する読み書きのセッションのステータスを管理する。セッションのステータスには「通常」と「更新中」がある。

ステータス「更新中」は、当該セッションにおいてデータベース２０の更新が開始されてから、その更新が確定されるまでの間の状態である。すなわち、アプリケーションから当該セッションの中での最初のデータベース２０に対する更新指示が発せられ、その更新指示が実行可能である（すなわちまだ更新が抑制されていない）場合に、そのセッションは「通常」状態から「更新中」状態に遷移する。そして、「更新中」状態にあるセッションにおいて、対応するアプリケーションから更新確定が指示されると、そのセッションの状態は「通常」に戻る。

ステータス「通常」は、「更新中」以外の状態である。言い換えれば、セッションが「通常」状態にあるということは、そのセッションの中でまだデータベース２０の更新が始まっていないか、又はそのセッションの中でまとめて更新すべき複数のオブジェクトの更新が確定済みであるか、のいずれかであることを意味する。

「更新中」状態であるセッションを中断すると、データベース２０が整合性のとれていない状態となり、その状態でデータベース２０をオンラインバックアップすると、上述したように有益でないバックアップが生成される。そこで、本実施形態では、「更新中」状態であるセッションは、「通常」状態に遷移するのを待って中断（すなわち更新を「抑制」）し、オンラインバックアップを実行する。

ステータス管理部３２は、各アプリケーション１０ａ及び１０ｂが実行しているセッションのステータスを記憶したセッションステータス管理テーブルを有する。そして、オンラインバックアップのための制御の進行に応じて、このテーブルに保持される情報を更新していく。

図３に、セッションステータス管理テーブルのデータ内容の一例を示す。図３に例示したテーブルには、アプリケーションのＩＤと、そのアプリケーションが実行しているセッションのＩＤと、そのセッションのステータスと、の３つの項目の組が保持されている。図３の例では、アプリケーションＩＤ「０００１」に対応するアプリケーションは２つのセッション「Ｓ０００１」及び「Ｓ０００２」を実行中であり、アプリケーションＩＤ「０００２」に対応するアプリケーションは１つのセッション「Ｓ０００１」を実行中である。このうち、セッション「Ｓ０００１」は、２つのアプリケーション「０００１」と「０００２」が連携して行うセッションであり、それら２つのアプリケーションの両方がデータベースに対して更新を行う可能性がある。また、図３の例では、セッション「Ｓ０００１」は「通常」状態であり、セッション「Ｓ０００２」は「更新中」状態である。

図３の例は、すべてのアプリケーションが実行中のセッションのステータスを１つのセッションステータス管理テーブルに保持するものであったが、これは一例に過ぎない。セッションの管理はアプリケーションごとにできれば足りるので、アプリケーションごとのセッションステータス管理テーブルを用いてもよい。アプリケーションごとのセッションステータス管理テーブルには、当該アプリケーションが実行しているセッションのセッションＩＤと、そのセッションのステータスが保持される。またこの場合、アプリケーションごとのセッションステータス管理テーブルを、ステータス管理部３２ではなく、当該アプリケーションに対応するデータベースＩ／Ｏ部３０が保持していてもよい。

図１の説明に戻ると、オンラインバックアップ部２２は、データベース２０のオンラインバックアップを担当する機能モジュールである。オンラインバックアップ部２２は、従来のものと同様のものでよい。

オンラインバックアップトリガー部３４は、オンラインバックアップ部２２に対してオンラインバックアップの実行を指示するモジュールである。オンラインバックアップトリガー部３４は、ステータス管理部３２を参照することで、データベース２０がどのアプリケーション１０ａ及び１０ｂから見ても「整合性がとれている状態」となっており、かつ、どのアプリケーション１０ａ及び１０ｂからのデータベース更新も抑制されているときに、オンラインバックアップが実行されるようにする。

以上、図１を参照して、本実施形態のシステム構成の一例を説明した。図１のシステム構成は、１つのコンピュータ上、又は複数のコンピュータから構成されるコンピュータシステム上に、ソフトウエア的に構築される。すなわち、ある例では、図１に示したすべての要素が１台のコンピュータ上にソフトウエアとして実装される。別の例では、図１に示した要素が、複数のコンピュータ上に分散してインストールされ、それら要素がネットワークを介して通信を行いながら、各々の機能を発揮する。例えば、図１に示した要素のうち、アプリケーション１０ａ及び１０ｂ以外の要素が１台のコンピュータ上に構築され、アプリケーション１０ａ及び１０ｂがそれぞれ、そのコンピュータとは別の個別のコンピュータ上に構築されるようなシステム構成も可能である。

ここで、コンピュータは、例えば、ハードウエアとして、ＣＰＵ等のマイクロプロセッサ、ランダムアクセスメモリ（ＲＡＭ）およびリードオンリメモリ（ＲＯＭ）等のメモリ（一次記憶）、ＨＤＤ（ハードディスクドライブ）等の二次記憶装置を制御するコントローラ、各種Ｉ／Ｏ（入出力）インタフェース、ローカルエリアネットワークなどのネットワークとの接続のための制御を行うネットワークインタフェース等の要素群が、たとえばバスを介して相互に接続された回路構成を有する。また、そのバスに対し、例えばＩ／Ｏインタフェース経由で、ＣＤやＤＶＤなどの可搬型ディスク記録媒体に対する読み取り及び／又は書き込みのためのディスクドライブ、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体に対する読み取り及び／又は書き込みのためのメモリリーダライタ、などが接続されてもよい。上に例示した各機能モジュールの処理内容が記述されたプログラムがＣＤやＤＶＤ等の記録媒体を経由して、又はネットワーク等の通信手段経由で、ハードディスクドライブ等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがＲＡＭに読み出されＣＰＵ等のマイクロプロセッサにより実行されることにより、上に例示した機能モジュール群が実現される。

次に、図４を参照して、データベースＩ／Ｏ部３０の処理手順の一例を説明する。この手順は、対応するアプリケーション１０ａ又は１０ｂから、データベース２０に対する読み書きの指示が到来するごとに実行される。

この処理の前提として、アプリケーション１０ａ及び１０ｂがデータベースＩ／Ｏ部３０に送る指示には、当該アプリケーションのＩＤと、その指示が属するセッションのセッションＩＤとが含まれる。ここで、セッションＩＤは、アプリケーションが新規のセッションを開始するごとに、例えばそのアプリケーション自身が、そのセッションのために一意的な値として生成する。そして、同じセッションの中でデータベース２０内の複数のオブジェクトの更新処理を行う場合、アプリケーションは、それら個々のオブジェクトについて、アプリケーションＩＤ及びセッションＩＤを含んだ更新指示を発する。また、あるアプリケーションが、自分が始めたセッションの中で、別のアプリケーションに対してデータベース２０内のオブジェクトの依頼する場合には、前者のアプリケーションは、後者のアプリケーションに対してそのセッションのセッションＩＤを通知する。前者からの依頼に応じて後者のアプリケーションが発する更新指示は、後者のアプリケーションＩＤと共に、前者から通知されたセッションＩＤを含む。

図４の処理手順では、まず、データベースＩ／Ｏ部３０は、対応するアプリケーション１０ａ又は１０ｂから指示された処理の種別が、「参照」、「更新」、「更新確定」のいずれであるかを判定する（Ｓ１０）。指示された処理が「参照」である場合、データベースＩ／Ｏ部３０は、その指示（すなわち「参照指示」）を、データベース２０に転送することで、その指示に応じた処理（参照）が実行されるようにする（Ｓ１２）。Ｓ１２にて指示をデータベース２０に転送すると、データベースＩ／Ｏ部３０は、その指示についての処理を終了する。このように、本実施形態では、データベース２０に更新が発生しない参照指示については、後述のように更新指示を待機させている間も、待機させずに実行されるようにしている。

指示された処理が「更新」である場合、データベースＩ／Ｏ部３０は、ステータス管理部３２のＩ／Ｏステータス管理テーブルを参照して、自分自身のステータスを確認し（Ｓ１４）、確認したステータスの値が「通常」、「抑制依頼中」、「抑制完了」のいずれであるかを判定する（Ｓ１６）。

Ｓ１６で自分のステータスが「通常」であると判定した場合、データベースＩ／Ｏ部３０は、ステータス管理部３２に対して、その更新指示のセッションＩＤと、データベースＩＯ部３０自身の識別情報（「アプリケーションＩＤ」）と、更新指示を実行する旨と、を通知する（Ｓ１８）。この通知に応じ、ステータス管理部３２は、セッションステータス管理テーブル内の、そのセッションＩＤとアプリ−ケーションＩＤとの組合せに対応するステータスの値を「更新中」とする。すなわち、そのセッションＩＤとアプリ−ケーションＩＤとの組合せに対応するステータス値が「通常」である場合は、そのステータス値を「更新中」に書き換え、「更新中」ならばその値を維持する。また、そのセッションＩＤとアプリ−ケーションＩＤとの組合せがセッションステータス管理テーブルに未登録である場合は、そのテーブルに、その組合せに含まれるセッションＩＤ及びアプリケーションＩＤとを含んだエントリを追加し、そのエントリのステータスを「更新中」とする。

そして、データベースＩ／Ｏ部３０は、その更新指示をデータベース２０に転送することで、その指示に応じた処理（更新）が実行されるようにする（Ｓ１２）。

このように、データベースＩ／Ｏ部３０のステータスが「通常」である場合は、オンラインバックアップ又はその準備が行われていないということなので、アプリケーションからの指示に応じてデータベース２０の更新が行われる。

さて、Ｓ１６で自分自身のステータスが「抑制依頼中」であることがわかると、データベースＩ／Ｏ部３０は、ステータス管理部３２のセッションステータス管理テーブルにアクセスし、当該更新指示のセッションＩＤに対応するステータスの値を確認する（Ｓ２０）。そして、確認により得たステータスの値が「通常」及び「更新中」のいずれであるかを判定する（Ｓ２２）。ここで、Ｓ２０では、セッションステータス管理テーブル内に、そのセッションＩＤに対応するエントリが複数ある場合（例えば複数のアプリケーションが１セッション内で連携して、互いに関連するオブジェクト群を更新する場合）には、それら複数のエントリすべてのステータスを調べる。そして、Ｓ２２では、それら複数のエントリのステータスがすべて「通常」である場合、当該セッションのステータスは「通常」であると判定し、それら複数のエントリのステータスのなかに「更新中」のものが１以上あれば、当該セッションのステータスは「更新中」と判定する。

Ｓ２２で当該セッションのステータスが「更新中」であるとわかった場合、データベースＩ／Ｏ部３０は、その更新指示をデータベース２０に転送することで、その指示に応じた処理（更新）が実行されるようにする（Ｓ１２）。すなわち、この時点では、オンラインバックアップの準備が始まっており（これはデータベースＩ／Ｏ部３０自身のステータスが「抑制依頼中」であることからわかる）、かつ、その準備開始の時点で既に開始されているオブジェクト群の更新が確定していない（これは当該セッションのステータスが「更新中」であることからわかる）ので、データベース２０の状態が当該セッションの発行元のアプリケーションからみて「整合性がとれている状態」となるまで（すなわち対応するアプリケーションから当該セッションについての更新確定指示が来るまで）は、更新指示を受け入れるのである。

Ｓ２２で当該セッションのステータスが「通常」であるとわかった場合、データベースＩ／Ｏ部３０は、その更新指示を待機させる（Ｓ２４）。例えば、その更新指示をデータベースＩ／Ｏ部３０自身の内部に保留する。

すなわち、Ｓ２２で当該セッションのステータスが「通常」であるとわかった時点では、オンラインバックアップの準備が始まっており、かつ、当該セッションの更新対象のオブジェクトの更新処理がまだ１つも始まっていないか又はそれら更新対象のすべてのオブジェクトの更新が「確定」されている。複数のアプリケーションが、まとめて更新すべき互いに関連する複数のオブジェクトを１セッション内でそれぞれ更新する状況でも、Ｓ２２の判定結果が「通常」であれば、それら複数のオブジェクトの更新はすべて確定されている。したがって、この時点では、データベース２０は、そのセッションの発行元のそれら複数のアプリケーションすべてから見て「整合性がとれている状態」であり、この状態でオンラインバックアップを行っても問題はない。そこで、この場合は、更新処理の指示を待機させる（Ｓ２４）のである。

また、データベースＩ／Ｏ部３０は、Ｓ２４で更新指示を待機させた場合、その更新指示を送ってきたアプリケーションに対して、その更新指示を待機させた旨を示す情報を送ってもよい。また、その情報を待機させた時点で送る代わりに、あるいはそれに加えて、アプリケーションからその更新指示の状況の問い合わせが到来したときに、その情報をアプリケーションに回答してもよい。アプリケーションは、その情報により、更新指示が待機中であることを知ることができ、更新指示に応じたデータベース更新処理が遅れているのが、エラーなどの不具合ではなく、（オンラインバックアップのための）正常な待機のためであることがわかる。アプリケーションは、データベースＩ／Ｏ部３０から提供された待機の旨の情報に応じて、現在データベース２０のオンラインバックアップ中であるためデータベースの更新が遅れることなどを知らせるメッセージを表示してもよい。

Ｓ１６の判定に戻ると、データベースＩ／Ｏ部３０は、この判定で自分自身のステータスが「抑制完了」であることがわかると、更新指示を待機させる（Ｓ２４）。「抑制完了」状態では、「抑制依頼中」状態の開始時点でデータベースＩ／Ｏ部３０が既に始めていたデータベース更新はすべて確定され、アプリケーションにとって「整合性がとれている状態」となっているので、更新指示に対応するセッションのステータスを確認するまでもなく、その更新指示を待機させるのである。

このようにして、すべてのデータベースＩ／Ｏ部３０が「抑制完了」状態である間（この間は、すべてのアプリケーションから発せられるすべての更新指示が待機させられる）に、オンラインバックアップが実行される（詳しくは，図６の手順を参照）。

そして、Ｓ２４の後、データベースＩ／Ｏ部３０は、例えば定期的に、ステータス管理部３２内の自分自身のステータスを確認し（Ｓ２６）、そのステータスが「通常」に戻っているかどうかを判定する（Ｓ２８）。Ｓ１６の時点で「抑制依頼中」又は「抑制完了」状態であったデータベースＩ／Ｏ部３０が「通常」状態に戻るのは、オンラインバックアップが完了した場合である（後述する図５の手順を参照）。したがって、Ｓ２８の判定結果がＹＥＳであれば、オンラインバックアップは既に完了しているので、データベースＩ／Ｏ部３０は、それまでに待機させていた更新指示を順にデータベース２０に転送し、各指示に応じてオブジェクトの更新処理を行わせる（Ｓ１２）。一方、Ｓ２８の判定結果がＮＯであれば、オンラインバックアップはまだ完了していないと言うことなので、Ｓ２４に戻り、更新指示の待機を続行する。

さて、Ｓ１０の判定に戻ると、ここで判定した指示の種別が「更新確定」であれば、データベースＩ／Ｏ部３０は、その更新確定指示をデータベース２０に転送する（Ｓ３０）。これにより、データベース２０は、その更新確定指示の対象である各オブジェクトの更新を確定する。これにより、それら各オブジェクトの値は、アプリケーションにとって「整合性のとれている状態」で確定される。逆に言えば、更新指示に応じてデータ内容の更新が行われたとしても、まだ更新確定指示が来ていないオブジェクトのデータ内容は、アプリケーションにとって「整合性がとれていない状態」である可能性がある。

このようにして各オブジェクトの更新処理を確定した後、データベースＩ／Ｏ部３０は、ステータス管理部３２内のセッションステータス管理テーブルにアクセスし、当該更新確定処理のセッションＩＤと当該データベースＩ／Ｏ部３０のアプリケーションＩＤとの組に対応するステータスの値を「通常」にする（Ｓ３２）。すなわち、更新確定指示が到来すると言うことは、必ずその前に更新指示が到来しており、その更新指示に応じ、当該指示に係るセッションのステータスが「更新中」にセットされている（Ｓ１８）はずなので、これを「通常」に戻す。このように、Ｓ３２の時点では、更新確定により、更新確定指示を発したアプリケーションが当該セッションでそれまでに更新していたオブジェクトはすべて確定され、「整合性のとれている状態」となっているので、当該アプリケーションについての当該セッションの状態を「通常」に戻すことで、それ以降にそのアプリケーションから新たな更新指示が来てもそれを待機させるようにするのである（Ｓ２２及びＳ２４参照）。

その後、データベースＩ／Ｏ部３０は、ステータス管理部３２を参照して自分自身のステータスを確認し（Ｓ３４）、確認したステータスが「抑制依頼中」であるか否かを判定する（Ｓ３６）。この判定の結果がＹＥＳの場合、更に、ステータス管理部３２を参照して、当該データベースＩ／Ｏ部３０に対応するアプリケーションが実行しているすべてのセッション（すなわちそのアプリケーションのＩＤに対応する各セッション）が「通常」状態であるかどうかを判定する（Ｓ３８）。Ｓ３８の判定結果がＹＥＳの場合、当該データベースＩ／Ｏ部３０が実行していたすべてのセッションにおけるデータベース更新がすべて確定され、「整合性がとれている状態」となっている。したがって、この場合データベースＩ／Ｏ部３０は、ステータス管理部３２が保持している当該データベースＩ／Ｏ部３０の状態（すなわち当該Ｉ／Ｏ部３０に対応するアプリケーションのステータス）を「抑制依頼中」から「抑制完了」に変更する（Ｓ４０）。これ以降、データベースＩ／Ｏ部３０のステータスが「通常」に戻るまでの間は、データベースＩ／Ｏ部３０はすべてのアプリケーションからのすべての更新指示を待機させる（Ｓ１６及びＳ２４参照）ことで、データベース２０のオンラインバックアップが実行できる状況を整える。Ｓ４０でデータベースＩ／Ｏ部３０のステータスを変更した後、データベースＩ／Ｏ部３０は、その更新確定指示についての処理を終了する。

また、Ｓ３６又はＳ３８の判定結果がＮＯである場合には、ステータス管理部３２のテーブルに保持されたデータベースＩ／Ｏ部３０自身のステータスを変更せずに、当該更新確定指示についての処理を終了する。

次に、図５を参照して、オンラインバックアップトリガー部３４の処理手順の例を説明する。

図５の手順は、オンラインバックアップの開始条件が満たされた場合、例えばユーザから開始指示があった場合や、あらかじめ定めた規則により定まる開始タイミングが到来したときに、開始される。オンラインバックアップのタイミングを決める規則は、従来のものと同様でよい。一例を挙げるならば、定期的なオンラインバックアップのタイミングを規定する規則がある。

この処理では、オンラインバックアップトリガー部３４は、まず、ステータス管理部３２のＩ／Ｏステータス管理テーブルを参照して、すべてのデータベースＩ／Ｏ部３０のステータスを確認する（Ｓ５０）。そして、それらデータベースＩ／Ｏ部３０のステータスがすべて「通常」、それらステータスのうちの少なくとも１つが「抑制依頼中」、又は、それらステータスのすべてが「抑制完了中」、のいずれであるかを判定する（Ｓ５２）。

この判定の結果が、データベースＩ／Ｏ部３０のステータスがすべて「抑制完了」であるか、又は少なくとも１つが「抑制依頼中」である場合には、オンラインバックアップトリガー部３４は、今回のオンラインバックアップを取りやめるなどのエラー処理を行う（Ｓ５４）。このような場合が生じるのは、例えば、前回のオンラインバックアップが完了していない時点で、今回のオンラインバックアップのタイミングが到来するなどの異常な場合なので、エラー処理を行うのである。

一方、Ｓ５２の判定の結果、データベースＩ／Ｏ部３０のステータスがすべて「通常」であることがわかると、オンラインバックアップトリガー部３４は、ステータス管理部３２のＩ／Ｏステータス管理テーブル内の、すべてのデータベースＩ／Ｏ部３０のステータスを「抑制依頼中」に変更する（Ｓ５６）。データベースＩ／Ｏ部３０は、更新指示をデータベース２０に取り次ぐか待機させるかを判定する際、Ｉ／Ｏステータス管理テーブル内の自分自身のステータスを確認するので、Ｓ５６でのステータス変更は、データベースＩ／Ｏ部３０に対して「抑制依頼」を行うことと実質的に等価である。

Ｓ５６の後、オンラインバックアップトリガー部３４は、今回行おうとしているオンラインバックアップ処理を待機させる（Ｓ５８）。そして、Ｉ／Ｏステータス管理テーブルを例えば定期的に監視して、すべてのデータベースＩ／Ｏ部３０のステータスを確認し（Ｓ６０）、それらステータスがすべて「抑制完了」となっているかどうかを判定する（Ｓ６２）。「抑制依頼中」のままのデータベースＩ／Ｏ部３０が１つでもあれば、Ｓ６２の判定結果はＮＯとなる。この場合、オンラインバックアップトリガー部３４は、オンラインバックアップの実行の待機を続ける（Ｓ５８）。この待機は、Ｓ６２で、すべてのデータベースＩ／Ｏ部３０のステータスが「抑制完了」となったと判定されるまで続く。

Ｓ６２ですべてのデータベースＩ／Ｏ部３０のステータスが「抑制完了」となったと判定されると、オンラインバックアップトリガー部３４は、オンラインバックアップ部２２に対してオンラインバックアップの実行を指示する（Ｓ６４）。すなわち、この状態では、すべてのアプリケーションからの更新指示が待機させられていると共に、データベース２０はすべてのアプリケーションにとって「整合性がとれている状態」なので、オンラインバックアップを実行するのである。オンラインバックアップ部２２は、この指示に応じて、データベース２０のオンラインバックアップを実行する。

データベース２０のオンラインバックアップが完了すると、オンラインバックアップ部２２は、オンラインバックアップトリガー部３４に対して、オンラインバックアップが完了した旨を通知する。この通知を受けたオンラインバックアップトリガー部３４は、ステータス管理部３２内のＩ／Ｏステータス管理テーブルにおけるすべてのデータベースＩ／Ｏ部３０のステータスを、「抑制完了」から「通常」に変更する（Ｓ６６）。これにより、各データベースＩ／Ｏ部３０は、いままで待機させていた更新指示をデータベース２０に転送する（図４のＳ２８からＳ１２に続く流れを参照）。

以上に説明したデータベースＩ／Ｏ部３０の処理（図４参照）とオンラインバックアップトリガー部３４の処理（図５参照）との連携により、データベース２０がすべてのアプリケーションにとって整合性がとれている状態で、オンラインバックアップが実行される。

次に、図６を参照して、具体的な処理の流れの中での、ステータス管理部３２内のＩ／Ｏステータス管理テーブルの変遷の例を説明する。

まず、データベース２０が起動したが、まだどのアプリケーション１０ａ、１０ｂからもアクセスがない場合は、Ｉ／Ｏステータス管理テーブルは空である（図６の（１））。

この後、あるアプリケーション（ＩＤが「０００１」であるとする）が、データベース２０へアクセスするための初期化処理を実行すると、このアプリケーションに対応するデータベースＩ／Ｏ部３０が起動され、そのデータベースＩ／Ｏ部３０がＩ／Ｏステータス管理テーブルに対して、そのアプリケーションＩＤ「０００１」に対応するエントリを追加し、そのエントリのステータス値を「通常」に設定する（図６の（２））。

その後、別のアプリケーション（ＩＤ「０００２」）が、データベース２０へアクセスするための初期化を実行すると、このアプリケーションに対応するデータベースＩ／Ｏ部３０がＩ／Ｏステータス管理テーブルに対して、そのアプリケーションＩＤ「０００２」に対応するエントリを追加し、そのエントリのステータス値を「通常」に設定する（図６の（３））。

次に、データベース２０を管理するユーザが、本システムに対して、オンラインバックアップの実行を指示すると、その指示を受けたオンラインバックアップトリガー部３４が、その時点でＩ／Ｏステータス管理テーブルに登録されているすべてのエントリ（上述した２つのアプリケーションに対応）のステータス値を「抑制依頼中」に変更する（図６の（４））。

それら２つのアプリケーションに対応する各データベースＩ／Ｏ部３０は、そのステータス変更を検知し、既に開始しているまとめて更新すべき一連のオブジェクトの更新は続行するが、それ以外の新たな更新処理は待機させる。そして、例えばアプリケーション「０００１」が実行中の更新処理がすべて確定した場合には、そのアプリケーションに対応するデータベースＩ／Ｏ部３０は、Ｉ／Ｏステータス管理テーブル内のそのアプリケーション「０００１」のエントリのステータスを「抑制完了」に変更する（図６の（５））。

その後アプリケーション「０００２」が実行中の更新処理がすべて確定すると、対応するデータベースＩ／Ｏ部３０が、Ｉ／Ｏステータス管理テーブル内のＩＤ「０００２」のエントリのステータスを「抑制完了」に変更する（図６の（６））。

このようにしてＩ／Ｏステータス管理テーブル内のすべてのエントリのステータスが「抑制完了」になると、オンラインバックアップトリガー部３４は、オンラインバックアップ部２２に対してデータベース２０のオンラインバックアップを開始させる。

そして、そのオンラインバックアップが成功裏に完了すると、オンラインバックアップトリガー部３４は、Ｉ／Ｏステータス管理テーブル内のすべてのエントリのステータスを「通常」に戻す（図６の（７））。これにより、データベース２０に対する更新が再開され、各データベースＩ／Ｏ部３０は、「抑制依頼中」及び「抑制完了」状態の時に待機させた更新指示をデータベース２０に伝達し、更新を実行させる。

以上、本発明の実施形態を説明した。以上に説明したように、本実施形態では、データベース２０が複数のアプリケーションのすべてからみて整合性のとれている状態となるように制御し、そのような状態になるとオンラインバックアップを実行する。したがって、オンラインバックアップにより生成されるバックアップデータは、複数のアプリケーションのすべてからみて整合性のとれているものとなっており、いずれのアプリケーションからも利用しやすいものとなっている。

また、上記実施形態では、データベース２０内のまとめて更新すべき互いに関連するオブジェクト群を、複数のアプリケーションが連携して更新する場合でも、データベース２０がそれら複数のアプリケーションすべてにとって「整合性のとれている状態」となっているときにオンラインバックアップが行われる。

以上に説明した実施形態はあくまで一例に過ぎず、本発明の技術的思想の範囲内で様々な変形が考えられる。

例えば、図１の例では、アプリケーション１０ａ、１０ｂの各々に対応してそれぞれ個別にデータベースＩ／Ｏ部３０を設けたが、この代わりにデータベースＩ／Ｏ部３０を１つだけ設けることとし、複数のアプリケーションがその唯一のデータベースＩ／Ｏ部３０を介してデータベース２０とやりとりを行うようにしてもよい。ただし、この場合その唯一のデータベースＩ／Ｏ部３０は、受け取った更新指示等の指示がどのアプリケーションからのものかを認識する必要がある。データベースＩ／Ｏ部３０は、その認識の結果に従い、その指示に対するデータベース２０からの応答を、その指示の発信元のアプリケーションに返す。また、この場合、ステータス管理部３２内のＩ／Ｏステータス管理テーブルは、データベースＩ／Ｏ部３０のステータスの代わりに、各アプリケーションのステータスを管理する。ただし、上記実施形態のＩ／Ｏステータス管理テーブルは、もともと、各アプリケーションに対して一対一に対応するデータベースＩ／Ｏ部３０のステータスを、それら各アプリケーションのＩＤに対応づけて管理していたので、そのテーブルのデータ構造は上記実施形態のものと同様（図２参照）でよい。また、データベースＩ／Ｏ部３０を１つだけ設ける構成の場合、そのデータベースＩ／Ｏ部３０は、アプリケーションから更新確定指示を受け取ると、その更新確定指示を発したアプリケーションのＩＤを特定し、そのＩ／Ｏステータス管理テーブル内のそのアプリケーションＩＤに対応するエントリのステータスを「抑制完了」に書き換えればよい。

また、図１の例では、データベースＩ／Ｏ部３０、ステータス管理部３２、及びオンラインバックアップトリガー部３４をそれぞれ別々の機能モジュールとして実現しているが、この代わりに、それら３種のモジュールの機能を１つの機能モジュールとして実装してもよいし、それら３種のうちの２種のモジュールの機能を１つのモジュールにまとめて実装してもよい。例えば、ステータス管理部３２とオンラインバックアップトリガー部３４とを１つの機能モジュールにまとめて実装してもよい。

また、上記実施形態では、Ｓ２４（図４）にて更新指示の実行を待機させたが、この代わりに、更新指示の発行元のアプリケーションに対し、現時点ではオンラインバックアップのために更新ができない旨を通知した上で、その更新指示を破棄するようにしてもよい。この場合、アプリケーションは、データベースＩ／Ｏ部３０等からオンラインバックアップの完了通知を受けた後、破棄された更新指示を再度発行すればよい。なお、Ｓ２４にて更新指示の実行を待機させる上記実施形態の方式の方が、アプリケーションの処理負担が少なく、また既存のアプリケーションを本実施形態のシステムに対応させるための改変も少なくて済む。

１０ａ，１０ｂ アプリケーション、２０ データベース、２２ オンラインバックアップ部、３０ データベースＩ／Ｏ部、３２ ステータス管理部、３４ オンラインバックアップトリガー部。

Claims (3)

1. 複数のアプリケーションの各々の状態を記憶する状態記憶手段と、
   前記複数のアプリケーションのうちの少なくとも１つからデータベースの更新指示を受け取り、受け取った前記更新指示に応じて前記データベースを更新するか否かを制御する少なくとも１つの更新制御手段と、
   前記データベースのオンラインバックアップの開始条件が満たされた場合、前記状態記憶手段に記憶された前記複数のアプリケーションの状態をすべてあらかじめ定められた第１の状態とすると共に、前記状態記憶手段に記憶された前記複数のアプリケーションの状態がすべてあらかじめ定められた第２の状態となったことを検知すると、前記データベースのオンラインバックアップを開始するための制御を行うオンラインバックアップ制御手段と、
   を有し、
   前記更新制御手段は、受け取った前記更新指示を発したアプリケーションの状態が前記第１の状態である場合、当該更新指示に対応するセッションにおける当該アプリケーションからの他の更新指示に応じて前記データベースの更新を既に行っており且つ当該セッションについての更新確定指示を当該アプリケーションからまだ受け取っていなければ、前記更新指示に応じて前記データベースを更新し、受け取った前記更新指示に対応するセッションについての更新確定指示を当該アプリケーションから既に受け取っているか又は当該更新指示の前に当該セッションにおける他の更新指示に応じて前記データベースの更新を一度も行っていなければ、当該更新指示に応じた前記データベースの更新を少なくとも前記オンラインバックアップが完了するまでは取りやめると共に、前記第１の状態にある前記アプリケーションが実行しているすべてのセッションについて前記更新指示に応じた前記データベースの更新を取りやめた状態となると、前記状態記憶手段に記憶された当該アプリケーションの状態を前記第２の状態に変更する、
   ことを特徴とするオンラインバックアップ制御システム。
2. 前記更新制御手段は、受け取った前記更新指示に対応するセッションについての更新確定指示を当該アプリケーションから既に受け取っているか又は当該更新指示の前に当該セッションにおける他の更新指示に応じて前記データベースの更新を一度も行っていなければ、当該更新指示を待機させると共に、前記オンラインバックアップが完了すると、待機させていた前記更新指示に応じて前記データベースの更新が行われるようにする、ことを特徴とする請求項１に記載のオンラインバックアップ制御システム。
3. コンピュータを、
   複数のアプリケーションの各々の状態を記憶する状態記憶手段、
   前記複数のアプリケーションのうちの少なくとも１つからデータベースの更新指示を受け取り、受け取った前記更新指示に応じて前記データベースを更新するか否かを制御する少なくとも１つの更新制御手段、
   前記データベースのオンラインバックアップの開始条件が満たされた場合、前記状態記憶手段に記憶された前記複数のアプリケーションの状態をすべてあらかじめ定められた第１の状態とすると共に、前記状態記憶手段に記憶された前記複数のアプリケーションの状態がすべてあらかじめ定められた第２の状態となったことを検知すると、前記データベースのオンラインバックアップを開始するための制御を行うオンラインバックアップ制御手段、
   として機能させるためのプログラムであって、
   前記更新制御手段は、受け取った前記更新指示を発したアプリケーションの状態が前記第１の状態である場合、当該更新指示に対応するセッションにおける当該アプリケーションからの他の更新指示に応じて前記データベースの更新を既に行っており且つ当該セッションについての更新確定指示を当該アプリケーションからまだ受け取っていなければ、前記更新指示に応じて前記データベースを更新し、受け取った前記更新指示に対応するセッションについての更新確定指示を当該アプリケーションから既に受け取っているか又は当該更新指示の前に当該セッションにおける他の更新指示に応じて前記データベースの更新を一度も行っていなければ、当該更新指示に応じた前記データベースの更新を少なくとも前記オンラインバックアップが完了するまでは取りやめると共に、前記第１の状態にある前記アプリケーションが実行しているすべてのセッションについて前記更新指示に応じた前記データベースの更新を取りやめた状態となると、前記状態記憶手段に記憶された当該アプリケーションの状態を前記第２の状態に変更する、
   ことを特徴とするプログラム。
   

Images