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

データベースの再編成方法、ストレージ装置及びストレージシステム Download PDF

Info

Publication number
JP4518485B2
JP4518485B2 JP2004305680A JP2004305680A JP4518485B2 JP 4518485 B2 JP4518485 B2 JP 4518485B2 JP 2004305680 A JP2004305680 A JP 2004305680A JP 2004305680 A JP2004305680 A JP 2004305680A JP 4518485 B2 JP4518485 B2 JP 4518485B2
Authority
JP
Japan
Prior art keywords
volume
log
database
address
index
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
Application number
JP2004305680A
Other languages
English (en)
Other versions
JP2006119822A (ja
Inventor
優 喜連川
和生 合田
信男 河村
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
University of Tokyo NUC
Original Assignee
Hitachi Ltd
University of Tokyo NUC
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd, University of Tokyo NUC filed Critical Hitachi Ltd
Priority to JP2004305680A priority Critical patent/JP4518485B2/ja
Priority to US11/080,648 priority patent/US7421456B2/en
Publication of JP2006119822A publication Critical patent/JP2006119822A/ja
Application granted granted Critical
Publication of JP4518485B2 publication Critical patent/JP4518485B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22Indexing; Data structures therefor; Storage structures
    • G06F16/2282Tablespace storage structures; Management thereof

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

本発明は、データベースを運用するストレージシステムに関し、特にデータベースの再編成方法に関する。
従来、データベースを管理するDBMS(Data Base Management System)は、データベースの応答性を高めるように設計されている。ストレージ等の記憶空間は、データベースの保存領域を頻繁に変えないなど、できるだけ複雑な管理を避けるように設計されている。従って、DBMSの記憶空間は、運用の時間経過に伴って、徐々に「乱れ」が発生する。「乱れ」とは、断片化空間や未回収領域、空間管理構造の不均衡化が発生していることである。記憶空間の乱れは、データベースの応答性を劣化させ、記憶空間の予想外の消費を発生させる。
記憶空間の乱れを解消するために、多くのDBMSには専用のソフトウェアが用意されている。このソフトウェアは、断片化の解消、未回収領域の回収、空間管理構造の均衡化を行うことによって、記憶空間を乱れのない理想的な状態に変化させる。この処理を「再編成」と呼ぶ。
DBMSの管理者は、定期的に再編成用ソフトウェアを用いて再編成を行うことによって、データベースの応答性の劣化、記憶空間の予想外の消費を解消する必要がある。
例えば、このようなDBMSとしては、ホストコンピュータからのアクセス要求が書き込み要求であり、その書き込み内容がホストコンピュータのバッファ上で行われたデータベース処理の内容を示すログ情報である場合に、ホストコンピュータ側で認識している論理的な位置情報と正記憶装置サブシステム上の物理的な位置情報との対応関係を示す変換テーブルによって、前記ログ情報中に示された位置情報を正記憶装置サブシステム上の物理的な位置情報に変換するステップと、その変換した物理的な位置情報で表される正記憶装置サブシステム上のデータベース領域のデータを前記ログ情報の内容に従って更新し、前記アクセス要求を副記憶装置サブシステムへ送信するステップとを有するものがある(例えば、特許文献1参照。)。
また、ホストコンピュータからのアクセス要求が書き込み要求であり、その書き込み内容がホストコンピュータのバッファ上で行われたデータベース処理の内容を示すログ情報であるかどうかを判定するステップと、前記書き込み内容が前記ログ情報である場合に、ホストコンピュータ側のデータベース処理で認識している論理的な位置情報と記憶装置サブシステム上の物理的な位置情報との対応関係を示す変換テーブルによって、前記ログ情報中に示された位置情報を記憶装置サブシステム上の物理的な位置情報に変換するステップと、その変換した物理的な位置情報で表される記憶装置サブシステム上のデータベース領域のデータを前記ログ情報の内容に従って更新するステップとを有するものがある(例えば特許文献2参照。)。
特開2004−199497号公報 特開2004−199498号公報
前記の従来の再編成については、二つの問題点がある。
第一に、今日利用可能な再編成ソフトウェアは、システムの停止を必要とする。また、運用中に再編成を実行する場合ではサービスの性能劣化が著しい。このため、DBMS管理者は、膨大なDBMSのパラメータ設定と周到な管理計画の元に再編成を実行する必要がある。これは、DBMS管理を困難なものにし、結果的にITシステムの管理コストの高騰を招いている。
第二に、多くのITシステムが24時間稼働するようになり、再編成による副作用、即ち、サービス停止や性能劣化はもはやユーザに受け入れられない。このようなシステムにおいては、再編成ソフトウェアによる再編成処理そのものが困難である。
本発明は、ホストコンピュータからの要求に基づいて、ストレージ装置のディスクドライブに保存されるデータベースの再編成方法であって、前記ディスクドライブは、データベースを保存する第一のボリュームと、前記第一のボリュームとペアを構成し、前記データベースの複製を格納する第二のボリュームと、前記データベースへのアクセスによって生成されるログを保存する第三のボリュームと、前記第二のボリュームに保存されたデータベースの内容の複製を保存可能な第四のボリュームとを含み、前記ホスト計算機は、トランザクションを静止化し、前記第一のボリュームと前記第二のボリュームのペアを分割して、前記第一のボリュームに対してのみ、前記データベースへアクセスするように設定し、前記トランザクションの静止化を解除し、前記ストレージ装置に、第二のボリュームを再編成させる要求を送り前記ストレージ装置は、前記ホストコンピュータから前記第二のボリュームの再編成要求を受け付けると、前記第二のボリュームに保存されたデータベースの内容を前記第四のボリュームに論理的に複写し、前記複写が完了した第二のボリュームを初期化し、前記第四のボリュームに保存されたデータベースの内容を前記第二のボリュームに物理的に複写し、前記トランザクションの静止化以後のログを前記第三のボリュームから取得し、前記第二のボリュームの表ブロックの、再編成処理前のアドレスと再編成処理後のアドレスとを対応付けて保存するアドレス変換表を用いて、前記第二のボリュームに保存されたデータベースに当該ログを反映し、前記ホスト計算機は、前記第二のボリュームの内容を前記第一のボリュームに複写して、前記第一のボリュームと前記第二のボリュームとのペアを再同期する。
従って、本発明によると、ホストコンピュータからの指示によって、ストレージ装置に、データベースの再編成処理を行わせることが可能となる。
以下、本発明の実施の形態を図面を参照して説明する。
図1は、本実施の形態の、データベースシステムのブロック図である。
ホストコンピュータ100が、SAN(Storage Area Network)300を介してストレージ装置200に接続している。
ホストコンピュータ100は、SAN300を介してストレージ装置200のデータの操作を要求する。ストレージ装置200は、その結果をホストコンピュータ100に返す。なお、本発明のデータベースシステムはSANに限定されるものではなく、ホストコンピュータ100とストレージ装置200とのネットワーク機能を実現するものであればよい。
ホストコンピュータ100は、CPU110、メモリ120等によって構成される。CPU110は、各種プログラムを実行してホストコンピュータ100を制御する。メモリ120は、データベース管理システム130を格納する。このDB管理システム130は、プログラムによって構成される。このプログラムがCPU110によって実行されることで、ホストコンピュータ100がDB管理システム130として機能する。
なお、DB管理システム130はソフトウェアで構成されなくてもよい。例えば、オブジェクトによって実現されるものであっても、ハードウェア構成によって実現されるものであってもよい。また、ホストコンピュータ100は、仮想計算機であってもよい。
DB管理システム130は、DBアクセス制御部140、DB運用操作制御部150、ログバッファ160及びDBバッファ170によって構成される。
DBアクセス制御部140は、DBバッファ160に格納された内容をストレージ装置200内のディスクドライブ220のデータとして反映させる。このとき、DBバッファ160の内容を示すログ情報をログバッファ170に格納する。格納されたログ情報は、ストレージ装置200内のディスクドライブのデータとして反映される。
DBアクセス制御部140は、DB問合せ制御部141、DBアクセス処理部142及びログ出力処理部143によって構成される。DB問合せ制御部141は、データベースの表空間(インデックス)を参照して、データベースの格納位置を取得する。DBアクセス処理部142は、データベースにデータを書き込み、又はデータを読み出す。ログ出力処理部143は、データベース処理の内容を示すログをストレージ装置200に格納させる。
DB運用操作制御部150は、ストレージ装置200にデータベースの運用に関する処理を指示する。具体的には、DB運用操作制御部150は、データベースのバックアップや再編成処理を指示する。
DB運用操作制御部150は、DB再編成処理部151、DBバックアップ制御部152、DB回復制御部153及びDB状態解析制御部154によって構成される。
DB再編成処理部151は、データベースの空間の乱れや不均衡化を解決するための再編成処理をストレージ装置200に指示する。
DBバックアップ制御部152は、データベースのバックアップ作成処理をストレージ装置200に指示する。
DB回復制御部153は、データベースの回復を制御する。
DB状態回復制御部154は、ストレージ装置200にデータベースの状態を問い合わせ、データベースの状態を解析する。たとえば、データベースの空間の乱れや不均衡化の状態を解析する。
ストレージ装置200は、ディスク制御部210及びディスクドライブ220によって構成される。
ディスク制御部210は、ディスクドライブ220へのデータの読み書きを制御する。
ディスク制御部210は、キャッシュメモリ211、ホストインタフェース処理部212、DB再編成処理部213、ボリュームコピー処理部214及びディスクアクセス制御部215によって構成される。
キャッシュメモリ211は、ディスクドライブ220に読み書きされるデータを一時的に格納する。
ホストインタフェース処理部212は、ホストコンピュータ100から送られた要求を解析し、当該要求をディスク制御部210の他の処理部に送る。また、ディスク制御部210の他の処理部から受け取った結果をホストコンピュータ100に返す。
DB再編成処理部213は、ディスクドライブ220に生じたデータベースの空間の乱れや不均衡化を解決する再編成処理を実行する。
ボリュームコピー処理部214は、ディスクドライブ220のボリューム間のコピー、ボリューム間の同期及びボリューム間の同期の解除等を制御する。
ディスクアクセス制御部215は、ディスクドライブ220に、SCSIやFibreChannel等のプロトコルに基づいてアクセスする。
ディスクドライブ220は、一つ以上の磁気ディスクドライブによって構成される。
これら複数の磁気ディスクドライブは、RAID構成等によって論理的な領域が構成される。この領域は複数の領域(LU:論理ユニット)に論理的に分割される。そして、データを格納する領域である論理ボリュームが、一つ以上の論理ユニットによって構成される。
なお、本実施形態の各処理部や制御部は、オブジェクトやプログラム、プロセス、スレッド等によって実現されるものであってもよい。また、ハードウェア構成によって実現されるものであってもよい。
ディスクドライブ220には、ログ221、正DB222、副DB223、DB定義情報224、DB−ディスクブロック変換テーブル225及びアドレス変換表226等の複数のデータ格納領域が構成される。はお、本発明のディスクドライブ220はハードディスクに限定されるものではなく、データを記憶できる機能を有するものであればよい。
ログ221は、データベース処理における差分ログを格納する。
正DB222は、ホストコンピュータ100によってアクセスされるデータベースを格納する。
副DB223は、正DB222の複製を格納する。業務運用時は、正DB222及び副DB223は同期状態である。すなわち、ホストコンピュータ100から正DB222への書き込みデータは、副DB223にも書き込まれる。正DB222及び副DB223が同期状態であれば、正DB222及び副DB223の内容は同一となる。
DB定義情報224は、ディスクドライブ220に格納されるデータベースの構成情報を格納する。データベースの構成情報は、例えば、データベース名、各データベースのデータ及び索引のスキーマ、統計情報等である。
DB−ディスクブロック変換テーブル225は、データベースの各データと当該データが格納されている物理的な位置との対応が格納される。
アドレス変換表226は、データベースの再編成処理及びその後の追い付き処理に用いられる。アドレス変換表226には、再編成処理の前後でデータのディスクドライブ220上の物理的な格納位置が変更された場合に、その前後の物理的な位置が格納される。
なお、アドレス変換表226は、ディスクドライブ220ではなく、メモリ上の領域の保存されるものであってもよい。
次に、ディスクドライブ220に保存されるデータベースの構成を説明する。
ディスクドライブ220に保存されるデータは、主にデータベースの本体である「表データ」及びその検索や一覧のために用いられる「索引データ」によって構成される。
図2は、表データの説明図である。
表データは、複数の表ブロックから構成される。この複数の表ブロックによってファイルが構成される。各表ブロックには保存データの最小構成単位である「行」が含まれている。
図2の例では、ファイル1が四つの表ブロックによって構成されていることを示す。このファイルの構成はDB−ディスクブロック変換テーブル225(図4参照)に格納されている。
図3は、索引データの説明図である。
索引データは、ブロックの集合から構成され、これらのブロックは木構造となっている。
木構造は、根ブロック、枝ブロック及び葉ブロックから構成される。根ブロックには参照先の枝ブロックのアドレスが格納される。枝ブロックには参照先の葉ブロックのアドレスが格納される。葉ブロックには索引エントリが格納される。索引エントリは、キー値、重複数、行アドレスによって構成される。キー値は、データベースのデータを検索するための検索キーが格納される。重複数は、参照先の重複の数を示す情報が格納される。行エントリは、表データの行アドレスが格納される。
DB管理システム130は、検索キーを用いてこの索引データを検索することによって、表データの行アドレスを得る。そして、この行アドレスを用いて表データにアクセスする。
図4は、DB−ディスクブロック変換テーブル225の一例の表である。
DB−ディスクブロック変換テーブル225は、データベース領域ID2251、種別2252、ファイルID2253、ブロック長2254、論理ボリュームID2255、物理デバイスID2256及び相対位置2257によって構成される。
データベース領域ID2251は、データベースが格納されるデータベース領域毎に付けられる固有の識別子である。
種別2252は、データベース領域に格納されるデータベースの種別である。種別には、DB(データベースを示す)、ログ等の情報が格納される。
ファイルID2253は、その領域に格納されるデータベース領域が複数のファイルで構成されている場合に、そのファイル毎に付けられる固有の識別子である。
ブロック長2254は、そのデータベース領域を構成する表ブロックの長さ(サイズ)が示される。
論理ボリュームID2255は、そのデータベース領域の構成ファイルが格納されている論理ボリュームを識別するための識別子である。
物理デバイスID2256は、論理ボリュームIDによって識別される論理ボリュームがマッピングされている物理デバイスを識別するための識別子である。具体的には、LU毎に個別に付けられる番号であるLUN(Logical Unit Number)である。
相対位置2257は、そのデータベースが格納される領域はLUの中のどの場所であるか、LUの相対位置によって示される。具体的にはLBA(Logical Block Address)が格納される。
本実施形態のデータベースを構成するファイルは、ホストコンピュータ100で稼働しているオペレーティングシステムが認識するファイルシステムとして論理ボリュームにマッピングされる。また、論理ボリュームは、ストレージ装置200の物理デバイスであるディスクドライブ220に対応したデバイスファイルとしてマッピングされる。
ストレージ装置200内では、デバイスファイルは、LUに対応している。従って、データベース領域を構成するファイルは、最終的に物理デバイスであるディスクドライブの磁気ディスクドライブにマッピングされる。対応する物理情報は、ストレージ装置200内の磁気ディスクドライブを識別するための物理デバイスIDと、物理デバイス内の相対位置であるLBAである。
図5は、マッピングの関係を示す説明図である。
図5は、ホストコンピュータ100によって認識されるデータベース領域、ホストコンピュータ100で稼働するオペレーティングシステムによって認識される論理ボリューム、デバイスファイル、及び、ストレージ装置200のLUのマッピング関連の例を示す。
データベース管理システム130は、データを格納するデータベース領域は、複数のファイルから構成されるものとして認識する。構成される各ファイルは、ホストコンピュータ100で稼働するオペレーティングシステムのファイルに対応している。なお、図5では、オペレーティングシステムにおいてRAWデバイスとして認識されるケースを想定している。
また、オペレーティングシステムのファイルは、物理的なディスクドライブに対応するデバイスファイルとして管理されている。デバイスファイルは、ストレージ装置200のLUにマッピングされている。
次に、本実施形態のデータベースシステムの処理を説明する。
図6は、ストレージ装置200の受け付けコマンド解析処理のフローチャートである。
ストレージ装置200は、ホストコンピュータ100からの要求に基づいて、この処理を行う。
ホストインタフェース処理部212は、ホストコンピュータ100からの要求を受信し、その内容を解析する。
ホストコンピュータ100からの要求が読み出し要求(Readコマンド)又は書き込み要求(Writeコマンド)であった場合は(ステップ1001)、ステップ1002に移行する。ステップ1002では、ホストコンピュータ100からの要求がReadコマンドであるかWriteコマンドであるかが判定される。
ホストコンピュータ100からの要求がReadコマンドであった場合は、Read処理(図7参照)が実行される(ステップ1011)。ホストコンピュータ100からの要求がWriteコマンドであった場合は、Write処理(図8参照)が実行される(ステップ1012)。
ホストコンピュータ100からの要求がボリュームコピーコマンドであった場合は(ステップ1003)、ボリュームコピー処理(図9参照)が実行される(ステップ1004)。
ホストコンピュータ100からの要求がDB再編成コマンドであった場合は(ステップ1005)、図11に示すDB再編成処理が実行される(ステップ1006)。
何れのコマンドでもない場合は、処理が終了される。
図7は、Read処理のフローチャートである。
この処理は、ホストインタフェース処理部212によって実行される。
まず、受信したコマンドが解析され、当該コマンドの内容及びアクセス先のアドレスを取得する(ステップ1101)。
次に、取得されたアクセス先のアドレスのデータが、キャッシュメモリ211に格納されているか否かを判定する(ステップ1102)。
データがキャッシュメモリ211に格納されていると判定した場合は、ステップ1105に移行する。
データがキャッシュメモリ211に格納されていないと判定した場合は、要求データを読み出してキャッシュメモリ211に転送させる旨の転送依頼を、ディスクアクセス制御部215に送る(ステップ1103)。このとき、転送先のキャッシュメモリ211の転送先アドレスのデータが更新されたことを示す情報が、キャッシュメモリ211に設けられたキャッシュ管理テーブルに登録される。
この転送要求によって、ディスクドライブ220からキャッシュメモリ211にデータが転送される。そして、このデータの転送が終了したか否かを判定する(ステップ1104)。
データの転送がまだ終了していないと判定した場合は、データの転送が終了するまで待機する。データの転送が完了したと判定した場合は、ステップ1105に移行する。
ステップ1105では、キャッシュメモリ211に格納されている要求データを、ホストコンピュータ100に送信する。その後、処理を終了する。
このRead処理によって、要求データがホストコンピュータ100に送信される。
図8は、Write処理のフローチャートである。
この処理は、ホストインタフェース処理部212によって実行される。
まず、受信したWriteコマンドが解析され、当該コマンドの内容、アクセス先のアドレス及び書き込みデータを取得する(ステップ1201)。
次に、取得したアクセス先のアドレスに既に存在するデータは、キャッシュメモリ211に格納されているか否かを判定する(ステップ1202)。
データがキャッシュメモリ211に格納されていると判定した場合は、ステップ1205に移行する。
データがキャッシュメモリ211に格納されていないと判定した場合は、当該アドレスに存在するデータを読み出してキャッシュメモリ211に転送させる旨の転送要求を、ディスクアクセス制御部215に送る(ステップ1203)。このとき、転送先のキャッシュメモリ211の転送先アドレスのデータが更新されたことを示す情報が、キャッシュメモリ211に設けられたキャッシュ管理テーブルに登録される。
この転送要求によって、ディスクドライブ220からキャッシュメモリ211にデータが転送される。そして、このデータの転送が終了したか否かを判定する(ステップ1204)。
データの転送がまだ終了していないと判定した場合は、データの転送が終了するまで待機する。データの転送が完了したと判定した場合は、ステップ1205に移行する。
ステップ1205では、キャッシュメモリ211に格納されているデータを、Writeコマンドによって指示された書き込みデータに更新する。
このデータの更新が完了すると、ステップ1206に移行し、Write処理が完了した旨を、ホストコンピュータ100に送信する。その後、処理を終了する。
図9は、ボリュームコピー処理のフローチャートである。
この処理は、ホストインタフェース処理部212によって実行される。
ホストインタフェース処理部212は、ホストコンピュータ100からの要求を受信し、その内容を解析する。ボリュームコピーコマンドには、コピー処理及びペア切り離し処理があり、いずれかの処理が選択される。
ホストコンピュータ100からの要求がペア生成コマンドであった場合は(ステップ1301)、コピー処理を実行する(ステップ1302)。具体的には、コピー元の論理ボリュームの内容をコピー先の論理ボリュームに全て複写(コピー)する。また。この処理によってコピー元論理ボリューム及びコピー先論理ボリュームが同期状態となる。
ホストコンピュータ100からの要求がペア分割コマンドであった場合は(ステップ1303)、ペア切り離し処理を実行する(ステップ1304)。具体的には、同期されている二つの論理ボリュームの同期が解除される。
ホストコンピュータ100からの要求がペア再同期コマンドであった場合は(ステップ1305)、ボリュームコピー処理を実行する(ステップ1306)。この処理はステップ1302と同様である。
何れのコマンドでもない場合は、処理を終了する。
図10は、DB再編成制御処理のフローチャートである。
この処理は、ホストコンピュータ100のDB再編成制御部151によって実行される。
DB再編成制御処理が開始されると、まず、データベースを静止化する(ステップ1401)。具体的には、DB再編成制御部151は、DBアクセス制御部140に対して、データベースに対するトランザクションの受け付けを停止させ、実行中のトランザクションを全て完了させる要求を送る。
次に、ボリュームペアを分割する(ステップ1402)。具体的には、DB再編成制御部151は、ストレージ装置200に対してペア分割コマンドを送る。これによって、同期されているボリュームペアである主DB222及び副DB223の同期を解除し、ボリュームペアが分割される。
次に、データベースの処理を受け付けるボリューム(カレントデータベース)を主DB222のみに変更する。その後、データベースの静止化を解除する(ステップ1403)。具体的には、DB再編成制御部151は、DBアクセス制御部140に、カレントデータベース主DB222のみにする要求を送る。また、DB再編成処理部151は、DBアクセス制御部140に、データベースに対するトランザクションの受付を開始する要求を送る。この処理によって、主DB222のみがホストコンピュータ100のアクセス対象となる
次に、図11に示すDB再編成処理を実行する(ステップ1404)。具体的には、DB再編成制御部151が、ストレージ装置200に対して、DB再編成コマンドを送信する。
DB再編成処理が完了すると、ボリュームペアを再同期させる(ステップ1405)。具体的には、DB再編成制御部151は、ストレージ装置200に対してボリュームペア再同期コマンドを送る。これによって、主DB222及び副DB223がボリュームペアとして再同期される。
この再同期において、副DB223の内容はDB再編理完了後のデータベースの空間の乱れや不均衡化が解決された状態である。この副DB223の内容を主DB222にコピーすることで、主DB222及び副DB223の内容が、共に再編成処理完了後の内容となる。
以上の処理によって、データベースが再編成される。
図11は、ディスクドライブの再編成処理の説明図である。
この処理は、DB再編成処理部213によって実行される。
図11では、3つのLU(LI#1、LU#2及びLU#3)が示されている。これらはそれぞれ主DB、副DB及びログの領域として設定されている。
業務運用時は、LU#1及びLU#2は同期している。LU#1、すなわち主DBに対するアクセスは、LU#2、すなわち副DBに対しても実行され、LU#1とLU#2との内容は常に同一となる。また、このアクセスのログがLU#3に格納される。
まず、データベースの静止化が実行され、トランザクションの受け付けを停止する。データベースの静止化が完了すると、LU#1とLU#2との同期を解除し、LU#1とLU#2とでのボリュームペアが分割される。
ボリュームペアが分割されると、データベースの静止化が解除され、トランザクションの受け付けが再開される。このとき、データベースのアクセスはLU#1に対してのみ行われるよう設定を変更する。
この状態でLU#2の再編成処理が実行される。LU#1とLU#2とは分割され非同期状態にあるので、システムの運用は再編成処理の影響を受けない。また、再編成処理中のアクセスのログはLU#3に格納される。
LU#2の再編成が完了すると、LU#3に格納されたログを用いて追い付き処理が実行される。
この追い付き処理が完了すると、アクセスを受け付けているLU#1とLU#2とのデータは論理的に等価となる。
次に、LU#2の内容をLU#1にコピーすることで、LU#2とLU#1とを同期させる。
同期が完了すると、再編成処理が完了する。
図12は、DB再編成処理のフローチャートである。
この処理は、DB再編成処理部213によって実行される。
まず、指定されたデータベースのデータベース領域IDを取得する。そして、DB定義情報224及びDB−ディスクブロック変換テーブル225を参照し、当該データベースが格納されている領域(論理ボリューム)を示す識別子を取得する(ステップ1501)。
次に、ステップ1501において取得された論理ボリュームと同じ(又はそれ以上)の容量を持つ論理ボリューム(以降、「アンロード用ボリューム」と呼ぶ)を新たに作成する。そして、作成したアンロード用ボリュームに、データベースの内容を論理的に複写(コピー)する(ステップ1502)。この場合、データベースの空間の乱れや不均衡化を解決するように、各データのディスクドライブ上の配置を考慮して、論理ボリュームの内容をアンロード用ボリュームにコピーする。
例えば、同一の表ブロック又は同一の索引ブロックは、物理的に連続した領域に格納される。また、指定された充填率目標値に基づいて、アンロード用ボリュームにデータを格納する。なお、このステップ1502の処理を、以降は「アンロード処理」と呼ぶ。
このように、アンロード処理によってデータのコピーされたアンロード用ボリュームとデータベースが保存されていた論理ボリュームとは、論理的には等価であるが、各データの物理配置は必ずしも等価ではない。
次に、アンロード処理が完了したデータのコピー元である論理ボリュームを初期化する(ステップ1503)。
次に、アンロード用ボリュームの内容を、初期化した論理ボリュームにコピーする(ステップ1504)。この場合は、ステップ1502のアンロード処理のコピーとは異なり、図9において前述したコピー処理として、論理ボリュームの内容がそのままコピーされる。
ステップ1501乃至1504の処理によって、データベースの再編成が完了する。次に、このデータベースの再編成の処理の間に記録されたログをデータベースの再編成された論理ボリュームに反映させる追い付き処理を実行する(ステップ1505)。この追い付き処理は図13で後述する。
追い付き処理が完了すると、DB再編成処理部213は、ホストコンピュータ100に、DB再編成処理が完了した旨を送信し、図10のフローチャートに復帰する。
図13は、追い付き処理のフローチャートである。
この処理は、DB再編成処理部213によって実行される。
まず、DB再編成処理が実行されていた間に記録されたログを、ログ221から一つずつ読み出す(ステップ1601)。
次に、読み出されたログが、表のデータであるか、索引のデータであるかを判定する(ステップ1602)。
読み出されたログが表のデータであると判定された場合は、表追い付き処理が実行される(ステップ1603)。この処理は図15で後述する。
読み出されたログが索引のデータであると判定された場合は、索引追い付き処理が実行される(ステップ1604)。この処理は図24で後述する。
実際には、表追い付き処理の完了後に、表追い付き処理によってアドレスが追加されたアドレス変換表225を用いて、索引追い付き処理が実行される。
そして、表追い付き処理及び索引追い付き処理が実行された場合は、図11のフローチャートに復帰する。
次に、追い付き処理について説明する。
本実施の形態では、DB再編成処理部213が、再編成処理期間中のログのうち必要なものを抽出し、そのログをデータベースの行アドレス毎に集約する。そして、集約したログによってデータベースの追い付き処理を行う。
図14A、図14Bは、再編成期間中のログから抽出されるログの説明図である。
表ブロックの行に対するログは、行の挿入、行の削除及び行の更新が抽出される。索引ブロックの索引エントリに対するログ(索引ログ)は、索引エントリの挿入及び索引エントリの削除が抽出される。抽出されたログは、後に説明するようにディスク装置210のメモリ216に設けられたバッファに格納される。
その他のログ、例えば、ブロックの新規割り当て、ブロックの解放又はブロックの分割などデータベースの構造の変更を示すログは、再編成後のデータベースに対しては考慮する必要がないので抽出されない。
表ブロックの行に対するログ(行ログ4001)は、ログシーケンス番号(LSN)、ログの種別、行アドレス及び行データによって構成される(図14A)。
LSNはログ毎に、ログが記録された順に付けられる番号である。ログの種別は、当該ログの操作の種別が格納される。「INS」は挿入を示す。「DEL」は削除を示す。「UPD」は更新を示す。行アドレスは、対象となる行が格納されているアドレスを示す。
行データには、挿入であれば、挿入される新たな行データが格納される。削除であれば行データは空欄となる。更新であれば、更新前の行データと更新後の行データとが格納される。
索引エントリに対するログ(索引ログ4002)は、ログシーケンス番号(LSN)、ログの種別、索引アドレス、キーデータ及び行アドレスによって構成される(図14B)。
ログの種別は、索引エントリに対する操作の種別が格納される。「IS1」は索引エントリの挿入を示す。「DL1」は索引エントリの削除を示す。
キーデータには、挿入であれば、挿入される新たなキーデータが格納される。削除であればキーデータは空欄となる。
行アドレスには、当該索引エントリに対応する行のアドレスが格納される。
図15は、表追い付き処理の概要のフローチャートである。
この処理は、DB再編成処理部213によって実行される。
まず、時系列に格納されているログから、再編成処理中に記録されたログが切り出され、取得される。
なお、再編成処理中のみでなく、再編成処理後に、この表追い付き処理の実行中に記録されるログについても考慮する必要がある。これに対しては、再編成処理中のログの追い付き処理を完了した後に、追い付き処理中に記録されたログを、さらに追い付き処理する方法や、再編成処理中のログの追い付き処理中に記録されたログについても、並行して追い付き処理する方法等が考えられる。
次に、切り出されたログ系列から、挿入(INS)、削除(DEL)及び更新(UPD)のログが抽出される。
次に、抽出されたログ系列が、行アドレス毎に集約される。具体的には、抽出されたログ系列が行アドレス毎にまとめられ、行アドレス毎に時系列順に並べられる。そして、行アドレス毎に一つのログに変換される。このログの変換は図16で後述する。
そして、この行アドレス毎に、行へのログが適用される。このとき、ログの対象となっている行アドレスが、アドレス変換表に記録されているか否かが判定される。
アドレス変換表に記録されている場合は、アドレス変換表226を参照することで、再編成処理後の行アドレスを参照できる。
一方、アドレス変換表に記録されていない場合は、再編成処理前に存在しなかった行のアドレスに、再編成処理中に挿入がされている。
アドレス変換表に記録されているか否かは、当該ログの行アドレスを参照することで判定される。
アドレス変換表に記録されている行アドレスについては、アドレス変換後のアドレスに並び替えを行い、一つのログに集約された処理が実行される。例えば集約された当該ログが「削除」であった場合は、当該行アドレスの行が削除される。
一方、アドレス変換表に記録されていない行アドレスについては、新たな行アドレスの領域を挿入し、当該挿入された行アドレスにデータを書き込む。この新たな行アドレスは、アドレス変換表226に記録される。
図16A、図16Bは、ログの集約の説明図である。
図16Aにおいて、既に主DB222に存在する行アドレスの行に対してされた操作が「DEL」(削除)又は「UPD」(更新)のみであった場合は、そのまま、「DEL」又は「UPD」ログとする。
行アドレスで特定される行に、複数のログが記録されている場合は、複数のログのうち、最古のログ(最初に記録されたログ)及び最新のログ(最後に記録されたログ)のみを取り出して変換処理を行う。
最古のログが「DEL」であり、最新のログが「INS」(挿入)である場合は、当該行アドレスに対する操作は、一つの「UPD」に変換される。
最古のログが「DEL」であり、最新のログが「DEL」である場合は、当該行アドレスに対する操作は、一つの「DEL」に変換される。
最古のログが「DEL」であり、最新のログが「UPD」である場合は、当該行アドレスに対する操作は、一つの「UPD」に変換される。
最古のログが「UPD」であり、最新のログが「INS」である場合は、当該行アドレスに対する操作は、一つの「UPD」に変換される。
最古のログが「UPD」であり、最新のログが「DEL」である場合は、当該行アドレスに対する操作は、一つの「DEL」に変換される。
最古のログが「UPD」であり、最新のログが「UPD」である場合は、当該行アドレスに対する操作は、一つの「UPD」に変換される。
一方、図16Bにおいて、再編成処理前に存在しなかった行アドレスに対してなされた操作、すなわち、最古のログが「INS」である場合は、アドレス変換表に記録されていないログとしてログが変更される。
この場合、当該行アドレスに対してなされた操作が「INS」のみであった場合は、そのまま「INS」ログとする。
行アドレスで特定される行に、複数のログが記録されている場合は、複数のログのうち、最古のログ(最初に記録されたログ)及び最新のログ(最後に記録されたログ)のみを取り出して変換処理を行う。
最古のログが「INS」であり、最新のログが「INS」である場合は、当該行アドレスに対する操作は、一つの「INS」に変換される。
最古のログが「INS」であり、最新のログが「DEL」である場合は、当該行アドレスに対する操作は、「NOP」(No Operation)に変換される。実際には、当該行アドレスには操作は行われない。
最古のログが「INS」であり、最新のログが「UPD」である場合は、当該行アドレスに対する操作は、一つの「INS」に変換される。
図17は、表追い付き処理のフローチャートである。
この処理は、DB再編成処理部213によって実行される。
まず、ログの終端までを読み出したか否かを判定する(ステップ2001)。
ログの終端まで読み出されたと判定した場合は、処理を終了する。
まだログの終端まで読み出されていないと判定した場合は、ログ系列の読み出し処理が実行される(ステップ2002)。この処理によって、ログ221から必要なログがログ系列として抽出される。抽出されたログ系列は、バッファAに格納される。
次に、バッファAに格納されたログ系列の集約処理が実行される(ステップ2003)。この処理によって、行アドレス毎に一つのログに変換され、バッファBに格納される。
次に、集約されたログの、アドレス変換処理が実行される(ステップ2004)。この処理によって、アドレス変換表に記録されているログとアドレス変換表に記録されていないログとが判別され、アドレス変換表226に基づいて再編成処理前後の行アドレスが変換され、それぞれ別のバッファ(バッファC、バッファD)に格納される。
次に、バッファCに格納されたログをデータベースの表に適用するログ適用処理1が実行される(ステップ2005)。
次に、バッファDに格納されたログをデータベースの表に適用するログ適用処理2が実行される(ステップ2006)。
以上の処理が、全てのログの読み込みが完了するまで実行される。
なお、ステップ2005及びステップ2006は、必ずこのフローチャートの処理順序で実行される必要はない。バッファC及びバッファDにログが格納された時点で、各々の処理が開始されるようにしてもよい。
なお、これらのバッファA、B、C及びDは、ディスク制御装置210のメモリ216に設けられる。
図18は、図17のステップ2002のログ系列の読み出し処理のフローチャートである。
この処理は、DB再編成処理部213によって実行される。
まず、ログの終端まで読み出されたか否か、又は、バッファAに設定された容量の上限までログが格納され、バッファAが満杯となったか否かを判定する(ステップ2101)。
ログの終端まで読み出されたと判定した場合、又は、バッファAが満杯となったと判定した場合は、図17のフローチャートに復帰する。
一方、またログの終端ではなく、かつ、まだバッファAは満杯でないと判定した場合は、ログ221に記録された再編成処理中のログが読み出される(ステップ2102)。
次に、読み出されたログの種類が判別される(ステップ2103)。読み出されたログの種類が、INS(挿入)、UPD(更新)、DEL(削除)であった場合は、ステップ2140に移行し、当該ログがバッファAに格納される。
一方、読み出されたログの種類が、INS(挿入)、UPD(更新)、DEL(削除)の何れでもない場合は、ログを適用する必要がないため、ステップ2101に戻る。
このログ系列の読み出し処理によって、追い付き処理に必要なログ、すなわちINS(挿入)、UPD(更新)、DEL(削除)のログが抽出され、バッファAに格納される。
図19は、図17のステップ2003のログ系列の集約処理のフローチャートである。
この処理は、DB再編成処理部213によって実行される。
前述したように、抽出したログ系列が行アドレス毎に集約され、ログの変換が行われる。
まず、バッファAに格納されたログを、行アドレスの順で並べ替える(ステップ2201)。
次に、バッファAから並べ替えられたログの終端まで読み出されたか否かを判定する(ステップ2101)。並び替えられたログの終端まで読み出されたと判定した場合は、図17のフローチャートに復帰する。
並び替えられたログが、まだ終端まで読み出されていないと判定した場合は、バッファAから、同一の行アドレスのログが読み出される(ステップ2203)。
次に、読み出された同一の行アドレスのログが変換される(ステップ2204)。なお、この処理は図20で後述する。この処理によって、同一の行アドレスに対する操作が一つのログに変換される。
次に、変換されたログが、行アドレス毎にバッファBに格納される(ステップ2205)。そして、ステップ2202に戻り、次の行アドレスについて処理する。
図20は、図19のステップ2203のログの変換のフローチャートである。
この処理は、DB再編成処理部213によって実行される。
まず、同一の行アドレスのログのうち、最古のログの種別を判定する(ステップ2301)。最古のログの種別が更新(UPD)又は削除(DEL)であると判定した場合は、ステップ2302に移行する。最古のログの種類が挿入(INS)であると判定した場合は、ステップ2305に移行する。
ステップ2302では、同一の行アドレスのログのうち、最新のログの種別が判別される。最新のログの種類がINS又はUPDであると判定した場合は、ステップ2303において、当該行アドレスのログはUPDに変換される。
一方、最新のログの種類がDELであると判定した場合は、ステップ2304において、当該行アドレスへのログはDELに変換される。
同様に、ステップ2305では、同一の行アドレスのログのうち、最新のログの種別を判別する。最新のログの種類がINS又はUPDであると判定した場合は、ステップ2306において、当該行アドレスへのログはINSに変換される。
一方、最新のログの種類がDELであると判定した場合は、ステップ2307において、当該行アドレスへのログは出力されない。
ログの変換が完了すると、図19の処理に復帰する。
図21は、図17のステップ2004のアドレス変換処理のフローチャートである。
この処理は、DB再編成処理部213によって実行される。
まず、バッファBに格納されたログが、終端まで読み出されたか否かを判定する(ステップ2401)。ログの終端まで読み出されたと判定した場合は、図17のフローチャートに復帰する。
ログがまだ終端まで読み出されていないと判定した場合は、バッファBから、同一の行アドレスのログが読み出される(ステップ2402)。
次に、読み出されたログの行アドレスが、アドレス変換表に記録されているか否かを判定する(ステップ2403)。当該行アドレスがアドレス変換表に記録されていないと判定した場合は、ステップ2404に移行し、当該ログがバッファDに格納される。
当該行アドレスがアドレス変換表に記録されていると判定した場合は、ステップ2405に移行し、アドレス変換表に基づいて、当該ログの行アドレスを再編成処理後の行アドレスに変換する。
次に、行アドレスが変換されたログを、バッファBに格納する(ステップ2406)。
図22は、図17のステップ2205のログ適用処理1のフローチャートである。
この処理は、DB再編成処理部213によって実行される。
まず、バッファCに格納されたログを、行アドレスの順で並べ替えられる(ステップ2501)。
次に、並び替えられたログが読み出され、ディスクドライブ220のデータベースに適用される(ステップ2502)。具体的には、読み出されたログが、データベース上のログが示す行アドレスに適用される。
なお、適用されたログのうち、DEL(削除)のログは、当該ログの示す行アドレスがアドレス変換表から削除される(ステップ2503)。
このログの適用処理1が完了すると、図17の処理に復帰する。
なお、このログの適用の際に、ディスクドライブ220の磁気ディスクドライブ毎にログを分離し、磁気ディスクドライブ毎に並列処理を行うことによって、ログの適用の処理を高速化してもよい。
図23は、図17のステップ2006のログ適用処理2のフローチャートである。
この処理は、DB再編成処理部213によって実行される。
まず、バッファDに格納されているログを読み出し、ディスクドライブ220のデータベースに適用する(ステップ2601)。この場合のログは、全てINSであるので(図16B参照)具体的には、当該ログに基づいて、データベースへの挿入が処理される(ステップ2601)。
次に、適用したログの行アドレスが、アドレス変換表に登録される(ステップ2602)。
このログの適用処理2が完了すると、図17の処理に復帰する。
このように、表追い付き処理(図17)によって、再編成処理中の記録された行ブロックに対するログが、再編成処理後のデータベースに適用される。
次に、索引追い付き処理について説明する。
図24は、索引追い付き処理の概要のフローチャートである。
この処理は、DB再編成処理部213によって実行される。
まず、時系列に格納されているログから、再編成処理中に記録された索引ログが切り出され、取得される。
なお、再編成処理中のみでなく、再編成処理後に、この索引追い付き処理の実行中に記録されるログについても考慮する必要がある。これに対しては、再編成処理中のログの追い付き処理を完了した後に、追い付き処理中に記録されたログを、さらに追い付き処理する方法や、再編成処理中のログの追い付き処理中に記録されたログについても、並行して追い付き処理する方法等が考えられる。
次に、切り出された索引ログから、IS1(挿入)及びDL1(削除)の索引ログが抽出される。
次に、抽出された索引ログが、行アドレス毎に集約される。具体的には、抽出された索引ログに示される行アドレス毎にまとめられ、時系列順に並べられる。そして、行アドレス毎の索引ログに変換される。この索引ログの変換は図27で後述する。
そして、この行アドレスが、アドレス変換表に記録されているか否かが判定される。
アドレス変換表に記録されている場合は、アドレス変換表226を参照することで、当該索引ログに含まれている行アドレスから、再編成処理後の行アドレスを参照できる。一方、アドレス変換表に記録されていない場合は、再編成処理前に存在しなかった行のアドレスに、再編成処理中に挿入されている。
アドレス変換表に記録されているか否かは、当該索引ログの行アドレスを参照することで判定される。アドレス変換表に記録されている行アドレスについては、最古の索引ログが「DL1」である行アドレスが抽出される。
次に、アドレス変換表に基づいて、索引アドレスが変換される。
この場合、索引アドレスが変換されない場合、すなわち、再編成処理中に、索引エントリが削除された索引アドレスは、索引アドレスが変換できないので、当該索引ログに従って索引エントリが削除される。
アドレス変換表に基づいて、索引アドレスが変換される場合は、まず、索引アドレス順にログが並び替えられる。そして、並び替えられた索引ログをデータベースに適用する。
一方、アドレス変換表に記録されていない行アドレスについては、最古の索引ログがIS1である行アドレスが抽出される。なお、アドレス変換表に記録されていない行アドレスの最古の索引ログがIS1であり、最新の索引ログがDL1である場合は、アドレス変換表に記録されているログとして扱う。この索引ログについては、新たな行アドレスの領域を挿入する。この新たな行アドレスは、アドレス変換表226に記録される。
図25A、図25Bは、索引ログのアドレス変換の説明図である。
再編成処理前に存在しなかった索引アドレスの索引ログは、図25Aのように当該索引アドレスに対応する行アドレスを、アドレス変換表に基づいて変換する。
この場合、当該行アドレスに対してなされた操作が「DL1」のみであった場合は、そのまま「DL1」ログとする。
一方、同一の索引アドレスに対して、複数の索引ログが記録されている場合は、複数の索引ログのうち、最古の索引ログ(最初に記録された索引ログ)及び最新の索引ログ(最後に記録された索引ログ)のみを取り出して変換処理を行う。
最古のログが「IS1」であり、最新のログが「DL1」である場合は、当該索引アドレスに対する操作は、「NOP」(No Operation)に変換される。実際には、当該索引アドレスには操作は行われない。
最古のログが「DL1」(削除)であり、最新のログが「DL1」である場合は、当該行アドレスに対する操作は、一つの「DL1」に変換される。
既にデータベースに存在する索引アドレスの索引エントリに対してなされた操作が「IS1」(挿入)のみであった場合は、図25Bのように、そのまま「IS1」ログに変換される。
一方、同一の索引アドレスに対して、複数の索引ログが記録されている場合は、複数の索引ログのうち、最古の索引ログ(最初に記録された索引ログ)及び最新の索引ログ(最後に記録された索引ログ)のみを取り出して変換処理を行う。
最古のログが「IS1」であり、最新のログが「IS1」である場合は、当該行アドレスに対する操作は、一つの「IS1」に変換される。
最古のログが「DL1」(削除)であり、最新のログが「IS1」である場合は、当該行アドレスに対する操作は、「DL1」、「IS1」という二つのログに変換される。
図26は、索引追い付き処理を示すフローチャートである。
この処理は、DB再編成処理部213によって実行される。
まず、索引ログを終端まで読み出したか否かを判定する(ステップ3001)。
索引ログの終端まで読み出されたと判定した場合は、処理を終了する。
まだ索引ログの終端まで読み出されていないと判定した場合は、索引ログの読み込み処理が実行される(ステップ3002)。この処理によって、ログ221から必要な索引ログがログ系列として抽出され、バッファEに格納される。
次に、バッファEに格納された索引ログ系列の集約処理が実行される(ステップ3003)。この処理によって、行アドレス毎の索引ログに変換され、バッファFに格納される。
次に、アドレス変換処理が実行される(ステップ3004)。この処理によって、アドレス変換表に記録されている索引ログとアドレス変換表に記録されていない索引ログとが判別され、それぞれ別のバッファG、バッファHに格納される。
次に、バッファGに格納された索引ログをデータベースの表に適用する索引ログ適用処理1が実行される(ステップ3005)。
次に、バッファHに格納された索引ログをデータベースの表に適用する索引ログ適用処理2が実行される(ステップ3006)。
以上の処理が、全ての索引ログの読み込みが完了するまで実行される。
なお、ステップ3005及びステップ3006は、必ずこのフローチャートの処理順序で実行される必要はない。バッファG及びバッファHにログが格納された時点で、順次処理を開始するようにしてもよい。
なお、これらのバッファE、F、G及びHは、ディスク制御装置210のメモリ216に設けられる。
図27は、図26のステップ3002の索引ログ系列読み込み処理のフローチャートである。
この処理は、DB再編成処理部213によって実行される。
まず、索引ログの終端まで読み出されたか否か、又は、バッファEに設定された容量の上限まで索引ログが格納され、バッファEが満杯となったか否かを判定する(ステップ3101)。
索引ログの終端まで読み出されたと判定した場合、又は、バッファEが満杯となったと判定した場合は、図26のフローチャートに復帰する。
一方、またログの終端ではなく、かつ、まだバッファEは満杯でないと判定した場合は、ログ221に記録された再編成処理中の索引ログが読み出される(ステップ3102)。
次に、読み出されたログの種類が判別される(ステップ3103)。読み出されたログの種類が、IN1(挿入)又はDL1(削除)であった場合は、ステップ3140に移行し、当該ログがバッファEに格納される。
一方、読み出されたログの種類が、IN1(挿入)及びDL1(削除)の何れでもない場合は、ログを適用する必要がないため、ステップ3101に戻る。
このログ読み込み処理によって、追い付き処理に必要なログ、すなわちIS1(挿入)及びDL1(削除)の索引ログが抽出され、バッファEに格納される。
図28は、図26のステップ3003の索引ログ系列の集約処理のフローチャートである。
この処理は、DB再編成処理部213によって実行される。
前述したように、抽出されたログ系列が行アドレス毎に集約され、索引ログが変換される。
まず、バッファEに格納された索引ログ系列が、行アドレスの順で並べ替えられる(ステップ3201)。
次に、バッファEに格納された並べ替えられた索引ログの終端まで読み出されたか否かを判定する(ステップ3101)。並び替えられた索引ログの終端まで読み出されたと判定した場合は、図26のフローチャートに復帰する。
並び替えられた索引ログが、まだ終端まで読み出されていないと判定した場合は、バッファEから、同一の行アドレスの索引ログが読み出される(ステップ3203)。
次に、読み出された同一の行アドレスのログが変換される(ステップ3204)なお、この処理は図29で後述する。この処理によって、同一の行アドレス毎の索引ログに変換される。
次に、変換された索引ログが、バッファFに格納される(ステップ3205)。そして、ステップ3202に戻り、次の行アドレスについて処理される。
図29は、図28の索引ログ変換のフローチャートである。
この処理は、DB再編成処理部213によって実行される。
まず、同一の行アドレスに対する索引ログのうち、最古の索引ログの種別を判定する(ステップ3301)。最古の索引ログの種別がDL1であると判定した場合は、ステップ3302に移行する。最古の索引ログの種類がIS1であると判定した場合は、ステップ3305に移行する。
ステップ3302では、同一の行アドレスの索引ログのうち、最新の索引ログの種別が判別される。最新の索引ログの種類がIS1であると判定した場合は、ステップ3303において、当該行アドレスの索引ログは、DL1及びIS1に変換される。
一方、最新の索引ログの種類がDL1であると判定した場合は、ステップ3304において、当該行アドレスへの索引ログはDL1に変換される。
同様にステップ3305では、同一の行アドレスに対する索引ログのうち、最新の索引ログの種別を判別する。最新の索引ログの種類がIS1あると判定した場合は、ステップ3306において、当該行アドレスの索引ログはIS1に変換される。
一方、最新の索引ログの種類がDL1であると判定した場合は、ステップ3307において、当該行アドレスの索引ログは出力されない。
索引ログの変換が完了すると、図28の処理に復帰する。
図30は、図26のステップ3004のアドレス変換処理のフローチャートである。
この処理は、DB再編成処理部213によって実行される。
まず、バッファFに格納された索引ログが、終端まで読み出されたか否かを判定する(ステップ3401)。索引ログの終端まで読み出されたと判定した場合は、図26のフローチャートに復帰する。
索引ログがまだ終端まで読み出されていないと判定した場合は、バッファFから、同一の行アドレスの索引ログが読み出される(ステップ3402)。
次に、読み込んだ索引ログの行アドレスが、アドレス変換表に記録されていており、アドレス変換表から当該行アドレスが参照可能か否かを判定する(ステップ3403)。当該行アドレスがアドレス変換表に記録されていない場合と判定した場合は、ステップ3404に移行する。
ステップ3404では、当該索引ログが、アドレス変換表に基づいて、変換後の行アドレスに変換される。そして、行アドレスの変換された索引ログが、バッファHに格納される(ステップ3405)。
一方、当該行アドレスがアドレス変換表に記録されていると判定された場合は、ステップ3406に移行し、当該行索引ログの索引アドレスが、アドレス変換表に基づいて変換後の索引アドレスに変換される。
そして、行アドレスの変換されたログが、バッファGに格納される(ステップ3407)。
図31は、図26のステップ2005の索引ログ適用処理1のフローチャートである。
この処理は、DB再編成処理部213によって実行される。
まず、バッファGに格納された索引ログを、索引アドレスの順で並べ替えられる(ステップ3501)。
次に、並び替えられた索引ログが読み出され、ディスクドライブ220のデータベースに適用される(ステップ3502)。具体的には、読み出された索引ログに示される索引アドレスの索引エントリに、当該索引ログの内容が適用される。
また、DL1(削除)を指示する索引ログに関しては、当該索引アドレスがアドレス変換表から削除される(ステップ3503)。
この索引ログ適用処理1が完了すると、図26の処理に復帰する。
なお、このログの適用の際に、ディスクドライブ220の磁気ディスクドライブ毎にログを分離し、磁気ディスクドライブ毎に並列処理を行うことによって、ログの適用の処理を高速化してもよい。
図32は、図26のステップ3006の索引ログ適用処理2のフローチャートである。
この処理は、DB再編成処理部213によって実行される。
まず、バッファHに格納されている索引ログが読み出され、ディスクドライブ220のデータベースに適用される(ステップ3602)。具体的には、読み出された索引ログに示される索引アドレスに対して、当該索引ログの内容に基づいて索引エントリの領域が挿入され、索引ログに基づいてその内容が適用される。
次に、索引エントリを挿入した索引アドレスが、アドレス変換表に登録される(ステップ3602)。
この索引ログ適用処理2が完了すると、図26の処理に復帰する。
このように、索引追い付き処理(図28)によって、再編成処理中のデータベースの索引ログが、再編成が処理されたLUに適用される。
前述したように、本発明の実施の形態のデータベースシステムでは、ストレージ装置200に再編成の処理機能である再編成処理部213を設けたので、ホストコンピュータ100からの指示によって、ストレージ装置200側でデータベースの再編成処理を行うことができる。この再編成処理において、ストレージ200は、再編成中にデータベースになされたトランザクションのログを格納しておき、再編成終了後に、当該ログの追い付き処理を行う。このようにすることで、データベースシステムの処理を停止することなく、データベースの再編成処理が可能となる。
次に、本発明の実施の形態の変形例であるデータベースシステムについて説明する。
前述した実施の形態のデータベースシステムでは、ホストコンピュータ100からの指示によって、ストレージ装置200が再編成処理するように構成した。本変形例では、ホストコンピュータ100からの指示によらず、ストレージ装置200が、再編成処理の開始を判断し再編成処理をする。以降に、その詳細を説明する。
ストレージ装置200は、実施の形態のように、ホストコンピュータ100からの再編成コマンドを受信した場合に、再編成処理をする。これとは別に、所定の条件となった場合に、再編成処理をする。
所定の条件とは、例えば、所定の時間間隔や、データベースを格納している論理ボリュームの容量の上限付近(ハイウォーターマーク)までデータが格納され、データを格納する領域がこれ以上見つからない場合等である。
この場合、ストレージ装置のDB再編成処理部213は、ディスクアクセス制御部215に、データベースのチェックポイントの場所を問い合わせる。チェックポイントは、データベースの内容の整合性を保証するために、全てのトランザクションが完了している時点を示す情報である。
DB再編成処理部213は、複数のチェックポイントのうち、最新のチェックポイントと最新のチェックポイント以前の直近のチェックポイントとを取得する。
そして、この二つのチェックポイント間に記録されたログを識別する。
以降、ストレージ装置200において、図10の処理が行われる。すなわち、DB再編成処理部213は、ボリュームペアを分割し(図10のステップ1402)、カレントデータベースを主DB222のみに切り換え、副DB223の再編成処理を行う。この場合、追い付き処理は、取得した最新のチェックポイントとそれ以前のチェックポイントと間に記録されたログが用いられる。
前述したように、本変形例では、ホストコンピュータ100の指示によらず、ストレージ装置200側で自立して再編成処理を開始することによって、ホストコンピュータ100側の処理負荷を低減できる。
本発明の実施の形態の、データベースシステムのブロック図である。 本発明の実施の形態の、表データの説明図である。 本発明の実施の形態の、索引データの説明図である。 本発明の実施の形態の、DB−ディスクブロック変換テーブル225の一例の表である。 本発明の実施の形態の、マッピングの関係を示す説明図である。 本発明の実施の形態の、ストレージ装置200の処理のフローチャートである。 本発明の実施の形態の、Read処理のフローチャートである。 本発明の実施の形態の、Write処理のフローチャートである。 本発明の実施の形態の、ボリュームコピー処理のフローチャートである。 本発明の実施の形態の、DB再編成制御処理のフローチャートである。 本発明の実施の形態の、ディスクドライブの再編成処理の説明図である。 本発明の実施の形態の、DB再編成処理のフローチャートである。 本発明の実施の形態の、追い付き処理のフローチャートである。 本発明の実施の形態の、再編成期間中のログから抽出されるログの説明図である。 本発明の実施の形態の、再編成期間中のログから抽出されるログの説明図である。 本発明の実施の形態の、表追い付き処理の概要のフローチャートである。 本発明の実施の形態の、ログの集約の説明図である。 本発明の実施の形態の、ログの集約の説明図である。 本発明の実施の形態の、表追い付き処理を示すフローチャートである。 本発明の実施の形態の、ログ読み出し処理のフローチャートである。 本発明の実施の形態の、ログの集約処理のフローチャートである。 本発明の実施の形態の、ログの変換のフローチャートである。 本発明の実施の形態の、アドレス変換処理のフローチャートである。 本発明の実施の形態の、ログ適用処理1のフローチャートである。 本発明の実施の形態の、ログ適用処理2のフローチャートである。 本発明の実施の形態の、索引追い付き処理の概要のフローチャートである。 本発明の実施の形態の、索引ログのアドレス変換の説明図である。 本発明の実施の形態の、索引ログのアドレス変換の説明図である。 本発明の実施の形態の、索引追い付き処理を示すフローチャートである。 本発明の実施の形態の、索引ログ読み込み処理のフローチャートである。 本発明の実施の形態の、索引ログの集約処理のフローチャートである。 本発明の実施の形態の、索引ログの変換のフローチャートである。 本発明の実施の形態の、アドレス変換処理のフローチャートである。 本発明の実施の形態の、索引ログ適用処理1のフローチャートである。 本発明の実施の形態の、索引ログ適用処理2のフローチャートである。
符号の説明
100 ホストコンピュータ
120 メモリ
130 DB管理システム
140 DBアクセス制御部
141 DB問合せ制御部
142 DBアクセス処理部
143 ログ出力処理部
150 DB運用操作制御部
151 DB再編成処理部
152 DBバックアップ制御部
153 DB回復制御部
154 DB状態回復制御部
160 ログバッファ
170 DBバッファ
210 ディスク制御部
211 キャッシュメモリ
213 DB再編成処理部
215 ディスクアクセス制御部
221 ログ
222 主DB
223 副DB
224 DB定義情報
225 DB−ディスクブロック変換テーブル
226 アドレス変換表

Claims (9)

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

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2004305680A JP4518485B2 (ja) 2004-10-20 2004-10-20 データベースの再編成方法、ストレージ装置及びストレージシステム
US11/080,648 US7421456B2 (en) 2004-10-20 2005-03-16 Method and system for data processing with database reorganization for the same

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2004305680A JP4518485B2 (ja) 2004-10-20 2004-10-20 データベースの再編成方法、ストレージ装置及びストレージシステム

Publications (2)

Publication Number Publication Date
JP2006119822A JP2006119822A (ja) 2006-05-11
JP4518485B2 true JP4518485B2 (ja) 2010-08-04

Family

ID=36182077

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004305680A Expired - Fee Related JP4518485B2 (ja) 2004-10-20 2004-10-20 データベースの再編成方法、ストレージ装置及びストレージシステム

Country Status (2)

Country Link
US (1) US7421456B2 (ja)
JP (1) JP4518485B2 (ja)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101681237B (zh) 2007-06-08 2011-09-21 富士通株式会社 加密装置及加密方法
US9430526B2 (en) * 2008-09-29 2016-08-30 Teradata Us, Inc. Method and system for temporal aggregation
US8180728B2 (en) * 2009-09-21 2012-05-15 Bmc Software, Inc. Area-specific reload of database
US20130238867A1 (en) * 2012-03-06 2013-09-12 Hitachi, Ltd. Method and apparatus to deploy and backup volumes
US8738823B2 (en) * 2012-10-16 2014-05-27 International Business Machines Corporation Quiescing input/output (I/O) requests to subsets of logical addresses in a storage for a requested operation
US10296235B2 (en) * 2016-06-27 2019-05-21 International Business Machines Corporation Partial volume reorganization to increase data availability

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000507375A (ja) * 1996-03-19 2000-06-13 シーベル システムズ,インコーポレイティド 部分的複製データベースシステムのネットワーク維持方法
JP2000347909A (ja) * 1999-06-07 2000-12-15 Hitachi Ltd トランザクション処理向けストレージ方法および装置、トランザクショナルストレージ
JP2001022620A (ja) * 1999-07-06 2001-01-26 Ricoh Co Ltd データベース変更処理最適化方式
JP2001344138A (ja) * 2000-05-30 2001-12-14 Ricoh Co Ltd データベースロギング方法及びデータベース回復方法
JP2001344136A (ja) * 2000-05-31 2001-12-14 Nec Corp 複写ディスク装置群管理システム及びそれに用いる複写ディスク装置群管理方法
JP2004157637A (ja) * 2002-11-05 2004-06-03 Hitachi Ltd ストレージ管理方法
JP2004199264A (ja) * 2002-12-17 2004-07-15 Hitachi Ltd データベース処理方法及びその実施装置並びにその処理プログラム

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH02212949A (ja) * 1989-02-14 1990-08-24 Nec Corp オンライン中データベース再編成処理方式
US5544347A (en) * 1990-09-24 1996-08-06 Emc Corporation Data storage system controlled remote data mirroring with respectively maintained data indices
JPH06250794A (ja) * 1993-02-24 1994-09-09 Toshiba Corp ディスクサブシステムの再構成が可能な部分的耐ディスク障害コンピュータ
US5721915A (en) * 1994-12-30 1998-02-24 International Business Machines Corporation Interaction between application of a log and maintenance of a table that maps record identifiers during online reorganization of a database
JPH10207754A (ja) * 1997-01-16 1998-08-07 Fujitsu Ltd 更新系データベースの複製方式
US6070170A (en) * 1997-10-01 2000-05-30 International Business Machines Corporation Non-blocking drain method and apparatus used to reorganize data in a database
US6289357B1 (en) * 1998-04-24 2001-09-11 Platinum Technology Ip, Inc. Method of automatically synchronizing mirrored database objects
JP4393762B2 (ja) 2002-12-19 2010-01-06 株式会社日立製作所 データベース処理方法及び装置並びにその処理プログラム
JP4290975B2 (ja) 2002-12-19 2009-07-08 株式会社日立製作所 データベース処理方法及び装置並びにその処理プログラム及びディザスタリカバリ方法及びシステム

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000507375A (ja) * 1996-03-19 2000-06-13 シーベル システムズ,インコーポレイティド 部分的複製データベースシステムのネットワーク維持方法
JP2000347909A (ja) * 1999-06-07 2000-12-15 Hitachi Ltd トランザクション処理向けストレージ方法および装置、トランザクショナルストレージ
JP2001022620A (ja) * 1999-07-06 2001-01-26 Ricoh Co Ltd データベース変更処理最適化方式
JP2001344138A (ja) * 2000-05-30 2001-12-14 Ricoh Co Ltd データベースロギング方法及びデータベース回復方法
JP2001344136A (ja) * 2000-05-31 2001-12-14 Nec Corp 複写ディスク装置群管理システム及びそれに用いる複写ディスク装置群管理方法
JP2004157637A (ja) * 2002-11-05 2004-06-03 Hitachi Ltd ストレージ管理方法
JP2004199264A (ja) * 2002-12-17 2004-07-15 Hitachi Ltd データベース処理方法及びその実施装置並びにその処理プログラム

Also Published As

Publication number Publication date
JP2006119822A (ja) 2006-05-11
US20060085488A1 (en) 2006-04-20
US7421456B2 (en) 2008-09-02

Similar Documents

Publication Publication Date Title
JP4683546B2 (ja) データベースの再編成方法及びデータベース再編成システム
US7765372B2 (en) Storage controller and data management method
US8769227B2 (en) Storage controller and data management method
US9665304B2 (en) Storage system with fast snapshot tree search
US8566549B1 (en) Synchronizing performance requirements across multiple storage platforms
US7644244B2 (en) Storage system and snapshot management method
US7822939B1 (en) Data de-duplication using thin provisioning
US7596713B2 (en) Fast backup storage and fast recovery of data (FBSRD)
US7509467B2 (en) Storage controller and data management method
US6678809B1 (en) Write-ahead log in directory management for concurrent I/O access for block storage
US20070198604A1 (en) Computer system, computer system management console, and data recovery management method
KR100317691B1 (ko) 로그 구조화 목표 저장장치를 사전에 구성하여 볼륨을 효율적으로 복사하는 방법 및 장치
JP4290975B2 (ja) データベース処理方法及び装置並びにその処理プログラム及びディザスタリカバリ方法及びシステム
WO2007110931A1 (ja) 名前空間複製プログラム、名前空間複製装置、名前空間複製方法
JP2009543198A (ja) ブロック指紋を読み出し、ブロック指紋を使用してデータ重複を解消するシステム、及び方法
EP1636690B1 (en) Managing a relationship between one target volume and one source volume
US7421456B2 (en) Method and system for data processing with database reorganization for the same
US20230079621A1 (en) Garbage collection from archival of storage snapshots
US10846012B2 (en) Storage system for minimizing required storage capacity during remote volume replication pair duplication
US11875060B2 (en) Replication techniques using a replication log
US20050223180A1 (en) Accelerating the execution of I/O operations in a storage system

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20070730

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A711

Effective date: 20070730

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20070730

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20070928

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20091224

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100112

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100308

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: 20100427

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: 20100514

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130528

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4518485

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: 20130528

Year of fee payment: 3

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees