JP2010211616A - データベース管理システム、ロック障害監視方法及びロック障害監視プログラム - Google Patents

データベース管理システム、ロック障害監視方法及びロック障害監視プログラム Download PDF

Info

Publication number
JP2010211616A
JP2010211616A JP2009058337A JP2009058337A JP2010211616A JP 2010211616 A JP2010211616 A JP 2010211616A JP 2009058337 A JP2009058337 A JP 2009058337A JP 2009058337 A JP2009058337 A JP 2009058337A JP 2010211616 A JP2010211616 A JP 2010211616A
Authority
JP
Japan
Prior art keywords
session
lock
recorded
flag
recording
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.)
Granted
Application number
JP2009058337A
Other languages
English (en)
Other versions
JP5332754B2 (ja
Inventor
Hiroaki Handa
裕明 半田
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.)
Ricoh Co Ltd
Original Assignee
Ricoh Co 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 Ricoh Co Ltd filed Critical Ricoh Co Ltd
Priority to JP2009058337A priority Critical patent/JP5332754B2/ja
Publication of JP2010211616A publication Critical patent/JP2010211616A/ja
Application granted granted Critical
Publication of JP5332754B2 publication Critical patent/JP5332754B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

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

Abstract

【課題】ロック障害の発生に関係のないセッションを残存させながら、効率よく処理を行なうことができるロック障害監視プログラム、ロック障害監視方法及びデータベース管理システムを提供する。
【解決手段】データベース管理システム41,42の制御手段は、アイドル状態において初めて障害発生判定時間より長い経過時間のセッションを検出した場合には、アイドル状態処理を実行する。再びロック監視処理が実行されたときに、ロック障害が継続して発生している場合には、制御手段は、経過時間に基づいてセッションを開放するロック解除待機状態処理を実行する。次のロック監視処理が実行されたときにロック障害が継続して発生していた場合には、制御手段は、解除起動完了状態処理を実行する。その後も、ロック障害が継続して発生していた場合には、制御手段は、一定時間以上経過しているすべてのセッションの開放処理を実行する。
【選択図】図1

Description

本発明は、データベースにおけるロック制御においてロック障害の発生を監視するロック障害監視方法、ロック障害監視プログラム及びデータベース管理システムに関する。
従来から、企業等において共有データとしてのデータベースを管理するデータベースシステムが存在する。このデータベースシステムは、データを記憶しているデータベースと、このデータベースに対して処理を実行するデータベース管理システムとを含んで構成される。データベース管理システムでは、外部から同時に処理依頼を受信しても処理を実行するために排他制御が行なわれている(例えば、特許文献1参照。)。
排他制御においては、データベース管理システムでは、読み書きを対象とするデータ領域に対してロックして、他の処理の読み出しや書き込みを一時的に制限又は禁止する。そして、処理が終了した場合に、データベース管理システムは、ロックを解除して、他の処理の読み出しや書き込みが行なえるように制御している。
ところが、データベース管理システムでは、データ領域のロック解除ができなくなる場合がある。この場合、データベース管理システムは、このデータ領域に対して後続の処理が行なえなくなるため、このデータ領域を処理対象領域とするセッションが処理の順番待ちをしたまま未処理の状態で蓄積される。そして、データベース管理システムにこのデータ領域に対する処理指示を出していたサーバは、データベース管理システムから処理結果を受信しないため、未処理の処理が蓄積される。
この場合、従来では、サーバを再起動させて、データベース管理システムのセッションすべてを開放することがある。開放されたセッションには、二度と同じ処理が行なわれないものもあるため、データに矛盾が生じる可能性があり、正しい処理を効率よく行なうことができなかった。そこで、ロック障害の発生に関係のないセッションは、できる限り残存させることが望ましい。
本発明は、上述の課題に鑑みてなされ、その目的は、ロック障害の発生に関係のないセッションを残存させながら、効率よく処理を行なうことができるロック障害監視方法、ロック障害監視プログラム及びデータベース管理システムを提供することにある。
上記問題点を解決するために、請求項1に記載の発明は、セッション識別子と、セッションが開始されてからの経過時間とを関連付けて記録したセッション管理データ記憶手段と、ロック検出フラグを記録するロック検出フラグ記録手段と、第1開放処理を行なったことを示す実行済フラグを記録する処理実行済フラグ記録手段と、データベースに対する処理制御を行なう制御手段とを備え、ロック障害の監視を行なうデータベース管理システムであって、前記制御手段が、セッション開始の経過時間に応じて、ロック障害の発生の有無を定期的に検出するロック障害検出手段と、ロック障害を検出した場合には、既にロック検出フラグが記録されているか否かを判定する手段と、前記ロック検出フラグが記録されていない場合には、新たにロック検出フラグを前記ロック検出フラグ記録手段に記録するロック検出フラグ記録手段と、前記ロック検出フラグが記録されている場合には、既
に実行済フラグが記録されているか否かを判定する手段と、前記ロック検出フラグが記録されており、かつ前記実行済フラグが記録されていない場合には、前記セッション管理データ記憶手段に記録された前記経過時間に基づくセッションを強制的に開放する第1開放処理を実行し、前記実行済フラグを記録する第1処理実行手段と、前記ロック検出フラグ及び前記実行済フラグが記録されている場合には、前記第1開放処理において開放したセッションとは別のセッションを強制的に開放する第2開放処理を実行する第2処理実行手段とを備えたことを要旨とする。
請求項2に記載の発明は、請求項1に記載のデータベース管理システムにおいて、前記セッション管理データ記憶手段は、セッション識別子に関連付けて、前記データベースの処理対象領域を特定する対象特定データを更に記憶しており、前記制御手段は、セッション識別子、セッションが開始されてからの経過時間、ロック検出フラグ及び前記対象特定データを関連付けて記録した第2のセッション管理データ記憶手段と、前記データベースに対して処理を行なう第2の制御手段とを備えた他のデータベース管理システムに接続されており、前記第2処理実行手段が、前記セッション管理データ記憶手段に記録された経過時間から、一定時間以上経過しているセッションを特定し、このセッションの処理対象領域と重複する処理対象領域に対して処理を行なうセッションが前記第2セッション管理データ記憶手段に記録されているか否かを判定する手段と、前記第2セッション管理データ記憶手段に記録されている場合には、重複する処理対象領域のセッションの経過時間を比較する手段と、比較した結果、経過時間が長いセッションが前記セッション管理データ記憶手段に記録されている場合には、このセッションを強制的に開放する連携開放処理を実行する手段とを更に備えたことを要旨とする。
請求項3に記載の発明は、請求項1又は2に記載のデータベース管理システムにおいて、前記第2開放処理を実行した回数を記録する回数データ記憶手段を備え、前記第2処理実行手段は、前記回数データ記憶手段に記録された回数に応じて、前記セッション管理データ記憶手段に記録されている経過時間から、段階的にセッションを強制的に開放することを要旨とする。
請求項4に記載の発明は、請求項1〜3のいずれか1項に記載のデータベース管理システムにおいて、前記第1処理実行手段は、前記セッション管理データ記憶手段に記録された経過時間のうち、最も長い経過時間のセッションを強制的に解放する第1開放処理を実行することを要旨とする。
請求項5に記載の発明は、セッション識別子と、セッションが開始されてからの経過時間とを関連付けて記録したセッション管理データ記憶手段と、ロック検出フラグを記録するロック検出フラグ記録手段と、第1開放処理を行なったことを示す実行済フラグを記録する処理実行済フラグ記録手段と、データベースに対する処理制御を行なう制御手段とを備えたデータベース管理システムにおけるロック障害の監視を行なう方法であって、前記制御手段が、セッション開始の経過時間に応じて、ロック障害の発生の有無を定期的に検出するロック障害検出段階と、ロック障害を検出した場合には、既にロック検出フラグが記録されているか否かを判定する段階と、前記ロック検出フラグが記録されていない場合には、新たにロック検出フラグを前記ロック検出フラグ記録手段に記録するロック検出フラグ記録段階と、前記ロック検出フラグが記録されている場合には、既に実行済フラグが記録されているか否かを判定する段階と、前記ロック検出フラグが記録されており、かつ前記実行済フラグが記録されていない場合には、前記セッション管理データ記憶手段に記録された前記経過時間に基づくセッションを強制的に開放する第1開放処理を実行し、前記実行済フラグを記録する第1処理実行段階と、前記ロック検出フラグ及び前記実行済フラグが記録されている場合には、前記第1開放処理において開放したセッションとは別のセッションを強制的に開放する第2開放処理を実行する第2処理実行段階とを実行するこ
とを要旨とする。
請求項6に記載の発明は、セッション識別子と、セッションが開始されてからの経過時間とを関連付けて記録したセッション管理データ記憶手段と、ロック検出フラグを記録するロック検出フラグ記録手段と、第1開放処理を行なったことを示す実行済フラグを記録する処理実行済フラグ記録手段と、データベースに対する処理制御を行なう制御手段とを備えたデータベース管理システムにおけるロック障害の監視を行なうプログラムであって、前記制御手段を、セッション開始の経過時間に応じて、ロック障害の発生の有無を定期的に検出するロック障害検出手段、ロック障害を検出した場合には、既にロック検出フラグが記録されているか否かを判定する手段、前記ロック検出フラグが記録されていない場合には、新たにロック検出フラグを前記ロック検出フラグ記録手段に記録するロック検出フラグ記録手段、前記ロック検出フラグが記録されている場合には、既に実行済フラグが記録されているか否かを判定する手段、前記ロック検出フラグが記録されており、かつ前記実行済フラグが記録されていない場合には、前記セッション管理データ記憶手段に記録された前記経過時間に基づくセッションを強制的に開放する第1開放処理を実行し、前記実行済フラグを記録する第1処理実行手段、及び前記ロック検出フラグ及び前記実行済フラグが記録されている場合には、前記第1開放処理において開放したセッションとは別のセッションを強制的に開放する第2開放処理を実行する第2処理実行手段として機能することを要旨とする。
(作用)
本発明によれば、ロック障害を検出した場合には、新たにロック検出フラグを記録して、次のロック監視処理においてロック障害が解消されるか否かを監視する。ロック検出フラグが記録されたときに、継続してロック障害が発生している場合には、経過時間に基づいてセッションを強制的に開放する第1開放処理を実行して、次のロック監視処理においてロック障害が解消されているか否かを監視する。第1開放処理を実行しても継続してロック障害が発生している場合には、別のセッションを強制的に開放する。このため、経過時間からロック障害が発生している可能性の高いセッションを開放した後、しばらくしてもロック障害が発生していなかった場合にのみ、別のセッションを強制的に開放する。従って、ロック障害の発生状態を見ながら徐々にセッションを強制的に開放するので、ロック障害の発生に影響していないようなセッションについては残存させることができる。
本発明によれば、制御手段は、第2開放処理において、一定時間以上経過しているセッションの処理対象領域と重複する処理対象領域のセッションが、他のデータベース管理システムに存在し、他のデータベース管理システムのそのセッションの経過時間よりも長い場合には、このセッションを強制的に開放する。このため、他のデータベース管理システムにおける処理状況からロック障害の発生に影響していると判定できるセッションを開放するため、その他のセッションについては残存させることができる。
本発明によれば、制御手段は、第2開放処理において、回数データ記憶手段に記録された回数に応じて、セッション管理データ記憶手段に記録されている経過時間から、段階的にセッションを強制的に開放する。このため、ロック障害の発生状態を見ながら徐々にセッションを強制的に開放するので、ロック障害の発生に影響していないようなセッションについては残存させることができる。
本発明によれば、制御手段は、第1開放処理において、セッション管理データ記憶手段に記録された経過時間のうち、最も長い経過時間のセッションを強制的に解放する。このため、処理に長い時間がかかっているセッションをロック障害の発生原因の可能性が高いセッションとして開放するので、ロック障害の解消を自動的に図ることができる。
本発明によれば、ロック障害の発生に関係のないセッションを残存させながら、効率よく処理を行なうことができる。
実施形態における処理管理システムの概略構成図。 ロック監視処理の処理手順を説明する流れ図。 ロック障害が発生しているときの各処理の処理手順を説明するための流れ図であり、(a)はアイドル状態処理、(b)はロック解除待機状態処理、(c)は解除起動完了状態処理、(d)はロック継続中状態処理。 変更例におけるロック継続中状態処理の処理手順を説明するための流れ図。
以下、本発明を具体化した一実施形態を図1〜図3に基づいて説明する。本実施形態においては、図1に示すように、クライアント機器10の状態情報を管理するための処理を行なう処理管理システム20として説明する。ここで、状態情報には、例えば、出力した紙のカウンタ値やエラー発生情報等が含まれる。
処理管理システム20は、ネットワーク(例えばインターネット)を介して、複数のクライアント機器10に接続されている。本実施形態では、クライアント機器10は、ネットワーク機能を備えた印刷機器や複合機である。クライアント機器10は、状態を管理する依頼を処理管理システム20に送信する。この状態管理依頼には、クライアント機器10の機器識別子に関連付けられた状態情報が含まれる。
処理管理システム20は、負荷分散機21、複数の処理サーバ31,32,…,3n、複数のデータベース管理システム41,42及びデータベース25を備えている。本実施形態の処理管理システム20は、図1に示すように、第1の処理サーバ31、第2の処理サーバ32,…,第nの処理サーバ3nを備えている。また、本実施形態の処理管理システム20は、第1のデータベース管理システム41及び第2のデータベース管理システム42を備えている。データベース25は、クライアント機器10の機器識別子に関連付けて状態情報を記憶する。
負荷分散機21は、各クライアント機器10からの状態管理依頼を受信する。負荷分散機21は、各処理サーバ31〜3nに接続されており、状態管理依頼に応じたジョブを各処理サーバ31〜3nに振り分ける。この場合、負荷分散機21は、各処理サーバ31〜3nから未処理のジョブ数に関する情報を取得し、未処理のジョブ数を比較する。比較した結果、負荷分散機21は、各処理サーバ31〜3nにおける未処理のジョブ数が同程度になるように、状態管理依頼を各処理サーバ31〜3nに振り分けて送信する。
処理サーバ31〜3nは、クライアント機器10の状態情報を用いたジョブ(管理処理)を実行する。このジョブとしては、例えば、処理サーバ31〜3nは、各クライアント機器10からの状態管理依頼に基づいて、受信した状態情報をデータベース25に記憶する処理等がある。このジョブの実行において、データベース25に対して読み出しや書き込み処理を行なう等のデータベース処理を行なう場合、各処理サーバ31〜3nは、より早く処理が可能なデータベース管理システムに対してデータベース処理依頼を送信する。具体的には、各処理サーバ31〜3nは、データベース管理システム41,42の後述するセッション記憶部からセッション管理データの数を取得して比較し、このセッション管理データの数が少ないデータベース管理システム41,42にデータベース処理依頼を送信する。
各データベース管理システム41,42は、各処理サーバ31〜3nからのデータベース処理依頼に応じてデータベース25に対してデータベース処理を実行する。本願発明のデータベース管理システム41,42は、制御手段(CPU)及び記憶手段(RAM、ROM等)を備えている。
各データベース管理システム41,42は、セッションを管理するためのセッション管理データを記憶するセッション記憶部を備えている。このセッション記憶部がセッション管理データ記憶手段として機能する。セッション管理データは、処理サーバ31〜3nからのデータベース処理依頼を受信した場合に、セッション記憶部に記録される。このセッション管理データには、セッションを特定するためのセッション識別子と、データベース25とのセッションを開始してからの経過時間とが関連付けられて記憶される。各データベース管理システム41,42は、各処理サーバ31〜3nからのデータベース処理依頼に対してセッション識別子を付与し、セッション記憶部に記録する。
また、各データベース管理システム41,42は、ログファイルデータ記憶部を備えている。このログファイルデータ記憶部には、実行済みの処理に関するログデータが記録される。このログデータには、処理を特定する処理識別子、処理対象領域を特定する対象識別子及び処理時間等に関するデータが含まれる。
更に、本実施形態の各データベース管理システム41,42の制御手段は、後述するロック監視処理(ロック障害検出段階、ロック検出フラグ記録段階、第1処理実行段階及び第2処理実行段階等を含む処理)を行なう。このため、各データベース管理システム41,42の制御手段は、定期的に実行するロック監視処理プログラムを記憶している。そして、このロック監視処理プログラムを実行することにより、各データベース管理システム41,42の制御手段は、ロック障害検出手段、第1処理実行手段及び第2処理実行手段等として機能する。
更に、各データベース管理システム41,42には、ロック検出フラグ記録手段及び処理実行済フラグ記録手段としての状態フラグデータ記憶部が設けられている。この状態フラグデータ記憶部には、ロック検出フラグ及び処理実行済フラグを示す状態フラグが記録される。本実施形態では、状態フラグとして、「アイドル状態」、「ロック解除待機状態」、「解除起動完了状態」及び「ロック継続中状態」のそれぞれを示すフラグを用いる。
アイドル状態フラグは、データベース25とのセッションを開始してからの経過時間が一定以上長いセッションがない状態、すなわちロック障害が発生されていない状態を示す。
ロック解除待機状態フラグとは、ロック障害が発生したが、次のロック監視処理を行なうまで待機する状態を示す。
解除起動完了状態フラグとは、ロック解除待機状態フラグが記録されていた場合に、今回のロック監視処理においてもロックの障害が解除されていなかった状態を示す。
ロック継続中状態フラグとは、解除起動完了状態フラグが記録されていた場合に、今回のロック監視処理においてもロック障害が解除されておらず継続中であった状態を示す。
なお、本実施形態では、ロック監視処理が最初に行なわれる場合には、アイドル状態フラグが状態フラグデータ記憶部に記録されている。更に、本実施形態において、ロック解除待機状態フラグ、解除起動完了状態フラグ及びロック継続中状態フラグがロック検出フラグとして機能する。また、本実施形態においては、解除起動完了状態フラグ及びロック継続中状態フラグが実行済フラグとして機能する。
本実施形態では、各データベース管理システム41,42の制御手段は、セッション開始からの経過時間が、予め定めた一定時間(障害発生判定時間)以上の場合には、ロック障害が発生していると判定する。このため、データベース管理システム41,42の制御手段は、障害発生判定時間に関するデータを記憶している。
また、各データベース管理システム41,42は、警告通知、障害通知、ロック障害解消通知を送信する通知先に関するデータを記憶手段に記録している。更に、各データベース管理システム41,42には、ログを出力するための出力装置と、操作指示を入力するための入力装置とが接続されている。出力装置としては、具体的には、ディスプレイが用いられる。
次に、以上のように構成された処理管理システム20においてクライアント機器10の状態情報を管理する管理処理について、図2及び図3を用いて説明する。
クライアント機器10は、定期的に、カウンタ値やエラー発生情報等を含む状態管理依頼を、インターネットを介して処理管理システム20に送信する。処理管理システム20の負荷分散機21は、状態管理依頼を受信すると、各処理サーバ31〜3nにおいて未処理のジョブ数を取得する。負荷分散機21は、取得した未処理のジョブ数に応じて最もジョブ数が少ない各処理サーバ31〜3nに対して、状態管理依頼を送信する。
各処理サーバ31,32は、状態管理依頼を受信した順番に従って管理処理を行なう。ここで、処理サーバ31が、状態管理依頼に対応してデータベース25にカウンタ値を記録する処理を行なう場合について説明する。この場合、処理サーバ31は、より早く処理が可能なデータベース管理システムに対してデータベース処理依頼を送信する。このデータベース処理依頼には、処理対象領域を特定する対象特定データ、処理操作を特定する操作内容データ及び依頼元を特定するサーバ識別子等が含まれる。
データベース管理システム41,42は、受信したデータベース処理依頼に基づいて、セッション識別子を付与してセッション管理データを生成して、セッション記憶部に記憶する。そして、データベース管理システム41,42は、セッション管理データの対象特定データに対応するデータベース25の処理対象領域に対して、操作内容データに応じたデータベース処理(データベースへの読み出し処理や書き込み処理等)を行なう。この場合、データベース管理システム41,42は、セッションの対象特定データに基づいて、データベース25に対して排他制御を行ないながらデータベース処理を行なう。更に、データベース管理システム41,42は、データベース処理を開始してからの経過時間をセッション記憶部に記録する。そして、データベース25に対するデータベース処理が完了すると、データベース管理システム41,42は、このセッションのセッション識別子、対象特定データ及び処理時間に関するデータをログファイルデータ記憶部に記録する。そして、データベース管理システム41,42は、データベース処理依頼に含まれるサーバ識別子の処理サーバ31に処理完了結果データを送信する。
次に、データベース管理システム41,42が、上述した状態情報の管理処理とは並行して行なうロック監視処理について、図3及び図4を参照して説明する。このロック監視処理は、一定時間ごとに定期的に繰り返して実行される。
まず、データベース管理システム41,42の制御手段は、ロック解除中か否かを判定する(ステップS1−1)。ここで、制御手段は、状態フラグとしてアイドル状態フラグが記録されており、かつ経過時間が障害発生判定時間以上のセッションがあるか否かを判定する。具体的には、状態フラグデータ記憶部にアイドル状態フラグ以外のフラグが記録されている場合には、制御手段は、「ロック解除中でない」と判定する。
また、状態フラグデータ記憶部にアイドル状態フラグが記録されていた場合には、制御手段は、セッション記憶部の経過時間と障害発生判定時間とを比較する。そして、経過時間が障害発生判定時間より短いセッションのセッション管理データのみがセッション記憶部に記録されている場合には、制御手段は、ロック解除中と判定する。この場合(ステップS1−1において「YES」の場合)、ロック監視処理を終了する。
一方、「ロック解除中」でない場合(ステップS1−1において「NO」の場合)には、データベース管理システムの制御手段は、ロック障害が発生しているか否かを判定する(ステップS1−2)。ここで、制御手段は、経過時間が障害発生判定時間より長いセッションがあるか否かを判定する。具体的には、制御手段は、セッション記憶部の経過時間と障害発生判定時間とを比較する。そして、経過時間が障害発判定時間より長いセッションのセッション管理データがセッション記憶部に記録されていた場合(ステップS1−2において「YES」の場合)には、制御手段は、状態による振り分け処理を実行する(ステップS1−3)。ここで、制御手段は、状態フラグデータ記憶部に記録された状態フラグに応じて実行する処理を特定(判定)する。具体的には、状態フラグデータ記憶部にアイドル状態フラグが記録されている場合には、制御手段は、アイドル状態処理を実行する(ステップS1−4)。状態フラグデータ記憶部にロック解除待機状態フラグが記録されている場合には、制御手段は、経過時間に基づいてセッションを開放する第1開放処理としてのロック解除待機状態処理を実行する(ステップS1−5)。また、状態フラグデータ記憶部に解除起動完了状態フラグが記録されている場合には、制御手段は、解除起動完了状態処理を実行する(ステップS1−6)。また、状態フラグデータ記憶部にロック継続中状態フラグが記録されている場合には、制御手段は、第2開放処理としてのロック継続中状態処理を実行する(ステップS1−7)。
(アイドル状態処理)
次に、アイドル状態フラグが記録されている場合に実行されるアイドル状態処理(ステップS1−4)について、図3(a)を用いて説明する。
この場合、データベース管理システム41,42の制御手段は、警告通知送信処理を実行する(ステップS2−1)。具体的には、制御手段は、記憶手段に記録されている通知先に関するデータを取得する。そして、この制御手段は、この通知先に対して障害が発生した可能性がある旨の警告通知を送信する。
次に、制御手段は、ロック解除待機状態への遷移処理を実行する(ステップS2−2)。具体的には、制御手段は、ロック解除待機状態フラグを状態フラグデータ記憶部に記録する。
そして、制御手段は、解析用ログ出力処理を実行する(ステップS2−3)。具体的には、制御手段は、ログファイルデータ記憶部に記録された各セッションのログファイルデータをディスプレイに表示する。以上により、制御手段は、ロック監視処理を終了する。
(ロック解除待機状態処理)
次に、ロック解除待機状態フラグが記録されている場合に実行されるロック解除待機状態処理(ステップS1−5)について、図3(b)を用いて説明する。
この場合、制御手段は、ロック解除起動処理を実行する(ステップS3−1)。ここで、制御手段は、セッション記憶部の経過時間のうち最も長いセッションを開放する処理を実行する。具体的には、制御手段は、セッション記憶部において各セッションの経過時間を比較する。そして、制御手段は、最も長いセッションをセッション記憶部から特定し、このセッションを開放し、このセッションのセッション管理データをセッション記憶部か
ら削除する。
次に、制御手段は、解除起動完了状態への遷移処理を実行する(ステップS3−2)。具体的には、制御手段は、解除起動完了状態フラグを状態フラグデータ記憶部に記録する。以上により、制御手段は、ロック監視処理を終了する。
(解除起動完了状態処理)
次に、解除起動完了状態フラグが記録されている場合に実行される解除起動完了状態処理(ステップS1−6)について、図3(c)を用いて説明する。
この場合、制御手段は、障害通知送信処理を実行する(ステップS4−1)。具体的には、制御手段は、記憶手段に記録されている通知先に関するデータを取得し、この通知先に対して障害発生した旨の障害通知を送信する。
次に、制御手段は、ロック継続中状態への遷移処理を実行する(ステップS4−2)。具体的には、制御手段は、ロック継続中状態フラグを状態フラグデータ記憶部に記録する。
そして、制御手段は、解析用ログ出力処理を実行する(ステップS4−3)。具体的には、制御手段は、ログファイルデータ記憶部に記録された各セッションのログファイルデータをディスプレイに表示する。以上により、制御手段は、ロック監視処理を終了する。
(ロック継続中状態処理)
次に、ロック継続中状態フラグが記録されている場合に実行されるロック継続中状態処理(ステップS1−7)について、図3(d)を用いて説明する。
この場合、制御手段は、一定時間以上経過しているすべてのセッションの開放処理を実行する(ステップS5−1)。具体的には、制御手段は、セッション記憶部に記録された各セッションの経過時間と、予め記憶している削除判定時間とを比較する。そして、制御手段は、削除判定時間より長い経過時間のセッションをセッション記憶部から特定し、このセッションを開放し、このセッションのセッション管理データをセッション記憶部から削除する。以上により、制御手段は、ロック監視処理を終了する。
一方、ロック障害が発生していない場合(ステップS1−2において「NO」の場合)、すなわちロック障害が解消した場合には、制御手段は、障害通知が送信済みか否かを判定する(ステップS1−8)。具体的には、制御手段は、経過時間が障害発生判定時間より短いセッションのみのセッション管理データがセッション記憶部に記録されており、かつ解除起動完了状態フラグ又はロック継続中状態フラグが状態フラグデータ記憶部に記録されている場合には、障害通知を送信したと判定する。
この場合(ステップS1−8において「YES」の場合)、制御手段は、ロック解消通知送信処理を実行する(ステップS1−9)。具体的には、制御手段は、記憶手段に記録されている通知先に関するデータを取得する。そして、この制御手段は、この通知先に対してロック障害が解消した旨を含む解消通知を送信する。
次に、この制御手段は、状態フラグデータ記憶部に、アイドル状態フラグを記録する(ステップS1−10)。以上により、制御手段は、ロック監視処理を終了する。
本実施形態によれば、以下のような効果を得ることができる。
・ 本実施形態のデータベース管理システム41,42の制御手段は、アイドル状態に
おいて初めて障害発生判定時間より長い経過時間のセッションを検出した場合(ステップS1−2において「YES」の場合)には、アイドル状態処理(ステップS1−4)を実行する。そして、再びロック監視処理が実行されたときに、ロック障害が継続して発生している場合(ステップS1−2において「YES」の場合)には、制御手段は、経過時間に基づいてセッションを開放するロック解除待機状態処理(ステップS1−5)を実行する。更に、次のロック監視処理が実行されたときにロック障害が継続して発生していた場合には、制御手段は、解除起動完了状態処理(ステップS1−6)を実行する。その後も、ロック障害が継続して発生していた場合には、制御手段は、ロック継続中状態処理(ステップS1−7)を実行し、一定時間以上経過しているすべてのセッションの開放処理を実行する(ステップS5−1)。このため、ロック障害が継続して発生している場合には、ロック障害の発生原因の可能性の高いセッションを開放し、しばらくしてもロック障害が継続して発生した場合にのみ、別のセッションを強制的に開放する。従って、ロック障害の発生状態に応じて徐々にセッションを強制的に開放させてロック障害の解消を試みることができるので、ロック障害の発生に影響していないようなセッションをできるだけ残存させることができる。
・ 本実施形態のデータベース管理システム41,42の制御手段は、ロック解除待機状態処理(ステップS1−5)において、最も経過時間の長いセッションを開放した(ステップS3−1)。このため、ロック障害の発生原因の可能性が高い最も経過時間の長いセッションを開放するので、効率よくロック障害の解消を行なうことができる。
・ 本実施形態のデータベース管理システム41,42の制御手段は、アイドル状態フラグ以外のフラグが記録されていたときに障害が発生していない場合(ステップS1−2において「NO」の場合)には、アイドル状態フラグを記録する(ステップS1−10)。このため、次回以降にロック障害が発生した場合には、アイドル状態処理、ロック解除待機状態処理、解除起動完了状態処理、ロック継続中処理の順番に再び処理を行なうことができる。従って、ロック障害が繰り返し発生した場合にも、発生した状態に応じて徐々にセッションを強制的に開放するので、ロック障害の発生に影響していないようなセッションについては残存させることができる。
また、上記実施形態は以下のように変更してもよい。
○ 上記実施形態において、データベース管理システム41,42の制御手段は、障害発生判定時間より長い経過時間のセッションのセッション管理データがセッション記憶部に記録されていた場合には、ロック障害が発生していると判定した(ステップS1−2において「YES」)。ロック障害が発生しているとの判定は、これに限定されない。例えば、セッション記憶部に記録されたセッション管理データの総数が一定値(判定数)以上、かつすべてのセッションの経過時間が一定時間(障害発生判定時間)以上経過している場合にのみ、ロック障害が発生していると制御手段が判定してもよい。また、セッションによっては処理時間が長い場合もある。この場合には、このセッションについては経過時間が障害発生判定時間を越えてもロック障害が発生していないと判定してもよい。具体的には、処理時間が長いセッションの属性情報(例えば、セッション名やデータベース25の対象領域)を特定するデータを例外属性データ記憶手段に記録する。また、セッション記憶部には、属性情報をセッション識別子とともに記録する。そして、ロック障害が発生しているか否かを判定する場合、データベース管理システム41,42の制御手段は、まず、障害発生判定時間より長い経過時間のセッション管理データがセッション記憶部に記録されているか否かを判定する。そして、障害発生判定時間より長い経過時間のセッションがある場合には、このセッションのセッション識別子に関連付けられた属性情報をセッション記憶部から取得し、例外属性データ記憶手段と比較する。そして、制御手段は、例外属性データ記憶手段に記録されたデータでない場合には、ロック障害が発生していると判定する。これにより、処理時間が長いセッションを、ロック障害発生の対象外として予
め除外することができるので、より正確にロック障害の発生を自動的に検出することができる。また、制御手段はこの処理時間が長いセッションにロック障害が発生したことを検知する第2障害発生判定時間を記憶してもよい。第2障害発生判定時間は障害発生判定時間よりも長い。この場合、例外属性データ記憶手段に記憶された属性情報のセッションであった場合には、制御手段は、このセッションの経過時間が、第2障害発生判定時間を経過しているか否かを判定する。第2障害発生判定時間を経過している場合には、制御手段は、ロック障害の発生を検知する。この場合には、処理時間が長いセッションについてロック障害が発生した場合でも、このセッションを開放することができる。
○ 上記実施形態のデータベース管理システム41,42の制御手段は、ロック解除待機状態処理(ステップS1−5)において、最も古いセッションを開放するロック解除起動処理を実行した(ステップS3−1)。これに限らず、制御手段は、セッションの経過時間に基づいて、ロック障害の発生要因と考えられる他のセッションを開放してもよい。例えば、障害発生判定時間より長い経過時間のセッションをすべて開放してもよい。この場合、ロック継続中状態処理においては、すべてのセッションを開放する等、ロック解除待機状態処理とは異なる処理を行なう。これにより、ロック障害が継続して発生している場合には、できるだけセッションを残存させながら、段階的にセッションを開放してロック障害の解消を自動的に図ることができる。
○ 上記実施形態のデータベース管理システム41,42の制御手段は、ロック障害の発生が継続している場合には、ロック解除待機状態処理、解除起動完了状態処理及びロック継続中状態処理を順番に行なった。これに代えて、解除起動完了状態処理を省略してもよい。すなわち、ロック解除起動処理(ステップS3−1)を行なった後、次のロック監視処理が行なわれてもロック障害が発生している場合には、すぐにロック継続中状態処理を実行してもよい。この場合においても、セッションを段階的に開放することができるので、ロック障害に関係のないセッションを残存させながらロック障害の解消を自動的に図ることができる。
○ 上記実施形態のデータベース管理システム41,42の制御手段は、ロック継続中状態処理において、一定時間以上経過しているすべてのセッションの開放処理を実行した(ステップS5−1)。ロック継続中状態処理は、この処理に限られない。例えば、すべてのセッションを開放したり、他のデータベース管理システム(41,42)と連携を取りながら、ロック障害の発生原因となるセッションを開放したりしてもよい。他のデータベース管理システムと連携を取りながらセッションの開放を行なう場合には、他のデータベース管理システムは、第2のセッション管理データ記憶手段及び第2の制御手段を備える。各データベース管理システムの各セッション管理データ記憶手段には、セッション識別子に関連付けて、経過時間、ロック検出フラグ及びデータベース25の処理対象領域を特定する対象特定データを記録する。第2開放処理において、データベース管理システム41,42の制御手段は、セッション管理データ記憶手段に記録された経過時間から、一定時間(連携判定時間)以上経過しているセッションを特定する。そして、この連携判定時間以上経過しているセッションがある場合、制御手段は、このセッションの処理対象領域をセッション管理データの対象特定データから特定する。そして、制御手段は、この対象特定データと、他のセッションの対象特定データとを比較して、処理対象領域が重複するセッションのセッション管理データが、他のデータベース管理システムのセッション管理データ記憶手段に記録されているか否かを判定する。そして、該当するセッション管理データ記憶手段に記録されていた場合には、制御手段は、重複する処理対象領域のセッションとして特定された対象特定データに関連付けられた経過時間を比較する。比較した結果、経過時間が長いセッションが、内蔵するセッション管理データ記憶手段に記録されている場合には、データベース管理システムの制御手段は、このセッション識別子によって特定されるセッションを強制的に開放する連携開放処理を実行する。従って、他のデータ
ベース管理システムにおける処理状況からロック障害に関係していると判定できるセッションを開放するため、その他のロック障害の発生に関係のないセッションについては残存させることができる。
また、ロック継続中状態処理を行なう回数に応じて、開放するセッションを段階的に決定してもよい。この場合、各データベース管理システム41,42の制御手段に、ロック継続中状態処理を行なった回数を記録する回数データ記憶手段を設ける。例えば、図4に示すように、最初のロック継続中状態処理の場合(ステップS6−1)においては、一定時間以上経過しているセッションと、同じデータ領域をロックしているセッションが他のデータベース管理システムにあるか否かを判定する(ステップS6−2)。他のデータベース管理システムにある場合(ステップS6−2において「YES」の場合)には、制御手段は、記憶しているセッションの経過時間が、他のデータベース管理システムに記憶しているセッションの経過時間より長いか否かを判定する(ステップS6−3)。長い場合(ステップS6−3において「YES」の場合)には、このセッションを開放し(ステップS6−4)、回数データ記憶手段に「2」の回数を記録する(ステップS6−5)。
一方、一定時間以上経過しているセッションと重複する処理対象領域のセッションが他のデータベースシステムにない場合(ステップS6−2において「NO」の場合)には、一定時間以上経過しているすべてのセッションを開放する(ステップS6−7)。また、他のデータベース管理システムに記憶されているセッションのほうが長い場合(ステップS6−3において「NO」の場合)にも、一定時間以上経過しているすべてのセッションを開放する(ステップS6−7)。また、回数データ記憶手段に記録された回数が「2」〜「4」の場合(ステップS6−1において「NO」かつステップS6−6において「NO」の場合)にも、一定時間以上経過しているすべてのセッションを開放する(ステップS6−7)。そして、ステップS6−7を行なった場合には、制御手段は、回数データ記憶手段に記録されている回数に「1」を加算した新たな回数を算出し、この回数を新たな回数として、このデータ領域に記録する(ステップS6−8)。
その後、ロック継続中状態処理を行なった場合に、回数データ記憶手段に記録された回数が「5」以上の場合(ステップS6−6において「YES」の場合)には、すべてのセッションを開放する(ステップS6−9)。以上のようにして、段階的にセッションを開放することができるので、ロック障害に関係のないセッションを残存させながらロック障害の解消を自動的に図ることができる。
10…クライアント機器、20…処理管理システム、21…負荷分散機、25…データベース、31…第1の処理サーバ、32…第2の処理サーバ、3n…第nの処理サーバ、41…第1のデータベース管理システム、42…第2のデータベース管理システム。
特開2002−149450号公報(第4頁)

Claims (6)

  1. セッション識別子と、セッションが開始されてからの経過時間とを関連付けて記録したセッション管理データ記憶手段と、ロック検出フラグを記録するロック検出フラグ記録手段と、第1開放処理を行なったことを示す実行済フラグを記録する処理実行済フラグ記録手段と、データベースに対する処理制御を行なう制御手段とを備え、ロック障害の監視を行なうデータベース管理システムであって、
    前記制御手段が、
    セッション開始の経過時間に応じて、ロック障害の発生の有無を定期的に検出するロック障害検出手段と、
    ロック障害を検出した場合には、既にロック検出フラグが記録されているか否かを判定する手段と、
    前記ロック検出フラグが記録されていない場合には、新たにロック検出フラグを前記ロック検出フラグ記録手段に記録するロック検出フラグ記録手段と、
    前記ロック検出フラグが記録されている場合には、既に実行済フラグが記録されているか否かを判定する手段と、
    前記ロック検出フラグが記録されており、かつ前記実行済フラグが記録されていない場合には、前記セッション管理データ記憶手段に記録された前記経過時間に基づくセッションを強制的に開放する第1開放処理を実行し、前記実行済フラグを記録する第1処理実行手段と、
    前記ロック検出フラグ及び前記実行済フラグが記録されている場合には、前記第1開放処理において開放したセッションとは別のセッションを強制的に開放する第2開放処理を実行する第2処理実行手段と
    を備えたことを特徴とするデータベース管理システム。
  2. 前記セッション管理データ記憶手段は、セッション識別子に関連付けて、前記データベースの処理対象領域を特定する対象特定データを更に記憶しており、
    前記制御手段は、セッション識別子、セッションが開始されてからの経過時間、ロック検出フラグ及び前記対象特定データを関連付けて記録した第2のセッション管理データ記憶手段と、前記データベースに対して処理を行なう第2の制御手段とを備えた他のデータベース管理システムに接続されており、
    前記第2処理実行手段が、
    前記セッション管理データ記憶手段に記録された経過時間から、一定時間以上経過しているセッションを特定し、このセッションの処理対象領域と重複する処理対象領域に対して処理を行なうセッションが前記第2セッション管理データ記憶手段に記録されているか否かを判定する手段と、
    前記第2セッション管理データ記憶手段に記録されている場合には、重複する処理対象領域のセッションの経過時間を比較する手段と、
    比較した結果、経過時間が長いセッションが前記セッション管理データ記憶手段に記録されている場合には、このセッションを強制的に開放する連携開放処理を実行する手段とを更に備えたことを特徴とする請求項1に記載のデータベース管理システム。
  3. 前記第2開放処理を実行した回数を記録する回数データ記憶手段を備え、
    前記第2処理実行手段は、
    前記回数データ記憶手段に記録された回数に応じて、前記セッション管理データ記憶手段に記録されている経過時間から、段階的にセッションを強制的に開放することを特徴とする請求項1又は2に記載のデータベース管理システム。
  4. 前記第1処理実行手段は、前記セッション管理データ記憶手段に記録された経過時間のうち、最も長い経過時間のセッションを強制的に解放する第1開放処理を実行することを
    特徴とする請求項1〜3のいずれか1項に記載のデータベース管理システム。
  5. セッション識別子と、セッションが開始されてからの経過時間とを関連付けて記録したセッション管理データ記憶手段と、ロック検出フラグを記録するロック検出フラグ記録手段と、第1開放処理を行なったことを示す実行済フラグを記録する処理実行済フラグ記録手段と、データベースに対する処理制御を行なう制御手段とを備えたデータベース管理システムにおけるロック障害の監視を行なう方法であって、
    前記制御手段が、
    セッション開始の経過時間に応じて、ロック障害の発生の有無を定期的に検出するロック障害検出段階と、
    ロック障害を検出した場合には、既にロック検出フラグが記録されているか否かを判定する段階と、
    前記ロック検出フラグが記録されていない場合には、新たにロック検出フラグを前記ロック検出フラグ記録手段に記録するロック検出フラグ記録段階と、
    前記ロック検出フラグが記録されている場合には、既に実行済フラグが記録されているか否かを判定する段階と、
    前記ロック検出フラグが記録されており、かつ前記実行済フラグが記録されていない場合には、前記セッション管理データ記憶手段に記録された前記経過時間に基づくセッションを強制的に開放する第1開放処理を実行し、前記実行済フラグを記録する第1処理実行段階と、
    前記ロック検出フラグ及び前記実行済フラグが記録されている場合には、前記第1開放処理において開放したセッションとは別のセッションを強制的に開放する第2開放処理を実行する第2処理実行段階と
    を実行することを特徴とする対応するロック障害監視方法。
  6. セッション識別子と、セッションが開始されてからの経過時間とを関連付けて記録したセッション管理データ記憶手段と、ロック検出フラグを記録するロック検出フラグ記録手段と、第1開放処理を行なったことを示す実行済フラグを記録する処理実行済フラグ記録手段と、データベースに対する処理制御を行なう制御手段とを備えたデータベース管理システムにおけるロック障害の監視を行なうプログラムであって、
    前記制御手段を、
    セッション開始の経過時間に応じて、ロック障害の発生の有無を定期的に検出するロック障害検出手段、
    ロック障害を検出した場合には、既にロック検出フラグが記録されているか否かを判定する手段、
    前記ロック検出フラグが記録されていない場合には、新たにロック検出フラグを前記ロック検出フラグ記録手段に記録するロック検出フラグ記録手段、
    前記ロック検出フラグが記録されている場合には、既に実行済フラグが記録されているか否かを判定する手段、
    前記ロック検出フラグが記録されており、かつ前記実行済フラグが記録されていない場合には、前記セッション管理データ記憶手段に記録された前記経過時間に基づくセッションを強制的に開放する第1開放処理を実行し、前記実行済フラグを記録する第1処理実行手段、及び
    前記ロック検出フラグ及び前記実行済フラグが記録されている場合には、前記第1開放処理において開放したセッションとは別のセッションを強制的に開放する第2開放処理を実行する第2処理実行手段
    として機能することを特徴とするロック障害監視プログラム。
JP2009058337A 2009-03-11 2009-03-11 データベース管理システム、ロック障害監視方法及びロック障害監視プログラム Expired - Fee Related JP5332754B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2009058337A JP5332754B2 (ja) 2009-03-11 2009-03-11 データベース管理システム、ロック障害監視方法及びロック障害監視プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2009058337A JP5332754B2 (ja) 2009-03-11 2009-03-11 データベース管理システム、ロック障害監視方法及びロック障害監視プログラム

Publications (2)

Publication Number Publication Date
JP2010211616A true JP2010211616A (ja) 2010-09-24
JP5332754B2 JP5332754B2 (ja) 2013-11-06

Family

ID=42971684

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009058337A Expired - Fee Related JP5332754B2 (ja) 2009-03-11 2009-03-11 データベース管理システム、ロック障害監視方法及びロック障害監視プログラム

Country Status (1)

Country Link
JP (1) JP5332754B2 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012194895A (ja) * 2011-03-17 2012-10-11 Bank Of Tokyo-Mitsubishi Ufj Ltd トランザクション処理システム及びトランザクション処理システムの動作方法
JP2014063310A (ja) * 2012-09-20 2014-04-10 Toshiba Corp Icカード、携帯可能電子装置、及びicカード処理装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10228406A (ja) * 1997-02-13 1998-08-25 Tec Corp データベース共有システム
JP2004246439A (ja) * 2003-02-12 2004-09-02 Nec Corp クラスタシステムにおけるストール防止方式,方法およびプログラム

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10228406A (ja) * 1997-02-13 1998-08-25 Tec Corp データベース共有システム
JP2004246439A (ja) * 2003-02-12 2004-09-02 Nec Corp クラスタシステムにおけるストール防止方式,方法およびプログラム

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012194895A (ja) * 2011-03-17 2012-10-11 Bank Of Tokyo-Mitsubishi Ufj Ltd トランザクション処理システム及びトランザクション処理システムの動作方法
US8825796B2 (en) 2011-03-17 2014-09-02 The Bank Of Tokyo-Mitsubishi Ufj, Ltd. Transaction processing system and operation of the transaction process system
JP2014063310A (ja) * 2012-09-20 2014-04-10 Toshiba Corp Icカード、携帯可能電子装置、及びicカード処理装置

Also Published As

Publication number Publication date
JP5332754B2 (ja) 2013-11-06

Similar Documents

Publication Publication Date Title
US8438563B2 (en) Recording medium recording thereon virtual machine management program, management server device, and method for managing virtual machine
JP2018037752A (ja) 画像出力装置、履歴表示装置、および履歴表示プログラム
JP6150453B2 (ja) サーバ装置、システム、およびログ収集支援方法
JP2006091343A (ja) 画像処理装置および異常報知方法
JP5794690B2 (ja) 情報処理装置、情報処理方法及びプログラム
US11169896B2 (en) Information processing system
US20030072023A1 (en) Key operation monitoring method, drawing information obtaining method and key operation reproducing method in image forming apparatus
JP5332754B2 (ja) データベース管理システム、ロック障害監視方法及びロック障害監視プログラム
JP2010140111A (ja) 機器管理装置、機器管理システム、ログ管理方法、ログ管理プログラム、及びそのプログラムを記録した記録媒体
JP2006338197A (ja) トランザクション制御プログラム、トランザクション制御方法及びトランザクション処理システム
JP2002269305A (ja) ワークフロー自動監視制御方法、装置、及びプログラム
JP2016071398A (ja) テスト実行装置、テスト実行方法およびコンピュータプログラム
CN111666141A (zh) 任务调度方法、装置、设备及计算机存储介质
JP2009223743A (ja) 障害解析支援システム及び障害解析支援方法
US20080047002A1 (en) Image forming apparatus
JP2011022850A (ja) 画像処理装置、画像出力管理方法及びプログラム
EP0911734A1 (en) Virus protection in a network environment
JP5338964B1 (ja) 制御装置、画像形成システムおよびプログラム
JP5641856B2 (ja) 監視制御システム
JP6436704B2 (ja) テスト実行装置、テスト実行方法およびコンピュータプログラム
CN110808956B (zh) 一种数据交互方法及系统
JP2010244116A (ja) 履歴情報管理装置、履歴情報管理方法、及びプログラム
JP5231035B2 (ja) ジョブ処理システムおよびジョブ処理方法
JP2012181699A (ja) 障害調査情報資料採取システム、管理サーバ、障害調査情報資料採取方法およびそのプログラム
JP2020201982A (ja) 稼働管理装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20120130

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120620

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20130627

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20130702

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130715

LAPS Cancellation because of no payment of annual fees