(57)【特許請求の範囲】
【請求項１】
インスタンスの包含関係を記憶する包含関係ファイルと、
インスタンスの管理情報を記憶するインスタンスファイルと、
上記包含関係ファイルと上記インスタンスファイルを用いて、管理情報をアクセスするデータベースアクセス部とを備えたマネジメント・インフォメーション・ベース・管理システムであって、
上記インスタンスファイルは、インスタンスが持つ管理情報のサイズを記憶するサイズ記憶部を有し、
上記データベースアクセス部は、管理情報のサイズの変更があった場合、上記サイズ記憶部にある管理情報のサイズを新たなサイズに変更し、新たなサイズに基づいてインスタンスファイルを再生する管理情報サイズメンテナンス部を備えた
ことを特徴とするマネジメント・インフォメーション・ベース・管理システム。
【請求項２】
上記マネジメント・インフォメーション・ベース・管理システムは、インスタンスの包含関係を親子兄弟を示す包含木で表すとともに、上記包含関係ファイルは、包含木の深さレベル毎に複数設けられたことを特徴とする請求項１記載のマネジメント・インフォメーション・ベース・管理システム。
【請求項３】
上記複数の包含関係ファイルは、各ファイル毎に定められた所定数の兄弟を記憶する複数の領域が設けられたことを特徴とする請求項２記載のマネジメント・インフォメーション・ベース・管理システム。
【請求項４】
上記マネジメント・インフォメーション・ベース・管理システムは、管理対象に管理対象クラスを割り当てるとともに、上記インスタンスファイルは上記管理対象クラス毎に複数設けられたことを特徴とする請求項１，２または３記載のマネジメント・インフォメーション・ベース・管理システム。
【請求項５】
上記データベースアクセス部は、新たな管理対象クラスが追加された場合に、その管理対象クラスに対応するインスタンスファイルを生成する管理対象クラスメンテナンス部を備えたことを特徴とする請求項４記載のマネジメント・インフォメーション・ベース・管理システム。
【請求項６】
上記データベースアクセス部は、新たなインスタンスが追加された場合、そのインスタンスが存在する深さレベルに対応する包含関係ファイルにそのインスタンスを追加し、そのインスタンスの管理対象クラスに対応するインスタンスファイルにそのインスタンスを追加するとともに、包含関係ファイルに追加したインスタンスからインスタンスファイルに追加したインスタンスをアクセスするポインタを付加するインスタンスメンテナンス部を備えたことを特徴とする請求項４記載のマネジメント・インフォメーション・ベース・管理システム。
【請求項７】
上記データベースアクセス部は、管理対象ネットワークの構成が変更されることによる包含木の変更があった場合、上記包含関係ファイルの親子あるいは兄弟のポインタの付け変えを行うことにより、包含木の変更を行う包含木メンテナンス部を備えたことを特徴とする請求項４記載のマネジメント・インフォメーション・ベース・管理システム。
【請求項８】
上記データベースアクセス部は、少なくとも上記包含関係ファイルおよび上記インスタンスファイルのいずれかのファイルのガーベージコレクションを行うガーベージコレクション部を備えたことを特徴とする請求項１記載のマネジメント・インフォメーション・ベース・管理システム。
【請求項９】
上記インスタンスファイルは、各インスタンスの管理情報の更新時刻を記憶するとともに、上記データベースアクセス部は、上記更新時刻に基づいて管理情報のアクセスの制御を行う表示処理部を備えたことを特徴とする請求項４記載のマネジメント・インフォメーション・ベース・管理システム。
【発明の詳細な説明】
【０００１】
【産業上の利用分野】
この発明は、開放型システム間相互接続（ＯＳＩ：Ｏｐｅｎ  Ｓｙｓｔｅｍｓ  Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ）管理のデータベースの内部構成に関するものである。特に、この発明はマネジメント・インフォメーション・ベース（ＭＩＢ：Ｍａｎａｇｅｍｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂａｓｅ）・管理システムの構成及びそのメンテナンスに関するものである。
【０００２】
【従来の技術】
当初のネットワークには、ネットワーク全体を管理する仕組みは導入されておらず、ネットワーク管理の基本的な考え方は存在していなかった。ネットワークに接続するノードの数が増え、ネットワーク全体の通信量が増加するのに伴い、ネットワーク管理者がネットワーク全体の管理対象の状態を正確にかつリアルタイムに把握することが要求されるようになってきた。その要求に応えるためネットワーク全体の資源を積極的に管理するためのシステムが、ＯＳＩ管理システムである。ネットワーク管理にはいろいろな要求があるが、ＯＳＩではさまざまな要求に対して、ネットワーク管理で提供する機能を以下のようにいくつかに分類している。
１．障害管理（ＦＡＵＬＴ  ＭＡＮＡＧＥＭＥＮＴ）
エラー発生記録の管理、エラー検出通知の受付と対処、診断機能の遂行
２．課金管理（ＡＣＣＯＵＮＴＩＮＧ  ＭＡＮＡＧＥＭＥＮＴ）
ネットワーク資源の利用状況に応じて課金したり、コストを算出する仕組み。
３．構成および名前管理（ＣＯＮＦＩＧＵＲＡＴＩＯＮ  ＡＮＤ  ＮＡＭＥ  ＭＡＮＡＧＥＭＥＮＴ）
継続的にネットワークサービスを提供するために、ネットワーク資源を統制し、個々を識別し、データの集配を務める仕組み。
具体的には、システムパラメータの設定、ネットワーク資源の起動と停止、ネットワークの状況に影響を与えるデータの収集、ネットワークの構成の変更など。
４．性能管理（ＰＥＲＦＯＲＭＡＮＣＥ  ＭＡＮＡＧＥＭＥＮＴ）
ネットワーク資源の動作状況、および通信の効果を評価するために必要な機能。
具体的には、解析や計画のための統計データの収集、システムの使用状況記録の維持管理、ネットワーク上の通信量を測定し、ネットワークの負荷が適正量を越えないように監視、不正データがないかどうか、ネットワーク診断用など。
５．セキュリティ管理（ＳＥＣＵＲＩＴＹ  ＭＡＮＡＧＥＭＥＮＴ）
ネットワーク資源の保全をはかる。
具体的には、認証の仕組み、アクセス管理、暗号化、セキュリティ記録の維持管理。
【０００３】
ＯＳＩにおけるネットワーク管理の標準化作業は検討段階にある。例えば管理情報をどのようにマネジメント・インフォメーション・ベースに記憶するかは特にＯＳＩの基準においては定められておらず、個々のシステムにまかされたものとなっている。
【０００４】
図２７は、一般的なＯＳＩ管理システムの一例を示す図である。ＯＳＩ管理システムは大きく分けて２つのネットワークで構成されている。１つは個々の資源で構成された管理対象ネットワーク２００である。もう１つは管理対象ネットワーク２００に存在する個々の資源を管理するための管理ネットワーク１００である。管理対象ネットワーク２００内に存在している個々の資源のことを管理対象という。例えば図２７においては、管理対象としてシステム２１０、ローカル・エリア・ネットワーク２１１、ワークステーション２１２、システム２２０、プライベート・ブランチ・エクスチェンジャ２２１、パーソナルコンピュータ２２２、タイム・ディビジョン・マルチプレクサー２２３が存在している。これらの管理対象はユーザの要求に合わせてシステム化されたネットワークである。管理対象ネットワーク２００はユーザの業務を実際に実行するためのシステムを提供する。
一方、管理ネットワーク１００は管理対象ネットワーク２００に存在する管理対象を監視及び管理するためのネットワークである。管理ネットワーク１００には各管理対象を監視するエージェント１０２ａ，１０２ｂ，１０２ｃ…が存在する。また、各エージェント１０２ａ，１０２ｂ，１０２ｃからの情報を総合的に管理するマネージャ１０１が存在する。さらにエージェント及びマネージャがアクセスするための情報を記憶するマネジメント・インフォメーション・ベース１１０が存在する。また、マネージャ１０１とエージェント１０２ａ，１０２ｂ，１０２ｃ…とマネジメント・インフォメーション・ベース１１０を結合するネットワーク１０３が存在する。エージェントは管理対象ネットワーク２００内の管理対象を管理する為に、前述したようなネットワーク管理に必要な管理情報の授受を行う。エージェントは管理対象に対して管理操作を行い、また管理対象からの通知を受け取る。マネージャ１０１はエージェントに対して管理操作を指示する。また、マネージャ１０１はエージェントが管理対象から受け取った通知をエージェントから受け取る。このようにマネージャからエージェントへ、そしてエージェントから管理対象に管理操作の実行が行われる。一方、管理対象からエージェントへ、そしてエージェントからマネージャに対して管理対象で発生した情報の通知が行われる。この管理操作の実行は、マネジメント用のプロトコルに沿って行われる。このようにマネージャとエージェント及びエージェントと管理対象との間で受渡しした情報は管理情報としてマネジメント・インフォメーション・ベース１１０に記憶される。ここでこれらの管理情報をどのようにマネジメント・インフォメーション・ベースに記憶するかは特にＯＳＩの基準においては定められておらず、個々のシステムにまかされたものとなっている。
【０００５】
次に、図２８を用いて管理情報の構造について説明する。ＯＳＩ管理システムにおいては、ネットワーク管理において発生する管理情報は管理対象の追加、修正等がリアルタイムに発生することを考慮し、拡張性を持つ概念でその構造を記述する。そしてその具体的な方法としてオブジェクト指向型の設計を取り入れている。このオブジェクト指向設計の特徴はクラスとインスタンスという概念を導入した点である。図２８にこのクラスとインスタンスのいくつかの例を示す。図２８において、楕円はクラスを示し、四角はインスタンスを示す。（ａ）においては、コンピュータというクラスに対してパーソナルコンピュータ、ワークステーション、スモールビジネスコンピュータというインスタンスが存在する場合を示している。また、（ｂ）においてはパーソナルコンピュータというクラスに対して８ビット機、１６ビット機、３２ビット機というインスタンスが存在する場合を示している。また、（ｃ）においては動物というクラスに対して、イヌ、ネコ、馬というインスタンスが存在する場合を示している。クラスとは共通の特性を定義したものである。インスタンスとはクラスで定義された特性を持つ具体化されたものである。以下、ＯＳＩ管理のためのクラスを管理対象クラスと呼ぶ。また、ＯＳＩ管理のためのインスタンスを管理対象インスタンスあるいは単にインスタンスと呼ぶ。
【０００６】
次に、図２９を用いて、管理対象クラスについて、さらに説明する。図２９は継承木の一例を示す図であり、楕円印は管理対象クラスを示している。また図において、上下関係はスーパークラス及びサブクラスの関係を示している。サブクラスはスーパークラスの特性を継承する。ここで特性とは属性、操作、通知、振る舞いを意味する。サブクラスはスーパークラスの特性を継承しているとともに、新たな特性を追加することができる。逆にサブクラスはスーパークラスの特性のうち何れかのものを削除するということは許されない。例えば、図２９において、ネットワークというサブクラスはシステムというスーパークラスが持つ特性をすべて継承している。同様にワークステーションというサブクラスはシステムの特性をすべて継承している。
【０００７】
次に、図３０を用いて管理対象インスタンスの包含木の例について説明する。管理対象インスタンスを一意に識別するために管理対象インスタンスに名前がつけられる。この名前付けは包含木と呼ばれるツリーに基づいて名前付けがなされる。この包含木は管理対象インスタンスの包含関係を示している。図３０において、（ａ）は管理対象インスタンスの表現方法を示している。管理対象インスタンスは管理対象クラスのオブジェクト識別子と管理対象インスタンスに割り振られた識別名によって表現することができる。図３０の（ｂ）は（ａ）に示した表現方法を用いて包含木を図示したものである。包含木の上下関係は親子関係を示している。包含木の左右関係は兄弟関係を示している。この包含木の例は図２７に示した管理対象ネットワーク２００の場合を示したものである。例えば、この包含木はルートに対してシステム２１０とシステム２２０が存在している。また、システム２１０にはネットワーク２１１とワークステーション２１２が存在していることを示している。
【０００８】
次に、相対識別名ＲＤＮと識別名ＤＮについて説明する。各管理対象インスタンスが持っている名前属性型とその値から構成される組を相対識別名（ＲＤＮ）と呼ぶ。例えば、ワークステーション２１２の相対識別名は（ＷＳＩＤ＝”Ｗ１”）である。同様に、ワークステーション２２４の相対識別名は（ＷＳＩＤ＝”Ｗ１”）である。一方、包含木に沿って前述した相対識別名を並べた名前を識別名（ＤＮ）と呼ぶ。例えば、ワークステーション２１２の場合、識別名は（システムＩＤ＝”ＸＹＺ”）（ＷＳＩＤ＝”Ｗ１”）である。また、ワークステーション２２４の場合の識別名は（システムＩＤ＝”ＯＰＱ”）（ＷＳＩＤ＝”Ｗ１”）である。以上のように、ワークステーション２１２とワークステーション２２４の相対識別名は同一であり互いを識別することはできないが、識別名を用いることにより、管理対象を一意に識別することができる。
【０００９】
図３１及び図３２は特開平３−２３１３５２号公報に示された継承木の論理構成図及び継承木の物理構成図である。図３１に示すような継承木を図３２に示すような構成によりマネジメント・インフォメーション・ベースに記憶する例を示している。図３２においては、各管理対象クラスをノードとして表現している。各ノードには左のポインタと右のポインタが存在している。左のポインタは図３１における親子関係を示すポインタである。また、右のポインタは兄弟関係を示すポインタである。このような左のポインタと右のポインタを用いることにより継承木を検索することができる。
【００１０】
次に、図３３は情報処理学会第４２回（平成３年前期）全国大会（１−１６９〜１−１７０）において発表されたマネジメント・インフォメーション・ベースのデータ構造を示す図である。インスタンスの属性情報はインスタンス情報テーブル４００を介してアクセスすることができる。インスタンス情報テーブル４００には上下左右のインスタンスを表すアドレスが保持されているとともに、フォワードポインタ検索ができるようにフォワードアドレスが記憶されている。上下左右のアドレスは包含木を検索するために用いるものである。また、フォワードアドレスはインスタンスが包含する下位のインスタンス群を特定するためのものである。このように、２分木検索とフォワードポインタ検索の２方式を併用することでインスタンスの高速検索を可能としている。このインスタンス情報テーブル４００はエージェント情報テーブル４１０から参照される。そして、これらエージェント情報テーブル４１０とインスタンス情報テーブル４００はエージェント単位に記憶されている。一方、クラス情報テーブル５００は上位クラスアドレスと下位クラスアドレスの上下アドレスを持つことによりクラス情報を検索する。アトリビュート情報テーブル５２０には各クラスの属性が記憶されており、これらの情報はクラス情報テーブル５００のアトリビュートリスト情報を用いて参照することができる。
【００１１】
【発明が解決しようとする課題】
マネジメント・インフォメーション・ベースに記憶されるデータ量は大規模なものとなる。また、各インスタンスへのアクセス処理は高速に行われることが要求される。さらに、管理情報は管理対象の状態が変化するたびにダイナミックにかつリアルタイムに更新されるため、容易にかつ高速に更新が可能な構成をとる必要がある。従来のＯＳＩ管理システムにおいては、各管理対象の関係や管理対象の構成をアプリケーション設定時、またはアプリケーションプログラムのコンパイル時に静的に取り込んでいた。従って、管理対象間の包含関係や管理情報の構成をアプリケーション側で吸収しなければならず、柔軟なシステム構築が難しかった。
【００１２】
例えば、スーパークラスにおいて特性等の変更が生ずると、そのスーパークラス定義の変更に基づきサブクラスの定義をし直し、関連するプログラムのコンパイル及びリンクをし直す必要があった。図３１、図３２及び図３３に示した従来のマネジメント・インフォメーション・ベースはこのようなアプリケーション側の負担を軽減するとともに、インスタンスの高速アクセス及びネットワークの構成変更に伴うダイナミックな更新を可能にするために考えられたものである。しかし、これらのシステムにおいても管理対象クラス及び管理対象インスタンスの両方にわたって総合的にかつ柔軟的にシステムを構築するという点においてはまだ考慮すべき点が残っている。
【００１３】
さらに、前述したようにＯＳＩにおけるネットワーク管理の標準化作業は検討段階にあり例えば管理情報をどのようにマネジメント・インフォメーション・ベースに記憶するかは特にＯＳＩの基準においては定められておらず、個々のシステムにまかされたものとなっている。
【００１４】
この発明は上記のような問題点を解決するためになされたもので、マネジメント・インフォメーション・ベースの新たなファイル構成を提案するとともに、そのファイル構成に基づくＯＳＩ管理システムを提供することを目的とする。さらに、前述した管理の仕組みのうち、特に、構成および名前管理に有効な手段を提供することを目的とする。具体的には以下の点である。
（１）オブジェクト指向の概念を用いて表現されたネットワーク管理の管理情報のデータベースにおけるインスタンス間の包含関係の追加、削除を柔軟に行えること。
（２）マネジメント・インフォメーション・ベースの保守が容易であること。
（３）マネジメント・インフォメーション・ベースに記憶されたインスタンスの追加及び削除の繰り返しに対して、無駄なリソースを発生させないこと。
【００１５】
【課題を解決するための手段】
この発明に係るマネジメント・インフォメーション・ベース・管理システムは、以下の要素を有するものである。
（ａ）インスタンスの包含関係を記憶する包含関係ファイル、
（ｂ）インスタンスの管理情報を記憶するインスタンスファイル、
（ｃ）上記包含関係ファイルと上記インスタンスファイルを用いて、管理情報をアクセスするデータベースアクセス部。
【００１６】
この発明に係るマネジメント・インフォメーション・ベース・管理システムは、インスタンスの包含関係を親子兄弟を示す包含木で表すとともに、上記包含関係ファイルは、包含木の深さレベル毎に複数設けられたことを特徴とする。
【００１７】
この発明に係るマネジメント・インフォメーション・ベース・管理システムは、複数の包含関係ファイルに、各ファイル毎に定められた所定数の兄弟を記憶する複数の領域が設けられたことを特徴とする。
【００１８】
この発明に係るマネジメント・インフォメーション・ベース・管理システムは、管理対象に管理対象クラスを割り当てるとともに、上記管理対象クラス毎に上記インスタンスファイルを複数設けることを特徴とする。
【００１９】
この発明に係るマネジメント・インフォメーション・ベース・管理システムは、上記データベースアクセス部に、新たな管理対象クラスが追加された場合に、その管理対象クラスに対応するインスタンスファイルを生成する管理対象クラスメンテナンス部を備えたことを特徴とする。
【００２０】
この発明に係るマネジメント・インフォメーション・ベース・管理システムは、新たなインスタンスが追加された場合、そのインスタンスが存在する深さレベルに対応する包含関係ファイルにそのインスタンスを追加し、そのインスタンスの管理対象クラスに対応するインスタンスファイルにそのインスタンスを追加するとともに、包含関係ファイルに追加したインスタンスからインスタンスファイルに追加したインスタンスをアクセスするポインタを付加するインスタンスメンテナンス部を備えたデータベースアクセス部を有することを特徴とする。
【００２１】
この発明に係るマネジメント・インフォメーション・ベース・管理システムは、上記インスタンスファイルに、インスタンスが持つ管理情報のサイズを記憶するサイズ記憶部を有することを特徴とする。
【００２２】
この発明に係るマネジメント・インフォメーション・ベース・管理システムは、管理情報のサイズの変更があった場合、上記サイズ記憶部にある管理情報のサイズを新たなサイズに変更し、新たなサイズに基づいてインスタンスファイルを再生する管理情報サイズメンテナンス部を備えたデータベースアクセス部を有することを特徴とする。
【００２３】
この発明に係るマネジメント・インフォメーション・ベース・管理システムは、管理対象ネットワークの構成が変更されることによる包含木の変更があった場合、上記包含関係ファイルの親子あるいは兄弟のポインタの付け変えを行うことにより、包含木の変更を行う包含木メンテナンス部を備えたデータベースアクセス部を有することを特徴とする。
【００２４】
この発明に係るマネジメント・インフォメーション・ベース・管理システムは、上記データベースアクセス部に、少なくとも上記包含関係ファイルおよび上記インスタンスファイルのいずれかのファイルのガーベージコレクションを行うガーベージコレクション部を備えたことを特徴とする。
【００２５】
この発明に係るマネジメント・インフォメーション・ベース・管理システムは、各インスタンスの管理情報の更新時刻を記憶するインスタンスファイルを有し、上記更新時刻に基づいて管理情報のアクセスの制御を行う表示処理部を備えたデータベースアクセス部を有することを特徴とする。
【００２８】
【作用】
この発明におけるマネジメント・インフォメーション・ベース・管理システムは、データ構造が大きく二つに分かれており、包含関係ファイルがインスタンスの包含関係を記憶し、インスタンスファイルがインスタンスの管理情報を記憶する。さらに、これらのファイルを用いてデータベースアクセス部が、管理情報をアクセスする。このため、インスタンスの包含関係をマネジメント・インフォメーション・ベース・管理システムのなかに持つことができる。
【００２９】
この発明に係るマネジメント・インフォメーション・ベース・管理システムは、インスタンスの包含関係を親子兄弟を示す包含木で表すとともに、包含関係ファイルは、包含木の深さレベル毎に複数設けられている。このため、リソースの節約につながるとともに、ファイル名を一意に容易に特定できる。また、この構造により、インスタンスの検索を容易に行える。
【００３０】
この発明に係るマネジメント・インフォメーション・ベース・管理システムは、複数の包含関係ファイルに、各ファイル毎に定められた所定数の兄弟を記憶する複数の領域が設けられている。このため、管理対象の包含関係に応じた値をファイル毎に設定することが可能となる。この構造により、インスタンスの追加、削除を容易かつ高速にしている。
【００３１】
この発明に係るマネジメント・インフォメーション・ベース・管理システムは、管理対象に管理対象クラスを割り当てるとともに、その管理対象クラス毎にインスタンスファイルを複数設けるものである。これにより、管理対象クラスの追加削除に対応した、マネジメント・インフォメーション・ベース・管理システムの保守が可能となる。
また、クラス毎に分けることにより、その各々のインスタンスが持つ属性の数、大きさ等が、同等のものを１つのファイルに集める事が可能となる。このことにより、インスタンスの削除／追加の時のリソースの再利用を可能とし、リソースの節約が可能となる。また、マネージメント・インフォメーション・ベース・管理システムの保守も容易となる。
【００３２】
この発明に係るマネジメント・インフォメーション・ベース・管理システムは、管理対象クラスメンテナンス部が、新たな管理対象クラスが追加された場合に、その管理対象クラスに対応するインスタンスファイルを生成する。このため、ネットワークにおける管理対象クラスの追加を、動的に、マネジメント・インフォメーション・ベース・管理システムに反映することができる。
【００３３】
この発明に係るマネジメント・インフォメーション・ベース・管理システムは、インスタンスメンテナンス部が、新たなインスタンスが追加された場合、そのインスタンスが存在する深さレベルに対応する包含関係ファイルにそのインスタンスを追加し、そのインスタンスの管理対象クラスに対応するインスタンスファイルにそのインスタンスを追加するとともに、包含関係ファイルに追加したインスタンスからインスタンスファイルに追加したインスタンスをアクセスするポインタを付加する。このため、動的な、インスタンスの追加削除が可能となる。
【００３４】
この発明に係るマネジメント・インフォメーション・ベース・管理システムにおいて、インスタンスファイルは、クラス毎にインスタンスが持つ管理情報のサイズを記憶するサイズ記憶部を有している。これにより、管理対象クラスの属性に適合した管理情報サイズを設定できる。これにより、リソースの節約ができる。
【００３５】
この発明に係るマネジメント・インフォメーション・ベース・管理システムにおいて、管理情報のサイズの変更があった場合、上記サイズ記憶部にある管理情報のサイズを新たなサイズに変更し、新たなサイズに基づいてインスタンスファイルを再生する管理情報サイズメンテナンス部を備えている。このため、属性の追加削除を動的に、容易に行うことができる。
【００３６】
この発明に係るマネジメント・インフォメーション・ベース・管理システムは、包含木メンテナンス部が、管理対象ネットワークの構成が変更されることによる包含木の変更があった場合、上記包含関係ファイルの親子あるいは兄弟のポインタの付け変えを行うことにより、包含木の変更を行う。このため、ネットワーク管理運用中に管理対象ネットワークの構成の変更があっても、柔軟に対応できる。
【００３７】
この発明に係るマネジメント・インフォメーション・ベース・管理システムは、ガーベージコレクション部を備え、ガーベージコレクション部は、包含関係ファイルやインスタンスファイルのガーベージコレクションを行う。これにより、リソースを節約し、資源の有効活用を図ることができる。
【００３８】
この発明に係るマネジメント・インフォメーション・ベース・管理システムにおいて、インスタンスファイルは、各インスタンスの管理情報の更新時刻を記憶し、表示処理部は、その更新時刻と、表示処理終了時刻を比較して、その比較に基づいてマネジメント・インフォメーション・ベース・管理システムの管理情報の表示を行う。このため、常に表示を継続させる必要が無くなり、ネットワーク管理システムの運用が効率的となる。
【００４１】
【実施例】
実施例１．
以下に、この発明の一実施例を図について説明する。図１はデータベースの概要を示したものである。１はインスタンスにより構成される包含木を示す。１１，１２はそれぞれ包含木における深さレベル１、深さレベル２の包含関係ファイルである。２１，２２，２３はそれぞれ管理対象クラス毎のインスタンスファイルである。３１はこれらのファイルを有するマネジメント・インフォメーション・ベースを示したものである。
【００４２】
図２に、包含関係ファイル、インスタンスファイルの詳細を示す。
包含関係ファイルにおいて、４１〜４４は兄弟を格納する兄弟格納領域を示す。５１，５２，５３は兄弟格納領域の空き管理を行うためのデータである。６１〜６４は包含木内のインスタンスの関係を保持するためのインスタンス毎のデータである。このインスタンス毎のデータとしてはフラグ、子供へのポインタ、クラス、インスタンスへのポインタ、インスタンス名が記憶される。インスタンス名には包含関係ファイルでは相対識別名、インスタンスファイルでは識別名が格納される。
【００４３】
インスタンスファイルにおいて、７１はクラス毎のインスタンスが持ち得る最大属性数７１ａと属性値最大サイズ７１ｂを格納するサイズ領域である。この最大属性数及び属性値最大サイズをかけ合わせることにより後述する管理情報のサイズを求めることができる。８１，８２はインスタンス毎の管理情報を格納する管理情報領域を示す。１０１，１０２はそれぞれ自分の子を指すポインタである。１１１はクラスとインスタンスポインタを用いて、インスタンスファイル中の該当インスタンスを指す。１２１は兄弟格納領域に兄弟のインスタンスを格納しきれなくなり、新たな兄弟格納領域を確保した場合に、この新たな兄弟格納領域を指し示すためのポインタである。
【００４４】
管理情報領域８１，８２のサイズは、７１の最大属性数と属性値最大サイズから計算される。例えば、最大属性数＝２であり、属性値最大サイズが８である場合には、管理情報領域８１，８２は最大属性数×属性値最大サイズ＝２×８（バイト）のサイズを持つ領域となる。
【００４５】
次に、図３を用いて包含関係ファイルの構成について説明する。図３において、深さレベル１の包含関係ファイル１１は兄弟格納領域４１に２人の兄弟まで保持することができる場合を示している。一方、深さレベル２の包含関係ファイル１２は兄弟格納領域４２，４３，４４にそれぞれ４人の兄弟まで保持することができる場合を示している。このように包含関係ファイルは深さレベル毎に持つとともに各深さレベル毎に兄弟格納領域に格納できる兄弟数を変えて持つことができる。この兄弟数は管理対象の包含関係に応じた値を設定することができる。図３の例においては、深さレベル１においては兄弟が２人しか存在しないため、深さレベル１の包含関係ファイル１１には兄弟格納領域４１に２つのデータ６１，６２を記憶する領域を予め確保したものである。また、深さレベル２の包含関係ファイル１２においては兄弟格納領域４２，４３，４４にそれぞれ４つの兄弟が格納できるようにしたものである。包含木の深さレベル２において、兄弟数が最大４の場合にはこのように４つのデータを格納する領域を設ければよい。
【００４６】
なお、この数は兄弟の最大数に合わせる必要はない。例えば、深さレベル２の兄弟の最大数が５である場合であっても、図３に示すように４つの領域を保持するようにしてもかまわない。兄弟格納領域４２において、３つ目のデータを格納する場合には、未使用領域６３ｃに対して新たなデータを格納する。一方、兄弟格納領域４３に対して新たなデータを格納する場合には、既に４つのデータで占められているため５つ目のデータは他の領域例えば兄弟格納領域４４に格納する。その方法は兄弟格納領域の空き管理用データにおいて、ポインタ１２１を用いて領域がオーバーフローしたことを示し、オーバーフローしたデータが格納されている新たな領域４４をポイントする。このようにして、新たなデータを未使用領域６５ａに格納する。このように兄弟格納領域に格納できるデータ数は必ずしも兄弟の最大数である必要はない。オーバーフローした場合には、他の兄弟格納領域にそのオーバーフローしたデータを格納することができる。
【００４７】
次に、図４を用いてインスタンスファイルの例について説明する。図４においては、システム用のインスタンスファイルとネットワーク用のインスタンスファイルとワークステーション用のインスタンスファイルを示している。システム用インスタンスファイルの最大属性数は２であり、属性値最大サイズは８である。従って、管理情報８１ａは２×８バイトのサイズを持つ。同様に管理情報８２ａも１６バイトのサイズを持つ。次に、ネットワーク用インスタンスファイルにおいては、最大属性数が５であり、属性値最大サイズが１６であるため、管理情報８１ｂと８２ｂはそれぞれ５×１６バイトのサイズを持つ。同様にしてワークステーション用インスタンスファイルの管理情報８１ｃ、８２ｃは６×８バイトの管理情報サイズを持つ。
【００４８】
次に、図５は管理情報の一例を示す図である。図５に示す管理情報はワークステーション用インスタンスファイルの管理情報の一例である。図４に示すように、ワークステーション用インスタンスファイルに６×８バイトのサイズで管理情報を記憶できる場合、図５に示すようにそのワークステーションが送信したデータ数、そのワークステーションが受信したデータ数、そのワークステーションの送信回数、そのワークステーションが受信した受信回数、送信エラー回数、受信エラー回数を管理情報として記憶する。
【００４９】
次に、図６を用いて包含関係ファイルのファイル名について説明する。包含関係ファイルのファイル名には包含木の深さレベルをファイル名に用いる。この例においては、サブディレクトリＤＢがマネジメント・インフォメーション・ベースのサブディレクトリを示しており、ＳＵＢＴＲＥＥが包含関係ファイルのサブディレクトリを示している。さらに１は深さレベル１のファイル名を示している。このように深さレベル１のファイル名は／ＤＢ／ＳＵＢＴＲＥＥ／１により表される。同様に深さレベル２のファイル名は／ＤＢ／ＳＵＢＴＲＥＥ／２により表される。このように包含木の深さレベルを用いることにより包含関係ファイルが一意にかつ容易に特定できる。
【００５０】
次に、図７を用いてインスタンスファイルのファイル名について説明する。インスタンスファイルのファイル名にはクラスのオブジェクト識別子を用いる。オブジェクト識別子は登録木に従って一意に付けられた識別子であり、システムクラスの場合、”２．９．３．２．３．１３”といった値をとる。このこのオブジェクト識別子の・セパレータを／セパレータにかえて記述した文字列をファイル名に用いる。例えば、図７に示すように管理対象クラス”システム”のオブジェクト識別子が”２．９．３．２．３．１３”であり、管理対象クラス”ネットワーク”のオブジェクト識別子が”１．３．１４．２．２．１．５”である場合、管理対象クラス”システム”のインスタンスファイルのファイル名は／ＤＢ／２／９／３／２／３／１３ｉである。また管理対象クラス”ネットワーク”のインスタンスファイルのファイル名は／ＤＢ／ＳＹＳ／１／３／１４／２／２／１／５ｉである。ここでｉをファイル名に用いるのは、サブディレクトリかファイルかを識別するためのものであり、ｉが付いているものがファイル名を示し、ｉがついていないものはサブディレクトリそのものを示す。例えば／ＤＢ／１はサブディレクトリであることを示し、／ＤＢ／１ｉはファイル名を示す。
【００５１】
次に、図８を用いてマネジメント・インフォメーション・ベース３１のファイル群５０１をアクセスするデータベースアクセス部５００について説明する。データベースアクセス部５００にはマネジメント・インフォメーション・ベース３１をアクセスし、追加、更新するためのいくつかの処理部が用意されている。
【００５２】
管理対象クラスメンテナンス部５１０は管理対象クラスが追加された場合にその管理対象クラスに対応するインスタンスファイルを生成する。また、管理対象クラスが削除された場合には、対応するインスタンスファイルを削除する。
【００５３】
次に、インスタンスメンテナンス部５２０はインスタンスの追加及び削除を行う。インスタンスメンテナンス部５２０は包含関係ファイルに対して追加するインスタンスを深さレベルに対応する包含関係ファイルに登録する。また、追加するインスタンスをそのインスタンスが属する管理対象クラスのインスタンスファイルに追加する。
【００５４】
次に、管理情報サイズメンテナンス部５３０は任意の管理対象クラスに対して新たな属性を追加したり、既に存在する属性を削除する。
【００５５】
次に、包含木メンテナンス部５４０は管理対象ネットワークの構成が変更されることによる包含木の変更を行う。包含木メンテナンス部５４０は包含関係ファイルの親子あるいは兄弟のポインタの付け変えを行うことにより、包含木の変更を行う。
【００５６】
次に、ガーベージコレクション部５５０は包含関係ファイル及びインスタンスファイルに未使用領域が散らばった場合にこれを１つにまとめる。
【００５７】
次に、表示処理部５６０はインスタンスファイル内の管理情報を表示するものである。オペレータはこの表示処理部５６０からの管理情報の出力を監視することにより、管理対象の状態を把握する。
【００５８】
また、５７０は包含関係ファイル及びインスタンスファイルを生成するファイル生成部である。
【００５９】
以下、これらデータベースアクセス部５００に設けられた各部の処理について説明する。
【００６０】
〔ファイル生成部５７０の処理〕
図９を用いてファイル生成部が包含関係ファイル及びインスタンスファイルを生成する手順について説明する。ファイル生成部５７０は、このマネジメント・インフォメーション・ベースを生成する場合に最初に一度だけ実行されるものである。図１０はＭＩＢの初期状態を示す図である。生成前の状態なので、まだなにも存在しない。
まず、Ｓ１において包含木の深さレベル毎に包含関係ファイルを生成する。この状態を図１１に示す。まだなにも登録されていない、空の包含関係ファイルだけが、ＭＩＢのなかに存在する。
次に、Ｓ２において管理対象クラス毎にインスタンスファイルを生成する。この包含関係ファイルの生成とインスタンスファイルの生成は順序を逆に行ってもかまわない。この時点では単にファイルが生成されるだけであり、ファイルの内容については何も登録されていない。この状態を図１２に示す。
次に、Ｓ３において親子、兄弟を示すポインタを付加して包含関係ファイルにインスタンス毎のデータを登録する。前述したように、包含関係ファイル間でインスタンスの親子関係を保持し、個々の包含関係ファイル内でインスタンスの兄弟関係を保持するようにポインタ付けを行う。この状態を図１３に示す。
次に、Ｓ４において管理対象に対応するインスタンスをインスタンスファイルに登録する。インスタンスファイルに登録されたインスタンスは包含関係ファイルからリンク付けがなされる。この時点ではインスタンスファイルに登録されたインスタンスはまだ管理情報の領域を有しているのみであり、実際の属性値はまだ収集されていない。この状態を図１４に示す。
次に、Ｓ５において管理対象からの管理情報を収集し、得られた属性値を対応するインスタンスの管理情報としてインスタンスファイルに記憶する。この状態を図１５に示す。
【００６１】
このようにしてファイル生成部５７０は包含関係ファイルとインスタンスファイルを生成し、この生成終了により管理動作を開始することができる。なお、このファイル生成後においても、新たにインスタンスファイルが作られる場合、あるいはインスタンスファイルに新たなインスタンスを追加する場合が存在する。これらの動作については管理対象クラスメンテナンス部５１０及びインスタンスメンテナンス部５２０の処理において説明する。
【００６２】
〔管理対象クラスメンテナンス部５１０の処理〕
以下に管理対象クラスメンテナンス部５１０における処理を管理対象クラスの追加と削除に分けて説明する。
【００６３】
（１）管理対象クラスの追加
前述したように、インスタンスファイルは管理対象クラスに対応して複数生成される。従って、管理対象ネットワークの中に新たな管理対象クラスを持つ管理対象が追加された場合には、その新たな管理対象クラスに対応するインスタンスファイルが生成されなければならない。インスタンスファイルを生成する場合、インスタンスファイルのファイル名には図７に示したように管理対象クラスのオブジェクト識別子を用いる。
このように、管理対象クラス毎の最大属性数と属性値の最大サイズ、及び初期状態の空き管理データだけを持つインスタンスファイルを事前に用意しておく。この初期状態のインスタンスファイルの生成は、オンライン運転中も可能である。
例えば、オンライン運転中にインスタンスファイルに対してのアクセスをロックすることによりインスタンスファイルに対して排他制御を行うことができ、その排他制御を行っている間にインスタンスファイルを生成することができる。
追加した管理対象クラスに属するインスタンスを追加する場合は、その管理対象クラスのオブジェクト識別子より、インスタンスファイルのファイル名を特定する。このようにして、追加するインスタンスは、すでに用意しておいたインスタンスファイルに格納される。なお、管理対象クラスを新たに追加する場合、包含関係ファイルに対する処置は不要である。すなわち、包含関係ファイルに対して管理対象クラスメンテナンス部５１０は特別な処理を行わない。
（２）管理対象クラスの削除
管理対象ネットワークから管理対象が削除され、その管理対象が属している管理対象クラスを削除する場合、その管理対象クラスに対応するインスタンスファイルを削除する。
削除対象となる管理対象クラスのインスタンスファイルを、その管理対象クラスのオブジェクト識別子により検索し、登録されているインスタンスのインスタンス名を得る。このインスタンス名を使用して、包含関係ファイルからのインスタンスの削除及びインスタンスファイルからのインスタンスの削除を実施する。
（インスタンスの削除については後述する。）
以上の処理を削除対象となるクラスのインスタンスファイルに登録されているすべてのインスタンスに対して繰り返す。登録されているインスタンスが存在しなくなったら、削除対象となるクラスのインスタンスファイルを削除する。ＭＩＢのデータベース全体に排他制御を行うことにより、管理対象クラスの削除はオンライン運転中も可能である。
【００６４】
〔インスタンスメンテナンス部５２０の処理〕
次に、インスタンスメンテナンス部５２０の処理を包含関係ファイルに対する処理とインスタンスファイルに対する処理に分けて説明する。
管理対象ネットワークに対して新たな管理対象が追加された場合、その管理対象をインスタンスとして包含関係ファイル及びインスタンスファイルに追加する処理を行う。逆に、管理対象ネットワークから管理対象が取り除かれた場合には、包含関係ファイル及びインスタンスファイルから対応するインスタンスを削除する。
＜包含関係ファイルに対する処理＞
（１）インスタンスの追加
（ａ）インスタンスを追加する場合には、そのインスタンスの深さレベルに応じた包含関係ファイルを検索し、格納すべき兄弟格納領域を検索する。検索した兄弟格納領域の中に既に他の兄弟が存在する場合は、その兄弟格納領域の未使用領域にインスタンスを追加する。
（ｂ）兄弟が存在していない場合は、まだ兄弟格納領域が確保されていないので、新たな兄弟格納領域を確保し、その中にインスタンスを追加する。その後、確保した兄弟格納領域を親からポイントする。
（２）インスタンスの削除
（ａ）削除しようとするインスタンスが子を持っている場合は、子孫削除のオプション指定がない場合、削除失敗とする。または、削除するインスタンスが子を持っている場合で、子孫削除のオプション指定がある場合、子孫もすべて削除する。
（ｂ）削除しようとするインスタンスが子を持っていない場合は、そのインスタンスを削除する。削除した結果、兄弟が存在しなくなった場合すなわち、そのインスタンスの親が子を持たなくなった場合は、兄弟格納領域を解放し、親が持っている子へのポインタをクリアする。
＜インスタンスファイルに対する処理＞
（１）インスタンスの追加
前述した包含関係ファイルにおけるインスタンスの追加が成功した場合に、該当インスタンスが属するクラスのインスタンスファイルに管理情報を格納し、包含関係ファイル上のインスタンスポインタが管理情報を格納したレコードを指すようにする。
（２）インスタンスの削除
前述した包含関係ファイルにおけるインスタンスの削除が成功した場合、該当インスタンスをインスタンスファイルから削除する。
なお、包含関係ファイル、インスタンスファイルともに、インスタンスを追加した場合は、フラグを使用中にセットする。削除の場合は、フラグをリセットし、未使用とする。
【００６５】
〔管理情報サイズメンテナンス部５３０の処理〕
任意の管理対象クラスに対して、属性を追加または削除した場合の処理を以下に示す。
ここで属性の追加とは、あるインスタンスが持つ管理情報の属性の数を増加させる場合、あるいはインスタンスの管理情報の属性のサイズが増加する場合の何れかをいう。
例えば、図１６に示す管理情報の場合には、最大属性数が６個であり、属性値最大サイズが８バイトの場合を示している。そして、属性１から属性４が管理情報として格納されている。このような状態で、例えば新たに属性５が追加された場合には、まだ未使用領域が存在しているため、この未使用領域を用いて属性５を記憶することができる。あるいは、属性１から属性４まで存在している状態で新たに３つの属性を追加する場合、未使用領域は２つしか残っていないため、最大属性数６を越えて属性を記憶する必要性が生ずる。
また、一方、属性４のサイズが変更され３２バイト使用するような変更が生じた場合には、格納領域が足らなくなる。このように任意の管理対象クラスに対して属性が追加された場合、すなわち属性の数を増加させる場合およびサイズが変更された場合には以下のような処理を行う。また、属性を削除する場合にも同様に以下のような処理を行う。
【００６６】
（ａ）属性を追加してもクラス毎にインスタンスファイルに持っている最大属性数、属性値最大サイズが変わらない場合は、なにもしない。
（ｂ）属性を追加または削除した結果、クラス毎のインスタンスファイルに持っている最大属性数、属性値最大サイズに変更が必要な場合は、属性追加／削除後の最大属性数、属性値最大サイズ及び初期状態の空き管理データだけを持つテンポラリファイルを用意する。このとき、テンポラリファイルの各レコードサイズは、テンポラリファイルに設定した最大属性数、属性値最大サイズより決まる。
図１７はインスタンスファイルに持っている最大属性数及び属性値最大サイズに変更が生じ、テンポラリファイルを生成した場合を示している。インスタンスファイルの最大属性数＝６がテンポラリファイルにおいては８に変更されている。また、同じくインスタンスファイルの属性値最大サイズ＝８がテンポラリファイルにおいては１６に変更されている。また、インスタンスファイルにおいて管理情報のサイズは６×８バイトであったものがテンポラリファイルの管理情報のサイズは８×１６に変更されている。
次に該当のインスタンスファイルの空き管理データをテンポラリファイルの空き管理データにコピーする。該当インスタンスファイルの各レコードの内容をテンポラリファイルの同一のレコード位置に追加して行く。属性削除の場合は、削除する属性を除いた管理情報をコピーする。すべてのレコードを移し終えてから、インスタンスファイルを削除し、テンポラリファイルのファイル名を削除したインスタンスファイルのファイル名に変更する。このファイル名変更の処理までをＭＩＢのデータベース全体に排他制御でロックをかけることにより、オンライン運転中でも属性の追加／削除が可能となる。
【００６７】
なお、この時点では、新しいインスタンスファイルには元のインスタンスファイルにあったデータと同じものがコピーされただけであり、追加された属性あるいはサイズが増加した属性の新たな属性値はまだ記録されていない。従って、新しいインスタンスファイルに登録されているインスタンスの属性値を収集し、管理情報を最新の状態に更新する。
例えば、図５に示す管理情報に対して新たに使用時間という属性を追加する場合には、新たな属性として追加された使用時間の値が属性値として登録されていないため、マネージャはエージェントに対して各管理対象の使用時間を通知するような指示を出す。エージェントは管理対象から使用時間の通知を受け、各インスタンスに対して使用時間という属性値を記憶することにより、インスタンスファイルの管理情報を最新の状態にする。
【００６８】
〔包含木メンテナンス部５４０の処理〕
次に、管理対象ネットワークの構成が変更され、包含木を変更しなければならない場合の処理について説明する。
図１８において、インスタンス１３１を境に包含関係１４１から包含関係１４２に変更となった場合を例にとって新しい包含関係をデータベースに反映する処理を以下に説明する。図１８において、１３１〜１３６はネットワークを構成するインスタンスである。１４１はネットワーク構成変更前のインスタンスの包含関係を示し、１４２は変更後のインスタンスの包含関係を示す。１４５，１４６はデータベース上の包含関係を１４１から１４２に変更するまでの過程において発生する包含関係を示す。
【００６９】
ネットワークの構成が変更された場合には、まずエージェントが包含木に変更があったことを管理対象ネットワークから知らされることにより包含関係１４２を認識する。それに対してマネージャは以前の包含関係１４１を記憶しており、包含関係１４１と包含関係１４２には矛盾がある。そこでマネージャはエージェントが認識した包含木と同様の包含木を認識するために以下のような処理を行う。
マネージャはエージェントを経由して、包含関係変更があったインスタンス１３１から、ＯＳＩ管理のプロトコルを利用して、１レベル下位のインスタンスを得る。その結果インスタンス１３２，１３５が得られる。マネージャの管理するデータベース上は、包含関係１４１となっているため、包含関係にインスタンス１３５を追加し、その結果包含関係１４５となる。
次にマネージャは、エージェントを経由して、インスタンス１３２から、ＯＳＩ管理のプロトコルを利用し、１レベル下位のインスタンスを得る。その結果、インスタンス１３３が得られる。マネージャの管理するデータベース上は包含関係１４５となっているため、包含関係１４５からインスタンス１３４を削除する。その結果、包含関係１４６となる。
次に、マネージャは同様にインスタンス１３５からＯＳＩ管理のプロトコルを利用し１レベル下位のインスタンスを得る。その結果、インスタンス１３６が得られる。マネージャの管理するデータベース上は包含関係１４６となっているため、包含関係１４６にインスタンス１３６を追加する。
同様の処理をインスタンス１３３，１３６の順に実施すると、インスタンス１３３，１３６の下位のインスタンスは存在しない。従って、包含関係に対する新たな変更は生じない。このようにして、ネットワーク管理のためのデータベース上も包含木は包含関係１４２となり、実際の管理対象ネットワークの構成と一致する。
前述したように包含関係の変更前後で境となったインスタンス１３１が明確でない場合は、マネージャはインスタンス１３１のかわりに、ｒｏｏｔから同様に１レベル毎に下位のインスタンスの構成を変更後の包含関係に合わせていくことにより、データベースを最新の状態に保つことができる。
【００７０】
〔ガーベージコレクション部５５０の処理〕
ガーベージコレクション部５５０は包含関係ファイルあるいはインスタンスファイルにインスタンスの追加、削除が行われることにより生じた無駄な領域を削除する。
前述したデータベースの構造では、インスタンスの追加／削除を繰り返すことにより、無駄な領域がでてくる。この無駄な領域を削除するための処理を以下に示す。
【００７１】
＜包含関係ファイルのファイル容量縮少＞
下記の２通りの方法で縮少する。
（１）図２において、ポインタ１２１が指すように兄弟格納領域が複数カ所にまたがっている場合で、以下の式が成り立つとき、数カ所の領域にちらばっている兄弟をさらに少ない領域にまとめて、解放された兄弟格納領域を増やす。
兄弟の合計数≦（兄弟が使用している兄弟格納領域数−１）×（１つの兄弟格納領域に格納できる最大兄弟数）
図１９は、包含関係ファイルの兄弟格納領域をまとめる場合を示す図である。図１９（ａ）において、包含関係ファイルには兄弟１、兄弟２、兄弟３の３つの兄弟が記憶されている。この３つの兄弟が使用している兄弟格納領域は兄弟格納領域４１，４２，４３である。従って、兄弟が使用している兄弟格納領域数は３となる。また、１つの兄弟格納領域に格納できる最大兄弟数はこの例においては２である。従って、図１９（ｃ）に示す計算式の通り条件が成り立つために数カ所の領域に散らばっている兄弟を少ない領域にまとめる。図１９（ｂ）に示すように、この例においては３つの兄弟は兄弟格納領域４１と４２に格納され、兄弟格納領域４３は解放される。
（２）図２０は包含関係ファイルの縮少例を示す。図２０において（ａ）はインスタンスの追加／削除の結果、ある深さレベルの包含関係ファイル内で使用中の兄弟格納領域と未使用の兄弟格納領域がランダムに並んでいる様子を示す。（ｂ）は包含関係ファイルの縮少処理により使用中の兄弟格納領域と未使用の兄弟格納領域がソートされた様子を示す。包含関係ファイルのうちのある深さレベルのファイルにおいて、図２０（ａ）のように使用中の兄弟格納領域と未使用の兄弟格納領域がランダムに並んでいる場合、使用中の兄弟格納領域の内容を、ファイル先頭からの相対位置が自領域よりも近い未使用の兄弟格納領域に移し、この兄弟の親が持つ子へのポインタも書き換える。上記の処理を繰り返し、図２０（ｂ）に示すようにファイルの先頭からは、使用中の兄弟格納領域が連続して並び、その次から未使用の兄弟格納領域が連続して並ぶようにする。次にファイルの先頭から使用中の兄弟格納領域すべてをテンポラリのファイルにコピーし、さらにテンポラリファイルを元の包含関係ファイルに上書きする。テンポラリファイルは削除する。この結果、包含関係ファイルは縮少される。
【００７２】
＜インスタンスファイルの縮少＞
図２１はインスタンスファイルの縮少例を示す。図２１において（ａ）はインスタンスの追加／削除の結果、あるクラスのインスタンスファイル内で使用中のインスタンス毎の管理情報格納領域と未使用の管理情報格納領域がランダムに並んでいる様子を示す。（ｂ）はインスタンスファイルの縮少処理により使用中の管理情報格納領域と未使用の管理情報格納領域がソートされた様子を示す。
任意のクラスのインスタンスファイルにおいて、図２に示すような管理情報格納領域８１，８２が、図２１（ａ）のように使用中、未使用とランダムに並んでいる場合、使用中の管理情報格納領域の内容を、ファイル先頭からの相対位置が自領域よりも近い未使用の管理情報格納領域に移す。包含関係ファイルのインスタンスポインタも移動先のポインタに書き換える。以上の処理を繰り返し、図２１（ｂ）に示すように、ファイルの先頭からは、使用中の管理情報格納領域が連続して並び、その次から未使用の管理情報格納領域が連続して並ぶようにする。次にファイルの先頭から使用中の管理情報格納領域すべてをテンポラリのファイルにコピーし、さらにテンポラリファイルを元のインスタンスファイルに上書きする。テンポラリファイルは削除する。この結果、インスタンスファイルは縮少される。
【００７３】
以上のガーベージコレクション処理は、ＭＩＢのデータベース全体に排他制御でロックをかけることにより、オンライン運転中でもデータベース全体の縮少が可能となる。
【００７４】
〔表示処理部５６０の処理〕
図２２は、本実施例によるデータ構造を用いたＭＩＢを有するネットワーク管理装置の構成例を示す。３１は本実施例によるデータ構造を用いたＭＩＢを示す。５１０〜５５０は前述のデータベースを更新し、ユーザとのインタフェースは持たない処理群を示す。これに対し、５６０はＭＩＢの内容をユーザに対して表示する表示処理部である。３０４は表示処理部５６０がＭＩＢ表示処理の終了時刻を格納するためのファイルを示す。
図２２において、ＭＩＢ表示処理終了時に、ＭＩＢ表示処理終了時刻をＭＩＢ表示処理終了時刻ファイル３０４に格納しておく。ＭＩＢ表示処理が実行されていない間も、更新処理部５１０〜５５０がＭＩＢを更新し、その都度、インスタンスファイルの各インスタンス毎に持つ更新時刻を更新する。次に、表示処理部５６０が立ち上がった時、前回のＭＩＢ表示処理終了時刻とインスタンスファイル内の更新時刻を比較し、前回のＭＩＢ表示処理終了時刻より後で更新されたインスタンスの管理情報をピックアップし表示する。
例えば、ＭＩＢ表示処理終了時刻ファイル３０４が表示処理終了時刻として１０：００を記憶しており、表示処理部５６０がその後起動された場合には、ＭＩＢのインスタンスの更新時刻が１０：００よりも遅いものを選択し表示する。この処理により常にＭＩＢの内容を表示させておく必要はなくなり、効率的なネットワーク管理システムの運用が可能となる。インスタンス毎の更新時刻は、インスタンスファイルではなく、包含関係ファイルに持っても同様の作用が可能である。
【００７５】
以上のように、この実施例は、ＯＳＩ管理のＭＩＢの内部構造において、インスタンスの包含関係を格納する部分と、インスタンスの管理情報を格納する部分に分けたことを特徴とする。
また、インスタンスの管理情報を格納する部分を管理対象クラス毎に分けたことを特徴とする。
また、前述の管理対象クラス毎に分けた管理情報格納部分に、そのクラスのインスタンスが持ち得る属性の数と各々の属性値の中の予想される最大サイズを持つことを特徴とする。
また、インスタンスの包含関係を格納する部分を、包含木の深さレベル毎に分けたことを特徴とする。
また、管理情報格納部分に、各インスタンスの管理情報の更新時刻を記憶することを特徴とする。
【００７６】
以上のように、この実施例に係るデータベースは、その内部構造にインスタンス間の包含関係を表した部分と、個々のインスタンスが持つ管理情報を格納する部分とがある。この包含関係を表した部分において、インスタンス間の親子、兄弟の関係を用いてインスタンスの包含関係を柔軟に追加削除可能とする。
また、包含関係ファイルを深さレベル毎に分け、各深さレベル毎に、１つの兄弟格納領域に格納できる最大の兄弟数を持つことにより、管理対象の包含関係に応じた値を設定できる。この結果、無駄な領域を確保しておく必要性を減らすことができる。
また、インスタンスをクラス毎に分け、各ファイル毎に、最大属性数、属性値の最大サイズを持つことにより、各クラス毎のインスタンスの管理情報格納領域のサイズをファイル毎に固定値として、無駄な領域を確保しておく必要性が少なくなる。
【００７７】
実施例２．
以下、この発明の他の実施例を図２３に基づいて説明する。図２３において、１１，１２，１３はそれぞれ深さレベル１，２，３の包含関係ファイルである。この包含関係ファイルによって包含関係を表現する。２１，２２，２３はそれぞれのクラス毎のインスタンスファイルである。このインスタンスファイルの中に管理情報を格納する。１５１，１５２はそれぞれ自分の親、子を指すポインタである。１５３，１５４はそれぞれ自分の兄、弟を指すポインタである。１６１は包含木中の深さレベルとレコードＮｏを用いて包含関係ファイル中の当該インスタンスを指すポインタである。１６２はクラス名とインスタンスポインタを用いてインスタンスファイル中の当該インスタンスを指すポインタである。
また、フラグ１６３は空き管理用に用いるフラグである。また、深さレベル１６４は包含木中の深さレベルを示すものである。また、インスタンス名６６はインスタンスの識別名が記憶される。属性数６７は各々のインスタンスが使っている属性の数を記憶する。また、属性の大きさ６８は各々のクラスの属性の最大値が記憶できる大きさである。また、属性領域の大きさ６９は各々のクラスの属性の最大数分の領域を確保したものである。また、属性は制御フラグ６８ａと属性ＩＤ６８ｂと属性値６８ｃから構成されている。制御フラグ６８ａは属性値６８ｃをアクセスする場合の制御に用いるものである。例えばアクセス時間、あるいはアクセス件等を記憶する。属性ＩＤ６８ｂは属性値６８ｃの種別を表す識別子が記憶される。
この実施例におけるインスタンス間の親子、兄弟の関係は親と子、兄と弟を互いにポイントし合う形をとる点が前述した実施例と異なる点である。従って、前述した実施例では兄から弟へのポインタのみが存在していたのに対して、この実施例においては弟から兄を指すポインタが存在している。また、前述した実施例では親から子を指すポインタのみが存在していたのに対して、この実施例では子から親を示すポインタが存在している。さらに、包含関係ファイルとインスタンスファイルの関係においては前述した実施例においては、包含関係ファイルからインスタンスファイルをポイントしていたのに対して、この実施例ではインスタンスファイルから包含関係ファイルをポイントできるようになっている。
このようにこの実施例では相互に参照することが可能になるため、途中の要素の追加削除が容易なデータベースが構築される。従って、包含関係をより柔軟に追加、削除することが可能となる。
また、この実施例が前述した実施例と異なる点は、兄弟格納領域というブロック化された領域を設けることなく、１つのインスタンス単位に包含関係ファイルにインスタンスを追加できる点である。
【００７８】
実施例３．
次に、図２４から図２６を用いて具体的なファイル構成及び具体的なデータ構造について説明する。図２４はこの実施例におけるファイル名を示しており、ここでは包含関係ファイルをｓｕｂｔｒｅｅ＿ｆｉｌｅとしている。また、インスタンスファイルはｉｎｓｔａｎｃｅ＿ｆｉｌｅとしている。次に、図２５、図２６はファイルの構成を示す図である。これらのファイルはインスタンスの包含関係と属性値を格納するためのデータベースを構成している。
ｓｕｂｔｒｅｅ＿ｆｉｌｅ１１，１２には、包含関係が格納され、包含木の深さレベル毎にファイルが分かれている。ｉｎｓｔａｎｃｅ＿ｆｉｌｅ１１，１２に属性値が格納され、クラス毎にファイルが分かれている。アプリケーションは、共通のアプリケーションプログラムインターフェース（ＡＰＩ）を使ってアクセスできる。
【００７９】
＜ｓｕｂｔｒｅｅ＿ｈｅａｄｅｒ１１ｈ＞
各ｓｕｂｔｒｅｅ＿ｆｉｌｅ１１の制御データが入る構造体である。
＜ｓｕｂｔｒｅｅ＿ｒｅｃｏｒｄ６０＞
ｓｕｂｔｒｅｅ＿ｒｅｃｏｒｄ６０以下のｓｕｂｔｒｅｅ＿ｉｔｅｍ６１，６２には、同一の親を持つインスタンス（各インスタンスの兄弟）を格納する。ｓｕｂｔｒｅｅ＿ｒｅｃｏｒｄ６０は、これらのｓｕｂｔｒｅｅ＿ｉｔｅｍ６１，６２を管理するための構造体である。同一の親を持つインスタンスが、一つのｓｕｂｔｒｅｅ＿ｒｅｃｏｒｄ６０に入り切らない場合は、他のｓｕｂｔｒｅｅ＿ｒｅｃｏｒｄに残りのインスタンスを格納する。
＜ｓｕｂｔｒｅｅ＿ｉｔｅｍ６１＞
各インスタンス毎に存在し、ＲＤＮ、下位のｓｕｂｔｒｅｅ（子のインスタンス）へのポインタ（ｃｈｉｌｄ＿ｒｅｃｏｒｄ）１０１、クラス１１１ｂ、及び、ｉｎｓｔａｎｃｅ＿ｆｉｌｅにおいて属性値を格納しているレコードのレコード番号（ｉｎｓｔａｎｃｅ＿ｎｕｍｂｅｒ）１１１ａを持つ。
【００８０】
＜ｉｎｓｔａｎｃｅ＿ｈｅａｄｅｒ２１ｈ＞
各ｉｎｓｔａｎｃｅ＿ｆｉｌｅ２１の制御データが入る構造体である。
＜ｉｎｓｔａｎｃｅ＿ｒｅｃｏｒｄ２７，２８＞
各インスタンスの属性値が入る構造体である。
【００８１】
次に図２６を用いてデータ構造について説明する。
＜ｓｕｂｔｒｅｅ＿ｈｅａｄｅｒ１１ｈ＞
（１）ｆｉｒｓｔ＿ｆｒｅｅ＿ｒｅｃｏｒｄ１１ｐ
ｓｕｂｔｒｅｅ＿ｆｉｌｅ１１の空きのｓｕｂｔｒｅｅ＿ｒｅｃｏｒｄ６０ｂ，６０ｃは、ポインタによって次々にリンクされている。ｆｉｒｓｔ＿ｆｒｅｅ＿ｒｅｃｏｒｄ１１ｐは、ｓｕｂｔｒｅｅ＿ｆｉｌｅ１１の最初の空きｓｕｂｔｒｅｅ＿ｒｅｃｏｒｄ６０ｂへのポインタである。但し、あるｓｕｂｔｒｅｅ＿ｒｅｃｏｒｄ６０ａが、”使用中”から”空き”になったとき、そのｓｕｂｔｒｅｅ＿ｒｅｃｏｒｄ６０ａは、ｆｉｒｓｔ＿ｆｒｅｅ＿ｒｅｃｏｒｄ１１ｐからポイントされ、直前にｆｉｒｓｔ＿ｆｒｅｅ＿ｒｅｃｏｒｄ１１ｐからポイントされていた空きのｓｕｂｔｒｅｅ＿ｒｅｃｏｒｄ６０ｂは、新しくｆｉｒｓｔ＿ｆｒｅｅ＿ｒｅｃｏｒｄ１１ｐからポイントされた空きｓｕｂｔｒｅｅ＿ｒｅｃｏｒｄ６０ａからポイントされる。
従って、ｆｉｒｓｔ＿ｆｒｅｅ＿ｒｅｃｏｒｄ１１ｐがｓｕｂｔｒｅｅ＿ｆｉｌｅ１１の物理的な先頭に一番近い空きｓｕｂｔｒｅｅ＿ｒｅｃｏｒｄをポイントしているとはかぎらない。空きｓｕｂｔｒｅｅ＿ｒｅｃｏｒｄもｓｕｂｔｒｅｅ＿ｆｉｌｅの先頭のほうから順にリンクしているとはかぎらない。
次の新しいｓｕｂｔｒｅｅ＿ｒｅｃｏｒｄを使用する場合は、ｆｉｒｓｔ＿ｆｒｅｅ＿ｒｅｃｏｒｄがポイントしているｓｕｂｔｒｅｅ＿ｒｅｃｏｒｄから使用していく。
＜ｓｕｂｔｒｅｅ＿ｒｅｃｏｒｄ６０ａ＞
（１）ｎｅｘｔ＿ｒｅｃｏｒｄ＿ｐｔｒ６０ｐ
そのレコードが”使用中”／”空き”を示すフラグを持つ。また、空きｓｕｂｔｒｅｅ＿ｒｅｃｏｒｄの場合は、次の空きｓｕｂｔｒｅｅ＿ｒｅｃｏｒｄへのポインタを持つ（次の空きｓｕｂｔｒｅｅ＿ｒｅｃｏｒｄがない場合は、ポインタとして、ＮＵＬＬが入る）。
使用中のレコードの場合は、ポインタ部分（フラグ以外の部分）にＮＵＬＬが入る。但し、同一の親を持つインスタンスが、一つのｓｕｂｔｒｅｅ＿ｒｅｃｏｒｄに入り切らない場合は、他のｓｕｂｔｒｅｅ＿ｒｅｃｏｒｄに残りのインスタンスを格納するため、そのｓｕｂｔｒｅｅ＿ｒｅｃｏｒｄへのポインタを格納する。同一の親を持つインスタンスが複数のｓｕｂｔｒｅｅ＿ｒｅｃｏｒｄに格納された場合、親は最初に作成されたｓｕｂｔｒｅｅ＿ｒｅｃｏｒｄへのポインタを持ち、残りのｓｕｂｔｒｅｅ＿ｒｅｃｏｒｄは、ｎｅｘｔ＿ｒｅｃｏｒｄ＿ｐｒｔ６０ｐにより作成順にリンクされていく。
複数のｓｕｂｔｒｅｅ＿ｒｅｃｏｒｄへ、同一の親を持つインスタンスを格納した後で、それらのインスタンスがいくつかが削除されても、一つのｓｕｂｔｒｅｅ＿ｒｅｃｏｒｄへまとめることはしない。
（２）ｆｉｒｓｔ＿ｆｒｅｅ＿ｉｔｅｍ６０ｉ
ｓｕｂｔｒｅｅ＿ｒｅｃｏｒｄ６０ａにおける空きのｓｕｂｔｒｅｅ＿ｉｔｅｍ６２，６４の管理方法は、ｓｕｂｔｒｅｅ＿ｆｉｌｅ１１における空きのｓｕｂｔｒｅｅ＿ｒｅｃｏｒｄ６０ｂ，６０ｃの管理方法と同じ（空きのｓｕｂｔｒｅｅ＿ｉｔｅｍをポインタでつないでいく）である。ｆｉｒｓｔ＿ｆｒｅｅ＿ｉｔｅｍ６０ｉは、ｓｕｂｔｒｅｅ＿ｒｅｃｏｒｄ６０ａにおける最初の空きｓｕｂｔｒｅｅ＿ｉｔｅｍ６２へのポインタを持つ。
【００８２】
＜ｓｕｂｔｒｅｅ＿ｉｔｅｍ６１＞
（１）ｃｈｉｌｄ＿ｒｅｃｏｒｄ１０１
ｎｅｘｔ＿ｒｅｃｏｒｄ＿ｐｔｒ６０ｂと同様に、ｓｕｂｔｒｅｅ＿ｉｔｅｍの”使用中”／”空き”を示すフラグを持つ。
また、空きｓｕｂｔｒｅｅ＿ｉｔｅｍ６２の場合は、次の空きｓｕｂｔｒｅｅ＿ｉｔｅｍ６４へのポインタを持つ（次の空きｓｕｂｔｒｅｅ＿ｉｔｅｍがない場合は、ポインタとしてＮＵＬＬが入る）。
使用中のｓｕｂｔｒｅｅ＿ｉｔｅｍ６１の場合は、ポインタ部分（フラグ以外の部分）にＮＵＬＬ、または、下位のｓｕｂｔｒｅｅ＿ｆｉｌｅのｓｕｂｔｒｅｅ＿ｒｅｃｏｒｄへのポインタ（子インスタンスへのポインタ）が入る。
（２）ｉｎｓｔａｎｃｅ＿ｎｕｍｂｅｒ１１１ａ
ｃｌａｓｓ１１１ｂが示すｉｎｓｔａｎｃｅ＿ｆｉｌｅ２１の中で、属性値を格納しているレコードのレコード番号を持つ。
（３）ｃｌａｓｓ１１１ｂ
当該インスタンスが属する管理オブジェクトクラスが入る。
（４）ｒｄｎ
当該インスタンスのＲＤＮが入る。
【００８３】
＜ｉｎｓｔａｎｃｅ＿ｈｅａｄｅｒ＞
（１）ｆｉｒｓｔ＿ｆｒｅｅ＿ｉｎｓｔａｎｃｅ７２
ｉｎｓｔａｎｃｅ＿ｆｉｌｅ２１における空きのｉｎｓｔａｎｃｅ＿ｒｅｃｏｒｄ２７，２９の管理方法は、ｓｕｂｔｒｅｅ＿ｆｉｌｅにおける空きのｓｕｂｔｒｅｅ＿ｒｅｃｏｒｄの管理方法と同じ（空きのｉｎｓｔａｎｃｅ＿ｒｅｃｏｒｄをポインタでつないでいく）である。ｆｉｒｓｔ＿ｆｒｅｅ＿ｉｎｓｔａｎｃｅ７２は、ｉｎｓｔａｎｃｅ＿ｆｉｌｅにおける最初の空きｉｎｓｔａｎｃｅ＿ｒｅｃｏｒｄ２７へのポインタを持つ。
【００８４】
＜ｉｎｓｔａｎｃｅ＿ｒｅｃｏｒｄ２７＞
（１）ｎｅｘｔ＿ｆｒｅｅ＿ｉｎｓｔａｎｃｅ２７ｐ
ｎｅｘｔ＿ｒｅｃｏｒｄ＿ｐｒｔ６０ｐと同様に、ｉｎｓｔａｎｃｅ＿ｒｅｃｏｒｄ２７の”使用中”／”空き”を示すフラグを持つ。また、空きｉｎｓｔａｎｃｅ＿ｒｅｃｏｒｄの場合は、次の空きｉｎｓｔａｎｃｅ＿ｒｅｃｏｒｄ２８へのポインタを持つ（次の空きｉｎｓｔａｎｃｅ＿ｒｅｃｏｒｄがない場合は、ポインタとして、ＮＵＬＬが入る）。
使用中のｉｎｓｔａｎｃｅ＿ｒｅｃｏｒｄ２８の場合は、ポインタ部分（フラグ以外の部分）にＮＵＬＬが入る。
（２）ｄｎ
当該インスタンスのＤＮが入る。
（３）ａｔｔｒｉｂｕｔｅ８１
当該ｉｎｓｔａｎｃｅ＿ｆｉｌｅ２１のクラスが持ち得る属性の最大数分存在する。各々のａｔｔｒｉｂｕｔｅ８１には、属性のオブジェクト識別子と属性値が入る。
【００８５】
以上のようにこの実施例では、ファイルの構成及びデータ構造の具体例について説明した。
【００８６】
実施例４．
実施例１においては、データベースの概要およびデータ構造を説明しながら、属性の例としては使用時間等をあげた。
次に、他の属性の具体例を示す。
【００８７】
例えば、属性として、管理対象毎のパスワードを格納すれば、端末から入力されたパスワードと照合して、ユーザーのアクセスを制御したり、管理対象である資源への不当なアクセスを防ぐことが可能である。これによって、ネットワーク管理機能のひとつとして、セキュリティ管理を実現できる。
【００８８】
実施例５．
また、属性として、使用時間の他に、送受信のデータ件数、送受信データ量等を記憶させるようにすれば、ネットワーク資源の使用量を測定し、ネットワークの負荷が、適正量を越えないように監視し、ネットワーク運用の最適化を図ることができる。
【００８９】
実施例６．
上記実施例に加えて、属性として更に金額を格納すれば、ネットワークの使用量を反映させた課金管理を行うことができる。
【００９０】
【発明の効果】
この発明によれば、管理情報はインスタンスファイルに格納され、インスタンスの包含関係は包含関係ファイルに格納される。このように、インスタンスの包含関係をマネジメント・インフォメーション・ベース・管理システムのなかに持つことができるので、ネットワーク管理の対象となる個々の資源の変更を、ネットワーク運用中にダイナミックに、マネジメント・インフォメーション・ベース・管理システムに反映させることが可能となる。
【００９１】
この発明によれば、インスタンスの包含関係は親子兄弟を示す包含木で表される。そのため、管理対象インスタンスの検索を効率的に行える。また、包含関係ファイルは、包含木の深さレベル毎に複数設けられている。このため、リソースの節約につながる。さらに、包含関係ファイルは、包含木の階層に沿って名前付けされているため、ファイル名を一意に容易に特定できる。
【００９２】
この発明によれば、個々の包含関係ファイルに、各ファイル毎に定められた所定数の兄弟を記憶する複数の領域が設けられている。このため、管理対象の包含関係に応じた適正な値をファイル毎に設定することが可能となるので、余分な領域を確保しておく必要がなくなる。
【００９３】
この発明によれば、管理対象に管理対象クラスを割り当て、その管理対象クラス毎にインスタンスファイルを複数設ける。これにより、ネットワーク内で、管理対象クラスの追加削除の要求が発生した場合、ネットワーク運用中でも、その追加削除をマネジメント・インフォメーション・ベース・管理システム上に反映することが可能となる。
【００９４】
この発明によれば、管理対象クラスメンテナンス部に、新たな管理対象クラスが追加された場合に、その管理対象クラスに対応するインスタンスファイルを生成する。このため、ネットワークにおける管理対象クラスの追加を、動的に、行える。必要に応じて、ファイル生成が可能なので、リソースの節約にもなる。
【００９５】
この発明に係るマネジメント・インフォメーション・ベース・管理システムは、インスタンスメンテナンス部が、新たなインスタンスが追加された場合、そのインスタンスが存在する深さレベルに対応する包含関係ファイルにそのインスタンスを追加し、そのインスタンスの管理対象クラスに対応するインスタンスファイルにそのインスタンスを追加するとともに、包含関係ファイルに追加したインスタンスからインスタンスファイルに追加したインスタンスをアクセスするポインタを付加する。このため、動的な、インスタンスの追加削除が可能となる。
【００９６】
この発明に係るマネジメント・インフォメーション・ベース・管理システムにおいて、インスタンスファイルは、インスタンスが持つ管理情報のサイズを記憶するサイズ記憶部を有している。これにより、管理対象クラスの属性に適合した管理情報サイズを設定できる。従来のように、管理情報格納部分にクラス毎の属性の種類を持たずに、クラス毎にインスタンスが持ち得る属性の最大数と各々の属性値の中の予想される最大サイズを持つことにより、属性の追加／削除が容易になり、リソースの節約につながる。
【００９７】
この発明に係るマネジメント・インフォメーション・ベース・管理システムにおいて、管理情報のサイズの変更があった場合、上記サイズ記憶部にある管理情報のサイズを新たなサイズに変更し、新たなサイズに基づいてインスタンスファイルを再生する管理情報サイズメンテナンス部を備えている。このため、従来のように、プログラムのコンパイルやリンクのやり直しをせず、オンライン運転中に属性の追加削除を動的に、容易に行うことができる。
【００９８】
この発明によれば、包含木メンテナンス部が、管理対象ネットワークの構成が変更されることによる包含木の変更があった場合、上記包含関係ファイルの親子あるいは兄弟のポインタの付け変えを行うことにより、包含木の変更を行う。このため、ネットワーク管理運用中に管理対象ネットワークの構成の変更があっても、柔軟に対応できる。
【００９９】
この発明によればガーベージコレクション部は、包含関係ファイルやインスタンスファイルのガーベージコレクションを行う。これにより、リソースを節約し、資源の有効活用を図ることができる。
【０１００】
この発明によれば表示処理部は、インスタンスファイルに記憶した各インスタンスの管理情報の更新時刻と、表示処理終了時刻を比較して、その比較に基づいてマネジメント・インフォメーション・ベース・管理システムの管理情報の表示を行う。このため、常に表示を継続させる必要が無くなり、ネットワーク管理システムの運用が効率的となる。
【０１０２】
以上のように、この発明によれば、ＯＳＩ参照モデルによるネットワーク管理のためのＭＩＢおよびその生成において、従来、静的に取り込んでいた管理対象の構成を、ネットワーク運用中に動的に変更することができ、より効率的なネットワーク管理の保守、運営を可能にした。
【図面の簡単な説明】
【図１】この発明の一実施例によるマネジメント・インフォメーション・ベースの概要を示す図である。
【図２】この発明の一実施例による包含関係ファイル、インスタンスファイルの詳細構造を示す図である。
【図３】この発明の一実施例による包含関係ファイルの一例を示す図である。
【図４】この発明の一実施例によるインスタンスファイルの一例を示す図である。
【図５】この発明の一実施例による管理情報の一例を示す図である。
【図６】この発明の一実施例による包含関係ファイルのファイル名を示す図である。
【図７】この発明の一実施例によるインスタンスファイルのファイル名を示す図である。
【図８】この発明の一実施例によるデータベースアクセス部を示す図である。
【図９】この発明のファイル生成部が包含関係ファイルおよびインスタンスファイルを生成する手順を示す図である。
【図１０】この発明のファイル生成部が包含関係ファイルおよびインスタンスファイルを生成する過程におけるＭＩＢの状態を示す図である。
【図１１】この発明のファイル生成部が包含関係ファイルおよびインスタンスファイルを生成する過程におけるＭＩＢの状態を示す図である。
【図１２】この発明のファイル生成部が包含関係ファイルおよびインスタンスファイルを生成する過程におけるＭＩＢの状態を示す図である。
【図１３】この発明のファイル生成部が包含関係ファイルおよびインスタンスファイルを生成する過程におけるＭＩＢの状態を示す図である。
【図１４】この発明のファイル生成部が包含関係ファイルおよびインスタンスファイルを生成する過程におけるＭＩＢの状態を示す図である。
【図１５】この発明のファイル生成部が包含関係ファイルおよびインスタンスファイルを生成する過程におけるＭＩＢの状態を示す図である。
【図１６】この発明の一実施例による最大属性数と属性値最大サイズを説明する図である。
【図１７】この発明の一実施例によるインスタンスファイルの管理情報サイズの変更を示す図である。
【図１８】この発明の一実施例によるデータベース上の包含木の変更例を示す図である。
【図１９】この発明の一実施例による包含関係ファイルの兄弟格納領域の縮小例を示す図である。
【図２０】この発明の一実施例による包含関係ファイルの縮少例を示す図である。
【図２１】この発明の一実施例によるインスタンスファイルの縮少例を示す図である。
【図２２】この発明の一実施例によるネットワーク管理装置構成例を示す図である。
【図２３】この発明の他の実施例によるマネジメント・インフォメーション・ベースを示す図である。
【図２４】この発明の他の実施例によるファイル名を示す図である。
【図２５】この発明の他の実施例によるファイル構成を示す図である。
【図２６】この発明の他の実施例によるデータ構造を示す図である。
【図２７】従来の一般的なＯＳＩ管理システムを示す図である。
【図２８】従来のクラスとインスタンスの例を示す図である。
【図２９】従来の継承木の一例を示す図である。
【図３０】従来の包含木の例を示す図である。
【図３１】従来の継承木の論理構成図である。
【図３２】従来の継承木の物理構成図である。
【図３３】従来のマネジメント・インフォメーション・ベースのデータ構造を示す図である。
【符号の説明】
１  包含木
１１〜１２  深さレベル毎の包含関係ファイル
２１〜２３  管理対象クラス毎のインスタンスファイル
３１  マネジメント・インフォメーション・ベース
４１〜４４  兄弟格納領域
５１〜５３  兄弟格納領域の空き管理用データ
６１〜６４  包含木のためのインスタンス毎のデータ
７１  サイズ領域
８１，８２  インスタンス毎の管理情報
１０１，１０２  子を指すポインタ
１１１  管理情報を指すポインタ
１２１  残りの兄弟を指すポインタ
１３１〜１３５  ネットワークを構成するインスタンス
１４１  ネットワーク構成変更前の包含木
１４２  ネットワーク構成変更後の包含木
１４５，１４６  データベース上の包含木変更過程
２０１  包含関係ファイル縮少処理前の例
２０２  包含関係ファイル縮少処理によるソート後の例
２０３  インスタンスファイル縮少処理前の例
２０４  インスタンスファイル縮少処理によるソート後の例
３０４  ネットワーク管理装置におけるＭＩＢ表示処理終了時刻格納ファイル
５１０〜５６０  ネットワーク管理装置におけるＭＩＢ更新処理部
【図１】
0003714483.tif 000002
【図２】
0003714483.tif 000003
【図３】
0003714483.tif 000004
【図４】
0003714483.tif 000005
【図５】
0003714483.tif 000006
【図６】
0003714483.tif 000007
【図７】
0003714483.tif 000008
【図８】
0003714483.tif 000009
【図９】
0003714483.tif 000010
【図１０】
0003714483.tif 000011
【図１１】
0003714483.tif 000012
【図１２】
0003714483.tif 000013
【図１３】
0003714483.tif 000014
【図１４】
0003714483.tif 000015
【図１５】
0003714483.tif 000016
【図１６】
0003714483.tif 000017
【図１７】
0003714483.tif 000018
【図１８】
0003714483.tif 000019
【図１９】
0003714483.tif 000020
【図２０】
0003714483.tif 000021
【図２１】
0003714483.tif 000022
【図２２】
0003714483.tif 000023
【図２３】
0003714483.tif 000024
【図２４】
0003714483.tif 000025
【図２５】
0003714483.tif 000026
【図２６】
0003714483.tif 000027
【図２７】
0003714483.tif 000028
【図２８】
0003714483.tif 000029
【図２９】
0003714483.tif 000030
【図３０】
0003714483.tif 000031
【図３１】
0003714483.tif 000032
【図３２】
0003714483.tif 000033
【図３３】
0003714483.tif 000034