(57)【要約】【課題】システム全体としての運用効率を向上させる。【解決手段】対話型処理手段２は、入力された処理要求２ａ，２ｂ，２ｃ，・・・に応答して、データベース１の操作を伴う対話型処理を実行する。バッチ処理手段３は、データベース１の操作を伴う一連の処理要求がまとめられたバッチ処理要求３ａに応答して、バッチ処理要求３ａに従った一連のバッチ処理を実行する。ログ記憶手段４は、データベース１に関連する処理の履歴情報を時系列で保持する。ログ取得手段５は、バッチ処理の実行中を除き、対話型処理手段２がデータベース１の操作を行う毎に操作内容を示す操作履歴４ａ，４ｂをログ記憶手段４に格納し、バッチ処理手段３によりバッチ処理が実行されると、バッチ処理の実行を示すチェックポイントログ４ｃをログ記憶手段４に格納する。【選択図】　　　　図１
2004078505.tif 000002
【特許請求の範囲】
【請求項１】
データベースに対する操作履歴を管理するデータベース操作履歴管理装置において、
入力された処理要求に応答して、前記データベースの操作を伴う対話型処理を実行する対話型処理手段と、
前記データベースの操作を伴う一連の処理要求がまとめられたバッチ処理要求に応答して、前記バッチ処理要求に従った一連のバッチ処理を実行するバッチ処理手段と、
前記データベースに関連する処理の履歴情報を時系列で保持するログ記憶手段と、
前記バッチ処理の実行中を除き、前記対話型処理手段が前記データベースの操作を行う毎に操作内容を示す操作履歴を前記ログ記憶手段に格納し、前記バッチ処理手段により前記バッチ処理が実行されると、前記バッチ処理の実行を示すチェックポイントログを前記ログ記憶手段に格納するログ取得手段と、
を有することを特徴とするデータベース操作履歴管理装置。
【請求項２】
前記ログ取得手段は、前記バッチ処理手段により前記データベースが操作されたときにのみ前記チェックポイントログを前記ログ記憶手段に格納することを特徴とする請求項１記載のデータベース操作履歴管理装置。
【請求項３】
前記ログ記憶手段に格納されている前記操作履歴に基づいて、前記データベースに対して実行された操作を、時系列に沿って、前記チェックポイントログに達するまで順次再実行する履歴再現手段をさらに有することを特徴とする請求項１記載のデータベース操作履歴管理装置。
【請求項４】
データベースに対する操作履歴を管理するデータベース操作履歴管理方法において、
入力された処理要求に応答して、前記データベースの操作を伴う対話型処理を実行し、
前記データベースの操作を行う毎に操作内容を示す操作履歴を、前記データベースに関連する処理の履歴情報を時系列で保持するログ記憶手段に格納し、
前記データベースの操作を伴う対話型処理の実行を停止し、
前記データベースの操作を伴う一連の処理要求がまとめられたバッチ処理要求に応答して、前記バッチ処理要求に従った一連のバッチ処理を実行し、
前記バッチ処理の実行を示すチェックポイントログを前記ログ記憶手段に格納する、
ことを特徴とするデータベース操作履歴管理方法。
【請求項５】
データベースに対する操作履歴を管理するデータベース操作履歴管理プログラムにおいて、
コンピュータに、
入力された処理要求に応答して、前記データベースの操作を伴う対話型処理を実行し、
前記データベースの操作を行う毎に操作内容を示す操作履歴を、前記データベースに関連する処理の履歴情報を時系列で保持するログ記憶手段に格納し、
前記データベースの操作を伴う対話型処理の実行を停止し、
前記データベースの操作を伴う一連の処理要求がまとめられたバッチ処理要求に応答して、前記バッチ処理要求に従った一連のバッチ処理を実行し、
前記バッチ処理の実行を示すチェックポイントログを前記ログ記憶手段に格納する、
処理を実行させることを特徴とするデータベース操作履歴管理プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はデータベースに対する操作履歴を管理するためのデータベース操作履歴管理装置、データベース操作履歴管理方法、およびデータベース操作履歴管理プログラムに関し、特にバッチ処理によるデータベースの操作を伴うシステムで利用されるデータベース操作履歴管理装置、データベース操作履歴管理方法、およびデータベース操作履歴管理プログラムに関する。
【０００２】
【従来の技術】
業務に使用されるコンピュータシステムでは、日々発生する業務に応じたデータをデータベースに格納する。このようにして逐次更新されるデータベースの内容は、システム障害が発生した場合でも最新の状態に正しく復旧する必要がある。
【０００３】
データベースを利用した業務形態は、「オンライン業務」と「バッチ業務」の２つにカテゴライズされており、データベースの復旧手法は、業務形態によって異なる。
【０００４】
・オンライン業務
オンライン業務は、操作入力等に応答してデータの参照、更新が頻繁に行われる。そのため、処理レスポンスが重要となる。オンライン業務中に異常が発生した場合には、過去に取得した退避データをリストアした後に、データベースに対する操作履歴（以下、アーカイブログと呼ぶ）を適用してデータの復旧を実施する。
【０００５】
ここで、アーカイブログとは、データを更新した履歴である。ユーザからの操作入力等に応じた対話型の処理要求に応じたデータの挿入、更新などが実行されたときに、更新されたデータに対応したアーカイブログがログファイルに出力される。データベースにディスク障害などの異常が発生すると、ログファイルに記録されたアーカイブログを辿ることで、データベースが復旧できる。オンライン業務では、ユーザからの操作入力に応じたデータの挿入や更新が行われるため、アーカイブログを取得しておかないと過去に実行された操作を再現できず、データベースの復旧が困難となる。
【０００６】
・バッチ業務
オンライン業務とは異なり、バッチ業務は、予め用意されたデータ更新要求に応じて、大量のデータの挿入が高い頻度で実行される。大規模なバッチ業務の実行前には、障害等の発生に備え、データベース内のデータの退避が行われる。そして、バッチ業務中にシステムの異常が発生した場合には、まず予め取得した退避データをリストアすることで、バッチ業務の開始前の状態にデータベースを復旧する。その後、バッチ業務を最初から再実行する。
【０００７】
以上のように、オンライン業務とバッチ業務とでは、障害発生時の復旧方法が異なる。
ところで、多くのデータベースシステムでは、日中はオンライン業務、夜間はバッチ業務というように、時間帯を分けて双方の業務が行われる。このような場合は、一般的には、バッチ業務中を含む業務全体におけるアーカイブログが取得される。
【０００８】
すなわち、過去にバックアップが行われた時点からのデータベースに対して実施された操作内容が継続的にアーカイブログとして取得されていることが、アーカイブログを用いて正しくデータベースを復旧するための前提条件である。途中にアーカイブログが取得されていない期間が存在すると、その期間中のデータベースの変更が再現できないため、正しい復旧作業はできない。
【０００９】
そのため、オンライン処理とバッチ処理とを行うシステムでは、バッチ業務中も継続してアーカイブログを取得する。これにより、アーカイブログの連続性が保たれ、アーカイブログを用いてデータベースを正しく復旧することが可能となる。
【００１０】
ただし、バッチ業務では大量のデータの挿入処理が実施される。そのため、バッチ処理中にアーカイブログを取得した場合、大量のアーカイブログが出力される結果となり、アーカイブログを出力するためには大容量のストレージデバイスが必要となる。さらに、ストレージデバイスに対しての入出力処理（たとえば、データの書き込み処理）が頻繁に動作するため、バッチ業務自体の処理速度が低下する。
【００１１】
そこで、バッチ業務実施時に、アーカイブログ運用を一時的に停止する方法が考えられている。
図１３は、従来のアーカイブログ運用を一時的に停止する場合のシステム運用例を示す図である。たとえば、オンライン業務から一日の業務が開始される。オンライン業務が行われている間は、アーカイブログ運用が行われている。すなわち、アーカイブログが取得されている。日中のオンライン業務が終了すると、全データベース（ＤＢ）のバックアップが行われ、全データベースの退避データが取得される（ステップＳ９２）。バックアップ終了後、アーカイブログ運用の停止処理が行われる（ステップＳ９３）。これ以降、データベースに対してデータの挿入等の操作が行われても、アーカイブログは取得されない。
【００１２】
その後、バッチ業務（ステップＳ９４）が行われる。バッチ業務終了後、アーカイブログ運用が開始される（ステップＳ９５）。そして、再度、全データベースのバックアップが行われ、全データベースの退避データが取得される（ステップＳ９６）。バックアップが終了すると、次の営業日のオンライン業務（ステップＳ９１）が開始される。
【００１３】
このように、バッチ業務（ステップＳ９４）の間、アーカイブログ運用を止めることにより、アーカイブログの運用区間が連続しなくなる。そこで、アーカイブログ運用停止時、およびアーカイブログ運用開始時に、全データベースのバックアップ処理（ステップＳ９２，Ｓ９６）が行われる。これにより、アーカイブログ運用再開後に障害が発生した場合、再開前に取得した退避データをリストアし、それ以降のアーカイブログに基づいてデータベースへの操作を再現することで、データベースを最新の状態まで復旧することができる。
【００１４】
【発明が解決しようとする課題】
しかし、従来のアーカイブログ運用を一時的に停止する方法には、以下の問題がある。
【００１５】
アーカイブログの運用期間が連続していないため、アーカイブログ運用開始時には全データベースの退避データが必要となる。一日一回のバッチ業務が発生するものとすれば、毎日２回ずつ全データベースのバックアップを行うことになる。しかも、対象のデータベースが複数の資源で構成される場合でも、各資源に対する操作の有無が不明であるため、バッチ業務中に操作されていない（参照のみ実行、もしくは何も実行しない）データベースに関しても、退避データを取得する必要がある。この結果、退避データの格納のために、大量の記憶領域が必要となる。
【００１６】
しかも、退避データを取得する処理時間が増加することにより、システム全体の運用効率が悪化する。
本発明はこのような点に鑑みてなされたものであり、システム全体としての運用効率を向上させたデータベース操作履歴管理装置、データベース操作履歴管理方法、およびデータベース操作履歴管理プログラムを提供することを目的とする。
【００１７】
【課題を解決するための手段】
本発明の第１の態様では上記課題を解決するために、図１に示すようなデータベース操作履歴管理装置が提供される。本発明に係るデータベース操作履歴管理装置は、データベース１に対する操作履歴を管理するものであり、以下の機能を有する。
【００１８】
対話型処理手段２は、入力された処理要求２ａ，２ｂ，２ｃ，・・・に応答して、データベース１の操作を伴う対話型処理を実行する。バッチ処理手段３は、データベース１の操作を伴う一連の処理要求がまとめられたバッチ処理要求３ａに応答して、バッチ処理要求３ａに従った一連のバッチ処理を実行する。ログ記憶手段４は、データベース１に関連する処理の履歴情報を時系列で保持する。ログ取得手段５は、バッチ処理の実行中を除き、対話型処理手段２がデータベース１の操作を行う毎に操作内容を示す操作履歴４ａ，４ｂをログ記憶手段４に格納し、バッチ処理手段３によりバッチ処理が実行されると、バッチ処理の実行を示すチェックポイントログ４ｃをログ記憶手段４に格納する。
【００１９】
このようなデータベース操作履歴管理装置によれば、処理要求２ａ，２ｂ，２ｃ，・・・が入力されると対話型処理手段２により、データベース１の操作を伴う処理が実行される。すると、ログ取得手段５により、データベース１の操作が行われる毎に操作内容を示す操作履歴４ａ，４ｂがログ記憶手段４に格納される。また、バッチ処理要求３ａが入力されると、バッチ処理手段３によりバッチ処理要求３ａに従った一連のバッチ処理が実行される。ログ取得手段５によるバッチ処理の実行中は操作履歴の格納は行われず、バッチ処理の実行を示すチェックポイントログ４ｃがログ記憶手段４に格納される。
【００２０】
本発明の第２の態様では、データベースに対する操作履歴を管理するデータベース操作履歴管理方法において、入力された処理要求に応答して、前記データベースの操作を伴う対話型処理を実行し、前記データベースの操作を行う毎に操作内容を示す操作履歴を、前記データベースに関連する処理の履歴情報を時系列で保持するログ記憶手段に格納し、前記データベースの操作を伴う対話型処理の実行を停止し、前記データベースの操作を伴う一連の処理要求がまとめられたバッチ処理要求に応答して、前記バッチ処理要求に従った一連のバッチ処理を実行し、前記バッチ処理の実行を示すチェックポイントログを前記ログ記憶手段に格納する、ことを特徴とするデータベース操作履歴管理方法が提供される。
【００２１】
このようなデータベース操作履歴管理方法によれば、入力された処理要求に応答して対話型処理が実行され、データベースの操作を行う毎に操作内容を示す操作履歴がログ記憶手段に格納される。次に、対話型処理の実行が停止され、バッチ処理要求に応答して、バッチ処理要求に従った一連のバッチ処理が実行される。そして、バッチ処理の実行を示すチェックポイントログがログ記憶手段に格納される。
【００２２】
本発明の第３の態様では、データベースに対する操作履歴を管理するデータベース操作履歴管理プログラムにおいて、コンピュータに、入力された処理要求に応答して、前記データベースの操作を伴う対話型処理を実行し、前記データベースの操作を行う毎に操作内容を示す操作履歴を、前記データベースに関連する処理の履歴情報を時系列で保持するログ記憶手段に格納し、前記データベースの操作を伴う対話型処理の実行を停止し、前記データベースの操作を伴う一連の処理要求がまとめられたバッチ処理要求に応答して、前記バッチ処理要求に従った一連のバッチ処理を実行し、前記バッチ処理の実行を示すチェックポイントログを前記ログ記憶手段に格納する、処理を実行させることを特徴とするデータベース操作履歴管理プログラムが提供される。
【００２３】
このようなデータベース操作履歴管理プログラムをコンピュータで実行すれば、そのコンピュータにより、上記本発明の第２の態様で示したデータベース操作履歴管理方法と同様の処理が行われる。
【００２４】
【発明の実施の形態】
以下、本発明の実施の形態を図面を参照して説明する。
まず、実施の形態に適用される発明の概要について説明し、その後、実施の形態の具体的な内容を説明する。
【００２５】
図１は、実施の形態に適用される発明の概念図である。図１に示すデータベース操作履歴管理装置は、データベース１に対する操作履歴を管理するものであり、以下の機能を有する。また、データベース操作履歴管理装置では、データベース１に対する対話型処理とバッチ処理とは、時間帯を分けて行われる。
【００２６】
対話型処理手段２は、入力された処理要求２ａ，２ｂ，２ｃ，・・・に応答して、データベース１の操作を伴う対話型処理を実行する。対話型処理は、たとえば、ネットワークを介して接続される端末装置から送られる処理要求２ａ，２ｂ，２ｃ，・・・に応答して実行されるオンライン処理である。
【００２７】
バッチ処理手段３は、データベース１の操作を伴う一連の処理要求がまとめられたバッチ処理要求３ａに応答して、バッチ処理要求３ａに従った一連のバッチ処理を実行する。
【００２８】
ログ記憶手段４は、データベース１に関連する処理の履歴情報を時系列で保持する。たとえば、操作履歴４ａ，４ｂやチェックポイント（ＣＰ）ログ４ｃが、時系列で保持される。
【００２９】
ログ取得手段５は、バッチ処理の実行中を除き、対話型処理手段２がデータベース１の操作を行う毎に操作内容を示す操作履歴４ａ，４ｂをログ記憶手段４に格納する。また、ログ取得手段５は、バッチ処理手段３によりバッチ処理が実行されると、バッチ処理の実行を示すチェックポイントログ４ｃをログ記憶手段４に格納する。たとえば、ログ取得手段５は、バッチ処理手段３によるデータベース１の最初の操作が行われたときに、チェックポイントログ４ｃをログ記憶手段４に格納する。
【００３０】
このようなデータベース操作履歴管理装置によれば、処理要求２ａ，２ｂ，２ｃ，・・・が入力されると対話型処理手段２により、データベース１の操作を伴う処理が実行される。すると、ログ取得手段５により、データベース１の操作が行われる毎に操作内容を示す操作履歴４ａ，４ｂがログ記憶手段４に格納される。また、バッチ処理要求３ａが入力されると、バッチ処理手段３によりバッチ処理要求３ａに従った一連のバッチ処理が実行される。ログ取得手段５によるバッチ処理の実行中は操作履歴の格納は行われず、バッチ処理の実行を示すチェックポイントログ４ｃがログ記憶手段４に格納される。
【００３１】
このようにしてログ記憶手段４に格納された各種ログを利用すれば、システム障害等によりデータベース１の内容の正確性が保証できなくなったときに、データベース１を最新の状態に復旧することができる。
【００３２】
たとえば、バッチ処理中に障害が発生すると、ログ記憶手段４に格納されている操作履歴４ａ，４ｂに基づいて、データベース１に対して実行された操作を、時系列に沿って、チェックポイントログ４ｃに達するまで順次再実行する。そして、バッチ処理要求３ａに応じたバッチ処理を再度実行する。これにより、バッチ処理中に障害が発生しても、データベース１の内容を最新の状態まで復旧することができる。しかも、バッチ処理の開始前にデータベース１のバックアップを取っておく必要が無いため、処理効率が向上する。
【００３３】
なお、ログ取得手段５は、バッチ処理手段３によりデータベース１が操作されたときにのみチェックポイントログをログ記憶手段４に格納してもよい。これにより、ログ記憶手段４を参照してチェックポイントログが書き込まれていなければ、バッチ処理においてデータベース１の操作が行われなかったことが分かる。すなわち、以後、継続した対話型処理を実行する場合でも、データベース１のバックアップを行わなくても良いことが分かり、作業を簡略化することができる。
【００３４】
また、データベースが複数の資源で構成される場合、ログ取得手段５は、バッチ処理手段３による複数の資源それぞれの操作の有無を示す資源毎のチェックポイントログを、ログ記憶手段４に格納してもよい。これにより、バッチ処理中の資源毎の操作の有無を把握することができる。以後、継続した対話型処理を実行する場合、更新された資源のバックアップのみを行えばよいことが分かり、作業を簡略化することができる。なお、データベース１を構成する資源は、たとえば、ＤＳＩ（Ｄａｔａ　Ｓｔｒｕｃｔｕｒｅ　Ｉｎｓｔａｎｃｅ）と呼ばれる格納構造のデータである。
【００３５】
ところで、複数のユーザが共用するコンピュータシステムでは、対話型処理の１つであるオンライン処理が行われる場合が多い。オンライン処理を実行するオンライン業務とバッチ処理を実行するバッチ業務とを、時間帯を分けて実施するコンピュータシステムとして、たとえば、銀行のオンラインシステムなどがある。銀行のオンラインシステムでは、日中は、各店舗においてオペレータが入力した処理要求に応じて、オンライン業務が実行され、夜間はメンテナンス作業を含めたバッチ処理が実行される。
【００３６】
以下、対話型処理として、ネットワーク経由で接続された端末装置からの処理要求に応じたオンライン処理を行う場合の例を採り、本発明の実施の形態を具体的に説明する。なお、以下の実施の形態では、操作履歴として記録された情報を、アーカイブログと呼ぶこととする。
【００３７】
図２は、本実施の形態のシステム構成例を示す図である。図２の例では、データベースサーバ１００に対して、ネットワーク１０を介して複数の端末装置２０１，２０２，２０３，・・・が接続されている。データベースサーバ１００は、オンライン業務やバッチ業務に関連するデータベースを保持するサーバコンピュータである。端末装置２０１，２０２，２０３，・・・は、ネットワーク１０を介してデータベースサーバ１００にアクセスし、オンライン業務の処理要求を送信することができる。
【００３８】
図３は、本発明の実施の形態に用いるデータベースサーバのハードウェア構成例を示す図である。データベースサーバ１００は、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）１０１によって装置全体が制御されている。ＣＰＵ１０１には、バス１０８を介してＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）１０２、ハードディスクドライブ（ＨＤＤ：Ｈａｒｄ　Ｄｉｓｋ　Ｄｒｉｖｅ）１０３ａ，１０３ｂ，１０３ｃ、グラフィック処理装置１０４、入力インタフェース１０５、テープ装置１０６および通信インタフェース１０７が接続されている。
【００３９】
ＲＡＭ１０２には、ＣＰＵ１０１に実行させるＯＳ（Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０２には、ＣＰＵ１０１による処理に必要な各種データが格納される。ＨＤＤ１０３ａ，１０３ｂ，１０３ｃには、ＯＳや応用（アプリケーション）プログラムが格納される。特に、ＨＤＤ１０３ａは、データベースを格納するためにも利用される。また、１０３ｂは、アーカイブログを格納するためにも利用される。ＨＤＤ１０３ｃは、バックアップされた退避データを格納するためにも利用される。
【００４０】
グラフィック処理装置１０４には、モニタ１１が接続されている。グラフィック処理装置１０４は、ＣＰＵ１０１からの命令に従って、画像をモニタ１１の画面に表示させる。入力インタフェース１０５には、キーボード１２とマウス１３とが接続されている。入力インタフェース１０５は、キーボード１２やマウス１３から送られてくる信号を、バス１０８を介してＣＰＵ１０１に送信する。
【００４１】
テープ装置１０６は、バックアップ用の退避データを、所定の磁気テープに記録する装置である。すなわち、バックアップ処理で生成された退避データは、一旦、バックアップ用のＨＤＤ１０３ｃに格納され、その後、ＨＤＤ１０３ｃ内の退避データが、テープ装置１０６によって磁気テーブに記録される。
【００４２】
通信インタフェース１０７は、ネットワーク１０に接続されている。通信インタフェース１０７は、ネットワーク１０を介して、他のコンピュータ（たとえば、端末装置２０１，２０２，２０３，・・・）との間でデータの送受信を行う。
【００４３】
以上のようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。なお、図３には、データベースサーバ１００のハードウェア構成例を示したが、端末装置２０１，２０２，２０３，・・・も同様のハードウェア構成で実現することができる。
【００４４】
次に、データベースサーバ１００が本実施の形態の処理を実行するために有している処理機能について説明する。
図４は、データベースサーバの機能構成を示すブロック図である。データベースサーバ１００は、データベース１１１、アーカイブログ記憶部１１２、退避データ記憶部１１３、ログ管理ファイル１１４、オンライン業務処理部１２１、バッチ業務処理部１２２、データベース操作部１３１、アーカイブログ取得部１４１、履歴再現部１４２、バックアップ部１５１、およびリストア部１５２を有している。
【００４５】
データベース１１１には、各種業務の結果、発生するデータが格納される。格納されるデータは、資源１１１ａ，１１１ｂ，１１１ｃ，・・・毎に管理されている。資源１１１ａ，１１１ｂ，１１１ｃ，・・・は、それぞれ個別の用途に応じたデータが格納されている。たとえば、データベース１１１は、図３に示すＨＤＤ１０３ａ内の記憶領域である。
【００４６】
アーカイブログ記憶部１１２は、データベース１１１へのデータの挿入等の操作に応じたアーカイブログが時系列で記録された記録領域である。たとえば、アーカイブログ記憶部１１２は、図３に示すＨＤＤ１０３ｂ内の記憶領域である。
【００４７】
退避データ記憶部１１３は、バックアップ処理により退避される退避データを格納する記憶領域である。たとえば、退避データ記憶部１１３は、図３のＨＤＤ１０３ｃ内の記憶領域である。
【００４８】
ログ管理ファイル１１４は、アーカイブログ取得処理に関する各種管理情報が格納されるファイルである。ログ管理ファイル１１４には、アーカイブログの出力を実行するか否かを示すフラグ（アーカイブログ出力停止フラグ）が設定されている。
【００４９】
オンライン業務処理部１２１は、端末装置２０１，２０２，２０３，・・・から送られたオンラインの処理要求に応じてオンライン業務を実行する処理機能である。オンライン業務処理部１２１は、オンライン業務実行用の応用プログラムをデータベースサーバ１００が実行することで実現する。
【００５０】
バッチ業務処理部１２２は、システム管理者によるキーボード１２等を介した操作入力に応答して、バッチ処理を実行する処理機能である。バッチ業務処理部１２２は、バッチ業務実行用の応用プログラムをデータベースサーバ１００が実行することで実現する。
【００５１】
データベース操作部１３１は、オンライン業務処理部１２１やバッチ業務処理部１２２からの要求に応答して、データベース１１１に対するデータの入出力を行う。たとえば、任意の資源に対するデータの挿入要求が出された場合には、データベース操作部１３１は、データベース１１１内の指定された資源へデータを挿入する。任意の資源内のデータの参照要求が出された場合には、データベース操作部１３１は、データベース１１１内の指定された資源からデータを取得し、要求を出力したアプリケーション（オンライン業務処理部１２１もしくはバッチ業務処理部１２２）へ取得したデータを渡す。
【００５２】
アーカイブログ取得部１４１は、データベース操作部１３１で実行されるデータベース１１１の操作を監視する。そして、データベース操作部１３１によるデータベース１１１の操作が行われる場合、アーカイブログ取得部１４１は、その操作の内容を表す操作履歴（アーカイブログ）を取得し、アーカイブログ記憶部１１２に格納する。
【００５３】
なお、アーカイブログ取得部１４１は、アーカイブログを取得した際、ログ管理ファイル１１４に設定されているアーカイブログ出力停止フラグを参照して、アーカイブログ出力停止フラグがＯＦＦの場合にのみ、アーカイブログの格納処理を行う。ただし、アーカイブログ取得部１４１は、アーカイブログ出力停止フラグがＯＮであっても、バッチ業務における各資源に対する最初の操作が行われた場合には、チェックポイントログをアーカイブログ記憶部１１２に格納する。また、アーカイブログ取得部１４１は、バックアップ部１５１によるバックアップ処理の状況を監視しており、資源のバックアップが行われると、アーカイブログ出力停止フラグがＯＮであっても、バックアップされたことを示すバックアップログをアーカイブログ記憶部１１２に格納する。
【００５４】
履歴再現部１４２は、アーカイブログ記憶部１１２に蓄積されているアーカイブログを参照し、システム障害等によりデータの内容が過去の状態に戻ってしまったデータベース１１１を最新の状態に復旧する。具体的には、履歴再現部１４２は、アーカイブログ記憶部１１２に蓄積されているアーカイブログを、蓄積された時刻が古いものから順に取得し、そのアーカイブログで示されるデータベース１１１への操作を再実行する。
【００５５】
バックアップ部１５１は、ユーザからの操作入力等に応答して、データベース１１１に格納されているデータのバックアップを行う。具体的には、バックアップ部１５１は、操作入力で指定された資源のデータを全て抽出する。そして、バックアップ部１５１は、抽出したデータを退避データとして、退避データ記憶部１１３に格納する。このとき、データの圧縮が指定されている場合には、バックアップ部１５１は、抽出したデータを所定のデータ圧縮アルゴリズムで圧縮し、圧縮後のデータを退避データとする。
【００５６】
リストア部１５２は、ユーザからの操作入力に応答して、退避データ記憶部１１３に格納されている退避データを、データベース１１１内にリストアする。退避データのリストアは、資源毎に行われる。
【００５７】
図５は、アーカイブログ記憶部のデータ構造例を示す図である。アーカイブログ記憶部１１２には、アーカイブログ１１２ａ，１１２ｂ，１１２ｃ，１１２ｄ，１１２ｉ，１１２ｊ、チェックポイント（ＣＰ）ログ１１２ｅ，１１２ｆ、バックアップログ１１２ｇ，１１２ｈなどのデータが格納されている。
【００５８】
アーカイブログ１１２ａ，１１２ｂ，１１２ｃ，１１２ｄ，１１２ｉ，１１２ｊは、データベース操作部１３１によってデータベース１１１に対して実行されたデータの操作内容を示す履歴データである。アーカイブログ１１２ａ，１１２ｂ，１１２ｃ，１１２ｄ，１１２ｉ，１１２ｊには、処理の内容、操作対象の資源名、操作時刻、操作対象ページ（本実施の形態では、資源内のデータがページ単位で管理されている）、データ内容などの情報が含まれる。たとえば、アーカイブログ１１２ａは、処理の内容が「挿入」、操作対象資源名が「Ａ」、操作時刻が「２００２年７月７日９時１分（２００２．０７．０７　０９：０１）」、操作対象ページが「ｐａｇｅ＃１」、データ内容が「ｄａｔａ＃１」である。
【００５９】
ＣＰログ１１２ｅ，１１２ｆは、バッチ業務処理部１２２からの要求に応じた各資源への最初の操作が行われたことを示す情報である。ＣＰログ１１２ｅ，１１２ｆには、処理の内容、操作対象の資源名、操作時刻などの情報が含まれる。たとえば、ＣＰログ１１２ｅは、処理の内容が「ＣＰ」、操作対象資源名が「Ａ」、操作時刻が「２００２年７月７日２１時４分（２００２．０７．０７　２１：０４）」である。ＣＰログ１１２ｆは、処理の内容が「ＣＰ」、操作対象資源名が「Ｂ」、操作時刻が「２００２年７月７日２１時１５分（２００２．０７．０７　２１：１５）」である。
【００６０】
バックアップログ１１２ｇ，１１２ｈは、資源のバックアップが行われたことを示す情報である。バックアップログ１１２ｇ，１１２ｈには、処理の内容、操作対象の資源名、操作時刻などの情報が含まれる。たとえば、バックアップログ１１２ｇは、処理の内容が「ｂａｃｋｕｐ」、操作対象資源名が「Ａ」、操作時刻が「２００２年７月７日２３時２分（２００２．０７．０７　２３：０２）」である。バックアップログ１１２ｈは、処理の内容が「ｂａｃｋｕｐ」、操作対象資源名が「Ｂ」、操作時刻が「２００２年７月７日２３時５４分（２００２．０７．０７　２３：５４）」である。
【００６１】
図６は、ログ管理ファイルのデータ構造例を示す図である。ログ管理ファイル１１４には、アーカイブログ記憶部１１２に格納するアーカイブログの入出力を管理するための各種情報が設定されている。その１つに、アーカイブログ出力停止フラグ１１４ａがある。アーカイブログ出力停止フラグ１１４ａは、データベース操作部１３１に対して出力された処理要求に応じたアーカイブログをアーカイブログ記憶部１１２に出力するか否かを示すフラグである。アーカイブログ出力停止フラグ１１４ａは、アーカイブログの出力を停止する際にＯＮが設定され、アーカイブログの出力を行う際にＯＦＦが設定されている。
【００６２】
以上のような構成のデータベースサーバ１００が、以下のような手順で運用される。
図７は、アーカイブログ出力を一時的に停止する場合のシステム運用例を示す図である。
【００６３】
一日の業務が開始されると、データベースサーバ１００では、オンライン業務が実行される（ステップＳ１１）。このとき、アーカイブログ出力運用中である（アーカイブログ出力停止フラグ１１４ａは「ＯＦＦ」）。
【００６４】
オンライン業務中は、端末装置２０１，２０２，２０３，・・・に対するユーザの操作入力に応じて、端末装置２０１，２０２，２０３，・・・からデータベースサーバ１００へ処理要求が送られる。データベースサーバ１００では、オンライン業務処理部１２１が処理要求に応じた処理を実行する。オンライン業務処理部１２１は、処理の実行中にデータベース１１１の操作（データの挿入、削除等）要求をデータベース操作部１３１に対して出力する。操作要求では、操作対象の資源やデータが特定される。データベース操作部１３１は、オンライン業務処理部１２１からの操作要求に従って、データベース１１１内の資源を操作する（たとえば、データを挿入する）。
【００６５】
このときアーカイブログ取得部１４１は、ログ管理ファイル１１４内のアーカイブログ出力停止フラグ１１４ａを参照する。アーカイブログ出力停止フラグ１１４ａが「ＯＦＦ」であることを確認すると、アーカイブログ取得部１４１は、オンライン業務処理部１２１から出された操作要求に従って実行されるデータベース１１１への操作内容を示すアーカイブログを生成し、アーカイブログ記憶部１１２に蓄積する。
【００６６】
オンライン業務を行う時間帯が終了すると、アーカイブログ出力停止処理が行われる（ステップＳ１２）。
具体的には、まず、データベースサーバ１００の管理者により、アーカイブログ出力停止を指令する操作入力が行われる。たとえば、データベースサーバ１００においてアーカイブログ出力停止に対応するコマンドが用意されており、管理者は、キーボード１２等を用いてそのコマンドを入力する。
【００６７】
すると、管理者からの操作入力に応答して、アーカイブログ取得部１４１がログ管理ファイル１１４内のアーカイブログ出力停止フラグ１１４ａを「ＯＮ」に変更する。
【００６８】
次に、バッチ業務が実行される（ステップＳ１３）。
具体的には、データベースサーバ１００の管理者が、バッチ処理の処理要求を操作入力する。たとえば、管理者は、キーボード１２等を用いて、バッチ処理に必要な多数のデータが格納されたファイルを指定したバッチ処理の処理要求を入力する。すると、その処理要求に応じた処理がバッチ業務処理部１２２で実行される。たとえば、バッチ業務処理部１２２は、指定されたファイルからデータを順次取り出し、処理要求に応じたデータベース１１１の操作要求をデータベース操作部１３１に渡す。データベース操作部１３１は、バッチ業務処理部１２２からの操作要求に従って、データベース１１１内の資源を操作する（たとえば、データを挿入する）。
【００６９】
このときアーカイブログ取得部１４１は、バッチ業務処理部１２２からデータベース操作部１３１に渡された操作要求を取得するとともに、ログ管理ファイル１１４内のアーカイブログ出力停止フラグ１１４ａを参照する。アーカイブログ出力停止フラグ１１４ａが「ＯＮ」であることを確認すると、アーカイブログ取得部１４１は、オンライン業務処理部１２１から出された操作要求に応じて操作される資源が、アーカイブログ出力停止後に既に更新されているか否かを判断する。この判断は、操作対象の資源に対応するＣＰログがアーカイブログファイルに格納されているか否かに基づいて行われる。操作対象の資源がまだ更新されていなければ、アーカイブログ取得部１４１は、その資源に応じたＣＰログをアーカイブログ記憶部１１２に蓄積する。
【００７０】
バッチ業務が終了したら、アーカイブログ出力が開始される（ステップＳ１４）。
具体的には、まず、データベースサーバ１００の管理者により、アーカイブログ出力停止を指令する操作入力が行われる。たとえば、データベースサーバ１００においてアーカイブログ出力停止に対応するコマンドが用意されており、管理者は、キーボード１２等を用いてそのコマンドを入力する。
【００７１】
すると、管理者からの操作入力に応答して、アーカイブログ取得部１４１がログ管理ファイル１１４内のアーカイブログ出力停止フラグ１１４ａを「ＯＦＦ」に変更する。
【００７２】
次に、更新された資源の退避データが取得される（ステップＳ１５）。
具体的には、バックアップ部１５１がアーカイブログ記憶部１１２を参照し、更新された資源を判別する。更新された資源の判別は、その資源に対応するＣＰログが格納されているか否かに基づいて行う。次に、バックアップ部１５１は、更新された資源の一覧をモニタ１１に表示する。モニタ１１に表示された一覧を管理者が確認し、管理者は、キーボード１２等を用いて任意の資源のバックアップ指示を操作入力する。たとえば、管理者は、資源を指定したバックアップコマンドを入力する。バックアップ部１５１は、資源のバックアップを指示する操作入力に応答して、指示された資源の退避データを生成し、退避データ記憶部１１３に格納する。
【００７３】
なお、定期的（たとえば、１週間に１回）に、更新された資源の退避データの取得処理（ステップＳ１５）に代えて、データベース１１１全体の退避データが取得される。データベース１１１全体の退避データを取得した際には、アーカイブログ記憶部１１２に蓄積されているアーカイブログを破棄する。
【００７４】
資源の退避データを取得後、処理がオンライン業務（ステップＳ１１）に進められ、ステップＳ１１〜Ｓ１５に示した運用手順が繰り返される。システム運用中にデータベース１１１の内容に正確性が保証できなくなるような障害が発生すると、データベース１１１の復旧作業が行われる。復旧作業は、資源毎に行われる。たとえば、資源が複数のＨＤＤに分散格納されている場合、特定のＨＤＤについての障害であれば、そのＨＤＤに格納された資源の復旧作業が行われる。
【００７５】
データベース１１１の復旧作業の手順は、障害の発生時期に依存する。オンライン業務（ステップＳ１１）およびアーカイブログ出力停止作業（ステップＳ１２）の間に障害が発生した場合、以下の手順でデータベース１１１の復旧作業が行われる。
【００７６】
まず、退避データがリストアされる（ステップＳ２１）。
具体的には、データベースサーバ１００の管理者が、キーボード１２等を用いて、障害が発生した資源から作成された最新の退避データを指定したリストアを指示する操作入力を行う。すると、その操作入力に応答して、リストア部１５２がリストアを行う。すなわち、リストア部１５２は、指定された退避データを、データベース１１１内に格納する。なお、退避データが圧縮形式のデータであれば、リストア部１５２は、圧縮された退避データを復元（展開、解凍、伸張ともいう）した後、データベース１１１内に格納する。
【００７７】
次に、操作履歴が再現される（ステップＳ２２）。
具体的には、データベースサーバ１００の管理者が、キーボード１２等を用いて、障害が発生した資源の履歴再現を指示する操作入力を行う。すると、その操作入力に応答して、履歴再現部１４２がアーカイブログ記憶部１１２を参照し、指定された資源に関するアーカイブログを取得する。ただし、取得するアーカイブログは、指定された資源に関する最新のバックアップログより後に格納されたものである。そして、履歴再現部１４２は、アーカイブログ生成時刻の古い順に資源に対する操作を再現する。
【００７８】
データベース１１１の復旧作業が終わると、障害発生時点の業務が再開される。
バッチ業務（ステップＳ１３）、アーカイブログ出力開始（ステップＳ１４）、および更新された資源の退避データ取得（ステップＳ１５）の各作業中に障害が発生した場合、以下の手順でデータベース１１１の復旧作業が行われる。
【００７９】
まず、退避データがリストアされる（ステップＳ３１）。具体的処理内容は、ステップＳ２１の処理と同様である。
次に、操作履歴が再現される（ステップＳ３２）。
【００８０】
具体的には、データベースサーバ１００の管理者が、キーボード１２等を用いて、障害が発生した資源の履歴再現を指示する操作入力を行う。すると、その操作入力に応答して、履歴再現部１４２がアーカイブログ記憶部１１２を参照し、指定された資源に関するアーカイブログを取得する。ただし、取得するアーカイブログは、指定された資源に関する最新のバックアップログより後に格納され、且つ指定された資源に関する最新のＣＰログより前に格納されたものである。そして、履歴再現部１４２は、アーカイブログ生成時刻の古い順に資源に対する操作を再現する。
【００８１】
さらに、バッチ業務が最初から再実行される（ステップＳ３３）。
データベース１１１の復旧作業が終わると、障害発生時点の業務が再開される。ただし、バッチ業務中に障害が発生した場合には、そのバッチ業務は再実行により完了しているため、その次の業務から再開される。
【００８２】
このような手順で運用することにより、最低限のバックアップ処理でデータベースを復旧させるための情報を格納することができる。
次に、本実施の形態に係るデータベースサーバ１００で行われる主な処理に関する処理手順を詳細に説明する。
【００８３】
まず、アーカイブログ出力停止フラグの設定処理について説明する。本実施の形態では、データベースサーバ１００において、アーカイブログ設定コマンドが用意されている。アーカイブログ設定コマンドは、たとえば、引数によってアーカイブログの出力を停止するのか、開始するのかを指定することができる。
【００８４】
図８は、アーカイブログ設定コマンドの実行手順を示すフローチャートである。以下、図８に示す処理をステップ番号に沿って説明する。
［ステップＳ４１］アーカイブログ設定コマンドが入力されると、アーカイブログ取得部１４１は、アーカイブログ設定コマンドで要求されている処理が、アーカイブログ出力の停止なのか開始なのかを判断する。たとえば、アーカイブログ設定コマンドに設定されている引数に基づいて判断することができる。
【００８５】
アーカイブログ出力の停止要求であれば処理がステップＳ４２に進められる。アーカイブログ出力の開始要求であれば処理がステップＳ４３に進められる。
［ステップＳ４２］アーカイブログ取得部１４１は、ログ管理ファイル１１４内のアーカイブログ出力停止フラグを「ＯＮ」にする。これにより、以後のアーカイブログの出力が停止される（ＣＰログ、バックアップログを除く）。その後、処理が終了する。
【００８６】
［ステップＳ４３］アーカイブログ取得部１４１は、ログ管理ファイル１１４内のアーカイブログ出力停止フラグを「ＯＦＦ」にする。これにより、以後のデータベース１１１に対する操作が行われる毎に、アーカイブログが出力される。その後、処理が終了する。
【００８７】
次に、データベース操作要求に対応する処理について説明する。
図９は、データベース操作要求対応処理の手順を示すフローチャートである。以下、図９に示す処理をステップ番号に沿って説明する。この処理は、オンライン業務処理部１２１またはバッチ業務処理部１２２からデータベース１１１の操作要求が出されたときに実行が開始される。
【００８８】
［ステップＳ５１］アーカイブログ取得部１４１は、アーカイブログ出力が停止状態か否かを判断する。具体的には、アーカイブログ取得部１４１は、ログ管理ファイル１１４内のアーカイブログ出力停止フラグ１１４ａを参照し、「ＯＮ」であれば出力停止状態であり、「ＯＦＦ」であれば出力停止状態ではないと判断する。出力停止状態の場合には処理がステップＳ５２に進められる。出力停止状態の場合には処理がステップＳ５５に進められる。
【００８９】
［ステップＳ５２］アーカイブログ取得部１４１は、チェックポイント（ＣＰ）ログを出力済みか否かを判断する。具体的には、アーカイブログ取得部１４１は、操作対象となる資源に対応するチェックポイントログ（該当する資源のバックアップログより以前に登録されたものは除く）をアーカイブログ記憶部１１２から検索する。操作対象資源のチェックポイントログの検出の有無により、チェックポイントログが出力済みか否かを判断することができる。
【００９０】
チェックポイントログが出力済みの場合には、処理がステップＳ５４に進められる。チェックポイントログが未出力の場合には、処理がステップＳ５３に進められる。
【００９１】
［ステップＳ５３］アーカイブログ取得部１４１は、チェックポイント出力処理を行う。具体的には、アーカイブログ取得部１４１は、アーカイブログ記憶部１１２に、操作対象の資源に対応するチェックポイントログを格納する。
【００９２】
［ステップＳ５４］データベース操作部１３１は、データベース１１１の操作要求に従ってデータの更新（インサート）等の操作を行う。その後、処理が終了する。
【００９３】
［ステップＳ５５］アーカイブログ出力が停止状態ではない場合、データベース操作部１３１は、データベース１１１の操作要求に従ってデータの更新（インサート）等の操作を行う。
【００９４】
［ステップＳ５６］アーカイブログ取得部１４１は、アーカイブログ記憶部１１２に、入力された操作要求に応じたアーカイブログを格納する。その後、処理が終了する。
【００９５】
次に、更新された資源の退避データの取得（ステップＳ１５）の際に、更新された資源の一覧を表示する処理について説明する。
図１０は、更新資源一覧表示処理の手順を示すフローチャートである。以下、図１０に示す処理をステップ番号に沿って説明する。
【００９６】
［ステップＳ６１］バックアップ部１５１は、アーカイブログ記憶部１１２を参照し、ログが存在するか否かを判断する。ログが存在しない場合には、処理がステップＳ６５に進められる。ログが存在する場合処理がステップＳ６２に進められる。
【００９７】
［ステップＳ６２］バックアップ部１５１は、アーカイブログ記憶部１１２からのログの読込が終了したか否かを判断する。ログの読込が終了した場合には処理がステップＳ６５に進められる。ログの読込が終了していない場合には処理がステップＳ６３に進められる。
【００９８】
［ステップＳ６３］バックアップ部１５１は、アーカイブログ記憶部１１２からログを順次読込、アーカイブログ出力停止のチェックポイントログか否かを判断する。チェックポイントログの場合には、処理がステップＳ６４に進められる。チェックポイントログではない場合には、処理がステップＳ６５に進められる。
【００９９】
［ステップＳ６４］バックアップ部１５１は、読み込んだチェックポイントログから情報を獲得して、ＲＡＭ１０２等に保存する。その後、処理がステップＳ６２に進められる。
【０１００】
［ステップＳ６５］バックアップ部１５１は、ステップＳ６４の処理でＲＡＭ１０２等に保存したチェックポイントログに基づく情報を更新資源一覧画面として、モニタ１１に表示させる。その後、処理が終了する。
【０１０１】
図１１は、更新資源一覧画面の一例を示す図である。更新資源一覧画面６０には、チェックポイントログ毎に、チェックポイントログの記録された日付と、データベース情報とが表示されている。データベース情報には、データベース名と資源名とが含まれる。
【０１０２】
システムの管理者は、このような更新資源一覧画面６０を参照して、バックアップ処理により退避データを取得すべき資源を判断することができる。たとえば、本日が２００２年７月７日であり、バッチ業務が毎日行われている場合、日付が”２００２／０７／０７”である情報に対応づけて表示されているデータベース情報によって、更新された資源を判断することができる。図１１の例では、「在庫管理ＤＢ」という名称のデータベースの「在庫表ＤＳＩ」という名称の資源が７月７日の深夜に行われたバッチ業務により更新されたことが分かる。データベースサーバ１００の管理者が、更新された資源のバックアップを指示する操作入力を行えば、バックアップ部１５１によってその資源の退避データが作成され、退避データ記憶部１１３に格納される。
【０１０３】
次に、バッチ業務中にディスク障害等の異常が発生した場合の復旧（リカバリ）処理について説明する。
図１２は、リカバリ処理の手順を示すフローチャートである。以下、図１２に示す処理をステップ番号に沿って説明する。
【０１０４】
［ステップＳ７１］リストア部１５２は、管理者からの操作入力に応じて、指定された資源に対し、退避データのリストアを行う。退避データは、たとえば、前日のバッチ業務実施後に取得されたもの、または、過去のある時点に取得されたものである。
【０１０５】
［ステップＳ７２］履歴再現部１４２は、復旧させるべき資源にアーカイブログ適用を開始する。
［ステップＳ７３］履歴再現部１４２は、アーカイブログ記憶部１１２内にログが存在するか否かを判断する。ログが存在する場合には処理がステップＳ７４に進められる。ログが存在しない場合には、処理がステップＳ７７に進められる。
【０１０６】
［ステップＳ７４］履歴再現部１４２は、アーカイブログ記憶部１１２からログを順次読み込み、アーカイブログ出力停止のＣＰログか否かを判断する。ＣＰログの場合には、処理がステップＳ７６に進められる。ＣＰログではない場合には、処理がステップＳ７５に進められる。
【０１０７】
［ステップＳ７５］履歴再現部１４２は、アーカイブログの適用処理を行う。具体的には、アーカイブログで示されているデータベース１１１内のデータの操作内容を解析し、アーカイブログが取得されたときと同様の操作をデータベース１１１に対して行う。その後、処理がステップＳ７３に進められる。
【０１０８】
［ステップＳ７６］履歴再現部１４２は、バッチ業務開始状態に復元完了通知をモニタ１１に表示する。
［ステップＳ７７］履歴再現部１４２は、アーカイブログの適用を終了する。
【０１０９】
障害の発生がバッチ業務中であれば、リカバリ処理後、バッチ業務を最初から再実行する。
このように、アーカイブログ適用時にチェックポイントログが検出されない場合には、バッチ業務時にデータが更新されなかったデータベースと認識できる。この結果、アーカイブログは連続していると判断できるため、最新状態まで（アーカイブログ出力停止区間を挟んだ）復旧が可能である。
【０１１０】
なお、各資源に対応するチェックポイントログの検出の有無に基づき、バッチ業務中に操作された資源のバックアップを自動的に実行することも可能である。この場合、復旧処理を実行後は、バッチ業務開始まで復元が完了した資源（対応するチェックポイントログが検出された資源）と、最新状態まで復元が完了した資源（対応するチェックポイントログが検出されない資源）が存在する。そこで、各資源の復元状態を画面に表示してもよい。
【０１１１】
以上説明したように、本実施の形態では、アーカイブログの停止期間があってもデータベースの復旧が可能となる、これにより、バッチ業務前に退避データの取得が不要となる。また、チェックポイントログによりバッチ業務中に操作された資源が判別可能であるため、バッチ業務後には、バッチ業務で操作された資源に限定して、退避データの取得を行うことができる。
【０１１２】
その結果、退避データを取得するディスクの大幅な削減が可能となり、ＨＤＤ等のストレージデバイスの使用効率が向上する。また、退避データの取得時間の短縮により、システム全体のパフォーマンスが向上する。
【０１１３】
なお、上記の処理機能は、コンピュータによって実現することができる。その場合、データベース操作履歴管理装置が有すべき機能の処理内容を記述したデータベース操作履歴管理プログラムが提供される。そのデータベース操作履歴管理プログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したデータベース操作履歴管理プログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記録装置には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＤＶＤ（Ｄｉｇｉｔａｌ　Ｖｅｒｓａｔｉｌｅ　Ｄｉｓｃ）、ＤＶＤ−ＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ　Ｄｉｓｃ　Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）、ＣＤ−Ｒ（Ｒｅｃｏｒｄａｂｌｅ）／ＲＷ（ＲｅＷｒｉｔａｂｌｅ）などがある。光磁気記録媒体には、ＭＯ（Ｍａｇｎｅｔｏ−Ｏｐｔｉｃａｌ　ｄｉｓｃ）などがある。
【０１１４】
データベース操作履歴管理プログラムを流通させる場合には、たとえば、そのデータベース操作履歴管理プログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭなどの可搬型記録媒体が販売される。また、データベース操作履歴管理プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのデータベース操作履歴管理プログラムを転送することもできる。
【０１１５】
データベース操作履歴管理プログラムを実行するコンピュータは、たとえば、可搬型記録媒体に記録されたデータベース操作履歴管理プログラムもしくはサーバコンピュータから転送されたデータベース操作履歴管理プログラムを、自己の記憶装置に格納する。そして、データベース操作履歴管理コンピュータは、自己の記憶装置からデータベース操作履歴管理プログラムを読み取り、データベース操作履歴管理プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接データベース操作履歴管理プログラムを読み取り、そのデータベース操作履歴管理プログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからデータベース操作履歴管理プログラムが転送される毎に、逐次、受け取ったデータベース操作履歴管理プログラムに従った処理を実行することもできる。
【０１１６】
（付記１）　データベースに対する操作履歴を管理するデータベース操作履歴管理装置において、
入力された処理要求に応答して、前記データベースの操作を伴う対話型処理を実行する対話型処理手段と、
前記データベースの操作を伴う一連の処理要求がまとめられたバッチ処理要求に応答して、前記バッチ処理要求に従った一連のバッチ処理を実行するバッチ処理手段と、
前記データベースに関連する処理の履歴情報を時系列で保持するログ記憶手段と、
前記バッチ処理の実行中を除き、前記対話型処理手段が前記データベースの操作を行う毎に操作内容を示す操作履歴を前記ログ記憶手段に格納し、前記バッチ処理手段により前記バッチ処理が実行されると、前記バッチ処理の実行を示すチェックポイントログを前記ログ記憶手段に格納するログ取得手段と、
を有することを特徴とするデータベース操作履歴管理装置。
【０１１７】
（付記２）　前記ログ取得手段は、前記バッチ処理手段により前記データベースが操作されたときにのみ前記チェックポイントログを前記ログ記憶手段に格納することを特徴とする付記１記載のデータベース操作履歴管理装置。
【０１１８】
（付記３）　前記データベースが複数の資源で構成される場合、前記ログ取得手段は、前記バッチ処理手段による前記複数の資源それぞれの操作の有無を示す前記資源毎の前記チェックポイントログを、前記ログ記憶手段に格納することを特徴とする付記２記載のデータベース操作履歴管理装置。
【０１１９】
（付記４）　前記ログ取得手段は、前記バッチ処理手段による前記複数の資源それぞれに対する最初の操作が行われたとときに、前記資源毎の前記チェックポイントログを前記ログ記憶手段に格納することを特徴とする付記３記載のデータベース操作履歴管理装置。
【０１２０】
（付記５）　前記ログ記憶手段から前記資源毎の前記チェックポイントログを抽出し、抽出した前記チェックポイントログに基づいて操作された前記資源の一覧を表示する一覧表示手段をさらに有することを特徴とする付記３記載のデータベース操作履歴管理装置。
【０１２１】
（付記６）　前記ログ記憶手段に格納されている前記操作履歴に基づいて、前記データベースに対して実行された操作を、時系列に沿って、前記チェックポイントログに達するまで順次再実行する履歴再現手段をさらに有することを特徴とする付記１記載のデータベース操作履歴管理装置。
【０１２２】
（付記７）　操作入力に応答して、前記データベース内のデータのバックアップ処理を行うバックアップ手段を更に有し、
前記ログ取得手段は、前記バックアップ手段によるバックアップ処理の履歴を、前記ログ記憶手段に格納することを特徴とする付記１記載のデータベース操作履歴管理装置。
【０１２３】
（付記８）　前記対話型処理手段は、ネットワーク経由で接続された端末装置からの処理要求に応じたオンライン業務を実行することを特徴とする付記１記載のデータベース操作履歴管理装置。
【０１２４】
（付記９）　データベースに対する操作履歴を管理するデータベース操作履歴管理方法において、
入力された処理要求に応答して、前記データベースの操作を伴う対話型処理を実行し、
前記データベースの操作を行う毎に操作内容を示す操作履歴を、前記データベースに関連する処理の履歴情報を時系列で保持するログ記憶手段に格納し、
前記データベースの操作を伴う対話型処理の実行を停止し、
前記データベースの操作を伴う一連の処理要求がまとめられたバッチ処理要求に応答して、前記バッチ処理要求に従った一連のバッチ処理を実行し、
前記バッチ処理の実行を示すチェックポイントログを前記ログ記憶手段に格納する、
ことを特徴とするデータベース操作履歴管理方法。
【０１２５】
（付記１０）　データベースに対する操作履歴を管理するデータベース操作履歴管理プログラムにおいて、
コンピュータに、
入力された処理要求に応答して、前記データベースの操作を伴う対話型処理を実行し、
前記データベースの操作を行う毎に操作内容を示す操作履歴を、前記データベースに関連する処理の履歴情報を時系列で保持するログ記憶手段に格納し、
前記データベースの操作を伴う対話型処理の実行を停止し、
前記データベースの操作を伴う一連の処理要求がまとめられたバッチ処理要求に応答して、前記バッチ処理要求に従った一連のバッチ処理を実行し、
前記バッチ処理の実行を示すチェックポイントログを前記ログ記憶手段に格納する、
処理を実行させることを特徴とするデータベース操作履歴管理プログラム。
【０１２６】
（付記１１）　データベースに対する操作履歴を管理するデータベース操作履歴管理プログラムを記録したコンピュータ読み取り可能な記録媒体において、
前記コンピュータに、
入力された処理要求に応答して、前記データベースの操作を伴う対話型処理を実行し、
前記データベースの操作を行う毎に操作内容を示す操作履歴を、前記データベースに関連する処理の履歴情報を時系列で保持するログ記憶手段に格納し、
前記データベースの操作を伴う対話型処理の実行を停止し、
前記データベースの操作を伴う一連の処理要求がまとめられたバッチ処理要求に応答して、前記バッチ処理要求に従った一連のバッチ処理を実行し、
前記バッチ処理の実行を示すチェックポイントログを前記ログ記憶手段に格納する、
処理を実行させることを特徴とするデータベース操作履歴管理プログラムを記録したコンピュータ読み取り可能な記録媒体。
【０１２７】
【発明の効果】
以上説明したように本発明では、バッチ処理の実行中はデータベースに対する操作履歴の格納は行わず、バッチ処理の実行を示すチェックポイントログをログ記憶手段に格納するようにしたため、バッチ処理中に障害が発生した場合、チェックポイントログ以前の操作履歴を再現することで、バッチ処理開始以前の状態にデータベースを戻すことができる。その結果、バッチ業務開始前にデータベースのバックアップを行う必要がなくなり、処理効率が向上する。
【図面の簡単な説明】
【図１】実施の形態に適用される発明の概念図である。
【図２】本実施の形態のシステム構成例を示す図である。
【図３】本発明の実施の形態に用いるデータベースサーバのハードウェア構成例を示す図である。
【図４】データベースサーバの機能構成を示すブロック図である。
【図５】アーカイブログ記憶部のデータ構造例を示す図である。
【図６】ログ管理ファイルのデータ構造例を示す図である。
【図７】アーカイブログ出力を一時的に停止する場合のシステム運用例を示す図である。
【図８】アーカイブログ設定コマンドの実行手順を示すフローチャートである。
【図９】データベース操作要求対応処理の手順を示すフローチャートである。
【図１０】更新資源一覧表示処理の手順を示すフローチャートである。
【図１１】更新資源一覧画面の一例を示す図である。
【図１２】リカバリ処理の手順を示すフローチャートである。
【図１３】従来のアーカイブログ運用を一時的に停止する場合のシステム運用例を示す図である。
【符号の説明】
１　データベース
２　対話型処理手段
２ａ，２ｂ，２ｃ　処理要求
３　バッチ処理手段
３ａ　バッチ処理要求
４　ログ記憶手段
４ａ，４ｂ　操作履歴
４ｃ　チェックポイントログ
５　ログ取得手段
１０　ネットワーク
１００　データベースサーバ
２０１，２０２，２０３　端末装置
【図１】
2004078505.tif 000003
【図２】
2004078505.tif 000004
【図３】
2004078505.tif 000005
【図４】
2004078505.tif 000006
【図５】
2004078505.tif 000007
【図６】
2004078505.tif 000008
【図７】
2004078505.tif 000009
【図８】
2004078505.tif 000010
【図９】
2004078505.tif 000011
【図１０】
2004078505.tif 000012
【図１１】
2004078505.tif 000013
【図１２】
2004078505.tif 000014
【図１３】
2004078505.tif 000015