JP4393762B2 - データベース処理方法及び装置並びにその処理プログラム - Google Patents
データベース処理方法及び装置並びにその処理プログラム Download PDFInfo
- Publication number
- JP4393762B2 JP4393762B2 JP2002368688A JP2002368688A JP4393762B2 JP 4393762 B2 JP4393762 B2 JP 4393762B2 JP 2002368688 A JP2002368688 A JP 2002368688A JP 2002368688 A JP2002368688 A JP 2002368688A JP 4393762 B2 JP4393762 B2 JP 4393762B2
- Authority
- JP
- Japan
- Prior art keywords
- database
- log information
- host computer
- log
- subsystem
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/2097—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements maintaining the standby controller/processing unit updated
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1471—Saving, restoring, recovering or retrying involving logging of persistent data for recovery
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
- G06F11/2094—Redundant storage or storage space
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99941—Database schema or data structure
- Y10S707/99944—Object-oriented database structure
- Y10S707/99945—Object-oriented database structure processing
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99941—Database schema or data structure
- Y10S707/99948—Application of database or data structure, e.g. distributed, multimedia, or image
Description
【０００１】
【発明の属する技術分野】
本発明はホストコンピュータと記憶装置サブシステムとを接続してデータベース処理を行うデータベース処理システムに関し、特にホストコンピュータのデータベース処理の内容を示すログ情報により、記憶装置サブシステム内のデータベースにデータベース処理内容を反映するデータベース処理システムに適用して有効な技術に関するものである。
【０００２】
【従来の技術】
従来のデータベース管理システムでは、ホストコンピュータ上と記憶装置サブシステムとの間でデータベースブロック及びログブロックの入出力を行っている。すなわち、データベース管理システムが入出力の効率を向上させる為にホストコンピュータのメインメモリ上にデータベースのバッファを設定し、当該バッファ上に記憶装置（メインメモリと比較して低速で大容量の磁気ディスク装置等の記憶装置を指すものとする）から入力したデータベースブロックをキャッシングすることによって、できるだけ記憶装置からの入出力を削減している。
【０００３】
この様なデータベース管理システムでは、データの更新処理については、予めデータベースバッファ上に入力したデータベースブロックに対して行い、その際の更新履歴情報をログ専用のバッファにログとして書き出した後、トランザクションの決着時にそのログを記憶装置に強制出力することによって整合性を保証している。その際、データベースブロックの記憶装置への反映（書き込み）では、当該ブロックに対して行った更新履歴ログを先行して記憶装置に出力する、所謂ＷＡＬ（Ｗｒｉｔｅ Ａｈｅａｄ Ｌｏｇ）を遵守する必要がある。
【０００４】
また、データベース管理システムでは、障害に備え、定期的にＤＢの整合性を保証する為、稼動中にチェックポイントを取得する。チェックポイントは、システム障害時の再開始処理を行う起点となるデータベースの整合性が保証されたポイントとなる。主にチェックポイントは稼動中に出力したログブロック数がある一定の回数に達した時点に取得する場合が多い。チェックポイント処理では、その時点のデータベースバッファ上の更新が行われたデータベースブロックを記憶装置上に全て書き出す処理が行われる（例えば非特許文献１参照）。
【０００５】
【非特許文献１】
ジム・グレイ(Jim Gray)、アンドレアス・ロイター(Andreas Reuter)著、「トランザクション・プロセッシング：コンセプト・アンド・テクニック(TRANSACTION PROCESSING:CONCEPTS AND TECHNIQUES)」（米国）、第1版、モーガン・カウフマン・パブリッシャー(MORGAN KAUFMAN PUBLISHERS)社発行、1993年、pp.556-557、pp.604-609
【０００６】
【発明が解決しようとする課題】
従来のデータベース管理システムにおけるデータベースブロックの記憶装置への書き込み方法では、前記の様にデータベースバッファ上の更新が行われたデータベースブロックを記憶装置上に全て書き出す処理が行われるが、更新が行われたデータベースブロック中には更新の行われていないレコードも含まれている為、必要の無い入出力も発生し、ホストコンピュータと記憶装置サブシステムとの間の入出力処理に大きな負荷がかかるという問題がある。
【０００７】
本発明の目的は上記問題を解決し、ホストコンピュータのバッファ上で行われたデータベース処理の内容を記憶装置サブシステム上のデータベース領域へ反映させる際に、ホストコンピュータと記憶装置サブシステムとの間の入出力処理負荷を低減させることが可能な技術を提供することにある。
【０００８】
本発明の他の目的は、ホストコンピュータの障害回復処理時に記憶装置サブシステムのキャッシュメモリ上に上記データベースの反映データが格納されているため、上記回復処理を高速に実行することができる技術を提供することにある。
【０００９】
本発明の他の目的はホストコンピュータのバッファ上で行われたデータベース処理の内容をログ情報によって記憶装置サブシステム上のデータベース領域へ反映させる際に、不要な入出力処理を省略することが可能な技術を提供することにある。
【００１０】
本発明の他の目的はホストコンピュータのバッファ上で行われたデータベース処理の内容をログ情報によって記憶装置サブシステム上のデータベース領域へ反映させる際に、その処理を効率的に行うことが可能な技術を提供することにある。
【００１１】
本発明の他の目的は複数台の記憶装置サブシステムにデータベース領域を配置している大規模なデータベース処理システムで、ホストコンピュータのバッファ上で行われたデータベース処理の内容を記憶装置サブシステム上のデータベース領域へ反映させる際にも、ホストコンピュータと記憶装置サブシステムとの間の入出力処理負荷を低減させることが可能な技術を提供することにある。
【００１２】
【課題を解決するための手段】
本発明は、ホストコンピュータのバッファ上で行われたデータベース処理の内容を記憶装置上のデータベースに反映させる処理を行うデータベース処理システムにおいて、ホストコンピュータで行われたデータベース処理の内容を示すログ情報に従って記憶装置サブシステム上のデータベース領域のデータへデータベース処理内容を反映するものである。
【００１３】
本発明のデータベース処理システムでは、記憶装置サブシステム内のデータベース領域の内容を一時的に保持するデータベースバッファと、データベースバッファに対する更新処理の内容を一時的に保持するログバッファとをホストコンピュータに備えており、ホストコンピュータでのデータベース処理の実行に伴ってデータベースバッファの内容が変更され、その変更内容を記憶装置サブシステム内のデータベース領域に反映させる必要が生じた場合には、データベースバッファ上で行われた更新処理の内容を示すログ情報の記憶装置サブシステムへの書き込みを要求するアクセス要求をホストコンピュータから記憶装置サブシステムへ送信する。
【００１４】
記憶装置サブシステムでは、前記アクセス要求をホストコンピュータから受信し、その受信したアクセス要求が書き込み要求または読み込み要求のいずれであるかを判定する。そして、その受信したアクセス要求が書き込み要求である場合には、その書き込み内容がホストコンピュータで行われたデータベース処理の内容を示すログ情報であるかどうかを判定する。
【００１５】
前記判定の結果、その書き込み内容が前記ログ情報である場合には、ホストコンピュータ側のデータベース処理で認識している論理的な位置情報と記憶装置サブシステム上の物理的な位置情報との対応関係を示す変換テーブルを参照し、前記ログ情報中に示された位置情報を記憶装置サブシステム上の物理的な位置情報に変換した後、その変換した物理的な位置情報で表される記憶装置サブシステム上のデータベース領域のデータを前記ログ情報の内容に従って更新する。
【００１６】
そのときに、記憶装置サブシステムのキャッシュメモリに当該反映対象データが格納されている場合には、キャッシュメモリに格納されている当該反映対象データを反映する。キャッシュメモリに格納されていない場合は、キャッシュメモリに反映対象データをアップロードし、その後、上記反映対象データをキャッシュメモリに格納する。
【００１７】
またホストコンピュータは、データベースバッファ中にデータベース処理でアクセス対象となっているデータが存在していない場合に、当該データの読み込み要求をホストコンピュータから記憶装置サブシステムへ送信し、記憶装置サブシステムは、ホストコンピュータから受信したアクセス要求が読み込み要求である場合には、それ以前の書き込み要求で受信したログ情報中に、読み込み対象のデータを更新するログ情報が含まれているかどうかを判定し、そのログ情報中に読み込み対象のデータを更新するログ情報が含まれている場合には、読み込み対象のデータを当該ログ情報の内容に従って更新してホストコンピュータ側へ送信する。
【００１８】
前記の様に本発明では、データベースバッファの内容を記憶装置サブシステム内のデータベース領域に反映させる必要が生じた場合に、更新処理の行われたレコードを１つでも含むデータベースブロック全てをホストコンピュータから記憶装置サブシステムへ送信するのではなく、データベースバッファに対する更新処理の内容を示すログ情報をホストコンピュータから記憶装置サブシステムへ送信するので、ホストコンピュータと記憶装置サブシステムとの間で送信されるデータ量を減少させることができる。
【００１９】
以上の様に本発明のデータベース処理システムによれば、ホストコンピュータのバッファ上で行われたデータベース処理の内容を示すログ情報に従って記憶装置サブシステム上のデータベース領域のデータを更新するので、ホストコンピュータのバッファ上で行われたデータベース処理の内容を記憶装置サブシステム上のデータベース領域へ反映させる際に、ホストコンピュータと記憶装置サブシステムとの間の入出力処理負荷を低減させることが可能である。
【００２０】
【発明の実施の形態】
（実施形態１）
以下にホストコンピュータのバッファ上で行われたデータベース処理の内容をディスクサブシステムの磁気ディスク装置上のデータベースに反映させる処理を行う実施形態１のデータベース処理システムについて説明する。
【００２１】
図１は本実施形態のデータベース処理システムのシステム構成を示す図である。図１に示す様に本実施形態のホストコンピュータ１はデータベース管理処理部１０を有している。データベース管理処理部１０は、ホストコンピュータ１のＤＢバッファ１２の内容をディスクサブシステム２内の磁気ディスク装置へ反映させる必要が生じた場合に、そのＤＢバッファ１２に対して行われたデータベース処理の内容を示すログ情報であるログブロック２６２ａの書き込み要求をホストコンピュータ１からディスクサブシステム２へ送信し、ＤＢバッファ１２中にデータベース処理でアクセス対象となっているデータが存在していない場合に当該データの読み込み要求をホストコンピュータ１からディスクサブシステム２へ送信する処理部である。
【００２２】
ホストコンピュータ１をデータベース管理処理部１０として機能させる為のプログラムは、ＣＤ−ＲＯＭ等の記録媒体に記録され磁気ディスク等に格納された後、メモリにロードされて実行されるものとする。なお前記プログラムを記録する記録媒体はＣＤ−ＲＯＭ以外の他の記録媒体でも良い。また前記プログラムを当該記録媒体から情報処理装置にインストールして使用しても良いし、ネットワークを通じて当該記録媒体にアクセスして前記プログラムを使用するものとしても良い。
またディスクサブシステム２は、ディスク制御処理部２１と、ディスクアクセス制御部２３と、更新処理部３０とを有している。
【００２３】
ディスク制御処理部２１は、ホストコンピュータ１から送信されたアクセス要求を受信し、その受信したアクセス要求が書き込み要求または読み込み要求のいずれであるかを判定する処理や、ディスクサブシステム装置全体の動作を制御する制御処理部である。
【００２４】
ディスクアクセス制御部２３は、ディスクサブシステム２配下の各磁気ディスク装置へのアクセスを制御する処理部である。更新処理部３０は、前記受信したアクセス要求が書き込み要求である場合に、その書き込み内容がホストコンピュータ１のＤＢバッファ１２上で行われたデータベース処理の内容を示すログ情報であるかどうかを判定し、前記書き込み内容が前記ログ情報である場合に、ホストコンピュータ１側のデータベース処理で認識している論理的な位置情報とディスクサブシステム２上の物理的な位置情報との対応関係を示すＤＢ−ディスクブロック変換テーブル２８によって、前記ログ情報中に示された位置情報をディスクサブシステム２上の物理的な位置情報に変換し、その変換した物理的な位置情報で表されるディスクサブシステム２上のデータベース領域２４のデータを前記ログ情報の内容に従って更新する処理部である。
【００２５】
ディスクサブシステム２を、ディスク制御処理部２１、ディスクアクセス制御部２３及び更新処理部３０として機能させる為のプログラムは、フロッピーディスク等の記録媒体に記録されて実行されるものとする。なお前記プログラムを記録する記録媒体はフロッピーディスク以外の他の記録媒体でも良い。また前記プログラムを当該記録媒体から情報処理装置にインストールして使用しても良いし、ネットワークを通じて当該記録媒体にアクセスして前記プログラムを使用するものとしても良い。
【００２６】
本実施形態のホストコンピュータ１とディスクサブシステム２は、ストレージエリアネットワーク１６で接続されている。
ホストコンピュータ１では、データベース管理処理部１０が稼動し、ホストコンピュータ１は、ディスクサブシステム２内のデータベース領域２４の内容を一時的に保持するＤＢバッファ１２と、ＤＢバッファ１２に対する更新処理の内容を一時的に保持するログバッファ１４とを備えている。
【００２７】
ディスクサブシステム２では、ホストコンピュータ１からの命令を受けて動作するディスク制御処理部２１と、キャッシュメモリ２２と、ディスクアクセス制御部２３とを通して磁気ディスク装置上のデータベース領域２４へのアクセスが行われており、ディスクアクセスは常にキャッシュメモリ２２を介して行われることになる。
【００２８】
本実施形態では、ホストコンピュータ１上のデータベース管理処理部１０で動作するトランザクションによって更新されたデータの更新履歴情報であるログ情報がログブロック２６２ａに書き込まれ、トランザクションの決着時等、ＤＢバッファ１２の内容をディスクサブシステム２へ反映させる必要が生じた場合に、ログブロック２６２ａがディスクサブシステム２に書き込まれる。
【００２９】
本実施形態の更新処理部３０は、データの書き込みが行われると、そのデータがログブロック２６２ａであるかどうかを判定し、ディスクサブシステム２上でデータベースブロック２４２ａの書き込みを制御する。
【００３０】
すなわち更新処理部３０は、ディスクサブシステム２が受け付けたコマンドを解析し、ログブロック２６２ａの書き込み要求であれば、キャッシュメモリ２２上に書き込んだログブロック２６２ａを解析し、ログブロック２６２ａ中のログレコードから該当するデータベース領域２４のデータベースブロック２４２ａをキャッシュメモリ２２上にアップロードし、ログの内容を反映する処理を行う。
【００３１】
このとき反映されるデータベースブロック２４２ａは、ログブロック２６２ａ中のログレコードではホストコンピュータ１上のデータベース管理処理部１０が認識できる論理的な位置情報で表されている為、この論理的な位置情報をディスクサブシステム２上の物理的な位置情報にマッピングする必要がある。そこで、この処理をＤＢ−ディスクブロック変換テーブル２８を用いて行う。ＤＢ−ディスクブロック変換テーブル２８は、一般的にはＤＢ構築時にホストコンピュータ１上のデータベース管理処理部１０から作成されることになる。
【００３２】
図２は本実施形態のＤＢ−ディスクブロック変換テーブル２８の構成情報を示す図である。図２に示す様にＤＢ−ディスクブロック変換テーブル２８は、データベース領域２４を識別する為の情報であるデータベース領域ＩＤと、そのデータベース領域ＩＤで識別されるデータベース領域が複数のファイルで構成される場合のファイルの順序番号を示すファイルＩＤと、前記データベース領域を構成するブロックの長さを示すブロック長と、前記データベース領域の構成ファイルが確保されている論理ボリュームを識別する為の情報である論理ボリュームＩＤと、その論理ボリュームＩＤで識別される論理ボリュームがマッピングされているディスクサブシステムを識別する為の番号であるディスク制御装置番号と、そのディスク制御装置番号で識別されるディスクサブシステムの磁気ディスク装置の内で、前記論理ボリュームがマッピングされている磁気ディスク装置のドライブ番号を識別する為の情報である物理デバイスＩＤと、その物理デバイスＩＤで識別される磁気ディスク装置上での当該ファイルの相対的な位置を示す相対位置とを格納している。
【００３３】
データベース領域２４を構成するファイルは、ホストコンピュータ１上のオペレーティングシステムが認識するファイルシステムとして論理ボリュームにマッピングされる。更に、論理ボリュームは、ディスクサブシステム２の物理デバイスである磁気ディスク装置に対応したデバイスファイルとしてマッピングされる。
【００３４】
ディスクサブシステム２内では、前記デバイスファイルは、ＬＵ（Ｌｏｇｉｃａｌ Ｕｎｉｔ）に対応している。従って、データベース領域２４を構成するファイルは、最終的に物理デバイスである磁気ディスク装置にマッピングされる。対応する物理情報は、ディスクサブシステム２上の物理デバイスを識別する為の物理デバイスＩＤと、物理デバイス内の相対位置であるＬＢＡ（ＬｏｇｉｃａｌＢｌｏｃｋ Ａｄｄｒｅｓｓ）である。
【００３５】
図３は本実施形態のホストコンピュータ上で認識されるデータベース領域と、オペレーティングシステムが認識する論理ボリュームと、デバイスファイル及びディスクサブシステム内のＬＵへのマッピング関連の例を示す図である。図３に示す様にデータベース管理処理部１０では、データを格納するデータベース領域は、複数のファイルから構成されるものとして認識されている。構成する各ファイルは、ホストコンピュータ１上のオペレーティングシステムのファイルに対応しており、図３ではオペレーティングシステムにおいてＲＡＷデバイスとして認識されるケースを想定している。更に、オペレーティングシステムのファイルは、物理的な磁気ディスク装置に対応するデバイスファイルとして管理されており、そのデバイスファイルは、前述した様にディスクサブシステム２内の各々の磁気ディスク装置に対応するＬＵにマッピングされている。
【００３６】
次に図４から図７に示す流れ図を用いてホストコンピュータ１上のデータベース管理処理部１０からログバッファ１４中のログブロック２６２ａのディスクサブシステム２への書き込みを要求するアクセス要求の処理について説明する。始めに、図４を用いて処理の概要を示す。
【００３７】
図４は本実施形態の受信コマンド解析処理の処理手順を示すフローチャートである。図４に示した処理は、ディスクサブシステム２内のプロセッサによって実行されるディスク制御処理部２１の処理として実現されるものであり、ホストコンピュータ１からのアクセス要求を受領したディスクサブシステム２は、始めに受領コマンドの解析処理を行う（ステップ３００）。接続チャネルのプロトコルに従ってコマンドを解析することで、アクセス要求がＲＥＡＤコマンドであるかＷＲＩＴＥコマンドであるかを識別できるものとする。
【００３８】
ステップ３２０でディスク制御処理部２１は、受領コマンドがＷＲＩＴＥコマンドであるかを判定し、ＷＲＩＴＥコマンドである場合にはＷＲＩＴＥコマンド処理を行う（ステップ３４０）。また、ＲＥＡＤコマンドである場合にはＲＥＡＤコマンド処理（ステップ３６０）を行う。
【００３９】
図５は本実施形態のＷＲＩＴＥコマンド受領時の処理手順を示すフローチャートである。図５の様に更新処理部３０は、ディスク制御処理部２１からコマンドを受領すると、受信コマンドからコマンド種類とアクセス先アドレスを解析し、ＷＲＩＴＥコマンドであることを認識する（ステップ３４１）。ここで、アクセス先アドレスからは、複数のディスクサブシステムやその各磁気ディスク装置に割り当てられているアドレスを示す装置構成管理テーブルの情報との比較を行うことにより、アクセス要求先のディスク制御装置番号とドライブ番号を識別することができるものとする。
【００４０】
次に、ステップ３４１で解析したアクセス先アドレスのデータが、ディスクサブシステム２のキャッシュメモリ２２に保持されているかどうかを調べ、キャッシュヒットミス判定を行う（ステップ３４２）。
【００４１】
アクセス先データがキャッシュメモリ２２に保持されていないキャッシュミスの場合には、前記の様にアクセス要求先のドライブ番号を識別し、ディスクサブシステム２のディスクアクセス制御部２３に対してそのドライブ番号に対応する磁気ディスク装置からキャッシュメモリ２２ヘの転送依頼を行う（ステップ３４３）。この場合、転送終了までＷＲＩＴＥ処理を中断し（ステップ３４４）、転送処理終了後、再度ＷＲＩＴＥ処理を継続する。また、転送先のキャッシュアドレスはキャッシュの空きリスト等、一般的な方法で管理、取得すれば良いが、転送先アドレスについては、キャッシュ管理テーブルを更新することで登録する必要がある。
【００４２】
ステップ３４２でキャッシュヒットの判定の場合、またはステップ３４４で転送処理が終了した場合には、ディスクサブシステム２内のキャッシュメモリ２２に対して当該データの更新を行う（ステップ３４５）。すなわち、ホストコンピュータ１から受領したデータの内容を書き込む。
【００４３】
データの更新が終了した後、前記アクセス先アドレスがログ用ディスク２６内のアドレスであるかどうかを調べて当該データがデータベース処理のログ用ディスク２６のデータであるかを判定し（ステップ３４６）、書き込み内容がログ用ディスク２６へのデータ、すなわちログブロックである場合には、そのログブロックの内容に従って該当するデータベース領域２４のデータベースブロックヘのログ追跡処理を行う（ステップ３４７）。
【００４４】
ログ追跡処理が完了するか、ステップ３４６の判定でログブロックではないと判定された場合、ホストコンピュータ１に対してＷＲＩＴＥコマンド処理の完了報告を行う（ステップ３４８）。
【００４５】
図６は本実施形態のログ追跡処理の処理手順を示すフローチャートである。ログブロックは複数のログレコードの集まりである。従って、図６に示す様にログブロックに含まれるログレコードについて順次、処理を行っていく。
【００４６】
まず更新処理部３０は、ログレコードのログ情報がトランザクションの開始処理、ＣＯＭＭＩＴまたはＲＯＬＬＢＡＣＫといった決着処理を示す情報であるかを判定する（ステップ４０１）。
【００４７】
当該ログレコードがトランザクションの状態変更ログではない場合には、更にデータベースの更新履歴を示すトランザクション更新ログであるかを判定する（ステップ４０２）。
【００４８】
当該ログレコードがトランザクション更新ログである場合には、図２に示したＤＢ−ディスクブロック変換テーブル２８を参照し、ログレコード中に記録されたログ情報に含まれているデータベース領域ＩＤ、ファイルＩＤ、ページ番号から、対応する物理ディスクのディスク制御装置番号とドライブ番号とページ番号を識別する（ステップ４０３）。すなわち、当該ログ情報に含まれているデータベース領域ＩＤ及びファイルＩＤに一致するレコードを、ＤＢ−ディスクブロック変換テーブル２８から検索して該当するディスク制御装置番号、ドライブ番号及び相対位置を求めた後、その相対位置がファイルの先頭であるものとして、当該ログ情報のページ番号を物理ディスク上のページ番号に変換する。
【００４９】
次にステップ４０３で前記の様に識別したデータがキャッシュメモリ２２に保持されているかどうかを調べてキャッシュヒットミス判定を行う（ステップ４０４）。当該データがキャッシュメモリ２２に保持されていないキャッシュミスの場合には、ディスクアクセス制御部２３に対して当該データベースブロックのドライブからキャッシュメモリ２２ヘの転送依頼を行う（ステップ４０５）。
【００５０】
ステップ４０４で当該データベースブロックがキャッシュヒットするか、ステップ４０５で転送処理が終了するとキャッシュメモリ２２中の当該データベースブロックに対してログレコードに含まれているデータベース更新履歴情報を反映する（ステップ４０６）。
【００５１】
一方、ステップ４０１で判定した結果、当該ログレコードがトランザクションの状態変更ログであり、ＲＯＬＬＢＡＣＫログである場合には、ステップ４０８で当該トランザクションによる更新履歴情報の反映を取り消す処理を行う。
【００５２】
ステップ４０７では、当該ログブロックの全ログレコードの処理を完了したかどうかを調べ、まだ全ログレコードの処理を完了していない場合にはステップ４０１へ戻り、完了した場合には処理を終了する。
【００５３】
図７は本実施形態のＲＥＡＤコマンド受領時の処理手順を示すフローチャートである。図７の様に更新処理部３０は、ディスク制御処理部２１からコマンドを受領すると、受信コマンドからコマンドの種類とアクセス先アドレスを解析し、ＲＥＡＤアクセス要求であることを認識する（ステップ３６１）。ここで、アクセス先アドレスからは、前記と同様にして装置構成管理テーブルを参照することで、アクセス要求先のディスク制御装置番号とドライブ番号を識別できるものとする。
【００５４】
次に、ステップ３６１で解析したアクセス先アドレスのデータが、ディスクサブシステム２のキャッシュメモリ２２に保持されているかどうかを調べ、キャッシュヒットミス判定を行う（ステップ３６２）。
【００５５】
アクセス先データがキャッシュメモリ２２に保持されていないキャッシュミスの場合には、前記の様にアクセス要求先のドライブ番号を識別し、ディスクサブシステム２のディスクアクセス制御部２３に対してそのドライブ番号に対応する磁気ディスク装置からキャッシュメモリ２２ヘの転送依頼を行う（ステップ３６３）。この場合、転送終了までＲＥＡＤ処理を中断し（ステップ３６４）、転送処理終了後、再度ＲＥＡＤ処理を継続する。また、転送先のキャッシュアドレスはキャッシュの空きリスト等、一般的な方法で管理、取得すれば良いが、転送先アドレスについては、キャッシュ管理テーブルを更新することで登録する必要がある。
【００５６】
ステップ３６２でキャッシュヒットの判定の場合、またはステップ３６４で転送処理が終了した場合、従来の単純なデータの読み出しの場合では当該ディスクサブシステム内のキャッシュメモリのデータをチャネルに転送するが、本実施形態では、更に当該データがデータベース管理処理部１０からのデータベースブロックのＲＥＡＤ要求であるかを判定する（ステップ３６５）。当該データがデータベースブロックであるかは、ＤＢ−ディスクブロック変換テーブル２８を参照し、該当ドライブ番号の存在を判定することによって識別できる。
【００５７】
当該データがデータベースブロックである場合には、それ以前のＷＲＩＴＥ要求で受信し、ログ追跡処理の終了していないログ情報中にそのデータベースブロックを更新するログレコードが含まれているかどうかを判定し、含まれている場合にはその更新を行う。
【００５８】
すなわち、そのＲＥＡＤアクセス要求先の物理ドライブのドライブ番号とページ番号をアクセス先アドレスから求め、ログ追跡処理の終了していないログレコードの物理ドライブのドライブ番号及びページ番号と比較して、キャッシュメモリ２２中のログブロック２６２ａ内のログレコード中に反映する必要のあるログレコードがあるかを判定し（ステップ３６６）、該当ログレコードが存在した場合にはログ追跡処理を行う（ステップ３６７）。
そして、ステップ３６５の処理によって該当データがデータベースブロックでないと判定された時点か、若しくはステップ３６７のログ追跡処理が完了した時点で該当データをチャネルに転送する。
【００５９】
前記の様に本実施形態では、ＤＢバッファ１２に対する更新処理の内容を示すログ情報によりディスクサブシステム２上のデータベース領域２４のデータを更新するので、従来のデータベース管理システムで行っていたデータベースブロックの記憶装置サブシステムへの書き込みについては本実施形態では必要無くなる。また、チェックポイント取得時にも同様にログ情報によりデータベース領域２４への書き込みをディスクサブシステム２側で行う。この為、本実施形態においてホストコンピュータ１は、チェックポイント取得処理等のＤＢバッファ１２の内容をディスクサブシステム２へ反映させる処理を瞬時に終了させることが可能であり、ログ情報によりディスクサブシステム２上でデータベース領域２４のデータを更新している間も、ホストコンピュータ１側ではデータベース処理を続行することができる。
【００６０】
この際、ホストコンピュータ１でデータベース処理を続行中にアクセス対象のデータがＤＢバッファ１２中に存在していないことが検出され、ディスクサブシステム２に対してデータベースブロックの読み込み要求が行われた場合には、その読み込み対象のデータベースブロックをログ情報の内容に従って更新した後にホストコンピュータ１へ送信するので、ホストコンピュータ１は、ディスクサブシステム２でのログ追跡処理を何ら意識すること無くデータベース処理を続行することが可能である。
【００６１】
更に本実施形態では、ホストコンピュータ１からディスクサブシステム２へのデータベースブロックの書き込みが不要になることによって、ディスクサブシステム２に対する帯域幅を大幅に増加させたのと同様の効果を得ることが可能になる。すなわち本実施形態では、ＤＢバッファ１２の内容をディスクサブシステム２内のデータベース領域２４に反映させる必要が生じた場合に、更新処理の行われたレコードを１つでも含むデータベースブロック２４２ａ全てをディスクサブシステム２へ送信するのではなく、ＤＢバッファ１２に対する更新処理の内容を示すログブロック２６２ａをディスクサブシステム２へ送信するので、ディスクサブシステム２へ送信されるデータ量を減少させることが可能であり、この為、ディスクサブシステム２に対する帯域幅を相対的に増加させることができる。
【００６２】
一方、ホストコンピュータ１側のデータベース管理処理が障害によってダウンした場合であっても、ディスクサブシステム２上のキャッシュメモリ２２は、最新のデータベースブロック２４２の状態が保持されたウォームキャッシュ状態となっているので、再開始処理時にホストコンピュータ１からディスクサブシステム２に対する入出力要求があった場合にキャッシュヒットとなり、実際に磁気ディスク装置上のデータベース領域２４までアクセスする頻度を極端に軽減することができる。
【００６３】
以上説明した様に本実施形態のデータベース処理システムによれば、ホストコンピュータのバッファ上で行われたデータベース処理の内容を示すログ情報に従って記憶装置サブシステム上のデータベース領域のデータを更新するので、ホストコンピュータのバッファ上で行われたデータベース処理の内容を記憶装置サブシステム上のデータベース領域へ反映させる際に、ホストコンピュータと記憶装置サブシステムとの間の入出力処理負荷を低減させることが可能である。
【００６４】
データベース領域へ反映したデータは、記憶装置サブシステム内のキャッシュに格納されているため、反映データを利用する場合や、特にデータを大量に参照するホストコンピュータの障害回復処理の高速化を図ることが可能である。
【００６５】
（実施形態２）
以下にログ情報の内、ＣＯＭＭＩＴされたトランザクションのログ情報を用いて更新を行う実施形態２のデータベース処理システムについて説明する。
実施形態１のログ追跡処理では、全てのログレコードを対象に該当するデータベースブロックヘの反映処理を行ったが、本実施形態ではログ追跡処理の別の実施方法について図８から図１０を用いて説明する。
【００６６】
図８は本実施形態のログ追跡処理においてログブロック中に含まれる全てのログレコードについてトランザクション毎にログを解析した結果の例を示す図である。図８に示す様に本実施形態では、ログブロック２６２ａを解析し、まず当該ディスクサブシステム内のキャッシュメモリ２２とは異なる共用メモリ上に抽出ログバッファ２６４を確保して、抽出ログバッファ２６４に全てのログレコード２６６ａ〜２６６ｌを格納する。
【００６７】
このとき、各ログレコードをトランザクション別に管理する為、トランザクションログ管理テーブル２６８によって各々のログレコードをトランザクション別に管理し、トランザクションＴＲ１からトランザクションＴＲ４までのログレコードのチェインをそれぞれ生成する。
【００６８】
すなわち、トランザクションＴＲ１には、トランザクションログ管理テーブル２６８ａ、２６８ｂ、２６８ｃ、乃至２６８ｆがチェインされ、トランザクションＴＲ２には、トランザクションログ管理テーブル２６８ｅ、２６８ｇがチェインされる。またトランザクションＴＲ３には、トランザクションログ管理テーブル２６８ｈ、２６８ｊ、２６８ｌがチェインされ、トランザクションＴＲ４には、トランザクションログ管理テーブル２６８ｉ、２６８ｋがチェインされる。
【００６９】
この様に、トランザクションログ管理テーブル２６８を各々のトランザクション毎にチェインさせることにより、ログレコード情報にトランザクションの正常決着処理を示すＣＯＭＭＩＴが識別されたトランザクションのログレコードだけを対象にすることができる。
【００７０】
図９は本実施形態の図８のトランザクションログ管理テーブル２６８を用いる際のログレコード分別処理の処理手順を示すフローチャートである。本処理は、図５のステップ３４７で示したＷＲＩＴＥコマンド処理に代わる処理である。
【００７１】
ログブロック中の各ログレコードについて、トランザクション開始を示すトランザクションＢＥＧＩＮログであるかを判定し（ステップ４４１）、トランザクションＢＥＧＩＮログである場合、そのログを抽出ログバッファ２６４へ追加し、トランザクションログ管理テーブル２６８ヘの登録を行う。
【００７２】
ステップ４４１の判定でトランザクションＢＥＧＩＮログではないと判定された場合にはデータベース更新ログであるかを判定し（ステップ４４３）、データベース更新ログである場合には、該当するトランザクション識別子と同じトランザクションログ管理テーブル２６８の最後尾にチェインする。
【００７３】
ステップ４４３の判定でトランザクション更新ログではないと判定された場合には、トランザクションの無効化を示すトランザクションＲＯＬＬＢＡＣＫログかであるかを判定し（ステップ４４５）、トランザクションＲＯＬＬＢＡＣＫ処理である場合には、該当するトランザクション識別子と同じ識別子のトランザクションログ管理テーブル２６８を削除すると同時に抽出ログバッファ２６４の該当するログレコードも削除する。すなわち、ＲＯＬＬＢＡＣＫしたトランザクションのログは、データベースブロックヘ反映されない様にする。
【００７４】
ステップ４４５の判定でトランザクションＲＯＬＬＢＡＣＫログではないと判定された場合には、トランザクションの有効化を示すトランザクションＣＯＭＭＩＴログであるかを判定し（ステップ４４７）、トランザクションＣＯＭＭＩＴログである場合にはログ追跡処理を行う（ステップ４４８）。
【００７５】
ステップ４４７の判定でトランザクションＣＯＭＭＩＴログではないと判定された後、ステップ４４９でログブロックの終了を検出するまでステップ４４１からステップ４４９までを繰り返す。
【００７６】
図１０は本実施形態の図９のステップ４４８におけるログ追跡処理の処理手順を示すフローチャートである。図１０のログ追跡処理では、ＣＯＭＭＩＴしたトランザクションのトランザクションログ管理テーブル２６８の先頭アドレスの次のアドレスが引き渡される。つまり、トランザクションＢＥＧＩＮログを処理の対象から外すことができる。
【００７７】
この処理では、１つのトランザクションの複数のログレコードの集まりについて順次、処理を行っていく。まずステップ４４８１では、ログレコードのログ情報がトランザクションのＣＯＭＭＩＴログであるかどうかを判定し、当該ログレコードが、ＣＯＭＭＩＴログではなく、トランザクション更新ログである場合には、ログレコード中に記録された当該ログ情報に含まれているデータベース領域ＩＤ、ファイルＩＤ及びページ番号と、図２に示したＤＢ−ディスクブロック変換テーブル２８の情報とを比較し、対応する物理ディスクのディスク制御装置番号とドライブ番号とページ番号を識別する（ステップ４４８２）。
【００７８】
次にステップ４４８１で識別した当該データについてキャッシュメモリ２２に対してキャッシュヒットミス判定を行う（ステップ４４８３）。当該データがキャッシュメモリに保持されていないキャッシュミスの場合には、ディスクアクセス制御部２３に対して当該データベースブロックのドライブからキャッシュメモリ２２ヘの転送依頼を行う（ステップ４４８４）。
【００７９】
ステップ４４８３で当該データベースブロックがキャッシュヒットするか、ステップ４４８４で転送処理が終了すると、キャッシュメモリ２２中の当該データベースブロックに、ログレコードに含まれるデータベース更新履歴情報を反映する（ステップ４４８５）。
ステップ４４８１からステップ４４８５までの処理を、当該トランザクションの全ログレコードの処理が完了するまで行う（ステップ４４８６）。
【００８０】
一方、ステップ４４８１の判定でトランザクションＣＯＭＭＩＴログが出現した場合には、当該トランザクションのログについて全て処理を反映し終わっているのでステップ４４８７へ進み、トランザクションログ管理テーブル２６８及びトランザクション抽出ログバッファ２６４から当該トランザクションに関する全ての情報を削除する。
【００８１】
以上説明した様に本実施形態のデータベース処理システムによれば、ログ情報の内、ＣＯＭＭＩＴされたトランザクションのログ情報を用いて更新を行うので、ホストコンピュータのバッファ上で行われたデータベース処理の内容をログ情報によって記憶装置サブシステム上のデータベース領域へ反映させる際の入出力処理を省略することが可能である。
【００８２】
（実施形態３）
以下にデータベース領域のデータの更新を、そのデータベース領域のデータに対応する物理デバイス毎に並列に行う実施形態３のデータベース処理システムについて説明する。
【００８３】
図１１は本実施形態のデータベース処理システムの概略構成を示す図である。本実施形態の処理は、実施形態１及び実施形態２に共通して実施することができる。すなわち、実施形態１の図６におけるログ追跡処理及び実施形態２の図１０におけるログ追跡処理において、データベースブロックのデータベース領域ＩＤ、ファイルＩＤ及びページ番号から、ＤＢ−ディスクブロック変換テーブル２８を使用して物理ドライブのドライブ番号を取得した後、ドライブ毎に異なるプロセッサに処理を分割して実行することで、キャッシュメモリ２２ヘの書き込み処理を並列化する。つまり、キャッシュメモリに書き込むことで、各ドライブへの反映処理を並列処理させることができ、高速なデータ反映が可能となる。ここで本実施形態のディスクサブシステムは、ドライブ毎の処理を実行する複数のプロセッサを備えているものとする。
【００８４】
以上説明した様に本実施形態のデータベース処理システムによれば、ログ情報によるデータベース領域のデータの更新を、そのデータベース領域のデータに対応する物理デバイス毎に並列に行うので、ホストコンピュータのバッファ上で行われたデータベース処理の内容をログ情報によって記憶装置サブシステム上のデータベース領域へ反映させる際に、その処理を効率的に行うことが可能である。
【００８５】
（実施形態４）
以下にディスクサブシステムを追加した場合の実施形態４のデータベース処理システムについて説明する。
図１２は本実施形態のデータベース処理システムの概略構成を示す図である。図１２に示す様に本実施形態のディスクサブシステム１２００はデータ送信処理部３１を有している。データ送信処理部３１は、ログ情報の内容に従って更新されるデータベース領域のデータがディスクサブシステム１２００とは異なるディスクサブシステム１２０１中に存在している場合に、そのログ情報の内容をディスクサブシステム１２０１へ送信する処理部である。
【００８６】
ディスクサブシステム１２００をデータ送信処理部３１として機能させる為のプログラムは、フロッピーディスク等の記録媒体に記録されて実行されるものとする。なお前記プログラムを記録する記録媒体はフロッピーディスク以外の他の記録媒体でも良い。また前記プログラムを当該記録媒体から情報処理装置にインストールして使用しても良いし、ネットワークを通じて当該記録媒体にアクセスして前記プログラムを使用するものとしても良い。
【００８７】
またディスクサブシステム１２０１はデータ受信処理部３２を有している。データ受信処理部３２は、前記送信されたログ情報を受信して、ディスクサブシステム１２０１の更新処理部３０へ、ディスクサブシステム１２０１内のデータベース領域２４のデータの更新を指示する処理部である。
【００８８】
ディスクサブシステム１２０１をデータ受信処理部３２として機能させる為のプログラムは、フロッピーディスク等の記録媒体に記録されて実行されるものとする。なお前記プログラムを記録する記録媒体はフロッピーディスク以外の他の記録媒体でも良い。また前記プログラムを当該記録媒体から情報処理装置にインストールして使用しても良いし、ネットワークを通じて当該記録媒体にアクセスして前記プログラムを使用するものとしても良い。
【００８９】
次に本実施形態について図１２を用いて説明する。本実施形態では、実施形態１で示した構成にもう１つのディスクサブシステムを追加した場合の例を表している。つまり、追加したディスクサブシステム１２０１にはデータベース領域だけが存在する例を示している。
【００９０】
本実施形態では、データベース管理処理部１０が管理するデータベース領域２４がディスクサブシステム１２００及び１２０１に存在している。但し、ログ領域はディスクサブシステム１２００にしか存在していない。この様な場合、ディスクサブシステム１２００のディスク制御処理部２１には、ホストコンピュータ１からＷＲＩＴＥ要求のあったログブロックを判定し、ディスクサブシステム１２０１にログブロックを送信するデータ送信処理部３１が必要になる。また、ディスクサブシステム１２０１にはデータ送信処理部３１から送信されたデータを受信するデータ受信処理部３２が必要となる。
【００９１】
複数台のディスクサブシステムを用いて大規模なデータベースシステムを構築した場合、この様なデータベース領域が配置される場合があるが、本実施形態では、以下の様に処理を行う。
すなわち、ディスクサブシステム１２００のデータ送信処理部３１は、 ログ情報の内容に従って更新されるデータベース領域のデータについて、そのディスク制御装置番号を図２のＤＢ−ディスクブロック変換テーブル２８から求め、その求めたディスク制御装置番号がディスクサブシステム１２００の番号と異なっている場合には、そのディスク制御装置番号のディスクサブシステム、例えばディスクサブシステム１２０１のデータ受信処理部３２へ送信し、データ受信処理部３２により、そのログ情報を受信して、ディスクサブシステム１２０１の更新処理部３０へ、ディスクサブシステム１２０１内のデータベース領域２４のデータの更新を指示する。
【００９２】
以上説明した様に本実施形態のデータベース処理システムによれば、ログ情報の内容に従って更新されるデータベース領域のデータが他の記憶装置サブシステム中に存在している場合に、そのログ情報の内容を当該記憶装置サブシステムへ送信し、その記憶装置サブシステム内でデータベース領域のデータの更新を行うので、複数台の記憶装置サブシステムにデータベース領域を配置している大規模なデータベース処理システムで、ホストコンピュータのバッファ上で行われたデータベース処理の内容を記憶装置サブシステム上のデータベース領域へ反映させる際にも、ホストコンピュータと記憶装置サブシステムとの間の入出力処理負荷を低減させることが可能である。また、反映したデータを利用する場合も複数の記憶装置サブシステム内のキャッシュメモリに格納されているため、並列に参照することができ、高速にアクセスすることが可能である。
【００９３】
【発明の効果】
本発明によればホストコンピュータで行われたデータベース処理の内容を示すログ情報に従って記憶装置サブシステム上のデータベース領域のデータを更新するので、ホストコンピュータで行われたデータベース処理の内容を記憶装置サブシステム上のデータベース領域へ反映させる際に、ホストコンピュータと記憶装置サブシステムとの間の入出力処理負荷を低減させることが可能である。
【図面の簡単な説明】
【図１】実施形態１のデータベース処理システムのシステム構成を示す図である。
【図２】実施形態１のＤＢ−ディスクブロック変換テーブル２８の構成情報を示す図である。
【図３】実施形態１のホストコンピュータ上で認識されるデータベース領域と、オペレーティングシステムが認識する論理ボリュームと、デバイスファイル及びディスクサブシステム内のＬＵへのマッピング関連の例を示す図である。
【図４】実施形態１の受信コマンド解析処理の処理手順を示すフローチャートである。
【図５】実施形態１のＷＲＩＴＥコマンド受領時の処理手順を示すフローチャートである。
【図６】実施形態１のログ追跡処理の処理手順を示すフローチャートである。
【図７】実施形態１のＲＥＡＤコマンド受領時の処理手順を示すフローチャートである。
【図８】実施形態２のログ追跡処理においてログブロック中に含まれる全てのログレコードについてトランザクション毎にログを解析した結果の例を示す図である。
【図９】実施形態２の図８のトランザクションログ管理テーブル２６８を用いる際のログレコード分別処理の処理手順を示すフローチャートである。
【図１０】実施形態２の図９のステップ４４８におけるログ追跡処理の処理手順を示すフローチャートである。
【図１１】実施形態３のデータベース処理システムの概略構成を示す図である。
【図１２】実施形態４のデータベース処理システムの概略構成を示す図である。
【符号の説明】
１…ホストコンピュータ、２…ディスクサブシステム、１２…ＤＢバッファ、１４…ログバッファ、１６…ストレージエリアネットワーク、２２…キャッシュメモリ、２４…データベース領域、２４２…データベースブロック、２６…ログ用ディスク、２６２…ログブロック、２８…ＤＢ−ディスクブロック変換テーブル、１０…データベース管理処理部、２１…ディスク制御処理部、２３…ディスクアクセス制御部、３０…更新処理部、２６４…抽出ログバッファ、２６６…ログレコード、２６８…トランザクションログ管理テーブル、１２００及び１２０１…ディスクサブシステム、３１…データ送信処理部、３２…データ受信処理部。
【発明の属する技術分野】
本発明はホストコンピュータと記憶装置サブシステムとを接続してデータベース処理を行うデータベース処理システムに関し、特にホストコンピュータのデータベース処理の内容を示すログ情報により、記憶装置サブシステム内のデータベースにデータベース処理内容を反映するデータベース処理システムに適用して有効な技術に関するものである。
【０００２】
【従来の技術】
従来のデータベース管理システムでは、ホストコンピュータ上と記憶装置サブシステムとの間でデータベースブロック及びログブロックの入出力を行っている。すなわち、データベース管理システムが入出力の効率を向上させる為にホストコンピュータのメインメモリ上にデータベースのバッファを設定し、当該バッファ上に記憶装置（メインメモリと比較して低速で大容量の磁気ディスク装置等の記憶装置を指すものとする）から入力したデータベースブロックをキャッシングすることによって、できるだけ記憶装置からの入出力を削減している。
【０００３】
この様なデータベース管理システムでは、データの更新処理については、予めデータベースバッファ上に入力したデータベースブロックに対して行い、その際の更新履歴情報をログ専用のバッファにログとして書き出した後、トランザクションの決着時にそのログを記憶装置に強制出力することによって整合性を保証している。その際、データベースブロックの記憶装置への反映（書き込み）では、当該ブロックに対して行った更新履歴ログを先行して記憶装置に出力する、所謂ＷＡＬ（Ｗｒｉｔｅ Ａｈｅａｄ Ｌｏｇ）を遵守する必要がある。
【０００４】
また、データベース管理システムでは、障害に備え、定期的にＤＢの整合性を保証する為、稼動中にチェックポイントを取得する。チェックポイントは、システム障害時の再開始処理を行う起点となるデータベースの整合性が保証されたポイントとなる。主にチェックポイントは稼動中に出力したログブロック数がある一定の回数に達した時点に取得する場合が多い。チェックポイント処理では、その時点のデータベースバッファ上の更新が行われたデータベースブロックを記憶装置上に全て書き出す処理が行われる（例えば非特許文献１参照）。
【０００５】
【非特許文献１】
ジム・グレイ(Jim Gray)、アンドレアス・ロイター(Andreas Reuter)著、「トランザクション・プロセッシング：コンセプト・アンド・テクニック(TRANSACTION PROCESSING:CONCEPTS AND TECHNIQUES)」（米国）、第1版、モーガン・カウフマン・パブリッシャー(MORGAN KAUFMAN PUBLISHERS)社発行、1993年、pp.556-557、pp.604-609
【０００６】
【発明が解決しようとする課題】
従来のデータベース管理システムにおけるデータベースブロックの記憶装置への書き込み方法では、前記の様にデータベースバッファ上の更新が行われたデータベースブロックを記憶装置上に全て書き出す処理が行われるが、更新が行われたデータベースブロック中には更新の行われていないレコードも含まれている為、必要の無い入出力も発生し、ホストコンピュータと記憶装置サブシステムとの間の入出力処理に大きな負荷がかかるという問題がある。
【０００７】
本発明の目的は上記問題を解決し、ホストコンピュータのバッファ上で行われたデータベース処理の内容を記憶装置サブシステム上のデータベース領域へ反映させる際に、ホストコンピュータと記憶装置サブシステムとの間の入出力処理負荷を低減させることが可能な技術を提供することにある。
【０００８】
本発明の他の目的は、ホストコンピュータの障害回復処理時に記憶装置サブシステムのキャッシュメモリ上に上記データベースの反映データが格納されているため、上記回復処理を高速に実行することができる技術を提供することにある。
【０００９】
本発明の他の目的はホストコンピュータのバッファ上で行われたデータベース処理の内容をログ情報によって記憶装置サブシステム上のデータベース領域へ反映させる際に、不要な入出力処理を省略することが可能な技術を提供することにある。
【００１０】
本発明の他の目的はホストコンピュータのバッファ上で行われたデータベース処理の内容をログ情報によって記憶装置サブシステム上のデータベース領域へ反映させる際に、その処理を効率的に行うことが可能な技術を提供することにある。
【００１１】
本発明の他の目的は複数台の記憶装置サブシステムにデータベース領域を配置している大規模なデータベース処理システムで、ホストコンピュータのバッファ上で行われたデータベース処理の内容を記憶装置サブシステム上のデータベース領域へ反映させる際にも、ホストコンピュータと記憶装置サブシステムとの間の入出力処理負荷を低減させることが可能な技術を提供することにある。
【００１２】
【課題を解決するための手段】
本発明は、ホストコンピュータのバッファ上で行われたデータベース処理の内容を記憶装置上のデータベースに反映させる処理を行うデータベース処理システムにおいて、ホストコンピュータで行われたデータベース処理の内容を示すログ情報に従って記憶装置サブシステム上のデータベース領域のデータへデータベース処理内容を反映するものである。
【００１３】
本発明のデータベース処理システムでは、記憶装置サブシステム内のデータベース領域の内容を一時的に保持するデータベースバッファと、データベースバッファに対する更新処理の内容を一時的に保持するログバッファとをホストコンピュータに備えており、ホストコンピュータでのデータベース処理の実行に伴ってデータベースバッファの内容が変更され、その変更内容を記憶装置サブシステム内のデータベース領域に反映させる必要が生じた場合には、データベースバッファ上で行われた更新処理の内容を示すログ情報の記憶装置サブシステムへの書き込みを要求するアクセス要求をホストコンピュータから記憶装置サブシステムへ送信する。
【００１４】
記憶装置サブシステムでは、前記アクセス要求をホストコンピュータから受信し、その受信したアクセス要求が書き込み要求または読み込み要求のいずれであるかを判定する。そして、その受信したアクセス要求が書き込み要求である場合には、その書き込み内容がホストコンピュータで行われたデータベース処理の内容を示すログ情報であるかどうかを判定する。
【００１５】
前記判定の結果、その書き込み内容が前記ログ情報である場合には、ホストコンピュータ側のデータベース処理で認識している論理的な位置情報と記憶装置サブシステム上の物理的な位置情報との対応関係を示す変換テーブルを参照し、前記ログ情報中に示された位置情報を記憶装置サブシステム上の物理的な位置情報に変換した後、その変換した物理的な位置情報で表される記憶装置サブシステム上のデータベース領域のデータを前記ログ情報の内容に従って更新する。
【００１６】
そのときに、記憶装置サブシステムのキャッシュメモリに当該反映対象データが格納されている場合には、キャッシュメモリに格納されている当該反映対象データを反映する。キャッシュメモリに格納されていない場合は、キャッシュメモリに反映対象データをアップロードし、その後、上記反映対象データをキャッシュメモリに格納する。
【００１７】
またホストコンピュータは、データベースバッファ中にデータベース処理でアクセス対象となっているデータが存在していない場合に、当該データの読み込み要求をホストコンピュータから記憶装置サブシステムへ送信し、記憶装置サブシステムは、ホストコンピュータから受信したアクセス要求が読み込み要求である場合には、それ以前の書き込み要求で受信したログ情報中に、読み込み対象のデータを更新するログ情報が含まれているかどうかを判定し、そのログ情報中に読み込み対象のデータを更新するログ情報が含まれている場合には、読み込み対象のデータを当該ログ情報の内容に従って更新してホストコンピュータ側へ送信する。
【００１８】
前記の様に本発明では、データベースバッファの内容を記憶装置サブシステム内のデータベース領域に反映させる必要が生じた場合に、更新処理の行われたレコードを１つでも含むデータベースブロック全てをホストコンピュータから記憶装置サブシステムへ送信するのではなく、データベースバッファに対する更新処理の内容を示すログ情報をホストコンピュータから記憶装置サブシステムへ送信するので、ホストコンピュータと記憶装置サブシステムとの間で送信されるデータ量を減少させることができる。
【００１９】
以上の様に本発明のデータベース処理システムによれば、ホストコンピュータのバッファ上で行われたデータベース処理の内容を示すログ情報に従って記憶装置サブシステム上のデータベース領域のデータを更新するので、ホストコンピュータのバッファ上で行われたデータベース処理の内容を記憶装置サブシステム上のデータベース領域へ反映させる際に、ホストコンピュータと記憶装置サブシステムとの間の入出力処理負荷を低減させることが可能である。
【００２０】
【発明の実施の形態】
（実施形態１）
以下にホストコンピュータのバッファ上で行われたデータベース処理の内容をディスクサブシステムの磁気ディスク装置上のデータベースに反映させる処理を行う実施形態１のデータベース処理システムについて説明する。
【００２１】
図１は本実施形態のデータベース処理システムのシステム構成を示す図である。図１に示す様に本実施形態のホストコンピュータ１はデータベース管理処理部１０を有している。データベース管理処理部１０は、ホストコンピュータ１のＤＢバッファ１２の内容をディスクサブシステム２内の磁気ディスク装置へ反映させる必要が生じた場合に、そのＤＢバッファ１２に対して行われたデータベース処理の内容を示すログ情報であるログブロック２６２ａの書き込み要求をホストコンピュータ１からディスクサブシステム２へ送信し、ＤＢバッファ１２中にデータベース処理でアクセス対象となっているデータが存在していない場合に当該データの読み込み要求をホストコンピュータ１からディスクサブシステム２へ送信する処理部である。
【００２２】
ホストコンピュータ１をデータベース管理処理部１０として機能させる為のプログラムは、ＣＤ−ＲＯＭ等の記録媒体に記録され磁気ディスク等に格納された後、メモリにロードされて実行されるものとする。なお前記プログラムを記録する記録媒体はＣＤ−ＲＯＭ以外の他の記録媒体でも良い。また前記プログラムを当該記録媒体から情報処理装置にインストールして使用しても良いし、ネットワークを通じて当該記録媒体にアクセスして前記プログラムを使用するものとしても良い。
またディスクサブシステム２は、ディスク制御処理部２１と、ディスクアクセス制御部２３と、更新処理部３０とを有している。
【００２３】
ディスク制御処理部２１は、ホストコンピュータ１から送信されたアクセス要求を受信し、その受信したアクセス要求が書き込み要求または読み込み要求のいずれであるかを判定する処理や、ディスクサブシステム装置全体の動作を制御する制御処理部である。
【００２４】
ディスクアクセス制御部２３は、ディスクサブシステム２配下の各磁気ディスク装置へのアクセスを制御する処理部である。更新処理部３０は、前記受信したアクセス要求が書き込み要求である場合に、その書き込み内容がホストコンピュータ１のＤＢバッファ１２上で行われたデータベース処理の内容を示すログ情報であるかどうかを判定し、前記書き込み内容が前記ログ情報である場合に、ホストコンピュータ１側のデータベース処理で認識している論理的な位置情報とディスクサブシステム２上の物理的な位置情報との対応関係を示すＤＢ−ディスクブロック変換テーブル２８によって、前記ログ情報中に示された位置情報をディスクサブシステム２上の物理的な位置情報に変換し、その変換した物理的な位置情報で表されるディスクサブシステム２上のデータベース領域２４のデータを前記ログ情報の内容に従って更新する処理部である。
【００２５】
ディスクサブシステム２を、ディスク制御処理部２１、ディスクアクセス制御部２３及び更新処理部３０として機能させる為のプログラムは、フロッピーディスク等の記録媒体に記録されて実行されるものとする。なお前記プログラムを記録する記録媒体はフロッピーディスク以外の他の記録媒体でも良い。また前記プログラムを当該記録媒体から情報処理装置にインストールして使用しても良いし、ネットワークを通じて当該記録媒体にアクセスして前記プログラムを使用するものとしても良い。
【００２６】
本実施形態のホストコンピュータ１とディスクサブシステム２は、ストレージエリアネットワーク１６で接続されている。
ホストコンピュータ１では、データベース管理処理部１０が稼動し、ホストコンピュータ１は、ディスクサブシステム２内のデータベース領域２４の内容を一時的に保持するＤＢバッファ１２と、ＤＢバッファ１２に対する更新処理の内容を一時的に保持するログバッファ１４とを備えている。
【００２７】
ディスクサブシステム２では、ホストコンピュータ１からの命令を受けて動作するディスク制御処理部２１と、キャッシュメモリ２２と、ディスクアクセス制御部２３とを通して磁気ディスク装置上のデータベース領域２４へのアクセスが行われており、ディスクアクセスは常にキャッシュメモリ２２を介して行われることになる。
【００２８】
本実施形態では、ホストコンピュータ１上のデータベース管理処理部１０で動作するトランザクションによって更新されたデータの更新履歴情報であるログ情報がログブロック２６２ａに書き込まれ、トランザクションの決着時等、ＤＢバッファ１２の内容をディスクサブシステム２へ反映させる必要が生じた場合に、ログブロック２６２ａがディスクサブシステム２に書き込まれる。
【００２９】
本実施形態の更新処理部３０は、データの書き込みが行われると、そのデータがログブロック２６２ａであるかどうかを判定し、ディスクサブシステム２上でデータベースブロック２４２ａの書き込みを制御する。
【００３０】
すなわち更新処理部３０は、ディスクサブシステム２が受け付けたコマンドを解析し、ログブロック２６２ａの書き込み要求であれば、キャッシュメモリ２２上に書き込んだログブロック２６２ａを解析し、ログブロック２６２ａ中のログレコードから該当するデータベース領域２４のデータベースブロック２４２ａをキャッシュメモリ２２上にアップロードし、ログの内容を反映する処理を行う。
【００３１】
このとき反映されるデータベースブロック２４２ａは、ログブロック２６２ａ中のログレコードではホストコンピュータ１上のデータベース管理処理部１０が認識できる論理的な位置情報で表されている為、この論理的な位置情報をディスクサブシステム２上の物理的な位置情報にマッピングする必要がある。そこで、この処理をＤＢ−ディスクブロック変換テーブル２８を用いて行う。ＤＢ−ディスクブロック変換テーブル２８は、一般的にはＤＢ構築時にホストコンピュータ１上のデータベース管理処理部１０から作成されることになる。
【００３２】
図２は本実施形態のＤＢ−ディスクブロック変換テーブル２８の構成情報を示す図である。図２に示す様にＤＢ−ディスクブロック変換テーブル２８は、データベース領域２４を識別する為の情報であるデータベース領域ＩＤと、そのデータベース領域ＩＤで識別されるデータベース領域が複数のファイルで構成される場合のファイルの順序番号を示すファイルＩＤと、前記データベース領域を構成するブロックの長さを示すブロック長と、前記データベース領域の構成ファイルが確保されている論理ボリュームを識別する為の情報である論理ボリュームＩＤと、その論理ボリュームＩＤで識別される論理ボリュームがマッピングされているディスクサブシステムを識別する為の番号であるディスク制御装置番号と、そのディスク制御装置番号で識別されるディスクサブシステムの磁気ディスク装置の内で、前記論理ボリュームがマッピングされている磁気ディスク装置のドライブ番号を識別する為の情報である物理デバイスＩＤと、その物理デバイスＩＤで識別される磁気ディスク装置上での当該ファイルの相対的な位置を示す相対位置とを格納している。
【００３３】
データベース領域２４を構成するファイルは、ホストコンピュータ１上のオペレーティングシステムが認識するファイルシステムとして論理ボリュームにマッピングされる。更に、論理ボリュームは、ディスクサブシステム２の物理デバイスである磁気ディスク装置に対応したデバイスファイルとしてマッピングされる。
【００３４】
ディスクサブシステム２内では、前記デバイスファイルは、ＬＵ（Ｌｏｇｉｃａｌ Ｕｎｉｔ）に対応している。従って、データベース領域２４を構成するファイルは、最終的に物理デバイスである磁気ディスク装置にマッピングされる。対応する物理情報は、ディスクサブシステム２上の物理デバイスを識別する為の物理デバイスＩＤと、物理デバイス内の相対位置であるＬＢＡ（ＬｏｇｉｃａｌＢｌｏｃｋ Ａｄｄｒｅｓｓ）である。
【００３５】
図３は本実施形態のホストコンピュータ上で認識されるデータベース領域と、オペレーティングシステムが認識する論理ボリュームと、デバイスファイル及びディスクサブシステム内のＬＵへのマッピング関連の例を示す図である。図３に示す様にデータベース管理処理部１０では、データを格納するデータベース領域は、複数のファイルから構成されるものとして認識されている。構成する各ファイルは、ホストコンピュータ１上のオペレーティングシステムのファイルに対応しており、図３ではオペレーティングシステムにおいてＲＡＷデバイスとして認識されるケースを想定している。更に、オペレーティングシステムのファイルは、物理的な磁気ディスク装置に対応するデバイスファイルとして管理されており、そのデバイスファイルは、前述した様にディスクサブシステム２内の各々の磁気ディスク装置に対応するＬＵにマッピングされている。
【００３６】
次に図４から図７に示す流れ図を用いてホストコンピュータ１上のデータベース管理処理部１０からログバッファ１４中のログブロック２６２ａのディスクサブシステム２への書き込みを要求するアクセス要求の処理について説明する。始めに、図４を用いて処理の概要を示す。
【００３７】
図４は本実施形態の受信コマンド解析処理の処理手順を示すフローチャートである。図４に示した処理は、ディスクサブシステム２内のプロセッサによって実行されるディスク制御処理部２１の処理として実現されるものであり、ホストコンピュータ１からのアクセス要求を受領したディスクサブシステム２は、始めに受領コマンドの解析処理を行う（ステップ３００）。接続チャネルのプロトコルに従ってコマンドを解析することで、アクセス要求がＲＥＡＤコマンドであるかＷＲＩＴＥコマンドであるかを識別できるものとする。
【００３８】
ステップ３２０でディスク制御処理部２１は、受領コマンドがＷＲＩＴＥコマンドであるかを判定し、ＷＲＩＴＥコマンドである場合にはＷＲＩＴＥコマンド処理を行う（ステップ３４０）。また、ＲＥＡＤコマンドである場合にはＲＥＡＤコマンド処理（ステップ３６０）を行う。
【００３９】
図５は本実施形態のＷＲＩＴＥコマンド受領時の処理手順を示すフローチャートである。図５の様に更新処理部３０は、ディスク制御処理部２１からコマンドを受領すると、受信コマンドからコマンド種類とアクセス先アドレスを解析し、ＷＲＩＴＥコマンドであることを認識する（ステップ３４１）。ここで、アクセス先アドレスからは、複数のディスクサブシステムやその各磁気ディスク装置に割り当てられているアドレスを示す装置構成管理テーブルの情報との比較を行うことにより、アクセス要求先のディスク制御装置番号とドライブ番号を識別することができるものとする。
【００４０】
次に、ステップ３４１で解析したアクセス先アドレスのデータが、ディスクサブシステム２のキャッシュメモリ２２に保持されているかどうかを調べ、キャッシュヒットミス判定を行う（ステップ３４２）。
【００４１】
アクセス先データがキャッシュメモリ２２に保持されていないキャッシュミスの場合には、前記の様にアクセス要求先のドライブ番号を識別し、ディスクサブシステム２のディスクアクセス制御部２３に対してそのドライブ番号に対応する磁気ディスク装置からキャッシュメモリ２２ヘの転送依頼を行う（ステップ３４３）。この場合、転送終了までＷＲＩＴＥ処理を中断し（ステップ３４４）、転送処理終了後、再度ＷＲＩＴＥ処理を継続する。また、転送先のキャッシュアドレスはキャッシュの空きリスト等、一般的な方法で管理、取得すれば良いが、転送先アドレスについては、キャッシュ管理テーブルを更新することで登録する必要がある。
【００４２】
ステップ３４２でキャッシュヒットの判定の場合、またはステップ３４４で転送処理が終了した場合には、ディスクサブシステム２内のキャッシュメモリ２２に対して当該データの更新を行う（ステップ３４５）。すなわち、ホストコンピュータ１から受領したデータの内容を書き込む。
【００４３】
データの更新が終了した後、前記アクセス先アドレスがログ用ディスク２６内のアドレスであるかどうかを調べて当該データがデータベース処理のログ用ディスク２６のデータであるかを判定し（ステップ３４６）、書き込み内容がログ用ディスク２６へのデータ、すなわちログブロックである場合には、そのログブロックの内容に従って該当するデータベース領域２４のデータベースブロックヘのログ追跡処理を行う（ステップ３４７）。
【００４４】
ログ追跡処理が完了するか、ステップ３４６の判定でログブロックではないと判定された場合、ホストコンピュータ１に対してＷＲＩＴＥコマンド処理の完了報告を行う（ステップ３４８）。
【００４５】
図６は本実施形態のログ追跡処理の処理手順を示すフローチャートである。ログブロックは複数のログレコードの集まりである。従って、図６に示す様にログブロックに含まれるログレコードについて順次、処理を行っていく。
【００４６】
まず更新処理部３０は、ログレコードのログ情報がトランザクションの開始処理、ＣＯＭＭＩＴまたはＲＯＬＬＢＡＣＫといった決着処理を示す情報であるかを判定する（ステップ４０１）。
【００４７】
当該ログレコードがトランザクションの状態変更ログではない場合には、更にデータベースの更新履歴を示すトランザクション更新ログであるかを判定する（ステップ４０２）。
【００４８】
当該ログレコードがトランザクション更新ログである場合には、図２に示したＤＢ−ディスクブロック変換テーブル２８を参照し、ログレコード中に記録されたログ情報に含まれているデータベース領域ＩＤ、ファイルＩＤ、ページ番号から、対応する物理ディスクのディスク制御装置番号とドライブ番号とページ番号を識別する（ステップ４０３）。すなわち、当該ログ情報に含まれているデータベース領域ＩＤ及びファイルＩＤに一致するレコードを、ＤＢ−ディスクブロック変換テーブル２８から検索して該当するディスク制御装置番号、ドライブ番号及び相対位置を求めた後、その相対位置がファイルの先頭であるものとして、当該ログ情報のページ番号を物理ディスク上のページ番号に変換する。
【００４９】
次にステップ４０３で前記の様に識別したデータがキャッシュメモリ２２に保持されているかどうかを調べてキャッシュヒットミス判定を行う（ステップ４０４）。当該データがキャッシュメモリ２２に保持されていないキャッシュミスの場合には、ディスクアクセス制御部２３に対して当該データベースブロックのドライブからキャッシュメモリ２２ヘの転送依頼を行う（ステップ４０５）。
【００５０】
ステップ４０４で当該データベースブロックがキャッシュヒットするか、ステップ４０５で転送処理が終了するとキャッシュメモリ２２中の当該データベースブロックに対してログレコードに含まれているデータベース更新履歴情報を反映する（ステップ４０６）。
【００５１】
一方、ステップ４０１で判定した結果、当該ログレコードがトランザクションの状態変更ログであり、ＲＯＬＬＢＡＣＫログである場合には、ステップ４０８で当該トランザクションによる更新履歴情報の反映を取り消す処理を行う。
【００５２】
ステップ４０７では、当該ログブロックの全ログレコードの処理を完了したかどうかを調べ、まだ全ログレコードの処理を完了していない場合にはステップ４０１へ戻り、完了した場合には処理を終了する。
【００５３】
図７は本実施形態のＲＥＡＤコマンド受領時の処理手順を示すフローチャートである。図７の様に更新処理部３０は、ディスク制御処理部２１からコマンドを受領すると、受信コマンドからコマンドの種類とアクセス先アドレスを解析し、ＲＥＡＤアクセス要求であることを認識する（ステップ３６１）。ここで、アクセス先アドレスからは、前記と同様にして装置構成管理テーブルを参照することで、アクセス要求先のディスク制御装置番号とドライブ番号を識別できるものとする。
【００５４】
次に、ステップ３６１で解析したアクセス先アドレスのデータが、ディスクサブシステム２のキャッシュメモリ２２に保持されているかどうかを調べ、キャッシュヒットミス判定を行う（ステップ３６２）。
【００５５】
アクセス先データがキャッシュメモリ２２に保持されていないキャッシュミスの場合には、前記の様にアクセス要求先のドライブ番号を識別し、ディスクサブシステム２のディスクアクセス制御部２３に対してそのドライブ番号に対応する磁気ディスク装置からキャッシュメモリ２２ヘの転送依頼を行う（ステップ３６３）。この場合、転送終了までＲＥＡＤ処理を中断し（ステップ３６４）、転送処理終了後、再度ＲＥＡＤ処理を継続する。また、転送先のキャッシュアドレスはキャッシュの空きリスト等、一般的な方法で管理、取得すれば良いが、転送先アドレスについては、キャッシュ管理テーブルを更新することで登録する必要がある。
【００５６】
ステップ３６２でキャッシュヒットの判定の場合、またはステップ３６４で転送処理が終了した場合、従来の単純なデータの読み出しの場合では当該ディスクサブシステム内のキャッシュメモリのデータをチャネルに転送するが、本実施形態では、更に当該データがデータベース管理処理部１０からのデータベースブロックのＲＥＡＤ要求であるかを判定する（ステップ３６５）。当該データがデータベースブロックであるかは、ＤＢ−ディスクブロック変換テーブル２８を参照し、該当ドライブ番号の存在を判定することによって識別できる。
【００５７】
当該データがデータベースブロックである場合には、それ以前のＷＲＩＴＥ要求で受信し、ログ追跡処理の終了していないログ情報中にそのデータベースブロックを更新するログレコードが含まれているかどうかを判定し、含まれている場合にはその更新を行う。
【００５８】
すなわち、そのＲＥＡＤアクセス要求先の物理ドライブのドライブ番号とページ番号をアクセス先アドレスから求め、ログ追跡処理の終了していないログレコードの物理ドライブのドライブ番号及びページ番号と比較して、キャッシュメモリ２２中のログブロック２６２ａ内のログレコード中に反映する必要のあるログレコードがあるかを判定し（ステップ３６６）、該当ログレコードが存在した場合にはログ追跡処理を行う（ステップ３６７）。
そして、ステップ３６５の処理によって該当データがデータベースブロックでないと判定された時点か、若しくはステップ３６７のログ追跡処理が完了した時点で該当データをチャネルに転送する。
【００５９】
前記の様に本実施形態では、ＤＢバッファ１２に対する更新処理の内容を示すログ情報によりディスクサブシステム２上のデータベース領域２４のデータを更新するので、従来のデータベース管理システムで行っていたデータベースブロックの記憶装置サブシステムへの書き込みについては本実施形態では必要無くなる。また、チェックポイント取得時にも同様にログ情報によりデータベース領域２４への書き込みをディスクサブシステム２側で行う。この為、本実施形態においてホストコンピュータ１は、チェックポイント取得処理等のＤＢバッファ１２の内容をディスクサブシステム２へ反映させる処理を瞬時に終了させることが可能であり、ログ情報によりディスクサブシステム２上でデータベース領域２４のデータを更新している間も、ホストコンピュータ１側ではデータベース処理を続行することができる。
【００６０】
この際、ホストコンピュータ１でデータベース処理を続行中にアクセス対象のデータがＤＢバッファ１２中に存在していないことが検出され、ディスクサブシステム２に対してデータベースブロックの読み込み要求が行われた場合には、その読み込み対象のデータベースブロックをログ情報の内容に従って更新した後にホストコンピュータ１へ送信するので、ホストコンピュータ１は、ディスクサブシステム２でのログ追跡処理を何ら意識すること無くデータベース処理を続行することが可能である。
【００６１】
更に本実施形態では、ホストコンピュータ１からディスクサブシステム２へのデータベースブロックの書き込みが不要になることによって、ディスクサブシステム２に対する帯域幅を大幅に増加させたのと同様の効果を得ることが可能になる。すなわち本実施形態では、ＤＢバッファ１２の内容をディスクサブシステム２内のデータベース領域２４に反映させる必要が生じた場合に、更新処理の行われたレコードを１つでも含むデータベースブロック２４２ａ全てをディスクサブシステム２へ送信するのではなく、ＤＢバッファ１２に対する更新処理の内容を示すログブロック２６２ａをディスクサブシステム２へ送信するので、ディスクサブシステム２へ送信されるデータ量を減少させることが可能であり、この為、ディスクサブシステム２に対する帯域幅を相対的に増加させることができる。
【００６２】
一方、ホストコンピュータ１側のデータベース管理処理が障害によってダウンした場合であっても、ディスクサブシステム２上のキャッシュメモリ２２は、最新のデータベースブロック２４２の状態が保持されたウォームキャッシュ状態となっているので、再開始処理時にホストコンピュータ１からディスクサブシステム２に対する入出力要求があった場合にキャッシュヒットとなり、実際に磁気ディスク装置上のデータベース領域２４までアクセスする頻度を極端に軽減することができる。
【００６３】
以上説明した様に本実施形態のデータベース処理システムによれば、ホストコンピュータのバッファ上で行われたデータベース処理の内容を示すログ情報に従って記憶装置サブシステム上のデータベース領域のデータを更新するので、ホストコンピュータのバッファ上で行われたデータベース処理の内容を記憶装置サブシステム上のデータベース領域へ反映させる際に、ホストコンピュータと記憶装置サブシステムとの間の入出力処理負荷を低減させることが可能である。
【００６４】
データベース領域へ反映したデータは、記憶装置サブシステム内のキャッシュに格納されているため、反映データを利用する場合や、特にデータを大量に参照するホストコンピュータの障害回復処理の高速化を図ることが可能である。
【００６５】
（実施形態２）
以下にログ情報の内、ＣＯＭＭＩＴされたトランザクションのログ情報を用いて更新を行う実施形態２のデータベース処理システムについて説明する。
実施形態１のログ追跡処理では、全てのログレコードを対象に該当するデータベースブロックヘの反映処理を行ったが、本実施形態ではログ追跡処理の別の実施方法について図８から図１０を用いて説明する。
【００６６】
図８は本実施形態のログ追跡処理においてログブロック中に含まれる全てのログレコードについてトランザクション毎にログを解析した結果の例を示す図である。図８に示す様に本実施形態では、ログブロック２６２ａを解析し、まず当該ディスクサブシステム内のキャッシュメモリ２２とは異なる共用メモリ上に抽出ログバッファ２６４を確保して、抽出ログバッファ２６４に全てのログレコード２６６ａ〜２６６ｌを格納する。
【００６７】
このとき、各ログレコードをトランザクション別に管理する為、トランザクションログ管理テーブル２６８によって各々のログレコードをトランザクション別に管理し、トランザクションＴＲ１からトランザクションＴＲ４までのログレコードのチェインをそれぞれ生成する。
【００６８】
すなわち、トランザクションＴＲ１には、トランザクションログ管理テーブル２６８ａ、２６８ｂ、２６８ｃ、乃至２６８ｆがチェインされ、トランザクションＴＲ２には、トランザクションログ管理テーブル２６８ｅ、２６８ｇがチェインされる。またトランザクションＴＲ３には、トランザクションログ管理テーブル２６８ｈ、２６８ｊ、２６８ｌがチェインされ、トランザクションＴＲ４には、トランザクションログ管理テーブル２６８ｉ、２６８ｋがチェインされる。
【００６９】
この様に、トランザクションログ管理テーブル２６８を各々のトランザクション毎にチェインさせることにより、ログレコード情報にトランザクションの正常決着処理を示すＣＯＭＭＩＴが識別されたトランザクションのログレコードだけを対象にすることができる。
【００７０】
図９は本実施形態の図８のトランザクションログ管理テーブル２６８を用いる際のログレコード分別処理の処理手順を示すフローチャートである。本処理は、図５のステップ３４７で示したＷＲＩＴＥコマンド処理に代わる処理である。
【００７１】
ログブロック中の各ログレコードについて、トランザクション開始を示すトランザクションＢＥＧＩＮログであるかを判定し（ステップ４４１）、トランザクションＢＥＧＩＮログである場合、そのログを抽出ログバッファ２６４へ追加し、トランザクションログ管理テーブル２６８ヘの登録を行う。
【００７２】
ステップ４４１の判定でトランザクションＢＥＧＩＮログではないと判定された場合にはデータベース更新ログであるかを判定し（ステップ４４３）、データベース更新ログである場合には、該当するトランザクション識別子と同じトランザクションログ管理テーブル２６８の最後尾にチェインする。
【００７３】
ステップ４４３の判定でトランザクション更新ログではないと判定された場合には、トランザクションの無効化を示すトランザクションＲＯＬＬＢＡＣＫログかであるかを判定し（ステップ４４５）、トランザクションＲＯＬＬＢＡＣＫ処理である場合には、該当するトランザクション識別子と同じ識別子のトランザクションログ管理テーブル２６８を削除すると同時に抽出ログバッファ２６４の該当するログレコードも削除する。すなわち、ＲＯＬＬＢＡＣＫしたトランザクションのログは、データベースブロックヘ反映されない様にする。
【００７４】
ステップ４４５の判定でトランザクションＲＯＬＬＢＡＣＫログではないと判定された場合には、トランザクションの有効化を示すトランザクションＣＯＭＭＩＴログであるかを判定し（ステップ４４７）、トランザクションＣＯＭＭＩＴログである場合にはログ追跡処理を行う（ステップ４４８）。
【００７５】
ステップ４４７の判定でトランザクションＣＯＭＭＩＴログではないと判定された後、ステップ４４９でログブロックの終了を検出するまでステップ４４１からステップ４４９までを繰り返す。
【００７６】
図１０は本実施形態の図９のステップ４４８におけるログ追跡処理の処理手順を示すフローチャートである。図１０のログ追跡処理では、ＣＯＭＭＩＴしたトランザクションのトランザクションログ管理テーブル２６８の先頭アドレスの次のアドレスが引き渡される。つまり、トランザクションＢＥＧＩＮログを処理の対象から外すことができる。
【００７７】
この処理では、１つのトランザクションの複数のログレコードの集まりについて順次、処理を行っていく。まずステップ４４８１では、ログレコードのログ情報がトランザクションのＣＯＭＭＩＴログであるかどうかを判定し、当該ログレコードが、ＣＯＭＭＩＴログではなく、トランザクション更新ログである場合には、ログレコード中に記録された当該ログ情報に含まれているデータベース領域ＩＤ、ファイルＩＤ及びページ番号と、図２に示したＤＢ−ディスクブロック変換テーブル２８の情報とを比較し、対応する物理ディスクのディスク制御装置番号とドライブ番号とページ番号を識別する（ステップ４４８２）。
【００７８】
次にステップ４４８１で識別した当該データについてキャッシュメモリ２２に対してキャッシュヒットミス判定を行う（ステップ４４８３）。当該データがキャッシュメモリに保持されていないキャッシュミスの場合には、ディスクアクセス制御部２３に対して当該データベースブロックのドライブからキャッシュメモリ２２ヘの転送依頼を行う（ステップ４４８４）。
【００７９】
ステップ４４８３で当該データベースブロックがキャッシュヒットするか、ステップ４４８４で転送処理が終了すると、キャッシュメモリ２２中の当該データベースブロックに、ログレコードに含まれるデータベース更新履歴情報を反映する（ステップ４４８５）。
ステップ４４８１からステップ４４８５までの処理を、当該トランザクションの全ログレコードの処理が完了するまで行う（ステップ４４８６）。
【００８０】
一方、ステップ４４８１の判定でトランザクションＣＯＭＭＩＴログが出現した場合には、当該トランザクションのログについて全て処理を反映し終わっているのでステップ４４８７へ進み、トランザクションログ管理テーブル２６８及びトランザクション抽出ログバッファ２６４から当該トランザクションに関する全ての情報を削除する。
【００８１】
以上説明した様に本実施形態のデータベース処理システムによれば、ログ情報の内、ＣＯＭＭＩＴされたトランザクションのログ情報を用いて更新を行うので、ホストコンピュータのバッファ上で行われたデータベース処理の内容をログ情報によって記憶装置サブシステム上のデータベース領域へ反映させる際の入出力処理を省略することが可能である。
【００８２】
（実施形態３）
以下にデータベース領域のデータの更新を、そのデータベース領域のデータに対応する物理デバイス毎に並列に行う実施形態３のデータベース処理システムについて説明する。
【００８３】
図１１は本実施形態のデータベース処理システムの概略構成を示す図である。本実施形態の処理は、実施形態１及び実施形態２に共通して実施することができる。すなわち、実施形態１の図６におけるログ追跡処理及び実施形態２の図１０におけるログ追跡処理において、データベースブロックのデータベース領域ＩＤ、ファイルＩＤ及びページ番号から、ＤＢ−ディスクブロック変換テーブル２８を使用して物理ドライブのドライブ番号を取得した後、ドライブ毎に異なるプロセッサに処理を分割して実行することで、キャッシュメモリ２２ヘの書き込み処理を並列化する。つまり、キャッシュメモリに書き込むことで、各ドライブへの反映処理を並列処理させることができ、高速なデータ反映が可能となる。ここで本実施形態のディスクサブシステムは、ドライブ毎の処理を実行する複数のプロセッサを備えているものとする。
【００８４】
以上説明した様に本実施形態のデータベース処理システムによれば、ログ情報によるデータベース領域のデータの更新を、そのデータベース領域のデータに対応する物理デバイス毎に並列に行うので、ホストコンピュータのバッファ上で行われたデータベース処理の内容をログ情報によって記憶装置サブシステム上のデータベース領域へ反映させる際に、その処理を効率的に行うことが可能である。
【００８５】
（実施形態４）
以下にディスクサブシステムを追加した場合の実施形態４のデータベース処理システムについて説明する。
図１２は本実施形態のデータベース処理システムの概略構成を示す図である。図１２に示す様に本実施形態のディスクサブシステム１２００はデータ送信処理部３１を有している。データ送信処理部３１は、ログ情報の内容に従って更新されるデータベース領域のデータがディスクサブシステム１２００とは異なるディスクサブシステム１２０１中に存在している場合に、そのログ情報の内容をディスクサブシステム１２０１へ送信する処理部である。
【００８６】
ディスクサブシステム１２００をデータ送信処理部３１として機能させる為のプログラムは、フロッピーディスク等の記録媒体に記録されて実行されるものとする。なお前記プログラムを記録する記録媒体はフロッピーディスク以外の他の記録媒体でも良い。また前記プログラムを当該記録媒体から情報処理装置にインストールして使用しても良いし、ネットワークを通じて当該記録媒体にアクセスして前記プログラムを使用するものとしても良い。
【００８７】
またディスクサブシステム１２０１はデータ受信処理部３２を有している。データ受信処理部３２は、前記送信されたログ情報を受信して、ディスクサブシステム１２０１の更新処理部３０へ、ディスクサブシステム１２０１内のデータベース領域２４のデータの更新を指示する処理部である。
【００８８】
ディスクサブシステム１２０１をデータ受信処理部３２として機能させる為のプログラムは、フロッピーディスク等の記録媒体に記録されて実行されるものとする。なお前記プログラムを記録する記録媒体はフロッピーディスク以外の他の記録媒体でも良い。また前記プログラムを当該記録媒体から情報処理装置にインストールして使用しても良いし、ネットワークを通じて当該記録媒体にアクセスして前記プログラムを使用するものとしても良い。
【００８９】
次に本実施形態について図１２を用いて説明する。本実施形態では、実施形態１で示した構成にもう１つのディスクサブシステムを追加した場合の例を表している。つまり、追加したディスクサブシステム１２０１にはデータベース領域だけが存在する例を示している。
【００９０】
本実施形態では、データベース管理処理部１０が管理するデータベース領域２４がディスクサブシステム１２００及び１２０１に存在している。但し、ログ領域はディスクサブシステム１２００にしか存在していない。この様な場合、ディスクサブシステム１２００のディスク制御処理部２１には、ホストコンピュータ１からＷＲＩＴＥ要求のあったログブロックを判定し、ディスクサブシステム１２０１にログブロックを送信するデータ送信処理部３１が必要になる。また、ディスクサブシステム１２０１にはデータ送信処理部３１から送信されたデータを受信するデータ受信処理部３２が必要となる。
【００９１】
複数台のディスクサブシステムを用いて大規模なデータベースシステムを構築した場合、この様なデータベース領域が配置される場合があるが、本実施形態では、以下の様に処理を行う。
すなわち、ディスクサブシステム１２００のデータ送信処理部３１は、 ログ情報の内容に従って更新されるデータベース領域のデータについて、そのディスク制御装置番号を図２のＤＢ−ディスクブロック変換テーブル２８から求め、その求めたディスク制御装置番号がディスクサブシステム１２００の番号と異なっている場合には、そのディスク制御装置番号のディスクサブシステム、例えばディスクサブシステム１２０１のデータ受信処理部３２へ送信し、データ受信処理部３２により、そのログ情報を受信して、ディスクサブシステム１２０１の更新処理部３０へ、ディスクサブシステム１２０１内のデータベース領域２４のデータの更新を指示する。
【００９２】
以上説明した様に本実施形態のデータベース処理システムによれば、ログ情報の内容に従って更新されるデータベース領域のデータが他の記憶装置サブシステム中に存在している場合に、そのログ情報の内容を当該記憶装置サブシステムへ送信し、その記憶装置サブシステム内でデータベース領域のデータの更新を行うので、複数台の記憶装置サブシステムにデータベース領域を配置している大規模なデータベース処理システムで、ホストコンピュータのバッファ上で行われたデータベース処理の内容を記憶装置サブシステム上のデータベース領域へ反映させる際にも、ホストコンピュータと記憶装置サブシステムとの間の入出力処理負荷を低減させることが可能である。また、反映したデータを利用する場合も複数の記憶装置サブシステム内のキャッシュメモリに格納されているため、並列に参照することができ、高速にアクセスすることが可能である。
【００９３】
【発明の効果】
本発明によればホストコンピュータで行われたデータベース処理の内容を示すログ情報に従って記憶装置サブシステム上のデータベース領域のデータを更新するので、ホストコンピュータで行われたデータベース処理の内容を記憶装置サブシステム上のデータベース領域へ反映させる際に、ホストコンピュータと記憶装置サブシステムとの間の入出力処理負荷を低減させることが可能である。
【図面の簡単な説明】
【図１】実施形態１のデータベース処理システムのシステム構成を示す図である。
【図２】実施形態１のＤＢ−ディスクブロック変換テーブル２８の構成情報を示す図である。
【図３】実施形態１のホストコンピュータ上で認識されるデータベース領域と、オペレーティングシステムが認識する論理ボリュームと、デバイスファイル及びディスクサブシステム内のＬＵへのマッピング関連の例を示す図である。
【図４】実施形態１の受信コマンド解析処理の処理手順を示すフローチャートである。
【図５】実施形態１のＷＲＩＴＥコマンド受領時の処理手順を示すフローチャートである。
【図６】実施形態１のログ追跡処理の処理手順を示すフローチャートである。
【図７】実施形態１のＲＥＡＤコマンド受領時の処理手順を示すフローチャートである。
【図８】実施形態２のログ追跡処理においてログブロック中に含まれる全てのログレコードについてトランザクション毎にログを解析した結果の例を示す図である。
【図９】実施形態２の図８のトランザクションログ管理テーブル２６８を用いる際のログレコード分別処理の処理手順を示すフローチャートである。
【図１０】実施形態２の図９のステップ４４８におけるログ追跡処理の処理手順を示すフローチャートである。
【図１１】実施形態３のデータベース処理システムの概略構成を示す図である。
【図１２】実施形態４のデータベース処理システムの概略構成を示す図である。
【符号の説明】
１…ホストコンピュータ、２…ディスクサブシステム、１２…ＤＢバッファ、１４…ログバッファ、１６…ストレージエリアネットワーク、２２…キャッシュメモリ、２４…データベース領域、２４２…データベースブロック、２６…ログ用ディスク、２６２…ログブロック、２８…ＤＢ−ディスクブロック変換テーブル、１０…データベース管理処理部、２１…ディスク制御処理部、２３…ディスクアクセス制御部、３０…更新処理部、２６４…抽出ログバッファ、２６６…ログレコード、２６８…トランザクションログ管理テーブル、１２００及び１２０１…ディスクサブシステム、３１…データ送信処理部、３２…データ受信処理部。
Claims (10)
- ホストコンピュータのバッファ上で行われたデータベース処理の内容を記憶装置上のデータベースに反映させる処理を行うデータベース処理方法において、
記憶装置サブシステムが、ホストコンピュータから送信されたアクセス要求を受信し、その受信したアクセス要求が書き込み要求または読み込み要求のいずれであるかを判定するステップと、前記受信したアクセス要求が書き込み要求である場合に、前記記憶装置サブシステムが、その書き込み内容がホストコンピュータのバッファ上で行われたデータベース処理の内容を示すログ情報であるかどうかを判定するステップと、前記書き込み内容が前記ログ情報である場合に、前記記憶装置サブシステムが、前記ログ情報中に格納された前記書き込み内容の位置を示すホストコンピュータ側のデータベース処理で認識しているデータベース領域ＩＤ、ファイルＩＤと記憶装置サブシステム上の物理的な位置に対応するディスク制御装置番号、物理ディスクＩＤとの対応関係を示す変換テーブルによって、前記ログ情報中に示された位置情報を記憶装置サブシステム上の物理的な位置情報に変換するステップと、前記記憶装置サブシステムが、その変換した物理的な位置情報で表される記憶装置サブシステム上のデータベース領域のデータを前記ログ情報の内容に従って更新するステップとを有することを特徴とするデータベース処理方法。 - ホストコンピュータのバッファ上で行われたデータベース処理の内容を記憶装置上のデータベースに反映させる処理を行うデータベース処理方法において、
ホストコンピュータのデータベースバッファの内容を記憶装置サブシステム内の記憶装置へ反映させる必要が生じた場合に、そのデータベースバッファに対して行われたデータベース処理の内容を示すログ情報の書き込み要求をホストコンピュータから記憶装置サブシステムへ送信するステップと、データベースバッファ中にデータベース処理でアクセス対象となっているデータが存在していない場合に当該データの読み込み要求をホストコンピュータから記憶装置サブシステムへ送信するステップと、
前記記憶装置サブシステムが、ホストコンピュータから送信されたアクセス要求を受信し、その受信したアクセス要求が書き込み要求または読み込み要求のいずれであるかを判定するステップと、前記受信したアクセス要求が書き込み要求である場合に、前記記憶装置サブシステムが、その書き込み内容が前記ログ情報であるかどうかを判定するステップと、前記書き込み内容が前記ログ情報である場合に、前記記憶装置サブシステムが、前記ログ情報中に格納された前記書き込み内容の位置を示すホストコンピュータ側のデータベース処理で認識しているデータベース領域ＩＤ、ファイルＩＤと記憶装置サブシステム上の物理的な位置に対応するディスク制御装置番号、物理ディスクＩＤとの対応関係を示す変換テーブルによって、前記ログ情報中に示された位置情報を記憶装置サブシステム上の物理的な位置情報に変換するステップと、前記記憶装置サブシステムが、その変換した物理的な位置情報で表される記憶装置サブシステム上のデータベース領域のデータを前記ログ情報の内容に従って更新するステップとを有することを特徴とするデータベース処理方法。 - 前記受信したアクセス要求が読み込み要求である場合に、それ以前の書き込み要求で受信したログ情報中に読み込み対象のデータを更新するログ情報が含まれているかどうかを判定し、前記受信したログ情報中に読み込み対象のデータを更新するログ情報が含まれている場合に、読み込み対象のデータを当該ログ情報の内容に従って更新することを特徴とする請求項１または請求項２のいずれかに記載されたデータベース処理方法。
- 前記ログ情報の内、ＣＯＭＭＩＴされたトランザクションのログ情報を用いて更新を行うことを特徴とする請求項１乃至請求項３のいずれか１項に記載されたデータベース処理方法。
- 前記データベース領域のデータの更新を、そのデータベース領域のデータに対応する物理デバイス毎に並列に行うことを特徴とする請求項１乃至請求項４のいずれか１項に記載されたデータベース処理方法。
- 前記ログ情報の内容に従って更新されるデータベース領域のデータが他の記憶装置サブシステム中に存在している場合に、そのログ情報の内容を当該記憶装置サブシステムへ送信し、その記憶装置サブシステム内でデータベース領域のデータの更新を行うことを特徴とする請求項１乃至請求項５のいずれか１項に記載されたデータベース処理方法。
- ホストコンピュータのバッファ上で行われたデータベース処理の内容を記憶装置上のデータベースに反映させる処理を行う記憶装置サブシステムにおいて、
ホストコンピュータから送信されたアクセス要求を受信し、その受信したアクセス要求が書き込み要求または読み込み要求のいずれであるかを判定する制御処理部と、
前記受信したアクセス要求が書き込み要求である場合に、その書き込み内容がホストコンピュータのバッファ上で行われたデータベース処理の内容を示すログ情報であるかどうかを判定し、前記書き込み内容が前記ログ情報である場合に、前記ログ情報中に格納された前記書き込み内容の位置を示すホストコンピュータ側のデータベース処理で認識しているデータベース領域ＩＤ、ファイルＩＤと記憶装置サブシステム上の物理的な位置に対応するディスク制御装置番号、物理ディスクＩＤとの対応関係を示す変換テーブルによって、前記ログ情報中に示された位置情報を記憶装置サブシステム上の物理的な位置情報に変換し、その変換した物理的な位置情報で表される記憶装置サブシステム上のデータベース領域のデータを前記ログ情報の内容に従って更新する更新処理部とを備えることを特徴とする記憶装置サブシステム。 - 前記更新処理部は、受信したアクセス要求が読み込み要求である場合に、それ以前の書き込み要求で受信したログ情報中に読み込み対象のデータを更新するログ情報が含まれているかどうかを判定し、前記受信したログ情報中に読み込み対象のデータを更新するログ情報が含まれている場合に、読み込み対象のデータを当該ログ情報の内容に従って更新するものであることを特徴とする請求項７に記載された記憶装置サブシステム。
- ホストコンピュータのバッファ上で行われたデータベース処理の内容を記憶装置上のデータベースに反映させる処理を行うデータベース処理システムにおいて、
ホストコンピュータのデータベースバッファの内容を記憶装置サブシステム内の記憶装置へ反映させる必要が生じた場合に、そのデータベースバッファに対して行われたデータベース処理の内容を示すログ情報の書き込み要求をホストコンピュータから記憶装置サブシステムへ送信し、データベースバッファ中にデータベース処理でアクセス対象となっているデータが存在していない場合に当該データの読み込み要求をホストコンピュータから記憶装置サブシステムへ送信するデータベース管理処理部と、
ホストコンピュータから送信されたアクセス要求を受信し、その受信したアクセス要求が書き込み要求または読み込み要求のいずれであるかを判定する制御処理部と、
前記受信したアクセス要求が書き込み要求である場合に、その書き込み内容が前記ログ情報であるかどうかを判定し、前記書き込み内容が前記ログ情報である場合に、前記ログ情報中に格納された前記書き込み内容の位置を示すホストコンピュータ側のデータベース処理で認識しているデータベース領域ＩＤ、ファイルＩＤと記憶装置サブシステム上の物理的な位置に対応するディスク制御装置番号、物理ディスクＩＤとの対応関係を示す変換テーブルによって、前記ログ情報中に示された位置情報を記憶装置サブシステム上の物理的な位置情報に変換し、その変換した物理的な位置情報で表される記憶装置サブシステム上のデータベース領域のデータを前記ログ情報の内容に従って更新する更新処理部とを備えることを特徴とするデータベース処理システム。 - ホストコンピュータのバッファ上で行われたデータベース処理の内容を記憶装置上のデータベースに反映させる処理を行う記憶装置サブシステムとしてコンピュータを機能させる為のプログラムにおいて、
ホストコンピュータから送信されたアクセス要求を受信し、その受信したアクセス要求が書き込み要求または読み込み要求のいずれであるかを判定する制御処理部と、
前記受信したアクセス要求が書き込み要求である場合に、その書き込み内容がホストコンピュータのバッファ上で行われたデータベース処理の内容を示すログ情報であるかどうかを判定し、前記書き込み内容が前記ログ情報である場合に、前記ログ情報中に格納された前記書き込み内容の位置を示すホストコンピュータ側のデータベース処理で認識しているデータベース領域ＩＤ、ファイルＩＤと記憶装置サブシステム上の物理的な位置に対応するディスク制御装置番号、物理ディスクＩＤとの対応関係を示す変換テーブルによって、前記ログ情報中に示された位置情報を記憶装置サブシステム上の物理的な位置情報に変換し、その変換した物理的な位置情報で表される記憶装置サブシステム上のデータベース領域のデータを前記ログ情報の内容に従って更新する更新処理部としてコンピュータを機能させることを特徴とするプログラム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002368688A JP4393762B2 (ja) | 2002-12-19 | 2002-12-19 | データベース処理方法及び装置並びにその処理プログラム |
| US10/628,467 US7031984B2 (en) | 2002-12-19 | 2003-07-29 | Disaster recovery processing method and apparatus and storage unit for the same |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002368688A JP4393762B2 (ja) | 2002-12-19 | 2002-12-19 | データベース処理方法及び装置並びにその処理プログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004199498A JP2004199498A (ja) | 2004-07-15 |
| JP4393762B2 true JP4393762B2 (ja) | 2010-01-06 |
Family
ID=32708111
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002368688A Expired - Fee Related JP4393762B2 (ja) | 2002-12-19 | 2002-12-19 | データベース処理方法及び装置並びにその処理プログラム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US7031984B2 (ja) |
| JP (1) | JP4393762B2 (ja) |
Families Citing this family (45)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2003316522A (ja) * | 2002-04-26 | 2003-11-07 | Hitachi Ltd | 計算機システムおよび計算機システムの制御方法 |
| JP4290975B2 (ja) * | 2002-12-19 | 2009-07-08 | 株式会社日立製作所 | データベース処理方法及び装置並びにその処理プログラム及びディザスタリカバリ方法及びシステム |
| JP4301849B2 (ja) * | 2003-03-31 | 2009-07-22 | 株式会社日立製作所 | 情報処理方法及びその実施システム並びにその処理プログラム並びにディザスタリカバリ方法およびシステム並びにその処理を実施する記憶装置およびその制御処理方法 |
| JP4386694B2 (ja) | 2003-09-16 | 2009-12-16 | 株式会社日立製作所 | 記憶システム及び記憶制御装置 |
| JP2005157712A (ja) * | 2003-11-26 | 2005-06-16 | Hitachi Ltd | リモートコピーネットワーク |
| JP4452533B2 (ja) | 2004-03-19 | 2010-04-21 | 株式会社日立製作所 | システムおよび記憶装置システム |
| JP4561168B2 (ja) * | 2004-04-28 | 2010-10-13 | 株式会社日立製作所 | データ処理システムおよび方法並びにその処理プログラム |
| JP4575059B2 (ja) * | 2004-07-21 | 2010-11-04 | 株式会社日立製作所 | ストレージ装置 |
| JP4518485B2 (ja) | 2004-10-20 | 2010-08-04 | 株式会社日立製作所 | データベースの再編成方法、ストレージ装置及びストレージシステム |
| US7577805B2 (en) * | 2004-11-01 | 2009-08-18 | Hitachi, Ltd. | Using bandwidth and capacity parameters to control remote copy operations in storage systems |
| JP2006293850A (ja) * | 2005-04-13 | 2006-10-26 | Hitachi Ltd | リモートコピーシステムおよびリモートコピー方法 |
| US7606801B2 (en) * | 2005-06-07 | 2009-10-20 | Varonis Inc. | Automatic management of storage access control |
| JP4806557B2 (ja) * | 2005-10-18 | 2011-11-02 | 株式会社日立製作所 | ログを管理するストレージ装置及び計算機システム |
| JP4762693B2 (ja) * | 2005-11-22 | 2011-08-31 | 株式会社日立製作所 | ファイルサーバ、ファイルサーバのログ管理システム及びファイルサーバのログ管理方法 |
| US7761426B2 (en) * | 2005-12-07 | 2010-07-20 | International Business Machines Corporation | Apparatus, system, and method for continuously protecting data |
| US8561146B2 (en) | 2006-04-14 | 2013-10-15 | Varonis Systems, Inc. | Automatic folder access management |
| JP4833734B2 (ja) * | 2006-05-19 | 2011-12-07 | 株式会社日立製作所 | データベースシステム、ストレージ装置、初期コピー方法及びログ適用方法 |
| US7558982B2 (en) * | 2006-09-01 | 2009-07-07 | Siemens Communications, Inc. | Presence enhanced disaster/overload recovery |
| US8239925B2 (en) * | 2007-04-26 | 2012-08-07 | Varonis Systems, Inc. | Evaluating removal of access permissions |
| US8266114B2 (en) | 2008-09-22 | 2012-09-11 | Riverbed Technology, Inc. | Log structured content addressable deduplicating storage |
| US20100211616A1 (en) * | 2009-02-16 | 2010-08-19 | Rajesh Khandelwal | Performance by Avoiding Disk I/O for Deduplicated File Blocks |
| US9641334B2 (en) * | 2009-07-07 | 2017-05-02 | Varonis Systems, Inc. | Method and apparatus for ascertaining data access permission of groups of users to groups of data elements |
| CN102656553B (zh) * | 2009-09-09 | 2016-02-10 | 瓦欧尼斯系统有限公司 | 企业级数据管理 |
| US20110061093A1 (en) * | 2009-09-09 | 2011-03-10 | Ohad Korkus | Time dependent access permissions |
| US10229191B2 (en) | 2009-09-09 | 2019-03-12 | Varonis Systems Ltd. | Enterprise level data management |
| US8578507B2 (en) * | 2009-09-09 | 2013-11-05 | Varonis Systems, Inc. | Access permissions entitlement review |
| US8533787B2 (en) | 2011-05-12 | 2013-09-10 | Varonis Systems, Inc. | Automatic resource ownership assignment system and method |
| US10037358B2 (en) | 2010-05-27 | 2018-07-31 | Varonis Systems, Inc. | Data classification |
| WO2011148375A1 (en) | 2010-05-27 | 2011-12-01 | Varonis Systems, Inc. | Automation framework |
| US10296596B2 (en) | 2010-05-27 | 2019-05-21 | Varonis Systems, Inc. | Data tagging |
| US9870480B2 (en) | 2010-05-27 | 2018-01-16 | Varonis Systems, Inc. | Automatic removal of global user security groups |
| US9147180B2 (en) | 2010-08-24 | 2015-09-29 | Varonis Systems, Inc. | Data governance for email systems |
| JP5665518B2 (ja) * | 2010-12-14 | 2015-02-04 | キヤノン株式会社 | データベースシステム、その情報処理方法、およびそのプログラム |
| US8560628B2 (en) * | 2011-01-11 | 2013-10-15 | International Business Machines Corporation | Supporting autonomous live partition mobility during a cluster split-brained condition |
| US8909673B2 (en) | 2011-01-27 | 2014-12-09 | Varonis Systems, Inc. | Access permissions management system and method |
| WO2012101620A1 (en) | 2011-01-27 | 2012-08-02 | Varonis Systems, Inc. | Access permissions management system and method |
| US9680839B2 (en) | 2011-01-27 | 2017-06-13 | Varonis Systems, Inc. | Access permissions management system and method |
| KR101331452B1 (ko) * | 2012-03-22 | 2013-11-21 | 주식회사 엘지씨엔에스 | 데이터베이스 관리 방법 및 그를 위한 데이터베이스 관리 서버 |
| US11151515B2 (en) | 2012-07-31 | 2021-10-19 | Varonis Systems, Inc. | Email distribution list membership governance method and system |
| US9152506B2 (en) * | 2012-09-20 | 2015-10-06 | Hitachi, Ltd. | Management apparatus and management method |
| US9251363B2 (en) | 2013-02-20 | 2016-02-02 | Varonis Systems, Inc. | Systems and methodologies for controlling access to a file system |
| US9396089B2 (en) * | 2014-05-30 | 2016-07-19 | Apple Inc. | Activity tracing diagnostic systems and methods |
| US9477555B1 (en) * | 2015-11-16 | 2016-10-25 | International Business Machines Corporation | Optimized disaster-recovery-as-a-service system |
| US11706227B2 (en) | 2016-07-20 | 2023-07-18 | Varonis Systems Inc | Systems and methods for processing access permission type-specific access permission requests in an enterprise |
| WO2018195672A1 (en) * | 2017-04-28 | 2018-11-01 | Groupe De Développement Icrtech | Probabilistic based system and method for decision making in the context of argumentative structures |
Family Cites Families (21)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4751702A (en) | 1986-02-10 | 1988-06-14 | International Business Machines Corporation | Improving availability of a restartable staged storage data base system that uses logging facilities |
| JPS6364144A (ja) | 1986-09-04 | 1988-03-22 | Hitachi Ltd | 記憶装置間デ−タ転送方式 |
| US5544347A (en) | 1990-09-24 | 1996-08-06 | Emc Corporation | Data storage system controlled remote data mirroring with respectively maintained data indices |
| US5280611A (en) * | 1991-11-08 | 1994-01-18 | International Business Machines Corporation | Method for managing database recovery from failure of a shared store in a system including a plurality of transaction-based systems of the write-ahead logging type |
| US5530855A (en) | 1992-10-13 | 1996-06-25 | International Business Machines Corporation | Replicating a database by the sequential application of hierarchically sorted log records |
| US5758355A (en) | 1996-08-07 | 1998-05-26 | Aurum Software, Inc. | Synchronization of server database with client database using distribution tables |
| US6173292B1 (en) | 1998-03-04 | 2001-01-09 | International Business Machines Corporation | Data recovery in a transactional database using write-ahead logging and file caching |
| US6226651B1 (en) | 1998-03-27 | 2001-05-01 | International Business Machines Corporation | Database disaster remote site recovery |
| SE515459C2 (sv) | 1999-02-10 | 2001-08-06 | Ericsson Telefon Ab L M | Metod för att synkronisera en värddatabas och en fjärrdatabas |
| JP3763992B2 (ja) | 1999-03-30 | 2006-04-05 | 富士通株式会社 | データ処理装置及び記録媒体 |
| US6643795B1 (en) | 2000-03-30 | 2003-11-04 | Hewlett-Packard Development Company, L.P. | Controller-based bi-directional remote copy system with storage site failover capability |
| JP2001356945A (ja) | 2000-04-12 | 2001-12-26 | Anetsukusu Syst Kk | データバックアップ・リカバリー方式 |
| US6801921B2 (en) | 2000-09-08 | 2004-10-05 | Hitachi, Ltd. | Method and system for managing multiple database storage units |
| US20020103815A1 (en) | 2000-12-12 | 2002-08-01 | Fresher Information Corporation | High speed data updates implemented in an information storage and retrieval system |
| US6748502B2 (en) | 2001-01-12 | 2004-06-08 | Hitachi, Ltd. | Virtual volume storage |
| US7177866B2 (en) | 2001-03-16 | 2007-02-13 | Gravic, Inc. | Asynchronous coordinated commit replication and dual write with replication transmission and locking of target database on updates only |
| US7103586B2 (en) | 2001-03-16 | 2006-09-05 | Gravic, Inc. | Collision avoidance in database replication systems |
| JP4076326B2 (ja) | 2001-05-25 | 2008-04-16 | 富士通株式会社 | バックアップシステム、データベース装置、データベース装置のバックアップ方法、データベース管理プログラム、バックアップ装置、バックアップ方法および、バックアッププログラム |
| US20040107381A1 (en) * | 2002-07-12 | 2004-06-03 | American Management Systems, Incorporated | High performance transaction storage and retrieval system for commodity computing environments |
| US8121978B2 (en) * | 2002-11-15 | 2012-02-21 | Sybase, Inc. | Database system providing improved methods for data replication |
| US20040133507A1 (en) * | 2003-01-02 | 2004-07-08 | Paul Barbour | Method and system for conducting financial transactions using single use credit card numbers |
-
2002
- 2002-12-19 JP JP2002368688A patent/JP4393762B2/ja not_active Expired - Fee Related
-
2003
- 2003-07-29 US US10/628,467 patent/US7031984B2/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004199498A (ja) | 2004-07-15 |
| US7031984B2 (en) | 2006-04-18 |
| US20040139124A1 (en) | 2004-07-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4393762B2 (ja) | データベース処理方法及び装置並びにその処理プログラム | |
| JP4290975B2 (ja) | データベース処理方法及び装置並びにその処理プログラム及びディザスタリカバリ方法及びシステム | |
| US7657584B2 (en) | Reorganization method of database and a database reorganization system | |
| JP4131514B2 (ja) | ネットワークシステム、サーバ、データ処理方法及びプログラム | |
| JP3522527B2 (ja) | 入出力制御装置および入出力制御方法 | |
| US6216199B1 (en) | Hardware mechanism for managing cache structures in a data storage system | |
| US7996445B2 (en) | Block reallocation planning during read-ahead processing | |
| US7958318B2 (en) | Coherency maintaining device and coherency maintaining method | |
| US7302454B2 (en) | Method and system for data processing with data backup | |
| US6009498A (en) | Disk control unit for holding track data in cache memory | |
| US20210157746A1 (en) | Key-value storage device and system including the same | |
| JP3228972B2 (ja) | 医用画像保管通信システム | |
| US8230191B2 (en) | Recording medium storing allocation control program, allocation control apparatus, and allocation control method | |
| CN105190573A (zh) | 存储数据的减少冗余 | |
| CN107148622B (zh) | 智能闪存高速缓存记录器 | |
| US6101574A (en) | Disk control unit for holding track data in non-volatile cache memory | |
| JP4561168B2 (ja) | データ処理システムおよび方法並びにその処理プログラム | |
| US6658541B2 (en) | Computer system and a database access method thereof | |
| JP3324572B2 (ja) | 情報処理装置並びにコンピュータに実行させるためのプログラムを記録した記録媒体 | |
| KR102061069B1 (ko) | 텍스쳐 맵핑 파이프라인을 위한 논블로킹 방식의 텍스쳐 캐쉬 메모리 시스템 및 논블로킹 방식의 텍스쳐 캐쉬 메모리의 동작 방법 | |
| JP2005316632A (ja) | キャッシュ制御およびデータ処理システム並びにその処理プログラム | |
| US11789908B2 (en) | Offloading memory maintenance for a log-structured file system | |
| JP3555523B2 (ja) | メモリ管理装置及び管理方法並びに管理プログラムを記録した記録媒体 | |
| JP3335919B2 (ja) | ディスクキャッシュ制御装置 | |
| CN116431076A (zh) | 一种日志追加型文件系统闪存的数据缓存管理装置及方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20051111 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20081128 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20081209 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090206 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20090331 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090424 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20090603 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20091013 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20091014 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4393762 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121023 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121023 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131023 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |