JP3741388B2 - データベースの予約アクセス処理方法 - Google Patents
データベースの予約アクセス処理方法 Download PDFInfo
- Publication number
- JP3741388B2 JP3741388B2 JP23472795A JP23472795A JP3741388B2 JP 3741388 B2 JP3741388 B2 JP 3741388B2 JP 23472795 A JP23472795 A JP 23472795A JP 23472795 A JP23472795 A JP 23472795A JP 3741388 B2 JP3741388 B2 JP 3741388B2
- Authority
- JP
- Japan
- Prior art keywords
- reservation
- update
- record
- time
- access
- 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
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【産業上の利用分野】
本発明は、複数レコードの一括更新ならびに同時参照を行なうデータベースシステムに関し、特に複数のレコードへのアクセスを該複数のレコードの共用排他制御を行なわずに実行することが要求されるオンラインデータベース処理システムにおける予約アクセス処理方法に関する。
【０００２】
【従来の技術】
情報化社会の発達により、銀行のオンラインシステム等の大容量のデータを保持するオンラインデータベースシステムが構築されてきた。オンラインデータベースシステムでは、テーブルのレコードに対する参照、更新がオンラインで頻繁に行なわれる。
【０００３】
特に、銀行口座の統計情報の取得や、利息計算に基づく口座残高の更新、あるいはデータのバックアップ等の大量レコードの更新及び参照を行なう大規模バッチ処理は、データベースのテーブル全体を長時間排他確保することが必要なため、オンラインシステムを停止している間に行なう必要があった。ところが、近年のデータベースの大容量化、ならびに、オンラインシステムの稼働時間延長への要求は、上記大規模バッチ処理をシステム停止時間に行なうという方法を不可能にしつつある。
【０００４】
これらの問題を解決するために、従来はシステムを２重化して、一方をオンライン用に、他方を大規模バッチ処理用に用いて、適当なタイミングで整合性を取る方法や、データのバックアップを定期的に取り、統計情報の作成等の参照系の大規模バッチ処理はバックアップデータに対して行なう方法等が用いられてきた。また、データのバージョンを複数管理することにより、過去のある時点における一貫性のあるデータに対してアクセスする機能を提供するデータベースのバージョン管理方式等が提案されてきた。
【０００５】
特に、データベースのバージョン管理方式等は、種々の方法が提案されている。例えば、特開平６−２８３１５号では、トランザクション処理と参照アクセス処理を相互干渉させることなく効率的に並列実行するための方法が開示されている。すなわち、この公知例では、データベースの各頁について有限数の論理バージョンを保持し、これらをタイムスタンプにより管理し、また現在進行中のトランザクションを管理するテーブルおよびシステム状態を表現する情報を記憶することにより、トランザクション進行中のテーブルに対する照会アクセスを、該トランザクションを停止することなく、より新しいバージョンのデータベースにアクセスすることを可能にしている。このようなデータベースのバージョン管理方式は、データの更新を伴うトランザクション処理と大量データの参照を行う参照系バッチ処理を並列に実行する際に有効な技術である。
【０００６】
【発明が解決しようとする課題】
上述したように、従来のオンラインシステムでは、大規模バッチ処理を実行する際に、システムを停止するか、システムを２重化するか、あるいは、データのバックアップまたは複数のデータのバージョンを取るかの方法を取っていた。
【０００７】
しかしながら、オンラインシステムを停止させその停止中に処理するという方法では、システムの２４時間連続運転を不可能にするという大きな問題点がある。
【０００８】
また、システムを２重化して一方をオンラインシステム用に、他方を大規模バッチ処理用に適用する方法では、それぞれのデータの一貫性を保証することが困難であり、オンラインで逐次更新されているデータを直接参照したい場合には適用不可能である。また、大規模バッチ処理用のシステムで実行した更新系の処理結果は、オンラインシステム用と大規模バッチ処理用のシステム間のデータの整合性を取った後でなければオンラインシステム側で読み取ることができないという問題がある。
【０００９】
さらに、データのバックアップを活用して大規模バッチ処理を実行する方法では、データのバックアップ処理自身が大規模参照系バッチ処理であり、バックアップ処理のためのテーブルの排他制御が必要であるという問題点がある。
【００１０】
また、データベースのバージョン管理を行なう方法では、トランザクション処理と参照系のバッチ処理を並行に処理する場合には有効であるが、トランザクション処理と更新系のバッチ処理を並行に処理することは不可能であり、また参照系のバッチ処理に関しても、より新しいデータベースにアクセスすることはできるものの、ある時刻の正確な統計情報を得ることは不可能であるという問題点があった。さらに、データベースの複数のバージョンを常に保持するため、大容量の記憶装置が必要になるという問題点があった。
【００１１】
本発明は、大量レコードの更新や参照を、当該レコードの排他制御を同時に確保せずに個々のレコード単位の排他制御により実行する方法を提供することを目的とする。
【００１２】
本発明の他の目的は、大量レコードの更新を論理的には指定された時刻に同時に行なったようにデータベースのユーザに対して見せる機能を提供することにある。
【００１３】
さらに本発明の他の目的は、指定された時刻における大量レコードの参照を必要最小限のデータのバックアップのみで実現する機能を提供することにある。
【００１４】
また本発明の他の目的は、一つのレコードに対して複数の予約アクセス登録を可能とする機能を提供することにある。
【００１５】
本発明の他の目的は、予約アクセス処理が失敗した場合に、該予約アクセス処理全体を取り消すことを可能とする機能を提供することにある。
【００１６】
【課題を解決するための手段】
本発明に係る予約アクセス処理方法では、複数のレコードの更新をあらかじめ予約することにより、該予約された更新を指定された予約更新時刻に論理的に同時に実行するための方法を提供する。この予約更新処理は、当該レコードの更新を予約登録するための予約更新前処理と、予約更新時刻以降の当該レコードへの最初のアクセス時に行なわれる予約更新後処理とで実行される。予約更新前処理においては、前記データベーステーブルの各レコードに１対１に対応した予約更新時刻と予約情報とで構成される予約更新情報に該レコードの予約更新時刻ならびに更新内容を格納する。そして、データベースへのレコードのアクセス時には、該レコードに対する予約更新登録の有無及び現時刻と予約更新時刻との比較を行ない、該レコードに対応する予約更新登録があり、かつ、現時刻が予約更新時刻以降であれば予約更新後処理を実行してから当該レコードに対するアクセス処理を実行し、予約更新登録がない場合、もしくは、現時刻が予約更新時刻以前であれば予約された更新は行なわずに該レコードに対するアクセス処理を実行する。そして、予約更新後処理においては、当該レコードに登録されている更新を実行して該予約更新登録を削除する。
【００１７】
前記予約更新時刻以降に、前記予約更新後処理ステップを前記更新予約されたレコードのすべてに関して実行するクリーンナップ処理を行なうようにしてもよい。また、前記予約更新前処理ステップで予約更新登録を実行している途中で、現時刻が該予約更新登録の予約更新時刻を過ぎてしまった場合には、該予約更新処理の状態を予約更新前処理取消状態に設定し、それまでに予約更新登録した全てのレコードの予約更新情報を削除すると共に、前記予約更新後処理ステップを実行する際には、当該予約更新処理の状態を確認して、該状態が予約更新前処理取消であった場合には該予約更新登録を破棄するようにする。予約更新処理の状態は、例えば予約アクセス状態を管理するテーブルを設けることにより管理するとよい。
【００１８】
さらに、本発明に係る予約アクセス処理方法では、複数のレコードの参照をあらかじめ予約することにより、該複数のレコードの共用排他アクセス権の確保を同時に確保することなく、該予約参照時刻に全てのレコードの参照を実行するための方法を提供する。予約参照処理は、当該レコードの参照を予約登録するための予約参照前処理と、予約参照時刻以降に実行される予約参照後処理と、予約参照時刻以降かつ予約参照後処理以前の間に発生する当該参照レコードへの更新処理時に実行される予約参照バックアップ処理とで実行される。予約参照前処理においては、前記データベーステーブルの各レコードに１対１に対応した予約参照時刻と予約情報とで構成される予約更新情報に該レコードの予約参照時刻ならびに参照内容を格納する。そして、データベースへのレコードの更新アクセス時には、該レコードに対する予約更新登録の有無及び現時刻と予約更新時刻との比較を行ない、該レコードに対応する予約参照登録があり、かつ、現時刻が予約参照時刻以降であれば予約参照バックアップ処理を実行して当該レコードのデータのバックアップを作成してから当該レコードに対する更新アクセス処理を実行し、予約参照登録がない場合、もしくは、現時刻が予約参照時刻以前であれば予約参照バックアップ処理は行なわずに該レコードに対する更新アクセス処理を実行する。また、予約参照時刻以降にタイマ割り込み等により起動される予約参照後処理においては、当該レコードのバックアップデータが作成されている場合にはバックアップデータを参照してから該バックアップデータ及び該予約参照登録を削除し、バックアップデータが存在しない場合には当該レコードの内容を直接参照してから該予約参照登録を削除する。
【００１９】
前記予約参照前処理ステップで予約参照登録を実行している途中で、現時刻が該予約参照登録の予約参照時刻を過ぎてしまった場合には、該予約参照処理の状態を予約参照前処理取消状態に設定し、それまでに予約参照登録した全てのレコードの予約参照情報を削除すると共に、前記予約参照バックアップ処理ステップ及び前記予約参照後処理ステップを実行する際には、当該予約参照処理の状態を確認して、該状態が予約参照前処理取消であった場合には該予約参照登録を破棄するようにする。予約参照処理の状態は、例えば予約アクセス状態を管理するテーブルを設けることにより管理するとよい。
【００２０】
さらに、前記予約更新登録又は前記予約参照登録において格納する予約更新情報又は予約参照情報に、次の予約更新情報又は予約参照情報へのポインタを設け、一つのレコードに対して複数の予約アクセスを登録するようにしてもよい。
【００２１】
【作用】
本発明の予約更新処理における予約更新前処理ならびに予約更新後処理においては、現在処理中のレコードに関連する排他制御処理のみを行なえばよく、更新するレコード全体の排他制御を同時に行なう必要はない。このため、大量レコードの更新を個々のレコード単位のロックのみで実現することが可能となった。
【００２２】
また、予約更新登録されたレコードの更新処理は予約更新時刻以降の最初の当該レコードに対するアクセス処理時に行なわれるため、予約更新時刻には実際にはデータベースの更新は行わない。このため、全てのレコードの更新処理を一瞬にして実行したようにユーザに対して見せることが可能となった。
【００２３】
一方、本発明の予約参照処理における予約参照前処理、予約参照バックアップ処理ならびに予約参照後処理においては、現在処理中のレコードに関連する排他制御処理のみを行なえばよく、参照するレコード全体の排他制御を同時に行なう必要はない。このため、大量レコードの更新を個々のレコード単位のロックのみで実現することが可能となった。
【００２４】
また、予約参照されたレコードの参照処理は予約参照時刻以降にタイマ割り込み等により起動された予約参照後処理により実行される。予約参照時刻には実際にはデータベースの参照処理は行わないので、全てのレコードの参照処理を一瞬にして実行したようにユーザに対して見せることが可能となった。
【００２５】
また、予約参照登録されたレコードのバックアップは、指定された予約参照時刻以降でかつ当該レコードの予約参照後処理がまだ実行されていない場合に当該レコードに対して更新処理が行なわれた場合のみ実行されるため、一貫性のあるデータの参照を実現するために必要なデータのバックアップを最小限にすることが可能となった。さらに、これらのバックアップデータは、予約参照後処理実行時に削除されるため、システム全体のデータベース容量のオーバヘッドを低減することが可能となった。
【００２６】
さらに本発明では、一つのレコードに対して複数の予約アクセス登録を可能にすることで種々のシステムに対して本機能を提供することが可能となった。
【００２７】
また、本発明では、予約アクセス状態を管理するテーブルを設けることにより、予約アクセス前処理が予約アクセス時刻までに完了しなかった場合に該予約アクセス処理を取り消すための機能を提供することが可能となった。
【００２８】
【実施例】
以下、図面を用いて本発明の実施例を説明する。
【００２９】
図２３は、本発明を実施するデータベースシステムの構成を示す図である。本システムは、データベースをアクセスする複数の端末３００，３０１と、データベースをアクセスする一つ以上のアプリケーションサーバ３０３，３０４と、データベースを保持するデータベースサーバ３０２とで構成される。データベースサーバ３０２は、データベースシステム３０５およびデータベース３０８で構成される。データベースシステム３０５は、アプリケーションから発行されるＳＱＬ（Structured Query Language）などの問い合わせ処理の実行を制御する問い合わせ実行制御部３０６とデータベースをアクセスするデータベースアクセス部３０７とで構成される。本図ではデータベースサーバ３０２とアプリケーションサーバ３０３，３０４とが異なるプロセッサ上に実装されている図を示しているが、アプリケーションサーバとデータベースサーバは同一プロセッサ上に実装してもよい。また、データベースシステムは、単一のプロセッサで動作する通常のデータベースシステムだけでなく、複数のプロセッサ上で動作する並列データベースシステムであってもよい。
【００３０】
今、端末３０１でデータベースのテーブルを一括更新しようとしており、端末３００でテーブルを参照しようとしているとする。具体的な例で説明すると、アプリケーションサーバ３０４は給与振込みプログラム、アプリケーションサーバ３０３は残高照会プログラムであり、端末３０１から社員口座に給与振込を行なおうとしており、端末３００からある人が自分の口座の残高照会を行なおうとしている、と言った状況である。本発明では、このような状況のときに、一括更新処理の時刻を指定することによりデータベースの更新時刻のずれをなくし、一貫性のあるデータに参照するための手段を提供する。本発明による新しいデータベースアクセス方法は、図２３のデータベースシステム内部の問い合わせ実行制御部３０６とデータベースアクセス部３０７に実装される。以下の説明では、各実施例にしたがって、新しいデータベースアクセス方法を説明する。
【００３１】
［実施例１］
実施例１では、データベースの予約更新処理を提供するための方法について説明する。
【００３２】
図１(a) は、本実施例における予約更新処理の概要を説明する図である。横軸は時刻の流れを示し、黒い四角は各時刻において実行される処理を示している。予約更新処理は、レコードの更新を予約登録するための予約更新前処理(1) と、予約更新時刻(5)以降に行なわれる予約更新後処理(2) の２つの処理で実現される。
【００３３】
予約更新前処理(1) が完了したレコードに対して、予約更新時刻(5)以前にアクセスする場合には更新前のデータを提供し(3) 、更新時刻(5)より後で該レコードにアクセスする場合には予約更新後処理(2) を行ない予約されていた更新処理を実行してから更新後のデータを提供する(4) 。
【００３４】
このように、レコードの更新を更新時刻以降の最初のアクセスまで遅延させることにより、予約更新時刻にはレコードの更新処理を実行せずに(5) 、該予約更新時刻に全てのレコードの更新が同時に実行されたように論理的に見せることが可能となる。
【００３５】
図１(b) は、予約更新処理を実現するためのテーブル構造を示す図である。口座テーブル(6)及び支店テーブル(7)はアプリケーションが作成したデータベーステーブル（ＤＢテーブル）であり、予約更新テーブル(8)及び予約管理テーブル(9)は予約更新処理を実現するためにデータベースシステムが作成したテーブルである。
【００３６】
アプリケーションが作成したＤＢテーブルのうち、アプリケーションからは、破線で囲った部分(10)のみ直接アクセスすることができる。予約更新時刻(11及び15)とアクセスＩＤ(12及び16)は、予約更新処理を実現するためにデータベースシステムが付加した列である。ＤＢテーブルに付加した列のうち、予約更新時刻(11及び15)には、各レコードの予約更新時刻が格納される。予約更新時刻(11及び15)に何も格納されていない場合には、該レコードに対して更新の予約処理が登録されていないことを示す。アクセスＩＤ(12及び16)には、予約更新テーブル(8)にアクセスするための識別子が格納される。
【００３７】
予約更新テーブル(8)は、データベースシステム内に１つ存在し、アクセスＩＤ(13)と、予約情報(14)とで構成される。アクセスＩＤ(13)は、予約更新テーブル(8)内でユニークな識別子であり、ＤＢテーブル(6及び7)と予約更新テーブル(8)との対応を取る。予約情報(14)には、予約された更新処理の予約ＩＤ及び更新処理内容が記述される。
【００３８】
予約管理テーブル(9)は、データベースシステム内に１つ存在し、予約ＩＤ(17)、予約状態(18)、及び、予約更新時刻(19)とで構成される。予約ＩＤ(17)は、論理的に同時に実行すべき予約更新処理１つにつき１つ付与される番号であり、データベースシステム内でユニークな番号である。予約状態(18)は、前記同時に実行すべき予約更新処理の処理状態を示す。処理状態としては、予約更新前処理開始、予約更新前処理取消等がある。予約更新前処理開始は、当該予約更新の前処理を行なっている最中であることを示し、予約更新前処理取消は、当該予約更新の前処理が予約時刻までに終了しなかったため、既に登録している予約更新情報を取消中であることを示す。一方、予約更新時刻(19)は、予約更新を実行する時刻を格納している。
【００３９】
本実施例で示している予約更新は、予約ＩＤ(17)がR0050、更新時刻(19)が1992/06/10 9:00であり、現在予約更新前処理中であり、予約された更新内容としては、口座テーブル(6)の口座番号670190048のレコードの残高に200,000を加算し、口座番号670190049のレコードの残高に300,000を加算し、というようになっている。
【００４０】
本実施例で示したテーブル構造ではＤＢテーブル(6及び7)と予約更新テーブル(8)の対応や予約更新テーブル(8)と予約管理テーブル(9)との対応を取るために識別子を用いているが、ポインタ等を用いてこれらの対応を取ることももちろん可能である。
【００４１】
図２は、本実施例における予約更新前処理の流れを示す図である。予約更新前処理（２０）では、まず予約ＩＤを取得して、予約管理テーブル(9)へ該予約ＩＤならびに予約時刻の登録を行なう（ステップ２１）。予約ＩＤは、データベースシステム内でユニークな識別子である。次に、予約管理テーブル(9)の予約状態を予約更新前処理開始に設定して（ステップ２２）、全ての更新レコードについて、以下の処理を実行する。
【００４２】
まず、更新すべきレコードの内容を後述のデータベースアクセス処理（ＤＢアクセス処理）により取得する（ステップ２３）。次に、該レコードの予約更新時刻フィールド(11又は15)を確認して、既に他の予約更新が登録されているか否か判定する（ステップ２４）。既に他の予約更新が登録されていたならば、エラー処理（ステップ２９）に制御を移す。他の予約更新が登録されていない場合には、登録中の予約更新処理の予約時刻を既に過ぎていないかをチェックし（ステップ２５）、もし予約時刻を過ぎていた場合には、当該予約更新前処理が予定時刻に間に合わなかったとしてエラー処理（ステップ２９）に制御を移す。
【００４３】
ステップ２５で予約時刻を過ぎていない場合には、予約情報を予約更新テーブル(8)に登録して（ステップ２６）、次の更新レコードの処理に移る（ステップ２７）。全ての更新レコードの予約情報の登録が完了したならば（ステップ２７）、予約管理テーブル(9)から該予約更新に対応するエントリを削除して（ステップ２８）、処理を終了する。
【００４４】
一方、各レコードの予約情報の登録中にエラーが発生した場合には、まず予約管理テーブル(9)の状態を予約更新前処理取消に設定して、該予約更新前処理で登録した全ての予約情報をテーブルから削除し、最後に予約管理テーブル(9)の状態を予約更新前処理失敗に設定してエラーリターンする（ステップ２９）。
【００４５】
図３は、本実施例におけるデータベースアクセス処理（ＤＢアクセス処理）の流れを示す図である。ＤＢアクセス処理は、レコードの参照処理及びレコードの更新処理の両方を包含する。
【００４６】
ＤＢアクセス処理（３０）では、まずアクセス対象のレコードをＤＢテーブル(6又は7)から取得し（ステップ３１）、そのレコードの予約更新時刻(11又は15)が登録されており、かつ、現時刻が該予約更新時刻を過ぎているか否かを判定する（ステップ３２）。予約更新時刻を過ぎていたならば、該レコードのアクセスＩＤをキーにして予約更新テーブル(8)から予約情報(14)を取得し（ステップ３３）、該予約情報(14)に基づき後述の予約更新後処理を行ない（ステップ３４）、その後、該レコードのＤＢアクセス処理を実行する（ステップ３５）。
【００４７】
ステップ３２でアクセス対象のレコードの予約更新時刻が登録されていない場合や、該レコードの予約更新時刻がまだ過ぎていない場合には、予約更新後処理は行なわずに現在のレコードに対してＤＢアクセス処理（ステップ３５）を行なう。
【００４８】
図４は、本実施例における予約更新後処理の流れを示す図である。予約更新後処理（４０）では、まず、予約管理テーブル(9)を予約ＩＤで検索して（ステップ４１）、予約管理テーブル(9)の状態(18)を確認する（ステップ４２）。予約管理テーブル(9)の状態(18)が予約更新前処理取消以外であれば、予約情報(14)に従って当該レコードの更新処理を行ない（ステップ４３）、その後、予約更新テーブル(8)から該予約情報(14)を削除する（ステップ４４）。予約管理テーブル(9)の状態(18)が予約更新前処理取消である場合には（ステップ４２）、当該レコードの更新は行なわずに予約更新テーブル(8)から予約情報(14)を削除して（ステップ４４）、予約更新後処理を終了する。
【００４９】
本実施例では、予約更新されたレコードは、予約更新時刻以降に該レコードに対してＤＢアクセスが起こらないかぎり更新されることはない。しかしながら、通常のデータベースシステムにおいては、定期的にバックアップ作業を行なっているため、該バックアップ作業の際にＤＢアクセスが発生し、当該レコードの予約更新後処理が実行される。バックアップを取らないシステムにおいては、予約更新処理を終了させるために一定期間毎に全データベースをアクセスするクリーンナップ処理を実行することにより、予約更新後処理を実行させることができる。
【００５０】
本実施例では、ＤＢテーブルに予約更新時刻フィールドを設け、ＤＢアクセス処理時に予約更新時刻と現時刻の関係により予約更新を行なうか行なわないかを決定する処理を設けたことに特徴がある。これにより、予約更新時刻にＤＢをアクセスすることなく、アプリケーションからは、該予約更新時刻にあたかも全レコードが同時に更新されたように論理的に見える機能を提供することが可能となった。
【００５１】
また、全ての処理はテーブルのレコード単位の排他制御を用いて実現できるため、システム稼働中にも大量のレコードの一括更新を行なうことが可能である。また、予約更新前処理が完了しないうちに予約時刻を過ぎてしまった場合の予約更新情報の取り消し手段を有することも本実施例の特徴の一つである。
【００５２】
本実施例は、リレーショナル型のデータベースシステムのみならず、構造型あるいは階層型のデータベースシステム等の、レコードを単位としてアクセスするあらゆるデータベースに適用できることは明らかである。
【００５３】
［実施例２］
次に、本発明の第２の実施例を説明する。この実施例２では、データベースの予約参照処理を提供するための方法について説明する。
【００５４】
図５(a)は、本実施例における予約参照処理の概要を説明する図である。横軸は時刻の流れを示し、黒い四角は各時刻において実行される処理を示している。予約参照処理は、レコードの参照を予約登録するための予約参照前処理(51)と、参照時刻(56)以降に行なわれる予約参照後処理(52)、および、参照時刻(56)以降かつ予約参照後処理(52)以前の間に発生するＤＢ更新処理時に行なわれる予約参照バックアップ処理(53)の３つの処理で実現される。
【００５５】
予約参照前処理(51)が完了したレコードに対して、予約参照時刻(56)以前に該レコードを更新する場合には通常通り更新処理を行ない(54)、参照時刻(56)より後かつ予約参照後処理(52)以前に該レコードの更新処理を行なう場合には予約参照バックアップ処理(53)を行ない予約参照されていたレコードのバックアップを作成してから当該レコードの更新処理を行なう(55)。
【００５６】
予約参照後処理(52)では、参照レコードのバックアップが作成されている場合には該バックアップデータを参照し、バックアップがない場合には該レコードのデータを参照する。予約参照後処理(52)は、予約参照時刻(56)以降の適当なタイミングで実行する。予約参照後処理(52)を起動するタイミングは、参照時刻(56)以降にタイマにより起動をかける方法や、参照時刻(56)以降の最初のＤＢアクセス発生時点等、様々な方法により実現することができる。
【００５７】
本実施例では、予約参照後処理以前に更新が行なわれるレコードのみバックアップを作成することにより、予約参照時刻にはレコードの参照処理を実行せずに(56)、該予約参照時刻に全てのレコードの参照が同時に実行されたように論理的に見せることが可能となる。
【００５８】
図５(b)は、予約参照処理を実現するためのテーブル構造を示す図である。口座テーブル(500)及び支店テーブル(501)は、アプリケーションが作成したデータベーステーブル（ＤＢテーブル）であり、予約参照テーブル(502)、バックアップテーブル(503)及び予約管理テーブル(504)は予約参照処理を実現するためにデータベースシステムが作成したテーブルである。
【００５９】
アプリケーションが作成した ＤＢテーブルのうち、アプリケーションからは、破線で囲った部分(505)のみ直接アクセスすることができる。予約参照時刻(506及び508)とアクセスＩＤ(507及び509)は、予約参照処理を実現するためにデータベースシステムが付加した列である。ＤＢテーブルに付加した列のうち、予約参照時刻(506及び508)には、各レコードの予約参照時刻が格納される。予約参照時刻(506及び508)に何も格納されていない場合には、該レコードに対して参照の予約処理が登録されていないことを示す。アクセスＩＤ(507及び509)には、予約参照テーブル(502)にアクセスするための識別子が格納される。
【００６０】
予約参照テーブル(502)は、データベースシステム内に１つ存在し、アクセスＩＤ(510)と、予約情報(511)とで構成される。アクセスＩＤ(510)は、予約参照テーブル(502)内でユニークな識別子であり、ＤＢテーブル(500及び501)と予約参照テーブル(502)の対応を取る。予約情報(511)には、予約された参照処理の予約識別子及びバックアップ識別子が記述される。バックアップ識別子（ＩＤ）は、バックアップが存在する場合のバックアップＩＤを示し、予約参照テーブル(502)のエントリとバックアップテーブル(503)のエントリの対応を取る。予約情報(511)中のバックアップＩＤがNULL値（初期値）のときは、未だ当該レコードのバックアップを取っていないことを示す。
【００６１】
バックアップテーブル(503)は、データベースシステム内に一つ存在し、バックアップＩＤ(512)とバックアップデータ(513)とで構成される。バックアップＩＤ(512)は、バックアップテーブル(503)内でユニークな識別子である。バックアップデータ(513)には、予約参照時刻以降に更新されるレコードのバックアップ（更新する前のレコードのバックアップ）を格納する。本実施例ではバックアップはレコード単位で格納しているが、参照されるフィールドのみのバックアップを取ることももちろん可能である。
【００６２】
予約管理テーブル(504)は、データベースシステム内に１つ存在し、予約ＩＤ(514)、予約状態(515)、予約参照時刻(516)、及び、予約実行文(517)とで構成される。予約ＩＤ(514)は、論理的に同時に実行すべき予約参照処理１つにつき１つ付与される番号であり、データベースシステム内でユニークな番号である。予約状態(515)は、前記同時に実行すべき予約参照処理の処理状態を示す。処理状態としては、予約参照前処理開始、予約参照前処理完了、予約参照前処理取消等がある。予約参照前処理開始は、当該予約参照の前処理を行なっている最中であることを示し、予約参照前処理完了は、当該予約参照の前処理が正常終了したことを示し、予約参照前処理取消は、当該予約参照の前処理が予約時刻までに終了しなかったため、既に登録している予約参照情報を取消中であることを示す。一方、予約参照時刻(516)には、予約参照を実行する時刻が格納され、予約実行文には予約された参照実行文（問い合わせ実行文又は問い合わせ実行コード）が格納される。
【００６３】
本実施例で示している予約参照は、予約ＩＤ(514)がR0119、参照時刻(516)が1992/06/10 7:00であり、現在予約参照前処理完了しており、口座テーブル(500)の口座番号670191000のレコード、670191001のレコード、及び、支店テーブル(501)の支店番号670191のレコードがそれぞれ予約参照登録されている。また、口座テーブル(500)の口座番号670191000及び支店テーブル(501)の支店番号670191のレコードは予約参照時刻以降に更新処理が行なわれたため、バックアップテーブル(503)に予約参照時刻の時点におけるレコードの内容が保存されている。
【００６４】
本実施例で示したテーブル構造ではＤＢテーブルと予約参照テーブルの対応や予約参照テーブルと予約管理テーブル、あるいは、予約参照テーブルとバックアップテーブルの対応を取るためにそれぞれ識別子を用いているが、ポインタ等を用いてこれらの対応を取ることももちろん可能である。
【００６５】
図６は、本実施例における予約参照前処理の流れを示す図である。予約参照前処理（６０）では、まず予約ＩＤを取得して、予約管理テーブル(504)へ該予約ＩＤ、予約時刻および予約実行文の登録を行なう（ステップ６１）。次に、予約管理テーブル(504)の予約状態を予約参照前処理開始に設定して（ステップ６２）、全ての参照レコードについて、以下の処理を実行する。
【００６６】
まず、参照すべきレコードの内容を取得する（ステップ６３）。次に、該レコードの予約参照時刻フィールド(506又は508)を確認して、既に他の予約参照が登録されているか否か判定する（ステップ６４）。既に他の予約参照が登録されていたならば、エラー処理（ステップ６９）に制御を移す。他の予約参照が登録されていない場合には、登録中の予約参照処理の予約時刻を既に過ぎていないかをチェックし（ステップ６５）、もし予約時刻を過ぎていた場合には、当該予約参照前処理が予定時刻に間に合わなかったとしてエラー処理（ステップ６９）に制御を移す。
【００６７】
ステップ６５で予約時刻を過ぎていない場合には、予約情報を予約参照テーブル(502)に登録して（ステップ６６）、次の参照レコードの処理に移る（ステップ６７）。なお、予約情報(511)のバックアップＩＤは、NULL値（バックアップデータなし）に初期設定する。
【００６８】
全ての参照レコードの予約情報の登録が完了したならば（ステップ６７）、予約管理テーブル(504)の予約状態(515)を予約参照前処理完了に設定して（ステップ６８）、処理を終了する。
【００６９】
一方、各レコードの予約情報の登録中にエラーが発生した場合には、まず予約管理テーブル(504)の状態を予約参照前処理取消に設定して、該予約参照前処理で登録した全ての予約情報をテーブルから削除し、最後に予約管理テーブル(504)の状態を予約参照前処理失敗に設定してエラーリターンする（ステップ６９）。
【００７０】
図７は、本実施例における一行更新処理の流れを示す図である。一行更新処理は、一つのレコードの内容を更新する処理であり、データベースの更新処理の中から呼び出される。
【００７１】
一行更新処理（７０）では、まず、更新するレコードを取得して（ステップ７１）、該レコードの予約参照時刻(506又は508)をチェックする（ステップ７２）。該レコードの予約参照時刻が登録されており、かつ、現時刻が該予約参照時刻を過ぎていたならば、該レコードのアクセスＩＤ(507又は509)をキーにして予約参照テーブル(502)から予約情報(511)を取得し（ステップ７３）、後述の予約参照バックアップ処理を行なう（ステップ７４）。その後、該レコードの更新処理を実行して（ステップ７５）、処理を終了する。
【００７２】
ステップ７２でアクセス対象のレコードの予約更新時刻が登録されていない場合や、該レコードの予約更新時刻がまだ過ぎていない場合には、予約参照バックアップ処理は行なわずに現在のレコードの更新処理を行なって（ステップ７５）、処理を終了する。
【００７３】
図８は、本実施例における予約参照バックアップ処理の流れを示す図である。予約参照バックアップ処理（８０）では、まず、予約管理テーブル(504)を予約ＩＤで検索して（ステップ８５）、予約管理テーブル(504)の状態(515)を確認する（ステップ８６）。予約管理テーブル(504)の状態(515)が予約参照前処理取消であれば、エラーリターンする。
【００７４】
ステップ８６で予約管理テーブル(504)の状態(515)が予約参照前処理取消以外であれば、当該レコードに対応する予約情報(511)からバックアップＩＤを取得し、当該レコードのバックアップが存在するかどうかをチェックする（ステップ８１）。当該レコードのバックアップが既に存在する場合には、バックアップを作成する必要がないため、予約参照バックアップ処理を終了する。
【００７５】
ステップ８１で当該レコードのバックアップが存在しない場合には、バックアップＩＤを新規に取得し（ステップ８２）、該レコードの内容をバックアップテーブル(503)に登録し（ステップ８３）、予約情報(511)に取得したバックアップＩＤを書き込み（ステップ８４）、予約参照バックアップ処理を終了する。
【００７６】
図９は、本実施例における予約参照後処理の流れを示す図である。予約参照後処理（９０）では、まず、予約管理テーブル(504)を予約ＩＤで検索し、予約状態(515)及び予約実行文(517)を取得する（ステップ９１）。次に、予約管理テーブル(504)の状態(515)をチェックする（ステップ９２）。その状態が予約参照前処理取消であれば、予約参照エラーとしてリターンする。それ以外の場合には、各参照レコードについて以下の処理を実行する。
【００７７】
まず、参照レコードを通常処理通りに取得する（ステップ９３）。次に、予約参照テーブル(502)から該レコードに対応する予約情報(511)を取得し（ステップ９４）、該レコードのバックアップが存在するかどうかをチェックする（ステップ９５）。
【００７８】
バックアップデータが存在する場合には、バックアップテーブル(503)から当該レコードのバックアップデータ(513)を取得して（ステップ９６）、ステップ９７に進む。バックアップデータが存在しない場合には、ステップ９６をスキップしてステップ９７に進む。
【００７９】
そして、予約実行文に従って予約していた参照処理を実行し（ステップ９７）、その後、予約参照テーブル(502)から該予約情報(511)を削除する（ステップ９８）。このとき、該レコードのバックアップデータ(513)がある場合にはそのバックアップデータも削除する。そして、全てのレコードの参照が終了してから、予約管理テーブル(504)から該予約参照に対応するエントリを削除して（ステップ９９）、予約参照後処理を終了する。
【００８０】
本実施例では、予約参照されたレコードについては、予約参照時刻以降に該レコードに対して更新処理が起こらないかぎり該レコードのバックアップは作成しない。また、予約参照後処理が終了すると該予約参照処理のために生成したバックアップは全て消去されるため、データベースの領域を長時間取り続けることがない。したがって、最小限のバックアップにより論理的に一貫性のある大規模データの参照を行なうことが可能である。
【００８１】
また、全ての処理はテーブルのレコード単位の排他制御を用いて実現できるため、システム稼働中にも大量のレコードの同時参照を行なうことが可能である。また、予約参照前処理が完了しないうちに予約時刻を過ぎてしまった場合の予約参照情報の取り消し手段を有することも本実施例の特徴の一つである。
【００８２】
本実施例は、リレーショナル型のデータベースシステムのみならず、構造型あるいは階層型のデータベースシステム等の、レコードを単位としてアクセスするあらゆるデータベースに適用できることは明らかである。
【００８３】
［実施例３］
次に、本発明の第３の実施例を説明する。本実施例３では、データベースの予約更新ならびに予約参照を同時に提供するための方法について説明する。
【００８４】
図１０は、本実施例における予約更新ならびに予約参照の処理の概要を説明する図である。横軸は時刻の流れを示し、黒い四角は各時刻において実行される処理を示している。予約更新処理は、実施例１と同様に、予約更新前処理(101)と、予約更新後処理(102)の２つの処理で実現される。一方、予約参照処理は、実施例２と同様に、予約参照前処理(103)と、予約参照バックアップ処理(104)と、予約参照後処理(105)の３つの処理で実現される。
【００８５】
予約更新処理に関しては、予約更新前処理(101)が完了したレコードに対して予約更新時刻以前にアクセスした場合には更新前のデータを提供し(106)、更新時刻より後で該レコードにアクセスした場合には予約更新後処理(102)を行ない予約されていた更新処理を実行してから更新後のデータを提供する(107)。
【００８６】
一方、予約参照処理に関しては、予約参照前処理(103)が完了したレコードに対して、予約参照時刻以前に該レコードを更新した場合には通常通り更新処理を行ない(108)、参照時刻より後かつ予約参照後処理(105)以前に該レコードを更新した場合には予約参照バックアップ処理(104)を行ない予約参照されていたレコードのバックアップを作成してから該レコードの更新処理を行なう(109)。
【００８７】
予約参照後処理(105)では、参照レコードのバックアップが作成されている場合には該バックアップデータを参照し、バックアップがない場合には該レコードのデータを参照する。予約参照後処理(105)は、予約参照時刻以降の適当なタイミングで実行する。予約参照後処理(105)を起動するタイミングは、参照時刻以降にタイマにより起動をかける方法や、参照時刻以降の最初のＤＢアクセス発生時点等、様々な方法により実現することができる。
【００８８】
図１１は、予約更新及び予約参照処理を実現するためのテーブル構造を示す図である。口座テーブル(110)及び支店テーブル(111)はアプリケーションが作成したデータベーステーブル（ＤＢテーブル）であり、予約アクセステーブル(112)、バックアップテーブル(113)及び予約管理テーブル(114)は予約更新及び予約参照処理を実現するためにデータベースシステムが作成したテーブルである。
【００８９】
アプリケーションが作成した ＤＢテーブルのうち、アプリケーションからは、破線で囲った部分(115)のみ直接アクセスすることができる。予約アクセス時刻(1101及び1103)とアクセスＩＤ(1102及び1104)は、予約更新及び予約参照処理を実現するためにデータベースシステムが付加した列である。ＤＢテーブルに付加した列のうち、予約アクセス時刻(1101及び1103)には、各レコードの予約アクセス時刻が格納される。予約アクセス時刻(1101及び1103)に何も格納されていない場合には、該レコードに対して更新又は参照の予約処理が行なわれていないことを示す。アクセスＩＤ(1102及び1104)には、予約アクセステーブルにアクセスするための識別子が格納される。
【００９０】
予約アクセステーブル(112)は、データベースシステム内に１つ存在し、アクセスＩＤ(1105)と、予約情報(1106)とで構成される。アクセスＩＤ(1105)は、予約アクセステーブル内でユニークな識別子であり、ＤＢテーブル(110及び111)と予約アクセステーブル(112)の対応を取る。予約情報(1106)には、予約された処理の種別（更新又は参照）と該処理の予約識別子（ＩＤ）が格納される。さらに、付加情報として、更新処理の場合には更新処理内容が格納され、参照処理の場合にはバックアップ識別子が記述される。バックアップ識別子は、バックアップが存在する場合のバックアップＩＤを示し、予約アクセステーブル(112)のエントリとバックアップテーブル(113)のエントリの対応を取る。
【００９１】
バックアップテーブル(113)は、データベースシステム内に一つ存在し、バックアップＩＤ(1107)とバックアップデータ(1108)とで構成される。バックアップＩＤ(1107)は、バックアップテーブル(113)内でユニークな識別子である。バックアップデータ(1108)には、予約アクセス時刻以降に更新されたレコードのバックアップ（更新前の状態のバックアップ）を格納する。本実施例ではバックアップはレコード単位で格納しているが、参照されるフィールドのみのバックアップを取ることももちろん可能である。
【００９２】
予約管理テーブル(114)は、データベースシステム内に１つ存在し、予約ＩＤ(1109)、予約状態(1110)、予約アクセス時刻(1111)、及び、予約実行文(1112)とで構成される。
【００９３】
予約ＩＤ(1109)は、論理的に同時に実行すべき予約アクセス処理１つにつき１つ付与される番号であり、データベースシステム内でユニークな番号である。予約状態(1110)は、前記同時に実行すべき予約参照処理の処理状態を示す。処理状態としては、予約更新前処理開始、予約更新前処理取消、予約参照前処理開始、予約参照前処理完了、予約参照前処理取消等がある。予約更新前処理開始及び予約参照前処理開始は、当該予約アクセスの前処理を行なっている最中であることを示し、予約参照前処理完了は、当該予約参照の前処理が正常終了したことを示し、予約更新前処理取消及び予約参照前処理取消は、当該予約アクセスの前処理が予約時刻までに終了しなかったため、既に登録している予約情報を取消中であることを示す。
【００９４】
一方、予約アクセス時刻(1111)には、予約アクセスを実行する時刻が格納され、予約実行文(1112)には、予約された参照実行文（問い合わせ実行文又は問い合わせ実行コード）が格納される。
【００９５】
本実施例では、予約ＩＤがR0050の予約更新処理、予約ＩＤがR0119の予約参照処理、及び予約ＩＤがR0120の予約参照処理がそれぞれ登録されている。予約ＩＤがR0050の予約更新処理は、更新時刻が1992/06/10 9:00であり、現在、予約更新前処理が完了しており、口座テーブルの口座番号670190048のレコードの残高に200,000を加算し、口座番号670190049のレコードの残高に300,000を加算する、という内容である。予約ＩＤがR0119の予約参照処理は、参照時刻が1992/06/10 7:00であり、現在予約参照前処理完了しており、口座テーブルの口座番号670191000のレコード、670191001のレコード、及び、支店テーブルの支店番号670191のレコードがそれぞれ予約参照登録されており、口座テーブルの口座番号670191000及び支店テーブルの支店番号670191のレコードは予約アクセス時刻以降に更新処理が行なわれたため、バックアップテーブルに予約アクセス時刻の時点におけるレコードの内容が保存されている。
【００９６】
本実施例で示したテーブル構造ではＤＢテーブルと予約アクセステーブルの対応や予約アクセステーブルと予約管理テーブル、あるいは、予約アクセステーブルとバックアップテーブルの対応を取るためにそれぞれ識別子を用いているが、ポインタ等を用いてこれらの対応を取ることももちろん可能である。
【００９７】
図１２は、本実施例における予約更新前処理の流れを示す図である。予約更新前処理（１２０）では、まず予約ＩＤを取得して、予約管理テーブル(114)へ該予約ＩＤならびに予約時刻の登録を行なう（ステップ１２１）。予約ＩＤは、データベースシステム内でユニークな識別子である。次に、予約管理テーブル(114)の予約状態(1110)を予約更新前処理開始に設定して（ステップ１２２）、全ての更新レコードについて、以下の処理を実行する。
【００９８】
まず、更新すべきレコードの内容を後述の１行参照処理により取得する（ステップ１２３）。次に、該レコードの予約アクセス時刻フィールド(1101又は1103)を確認して、既に他の予約アクセスが登録されているか否かを判定する（ステップ１２４）。既に他の予約アクセスが登録されていたならば、エラー処理（ステップ１２９）に制御を移す。他の予約アクセスが登録されていない場合には、登録中の予約更新処理の予約時刻を既に過ぎていないかをチェックし（ステップ１２５）、もし予約時刻を過ぎていた場合には、当該予約更新前処理が予定時刻に間に合わなかったとしてエラー処理（ステップ１２９）に制御を移す。
【００９９】
ステップ１２５で予約時刻を過ぎていない場合には、予約情報を予約アクセステーブル(112)に登録して（ステップ１２６）、次の更新レコードの処理に移る（ステップ１２７）。なお、予約情報(1106)の処理の種別は更新処理に設定し、更新処理内容には更新する列名及び更新情報を設定する。
【０１００】
全ての更新レコードの予約情報の登録が完了したならば（ステップ１２７）、予約管理テーブル(114)から該予約更新に対応するエントリを削除して（ステップ１２８）、処理を終了する。
【０１０１】
一方、各レコードの予約情報の登録中にエラーが発生した場合には、まず予約管理テーブル(114)の状態(1110)を予約更新前処理取消に設定して、該予約更新前処理で登録した全ての予約情報をテーブルから削除し、最後に予約管理テーブル(114)の状態(1110)を予約更新前処理失敗に設定してエラーリターンする（ステップ１２９）。
【０１０２】
図１３は、本実施例における予約参照前処理の流れを示す図である。予約参照前処理（１３０）では、まず予約ＩＤを取得して、予約管理テーブル(114)へ該予約ＩＤ、予約時刻ならびに予約実行文の登録を行なう（ステップ１３１）。次に、予約管理テーブル(114)の予約状態(1110)を予約参照前処理開始に設定して（ステップ１３２）、全ての参照レコードについて、以下の処理を実行する。
【０１０３】
まず、参照すべきレコードを後述の１行参照処理により取得する（ステップ１３３）。次に、該レコードの予約アクセス時刻フィールド(1101又は1103)を確認して、既に他の予約アクセスが登録されているか否かを判定する（ステップ１３４）。既に他の予約アクセスが登録されていたならば、エラー処理（ステップ１３９）に制御を移す。他の予約アクセスが登録されていない場合には、登録中の予約参照処理の予約時刻を既に過ぎていないかをチェックし（ステップ１３５）、もし予約時刻を過ぎていた場合には、当該予約参照前処理が予定時刻に間に合わなかったとしてエラー処理（ステップ１３９）に制御を移す。
【０１０４】
ステップ１３５で予約時刻を過ぎていない場合には、予約情報を予約アクセステーブル(112)に登録して（ステップ１３６）、次の参照レコードの処理に移る（ステップ１３７）。なお、予約情報(1106)の処理の種別は参照に設定し、バックアップＩＤはNULL値（バックアップデータなし）に初期設定する。
【０１０５】
全ての参照レコードの予約情報の登録が完了したならば（ステップ１３７）、予約管理テーブル(114)の予約状態(1110)を予約参照前処理完了に設定して（ステップ１３８）、処理を終了する。
【０１０６】
一方、各レコードの予約情報の登録中にエラーが発生した場合には、まず予約管理テーブル(114)の状態(1110)を予約参照前処理取消に設定して、該予約参照前処理で登録した全ての予約情報をテーブルから削除し、最後に予約管理テーブル(114)の状態(1110)を予約参照前処理失敗に設定してエラーリターンする（ステップ１３９）。
【０１０７】
図１４は、本実施例における一行更新処理の流れを示す図である。一行更新処理は、一つのレコードの内容を更新する処理であり、データベースの更新処理の中から呼び出される。
【０１０８】
一行更新処理（１４０）では、まず、更新するレコードを取得して（ステップ１４１）、該レコードの予約アクセス時刻(1101又は1103)をチェックする（ステップ１４２）。該レコードの予約アクセス時刻が登録されていたなら、現時刻が該予約アクセス時刻を過ぎているか否か判定する（ステップ１４３）。該レコードの予約アクセス時刻が登録されており、かつ現時刻が該予約アクセス時刻を過ぎていたならば、該レコードのアクセスＩＤ(1102又は1104)をキーにして予約アクセステーブル(112)から予約情報(1106)を取得し（ステップ１４４）、予約情報(1106)のアクセス種別をチェックする（ステップ１４５）。
【０１０９】
予約情報(1106)のアクセス種別が更新の場合には、後述の予約更新後処理を行ない（ステップ１４６）、アクセス種別が参照の場合には、予約参照バックアップ処理を行なう（ステップ１４７）。そして、最後に、該レコードの更新処理を実行する（ステップ１４８）。予約参照バックアップ処理は、実施例２で説明した処理と全く同様である。
【０１１０】
ステップ１４２，１４３で、アクセス対象のレコードの予約アクセス時刻が登録されていない場合や、該レコードの予約アクセス時刻がまだ過ぎていない場合には、通常通りレコードの更新処理（ステップ１４８）を行なう。
【０１１１】
図１５は、本実施例における一行参照処理の流れを示す図である。一行参照処理は、一つのレコードの内容を参照する処理であり、データベースの参照処理の中から呼び出される。
【０１１２】
一行参照処理（１５０）では、まず、参照するレコードを取得して（ステップ１５１）、該レコードの予約アクセス時刻(1101又は1103)をチェックする（ステップ１５２）。該レコードの予約アクセス時刻が登録されていたなら、現時刻が該予約アクセス時刻を過ぎているか否か判定する（ステップ１５３）。該レコードの予約アクセス時刻が登録されており、かつ現時刻が該予約アクセス時刻を過ぎていたならば、該レコードのアクセスＩＤ(1102又は1104)をキーにして予約アクセステーブル(112)から予約情報(1106)を取得し（ステップ１５４）、予約情報(1106)のアクセス種別をチェックする（ステップ１５５）。
【０１１３】
予約情報(1106)のアクセス種別が更新の場合には、後述の予約更新後処理を行ない（ステップ１５６）、更新後のデータを参照データとして呼び出し元にリターンする。ステップ１５５でアクセス種別が参照の場合には、該レコードのデータをそのまま参照データとして呼び出し元にリターンする。
【０１１４】
ステップ１５２，１５３でアクセス対象のレコードの予約アクセス時刻が登録されていない場合や、該レコードの予約アクセス時刻がまだ過ぎていない場合にも、該レコードのデータをそのまま参照データとして呼び出し元にリターンする。
【０１１５】
図１６は、本実施例における予約更新後処理の流れを示す図である。予約更新後処理（１６０）では、まず、予約管理テーブル(114)を予約ＩＤで検索して（ステップ１６１）、予約管理テーブル(114)の状態(1110)を確認する（ステップ１６２）。次に、予約管理テーブル(114)の状態(1110)が予約更新前処理取消以外であれば、予約情報(1106)に従って当該レコードの更新処理を行ない（ステップ１６３）、その後、予約アクセステーブル(112)から該予約情報(1106)を削除する（ステップ１６４）。ステップ１６２で予約管理テーブル(114)の状態(1110)が予約更新前処理取消の場合には、当該レコードの更新は行なわずに予約アクセステーブル(112)から予約情報(1106)を削除して（ステップ１６４）、予約更新後処理を終了する。
【０１１６】
図１７は、本実施例における予約参照後処理の流れを示す図である。予約参照後処理（１７０）では、まず、予約管理テーブル(114)を予約ＩＤで検索し、予約状態(1110)及び予約実行文(1112)を取得する（ステップ１７１）。次に、予約管理テーブル(114)の状態(1110)が予約参照前処理取消であれば、予約参照エラーとしてリターンする。それ以外の場合には、各参照レコードについて以下の処理を実行する。
【０１１７】
まず、参照レコードを通常処理通りに取得する（ステップ１７３）。次に、予約アクセステーブル(112)から該レコードに対応する予約情報(1106)を取得し（ステップ１７４）、該レコードのバックアップが存在するかどうかをチェックする（ステップ１７５）。バックアップデータが存在する場合には、バックアップテーブル(113)から当該レコードのバックアップデータ(1108)を取得して（ステップ１７６）、ステップ１７７に進む。バックアップデータ(1108)が存在しない場合には、そのままステップ１７７に進む。
【０１１８】
そして、予約実行文に従って予約していた参照処理を実行し（ステップ１７７）、その後、予約アクセステーブル(112)から該予約情報(1106)を削除する（ステップ１７８）。このとき、該レコードのバックアップデータ(1108)がある場合には、そのバックアップデータも削除する。そして、全てのレコードの参照が終了してから、予約管理テーブル(114)から該予約参照に対応するエントリを削除して（ステップ１７９）、予約参照後処理を終了する。
【０１１９】
本実施例は、実施例１で述べた予約更新処理と実施例２で述べた予約参照処理を同時に実現するところに特徴がある。本実施例では、これらの処理を同時に実現するために予約情報としてアクセス種別を追加し、１行更新処理及び１行参照処理において該アクセス種別を判定して、予約更新後処理を行なうか、バックアップ処理を行なうかを決定しているところに特徴がある。
【０１２０】
本実施例では、予約更新及び予約参照の処理をデータベースシステムの機能として実現することにより、大量レコードの更新処理および大量レコードの参照を一瞬で行なうようにアプリケーションプログラムに見せることが可能となる。このため、従来、データベースシステムを一時停止させて行なわなければならなかった、データのバックアップ処理やデータベースの統計処理、給与振込みのオンラインバッチ処理等の、種々の大規模データベース処理を、システム稼働中に行なうことが可能となる。これにより、銀行オンラインの２４時間連続運転等のデータベースシステムの無停止運転機能が容易に実現可能となる。
【０１２１】
なお、本実施例は、リレーショナル型のデータベースシステムのみならず、構造型あるいは階層型のデータベースシステム等の、レコードを単位としてアクセスするあらゆるデータベースに適用できることは明らかである。
【０１２２】
［実施例４］
上記実施例１から実施例３までの予約アクセス処理では、一つのレコードには１つの予約アクセス処理しか登録できず、既に予約アクセスが登録されているレコードに対して新たな予約アクセスを登録するとエラーリターンする仕様となっていた。
【０１２３】
そこで、実施例４では一つのレコードに対して複数の予約アクセスを登録可能にする複数予約アクセス登録機能を実現する方法について説明する。本実施例では、実施例３で示した予約更新ならびに予約参照を同時に実現する方法に複数予約アクセス登録機能を追加した例を示すが、実施例１及び実施例２に複数予約アクセス登録機能を追加することも、同様の方式で容易に実現することが可能である。
【０１２４】
図１８は、複数予約アクセス登録機能を実現するためのテーブル構造を示す図である。口座テーブル(181)及び支店テーブル(182)はアプリケーションが作成したデータベーステーブル（ＤＢテーブル）であり、予約アクセステーブル(183)、バックアップテーブル(184)及び予約管理テーブル(185)は複数予約アクセス登録機能を実現するためにデータベースシステムが作成したテーブルである。
【０１２５】
アプリケーションが作成した ＤＢテーブルのうち、アプリケーションからは、破線で囲った部分(186)のみ直接アクセスすることができる。予約アクセス時刻(1801及び1803)とアクセスＩＤ(1802及び1804)は、予約更新及び予約参照処理を実現するためにデータベースシステムが付加した列である。ＤＢテーブルに付加した列のうち、予約アクセス時刻(1801及び1803)には、各レコードに登録されている予約アクセス処理のうち、最も処理時間が早い処理の予約アクセス時刻が格納される。予約アクセス時刻(1801及び1803)に何も格納されていない場合には、該レコードに対して更新又は参照の予約処理が登録されていないことを示す。アクセスＩＤ(1802及び1804)には、各レコードに登録されている予約アクセス処理のうち、最も処理時間が早い処理に対応する識別子が格納される。
【０１２６】
予約アクセステーブル(183)は、データベースシステム内に１つ存在し、アクセスＩＤ(1805)と、予約情報(1806)と、該予約アクセス処理の次に登録されている次予約アクセス時刻(1807)と、次アクセスＩＤ(1808)とから構成される。
【０１２７】
アクセスＩＤ(1805)は、予約アクセステーブル(183)内でユニークな識別子であり、ＤＢテーブル(181及び182)と予約アクセステーブル(183)の対応を取る。予約情報(1806)には、予約されたアクセス種別（更新又は参照）と該処理の予約識別子が格納される。さらに、付加情報として、更新処理の場合には更新処理内容が格納され、参照処理の場合にはバックアップ識別子が記述される。
【０１２８】
一つのレコードに複数の予約アクセスがある場合には、該複数の予約アクセス処理を予約時刻の早い順に並べて予約アクセステーブル(183)の次予約時刻(1807)と次予約アクセスＩＤ(1808)に順次登録する。次予約アクセス時刻(1807)ならびに次アクセスＩＤ(1808)が未登録の場合は、該予約アクセスが、該レコードに登録されている予約アクセス処理の最後であることを示す。このような予約アクセステーブル(183)のエントリのチェインのことを、以下の説明では、予約アクセスリストと呼ぶ。
【０１２９】
バックアップテーブル(184)は、データベースシステム内に一つ存在し、バックアップＩＤ(1810)とバックアップデータ(1811)とで構成される。バックアップＩＤ(1810)は、バックアップテーブル(184)内でユニークな識別子である。バックアップＩＤ(1810)は、バックアップが存在する場合のバックアップ識別子を示し、予約アクセステーブル(183)のエントリとバックアップテーブル(184)のエントリとの対応を取る。バックアップデータ(1811)には、予約アクセス時刻以降に更新されたレコードのバックアップを格納する。本実施例ではバックアップはレコード単位で格納しているが、参照されるフィールドのみのバックアップを取ることももちろん可能である。
【０１３０】
予約管理テーブル(185)は、データベースシステム内に１つ存在し、予約ＩＤ(1812)、予約状態(1813)、予約アクセス時刻(1814)、及び、予約実行文(1815)とで構成される。
【０１３１】
予約ＩＤ(1812)は、論理的に同時に実行すべき予約アクセス処理１つにつき１つ付与される番号であり、データベースシステム内でユニークな番号である。予約状態(1813)は、前記同時に実行すべき予約参照処理の処理状態を示す。処理状態としては、予約更新前処理開始、予約更新前処理取消、予約参照前処理開始、予約参照前処理完了、予約参照前処理取消等がある。予約更新前処理開始及び予約参照前処理開始は、当該予約アクセスの前処理を行なっている最中であることを示し、予約参照前処理完了は、当該予約参照の前処理が正常終了したことを示し、予約更新前処理取消及び予約参照前処理取消は、当該予約アクセスの前処理が予約時刻までに終了しなかったため、既に登録している予約情報を取消中であることを示す。
【０１３２】
一方、予約アクセス時刻(1814)には、予約アクセスを実行する時刻が格納され、予約実行文(1815)には、予約された参照実行文（問い合わせ実行文又は問い合わせ実行コード）が格納される。
【０１３３】
本実施例では、予約ＩＤがR0050の予約更新処理及び、予約ＩＤがR0119の予約参照処理、予約ＩＤがR0120の予約参照処理がそれぞれ登録されている。口座テーブルの口座番号670190049のレコードには、アクセスＩＤがA0002の予約更新処理と、アクセスＩＤがA0350の予約参照処理の２つの予約アクセス処理が登録されている。アクセスＩＤがA0002の予約更新処理の予約時刻が9:00、アクセスＩＤがA0350の予約参照処理の予約時刻が12:00であるので、アクセスＩＤがA0002の予約更新処理が予約アクセスリストの先頭に登録されており、アクセスＩＤがA0350の予約参照処理が予約アクセスリストの次の部分に登録されている。
【０１３４】
本実施例で示したテーブル構造ではＤＢテーブルと予約アクセステーブルの対応や予約アクセステーブルと予約管理テーブル、あるいは、予約アクセステーブルとバックアップテーブルの対応を取るためにそれぞれ識別子を用いているが、ポインタ等を用いてこれらの対応を取ることももちろん可能である。
【０１３５】
図１９は、本実施例における予約更新前処理の流れを示す図である。予約更新前処理では、まず予約管理テーブル(185)の予約アクセス時刻(1814)を、登録しようとしている予約アクセスの予約アクセス時刻で検索し（ステップ１９０）、該アクセス時刻と一致する予約アクセスが存在しその状態が前処理開始であるか否かを判定する（ステップ１９１）。該アクセス時刻と一致する予約アクセスが存在しその状態が前処理開始であれば、他の予約アクセス前処理と衝突しているため、エラーリターンする。該エラーリターンを受け取ったアプリケーションプログラムは、予約アクセス時刻を変更するか、あるいは、現在実行中の予約アクセス前処理が終了するまで待つかのいずれかの処理を行なうことによりエラー状態から回復することが可能である。
【０１３６】
予約アクセス前処理の衝突チェック（ステップ１９１）が完了したならば、予約ＩＤを取得して、予約管理テーブル(185)へ該予約ＩＤならびに予約時刻の登録を行ない（ステップ１９２）、予約管理テーブル(185)の予約状態(1813)を予約更新前処理開始に設定する（ステップ１９３）。そして、全ての更新レコードについて、以下の処理を実行する。
【０１３７】
まず、更新すべきレコードの内容を後述の１行参照処理により取得する（ステップ１９４）。次に、登録中の予約更新処理の予約時刻を既に過ぎていないかをチェックし（ステップ１９５）、もし予約時刻を過ぎていた場合には、当該予約更新前処理が予定時刻に間に合わなかったとしてエラー処理（ステップ１９９）に制御を移す。
【０１３８】
ステップ１９５で予約時刻を過ぎていない場合には、予約情報を予約アクセステーブル(183)に登録して（ステップ１９６）、次の更新レコードの処理に移る（ステップ１９７）。予約情報(1806)のアクセステーブル(183)への登録は、該更新レコードに既に登録されている予約アクセスリストのうち、該予約アクセス時刻より遅いアクセス時刻を持つ予約情報の直前に該予約アクセス情報を登録する。該予約アクセス時刻より遅いアクセス時刻を持つ予約情報がない場合には、予約アクセスリストの最後に該予約アクセス情報を登録する。予約情報(1806)の処理の種別は更新処理に設定し、更新処理内容には更新する列名及び更新情報を設定する。
【０１３９】
全ての更新レコードの予約情報の登録が完了したならば（ステップ１９７）、予約管理テーブル(185)から該予約更新に対応するエントリを削除して（ステップ１９８）、処理を終了する。
【０１４０】
一方、各レコードの予約情報の登録中にエラーが発生した場合には、まず予約管理テーブル(185)の状態を予約更新前処理取消に設定して、該予約更新前処理で登録した全ての予約情報をテーブルから削除し、最後に予約管理テーブル(185)の状態を予約更新前処理失敗に設定してエラーリターンする（ステップ１９９）。
【０１４１】
図２０は、本実施例における予約参照前処理の流れを示す図である。予約参照前処理では、まず予約管理テーブル(185)の予約アクセス時刻(1814)を、登録しようとしている予約アクセスの予約アクセス時刻で検索し（ステップ２００）、該アクセス時刻と一致する予約アクセスが存在しその状態が前処理開始であるか否かを判定する（ステップ２０１）。該アクセス時刻と一致する予約アクセスが存在しその状態が前処理開始であれば、他の予約アクセス前処理と衝突しているため、エラーリターンする。該エラーリターンを受け取ったアプリケーションプログラムは、予約アクセス時刻を変更するか、あるいは、現在実行中の予約アクセス前処理が終了するまで待つかのいずれかの処理を行なうことにより、エラー状態から回復することが可能である。
【０１４２】
予約アクセス前処理の衝突チェック（ステップ２０１）が完了したならば、予約ＩＤを取得して、予約管理テーブル(185)へ該予約ＩＤ、予約時刻ならびに予約実行文の登録を行い（ステップ２０２）、予約管理テーブル(185)の予約状態(1813)を予約参照前処理開始に設定する（ステップ２０３）。次に、全ての参照レコードについて、以下の処理を実行する。
【０１４３】
まず、参照すべきレコードを後述の１行参照処理により取得する（ステップ２０４）。次に、登録中の予約参照処理の予約時刻を既に過ぎていないかをチェックし（ステップ２０５）、もし予約時刻を過ぎていた場合には、当該予約参照前処理が予定時刻に間に合わなかったとしてエラー処理（ステップ２０９）に制御を移す。
【０１４４】
ステップ２０５で予約時刻を過ぎていない場合には、予約情報を予約アクセステーブル(183)に登録して（ステップ２０６）、次の参照レコードの処理に移る（ステップ２０７）。予約情報(1806)のアクセステーブル(183)への登録は、該更新レコードに既に登録されている予約アクセスリストのうち、該予約アクセス時刻より遅いアクセス時刻を持つ予約情報の直前に該予約アクセス情報を登録する。該予約アクセス時刻より遅いアクセス時刻を持つ予約情報がない場合には、予約アクセスリストの最後に該予約アクセス情報を登録する。予約情報(1806)の処理の種別は参照に設定し、バックアップＩＤはNULL値（バックアップデータなし）に初期設定する。
【０１４５】
全ての参照レコードの予約情報の登録が完了したならば（ステップ２０７）、予約管理テーブル(185)の予約状態(1813)を予約参照前処理完了に設定して処理を終了する。
【０１４６】
一方、各レコードの予約情報の登録中にエラーが発生した場合には、まず予約管理テーブル(185)の状態を予約参照前処理取消に設定して、該予約参照前処理で登録した全ての予約情報をテーブルから削除し、最後に予約管理テーブル(185)の状態を予約参照前処理失敗に設定してエラーリターンする（ステップ２０９）。
【０１４７】
図２１は、本実施例における一行更新処理の流れを示す図である。一行更新処理は、一つのレコードの内容を更新する処理であり、データベースの更新処理の中から呼び出される。
【０１４８】
一行更新処理では、まず、更新するレコードを取得して（ステップ２１０）、該レコードの予約アクセス時刻(1801又は1803)をチェックする（ステップ２１１）。アクセス対象のレコードの予約アクセス時刻が登録されていたら、現在の時刻が該レコードの予約アクセス時刻を過ぎたか否かを判定する（ステップ２１２）。アクセス対象のレコードの予約アクセス時刻が登録されていない場合、または該レコードの予約アクセス時刻がまだ過ぎていない場合には、通常通りレコードの更新処理（ステップ２１９）を行なう。
【０１４９】
ステップ２１１，２１２で、該レコードの予約アクセス時刻が登録されており、かつ、現時刻が該予約アクセス時刻を過ぎていたならば、該レコードのアクセスＩＤ(1802又は1804)をキーにして予約アクセステーブル(183)から予約情報(1806)を取得し（ステップ２１３）、予約情報のアクセス種別をチェックする。
【０１５０】
予約情報(1806)のアクセス種別が更新の場合には、予約更新後処理を行ない（ステップ２１４）、アクセス種別が参照の場合には、予約参照バックアップ処理を行なう（ステップ２１５）。予約更新後処理は実施例３で説明した処理と全く同様であり、予約参照バックアップ処理は実施例２で説明した処理と全く同様である。
【０１５１】
次に、予約アクセステーブル(183)の次予約アクセス時刻(1807)を確認し（ステップ２１６）、次予約アクセス時刻(1807)の指定がある場合は、現時刻がその次予約アクセス時刻を過ぎているか否かを判定する（ステップ２１７）。次予約アクセス時刻の指定があり、かつ、現時刻が次予約アクセス時刻を過ぎていたならば、予約アクセステーブル(183)を次アクセスＩＤ(1808)で検索して次に登録されている予約情報(1806)を取得し（ステップ２１８）、アクセス種別のチェックに戻る。
【０１５２】
ステップ２１６，２１７で、次予約アクセス時刻が登録されていない場合や、次予約アクセス時刻をまだ過ぎていない場合には、予約アクセス処理のループを脱出し、該レコードの更新処理（ステップ２１９）を実行する。
【０１５３】
図２２は、本実施例における一行参照処理の流れを示す図である。一行参照処理は、一つのレコードの内容を参照する処理であり、データベースの参照処理の中から呼び出される。
【０１５４】
一行参照処理では、まず、参照するレコードを取得して（ステップ２２０）、該レコードの予約アクセス時刻(1801又は1803)をチェックする（ステップ２２１）。アクセス対象のレコードの予約アクセス時刻が登録されている場合は、現時刻が該レコードの予約アクセス時刻を過ぎているか否かを判定する（ステップ２２２）。アクセス対象のレコードの予約アクセス時刻が登録されていない場合や、該レコードの予約アクセス時刻がまだ過ぎていない場合には、該レコードのデータをそのまま参照データとして呼び出し元にリターンする。
【０１５５】
ステップ２２１，２２２で、該レコードの予約アクセス時刻が登録されており、かつ、現時刻が該予約アクセス時刻を過ぎていたならば、該レコードのアクセスＩＤ(1802又は1804)をキーにして予約アクセステーブル(183)から予約情報(1806)を取得し（ステップ２２３）、予約情報(1806)のアクセス種別をチェックする。
【０１５６】
予約情報(1806)のアクセス種別が参照の場合には、現在のデータを参照データとするとともに、予約参照フラグをオンにして（ステップ２２７）、ステップ２２８に進む。
【０１５７】
予約情報(1806)のアクセス種別が更新の場合には、予約参照フラグがオンであるか否かを判定し（ステップ２２４）、オンであれば、予約参照バックアップ処理を行なってから（ステップ２２５）、予約更新後処理を行ない（ステップ２２６）、ステップ２２８に進む。ステップ２２４で、予約参照フラグがオフであれば、予約更新後処理（ステップ２２６）のみを行なう。予約更新後処理を行なった場合には更新後のデータを参照データとする。予約更新後処理は実施例３で説明した処理と全く同様であり、予約参照バックアップ処理は実施例２で説明した処理と全く同様である。
【０１５８】
次に、予約アクセステーブル(183)の次予約アクセス時刻(1807)を確認し（ステップ２２８）、次予約アクセス時刻(1807)の指定があれば、現時刻がその次予約アクセス時刻を過ぎているか否かを判定する（ステップ２２９）。次予約アクセス時刻の指定があり、かつ、現時刻が次予約アクセス時刻を過ぎていたならば、予約アクセステーブル(183)を次アクセスＩＤ(1808)で検索して次に登録されている予約情報(1806)を取得し（ステップ２３０）、アクセス種別のチェックに戻る。
【０１５９】
ステップ２２８，２２９で、次予約アクセス時刻(1807)が登録されていない場合や次予約アクセス時刻をまだ過ぎていない場合には、予約アクセス処理のループを脱出し、参照データを呼び出し元にリターンする。
【０１６０】
本実施例によれば、複数の予約アクセスを登録することができる。
【０１６１】
【発明の効果】
本発明によれば、複数のレコードの一括更新ならびに同時参照を行なうデータベースシステムにおいて、該複数のレコードへのアクセスをあらかじめ時刻指定で予約登録しておくことにより、該予約時刻に同時に更新又は参照が実行されたようにアプリケーションプログラムに対してみせることを可能とした。本発明では、登録された予約アクセス処理を予約時刻以前に行なう予約アクセス前処理と、予約時刻以降に実行される予約アクセス後処理に分割して実行することにより、データベースシステムを停止することなく大量レコードの一括更新および参照を実行することを可能とした。
【図面の簡単な説明】
【図１】第１の実施例における処理概要図およびテーブル構成図
【図２】第１の実施例における予約更新前処理の流れ図
【図３】第１の実施例におけるDBアクセス処理の流れ図
【図４】第１の実施例における予約更新後処理の流れ図
【図５】第２の実施例における処理概要図およびテーブル構成図
【図６】第２の実施例における予約参照前処理の流れ図
【図７】第２の実施例における１行更新処理の流れ図
【図８】第２の実施例における予約参照バックアップ処理の流れ図
【図９】第２の実施例における予約参照後処理の流れ図
【図１０】第３の実施例における処理の概要図
【図１１】第３の実施例におけるテーブル構成図
【図１２】第３の実施例における予約更新前処理の流れ図
【図１３】第３の実施例における予約参照前処理の流れ図
【図１４】第３の実施例における１行更新処理の流れ図
【図１５】第３の実施例における１行参照処理の流れ図
【図１６】第３の実施例における予約更新後処理の流れ図
【図１７】第３の実施例における予約参照後処理の流れ図
【図１８】第４の実施例におけるテーブル構成図
【図１９】第４の実施例における予約更新前処理の流れ図
【図２０】第４の実施例における予約参照前処理の流れ図
【図２１】第４の実施例における１行更新処理の流れ図
【図２２】第４の実施例における１行参照処理の流れ図
【図２３】本発明を実施するデータベースシステムの構成を示す図
【符号の説明】
1…予約更新前処理、2…予約更新後処理、5…予約更新時刻、6…DBテーブル(口座テーブル)、7…DBテーブル(支店テーブル)、8…予約更新テーブル、9…予約管理テーブル、51…予約参照前処理、52…予約参照後処理、53…予約参照バックアップ処理、56…予約参照時刻、502…予約参照テーブル、503…バックアップテーブル。
【産業上の利用分野】
本発明は、複数レコードの一括更新ならびに同時参照を行なうデータベースシステムに関し、特に複数のレコードへのアクセスを該複数のレコードの共用排他制御を行なわずに実行することが要求されるオンラインデータベース処理システムにおける予約アクセス処理方法に関する。
【０００２】
【従来の技術】
情報化社会の発達により、銀行のオンラインシステム等の大容量のデータを保持するオンラインデータベースシステムが構築されてきた。オンラインデータベースシステムでは、テーブルのレコードに対する参照、更新がオンラインで頻繁に行なわれる。
【０００３】
特に、銀行口座の統計情報の取得や、利息計算に基づく口座残高の更新、あるいはデータのバックアップ等の大量レコードの更新及び参照を行なう大規模バッチ処理は、データベースのテーブル全体を長時間排他確保することが必要なため、オンラインシステムを停止している間に行なう必要があった。ところが、近年のデータベースの大容量化、ならびに、オンラインシステムの稼働時間延長への要求は、上記大規模バッチ処理をシステム停止時間に行なうという方法を不可能にしつつある。
【０００４】
これらの問題を解決するために、従来はシステムを２重化して、一方をオンライン用に、他方を大規模バッチ処理用に用いて、適当なタイミングで整合性を取る方法や、データのバックアップを定期的に取り、統計情報の作成等の参照系の大規模バッチ処理はバックアップデータに対して行なう方法等が用いられてきた。また、データのバージョンを複数管理することにより、過去のある時点における一貫性のあるデータに対してアクセスする機能を提供するデータベースのバージョン管理方式等が提案されてきた。
【０００５】
特に、データベースのバージョン管理方式等は、種々の方法が提案されている。例えば、特開平６−２８３１５号では、トランザクション処理と参照アクセス処理を相互干渉させることなく効率的に並列実行するための方法が開示されている。すなわち、この公知例では、データベースの各頁について有限数の論理バージョンを保持し、これらをタイムスタンプにより管理し、また現在進行中のトランザクションを管理するテーブルおよびシステム状態を表現する情報を記憶することにより、トランザクション進行中のテーブルに対する照会アクセスを、該トランザクションを停止することなく、より新しいバージョンのデータベースにアクセスすることを可能にしている。このようなデータベースのバージョン管理方式は、データの更新を伴うトランザクション処理と大量データの参照を行う参照系バッチ処理を並列に実行する際に有効な技術である。
【０００６】
【発明が解決しようとする課題】
上述したように、従来のオンラインシステムでは、大規模バッチ処理を実行する際に、システムを停止するか、システムを２重化するか、あるいは、データのバックアップまたは複数のデータのバージョンを取るかの方法を取っていた。
【０００７】
しかしながら、オンラインシステムを停止させその停止中に処理するという方法では、システムの２４時間連続運転を不可能にするという大きな問題点がある。
【０００８】
また、システムを２重化して一方をオンラインシステム用に、他方を大規模バッチ処理用に適用する方法では、それぞれのデータの一貫性を保証することが困難であり、オンラインで逐次更新されているデータを直接参照したい場合には適用不可能である。また、大規模バッチ処理用のシステムで実行した更新系の処理結果は、オンラインシステム用と大規模バッチ処理用のシステム間のデータの整合性を取った後でなければオンラインシステム側で読み取ることができないという問題がある。
【０００９】
さらに、データのバックアップを活用して大規模バッチ処理を実行する方法では、データのバックアップ処理自身が大規模参照系バッチ処理であり、バックアップ処理のためのテーブルの排他制御が必要であるという問題点がある。
【００１０】
また、データベースのバージョン管理を行なう方法では、トランザクション処理と参照系のバッチ処理を並行に処理する場合には有効であるが、トランザクション処理と更新系のバッチ処理を並行に処理することは不可能であり、また参照系のバッチ処理に関しても、より新しいデータベースにアクセスすることはできるものの、ある時刻の正確な統計情報を得ることは不可能であるという問題点があった。さらに、データベースの複数のバージョンを常に保持するため、大容量の記憶装置が必要になるという問題点があった。
【００１１】
本発明は、大量レコードの更新や参照を、当該レコードの排他制御を同時に確保せずに個々のレコード単位の排他制御により実行する方法を提供することを目的とする。
【００１２】
本発明の他の目的は、大量レコードの更新を論理的には指定された時刻に同時に行なったようにデータベースのユーザに対して見せる機能を提供することにある。
【００１３】
さらに本発明の他の目的は、指定された時刻における大量レコードの参照を必要最小限のデータのバックアップのみで実現する機能を提供することにある。
【００１４】
また本発明の他の目的は、一つのレコードに対して複数の予約アクセス登録を可能とする機能を提供することにある。
【００１５】
本発明の他の目的は、予約アクセス処理が失敗した場合に、該予約アクセス処理全体を取り消すことを可能とする機能を提供することにある。
【００１６】
【課題を解決するための手段】
本発明に係る予約アクセス処理方法では、複数のレコードの更新をあらかじめ予約することにより、該予約された更新を指定された予約更新時刻に論理的に同時に実行するための方法を提供する。この予約更新処理は、当該レコードの更新を予約登録するための予約更新前処理と、予約更新時刻以降の当該レコードへの最初のアクセス時に行なわれる予約更新後処理とで実行される。予約更新前処理においては、前記データベーステーブルの各レコードに１対１に対応した予約更新時刻と予約情報とで構成される予約更新情報に該レコードの予約更新時刻ならびに更新内容を格納する。そして、データベースへのレコードのアクセス時には、該レコードに対する予約更新登録の有無及び現時刻と予約更新時刻との比較を行ない、該レコードに対応する予約更新登録があり、かつ、現時刻が予約更新時刻以降であれば予約更新後処理を実行してから当該レコードに対するアクセス処理を実行し、予約更新登録がない場合、もしくは、現時刻が予約更新時刻以前であれば予約された更新は行なわずに該レコードに対するアクセス処理を実行する。そして、予約更新後処理においては、当該レコードに登録されている更新を実行して該予約更新登録を削除する。
【００１７】
前記予約更新時刻以降に、前記予約更新後処理ステップを前記更新予約されたレコードのすべてに関して実行するクリーンナップ処理を行なうようにしてもよい。また、前記予約更新前処理ステップで予約更新登録を実行している途中で、現時刻が該予約更新登録の予約更新時刻を過ぎてしまった場合には、該予約更新処理の状態を予約更新前処理取消状態に設定し、それまでに予約更新登録した全てのレコードの予約更新情報を削除すると共に、前記予約更新後処理ステップを実行する際には、当該予約更新処理の状態を確認して、該状態が予約更新前処理取消であった場合には該予約更新登録を破棄するようにする。予約更新処理の状態は、例えば予約アクセス状態を管理するテーブルを設けることにより管理するとよい。
【００１８】
さらに、本発明に係る予約アクセス処理方法では、複数のレコードの参照をあらかじめ予約することにより、該複数のレコードの共用排他アクセス権の確保を同時に確保することなく、該予約参照時刻に全てのレコードの参照を実行するための方法を提供する。予約参照処理は、当該レコードの参照を予約登録するための予約参照前処理と、予約参照時刻以降に実行される予約参照後処理と、予約参照時刻以降かつ予約参照後処理以前の間に発生する当該参照レコードへの更新処理時に実行される予約参照バックアップ処理とで実行される。予約参照前処理においては、前記データベーステーブルの各レコードに１対１に対応した予約参照時刻と予約情報とで構成される予約更新情報に該レコードの予約参照時刻ならびに参照内容を格納する。そして、データベースへのレコードの更新アクセス時には、該レコードに対する予約更新登録の有無及び現時刻と予約更新時刻との比較を行ない、該レコードに対応する予約参照登録があり、かつ、現時刻が予約参照時刻以降であれば予約参照バックアップ処理を実行して当該レコードのデータのバックアップを作成してから当該レコードに対する更新アクセス処理を実行し、予約参照登録がない場合、もしくは、現時刻が予約参照時刻以前であれば予約参照バックアップ処理は行なわずに該レコードに対する更新アクセス処理を実行する。また、予約参照時刻以降にタイマ割り込み等により起動される予約参照後処理においては、当該レコードのバックアップデータが作成されている場合にはバックアップデータを参照してから該バックアップデータ及び該予約参照登録を削除し、バックアップデータが存在しない場合には当該レコードの内容を直接参照してから該予約参照登録を削除する。
【００１９】
前記予約参照前処理ステップで予約参照登録を実行している途中で、現時刻が該予約参照登録の予約参照時刻を過ぎてしまった場合には、該予約参照処理の状態を予約参照前処理取消状態に設定し、それまでに予約参照登録した全てのレコードの予約参照情報を削除すると共に、前記予約参照バックアップ処理ステップ及び前記予約参照後処理ステップを実行する際には、当該予約参照処理の状態を確認して、該状態が予約参照前処理取消であった場合には該予約参照登録を破棄するようにする。予約参照処理の状態は、例えば予約アクセス状態を管理するテーブルを設けることにより管理するとよい。
【００２０】
さらに、前記予約更新登録又は前記予約参照登録において格納する予約更新情報又は予約参照情報に、次の予約更新情報又は予約参照情報へのポインタを設け、一つのレコードに対して複数の予約アクセスを登録するようにしてもよい。
【００２１】
【作用】
本発明の予約更新処理における予約更新前処理ならびに予約更新後処理においては、現在処理中のレコードに関連する排他制御処理のみを行なえばよく、更新するレコード全体の排他制御を同時に行なう必要はない。このため、大量レコードの更新を個々のレコード単位のロックのみで実現することが可能となった。
【００２２】
また、予約更新登録されたレコードの更新処理は予約更新時刻以降の最初の当該レコードに対するアクセス処理時に行なわれるため、予約更新時刻には実際にはデータベースの更新は行わない。このため、全てのレコードの更新処理を一瞬にして実行したようにユーザに対して見せることが可能となった。
【００２３】
一方、本発明の予約参照処理における予約参照前処理、予約参照バックアップ処理ならびに予約参照後処理においては、現在処理中のレコードに関連する排他制御処理のみを行なえばよく、参照するレコード全体の排他制御を同時に行なう必要はない。このため、大量レコードの更新を個々のレコード単位のロックのみで実現することが可能となった。
【００２４】
また、予約参照されたレコードの参照処理は予約参照時刻以降にタイマ割り込み等により起動された予約参照後処理により実行される。予約参照時刻には実際にはデータベースの参照処理は行わないので、全てのレコードの参照処理を一瞬にして実行したようにユーザに対して見せることが可能となった。
【００２５】
また、予約参照登録されたレコードのバックアップは、指定された予約参照時刻以降でかつ当該レコードの予約参照後処理がまだ実行されていない場合に当該レコードに対して更新処理が行なわれた場合のみ実行されるため、一貫性のあるデータの参照を実現するために必要なデータのバックアップを最小限にすることが可能となった。さらに、これらのバックアップデータは、予約参照後処理実行時に削除されるため、システム全体のデータベース容量のオーバヘッドを低減することが可能となった。
【００２６】
さらに本発明では、一つのレコードに対して複数の予約アクセス登録を可能にすることで種々のシステムに対して本機能を提供することが可能となった。
【００２７】
また、本発明では、予約アクセス状態を管理するテーブルを設けることにより、予約アクセス前処理が予約アクセス時刻までに完了しなかった場合に該予約アクセス処理を取り消すための機能を提供することが可能となった。
【００２８】
【実施例】
以下、図面を用いて本発明の実施例を説明する。
【００２９】
図２３は、本発明を実施するデータベースシステムの構成を示す図である。本システムは、データベースをアクセスする複数の端末３００，３０１と、データベースをアクセスする一つ以上のアプリケーションサーバ３０３，３０４と、データベースを保持するデータベースサーバ３０２とで構成される。データベースサーバ３０２は、データベースシステム３０５およびデータベース３０８で構成される。データベースシステム３０５は、アプリケーションから発行されるＳＱＬ（Structured Query Language）などの問い合わせ処理の実行を制御する問い合わせ実行制御部３０６とデータベースをアクセスするデータベースアクセス部３０７とで構成される。本図ではデータベースサーバ３０２とアプリケーションサーバ３０３，３０４とが異なるプロセッサ上に実装されている図を示しているが、アプリケーションサーバとデータベースサーバは同一プロセッサ上に実装してもよい。また、データベースシステムは、単一のプロセッサで動作する通常のデータベースシステムだけでなく、複数のプロセッサ上で動作する並列データベースシステムであってもよい。
【００３０】
今、端末３０１でデータベースのテーブルを一括更新しようとしており、端末３００でテーブルを参照しようとしているとする。具体的な例で説明すると、アプリケーションサーバ３０４は給与振込みプログラム、アプリケーションサーバ３０３は残高照会プログラムであり、端末３０１から社員口座に給与振込を行なおうとしており、端末３００からある人が自分の口座の残高照会を行なおうとしている、と言った状況である。本発明では、このような状況のときに、一括更新処理の時刻を指定することによりデータベースの更新時刻のずれをなくし、一貫性のあるデータに参照するための手段を提供する。本発明による新しいデータベースアクセス方法は、図２３のデータベースシステム内部の問い合わせ実行制御部３０６とデータベースアクセス部３０７に実装される。以下の説明では、各実施例にしたがって、新しいデータベースアクセス方法を説明する。
【００３１】
［実施例１］
実施例１では、データベースの予約更新処理を提供するための方法について説明する。
【００３２】
図１(a) は、本実施例における予約更新処理の概要を説明する図である。横軸は時刻の流れを示し、黒い四角は各時刻において実行される処理を示している。予約更新処理は、レコードの更新を予約登録するための予約更新前処理(1) と、予約更新時刻(5)以降に行なわれる予約更新後処理(2) の２つの処理で実現される。
【００３３】
予約更新前処理(1) が完了したレコードに対して、予約更新時刻(5)以前にアクセスする場合には更新前のデータを提供し(3) 、更新時刻(5)より後で該レコードにアクセスする場合には予約更新後処理(2) を行ない予約されていた更新処理を実行してから更新後のデータを提供する(4) 。
【００３４】
このように、レコードの更新を更新時刻以降の最初のアクセスまで遅延させることにより、予約更新時刻にはレコードの更新処理を実行せずに(5) 、該予約更新時刻に全てのレコードの更新が同時に実行されたように論理的に見せることが可能となる。
【００３５】
図１(b) は、予約更新処理を実現するためのテーブル構造を示す図である。口座テーブル(6)及び支店テーブル(7)はアプリケーションが作成したデータベーステーブル（ＤＢテーブル）であり、予約更新テーブル(8)及び予約管理テーブル(9)は予約更新処理を実現するためにデータベースシステムが作成したテーブルである。
【００３６】
アプリケーションが作成したＤＢテーブルのうち、アプリケーションからは、破線で囲った部分(10)のみ直接アクセスすることができる。予約更新時刻(11及び15)とアクセスＩＤ(12及び16)は、予約更新処理を実現するためにデータベースシステムが付加した列である。ＤＢテーブルに付加した列のうち、予約更新時刻(11及び15)には、各レコードの予約更新時刻が格納される。予約更新時刻(11及び15)に何も格納されていない場合には、該レコードに対して更新の予約処理が登録されていないことを示す。アクセスＩＤ(12及び16)には、予約更新テーブル(8)にアクセスするための識別子が格納される。
【００３７】
予約更新テーブル(8)は、データベースシステム内に１つ存在し、アクセスＩＤ(13)と、予約情報(14)とで構成される。アクセスＩＤ(13)は、予約更新テーブル(8)内でユニークな識別子であり、ＤＢテーブル(6及び7)と予約更新テーブル(8)との対応を取る。予約情報(14)には、予約された更新処理の予約ＩＤ及び更新処理内容が記述される。
【００３８】
予約管理テーブル(9)は、データベースシステム内に１つ存在し、予約ＩＤ(17)、予約状態(18)、及び、予約更新時刻(19)とで構成される。予約ＩＤ(17)は、論理的に同時に実行すべき予約更新処理１つにつき１つ付与される番号であり、データベースシステム内でユニークな番号である。予約状態(18)は、前記同時に実行すべき予約更新処理の処理状態を示す。処理状態としては、予約更新前処理開始、予約更新前処理取消等がある。予約更新前処理開始は、当該予約更新の前処理を行なっている最中であることを示し、予約更新前処理取消は、当該予約更新の前処理が予約時刻までに終了しなかったため、既に登録している予約更新情報を取消中であることを示す。一方、予約更新時刻(19)は、予約更新を実行する時刻を格納している。
【００３９】
本実施例で示している予約更新は、予約ＩＤ(17)がR0050、更新時刻(19)が1992/06/10 9:00であり、現在予約更新前処理中であり、予約された更新内容としては、口座テーブル(6)の口座番号670190048のレコードの残高に200,000を加算し、口座番号670190049のレコードの残高に300,000を加算し、というようになっている。
【００４０】
本実施例で示したテーブル構造ではＤＢテーブル(6及び7)と予約更新テーブル(8)の対応や予約更新テーブル(8)と予約管理テーブル(9)との対応を取るために識別子を用いているが、ポインタ等を用いてこれらの対応を取ることももちろん可能である。
【００４１】
図２は、本実施例における予約更新前処理の流れを示す図である。予約更新前処理（２０）では、まず予約ＩＤを取得して、予約管理テーブル(9)へ該予約ＩＤならびに予約時刻の登録を行なう（ステップ２１）。予約ＩＤは、データベースシステム内でユニークな識別子である。次に、予約管理テーブル(9)の予約状態を予約更新前処理開始に設定して（ステップ２２）、全ての更新レコードについて、以下の処理を実行する。
【００４２】
まず、更新すべきレコードの内容を後述のデータベースアクセス処理（ＤＢアクセス処理）により取得する（ステップ２３）。次に、該レコードの予約更新時刻フィールド(11又は15)を確認して、既に他の予約更新が登録されているか否か判定する（ステップ２４）。既に他の予約更新が登録されていたならば、エラー処理（ステップ２９）に制御を移す。他の予約更新が登録されていない場合には、登録中の予約更新処理の予約時刻を既に過ぎていないかをチェックし（ステップ２５）、もし予約時刻を過ぎていた場合には、当該予約更新前処理が予定時刻に間に合わなかったとしてエラー処理（ステップ２９）に制御を移す。
【００４３】
ステップ２５で予約時刻を過ぎていない場合には、予約情報を予約更新テーブル(8)に登録して（ステップ２６）、次の更新レコードの処理に移る（ステップ２７）。全ての更新レコードの予約情報の登録が完了したならば（ステップ２７）、予約管理テーブル(9)から該予約更新に対応するエントリを削除して（ステップ２８）、処理を終了する。
【００４４】
一方、各レコードの予約情報の登録中にエラーが発生した場合には、まず予約管理テーブル(9)の状態を予約更新前処理取消に設定して、該予約更新前処理で登録した全ての予約情報をテーブルから削除し、最後に予約管理テーブル(9)の状態を予約更新前処理失敗に設定してエラーリターンする（ステップ２９）。
【００４５】
図３は、本実施例におけるデータベースアクセス処理（ＤＢアクセス処理）の流れを示す図である。ＤＢアクセス処理は、レコードの参照処理及びレコードの更新処理の両方を包含する。
【００４６】
ＤＢアクセス処理（３０）では、まずアクセス対象のレコードをＤＢテーブル(6又は7)から取得し（ステップ３１）、そのレコードの予約更新時刻(11又は15)が登録されており、かつ、現時刻が該予約更新時刻を過ぎているか否かを判定する（ステップ３２）。予約更新時刻を過ぎていたならば、該レコードのアクセスＩＤをキーにして予約更新テーブル(8)から予約情報(14)を取得し（ステップ３３）、該予約情報(14)に基づき後述の予約更新後処理を行ない（ステップ３４）、その後、該レコードのＤＢアクセス処理を実行する（ステップ３５）。
【００４７】
ステップ３２でアクセス対象のレコードの予約更新時刻が登録されていない場合や、該レコードの予約更新時刻がまだ過ぎていない場合には、予約更新後処理は行なわずに現在のレコードに対してＤＢアクセス処理（ステップ３５）を行なう。
【００４８】
図４は、本実施例における予約更新後処理の流れを示す図である。予約更新後処理（４０）では、まず、予約管理テーブル(9)を予約ＩＤで検索して（ステップ４１）、予約管理テーブル(9)の状態(18)を確認する（ステップ４２）。予約管理テーブル(9)の状態(18)が予約更新前処理取消以外であれば、予約情報(14)に従って当該レコードの更新処理を行ない（ステップ４３）、その後、予約更新テーブル(8)から該予約情報(14)を削除する（ステップ４４）。予約管理テーブル(9)の状態(18)が予約更新前処理取消である場合には（ステップ４２）、当該レコードの更新は行なわずに予約更新テーブル(8)から予約情報(14)を削除して（ステップ４４）、予約更新後処理を終了する。
【００４９】
本実施例では、予約更新されたレコードは、予約更新時刻以降に該レコードに対してＤＢアクセスが起こらないかぎり更新されることはない。しかしながら、通常のデータベースシステムにおいては、定期的にバックアップ作業を行なっているため、該バックアップ作業の際にＤＢアクセスが発生し、当該レコードの予約更新後処理が実行される。バックアップを取らないシステムにおいては、予約更新処理を終了させるために一定期間毎に全データベースをアクセスするクリーンナップ処理を実行することにより、予約更新後処理を実行させることができる。
【００５０】
本実施例では、ＤＢテーブルに予約更新時刻フィールドを設け、ＤＢアクセス処理時に予約更新時刻と現時刻の関係により予約更新を行なうか行なわないかを決定する処理を設けたことに特徴がある。これにより、予約更新時刻にＤＢをアクセスすることなく、アプリケーションからは、該予約更新時刻にあたかも全レコードが同時に更新されたように論理的に見える機能を提供することが可能となった。
【００５１】
また、全ての処理はテーブルのレコード単位の排他制御を用いて実現できるため、システム稼働中にも大量のレコードの一括更新を行なうことが可能である。また、予約更新前処理が完了しないうちに予約時刻を過ぎてしまった場合の予約更新情報の取り消し手段を有することも本実施例の特徴の一つである。
【００５２】
本実施例は、リレーショナル型のデータベースシステムのみならず、構造型あるいは階層型のデータベースシステム等の、レコードを単位としてアクセスするあらゆるデータベースに適用できることは明らかである。
【００５３】
［実施例２］
次に、本発明の第２の実施例を説明する。この実施例２では、データベースの予約参照処理を提供するための方法について説明する。
【００５４】
図５(a)は、本実施例における予約参照処理の概要を説明する図である。横軸は時刻の流れを示し、黒い四角は各時刻において実行される処理を示している。予約参照処理は、レコードの参照を予約登録するための予約参照前処理(51)と、参照時刻(56)以降に行なわれる予約参照後処理(52)、および、参照時刻(56)以降かつ予約参照後処理(52)以前の間に発生するＤＢ更新処理時に行なわれる予約参照バックアップ処理(53)の３つの処理で実現される。
【００５５】
予約参照前処理(51)が完了したレコードに対して、予約参照時刻(56)以前に該レコードを更新する場合には通常通り更新処理を行ない(54)、参照時刻(56)より後かつ予約参照後処理(52)以前に該レコードの更新処理を行なう場合には予約参照バックアップ処理(53)を行ない予約参照されていたレコードのバックアップを作成してから当該レコードの更新処理を行なう(55)。
【００５６】
予約参照後処理(52)では、参照レコードのバックアップが作成されている場合には該バックアップデータを参照し、バックアップがない場合には該レコードのデータを参照する。予約参照後処理(52)は、予約参照時刻(56)以降の適当なタイミングで実行する。予約参照後処理(52)を起動するタイミングは、参照時刻(56)以降にタイマにより起動をかける方法や、参照時刻(56)以降の最初のＤＢアクセス発生時点等、様々な方法により実現することができる。
【００５７】
本実施例では、予約参照後処理以前に更新が行なわれるレコードのみバックアップを作成することにより、予約参照時刻にはレコードの参照処理を実行せずに(56)、該予約参照時刻に全てのレコードの参照が同時に実行されたように論理的に見せることが可能となる。
【００５８】
図５(b)は、予約参照処理を実現するためのテーブル構造を示す図である。口座テーブル(500)及び支店テーブル(501)は、アプリケーションが作成したデータベーステーブル（ＤＢテーブル）であり、予約参照テーブル(502)、バックアップテーブル(503)及び予約管理テーブル(504)は予約参照処理を実現するためにデータベースシステムが作成したテーブルである。
【００５９】
アプリケーションが作成した ＤＢテーブルのうち、アプリケーションからは、破線で囲った部分(505)のみ直接アクセスすることができる。予約参照時刻(506及び508)とアクセスＩＤ(507及び509)は、予約参照処理を実現するためにデータベースシステムが付加した列である。ＤＢテーブルに付加した列のうち、予約参照時刻(506及び508)には、各レコードの予約参照時刻が格納される。予約参照時刻(506及び508)に何も格納されていない場合には、該レコードに対して参照の予約処理が登録されていないことを示す。アクセスＩＤ(507及び509)には、予約参照テーブル(502)にアクセスするための識別子が格納される。
【００６０】
予約参照テーブル(502)は、データベースシステム内に１つ存在し、アクセスＩＤ(510)と、予約情報(511)とで構成される。アクセスＩＤ(510)は、予約参照テーブル(502)内でユニークな識別子であり、ＤＢテーブル(500及び501)と予約参照テーブル(502)の対応を取る。予約情報(511)には、予約された参照処理の予約識別子及びバックアップ識別子が記述される。バックアップ識別子（ＩＤ）は、バックアップが存在する場合のバックアップＩＤを示し、予約参照テーブル(502)のエントリとバックアップテーブル(503)のエントリの対応を取る。予約情報(511)中のバックアップＩＤがNULL値（初期値）のときは、未だ当該レコードのバックアップを取っていないことを示す。
【００６１】
バックアップテーブル(503)は、データベースシステム内に一つ存在し、バックアップＩＤ(512)とバックアップデータ(513)とで構成される。バックアップＩＤ(512)は、バックアップテーブル(503)内でユニークな識別子である。バックアップデータ(513)には、予約参照時刻以降に更新されるレコードのバックアップ（更新する前のレコードのバックアップ）を格納する。本実施例ではバックアップはレコード単位で格納しているが、参照されるフィールドのみのバックアップを取ることももちろん可能である。
【００６２】
予約管理テーブル(504)は、データベースシステム内に１つ存在し、予約ＩＤ(514)、予約状態(515)、予約参照時刻(516)、及び、予約実行文(517)とで構成される。予約ＩＤ(514)は、論理的に同時に実行すべき予約参照処理１つにつき１つ付与される番号であり、データベースシステム内でユニークな番号である。予約状態(515)は、前記同時に実行すべき予約参照処理の処理状態を示す。処理状態としては、予約参照前処理開始、予約参照前処理完了、予約参照前処理取消等がある。予約参照前処理開始は、当該予約参照の前処理を行なっている最中であることを示し、予約参照前処理完了は、当該予約参照の前処理が正常終了したことを示し、予約参照前処理取消は、当該予約参照の前処理が予約時刻までに終了しなかったため、既に登録している予約参照情報を取消中であることを示す。一方、予約参照時刻(516)には、予約参照を実行する時刻が格納され、予約実行文には予約された参照実行文（問い合わせ実行文又は問い合わせ実行コード）が格納される。
【００６３】
本実施例で示している予約参照は、予約ＩＤ(514)がR0119、参照時刻(516)が1992/06/10 7:00であり、現在予約参照前処理完了しており、口座テーブル(500)の口座番号670191000のレコード、670191001のレコード、及び、支店テーブル(501)の支店番号670191のレコードがそれぞれ予約参照登録されている。また、口座テーブル(500)の口座番号670191000及び支店テーブル(501)の支店番号670191のレコードは予約参照時刻以降に更新処理が行なわれたため、バックアップテーブル(503)に予約参照時刻の時点におけるレコードの内容が保存されている。
【００６４】
本実施例で示したテーブル構造ではＤＢテーブルと予約参照テーブルの対応や予約参照テーブルと予約管理テーブル、あるいは、予約参照テーブルとバックアップテーブルの対応を取るためにそれぞれ識別子を用いているが、ポインタ等を用いてこれらの対応を取ることももちろん可能である。
【００６５】
図６は、本実施例における予約参照前処理の流れを示す図である。予約参照前処理（６０）では、まず予約ＩＤを取得して、予約管理テーブル(504)へ該予約ＩＤ、予約時刻および予約実行文の登録を行なう（ステップ６１）。次に、予約管理テーブル(504)の予約状態を予約参照前処理開始に設定して（ステップ６２）、全ての参照レコードについて、以下の処理を実行する。
【００６６】
まず、参照すべきレコードの内容を取得する（ステップ６３）。次に、該レコードの予約参照時刻フィールド(506又は508)を確認して、既に他の予約参照が登録されているか否か判定する（ステップ６４）。既に他の予約参照が登録されていたならば、エラー処理（ステップ６９）に制御を移す。他の予約参照が登録されていない場合には、登録中の予約参照処理の予約時刻を既に過ぎていないかをチェックし（ステップ６５）、もし予約時刻を過ぎていた場合には、当該予約参照前処理が予定時刻に間に合わなかったとしてエラー処理（ステップ６９）に制御を移す。
【００６７】
ステップ６５で予約時刻を過ぎていない場合には、予約情報を予約参照テーブル(502)に登録して（ステップ６６）、次の参照レコードの処理に移る（ステップ６７）。なお、予約情報(511)のバックアップＩＤは、NULL値（バックアップデータなし）に初期設定する。
【００６８】
全ての参照レコードの予約情報の登録が完了したならば（ステップ６７）、予約管理テーブル(504)の予約状態(515)を予約参照前処理完了に設定して（ステップ６８）、処理を終了する。
【００６９】
一方、各レコードの予約情報の登録中にエラーが発生した場合には、まず予約管理テーブル(504)の状態を予約参照前処理取消に設定して、該予約参照前処理で登録した全ての予約情報をテーブルから削除し、最後に予約管理テーブル(504)の状態を予約参照前処理失敗に設定してエラーリターンする（ステップ６９）。
【００７０】
図７は、本実施例における一行更新処理の流れを示す図である。一行更新処理は、一つのレコードの内容を更新する処理であり、データベースの更新処理の中から呼び出される。
【００７１】
一行更新処理（７０）では、まず、更新するレコードを取得して（ステップ７１）、該レコードの予約参照時刻(506又は508)をチェックする（ステップ７２）。該レコードの予約参照時刻が登録されており、かつ、現時刻が該予約参照時刻を過ぎていたならば、該レコードのアクセスＩＤ(507又は509)をキーにして予約参照テーブル(502)から予約情報(511)を取得し（ステップ７３）、後述の予約参照バックアップ処理を行なう（ステップ７４）。その後、該レコードの更新処理を実行して（ステップ７５）、処理を終了する。
【００７２】
ステップ７２でアクセス対象のレコードの予約更新時刻が登録されていない場合や、該レコードの予約更新時刻がまだ過ぎていない場合には、予約参照バックアップ処理は行なわずに現在のレコードの更新処理を行なって（ステップ７５）、処理を終了する。
【００７３】
図８は、本実施例における予約参照バックアップ処理の流れを示す図である。予約参照バックアップ処理（８０）では、まず、予約管理テーブル(504)を予約ＩＤで検索して（ステップ８５）、予約管理テーブル(504)の状態(515)を確認する（ステップ８６）。予約管理テーブル(504)の状態(515)が予約参照前処理取消であれば、エラーリターンする。
【００７４】
ステップ８６で予約管理テーブル(504)の状態(515)が予約参照前処理取消以外であれば、当該レコードに対応する予約情報(511)からバックアップＩＤを取得し、当該レコードのバックアップが存在するかどうかをチェックする（ステップ８１）。当該レコードのバックアップが既に存在する場合には、バックアップを作成する必要がないため、予約参照バックアップ処理を終了する。
【００７５】
ステップ８１で当該レコードのバックアップが存在しない場合には、バックアップＩＤを新規に取得し（ステップ８２）、該レコードの内容をバックアップテーブル(503)に登録し（ステップ８３）、予約情報(511)に取得したバックアップＩＤを書き込み（ステップ８４）、予約参照バックアップ処理を終了する。
【００７６】
図９は、本実施例における予約参照後処理の流れを示す図である。予約参照後処理（９０）では、まず、予約管理テーブル(504)を予約ＩＤで検索し、予約状態(515)及び予約実行文(517)を取得する（ステップ９１）。次に、予約管理テーブル(504)の状態(515)をチェックする（ステップ９２）。その状態が予約参照前処理取消であれば、予約参照エラーとしてリターンする。それ以外の場合には、各参照レコードについて以下の処理を実行する。
【００７７】
まず、参照レコードを通常処理通りに取得する（ステップ９３）。次に、予約参照テーブル(502)から該レコードに対応する予約情報(511)を取得し（ステップ９４）、該レコードのバックアップが存在するかどうかをチェックする（ステップ９５）。
【００７８】
バックアップデータが存在する場合には、バックアップテーブル(503)から当該レコードのバックアップデータ(513)を取得して（ステップ９６）、ステップ９７に進む。バックアップデータが存在しない場合には、ステップ９６をスキップしてステップ９７に進む。
【００７９】
そして、予約実行文に従って予約していた参照処理を実行し（ステップ９７）、その後、予約参照テーブル(502)から該予約情報(511)を削除する（ステップ９８）。このとき、該レコードのバックアップデータ(513)がある場合にはそのバックアップデータも削除する。そして、全てのレコードの参照が終了してから、予約管理テーブル(504)から該予約参照に対応するエントリを削除して（ステップ９９）、予約参照後処理を終了する。
【００８０】
本実施例では、予約参照されたレコードについては、予約参照時刻以降に該レコードに対して更新処理が起こらないかぎり該レコードのバックアップは作成しない。また、予約参照後処理が終了すると該予約参照処理のために生成したバックアップは全て消去されるため、データベースの領域を長時間取り続けることがない。したがって、最小限のバックアップにより論理的に一貫性のある大規模データの参照を行なうことが可能である。
【００８１】
また、全ての処理はテーブルのレコード単位の排他制御を用いて実現できるため、システム稼働中にも大量のレコードの同時参照を行なうことが可能である。また、予約参照前処理が完了しないうちに予約時刻を過ぎてしまった場合の予約参照情報の取り消し手段を有することも本実施例の特徴の一つである。
【００８２】
本実施例は、リレーショナル型のデータベースシステムのみならず、構造型あるいは階層型のデータベースシステム等の、レコードを単位としてアクセスするあらゆるデータベースに適用できることは明らかである。
【００８３】
［実施例３］
次に、本発明の第３の実施例を説明する。本実施例３では、データベースの予約更新ならびに予約参照を同時に提供するための方法について説明する。
【００８４】
図１０は、本実施例における予約更新ならびに予約参照の処理の概要を説明する図である。横軸は時刻の流れを示し、黒い四角は各時刻において実行される処理を示している。予約更新処理は、実施例１と同様に、予約更新前処理(101)と、予約更新後処理(102)の２つの処理で実現される。一方、予約参照処理は、実施例２と同様に、予約参照前処理(103)と、予約参照バックアップ処理(104)と、予約参照後処理(105)の３つの処理で実現される。
【００８５】
予約更新処理に関しては、予約更新前処理(101)が完了したレコードに対して予約更新時刻以前にアクセスした場合には更新前のデータを提供し(106)、更新時刻より後で該レコードにアクセスした場合には予約更新後処理(102)を行ない予約されていた更新処理を実行してから更新後のデータを提供する(107)。
【００８６】
一方、予約参照処理に関しては、予約参照前処理(103)が完了したレコードに対して、予約参照時刻以前に該レコードを更新した場合には通常通り更新処理を行ない(108)、参照時刻より後かつ予約参照後処理(105)以前に該レコードを更新した場合には予約参照バックアップ処理(104)を行ない予約参照されていたレコードのバックアップを作成してから該レコードの更新処理を行なう(109)。
【００８７】
予約参照後処理(105)では、参照レコードのバックアップが作成されている場合には該バックアップデータを参照し、バックアップがない場合には該レコードのデータを参照する。予約参照後処理(105)は、予約参照時刻以降の適当なタイミングで実行する。予約参照後処理(105)を起動するタイミングは、参照時刻以降にタイマにより起動をかける方法や、参照時刻以降の最初のＤＢアクセス発生時点等、様々な方法により実現することができる。
【００８８】
図１１は、予約更新及び予約参照処理を実現するためのテーブル構造を示す図である。口座テーブル(110)及び支店テーブル(111)はアプリケーションが作成したデータベーステーブル（ＤＢテーブル）であり、予約アクセステーブル(112)、バックアップテーブル(113)及び予約管理テーブル(114)は予約更新及び予約参照処理を実現するためにデータベースシステムが作成したテーブルである。
【００８９】
アプリケーションが作成した ＤＢテーブルのうち、アプリケーションからは、破線で囲った部分(115)のみ直接アクセスすることができる。予約アクセス時刻(1101及び1103)とアクセスＩＤ(1102及び1104)は、予約更新及び予約参照処理を実現するためにデータベースシステムが付加した列である。ＤＢテーブルに付加した列のうち、予約アクセス時刻(1101及び1103)には、各レコードの予約アクセス時刻が格納される。予約アクセス時刻(1101及び1103)に何も格納されていない場合には、該レコードに対して更新又は参照の予約処理が行なわれていないことを示す。アクセスＩＤ(1102及び1104)には、予約アクセステーブルにアクセスするための識別子が格納される。
【００９０】
予約アクセステーブル(112)は、データベースシステム内に１つ存在し、アクセスＩＤ(1105)と、予約情報(1106)とで構成される。アクセスＩＤ(1105)は、予約アクセステーブル内でユニークな識別子であり、ＤＢテーブル(110及び111)と予約アクセステーブル(112)の対応を取る。予約情報(1106)には、予約された処理の種別（更新又は参照）と該処理の予約識別子（ＩＤ）が格納される。さらに、付加情報として、更新処理の場合には更新処理内容が格納され、参照処理の場合にはバックアップ識別子が記述される。バックアップ識別子は、バックアップが存在する場合のバックアップＩＤを示し、予約アクセステーブル(112)のエントリとバックアップテーブル(113)のエントリの対応を取る。
【００９１】
バックアップテーブル(113)は、データベースシステム内に一つ存在し、バックアップＩＤ(1107)とバックアップデータ(1108)とで構成される。バックアップＩＤ(1107)は、バックアップテーブル(113)内でユニークな識別子である。バックアップデータ(1108)には、予約アクセス時刻以降に更新されたレコードのバックアップ（更新前の状態のバックアップ）を格納する。本実施例ではバックアップはレコード単位で格納しているが、参照されるフィールドのみのバックアップを取ることももちろん可能である。
【００９２】
予約管理テーブル(114)は、データベースシステム内に１つ存在し、予約ＩＤ(1109)、予約状態(1110)、予約アクセス時刻(1111)、及び、予約実行文(1112)とで構成される。
【００９３】
予約ＩＤ(1109)は、論理的に同時に実行すべき予約アクセス処理１つにつき１つ付与される番号であり、データベースシステム内でユニークな番号である。予約状態(1110)は、前記同時に実行すべき予約参照処理の処理状態を示す。処理状態としては、予約更新前処理開始、予約更新前処理取消、予約参照前処理開始、予約参照前処理完了、予約参照前処理取消等がある。予約更新前処理開始及び予約参照前処理開始は、当該予約アクセスの前処理を行なっている最中であることを示し、予約参照前処理完了は、当該予約参照の前処理が正常終了したことを示し、予約更新前処理取消及び予約参照前処理取消は、当該予約アクセスの前処理が予約時刻までに終了しなかったため、既に登録している予約情報を取消中であることを示す。
【００９４】
一方、予約アクセス時刻(1111)には、予約アクセスを実行する時刻が格納され、予約実行文(1112)には、予約された参照実行文（問い合わせ実行文又は問い合わせ実行コード）が格納される。
【００９５】
本実施例では、予約ＩＤがR0050の予約更新処理、予約ＩＤがR0119の予約参照処理、及び予約ＩＤがR0120の予約参照処理がそれぞれ登録されている。予約ＩＤがR0050の予約更新処理は、更新時刻が1992/06/10 9:00であり、現在、予約更新前処理が完了しており、口座テーブルの口座番号670190048のレコードの残高に200,000を加算し、口座番号670190049のレコードの残高に300,000を加算する、という内容である。予約ＩＤがR0119の予約参照処理は、参照時刻が1992/06/10 7:00であり、現在予約参照前処理完了しており、口座テーブルの口座番号670191000のレコード、670191001のレコード、及び、支店テーブルの支店番号670191のレコードがそれぞれ予約参照登録されており、口座テーブルの口座番号670191000及び支店テーブルの支店番号670191のレコードは予約アクセス時刻以降に更新処理が行なわれたため、バックアップテーブルに予約アクセス時刻の時点におけるレコードの内容が保存されている。
【００９６】
本実施例で示したテーブル構造ではＤＢテーブルと予約アクセステーブルの対応や予約アクセステーブルと予約管理テーブル、あるいは、予約アクセステーブルとバックアップテーブルの対応を取るためにそれぞれ識別子を用いているが、ポインタ等を用いてこれらの対応を取ることももちろん可能である。
【００９７】
図１２は、本実施例における予約更新前処理の流れを示す図である。予約更新前処理（１２０）では、まず予約ＩＤを取得して、予約管理テーブル(114)へ該予約ＩＤならびに予約時刻の登録を行なう（ステップ１２１）。予約ＩＤは、データベースシステム内でユニークな識別子である。次に、予約管理テーブル(114)の予約状態(1110)を予約更新前処理開始に設定して（ステップ１２２）、全ての更新レコードについて、以下の処理を実行する。
【００９８】
まず、更新すべきレコードの内容を後述の１行参照処理により取得する（ステップ１２３）。次に、該レコードの予約アクセス時刻フィールド(1101又は1103)を確認して、既に他の予約アクセスが登録されているか否かを判定する（ステップ１２４）。既に他の予約アクセスが登録されていたならば、エラー処理（ステップ１２９）に制御を移す。他の予約アクセスが登録されていない場合には、登録中の予約更新処理の予約時刻を既に過ぎていないかをチェックし（ステップ１２５）、もし予約時刻を過ぎていた場合には、当該予約更新前処理が予定時刻に間に合わなかったとしてエラー処理（ステップ１２９）に制御を移す。
【００９９】
ステップ１２５で予約時刻を過ぎていない場合には、予約情報を予約アクセステーブル(112)に登録して（ステップ１２６）、次の更新レコードの処理に移る（ステップ１２７）。なお、予約情報(1106)の処理の種別は更新処理に設定し、更新処理内容には更新する列名及び更新情報を設定する。
【０１００】
全ての更新レコードの予約情報の登録が完了したならば（ステップ１２７）、予約管理テーブル(114)から該予約更新に対応するエントリを削除して（ステップ１２８）、処理を終了する。
【０１０１】
一方、各レコードの予約情報の登録中にエラーが発生した場合には、まず予約管理テーブル(114)の状態(1110)を予約更新前処理取消に設定して、該予約更新前処理で登録した全ての予約情報をテーブルから削除し、最後に予約管理テーブル(114)の状態(1110)を予約更新前処理失敗に設定してエラーリターンする（ステップ１２９）。
【０１０２】
図１３は、本実施例における予約参照前処理の流れを示す図である。予約参照前処理（１３０）では、まず予約ＩＤを取得して、予約管理テーブル(114)へ該予約ＩＤ、予約時刻ならびに予約実行文の登録を行なう（ステップ１３１）。次に、予約管理テーブル(114)の予約状態(1110)を予約参照前処理開始に設定して（ステップ１３２）、全ての参照レコードについて、以下の処理を実行する。
【０１０３】
まず、参照すべきレコードを後述の１行参照処理により取得する（ステップ１３３）。次に、該レコードの予約アクセス時刻フィールド(1101又は1103)を確認して、既に他の予約アクセスが登録されているか否かを判定する（ステップ１３４）。既に他の予約アクセスが登録されていたならば、エラー処理（ステップ１３９）に制御を移す。他の予約アクセスが登録されていない場合には、登録中の予約参照処理の予約時刻を既に過ぎていないかをチェックし（ステップ１３５）、もし予約時刻を過ぎていた場合には、当該予約参照前処理が予定時刻に間に合わなかったとしてエラー処理（ステップ１３９）に制御を移す。
【０１０４】
ステップ１３５で予約時刻を過ぎていない場合には、予約情報を予約アクセステーブル(112)に登録して（ステップ１３６）、次の参照レコードの処理に移る（ステップ１３７）。なお、予約情報(1106)の処理の種別は参照に設定し、バックアップＩＤはNULL値（バックアップデータなし）に初期設定する。
【０１０５】
全ての参照レコードの予約情報の登録が完了したならば（ステップ１３７）、予約管理テーブル(114)の予約状態(1110)を予約参照前処理完了に設定して（ステップ１３８）、処理を終了する。
【０１０６】
一方、各レコードの予約情報の登録中にエラーが発生した場合には、まず予約管理テーブル(114)の状態(1110)を予約参照前処理取消に設定して、該予約参照前処理で登録した全ての予約情報をテーブルから削除し、最後に予約管理テーブル(114)の状態(1110)を予約参照前処理失敗に設定してエラーリターンする（ステップ１３９）。
【０１０７】
図１４は、本実施例における一行更新処理の流れを示す図である。一行更新処理は、一つのレコードの内容を更新する処理であり、データベースの更新処理の中から呼び出される。
【０１０８】
一行更新処理（１４０）では、まず、更新するレコードを取得して（ステップ１４１）、該レコードの予約アクセス時刻(1101又は1103)をチェックする（ステップ１４２）。該レコードの予約アクセス時刻が登録されていたなら、現時刻が該予約アクセス時刻を過ぎているか否か判定する（ステップ１４３）。該レコードの予約アクセス時刻が登録されており、かつ現時刻が該予約アクセス時刻を過ぎていたならば、該レコードのアクセスＩＤ(1102又は1104)をキーにして予約アクセステーブル(112)から予約情報(1106)を取得し（ステップ１４４）、予約情報(1106)のアクセス種別をチェックする（ステップ１４５）。
【０１０９】
予約情報(1106)のアクセス種別が更新の場合には、後述の予約更新後処理を行ない（ステップ１４６）、アクセス種別が参照の場合には、予約参照バックアップ処理を行なう（ステップ１４７）。そして、最後に、該レコードの更新処理を実行する（ステップ１４８）。予約参照バックアップ処理は、実施例２で説明した処理と全く同様である。
【０１１０】
ステップ１４２，１４３で、アクセス対象のレコードの予約アクセス時刻が登録されていない場合や、該レコードの予約アクセス時刻がまだ過ぎていない場合には、通常通りレコードの更新処理（ステップ１４８）を行なう。
【０１１１】
図１５は、本実施例における一行参照処理の流れを示す図である。一行参照処理は、一つのレコードの内容を参照する処理であり、データベースの参照処理の中から呼び出される。
【０１１２】
一行参照処理（１５０）では、まず、参照するレコードを取得して（ステップ１５１）、該レコードの予約アクセス時刻(1101又は1103)をチェックする（ステップ１５２）。該レコードの予約アクセス時刻が登録されていたなら、現時刻が該予約アクセス時刻を過ぎているか否か判定する（ステップ１５３）。該レコードの予約アクセス時刻が登録されており、かつ現時刻が該予約アクセス時刻を過ぎていたならば、該レコードのアクセスＩＤ(1102又は1104)をキーにして予約アクセステーブル(112)から予約情報(1106)を取得し（ステップ１５４）、予約情報(1106)のアクセス種別をチェックする（ステップ１５５）。
【０１１３】
予約情報(1106)のアクセス種別が更新の場合には、後述の予約更新後処理を行ない（ステップ１５６）、更新後のデータを参照データとして呼び出し元にリターンする。ステップ１５５でアクセス種別が参照の場合には、該レコードのデータをそのまま参照データとして呼び出し元にリターンする。
【０１１４】
ステップ１５２，１５３でアクセス対象のレコードの予約アクセス時刻が登録されていない場合や、該レコードの予約アクセス時刻がまだ過ぎていない場合にも、該レコードのデータをそのまま参照データとして呼び出し元にリターンする。
【０１１５】
図１６は、本実施例における予約更新後処理の流れを示す図である。予約更新後処理（１６０）では、まず、予約管理テーブル(114)を予約ＩＤで検索して（ステップ１６１）、予約管理テーブル(114)の状態(1110)を確認する（ステップ１６２）。次に、予約管理テーブル(114)の状態(1110)が予約更新前処理取消以外であれば、予約情報(1106)に従って当該レコードの更新処理を行ない（ステップ１６３）、その後、予約アクセステーブル(112)から該予約情報(1106)を削除する（ステップ１６４）。ステップ１６２で予約管理テーブル(114)の状態(1110)が予約更新前処理取消の場合には、当該レコードの更新は行なわずに予約アクセステーブル(112)から予約情報(1106)を削除して（ステップ１６４）、予約更新後処理を終了する。
【０１１６】
図１７は、本実施例における予約参照後処理の流れを示す図である。予約参照後処理（１７０）では、まず、予約管理テーブル(114)を予約ＩＤで検索し、予約状態(1110)及び予約実行文(1112)を取得する（ステップ１７１）。次に、予約管理テーブル(114)の状態(1110)が予約参照前処理取消であれば、予約参照エラーとしてリターンする。それ以外の場合には、各参照レコードについて以下の処理を実行する。
【０１１７】
まず、参照レコードを通常処理通りに取得する（ステップ１７３）。次に、予約アクセステーブル(112)から該レコードに対応する予約情報(1106)を取得し（ステップ１７４）、該レコードのバックアップが存在するかどうかをチェックする（ステップ１７５）。バックアップデータが存在する場合には、バックアップテーブル(113)から当該レコードのバックアップデータ(1108)を取得して（ステップ１７６）、ステップ１７７に進む。バックアップデータ(1108)が存在しない場合には、そのままステップ１７７に進む。
【０１１８】
そして、予約実行文に従って予約していた参照処理を実行し（ステップ１７７）、その後、予約アクセステーブル(112)から該予約情報(1106)を削除する（ステップ１７８）。このとき、該レコードのバックアップデータ(1108)がある場合には、そのバックアップデータも削除する。そして、全てのレコードの参照が終了してから、予約管理テーブル(114)から該予約参照に対応するエントリを削除して（ステップ１７９）、予約参照後処理を終了する。
【０１１９】
本実施例は、実施例１で述べた予約更新処理と実施例２で述べた予約参照処理を同時に実現するところに特徴がある。本実施例では、これらの処理を同時に実現するために予約情報としてアクセス種別を追加し、１行更新処理及び１行参照処理において該アクセス種別を判定して、予約更新後処理を行なうか、バックアップ処理を行なうかを決定しているところに特徴がある。
【０１２０】
本実施例では、予約更新及び予約参照の処理をデータベースシステムの機能として実現することにより、大量レコードの更新処理および大量レコードの参照を一瞬で行なうようにアプリケーションプログラムに見せることが可能となる。このため、従来、データベースシステムを一時停止させて行なわなければならなかった、データのバックアップ処理やデータベースの統計処理、給与振込みのオンラインバッチ処理等の、種々の大規模データベース処理を、システム稼働中に行なうことが可能となる。これにより、銀行オンラインの２４時間連続運転等のデータベースシステムの無停止運転機能が容易に実現可能となる。
【０１２１】
なお、本実施例は、リレーショナル型のデータベースシステムのみならず、構造型あるいは階層型のデータベースシステム等の、レコードを単位としてアクセスするあらゆるデータベースに適用できることは明らかである。
【０１２２】
［実施例４］
上記実施例１から実施例３までの予約アクセス処理では、一つのレコードには１つの予約アクセス処理しか登録できず、既に予約アクセスが登録されているレコードに対して新たな予約アクセスを登録するとエラーリターンする仕様となっていた。
【０１２３】
そこで、実施例４では一つのレコードに対して複数の予約アクセスを登録可能にする複数予約アクセス登録機能を実現する方法について説明する。本実施例では、実施例３で示した予約更新ならびに予約参照を同時に実現する方法に複数予約アクセス登録機能を追加した例を示すが、実施例１及び実施例２に複数予約アクセス登録機能を追加することも、同様の方式で容易に実現することが可能である。
【０１２４】
図１８は、複数予約アクセス登録機能を実現するためのテーブル構造を示す図である。口座テーブル(181)及び支店テーブル(182)はアプリケーションが作成したデータベーステーブル（ＤＢテーブル）であり、予約アクセステーブル(183)、バックアップテーブル(184)及び予約管理テーブル(185)は複数予約アクセス登録機能を実現するためにデータベースシステムが作成したテーブルである。
【０１２５】
アプリケーションが作成した ＤＢテーブルのうち、アプリケーションからは、破線で囲った部分(186)のみ直接アクセスすることができる。予約アクセス時刻(1801及び1803)とアクセスＩＤ(1802及び1804)は、予約更新及び予約参照処理を実現するためにデータベースシステムが付加した列である。ＤＢテーブルに付加した列のうち、予約アクセス時刻(1801及び1803)には、各レコードに登録されている予約アクセス処理のうち、最も処理時間が早い処理の予約アクセス時刻が格納される。予約アクセス時刻(1801及び1803)に何も格納されていない場合には、該レコードに対して更新又は参照の予約処理が登録されていないことを示す。アクセスＩＤ(1802及び1804)には、各レコードに登録されている予約アクセス処理のうち、最も処理時間が早い処理に対応する識別子が格納される。
【０１２６】
予約アクセステーブル(183)は、データベースシステム内に１つ存在し、アクセスＩＤ(1805)と、予約情報(1806)と、該予約アクセス処理の次に登録されている次予約アクセス時刻(1807)と、次アクセスＩＤ(1808)とから構成される。
【０１２７】
アクセスＩＤ(1805)は、予約アクセステーブル(183)内でユニークな識別子であり、ＤＢテーブル(181及び182)と予約アクセステーブル(183)の対応を取る。予約情報(1806)には、予約されたアクセス種別（更新又は参照）と該処理の予約識別子が格納される。さらに、付加情報として、更新処理の場合には更新処理内容が格納され、参照処理の場合にはバックアップ識別子が記述される。
【０１２８】
一つのレコードに複数の予約アクセスがある場合には、該複数の予約アクセス処理を予約時刻の早い順に並べて予約アクセステーブル(183)の次予約時刻(1807)と次予約アクセスＩＤ(1808)に順次登録する。次予約アクセス時刻(1807)ならびに次アクセスＩＤ(1808)が未登録の場合は、該予約アクセスが、該レコードに登録されている予約アクセス処理の最後であることを示す。このような予約アクセステーブル(183)のエントリのチェインのことを、以下の説明では、予約アクセスリストと呼ぶ。
【０１２９】
バックアップテーブル(184)は、データベースシステム内に一つ存在し、バックアップＩＤ(1810)とバックアップデータ(1811)とで構成される。バックアップＩＤ(1810)は、バックアップテーブル(184)内でユニークな識別子である。バックアップＩＤ(1810)は、バックアップが存在する場合のバックアップ識別子を示し、予約アクセステーブル(183)のエントリとバックアップテーブル(184)のエントリとの対応を取る。バックアップデータ(1811)には、予約アクセス時刻以降に更新されたレコードのバックアップを格納する。本実施例ではバックアップはレコード単位で格納しているが、参照されるフィールドのみのバックアップを取ることももちろん可能である。
【０１３０】
予約管理テーブル(185)は、データベースシステム内に１つ存在し、予約ＩＤ(1812)、予約状態(1813)、予約アクセス時刻(1814)、及び、予約実行文(1815)とで構成される。
【０１３１】
予約ＩＤ(1812)は、論理的に同時に実行すべき予約アクセス処理１つにつき１つ付与される番号であり、データベースシステム内でユニークな番号である。予約状態(1813)は、前記同時に実行すべき予約参照処理の処理状態を示す。処理状態としては、予約更新前処理開始、予約更新前処理取消、予約参照前処理開始、予約参照前処理完了、予約参照前処理取消等がある。予約更新前処理開始及び予約参照前処理開始は、当該予約アクセスの前処理を行なっている最中であることを示し、予約参照前処理完了は、当該予約参照の前処理が正常終了したことを示し、予約更新前処理取消及び予約参照前処理取消は、当該予約アクセスの前処理が予約時刻までに終了しなかったため、既に登録している予約情報を取消中であることを示す。
【０１３２】
一方、予約アクセス時刻(1814)には、予約アクセスを実行する時刻が格納され、予約実行文(1815)には、予約された参照実行文（問い合わせ実行文又は問い合わせ実行コード）が格納される。
【０１３３】
本実施例では、予約ＩＤがR0050の予約更新処理及び、予約ＩＤがR0119の予約参照処理、予約ＩＤがR0120の予約参照処理がそれぞれ登録されている。口座テーブルの口座番号670190049のレコードには、アクセスＩＤがA0002の予約更新処理と、アクセスＩＤがA0350の予約参照処理の２つの予約アクセス処理が登録されている。アクセスＩＤがA0002の予約更新処理の予約時刻が9:00、アクセスＩＤがA0350の予約参照処理の予約時刻が12:00であるので、アクセスＩＤがA0002の予約更新処理が予約アクセスリストの先頭に登録されており、アクセスＩＤがA0350の予約参照処理が予約アクセスリストの次の部分に登録されている。
【０１３４】
本実施例で示したテーブル構造ではＤＢテーブルと予約アクセステーブルの対応や予約アクセステーブルと予約管理テーブル、あるいは、予約アクセステーブルとバックアップテーブルの対応を取るためにそれぞれ識別子を用いているが、ポインタ等を用いてこれらの対応を取ることももちろん可能である。
【０１３５】
図１９は、本実施例における予約更新前処理の流れを示す図である。予約更新前処理では、まず予約管理テーブル(185)の予約アクセス時刻(1814)を、登録しようとしている予約アクセスの予約アクセス時刻で検索し（ステップ１９０）、該アクセス時刻と一致する予約アクセスが存在しその状態が前処理開始であるか否かを判定する（ステップ１９１）。該アクセス時刻と一致する予約アクセスが存在しその状態が前処理開始であれば、他の予約アクセス前処理と衝突しているため、エラーリターンする。該エラーリターンを受け取ったアプリケーションプログラムは、予約アクセス時刻を変更するか、あるいは、現在実行中の予約アクセス前処理が終了するまで待つかのいずれかの処理を行なうことによりエラー状態から回復することが可能である。
【０１３６】
予約アクセス前処理の衝突チェック（ステップ１９１）が完了したならば、予約ＩＤを取得して、予約管理テーブル(185)へ該予約ＩＤならびに予約時刻の登録を行ない（ステップ１９２）、予約管理テーブル(185)の予約状態(1813)を予約更新前処理開始に設定する（ステップ１９３）。そして、全ての更新レコードについて、以下の処理を実行する。
【０１３７】
まず、更新すべきレコードの内容を後述の１行参照処理により取得する（ステップ１９４）。次に、登録中の予約更新処理の予約時刻を既に過ぎていないかをチェックし（ステップ１９５）、もし予約時刻を過ぎていた場合には、当該予約更新前処理が予定時刻に間に合わなかったとしてエラー処理（ステップ１９９）に制御を移す。
【０１３８】
ステップ１９５で予約時刻を過ぎていない場合には、予約情報を予約アクセステーブル(183)に登録して（ステップ１９６）、次の更新レコードの処理に移る（ステップ１９７）。予約情報(1806)のアクセステーブル(183)への登録は、該更新レコードに既に登録されている予約アクセスリストのうち、該予約アクセス時刻より遅いアクセス時刻を持つ予約情報の直前に該予約アクセス情報を登録する。該予約アクセス時刻より遅いアクセス時刻を持つ予約情報がない場合には、予約アクセスリストの最後に該予約アクセス情報を登録する。予約情報(1806)の処理の種別は更新処理に設定し、更新処理内容には更新する列名及び更新情報を設定する。
【０１３９】
全ての更新レコードの予約情報の登録が完了したならば（ステップ１９７）、予約管理テーブル(185)から該予約更新に対応するエントリを削除して（ステップ１９８）、処理を終了する。
【０１４０】
一方、各レコードの予約情報の登録中にエラーが発生した場合には、まず予約管理テーブル(185)の状態を予約更新前処理取消に設定して、該予約更新前処理で登録した全ての予約情報をテーブルから削除し、最後に予約管理テーブル(185)の状態を予約更新前処理失敗に設定してエラーリターンする（ステップ１９９）。
【０１４１】
図２０は、本実施例における予約参照前処理の流れを示す図である。予約参照前処理では、まず予約管理テーブル(185)の予約アクセス時刻(1814)を、登録しようとしている予約アクセスの予約アクセス時刻で検索し（ステップ２００）、該アクセス時刻と一致する予約アクセスが存在しその状態が前処理開始であるか否かを判定する（ステップ２０１）。該アクセス時刻と一致する予約アクセスが存在しその状態が前処理開始であれば、他の予約アクセス前処理と衝突しているため、エラーリターンする。該エラーリターンを受け取ったアプリケーションプログラムは、予約アクセス時刻を変更するか、あるいは、現在実行中の予約アクセス前処理が終了するまで待つかのいずれかの処理を行なうことにより、エラー状態から回復することが可能である。
【０１４２】
予約アクセス前処理の衝突チェック（ステップ２０１）が完了したならば、予約ＩＤを取得して、予約管理テーブル(185)へ該予約ＩＤ、予約時刻ならびに予約実行文の登録を行い（ステップ２０２）、予約管理テーブル(185)の予約状態(1813)を予約参照前処理開始に設定する（ステップ２０３）。次に、全ての参照レコードについて、以下の処理を実行する。
【０１４３】
まず、参照すべきレコードを後述の１行参照処理により取得する（ステップ２０４）。次に、登録中の予約参照処理の予約時刻を既に過ぎていないかをチェックし（ステップ２０５）、もし予約時刻を過ぎていた場合には、当該予約参照前処理が予定時刻に間に合わなかったとしてエラー処理（ステップ２０９）に制御を移す。
【０１４４】
ステップ２０５で予約時刻を過ぎていない場合には、予約情報を予約アクセステーブル(183)に登録して（ステップ２０６）、次の参照レコードの処理に移る（ステップ２０７）。予約情報(1806)のアクセステーブル(183)への登録は、該更新レコードに既に登録されている予約アクセスリストのうち、該予約アクセス時刻より遅いアクセス時刻を持つ予約情報の直前に該予約アクセス情報を登録する。該予約アクセス時刻より遅いアクセス時刻を持つ予約情報がない場合には、予約アクセスリストの最後に該予約アクセス情報を登録する。予約情報(1806)の処理の種別は参照に設定し、バックアップＩＤはNULL値（バックアップデータなし）に初期設定する。
【０１４５】
全ての参照レコードの予約情報の登録が完了したならば（ステップ２０７）、予約管理テーブル(185)の予約状態(1813)を予約参照前処理完了に設定して処理を終了する。
【０１４６】
一方、各レコードの予約情報の登録中にエラーが発生した場合には、まず予約管理テーブル(185)の状態を予約参照前処理取消に設定して、該予約参照前処理で登録した全ての予約情報をテーブルから削除し、最後に予約管理テーブル(185)の状態を予約参照前処理失敗に設定してエラーリターンする（ステップ２０９）。
【０１４７】
図２１は、本実施例における一行更新処理の流れを示す図である。一行更新処理は、一つのレコードの内容を更新する処理であり、データベースの更新処理の中から呼び出される。
【０１４８】
一行更新処理では、まず、更新するレコードを取得して（ステップ２１０）、該レコードの予約アクセス時刻(1801又は1803)をチェックする（ステップ２１１）。アクセス対象のレコードの予約アクセス時刻が登録されていたら、現在の時刻が該レコードの予約アクセス時刻を過ぎたか否かを判定する（ステップ２１２）。アクセス対象のレコードの予約アクセス時刻が登録されていない場合、または該レコードの予約アクセス時刻がまだ過ぎていない場合には、通常通りレコードの更新処理（ステップ２１９）を行なう。
【０１４９】
ステップ２１１，２１２で、該レコードの予約アクセス時刻が登録されており、かつ、現時刻が該予約アクセス時刻を過ぎていたならば、該レコードのアクセスＩＤ(1802又は1804)をキーにして予約アクセステーブル(183)から予約情報(1806)を取得し（ステップ２１３）、予約情報のアクセス種別をチェックする。
【０１５０】
予約情報(1806)のアクセス種別が更新の場合には、予約更新後処理を行ない（ステップ２１４）、アクセス種別が参照の場合には、予約参照バックアップ処理を行なう（ステップ２１５）。予約更新後処理は実施例３で説明した処理と全く同様であり、予約参照バックアップ処理は実施例２で説明した処理と全く同様である。
【０１５１】
次に、予約アクセステーブル(183)の次予約アクセス時刻(1807)を確認し（ステップ２１６）、次予約アクセス時刻(1807)の指定がある場合は、現時刻がその次予約アクセス時刻を過ぎているか否かを判定する（ステップ２１７）。次予約アクセス時刻の指定があり、かつ、現時刻が次予約アクセス時刻を過ぎていたならば、予約アクセステーブル(183)を次アクセスＩＤ(1808)で検索して次に登録されている予約情報(1806)を取得し（ステップ２１８）、アクセス種別のチェックに戻る。
【０１５２】
ステップ２１６，２１７で、次予約アクセス時刻が登録されていない場合や、次予約アクセス時刻をまだ過ぎていない場合には、予約アクセス処理のループを脱出し、該レコードの更新処理（ステップ２１９）を実行する。
【０１５３】
図２２は、本実施例における一行参照処理の流れを示す図である。一行参照処理は、一つのレコードの内容を参照する処理であり、データベースの参照処理の中から呼び出される。
【０１５４】
一行参照処理では、まず、参照するレコードを取得して（ステップ２２０）、該レコードの予約アクセス時刻(1801又は1803)をチェックする（ステップ２２１）。アクセス対象のレコードの予約アクセス時刻が登録されている場合は、現時刻が該レコードの予約アクセス時刻を過ぎているか否かを判定する（ステップ２２２）。アクセス対象のレコードの予約アクセス時刻が登録されていない場合や、該レコードの予約アクセス時刻がまだ過ぎていない場合には、該レコードのデータをそのまま参照データとして呼び出し元にリターンする。
【０１５５】
ステップ２２１，２２２で、該レコードの予約アクセス時刻が登録されており、かつ、現時刻が該予約アクセス時刻を過ぎていたならば、該レコードのアクセスＩＤ(1802又は1804)をキーにして予約アクセステーブル(183)から予約情報(1806)を取得し（ステップ２２３）、予約情報(1806)のアクセス種別をチェックする。
【０１５６】
予約情報(1806)のアクセス種別が参照の場合には、現在のデータを参照データとするとともに、予約参照フラグをオンにして（ステップ２２７）、ステップ２２８に進む。
【０１５７】
予約情報(1806)のアクセス種別が更新の場合には、予約参照フラグがオンであるか否かを判定し（ステップ２２４）、オンであれば、予約参照バックアップ処理を行なってから（ステップ２２５）、予約更新後処理を行ない（ステップ２２６）、ステップ２２８に進む。ステップ２２４で、予約参照フラグがオフであれば、予約更新後処理（ステップ２２６）のみを行なう。予約更新後処理を行なった場合には更新後のデータを参照データとする。予約更新後処理は実施例３で説明した処理と全く同様であり、予約参照バックアップ処理は実施例２で説明した処理と全く同様である。
【０１５８】
次に、予約アクセステーブル(183)の次予約アクセス時刻(1807)を確認し（ステップ２２８）、次予約アクセス時刻(1807)の指定があれば、現時刻がその次予約アクセス時刻を過ぎているか否かを判定する（ステップ２２９）。次予約アクセス時刻の指定があり、かつ、現時刻が次予約アクセス時刻を過ぎていたならば、予約アクセステーブル(183)を次アクセスＩＤ(1808)で検索して次に登録されている予約情報(1806)を取得し（ステップ２３０）、アクセス種別のチェックに戻る。
【０１５９】
ステップ２２８，２２９で、次予約アクセス時刻(1807)が登録されていない場合や次予約アクセス時刻をまだ過ぎていない場合には、予約アクセス処理のループを脱出し、参照データを呼び出し元にリターンする。
【０１６０】
本実施例によれば、複数の予約アクセスを登録することができる。
【０１６１】
【発明の効果】
本発明によれば、複数のレコードの一括更新ならびに同時参照を行なうデータベースシステムにおいて、該複数のレコードへのアクセスをあらかじめ時刻指定で予約登録しておくことにより、該予約時刻に同時に更新又は参照が実行されたようにアプリケーションプログラムに対してみせることを可能とした。本発明では、登録された予約アクセス処理を予約時刻以前に行なう予約アクセス前処理と、予約時刻以降に実行される予約アクセス後処理に分割して実行することにより、データベースシステムを停止することなく大量レコードの一括更新および参照を実行することを可能とした。
【図面の簡単な説明】
【図１】第１の実施例における処理概要図およびテーブル構成図
【図２】第１の実施例における予約更新前処理の流れ図
【図３】第１の実施例におけるDBアクセス処理の流れ図
【図４】第１の実施例における予約更新後処理の流れ図
【図５】第２の実施例における処理概要図およびテーブル構成図
【図６】第２の実施例における予約参照前処理の流れ図
【図７】第２の実施例における１行更新処理の流れ図
【図８】第２の実施例における予約参照バックアップ処理の流れ図
【図９】第２の実施例における予約参照後処理の流れ図
【図１０】第３の実施例における処理の概要図
【図１１】第３の実施例におけるテーブル構成図
【図１２】第３の実施例における予約更新前処理の流れ図
【図１３】第３の実施例における予約参照前処理の流れ図
【図１４】第３の実施例における１行更新処理の流れ図
【図１５】第３の実施例における１行参照処理の流れ図
【図１６】第３の実施例における予約更新後処理の流れ図
【図１７】第３の実施例における予約参照後処理の流れ図
【図１８】第４の実施例におけるテーブル構成図
【図１９】第４の実施例における予約更新前処理の流れ図
【図２０】第４の実施例における予約参照前処理の流れ図
【図２１】第４の実施例における１行更新処理の流れ図
【図２２】第４の実施例における１行参照処理の流れ図
【図２３】本発明を実施するデータベースシステムの構成を示す図
【符号の説明】
1…予約更新前処理、2…予約更新後処理、5…予約更新時刻、6…DBテーブル(口座テーブル)、7…DBテーブル(支店テーブル)、8…予約更新テーブル、9…予約管理テーブル、51…予約参照前処理、52…予約参照後処理、53…予約参照バックアップ処理、56…予約参照時刻、502…予約参照テーブル、503…バックアップテーブル。
Claims (8)
- 複数のレコードを含むデータベーステーブルを格納する記憶装置と、前記データベーステーブルの任意のレコードにアクセスするための処理装置とを有するデータベース処理装置において、複数のレコードの更新をあらかじめ予約することにより、該予約された更新を見掛け上指定された予約更新時刻に実行する予約アクセス処理方法であって、
前記予約された更新処理は、当該レコードの更新を予約登録するための予約更新前処理ステップと、予約更新時刻以降の当該レコードへの最初のアクセス時に行なわれる予約更新後処理ステップとで実行され、
前記予約更新前処理ステップにおいては、前記データベーステーブルの更新すべき各レコードに１対１に対応した予約更新時刻と予約情報とで構成される予約更新情報として該レコードの予約更新時刻及び更新内容を格納することにより予約更新登録を行ない、
前記予約更新後処理ステップにおいては、当該レコードに対応する予約更新登録の更新内容に従って更新を実行し、該予約更新登録を削除し、
前記更新処理とは別に前記データベースへのレコードのアクセスが要求されたときは、該レコードに対する予約更新登録の有無及び現時刻と予約更新時刻との比較を行ない、該レコードに対応する予約更新登録があり、かつ、現時刻が予約更新時刻以降であれば前記予約更新後処理を実行してから当該レコードに対するアクセス処理を実行し、予約更新登録がない場合、又は、現時刻が予約更新時刻以前であれば予約された更新は行なわずに該レコードに対するアクセス処理を実行することを特徴とするデータベースの予約アクセス方法。 - 前記予約更新時刻以降に、前記予約更新後処理ステップを前記更新予約されたレコードのすべてに関して実行するクリーンナップ処理を行なう請求項１に記載のデータベースの予約アクセス方法。
- 前記予約更新前処理ステップで予約更新登録を実行している途中で、現時刻が該予約更新登録の予約更新時刻を過ぎてしまった場合には、該予約更新処理の状態を予約更新前処理取消状態に設定し、それまでに予約更新登録した全てのレコードの予約更新情報を削除すると共に、前記予約更新後処理ステップを実行する際には、当該予約更新処理の状態を確認して、該状態が予約更新前処理取消であった場合には該予約更新登録を破棄する請求項１または２のいずれか１つに記載のデータベースの予約アクセス方法。
- 複数のレコードを含むデータベーステーブルを格納する記憶装置と、前記データベーステーブルの任意のレコードにアクセスするための処理装置とを有するデータベース処理装置において、複数のレコードの参照をあらかじめ予約することにより、該複数のレコードの共用排他アクセス権を同時に確保することなく、見掛け上該予約参照時刻に該複数のレコードの参照を実行する予約アクセス処理方法であって、
前記予約された参照処理は、当該レコードの参照を予約登録するための予約参照前処理ステップと、予約参照時刻以降に起動され実行される予約参照後処理ステップと、予約参照時刻以降かつ予約参照後処理以前の間に発生する参照が予約された当該レコードへの更新処理時に実行される予約参照バックアップ処理ステップとで実行され、
前記予約参照前処理ステップにおいては、前記データベーステーブルの参照すべき各レコードに１対１に対応した予約参照時刻と予約情報とで構成される予約参照情報として該レコードの予約参照時刻及び参照内容を格納することにより予約参照登録を行ない、
前記予約参照バックアップ処理ステップにおいては、参照が予約されたレコードへの更新処理を行なう前に該レコードのバックアップデータを作成し、
前記予約参照後処理ステップにおいては、当該レコードのバックアップデータが作成されている場合にはバックアップデータを参照してから該バックアップデータ及び該予約参照登録を削除し、バックアップデータが存在しない場合には当該レコードの内容を直接参照してから該予約参照登録を削除し、
前記参照処理とは別に前記データベースへのレコードの更新が要求されたときは、該レコードに対する予約参照登録の有無及び現時刻と予約参照時刻との比較を行ない、該レコードに対応する予約参照登録があり、かつ、現時刻が予約参照時刻以降であれば前記予約参照バックアップ処理を実行して当該レコードのバックアップデータを作成してから当該レコードに対する更新アクセス処理を実行し、予約参照登録がない場合、又は、現時刻が予約参照時刻以前であれば予約参照バックアップ処理は行なわずに該レコードに対する更新アクセス処理を実行することを特徴とするデータベースの予約アクセス方法。 - 前記予約参照後処理ステップは、前記予約参照時刻以降の適当なタイミングで、タイマ割込み又は最初のデータベースアクセス発生を契機として起動される請求項４に記載のデータベースの予約アクセス方法。
- 前記予約参照前処理ステップで予約参照登録を実行している途中で、現時刻が該予約参照登録の予約参照時刻を過ぎてしまった場合には、該予約参照処理の状態を予約参照前処理取消状態に設定し、それまでに予約参照登録した全てのレコードの予約参照情報を削除すると共に、前記予約参照バックアップ処理ステップ及び前記予約参照後処理ステップを実行する際には、当該予約参照処理の状態を確認して、該状態が予約参照前処理取消であった場合には該予約参照登録を破棄する請求項４または５のいずれか１つに記載のデータベースの予約アクセス方法。
- 請求項１に記載の予約アクセス方法により複数のレコードの更新を見掛け上同時に実行するとともに、請求項４に記載の予約アクセス方法により複数のレコードへの参照を該複数のレコードの共用排他アクセス権を同時に確保することなく実行することを特徴とするデータベースの予約アクセス方法。
- 前記予約更新登録又は前記予約参照登録において格納する予約更新情報又は予約参照情報に、次の予約更新情報又は予約参照情報へのポインタを設け、一つのレコードに対して複数の予約アクセスを登録可能にした請求項１から３のいずれか１つに記載のデータベースの予約アクセス方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP23472795A JP3741388B2 (ja) | 1994-09-08 | 1995-08-21 | データベースの予約アクセス処理方法 |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP24066594 | 1994-09-08 | ||
| JP6-240665 | 1994-09-08 | ||
| JP23472795A JP3741388B2 (ja) | 1994-09-08 | 1995-08-21 | データベースの予約アクセス処理方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH08129501A JPH08129501A (ja) | 1996-05-21 |
| JP3741388B2 true JP3741388B2 (ja) | 2006-02-01 |
Family
ID=26531727
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP23472795A Expired - Fee Related JP3741388B2 (ja) | 1994-09-08 | 1995-08-21 | データベースの予約アクセス処理方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3741388B2 (ja) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| AU1945499A (en) * | 1997-12-22 | 1999-07-12 | Rightworks Corporation | System and method for collaborative data sharing |
| US7069228B1 (en) | 1998-04-30 | 2006-06-27 | Rose James W | Apparatus and method for an internet based computer reservation booking system |
| JP6390219B2 (ja) * | 2014-07-08 | 2018-09-19 | 富士ゼロックス株式会社 | ファイル管理装置及びプログラム |
-
1995
- 1995-08-21 JP JP23472795A patent/JP3741388B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH08129501A (ja) | 1996-05-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US5701457A (en) | Method of designated time interval reservation access process of online updating and backing up of large database versions without reserving exclusive control | |
| US5778388A (en) | Method of processing a synchronization point in a database management system to assure a database version using update logs from accumulated transactions | |
| US8868577B2 (en) | Generic database manipulator | |
| JP4237354B2 (ja) | トランザクション処理方法及びトランザクション処理システム | |
| JP2667039B2 (ja) | データ管理システムおよびデータ管理方法 | |
| EP0501160A2 (en) | Intelligent page store for concurrent and consistent access to a database by a transaction processor and a query processor | |
| JPH0212460A (ja) | 索引木への並列アクセスのためのデータ・アクセス方法およびデータ処理システム | |
| US20040215998A1 (en) | Recovery from failures within data processing systems | |
| US20030135478A1 (en) | Method and system for online reorganization of databases | |
| JPH04310148A (ja) | データの単位を高速度でアクセスする方法 | |
| JPH06318165A (ja) | 故障後の再起動中でのトランザクション適応システムにおいてデータを利用可能にする方法 | |
| JPS633341B2 (ja) | ||
| JPH056297A (ja) | トランザクシヨン処理方法およびシステム | |
| JPH0728679A (ja) | チェックイン・チェックアウトモデルにおける施錠方式 | |
| JP3052908B2 (ja) | トランザクションプログラム並列実行方法およびトランザクションプログラム並列実行方式 | |
| Haderle et al. | IBM Database 2 overview | |
| JP3621433B2 (ja) | データベース排他制御方法 | |
| JP3741388B2 (ja) | データベースの予約アクセス処理方法 | |
| JP3970524B2 (ja) | 複数オペレーション間の排他制御方法 | |
| Kiviniemi et al. | Transaction processing in the RODAIN real-time database system | |
| JP2610926B2 (ja) | トランザクション制御方式 | |
| JPH10232809A (ja) | トランザクション処理システム | |
| JPH03123946A (ja) | データベースの排他制御方法 | |
| JPH04282733A (ja) | データベース管理方法 | |
| JP2569063B2 (ja) | 複合サブシステム形オンラインシステムの障害回復方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 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: 20051107 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20051107 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |