JP4137264B2 - データベース負荷分散処理方法及びその実施装置 - Google Patents
データベース負荷分散処理方法及びその実施装置 Download PDFInfo
- Publication number
- JP4137264B2 JP4137264B2 JP00042299A JP42299A JP4137264B2 JP 4137264 B2 JP4137264 B2 JP 4137264B2 JP 00042299 A JP00042299 A JP 00042299A JP 42299 A JP42299 A JP 42299A JP 4137264 B2 JP4137264 B2 JP 4137264B2
- Authority
- JP
- Japan
- Prior art keywords
- processing
- path
- server
- load
- distributed function
- 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
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2458—Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
- G06F16/2471—Distributed queries
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/912—Applications of a database
- Y10S707/922—Communications
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/964—Database arrangement
- Y10S707/966—Distributed
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
- Y10S707/99953—Recoverability
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- General Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Computing Systems (AREA)
- Fuzzy Systems (AREA)
- Mathematical Physics (AREA)
- Probability & Statistics with Applications (AREA)
- Software Systems (AREA)
- Computational Linguistics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Computer And Data Communications (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明はデータベースアクセスの負荷分散を行うデータベース負荷分散処理システムに関し、特に複数の通信回線を介してクライアントシステムと接続されている複数のサーバシステムが管理する分散データベースアクセス環境で分散機能を実行するトランザクションにより負荷分散を行うデータベース負荷分散処理システムに適用して有効な技術に関するものである。
【０００２】
【従来の技術】
従来の複数のサーバによる分散データベースシステムでは、トランザクション処理プログラムやアプリケーションプログラム単位で負荷分散を行って処理効率を向上させている。アプリケーションプログラム単位の負荷分散を行うオンラインシステムの負荷分散方式については特開平６−１１０８５０号公報に記載されており、この方式ではネットワーク内で該当アプリケーションプログラムに対する負荷が最も低い計算機システムに処理を依頼している。
【０００３】
また従来の分散データベースシステムでは、ユーザアプリケーションプログラム（ＵＡＰ）にトランザクションエラー事象を検知して再実行を促すリトライ処理をＵＡＰに作り込んでおき、実行したトランザクションがエラーとなって利用資源の不稼動状況・障害状況が判明した場合に前記リトライ処理により当該トランザクションの再実行を行っている。
【０００４】
その他、従来の分散データベースシステムでは、統計解析情報としてファイルに出力された過去のトランザクションの処理結果を示す情報を編集・解析して目標のトランザクションスループットを実現する為の分散機能処理パス数を決め、決定した分散機能処理パス数でトランザクション処理を行うことにより次のトランザクションスループットを向上させている。
【０００５】
【発明が解決しようとする課題】
分散機能トランザクションスループットを確保することを目的としてトランザクション負荷を使用可能な通信・サーバシステムに分散させる為には、通信及びサーバシステムのリアルタイムな稼動状態・負荷状態の検知及び管理が必要になる。また分散データベース処理に必要な複数のシステム資源の使用負荷を統合管理し、個々の使用資源の負荷分散を行うだけでなく分散データベース処理トランザクション性能が確保できる様なシステム資源の割り当てを行う必要がある。
【０００６】
しかし、従来の複数のサーバによる分散データベースシステムの場合、分散データベース処理に必要な通信環境、サーバ処理を行うＣＰＵ、サーバトランザクション処理負荷等、複数のシステム情報を統合的に管理して経験値等から最適な実行資源を選択する処理が行われていない為、通信資源及びトランザクション処理サーバが複数存在する実行環境であってもトランザクションの負荷分散が行われずに特定の処理資源に負荷が集中して処理待ち時間が増大することによりトランザクションスループットが低下し、システム環境に適応した分散データベース処理トータルとしてのトランザクション性能を確保することが困難になるという問題がある。
【０００７】
また、前記従来の分散データベースシステムでは、ＵＡＰにトランザクションエラー事象を検知して再実行を促すリトライ処理をＵＡＰに作り込んでいる為、ＵＡＰ開発時にリトライ処理を作り込む工数が必要となるという問題がある。更に、分散機能処理パスの障害発生時に利用資源の不稼動状況・障害状況を把握して他のトランザクション実行に対して影響が最小となる様な交代パスの設定・選択を行うことが必要となるが、前記リトライ処理では実行したトランザクションがエラーとなって初めてそのリトライ処理を行ったＵＡＰに利用資源の不稼動状況・障害状況が判る為、障害時に全てのＵＡＰで利用資源の不稼動状況・障害状況が判明するまでにトランザクションエラー事象が多発してトランザクションスループットが低下するという問題がある。
【０００８】
また分散データベースシステムでは、業務内容の変更・トランザクション量の増大に伴う動的な業務実行環境の変動に対応する分散機能実行資源のチューニングを行う必要があるが、前記従来の分散データベースシステムでは、統計解析情報としてファイルに出力された過去のトランザクション処理結果を示す情報を編集・解析して目標のトランザクションスループットを実現する為の分散機能処理パス資源数を決めている為、業務トラフィックの動的な変動に伴うトランザクション量の増加に対応して通信及びサーバ資源の数を自動的に確保することができないという問題がある。
【０００９】
本発明の目的は上記問題を解決し、特定の通信資源やサーバ資源に負荷が集中することによるトランザクションスループットの低下を防止することが可能な技術を提供することにある。
【００１０】
本発明の他の目的は障害発生時のリトライ処理に伴うトランザクション実行エラー多発によるトランザクションスループットの低下を防止し、ＵＡＰへのトランザクションリトライ処理の作り込みを不要とすることが可能な技術を提供することにある。
【００１１】
本発明の他の目的は分散機能トランザクション実行時の処理パス数の決定を目的とする統計情報の取得・編集・解析というプロセスを省略して資源チューニングの工数を削減することが可能な技術を提供することにある。
【００１２】
【課題を解決するための手段】
本発明は複数のサーバで管理される分散データベースへのアクセスを負荷分散するデータベース負荷分散処理システムにおいて、通信状態及びサーバ状態を示す情報に応じてデータベースアクセスの負荷分散を行うものである。
【００１３】
本発明のデータベース負荷分散処理システムの通信状態管理処理部では、通信資源での障害の有無、負荷、稼動状態を監視して通信状態を管理し、サーバ状態管理処理部では、サーバでの障害の有無、負荷、稼動状態を監視してサーバ状態を管理する。
【００１４】
分散機能パス選択管理処理部では、前記通信状態及びサーバ状態を示す情報を参照し、優先度設定基準を基に各分散機能処理パスの選択優先度を設定する。トランザクションの処理要求が行われた場合には、前記設定した選択優先度に従って分散機能処理パスを分散機能クライアントに提示し、分散機能クライアントは提示を分散機能処理パスでのトランザクション処理を依頼する。
【００１５】
通信資源またはサーバの障害が発生した場合には、交代パス管理処理部により、障害が発生した分散機能処理パスを特定して前記選択優先度が最も高いパスを交代パスとして設定する。前記障害が発生したパスでトランザクションを処理中であった場合には、前記障害によりエラーが発生したトランザクションを前記交代パスで再実行する。
【００１６】
またパス選択学習処理部では、過去のトランザクション処理結果を示す負荷分散統計情報データと現在のトランザクション量を比較して最適な分散機能処理パス数を求め、現在の処理パス数を前記求めた分散機能処理パス数に変更して使用資源の最適化を行う。そして前記最適化した各分散機能処理パス毎のトランザクションの処理に要した処理時間を示すトランザクション処理時間を記録する。
【００１７】
分散機能パス選択管理処理部では、前記通信状態及びサーバ状態並びに前記トランザクション処理時間を示す情報に応じて、前記最適化した各分散機能処理パスの選択優先度を設定し、前記設定した選択優先度に従って分散機能処理パスを分散機能クライアントに提示する。
【００１８】
以上の様に本発明のデータベース負荷分散処理システムによれば、通信状態及びサーバ状態に応じて分散機能処理トランザクション要求を複数の通信資源及びサーバ資源に負荷分散させるので、特定の通信資源やサーバ資源に負荷が集中することによるトランザクションスループットの低下を防止することが可能である。
【００１９】
【発明の実施の形態】
以下に通信状態及びサーバ状態に応じてデータベースアクセスの負荷分散を行う一実施形態のデータベース負荷分散処理システムについて説明する。
【００２０】
図１は本実施形態のデータベース負荷分散処理システムの概略構成を示す図である。図１に示す様に本実施形態のＤＢクライアントは、分散機能パス選択管理処理部９と、資源負荷管理処理部２６と、通信状態管理処理部１２と、サーバ状態管理処理部１３と、交代パス管理処理部１４と、パス選択学習処理部１５と、通信資源状態管理処理部１７と、通信負荷状態管理処理部１８と、サーバ資源状態管理処理部１９と、サーバ負荷状態管理処理部２０とを有している。
【００２１】
分散機能パス選択管理処理部９は、通信状態及びサーバ状態を示す情報または過去のトランザクション処理時間に応じて分散機能処理パスの選択優先度を設定し、前記設定した選択優先度に従って分散機能処理パスを分散機能クライアントに提示する処理部である。
【００２２】
資源負荷管理処理部２６は、通信資源及びサーバ資源での障害の有無、負荷、稼動状態を管理する処理部である。通信状態管理処理部１２は、通信資源での障害の有無、負荷、稼動状態を監視して通信状態を管理する処理部である。
【００２３】
サーバ状態管理処理部１３は、サーバでの障害の有無、負荷、稼動状態を監視してサーバ状態を管理する処理部である。交代パス管理処理部１４は、通信資源またはサーバの障害が発生した場合に、障害が発生した分散機能処理パスを特定し、前記選択優先度が最も高いパスを交代パスとして設定し、前記障害によりエラーが発生したトランザクションを前記交代パスで再実行する処理部である。
【００２４】
パス選択学習処理部１５は、処理中の処理パス数を処理中のトランザクション量に適した分散機能処理パス数に変更し、各分散機能処理パス毎のトランザクション処理に要した処理時間を示すトランザクション処理時間を記録する処理部である。
【００２５】
通信資源状態管理処理部１７は、分散機能処理パス数や通信エンティティ数等の通信資源の状態を管理する処理部である。通信負荷状態管理処理部１８は、要求されたトランザクション量等の通信負荷を管理する処理部である。
【００２６】
サーバ資源状態管理処理部１９は、処理サーバ数等のサーバ資源の状態を管理する処理部である。サーバ負荷状態管理処理部２０は、サーバで処理したトランザクション量等のサーバ負荷の状態を管理する処理部である。
【００２７】
ＤＢクライアントを分散機能パス選択管理処理部９、資源負荷管理処理部２６、通信状態管理処理部１２、サーバ状態管理処理部１３、交代パス管理処理部１４、パス選択学習処理部１５、通信資源状態管理処理部１７、通信負荷状態管理処理部１８、サーバ資源状態管理処理部１９及びサーバ負荷状態管理処理部２０として機能させる為のプログラムは、ＣＤ−ＲＯＭ等の記録媒体に記録され磁気ディスク等に格納された後、メモリにロードされて実行されるものとする。なお前記プログラムを記録する媒体はＣＤ−ＲＯＭ以外の他の媒体でも良い。
【００２８】
ＤＢサーバは、サーバ状態監視処理部７と、負荷状態監視処理部２１と、稼動状態監視処理部２２と、運用管理処理部２３と、サーバ状態報告処理部２４とを有している。
【００２９】
サーバ状態監視処理部７は、サーバでの障害の有無、負荷、稼動状態を監視する処理部である。負荷状態監視処理部２１は、サーバで処理したトランザクション量を監視する処理部である。稼動状態監視処理部２２は、サーバの稼動状態を監視する処理部である。
【００３０】
運用管理処理部２３は、サーバの運用管理を行う処理部である。サーバ状態報告処理部２４は、サーバ状態監視処理部７により得られたサーバ状態を示す情報をサーバ状態管理処理部１３へ報告する処理部である。
【００３１】
ＤＢサーバをサーバ状態監視処理部７、負荷状態監視処理部２１、稼動状態監視処理部２２、運用管理処理部２３及びサーバ状態報告処理部２４として機能させる為のプログラムは、ＣＤ−ＲＯＭ等の記録媒体に記録され磁気ディスク等に格納された後、メモリにロードされて実行されるものとする。なお前記プログラムを記録する媒体はＣＤ−ＲＯＭ以外の他の媒体でも良い。
【００３２】
次に図２〜図５により通信資源及びサーバ資源管理、分散機能処理パス情報管理の方法について説明する。
【００３３】
図２は本実施形態の通信資源管理データの一例を示す図である。資源管理テーブル２７は通信環境に存在する通信処理装置１０毎の障害情報、稼動情報及び運用情報の設定を管理するテーブルである。障害情報は障害発生の有無を管理する情報であり、稼動情報はシステム起動の有無を管理する情報である。運用情報は通信処理装置１０の運用時間を定義した情報である。
【００３４】
通信資源に関する前記情報取得は、分散機能パス管理処理部４起動時の通信オープン処理時、通信障害発生時及びその回復時、通信負荷増大時、またはシステムに定義された監視時間（Δｔ）毎に行われる。前記情報取得を行う状態となっているかどうかは資源負荷管理処理部２６及び分散機能クライアント３によって監視される。
【００３５】
図３は本実施形態のサーバ資源管理データの一例を示す図である。資源管理テーブル２８は分散機能トランザクション処理を実行する分散機能サーバ６毎の障害情報、稼動情報及び運用情報の設定を管理するテーブルである。障害情報はサーバ障害発生の有無を管理する情報であり、稼動情報はサーバ起動の有無を管理する情報である。運用情報はサーバシステムの運用時間を本システムに定義した情報である。
【００３６】
サーバ資源に関する前記情報取得は、分散機能パス管理処理部４起動時のサーバ状態確認処理時、サーバ起動時のサーバ状態報告受信時、サーバ障害発生及び回復のサーバ状態報告受信時、サーバ処理トランザクション負荷増大時のサーバ状態報告受信時、システムに定義された監視時間（Δｔ）毎のサーバ状態報告受信時に行われる。
【００３７】
前記サーバ状態報告は、システム起動時に確立するクライアント側のサーバ状態管理処理部１３とサーバ側のサーバ状態報告処理部２４間のサーバ状態報告用の通信路及び通信プロトコルを使用し、サーバが前記情報取得の契機を検知してサーバ主導型でクライアントに送信することにより行われる。なお分散機能クライアント３のサーバシステムダウン監視タイマによる契機により行っても良い。
【００３８】
図４は本実施形態の分散機能処理パス情報管理データの一例を示す図である。前記契機で作成した資源管理テーブル２７及び資源管理テーブル２８を基に、同じ契機で分散機能処理パス情報管理テーブル２９を作成する。本テーブルは、分散機能トランザクションを実行する仮想的な資源単位である分散機能処理パス毎に、通信パス、通信経路、処理サーバ、通信利用情報、サーバ利用情報、通信負荷、サーバＣＰＵ負荷、サーバトランザクション負荷及び交代パス使用の有無を管理する。
【００３９】
通信パスは適用する通信エンティティ１１を示す。通信経路は適用する通信装置名を示す。処理サーバは適用する分散機能サーバ６を表している。通信利用情報は通信処理装置１０及び通信機能の稼動可否の情報である。サーバ利用情報はサーバシステムの稼動可否の情報である。通信利用情報またはサーバ利用情報のいづれかが否の場合には当該分散機能処理パスは使用不可となる。
【００４０】
通信負荷は当該通信エンティティを使用して送信要求を行っているトランザクション量を示す。サーバＣＰＵ負荷は当該サーバシステムの当該通信パスの処理におけるＣＰＵ利用率を示す。サーバトランザクション負荷はサーバシステムで分散ＤＢアクセスサーバ処理を実行しているサーバトランザクション量を示す。交代パス使用には交代機能として当該分散機能処理パスを使用しているか否かの情報を設定する。
【００４１】
図５は本実施形態のパス選択情報データの一例を示す図である。資源管理テーブル２７及び資源管理テーブル２８並びに分散機能処理パス情報管理テーブル２９は資源負荷管理処理部２６により管理される。分散機能処理パス情報管理テーブル２９で管理している分散機能処理パスの選択優先度をパス選択テーブル３０により管理しており、分散機能パス選択管理処理部９は、分散機能処理パス選択優先度設定基準に従って前記分散機能処理パス毎に選択優先度を付与する。
【００４２】
図６は本実施形態の分散機能処理パス選択優先度設定基準の一例を示す図である。ここで、分散機能処理パス情報管理テーブル２９、分散機能処理パス選択優先度設定基準５０、パス選択テーブル３０及び分散機能処理パス決定情報テーブル４１を適用した分散機能処理パス選択優先度の設定方法を示す。
【００４３】
分散機能パス選択管理処理部９は、資源負荷管理処理部２６が設定する分散機能処理パス情報管理テーブル２９を特定時間毎に参照して、各分散機能処理パス毎に選択優先度を付与してパス選択テーブル３０を生成する。
【００４４】
選択優先度の付与基準は以下の通りとする。まず［１］では分散機能処理パス情報管理テーブル２９の通信負荷、サーバＣＰＵ負荷及びサーバ負荷（処理トランザクション量）全てが最低である分散機能処理パスに対して選択優先度を設定する。次に［２］では［１］の設定基準で処理パスの選択優先度が設定できない場合（例えば、通信負荷が最低のパスはＰ11、サーバ負荷が最低のパスはＰ12等［１］の基準だけでは選択優先度が設定できない場合）に、図１０の分散機能処理パス決定情報テーブル４１を参照して、負荷が近似のパスの内でトランザクション処理時間が小さいパスから順に選択優先度を設定する。
【００４５】
分散機能処理パス決定情報テーブル４１は、パス選択学習処理部１５によって過去の統計情報としてメモリ上に管理され、システム閉塞時に統計情報格納ファイル１６として保存される。またシステム起動時に過去の定量分のデータが統計情報格納ファイル１６からメモリ上に読み出される。
【００４６】
分散機能パス選択管理処理部９は、分散機能処理トランザクション要求とは非同期に特定時間毎でパス選択テーブル３０にパス選択優先度を設定する。従って、分散機能処理トランザクション要求発生時に分散機能クライアント３は、パス選択テーブル３０に設定されている選択優先度が最高のパスを選択するだけで良く、選択処理のオーバヘッドを削減できる。
【００４７】
図７は本実施形態の分散機能処理パスの概念を示す図である。分散機能トランザクションを実行する仮想的な資源単位である分散機能処理パス（Ｐ11、Ｐ12、Ｐ21、Ｐ22）は、送受信の一単位資源である通信エンティティ１１（ＡＥ）と、通信処理装置１０、分散機能サーバ６の組み合わせにより分散機能パス管理処理部４に定義される。
【００４８】
図８は本実施形態のパス選択学習処理部１５に関連するインタフェースの概略を示す図である。パス選択学習処理部１５は、入出力トランザクション管理部３１、トランザクション負荷管理部３２、負荷分散統計情報データ管理部３３を有し、統計情報格納ファイル１６を用いて処理を行う。
【００４９】
パス選択学習処理部１５は、過去の時間Δｔの平均実行トランザクション量（ＴＲ）・現状の分散機能処理パス数（ＰＮ）・クライアント側の通信エンティティ数（ＣＮ）・処理サーバ数（ＳＶＮ）・算出したΔｔのトランザクション処理時間平均値（Ｔ1ａｖｅ）・算出したΔｔのトランザクションスループット（Ｔ2ａｖｅ）を負荷分散最適化統計情報テーブル（資源数決定情報テーブル４０）としてメモリ管理する。
【００５０】
分散機能クライアント３は現状の入力トランザクション数を把握しており、入出力トランザクション管理部３１は時間Δｔのあるチェックポイントでのトランザクション総数、各トランザクションの入出力時間及び処理時間を管理し、本値からΔｔの平均実行トランザクション量（ＴＲ）値を算出する。
【００５１】
トランザクション負荷管理部３２はΔｔのＴＲ値からＴ1ａｖｅ、Ｔ2ａｖｅを算出する。資源数決定情報テーブル４０を管理する負荷分散統計情報データ管理部３３は、入出力トランザクション管理部３１からＴＲ、トランザクション負荷管理部３２からＴ1ａｖｅ及びＴ2ａｖｅ、通信資源状態管理処理部１７からＰＮ、ＣＮ、サーバ資源状態管理処理部１９からＳＶＮを取得する。
【００５２】
また入出力トランザクション管理部３１は、各トランザクションの入出力時間、各トランザクション処理時間の他に、各トランザクションが使用した分散機能処理パスをメモリ上に管理している。入出力トランザクション管理部３１が管理する前記情報と、分散機能パス選択管理処理部９が管理する分散機能処理パス情報管理テーブル２９の情報により、負荷分散統計情報データ管理部３３は、特定時間毎に分散機能処理パス単位で最近当該パスを使用したトランザクション実行時の通信負荷、サーバＣＰＵ負荷、サーバ負荷（トランザクション量）及び当該トランザクション処理時間を分散機能処理パス決定情報テーブル４１の１エントリとして追加してメモリ上に蓄積・管理する。
【００５３】
負荷分散統計情報データ管理部３３は、システム閉塞時にメモリ上の負荷分散最適化統計情報テーブル（資源数決定情報テーブル４０及び分散機能処理パス決定情報テーブル４１）をファイルに格納し、また、システム起動時に前記負荷分散最適化統計情報テーブルを格納したファイルからシステム定義による設定範囲分のデータをローディングしてメモリに常駐させる。
【００５４】
図９は本実施形態の資源数決定情報の一例を示す図である。資源数決定情報テーブル４０は、過去のある時間Δｔのトランザクション量から現在実行中のトランザクション量に適応する分散機能処理パスの数を算出して現在確立中の分散機能処理パス数を自律的に変動させることを目的として参照・生成される統計情報データを格納しており、システム定義にて設定されるΔｔ毎のＴＲ、ＰＮ、ＣＮ、ＳＶＮ、Ｔ1ａｖｅ、Ｔ2ａｖｅの値を１レコードとして時系列に管理する。
【００５５】
図１０は本実施形態の分散機能処理パス決定情報の一例を示す図である。分散機能処理パス決定情報テーブル４１は、分散機能パス選択管理処理部９が分散機能処理パスの選択優先度をパス選択テーブル３０に設定する際、トランザクション処理時間が最小になる様な分散機能処理パスの選択優先度を上げることを目的として参照される統計情報データを格納している。前記両テーブルはパス選択学習処理部１５により管理される。
【００５６】
次に本実施形態の処理の流れを図により説明する。まず、分散機能パス管理処理部４の開始及び閉塞処理について図１１及び図１２により説明する。
【００５７】
図１１は本実施形態の分散機能パス管理開始処理の処理手順を示すフローチャートである。システム起動時の処理として、ステップ６０１で分散機能パス管理用の資源をイニシャライズし、ステップ６０２でパス選択学習処理部１５により負荷分散最適化統計情報テーブル（資源数決定情報テーブル４０及び分散機能処理パス決定情報テーブル４１）のローディングを行った後、ステップ６０３でサーバ状態報告用通信をサーバ状態管理処理部１３とサーバ状態報告処理部２４間で確立する。
【００５８】
ステップ６０４で分散機能処理パスを１つ以上確保可能かどうかを調べ、起動している分散機能サーバシステムが１つ以上存在する場合にはステップ６０７に進み、未起動サーバが起動時にサーバ状態報告用通信を使用して送信する状態報告データの受信または起動中のサーバが定期的に送信する状態報告データの受信を行う為にサーバ状態報告受信待ちタスクを起動する。ステップ６０４で起動中のサーバが存在しない場合には、ステップ６０５で分散機能処理不可メッセージを出力した後、ステップ６０６で前記サーバ状態報告受信待ちタスクを起動する。
【００５９】
その後ステップ６０８では、起動中のサーバから運用、稼動、障害情報を前記状態報告データにより取得し、ステップ６０９で資源管理テーブル２８及び分散機能処理パス情報管理テーブル２９を作成する。
【００６０】
次にステップ６１０で通信オープン処理を行う。この時、資源管理テーブル２７を生成し、通信障害情報が存在する場合、資源管理テーブル２７に反映する。その後、ステップ６１１で分散機能トランザクションを実行する為の分散機能処理パス及び通信路を確立し、ステップ６１２〜ステップ６１４で資源負荷管理処理部２６、分散機能パス選択管理処理部９及びパス選択学習処理部１５を起動してステップ６１５で開始処理を完了する。
【００６１】
図１２は本実施形態の分散機能パス管理閉塞処理の処理手順を示すフローチャートである。システム閉塞時の処理としては、ステップ６１６で資源負荷管理処理部２６を閉塞した後、ステップ６１７で通信の閉塞処理、ステップ６１８で分散機能パス選択管理処理部９の閉塞処理を行う。その後、ステップ６１９で負荷分散最適化統計情報テーブル（資源数決定情報テーブル４０及び分散機能処理パス決定情報テーブル４１）をファイルに格納した後、ステップ６２０でパス選択学習処理部１５を閉塞してステップ６２１で閉塞処理を完了する。
【００６２】
次にクライアントの分散機能パス管理処理部４起動時のサーバ状態管理処理部１３及びサーバ状態報告処理部２４の処理について図１３〜図１５により説明する。
【００６３】
図１３は本実施形態のサーバ状態管理処理部１３及びサーバ状態報告処理部２４の処理手順を示すフローチャートである。分散機能パス管理処理部４の開始処理で起動された起動時サーバ状態管理処理（ＲＩ）は、ステップ７０１で未起動サーバが存在する場合にステップ７０２に進み、システム環境に定義された全てのサーバからの起動時の状態を報告を受ける受信処理を専用タスクで行う。
【００６４】
ステップ７０３では、サーバから受信した状態報告データの内容により、資源管理テーブル２７及び資源管理テーブル２８、分散機能処理パス情報管理テーブル２９を生成または更新する。
【００６５】
ステップ７０４では、起動を確認したサーバに対して分散機能処理パス及びサーバ状態報告用パスを確立する。特定時間サーバからの受信データがない場合、サーバ未起動と認識して、その旨を資源管理テーブル２７及び資源管理テーブル２８、分散機能処理パス情報管理テーブル２９に反映する。定義された全サーバが起動した時点で起動時サーバ状態管理処理（ＲＩ）を終了する。
【００６６】
分散機能サーバ６の起動時のサーバ状態報告処理部２４の開始処理（ＲＳＶ１）では、まずステップ７０５でサーバ主導でクライアント側のサーバ状態管理処理部１３との間にサーバ状態報告用の通信を確立して、ステップ７０６で分散機能サーバ状態・サーバＣＰＵ負荷・運用情報（サーバシステム定義情報等）を取得し、ステップ７０７でサーバ起動時の状態としてサーバ状態管理処理部１３に報告を行う。
【００６７】
図１４は本実施形態のサーバ主導型サーバ状態管理報告の処理手順を示すフローチャートである。サーバ状態の報告は、サーバ主導型（ＲＳＶ２）とクライアントからの問い合わせ応答型（ＲＳＶ３）の２つの形態がある。サーバ主導型（ＲＳＶ２）の場合、まずステップ７０８で分散機能サーバ６の稼働中に閉塞指示があるかどうかを調べ、閉塞指示がある迄ステップ７０９以下の処理を行う。
【００６８】
サーバシステム定義等で設定されたサーバ状態確認インターバル毎またはサーバ障害発生時にステップ７０９からステップ７１０〜ステップ７１２の処理に進み、サーバ状態をクライアント側に報告する。前記報告の際には、報告する情報として分散機能サーバ状態・サーバＣＰＵ負荷・サーバ分散ＤＢアクセストランザクション負荷・サーバＤＢＭＳ負荷・ＤＢ排他情報をチェックしてサーバ状態報告送信データを作成し、分散機能サーバ６内の資源負荷管理処理部２６が保持する資源管理テーブル２７を参照して最小負荷の通信資源でサーバ状態報告送信処理を行う。
【００６９】
図１５は本実施形態のクライアント主導型サーバ状態管理報告の処理手順を示すフローチャートである。クライアント主導型（ＲＳＶ３）の場合、ステップ７１３で分散機能サーバ６の稼動中に閉塞指示があるかどうかを調べ、閉塞指示がある迄ステップ７１４以下の処理を行う。
【００７０】
ステップ７１４でクライアントのサーバ状態管理処理部１３からのサーバ状態報告問い合わせを受信すると、ステップ７１５〜ステップ７１７で前記サーバ状態（分散機能サーバ状態・サーバＣＰＵ負荷・サーバ分散ＤＢアクセストランザクション負荷・サーバＤＢＭＳ負荷・ＤＢ排他情報）を報告する。
【００７１】
図１６は本実施形態の分散機能パス選択管理処理部９の処理手順を示すフローチャートである。分散機能パス管理処理部４の開始処理に於いて、分散機能パス選択管理処理メイン（Ｍ）は、ステップ８０１及びステップ８０２で分散機能パス選択管理処理部９の資源である分散機能処理パス情報管理テーブル２９及びパス選択テーブル３０を初期設定後、ステップ８０３で分散機能クライアント３からのトランザクション処理要求とは非同期に動作する分散機能パス選択管理処理部９専用のタスク上で、Δｔ毎にパス選択処理（Ｍ１）を起動する。
【００７２】
図１７は本実施形態のパス選択処理の処理手順を示すフローチャートである。起動されたパス選択処理（Ｍ１）は、ステップ８０４でパス選択学習処理部１５が管理する分散機能処理パス決定情報テーブル４１を参照して、分散機能処理パス選択優先度設定基準５０に基づきパス選択テーブル３０に分散機能処理パスの選択優先度を設定する。
【００７３】
図１８は本実施形態のパス提示処理の処理手順を示すフローチャートである。ＵＡＰ１からの分散機能トランザクション要求（分散データベースアクセス要求）がある場合、分散機能クライアント３から、分散機能パス選択管理処理部９がコールされ、ステップ８０５では、前記設定したパス選択テーブル３０を参照して選択優先度が最高のパスを分散機能クライアント３に提示する。分散機能クライアント３は前記提示されたパスを用いてトランザクション要求を行う。
【００７４】
なお本実施形態では、利用可能な資源の範囲でクライアントシステム側のＵＡＰ１と特定サーバシステムのＤＢ２５とを特定の分散機能処理パスでの論理的な括りつけを行うことにより、特定の業務から操作する分散データベースの範囲を固定にした上でその他の分散データベース業務トランザクションの処理負荷を分散させることとしても良い。
【００７５】
次に通信及びサーバ状態（稼動・負荷状態）を管理する資源負荷管理処理部２６の処理について図１９〜図２１により説明する。
【００７６】
図１９は本実施形態の資源負荷管理処理部２６の処理手順を示すフローチャートである。資源負荷管理メイン（Ｒ）は、分散機能パス管理処理部４の開始処理時にタスクとして起動され、ステップ９０１では各種事象を監視し、分散機能クライアント３からの通信障害及びサーバ障害事象を検知した場合、分散機能処理パス情報管理テーブル２９を参照して負荷増大事象を検知した場合、または特定時間が経過した場合にステップ９０２〜ステップ９０４の処理に進み、通信状態管理処理部１２（Ｒ１）、サーバ状態管理処理部１３（Ｒ２）、交代パス管理処理部１４（Ｒ３）を起動する。
【００７７】
図２０は本実施形態の通信状態管理処理の処理手順を示すフローチャートである。前記契機で起動された通信状態管理処理部１２では、次に示す要領で通信障害の有無、通信負荷、通信稼動状態を管理する。通信障害を検知した場合にはステップ９０５で、資源管理テーブル２７及び分散機能処理パス情報管理テーブル２９を更新する。ステップ９０６では分散機能処理パス毎に分散機能処理パス情報管理テーブル２９の通信負荷を更新し、当該通信負荷の値をチェックして分散機能処理パス毎のトランザクション負荷を管理する。ステップ９０７では資源管理テーブル２７の運用情報を基に各通信資源の稼動状態をチェックして資源管理テーブル２７の稼動情報を更新し、その稼動情報の変更に対応する分散機能処理パス情報管理テーブル２９の内容を更新する。
【００７８】
図２１は本実施形態のサーバ状態管理処理の処理手順を示すフローチャートである。前記契機で起動されたサーバ状態管理処理部１３では、次の要領でサーバ障害有無、負荷状態及びサーバ稼動状態を管理する。まずステップ９０８でサーバ状態報告処理部２４からのサーバ状態報告を受信して、ステップ９０９で分散機能クライアント３のサーバシステムダウン検知状況を確認して資源管理テーブル２８に反映する。またステップ９１０では、前記受信したサーバ状態報告の内容からサーバ障害情報及び負荷情報に関して資源管理テーブル２８及び分散機能処理パス情報管理テーブル２９を更新する。ステップ９１１では資源管理テーブル２８の運用情報を基に各サーバの稼動状態をチェックして資源管理テーブル２８の稼動情報を更新し、その稼動情報の変更に対応する分散機能処理パス情報管理テーブル２９の内容を更新する。
【００７９】
図２２は本実施形態の交代パス管理処理の処理手順を示すフローチャートである。交代パス管理処理部１４は、ステップ９１２で通信及びサーバの障害または回復事象発生時に通信状態管理処理部１２及びサーバ状態管理処理部１３から起動され、ステップ９１３で通信資源及びサーバ資源の障害または回復事象が発生した分散機能処理パスを特定する。障害事象の場合にはステップ９１４で分散機能処理パス情報管理テーブル２９を参照して最小負荷のパスを選択して交代パスとして登録し、また障害回復時にはステップ９１４で交代パス登録を抹消する。ステップ９１５ではパス障害によりエラーが発生したトランザクションが存在する場合にＵＡＰ１へエラーリターンさせずに前記交代パスを使用して再実行させる。
【００８０】
交代パスに関しては、予めパス障害時にのみ交代パスとして使用する旨のシステム定義をしておき、障害発生パスが回復しない間は、前記の定義したパスを障害発生パスの代替パスとして使用する方法と、現在使用中のパスの中から負荷の低いパスを交代パスとして設定する方法がある。
【００８１】
トランザクションスループットを下げない為には前者の運用が望ましいが、通信装置毎やサーバシステム毎に交代パスが必要となる為、システム資源の問題で交代パスを余分に設定できない場合には障害が発生したトランザクションを後者の交代パスで処理させることになる。
【００８２】
またステップ９１６で交代パス登録・抹消状況及びエラートランザクション再実行状況をログ及びメッセージ出力することによりエラー発生の状況（頻度・リトライ時間）がトランザクションスループットに与える影響を解析して、システム構築資源のチューニング（通信回線本数等）に利用することができる。
【００８３】
図２３は本実施形態のパス選択学習開始処理の処理手順を示すフローチャートである。まず分散機能パス管理処理部４の開始処理時にパス選択学習開始処理（ＳＩ）がコールされ、ステップ１００１で負荷分散最適化統計情報テーブルの資源数決定情報テーブル４０及び分散機能処理パス決定情報テーブル４１を統計情報格納ファイル１６からローディングする。この時、ステップ１００２でシステム定義によりメモリに常駐化させるテーブルの範囲（ｎ日分、ｍレコード分等）を設定しておき、当該範囲の負荷分散最適化統計情報テーブルデータをメモリに展開する。
【００８４】
図２４は本実施形態のパス選択学習閉塞処理の処理手順を示すフローチャートである。分散機能パス管理処理部４の閉塞処理時にパス選択学習閉塞処理（ＳＴ）がコールされ、ステップ１００３でメモリ上の負荷分散最適化統計情報テーブル（資源数決定情報テーブル４０及び分散機能処理パス決定情報テーブル４１）を統計情報格納ファイル１６に格納する。
【００８５】
図２５は本実施形態のパス選択学習処理の処理手順を示すフローチャートである。パス選択学習処理メイン（Ｓ）は、分散機能パス管理処理部４の開始処理時にタスクとして起動され、ステップ１００４、ステップ１００７、ステップ１０１０で特定時間（Δｔ）の経過が検出される毎に、ステップ１００８でトランザクション統計情報取得処理（Ｓ1）、ステップ１００５で使用資源数最適化処理（Ｓ2）及びステップ１０１１でパス選択優先度情報管理（Ｓ3）を起動する。
【００８６】
前記契機で起動されたトランザクション統計情報取得処理（Ｓ1）、使用資源数最適化処理（Ｓ2）及びパス選択優先度情報管理（Ｓ3）に関して、以下に処理内容を示す。
【００８７】
図２６は本実施形態のトランザクション統計情報取得処理の処理手順を示すフローチャートである。トランザクション統計情報取得処理（Ｓ1）では、ステップ１１０１で分散機能パス選択管理処理部９が一定間隔で出力する当該時点での総トランザクション量の値を蓄積し、過去のΔｔの平均トランザクション数（ＴＲ）を算出する。
【００８８】
またステップ１１０２で通信状態管理処理部１２から通信エンティティ数（ＣＮ）及び分散機能処理パス数（ＰＮ）を取得し、ステップ１１０３でサーバ状態管理処理部１３から現状の処理サーバ数（ＳＶＮ）を取得する。
【００８９】
ステップ１１０４で前記ＴＲからトランザクション平均処理時間（Ｔ1ａｖｅ）及びトランザクションスループット（Ｔ2ａｖｅ）を算出し、ステップ１１０５で前記ＴＲ、ＣＮ、ＰＮ、ＳＶＮ、Ｔ1ａｖｅ、Ｔ2ａｖｅを各項目とする１レコードを作成して、時系列に負荷分散最適化統計情報テーブル（資源数決定情報テーブル４０）に管理する。
【００９０】
図２７は本実施形態の使用資源数最適化処理の処理手順を示すフローチャートである。使用資源数最適化処理（Ｓ2）では、前記Ｓ1の処理と同様にステップ１１０６で過去のΔｔの平均トランザクション数（ＴＲｃ）を算出し、また前記Ｓ1の処理と同様にステップ１１０７で現時点での通信エンティティ数（ＣＮｃ）、分散機能処理パス数（ＰＮｃ）、処理サーバ数（ＳＶＮｃ）を取得する。
【００９１】
ステップ１１０８で負荷分散最適化統計情報テーブル（資源数決定情報テーブル４０）を参照して、ＴＲｃの値から、Ｔ1ａｖｅが最小、Ｔ2ａｖｅが最大になる様なＣＮ及びＰＮの値を決定して、ステップ１１０９で現状のパス数を前記決定値に基づき増減させる。この時、パス数を減少させる場合、仕掛かり中のトランザクション処理の完了を待ち、当該パスを閉塞する。
【００９２】
図２８は本実施形態のパス選択優先度情報管理の処理手順を示すフローチャートである。パス選択優先度情報管理（Ｓ3）では、まずステップ１１１０で入出力トランザクション管理部３１が管理するトランザクション処理時間及びトランザクションが使用したパス情報を入力し、またステップ１１１１で分散機能パス選択管理処理部９が管理するパス情報（分散機能処理パス情報管理テーブル２９の情報）を入力した後、ステップ１１１２で前記入力情報から分散機能処理パス毎に、負荷情報及び最近のトランザクション処理時間の情報を分散機能処理パス決定情報テーブル４１に追加・変更する。本情報を基に分散機能パス選択管理処理部９がパス選択テーブル３０を生成する。
【００９３】
以上説明した様に本実施形態のデータベース負荷分散処理システムによれば、通信状態及びサーバ状態に応じて分散機能処理トランザクション要求を複数の通信資源及びサーバ資源に負荷分散させるので、特定の通信資源やサーバ資源に負荷が集中することによるトランザクションスループットの低下を防止することが可能である。
【００９４】
また本実施形態のデータベース負荷分散処理システムによれば、障害によりエラーが発生したトランザクションを交代パスで再実行するので、障害発生時のリトライ処理に伴うトランザクション実行エラー多発によるトランザクションスループットの低下を防止し、ＵＡＰへのトランザクションリトライ処理の作り込みを不要とすることが可能である。
【００９５】
また本実施形態のデータベース負荷分散処理システムによれば、過去のトランザクション実行状況と通信及びサーバ資源数に関する統計情報を参考にして、現状のトランザクション数に適合した資源数に動的及び自律的に変更するので、分散機能トランザクション実行時の処理パス数の決定を目的とする統計情報の取得・編集・解析というプロセスを省略して資源チューニングの工数を削減することが可能である。
【００９６】
【発明の効果】
本発明によれば通信状態及びサーバ状態に応じて分散機能処理トランザクション要求を複数の通信資源及びサーバ資源に負荷分散させるので、特定の通信資源やサーバ資源に負荷が集中することによるトランザクションスループットの低下を防止することが可能である。
【図面の簡単な説明】
【図１】本実施形態のデータベース負荷分散処理システムの概略構成を示す図である。
【図２】本実施形態の通信資源管理データの一例を示す図である。
【図３】本実施形態のサーバ資源管理データの一例を示す図である。
【図４】本実施形態の分散機能処理パス情報管理データの一例を示す図である。
【図５】本実施形態のパス選択情報データの一例を示す図である。
【図６】本実施形態の分散機能処理パス選択優先度設定基準の一例を示す図である。
【図７】本実施形態の分散機能処理パスの概念を示す図である。
【図８】本実施形態のパス選択学習処理部１５に関連するインタフェースの概略を示す図である。
【図９】本実施形態の資源数決定情報の一例を示す図である。
【図１０】本実施形態の分散機能処理パス決定情報の一例を示す図である。
【図１１】本実施形態の分散機能パス管理開始処理の処理手順を示すフローチャートである。
【図１２】本実施形態の分散機能パス管理閉塞処理の処理手順を示すフローチャートである。
【図１３】本実施形態のサーバ状態管理処理部１３及びサーバ状態報告処理部２４の処理手順を示すフローチャートである。
【図１４】本実施形態のサーバ主導型サーバ状態管理報告の処理手順を示すフローチャートである。
【図１５】本実施形態のクライアント主導型サーバ状態管理報告の処理手順を示すフローチャートである。
【図１６】本実施形態の分散機能パス選択管理処理部９の処理手順を示すフローチャートである。
【図１７】本実施形態のパス選択処理の処理手順を示すフローチャートである。
【図１８】本実施形態のパス提示処理の処理手順を示すフローチャートである。
【図１９】本実施形態の資源負荷管理処理部２６の処理手順を示すフローチャートである。
【図２０】本実施形態の通信状態管理処理の処理手順を示すフローチャートである。
【図２１】本実施形態のサーバ状態管理処理の処理手順を示すフローチャートである。
【図２２】本実施形態の交代パス管理処理の処理手順を示すフローチャートである。
【図２３】本実施形態のパス選択学習開始処理の処理手順を示すフローチャートである。
【図２４】本実施形態のパス選択学習閉塞処理の処理手順を示すフローチャートである。
【図２５】本実施形態のパス選択学習処理の処理手順を示すフローチャートである。
【図２６】本実施形態のトランザクション統計情報取得処理の処理手順を示すフローチャートである。
【図２７】本実施形態の使用資源数最適化処理の処理手順を示すフローチャートである。
【図２８】本実施形態のパス選択優先度情報管理の処理手順を示すフローチャートである。
【符号の説明】
１…ＵＡＰ、２…ＵＡＰスケジュール管理処理部、３…分散機能クライアント、４…分散機能パス管理処理部、５…通信管理処理部、６…分散機能サーバ、８…サーバＤＢＭＳ、１０…通信処理装置、１１…通信エンティティ、１６…統計情報格納ファイル、２５…ＤＢ、９…分散機能パス選択管理処理部、２６…資源負荷管理処理部、１２…通信状態管理処理部、１３…サーバ状態管理処理部、１４…交代パス管理処理部、１５…パス選択学習処理部、１７…通信資源状態管理処理部、１８…通信負荷状態管理処理部、１９…サーバ資源状態管理処理部、２０…サーバ負荷状態管理処理部、７…サーバ状態監視処理部、２１…負荷状態監視処理部、２２…稼動状態監視処理部、２３…運用管理処理部、２４…サーバ状態報告処理部、２７…資源管理テーブル、２８…資源管理テーブル、２９…分散機能処理パス情報管理テーブル、３０…パス選択テーブル、５０…分散機能処理パス選択優先度設定基準、３１…入出力トランザクション管理部、３２…トランザクション負荷管理部、３３…負荷分散統計情報データ管理部、４０…資源数決定情報テーブル、４１…分散機能処理パス決定情報テーブル。
【発明の属する技術分野】
本発明はデータベースアクセスの負荷分散を行うデータベース負荷分散処理システムに関し、特に複数の通信回線を介してクライアントシステムと接続されている複数のサーバシステムが管理する分散データベースアクセス環境で分散機能を実行するトランザクションにより負荷分散を行うデータベース負荷分散処理システムに適用して有効な技術に関するものである。
【０００２】
【従来の技術】
従来の複数のサーバによる分散データベースシステムでは、トランザクション処理プログラムやアプリケーションプログラム単位で負荷分散を行って処理効率を向上させている。アプリケーションプログラム単位の負荷分散を行うオンラインシステムの負荷分散方式については特開平６−１１０８５０号公報に記載されており、この方式ではネットワーク内で該当アプリケーションプログラムに対する負荷が最も低い計算機システムに処理を依頼している。
【０００３】
また従来の分散データベースシステムでは、ユーザアプリケーションプログラム（ＵＡＰ）にトランザクションエラー事象を検知して再実行を促すリトライ処理をＵＡＰに作り込んでおき、実行したトランザクションがエラーとなって利用資源の不稼動状況・障害状況が判明した場合に前記リトライ処理により当該トランザクションの再実行を行っている。
【０００４】
その他、従来の分散データベースシステムでは、統計解析情報としてファイルに出力された過去のトランザクションの処理結果を示す情報を編集・解析して目標のトランザクションスループットを実現する為の分散機能処理パス数を決め、決定した分散機能処理パス数でトランザクション処理を行うことにより次のトランザクションスループットを向上させている。
【０００５】
【発明が解決しようとする課題】
分散機能トランザクションスループットを確保することを目的としてトランザクション負荷を使用可能な通信・サーバシステムに分散させる為には、通信及びサーバシステムのリアルタイムな稼動状態・負荷状態の検知及び管理が必要になる。また分散データベース処理に必要な複数のシステム資源の使用負荷を統合管理し、個々の使用資源の負荷分散を行うだけでなく分散データベース処理トランザクション性能が確保できる様なシステム資源の割り当てを行う必要がある。
【０００６】
しかし、従来の複数のサーバによる分散データベースシステムの場合、分散データベース処理に必要な通信環境、サーバ処理を行うＣＰＵ、サーバトランザクション処理負荷等、複数のシステム情報を統合的に管理して経験値等から最適な実行資源を選択する処理が行われていない為、通信資源及びトランザクション処理サーバが複数存在する実行環境であってもトランザクションの負荷分散が行われずに特定の処理資源に負荷が集中して処理待ち時間が増大することによりトランザクションスループットが低下し、システム環境に適応した分散データベース処理トータルとしてのトランザクション性能を確保することが困難になるという問題がある。
【０００７】
また、前記従来の分散データベースシステムでは、ＵＡＰにトランザクションエラー事象を検知して再実行を促すリトライ処理をＵＡＰに作り込んでいる為、ＵＡＰ開発時にリトライ処理を作り込む工数が必要となるという問題がある。更に、分散機能処理パスの障害発生時に利用資源の不稼動状況・障害状況を把握して他のトランザクション実行に対して影響が最小となる様な交代パスの設定・選択を行うことが必要となるが、前記リトライ処理では実行したトランザクションがエラーとなって初めてそのリトライ処理を行ったＵＡＰに利用資源の不稼動状況・障害状況が判る為、障害時に全てのＵＡＰで利用資源の不稼動状況・障害状況が判明するまでにトランザクションエラー事象が多発してトランザクションスループットが低下するという問題がある。
【０００８】
また分散データベースシステムでは、業務内容の変更・トランザクション量の増大に伴う動的な業務実行環境の変動に対応する分散機能実行資源のチューニングを行う必要があるが、前記従来の分散データベースシステムでは、統計解析情報としてファイルに出力された過去のトランザクション処理結果を示す情報を編集・解析して目標のトランザクションスループットを実現する為の分散機能処理パス資源数を決めている為、業務トラフィックの動的な変動に伴うトランザクション量の増加に対応して通信及びサーバ資源の数を自動的に確保することができないという問題がある。
【０００９】
本発明の目的は上記問題を解決し、特定の通信資源やサーバ資源に負荷が集中することによるトランザクションスループットの低下を防止することが可能な技術を提供することにある。
【００１０】
本発明の他の目的は障害発生時のリトライ処理に伴うトランザクション実行エラー多発によるトランザクションスループットの低下を防止し、ＵＡＰへのトランザクションリトライ処理の作り込みを不要とすることが可能な技術を提供することにある。
【００１１】
本発明の他の目的は分散機能トランザクション実行時の処理パス数の決定を目的とする統計情報の取得・編集・解析というプロセスを省略して資源チューニングの工数を削減することが可能な技術を提供することにある。
【００１２】
【課題を解決するための手段】
本発明は複数のサーバで管理される分散データベースへのアクセスを負荷分散するデータベース負荷分散処理システムにおいて、通信状態及びサーバ状態を示す情報に応じてデータベースアクセスの負荷分散を行うものである。
【００１３】
本発明のデータベース負荷分散処理システムの通信状態管理処理部では、通信資源での障害の有無、負荷、稼動状態を監視して通信状態を管理し、サーバ状態管理処理部では、サーバでの障害の有無、負荷、稼動状態を監視してサーバ状態を管理する。
【００１４】
分散機能パス選択管理処理部では、前記通信状態及びサーバ状態を示す情報を参照し、優先度設定基準を基に各分散機能処理パスの選択優先度を設定する。トランザクションの処理要求が行われた場合には、前記設定した選択優先度に従って分散機能処理パスを分散機能クライアントに提示し、分散機能クライアントは提示を分散機能処理パスでのトランザクション処理を依頼する。
【００１５】
通信資源またはサーバの障害が発生した場合には、交代パス管理処理部により、障害が発生した分散機能処理パスを特定して前記選択優先度が最も高いパスを交代パスとして設定する。前記障害が発生したパスでトランザクションを処理中であった場合には、前記障害によりエラーが発生したトランザクションを前記交代パスで再実行する。
【００１６】
またパス選択学習処理部では、過去のトランザクション処理結果を示す負荷分散統計情報データと現在のトランザクション量を比較して最適な分散機能処理パス数を求め、現在の処理パス数を前記求めた分散機能処理パス数に変更して使用資源の最適化を行う。そして前記最適化した各分散機能処理パス毎のトランザクションの処理に要した処理時間を示すトランザクション処理時間を記録する。
【００１７】
分散機能パス選択管理処理部では、前記通信状態及びサーバ状態並びに前記トランザクション処理時間を示す情報に応じて、前記最適化した各分散機能処理パスの選択優先度を設定し、前記設定した選択優先度に従って分散機能処理パスを分散機能クライアントに提示する。
【００１８】
以上の様に本発明のデータベース負荷分散処理システムによれば、通信状態及びサーバ状態に応じて分散機能処理トランザクション要求を複数の通信資源及びサーバ資源に負荷分散させるので、特定の通信資源やサーバ資源に負荷が集中することによるトランザクションスループットの低下を防止することが可能である。
【００１９】
【発明の実施の形態】
以下に通信状態及びサーバ状態に応じてデータベースアクセスの負荷分散を行う一実施形態のデータベース負荷分散処理システムについて説明する。
【００２０】
図１は本実施形態のデータベース負荷分散処理システムの概略構成を示す図である。図１に示す様に本実施形態のＤＢクライアントは、分散機能パス選択管理処理部９と、資源負荷管理処理部２６と、通信状態管理処理部１２と、サーバ状態管理処理部１３と、交代パス管理処理部１４と、パス選択学習処理部１５と、通信資源状態管理処理部１７と、通信負荷状態管理処理部１８と、サーバ資源状態管理処理部１９と、サーバ負荷状態管理処理部２０とを有している。
【００２１】
分散機能パス選択管理処理部９は、通信状態及びサーバ状態を示す情報または過去のトランザクション処理時間に応じて分散機能処理パスの選択優先度を設定し、前記設定した選択優先度に従って分散機能処理パスを分散機能クライアントに提示する処理部である。
【００２２】
資源負荷管理処理部２６は、通信資源及びサーバ資源での障害の有無、負荷、稼動状態を管理する処理部である。通信状態管理処理部１２は、通信資源での障害の有無、負荷、稼動状態を監視して通信状態を管理する処理部である。
【００２３】
サーバ状態管理処理部１３は、サーバでの障害の有無、負荷、稼動状態を監視してサーバ状態を管理する処理部である。交代パス管理処理部１４は、通信資源またはサーバの障害が発生した場合に、障害が発生した分散機能処理パスを特定し、前記選択優先度が最も高いパスを交代パスとして設定し、前記障害によりエラーが発生したトランザクションを前記交代パスで再実行する処理部である。
【００２４】
パス選択学習処理部１５は、処理中の処理パス数を処理中のトランザクション量に適した分散機能処理パス数に変更し、各分散機能処理パス毎のトランザクション処理に要した処理時間を示すトランザクション処理時間を記録する処理部である。
【００２５】
通信資源状態管理処理部１７は、分散機能処理パス数や通信エンティティ数等の通信資源の状態を管理する処理部である。通信負荷状態管理処理部１８は、要求されたトランザクション量等の通信負荷を管理する処理部である。
【００２６】
サーバ資源状態管理処理部１９は、処理サーバ数等のサーバ資源の状態を管理する処理部である。サーバ負荷状態管理処理部２０は、サーバで処理したトランザクション量等のサーバ負荷の状態を管理する処理部である。
【００２７】
ＤＢクライアントを分散機能パス選択管理処理部９、資源負荷管理処理部２６、通信状態管理処理部１２、サーバ状態管理処理部１３、交代パス管理処理部１４、パス選択学習処理部１５、通信資源状態管理処理部１７、通信負荷状態管理処理部１８、サーバ資源状態管理処理部１９及びサーバ負荷状態管理処理部２０として機能させる為のプログラムは、ＣＤ−ＲＯＭ等の記録媒体に記録され磁気ディスク等に格納された後、メモリにロードされて実行されるものとする。なお前記プログラムを記録する媒体はＣＤ−ＲＯＭ以外の他の媒体でも良い。
【００２８】
ＤＢサーバは、サーバ状態監視処理部７と、負荷状態監視処理部２１と、稼動状態監視処理部２２と、運用管理処理部２３と、サーバ状態報告処理部２４とを有している。
【００２９】
サーバ状態監視処理部７は、サーバでの障害の有無、負荷、稼動状態を監視する処理部である。負荷状態監視処理部２１は、サーバで処理したトランザクション量を監視する処理部である。稼動状態監視処理部２２は、サーバの稼動状態を監視する処理部である。
【００３０】
運用管理処理部２３は、サーバの運用管理を行う処理部である。サーバ状態報告処理部２４は、サーバ状態監視処理部７により得られたサーバ状態を示す情報をサーバ状態管理処理部１３へ報告する処理部である。
【００３１】
ＤＢサーバをサーバ状態監視処理部７、負荷状態監視処理部２１、稼動状態監視処理部２２、運用管理処理部２３及びサーバ状態報告処理部２４として機能させる為のプログラムは、ＣＤ−ＲＯＭ等の記録媒体に記録され磁気ディスク等に格納された後、メモリにロードされて実行されるものとする。なお前記プログラムを記録する媒体はＣＤ−ＲＯＭ以外の他の媒体でも良い。
【００３２】
次に図２〜図５により通信資源及びサーバ資源管理、分散機能処理パス情報管理の方法について説明する。
【００３３】
図２は本実施形態の通信資源管理データの一例を示す図である。資源管理テーブル２７は通信環境に存在する通信処理装置１０毎の障害情報、稼動情報及び運用情報の設定を管理するテーブルである。障害情報は障害発生の有無を管理する情報であり、稼動情報はシステム起動の有無を管理する情報である。運用情報は通信処理装置１０の運用時間を定義した情報である。
【００３４】
通信資源に関する前記情報取得は、分散機能パス管理処理部４起動時の通信オープン処理時、通信障害発生時及びその回復時、通信負荷増大時、またはシステムに定義された監視時間（Δｔ）毎に行われる。前記情報取得を行う状態となっているかどうかは資源負荷管理処理部２６及び分散機能クライアント３によって監視される。
【００３５】
図３は本実施形態のサーバ資源管理データの一例を示す図である。資源管理テーブル２８は分散機能トランザクション処理を実行する分散機能サーバ６毎の障害情報、稼動情報及び運用情報の設定を管理するテーブルである。障害情報はサーバ障害発生の有無を管理する情報であり、稼動情報はサーバ起動の有無を管理する情報である。運用情報はサーバシステムの運用時間を本システムに定義した情報である。
【００３６】
サーバ資源に関する前記情報取得は、分散機能パス管理処理部４起動時のサーバ状態確認処理時、サーバ起動時のサーバ状態報告受信時、サーバ障害発生及び回復のサーバ状態報告受信時、サーバ処理トランザクション負荷増大時のサーバ状態報告受信時、システムに定義された監視時間（Δｔ）毎のサーバ状態報告受信時に行われる。
【００３７】
前記サーバ状態報告は、システム起動時に確立するクライアント側のサーバ状態管理処理部１３とサーバ側のサーバ状態報告処理部２４間のサーバ状態報告用の通信路及び通信プロトコルを使用し、サーバが前記情報取得の契機を検知してサーバ主導型でクライアントに送信することにより行われる。なお分散機能クライアント３のサーバシステムダウン監視タイマによる契機により行っても良い。
【００３８】
図４は本実施形態の分散機能処理パス情報管理データの一例を示す図である。前記契機で作成した資源管理テーブル２７及び資源管理テーブル２８を基に、同じ契機で分散機能処理パス情報管理テーブル２９を作成する。本テーブルは、分散機能トランザクションを実行する仮想的な資源単位である分散機能処理パス毎に、通信パス、通信経路、処理サーバ、通信利用情報、サーバ利用情報、通信負荷、サーバＣＰＵ負荷、サーバトランザクション負荷及び交代パス使用の有無を管理する。
【００３９】
通信パスは適用する通信エンティティ１１を示す。通信経路は適用する通信装置名を示す。処理サーバは適用する分散機能サーバ６を表している。通信利用情報は通信処理装置１０及び通信機能の稼動可否の情報である。サーバ利用情報はサーバシステムの稼動可否の情報である。通信利用情報またはサーバ利用情報のいづれかが否の場合には当該分散機能処理パスは使用不可となる。
【００４０】
通信負荷は当該通信エンティティを使用して送信要求を行っているトランザクション量を示す。サーバＣＰＵ負荷は当該サーバシステムの当該通信パスの処理におけるＣＰＵ利用率を示す。サーバトランザクション負荷はサーバシステムで分散ＤＢアクセスサーバ処理を実行しているサーバトランザクション量を示す。交代パス使用には交代機能として当該分散機能処理パスを使用しているか否かの情報を設定する。
【００４１】
図５は本実施形態のパス選択情報データの一例を示す図である。資源管理テーブル２７及び資源管理テーブル２８並びに分散機能処理パス情報管理テーブル２９は資源負荷管理処理部２６により管理される。分散機能処理パス情報管理テーブル２９で管理している分散機能処理パスの選択優先度をパス選択テーブル３０により管理しており、分散機能パス選択管理処理部９は、分散機能処理パス選択優先度設定基準に従って前記分散機能処理パス毎に選択優先度を付与する。
【００４２】
図６は本実施形態の分散機能処理パス選択優先度設定基準の一例を示す図である。ここで、分散機能処理パス情報管理テーブル２９、分散機能処理パス選択優先度設定基準５０、パス選択テーブル３０及び分散機能処理パス決定情報テーブル４１を適用した分散機能処理パス選択優先度の設定方法を示す。
【００４３】
分散機能パス選択管理処理部９は、資源負荷管理処理部２６が設定する分散機能処理パス情報管理テーブル２９を特定時間毎に参照して、各分散機能処理パス毎に選択優先度を付与してパス選択テーブル３０を生成する。
【００４４】
選択優先度の付与基準は以下の通りとする。まず［１］では分散機能処理パス情報管理テーブル２９の通信負荷、サーバＣＰＵ負荷及びサーバ負荷（処理トランザクション量）全てが最低である分散機能処理パスに対して選択優先度を設定する。次に［２］では［１］の設定基準で処理パスの選択優先度が設定できない場合（例えば、通信負荷が最低のパスはＰ11、サーバ負荷が最低のパスはＰ12等［１］の基準だけでは選択優先度が設定できない場合）に、図１０の分散機能処理パス決定情報テーブル４１を参照して、負荷が近似のパスの内でトランザクション処理時間が小さいパスから順に選択優先度を設定する。
【００４５】
分散機能処理パス決定情報テーブル４１は、パス選択学習処理部１５によって過去の統計情報としてメモリ上に管理され、システム閉塞時に統計情報格納ファイル１６として保存される。またシステム起動時に過去の定量分のデータが統計情報格納ファイル１６からメモリ上に読み出される。
【００４６】
分散機能パス選択管理処理部９は、分散機能処理トランザクション要求とは非同期に特定時間毎でパス選択テーブル３０にパス選択優先度を設定する。従って、分散機能処理トランザクション要求発生時に分散機能クライアント３は、パス選択テーブル３０に設定されている選択優先度が最高のパスを選択するだけで良く、選択処理のオーバヘッドを削減できる。
【００４７】
図７は本実施形態の分散機能処理パスの概念を示す図である。分散機能トランザクションを実行する仮想的な資源単位である分散機能処理パス（Ｐ11、Ｐ12、Ｐ21、Ｐ22）は、送受信の一単位資源である通信エンティティ１１（ＡＥ）と、通信処理装置１０、分散機能サーバ６の組み合わせにより分散機能パス管理処理部４に定義される。
【００４８】
図８は本実施形態のパス選択学習処理部１５に関連するインタフェースの概略を示す図である。パス選択学習処理部１５は、入出力トランザクション管理部３１、トランザクション負荷管理部３２、負荷分散統計情報データ管理部３３を有し、統計情報格納ファイル１６を用いて処理を行う。
【００４９】
パス選択学習処理部１５は、過去の時間Δｔの平均実行トランザクション量（ＴＲ）・現状の分散機能処理パス数（ＰＮ）・クライアント側の通信エンティティ数（ＣＮ）・処理サーバ数（ＳＶＮ）・算出したΔｔのトランザクション処理時間平均値（Ｔ1ａｖｅ）・算出したΔｔのトランザクションスループット（Ｔ2ａｖｅ）を負荷分散最適化統計情報テーブル（資源数決定情報テーブル４０）としてメモリ管理する。
【００５０】
分散機能クライアント３は現状の入力トランザクション数を把握しており、入出力トランザクション管理部３１は時間Δｔのあるチェックポイントでのトランザクション総数、各トランザクションの入出力時間及び処理時間を管理し、本値からΔｔの平均実行トランザクション量（ＴＲ）値を算出する。
【００５１】
トランザクション負荷管理部３２はΔｔのＴＲ値からＴ1ａｖｅ、Ｔ2ａｖｅを算出する。資源数決定情報テーブル４０を管理する負荷分散統計情報データ管理部３３は、入出力トランザクション管理部３１からＴＲ、トランザクション負荷管理部３２からＴ1ａｖｅ及びＴ2ａｖｅ、通信資源状態管理処理部１７からＰＮ、ＣＮ、サーバ資源状態管理処理部１９からＳＶＮを取得する。
【００５２】
また入出力トランザクション管理部３１は、各トランザクションの入出力時間、各トランザクション処理時間の他に、各トランザクションが使用した分散機能処理パスをメモリ上に管理している。入出力トランザクション管理部３１が管理する前記情報と、分散機能パス選択管理処理部９が管理する分散機能処理パス情報管理テーブル２９の情報により、負荷分散統計情報データ管理部３３は、特定時間毎に分散機能処理パス単位で最近当該パスを使用したトランザクション実行時の通信負荷、サーバＣＰＵ負荷、サーバ負荷（トランザクション量）及び当該トランザクション処理時間を分散機能処理パス決定情報テーブル４１の１エントリとして追加してメモリ上に蓄積・管理する。
【００５３】
負荷分散統計情報データ管理部３３は、システム閉塞時にメモリ上の負荷分散最適化統計情報テーブル（資源数決定情報テーブル４０及び分散機能処理パス決定情報テーブル４１）をファイルに格納し、また、システム起動時に前記負荷分散最適化統計情報テーブルを格納したファイルからシステム定義による設定範囲分のデータをローディングしてメモリに常駐させる。
【００５４】
図９は本実施形態の資源数決定情報の一例を示す図である。資源数決定情報テーブル４０は、過去のある時間Δｔのトランザクション量から現在実行中のトランザクション量に適応する分散機能処理パスの数を算出して現在確立中の分散機能処理パス数を自律的に変動させることを目的として参照・生成される統計情報データを格納しており、システム定義にて設定されるΔｔ毎のＴＲ、ＰＮ、ＣＮ、ＳＶＮ、Ｔ1ａｖｅ、Ｔ2ａｖｅの値を１レコードとして時系列に管理する。
【００５５】
図１０は本実施形態の分散機能処理パス決定情報の一例を示す図である。分散機能処理パス決定情報テーブル４１は、分散機能パス選択管理処理部９が分散機能処理パスの選択優先度をパス選択テーブル３０に設定する際、トランザクション処理時間が最小になる様な分散機能処理パスの選択優先度を上げることを目的として参照される統計情報データを格納している。前記両テーブルはパス選択学習処理部１５により管理される。
【００５６】
次に本実施形態の処理の流れを図により説明する。まず、分散機能パス管理処理部４の開始及び閉塞処理について図１１及び図１２により説明する。
【００５７】
図１１は本実施形態の分散機能パス管理開始処理の処理手順を示すフローチャートである。システム起動時の処理として、ステップ６０１で分散機能パス管理用の資源をイニシャライズし、ステップ６０２でパス選択学習処理部１５により負荷分散最適化統計情報テーブル（資源数決定情報テーブル４０及び分散機能処理パス決定情報テーブル４１）のローディングを行った後、ステップ６０３でサーバ状態報告用通信をサーバ状態管理処理部１３とサーバ状態報告処理部２４間で確立する。
【００５８】
ステップ６０４で分散機能処理パスを１つ以上確保可能かどうかを調べ、起動している分散機能サーバシステムが１つ以上存在する場合にはステップ６０７に進み、未起動サーバが起動時にサーバ状態報告用通信を使用して送信する状態報告データの受信または起動中のサーバが定期的に送信する状態報告データの受信を行う為にサーバ状態報告受信待ちタスクを起動する。ステップ６０４で起動中のサーバが存在しない場合には、ステップ６０５で分散機能処理不可メッセージを出力した後、ステップ６０６で前記サーバ状態報告受信待ちタスクを起動する。
【００５９】
その後ステップ６０８では、起動中のサーバから運用、稼動、障害情報を前記状態報告データにより取得し、ステップ６０９で資源管理テーブル２８及び分散機能処理パス情報管理テーブル２９を作成する。
【００６０】
次にステップ６１０で通信オープン処理を行う。この時、資源管理テーブル２７を生成し、通信障害情報が存在する場合、資源管理テーブル２７に反映する。その後、ステップ６１１で分散機能トランザクションを実行する為の分散機能処理パス及び通信路を確立し、ステップ６１２〜ステップ６１４で資源負荷管理処理部２６、分散機能パス選択管理処理部９及びパス選択学習処理部１５を起動してステップ６１５で開始処理を完了する。
【００６１】
図１２は本実施形態の分散機能パス管理閉塞処理の処理手順を示すフローチャートである。システム閉塞時の処理としては、ステップ６１６で資源負荷管理処理部２６を閉塞した後、ステップ６１７で通信の閉塞処理、ステップ６１８で分散機能パス選択管理処理部９の閉塞処理を行う。その後、ステップ６１９で負荷分散最適化統計情報テーブル（資源数決定情報テーブル４０及び分散機能処理パス決定情報テーブル４１）をファイルに格納した後、ステップ６２０でパス選択学習処理部１５を閉塞してステップ６２１で閉塞処理を完了する。
【００６２】
次にクライアントの分散機能パス管理処理部４起動時のサーバ状態管理処理部１３及びサーバ状態報告処理部２４の処理について図１３〜図１５により説明する。
【００６３】
図１３は本実施形態のサーバ状態管理処理部１３及びサーバ状態報告処理部２４の処理手順を示すフローチャートである。分散機能パス管理処理部４の開始処理で起動された起動時サーバ状態管理処理（ＲＩ）は、ステップ７０１で未起動サーバが存在する場合にステップ７０２に進み、システム環境に定義された全てのサーバからの起動時の状態を報告を受ける受信処理を専用タスクで行う。
【００６４】
ステップ７０３では、サーバから受信した状態報告データの内容により、資源管理テーブル２７及び資源管理テーブル２８、分散機能処理パス情報管理テーブル２９を生成または更新する。
【００６５】
ステップ７０４では、起動を確認したサーバに対して分散機能処理パス及びサーバ状態報告用パスを確立する。特定時間サーバからの受信データがない場合、サーバ未起動と認識して、その旨を資源管理テーブル２７及び資源管理テーブル２８、分散機能処理パス情報管理テーブル２９に反映する。定義された全サーバが起動した時点で起動時サーバ状態管理処理（ＲＩ）を終了する。
【００６６】
分散機能サーバ６の起動時のサーバ状態報告処理部２４の開始処理（ＲＳＶ１）では、まずステップ７０５でサーバ主導でクライアント側のサーバ状態管理処理部１３との間にサーバ状態報告用の通信を確立して、ステップ７０６で分散機能サーバ状態・サーバＣＰＵ負荷・運用情報（サーバシステム定義情報等）を取得し、ステップ７０７でサーバ起動時の状態としてサーバ状態管理処理部１３に報告を行う。
【００６７】
図１４は本実施形態のサーバ主導型サーバ状態管理報告の処理手順を示すフローチャートである。サーバ状態の報告は、サーバ主導型（ＲＳＶ２）とクライアントからの問い合わせ応答型（ＲＳＶ３）の２つの形態がある。サーバ主導型（ＲＳＶ２）の場合、まずステップ７０８で分散機能サーバ６の稼働中に閉塞指示があるかどうかを調べ、閉塞指示がある迄ステップ７０９以下の処理を行う。
【００６８】
サーバシステム定義等で設定されたサーバ状態確認インターバル毎またはサーバ障害発生時にステップ７０９からステップ７１０〜ステップ７１２の処理に進み、サーバ状態をクライアント側に報告する。前記報告の際には、報告する情報として分散機能サーバ状態・サーバＣＰＵ負荷・サーバ分散ＤＢアクセストランザクション負荷・サーバＤＢＭＳ負荷・ＤＢ排他情報をチェックしてサーバ状態報告送信データを作成し、分散機能サーバ６内の資源負荷管理処理部２６が保持する資源管理テーブル２７を参照して最小負荷の通信資源でサーバ状態報告送信処理を行う。
【００６９】
図１５は本実施形態のクライアント主導型サーバ状態管理報告の処理手順を示すフローチャートである。クライアント主導型（ＲＳＶ３）の場合、ステップ７１３で分散機能サーバ６の稼動中に閉塞指示があるかどうかを調べ、閉塞指示がある迄ステップ７１４以下の処理を行う。
【００７０】
ステップ７１４でクライアントのサーバ状態管理処理部１３からのサーバ状態報告問い合わせを受信すると、ステップ７１５〜ステップ７１７で前記サーバ状態（分散機能サーバ状態・サーバＣＰＵ負荷・サーバ分散ＤＢアクセストランザクション負荷・サーバＤＢＭＳ負荷・ＤＢ排他情報）を報告する。
【００７１】
図１６は本実施形態の分散機能パス選択管理処理部９の処理手順を示すフローチャートである。分散機能パス管理処理部４の開始処理に於いて、分散機能パス選択管理処理メイン（Ｍ）は、ステップ８０１及びステップ８０２で分散機能パス選択管理処理部９の資源である分散機能処理パス情報管理テーブル２９及びパス選択テーブル３０を初期設定後、ステップ８０３で分散機能クライアント３からのトランザクション処理要求とは非同期に動作する分散機能パス選択管理処理部９専用のタスク上で、Δｔ毎にパス選択処理（Ｍ１）を起動する。
【００７２】
図１７は本実施形態のパス選択処理の処理手順を示すフローチャートである。起動されたパス選択処理（Ｍ１）は、ステップ８０４でパス選択学習処理部１５が管理する分散機能処理パス決定情報テーブル４１を参照して、分散機能処理パス選択優先度設定基準５０に基づきパス選択テーブル３０に分散機能処理パスの選択優先度を設定する。
【００７３】
図１８は本実施形態のパス提示処理の処理手順を示すフローチャートである。ＵＡＰ１からの分散機能トランザクション要求（分散データベースアクセス要求）がある場合、分散機能クライアント３から、分散機能パス選択管理処理部９がコールされ、ステップ８０５では、前記設定したパス選択テーブル３０を参照して選択優先度が最高のパスを分散機能クライアント３に提示する。分散機能クライアント３は前記提示されたパスを用いてトランザクション要求を行う。
【００７４】
なお本実施形態では、利用可能な資源の範囲でクライアントシステム側のＵＡＰ１と特定サーバシステムのＤＢ２５とを特定の分散機能処理パスでの論理的な括りつけを行うことにより、特定の業務から操作する分散データベースの範囲を固定にした上でその他の分散データベース業務トランザクションの処理負荷を分散させることとしても良い。
【００７５】
次に通信及びサーバ状態（稼動・負荷状態）を管理する資源負荷管理処理部２６の処理について図１９〜図２１により説明する。
【００７６】
図１９は本実施形態の資源負荷管理処理部２６の処理手順を示すフローチャートである。資源負荷管理メイン（Ｒ）は、分散機能パス管理処理部４の開始処理時にタスクとして起動され、ステップ９０１では各種事象を監視し、分散機能クライアント３からの通信障害及びサーバ障害事象を検知した場合、分散機能処理パス情報管理テーブル２９を参照して負荷増大事象を検知した場合、または特定時間が経過した場合にステップ９０２〜ステップ９０４の処理に進み、通信状態管理処理部１２（Ｒ１）、サーバ状態管理処理部１３（Ｒ２）、交代パス管理処理部１４（Ｒ３）を起動する。
【００７７】
図２０は本実施形態の通信状態管理処理の処理手順を示すフローチャートである。前記契機で起動された通信状態管理処理部１２では、次に示す要領で通信障害の有無、通信負荷、通信稼動状態を管理する。通信障害を検知した場合にはステップ９０５で、資源管理テーブル２７及び分散機能処理パス情報管理テーブル２９を更新する。ステップ９０６では分散機能処理パス毎に分散機能処理パス情報管理テーブル２９の通信負荷を更新し、当該通信負荷の値をチェックして分散機能処理パス毎のトランザクション負荷を管理する。ステップ９０７では資源管理テーブル２７の運用情報を基に各通信資源の稼動状態をチェックして資源管理テーブル２７の稼動情報を更新し、その稼動情報の変更に対応する分散機能処理パス情報管理テーブル２９の内容を更新する。
【００７８】
図２１は本実施形態のサーバ状態管理処理の処理手順を示すフローチャートである。前記契機で起動されたサーバ状態管理処理部１３では、次の要領でサーバ障害有無、負荷状態及びサーバ稼動状態を管理する。まずステップ９０８でサーバ状態報告処理部２４からのサーバ状態報告を受信して、ステップ９０９で分散機能クライアント３のサーバシステムダウン検知状況を確認して資源管理テーブル２８に反映する。またステップ９１０では、前記受信したサーバ状態報告の内容からサーバ障害情報及び負荷情報に関して資源管理テーブル２８及び分散機能処理パス情報管理テーブル２９を更新する。ステップ９１１では資源管理テーブル２８の運用情報を基に各サーバの稼動状態をチェックして資源管理テーブル２８の稼動情報を更新し、その稼動情報の変更に対応する分散機能処理パス情報管理テーブル２９の内容を更新する。
【００７９】
図２２は本実施形態の交代パス管理処理の処理手順を示すフローチャートである。交代パス管理処理部１４は、ステップ９１２で通信及びサーバの障害または回復事象発生時に通信状態管理処理部１２及びサーバ状態管理処理部１３から起動され、ステップ９１３で通信資源及びサーバ資源の障害または回復事象が発生した分散機能処理パスを特定する。障害事象の場合にはステップ９１４で分散機能処理パス情報管理テーブル２９を参照して最小負荷のパスを選択して交代パスとして登録し、また障害回復時にはステップ９１４で交代パス登録を抹消する。ステップ９１５ではパス障害によりエラーが発生したトランザクションが存在する場合にＵＡＰ１へエラーリターンさせずに前記交代パスを使用して再実行させる。
【００８０】
交代パスに関しては、予めパス障害時にのみ交代パスとして使用する旨のシステム定義をしておき、障害発生パスが回復しない間は、前記の定義したパスを障害発生パスの代替パスとして使用する方法と、現在使用中のパスの中から負荷の低いパスを交代パスとして設定する方法がある。
【００８１】
トランザクションスループットを下げない為には前者の運用が望ましいが、通信装置毎やサーバシステム毎に交代パスが必要となる為、システム資源の問題で交代パスを余分に設定できない場合には障害が発生したトランザクションを後者の交代パスで処理させることになる。
【００８２】
またステップ９１６で交代パス登録・抹消状況及びエラートランザクション再実行状況をログ及びメッセージ出力することによりエラー発生の状況（頻度・リトライ時間）がトランザクションスループットに与える影響を解析して、システム構築資源のチューニング（通信回線本数等）に利用することができる。
【００８３】
図２３は本実施形態のパス選択学習開始処理の処理手順を示すフローチャートである。まず分散機能パス管理処理部４の開始処理時にパス選択学習開始処理（ＳＩ）がコールされ、ステップ１００１で負荷分散最適化統計情報テーブルの資源数決定情報テーブル４０及び分散機能処理パス決定情報テーブル４１を統計情報格納ファイル１６からローディングする。この時、ステップ１００２でシステム定義によりメモリに常駐化させるテーブルの範囲（ｎ日分、ｍレコード分等）を設定しておき、当該範囲の負荷分散最適化統計情報テーブルデータをメモリに展開する。
【００８４】
図２４は本実施形態のパス選択学習閉塞処理の処理手順を示すフローチャートである。分散機能パス管理処理部４の閉塞処理時にパス選択学習閉塞処理（ＳＴ）がコールされ、ステップ１００３でメモリ上の負荷分散最適化統計情報テーブル（資源数決定情報テーブル４０及び分散機能処理パス決定情報テーブル４１）を統計情報格納ファイル１６に格納する。
【００８５】
図２５は本実施形態のパス選択学習処理の処理手順を示すフローチャートである。パス選択学習処理メイン（Ｓ）は、分散機能パス管理処理部４の開始処理時にタスクとして起動され、ステップ１００４、ステップ１００７、ステップ１０１０で特定時間（Δｔ）の経過が検出される毎に、ステップ１００８でトランザクション統計情報取得処理（Ｓ1）、ステップ１００５で使用資源数最適化処理（Ｓ2）及びステップ１０１１でパス選択優先度情報管理（Ｓ3）を起動する。
【００８６】
前記契機で起動されたトランザクション統計情報取得処理（Ｓ1）、使用資源数最適化処理（Ｓ2）及びパス選択優先度情報管理（Ｓ3）に関して、以下に処理内容を示す。
【００８７】
図２６は本実施形態のトランザクション統計情報取得処理の処理手順を示すフローチャートである。トランザクション統計情報取得処理（Ｓ1）では、ステップ１１０１で分散機能パス選択管理処理部９が一定間隔で出力する当該時点での総トランザクション量の値を蓄積し、過去のΔｔの平均トランザクション数（ＴＲ）を算出する。
【００８８】
またステップ１１０２で通信状態管理処理部１２から通信エンティティ数（ＣＮ）及び分散機能処理パス数（ＰＮ）を取得し、ステップ１１０３でサーバ状態管理処理部１３から現状の処理サーバ数（ＳＶＮ）を取得する。
【００８９】
ステップ１１０４で前記ＴＲからトランザクション平均処理時間（Ｔ1ａｖｅ）及びトランザクションスループット（Ｔ2ａｖｅ）を算出し、ステップ１１０５で前記ＴＲ、ＣＮ、ＰＮ、ＳＶＮ、Ｔ1ａｖｅ、Ｔ2ａｖｅを各項目とする１レコードを作成して、時系列に負荷分散最適化統計情報テーブル（資源数決定情報テーブル４０）に管理する。
【００９０】
図２７は本実施形態の使用資源数最適化処理の処理手順を示すフローチャートである。使用資源数最適化処理（Ｓ2）では、前記Ｓ1の処理と同様にステップ１１０６で過去のΔｔの平均トランザクション数（ＴＲｃ）を算出し、また前記Ｓ1の処理と同様にステップ１１０７で現時点での通信エンティティ数（ＣＮｃ）、分散機能処理パス数（ＰＮｃ）、処理サーバ数（ＳＶＮｃ）を取得する。
【００９１】
ステップ１１０８で負荷分散最適化統計情報テーブル（資源数決定情報テーブル４０）を参照して、ＴＲｃの値から、Ｔ1ａｖｅが最小、Ｔ2ａｖｅが最大になる様なＣＮ及びＰＮの値を決定して、ステップ１１０９で現状のパス数を前記決定値に基づき増減させる。この時、パス数を減少させる場合、仕掛かり中のトランザクション処理の完了を待ち、当該パスを閉塞する。
【００９２】
図２８は本実施形態のパス選択優先度情報管理の処理手順を示すフローチャートである。パス選択優先度情報管理（Ｓ3）では、まずステップ１１１０で入出力トランザクション管理部３１が管理するトランザクション処理時間及びトランザクションが使用したパス情報を入力し、またステップ１１１１で分散機能パス選択管理処理部９が管理するパス情報（分散機能処理パス情報管理テーブル２９の情報）を入力した後、ステップ１１１２で前記入力情報から分散機能処理パス毎に、負荷情報及び最近のトランザクション処理時間の情報を分散機能処理パス決定情報テーブル４１に追加・変更する。本情報を基に分散機能パス選択管理処理部９がパス選択テーブル３０を生成する。
【００９３】
以上説明した様に本実施形態のデータベース負荷分散処理システムによれば、通信状態及びサーバ状態に応じて分散機能処理トランザクション要求を複数の通信資源及びサーバ資源に負荷分散させるので、特定の通信資源やサーバ資源に負荷が集中することによるトランザクションスループットの低下を防止することが可能である。
【００９４】
また本実施形態のデータベース負荷分散処理システムによれば、障害によりエラーが発生したトランザクションを交代パスで再実行するので、障害発生時のリトライ処理に伴うトランザクション実行エラー多発によるトランザクションスループットの低下を防止し、ＵＡＰへのトランザクションリトライ処理の作り込みを不要とすることが可能である。
【００９５】
また本実施形態のデータベース負荷分散処理システムによれば、過去のトランザクション実行状況と通信及びサーバ資源数に関する統計情報を参考にして、現状のトランザクション数に適合した資源数に動的及び自律的に変更するので、分散機能トランザクション実行時の処理パス数の決定を目的とする統計情報の取得・編集・解析というプロセスを省略して資源チューニングの工数を削減することが可能である。
【００９６】
【発明の効果】
本発明によれば通信状態及びサーバ状態に応じて分散機能処理トランザクション要求を複数の通信資源及びサーバ資源に負荷分散させるので、特定の通信資源やサーバ資源に負荷が集中することによるトランザクションスループットの低下を防止することが可能である。
【図面の簡単な説明】
【図１】本実施形態のデータベース負荷分散処理システムの概略構成を示す図である。
【図２】本実施形態の通信資源管理データの一例を示す図である。
【図３】本実施形態のサーバ資源管理データの一例を示す図である。
【図４】本実施形態の分散機能処理パス情報管理データの一例を示す図である。
【図５】本実施形態のパス選択情報データの一例を示す図である。
【図６】本実施形態の分散機能処理パス選択優先度設定基準の一例を示す図である。
【図７】本実施形態の分散機能処理パスの概念を示す図である。
【図８】本実施形態のパス選択学習処理部１５に関連するインタフェースの概略を示す図である。
【図９】本実施形態の資源数決定情報の一例を示す図である。
【図１０】本実施形態の分散機能処理パス決定情報の一例を示す図である。
【図１１】本実施形態の分散機能パス管理開始処理の処理手順を示すフローチャートである。
【図１２】本実施形態の分散機能パス管理閉塞処理の処理手順を示すフローチャートである。
【図１３】本実施形態のサーバ状態管理処理部１３及びサーバ状態報告処理部２４の処理手順を示すフローチャートである。
【図１４】本実施形態のサーバ主導型サーバ状態管理報告の処理手順を示すフローチャートである。
【図１５】本実施形態のクライアント主導型サーバ状態管理報告の処理手順を示すフローチャートである。
【図１６】本実施形態の分散機能パス選択管理処理部９の処理手順を示すフローチャートである。
【図１７】本実施形態のパス選択処理の処理手順を示すフローチャートである。
【図１８】本実施形態のパス提示処理の処理手順を示すフローチャートである。
【図１９】本実施形態の資源負荷管理処理部２６の処理手順を示すフローチャートである。
【図２０】本実施形態の通信状態管理処理の処理手順を示すフローチャートである。
【図２１】本実施形態のサーバ状態管理処理の処理手順を示すフローチャートである。
【図２２】本実施形態の交代パス管理処理の処理手順を示すフローチャートである。
【図２３】本実施形態のパス選択学習開始処理の処理手順を示すフローチャートである。
【図２４】本実施形態のパス選択学習閉塞処理の処理手順を示すフローチャートである。
【図２５】本実施形態のパス選択学習処理の処理手順を示すフローチャートである。
【図２６】本実施形態のトランザクション統計情報取得処理の処理手順を示すフローチャートである。
【図２７】本実施形態の使用資源数最適化処理の処理手順を示すフローチャートである。
【図２８】本実施形態のパス選択優先度情報管理の処理手順を示すフローチャートである。
【符号の説明】
１…ＵＡＰ、２…ＵＡＰスケジュール管理処理部、３…分散機能クライアント、４…分散機能パス管理処理部、５…通信管理処理部、６…分散機能サーバ、８…サーバＤＢＭＳ、１０…通信処理装置、１１…通信エンティティ、１６…統計情報格納ファイル、２５…ＤＢ、９…分散機能パス選択管理処理部、２６…資源負荷管理処理部、１２…通信状態管理処理部、１３…サーバ状態管理処理部、１４…交代パス管理処理部、１５…パス選択学習処理部、１７…通信資源状態管理処理部、１８…通信負荷状態管理処理部、１９…サーバ資源状態管理処理部、２０…サーバ負荷状態管理処理部、７…サーバ状態監視処理部、２１…負荷状態監視処理部、２２…稼動状態監視処理部、２３…運用管理処理部、２４…サーバ状態報告処理部、２７…資源管理テーブル、２８…資源管理テーブル、２９…分散機能処理パス情報管理テーブル、３０…パス選択テーブル、５０…分散機能処理パス選択優先度設定基準、３１…入出力トランザクション管理部、３２…トランザクション負荷管理部、３３…負荷分散統計情報データ管理部、４０…資源数決定情報テーブル、４１…分散機能処理パス決定情報テーブル。
Claims (5)
- 複数のサーバで管理される分散データベースへのアクセスを負荷分散するデータベース負荷分散処理方法において、
通信資源での障害の有無、負荷、稼動状態を監視して通信状態を管理するステップと、サーバでの障害の有無、負荷、稼動状態を監視してサーバ状態を管理するステップと、各分散機能処理パス毎のトランザクション処理に要した処理時間を示すトランザクション処理時間を記録するステップと、前記通信状態及びサーバ状態並びに前記トランザクション処理時間を示す情報に応じて、入力トランザクション処理のバックグラウンドで非同期に分散機能処理パスの選択優先度を設定するステップと、前記設定した選択優先度に従って分散機能処理パスを分散機能クライアントに提示するステップとを有することを特徴とするデータベース負荷分散処理方法。 - 障害が発生した場合に、障害が発生した分散機能処理パスを特定し、前記選択優先度が最も高いパスを交代パスとして設定し、前記障害によりエラーが発生したトランザクションを前記交代パスで再実行するステップを有することを特徴とする請求項１に記載されたデータベース負荷分散処理方法。
- 複数のサーバで管理される分散データベースへのアクセスを負荷分散するデータベース負荷分散処理方法において、
通信資源での障害の有無、負荷、稼動状態を監視して通信状態を管理するステップと、サーバでの障害の有無、負荷、稼動状態を監視してサーバ状態を管理するステップと、分散機能処理パス及び過去時間間隔単位にトランザクション実行時の通信負荷、サーバ負荷及び実行トランザクション処理時間をメモリ上に蓄積管理する負荷分散統計情報管理部が管理する過去の統計情報データを参照して処理中のトランザクション量に適した分散機能処理パス数を算出し、現在確立中の分散機能処理パス数を、前記算出した分散機能処理パス数に変更し、各分散機能処理パス毎のトランザクション処理に要した処理時間を記録するステップと、前記通信状態及びサーバ状態並びに前記トランザクション処理時間を示す情報に応じて分散機能処理パスの選択優先度を設定するステップと、前記設定した選択優先度に従って分散機能処理パスを分散機能クライアントに提示するステップとを有することを特徴とするデータベース負荷分散処理方法。 - 複数のサーバで管理される分散データベースへのアクセスを負荷分散するデータベース負荷分散処理装置において、
通信資源での障害の有無、負荷、稼動状態を監視して通信状態を管理する通信状態管理処理部と、サーバでの障害の有無、負荷、稼動状態を監視してサーバ状態を管理するサーバ状態管理処理部と、各分散機能処理パス毎のトランザクション処理に要した処理時間を示すトランザクション処理時間を記録するパス選択学習処理部と、前記通信状態及びサーバ状態並びに前記トランザクション処理時間を示す情報に応じて、入力トランザクション処理のバックグラウンドで非同期に分散機能処理パスの選択優先度を設定し、前記設定した選択優先度に従って分散機能処理パスを分散機能クライアントに提示する分散機能パス選択管理処理部とを備えることを特徴とするデータベース負荷分散処理装置。 - 複数のサーバで管理される分散データベースへのアクセスを負荷分散するデータベース負荷分散処理装置において、
通信資源での障害の有無、負荷、稼動状態を監視して通信状態を管理する通信状態管理処理部と、サーバでの障害の有無、負荷、稼動状態を監視してサーバ状態を管理するサーバ状態管理処理部と、分散機能処理パス及び過去時間間隔単位にトランザクション実行時の通信負荷、サーバ負荷及び実行トランザクション処理時間をメモリ上に蓄積管理する負荷分散統計情報管理部が管理する過去の統計情報データを参照して処理中のトランザクション量に適した分散機能処理パス数を算出し、現在確立中の分散機能処理パス数を、前記算出した分散機能処理パス数に変更し、各分散機能処理パス毎のトランザクション処理に要した処理時間を示すトランザクション処理時間を記録するパス選択学習処理部と、前記通信状態及びサーバ状態並びに前記トランザクション処理時間を示す情報に応じて分散機能処理パスの選択優先度を設定し、前記設定した選択優先度に従って分散機能処理パスを分散機能クライアントに提示する分散機能パス選択管理処理部とを備えることを特徴とするデータベース負荷分散処理装置。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP00042299A JP4137264B2 (ja) | 1999-01-05 | 1999-01-05 | データベース負荷分散処理方法及びその実施装置 |
| US09/478,202 US6816860B2 (en) | 1999-01-05 | 2000-01-05 | Database load distribution processing method and recording medium storing a database load distribution processing program |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP00042299A JP4137264B2 (ja) | 1999-01-05 | 1999-01-05 | データベース負荷分散処理方法及びその実施装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000200253A JP2000200253A (ja) | 2000-07-18 |
| JP4137264B2 true JP4137264B2 (ja) | 2008-08-20 |
Family
ID=11473376
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP00042299A Expired - Fee Related JP4137264B2 (ja) | 1999-01-05 | 1999-01-05 | データベース負荷分散処理方法及びその実施装置 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6816860B2 (ja) |
| JP (1) | JP4137264B2 (ja) |
Families Citing this family (39)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB0006097D0 (en) * | 2000-03-15 | 2000-05-03 | Pace Micro Tech Plc | Control system for network servers |
| US7089301B1 (en) * | 2000-08-11 | 2006-08-08 | Napster, Inc. | System and method for searching peer-to-peer computer networks by selecting a computer based on at least a number of files shared by the computer |
| KR20020017926A (ko) * | 2000-08-29 | 2002-03-07 | 오명철 | 주변 네트워크 인식 인터넷 컨텐츠 분산 배포 시스템 및그 제어 방법 |
| US20020078075A1 (en) * | 2000-12-15 | 2002-06-20 | Colson James C. | System, method, and program product for prioritizing synchronizable data |
| US7099912B2 (en) * | 2001-04-24 | 2006-08-29 | Hitachi, Ltd. | Integrated service management system |
| JP3945297B2 (ja) * | 2001-04-24 | 2007-07-18 | 株式会社日立製作所 | システム及び管理システム |
| US7085827B2 (en) * | 2001-09-20 | 2006-08-01 | Hitachi, Ltd. | Integrated service management system for remote customer support |
| KR100467397B1 (ko) * | 2001-10-25 | 2005-01-24 | (주)씨디네트웍스 | 콘텐츠 능동적 동기화 시스템 및 이 시스템을 이용한인터넷 콘텐츠 전송 네트웍 서비스 방법 |
| US20030115259A1 (en) * | 2001-12-18 | 2003-06-19 | Nokia Corporation | System and method using legacy servers in reliable server pools |
| JP4039195B2 (ja) * | 2001-12-27 | 2008-01-30 | 富士ゼロックス株式会社 | ネットワークシステム |
| JP3891273B2 (ja) * | 2002-03-05 | 2007-03-14 | 日本電気株式会社 | トランザクション処理の負荷分散方法およびそのシステム |
| KR20030073891A (ko) * | 2002-03-13 | 2003-09-19 | 주식회사 신텔정보통신 | 소비자 참여 방식의 콘텐츠 전송 네트워크 운영시스템 및그 운영방법 |
| KR100457688B1 (ko) * | 2002-08-06 | 2004-11-17 | 에스케이텔레텍주식회사 | 인터넷 콘텐츠 네비게이션 모니터링 단말기 및 모니터링방법 |
| EP1546841A4 (en) * | 2002-08-16 | 2006-03-01 | Nuasis Corp | VOIP SUB-SYSTEM WITH HIGH AVAILABILITY |
| JP2004173136A (ja) * | 2002-11-22 | 2004-06-17 | Fujitsu Ltd | ネットワーク管理装置 |
| US6989509B2 (en) * | 2003-03-17 | 2006-01-24 | Lincoln Global, Inc. | Self-contained integrated welder/generator and compressor |
| WO2004093394A1 (ja) * | 2003-04-14 | 2004-10-28 | Fujitsu Limited | データ中継装置、データ中継方法、データ中継プログラム、サービス選択装置、サービス選択方法、及びサービス選択プログラム |
| US20050169254A1 (en) * | 2003-04-14 | 2005-08-04 | Fujitsu Limited | Data relay apparatus, data relay method, data relay program, service selection apparatus, service selection method and service selection program |
| US6992265B2 (en) * | 2004-01-15 | 2006-01-31 | Lincoln Global, Inc. | Integrated engine welder and electric compressor |
| US8080761B2 (en) * | 2004-08-17 | 2011-12-20 | Lincoln Global, Inc. | Hybrid powered welder |
| US7921407B2 (en) * | 2004-08-10 | 2011-04-05 | Oracle America, Inc. | System and method for supporting multiple alternative methods for executing transactions |
| CN101346696B (zh) * | 2005-12-28 | 2013-10-02 | 国际商业机器公司 | 负荷分散型客户机服务器系统及负荷分散方法 |
| US8849746B2 (en) * | 2006-12-19 | 2014-09-30 | Teradata Us, Inc. | High-throughput extract-transform-load (ETL) of program events for subsequent analysis |
| US8296385B2 (en) * | 2007-04-23 | 2012-10-23 | Lenovo (Singapore) Pte. Ltd. | Apparatus and method for selective engagement in software distribution |
| US20090019103A1 (en) * | 2007-07-11 | 2009-01-15 | James Joseph Tommaney | Method and system for processing a database query |
| US7966363B2 (en) * | 2007-09-28 | 2011-06-21 | Hewlett-Packard Development Company, L.P. | Method and system for visualizing distributed systems |
| US8856196B2 (en) * | 2008-07-22 | 2014-10-07 | Toyota Jidosha Kabushiki Kaisha | System and method for transferring tasks in a multi-core processor based on trial execution and core node |
| US8316045B1 (en) * | 2009-02-10 | 2012-11-20 | Sprint Communications Company L.P. | Database linking system |
| JP5360978B2 (ja) * | 2009-05-22 | 2013-12-04 | 株式会社日立製作所 | ファイルサーバ、及びファイルサーバにおけるファイル操作通知方法 |
| US20110113409A1 (en) * | 2009-11-10 | 2011-05-12 | Rodrick Evans | Symbol capabilities support within elf |
| JP5515157B2 (ja) | 2010-06-01 | 2014-06-11 | 株式会社日立製作所 | Ｉ／ｏデバイス管理方法、及び計算機システム |
| US8693981B1 (en) | 2011-06-17 | 2014-04-08 | Cellco Partnership | Monitoring persistent client connection status in a distributed server environment |
| CN103731335B (zh) * | 2012-10-11 | 2017-10-24 | 腾讯科技（深圳）有限公司 | 共同消息发送方法及装置 |
| US9384227B1 (en) * | 2013-06-04 | 2016-07-05 | Amazon Technologies, Inc. | Database system providing skew metrics across a key space |
| US10514857B2 (en) | 2013-08-29 | 2019-12-24 | Pure Storage, Inc. | Dynamic adjusting of parameters based on resource scoring |
| US10686880B2 (en) * | 2013-08-29 | 2020-06-16 | Pure Storage, Inc. | Dispersed storage based on range availability and methods for use therewith |
| AU2016292783B2 (en) * | 2015-07-10 | 2019-05-30 | Ab Initio Technology Llc | Method and architecture for providing database access control in a network with a distributed database system |
| US20190020559A1 (en) * | 2017-07-17 | 2019-01-17 | Nicira, Inc. | Distributed health check in virtualized computing environments |
| CN112162846B (zh) | 2020-11-27 | 2021-04-09 | 腾讯科技（深圳）有限公司 | 事务处理方法、设备及计算机可读存储介质 |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4897781A (en) * | 1987-02-13 | 1990-01-30 | International Business Machines Corporation | System and method for using cached data at a local node after re-opening a file at a remote node in a distributed networking environment |
| US6185601B1 (en) * | 1996-08-02 | 2001-02-06 | Hewlett-Packard Company | Dynamic load balancing of a network of client and server computers |
| US6012052A (en) * | 1998-01-15 | 2000-01-04 | Microsoft Corporation | Methods and apparatus for building resource transition probability models for use in pre-fetching resources, editing resource link topology, building resource link topology templates, and collaborative filtering |
-
1999
- 1999-01-05 JP JP00042299A patent/JP4137264B2/ja not_active Expired - Fee Related
-
2000
- 2000-01-05 US US09/478,202 patent/US6816860B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US20030097370A1 (en) | 2003-05-22 |
| US6816860B2 (en) | 2004-11-09 |
| JP2000200253A (ja) | 2000-07-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4137264B2 (ja) | データベース負荷分散処理方法及びその実施装置 | |
| US9723097B2 (en) | Assigning shared catalogs to cache structures in a cluster computing system | |
| JP4321705B2 (ja) | スナップショットの取得を制御するための装置及び記憶システム | |
| US11016956B2 (en) | Database management system with database hibernation and bursting | |
| US7047360B2 (en) | Method and apparatus for adjusting performance of logical volume copy destination | |
| US8707386B2 (en) | Policy processing system, method, and program | |
| US8856793B2 (en) | System, method and program for scheduling computer program jobs | |
| US7937437B2 (en) | Method and apparatus for processing a request using proxy servers | |
| US7543174B1 (en) | Providing high availability for an application by rapidly provisioning a node and failing over to the node | |
| US7328213B2 (en) | Transaction processing method, transaction control apparatus and program thereof | |
| US20040226013A1 (en) | Managing tasks in a data processing environment | |
| US20080288812A1 (en) | Cluster system and an error recovery method thereof | |
| US9606880B2 (en) | Information processing apparatus, information processing system, and control method therefor | |
| US6269410B1 (en) | Method and apparatus for using system traces to characterize workloads in a data storage system | |
| JP2007102452A (ja) | システム管理プログラムおよびシステム管理方法 | |
| US8769223B2 (en) | System and method for setting an activation state for a device used in a backup operation | |
| WO2009068642A1 (en) | Method for using dynamically scheduled synthetic transactions to monitor performance and availability of e-business systems | |
| US6947957B1 (en) | Proactive clustered database management | |
| US20050198298A1 (en) | System monitoring method | |
| US11934665B2 (en) | Systems and methods for ephemeral storage snapshotting | |
| CN115470059A (zh) | 一种磁盘检测方法、装置、设备及存储介质 | |
| US6266697B1 (en) | System automatically maintaining client under control of client, and a recording medium therefor | |
| US7542998B1 (en) | Cause to effect methodology for monitoring database performance | |
| JP4099115B2 (ja) | ジョブ実行システム及び実行制御方法 | |
| US20060078006A1 (en) | Data transmission process |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050405 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050603 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20050628 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050826 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20050912 |
|
| A912 | Re-examination (zenchi) completed and case transferred to appeal board |
Free format text: JAPANESE INTERMEDIATE CODE: A912 Effective date: 20060120 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080507 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080604 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110613 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110613 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120613 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120613 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130613 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |