JP4139642B2 - データベース管理方法およびシステム - Google Patents

データベース管理方法およびシステム Download PDF

Info

Publication number
JP4139642B2
JP4139642B2 JP2002219049A JP2002219049A JP4139642B2 JP 4139642 B2 JP4139642 B2 JP 4139642B2 JP 2002219049 A JP2002219049 A JP 2002219049A JP 2002219049 A JP2002219049 A JP 2002219049A JP 4139642 B2 JP4139642 B2 JP 4139642B2
Authority
JP
Japan
Prior art keywords
log
processing
database
transaction
storage device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2002219049A
Other languages
English (en)
Other versions
JP2004062473A (ja
Inventor
尚志 鈴木
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Software Engineering Co Ltd
Hitachi Ltd
Original Assignee
Hitachi Software Engineering Co Ltd
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Software Engineering Co Ltd, Hitachi Ltd filed Critical Hitachi Software Engineering Co Ltd
Priority to JP2002219049A priority Critical patent/JP4139642B2/ja
Publication of JP2004062473A publication Critical patent/JP2004062473A/ja
Application granted granted Critical
Publication of JP4139642B2 publication Critical patent/JP4139642B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Landscapes

  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

【0001】
【発明の属する技術分野】
本発明は、複数のトランザクションからアクセスされるデータを記憶するデータベースを管理するデータベース管理技術に関する。
【0002】
【従来の技術】
多重処理環境におけるデータベース管理システムでは、一定間隔おきにシンクポイントあるいはチェックポイントという同期点を設けている。これは、障害が発生しデータベースの再開始回復処理を実行しなければならない場合、障害が発生した時点の直前のシンクポイントの状態にデータベースを復元することを保証し、そこから処理の再開を図ることによってデータベースの再開始回復処理を行う。シンクポイントは、更新を含むトランザクション処理の進行とは非同期に取得することが出来る。
【0003】
データベース管理システム、特にリレーショナル・データベース管理システムは、データベース、スキーマ、表、行といったように、論理的な階層をもつ資源で構成される。物理的に表を格納するための不揮発性記憶装置である磁気ディスクなどの場合、行を物理的に固定長のブロックあるいはページと言う単位で格納する。トランザクション処理において行われるデータベースのアクセスは、このページを単位として主記憶装置上に確保されたバッファプールを介して行われる。あるトランザクションにおいて、必要なページがバッファプールに読み込まれ、バッファプール内で検索、更新処理が行われる。バッファプールに読み込まれたページは、出来るだけ長くバッファプール上に存在するように管理されることによって、磁気ディスクなどの外部記憶装置との入出力処理オーバヘッドを削減している。あるトランザクションにおいて行われたデータベースの更新処理については、その更新履歴情報をログとして取得する。ログは外部記憶装置のような不揮発性の記憶装置に永久的に記録される。ログレコードはプロセッサ内の主記憶装置上における揮発性のログバッファにまず書きこまれ、トランザクションが確定される時に外部記憶装置上のログファイルに移される。この場合、トランザクションにおいて行われたバッファプール上のページの更新は、いずれ外部記憶装置上のデータベースに反映されなければならない。
【0004】
バッファプール上の更新頁を外部記憶装置に反映する方法には、トランザクション確定時とは遅延させてバッファプールより更新されたページを外部記憶装置上のデータベースに反映することによって、同一ページへの複数のトランザクションの更新をまとめて外部記憶装置への書き込みを行うことで、トランザクション確定時の外部記憶装置への書き込みオーバヘッドを削減するものがある。
【0005】
トランザクション確定時よりも遅延させて外部記憶装置への書き込みを行う場合、外部記憶装置に更新されたページが書き込まれる前に障害などによりデータベース管理システムが終了してしまうとそのページの情報は失われる。この場合、システムの再開始が行われ、システムが終了した時点までに行われたトランザクションの回復を保証する必要がある。トランザクションが確定される前に障害が生じた場合は、そのトランザクションで行われた全ての更新を確実に元に戻す。また、トランザクション確定後に障害が生じた場合は、そのトランザクションにて行われた更新を全て保証させなければならない。
【0006】
システムの再開始時には、前回のシンクポイントより行われた全てのトランザクションを外部記憶装置上に保存されたログファイルからログレコードを読み出して回復する。ログレコードによるトランザクション回復時には、確定されたトランザクションであっても実際に更新したページについてはバッファプール上から外部記憶装置へ反映されていないことがある。その場合は、外部記憶装置上のデータベースから回復対象のページを再度バッファプール上に読み込み、ログレコードを基に更新処理を再実行(REDO)する。
【0007】
逆に確定されたトランザクションおよび確定されていないトランザクションで行われた更新がすでにバッファプールから外部記憶装置へ反映されてしまっている場合もある。これに対応する対策としては、ページ中に更新が発生した時のログのログシーケンス番号(LSN)を持っておくことによって解決される。ページに対してあるトランザクションによって更新が行われると、その時のログを取得すると共にそのログレコードのLSNをあわせてページ内に書き込んでおく。そうすると、バッファプールから更新されたページが外部記憶装置に書き込まれることによって、そのトランザクションで行った更新がどのログに対応する更新まで外部記憶装置に反映されているかがわかる。これにより、システムの再開始時に回復対象の更新ページ全てを回復する必要が無くなる。
【0008】
更新対象ページをバッファプールに読み込んだ場合、読み込んだページのLSNとログレコードのLSNを比較し、ページのLSNの方がログレコードのLSNより大きい時は、そのログレコードの記憶された更新情報はすでに反映されていることになる。ということは、ページのLSNの方がログレコードのLSNより小さい時だけ、ログを使用してREDOを行えばよいということになる。データベース管理システムでは、こうした再開始時の処理時間を出来る限り短時間で行うことが望ましい。そのためには、再開始処理時のREDO処理を極力削減することが望まれる。それには、通常バッファプール上で更新されたページを適切な時期にシステムプロセスを使用して、バックグラウンドで外部記憶装置上のデータベースに書き込むことであり、最低限必要なログレコードのみを読み込めるように読み込み開始位置を設定することである。
【0009】
ここで、再開始処理において直前のシンクポイントから回復処理を行う場合に前提とされるのは、直前のシンクポイント時点のデータベースの状態からログを用いて回復が行えることを保証することである。そのために、シンクポイントを取得する処理では、まずログレコードとしてシンクポイント開始ログを取得し、REDO開始ログレコード番号となるログレコード番号として主記憶装置上に記憶することから開始する。この後、ログバッファ上のログレコードを外部記憶装置上のログファイルに書きこむ。
【0010】
ログの書きこみが終了すると、次は実行中かつ確定されていないトランザクションに対してシンクポイント取得処理中であるマークをつけ、バッファプール上の全ての更新されたページを外部記憶装置上のデータベースに書きこむ。これが終わると、停止したトランザクション処理の続行を開始してシンクポイント取得を完了する。最後にREDO開始ログレコード番号を確定するためにマークをつけたトランザクションが全て確定するまで監視を行い、確定後ログバッファ上のログレコードを外部記憶装置上のログファイルに、REDO開始ログレコード番号を外部記憶装置上に書きこむ。
【0011】
これによって、マークしたトランザクションをシステム再開始処理でロールバックする必要が無くなるため、REDO開始ログレコード番号より古いログレコードをデータベース回復処理で使用しなくなる。次のシンクポイントが取得されるまでに障害などによりシステムが終了しても、今取得したシンクポイントのデータベースの状態とREDO開始ログレコード番号より古いログレコードの更新情報が保証されたので、取得したシンクポイントを起点にしてREDO開始ログレコード番号より新しいログレコードを使用して再開始処理を行うことができる。
【0012】
これらの従来技術は、特開平8−87510号公報に開示されているデータベース管理方法に詳細に説明されている。
【0013】
【発明が解決しようとする課題】
上記従来技術では、シンクポイント取得処理時点において確定していないトランザクションが長時間更新処理を実行すると、REDO開始ログレコード番号が確定するまでの間に外部記憶装置上のデータベースに書きこまれていないページとREDOで読み込むログレコードが増加することになるため、再開始処理時間を最小にするための工夫が必要となる。
【0014】
本発明の目的は、再開始処理時間を削減するデータベース管理方法およびシステムを提供することにある。
【0015】
【課題を解決するための手段】
上記目的を達成するために、本発明のデータベース管理方法では、シンクポイント取得処理時点においてマークをつけた確定していないトランザクションが全て確定するまでに長時間が経過した場合、確定していない全てのトランザクションに前記マークがついていることをシンクポイント取得処理中の一定間隔毎に確認し、全てのトランザクションに前記マークがついている場合にのみREDOで読み込むログの先頭ログレコードを主記憶装置上に再度設定し、再び前記バッファの全ての更新したページを書き込むことにより解決する。この場合、マークするトランザクションを増減することがないため、最終的なシンクポイント取得完了のタイミングを変更せずに、REDOで読み込むログレコード量を削減することが出来る。
【0016】
【発明の実施の形態】
本実施例では、シンクポイント取得処理時点において確定していないトランザクションが長時間更新処理を実行すると、シンクポイント取得処理に長時間を要し、バッファプールから長い間外部記憶装置上のデータベースに書き込まれていないページが発生し、REDO開始ログレコード番号より新しいログレコードが増加し、REDOでログファイルを読み込む回数が増えることを防ぐ。特にシンクポイント取得処理中に更新したバッファプールを定期的に外部記憶装置上のデータベースに書き込み、REDO開始ログレコード番号を最適化する。
【0017】
以下、本発明を実施する場合の一形態を図面を参照して具体的に説明する。
【0018】
図2は、本発明の一実施例にかかるコンピュータシステム10の構成を示す。コンピュータシステム10は、CPU12、主記憶装置14、磁気ディスク等の外部記憶装置16及び多数の端末18で構成される。主記憶装置14上には、データベース管理システム20が置かれ、外部記憶装置16上にはデータベース管理システム20が管理するデータベース36及びデータベース更新に関する更新履歴情報であるログファイル37が格納される。
【0019】
データベース管理システム20は、ユーザからのデータベース問い合わせ要求であるSQLを受け取り、構文解析意味解析処理を通してデータベースアクセスの最適なアクセス経路を決定する最適化処理を行ない、決定したアクセス経路に基づいてデータベース処理用の内部処理コードを生成する質問解析処理部21、生成された内部処理コードを基にデータベースアクセスを行うデータベース演算処理部22、外部記憶装置16に格納されたデータベース36からデータを主記憶装置14上に確保したバッファプールとの間でデータの入出力を行うバッファプール管理部23、前記端末18から投入されたトランザクションを管理するトランザクション管理部24、バッファプール34の上で行われたデータの更新をトランザクションとは非同期に外部記憶装置16上のデータベース36に書き込みを行う遅延書き込み処理部25、定期的にデータベースを整合性が取れた状態にすることを保証する処理を行うシンクポイント取得処理部26、トランザクションで行われたデータベースへの更新履歴情報であるログ(以下、ログと略す)を管理し、各ログレコードのログシーケンス番号(以下、LSNと略す)を割り振り、トランザクションの完了時に主記憶装置14上のログバッファ35から外部記憶装置16上のログファイル37に書き込みを行うログ書き込み処理部27、システム再開始時にREDO開始ログレコード番号を取得してログファイル37から主記憶装置14上のログ読み込みバッファ39にログレコードを読み込みを行うログ読み込み処理部28、及びログ読み込みバッファ39のログレコードから主記憶装置14上に確保したバッファプール及びデータベース36へのREDOを行うREDO処理部29で構成される。前記バッファプール管理部23は、主記憶装置14上に確保したバッファプール34をデータベースのデータを蓄積する単位である物理適に固定長のページと対応させて管理するためのバッファプール管理テーブル31、ページ管理テーブル32及びハッシュ管理テーブル33を使用する。
【0020】
図3は、先に述べたトランザクション管理部24が使用するトランザクション管理テーブル44の構造を示す。トランザクション管理テーブル44にはトランザクション実行中であることを示す実行フラグ441、シンクポイント取得開始処理でマークする時に使用するマークフラグ442、トランザクション番号443、トランザクション開始ログのLSN444などで構成する。
【0021】
ここで、本発明に関わるトランザクション処理について図4から図7を用いて説明する。図2における端末18からトランザクションが投入されるとトランザクション管理部24はトランザクション開始処理を行う。トランザクション開始処理の概略処理フローを図4に示す。トランザクションが開始されると、まず、トランザクション管理テーブル44を当該トランザクション用に割り当て、初期化する(ステップ52)。
【0022】
次に、トランザクション開始ログを作成し、トランザクション管理テーブル44上の実行フラグ441をONに設定し、ログ書き込み処理部27にログの出力要求を発行し、主記憶装置14上のログバッファ35に出力し、データベース管理システム内の一貫したLSNを割り振り、LSNを取得する(ステップ54)。取得したLSNを当該トランザクションのトランザクション管理テーブルのトランザクション開始ログとして登録する(ステップ56)。こうして、トランザクション開始処理が完了すると、データベースに対する質問処理が実行される。データベースに対する質問処理のうち、更新処理が行われた場合、更新操作を回復するためのUNDOログを作成し、ログ書き込み処理部27に対し書き込み要求を発行するとともにUNDOログのLSNを取得する(ステップ63)。UNDOログが取得できたら、更新対象行の更新操作を行う(ステップ64)。そして、更新した行に対する再実行による回復のためのREDOログを出力し、REDOログのLSNを取得する(ステップ65)。取得したREDOログのLSNをページ内制御情報42のLSN425に書き込み、更新する(ステップ66)。REDOログのLSNを更新した後、当該ページに対する更新をデータベースに反映するため、バッファプール管理部23に対してページ出力要求を行う(ステップ68)。
【0023】
ただし、当該要求は直ちにデータベース36に書き込まれるのではなく、当該ページを管理するページ管理テーブル32の出力要求フラグ330を出力要求状態に設定するのみとする。出力要求状態に設定することで、当該バッファプールの置換アルゴリズムにしたがって、バッファスチール(他のページを入力するためにデータベースに強制的に書きだす)されるか、遅延書き込み処理部25によって非同期にデータベース36に書き込まれるまで、主記憶装置14上のバッファプール34上に置かれる。次に、トランザクション内で行ったデータベースへのアクセス処理が終わるとトランザクションを有効なものとするために2フェーズに分けてトランザクションを完結させる。
【0024】
まず、図6にトラザンクションのPREPARE処理フェーズについて説明する。まず、トランザクションのPREPAREログをログバッファに書き込む(ステップ72)。次いで、当該PREPAREログをログファイル37に強制出力する(ステップ74)。PREPAREフェーズが終わるとトランザクションを正常に終了させるためにCOMMITフェーズに入る。COMMITフェーズの処理概略フローを図7に示す。トランザクションCOMMITログをログバッファに出力する(ステップ82)。COMMITログをログファイル37に強制出力する。これにより、トランザクションが確約できたので当該トランザクションで取得したすべての排他資源に対するロックを解放する(ステップ84)。COMMITされたトランザクションは、トランザクション実行時に割り当てられたトランザクション管理テーブルが不要となるため、システム内のアクティブトランザクション表から当該COMMITされたトランザクションを取り除くとともに実行フラグ441およびマークフラグ442をOFFに設定し、トランザクション管理テーブルを解放する(ステップ86)。
【0025】
次に、本発明に関わるREDO処理について、図8を用いて説明する。まずシステムの再開始時に、ログ読み込み処理部28にて外部記憶装置16上に記憶したREDO開始ログレコード番号を読み込む(ステップ91)。次いでログファイル37からREDO開始ログレコード番号を起点とするログレコードをログ読み込みバッファ39に読み込み、REDO処理部29にログ読み込みバッファ39上のログレコードを送信する(ステップ92)。REDO処理部29では受信したログレコードからREDOログを取得し、REDOログのLSNとREDOログが更新したデータベースが記憶しているLSNとを比較する。REDOログのLSNの方が大きい番号である場合、REDOログの更新情報をバッファプール上のページに反映する(ステップ93)。ログ読み込み処理部28へ応答を返す(ステップ94)。ログ読み込み処理部28ではさらにREDOログを読み込む必要がある場合、REDO開始ログレコード番号をログ読み込みバッファ39に読めこめなかった先頭のログレコードに更新し、再度ステップ92から処理を繰り返す(ステップ95)。
【0026】
次に、本発明に関わるシンクポイント取得処理について、図1を用いて説明する。シンクポイントの設定の目的は、システムが障害により停止してしまったとしても確実にシステムすなわちデータベースを回復でき、システムを存続できることを確かなものにすることである。また、シンクポイントを設定することによってデータベースの回復時のREDOで必要なログの使用を少なくさせることにもある。シンクポイントを取得するタイミングは様々であるが、定期的に何らかのアクションによって実施される。たとえば、ログファイルへのログの出力回数が一定の回数に達した時点によってシンクポイントを取得する方法がある。この場合、シンクポイント取得のトリガを与えるのはログ書き込み処理部27である。まずシンクポイント取得処理部26にシンクポイント取得処理要求が渡されると、シンクポイント取得開始ログを作成し、ログバッファに書き込む(ステップ251)。次にシンクポイント処理部26は遅延書き込み処理部25にバッファプール34中に存在する全ての更新ページを出力するよう、要求を送信する。
【0027】
遅延書き込み処理部25でシンクポイント処理部26から要求を受信した後の処理を示す。シンクポイント取得開始時点でのバッファプールの物理的整合性を一時的に保証するためにロックを確保する(ステップ252)。当該ロックはラッチと呼ぶことも有り、データベースの論理的な整合性を保証するために用いるロックとは異なり、保持時間が短いという特長がある。バッファプールのロックを確保できたならば、当該ロックが解放されるまでの間、トランザクショによるバッファプールへのアクセスは一時的に待たされる。
【0028】
次に遅延書き込み処理部25でバッファプール34中に存在するすべてのページのページ管理テーブルを走査し、出力要求フラグ330が出力要求状態になっているページについてシンクポイント取得中フラグ335をシンクポイント取得状態に設定する(ステップ253)。ステップ253と同時にシンクポイント取得においてデータベース36へ書き込む対象となるページを管理するページ管理テーブルリスト38を作成する(ステップ254)。出力対象ペ−ジ管理テ−ブルリスト38には、当該リスト作成時にリストに登録されたバッファプ−ル34中の対象ペ−ジのペ−ジ管理テ−ブル32のアドレス382aから382dとその出力対象ペ−ジ数であるシンクポイント出力ペ−ジ数カウンタ381で構成される。登録されたリストの最後には、次の出力対象ペ−ジ管理テ−ブルがないことを示す情報328eとして0を設定する。そして、作成された出力対象ペ−ジ管理テ−ブルリスト38の当該リストが作成された時点でシンクポイント出力ペ−ジ数カウンタ381が決定される(ステップ255)。当該カウンタは、セマフォにより実現されていてもよい。当該シンクポイントでデータベースへの書きだしを行うページが確約されたので直ちにバッファプールのロックを解放する(ステップ256)。当該バッファプ−ルのロック期間中には、一切の外部記憶装置との入出力処理を行わないのでCPU処理だけの短いロック時間となる。これにより、バッファプールへのロック待ちとなっていたトランザクションの処理が続行可能となる。そして、作成された出力対象のページ管理テーブルリストに基づいて当該シンクポイントで出力すべきページを遅延書き込み処理部25に対して要求しデータベースへの出力を開始する(ステップ257)。シンクポイントにおいて出力対象となったすべてのページの出力が完了したか否かは、前記シンクポイント出力ペ−ジ数カウンタ381が0になったかどうかによって決定される(ステップ258)。したがって、シンクポイント出力ペ−ジ数カウンタ381が0になるまで当該処理は待ち状態となる。これは、シンクポイント出力対象ペ−ジの書き込み処理中に他のトランザクションによって書き込み処理が行われることがあるため、他のトランザクションによって書き込み処理が行われ、シンクポイント出力ペ−ジ数カウンタ381をカウントダウンして0になるまで同期を取る必要があるからである。シンクポイントにおいて出力対象となったすべてのページの出力が完了すると、すなわちシンクポイント出力ペ−ジ数カウンタ381が0になると待ち状態が解除されるので、シンクポイント取得完了ログを作成し、ログバッファに書き込むと同時にログファイルへの書き込みを行う(ステップ259)。シンクポイント取得処理が完了した時点で、シンクポイント取得処理部26に完了応答を送信する(ステップ260)。
【0029】
シンクポイント取得処理部26では、遅延書き込み処理部25にバッファプール34中に存在する全ての更新ページを出力するよう要求を送信した後、トランザクション管理テーブル44を走査して実行フラグ441がONである全てのトランザクションのマークフラグ442をONに設定し、遅延書き込み処理部25からシンクポイント取得完了応答を受信するまで待ち合わせる(ステップ261)。シンクポイント取得処理部26はシンクポイント取得完了応答を受信した後、トランザクション管理テーブル44を走査して、実行フラグ441がONかつマークフラグ442がONであるトランザクションが存在している間、当該処理を待ち合わせる(ステップ262)。これはマークしたトランザクションがロールバックすると更新した情報を回復するためにREDO開始ログレコード番号より前のログレコードを必要とする場合があるためである。マークしたトランザクションが全て確定した後、ログバッファ上に書き込んであるログレコードを全てログファイル37に反映した後、当該シンクポイントをカレントな有効シンクポイントとするため当該シンクポイント開始ログのLSNをカレント有効シンクポイントとする(ステップ263)。この有効シンクポイントのLSNはREDO開始ログレコード番号として使用するので、外部記憶装置16のような不揮発な記憶装置に格納されることが望ましい。システムがこの後障害や故障によりシステムが停止しても、システムの再開始時にこの有効シンクポイントのLSNを読み出して、ログ読み込み処理部28から当該LSNを起点とするログレコードを読み込んで、ログからデータベースの回復が行えるようになる。
【0030】
以下、本発明の実施形態について図1と図9を用いて説明する。図1のステップ262の待ち合わせ中に一定間隔が経過した時に、シンクポイント取得処理部26では最後に出力したログレコードのレコード番号を取得して主記憶装置14上に記憶する(ステップ271)。一定間隔の経過を示すアクションはさまざまだが、一定間隔の経過をログの出力回数が一定数に達した場合とする方法がある。次にトランザクション管理テーブル44を走査して実行フラグ441がONである全てのトランザクションのマークフラグ442がONである時に、シンクポイント取得処理部26では再度遅延書き込み処理部25にバッファプール34中に存在する全ての更新ページを出力するよう、要求を送信する(ステップ272)。遅延書き込み処理部25にて行う処理は前述のステップ252からステップ260までである。シンクポイント取得処理部26では遅延書き込み処理部25からシンクポイント取得完了応答を受信するまで待ち合わせる(ステップ273)。シンクポイント取得処理部26はシンクポイント取得完了応答を受信した後、主記憶装置14に記憶したログレコードのレコード番号をREDO開始ログレコード番号に反映し、再度ステップ282に回帰する(ステップ274)。以降ステップ263を行った時に外部記憶装置16に反映するREDO開始ログレコード番号はシンクポイント取得開始時に記憶したログレコード番号101ではなく、ステップ262の待ち合わせ中に記憶したログレコード番号102となるため、REDOで読み込むログレコードの量を(ログレコード番号102−ログレコード番号101)個分削減することが出来る。
【0031】
以上により、データベース管理システムで再開始時に回復するデータベースの更新情報量を削減するために一定間隔おきに取得するシンクポイント処理にて、ロールフォワード処理で読み込む先頭ログレコード番号の決定時間を短縮する、もしくは、ロールフォワード処理で読み込むログレコード数を削減することにより、システム再開始が完了するまでの時間を短縮し、システムダウンを短縮することができる。
【0032】
また、シンクポイント取得開始時にマークしたトランザクションをシンクポイント取得処理途中に再度チェックすることで、マークしたトランザクションが確定するのを待ち合わせる間に再び更新ページをデータベースに書き込んでREDOで読み込むログのレコード位置をより新しい番号に変更できるため、REDOで読み込むログのレコード量を大幅に削減することができる。またトランザクションへはマークをつけるだけであるので、シンクポイント取得処理にてトランザクション処理を全く停止することなく確定するまで待ち合わせることが可能である。
【0033】
【発明の効果】
以上、本発明によれば、再開始処理時間を削減することが可能となる。
【図面の簡単な説明】
【図1】本発明の特長となるシンクポイント取得処理の概略フローを示す。
【図2】本発明を実施するためのデータベース管理システムの構成図
【図3】トランザクションを管理するテーブルの構造を示す
【図4】トランザクション開始処理の処理フローを示す。
【図5】あるトランザクションにおけるデータベースの更新処理の処理フローを示す。
【図6】トランザクションPREPARE処理の処理フローを示す。
【図7】トランザクションCOMMIT処理の処理フローを示す。
【図8】REDO処理の処理フローを示す。
【図9】本発明における、シンクポイント取得処理の処理フローを示す。
【符号の説明】
10:コンピュ−タシステム、12:CPU、14:主記憶装置、16:外部記憶装置、18:端末、20:デ−タベ−ス管理システム、21:質問解析処理部、22:デ−タベ−ス演算処理部、23:バッファプ−ル管理部、24:トランザクション管理部、25:遅延書き込み処理部、26:シンクポイント取得処理部、27:ログ書き込み処理部、28:ログ読み込み処理部、29:REDO処理部、31:バッファプ−ル管理テ−ブル、32:ペ−ジ管理テ−ブル、33:ハッシュ管理テ−ブル、34:バッファプ−ル、35:ログバッファ、36:デ−タベ−ス、37:ログファイル、38:出力対象ペ−ジ管理テ−ブルリスト、39:ログ読み込みバッファ、42:ペ−ジ内制御情報、44:トランザクション管理テーブル、330:出力要求フラグ、381:シンクポイント出力ペ−ジ数カウンタ、425:LSN、441:実行フラグ、442:マークフラグ、443:トランザクション番号、444:トランザクション開始ログのLSN

Claims (2)

  1. 開始回復処理を前提としたトランザクション処理を行うデータベース管理システムにおけるデータベース管理方法において、
    前記シンクポイント取得開始時に障害発生時の再開始回復処理で使用するログレコードの読み込み開始位置を主記憶装置上に記憶し、さらに外部記憶装置上のデータベースに書き込みされていない主記憶装置上にマッピングされたバッファに格納された全ての更新されたページにシンクポイント取得処理中であるマークを付け、前記シンクポイント取得処理中は前記マークのついた全ての更新されたページを前記データベースに書き込み、前記更新ページについて全て前記データベースに書き込みの完了を検知し、前記シンクポイント取得開始時に動作していた前記トランザクションの決着処理を監視し、前記トランザクションが全て決着した時点をシンクポイント取得完了点とし、前記ログレコードの読み込み開始位置を外部記憶装置に書きこむことにより前記シンクポイント処理中の場合もトランザクション処理続行可能とし、前記シンクポイント処理中に前記シンクポイントとREDOで読み込むログの先頭レコード位置を取得し、
    シンクポイント取得処理時点においてマークをつけた確定していないトランザクションが全て確定するまでに所定時間が経過した場合、確定していない全てのトランザクションに前記マークがついていることをシンクポイント取得処理中の所定時間毎に確認し、全てのトランザクションに前記マークがついている場合にのみREDOで読み込むログの先頭ログレコードを主記憶装置上に再度設定し、再び前記バッファの全ての更新したページを書き込むことを特徴とするデータベース管理方法。
  2. 開始回復処理を前提としたトランザクション処理を行うデータベース管理システムにおいて、
    前記シンクポイント取得開始時に障害発生時の再開始回復処理で使用するログレコードの読み込み開始位置を主記憶装置上に記憶し、さらに外部記憶装置上のデータベースに書き込みされていない主記憶装置上にマッピングされたバッファに格納された全ての更新されたページにシンクポイント取得処理中であるマークを付け、前記シンクポイント取得処理中は前記マークのついた全ての更新されたページを前記データベースに書き込み、前記更新ページについて全て前記データベースに書き込みの完了を検知し、前記シンクポイント取得開始時に動作していた前記トランザクションの決着処理を監視し、前記トランザクションが全て決着した時点をシンクポイント取得完了点とし、前記ログレコードの読み込み開始位置を外部記憶装置に書きこむことにより前記シンクポイント処理中の場合もトランザクション処理続行可能とし、前記シンクポイント処理中に前記シンクポイントとREDOで読み込むログの先頭レコード位置を取得する手段と、
    シンクポイント取得処理時点においてマークをつけた確定していないトランザクションが全て確定するまでに所定時間が経過した場合、確定していない全てのトランザクションに前記マークがついていることをシンクポイント取得処理中の所定時間毎に確認し、全てのトランザクションに前記マークがついている場合にのみREDOで読み込むログの先頭ログレコードを主記憶装置上に再度設定し、再び前記バッファの全ての更新したページを書き込む手段とを備えたことを特徴とするデータベース管理システム。
JP2002219049A 2002-07-29 2002-07-29 データベース管理方法およびシステム Expired - Fee Related JP4139642B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2002219049A JP4139642B2 (ja) 2002-07-29 2002-07-29 データベース管理方法およびシステム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2002219049A JP4139642B2 (ja) 2002-07-29 2002-07-29 データベース管理方法およびシステム

Publications (2)

Publication Number Publication Date
JP2004062473A JP2004062473A (ja) 2004-02-26
JP4139642B2 true JP4139642B2 (ja) 2008-08-27

Family

ID=31940046

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2002219049A Expired - Fee Related JP4139642B2 (ja) 2002-07-29 2002-07-29 データベース管理方法およびシステム

Country Status (1)

Country Link
JP (1) JP4139642B2 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100781515B1 (ko) * 2006-01-10 2007-12-03 삼성전자주식회사 트랜잭션 처리를 위한 로그 정보 관리 시스템 및 방법
JP5163179B2 (ja) * 2008-02-25 2013-03-13 株式会社リコー 情報処理装置、情報処理方法、及びプログラム
JP5439014B2 (ja) * 2009-04-10 2014-03-12 株式会社日立製作所 データ処理システム、その処理方法、及び計算機
CN111797158B (zh) * 2019-04-08 2024-04-05 北京沃东天骏信息技术有限公司 数据同步***、方法和计算机可读存储介质

Also Published As

Publication number Publication date
JP2004062473A (ja) 2004-02-26

Similar Documents

Publication Publication Date Title
JP3593366B2 (ja) デ−タベ−ス管理方法
US11321299B2 (en) Scalable conflict detection in transaction management
US10430298B2 (en) Versatile in-memory database recovery using logical log records
Malviya et al. Rethinking main memory OLTP recovery
US6879981B2 (en) Sharing live data with a non cooperative DBMS
JP3763992B2 (ja) データ処理装置及び記録媒体
US8909610B2 (en) Shared log-structured multi-version transactional datastore with metadata to enable melding trees
US8239356B2 (en) Methods and apparatuses for data protection
KR100862661B1 (ko) 지연된 로깅 방법 및 그 장치
US8386421B2 (en) Concurrency control for confluent trees
EP3827347B1 (en) Constant time database recovery
JP7101566B2 (ja) 不揮発性メモリにおけるマルチバージョン同時実行制御(mvcc)
JPH0812631B2 (ja) データベース・トランザクション及び照会処理システム
JPH07175700A (ja) データベース管理方式
JP5012628B2 (ja) メモリデータベース、メモリデータベースシステム及びメモリデータベース更新方法
CN107710203B (zh) 分布式键/值存储库之上的事务数据库层
US20140040208A1 (en) Early release of transaction locks based on tags
EP1456750A1 (en) Collision handling apparatus and method
CN110515705B (zh) 可扩展的持久性事务内存及其工作方法
CN113220490A (zh) 异步写回持久化内存的事务持久化方法及***
JP4139642B2 (ja) データベース管理方法およびシステム
WO2024098363A1 (zh) 一种基于多核处理器的并发事务处理方法及其***
Do et al. Fast peak-to-peak behavior with SSD buffer pool
CN112612647B (zh) 日志并行重演方法、装置、设备及存储介质
JPH0816881B2 (ja) データベース更新方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20040713

RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20060512

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20060512

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20071023

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20071225

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20080527

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20080609

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110613

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110613

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120613

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120613

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130613

Year of fee payment: 5

LAPS Cancellation because of no payment of annual fees