JP4813924B2 - データベース管理システム、ストレージ装置、ディザスタリカバリシステム及びデータベースのバックアップ方法 - Google Patents

データベース管理システム、ストレージ装置、ディザスタリカバリシステム及びデータベースのバックアップ方法 Download PDF

Info

Publication number
JP4813924B2
JP4813924B2 JP2006052174A JP2006052174A JP4813924B2 JP 4813924 B2 JP4813924 B2 JP 4813924B2 JP 2006052174 A JP2006052174 A JP 2006052174A JP 2006052174 A JP2006052174 A JP 2006052174A JP 4813924 B2 JP4813924 B2 JP 4813924B2
Authority
JP
Japan
Prior art keywords
database
unit
storage device
data
site
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
JP2006052174A
Other languages
English (en)
Other versions
JP2007233543A (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
Original Assignee
Hitachi Ltd
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 filed Critical Hitachi Ltd
Priority to JP2006052174A priority Critical patent/JP4813924B2/ja
Priority to US11/405,464 priority patent/US7587430B2/en
Publication of JP2007233543A publication Critical patent/JP2007233543A/ja
Application granted granted Critical
Publication of JP4813924B2 publication Critical patent/JP4813924B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

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/202—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 processing functionality is redundant
    • G06F11/2048—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 processing functionality is redundant where the redundant components share neither address space nor persistent storage
    • 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
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/80—Database-specific techniques
    • 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/99951—File or database maintenance
    • Y10S707/99952—Coherency, e.g. same view to multiple users
    • 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/99951—File or database maintenance
    • Y10S707/99952—Coherency, e.g. same view to multiple users
    • Y10S707/99953—Recoverability

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

本発明は、データのバックアップシステムの改良に関し、特に、データベースに適したバックアップシステムに関する。
近年、二つの計算機システムを用いた、データベースのバックアップシステムが広く用いられている。データベースのバックアップとは、一方の計算機システムのデータと同じデータを作成し、他方の計算機システムに保存することである。バックアップ元の計算機システムを現用システム（または正サイト）、バックアップ先の計算機システムを待機システム（または副サイト）と呼ぶ。また、待機システムに保存するデータをバックアップデータと呼ぶ。二重化システムによるデータベースバックアップの方法として、ログ転送方法が知られている（例えば、非特許文献１）。
ログ転送方法とは、現用システムのデータ更新記録（ログ）を待機システムに転送し、待機システムでバックアップデータを作成する方法である。このログ転送方法では、バックアップ開始の段階で、現用システムのデータと待機システムのバックアップデータを同一にする。バックアップの開始後は、現用システムのデータ更新記録を待機システムに転送する。待機システムでは、転送されたデータ更新記録をもとにバックアップデータを更新し、最新のバックアップデータを作成する。
一般に、計算機システムはストレージ装置を含み、計算機システムのデータはストレージ装置に格納される。ストレージ装置には、二つの装置の間でデータを複写する複写機能（リモートコピー）を持つものが知られている（特許文献１）。このリモートコピー機能はネットワークを介してデータを転送し、一方のストレージ装置のデータを他方のストレージ装置に複写する機能である。
近年のストレージ装置では、リモートコピーを用いたディザスタリカバリ（Disaster Recovery）システムの利用が拡大している。ディザスタリカバリシステム（以下、ＤＲシステムとする）は、運用中のサイト（正サイト）から遠隔地サイト（副サイト）にデータをリモートコピーしておき、自然災害等の障害時においてビジネスを継続することを目的としている。
上記ＤＲシステムでは、正サイトと副サイトの位置関係を数百km以上離して配置する場合もある。このようなＤＲシステムでは、正サイトと副サイトを接続するネットワークの構築及び維持のためのコストが大きくなる。特に、２つのサイト間で数百kmに及ぶ広帯域幅回線（例えば、数Gbps）を維持するには、非常に多くのコストを要する。ＤＲシステムでコスト削減を行うためには、２つのサイト間のネットワークを狭帯域幅回線（例えば、１００Mbps）で構築することが必要となる。そこで、正サイトのデータベースからログだけを副サイトへ転送し、副サイトではログ適用を実施することで正サイトのデータベースの複製を行うログ転送方法（ログベース）のＤＲシステムが知られている。ログベースのＤＲシステムでは、副サイトの計算機が、リモートコピーで転送されたログを読み込んで、読み込んだログを副サイトのデータベースに適用するログ適用部が動作する。正サイトと副サイトの間の通信は、ログの転送のみで良いため、２つのサイト間のネットワークに狭帯域幅回線を用いてＤＲシステムを実現することができる。
特開２００４−７８７４６号公報 Cristos A.Polyzois,Hector Garcia-Molina 著、「Evaluation of remote backup algorithms for transaction processing systems」、ACM transactions on Database Systems 刊、Vol.19, No.3,１９９４年９月発行、第４２３頁−第４４９頁
上記ログ転送方法を用いたＤＲシステムでは、初期セットアップ以降の通常時においては、正サイトから副サイトへのログのみの転送ですむため、狭帯域幅回線での運用することができる。しかし、現実のデータベースの運用では、正サイトのデータベースを副サイトへ転送する必要が生じる場合がある。例えば、深夜や休日などに行うバッチ処理では、計算機の処理能力への影響を考慮してログ出力を一時的に抑止した状態で正サイトのデータベースで大量更新を行うログレスパッチを行う場合がある。バッチ処理が終了した時点では、副サイトのデータベースを正サイトのデータベースへ一致させるには、正サイトのデータベースを転送する必要が生じる。また、正サイトで障害（回線障害など）が発生してＤＲシステムを一時的に停止する場合、データベースの運用を継続すると、障害が復旧した時点の正サイトのデータベースと副サイトのデータベースは、一致しない。このため、正サイトのデータベースを副サイトのデータベースへ転送して副サイトのデータベースを正サイトのデータベースに一致させる必要がある。
このように、ＤＲシステムを備えた計算機システムであっても、ログ転送方法が利用できない場合が日常的に発生する場合がある。このため、副サイトのデータベースを正サイトのデータベースに一致させる同期処理が必要になる。
正サイトと副サイトのデータベースの同期方法としては、ストレージ装置の初期コピー機能を用いる方法がある。初期コピー機能では、データベースを格納するストレージ装置のボリューム全体をシーケンシャルにコピーし、正サイトから副サイトへデータベースを転送する。この場合、大量のデータ転送が必要となるため、２つのサイト間のネットワークが狭帯域幅回線では現実的な時間で転送を完了できない、という問題がある。広帯域幅回線を用いれば、現時的な時間での転送も可能となるが、その場合は、回線コストを削減することができず、ログベースのＤＲシステムのメリットが失われてしまう。
２つのサイト間のネットワークに広帯域幅回線を用いずに同期処理を実現する方法としては、テープ搬送方法方が挙げられる。すなわち、同期化をする時に、正サイトのデータベースでテープメディアにバックアップを取得し、副サイトにトラック等で搬送する。副サイトでは、搬送されたテープからリストアを行い、その後、ログ適用を再開する。しかし、この方法ではトラック及び保守要員の手配やバックアップ、リストア処理が必要になり、輸送コストや人件費がかかる上に、処理が煩雑になるという問題点がある。
そこで本発明は、上記問題点に鑑みてなされたもので、正サイトと副サイト間のネットワークを狭帯域幅回線で構築しながらもデータベースの同期処理を現実的な時間で実現し、かつシステムの運用コストを抑制することを目的とする。
本発明は、データベースを格納するストレージ装置と、前記データベースへの参照要求または更新要求を受け付けて、前記ストレージ装置のデータベースを参照または更新するデータベース管理サーバを実行するサーバ計算機と、を備えたデータベース管理システムにおいて、前記データベース管理サーバは、前記更新要求に基づいて前記ストレージ装置のデータベースを読み込んでデータを更新する更新実行部と、前記更新を行ったデータ内の未使用領域を予め設定した文字または値で連続的に上書きする不要情報除去処理を実行する不要情報除去部と、前記データをストレージ装置へ書き込む書込部と、を備え、前記不要情報除去部は、前記更新の種別に基づいて前記不要情報除去処理が必要か否かを判定するとともに、前記不要情報除去処理が必要な場合には、前記更新の種別に応じて前記不要情報除去処理の態様を切り替える。
また、前記ストレージ装置は、ネットワークを介して前記データベースの複製を格納する第２のストレージ装置に接続され、前記ストレージ装置は、前記データベースを前記第２のストレージ装置へ転送するリモートコピー部を有し、前記ストレージ装置は、連続した値を圧縮するデータ圧縮部を備えたネットワーク装置を介して前記ネットワークに接続される。
したがって、本発明によれば、ストレージ装置のデータベースをネットワーク装置及びネットワークを介して他の計算機やストレージ装置へ転送するときには、データベースの更新を行ったデータ内の未使用領域が予め設定した文字または値で連続的に上書きされているので、ネットワーク装置で圧縮される。このため、データベースの転送に要する時間を短縮することが可能となる。例えば、正サイトと副サイト間でデータベースの転送を行う場合では、正サイトと副サイトのネットワークを狭帯域幅回線で構築しながらもデータベースの転送（例えば、同期処理）を現実的な時間で実現することが可能となる。そして、狭帯域幅回線が利用可能となることで、システムの運用コストを抑制することができる。
以下、本発明の一実施形態を添付図面に基づいて説明する。
図１は、本発明の第１の実施形態を示し、ログ転送によるディザスタリカバリシステム（以下、ＤＲシステム）の構成を示すブロック図で、正サイトから副サイト２へデータベースのバックアップを行う一例を示す。
図１は、正サイト（現用システム）１の正データベース（以下、正ＤＢ）１１９の更新差分を示すログを副サイト（待機システム）２へ送信し、副サイト２で正データベースのバックアップデータ（ＤＢ１２９）を生成するディザスタリカバリを行うバックアップシステムを示す。
正サイト（現用システム）１は正サーバ１００と正ストレージ装置１１０（正外部記憶装置）から構成される。正サーバ１００では、正ＤＢＭＳ（DataBase Management System）１０１が稼動しており、この正ＤＢＭＳ１０１（第１のＤＢＭＳ）がユーザ端末３３０等から業務を受け付け、正ＤＢ１１９（第１のデータベース）を提供する。なお、正サーバ１００は、データベース管理サーバとして機能している。
また、正サーバ１００（第１のサーバ）は、ネットワーク３１０に接続されてユーザ端末３３０や副サイトの副サーバ１３０（第２のサーバ、バックアップ計算機）及び管理端末３４０と通信する。なお、管理端末３４０は正サイト１内に配置することができる。
正ＤＢＭＳ１０１は、正サーバ１００に接続された正ストレージ装置１１０に格納される正ＤＢ１１９を管理し、ユーザ端末３３０等に業務を提供する。また、正ＤＢＭＳ１０１は、正ＤＢ１１９に更新があったときにはログを生成し、正ストレージ装置１１０のログ１１８に格納する。正ストレージ装置１１０は、通常の稼動状態ではログ１１８を副サイト２へ転送し、正ＤＢ１１９のバックアップを行う。
正ＤＢＭＳ１０１は、ユーザ端末３３０からの要求に応じて正ＤＢ１１９にアクセスするトランザクション実行部１０４と、正ＤＢ１１９の更新差分からログを生成し正ストレージ装置１１０に格納するログ管理部１０５と、正ストレージ装置１１０の正ＤＢ１１９をメモリ上に保持するＤＢバッファ１０２と、生成したログをメモリ上に保持するログバッファ１０３と、ＤＢバッファ１０２に保持された更新データを正ストレージ装置１１０の正ＤＢ１１９に書き込む遅延書込部１０６と、を備える。
さらに、正ＤＢＭＳ１０１は、正サイト１と副サイト２の同期処理を高速化するために、正ＤＢ１１９の情報の意味を意識してデータ圧縮の前処理を行う不要情報除去部４００と、正ＤＢＭＳ１０１の動作状態に応じて不要情報除去部４００を制御する構成管理部４０１とを備えている。
正ストレージ装置１１０は、ディスク装置またはディスクアレイで構成され、正ＤＢ１１９とログ１１８を格納する。そして、正ストレージ装置１１０には、正サーバ１００からの要求に応じて正ＤＢ１１９やログ１１８への読み書きを制御する制御部１１１を有する。また、制御部１１１は、ＳＡＮ（Storage Area Network）等のストレージ装置用のネットワークを介して正サイト１内の正サーバ１００に接続される。そして、制御部１１１は、データの圧縮機能を備えたネットワーク装置１４０に接続される。このネットワーク装置１４０は、狭帯域回線（例えば、１００MbpsなどのＩＰネットワーク）で構成されたＷＡＮ等のネットワーク３２０を介して副サイト２の副ストレージ装置１２０（副外部記憶装置）と通信可能となっている。
正ストレージ装置１１０の制御部１１１は、正ＤＢＭＳ１０１からの要求に応じて正ＤＢ１１９またはログ１１８へのアクセス要求等の発行や、ログ転送の制御を指令するコマンド処理部１１２と、ログ１１８が更新されると副サイト２の副ストレージ装置１２０へ更新されたログ１１８を送信（リモートコピー）するリモートコピー処理部１１３と、メモリ上にディスク装置のデータを一時的に保持するディスクキャッシュ１１６と、コマンド処理部１１２やリモートコピー処理部１１３の要求に応じて正ＤＢ１１９やログ１１８へのアクセスを実行するディスクアクセス制御部１１７と、を備える。
なお、副サイト２の副ストレージ装置１２０へのログ１１８の送信は、同期リモートコピーの他に非同期リモートコピーで行うことができる。また、正ストレージ装置１１０と正サーバ１００の接続は、ＳＡＮ等のネットワークやＩ／Ｏインターフェースなどにより接続される。
ここで、正サイト１の正サーバ１００と正ストレージ装置１１０の構成を図２に示す。図２において、正サーバ１００は、正ＤＢＭＳ１０１の機能要素（プログラムなど）やデータを格納するメモリ１１と、メモリ１１に格納された機能要素を実行するＣＰＵ１０と、正ストレージ装置１１０及びネットワーク３１０と接続するインターフェース１２と、を備える。なお、インターフェース１２は、正ストレージ装置１１０との接続がＦＣ（Fibre Channel）等のＳＡＮで、ネットワーク３１０との接続がＩＰプロトコルの場合は、独立したインターフェースで構成することができる。
図２において、正ストレージ装置１１０は、制御部１１１の機能要素（プログラムなど）やデータを格納するメモリ１４と、メモリ１４に格納された機能要素を実行するＣＰＵ１３と、正サーバ１００と接続するインターフェース１５と、ディスク装置１７と接続するインターフェース１６とを備える。なお、インターフェース１５は、ネットワーク装置１４０にも接続される。
ネットワーク装置１４０は、正ストレージ装置１１０と正サーバ１００の接続がＦＣ（Fibre Channel）等のＳＡＮで、ネットワーク３２０との接続がＩＰプロトコルの場合は、例えば、ＦＣ−ＩＰの変換機能を備えたルータなどで構成される。そして、ネットワーク装置１４０は、正ストレージ装置１１０から副サイト２へ送信するデータを圧縮するデータ圧縮部１４１を含んでいる。このデータ圧縮部１４１は、連続的な文字列を符号（シンボル）で置き代えて圧縮を行うStacker圧縮などの公知の手法を用いるものである。このデータ圧縮部１４１は、同一の文字列（データ）が連続する場合には、圧縮率を向上させることができる。また、データ圧縮部１４１は受信した圧縮データを元のデータに伸張する機能も有するものとする。
次に、副サイト２は、図１において、正サイト１からのログ１１８に基づいて副ＤＢ１２９を生成・更新するログ適用制御部１３１が稼動する副サーバ１３０と、正サイト１の正ストレージ装置１１０から送られてきたログと正ＤＢ１１９の複製である副ＤＢ１２９（第２のデータベース）を格納する副ストレージ装置１２０と、から構成される。なお、副サーバ１３０では、正サイト１のＤＢ処理を引き継ぐための、副ＤＢＭＳ１３２（第２のＤＢＭＳ）が用意されている。なお、図ではログ適用部１３１と副ＤＢＭＳ１３２は同一のサーバ１３０で稼動させているが、別のサーバで稼動させてもよい。ログ適用部１３１は軽い処理であるため、例えば、アプライアンスサーバで稼動させ、副サーバ１３０は停止させておいてもよい。
副ストレージ装置１２０は、ディスク装置またはディスクアレイで構成され、副ＤＢ１２９とログ１２８を格納する。そして、副ストレージ装置１２０には、副サーバ１３０からの要求に応じて副ＤＢ１２９やログ１２８への読み書きを制御する制御部１２１を有する。
副ストレージ装置１２０の制御部１２１は、ログ適用制御部１３１やネットワーク装置１５０からの要求に応じて副ＤＢ１２９またはログ１２８へのアクセス要求等の発行や、ログ転送の制御を指令するコマンド処理部１２２と、メモリ上にディスク装置のデータを一時的に保持するディスクキャッシュ１２６と、コマンド処理部１２２の要求に応じて副ＤＢ１２９やログ１２８へのアクセスを実行するディスクアクセス制御部１２７と、を備える。また、副ストレージ装置１２０の制御部１２１は、副サイト２が正サイト１を引き継いだときに、ログ１２８が更新されると正ストレージ装置１１０へ更新されたログ１２８を送信（リモートコピー）するリモートコピー処理部１２３を備える。
なお、コマンド処理部１２２は、正ストレージ装置１１０から同期化要求があったときには、正サイト１から受信した正ＤＢ１１９を、副サイト２の副ＤＢ１２９に書き込んで同期させる。
副ストレージ装置１２０は、正サイト１と同様にデータ圧縮機能とデータ伸張機能を備えたネットワーク装置１５０を介してネットワーク３２０に接続される。ネットワーク装置１５０は、正サイト１の正ストレージ装置１１０から受信した圧縮データを元のデータに伸張（復号）して副ストレージ装置１２０に転送する。
なお、副サイト２の副サーバ１３０、副ストレージ装置１２０、ネットワーク装置１５０は、図２で示した正サイト１の正サーバ１００、正ストレージ装置１１０、ネットワーク装置１４０を備え、副サーバ１３０、副サーバ１３０は正サイト１と同様にＣＰＵ、メモリ、インターフェース、ディスク装置を備える。
次に、図１において、正ＤＢＭＳ１０１は、ユーザ端末３３０から問い合わせ（クエリ）を受信すると、トランザクション実行部１０４は、正ＤＢ１１９から参照や更新の対象となるＤＢページを正ストレージ装置１１０から読み込んで、ＤＢバッファ１０２上にロードする。トランザクション実行部１０４は、ユーザ端末３３０からの要求が更新の場合は、ＤＢバッファ１０２上のＤＢページを更新する。更新したＤＢページは、遅延書込部１０６によって正ストレージ装置１１０に書き込まれる。なお、ＤＢページは、正ＤＢＭＳ１０１が管理するデータ（正ＤＢ１１９及び副ＤＢ１２９）の管理単位の一つであり、後述するように、複数の行データを含むデータ構造である。
遅延書込部１０６は、正ＤＢＭＳ１０１の性能を確保するため、更新されたＤＢページの書き込みを、ＤＢバッファ１０２上の更新とは非同期に行う。遅延書込部１０６は、例えば、一定時間毎にＤＢバッファ１０２の更新部分を正ストレージ装置１１０に書き込み、あるいは、ＤＢバッファ１０２のＤＢページに一定量以上の更新があったタイミングやユーザや管理者からの指示によって正ストレージ装置１１０への書き出しを実行する。また、正ＤＢ１１９の信頼性向上の観点から、ログ管理部１０５は必ず正ＤＢ１１９の更新差分をログバッファ１０３に書き込む。そして、対象となる更新がコミットされた時には、このコミットに同期して正ストレージ装置１１０のログ１１８に更新差分情報（ログ）を書き込む。
また、正ＤＢＭＳ１０１のトランザクション実行部１０４は、ＤＢバッファ１０２上でＤＢページの更新を実行する度に、不要情報除去部４００を起動する。不要情報除去部４００は、更新が行われたＤＢページについて未使用の領域(不要情報)があるかを判定し、未使用領域（不要領域）がある場合にはこの領域に予め設定した同一の文字または値を書き込んで、未使用領域をクリアする。
また、正ＤＢＭＳ１０１の構成管理部４０１は、管理者またはユーザあるいはログ管理部１０５の要求などに応じて、不要情報除去部４００の有効/無効を設定可能とする。これは、不要情報除去処理が、正ＤＢ１１９と副ＤＢ１２９の同期化処理のときにのみ必要な処理であり、それ以外の場合は、正サーバ１００の処理能力が不要情報除去処理の分だけ低下するのを防ぐため、不要情報除去部４００の機能を無効化するためである。つまり、構成管理部４０１は、ユーザ端末３３０や管理端末３４０からの指令があったときに不要情報除去部４００の機能を有効または無効に設定する。あるいは、ログ管理部１０５からログ生成機能を停止する通知を受けた場合には、構成管理部４０１は、正サーバ１００でログレスバッチ処理など正ＤＢ１１９の全体が更新される処理が実行されると判断し、不要情報除去部４００の機能を有効に設定する。あるいは、夜間や休日などにログレスバッチ処理を周期的に繰り返す場合では、構成管理部４０１が所定のバッチ処理開始時間になると、不要情報除去部４００を有効に設定し、バッチ処理終了時間になると不要情報除去部４００を無効に設定するようにしてもよい。
＜ＤＢページの概要＞
次に、ＤＢページについて説明する。図３は、正ＤＢ１１９（副ＤＢ１２９）を構成するＤＢページ２００の内部構造を示す説明図である。正ＤＢ１１９は、複数あるいは多数のＤＢページ２００で構成される。
ＤＢページ２００内には、複数の行情報２０１〜２０３が記録される。行情報は、ヘッダ２２１〜２２３とデータ部（図中２０１〜２０３からヘッダ２２１〜２２３を除いた領域）からなる。ヘッダ２２１〜２２３には行（行情報）の長さが記録されている。データ部には、文字列や値などのデータが格納されている。なお、本実施形態の行情報２０１〜２０３は、可変長の例を示している。
ひとつのＤＢページ２００には、行情報２０１〜２０３以外に、複数の制御情報、すなわち、リンク２１１〜２１３とトレイラ２３０を含む。本実施形態のＤＢページ２００では、ＤＢページ２００の領域の終端（図中右下）アドレスにトレイラ２３０が配置され、ＤＢページ２００の領域の先頭（図中左上）アドレスから行情報２０１〜２０３が格納されていく。そして、リンク２１１〜２１３はトレイラ２３０の先頭アドレスからＤＢページ２００の先頭アドレスへ向けて、順次格納されている。
リンク２１１〜２１３は、行情報２０１〜２０３と結び付けられており、リンク２１１〜２１３に格納される値としては、対応する行情報２０１〜２０３への（ＤＢページ内の）オフセット値が格納される。通常、リンク２１１〜２１３には、ＤＢページ２００の大きさからトレイラ２３０を減じた値より小さな正の整数が記録される。例えば、リンク２１１〜２１３には、ＤＢページ２００の領域の先頭アドレスからのオフセット値が設定される。行情報を削除した場合には、削除された行情報に対応するリンクには正ＤＢＭＳ１０１から見て無効な値（例えば、負の整数）が記録される。
トレイラ２３０には、ＤＢページ２００で使用しているリンクの数（行情報の数）を示す使用リンク数２３１と、ＤＢページ２００の領域に割り当て済みのリンクの数を示す割り当てリンク数２３２と、ＤＢページ２００の領域内で使用されていない領域を指し示す未使用領域オフセット２３３と、ＤＢページ２００内の行情報のいずれかひとつに更新や削除によって未使用領域となった領域の有無を示す未使用領域フラグ２４０が設定される。
割り当てリンク数２３２は、行情報２０１〜２０３のために割り当てられたリンク２１１〜２１３の数であり、使用リンク数２３１は、割り当て済みのリンクの中で有効なリンクの数を表す。そのため、例えば、行情報を削除した場合には、使用リンク数２３１が１だけ減じられる。逆に、行情報を追加した場合には、使用リンク数２３１と割り当てリンク数２３２が加算される。
未使用領域オフセット２３３は、ＤＢページ２００内の未使用領域へのオフセットであり、図３の例では、最後の行情報２０３の終端アドレスを指す。つまり、新たに、行情報を追加する際には、未使用領域オフセット２３３の位置からヘッダとデータ部を書き込むことになる。
このような構造のＤＢページ２００の行情報２０１〜２０３、ヘッダ２２１〜２２３及び制御情報は正ＤＢＭＳ１０１によって更新され、また、後述するように、不要情報除去部４００もＤＢページ２００の領域の行情報２０２と制御情報を更新する。
例えば、あるＤＢページ２００に行情報を挿入する場合は、ＤＢページ２００内の空き領域に行情報を生成し、この行情報へのポインタをリンクに記録する。行情報を参照する場合には、このリンクを参照してヘッダに記載された長さのデータを行情報として読み込む。正ＤＢＭＳ１０１はオンライン性能を確保するための設計がなされているため、削除を行う場合には、リンク領域のみ変更を行い、データ本体はそのままにしておく。
例えば、行情報を削除する場合、正ＤＢＭＳ１０１は図４に示すような処理を実行する。図４は、図３に示したＤＢページ２００の行情報２０２を削除した状態を示す説明図である。
行情報２０２を削除する場合、正ＤＢＭＳ１０１は削除対象の行情報２０２及びヘッダ２２２に対応するリンク２１２に所定の無効値（負値）を書き込む。これにより、ヘッダ２２２及び行情報２０２のオフセット値が無効となり、正ＤＢＭＳ１０１は、行情報２０２のデータにアクセスできなくなる。実際には、ヘッダ２２２及び行情報２０２はＤＢページ２００の領域内に存在するが、アドレス情報を削除することで見かけ上データを消去したものとする。
そして、正ＤＢＭＳ１０１は、行情報２０２及びヘッダ２２２の領域が未使用となったので、未使用領域フラグ２４０を「１」にセットし、このＤＢページ２００に不要な情報を含む未使用領域が発生したことを示す。なお、未使用領域フラグ２４０が「０」のときには、未使用領域（不要情報）がないことを示す。なお、不要情報とは、ＤＢページ２００の領域内で、リンク２１１〜２１３等から参照されない領域で、かつ、不連続な値や文字列が格納されている領域を示す。
一方、正ＤＢＭＳ１０１が行情報を更新する際には、行情報の長さが増加する場合がある。図５は、図３に示したＤＢページ２００の行情報２０２を更新し、行長が増大した状態を示す説明図である。
正ＤＢＭＳ１０１は、行情報２０２を更新した結果、行情報２０２の長さが増大したので、現在の行情報２０２を未使用領域として新たな未使用領域に行情報２０２を複写して更新する。行情報２０２のデータ長が増大した場合、直前の行情報２０１の終端アドレスと、直後の行情報２０３の先頭アドレスの間に、更新後の行情報２０２’及びヘッダ２２２’を格納することができなくなる。
正ＤＢＭＳ１０１は、ＤＢページ２００の未使用領域オフセット２３３の値を読み込んで、この値が示すアドレスから書き込みを行う。つまり、図示の状態では未使用領域オフセット２３３の値は、ＤＢページ２００内の最後の行情報となる行情報２０３の終端となる。そして、正ＤＢＭＳ１０１は、この最後の行情報２０３の終端アドレスから、更新後のヘッダ２２２’と行情報２０２’を書き込む。そして、正ＤＢＭＳ１０１は、行情報２０２’のヘッダ２２２’の先頭アドレスのオフセットを、新たな行情報２０３の後の値に変更してリンク２１２に書き込む。また、最後の行情報は今回更新した行情報２０２’に変更されたので、新たな未使用領域の終端となる行情報２０２’の終端のアドレスのオフセットを、未使用領域オフセット２３３に記録する。なお、行長が変更された場合のリンク操作としては以下のようにしてもよい。すなわち、旧リンク２１２は負の値を記録し、新たなリンクを割り当てた上で、該リンクには行情報２０２’のオフセットを記録する。
このように、行情報のデータ長が増大する場合も、更新前のデータはそのまま保存されてＤＢページ２００内に未使用領域が発生し、リンク２１２とポインタなどの制御情報のみが更新される。
＜データ圧縮の概要＞
上記図３〜図５で示したように、正ＤＢＭＳ１０１は、データの削除や更新を行う際には、古いデータを残して制御情報だけを書き換えることでＤＢ１１９の処理を行っていた。このようなＤＢ処理は、必要最低限の処理のみを行うため正ＤＢＭＳ１０１のオンライン性能を確保の点からは有効だが、同期処理のために副サイト２へ正ＤＢ１１９を転送する場合では、ネットワーク装置１４０における圧縮率を下げる要因となりうる。ネットワーク装置１４０のデータ圧縮部１４１では、同一の値や文字が連続していれば容易にデータの圧縮率を上げることができる。
そこで、本発明では、ＤＢページ２００内の未使用領域の内容と、ネットワーク装置１４０のデータ圧縮の特性に着目したもので、正サイト１と副サイト２の同期処理を行う前に、ＤＢページ２００内の不要情報を連続的な同一の文字や値に更新しておくものである。
図６は、本発明の概要を示す説明図である。図６において、まず図中Ｐ１のように、正サイト１の正ＤＢＭＳ１０１では、更新や削除を行う度に不要情報除去部４００が起動して、ＤＢページ２００内の未使用領域に含まれる不要な情報（ＤＢページ２００における行情報２０２）を「０」などの所定の文字または値で連続的に上書きしておく（０でクリアする）。そして、正ＤＢ１１９と副ＤＢ１２９の同期処理の際には、不要な情報をクリアした状態の正ＤＢ１１９をネットワーク装置１４０で圧縮してから副サイト２へ転送を行う（Ｐ２）。正ストレージ装置１１０から送信された正ＤＢ１１９のデータは、図６のＰ２で示すように、非圧縮であり、正ＤＢＭＳ１０１が書き込んだＤＢページ２００の内容がそのままネットワーク装置１４０に送られる。図６のＰ１で、削除された行情報２０２（図３参照）の領域は、所定の文字または値で連続的に上書きれた未使用領域２０２Ａとなる。
正ＤＢ１１９のデータは、正サイト１のネットワーク装置１４０のデータ圧縮部１４１で圧縮される（Ｐ３）。この圧縮の際には、未使用領域２０２Ａの前後の行情報２０１、行情報２０３の内容が不連続な値が多い場合には、圧縮率の向上は見られない。これに対して、図６のＰ１で所定の文字または値で連続的に上書きされた未使用領域２０２Ａは、同一の文字または値が連続するため、ネットワーク装置１４０のデータ圧縮部１４１で、大幅に圧縮することができる（Ｐ４）。
このように、未使用領域２０２Ａを大幅に圧縮した後に、ネットワーク装置１４０から狭帯域幅回線で構成されたＷＡＮなどのネットワーク３２０へ圧縮後のデータ２０１’、２０２Ａ’、２０３’が送信される。副サイト２では、ネットワーク装置１５０で受信したデータを伸張して元のデータへ復元する。そして、ネットワーク装置１５０から転送されたデータは副ストレージ装置１２０に格納され、副ＤＢ１２９は正ＤＢ１１９に同期する。
このように、本発明では、ＤＢページ２００内の未使用領域に残存する不要な情報を０クリアしてから転送を行うため、特別なハードウェアや複雑な処理を加えることなく、ネットワーク装置１４０、１５０で高い圧縮率が得られることが期待できる。これにより、正ストレージ装置１１０と副ストレージ装置１２０を接続するネットワーク３２０を狭帯域幅回線で構築しながらもデータベースの同期処理を現実的な時間で実現し、かつ複雑な処理を必要としないので、ＤＲシステムの運用コストを抑制することが可能となるのである。
＜処理の詳細＞
以下、正ＤＢＭＳ１０１の詳細な処理の一例について説明する。図７は、正ＤＢＭＳ１０１で行われるＤＢページ２００の更新処理のフローチャートを示し、ユーザ端末３３０などから要求（クエリ）を受け付ける度に実行されるものである。
図７において、正ＤＢＭＳ１０１のトランザクション実行部１０４は、受け付けたクエリを解析し、クエリプランを生成する（５００）。このクエリプラン作成により、要求された処理に必要なＤＢページ２００を特定することができる。続いて、必要なＤＢページ２００を正ストレージ装置１１０またはＤＢバッファ１０２から入力する（５０１）。
トランザクション実行部１０４は、特定されたＤＢページ２００がＤＢバッファ１０２上にあれば、ＤＢバッファ１０２から該当するＤＢページ２００を入力し、ＤＢバッファ１０２に特定したＤＢページ２００がなければ、正ストレージ装置１１０からＤＢバッファ１０２へ読み込んで、トランザクション実行部１０４に入力する。
次に、構成管理部４０１において、不要情報除去部４００が有効になっているか否かを判定する（５０２）。不要情報除去部４００が無効であれば、トランザクション実行部１０４は、ＤＢページ２００を更新する（５０３）。
一方、不要情報除去部４００が有効であるならば、トランザクション実行部１０４は、該ＤＢページ２００に関して、未使用領域の不要情報除去処理が必要かどうかを判定する（５０４）。すなわち、上記ステップ５００で解析したクエリの種別が、行情報の削除、あるいは、リンクの張替えを伴うもの（上記図５の行長の増加）であるか否かを判定する。判定の結果、不要情報除去処理が不要であれば、トランザクション実行部１０４は、ＤＢページ２００の更新を行う。一方、不要情報除去処理が必要であれば、ＤＢページ２００の更新を行った後に、不要情報除去部４００を呼び出す（５０６，５０７）。
次に、図８は上記図７のステップ５０７で呼び出される不要情報除去部４００で行われる処理の一例を示すフローチャートである。
不要情報除去部４００は、最初に、ＤＢページ２００に対する更新の種別を判定する（６０２）。ＤＢページ２００に対する更新の種別が削除であればステップ６０８へ進み、更新の種別が削除以外であればステップ６０３に進む。
更新の種別が削除の場合は、削除対象の行情報（例えば、図４のＤＢページ２００内の行情報２０２）の全領域（ヘッダ２２２を含む）を所定の文字（または値）「０」で連続して上書きする（６０８）。所定の文字（または、値）を書き込む領域（未使用領域）は、図３で示したように削除対象のリンクが指し示すアドレスを未使用領域の先頭アドレスとし、この先頭アドレスにヘッダ２２１の値を加えたアドレスを未使用領域の終端アドレスとする。そして、未使用領域の先頭アドレスから終端アドレスまで連続的に同一の文字または値を上書きする。例えば、図４のように、行情報２０２を削除するときには、リンク２１２が指し示すアドレスからヘッダ２２２の値を加えたアドレスまでが未使用領域となる。なお、この時点では、リンク２１１は更新されていないのでヘッダ２２２を参照できる。
続いて、対応するリンク（例えば、図４のリンク２１２）の値を所定の無効な値である負値に更新する（６０８）。そして、不要情報除去部４００は、トレイラ２３０の使用リンク数２３１の値を１だけ減じて処理を終了する。
次に、ＤＢページ２００に対する更新の種別が削除でない場合、すなわち、リンクの張替えが行われる場合はステップ６０３に進む。ここで、リンクの張替えとしては、上記図５の行情報２０２’のように、例えば、行情報のサイズ変更に伴って、更新後の行情報を別領域へコピーする場合などである。リンクの張り替えの場合は、更新後の行情報のコピー先となるオフセット値を計算する（６０４）。例えば、同一ページ内であるならば、未使用領域オフセット２３３を用いればよい。
続いて、不要情報除去部４００は、上記演算で求めたオフセット値以下のアドレスに更新後の行情報をコピーする（６０４）。次に、更新前の行情報の全領域を所定の文字（または値）「０」で連続して上書きする（６０５）。さらに、不要情報除去部４００は、更新前の行情報に対応するリンクの値を、上記ステップ６０３で求めたオフセット値に置き換える（６０６）。なお、未使用領域オフセット２３３の値は、更新後の行情報の終端アドレスを指し示すように変更して処理を終了する。
以上の処理により、削除やリンクの張り替えが発生すると、ＤＢバッファ１０２に読み込まれたＤＢページ２００は、不要情報除去部４００が未使用領域を所定の値で連続的に上書きして、不要情報をクリアする。この後、遅延書込部１０６がＤＢバッファ１０２のＤＢページ２００を正ＤＢ１１９に当該ＤＢページ２００を書き出す。
夜間のログレスバッチ処理の完了した後や、回線障害などで正サイト１のリモートコピーを一旦停止した後に、リモートコピーを再開するときなど、正ＤＢＭＳ１０１が同期処理を実行する。
この同期処理は、正ＤＢＭＳ１０１が正ストレージ装置１１０へ正ＤＢ１１９を副サイト２へ転送するように指令することで開始される。正ストレージ装置１１０は、正ＤＢ１１９の内容をネットワーク装置１４０からネットワーク３２０を介して副ストレージ装置１２０へ転送する。
ネットワーク装置１４０は、図６で示したように、データ圧縮部１４１が連続した値を効率よく圧縮することができるので、０クリアされたＤＢページ２００の未使用領域２０２Ａは極めて高い圧縮率となって、正ＤＢ１１９の実質的な転送量を大幅に削減できる。したがって、正ストレージ装置１１０と副ストレージ装置１２０を接続するネットワーク３２０を狭帯域回線で構成しても、転送する正ＤＢ１１９の容量を極めて小さくできるので、前記従来例に比して短時間で同期処理を完了することができるのである。例えば、深夜にログレスバッチ処理を開始して早朝に終了した場合、早朝から業務開始時刻までの間に正ＤＢ１１９と副ＤＢ１２９の同期処理を完了することができるのである。
このように、本発明では特別なハードウェアを追加することなく、かつ、管理者などの労力も必要とせずに、低コストなネットワーク３２０を利用しながら同期処理を行うことができるので、ＤＲシステムの運用コストを抑制できるのである。
なお、上記不要情報除去部４００の有効または無効を管理端末３４０等で設定する場合には、構成管理部４０１が管理端末３４０へ図９で示すような設定画面（ユーザーインターフェース）７００を提供しても良い。図９は管理端末３４０の表示画面の一例を示す説明図である。
図９において、不要情報除去部４００の有効または無効の設定は、例えば、チェックボックス７０１を用いて行う。このチェックボックス７０１をクリックなどにより選択し、図中「ＯＫ」ボタンをクリックすることで、構成管理部４０１は不要情報除去部４００を有効にする。逆に、チェックボックス７０１の選択を解除すれば、構成管理部４０１は不要情報除去部４００を無効にする。
なお、図９のユーザーインターフェースでは、不要情報除去部４００の有効にした場合に、正ＤＢＭＳ１０１の処理能力に影響が生じる可能性があることを示す表示部７０２を設けても良い。このようなユーザーインターフェース７００により、ＤＢ同期化時等に管理者が不要情報除去処理を有効にすることが可能となる。
＜第２実施形態＞
図１０は、第２の実施形態を示し、正サイト１の正ＤＢＭＳ１０１及び正ストレージ装置１１０のブロック図である。本第２実施形態は、前記第１実施形態の不要情報除去部４００を遅延書込部１０６が正ＤＢ１１９へＤＢページ２００を書き出すときに機能する用にしたものであり、その他の構成は前記第１実施形態と同様である。
不要情報除去部４００は、前記第１実施形態のトランザクション実行部１０４に代わって、遅延書込部１０６から呼び出される。なお、不要情報除去部４００の有効または無効の設定は前記第１実施形態と同様に構成管理部４０１が管理する。
遅延書込部１０６は、ＤＢバッファ１０２上のダーティページ（ＤＢバッファ１０２の書き戻し対象ページ）を正ストレージ装置１１０へ出力するタイミングを一定時間経過後や一定の更新量があった時などに設定する。
そして、遅延書込部１０６がＤＢバッファ１０２上のＤＢページ２００を正ストレージ装置１１０の正ＤＢ１１９へ書き出すときには、不要情報除去部４００が呼び出される。
不要情報除去部４００は、ＤＢバッファ１０２から書き戻し対象ページ内を解析し、ＤＢページ２００内部の未使用領域（不要情報）を所定の文字（または値）「０」で上書きした後に、正ストレージ装置１１０への出力を行う。遅延書込部１０６から不要情報除去部４００を呼び出す場合には、ＤＢページ２００の同一領域に繰り返し更新が行われる場合でも、正ストレージ装置１１０へＤＢページ２００を書き出すときに１度だけ不要情報除去部４００を呼び出せばよい。このため、同一のＤＢページ２００に複数回の更新が発生する場合でも、このＤＢページ２００に対する不要情報除去部４００の呼び出し回数を削減でき、正ＤＢＭＳ１０１の処理性能への影響を最小限減にすることができる。
前記第１実施形態のように、不要情報除去部４００をトランザクション実行部１０４から呼び出す場合には、ＤＢページ２００の更新の度に不要情報除去部４００が呼び出されてしまう。これに対して、本第２実施形態では、不要情報除去部４００は遅延書込部１０６がＤＢバッファ１０２からＤＢページ２００を正ストレージ装置１１０へ書き出すときにのみ不要情報除去部４００を呼び出すため、正ＤＢＭＳ１０１のオンライン性能への影響を抑制することができる。
遅延書込部１０６から不要情報除去部４００を呼び出す場合、未使用領域の有無（不要情報）を判定するには、全てのリンクをチェックする方法が考えられる。しかし、ＤＢページ２００の更新時には、トランザクション実行部１０４では更新の種別が分かっているため、更新の結果により未使用領域が生成されるかを判断することができる。したがって、更新時にはトランザクション実行部１０４が、ＤＢページ２００に未使用領域の有無を表す未使用領域フラグ２４０を設定する。つまり、ＤＢページ２００を新規に作る場合、あるいは、新たにＤＢページ２００をＤＢバッファ１０２へ読み込むときには、トランザクション実行部１０４がＤＢページ２００のトレイラ２３０中の未使用領域フラグ２４０を「０」に設定する。そして、トランザクション実行部１０４は、ＤＢページ２００に対して未使用領域が発生する更新を行った場合にのみ、未使用領域フラグ２４０を１にセットする。この未使用領域フラグ２４０が「０」の場合は未使用領域が無いことが分かり、個々のリンク解析が不要となるため、正ＤＢＭＳ１０１のオンライン性能への影響をさらに削減することが可能となる。
次に、正ＤＢＭＳ１０１で行われる処理の一例について説明する。図１１は、正ＤＢＭＳ１０１で行われるＤＢページ２００の更新処理のフローチャートを示し、ユーザ端末３３０などから要求（クエリ）を受け付ける度に実行されるものである。
ステップ５００、５０１では、前記第１実施形態の図７と同様に、正ＤＢＭＳ１０１のトランザクション実行部１０４は、受け付けたクエリを解析し、クエリプランを生成する（５００）。そして作成したクエリプランにより、要求された処理に必要なＤＢページ２００を特定し、必要なＤＢページ２００を正ストレージ装置１１０またはＤＢバッファ１０２から入力する（５０１）。
次に、ステップ５０２も前記第１実施形態の図７と同様に、トランザクション実行部１０４は、構成管理部４０１において、不要情報除去部４００が有効になっているか否かを判定し、不要情報除去部４００が無効であれば、トランザクション実行部１０４は、ＤＢページ２００を更新し（５０３）、不要情報除去部４００が有効であれば未使用領域の不要情報除去処理が必要かどうかを判定する（５０４）。
ステップ５０４も前記第１実施形態の図７と同様に、クエリの種別が行情報の削除、あるいは、リンクの張替えを伴うものであるか否かを判定し、不要情報除去処理が不要であれば、トランザクション実行部１０４は、ＤＢページ２００の更新を行う（５０５）。
一方、不要情報除去処理が必要と判定したときには、トランザクション実行部１０４がＤＢページ２００のトレイラ２３０中の未使用領域フラグ２４０を「１」にセットする（９００）。そして、トランザクション実行部１０４は、ＤＢページ２００の更新を行う（５０６）。
トランザクション実行部１０４では、上記の処理をユーザ端末３３０等からクエリを受け付ける度に実行し、ＤＢバッファ１０２上のＤＢページ２００に対して更新（あるいは参照）を実行し、更新の際に未使用領域が発生すると未使用領域フラグ２４０をセットしておく。つまり、本第２実施形態の場合、トランザクション実行部１０４は、未使用領域フラグ２４０をセットする点が従来例とは異なる。
次に、遅延書込部１０６で行われる処理の一例を、図１２に示す。図１２の処理は、遅延書込部１０６が所定のタイミングで実行するもので、例えば、一定時間毎にＤＢバッファ１０２の更新部分を正ストレージ装置１１０に書き込み、あるいは、ＤＢバッファ１０２のＤＢページに一定量以上の更新があったタイミングやユーザや管理者からの指示によって正ストレージ装置１１０への書き出しを実行する。
遅延書込部１０６は、まず、デステージ（正ストレージ装置１１０へ書き出す）すべきダーティページ（更新済みのＤＢページ２００）を予め設定した条件により特定する（１０００）。この条件としては、例えば、ダーティページの全てをデステージの対象とする場合と、予め与えられた比率に基づいてダーティページの一部のみをデーステージする場合がある。
次に、不要情報除去部４００が有効となっているかを構成管理部４０１に問い合わせて確認する（１００１）。不要情報除去部４００が無効の場合では、遅延書込部１０６は通常通り、対象となるＤＢページ２００を全てデステージする（１００２）。
一方、不要情報除去部４００が有効になっている場合は、最初に全てのＤＢページ２００がデステージ済みであるか否かを判定する（１００３，１００４）。デステージ対象のＤＢページ２００がなければ処理を終了する（１００７）。デステージの対象となるＤＢページ２００がＤＢバッファ１０２上にある場合（デステージが未了のＤＢページ２００）には、遅延書込部１０６が該ＤＢページ２００の解析を行う（１００５）。
ＤＢページ２００の解析は、遅延書込部１０６が対象のＤＢページ２００のトレイラ２３０中の未使用領域フラグ２４０を読み込んで、このフラグの値によってステップ１００６で未使用領域の有無を判定する。
ステップ１００６では、未使用領域フラグ２４０が「１」であれば未使用領域があると判定してステップ１００９へ進み、「０」であれば未使用領域が無いと判定してステップ１００７へ進む。
未使用領域が無いと判定されたステップ１００７では、対象のＤＢページ２００についてそのままデステージを行った後、ステップＳ１へ戻る（１００８）。
一方、未使用領域がある場合のステップ１００９では、不要情報除去部４００を呼び出して対象のＤＢページ２００内の未使用領域に所定の文字（例えば、「０」）を連続的に書き込む。このステップ１００９の処理は、前記第１実施形態の図８と同様であり、図８のステップ６０２の判定は、不要情報除去部４００がリンク内に所定の無効値（例えば、負値）があれば、更新種別が削除であると判定すればよい。
そして、不要情報除去処理が完了すると対象のＤＢページ２００をデステージし（１０１０）、ステップＳ１へ戻る（１０１１）。
以上のように、不要情報除去部４００が有効の場合には、遅延書込部１０６がＤＢページ２００内のトレイラ２３０中の未使用領域フラグ２４０を読み込んで、ＤＢページ２００毎に未使用領域の有無を判定する。そして、未使用領域があれば所定の文字または値を連続的に書き込んで、同期化時の前処理を行う。これらの処理を、デステージの対象となる全てのＤＢページ２００について実施した後に処理を完了する。
このように、本第２実施形態では、遅延書込部１０６が機能するときに不要情報除去部４００を呼び出すようにしたので、未使用領域のあるＤＢページ２００について更新の度に不要情報除去処理を行う必要が無くなって、正サーバ１００の負荷を低減できる。これにより、サーバ１００の処理能力を正ＤＢＭＳ１０１の処理に割り当てることで、トランザクション処理性能の低下を抑制できる。
なお、上記においては遅延書込部１０６が、ステップ１００５のＤＢページ２００の解析を行う例を示したが、不要情報除去部４００がステップ１００５の処理を行うようにしても良い。
＜第３実施形態＞
図１３は、第３の実施形態を示し、前記第２実施形態の図１２で示したＤＢページ２００の解析処理（１００５）と不要情報除去処理（１００９）をリンク２１１〜２１３（図３参照）を解析して行うようにしたもので、その他の構成は前記第２実施形態と同様である。
前記第２実施形態では、遅延書込部１０６がＤＢページ２００の未使用領域の有無の判定を未使用領域フラグ２４０の値に基づいて行ったが、本第３実施形態は、ＤＢページ２００の未使用領域フラグ２４０を用いない場合（または、ＤＢページ２００に未使用領域フラグ２４０がない場合）を示す。
図１３は、図１２のステップ１００５、１００６，１００９の処理を、ＤＢページ２００のリンク２１１〜２１３に基づいて遅延書込部１０６と不要情報除去部４００が行う場合のフローチャートを示す。
最初にステップ２３０２において、遅延書込部１０６は、対象のＤＢページ２００内の全てのリンク２１１〜２１３を解析したかを否かを判定する（２３０２）。全てのリンク２１１〜２１３の解析が完了していれば処理を終了し（２３０６）、解析が未了のリンク２１１〜２１３があればステップ２３０３へ進む。
ステップ２３０３では、解析が未了のリンク２１１〜２１３があれば、遅延書込部１０６は該リンクを解析する。
続いて、ステップ２３０４では、リンク２１１〜２１３が指し示す領域（図３の行情報２０１〜２０３及びヘッダ２２１〜２２３）が未使用領域（不要情報）であるかを判定する。リンク先の領域が未使用領域であるか否かの判定は、例えば、リンク２１１〜２１３に記録されている値で判定することができる。例えば、リンクの値が所定の無効値（例えば、負の整数）であれば、未使用領域であると判定すればよい。上記図４で示したように、行情報２０２及びヘッダ２２２を削除した場合には、この行情報２０１及びヘッダ２２１が格納された先頭アドレスを指し示すリンク２１２は所定の負値が設定されている。
あるいは、ＤＢページ２００内の割り当てリンク数２３２（図３参照）と使用リンク数２３１を比較し、割り当てリンク数２３２よりも使用リンク数２３１が小さければ、未使用領域があると判定しても良い。
リンク先が未使用領域（不要情報）であると判定した場合にはステップ２３０６へ進み、未使用領域ではないと判定したときにはＳ２３０５からステップＳ１へ戻る。
ステップ２３０６では、図６で示したように、不要情報除去部４００が、未使用領域を所定の文字（例えば、「０」）で連続して上書きする。
この上書きを実施する未使用領域の位置は、例えば、図６の例では、負値となっているリンク２１２の前後の有効なリンク２１１及びリンク２１３から求めることができる。すなわち、負値となっているリンク２１２の前方のリンク２１１から未使用領域の先頭アドレスを求め、負値となっているリンク２１２の後方のリンク２１３から未使用領域の終端アドレスを求めることができる。つまり、負値となっているリンク２１２の前方のリンク２１１からヘッダ２２１の値を参照し、リンク２１１が指し示すアドレスにヘッダ２２１の値を加算したものが行情報２０１の終端アドレスとなる。そして、この終端アドレスに１を加えたものが未使用領域の開始アドレスとなる。一方、負値となっているリンク２１２の後方のリンク２１３が指し示すアドレスから１を減じたものが未使用領域の終端アドレスとなる。なお、未使用となったリンクに負値を記録する時に、以前に記録されている値に−１を乗じている場合には、未使用領域は以下のように求めることも可能である。すなわち、記録されている値の絶対値を未使用領域の先頭アドレスとする。さらに、先頭アドレスから行長を求め、先頭アドレスに行長を加算したものが終端アドレスとなる。
このようにして求めた未使用領域の開始アドレスから終端アドレスまでの領域に所定の文字（または値）を連続して上書きする。これにより、未使用領域の開始ドレスから終端アドレスまでの領域は、同一の文字または値が連続的に格納されることになる。
以上の処理が完了した後に、現在のＤＢページ２００をデステージして（慈雨１２の１００７及び１０１０の処理）、全てのデステージ対象のＤＢページ２００について解析と未使用領域のクリアを行えばよい。
なお、上記では、無効なリンクがあった時に、リンク先の情報を０で上書きしたが、新たな（全体を０で上書きした）ＤＢページ２００を用意し、トレイラ２３０と有効なリンクとその行情報のみをコピーしてもよい。
＜第４実施形態＞
図１４は、第４の実施形態を示し、正サイト１の正ＤＢＭＳ１０１及び正ストレージ装置１１０のブロック図である。本第４実施形態は、前記第１実施形態の不要情報除去部と構成管理部を正ストレージ装置１１０の制御部１１１に設けたもので、その他の構成は前記第１実施形態と同様である。
正ストレージ装置１１０の制御部１１１には、正ＤＢ１１９へ書き込むＤＢページ２００中の未使用領域を所定の文字で連続的に上書きするクリアする不要情報除去部１４００と、この不要情報除去部１４００の有効、無効を設定する構成管理部１４０１が設けられる。その他の機能要素は前記第１実施形態と同様である。
不要情報除去部１４００を正ストレージ装置１１０内に設ける場合には、不要情報除去機能の有効／無効、及び、どの領域を不要情報除去の対象とするかを構成管理部１４０１で設定する。本第４実施形態では、正ＤＢ１１９の領域に対して書き込みが行われるときに、不要情報除去部１４００が起動するように構成管理部１４０１へ予め設定しておく。
コマンド処理部１１２は正ＤＢＭＳ１０１から書き込み要求を受け付けると、最初に、正ＤＢ１１９へ書き込むＤＢページ２００が不要情報除去の対象であるかを判定する。
構成管理部１４０１で設定された領域（ここでは正ＤＢ１１９）に書き込みが行われた場合には、不要情報除去部１４００が正ＤＢＭＳ１０１から受信したＤＢページ２００を解析して内部に未使用領域（不要情報）があるか否かを判定する。なお、この判定は、前記第２または第３実施形態と同様にして不要情報除去部１４００が実施する。
対象のＤＢページ２００に未使用領域があれば、不要情報除去部１４００を呼び出し、内部の未使用領域（不要情報）をクリアしてから、キャッシュ１２６に格納する。このとき、リモートコピー処理部１１３でリモートコピー機能が有効に設定されている場合には、リモートコピー処理部１１３が呼び出され、格納対象のＤＢページ２００は、副サイト２の副ストレージ装置１２０に転送される。
そして、不要情報除去部１４００がＤＢページ２００の未使用領域のクリアを完了すると、コマンド処理部１１２はキャッシュ１１６上のデータを、ディスクアクセス制御部１１７によって、正ＤＢ１１９の領域に書き込む。なお、ディスクアクセス制御部１１７は、キャッシュ１１６上の更新データの量などが所定の条件となったときや所定の周期などに応じてディスク装置の所定の領域に受け付けたデータを格納する。
図１５は、正ストレージ装置１１０の制御部１１１（コマンド処理部１１２及び不要情報除去部１４００）で行われるデータ格納処理の一例を示すフローチャートである。
制御部１１１は、まず、正ＤＢＭＳ１０１から更新要求を受け付ける（１３００）。次に、構成管理部１４０１に問い合わせを行って、不要情報除去部１４００が有効になっているかを判定する（１３０１）。また、このとき、制御部１１１は構成管理部１４０１に設定された未使用領域の監視対象となるディスク装置の領域を判定する。例えば、未使用領域の監視を行うディスク装置の領域を正ＤＢ１１９に設定しておく。
上記判定では受け付けた更新要求が、書き込み先が正ＤＢ１１９の領域で、かつ、不要情報除去部１４００が有効になっているときに、ステップ１３０２へ進んでデータ（ＤＢページ２００）の解析を行う。
一方、不要情報除去部１４００が無効の場合あるいは書き込み対象が正ＤＢ１１９以外の場合（例えば、ログの書き込み）では、キャッシュ１１６へ受け付けた更新要求のデータを書き込む（１３１５）。そしてキャッシュ１１６上のデータは、ディスクアクセス制御部１１７により、非同期でキャッシュ１１６から該当する領域（ボリューム）へ書き込みが行われる。キャッシュ１１６に格納した後には、Ｓ０へ戻って次の更新要求を受け付ける。
上記受け付けた更新要求がディスク装置の所定の対象領域に対するもので、かつ、不要情報除去部１４００が有効な場合では、ＤＢページ２００の解析を行う（１３０２）。
ステップ２３０３では、不要情報除去部１４００がＤＢページ２００を解析し、未使用領域の有無を検出する。なお、未使用領域の検出は、上記第２または第３実施形態と同様である。
ステップ１３０３では、上記解析の結果、更新要求に含まれるＤＢページ２００に未使用領域があるか否かを判定する。未使用領域があればＳ１に進んでＤＢページ２００内のリンク２１１〜２１３を検査する。一方、受け付けたＤＢページ２００に未使用領域がなければ、このＤＢページ２００をキャッシュ１１６に格納してからＳ０へ戻り、次の更新要求を受け付ける（１３０４，１３０５）
未使用領域がある場合には、ＤＢページ２００内の全てのリンク２１１〜２１３について解析を行ったか否かを判定する（１３０６，１３０７）。
ＤＢページ２００内の全リンクの解析が完了していれば、このＤＢページ２００をキャッシュ１１６へ格納してからＳ０へ戻る（１３１３，１３１４）。解析が未了のリンクがあればステップ１３０８でリンクに対応する領域が未使用領域であるか否かを解析する。なお、このリンク先が未使用領域であるか否かの解析は前記第２，第３実施形態と同様である。
そして、ステップ１３０９では、上記解析を行ったリンク２１１〜２１３が指し示す行情報２０１〜２０３が未使用領域であるか否かを判定し、未使用領域であればステップ１３１１へ進んで、未使用領域に所定の文字（または値）を連続的に上書きする（１３１１）。そして、Ｓ１へ戻ってＤＢページ２００内の全てのリンク２１１〜２１３について未使用領域の解析が終わるまで処理を繰り返す（１３１２）。
一方、解析したリンク２１１〜２１３先の領域が未使用領域でなければ、Ｓ１へ戻ってＤＢページ２００内の全てのリンク２１１〜２１３について未使用領域の解析が終わるまで処理を繰り返す（１３１０）。
以上のように、正ストレージ装置１１０でＤＢページ２００の未使用領域をクリアする場合は、正ＤＢＭＳ１０１からの更新要求を受け付ける度に、コマンド処理部１１２が不要情報除去部１４００を呼び出して、未使用領域があれば同一の文字または値を連続的に上書きし、同期化時の圧縮の前処理を実行することができる。
そして、正ストレージ装置１１０で未使用領域のクリアを実行するので、正ＤＢＭＳ１０１が稼動する正サーバ１００の処理能力が不要情報除去処理で低下するのを抑制できる。
なお、上記第４実施形態では、不要情報除去部１４００の有効または無効の設定は、正ＤＢＭＳ１０１を介して管理欄末３４０等から行えばよい。この場合、正ＤＢＭＳ１０１は、管理欄末３４０等から受信した指令を正ストレージ装置１１０のコマンド処理部１１２に送って、設定を実行させることができる。
上記不要情報除去部１４００の有効または無効を管理端末３４０等で設定する場合には、正ＤＢＭＳ１０１が管理端末３４０へ図１６で示すような設定画面（ユーザーインターフェース）１２００を提供しても良い。図１６は管理端末３４０の表示画面の一例を示す説明図である。
図１６において、不要情報除去部１４００の有効または無効の設定は、例えば、チェックボックス１２０１を用いて行う。このチェックボックス１２０１をクリックなどにより選択し、図中「ＯＫ」ボタンをクリックすることで、正ＤＢＭＳ１０１は正ストレージ装置１１０に対して不要情報除去部１４００を有効にするよう指令する。逆に、チェックボックス１２０１の選択を解除すれば、正ＤＢＭＳ１０１は正ストレージ装置１１０に対して不要情報除去部１４００を無効にするよう指令する。
なお、図１６のユーザーインターフェースでは、不要情報除去部１４００の有効にした場合に、正ストレージ装置１１０の処理能力に影響が生じる可能性があることを示す表示部１２０２を設けても良い。このようなユーザーインターフェース１２００により、ＤＢ同期化時等に管理者が不要情報除去処理を有効にすることが可能となる。
ここで、正ストレージ装置１１０の不要情報除去部１４００では、ＤＢページ２００の解析を行うが、そのためには、正ストレージ装置１１０がＤＢページ２００のフォーマットを知っている必要がある。そして、正ストレージ装置１１０のディスク装置１７内に複数のボリュームがあり、複数種のデータベースを格納可能な場合では、設定画面１２００で、チェックボックス１２０３，１２０４，１２０５のようにＤＢＭＳの種類を選択できるようにしても良い。そして、設定画面１２００からで、どのＤＢＭＳを不要情報除去処理の対象とするかを指定する。また、不要情報除去処理の対象となるディスク装置１７の領域指定も行うようにしてもよい。例えば、図１６に示すＬＵ（論理ユニット）番号やＬＵ内の論理アドレス（ＬＢＡ：Logical Block Address）を文字入力領域１２０６，１２０７，１２０８で指定できるようにする。これにより、管理欄末３４０等から不要情報除去処理を実施するＤＢＭＳの種類やディスク装置１７の領域やアドレスを詳細に設定可能となる。
図１７は、図１４に示した正サイト１と副サイト２で構成されるＤＲシステムを示すブロック図である。
図１７では、正ストレージ装置１１０内に不要情報除去部１４００を有しており、上記のように正ＤＢＭＳ１０１の更新要求に応じてＤＢページ２００の未使用領域のクリアを行う。
副サイト２は、リモートコピー機能を有する副ストレージ装置１２０とログ適用を行う副サーバ１３０からなる。ネットワーク３２０は、圧縮・伸張機能を有するネットワーク装置１４０，１５０が狭帯域回線のＷＡＮ等のネットワーク３２０を介して接続されている。
このＤＲシステムでは、平常時は、ログのみを正サイト１から副サイト２へ転送し、副サイト２では受信したログ１２８を副ＤＢ１２９に適用することで、副ＤＢ１２９を回復する。
しかし、正サイト１からログ出力がない運用を行った後に、正ＤＢ１１９と副ＤＢ１２９の同期化が必要となる場合には、構成管理部１４０１で不要情報除去部１４００を有効にした後、正ＤＢ１１９を正ストレージ装置１１０のリモートコピー処理部１１３で副サイト２へリモートコピーを行うように設定する。
このとき、正ＤＢ１１９内の未使用領域（不要情報）が０で上書きされているため、ネットワーク装置１４０での圧縮率が高まるため、狭帯域幅回線であっても現実的な時間で処理が行えるのである。
図１８は、上記図１７に示したログベースのＤＲシステムで、正ＤＢ１１９でログレズバッチ処理を実施した後、正ＤＢ１１９と副ＤＢ１２９の同期化を行う際のタイムチャートである。
正ＤＢ１１９と副ＤＢ１２９の再同期が必要となるケースとしては、ログレスバッチがある。ログレスバッチとは、正ＤＢ１１９で大量の更新を含むため、そのまま実行するとログ出力がネックとなり十分なオンライン性能が得られないことから、ログ出力を一時的に停止した上で正ＤＢ１１９の更新を実行する形態を指す。
ログベースのＤＲシステムではログ１１８を副サイト２へ転送することが前提となるため、ログ１１８が副サイト２へ転送されない期間については、正ＤＢ１１９への更新はリモートコピーで副サイト２の副ＤＢ１２９で複製する。この処理について、図１８を参照しながら以下に説明する。
まず、最初に正ＤＢＭＳ１０１で同期点を作成する（１６００）。これは、管理欄末３４０等から正ＤＢＭＳ１０１に指令を行う。同期点作成の方法としては、静止化（トランザクションを決着させると共に、ダーティページを正ストレージ装置１１０に書き出す）や正常停止が考えられる。副サイト２ではこの同期点まで適用を行った後、副サイト２におけるログ適用を停止する（１６１０）。
次に、正サイト１において、正ＤＢ１１９が副サイト２の副ＤＢ１２９へリモートコピーを行うように、リモートコピー処理部１１３の設定を変更する（１６０１）。続いて、不要情報除去部１４００を有効にする（１６０２）。
不要情報除去部１４００を機能させた状態で、ログレスバッチ処理を開始する（１６０３）。このとき、正ストレージ装置１１０のリモートコピーにより、正ＤＢ１１９の内容は副サイト２の副ＤＢ１２９へ転送される設定になっているため、ログレスバッチによる更新は副サイト２の副ＤＢ１２９に反映される。ログレスバッチ処理の終了確認後（１６０４）、再び同期点の作成を行う（１６０５）。
続いて、正サイト１で正ＤＢＭＳ１０１の副サイト２へのリモートコピーを遮断するように、リモートコピー処理部１１３の設定を変更する。副サイト２では、２回目の同期点からログ適用を開始するようログ適用制御部１３１へ管理欄末３４０等から指令する（１６１１）。最後に、正サイト１では、正ストレージ装置１１０の不要情報除去部１４００を無効に設定し、オンライン処理の受付を再開し、通常のログベースのＤＲシステムの複製処理に復帰する（１６０７）。
以上のように、ログレスバッチ処理の際には、不要情報除去部１４００を有効にさせた状態で、正ストレージ装置１１０のリモートコピーにより正ＤＢ１１９を副サイト２の副ＤＢ１２９へ転送することで、同期化を短時間で完了することができる。つまり、ログレスバッチ処理で更新を行ったＤＢページ２００は、正ストレージ装置１１０へ格納される際に未使用領域の０クリアが実施される。そして、更新されたＤＢページ２００はリモートコピーにより副サイト２の副ＤＢ１２９へ転送される。このとき、ネットワーク装置１４０では、連続した文字でクリアされた未使用領域を高圧縮率で圧縮が可能となる。このため、ネットワーク３２０で転送する正ＤＢ１１９のデータ量を大幅に低減することができるので、ログレスバッチ処理の終了からログベースのＤＲシステムへの移行を短時間で行うことができる。
また、正ストレージ装置１１０に不要情報除去部１４００を設けたので、正ＤＢＭＳ１０１を実行する正サーバ１００は、不要情報除去処理にかかる負荷を考慮する必要が無く、ログレスバッチ処理を高速に実行することができるのである。つまり、本第３実施形態の場合、更新したＤＢページ２００の読み込みと不要情報除去処理及び正ＤＢ１１９への書き込みは、正ストレージ装置１１０内で実行されるので、正ＤＢＭＳ１０１は、クエリの受付と更新ページのログの生成及び管理機能があればよい。
なお、上記図１８のログレスバッチ処理は、前記第１実施形態〜第３実施形態の構成でも同様に実行することができる。
＜第５実施形態＞
図１９は、第５の実施形態を示し、前記第２実施形態のＤＢＭＳ１０１に正ＤＢ１１９で更新した領域を差分ビットマップに記憶する差分管理部１０７と、差分管理部１０７の情報に基づいて更新されたＤＢページ２００を正ストレージ装置１１０から読み込む更新ページ入力部１０８とを付加したＤＲシステムのブロック図である。その他の構成は、前記第２実施形態と同様である。
前記第１実施形態〜第４実施形態では、ログレスバッチ処理などの正ＤＢ１１９の更新処理と並行して更新データを副サイト２の副ＤＢ１２９へ転送する場合に適した処理について説明してきた。
一方、更新が行われた正ＤＢ１１９の領域を記憶しておき、あるタイミングで一括して正ＤＢ１１９の更新差分を副サイト２の副ＤＢ１２９へ転送するログベースのＤＲシステムの一例を本第５実施形態に示す。つまり、本第５実施形態では、通常の稼働時には不要情報除去部４００を無効に設定しておき、更新されたＤＢページ２００を一括して副サイト２へ転送するときのみ不要情報除去部４００を有効にするものである。
一括して正ＤＢ１１９の更新差分を副サイト２の副ＤＢ１２９へ転送する例としては、例えば、ネットワーク３２０の回線障害により長期間ログ転送が行えなかった場合や、副サイト２のメンテナンス（例えば、副サーバ１３０の交換）のために長期間、ログ適用が行えなかった場合などがある。つまり、副サイト２で適用すべきログ１１８が転送されていなかったり、あるいは、副サイト２でログ１２８を適用する前に正サイト１で新しいログ１１８で上書きされてしまった場合には、正ＤＢ１１９と副ＤＢ１２９の同期化が必要となる。この場合、正ＤＢ１１９全体を転送するのは高コストなため、予め正ＤＢ１１９の更新領域を記憶しておく。そして、回線障害やメンテナンス終了時に正サイト１から副サイト２へ、正ＤＢ１１９の更新部分のみを一括して圧縮転送する。
正ＤＢＭＳ１０１の差分管理部１０７は、正ＤＢＭＳ１０１の差分ビットマップなどを含んでおり、ある期間内に更新が行われた領域を記憶しておく。つまり、差分管理部１０７では、正ＤＢ１１９の領域（例えば、ＤＢページ２００）に対応する差分ビットマップに、更新が行われた領域に対応するビットを設定して更新の状態を記憶する。
更新ページ入力部１０８は、正ＤＢ１１９の一括転送実施時に、差分管理部１０７が持つ差分ビットマップを元に、更新が行われたＤＢページ２００を正ストレージ装置１１０あるいはＤＢバッファ１０２から読み込む。なお、差分管理部１０７は、管理欄末３４０等から指令に応じて差分管理部１０７を有効または無効に設定することができる。あるいは、差分管理部１０７を定期的に有効にするようにしても良い。
そして、正ＤＢＭＳ１０１は、正ＤＢ１１９の一括転送を行う際には、差分管理部１０７の差分ビットマップから転送が必要な更新済みのＤＢページ２００を更新ページ入力部１０８に入力する。全ての更新済みＤＢページ２００の入力が完了したら、更新ページ入力部１０８の各ＤＢページ２００を不要情報除去部４００で未使用領域のクリアを行ってから、遅延書込部１０６により正ストレージ装置１１０に書き出す。正ストレージ装置１１０ではリモートコピーにより未使用領域のクリアを行ったＤＢページ２００を一括して副サイト２の副ストレージ装置１２０は転送し、副ＤＢ１２９を同期させるのである。
一括転送を行う例として、回線障害時の回復手順を図２０に示す。
図２０において、まず、正ＤＢＭＳ１０１では差分管理部１０７を有効にしておき、事前に差分管理を開始しておく（２２００）。続いて、正ＤＢＭＳ１０１は回線障害を検出する（２２０１）。正ＤＢＭＳ１０１は、回線障害が発生したことを副サイト２のログ適用制御部１３１に通知しておく。また、正ストレージ装置１１０のリモートコピーを停止させる。
副サイト２のログ適用制御部１３１は、正サイト１からの回線障害を受けて、ログ適用を停止する（２２２０）。ここで、正サイト１の差分管理は、定期的に実施してもよいし、チェックポイントと連携させて開始させてもよい。あるいは、回線障害を検出した時か差分管理部１０７を有効にして差分管理を開始してもよい。また、回線障害は、正サイト１と副サイト２の間でハートビードを行って検出してもよいし、キャリアと連携して実施してもよい。
正ＤＢＭＳ１０１では、回線障害中も正ＤＢ１１９に対する更新または参照を受け付ける（２２０２）。そして、差分管理部１０７の差分ビットマップには、正ＤＢ１１９のどの領域に更新が行われたかを記憶しておく。
次に、回線障害が復旧すると、正サイト１のストレージ装置１１０では、リモートコピーを再開し、ログ１１８のリモートコピーを再接続する（２２０３）。この時、回線障害が短時間であれば、再接続したリモートコピーにより更新のあったログ１１８を副サイト２へ転送し、そのままログ適用を再開すればよい。しかし、回線障害により長期間にわたってログ１１８のリモートコピーを停止した場合には、副サイト２でログ１２８の適用が完了していないログが新しいログで上書きされている可能性があり、この場合は、正ＤＢ１１９を副ＤＢ１２９へ転送する必要が生じる。
このために、正サイト１の正ＤＢＭＳ１０１では、同期点の生成とＩＯ受付（クエリ受付）中断を実施する（２２０４）。次に、正ＤＢＭＳ１０１は、差分管理を終了する（２２０５）。次に、正ＤＢ１１９へ書き込まれるＤＢページ２００が副サイト２へリモートコピーで転送されるように、正ストレージ装置１１０のリモートコピー処理部１１３の設定を変更する（２２０６）。
リモートコピーの設定変更が完了した後、正ＤＢＭＳ１０１及び正ストレージ装置１１０では、差分管理期間に更新されたＤＢページ２００（更新差分）の一括転送を行う。
すなわち、正ＤＢＭＳ１０１では、差分管理部１０７の差分ビットマップ情報を元に、正ストレージ装置１１０から更新されたＤＢページ２００のみを更新ページ入力部１０８へ入力する（２２０７）。そして、正ＤＢＭＳ１０１は更新ページ入力部１０８に読み込んだ更新差分のＤＢページ２００内部を解析し、内部の未使用領域（不要情報）をクリアした上で正ストレージ装置１１０に書き戻す（２２０８，２２０９）。
ここで、正ストレージ装置１１０の正ＤＢ１１９は、上述のようにリモートコピー設定がされているため、正ＤＢＭＳ１０１が正ストレージ装置１１０へ書き戻したＤＢページ２００（更新ページ）は、副サイト２に転送される。
差分管理部１０７の差分ビットマップに記録された全てのＤＢページ２００を転送し終えたら、正ＤＢ１１９から副サイト２の副ＤＢ１２９へのリモートコピーを切断する（２２１０）。このリモートコピーの切断を受けて、副サイト２では、ログ適用制御部１３１を起動して正ＤＢＭＳ１０１で設定した同期点（２２０４）からログ適用を開始する。最後に、正ＤＢＭＳ１０１でＩＯ受付（クエリ受付）を再開し、正ストレージ装置１１０のリモートコピー処理部１１３を正ＤＢ１１９のログ１１８を副サイト２のログ１２８へリモートコピーするように設定を変更し、通常のログベースのＤＲシステムの複製に復帰する。
なお、図２０では正ＤＢ１１９を副サイト２の副ＤＢ１２９へ転送している期間中は、ＩＯ受付（クエリ受付）を中断しているが、正サイト１の正ストレージ装置１１０でローカルミラー運用を行っておき、正ＤＢ１１９の転送時には、ローカルミラーを切断し、それぞれ更新用と転送用に分けるのであれば、正ＤＢＭＳ１０１での更新を中断する必要はない。
以上のように、回線障害でＤＲシステムを一時的に停止する場合や、ログレスバッチ処理でログを生成しない場合には、更新を行ったＤＢページ２００を差分管理部１０７で差分ビットマップに記録しておく。なお、このときの更新時には不要情報除去部４００を無効にしておく。
そして、回線障害の復旧後やログレスバッチ処理の完了後に、不要情報除去部４００を有効に設定し、差分管理部１０７内の差分ビットマップから更新を行ったＤＢページ２００を一括して読み出し、不要情報除去部４００で未使用領域のクリアを実施して正ＤＢ１１９へ書き込む。正ストレージ装置１１０では、正ＤＢ１１９を副ＤＢ１２９へ転送するようにリモートコピー処理部１１３の設定を変更しておく。これにより、回線障害やログレスバッチ処理の期間中に更新されたＤＢページ２００は未使用領域をクリアされて一括して副サイト２へ転送される。そして、前記各実施形態で述べたように、同一の文字または値で連続的に上書きされたＤＢページ２００の未使用領域はネットワーク装置１４０で高い圧縮率で圧縮されるので、狭帯域回線のネットワーク３２０を利用しても通信時間の増大を防ぐことができる。
なお、更新されたＤＢページ２００の一括転送が完了した後には、正ストレージ装置１１０のリモートコピー処理部１１３の設定を、ログ１１８が副サイト２へ転送されるように変更し、また、不要情報除去部４００を無効に設定する。これにより、ログ転送によるＤＲシステムを再開する。
さらに、正サイト１から副サイト２へは、正ＤＢ１１９のうち上記期間中に更新があったＤＢページ２００のみとなるため、正ＤＢ１１９の全てを副サイト２へ転送する場合に比して転送に要する時間を大幅に短縮することができる。
＜第６実施形態＞
図２１は、第６の実施形態を示し、前記第４実施形態のＤＢＭＳ１０１に正ＤＢ１１９で更新した領域を差分ビットマップに記憶する差分管理部１０７と、差分管理部１０７の情報に基づいて更新されたＤＢページ２００を正ストレージ装置１１０から読み込む更新ページ入力部１０８とを付加したＤＲシステムのブロック図である。その他の構成は、前記第２実施形態と同様である。
本第６実施形態では、前記第５実施形態と同様に、通常の稼働時には不要情報除去部４００を無効に設定しておき、更新されたＤＢページ２００を一括して副サイト２へ転送するときのみ不要情報除去部４００を有効にするものである。
本第６実施形態では、差分管理部１０７は前記第５実施形態と同様に、回線障害の発生期間やログレスバッチ処理の期間に更新されたＤＢページ２００を記憶する。
そして、上記回線障害の復旧後やログレスバッチ処理の完了後に、更新されたＤＢページ２００を一括して更新ページ入力部１０８へ読み込み、正ストレージ装置１１０に書き戻す。このとき、正ストレージ装置１１０の不要情報除去部１４００を有効に設定し、リモートコピー処理部１１３の設定を、書き込みのあったＤＢページ２００を副サイト２へ転送するように設定する。
更新されたＤＢページ２００の一括転送時には、前記第５実施形態と同様に、差分管理部１０７での差分管理を停止する。そして、正ＤＢＭＳ１０１が差分管理部１０７の差分ビットマップに基づいて、差分管理を実施した期間中に更新のあったＤＢページ２００のみを更新ページ入力部１０８へ読み込む。そして、正ＤＢＭＳ１０１は、更新ページ入力部１０８に読み込まれたＤＢページ２００を正ストレージ装置１１０へ書き戻す。
正ストレージ装置１１０では、正ＤＢＭＳ１０１が書き戻したＤＢページ２００について、不要情報除去部１４００が未使用領域のクリアを実施し、正ＤＢ１１９へ書き込む。リモートコピー処理部１１３は、正ＤＢ１１９へ書き戻されたＤＢページ２００を副サイト２へ転送する。
このとき、前記第５実施形態と同様に未使用領域があるＤＢページ２００は、所定の文字または値で連続的に未使用領域をクリアされているので、ネットワーク装置１４０は高い圧縮率でＤＢページ２００の圧縮を行うことができる。したがって、前記第５実施形態と同様に、狭帯域回線のネットワーク３２０を利用してもＤＢページ２００の転送に要する通信時間の増大を防ぐことができる。
＜第７実施形態＞
図２２は、第７の実施形態を示し、前記第５実施形態に示したＤＢＭＳ１０１内の差分管理部１０７を、正サーバ１００のＯＳ１１００に含まれるようにしたもので、その他の構成は、前記第５実施形態と同様である。
正サーバ１００には正ＤＢＭＳ１０１を管理するＯＳ１１００が稼動する。このＯＳ１１００には、正ストレージ装置１１０の正ＤＢ１１９の更新差分情報を管理する差分管理部１１０７が機能する。
ＯＳ１１００内部の差分管理部１１０７は、一定期間に受け付けた正ＤＢ１１９の更新領域を差分ビットマップ等に記憶しておく。正ＤＢＭＳ１０１で更新ページの一括転送を実行する際には、更新ページ入力部１０８は、差分管理部１１０７の情報に基づいて正ストレージ装置１１０から更新されたＤＢページ２００のみを入力し、遅延書込部１０６が更新ページ入力部１０８のページを正ストレージ装置１１０へ書き戻す。このとき遅延書込部１０６は不要情報除去部４００を呼び出し、ＤＢページ２００内部の未使用領域（不要情報）を０等の所定の文字または値で上書きしてから書き戻しを行う。
この一括転送時には、正ストレージ装置１１０のリモートコピー処理部１１３は、正ＤＢ１１９に書き込まれたＤＢページ２００を副サイト２へ転送するように設定しておく。
これにより、前記第５実施形態と同様に、未使用領域があるＤＢページ２００は、所定の文字または値で連続的に未使用領域をクリアされているので、ネットワーク装置１４０は高い圧縮率でＤＢページ２００の圧縮を行うことができる。したがって、前記第５実施形態と同様に、狭帯域回線のネットワーク３２０を利用してもＤＢページ２００の転送に要する通信時間の増大を防ぐことができる。
なお、図２２では、ＯＳ１１００が差分管理部１１０７を含む場合を示したが、この差分管理部を論理ボリューム（ＬＶＭ）を管理するＬＶＭ層に含めてもよい。
＜第８実施形態＞
図２３は、第８の実施形態を示し、前記第７実施形態に示したＤＢＭＳ１０１内の不要情報除去部４００及び構成管理部４０１を正ストレージ装置１１０の制御部１１１で実行するようにしたものである。
正ストレージ装置１１０の不要情報除去部１４００と構成管理部１４０１は前記第４実施形態と同様であり、不要情報除去部１４００が有効のときには、正ＤＢ１１９へ書き込むＤＢページ２００について未使用領域のクリアを実施する。
ＯＳ１１００内部の差分管理部１１０７は、一定期間に受け付けた正ＤＢ１１９の更新領域を差分ビットマップ等に記憶しておく。正ＤＢＭＳ１０１で更新ページの一括転送を実行する際には、更新ページ入力部１０８は、差分管理部１１０７の情報に基づいて正ストレージ装置１１０から更新されたＤＢページ２００のみを入力し、遅延書込部１０６が更新ページ入力部１０８のページを正ストレージ装置１１０へ書き戻す。
このとき正ストレージ装置１１０では不要情報除去部４００を有効にしておき、ＤＢページ２００内部の未使用領域（不要情報）を０等の所定の文字または値で上書きしてから正ＤＢ１１９へ書き戻しを行う。
この一括転送時には、正ストレージ装置１１０のリモートコピー処理部１１３は、正ＤＢ１１９に書き込まれたＤＢページ２００を副サイト２へ転送するように設定しておく。
これにより、前記第５実施形態と同様に、未使用領域があるＤＢページ２００は、所定の文字または値で連続的に未使用領域をクリアされているので、ネットワーク装置１４０は高い圧縮率でＤＢページ２００の圧縮を行うことができる。したがって、前記第５実施形態と同様に、狭帯域回線のネットワーク３２０を利用してもＤＢページ２００の転送に要する通信時間の増大を防ぐことができる。
＜第９実施形態＞
図２４は、第９の実施形態を示し、前記第６実施形態に示したＤＢＭＳ１０１の差分管理部１０７を、正ストレージ装置１１０の制御部１１１で実行するようにしたものである。その他の構成は、前記第６実施形態と同様である。
この場合では、正ストレージ装置１１０の制御部１１１で差分管理部１１０７が実行され、正ＤＢ１１９の更新した領域が差分ビットマップに記録される。
更新ページの一括転送の際には、まず、正ＤＢＭＳ１０１が差分管理部１１０７の差分管理を停止させる。正ＤＢＭＳ１０１は正ストレージ装置１１０に対して差分管理期間に更新されたＤＢページ２００の未使用領域のクリアを実施するように要求する。このとき、正ストレージ装置１１０の不要情報除去部１４００を有効にし、リモートコピー処理部１１３の設定を、正ＤＢ１１９への書き込みの際に副サイト２へ転送するように変更しておく。
正ストレージ装置１１０は、差分管理部１１０７の差分ビットマップに基づいて正ＤＢ１１９から更新されたＤＢページ２００のみを読み出して不要情報除去処理を実行する。不要情報除去部１４００は未使用領域をクリアしたＤＢページ２００を正ＤＢ１１９へ書き戻す。
リモートコピー処理部１１３は、不要情報除去部４００から書き込まれたＤＢページ２００について正ＤＢ１１９へ書き戻し、同時に、副サイト２へ転送する。
これにより、前記第５実施形態と同様に、未使用領域があるＤＢページ２００は、所定の文字または値で連続的に未使用領域をクリアされているので、ネットワーク装置１４０は高い圧縮率でＤＢページ２００の圧縮を行うことができる。したがって、前記第５実施形態と同様に、狭帯域回線のネットワーク３２０を利用してもＤＢページ２００の転送に要する通信時間の増大を防ぐことができる。
なお、本第９実施形態の場合、更新したＤＢページ２００の読み込みと不要情報除去処理及び正ＤＢ１１９への書き込みは、正ストレージ装置１１０内で実行されるので、正ＤＢＭＳ１０１は、クエリの受付と更新ページのログの生成及び管理機能があればよい。
以上のように、本発明によれば、正サイトと副サイトを狭帯域幅回線のネットワークで接続したログベースのディザスタリカバリシステムに適用することができる。特に、正サイトと副サイトの間で、ログレスバッチ処理の完了後や回線障害復旧後にデータベースの同期化処理を実施する場合に好適である。
本発明の第１の実施形態を示し、２つのサイトでディザスタリカバリを行う計算機システムの構成を示すブロック図。 同じく、第１の実施形態を示し、正サイトのサーバ及び正ストレージ装置の構成を示すブロック図。 同じく、第１の実施形態を示し、データベースのページの構造を示す説明図。 同じく、第１の実施形態を示し、削除が行われたときのデータベースのページの内容を示す説明図。 同じく、第１の実施形態を示し、行情報の長さが増大したときのデータベースのページの内容を示す説明図。 同じく、第１の実施形態を示し、本発明の処理の流れを示す説明図。 同じく、第１の実施形態を示し、正サイトのＤＢＭＳのトランザクション実行部で実行する処理の流れを示すフローチャート。 同じく、第１の実施形態を示し、正サイトのＤＢＭＳの不要情報除去部４００で実行する処理の流れを示すフローチャート。 同じく、第１の実施形態を示し、管理端末へ提供するユーザインターフェースの一例を示す画面イメージ。 第２の実施形態を示し、正サイトの正ＤＢＭＳ及び正ストレージ装置の構成を示すブロック図である。 同じく、第２の実施形態を示し、正サイトのＤＢＭＳのトランザクション実行部で実行する処理の一例を示すフローチャート。 同じく、第２の実施形態を示し、正サイトのＤＢＭＳの遅延書込部で実行する処理の一例を示すフローチャート。 第３の実施形態を示し、正サイトのＤＢＭＳの遅延書込部と不要情報除去部で実行する処理の一例を示すフローチャート。 第４の実施形態を示し、正サイトの正ＤＢＭＳ及び正ストレージ装置の構成を示すブロック図である。 同じく、第４の実施形態を示し、正サイトの正ストレージ装置の制御部で実行する処理の一例を示すフローチャート。 同じく、第４の実施形態を示し、管理端末へ提供するユーザインターフェースの一例を示す画面イメージ。 同じく、第４の実施形態を示し、正サイトと副サイトのディザスタリカバリシステムを示すブロック図。 同じく、第４の実施形態を示し、図１７に示したログベースのＤＲシステムで、正ＤＢＭＳでログレズバッチ処理を実施した後、正ＤＢと副ＤＢの同期化を行う際のタイムチャート。 第５の実施形態を示し、正サイトの正ＤＢＭＳ及び正ストレージ装置の構成を示すブロック図である。 同じく、第５の実施形態を示し、正サイトで差分管理を実行中に回線障害が発生し、回線障害回復後に正ＤＢと副ＤＢの同期化を行う際のタイムチャート。 第６の実施形態を示し、正サイトの正ＤＢＭＳ及び正ストレージ装置の構成を示すブロック図である。 第７の実施形態を示し、正サイトの正ＤＢＭＳ及び正ストレージ装置の構成を示すブロック図である。 第８の実施形態を示し、正サイトの正ＤＢＭＳ及び正ストレージ装置の構成を示すブロック図である。 第９の実施形態を示し、正サイトの正ＤＢＭＳ及び正ストレージ装置の構成を示すブロック図である。
符号の説明
１ 主サイト
２ 副サイト
１００ 主サーバ
１０１ 正ＤＢＭＳ
１０２ ＤＢバッファ
１０３ ログバッファ
１０４ トランザクション実行部
１０５ ログ管理部
１０６ 遅延書込部
１０７ 差分管理部
１１０ 正ストレージ装置
１１３ リモートコピー処理部
１１８ ログ
１１９ 正ＤＢ
１２０ 副ストレージ装置
１２８ 副ログ
１２９ 副ＤＢ
１３０ 副サーバ
１３１ ログ適用制御部
４００ 不要情報除去部
４０１ 構成管理部

Claims (20)

  1. データベースを格納するストレージ装置と、
    前記データベースへの参照要求または更新要求を受け付けて、前記ストレージ装置のデータベースを参照または更新するデータベース管理サーバを実行するサーバ計算機と、を備えたデータベース管理システムにおいて、
    前記データベース管理サーバは、
    前記更新要求に基づいて前記ストレージ装置のデータベースを読み込んでデータを更新する更新実行部と、
    前記更新を行ったデータ内の未使用領域を予め設定した文字または値で連続的に上書きする不要情報除去処理を実行する不要情報除去部と、
    前記データをストレージ装置へ書き込む書込部と、
    を備え、
    前記不要情報除去部は、前記更新の種別に基づいて前記不要情報除去処理が必要か否かを判定するとともに、前記不要情報除去処理が必要な場合には、前記更新の種別に応じて前記不要情報除去処理の態様を切り替えることを特徴とするデータベース管理システム。
  2. 前記不要情報除去部は、
    前記更新実行部がデータを更新する度に、更新を行ったデータ内の未使用領域を予め設定した文字または値で連続的に上書きし、
    前記書込部は、
    前記不要情報除去部で処理した前記データをストレージ装置へ書き込むことを特徴とする請求項１に記載のデータベース管理システム。
  3. 前記更新実行部は、
    前記更新要求に基づいて前記ストレージ装置のデータベースをバッファ上に読み込んでデータを更新し、
    前記書込部は、
    前記バッファ上で更新された前記データをストレージ装置へ書き込み、
    前記不要情報除去部は、
    前記書込部が、前記バッファ上で更新されたデータをストレージ装置へ書き込むときに、更新を行ったデータ内の未使用領域を予め設定した文字または値で連続的に上書きすることを特徴とする請求項１に記載のデータベース管理システム。
  4. 前記データベース管理サーバは、
    前記不要情報除去部の機能を有効または無効に設定する構成管理部を有し、
    前記構成管理部は、ネットワークを介して接続された管理計算機に対して前記不要情報除去部の機能を有効または無効に設定するインターフェースを提供することを特徴とする請求項１に記載のデータベース管理システム。
  5. 前記ストレージ装置は、ネットワークを介して前記データベースの複製を格納する第２のストレージ装置に接続され、
    前記ストレージ装置は、
    前記データベースを前記第２のストレージ装置へ転送するリモートコピー部を有し、
    前記ストレージ装置は、連続した値を圧縮するデータ圧縮部を備えたネットワーク装置を介して前記ネットワークに接続されたことを特徴とする請求項１に記載のデータベース管理システム。
  6. 前記更新実行部は、
    前記データベースから更新を行うページを特定して読み込んで、当該ページのデータを更新し、
    前記不要情報除去部は、
    前記ページ内の未使用領域について予め設定した文字または値で連続的に上書きすることを特徴とする請求項１に記載のデータベース管理システム。
  7. 前記データベース管理サーバは、
    前記更新したデータの領域を記憶する更新差分管理部と、
    前記更新差分管理部に記憶された領域のデータを前記ストレージ装置から一括して読み込む更新データ入力部と、を有し、
    前記不要情報除去部は、前記更新データ入力部に読み込まれたデータ内の未使用領域を予め設定した文字または値で連続的に上書きすることを特徴とする請求項１に記載のデータベース管理システム。
  8. 前記更新差分管理部は、
    前記更新されたデータベースの領域に対応するビットマップを備えたことを特徴とする請求項７に記載のデータベース管理システム。
  9. 前記サーバ計算機は、前記データベース管理サーバを実行するＯＳを有し、
    前記ＯＳは、
    前記更新したデータの領域を記憶する更新差分管理部を有し、
    前記データベース管理サーバは、
    前記更新差分管理部に記憶された領域のデータを前記ストレージ装置から一括して読み込む更新データ入力部と、を有し、
    前記不要情報除去部は、前記更新データ入力部に読み込まれたデータ内の未使用領域を予め設定した文字または値で連続的に上書きすることを特徴とする請求項１に記載のデータベース管理システム。
  10. データベースを格納するストレージ装置と、
    前記データベースへの参照要求または更新要求を受け付けて、前記ストレージ装置のデータベースを参照または更新するデータベース管理サーバを実行するサーバ計算機と、を備えたデータベース管理システムにおいて、
    前記データベース管理サーバは、
    前記更新要求に基づいて前記ストレージ装置のデータベースを読み込んでデータを更新する更新実行部と、
    前記更新したデータを前記ストレージ装置へ書き込む書込部と、を有し、
    前記ストレージ装置は、
    前記データベース管理サーバが書き込んだ前記データ内の未使用領域を予め設定した文字または値で連続的に上書きする不要情報除去処理を実行する不要情報除去部を、有し、
    前記不要情報除去部は、前記更新の種別に基づいて前記不要情報除去処理が必要か否かを判定するとともに、前記不要情報除去処理が必要な場合には、前記更新の種別に応じて前記不要情報除去処理の態様を切り替えることを特徴とするデータベース管理システム。
  11. 前記ストレージ装置は、
    前記不要情報除去部の機能を有効または無効に設定する構成管理部を有し、
    前記構成管理部は、ネットワークを介して接続された管理計算機に対して前記不要情報除去部の機能を有効または無効に設定するインターフェースを提供することを特徴とする請求項１０に記載のデータベース管理システム。
  12. 前記ストレージ装置は、
    前記更新したデータの領域を記憶する更新差分管理部を有し、
    前記不要情報除去部は、前記更新差分管理部に記憶された領域のデータを一括して読み込んで、データ内の未使用領域を予め設定した文字または値で連続的に上書きすることを特徴とする請求項１０に記載のデータベース管理システム。
  13. 前記更新差分管理部は、
    前記更新されたデータベースの領域に対応するビットマップを備えたことを特徴とする請求項１２に記載のデータベース管理システム。
  14. 前記サーバ計算機は、前記データベース管理サーバを実行するＯＳを有し、
    前記ＯＳは、
    前記更新したデータの領域を記憶する更新差分管理部を有し、
    前記データベース管理サーバは、
    前記不要情報除去部は、前記更新差分管理部に記憶された領域のデータを一括して読み込んで、当該データ内の未使用領域を予め設定した文字または値で連続的に上書きすることを特徴とする請求項１０に記載のデータベース管理システム。
  15. サーバ計算機によって更新されたデータが書き込まれたデータベースを格納するストレージ装置において、
    前記ストレージ装置は、
    前記サーバ計算機が書き込んだ前記データ内の未使用領域を予め設定した文字または値で連続的に上書きする不要情報除去処理を実行する不要情報除去部を、有し、
    前記不要情報除去部は、前記更新の種別に基づいて前記不要情報除去処理が必要か否かを判定するとともに、前記不要情報除去処理が必要な場合には、前記更新の種別に応じて前記不要情報除去処理の態様を切り替えることを特徴とストレージ装置。
  16. 前記ストレージ装置は、
    前記不要情報除去部の機能を有効または無効に設定する構成管理部を有し、
    前記構成管理部は、ネットワークを介して接続された管理計算機に対して前記不要情報除去部の機能を有効または無効に設定するインターフェースを提供することを特徴とする請求項１５に記載のストレージ装置。
  17. 第１のサイトと第２のサイトをネットワークを介して接続し、前記第１のサイトのデータを前記第２のサイトへ転送するディザスタリカバリシステムにおいて、
    前記第１のサイトは、
    第１のデータベースを格納する第１のストレージ装置と、
    前記第１のデータベースへの参照要求または更新要求を受け付けて、前記第１のストレージ装置の第１データベースを参照または更新する第１のデータベース管理サーバを実行する第１のサーバ計算機と、を備え、
    前記第１のデータベース管理サーバは、
    前記更新要求に基づいて前記第１のストレージ装置の第１のデータベースを読み込んでデータを更新する更新実行部と、
    前記更新を行ったデータ内の未使用領域を予め設定した文字または値で連続的に上書きする不要情報除去処理を実行する不要情報除去部と、
    前記データを第１のストレージ装置へ書き込む書込部と、
    前記第１のストレージ装置へ書き込まれた前記データを前記第２のサイトへ送信する転送部と、
    前記ネットワークに接続されて、連続した値を圧縮するデータ圧縮部を備えた第１のネットワーク装置と、を備え、
    前記不要情報除去部は、前記更新の種別に基づいて前記不要情報除去処理が必要か否かを判定するとともに、前記不要情報除去処理が必要な場合には、前記更新の種別に応じて前記不要情報除去処理の態様を切り替え、
    前記第２のサイトは、
    第１のサイトから受信したデータを伸張して、第２のストレージ装置へ転送する第２のネットワーク装置と、
    前記第１のストレージ装置から受信したデータを、前記第１のデータベースの複製として格納する第２のストレージ装置と、を備えたことを特徴とするディザスタリカバリシステム。
  18. 第１のサイトと第２のサイトをネットワークを介して接続し、前記第１のサイトのデータを前記第２のサイトへ転送するディザスタリカバリシステムにおいて、
    前記第１のサイトは、
    第１のデータベースを格納する第１のストレージ装置と、
    前記第１のデータベースへの参照要求または更新要求を受け付けて、前記第１のストレージ装置の第１データベースを参照または更新する第１のデータベース管理サーバを実行する第１のサーバ計算機と、を備え、
    前記第１のデータベース管理サーバは、
    前記更新要求に基づいて前記第１のストレージ装置の第１のデータベースを読み込んでデータを更新する更新実行部と、
    前記データを第１のストレージ装置へ書き込む書込部と、を有し、
    前記第１のストレージ装置は、
    前記第１のデータベース管理サーバから書き込まれたデータ内の未使用領域を予め設定した文字または値で連続的に上書きする不要情報除去処理を実行する不要情報除去部と、
    前記不要情報除去部で処理したデータを前記第１のデータベースへ書き込むアクセス制御部と、
    前記データを第２のサイトへ転送する転送部と、を有し、
    前記ネットワークに接続されて、連続した値を圧縮するデータ圧縮部を備えた第１のネットワーク装置と、を備え、
    前記不要情報除去部は、前記更新の種別に基づいて前記不要情報除去処理が必要か否かを判定するとともに、前記不要情報除去処理が必要な場合には、前記更新の種別に応じて前記不要情報除去処理の態様を切り替え、
    前記第２のサイトは、
    第１のサイトから受信したデータを伸張して、第２のストレージ装置へ転送する第２のネットワーク装置と、
    前記第１のストレージ装置から受信したデータを、前記第１のデータベースの複製として格納する第２のストレージ装置と、を備えたことを特徴とするディザスタリカバリシステム。
  19. 第１のデータベースを提供する第１のデータベース管理サーバと、前記第１のデータベースを格納する第１のストレージ装置を含む第１のサイトから前記第１のデータベースの更新差分を示すログのコピーを受け付けるとともに、第２のデータベースを格納する第２のストレージ装置と、前記第１のストレージ装置からコピーした前記ログに基づいて前記第２のデータベースを第２のサイトで回復するデータベースのバックアップ方法であって、
    前記ログに基づいて前記第２のデータベースを回復する処理と、
    前記第１のサイトで、前記第１のデータベースの同期点を作成する処理と、
    前記第２のサイトで、前記同期点までログを適用した後に、ログ適用を停止する処理と、
    前記第１のサイトで前記ログの送信を停止する処理と、
    前記第１のストレージ装置から第１のデータベースを第２のサイトへ送信するように切り換える処理と、
    前記第１のデータベースの更新を行う処理と、
    前記更新された第１のデータベースのデータについて、未使用領域を予め設定した文字または値で連続的に上書きする処理と、
    前記更新の種別に基づいて前記上書きする処理が必要か否かを判定するとともに、前記上書きする処理が必要な場合には、前記更新の種別に応じて前記上書きする処理の態様を切り替える処理と、
    前記上書きを行ったデータを含む第１のデータベースを前記第２のサイトへ送信する処理と、
    前記第１のサイトから送信された第１のデータベースをデータ圧縮する処理と、
    前記第１のデータベースの同期点を作成する処理と、
    前記第１のストレージ装置からログを第２のサイトへ送信するように切り換える処理と、
    前記第２のサイトで、前記同期点からログ適用を再開する処理と、
    を含むことを特徴とするデータベースのバックアップ方法。
  20. 第１のデータベースを提供する第１のデータベース管理サーバと、前記第１のデータベースを格納する第１のストレージ装置を含む第１のサイトから前記第１のデータベースの更新差分を示すログのコピーを受け付けるとともに、第２のデータベースを格納する第２のストレージ装置と、前記第１のストレージ装置からコピーした前記ログに基づいて前記第２のデータベースを第２のサイトで回復するデータベースのバックアップ方法であって、
    前記ログに基づいて前記第２のデータベースを回復する処理と、
    前記第１のサイトで、前記第１のデータベースについて更新領域の記憶を開始する処理と、
    前記第１のサイトの障害発生に基づいて、前記第２のサイトでログ適用を停止し、前記第１のサイトで前記ログの送信を停止する処理と、
    前記第１のサイトの障害回復に基づいて、第１のサイトからのログの送信を再開する処理と、
    前記第１のサイトで前記第１のデータベースの同期点を作成する処理と、
    前記第１のサイトで、前記第１のデータベースについて更新した領域の記憶を終了する処理と、
    前記第１のストレージ装置から第１のデータベースを第２のサイトへ送信するように切り換える処理と、
    前記第１のサイトで、前記記憶した第１のデータベースの更新領域を前記第１のストレージ装置から一括して抽出する処理と、
    前記更新された第１のデータベースのデータについて、未使用領域を予め設定した文字または値で連続的に上書きしてから第１のストレージ装置へ書き込む処理と、
    前記更新の種別に基づいて前記上書きする処理が必要か否かを判定するとともに、前記上書きする処理が必要な場合には、前記更新の種別に応じて前記上書きする処理の態様を切り替える処理と、
    前記第１のサイトから第２のサイトへ送信された第１のデータベースをデータ圧縮する処理と、
    前記抽出した第１のデータベースのデータの転送が完了した後に、前記第１のストレージ装置のログを第２のサイトへ送信するように切り換える処理と、
    前記第２のサイトで、前記同期点からログ適用を再開する処理と、
    を含むことを特徴とするデータベースのバックアップ方法。
JP2006052174A 2006-02-28 2006-02-28 データベース管理システム、ストレージ装置、ディザスタリカバリシステム及びデータベースのバックアップ方法 Expired - Fee Related JP4813924B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2006052174A JP4813924B2 (ja) 2006-02-28 2006-02-28 データベース管理システム、ストレージ装置、ディザスタリカバリシステム及びデータベースのバックアップ方法
US11/405,464 US7587430B2 (en) 2006-02-28 2006-04-18 Backup system for data base

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2006052174A JP4813924B2 (ja) 2006-02-28 2006-02-28 データベース管理システム、ストレージ装置、ディザスタリカバリシステム及びデータベースのバックアップ方法

Publications (2)

Publication Number Publication Date
JP2007233543A JP2007233543A (ja) 2007-09-13
JP4813924B2 true JP4813924B2 (ja) 2011-11-09

Family

ID=38445299

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006052174A Expired - Fee Related JP4813924B2 (ja) 2006-02-28 2006-02-28 データベース管理システム、ストレージ装置、ディザスタリカバリシステム及びデータベースのバックアップ方法

Country Status (2)

Country Link
US (1) US7587430B2 (ja)
JP (1) JP4813924B2 (ja)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4249719B2 (ja) * 2005-03-29 2009-04-08 株式会社日立製作所 バックアップシステム、プログラム及びバックアップ方法
JP4624376B2 (ja) * 2007-04-26 2011-02-02 株式会社損害保険ジャパン データのビジュアルキャビネットシステム及びそのシステムを利用したデータ表示方法
US11334851B1 (en) * 2007-05-18 2022-05-17 The Pnc Financial Services Group, Inc. Extending availability of business date driven applications
US20090190483A1 (en) * 2008-01-25 2009-07-30 Inventec Corporation Network transmission system and a testing method thereof
US20090234955A1 (en) * 2008-03-13 2009-09-17 Mark Gregory Hanley Methods and Systems for Synchronization of Multiple Applications
JP5365128B2 (ja) * 2008-10-03 2013-12-11 富士通株式会社 一括登録されるデータに係る情報システム、方法、およびプログラム
US8935223B2 (en) * 2009-04-30 2015-01-13 Oracle International Corporation Structure of hierarchical compressed data structure for tabular data
US8296517B2 (en) 2009-08-19 2012-10-23 Oracle International Corporation Database operation-aware striping technique
EP2290562A1 (en) * 2009-08-24 2011-03-02 Amadeus S.A.S. Segmented main-memory stored relational database table system with improved collaborative scan algorithm
JP5492103B2 (ja) * 2011-01-25 2014-05-14 株式会社日立製作所 バックアップ装置、バックアップ方法、データ圧縮方法、バックアッププログラムおよびデータ圧縮プログラム
US20130185133A1 (en) 2012-01-15 2013-07-18 Linda Tong Recommending virtual reward offers and awarding virtual rewards
US9323798B2 (en) 2013-01-14 2016-04-26 International Business Machines Corporation Storing a key value to a deleted row based on key range density
US9678673B2 (en) * 2013-03-28 2017-06-13 Hewlett Packard Enterprise Development Lp Coordinating replication of data stored in a non-volatile memory-based system
US9110847B2 (en) * 2013-06-24 2015-08-18 Sap Se N to M host system copy
US9519649B2 (en) 2013-10-07 2016-12-13 International Business Machines Corporation Free space management in a database
KR101593632B1 (ko) * 2014-09-04 2016-02-12 광운대학교 산학협력단 데이터베이스 압축 방법 및 그 장치
US10055442B2 (en) * 2014-10-31 2018-08-21 Microsoft Technology Licensing, Llc Efficient updates in non-clustered column stores
US9990308B2 (en) 2015-08-31 2018-06-05 Oracle International Corporation Selective data compression for in-memory databases

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6014674A (en) * 1996-11-14 2000-01-11 Sybase, Inc. Method for maintaining log compatibility in database systems
JPH11143747A (ja) * 1997-11-11 1999-05-28 Toshiba Tec Corp プリアロケ−ションファイルの高圧縮化方法
US6651073B1 (en) * 2000-05-23 2003-11-18 International Business Machines Corporation Method and apparatus for insuring database data integrity without data recovery logging
US6567928B1 (en) * 2000-05-23 2003-05-20 International Business Machines Corporation Method and apparatus for efficiently recovering from a failure in a database that includes unlogged objects
JP2002358222A (ja) * 2001-06-04 2002-12-13 Hitachi Ltd データ二重化システム及び方法
JP2004078476A (ja) 2002-08-14 2004-03-11 Fanuc Ltd 数値制御装置
US8121978B2 (en) * 2002-11-15 2012-02-21 Sybase, Inc. Database system providing improved methods for data replication
US7337195B2 (en) * 2002-12-31 2008-02-26 International Business Machines Corporation Method and device for establishing synchronized recovery log points
US7389308B2 (en) * 2003-05-30 2008-06-17 Microsoft Corporation Shadow paging
JP4512386B2 (ja) 2004-03-05 2010-07-28 株式会社日立製作所 バックアップシステムおよび方法
JP4581500B2 (ja) 2004-06-17 2010-11-17 株式会社日立製作所 ディザスタリカバリシステム、プログラム及びデータベースのリカバリ方法
JP4484618B2 (ja) 2004-07-30 2010-06-16 株式会社日立製作所 ディザスタリカバリシステム、プログラム及びデータの複製方法

Also Published As

Publication number Publication date
US7587430B2 (en) 2009-09-08
JP2007233543A (ja) 2007-09-13
US20070203958A1 (en) 2007-08-30

Similar Documents

Publication Publication Date Title
JP4813924B2 (ja) データベース管理システム、ストレージ装置、ディザスタリカバリシステム及びデータベースのバックアップ方法
US7225307B2 (en) Apparatus, system, and method for synchronizing an asynchronous mirror volume using a synchronous mirror volume
US7472243B2 (en) Storage system and control method thereof
US7120824B2 (en) Method, apparatus and program storage device for maintaining data consistency and cache coherency during communications failures between nodes in a remote mirror pair
US8209507B2 (en) Storage device and information management system
US7747576B2 (en) Incremental update control for remote copy
KR100643179B1 (ko) 주 시스템 및 백업 시스템 간의 데이터 복원 시스템 및 그 방법
US6728736B2 (en) System and method for synchronizing a data copy using an accumulation remote copy trio
US7587564B2 (en) System, method and computer program product for managing data versions
JP4699091B2 (ja) ディザスタリカバリ方法およびシステム
JP4993913B2 (ja) 記憶制御装置及びそのデータ管理方法
US7539703B2 (en) Setup method for disaster recovery system
US7921273B2 (en) Method, system, and article of manufacture for remote copying of data
EP1712998B1 (en) Remote copy system and remote copy method
US7844643B2 (en) Storage management system with integrated continuous data protection and remote copy
US20060195670A1 (en) Multi-site remote-copy system
US20090106400A1 (en) Remote data copying among storage systems
KR19980024086A (ko) 컴퓨터 시스템 및 화일 관리 방법
JP2006023889A (ja) リモートコピーシステム及び記憶装置システム
US7069400B2 (en) Data processing system
JP2006277208A (ja) バックアップシステム、プログラム及びバックアップ方法
JP2002149499A (ja) データの完全性を備えるリモートコピーシステム
US7260739B2 (en) Method, apparatus and program storage device for allowing continuous availability of data during volume set failures in a mirrored environment
US10846012B2 (en) Storage system for minimizing required storage capacity during remote volume replication pair duplication
JP2001318801A (ja) 二重系計算機システム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20080922

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20110530

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110607

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110729

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

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

R150 Certificate of patent or registration of utility model

Ref document number: 4813924

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

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees