JP4895437B2 - データベース管理方法およびシステム並びにその処理プログラムおよびそのプログラムを格納した記録媒体 - Google Patents
データベース管理方法およびシステム並びにその処理プログラムおよびそのプログラムを格納した記録媒体 Download PDFInfo
- Publication number
- JP4895437B2 JP4895437B2 JP2001195684A JP2001195684A JP4895437B2 JP 4895437 B2 JP4895437 B2 JP 4895437B2 JP 2001195684 A JP2001195684 A JP 2001195684A JP 2001195684 A JP2001195684 A JP 2001195684A JP 4895437 B2 JP4895437 B2 JP 4895437B2
- Authority
- JP
- Japan
- Prior art keywords
- database
- data
- area
- olap
- management
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、複数のデータベースを有するデータベース管理技術に関し、あるデータベースの情報を他のデータベースに格納するデータベース管理技術に関する。
【０００２】
【従来の技術】
高可用性のソリューションとして、データベース(DB)管理システムを２重化させ、片系がＣＰＵダウン、電源ダウンなどシステム障害の要因でデータベースシステム全体が停止するのを防ぐ目的で、ＨＡ（High Availability）システムのように多重化構成などが考えられる。例えば、文献（Jim Gray and Andreas Reuter, Tranzaction Processing: Concepts and Techniques, Morgan Kaufmann Publishers, 1993）にはＨＡシステム構成によるＤＢ障害対策としてのホットスタンバイ無停止運用について開示している。また、データベースを格納するディスク装置には、高信頼性を保証するために、ＲＡＩＤ（Redundant Array of Inexpensive Disks）構成を併用することが多い。このＲＡＩＤ構成は、文献（David A. Patterson et. al., A Case for Redundant Arrays of Inexpensive Disks(RAID), ACM SIGMOD 1988.）で詳細に開示されている。さらに、分散されたシステム間で同一の見方でデータベースをアクセスさせる機能として、レプリカＤＢがある。このレプリカＤＢ技術は、文献（Date, C.J., An Introduction to Database Systems: Volume 1 Fifth Edition, Addison-Wesley Publisher, 1990）で開示されている。
【０００３】
【発明が解決しようとする課題】
しかし、数万ユーザから同時にアクセスされるＷｅｂ環境、あるいは日々分析データが追加される数十ＴＢからなる大規模なＤＢを管理するDWHシステムにデータベース管理システムが適用される現状では、これらのデータベースシステムの運用につれて大幅に増加・変動するＤＢ量、ユーザ数、負荷量などに対応することが必須になる。予め、このようなＤＢ量、ユーザ数、負荷量の増減を加味してＤＢ設計（データ分割方法、メモリ量、プロセッサ・サーバ数、ディスク量の配置配分）を行うことも可能ではあるが、初期的にデータベースシステムを稼動させる時点では増加量を見込んだ膨大なシステムコストを考慮すると必要最小限のシステム構成でデータベースシステムを稼動せざるをえない。そのため、ＤＢ量、ユーザ数、負荷量が増減した時点で、初期時のＤＢ設計を見直し、再構築することになる。従来までは、このようなＤＢ設計方針に基き、データベースシステムの運用を止め、即ちＤＢサービスを停止させ、データ分割方法、メモリ量、プロセッサ・サーバ数、ディスク量を必要に応じて各々変更していた。
【０００４】
このＤＢサービス停止には、様々な要因が考えられる。例えば、Ｗｅｂ環境では年々増加するサービス数、Ｗｅｂブラウザなどのクライアントからのアクセス要求に対して、これらの要求を処理するために必要とされる処理能力に対応してデータベース管理システムのサーバの追加が必要になる。また、クライアントへのサービスを追加することでアプリケーションプログラムが増えることでデータベースに対する見方が多様になることで、対応する表も増え結果的にＤＢ量も年々増加する一方になる。これらのＤＢを格納するディスクの追加、データ分割方法のスキーマの変更を行うことによって、ＤＢ量の不均衡、ＤＢアクセス負荷の均衡化を図ることを考慮する必要がある。さらに、大量のＤＢ削除などの操作によるＤＢ構造の乱れにより検索効率の低下を防ぐために、ＤＢの再編成を定期的に行う必要がある。
【０００５】
これらのＤＢ運用機能は、夜間のデータベースシステム稼動停止あるいは週末のバッチ運用で行われる。ただし、Ｗｅｂ環境に代表されるようにデータベースシステムが２４時間グローバルに世界規模で利用されるようになった現在では、ＤＢ稼動停止時間やバッチ運用時間が確保できない状況がでてくる。そのため、ＤＢサービス無停止でこれらの運用を並行に実現する要求が強まっている。
【０００６】
このようなデータベース運用機能は、夜間のデータベースシステム稼動停止あるいは週末のバッチ運用で行われる。ただし、Ｗｅｂ環境に代表されるようにデータベースシステムが２４時間グローバルに世界規模で利用されるようになってくると、データベース稼動停止時間やバッチ運用時間が確保できない状況がでてくる。
【０００７】
本発明の目的は、データベースへのデータ格納をデータベースサービスと並行して処理するデータベース管理方法およびシステムを提供することにある。
【０００８】
【課題を解決するための手段】
前記課題を以下の手段により解決する。
第１のデータベースと第２のデータベースとを有するデータベース管理システムにおけるデータベース管理方法において、次のステップを有する。
（１）入力されたデータを上記第１のデータベースに格納する第１のステップ、（２）設定された条件を満たしたとき、上記第２のデータベースに登録したデータを管理する管理情報に基づいて上記第２のデータベースに登録さていないデータを上記第１のデータベースから得て、該得られたデータを上記第２のデータベースへ登録し、該得られたデータについて上記管理情報を更新する第２のステップ
このように、設定された条件により、上記第２のデータベースに登録したデータを管理する管理情報に基づいて上記第２のデータベースに登録さていないデータを上記第１のデータベースから得て、該得られたデータを上記第２のデータベースへ登録することができるため、第２のデータベースへのデータ格納を第１のデータベースサービスと並行して処理することができるようになる。
【０００９】
【発明の実施の形態】
ＤＢのサービス停止には、様々な要因が考えられる。例えば、Ｗｅｂ環境では年々増加するサービス数、Ｗｅｂブラウザなどのクライアントからのアクセス要求に対して、これらの要求を処理するために必要とされる処理能力に対応してデータベース管理システムのサーバの追加が必要になる。また、クライアントへのサービスを追加することでアプリケーションプログラムが増えることでデータベースに対する見方が多様になることで、対応する表も増え結果的にＤＢ量も年々増加する一方になる。これらのＤＢを格納するディスクの追加、データ分割方法のスキーマの変更を行うことによって、ＤＢ量の不均衡、ＤＢアクセス負荷の均衡化を図ることを考慮する必要がある。さらに、大量のＤＢ削除などの操作によるＤＢ構造の乱れにより検索効率の低下を防ぐために、ＤＢの再編成を定期的に行う必要がある。
【００１０】
これらのＤＢ運用機能は、夜間のデータベースシステム稼動停止あるいは週末のバッチ運用で行われる。ただし、Ｗｅｂ環境に代表されるようにデータベースシステムが２４時間グローバルに世界規模で利用されるようになった現在では、ＤＢ稼動停止時間やバッチ運用時間が確保できない状況がでてくる。そのため、ＤＢサービス無停止でこれらの運用を並行に実現する要求が強まっている。このＤＢサービスを停止させないで、ＤＢ運用を行うためには、次の課題を解消する必要がある。
（ｉ）接続性・拡張性
データベース処理を行うサーバとデータベースを管理するストーレジが独立に、しかも自立的にデータ管理が運用できることにより、サーバあるいはストーレジが稼動中に接続構成や各サーバ・ストーレジ追加・変更が容易になる。
（ii）データ共用
複数のサーバ間でストーレジが共用可能であることにより、フラットフォームと独立にデータ移動、変換が可能となる。
（iii）高可用性
破壊されてはならないデータを多重化あるいは離れた場所にコピーできる。
【００１１】
これらの要件を満たすのが、次世代ＩＴとして注目を浴びているＳＡＮ（Storage Area Network）ソリューションである。ＳＡＮソリューションの目指す目標は、次の４点である。
（ａ）ストーレジ入出力性能の大幅向上（Performance)
（ｂ）サーバ環境とは独立した柔軟なストーレジ環境の設定・拡張（Scalability)
（ｃ）ストーレジの一元運用(Storage Management Efficiency)
（ｄ）接続距離を飛躍的に延ばす事による災害対策(Data Protection)
特に、データベースシステムの拡張性を加味すると、上記の（ｂ）の特長活かすことが有望である。
【００１２】
ここで具体的なデータベースシステムで議論する。大手小売業販売実績管理システムでは、地域に展開している各小売店舗の時々刻々の販売履歴情報をＰＯＳ端末などにより集積されている。これらの情報は、在庫管理、発注管理、商品配送計画などと関連付けられている。また、売れ筋商品分析などの結果を、即時に店舗内商品配置に反映することも考えられる。そのために、ＲＤＢシステムに時系列順に、販売履歴コードなどからなるレコードをＤＢへ追記中心で反映することでＤＢを構築して行く。また、ここで蓄積された履歴ＤＢをソースにして、多元な分析軸で瞬時にＯＬＡＰ分析が可能なＯＬＡＰシステムを構築する。このＯＬＡＰシステムは、ＲＤＢシステムで構築された履歴ＤＢを反映する必要がある。従来技術のレプリカＤＢでは、抽出元のＲＤＢへの更新によって変更された部分を抽出し、これらを即時あるいはある時間遅れで反映先ＲＤＢへ反映される。レプリカＤＢでは、抽出元、反映先ともＲＤＢであるので、基本的には同一のデータ（一部ジョインあるいは複数の表への分類なども含まれる）の複製が作成される。ここでのＲＤＢシステムからＯＬＡＰシステムへの反映方法には、２通りが考えられる。
(a)初期作成
ＲＤＢシステムに構築された全ての履歴ＤＢをデータロードし、ＯＬＡＰシステムへ反映する
(b)追加更新
履歴ＤＢで追加更新が行われた部分を、ＯＬＡＰシステムへ追加ロードする
典型的な、販売履歴ＤＢに対するＤＢ諸元及びアクセス特性は、以下のようになる。大手小売業販売実績から推定から推定すると、７．７Ｍ件／日の販売実績があり、各実績毎に２００Ｂ〜１ＫＢ長のレコードを登録することにより、約４０ＧＢ〜２００ＧＢ／月の履歴ＤＢ規模になる。年間で約０．４ＴＢ〜２ＴＢのＤＢが追加されることになる。この履歴ＤＢは、スタースキーマを構成し、ＳＱＬの集約問合せにより統計サマリーを作成する業務で利用されことが多い。
【００１３】
また、販売履歴ＤＢをより多次元の軸で動的に分析する業務ではＯＬＡＰシステムを用い、１８〜２４ヶ月の履歴データを構築して、販売地区毎、あるいは商品毎の同月比、月別、期別などで分析を行う必要がある。さらに、約３ヶ月の履歴データに８０％以上のアクセスが集中する特徴もあり、さらにデータの鮮度をより上げるニーズが増えつつある。上記議論したが、このＲＤＢシステムとＯＬＡＰシステムのサービスを無停止で提供されなければならないことは言うまでもない。
【００１４】
ＤＢサービスを無停止で時系列、販売履歴コードなどにより追記中心の履歴ＤＢを対象にしたＯＬＡＰ分析業務をＲＤＢ業務を停止せずに構築（初期作成、追加更新）するためには、次の課題を解決する必要がある。
(1)ＲＤＢシステムで追加更新するデータベース領域とＯＬＡＰシステムへ初期作成、追加ロードするデータベース領域が重なるために、ＲＤＢシステム及びＯＬＡＰシステムでアクセスが競合するため、ＲＤＢシステム側のシステム性能が低下する。
(2)ＯＬＡＰ分析業務では、最近のデータへのアクセスの８０％が集中し、しかもＯＬＡＰシステムへの追加ロードの対象にもなるため、局所的なデータベース領域に負荷が集中する。
【００１５】
これらの課題を解消するために、次の解決方法を考える。
【００１６】
アクセスするデータベース領域が競合するため生じる課題に対しては、次の解決方法を考える。
(a)データベース格納領域を分離
ＲＤＢシステムでアクセスするデータベース領域はデータ追加と参照が主であり、ＯＬＡＰサーバへ追加ロードし反映するため読み出しのみであることに着目すれば、ディスク装置の多重化機能あるいはＯＳが提供するディスク２重書きを利用することにより、物理的にデータベース領域を複数もつことで対応する。このデータベース領域は書き込みの同期が取られていることが前提である。正Ｖｏｌ（データ追加と参照あり）と副Ｖｏｌ（指定時刻で整合性があるＤＢ）の内容が異なり、しかも物理的に隔絶することでアクセス負荷を分ける。
(b)データベース管理システムの更新履歴情報システムログの利用
データベース管理システムでは、ＤＢ障害回復のために更新履歴情報システムログを保持している。即ち、このシステムログにはデータベースシステムへの全更新情報が含まれているので、ある時点からの更新情報を抽出することが可能である。ＯＬＡＰサーバへ追加ロードし反映するためには、このシステムログから抽出した該当する履歴ＤＢ表に関するデータを作成することができる。
(c)ＯＬＡＰサーバへの反映部分を局所化する方法
データベースをキー値範囲、ハッシュ分割などにより分割する手法が行われているが、最近のデータを細分化し、かつ８０％のアクセスが集中するため並列化効果を高めるため、多段の階層分割を採用する。即ち、ＯＬＡＰサーバへ追加ロードする対象のデータは、時系列的には最近に集まる特性を持つため、時間的に近いデータを上記の分割手法を用いて分割区間として局所化する。これによって、ＲＤＢシステムの負荷を最小限にさせ、追加ロードのための読み出しが可能となる。
【００１７】
また、ＲＤＢシステムからＯＬＡＰシステムへデータを反映する場合、あるデータベースとして整合の取れた状態でＯＬＡＰ分析ができることが要求される。即ち、ある時点でのデータベースとして整合が取れたデータをＲＤＢシステムからＯＬＡＰシステムへ見せることが必要となる。この課題を解消するために、次の手段を適用する。
(a)ＲＤＢシステムのデータベースを時系列順で分割管理
時系列順で分割管理するため、追加ロードする対象のデータアクセス範囲を局所化可能である。ＲＤＢシステム側では、以前どこまでの時系列範囲をＯＬＡＰシステム側に反映したかを把握すれば、今回どの時系列範囲を追加ロードすればよいかが判定できる。
(b)システムログ情報を基にデータ反映
ＲＤＢシステムではデータベースへの更新反映情報をシステムログとして維持管理している。ＯＬＡＰシステムへ追加ロードするデータは、このシステムログ情報から該当する履歴ＤＢ表のある時点からの更新履歴を抽出すればよい。
【００１８】
上記のＳＡＮソリューションと組み合わせることにより、ＤＢ処理を行うサーバとＤＢを格納するストーレジが光ファイバなどの高速なネットワークを介して接続されるため、サーバとストーレジとの共用関係や接続に関するマッピング情報を変更するのみで動的なサーバ追加、ディスク追加などが容易に運用できる。さらに、各ストーレジはＲＡＩＤディスクを利用するため、多重化による信頼性の確保とともにＤＢ運用でワークとして必要な領域を動的なデバイスとして割当て、解除などの機能を利用することにより、通常業務を停止しないでＤＢ再編成運用ができる。具体的には、サーバ及びディスクを追加することでＤＢシステムの規模を拡大する、即ちスケーラブルなシステムが構築できる。
【００１９】
前記課題を以下の手段により解決する。
（１）ＤＢ分割管理するシステムで、新たに第１のＤＢ格納領域と第２のＤＢ格納領域を割当て、第１の格納領域の複写を第２の格納領域に反映し、複写の指示が解除されると第１の格納領域への書き込みが行われ、再複写の指示が行われると複写指示が解除された間第１の格納領域に書き込まれたデータが第２の格納領域に反映されること
（２）（１）において、複写の指示が解除される間、第２の格納領域に指定された時刻までトランザクションが完了したシステムログを第２の格納領域に反映し、第２の格納領域を読み出すこと。
（３）（１）において、ＤＢ分割管理手法として、キーレンジ分割、ハッシュ分割、ラウンドロビン分割、及びそれらを多元的に組合せる分割手段を用い、時系列でより最近のデータを細分化してデータ分割すること。
（４）（１）において、第１のＤＢ格納領域と第２のＤＢ格納領域を割当てるデータベース領域は、前回までに反映された時点以降の時系列でより最近のデータを格納するデータベース領域であること。
（５）ＤＢ分割管理するシステムで、第１のＤＢ格納領域を割当て、第１の格納領域への書き込み履歴であるシステムログから前回まで反映された時点以降の該当するデータを読み出すこと。
【００２０】
以下、本発明の実施例を図面を用いて詳細に説明する。
時系列、販売履歴コードなどにより追記中心の履歴ＤＢを対象にしたＯＬＡＰ分析業務をＲＤＢ業務を停止せずに構築（初期作成、追加更新）する。ＤＢ分割管理は、ＤＢ障害の局所化、バックアップ単位の細分化手段として適用されていたが、追記によるＤＢ量の変動、及びＯＬＡＰサーバへの反映部分を局所化する方法として適用する。
【００２１】
図ｌは、ＲＤＢシステムからＯＬＡＰシステムへデータを反映する全体構成を示してる。ＲＤＢシステムは、アプリケーションプログラム１０、１１、及びデータ抽出部２００を含むデータベース管理システム２０で構成されている。また、ＯＬＡＰシステムは、アプリケーションプログラム１１、１２、及びデータ反映部６００を含むＯＬＡＰサーバシステム６０で構成されている。ＲＤＢシステム及びＯＬＡＰシステムのデータベースは、ＳＡＮを介して接続されている。ＲＤＢシステムのデータベースは、エリアに分割されており、図３で示すようにエリア１の３００、エリア２の３０１、エリア３の３０２、エリア４の３０３、エリア５１の３０４、エリア５２の３０５、エリア５３の３０６に各々格納されている。エリア５１の３０４、エリア５２の３０５、エリア５３の３０６は、正Ｖｏｌとして格納管理されているが、ディスク２重書き機能を有する場合、エリア５１の３０７、エリア５２の３０８、エリア５３の３０９に副Ｖｏｌが格納管理される。ＯＬＡＰシステムのデータベースは、エリアに分割されており、エリア１の７００、エリア２の７０１、エリア３の７０２に格納管理される。
【００２２】
ＲＤＢシステムでデータ更新されるとデータベース管理システム２０によってデータベースへ書き込まれる。この例では、正Ｖｏｌであるエリア５１の３０４、エリア５２の３０５、エリア５３の３０６に書き込まれる。正Ｖｏｌへの書き込みは、バックグラウンドで副Ｖｏｌへ書き込みとなる。ＲＤＢシステムからＯＬＡＰシステムへのデータ反映は、データベース管理システム２０のデータ抽出部２００及びＯＬＡＰサーバシステム６０のデータ反映部６００を介して行われる。ＯＬＡＰサーバシステム６０は、ＲＤＢシステムから反映されたデータを分割スキーマに基きエリア１の７００、エリア２の７０１、エリア３の７０２に格納する。
【００２３】
図２は、データベース管理システム２０の構成図である。ユーザが作成したアプリケーションプログラム１０、１１と問合せ処理やリソース管理などのデータベースシステム全体の管理を行うデータベース管理システム２０がある。上記のデータベース管理システム２０は、システム制御２１、論理処理部２２、物理処理部２３と、データベースアクセス対象となるデータを永続的にあるいは一時的に格納するデータベース３０・ディクショナリ５０・システムログ４０からなる。また、上記データベース管理システム２０はネットワークなどを介して他のシステムと接続されている。
【００２４】
ＳＡＮ構成のシステムでは、上記データベース３０・ディクショナリ５０・システムログ４０の全体あるいは一部分がＳＡＮ８０を介してディスク装置に格納されている。この場合、ディクショナリ５０にはデータベース３０を各エリアにどのスキーマ分割手法で分割したか、あるいはエリアと正副Ｖｏｌのマッピングなどについて設定している。表定義文、表変更文などにより、このディクショナリ５０情報を更新することでデータベース管理システム、ＯＬＡＰサーバシステムなどサーバシステム側とＳＡＮを介して接続されたディスク装置内のスキーマ分割されたデータベースの格納部分となるエリアやこれらのエリアと対応付く正副Ｖｏｌなどストーレジ側とのマッピングが設定、更新される。
【００２５】
上記システム制御２１は、ユーザからの問合せ入力、問合せ結果の返却、データロード・データ再編成・再構成コマンドなど受付によるデータベース保守、他システムとの連携制御などを行う。上記論理処理部２２は、問合せの構文解析・意味解析を行う問合せ解析２２０と、適切な処理手順を生成する最適化処理２２１と、処理手順に対応したコードの生成を行うコード生成２２２とを具備している。また、上記生成されたコードに基きコードの解釈実行を行うコード解釈実行２２３を具備している。さらに、表定義コマンド、表変更コマンド、エリア−Ｖｏｌマッピング・コマンド、正副Ｖｏｌ制御コマンドなどコマンド解析実行を行うコマンド解析２２５を具備している。上記物理処理部２３は、アクセスしたデータの条件判定、編集、レコード追加などを実現するデータアクセス制御２３０と、データベースレコードの読み書きなどのアクセス制御を行うデータベースバッファ制御２３１と、システムで共用するリソースの排他制御２３２とを具備している。さらに、データベース３０の読み出し及び書き込みはデータベースバッファ２４を介して行われる。システムログ４０は、データベース３０へのデータ挿入、更新、削除などの更新履歴情報を蓄積する。ディクショナリ５０は、データベース３０の表、インデクスなどデータベース・スキーマ情報、データベース３０のデータ分割方法、格納管理する領域名称、ページサイズなどの格納情報からなる。また、データ分割方法の変更などのコマンドが実行されると、ディクショナリ５０が変更される。
【００２６】
次に、販売履歴表を時系列で分割する一実施例として、データベース分割方法としてキーレンジ分割手法を用いる。データベース分割方法には、キーレンジ分割手法以外にハッシュ分割手法、ラウンドロビン分割手法、及びこれらの手法を多元的に組合せる手法などがあり、これらを分割手法として適用することは可能である。
図３は、販売履歴表を時系列で分割して管理している。販売履歴表は、年度、半期、月毎で分割管理されている。具体的には、９７年度はエリア１の３００、９８年度はエリア２の３０１、９９年度第１四半期はエリア３の３０２、９９年度第二四半期はエリア４の３０３、９９年度７月分はエリア５１の３０４、９９年度８月分はエリア５２の３０５、９９年度９月分はエリア５３の３０６に格納されている。この場合、ディクショナリ５０には、各々キーレンジ区間とその区間に対応するエリア名が設定される。
【００２７】
例えば、このデータベース分割は次の表定義文で実行される。
また、この例では、９９年度第三四半期に対してエリアが割当てられていないが、９９年度９月分にデータ反映し終えた時点で、各々９９年度７、８、９月分に割当てられているエリア５１の３０４、エリア５２の３０５、エリア５３の３０６を併合し、エリア５として管理される。
【００２８】
図４は、９９年度９月分にデータ反映し終えた時点でのデータベース分割方法の変更を行う場合の表変更文の実行を示す。エリア５１の３０４、エリア５２の３０５の分割区間で管理されていたデータベースをエリア５３の３０６を含め、エリア５の３０７とする表変更文は次のようになる。
ALTER TABLE 販売履歴表
MERGE AREA (エリア５１,エリア５２,エリア５３)
INTO ( (エリア５) 時刻コード>='1999-09');
この表変更文によって、ディクショナリ５０には、各々キーレンジ区間とその区間に対応するエリア５１、エリア５２、エリア５３エリア名が、エリア５に変更され、設定される。
【００２９】
図５は、論理処理部２２の処理フローである。表定義文及び表変更文などのコマンド解析実行、問合せ解析、問合せ実行は、この論理処理部２２で実現される。ユーザから入力されたコマンドが、解析要求、実行要求、あるいはコマンド解析実行であるか確認される（２２５）。解析要求であれば、問合せ解析（２２０）、最適化処理（２２１）、コード生成（２２２）が行われる。また、実行要求であれば、コード解釈実行が行われる（２２３）。さらに、コマンド解析実行要求であれば、コマンド解析が行われる（２２４）。表定義コマンドであれば（２２６）、表のデータベース分割方法、各エリア名への対応付けなどをディクショナリ５０へ登録する（２２７）。表定義コマンドであれば（２２８）、表のデータベース分割方法の変更及び各エリアの追加、削除、併合、分割などに応じてディクショナリ５０へ登録する。エリア−Ｖｏｌマッピング・コマンドであれば（２３０）、各エリアに対応する正副Ｖｏｌ情報をディクシュナリ５０へ登録する。正副Ｖｏｌ制御コマンドであれば（２３２）、正副Ｖｏｌへの切り離し指示、再接続指示を該当するディスク装置へ発行する（２３３）。
【００３０】
図６は、ディスク２重書きの原理を示す。以下の説明で、ディスク２重書き機能を適用するため、ここで開示する。ディスク装置へ正副Ｖｏｌ対を設け２重に書き込む場合、ディスク２重書き機能が存在するか否かで動作が異なる。
【００３１】
ディスク２重書き機能が存在しない場合（(a)）、データベースバッファ管理２３１から正Ｖｏｌのエリア２の３０及び副Ｖｏｌのエリア２の３１に対して、各ディスク装置に書き込み要求が発行される。即ち、ソフトウェア的に２つのディスク装置上で同一のデータを常に保持することになる。
【００３２】
また、ディスク２重書き機能が存在する場合（(b)）、データベースバッファ管理２３１から正Ｖｏｌのエリア２の３０に対して書き込み要求が発行される。ディスク２重書き機能を有するディスク装置では、正Ｖｏｌのエリア２の３０と副Ｖｏｌのエリア２の３１の対応付けを指定されており、この対応付けにより正Ｖｏｌのエリア２の３０への書き込みを副Ｖｏｌのエリア２の３１の書き込みとして反映させる。即ち、ディスク装置側の機能としてハードウェア的に２つのディスク装置上で同一のデータを常に保持することになる。
【００３３】
さらに、正Ｖｏｌのエリア２の３０及び副Ｖｏｌのエリア２の３１を次のエリア−Ｖｏｌマッピング文で定義させる。
このエリア−Ｖｏｌマッピング文によって、ディクショナリ５０には、各々エリアとそのエリアに対応する正Ｖｏｌ名「正ボリューム２」、副Ｖｏｌ名「副ボリューム２」が設定される。
【００３４】
図７は、データベースバッファ管理２３１のフロー詳細である。データアクセス処理２３０でデータベースのページへの読み書き要求があると呼び出される。まず、データベースバッファ上に該当するページが存在するか否かを確認する（２３１０）。存在すれば、該当バッファ位置を通知し終了する（２３１１）。存在しなければ、該当するページをデータベースバッファに読み込むために、替わりに掃き出すべきページを決定する（２３１２）。ページを書き出す場合、ディスク装置に２重書き機能があるか否かを確認する（２３１３）。２重書き機能が存在すれば、ディスク装置の正Ｖｏｌに書き込み要求を発行し（２３１５）、ディスク装置の正Ｖｏｌ内容を副Ｖｏｌに反映する（２３１６）。２重書き機能が存在しなければ、ＯＳなどの手段でディスク装置の正副Ｖｏｌ対に対してそれぞれ書き込み要求を発行する（２３１４）。その次、空いたデータベースバッファに要求ページを読み込み（２３１７）、終了する。
次に、ＲＤＢシステムからＯＬＡＰシステムへデータ反映する一実施例を示す。
【００３５】
まず、ディスク２重化する場合とシステムログベースのデータ反映する場合に分けられる。さらに、ディスク２重化する場合も、ディスク２重書き機能の有無で分けられる。各々の場合について、以下では図８、９、１０で説明する。
【００３６】
図８は、ディスク２重書きなしの場合である。これば、図６の（ａ）に相当し、ソフトウェア的にディスク２重化を実現している。
まず、（ｉ）指定時刻データ作成フェーズとして、副Ｖｏｌに指定時刻で整合が取れたデータベース状態を作成する。データベースバッファ２３１から副Ｖｏｌのエリア２の３１への書き込みが抑止される。次に、データ抽出部２００がシステムログ４０から指定時刻までにトランザクションが完了したデータベースとするために、システムログ情報を時系列で反映する。
次に、（ii）データ抽出反映フェーズとして、データ抽出部２００が副Ｖｏｌのエリア２の３１からデータを抽出して、データ反映部６００を介しＯＬＡＰサーバシステムのスキーマ分割方法に従いエリア１の７００、エリア２の７０１、エリアｍの７０２へデータ登録される。
さらに、（iii）正副Ｖｏｌ再接続フェーズとして、上記（ｉ）、（ii）のフェーズ実行中に正Ｖｏｌのエリア２の３０に書き込まれた状態と副Ｖｏｌのエリア２の３１の状態との整合を保つため、データ抽出部２００がシステムログ４０から現時点までの最新のデータベースとするために、システムログ情報を時系列で反映する。
【００３７】
図９は、ディスク２重書きありの場合である。これば、図６の（ｂ）に相当し、ディスク装置で具備するディスク２重化を前提としている。
まず、（ｉ）指定時刻データ作成フェーズとして、副Ｖｏｌに指定時刻で整合が取れたデータベース状態を作成する。正Ｖｏｌのエリア２の３０から副Ｖｏｌのエリア２の３１への書き込みが抑止されると同時に、正Ｖｏｌのエリア２の３０への書き込み情報は差分情報３０００に反されるよう設定される。次に、データ抽出部２００がシステムログ４０から指定時刻までにトランザクションが完了したデータベースとするために、システムログ情報を時系列で反映する。
次に、（ii）データ抽出反映フェーズとして、データ抽出部２００が副Ｖｏｌのエリア２の３１からデータを抽出して、データ反映部６００を介しＯＬＡＰサーバシステムのスキーマ分割方法に従いエリア１の７００、エリア２の７０１、エリアｍの７０２へデータ登録される。
さらに、（iii）正副Ｖｏｌ再接続フェーズとして、上記（ｉ）、（ii）のフェーズ実行中に正Ｖｏｌのエリア２の３０に書き込まれた状態と副Ｖｏｌのエリア２の３１の状態との整合を保つため、差分情報３０００が副Ｖｏｌのエリア２の３１へ反映され現時点までの最新のデータベースとなる。
【００３８】
図１０は、システムログベースのデータ反映する場合である。
まず、前回までにデータ反映したシステムログ・ポイントを取得する。このシステムログ・ポイントは、指定時刻を表したものである。次に、当該システムログ・ポイント以降で、指定された時刻までのシステムログをデータ反映する。基本的には、システムログは時系列順に蓄積されているので、この順にデータ反映すればよい。具体的には、システムログ４０からデータを抽出して、データ反映部６００を介しＯＬＡＰサーバシステムのスキーマ分割方法に従いエリア１の７００、エリア２の７０１、エリアｍの７０２へデータ登録される。
【００３９】
上記のデータ抽出及びデータ反映の詳細フローを示す。
図１１は、データ抽出部２００のフローである。システムログベースのデータ反映か否かをか確認する（２００１）。システムログベースのデータ反映であれば、前回までにデータ反映したシステムログ・ポイントを取得し通知する（２００２）。次に、当該システムログ・ポイント以降で、指定された時刻までのシステムログ情報をデータ反映する（２００３）。システムログベースのデータ反映でなければ、ディスク装置に２重書き機能が存在するか否かを確認する（２００４）。
【００４０】
ディスク装置に２重書き機能が存在すれば、ディスク装置の正Ｖｏｌと副Ｖｏｌとのデータ反映同期関係を切り離す（２００５）と同時に、正Ｖｏｌへの書き込み内容を差分情報３０００へ反映するモードにディスク装置を設定する（２００６）。次に、システムログを基にして、副Ｖｏｌを指定時刻までにトランザクションが完了したデータベース状態にするため、システムログ情報を反映する（２００７）。さらに、副Ｖｏｌの内容を抽出し、データ反映する（２００８）。最後に、上記ステップで正Ｖｏｌに書き込まれた状態と副Ｖｏｌの状態との整合を保つため、差分情報３０００を副Ｖｏｌに反映し（２００９）、ディスク装置の正Ｖｏｌと副Ｖｏｌとを再接続する（２０１０）。
【００４１】
ディスク装置に２重書き機能が存在しなければ、ＯＳなど手段でのディスク装置への正Ｖｏｌのみの書き込みモードとし、副Ｖｏｌへの書き込みを抑止する（２０１１）。次に、システムログを基にして、副Ｖｏｌを指定時刻までにトランザクションが完了したデータベース状態にするため、システムログ情報を反映する（２０１２）。さらに、副Ｖｏｌの内容を抽出し、データ反映する（２０１３）。最後に、上記ステップで正Ｖｏｌに書き込まれた状態と副Ｖｏｌの状態との整合を保ち、現時点までの最新のデータベースとするために、システムログ情報を副Ｖｏｌに反映し（２０１４）、正副Ｖｏｌ書き込みモードに戻す（２０１５）。
【００４２】
図１２は、データ反映部６００のフローである。データ抽出部２００からのデータを受け取り（６０００）、初期作成、追加ロードを行い、分割スキーマに従い、各エリアへデータを登録する（６００１）。また、ＯＬＡＰシステムにデータ反映された内容に基づき、管理情報９０００を更新する（６００２）。
【００４３】
図１３に示す公知技術のレプリカＤＢ方式とＲＤＢ−ＯＬＡＰ連携方式についての差異を開示する。レプリカＤＢ方式は、抽出元のＲＤＢ３０１への更新によって変更された部分を抽出し、これらを即時あるいはある時間遅れで反映先ＲＤＢ３０２へ反映させる。レプリカＤＢでは、抽出元、反映先ともＲＤＢであるので、基本的には同一のデータ（一部ジョインあるいは複数の表への分類なども含まれる）の複製が作成される。従って、反映先ＲＤＢ３０２のデータを問合せでアクセスする場合、特別に抽出元ＲＤＢ３０１との関連性を考慮することはない。一方、ＲＤＢ−ＯＬＡＰ連携方式は、ＲＤＢシステムへの更新によって変更された部分を抽出し、これらを即時あるいはある時間遅れでＯＬＡＰシステムへ反映される。ＲＤＢ−ＯＬＡＰ連携方式では、ＯＬＡＰシステムを問合せでアクセスする場合、ＯＬＡＰシステムで管理するデータ３０１とＲＤＢ−ＯＬＡＰ連携で管理される管理情報９０００（反映までの時間隔、時刻、地域区分、顧客区分など）との組合せで意味を持つ。事実に関するデータを管理するのがＲＤＢシステムであり、それらから導き出せるトレンド分析結果などを引き出すのがＯＬＡＰシステムであるため、分析業務の前提条件は上記の管理情報９０００から導出されることになる。例えば、顧客購買分析では、時間隔・時刻などの時系列、販売された商品の地域別売上げ、商品を買った顧客の分類に基づき、様々な分析軸で評価する必要がある。その中で時系列をベースにすると、前年比、四半期比、先週比、前日比などの尺度で分析するためには、分析対象となるＯＬＡＰシステムのデータ７０１が、事実情報が蓄積管理されているＲＤＢシステムから上記尺度に従って適切に反映されていなければならない。即ち、ＯＬＡＰシステムへの問合せでは、これらの尺度を反映した管理情報とＯＬＡＰシステムのデータ７０１とで始めて意味ある結果が得られることとなる。
【００４４】
図１４は、ＯＬＡＰ問合せ処理部９００の詳細フローである。まず、ＯＬＡＰ問合せの解析処理を行い、その問合せの結果としてアクセスするべきＯＬＡＰシステムのデータ７０１を決定する（９０１）。次に、ＯＬＡＰシステムへのデータ反映状況を設定している管理情報９０００を読み出し、問合せ結果で必要となるデータを作成する（９０２）。最後に、ＯＬＡＰシステムのデータ７０１をアクセスし、管理情報９０００とマージすることで問合せへの結果として返却する（９０３）。
【００４５】
図１５は、システムログの構成内容である。システムログは、ログシーケンス番号、タイムスタンプ、ログ種別、ログ内容から構成される。ログシーケンス番号は、ＲＤＢシステムでユニークとなる識別子が割り当てられる。タイムスタンプは、当該システムログに関するイベントが発生した時刻を記録するために設定される。ログ種別は、抽出反映処理の開始（event_start）、抽出反映処理の中断（event_suspend）、抽出反映処理の再開（event_restart）、データのコミット（event_commit）、データの更新（event_update）、データの抽出反映（event_reflect）がある。ログ内容は、データベースへの更新履歴情報を記録する。これらのシステムログを基にして、ＲＤＢシステムからＯＬＡＰシステムへの抽出反映処理の制御を行うことができる。
【００４６】
本発明は、密結合／疎結合マルチプロセッサシステム、大型計算機のソフトウェアシステムを介して実現することも、また各処理部のために専用プロセッサが用意された密結合／疎結合マルチプロセッサシステムを介して実現することも可能である。さらに、単一のプロセッサシステムでも各々システム稼動にためにプロセスを割当ててあれば適用可能である。複数のプロセッサが各々複数のディスクをお互いに共用する構成にも適用可能である。
なお、前述したフローチャートの処理は、図２に示したような一般的なデータ処理装置でプログラムを実行することによって実現できる。また、そのプログラムは、ハードディスク装置、フロッピーディスクなどのコンピュータで読み書きができる記憶媒体に格納することができ、ネットワークを通してプログラムにアクセスすることができる。
【００４７】
【発明の効果】
本発明によれば、データベースへのデータ反映をデータベースサービスと並行して処理することが可能となる。
【図面の簡単な説明】
【図１】データベースシステムにおけるデータ抽出格納処理の概要を示す概念図
【図２】本発明の実施例におけるデータベース管理システムの構成を示す概略図
【図３】表定義時のスキーマ分割方法を適用した場合の構成図
【図４】表変更時のスキーマ分割方法を適用した場合の構成図
【図５】論理処理部の詳細フローの構成図
【図６】ディスク２重書き機能の構成図
【図７】データベースバッファ管理の詳細フローの構成図
【図８】ディスク２重書き機能なしの場合のデータ抽出格納方法の構成図
【図９】ディスク２重書き機能ありの場合のデータ抽出格納方法の構成図
【図１０】システムログベースのデータ抽出格納方法の構成図
【図１１】データ抽出部の詳細フローの構成図
【図１２】データ格納部の詳細フローの構成図
【図１３】ＲＤＢ−ＯＬＡＰ連携方式の従来の概念図
【図１４】ＯＬＡＰ問合せ処理部の詳細フローの構成図
【図１５】システムログの構成図
【符号の説明】
１０、１１、１２、１３…アプリケーションプログラム
２０…データベース管理システム
３０…データベース
４０…システムログ
５０…ディクショナリ
６０…ＯＬＡＰサーバシステム
８０…ＳＡＮ
【発明の属する技術分野】
本発明は、複数のデータベースを有するデータベース管理技術に関し、あるデータベースの情報を他のデータベースに格納するデータベース管理技術に関する。
【０００２】
【従来の技術】
高可用性のソリューションとして、データベース(DB)管理システムを２重化させ、片系がＣＰＵダウン、電源ダウンなどシステム障害の要因でデータベースシステム全体が停止するのを防ぐ目的で、ＨＡ（High Availability）システムのように多重化構成などが考えられる。例えば、文献（Jim Gray and Andreas Reuter, Tranzaction Processing: Concepts and Techniques, Morgan Kaufmann Publishers, 1993）にはＨＡシステム構成によるＤＢ障害対策としてのホットスタンバイ無停止運用について開示している。また、データベースを格納するディスク装置には、高信頼性を保証するために、ＲＡＩＤ（Redundant Array of Inexpensive Disks）構成を併用することが多い。このＲＡＩＤ構成は、文献（David A. Patterson et. al., A Case for Redundant Arrays of Inexpensive Disks(RAID), ACM SIGMOD 1988.）で詳細に開示されている。さらに、分散されたシステム間で同一の見方でデータベースをアクセスさせる機能として、レプリカＤＢがある。このレプリカＤＢ技術は、文献（Date, C.J., An Introduction to Database Systems: Volume 1 Fifth Edition, Addison-Wesley Publisher, 1990）で開示されている。
【０００３】
【発明が解決しようとする課題】
しかし、数万ユーザから同時にアクセスされるＷｅｂ環境、あるいは日々分析データが追加される数十ＴＢからなる大規模なＤＢを管理するDWHシステムにデータベース管理システムが適用される現状では、これらのデータベースシステムの運用につれて大幅に増加・変動するＤＢ量、ユーザ数、負荷量などに対応することが必須になる。予め、このようなＤＢ量、ユーザ数、負荷量の増減を加味してＤＢ設計（データ分割方法、メモリ量、プロセッサ・サーバ数、ディスク量の配置配分）を行うことも可能ではあるが、初期的にデータベースシステムを稼動させる時点では増加量を見込んだ膨大なシステムコストを考慮すると必要最小限のシステム構成でデータベースシステムを稼動せざるをえない。そのため、ＤＢ量、ユーザ数、負荷量が増減した時点で、初期時のＤＢ設計を見直し、再構築することになる。従来までは、このようなＤＢ設計方針に基き、データベースシステムの運用を止め、即ちＤＢサービスを停止させ、データ分割方法、メモリ量、プロセッサ・サーバ数、ディスク量を必要に応じて各々変更していた。
【０００４】
このＤＢサービス停止には、様々な要因が考えられる。例えば、Ｗｅｂ環境では年々増加するサービス数、Ｗｅｂブラウザなどのクライアントからのアクセス要求に対して、これらの要求を処理するために必要とされる処理能力に対応してデータベース管理システムのサーバの追加が必要になる。また、クライアントへのサービスを追加することでアプリケーションプログラムが増えることでデータベースに対する見方が多様になることで、対応する表も増え結果的にＤＢ量も年々増加する一方になる。これらのＤＢを格納するディスクの追加、データ分割方法のスキーマの変更を行うことによって、ＤＢ量の不均衡、ＤＢアクセス負荷の均衡化を図ることを考慮する必要がある。さらに、大量のＤＢ削除などの操作によるＤＢ構造の乱れにより検索効率の低下を防ぐために、ＤＢの再編成を定期的に行う必要がある。
【０００５】
これらのＤＢ運用機能は、夜間のデータベースシステム稼動停止あるいは週末のバッチ運用で行われる。ただし、Ｗｅｂ環境に代表されるようにデータベースシステムが２４時間グローバルに世界規模で利用されるようになった現在では、ＤＢ稼動停止時間やバッチ運用時間が確保できない状況がでてくる。そのため、ＤＢサービス無停止でこれらの運用を並行に実現する要求が強まっている。
【０００６】
このようなデータベース運用機能は、夜間のデータベースシステム稼動停止あるいは週末のバッチ運用で行われる。ただし、Ｗｅｂ環境に代表されるようにデータベースシステムが２４時間グローバルに世界規模で利用されるようになってくると、データベース稼動停止時間やバッチ運用時間が確保できない状況がでてくる。
【０００７】
本発明の目的は、データベースへのデータ格納をデータベースサービスと並行して処理するデータベース管理方法およびシステムを提供することにある。
【０００８】
【課題を解決するための手段】
前記課題を以下の手段により解決する。
第１のデータベースと第２のデータベースとを有するデータベース管理システムにおけるデータベース管理方法において、次のステップを有する。
（１）入力されたデータを上記第１のデータベースに格納する第１のステップ、（２）設定された条件を満たしたとき、上記第２のデータベースに登録したデータを管理する管理情報に基づいて上記第２のデータベースに登録さていないデータを上記第１のデータベースから得て、該得られたデータを上記第２のデータベースへ登録し、該得られたデータについて上記管理情報を更新する第２のステップ
このように、設定された条件により、上記第２のデータベースに登録したデータを管理する管理情報に基づいて上記第２のデータベースに登録さていないデータを上記第１のデータベースから得て、該得られたデータを上記第２のデータベースへ登録することができるため、第２のデータベースへのデータ格納を第１のデータベースサービスと並行して処理することができるようになる。
【０００９】
【発明の実施の形態】
ＤＢのサービス停止には、様々な要因が考えられる。例えば、Ｗｅｂ環境では年々増加するサービス数、Ｗｅｂブラウザなどのクライアントからのアクセス要求に対して、これらの要求を処理するために必要とされる処理能力に対応してデータベース管理システムのサーバの追加が必要になる。また、クライアントへのサービスを追加することでアプリケーションプログラムが増えることでデータベースに対する見方が多様になることで、対応する表も増え結果的にＤＢ量も年々増加する一方になる。これらのＤＢを格納するディスクの追加、データ分割方法のスキーマの変更を行うことによって、ＤＢ量の不均衡、ＤＢアクセス負荷の均衡化を図ることを考慮する必要がある。さらに、大量のＤＢ削除などの操作によるＤＢ構造の乱れにより検索効率の低下を防ぐために、ＤＢの再編成を定期的に行う必要がある。
【００１０】
これらのＤＢ運用機能は、夜間のデータベースシステム稼動停止あるいは週末のバッチ運用で行われる。ただし、Ｗｅｂ環境に代表されるようにデータベースシステムが２４時間グローバルに世界規模で利用されるようになった現在では、ＤＢ稼動停止時間やバッチ運用時間が確保できない状況がでてくる。そのため、ＤＢサービス無停止でこれらの運用を並行に実現する要求が強まっている。このＤＢサービスを停止させないで、ＤＢ運用を行うためには、次の課題を解消する必要がある。
（ｉ）接続性・拡張性
データベース処理を行うサーバとデータベースを管理するストーレジが独立に、しかも自立的にデータ管理が運用できることにより、サーバあるいはストーレジが稼動中に接続構成や各サーバ・ストーレジ追加・変更が容易になる。
（ii）データ共用
複数のサーバ間でストーレジが共用可能であることにより、フラットフォームと独立にデータ移動、変換が可能となる。
（iii）高可用性
破壊されてはならないデータを多重化あるいは離れた場所にコピーできる。
【００１１】
これらの要件を満たすのが、次世代ＩＴとして注目を浴びているＳＡＮ（Storage Area Network）ソリューションである。ＳＡＮソリューションの目指す目標は、次の４点である。
（ａ）ストーレジ入出力性能の大幅向上（Performance)
（ｂ）サーバ環境とは独立した柔軟なストーレジ環境の設定・拡張（Scalability)
（ｃ）ストーレジの一元運用(Storage Management Efficiency)
（ｄ）接続距離を飛躍的に延ばす事による災害対策(Data Protection)
特に、データベースシステムの拡張性を加味すると、上記の（ｂ）の特長活かすことが有望である。
【００１２】
ここで具体的なデータベースシステムで議論する。大手小売業販売実績管理システムでは、地域に展開している各小売店舗の時々刻々の販売履歴情報をＰＯＳ端末などにより集積されている。これらの情報は、在庫管理、発注管理、商品配送計画などと関連付けられている。また、売れ筋商品分析などの結果を、即時に店舗内商品配置に反映することも考えられる。そのために、ＲＤＢシステムに時系列順に、販売履歴コードなどからなるレコードをＤＢへ追記中心で反映することでＤＢを構築して行く。また、ここで蓄積された履歴ＤＢをソースにして、多元な分析軸で瞬時にＯＬＡＰ分析が可能なＯＬＡＰシステムを構築する。このＯＬＡＰシステムは、ＲＤＢシステムで構築された履歴ＤＢを反映する必要がある。従来技術のレプリカＤＢでは、抽出元のＲＤＢへの更新によって変更された部分を抽出し、これらを即時あるいはある時間遅れで反映先ＲＤＢへ反映される。レプリカＤＢでは、抽出元、反映先ともＲＤＢであるので、基本的には同一のデータ（一部ジョインあるいは複数の表への分類なども含まれる）の複製が作成される。ここでのＲＤＢシステムからＯＬＡＰシステムへの反映方法には、２通りが考えられる。
(a)初期作成
ＲＤＢシステムに構築された全ての履歴ＤＢをデータロードし、ＯＬＡＰシステムへ反映する
(b)追加更新
履歴ＤＢで追加更新が行われた部分を、ＯＬＡＰシステムへ追加ロードする
典型的な、販売履歴ＤＢに対するＤＢ諸元及びアクセス特性は、以下のようになる。大手小売業販売実績から推定から推定すると、７．７Ｍ件／日の販売実績があり、各実績毎に２００Ｂ〜１ＫＢ長のレコードを登録することにより、約４０ＧＢ〜２００ＧＢ／月の履歴ＤＢ規模になる。年間で約０．４ＴＢ〜２ＴＢのＤＢが追加されることになる。この履歴ＤＢは、スタースキーマを構成し、ＳＱＬの集約問合せにより統計サマリーを作成する業務で利用されことが多い。
【００１３】
また、販売履歴ＤＢをより多次元の軸で動的に分析する業務ではＯＬＡＰシステムを用い、１８〜２４ヶ月の履歴データを構築して、販売地区毎、あるいは商品毎の同月比、月別、期別などで分析を行う必要がある。さらに、約３ヶ月の履歴データに８０％以上のアクセスが集中する特徴もあり、さらにデータの鮮度をより上げるニーズが増えつつある。上記議論したが、このＲＤＢシステムとＯＬＡＰシステムのサービスを無停止で提供されなければならないことは言うまでもない。
【００１４】
ＤＢサービスを無停止で時系列、販売履歴コードなどにより追記中心の履歴ＤＢを対象にしたＯＬＡＰ分析業務をＲＤＢ業務を停止せずに構築（初期作成、追加更新）するためには、次の課題を解決する必要がある。
(1)ＲＤＢシステムで追加更新するデータベース領域とＯＬＡＰシステムへ初期作成、追加ロードするデータベース領域が重なるために、ＲＤＢシステム及びＯＬＡＰシステムでアクセスが競合するため、ＲＤＢシステム側のシステム性能が低下する。
(2)ＯＬＡＰ分析業務では、最近のデータへのアクセスの８０％が集中し、しかもＯＬＡＰシステムへの追加ロードの対象にもなるため、局所的なデータベース領域に負荷が集中する。
【００１５】
これらの課題を解消するために、次の解決方法を考える。
【００１６】
アクセスするデータベース領域が競合するため生じる課題に対しては、次の解決方法を考える。
(a)データベース格納領域を分離
ＲＤＢシステムでアクセスするデータベース領域はデータ追加と参照が主であり、ＯＬＡＰサーバへ追加ロードし反映するため読み出しのみであることに着目すれば、ディスク装置の多重化機能あるいはＯＳが提供するディスク２重書きを利用することにより、物理的にデータベース領域を複数もつことで対応する。このデータベース領域は書き込みの同期が取られていることが前提である。正Ｖｏｌ（データ追加と参照あり）と副Ｖｏｌ（指定時刻で整合性があるＤＢ）の内容が異なり、しかも物理的に隔絶することでアクセス負荷を分ける。
(b)データベース管理システムの更新履歴情報システムログの利用
データベース管理システムでは、ＤＢ障害回復のために更新履歴情報システムログを保持している。即ち、このシステムログにはデータベースシステムへの全更新情報が含まれているので、ある時点からの更新情報を抽出することが可能である。ＯＬＡＰサーバへ追加ロードし反映するためには、このシステムログから抽出した該当する履歴ＤＢ表に関するデータを作成することができる。
(c)ＯＬＡＰサーバへの反映部分を局所化する方法
データベースをキー値範囲、ハッシュ分割などにより分割する手法が行われているが、最近のデータを細分化し、かつ８０％のアクセスが集中するため並列化効果を高めるため、多段の階層分割を採用する。即ち、ＯＬＡＰサーバへ追加ロードする対象のデータは、時系列的には最近に集まる特性を持つため、時間的に近いデータを上記の分割手法を用いて分割区間として局所化する。これによって、ＲＤＢシステムの負荷を最小限にさせ、追加ロードのための読み出しが可能となる。
【００１７】
また、ＲＤＢシステムからＯＬＡＰシステムへデータを反映する場合、あるデータベースとして整合の取れた状態でＯＬＡＰ分析ができることが要求される。即ち、ある時点でのデータベースとして整合が取れたデータをＲＤＢシステムからＯＬＡＰシステムへ見せることが必要となる。この課題を解消するために、次の手段を適用する。
(a)ＲＤＢシステムのデータベースを時系列順で分割管理
時系列順で分割管理するため、追加ロードする対象のデータアクセス範囲を局所化可能である。ＲＤＢシステム側では、以前どこまでの時系列範囲をＯＬＡＰシステム側に反映したかを把握すれば、今回どの時系列範囲を追加ロードすればよいかが判定できる。
(b)システムログ情報を基にデータ反映
ＲＤＢシステムではデータベースへの更新反映情報をシステムログとして維持管理している。ＯＬＡＰシステムへ追加ロードするデータは、このシステムログ情報から該当する履歴ＤＢ表のある時点からの更新履歴を抽出すればよい。
【００１８】
上記のＳＡＮソリューションと組み合わせることにより、ＤＢ処理を行うサーバとＤＢを格納するストーレジが光ファイバなどの高速なネットワークを介して接続されるため、サーバとストーレジとの共用関係や接続に関するマッピング情報を変更するのみで動的なサーバ追加、ディスク追加などが容易に運用できる。さらに、各ストーレジはＲＡＩＤディスクを利用するため、多重化による信頼性の確保とともにＤＢ運用でワークとして必要な領域を動的なデバイスとして割当て、解除などの機能を利用することにより、通常業務を停止しないでＤＢ再編成運用ができる。具体的には、サーバ及びディスクを追加することでＤＢシステムの規模を拡大する、即ちスケーラブルなシステムが構築できる。
【００１９】
前記課題を以下の手段により解決する。
（１）ＤＢ分割管理するシステムで、新たに第１のＤＢ格納領域と第２のＤＢ格納領域を割当て、第１の格納領域の複写を第２の格納領域に反映し、複写の指示が解除されると第１の格納領域への書き込みが行われ、再複写の指示が行われると複写指示が解除された間第１の格納領域に書き込まれたデータが第２の格納領域に反映されること
（２）（１）において、複写の指示が解除される間、第２の格納領域に指定された時刻までトランザクションが完了したシステムログを第２の格納領域に反映し、第２の格納領域を読み出すこと。
（３）（１）において、ＤＢ分割管理手法として、キーレンジ分割、ハッシュ分割、ラウンドロビン分割、及びそれらを多元的に組合せる分割手段を用い、時系列でより最近のデータを細分化してデータ分割すること。
（４）（１）において、第１のＤＢ格納領域と第２のＤＢ格納領域を割当てるデータベース領域は、前回までに反映された時点以降の時系列でより最近のデータを格納するデータベース領域であること。
（５）ＤＢ分割管理するシステムで、第１のＤＢ格納領域を割当て、第１の格納領域への書き込み履歴であるシステムログから前回まで反映された時点以降の該当するデータを読み出すこと。
【００２０】
以下、本発明の実施例を図面を用いて詳細に説明する。
時系列、販売履歴コードなどにより追記中心の履歴ＤＢを対象にしたＯＬＡＰ分析業務をＲＤＢ業務を停止せずに構築（初期作成、追加更新）する。ＤＢ分割管理は、ＤＢ障害の局所化、バックアップ単位の細分化手段として適用されていたが、追記によるＤＢ量の変動、及びＯＬＡＰサーバへの反映部分を局所化する方法として適用する。
【００２１】
図ｌは、ＲＤＢシステムからＯＬＡＰシステムへデータを反映する全体構成を示してる。ＲＤＢシステムは、アプリケーションプログラム１０、１１、及びデータ抽出部２００を含むデータベース管理システム２０で構成されている。また、ＯＬＡＰシステムは、アプリケーションプログラム１１、１２、及びデータ反映部６００を含むＯＬＡＰサーバシステム６０で構成されている。ＲＤＢシステム及びＯＬＡＰシステムのデータベースは、ＳＡＮを介して接続されている。ＲＤＢシステムのデータベースは、エリアに分割されており、図３で示すようにエリア１の３００、エリア２の３０１、エリア３の３０２、エリア４の３０３、エリア５１の３０４、エリア５２の３０５、エリア５３の３０６に各々格納されている。エリア５１の３０４、エリア５２の３０５、エリア５３の３０６は、正Ｖｏｌとして格納管理されているが、ディスク２重書き機能を有する場合、エリア５１の３０７、エリア５２の３０８、エリア５３の３０９に副Ｖｏｌが格納管理される。ＯＬＡＰシステムのデータベースは、エリアに分割されており、エリア１の７００、エリア２の７０１、エリア３の７０２に格納管理される。
【００２２】
ＲＤＢシステムでデータ更新されるとデータベース管理システム２０によってデータベースへ書き込まれる。この例では、正Ｖｏｌであるエリア５１の３０４、エリア５２の３０５、エリア５３の３０６に書き込まれる。正Ｖｏｌへの書き込みは、バックグラウンドで副Ｖｏｌへ書き込みとなる。ＲＤＢシステムからＯＬＡＰシステムへのデータ反映は、データベース管理システム２０のデータ抽出部２００及びＯＬＡＰサーバシステム６０のデータ反映部６００を介して行われる。ＯＬＡＰサーバシステム６０は、ＲＤＢシステムから反映されたデータを分割スキーマに基きエリア１の７００、エリア２の７０１、エリア３の７０２に格納する。
【００２３】
図２は、データベース管理システム２０の構成図である。ユーザが作成したアプリケーションプログラム１０、１１と問合せ処理やリソース管理などのデータベースシステム全体の管理を行うデータベース管理システム２０がある。上記のデータベース管理システム２０は、システム制御２１、論理処理部２２、物理処理部２３と、データベースアクセス対象となるデータを永続的にあるいは一時的に格納するデータベース３０・ディクショナリ５０・システムログ４０からなる。また、上記データベース管理システム２０はネットワークなどを介して他のシステムと接続されている。
【００２４】
ＳＡＮ構成のシステムでは、上記データベース３０・ディクショナリ５０・システムログ４０の全体あるいは一部分がＳＡＮ８０を介してディスク装置に格納されている。この場合、ディクショナリ５０にはデータベース３０を各エリアにどのスキーマ分割手法で分割したか、あるいはエリアと正副Ｖｏｌのマッピングなどについて設定している。表定義文、表変更文などにより、このディクショナリ５０情報を更新することでデータベース管理システム、ＯＬＡＰサーバシステムなどサーバシステム側とＳＡＮを介して接続されたディスク装置内のスキーマ分割されたデータベースの格納部分となるエリアやこれらのエリアと対応付く正副Ｖｏｌなどストーレジ側とのマッピングが設定、更新される。
【００２５】
上記システム制御２１は、ユーザからの問合せ入力、問合せ結果の返却、データロード・データ再編成・再構成コマンドなど受付によるデータベース保守、他システムとの連携制御などを行う。上記論理処理部２２は、問合せの構文解析・意味解析を行う問合せ解析２２０と、適切な処理手順を生成する最適化処理２２１と、処理手順に対応したコードの生成を行うコード生成２２２とを具備している。また、上記生成されたコードに基きコードの解釈実行を行うコード解釈実行２２３を具備している。さらに、表定義コマンド、表変更コマンド、エリア−Ｖｏｌマッピング・コマンド、正副Ｖｏｌ制御コマンドなどコマンド解析実行を行うコマンド解析２２５を具備している。上記物理処理部２３は、アクセスしたデータの条件判定、編集、レコード追加などを実現するデータアクセス制御２３０と、データベースレコードの読み書きなどのアクセス制御を行うデータベースバッファ制御２３１と、システムで共用するリソースの排他制御２３２とを具備している。さらに、データベース３０の読み出し及び書き込みはデータベースバッファ２４を介して行われる。システムログ４０は、データベース３０へのデータ挿入、更新、削除などの更新履歴情報を蓄積する。ディクショナリ５０は、データベース３０の表、インデクスなどデータベース・スキーマ情報、データベース３０のデータ分割方法、格納管理する領域名称、ページサイズなどの格納情報からなる。また、データ分割方法の変更などのコマンドが実行されると、ディクショナリ５０が変更される。
【００２６】
次に、販売履歴表を時系列で分割する一実施例として、データベース分割方法としてキーレンジ分割手法を用いる。データベース分割方法には、キーレンジ分割手法以外にハッシュ分割手法、ラウンドロビン分割手法、及びこれらの手法を多元的に組合せる手法などがあり、これらを分割手法として適用することは可能である。
図３は、販売履歴表を時系列で分割して管理している。販売履歴表は、年度、半期、月毎で分割管理されている。具体的には、９７年度はエリア１の３００、９８年度はエリア２の３０１、９９年度第１四半期はエリア３の３０２、９９年度第二四半期はエリア４の３０３、９９年度７月分はエリア５１の３０４、９９年度８月分はエリア５２の３０５、９９年度９月分はエリア５３の３０６に格納されている。この場合、ディクショナリ５０には、各々キーレンジ区間とその区間に対応するエリア名が設定される。
【００２７】
例えば、このデータベース分割は次の表定義文で実行される。
【００２８】
図４は、９９年度９月分にデータ反映し終えた時点でのデータベース分割方法の変更を行う場合の表変更文の実行を示す。エリア５１の３０４、エリア５２の３０５の分割区間で管理されていたデータベースをエリア５３の３０６を含め、エリア５の３０７とする表変更文は次のようになる。
ALTER TABLE 販売履歴表
MERGE AREA (エリア５１,エリア５２,エリア５３)
INTO ( (エリア５) 時刻コード>='1999-09');
この表変更文によって、ディクショナリ５０には、各々キーレンジ区間とその区間に対応するエリア５１、エリア５２、エリア５３エリア名が、エリア５に変更され、設定される。
【００２９】
図５は、論理処理部２２の処理フローである。表定義文及び表変更文などのコマンド解析実行、問合せ解析、問合せ実行は、この論理処理部２２で実現される。ユーザから入力されたコマンドが、解析要求、実行要求、あるいはコマンド解析実行であるか確認される（２２５）。解析要求であれば、問合せ解析（２２０）、最適化処理（２２１）、コード生成（２２２）が行われる。また、実行要求であれば、コード解釈実行が行われる（２２３）。さらに、コマンド解析実行要求であれば、コマンド解析が行われる（２２４）。表定義コマンドであれば（２２６）、表のデータベース分割方法、各エリア名への対応付けなどをディクショナリ５０へ登録する（２２７）。表定義コマンドであれば（２２８）、表のデータベース分割方法の変更及び各エリアの追加、削除、併合、分割などに応じてディクショナリ５０へ登録する。エリア−Ｖｏｌマッピング・コマンドであれば（２３０）、各エリアに対応する正副Ｖｏｌ情報をディクシュナリ５０へ登録する。正副Ｖｏｌ制御コマンドであれば（２３２）、正副Ｖｏｌへの切り離し指示、再接続指示を該当するディスク装置へ発行する（２３３）。
【００３０】
図６は、ディスク２重書きの原理を示す。以下の説明で、ディスク２重書き機能を適用するため、ここで開示する。ディスク装置へ正副Ｖｏｌ対を設け２重に書き込む場合、ディスク２重書き機能が存在するか否かで動作が異なる。
【００３１】
ディスク２重書き機能が存在しない場合（(a)）、データベースバッファ管理２３１から正Ｖｏｌのエリア２の３０及び副Ｖｏｌのエリア２の３１に対して、各ディスク装置に書き込み要求が発行される。即ち、ソフトウェア的に２つのディスク装置上で同一のデータを常に保持することになる。
【００３２】
また、ディスク２重書き機能が存在する場合（(b)）、データベースバッファ管理２３１から正Ｖｏｌのエリア２の３０に対して書き込み要求が発行される。ディスク２重書き機能を有するディスク装置では、正Ｖｏｌのエリア２の３０と副Ｖｏｌのエリア２の３１の対応付けを指定されており、この対応付けにより正Ｖｏｌのエリア２の３０への書き込みを副Ｖｏｌのエリア２の３１の書き込みとして反映させる。即ち、ディスク装置側の機能としてハードウェア的に２つのディスク装置上で同一のデータを常に保持することになる。
【００３３】
さらに、正Ｖｏｌのエリア２の３０及び副Ｖｏｌのエリア２の３１を次のエリア−Ｖｏｌマッピング文で定義させる。
【００３４】
図７は、データベースバッファ管理２３１のフロー詳細である。データアクセス処理２３０でデータベースのページへの読み書き要求があると呼び出される。まず、データベースバッファ上に該当するページが存在するか否かを確認する（２３１０）。存在すれば、該当バッファ位置を通知し終了する（２３１１）。存在しなければ、該当するページをデータベースバッファに読み込むために、替わりに掃き出すべきページを決定する（２３１２）。ページを書き出す場合、ディスク装置に２重書き機能があるか否かを確認する（２３１３）。２重書き機能が存在すれば、ディスク装置の正Ｖｏｌに書き込み要求を発行し（２３１５）、ディスク装置の正Ｖｏｌ内容を副Ｖｏｌに反映する（２３１６）。２重書き機能が存在しなければ、ＯＳなどの手段でディスク装置の正副Ｖｏｌ対に対してそれぞれ書き込み要求を発行する（２３１４）。その次、空いたデータベースバッファに要求ページを読み込み（２３１７）、終了する。
次に、ＲＤＢシステムからＯＬＡＰシステムへデータ反映する一実施例を示す。
【００３５】
まず、ディスク２重化する場合とシステムログベースのデータ反映する場合に分けられる。さらに、ディスク２重化する場合も、ディスク２重書き機能の有無で分けられる。各々の場合について、以下では図８、９、１０で説明する。
【００３６】
図８は、ディスク２重書きなしの場合である。これば、図６の（ａ）に相当し、ソフトウェア的にディスク２重化を実現している。
まず、（ｉ）指定時刻データ作成フェーズとして、副Ｖｏｌに指定時刻で整合が取れたデータベース状態を作成する。データベースバッファ２３１から副Ｖｏｌのエリア２の３１への書き込みが抑止される。次に、データ抽出部２００がシステムログ４０から指定時刻までにトランザクションが完了したデータベースとするために、システムログ情報を時系列で反映する。
次に、（ii）データ抽出反映フェーズとして、データ抽出部２００が副Ｖｏｌのエリア２の３１からデータを抽出して、データ反映部６００を介しＯＬＡＰサーバシステムのスキーマ分割方法に従いエリア１の７００、エリア２の７０１、エリアｍの７０２へデータ登録される。
さらに、（iii）正副Ｖｏｌ再接続フェーズとして、上記（ｉ）、（ii）のフェーズ実行中に正Ｖｏｌのエリア２の３０に書き込まれた状態と副Ｖｏｌのエリア２の３１の状態との整合を保つため、データ抽出部２００がシステムログ４０から現時点までの最新のデータベースとするために、システムログ情報を時系列で反映する。
【００３７】
図９は、ディスク２重書きありの場合である。これば、図６の（ｂ）に相当し、ディスク装置で具備するディスク２重化を前提としている。
まず、（ｉ）指定時刻データ作成フェーズとして、副Ｖｏｌに指定時刻で整合が取れたデータベース状態を作成する。正Ｖｏｌのエリア２の３０から副Ｖｏｌのエリア２の３１への書き込みが抑止されると同時に、正Ｖｏｌのエリア２の３０への書き込み情報は差分情報３０００に反されるよう設定される。次に、データ抽出部２００がシステムログ４０から指定時刻までにトランザクションが完了したデータベースとするために、システムログ情報を時系列で反映する。
次に、（ii）データ抽出反映フェーズとして、データ抽出部２００が副Ｖｏｌのエリア２の３１からデータを抽出して、データ反映部６００を介しＯＬＡＰサーバシステムのスキーマ分割方法に従いエリア１の７００、エリア２の７０１、エリアｍの７０２へデータ登録される。
さらに、（iii）正副Ｖｏｌ再接続フェーズとして、上記（ｉ）、（ii）のフェーズ実行中に正Ｖｏｌのエリア２の３０に書き込まれた状態と副Ｖｏｌのエリア２の３１の状態との整合を保つため、差分情報３０００が副Ｖｏｌのエリア２の３１へ反映され現時点までの最新のデータベースとなる。
【００３８】
図１０は、システムログベースのデータ反映する場合である。
まず、前回までにデータ反映したシステムログ・ポイントを取得する。このシステムログ・ポイントは、指定時刻を表したものである。次に、当該システムログ・ポイント以降で、指定された時刻までのシステムログをデータ反映する。基本的には、システムログは時系列順に蓄積されているので、この順にデータ反映すればよい。具体的には、システムログ４０からデータを抽出して、データ反映部６００を介しＯＬＡＰサーバシステムのスキーマ分割方法に従いエリア１の７００、エリア２の７０１、エリアｍの７０２へデータ登録される。
【００３９】
上記のデータ抽出及びデータ反映の詳細フローを示す。
図１１は、データ抽出部２００のフローである。システムログベースのデータ反映か否かをか確認する（２００１）。システムログベースのデータ反映であれば、前回までにデータ反映したシステムログ・ポイントを取得し通知する（２００２）。次に、当該システムログ・ポイント以降で、指定された時刻までのシステムログ情報をデータ反映する（２００３）。システムログベースのデータ反映でなければ、ディスク装置に２重書き機能が存在するか否かを確認する（２００４）。
【００４０】
ディスク装置に２重書き機能が存在すれば、ディスク装置の正Ｖｏｌと副Ｖｏｌとのデータ反映同期関係を切り離す（２００５）と同時に、正Ｖｏｌへの書き込み内容を差分情報３０００へ反映するモードにディスク装置を設定する（２００６）。次に、システムログを基にして、副Ｖｏｌを指定時刻までにトランザクションが完了したデータベース状態にするため、システムログ情報を反映する（２００７）。さらに、副Ｖｏｌの内容を抽出し、データ反映する（２００８）。最後に、上記ステップで正Ｖｏｌに書き込まれた状態と副Ｖｏｌの状態との整合を保つため、差分情報３０００を副Ｖｏｌに反映し（２００９）、ディスク装置の正Ｖｏｌと副Ｖｏｌとを再接続する（２０１０）。
【００４１】
ディスク装置に２重書き機能が存在しなければ、ＯＳなど手段でのディスク装置への正Ｖｏｌのみの書き込みモードとし、副Ｖｏｌへの書き込みを抑止する（２０１１）。次に、システムログを基にして、副Ｖｏｌを指定時刻までにトランザクションが完了したデータベース状態にするため、システムログ情報を反映する（２０１２）。さらに、副Ｖｏｌの内容を抽出し、データ反映する（２０１３）。最後に、上記ステップで正Ｖｏｌに書き込まれた状態と副Ｖｏｌの状態との整合を保ち、現時点までの最新のデータベースとするために、システムログ情報を副Ｖｏｌに反映し（２０１４）、正副Ｖｏｌ書き込みモードに戻す（２０１５）。
【００４２】
図１２は、データ反映部６００のフローである。データ抽出部２００からのデータを受け取り（６０００）、初期作成、追加ロードを行い、分割スキーマに従い、各エリアへデータを登録する（６００１）。また、ＯＬＡＰシステムにデータ反映された内容に基づき、管理情報９０００を更新する（６００２）。
【００４３】
図１３に示す公知技術のレプリカＤＢ方式とＲＤＢ−ＯＬＡＰ連携方式についての差異を開示する。レプリカＤＢ方式は、抽出元のＲＤＢ３０１への更新によって変更された部分を抽出し、これらを即時あるいはある時間遅れで反映先ＲＤＢ３０２へ反映させる。レプリカＤＢでは、抽出元、反映先ともＲＤＢであるので、基本的には同一のデータ（一部ジョインあるいは複数の表への分類なども含まれる）の複製が作成される。従って、反映先ＲＤＢ３０２のデータを問合せでアクセスする場合、特別に抽出元ＲＤＢ３０１との関連性を考慮することはない。一方、ＲＤＢ−ＯＬＡＰ連携方式は、ＲＤＢシステムへの更新によって変更された部分を抽出し、これらを即時あるいはある時間遅れでＯＬＡＰシステムへ反映される。ＲＤＢ−ＯＬＡＰ連携方式では、ＯＬＡＰシステムを問合せでアクセスする場合、ＯＬＡＰシステムで管理するデータ３０１とＲＤＢ−ＯＬＡＰ連携で管理される管理情報９０００（反映までの時間隔、時刻、地域区分、顧客区分など）との組合せで意味を持つ。事実に関するデータを管理するのがＲＤＢシステムであり、それらから導き出せるトレンド分析結果などを引き出すのがＯＬＡＰシステムであるため、分析業務の前提条件は上記の管理情報９０００から導出されることになる。例えば、顧客購買分析では、時間隔・時刻などの時系列、販売された商品の地域別売上げ、商品を買った顧客の分類に基づき、様々な分析軸で評価する必要がある。その中で時系列をベースにすると、前年比、四半期比、先週比、前日比などの尺度で分析するためには、分析対象となるＯＬＡＰシステムのデータ７０１が、事実情報が蓄積管理されているＲＤＢシステムから上記尺度に従って適切に反映されていなければならない。即ち、ＯＬＡＰシステムへの問合せでは、これらの尺度を反映した管理情報とＯＬＡＰシステムのデータ７０１とで始めて意味ある結果が得られることとなる。
【００４４】
図１４は、ＯＬＡＰ問合せ処理部９００の詳細フローである。まず、ＯＬＡＰ問合せの解析処理を行い、その問合せの結果としてアクセスするべきＯＬＡＰシステムのデータ７０１を決定する（９０１）。次に、ＯＬＡＰシステムへのデータ反映状況を設定している管理情報９０００を読み出し、問合せ結果で必要となるデータを作成する（９０２）。最後に、ＯＬＡＰシステムのデータ７０１をアクセスし、管理情報９０００とマージすることで問合せへの結果として返却する（９０３）。
【００４５】
図１５は、システムログの構成内容である。システムログは、ログシーケンス番号、タイムスタンプ、ログ種別、ログ内容から構成される。ログシーケンス番号は、ＲＤＢシステムでユニークとなる識別子が割り当てられる。タイムスタンプは、当該システムログに関するイベントが発生した時刻を記録するために設定される。ログ種別は、抽出反映処理の開始（event_start）、抽出反映処理の中断（event_suspend）、抽出反映処理の再開（event_restart）、データのコミット（event_commit）、データの更新（event_update）、データの抽出反映（event_reflect）がある。ログ内容は、データベースへの更新履歴情報を記録する。これらのシステムログを基にして、ＲＤＢシステムからＯＬＡＰシステムへの抽出反映処理の制御を行うことができる。
【００４６】
本発明は、密結合／疎結合マルチプロセッサシステム、大型計算機のソフトウェアシステムを介して実現することも、また各処理部のために専用プロセッサが用意された密結合／疎結合マルチプロセッサシステムを介して実現することも可能である。さらに、単一のプロセッサシステムでも各々システム稼動にためにプロセスを割当ててあれば適用可能である。複数のプロセッサが各々複数のディスクをお互いに共用する構成にも適用可能である。
なお、前述したフローチャートの処理は、図２に示したような一般的なデータ処理装置でプログラムを実行することによって実現できる。また、そのプログラムは、ハードディスク装置、フロッピーディスクなどのコンピュータで読み書きができる記憶媒体に格納することができ、ネットワークを通してプログラムにアクセスすることができる。
【００４７】
【発明の効果】
本発明によれば、データベースへのデータ反映をデータベースサービスと並行して処理することが可能となる。
【図面の簡単な説明】
【図１】データベースシステムにおけるデータ抽出格納処理の概要を示す概念図
【図２】本発明の実施例におけるデータベース管理システムの構成を示す概略図
【図３】表定義時のスキーマ分割方法を適用した場合の構成図
【図４】表変更時のスキーマ分割方法を適用した場合の構成図
【図５】論理処理部の詳細フローの構成図
【図６】ディスク２重書き機能の構成図
【図７】データベースバッファ管理の詳細フローの構成図
【図８】ディスク２重書き機能なしの場合のデータ抽出格納方法の構成図
【図９】ディスク２重書き機能ありの場合のデータ抽出格納方法の構成図
【図１０】システムログベースのデータ抽出格納方法の構成図
【図１１】データ抽出部の詳細フローの構成図
【図１２】データ格納部の詳細フローの構成図
【図１３】ＲＤＢ−ＯＬＡＰ連携方式の従来の概念図
【図１４】ＯＬＡＰ問合せ処理部の詳細フローの構成図
【図１５】システムログの構成図
【符号の説明】
１０、１１、１２、１３…アプリケーションプログラム
２０…データベース管理システム
３０…データベース
４０…システムログ
５０…ディクショナリ
６０…ＯＬＡＰサーバシステム
８０…ＳＡＮ
Claims (4)
- 複数のデータベースシステムを連携するデータベースシステム管理システムであって、
第１の形式のデータベースを備える第１のデータベースシステムと、前記第１の形式のデータベースとは異なる第２の形式のデータベースを備える第２のデータベースシステムを有し、
第１の形式のデータベースのシステムログからある時点以降データを抽出する手段と、
前記抽出したデータを前記第２のデータベースシステムが受け取り、第２の形式のデータベースに前記抽出データを反映するとともに、前記第２の形式のデータベースへの反映状況を設定した管理情報を更新するデータ反映手段と、
前記第２のデータベースシステムへの問合せの解析処理を前記管理情報に基づいて行い、問合せ結果としてアクセスするべき前記第２の形式のデータベースのデータを決定する手段と、
前記第２のデータベースシステムが前記管理情報を読み出し、前記問合せ結果の分析尺度を決めるデータを作成する手段と、
前記第２の形式のデータベースにおけるデータをアクセスし、前記分析尺度を決めるデータに基づき管理情報とマージすることで前記問合せ結果として返却する手段とを有することを特徴とするデータベース管理システム。 - 請求項１記載のデータベース管理システムにおいて、
前記第１の形式のデータベースは、ＲＤＢであり、前記第２の形式のデータベースは、
ＯＬＡＰ ＤＢであることを特徴とするデータベース管理システム。 - 請求項１もしくは２に記載のデータベース管理システムにおいて、
前記管理情報は、反映までの時間隔、時刻、地域区分、顧客区分であることを特徴とするデータベース管理システム。 - 請求項１乃至３のいずれかに記載のデータベース管理システムにおいて、
前記システムログには、データの抽出反映処理を示す情報、および抽出反映処理の開始、
中断を示す情報を含むことを特徴とするデータベース管理システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001195684A JP4895437B2 (ja) | 2000-09-08 | 2001-06-28 | データベース管理方法およびシステム並びにその処理プログラムおよびそのプログラムを格納した記録媒体 |
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000-278671 | 2000-09-08 | ||
| JP2000278671 | 2000-09-08 | ||
| JP2000278671 | 2000-09-08 | ||
| JP2001195684A JP4895437B2 (ja) | 2000-09-08 | 2001-06-28 | データベース管理方法およびシステム並びにその処理プログラムおよびそのプログラムを格納した記録媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002157156A JP2002157156A (ja) | 2002-05-31 |
| JP4895437B2 true JP4895437B2 (ja) | 2012-03-14 |
Family
ID=26599928
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001195684A Expired - Fee Related JP4895437B2 (ja) | 2000-09-08 | 2001-06-28 | データベース管理方法およびシステム並びにその処理プログラムおよびそのプログラムを格納した記録媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4895437B2 (ja) |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8315972B2 (en) * | 2003-09-26 | 2012-11-20 | Microsoft Corporation | Method for maintaining databases information about multiple instances of an activity generating, updating virtual OLAP cube based on modified star-schema |
| US7158991B2 (en) * | 2003-09-30 | 2007-01-02 | Veritas Operating Corporation | System and method for maintaining temporal data in data storage |
| US7890508B2 (en) * | 2005-08-19 | 2011-02-15 | Microsoft Corporation | Database fragment cloning and management |
| JP2008117300A (ja) * | 2006-11-07 | 2008-05-22 | Mitsubishi Electric Corp | 検索装置、データ処理装置および検索方法 |
| JP5186972B2 (ja) * | 2008-03-25 | 2013-04-24 | 富士通株式会社 | 情報記憶システム |
| CN102129425B (zh) * | 2010-01-20 | 2016-08-03 | 阿里巴巴集团控股有限公司 | 数据仓库中大对象集合表的访问方法及装置 |
| JP6272556B2 (ja) * | 2015-04-02 | 2018-01-31 | 株式会社日立製作所 | 共有リソース更新装置及び共有リソース更新方法 |
-
2001
- 2001-06-28 JP JP2001195684A patent/JP4895437B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2002157156A (ja) | 2002-05-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7321907B2 (en) | Method and system for managing multiple database storage units | |
| US10997148B2 (en) | Processing transactions on journaled tables | |
| Antonopoulos et al. | Socrates: The new sql server in the cloud | |
| US8122284B2 (en) | N+1 failover and resynchronization of data storage appliances | |
| JP5047806B2 (ja) | データ・ウェアハウジングのための装置および方法 | |
| CN100476710C (zh) | 在数据存储器中保持临时数据的系统和方法 | |
| KR100926880B1 (ko) | Ｄｂｍｓ에서의 데이터 복제 방법 및 시스템 | |
| US7334002B2 (en) | System and method for recovery units in databases | |
| CN1746893B (zh) | 事务文件系统 | |
| US7103619B1 (en) | System and method for automatic audit data archiving within a remote database backup system | |
| CN100524235C (zh) | 存储网络中的恢复操作 | |
| US7389313B1 (en) | System and method for creating a snapshot copy of a database | |
| US7263537B1 (en) | System and method for creating multiple QUIESCE database copies at a single server | |
| JP7263297B2 (ja) | ハイブリッドクラウド弾性スケーリングおよび高性能データ仮想化のためのリアルタイムクロスシステムデータベースレプリケーション | |
| CN102906743A (zh) | 混合oltp和olap高性能数据库系统 | |
| JP4895437B2 (ja) | データベース管理方法およびシステム並びにその処理プログラムおよびそのプログラムを格納した記録媒体 | |
| WO2017156855A1 (en) | Database systems with re-ordered replicas and methods of accessing and backing up databases | |
| Siddha | A Persistent Snapshot Device Driver for Linux | |
| CA2618938C (en) | Data consistency control method and software for a distributed replicated database system | |
| Frank | Atomicity implementation in mobile computing | |
| US11914571B1 (en) | Optimistic concurrency for a multi-writer database | |
| Riedel et al. | When local becomes global: An application study of data consistency in a networked world | |
| Tinnefeld | Building a Columnar Database on RAMCloud | |
| Agrawal et al. | ElasTraS: An Elastic, Scalable, and Self Managing Transactional Database for the Cloud | |
| Pacheco | Using Data Guard for Disaster Recovery & Rolling Upgrades |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050317 |
|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20060418 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080617 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080808 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080909 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20081110 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20081216 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090213 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20090303 |
|
| A912 | Re-examination (zenchi) completed and case transferred to appeal board |
Free format text: JAPANESE INTERMEDIATE CODE: A912 Effective date: 20090410 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20111021 |
|
| 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: 20111220 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20150106 Year of fee payment: 3 |
|
| LAPS | Cancellation because of no payment of annual fees |