JP2011086241A - データベースの複製を生成する装置及び方法 - Google Patents

Abstract

【課題】静止点におけるデータベースの複製を生成する際のコストを抑える。
【解決手段】ＤＢＭＳ２０では、アプリケーションプログラム１０ａ，１０ｂの要求に応じて、基表更新機能２１が、基表３０及び回復開始点３１を更新し、更新ログ記録機能２２が、基表３０に対する更新ログ４０を記録する。そして、所定のタイミングで、バックアップ機能２３が、基表３０の内容をバックアップファイル５０に出力し、基表３０に付随する回復開始点３１を回復開始点５１にコピーする。その後、ユーザによって静止点及び基表３０が指定されると、複製生成機能６０が、指定された基表３０のバックアップファイル５０を、更新ログ４０の回復開始点５１から静止点までの部分で更新することにより、静止点における基表３０の複製である対象表７０を生成する。
【選択図】図１

Description

本発明は、データベースの複製を生成する装置及び方法に関する。特に、本発明は、特定の時点におけるデータベースの複製を生成する装置及び方法に関する。

近年、２４時間３６５日連続運転するコンピュータシステムが増えている。このようなコンピュータシステムでは、データベースに対して常に更新が行われることになる。しかし、このように常に更新が行われるデータベースであっても、これをバッチ処理に対する入力データや情報系のデータベースとして活用する場合には、ある静止点におけるデータベースを複製したいという要求が出てくる。

例えば常に更新が行われているデータベースの０時における内容が要求された場合を考える。
この場合、このデータベースの表に対して行の挿入しか行われないことが保証されていれば、データベースの０時における内容を読み出すことは可能である。各行に対して挿入時刻を保持するタイムスタンプ列を持たせ、「挿入時刻が０時以前である」という条件を満たす行を読み出せばよいからである。
ところが、このデータベースの表に対して行の更新が行われるとすると、この方法は使用できない。各行に対して更新時刻を保持するタイムスタンプを持たせても、これが複製時にそのまま残っているとは限らないからである。例えば、Ａ行が２３時５９分０秒と０時０分１０秒に更新されたとする。すると、Ａ行が保持するタイムスタンプは０時０分１０秒となる。従って、０時数分過ぎに「更新時刻が０時以前である」という条件を満たす行を検索すると、Ａ行はこの検索結果から外れ、その結果、Ａ行の２３時５９分０秒のデータは失われ、データベースの０時における整合性のある内容は取得できない。このように更新が常時行われているデータベースのある静止点における内容を作成するのは、現在の機能では難しい。
データベースの行を削除した場合も同様、元々存在していた行が、静止点におけるデータベースの内容を取得した際に失われる場合がある。

ここで、ある時点におけるデータベースの内容を取得する技術は、幾つかの公報に開示されている（例えば、特許文献１〜４参照）。

特許文献１では、管理テーブル部が、データベースに登録されている各オブジェクトの管理情報を保持し随時更新され、スナップショット情報記憶部が、ある時点の管理テーブル部のコピーを保持し、バックアップ処理部が、バックアップタイミングになると、スナップショット情報記憶部に保持した情報と、現在の管理テーブル部とを比較し、データベースの変化内容（差分）を特定し、その変化内容を表すバックアップ情報を作成して保管している。

特許文献２では、バックアップ装置が、バックアップを実行する指示を受付けると、指示によって示される時点について作成されるスナップショットを格納する記憶領域を、指示によって示される時点それぞれに割り当て、指示によって示される時点より後に元データが更新されると、指示によって示される直前の時点における更新が行われた箇所に対応する元データが直前の時点について作成される最新のスナップショットを格納する記憶領域として割り当てられた記憶領域に格納されているかを確認し、格納されていないと確認されると、更新が行われた箇所に対応する更新直前の元データを、最新のスナップショットを格納する記憶領域にのみ格納している。

特許文献３では、バックアップ作成装置が、データベースのバックアップ処理を行うと共に、バックアップ処理の進捗状況通知を生成し、データベース参照・更新処理装置が、データベースの参照・更新処理を行なうと共に、データベースに対して行ったデータの追加又は更新内容を表わす追加更新情報を出力し、バックアップ作成状況通知装置が、バックアップの進捗状況通知と追加更新情報に基づいてバックアップ処理済みのデータに対して追加更新がなされているかを判定し、バックアップ処理済みのデータに対して追加更新がなされた場合に、追加更新反映装置が、追加更新情報に基づいてバックアップデータに対してデータの追加更新処理を行っている。

特許文献４では、システム復旧管理部が、ストレージ装置のバックアップリストア処理部を用いて、ボリュームの初期状態のバックアップならびにシステム稼動中のスナップショットを作成し、回復ポイントを用いて状況を管理し、システムの障害発生時には、回復ポイントから回復するポイントを決定し、作成したバックアップからのボリュームの復元と、データの整合性を保つためメタデータの書き換えを行っている。

特開２００１−３４４１３９号公報 特開２００９−１４６２２８号公報 特開平９−９７２０１号公報 特開２００５−２４２７２９号公報

しかしながら、何れの特許文献も、ある時点におけるデータベースの内容のバックアップ、或いは、これに加えてリストアを行うに過ぎず、ある時点におけるデータベースの複製を作成するものではない。
ここで、ある時点におけるデータベースの複製を作成するには、次のようなアプローチがある。
第一に、業務アプリケーションにデータベースを更新させながら、データベースからデータを取り出し、その取り出しを行う間に業務アプリケーションが記録した取引ログ（業務ログ）を、取り出したデータに当て込む、というアプローチである。
第二に、データベースを更新する際に別表も更新し、静止点において別表の更新を一旦停止することで、静止点におけるデータベースの複製を作成する、というアプローチである。
しかしながら、何れのアプローチも、実装及びシステム運用にコストがかかるという問題がある。特に数千テーブル或いは数ＴＢのデータベースを保有する大規模システムの場合、このようなアプローチでの実装及び運用は現実的ではない。

本発明の目的は、特定の時点におけるデータベースの複製を生成する際のコストを抑えることにある。

かかる目的のもと、本発明は、特定の時点におけるデータベースの複製を生成する装置であって、データベースの回復に用いるためにＤＢＭＳ（DataBase Management System）が特定の時点よりも前にデータベースの更新を停止することなく出力したデータベースのバックアップデータを取得するバックアップデータ取得部と、データベースの回復に用いるためにＤＢＭＳがバックアップデータを出力した時間帯よりも前の回復開始点から特定の時点までの間に記録したデータベースの更新ログを取得する更新ログ取得部と、バックアップデータ取得部により取得されたバックアップデータと、更新ログ取得部により取得された更新ログとに基づいて、特定の時点におけるデータベースの内容を保持する新たなデータベースを複製として生成する生成部とを含む、装置を提供する。

ここで、生成部は、バックアップデータ取得部により取得されたバックアップデータを、更新ログ取得部により取得された更新ログのうち特定の時点よりも前にコミットされたトランザクションに関する部分で更新することにより、新たなデータベースを生成する、ものであってよい。
生成部は、バックアップデータ取得部により取得されたバックアップデータを、更新ログ取得部により取得された更新ログのうちバックアップデータに反映されていない更新に関する部分で更新することにより、新たなデータベースを生成する、ものであってよい。
この装置は、ユーザによる特定の時点の指定を受け付ける受付部を更に含む、ものであってよい。
この装置は、バックアップデータ取得部により取得されたバックアップデータに関連付けて記憶された回復開始点を取得する回復開始点取得部を更に含む、ものであってよい。

また、本発明は、特定の時点におけるデータベースの複製を生成する装置であって、データベースの回復に用いるためにデータベースの更新を停止することなくデータベースのバックアップデータを出力する出力機能と、データベースの回復に用いるためにデータベースの更新ログを記録する記録機能とを少なくとも有する、ＤＢＭＳ（DataBase Management System）と、特定の時点よりも前にＤＢＭＳの出力機能により出力されたバックアップデータと、バックアップデータを出力した時間帯よりも前の回復開始点から特定の時点までの間にＤＢＭＳの記録機能により記録された更新ログとに基づいて、特定の時点におけるデータベースの内容を保持する新たなデータベースを複製として生成する生成部とを含む、装置も提供する。

ここで、この装置は、ＤＢＭＳの出力機能により出力されたバックアップデータに関連付けて、バックアップデータが出力された時間帯よりも前のチェックポイントを記憶する記憶部と、記憶部にバックアップデータに関連付けて記憶されたチェックポイントを回復開始点に決定する決定部とを更に含む、ものであってよい。

また、本発明は、特定の時点におけるデータベースの複製を生成する装置であって、データベースの回復に用いるためにデータベースの更新を停止することなくデータベースのバックアップデータを出力する出力機能と、データベースの回復に用いるためにデータベースの更新ログを記録する記録機能とを少なくとも有する、ＤＢＭＳ（DataBase Management System）と、特定の時点よりも前にＤＢＭＳの出力機能により出力されたバックアップデータを取得するバックアップデータ取得部と、バックアップデータを出力した時間帯よりも前の回復開始点から特定の時点までの間にＤＢＭＳの記録機能により記録された更新ログを取得する更新ログ取得部と、バックアップデータ取得部により取得されたバックアップデータを、更新ログ取得部により取得された更新ログのうち、特定の時点よりも前にコミットされたトランザクションに関し、かつ、バックアップデータに反映されていない更新に関する部分で更新することにより、特定の時点におけるデータベースの内容を保持する新たなデータベースを複製として生成する生成部とを含む、装置も提供する。

更に、本発明は、特定の時点におけるデータベースの複製を生成する方法であって、データベースの回復に用いるためにＤＢＭＳ（DataBase Management System）が特定の時点よりも前にデータベースの更新を停止することなく出力したデータベースのバックアップデータを取得するステップと、データベースの回復に用いるためにＤＢＭＳがバックアップデータを出力した時間帯よりも前の回復開始点から特定の時点までの間に記録したデータベースの更新ログを取得するステップと、バックアップデータと、更新ログとに基づいて、特定の時点におけるデータベースの内容を保持する新たなデータベースを複製として生成するステップとを含む、方法も提供する。

更にまた、本発明は、特定の時点におけるデータベースの複製を生成する装置としてコンピュータを機能させるプログラムであって、コンピュータを、データベースの回復に用いるためにＤＢＭＳ（DataBase Management System）が特定の時点よりも前にデータベースの更新を停止することなく出力したデータベースのバックアップデータを取得するバックアップデータ取得部と、データベースの回復に用いるためにＤＢＭＳがバックアップデータを出力した時間帯よりも前の回復開始点から特定の時点までの間に記録したデータベースの更新ログを取得する更新ログ取得部と、バックアップデータ取得部により取得されたバックアップデータと、更新ログ取得部により取得された更新ログとに基づいて、特定の時点におけるデータベースの内容を保持する新たなデータベースを複製として生成する生成部として機能させる、プログラムも提供する。

本発明によれば、特定の時点におけるデータベースの複製を生成する際のコストを抑えることができる。

本発明の実施の形態が適用されるコンピュータの構成例を示した図である。 本発明の実施の形態の動作の概要について示した図である。 トランザクション、バックアップ、回復開始点、静止点を時間軸上に示した図である。 更新ログの一例を示した図である。 各時点における基表の状態を示した図である。 複製される基表に対する回復開始点から静止点までの更新ログの一例を示した図である。 更新ログで更新することによる対象表の内容の変化を示した図である。 本発明の実施の形態における複製生成機能の構成例を示したブロック図である。 本発明の実施の形態における複製生成機能の動作例を示したフローチャートである。 本発明の実施の形態を適用可能なコンピュータのハードウェア構成を示した図である。

本発明の実施の形態は、従来データベースの障害回復のためにしか使用していなかったバックアップデータと更新ログとを活用し、業務上有用な任意の静止点における表の複製を容易に作成可能とするものである。
この動作の概要を簡単に説明すると次のようになる。尚、ここでは、データベース内の複製元の表（基表）をTABLE1とし、基表の複製を格納する対象の表（対象表）をTABLEXとして説明する。
まず、ＤＢＭＳ（DataBase Management System）は、TABLE1の更新を停止することなくオンラインバックアップを行い、バックアップデータを取得する。
次に、ＤＢＭＳは、TABLE1のバックアップデータと更新ログとを使用してTABLEXのデータを作成する。即ち、任意の静止点が決まると、TABLE1のバックアップデータをTABLEXに反映し、TABLE1の更新ログを当てて静止点までデータを復元する。その結果、TABLEXは、ある静止点におけるTABLE1のデータを持つ表となり、バッチ処理に対する入力データ、情報系データベース等として、業務上の活用が可能となる。

以下、添付図面を参照して、本発明の実施の形態について詳細に説明する。
図１は、本実施の形態が適用されるコンピュータの構成を示したブロック図である。
図示するように、コンピュータは、アプリケーションプログラム（以下、単に「アプリケーション」という）１０ａ，１０ｂと、ＤＢＭＳ２０と、基表３０とを備える。また、更新ログ４０と、バックアップファイル５０と、複製生成機能６０と、対象表７０とを備える。

アプリケーション１０ａ，１０ｂは、ＤＢＭＳ２０に対して、基表３０の更新を要求する。尚、図では、アプリケーション１０ａ，１０ｂを示しているが、これらを区別する必要がない場合は、アプリケーション１０と表記する。また、アプリケーション１０は、ここでは２つしか示していないが、３つ以上あってもよい。

ＤＢＭＳ２０は、基表３０を含むデータベースを管理するプログラムである。特に、本実施の形態におけるＤＢＭＳ２０は、基表３０に対する更新データを更新ログ４０に書き出しながら稼働し、オペレーターの要求に応じて基表３０の内容をバックアップファイル５０に出力するものであり、基表更新機能２１と、更新ログ記録機能２２と、バックアップ機能２３とを含む。

このうち、基表更新機能２１は、アプリケーション１０から基表３０の更新が要求されると、基表３０を更新する。また、データベース上の整合性が保証された時点で、基表３０に付随する回復開始点３１（回復に用いる更新ログ４０の位置を示す情報）を更新する。

また、更新ログ記録機能２２は、基表３０の更新の取り消しや再実行を行う際に必要な更新データを更新ログ４０に書き出し、コミット時にはコミットが行われたことを示すコミット情報を更新ログ４０に書き出す。本実施の形態では、更新ログを記録する記録機能の一例として、更新ログ記録機能２２を設けている。

更に、バックアップ機能２３は、基表３０がアプリケーション１０により更新中であっても基表３０のバックアップを取得してバックアップファイル５０に出力する。これは、例えば、ＤＢＭＳ２０内のバッファプール（不図示）に基表３０及び回復開始点３１のデータを一時的に格納し、このバッファプール内のデータを読むことで可能である。或いは、バッファプール内のデータを読まずに、基表３０及び回復開始点３１を物理ディスクファイルとしてバックアップすることで行ってもよい。尚、このバックアップは、目標静止点（ユーザによって指定される可能性のある静止点）の前に実行すればよい。その際、目標静止点の直前の時刻に実行するか目標静止点から一定の間隔をあけた時刻に実行するかは任意であるが、目標静止点に近い時刻に実行することで、基表３０の複製の作成に要する時間は短縮される。また、ある静止点における複数の基表３０の内容が必要な場合も、オンラインバックアップを実行する時刻は、それぞれの基表３０に対して、任意に設定可能である。つまり、複数の基表３０のバックアップを同一時刻に取得しなければならない等の制約はない。本実施の形態では、バックアップデータを出力する出力機能の一例として、バックアップ機能２３を設けている。

尚、本明細書では、ＤＢＭＳ２０を、上述したようにプログラムとして説明するが、プログラムが実行されることによって実現されるコンピュータの機能として捉えることもできる。

基表３０は、アプリケーション１０によって更新される表であり、常に更新されているものとする。尚、ここでは単に「基表３０」と称するが、これを、基表３０を記憶する記憶手段として捉えてもよい。また、基表３０には、回復開始点３１が付随して記憶されている。

更新ログ４０は、基表３０の更新の取り消しや再実行を行う際に必要な更新データを保持する。ここで、更新ログ４０内のログレコードは、ＲＢＡ（相対バイトアドレス）やタイムスタンプ等の更新ログ４０内でのログレコードの位置を示すログ位置情報と、そのログレコードに対応する基表３０内の更新されたレコードの位置を示す更新位置情報とを保持している。尚、ここでは単に「更新ログ４０」と称するが、これを、更新ログ４０を記憶する記憶手段として捉えてもよい。

バックアップファイル５０は、基表３０のバックアップが出力されるファイルである。尚、ここでは単に「バックアップファイル５０」と称するが、これを、バックアップファイル５０を記憶する記憶手段として捉えてもよい。また、バックアップファイル５０には、回復開始点５１が付随して記憶されている。この回復開始点５１は、基表３０がバックアップされた際に、基表３０に付随して記憶された回復開始点３１がコピーされたものである。ここで、バックアップファイル５０は、アプリケーション１０による基表３０の更新中に作成されたものであるため、更新データが必ずしも反映されたものではないが、回復開始点５１を起点として更新ログ４０を適用することにより、更新データを全て反映させることが可能になっている。本実施の形態では、バックアップデータの一例として、また、バックアップデータに関連付けてチェックポイントを記憶する記憶部の一例として、バックアップファイル５０を設けている。

複製生成機能６０は、複製したい基表３０と静止点とをユーザが指定することによって機能する。具体的には、複製生成機能６０は、基表３０のバックアップファイル５０を読み出し、対象表７０にリストアする。また、バックアップファイル５０に付随する回復開始点５１を読み、それを開始点として更新ログ４０を読み出す。そして、更新ログ４０から指定された基表３０のログを読み、対象表７０に対しそのログを適用する。その際、更新ログ４０内のログ位置情報及び更新位置情報が用いられる。基表３０のバックアップファイル５０をリストアした対象表７０は、基表３０と物理的に同じ構造を持っているので、これらの情報の活用が可能になっている。このようなログの適用に当たっては、ログに対応するコミット情報のタイムスタンプと静止点とを比較する。例えば、静止点でまだコミットが行われていないトランザクションについては、更新データを反映させない。或いは、一旦静止点まで更新データを反映させた後にロールバックを行う。その結果、静止点において確定している更新データのみが反映され、静止点における厳密な基表３０の内容が対象表７０上に作成される。尚、複製生成機能６０は、１つの静止点を指定し、複数の基表３０を一括して処理することも可能である。尚、図では、複製生成機能６０を、ＤＢＭＳ２０から独立した機能として示したが、ＤＢＭＳ２０が有する障害回復機能を拡張した機能であってもよい。本実施の形態では、新たなデータベースを生成する生成部の一例として、また、バックアップデータに関連付けて記憶されたチェックポイントを回復開始点に決定する決定部の一例として、複製生成機能６０を設けている。

対象表７０は、静止点における基表３０の内容が格納される別表である。ここで、対象表７０は、表の属性が基表３０と完全に同じであるものとする。具体的には、列名、各列のデータタイプや長さ、列の並び順、表の容量指定が同一であるものとする。但し、索引に関しては同一でなくても問題はない。尚、ここでは単に「対象表７０」と称するが、これを、対象表７０を記憶する記憶手段として捉えてもよい。

次に、複製生成機能６０による基表３０の複製動作の概要を説明する。
図２は、複製生成機能６０の動作の概要を模式的に示した図である。
（ａ）は、図１に示したように１つの基表３０を複製して１つの対象表７０を生成する場合の図である。
この場合は、例えば、「RECOVER FROM TABLE1 TO TABLEX RESTORE ＜T1ファイル名＞ QUIESCEPOINT XXXXX」といった障害回復コマンドを拡張したコマンドにより、動作が開始する。即ち、まず、対象表７０に対し、基表３０のバックアップファイル５０をリストアする。リストア終了後、更新ログ４０から基表３０のログを読み出し、対象表７０に当て込むことにより、「QUIESCEPOINT XXXXX」で指定された静止点まで対象表７０を復元する。この場合、静止点までにコミットされたトランザクションによる更新データは反映されるが、静止点を跨ったトランザクションや、静止点以降に実行されたトランザクションの更新データは反映されず、静止点における基表３０の内容を持つ対象表７０が作成される。

（ｂ）は、図１には示していないが、複数の基表３０を複製して複数の対象表７０を生成する場合の図である。
この場合は、例えば、「RECOVER FROM （TABLE1,TABLE2,TABLE3) TO (TABLEX,TABLEY,TABLEZ) RESTORE ＜T1ファイル名＞, ＜T2ファイル名＞, ＜T3ファイル名＞ QUIESCEPOINT XXXXX」といった障害回復コマンドを拡張したコマンドにより、動作が開始する。即ち、まず、対象表７０ａ，７０ｂ，７０ｃに対し、基表３０ａのバックアップファイル５０ａ、基表３０ｂのバックアップファイル５０ｂ、基表３０ｃのバックアップファイル５０ｃを並列にリストアする。リストア終了後、更新ログ４０から基表３０ａ，３０ｂ，３０ｃのログを読み出し、対象表７０ａ，７０ｂ，７０ｃに当て込むことにより、「QUIESCEPOINT XXXXX」で指定された静止点まで対象表７０を復元する。この場合、バックアップファイル５０のリストア作業を並列に行い、かつ、更新ログ４０を一度読み出すだけで当て込みも行えるので、同じ静止点における複数の対象表７０の作成にかかる時間を短縮することが可能である。

尚、上述のように、基表３０のバックアップファイル５０と更新ログ４０とを使用して対象表７０を作成するためには、障害回復コマンドの機能拡張が必要となる。しかしながら、静止点を指定してバックアップファイル５０と更新ログ４０とによって基表３０のデータを回復する技術は既に確立されているため、これを基表３０とは別の対象表７０に対して行うという機能拡張のみで、実現可能である。

次に、本実施の形態における複製生成機能６０の動作について、具体例を用いて説明する。
図３は、基表３０を更新するトランザクション、基表３０のバックアップ、回復開始点、静止点を時間軸上に示した図である。
図示するように、回復開始点ＲＢＴ１の後、トランザクション１〜４が実行され、その後、トランザクション５が、静止点Ｑｔ１に跨って実行されている。また、バックアップは、トランザクション２の実行中に開始され、トランザクション３の実行中に終了している。尚、回復開始点ＲＢＴ１は、例えば、システムチェックポイントであり、ＤＢＭＳ２０内のシステム内情報及びバックアップファイル５０内に保持されている。

図４は、図３の例において記録される更新ログ４０の具体例を示した図である。図において、更新ログ４０は、時刻、トランザクション、基表、レコードＩＤ、更新内容を並べたものになっている。このうち、レコードＩＤは、基表３０内でのレコードの位置を表す情報であり、Ｒｘで表している。そして、以下では、レコードＩＤがＲｘのレコードを「レコードＲｘ」と表記するものとする。また、更新内容において、矢印の左側は更新前の値を示し、矢印の右側は更新後の値を示している。尚、更新ログ４０内には複数の基表３０に対する更新データが含まれている。つまり、基表３０ａ以外に、基表３０ｂ，３０ｃに対する更新データも含まれている。
ここで、更新ログ４０について簡単に説明すると、トランザクション１は、時刻ｔ１，ｔ２，ｔ４で基表３０を更新し、時刻ｔ５でコミットしている。トランザクション２は、時刻ｔ３，ｔ６で基表３０を更新し、時刻ｔ７でコミットしている。トランザクション３は、時刻ｔ８，ｔ９で基表３０を更新し、時刻ｔ１０でコミットしている。トランザクション４は、時刻ｔ１１で基表３０を更新し、時刻ｔ１３でコミットしている。トランザクション５は、時刻ｔ１２，ｔ１４で基表３０を更新し、時刻ｔ１５でコミットしている。

図５は、図４の更新ログ４０に示したような更新が行われた場合の各時点における基表３０ａの状態を示した図である。
（ａ）は、時刻ｔ１よりも前の時刻における基表３０ａの内容である。レコードＲ１，Ｒ２，Ｒ３，Ｒ４，Ｒ５，Ｒ６の値は、それぞれ、「１００」、「２００」、「３００」、「４００」、「５００」、「６００」となっている。
（ｂ）は、時刻ｔ５以降で時刻ｔ６よりも前の時刻における基表３０ａの内容である。図４を参照すると、時刻ｔ１でレコードＲ３の値が「３００」から「３５０」に更新され、時刻ｔ４でレコードＲ５の値が「５００」から「４５０」に更新されているので、レコードＲ１，Ｒ２，Ｒ３，Ｒ４，Ｒ５，Ｒ６の値は、それぞれ、「１００」、「２００」、「３５０」、「４００」、「４５０」、「６００」となっている。

（ｃ）は、時刻ｔ８以降で時刻ｔ９よりも前の時刻における基表３０ａの内容である。図４を参照すると、時刻ｔ６でレコードＲ６の値が「６００」から「６５０」に更新され、時刻ｔ８でレコードＲ２の値が「２００」から「２５０」に更新されているので、レコードＲ１，Ｒ２，Ｒ３，Ｒ４，Ｒ５，Ｒ６の値は、それぞれ、「１００」、「２５０」、「３５０」、「４００」、「４５０」、「６５０」となっている。
（ｄ）は、時刻ｔ１５以降の時刻における基表３０ａの内容である。図４を参照すると、時刻ｔ１１でレコードＲ３の値が「３５０」から「２００」に更新され、時刻ｔ１２でレコードＲ６の値が「６５０」から「７００」に更新され、時刻ｔ１４でレコードＲ２の値が「２５０」から「３００」に更新さているので、レコードＲ１，Ｒ２，Ｒ３，Ｒ４，Ｒ５，Ｒ６の値は、それぞれ、「１００」、「３００」、「２００」、「４００」、「４５０」、「７００」となっている。

そして、（ｅ）は、時刻Ｂｔ１から時刻Ｂｔ２の間にバックアップされた基表３０ａの内容、つまり、バックアップファイル５０の内容である。ここでは、各レコードのバックアップ時刻と更新時刻との先後により、（ｂ）から（ｃ）にかけて破線で示したように、レコードＲ１〜Ｒ５は（ｂ）の状態で、レコードＲ６は（ｃ）の状態でバックアップファイル５０に含まれている。即ち、例えばレコードＲ２の値として、（ｃ）に示した更新後の値である「２５０」はバックアップファイル５０に反映されず、（ｂ）に示した更新前の値である「２００」がバックアップファイル５０に反映されている。このように、このバックアップファイル５０は、オンラインバックアップで作成されるため、必ずしも、整合性のある状態でデータがバックアップされたものではない。

次に、図４の更新ログ４０と、図５（ｅ）のバックアップファイル５０とに基づいて、対象表７０に、静止点Ｑｔ１における基表３０ａの内容を復元する場合の動作について具体的に説明する。
まず、複製生成機能６０は、基表３０ａのバックアップファイル５０を対象表７０にリストアする。
また、回復開始点はＲＢＴ１、静止点はＱｔ１（ｔ１３＜Ｑｔ１＜ｔ１４）なので、複製生成機能６０は、更新ログ４０のうち、ＲＢＴ１よりも後でＱｔ１以前の時刻における基表３０ａに対するログを用いる。
図６は、複製生成機能６０によって用いられるログを示している。
ここでは、図４の更新ログ４０の時刻ｔ１〜ｔ１５のログレコードのうち、時刻ｔ１４，ｔ１５のログレコードは、Ｑｔ１より後の時刻のログレコードなので除外されている。また、時刻ｔ２，ｔ３，ｔ９のログレコードは、基表３０ａに対するログレコードではないので除外されている。

そして、このようなログが、対象表７０に対して当て込まれる。
図７は、ログを当て込む際の対象表７０の内容の遷移を示した図である。
（ａ）は、ログを当て込む前の対象表７０の内容である。破線＃１内の楕円で囲んだレコードＲ３，Ｒ５，Ｒ６には、図６の（１）、（２）、（３）の更新が既に反映されている。
（ｂ），（ｃ），（ｄ）は、ログを当て込んだときの対象表７０の内容である。破線＃２内の楕円で囲んだレコードＲ２には、図６の（４）の更新が反映され、その値は（ｂ）の「２００」から（ｃ）の「２５０」へと書き換えられている。また、同様に、破線＃２内の楕円で囲んだレコードＲ３には、図６の（５）の更新が反映され、その値は（ｃ）の「３５０」から（ｄ）の「２００」へと書き換えられている。一方、図６の（６）の更新に対応するコミット情報は図６に含まれていないので、破線＃３内の楕円で囲んだレコードＲ６には、図６の（６）の更新は反映されていない。

次に、このような動作を実現する複製生成機能６０について詳細に説明する。
図８は、複製生成機能６０の機能構成例を示したブロック図である。
図示するように、複製生成機能６０は、バックアップファイル取得部６１と、対象表生成部６２と、更新ログ取得部６３と、静止点受付部６４と、更新判定部６５とを備えている。

バックアップファイル取得部６１は、ＤＢＭＳ２０が出力したバックアップファイル５０のうち指定された基表３０のバックアップファイル５０を取得する。また、このとき、バックアップファイル５０に付随する回復開始点５１も取得する。本実施の形態では、バックアップデータを取得するバックアップデータ取得部の一例として、また、バックアップデータに関連付けて記憶された回復開始点を取得する回復開始点取得部の一例として、バックアップファイル取得部６１を設けている。
対象表生成部６２は、バックアップファイル取得部６１が取得したバックアップファイル５０を対象表７０にリストアし、更新判定部６５により対象表７０に反映すべきと判定されたログレコードを対象表７０に当て込むことにより、ある静止点における基表３０の複製を格納した対象表７０を生成する。本実施の形態では、新たなデータベースを生成する生成部の一例として、対象表生成部６２を設けている。

更新ログ取得部６３は、ＤＢＭＳ２０が出力した更新ログ４０を取得する。本実施の形態では、更新ログを取得する更新ログ取得部の一例として、更新ログ取得部６３を設けている。
静止点受付部６４は、例えばユーザが指定した静止点の情報を受け付ける。本実施の形態では、特定の時点の指定を受け付ける受付部の一例として、静止点受付部６４を設けている。
更新判定部６５は、更新ログ取得部６３が取得した更新ログ４０内の各ログレコードについて、対象表７０に反映すべきかどうかを判定する。

図９は、複製生成機能６０の動作例を示したフローチャートである。
複製生成機能６０では、まず、静止点受付部６４が、例えばユーザにより静止点の指定を受け付ける（ステップ６０１）。
次に、バックアップファイル取得部６１が、ＤＢＭＳ２０が出力したバックアップファイル５０のうち、指定された基表３０のバックアップファイル５０及びこれに付随する回復開始点５１を取得する（ステップ６０２）。そして、対象表生成部６２が、このバックアップファイル５０を対象表７０にリストアする（ステップ６０３）。
また、更新ログ取得部６３が、ＤＢＭＳ２０が出力した更新ログ４０を取得する（ステップ６０４）。

このようにバックアップファイル５０が対象表７０にリストアされ、更新ログ４０が取得されると、更新判定部６５が、更新ログ４０内の各ログレコードを対象表７０の更新に用いるかどうかを判定し、更新に用いると判定されたログレコードで対象表７０を更新する。
即ち、まず、更新判定部６５は、回復開始点５１のログレコードを見つける（ステップ６０５）。ここで、回復開始点５１としては、ステップ６０２でバックアップファイル取得部６１がバックアップファイル５０と共に取得した回復開始点５１を用いればよい。そして、回復開始点で実行中だったトランザクションに関する情報（以下、「トランザクション情報」という）をログレコードから読み取り、仕掛かり中トランザクション情報として、メモリに記憶する（ステップ６０６）。

次に、更新判定部６５は、取得された更新ログ４０から１つのログレコードを読み出す（ステップ６０７）。そして、そのログレコードにおける更新が静止点よりも後に行われたものかどうかを判定する（ステップ６０８）。具体的には、そのログレコードのタイムスタンプが静止点のタイムスタンプより新しいかどうかを判定する。ここで、静止点としては、ステップ６０１で静止点受付部６４が受け付けた静止点を用いればよい。
ここで、そのログレコードにおける更新が静止点よりも後に行われたものではない、つまり、そのログレコードのタイムスタンプが静止点のタイムスタンプより新しくないと判定されれば、更新判定部６５は、そのログレコードが基表３０の更新に関するログレコードであるかどうかを判定する（ステップ６０９）。
その結果、基表３０の更新に関するログレコードでないと判定されれば、ステップ６０７へ戻る。
一方、基表３０の更新に関するログレコードであると判定されれば、そのログレコードがトランザクション開始情報（以下、単に「開始情報」という）を含むかどうかを判定する（ステップ６１０）。そして、そのログレコードが開始情報を含むと判定されれば、新しいトランザクション情報を仕掛かり中トランザクション情報としてメモリに記憶して（ステップ６１１）、ステップ６０７へ戻る。また、そのログレコードが開始情報を含まないと判定されれば、ステップ６１２へ進む。

また、更新判定部６５は、そのログレコードがコミット情報を含むかどうかを判定する（ステップ６１２）。そして、そのログレコードがコミット情報を含むと判定されれば、コミット情報に対応する仕掛かり中トランザクション情報をメモリから消去して（ステップ６１３）、ステップ６０７へ戻る。また、そのログレコードがコミット情報を含まないと判定されれば、対象表７０の更新処理に移る。

即ち、このようにステップ６０８で静止点よりも後における更新に関するものではないと判定され、ステップ６０９で基表３０の更新に関すると判定され、ステップ６１０で開始情報を含まないと判定され、ステップ６１２でコミット情報を含まないと判定されたログレコードは、対象表７０に反映すべき更新データを保持するログレコードである。そこで、更新判定部６５は、この基表３０のログレコードを対象表７０のログレコードに変換し（ステップ６１４）、変換後のログレコードで対象表７０を更新する（ステップ６１５）。そして、ステップ６０７へ戻り、以降、ステップ６０７で読み込んだログレコードに対して、ステップ６０８でログレコードにおける更新が静止点よりも後に行われたものとなるまで同様の処理を繰り返す。そして、ステップ６０８でログレコードにおける更新が静止点よりも後に行われたものである、つまり、ログレコードのタイムスタンプが静止点のタイムスタンプより新しいと判定されれば、メモリ内に残った仕掛かり中トランザクション情報のトランザクションに属する更新済みデータをロールバックさせる（ステップ６１６）。

ここで、図９のフローチャートにおける複製生成機能６０の動作例を、ステップ６０７で図６のログレコードを読み込んで図７のような更新を行う場合を例にとって説明する。但し、時刻ｔ５，ｔ７，ｔ１０，ｔ１３のログレコードを読み込んだ場合については、これらがコミット情報であり、ステップ６１２で「Ｙｅｓ」となって、更新に用いるログレコードと判定されないので、説明を省略する。

まず、図６のログレコード（１）を読み込んだ場合について説明する。尚、このログレコード（１）については、ステップ６０７で読み込まれたことによりＲＢＴ１＜ｔ１であることが確認されたことを前提とする。そして、ステップ６０８でｔ１≦Ｑｔ１であることが確認され、ステップ６０９で基表３０ａのログレコードであることが確認され、ステップ６１０で開始情報を含まないことが確認され、ステップ６１２でコミット情報を含まないことが確認されるので、複製生成機能６０は、このログレコード（１）に従い、対象表７０内のレコードＲ３の値を更新しようとする。しかしながら、レコードＲ３は更新済みなので実際には更新は行われない。

次に、図６のログレコード（２）を読み込んだ場合について説明する。尚、このログレコード（２）については、ステップ６０７で読み込まれたことによりＲＢＴ１＜ｔ４であることが確認されたことを前提とする。そして、ステップ６０８でｔ４≦Ｑｔ１であることが確認され、ステップ６０９で基表３０ａのログレコードであることが確認され、ステップ６１０で開始情報を含まないことが確認され、ステップ６１２でコミット情報を含まないことが確認されるので、複製生成機能６０は、このログレコード（２）に従い、対象表７０内のレコードＲ５の値を更新しようとする。しかしながら、レコードＲ５は更新済みなので実際には更新は行われない。

次いで、図６のログレコード（３）を読み込んだ場合について説明する。尚、このログレコード（３）については、ステップ６０７で読み込まれたことによりＲＢＴ１＜ｔ６であることが確認されたことを前提とする。そして、ステップ６０８でｔ６≦Ｑｔ１であることが確認され、ステップ６０９で基表３０ａのログレコードであることが確認され、ステップ６１０で開始情報を含まないことが確認され、ステップ６１２でコミット情報を含まないことが確認されるので、複製生成機能６０は、このログレコード（２）に従い、対象表７０内のレコードＲ６の値を更新しようとする。しかしながら、レコードＲ６は更新済みなので実際には更新は行われない。
以上は、図７の破線＃１内の楕円で囲んだレコードに対する処理である。

また、図６のログレコード（４）を読み込んだ場合について説明する。尚、このログレコード（４）については、ステップ６０７で読み込まれたことによりＲＢＴ１＜ｔ８であることが確認されたことを前提とする。そして、ステップ６０８でｔ８≦Ｑｔ１であることが確認され、ステップ６０９で基表３０ａのログレコードであることが確認され、ステップ６１０でコミット情報ではないことが確認され、ステップ６１２でコミット情報を含まないことが確認されるので、複製生成機能６０は、このログレコード（４）に従い、対象表７０内のレコードＲ２の値を「２００」から「２５０」に変更する。

次に、図６のログレコード（５）を読み込んだ場合について説明する。尚、このログレコード（５）については、ステップ６０７で読み込まれたことによりＲＢＴ１＜ｔ１１であることが確認されたことを前提とする。そして、ステップ６０８でｔ１１≦Ｑｔ１であることが確認され、ステップ６０９で基表３０ａのログレコードであることが確認され、ステップ６１０でコミット情報ではないことが確認され、ステップ６１２でコミット情報を含まないことが確認されるので、複製生成機能６０は、このログレコード（５）に従い、対象表７０内のレコードＲ３の値を「３５０」から「２００」に変更する。
以上は、図７の破線＃２内の楕円で囲んだレコードに対する処理である。

一方、図６のログレコード（６）を読み込んだ場合について説明する。尚、このログレコード（６）については、ステップ６０７で読み込まれたことによりＲＢＴ１＜ｔ１２であることが確認されたことを前提とする。そして、ステップ６０８でｔ１２≦Ｑｔ１であることが確認され、ステップ６０９で基表３０ａのログレコードであることが確認され、ステップ６１０でコミット情報ではないことが確認され、ステップ６１２でコミット情報を含まないことが確認されるので、複製生成機能６０は、このログレコード（６）に従い、対象表７０内のレコードＲ６の値を「６５０」から「７００」に変更する。しかしながら、ステップ６０８で「Ｙｅｓ」となった時点で、このログレコード（６）を出力したトランザクションのトランザクション情報がメモリ内に存在するので、ステップ６１６でこの変更に対してロールバックが行われ、レコードＲ６の値は「６５０」に戻される。
以上は、図７の破線＃３内の楕円で囲んだレコードに対する処理である。

以上、本発明の実施の形態について説明した。
このように、本実施の形態では、ある静止点におけるデータベースの複製を、基表３０のオンラインバックアップと更新ログ４０とから、別表である対象表７０に対して作成するようにした。これにより、流動的な（常に更新によって変化する）データベースの静止点における内容を容易に別表に作成可能となる。
また、本実施の形態では、対象表７０の作成が基表３０の更新業務に一切影響しないため、基表３０を連続的に稼動させることができる。
更に、本実施の形態では、例えば数百ＧＢの大きな基表３０であっても、その複製に要する時間を短くし、その際に必要なＣＰＵ使用量、ディスク容量を小さくすることが可能になる。
更にまた、本実施の形態では、同じ静止点における複数の基表３０の内容を持つ複製の作成も可能である。

尚、本実施の形態を製品に実装するために、以下の製品改善を行えばよい。
まず、ある基表３０のバックアップファイル５０と更新ログ４０とを基表３０とは別の表の復元のために使用できるようにするような改善である。例えば、ＤＢＭＳ２０が別の表に使用できないように制限されていれば、その制限を外す必要がある。そして、基表３０の更新ログ４０をその情報を保持したまま対象表７０に当てるように変換する機能を追加する必要がある。
また、製品は以下の機能を備えることが望ましい。
第一に、運用を容易に行えるよう、静止点をタイムスタンプによって指定できるようにする機能である。
第二に、基表３０と対象表７０の属性が同じであることをチェックする機能である。

最後に、本実施の形態を適用するのに好適なコンピュータのハードウェア構成について説明する。図１０は、このようなコンピュータのハードウェア構成の一例を示した図である。図示するように、コンピュータは、演算手段であるＣＰＵ（Central Processing Unit）９０ａと、Ｍ／Ｂ（マザーボード）チップセット９０ｂを介してＣＰＵ９０ａに接続されたメインメモリ９０ｃと、同じくＭ／Ｂチップセット９０ｂを介してＣＰＵ９０ａに接続された表示機構９０ｄとを備える。また、Ｍ／Ｂチップセット９０ｂには、ブリッジ回路９０ｅを介して、ネットワークインターフェイス９０ｆと、磁気ディスク装置（ＨＤＤ）９０ｇと、音声機構９０ｈと、キーボード／マウス９０ｉと、フレキシブルディスクドライブ９０ｊとが接続されている。

尚、図１０において、各構成要素は、バスを介して接続される。例えば、ＣＰＵ９０ａとＭ／Ｂチップセット９０ｂの間や、Ｍ／Ｂチップセット９０ｂとメインメモリ９０ｃの間は、ＣＰＵバスを介して接続される。また、Ｍ／Ｂチップセット９０ｂと表示機構９０ｄとの間は、ＡＧＰ（Accelerated Graphics Port）を介して接続されてもよいが、表示機構９０ｄがＰＣＩ Ｅｘｐｒｅｓｓ対応のビデオカードを含む場合、Ｍ／Ｂチップセット９０ｂとこのビデオカードの間は、ＰＣＩ Ｅｘｐｒｅｓｓ（ＰＣＩｅ）バスを介して接続される。また、ブリッジ回路９０ｅと接続する場合、ネットワークインターフェイス９０ｆについては、例えば、ＰＣＩ Ｅｘｐｒｅｓｓを用いることができる。また、磁気ディスク装置９０ｇについては、例えば、シリアルＡＴＡ（AT Attachment）、パラレル転送のＡＴＡ、ＰＣＩ（Peripheral Components Interconnect）を用いることができる。更に、キーボード／マウス９０ｉ、及び、フレキシブルディスクドライブ９０ｊについては、ＵＳＢ（Universal Serial Bus）を用いることができる。

ここで、本発明は、全てハードウェアで実現してもよいし、全てソフトウェアで実現してもよい。また、ハードウェア及びソフトウェアの両方により実現することも可能である。また、本発明は、コンピュータ、データ処理システム、コンピュータプログラムとして実現することができる。このコンピュータプログラムは、コンピュータにより読取り可能な媒体に記憶され、提供され得る。ここで、媒体としては、電子的、磁気的、光学的、電磁的、赤外線又は半導体システム（装置又は機器）、或いは、伝搬媒体が考えられる。また、コンピュータにより読取り可能な媒体としては、半導体、ソリッドステート記憶装置、磁気テープ、取り外し可能なコンピュータディスケット、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、リジッド磁気ディスク、及び光ディスクが例示される。現時点における光ディスクの例には、コンパクトディスク−リードオンリーメモリ（ＣＤ−ＲＯＭ）、コンパクトディスク−リード／ライト（ＣＤ−Ｒ／Ｗ）及びＤＶＤが含まれる。

以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態には限定されない。本発明の精神及び範囲から逸脱することなく様々に変更したり代替態様を採用したりすることが可能なことは、当業者に明らかである。

１０…アプリケーションプログラム、２０…ＤＢＭＳ、３０…基表、４０…更新ログ、５０…バックアップファイル、６０…複製生成機能、７０…対象表

Claims (10)

1. 特定の時点におけるデータベースの複製を生成する装置であって、
   前記データベースの回復に用いるためにＤＢＭＳ（DataBase Management System）が前記特定の時点よりも前に当該データベースの更新を停止することなく出力した当該データベースのバックアップデータを取得するバックアップデータ取得部と、
   前記データベースの回復に用いるために前記ＤＢＭＳが前記バックアップデータを出力した時間帯よりも前の回復開始点から前記特定の時点までの間に記録した当該データベースの更新ログを取得する更新ログ取得部と、
   前記バックアップデータ取得部により取得された前記バックアップデータと、前記更新ログ取得部により取得された前記更新ログとに基づいて、前記特定の時点における前記データベースの内容を保持する新たなデータベースを前記複製として生成する生成部と
   を含む、装置。
2. 前記生成部は、前記バックアップデータ取得部により取得された前記バックアップデータを、前記更新ログ取得部により取得された前記更新ログのうち前記特定の時点よりも前にコミットされたトランザクションに関する部分で更新することにより、前記新たなデータベースを生成する、請求項１の装置。
3. 前記生成部は、前記バックアップデータ取得部により取得された前記バックアップデータを、前記更新ログ取得部により取得された前記更新ログのうち当該バックアップデータに反映されていない更新に関する部分で更新することにより、前記新たなデータベースを生成する、請求項１の装置。
4. ユーザによる前記特定の時点の指定を受け付ける受付部を更に含む、請求項１の装置。
5. 前記バックアップデータ取得部により取得された前記バックアップデータに関連付けて記憶された前記回復開始点を取得する回復開始点取得部を更に含む、請求項１の装置。
6. 特定の時点におけるデータベースの複製を生成する装置であって、
   前記データベースの回復に用いるために当該データベースの更新を停止することなく当該データベースのバックアップデータを出力する出力機能と、前記データベースの回復に用いるために当該データベースの更新ログを記録する記録機能とを少なくとも有する、ＤＢＭＳ（DataBase Management System）と、
   前記特定の時点よりも前に前記ＤＢＭＳの前記出力機能により出力された前記バックアップデータと、前記バックアップデータを出力した時間帯よりも前の回復開始点から前記特定の時点までの間に前記ＤＢＭＳの前記記録機能により記録された前記更新ログとに基づいて、前記特定の時点における前記データベースの内容を保持する新たなデータベースを前記複製として生成する生成部と
   を含む、装置。
7. 前記ＤＢＭＳの前記出力機能により出力された前記バックアップデータに関連付けて、当該バックアップデータが出力された時間帯よりも前のチェックポイントを記憶する記憶部と、
   前記記憶部に前記バックアップデータに関連付けて記憶された前記チェックポイントを前記回復開始点に決定する決定部と
   を更に含む、請求項６の装置。
8. 特定の時点におけるデータベースの複製を生成する装置であって、
   前記データベースの回復に用いるために当該データベースの更新を停止することなく当該データベースのバックアップデータを出力する出力機能と、前記データベースの回復に用いるために当該データベースの更新ログを記録する記録機能とを少なくとも有する、ＤＢＭＳ（DataBase Management System）と、
   前記特定の時点よりも前に前記ＤＢＭＳの前記出力機能により出力された前記バックアップデータを取得するバックアップデータ取得部と、
   前記バックアップデータを出力した時間帯よりも前の回復開始点から前記特定の時点までの間に前記ＤＢＭＳの前記記録機能により記録された前記更新ログを取得する更新ログ取得部と、
   前記バックアップデータ取得部により取得された前記バックアップデータを、前記更新ログ取得部により取得された前記更新ログのうち、前記特定の時点よりも前にコミットされたトランザクションに関し、かつ、当該バックアップデータに反映されていない更新に関する部分で更新することにより、前記特定の時点における前記データベースの内容を保持する新たなデータベースを前記複製として生成する生成部と
   を含む、装置。
9. 特定の時点におけるデータベースの複製を生成する方法であって、
   前記データベースの回復に用いるためにＤＢＭＳ（DataBase Management System）が前記特定の時点よりも前に当該データベースの更新を停止することなく出力した当該データベースのバックアップデータを取得するステップと、
   前記データベースの回復に用いるために前記ＤＢＭＳが前記バックアップデータを出力した時間帯よりも前の回復開始点から前記特定の時点までの間に記録した当該データベースの更新ログを取得するステップと、
   前記バックアップデータと、前記更新ログとに基づいて、前記特定の時点における前記データベースの内容を保持する新たなデータベースを前記複製として生成するステップと
   を含む、方法。
10. 特定の時点におけるデータベースの複製を生成する装置としてコンピュータを機能させるプログラムであって、
    前記コンピュータを、
    前記データベースの回復に用いるためにＤＢＭＳ（DataBase Management System）が前記特定の時点よりも前に当該データベースの更新を停止することなく出力した当該データベースのバックアップデータを取得するバックアップデータ取得部と、
    前記データベースの回復に用いるために前記ＤＢＭＳが前記バックアップデータを出力した時間帯よりも前の回復開始点から前記特定の時点までの間に記録した当該データベースの更新ログを取得する更新ログ取得部と、
    前記バックアップデータ取得部により取得された前記バックアップデータと、前記更新ログ取得部により取得された前記更新ログとに基づいて、前記特定の時点における前記データベースの内容を保持する新たなデータベースを前記複製として生成する生成部と
    して機能させる、プログラム。

Images