JP2006119822A - データベースの再編成方法、ストレージ装置及びストレージシステム - Google Patents

Abstract

【課題】データベースの再編成処理を実行するストレージシステム提供する。
【解決手段】ホストコンピュータからの要求に基づいて、ストレージ装置のディスクドライブに保存されるデータベースの再編成方法であって、ディスクドライブは、データベースを保存する第一のボリュームと、第一のボリュームとペアを構成し、データベースの複製を格納する第二のボリュームとを含み、ホストコンピュータのトランザクションを静止化し、第一のボリュームと第二のボリュームのペアを分割し、第一のボリュームに対してのみ、データベースへアクセスするように設定し、トランザクションの静止化を解除し、第二のボリュームを再編成し、第二のボリュームの内容を第一のボリュームに複写し、第一のボリュームと第二のボリュームとのペアを再同期する手順を含む。
【選択図】図１

Description

本発明は、データベースを運用するストレージシステムに関し、特にデータベースの再編成方法に関する。

従来、データベースを管理するＤＢＭＳ（Data Base Management System）は、データベースの応答性を高めるように設計されている。ストレージ等の記憶空間は、データベースの保存領域を頻繁に変えないなど、できるだけ複雑な管理を避けるように設計されている。従って、ＤＢＭＳの記憶空間は、運用の時間経過に伴って、徐々に「乱れ」が発生する。「乱れ」とは、断片化空間や未回収領域、空間管理構造の不均衡化が発生していることである。記憶空間の乱れは、データベースの応答性を劣化させ、記憶空間の予想外の消費を発生させる。

記憶空間の乱れを解消するために、多くのＤＢＭＳには専用のソフトウェアが用意されている。このソフトウェアは、断片化の解消、未回収領域の回収、空間管理構造の均衡化を行うことによって、記憶空間を乱れのない理想的な状態に変化させる。この処理を「再編成」と呼ぶ。

ＤＢＭＳの管理者は、定期的に再編成用ソフトウェアを用いて再編成を行うことによって、データベースの応答性の劣化、記憶空間の予想外の消費を解消する必要がある。

例えば、このようなＤＢＭＳとしては、ホストコンピュータからのアクセス要求が書き込み要求であり、その書き込み内容がホストコンピュータのバッファ上で行われたデータベース処理の内容を示すログ情報である場合に、ホストコンピュータ側で認識している論理的な位置情報と正記憶装置サブシステム上の物理的な位置情報との対応関係を示す変換テーブルによって、前記ログ情報中に示された位置情報を正記憶装置サブシステム上の物理的な位置情報に変換するステップと、その変換した物理的な位置情報で表される正記憶装置サブシステム上のデータベース領域のデータを前記ログ情報の内容に従って更新し、前記アクセス要求を副記憶装置サブシステムへ送信するステップとを有するものがある（例えば、特許文献１参照。）。

また、ホストコンピュータからのアクセス要求が書き込み要求であり、その書き込み内容がホストコンピュータのバッファ上で行われたデータベース処理の内容を示すログ情報であるかどうかを判定するステップと、前記書き込み内容が前記ログ情報である場合に、ホストコンピュータ側のデータベース処理で認識している論理的な位置情報と記憶装置サブシステム上の物理的な位置情報との対応関係を示す変換テーブルによって、前記ログ情報中に示された位置情報を記憶装置サブシステム上の物理的な位置情報に変換するステップと、その変換した物理的な位置情報で表される記憶装置サブシステム上のデータベース領域のデータを前記ログ情報の内容に従って更新するステップとを有するものがある（例えば特許文献２参照。）。
特開２００４−１９９４９７号公報 特開２００４−１９９４９８号公報

前記の従来の再編成については、二つの問題点がある。

第一に、今日利用可能な再編成ソフトウェアは、システムの停止を必要とする。また、運用中に再編成を実行する場合ではサービスの性能劣化が著しい。このため、ＤＢＭＳ管理者は、膨大なＤＢＭＳのパラメータ設定と周到な管理計画の元に再編成を実行する必要がある。これは、ＤＢＭＳ管理を困難なものにし、結果的にＩＴシステムの管理コストの高騰を招いている。

第二に、多くのＩＴシステムが２４時間稼働するようになり、再編成による副作用、即ち、サービス停止や性能劣化はもはやユーザに受け入れられない。このようなシステムにおいては、再編成ソフトウェアによる再編成処理そのものが困難である。

本発明は、ホストコンピュータからの要求に基づいて、ストレージ装置のディスクドライブに保存されるデータベースの再編成方法であって、ディスクドライブは、データベースを保存する第一のボリュームと、第一のボリュームとペアを構成し、データベースの複製を格納する第二のボリュームとを含み、ホストコンピュータのトランザクションを静止化し、第一のボリュームと第二のボリュームのペアを分割し、第一のボリュームに対してのみ、データベースへアクセスするように設定し、トランザクションの静止化を解除し、第二のボリュームを再編成し、第二のボリュームの内容を第一のボリュームに複写し、第一のボリュームと第二のボリュームとのペアを再同期する手順を含むことを特徴とする。ストレージ装置では、再編成中にデータベースになされたトランザクションのログを格納しておき、再編成終了後に、当該ログをデータベースに反映させる。このようにすることで、データベースシステムの処理を停止することなく、データベースの再編成処理が可能となる。

従って、本発明によると、ホストコンピュータからの指示によって、ストレージ装置に、データベースの再編成処理を行わせることが可能となる。

以下、本発明の実施の形態を図面を参照して説明する。

図１は、本実施の形態の、データベースシステムのブロック図である。

ホストコンピュータ１００が、ＳＡＮ（Storage Area Network）３００を介してストレージ装置２００に接続している。

ホストコンピュータ１００は、ＳＡＮ３００を介してストレージ装置２００のデータの操作を要求する。ストレージ装置２００は、その結果をホストコンピュータ１００に返す。なお、本発明のデータベースシステムはＳＡＮに限定されるものではなく、ホストコンピュータ１００とストレージ装置２００とのネットワーク機能を実現するものであればよい。

ホストコンピュータ１００は、ＣＰＵ１１０、メモリ１２０等によって構成される。ＣＰＵ１１０は、各種プログラムを実行してホストコンピュータ１００を制御する。メモリ１２０は、データベース管理システム１３０を格納する。このＤＢ管理システム１３０は、プログラムによって構成される。このプログラムがＣＰＵ１１０によって実行されることで、ホストコンピュータ１００がＤＢ管理システム１３０として機能する。

なお、ＤＢ管理システム１３０はソフトウェアで構成されなくてもよい。例えば、オブジェクトによって実現されるものであっても、ハードウェア構成によって実現されるものであってもよい。また、ホストコンピュータ１００は、仮想計算機であってもよい。

ＤＢ管理システム１３０は、ＤＢアクセス制御部１４０、ＤＢ運用操作制御部１５０、ログバッファ１６０及びＤＢバッファ１７０によって構成される。

ＤＢアクセス制御部１４０は、ＤＢバッファ１６０に格納された内容をストレージ装置２００内のディスクドライブ２２０のデータとして反映させる。このとき、ＤＢバッファ１６０の内容を示すログ情報をログバッファ１７０に格納する。格納されたログ情報は、ストレージ装置２００内のディスクドライブのデータとして反映される。

ＤＢアクセス制御部１４０は、ＤＢ問合せ制御部１４１、ＤＢアクセス処理部１４２及びログ出力処理部１４３によって構成される。ＤＢ問合せ制御部１４１は、データベースの表空間（インデックス）を参照して、データベースの格納位置を取得する。ＤＢアクセス処理部１４２は、データベースにデータを書き込み、又はデータを読み出す。ログ出力処理部１４３は、データベース処理の内容を示すログをストレージ装置２００に格納させる。

ＤＢ運用操作制御部１５０は、ストレージ装置２００にデータベースの運用に関する処理を指示する。具体的には、ＤＢ運用操作制御部１５０は、データベースのバックアップや再編成処理を指示する。

ＤＢ運用操作制御部１５０は、ＤＢ再編成処理部１５１、ＤＢバックアップ制御部１５２、ＤＢ回復制御部１５３及びＤＢ状態解析制御部１５４によって構成される。

ＤＢ再編成処理部１５１は、データベースの空間の乱れや不均衡化を解決するための再編成処理をストレージ装置２００に指示する。

ＤＢバックアップ制御部１５２は、データベースのバックアップ作成処理をストレージ装置２００に指示する。

ＤＢ回復制御部１５３は、データベースの回復を制御する。

ＤＢ状態回復制御部１５４は、ストレージ装置２００にデータベースの状態を問い合わせ、データベースの状態を解析する。たとえば、データベースの空間の乱れや不均衡化の状態を解析する。

ストレージ装置２００は、ディスク制御部２１０及びディスクドライブ２２０によって構成される。

ディスク制御部２１０は、ディスクドライブ２２０へのデータの読み書きを制御する。

ディスク制御部２１０は、キャッシュメモリ２１１、ホストインタフェース処理部２１２、ＤＢ再編成処理部２１３、ボリュームコピー処理部２１４及びディスクアクセス制御部２１５によって構成される。

キャッシュメモリ２１１は、ディスクドライブ２２０に読み書きされるデータを一時的に格納する。

ホストインタフェース処理部２１２は、ホストコンピュータ１００から送られた要求を解析し、当該要求をディスク制御部２１０の他の処理部に送る。また、ディスク制御部２１０の他の処理部から受け取った結果をホストコンピュータ１００に返す。

ＤＢ再編成処理部２１３は、ディスクドライブ２２０に生じたデータベースの空間の乱れや不均衡化を解決する再編成処理を実行する。

ボリュームコピー処理部２１４は、ディスクドライブ２２０のボリューム間のコピー、ボリューム間の同期及びボリューム間の同期の解除等を制御する。

ディスクアクセス制御部２１５は、ディスクドライブ２２０に、ＳＣＳＩやＦｉｂｒｅＣｈａｎｎｅｌ等のプロトコルに基づいてアクセスする。

ディスクドライブ２２０は、一つ以上の磁気ディスクドライブによって構成される。

これら複数の磁気ディスクドライブは、ＲＡＩＤ構成等によって論理的な領域が構成される。この領域は複数の領域（ＬＵ：論理ユニット）に論理的に分割される。そして、データを格納する領域である論理ボリュームが、一つ以上の論理ユニットによって構成される。

なお、本実施形態の各処理部や制御部は、オブジェクトやプログラム、プロセス、スレッド等によって実現されるものであってもよい。また、ハードウェア構成によって実現されるものであってもよい。

ディスクドライブ２２０には、ログ２２１、正ＤＢ２２２、副ＤＢ２２３、ＤＢ定義情報２２４、ＤＢ−ディスクブロック変換テーブル２２５及びアドレス変換表２２６等の複数のデータ格納領域が構成される。はお、本発明のディスクドライブ２２０はハードディスクに限定されるものではなく、データを記憶できる機能を有するものであればよい。

ログ２２１は、データベース処理における差分ログを格納する。

正ＤＢ２２２は、ホストコンピュータ１００によってアクセスされるデータベースを格納する。

副ＤＢ２２３は、正ＤＢ２２２の複製を格納する。業務運用時は、正ＤＢ２２２及び副ＤＢ２２３は同期状態である。すなわち、ホストコンピュータ１００から正ＤＢ２２２への書き込みデータは、副ＤＢ２２３にも書き込まれる。正ＤＢ２２２及び副ＤＢ２２３が同期状態であれば、正ＤＢ２２２及び副ＤＢ２２３の内容は同一となる。

ＤＢ定義情報２２４は、ディスクドライブ２２０に格納されるデータベースの構成情報を格納する。データベースの構成情報は、例えば、データベース名、各データベースのデータ及び索引のスキーマ、統計情報等である。

ＤＢ−ディスクブロック変換テーブル２２５は、データベースの各データと当該データが格納されている物理的な位置との対応が格納される。

アドレス変換表２２６は、データベースの再編成処理及びその後の追い付き処理に用いられる。アドレス変換表２２６には、再編成処理の前後でデータのディスクドライブ２２０上の物理的な格納位置が変更された場合に、その前後の物理的な位置が格納される。

なお、アドレス変換表２２６は、ディスクドライブ２２０ではなく、メモリ上の領域の保存されるものであってもよい。

次に、ディスクドライブ２２０に保存されるデータベースの構成を説明する。

ディスクドライブ２２０に保存されるデータは、主にデータベースの本体である「表データ」及びその検索や一覧のために用いられる「索引データ」によって構成される。

図２は、表データの説明図である。

表データは、複数の表ブロックから構成される。この複数の表ブロックによってファイルが構成される。各表ブロックには保存データの最小構成単位である「行」が含まれている。

図２の例では、ファイル１が四つの表ブロックによって構成されていることを示す。このファイルの構成はＤＢ−ディスクブロック変換テーブル２２５（図４参照）に格納されている。

図３は、索引データの説明図である。

索引データは、ブロックの集合から構成され、これらのブロックは木構造となっている。

木構造は、根ブロック、枝ブロック及び葉ブロックから構成される。根ブロックには参照先の枝ブロックのアドレスが格納される。枝ブロックには参照先の葉ブロックのアドレスが格納される。葉ブロックには索引エントリが格納される。索引エントリは、キー値、重複数、行アドレスによって構成される。キー値は、データベースのデータを検索するための検索キーが格納される。重複数は、参照先の重複の数を示す情報が格納される。行エントリは、表データの行アドレスが格納される。

ＤＢ管理システム１３０は、検索キーを用いてこの索引データを検索することによって、表データの行アドレスを得る。そして、この行アドレスを用いて表データにアクセスする。

図４は、ＤＢ−ディスクブロック変換テーブル２２５の一例の表である。

ＤＢ−ディスクブロック変換テーブル２２５は、データベース領域ＩＤ２２５１、種別２２５２、ファイルＩＤ２２５３、ブロック長２２５４、論理ボリュームＩＤ２２５５、物理デバイスＩＤ２２５６及び相対位置２２５７によって構成される。

データベース領域ＩＤ２２５１は、データベースが格納されるデータベース領域毎に付けられる固有の識別子である。

種別２２５２は、データベース領域に格納されるデータベースの種別である。種別には、ＤＢ（データベースを示す）、ログ等の情報が格納される。

ファイルＩＤ２２５３は、その領域に格納されるデータベース領域が複数のファイルで構成されている場合に、そのファイル毎に付けられる固有の識別子である。

ブロック長２２５４は、そのデータベース領域を構成する表ブロックの長さ（サイズ）が示される。

論理ボリュームＩＤ２２５５は、そのデータベース領域の構成ファイルが格納されている論理ボリュームを識別するための識別子である。

物理デバイスＩＤ２２５６は、論理ボリュームＩＤによって識別される論理ボリュームがマッピングされている物理デバイスを識別するための識別子である。具体的には、ＬＵ毎に個別に付けられる番号であるＬＵＮ（Logical Unit Number）である。

相対位置２２５７は、そのデータベースが格納される領域はＬＵの中のどの場所であるか、ＬＵの相対位置によって示される。具体的にはＬＢＡ（Logical Block Address）が格納される。

本実施形態のデータベースを構成するファイルは、ホストコンピュータ１００で稼働しているオペレーティングシステムが認識するファイルシステムとして論理ボリュームにマッピングされる。また、論理ボリュームは、ストレージ装置２００の物理デバイスであるディスクドライブ２２０に対応したデバイスファイルとしてマッピングされる。

ストレージ装置２００内では、デバイスファイルは、ＬＵに対応している。従って、データベース領域を構成するファイルは、最終的に物理デバイスであるディスクドライブの磁気ディスクドライブにマッピングされる。対応する物理情報は、ストレージ装置２００内の磁気ディスクドライブを識別するための物理デバイスＩＤと、物理デバイス内の相対位置であるＬＢＡである。

図５は、マッピングの関係を示す説明図である。

図５は、ホストコンピュータ１００によって認識されるデータベース領域、ホストコンピュータ１００で稼働するオペレーティングシステムによって認識される論理ボリューム、デバイスファイル、及び、ストレージ装置２００のＬＵのマッピング関連の例を示す。

データベース管理システム１３０は、データを格納するデータベース領域は、複数のファイルから構成されるものとして認識する。構成される各ファイルは、ホストコンピュータ１００で稼働するオペレーティングシステムのファイルに対応している。なお、図５では、オペレーティングシステムにおいてＲＡＷデバイスとして認識されるケースを想定している。

また、オペレーティングシステムのファイルは、物理的なディスクドライブに対応するデバイスファイルとして管理されている。デバイスファイルは、ストレージ装置２００のＬＵにマッピングされている。

次に、本実施形態のデータベースシステムの処理を説明する。

図６は、ストレージ装置２００の受け付けコマンド解析処理のフローチャートである。

ストレージ装置２００は、ホストコンピュータ１００からの要求に基づいて、この処理を行う。

ホストインタフェース処理部２１２は、ホストコンピュータ１００からの要求を受信し、その内容を解析する。

ホストコンピュータ１００からの要求が読み出し要求（Ｒｅａｄコマンド）又は書き込み要求（Ｗｒｉｔｅコマンド）であった場合は（ステップ１００１）、ステップ１００２に移行する。ステップ１００２では、ホストコンピュータ１００からの要求がＲｅａｄコマンドであるかＷｒｉｔｅコマンドであるかが判定される。

ホストコンピュータ１００からの要求がＲｅａｄコマンドであった場合は、Ｒｅａｄ処理（図７参照）が実行される（ステップ１０１１）。ホストコンピュータ１００からの要求がＷｒｉｔｅコマンドであった場合は、Ｗｒｉｔｅ処理（図８参照）が実行される（ステップ１０１２）。

ホストコンピュータ１００からの要求がボリュームコピーコマンドであった場合は（ステップ１００３）、ボリュームコピー処理（図９参照）が実行される（ステップ１００４）。

ホストコンピュータ１００からの要求がＤＢ再編成コマンドであった場合は（ステップ１００５）、図１１に示すＤＢ再編成処理が実行される（ステップ１００６）。

何れのコマンドでもない場合は、処理が終了される。

図７は、Ｒｅａｄ処理のフローチャートである。

この処理は、ホストインタフェース処理部２１２によって実行される。

まず、受信したコマンドが解析され、当該コマンドの内容及びアクセス先のアドレスを取得する（ステップ１１０１）。

次に、取得されたアクセス先のアドレスのデータが、キャッシュメモリ２１１に格納されているか否かを判定する（ステップ１１０２）。

データがキャッシュメモリ２１１に格納されていると判定した場合は、ステップ１１０５に移行する。

データがキャッシュメモリ２１１に格納されていないと判定した場合は、要求データを読み出してキャッシュメモリ２１１に転送させる旨の転送依頼を、ディスクアクセス制御部２１５に送る（ステップ１１０３）。このとき、転送先のキャッシュメモリ２１１の転送先アドレスのデータが更新されたことを示す情報が、キャッシュメモリ２１１に設けられたキャッシュ管理テーブルに登録される。

この転送要求によって、ディスクドライブ２２０からキャッシュメモリ２１１にデータが転送される。そして、このデータの転送が終了したか否かを判定する（ステップ１１０４）。

データの転送がまだ終了していないと判定した場合は、データの転送が終了するまで待機する。データの転送が完了したと判定した場合は、ステップ１１０５に移行する。

ステップ１１０５では、キャッシュメモリ２１１に格納されている要求データを、ホストコンピュータ１００に送信する。その後、処理を終了する。

このＲｅａｄ処理によって、要求データがホストコンピュータ１００に送信される。

図８は、Ｗｒｉｔｅ処理のフローチャートである。

この処理は、ホストインタフェース処理部２１２によって実行される。

まず、受信したＷｒｉｔｅコマンドが解析され、当該コマンドの内容、アクセス先のアドレス及び書き込みデータを取得する（ステップ１２０１）。

次に、取得したアクセス先のアドレスに既に存在するデータは、キャッシュメモリ２１１に格納されているか否かを判定する（ステップ１２０２）。

データがキャッシュメモリ２１１に格納されていると判定した場合は、ステップ１２０５に移行する。

データがキャッシュメモリ２１１に格納されていないと判定した場合は、当該アドレスに存在するデータを読み出してキャッシュメモリ２１１に転送させる旨の転送要求を、ディスクアクセス制御部２１５に送る（ステップ１２０３）。このとき、転送先のキャッシュメモリ２１１の転送先アドレスのデータが更新されたことを示す情報が、キャッシュメモリ２１１に設けられたキャッシュ管理テーブルに登録される。

この転送要求によって、ディスクドライブ２２０からキャッシュメモリ２１１にデータが転送される。そして、このデータの転送が終了したか否かを判定する（ステップ１２０４）。

データの転送がまだ終了していないと判定した場合は、データの転送が終了するまで待機する。データの転送が完了したと判定した場合は、ステップ１２０５に移行する。

ステップ１２０５では、キャッシュメモリ２１１に格納されているデータを、Ｗｒｉｔｅコマンドによって指示された書き込みデータに更新する。

このデータの更新が完了すると、ステップ１２０６に移行し、Ｗｒｉｔｅ処理が完了した旨を、ホストコンピュータ１００に送信する。その後、処理を終了する。

図９は、ボリュームコピー処理のフローチャートである。

この処理は、ホストインタフェース処理部２１２によって実行される。

ホストインタフェース処理部２１２は、ホストコンピュータ１００からの要求を受信し、その内容を解析する。ボリュームコピーコマンドには、コピー処理及びペア切り離し処理があり、いずれかの処理が選択される。

ホストコンピュータ１００からの要求がペア生成コマンドであった場合は（ステップ１３０１）、コピー処理を実行する（ステップ１３０２）。具体的には、コピー元の論理ボリュームの内容をコピー先の論理ボリュームに全て複写（コピー）する。また。この処理によってコピー元論理ボリューム及びコピー先論理ボリュームが同期状態となる。

ホストコンピュータ１００からの要求がペア分割コマンドであった場合は（ステップ１３０３）、ペア切り離し処理を実行する（ステップ１３０４）。具体的には、同期されている二つの論理ボリュームの同期が解除される。

ホストコンピュータ１００からの要求がペア再同期コマンドであった場合は（ステップ１３０５）、ボリュームコピー処理を実行する（ステップ１３０６）。この処理はステップ１３０２と同様である。

何れのコマンドでもない場合は、処理を終了する。

図１０は、ＤＢ再編成制御処理のフローチャートである。

この処理は、ホストコンピュータ１００のＤＢ再編成制御部１５１によって実行される。

ＤＢ再編成制御処理が開始されると、まず、データベースを静止化する（ステップ１４０１）。具体的には、ＤＢ再編成制御部１５１は、ＤＢアクセス制御部１４０に対して、データベースに対するトランザクションの受け付けを停止させ、実行中のトランザクションを全て完了させる要求を送る。

次に、ボリュームペアを分割する（ステップ１４０２）。具体的には、ＤＢ再編成制御部１５１は、ストレージ装置２００に対してペア分割コマンドを送る。これによって、同期されているボリュームペアである主ＤＢ２２２及び副ＤＢ２２３の同期を解除し、ボリュームペアが分割される。

次に、データベースの処理を受け付けるボリューム（カレントデータベース）を主ＤＢ２２２のみに変更する。その後、データベースの静止化を解除する（ステップ１４０３）。具体的には、ＤＢ再編成制御部１５１は、ＤＢアクセス制御部１４０に、カレントデータベース主ＤＢ２２２のみにする要求を送る。また、ＤＢ再編成処理部１５１は、ＤＢアクセス制御部１４０に、データベースに対するトランザクションの受付を開始する要求を送る。この処理によって、主ＤＢ２２２のみがホストコンピュータ１００のアクセス対象となる
次に、図１１に示すＤＢ再編成処理を実行する（ステップ１４０４）。具体的には、ＤＢ再編成制御部１５１が、ストレージ装置２００に対して、ＤＢ再編成コマンドを送信する。

ＤＢ再編成処理が完了すると、ボリュームペアを再同期させる（ステップ１４０５）。具体的には、ＤＢ再編成制御部１５１は、ストレージ装置２００に対してボリュームペア再同期コマンドを送る。これによって、主ＤＢ２２２及び副ＤＢ２２３がボリュームペアとして再同期される。

この再同期において、副ＤＢ２２３の内容はＤＢ再編理完了後のデータベースの空間の乱れや不均衡化が解決された状態である。この副ＤＢ２２３の内容を主ＤＢ２２２にコピーすることで、主ＤＢ２２２及び副ＤＢ２２３の内容が、共に再編成処理完了後の内容となる。

以上の処理によって、データベースが再編成される。

図１１は、ディスクドライブの再編成処理の説明図である。

この処理は、ＤＢ再編成処理部２１３によって実行される。

図１１では、３つのＬＵ（ＬＩ＃１、ＬＵ＃２及びＬＵ＃３）が示されている。これらはそれぞれ主ＤＢ、副ＤＢ及びログの領域として設定されている。

業務運用時は、ＬＵ＃１及びＬＵ＃２は同期している。ＬＵ＃１、すなわち主ＤＢに対するアクセスは、ＬＵ＃２、すなわち副ＤＢに対しても実行され、ＬＵ＃１とＬＵ＃２との内容は常に同一となる。また、このアクセスのログがＬＵ＃３に格納される。

まず、データベースの静止化が実行され、トランザクションの受け付けを停止する。データベースの静止化が完了すると、ＬＵ＃１とＬＵ＃２との同期を解除し、ＬＵ＃１とＬＵ＃２とでのボリュームペアが分割される。

ボリュームペアが分割されると、データベースの静止化が解除され、トランザクションの受け付けが再開される。このとき、データベースのアクセスはＬＵ＃１に対してのみ行われるよう設定を変更する。

この状態でＬＵ＃２の再編成処理が実行される。ＬＵ＃１とＬＵ＃２とは分割され非同期状態にあるので、システムの運用は再編成処理の影響を受けない。また、再編成処理中のアクセスのログはＬＵ＃３に格納される。

ＬＵ＃２の再編成が完了すると、ＬＵ＃３に格納されたログを用いて追い付き処理が実行される。

この追い付き処理が完了すると、アクセスを受け付けているＬＵ＃１とＬＵ＃２とのデータは論理的に等価となる。

次に、ＬＵ＃２の内容をＬＵ＃１にコピーすることで、ＬＵ＃２とＬＵ＃１とを同期させる。

同期が完了すると、再編成処理が完了する。

図１２は、ＤＢ再編成処理のフローチャートである。

この処理は、ＤＢ再編成処理部２１３によって実行される。

まず、指定されたデータベースのデータベース領域ＩＤを取得する。そして、ＤＢ定義情報２２４及びＤＢ−ディスクブロック変換テーブル２２５を参照し、当該データベースが格納されている領域（論理ボリューム）を示す識別子を取得する（ステップ１５０１）。

次に、ステップ１５０１において取得された論理ボリュームと同じ（又はそれ以上）の容量を持つ論理ボリューム（以降、「アンロード用ボリューム」と呼ぶ）を新たに作成する。そして、作成したアンロード用ボリュームに、データベースの内容を論理的に複写（コピー）する（ステップ１５０２）。この場合、データベースの空間の乱れや不均衡化を解決するように、各データのディスクドライブ上の配置を考慮して、論理ボリュームの内容をアンロード用ボリュームにコピーする。

例えば、同一の表ブロック又は同一の索引ブロックは、物理的に連続した領域に格納される。また、指定された充填率目標値に基づいて、アンロード用ボリュームにデータを格納する。なお、このステップ１５０２の処理を、以降は「アンロード処理」と呼ぶ。

このように、アンロード処理によってデータのコピーされたアンロード用ボリュームとデータベースが保存されていた論理ボリュームとは、論理的には等価であるが、各データの物理配置は必ずしも等価ではない。

次に、アンロード処理が完了したデータのコピー元である論理ボリュームを初期化する（ステップ１５０３）。

次に、アンロード用ボリュームの内容を、初期化した論理ボリュームにコピーする（ステップ１５０４）。この場合は、ステップ１５０２のアンロード処理のコピーとは異なり、図９において前述したコピー処理として、論理ボリュームの内容がそのままコピーされる。

ステップ１５０１乃至１５０４の処理によって、データベースの再編成が完了する。次に、このデータベースの再編成の処理の間に記録されたログをデータベースの再編成された論理ボリュームに反映させる追い付き処理を実行する（ステップ１５０５）。この追い付き処理は図１３で後述する。

追い付き処理が完了すると、ＤＢ再編成処理部２１３は、ホストコンピュータ１００に、ＤＢ再編成処理が完了した旨を送信し、図１０のフローチャートに復帰する。

図１３は、追い付き処理のフローチャートである。

この処理は、ＤＢ再編成処理部２１３によって実行される。

まず、ＤＢ再編成処理が実行されていた間に記録されたログを、ログ２２１から一つずつ読み出す（ステップ１６０１）。

次に、読み出されたログが、表のデータであるか、索引のデータであるかを判定する（ステップ１６０２）。

読み出されたログが表のデータであると判定された場合は、表追い付き処理が実行される（ステップ１６０３）。この処理は図１５で後述する。

読み出されたログが索引のデータであると判定された場合は、索引追い付き処理が実行される（ステップ１６０４）。この処理は図２４で後述する。

実際には、表追い付き処理の完了後に、表追い付き処理によってアドレスが追加されたアドレス変換表２２５を用いて、索引追い付き処理が実行される。

そして、表追い付き処理及び索引追い付き処理が実行された場合は、図１１のフローチャートに復帰する。

次に、追い付き処理について説明する。

本実施の形態では、ＤＢ再編成処理部２１３が、再編成処理期間中のログのうち必要なものを抽出し、そのログをデータベースの行アドレス毎に集約する。そして、集約したログによってデータベースの追い付き処理を行う。

図１４Ａ、図１４Ｂは、再編成期間中のログから抽出されるログの説明図である。

表ブロックの行に対するログは、行の挿入、行の削除及び行の更新が抽出される。索引ブロックの索引エントリに対するログ（索引ログ）は、索引エントリの挿入及び索引エントリの削除が抽出される。抽出されたログは、後に説明するようにディスク装置２１０のメモリ２１６に設けられたバッファに格納される。

その他のログ、例えば、ブロックの新規割り当て、ブロックの解放又はブロックの分割などデータベースの構造の変更を示すログは、再編成後のデータベースに対しては考慮する必要がないので抽出されない。

表ブロックの行に対するログ（行ログ４００１）は、ログシーケンス番号（ＬＳＮ）、ログの種別、行アドレス及び行データによって構成される（図１４Ａ）。

ＬＳＮはログ毎に、ログが記録された順に付けられる番号である。ログの種別は、当該ログの操作の種別が格納される。「ＩＮＳ」は挿入を示す。「ＤＥＬ」は削除を示す。「ＵＰＤ」は更新を示す。行アドレスは、対象となる行が格納されているアドレスを示す。

行データには、挿入であれば、挿入される新たな行データが格納される。削除であれば行データは空欄となる。更新であれば、更新前の行データと更新後の行データとが格納される。

索引エントリに対するログ（索引ログ４００２）は、ログシーケンス番号（ＬＳＮ）、ログの種別、索引アドレス、キーデータ及び行アドレスによって構成される（図１４Ｂ）。

ログの種別は、索引エントリに対する操作の種別が格納される。「ＩＳ１」は索引エントリの挿入を示す。「ＤＬ１」は索引エントリの削除を示す。

キーデータには、挿入であれば、挿入される新たなキーデータが格納される。削除であればキーデータは空欄となる。

行アドレスには、当該索引エントリに対応する行のアドレスが格納される。

図１５は、表追い付き処理の概要のフローチャートである。

この処理は、ＤＢ再編成処理部２１３によって実行される。

まず、時系列に格納されているログから、再編成処理中に記録されたログが切り出され、取得される。

なお、再編成処理中のみでなく、再編成処理後に、この表追い付き処理の実行中に記録されるログについても考慮する必要がある。これに対しては、再編成処理中のログの追い付き処理を完了した後に、追い付き処理中に記録されたログを、さらに追い付き処理する方法や、再編成処理中のログの追い付き処理中に記録されたログについても、並行して追い付き処理する方法等が考えられる。

次に、切り出されたログ系列から、挿入（ＩＮＳ）、削除（ＤＥＬ）及び更新（ＵＰＤ）のログが抽出される。

次に、抽出されたログ系列が、行アドレス毎に集約される。具体的には、抽出されたログ系列が行アドレス毎にまとめられ、行アドレス毎に時系列順に並べられる。そして、行アドレス毎に一つのログに変換される。このログの変換は図１６で後述する。

そして、この行アドレス毎に、行へのログが適用される。このとき、ログの対象となっている行アドレスが、アドレス変換表に記録されているか否かが判定される。

アドレス変換表に記録されている場合は、アドレス変換表２２６を参照することで、再編成処理後の行アドレスを参照できる。

一方、アドレス変換表に記録されていない場合は、再編成処理前に存在しなかった行のアドレスに、再編成処理中に挿入がされている。

アドレス変換表に記録されているか否かは、当該ログの行アドレスを参照することで判定される。

アドレス変換表に記録されている行アドレスについては、アドレス変換後のアドレスに並び替えを行い、一つのログに集約された処理が実行される。例えば集約された当該ログが「削除」であった場合は、当該行アドレスの行が削除される。

一方、アドレス変換表に記録されていない行アドレスについては、新たな行アドレスの領域を挿入し、当該挿入された行アドレスにデータを書き込む。この新たな行アドレスは、アドレス変換表２２６に記録される。

図１６Ａ、図１６Ｂは、ログの集約の説明図である。

図１６Ａにおいて、既に主ＤＢ２２２に存在する行アドレスの行に対してされた操作が「ＤＥＬ」（削除）又は「ＵＰＤ」（更新）のみであった場合は、そのまま、「ＤＥＬ」又は「ＵＰＤ」ログとする。

行アドレスで特定される行に、複数のログが記録されている場合は、複数のログのうち、最古のログ（最初に記録されたログ）及び最新のログ（最後に記録されたログ）のみを取り出して変換処理を行う。

最古のログが「ＤＥＬ」であり、最新のログが「ＩＮＳ」（挿入）である場合は、当該行アドレスに対する操作は、一つの「ＵＰＤ」に変換される。

最古のログが「ＤＥＬ」であり、最新のログが「ＤＥＬ」である場合は、当該行アドレスに対する操作は、一つの「ＤＥＬ」に変換される。

最古のログが「ＤＥＬ」であり、最新のログが「ＵＰＤ」である場合は、当該行アドレスに対する操作は、一つの「ＵＰＤ」に変換される。

最古のログが「ＵＰＤ」であり、最新のログが「ＩＮＳ」である場合は、当該行アドレスに対する操作は、一つの「ＵＰＤ」に変換される。

最古のログが「ＵＰＤ」であり、最新のログが「ＤＥＬ」である場合は、当該行アドレスに対する操作は、一つの「ＤＥＬ」に変換される。

最古のログが「ＵＰＤ」であり、最新のログが「ＵＰＤ」である場合は、当該行アドレスに対する操作は、一つの「ＵＰＤ」に変換される。

一方、図１６Ｂにおいて、再編成処理前に存在しなかった行アドレスに対してなされた操作、すなわち、最古のログが「ＩＮＳ」である場合は、アドレス変換表に記録されていないログとしてログが変更される。

この場合、当該行アドレスに対してなされた操作が「ＩＮＳ」のみであった場合は、そのまま「ＩＮＳ」ログとする。

行アドレスで特定される行に、複数のログが記録されている場合は、複数のログのうち、最古のログ（最初に記録されたログ）及び最新のログ（最後に記録されたログ）のみを取り出して変換処理を行う。

最古のログが「ＩＮＳ」であり、最新のログが「ＩＮＳ」である場合は、当該行アドレスに対する操作は、一つの「ＩＮＳ」に変換される。

最古のログが「ＩＮＳ」であり、最新のログが「ＤＥＬ」である場合は、当該行アドレスに対する操作は、「ＮＯＰ」（No Operation）に変換される。実際には、当該行アドレスには操作は行われない。

最古のログが「ＩＮＳ」であり、最新のログが「ＵＰＤ」である場合は、当該行アドレスに対する操作は、一つの「ＩＮＳ」に変換される。

図１７は、表追い付き処理のフローチャートである。

この処理は、ＤＢ再編成処理部２１３によって実行される。

まず、ログの終端までを読み出したか否かを判定する（ステップ２００１）。

ログの終端まで読み出されたと判定した場合は、処理を終了する。

まだログの終端まで読み出されていないと判定した場合は、ログ系列の読み出し処理が実行される（ステップ２００２）。この処理によって、ログ２２１から必要なログがログ系列として抽出される。抽出されたログ系列は、バッファＡに格納される。

次に、バッファＡに格納されたログ系列の集約処理が実行される（ステップ２００３）。この処理によって、行アドレス毎に一つのログに変換され、バッファＢに格納される。

次に、集約されたログの、アドレス変換処理が実行される（ステップ２００４）。この処理によって、アドレス変換表に記録されているログとアドレス変換表に記録されていないログとが判別され、アドレス変換表２２６に基づいて再編成処理前後の行アドレスが変換され、それぞれ別のバッファ（バッファＣ、バッファＤ）に格納される。

次に、バッファＣに格納されたログをデータベースの表に適用するログ適用処理１が実行される（ステップ２００５）。

次に、バッファＤに格納されたログをデータベースの表に適用するログ適用処理２が実行される（ステップ２００６）。

以上の処理が、全てのログの読み込みが完了するまで実行される。

なお、ステップ２００５及びステップ２００６は、必ずこのフローチャートの処理順序で実行される必要はない。バッファＣ及びバッファＤにログが格納された時点で、各々の処理が開始されるようにしてもよい。

なお、これらのバッファＡ、Ｂ、Ｃ及びＤは、ディスク制御装置２１０のメモリ２１６に設けられる。

図１８は、図１７のステップ２００２のログ系列の読み出し処理のフローチャートである。

この処理は、ＤＢ再編成処理部２１３によって実行される。

まず、ログの終端まで読み出されたか否か、又は、バッファＡに設定された容量の上限までログが格納され、バッファＡが満杯となったか否かを判定する（ステップ２１０１）。

ログの終端まで読み出されたと判定した場合、又は、バッファＡが満杯となったと判定した場合は、図１７のフローチャートに復帰する。

一方、またログの終端ではなく、かつ、まだバッファＡは満杯でないと判定した場合は、ログ２２１に記録された再編成処理中のログが読み出される（ステップ２１０２）。

次に、読み出されたログの種類が判別される（ステップ２１０３）。読み出されたログの種類が、ＩＮＳ（挿入）、ＵＰＤ（更新）、ＤＥＬ（削除）であった場合は、ステップ２１４０に移行し、当該ログがバッファＡに格納される。

一方、読み出されたログの種類が、ＩＮＳ（挿入）、ＵＰＤ（更新）、ＤＥＬ（削除）の何れでもない場合は、ログを適用する必要がないため、ステップ２１０１に戻る。

このログ系列の読み出し処理によって、追い付き処理に必要なログ、すなわちＩＮＳ（挿入）、ＵＰＤ（更新）、ＤＥＬ（削除）のログが抽出され、バッファＡに格納される。

図１９は、図１７のステップ２００３のログ系列の集約処理のフローチャートである。

この処理は、ＤＢ再編成処理部２１３によって実行される。

前述したように、抽出したログ系列が行アドレス毎に集約され、ログの変換が行われる。

まず、バッファＡに格納されたログを、行アドレスの順で並べ替える（ステップ２２０１）。

次に、バッファＡから並べ替えられたログの終端まで読み出されたか否かを判定する（ステップ２１０１）。並び替えられたログの終端まで読み出されたと判定した場合は、図１７のフローチャートに復帰する。

並び替えられたログが、まだ終端まで読み出されていないと判定した場合は、バッファＡから、同一の行アドレスのログが読み出される（ステップ２２０３）。

次に、読み出された同一の行アドレスのログが変換される（ステップ２２０４）。なお、この処理は図２０で後述する。この処理によって、同一の行アドレスに対する操作が一つのログに変換される。

次に、変換されたログが、行アドレス毎にバッファＢに格納される（ステップ２２０５）。そして、ステップ２２０２に戻り、次の行アドレスについて処理する。

図２０は、図１９のステップ２２０３のログの変換のフローチャートである。

この処理は、ＤＢ再編成処理部２１３によって実行される。

まず、同一の行アドレスのログのうち、最古のログの種別を判定する（ステップ２３０１）。最古のログの種別が更新（ＵＰＤ）又は削除（ＤＥＬ）であると判定した場合は、ステップ２３０２に移行する。最古のログの種類が挿入（ＩＮＳ）であると判定した場合は、ステップ２３０５に移行する。

ステップ２３０２では、同一の行アドレスのログのうち、最新のログの種別が判別される。最新のログの種類がＩＮＳ又はＵＰＤであると判定した場合は、ステップ２３０３において、当該行アドレスのログはＵＰＤに変換される。

一方、最新のログの種類がＤＥＬであると判定した場合は、ステップ２３０４において、当該行アドレスへのログはＤＥＬに変換される。

同様に、ステップ２３０５では、同一の行アドレスのログのうち、最新のログの種別を判別する。最新のログの種類がＩＮＳ又はＵＰＤであると判定した場合は、ステップ２３０６において、当該行アドレスへのログはＩＮＳに変換される。

一方、最新のログの種類がＤＥＬであると判定した場合は、ステップ２３０７において、当該行アドレスへのログは出力されない。

ログの変換が完了すると、図１９の処理に復帰する。

図２１は、図１７のステップ２００４のアドレス変換処理のフローチャートである。

この処理は、ＤＢ再編成処理部２１３によって実行される。

まず、バッファＢに格納されたログが、終端まで読み出されたか否かを判定する（ステップ２４０１）。ログの終端まで読み出されたと判定した場合は、図１７のフローチャートに復帰する。

ログがまだ終端まで読み出されていないと判定した場合は、バッファＢから、同一の行アドレスのログが読み出される（ステップ２４０２）。

次に、読み出されたログの行アドレスが、アドレス変換表に記録されているか否かを判定する（ステップ２４０３）。当該行アドレスがアドレス変換表に記録されていないと判定した場合は、ステップ２４０４に移行し、当該ログがバッファＤに格納される。

当該行アドレスがアドレス変換表に記録されていると判定した場合は、ステップ２４０５に移行し、アドレス変換表に基づいて、当該ログの行アドレスを再編成処理後の行アドレスに変換する。

次に、行アドレスが変換されたログを、バッファＢに格納する（ステップ２４０６）。

図２２は、図１７のステップ２２０５のログ適用処理１のフローチャートである。

この処理は、ＤＢ再編成処理部２１３によって実行される。

まず、バッファＣに格納されたログを、行アドレスの順で並べ替えられる（ステップ２５０１）。

次に、並び替えられたログが読み出され、ディスクドライブ２２０のデータベースに適用される（ステップ２５０２）。具体的には、読み出されたログが、データベース上のログが示す行アドレスに適用される。

なお、適用されたログのうち、ＤＥＬ（削除）のログは、当該ログの示す行アドレスがアドレス変換表から削除される（ステップ２５０３）。

このログの適用処理１が完了すると、図１７の処理に復帰する。

なお、このログの適用の際に、ディスクドライブ２２０の磁気ディスクドライブ毎にログを分離し、磁気ディスクドライブ毎に並列処理を行うことによって、ログの適用の処理を高速化してもよい。

図２３は、図１７のステップ２００６のログ適用処理２のフローチャートである。

この処理は、ＤＢ再編成処理部２１３によって実行される。

まず、バッファＤに格納されているログを読み出し、ディスクドライブ２２０のデータベースに適用する（ステップ２６０１）。この場合のログは、全てＩＮＳであるので（図１６Ｂ参照）具体的には、当該ログに基づいて、データベースへの挿入が処理される（ステップ２６０１）。

次に、適用したログの行アドレスが、アドレス変換表に登録される（ステップ２６０２）。

このログの適用処理２が完了すると、図１７の処理に復帰する。

このように、表追い付き処理（図１７）によって、再編成処理中の記録された行ブロックに対するログが、再編成処理後のデータベースに適用される。

次に、索引追い付き処理について説明する。

図２４は、索引追い付き処理の概要のフローチャートである。

この処理は、ＤＢ再編成処理部２１３によって実行される。

まず、時系列に格納されているログから、再編成処理中に記録された索引ログが切り出され、取得される。

なお、再編成処理中のみでなく、再編成処理後に、この索引追い付き処理の実行中に記録されるログについても考慮する必要がある。これに対しては、再編成処理中のログの追い付き処理を完了した後に、追い付き処理中に記録されたログを、さらに追い付き処理する方法や、再編成処理中のログの追い付き処理中に記録されたログについても、並行して追い付き処理する方法等が考えられる。

次に、切り出された索引ログから、ＩＳ１（挿入）及びＤＬ１（削除）の索引ログが抽出される。

次に、抽出された索引ログが、行アドレス毎に集約される。具体的には、抽出された索引ログに示される行アドレス毎にまとめられ、時系列順に並べられる。そして、行アドレス毎の索引ログに変換される。この索引ログの変換は図２７で後述する。

そして、この行アドレスが、アドレス変換表に記録されているか否かが判定される。

アドレス変換表に記録されている場合は、アドレス変換表２２６を参照することで、当該索引ログに含まれている行アドレスから、再編成処理後の行アドレスを参照できる。一方、アドレス変換表に記録されていない場合は、再編成処理前に存在しなかった行のアドレスに、再編成処理中に挿入されている。

アドレス変換表に記録されているか否かは、当該索引ログの行アドレスを参照することで判定される。アドレス変換表に記録されている行アドレスについては、最古の索引ログが「ＤＬ１」である行アドレスが抽出される。

次に、アドレス変換表に基づいて、索引アドレスが変換される。

この場合、索引アドレスが変換されない場合、すなわち、再編成処理中に、索引エントリが削除された索引アドレスは、索引アドレスが変換できないので、当該索引ログに従って索引エントリが削除される。

アドレス変換表に基づいて、索引アドレスが変換される場合は、まず、索引アドレス順にログが並び替えられる。そして、並び替えられた索引ログをデータベースに適用する。

一方、アドレス変換表に記録されていない行アドレスについては、最古の索引ログがＩＳ１である行アドレスが抽出される。なお、アドレス変換表に記録されていない行アドレスの最古の索引ログがＩＳ１であり、最新の索引ログがＤＬ１である場合は、アドレス変換表に記録されているログとして扱う。この索引ログについては、新たな行アドレスの領域を挿入する。この新たな行アドレスは、アドレス変換表２２６に記録される。

図２５Ａ、図２５Ｂは、索引ログのアドレス変換の説明図である。

再編成処理前に存在しなかった索引アドレスの索引ログは、図２５Ａのように当該索引アドレスに対応する行アドレスを、アドレス変換表に基づいて変換する。

この場合、当該行アドレスに対してなされた操作が「ＤＬ１」のみであった場合は、そのまま「ＤＬ１」ログとする。

一方、同一の索引アドレスに対して、複数の索引ログが記録されている場合は、複数の索引ログのうち、最古の索引ログ（最初に記録された索引ログ）及び最新の索引ログ（最後に記録された索引ログ）のみを取り出して変換処理を行う。

最古のログが「ＩＳ１」であり、最新のログが「ＤＬ１」である場合は、当該索引アドレスに対する操作は、「ＮＯＰ」（No Operation）に変換される。実際には、当該索引アドレスには操作は行われない。

最古のログが「ＤＬ１」（削除）であり、最新のログが「ＤＬ１」である場合は、当該行アドレスに対する操作は、一つの「ＤＬ１」に変換される。

既にデータベースに存在する索引アドレスの索引エントリに対してなされた操作が「ＩＳ１」（挿入）のみであった場合は、図２５Ｂのように、そのまま「ＩＳ１」ログに変換される。

一方、同一の索引アドレスに対して、複数の索引ログが記録されている場合は、複数の索引ログのうち、最古の索引ログ（最初に記録された索引ログ）及び最新の索引ログ（最後に記録された索引ログ）のみを取り出して変換処理を行う。

最古のログが「ＩＳ１」であり、最新のログが「ＩＳ１」である場合は、当該行アドレスに対する操作は、一つの「ＩＳ１」に変換される。

最古のログが「ＤＬ１」（削除）であり、最新のログが「ＩＳ１」である場合は、当該行アドレスに対する操作は、「ＤＬ１」、「ＩＳ１」という二つのログに変換される。

図２６は、索引追い付き処理を示すフローチャートである。

この処理は、ＤＢ再編成処理部２１３によって実行される。

まず、索引ログを終端まで読み出したか否かを判定する（ステップ３００１）。

索引ログの終端まで読み出されたと判定した場合は、処理を終了する。

まだ索引ログの終端まで読み出されていないと判定した場合は、索引ログの読み込み処理が実行される（ステップ３００２）。この処理によって、ログ２２１から必要な索引ログがログ系列として抽出され、バッファＥに格納される。

次に、バッファＥに格納された索引ログ系列の集約処理が実行される（ステップ３００３）。この処理によって、行アドレス毎の索引ログに変換され、バッファＦに格納される。

次に、アドレス変換処理が実行される（ステップ３００４）。この処理によって、アドレス変換表に記録されている索引ログとアドレス変換表に記録されていない索引ログとが判別され、それぞれ別のバッファＧ、バッファＨに格納される。

次に、バッファＧに格納された索引ログをデータベースの表に適用する索引ログ適用処理１が実行される（ステップ３００５）。

次に、バッファＨに格納された索引ログをデータベースの表に適用する索引ログ適用処理２が実行される（ステップ３００６）。

以上の処理が、全ての索引ログの読み込みが完了するまで実行される。

なお、ステップ３００５及びステップ３００６は、必ずこのフローチャートの処理順序で実行される必要はない。バッファＧ及びバッファＨにログが格納された時点で、順次処理を開始するようにしてもよい。

なお、これらのバッファＥ、Ｆ、Ｇ及びＨは、ディスク制御装置２１０のメモリ２１６に設けられる。

図２７は、図２６のステップ３００２の索引ログ系列読み込み処理のフローチャートである。

この処理は、ＤＢ再編成処理部２１３によって実行される。

まず、索引ログの終端まで読み出されたか否か、又は、バッファＥに設定された容量の上限まで索引ログが格納され、バッファＥが満杯となったか否かを判定する（ステップ３１０１）。

索引ログの終端まで読み出されたと判定した場合、又は、バッファＥが満杯となったと判定した場合は、図２６のフローチャートに復帰する。

一方、またログの終端ではなく、かつ、まだバッファＥは満杯でないと判定した場合は、ログ２２１に記録された再編成処理中の索引ログが読み出される（ステップ３１０２）。

次に、読み出されたログの種類が判別される（ステップ３１０３）。読み出されたログの種類が、ＩＮ１（挿入）又はＤＬ１（削除）であった場合は、ステップ３１４０に移行し、当該ログがバッファＥに格納される。

一方、読み出されたログの種類が、ＩＮ１（挿入）及びＤＬ１（削除）の何れでもない場合は、ログを適用する必要がないため、ステップ３１０１に戻る。

このログ読み込み処理によって、追い付き処理に必要なログ、すなわちＩＳ１（挿入）及びＤＬ１（削除）の索引ログが抽出され、バッファＥに格納される。

図２８は、図２６のステップ３００３の索引ログ系列の集約処理のフローチャートである。

この処理は、ＤＢ再編成処理部２１３によって実行される。

前述したように、抽出されたログ系列が行アドレス毎に集約され、索引ログが変換される。

まず、バッファＥに格納された索引ログ系列が、行アドレスの順で並べ替えられる（ステップ３２０１）。

次に、バッファＥに格納された並べ替えられた索引ログの終端まで読み出されたか否かを判定する（ステップ３１０１）。並び替えられた索引ログの終端まで読み出されたと判定した場合は、図２６のフローチャートに復帰する。

並び替えられた索引ログが、まだ終端まで読み出されていないと判定した場合は、バッファＥから、同一の行アドレスの索引ログが読み出される（ステップ３２０３）。

次に、読み出された同一の行アドレスのログが変換される（ステップ３２０４）なお、この処理は図２９で後述する。この処理によって、同一の行アドレス毎の索引ログに変換される。

次に、変換された索引ログが、バッファＦに格納される（ステップ３２０５）。そして、ステップ３２０２に戻り、次の行アドレスについて処理される。

図２９は、図２８の索引ログ変換のフローチャートである。

この処理は、ＤＢ再編成処理部２１３によって実行される。

まず、同一の行アドレスに対する索引ログのうち、最古の索引ログの種別を判定する（ステップ３３０１）。最古の索引ログの種別がＤＬ１であると判定した場合は、ステップ３３０２に移行する。最古の索引ログの種類がＩＳ１であると判定した場合は、ステップ３３０５に移行する。

ステップ３３０２では、同一の行アドレスの索引ログのうち、最新の索引ログの種別が判別される。最新の索引ログの種類がＩＳ１であると判定した場合は、ステップ３３０３において、当該行アドレスの索引ログは、ＤＬ１及びＩＳ１に変換される。

一方、最新の索引ログの種類がＤＬ１であると判定した場合は、ステップ３３０４において、当該行アドレスへの索引ログはＤＬ１に変換される。

同様にステップ３３０５では、同一の行アドレスに対する索引ログのうち、最新の索引ログの種別を判別する。最新の索引ログの種類がＩＳ１あると判定した場合は、ステップ３３０６において、当該行アドレスの索引ログはＩＳ１に変換される。

一方、最新の索引ログの種類がＤＬ１であると判定した場合は、ステップ３３０７において、当該行アドレスの索引ログは出力されない。

索引ログの変換が完了すると、図２８の処理に復帰する。

図３０は、図２６のステップ３００４のアドレス変換処理のフローチャートである。

この処理は、ＤＢ再編成処理部２１３によって実行される。

まず、バッファＦに格納された索引ログが、終端まで読み出されたか否かを判定する（ステップ３４０１）。索引ログの終端まで読み出されたと判定した場合は、図２６のフローチャートに復帰する。

索引ログがまだ終端まで読み出されていないと判定した場合は、バッファＦから、同一の行アドレスの索引ログが読み出される（ステップ３４０２）。

次に、読み込んだ索引ログの行アドレスが、アドレス変換表に記録されていており、アドレス変換表から当該行アドレスが参照可能か否かを判定する（ステップ３４０３）。当該行アドレスがアドレス変換表に記録されていない場合と判定した場合は、ステップ３４０４に移行する。

ステップ３４０４では、当該索引ログが、アドレス変換表に基づいて、変換後の行アドレスに変換される。そして、行アドレスの変換された索引ログが、バッファＨに格納される（ステップ３４０５）。

一方、当該行アドレスがアドレス変換表に記録されていると判定された場合は、ステップ３４０６に移行し、当該行索引ログの索引アドレスが、アドレス変換表に基づいて変換後の索引アドレスに変換される。

そして、行アドレスの変換されたログが、バッファＧに格納される（ステップ３４０７）。

図３１は、図２６のステップ２００５の索引ログ適用処理１のフローチャートである。

この処理は、ＤＢ再編成処理部２１３によって実行される。

まず、バッファＧに格納された索引ログを、索引アドレスの順で並べ替えられる（ステップ３５０１）。

次に、並び替えられた索引ログが読み出され、ディスクドライブ２２０のデータベースに適用される（ステップ３５０２）。具体的には、読み出された索引ログに示される索引アドレスの索引エントリに、当該索引ログの内容が適用される。

また、ＤＬ１（削除）を指示する索引ログに関しては、当該索引アドレスがアドレス変換表から削除される（ステップ３５０３）。

この索引ログ適用処理１が完了すると、図２６の処理に復帰する。

なお、このログの適用の際に、ディスクドライブ２２０の磁気ディスクドライブ毎にログを分離し、磁気ディスクドライブ毎に並列処理を行うことによって、ログの適用の処理を高速化してもよい。

図３２は、図２６のステップ３００６の索引ログ適用処理２のフローチャートである。

この処理は、ＤＢ再編成処理部２１３によって実行される。

まず、バッファＨに格納されている索引ログが読み出され、ディスクドライブ２２０のデータベースに適用される（ステップ３６０２）。具体的には、読み出された索引ログに示される索引アドレスに対して、当該索引ログの内容に基づいて索引エントリの領域が挿入され、索引ログに基づいてその内容が適用される。

次に、索引エントリを挿入した索引アドレスが、アドレス変換表に登録される（ステップ３６０２）。

この索引ログ適用処理２が完了すると、図２６の処理に復帰する。

このように、索引追い付き処理（図２８）によって、再編成処理中のデータベースの索引ログが、再編成が処理されたＬＵに適用される。

前述したように、本発明の実施の形態のデータベースシステムでは、ストレージ装置２００に再編成の処理機能である再編成処理部２１３を設けたので、ホストコンピュータ１００からの指示によって、ストレージ装置２００側でデータベースの再編成処理を行うことができる。この再編成処理において、ストレージ２００は、再編成中にデータベースになされたトランザクションのログを格納しておき、再編成終了後に、当該ログの追い付き処理を行う。このようにすることで、データベースシステムの処理を停止することなく、データベースの再編成処理が可能となる。

次に、本発明の実施の形態の変形例であるデータベースシステムについて説明する。

前述した実施の形態のデータベースシステムでは、ホストコンピュータ１００からの指示によって、ストレージ装置２００が再編成処理するように構成した。本変形例では、ホストコンピュータ１００からの指示によらず、ストレージ装置２００が、再編成処理の開始を判断し再編成処理をする。以降に、その詳細を説明する。

ストレージ装置２００は、実施の形態のように、ホストコンピュータ１００からの再編成コマンドを受信した場合に、再編成処理をする。これとは別に、所定の条件となった場合に、再編成処理をする。

所定の条件とは、例えば、所定の時間間隔や、データベースを格納している論理ボリュームの容量の上限付近（ハイウォーターマーク）までデータが格納され、データを格納する領域がこれ以上見つからない場合等である。

この場合、ストレージ装置のＤＢ再編成処理部２１３は、ディスクアクセス制御部２１５に、データベースのチェックポイントの場所を問い合わせる。チェックポイントは、データベースの内容の整合性を保証するために、全てのトランザクションが完了している時点を示す情報である。

ＤＢ再編成処理部２１３は、複数のチェックポイントのうち、最新のチェックポイントと最新のチェックポイント以前の直近のチェックポイントとを取得する。

そして、この二つのチェックポイント間に記録されたログを識別する。

以降、ストレージ装置２００において、図１０の処理が行われる。すなわち、ＤＢ再編成処理部２１３は、ボリュームペアを分割し（図１０のステップ１４０２）、カレントデータベースを主ＤＢ２２２のみに切り換え、副ＤＢ２２３の再編成処理を行う。この場合、追い付き処理は、取得した最新のチェックポイントとそれ以前のチェックポイントと間に記録されたログが用いられる。

前述したように、本変形例では、ホストコンピュータ１００の指示によらず、ストレージ装置２００側で自立して再編成処理を開始することによって、ホストコンピュータ１００側の処理負荷を低減できる。

本発明の実施の形態の、データベースシステムのブロック図である。 本発明の実施の形態の、表データの説明図である。 本発明の実施の形態の、索引データの説明図である。 本発明の実施の形態の、ＤＢ−ディスクブロック変換テーブル２２５の一例の表である。 本発明の実施の形態の、マッピングの関係を示す説明図である。 本発明の実施の形態の、ストレージ装置２００の処理のフローチャートである。 本発明の実施の形態の、Ｒｅａｄ処理のフローチャートである。 本発明の実施の形態の、Ｗｒｉｔｅ処理のフローチャートである。 本発明の実施の形態の、ボリュームコピー処理のフローチャートである。 本発明の実施の形態の、ＤＢ再編成制御処理のフローチャートである。 本発明の実施の形態の、ディスクドライブの再編成処理の説明図である。 本発明の実施の形態の、ＤＢ再編成処理のフローチャートである。 本発明の実施の形態の、追い付き処理のフローチャートである。 本発明の実施の形態の、再編成期間中のログから抽出されるログの説明図である。 本発明の実施の形態の、再編成期間中のログから抽出されるログの説明図である。 本発明の実施の形態の、表追い付き処理の概要のフローチャートである。 本発明の実施の形態の、ログの集約の説明図である。 本発明の実施の形態の、ログの集約の説明図である。 本発明の実施の形態の、表追い付き処理を示すフローチャートである。 本発明の実施の形態の、ログ読み出し処理のフローチャートである。 本発明の実施の形態の、ログの集約処理のフローチャートである。 本発明の実施の形態の、ログの変換のフローチャートである。 本発明の実施の形態の、アドレス変換処理のフローチャートである。 本発明の実施の形態の、ログ適用処理１のフローチャートである。 本発明の実施の形態の、ログ適用処理２のフローチャートである。 本発明の実施の形態の、索引追い付き処理の概要のフローチャートである。 本発明の実施の形態の、索引ログのアドレス変換の説明図である。 本発明の実施の形態の、索引ログのアドレス変換の説明図である。 本発明の実施の形態の、索引追い付き処理を示すフローチャートである。 本発明の実施の形態の、索引ログ読み込み処理のフローチャートである。 本発明の実施の形態の、索引ログの集約処理のフローチャートである。 本発明の実施の形態の、索引ログの変換のフローチャートである。 本発明の実施の形態の、アドレス変換処理のフローチャートである。 本発明の実施の形態の、索引ログ適用処理１のフローチャートである。 本発明の実施の形態の、索引ログ適用処理２のフローチャートである。

符号の説明

１００ ホストコンピュータ
１２０ メモリ
１３０ ＤＢ管理システム
１４０ ＤＢアクセス制御部
１４１ ＤＢ問合せ制御部
１４２ ＤＢアクセス処理部
１４３ ログ出力処理部
１５０ ＤＢ運用操作制御部
１５１ ＤＢ再編成処理部
１５２ ＤＢバックアップ制御部
１５３ ＤＢ回復制御部
１５４ ＤＢ状態回復制御部
１６０ ログバッファ
１７０ ＤＢバッファ
２１０ ディスク制御部
２１１ キャッシュメモリ
２１３ ＤＢ再編成処理部
２１５ ディスクアクセス制御部
２２１ ログ
２２２ 主ＤＢ
２２３ 副ＤＢ
２２４ ＤＢ定義情報
２２５ ＤＢ−ディスクブロック変換テーブル
２２６ アドレス変換表

Claims (10)

1. ホストコンピュータからの要求に基づいて、ストレージ装置のディスクドライブに保存されるデータベースの再編成方法であって、
   前記ディスクドライブは、データベースを保存する第一のボリュームと、前記第一のボリュームとペアを構成し、前記データベースの複製を格納する第二のボリュームとを含み、
   前記ホストコンピュータは、
   トランザクションを静止化し、
   前記第一のボリュームと前記第二のボリュームのペアを分割して、前記第一のボリュームに対してのみ、前記データベースへアクセスするように設定し、
   前記トランザクションの静止化を解除し、
   前記第二のボリュームを再編成し、
   前記第二のボリュームの内容を前記第一のボリュームに複写して、前記第一のボリュームと前記第二のボリュームとのペアを再同期する手順を含むことを特徴とする再編成方法。
2. 前記ディスクドライブは、前記データベースへのアクセスによって生成されるログを保存する第三のボリュームと、前記第二のボリュームに保存されたデータベースの内容の複製を保存可能な第四のボリュームとを含み、
   前記第二のボリュームを再編成する手順は、
   前記第二のボリュームに保存されたデータベースの内容を前記第四のボリュームに論理的に複写し、
   前記複写が完了した第二のボリュームを初期化し、
   前記第四のボリュームに保存されたデータベースの内容を前記第二のボリュームに物理的に複写し、
   前記トランザクションの静止化以後のログを前記第三のボリュームから取得し、前記第二のボリュームに保存されたデータベースに当該ログを反映することを特徴とする請求項１に記載の再編成方法。
3. 前記第二のボリュームに保存されたデータベースにログを反映する手順は、
   前記取得したログのうち、データベースの表ブロックに関するログを前記第二のボリュームに保存されたデータベースに反映し、
   取得したログのうち、データベースの索引ブロックに関するログを前記第二のボリュームに保存されたデータベースに反映することを特徴とする請求項２に記載の再編成方法。
4. 前記第二のボリュームに保存されたデータベースにログを反映する手順は、
   前記取得したログのうち、同一のアドレスに対応するログの最古のログと最新のログを参照して、１又は２のログに集約し、
   その後、前記集約したログを前記第二のボリュームに保存されたデータベースに反映することを特徴とする請求項２に記載の再編成方法。
5. 前記ストレージ装置は、前記第二のボリュームの表ブロックの、再編成処理前のアドレスと再編成処理後のアドレスとを対応付けて保存するアドレス変換表を備え、
   前記第二のボリュームに保存されたデータベースにログを反映する手順は、
   前記取得したログから、所定の種別のログを抽出し、
   前記抽出したログを、当該ログの対象である前記第二のボリュームに保存されたデータベースのアドレス毎にまとめ、
   前記まとめられたログを、当該アドレス毎のログとして変換し；
   前記変換されたログのアドレスが前記アドレス変換表に保存されている場合は、前記変換されたログのアドレスを、前記アドレス変換表に基づいて、再編成処理後のアドレスに変換し、
   前記変換されたログを、変換後のアドレス毎に並び替えて、前記第二のボリュームに保存されたデータベースに反映し；
   前記変換されたログのアドレスが前記アドレス変換表に保存されていない場合は、当該アドレスの領域を前記第二のボリュームに作成し、
   前記ログを、前記第二のボリュームに保存されたデータベースの当該作成した領域のアドレスに反映することを特徴とする請求項４に記載の再編成方法。
6. 前記ストレージ装置は、前記第二のボリュームの表ブロックの、再編成処理前の行アドレスと再編成処理後の行アドレスとを対応付けて保存するアドレス変換表を備え、
   前記第二のボリュームに保存されたデータベースにログを反映する手順は、
   前記取得した索引ログから、所定の種別の索引ログを抽出し、
   前記抽出した索引ログを、当該索引の対象である前記第二のボリュームの表ブロックの行アドレス毎にまとめ、
   前記まとめられた索引ログを、当該行アドレス毎のログとして変換し；
   前記変換されたログのアドレスが前記アドレス変換表に保存されている場合は、前記変換された索引ログの行アドレスを、前記アドレス変換表に基づいて、再編成処理後の行アドレスに変換し、
   前記変換された索引ログを、前記索引アドレス毎に並び替えて、前記第二のボリュームに保存されたデータベースに反映し；
   前記変換されたログのアドレスが、前記アドレス変換表に保存されていない場合は、当該索引アドレスの領域を前記第二のボリュームに作成し、
   前記索引ログを、前記第二のボリュームの当該作成した領域の索引アドレスに保存されたデータベースに反映することを特徴とする請求項４に記載の再編成方法。
7. ホストコンピュータによってアクセスされるデータベースをディスクドライブに保存するストレージ装置であって、
   前記ディスクドライブに保存されたデータベースを再編成するデータベース再編成処理部を備え、
   前記ディスクドライブは、データベースを保存する第一のボリュームと、前記第一のボリュームとペアを構成し、前記データベースの複製を格納する第二のボリュームと、前記データベースに対するアクセスによって生成されるログを保存する第三のボリュームと、前記第二のボリュームに保存されたデータベースの内容の複製を保存可能な第四のボリュームとを含み、
   前記データベース再編成処理部は、
   前記ホストコンピュータからのトランザクションが静止化した状態で、前記第一のボリュームと前記第二のボリュームのペアを分割し、
   前記第二のボリュームに保存されたデータベースの内容を前記第四のボリュームに論理的に複写し、
   前記複写が完了した第二のボリュームを初期化し、
   前記第四のボリュームに保存されたデータベースの内容を前記第二のボリュームに物理的に複写し、
   前記トランザクションの静止化以後のログを前記第三のボリュームから取得し、前記第二のボリュームに保存されたデータベースに反映し、
   前記第二のボリュームの内容を前記第一のボリュームに複写し、
   前記第一のボリュームと前記第二のボリュームとのペアを再同期することを特徴とするストレージ装置。
8. 前記データベース再編成処理部は、
   取得したログのうち、データベースの表ブロックに関するログを前記第二のボリュームに保存されたデータベースに反映し、
   取得したログのうち、データベースの索引ブロックに関するログを前記第二のボリュームに保存されたデータベースに反映することを特徴とする請求項７に記載のストレージ装置。
9. 前記第二のボリュームの表ブロックの、再編成処理前の行アドレスと再編成処理後の行アドレスとを対応付けて保存するアドレス変換表を備え、
   前記データベース再編成処理部は、
   前記取得したログから、所定の種別のログを抽出し、
   前記抽出したログを、当該ログの対象である前記第二のボリュームのアドレス毎にまとめ、
   前記まとめられたログを、当該アドレス毎のログとして変換し；
   前記変換されたログのアドレスが前記アドレス変換表に保存されている場合は、前記変換された索引ログの行アドレスを、前記アドレス変換表に基づいて、再編成処理後の行アドレスに変換し、
   前記変換された索引ログを、当該索引ログの前記第二のボリュームの索引アドレス毎に並び替え、
   前記並び替えたログのうち、同一のアドレスに対応するログの最古のログと最新のログを参照して、１又は２のログに集約し、
   前記集約したログを、前記第二のボリュームに保存されたデータベースに反映することを特徴とする請求項７に記載のストレージ装置。
10. ホストコンピュータと、
    前記ホストコンピュータによってアクセスされるデータベースをディスクドライブに保存するストレージ装置と、を備えるデータベースシステムにおいて、
    前記ホストコンピュータは、データベースの運用操作を制御するデータベース運用操作制御部を備え、
    前記ストレージ装置は、前記ホストコンピュータからの制御信号を受け付けるホストインタフェースと、前記ディスクドライブに保存されたデータベースを再編成するデータベース再編成処理部と、を備え、
    前記ディスクドライブは、データベースを保存する第一のボリュームと、前記第一のボリュームとペアを構成し、前記データベースの複製を保存する第二のボリュームと、前記データベースに対するアクセスによって生成されるログを保存する第三のボリュームと、前記第二のボリュームに保存されたデータベースの内容の複製を保存可能な第四のボリュームとを含み、
    前記データベース運用操作制御部は、
    前記ホストコンピュータのトランザクションを静止化し、
    前記ボリュームペアを分割させ、
    前記データベースへのアクセスを前記第一のボリュームに対してのみ行うように設定し、
    前記トランザクションの静止化を解除し、
    前記ストレージ装置に、第二のボリュームを再編成させる要求を送り；
    前記データベース再編成処理部は、
    前記ホストコンピュータから前記第二のボリュームの再編成要求を受け付けると、
    前記第二のボリュームに保存されたデータベースの内容を前記第四のボリュームに論理的に複写し、
    前記複写が完了した第二のボリュームを初期化し、
    前記第四のボリュームに保存されたデータベースの内容を前記第二のボリュームに物理的に複写し、
    前記トランザクションの静止化以後のログを前記第三のボリュームから取得し、前記第二のボリュームに反映し、
    前記データベース運用操作制御部は、
    前記トランザクションの静止化以後のログを前記第三のボリュームから取得し、前記第二のボリュームに反映し、
    前記第二のボリュームの内容を前記第一のボリュームに複写し、
    前記第一のボリュームと前記第二のボリュームとをボリュームペアとして再同期することを特徴とするストレージシステム。
    

Images