JP5055059B2 - データベース処理方法、その実施システム及びプログラム - Google Patents

Description

本発明はデータベースに対するロック形式の選択やリクエストのキュー制御を行うデータベース処理技術に関するものである。

従来技術では、アプリケーションがＪＤＢＣ（Ｊａｖａ Ｄａｔａｂａｓｅ Ｃｏｎｎｅｃｔｉｖｉｔｙ）等のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を直接使用しデータベースを操作する場合は、ＳＱＬ文をユーザが直接ソースコードに記述する方法が主であり、そのためＳＱＬ文が各ソースに散在してしまい、管理が煩雑になる。また、データベースに対するロック形式もユーザが手動でテーブル毎に設定する必要がある。

一方、登場したＯｂｊｅｃｔ／Ｒｅｌａｔｉｏｎａｌマッピング（以下、Ｏ／Ｒマッピング）は、オブジェクトとリレーショナルデータベースのテーブルのレコードのマッピングを行うフレームワークであり、レコード単位の排他制御はＯ／Ｒマッピングフレームワーク若しくはＤａｔａＢａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ（以下、ＤＢＭＳ）が管理する。一般的に排他制御を行う方式には、Ｐｅｓｓｉｍｉｓｔｉｃ方式とＯｐｔｉｍｉｓｔｉｃ方式の２つがあり、ユーザはオブジェクト毎にどちらの方式かを指定する。

Ｐｅｓｓｉｍｉｓｔｉｃ方式は、最初にデータを読み取る時からロックをかけるため、更新処理は必ず成功する。その代わり、ロックの取得時間が長いため、同じレコードにアクセスするトランザクションが存在する場合、ロックの競合が発生して、同時実行性が低下する可能性がある。

共有ロックを取得するＯｐｔｉｍｉｓｔｉｃの特徴は、排他の範囲が狭いため、ロックの競合が発生する可能性が低く、同時実行性に優れている。但し、同じデータを変更する複数のトランザクションが存在する場合は、更新に失敗する可能性が高くなる。

リレーショナルデータベースのレコードとオブジェクトをマッピングするＯ／Ｒマッピングは、レコードをオブジェクトとして扱い、データベースのレコードを意識することなく扱える様にする。ユーザがデータベースのレコードを操作するには、Ｏ／Ｒマッピングフレームワークが提供するＡＰＩを使用してオブジェクトを操作することでデータベースのレコードを操作する。

特開２００６−９２３５８号公報

ユーザはアプリケーションの特徴やシステム構成、性能要件に応じて、Ｏ／Ｒマッピングフレームワークに対して手動でロック方式を設定しなければならないため、手間がかかる。

本発明の目的は、適切なロック形式を導き出して、動的に適切なロック形式をＯ／Ｒマッピングフレームワークに対して設定することであり、状況（アクセスの傾向、負荷）に応じてロック形式を動的に選択することである。

また、動的に適切なロック方式を選択したとしても、同一データに対するアクセスが多く、ロックの衝突率が改善されない場合は、ロックを取得できない他のトランザクションによるロック待ちが頻繁に発生すると、リソースを有効に使えず、システム全体のパフォーマンスが低下する。

本発明の目的では、ロック方式の変更だけでなく、同一データにアクセスするリクエストの流動制御（同時実行数の変更）を行うことにより、システム全体のパフォーマンスを向上させることが可能である。

本発明は、データベースに対するロック形式を選択してデータベース処理を管理する計算機システムにおいて、トレースログとマッピングテーブルを解析してオブジェクトのロック形式を判定しロック形式の設定を行うものである。

上記目的を達成する為に、本発明の計算機システムでは、障害解析で用いるトレースログとマッピングテーブルを解析することによってオペレーション対応テーブル及びオブジェクト管理テーブルを作成する。そして、そのトレースログとマッピングテーブルの解析結果であるオペレーション対応テーブル及びオブジェクト管理テーブルから随時適切なロック形式を判定し、動的にロック形式の変更を行う。更に本発明の管理サーバは、オペレーション対応テーブル及びオブジェクト管理テーブルからキューの同時実行数の制御を行い、スケジューラが効率的にリクエストをキューに割り振ることにより、ロックの競合率を抑える処理を行う。

本発明では、主に障害解析で用いているトレースを分析することによって、データベースに対する排他制御の適切なロック形式を自動的に判定することができる。
また、管理サーバが自動的に適切なロック形式をデータベースに対して設定することにより、ユーザはデータベースに対する設定作業を軽減することができる。
更に、ロック形式を変更するだけでなく、同一データにアクセスするリクエストの流動制御を行うことで、アプリケーションサーバに効率的にリクエストを割り振り、システム全体のパフォーマンスを向上させることができる。

以下にデータベースに対するロック形式を選択してデータベース処理を管理する一実施形態の計算機システムについて説明する。

図１は本実施形態の複数のプログラム実行装置（アプリケーションサーバ）を管理する計算機システムの構成を示す図である。図１の基本構成の概略図に示す様に、ロードバランサ１０１は、リクエストを受信するとロードバランサの規則に従い受信したリクエストをスケジューラ１０２に割り振る。リクエストがロードバランサ１０１によりスケジューラ１０２に割り振られた場合、スケジューラ１０２は、リクエストをどのキューに割り当てるか判定するため、キューテーブル１０４を参照して、リクエストをキュー１０３に格納する。

キュー１０３に格納されているリクエストが存在する場合、コンテナ１２６はリクエストをキュー１０３から取り出して処理を開始する。コンテナ１２６は、リクエストの処理に応じてトレースを取得するタイミングになった場合、トレーサ１１４を使用してトレースログ１１５を取得する。そしてコンテナ１２６は、リクエストをアプリケーション１０６に渡す。

アプリケーション１０６はユーザオブジェクト１０７を操作し、ユーザオブジェクト１０７は、アプリケーション１０６からユーザオブジェクト１０７に対して行われた操作をＯ／Ｒマッピングフレームワーク１０８に通知する。

Ｏ／Ｒマッピングフレームワーク１０８は、マッピングテーブル１１１を参照して操作されたユーザオブジェクト１０７のロック形式を取得する。そしてＯ／Ｒマッピングフレームワーク１０８は、ロック形式に従った操作を参照部１０９、更新部１１０に対して行う。

すなわち、データベースサーバ１１３のデータを参照する場合、Ｏ／Ｒマッピングフレームワーク１０８の参照部１０９は、データベースアクセス部１１２に対してデータを参照する命令を出す。データベースアクセス部１１２では、実際にデータベースサーバ１１３のテーブル１２４の操作を行う為に、データベースサーバ１１３に対して、データベース用の命令を送信する。データベースサーバ１１３は、受信した命令をＤＢＭＳ１２５が解釈して、テーブル１２４に対して処理を行い、結果を返す。

また、データベースサーバ１１３のデータを更新する場合には、Ｏ／Ｒマッピングフレームワーク１０８の更新部１１０が、データベースアクセス部１１２に対してデータを更新する命令を出す。データベースアクセス部１１２はデータベースサーバ１１３のテーブル１２４を更新する。

Ｏ／Ｒマッピングフレームワーク１０８は、データベースの参照後若しくは更新後、結果をユーザオブジェクト１０７に対して設定する。更新処理を実行した場合、Ｏ／Ｒマッピングフレームワーク１０８はユーザオブジェクト１０７を更新する。

そしてアプリケーション１０６はユーザオブジェクト１０７の結果を参照し、アプリケーション１０６はコンテナ１２６に結果を返す。またコンテナ１２６は、結果をリクエストの送信元に返す。

管理装置である管理サーバ１００の解析部１１６は、マッピングテーブル１１１とトレースログ１１５を解析して、オペレーション対応テーブル１２３、オブジェクト管理テーブル１２２を作成する。

また管理サーバ１００の判定部１１７は、ロック判定部１１８とキュー判定部１１９から構成される。ロック判定部１１８では、オペレーション対応テーブル１２３、オブジェクト管理テーブル１２２から、ユーザオブジェクト１０７に対して設定する適切なロック形式を判定する。キュー判定部１１９では、オペレーション対応テーブル１２３、オブジェクト管理テーブル１２２から、キューの同時実行数の設定を判定する。

管理サーバ１００の設定部１２０は、サーバテーブル１２１を参照して、設定を行うスケジューラ１０２を決定して、ロック判定部１１８が判定した適切なロック形式をＯ／Ｒマッピングフレームワーク１０８に対して設定し、また、キュー判定部１１９が判定した適切な同時実行数をスケジューラ１０２に対して設定する。

またスケジューラ１５２は、スケジューラ１０２と同等の機能を有する。キュー１５３は、キュー１０３と同等の機能を有する。キューテーブル１５４は、キューテーブル１０４と同等の機能を有する。コンテナ１７６は、コンテナ１２６と同等の機能を有する。アプリケーション１５６は、アプリケーション１０６と同等の機能を有する。ユーザオブジェクト１５７は、ユーザオブジェクト１０７と同等の機能を有する。マッピングテーブル１６１は、マッピングテーブル１１１と同等の機能を有する。Ｏ／Ｒマッピングフレームワーク１５８は、Ｏ／Ｒマッピングフレームワーク１０８と同等の機能を有し、参照部１５９と更新部１６０から構成され、それぞれは参照部１０９と更新部１１０と同等の機能を有する。トレーサ１６４は、トレーサ１１４と同等の機能を有し、トレースログ１６５はトレーサ１６４により出力されるログである。
以下に、図１における各部の説明を行う。

図５は本実施形態のＰｅｓｓｉｍｉｓｔｉｃ／Ｏｐｔｉｍｉｓｔｉｃのリクエストの処理の流れを示す図である。本実施形態のＰｅｓｓｉｍｉｓｔｉｃ／Ｏｐｔｉｍｉｓｔｉｃのリクエストの処理の流れをシーケンスを用いて説明する。

ＡＰ層１１２０は、図１のコンテナ１２６及びアプリケーション１０６を指す。ＯＲ層１１２１は、図１のユーザオブジェクト１０７、Ｏ／Ｒマッピングフレームワーク１０８を指す。ＤＢ層１１２２は、図１のデータベースサーバ１１３及びＤＢＭＳ１２５、テーブル１２４を指す。

ＡＰ層１１２０がリクエスト１１００を受け取ると、ＡＰ層１１２０は、リクエスト１１００の処理を開始することを示すリクエスト開始ポイント１１０１のトレースログを出力する。

リクエスト１１００がＡＰ層からＯＲ層１１２１に渡され、ＯＲ層からＤＢ層にデータの参照を行う場合、ＯＲ層はＤＢ層の参照を開始することを示す参照開始ポイント１１０２のトレースログを出力する。また、ＯＲ層はＤＢ層の参照が完了すると、参照を完了したことを示す参照完了ポイント１１０３のトレースログを出力する。

ＯＲ層からＤＢ層にデータの更新を行う場合、ＯＲ層はＤＢ層の更新を開始することを示す更新開始ポイント１１０４のトレースログを出力する。また、ＯＲ層はＤＢ層の更新が完了すると、更新を完了したことを示す更新完了ポイント１１０５のトレースログを出力する。リクエスト１１００の処理が完了するとＡＰ層は、処理が完了したことを示すリクエスト完了ポイント１１０６のトレースログを出力する。

ＯＲ層１１２１がＤＢ層１１２２を参照している時間つまり参照時間１１０７は、参照開始ポイント１１０２が取得された時間から参照完了ポイント１１０３が取得された時間の差分と定義する。ＯＲ層１１２１の参照が完了して次の更新を行うまでの時間つまり中間時間１１０８を参照完了ポイント１１０３が取得された時間から更新開始ポイントが取得された時間の差分と定義する。ＯＲ層１１２１がＤＢ層１１２２を更新している時間つまり更新時間１１０９は、更新開始ポイント１１０４で取得された時間から更新完了ポイント１１０５が取得された時間の差分と定義する。待ち時間１１１１は、参照時間１１０７と中間時間１１０８と更新時間１１０９の和と定義する。処理時間１１１０は、ＡＰ層でのリクエスト開始ポイント１１０１を取得した時間とリクエスト完了ポイント１１０６を取得した時間の差分と定義する。処理時間１１１０の構成要素には、参照時間１１０７、中間時間１１０８、更新時間１１０９が含まれる。

図６は本実施形態のＰｅｓｓｉｍｉｓｔｉｃロック形式の動作例を示す図である。リクエストＡ１２００、リクエストＢ１２１０、リクエストＣ１２２０は、それぞれ同時期に同一のデータにアクセスが発生した例を示しており、処理の実行順序は、リクエストＡ１２００、リクエストＢ１２１０、リクエストＣ１２２０の順とする。

Ｐｅｓｓｉｍｉｓｔｉｃのロック形式の特徴は、リクエストのデータベースの操作開始から完了までロックを取得することである。つまり、リクエストＡ１２００において、データベースアクセス時には、参照開始ポイント１２０２から更新完了ポイント１２０５までの間、ロックを取得する。この時、リクエストＢ１２１０では、同時期に参照開始ポイント１２１２で、ロックを取得しようとしているが、リクエストＢ１２１０より先にリクエストＡ１２００がロックを取得したため、実際に参照が完了する時点つまり参照完了ポイント１２１３までの間に、リクエストＡ１２００のロック時間１２３０つまり参照開始ポイント１２０２から更新完了ポイント１２０５までの時間分、ロックの取得を待たされる。

また、リクエストＣ１２２０については、リクエストＡ１２００、リクエストＢ１２１０のロックが解除されるまで、つまりリクエストＡのロック時間１２３０とリクエストＢ１２１０のロック時間の和の時間分、ロックの取得を待たされる。以降のリクエストについても、同様にロックが競合した場合、ロックの取得を待たされる。

ロック時間１２３０は、データベースにアクセスを開始した参照開始ポイント１２０２から更新が完了する更新完了ポイント１２０５の差分となる。ロックの衝突が発生した場合、ここではリクエストＢにおいて、ロック時間とは、参照開始ポイント１２１２と更新完了ポイント１２１５の差分からリクエストＡのロック時間１２３０の差分となる。ロック待ち時間１２４０は、ロックの競合が発生して、他のリクエストによってロックの取得を待たされる時間とする。リクエストＢにおいて、ロックの待ち時間は、リクエストＡのロック時間に相当する。リクエストＣにおいて、ロックの待ち時間は、リクエストＡのロック時間とリクエストＢのロック時間の和に相当する。

図７は本実施形態のＯｐｔｉｍｉｓｔｉｃロック形式の動作例を示す図である。リクエストＡ１３００、リクエストＢ１３１０は、それぞれ同時期に同一のデータにアクセスが発生した場合を示しており、処理の実行順序は、リクエストＡ１３００、リクエストＢ１３１０の順とする。

Ｏｐｔｉｍｉｓｔｉｃのロック形式の特徴は、データ参照時に共有ロックを取得して、実際にデータ更新時に、他のリクエストが共有ロックを取得していないか判断して、他のリクエストが共有ロックを取得している場合は、データの更新に失敗することである。失敗したリクエストにおいて、処理をデータ参照時から再びリトライさせる。

リクエストＡ１３００は参照開始ポイント１３０２で、リクエストＢ１３１０より先に共有ロックを取得する。リクエストＢ１３１０は、その後に、参照開始ポイント１３１２で共有ロックを取得する。リクエストＡ１３００は、ほかのリクエストＢが共有ロックを取得しているため、データの更新に失敗し、共有ロックを解放する。この時、ＡＰ層は更新エラーポイント１３０４をトレースログに出力して、再度データ参照からつまり共有ロックの取得からリトライする。

リクエストＡ１３００が共有ロックを解放すると、リクエストＢ１３１０は他のリクエストで共有ロックを保持しているリクエストが存在しないため、実際にデータの更新を行い、処理を完了する。再度データ参照からリトライしているリクエストＡ１３００は、リクエストＢがロックを解放する更新完了ポイント１３１５の後に、共有ロックを取得でき、処理を完了することができる。

この時、リクエストＡ１３００の更新エラーポイント１３０４から更新が成功する時に取得した共有ロック取得時間つまり参照開始ポイント１３０５の差分の時間が、最長リトライ時間と定義する。リトライなし時間は、リトライ処理を行わずにリクエストの処理を完了した処理時間と定義する。つまり、リトライなし時間の定義は、処理時間１３１６と浪費時間１３１７の差分とする。浪費時間１３１７の定義は、共有ロックを取得してからロックの衝突が発生して、ロックの再取得を含めて、ロックの取得が無駄になった時間とする。

図８は本実施形態の解析部１１６／判定部１１７／設定部１２０の処理概要のフロー例を示す図である。図８に示す様に管理サーバ１００は、サーバテーブル１２１を参照して、全てのアプリケーションサーバについて、次の解析部１１６、判定部１１７、設定部１２０の処理を実行する（１４００）。

まず解析部１１６は、トレースログ１１５とマッピングテーブル１１１を解析して、オペレーション対応テーブル１２３とオブジェクト管理テーブル１２２を作成する（１４０１）。

判定部１１７を構成するロック判定部１１８は、オペレーション対応テーブル１２３とオブジェクト管理テーブル１２２を参照してオブジェクトの適切なロック形式を判定する（１４０２）。
判定部１１７を構成するキュー判定部１１９は、オペレーション対応テーブル１２３とオブジェクト管理テーブル１２２とキューテーブル１０４を参照して、キューのリクエスト処理の同時実行数の増減を判定する（１４０３）。

そして設定部１２０は、ロック判定部１１８が判定したロック形式をＯ／Ｒマッピングフレームワーク１０８に対して設定し、キュー判定部１１９が判定したキューのリクエスト処理の同時実行数の増減についてスケジューラ１０２に対して設定する（１４０４）。その後、解析部１１６の処理１４０１に戻る。
ロック判定部１１８の詳細なフローは図９、キュー判定部の詳細なフローは図１０を用いて説明する。

図９は本実施形態のロック判定部１１８のフロー例を示す図である。図９に示す様にロック判定部１１８は、オブジェクトのロック形式がＰｅｓｓｉｍｉｓｔｉｃかどうか判定する（３０２）。

オブジェクトのロック形式がＰｅｓｓｉｍｉｓｔｉｃの場合は、（平均処理時間−平均待ち時間）×（１−衝突率）＋（平均処理時間−平均待ち時間＋平均参照時間＋平均中間時間＋リトライ待ち時間）×衝突率で求められる値とＰｅｓｓｉｍｉｓｔｉｃの平均処理時間の値を比較する（３０３）。

この式の考え方は、ロック形式がＰｅｓｓｉｍｉｓｔｉｃの場合、Ｏｐｔｉｍｉｓｔｉｃでの処理時間を予測することである。ロックの衝突が発生しない場合のＯｐｔｉｍｉｓｔｉｃの処理時間は、待ち時間は発生しないため、（平均処理時間−平均待ち時間）と予測する。また、ロックの衝突が発生した場合のＯｐｔｉｍｉｓｔｉｃの処理時間は、待ち時間は発生せず、ロックの衝突により無駄になった処理及びロック再取得処理があるため、（平均処理時間−平均待ち時間＋平均参照時間＋平均中間時間＋リトライ待ち時間）と予測する。

前記比較の結果、Ｐｅｓｓｉｍｉｓｔｉｃの平均処理時間が大きい場合、ロック判定部１１８はオブジェクトのロック形式をＯｐｔｉｍｉｓｔｉｃに変更する様にＯ／Ｒマッピングフレームワークに命令することをメモリに保持しておく（３０４）。またＰｅｓｓｉｍｉｓｔｉｃの平均処理時間が等しいか小さい場合は、判定処理を終了する。

一方、オブジェクトのロック形式がＰｅｓｓｉｍｉｓｔｉｃではない場合、リトライなし平均処理時間＋（平均参照時間＋平均中間時間＋平均更新時間）×衝突率＋リトライなし平均処理時間×（１−衝突率）よりＯｐｔｉｍｉｓｔｉｃの平均処理時間が大きいか判定する（３０６）。

Ｏｐｔｉｍｉｓｔｉｃの平均処理時間が大きい場合、ロック判定部１１８は、オブジェクトのロック形式をＰｅｓｓｉｍｉｓｔｉｃに変更する様に、Ｏ／Ｒマッピングフレームワークに命令することをメモリに保持しておく（３０７）。またＯｐｔｉｍｉｓｔｉｃの平均処理時間が等しいか小さい場合、判定処理を終了する。

この処理では、ロック形式がＯｐｔｉｍｉｓｔｉｃの場合、Ｐｅｓｓｉｍｉｓｔｉｃでの処理時間を予測している。すなわち、ロックの衝突が発生しない場合のＰｅｓｓｉｍｉｓｔｉｃの処理時間は、ロックによる待ち時間が発生しないため、リトライなし平均処理時間と予測し、ロックの衝突が発生した場合の処理時間は、ロックによる待ち時間を（平均参照時間＋平均中間時間＋平均更新時間）と想定して、リトライなし平均処理時間＋（平均参照時間＋平均中間時間＋平均更新時間）と予測する。

図１０は本実施形態のキュー判定部１１９のフロー例を示す図である。図１０に示す様にキュー判定部１１９は、まずユーザがスケジューラのキューテーブルに対して設定した閾値を読み込む（４０１）。そして、オブジェクトのロック形式がＰｅｓｓｉｍｉｓｔｉｃかどうかの判定する（４０２）。

オブジェクトのロック形式がＰｅｓｓｉｍｉｓｔｉｃの場合、平均処理時間より閾値が大きいかを判定する（４０３）。平均処理時間より閾値が大きい場合、キュー判定部１１９は、スケジューラに対してキューの同時実行数を増やす命令を出すことをメモリに保持しておく（４０４）。

また、平均処理時間より閾値が同じか小さい場合、閾値がリトライなし平均処理時間より大きく、かつ平均処理時間より小さいか判定する（４０６）。判定の理由は、キューを絞ることで、ロックの衝突が減少して、平均処理時間が短縮され、リトライなし時間に近づけることができると予測するためである。

閾値がリトライなし平均処理時間より大きく、かつ平均処理時間より小さい場合、キュー判定部１１９は、スケジューラに対してキューの同時実行数を減らす命令を出すことをメモリに保持しておく（４０７）。そして、閾値がリトライなし平均処理時間以下、または平均処理時間以上の場合、判定処理を終了する。

一方、オブジェクトのロック形式がＰｅｓｓｉｍｉｓｔｉｃでない場合、平均処理時間より閾値が大きいか判定する（４０８）。平均処理時間より閾値が大きい場合、キュー判定部１１９は、スケジューラに対してキューの同時実行数を増やす命令を出すことをメモリに保持しておく（４０９）。

また、平均処理時間より閾値が等しいか小さい場合、閾値が、平均処理時間−平均待ち時間より大きくかつ平均処理時間より小さいかどうか判定する（４１０）。判定の理由は、キューを絞ることで、ロックの衝突が減少して、平均処理時間が短縮され、待ち時間なしの平均処理時間に近づけることができると予測するためである。

閾値が、平均処理時間−平均待ち時間より大きくかつ平均処理時間より小さい場合、キュー判定部１１９は、スケジューラに対してキューの同時実行数を減らす命令を出すことをメモリに保持しておく（４１１）。そして、閾値が、平均処理時間−平均待ち時間より大きくかつ平均処理時間より小さいことを満たさない場合、判定処理を終了する。

図１１は本実施形態のリクエストフローの例を示す図である。図１１に示す様にロードバランサ１０１がリクエストを受信すると（５０１）、ロードバランサ１０１は、ロードバランサ自身のルールに従い、リクエストをスケジューラに割り振る（５０２）。

スケジューラは、リクエストに操作するユーザオブジェクトを特定できる情報がある場合、キューテーブルを参照して、リクエストのオペレーションに対応するキューにリクエストをキューイングし、そうでない場合はキューイングルールに従いキューにリクエストをキューイングする（５０３）。

キューにリクエストをキューイングしたとき、キューの最大同時実行数が現在の同時実行数より小さいか判定する（５０４）。キューの現在の同時実行数が最大同時実行数以上の場合、スケジューラは、キューが同時に実行しているリクエストのいずれか１つが完了するまで新しいリクエストの処理を待機させる（５０５）。キューの現在の同時実行数が最大同時実行数より小さい場合、スケジューラは、キューにリクエストをキューイングして、キューの現在の同時実行数の値を１つ増やす（５０６）。

コンテナは、キューからリクエストを取り出し（５０７）、コンテナは、トレーサを使用して、リクエストの開始処理を示すトレースログを取得する（５０８）。そしてコンテナは、取り出したリクエストの処理をアプリケーションに渡す（５０９）。

アプリケーションは、ユーザオブジェクトに対してメソッド呼び出しを行う（５１０）。Ｏ／Ｒマッピングフレームワークは、マッピングテーブルを参照して、ユーザオブジェクトにマッピングされているデータベースサーバのテーブルを知る（５１１）。

コンテナは、トレースを利用してテーブル参照開始を示すトレースログを取得する（５１２）。Ｏ／Ｒマッピングフレームワークは、参照部を使用して、データベースアクセス部を介して、データベースサーバのテーブルを参照する（５１３）。コンテナは、トレースを利用して、テーブル参照完了を示すトレースログを取得する（５１５）。

コンテナは、トレースを利用してテーブル更新開始を示すトレースログを取得する（５１５）。Ｏ／Ｒマッピングフレームワークは、更新部を利用して、データベースアクセス部を介して、データベースサーバのテーブルを更新する（５１６）。コンテナは、トレースを利用してテーブル更新完了を示すトレースログを取得する（５１７）。Ｏ／Ｒマッピングフレームワークは、結果をユーザオブジェクトに対して設定する（５１８）。

ユーザオブジェクトは結果をアプリケーションに返す（５１９）。アプリケーションは結果をコンテナに返す（５２０）。コンテナは、トレースを利用して、リクエストの完了を示すトレースログを取得する（５２１）。コンテナは、結果をリクエストの送信元に返す（５２２）。スケジューラは、キューの現在の同時実行数の値を１つ減らす（５２３）。

図１２は本実施形態のマッピングテーブル１１１の構成を示す図である。図１２に示す様にマッピングテーブル１１１は、オブジェクト６０１、ロック形式６０２から構成される。Ｏ／Ｒマッピングフレームワーク１０８は、データベースサーバ１１３にアクセスする時のユーザオブジェクト１０７のロック形式６０２を、オブジェクト６０１をキーにして取得する。また、解析部１１６が、オブジェクト管理テーブル１２２を作成する上で、ユーザオブジェクト１０７の現在のロック形式６０２を取得する為に参照される。

図１３は本実施形態のトレースログ１１５の構成を示す図である。図１３に示す様にトレースログ１１５は、トレースポイント７０１、時刻７０２、リクエスト通番７０３、オペレーション７０４、オブジェクト７０５、オブジェクトＩＤ７０６から構成される。

トレースポイント７０１には、アプリケーションサーバでの処理の開始を示す開始ポイントＴＲＣ００００１、処理の完了を示す完了ポイントＴＲＣ００００６、Ｏ／Ｒマッピングフレームワークにおいて、データベースに対してデータの参照の開始を示すポイントＴＲＣ００００２、参照の完了を示すポイントＴＲＣ００００３、データの更新の開始を示すポイントＴＲＣ００００４、更新の完了を示すポイントＴＲＣ００００５が存在する。

時刻７０２は、トレースポイント７０１を取得した時点の現在時刻とする。なお、本システムを構成するサーバ間の時刻合わせは行われていることを前提とする。リクエスト通番７０３は、一つのリクエストに対して一意の通番がトレーサによって割り振られる。リクエスト通番でフィルタリングを行うことにより、リクエストの処理の流れが確認できる。

オペレーション７０４は、リクエストに含まれている情報である。例えば、ＵＲＬ等を指す。トレースポイントＴＲＣ００００１及びＴＲＣ００００６のみで取得可能である。オブジェクト７０５は、リクエストの処理で実際に操作されるデータベースのデータにマッピングされているオブジェクトである。オブジェクトＩＤ７０６は、オブジェクト７０５を示す一意のＩＤである。オブジェクト７０５、オブジェクトＩＤはトレースポイントＴＲＣ００００２、ＴＲＣ００００３、ＴＲＣ００００４、ＴＲＣ００００５で取得可能である。

図１４は本実施形態のキューテーブル１０４の構成を示す図である。図１４に示す様にキューテーブル１０４は、キュー名８０１、オペレーション８０２、閾値８０３から構成される。

キュー名８０１は、スケジューラが管理するキューの名前を指す。オペレーション８０２は、キューにキューイングされたリクエストに含まれている情報である。閾値８０３は、キュー判定部で使用され、ユーザにより入力される情報である。

図１５は本実施形態のオペレーション対応テーブル１２３の構成を示す図である。図１５に示す様にオペレーション対応テーブル１２３は、オペレーション９０１、オブジェクト９０２から構成される。

オペレーション９０１は、リクエストに含まれる情報である。オブジェクト９０２は、リクエストの処理で実際に操作されるデータベースのデータにマッピングされているオブジェクトである。１つのオペレーションに対して、複数のオブジェクトを操作することもある。

図１６は本実施形態のオブジェクト管理テーブル１２２の構成を示す図である。図１６に示す様にオブジェクト管理テーブル１２２は、オブジェクト１００１、ロック形式１００２、平均処理時間１００３、平均参照時間１００４、平均中間時間１００５、平均更新時間１００６、平均待ち時間１００７、ロック衝突率１００８から構成される。

オブジェクト１００１は、リクエストの処理で実際に操作されるデータベースのデータにマッピングされているオブジェクトである。ロック形式１００２は、オブジェクト１００１をキーに、キューテーブルから取得したロック形式６０２である。

平均処理時間１００３は、同一のオブジェクトにおける現在までの処理時間の平均値である。平均参照時間１００４は、同一のオブジェクトにおける現在までの参照時間の平均値である。平均中間時間１００５は、同一のオブジェクトにおける現在までの中間時間の平均値である。平均更新時間１００６は、同一のオブジェクトにおける現在までの更新時間の平均値である。

平均待ち時間１００７は、同一のオブジェクトにおける現在までの待ち時間の平均値である。ロック衝突率１００８は、同一のオブジェクトに対するロックの衝突率である。リトライなし平均処理時間１００９は、同一オブジェクトにおいて、ロック形式Ｏｐｔｓｍｉｓｔｉｃである場合、ロックの衝突が起きずに、リクエストが処理された平均時間であり、ロックの衝突が発生した場合にリトライされる時間を含まない時間である。

図１７は本実施形態のサーバテーブル１２１の構成を示す図である。図１７に示す様にサーバテーブル１７０３は、サーバ名１７０１、スケジューラ１７０２から構成される。サーバ名１７０１は、管理サーバ１００が管理しているサーバ群を指す。設定部１２０がロック形式またはキューの同時実行数の設定を行う場合に、サーバ名１７０１をキーに、設定対象となるスケジューラ１０２を取得する。

本実施形態の情報処理装置は、図２のアプリケーションサーバ１０５、図３の管理サーバ１００、データベースサーバ１１３から構成される。

図２は本実施形態のアプリケーションサーバ１０５のハードウェア構成を示す図である。図２において、アプリケーションサーバ１０５は、メモリ２０２、ＣＰＵ２０１、記憶装置２０３、通信インターフェイス２０４から構成される。メモリ２０２には、コンテナ１２６、キューテーブル１０４、スケジューラ１０２、キュー１０３、アプリケーション１０６、マッピングテーブル１１１、ユーザオブジェクト１０７、データベースアクセス部１１２、トレーサ１１４、Ｏ／Ｒマッピングフレームワーク１０８、参照部１０９、更新部１１０が格納されており、各々ＣＰＵ２０１によって実行される。記憶装置２０３には、トレースログ１１５が格納されおり、必要に応じてメモリ２０２にロードされる。

図３は本実施形態の管理サーバ１００のハードウェア構成を示す図である。図３において、管理サーバ１００は、メモリ２３３、ＣＰＵ２４２、通信インターフェイス２３１から構成される。メモリ２３３には、判定部１１７、ロック判定部１１８、キュー判定部１１９、解析部１１６、設定部１２０、オペレーション対応テーブル１２３、オブジェクト管理テーブル１２２、サーバテーブル１２１が格納されており、各々ＣＰＵ２４２によって実行される。

本実施形態において、解析部１１６等の各処理部としてコンピュータを機能させる為のプログラムは、ＣＤ−ＲＯＭ等の記録媒体に記録され磁気ディスク等に格納された後、メモリにロードされて実行されるものとする。なお前記プログラムを記録する記録媒体はＣＤ−ＲＯＭ以外の他の記録媒体でも良い。また前記プログラムを当該記録媒体からコンピュータにインストールして使用しても良いし、ネットワークを通じて当該記録媒体にアクセスして前記プログラムを使用するものとしても良い。

図４は本実施形態のデータベースサーバ１１３のハードウェア構成を示す図である。図４において、データベースサーバ１１３は、メモリ２６３、ＣＰＵ２６１、記憶装置２６４、通信インターフェイス２６２から構成される。メモリ２６３には、ＤＢＭＳ１２５が格納されており、ＣＰＵ２６１によって実行される。記憶装置２６４には、データベースのテーブル１２４が格納されており、必要に応じてメモリ２６３にロードされる。

従来技術では、アプリケーションの特徴やシステム構成、性能要件に応じて、手動でＯ／Ｒマッピングフレームワークに対してロック形式を手動で設定しており、ロック形式はＯ／Ｒマッピングフレームワークの定義ファイルに記載する等、ユーザが手動で設定を記述する必要があった。

本実施形態では、管理サーバが自動で適切なロック形式を判定して、設定するため、ユーザが手動で定義ファイルを記述する必要がなくなり、Ｏ／Ｒマッピングフレームワークの設定作業を軽減できる。

以上説明した様に本実施形態のデータベース処理装置によれば、トレースログとマッピングテーブルを解析してオブジェクトのロック形式を判定しロック形式の設定を行うので、データベース処理における適切なロック形式を導き出して、動的に適切なロック形式をＯ／Ｒマッピングフレームワークに対して設定することが可能である。

また本実施形態のデータベース処理装置によれば、トレースログとマッピングテーブルを解析してキューのリクエスト処理の同時実行数の増減を判定し同時実行数の設定を行うので、データベース処理におけるシステム全体のパフォーマンスを向上させることが可能である。

本実施形態の複数のアプリケーションサーバを管理するシステムの構成を示す図である。 本実施形態のアプリケーションサーバ１０５のハードウェア構成を示す図である。 本実施形態の管理サーバ１００のハードウェア構成を示す図である。 本実施形態のデータベースサーバ１１３のハードウェア構成を示す図である。 本実施形態のＰｅｓｓｉｍｉｓｔｉｃ／Ｏｐｔｉｍｉｓｔｉｃのリクエストの処理の流れを示す図である。 本実施形態のＰｅｓｓｉｍｉｓｔｉｃロック形式の動作例を示す図である。 本実施形態のＯｐｔｉｍｉｓｔｉｃロック形式の動作例を示す図である。 本実施形態の解析部１１６／判定部１１７／設定部１２０の処理概要のフロー例を示す図である。 本実施形態のロック判定部１１８のフロー例を示す図である。 本実施形態のキュー判定部１１９のフロー例を示す図である。 本実施形態のリクエストフローの例を示す図である。 本実施形態のマッピングテーブル１１１の構成を示す図である。 本実施形態のトレースログ１１５の構成を示す図である。 本実施形態のキューテーブル１０４の構成を示す図である。 本実施形態のオペレーション対応テーブル１２３の構成を示す図である。 本実施形態のオブジェクト管理テーブル１２２の構成を示す図である。 本実施形態のサーバテーブル１２１の構成を示す図である。

符号の説明

１００…管理サーバ、１０１…ロードバランサ、１０２…スケジューラ、１０３…キュー、１０４…キューテーブル、１０５…アプリケーションサーバ、１０６…アプリケーション、１０７…ユーザオブジェクト、１０８…Ｏ／Ｒマッピングフレームワーク、１０９…参照部、１１０…更新部、１１１…マッピングテーブル、１１２…データベースアクセス部、１１３…データベースサーバ、１１４…トレーサ、１１５…トレースログ、１１６…解析部、１１７…判定部、１１８…ロック判定部、１１９…キュー判定部、１２０…設定部、１２１…サーバテーブル、１２２…オブジェクト管理テーブル、１２３…オペレーション対応テーブル、１２４…テーブル、１２５…ＤＢＭＳ、１２６…コンテナ、１５２…スケジューラ、１５３…キュー、１５４…キューテーブル、１５６…アプリケーション、１５７…ユーザオブジェクト、１５８…Ｏ／Ｒマッピングフレームワーク、１５９…参照部、１６０…更新部、１６１…マッピングテーブル、１６２…データベースアクセス部、１６４…トレーサ、１６５…トレースログ、１７６…コンテナ、２０１…ＣＰＵ、２０２…メモリ、２０３…記憶装置、２０４…通信インターフェイス、２３１…通信インターフェイス、２３３…メモリ、２４２…ＣＰＵ、２６１…ＣＰＵ、２６２…通信インターフェイス、２６３…メモリ、２６４…記憶装置、１１００…リクエスト、１１０１…リクエスト開始ポイント、１１０２…参照開始ポイント、１１０３…参照完了ポイント、１１０４…更新開始ポイント、１１０５…更新完了ポイント、１１０６…リクエスト完了ポイント、１１０７…参照時間、１１０８…中間時間、１１０９…更新時間、１１１０…処理時間、１１１１…待ち時間、１１２０…ＡＰ層、１１２１…ＯＲ層、１１２２…ＤＢ層、１２００…リクエストＡ、１２０２…参照開始ポイント、１２０５…更新完了ポイント、１２１０…リクエストＢ、１２１２…参照開始ポイント、１２１３…参照完了ポイント、１２１５…更新完了ポイント、１２２０…リクエストＣ、１２３０…ロック時間、１２４０…ロック待ち時間、１３００…リクエストＡ、１３０２…参照開始ポイント、１３０４…更新エラーポイント、１３０５…参照開始ポイント、１３１０…リクエストＢ、１３１２…参照開始ポイント、１３１５…更新完了ポイント、１３１６…処理時間、１３１７…浪費時間、６０１…オブジェクト、６０２…ロック形式、７０１…トレースポイント、７０２…時刻、７０３…リクエスト通番、７０４…オペレーション、７０５…オブジェクト、７０６…オブジェクトＩＤ、８０１…キュー名、８０２…オペレーション、８０３…閾値、９０１…オペレーション、９０２…オブジェクト、１００１…オブジェクト、１００２…ロック形式、１００３…平均処理時間、１００４…平均参照時間、１００５…平均中間時間、１００６…平均更新時間、１００７…平均待ち時間、１００８…ロック衝突率、１００９…リトライなし平均処理時間、１７０１…サーバ名、１７０２…スケジューラ、１７０３…サーバテーブル。

Claims (10)

1. データベース装置は、データベースを管理し、
   複数のプログラム実行装置（アプリケーションサーバ）は、第１の記憶装置を有し、受け付けたオペレーションに基づいたプログラムの実行により該データベース装置へアクセスするとともにサービスを実現し、
   管理装置は、第２の記憶装置を有し、前記複数のプログラム実行装置を管理し、
   前記プログラム実行装置は、前記オペレーションを含む前記プログラムのトレースログと、前記プログラムが利用する前記データベースへのアクセス時に用いるロック形式を記憶したマッピングテーブルとを前記第１の記憶装置に格納し、
   前記管理装置は、前記第１の記憶装置から前記トレースログと前記マッピングテーブルとを参照して解析し、前記オペレーションとその該オペレーションに基づいて実行されたプログラムと該プログラムのトレースログとを対応付けて前記第２の記憶装置に格納し、該格納した前記オペレーションとその該オペレーションに基づいて実行されたプログラムと該プログラムのトレースログを参照し、前記ロック形式毎に前記オペレーションに対する前記トレースログを評価して前記プログラム実行装置で用いる前記ロック形式を決定し、該決定したロック形式の前記複数のプログラム実行装置への設定を行うことを特徴とするデータベース処理方法。
2. 前記管理装置はオブジェクトのロック形式として設定されている第１のロック形式における平均処理時間とオブジェクトのロック形式として設定されていない第２のロック形式における平均処理時間とを比較して前記オブジェクトのロック形式の判定を行うことを特徴とする請求項１に記載されたデータベース処理方法。
3. 前記管理装置はオブジェクトのロック形式として設定されていない第２のロック形式における平均処理時間を所定の式に従って算出して平均処理時間の比較を行うことを特徴とする請求項２に記載されたデータベース処理方法。
4. 前記管理装置が前記判定を行うロック形式はＰｅｓｓｉｍｉｓｔｉｃロック形式とＯｐｔｉｍｉｓｔｉｃロック形式であることを特徴とする請求項２または請求項３のいずれかに記載されたデータベース処理方法。
5. 前記管理装置は、オブジェクトのロック形式として設定されている第１のロック形式がＰｅｓｓｉｍｉｓｔｉｃロック形式である場合に、オブジェクトのロック形式として設定されていない第２のロック形式であるＯｐｔｉｍｉｓｔｉｃロック形式における平均処理時間を、（平均処理時間−平均待ち時間）×（１−衝突率）＋（平均処理時間−平均待ち時間＋平均参照時間＋平均中間時間＋リトライ待ち時間）×衝突率の式に従って算出して平均処理時間の比較を行うことを特徴とする請求項４に記載されたデータベース処理方法。
6. 前記管理装置は、オブジェクトのロック形式として設定されている第１のロック形式がＯｐｔｉｍｉｓｔｉｃロック形式である場合に、オブジェクトのロック形式として設定されていない第２のロック形式であるＰｅｓｓｉｍｉｓｔｉｃロック形式における平均処理時間を、リトライなし平均処理時間＋（平均参照時間＋平均中間時間＋平均更新時間）×衝突率＋リトライなし平均処理時間×（１−衝突率）の式に従って算出して平均処理時間の比較を行うことを特徴とする請求項４に記載されたデータベース処理方法。
7. 前記管理装置が前記オペレーション対応テーブルとオブジェクト管理テーブルとキューテーブルを記憶装置から読み出してキューのリクエスト処理の同時実行数の増減を判定し、前記管理装置が前記判定したキューのリクエスト処理の同時実行数の増減についてアプリケーションサーバへ通信装置により送信してリクエスト処理の同時実行数の設定を行うことを特徴とする請求項１乃至請求項６のいずれか１項に記載されたデータベース処理方法。
8. 前記管理装置は設定されているロック形式における平均処理時間と所定の閾値とを比較してリクエスト処理の同時実行数の増減を判定することを特徴とする請求項７に記載されたデータベース処理方法。
9. データベース装置は、データベースを管理し、
   複数のプログラム実行装置（アプリケーションサーバ）は、第１の記憶装置を有し、受け付けたオペレーションに基づいたプログラムの実行により該データベース装置へアクセスするとともにサービスを実現し、
   管理装置は、第２の記憶装置を有し、前記複数のプログラム実行装置を管理し、
   前記プログラム実行装置は、前記オペレーションを含む前記プログラムのトレースログと、前記プログラムが利用する前記データベースへのアクセス時に用いるロック形式を記憶したマッピングテーブルとを前記第１の記憶装置に格納し、
   前記管理装置は、前記第１の記憶装置から前記トレースログと前記マッピングテーブルとを参照して解析し、前記オペレーションとその該オペレーションに基づいて実行されたプログラムと該プログラムのトレースログとを対応付けて前記第２の記憶装置に格納し、該格納した前記オペレーションとその該オペレーションに基づいて実行されたプログラムと該プログラムのトレースログを参照し、前記ロック形式毎に前記オペレーションに対する前記トレースログを評価して前記プログラム実行装置で用いる前記ロック形式を決定し、該決定したロック形式の前記複数のプログラム実行装置への設定を行うことを特徴とする計算機システム。
10. データベース装置は、データベースを管理し、
    複数のプログラム実行装置（アプリケーションサーバ）は、第１の記憶装置を有し、受け付けたオペレーションに基づいたプログラムの実行により該データベース装置へアクセスするとともにサービスを実現し、
    管理装置は、第２の記憶装置を有し、前記複数のプログラム実行装置を管理し、
    前記プログラム実行装置は、前記オペレーションを含む前記プログラムのトレースログと、前記プログラムが利用する前記データベースへのアクセス時に用いるロック形式を記憶したマッピングテーブルとを前記第１の記憶装置に格納し、
    前記管理装置は、前記第１の記憶装置から前記トレースログと前記マッピングテーブルとを参照して解析し、前記オペレーションとその該オペレーションに基づいて実行されたプログラムと該プログラムのトレースログとを対応付けて前記第２の記憶装置に格納し、該格納した前記オペレーションとその該オペレーションに基づいて実行されたプログラムと該プログラムのトレースログを参照し、前記ロック形式毎に前記オペレーションに対する前記トレースログを評価して前記プログラム実行装置で用いる前記ロック形式を決定し、該決定したロック形式の前記複数のプログラム実行装置への設定を行うデータベース処理方法をコンピュータに実行させることを特徴とするプログラム。

Images