(57)【要約】【課題】  複数システムでデータベースを同時利用する場合に発生しやすい障害としては、セッションが枯渇し新規ログイン接続エラーとなる障害が考えられる。【解決手段】  各拠点と対応付けて閾値を記憶する拠点確認マスタデータベースと、前記拠点のセッション数を記憶する監視データ記録データベースと、ユーザが前記各拠点にログインした場合に、前記監視データ記録データベースの前記拠点に対応するセッション数を追加するセッション監視機能部と、前記拠監視データ記録データベースの前記セッション数が前記閾値を超えた場合に警告を表示する状態確認機能部とを有する。【選択図】  図１
2015041306.tif 000002
【特許請求の範囲】
【請求項１】
各拠点と対応付けて閾値を記憶する拠点確認マスタデータベースと、
前記拠点のセッション数を記憶する監視データ記録データベースと、
ユーザが前記各拠点にログインした場合に、前記監視データ記録データベースの前記拠点に対応するセッション数を追加するセッション監視機能部と、
前記拠監視データ記録データベースの前記セッション数が、前記拠点確認マスタデータベースの前記閾値を超えた場合に警告を表示する状態確認機能部と
を有することを特徴とするセッション数管理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、セッションを管理する技術に関する。
【背景技術】
【０００２】
近年、データベース管理システムの高機能化、ＨＤＤの大容量化に伴い、データベースは複数のシステムからセッションを確立して利用されることが一般的になっている。このような複数のセッションを管理する技術がいくつか知られている。例えば特許文献１（特開２０１０−００４１２２号公報）では、セッションをある一定時間で自動で切ることにより無駄なセッションを省く旨について開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１０−００４１２２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
複数システムでデータベースを同時利用する場合に発生しやすい障害としては、セッションが枯渇し新規ログイン接続エラーとなる障害が考えられる。この解決方法としてデータベース管理者が不要なセッションを切断することが考えられるが、どのセッションか切断してよいセッションか判断できず対応が取れない。また、特許文献１のように時間で強制的にセッションを切断する方法ではデータベースにおいては時間の長さが必ず不要なセッションとなる訳ではなく必要なセッションを切断する可能性があり、好ましくない。本発明は効率よくセッションを管理することを目的とする。
【課題を解決するための手段】
【０００５】
上記課題を解決するために、本発明では、各拠点と対応付けて閾値を記憶する拠点確認マスタデータベースと、前記拠点のセッション数を記憶する監視データ記録データベースと、ユーザが前記各拠点にログインした場合に、前記監視データ記録データベースの前記拠点に対応するセッション数を追加するセッション監視機能部と、前記拠監視データ記録データベースの前記セッション数が前記閾値を超えた場合に警告を表示する状態確認機能部とを有する。
【発明の効果】
【０００６】
本発明によればセッション数を効率よく管理することができる。
【図面の簡単な説明】
【０００７】
【図１】本発明の一実施形態の概略システム構成図である。
【図２】拠点確認マスタデータベースを示す図である。
【図３】初期拠点レコードデータベースを示す図である。
【図４】ユーザ別監視データデータベースを示す図である。
【図５】監視データ記録データベースを示す図である。
【図６】本実施形態の処理フローチャートを示す図である。
【発明を実施するための形態】
【０００８】
以下、本発明の一実施形態を、図面を用いて説明する。本実施形態では、まず本実施形態で用いる装置について、その概略システム構成図を図１に示す。図１に示すように、複数の利用者、及び複数のシステム１１１が稼動している拠点１１０から、ネットワーク１２０を介してデータベース１３０に接続している。この時、セッション数管理装置１４０は、ネットワーク１２０を介し、データベース１３０に接続し、拠点１１０の接続情報を取得する。セッション数管理装置１４０はデータベース１３０のセッション数を管理するものである。
【０００９】
セッション数管理装置１４０は、データベースから接続されているセッション数を取得するセッション監視機能部１４１、監視情報から異常状態を判定する状態確認機能部１４２、ユーザに通知する通知機能部１４３を有し、拠点確認マスタデータベース１４５、監視データ記録データベース１４４、ユーザ別監視データデータベース１４６、初期拠点レコードデータベース１４７を保持する。
【００１０】
セッション数管理装置１４０は、データベース１３０とは異なるサーバ上で起動可能であり、一定間隔でデータベース１３０に接続し、セッション情報を取得する。セッション監視機能部１４１では、データベース１３０が保持しているセッション情報を、データベース１３０が管理しているユーザ毎の監視データとして取得する。続いて、取得したユーザ毎の監視データは、拠点確認マスタデータベース１４５と命名規則を用いて拠点ごとに分類する。
【００１１】
具体的には、各拠点に拠点文字列を設け、ユーザをその拠点文字列を含む名前で作成することで、ユーザ毎の監視データを拠点ごとに分類する。続いてユーザ別の監視データのセッション数を拠点毎に足し合わせることで、新たに拠点別の監視データとして作成する。続いて作成した拠点別の監視データを監視データ記録データベース１４４に保存する。上記の処理により、ユーザ別に取得した情報を拠点別に変換して保持することで、以降の処理で拠点別に管理することを可能とする。
【００１２】
状態確認機能部１４２では監視データ記録データベース１４４よりデータを取得し、セッションの異常判定を実施する。判定方法については特に指定はなく自由に設定してよいが、例えば、閾値を用いた判定方法や、時系列データを利用した例外判別の方法などがある。通知機能部１４３では状態確認機能部１４２の判定結果によって、警告、または復旧を通知する。次に図２〜図５の図表について説明した後、図６のフローチャートに沿って処理を説明する。
【００１３】
図２は拠点確認マスタデータベース１４５を示す図であり、拠点名、拠点文字列、拠点纏め者、閾値をカラムとして保持する。拠点名は、拠点がどこであるかを特定する情報を記憶する。拠点文字列はセッション監視機能部１４１で取得した監視データを拠点別に分類する場合に利用し、拠点纏め者は通知機能部１４３で通知先を特定するために利用する。ここで、閾値とは各拠点におけるデータベース１３０へのセッション数の上限値を特定するもので、この閾値はもとから記憶させてあるものとしても良いし、ユーザやシステムからの入力を受付けて記憶することとしてもよい。
【００１４】
図３は初期拠点レコードデータベース１４７を示す図である。初期拠点レコードデータベース１４７は拠点確認マスタデータベース１４５に登録されているレコード数分作成され、拠点文字列と監視時刻、セッション数をカラムとして保持する。拠点文字列は、拠点を特定する情報である。監視時刻はセッション監視機能部１４１で監視した時刻、セッション数は初期値０として作成される。
【００１５】
図４はユーザ別監視データデータベース１４６を示す図であり、ユーザ名、監視時刻、セッション数をカラムとして保持する。ユーザ別監視データデータベース１４６は、セッション監視機能部１４１で１度に取得できるユーザ別のセッション数の情報を示しており、ユーザ名はデータベース１３０に接続しているユーザの名前、監視時刻はセッション監視機能部１４１で監視した時刻、セッション数は監視したときのユーザのセッション数の合計を示している。
【００１６】
図５は監視データ記録データベース１４４を示す図であり、拠点別文字列、監視時刻、セッション数をカラムとして保持する。監視データ記録データベース１４４はセッション監視機能部１４１で取得した監視データを保存し、状態確認機能部１４２で利用される。監視データ記録データベース１４４の各レコードは、後述する処理フローチャート図６の監視データ加工処理ステップ２２０より、ユーザ別監視データデータベース１４６でユーザ名毎に保持されていたセッション数を、拠点文字列毎に変換して保持される。
【００１７】
図６は本実施形態の処理フローを示す図である。本処理フローではセッション数管理装置１４０の機能を一連の処理として示している。セッション監視機能部１４１は監視データ取得処理ステップ２１０から監視データ登録処理ステップ２３０までを実施し、状態確認機能部１４２は判定用データ取得処理ステップ２４０から異常判定処理ステップ２５０までを実施し、通知機能部１４３は通知確認処理ステップ２６０を実施する。特にセッション数管理装置１４０で重要な機能はセッション監視機能部１４２の監視データ加工処理ステップ２２０にあるため、詳細処理をステップ２２１からステップ２２５に分けて説明する。なお、処理フローチャート図６に示されている一連の処理は、セッション数管理装置１４０により一定間隔ごとに実行されるものとする。一定間隔の長さは、データベース管理者によって任意に設定できる。本処理フローチャート図６の詳細について以下に示す。
【００１８】
まずセッション数管理装置１４０は監視データ取得処理ステップ２１０を行う。本処理により監視対象となるデータベース１３０に接続して、ユーザ別監視データデータベース１４６を取得する。なお、データベースを利用する場合、システム毎に接続権限が割り当てられる場合が多く、セッション数管理装置１４０で監視するデータベースでも、システム毎に個別のユーザ名で権限を与えるものとする。以後の説明では、ユーザとはデータベースに接続しているシステムのことをさすものとする。監視時刻はデータベース１３０に接続した時刻、セッション数はデータベースに接続しているセッション数の総数である。ユーザ別監視データデータベース１４６には例として６ユーザのデータしか記載していないが、これに限定されるものではなく、ユーザ数は利用されている形態によって増減してもよい。
【００１９】
続いてセッション数管理装置１４０は監視データ加工処理ステップ２２０を行う。本処理は監視データ取得処理ステップ２１０で取得したユーザ別監視データデータベース１４６を、拠点確認マスタデータベース１４５を利用して監視データ記録データベース１４４に登録できるデータに加工する。具体的には、まず初期レコード作成ステップ２２１を行う。本処理では、拠点確認マスタデータベース１４５の拠点文字列を拠点確認マスタデータベース１４５のレコード分読み込み、初期拠点レコードデータベース１４７を作成する。続いて拠点別監視データ図４から監視データを１レコード読み込むステップ２２２。続いて読み込んだ１レコードのユーザ名から拠点を判別するステップ２２３。判別方法としてはユーザ名の上２桁と拠点文字列が一致するかを確認し、一致する拠点レコードのセッション数に監視レコードのセッション数を加算するステップ２２４。このように、システム１１１と拠点１１０の関連付けにユーザ名の命名規則を利用している。続いて、ユーザ別監視データデータベース１４６のうち、読み込まれていないレコードがあるかを判定し、監視レコードに次レコードがある場合には、監視データを読み込むステップ２２２処理に戻る。すべての監視レコードが読み込まれている場合は、監視データ加工処理ステップ２２０が完了する。
【００２０】
続いてセッション数管理装置１４０は監視データ登録処理ステップ２３０を行う。本処理では監視データ加工処理ステップ２２０で作成した拠点レコードを監視データ記録データベース１４４に登録する。
【００２１】
続いてセッション数管理装置１４０は判定用データ取得処理ステップ２４０を行う。本処理では、監視データ記録データベース１４４から異常判定に必要なレコードを取得する。取得するレコードは、監視時刻をキーとして監視時刻が新しいデータから監視Ｎ回分、レコード数にして’Ｎ×監視データ取得処理ステップ２１０で取得したレコード数’となる。監視Ｎ回分は、異常判定方法により異なるが、例えば閾値による異常判定を行う場合は、監視時刻が最も新しいレコードを１回分取得する。
【００２２】
続いてセッション数管理装置１４０は異常判定処理ステップ２５０を行う。本処理では、監視データを利用して各セッションに問題がないかを判定する。判定方法は、例えば閾値を用いて異常値かどうかを判定する。閾値は拠点確認マスタデータベース１４５に設定することで、各拠点別に判定を実施する。本発明では、判定方法については限定しないが、拠点別確認マスタ図２に異常判定用の項目を設定することができる。
【００２３】
続いてセッション数管理装置１４０は通知確認処理ステップ２６０を行う。本処理では、まず異常判定処理ステップ２５０の結果を保持し、通知の有無を判定する。通知は前回行われた監視の異常判定結果と今回の異常判定結果を比較し、変更があった場合のみ通知する。例えば、ある拠点の異常判定処理ステップ２５０の前回分と今回分の連続の結果が、正常、異常と変更された場合には警告を通知する。また、異常、正常となった場合には復旧を通知し、異常、異常のような場合には通知しない。判定後は関係者に通知する。通知先は、データベース管理者の他、通知が必要な拠点の拠点纏め者を拠点確認マスタデータベース１４５より取得し、通知する。本処理によって、異常発生時の拠点での迅速な障害対応を可能にする。
【００２４】
上述した監視データ取得処理ステップ２１０〜通知確認処理ステップ２６０をセッション数管理装置１４０が一定間隔で連続して実施することで、セッション数の監視と異常通知を拠点別に実施することができる。その結果、異常発生時には拠点纏め者まですばやく通知することができ、データベース管理者の運用工数を削減できる。
【００２５】
次にセッション数管理装置１４０を用いてデータベースのセッション数を監視する方法の具体例を、図２〜図５のデータを利用して説明する。
【００２６】
ここでは、データベースに接続している拠点は拠点確認マスタデータベース１４５の拠点名にある’東京拠点’、’神奈川拠点’、’愛知拠点’、’北海道拠点’とし、’２０１３／３／１の１５：００’に監視された場合の例について処理フローチャート図６の一連の動作を説明するものとする。ただし、’２０１３／３／１の１５：００’に監視される前より、既に監視が実施されており、一度前に行われた一連の処理では、監視対象のデータベースには特に異常がみられなかったこととする。また異常判定方法としては閾値による判定を利用し、閾値は拠点確認マスタデータベース１４５の閾値に設定したものを利用するものとする。更に監視対象のデータベース１３０はオラクルデータベースを利用しているものとする。以下に具体例を示す。
【００２７】
まず監視データ取得処理ステップ２１０では時刻が’２０１３／３／１  １５：００’となった時、ネットワークを介してオラクルデータベースに接続し、動的パフォーマンスビューであるＶ＄ＳＥＳＳＩＯＮからＵＳＥＲＮＡＭＥとＵＳＥＲＮＡＭＥのレコード数を取得する。取得したＵＳＥＲＮＡＭＥとＵＳＥＲＮＡＭＥレコード数は、それぞれユーザ名とセッション数としてユーザ別監視データデータベース１４６に保持する。
【００２８】
続いて監視データ加工処理ステップ２２０では、まず初期拠点レコードデータベースを作成する。本処理では、拠点確認マスタデータベース１４５の拠点文字列を読み込み、初期拠点レコードデータベース１４７として読み込んだ拠点文字列をもつレコードをそれぞれ作成する。監視時刻は’２０１３／３／１  １５：００’、セッション数は’０’とする。続いてユーザ別監視データデータベース１４６の１レコード目を読み込む。１レコード目のユーザ名は’ＴＯ＿ＢＰＲ’であり、上２桁が初期拠点レコードデータベース１４７の拠点文字列が’ＴＯ’となるレコードに一致する。よって１レコード目のセッション数である’２７’を拠点文字列が’ＴＯ’となる拠点レコードのセッション数に加算する。続いて、残りの監視レコードを確認し、順に２レコード目から６レコード目まで読み込み、対応する拠点文字列をもつ拠点レコードにセッション数を加算する。
【００２９】
続いて監視データ登録処理ステップ２３０では、監視データ加工処理ステップ２２０で作成された拠点レコードをセッション数管理装置１４０で保持しているデータベースにある監視データ記録データベース１４４に保存する。
【００３０】
続いて判定用データ取得処理ステップ２４０では、監視データ記録データベース１４４から監視時刻をキーにして、最新の監視データとなる監視時刻が’  ２０１３／３／１  １５：００’のレコードを取得する。
【００３１】
続いて異常判定処理ステップ２５０では、判定用データ取得処理ステップ２４０で取得した計４レコードに対してそれぞれ異常判定を実施する。まず拠点別文字列’ＴＯ’のレコードを取り出し、拠点確認マスタデータベース１４５の拠点文字列が’ＴＯ’となるレコードの閾値と、セッション数の比較を行う。拠点別文字列’ＴＯ’のセッション数は’４９’、閾値は’４５’でありセッション数が閾値より高いため、拠点文字列’ＴＯ’は異常と判定する。同様に、拠点文字列が’ＫＡ’、’ＡＩ’、’ＨＯ’のレコードのセッション数も拠点確認マスタデータベース１４５の閾値と比較を実施すると、拠点文字列が’ＫＡ’の場合、セッション数が’３６’、閾値が’４０’になり、セッション数のほうが低いため正常となる。拠点文字列が’ＡＩ’の場合、セッション数が’２１’、閾値が’３０’のため正常、拠点文字列が’ＨＯ’の場合、セッション数が’５’、閾値が’３０’のため正常となる。
【００３２】
続いて通知確認処理ステップ２６０では、異常判定処理ステップ２５０の結果から通知の有無を判定する。前回の結果はすべて正常として今回の結果と比較すると、拠点文字列が’ＫＡ’の場合、今回の結果が異常であるため、通知が必要になる。その他の拠点文字列はそれぞれ今回の結果が正常であるため、通知は行われない。通知は、拠点確認マスタデータベース１４５より拠点文字列が’ＫＡ’となるレコードの拠点纏め者’ＡＡＡＡＡＡＡ’とデータベース管理者に対して、拠点名’東京拠点’のセッション数に異常が発生したことを通知する。
【符号の説明】
【００３３】
１１０：拠点、１１１：システム、１２０：ネットワーク、１３０：データベース、１４０：セッション数管理装置、１４１：セッション監視機能部、１４２状態確認機能部、１４３：通知機能部、１４４：監視データ記録データベース、１４５：拠点確認マスタデータベース
【図１】
2015041306.tif 000003
【図２】
2015041306.tif 000004
【図３】
2015041306.tif 000005
【図４】
2015041306.tif 000006
【図５】
2015041306.tif 000007
【図６】
2015041306.tif 000008