JP2002530741A

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

Info

Publication number: JP2002530741A
Application number: JP2000582895A
Authority: JP
Inventors: タマー，フィリップ・イー; リー，テリー・セト
Original assignee: イーエムシーコーポレーション
Priority date: 1998-11-19
Filing date: 1999-11-19
Publication date: 2002-09-17
Anticipated expiration: 2019-11-19
Also published as: US6385626B1; GB2359159A; DE19983713T1; WO2000029952A3; JP3866038B2; GB2359159B; HK1039665B; WO2000029952A9; GB0109796D0; WO2000029952A2; HK1039665A1

Abstract

(57)【要約】論理オブジェクトが格納されているデータ記憶システム内の物理レベルに関する情報を試験することによって、ホスト・コンピュータ上の論理オブジェクトに対する変更を識別する方法および装置。一実施形態では、基準時点以降の論理オブジェクトに対する変更を判定する方法を、コンピュータ・システムにおけるホスト・コンピュータのアプリケーション・レイヤに属する論理オブジェクトについて記載する。コンピュータ・システムは、ホスト・コンピュータ、記憶システム、および論理オブジェクトを記憶システム上の物理記憶ロケーションに関する物理レイヤにマップする少なくとも１つのマッピング・レイヤを含む。物理レイヤは、基準時点以降に記憶システム上の物理記憶ロケーションに対して行われた変更に関する物理変更情報を含む。この方法は、論理オブジェクトをアプリエーション・レイヤから物理レイヤにマップし、どの物理記憶ロケーションが、論理オブジェクトに対応するデータを含むか識別するステップと、物理変更情報を試験し、マップするステップにおいて識別された、基準時点以降に変化したデータを含む物理記憶ロケーションのいずれをも識別するステップと、試験するステップにおいて、基準時点以降に変化したデータを含むとして、いずれかの物理記憶ロケーションが識別された場合、論理オブジェクトに対して変更が行われたと判定するステップとを含む。

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 ... 以上、本発明のいくつかの実施形態を詳細に説明したが、種々の変更および改
良も当業者には容易に想起されよう。かかる変更および改良は、本発明の精神お
よび範囲内であることとする。したがって、前述の説明は一例に過ぎず、限定と
して意図したのではない。本発明は、特許請求の範囲およびその均等物によって
規定されるものとしてのみ限定されることとする。

【図面の簡単な説明】

【図１】本発明の態様を採用可能なコンピュータ・システムの機能ブロック図である。

【図２】ＯＲＡＣＬＥデータベース内にデータを格納する方法の構成図である。

【図３】論理オブジェクトの物理空間に対するマッピングを行なうマッピング・レイヤ
を有するコンピュータ・システムの構成図である。

【図４】本発明の一実施形態にしたがって、論理オブジェクトに対する変更の識別に用
いることができる識別ルーチンを示すフローチャートである。

【図５】図５（ａ）は、論理オブジェクトと、当該論理オブジェクトが物理空間のどこ
に格納されているかを示すマッピング情報との間の対応を示す図である。図５（ｂ）は、本発明の例示の一実施形態による物理レベルにおける変更情報
を示すために用いられるビットマップを示す図である。

【図６】本発明の一実施形態にしたがって、指定された論理オブジェクトに対応する物
理変更ビットをリセットするために、変更ＡＰＩが用いることができるステップ
を示すフローチャートである。

【図７】本発明の実施形態と共に用い、論理オブジェクトを物理空間にマップするため
に用いることができる、例示のマッピング・ルーチンのフローチャートである。

【図８】マッピング・レイヤおよびインテリジェント記憶装置を含むコンピュータ・シ
ステムの構成図である。

【図９】本発明の一態様にしたがってアプリケーション・プログラムのデバックを行な
うために実行することができるステップを示すフローチャートである。

【図１０】本発明の別の実施形態にしたがって、最少のダウンタイムで論理オブジェクト
を再編成するために用いることができる再編成ルーチンを示すフローチャートで
ある。

【図１１】ＯＲＡＣＬＥデータベースにおける行識別子を示す図である。

【図１２】本発明の別の実施形態にしたがって、データベース・オブジェクトの行または
レコードを識別し、特定のレコードに対応するデータを供給するルーチンを示す
フローチャートである。

【図１３】本発明の別の実施形態にしたがって、特定のデータベース・オブジェクトと連
携された行またはレコードを識別しダンプする際のフローチャートである。

【図１４】本発明の更に別の実施形態にしたがって、データベース・オブジェクトの特定
の論理ブロック内にある全ての行が含まれる、上側境界および下側境界を決定す
る際に用いることができる、上側境界および下側境界行識別ルーチンのフローチ
ャートである。

【手続補正書】特許協力条約第３４条補正の翻訳文提出書

【提出日】平成１２年２月１１日（２０００．２．１１）

【手続補正１】

【補正対象書類名】明細書

【補正対象項目名】発明の名称

【補正方法】変更

【補正内容】

【発明の名称】物理レベルにおける論理オブジェクトに対する変更に基づい
て、論理オブジェクトに対する変更を識別する方法および装置

【手続補正２】

【補正対象書類名】明細書

【補正対象項目名】０００１

【補正方法】変更

【補正内容】

【手続補正３】

【補正対象書類名】明細書

【補正対象項目名】０００２

【補正方法】変更

【補正内容】

【手続補正４】

【補正対象書類名】明細書

【補正対象項目名】０００３

【補正方法】変更

【補正内容】

【手続補正５】

【補正対象書類名】明細書

【補正対象項目名】０００４

【補正方法】変更

【補正内容】

【手続補正６】

【補正対象書類名】明細書

【補正対象項目名】００４９

【補正方法】変更

【補正内容】

【００４９】ステップ７１０において論理オブジェクトの所有権を判定した後、マッピング
・ルーチンはステップ７２０に進み、ルーチンは、指定された論理オブジェクト
と連携するマッピング・レイヤの数を識別する。論理オブジェクトが、ＵＮＩＸ
オペレーティング・システムを有するホスト・コンピュータ上に常駐するファイ
ル・システム内のファイルであるという前述の例では、ｄｆコマンドは、どのフ
ァイル・システムが指定の論理オブジェクトを所有するのかについて識別するだ
けでなく、更にどの論理デバイス上にファイル・システムが実装されているかに
ついても識別する。ファイル・システムの下にどのようなマッピング・レイヤが
存在するかに応じて、ファイル・システムに対して識別された論理デバイスは、
物理空間３３０内のロケーションに直接対応する論理ボリュームであったり、ま
たはＬＶＭ３２４のような更に別のマッピング・レイヤによってマップされる場
合もある。しかしながら、ファイル・システムが実装されている論理デバイスが
一旦識別されたなら、マッピング・ルーチンは、次に、ホスト・コンピュータ・
システム上に存在することがわかっているいずれかのＬＶＭに問い合わせを行い
、このＬＶＭが、識別された論理デバイスを下位レイヤにマップするか否か判定
を行なう。殆どのＬＶＭは、ユーザに、ＬＶＭに問い合わせを行い、指定された
論理デバイスがＬＶＭにはわかっているか否か判定させる。デバイスがＬＶＭに
わかっている場合、ＬＶＭは、論理デバイスがＬＶＭによってマップされた先の
論理ボリューム・アドレスを回答する。あるいは、ＬＶＭにはデバイスがわかっ
ていない場合、ＬＶＭは、回答する際、典型的に、その旨示し、ＬＶＭはファイ
ル・システムに対していずれのレベルのマッピングも行なわないことを示す。Ｌ
ＶＭの下に別のマッピング・レイヤがない場合、この論理ボリューム・アドレス
は物理空間内のロケーションに対応する。

【手続補正７】

【補正対象書類名】明細書

【補正対象項目名】００５０

【補正方法】変更

【補正内容】

【手続補正８】

【補正対象書類名】明細書

【補正対象項目名】００５１

【補正方法】変更

【補正内容】

【手続補正９】

【補正対象書類名】明細書

【補正対象項目名】００６５

【補正方法】変更

【補正内容】

【手続補正１０】

【補正対象書類名】明細書

【補正対象項目名】００６６

【補正方法】変更

【補正内容】

【手続補正１１】

【補正対象書類名】明細書

【補正対象項目名】００６７

【補正方法】変更

【補正内容】

【手続補正１２】

【補正対象書類名】明細書

【補正対象項目名】００６８

【補正方法】変更

【補正内容】

【手続補正１３】

【補正対象書類名】明細書

【補正対象項目名】００６９

【補正方法】変更

【補正内容】

【手続補正書】特許協力条約第３４条補正の翻訳文提出書

【提出日】平成１２年２月２７日（２０００．２．２７）

【手続補正１】

【補正対象書類名】明細書

【補正対象項目名】特許請求の範囲

【補正方法】変更

【補正内容】

【特許請求の範囲】

【手続補正２】

【補正対象書類名】明細書

【補正対象項目名】０１２３

【補正方法】変更

【補正内容】

【手続補正３】

【補正対象書類名】明細書

【補正対象項目名】０１２４

【補正方法】変更

【補正内容】

【手続補正４】

【補正対象書類名】明細書

【補正対象項目名】０１２５

【補正方法】変更

【補正内容】

【０１２５】 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

【特許請求の範囲】

【請求項１】基準時点以降の論理オブジェクトに対する変更を判定する方
法であって、前記論理オブジェクトは、ホスト・コンピュータ、記憶システム、
および前記論理オブジェクトを前記記憶システム上の物理記憶ロケーションに関
係する物理レイヤにマップする少なくとも１つのマッピング・レイヤを含むコン
ピュータ・システムにおけるホスト・コンピュータのアプリケーション・レイヤ
に属し、前記物理レイヤが、前記基準時点以降における前記記憶システム上の前
記物理記憶ロケーションに対して行われた変更に関係する物理変更情報を含み、
前記方法が、（Ａ）前記アプリケーション・レイヤから前記物理レイヤに前記論理オブジェ
クトをマップし、どの物理記憶ロケーションが前記論理オブジェクトに対応する
データを含むか識別するステップと、（Ｂ）前記物理変更情報を試験して、前記ステップ（Ａ）において識別された
、前記基準時点以降に変化したデータを含む物理記憶ロケーションのいずれをも
識別するステップと、（Ｃ）いずれかの物理記憶ロケーションが、前記ステップ（Ｂ）において前記
基準時点以降に変化したデータを含むと識別された場合、変更が前記論理オブジ
ェクトに対して行われたと判定するステップと、から成る方法。
【請求項２】請求項１記載の方法において、前記論理オブジェクトは、集
合的に前記論理オブジェクトを形成する複数の論理ユニットを含み、前記方法は
、更に、（Ｄ）前記ステップ（Ｂ）において識別された前記物理記憶ロケーションを前
記アプリケーション・レイヤにマップし、前記複数の論理ユニットのどれがそれ
に対応するか判定することにより、前記論理オブジェクトにおける前記複数の論
理ユニットのどれが、前記基準時点以降に変化したデータを含むのか識別するス
テップを含む、方法。
【請求項３】請求項１記載の方法において、前記論理オブジェクトは、集
合的に前記論理オブジェクトを形成する複数の論理ユニットを含み、前記方法は
、更に、（Ｄ）前記基準時点において前記論理オブジェクトのコピーを作成するステッ
プと、（Ｅ）前記ステップ（Ｂ）において識別した前記物理記憶ロケーションを、前
記アプリケーション・レイヤにマップし、前記論理オブジェクトの前記複数の論
理ユニットのどれがそれに対応するかを判定することにより、前記論理オブジェ
クトにおける前記複数の論理ユニットのどれが、前記基準時点以降に変化したデ
ータを含むのか識別するステップと、（Ｆ）変化したデータを含む前記論理オブジェクト内の論理ユニットを、前記
論理オブジェクトのコピーにおける対応する論理ユニットと比較し、前記論理オ
ブジェクトに対する変更の特性を判定するステップと、を含む方法。
【請求項４】請求項３記載の方法において、変化したデータを含む前記論
理オブジェクト内の論理ユニットは、各々、前記論理オブジェクトが前記アプリ
ケーション・レイヤにおいて属するアプリケーションに関連する情報の数個のフ
ィールドを含み、前記ステップ（Ｆ）は、変化したデータを含む前記論理オブジ
ェクト内の論理ユニットを、前記論理オブジェクトのコピーにおける対応する論
理ユニットと比較し、前記論理オブジェクトを形成する前記論理ユニットにおけ
る前記数個の情報フィールドのどれが、前記基準時点以降に変化したか判定する
ステップを含む方法。
【請求項５】請求項１記載の方法において、前記記憶システムは、前記物
理レイヤから前記記憶システムに含まれる複数の記憶装置にマップする追加のマ
ッピング・レイヤを含み、前記物理変更情報を前記物理レイヤにおいて与え、前
記ステップ（Ａ）は、前記論理オブジェクトを前記アプリケーション・レイヤか
ら前記物理レイヤのみにマップし、前記追加のマッピング・レイヤを通じて前記
複数の記憶装置にはマップしない、ステップを含む方法。
【請求項６】請求項１記載の方法であって、更に、（Ｄ）前記基準時点において前記物理変更情報をリセットするステップ、を含む方法。
【請求項７】請求項６記載の方法において、前記ステップ（Ｄ）は、（Ｅ）前記論理オブジェクトを前記アプリケーション・レイヤから前記物理レ
イヤにマップし、どの物理記憶ロケーションが前記論理オブジェクトに対応する
データを含むか識別するステップと、（Ｆ）前記ステップ（Ｅ）において識別した前記物理記憶ロケーションに対応
する前記物理変更情報をリセットするステップと、を含む方法。
【請求項８】請求項１記載の方法において、前記物理記憶ロケーションは
、物理情報ユニットで編成されており、前記物理変更情報は、少なくとも１つの
ビット・マップを含み、１つのビットが各物理情報ユニットに対応し、前記ステ
ップ（Ｂ）は、前記少なくとも１つのビット・マップを試験し、前記基準時点以
降に変化したデータを含む前記物理情報ユニットを識別するステップを含む方法
。
【請求項９】請求項１記載の方法において、前記物理記憶ロケーションは
、論理ボリューム単位で編成され、各々が複数のトラックを含み、前記物理変更
情報は、各論理ボリュームに対するビット・マップを含み、各ビット・マップは
、対応する論理ボリューム内の各トラックに対応するビットを含み、前記ステッ
プ（Ｂ）は、前記論理ボリュームの少なくとも１つに対して前記ビット・マップ
を試験し、前記基準時点以降に変化したデータを含む、前記論理ボリュームの少
なくとも１つの前記トラックのいずれもを識別するステップを含む方法。
【請求項１０】請求項１記載の方法において、前記論理オブジェクトは、
集合的に前記論理オブジェクトを形成する複数の論理ユニットを含み、前記ステ
ップ（Ａ）は、前記論理オブジェクトに対応するデータを含む前記物理記憶ロケ
ーションを、隣接する物理ロケーションの１つ以上のストリングの集合体として
識別するステップを含み、前記ストリングは、当該ストリングと、該ストリング
が対応する前記複数の論理ユニットとの間で対応を維持するように順序付けられ
る方法。
【請求項１１】ホスト・コンピュータ上における実行のためにコンピュー
タ・プログラムをエンコードされたコンピュータ読み取り可能媒体であって、前
記ホスト・コンピュータが、記憶システムに結合され、当該ホスト・コンピュー
タ上のアプリケーション・レイヤに属する論理オブジェクトを前記記憶システム
上の物理記憶ロケーションに関係する物理レイヤにマップする少なくとも１つの
マッピング・レイヤを含み、前記物理レイヤは、基準時点以降に前記記憶システ
ム上の前記物理記憶位置に対して行われた変更に関する物理変更情報を含み、前
記コンピュータ・プログラムは、前記ホスト・コンピュータ上で実行されたとき
に、前記基準時点以降の論理オブジェクトに対する変更を判定する方法を実行し
、該方法が、（Ａ）前記アプリケーション・レイヤから前記物理レイヤに前記論理オブジェ
クトをマップし、どの物理記憶ロケーションが前記論理オブジェクトに対応する
データを含むか識別するステップと、（Ｂ）前記物理変更情報を試験して、前記ステップ（Ａ）において識別された
、前記基準時点以降に変化したデータを含む物理記憶ロケーションのいずれをも
識別するステップと、（Ｃ）いずれかの物理記憶ロケーションが、前記ステップ（Ｂ）において前記
基準時点以降に変化したデータを含むと識別された場合、変更が前記論理オブジ
ェクトに対して行われたと判定するステップと、から成るコンピュータ読み取り可能媒体。
【請求項１２】請求項１１記載のコンピュータ読み取り可能媒体において
、前記論理オブジェクトは、集合的に前記論理オブジェクトを形成する複数の論
理ユニットを含み、前記方法は、更に、（Ｄ）前記ステップ（Ｂ）において識別された前記物理記憶ロケーションを前
記アプリケーション・レイヤにマップし、前記複数の論理ユニットのどれがそれ
に対応するか判定することにより、前記論理オブジェクトにおける前記複数の論
理ユニットのどれが、前記基準時点以降に変化したデータを含むのか識別するス
テップを含む、コンピュータ読み取り可能媒体。
【請求項１３】請求項１１記載のコンピュータ読み取り可能媒体において
、前記論理オブジェクトは、集合的に前記論理オブジェクトを形成する複数の論
理ユニットを含み、前記方法は、更に、（Ｄ）前記基準時点において前記論理オブジェクトのコピーを作成するステッ
プと、（Ｅ）前記ステップ（Ｂ）において識別した前記物理記憶ロケーションを、前
記アプリケーション・レイヤにマップし、前記論理オブジェクトの前記複数の論
理ユニットのどれがそれに対応するかを判定することにより、前記論理オブジェ
クトにおける前記複数の論理ユニットのどれが、前記基準時点以降に変化したデ
ータを含むのか識別するステップと、（Ｆ）変化したデータを含む前記論理オブジェクト内の論理ユニットを、前記
論理オブジェクトのコピーにおける対応する論理ユニットと比較し、前記論理オ
ブジェクトに対する変更の特性を判定するステップと、を含むコンピュータ読み取り可能媒体。
【請求項１４】請求項１３記載のコンピュータ読み取り可能媒体において
、変化したデータを含む前記論理オブジェクト内の論理ユニットは、各々、前記
論理オブジェクトが前記アプリケーション・レイヤにおいて属するアプリケーシ
ョンに関連する情報の数個のフィールドを含み、前記ステップ（Ｆ）は、変化し
たデータを含む前記論理オブジェクト内の論理ユニットを、前記論理オブジェク
トのコピーにおける対応する論理ユニットと比較し、前記論理オブジェクトを形
成する前記論理ユニットにおける前記数個の情報フィールドのどれが、前記基準
時点以降に変化したか判定するステップを含むコンピュータ読み取り可能媒体。
【請求項１５】請求項１１記載のコンピュータ読み取り可能媒体において
、前記記憶システムは、前記物理レイヤから、前記記憶システムに含まれる複数
の記憶装置にマップする追加のマッピング・レイヤを含み、前記物理変更情報を
前記物理レイヤにおいて与え、前記ステップ（Ａ）は、前記論理オブジェクトを
前記アプリケーション・レイヤから前記物理レイヤのみにマップし、前記追加の
マッピング・レイヤを通じて前記複数の記憶装置にはマップしない、ステップを
含むコンピュータ読み取り可能媒体。
【請求項１６】請求項１１記載のコンピュータ読み取り可能媒体であって
、更に、（Ｄ）前記基準時点において前記物理変更情報をリセットするステップ、を含むコンピュータ読み取り可能媒体。
【請求項１７】請求項１６記載のコンピュータ読み取り可能媒体において
、前記ステップ（Ｄ）は、（Ｅ）前記論理オブジェクトを前記アプリケーション・レイヤから前記物理レ
イヤにマップし、どの物理記憶ロケーションが前記論理オブジェクトに対応する
データを含むか識別するステップと、（Ｆ）前記ステップ（Ｅ）において識別した前記物理記憶ロケーションに対応
する前記物理変更情報をリセットするステップと、を含むコンピュータ読み取り可能媒体。
【請求項１８】請求項１１記載のコンピュータ読み取り可能媒体において
、前記物理記憶ロケーションは、物理情報ユニットで編成されており、前記物理
変更情報は、少なくとも１つのビット・マップを含み、１つのビットが各物理情
報ユニットに対応し、前記ステップ（Ｂ）は、前記少なくとも１つのビット・マ
ップを試験し、前記基準時点以降に変化したデータを含む前記物理情報ユニット
を識別するステップを含むコンピュータ読み取り可能媒体。
【請求項１９】請求項１１記載のコンピュータ読み取り可能媒体において
、前記物理記憶ロケーションは、論理ボリューム単位で編成され、各々が複数の
トラックを含み、前記物理変更情報は、各論理ボリュームに対するビット・マッ
プを含み、各ビット・マップは、対応する論理ボリューム内の各トラックに対応
するビットを含み、前記ステップ（Ｂ）は、前記論理ボリュームの少なくとも１
つに対して前記ビット・マップを試験し、前記基準時点以降に変化したデータを
含む、前記論理ボリュームの少なくとも１つの前記トラックのいずれもを識別す
るステップを含むコンピュータ読み取り可能媒体。
【請求項２０】請求項１１記載のコンピュータ読み取り可能媒体において
、前記論理オブジェクトは、集合的に前記論理オブジェクトを形成する複数の論
理ユニットを含み、前記ステップ（Ａ）は、前記論理オブジェクトに対応するデ
ータを含む前記物理記憶ロケーションを、隣接する物理ロケーションの１つ以上
のストリングの集合体として識別するステップを含み、前記ストリングは、当該
ストリングと、該ストリングが対応する前記複数の論理ユニットとの間で対応を
維持するように順序付けられるコンピュータ読み取り可能媒体。
【請求項２１】複数の物理記憶ロケーションを有する記憶システムと共に
用いるホスト・コンピュータであって、前記ホスト・コンピュータ上のアプリケーション・レイヤに属する論理オブジ
ェクトを、前記記憶システム上の前記複数の物理記憶ロケーションに関係する物
理レイヤにマップする少なくとも１つのマッピング・レイヤであって、前記物理
レイヤが、基準時点以降に前記記憶システム上の前記複数の物理記憶ロケーショ
ンに対して行われた変更に関する物理変更情報を含む、マッピング・レイヤと、前記少なくとも１つのマッピング・レイヤから、前記アプリケーション・レイ
ヤから前記物理レイヤへの論理オブジェクトのマッピングを判定し、前記複数の
物理記憶ロケーションのどれが、前記論理オブジェクトに対応するデータを含む
か識別する判定手段と、前記判定手段によって識別された前記複数の物理記憶ロケーションに対応する
前記物理変更情報を試験することにより、前記基準時点以降において前記論理オ
ブジェクトに対して変更が行われたか否か識別する手段と、を備えるホスト・コンピュータ。
【請求項２２】請求項２１記載のホスト・コンピュータにおいて、前記識
別する手段は、前記判定手段によって識別された前記複数の物理記憶ロケーションのいずれか
が、前記基準時点以降に変化したデータを含むとき、前記論理オブジェクトに対
して変更が行われたと判定する手段を含む、ホスト・コンピュータ。
【請求項２３】請求項２１記載のホスト・コンピュータにおいて、前記識
別する手段は、前記判定手段によって識別された前記複数の物理記憶ロケーションに、前記基
準時点以降に変化したデータを含むものがないとき、前記論理オブジェクトに対
して変更が行われなかったと判定する手段を含む、ホスト・コンピュータ。
【請求項２４】請求項２１記載のホスト・コンピュータにおいて、前記論
理オブジェクトは、集合的に前記論理オブジェクトを形成する複数の論理ユニッ
トを含み、前記識別する手段は、前記判定手段によって識別された前記複数の物理記憶ロケーションに対応する
前記物理変更情報を前記アプリケーション・レイヤにマップし、前記論理オブジ
ェクトを形成する前記複数の論理ユニットが前記基準時点以降変化したか否か識
別する手段を含む、ホスト・コンピュータ。
【請求項２５】請求項２１記載のホスト・コンピュータにおいて、前記論
理オブジェクトは、集合的に前記論理オブジェクトを形成する複数の論理ユニッ
トを含み、前記ホスト・コンピュータは、更に、前記基準時点において前記論理オブジェクトをコピーする手段と、前記判定手段によって識別された前記複数の物理記憶ロケーションに対応する
前記物理変更情報を、前記アプリケーション・レイヤにマップし、前記論理オブ
ジェクトを形成する前記複数の論理ユニットが前記基準時点以降に変化したか否
か識別する手段と、変化したデータを含む前記論理オブジェクト内の前記論理ユニットを、前記論
理オブジェクトのコピー内の対応する論理ユニットと比較し、前記論理オブジェ
クトに対する変更の特性を判定する手段と、を更に備えるホスト・コンピュータ。
【請求項２６】請求項２５記載のホスト・コンピュータにおいて、変化し
たデータを含む前記論理オブジェクト内の前記論理ユニットは、各々、前記アプ
リケーション・レイヤにおいて前記論理オブジェクトが属するアプリケーション
に関連する情報のフィールドを数個含み、前記比較する手段は、変化したデータ
を含む前記論理オブジェクト内の論理ユニットを、前記論理オブジェクトのコピ
ーにおける対応する論理ユニットと比較し、前記論理オブジェクトを形成する前
記論理ユニットにおける前記数個の情報フィールドのどれが、前記基準時点以降
に変化したか判定する手段を含むホスト・コンピュータ。
【請求項２７】請求項２１記載のホスト・コンピュータにおいて、前記記
憶システムは、前記物理レイヤから、前記記憶システムに含まれる複数の記憶装
置にマップする追加のマッピング・レイヤを含み、前記物理変更情報は前記物理
レイヤにおいて与えられ、前記判定手段は、前記追加のマッピング・レイヤを通
じた前記複数の記憶装置への更なるマッピングを行なわずに、前記論理オブジェ
クトの前記アプリケーション・レイヤから前記物理レイヤのみへのマッピングを
判定する、ホスト・コンピュータ。
【請求項２８】請求項２１記載のホスト・コンピュータであって、更に、前記基準時点において前記物理変更情報をリセットする手段、を含むホスト・コンピュータ。
【請求項２９】請求項２８記載のホスト・コンピュータにおいて、前記リ
セットする手段は、前記基準時点において前記判定手段によって識別された前記物理記憶ロケーシ
ョンに対応する前記物理変更情報をリセットする手段、を含むホスト・コンピュータ。
【請求項３０】請求項２１記載のホスト・コンピュータにおいて、前記物
理記憶ロケーションは、物理情報ユニットで編成されており、前記物理変更情報
は、少なくとも１つのビット・マップを含み、１つのビットが各物理情報ユニッ
トに対応し、前記識別する手段が、前記少なくとも１つのビット・マップを試験
し、前記基準時点以降に変化したデータを含む前記物理情報ユニットを識別する
、ホスト・コンピュータ。
【請求項３１】請求項２１記載のホスト・コンピュータにおいて、前記物
理記憶ロケーションは、各々複数のトラックを含む論理ボリューム単位で編成さ
れ、前記物理変更情報は、各論理ボリュームに対するビット・マップを含み、各
ビット・マップは、対応する論理ボリューム内の各トラックに対応するビットを
含み、前記識別する手段が、前記論理ボリュームの少なくとも１つに対して前記
ビット・マップを試験し、前記論理ボリュームの少なくとも１つの前記トラック
のいずれかが、前記基準時点以降に変化したデータを含むか否か識別する、ホス
ト・コンピュータ。
【請求項３２】請求項２１記載のホスト・コンピュータにおいて、前記論
理オブジェクトは、集合的に前記論理オブジェクトを形成する複数の論理ユニッ
トを含み、前記判定手段は、前記複数の論理ユニットの前記物理レイヤへのマッ
ピングを判定し、前記論理オブジェクトに対応するデータを含む前記物理記憶ロ
ケーションを、隣接する物理ロケーションの１つ以上のストリングの集合体とし
て識別し、前記ストリングが、当該ストリングと、該ストリングが対応する前記
複数の論理ユニットとの間で対応を維持するように順序付けられる、ホスト・コ
ンピュータ。
【請求項３３】ホスト・コンピュータと共に用いる記憶システムであって
、前記ホスト・コンピュータが、当該ホスト・コンピュータ上のアプリケーショ
ン・レイヤに属する論理オブジェクトを、少なくとも１つの記憶ボリュームを含
む物理レイヤにマップする少なくとも１つのマッピング・レイヤを有し、前記記
憶システムが、前記少なくとも１つの記憶ボリュームに含まれるデータを格納する少なくとも
１つの記憶装置と、前記記憶システム上の少なくとも１つの記憶ボリュームに関する変更情報を記
憶するメモリであって、前記変更情報が、基準時点以降に前記少なくとも１つの
記憶ボリュームに対して変更が行われたか否か識別する、メモリと、前記アプリケーション・レイヤから前記論理オブジェクトに対応するデータを
含む前記少なくとも１つの記憶ボリュームへの前記論理オブジェクトのマッピン
グを、前記ホスト・コンピュータから受信する手段と、前記論理オブジェクトに対応するデータを含む前記少なくとも１つの記憶ボリ
ュームに関する前記変更情報を試験することによって、前記基準時点以降に前記
論理オブジェクトに変更が行われたか否か判定する手段と、を備える記憶システム。
【請求項３４】請求項３３記載の記憶システムにおいて、前記判定する手
段は、前記論理オブジェクトに対応するデータのいずれかが前記基準時点以降に変化
したデータを含む場合、前記論理オブジェクトに対して変更が行われたと識別す
る手段を含む、記憶システム。
【請求項３５】請求項３３記載の記憶システムにおいて、前記判定する手
段は、前記論理オブジェクトに対応するデータに、前記基準時点以降に変化したデー
タを含むものがない場合、前記論理オブジェクトに対して変更が行われなかった
と識別する手段を含む、記憶システム。
【請求項３６】請求項３３記載の記憶システムにおいて、前記メモリは、
前記少なくとも１つの記憶ボリュームに含まれる情報ユニットに関して、前記変
更情報を格納する、記憶システム。
【請求項３７】請求項３６記載の記憶システムにおいて、前記変更情報は
少なくとも１つのビット・マップを含み、１つのビットが前記少なくとも１つの
記憶ボリュームに含まれる各情報ユニットに対応し、前記判定する手段が、前記
少なくとも１つのビット・マップを試験し、前記情報ユニットが、前記基準時点
以降に変化したデータを含むか否か識別する、記憶システム。
【請求項３８】請求項３３記載の記憶システムにおいて、更に、前記基準時点において前記変更情報をリセットする手段を備える、記憶システム。
【請求項３９】請求項３８記載の記憶システムにおいて、前記メモリは、
前記少なくとも１つの記憶装置に格納されている情報ユニットに関して前記変更
情報を格納し、前記リセットする手段は、前記論理オブジェクトに対応するデータを含む情報ユニットに対応する前記変
更情報をリセットする手段を含む、記憶システム。
【請求項４０】請求項３３記載のデータ記憶システムにおいて、前記少な
くとも１つの記憶ボリュームは、前記ホスト・コンピュータが、前記データ記憶
システム内に物理記憶装置を構成するものとして認めた論理ボリュームを含み、
前記記憶システムは、更に、前記少なくとも１つの記憶ボリュームを前記少なくとも１つの記憶装置にマッ
プする追加のマッピング・レイヤを備える、データ記憶システム。
【請求項４１】請求項３３記載のデータ記憶システムであって、更に、前記ホスト・コンピュータに、前記基準時点に、前記論理オブジェクトに変更
が行われたか否かについての指示を与える手段を備える、データ記憶システム。
【請求項４２】請求項４１記載のデータ記憶システムにおいて、前記論理
オブジェクトは、集合的に前記論理オブジェクトを形成する複数の論理ユニット
を含み、前記与える手段は、前記論理オブジェクトを集合的に形成する前記複数
の論理ユニットの各々に対して変更が行われたか否かについての指示を、前記ホ
スト・コンピュータに与える、データ記憶システム。
【請求項４３】請求項４２記載のデータ記憶システムにおいて、前記受信
する手段は、前記論理ユニットのマッピングを前記ホスト・コンピュータからあ
る順序で受信し、前記与える手段は、前記ホスト・コンピュータに、前記順序で
、前記論理オブジェクトを集合的に形成する前記複数の論理ユニットの各々に対
して変更が行われたか否かの指示を与える、データ記憶システム。