JPH02292641A

JPH02292641A - データベース管理方法

Info

Publication number: JPH02292641A
Application number: JP1112865A
Authority: JP
Inventors: Tetsuo Iizuka; 飯塚　哲夫; Katsuhiro Ariyoshi; 有吉　克浩; Rinichi Takashi; 高志　林一
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 1989-05-02
Filing date: 1989-05-02
Publication date: 1990-12-04

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】〔産業上の利用分野〕本発明は、データベースを多重化して、これらを障害時
の回復に用いるとともに、検索用としても利用できるよ
うなデータベース管理方法に関する。

〔従来の技術］従来より、データベースを二重化してデータに対する信
頼性の向上を図っている。通常、データベースシステム
は、中央にデータベースを配置し、中央とオンラインで
接続された遠隔地の端末との間で相互通信を行うことに
より、端末から中央のデータベースを利用している。デ
ータベースの内容を更新する場合には、オンライン処理
を中断することができないため、通常は夜間や休日に一
括処理を行っていた。しかし、１回の処理に数１０時間
もかかる場合には、夜間や休日だけでは更新処理は完了
せず、また係員の休日出勤が増加するため問題があった
。

一方、データベース二重化システムにおいて、オンライ
ン処理と併行してデータベースの更新情報を正のデータ
ベースと副のデータベースに同時に書込む場合には、利
用者からのアクセスに備えて、正と副とでシリアルに処
理する必要があるため、副系データベースの書込み完了
を待たなくてはならず、通常のデータベースシステムに
比べると処理性能が低下する。この場合には、利用者か
ら、通常のデータベースシステムと同程度の処理性能の
向上が望まれていた。

また、データベースシステムにおいて、複数タスクが検
索を行い、それ以外のタスクが更新するような一括処理
方式が提案されている（例えば、特開昭６１−８８３４
９号公報参照）．，この方式においては、第１のプロセ
ッサはデータベースを用いてオンライン処理（検索）を
行い、第２のプロセッサはデータベースの一括更新処理
（更新）を行う。第２のプロセッサはファイル装置のｌ
ないし複数トラック単位で複数のファイル装置を時分割
的にアクセスして一括処理を行い、処理中のファイル装
置のトラックは第１のプロセッサがオンライン処理で使
用することを禁止している。このように、更新タスクを
優先して、トラック単位の処理を行うことにより，更新
系処理の負荷を分散することができ、その結果，検索系
タスクの待ち時間を減少させることが可能である。

【発明が解決しようとする課題〕

前述の各多重化データベースシステムでは、データベー
ス障害に対する回復、および処理の高速化による検索性
能の向上については、あまり配慮されていないため、更
新系タスクが処理を行っている間は、検索系タスクの処
理ができないという問題があった。

本発明の目的は、これら従来の課題を解決し、データベ
ースの多重化により、データベースの障害に対する回復
時間を短縮するとともに、更新処理と検索処理とを並行
して処理することにより、信頼性の向上と性能の向上を
図ることが可能なデータベース管理方法を提供すること
にある。

〔課題を解決するための手段〕

上記目的を達成するため、本発明のデータベース管理方
法は、（ｉ）予定の時点で同一内容を持つような複数の
データベースシステムの管理方法において、第１のデー
タベースは常時最新の更新状態にあり、残りの第２のデ
ータベースは未更新状態にあり、かつデータを更新する
毎に更新データ累積情報としてメモリに累積しておき、
最新の更新状態にある上記第１のデータベースに障害が
発生したときには、該第１のデータベースをシステムか
ら切り離し、未更新の上記第２のデータベースに上記更
新データ累積情報を反映して、最新の更新状態にした上
で、それ以降のユーザの更新要求に対して」二記第２の
データベースが処理することに特徴がある。また、（ｉ
ｆ）Ｊ二記データベースの更新データを直ちに反映せず
に、該更新データをメモリ上に累積していき、該メモリ
上の更新データを予定の周期で上記データベースに反映
させ、各データベース相互間の同期処理を行うことにも
特徴がある。（ｉｊｉ）第１のデータベースが常に最新
の更新状態にあり、残りの第２のデータベースは予定の
期間だけ未更新状態にあり，かつデータの更新毎に更新
データ累積情報としてメモリに累積していく場合、ユー
ザのデータベース検索要求に対して、最新の更新状態に
ある上記第１のデータベースで処理するか、あるいは未
更新状態にある上記第２のデータベースと上記更新デー
タ累積情報を基に処理するか、いずれか一方を実行する
ことにも特徴がある。また、（ｉｖ）上記ユーザのデー
タベース検索要求に対して、第１および第２のデータベ
ースの中で、データベースのＩ／Ｏ負荷が軽い方のデー
タベースを用いて処理することにも特徴がある。また、
（Ｖ）上記更新データ累積情報は、ユーザ業務の作業単
位であるトランザクションの開始から終了までの更新デ
ータをデータベースＩ／Ｏ単位に累積したものであり、
該更新データ累積情報を基に未更新データベースに反映
処理を行うことにも特徴がある。また、（ｖ１）上記更
新データ累積情報を、未更新状態にあるデータベースに
反映する場合、反映する間隔をユーザが任意に指定し、
該データベースに反映処理を行う時間以外の時間にはユ
ーザのデータ検索要求に対する処理を行わせることにも
特徴がある。また，（■）上記第１および第２のデータ
ベースの中、ユーザの要求によりいずれのデータベース
をアクセスするのかを判定する場合、人工知脳技術によ
りアクセスパターンを学習させ、学習の結果によりいず
れか一方を決定することにも特徴がある。さらに、（暢
）上記未更新状態にあるデータベースに更新デタ累禎情
報を反映させる場合、人工知脳技術によりアクセスパタ
ーンを学習させ、学習の結果により上記更新データ反映
予定時刻を設定することにも特徴がある。

〔作　　用１本発明においては、正系のデータベースと副系のデータ
ベースに多重化するとともに、更新データを一旦蓄積し
ておく更新データ累積情報ファイルを設けて、下記の方
法により処理を行う。

（イ）正系データベースに異常が生じたときには、正系
データベースをシステムがら切り離し、更新データ累積
情報を副系のデータベースに反映させて最新の更新状態
とした後、正系データベースとして処理する。

（口）データベースの更新要求に対しては、正系のデー
タベースを用いて更新処理を行い、かつ更新データを更
新データ累積情報ファイルに蓄積しておき、予定の期間
蓄積した後に副系データベースに反映させる。

（ハ）データベースの検索要求に対しては、更新データ
累積情報と副系データベースを用いて検索処理を行う。

このように、データベースの検索は副系データベースで
実行するので、通常のデータベースに比べ入出力に伴う
チャネル負荷が減少し、システム全体のスループットの
向上が図れる。また，デタベースの障害が生じたときに
は、副系のデータベースにより回復を行うので、従来の
システムのようにデータベースのバックアップにより回
復する方法に比べ、データベースの回復時間を短縮する
ことが可能である。

〔実施例Ｊ以下，本発明の一実施例を、図面により詳細に説明する
。

第１図は、本発明の一実施例を示すデータベス管理シス
テムの構成図である。

本発明のデータベース管理システムは、ユーザアプリケ
ーションプログラム（以下、ＵＡＰと記す）！００と、
データベースシステム１０と、正系のデータベース＋１
００と．副系のデータベース１　２００とから構成され
ている。ＵＡＰＩＯＯは、ユーザからのデータベース（
以下、ＤＢと記す）へのアクセス要求を処理するために
、データベースシステム１０に制御を渡す。データベー
スシステム１０は、ＤＢをシステム制御するＤＢ制御部
２００と、コンソール装置１１０から人力された副系Ｄ
Ｂｌ２００への出力要求を判断するＤＢ管理部４００と
，更新したデータを副系ＤＢＩ２００に出力する処理を
管理するＤＢ副管理部５００と、ＤＢ中のレコードを処
理するために一時蓄積するＤＢバッファ６００と、正系
ＤＢＩＩＯＯへの入出力要求を行うＤＩ３正Ｉ／Ｏ部９
００と、トランザクション内で発生した更新データを、
ＤＢの入出力単位に累積するトランザクション更新デー
タ累積バッファ７００と、ＤＢ更新データを副系ＤＢｌ
２００に反映させるまだの期１１７１を管理するＤＢ更
新データ反映間隔管理部３００と、ＤＢ更新データ反映
間隔管理部３００で管理した時間に達するまでは、トラ
ンザクション更新データ累積バッファ７００内に蓄積し
ておいた更新データを、トランザクション終了毎にコピ
ーしてまとめてお＜ＤＢ更新データ反映バッファ８００
と，更新したデータを副系ＤＢｌ２００に出力するため
のＤＢ副Ｉ／Ｏ部１　０００とで構成される。

正系ＤＢＩＩＯＯは、常に更新情報を反映し、最新のＤ
Ｂ状態を維持する。すなわち、更新要求が入力すると５
ＩＬちに正系ＤＢにのみ更新処理を実行する。

一方、副系ＤＢｌ２００は、更新データ反映間隔に達す
るまでは未更新状態であり、更新データ反映間隔に達し
た時点で更新情報を反映するために、正系ＤＢ　ｌ　＋
　００と同期がとられる。副系ＤＢに反映させるまでは
、更新データを累積バッファ７００および更新データ反
映バッファ８００に一時蓄積しておく。そして、コンソ
ール装置１１０からの検索要求が入力すると、検索処理
は全て副系ＤＢにより実行される。

第７図は、第１図の応用例を示すデータベースシステム
の構成図である。

ここでは、複数のユーザによりそれぞれトランザクショ
ンＡ，Ｂ，Ｃを処理する場合に、正系ＤＢを１系統設け
るとともに、副系ＤＢを複数のトランザクション毎に設
け、トランザクションＡ，Ｂ，Ｃ毎の累積バッファ７０
１〜７０３．反映バッファ８０１〜８０３により、各ト
ランザクション毎の更新データを副系ＤＢに反映させる
ようにする。コンソール装置１１１〜１１３は、ユーザ
毎に複数個設けてもよく、また１人のユーザが複数のト
ランザクションを実行する場合には、１個のコンソール
装ｒａ＋１０から複数のトランザクションを混在させて
実行することも可能である。

第２図は、第１図におけるｌ）　Ｂ制御部の処理フロー
チャートである。

ＤＢ制御部２００は、ＵＡＰＩＯＯからＤＢに対するＤ
Ｂアクセス要求を発行した時に、制御を受け取る制御部
である。このＤＢ制仰部２００は、ＵＡＰＩＯＯの命令
入力が終了したか否かを判断し（ステップ２０１）、Ｕ
ＡＰ終了であればＵＡＰ終了要求をセットする（ステッ
プ２２０）。次に、ＤＢ更新データ反映間隔管理部３０
０を呼び出す（ステップ２３０）。

第３図は、第１図におけるＤＢ更新データ反映間隔管理
部の処理フローチャートである。

ＤＢ更新データ反映間隔管理部３００では．現在時刻を
取得し（ステップ３１０）、更新データ反映予定時刻を
求める（ステップ３２０）。その後、現在時刻が更新デ
ータ反映間隔の時刻に達しているか否かをチェックし（
ステップ３３０）、その時刻に達していたならば反映す
る旨のリターンコード４を元に返す（ステップ３４０）
。また、時刻に達していないならば、反映しない旨のリ
ターンコードＯを元に返す（ステップ３５０）。

第２図に戻って、第３図からのリターンコード４または
０が戻されるため、反映コード４であれば（ステップ２
４０）、更新データ反映要求をセットする（ステップ２
５０）。その後、ＤＩ３？７理部４００を呼び、制御を
渡すくステップ２６０）。一方、反映しない旨のリター
ンコードＯであれば（ステップ２４０）、そのままＤＢ
管理部４００を呼び、制御を渡す（ステップ２６０）。

第４図は、第１図におけるＤＢ管理部の処理フローチャ
ートである。

ＤＢ管理部４００は、ＤＢ制御部２ｏＯから呼び出され
たとき、ＵＡＰ終了要求処理によってその後の処理が分
かれる（ステップ４ｌＯ）。Ｙ（同期点）、つまりＵＡ
Ｐ終了要求を行う場合には、ＤＢ副管理部５００を呼び
出す（ステップ４２０）。

また、Ｎ（ＤＢアクセス）、つまりＵＡＰ終了要求を行
わないときには、更新か検索の更新要求タイプかによっ
て処理が分かれる（ステップ４３０）。

すなわち、検索のときには、ＤＢ副管理部５００を呼び
出す（ステップ４６０）。また、更新の時には，更新し
たデータ内容を正系ＤＢに出力してから（ステップ４４
０）、ＤＢ副管理部５００を呼び出す（ステップ４５０
）。そして、その後、更新データ反映要求か否かをチェ
ックして（ステップ４７０）、要求を行うときには、Ｄ
Ｂ副管理部５００を呼び出す（ステップ４８０）。

結局、ＤＢ管理部４００では、ＵＡＰ終了要求があると
き、検索要求があるとき、更新要求があるとき、および
更新データ反映要求があるとき、の４つの場合にＤＢ副
管理部５００を呼び出すことになる。

第５図は、第１図におけるＤＢ副管理部の処理フローチ
ャートである。

ＤＢ副管理部５００は、ＤＢ管理部４００から呼び出さ
れると、要求のタイプ、つまりＵＡＰ終了要求、検索要
求、更新データ累積要求、および更新データ反映要求の
４つのタイプにより処理が分かれる（ステップ５１０）
。

先ず、ｔＪＡＰ終了要求では、１・ランザクション更新
データ累積バツファ７００からＤＢ更新データ反映バッ
ファ８００にデータ転送を行った後（ステップ５８０）
、管理情報をクリアする（ステップ５８５）。

また、検索要求の場合には（ステップ５ｌＯ）、トラン
ザクション更新データ累積バツファ７００に検索すべき
データが格納されているか否かを探し出す（ステップ５
５０）。もし、そこにデータが有れば（ステップ５５５
）、ＤＢバツファ６００にデータを転送する（ステツフ
５７５）。トランザクション更新データ累積バツファ７
００にデータが無ければ（ステップ５５５）、ＤＢ更新
データ反映バッファ８００にデータが格納されているか
否かを探し出す（ステップ５６５）。もしデータが有れ
ば、ＤＢバッファ６００にデータを転送する（ステップ
５７５）。もしデータが無ければ、ＤＢ副Ｉ／Ｏ部１０
００を呼び出し（ステップ５７０）．該当するデータを
読み出してＤＢバッファ６００に転送する（ステップ５
７５）。被検索データは、ＤＢバッファ６００からＤＢ
管理部４００，ＤＢ制御部３００を介してユーザに出力
される。

次に、更新データ累積要求であれば（ステップ５１０）
、トランザクション更新データ累積バッファ７００内に
更新すべきレコードがあるか否か探す（ステップ５２０
）。もし、そこに［］的のレコードがあれば（ステップ
５２５）、更新データをトランザクション更新データ累
積バッファ７００に重ねて格納する（ステップ５４５）
。また、目的とするレコードがなければ（ステップ５２
５）、トランザクション更新データ累積バッファ７００
の領域を確保し（ステップ５３０）、ＤＢ副Ｉ／Ｏ部ｌ
０００を呼び出す（ステップ５３５）。そして、副系Ｄ
Ｂ１２００から読み出した該当レコードをトランザクシ
ョン更新データ累積バッファ７００に転送し（ステップ
５４０）、更新データをトランザクション更新データ累
積バッファ７００に重ねて格納する（ステップ５４５）
。

次に、更新データ反映要求であれば（ステップ５１０）
，ＤＢ更新データ反映バッファ８００の先頭バッファに
位置付け（ステップ５９０）、そのバッファが出力すべ
きバッファであるか否か判定する（ステップ５９２）。

そうであれば、ＤＢ副■／０部１　０００を呼び出す（
ステップ５９５）。さらに、次のバッファに位置付けし
て（ステップ５９７），出力すべきバッファがなくなる
までこの動作を繰り返す（ステップ５９０〜５９７）。

また、更新データ反映バッファ中に出力すべきバツファ
がない場合には、処理を最初に戻す。

第６図は、第１図におけるＤＢ正（副）Ｉ／Ｏ部の処理
フローチャートである。

ＤＢ正（副）Ｉ／Ｏ部９００　（１０００）は、正（副
）系ＤＢＩＩＯＯへの出力が書き込みか、読み込みかの
要求タイプによって処理が分かれる（ステップ１１１０
および１　２　１　０）。

先ず、書き込みタイプの時には、ＤＢバッファ６００か
ら書き込みバッファを求めて（ステップｌ１５０および
１２５０）．正（副）系ＤＢＩＩ○Ｏに出力する（ステ
ップ１１６０および＋２６０）。

次に、読み込みタイプの時には、ＤＢバッファのうち空
きバッファを検出し（ステップ１１２０および１．２２
０）、正（副）系ＤＢＩＩＯＯから読み出したデータを
入力して（ステップ１１３０および１２３０　）、空き
バッファにそのＤＢレコードを転送する（ステップ１１
４０および１２４０）。

第８図は、第７図における複数の副系ＤＢを備えたデー
タベースに対して、トランザクション毎のアクセス要求
をデータベース順序のデータに並べ替える場合の説明図
である。

副系ＤＢは、先頭から順にａｌｌ　ａｌｌ　ａ．，　ａ
１１・・・・・・と各ボリューム毎に整列されており、
ａ，が副ＤＢ１２００に，ａ．が副ＤＢ］２０１に，ａ
，が副ＤＢｌ２０２に，・・・・それぞれ格納されてい
る場合、トランザクションＡにおいて、ａＩＩ　ａＩＩ
　ａＩのアクセス要求があり、トランザクションＢにお
いて、ａｌｌ　ａＩのアクセス要求があり、トランザク
ションＣにおいて、ａ．のアクセス要求があったときに
は、更新データ累積バッファを世代管理することにより
、時系列データベースを管理する。更新データ累積バッ
ファ７００，７０１，７０２，　　・・・と各副系ＤＢ
に対応して世代毎に配置しておけば、世代毎に管理する
ことが容易である。

以上が，本発明によるデータベース管理方法の基本動作
の説明である。

以下に、木グろ明の基本動作をまとめるとともに、応用
動作についても述べる。

（イ）本発明においては、ＤＢを多重化したシステムに
対して、副系ＤＢへの書き込みを、従来の書き込み時間
、つまり正系ＤＢと同時ないし正系ＤＢに書き込んだ直
後の時間より遅らせることによって、ＤＢアクセスレス
ポンスタイムを向上させることができる。すなわち、検
索要求を副系ＤＢに対してアクセスさせることにより、
書き込み時問中はアクセス不能となるので、書き込み時
間をなくして常時アクセス可能にしている。

（口）また、本発明においては、ＤＢの更新データ累積
情報を直ちに副系ＤＢに反映させないで、メモリ上に累
積していき、任意の間隔で副系ＤＢに反映させることが
できる。

（ハ）副系ＤＢに対して更新データの反映する間隔を指
定することができるようにし、指定された間隔に基づい
て副系ＤＢに更新データを反映させることができる。

（二）ＤＢの二重書きシステムにおいて、副系ＤＢに対
する書き込み更新データの反映時刻を任意に設定できる
ようにする。

（ホ）ＤＢ検索システムにおいて、ＤＢ検索時に先ずバ
ックアップファイルから読み出しすることにより、Ｉ／
Ｏの並列処理を可能とする。

（へ）Ｄ．Ｂのデータ更新の都度、更新データを累積し
てジャーナルに取得することも可能である。

（ト）Ｄ　Ｂの検索アクセスは、副系ＤＢから読み出し
、かつ更新データ累積バッファと合わせて探索するから
、高速検索が可能である。

（チ）ＤＢ検索要求時、複数の副系ＤＢに対して負荷の
軽いＤＢをアクセスすることにより、高速処理が可能で
ある（第７図および第８図参照）。

（り）更新データ累積バツファ７００を全てメモリ常駐
化することにより、更新データの反映が殆んど不要とな
るので，検索処理が高速に行える。

（ヌ）アクセス頻度が少ないものに対しては、更新デー
タ反映予定時刻を自動的に長くすることにより、反映処
理が少なくて済み，検索処理も高速に行える。

（ル）ジャーナルを不要にして、更新データを更新デー
タ累積バッファに蓄積することにより、故障の回復時に
は、ジャーナルからではなく、更新データ累積バッファ
のデータより回復な竹うので、回復時間が短縮できる。

（ヲ）更新データをメモリに蓄積していくと、メモリ容
量が不足するので、同一レコードについては累積してい
くようにする。

（ワ）人工知脳（以下、ＡＩと記す）（人間の知的作業
をコンピュータでシミュレートする）技術により、アク
セスパターンを学習し、正副系のいずれをアクセスする
かを決定する。すなわち、データ更新要求やデータ検索
要求等のパターンを学習させることにより、各制御部や
管理部の機能を簡単化することができる。

（力）ＡＩ技術によりアクセスパターンを学習し、更新
データ反映予定時刻を設定する。すなわち、アクセス頻
度により、世代毎の各副系ＤＢに対して反映間隔を決定
し、反映時刻を設定する。

（ヨ）ネットワークを介した重複ＤＢにおいて、直ちに
全てのノードに対して更新データを送出せずに、ノード
内で更新データ累積バッファに蓄積しておき、任意の更
新データ反映予定時刻に各ノードに送出するようにする
。すなわち、複数ノードがネットワークを介してデータ
ベースに接続されている場合に、更新データを直ちに各
ノードに通知せず、予め定めた間隔で更新データを送出
するようにする。

（タ）ＵＡＰ同期点までの更新データを累積する更新デ
ータ累積バッファを設けて、障害発生時、そのバッファ
をキャンセルするだけで回復ができるようにする。これ
により、ＵＡＰの論理障害時でもジャーナルを不要にで
きる。

（レ）物理障害時、副系ＤＢと更新データ累積バツファ
をもとにマージして、正系ＤＢを回復するので、ジャー
ナル入力処理が不要となる。

（ソ）累積データを複数世代に備えることにより、世代
管理を容易にすることができる（第７図および第８図参
照）。

（ツ）メモリに電池を付加し、かつ不揮発性メモリにす
ることにより、Ｍｉ源断または投入に関係なく、バック
アップを不要にすることができる。

（ネ）ＤＢの多重化を銀行オンラインシステムに適用す
ることにより、高信頼性と高速レスポンスタイムの要求
に応じることができる。

（ナ）同一レコードを多数回更新することにより、大量
のジャーナルが発生する特定データ更新処理システムに
本発明を適用すれば、極めて有効である。

（ラ）更新データ累積バッファを世代管理することによ
り、時系列データベースを管理することが可能である。

〔発明の効果］以」一説明したように、本発明によれば、ＤＢの物理障
害に対して、ユーザが指定する更新データ反映間隔分の
更新データと副系ＤＢのデータを用いて回復することが
できるので、従来のバッグアップとジャーナルによる回
復時間より短縮することができる。また、ＤＢの検索要
求に対して，副系ＤＢを用いて処理するので、一般のＤ
Ｂに比べてＤＢの入出力に対するチャネル負荷を分散す
ることができ、ＤＢシステム全体のスルーブットを向上
させることができる。

【図面の簡単な説明】

第１図は本発明の一実施例を示すデータベース管理シス
テムの構成図、第２図は第１図のＤＢ制御部の処理フロ
ーチャート、第３図は第１図におけるＤＢ更新データ反
映間隔管理部の処理フローチャート、第４図は第１図に
おけるＤＢ管理部の処理フローチャート、第５図は第１
図におけるＤＢ副管理部の処理フローチャート、第６図
は第１図における正（副）系ＤＢのＩ／Ｏ部の処理フロ
チャート、第７図は本発明の他の実施例を示すデータベ
ース管理システムの構成図、第８図は第７図における更
新デ〜タの世代管理の方法を示す図である。ｌＯ：データベース（ＤＢ）システム、＋００：ユーザ
アプリケーションプログラム（ＩＪＡＰ）、１１０ニコ
ンソール装置、２００：ＤＢ制御部、３００：ＤＢ更新
データ反映間隔管理部、４００：ＤＢ’？？理部，５０
０：ＤＢ副管理部、６００：ＤＢバッファ，７００，７
０１，７０２：　トランザクション更新データ累積バッ
ファ、８００，８０１，８０２：ＤＢ更新データ反映バ
ッファ、９００：ＤＢ正Ｉ／Ｏ部，１０００：ＤＢ副Ｉ
／Ｏ部、ｌｌＯＯ；正系ＤＢ，１２００，１２０１，１
２０２：副系ＤＢ．第図第図第図第図

Claims

【特許請求の範囲】１、予定の時点で同一内容を持つような複数のデータベ
ースシステムの管理方法において、第１のデータベース
は常時最新の更新状態にあり、残りの第２のデータベー
スは未更新状態にあり、かつデータを更新する毎に更新
データ累積情報としてメモリに累積しておき、最新の更
新状態にある上記第１のデータベースに障害が発生した
ときには、該第１のデータベースをシステムから切り離
し、未更新の上記第２のデータベースに上記更新データ
累積情報を反映して、最新の更新状態にした上で、それ
以降のユーザの更新要求に対して上記第２のデータベー
スが処理することを特徴とするデータベース管理方法。２、予定の時点で同一内容を持つような複数のデータベ
ースシステムの管理方法において、上記データベースの
更新データを直ちに反映せずに、該更新データをメモリ
上に累積していき、該メモリ上の更新データを予定の周
期で上記データベースに反映させ、各データベース相互
間の同期処理を行うことを特徴とするデータベース管理
方法。３、予定の時点で同一内容を持つような複数のデータベ
ースシステムの管理方法において、第１のデータベース
が常に最新の更新状態にあり、残りの第２のデータベー
スは予定の期間だけ未更新状態にあり、かつデータの更
新毎に更新データ累積情報としてメモリに累積していく
場合、ユーザのデータベース検索要求に対して、最新の
更新状態にある上記第１のデータベースで処理するか、
あるいは未更新状態にある上記第２のデータベースと上
記更新データ累積情報を基に処理するか、いずれか一方
を実行することを特徴とするデータベース管理方法。４、上記ユーザのデータベース検索要求に対して、第１
および第２のデータベースの中で、データベースのＩ／
Ｏ負荷が軽い方のデータベースを用いて処理することを
特徴とする請求項３記載のデータベース管理方法。５、上記更新データ累積情報は、ユーザ業務の作業単位
であるトランザクションの開始から終了までの更新デー
タをデータベースＩ／Ｏ単位に累積したものであり、該
更新データ累積情報を基に未更新データベースに反映処
理を行うことを特徴とする請求項３記載のデータベース
管理方法。６、上記更新データ累積情報を、未更新状態にあるデー
タベースに反映する場合、反映する間隔をユーザが任意
に指定し、該データベースに反映処理を行う時間以外の
時間にはユーザのデータ検索要求に対する処理を行わせ
ることを特徴とする請求項３記載のデータベース管理方
法。７、上記第１および第２のデータベースの中、ユーザの
要求によりいずれのデータベースをアクセスするのかを
判定する場合、人工知脳技術によりアクセスパターンを
学習させ、学習の結果によりいずれか一方を決定するこ
とを特徴とする請求項３または４記載のデータベース管
理方法。８、上記未更新状態にあるデータベースに更新データ累
積情報を反映させる場合、人工知脳技術によりアクセス
パターンを学習させ、学習の結果により上記更新データ
反映予定時刻を設定することを特徴とする請求項３また
は６記載のデータベース管理方法。