(57)【要約】      （修正有）【課題】情報処理装置の障害発生時におけるメモリダンプデータの保存領域を削減する。【解決手段】システム起動（１０１）時に、ダンプファイル生成管理部（１０６）は、障害発生時に保存した元ダンプデータ（１１１）が存在していればダンプマップ生成部（１０７）に対して処理を要求する。ダンプマップ生成部（１０７）は、元ダンプデータ（１１１）を変換後ダンプファイル（１１３）にコピーする。元ダンプデータ（１１１）上に存在していたユーザデータについて、回復が必要であれば、実データ（１１８）上に回復対象のユーザデータである抽出後実データ（１１９）を書き込み、変換後ダンプファイル（１１３）から該ユーザデータを削除するとともに、変換後ダンプファイル（１１３）と実データ（１１８）との対応関係をダンプデータブロックマッピングテーブル（１１４）に記録する。【選択図】図１
2008293108.tif 000002
【特許請求の範囲】
【請求項１】
情報処理装置の障害発生時によるシステムダウン時に実メモリ上のユーザデータをダンプデータとして外部記憶装置に保存し、これを元に障害原因を調査するダンプデータ管理
システムにおいて、
障害発生時に外部記憶装置上の実データに反映できなかったユーザデータについてダンプデータ上のユーザデータを元に実データに回復した後にダンプデータ内の該当ユーザデータを削除する手段と、
削除したダンプデータ内のユーザデータと実データ内のユーザデータとの対応関係情報を保持する手段と、
実データへのアクセスが発生した場合にダンプデータ内のユーザデータの変更であれば実データ内の該当ユーザデータを変更する前に該当ユーザデータをダンプデータへ書き戻して実データと分離する手段と
を有することを特徴とするダンプデータ管理システム。
【請求項２】
前記ダンプデータを解析する際に、参照する箇所が前記ユーザデータであった場合に、前記対応関係情報に基づいて前記実データ内の該当するユーザデータから参照する手段を備えることを特徴とする請求項１に記載のダンプデータ管理システム。
【請求項３】
前記ダンプデータを他のシステムに移動する際に、前記ダンプデータと前記ユーザデータとの両方を１つの連続したダンプデータに再構成して移動する手段と、
移動した後に前記ダンプデータと前記対応関係情報とを削除する手段とを備えることを特徴とする請求項１又は２に記載のダンプデータ管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ダンプデータ管理システムに関し、特に、システムダウン後のデータ回復を迅速に行い、かつ、データ回復に必要なデータを保持するディスク領域を最小限に節約するシステムである。
【背景技術】
【０００２】
情報処理装置の障害発生時に、障害の原因を調査する方法として、障害発生時の実メモリ上データのコピーをとるメモリダンプ機能が存在している。このメモリダンプ機能を利用した技術として、実メモリ上で編集していたデータを、メモリダンプより抽出してデータ（ユーザデータ）の回復を効率よく行う事が可能なシステムがある。これについては、下記の特許文献１に記載の技術が知られている。
【０００３】
【特許文献１】特開平０９−２４４９０７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
上記特許文献１に記載の方法は、データ回復を行うことを開示しているが、回復後に、データはメモリダンプ上と実ユーザデータ（実データ）上との２箇所に重複して存在することとなり、ディスク領域を２倍必要とするという問題がある。例えば、システム上でメモリダンプを複数管理する場合には、この重複によりディスク領域が大きく圧迫される可能性もある。
【０００５】
メモリダンプの容量を削減する方法としては、メモリダンプ自身を圧縮して保存する方法が一般的であるが、この方法では、抽出したデータを解析するためには、一旦解凍する必要があるため、解析に時間を要し、解凍時には元ダンプデータと同容量のディスク領域が必要となるという問題もある。
【０００６】
本発明の目的は、ディスク上の無駄な領域を削減することである。また、解析時の時間的効率を改善することである。
【課題を解決するための手段】
【０００７】
本発明によるダンプデータ管理システムでは、現在二重に存在しているメモリダンプ上と実ユーザデータ上とのユーザデータを一元管理し、ディスク上の無駄な領域を削減する。また、解凍を行うことなくそのまま解析を可能とすることにより、解析時の時間的効率を改善する。
【０００８】
本発明の一観点によれば、情報処理装置の障害発生時によるシステムダウン時に実メモリ上のユーザデータをダンプデータとして外部記憶装置に保存し、これを元に障害原因を調査するダンプデータ管理システムにおいて、障害発生時に外部記憶装置上の実データに反映できなかったユーザデータについてダンプデータ上のユーザデータを元に実データに回復した後にダンプデータ内の該当ユーザデータを削除する手段と、削除したダンプデータ内のユーザデータと実データ内のユーザデータとの対応関係情報を保持する手段と、実データへのアクセスが発生した場合にダンプデータ内のユーザデータの変更であれば実データ内の該当ユーザデータを変更する前に該当ユーザデータをダンプデータへ書き戻して実データと分離する手段と、を有することを特徴とするダンプデータ管理システムが提供される。これにより、メモリダンプ内のユーザデータの領域と実データ上のユーザデータの領域が同一であれば１つにすることができ、外部記憶装置内の領域を削減することができる。
【０００９】
前記ダンプデータを解析する際に、参照する箇所が前記ユーザデータであった場合に、前記対応関係情報に基づいて前記実データ内の該当するユーザデータから参照する手段を備えることが好ましい。これにより、外部記憶装置内の領域を削減したまま直接参照することができ解析時に必要となる領域が削減できる。また、ダンプデータの復元の時間が短縮できる。
【００１０】
前記ダンプデータを他のシステムに移動する際に、前記ダンプデータと前記ユーザデータとの両方を１つの連続したダンプデータに再構成して移動する手段と、移動した後に前記ダンプデータと前記対応関係情報とを削除する手段と、を備えることが好ましい。これにより、外部記憶装置からダンプデータを移動、削除できることが可能である。
【発明の効果】
【００１１】
本発明のダンプデータ管理システムでは、ダンプデータ領域を実データに反映させた状態で削減することができるうえ、解析する際にもダンプデータ領域を増大させる必要がなく、少ないディスク領域で多数のメモリダンプを同時に保持しながら解析する事が可能となり、解析の準備に必要な時間も短縮できるため、今後のシステム搭載メモリの拡大においても有効である。
【発明を実施するための最良の形態】
【００１２】
本明細書において、実データは、管理データとユーザデータとを含む。ユーザデータは、ユーザが用いているデータである。管理データは、種々の権利を行うためのデータである。ユーザデータであるか否かは、ＯＳの管理テーブルに基づいて判定することができる。
【００１３】
以下、本発明の一実施の形態によるダンプデータ管理システムについてダンプデータ管理システム図面を参照しながら説明を行う。図１は、本実施の形態によるダンプデータ管理システムの一構成例を示す機能ブロック図である。図１に示すように、本実施の形態によるダンプデータ管理システムは、オペレーティングシステム（１０５）内の、ダンプファイル生成管理部（１０６）、ダンプマップ生成部（１０７）、アクセス管理部（１０８）、ダンプ再構成部（１０９）、ダンプ転送部(１１０)、有して構成されている。
【００１４】
ダンプファイル生成管理部（１０６）は、処理すべき元ダンプデータ（１１１）の存在を確認し、処理の要否を判断する。システム起動（１０１）をトリガーに、障害発生時に保存した元ダンプデータ（１１１）が存在しているか否かを確認し、元ダンプデータ（１１１）が存在していればダンプマップ生成部（１０７）に対して処理を要求する。
【００１５】
ダンプマップ生成部（１０７）は、ダンプファイル生成管理部（１０６）からの要求を受け、元ダンプデータ（１１１）から変換後ダンプファイル（１１３）へのコピーと、変換後ダンプファイル（１１３）からのユーザデータＤ１の回復と、変換後ダンプファイル（１１３）からのユーザデータＤ１の削除とを実行する。元ダンプデータ（１１１）からメモリダンプデータを読み込み、元ダンプデータ（１１１）上に存在していたユーザデータ（Ｄ１）について、変換後ダンプファイル（１１３）とダンプデータブロックマッピングテーブル（１１４）とを作成し、ユーザデータの回復が必要であれば、実データ（１１８）上に回復対象のユーザデータである抽出後実データ（１１９）を書き込む。
【００１６】
アクセス管理部（１０８）は、ダンプマップ生成部（１０７）によるダンプ変換処理が完了した後、ダンプファイルが削除されるまでの間に、実データへのアクセス要求（１０２）よりダンプデータ上のデータに変更が発生した場合に、現在のデータを変換後ダンプファイルへ書き戻す処理を行う。実データ（１１８）へのアクセス要求があり抽出後実データ（１１９）に変更が生じる場合、抽出後実データ（１１９）よりデータを読み出し変換後ダンプファイル（１１３）へ書き戻す。その後、書き戻したデータに対応するダンプデータブロックマッピングテーブル（１１４）を更新した後に、変更データを実データ（１１８）として書き込む（Ｄ１）。
【００１７】
ダンプ再構成部（１０９）は、ダンプ解析ツールからのダンプデータ直接参照（１０３）に対して、変換後ダンプファイル（１１３）と抽出後実データ（１１９）とに分散したダンプデータを正しい場所から読み出す部分である。ダンプ解析ツールからダンプデータの参照要求があると、参照対象のページがダンプデータブロックマッピングテーブル（１１４）に存在しているか否かを検索し、参照対象のページがダンプデータブロックマッピングテーブル（１１４）に存在していれば、抽出後実データ（１１９）から読み出しを行い、参照対象のページがダンプデータブロックマッピングテーブル（１１４）に存在していなければ、変換後ダンプファイル（１１３）から読み出しを行う。
【００１８】
ダンプ転送部（１１０）は、別の記憶装置へダンプデータを移動し、移動の完了した変換後ダンプファイル（１１３）のデータを記憶装置上から削除する処理を行う（Ｄ１）。変換後ダンプファイル（１１３）とダンプデータブロックマッピングテーブル（１１４）と抽出後実データ（１１９）とから元ダンプデータ（１１１）を再構成しながら移動する。移動が完了した変換後ダンプファイル（１１３）とダンプデータブロックマッピングテーブル（１１４）とは、移動元の記憶装置から削除する。
【００１９】
このシステムにより生成される変換後ダンプファイル（１１３、１１５）とダンプブロックマッピングテーブル（１１４、１１６）とは複数存在が可能であり、１つのダンプデータにつき、１組の変換後ダンプファイル（１１３）とダンプテーブルブロックマッピングテーブル（１１４）とを持つ。
【００２０】
このシステムの前提として、このオペレーティングシステム（１０５）で使用される記憶装置へのアクセスは、オペレーティングシステムが標準的にもつデータ管理機能（ファイルシステム等）を利用したファイルのページ管理等により行われるものとする。
【００２１】
尚、図示しないが、システム起動（１０１）、実データへのアクセス要求（１０２）、ダンプデータ直接参照（１０３）、ダンプ回収（１０４）等のユーザ操作は、クライアント端末を介して、サーバコンピュータ等の情報処理装置の内部に存在するオペレーティングシステム（１０５）にアクセスすることによって行われる。
【００２２】
図２は、変換後ダンプファイル（１１３）のデータが実データ（１１８）のどの場所に回復されたかに関する関係（対応関係情報）を管理するダンプデータブロックマッピングテーブル（１１４）の一構成例を示す図である。図２に示すように、ダンプデータブロックマッピングテーブル（１１４）は、変換後ダンプファイル（１１３）のデータが元ダンプデータ（１１１）の先頭から何番目のページのデータであるかを表す元ダンプデータ内ページ番号（２０１）・（２０２）と、実データ内の先頭から何番目の領域にデータを復元したかを表す実データ内ブロック番号（２０３）・（２０４）と、の関係を管理している。ページは、オペレーティングシステムが管理するデータサイズの単位である。ページ番号（ファイルの先頭から何ビット目であるかを示す）とブロック番号とは、管理単位が一致している必要があり、ブロック番号は管理単位で記憶装置上（＝実データ（１１８）上）に先頭から付与した番号である。
【００２３】
ダンプデータブロックマッピングテーブル（１１４）に登録されている１つめのエントリの元ダンプデータ内ページ番号１（２０１）と実データ内ブロック番号１（２０３）とは、変換後ダンプファイル（１１３）から削除された削除済みデータ１（２０５）であり、抽出後実データ１（２０６）として実データ（１１８）上にのみ存在していることを意味している。
【００２４】
ダンプデータブロックマッピングテーブル（１１４）のライフサイクルについては、システム起動（１０１）の時に元ダンプデータ（１１１）から変換後ダンプファイル（１１３）を生成する時に例えば同時に作成される。その後、実データアクセス（１０２）の時に検索・一部エントリが削除され、ダンプ回収（１０４）の操作によるダンプ転送部（１１０）により変換後ダンプファイル（１１３）が全て移動すると完全に削除される。
【００２５】
尚、このダンプデータブロックマッピングテーブル（１１４）は、頻繁に参照・更新されるため、情報のディスク格納方式・メモリ管理方式ともに、高速検索・再構成が可能な技術を適用するとより効果的である。
【００２６】
図３は、変換後ダンプファイル（１１３）が複数存在する場合において、その複数の変換後ダンプファイル（１１３）を管理するダンプファイル管理テーブル（１１７）の一構成例を示す図である。このダンプファイル管理テーブル（１１７）は、管理している変換後ダンプファイル（１１３）の数（３０１）と、各変換後ダンプファイル（１１３）のダンプファイル番号（３０２、３０３…）の配列とから構成されている。ここで言うダンプファイル番号とは、オペレーティングシステムが標準的にもつデータ管理機能（ファイルシステム等）により各変換後ダンプファイル（１１３）に割り振られるシステムで唯一の番号であり、オペレーティングシステムはファイル番号よりファイルを特定する機能を有している。
【００２７】
また、ある変換後ダンプファイル（１１３）とダンプデータブロックマッピングテーブル（１１４）とは、１組で１つのダンプデータとして保存されるため、変換後ダンプファイル（１１３）のダンプファイル番号を特定することにより対応するダンプデータブロックマッピングテーブル（１１４）を参照することができる。尚、ＯＳが保持するシステムにおけるタイマにより、ダンプデータ中にはその生成日時情報が保持されている。
【００２８】
このダンプファイル管理テーブル（１１７）は、システム起動（１０１）時に変換後ダンプファイル（１１３）が生成されると、ダンプファイル数（３０１）をインクリメントし、生成した変換後ダンプファイル（１１３）のダンプファイル番号を配列に追加する。その後、実データアクセス（１０２）時に、全ダンプデータブロックマッピングテーブル（１１４）を参照するために、このダンプファイル管理テーブル（１１７）に管理されるダンプファイル番号（３０１、３０２、３０３…）を順番に対象としていく。変換後ダンプファイル（１１３）のダンプ回収（１０４）の処理が完了すると、その変換後ダンプファイル（１１３）に対応するエントリがダンプファイル管理テーブル（１１７）より削除される。
【００２９】
図４はダンプファイル生成管理部（１０６）における処理の流れを示すフローチャート図である。この処理は、システム起動時に自動的に開始される（ステップ４０１）。次いで、システムの障害時に自動的に格納された元ダンプデータ（１１１）が存在するか否かの確認を行う（ステップ４０２）。この確認については、元ダンプデータ（１１１）の領域に存在確認用のフラグをもち、ダンプマップ生成部（１０７）によりダンプファイルマップ生成が完了すると、元ダンプデータ（１１１）の存在フラグがオフとなる。元ダンプデータ（１１１）の領域は常に固定領域であり、障害により二度目の元ダンプデータ生成処理が行われると上書きされるものとし、常に１つ分の元ダンプデータ領域のみを必要とする。
【００３０】
元ダンプデータ（１１１）の存在フラグを確認することにより、元ダンプデータ（１１１）が存在しなかった場合は（ｎｏ）、そのままシステム起動を完了し何もしない（エンド）。元ダンプデータ（１１１）の存在が確認できた場合は（ｙｅｓ）、ダンプマップ生成部（１０７）を呼び出す（ステップ４０３）。
【００３１】
図５はダンプ生成部（１０７）における処理の流れを示すフローチャート図である。ダンプ生成部（１０７）は、元ダンプデータ（１１１）から変換後ダンプファイル（１１３）へ全てのデータをコピーし、コピーが完了した時点で元ダンプデータ（１１１）の存在フラグをオフとする（ステップ５０１）。元ダンプデータ（１１１）の位置はシステムにおいて固定であり定義されているものとする。ダンプ生成部（１０７）の処理が全て完了する前にもう一度障害が発生した場合には、元ダンプデータ（１１１）が上書きされるため退避が有効である。
【００３２】
変換後ダンプファイル（１１３）から、ユーザデータのページを抽出してくる（ステップ５０２）。これは上記特許文献１に記載された技術を利用しており、メモリダンプ上にユーザデータを管理するテーブルを保持しており、その管理テーブルを利用してユーザデータのページを抽出することが可能である。尚、特許文献１と異なる点は、特許文献１では、障害発生の直前に編集していた過渡状態のデータの回復を目的として抽出対象としているが、本実施の形態では、データ回復かつダンプ格納領域の削減が目的であるため、対象とするデータは編集中データだけではなく、参照のために読み込んだページも抽出対象とする。ここで抽出したページのアドレスよりページ番号を取得する。アドレスをページのサイズで割ったものがページ番号となる。
以下、ステップ５０４からステップ５０９までの処理は、ここで抽出した１つのページを処理対象とし、抽出データが存在する間、繰り返すものである（ステップ５０３）。
【００３３】
ステップ５０２で抽出したページの管理情報を変換後ダンプファイル（１１３）より読み出し、抽出したページが実データ内のどの位置に書き込まれるべきかの情報がすでに決定しているかどうかに関する情報を取得する（ステップ５０４）。ブロック番号が既に決定している場合には（ｙｅｓ）、決定しているブロック番号を記憶しておく。ブロック番号が決定しているかどうかという判定の意味は、障害が発生しメモリダンプを取得した時点で、既に、今抽出したページのデータが実データ（１１８）上のどの位置のデータに対応するかが決定していたかどうかということである。実データ（１１８）上の書き込み位置のことをブロック番号と呼ぶ。
【００３４】
ステップ５０４でのブロック番号の確認の結果、ブロック番号が決定していない場合（ｎｏ）、実データ（１１８）上より空き領域を検索し、対象のページを書き込む実データ上のブロック番号を決定する（ステップ５０５）。決定したブロック番号の領域は実データ上で使用済み領域となるように実データ上の管理情報を更新する。これらの実データ（１１８）上の空きブロック検索と取得とについては、オペレーティングシステムが標準でもつデータ管理機能（ファイルシステム等）を利用することができうる。ここで、更新する管理情報については、ダンプデータからの回復対象外としているため、更新しても問題はない。このステップまでに、ステップ５０２で抽出したデータのページ番号とブロック番号とが決定している。このページ番号とブロック番号との対を、ダンプデータブロックマッピングテーブルへ追加する（ステップ５０６）。ステップ５０２で抽出データした更新データかまたは参照データであったかをダンプ上にあるページの管理情報より取得する（ステップ５０７）。ステップ５０７における確認処理の結果、データが更新データの場合は（ｙｅｓ）、回復が必要であるため、実データ（１１８）上のブロック番号に対して抽出データの書き込みを行う（ステップ５０８）。ここで実データ（１１８）上に書き込んだデータを抽出後実データ（１１９）と呼ぶ。ステップ５０７の確認の結果、抽出データが参照データの場合は（ｎｏ）、ステップ５０８をスキップする。
【００３５】
実データ（１１８）上への回復が完了すると、変換後ダンプファイル（１１３）内に存在する抽出データの領域を削除する（ステップ５０９）。この削除処理は、抽出ページに対応する領域の解放であり、その分だけディスク領域を解放することができる。解放された領域は、空き領域として別の用途に使用することが可能となる。これによりダンプ格納領域が削減できる。
【００３６】
上記のステップ５０２からステップ５０９までの処理を繰り返し、変換後ダンプファイル（１１３）に抽出すべきユーザデータがなくなると、変換後ダンプファイル（１１３）のファイル番号を取得する（ステップ５１０）。ファイル番号については図３においても説明したが、オペレーティングシステムが標準にもつ機能であり、アクセスするファイルからファイル番号を取得する機能を有している。ステップ５１０で取得したファイル番号を、ダンプファイル管理番号テーブル（１１７）の１エントリとして追加する（ステップ５１１）。最後に、ダンプファイル管理テーブル（１１７）のダンプファイル総数をインクリメントする（ステップ５１２）。
【００３７】
図６は、アクセス管理部（１０８）における処理の流れを示すフローチャート図である。システムに対して、システム上のデータへのアクセス要求がきた場合に、そのアクセスが変更要求か参照要求かを判定する（ステップ６０１）。参照要求の場合は（ｎｏ）、通常の処理と同様に、実データの読み込み処理を行いアクセスを完了する（ステップ６０２）。変更アクセスであった場合は（ｙｅｓ）、アクセス対象のデータがすでに存在しているデータの上書きアクセスか、新規のデータアクセスか、を判断する（ステップ６０３）。この判断は、オペレーティングシステムが標準でもつデータ管理機能（ファイルシステム等）において、アクセス対象のページのブロック番号を取得する機能によって判断することが可能である。ブロック番号が取得できた場合には、既存のデータが実データ（１１８）上に存在していると判断できる。
【００３８】
ステップ６０３において、ブロック番号が取得できない場合は（ｎｏ）、新規書き込みアクセスであり、抽出後実データ（１１９）を上書きしてしまう可能性はないため通常の書き込み処理を行い（ステップ６０４）、アクセスを完了する。ステップ６０３において上書きアクセスと判断した場合は（ｙｅｓ）、実データ（１１９）上への書き込み先のブロック番号を保存する（ステップ６０５）。
【００３９】
ダンプファイル管理テーブル（１１７）より、ダンプファイル番号配列の先頭から、この後のステップ６０８からステップ６１３までの処理対象とする変換後ダンプファイル（１１３）とダンプデータブロックマッピングテーブル（１１４）とを取得する（ステップ６０６）。そして、ステップ６０８からステップ６１３までの処理を行った後、ダンプファイル番号配列の次の変換後ダンプファイル（１１３）に対して同様の処理を繰り返し、ダンプファイル管理テーブル（１１７）に存在する、変換後ダンプ総数分だけ繰り返したら処理を終了する（ステップ６０７）。ダンプデータブロックマッピングテーブル（１１４）からステップ６０３で取得したブロック番号に一致するエントリを検索する（ステップ６０８）。
【００４０】
ダンプデータブロックマッピング（１１４）に一致するエントリが存在していない場合は（ステップ６０９：ｎｏ）通常のデータ書き込み処理（ステップ６１３）を行い、アクセスを完了する。
【００４１】
ステップ６０８の検索結果エントリが存在していた場合には（ステップ６０９：ｙｅｓ）、取得したエントリのブロック番号よりページ単位で実データ（１１８）からの読み出しを行う（ステップ６１０）。
【００４２】
ステップ６０８の検索により取得したエントリの変換後ダンプファイル（１１３）のページ番号のオフセットに対してステップ６１０で読み込んだデータの書き戻しを行う（ステップ６１１）。次いで、ダンプブロックマッピングテーブル（１１４）よりステップ６０８で取得したエントリを削除する（ステップ６１２）。そして、アクセス要求のあったデータを実際に実データ（１１８）上に書き込む（ステップ６１３）。
【００４３】
図７は、ダンプ再構成部（１０９）における処理の流れを示すフローチャート図である。これはダンプ解析を行うためにダンプファイルの必要のデータを読み出すための処理であり、ダウンしたＯＳへ直接ログインして調べる場合の処理である。
【００４４】
ダンプ解析ツール（１０３）よりダンプファイル参照要求を受け取り、要求対象の変換後ダンプファイル番号と要求データのアドレスとにより、ページ番号を取得する（ステップ７０１）。次いで、ステップ７０１で取得したページが実際のディスク領域をもっているかどうかを確認する（ステップ７０２）。この処理は、オペレーティングシステムが標準的にもつデータ管理方式による機能を利用し、ページに対応するブロック番号を取得することにより可能である。ステップ７０２の処理の結果、ブロック番号を取得できれば（ｙｅｓ）取得したブロック番号よりそのままデータの読み込みを行い（ステップ７０５）、ダンプ解析ツールにデータを渡し処理を完了する（エンド）。
【００４５】
ステップ７０２の処理の結果、ブロック番号を取得できなかった場合は（ｎｏ）、抽出後実データ（１１９）上にデータを回復したということである。従って、ステップ７０１において取得した参照要求の変換後ダンプファイル番号をキーにしてダンプファイル管理テーブル（１１７）より対象の変換後ダンプファイルとそのダンプデータブロックマッピングテーブル（１１４）とを取得する。取得したダンプデータブロックマッピングテーブル（１１４）より、ステップ７０１で取得した要求ページ番号と一致するエントリを検索し取得する（ステップ７０３）。次いで、ステップ７０３で取得したエントリの実データ（１１８）上のブロック番号を取得する（ステップ７０４）。ステップ７０４において取得したブロック番号より、実データ（１１８）の読み込みを行い（ステップ７０５）、ダンプ解析ツールにデータを渡す。以後、ダンプ解析ツールより要求がある度に、上記のステップ７０１からステップ７０５までの処理を繰り返す。
【００４６】
図８は、ダンプ転送部（１１０）における処理の流れを示すフローチャート図である。この処理は、変換後ダンプファイル（１１３）を別の記憶装置へ転送する処理に相当する。ダンプファイルの転送（移動）要求に対して、指定されたダンプファイルからダンプファイルのサイズを取得する。この処理は、オペレーティングシステムが標準でもつデータ管理機能（ファイルシステム等の管理機能）により実行可能な処理である（ステップ８０１）。
【００４７】
以降、ステップ８０２からステップ８０８までの処理を、ダンプファイルのサイズになるまで、１ページずつを処理対象のページとして抽出し、処理を繰り返す（ステップ８０２）。
【００４８】
ステップ８０２により抽出されたページがブロック番号をもつかどうか確認を行う。この処理は、オペレーティングシステムが標準でもつデータ管理機能（ファイルシステム等の管理機能）により実行可能である（ステップ８０３）。
【００４９】
ステップ８０３でブロック番号が取得できた場合は（ｙｅｓ）、ステップ８０４、ステップ８０５をスキップする。ステップ８０３でブロック番号が取得できなかった場合は（ｎｏ）、現在転送要求対象の変換後ダンプファイル（１１３）に対するダンプデータブロックマッピングテーブル（１１４）を特定する。このテーブルより要求ページ番号をキーにエントリを検索し取得し（ステップ８０４）、ステップ８０４で取得したエントリより、実データ（１１８）上のブロック番号を取得する（ステップ８０５）。
【００５０】
ステップ８０３又はステップ８０５で取得したブロック番号より、抽出後実データ（１１９）よりデータの読み込みを行う（ステップ８０６）。ステップ８０６で読み込んだデータを転送する（ステップ７０７）。転送方法については一般的なデータ転送技術を利用する。データ転送後に、ステップ８０４でみつけたエントリをダンプデータブロックマッピングテーブル（１１４）より削除し、対象ページのデータを変換後ダンプファイル（１１３）より解放する。
【００５１】
ステップ８０２からステップ８０８までの処理を、ダンプファイルのサイズ分だけ繰り返し、最後にダンプファイル管理テーブル（１１７）より転送対象の変換後ダンプファイル（１１３）に対応するダンプファイル番号（３０２）のエントリを削除し、変換後ダンプファイル数（３０１）をデクリメントする。そして、記憶装置上から変換後ダンプファイルそのものを削除する（ステップ８０９）。
【００５２】
以上の処理により、ダンプデータ領域を実データに反映させた状態で削減することができる。また、データ解析を行う際においても、ダンプデータ領域を増大させる必要がなく、少ないディスク領域で多数のメモリダンプを同時に保持しながら解析することが可能となり、解析の準備に必要な時間も短縮できる。従って、今後、システム搭載のメモリの拡大に対しても寄与することができる。
【産業上の利用可能性】
【００５３】
本発明は、情報処理装置に利用可能である。
【図面の簡単な説明】
【００５４】
【図１】本発明の一実施の形態による情報処理装置のシステム制御機能の一構成例を示すブロック図である。
【図２】ダンプデータブロックマッピングの詳細を示したブロック図である。
【図３】ダンプファイル管理構成の詳細を示したブロック図である。
【図４】ダンプファイル生成管理部における処理の流れを示すフローチャート図である。
【図５】ダンプマップ生成部における処理の流れを示すフローチャート図である。
【図６】アクセス管理部における処理の流れを示すフローチャート図である。
【図７】ダンプ再構成部における処理の流れを示すフローチャート図である。
【図８】ダンプ転送部における処理の流れを示すフローチャート図である。
【符号の説明】
【００５５】
１０１…システム起動（イベント）、１０２…実データアクセス（イベント）、１０３…ダンプ解析ツールからの直接参照（イベント）、１０４…ダンプ回収（イベント）、１０５…オペレーティングシステム、１０６…ダンプファイル生成管理部、１０７…ダンプマップ生成部、１０８…アクセス管理部、１０９…ダンプ再構成部、１１０…ダンプ転送部、１１１…元ダンプデータ、１１３…変換後ダンプファイル、１１４…ダンプデータブロックマッピング、１１５…変換後ダンプファイル、１１６…ダンプデータブロックマッピング、１１７…ダンプファイル管理テーブル、１１８…実データ、１１９…抽出後実データ、２０１…元ダンプデータ内ページ番号１、２０２…元ダンプデータ内ページ番号２、２０３…実データ内ブロック番号１、２０４…実データ内ブロック番号２、２０５…削除済みデータ１、２０６…抽出後実データ１、３０１…ダンプファイル数、３０２…ダンプファイル番号、３０３…ダンプファイル番号。
【図１】
2008293108.tif 000003
【図２】
2008293108.tif 000004
【図３】
2008293108.tif 000005
【図４】
2008293108.tif 000006
【図５】
2008293108.tif 000007
【図６】
2008293108.tif 000008
【図７】
2008293108.tif 000009
【図８】
2008293108.tif 000010