JP3029415B2 - データベース保守管理システム - Google Patents

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、データベースを使
用した通常業務処理が２４時間連続して行われるシステ
ムに搭載されその通常業務処理を停止することなくデー
タベースの保守管理を行うデータベース保守管理システ
ム、特にデータベースのメンテナンスの自動化に関す
る。

【０００２】

【従来の技術】図１７は、設備の保守管理を行うシステ
ムの全体構成図である。各地に点在しているエレベータ
やビル設備など（以下、単に「設備」という）１は、全
国を複数に分割されたブロック毎に設置された各情報セ
ンタ２によって管理される。各情報センタ２は、管轄内
の各設備１を２４時間体制で監視し、各顧客に関する情
報やクラアイントにおいて発生した異常を報告する障害
情報などをデータベース３に蓄積しながら集中管理する
ともにシステム全体を接続するネットワーク４を介して
他の情報センタ２との間で情報交換を行う。また、この
ネットワーク４には、全国各地に設置された営業所５も
接続されており、各営業所５は、設置された情報端末か
ら情報センタ２のデータベース３をアクセスすることに
よって様々な情報を取得している。ホストコンピュータ
６は、このネットワーク４に接続されている情報センタ
２、及び保守管理システムと他のシステムとを接続して
いる。

【０００３】各情報センタ２は、ルータ７、処理用クラ
イアント８、操作用クライアント９、サーバ１０及びバ
ックアップ用サーバ１１をＬＡＮ１２によって接続した
構成を有している。情報センタ２は、保守管理管轄内の
設備を２４時間体制で監視をしていなければならないの
で、通常の業務処理用のデータベース３を管理している
サーバ１０の他にバックアップ用サーバ１１を設けてい
る。このバックアップ用サーバ１１は、適宜更新された
情報がコピーされるなどしてサーバ１０と基本的には同
じデータベース３を保有している。処理用クライアント
８は、データベース３のバックアップの実行等のデータ
保全処理などのシステム管理を行う。また、操作用クラ
イアント９は、データベース３に蓄積したデータに基づ
き設備、顧客の管理・運用等通常の業務処理を行う。

【０００４】ところで、データベース３には、契約した
顧客、設備に関する情報、電話による通報に関する情
報、検出した障害に関する情報、更にホストコンピュー
タ６を介して他の情報システムから送られてきたマスタ
データの更新情報など様々なデータが登録、蓄積されて
おり、目的等に応じて複数に分類され管理されている。
また、データベース３には、収集された情報を加工して
種々の統計情報も業務処理のために集計され蓄積されて
いる。データベース３に蓄積されるデータには、定期メ
ンテナンス報告などのように定期的で定量的なものから
障害情報に代表されるように発生するタイミングや発生
データ量が未定なものまで含まれている。従って、各情
報センタに配属された管理者がデータベース３の使用状
況等を監視して適宜バックアップをとったり、ファイル
を移動したりデータベース３のメンテナンスをしてい
た。

【０００５】

【発明が解決しようとする課題】しかしながら、従来に
おいては、細かなデータベースの保守・管理は、人手に
よって行われており、自動的に行うことができなかっ
た。例えば、データベース全体を手動でバックアップす
ることはできても不要となったデータや重要なデータを
切り分けて適宜バックアップなどの処理を自動的にする
ことはできなかった。

【０００６】また、他の情報センタから送られてきた更
新用のマスタデータをマスタデータベースに反映させる
処理を自動的にすることはできなかった。

【０００７】また、データベースの検索時間などの性能
が劣化した場合に自動的に回復させるような機能はなか
った。

【０００８】このようなデータベースの保守管理作業に
は、専門的な知識が必要となるため、従来では、各情報
センタに専門的なスキルを有する技術者を配属して対応
するようにしていた。しかし、保守管理システムは、２
４時間体制で運用されているため、データベース管理者
に多大な業務負荷をかけてしまうか、各情報センタに複
数のデータベース管理者を配属するなどして対応しなけ
ればならず好ましい運用をしているとは言えない。

【０００９】本発明は以上のような問題を解決するため
になされたものであり、その目的は、業務運用中にデー
タベースのメンテナンスを自動的に行うことのできるデ
ータベース保守管理システムを提供することにある。

【００１０】

【課題を解決するための手段】以上のような目的を達成
するために、本発明に係るデータベース保守管理システ
ムは、データベースを使用した通常業務処理が２４時間
連続して行われるシステムに搭載されその通常業務処理
を停止することなく前記データベースの保守管理を行う
データベース保守管理システムにおいて、予め設定され
たバックアップ対象となるデータベース、当該各データ
ベースのバックアップ開始時刻、バックアップされたデ
ータベースに基づき生成する二次的データベース及び当
該各二次的データベースの生成処理開始時刻を保持する
データベース管理パラメータ記憶手段と、前記バックア
ップ開始時刻になった時点で対応する前記データベース
のバックアップを行うバックアップ処理手段と、前記生
成処理開始時刻になった時点で対応する前記二次的デー
タベースの生成処理を自動的に行うデータベース生成処
理手段と、データベースへのアクセス先を前記データベ
ース又は前記二次的データベースに振り分けるアクセス
制御手段とを有するものである。

【００１１】

【００１２】

【００１３】

【００１４】

【００１５】

【００１６】また、上記発明において前記機能処理を一
定周期で実行させる機能実行制御手段を有するものであ
る。

【００１７】

【００１８】

【発明の実施の形態】以下、図面に基づいて、本発明の
好適な実施の形態について説明する。本実施の形態にお
いては、本発明に係るデータベース保守管理システムが
提供する各機能を各実施の形態において説明する。

【００１９】実施の形態１．図１は、本発明に係るデー
タベース保守管理システムの実施の形態１を適用した設
備の保守管理を行うシステムの全体構成図である。基本
構成に関しては、従来例と同様である。すなわち、複数
に分割された各ブロックに含まれる各設備１は、ブロッ
ク毎に設置された情報センタ２０によって保守管理され
る。各情報センタ２０は、管轄内の各設備１を２４時間
体制で監視し、顧客情報や障害情報などをデータベース
に蓄積しながら集中管理するとともにシステム全体を接
続するネットワーク４を介して他の情報センタ２０との
間で情報交換を行う。また、このネットワーク４には、
全国各地に設置された営業所５も接続されており、各営
業所５は、設置された情報端末（以下、「遠隔クライア
ント」という）から情報センタ２０のデータベースをア
クセスすることによって様々な情報を取得している。ホ
ストコンピュータ６は、このネットワーク４に接続され
ている情報センタ２０、及び保守管理システムと他のシ
ステムとを接続している。

【００２０】図２は、本実施の形態において各情報セン
タ２０に設置されるデータベース保守管理システムの全
体構成図である。図２には、ルータ２１、複数台のサー
バ２２、ファイル転送クライアント２３及びデータベー
ス監視クライアント２４が示されている。これらは、Ｌ
ＡＮ２５によって接続されている。この情報センタ２０
によって保守管理される各設備１は、ルータ２１を介し
てアクセスされる。サーバ２２は、それぞれ１乃至複数
台の外部記憶装置、例えば磁気ディスク装置を搭載して
おり、各磁気ディスク装置に各種データベースを振り分
けて格納している。基本的にはデータベースを機能毎に
分類している。

【００２１】バックアップ用を含めた各種データベース
をどのサーバ２２のどの磁気ディスク装置に設けるか
は、説明をしない限り単なる設計事項である。ファイル
転送クライアント２３は、保守管理システムにおけるネ
ットワーク４を介してデータ通信を行うための通信端末
装置である。データベース監視クライアント２４は、デ
ータベース保守管理システムの主要部をなし、各サーバ
２２に格納されているデータベースの保守管理を行う。
なお、情報センタ２０には、その他にも図１７に示した
操作用クライアントに相当するクライアントコンピュー
タなどがＬＡＮ２５に接続されているが、本実施の形態
の特徴的な構成要素でないため図２から省略している。
図２に示したシステム構成は、後述する各実施の形態２
〜５においても共通する。

【００２２】図３は、図２に示したシステム構成の機能
ブロック図であって本実施の形態の特徴的なマスタメン
テナンス機能を説明するのに必要な構成要素のみ図示し
た。図３において、ファイル転送クライアント２３は、
他のシステムからホストコンピュータを介して送られて
きた更新用のマスタデータを受信するマスタデータ受信
部２６を有している。データベース監視クライアント２
４は、ファイル転送クライアント２３が受信したマスタ
データをマスタデータベース２７に自動的に反映させる
マスタ管理部２８を有している。マスタデータベース２
７には、保守管理先の設備に関する情報などこのシステ
ムのみならず他のシステムと共通して内容のデータなど
が登録されている。実際には、マスタデータベース２７
が複数設けられているが、本実施の形態では、便宜上１
つのみを示している。

【００２３】本実施の形態において特徴的なことは、以
上の構成を設けたことで他のシステムからマスタデータ
を受け取った時点でマスタデータベース２７を自動的に
更新できるようにしたことである。

【００２４】次に、本実施の形態におけるマスタメンテ
ナンス機能の処理について図４に示したフローチャート
を用いて説明する。

【００２５】保守管理システムでは、マスタデータ、例
えば新規のあるいは解約した顧客に関する情報が毎日情
報センタ２０に送られてくる。この送られてくる情報
は、ホストコンピュータ６によって前日のマスタデータ
と当日のマスタデータとを比較することによって得られ
たマスタデータの差分情報である。より詳細には、更新
すべきマスタデータと共にどのマスタデータベースに対
する新規／変更／削除処理かが当該情報に含まれてい
る。ファイル転送クライアント２３のマスタデータ受信
部２６は、ホストコンピュータ６からネットワーク４を
介して送られてくるマスタデータを受信する（ステップ
１０１）。ファイル転送クライアント２３は、マスタデ
ータを受信すると、マスタデータと共にその旨をデータ
ベース監視クライアント２４に通知する（ステップ１０
２）。データベース監視クライアント２４のマスタ管理
部２８は、その旨等を受け取った時点でそのマスタデー
タをマスタデータベース２７に反映させる（ステップ１
０３）。

【００２６】本実施の形態によれば、以上のように動作
するので、人手を介することなくマスタデータベース２
７の更新を自動的にすることができる。なお、マスタデ
ータベース２７が複数存在する場合、送られてくるマス
タデータにマスタデータベース名が付加されているの
で、更新すべきマスタデータベース２７を容易に特定す
ることができる。また、マスタ管理部２８は、情報セン
タ２０で内部で生成されたマスタデータの更新情報に対
しても同様にして当該更新情報に基づきマスタデータベ
ース２７を更新することができる。

【００２７】実施の形態２．図５は、本実施の形態にお
けるデータベース保守管理システムの機能ブロック構成
図である。図３と同様に本実施の形態の特徴的な履歴デ
ータの保存／削除機能を説明するのに必要な構成要素の
み図示した。本実施の形態における保守管理システムの
全体構成及び情報センタ２０の構成は、実施の形態１と
同様である。データベース監視クライアント２４は、パ
ラメータテーブル２９と履歴データベース管理部３０と
を有している。本実施の形態は、履歴データベース（Ｄ
Ｂ）３１に蓄積された故障履歴、発報履歴、フォロー履
歴などの履歴データの整理を行うためのデータ保存／削
除機能を提供することを特徴としているが、この履歴デ
ータの保存／削除機能の実行制御に必要なパラメータが
データベース管理パラメータ記憶手段として設けられた
パラメータテーブル２９に予め設定されている。本実施
の形態においては、履歴データベース３１への履歴デー
タ保存期間、待避対象とする履歴データを指定した待避
対象情報及び履歴データベース３１のための必要空き容
量が設定されている。このうち、待避対象とする履歴デ
ータを指定した待避対象情報というのは、次の理由で設
定される情報である。すなわち、履歴データの中には、
一定期間ではあるかもしれないが、その期間においては
業務処理遂行上常時参照されるため待避の対象とすべき
でないものが含まれているからである。従って、待避対
象情報には、待避の対象としてもよい履歴データが設定
されることになる。上記一定期間というのが履歴データ
保存期間に相当する。なお、待避対象情報としては、履
歴データ単位、履歴データテーブル単位、履歴データベ
ース単位など運用に適した単位での設定をすればよい。
また、図５に示したように履歴データベース３１がサー
バＡに格納されているとすると、他のサーバＢの保存用
履歴データベース３２が履歴データの待避先となるデー
タ保存手段として使用される。また、履歴データベース
管理部３０は、後述する条件下において履歴データベー
ス３１内の履歴データをサーバＢの保存用履歴データベ
ース（ＤＢ）３２に移動する。なお、本実施の形態にお
ける履歴データベース３１及び保存用履歴データベース
３２は、任意のサーバ２２の任意の磁気ディスク装置に
１乃至複数個設けることができるが、ここでは便宜上各
１個を示すことにする。

【００２８】次に、本実施の形態における履歴データの
保存／削除機能処理について図６に示したフローチャー
トを用いて説明する。

【００２９】前述した履歴データは、何もしなければ日
々履歴データベース３１に蓄積され膨大な量になってし
まう。そこで、履歴データベース管理部３０を常時稼動
させておき、履歴データベース３１の空き容量を一定周
期で常時監視させる（ステップ２０１）。履歴データベ
ース管理部３０は、履歴データベース３１の空き容量が
パラメータテーブル２９に設定されている必要空き容量
以下になったことを検出すると、その時点で履歴データ
ベース３１に蓄積されている履歴データを保存用履歴デ
ータベース３２に移動する。すなわち、移動対象となっ
た履歴データを保存用履歴データベース３２にコピーし
（ステップ２０２）、当該履歴データを履歴データベー
ス３１から削除する（ステップ２０３）。このとき、履
歴データベース管理部３０は、パラメータテーブル２９
に設定されている待避対象情報に基づき待避対象となっ
ている履歴データであって履歴データ保存期間を過ぎた
履歴データを保存用履歴データベース３２への移動対象
とする。なお、パラメータテーブル２９には、履歴デー
タ毎に履歴データ保存期間を設定することができる。

【００３０】本実施の形態によれば、履歴データベース
３１の空き容量が一定以下になった時点で条件に合致し
た履歴データを保存用履歴データベース３２に移動する
ようにしたので、履歴データベース３１のために空き領
域を自動的に確保することができる。また、移動対象と
なる履歴データをシステムにおける利用状況すなわち履
歴データの種類及び蓄積してからの経過時間を考慮して
特定している。

【００３１】なお、上記説明では、履歴データの待避先
を単一の保存用履歴データベース３２としたが、履歴デ
ータの種別によって異なる磁気ディスク装置あるいは異
なるサーバ２２に履歴データ保存手段を設けるようにし
てもよい。また、データベース管理パラメータ記憶手段
としてのパラメータテーブル２９をメモリ上に展開して
おいたり、ファイル形式で持たせておくことができる。
また、扱うデータも履歴データに限られたものではな
い。

【００３２】実施の形態３．図７は、本実施の形態にお
けるデータベース保守管理システムの機能ブロック構成
図である。図３と同様に本実施の形態の特徴的なバック
アップ機能を説明するのに必要な構成要素のみ図示し
た。本実施の形態における保守管理システムの全体構成
及び情報センタ２０の構成は、実施の形態１と同様であ
る。図７において、データベース監視クライアント２４
は、パラメータテーブル２９とバックアップ処理部３３
とを有している。本実施の形態におけるパラメータテー
ブル２９には、バックアップ対象となるデータベースの
名称と当該各データベースのバックアップ開始時刻とバ
ックアップ先とが予め設定されている。すなわち、所定
の時間（バックアップ開始時刻）になった時点で所定の
バックアップ先へバックアップをするデータベース名を
設定しておく。図８にパラメータテーブル２９への設定
例を示す。バックアップ処理部３３は、このバックアッ
プ処理を自動的に実行するための手段である。なお、本
実施の形態では、２世代のデータベースを保存するよう
にしているので、図８に示したように各データベースに
対して２箇所のバックアップ先が設定されている。

【００３３】次に、本実施の形態におけるバックアップ
機能処理について図９に示したフローチャートを用いて
説明する。

【００３４】バックアップ処理部３３は、常時所定の時
間間隔でシステム時刻とパラメータテーブル２９に設定
されているバックアップ開始時刻とを比較する（ステッ
プ３０１）。ここで、システム時刻がいずれかのバック
アップ開始時刻に達したとき、対応するデータベースの
バックアップ先に存在する先の世代のバックアップした
データベース（以下、「バックアップファイル」とい
う）を削除する（ステップ３０２，３０３）。なお、バ
ックアップ先の切替制御は、フラグ情報などにより行
う。そして、バックアップ先のボリューム（磁気ディス
ク装置）を初期化した後（ステップ３０４）、パラメー
タテーブル２９に設定されているディレクトリに当該デ
ータベースをコピーする（ステップ３０５）。もちろ
ん、当該ボリュームに他のファイルが存在する場合は初
期化しない。なお、バックアップ途中にデータベースア
クセスがあると、そのアクセスログが記録されるが、そ
の記録したログファイルをデータベースと共にバックア
ップをする。この後、上記フラグ情報を書き替えること
で次回のバックアップ先を指定する（ステップ３０
６）。

【００３５】本実施の形態によれば、指定した時刻（バ
ックアップ開始時刻）になった時点で設備の保守管理シ
ステムを停止することなく指定されたデータベースのバ
ックアップを自動的にとることができる。従って、バッ
クアップをとるべきデータベースが非常に多い場合でも
人手により多数のファイル名を入力させる必要がない。
この機能は、例えば、オラクル社のＳＱＬＢａｓｅ
５．１．４Ｊのオンラインバックアップ機能が提供する
コマンド（ＢＡＣＫＵＰ ＳＮＡＰＳＨＯＴ）を実行す
ることで実現できる。

【００３６】実施の形態４．図１０は、本実施の形態に
おけるデータベース保守管理システムの機能ブロック構
成図である。図３と同様に本実施の形態の特徴的なリス
トア機能を説明するのに必要な構成要素のみ図示した。
本実施の形態における保守管理システムの全体構成及び
情報センタ２０の構成は、実施の形態１と同様である。
図１０において、データベース監視クライアント２４
は、パラメータテーブル２９とリストア処理部３４とア
クセス制御部３５とを有している。本実施の形態におけ
るパラメータテーブル２９には、バックアップされたデ
ータベースに基づき生成する二次的データベースの名称
と、当該各二次的データベースの生成処理開始時刻と、
リストア先とが予め設定されている。すなわち、所定の
時間（リストア開始時刻）になった時点で所定のリスト
ア先へ二次的データベースを生成するデータベース名を
設定しておく。ここでいう二次的データベースというの
は、元のデータベースに対するアクセス負荷の分散を目
的として生成され、元のデータベースと基本的に同一内
容のデータベースである。本実施の形態では、バックア
ップファイルを元データとすることでこの処理の実行に
より元のデータベースを保有するサーバ２２への負荷を
軽減することができる。本実施の形態におけるパラメー
タテーブル２９にも図８と同様にして設定することにな
る。なお、本実施の形態では、二次的データベースを統
計データベースと称している。リストア処理部３４は、
このリストア処理を自動的に実行するための手段であ
る。アクセス制御部３５は、各クライアントからのデー
タベースへ要求に対してデータベースのアクセス先を元
のデータベース又は二次的データベースに振り分ける。

【００３７】次に、本実施の形態におけるリストア機能
処理について図１１に示したフローチャートを用いて説
明する。

【００３８】リストア処理部３４は、常時所定の時間間
隔でシステム時刻とパラメータテーブル２９に設定され
ているリストア開始時刻とを比較する（ステップ４０
１）。ここで、システム時刻がいずれかのリストア開始
時刻に達したとき、対応するデータベースのリストア先
に存在する先の統計データベースを削除する（ステップ
４０２，４０３）。そして、必要に応じて削除した統計
データベースを格納していたボリューム（磁気ディスク
装置）を初期化した後（ステップ４０４）、パラメータ
テーブル２９に設定されているディレクトリにバックア
ップファイルに基づき統計データベースを生成する（ス
テップ４０５）。

【００３９】本実施の形態によれば、指定した時刻（リ
ストア開始時刻）になった時点で設備の保守管理システ
ムを停止することなく指定された統計データベースを自
動的に再生成することができる。従って、リストアをと
るべきデータベースが非常に多い場合でも人手により多
数のファイル名を入力させる必要がない。この機能は、
例えば、オラクル社のＳＱＬＢａｓｅ ５．１．４Ｊの
オンラインリストア機能が提供するコマンド（ＲＥＳＴ
ＯＲＥ ＳＮＡＰＳＨＯＴ）を実行することで実現でき
る。

【００４０】このようにして、本実施の形態においては
統計データベースを生成するが、アクセス制御部３５
は、所定のクライアント、例えば営業所に設置されてい
る遠隔クライアントには、バックアップファイル又は統
計データベースをアクセスさせ、一方、情報センタ内の
クライアントには、元のデータベースをアクセスさせ
る。すなわち、従来では同一のデータベース２２に対し
て複数のクライアントからのアクセスが集中していた
が、本実施の形態ではデータベースアクセスを行うクラ
イアントによってアクセス先を振り分けることでアクセ
ス負荷の分散を図ることができる。

【００４１】実施の形態５．図１２は、本実施の形態に
おけるデータベース保守管理システムの機能ブロック構
成図である。図３と同様に本実施の形態の特徴的な統計
情報（インデックス）更新機能を説明するのに必要な構
成要素のみ図示した。本実施の形態における保守管理シ
ステムの全体構成及び情報センタ２０の構成は、実施の
形態１と同様である。図１２において、データベース監
視クライアント２４は、パラメータテーブル２９とイン
デックス更新部３６を有している。本実施の形態におけ
るパラメータテーブル２９には、統計データ更新開始時
刻が予め設定されている。インデックス更新部３６は、
所定の時間（リストア開始時刻）になった時点でデータ
ベースのインデックスを更新する。本実施の形態におけ
る統計情報（インデックス）更新機能は、次の目的のた
めに設けられている。

【００４２】すなわち、検索時間の短縮のためにデータ
ベースに登録される各データの格納先は、統計情報（イ
ンデックス）として実データとは別個に設定される。こ
の統計情報は、データベース構築時には一定の規則に従
い整然としているが、データの追加、削除が繰り返し行
われると、上記規則に従ったとしても統計情報自身がば
らついて格納されてきてしまう。このばらつきは、アク
セス時間の増大を招いてしまい、結果的に検索性能の劣
化を生じてくる。

【００４３】そこで、本実施の形態では、インデックス
更新部３６を設けることによって定期的すなわち毎日パ
ラメータテーブル２９に設定された時刻に統計情報の更
新を自動的にできるようにした。この機能は、例えば、
オラクル社のＳＱＬＢａｓｅ５．１．４Ｊの更新機能が
提供するコマンド（ＵＰＤＡＴＥ ＳＴＡＴＩＳＴＩＣ
Ｓ ・・）を実行することで実現できる。この更新機能
は、データベース毎に更新を実施する方法とテーブル毎
に行う方法とが提供されているが、本実施の形態では、
排他制御される単位をより小さくするためにテーブル単
位に更新を行うようにする。

【００４４】実施の形態６．図１３は、本実施の形態に
おけるデータベース保守管理システムの機能ブロック構
成図である。図３と同様に本実施の形態の特徴的なパー
ジ機能を説明するのに必要な構成要素のみ図示した。本
実施の形態における保守管理システムの全体構成及び情
報センタ２０の構成は、実施の形態１と同様である。図
１３において、データベース監視クライアント２４は、
パラメータテーブル２９とパージ処理部３７とを有して
いる。本実施の形態におけるパラメータテーブル２９に
は、予め設定されたパージ処理開始時刻が予め設定され
ている。すなわち、所定の時間（パージ開始時刻）にな
った時点でパージ処理部３７により所定のパージ処理が
自動実行される。本実施の形態におけるパージ機能は、
次の目的のために設けられている。

【００４５】すなわち、例えば米国ノベル社が提供する
Ｎｅｔｗａｒｅにより構築されたネットワーク上のファ
イルやディレクトリを削除した場合、そのファイルを例
えばオラクル社のＳＱＬＢａｓｅ ５．１．４ＪのＳＡ
ＬＶＡＧＥコマンドによって復旧させることができるよ
うに物理的には削除していない。ＳＱＬＢａｓｅの場
合、データベースにアクセスをした場合、そのアクセス
に伴いログファイルとテンポラリファイルを生成する。
これらのファイルは、一時的なものであり、不要となっ
た時点で削除される。このため、これらのファイルのた
めに使用された領域は、ボリューム上の空き領域として
カウントされるが、物理的には削除ファイルとして蓄積
されていくことになる。従って、このファイルを物理的
に削除しない限りは、そのファイルの格納領域を他のフ
ァイルによって使用させることができない。

【００４６】そこで、本実施の形態では、ファイルの物
理的な削除を行うパージ処理部３７を設けることによっ
て物理的な空き領域を確保できるようにした。この機能
は、ノベル社のＮｅｔＷａｒｅが提供するパージコマン
ド（ＰＵＲＧＥ）を実行することで実現できる。すなわ
ち、本実施の形態によれば、人手を介することなく毎日
パラメータテーブル２９に設定された時刻に定期的にパ
ージ処理を実行することができる。

【００４７】実施の形態７．上記各実施の形態において
は、本発明に係るデータベース保守管理システムが提供
する各機能をそれぞれ説明した。しかし、これらの各機
能は排他的に設ける必要がなく同じデータベース監視ク
ライアント２４に設け、同時に機能させることができ
る。図１４は、本実施の形態におけるデータベース保守
管理システムの機能ブロック構成図であるが、本実施の
形態では、上記各実施の形態において説明した各機能処
理を一定周期で実行させる機能実行制御部３８を設けた
ことを特徴としている。

【００４８】次に、本実施の形態における機能実行制御
部３８の処理について図１５に示したフローチャートを
用いて説明する。

【００４９】機能実行制御部３８は、最初にパラメータ
テーブル２９への設定内容を取得し（ステップ５０
１）、その内容から実行すべき機能処理を判定、認識す
る（ステップ５０２）。これ以降の処理は、一定の周期
（本実施の形態では１分間隔）で繰り返し行う（ステッ
プ５０３）。まず、マスタメンテナンス機能を実行する
場合は、更新用のマスタデータがファイル転送クライア
ント２３から所定のファイルに登録されているかを確認
する（ステップ５０４，５０５）。上記実施の形態１で
は、ファイル転送クライアント２３から更新用のマスタ
データを受信した時点で処理を開始するようにしたが、
本実施の形態のパラメータテーブル２９には、マスタメ
ンテナンス機能を実行の有無に関するフラグ情報が設定
されており、このフラグ情報によってマスタメンテナン
ス機能の実行制御を行うようにしている。ファイル転送
クライアント２３は、他のシステムから更新用のマスタ
データを受信したときにはデータベース監視クライアン
ト２４に設けてある所定のディレクトリに順次書き込
む。当該ディレクトリに書き込まれたデータは、キュー
管理されているので、機能実行制御部３８は、当該ディ
レクトリに更新用マスタデータが存在する場合は当該デ
ータのキュー情報に基づき順次マスタデータベースを更
新する（ステップ５０６）。

【００５０】一方、機能実行制御部３８は、マスタメン
テナンス機能を実行しないとき、パラメータテーブル２
９に設定された各機能の開始時刻とシステム時刻とを比
較し、処理開始時刻に達した機能が存在すれば、その機
能を実行する（ステップ５０７，５０８）。上記各実施
の形態では、各機能は自律的に実行するようにしたが、
本実施の形態では、機能実行制御部３８によって起動さ
れるように実行制御される。ここで、開始対象となる機
能は、履歴データの保存／削除機能、バックアップ機
能、リストア機能、統計情報更新機能及びパージ機能で
ある。

【００５１】実施の形態８．図１６は、実施の形態８に
おいて各情報センタに設置されるデータベース保守管理
システムの全体構成図である。本実施の形態は、設備の
保守管理を行うシステムにおいて特に音声データベース
の取扱いに関するものである。従って、上記各実施の形
態の代わりに音声再生クライアント３９が情報センタに
設けられている。この音声再生クライアント３９には、
パラメータテーブル４０、音声データベース管理部４１
及び音声データ保存部４２が設けられている。また、リ
ムーバブルなバックアップ用の外部記憶装置４３が外付
けされている。本実施の形態では、音声データベース４
４のバックアップ先を音声再生クライアント３９側の音
声データ保存部４２としている。更に、音声データ保存
部４２のバックアップをとるために外部記憶装置４３を
設けている。パラメータテーブル４０は、上記各実施の
形態と同様で各種パラメータ値が予め設定されている。
本実施の形態では、音声データベース４４のバックアッ
プを音声データ保存部４２へとるための処理の開始時
刻、音声データベース４４への音声データ保存期間、音
声データベース４４のための必要空き容量が設定されて
いる。更に、音声データ保存部４２のバックアップを外
部記憶装置４３へとるための処理の開始時刻、音声デー
タ保存部４２への音声データ保存期間、音声データ保存
部４２のための必要空き容量が設定されている。また、
指令台クライアント４５は、顧客との電話による会話を
するためのクライアントであり、１会話毎に１つの音声
データを生成する。

【００５２】次に、本実施の形態における処理について
説明する。本実施の形態における機能は、基本的には上
記実施の形態２において説明したディスク装置の空き容
量を常時監視して不定期にバックアップをとる履歴デー
タの保存／削除機能と上記実施の形態３において説明し
た定期的にバックアップをとるバックアップ機能との組
合せに基づく。

【００５３】まず、指令台クライアント４５において顧
客と会話された内容は、音声データとして所定のサーバ
２２の所定の音声データベース４４に蓄積される。この
音声データは、後で指令台クライアント４５において再
生することができ、会話の内容を確認したり、現地にお
いて設備のメンテナンス作業をしている技術者等に聞か
せることができる。

【００５４】音声データベース管理部４１は、常時所定
の時間間隔でシステム時刻とパラメータテーブル４０に
設定されているバックアップ開始時刻すなわち音声デー
タベース４４のバックアップを音声データ保存部４２へ
とるための処理の開始時刻及び音声データ保存部４２の
バックアップを外部記憶装置４３へとるための処理の開
始時刻とを比較する。ここで、システム時刻がいずれか
のバックアップ開始時刻に達したとき、音声データベー
ス４４／音声データ保存部４２に格納されている音声デ
ータを音声データ保存部４２／外部記憶装置４３にバッ
クアップをとる。この処理は、定期的な処理として日々
実行される。

【００５５】一方、音声データベース管理部４１は、音
声データベース４４／音声データ保存部４２の空き容量
を一定周期で常時監視する。なお、音声データベース４
４を音声データ保存部４２にバックアップをとる処理と
音声データ保存部４２を外部記憶装置４３にバックアッ
プをとる処理は、ほぼ同じなので、音声データベース４
４を音声データ保存部４２にバックアップをとる場合で
説明する。音声データベース管理部４１は、音声データ
ベース４４の空き容量がパラメータテーブル４０に設定
されている必要空き容量以下になったことを検出する
と、その時点で音声データベース４４に蓄積されている
音声データを音声データ保存部４２にコピーするととも
に当該データを音声データベース４４から削除する。こ
のようにして、空き容量の少なくなった音声データベー
ス４４のために空き領域を自動的に確保することができ
る。前述したように、音声データ保存部４２を外部記憶
装置４３にバックアップをとる場合も同様であり、空き
容量の少なくなった音声データ保存部４２に空き領域を
自動的に確保することができる。なお、外部記憶装置４
３の記憶媒体自身は、交換可能であるため適宜交換すれ
ばよい。

【００５６】本実施の形態によれば、指定した時刻（バ
ックアップ開始時刻）になった時点で設備の保守管理シ
ステムを停止することなく音声データベース４４及び音
声データ保存部４２のバックアップを自動的にとること
ができるとともに音声データベース４４及び音声データ
保存部４２に空き領域を自動的に確保することができ
る。

【００５７】本実施の形態において説明した音声データ
を扱う構成要素は、上記各実施の形態１〜７で説明した
構成要素と同一システム上に形成できることはいうまで
もなく、データベース監視クライアント２４と音声再生
クライアント３９とを同一クライアントとすることもで
きる。

【００５８】なお、上記各実施の形態において、各サー
バ２２は、１乃至複数のディスク装置を具備しており、
各ディスク装置に１乃至複数のデータベースを格納する
ようにした。このサーバ２２に保有される各データベー
スのバックアップファイルは、安全性や保守性、負荷分
散等を考慮して元のデータベースと同一サーバ上の異な
るディスク装置あるいは異なるサーバ２２のいずれかの
ディスク装置に保有することが望ましいが、どのサーバ
２２上に保有するかは、サーバの台数、各サーバが具備
するディスク装置の台数等により決定するシステムの設
計事項である。

【００５９】また、上記各実施の形態においてパラメー
タテーブルに設定されるバックアップ開始時刻等は、具
体的な例を示さなかったが、各パラメータ値は、システ
ムの規模や運用等を考慮した値に設定することが望まし
い。

【００６０】また、上記各実施の形態では、本発明に係
るデータベース保守管理システムをビル設備等を監視す
るシステムに適応した場合を例にして説明したが、デー
タベースを使用した通常業務処理を２４時間連続して行
う他のシステムにおいても適用することができ、上記と
同等の効果を奏することができる。

【００６１】

【発明の効果】本発明によれば、更新用マスタデータの
内容を人手を介することなくマスタデータベースに自動
的に反映することができる。

【００６２】また、履歴データベースの空き容量が必要
空き容量以下になった時点で条件に合致した履歴データ
を履歴データ保存手段に移動するようにしたので、履歴
データベースのために空き領域を自動的に確保すること
ができる。このため、データベースのオーバーフローに
よる障害発生を未然に防止することができる。

【００６３】また、バックアップ開始時刻になった時点
で設備の保守管理システムを停止することなくデータベ
ースのバックアップを自動的にとることができる。

【００６４】また、二次的データベースを自動生成でき
るようにし、また、これを設けることによってアクセス
負荷の分散を図ることができる。

【００６５】また、データベースのインデックスを自動
更新できるようにしたので、人手を介することなくデー
タベースの検索性能の劣化を防止することができる。

【００６６】また、データベース上に残った削除ファイ
ルを人手を介することなく自動的に削除することができ
る。

【図面の簡単な説明】

【図１】 本発明に係るデータベース保守管理システム
の実施の形態１を適用した設備の保守管理を行うシステ
ムの全体構成図である。

【図２】 実施の形態１において各情報センタに設置さ
れるデータベース保守管理システムの全体構成図であ
る。

【図３】 実施の形態１におけるデータベース保守管理
システムの機能ブロック構成図である。

【図４】 実施の形態１におけるマスタメンテナンス機
能処理を示したフローチャートである。

【図５】 実施の形態２におけるデータベース保守管理
システムの機能ブロック構成図である。

【図６】 実施の形態２における履歴データ保存／削除
機能処理を示したフローチャートである。

【図７】 実施の形態３におけるデータベース保守管理
システムの機能ブロック構成図である。

【図８】 実施の形態３におけるパラメータテーブルへ
の設定例を示した図である。

【図９】 実施の形態３におけるバックアップ機能処理
を示したフローチャートである。

【図１０】 実施の形態４におけるデータベース保守管
理システムの機能ブロック構成図である。

【図１１】 実施の形態４におけるリストア機能処理を
示したフローチャートである。

【図１２】 実施の形態５におけるデータベース保守管
理システムの機能ブロック構成図である。

【図１３】 実施の形態６におけるデータベース保守管
理システムの機能ブロック構成図である。

【図１４】 実施の形態７におけるデータベース保守管
理システムの機能ブロック構成図である。

【図１５】 実施の形態７における機能実行制御処理を
示したフローチャートである。

【図１６】 実施の形態８において各情報センタに設置
されるデータベース保守管理システムの全体構成図であ
る。

【図１７】 従来のデータベース保守管理システムを適
用した設備の保守管理を行うシステムの全体構成図であ
る。

【符号の説明】

１ 顧客、４ ネットワーク、５ 営業所、６ ホスト
コンピュータ、２０情報センタ、２１ ルータ、２２
サーバ、２３ ファイル転送クライアント、２４ デー
タベース監視クライアント、２５ ＬＡＮ、２６ マス
タデータ受信部、２７ マスタデータベース、２８ マ
スタ管理部、２９，４０ パラメータテーブル、３０
履歴データベース管理部、３１ 履歴データベース（Ｄ
Ｂ）、３２ 保存用履歴データベース（ＤＢ）、３３
バックアップ処理部、３４ リストア処理部、３５ ア
クセス制御部、３６ インデックス更新部、３７ パー
ジ処理部、３８ 機能実行制御部、３９ 音声再生クラ
イアント、４１ 音声データベース管理部、４２ 音声
データベース保存部、４３ 外部記憶装置、４４音声デ
ータベース、４５ 指令台クライアント。

───────────────────────────────────────────────────── フロントページの続き (56)参考文献 特開 平５−334161（ＪＰ，Ａ) 特開 平３−78042（ＪＰ，Ａ) 特開 平７−325739（ＪＰ，Ａ) 特開 平９−50394（ＪＰ，Ａ) 特開 平６−332760（ＪＰ，Ａ) 特開 平３−78042（ＪＰ，Ａ) 特開 平６−52119（ＪＰ，Ａ) 特開 平７−6070（ＪＰ，Ａ) 特開 平７−146849（ＪＰ，Ａ) 特開 平７−225709（ＪＰ，Ａ) 特開 平９−128276（ＪＰ，Ａ) 実開 平３−124244（ＪＰ，Ｕ) (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 12/00 G06F 17/30

Claims (2)

(57)【特許請求の範囲】
1. 【請求項１】 データベースを使用した通常業務処理が
   ２４時間連続して行われるシステムに搭載されその通常
   業務処理を停止することなく前記データベースの保守管
   理を行うデータベース保守管理システムにおいて、予め設定されたバックアップ対象となるデータベース、
   当該各データベースのバックアップ開始時刻、バックア
   ップされたデータベースに基づき生成する二次的データ
   ベース及び当該各二次的データベースの生成処理開始時
   刻を保持するデータベース管理パラメータ記憶手段と、 前記バックアップ開始時刻になった時点で対応する前記
   データベースのバックアップを行うバックアップ処理手
   段と、 前記生成処理開始時刻になった時点で対応する前記二次
   的データベースの生成処理を自動的に行うデータベース
   生成処理手段と、 データベースへのアクセス先を前記データベース又は前
   記二次的データベースに振り分けるアクセス制御手段
   と、 を有する ことを特徴とするデータベース保守管理システ
   ム。
2. 【請求項２】 前記機能処理を一定周期で実行させる機
   能実行制御手段を有することを特徴とする請求項１に記
   載のデータベース保守管理システム。