JP2007264770A - データベースアクセス方法及び装置 - Google Patents

データベースアクセス方法及び装置 Download PDF

Info

Publication number
JP2007264770A
JP2007264770A JP2006085849A JP2006085849A JP2007264770A JP 2007264770 A JP2007264770 A JP 2007264770A JP 2006085849 A JP2006085849 A JP 2006085849A JP 2006085849 A JP2006085849 A JP 2006085849A JP 2007264770 A JP2007264770 A JP 2007264770A
Authority
JP
Japan
Prior art keywords
access
server
request
database
application
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.)
Withdrawn
Application number
JP2006085849A
Other languages
English (en)
Inventor
Hidesuke Komiya
秀介 小宮
Tatsuhiro Furuya
龍浩 降矢
Yoshinori Machida
芳則 町田
Toshio Obara
利雄 小原
Takashi Okuyama
貴 奥山
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2006085849A priority Critical patent/JP2007264770A/ja
Publication of JP2007264770A publication Critical patent/JP2007264770A/ja
Withdrawn legal-status Critical Current

Links

Images

Landscapes

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

Abstract

【課題】本発明はデータベースアクセス方法及び装置に関し、APLサーバが故障しても、同一要求の同一アプリケーションに対しては、正常なアプリケーション結果を返すことができるデータベースアクセス方法及び装置を提供することを目的としている。
【解決手段】アプリケーションサーバ3内に、アプリケーション部3aからの入力情報と共にアプリケーションサーバIDをパラメータに付与して後述するデータベースアクセス制御部4cに通知するデータベースアクセスメソッド部3bを設け、データベースサーバ4内に、前記データベースアクセスメソッド部3bからの入力情報を元に、同一要求毎にアクセス情報として管理し、アクセス内容毎に最初のアクセスをRDBMSアクセスし、そのアクセス情報をメモリ4aに保存した後、アクセス元のアプリケーションサーバ3に結果を戻すデータベースアクセス制御部4cを設けて構成される。
【選択図】図2

Description

本発明はデータベースアクセス方法及び装置に関する。
RDBMS(Relational Data Base Management System:RDBを構築運用するために用いられる管理ソフトウェア)にてデータ管理するデータベースサーバと、ユーザ要求を実行するアプリケーション(以下APLと略す)サーバの構成において、高信頼なAPLサーバの構成としてHA構成、分散構成等が一般的な構成である。
HA構成は、サーバ故障発生時に即座にスタンバイ(以下SBYと略す)系に切り替えてサービスを継続する。また、分散構成は、同一サービスが提供可能な正常なAPLサーバにサービスを分散することでサービスを継続する。上記の構成で、サービス無中断とするAPLサーバ構成が構築されている。
これらの構成は、ユーザからの1つの要求を1つのAPLサーバが処理する仕組みであり、サーバ故障が発生すると、実行途中の要求があれば、サーバ構成の分岐点に戻って正常な他のサーバに対してリトライする(分散構成)。
また、実行途中の経過データを正常なサーバに引き継ぐ方式として、実行した時点のRDBMS上のコミット(確定)済み更新データ、若しくはAPLサーバのメモリ上の更新データを他の正常なサーバに引き継ぐことで、途中から実行しユーザの要求を継続する(HA構成)。
図11は従来の分散構成の説明図である。図において、1はユーザ、2はフロントサーバ、3はAPLサーバ、4はデータベースサーバ(RDBMS)である。APLサーバ3はAとBの2種類存在する。
1)ユーザ1がコマンドを入力し、フロントサーバ2からAPLサーバAにユーザ要求を通知する。
2)APLサーバAはデータベースサーバ4にアクセスし、必要に応じてデータの書き込みと読み出しを行ない、アプリケーションを実行する(ロジックにより繰り返し行なう)。
3)APLサーバAが故障し、フロントサーバ2にエラーが戻る。
4)受付部又はユーザ自身にて、同一ユーザ要求をリトライする。そして、フロントサーバ2から正常なAPLサーバBにユーザ要求を通知する。
5)APLサーバBは、データベースサーバ4にアクセスし、データの書き込みと読み出しを行ない、アプリケーションを実行する。
6)APLサーバBにて要求が完了すると、ユーザ1に要求完了を応答する。
図12は従来のHA構成の説明図である。図11と同一のものは、同一の符号を付して示す。
1)ユーザ1がコマンドを入力し、フロントサーバ2からAPLサーバ3のACT系に対してユーザ要求を通知する。
2)ACT系APLサーバ3はデータベースサーバ4にアクセスし、必要に応じてデータの書き込みと読み出しを行ない、アプリケーションを実行する(ロジックにより繰り返し行なう)。
3)ACT系のAPLサーバ3が故障し、SBY系(新ACT系)のアプリケーションに切り替わる。
4)新ACT系のAPLサーバ3が立上がり時に、ACT系で実行途中であったユーザ要求を、データベース状態、ACT系メモリ情報を元に途中から実行する。
5)新ACT系APLサーバ3は、データベースサーバ4にアクセスし、データの書き込みと読み出しを行ない、アプリケーションを実行する。
6)新ACT系APLサーバ3で要求が完了すると、ユーザ1に要求完了を応答する。
従来のこの種のシステムとしては、照合系では処理系からの通知情報の有無、周期性及び内容から照合対象とすべき処理系の選択と照合を定期的に行って、処理系相互間の同期、処理系の状態管理を必要としない照合出力方法の技術が知られている(例えば特許文献1参照)。また、個々の実プロセス及び擬似プロセスが実行される度に、プロセス数の差を算出し、この差が所定のしきい値を越えたか否かを判定し、越えない場合は後続の実プロセスを実行し、越えた場合には遅延時間解消処理を実行する技術が知られている(例えば、特許文献2参照)。
また、ネットワークインフラやWebサイトに故障が発生してもサービスが停止しない技術が知られている(例えば非特許文献1参照)。また、クラスタによる高信頼システムの構築技術に関する技術である「クラスタによるシステムダウンの未然防止」に関する技術が知られている(例えば、非特許文献2参照)。
特開昭60−263252号公報(第4頁右上欄第1行〜第5頁左下欄第2行、第1図〜第3図) 特開平8−249199号公報(段落0010〜0011、図1) 負荷分散入門、"アベイラビリティ(可用性)"、掲載日:2004年7月20日、富士通株式会社[2005.12.17検索]、インターネット〈URL:http://primeserver.fujitsu.com/ipcom/catalog/data/1/1.html〉 クラスタによる高信頼システムの構築、"クラスタによるシステムダウンロードの未然防止"富士通株式会社[2005.12.17検索]、インターネット〈URL:http://www.fmworld.net/biz/primergy/technical/cluster〉
前述した従来の技術によれば、故障時に実行していた要求は、最小で正常なサーバに引き継ぐ手続き時間、最大で1要求処理時間×2倍の応答時間がかかることになる。また、上記の遅延は、1つのAPLサーバで実行していた時の、その要求に対するリカバリ(リトライ)時間である。このリカバリの時間をなくすため、ユーザの1要求に対して、単純に同時に複数のAPLサーバにて冗長実行させ1台のサーバが正常に要求を完了すればよいとした場合、現存するRDBMSを用いたデータ更新を伴うアプリケーションのロジック、及びデータベースアクセスでは、同一レコードの更新処理で、後からアクセス(更新)したAPLサーバは、先にアクセス(更新)したAPLサーバがコミット(確定)/ロールバック(元に戻す)するまでRDBMSの排他にて待ち合わせが発生する。この場合、先にアクセスしていたサーバが故障すると、排他により待たされた時間分遅れてアクセスしたAPLサーバが要求を実行することになり応答が遅延する。
また、データ更新が複数回のコミットによって実行するアプリケーションのロジックにおいては、処理矛盾が発生してしまう。以下、この点につき、説明する。いま、あるアプリケーションが、処理A→処理B→処理Cの順番通りに処理しないと処理矛盾が発生するプログラムであるものとする。2つのAPLサーバ#1、APL#2で同時に、このアプリケーションを要求ID:1で実行した場合、APLサーバ#2が処理A後のコミットまで完了した時点(処理番号は1)で、APLサーバ#1は先に進んでいて処理B後のコミットが実行されると、データベース上の処理番号は2となる。APLサーバ#2は前記コミットの次の処理であるデータベース上の処理番号を取得して、処理番号は2を取得してしまう。この結果、APLサーバ#2の処理は、処理Aを処理Bをスキップして完了後に処理Cを実行することになってしまうので、処理矛盾が発生することになる。
このように、現存するRDBMSを用いたシステムにおいて、アプリケーションを同時実行すると、データ更新時のデータを保証しようとするRDBMS機能(排他)と、サーバ故障を危惧して複数台のAPLサーバにて同時実行しユーザ応答時間を保証しようとする仕組みとでは、相反する課題が発生してしまう。また、APLサーバ故障時に実行していた要求をその処理時点から保証するためには、アプリケーションのメモリ上の更新データを引き継ぐ仕組みが必要となる。
本発明はこのような課題に鑑みてなされたものであって、APLサーバが故障しても、他のAPLサーバが要求を実行してその結果をRDBMSのメモリに記憶させておくことにより、後続の同一のアプリケーション要求に対しては前記メモリに記憶されている処理結果を返すことにより、同一要求の同一アプリケーションに対しては、正常なアプリケーション結果を返すことができるデータベースアクセス方法及び装置を提供することを目的としている。
前述した課題の解決手段は、RDBMSを用いたシステムにおいて、ユーザから1つの要求を複数のAPLサーバ(同じアプリケーション、同じロジック)にて同時実行が可能なデータベースアクセスにある。本発明の課題の解決手段として、ユーザの1つの要求に同時実行する複数サーバからのデータベースアクセスに対して、最初のAPLサーバからのアクセスをRDBMSにアクセス・応答し、2つ目以降の同一アクセスは、最初のデータベースアクセス結果で応答することで解決する。
また、前述したAPLサーバのアクセス(更新後)、後からアクセス(更新)したAPLサーバがRDBMSの排他により待たされる排他については、後からアクセス(更新)したAPLサーバは、RDBMSにアクセスしないようにすることで解決できる。
また、データベースアクセスにて全てのデータ(入出力情報)を管理するアプリケーションにおいて、前述した解決手段で、複数APLサーバで走行するアプリケーションは全てホットスタンバイであり、各APLサーバのメモリ上の更新データも自アプリケーションにて更新されており、APLサーバ故障時に更新データを引き継ぐ仕組みを必要としない。
(1)請求項1記載の発明は、RDBMSを利用するアプリケーションにおいて、同一アプリケーションを複数のアプリケーションサーバに配備し、ユーザからの一要求に対して、同時に同一要求を複数のアプリケーションサーバで実行することによって発生する複数のデータベースアクセスを、同一要求の識別を持ってアクセス順番でアクセス情報を管理し、アクセス順番により最初のアクセスであれば、RDBMSにアクセスし、その結果をRDBMS内のメモリにアクセス情報として保存しアクセス元のアプリケーションサーバに結果を戻し、以降に発生する他アプリケーションサーバからの同一要求、同一アクセス順番のデータベースアクセスに対しては、保存した同一アクセス情報のアクセス結果を戻すようにしたことを特徴とする。
ここで、データベースアクセスとは、APLサーバにて動作するアプリケーションからのデータベースへのアクセスをいう。ユーザからの要求毎に、アプリケーションのロジックが異なる。要求毎に、データベースへのアクセスについてもアクセス内容とそのアクセス順番はさまざまである。
次に、RDBMSアクセスとは、現存するRDBMSへのアクセスをいう。
アクセス内容は、RDBMSアクセス(DBトランザクション取得,レコード生成,削除,更新,参照,コミット/ロールバック,DBトランザクション開放)の内容である。各要求に対する各アプリケーションの動作によって、パラメータとアクセス順番はさまざまである。
アクセス結果は、アクセス内容によってRDBMSへアクセスした結果をいう。
アクセス情報は、要求毎のアクセス内容とそのアクセス順番とアクセス結果、及び各APLサーバの実行状況をいう。
(2)請求項2記載の発明は、前記RDBMSへのアクセス情報を管理し、ユーザからの一要求に対して同一アクセス内容・順番のデータベースアクセスであれば、各アプリケーションサーバに同一のアクセス結果を保証するデータベースアクセス制御部をRDBMSを制御するデータベースサーバに配備するようにしたことを特徴とする。
(3)請求項3記載の発明は、コミット/ロールバックが、ユーザからの一要求の最後のデータベースアクセスとなるアプリケーションのロジックにおいて、最初にコミット/ロールバックしたアプリケーションサーバに結果を戻した以降に、同一要求IDに対して発生した他アプリケーションサーバからの全てのデータベースアクセスの結果を、要求実行完了でアプリケーションサーバに戻すようにしたことを特徴とする。
(4)請求項4記載の発明は、ユーザからの一要求を識別するシステム一意の識別子(要求ID)と、各アプリケーションサーバを識別するシステム一意の識別情報(APLサーバID)と、アクセス内容よりなる入力情報に、アプリケーションサーバ負荷情報(CPU使用率、リソース使用量等)を加えた入力情報として各アプリケーションサーバからのデータベースアクセス時に各アプリケーションサーバの負荷を判断して、一定以上の負荷がかかっている場合、また他のアプリケーションサーバとの負荷情報の差異が一定の範囲を超えたと判断した場合に、アプリケーションサーバのデータベースアクセスに対する結果、要求実行中止の旨をアプリケーションサーバに戻すようにしたことを特徴とする。
(5)請求項5記載の発明は、ユーザからのデータを入力すると共にデータを出力するアプリケーション同時実行制御部と、該アプリケーション同時実行制御部と接続され、アプリケーション処理を実行する複数のアプリケーションサーバと、該アプリケーションサーバと接続され、データを蓄積するデータベースを有するデータベースサーバとを含んで構成された装置において、前記アプリケーションサーバ内にRDBMSへアクセスするためのインタフェースをアプリケーション部に提供し、アプリケーション部からの入力情報と共にアプリケーションサーバIDをパラメータに付与して後述するデータベースアクセス制御部に通知するデータベースアクセスメソッド部を設け、前記データベースサーバ内に、前記データベースアクセスメソッド部からの入力情報を元に、同一要求毎にアクセス情報として管理し、アクセス内容毎に最初のアクセスをRDBMSアクセスし、そのアクセス情報をメモリに保存した後、アクセス元のアプリケーションサーバに結果を戻すデータベースアクセス制御部を設けたことを特徴とする。
(1)請求項1記載の発明によれば、RDBMSを用いたシステムにおいて、ユーザからの1つの要求を複数のAPLサーバにて同一アプリケーション、同一ロジックで同時実行することで、要求実行中のAPLサーバが故障しても、1台でも正常に要求実行したAPLサーバが存在すれば、サービス無中断(サーバ切替不要)にてユーザへの応答を保証することができる。また、要求実行中に突発的な負荷が一部のAPLサーバに発生しても、負荷の低い他APLサーバが先行してデータベースアクセスを行なうため、APLサーバ負荷によるユーザへの応答遅れを軽減することができる。
(2)請求項2記載の発明によれば、RDBMSを用いたシステムにおいて、ユーザからの1つの要求を複数のAPLサーバにて同一アプリケーション、同一ロジックで同時実行することで、要求実行中のAPLサーバが故障しても、1台でも正常に要求実行したAPLサーバが存在すれば、サービス無中断(サーバ切替不要)にてユーザへの応答を保証することができる。また、要求実行中に突発的な負荷が一部のAPLサーバに発生しても、負荷の低い他APLサーバが先行してデータベースアクセスを行なうため、APLサーバ負荷によるユーザへの応答遅れを軽減することができる。
(3)請求項3記載の発明によれば、ユーザ要求を複数APLサーバで同時実行中に1つのAPLサーバがユーザ要求を完了した以降は、実行中の他のAPLサーバのデータベースアクセス時に、結果としてそのユーザ要求が完了していることを知らせることで、その要求に対する実行を中止することができ、APLサーバの負荷を軽減させることができる。
(4)請求項4記載の発明によれば、ユーザ要求を複数APLサーバで同時実行中に、データベースアクセス時に、APLサーバ負荷情報(CPU使用率,リソース使用量等)を付加することで、同時実行(冗長実行)を制御し、負荷が重くなったAPLサーバの要求実行を中止することができ、APLサーバの負荷を軽減することができる。
(5)RDBMSを用いたシステムにおいて、ユーザからの1つの要求を複数のAPLサーバにて同一アプリケーション、同一ロジックで同時実行することで、要求実行中のAPLサーバが故障しても、1台でも正常に要求実行したAPLサーバが存在すれば、サービス無中断(サーバ切替不要)にてユーザへの応答を保証することができる。また、要求実行中に突発的な負荷が一部のAPLサーバに発生しても、負荷の低い他APLサーバが先行してデータベースアクセスを行なうため、APLサーバ負荷によるユーザへの応答遅れを軽減することができる。
この場合において、ユーザ要求を複数APLサーバで同時実行中に、各APLサーバのデータベースアクセス実行状況(アクセス済み実行順番の差異)をチェックすることで、同時実行(冗長実行)を制御し、負荷が重くなったAPLサーバの要求実行を中止することができ、APLサーバの負荷を軽減することができる。
また、この場合において、アプリケーションのロジックに合わせたアクセス情報管理を行なうことで、さまざまなデータベースアクセスに対応することができる。
・ユーザの1つの要求に対して、1つのアクセス情報の管理とせず、管理単位をロジックに合わせてサブ要求IDとして管理することができる(ユーザの要求が複数のデータベーストランザクションで制御するロジックとなる場合)。
・データベーストランザクションの確定の単位であるコミット/ロールバックを、ユーザ要求の完了とせず、アプリケーションとのインタフェースに“業務開始/業務完了”を設けて管理することができる(ユーザの要求が複数のコミット/ロールバックを伴うロジックとなる場合)。
以下、図面を参照して本発明の実施の形態例を詳細に説明する。
図1は本発明の構成説明図である。図11と同一のものは、同一の符号を付して示す。
1),1)´フロントサーバ2からAPLサーバA,Bに同一のユーザ要求を通知する。
2),2)´APLサーバA,Bはデータベース(以後DBと略す)サーバ4(RDBMS)3にアクセスし、データの書き込みと読み出しを行ないアプリケーションを実行する。この場合において、アプリケーションのロジックによりAPLサーバA,Bから複数のアクセスが発生する。DBサーバ4は、ユーザ要求毎にアクセス順番、内容、結果を管理してメモリ4aに格納しておく。そして、APLサーバA,Bから同一のアクセスを、最初にアクセスした結果で応答する。即ち、APLサーバAが故障した場合、その故障の前にアプリケーション実行結果がメモリ4aに格納されておれば、そのメモリ4aの内容で応答することができる。
3)この発明によれば、APLサーバAが故障しても、APLサーバBは、ユーザ要求の処理を続け、要求完了後、ユーザ1に応答する。
本発明によれば、RDBMSを用いたシステムにおいて、ユーザからの1つの要求を複数のAPLサーバにて同一アプリケーション、同一ロジックで同時実行することで、要求実行中のAPLサーバが故障しても、1台でも正常に要求実行したAPLサーバが存在すれば、サービス無中断(サーバ切替不要)にてユーザへの応答を保証することができる。また、要求実行中に突発的な負荷が一部のAPLサーバに発生しても、負荷の低い他APLサーバが先行してデータベースアクセスを行なうため、APLサーバ負荷によるユーザへの応答遅れを軽減することができる。
図2は本発明システムの構成例を示すブロック図である。図1と同一のものは、同一の符号を付して示す。図において、2はフロントサーバ、2aはフロントサーバ2から入力されるユーザ要求である。10は本発明を具備するシステムである。本発明を具備するシステム10は、以下のような構成をもつ。
11はフロントサーバ2からのユーザ要求2aを受けるAPLサーバ同時実行制御部、3は該APLサーバ同時実行制御部11と接続されるAPLサーバである。該APLサーバ3は複数台配備される。APLサーバ3において、3aはアプリケーション部、3bはフロントサーバ2とAPLサーバ3にデータベースアクセスインタフェースを提供するDBアクセスメソッド部である。4はAPLサーバ3と接続されるDBサーバである。DBサーバ4において、4bはアクセス情報、4cは複数サーバからの同一内容のアクセス、及びアクセス順番を管理し、同一結果を保証するDBアクセス制御部、4dはRDBMS部、4aは各種情報を記憶するメモリとしてのデータベースである。
DBアクセス制御部4cは、負荷等によるサーバ毎のアクセスのタイミング遅れは、先のアクセス結果を保存し、後のアクセス結果に反映させることでカバーする。また、先にユーザ要求を完了したAPLサーバがいれば、以降の他サーバのアクセスは実行しない、先勝ち方式とする。以降の他サーバのアクセスは、要求実行完了として、アプリケーションで処理中の要求実行を止める指示をアクセス結果として通知する。
なお、図の下には、それぞれの信号線の種別と四角で囲った構成の説明がなされている。以下、各構成要素について詳細に説明する。
1.APLサーバ同時実行制御部11
ユーザからの1つの要求を入力情報とし、複数のAPLサーバ3に対してユーザ要求2aを通知する。入力情報に要求IDが含まれる場合は、その要求IDを含めた情報で、APLサーバ3にユーザ要求を通知する。入力情報に要求IDがない場合には、要求IDを付与し、その要求IDを含めた情報で、APLサーバ3にユーザ要求を通知する。そして、ユーザ要求を通知したAPLサーバ3からの要求結果を待ち受け、何れかのAPLサーバ3から要求結果を受けた時点で、ユーザへ要求結果を応答する。ここで、要求IDとは、ユーザからの要求を識別するシステム一意の識別子のことである。
2.アプリケーション部3a
APLサーバ同時実行制御部11からの入力情報(要求IDを含む)を元に、ユーザ要求に対するアプリケーションのロジックを実行する。データベースアクセスを行なう場合は、要求IDをパラメータに含めてDBアクセスメソッド部3bを実行する。アプリケーションのロジックにより、1要求で複数のDBトランザクションを使用する場合は、要求IDに、ロジックに対応した複数のサブ要求IDを付与して要求ID(入力の要求ID+サブ要求ID)とする。
3.DBアクセスメソッド部3b
RDBMS部4dへアクセス(DBトランザクション取得,レコード生成,削除,更新,参照,コミット/ロールバック,DBトランザクション開放)するためのインタフェースをアプリケーション部3aに提供し、アプリケーション部3aからの入力情報(要求IDを含む)と共にAPLサーバIDをパラメータに付与してDBアクセス制御部4cに通知する。また、APLサーバ負荷情報(CPU使用率又はリソース使用量)をパラメータとして設定することで、DBアクセス制御部4c側にて自APLサーバの要求実行制御を行なう。ここで、APLサーバIDは、APLサーバ3を識別するシステム一意の識別情報である。
4.DBアクセス制御部4c
DBアクセスメソッド部3bからの入力情報を元に、同一要求毎にアクセス情報として管理し、アクセス内容毎に最初のアクセスをRDBMSアクセスし、そのアクセス情報を保存した後、アクセス元のAPLサーバ3に結果を戻す。以降、発生する同一アクセス内容、同一アクセス番号の他、APLサーバ(最初にアクセスしたAPLサーバ以外)からのデータベースアクセスは、保存した同一アクセス情報のアクセス結果を通知する。
また、1要求の全アクセスの完了(要求実行完了)を意味するアプリケーションとのインタフェースを明示的(コミット/ロールバック,DBトランザクション開放,要求完了インタフェース等)に決めておき、要求実行の完了を管理する。先に、要求実行完了したAPLサーバ3がいれば、以降の他APLサーバ3のアクセスは実行しない。以降の他APLサーバ3のアクセスは要求実行完了として、アプリケーションに処理中の要求実行を止める指示をアクセス結果として通知する。
また、アクセス情報にて管理するアクセス番号をもとに、先行するAPLサーバ3のアクセス番号との差異が規定値を越える場合、アクセスしたAPLサーバ3へアクセス結果として要求実行中止を通知する。また、入力情報にAPLサーバ負荷情報(CPU使用率又はリソース使用量等)を付加し、その値が規定値を越える場合、アクセスしたAPLサーバ3へアクセス結果として要求実行中止を通知する。
このように、本発明によれば、ユーザ要求を複数APLサーバ3で同時実行中に1つのAPLサーバ3がユーザ要求を完了した以降は、実行中の他のAPLサーバ3のデータベースアクセス時に、結果としてそのユーザ要求が完了していることを知らせることで、その要求に対する実行を中止することができ、APLサーバ3の負荷を軽減させることができる。
また、ユーザ要求を複数APLサーバ3で同時実行中に、データベースアクセス時に、APLサーバ負荷情報(CPU使用率,リソース使用量等)を付加することで、同時実行(冗長実行)を制御し、負荷が重くなったAPLサーバ3の要求実行を中止することができ、APLサーバ3の負荷を軽減することができる。
5.RDBMS部4d
既存のリレーショナルデータベースである。例えば、Oracle等がある。
図3はAPLサーバ同時実行制御部11の動作を示すフローチャートである。以降、フローチャートで示す記号等の意味は、図4に示す通りである。ユーザからの要求を受けると、システム一意となる要求IDを取得する(S1)。次に、既存の分散サーバにて管理される振り分け先APLサーバ情報から、分散可能な複数のAPLサーバ3を抽出する(S2)。次に、ユーザからの要求情報に要求IDを付加し、抽出した複数のAPLサーバ3にユーザ要求を通知する(S3)。APLサーバ3にてアプリケーションが実行され、その結果が出力されると、ユーザに対して出力情報を応答する(S4)。
図5はアプリケーション部3aの動作を示すフローチャートである。APLサーバ同時実行制御部11から要求情報と要求IDとからなるユーザ要求を受け付けると、本発明にて提供するDBアクセスメソッド部3bをアクセスする(S1)。DBアクセスメソッド部3bは、既存のデータベースアクセスの入力情報に要求IDを付加した入力情報でアクセスされる。そして、DBアクセスメソッドを実行し、アクセス結果が要求実行完了又は要求実行中止かチェックする(S2)。
アクセス結果が要求実行完了又は要求実行中止である場合には、ユーザ要求の実行を中止する(S3)。アクセス結果が要求実行完了でない場合、又は要求実行中止でない場合には、応答し、APLサーバ同時実行制御部11に対して出力情報(応答結果)を出力する(S4)。なお、図中に破線で囲った部分20は、アプリケーションロジックにより複数回のアクセスが発生する。
図6はDBアクセスメソッド部3bの動作を示すフローチャートである。DBアクセスメソッド部3bは、アプリケーションのロジックにてデータベースアクセスするメソッド分のDBアクセスメソッドを提供する。そして、DBアクセスメソッドを実装したAPLサーバ3のAPLサーバIDをシステムデータから読み込み(S1)、システムデータからAPLサーバ負荷情報(CPU使用率)を読み込む(S2)。そして、DBサーバにDBアクセスし、入力情報(既存のデータベースアクセスの入力情報、及び要求ID)とAPLサーバID、APLサーバ負荷情報を付加してDBサーバ4にアクセスし、通知する(S3)。
DBアクセス制御部4cは、これら情報を元に所定の処理を行なう。その間、DBサーバ4からのアクセス結果を待ち合わせし(S4)、受け取ったらアプリケーション部3aに応答する(S5)。アプリケーション部3aには、アクセス結果が出力情報として与えられる。
図7はDBアクセス制御部4cの動作を示すフローチャートである。DBアクセス制御部4cは、アクセス情報を管理し、RDBMS部4dへのRDBMSアクセスを制御する。アクセス情報は、要求ID、アクセス番号、DBトランザクションID、アクセス内容、アクセス結果、APLサーバ実行状況で構成する。APLサーバ3からの入力情報は、要求ID、アクセス内容、APLサーバID、CPU使用率である。
APLサーバ3からDBアクセスの通知があると、アクセス情報から入力情報(要求ID、APLサーバID)が一致する最後のアクセス番号を取得し(S1)、アクセス情報から同一要求IDのアクセス番号+1の情報を取得する(S2)。次に、要求IDの(アクセス番号+1)情報の有無を判定する(S3)。
アクセス番号+1の情報が存在しない場合は、RDBMS部4dにRDBMSアクセスし、RDBMSを実行する(S4)。RDBMS部4dからの結果が戻ると、アクセス情報に要求ID,(アクセス番号+1),DBトランザクションID,アクセス内容,アクセス結果,APLサーバ実行状態(APLサーバID)を登録する(S5)。ここで、DBトランザクションIDは、DBトランザクション取得にて上記を実行した結果であり、要求ID単位に最初のRDBMSアクセスで取得し、システム情報(DBトランザクションID)に設定する。以降の同一要求IDのDBアクセスは、上記アクセス情報を取得してRDBMSアクセス時にパラメータとして使用する。そして、アセス結果を出力情報に設定し(S6)、アクセス結果をAPLサーバ3に通知する(S7)。
要求IDの(アクセス番号+1)の情報が存在する場合は、先行するAPLサーバ3の実行状況確認、負荷状況確認を行なう。即ち、先行するAPLサーバ3の実行状況確認は、アクセス情報から入力情報(要求ID)で、最後のアクセス番号のアクセス情報(アクセス内容)を取得し(S8)、最後のアクセス内容を判定する(S9)。アクセス内容がDBトランザクション解放である場合は、出力情報のアクセス結果に“要求実行完了”を設定し、APLサーバ3に応答する(S10)。
アクセス内容がその他のアクセスである場合、要求IDの最後のアクセス番号と入力APLサーバ3の最後のアクセス番号との差異を算出する(S11)。そして、アクセス番号との差異>規定値であるかどうかチェックする(S12)。ここで、APLサーバ毎のアクセス番号の差異が規定値をオーバした場合は、アクセスしたAPLサーバ3の負荷が高いと判断する。アクセス番号との差異>規定値である場合には、出力情報のアクセス結果に“要求実行中止”を設定し、APLサーバ3に応答する(S14)。
アクセス番号との差異>規定値でない場合には、入力情報(CPU使用率)>規定値であるかどうかチェックする(S13)。ここで、入力情報(CPU使用率)が規定値をオーバした場合は、アクセスしたAPLサーバ3
の負荷が高いと判断する。そこで、(CPU使用率)>規定値である場合には、出力情報のアクセス結果に“要求実行中止”を設定し、APLサーバ3に応答する(S14)。
入力情報(CPU使用率)>規定値でない場合には、要求ID,(アクセス番号+1)のアクセス情報にAPLサーバ実行状態(APLサーバID)を追加し(S14)、要求ID,(アクセス番号+1)のアクセス情報のアクセス結果を出力情報に設定し(S15)、APLサーバに応答する(S7)。
RDBMS部4dは、現存するRDBMSである。指定したアクセス内容に対してアクセス結果を戻す機能を有する。
図9はアクセス情報を示す図である。要求IDと、アクセス番号と、DBトランザクションIDと、アクセス内容と、アクセス結果と、APLサーバの実行状態が登録されている。
図10は本発明の動作概要を示す図である。図2と同一のものは、同一の符号を付して示す。3はAPLサーバであり、APLサーバAとBの2台を示している。2はフロントサーバである。該フロントサーバ2はAPLサーバAとAPLサーバBと接続されている。各APLサーバ3において、3aはアプリケーション部、3bはDBアクセスメソッド部である。4cはDBアクセス制御部、4dはRDBMS部である。図中の※印は、「APLサーバID、及びサーバ負荷情報を付加してDBアクセス制御部に通知する」処理を示している。以下、通知処理と略する。
ユーザ(フロントサーバ)2からAPLサーバAとBに業務実行要求がなされる。以下、APLサーバA側の動作について説明する。APLサーバAでは、DBアクセス制御部4cに対して通知処理を行ない、要求実行を開始する(S1)。そして、RDBMS部4dからDBトランザクションを取得する。次にDBアクセス制御部4cに対して通知処理を行ない、DB情報(SELECT)を取得する(S2)。次に、DBアクセス制御部4cに対して通知処理を行ない、DB情報更新(1)(UPDATE)を行なう(S3)。
次に、DBアクセス制御部4cに対して通知処理を行ない、DB情報更新(2)(UPDATE)を行なう(S4)。次に、DBアクセス制御部4cに対して通知処理を行ない、DB確定(DBコミット)を行なう(S5)。次に、DBアクセス制御部4cに対して通知処理を行ない、要求実行終了する(S6)。この時、ユーザ(フロントサーバ)2に対して要求実行結果を通知し、DBトランザクションを開放する。
次に、APLサーバB側の動作について説明する。ユーザ(フロントサーバ)2からの業務実行要求がなされると、APLサーバBは、DBアクセス制御部4cに通知処理を行ない、DBトランザクションを取得する(S7)。次に、DBアクセス制御部4cに通知処理を行ない、DB情報(SELECT)を取得する(S8)。次に、DBアクセス制御部4cに通知処理を行ない、DB情報更新(1)(UPDATE)を行なう(S9)。次に、DBアクセス制御部4cに通知処理を行ない、DB情報(2)(UPDATE)を行なう(S10)。この時、APLサーバA側で既に実行処理が終了しているので、DBアクセス制御部4cから要求実行完了通知を受け、要求実行を破棄する。
以上、詳細に説明したように、本発明によれば、RDBMSを用いたシステムにおいて、ユーザからの1つの要求を複数のAPLサーバにて同一アプリケーション,同一ロジックで同時実行することで、要求実行中のAPLサーバが故障しても、1台でも正常に要求実行したAPLサーバが存在すれば、サービス無中断(サーバ切替不要)にてユーザへの応答を保証することができる。また、要求実行中に突発的な負荷が一部のAPLサーバに発生しても、負荷の低い他APLサーバが先行してデータベースアクセスを行なうため、APLサーバ負荷によるユーザへの応答遅れが軽減できる。
(付記1)
RDBMSを利用するアプリケーションにおいて、同一アプリケーションを複数のアプリケーションサーバに配備し、ユーザからの一要求に対して、同時に同一要求を複数のアプリケーションサーバで実行することによって発生する複数のデータベースアクセスを、同一要求の識別を持ってアクセス順番でアクセス情報を管理し、アクセス順番により最初のアクセスであれば、RDBMSにアクセスし、その結果をRDBMS内のメモリにアクセス情報として保存しアクセス元のアプリケーションサーバに結果を戻し、以降に発生する他アプリケーションサーバからの同一要求、同一アクセス順番のデータベースアクセスに対しては、保存した同一アクセス情報のアクセス結果を戻すようにしたことを特徴とするデータベースアクセス方法。
(付記2)
前記RDBMSへのアクセス情報を管理し、ユーザからの一要求に対して同一アクセス内容・順番のデータベースアクセスであれば、各アプリケーションサーバに同一のアクセス結果を保証するデータベースアクセス制御部をRDBMSを制御するデータベースサーバに配備するようにしたことを特徴とする。
(付記3)
コミット/ロールバックが、ユーザからの一要求の最後のデータベースアクセスとなるアプリケーションのロジックにおいて、最初にコミット/ロールバックしたアプリケーションサーバに結果を戻した以降に、同一要求IDに対して発生した他アプリケーションサーバからの全てのデータベースアクセスの結果を、要求実行完了でアプリケーションサーバに戻すようにしたことを特徴とする付記1又は2記載のデータベースアクセス方法。
(付記4)
ユーザからの一要求を識別するシステム一意の識別子と、各アプリケーションサーバを識別するシステム一意の識別情報と、アクセス内容よりなる入力情報に、アプリケーションサーバ負荷情報を加えた入力情報として各アプリケーションサーバからのデータベースアクセス時に各アプリケーションサーバの負荷を判断して、一定以上の負荷がかかっている場合、また他のアプリケーションサーバとの負荷情報の差異が一定の範囲を超えたと判断した場合に、アプリケーションサーバのデータベースアクセスに対する結果、要求実行中止の旨をアプリケーションサーバに戻すようにしたことを特徴とする付記1又は2記載のデータベースアクセス方法。
(付記5)
ユーザからのデータを入力すると共にデータを出力するアプリケーション同時実行制御部と、
該アプリケーション同時実行制御部と接続され、アプリケーション処理を実行する複数のアプリケーションサーバと、
該アプリケーションサーバと接続され、データを蓄積するデータベースを有するデータベースサーバとを含んで構成された装置において、
前記アプリケーションサーバ内にRDBMSへアクセスするためのインタフェースをアプリケーション部に提供し、アプリケーション部からの入力情報と共にアプリケーションサーバIDをパラメータに付与して後述するデータベースアクセス制御部に通知するデータベースアクセスメソッド部を設け、
前記データベースサーバ内に、前記データベースアクセスメソッド部からの入力情報を元に、同一要求毎にアクセス情報として管理し、アクセス内容毎に最初のアクセスをRDBMSアクセスし、そのアクセス情報をメモリに保存した後、アクセス元のアプリケーションサーバに結果を戻すデータベースアクセス制御部を設け、
たことを特徴とするデータベースアクセス装置。
(付記6)
複数のアプリケーションサーバで実行中の同一要求に対する各アプリケーションサーバの実行状況を、各アプリケーションサーバからのデータベースアクセス時に判断して、一定の遅れが発生したアプリケーションサーバのデータベースアクセスに対する結果、要求実行中止の旨をアプリケーションサーバに戻すことを特徴とする付記1又は2記載のデータベースアクセス方法。
(付記7)
ユーザからの一要求を識別するシステム一意の識別子と、各アプリケーションサーバを識別するシステム一意の識別情報と、アクセス内容よりなる入力情報の要求に加えてサブ要求IDをアプリケーションのロジックで規定し入力情報とすることによって、ユーザの一要求をサブ要求IDとして複数のデータベーストランザクションのアクセス情報を管理し、一要求であっても複数のデータベーストランザクションを取得してユーザからの要求を実行することを特徴とする付記1又は2記載のデータベースアクセス方法。
(付記8)
前記データベースアクセス制御部のインタフェースに業務開始/業務完了を設け、ユーザからの一要求の開始/完了をアプリケーションのロジックによって通知することを特徴とする付記1又は2記載のデータベースアクセス方法。
本発明の構成説明図である。 本発明システムの構成例を示すブロック図である。 APLサーバ同時実行制御部の動作を示すフローチャートである。 フローチャートの説明図である。 アプリケーション部の動作を示すフローチャートである。 DBアクセスメソッド部の動作を示すフローチャートである。 DBアクセス制御部の動作を示すフローチャートである。 DBアクセス制御部の動作を示すフローチャートである。 アクセス情報を示す図である。 本発明の動作概要を示す図である。 従来の分散構成の説明図である。 従来のHA構成の説明図である。
符号の説明
2 フロントサーバ
2a ユーザ要求
3 APLサーバ
3a アプリケーション部
3b DBアクセスメソッド部
4 DBサーバ
4a データベース
4b アクセス情報
4c DBアクセス制御部
4d RDBMS部
10 本発明を具備するシステム
11 APLサーバ同時実行制御部

Claims (5)

  1. RDBMSを利用するアプリケーションにおいて、同一アプリケーションを複数のアプリケーションサーバに配備し、ユーザからの一要求に対して、同時に同一要求を複数のアプリケーションサーバで実行することによって発生する複数のデータベースアクセスを、同一要求の識別を持ってアクセス順番でアクセス情報を管理し、アクセス順番により最初のアクセスであれば、RDBMSにアクセスし、その結果をRDBMS内のメモリにアクセス情報として保存しアクセス元のアプリケーションサーバに結果を戻し、以降に発生する他アプリケーションサーバからの同一要求、同一アクセス順番のデータベースアクセスに対しては、保存した同一アクセス情報のアクセス結果を戻すようにしたことを特徴とするデータベースアクセス方法。
  2. 前記RDBMSへのアクセス情報を管理し、ユーザからの一要求に対して同一アクセス内容・順番のデータベースアクセスであれば、各アプリケーションサーバに同一のアクセス結果を保証するデータベースアクセス制御部をRDBMSを制御するデータベースサーバに配備するようにしたことを特徴とする請求項1記載のデータベースアクセス方法。
  3. コミット/ロールバックが、ユーザからの一要求の最後のデータベースアクセスとなるアプリケーションのロジックにおいて、最初にコミット/ロールバックしたアプリケーションサーバに結果を戻した以降に、同一要求IDに対して発生した他アプリケーションサーバからの全てのデータベースアクセスの結果を、要求実行完了でアプリケーションサーバに戻すようにしたことを特徴とする請求項1又は2記載のデータベースアクセス方法。
  4. ユーザからの一要求を識別するシステム一意の識別子と、各アプリケーションサーバを識別するシステム一意の識別情報と、アクセス内容よりなる入力情報に、アプリケーションサーバ負荷情報を加えた入力情報として各アプリケーションサーバからのデータベースアクセス時に各アプリケーションサーバの負荷を判断して、一定以上の負荷がかかっている場合、また他のアプリケーションサーバとの負荷情報の差異が一定の範囲を超えたと判断した場合に、アプリケーションサーバのデータベースアクセスに対する結果、要求実行中止の旨をアプリケーションサーバに戻すようにしたことを特徴とする請求項1又は2記載のデータベースアクセス方法。
  5. ユーザからのデータを入力すると共にデータを出力するアプリケーション同時実行制御部と、
    該アプリケーション同時実行制御部と接続され、アプリケーション処理を実行する複数のアプリケーションサーバと、
    該アプリケーションサーバと接続され、データを蓄積するデータベースを有するデータベースサーバとを含んで構成された装置において、
    前記アプリケーションサーバ内にRDBMSへアクセスするためのインタフェースをアプリケーション部に提供し、アプリケーション部からの入力情報と共にアプリケーションサーバIDをパラメータに付与して後述するデータベースアクセス制御部に通知するデータベースアクセスメソッド部を設け、
    前記データベースサーバ内に、前記データベースアクセスメソッド部からの入力情報を元に、同一要求毎にアクセス情報として管理し、アクセス内容毎に最初のアクセスをRDBMSアクセスし、そのアクセス情報をメモリに保存した後、アクセス元のアプリケーションサーバに結果を戻すデータベースアクセス制御部を設け、
    たことを特徴とするデータベースアクセス装置。
JP2006085849A 2006-03-27 2006-03-27 データベースアクセス方法及び装置 Withdrawn JP2007264770A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2006085849A JP2007264770A (ja) 2006-03-27 2006-03-27 データベースアクセス方法及び装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2006085849A JP2007264770A (ja) 2006-03-27 2006-03-27 データベースアクセス方法及び装置

Publications (1)

Publication Number Publication Date
JP2007264770A true JP2007264770A (ja) 2007-10-11

Family

ID=38637737

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006085849A Withdrawn JP2007264770A (ja) 2006-03-27 2006-03-27 データベースアクセス方法及び装置

Country Status (1)

Country Link
JP (1) JP2007264770A (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009217503A (ja) * 2008-03-10 2009-09-24 Hitachi Ltd 計算機システム、計算機制御方法及び計算機制御プログラム
JP2013186509A (ja) * 2012-03-06 2013-09-19 Hitachi Ltd 複数サーバにおける同期方法
JP2014149862A (ja) * 2009-07-02 2014-08-21 Nhn Business Platform Corp 高可用性データベース管理システム、およびこれを用いたデータベース管理方法

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009217503A (ja) * 2008-03-10 2009-09-24 Hitachi Ltd 計算機システム、計算機制御方法及び計算機制御プログラム
JP2014149862A (ja) * 2009-07-02 2014-08-21 Nhn Business Platform Corp 高可用性データベース管理システム、およびこれを用いたデータベース管理方法
US9189348B2 (en) 2009-07-02 2015-11-17 Naver Corporation High availability database management system and database management method using same
JP2013186509A (ja) * 2012-03-06 2013-09-19 Hitachi Ltd 複数サーバにおける同期方法

Similar Documents

Publication Publication Date Title
CN114341792B (zh) 存储集群之间的数据分区切换
JP5191062B2 (ja) ストレージ制御システム、ストレージ制御システムに関する操作方法、データ・キャリア及びコンピュータ・プログラム
CN114787781B (zh) 用于启用高可用性受管理故障转移服务的系统和方法
US9442813B2 (en) Replaying jobs at a secondary location of a service
US9715522B2 (en) Information processing apparatus and control method
US9495293B1 (en) Zone consistency
US9165025B2 (en) Transaction recovery in a transaction processing computer system employing multiple transaction managers
EP2754059B1 (en) Clustered client failover
US20180101558A1 (en) Log-shipping data replication with early log record fetching
US9904573B2 (en) Transactional updating in dynamic distributed workloads
US11449241B2 (en) Customizable lock management for distributed resources
JP2001184248A (ja) 分散処理システムにおけるデータアクセス管理装置
JP2007264770A (ja) データベースアクセス方法及び装置
US10740320B2 (en) Systems and methods of operation lock management and system catalog overrides in database systems
WO2023274409A1 (zh) 在区块链系统中执行交易的方法和区块链节点
KR101696911B1 (ko) 분산 데이터 베이스 장치 및 그 장치에서의 스트림 데이터 처리 방법
JP2020095322A (ja) 分散ファイル装置、フェイルオーバ方法、プログラム及び記録媒体
JP5240861B2 (ja) 制御装置、データ移行システム、データ移行方法およびプログラム
JP2008090485A (ja) ジョブ管理装置、システムおよびプログラム
JP2010003265A (ja) データベース整合性チェック装置及び方法及びプログラム及びコンピュータ読取可能な記録媒体
US20170344281A1 (en) Methods for flexible data-mirroring to improve storage performance during mobility events and devices thereof
RU2714602C1 (ru) Способ и система для обработки данных
US11188522B2 (en) Streamlined database commit for synchronized nodes
JP2005063139A (ja) コンピュータシステムおよびプログラム
JP4280919B2 (ja) 複製管理システム、複製管理方法および複製管理プログラム

Legal Events

Date Code Title Description
A300 Application deemed to be withdrawn because no request for examination was validly filed

Free format text: JAPANESE INTERMEDIATE CODE: A300

Effective date: 20090602