JP3866038B2 - 物理レベルにおける論理オブジェクトに対する変更に基づいて、論理オブジェクトに対する変更を識別する方法および装置 - Google Patents

Description

【０００１】
（発明の分野）
本発明は、データ記憶装置に関する。本発明の一態様は、論理オブジェクトが格納されているデータ記憶システムにおいて、物理レベルに関する情報を用いることによって、論理オブジェクトに対する変更を識別する方法および装置を対象とする。本発明の別の態様は、識別子のグループを直接指定しない、データベース構造に関する情報に基づいて、データベース内部の論理データ・ユニットのロケーションを一意に指定する論理データ・ユニットの識別子を含む識別子のグループを決定することによって、データベースに属する論理データ・ユニットを識別する方法および装置を対象とする。
【０００２】
（関連技術の説明）
コンピュータ・システムは、通常、１つ以上の記憶装置を含む。図１は、かかる典型的なコンピュータ・システム１００のブロック図である。システム１００は、プロセッサ１２０およびメモリ１３０を有するホスト・コンピュータ１１０、ならびに記憶システム１４０を含む。記憶システム１４０は、多数の異なる種類の記憶装置（例えば、テープ記憶装置、フロッピ・ディスケット記憶装置、ディスク記憶装置等）のいずれの１つとすることもでき、あるいは異なる種類の記憶装置の組み合わせを含むこともできる。
【０００３】
ワード・プロセッシング・アプリケーション、デスクトップ・パブリッシング・アプリケーション、データベース・ソフトウエア等のようなアプリケーション・プログラムは、プロセッサ１２０上で実行し、１つ以上の論理的に関連するデータ・ブロックから形成される論理オブジェクト（例えば、ファイル等）上で動作する。アプリケーションが論理オブジェクト上で動作を実行する際、論理オブジェクトを形成するデータ・ブロックが記憶システム１４０から読み出され、更に効率的な処理のために、ホスト・コンピュータのメモリ１３０内に一時的に格納される。アプリケーションがこの論理オブジェクト上での動作を実行し終えると、論理オブジェクトを形成するデータはメモリ１３０から読み出され、記憶システム１４０に書き込まれる。
【０００４】
多くのアプリケーションでは、記憶システム１４０上に格納されているデータから、特定の時点以降に変更したサブセットを判定できることが望ましい。このような状況の一例は、逐次バックアップ（ｉｎｃｒｅｍｅｎｔａｌ ｂａｃｋｕｐ）である。フォールト・トレラント上の理由から、個々のアプリケーションのために記憶システム１４０上に格納されているデータは、周期的にバックアップするとよいことは認められよう。多くのアプリケーションでは、記憶システム１４０上に格納されるデータ量は膨大となる可能性があり、記憶システム１４０上に格納されているデータ全てのバックアップを完全に行なうプロセスは長時間かかる可能性がある。システム・バックアップを行なうとき、アプリケーション・プログラムは他のユーザには利用できない場合があり、あるいは、当該アプリケーションおよびその他のアプリケーションによって認められるコンピュータ・システム１００の性能は、著しく損なわれる、即ち、低下し、コンピュータ・システム１００は事実上他のユーザには利用できなくなる可能性があることは認められよう。したがって、記憶システム１４０上でデータをバックアップするために要する時間量を極力抑えることが望ましい。この課題に取り組むために、逐次バックアップの概念が生み出された。これは、記憶システム１４０上のデータのサブセットに対してバックアップを行うというもので、サブセットは、最後に完全にバックアップを行なった以降に変更した（即ち、追加、削除または修正された）データ部分のみに対応する。
【０００５】
多くのコンピュータ・システムは、記憶システム１４０上に格納されているデータ全てに対して逐次バックアップを行なう能力を備えている。しかしながら、記憶システム１４０は非常に大型である可能性があり、大量のデータを格納可能であるため、記憶システム１４０全体に対する逐次バックアップの実行は、非常に時間がかかるプロセスとなる可能性があることは認められよう。したがって、記憶システム１４０上に格納されているデータの内、特定のアプリケーションに関係し、したがって論理的に関係付けられているサブセットのみに作用する逐次バックアップ能力を備えることが望ましい。多くのコンピュータ・システムは、論理的に関係付けられているデータ・セットに対して逐次バックアップを行なう能力を備えている。これを行なうには、特定の基準時点（例えば、論理的に関連付けられているデータ・セットに対して最後に全体的なバックアップを行なった時点）以降、論理的に関連付けられているデータ・セットを形成する論理オブジェクトに対して行われた変更を識別する。このような逐次バックアップ・ファシリティ（ｆａｃｉｌｉｔｙ）の一例が、ＯＲＡＣＬＥリレーショナル・データベースに設けられており、データ・ベース内に含まれているデータを、特定の基準時点に関して、逐次バックアップすることが可能である。
【０００６】
ＯＲＡＣＬＥデータベースは、典型的に、テーブルの集合として編成されており、各テーブルは１つ以上のデータ行を含む。行は、主題（ｓｕｂｊｅｃｔ）のインスタンスである。例えば、「ＣＩＴＹ」という名称のテーブルは、ボストン、ロスアンゼルス、ニューヨークおよびパリというような、異なる都市に関連する、異なるいくつかのデータ行を含むことができる。各行は、人口、平均所得等のような、主題の属性を格納する多数の列を含むことができる。
【０００７】
図２は、テーブルに対する行データが、典型的に、ＯＲＡＣＬＥデータベース・ファイルに格納される際の方法を示す構造図である。各ファイル２００は、典型的に、通常のオペレーティング・システムのファイルであり、ファイル・ヘッダ２１０およびファイル・データ２２０を含む。ファイル・データ２２０は、データ・ブロック単位２３０で編成され、各ブロックは、ブロック・ヘッダ２４０およびブロック・データ２５０を有する。ブロック・データ２５０は、実際のデータ行を含み、これがデータベース内にある１つ以上のテーブルと連携（ａｓｓｏｃｉａｔｅ）されている。ブロック・ヘッダ２４０は、それぞれのデータ・ブロック２３０内にある各データ行を識別し、各データ行がどこで始まりどこで終わるかを識別する、行ディレクトリを含む。また、ブロック・ヘッダ２４０は、それぞれのデータ・ブロック２３０内の情報が基準時点（例えば、変更ビットが最後にリセットされた時点）以来変化したか否かを識別する１つ以上の変更ビットも含む。基準時点以降にデータ・ブロック２３０内部の行データに変更が加えられたならいつでも、１つ以上の変更ビットがデータベース・ソフトウエアによってセットされるので、この変更の発生は後に識別することが可能である。
【０００８】
先に注記したように、ＯＲＡＣＬＥデータベースは、特定の基準時点以降にデータベースのデータ・ブロック２３０に変更が加えられたことを識別することができる。各データ・ブロック２３０内の変更ビットは、典型的に、データベースのバックアップ後に、データベース・ソフトウエアによってリセットされるので、この基準点は、典型的に、データベースの完全なバックアップまたは逐次バックアップを最後に行なった時点である。データベースは、最後の完全なバックアップまたは逐次バックアップ以後に変更（即ち、追加、削除、または修正）されたデータ・ブロック２３０を識別することができるので、変更したデータ・ブロックのみをバックアップすることによって、データベースの逐次バックアップを行なうことができる。逐次バックアップは、データが変更されたデータ・ブロックのみをバックアップするのであって、データベースにはわかっているデータ・ブロック全てではないので、一般に、逐次バックアップに要する時間は、特に大きなデータベースの場合には、完全なデータベースのバックアップよりも遥かに短い。この時間の節約は重要となり得る。何故なら、いずれの形態にしろ、バックアップの間データベースに対する修正は典型的に禁止されるからである。データベースの破局的な障害の場合、最後の完全バックアップおよび最新の逐次バックアップに基づいて、データベースを復元することができる。
【０００９】
ＯＲＡＣＬＥデータベースは、特定の基準時点以降にデータベースに加えられた変更を識別することができるが、どのデータ・ブロックが変化したかを判定する際に要する時間量は、データベースのサイズに直接比例する。即ち、どのデータ・ブロックが変化したかを判定するためには、データベースは、データベースの各ファイルにおける各ブロック・ヘッダを走査しなければならない。したがって、大きなデータベースでは、逐次バックアップの有効性は、どのデータ・ブロックが変化したかをデータベースが判定するために要する時間量によって、弱められてしまう場合がある。更に、データベースは、当該データベース自体が制御するデータ・ブロックに対する変更を判定できるに過ぎないことを認めなければならない。
【００１０】
本発明の一態様の目的は、論理的に関係付けられたデータ・セット内において、特定の時間期間における変更を識別する、改良された方法および装置を提供することである。本発明の別の態様の目的は、データベースから従来アクセス可能であった最少データ単位よりも小さな粒度で、データベースに格納されているデータ単位を識別することである。
【００１１】
（発明の概要）
本発明の一態様によれば、ホスト・コンピュータ上における論理オブジェクトに対する変更を、記憶装置内の物理的変化に基づいて識別することを可能にする、アプリケーション・プログラミング・インターフェース（ＡＰＩ）を提供する。このＡＰＩは、いずれのアプリケーション・プログラムによってコールすることもでき、論理オブジェクトのどの論理ブロックが基準時点以降に変更されたかを識別することができる。
【００１２】
本発明の一実施形態によれば、基準時点以降の論理オブジェクトに対する変更を判定する方法を提供する。論理オブジェクトは、ホスト・コンピュータ、記憶システム、および論理オブジェクトを記憶システム上の物理記憶ロケーションに互いに関係する物理レイヤにマップする少なくとも１つのマッピング・レイヤを含むコンピュータ・システムにおけるホスト・コンピュータのアプリケーション・レイヤに属する。物理レイヤは、基準時点以降における記憶システム上の物理記憶ロケーションに対して行われた変更に関係する物理変更情報を含む。この方法は、アプリケーション・レイヤから物理レイヤに論理オブジェクトをマップし、どの物理記憶ロケーションが論理オブジェクトに対応するデータを含むか識別するステップと、物理変更情報を用いて、マップするステップにおいて識別された、基準時点以降に変化したデータを含む物理記憶ロケーションのいずれをも識別するステップと、いずれかの物理記憶ロケーションが、物理変更情報を用いるステップにおいて基準時点以降に変化したデータを含むと識別された場合、変更が論理オブジェクトに対して行われたと判定するステップを含む。
【００１３】
本発明の別の実施形態によれば、ホスト・コンピュータのためにコンピュータ・プログラムをエンコードされたコンピュータ読み取り可能媒体を提供する。ホスト・コンピュータは、記憶システムに結合され、当該ホスト・コンピュータ上のアプリケーション・レイヤに属する論理オブジェクトを、記憶システム上の物理記憶ロケーションに互いに関係する物理レイヤにマップする少なくとも１つのマッピング・レイヤを含む。物理レイヤは、基準時点以降に記憶システム上の物理記憶位置に対して行われた変更に関する物理変更情報を含む。コンピュータ・プログラムは、ホスト・コンピュータ上で実行されたときに、基準時点以降の論理オブジェクトに対する変更を判定する方法を実行する。このコンピュータ・プログラムは、アプリケーション・レイヤから物理レイヤに論理オブジェクトをマップし、どの物理記憶ロケーションが論理オブジェクトに対応するデータを含むか識別するステップと、物理変更情報を用いて、マップするステップにおいて識別された、基準時点以降に変化したデータを含む物理記憶ロケーションのいずれをも識別するステップと、いずれかの物理記憶ロケーションが、物理変更情報を用いるステップにおいて基準時点以降に変化したデータを含むと識別された場合、変更が論理オブジェクトに対して行われたと判定するステップとを含む。
【００１４】
本発明の別の実施形態によれば、複数の物理記憶ロケーションを有する記憶システムと共に用いるホスト・コンピュータを提供する。ホスト・コンピュータは、当該ホスト・コンピュータ上のアプリケーション・レイヤに属する論理オブジェクトを、記憶システム上の複数の物理記憶ロケーションに互いに関係する物理レイヤにマップする少なくとも１つのマッピング・レイヤを含む。物理レイヤは、基準時点以降に記憶システム上の複数の物理記憶ロケーションに対して行われた変更に関する物理変更情報を含む。また、ホスト・コンピュータは、アプリケーション・レイヤから物理レイヤに論理オブジェクトをマップする少なくとも１つのマッピング・レイヤを用いて、複数の物理記憶ロケーションのどれが論理オブジェクトに対応するデータを含むか識別する第１識別手段と、第１識別手段によって識別された複数の物理記憶ロケーションに対応する物理変更情報を用いることにより、基準時点以降において論理オブジェクトに対して変更が行われたか否か識別する手段とを含む。
【００１５】
本発明の別の実施形態によれば、ホスト・コンピュータと共に用いる記憶システムを提供する。ホスト・コンピュータは、当該ホスト・コンピュータ上のアプリケーション・レイヤに属する論理オブジェクトを、少なくとも１つの記憶ボリュームを含む物理レイヤにマップする少なくとも１つのマッピング・レイヤを含む。記憶システムは、少なくとも１つの記憶ボリュームに含まれるデータを格納する少なくとも１つの記憶装置と、記憶システム上の少なくとも１つの記憶ボリュームに対応する変更情報を記憶するメモリとを含む。メモリに格納されている変更情報は、基準時点以降に、少なくとも１つの記憶ボリュームに対して変更が行われたか否か識別する。更に、記憶システムは、アプリケーション・レイヤから論理オブジェクトに対応するデータを含む少なくとも１つの記憶ボリュームへの論理オブジェクトのマッピングを、ホスト・コンピュータから受信する手段と、論理オブジェクトに対応するデータを含む少なくとも１つの記憶ボリュームに対応する変更情報を用いることによって、基準時点以降に論理オブジェクトに変更が行われたか否か判定する手段と含む。
【００１６】
本発明の別の態様によれば、データベースに属する論理データ・ユニットのロケーションを一意に識別する識別子を得る方法および装置を提供する。この方法および装置は、データベースの構造に関する情報に基づいて識別子を判定するので、アプリケーション空間において、ラベルを用いて、データベースから論理オブジェクトに最初にアクセスする必要がないという利点がある。
【００１７】
本発明のこの態様の一実施形態によれば、データベースに属する論理データ・ユニットのロケーションを一意に識別する第１識別子を得る方法を提供する。この方法は、識別子のグループを直接指定しない、データベースの構造に関する情報に基づいて、第１識別子を含む識別子のグループを判定するステップを含む。
【００１８】
別の実施形態によれば、データベースに属する論理データ・ユニットの第１識別子を得る方法を提供する。第１識別子は、データベース内部における論理データ・ユニットのロケーションを一意に識別し、論理データ・ユニットは、アプリケーション空間ラベルを有し、アプリケーション・プログラムはこれを用いて、データベースから論理データ・ユニットにアクセスすることができる。この方法は、アプリケーション空間ラベルを用いてデータベースから論理データ・ユニットに最初にアクセスすることなく、第１識別子を与えるようにデータベースに要求するステップを含む。
【００１９】
更に別の実施形態によれば、データベースを含むホスト・コンピュータ上における実行のためのコンピュータ・プログラムがエンコードされたコンピュータ読み取り可能媒体を提供する。このコンピュータ・プログラムは、ホスト・コンピュータ上で実行されたときに、データベース内における論理データ・ユニットのロケーションを一意に識別する、論理データ・ユニットの第１識別子を得る方法を実行する。この方法は、データベースの構造に関する情報に基づいて第１識別子を含む識別子のグループを判定するステップを含み、前述の情報は識別子のグループを直接指定しない。
【００２０】
更に別の実施形態によれば、データベースを含むホスト・コンピュータ上における実行のためのコンピュータ・プログラムがエンコードされたコンピュータ読み取り可能媒体を提供する。このコンピュータ・プログラムは、ホスト・コンピュータ上で実行されたときに、データベースに属し、データベース内の論理データ・ユニットのロケーションを一意に識別する、論理データ・ユニットの第１識別子を得る方法を実行する。論理データ・ユニットは、アプリケーション空間におけるラベルを有し、これによってデータベースから論理データ・ユニットにアクセスすることができる。この方法は、アプリケーション空間におけるラベルを用いてデータベースから論理データ・ユニットに最初にアクセスすることなく、第１識別子を与えるようにデータベースに要求するステップを含む。
【００２１】
本発明の別の実施形態によれば、コンピュータを提供する。このコンピュータは、プロセッサと、当該プロセッサに結合され、データベースがロードされているメモリとを含む。データベースは、当該データベースに属する論理データ・ユニットと、データベース内における論理データ・ユニットのロケーションを一意に識別する第１識別子とを有する。コンピュータは、識別子のグループを直接指定しない、データベースの構造に関する情報に基づいて、第１識別子を含む識別子のグループを判定する手段を含む。
【００２２】
本発明の更に別の実施形態によれば、プロセッサと、当該プロセッサに結合され、データベースがロードされているメモリとを含むコンピュータを提供する。データベースは、当該データベースに属する論理データ・ユニットと、データベース内における論理データ・ユニットのロケーションを一意に識別する第１識別子とを有し、論理データ・ユニットは、アプリケーション空間ラベルを有し、プロセッサ上で実行するアプリケーションはこれを用いて、データベースから論理データ・ユニットにアクセスすることができる。コンピュータは、アプリケーション空間ラベルを用いてデータベースから論理データ・ユニットに最初にアクセスすることなく、第１識別子を与えるようにデータベースに要求する手段を含む。
【００２３】
（発明の詳細な説明）
本発明の例示の一実施形態によれば、論理オブジェクトが格納されているデータ記憶システムにおいて、物理レベルに関係する情報を用いることによって、論理オブジェクトに対する変更を識別する方法および装置を提供する。ここで用いる場合、「論理オブジェクト」という用語は、総称的に、論理的に関係付けられている情報（例えば、データベース、ファイル等）のあらゆるセットを意味することとし、いずれの特定的な種類の論理的に関係付けられている情報にも限定することは想定していない。データベースに対してどんな変更が行われたかを判定するのにファイル毎に各ブロック・ヘッダを走査しなければならない、ＯＲＡＣＬＥデータベースについて先に説明したような従来技術に対して、本発明の態様は、物理レベルにおいて論理オブジェクトに対する変更を識別することによって、著しい性能上の向上をもたらす。加えて、以下で更に詳細に論ずるが、本発明の別の例示実施形態によれば、論理ブロック・レベルにおいて単純に行なうよりも一層有意に、論理オブジェクトに対する変更を識別することができる。例えば、このような変更は、より低い粒度に対して識別することができ、アプリケーション・プログラムに対して一層有用な情報を提供するので、変更の具体的な本質（追加、削除、修正）を特定することができる。この点について、変更された論理ブロックを識別することは、逐次バックアップの用途には有用であるが、本発明は、より詳細な情報が望まれるその他の多数のアプリケーションにも用いることができる。
【００２４】
本発明の別の例示実施形態によれば、データベースに属する論理データ・ユニットのロケーションを一意に識別する識別子を得る方法および装置を提供する。この方法は、従来のように、ラベルを用いて、最初にデータベースから論理オブジェクトにアクセスする必要がないという利点がある。逆に、この方法および装置は、データベースの構造に関する情報に基づいて識別子を決定することができる。
【００２５】
本発明の技術を採用可能な応用分野の１つは、逐次バックアップを行なうことである。本願と同じ譲受人に譲渡された、ＭＥＴＨＯＤ ＡＮＤ ＡＰＰＡＲＡＴＵＳ ＦＯＲ Ａ ＤＩＦＦＥＲＥＮＴＩＡＬ ＢＡＣＫＵＰ ＩＮ Ａ ＣＯＭＰＵＴＥＲ ＳＴＯＲＡＧＥ ＳＹＳＴＥＭ（コンピュータ記憶システムにおける差分バックアップのための方法および装置）と題する、１９９８年６月３０日出願の米国特許出願第０９／１０７，６７９号は、差分データ・ファシリティについて記載しており、データ記憶システムにおける物理レベルに関連する情報を用いることによって論理オブジェクトに対する変更を識別することに関する本発明が、逐次バックアップを行なうために採用されている。その内容は、この言及により本願にも含まれるものとする。本発明のこの態様について、以下に更に詳しく纏める。しかしながら、データ記憶システムにおける物理レベルの情報を用いることによって、どのデータが論理オブジェクトに対して変化したかを判定することに関する本発明の態様は、多数の他の用途にも採用可能であることから、本発明は、逐次バックアップの用途に用いることに限定されるのではないことは認めてしかるべきである。
【００２６】
前述のように、本発明の態様の一部は、論理オブジェクトを形成するデータが格納されているデータ記憶システムにおける物理レベルに関するデータに基づいて、論理オブジェクトに対する変更を識別することを対象とする。物理レベルにおけるデータ変更に関する情報は、多数の方法のいずれで与えることもでき、本発明はいずれの特定の技法にも限定されない。ＭＡのＨｏｐｋｉｎｔｏｎにあるＥＭＣ Ｃｏｒｐｏｒａｔｉｏｎ（イーエムシー社）から入手可能な記憶システムのＳＹＭＭＥＴＲＩＸラインのようなインテリジェント記憶システムの中には、物理レベルで編成され、特定の基準時点以降に変化したデータを含む記憶システムの部分を識別するビット・セットを含むものがある。ＳＹＭＭＥＴＲＩＸラインの記憶システムは、ＳＹＭＭＥＴＲＩＸ ｍｏｄｅｌ ５５ＸＸ製品取扱説明書、Ｐ−Ｎ２００−８１０−５５０，ｒｅｖ．Ｆ、（１９９６年２月）を含む、ＥＭＣ社からの多数の刊行物に記載されている。
【００２７】
ＳＹＭＭＥＴＲＩＸラインの記憶システム、およびその他のインテリジェント・ディスク・ドライブ記憶システムでは、データは、トラックと呼ばれる単位で多数のディスク・ドライブに格納される。典型的なトラック・サイズは３２Ｋバイトである。インテリジェント記憶システムは、典型的に、記憶システム内のデータ・トラックを構成する際に用いられる、コンフィギュレーション情報（メタデータと呼ぶこともある）を含む。ＳＹＭＭＥＴＲＩＸラインの記憶システムでは、このメタデータは、記憶システムのどのトラックが、特定の基準時点以降に変化したかに関する情報を含む。この情報は、多数の形態のいずれを取ることも可能である。一実施態様では、論理ボリューム毎にビットマップを用意する。以下で更に詳しく論ずるが、論理ボリュームは、ホスト・コンピュータ１１０（図１）が記憶システム１４０内における物理デバイス（例えば、ディスク・ドライブ）に対応すると認めるものに対応する。しかしながら、記憶システム１４０内部で追加のマッピングが行われると、ホスト・コンピュータ１１０が指定する論理ボリュームと、記憶システム１４０内の物理デバイスとの間の１対１の対応がなくなる。とは言え、本出願の目的上、各論理ボリュームの単位に与えられる変更情報は、データ記憶システム内の物理レベルに関係すると見なすこととする。何故なら、論理ボリューム・レベルは、ホスト・コンピュータ１１０にアクセス可能な最も低いレベルであり、ホストによって、物理空間に対応することが認められるからである。各論理ボリュームに対するビットマップは、ディスク・ドライブ内の各トラックに対応するビットを含み、このビットは、当該トラックが、基準時点以降に変化したデータを含むか否かを示す。各論理ボリュームに対するビットマップは、単一のデータ構造として一緒に格納される。したがって、各論理ボリュームに対するビットマップを試験することによって、記憶システム１４０上のトラックは、ビットマップを最後にリセットしたときの、特定の基準時点以降に変化したデータを含むか否かに関する判定を行なうことができる。本発明の例示の一実施形態によれば、このビットマップを試験して、論理オブジェクトに対して行われた変更を識別する。各論理ボリュームに対してトラック・レベルで維持される変更情報は、多数のコピーを含むことができ、これらは独立してリセットすることができるので、同時に異なるインスタンスの監視を採用することができる。
【００２８】
記憶装置１４０に格納されているデータは、典型的に、「物理ブロック」と呼ばれる記憶単位で編成されており、複数の物理ブロックが１つのトラックを形成し、各物理ブロックは、特定数のデータ・バイト（例えば、５１２バイト）を含む。逆に、ホスト・コンピュータ１１０上で実行するアプリケーションは、典型的に、論理オブジェクトを形成する、論理的に関係付けられているデータ・ブロック（「論理ブロック」）で構成された論理オブジェクト（例えば、ファイル）上で動作を行なう。典型的に、コンピュータ・システム１００は、１つ以上のマッピング・レイヤを含み、論理オブジェクトを形成する論理データ・ブロックを、論理オブジェクトを表すデータが物理的に格納されている記憶システム１４０内の１つ以上の物理データ・ブロックにマップする。論理データ・ブロックのサイズは直接記憶システム１４０内に格納されている物理ブロックに対応することもできるが、必ずしもそうでなくてもよい。例えば、１つの論理データ・ブロックは、２つ以上の物理データ・ブロックにすることができ、その逆も可能である。
【００２９】
図３に示すように、コンピュータ・システム１００（図１）は、アプリケーション空間３１０および物理空間３３０を含む、多数の階層空間即ちレイヤを有するものと見なすことができる。アプリケーション空間３１０および物理空間３３０間には、マッピング・レイヤ３２０がある。前述のように、コンピュータ・システム１００のホスト・コンピュータ１１０上で実行するアプリケーション・プログラム（例えば、ワード・プロセッシング・アプリケーション、デスクトップ・パブリッシング・アプリケーション、データベース・ソフトウエア等）は、アプリケーション空間３１０内の論理オブジェクト（例えば、ファイル）上で動作する。これらの論理オブジェクトを形成するデータは、記憶システム１４０に含まれ物理空間３３０を規定する１つ以上の記憶装置３４１〜３４３上に格納される。
【００３０】
図３に示す代表例では、記憶システム１４０は、ディスク・ドライブ３４１〜３４３を含むディスク記憶システムである。各ディスク・ドライブは、記録媒体の１つ以上のディスク（例えば、磁気または光記録媒体）を含むことができ、その上にデータを格納し、さらにそこに格納されているデータを読み出すことができる。先に論じたように、ディスク・ドライブ３４１〜３４３の各々に格納されているデータは、典型的に、「物理ブロック」に関して編成されており、各物理ブロックは多数のデータ・バイトを含む。
【００３１】
図３に示す例示のシステムでは、マッピング・レイヤ３２０は、全体的にコンピュータ・システム１００のホスト・コンピュータ１１０上に実装されている。しかしながら、前述のように、インテリジェント記憶システム１４０を採用する場合、追加のマッピング・レイヤを記憶システム１４０上で実行することができる。マッピング・レイヤ３２０は、アプリケーション空間３１０内に指定されている各論理オブジェクトを、当該論理オブジェクトを形成するデータが格納されている物理空間３３０内にある１箇所以上の一意のロケーション（例えば、物理ブロック）にマップする。マッピング・レイヤ３２０は、ファイル・システム３２２または論理ボリューム・マネージャ（ＬＶＭ）３２４のような単一のマッピング・レイヤを含むことができ、または図３に示すように、多数のマッピング・レイヤ３２２および３２４を含むことができる。アプリケーション・プログラムがファイルのような論理オブジェクトにアクセスする場合、そのファイル名のような論理オブジェクト識別子を用いてオブジェクトを識別する。マッピング・レイヤ３２０は、典型的に、物理空間３３０内の一意のロケーションを、アプリケーション空間３１０内で識別した論理オブジェクトの各々を形成する論理データ・ブロックに割り当てるデータ構造として編成される。
【００３２】
先に述べたように、マッピング・レイヤ３２０は、ファイル・システム３２２およびＬＶＭ３２４のような多数のマッピング・レイヤを含むことができる。ＬＶＭは、究極的に論理オブジェクト識別子を、論理オブジェクトに対応するデータを格納する物理ブロックに変換する際に用いられるマッピング・レイヤを表す。ＬＶＭは、典型的に、多数の記憶装置を有し、記憶データのボリュームを論理（物理ではなく）レベルで管理可能な、大型コンピュータ・システムにおいて用いられる。ＬＶＭ３２４の有無は、アプリケーション空間３１０には透過的である。同様に、ＬＶＭ３２４の有無は、ファイル・システム３２２にも透過的である。この点に関して、ファイル・システムは、単に、アプリケーション空間３１０から、ファイル・システムが物理空間３３０であると認めるものにマップするだけに過ぎない。記憶システム１４０上のＬＶＭまたはマッピング・レイヤのような別のマッピング・レイヤがマッピング・レイヤ３２０内に含まれている場合、これは、単に、ファイル・システム内で行われたマッピングの結果は物理レイヤに対する最終的なマッピングを示していないことを意味する。
【００３３】
前述のことから認められるように、典型的なコンピュータ・システムでは、記憶システム１４０は、物理空間３３０内に格納しているデータ・ブロック間の論理関係を理解していない。データの論理グループ化はアプリケーション空間３１０において行われ、記憶システム１４０には受け渡されないので、これは正しい。同様に、典型的なコンピュータ・システムでは、アプリケーション空間３１０内で実行するアプリケーション・プログラムは論理データ・ブロック（またはその中に含まれ、それよりも小さくてより有意のデータ単位）が物理空間３３０内に格納されている物理ブロックにどのように対応するかを理解していない。したがって、ある記憶システムは物理レベルにおける変更情報を提供するが、この情報は、典型的なコンピュータ・システムでは、論理オブジェクトに対する変更に関する何らかの有意の情報を与えるためには用いることができない。何故なら、典型的なコンピュータ・システムにおけるアプリケーション・プログラムには、物理レベル上での変更が論理レベルに関係する態様を理解する能力がないからである。
【００３４】
本発明の一実施形態によれば、アプリケーション・プログラムには、論理オブジェクトのホスト・コンピュータ１１０が物理空間３３０であると認めるものに対するマッピングの理解が備えられているので、記憶システム１４０によって与えられる変更情報を用いて、論理オブジェクトに対する変更を識別することができる。この理解は、多数の方法のいずれでも得ることができ、本発明はいずれの特定の技法にも限定されない。コンピュータ・システムにおいて物理レベルの論理オブジェクトに対するマッピングを行うシステムの一例が、本願と同じ譲受人に譲渡され、ＳＹＳＴＥＭ ＦＯＲ ＤＥＴＥＲＭＩＮＩＮＧ ＭＡＰＰＩＮＧ ＯＦ ＬＯＧＩＣＡＬ ＯＢＪＥＣＴＳ ＩＮ Ａ ＣＯＭＰＵＴＥＲ ＳＹＳＴＥＭ（コンピュータ・システムにおいて論理オブジェクトのマッピングを行うシステム）と題する、１９９８年６月３０日に出願された米国特許出願番号第０９／１０８，０３８号に記載されている。その内容は、この言及により本願にも含まれるものとする。このマッピング・システムは、アプリケーション・プログラミング・インターフェース（ＡＰＩ）を含み、アプリケーション空間（図３）内で動作するアプリケーション・プログラムに、アプリケーション空間３１０内の論理オブジェクトを物理空間３３０にマップする能力を備える。本発明の一実施形態では、このマッピングＡＰＩを用いて、論理オブジェクトと、対応するデータを格納している物理空間３３０内の物理ブロックとの間の関係を理解する。この理解を用いると、物理空間３３０内に記憶システム１４０によって与えられる変更情報を用いて、論理オブジェクトに対する変更情報を決定することができる。
【００３５】
図４は、本発明の一実施形態による変更ＡＰＩが用いて、特定の時点以降に変化した論理オブジェクトの論理ブロックを判定するステップのフローチャートである。変更ＡＰＩはアプリケーション・プログラミング・インターフェースに関して説明するが、変更ＡＰＩはアプリケーション空間（３１０、図３）内のアプリケーション・プログラムのみと通信する必要はないことは認められよう。この点に関して、変更ＡＰＩは、論理オブジェクトに対する変更を識別し、ＬＶＭのような、他のコンピュータ・プログラムに対して変更を伝達するために用いられる汎用コンピュータ・プログラムとしてという方が、より適切に見なすことができる。更に、当業者には公知であろうが、変更ＡＰＩは、ソフトウエア、ハードウエア、またはファームウエアのみ、あるいはソフトウエア、ハードウエアおよびファームウエアのあらゆる組み合わせでも実現可能であることは認められよう。
【００３６】
図４のステップ４１０に示すように、変更情報を求める論理オブジェクトに対するマッピングを最初に行い、それに対応するデータを格納している物理ブロックを識別する。このマッピングは、先に引用した関連出願に記載されているマッピングＡＰＩを用いることによって行なうことができる。これについては以下で更に詳しく論ずる。しかしながら、本発明は、このマッピングＡＰＩの使用にも、論理オブジェクトのマッピングを行うその他のいずれの特定の技法にも限定されないことは認められよう。アプリケーション空間３１０に、対象の論理オブジェクトに対応する物理ブロックの識別を備えるのであれば、いずれの技法でも採用可能である。
【００３７】
ステップ４２０において、ステップ４１０において識別された物理ブロックのどれが、対象の基準時点以降に変化したかについて特定を行なう。先に論じたように、この物理レベルにおける変更情報は、各論理ボリュームに対して記憶システム１４０によって与えられる前述のビットマップを用いて判定することができる。しかしながら、本発明はこの点に関して限定される訳ではなく、図４の変更ルーチンに、対象物理ブロックのどれが変化したかに関する情報を与える技法であればいずれでも採用可能であることは認められよう。
【００３８】
ステップ４３０において、ステップ４２０で識別された物理ブロックを論理空間に照合し、それに対応する論理ブロックを識別する。この場合も、本発明は、このマッピング機能を実行するいずれの特定の技法にも限定されず、図４の変更ルーチンに、ステップ４２０で識別された物理ブロックに対応する論理ブロックの識別を与えるいずれの技法でも採用可能である。
【００３９】
図４に示す本発明の実施形態は、論理オブジェクトに行われた変更を判定するために用いられる従来の技法に対して、多数の利点をもたらすことは認められよう。例えば、データベースに対して逐次バックアップを行なう場合、従来の技法では、データベースがそのブロックの各々を走査して、バックアップを行なった最後の時点以降に変化したブロックを判定する。大きなデータベースでは、これは過度に長い時間を要する可能性があり、そのため、この長い時間中データベースの処理能力が低下する。これは、データベースに対して行われる変更の量には関係なく言えることである。何故なら、論理オブジェクト内における変更を判定する従来の技法は、僅かな変更がなされただけであっても、論理オブジェクト全体（例えば、データベース全体）を走査しなければならないからである。
【００４０】
従来の技法とは対照的に、図４に示す本発明の実施形態は、ケタ違いに高速化している。先に論じたように、物理レベルにおいて維持されている変更情報は、例えば、各論理ボリュームのどのトラックが変更データを含むかを示すビットマップを含む。ＳＹＭＭＥＴＲＩＸラインのディスク・アレイでは、このビットマップをＳＹＭＭＥＴＲＩＸ記憶システム内部のキャッシュに格納し、この情報にアクセスする際の記憶システムの応答時間を向上させている。加えて、論理オブジェクトを格納する際に用いた各論理ボリューム内における変更を判定するには、単一のビットマップのみを読み取ればよいので、図４に示す変更ルーチンの処理能力は、変更情報を求める論理オブジェクトのサイズに直接依存しない。
【００４１】
論理オブジェクトに対する変更を判定する従来の技法に対する別の利点として、図４の変更ＡＰＩは、変更情報が要求された論理オブジェクトの所有権には独立して、いずれのコンピュータ・プログラムでもコールできることがあげられる。例えば、変更ＡＰＩは、逐次バックアップ・ユーティリティ、オンライン報告システム、またはその他のいずれの形式のアプリケーション・プログラムでも、論理オブジェクトが、変更ＡＰＩをコールしたアプリケーション・プログラムによって所有されているか否かには無関係に、コールすることができる。これは、変更情報を要求したプログラムによって所有されている論理オブジェクトについての変更のみを判定できるに過ぎない従来の技法とは対照的である。例えば、ＯＲＡＣＬＥデータベースは論理オブジェクトに対してなされた変更を検出することができるが、当該データベース自体のみが制御する論理オブジェクトについてのみそうすることができるに過ぎない。尚、データベースによって所有されている論理オブジェクトが、データベースの知識なくして、他のアプリケーション・プログラムによる変更が可能である場合、データベースは、何らかの変更が論理オブジェクトに対してなされたか否かを判定することはできないことは認められよう。
【００４２】
従来の技法に対する変更ＡＰＩの更に別の利点は、変更ＡＰＩを使用しても、異なるアプリケーション・プログラム間の調整が不要であることである。例えば、論理オブジェクトに対する変更を追跡するためにインデックスを与えるために、何らかのアプリケーション・プログラムを書き込むことがある。典型的に、このようなインデックスは、論理オブジェクト自体とは別個のデータ構造として維持される。このアプリケーション・プログラムによって所有されている論理オブジェクトを変更すると、その論理オブジェクトに対応するインデックスが更新され、論理オブジェクトが変更されたことを反映する。しかしながら、他のアプリケーション・プログラムも論理オブジェクトを修正することを許されている場合、論理オブジェクトを修正する能力を有する全てのアプリケーション・プログラムは、一致して当該論理オブジェクトに対応するインデックスを同様に更新しなければならない。さもなければ、いずれも（論理オブジェクトを所有するアプリケーションも含む）変更が行われたか否かについて信頼性高く識別することはできない。更に、このような調整が可能であっても、論理オブジェクトを修正可能な各アプリケーション・プログラムは、インデックスを更新するタスクも負担することになる。したがって、論理オブジェクトを修正する場合、その修正を行なうアプリケーション・プログラムは、修正毎に２回の書き込みを事実上行なうことになる。１回は修正した論理オブジェクトを書き込むため、そして２回目の書き込みは当該論理オブジェクトに対応するインデックスを更新するためである。このように、論理オブジェクトを直接修正することを許されている各アプリケーション・プログラムは、追加のオーバーヘッドを負担することになる。対照的に、図４の変更ＡＰＩによって可能な変更情報の監視は、論理レベルではなく、物理レベルにおける変更に基づいて論理オブジェクトに対する変更を識別するので、アプリケーション・プログラムに対して透過的である。即ち、論理オブジェクトに対する変更の監視は、アプリケーション・プログラムへの追加のオーバーヘッドを伴わない。
【００４３】
尚、前述のことから、本発明の一実施形態では、物理空間３３０におけるトラック・レベルにおける変更を識別する情報を用いて、論理ブロック・レベルにおける変更を識別することは認められよう。各トラックは数個の物理ブロックを含むことが認められよう。トラック毎に唯１つの変更ビットが備えられているので、このビットは、トラック内の物理ブロックの１つだけが変化した場合でも、トラックに対するデータが変化したことを示す。したがって、図４の変更ルーチンにおけるステップ４２０を実行する際、単一の変更物理ブロックを含むトラックにおいてでさえ、物理ブロックの全てを識別し、それに対応する論理ブロックの全てを、ステップ４３０において、潜在的に変更データを含むものとして識別する。このように、図４の変更ルーチンはいくらか控えめ（ｃｏｎｓｅｒｖａｔｉｖｅ）であり、実際には変更がなかったのに、いくつかの論理ブロックを、変更があったとして識別する場合もある。これは、単に、トラック・レベルのみにおいて物理的変更を識別する技法の個々の実施態様の特性であるに過ぎない。尚、本発明は、異なる方法で実現し、物理レベルにおける変更情報をより小さい刻み（例えば、物理ブロック・レベル）で与えることができるようにすれば、変更ルーチンが、実際に変更があった論理ブロックを、より高い粒度で識別できることも認められよう。
【００４４】
先に論じたように、本発明の一実施形態では、関連出願に記載されているマッピングＡＰＩを用いて、対象の論理オブジェクトと物理空間との間のマッピング（例えば、図４のステップ４１０）を行なう。このＡＰＩが動作する態様について、図７を参照しながら説明する。図７に示すマッピング・ルーチンの一例は、ホスト・コンピュータ１１０（図１）上で実行し、論理オブジェクト（アプリケーション空間３１０内）の、ホスト・コンピュータが物理空間３３０内にあると見なす１組のブロックに対するマッピングを行うことができる。例えば、マッピング・ルーチンは、メモリ１３０（図１）に格納され、ホスト・コンピュータ１１０のプロセッサ１２０上で実行されるソフトウエアで実現することができる。
【００４５】
図７のマッピング・ルーチンは、２つの部分を有すると見なすことができる。即ち、ホスト・コンピュータ上にどれだけマッピング・レイヤがあるか判定する第１部、およびアプリケーション空間３１０からの指定された論理オブジェクトの、ホスト・コンピュータが物理空間であると認めたものに対するグローバル・マッピングを行う第２部である。これら情報ピースの各々は、マッピング・ルーチンをコールする毎に、動的に判定することができる。しかしながら、ホスト・コンピュータ上に存在するマッピング・レイヤ数は頻繁に変化しないので、本発明の一実施形態では、この情報を１回判定し、ホスト・コンピュータ上のマッピング・レイヤ３２０に対して変更が行われた場合にだけ必要に応じて更新する。このため、ホスト・コンピュータ上にどれだけマッピング・レイヤがあるかについての判定は、マッピング・ルーチンをコールする毎に行なう必要はない。一旦この情報を取得すれば、ホスト・コンピュータ１１０または記憶システム１４０にセーブしておけばよい。本発明の一実施形態では、この情報をホスト・コンピュータ上のメモリ１３０に格納し、この情報をアクセスする際に伴う遅延を極力抑えるようにしている。
【００４６】
例えば、ホスト・コンピュータ上にあるマッピング・レイヤの数は、最初に、初期プログラム・ロード（ＩＰＬ）、またはホスト・コンピュータ・システムのブート中に行なうことができる。システム起動時にロードされる各ファイル・システムおよび／またはＬＶＭを記録するコマンド・ユーティリティをホスト・コンピュータ上で実行することができる。このようなコマンド・ユーティリティは、背景タスクとして、周期的に実行し、別のファイル・システムまたはＬＶＭが後にマウント（実装）された場合に、マッピング・レイヤ３２０のレコードを更新することも可能である。あるいは、ホスト・コンピュータ上にマッピング・ルーチンがロードされたとき、およびファイル・システム、ＬＶＭまたはマッピング・レイヤ３２０のその他のコンポーネントがホスト・コンピュータに追加されたり、ホスト・コンピュータから除去される毎に、コンピュータ・ユーザ（例えば、システム・マネージャ）にどのマッピング・レイヤが存在するか指定させるコマンド・ユーティリティを実行することも可能である。
【００４７】
マッピング・ルーチンの第２部は、マッピング・ルーチンをコールする毎に実行することができる。端的に言うと、指定した論理オブジェクトのグローバル・マッピングは、マッピングのどのレイヤが、アプリケーション空間３１０（図３）内で指定された論理オブジェクトを所有するのかについての判定、指定された論理オブジェクトと連携するホスト・コンピュータ上にあるマッピング・レイヤ数の識別、および各マッピング・レイヤを通じて、指定された論理オブジェクトの、ホスト・コンピュータ１１０が物理空間であると認めたものにおける１組のブロックに対するマッピングの繰り返しを含む。マッピング・レイヤ３２０が、ファイル・システム３２２またはＬＶＭ３２４のような、単一のマッピング・レイヤのみを含む場合、アプリケーション空間において指定された論理オブジェクトは、物理空間内の１組の物理空間に直接マップされる。しかしながら、マッピング・レイヤが多数のマッピング・レイヤを含む場合、各マッピング・レイヤの出力を次のマッピング・レイヤに対する入力識別子として繰り返し用いる。それ以外のマッピング・レイヤがないと判定された場合、マッピング・ルーチンは、最下位のマッピング・レイヤにおいて識別した１組の物理ブロックを、マッピング・ルーチンをコールしたアプリケーションに戻す。
【００４８】
マッピング・ルーチンは、ホスト・コンピュータによって、「ｍａｐｐｉｎｇ ｆｉｌｅ Ａ」というようなコールを発行することによって、コールすることができる。ここで、識別子ｆｉｌｅ Ａはアプリケーション空間３１０において論理オブジェクトｆｉｌｅ Ａを一意に識別する。ステップ７１０において、マッピング・ルーチンは、アプリケーション空間における論理オブジェクトの所有権を判定する。尚、コンピュータ・システムによっては、ホスト・コンピュータ１１０上に多数のファイル・システムを実装している場合もあることは認められよう。例えば、ＵＮＩＸ（登録商標）オペレーティング・システムの下で動作するコンピュータ・システム上では、ＵＮＩＸ（登録商標）ファイル・システム（ＵＦＳ）、ＶＥＲＩＴＡＳ（ＶｘＦＳ）ファイル・システム、そして恐らくその他のファイル・システムに遭遇するのは特別なことではない。しかしながら、コンピュータ・システム上のファイルのような各論理オブジェクトは、通常、これらのファイル・システムの内１つだけによって所有されている。論理オブジェクトの所有権は、論理オブジェクトの形式に応じて、多数の方法のいずれでも判定することができる。例えば、論理オブジェクトがホスト・コンピュータ上に常駐するファイル・システム３２２である場合、マッピング・ルーチンは、ホスト・コンピュータのオペレーティング・システムに、ファイルがどこに位置するか特定するように要求することができる。例えば、論理ファイルが、ＵＮＩＸ（登録商標）オペレーティング・システムを有するコンピュータ・システム上のファイルである場合、マッピング・ルーチンはコマンドｄｆ ｆｉｌｅ Ａを発行し、オペレーティング・システムに、論理オブジェクトｆｉｌｅ Ａを所有するファイル・システムはどれか、マッピング・ルーチンに伝えるように要求することができる。他のオペレーティング・システムは、典型的に、同様の形式のコマンドを有する。
【００４９】
ステップ７１０において論理オブジェクトの所有権を判定した後、マッピング・ルーチンはステップ７２０に進み、ルーチンは、指定された論理オブジェクトと連携するマッピング・レイヤの数を識別する。論理オブジェクトが、ＵＮＩＸオペレーティング・システムを有するホスト・コンピュータ上に常駐するファイル・システム内のファイルであるという前述の例では、ｄｆコマンドは、どのファイル・システムが指定の論理オブジェクトを所有するのかについて識別するだけでなく、更にどの論理デバイス上にファイル・システムが実装されているかについても識別する。ファイル・システムの下にどのようなマッピング・レイヤが存在するかに応じて、ファイル・システムに対して識別された論理デバイスは、物理空間３３０内のロケーションに直接対応する論理ボリュームであったり、またはＬＶＭ３２４のような更に別のマッピング・レイヤによってマップされる場合もある。しかしながら、ファイル・システムが実装されている論理デバイスが一旦識別されたなら、マッピング・ルーチンは、次に、ホスト・コンピュータ・システム上に存在することがわかっているいずれかのＬＶＭに問い合わせを行い、このＬＶＭが、識別された論理デバイスを下位レイヤにマップするか否か判定を行なう。殆どのＬＶＭは、ユーザに、ＬＶＭに問い合わせを行い、指定された論理デバイスがＬＶＭにはわかっているか否か判定させる。デバイスがＬＶＭにわかっている場合、ＬＶＭは、論理デバイスがＬＶＭによってマップされた先の論理ボリューム・アドレスを回答する。あるいは、ＬＶＭにはデバイスがわかっていない場合、ＬＶＭは、回答する際、典型的に、その旨示し、ＬＶＭはファイル・システムに対していずれのレベルのマッピングも行なわないことを示す。ＬＶＭの下に別のマッピング・レイヤがない場合、この論理ボリューム・アドレスは物理空間内のロケーションに対応する。
【００５０】
ステップ７２０において、論理オブジェクトと連携するマッピング・レイヤの数を識別した後、マッピング・ルーチンはステップ７３０に進み、ここでマッピング・ルーチンは、指定された論理オブジェクトと連携する最初のマッピング・レイヤに対して、マッピング・レイヤ３２０において次に低いレイヤに対するオブジェクトのマッピングを行う。マッピング・レイヤ毎に、例えば、当該マッピング・レイヤに渡された論理オブジェクト（例えば、ファイル）に対するメタデータを格納しているマッピング・レイヤ（例えば、ファイル・システム３２２またはＬＶＭ３２４）のデータ構造の部分にアクセスすることによって、これを行なうことができる。特定のファイルに対するメタデータがファイル・システムまたはＬＶＭのデータ構造内に格納されているか否か判定を行なう方法は多数ある。例えば、メタデータの構造およびロケーションは、マッピング・レイヤ（例えば、ファイル・システム３２２またはＬＶＭ３２４）のベンダから直接得ることができる。一旦マッピング・レイヤ（例えば、ファイル・システムまたはＬＶＭ）に対するメタデータの構造およびロケーションがわかったなら、マッピング・ルーチンはこの構造を直接用いて、次のマッピング・レイヤへのウインドウをこれに与える情報にアクセスする。
【００５１】
最初のマッピング・レイヤにおいて指定された論理オブジェクトのマッピングを行った後、ルーチンはステップ７４０に進み、ここで、直前のマッピング・レイヤによって与えられたロケーションが更に別のマッピング・レイヤに従うか否かについて判定を行なう。従う場合、マッピング・ルーチンはステップ７３０に戻り、マッピング・ルーチンは、処理するマッピング・レイヤに対して、前述のように、マッピング・レイヤ３２０内の次の下位レイヤに対するオブジェクトのマッピングを行う。このように、ルーチンは、ステップ７４０において、指定された論理オブジェクトに対する最下位のマッピング・レイヤを処理し終えたと判定されるまで、マッピング・レイヤの各々に進み、処理し終えたときに、ルーチンはステップ７５０に進む。ステップ７５０において、ルーチンは、ホスト・コンピュータが物理空間３３０であると認めたものにおいて、マッピング・ルーチンがコールされたときにマッピングが要求された論理オブジェクトを構成するデータのブロックのロケーションを戻す。また、ルーチンは、論理オブジェクトのサイズ（例えば、バイト単位）を戻してもよい。ステップ７５０においてこの情報を戻した後、ルーチンは終了する。
【００５２】
以上、ファイルに対して動作するものとして、マッピング・ルーチンの動作について論じたが、ホスト・コンピュータは、別の形式の論理オブジェクトを含む場合もあり、マッピング・ルーチンはその場合でも同様に動作可能であることは認められよう。例えば、１つ以上のファイル・システムおよび／またはＬＶＭに加えて、コンピュータ・システム上にデータベースを実装することも可能である。データベースは、当該データベースのオブジェクトの各々が、特定のファイル・システムによって所有されるファイルとなるような構造とすることができ、または各オブジェクトが論理デバイスであってもよい。例えば、ＵＮＩＸオペレーティング・システムの下で動作するコンピュータ・システム上では、データベースは、／ｄｅｖ／ｄｅｖ１、／ｄｅｖ／ｄｅｖ２、および／ｄｅｖ／ｄｅｖ３のような３つのオブジェクトを有する場合もあり、その各々が論理デバイスである。これらの論理デバイスは、データベースによって、物理空間内の一意のロケーションにマップすることができ、あるいはＬＶＭのような他のマッピング・レイヤによってマップすることもできる。代わりに、データベースは、／ｕｓｒ／ｕｓｅｒｓ／ｄｂａｓｅ／ｄｂｆｉｌｅ１、／ｕｓｒ／ｕｓｅｒｓ／ｄｂａｓｅ／ｄｂｆｉｌｅ２、および／ｕｓｒ／ｕｓｅｒｓ／ｄｂａｓｅ／ｄｂｆｉｌｅｓ３というような３つのオブジェクトを有する場合もあり、ｄｂｆｉｌｅ１、ｄｂｆｉｌｅ２、およびｄｂｆｉｌｅ３は、ファイル・システムによって所有される通常のファイルである。この後者の場合、データベースおよびファイル・システムによって行われるマッピングに加えて、これらのファイルは、ＬＶＭのような、更に別のマッピング・レイヤによってマップすることも可能である。
【００５３】
尚、殆どのデータベースに対する構造は、データベースをコンピュータ・システム上に実装するときに、識別できることは認められよう。更に、より広く用いられるデータベースは、一般に、それによって所有されるいずれのオブジェクトでも次のマッピング・レイヤにマップするために動的にアクセスすることができる構造を有する。したがって、コンピュータ・システム上にどれだけ異なるマッピング・レイヤが存在するか、そしてどのマッピング・レイヤが特定の論理オブジェクトのマッピングに関与するかについて一旦判定したなら、論理オブジェクトの、ホスト・コンピュータが物理空間３３０にあると認めるロケーションに対するマッピングを行なえば、当該論理オブジェクトが、データベース、ファイル・システム、またはその他の何らかのオブジェクト管理階層のどれによって所有されているのかについて容易に判定することができる。
【００５４】
尚、各論理オブジェクトのマッピングは、コールしたときに、マッピング・ルーチンによって動的に行うことが好ましいが、１つ以上の論理オブジェクトのマッピングは、前もって決定しておき、クイック参照テーブルに保持しておくことも可能であることは認められよう。参照テーブルは、背景タスクとして作成し維持すれば、ホストの効率を更に高めることができる。このような参照テーブルは、論理オブジェクトに頻繁にアクセスし、経時的に比較的安定である場合に有利であると考えられる。
【００５５】
先に論じたように、数個の記憶システム１４０（図３）は、記憶装置の集合体を超えるものであり、インテリジェンスを有する。このような記憶システムは、ホスト・コンピュータによって与えられるマッピング・レイヤ３２０から物理空間３３０への、１つ以上の追加のマッピング・レイヤを実行することができる。このマッピングは、ホスト・コンピュータ・システムとは独立して行われ、したがってホストに対して透過的である。このため、ホストが、そのマッピング・レイヤ３２０によって与えられた所与の論理オブジェクトに対するブロックのロケーションが、記憶システム１４０内部のデータのロケーションに対応すると認めても、それが事実でないこともある。このため、ホスト・マッピング・レイヤ３２０はそれが物理空間３３０内の物理アドレスを指定していると確信していても、追加のマッピングを用いるインテリジェント記憶システムは、固有の物理アドレスであると判定した論理アドレスを受け取ると見なすことができる。インテリジェント記憶システム上で行われるマッピングはオプションとすることもできるので、システムは、それが受け取ったアドレスが物理空間３３０内の実際の物理アドレスを規定するように、構成することも可能である。
【００５６】
図８は、ホスト・コンピュータ上のマッピング・レイヤ３２０と物理空間３３０との間で追加のマッピングを行なうことができるインテリジェント記憶装置８４０を含むコンピュータ・システム８００のブロック図である。記憶装置８４０は、複数のディスク・ドライブ８４１〜８４３を含み、各ディスク・ドライブは数個のディスクを含む。このような大容量記憶システムの一例は、ＥＭＣ社から入手可能なＳＹＭＭＥＴＲＩＸラインのディスク・アレイである。
【００５７】
インテリジェント記憶システム８４０は、キャッシュ（図示せず）を内蔵し、ホスト・コンピュータには透過的に、システム性能を向上させることができる。典型的に、読み取り動作は、記憶システムに、要求されたデータがキャッシュ内にあるか否か判定を行なわせ、ある場合、データはキャッシュからホスト・コンピュータに転送される。要求されたデータがキャッシュ内にない場合、記憶システム８４０は、ディスク８４１〜８４３のどれにデータが格納されているか判定し、データを当該ディスクからキャッシュに転送する。次いで、要求されキャッシュ内にあるデータはホスト・コンピュータに転送される。書き込み動作では、データは、典型的に、キャッシュに書き込まれ、データがキャッシュに格納されていることが検証されると直ちに、ホスト・コンピュータには書き込みが完了したと報告される。次いで、記憶装置は、ディスク・ドライブ８４１〜８４３の内適切な１つに非同期でデータをデステージ（ｄｅｓｔａｇｅ）する。
【００５８】
先に論じた本発明の実施形態の全ては、前述と同様に、インテリジェント記憶システム８４０と共に用い得ることは認められよう。この点について、記憶システム８４０が追加のマッピング・レイヤを実行しても、このマッピングはホスト・コンピュータに対して透過的であり、ホストおよび記憶装置８４０間でインターフェースを行なう前述の技法に何ら影響も与えない。例えば、物理レベルにおけるデータ変更を反映するビットマップを論理ボリュームのトラックに与えれば、物理レイヤでどのような変更が行われたかを判定するために、マッピング・ルーチンは、記憶システム１４０内で行われるマッピングを評価する必要はない。
【００５９】
尚、図７のマッピング・ルーチンは、多数のフォーマットのいずれででも、マップされた論理オブジェクトに対応する物理データ・ブロックを戻すことができ（ステップ７５０）、本発明はいずれの特定のフォーマットにも限定されないことは認められよう。本発明の一実施形態によれば、図７のマッピング・ルーチンは、マップされた論理オブジェクトに対応する物理ブロックに関係する情報を、特定のフォーマットで戻す。特に、各論理オブジェクトは多数の論理ブロックで構成することができ、その各々は特定の論理ブロック・サイズを有することは認められよう。論理オブジェクトを構成する論理ブロックは、論理空間において隣接していてもよく、あるいは不連続な論理ブロック・アドレスで論理ブロックを含むこともできる。本発明の例示の一実施形態では、図７のマッピング・ルーチンは、論理オブジェクトがマップする物理ブロックに関する情報を、論理オブジェクトを形成する論理ブロックの順序に対応する順序で戻す。このように、論理オブジェクトに対する論理および物理ブロック間の対応が維持され、以下に述べるように用いることができ有利である。
【００６０】
本発明の更に別の例示の実施形態によれば、図７のマッピング・ルーチンによって戻される論理オブジェクトのフォーマットは、論理オブジェクトの論理ブロックとの対応を維持する順序で、論理オブジェクトを格納する隣接物理ブロックのセグメントを識別する。各セグメントは、記憶システム１４０内の物理記憶空間へのオフセット、および隣接する物理ブロックの数を示す範囲（例えば、５１２Ｋバイト）によって識別される。この点に関して、記憶システム１４０内部の物理ブロックは、開始アドレスから終了アドレスまでにわたる隣接物理ブロックの集合体として見なせることは認められよう。これによって、図７のマッピング・ルーチンの一実施態様によって与えられるオフセットおよび範囲は、論理オブジェクトに含まれるデータを格納する物理ブロックの各隣接セグメントを別個に識別する。加えて、前述のように、これらの隣接物理セグメントは、論理オブジェクトを形成する対応の論理ブロックに対応するために指定される。このように、図７のマッピング・ルーチンは、論理オブジェクトの物理レベルに対するマッピングを、論理オブジェクト全体のためだけではなく、その中に含まれる各論理ブロックのためにも維持する。
【００６１】
尚、論理オブジェクトは、当該論理オブジェクトを規定する用途に便利ないずれのサイズを有する論理ブロックに関しても定義できることは認められよう。同様に、物理ブロック・サイズは、記憶システム１４０に適切ないずれのサイズとすることも可能である。したがって、先に論じた図７のマッピング・ルーチンの例示の実施態様によって戻される物理ブロックは、論理オブジェクトに対する論理ブロックと１対１で対応する必要はない。しかしながら、物理ブロックによって表される論理ブロックの境界は、各論理ブロックに含まれるバイト（またはビット）数、および各物理ブロックに含まれるバイト（またはビット）数に基づいて、簡単な数学的計算で容易に決定することができる。このように、マッピング・ルーチンによって戻される物理ブロックの隣接するセグメントの順序の維持は、論理ブロックおよび物理ブロック間の対応の判定を可能にするために必要とされる全てである。
【００６２】
図７のルーチンを用いて、マップされた論理オブジェクトに対する論理ブロックと、これによって戻される物理ブロック間の対応付けを行なう方法を、図５（ａ）に概念的に示す。図５（ａ）は、１００個の論理ブロック５０１を含む論理オブジェクト５００を示す。図示の例では、論理ブロックは、記憶システム１４０（図１）の物理ブロック・サイズの２倍のブロック・サイズを有する。したがって、論理オブジェクト５００は、記憶システム１４０内にある２００個の物理ブロックに格納される。更に図５（ａ）に示すように、２００個の物理ブロックは、隣接する物理ブロックの２つのセグメント間で分割され、５０個の物理ブロックを含む第１セグメント５０３、および１５０個の物理ブロックを含む第２物理セグメント５０５となる。先に論じたように、図７のマッピング・ルーチンを論理オブジェクト５００に対して実行すると、マッピング・ルーチンは、２つの隣接物理セグメント５０３および５０５を別個に識別することによって、論理オブジェクトを格納している２００個の物理ブロックを識別する。物理セグメント５０３は、オフセット５０３ａおよび範囲５０３ｂによって識別される。同様に、物理セグメント５０５は、オフセット５０５ａおよび範囲５０５ｂによって定義される。前述のように、物理セグメント５０３および５０５はマッピング・ルーチンによって順番に戻されるので、論理オブジェクト５００に対する論理ブロック５０１と、セグメント５０３および５０５内の物理ブロックとの間の対応は維持される。
【００６３】
物理レベルにおける変更情報をどのようにして論理レベルにマップできるか（例えば、図４におけるステップ４３０）という代表例を、図５（ｂ）を参照しながら説明する。この実施態様例では、ホスト・コンピュータ上に変更ＡＰＩを備え、図４の変更ルーチンを実行する。この変更ＡＰＩは、ビットマップに関して、アプリケーション空間３１０（図３）において変化した論理ブロックを識別する。論理オブジェクト内のどの論理ブロックが変化したかに関する情報を求めているアプリケーション・プログラムは、変更ＡＰＩによって戻されたビットマプの内どのビットが変化したかを読み取るだけでよい。勿論、他の実施態様を代わりに備えてもよく、本発明はここに記載する特定の実施態様に限定される訳ではないことは認められよう。
【００６４】
本発明の例示の一実施形態では、論理ビットマップを備え、図７のマッピング・ルーチンによって戻される、前述のフォーマット（物理ブロックの隣接セクション毎にオフセットおよび範囲を含む）と共に動作する。この実施形態では、変更ＡＰＩには、図７のマッピング・ルーチンから戻される隣接物理セグメントを識別する情報が受け渡される。この点に関して、変更ＡＰＩは、隣接する物理セグメントの各々に対して１回コールすることができ、物理オフセット、所望のブロック・サイズ、および変更情報を求める範囲を受け渡すことができる。これに応答して、変更ＡＰＩは、記憶システム１４０によって与えられた物理変更情報を用いて、変更ＡＰＩがコールされたときに指定された物理ブロックの各々にビットが対応する、ビットマップを戻す。前述のように、図７のマッピング・ルーチンが物理セグメントを順に配列する方法のために、オブジェクトに対する物理ブロックと論理ブロックとの間の対応は維持される。したがって、この情報を用いると、変更ＡＰＩによって与えられるビットマップを用いて、論理オブジェクトのどの部分が、対象の特定基準時点以降に変化したかについて判定することができる。
【００６５】
図５（ｂ）は、本発明の例示の一実施形態による変更ルーチンが用いるビットマップの特性を示す。前述のように、変更ＡＰＩは、コールされたときに物理セグメント５０３または５０５の一方を受け渡すことができ、変更ビットと共に、コールにおいて指定された物理ブロックの各々に対応するビットマップを戻すことができる。これを図５（ｂ）に示す。即ち、隣接物理ブロック５０７はセグメント５０３における５０個のブロックを表す。ビットマップ５０９は、変更ＡＰＩによって戻すことができ、ビット５１１は物理ブロック５０７の各々に対応し、対応する物理ブロックが変更データを含むか否かを示す。物理ブロック５０７および論理ブロック５０１の対応はわかっているので（図５（ａ）参照）、ビットマップ５０９を用いて、論理オブジェクト５００の論理ブロック５０１の内どれが変更データを含むか判定することができる。
【００６６】
尚、変更ＡＰＩをコールして特定の隣接物理セグメントに対する変更情報を戻す場合、図７のマッピング・ルーチンによって戻される場合と同様に正確に物理セグメントを識別して、コールを行なう必要はないことは認められよう。即ち、変更ＡＰＩは、同じ物理オフセットを用いてコールすることが好ましいが、ブロック・サイズおよび範囲はいずれの所望値に変更することも可能である。尚、変更ＡＰＩをコールするときに要求したブロック・サイズは、図５（ｂ）に示すビットマップによって戻される情報の粒度を決定し、ブロック・サイズが小さい程粒度が大きくなることは認められよう。加えて、指定された範囲は、選択されたブロック・サイズによって異なる。
【００６７】
また、論理オブジェクトに対して変更データを検出することに関する本発明の態様を容易にするために、アプリケーション・プログラムが、論理オブジェクトに対応する物理変更ビットをリセットする能力を備えることが望ましいことは認められよう。
【００６８】
図６は、基準時点以降の論理オブジェクトに対する変更を監視するために用いられる、物理レベルのビットを変更ＡＰＩがリセットする際に用いることができるステップのフローチャートである。変更ＡＰＩは、ソフトウエアで実現することができ、ホスト・コンピュータ１１０のプロセッサ１２０上で実行し、記憶システム１４０（図１）と通信する。図６に示すように、変更ＡＰＩは、基準時点以降の変更に関して監視される論理オブジェクトの１つ以上のブロックにマークを付けることができる。ステップ６２０において、変更ＡＰＩは、指定された論理オブジェクトの論理ブロックの、論理オブジェクトが格納されている記憶装置内の１組の物理ブロックに対するマッピングを行なう。先に論じたように、これは、図７のマッピング・ルーチンを用いて行なうことができる。ステップ６３０において、ＡＰＩは、ステップ６３０においてＡＰＩが識別した論理ブロックに対応する、記憶システムのメタデータ内の物理ビットマップ５０９におけるビット５１１をリセットする。これによって、基準時点を確立し、それ以降は、マークを付けた論理ブロックに対するいずれの変更でも識別可能となる。
【００６９】
前述のように、本発明の実施形態は、アプリケーション空間３１０（図１）における論理オブジェクト上で動作するいずれのアプリケーション・プログラムでも、論理レベルにおいて、基準時点以降に生じたこれら論理オブジェクトに対する変更を識別することを可能にする。この技術の一使用例は、先に記したように、逐次バックアップである。しかしながら、この能力を用いれば、他にも無数の有用なアプリケーションが実現できることは認められよう。
【００７０】
例えば、アプリケーション・ソフトウエアを書くアプリケーション・プログラマは、コードの品質を検査する際、コードが実際に意図した通りに動くことを検証する。これを行なうには、典型的に、アプリケーション・ソフトウエアによって行われると予測された論理オブジェクトに対するあらゆるそして全ての変更が、実際に予測したように行われたことを確認する。しかしながら、当業者には公知のように、欠陥のあるアプリケーション・プログラムでは、そのアプリケーション・プログラムによって影響を受けるとは思いもよらなかった他の論理オブジェクトを思い掛けなく修正してしまうということもあり得る。本出願人の発明の技術を用いることによって、アプリケーション・プログラマは、アプリケーション・プログラムが、修正されるはずの情報のみを変更し、それ以上でもそれ以下でもないことを検証することができる。
【００７１】
図９は、アプリケーション・プログラムが、当該アプリケーション・プログラムによって修正されたはずの論理オブジェクトのみを変更したか否か確認するために実行することができるステップを示す。ステップ９１０において、変更ＡＰＩをコールし、監視のために、コンピュータ・システム上の論理オブジェクト全てにマークを付け、後にいずれの変更でも識別できるようにする。図６に関して説明したように、これは、記憶システムのメタデータの物理ビットマップ内の各ビットをリセットすることによって行なうことができる。
【００７２】
ステップ９２０において、コンピュータ・システム上でアプリケーション・プログラムを実行し、その意図した機能を遂行する。実行後、ステップ９３０において、変更ＡＰＩをコールし、コンピュータ・システム上で変化したあらゆる論理ブロックを識別する。図４に関して注記したように、変更ＡＰＩはビットマップ５０９を戻すことができる。そのビットは、コンピュータ・システム上の各論理ブロックに対応し、アプリケーション空間内の論理ブロックがアプリケーション・プログラムの実行によって変更されたか否かを表す。アプリケーション・プログラムによって変更された論理ブロックを、変更されることを予測していた論理ブロックと比較することによって、プログラマに、アプリケーション・プログラムにおける潜在的なエラーを警告する。前述のステップは、データベースのような他のアプリケーションによって所有される論理オブジェクトを修正するアプリケーション・プログラムを含む、あらゆるアプリケーション・プログラムの品質を検証するためにも使用可能であることは認められよう。例えば、以下で詳しく説明する図１２ないし図１４のルーチンと共に用いる場合、アプリケーション・プログラマは、彼／彼女のアプリケーション・プログラムが、当該アプリケーション・プログラムによって修正されることが予測されたデータベース・オブジェクトの行またはレコードのみを変更することを検証することができる。
【００７３】
本出願人の発明の技術の別の使用として、コンピュータ・システムの監査を実行することがあげられる。例えば、コンピュータ・システムは、正規ユーザによる以外は、修正させない１つ以上の論理オブジェクト（例えば、個人ファイル）を有する場合がある。典型的に、このような論理オブジェクトは、アプリケーション空間におけるあるレベル（例えば、オペレーティング・システムまたはファイル・システム・レベル）で保護されているので、論理オブジェクトは、正規の要員による以外、修正や削除されるはずはない。しかしながら、広く利用可能なコンピュータ・システムの場合、そのいずれにおいても、無許可の人がオペレーティング・システムまたはファイル・システム・レベルにおいて保護を突破し、論理オブジェクトを修正してしまう可能性があるという懸念が存在する。本出願に記載された技術を用いることによって、論理オブジェクトに対する不正な変更を検出することができる。
【００７４】
例えば、正規の要員が何らかの変更を、保護されている論理オブジェクトに対して行なった後、変更ＡＰＩをコールして、保護されている論理オブジェクトにマークを付け、論理オブジェクトに対するそれ以降のあらゆる変更を特定できるようにする。論理オブジェクトにマークを付けた後、変更ＡＰＩを周期的にコールして、保護されている論理オブジェクトにおけるいずれかの情報が変化したか否か確認することができる。例えば、周期的な間隔で変更ＡＰＩをコールするユーティリティ・アプリケーションを書いてもよい。このユーティリティ・アプリケーションは、保護されている論理オブジェクトに対して変更が検出された場合に、正規の要員に通知するように書くとよい。あるいは、またはこのようなユーティリティ・アプリケーションに加えて、正規の要員が差動データＡＰＩをコールし、別の変更を行なう前に、保護されている論理オブジェクトに対して不正の変更がなされていないことを確認することも可能である。
【００７５】
本出願人の発明の技術の別の使用として、一次コンピュータシステムから１つ以上のリモート・コンピュータ・システムに対して変更を複製することがあげられる。例えば、多くの組織が中央コンピュータを有し、そこにはデータベースが実装されており、多数の別のリモート・コンピュータ・システムがそのデータベースのコピーを有する。中央コンピュータ・システム上のデータベースに変更を加えると、これらの変更は一般的にリモート・コンピュータ・システム上のデータベースのコピーにも伝える必要がある。あらゆる変更情報を識別し、変更情報のみ（データベース全体ではなく）をリモート・コンピュータ・システムに伝えることによって、リモート・コンピュータ・システム上のデータベースを素早く更新することができるので便利である。
【００７６】
本出願人の発明の更に別の実施形態によれば、論理オブジェクトを再編成する方法が提供される。コンピュータ・システム上の論理オブジェクトは、典型的に、論理オブジェクトを形成するデータに対して行われる変更のために、時と共に変化する。例えば、新たなデータ・ブロックを追加する場合もあり、古いデータ・ブロックを削除または変更する場合もある。時間と共に、論理オブジェクトを形成する物理データ・ブロックは、記憶システム内の別々の非隣接物理ブロックに散在してしまう可能性がある。論理オブジェクトを形成するデータをメモリに読み込んだり、あるいはメモリから記憶装置に書き込む時、この断片化が、ホスト・コンピュータおよび記憶システム間に多数のＩ／Ｏ動作を生ずる可能性がある。
【００７７】
従来の論理オブジェクトの断片化を修正する方法は、典型的に、論理オブジェクトを形成するデータを、記憶システム内の空き空間の１組の隣接物理ブロックにコピーし、次いで断片化した論理オブジェクトの論理オブジェクト識別子を修正し、断片化を排した論理オブジェクトの新たなコピーを示すようにすることを伴う。しかしながら、従来の論理オブジェクトの断片化を修正する方法では、一般に、断片化修正プロセスが完了するまで、論理オブジェクトに対する修正を行うことができなかった。これは、このような断片化論理オブジェクトに頻繁にアクセスする（データベースのような）アプリケーションにとっては問題である。
【００７８】
図１０は、本発明の別の実施形態による再編成ルーチンの一例を示す。この再編成ルーチンは、論理オブジェクトのユーザに対する影響を最少に抑えつつ、ファイルのような論理オブジェクト、またはデータベース全体でさえも、断片化を修正するために用いることができる。再編成ルーチンは、ユーザ・プログラムまたはデータベースのような別のアプリケーション・プログラムによってコールすることができる。図１０に示す再編成ルーチンは、少なくとも１つの一次記憶装置と、少なくとも１つの一次記憶装置の１つ以上のミラーとを有するコンピュータ・システム上に論理オブジェクトが格納されていると仮定する。このようなミラー記憶装置は当技術分野では周知であり、一般に、リレーショナル・データベースが実装されているコンピュータ・システムのように、高いアクセス性（ａｃｃｅｓｓａｂｉｌｉｔｙ）を要求するコンピュータ・システムと連携されている。
【００７９】
ルーチンをコールする前に、ホスト・コンピュータ１１０（図１）のメモリ１３０において行われた論理オブジェクトに対するあらゆる変更を、記憶システム１４０に一括して送り込み（ｆｌｕｓｈ）、論理オブジェクトに対する全ての修正が記憶システムにおいて表されることを確保しておかなければならない。
【００８０】
ステップ１０１０において、再編成ルーチンは、論理オブジェクトを静止させ（書き込みを抑制し）論理オブジェクトに対する変更を一時的に禁止する。再編成ルーチンを実装するコンピュータ・システムによっては、論理オブジェクトはこの時間中リード・アクセスが可能な場合もある。論理オブジェクトを静止させた後、再編成ルーチンはステップ１０２０に進み、再編成ルーチンは、例えば、図６に関して説明した変更ＡＰＩをコールすることによって、論理オブジェクトにマークを付ける。これによって、再編成ルーチンは、再編成プロセスの間に論理オブジェクトに対して行われたあらゆる変更を、後に識別することができる。
【００８１】
ステップ１０３０において、一次記憶装置のミラーの１つを、コンピュータ・システムから分離させる。分離したミラーは基準を確立し、一次デバイス上の論理オブジェクトに対するあらゆる変更をこの基準と比較し識別することができる。ステップ１０４０において、再編成ルーチンは一次記憶装置を再活性化し、論理オブジェクトに対して変更を行なうことを許可する。一般に、ステップ１０１０ないし１０４０は、非常に短い時間量で行なうことができ、論理オブジェクトを修正できない時間量は抑えられる。
【００８２】
ステップ１０５０において、再編成ルーチンは（一次記憶装置からの）論理オブジェクトを新たな論理オブジェクトにコピーし、新たな再編成論理オブジェクトを作成する。これは、オペレーティング・システムが対応するいずれかのコピー・コマンドを用いて実行することができ、あるいは、より特殊化したコマンドを用いて実行することも可能である。例えば、論理オブジェクトがＯＲＡＣＬＥデータベースである場合、ＯＲＡＣＬＥデータベース・ソフトウエアは、「Ｃｒｅａｔｅ Ｔａｂｌｅ Ａｓ Ｓｅｌｅｃｔ」と呼ばれるコマンド・ユーティリティに対応している。これは、データベース・オブジェクトの再編成コピーを作成することができる。このＯＲＡＣＬＥのコマンドは、コマンドをコールした時点において存在している、一次記憶装置上の論理オブジェクトの再編成コピーを作成する。したがって、再編成コピーは、内部に含まれるデータに関しては、一次記憶装置の分離ミラー・コピー上に保存されている論理オブジェクトのコピーと同一である。しかしながら、再編成コピーは異なるフォーマット化がなされており、例えば、断片化修正フォーマット（ｄｅｆｒａｇｍｅｎｔｅｄ ｆｏｒｍａｔ）となっている。一次記憶装置上での論理オブジェクトの再編成が完了した後、再編成ルーチンはステップ１０６０に進む。
【００８３】
ステップ１０６０において、再編成ルーチンは、一次記憶装置上の再編成コピーの作成中に、一次記憶装置上の論理オブジェクトに対して行われたあらゆる変更を識別する。尚、大型のデータベースでは、再編成コピーの作成にはかなりの時間量を要する可能性があり、一次記憶装置上の論理オブジェクトに対する変更が非常に広範囲にわたる場合もあることを注記しておく。しかしながら、例えば、前述の変更ＡＰＩを用いることによって、論理オブジェクトに対するあらゆる変更を識別することができるので、これらの変更を再編成コピーに適用することができる。
【００８４】
ステップ１０７０において、再編成ルーチンは、一次記憶装置上の論理オブジェクトにおけるあらゆる変更を、論理オブジェクトの再編成コピーに適用する。このステップを実行する際、分割ミラー上に格納されている論理オブジェクトの基準コピーを、一次記憶装置上の論理オブジェクトと比較する。この比較によって、再編成ルーチンは、論理オブジェクト内の各論理ブロックにおけるどのデータが、基準コピーから変化したかについて正確に判定することができる。一次記憶装置上の論理オブジェクトと分離ミラー上の論理オブジェクトの基準コピーとの間の変化を識別した後、再編成ルーチンは、これらの変更を、一次記憶装置上の再編成論理オブジェクトに適用し、再編成コピーを更新し、ルーチンはステップ１０８０に進む。
【００８５】
ステップ１０８０において、再編成ルーチンは、一次記憶装置上の論理オブジェクトの論理オブジェクト識別子を修正して一次記憶装置上の当該論理オブジェクトの更新し再編成したコピーを示すようにして、ルーチンは終了する。
【００８６】
先に記したように、再編成ルーチンは、論理オブジェクトの変更データを、当該論理オブジェクトの基準コピーと比較することによって、論理オブジェクトに対する変更を識別することができる。当業者には認められようが、再編成ルーチンによって実行するステップは、データーベース・ソフトウエアが論理コピーを作成することができるデータベースにおける全てのデータベース・オブジェクトというように、多数の論理オブジェクトに対して実行することができる（即ち、ステップ１０５０において）。
【００８７】
本発明の更に別の実施形態によれば、最大論理ブロック・レベルよりも小さい論理ユニットで、データベース・オブジェクトに対する変更を識別する方法および装置を提供する。即ち、本発明の実施形態は、基準時点以降に追加、削除、または修正が行われたデータベースのあらゆるレコードの識別を可能にする。一実施形態では、この方法は、ＯＲＡＣＬＥデータベース・オブジェクトに対する変更を、基準時点以降に追加、削除、または修正されたデータのあらゆる行の行識別子によって識別できるようにする。この粒度は重要である。何故なら、最も関心がある情報は、典型的に、行レベルにあるからである。更に、本出願人の発明は、データベースにおいてどの行またはレコードの情報が変化したかを識別することによって、情報を報告することができる新たな枠組み（ｐａｒａｄｉｇｍ）全体を容易にすることができる。
【００８８】
当業者には公知であろうが、リレーショナル・データベース、可変シーケンシャル・アクセス方法（ＶＳＭＡ：ｖａｒｉａｂｌｅ ｓｅｑｕｅｎｔｉａｌ ａｃｃｅｓｓ ｍｅｔｈｏｄ）ファイル、インデックス・シーケンシャル・アクセス方法（ＩＳＡＭ）ファイル、および、ＯＲＡＣＬＥ、ＩＮＦＯＲＭＩＸ、ＳＹＢＡＳＥ、ＳＡＳ、ＳＡＰ等のような会社からのその他のデータ・ストアというようなデータ・ウェアハウス（ｄａｔａ ｗａｒｅｈｏｕｓｅ）が、銀行業務から健康管理まで広範囲に及ぶ多様な状況で用いられている。これらのデータ・ウェアハウスの各々は、ここではデータベースと呼ぶが、種々のハードウエアおよびオペレーティング・システムで構成された多数の異なる計算環境上に実現することができる。典型的に、これらのデータベースは大量の情報を格納し、その殆どは経時的に殆ど変化しない。ユーザ・プログラムまたはその他のアプリケーション・プログラムにとって最も関心がある情報は、情報のレコードまたは行と連携付けられたものである。データベース・オブジェクトの論理ブロックに関してデータベースに対する変更を識別することは、逐次バックアップや、データベースのセキュリティ監査というような目的にも使用可能であるが、この粒度はその他の目的に対しては粗すぎる可能性がある。ユーザ・プログラムまたはその他のアプリケーション・プログラムは、より具体的に、データベースのどの特定の行またはレコードが時と共に変化しているのかについて関心がある頻度が高い。例えば、データベース内に格納されているデータが在庫を表す場合、特定の品目の在庫の経時的な変化は、当該品目の実際の在庫よりも関心が高い場合がある。データベースからこのような情報にアクセスするために、特殊なオンライン報告アプリケーションが用意されていることが多い。これらの報告システムの中には、データベースによって与えられるログ・ファイルを処理するものもある。一般に、ログ・ファイル内のエントリの多くは、データベースに格納されている情報に対する変更については殆ど関与していないので、これは煩わしいプロセスである。変更情報のこの粒度を得る他の方法には、データベース自体の構造を修正し、論理レベルでデータ構造（例えば、インデックス）を割り当て、いつデータベースの特定の行が変更されたかを示すものがある。しかしながら、データベースのベンダは、このような変更を保証するのを躊躇っており、エンド・ユーザによってこのような修正がデータベースに対してなされると、データベース・ソフトウエアの今後のリリースに対するアップグレードを、継続できなくなる（ｕｎｔｅｎａｂｌｅ）虞れがある。更に、ソフトウエア・ベンダの一部は、実際にこのような変更を彼らのデータベースまたはアプリケーション・ソフトウエアに対して行なうことを禁止している。
【００８９】
本発明の別の態様によれば、データベースに属する論理データ・ユニットを識別する方法および装置を提供する。この場合、当該論理データ・ユニットに対するアプリケーション空間ラベルを用いて、データベースから論理ユニットに最初にアクセスする必要なく、これを行なう。一実施形態では、データベースに属する論理データ・ユニットのロケーションを一意に識別する第１識別子を得る方法を提供する。この方法は、識別子グループを直接指定しない、データベース構造に関する情報に基づいて、第１識別子を含む識別子グループを決定するステップを含む。後述する本発明の例示の一実施形態では、本発明のこの態様を用いて、データベース・オブジェクト内の行またはレコードを識別する。この方法は、変更ＡＰＩと共に用いて、あらゆるデータベース・オブジェクトに対して、当該データベース・オブジェクトのどの行またはレコードに、基準時点以降に追加、削除、または変更が行われたかについて判定し、対象の行またはレコードに対応する物理空間における物理変更ビットをリセットすることができる。ＯＲＡＣＬＥデータベースを対象とする一実施形態では、データベース・オブジェクトの行またはレコードを識別する方法は、ＯＲＡＣＬＥデータ・ディクショナリを用いて、論理レベルに格納されているデータベース・オブジェクトのファイル名称、およびそのデータベース・オブジェクトを形成する論理データ・ブロックを決定する。この情報に基づいて、レコード識別方法は、どの行またはレコードが各論理データ・ブロックに格納されているかについて判定を行なう。
【００９０】
先に注記したように、ＯＲＡＣＬＥデータベースでは、情報の行（またはレコード）はテーブル単位で格納されている。ＯＲＡＣＬＥデータベースは、行識別子（「ｒｏｗｉｄ」と呼ぶ）に基づいて情報の行を識別する。ＯＲＡＣＬＥデータベース内のｒｏｗｉｄのフォーマットを図１１に示す。図１１に示すように、ＯＲＡＣＬＥバージョン７以前のｒｏｗｉｄ１１１０のフォーマットは、ファイル番号１１１１、論理ブロック番号１１１２（アプリケーション空間３１０における）、および行番号１１１３を含む。ＯＲＡＣＬＥバージョン８のｒｏｗｉｄ１１２０のフォーマットは、オブジェクト番号１１２１、ファイル番号１１２２、論理ブロック番号１１２３、および行番号１１２４を含む。バージョン８において対応するオブジェクト・タイプは、クラスタ、インデックス編成テーブル、ユーザ定義オブジェクト等を含む。ＯＲＡＣＬＥバージン８におけるオブジェクト番号は、データベースが用いる場合のオブジェクトの名称、およびそのタイプを示し、各オブジェクトは、一意のオブジェクト番号を有する。全てのＯＲＡＣＬＥバージョンにおいて、ファイル番号は、オブジェクトが格納されているオペレーティング・システムのファイル名に基づいている。ＯＲＡＣＬＥバージョン８のｒｏｗｉｄはＯＲＡＣＬＥバージョン７以前のｒｏｗｉｄに含まれる情報のスーパーセットを含むので、以下の論述は、新しいバージョン８のｒｏｗｉｄフォーマットを対象にすることとする。しかしながら、本発明の実施形態はバージョン７以前でも同様に使用可能であることは認められよう。
【００９１】
各ｒｏｗｉｄは、行またはレコードが連携するオブジェクト名およびタイプ、ファイル名、論理ブロック、および当該行に関連するデータが論理レベルにおいて格納されている行番号を示すので、ＯＲＡＣＬＥデータベース・オブジェクトにおける各行またはレコードは、そのｒｏｗｉｄに基づいて一意に特定することができる。各行またはレコードはその対応するｒｏｗｉｄによって識別することができるが、特定の行またはレコードのｒｏｗｉｄを得るには、従来では、最初にアプリケーション空間におけるラベル（例えば、シカゴ市の人口）によって、行またはレコードにアクセスしなければならなかった。典型的に、この形態のアクセスは、特に大型データベースでは、非効率的である。一旦行またはレコードにアクセスしたなら、当該行またはレコードをデータベースに一意に識別するｒｏｗｉｄを、データベースから要求することができるので、データベースに対してｒｏｗｉｄを直接指定することによって、以降のアクセスを実行することができる。尚、例えば、アプリケーション・プログラムによって行またはレコードに最初にアクセスする場合、当該行と連携する論理データ・ブロック全体を、データベース・ソフトウエアによって読み取り、走査して所望の情報を求めることを注記しておく。本出願人は、報告システムのようなその他のアプリケーションは、この情報の大部分には関心がないことを発見した。例えば、このようなその他のアプリケーションは、データベース・オブジェクト内にある特定の行またはレコードのみを識別し、その中に格納されている情報が変更されたか否か判定することに関心があると考えられる。この技術にとって有用なその他のアプリケーションも、想定することができる。
【００９２】
本発明の一実施形態によれば、アプリケーション空間におけるラベルを用いてデータベースから論理データ・ユニットに最初にアクセスすることなく、データベース内部の論理データ・ユニットのロケーションを一意に識別する識別子を得る方法を提供する。この方法は、特定の行またはレコードに対応するデータを、別のアプリケーションに供給し、続いて処理または報告を行なうために用いることができる。以下では、データベース・オブジェクトの行またはレコードを識別する方法は、行またはレコードに対する変更を識別する（例えば、図４の変更ＡＰＩを用いて）ために用いるものとして説明するが、この方法は、その他の目的でデータベース・オブジェクトの特定の行またはレコードを識別するためにも使用可能であることは認められよう。
【００９３】
図１２は、データベース・オブジェクトの行またはレコードを識別し、特定のレコードに対応するデータを与える、データベース・レコード識別ルーチンを示す。図４の変更ルーチンと共に用いる場合、この識別ルーチンは、論理ブロック・レベルよりも低い粒度で、データベースの行またはレコードに格納されている情報が、基準時点以降に、追加、削除、または修正されたか否か識別するために用いることができる。同様に、識別ルーチンは、図６のリセット・ルーチンと共に用いて、物理空間内の対応する変更ビットをリセットすることも可能である。変更ＡＰＩと共に用いる場合、基準時点以降に変化した各行またはレコードを識別することができる。物理レベルで与えられる変更情報が、十分に小さな情報ユニットにおいて変更を識別するのに十分な粒度を有するのであれば、変更ＡＰＩを用いて、先に論じたように行またはレコードに対する変更を識別することができる。あるいは、物理変更情報が十分な粒度ではなく、データベース・オブジェクトのより大きな論理ユニットについてのみ変更を識別する場合、本発明の一実施形態では、変更されたより大きな論理ユニット（例えば、論理ブロック）の各行における行データを、基準時点における対応する論理ユニットで作られた基準コピーと比較し、基準点以降にデータベース・オブジェクトにおいて追加、削除、または修正されたいずれの情報の行でも識別することができる。
【００９４】
図１２のデータベース・レコード識別ルーチンは、ホスト・コンピュータ１１０（図１）のプロセッサ１２０上で実行する汎用アプリケーション・プログラムとして実装することができる。ユーザ・プログラムまたはその他のアプリケーション・プログラムは、特定のデータベース・オブジェクトをルーチンに指定することによって、データベース・レコード識別ルーチンと通信することができる。データベース・オブジェクトは、具体的なデータベース・オブジェクト・タイプ、例えば、テーブルとしてもよく、全体として、データベース全体に言及してもよい。データベース・レコード識別ルーチンのあるステップは、ルーチンに指定されたデータベース・オブジェクトのタイプに応じて変化する。これについて、以下で更に詳しく説明する。
【００９５】
図１２に示すデータベース・レコード識別ルーチンは、一次記憶装置および当該一次記憶装置の１つ以上のミラーを有するコンピュータ・システム上に、データベース・オブジェクトが格納されていると仮定する。レコード識別ルーチンをコールする前に、ホスト・コンピュータ１１０（図１）のメモリ１３０において行われたデータベース・オブジェクトに対するあらゆる変更を記憶システム１４０に一括して送り込み、論理オブジェクトに対する全ての修正が記憶システムにおいて表されることを確保する。
【００９６】
ステップ１２１０において、ルーチンはデータベース・オブジェクトを静止（即ち、書き込みを抑制）し、データベース・オブジェクトに対する変更を一時的に禁止する。ルーチンを実装するコンピュータ・システムによっては、この時間中読み取りアクセスのためにデータベース・オブジェクトがなおも利用できる場合もある。データベース・オブジェクトを静止した後、ルーチンはステップ１２２０に進み、例えば、図６に関して説明したリセットＡＰＩをコールすることによって、データベース・オブジェクトにマークを付ける。このステップによって、レコード識別ルーチンは、データベース・オブジェクトにおいて変更されたあらゆるレコードをその後に識別することができ、基準時点を設定し、この時点以降のデータベース・オブジェクトに対する変更を判定する。ステップ１２３０において、一次記憶装置のミラーの内１つをコンピュータ・システムから分離する。図１０の再編成ルーチンにおけると同様、分離ミラーは基準を確立し、一次記憶装置上のデータベース・オブジェクトに対するあらゆる変更をこの基準と比較し識別することができる。ステップ１２４０において、ルーチンは一次記憶装置を再活性化し、データベース・オブジェクトを変更可能にする。一般に、ステップ１２１０〜１２４０は、非常に短い時間量で行なうことができ、論理オブジェクトを修正できない時間量は抑えられる。
【００９７】
ステップ１２５０において、レコード識別ルーチンは、データベース・オブジェクトの変更を監視して以降の、一次記憶装置に上のデータベース・オブジェクトに行われたあらゆる変更を識別する。このステップは、データベース・オブジェクトを再活性化した後であればいずれの時点でも実行することができる。本発明の一実施形態では、図４に関して先に説明した変更ＡＰＩを用いて、修正されたデータベース・オブジェクトの論理ブロックに関して、データベース・オブジェクトにおける変更を識別する。
【００９８】
ステップ１２６０において、ルーチンは、ステップ１２５０で識別されたデータベース・オブジェクトの各変更論理ブロックと連携するレコードまたは行を識別し、ダンプ（即ち、読み出し出力）する。レコードまたは行をどのように識別しダンプするかについての更に詳しい説明は、図１３および図１４に関連付けて以下で記載する。
【００９９】
ステップ１２７０において、レコード識別ルーチンは、ステップ１２６０と同様に、一次記憶装置上のデータベース・オブジェクトの分割ミラー・コピーの対応する論理ブロックにおける行およびレコードを識別してダンプする。ステップ１２８０において、ルーチンは、ステップ１２６０および１２７０においてダンプしたレコードを比較し、基準時点以降に追加、削除、または修正された行を識別する。具体的には、ステップ１２８０において、あるｒｏｗｉｄが、分割ミラー上に格納されているデータベース・オブジェクトの基準コピー内で発見されたが、一次記憶装置上に格納されているデータベース・オブジェクト内では発見されない場合、基準時点以降に行が削除されたと判定する。あるいは、データベース・オブジェクトの特定の論理ブロックに対するｒｏｗｉｄが、一次記憶装置上のデータベース・オブジェクトの現バージョンにおいて発見されたが、分割ミラー上のデータベース・オブジェクトの基準コピー内では発見されない場合、基準時点以降にデータベース・オブジェクトに行が挿入または追加されたと判定する。最後に、ｒｏｗｉｄが、分割ミラー内のデータベース・オブジェクトの基準コピー内、および一次記憶装置上のデータベース・オブジェクトの現バージョンにおいて発見された場合、実際の行データの比較を行い、何らかの相違があるか否か識別する。データベース・オブジェクトの現バージョンに対する行データが、データベース・オブジェクトの基準コピーのそれと相違する場合、そのｒｏｗｉｄに対応する行内のデータが基準時点以降修正されたと判定する。
【０１００】
行情報が追加、削除、または修正されたか否か判定した後、ルーチンはステップ１２９０に進み、この情報をアプリケーション・プログラムまたはルーチンをコールしたユーザに提供し、次いでルーチンは終了する。
【０１０１】
図１３は、特定のデータベース・オブジェクトと連携する行またはレコードを識別しダンプするルーチンを示す。このルーチンは、レコード識別ルーチン、またはその他のアプリケーション・プログラムによってコールし、データベース・オブジェクト内の特定の行またはレコードを識別しダンプすることができる。図１３のルーチンは、典型的に、アプリケーション空間３１０（図３）内で実行する別のアプリケーション・プログラムによってコールされるが、異なる空間内で実行する別のコンピュータ・プログラムがこのルーチンをコールしてもよいことは認められよう。更に、図１３のルーチンは典型的にソフトウエアで実現されるが、本発明はそれに限定される訳ではない。何故なら、このルーチンは、ハードウエアまたはファームウエア、あるいはソフトウエア、ハードウエア、およびファームウエアの組み合わせで実現することも可能であるからである。
【０１０２】
端的に要約すると、図１３のルーチンは、上側境界ｒｏｗｉｄおよび下側境界ｒｏｗｉｄを、データベース・オブジェクトの対象論理ブロック内に潜在的に格納されている可能性がある各データ行毎に決定することを伴う。この決定は、対象の論理ブロックのオブジェクト番号（適用可能な場合）、ファイル番号、論理ブロック番号、ならびに論理ブロックに格納可能な最大および最小行番号に基づく。どのｒｏｗｉｄが対象の特定論理ブロック内に潜在的に格納されている可能性があるか判定した後、ルーチンは、どのｒｏｗｉｄが実際に対象の論理ブロックに格納されているかを判定し、これらのデータ行の各々と連携する行データを出力する。
【０１０３】
ステップ１３１０において、ルーチンは、データベース・オブジェクトの特定の論理ブロックに対応する上側および下側境界ｒｏｗｉｄを決定する。上側および下側境界ｒｏｗｉｄは、データベース・オブジェクトに対するオブジェクト番号、ファイル番号、および論理ブロック番号に基づいて算出される。図１３のルーチンを図４の変更ＡＰＩと共に用いて、変更したデータベース・オブジェクトの行をダンプする場合、データベース・オブジェクトに対する論理ブロック番号が変更ＡＰＩによって与えられる。したがって、特定の論理ブロック内に含まれる各行またはレコードに対してｒｏｗｉｄを算出するために足りない情報は、図１１に示すように、特定のレコードのオブジェクト番号、ファイル番号、および行番号である。図１４に関して以下で更に詳しく説明するが、オブジェクト番号およびファイル番号は、ＯＲＡＣＬＥデータ・ディクショナリに問い合わせ、特定のデータベース・オブジェクトを求めることによって決定することができる。この場合も、図４の変更ＡＰＩと共に用いる場合、データベース・オブジェクトはわかっており、これは、変更ＡＰＩに渡され、データベース・オブジェクト内におけるあらゆる変更を判定したオブジェクトである。したがって、決定すべき残っているものは、変更データを含むと識別された論理データ・ブロックにおける各行の実際の行番号である。論理ブロックに含まれる各データ行の行番号は正確にはわからないが、この行番号に対する上側および下側の境界は、図１４に関連付けて以下で説明するように決定することができる。論理ブロックにおける各行は、上側および下側境界の間にあることがわかる。
【０１０４】
識別した各論理データ・ブロックに対して上側および下側境界ｒｏｗｉｄを決定した後、ルーチンはステップ１３２０に進み、識別された論理ブロックからの個々のレコードを読み出し、ルーチンをコールしたアプリケーションに、以下に論ずるように与える。
【０１０５】
図１４は、データベース・オブジェクトの特定の論理ブロック内にある全ての行が存在する上側境界および下側境界を判定するために用いることができる上側境界および下側境界行識別ルーチンを示す。即ち、図１４のルーチンは、コールされたときに、論理ブロックが渡され、その論理ブロック上で動作する。上側および下側境界行識別ルーチンの動作は、論理ブロックが関連するデータベース・オブジェクトのタイプによって異なる。したがって、最初に、テーブルのような、データベース・オブジェクトの指定されたタイプについて、ルーチンの動作を説明し、次いでデータベース全体のように、データベース・オブジェクトのより一般的なタイプについて再度説明する。
【０１０６】
図１４に示すように、データベース・オブジェクトの特定のタイプ（例えば、テーブル）に対してコールされた後、上側および下側境界行識別ルーチンはステップ１４１０に進む。ステップ１４１０において、ルーチンは、指定されたデータベース・オブジェクトに対するオブジェクト番号を決定する。このステップは、ＯＲＡＣＬＥデータベースによって与えられる、ｄｂａ＿ｏｂｊｅｃｔｓディクショナリ・ビュー（ｄｉｃｔｉｏｎａｒｙ ｖｉｅｗ）を用いて、ＯＲＡＣＬＥデータ・ディクショナリに問い合わせることによって実行することができる。当業者には理解されようが、ＯＲＡＣＬＥデータ・ディクショナリとは、問い合わせをすることができ、データベースおよびそのデータベース・オブジェクトの構造および編成についての情報を提供するユーティリティである。ＯＲＡＣＬＥデータ・ディクショナリに対する問い合わせは、構造型問い合わせ言語（ＳＱＬ）ステートメントを用いて行われる。ＳＱＬは、リレーショナル・データベースにおいて動作を実行するために広く採用されている標準的なプログラミング言語であり、ＯＲＡＣＬＥ、ＩＮＦＯＲＭＩＸ等のようなリレーショナル・データベース提供者によって支援されている。例えば、以下のＳＱＬコード・フラグメントは、ＯＲＡＣＬＥデータ・ディクショナリに問い合わせ、「ＴＡＢＬＥ ＮＡＭＥ」という名称を有する指定のデータベース・テーブルを求め、この指定のテーブルに対応するオブジェクト番号を与える。
【０１０７】
1 select data_object_number
2 from dba_objects
3 where object_name='<TABLE NAME>'
4 and object_type='TABLE';
上のコード・フラグメントでは、問い合わせのライン４は、テーブルであるデータベース・オブジェクトに制約される。しかしながら、当業者には公知であろうが、このラインを修正し、他のデータベース・オブジェクト・タイプを識別することも可能である。
【０１０８】
指定されたデータベース・オブジェクトに対するオブジェクト番号を決定した後、ルーチンはステップ１４２０に進み、ここでルーチンは、指定されたデータベース・オブジェクトに対するファイル名（または複数のファイル名）を決定する。このステップは、ｄｂａ＿ｅｘｔｅｎｔｓディクショナリ・ビューを用いてＯＲＡＣＬＥデータ・ディクショナリに問い合わせることによって実行することができる。以下のＳＱＬコード・フラグメントは、ＯＲＡＣＬＥデータ・ディクショナリに問い合わせ、名称「ＴＡＢＬＥ ＮＡＭＥ」を有する指定のテーブルと連携するファイル識別子（即ち、ファイル名）を求める。
【０１０９】
1 select file_id
2 from dba_extents
3 where segment_name='<TABLE NAME>'
4 and segment_type='TABLE'
先のコード・フラグメントにおけると同様、この問い合わせは、テーブルであるデータベース・オブジェクトに限定されるが、当業者には公知のように、修正して他のデータベース・オブジェクト・タイプを識別することも可能である。
【０１１０】
指定のデータベース・オブジェクトと連携するファイルのファイル名を識別した後、行識別ルーチンはステップ１４３０に進む。ステップ１４３０において、ルーチンは、ステップ１２２０において識別したファイル名の各々に対応するファイル番号（ＯＲＡＣＬＥでは「相対ファイル番号」と呼ぶ）を識別する。このステップは、ｄｂａ＿ｄａｔａ＿ｆｉｌｅｓディクショナリ・ビューを用いてＯＲＡＣＬＥデータ・ディクショナリに問い合わせることによって、実行することができる。以下のＳＱＬコード・フラグメントは、ＯＲＡＣＬＥデータ・ディクショナリに問い合わせ、ファイル名「ＦＩＬＥ ＮＡＭＥ」を有するファイルと連携する相対ファイル番号を求める。
【０１１１】
1 select relative_fno
2 from dba_data_files
3 where file_id='<FILE NAME>'
あるいは、ステップ１４２０および１４３０は、直ぐ下に示すように、単一のＳＱＬコード・フラグメントを用いて実行してもよい。
【０１１２】
1 select
2 relative_fno,
3 file_name
4 from dba_data_files df
5 where df.file_id in (
6 select de.file_id
7 from dba_extents de
8 where segment_name='<TABLE>'
9 and segment_type='TABLE'
10 );
上のコード・フラグメントにおいて、ライン６ないし９は、「ＴＡＢＬＥ」という名称のテーブルに対するファイル識別子のリストを戻し、行１ないし５は、ファイル識別子のリストに対応する相対ファイル番号およびファイル名を戻す。
【０１１３】
ステップ１４３０において、指定のデータベース・オブジェクトに対する相対ファイル番号を決定した後、ルーチンはステップ１４４０に進む。ステップ１４４０において、ルーチンは、指定の論理ブロックに対して上側境界ｒｏｗｉｄおよび下側境界ｒｏｗｉｄを決定する。以下のＳＱＬコード・フラグメントは、データベース・オブジェクトが格納されている特定の論理ブロックに対して、ｒｏｗｉｄの上側境界および下側境界を決定する２つの代替方法の１つを示す。このコード・フラグメントは、ＯＲＡＣＬＥデータベース・ソフトウエアに対応する、直ぐ下に示す手順を利用する。
【０１１４】
1 select
2 DBMS_ROWID.ROWID_CREATE(
3 1,
4 <object number>
5 <relative file number>
6 <block number>
7 <row number>)
8 from dual;
上のコード・フラグメントでは、オブジェクト番号および相対ファイル番号は、それぞれ、ステップ１４２０および１４３０において決定したものである。ブロック番号は、データベース・オブジェクトの行が格納されている論理ブロック番号を示し、ルーチンをコールしたアプリケーション、例えば、図１２のレコード識別ルーチンによって、行識別ルーチンに与えることができる。上のコード・フラグメントにおいて用いられる行番号は、上側境界行番号または下側境界行番号のいずれかである。したがって、対象の論理ブロック毎に上のコード・フラグメントを２回実行する。１回目は下側境界行番号、そして再度上側境界行番号を用いて実行する。
【０１１５】
一般に、下側境界行番号は、ＯＲＡＣＬＥによって用いられる最低の行番号（即ち、行０）であり、上側境界行番号は、現在ＯＲＡＣＬＥが対応する最高の行番号である。現在、ＯＲＡＣＬＥが対応する最大論理ブロック・サイズは、６５５３６バイトである。いずれの行も少なくとも１バイトを占めるので、現在ＯＲＡＣＬＥが対応可能な最高の行番号は、行番号６５５３６である。更に、ＯＲＡＣＬＥによって供給されるｒｏｗｉｄ手順は、現在行番号６５５３６で元に戻る（ｗｒａｐ）ことを注記しておく。現在ＯＲＡＣＬＥが対応する最高の行番号を用いる代わりに、特定のＯＲＡＣＬＥデータベースにおいて見ることができる最高の行番号を用いてもよい。即ち、最高の行番号は、上側および下側境界行識別ルーチンと共に用いられる特定のＯＲＡＣＬＥデータベースにおいて許される最大論理ブロック・サイズに基づくことができる。この許される最大の論理ブロック・サイズは、ＯＲＡＣＬＥデータベースを検査することによって決定することができる。ＯＲＡＣＬＥデータベースによって用いられる最大許容論理ブロック・サイズが、ＯＲＡＣＬＥが対応する最大許容可能ブロック・サイズよりも著しく小さい場合、最高の行番号に対して小さい値を用いると、図１３のルーチンの効率を高めることができる。
【０１１６】
ステップ１４４０における上側および下側境界ｒｏｗｉｄを決定する代わりの方法は、オブジェクト番号、相対ファイル番号、論理ブロック番号、ならびに上側および下側境界行番号に基づくｒｏｗｉｄの直接エンコードに基づくことができる。ｒｏｗｉｄのフォーマットは、ＯＲＡＣＬＥ８ Ａｐｐｌｉｃａｔｉｏｎ Ｄｅｖｅｌｏｐｅｒ’ｓ Ｇｕｉｄｅ Ｒｅｌｅａｓｅ ８．０の第５章に、ＯＲＡＣＬＥによって文書化されている。文書化されているように、ｒｏｗｉｄは、基準６４キャラクタ・セットに基づく。ステップ１４１０ないし１４３０に記載したように、特定の対象論理ブロックに対して決定した情報（即ち、オブジェクト番号、相対ファイル番号、および論理ブロック番号）、および行番号（例えば行０および行６５５３６）に対する上側および下側境界が与えられると、所望通りに、いずれかの特定のプログラミング言語を用いて、文書化されている基準６４（ｂａｓｅ６４）キャラクタ・セットに基づいて、上側および下側境界ｒｏｗｉｄを直接エンコードすることができる。この直接エンコードは、一般に、前述のＯＲＡＣＬＥが対応する手順を用いるよりも効率的である。ステップ１４４０においていずれかの方法で上側および下側境界ｒｏｗｉｄを決定した後、ルーチンは終了する。
【０１１７】
先に注記したように、図１４の上側および下側境界行識別ルーチンは、データベース全体に対する上側および下側ｒｏｗｉｄを識別するためにも使用可能である。一般に、典型的なデータベースにおいては多数のデータベース・オブジェクトのために、このような情報は、典型的に、例えば、図１２のレコード識別ルーチンを用いることによって、特定の基準時点以降のデータベース全体に対するあらゆる変更を識別することの要求と連携して、要求される。データベース全体に関する変更情報が要求された場合（例えば、セキュリティ監査のため、またはデータベースのレコードを修正するアプリケーション・プログラムを検証するため）、以下のＳＱＬコード・フラグメントを用いて、データベース内で変化したあらゆる行またはレコードを識別することができる。
【０１１８】
1 select /*+parallel(dba_extents, 10, 1)*/
2 do.object_name||''||
3 do.data_object_id||''||
4 de.relative_fno||''||
5 de.owner||''||
6 from dba_extents de, dba_objects do
7 where do.object_name=de.segment_name
8 and do.onwer=de.owner
9 and do.object_type = de.segment_type
10 and do.object_type = 'TABLE'
11 and <BLOCK> between de.block_id and (de.block_id+de.blocks-1)
12 and de.file_id = (
13 select df.file_id
14 from dba_data_files df
15 where file_name = '<FILE NAME>'
16 );
上のコード・フラグメントは、ＯＲＡＣＬＥデータベースの各論理ブロックに対して、オブジェクト名および番号、ファイル名、ならびに相対ファイル番号を戻す双方向合併問い合わせ（ｊｏｉｎ ｑｕｅｒｙ）である。合併問い合わせとは、２つ以上の問い合わせ上でセット動作を実行するものである。上のコード・フラグメントでは、合併問い合わせは、２つのディクショナリ・ビューの共通部分（ｉｎｔｅｒｓｅｃｔｉｏｎ）を実行する。ＯＲＡＣＬＥデータベースにおけるブロック数は、従来のストレージのギガバイトに及び得るので、上のコード・フラグメントは、典型的に、変更ＡＰＩによって基準時点以降に変更されたとして識別された論理ブロックのように、特定の対象論理ブロックに限定される。直ぐ上に示したコード・フラグメントは、前述のレコード識別ルーチンと同じステップ１４１０ないし１４４０を実行するが、これは、単一のコード・フラグメントで、データベース全体として、指定の論理ブロックに対してこれらのステップを実行するのみである。
【０１１９】
上のコード・フラグメントは、ＯＲＡＣＬＥデータ・ディクショナリに、指定の論理ブロック番号に対して、ＯＲＡＣＬＥデータベースにおけるどのテーブル範囲に、指定の論理ブロック番号が存在するかについて判定を行なう。論理ブロックが存在する範囲が一旦判定されたなら、ｄｂａ＿ｅｘｔｅｎｔｓディクショナリ・ビューに問い合わせを行い、このテーブル範囲を所有するデータベース・オブジェクトを識別することができる。上のコード・フラグメントは、テーブル・オブジェクトおよび２つの異なるディクショナリ・ビュー（ｄｂａ＿ｏｂｊｅｃｔおよびｄｂａ＿ｅｘｔｅｎｔ）のみを見るが、他のデータベース・オブジェクトも見るように修正することができる。これら２つのビューから、オブジェクト名およびファイル名双方を決定し、これから、オブジェクト番号および相対ファイル番号を、前述と同様に決定することができる。このコード・フラグメントのライン１は、ＯＲＡＣＬＥデータベース・ソフトウエアに、可能であれば、この問い合わせを並行して１０個までのプロセッサ（ＣＰＵ）上で実行するように指令する。一般に、ＯＲＡＣＬＥユーティリティは、明示的に命令されない限り、並列プロセッサを用いて動作を実行することはない。
【０１２０】
前述のように、上側および下側境界行識別ルーチンは、データベース・オブジェクトの特定の論理ブロック内にある全てのｒｏｗｉｄが存在する上側境界および下側境界を決定する。しかしながら、この情報は、特定のブロック内にある全てのｒｏｗｉｄを見つけることができる境界を識別するだけに過ぎない。したがって、データベース・オブジェクトの特定の論理ブロック内にある実際の各データ行に対応する実際のｒｏｗｉｄを識別する方法を提供する。この方法は、実際のｒｏｗｉｄを識別するだけでなく、この情報をダンプする（即ち、読み取り出力する）ためにも用いることができるので（即ち図１３のステップ１３２０）、別のアプリケーション、例えば、図１２のレコード識別ルーチンが用いてもよい。
【０１２１】
例示の一実施形態では、論理ブロックにおける行情報は、特定の論理ブロックにおける各行について、行毎に得ることができる。例えば、以下のＳＱＬコード・フラグメントは、図１４の行識別ルーチンによって決定された、下側境界ｒｏｗｉｄ以上および上側ｒｏｗｉｄ以下のｒｏｗｉｄによって識別された論理ブロック内の全ての行を識別する。
【０１２２】
1 select/*+ rowid(<TABLE>)* / rowid, <TABLE>.* from <TABLE>
2 where (rowid >= '<LOW ROWID A' and rowid <= 'HIGH ROWID A')
上のコード・フラグメントを用いてＯＲＡＣＬＥデータ・ディクショナリに問い合わせをすると、ＯＲＡＣＬＥデータ・ディクショナリは、上側および下側ｒｏｗｉｄ間で各データ行毎に、ｒｏｗｉｄおよび行データ双方を戻す。このフラグメントによって与えられる情報は、他のアプリケーション、例えば、図１２のレコード識別ルーチンに行データを与えるために用いることができる。図１２のレコード識別ルーチンと共に用いる場合、コード・フラグメントは、ステップ１２８０においてレコード識別ルーチンによって比較される各論理データ・ブロックに対して実行される。
【０１２３】
別の実施形態では、多数の論理ブロックにおける行情報を、多数の論理ブロックにおける各行について、行毎に得ることができる。例えば、以下のＳＱＬコード・フラグメントは、単一動作で、論理ブロックＡ、Ｂ、Ｃ、およびＤ内にある全てのデータ行に対して、ｒｏｗｉｄおよび行データを得る。
【０１２４】
1 select /*+ rowid(<TABLE>) * / rowid, <TABLE>. * from <TABLE>
2 where (rowid >= '<LOW ROWID A' and rowid <= 'HIGH ROWID A')
3 or (rowid >= '<LOW ROWID B' and rowid <='HIGH ROWID B')
4 or (rowid >= '<LOW ROWID C' and rowid <='HIGH ROWID C')
5 or (rowid >= '<LOW ROWID D' and rowid <='HIGH ROWID D')
6 ...
多数の論理ブロックに対する行情報も、以下に示すような異なる方法で、当該数ブロックにおける各行について、行毎に得ることができる。先のコード・フラグメントにおけると同様、多数の論理ブロック内にある全ての行に対して、行データが戻される。以下のＳＱＬコード・フラグメントは、論理ブロックＡ、Ｂ、およびＣ内にある全てのデータ行に対して、ｒｏｗｉｄおよび行データを得る。
【０１２５】
1 select /*+ rowid(<TABLE>) * / rowid, <TABLE>. * from <TABLE>
2 where (rowid >= '<LOW ROWID A' and rowid <= 'HIGH ROWID A')
3 union all
4 select * from <TABLE>
5 where (rowid >= '<LOW ROWID B' and rowid <='HIGH ROWID B')
6 union all
7 select * from <TABLE>
8 where (rowid >= '<LOW ROWID C' and rowid <='HIGH ROWID C')
9 ...
以上、本発明のいくつかの実施形態を詳細に説明したが、種々の変更および改良も当業者には容易に想起されよう。かかる変更および改良は、本発明の範囲内であることとする。したがって、前述の説明は一例に過ぎず、限定として意図したのではない。本発明は、特許請求の範囲およびその均等物によって規定されるものとしてのみ限定されることとする。
【図面の簡単な説明】
【図１】 本発明の態様を採用可能なコンピュータ・システムの機能ブロック図である。
【図２】 ＯＲＡＣＬＥデータベース内にデータを格納する方法の構成図である。
【図３】 論理オブジェクトの物理空間に対するマッピングを行なうマッピング・レイヤを有するコンピュータ・システムの構成図である。
【図４】 本発明の一実施形態にしたがって、論理オブジェクトに対する変更の識別に用いることができる識別ルーチンを示すフローチャートである。
【図５】 図５（ａ）は、論理オブジェクトと、当該論理オブジェクトが物理空間のどこに格納されているかを示すマッピング情報との間の対応を示す図である。
図５（ｂ）は、本発明の例示の一実施形態による物理レベルにおける変更情報を示すために用いられるビットマップを示す図である。
【図６】 本発明の一実施形態にしたがって、指定された論理オブジェクトに対応する物理変更ビットをリセットするために、変更ＡＰＩが用いることができるステップを示すフローチャートである。
【図７】 本発明の実施形態と共に用い、論理オブジェクトを物理空間にマップするために用いることができる、例示のマッピング・ルーチンのフローチャートである。
【図８】 マッピング・レイヤおよびインテリジェント記憶装置を含むコンピュータ・システムの構成図である。
【図９】 本発明の一態様にしたがってアプリケーション・プログラムのデバックを行なうために実行することができるステップを示すフローチャートである。
【図１０】 本発明の別の実施形態にしたがって、最少のダウンタイムで論理オブジェクトを再編成するために用いることができる再編成ルーチンを示すフローチャートである。
【図１１】 ＯＲＡＣＬＥデータベースにおける行識別子を示す図である。
【図１２】 本発明の別の実施形態にしたがって、データベース・オブジェクトの行またはレコードを識別し、特定のレコードに対応するデータを供給するルーチンを示すフローチャートである。
【図１３】 本発明の別の実施形態にしたがって、特定のデータベース・オブジェクトと連携された行またはレコードを識別しダンプする際のフローチャートである。
【図１４】 本発明の更に別の実施形態にしたがって、データベース・オブジェクトの特定の論理ブロック内にある全ての行が含まれる、上側境界および下側境界を決定する際に用いることができる、上側境界および下側境界行識別ルーチンのフローチャートである。

Claims (32)

1. 基準時点以降の論理オブジェクトに対する変更を判定する方法であって、前記論理オブジェクトは、ホスト・コンピュータ、記憶システム、および前記論理オブジェクトを前記記憶システム上の物理記憶ロケーションに互いに関係する物理レイヤにマップする少なくとも１つのマッピング・レイヤを含むコンピュータ・システムにおける、ホスト・コンピュータのアプリケーション・レイヤに属し、前記物理レイヤが、前記基準時点以降における前記記憶システム上の前記物理記憶ロケーションに対して行われた変更を示す物理変更情報を含み、前記方法が、
   （Ａ）前記アプリケーション・レイヤから前記物理レイヤに前記論理オブジェクトをマップする前記少なくとも１つのマッピング・レイヤを用いて、どの物理記憶ロケーションが前記論理オブジェクトに対応するデータを含むか識別するステップと、
   （Ｂ）前記物理変更情報を用いて、前記ステップ（Ａ）において識別されたものの内、前記基準時点以降に変化したデータを含む物理記憶ロケーションを識別するステップと、
   （Ｃ）いずれかの物理記憶ロケーションが、前記ステップ（Ｂ）において前記基準時点以降に変化したデータを含むと識別された場合、変更が前記論理オブジェクトに対して行われたと判定するステップと、
   から成る方法。
2. 請求項１記載の方法において、前記論理オブジェクトは、集合的に前記論理オブジェクトを形成する複数の論理ユニットを含み、前記方法は、更に、
   （Ｄ）前記ステップ（Ｂ）において識別された前記物理記憶ロケーションを前記アプリケーション・レイヤに照合し、前記複数の論理ユニットのどれが当該識別された前記物理記憶ロケーションに対応するか判定することにより、前記論理オブジェクトにおける前記複数の論理ユニットのどれが、前記基準時点以降に変化したデータを含むのか識別するステップを含む、
   方法。
3. 請求項１記載の方法において、前記論理オブジェクトは、集合的に前記論理オブジェクトを形成する複数の論理ユニットを含み、前記方法は、更に、
   （Ｄ）前記基準時点において前記論理オブジェクトのコピーを作成するステップと、
   （Ｅ）前記ステップ（Ｂ）において識別した前記物理記憶ロケーションを前記アプリケーション・レイヤに照合し、前記論理オブジェクトの前記複数の論理ユニットのどれが当該識別された前記物理記憶ロケーションに対応するかを判定することにより、前記論理オブジェクトにおける前記複数の論理ユニットのどれが、前記基準時点以降に変化したデータを含むのか識別するステップと、
   （Ｆ）変化したデータを含む前記論理オブジェクト内の論理ユニットを、前記論理オブジェクトのコピーにおける対応する論理ユニットと比較し、前記論理オブジェクトに対する変更が、前記論理オブジェクトのコピーに対比して前記論理オブジェクトの追加、削除、および修正のうちのどれであるのかを判定するステップと、
   を含む方法。
4. 請求項３記載の方法において、変化したデータを含む前記論理オブジェクト内の論理ユニットは、各々、前記論理オブジェクトが前記アプリケーション・レイヤにおいて属するアプリケーションに関連する情報の数個のフィールドを含み、前記ステップ（Ｆ）は、変化したデータを含む前記論理オブジェクト内の論理ユニットを、前記論理オブジェクトのコピーにおける対応する論理ユニットと比較し、前記論理オブジェクトを形成する前記論理ユニットにおける前記数個の情報フィールドのどれが、前記基準時点以降に変化したか判定するステップを含む方法。
5. 請求項１ないし４のいずれか１項記載の方法において、前記記憶システムは、前記物理レイヤから前記記憶システムに含まれる複数の記憶装置にマップする追加のマッピング・レイヤを含み、前記物理変更情報を前記物理レイヤにおいて与え、前記ステップ（Ａ）は、前記論理オブジェクトを前記アプリケーション・レイヤから前記物理レイヤのみにマップし、前記追加のマッピング・レイヤを通じて前記複数の記憶装置にはマップしない、ステップを含む方法。
6. 請求項１記載の方法であって、更に、
   （Ｄ）前記基準時点において前記物理変更情報をリセットするステップ、
   を含む方法。
7. 請求項６記載の方法において、前記基準時点において前記物理変更情報をリセットするステップは、
   （Ｅ）前記論理オブジェクトを前記アプリケーション・レイヤから前記物理レイヤにマップする前記少なくとも１つのマッピング・レイヤを用いて、どの物理記憶ロケーションが前記論理オブジェクトに対応するデータを含むか識別するステップと、
   （Ｆ）前記ステップ（Ｅ）において識別した前記物理記憶ロケーションに対応する前記物理変更情報をリセットするステップと、
   を含む方法。
8. 請求項１ないし７のいずれか１項記載の方法において、前記物理記憶ロケーションは、物理情報ユニットで編成されており、前記物理変更情報は、少なくとも１つのビット・マップを含み、１つのビットが各物理情報ユニットに対応し、前記ステップ（Ｂ）は、前記少なくとも１つのビット・マップを検査し、前記基準時点以降に変化したデータを含む前記物理情報ユニットを識別するステップを含む方法。
9. 請求項１ないし７のいずれか１項記載の方法において、前記物理記憶ロケーションは、論理ボリューム単位で編成され、各々が複数のトラックを含み、前記物理変更情報は、各論理ボリュームに対するビット・マップを含み、各ビット・マップは、対応する論理ボリューム内の各トラックに対応するビットを含み、前記ステップ（Ｂ）は、前記論理ボリュームの少なくとも１つに対して前記ビット・マップを検査し、前記論理ボリュームの少なくとも１つの前記トラックの内、前記基準時点以降に変化したデータを含むものを識別するステップを含む方法。
10. 請求項１ないし９のいずれか１項記載の方法において、前記論理オブジェクトは、集合的に前記論理オブジェクトを形成する複数の論理ユニットを含み、前記ステップ（Ａ）は、前記論理オブジェクトに対応するデータを含む前記物理記憶ロケーションを、隣接する物理ロケーションの１つ以上のセグメントの集合体として識別するステップを含む、方法。
11. ホスト・コンピュータ上における実行のためにコンピュータ・プログラムをエンコードされたコンピュータ読み取り可能媒体であって、前記ホスト・コンピュータが、記憶システムに結合され、当該ホスト・コンピュータ上のアプリケーション・レイヤに属する論理オブジェクトを前記記憶システム上の物理記憶ロケーションに互いに関係する物理レイヤにマップする少なくとも１つのマッピング・レイヤを含み、前記物理レイヤは、基準時点以降に前記記憶システム上の前記物理記憶位置に対して行われた変更を示す物理変更情報を含み、前記ホスト・コンピュータは前記コンピュータ・プログラムに従って前記基準時点以降の論理オブジェクトに対する変更を判定する方法を実行し、該方法が、
    （Ａ）前記アプリケーション・レイヤから前記物理レイヤに前記論理オブジェクトをマップする前記少なくとも１つのマッピング・レイヤを用いて、どの物理記憶ロケーションが前記論理オブジェクトに対応するデータを含むか識別するステップと、
    （Ｂ）前記物理変更情報を用いて、前記ステップ（Ａ）において識別されたものの内、前記基準時点以降に変化したデータを含む物理記憶ロケーションを識別するステップと、
    （Ｃ）いずれかの物理記憶ロケーションが、前記ステップ（Ｂ）において前記基準時点以降に変化したデータを含むと識別された場合、変更が前記論理オブジェクトに対して行われたと判定するステップと、
    から成るコンピュータ読み取り可能媒体。
12. 請求項１１記載のコンピュータ読み取り可能媒体において、前記論理オブジェクトは、集合的に前記論理オブジェクトを形成する複数の論理ユニットを含み、前記方法は、更に、
    （Ｄ）前記ステップ（Ｂ）において識別された前記物理記憶ロケーションを前記アプリケーション・レイヤに照合し、前記複数の論理ユニットのどれが当該識別された前記物理記憶ロケーションに対応するか判定することにより、前記論理オブジェクトにおける前記複数の論理ユニットのどれが、前記基準時点以降に変化したデータを含むのか識別するステップを含む、
    コンピュータ読み取り可能媒体。
13. 請求項１１記載のコンピュータ読み取り可能媒体において、前記論理オブジェクトは、集合的に前記論理オブジェクトを形成する複数の論理ユニットを含み、前記方法は、更に、
    （Ｄ）前記基準時点において前記論理オブジェクトのコピーを作成するステップと、
    （Ｅ）前記ステップ（Ｂ）において識別した前記物理記憶ロケーションを前記アプリケーション・レイヤに照合し、前記論理オブジェクトの前記複数の論理ユニットのどれがそれに対応するかを判定することにより、前記論理オブジェクトにおける前記複数の論理ユニットのどれが、前記基準時点以降に変化したデータを含むのか識別するステップと、
    （Ｆ）変化したデータを含む前記論理オブジェクト内の論理ユニットを、前記論理オブジェクトのコピーにおける対応する論理ユニットと比較し、前記論理オブジェクトに対する変更が、前記論理オブジェクトのコピーに対比して前記論理オブジェクトの追加、削除、および修正のうちのどれであるのかを判定するステップと、
    を含むコンピュータ読み取り可能媒体。
14. 請求項１３記載のコンピュータ読み取り可能媒体において、変化したデータを含む前記論理オブジェクト内の論理ユニットは、各々、前記論理オブジェクトが前記アプリケーション・レイヤにおいて属するアプリケーションに関連する情報の数個のフィールドを含み、前記ステップ（Ｆ）は、変化したデータを含む前記論理オブジェクト内の論理ユニットを、前記論理オブジェクトのコピーにおける対応する論理ユニットと比較し、前記論理オブジェクトを形成する前記論理ユニットにおける前記数個の情報フィールドのどれが、前記基準時点以降に変化したか判定するステップを含むコンピュータ読み取り可能媒体。
15. 請求項１１ないし１４のいずれか１項記載のコンピュータ読み取り可能媒体において、前記記憶システムは、前記物理レイヤから、前記記憶システムに含まれる複数の記憶装置にマップする追加のマッピング・レイヤを含み、前記物理変更情報を前記物理レイヤにおいて与え、前記ステップ（Ａ）は、前記論理オブジェクトを前記アプリケーション・レイヤから前記物理レイヤのみにマップし、前記追加のマッピング・レイヤを通じて前記複数の記憶装置にはマップしない、ステップを含むコンピュータ読み取り可能媒体。
16. 請求項１１記載のコンピュータ読み取り可能媒体であって、更に、
    （Ｄ）前記基準時点において前記物理変更情報をリセットするステップ、
    を含むコンピュータ読み取り可能媒体。
17. 請求項１６記載のコンピュータ読み取り可能媒体において、前記ステップ（Ｄ）は、
    （Ｅ）前記論理オブジェクトを前記アプリケーション・レイヤから前記物理レイヤにマップする前記少なくとも１つのマッピング・レイヤを用いて、どの物理記憶ロケーションが前記論理オブジェクトに対応するデータを含むか識別するステップと、
    （Ｆ）前記ステップ（Ｅ）において識別した前記物理記憶ロケーションに対応する前記物理変更情報をリセットするステップと、
    を含むコンピュータ読み取り可能媒体。
18. 請求項１１ないし１７のいずれか１項記載のコンピュータ読み取り可能媒体において、前記物理記憶ロケーションは、物理情報ユニットで編成されており、前記物理変更情報は、少なくとも１つのビット・マップを含み、１つのビットが各物理情報ユニットに対応し、前記ステップ（Ｂ）は、前記少なくとも１つのビット・マップを検査し、前記基準時点以降に変化したデータを含む前記物理情報ユニットを識別するステップを含むコンピュータ読み取り可能媒体。
19. 請求項１１ないし１７のいずれか１項記載のコンピュータ読み取り可能媒体において、前記物理記憶ロケーションは、論理ボリューム単位で編成され、各々が複数のトラックを含み、前記物理変更情報は、各論理ボリュームに対するビット・マップを含み、各ビット・マップは、対応する論理ボリューム内の各トラックに対応するビットを含み、前記ステップ（Ｂ）は、前記論理ボリュームの少なくとも１つに対して前記ビット・マップを検査し、前記論理ボリュームの少なくとも１つの前記トラックの内、前記基準時点以降に変化したデータを含むものを識別するステップを含むコンピュータ読み取り可能媒体。
20. 請求項１１ないし１９のいずれか１項記載のコンピュータ読み取り可能媒体において、前記論理オブジェクトは、集合的に前記論理オブジェクトを形成する複数の論理ユニットを含み、前記ステップ（Ａ）は、前記論理オブジェクトに対応するデータを含む前記物理記憶ロケーションを、隣接する物理ロケーションの１つ以上のセグメントの集合体として識別するステップを含む、コンピュータ読み取り可能媒体。
21. 複数の物理記憶ロケーションを有する記憶システムと共に用いるホスト・コンピュータであって、
    前記ホスト・コンピュータ上のアプリケーション・レイヤに属する論理オブジェクトを、前記記憶システム上の前記複数の物理記憶ロケーションに互いに関係する物理レイヤにマップする少なくとも１つのマッピング・レイヤであって、前記物理レイヤが、基準時点以降に前記記憶システム上の前記複数の物理記憶ロケーションに対して行われた変更を示す物理変更情報を含む、マッピング・レイヤと、
    前記アプリケーション・レイヤから前記物理レイヤに論理オブジェクトをマップする前記少なくとも１つのマッピング・レイヤを用いて、前記複数の物理記憶ロケーションのどれが、前記論理オブジェクトに対応するデータを含むか識別する第１識別手段と、
    前記第１識別手段によって識別された、前記複数の物理記憶ロケーションに対応する前記物理変更情報を用いて、前記基準時点以降において前記論理オブジェクトに対して変更が行われたか否か識別する第２識別手段と、
    を備えるホスト・コンピュータ。
22. 請求項２１記載のホスト・コンピュータにおいて、前記第２識別手段は、
    前記第１識別手段によって識別された前記複数の物理記憶ロケーションのいずれかが、前記基準時点以降に変化したデータを含むとき、前記論理オブジェクトに対して変更が行われたと判定する手段を含む、
    ホスト・コンピュータ。
23. 請求項２１記載のホスト・コンピュータにおいて、前記第２識別手段は、
    前記第１識別手段によって識別された前記複数の物理記憶ロケーションに、前記基準時点以降に変化したデータを含むものがないとき、前記論理オブジェクトに対して変更が行われなかったと判定する手段を含む、
    ホスト・コンピュータ。
24. 請求項２１ないし２３のいずれか１項記載のホスト・コンピュータにおいて、前記論理オブジェクトは、集合的に前記論理オブジェクトを形成する複数の論理ユニットを含み、前記第２識別手段は、
    前記第１識別手段によって識別された前記複数の物理記憶ロケーションに対応する前記物理変更情報を用いて、前記論理オブジェクトを形成する前記複数の論理ユニットが前記基準時点以降変化したか否か識別する手段を含む、
    ホスト・コンピュータ。
25. 請求項２１ないし２３のいずれか１項記載のホスト・コンピュータにおいて、前記論理オブジェクトは、集合的に前記論理オブジェクトを形成する複数の論理ユニットを含み、前記ホスト・コンピュータは、更に、
    前記基準時点において前記論理オブジェクトをコピーする手段と、
    前記第１識別手段によって識別された前記複数の物理記憶ロケーションに対応する前記物理変更情報を用いて、前記論理オブジェクトを形成する前記複数の論理ユニットが前記基準時点以降に変化したか否か識別する手段と、
    変化したデータを含む前記論理オブジェクト内の前記論理ユニットを、前記論理オブジェクトのコピー内の対応する論理ユニットと比較し、前記論理オブジェクトに対する変更が、前記論理オブジェクトのコピーに対比して前記論理オブジェクトの追加、削除、および修正のうちのどれであるのかを判定する手段と、
    を更に備えるホスト・コンピュータ。
26. 請求項２５記載のホスト・コンピュータにおいて、変化したデータを含む前記論理オブジェクト内の前記論理ユニットは、各々、前記アプリケーション・レイヤにおいて前記論理オブジェクトが属するアプリケーションに関連する情報のフィールドを数個含み、前記比較する手段は、変化したデータを含む前記論理オブジェクト内の論理ユニットを、前記論理オブジェクトのコピーにおける対応する論理ユニットと比較し、前記論理オブジェクトを形成する前記論理ユニットにおける前記数個の情報フィールドのどれが、前記基準時点以降に変化したか判定する手段を含むホスト・コンピュータ。
27. 請求項２１ないし２６のいずれか１項記載のホスト・コンピュータにおいて、前記記憶システムは、前記物理レイヤから、前記記憶システムに含まれる複数の記憶装置にマップする追加のマッピング・レイヤを含み、前記物理変更情報は前記物理レイヤにおいて与えられ、前記第１識別手段は、前記追加のマッピング・レイヤを通じた前記複数の記憶装置への更なるマッピングを行なわずに、前記論理オブジェクトの前記アプリケーション・レイヤから前記物理レイヤのみへのマッピングを行う、ホスト・コンピュータ。
28. 請求項２１ないし２７のいずれか１項記載のホスト・コンピュータであって、更に、
    前記基準時点において前記物理変更情報をリセットする手段、
    を含むホスト・コンピュータ。
29. 請求項２８記載のホスト・コンピュータにおいて、前記リセットする手段は、
    前記基準時点において前記第１識別手段によって識別された前記物理記憶ロケーションに対応する前記物理変更情報をリセットする手段、
    を含むホスト・コンピュータ。
30. 請求項２１ないし２９のいずれか１項記載のホスト・コンピュータにおいて、前記物理記憶ロケーションは、物理情報ユニットで編成されており、前記物理変更情報は、少なくとも１つのビット・マップを含み、１つのビットが各物理情報ユニットに対応し、前記第２識別手段が、前記少なくとも１つのビット・マップを検査し、前記基準時点以降に変化したデータを含む前記物理情報ユニットを識別する、ホスト・コンピュータ。
31. 請求項２１ないし２９のいずれか１項記載のホスト・コンピュータにおいて、前記物理記憶ロケーションは、各々複数のトラックを含む論理ボリューム単位で編成され、前記物理変更情報は、各論理ボリュームに対するビット・マップを含み、各ビット・マップは、対応する論理ボリューム内の各トラックに対応するビットを含み、前記第２識別手段が、前記論理ボリュームの少なくとも１つに対して前記ビット・マップを検査し、前記論理ボリュームの少なくとも１つの前記トラックのいずれかが、前記基準時点以降に変化したデータを含むか否か識別する、ホスト・コンピュータ。
32. 請求項２１ないし３１のいずれか１項記載のホスト・コンピュータにおいて、前記論理オブジェクトは、集合的に前記論理オブジェクトを形成する複数の論理ユニットを含み、前記第１識別手段は、前記アプリケーション・レイヤの前記複数の論理ユニットから前記物理レイヤにマップするマッピング・レイヤを用いて、前記論理オブジェクトに対応するデータを含む前記物理記憶ロケーションを、隣接する物理ロケーションの１つ以上のセグメントの集合体として識別する、ホスト・コンピュータ。

Images