JP5982940B2 - 管理プログラム、管理装置および情報処理システム - Google Patents

Description

本発明は、データベースの管理技術に関する。

従来、異なる複数のデータベース（以下、ＤＢと記載する）を統合して、１つのデータベースとして管理する技術がある。例えば、複数のＤＢ−１〜ＤＢ−３に記憶された、システムの構成情報を統合して、システム全体の構成を管理するためのＣＭＤＢ（Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｍａｎａｇｅｍｅｎｔ Ｄａｔａｂａｓｅ）を構築する技術が存在する。

ＣＭＤＢは、各データベースで保持している情報を統合する際に、構成情報の同一性を判定し、同一とみなした構成情報をマージする機能（リコンシエーション機能）を持っている。データの同一性は、統合対象のデータベース間で共通に保持している情報の中から、データの同一性を判定するためのキーとなるデータを事前に設定し、キーとして設定されたデータ（もしくはそれに基づいて生成したハッシュ値など）が一致するかどうかで判定する。

ここで、図２１を用いて、ＣＭＤＢにおける統合処理について説明する。図２１は、ＤＢ−１、ＤＢ−２、ＤＢ−３の３つのＤＢを統合してＣＭＤＢを構築する例を示す。ＤＢ−１には、「ＮＯＤＥ＿Ａ」という装置のＩＰ＝「１９２．１６８．０．１」、ＮＡＭＥ＝「ｎａｍｅ＿ＸＸＸ」という情報が記憶されている。また、ＤＢ−２には、「Ｓｅｒｖｅｒ＿１」という装置のＩＤ＝「１９２．１６８．０．１」、ＨＤＤ＝「Ｄｉｓｋ＿ａｂｃ」という情報が記憶されている。また、ＤＢ−３には、「ＨＯＳＴ＿Ｘ」という装置のＩＰ＿ＡＤＤＲ＝「１９２．１６８．０．１」、ＣＰＵ＿ＩＮＦＯ＝「ＣＰＵ＿Ａ」という情報が記憶されている。

しかし、ＤＢ−１、ＤＢ−２、ＤＢ−３のそれぞれが独自のデータ形式で記憶しているが、例えば、「１９２．１６８．０．１」というデータは、ＤＢ−１、ＤＢ−２、ＤＢ−３で共通するデータである。このような場合、「ＮＯＤＥ＿Ａ」、「Ｓｅｒｖｅｒ＿１」、「ＨＯＳＴ＿Ｘ」が同一の装置を示すと判断できる。したがって、ＤＢ−１、ＤＢ−２、ＤＢ−３が記憶するデータを、ＤＢ−１、ＤＢ−２、ＤＢ−３のそれぞれ独自のデータ形式から、共通のデータ形式に変換し、ｉｐＡｄｄｒｅｓｓ属性を統合用のキーとすることで、ＣＭＤＢに統合する。このようにして、ｉｐＡｄｄｒｅｓｓ＝「１９２．１６８．０．１」である装置（図２１では「ＳＥＲＶＥＲ＿ＸＸＸ」と記載している）に関するＮａｍｅ＝「ｎａｍｅ＿ＸＸＸ」、ＣＰＵ＝「ＣＰＵ＿Ａ」、Ｄｉｓｋ＝「Ｄｉｓｋ＿ａｂｃ」という情報が、ＣＭＤＢから取得可能となる。

特開２０１１−１３３９８５

ＣＭＤＢとして統合されるそれぞれのＤＢは、ＤＢ毎にそれぞれ格納する構成情報の更新を行っており、更新により変更があった部分のデータ（変更データ）をそれぞれの送信周期でＣＭＤＢに与えているため、ＣＭＤＢにおいて統合する対象のデータの新旧に大きな時間的ずれが生ずることがある。例えば、図２１のＤＢ−１は、１分に一度といった頻度で変更データを送信するのに対して、ＤＢ−２、３は、１日に一度といった頻度で変更データを送信することがある。

このような状態でＣＭＤＢにおいてデータの統合処理を行うと、あるＤＢからは変更を反映済みの構成情報を既に取得しているものの、他のＤＢからはまだ変更を反映済みの構成情報を取得しておらず、新旧混じった統合データとなってしまうことがある。そして、このような整合性のない統合データに基づいてシステム設定などを実行すると、システムの構成要素として実行されるアプリケーションが誤作動してしまうおそれもある。

１つの側面では、本発明は、複数のＤＢが統合されるＣＭＤＢに含まれるデータに不整合が生ずることを抑止することを目的とする。

１つの案では、管理装置に、複数のデータベースの中から、データベースに記憶された統合対象のデータの更新頻度が最も高いデータベースを特定し、特定したデータベースからの更新データの取得に応じて、複数のデータベースのうちの、特定したデータベース以外のデータベースに記憶された情報を管理装置に送信させる要求を、特定したデータベース以外のデータベースに対して送信し、特定したデータベース以外のデータベースが要求に応じて管理装置に送信した情報に基づいて、前記統合対象のデータを更新する、ことを実行させる。

本発明の一態様によれば、複数のＤＢが統合されるＣＭＤＢに含まれるデータに不整合が生ずることを抑止することができる。

本発明を実施する実施例について、図面を参照して説明する。

本実施例は、例えば、図１に示すＤＢシステム１００において実現することが可能である。図１に示すＤＢシステム１００は、複数のＤＢを統合したＣＭＤＢ管理装置１０１と、ＣＭＤＢ管理装置１０１によって統合される対象のＤＢであるＤＢ管理装置１０２（１）〜１０２（３）を備え、それぞれはネットワーク１１０を介して相互に通信可能に接続されている。ＣＭＤＢ管理装置１０１、ＤＢ管理装置１０２（１）〜１０２（３）はそれぞれが、データを記憶するサーバ装置であっても良い。ＤＢ管理装置１０２（１）〜１０２（３）は、例えば図１のＤＢ管理装置１０２（３）のように、ＤＢ管理装置１０２（３）と接続された記憶装置１０３にデータを記憶することとしても良い。また、例えば、ＤＢ管理装置１０２（１）〜１０２（３）が１つのサーバ装置で実現されることとしても良い。本実施例においては、ＤＢシステム１００が有するＤＢ管理装置は、ＤＢ管理装置１０２（１）〜１０２（３）の３つであるが、ＤＢ管理装置およびＤＢ管理装置により実現されるＤＢの数は、この数に限定されない。

図２は、ＣＭＤＢ管理装置１０１のハードウェア構成図を示す。ＣＭＤＢ管理装置１０１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２０１、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２０２、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）２０３、ドライブ２０４、アダプタ２０６を備え、それぞれはバスによって相互に通信可能に接続されている。ＣＰＵ２０１は、ＣＭＤＢ管理装置１０１が実行する演算処理などを実行する。ＲＡＭ２０２は、例えば、ＣＰＵ２０１が実行する演算処理に用いられるデータがロードされる。ＨＤＤ２０３は、ＣＭＤＢ管理装置１０１がＤＢとして記憶する情報が記憶される。また、ＨＤＤ２０３は、例えば半導体記憶装置や、磁気テープ記憶装置などの、ＨＤＤ以外の記憶装置であっても構わない。ドライブ２０４は、例えばディスクＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２０５に記憶された情報を読み込み、ＲＡＭ２０２にロードすることが可能な読み取り装置である。アダプタ２０６は、ＣＭＤＢ管理装置１０１をネットワーク１１０に接続するための接続機器である。

図３に、ＤＢ管理装置１０２（１）のハードウェア構成図を示す。ＤＢ管理装置１０２（１）は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）３０１、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）３０２、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）３０３、ドライブ３０４、アダプタ３０６を備え、それぞれはバスによって相互に通信可能に接続されている。ＣＰＵ３０１は、ＤＢ管理装置１０２（１）が実行する演算処理を実行する。ＲＡＭ３０２は、例えば、ＣＰＵ３０１が実行する演算処理に用いられるデータがロードされる。ＨＤＤ３０３は、ＤＢ管理装置１０２（１）がＤＢとして記憶する情報が記憶される。また、ＨＤＤ３０３は、例えば半導体記憶装置や、磁気テープ記憶装置など、ＨＤＤ以外の記憶装置であっても構わない。ドライブ３０４は、例えばディスクＲＯＭ３０５に記憶された情報を読み込み、ＲＡＭ３０２にロードすることが可能な読み取り装置である。アダプタ３０６は、ＤＢ管理装置１０２（１）をネットワーク１１０に接続するための接続機器である。尚、ＤＢ管理装置１０２（２）、１０２（３）のハードウェア構成については、図３に示すＤＢ管理装置１０２（１）のハードウェア構成と同様の構成としてもよい。

図４は、ＣＭＤＢ管理装置１０１の機能ブロック図を示す。ＣＭＤＢ管理装置１０１は、通信制御部４０１、決定部４０２、データ更新部４０３、更新管理部４０４、判定部４０５、収集依頼部４０６を有する。また、ＣＭＤＢ管理装置１０１は、ＤＢ情報記憶部４１１、管理情報記憶部４１２、更新情報記憶部４１３、マスタＤＢ情報記憶部４１４、閾値情報記憶部４１５を有する。

通信制御部４０１、決定部４０２、データ更新部４０３、更新管理部４０４、判定部４０５、収集依頼部４０６は、例えば、ＣＰＵ２０１が、ＨＤＤ２０３に記憶されたプログラムを実行することにより実現されても良い。あるいは、ＣＰＵ２０１が実行するプログラムは、ディスクＲＯＭ２０５に記憶され、ドライブ２０４によって読み込まれることとしても良い。また、ＤＢ情報記憶部４１１、管理情報記憶部４１２、更新情報記憶部４１３、マスタＤＢ情報記憶部４１４、閾値情報記憶部４１５は、ＨＤＤ２０３やＲＡＭ２０２を用いて実現されても良い。

ここで、ＤＢ情報記憶部４１１の記憶内容について更に詳細に説明する。ＣＭＤＢ管理装置１０１は、統合する対象のＤＢとして、ＤＢ管理装置１０２（１）〜１０２（３）が管理する３つのＤＢを識別する情報を記憶している。例えば、ＣＭＤＢ管理装置１０１は、図５に示すようなＤＢ管理情報６００をＤＢ管理情報記憶部４１１に記憶する。

図５に示すＤＢ管理情報６００は、ＤＢ識別子６０１、接続先情報６０２、ＤＢ名６０３の情報を含む。

ＤＢ識別子６０１は、ＤＢ管理装置１０２（１）〜１０２（３）のそれぞれを識別する識別子である。図５においては、ＤＢ管理装置１０２（１）の識別子を「ＤＢ管理装置１０２（１）」、ＤＢ管理装置１０２（２）の識別子を「ＤＢ管理装置１０２（２）」、ＤＢ管理装置１０２（３）の識別子を「ＤＢ管理装置１０２（３）」と記載している。ＤＢ識別子６０１として他にも、ＷＷＮ（Ｗｏｒｌｄ Ｗｉｄｅ Ｎａｍｅ）や、ＤＢシステム１００の管理者が予め設定した識別番号などを用いても良い。

接続先情報６０２は、ＣＭＤＢ管理装置１０１がＤＢ管理装置１０２（１）〜１０２（３）のそれぞれに接続する際の接続先を特定する情報である。接続先情報６０２は、図５に示すように、「ホスト名＝Ｈｏｓｔ＿１」といったホスト名、「サーバ名＝Ｓｅｒｖｅｒ＿１」といったサーバ名、「ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレス＝１９２．１６８．０．３」といったＩＰアドレスなどで示されても良い。

ＤＢ名６０３は、ＤＢ管理装置１０２（１）〜１０２（３）のそれぞれに設定された名前を示す情報である。ＤＢ名６０３は、例えばＤＢシステム１００の管理者によってＤＢ管理装置１０２（１）〜１０２（３）のそれぞれに割り当てられた名前であっても良い。本実施例においては、ＤＢシステム１００の管理者によってＤＢ管理装置１０２（１）に「サーバ管理ＤＢ」、ＤＢ管理装置１０２（２）に「ストレージ管理ＤＢ」、ＤＢ管理装置１０２（３）に「ネットワーク管理ＤＢ」というＤＢ名６０３が割り当てられることとする。

図５のＤＢ情報の一例を挙げて説明すると、ＣＭＤＢ管理装置１０１は、ＤＢ情報６１０から、統合対象のＤＢの識別子としてＤＢ管理装置１０２（１）が含まれ、その接続先情報は、「Ｈｏｓｔ＿１」、そのＤＢ名は、「サーバ管理ＤＢ」であることを特定することができる。

次に、管理情報記憶部４１２の記憶内容について詳細に説明する。

図６は、管理情報記憶部４１２の記憶内容の一例であり、どのデータとどのデータとが統合されるべきかを定義している。ＣＭＤＢ管理装置１０１は、管理情報７００に基づいてＤＢ管理装置１０２（１）〜１０２（３）に記憶された情報の統合を行うことができる。

この例では、管理情報７００は、ＧＩＤ（Ｇｌｏｂａｌ Ｉｄｅｎｔｉｆｉｅｒ）７０１、データ種別７０２、ＤＢ識別子７０３、ＬＩＤ（Ｌｏｃａｌ Ｉｄｅｎｔｉｆｉｅｒ）７０４、属性情報７０５を含む。

ＧＩＤ７０１は、ＣＭＤＢ管理装置１０１において、データを一意に識別するための識別子である。

データ種別７０２は、データが何に関する情報であるかを特定する情報である。

ＤＢ識別子７０３は、ＤＢ管理装置１０２（１）〜１０２（３）を識別する識別子である。ＤＢ識別子７０３についての説明は、前述したＤＢ識別子６０１と同様であってよい。

ＬＩＤ７０４は、ＤＢ管理装置１０２（１）〜１０２（３）のそれぞれにおいて、データを一意に識別するための識別子である。

属性情報７０５は、ＤＢ管理装置１０２（１）〜１０２（３）に記憶された情報のうち、データを統合するキーとして用いられる情報を示している。例えば、図６の場合、管理情報７１０により特定される、ＤＢ管理装置１０２（１）のＬＩＤ＿１のデータと、管理情報７１１により特定される、ＤＢ管理装置１０２（２）のＳＶＲ＿１のデータとが、属性情報７０５のＩＰアドレス＝１９２．１６８．１．１をキーとして統合されることが示されている。また、管理情報７１２により特定される、ＤＢ管理装置１０２（１）のＬＩＤ＿２のデータと、管理情報７１３により特定される、ＤＢ管理装置１０２（２）のＤＩＳＫ＿１のデータとが、属性情報７０５のＩＤ＝ＤＩＳＫ＿１をキーとして統合されることが示されている。

また、ＣＭＤＢ管理装置１０１は、図７に示すような更新情報８００を更新情報記憶部４１３に記憶することができる。

図７は、ＤＢ管理装置１０２（１）〜１０２（３）のそれぞれの、記憶されたデータの更新に関する更新情報８００の一例を示す。更新情報８００は、例えば、ＤＢ識別子８０１、データ種別８０２、更新回数８０３、更新日時８０４、前回更新日時８０５、平均更新間隔８０６を含む。

ＤＢ識別子８０１は、ＤＢを識別する識別子である。ＤＢ識別子８０１についての説明は、前述したＤＢ識別子６０１と同様であってもよい。データ種別８０２は、データの種別を特定する情報である。更新回数８０３は、データがＣＭＤＢに更新された累計の回数を示す情報である。更新日時８０４は、最も新しい更新が行われた日時を特定する情報である。前回更新日時８０５は、更新日時８０４の日時に実行された更新の１つ前の更新が実行された日時を特定する情報である。平均更新間隔８０６は、これまでの更新実績に基づいて算出される更新頻度の指標である。

本実施例では、ＤＢシステム１００が備えるＤＢ管理装置１０２（１）〜１０２（３）のそれぞれについての更新頻度に基づいて、更新頻度が最も高いＤＢ管理装置１０２を特定する。そこで、本実施例では、更新情報記憶部４１３が記憶する更新情報を利用する。

ＣＭＤＢ管理装置１０１の決定部４０２は、更新情報８００に基づいて、ＧＩＤ７０１およびデータ種別７０２ごとに、更新頻度が最も高いデータが記憶されているＤＢを特定する。

まず、決定部４０２は、図６の管理情報を参照して、ＧＩＤ＿１に対応するデータ種別及びＤＢ識別子を検出する。この例では、ＣＭＤＢ管理装置１０１は、ＧＩＤ＿１に対応するデータ種別はサーバであり、ＤＢ識別子は、ＤＢ管理装置１０２（１）、ＤＢ１０２（２）の２つであることを検出する。

そして、決定部４０２は、図７の更新情報を参照して、ＤＢ識別子がＤＢ管理装置１０２（１）、または１０２（２）であって、データ種別がサーバであるものの平均更新間隔を求める。この例では、「８１秒」、「４８５秒」を取得する。

また、決定部４０２は、同様にして、ＧＩＤ＿２について、平均更新間隔「９１秒」、「５３５秒」を取得する。

そして、決定部４０２は、取得した平均更新間隔に基づいて、最も更新頻度が高いＤＢを決定する。この場合では、ＧＩＤ＿１については、「８１秒」、「４８５秒」のうち最小の値を持つ「８１秒」に対応するＤＢ管理装置１０２（１）を特定する（マスタＤＢとして特定する）。

また、ＧＩＤ＿２については、「９１秒」、「５３５秒」のうち最小の値を持つ「９１秒」に対応する１０２（１）をマスタＤＢとして特定する。

ここで、マスタＤＢの選定基準として更に、更新間隔がある所定の基準よりも短いことを条件に加えてもよい。更新間隔が長い場合にまで後述する処理を行うことによってリアルタイム性を求める処理を行うことを抑制することもできる。この場合、決定部４０２は、閾値情報記憶部４１５に記憶された所定の閾値を参照し、平均更新間隔がその所定の閾値よりも短いことを更に条件に加えてマスタＤＢに決定することとしても良い。なお、更新回数を閾値に加えることで、ある程度更新が行われて安定した状況下で平均更新間隔を用いた閾値判定を行うことができる。

図８は、閾値情報記憶部４１５に記憶される閾値情報１０００のデータ構造の一例を示す。閾値情報１０００は、例えば、データ種別に、更新回数、平均更新間隔が対応付けられたデータテーブルであって良い。例えば、閾値情報１０００は、データ種別がサーバのデータの閾値として、更新回数が１００回以上、平均更新間隔が１２０秒以内と設定されていることを示す。閾値情報１０００に基づいてマスタＤＢを決定する場合、決定部４０２は、最も更新頻度が高いＤＢの更新間隔が閾値より短い場合に、マスタＤＢに決定することとしても良い。また、決定部４０２は、最も更新頻度が高いＤＢの更新回数が閾値を上回りかつ、更新間隔が閾値より短い場合に、そのＤＢをマスタＤＢに決定し、マスタＤＢ情報記憶部４１４に記憶することもできる。

先の例では、更新情報８１０に対応する閾値は、更新回数１００回、平均更新間隔１２０秒である。更新情報８１０より、ＤＢ管理装置１０２（１）のサーバ情報の更新回数は４４４回であり、閾値の１００回を越えているまた、ＤＢ管理装置１０２（１）のサーバ情報の平均更新間隔は８１秒であり、閾値の１２０秒を下回る。したがって、閾値情報１０１０に設定された閾値を用いた条件を満たすので、ＤＢ管理装置１０２（１）をマスタＤＢに決定し、マスタＤＢ情報記憶部４１４に記憶する。例えば、マスタＤＢ情報記憶部４１４に記憶されるデータは、図９に示すようなマスタＤＢ情報９００であって良い。

尚、本実施例において、上記のような決定部４０２が実行する処理は、例えば定期的に実行され、ＤＢ管理装置１０２（１）〜１０２（３）に記憶されるデータそれぞれの更新頻度の変化に応じて、動的に決定されることとしても良い。

図１０は、ＤＢ管理装置１０２（１）の機能ブロック図を示す。ＤＢ管理装置１０２（１）は、通信制御部５０１、収集部５０２、依頼部５０３、更新部５０４、ＤＢアクセス部５０５を有する。また、ＤＢ管理装置１０２（１）は、収集情報記憶部５１１、ＤＢ５２０を有する。

通信制御部５０１、収集部５０２、依頼部５０３、更新部５０４、ＤＢアクセス部５０５は、例えば、ＣＰＵ３０１が、ＨＤＤ３０３に記憶されたプログラムを実行することにより実現されても良い。あるいは、ＣＰＵ３０１が実行するプログラムは、ディスクＲＯＭ３０５に記憶され、ドライブ３０４によって読み込まれることとしても良い。また、収集情報記憶部５１１、ＤＢ５２０は、ＨＤＤ３０３やＲＡＭ３０２を用いて実現されても良い。また、ＤＢ５２０は、図１の記憶装置１０３のような、ＤＢ管理装置と接続された記憶装置を用いて実現されても良い。その場合、ＤＢ管理装置１０２（１）は、ＤＢアクセス部５０５や通信制御部５０１を介して、ＤＢ管理装置と接続された記憶装置にアクセスすることとしても良い。尚、ＤＢ管理装置１０２（２）、１０２（３）の有する機能部、記憶部については、図１０に示すＤＢ管理装置１０２（１）と同様の機能構成としてもよい。

次に、本実施例のＣＭＤＢ管理装置１０１が実行する処理について説明する。図１１は、ＣＭＤＢ管理装置１０１が実行する処理の手順を示すフローチャートである。

まず、ＣＭＤＢ管理装置１０１は、ＤＢ管理装置１０２（１）〜１０２（３）がそれぞれの周期（タイミング）で送信した更新依頼を、送通信制御部４０１で受信する（Ｓ１１０１）。送受信部が受信した更新依頼に基づいて、データ更新部４０３は管理情報７００を更新する（Ｓ１１０２）。

ステップＳ１１０２の処理の実行後、更新管理部４０４は、更新情報８００を更新する（Ｓ１１０３）。

ステップＳ１１０３の処理を実行後、判定部４０５は、更新依頼を送信したＤＢが、マスタＤＢとして決定されたＤＢであるかを判定する（Ｓ１１０４）。例えば、マスタＤＢ情報記憶部４１４に記憶された図９のマスタＤＢ情報９００に含まれるＤＢ識別子９０２を参照し、更新依頼を送信したＤＢのＤＢ識別子が、ＤＢ識別子９０２と一致する場合、判定部４０５は、更新依頼を送信したＤＢがマスタＤＢであると判定する。尚、このステップＳ１１０４において、前述したマスタＤＢを決定する処理を決定部４０２が実行するようにすることもできる。更新依頼を送信したＤＢがマスタＤＢではないと判定部４０５が判定した場合、ＣＭＤＢ管理装置１０１は、図１１に示す更新処理を終了する。

一方、ステップＳ１１０４で、更新依頼を送信したＤＢがマスタＤＢであると判定部４０５が判定した場合、判定部４０５は、ステップＳ１１０１で通信制御部４０１が受信した更新依頼情報の中に、削除を依頼するデータが存在するかを判定する（Ｓ１１０５）。受信した更新依頼情報の中に、削除を依頼するデータが存在すると判定部４０５が判定した場合、データ更新部４０３は、削除依頼のデータと統合されているデータを管理情報７００から削除する（Ｓ１１０６）。具体的には、データ更新部４０３は、削除対象のＧＩＤについてのデータを削除する。データの削除を実行後、ステップＳ１１０７の処理を実行する。

一方、ステップＳ１１０５で受信した更新依頼情報の中に、削除を依頼するデータが存在しないと判定部４０５が判定した場合、データ更新部４０３はステップＳ１１０６の処理を実行せずに、ステップＳ１１０７の処理に移る。

ステップＳ１１０７において、収集依頼部４０６は、マスタＤＢ以外のＤＢ管理装置に対して、データの収集依頼を送信することで、最も更新頻度の高いＤＢに合わせて他のＤＢの更新も行うようにする。なお、Ｓ１１０６で削除を行う場合には、マスタＤＢ以外のＤＢ管理装置に対して、削除したＧＩＤに対応するＬＩＤを含む抑止依頼を、対応するＤＢ管理装置に送信することで、最新の情報では既に削除済みの構成についてＣＭＤＢ管理装置１０１にそのＧＩＤに関する不要な変更データが送信されないようにすることができる。

以上のように、ＣＭＤＢ管理装置１０１は、マスタＤＢからＣＭＤＢに対する更新依頼の受信に応じて他のＤＢに対して更新すべきデータの収集を行うため、更新依頼の送信周期が異なる複数のＤＢについてのデータ統合処理を行っても更新の遅れによるデータ不整合の発生を抑制することができる。

以上が統合処理の流れであるが、ここで、前述したステップＳ１１０１、Ｓ１１０２の処理について、更に処理の例を示しておく。

図１２は、更新依頼の際に、各ＤＢ管理装置がＣＭＤＢ管理装置１０１に送信する更新依頼情報を示す。この例では、ＤＢ管理装置１０２（３）が更新依頼情報１２１０を送信し、ＤＢ管理装置１０２（１）が更新依頼情報１２１１を送信し、更に、ＤＢ管理装置１０２（１）が更新依頼情報１２１１を順に送信する場合の更新情報をそれぞれ示している。

更新依頼情報は、ＤＢ識別子１２０１、更新種別１２０２、データ種別１２０３、ＬＩＤ１２０４、属性情報１２０５を含んでもよい。ＤＢ識別子１２０１、データ種別１２０３、ＬＩＤ１２０４、属性情報１２０５の説明については、前述したＤＢ識別子６０１、データ種別７０２、ＬＩＤ７０４、属性情報７０５と同様としてもよい。

更新種別１２０２は、更新の内容を示す情報である。更新種別について詳細を説明すると、「登録」は、ＣＭＤＢ管理装置１０１および管理情報７００に、新たな情報を追加することを示す更新種別である。「更新」は、ＣＭＤＢ管理装置１０１に登録されたデータを更新することを示す更新種別である。「削除」は、ＣＭＤＢ管理装置１０１に登録されたデータを削除することを示す更新種別である。例えば、更新依頼情報１２１０の場合、ＤＢ管理装置１０２（３）に記憶された、Ｈｏｓｔ＿Ａで特定されるデータを、ＩＰアドレス＝「１９２．１６８．１．１」をキーとして統合する（登録する）ことを依頼していることとなる。

例えば、ステップＳ１１０１で、通信制御部４０１が図１２の更新情報１２１０を受信した場合、データ更新部４０３は、管理情報７００を参照し、属性情報７０５がＩＰアドレス＝「１９２．１６８．１．１」であるＧＩＤ＿１のデータ管理情報７１０、７１１に、ＤＢ管理装置１０２（３）のＨｏｓｔ＿Ａで特定されるデータを統合する。この処理を実行した後の管理テーブルの例を図１３に示す。図１３に示すように、管理情報７００ｂには、ＧＩＤ＿１について、管理情報７１５が新たに追加されていることが分かる。

次に、ステップＳ１１０３の処理の例を説明する。前述のように、ステップＳ１１０３において、更新管理部４０４は、更新情報８００に記憶された情報を更新する。

具体的には、更新管理部４０４は、更新情報記憶部４１３に記憶された更新情報８００に対して以下の処理を実行する。
・ＤＢ識別子８０１とデータ種別８０２に情報が記憶されていない場合、ＤＢ識別子とデータ種別を記憶する。
・更新回数８０３の値を更新する。
・更新日時８０４に記憶されている情報で、前回更新日時８０５を更新する。
・更新日時８０４として現在の日時を記憶する。
・平均更新間隔を再計算し、算出した値を平均更新間隔８０６に記憶する。例えば、「｛現在の平均更新間隔×（更新回数−１）＋（更新日時−前回更新日時）｝÷（更新回数）」を平均更新間隔とする。

具体例を挙げて説明すると、例えば、図１２の更新依頼情報１２１０を受信した場合、ＤＢ識別子＝ＤＢ管理装置１０２（３）、データ種別＝サーバであるので、対応する更新情報は、更新情報８１５である。したがって更新管理部４０４は、更新情報８１５に含まれる更新回数８０３の値を「８」から「９」にインクリメントする。また、更新日時８０４に記憶される「２０１２／０１／２３ ０９：００：５６」の日時を、前回更新日時８０５に記憶する。また、更新日時８０４には、現在の日時を記憶する。例えば、現在の日時「２０１２／０１／２３ １０：００：５６」として、この値を更新日時８０４に記憶する。さらに、平均更新間隔を算出し、平均更新間隔の値を更新する。この場合、平均更新間隔は、｛４０５０×（９−１）＋（１３２７２８０４５６−１３２７２７６８５６）｝÷９＝（３２４００＋３６００）÷９＝４０００（秒）である。

尚、１３２７２８０４５６の値は、「２０１２／０１／２３ １０：００：５６」の日時を、エポック秒と呼ばれる「１９７０／０１／０１ ００：００：００」からの経過秒数に変換した値である。また、１３２７２７６８５６の値は、「２０１２／０１／２３ ０９：００：５６」の日時を、エポック秒に変換した値である。説明のために、図面においては、「２０１２／０１／２３ ０９：００：５６」のように、日付と時刻を用いて更新日時８０４を示しているが、更新日時８０４は、エポック秒のデータ形式で記憶されても良い。

以上の処理により更新を実行した後の更新情報の例を図１４に示す。図１４を参照すると、更新情報８００ｂの更新情報８１５が更新情報８１５ｂのように更新されていることが分かる。

最後に図１１のステップＳ１１０７の処理の例について説明する。まず、収集依頼部４０６は、更新を行った対象のＧＩＤに対応するＤＢ識別子とＬＩＤとを図６に示す管理情報７００を参照して求める。例えば、更新が、図１２の更新依頼情報１２１１に基づくものであった場合、更新の対象は、ＤＢ識別子がＤＢ管理装置１０２（１）、かつ、属性情報がＩＰ＝１９２．１６８．１．１で、データ種別がサーバであるＧＩＤ＿１である。このため、収集依頼部４０６は、図６に示す管理情報を参照して、ＧＩＤがＧＩＤ＿１であって、データ種別がサーバである他のＤＢ識別子と、ＬＩＤを取得する。すなわち、収集依頼部４０６は、ＤＢ管理装置１０２（２）、ＳＶＲ＿１を取得する。

そして、取得したＤＢ管理装置１０２（２）に対応する接続先情報を図５に示すＤＢ情報を参照して求める。この例では、Ｓｅｒｖｅｒ＿１が宛先として求まる。

従って、収集依頼部４０６は、図１５に示すような、収集依頼情報１５００を生成し、Ｓｅｒｖｅｒ＿１宛に収集依頼情報を送信する。なお、Ｓｅｒｖｅｒ＿１のアドレスは、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）サーバなどにアクセスすることで取得してもよいし、図５の宛先情報をＩＰアドレスとしておくことでＤＮＳサーバなどへのアクセスによるアドレス解決なしにアドレス取得できるようにしてもよい。

図１５において、収集依頼情報１５１０は、ＬＩＤ、データ種別、ＧＩＤ、属性情報を含むが、収集対象のレコードが特定できればよく、例えば、ＬＩＤだけ含めることで、集数対照のレコードを特定することとしてもよい。

また収集情報１５１０は、更に、抑止フラグを含んでもよい。例えば、収集依頼部４０６は、図１１のＳ１１０６で削除を実行した場合に、図１５の収集依頼情報１５１１のように、収集依頼情報の抑止フラグ１５０５をセット（収集依頼情報の対応データ部分にｔｒｕｅを書き込む）して、収集を抑止する依頼を行ってもよい。なお、抑止フラグが付与された依頼情報を受信したＤＢ管理装置１０２（１）〜１０２（３）は、対応する構成についての変更をＣＭＤＢ管理装置１０１に送信しないように抑制制御を行う。

尚、本実施例においては、抑止フラグを付与する場合、「ｔｒｕｅ」の値を付与することとするが、具体的な抑止フラグの値は、例えば「１」や、「ｏｎ」のように、「ｔｒｕｅ」以外の値であっても構わない。

収集依頼情報を生成した収集依頼部４０６は、生成した収集依頼情報を、通信制御部４０１を介して、ＤＢ識別子に対応するＤＢ管理装置１０２（１）〜１０２（３）に送信する。

一方、収集依頼情報を受信したＤＢ管理装置１０２（１）〜１０２（３）のぞれぞれは、通信制御部５０１が受信する収集依頼に基づいて処理を行う。図１６を用いて、処理の詳細について説明する。

図１６は、ＣＭＤＢ管理装置１０１が送信した収集依頼を通信制御部５０１が受信する場合にＤＢ管理装置１０２（１）〜１０２（３）のそれぞれが実行する処理の手順を示す。

まず、通信制御部５０１は、ＣＭＤＢ管理装置１０１が送信した収集依頼を受信する（Ｓ１６０１）。そして通信制御部５０１は、受信した収集依頼情報に基づいて、収集情報記憶部５１１に、情報を記憶する（Ｓ１６０２）。図１７に収集情報記憶部５１１が記憶する情報の一例を示す。図１７の収集情報１７００は、情報として、ＬＩＤ１７０１、データ種別１７０２、ＧＩＤ１７０３、属性情報１７０４、抑止フラグ１７０５、更新日時１７０６を含む。ＬＩＤ１７０１、データ種別１７０２、ＧＩＤ１７０３、属性情報１７０４、抑止フラグ１７０５は、通信制御部５０１が、受信した収集依頼情報に含まれるＬＩＤ１５０１、データ種別１５０２、ＧＩＤ１５０３、属性情報１５０４、抑止フラグ１５０５を抽出し、収集情報記憶部５１１に記憶した情報である。

収集部５０２は、収集情報記憶部５１１に記憶された収集情報１７００を参照して、抑止フラグがｔｒｕｅでない抑止対象外の収集依頼情報を読み出す（Ｓ１６０３）。ここで抑止対象の収集依頼情報は、読み出さないこととしたので、ＣＭＤＢ管理装置１０１に不要な変更データが送信されないようにすることができる。また、各ＤＢが周期的に変更データを送信する場合に、抑止対象の変更データについては送信を差し控えることで、不要な変更データをＣＭＤＢ管理装置１０１に送信してしまうことを抑制することができる。

収集部５０２は、取り出した収集情報１７００を参照し、例えば情報に含まれるＬＩＤ１７０１や属性情報１７０４に基づいて、ＤＢ５２０から対象のデータを検索する。ＤＢ５２０に対象のデータが存在し、さらに、前回の収集からデータが更新されている場合（Ｓ１６０４、Ｙｅｓ）は、対象データをＣＭＤＢが認識できる共通データ形式に変換する（Ｓ１６０５）。ここで、共通データ形式の変換のルールは、例えば、ＣＭＤＢ管理装置１０１によりデータが統合されるＤＢ管理装置１０２（１）〜（３）のそれぞれが実行するプログラムにて予め定義されている。ＤＢ管理装置１０２（１）〜（３）は、プログラムに定義された変換ルールに基づいて対象データを共通データ形式に変換する。

尚、ＤＢから対象のデータが検索されなかった場合、あるいは、対象のデータが前回の収集から更新されていない場合は、ステップＳ１６０５の変換は実行しなくてよい。

次に、依頼部５０３は、ＣＭＤＢ管理装置１０１に対して、共通データ形式に変換された変更データを送信することで、ＣＭＤＢに更新を反映するように要求する（Ｓ１６０６）。

更新依頼をＣＭＤＢ管理装置１０１に送信後、更新部５０４は、収集テーブルの更新日時１７０６の値を現在の時刻に更新してもよい（Ｓ１６０７）。

あるいは、更新部５０４は、収集テーブルの更新日時１７０６の値をＳ１６０１で通信制御部５０１が収集依頼情報を受信した時刻に更新することとしても良い。

図１８は、収集情報１７００が更新された後の収集情報１７００ｂの例を示す。図１８のようにステップＳ１６０７の処理によって、更新日時１７０６に日時を特定する情報が記憶されている。

収集情報記憶部５１１に、未処理の収集情報が記憶されている場合は、収集部５０２は、ステップＳ１６０３からの処理を繰り返す。

次に、ＤＢ管理装置１０２（１）〜１０２（３）の周期的な変更情報の送信と、この収集情報の受信との関係について図１９を用いて説明する。

ＤＢ管理装置１０２（１）〜１０２（３）はそれぞれ異なる周期で、ＣＭＤＢ管理装置１０１に変更データを送信（通常収集のための送信）するかどうかの処理判断を実行する。例えば、ＤＢ管理装置１０２管理装置（１）〜１０２（３）それぞれのデータの通常収集のタイミングに到達したとき、ＤＢ管理装置１０２（１）〜１０２（３）は変更データをＣＭＤＢ管理装置１０１に送信する処理を開始する（Ｓ１９０１）。ここでは、更に、ＬＩＤ毎に異なる周期、タイミングで行っているものとする。

まず、収集部５０２は、判断対象のＬＩＤに対応する収集情報が収集情報記憶部５１１に記憶されているか判定する（Ｓ１９０２）。判断対象のＬＩＤに対応する収集情報が収集情報記憶部５１１に記憶されていないと収集部５０２が判定した場合、収集部５０２はステップＳ１９０４の処理を実行する。

一方、ステップＳ１９０２において、判断対象のＬＩＤに対応する収集情報が収集情報記憶部５１１に記憶されていると収集部５０２が判定した場合、収集部５０２は、判断対象のＬＩＤを含む収集情報に含まれる更新日時１７０６が、当該ＬＩＤについて前回の通常収集のための送信処理によりＣＭＤＢ管理装置１０１に送信した日時よりも新しいか判定する（Ｓ１９０３）。

例えば、判断対象のＬＩＤがＤＩＳＫ＿１の場合、図１８を参照すると、判断対象のＬＩＤに対応する収集情報に対応する更新日時は２０１２／０１／２３の１０：０１：１５であることが分かる。一方、前回の通常収集のための送信処理によりＣＭＤＢ管理装置１０１に送信した日時は、図２０の更新日時情報２０００を参照すると、２０１２／０１／２３の１０：００：５６であることが分かる。従って、収集部５０２は、前記の通常収集における送信時刻よりも新しい時刻でＣＭＤＢ管理装置１０１からの収集依頼に基づく送信を行っているため、今回の通常収集のための送信処理は行わないものとすることができる。

一方、更新日時２００４よりも判断対象のＬＩＤに対応する収集情報に対応する更新日時１７０６の方が古い場合、収集部５０２はステップＳ１９０４の処理を実行する。

ステップＳ１９０４において、収集部５０２は、通常収集として、収集対象のＬＩＤ１５０１や属性情報１５０４をキーとして、ＤＢ５２０から対象のデータを検索することでＣＭＤＢ管理装置１０１に送信すべき変更データを収集する。

ステップＳ１９０４の処理を実行後、収集部５０２は、収集したＬＩＤに対応する収集情報が収集情報記憶部５１１に記憶されているか判定する（Ｓ１９０５）。なお、ここでの判定の処理は、ステップＳ１９０２で実行した処理と同様であるので、収集部５０２はステップＳ１９０２にて判定を実行した結果を用いることとしても良い。収集情報記憶部５１１に記憶されていないと収集部５０２が判定した場合、収集部５０２はステップＳ１９０７の処理を実行する。

一方、ステップＳ１９０５において、収集情報記憶部５１１に記憶されていると収集部５０２が判定した場合、ステップＳ１９０１で記憶されている対応する収集情報の抑止フラグ１５０５の値が「ｔｒｕｅ」であるか判定する（Ｓ１９０６）。抑止フラグ１５０５の値が「ｔｒｕｅ」でないと収集部５０２が判定した場合、依頼部５０３はＣＭＤＢ管理装置１０１に収集した変更データを送信することで更新依頼を実行する（Ｓ１９０７）。

一方、ステップＳ１９０６において、抑止フラグ１５０５の値が「ｔｒｕｅ」であると収集部５０２が判定した場合、収集部５０２は、ＣＭＤＢへの更新データの送信は行わない。

そして、更新部５０４は記憶している収集情報が以下の条件に合致する場合に、その収集情報の削除処理を行う（Ｓ１９０８）。
・ＣＭＤＢ管理装置１０１に更新済のデータに対応する情報であるか、または、
・抑止フラグ１５０５の値が「ｔｒｕｅ」であり、ＤＢ５２０から削除されている情報に対応する情報であるか
上述した削除条件の少なくとも一方を満たす場合に、更新部５０４は、収集情報記憶部５１１に記憶された、対応する収集情報を削除する。

以上のように、本実施例においては、ＣＭＤＢ管理装置１０１が管理するＤＢ管理装置１０２（１）〜１０２（３）のうち、更新頻度の高いＤＢをマスタＤＢとして決定する。マスタＤＢからの更新依頼の受信に応じて、マスタＤＢ以外のＤＢに記憶された情報を収集する収集依頼を、送信する。収集した情報に基づいて、ＣＭＤＢ管理装置１０１の内容を更新する。このような態様によれば、本実施例のＣＭＤＢ管理装置１０１は、マスタＤＢに記憶された情報の更新を更新するタイミングで、マスタＤＢ以外に記憶された情報も収集し、ＣＭＤＢ管理装置１０１の内容を更新することが可能となる。これにより、データの更新タイミングが統一されるので、例えばＣＭＤＢ管理装置１０１にアクセスする情報処理装置が、整合のとれていないデータを参照してしまうことを抑止することができる。

また、本実施例では、前回のデータの収集がＣＭＤＢ管理装置１０１からの依頼により実行されている場合、ＤＢ管理装置１０２（１）〜１０２（３）は、ＤＢ５２０から受信した収集依頼情報に基づくデータの収集を抑止する。これにより、ＤＢ管理装置１０２（１）〜１０２（３）が定期的に実行する、ＤＢ５２０からのデータの収集にかかる処理負荷を軽減することが可能である。

また、本実施例では、マスタＤＢからの依頼により、ＣＭＤＢの情報が削除される場合、削除が依頼された情報と統合された情報に対応する収集依頼情報に抑止フラグを付与してＤＢ管理装置１０２（１）〜１０２（３）に送信する。抑止フラグの付与された収集情報を受信したＤＢ管理装置１０２（１）〜１０２（３）は、抑止フラグの付与された収集情報に基づいて特定されるデータの、ＣＭＤＢ管理装置１０１への送信を抑止する。これにより、ＣＭＤＢ管理装置１０１で削除が依頼されたデータがＣＭＤＢ管理装置１０１に送信され続けることで、削除が依頼されたデータがＣＭＤＢ管理装置１０１から削除されずに記憶され続けることを抑止することができる。

本実施例において説明した態様は、本発明を実現する態様の１つであり、本発明を実施する具体的な態様は、本実施例に限定されない。

ＤＢシステム１００を示す。 ＣＭＤＢ管理装置１０１のハードウェア構成の一例を示す。 ＤＢ管理装置１０２（１）のハードウェア構成の一例を示す。 ＣＭＤＢ管理装置１０１の機能ブロック図を示す。 ＤＢ情報６００を示す。 管理情報７００を示す。 更新情報８００を示す。 閾値情報１０００を示す。 マスタＤＢ情報９００を示す。 ＤＢ管理装置１０２（１）の機能ブロック図を示す。 ＣＭＤＢ管理装置１０１が実行する処理の手順を示すフローチャートを示す。 更新依頼情報１２００を示す。 管理情報７００ｂを示す。 更新情報８００を示す。 収集依頼情報１５００を示す。 ＣＭＤＢ管理装置１０１が送信した収集依頼を受信したＤＢ管理装置１０２（１）〜１０２（３）が実行する処理の手順を示すフローチャートを示す。 収集情報１７００を示す。 収集情報１７００ｂを示す。 通常収集時にＤＢ管理装置１０２（１）〜１０２（３）が実行する処理の手順を示すフローチャートを示す。 更新日時情報２０００を示す。 従来技術を説明する図を示す。

１００ ＤＢシステム
１０１ ＣＭＤＢ管理装置
１０２（１）、１０２（２）、１０２（３） ＤＢ管理装置
１０３ 記憶装置
１１０ ネットワーク
２０１、３０１ ＣＰＵ
２０２、３０２ ＲＡＭ
２０３、３０３ ＨＤＤ
２０４、３０４ ドライブ
２０５、３０５ ディスクＲＯＭ
２０６、３０６ アダプタ
４０１、５０１ 通信制御部
４０２ 決定部
４０３ データ更新部
４０４ 更新管理部
４０５ 判定部
４０６ 収集依頼部
４１１ ＤＢ情報記憶部
４１２ 管理情報記憶部
４１３ 更新情報記憶部
４１４ マスタＤＢ情報記憶部
４１５ 閾値情報記憶部
５０２ 収集部
５０３ 依頼部
５０４ 更新部
５０５ ＤＢアクセス部
５１１ 収集情報記憶部
５１２ 更新日時情報記憶部
５２０ ＤＢ

Claims (6)

1. 管理装置に、
   複数のデータベースの中から、データベースに記憶された統合対象のデータの更新頻度が最も高いデータベースを特定し、
   特定した前記データベースからの更新データの取得に応じて、前記複数のデータベースのうちの、特定した前記データベース以外のデータベースに記憶された情報を前記管理装置に送信させる要求を、特定した前記データベース以外の前記データベースに対して送信し、
   特定した前記データベース以外の前記データベースが前記要求に応じて前記管理装置に送信した情報に基づいて、前記統合対象のデータを更新する、
   ことを実行させることを特徴とする管理プログラム。
2. 前記管理プログラムはさらに、
   前記管理装置に、
   前記複数のデータベースそれぞれについて、データベースからの更新要求の受信に応じて、記憶部に記憶された前記データベースの更新の回数を特定する回数情報と、更新要求を受信した時間を特定する時間情報とを更新し、
   前記回数情報と、前記時間情報に基づいて、更新頻度を算出し、
   算出した更新頻度に基づいて、更新頻度が最も高い前記データベースを特定する、
   ことを実行させることを特徴とする請求項１記載の管理プログラム。
3. 前記管理プログラムはさらに、
   前記管理装置に、
   特定した前記データベースから、統合されたデータを削除する削除要求を受信した場合、前記削除要求により特定されるデータと統合されたデータを記憶するデータベースに対して、前記統合されたデータの、前記管理装置への送信を抑止させる要求を送信する、
   ことを実行させることを特徴とする請求項１または２記載の管理プログラム。
4. 前記管理プログラムはさらに、
   前記管理装置に、
   前記統合されたデータの前記管理装置への送信を抑止させるフラグ情報を、前記削除要求とともに、統合されたデータを記憶する前記データベースに対して送信することにより、前記統合されたデータの前記管理装置への送信を抑止させる、
   ことを実行させることを特徴とする請求項３記載の管理プログラム。
5. 複数のデータベースの中から、データベースに記憶された統合対象のデータの更新頻度が最も高いデータベースを特定する特定部と、
   特定した前記データベースからの更新データの取得に応じて、前記複数のデータベースのうちの、特定した前記データベース以外のデータベースに記憶された情報を管理装置に送信させる要求を、特定した前記データベース以外の前記データベースに対して送信する送信部と、
   特定した前記データベース以外の前記データベースが前記要求に応じて前記管理装置に送信した情報に基づいて、前記統合対象のデータを更新する更新部と、
   を備えたことを特徴とする管理装置。
6. データベースを管理する情報処理装置と、複数の前記データベースに記憶されるデータを管理する管理装置とを備えた情報処理システムにおいて、
   前記管理装置は、
   複数の前記データベースの中から、データベースに記憶された統合対象のデータの更新頻度が最も高いデータベースを特定する特定部と、
   特定した前記データベースからの更新データの取得に応じて、前記複数のデータベースのうちの、特定した前記データベース以外のデータベースに記憶された情報を前記管理装置に送信させる要求を、特定した前記データベース以外の前記データベースに対して送信する送信部と、
   特定した前記データベース以外の前記データベースが前記要求に応じて前記管理装置に送信した情報に基づいて、前記統合対象のデータを更新する第１の更新部と、を備え、
   前記情報処理装置は、
   前記送信部が送信した要求の受信に応じて、自装置のデータベースのデータの情報収集を実行する収集部と、
   収集した情報を前記管理装置に送信する第２の送信部と、
   を備えたことを特徴とする情報処理システム。

Images