JPH06266597A

JPH06266597A - ログ取得方式

Info

Publication number: JPH06266597A
Application number: JP5050924A
Authority: JP
Inventors: Katsumi Hayashi; 克己林; Tomohiro Hayashi; 知博林; Mitsuhiro Ura; 満広浦; Tomoshige Senoo; 知茂妹尾
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 1993-03-11
Filing date: 1993-03-11
Publication date: 1994-09-22
Also published as: US5696967A

Abstract

(57)【要約】【目的】本発明は、複数のシステムからアクセスされ
るデータベースのログデータを取得するログ取得方式に
関し、ログデータ発生時に、複数システム間で共有する
共用メモリに全システムのログデータをデータベース更
新順に並べて取得しておき、障害発生時に、この並べか
え済みのログデータを参照して障害の発生した資源を閉
塞および復旧を迅速に行うことを目的とする。【構成】複数のシステムがデータベース１２を共用し
て更新したときのログデータを取得するログ取得処理１
４と、このログ取得処理１４が取得したログデータにつ
いて、資源毎にデータベース更新順に不揮発性の共用メ
モリ１０に書き出すログ書出処理１６とを備えるように
構成する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、システムが更新するデ
ータベースのログを取得するログ取得方式に関するもの
である。

【０００２】

【従来の技術】複数システム間で動作するデータベース
管理システムの運用中に、あるシステムがダウンした場
合、そのシステムのトランザクションがまさに更新中の
資源や、更新結果がデータベースに反映されていない資
源などの、最新性の保証されていない資源（汚染資源と
いう）を復旧（リカバリ）する必要がある。このとき、
汚染資源を他のシステムのトランザクションが更新・参
照しないようにするために、汚染資源を閉塞しなければ
ならない。汚染資源を閉塞さえしておけば、ダウンして
いないシステムだけでデータベース管理システムを運用
することができる（フォールバック運用）。このため、
時間のかかる汚染資源の復旧処理は、汚染資源を閉塞し
て他の活性システムがデータベース管理システムを運用
している最中に行うようにしている。

【０００３】また、汚染資源の復旧を行う場合には、デ
ータベースを更新したときに取得したログデータが必要
である。このログデータは、システム固有のログファイ
ルに、システム毎に取得し、これらのログデータについ
て、図６に示すように、汚染資源の復旧を行う前に資源
毎にデータベース更新順に並びかえておく。

【０００４】同様に、汚染資源の閉塞を行う場合、デー
タベース更新順に並びかえたログデータをもとに汚染資
源、つまり閉塞を行べき資源を見つける。図６は、従来
技術の説明図を示す。

【０００５】（１）ログデータの取得フェーズ：シス
テム１、２、３が各システム毎のシステム１用ログファ
イル、システム２用ログファイル、システム３用ログフ
ァイル（不揮発域）にそれぞれＤＢ（データベース）を
更新したログデータを保存する。

【０００６】（２）汚染資源の復旧フェーズ：システ
ム１、２、３がＤＢの資源を更新中に何らかの障害が発
生した場合、システム１、２、３の各ログファイルから
ログデータを取り出してデータベースの資源更新順にソ
ートし、作業用領域（揮発域）に格納する。このデータ
ベース更新順にソートしたログデータを最新のものから
参照し、障害の発生した資源のログデータを取り出し、
ＤＢの障害資源のリカバリ（復旧）を行う。

【０００７】

【発明が解決しようとする課題】上述したように、図６
のような従来のシステムで障害が発生した場合、ログデ
ータをデータ更新順に並びかえてこれを参照して、いず
れの資源を閉塞するか見つけると共に、閉塞した資源の
復旧を行うようにしていたため、システム毎に取得され
たログデータを資源毎にデータベース更新順に並びかえ
る必要があり、ログデータの量が膨大であり、並びかえ
る処理に膨大な時間が必要となってしまい、汚染資源を
見つけて閉塞してフォールバック運用したり、更に見つ
けた汚染資源を復旧したりするのが遅れてしまうという
問題があった。

【０００８】本発明は、これらの問題を解決するため、
複数システム間で共有するログファイルに全システムの
ログデータを資源毎にデータベース更新順に並べて取得
し、障害発生時にこの並びかえ済の資源毎のログデータ
を参照して汚染資源を閉塞および復旧を迅速に行うこと
を目的としている。

【０００９】

【課題を解決するための手段】図１を参照して課題を解
決するための手段を説明する。図１において、ログファ
イル１１は、ログデータを格納する複数システムが共有
するファイルである。

【００１０】ログ取得処理１４は、システムがデータベ
ース１２を更新したときのログデータを取得するもので
ある。

【００１１】

【作用】本発明は、図１に示すように、システムがデー
タベース１２を更新したときに、ログ取得処理１４がこ
のデータベース１２を更新したときのログデータを取得
して資源毎にデータベース更新順に共有のログファイル
１１に格納しておき、障害発生時にログファイル１１を
参照してデータベース１２の該当資源の閉塞および復旧
を行うようにしている。

【００１２】この際、障害発生時にログファイル１１を
参照してデータベース１２の該当資源の閉塞を行った
後、当該資源を元の状態に戻して復元するようにしてい
る。また、障害発生時にログファイル１１を参照してデ
ータベース１２の該当資源の閉塞を行った後、当該資源
を更新後の状態にして復元するようにしている。

【００１３】従って、複数システム間で共有するログフ
ァイル１１に全システムのログデータを資源毎にデータ
ベース更新順に並べて取得し、障害発生時にこの並びか
え済の資源毎のログデータを参照して汚染資源を閉塞お
よび復旧を迅速に行うことが可能となる。

【００１４】

【実施例】次に、図１から図５を用いて本発明の実施例
の構成および動作を順次詳細に説明する。

【００１５】図１は、本発明の１実施例構成図を示す。
図１において、ログファイル１１は、複数のシステム
１、２などに共有に設け、各システムがデータベース１
２の資源を更新したときのログデータを、データベース
の資源の更新順に並べて格納したものである。

【００１６】データベース１２は、各種データを検索し
やすく格納したものである。システム１、２は、データ
ベース１２を更新・参照して各種処理を行うものであっ
て、トランザクションが使用する領域およびシステムが
使用する領域などから構成されるものである。トランザ
クションが使用する領域は、図示のように、排他制御処
理１３、ログ取得処理１４などを実行するプログラムを
格納したり、作業域１５などから構成されている。シス
テムが使用する領域は、図示のように、ログ書出処理１
６、バッファ書き戻し処理１７などを実行するプログラ
ムを格納したり、バッファ１８、システム内作業域１９
などから構成されている。

【００１７】排他制御処理１３は、データベース１２の
資源の排他を獲得するものである。ログ取得処理１４
は、システムがデータベース１２を更新したときのログ
データを資源毎にデータベース更新順にログファイル１
１に格納するためのものである。

【００１８】作業域１５は、ログデータを一時的に格納
したりなどする領域である。ログ書出処理１６は、シス
テム内作業域１９にログデータが所定量を越えた場合な
どに取り出してログファイル１１に格納するものであ
る。

【００１９】バッファ書き出し処理１７は、バッファ１
８のデータをデータベース１２に格納したりなどするも
のである。バッファ１８は、データを一時的に格納する
ものである。

【００２０】システム内作業域１９は、各種データを一
時的に格納したりするものであって、ここではログデー
タを一時的に格納するものである。リカバリ処理は、リ
カバリを行なうものである。

【００２１】次に、図２のフローチャートに示す順序に
従い、図１の構成の動作を詳細に説明する。図２の
（ａ）において、Ｓ１は、トランザクション開始する。

【００２２】Ｓ２は、資源の排他獲得（排他的利用権を
獲得、以下同じ）する。これは、図１の排他制御処理１
３によって更新しようとするデータベース１２の資源の
排他を獲得する。

【００２３】Ｓ３は、更新前ログを取得する。これは、
データベース１２の資源を更新する前のログデータを取
得する。Ｓ４は、ＤＢを更新する。これは、Ｓ３に続
き、データベース１２の資源の更新を行う。

【００２４】Ｓ５は、更新後ログを取得する。これは、
データベース１２の資源を更新した後のログデータを取
得する。Ｓ６は、全ての資源への更新が終了したか判別
する。ＹＥＳの場合には、Ｓ９に進む。ＮＯの場合に
は、Ｓ７に進む。

【００２５】Ｓ７は、トランザクションの作業域に一定
量のログが溜まったか判別する。これは、図１の作業域
１５にＳ３およびＳ５で取得したログデータが一定量溜
まったか判別する。ＹＥＳの場合には、Ｓ８でトランザ
クションの作業域１５のログをシステム内作業域１９に
コピーし、Ｓ３に戻り繰り返す。一方、ＮＯの場合に
は、Ｓ３に戻り繰り返す。

【００２６】Ｓ９は、トランザクションの作業域の残り
のログをシステム内の作業域にコピする。即ち、Ｓ６の
ＹＥＳで資源への更新が終了したので、トランザクショ
ンの作業域１５のログデータをシステム内作業域１９に
コピーする。

【００２７】Ｓ１０は、システム内の作業域のログが不
揮発化されたか判別する。ＹＥＳの場合には、システム
内作業域１９のログデータがログファイル１１に保存さ
れて不揮発化されたと判明したので、Ｓ１１で資源の排
他解放し、Ｓ１２で一連のトランザクションを終了す
る。一方、ＮＯの場合には、Ｓ１０でシステム内作業域
１９のログデータが不揮発化されるのを待つ。不揮発化
するために複数のシステムに共有のログファイル１１に
保存する際に、データベース１２の資源毎にデータベー
ス更新順にログデータを保存するようにしている。

【００２８】ここで、Ｓ９で複数システム間で共有され
るので、ログファイル１１への書き出しは複数システム
間で逐次化される。例えば磁気ディスク装置を利用して
いる場合、装置制御装置に対して最初に占有権を獲得し
たシステムが書き出し可能とし、装置占有が開放された
後、同様のことを繰り返すといった手段が採用される。

【００２９】一方、ログの書き出し順番は、この逐次化
の方法と無関係にデータベース１２の資源の排他的利用
権の獲得によって保証している。データベースの利用権
を獲得出来なかったシステムは、そもそも、書き込むべ
きログが発生しようがないからである。本発明は、主記
憶共有しない独立の複数システム間でデータベースとロ
グを共有することによって、ＴＣＭＰと同様にログの複
合システム内での一貫した利用を実現可能となるもので
ある。

【００３０】以上によって、トランザクション開始時に
資源の排他を獲得し、データベース１２に資源の更新前
ログデータおよび更新後ログデータを取得して複数のシ
ステムで共有のログファイル１１にデータベース１２の
資源毎に更新順にログデータを保存して不揮発化した
後、排他解放して一連のトランザクション終了する。こ
れにより、データベース１２の資源のいずれかに障害が
発生しても、ログファイル１１には既に資源毎にデータ
ベース更新順にログデータが保存されているため、この
データベース更新順のログデータを参照して汚染資源の
閉塞および復旧を迅速に図ることが可能となる。

【００３１】図２の（ｂ）は、バッファ書き戻し処理１
７を示す。図２の（ｂ）において、Ｓ２１は、バッファ
がいっぱいか判別する。ＹＥＳの場合には、図１のバッ
ファ１８が一杯であると判明したので、Ｓ２２でバッフ
ァ更新前に取得したログが不揮発化されたか判別する。
ＹＥＳの場合には、Ｓ２３でバッファの書き戻しを行
い、Ｓ２１に戻る。一方、ＮＯの場合には、ログが不揮
発化されるのを待機する。

【００３２】図２の（ｃ）は、ログ書出処理１６を示
す。図２の（ｃ）において、Ｓ３１は、システム内の作
業域のログが一定量を越えたか判別する。ＹＥＳの場合
には、Ｓ３３で不揮発域の排他獲得する。

【００３３】Ｓ３４は、システム内の作業域１９のログ
を不揮発域（ログファイル１１）に書き出す。Ｓ３５
は、不揮発域の排他解放する。そして、Ｓ３１に戻る。

【００３４】次に、図３を用いてＵＮＤＯ（そのトラン
ザクショでのＤＢ更新を無かったことにする）時の動作
を詳細に説明する。図３において、Ｓ４１は、トランザ
クション開始する。

【００３５】Ｓ４２は、資源の排他獲得する。これは、
図１の排他制御処理１３が更新しようとするデータベー
ス１２の資源の排他を獲得する。Ｓ４３は、ＤＢ更新す
る。これは、Ｓ４２に続き、データベース１２の資源の
更新を行う。

【００３６】Ｓ４４は、バッファ書き戻しを行う。この
バッファ書き戻しの際に、当該バッファ書き戻しに関連
するログデータを資源毎にデータベース更新順にログフ
ァイル１１に保存しておく。

【００３７】Ｓ４５で、障害が発生する。これは、デー
タベース１２の資源への更新時に障害が発生する。Ｓ４
６は、リカバリ開始する。

【００３８】Ｓ４７は、不揮発域（ログファイル１１）
より全ての終了していないトランザクションの最後のロ
グを見つける。これは、Ｓ４４のときに合わせてログフ
ァイル１１に保存した資源毎のデータベース更新順のロ
グデータを取り出し、トランザクションが終了していな
いログデータを見つける。

【００３９】Ｓ４８は、Ｓ４７で見つけたログを使い、
資源の復旧、即ち元の状態に戻す。Ｓ４９は、１つ前の
ログを見つける。Ｓ５０は、トランザクションのログが
無いか判別する。ＹＥＳの場合には、Ｓ５１に進む。一
方、ＮＯの場合には、Ｓ４８に戻り、資源の復旧を繰り
返す。

【００４０】Ｓ５１は、全てのトランザクションの処理
が終了か判別する。ＹＥＳの場合には、リカバリ完了す
る。ＮＯの場合には、Ｓ４８に戻り、資源の復旧を繰り
返す。

【００４１】以上によって、ログファイル１１に資源毎
にデータベース更新順に保存したログデータから終了し
ていないトランザクションを順次見つけ出し、この見つ
け出したログデータを使って資源を元の状態に復元する
ことを繰り返す。これにより、障害発生時にログデータ
を資源毎にデータベース更新順に並びかえることなく、
即時に資源の閉塞および資源の復旧を開始することが可
能となる。

【００４２】次に、図４を用いてＲＥＤＯ（そのトラン
ザクションでのＤＢ更新状態をＤＢに反映する）時の動
作を詳細に説明する。図４において、Ｓ６１は、トラン
ザクション開始する。

【００４３】Ｓ６２は、資源の排他獲得する。これは、
図１の排他制御処理１３が更新しようとするデータベー
ス１２の資源の排他を獲得する。Ｓ６３は、ＤＢ更新す
る。これは、Ｓ６２に続き、データベース１２の資源の
更新を行う。このＤＢ更新前後の関連するログデータを
資源毎にデータベース更新順にログファイル１１に保存
しておく。

【００４４】Ｓ６４は、資源の排他解放する。Ｓ６５
は、トランザクション終了する。Ｓ６６は、障害発生し
たと（バッファ書き戻し未）する。

【００４５】Ｓ６７は、リカバリ開始する。Ｓ６８は、
不揮発化域（ログファイル１１）より終了しているトラ
ンザクションを見つける。

【００４６】Ｓ６９は、不揮発化域の先頭からログを１
つ取り出す。Ｓ７０は、ログがもうないか判別する。Ｙ
ＥＳの場合には、Ｓ７３でリカバリ完了する。ＮＯの場
合には、Ｓ７１に進む。

【００４７】Ｓ７１は、取り出したログが終了トランザ
クションのものか判別する。ＹＥＳの場合には、Ｓ６６
で障害発生してバッファ書き戻し未の資源のログデータ
と判明したので、Ｓ７２で資源の復旧として、当該ログ
データを使って更新後状態にし、Ｓ６９に戻り、繰り返
す。一方、ＮＯの場合には、Ｓ６９を戻り繰り返す。

【００４８】以上によって、ログファイル１１に資源毎
にデータベース更新順に保存したログデータから終了し
ているトランザクションを順次見つけ出し、この見つけ
出したログデータを使って資源を更新後の状態に復元す
ることを繰り返す。これにより、障害発生時にログデー
タを資源毎にデータベース更新順に並びかえることな
く、即時に資源の閉塞および資源の復旧を開始すること
が可能となる。

【００４９】図５は、本発明のログデータ取得説明図を
示す。これは、２つのトランザクションＡとトランザク
ションＢがデータデース１２の同一の資源αを更新した
ときに、不揮発化したログファイル１１に資源毎にログ
データをデータベース更新順に保存する様子を示したも
のである。

【００５０】図５の（ａ）は、模式的にログファイル１
１への保存を示したものである。図５の（ｂ）は、図５
の（ａ）の動作説明図である。（１）トランザクションＡの動作：は、トランザク
ションＡがデータベース１２の資源αの排他を獲得す
る。

【００５１】は、資源αの更新前ログ取得する。
は、資源αの更新する。は、資源αの更新後ログ取得
する。

【００５２】は、資源αのログの不揮発化（同期）す
る。この時点でログデータ（更新前ログデータおよび更
新後ログデータ）がログファイル１１に図５の（ａ）の
点線の矢印を用いて示すように保存する。

【００５３】は、トランザクションＡのＣＯＭＭＩＴ
終了する。は、資源αの排他解除する。（２）トランザクションＢの動作：は、トランザク
ションＢが資源αの排他獲得待ちする。

【００５４】は、資源αの排他獲得待ち解除する。
は、資源αの更新前ログ取得する。は、資源αの更新
する。

【００５５】（１０）は、資源αの更新後ログ取得す
る。（１１）は、資源αのログの不揮発化（同期）す
る。この時点でログデータ（更新前ログデータおよび更
新後ログデータ）がログファイル１１に図５の（ａ）の
点線の矢印を用いて示すように保存する。

【００５６】（１２）は、トランザクションＢのＣＯＭ
ＭＩＴ終了する。（１３）は、資源αの排他解除する。
以上の手順によって、ログファイル１１には、データベ
ース１２の資源毎にデータベース更新順にログデータが
保存されることとなる。

【００５７】

【発明の効果】以上説明したように、本発明によれば、
複数システム間で共有するログファイル１１に全システ
ムのログデータを資源毎にデータベース更新順に並べて
取得し、障害発生時にこの並びかえ済の資源毎のログデ
ータを参照して汚染資源を閉塞および復旧を行う構成を
採用しているため、データベース１２の資源の障害発生
時にログデータの並びかえを行うことなく、汚染資源の
閉塞および復旧を即時に開始することができる。これに
より、従来の汚染資源の閉塞および復旧するために、各
システムで取得したログデータをデータベースの資源毎
にソートして汚染資源を見つけて閉塞および復旧を開始
するという遅れを無くし、障害発生時に即時に汚染資源
を閉塞してフォールバック運用を開始しつつ汚染資源の
復旧を図ることが可能となる。

【図面の簡単な説明】

【図１】本発明の１実施例構成図である。

【図２】本発明の動作説明フローチャートである。

【図３】本発明のＵＮＤＯ（ＤＢ更新を無かったことに
する）時のフローチャートである。

【図４】本発明のＲＥＤＯ（ＤＢ更新状態をＤＢに反映
する）時のフローチャートである。

【図５】本発明のログデータ取得説明図である。

【図６】従来技術の説明図である。

【符号の説明】

１、２：システム１１：ログファイル１２：データベース１３：排他制御処理１４：ログ取得処理１５：作業域１６：ログ書出処理１７：バッファ書き戻し処理１８：バッファ１９：システム内作業域

─────────────────────────────────────────────────────

【手続補正書】

【提出日】平成６年１月２８日

【手続補正１】

【補正対象書類名】明細書

【補正対象項目名】全文

【補正方法】変更

【補正内容】

【書類名】明細書

【発明の名称】ログ取得方式

【特許請求の範囲】

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、複数のシステムがデー
タベースを共用するデータベース処理システムにおい
て、データベースのログデータを取得するログ取得方式
に関するものである。

【０００２】

【従来の技術】複数のシステムがデータベースを共用し
ているデータベース処理システムの運用中に、何らかの
原因でデータベースの資源に障害が発生した場合、デー
タベースを更新したときに取得したログデータが必要と
なる。

【０００３】従来、このログデータは、システム毎にシ
ステム固有のログファイルに取得する。そして、障害発
生時に、図６に示すように、全システム分のログファイ
ルを参照してデータベースの資源の更新時間順に並びか
えて、障害の発生した資源を復旧する。

【０００４】図６は、従来技術の説明図を示す。（１）ログデータの取得フェース：システム１、２、
３が各システム毎のシステム１用ログファイル、システ
ム２用ログファイル、システム３用ログファイル（不揮
発域）にそれぞれデータベースの資源を更新したときの
ログデータを保存する。

【０００５】（２）障害となった資源の復旧フェー
ズ：システム１、２、３がデータベース処理の運用中に
何らかの障害が発生した場合、システム１、２、３の各
ログファイルからログデータを取り出してデータベース
の資源の更新時間順に並べかえ、作業用領域に格納す
る。このデータベース更新順に並べかえたログデータを
参照し、障害の発生したデータベースの資源を復旧す
る。

【０００６】また、複数のシステムがデータベースを共
用しているデータベース処理システムにおけるログデー
タの並べかえ技術に関しては、次のものがある。・特開昭６１−１３３４５９号（データベース更新ログ
処理方式）これは、更新ログ用履歴ファイルをデータベースの資源
ごとにグループ化し、複数プロセッサで共用する。個々
の更新ログ用履歴ファイルは、区画化されており、ログ
格納位置がプロセッサごとに固定化される。

【０００７】・特開平３−２０２９５０号（ジャーナル収集方式）これは、各プロセッサから発生するログデータを一括し
てミニコンピュータ（ＢＥＰ）に送付し、共用データベ
ースに関するログデータをミニコンピュータ（ＢＥＰ）
が併合して共用のログファイルに保存する。

【０００８】

【発明が解決しようとする課題】上述した図６のような
従来のシステムで障害が発生した場合、ログデータをデ
ータベース更新順に並べかえてこれを参照して、障害と
なった資源の復旧を行うようにしていたため、システム
ごとに取得されたログデータをデータベース更新順に並
べかえる必要があり、ログデータの量が膨大であり、並
べかえる処理に膨大な時間が必要となってしまい、障害
の発生した資源を見つけて閉塞してフォールバック運用
したり、更に、その資源を復旧したりするのが遅れてし
まうという問題があった。

【０００９】また、前者の公報は、資源グループごとの
更新ログ履歴ファイルが各々のプロセッサごとに区画化
されており、各々のプロセッサは各自の区画域にログデ
ータを出力する。このため、リカバリ時にログデータを
並べかえる必要があるという問題があった。

【００１０】また、後者の公報は、ログデータを出力す
るプロセッサをミニコンピュータ（ＢＥＰ）に限定して
いる。このため、ログデータを出力するシステム異常時
の信頼性に欠けるという問題がある。

【００１１】本発明は、これらの問題を解決するため、
ログデータ発生時に、複数システム間で共有する共用メ
モリに全システムのログデータをデータベース更新順に
並べて取得しておき、障害発生時に、この並べかえ済み
のログデータを参照して障害の発生した資源の閉塞およ
び復旧を迅速に行うことを目的としている。

【００１２】

【課題を解決するための手段】図１を参照して課題を解
決するための手段を説明する。図１において、共用メモ
リ１０は、ログデータを格納する複数システムが共有す
るメモリである。この共用メモリ１０は、不揮発域に配
置することも、揮発域に配置することもできる。共用メ
モリ１０を揮発域に配置した場合には、更に、複数シス
テムで共有する不揮発性のログファイル１１を配置す
る。

【００１３】ログ取得処理１４は、各システム内で動作
するトランザクションがデータベース１２を更新したと
きのログデータをシステム内作業域１９に取得するもの
である。

【００１４】ログ書出処理１６は、トランザクションの
ログデータを不揮発域に書き出すものである。

【００１５】

【作用】本発明は、図１に示すように、トランザクショ
ンがデータベース１２を更新したときに、ログ取得処理
１４がこのデータベース１２を更新したときのログデー
タをシステム内作業域１９に取得し、ログ書出処理１６
がトランザクションによるデータベース更新順にログデ
ータを不揮発性の共用メモリ１０に書き出す。また、図
２に示すように、ログデータをデータ更新順に揮発性の
共用メモリ１０に書き出し、複数のシステムからのログ
データをまとめてスペース効率を高めるバッファリング
した後、不揮発性のログファイル１１に書き出すように
してもよい。

【００１６】従って、複数システム間で共用する共用メ
モリ１０に全システムのログデータがデータベース更新
順に並べられて書き出されているので、従来のログ併合
処理が不要であり、障害発生時には、ＴＣＭＰ（密結合
システム）と同様にこの並べかえ済みのログデータを参
照してデータベース１２の閉塞および復旧の性能を引き
出すことができる。

【００１７】また、対称的なシステム構成であるためシ
ステムの障害に強く、更に、ＢＥＰ（ログデータを取得
するミニコンピュータ）は不要であり、シンプルなシス
テム構成となる。

【００１８】

【実施例】次に、図１から図５を用いて、本発明の実施
例の構成および動作を順次詳細に説明する。

【００１９】図１は、本発明の１実施例構成図を示す。
図１において、共用メモリ１０は、複数のシステム１、
２・・・ｎなどに共有に設け、各システムがデータベー
ス１２の資源を更新したときのログデータをデータベー
ス１２の更新順に並べて格納するものである。

【００２０】データベース１２は、各種データを検索・
更新しやすく格納したものである。システム１、２・・
・ｎは、データベース１２を参照・更新して各種処理を
行うものであって、トランザクションが使用する領域や
システムが使用する領域などをローカルメモリに配置し
たものである。

【００２１】排他制御処理１３は、データベース１２の
資源の排他を獲得するものである。ログ取得処理１４
は、トランザクションがデータベース１２を更新したと
きのログデータをデータベース１２の更新順にシステム
内作業域１９に取得するものである。

【００２２】バッファ制御１５は、データをバッファに
格納などするものである。ログ書出処理１６は、共用メ
モリ１０が不揮発域に配置されている場合、システム内
作業域１９にログデータが所定量を越えたときなどに取
り出したログデータを共用メモリ１０に格納するもので
ある。

【００２３】バッファ書き戻し処理１７は、バッファ１
８上のデータをデータベース１２に格納したりなどする
ものである。バッファ１８は、データを一時的に格納す
るものである。

【００２４】システム内作業域１９は、各種データを一
時的に格納したりするものであって、ここでは、ログデ
ータを一時的に格納するものである。

【００２５】また、図２において、ログ書出処理１６
は、共用メモリ１０が揮発域に配置されている場合、シ
ステム内作業域１９にログデータが所定量を越えたとき
などに取り出したログデータを共用メモリ１０に複写
し、複数のシステムからのログデータをまとめてスペー
ス効率を高めるバッファリングした後に、不揮発性のロ
グファイル１１に格納するものである。

【００２６】次に、図３のフローチャートに示す順序に
従い、図１および図２の構成の動作を詳細に説明する。
図３の（ａ）において、Ｓ１は、トランザクションを開
始する。

【００２７】Ｓ２は、資源の排他獲得（排他的利用権を
獲得、以下同じ）する。これは、図１および図２の排他
制御処理１３によって更新しようとするデータベース１
２の資源の排他を獲得する。

【００２８】Ｓ３は、更新前ログをシステム内作業域に
取得する。これは、データベース１２の資源を更新する
前のログデータを取得する。Ｓ４は、データベースを更
新する。これは、Ｓ３に続き、データベース１２の資源
の更新をバッファ１８上で行う。

【００２９】Ｓ５は、更新後ログをシステム内作業域に
取得する。これは、データベース１２の資源を更新した
後のログデータを取得する。Ｓ６は、全ての資源への更
新が終了したかを判別する。ＹＥＳの場合には、Ｓ７に
進む。ＮＯの場合には、Ｓ３から繰り返す。

【００３０】Ｓ７は、システム内作業域のログデータが
不揮発化されたかを判別する。ＹＥＳの場合には、シス
テム内作業域１９のログデータが共用メモリ１０あるい
はログファイル１１に保存されて不揮発化されたと判明
したので、Ｓ８で資源の排他解放し、Ｓ９で一連のトラ
ンザクションを終了する。一方、ＮＯの場合には、Ｓ７
でシステム内作業域１９のログデータが不揮発化される
のを待つ。不揮発化するために、複数のシステムに共有
の共用メモリ１０またはログファイル１１に保存する際
に、データベース更新順にログデータを保存するように
している。

【００３１】ここで、共用メモリ１０へのアクセスは、
複数システム間で逐次化される。例えば共用メモリ１０
に対して最初に占有権を獲得したシステムが共用メモリ
１０へアクセス可能とし、占有権が解放された後に、同
様のことを繰り返すといった手段が採用される。

【００３２】一方、ログデータの書出し順番は、この逐
次化の方法と無関係にデータベース１２の資源の排他的
利用権の獲得によって保証している。データベース１２
の利用権を獲得できなかったら、そもそも書き込むべ
き、ログデータが発生しようがないからである。

【００３３】従って、同一資源に対するログデータは、
トランザクションの終了順に書き出されることが保証さ
れる。本発明は、独立の複数システム間でデータヘース
１２とログデータを共有することによって、ＴＣＭＰ
（密結合システム）と同様に、ログデータの複合システ
ムの一貫した利用を実現可能とするものである。

【００３４】以上によって、トランザクション開始時に
資源の排他を獲得し、データベース１２を更新する際に
更新前ログデータおよび更新後ログデータを取得し、複
数のシステムで共有の共用メモリ１０あるいは共有のロ
グファイル１１にデータベース１２の更新順にログデー
タを保存して不揮発化した後、排他解放して一連のトラ
ンザクションを終了する。これにより、データベース１
２の資源のいずれかに障害が発生しても、共用メモリ１
０あるいはログファイル１１には既にデータベース更新
順にログデータが保存されているために、このデータベ
ース更新順のログデータを参照して障害が発生した資源
の閉塞および復旧を迅速に図ることが可能となる。

【００３５】図３の（ｂ）は、バッファ書き戻し処理
（システム常駐デーモン）を示す。図３の（ｂ）におい
て、Ｓ２１は、バッファが一杯かを判別する。ＹＥＳの
場合には、図１あるいは図２のバッファ１８が一杯であ
ると判明したので、Ｓ２２で更新前に取得したログデー
タが不揮発化されたかを判別する。ＹＥＳの場合には、
Ｓ２３でバッファの書き戻しを行い、Ｓ２１に戻る。一
方、ＮＯの場合には、ログデータが不揮発化されるのを
待機する。

【００３６】図４の（ｃ）は、ログ書出処理（システム
常駐デーモン）を示す。図４の（ｃ）において、Ｓ３１
は、システム内作業域のログデータが一定量を超えたか
を判別する。ＹＥＳの場合には、Ｓ３３に進む。ＮＯの
場合には、Ｓ３２で、前回のシステム内作業域１９のロ
グデータの書出し契機から一定時間が経過したかを判別
する。また、Ｓ３２の他の判別手段としては、Ｓ７やＳ
２２から不揮発化要求が発生しているかを判別する場合
もある。ＹＥＳの場合には、Ｓ３３に進む。ＮＯの場合
には、Ｓ３１に戻る。

【００３７】Ｓ３３は、共用メモリが不揮発域に配置さ
れているかを判別する。ＹＥＳの場合には、Ｓ３４に進
む。ＮＯの場合には、Ｓ３８に進む。Ｓ３４は、複数の
システム間で共用メモリの排他を獲得する。例えば個々
のシステムは共用メモリ１０上に利用宣言を記録し、他
システムが既に利用宣言済みならば排他解放されるのを
待つといった手段が採用される。

【００３８】Ｓ３５は、共用メモリ上に記録されている
ログ最終書出位置を参照して、共用メモリ上の該当位置
にシステム内作業域にログデータを必要量だけ格納す
る。複数のシステムのログデータがトランザクションの
終了順にブロッキングされることになる。

【００３９】Ｓ３６は、共用メモリ上のログ最終書出位
置を更新する。Ｓ３７は、共用メモリの排他を解放す
る。そして、Ｓ３１に戻る。Ｓ３８は、複数のシステム
間で共用メモリの排他を獲得する。例えば個々のシステ
ムは共用メモリ１０上に利用宣言を記録し、他システム
が既に利用宣言済みならば排他解放されるのを待つとい
った手段が採用される。

【００４０】Ｓ３９は、共用メモリ上に記録されている
ログ最終書出位置を参照して、共用メモリ上の該当位置
にシステム内作業域のログデータを必要量だけ複写す
る。複数のシステムのログデータがトランザクションの
終了順にバッファリングされることとなる。

【００４１】Ｓ４０は、共用メモリ上のログ最終書出位
置を更新する。Ｓ４１は、共用メモリの排他を解放す
る。Ｓ４２は、共用メモリ内にバッファリングされたロ
グデータをログファイルに格納する。そして、Ｓ３１に
戻る。

【００４２】図５は、本発明のログデータ取得説明図を
示す。これは、２つのトランザクションＡとトランザク
ションＢがデータベース１２の同一資源αを更新したと
きに、不揮発域に配置された共用メモリ１０にログデー
タをデータベース更新順に保存する様子を示したもので
ある。

【００４３】図５の（ａ）は、模式的に不揮発域に配置
された共用メモリへのログデータの保存を示したもので
ある。図５の（ｂ）は、図５の（ａ）の動作説明図であ
る。（１）トランザクションＡの動作：は、トランザク
ションＡがデータベースの資源αの排他を獲得する。

【００４４】は、資源αの更新前ログを取得する。
は、資源αを更新する。は、資源αの更新後ログを取
得する。

【００４５】は、資源αのログデータの不揮発化を完
了同期をとる。この時点で、ログデータ（更新前ログデ
ータおよび更新後ログデータ）が共用メモリ１０に図５
の（ａ）の点線の矢印を用いて示すように保存される。

【００４６】は、ログデータの不揮発化の同期が完了
したことにより、トランザクションＡのＣＯＭＭＩＴが
終了する。は、資源αの排他解除を行う。

【００４７】（２）トランザクションＢの動作：
は、他のトランザクションが既にデータベースの資源α
を排他獲得しているので、トランザクションＢは資源排
他獲得待ちに入る。

【００４８】は、トランザクションＡが排他を解放し
たことにより、トランザクションＢがデータベースの資
源αの排他を獲得する。（１０）は、資源αの更新前ロ
グを取得する。

【００４９】（１１）は、資源αを更新する。（１２）
は、資源αの更新後ログを取得する。（１３）は、資源
αのログデータの不揮発化の完了同期をとる。この時点
で、ログデータ（更新前ログデータおよび更新後ログデ
ータ）が共用メモリに図５の（ａ）の点線の矢印を用い
て示すように保存される。

【００５０】（１４）は、ログデータの不揮発化の同期
が完了したことにより、トランザクションＢのＣＯＭＭ
ＩＴが終了する。（１５）は、資源αの排他解除を行
う。

【００５１】以上の手順によって、共用メモリ１０に
は、データベース１２の同一資源に関してトランザクシ
ョンの終了順にログデータが保存されることになる。

【００５２】

【発明の効果】以上説明したように、本発明によれば、
複数システムで共有する共用メモリ１０あるいはログフ
ァイル１１に全システムのログデータをデータベース１
２の更新順に並べて取得しているので、障害発生時に、
この並べかえ済みのログデータを参照することができる
ので、ログデータの並べかえ無しに障害となった資源の
閉塞および復旧を即時に開始することができる。これに
より、障害となった資源を閉塞および復旧するために、
各システムで個別に取得したログデータを併合するとい
った従来の手間を省くことができ、障害発生時に即時に
障害となった資源を閉塞してフォールバック運用を開始
しつつ資源を復旧することが可能となる。即ち、独立の
複数システム間でデータベース１２とログデータを共有
することによって、ＴＣＭＰ（密結合システム）と同様
にログデータの複合システムでの一貫した利用を実現可
能とするものである。

【図面の簡単な説明】

【図１】本発明の１実施例構成図である。

【図２】本発明の他の実施例構成図である。

【図３】本発明の動作説明フローチャート（つづく）で
ある。

【図４】本発明の動作説明フローチャート（つづき）で
ある。

【図５】本発明のログデータ取得説明図である。

【図６】従来技術の説明図である。

【符号の説明】１０：共用メモリ１１：ログファイル１２：データベース１３：排他制御処理１４：ログ取得処理１５：バッファ制御１６：ログ書出処理１７：バッファ書き戻し処理１８：バッファ１９：システム内作業域

【手続補正２】

【補正対象書類名】図面

【補正対象項目名】全図

【補正方法】変更

【補正内容】

【図１】

【図２】

【図３】

【図４】

【図５】

【図６】

───────────────────────────────────────────────────── フロントページの続き (72)発明者妹尾知茂神奈川県川崎市中原区上小田中1015番地富士通株式会社内

Claims

【特許請求の範囲】

【請求項１】システムが更新するデータベースのログを
取得するログ取得方式において、ログデータを格納する複数システムが共有するログファ
イル（１１）と、システムがデータベース（１２）を更新したときのログ
データを取得するログ取得処理（１４）とを備え、システムがデータベース（１２）を更新したときに、上
記ログ取得処理（１４）がこのデータベース（１２）を
更新したときのログデータを取得し、資源毎にデータベ
ース更新順に上記ログファイル（１１）に格納してお
き、障害発生時に上記ログファイル（１１）を参照してデー
タベース（１２）の該当資源の閉塞および復旧を行うよ
うに構成したことを特徴とするログ取得方式。
【請求項２】障害発生時に上記ログファイル（１１）を
参照してデータベース（１２）の該当資源の閉塞を行っ
た後、当該資源を元の状態に戻して復元するように構成
したことを特徴とする請求項１記載のログ取得方式。
【請求項３】障害発生時に上記ログファイル（１１）を
参照してデータベース（１２）の該当資源の閉塞を行っ
た後、当該資源を更新後の状態にして復元するように構
成したことを特徴とする請求項１記載のログ取得方式。