JP2004038516A - 業務処理システム、運用管理方法及び運用管理を行うためのプログラム - Google Patents
業務処理システム、運用管理方法及び運用管理を行うためのプログラム Download PDFInfo
- Publication number
- JP2004038516A JP2004038516A JP2002194083A JP2002194083A JP2004038516A JP 2004038516 A JP2004038516 A JP 2004038516A JP 2002194083 A JP2002194083 A JP 2002194083A JP 2002194083 A JP2002194083 A JP 2002194083A JP 2004038516 A JP2004038516 A JP 2004038516A
- Authority
- JP
- Japan
- Prior art keywords
- task
- business
- schedule
- storage device
- data
- 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
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1458—Management of the backup or restore process
- G06F11/1469—Backup restoration techniques
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
- Y10S707/99953—Recoverability
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Quality & Reliability (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Multi Processors (AREA)
Abstract
【課題】記憶装置に障害が発生した場合に業務の実行スケジュールを再構成するシステム、方法を提供することを目的とする。
【解決手段】障害が発生した記憶装置の回復時間を求め、この回復時間に基づいて障害が発生した記憶装置を利用する業務、利用しない業務のスケジュールを生成する。
【選択図】 図１
【解決手段】障害が発生した記憶装置の回復時間を求め、この回復時間に基づいて障害が発生した記憶装置を利用する業務、利用しない業務のスケジュールを生成する。
【選択図】 図１
Description
【０００１】
【発明の属する技術分野】
本発明は，業務の運用管理を行うための業務運用管理システムに関するものである。
【０００２】
【従来の技術】
コンピュータが処理を行う複数のジョブを１つの業務とし、更に複数の業務をスケジュールに従って実行する技術がある。またこれらの業務を実行するためにコンピュータは、データを記憶する記憶装置と接続されたシステムとなっている。このような技術において障害は発生した場合、できるだけ早急に業務を復帰させる必要がある。
【０００３】
例えば、特開平７−５６７９３号公報には、ファイル障害が発生した際に、オペレータの介在無しに障害復旧を行うために、障害ファイル名、障害装置名に基づいて障害復旧手順及び障害復旧用ジョブ制御分を組み立てることが記載されている。また、特開２０００−７６１１０号広報には、障害を受けた分散ファイルシステムにおいて、障害を受けたファイルだけを検出し、そのファイルだけをバックアップ情報から回復し、短時間でシステムを自動回復する技術が記載されている。また、特開２００１−３５０６７３号公報には、実行済みでないジョブの処理終了予定時刻を算出し、この時刻が各ジョブの終了すべき時刻より前であればスケジュールに組み込み、優先度に従って抽出された順に実行順序を付与してスケジュールを再構成し、再構成されたスケジュールによりジョブを実行することが開示されている。
【０００４】
【発明が解決しようとする課題】
特開平７−５６７９３号公報及び特開２０００−７６１１０号に記載された技術では、業務のスケジュールを再構成することについては開示されていない。また、特開２００１−３５０６７３号は復電時に、復電時刻に応じたジョブスケジュールを再構成するものであり、ファイルの障害については開示されていない。
【０００５】
本発明は、記憶装置に障害が発生した場合に業務の実行スケジュールを再構成するシステム、方法を提供することを目的とする。
【０００６】
【課題を解決するための手段】
業務に使われているファイルと業務の最終完了時間、その業務の重要度を業務運用管理のスケジュールデータの中に組み込んでおき、障害が起こった時にスケジュールデータを参照することにより問題となる業務を把握し、さらにディスク回復時間の条件から、それぞれにおける業務の緊急度を割り出しスケジュールの再構築を自動で行う。
【０００７】
【発明の実施の形態】
以下、図面を用いて説明する。
【０００８】
図１は業務を実行するシステム構成を示したものである。本システムは、業務の運用管理と業務の実行を行う複数の業務管理サーバ１００、業務の実行により生成されたデータ又は業務の実行に必要なデータを記憶する複数のディスク装置１２５、１２６、ディスク装置１２５、１２６へのデータの書き込み及び読み出しを制御するディスク管理サーバ１２０、ディスク装置１２５、１２６に記憶されたデータが記憶されている記憶装置１３５、記憶装置１３５へのデータの書き込み及び読み出しを制御するバックアップサーバ１３０とを有している。
ここで、記憶装置１３５は、ディスク装置１２５、１２６のデータのバックアップに利用されるものであり、ディスクにより構成されたものであっても、テープで構成されたものであってもよい。図１に示された業務管理サーバ１００、ディスク管理サーバ１２０、バックアップサーバ１３０は、プログラムやデータを記憶する記憶部１０１、１２１、１３１と、プログラムの実行を行うＣＰＵなどの処理部１０２、１２２、１３２とを有している。従って、各サーバは汎用のコンピュータであっても、また専用のハードウェアにより構成されているものでもよい。以下、各サーバについて具体的に説明する。
【０００９】
ここで、業務管理サーバ１００は同じ機能を実現するものであり、構成も同じものである。但し、各業務管理サーバで実行される業務又はジョブは異なる場合がある。
【００１０】
業務管理サーバ１００は、ジョブを実行するジョブ実行制御モジュール１０３、障害ディスクの回復にどれほどの時間が掛かるかを算出し、障害に影響のない業務をどのように処理するかを決めるスケジュール前処理モジュール１０４と、業務のスケジュールの再構築を行う優勢順位判別モジュール１０５と、障害が起こったとき業務に対して処理の緊急度を画面に表示し、それぞれの業務の担当者に障害の通知をする表示・通知モジュール１０６、データのバックアップやリストアを行うためにデータ転送モジュール１０７と、実行される複数のジョブ１０８とを有している。これらのモジュール及びジョブはソフトウェアプログラムであり、記憶部１０１に格納されている。尚、業務とは１つのジョブ１０８或いは複数のジョブ１０８の塊を意味する。また、記憶部１０１には、業務が実行されるスケジュールを定義したスケジュールデータ１０９、障害が発生したときにスケジュールを変更する業務の情報が登録された再スケジュールデータ１１０が記憶されるようになっている。
【００１１】
ディスク管理サーバ１２０は、ディスク管理モジュール１２３、どのディスク装置にどのファイルが記憶されているかを記したディスク・ファイル対応データ１２４とを有している。ディスク管理モジュール１２３はいくつかの機能を有しており、各機能について説明する。まず第１に、ディスク装置１２５、１２６へのデータの書き込みやデータの読み出しを行うアクセス制御機能である。次に、ディスク装置１２５、１２６へのデータの書き込み、読み出しを監視し、書き込み又は読み出しができない場合に、ディスク装置の障害であると判断し、障害が発生したディスク装置を特定する識別子を業務管理サーバ１００へ報告する機能である。この場合、業務管理サーバ１００からのアクセス要求によりディスク装置へアクセスした際に、読み出し又は書き込みができずディスク装置に障害が発生したことを検出する。従って、障害が発生した場合にはアクセス要求を受けた業務管理サーバ１００へ報告を行う。また、管理サーバ１００からのアクセス要求に基づいてディスク装置に格納されるデータのファイル名をファイル・ディスク対応データ１２４として格納する機能である。また、管理サーバ１００からの要求に応じてファイル・ディスク対応データ１２４を管理サーバ１００へ送る機能である。尚、ディスク管理モジュール１２３は、ソフトウェアプログラムであり記憶部１２１に記憶されている。
【００１２】
ディスク管理サーバ１２０に接続されたディスク装置１２５、１２６は、管理サーバ１００で実行されたジョブの結果や、ジョブに利用されるデータが格納されている。
【００１３】
バックアップサーバ１３０は、記憶装置１３５へのアクセスを管理するアクセス管理モジュール１３３を有している。尚、このモジュールもソフトウェアプログラムであり、バックアップサーバ１３０の記憶部１３１に記憶されている。記憶装置１３５は、バックアップのための記憶装置であり、業務管理サーバ１００、１１０によりディスク装置１２５、１２６のバックアップの対象となったデータが記憶されている。
【００１４】
図２にスケジュールデータ１０９の一例を示す。このスケジュールデータは、管理者によって設定され、ジョブ実行制御モジュール１０３は、このスケジュールデータを監視し、このスケジュールデータに従ってジョブを実行する。スケジュールデータ１０９は、業務の運用を管理するための情報であって、業務をどのように行っていくのかといった情報と、障害時における業務の優先度が含まれている。具体的には、開始時間２０２、実行時間２０３、スキップ設定２０４、リミッタ設定２０５、使用ファイル２０６、状態２０７が登録されている。開始時間２０２とは業務の開始時刻を示すものであり、実行時間２０３とは業務が終了するまでかかる時間である。スキップ設定２０４とは、これが「あり」と設定されると、この業務は実行しなくても良いことを示す。例えば、次の日に行ってもそれほど問題とならないような業務に対して設定される。リミッタ設定２０５とは、必ず終了しなければならない時刻である。使用ファイル２０６とは、当該業務を行う上で必要となるファイルである。状態２０７とは、業務の状態が登録されるもので、業務が終了した場合には「終了」、業務を実行中の場合は「実行中」が登録される。何も登録されていない場合は、まだ実行されていない状態を意味する。この実行状態２０７は、ジョブ実行制御モジュール１０３により登録される。尚、各々の業務は既に説明したように１つ又は複数のジョブによって構成されており、それぞれのジョブは業務と対応付けられており、業務が特定されるとジョブが特定できるようになっている。ジョブ実行制御モジュール１０３は、スケジュールデータ１０９を監視し、業務の実行時刻になったら、当該業務により特定されるジョブ１０８を実行する。
【００１５】
業務管理サーバ１００内の再スケジュールデータ１１０も図２に示したのとほぼ同じ情報を有している。つまり、業務名、開始時間、実行時間、スキップ設定、リミッタ設定、使用ファイルが登録される。但し、状態は登録されていない。
【００１６】
図３にファイル・ディスク対応データ１２４の一例を示す。ファイル・ディスク対応データ１２４は、それぞれのディスク装置１２５、１２６に記憶されているファイル情報３０２、３０３を示すものである。ディスク装置１２５、１２６はデータの塊としてファイル単位で記憶されており、ファイル情報３０２、３０３は、そのファイル名を意味する。
【００１７】
図１に示した業務管理サーバ１００は、ディスク装置の障害がディスク管理サーバ１２０から報告されると、スケジュール通りに業務が実行できるかを判断し、スケジュール通りに業務が実行できない場合には、スケジュールデータを変更する。以下、障害の報告を受けた業務管理サーバ１００の処理について説明する。
【００１８】
図４は、スケジューリングの再構築の処理全体を示したものである。ディスク装置の障害の報告を受けた業務管理サーバは、優先順位判別モジュール１０５を実行する。優先順位判別モジュール１０５により、スケジュールデータ１０９に登録されている業務で、まだ実行されていない業務の情報（業務名、開始時間、実行時間、スキップ設定、リミッタ設定、使用ファイル）をスケジュールデータ１０９から削除し、再スケジュールデータ１１０へ登録する（４０１）。次に、ファイル・ディスク対応データ１２４を送るようにディスク管理サーバ１２０へ要求する（４０２）。ディスク管理サーバ１２０のディスク管理モジュール１２３は、障害が発生したディスク装置のファイル・ディスク対応データ１２４を業務管理サーバへ送る。ファイル・ディスク対応データ１２４を受取った業務管理サーバは、優先順位判別モジュール１０５により障害が発生したディスク装置に記憶されたファイルを利用する業務を特定する（４０３）。例えば、ディスク装置１２５に障害が発生した場合、図２と図３よりディスク装置１２５に入っていたａ，ｂ，ｃというファイルを使用する業務Ａ、業務Ｂ、業務Ｃが特定される。
【００１９】
次に、スケジュール前処理モジュール１０４により、障害が発生したディスク装置の回復時間を求めると共に、再スケジュールデータ１１０に登録されている業務で障害が発生したディスクを利用しない業務についてのスケジュールの調整を行う（４０４）。
【００２０】
図５は、スケジュール前処理モジュール１０４の処理を示したものである。まず、障害が発生したディスク装置に格納されたファイル情報をバックアップサーバ１３０に送る。バックアップサーバ１３０のアクセス管理モジュール１３３は、送られてきたファイル情報から、それぞれのファイルの容量を求め、業務管理サーバへ送る。スケジュール前処理モジュール１０４は、送られてきたファイルの容量から、障害が発生したディスク装置が回復するまでにかかる時間を次式により求める（５０１）。
〔回復時間〕＝〔ボリューム交換時間〕＋〔容量〕／〔転送速度〕
ここで、ボリューム交換時間、転送速度は予め定数として与えておく。尚、ここでは、ファイル情報に基づいてアクセス管理モジュール１３３が容量を求める構成としているが、バックアップサーバ１３０でディスク装置ごとにファイルを管理している場合には、業務管理サーバから障害が発生したディスク装置を特定する識別子を送ることでディスク装置に記憶されたファイルの容量を求めることができる。
【００２１】
次に、再スケジュールデータ１１０に登録されている業務の中で、障害が発生したディスク装置を利用しない業務を特定し、この特定された業務の中から処理５０１で求めた回復時間内に実行される業務を求める（５０２）。回復時間内で実行される業務がある場合（処理５０２で「Ｙｅｓ」）、その業務がディスク回復時間（上記の式で求めた回復時間。）内に終了できる業務かどうかを判別する（５０３）。回復時間の間に終了できる業務（処理５０３で「Ｙｅｓ」）ならば当該業務をスケジュールデータ１０９に登録し、この業務を再スケジュールデータ１１０から削除し（５１０）、処理を終了する。回復時間の間に終了できない業務である場合（処理５０３で「Ｎｏ」）、業務の開始時間を早める（５０４）。
【００２２】
その業務開始時間を早めることによって、回復時間内に終了するか判別する（５０５）。回復時間内に業務が終了する場合（処理５０５で「Ｙｅｓ」）、開始時間を変更した業務の情報をスケジュールデータ１０９に登録し、再スケジュールデータ１１０から削除し（５１０）、処理を終了する。尚、処理５０３で「Ｎｏ」となり、スケジュールデータ１０９に登録されている業務のスケジュールが密なため、開始時間を早めることができない業務も、処理５０５の判断を行い処理が行われる。
【００２３】
回復時間内に業務が終了しない場合（処理５０５で「Ｎｏ」）、回復時間の終了時点で、その業務が所定のしきい値以上で終らせることができるかどうかを判別する（５０６）。しきい値は予め設定され、ここでは８０％として説明する。再スケジュールデータ１１０の実行時間より業務の実行にかかる時間が分かるので、業務の開始時間が決まれば、回復時間終了時点で、どの程度業務が行われたかがわかる。処理５０６では、回復時間の終了時点で業務の８０％が終了しているかを判断する。しきい値以上の業務が終了しない場合（処理５０６で「Ｎｏ」）、他の業務管理サーバで実行可能か判断する（５０７）。具体的には、業務名、業務の開始時間、実行時間、リミッタ設定値とを他の業務管理サーバへ送り、他の業務管理サーバから業務実行の可否の報告を受ける。他の業務管理サーバから実行が可能であるとの報告を受けると（処理５０７で「Ｙｅｓ」）、報告を受けた業務管理サーバに業務実行の依頼を通知する。この時に、再スケジュールデータ１１０に登録されている当該業務を削除する。尚、他の業務管理サーバで当該業務を実行するためには、他の業務管理サーバで当該業務を実行するためのジョブが予め登録されている必要があるが、当該ジョブを有していない場合、業務を依頼する業務サーバへ業務の実行を依頼する際に、業務の実行に必要なジョブを転送する。他の業務管理サーバで業務を実行できない場合（処理５０７で「Ｎｏ」）、処理を終了する。
【００２４】
しきい値以上の処理が終了できる場合（処理５０６で「Ｙｅｓ」）、当該業務の終了時間を新たな回復時間として（５０９）、スケジュールデータ１０９へ当該業務の情報を登録し、再スケジュールデータ１１０から当該業務の情報を削除する。尚、このとき開始時間が変更されていれば、変更された開始時間がスケジュールデータ１０９に登録される。再スケジュールデータ１１０に他の登録されている業務があれば（処理５１１で「Ｙｅｓ」）、再び処理５０２から処理を実行する。ジョブ実行制御モジュール１０３は、スケジュールデータ１０９によりジョブを実行しており、図５の処理５１０でスケジュールデータ１０９に登録された業務を実行する。
【００２５】
スケジュール前処理モジュール１０４でスケジュールの調整が終了すると、再び優先順位判別モジュール１０５により、図４の処理が行われる。
【００２６】
優先順位判別モジュール１０５は、再スケジュールデータ１１０に登録されている業務についてのスケジュールを決定する（４０５）。ここで、再スケジュールデータ１１０に登録されている業務は、障害が発生した以降に実行される業務から、回復時間内に終了する業務を除いたものとなっている。
【００２７】
図６、７は、処理４０５のスケジュール決定の処理を示したものである。
【００２８】
まずディスク装置の回復を行った後に業務を実行するため、それぞれの業務のリミッタ時刻から回復時間を差し引く（６０１）。次に、再スケジュールデータ１１０に登録された業務を、開始時間が早い順に整理し直し、全ての業務が問題なく行えるかどうかを判定する（６０２）。すべての業務が問題なく行えるとは、各業務についてリミッタ設定値を超えることなく業務が終了される場合をいう。全ての業務が問題なく行える場合（処理６０２で「Ｙｅｓ」）、この順番でスケジュールデータ１０９へ業務の情報を登録し、再スケジュールデータから当該業務の情報を削除し（６０７）、処理を終了する。
【００２９】
このままの順番ではリミッタ設定値を超える業務がある場合（処理６０２で「Ｎｏ」）、業務終了時刻がリミッタ設定に最も近い業務を１番目の業務になるように業務の順番を入れ替える（６０３）。
【００３０】
並び替えた業務の順番で全ての業務がリミッタ設定値を超えることなく行えるかどうかを判定する（６０４）。全ての業務がリミッタ設定値を超えない場合（処理６０４で「Ｙｅｓ」）、並び替えた順番で各業務の開始時刻を設定し、スケジュールデータ１０９に業務の情報を登録し、再スケジュールデータ１１０から当該業務の情報を削除し（６０７）、処理を終了する。
【００３１】
並び替えてもリミッタ設定値を超える業務がある場合（処理６０４で「Ｎｏ」）、業務の合計とリミッタにより処理した数を比較する（６０５）。まだ動かしていない業務がある場合（処理６０５で「Ｙｅｓ」）、次にリミッタが近い業務にたいして同様の処理を行う。
【００３２】
動かせる業務がなくなった場合（処理６０５で「Ｎｏ」）、業務の中でスキップするものがあるかどうかの判定を行う（６０８）。
【００３３】
スキップ可能な業務がある場合（処理６０８で「Ｙｅｓ」）、先頭にあるスキップ可能な業務を再スケジュールデータ１１０から削除する（６０８）。尚、このときの再スケジュールデータ１１０は、図６により決定された順番で処理されるよう、開始時間が設定されている。また、先頭にあるスキップ可能な業務とは、設定された開始時間が早いものを意味する。スキップ（削除）した結果、再スケジュールデータ１１０に登録されている業務がリミッタ設定値を超えないかどうかの判別を行う（６１０）。全ての業務がリミッタ設定値を超えない場合（処理６１０で「Ｙｅｓ」）、再スケジュールデータ１１０に登録された業務の情報をスケジュールデータ１１０に登録し、再スケジュールデータから業務の情報を削除する（６１１）。次に、スキップした業務を、通知・表示部に通知する（６１２）。リミッタ設定値を超える業務がある場合（処理６１０で「Ｎｏ」）、処理６０８に戻り次にスキップできる業務を求める。スキップするものがない場合は、現在再スケジュールデータ１１０に登録されている業務の情報をスケジュールデータ１０９へ登録し、再スケジュールデータ１１０から業務の情報を削除する（６１３）。また、リミッタ設定値内に終了しない業務を、通知・表示部に通知する（６１４）。図７の処理が終了すると再スケジュールデータ１１０に登録された業務の情報は、スケジュールデータ１０９に全て登録され、再スケジュールデータ１１０の業務の情報は全て削除されている。
【００３４】
再び、図４の処理に戻り、スケジュールが決まったら、業務ビューアに変更後の業務スケジュールを表示し、管理者へ通知する（４０６）。このとき、リミッタ設定値を超える業務が管理者に分かるように例えば赤色で表示したり、リミッタ設定値を超える業務だけを他の業務と分けて表示する。
【００３５】
図８は、表示・通知モジュール１０６の処理を示したものである。まず通知された業務が、スキップされた業務なのか、リミッタの制限内に終了しなかった業務なのかを判定する（７０１）。スキップされた業務ならば、スキップした業務に対して、業務担当者にメールで通知する（７０２）。業務ビューアにスキップした業務を青色で表示する（７０３）。リミッタ設定値以内で終了しない業務に対しては、業務がリミッタからどれだけ遅れてることになるのかを計算する（７０４）。これは、スケジュールデータ１０９のリミッタ設定値、開始時刻、実行時間から求めることができる。業務の遅れが緊急連絡時間を越えるかどうかの判定を行う（７０５）。緊急連絡時間とは、管理者によって予め決められた値である。業務の遅れが緊急連絡時間を超える場合は，その業務の担当者に電話で緊急の連絡を行う（７０６）。業務ビューアにリミッタ設定値を超えてしまう業務に対して赤色で表示する（７０７）。業務の遅れが緊急連絡時間以内である場合は、その業務の担当者にメールで通知を行う（７０８）。業務ビューアにリミッタ設定以内に終了しない業務に対して黄色で表示する（７０９）。
【００３６】
図９は、業務ビューア表示例を示したものである。
【００３７】
業務ビューア８０１には管理している業務示す業務名８０２とジョブ実行スケジュール８０３が表示される。ジョブ実行スケジュールのノード８１１〜８１４を緊急度によって色で分別する。デフォルトは緑色、緊急度が高いものを赤色、緊急度が低いものを黄色、業務をスキップしたものを青色で表示する。
【００３８】
再び図４の処理に戻り、障害が起こったディスク装置のディスク回復を行うためデータ転送モジュール１０７を実行する（４０７）。データ転送モジュール１０７は、バックアップサーバ１３０から障害の発生したディスク装置へデータのリストアを実行する。
【００３９】
図１０は障害の発生によるスケジュールの変更と管理者への通知を具体的に示したものである。９０１は実行される予定の業務であり、９１１〜９１４はそれぞれの業務のノードであり、９２１〜９２４はそれぞれの業務のリミッタ設定値である。障害が発生しない場合は、ノード９１１〜９１４で示したように業務が実行される。９３１のｄｏｗＮｏは、ディスクに障害が発生した時点を示したものである。尚、この時のスケジュールデータ１０９を図１２（ａ）に示す。
【００４０】
ディスク装置１２５で障害が発生した場合、ディスク装置１２５を利用している業務はファイル・ディスク対応データ１２４より業務Ａ，業務Ｂ，業務Ｃとなる。９４１はディスク装置１２５に格納されるデータの容量から求めた回復時間である。ケース０は、業務の開始時間に基づいて並べかえた業務のスケジュールである。
ケース１は、図６に示した処理６０３〜６０６により業務が並替えられたスケジュールである。具体的には、ケース０のスケジュールに対して、終了時刻がリミッタ設定値を超える業務（ここでは、業務Ａと業務Ｃである。）のうち、終了時刻がリミッタ設定値から最も離れている業務（ここでは、業務Ｃ）を、最初に実行する業務とする。ここでは、業務Ｃ、業務Ａ、業務Ｂ、業務Ｄとなる。並替えたスケジュールに基づいて、再び終了時刻がリミッタ設定値を超える業務のうち、終了時刻がリミッタ設定値から最も離れている業務を、最初に実行する業務とする。これにより、ケース１に示すように業務Ａ、業務Ｃ、業務Ｂ、業務Ｄの順に並替えられる。
【００４１】
順序を変更しても，リミッタ設定を超える業務があるので，次に図７の処理を行う。しかしながら、図１２（ａ）に示すように、スキップ設定に「あり」と示された業務がないので、そのまま処理を終了する。これにより表示・通知モジュール１０６は、リミッタ設定値を超える業務について次のように処理が行われる。
【００４２】
業務Ａと業務Ｃの担当者に連絡を送る。連絡の選択の方法は，リミッタ設定値から終了時刻がどれだけ離れているかによって決まる。リミッタ設定値から離れている時間が、緊急連絡時間以内である業務Ａに対しては、業務Ａの担当者にメールで連絡を送ると共に、業務ビューアに業務Ａを黄色で表示する。リミッタ設定値から離れている時間が緊急連絡時間を超える業務Ｃに対しては、業務Ｃの担当者に電話で連絡すると共に、業務ビューアに業務Ｃを赤色で表示する。ディスク回復後に、スケジュールデータ１０９に登録された通りにジョブの実行を行い、担当者は必要があればスケジュールデータ１０９を変更する。
【００４３】
ケース２は、図１２（ｂ）に示すように、スキップする業務があった場合に設定されたスケジュールを示したものである。ここでは、図１２（ｂ）より業務Ａがスキップ設定「あり」となっているので、業務Ａがスケジュールから削除されている。この場合、表示・通知モジュール１０６により、業務ビューアに再スケジュールした業務スケジュールを表示する。また、業務Ａがスキップしたことを担当者にメールで連絡し、業務ビューアには業務Ａを青色で表示する。
【００４４】
図１１は、図１２（ｃ）のるように障害発生前に業務Ａ、業務Ｄ、業務Ｂ、業務Ｃとスケジュールデータ１０９が設定されている場合のスケジュールの変更の例を示したものである。図１０と同じ符号のものは、図１０と同じ意味を示すものである。ディスク装置１２５で障害が発生した場合、図１０で説明したのと同様に業務Ａ、業務Ｂ、業務Ｃがディスク装置１２５を利用する業務であると特定される。
【００４５】
次に、図５に示した処理により、障害が発生したディスク障害１２５を利用しない業務で、回復時間内に実行予定の業務があるかを判別する。ここで、業務Ｄは障害の発生したディスク装置１２５を利用しない業務であり、回復時間内に実行が予定されている業務である。
【００４６】
業務Ｄは、ディスク回復時間内で終了しないので（１）、業務Ｄの開始時間を早める（２）。開始時間を早めても業務Ｄの終了時刻は、回復時間を超えてしまうので、回復時間の終了時点でどの程度業務が終了しているかを求める。業務が終了した程度が、予めさだめたしきい値（例えば、８０％。）以上終了している場合には、業務Ｄを実行させ、業務Ｄの終了時刻を回復時間の終了時点として、障害が発生したディスク装置１２４を利用する業務（ここでは、業務Ａ、業務Ｂ、業務Ｃ）について図６、図７に示した処理を行う。これにより、業務Ｄ、業務Ｂ、業務Ｃの順でスケジュールが設定される（３）。尚、業務Ａについてはスキップの設定がありスケジュールから削除している。
【００４７】
最後に表示・通知モジュール１０６により、業務Ａがスキップしたことを担当者にメールで連絡し、業務ビューアには業務Ａを青色で表示する。
【００４８】
尚、スケジュールデータ１０９に登録されたデータは、障害の発生により変更されるが、例えばスケジュールデータが１日単位で決まっている場合、次の日になれば変更前のスケジュールデータ１０９に設定されるようになっている。
【００４９】
また、障害が発生すると障害が発生した後に実行されるすべての業務を対象に図４〜８の処理を行ったが、業務の終了時刻と業務の開始時刻との間が回復時間よりも大きければ、その後の業務については図４〜８の処理を行う必要がない。例えば、業務Ａ、業務Ｂ、業務Ｃ、業務Ｄ、業務Ｅとあり、業務Ｃの終了時刻から業務Ｄの開始時刻までの時間が、回復時間よりも大きければ、業務Ｄ、業務Ｅについては、図４〜８の対象外としてもよい。これを実現するためには、例えば図５の処理５０１で回復時間が求められた後に、業務の終了時刻から次の業務の開始時刻までの時間を求め、この時間が回復時間より大きければ、それ以降の業務の情報をスケジュールデータ１０９に登録し、再スケジュールデータから削除する処理を行えばよい。
【００５０】
このように、障害によってどの業務に問題があるのかを管理者が探す必要がなくなる。また業務のスケジューリングを自動的に組みなおすことができる。スケジューリングできない場合でも、画面に問題となる業務とその緊急度を表示するので、管理者は問題となる業務の早期発見と修正を行うことができる。
【００５１】
【発明の効果】
以上説明したように、ディスクの障害に対した業務のスケジュールを設定することができる。
【図面の簡単な説明】
【図１】システムの構成を示した図である。
【図２】スケジュールデータの一例を示した図である。
【図３】ディスク・ファイル対応データの一例を示した図である。
【図４】スケジュール設定の処理を示した図である。
【図５】スケジュール設定の処理を示した図である。
【図６】スケジュール設定の処理を示した図である。
【図７】スケジュール設定の処理を示した図である。
【図８】表示及び通知の処理を示した図である。
【図９】設定されたスケジュールの表示例を示した図である。
【図１０】処理の具体例を示した図である。
【図１１】処理の具体例を示した図である。
【図１２】スケジュールデータの一例を示した図である。
【符号の説明】
１００ 業務管理サーバ
１０３ ジョブ実行制御モジュール
１０４ スケジュール前処理モジュール
１０５ 優先順位判別モジュール
１０６ 表示・通知モジュール
１０７ データ転送モジュール
１０８ ジョブ
１０９ スケジュールデータ
１１０ 再スケジュールデータ
１２０ ディスク管理サーバ
１２３ ディスク管理モジュール
１２４ ファイル・ディスク対応データ
１２５ ディスク装置
１２６ ディスク装置
１３０ バックアップサーバ
１３３ バックアップ管理モジュール
１３５ 記憶装置
【発明の属する技術分野】
本発明は，業務の運用管理を行うための業務運用管理システムに関するものである。
【０００２】
【従来の技術】
コンピュータが処理を行う複数のジョブを１つの業務とし、更に複数の業務をスケジュールに従って実行する技術がある。またこれらの業務を実行するためにコンピュータは、データを記憶する記憶装置と接続されたシステムとなっている。このような技術において障害は発生した場合、できるだけ早急に業務を復帰させる必要がある。
【０００３】
例えば、特開平７−５６７９３号公報には、ファイル障害が発生した際に、オペレータの介在無しに障害復旧を行うために、障害ファイル名、障害装置名に基づいて障害復旧手順及び障害復旧用ジョブ制御分を組み立てることが記載されている。また、特開２０００−７６１１０号広報には、障害を受けた分散ファイルシステムにおいて、障害を受けたファイルだけを検出し、そのファイルだけをバックアップ情報から回復し、短時間でシステムを自動回復する技術が記載されている。また、特開２００１−３５０６７３号公報には、実行済みでないジョブの処理終了予定時刻を算出し、この時刻が各ジョブの終了すべき時刻より前であればスケジュールに組み込み、優先度に従って抽出された順に実行順序を付与してスケジュールを再構成し、再構成されたスケジュールによりジョブを実行することが開示されている。
【０００４】
【発明が解決しようとする課題】
特開平７−５６７９３号公報及び特開２０００−７６１１０号に記載された技術では、業務のスケジュールを再構成することについては開示されていない。また、特開２００１−３５０６７３号は復電時に、復電時刻に応じたジョブスケジュールを再構成するものであり、ファイルの障害については開示されていない。
【０００５】
本発明は、記憶装置に障害が発生した場合に業務の実行スケジュールを再構成するシステム、方法を提供することを目的とする。
【０００６】
【課題を解決するための手段】
業務に使われているファイルと業務の最終完了時間、その業務の重要度を業務運用管理のスケジュールデータの中に組み込んでおき、障害が起こった時にスケジュールデータを参照することにより問題となる業務を把握し、さらにディスク回復時間の条件から、それぞれにおける業務の緊急度を割り出しスケジュールの再構築を自動で行う。
【０００７】
【発明の実施の形態】
以下、図面を用いて説明する。
【０００８】
図１は業務を実行するシステム構成を示したものである。本システムは、業務の運用管理と業務の実行を行う複数の業務管理サーバ１００、業務の実行により生成されたデータ又は業務の実行に必要なデータを記憶する複数のディスク装置１２５、１２６、ディスク装置１２５、１２６へのデータの書き込み及び読み出しを制御するディスク管理サーバ１２０、ディスク装置１２５、１２６に記憶されたデータが記憶されている記憶装置１３５、記憶装置１３５へのデータの書き込み及び読み出しを制御するバックアップサーバ１３０とを有している。
ここで、記憶装置１３５は、ディスク装置１２５、１２６のデータのバックアップに利用されるものであり、ディスクにより構成されたものであっても、テープで構成されたものであってもよい。図１に示された業務管理サーバ１００、ディスク管理サーバ１２０、バックアップサーバ１３０は、プログラムやデータを記憶する記憶部１０１、１２１、１３１と、プログラムの実行を行うＣＰＵなどの処理部１０２、１２２、１３２とを有している。従って、各サーバは汎用のコンピュータであっても、また専用のハードウェアにより構成されているものでもよい。以下、各サーバについて具体的に説明する。
【０００９】
ここで、業務管理サーバ１００は同じ機能を実現するものであり、構成も同じものである。但し、各業務管理サーバで実行される業務又はジョブは異なる場合がある。
【００１０】
業務管理サーバ１００は、ジョブを実行するジョブ実行制御モジュール１０３、障害ディスクの回復にどれほどの時間が掛かるかを算出し、障害に影響のない業務をどのように処理するかを決めるスケジュール前処理モジュール１０４と、業務のスケジュールの再構築を行う優勢順位判別モジュール１０５と、障害が起こったとき業務に対して処理の緊急度を画面に表示し、それぞれの業務の担当者に障害の通知をする表示・通知モジュール１０６、データのバックアップやリストアを行うためにデータ転送モジュール１０７と、実行される複数のジョブ１０８とを有している。これらのモジュール及びジョブはソフトウェアプログラムであり、記憶部１０１に格納されている。尚、業務とは１つのジョブ１０８或いは複数のジョブ１０８の塊を意味する。また、記憶部１０１には、業務が実行されるスケジュールを定義したスケジュールデータ１０９、障害が発生したときにスケジュールを変更する業務の情報が登録された再スケジュールデータ１１０が記憶されるようになっている。
【００１１】
ディスク管理サーバ１２０は、ディスク管理モジュール１２３、どのディスク装置にどのファイルが記憶されているかを記したディスク・ファイル対応データ１２４とを有している。ディスク管理モジュール１２３はいくつかの機能を有しており、各機能について説明する。まず第１に、ディスク装置１２５、１２６へのデータの書き込みやデータの読み出しを行うアクセス制御機能である。次に、ディスク装置１２５、１２６へのデータの書き込み、読み出しを監視し、書き込み又は読み出しができない場合に、ディスク装置の障害であると判断し、障害が発生したディスク装置を特定する識別子を業務管理サーバ１００へ報告する機能である。この場合、業務管理サーバ１００からのアクセス要求によりディスク装置へアクセスした際に、読み出し又は書き込みができずディスク装置に障害が発生したことを検出する。従って、障害が発生した場合にはアクセス要求を受けた業務管理サーバ１００へ報告を行う。また、管理サーバ１００からのアクセス要求に基づいてディスク装置に格納されるデータのファイル名をファイル・ディスク対応データ１２４として格納する機能である。また、管理サーバ１００からの要求に応じてファイル・ディスク対応データ１２４を管理サーバ１００へ送る機能である。尚、ディスク管理モジュール１２３は、ソフトウェアプログラムであり記憶部１２１に記憶されている。
【００１２】
ディスク管理サーバ１２０に接続されたディスク装置１２５、１２６は、管理サーバ１００で実行されたジョブの結果や、ジョブに利用されるデータが格納されている。
【００１３】
バックアップサーバ１３０は、記憶装置１３５へのアクセスを管理するアクセス管理モジュール１３３を有している。尚、このモジュールもソフトウェアプログラムであり、バックアップサーバ１３０の記憶部１３１に記憶されている。記憶装置１３５は、バックアップのための記憶装置であり、業務管理サーバ１００、１１０によりディスク装置１２５、１２６のバックアップの対象となったデータが記憶されている。
【００１４】
図２にスケジュールデータ１０９の一例を示す。このスケジュールデータは、管理者によって設定され、ジョブ実行制御モジュール１０３は、このスケジュールデータを監視し、このスケジュールデータに従ってジョブを実行する。スケジュールデータ１０９は、業務の運用を管理するための情報であって、業務をどのように行っていくのかといった情報と、障害時における業務の優先度が含まれている。具体的には、開始時間２０２、実行時間２０３、スキップ設定２０４、リミッタ設定２０５、使用ファイル２０６、状態２０７が登録されている。開始時間２０２とは業務の開始時刻を示すものであり、実行時間２０３とは業務が終了するまでかかる時間である。スキップ設定２０４とは、これが「あり」と設定されると、この業務は実行しなくても良いことを示す。例えば、次の日に行ってもそれほど問題とならないような業務に対して設定される。リミッタ設定２０５とは、必ず終了しなければならない時刻である。使用ファイル２０６とは、当該業務を行う上で必要となるファイルである。状態２０７とは、業務の状態が登録されるもので、業務が終了した場合には「終了」、業務を実行中の場合は「実行中」が登録される。何も登録されていない場合は、まだ実行されていない状態を意味する。この実行状態２０７は、ジョブ実行制御モジュール１０３により登録される。尚、各々の業務は既に説明したように１つ又は複数のジョブによって構成されており、それぞれのジョブは業務と対応付けられており、業務が特定されるとジョブが特定できるようになっている。ジョブ実行制御モジュール１０３は、スケジュールデータ１０９を監視し、業務の実行時刻になったら、当該業務により特定されるジョブ１０８を実行する。
【００１５】
業務管理サーバ１００内の再スケジュールデータ１１０も図２に示したのとほぼ同じ情報を有している。つまり、業務名、開始時間、実行時間、スキップ設定、リミッタ設定、使用ファイルが登録される。但し、状態は登録されていない。
【００１６】
図３にファイル・ディスク対応データ１２４の一例を示す。ファイル・ディスク対応データ１２４は、それぞれのディスク装置１２５、１２６に記憶されているファイル情報３０２、３０３を示すものである。ディスク装置１２５、１２６はデータの塊としてファイル単位で記憶されており、ファイル情報３０２、３０３は、そのファイル名を意味する。
【００１７】
図１に示した業務管理サーバ１００は、ディスク装置の障害がディスク管理サーバ１２０から報告されると、スケジュール通りに業務が実行できるかを判断し、スケジュール通りに業務が実行できない場合には、スケジュールデータを変更する。以下、障害の報告を受けた業務管理サーバ１００の処理について説明する。
【００１８】
図４は、スケジューリングの再構築の処理全体を示したものである。ディスク装置の障害の報告を受けた業務管理サーバは、優先順位判別モジュール１０５を実行する。優先順位判別モジュール１０５により、スケジュールデータ１０９に登録されている業務で、まだ実行されていない業務の情報（業務名、開始時間、実行時間、スキップ設定、リミッタ設定、使用ファイル）をスケジュールデータ１０９から削除し、再スケジュールデータ１１０へ登録する（４０１）。次に、ファイル・ディスク対応データ１２４を送るようにディスク管理サーバ１２０へ要求する（４０２）。ディスク管理サーバ１２０のディスク管理モジュール１２３は、障害が発生したディスク装置のファイル・ディスク対応データ１２４を業務管理サーバへ送る。ファイル・ディスク対応データ１２４を受取った業務管理サーバは、優先順位判別モジュール１０５により障害が発生したディスク装置に記憶されたファイルを利用する業務を特定する（４０３）。例えば、ディスク装置１２５に障害が発生した場合、図２と図３よりディスク装置１２５に入っていたａ，ｂ，ｃというファイルを使用する業務Ａ、業務Ｂ、業務Ｃが特定される。
【００１９】
次に、スケジュール前処理モジュール１０４により、障害が発生したディスク装置の回復時間を求めると共に、再スケジュールデータ１１０に登録されている業務で障害が発生したディスクを利用しない業務についてのスケジュールの調整を行う（４０４）。
【００２０】
図５は、スケジュール前処理モジュール１０４の処理を示したものである。まず、障害が発生したディスク装置に格納されたファイル情報をバックアップサーバ１３０に送る。バックアップサーバ１３０のアクセス管理モジュール１３３は、送られてきたファイル情報から、それぞれのファイルの容量を求め、業務管理サーバへ送る。スケジュール前処理モジュール１０４は、送られてきたファイルの容量から、障害が発生したディスク装置が回復するまでにかかる時間を次式により求める（５０１）。
〔回復時間〕＝〔ボリューム交換時間〕＋〔容量〕／〔転送速度〕
ここで、ボリューム交換時間、転送速度は予め定数として与えておく。尚、ここでは、ファイル情報に基づいてアクセス管理モジュール１３３が容量を求める構成としているが、バックアップサーバ１３０でディスク装置ごとにファイルを管理している場合には、業務管理サーバから障害が発生したディスク装置を特定する識別子を送ることでディスク装置に記憶されたファイルの容量を求めることができる。
【００２１】
次に、再スケジュールデータ１１０に登録されている業務の中で、障害が発生したディスク装置を利用しない業務を特定し、この特定された業務の中から処理５０１で求めた回復時間内に実行される業務を求める（５０２）。回復時間内で実行される業務がある場合（処理５０２で「Ｙｅｓ」）、その業務がディスク回復時間（上記の式で求めた回復時間。）内に終了できる業務かどうかを判別する（５０３）。回復時間の間に終了できる業務（処理５０３で「Ｙｅｓ」）ならば当該業務をスケジュールデータ１０９に登録し、この業務を再スケジュールデータ１１０から削除し（５１０）、処理を終了する。回復時間の間に終了できない業務である場合（処理５０３で「Ｎｏ」）、業務の開始時間を早める（５０４）。
【００２２】
その業務開始時間を早めることによって、回復時間内に終了するか判別する（５０５）。回復時間内に業務が終了する場合（処理５０５で「Ｙｅｓ」）、開始時間を変更した業務の情報をスケジュールデータ１０９に登録し、再スケジュールデータ１１０から削除し（５１０）、処理を終了する。尚、処理５０３で「Ｎｏ」となり、スケジュールデータ１０９に登録されている業務のスケジュールが密なため、開始時間を早めることができない業務も、処理５０５の判断を行い処理が行われる。
【００２３】
回復時間内に業務が終了しない場合（処理５０５で「Ｎｏ」）、回復時間の終了時点で、その業務が所定のしきい値以上で終らせることができるかどうかを判別する（５０６）。しきい値は予め設定され、ここでは８０％として説明する。再スケジュールデータ１１０の実行時間より業務の実行にかかる時間が分かるので、業務の開始時間が決まれば、回復時間終了時点で、どの程度業務が行われたかがわかる。処理５０６では、回復時間の終了時点で業務の８０％が終了しているかを判断する。しきい値以上の業務が終了しない場合（処理５０６で「Ｎｏ」）、他の業務管理サーバで実行可能か判断する（５０７）。具体的には、業務名、業務の開始時間、実行時間、リミッタ設定値とを他の業務管理サーバへ送り、他の業務管理サーバから業務実行の可否の報告を受ける。他の業務管理サーバから実行が可能であるとの報告を受けると（処理５０７で「Ｙｅｓ」）、報告を受けた業務管理サーバに業務実行の依頼を通知する。この時に、再スケジュールデータ１１０に登録されている当該業務を削除する。尚、他の業務管理サーバで当該業務を実行するためには、他の業務管理サーバで当該業務を実行するためのジョブが予め登録されている必要があるが、当該ジョブを有していない場合、業務を依頼する業務サーバへ業務の実行を依頼する際に、業務の実行に必要なジョブを転送する。他の業務管理サーバで業務を実行できない場合（処理５０７で「Ｎｏ」）、処理を終了する。
【００２４】
しきい値以上の処理が終了できる場合（処理５０６で「Ｙｅｓ」）、当該業務の終了時間を新たな回復時間として（５０９）、スケジュールデータ１０９へ当該業務の情報を登録し、再スケジュールデータ１１０から当該業務の情報を削除する。尚、このとき開始時間が変更されていれば、変更された開始時間がスケジュールデータ１０９に登録される。再スケジュールデータ１１０に他の登録されている業務があれば（処理５１１で「Ｙｅｓ」）、再び処理５０２から処理を実行する。ジョブ実行制御モジュール１０３は、スケジュールデータ１０９によりジョブを実行しており、図５の処理５１０でスケジュールデータ１０９に登録された業務を実行する。
【００２５】
スケジュール前処理モジュール１０４でスケジュールの調整が終了すると、再び優先順位判別モジュール１０５により、図４の処理が行われる。
【００２６】
優先順位判別モジュール１０５は、再スケジュールデータ１１０に登録されている業務についてのスケジュールを決定する（４０５）。ここで、再スケジュールデータ１１０に登録されている業務は、障害が発生した以降に実行される業務から、回復時間内に終了する業務を除いたものとなっている。
【００２７】
図６、７は、処理４０５のスケジュール決定の処理を示したものである。
【００２８】
まずディスク装置の回復を行った後に業務を実行するため、それぞれの業務のリミッタ時刻から回復時間を差し引く（６０１）。次に、再スケジュールデータ１１０に登録された業務を、開始時間が早い順に整理し直し、全ての業務が問題なく行えるかどうかを判定する（６０２）。すべての業務が問題なく行えるとは、各業務についてリミッタ設定値を超えることなく業務が終了される場合をいう。全ての業務が問題なく行える場合（処理６０２で「Ｙｅｓ」）、この順番でスケジュールデータ１０９へ業務の情報を登録し、再スケジュールデータから当該業務の情報を削除し（６０７）、処理を終了する。
【００２９】
このままの順番ではリミッタ設定値を超える業務がある場合（処理６０２で「Ｎｏ」）、業務終了時刻がリミッタ設定に最も近い業務を１番目の業務になるように業務の順番を入れ替える（６０３）。
【００３０】
並び替えた業務の順番で全ての業務がリミッタ設定値を超えることなく行えるかどうかを判定する（６０４）。全ての業務がリミッタ設定値を超えない場合（処理６０４で「Ｙｅｓ」）、並び替えた順番で各業務の開始時刻を設定し、スケジュールデータ１０９に業務の情報を登録し、再スケジュールデータ１１０から当該業務の情報を削除し（６０７）、処理を終了する。
【００３１】
並び替えてもリミッタ設定値を超える業務がある場合（処理６０４で「Ｎｏ」）、業務の合計とリミッタにより処理した数を比較する（６０５）。まだ動かしていない業務がある場合（処理６０５で「Ｙｅｓ」）、次にリミッタが近い業務にたいして同様の処理を行う。
【００３２】
動かせる業務がなくなった場合（処理６０５で「Ｎｏ」）、業務の中でスキップするものがあるかどうかの判定を行う（６０８）。
【００３３】
スキップ可能な業務がある場合（処理６０８で「Ｙｅｓ」）、先頭にあるスキップ可能な業務を再スケジュールデータ１１０から削除する（６０８）。尚、このときの再スケジュールデータ１１０は、図６により決定された順番で処理されるよう、開始時間が設定されている。また、先頭にあるスキップ可能な業務とは、設定された開始時間が早いものを意味する。スキップ（削除）した結果、再スケジュールデータ１１０に登録されている業務がリミッタ設定値を超えないかどうかの判別を行う（６１０）。全ての業務がリミッタ設定値を超えない場合（処理６１０で「Ｙｅｓ」）、再スケジュールデータ１１０に登録された業務の情報をスケジュールデータ１１０に登録し、再スケジュールデータから業務の情報を削除する（６１１）。次に、スキップした業務を、通知・表示部に通知する（６１２）。リミッタ設定値を超える業務がある場合（処理６１０で「Ｎｏ」）、処理６０８に戻り次にスキップできる業務を求める。スキップするものがない場合は、現在再スケジュールデータ１１０に登録されている業務の情報をスケジュールデータ１０９へ登録し、再スケジュールデータ１１０から業務の情報を削除する（６１３）。また、リミッタ設定値内に終了しない業務を、通知・表示部に通知する（６１４）。図７の処理が終了すると再スケジュールデータ１１０に登録された業務の情報は、スケジュールデータ１０９に全て登録され、再スケジュールデータ１１０の業務の情報は全て削除されている。
【００３４】
再び、図４の処理に戻り、スケジュールが決まったら、業務ビューアに変更後の業務スケジュールを表示し、管理者へ通知する（４０６）。このとき、リミッタ設定値を超える業務が管理者に分かるように例えば赤色で表示したり、リミッタ設定値を超える業務だけを他の業務と分けて表示する。
【００３５】
図８は、表示・通知モジュール１０６の処理を示したものである。まず通知された業務が、スキップされた業務なのか、リミッタの制限内に終了しなかった業務なのかを判定する（７０１）。スキップされた業務ならば、スキップした業務に対して、業務担当者にメールで通知する（７０２）。業務ビューアにスキップした業務を青色で表示する（７０３）。リミッタ設定値以内で終了しない業務に対しては、業務がリミッタからどれだけ遅れてることになるのかを計算する（７０４）。これは、スケジュールデータ１０９のリミッタ設定値、開始時刻、実行時間から求めることができる。業務の遅れが緊急連絡時間を越えるかどうかの判定を行う（７０５）。緊急連絡時間とは、管理者によって予め決められた値である。業務の遅れが緊急連絡時間を超える場合は，その業務の担当者に電話で緊急の連絡を行う（７０６）。業務ビューアにリミッタ設定値を超えてしまう業務に対して赤色で表示する（７０７）。業務の遅れが緊急連絡時間以内である場合は、その業務の担当者にメールで通知を行う（７０８）。業務ビューアにリミッタ設定以内に終了しない業務に対して黄色で表示する（７０９）。
【００３６】
図９は、業務ビューア表示例を示したものである。
【００３７】
業務ビューア８０１には管理している業務示す業務名８０２とジョブ実行スケジュール８０３が表示される。ジョブ実行スケジュールのノード８１１〜８１４を緊急度によって色で分別する。デフォルトは緑色、緊急度が高いものを赤色、緊急度が低いものを黄色、業務をスキップしたものを青色で表示する。
【００３８】
再び図４の処理に戻り、障害が起こったディスク装置のディスク回復を行うためデータ転送モジュール１０７を実行する（４０７）。データ転送モジュール１０７は、バックアップサーバ１３０から障害の発生したディスク装置へデータのリストアを実行する。
【００３９】
図１０は障害の発生によるスケジュールの変更と管理者への通知を具体的に示したものである。９０１は実行される予定の業務であり、９１１〜９１４はそれぞれの業務のノードであり、９２１〜９２４はそれぞれの業務のリミッタ設定値である。障害が発生しない場合は、ノード９１１〜９１４で示したように業務が実行される。９３１のｄｏｗＮｏは、ディスクに障害が発生した時点を示したものである。尚、この時のスケジュールデータ１０９を図１２（ａ）に示す。
【００４０】
ディスク装置１２５で障害が発生した場合、ディスク装置１２５を利用している業務はファイル・ディスク対応データ１２４より業務Ａ，業務Ｂ，業務Ｃとなる。９４１はディスク装置１２５に格納されるデータの容量から求めた回復時間である。ケース０は、業務の開始時間に基づいて並べかえた業務のスケジュールである。
ケース１は、図６に示した処理６０３〜６０６により業務が並替えられたスケジュールである。具体的には、ケース０のスケジュールに対して、終了時刻がリミッタ設定値を超える業務（ここでは、業務Ａと業務Ｃである。）のうち、終了時刻がリミッタ設定値から最も離れている業務（ここでは、業務Ｃ）を、最初に実行する業務とする。ここでは、業務Ｃ、業務Ａ、業務Ｂ、業務Ｄとなる。並替えたスケジュールに基づいて、再び終了時刻がリミッタ設定値を超える業務のうち、終了時刻がリミッタ設定値から最も離れている業務を、最初に実行する業務とする。これにより、ケース１に示すように業務Ａ、業務Ｃ、業務Ｂ、業務Ｄの順に並替えられる。
【００４１】
順序を変更しても，リミッタ設定を超える業務があるので，次に図７の処理を行う。しかしながら、図１２（ａ）に示すように、スキップ設定に「あり」と示された業務がないので、そのまま処理を終了する。これにより表示・通知モジュール１０６は、リミッタ設定値を超える業務について次のように処理が行われる。
【００４２】
業務Ａと業務Ｃの担当者に連絡を送る。連絡の選択の方法は，リミッタ設定値から終了時刻がどれだけ離れているかによって決まる。リミッタ設定値から離れている時間が、緊急連絡時間以内である業務Ａに対しては、業務Ａの担当者にメールで連絡を送ると共に、業務ビューアに業務Ａを黄色で表示する。リミッタ設定値から離れている時間が緊急連絡時間を超える業務Ｃに対しては、業務Ｃの担当者に電話で連絡すると共に、業務ビューアに業務Ｃを赤色で表示する。ディスク回復後に、スケジュールデータ１０９に登録された通りにジョブの実行を行い、担当者は必要があればスケジュールデータ１０９を変更する。
【００４３】
ケース２は、図１２（ｂ）に示すように、スキップする業務があった場合に設定されたスケジュールを示したものである。ここでは、図１２（ｂ）より業務Ａがスキップ設定「あり」となっているので、業務Ａがスケジュールから削除されている。この場合、表示・通知モジュール１０６により、業務ビューアに再スケジュールした業務スケジュールを表示する。また、業務Ａがスキップしたことを担当者にメールで連絡し、業務ビューアには業務Ａを青色で表示する。
【００４４】
図１１は、図１２（ｃ）のるように障害発生前に業務Ａ、業務Ｄ、業務Ｂ、業務Ｃとスケジュールデータ１０９が設定されている場合のスケジュールの変更の例を示したものである。図１０と同じ符号のものは、図１０と同じ意味を示すものである。ディスク装置１２５で障害が発生した場合、図１０で説明したのと同様に業務Ａ、業務Ｂ、業務Ｃがディスク装置１２５を利用する業務であると特定される。
【００４５】
次に、図５に示した処理により、障害が発生したディスク障害１２５を利用しない業務で、回復時間内に実行予定の業務があるかを判別する。ここで、業務Ｄは障害の発生したディスク装置１２５を利用しない業務であり、回復時間内に実行が予定されている業務である。
【００４６】
業務Ｄは、ディスク回復時間内で終了しないので（１）、業務Ｄの開始時間を早める（２）。開始時間を早めても業務Ｄの終了時刻は、回復時間を超えてしまうので、回復時間の終了時点でどの程度業務が終了しているかを求める。業務が終了した程度が、予めさだめたしきい値（例えば、８０％。）以上終了している場合には、業務Ｄを実行させ、業務Ｄの終了時刻を回復時間の終了時点として、障害が発生したディスク装置１２４を利用する業務（ここでは、業務Ａ、業務Ｂ、業務Ｃ）について図６、図７に示した処理を行う。これにより、業務Ｄ、業務Ｂ、業務Ｃの順でスケジュールが設定される（３）。尚、業務Ａについてはスキップの設定がありスケジュールから削除している。
【００４７】
最後に表示・通知モジュール１０６により、業務Ａがスキップしたことを担当者にメールで連絡し、業務ビューアには業務Ａを青色で表示する。
【００４８】
尚、スケジュールデータ１０９に登録されたデータは、障害の発生により変更されるが、例えばスケジュールデータが１日単位で決まっている場合、次の日になれば変更前のスケジュールデータ１０９に設定されるようになっている。
【００４９】
また、障害が発生すると障害が発生した後に実行されるすべての業務を対象に図４〜８の処理を行ったが、業務の終了時刻と業務の開始時刻との間が回復時間よりも大きければ、その後の業務については図４〜８の処理を行う必要がない。例えば、業務Ａ、業務Ｂ、業務Ｃ、業務Ｄ、業務Ｅとあり、業務Ｃの終了時刻から業務Ｄの開始時刻までの時間が、回復時間よりも大きければ、業務Ｄ、業務Ｅについては、図４〜８の対象外としてもよい。これを実現するためには、例えば図５の処理５０１で回復時間が求められた後に、業務の終了時刻から次の業務の開始時刻までの時間を求め、この時間が回復時間より大きければ、それ以降の業務の情報をスケジュールデータ１０９に登録し、再スケジュールデータから削除する処理を行えばよい。
【００５０】
このように、障害によってどの業務に問題があるのかを管理者が探す必要がなくなる。また業務のスケジューリングを自動的に組みなおすことができる。スケジューリングできない場合でも、画面に問題となる業務とその緊急度を表示するので、管理者は問題となる業務の早期発見と修正を行うことができる。
【００５１】
【発明の効果】
以上説明したように、ディスクの障害に対した業務のスケジュールを設定することができる。
【図面の簡単な説明】
【図１】システムの構成を示した図である。
【図２】スケジュールデータの一例を示した図である。
【図３】ディスク・ファイル対応データの一例を示した図である。
【図４】スケジュール設定の処理を示した図である。
【図５】スケジュール設定の処理を示した図である。
【図６】スケジュール設定の処理を示した図である。
【図７】スケジュール設定の処理を示した図である。
【図８】表示及び通知の処理を示した図である。
【図９】設定されたスケジュールの表示例を示した図である。
【図１０】処理の具体例を示した図である。
【図１１】処理の具体例を示した図である。
【図１２】スケジュールデータの一例を示した図である。
【符号の説明】
１００ 業務管理サーバ
１０３ ジョブ実行制御モジュール
１０４ スケジュール前処理モジュール
１０５ 優先順位判別モジュール
１０６ 表示・通知モジュール
１０７ データ転送モジュール
１０８ ジョブ
１０９ スケジュールデータ
１１０ 再スケジュールデータ
１２０ ディスク管理サーバ
１２３ ディスク管理モジュール
１２４ ファイル・ディスク対応データ
１２５ ディスク装置
１２６ ディスク装置
１３０ バックアップサーバ
１３３ バックアップ管理モジュール
１３５ 記憶装置
Claims (8)
- スケジュールに従って業務を実行するサーバと、前記サーバによって処理されたデータが記憶される第１の記憶装置と、前記第１の記憶装置に記憶されたデータが記憶される第２の記憶装置とを有する業務処理システムにおいて、
前記サーバは、前記第１の記憶装置の障害情報に基づいて、障害回復後に実行すべき業務を特定し、特定された前記業務の優先度に基づいて特定された前記業務のスケジュールを生成することを特徴とする業務処理システム。 - 請求項１記載の情報処理システムにおいて、前記サーバは、前記第２の記憶装置から前記第１の記憶装置へデータを転送する時間から、障害回復後に実行すべき業務であって前記第１の記憶装置を利用しない業務のスケジュールを生成することを特徴とする業務処理システム。
- 請求項１記載の情報処理システムにおいて、前記サーバは、障害によって決められた時間内に終了できない業務を、当該業務の担当者に通知する際に、業務の緊急度に応じて担当者への通知方法を変更することを特徴とする業務処理システム。
- 請求項１記載の情報処理システムにおいて、前記サーバは、障害によって決められた時間内に終了できない業務を、当該業務の優先度に応じた表示方法で表示することを特徴とする業務処理システム。
- 記憶装置へのデータの書き込み又は読み出しを伴う業務をスケジュールに従って管理する業務管理方法であって、
データの書き込み又は読み出しを行う記憶装置の障害情報によって、障害回復後に実行すべき業務を特定し、特定された前記業務の優先度に従って特定された前記業務のスケジュールを生成することを特徴とする業務管理方法。 - 記憶装置へのデータの書き込み又は読み出しを伴う業務をスケジュールに従って管理する業務管理方法であって、
データの書き込み又は読み出しを行う記憶装置の障害情報によって、障害回復後に実行すべき業務を特定し、前記記憶装置へのデータのリストアが終了する時刻を求め、当該求めた時刻から特定された前記業務が予め決められた時間に終了するようスケジュールを生成することを特徴とする業務管理方法。 - 請求項６記載の業務管理方法において、特定された前記業務が予め定められた時間に終了しない場合、少なくとも優先度が高い業務が予め定められた時刻に終了するようスケジュールを生成することを特徴とする業務管理方法。
- 記憶装置へのデータの書き込み又は読み出しを伴う業務をスケジュールに従って管理するコンピュータで実行可能なプログラムであって、
データの書き込み又は読み出しを行う記憶装置の障害情報によって、障害回復後に実行すべき業務を特定し、特定された前記業務の優先度に従って特定された前記業務のスケジュールを生成することを特徴とするプログラム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002194083A JP3951835B2 (ja) | 2002-07-03 | 2002-07-03 | 業務管理方法及び業務処理システム |
| US10/371,212 US7036041B2 (en) | 2002-07-03 | 2003-02-24 | Method, program and system for managing operation |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002194083A JP3951835B2 (ja) | 2002-07-03 | 2002-07-03 | 業務管理方法及び業務処理システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004038516A true JP2004038516A (ja) | 2004-02-05 |
| JP3951835B2 JP3951835B2 (ja) | 2007-08-01 |
Family
ID=31702863
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002194083A Expired - Fee Related JP3951835B2 (ja) | 2002-07-03 | 2002-07-03 | 業務管理方法及び業務処理システム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US7036041B2 (ja) |
| JP (1) | JP3951835B2 (ja) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007122167A (ja) * | 2005-10-25 | 2007-05-17 | Fujitsu Ltd | データ転送プログラム、データ転送方法およびデータ転送装置 |
| JP2009282581A (ja) * | 2008-05-19 | 2009-12-03 | Hitachi Ltd | ビジネスプロセス実行装置およびビジネスプロセス実行方法 |
| JP2013069075A (ja) * | 2011-09-21 | 2013-04-18 | Toshiba Tec Corp | コンピュータシステム、及びジョブ制御方法 |
| CN106651161A (zh) * | 2016-12-08 | 2017-05-10 | 国网浙江杭州市富阳区供电公司 | 采集运维动态派工方法 |
Families Citing this family (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4141875B2 (ja) | 2003-03-27 | 2008-08-27 | 株式会社日立製作所 | リカバリ処理方法及びその実施システム並びにその処理プログラム |
| JP2005018510A (ja) * | 2003-06-27 | 2005-01-20 | Hitachi Ltd | データセンタシステム及びその制御方法 |
| JP2005031771A (ja) * | 2003-07-08 | 2005-02-03 | Hitachi Ltd | ジョブスケジューリング管理方法及びシステム並びにプログラム |
| JP4485763B2 (ja) * | 2003-07-10 | 2010-06-23 | 株式会社日立製作所 | 運用管理方法及び装置 |
| JP4267420B2 (ja) * | 2003-10-20 | 2009-05-27 | 株式会社日立製作所 | ストレージ装置及びバックアップ取得方法 |
| GB2409297A (en) * | 2003-12-16 | 2005-06-22 | Ibm | Method of assessing the impact of the failure of a component on the temporal activity of the services supported by the component |
| WO2005069783A2 (en) * | 2004-01-09 | 2005-08-04 | T.W. Storage, Inc. | Methods and apparatus for searching backup data based on content and attributes |
| JP4831599B2 (ja) * | 2005-06-28 | 2011-12-07 | ルネサスエレクトロニクス株式会社 | 処理装置 |
| US7707451B2 (en) * | 2005-06-28 | 2010-04-27 | Alcatel-Lucent Usa Inc. | Methods and devices for recovering from initialization failures |
| GB0605064D0 (en) * | 2006-03-14 | 2006-04-26 | Ibm | A method and system for transaction recovery time estimation |
| US8738854B2 (en) * | 2010-09-03 | 2014-05-27 | Hitachi, Ltd. | Storage apparatus and control method of storage apparatus |
| US20140040447A1 (en) * | 2012-07-31 | 2014-02-06 | Hitachi, Ltd. | Management system and program product |
| US9430335B2 (en) * | 2013-09-18 | 2016-08-30 | International Business Machines Corporation | Optimizing the number and type of database backups to achieve a given recovery time objective (RTO) |
| JP6369235B2 (ja) * | 2014-09-02 | 2018-08-08 | 富士通株式会社 | ストレージ制御装置およびストレージ制御プログラム |
| JP2016057795A (ja) * | 2014-09-09 | 2016-04-21 | 富士通株式会社 | ストレージ制御装置，ストレージシステム及びストレージ制御プログラム |
| US11068357B2 (en) * | 2019-06-03 | 2021-07-20 | EMC IP Holding Company LLC | Uninterrupted restore operation using a time based approach |
Family Cites Families (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5574897A (en) * | 1992-09-30 | 1996-11-12 | International Business Machines Corporation | System managed logging of objects to speed recovery processing |
| US5455934A (en) | 1993-03-23 | 1995-10-03 | Eclipse Technologies, Inc. | Fault tolerant hard disk array controller |
| US6208913B1 (en) | 1993-06-25 | 2001-03-27 | Yz Systems, Inc. | Chemical injection system |
| JP2853527B2 (ja) | 1993-08-17 | 1999-02-03 | 日本電気株式会社 | ファイル障害自動復旧システム |
| US5613113A (en) * | 1993-10-08 | 1997-03-18 | International Business Machines Corporation | Consistent recreation of events from activity logs |
| FR2751106B1 (fr) * | 1996-07-11 | 1999-01-08 | Alsthom Cge Alcatel | Methode de planification de transactions distribuees |
| US6351754B1 (en) * | 1998-06-23 | 2002-02-26 | Oracle Corporation | Method and system for controlling recovery downtime |
| JP2000076110A (ja) | 1998-08-28 | 2000-03-14 | Hitachi Ltd | 分散ファイルシステムにおける回復処理システム |
| US6757850B1 (en) * | 1998-12-30 | 2004-06-29 | Ncr Corporation | Remote services management fault escalation |
| US6728879B1 (en) * | 1999-06-02 | 2004-04-27 | Microsoft Corporation | Transactional log with multi-sector log block validation |
| US6658590B1 (en) * | 2000-03-30 | 2003-12-02 | Hewlett-Packard Development Company, L.P. | Controller-based transaction logging system for data recovery in a storage area network |
| JP2001350637A (ja) | 2000-06-09 | 2001-12-21 | Nec Corp | 情報処理装置の復電時自動運転制御方式，方法および自動運転制御プログラムを記録した記録媒体 |
| WO2002007385A1 (fr) * | 2000-07-13 | 2002-01-24 | Fujitsu Limited | Dispositif de commande de surveillance |
| US6820217B2 (en) * | 2001-10-29 | 2004-11-16 | International Business Machines Corporation | Method and apparatus for data recovery optimization in a logically partitioned computer system |
| US7152181B2 (en) * | 2002-02-22 | 2006-12-19 | Bea Systems, Inc. | Method for highly available transaction recovery for transaction processing systems |
| US6947956B2 (en) * | 2002-06-06 | 2005-09-20 | International Business Machines Corporation | Method and apparatus for selective caching of transactions in a computer system |
| US6944789B2 (en) * | 2002-06-11 | 2005-09-13 | Hitachi, Ltd. | Method and apparatus for data backup and recovery |
| JP4141875B2 (ja) | 2003-03-27 | 2008-08-27 | 株式会社日立製作所 | リカバリ処理方法及びその実施システム並びにその処理プログラム |
| US7139629B2 (en) | 2003-04-28 | 2006-11-21 | Palo Alto Research Center Incorporated | Planning and scheduling for failure recovery system and method |
| US7100076B2 (en) | 2003-05-09 | 2006-08-29 | Hewlett-Packard Development Company, L.P. | Minimum latency reinstatement of database transaction locks |
-
2002
- 2002-07-03 JP JP2002194083A patent/JP3951835B2/ja not_active Expired - Fee Related
-
2003
- 2003-02-24 US US10/371,212 patent/US7036041B2/en not_active Expired - Fee Related
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007122167A (ja) * | 2005-10-25 | 2007-05-17 | Fujitsu Ltd | データ転送プログラム、データ転送方法およびデータ転送装置 |
| JP2009282581A (ja) * | 2008-05-19 | 2009-12-03 | Hitachi Ltd | ビジネスプロセス実行装置およびビジネスプロセス実行方法 |
| JP2013069075A (ja) * | 2011-09-21 | 2013-04-18 | Toshiba Tec Corp | コンピュータシステム、及びジョブ制御方法 |
| CN106651161A (zh) * | 2016-12-08 | 2017-05-10 | 国网浙江杭州市富阳区供电公司 | 采集运维动态派工方法 |
| CN106651161B (zh) * | 2016-12-08 | 2020-10-20 | 国网浙江杭州市富阳区供电公司 | 采集运维动态派工方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| JP3951835B2 (ja) | 2007-08-01 |
| US7036041B2 (en) | 2006-04-25 |
| US20040078628A1 (en) | 2004-04-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2004038516A (ja) | 業務処理システム、運用管理方法及び運用管理を行うためのプログラム | |
| US10725965B1 (en) | Systems and methods for managing copy creation and deletion | |
| US10860401B2 (en) | Work flow management for an information management system | |
| CN110309024B (zh) | 数据处理***及其执行数据处理任务的方法 | |
| JP6669682B2 (ja) | クラウドサーバスケジューリング方法及び装置 | |
| US8959509B1 (en) | Techniques for virtual machine backup scheduling | |
| US8856793B2 (en) | System, method and program for scheduling computer program jobs | |
| US6694345B1 (en) | External job scheduling within a distributed processing system having a local job control system | |
| US7657583B2 (en) | Calculating recovery time of an application system | |
| US10083094B1 (en) | Objective based backup job scheduling | |
| CN106406993A (zh) | 一种定时任务管理方法和*** | |
| US20130332505A1 (en) | Intelligent scheduling for remote computers | |
| Amvrosiadis et al. | Identifying trends in enterprise data protection systems | |
| US9838332B1 (en) | Dynamically meeting slas without provisioning static capacity | |
| US7266781B1 (en) | Method and apparatus for generating a graphical display report | |
| CN105760240A (zh) | 分布式任务处理方法及装置 | |
| CN108268211B (zh) | 一种数据处理方法及装置 | |
| US10003646B1 (en) | Protection status determinations for computing devices | |
| US9639701B1 (en) | Scheduling data protection operations based on data activity | |
| US11042454B1 (en) | Restoration of a data source | |
| CN109376137B (zh) | 一种文件处理方法及装置 | |
| US8972352B1 (en) | Probe based backup | |
| US20160359953A1 (en) | Migration enhanced by presence, instant messaging, and last log-on time | |
| US8589354B1 (en) | Probe based group selection | |
| CN110659161B (zh) | 一种基于Docker的备份数据有效性验证方法及*** |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040713 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060322 |
|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20060419 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060518 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20060822 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060919 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20061025 |
|
| 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: 20070403 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070416 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110511 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110511 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120511 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120511 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130511 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130511 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |