JPH07104811B2 - 高速データベース制御方式 - Google Patents
高速データベース制御方式Info
- Publication number
- JPH07104811B2 JPH07104811B2 JP1307675A JP30767589A JPH07104811B2 JP H07104811 B2 JPH07104811 B2 JP H07104811B2 JP 1307675 A JP1307675 A JP 1307675A JP 30767589 A JP30767589 A JP 30767589A JP H07104811 B2 JPH07104811 B2 JP H07104811B2
- Authority
- JP
- Japan
- Prior art keywords
- database
- processing
- reflection
- store number
- update
- 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 - Lifetime
Links
Description
【発明の詳細な説明】 〔産業上の利用分野〕 本発明は、データベースを有する計算機応用システムに
おける高速データベース制御方式に関するものである。
おける高速データベース制御方式に関するものである。
従来の技術では、第10図に示す通り、データベース更新
情報作成側５で発生する取引レコード（第10図に示すＡ
−1,A−2,B−１等、但しＡ−１はデータベースＡに対す
る１番目の更新情報、Ａ−２は同じく２番目の更新情報
を示す）単位にこの更新情報をデータベースへ反映する
側６に送っていた。データベース情報作成側５から、同
反映側６への取引レコード送信は高速化のための多重処
理が一般的であり、第10図では送信多重度と反映処理の
多重度が同じケースを示した。更新情報をデータベース
へ反映する側では送られた取引レコード毎にデータベー
スへ反映する処理7,8,9を起動していた。取引レコード
の発生は、データベースA,B,Cに対してランダムであ
り、このためデータベース更新情報反映側ではデータベ
ース更新時に、取引レコード間の排他競合が発生する可
能性があった。データベースA,B,Cはそれぞれ排他制御
の区分が異なり、第10図では、取引レコードＡ−1,A−
２の排他の単位が等しいため、競合が発生している。
情報作成側５で発生する取引レコード（第10図に示すＡ
−1,A−2,B−１等、但しＡ−１はデータベースＡに対す
る１番目の更新情報、Ａ−２は同じく２番目の更新情報
を示す）単位にこの更新情報をデータベースへ反映する
側６に送っていた。データベース情報作成側５から、同
反映側６への取引レコード送信は高速化のための多重処
理が一般的であり、第10図では送信多重度と反映処理の
多重度が同じケースを示した。更新情報をデータベース
へ反映する側では送られた取引レコード毎にデータベー
スへ反映する処理7,8,9を起動していた。取引レコード
の発生は、データベースA,B,Cに対してランダムであ
り、このためデータベース更新情報反映側ではデータベ
ース更新時に、取引レコード間の排他競合が発生する可
能性があった。データベースA,B,Cはそれぞれ排他制御
の区分が異なり、第10図では、取引レコードＡ−1,A−
２の排他の単位が等しいため、競合が発生している。
なお関連する技術として特開昭63−191249号公報等が挙
げられる。
げられる。
上記従来技術にはデータベースの更新処理を高速にでき
ない次の課題があった。
ない次の課題があった。
（１）データベース更新要求の単位である取引レコード
と更新処理の起動単位が同じであり、取引レコードごと
にデータベース更新のための起動と終了のプログラム処
理ステップがを必要とするためシステム全体の性能が低
下する。
と更新処理の起動単位が同じであり、取引レコードごと
にデータベース更新のための起動と終了のプログラム処
理ステップがを必要とするためシステム全体の性能が低
下する。
（２）本来データベース更新要求は、データベース設計
により決まる排他の範囲や単位と無関係に発生するた
め、ランダムな更新要求をそのまま起動する場合、デー
タベース反映処理相互に排他待ちが発生する。更新要求
の発生量増加により、排他待ちが膨大となりシステム全
体の性能が低下する。
により決まる排他の範囲や単位と無関係に発生するた
め、ランダムな更新要求をそのまま起動する場合、デー
タベース反映処理相互に排他待ちが発生する。更新要求
の発生量増加により、排他待ちが膨大となりシステム全
体の性能が低下する。
（３）課題の（１）で述べたデータベース更新処理の起
動と終了のためのプログラム処理ステップの対策として
は、データベース更新情報作成側で発生する取引レコー
ドのうち、ｎレコードを１つにまとめてブロッキング
し、ブロッキングされたブロック単位をデータベース更
新情報反映側で起動と終了することにより、起動と終了
のプログラム処理ステップ数を1/nに縮減できるが、こ
の場合次の問題点がある。
動と終了のためのプログラム処理ステップの対策として
は、データベース更新情報作成側で発生する取引レコー
ドのうち、ｎレコードを１つにまとめてブロッキング
し、ブロッキングされたブロック単位をデータベース更
新情報反映側で起動と終了することにより、起動と終了
のプログラム処理ステップ数を1/nに縮減できるが、こ
の場合次の問題点がある。
（ａ）デッドロックの発生 第12図に示すようにデータベースA,B（ＡとＢは排他制
御の区分を示す）に対する更新レコードをそれぞれＡ−
1,A−2,B−1,B−２とする。データベース反映処理10で
は、Ａ−１をデータベースＡに反映するためにＡに排他
要求をする。データベース反映処理11では、Ｂ−１をデ
ータベースＢに反映するためにＢに排他要求をする。こ
のあと、データベース反映処理10はＢ−２をデータベー
スＢに反映するためにＢに排他要求をするが、Ｂ−１に
よる反映処理のためデータベース反映処理11がすでにＢ
に排他要求をしているため、データベース反映処理10は
データベース反映処理11の終了待ちとなる。一方データ
ベース反映処理11は、Ａ−２による反映処理のためＡの
排他要求を行うが、同様にデータベース反映処理10の終
了待ちとなる。このようにデータベース反映処理10およ
びデータベース反映処理11がお互いに相手の終了を待ち
合うデッドロックが発生しやすくなる。
御の区分を示す）に対する更新レコードをそれぞれＡ−
1,A−2,B−1,B−２とする。データベース反映処理10で
は、Ａ−１をデータベースＡに反映するためにＡに排他
要求をする。データベース反映処理11では、Ｂ−１をデ
ータベースＢに反映するためにＢに排他要求をする。こ
のあと、データベース反映処理10はＢ−２をデータベー
スＢに反映するためにＢに排他要求をするが、Ｂ−１に
よる反映処理のためデータベース反映処理11がすでにＢ
に排他要求をしているため、データベース反映処理10は
データベース反映処理11の終了待ちとなる。一方データ
ベース反映処理11は、Ａ−２による反映処理のためＡの
排他要求を行うが、同様にデータベース反映処理10の終
了待ちとなる。このようにデータベース反映処理10およ
びデータベース反映処理11がお互いに相手の終了を待ち
合うデッドロックが発生しやすくなる。
（ｂ）排他待ちの増大（第４図参照） ランダムに発生するデータベース更新情報である取引レ
コードを単純に（例えば発生順に）ブロッキングし、デ
ータベースに反映する場合、起動されたブロック内にあ
る一連の取引レコードのデータベース排他の単位が入り
組んでいるため排他待ちが発生し、多重度が上がらなく
なり、データベース反映処理のシステム性能が低下す
る。例えば第13図に示すように、データベース反映処理
12では取引レコードＡ−1,B−1,B−３を同時に更新する
ため、データベースA,Bに排他要求をする。一方データ
ベース反映処理13では取引レコードＡ−2,A−3,C−２を
更新するためデータベースＡに排他要求をするが、既に
データベース反映処理12でＡに排他要求をしているた
め、データベース反映処理13はデータベース反映処理12
の終了待ちとなる。またデータベース反映処理14では取
引レコードＣ−1,B−2,C−３を更新するため、データベ
ースＣに排他要求をしたあとデータベースＢに排他要求
をするが、データベース反映処理12が既にＢを排他要求
をしているため、データベース反映処理12の終了待ちと
なり、結果としてデータベース反映処理12しか処理が進
まない。
コードを単純に（例えば発生順に）ブロッキングし、デ
ータベースに反映する場合、起動されたブロック内にあ
る一連の取引レコードのデータベース排他の単位が入り
組んでいるため排他待ちが発生し、多重度が上がらなく
なり、データベース反映処理のシステム性能が低下す
る。例えば第13図に示すように、データベース反映処理
12では取引レコードＡ−1,B−1,B−３を同時に更新する
ため、データベースA,Bに排他要求をする。一方データ
ベース反映処理13では取引レコードＡ−2,A−3,C−２を
更新するためデータベースＡに排他要求をするが、既に
データベース反映処理12でＡに排他要求をしているた
め、データベース反映処理13はデータベース反映処理12
の終了待ちとなる。またデータベース反映処理14では取
引レコードＣ−1,B−2,C−３を更新するため、データベ
ースＣに排他要求をしたあとデータベースＢに排他要求
をするが、データベース反映処理12が既にＢを排他要求
をしているため、データベース反映処理12の終了待ちと
なり、結果としてデータベース反映処理12しか処理が進
まない。
以上で述べた通り単純なブロッキングでは、システム性
能に悪影響を及ぼす。
能に悪影響を及ぼす。
本発明の目的は、この課題を解決することにある。
上記目的を達成するためには、次のようにすればよい。
（１）データベース更新情報の反映処理の起動単位を従
来の取引レコード単位から、複数のレコードをブロッキ
ングしたブロック起動方式としデータベース反映処理の
起動と終了に要するプログラム処理ステップ1/nに縮減
する。
来の取引レコード単位から、複数のレコードをブロッキ
ングしたブロック起動方式としデータベース反映処理の
起動と終了に要するプログラム処理ステップ1/nに縮減
する。
（２）ブロック相互の排他待ちおよびデッドロックを回
避するため、あらかじめ同一排他区分をとる取引レコー
ド群（Ａ−1,A−2,A−３またはＢ−1,B−2,B−３等）を
データベース更新処理を行う前にまとめてブロッキング
する。
避するため、あらかじめ同一排他区分をとる取引レコー
ド群（Ａ−1,A−2,A−３またはＢ−1,B−2,B−３等）を
データベース更新処理を行う前にまとめてブロッキング
する。
（３）同一排他区分を取引レコードからなるブロック
は、データベース更新処理で直列に処理することによ
り、排他の競合を回避し、合わせてデータ反映順序の逆
転も防止する。
は、データベース更新処理で直列に処理することによ
り、排他の競合を回避し、合わせてデータ反映順序の逆
転も防止する。
たとえば第11図に示すものがその例であり、同一排他を
とる取引レコード群がデータベース更新情報作成側５で
ブロッキングされ、データベース更新情報反映側６へ送
られる。データベース更新情報反映側６では各々のデー
タベース反映処理15,16,17によって直列に処理されてい
る。
とる取引レコード群がデータベース更新情報作成側５で
ブロッキングされ、データベース更新情報反映側６へ送
られる。データベース更新情報反映側６では各々のデー
タベース反映処理15,16,17によって直列に処理されてい
る。
本発明によれば、第１の手段はデータベース反映処理の
起動と終了にかかわるプログラム処理ステップを1/nに
縮減する働きをし、第2,第３の手段は、排他待ちや、デ
ッドロックをなくし、合わせてデータベース更新順序も
守る働きをする。
起動と終了にかかわるプログラム処理ステップを1/nに
縮減する働きをし、第2,第３の手段は、排他待ちや、デ
ッドロックをなくし、合わせてデータベース更新順序も
守る働きをする。
以下、本発明の一実施例について図面を用いて説明す
る。実施例として銀行オンラインシステムの場合につい
て説明する。
る。実施例として銀行オンラインシステムの場合につい
て説明する。
本発明は、データベース更新要求発生側と、反映側とが
同一センタ（または同一計算機）内にある場合（以下ロ
ーカルシステムと呼ぶ）でも、相互に別センタ内にあり
回線等で接続されている場合（以下リモートシステムと
呼ぶ）でも適用可能である。
同一センタ（または同一計算機）内にある場合（以下ロ
ーカルシステムと呼ぶ）でも、相互に別センタ内にあり
回線等で接続されている場合（以下リモートシステムと
呼ぶ）でも適用可能である。
（ａ）ローカルシステムでの実施例 銀行オンライン夜間センタ入力処理では、企業等契約者
から持ち込まれた給与振込み，公共料金引落し等のデー
タベース更新要求データ18を、ファイル入力によるオン
ライン処理でデータベースに反映させる。この処理を本
発明により高速化する。銀行の中心となる業務は勘定系
処理業務であるが、これは銀行のもつ各支店が契約者と
の窓口となっているため、データベースも支店（以下店
と略す）単位に作成されている。データベースの排他の
単位は契約者又は同一店内の複数の契約者群であること
もあるが、合計処理は点単位に把握する必要があるため
店単位に排他を必要とするデータベースも少なくない。
したがって、銀行オンラインのデータベースの更新処理
では、本発明での同一排他区分とするときの分類上のキ
ーは店とすることが最も適切である。
から持ち込まれた給与振込み，公共料金引落し等のデー
タベース更新要求データ18を、ファイル入力によるオン
ライン処理でデータベースに反映させる。この処理を本
発明により高速化する。銀行の中心となる業務は勘定系
処理業務であるが、これは銀行のもつ各支店が契約者と
の窓口となっているため、データベースも支店（以下店
と略す）単位に作成されている。データベースの排他の
単位は契約者又は同一店内の複数の契約者群であること
もあるが、合計処理は点単位に把握する必要があるため
店単位に排他を必要とするデータベースも少なくない。
したがって、銀行オンラインのデータベースの更新処理
では、本発明での同一排他区分とするときの分類上のキ
ーは店とすることが最も適切である。
第１図に示す夜間センタ入力処理のために持込まれた銀
行等のデータ18は、そのままではオンライン処理用の入
力データファイル形式になっていないため、計算機20に
よって一度フォーマット変換処理を行う必要がある。こ
の時、フォーマット変換の一環として、更新する口座の
ある店毎に店番振り分けを実施する（）。100,200,30
0はそれぞれ店番100の店,200番の店,300番の店対応であ
ることを示している。店番100に対する口座への振込デ
ータは、店番100入力用データファイル19に蓄積される
（）。データベース更新側６では計算機21が店番100
の入力データを読み込む（）と、店番100の更新情報
を複数まとめて反映処理用にブロッキング（）し、デ
ータベース反映処理22を起動する（）。反映処理を終
了させるとき終了処理を行う（）。
行等のデータ18は、そのままではオンライン処理用の入
力データファイル形式になっていないため、計算機20に
よって一度フォーマット変換処理を行う必要がある。こ
の時、フォーマット変換の一環として、更新する口座の
ある店毎に店番振り分けを実施する（）。100,200,30
0はそれぞれ店番100の店,200番の店,300番の店対応であ
ることを示している。店番100に対する口座への振込デ
ータは、店番100入力用データファイル19に蓄積される
（）。データベース更新側６では計算機21が店番100
の入力データを読み込む（）と、店番100の更新情報
を複数まとめて反映処理用にブロッキング（）し、デ
ータベース反映処理22を起動する（）。反映処理を終
了させるとき終了処理を行う（）。
店番100のブロックと店番200のブロックの処理は同時に
起動するが、同じ100のブロックは同時に１ブロックし
か起動しないシリアルスケジュール方式とする。データ
ベース反映処理側６では同一店番の取引レコードからな
るブロックがシリアルに起動されるように、店番対応の
制御テーブルが必要であり、本テーブルに当該店番のデ
ータベース反映処理が実行中か否かのステータス管理フ
ラグをもたせる。第１図はフラグ１をもつ反映処理22,2
3が実行中で、フラグ０をもつ反映処理24が未実行であ
ることを示している。
起動するが、同じ100のブロックは同時に１ブロックし
か起動しないシリアルスケジュール方式とする。データ
ベース反映処理側６では同一店番の取引レコードからな
るブロックがシリアルに起動されるように、店番対応の
制御テーブルが必要であり、本テーブルに当該店番のデ
ータベース反映処理が実行中か否かのステータス管理フ
ラグをもたせる。第１図はフラグ１をもつ反映処理22,2
3が実行中で、フラグ０をもつ反映処理24が未実行であ
ることを示している。
第３図は、第１図中のの処理フローを示すもので、入
力データに入力店番があるとき、入力店番によってデー
タを振り分け、入力店番がないとき、口座店番によって
データを振り分けている。
力データに入力店番があるとき、入力店番によってデー
タを振り分け、入力店番がないとき、口座店番によって
データを振り分けている。
第４図は、第１図中のの処理フローを示すもので、す
でに作成されたブロック内に取引レコードを収容する空
きがあれば（ステップ41YES）、ブロッキング処理を行
い（ステップ42）、ブロッキングが満杯になったとき
（ステップ43YES）、新たなデータブロックを作成して
準備する（ステップ44）。ブロック内に空きがなければ
（ステップ41NO）、新たなデータブロックを作成して
（ステップ45）、ブロッキング処理を行う（ステップ4
6）。
でに作成されたブロック内に取引レコードを収容する空
きがあれば（ステップ41YES）、ブロッキング処理を行
い（ステップ42）、ブロッキングが満杯になったとき
（ステップ43YES）、新たなデータブロックを作成して
準備する（ステップ44）。ブロック内に空きがなければ
（ステップ41NO）、新たなデータブロックを作成して
（ステップ45）、ブロッキング処理を行う（ステップ4
6）。
（第５図は、第１図中のの処理フローを示すもので、
起動要求を受付け（ステップ51）、当該データの店番に
対応するフラグが“0"であれば（ステップ52YES）、該
フラグを“1"にセットして（ステップ53）、反映処理を
行う（ステップ54）。該フラグがすでに“1"であれば
（ステップ52NO）、当該データを待ち状態にする（ステ
ップ55）。
起動要求を受付け（ステップ51）、当該データの店番に
対応するフラグが“0"であれば（ステップ52YES）、該
フラグを“1"にセットして（ステップ53）、反映処理を
行う（ステップ54）。該フラグがすでに“1"であれば
（ステップ52NO）、当該データを待ち状態にする（ステ
ップ55）。
第６図は、第１図中のの処理フローを示すもので、終
了処理を受付け（ステップ61）、当該店番に対応して待
ちデータがあるかどうかを調べ、待ちデータがなければ
（ステップ62NO）、フラグを“0"にリセットする（ステ
ップ63）。待ちデータがあれば（ステップ62YES）、そ
の待ちデータに対して反映処理を起動する（ステップ6
4）。
了処理を受付け（ステップ61）、当該店番に対応して待
ちデータがあるかどうかを調べ、待ちデータがなければ
（ステップ62NO）、フラグを“0"にリセットする（ステ
ップ63）。待ちデータがあれば（ステップ62YES）、そ
の待ちデータに対して反映処理を起動する（ステップ6
4）。
第７図は制御テーブルの構成を示すもので、店番71に対
応してそれぞれフラグ72が設けられている。
応してそれぞれフラグ72が設けられている。
第８図は、取引レコード形式の例を示すもので、（ａ）
は取引レコードが契約者持込データの場合の例、（ｂ）
は営業店端末取引入力データである場合の例である。第
１図に示すローカルシステムでは（ａ）のデータが入力
される。
は取引レコードが契約者持込データの場合の例、（ｂ）
は営業店端末取引入力データである場合の例である。第
１図に示すローカルシステムでは（ａ）のデータが入力
される。
（ｂ）リモートシステム実施例 銀行オンラインシステム障害が社会に与える影響の増大
に伴い、災害時に備えたバックアップシステムが必要と
なってきた。第２図に示すようにバックアップシステム
側26では、正システム側25と同じデータベースをもち、
正システム側データベース（正元帳）27の更新をリアル
タイムでバックアップ側データベース（副元帳）28に反
映させる必要がある。本反映処理にこの発明を適用す
る。
に伴い、災害時に備えたバックアップシステムが必要と
なってきた。第２図に示すようにバックアップシステム
側26では、正システム側25と同じデータベースをもち、
正システム側データベース（正元帳）27の更新をリアル
タイムでバックアップ側データベース（副元帳）28に反
映させる必要がある。本反映処理にこの発明を適用す
る。
第２図に示す正システム側25の計算機30では勘定処理系
のオンラインが動作している。店番が100の営業店から
入った普通預金出金処理が店番100に関する普通預金デ
ータベース27−１を更新した場合（）、これをバック
アップシステム側26に反映させる必要がある。
のオンラインが動作している。店番が100の営業店から
入った普通預金出金処理が店番100に関する普通預金デ
ータベース27−１を更新した場合（）、これをバック
アップシステム側26に反映させる必要がある。
正元帳データベース更新情報を抽出し（）、店番別振
り分けにより他の店番100のデータと共に送信キュー書
込用にブロッキングし（）、送信キュー32に書き込む
（）。送信キュー32内データは回線29を介してバック
アップシステム内受信キュー33に送られる（）。この
時、送信キュー32,受信キュー33,送信経路それぞれ店番
単位にもつことで、シリアライズ処理を実現する。計算
機31では、受信キュー33から取り出したデータベース更
新情報を反映処理用にブロッキングし（）、データベ
ース反映処理を起動する（）。反映処理を終了させる
とき終了処理を行う（）。データベース反映処理34,3
5,36では、同一店番ブロックが、シリアルに起動される
ように店番単位に制御テーブルをもつ（その構造はロー
カルシステムの場合と同様）。
り分けにより他の店番100のデータと共に送信キュー書
込用にブロッキングし（）、送信キュー32に書き込む
（）。送信キュー32内データは回線29を介してバック
アップシステム内受信キュー33に送られる（）。この
時、送信キュー32,受信キュー33,送信経路それぞれ店番
単位にもつことで、シリアライズ処理を実現する。計算
機31では、受信キュー33から取り出したデータベース更
新情報を反映処理用にブロッキングし（）、データベ
ース反映処理を起動する（）。反映処理を終了させる
とき終了処理を行う（）。データベース反映処理34,3
5,36では、同一店番ブロックが、シリアルに起動される
ように店番単位に制御テーブルをもつ（その構造はロー
カルシステムの場合と同様）。
なおの処理のフローは第３図、の処理フローは第４
図、の処理フローは第５図およびの処理フローは第
６図に示されるものとなる。また第２図に示すリモート
システムでは第８図（ｂ）の営業店端末取引データが入
力される。
図、の処理フローは第５図およびの処理フローは第
６図に示されるものとなる。また第２図に示すリモート
システムでは第８図（ｂ）の営業店端末取引データが入
力される。
なお第１図中のおよび第２図中のに示される取引レ
コードのブロッキング処理をそれぞれデータベース更新
情報作成側５および正システム側25で行ってもよいこと
はもちろんである。
コードのブロッキング処理をそれぞれデータベース更新
情報作成側５および正システム側25で行ってもよいこと
はもちろんである。
第９図は取引レコードをブロッキングしない従来方式
（ａ）とブロッキングする本発明（ｂ）の場合について
処理時間を比較するものである。本発明の場合には、ブ
ロッキングによって起動処理および終了処理が削減さ
れ、処理時間が短縮される。
（ａ）とブロッキングする本発明（ｂ）の場合について
処理時間を比較するものである。本発明の場合には、ブ
ロッキングによって起動処理および終了処理が削減さ
れ、処理時間が短縮される。
本発明によれば同一排他区分をもつ更新要求をまとめて
ブロック化し、同一排他区分をもつブロック相互はシリ
アルに起動するため排他待ちやデッドロックが生じな
い。これにより、高速なデータベース反映処理が可能と
なる。
ブロック化し、同一排他区分をもつブロック相互はシリ
アルに起動するため排他待ちやデッドロックが生じな
い。これにより、高速なデータベース反映処理が可能と
なる。
第１図は本発明のローカルシステムでの実施例を示す
図、第２図は本発明のリモートシステムでの実施例を示
す図、第３図は実施例の店番振分処理フローチャート、
第４図は実施例のデータベース更新情報反映処理用ブロ
ッキングの処理フローチャート、第５図は実施例のデー
タベース更新情報反映処理起動処理フローチャート、第
６図は、同終了処理フローチャート、第７図は制御テー
ブルの構成図、第８図は実施例の入力データ形式を示す
図、第９図は従来方式と本方式との処理時間を比較する
図、第10図は従来のデータベース反映処理を示す図、第
11図は本発明のデータベース反映処理を示す図、第12図
は単純なブロッキングによるデッドロック発生が起る例
を示す図、第13図は単純なブロッキングによる排他待ち
が発生する例を示す図である。 ５……データベース更新情報作成側、 ６……データベース更新情報反映側、 15,16,17……データベース反映処理、 A,B,C……データベース、 Ａ−1,A−2,……データベースＡに対する取引レコー
ド。
図、第２図は本発明のリモートシステムでの実施例を示
す図、第３図は実施例の店番振分処理フローチャート、
第４図は実施例のデータベース更新情報反映処理用ブロ
ッキングの処理フローチャート、第５図は実施例のデー
タベース更新情報反映処理起動処理フローチャート、第
６図は、同終了処理フローチャート、第７図は制御テー
ブルの構成図、第８図は実施例の入力データ形式を示す
図、第９図は従来方式と本方式との処理時間を比較する
図、第10図は従来のデータベース反映処理を示す図、第
11図は本発明のデータベース反映処理を示す図、第12図
は単純なブロッキングによるデッドロック発生が起る例
を示す図、第13図は単純なブロッキングによる排他待ち
が発生する例を示す図である。 ５……データベース更新情報作成側、 ６……データベース更新情報反映側、 15,16,17……データベース反映処理、 A,B,C……データベース、 Ａ−1,A−2,……データベースＡに対する取引レコー
ド。
フロントページの続き (56)参考文献 特開 昭59−8072（ＪＰ，Ａ) 特開 昭63−66640（ＪＰ，Ａ) ＢＩＴ別冊 ＡＣＭ Ｃｏｍｐｕｔｉｎ ｇ Ｓｕｒｖｅｙｓ’84 コンピュータ・ サイエンス、（1986）ＰＰ．145−188「ネ ットワーク型分散システムにおけるファイ ル・サーバ」、特に第156頁及び第161− 162頁「３．２．２．３トランザクション 境界」におけるＣＭＣＦＳに関する記載
Claims (1)
- 【請求項１】データベース更新レコードによってデータ
ベースの更新を制御するデータベース制御方式におい
て、前記データベースに対して同一の排他区分をもつ前
記レコードを所定の数だけまとめてブロッキングする手
段と、前記データベースの更新に当たって同一の排他区
分をもつブロックは１ブロックずつ直列に更新処理を起
動するよう制御する手段とを有することを特徴とする高
速データベース制御方式。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP1307675A JPH07104811B2 (ja) | 1989-11-29 | 1989-11-29 | 高速データベース制御方式 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP1307675A JPH07104811B2 (ja) | 1989-11-29 | 1989-11-29 | 高速データベース制御方式 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH03168847A JPH03168847A (ja) | 1991-07-22 |
| JPH07104811B2 true JPH07104811B2 (ja) | 1995-11-13 |
Family
ID=17971889
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP1307675A Expired - Lifetime JPH07104811B2 (ja) | 1989-11-29 | 1989-11-29 | 高速データベース制御方式 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JPH07104811B2 (ja) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3755415B2 (ja) | 2001-04-04 | 2006-03-15 | 株式会社デンソー | 処理実行装置、当該処理実行装置に搭載される処理プログラム、及び記録媒体 |
| EP2096564B1 (en) | 2008-02-29 | 2018-08-08 | Euroclear SA/NV | Improvements relating to handling and processing of massive numbers of processing instructions in real time |
| JP5430301B2 (ja) * | 2009-09-07 | 2014-02-26 | 三菱電機株式会社 | 通信装置管理システムおよびデータベースアクセス処理方法 |
-
1989
- 1989-11-29 JP JP1307675A patent/JPH07104811B2/ja not_active Expired - Lifetime
Non-Patent Citations (1)
| Title |
|---|
| ＢＩＴ別冊ＡＣＭＣｏｍｐｕｔｉｎｇＳｕｒｖｅｙｓ’８４コンピュータ・サイエンス、（１９８６）ＰＰ．１４５−１８８「ネットワーク型分散システムにおけるファイル・サーバ」、特に第１５６頁及び第１６１−１６２頁「３．２．２．３トランザクション境界」におけるＣＭＣＦＳに関する記載 |
Also Published As
| Publication number | Publication date |
|---|---|
| JPH03168847A (ja) | 1991-07-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6029177A (en) | Method and system for maintaining the integrity of a database providing persistent storage for objects | |
| CN108804112B (zh) | 一种区块链落账处理方法及系统 | |
| US6085200A (en) | System and method for arranging database restoration data for efficient data recovery in transaction processing systems | |
| US7805423B1 (en) | System and method for quiescing select data modification operations against an object of a database during one or more structural operations | |
| US8868577B2 (en) | Generic database manipulator | |
| US6070170A (en) | Non-blocking drain method and apparatus used to reorganize data in a database | |
| US6615219B1 (en) | Database management system and method for databases having large objects | |
| KR950007394B1 (ko) | 데이타 관리방법 및 데이타 관리시스템 | |
| Sidell et al. | Data replication in Mariposa | |
| US20040139127A1 (en) | Backup system and method of generating a checkpoint for a database | |
| CN111143389A (zh) | 事务执行方法、装置、计算机设备及存储介质 | |
| JPH06301581A (ja) | 過ち許容トランザクション指向データ処理 | |
| US20100169289A1 (en) | Two Phase Commit With Grid Elements | |
| CN102955792A (zh) | 一种实时全文搜索引擎事务处理的实现方法 | |
| US6895487B2 (en) | Methods for intra-partition parallelism for inserts | |
| Perrizo et al. | Hydro: A heterogeneous distributed database system | |
| JPWO2004036432A1 (ja) | データベースのアクセラレーター | |
| US20050071383A1 (en) | Efficient deletion of archived data | |
| JPH07104811B2 (ja) | 高速データベース制御方式 | |
| US8229946B1 (en) | Business rules application parallel processing system | |
| CN115048466A (zh) | 一种数据分析方法、系统、终端及存储介质 | |
| JPH0667944A (ja) | データベース管理方式 | |
| CN113986974A (zh) | 一种数据库事务管理方法及装置、恢复方法及装置 | |
| CN1324466A (zh) | 校验参照完整性中涉及的表空间的方法 | |
| JP4152107B2 (ja) | データベース更新情報の反映システムおよびそのためのプログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20071113 Year of fee payment: 12 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20081113 Year of fee payment: 13 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20081113 Year of fee payment: 13 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091113 Year of fee payment: 14 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101113 Year of fee payment: 15 |
|
| EXPY | Cancellation because of completion of term | ||
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101113 Year of fee payment: 15 |