JP2002157156A - データベース管理方法およびシステム並びにその処理プログラムおよびそのプログラムを格納した記録媒体 - Google Patents
データベース管理方法およびシステム並びにその処理プログラムおよびそのプログラムを格納した記録媒体Info
- Publication number
- JP2002157156A JP2002157156A JP2001195684A JP2001195684A JP2002157156A JP 2002157156 A JP2002157156 A JP 2002157156A JP 2001195684 A JP2001195684 A JP 2001195684A JP 2001195684 A JP2001195684 A JP 2001195684A JP 2002157156 A JP2002157156 A JP 2002157156A
- Authority
- JP
- Japan
- Prior art keywords
- database
- data
- registered
- area
- stored
- 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.)
- Granted
Links
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
(57)【要約】
【課題】Ｗｅｂ環境に代表されるようにデータベースシ
ステムが２４時間グローバルに世界規模で利用されるよ
うになってくると、データベース稼動停止時間やバッチ
運用時間が確保できない状況がでてくる。 【解決手段】入力されたデータを上記第１のデータベー
スに格納する。設定された条件を満たしたとき、上記第
２のデータベースに登録したデータを管理する管理情報
に基づいて上記第２のデータベースに登録さていないデ
ータを上記第１のデータベースから得る。その得られた
データを上記第２のデータベースへ登録し、該得られた
データについて上記管理情報を更新する。
ステムが２４時間グローバルに世界規模で利用されるよ
うになってくると、データベース稼動停止時間やバッチ
運用時間が確保できない状況がでてくる。 【解決手段】入力されたデータを上記第１のデータベー
スに格納する。設定された条件を満たしたとき、上記第
２のデータベースに登録したデータを管理する管理情報
に基づいて上記第２のデータベースに登録さていないデ
ータを上記第１のデータベースから得る。その得られた
データを上記第２のデータベースへ登録し、該得られた
データについて上記管理情報を更新する。
Description
【０００１】
【発明の属する技術分野】本発明は、複数のデータベー
スを有するデータベース管理技術に関し、あるデータベ
ースの情報を他のデータベースに格納するデータベース
管理技術に関する。
スを有するデータベース管理技術に関し、あるデータベ
ースの情報を他のデータベースに格納するデータベース
管理技術に関する。
【０００２】
【従来の技術】高可用性のソリューションとして、デー
タベース(DB)管理システムを２重化させ、片系がＣＰＵ
ダウン、電源ダウンなどシステム障害の要因でデータベ
ースシステム全体が停止するのを防ぐ目的で、ＨＡ（Hi
gh Availability）システムのように多重化構成などが
考えられる。例えば、文献（Jim Gray and Andreas Reu
ter, Tranzaction Processing: Concepts and Techniqu
es, Morgan Kaufmann Publishers, 1993）にはＨＡシス
テム構成によるＤＢ障害対策としてのホットスタンバイ
無停止運用について開示している。また、データベース
を格納するディスク装置には、高信頼性を保証するため
に、ＲＡＩＤ（Redundant Array of Inexpensive Disk
s）構成を併用することが多い。このＲＡＩＤ構成は、
文献（DavidA. Patterson et. al., A Case for Redund
ant Arrays of Inexpensive Disks(RAID), ACM SIGMOD
1988.）で詳細に開示されている。さらに、分散された
システム間で同一の見方でデータベースをアクセスさせ
る機能として、レプリカＤＢがある。このレプリカＤＢ
技術は、文献（Date, C.J., An Introduction to Datab
ase Systems: Volume 1 Fifth Edition, Addison-Wesle
y Publisher, 1990）で開示されている。
タベース(DB)管理システムを２重化させ、片系がＣＰＵ
ダウン、電源ダウンなどシステム障害の要因でデータベ
ースシステム全体が停止するのを防ぐ目的で、ＨＡ（Hi
gh Availability）システムのように多重化構成などが
考えられる。例えば、文献（Jim Gray and Andreas Reu
ter, Tranzaction Processing: Concepts and Techniqu
es, Morgan Kaufmann Publishers, 1993）にはＨＡシス
テム構成によるＤＢ障害対策としてのホットスタンバイ
無停止運用について開示している。また、データベース
を格納するディスク装置には、高信頼性を保証するため
に、ＲＡＩＤ（Redundant Array of Inexpensive Disk
s）構成を併用することが多い。このＲＡＩＤ構成は、
文献（DavidA. Patterson et. al., A Case for Redund
ant Arrays of Inexpensive Disks(RAID), ACM SIGMOD
1988.）で詳細に開示されている。さらに、分散された
システム間で同一の見方でデータベースをアクセスさせ
る機能として、レプリカＤＢがある。このレプリカＤＢ
技術は、文献（Date, C.J., An Introduction to Datab
ase Systems: Volume 1 Fifth Edition, Addison-Wesle
y Publisher, 1990）で開示されている。
【０００３】
【発明が解決しようとする課題】しかし、数万ユーザか
ら同時にアクセスされるＷｅｂ環境、あるいは日々分析
データが追加される数十ＴＢからなる大規模なＤＢを管
理するDWHシステムにデータベース管理システムが適用
される現状では、これらのデータベースシステムの運用
につれて大幅に増加・変動するＤＢ量、ユーザ数、負荷
量などに対応することが必須になる。予め、このような
ＤＢ量、ユーザ数、負荷量の増減を加味してＤＢ設計
（データ分割方法、メモリ量、プロセッサ・サーバ数、
ディスク量の配置配分）を行うことも可能ではあるが、
初期的にデータベースシステムを稼動させる時点では増
加量を見込んだ膨大なシステムコストを考慮すると必要
最小限のシステム構成でデータベースシステムを稼動せ
ざるをえない。そのため、ＤＢ量、ユーザ数、負荷量が
増減した時点で、初期時のＤＢ設計を見直し、再構築す
ることになる。従来までは、このようなＤＢ設計方針に
基き、データベースシステムの運用を止め、即ちＤＢサ
ービスを停止させ、データ分割方法、メモリ量、プロセ
ッサ・サーバ数、ディスク量を必要に応じて各々変更し
ていた。
ら同時にアクセスされるＷｅｂ環境、あるいは日々分析
データが追加される数十ＴＢからなる大規模なＤＢを管
理するDWHシステムにデータベース管理システムが適用
される現状では、これらのデータベースシステムの運用
につれて大幅に増加・変動するＤＢ量、ユーザ数、負荷
量などに対応することが必須になる。予め、このような
ＤＢ量、ユーザ数、負荷量の増減を加味してＤＢ設計
（データ分割方法、メモリ量、プロセッサ・サーバ数、
ディスク量の配置配分）を行うことも可能ではあるが、
初期的にデータベースシステムを稼動させる時点では増
加量を見込んだ膨大なシステムコストを考慮すると必要
最小限のシステム構成でデータベースシステムを稼動せ
ざるをえない。そのため、ＤＢ量、ユーザ数、負荷量が
増減した時点で、初期時のＤＢ設計を見直し、再構築す
ることになる。従来までは、このようなＤＢ設計方針に
基き、データベースシステムの運用を止め、即ちＤＢサ
ービスを停止させ、データ分割方法、メモリ量、プロセ
ッサ・サーバ数、ディスク量を必要に応じて各々変更し
ていた。
【０００４】このＤＢサービス停止には、様々な要因が
考えられる。例えば、Ｗｅｂ環境では年々増加するサー
ビス数、Ｗｅｂブラウザなどのクライアントからのアク
セス要求に対して、これらの要求を処理するために必要
とされる処理能力に対応してデータベース管理システム
のサーバの追加が必要になる。また、クライアントへの
サービスを追加することでアプリケーションプログラム
が増えることでデータベースに対する見方が多様になる
ことで、対応する表も増え結果的にＤＢ量も年々増加す
る一方になる。これらのＤＢを格納するディスクの追
加、データ分割方法のスキーマの変更を行うことによっ
て、ＤＢ量の不均衡、ＤＢアクセス負荷の均衡化を図る
ことを考慮する必要がある。さらに、大量のＤＢ削除な
どの操作によるＤＢ構造の乱れにより検索効率の低下を
防ぐために、ＤＢの再編成を定期的に行う必要がある。
考えられる。例えば、Ｗｅｂ環境では年々増加するサー
ビス数、Ｗｅｂブラウザなどのクライアントからのアク
セス要求に対して、これらの要求を処理するために必要
とされる処理能力に対応してデータベース管理システム
のサーバの追加が必要になる。また、クライアントへの
サービスを追加することでアプリケーションプログラム
が増えることでデータベースに対する見方が多様になる
ことで、対応する表も増え結果的にＤＢ量も年々増加す
る一方になる。これらのＤＢを格納するディスクの追
加、データ分割方法のスキーマの変更を行うことによっ
て、ＤＢ量の不均衡、ＤＢアクセス負荷の均衡化を図る
ことを考慮する必要がある。さらに、大量のＤＢ削除な
どの操作によるＤＢ構造の乱れにより検索効率の低下を
防ぐために、ＤＢの再編成を定期的に行う必要がある。
【０００５】これらのＤＢ運用機能は、夜間のデータベ
ースシステム稼動停止あるいは週末のバッチ運用で行わ
れる。ただし、Ｗｅｂ環境に代表されるようにデータベ
ースシステムが２４時間グローバルに世界規模で利用さ
れるようになった現在では、ＤＢ稼動停止時間やバッチ
運用時間が確保できない状況がでてくる。そのため、Ｄ
Ｂサービス無停止でこれらの運用を並行に実現する要求
が強まっている。
ースシステム稼動停止あるいは週末のバッチ運用で行わ
れる。ただし、Ｗｅｂ環境に代表されるようにデータベ
ースシステムが２４時間グローバルに世界規模で利用さ
れるようになった現在では、ＤＢ稼動停止時間やバッチ
運用時間が確保できない状況がでてくる。そのため、Ｄ
Ｂサービス無停止でこれらの運用を並行に実現する要求
が強まっている。
【０００６】このようなデータベース運用機能は、夜間
のデータベースシステム稼動停止あるいは週末のバッチ
運用で行われる。ただし、Ｗｅｂ環境に代表されるよう
にデータベースシステムが２４時間グローバルに世界規
模で利用されるようになってくると、データベース稼動
停止時間やバッチ運用時間が確保できない状況がでてく
る。
のデータベースシステム稼動停止あるいは週末のバッチ
運用で行われる。ただし、Ｗｅｂ環境に代表されるよう
にデータベースシステムが２４時間グローバルに世界規
模で利用されるようになってくると、データベース稼動
停止時間やバッチ運用時間が確保できない状況がでてく
る。
【０００７】本発明の目的は、データベースへのデータ
格納をデータベースサービスと並行して処理するデータ
ベース管理方法およびシステムを提供することにある。
格納をデータベースサービスと並行して処理するデータ
ベース管理方法およびシステムを提供することにある。
【０００８】
【課題を解決するための手段】前記課題を以下の手段に
より解決する。第１のデータベースと第２のデータベー
スとを有するデータベース管理システムにおけるデータ
ベース管理方法において、次のステップを有する。 （１）入力されたデータを上記第１のデータベースに格
納する第１のステップ、（２）設定された条件を満たし
たとき、上記第２のデータベースに登録したデータを管
理する管理情報に基づいて上記第２のデータベースに登
録さていないデータを上記第１のデータベースから得
て、該得られたデータを上記第２のデータベースへ登録
し、該得られたデータについて上記管理情報を更新する
第２のステップこのように、設定された条件により、上
記第２のデータベースに登録したデータを管理する管理
情報に基づいて上記第２のデータベースに登録さていな
いデータを上記第１のデータベースから得て、該得られ
たデータを上記第２のデータベースへ登録することがで
きるため、第２のデータベースへのデータ格納を第１の
データベースサービスと並行して処理することができる
ようになる。
より解決する。第１のデータベースと第２のデータベー
スとを有するデータベース管理システムにおけるデータ
ベース管理方法において、次のステップを有する。 （１）入力されたデータを上記第１のデータベースに格
納する第１のステップ、（２）設定された条件を満たし
たとき、上記第２のデータベースに登録したデータを管
理する管理情報に基づいて上記第２のデータベースに登
録さていないデータを上記第１のデータベースから得
て、該得られたデータを上記第２のデータベースへ登録
し、該得られたデータについて上記管理情報を更新する
第２のステップこのように、設定された条件により、上
記第２のデータベースに登録したデータを管理する管理
情報に基づいて上記第２のデータベースに登録さていな
いデータを上記第１のデータベースから得て、該得られ
たデータを上記第２のデータベースへ登録することがで
きるため、第２のデータベースへのデータ格納を第１の
データベースサービスと並行して処理することができる
ようになる。
【０００９】
【発明の実施の形態】ＤＢのサービス停止には、様々な
要因が考えられる。例えば、Ｗｅｂ環境では年々増加す
るサービス数、Ｗｅｂブラウザなどのクライアントから
のアクセス要求に対して、これらの要求を処理するため
に必要とされる処理能力に対応してデータベース管理シ
ステムのサーバの追加が必要になる。また、クライアン
トへのサービスを追加することでアプリケーションプロ
グラムが増えることでデータベースに対する見方が多様
になることで、対応する表も増え結果的にＤＢ量も年々
増加する一方になる。これらのＤＢを格納するディスク
の追加、データ分割方法のスキーマの変更を行うことに
よって、ＤＢ量の不均衡、ＤＢアクセス負荷の均衡化を
図ることを考慮する必要がある。さらに、大量のＤＢ削
除などの操作によるＤＢ構造の乱れにより検索効率の低
下を防ぐために、ＤＢの再編成を定期的に行う必要があ
る。
要因が考えられる。例えば、Ｗｅｂ環境では年々増加す
るサービス数、Ｗｅｂブラウザなどのクライアントから
のアクセス要求に対して、これらの要求を処理するため
に必要とされる処理能力に対応してデータベース管理シ
ステムのサーバの追加が必要になる。また、クライアン
トへのサービスを追加することでアプリケーションプロ
グラムが増えることでデータベースに対する見方が多様
になることで、対応する表も増え結果的にＤＢ量も年々
増加する一方になる。これらのＤＢを格納するディスク
の追加、データ分割方法のスキーマの変更を行うことに
よって、ＤＢ量の不均衡、ＤＢアクセス負荷の均衡化を
図ることを考慮する必要がある。さらに、大量のＤＢ削
除などの操作によるＤＢ構造の乱れにより検索効率の低
下を防ぐために、ＤＢの再編成を定期的に行う必要があ
る。
【００１０】これらのＤＢ運用機能は、夜間のデータベ
ースシステム稼動停止あるいは週末のバッチ運用で行わ
れる。ただし、Ｗｅｂ環境に代表されるようにデータベ
ースシステムが２４時間グローバルに世界規模で利用さ
れるようになった現在では、ＤＢ稼動停止時間やバッチ
運用時間が確保できない状況がでてくる。そのため、Ｄ
Ｂサービス無停止でこれらの運用を並行に実現する要求
が強まっている。このＤＢサービスを停止させないで、
ＤＢ運用を行うためには、次の課題を解消する必要があ
る。 （ｉ）接続性・拡張性 データベース処理を行うサーバとデータベースを管理す
るストーレジが独立に、しかも自立的にデータ管理が運
用できることにより、サーバあるいはストーレジが稼動
中に接続構成や各サーバ・ストーレジ追加・変更が容易
になる。 （ii）データ共用 複数のサーバ間でストーレジが共用可能であることによ
り、フラットフォームと独立にデータ移動、変換が可能
となる。 （iii）高可用性 破壊されてはならないデータを多重化あるいは離れた場
所にコピーできる。
ースシステム稼動停止あるいは週末のバッチ運用で行わ
れる。ただし、Ｗｅｂ環境に代表されるようにデータベ
ースシステムが２４時間グローバルに世界規模で利用さ
れるようになった現在では、ＤＢ稼動停止時間やバッチ
運用時間が確保できない状況がでてくる。そのため、Ｄ
Ｂサービス無停止でこれらの運用を並行に実現する要求
が強まっている。このＤＢサービスを停止させないで、
ＤＢ運用を行うためには、次の課題を解消する必要があ
る。 （ｉ）接続性・拡張性 データベース処理を行うサーバとデータベースを管理す
るストーレジが独立に、しかも自立的にデータ管理が運
用できることにより、サーバあるいはストーレジが稼動
中に接続構成や各サーバ・ストーレジ追加・変更が容易
になる。 （ii）データ共用 複数のサーバ間でストーレジが共用可能であることによ
り、フラットフォームと独立にデータ移動、変換が可能
となる。 （iii）高可用性 破壊されてはならないデータを多重化あるいは離れた場
所にコピーできる。
【００１１】これらの要件を満たすのが、次世代ＩＴと
して注目を浴びているＳＡＮ（Storage Area Network）
ソリューションである。ＳＡＮソリューションの目指す
目標は、次の４点である。 （ａ）ストーレジ入出力性能の大幅向上（Performance) （ｂ）サーバ環境とは独立した柔軟なストーレジ環境の
設定・拡張（Scalability) （ｃ）ストーレジの一元運用(Storage Management Effi
ciency) （ｄ）接続距離を飛躍的に延ばす事による災害対策(Dat
a Protection) 特に、データベースシステムの拡張性を加味すると、上
記の（ｂ）の特長活かすことが有望である。
して注目を浴びているＳＡＮ（Storage Area Network）
ソリューションである。ＳＡＮソリューションの目指す
目標は、次の４点である。 （ａ）ストーレジ入出力性能の大幅向上（Performance) （ｂ）サーバ環境とは独立した柔軟なストーレジ環境の
設定・拡張（Scalability) （ｃ）ストーレジの一元運用(Storage Management Effi
ciency) （ｄ）接続距離を飛躍的に延ばす事による災害対策(Dat
a Protection) 特に、データベースシステムの拡張性を加味すると、上
記の（ｂ）の特長活かすことが有望である。
【００１２】ここで具体的なデータベースシステムで議
論する。大手小売業販売実績管理システムでは、地域に
展開している各小売店舗の時々刻々の販売履歴情報をＰ
ＯＳ端末などにより集積されている。これらの情報は、
在庫管理、発注管理、商品配送計画などと関連付けられ
ている。また、売れ筋商品分析などの結果を、即時に店
舗内商品配置に反映することも考えられる。そのため
に、ＲＤＢシステムに時系列順に、販売履歴コードなど
からなるレコードをＤＢへ追記中心で反映することでＤ
Ｂを構築して行く。また、ここで蓄積された履歴ＤＢを
ソースにして、多元な分析軸で瞬時にＯＬＡＰ分析が可
能なＯＬＡＰシステムを構築する。このＯＬＡＰシステ
ムは、ＲＤＢシステムで構築された履歴ＤＢを反映する
必要がある。従来技術のレプリカＤＢでは、抽出元のＲ
ＤＢへの更新によって変更された部分を抽出し、これら
を即時あるいはある時間遅れで反映先ＲＤＢへ反映され
る。レプリカＤＢでは、抽出元、反映先ともＲＤＢであ
るので、基本的には同一のデータ（一部ジョインあるい
は複数の表への分類なども含まれる）の複製が作成され
る。ここでのＲＤＢシステムからＯＬＡＰシステムへの
反映方法には、２通りが考えられる。 (a)初期作成 ＲＤＢシステムに構築された全ての履歴ＤＢをデータロ
ードし、ＯＬＡＰシステムへ反映する (b)追加更新 履歴ＤＢで追加更新が行われた部分を、ＯＬＡＰシステ
ムへ追加ロードする典型的な、販売履歴ＤＢに対するＤ
Ｂ諸元及びアクセス特性は、以下のようになる。大手小
売業販売実績から推定から推定すると、７．７Ｍ件／日
の販売実績があり、各実績毎に２００Ｂ〜１ＫＢ長のレ
コードを登録することにより、約４０ＧＢ〜２００ＧＢ
／月の履歴ＤＢ規模になる。年間で約０．４ＴＢ〜２Ｔ
ＢのＤＢが追加されることになる。この履歴ＤＢは、ス
タースキーマを構成し、ＳＱＬの集約問合せにより統計
サマリーを作成する業務で利用されことが多い。
論する。大手小売業販売実績管理システムでは、地域に
展開している各小売店舗の時々刻々の販売履歴情報をＰ
ＯＳ端末などにより集積されている。これらの情報は、
在庫管理、発注管理、商品配送計画などと関連付けられ
ている。また、売れ筋商品分析などの結果を、即時に店
舗内商品配置に反映することも考えられる。そのため
に、ＲＤＢシステムに時系列順に、販売履歴コードなど
からなるレコードをＤＢへ追記中心で反映することでＤ
Ｂを構築して行く。また、ここで蓄積された履歴ＤＢを
ソースにして、多元な分析軸で瞬時にＯＬＡＰ分析が可
能なＯＬＡＰシステムを構築する。このＯＬＡＰシステ
ムは、ＲＤＢシステムで構築された履歴ＤＢを反映する
必要がある。従来技術のレプリカＤＢでは、抽出元のＲ
ＤＢへの更新によって変更された部分を抽出し、これら
を即時あるいはある時間遅れで反映先ＲＤＢへ反映され
る。レプリカＤＢでは、抽出元、反映先ともＲＤＢであ
るので、基本的には同一のデータ（一部ジョインあるい
は複数の表への分類なども含まれる）の複製が作成され
る。ここでのＲＤＢシステムからＯＬＡＰシステムへの
反映方法には、２通りが考えられる。 (a)初期作成 ＲＤＢシステムに構築された全ての履歴ＤＢをデータロ
ードし、ＯＬＡＰシステムへ反映する (b)追加更新 履歴ＤＢで追加更新が行われた部分を、ＯＬＡＰシステ
ムへ追加ロードする典型的な、販売履歴ＤＢに対するＤ
Ｂ諸元及びアクセス特性は、以下のようになる。大手小
売業販売実績から推定から推定すると、７．７Ｍ件／日
の販売実績があり、各実績毎に２００Ｂ〜１ＫＢ長のレ
コードを登録することにより、約４０ＧＢ〜２００ＧＢ
／月の履歴ＤＢ規模になる。年間で約０．４ＴＢ〜２Ｔ
ＢのＤＢが追加されることになる。この履歴ＤＢは、ス
タースキーマを構成し、ＳＱＬの集約問合せにより統計
サマリーを作成する業務で利用されことが多い。
【００１３】また、販売履歴ＤＢをより多次元の軸で動
的に分析する業務ではＯＬＡＰシステムを用い、１８〜
２４ヶ月の履歴データを構築して、販売地区毎、あるい
は商品毎の同月比、月別、期別などで分析を行う必要が
ある。さらに、約３ヶ月の履歴データに８０％以上のア
クセスが集中する特徴もあり、さらにデータの鮮度をよ
り上げるニーズが増えつつある。上記議論したが、この
ＲＤＢシステムとＯＬＡＰシステムのサービスを無停止
で提供されなければならないことは言うまでもない。
的に分析する業務ではＯＬＡＰシステムを用い、１８〜
２４ヶ月の履歴データを構築して、販売地区毎、あるい
は商品毎の同月比、月別、期別などで分析を行う必要が
ある。さらに、約３ヶ月の履歴データに８０％以上のア
クセスが集中する特徴もあり、さらにデータの鮮度をよ
り上げるニーズが増えつつある。上記議論したが、この
ＲＤＢシステムとＯＬＡＰシステムのサービスを無停止
で提供されなければならないことは言うまでもない。
【００１４】ＤＢサービスを無停止で時系列、販売履歴
コードなどにより追記中心の履歴ＤＢを対象にしたＯＬ
ＡＰ分析業務をＲＤＢ業務を停止せずに構築（初期作
成、追加更新）するためには、次の課題を解決する必要
がある。 (1)ＲＤＢシステムで追加更新するデータベース領域と
ＯＬＡＰシステムへ初期作成、追加ロードするデータベ
ース領域が重なるために、ＲＤＢシステム及びＯＬＡＰ
システムでアクセスが競合するため、ＲＤＢシステム側
のシステム性能が低下する。 (2)ＯＬＡＰ分析業務では、最近のデータへのアクセス
の８０％が集中し、しかもＯＬＡＰシステムへの追加ロ
ードの対象にもなるため、局所的なデータベース領域に
負荷が集中する。
コードなどにより追記中心の履歴ＤＢを対象にしたＯＬ
ＡＰ分析業務をＲＤＢ業務を停止せずに構築（初期作
成、追加更新）するためには、次の課題を解決する必要
がある。 (1)ＲＤＢシステムで追加更新するデータベース領域と
ＯＬＡＰシステムへ初期作成、追加ロードするデータベ
ース領域が重なるために、ＲＤＢシステム及びＯＬＡＰ
システムでアクセスが競合するため、ＲＤＢシステム側
のシステム性能が低下する。 (2)ＯＬＡＰ分析業務では、最近のデータへのアクセス
の８０％が集中し、しかもＯＬＡＰシステムへの追加ロ
ードの対象にもなるため、局所的なデータベース領域に
負荷が集中する。
【００１５】これらの課題を解消するために、次の解決
方法を考える。
方法を考える。
【００１６】アクセスするデータベース領域が競合する
ため生じる課題に対しては、次の解決方法を考える。 (a)データベース格納領域を分離 ＲＤＢシステムでアクセスするデータベース領域はデー
タ追加と参照が主であり、ＯＬＡＰサーバへ追加ロード
し反映するため読み出しのみであることに着目すれば、
ディスク装置の多重化機能あるいはＯＳが提供するディ
スク２重書きを利用することにより、物理的にデータベ
ース領域を複数もつことで対応する。このデータベース
領域は書き込みの同期が取られていることが前提であ
る。正Ｖｏｌ（データ追加と参照あり）と副Ｖｏｌ（指
定時刻で整合性があるＤＢ）の内容が異なり、しかも物
理的に隔絶することでアクセス負荷を分ける。 (b)データベース管理システムの更新履歴情報システム
ログの利用 データベース管理システムでは、ＤＢ障害回復のために
更新履歴情報システムログを保持している。即ち、この
システムログにはデータベースシステムへの全更新情報
が含まれているので、ある時点からの更新情報を抽出す
ることが可能である。ＯＬＡＰサーバへ追加ロードし反
映するためには、このシステムログから抽出した該当す
る履歴ＤＢ表に関するデータを作成することができる。 (c)ＯＬＡＰサーバへの反映部分を局所化する方法 データベースをキー値範囲、ハッシュ分割などにより分
割する手法が行われているが、最近のデータを細分化
し、かつ８０％のアクセスが集中するため並列化効果を
高めるため、多段の階層分割を採用する。即ち、ＯＬＡ
Ｐサーバへ追加ロードする対象のデータは、時系列的に
は最近に集まる特性を持つため、時間的に近いデータを
上記の分割手法を用いて分割区間として局所化する。こ
れによって、ＲＤＢシステムの負荷を最小限にさせ、追
加ロードのための読み出しが可能となる。
ため生じる課題に対しては、次の解決方法を考える。 (a)データベース格納領域を分離 ＲＤＢシステムでアクセスするデータベース領域はデー
タ追加と参照が主であり、ＯＬＡＰサーバへ追加ロード
し反映するため読み出しのみであることに着目すれば、
ディスク装置の多重化機能あるいはＯＳが提供するディ
スク２重書きを利用することにより、物理的にデータベ
ース領域を複数もつことで対応する。このデータベース
領域は書き込みの同期が取られていることが前提であ
る。正Ｖｏｌ（データ追加と参照あり）と副Ｖｏｌ（指
定時刻で整合性があるＤＢ）の内容が異なり、しかも物
理的に隔絶することでアクセス負荷を分ける。 (b)データベース管理システムの更新履歴情報システム
ログの利用 データベース管理システムでは、ＤＢ障害回復のために
更新履歴情報システムログを保持している。即ち、この
システムログにはデータベースシステムへの全更新情報
が含まれているので、ある時点からの更新情報を抽出す
ることが可能である。ＯＬＡＰサーバへ追加ロードし反
映するためには、このシステムログから抽出した該当す
る履歴ＤＢ表に関するデータを作成することができる。 (c)ＯＬＡＰサーバへの反映部分を局所化する方法 データベースをキー値範囲、ハッシュ分割などにより分
割する手法が行われているが、最近のデータを細分化
し、かつ８０％のアクセスが集中するため並列化効果を
高めるため、多段の階層分割を採用する。即ち、ＯＬＡ
Ｐサーバへ追加ロードする対象のデータは、時系列的に
は最近に集まる特性を持つため、時間的に近いデータを
上記の分割手法を用いて分割区間として局所化する。こ
れによって、ＲＤＢシステムの負荷を最小限にさせ、追
加ロードのための読み出しが可能となる。
【００１７】また、ＲＤＢシステムからＯＬＡＰシステ
ムへデータを反映する場合、あるデータベースとして整
合の取れた状態でＯＬＡＰ分析ができることが要求され
る。即ち、ある時点でのデータベースとして整合が取れ
たデータをＲＤＢシステムからＯＬＡＰシステムへ見せ
ることが必要となる。この課題を解消するために、次の
手段を適用する。 (a)ＲＤＢシステムのデータベースを時系列順で分割管
理 時系列順で分割管理するため、追加ロードする対象のデ
ータアクセス範囲を局所化可能である。ＲＤＢシステム
側では、以前どこまでの時系列範囲をＯＬＡＰシステム
側に反映したかを把握すれば、今回どの時系列範囲を追
加ロードすればよいかが判定できる。 (b)システムログ情報を基にデータ反映 ＲＤＢシステムではデータベースへの更新反映情報をシ
ステムログとして維持管理している。ＯＬＡＰシステム
へ追加ロードするデータは、このシステムログ情報から
該当する履歴ＤＢ表のある時点からの更新履歴を抽出す
ればよい。
ムへデータを反映する場合、あるデータベースとして整
合の取れた状態でＯＬＡＰ分析ができることが要求され
る。即ち、ある時点でのデータベースとして整合が取れ
たデータをＲＤＢシステムからＯＬＡＰシステムへ見せ
ることが必要となる。この課題を解消するために、次の
手段を適用する。 (a)ＲＤＢシステムのデータベースを時系列順で分割管
理 時系列順で分割管理するため、追加ロードする対象のデ
ータアクセス範囲を局所化可能である。ＲＤＢシステム
側では、以前どこまでの時系列範囲をＯＬＡＰシステム
側に反映したかを把握すれば、今回どの時系列範囲を追
加ロードすればよいかが判定できる。 (b)システムログ情報を基にデータ反映 ＲＤＢシステムではデータベースへの更新反映情報をシ
ステムログとして維持管理している。ＯＬＡＰシステム
へ追加ロードするデータは、このシステムログ情報から
該当する履歴ＤＢ表のある時点からの更新履歴を抽出す
ればよい。
【００１８】上記のＳＡＮソリューションと組み合わせ
ることにより、ＤＢ処理を行うサーバとＤＢを格納する
ストーレジが光ファイバなどの高速なネットワークを介
して接続されるため、サーバとストーレジとの共用関係
や接続に関するマッピング情報を変更するのみで動的な
サーバ追加、ディスク追加などが容易に運用できる。さ
らに、各ストーレジはＲＡＩＤディスクを利用するた
め、多重化による信頼性の確保とともにＤＢ運用でワー
クとして必要な領域を動的なデバイスとして割当て、解
除などの機能を利用することにより、通常業務を停止し
ないでＤＢ再編成運用ができる。具体的には、サーバ及
びディスクを追加することでＤＢシステムの規模を拡大
する、即ちスケーラブルなシステムが構築できる。
ることにより、ＤＢ処理を行うサーバとＤＢを格納する
ストーレジが光ファイバなどの高速なネットワークを介
して接続されるため、サーバとストーレジとの共用関係
や接続に関するマッピング情報を変更するのみで動的な
サーバ追加、ディスク追加などが容易に運用できる。さ
らに、各ストーレジはＲＡＩＤディスクを利用するた
め、多重化による信頼性の確保とともにＤＢ運用でワー
クとして必要な領域を動的なデバイスとして割当て、解
除などの機能を利用することにより、通常業務を停止し
ないでＤＢ再編成運用ができる。具体的には、サーバ及
びディスクを追加することでＤＢシステムの規模を拡大
する、即ちスケーラブルなシステムが構築できる。
【００１９】前記課題を以下の手段により解決する。 （１）ＤＢ分割管理するシステムで、新たに第１のＤＢ
格納領域と第２のＤＢ格納領域を割当て、第１の格納領
域の複写を第２の格納領域に反映し、複写の指示が解除
されると第１の格納領域への書き込みが行われ、再複写
の指示が行われると複写指示が解除された間第１の格納
領域に書き込まれたデータが第２の格納領域に反映され
ること （２）（１）において、複写の指示が解除される間、第
２の格納領域に指定された時刻までトランザクションが
完了したシステムログを第２の格納領域に反映し、第２
の格納領域を読み出すこと。 （３）（１）において、ＤＢ分割管理手法として、キー
レンジ分割、ハッシュ分割、ラウンドロビン分割、及び
それらを多元的に組合せる分割手段を用い、時系列でよ
り最近のデータを細分化してデータ分割すること。 （４）（１）において、第１のＤＢ格納領域と第２のＤ
Ｂ格納領域を割当てるデータベース領域は、前回までに
反映された時点以降の時系列でより最近のデータを格納
するデータベース領域であること。 （５）ＤＢ分割管理するシステムで、第１のＤＢ格納領
域を割当て、第１の格納領域への書き込み履歴であるシ
ステムログから前回まで反映された時点以降の該当する
データを読み出すこと。
格納領域と第２のＤＢ格納領域を割当て、第１の格納領
域の複写を第２の格納領域に反映し、複写の指示が解除
されると第１の格納領域への書き込みが行われ、再複写
の指示が行われると複写指示が解除された間第１の格納
領域に書き込まれたデータが第２の格納領域に反映され
ること （２）（１）において、複写の指示が解除される間、第
２の格納領域に指定された時刻までトランザクションが
完了したシステムログを第２の格納領域に反映し、第２
の格納領域を読み出すこと。 （３）（１）において、ＤＢ分割管理手法として、キー
レンジ分割、ハッシュ分割、ラウンドロビン分割、及び
それらを多元的に組合せる分割手段を用い、時系列でよ
り最近のデータを細分化してデータ分割すること。 （４）（１）において、第１のＤＢ格納領域と第２のＤ
Ｂ格納領域を割当てるデータベース領域は、前回までに
反映された時点以降の時系列でより最近のデータを格納
するデータベース領域であること。 （５）ＤＢ分割管理するシステムで、第１のＤＢ格納領
域を割当て、第１の格納領域への書き込み履歴であるシ
ステムログから前回まで反映された時点以降の該当する
データを読み出すこと。
【００２０】以下、本発明の実施例を図面を用いて詳細
に説明する。時系列、販売履歴コードなどにより追記中
心の履歴ＤＢを対象にしたＯＬＡＰ分析業務をＲＤＢ業
務を停止せずに構築（初期作成、追加更新）する。ＤＢ
分割管理は、ＤＢ障害の局所化、バックアップ単位の細
分化手段として適用されていたが、追記によるＤＢ量の
変動、及びＯＬＡＰサーバへの反映部分を局所化する方
法として適用する。
に説明する。時系列、販売履歴コードなどにより追記中
心の履歴ＤＢを対象にしたＯＬＡＰ分析業務をＲＤＢ業
務を停止せずに構築（初期作成、追加更新）する。ＤＢ
分割管理は、ＤＢ障害の局所化、バックアップ単位の細
分化手段として適用されていたが、追記によるＤＢ量の
変動、及びＯＬＡＰサーバへの反映部分を局所化する方
法として適用する。
【００２１】図ｌは、ＲＤＢシステムからＯＬＡＰシス
テムへデータを反映する全体構成を示してる。ＲＤＢシ
ステムは、アプリケーションプログラム１０、１１、及
びデータ抽出部２００を含むデータベース管理システム
２０で構成されている。また、ＯＬＡＰシステムは、ア
プリケーションプログラム１１、１２、及びデータ反映
部６００を含むＯＬＡＰサーバシステム６０で構成され
ている。ＲＤＢシステム及びＯＬＡＰシステムのデータ
ベースは、ＳＡＮを介して接続されている。ＲＤＢシス
テムのデータベースは、エリアに分割されており、図３
で示すようにエリア１の３００、エリア２の３０１、エ
リア３の３０２、エリア４の３０３、エリア５１の３０
４、エリア５２の３０５、エリア５３の３０６に各々格
納されている。エリア５１の３０４、エリア５２の３０
５、エリア５３の３０６は、正Ｖｏｌとして格納管理さ
れているが、ディスク２重書き機能を有する場合、エリ
ア５１の３０７、エリア５２の３０８、エリア５３の３
０９に副Ｖｏｌが格納管理される。ＯＬＡＰシステムの
データベースは、エリアに分割されており、エリア１の
７００、エリア２の７０１、エリア３の７０２に格納管
理される。
テムへデータを反映する全体構成を示してる。ＲＤＢシ
ステムは、アプリケーションプログラム１０、１１、及
びデータ抽出部２００を含むデータベース管理システム
２０で構成されている。また、ＯＬＡＰシステムは、ア
プリケーションプログラム１１、１２、及びデータ反映
部６００を含むＯＬＡＰサーバシステム６０で構成され
ている。ＲＤＢシステム及びＯＬＡＰシステムのデータ
ベースは、ＳＡＮを介して接続されている。ＲＤＢシス
テムのデータベースは、エリアに分割されており、図３
で示すようにエリア１の３００、エリア２の３０１、エ
リア３の３０２、エリア４の３０３、エリア５１の３０
４、エリア５２の３０５、エリア５３の３０６に各々格
納されている。エリア５１の３０４、エリア５２の３０
５、エリア５３の３０６は、正Ｖｏｌとして格納管理さ
れているが、ディスク２重書き機能を有する場合、エリ
ア５１の３０７、エリア５２の３０８、エリア５３の３
０９に副Ｖｏｌが格納管理される。ＯＬＡＰシステムの
データベースは、エリアに分割されており、エリア１の
７００、エリア２の７０１、エリア３の７０２に格納管
理される。
【００２２】ＲＤＢシステムでデータ更新されるとデー
タベース管理システム２０によってデータベースへ書き
込まれる。この例では、正Ｖｏｌであるエリア５１の３
０４、エリア５２の３０５、エリア５３の３０６に書き
込まれる。正Ｖｏｌへの書き込みは、バックグラウンド
で副Ｖｏｌへ書き込みとなる。ＲＤＢシステムからＯＬ
ＡＰシステムへのデータ反映は、データベース管理シス
テム２０のデータ抽出部２００及びＯＬＡＰサーバシス
テム６０のデータ反映部６００を介して行われる。ＯＬ
ＡＰサーバシステム６０は、ＲＤＢシステムから反映さ
れたデータを分割スキーマに基きエリア１の７００、エ
リア２の７０１、エリア３の７０２に格納する。
タベース管理システム２０によってデータベースへ書き
込まれる。この例では、正Ｖｏｌであるエリア５１の３
０４、エリア５２の３０５、エリア５３の３０６に書き
込まれる。正Ｖｏｌへの書き込みは、バックグラウンド
で副Ｖｏｌへ書き込みとなる。ＲＤＢシステムからＯＬ
ＡＰシステムへのデータ反映は、データベース管理シス
テム２０のデータ抽出部２００及びＯＬＡＰサーバシス
テム６０のデータ反映部６００を介して行われる。ＯＬ
ＡＰサーバシステム６０は、ＲＤＢシステムから反映さ
れたデータを分割スキーマに基きエリア１の７００、エ
リア２の７０１、エリア３の７０２に格納する。
【００２３】図２は、データベース管理システム２０の
構成図である。ユーザが作成したアプリケーションプロ
グラム１０、１１と問合せ処理やリソース管理などのデ
ータベースシステム全体の管理を行うデータベース管理
システム２０がある。上記のデータベース管理システム
２０は、システム制御２１、論理処理部２２、物理処理
部２３と、データベースアクセス対象となるデータを永
続的にあるいは一時的に格納するデータベース３０・デ
ィクショナリ５０・システムログ４０からなる。また、
上記データベース管理システム２０はネットワークなど
を介して他のシステムと接続されている。
構成図である。ユーザが作成したアプリケーションプロ
グラム１０、１１と問合せ処理やリソース管理などのデ
ータベースシステム全体の管理を行うデータベース管理
システム２０がある。上記のデータベース管理システム
２０は、システム制御２１、論理処理部２２、物理処理
部２３と、データベースアクセス対象となるデータを永
続的にあるいは一時的に格納するデータベース３０・デ
ィクショナリ５０・システムログ４０からなる。また、
上記データベース管理システム２０はネットワークなど
を介して他のシステムと接続されている。
【００２４】ＳＡＮ構成のシステムでは、上記データベ
ース３０・ディクショナリ５０・システムログ４０の全
体あるいは一部分がＳＡＮ８０を介してディスク装置に
格納されている。この場合、ディクショナリ５０にはデ
ータベース３０を各エリアにどのスキーマ分割手法で分
割したか、あるいはエリアと正副Ｖｏｌのマッピングな
どについて設定している。表定義文、表変更文などによ
り、このディクショナリ５０情報を更新することでデー
タベース管理システム、ＯＬＡＰサーバシステムなどサ
ーバシステム側とＳＡＮを介して接続されたディスク装
置内のスキーマ分割されたデータベースの格納部分とな
るエリアやこれらのエリアと対応付く正副Ｖｏｌなどス
トーレジ側とのマッピングが設定、更新される。
ース３０・ディクショナリ５０・システムログ４０の全
体あるいは一部分がＳＡＮ８０を介してディスク装置に
格納されている。この場合、ディクショナリ５０にはデ
ータベース３０を各エリアにどのスキーマ分割手法で分
割したか、あるいはエリアと正副Ｖｏｌのマッピングな
どについて設定している。表定義文、表変更文などによ
り、このディクショナリ５０情報を更新することでデー
タベース管理システム、ＯＬＡＰサーバシステムなどサ
ーバシステム側とＳＡＮを介して接続されたディスク装
置内のスキーマ分割されたデータベースの格納部分とな
るエリアやこれらのエリアと対応付く正副Ｖｏｌなどス
トーレジ側とのマッピングが設定、更新される。
【００２５】上記システム制御２１は、ユーザからの問
合せ入力、問合せ結果の返却、データロード・データ再
編成・再構成コマンドなど受付によるデータベース保
守、他システムとの連携制御などを行う。上記論理処理
部２２は、問合せの構文解析・意味解析を行う問合せ解
析２２０と、適切な処理手順を生成する最適化処理２２
１と、処理手順に対応したコードの生成を行うコード生
成２２２とを具備している。また、上記生成されたコー
ドに基きコードの解釈実行を行うコード解釈実行２２３
を具備している。さらに、表定義コマンド、表変更コマ
ンド、エリア−Ｖｏｌマッピング・コマンド、正副Ｖｏ
ｌ制御コマンドなどコマンド解析実行を行うコマンド解
析２２５を具備している。上記物理処理部２３は、アク
セスしたデータの条件判定、編集、レコード追加などを
実現するデータアクセス制御２３０と、データベースレ
コードの読み書きなどのアクセス制御を行うデータベー
スバッファ制御２３１と、システムで共用するリソース
の排他制御２３２とを具備している。さらに、データベ
ース３０の読み出し及び書き込みはデータベースバッフ
ァ２４を介して行われる。システムログ４０は、データ
ベース３０へのデータ挿入、更新、削除などの更新履歴
情報を蓄積する。ディクショナリ５０は、データベース
３０の表、インデクスなどデータベース・スキーマ情
報、データベース３０のデータ分割方法、格納管理する
領域名称、ページサイズなどの格納情報からなる。ま
た、データ分割方法の変更などのコマンドが実行される
と、ディクショナリ５０が変更される。
合せ入力、問合せ結果の返却、データロード・データ再
編成・再構成コマンドなど受付によるデータベース保
守、他システムとの連携制御などを行う。上記論理処理
部２２は、問合せの構文解析・意味解析を行う問合せ解
析２２０と、適切な処理手順を生成する最適化処理２２
１と、処理手順に対応したコードの生成を行うコード生
成２２２とを具備している。また、上記生成されたコー
ドに基きコードの解釈実行を行うコード解釈実行２２３
を具備している。さらに、表定義コマンド、表変更コマ
ンド、エリア−Ｖｏｌマッピング・コマンド、正副Ｖｏ
ｌ制御コマンドなどコマンド解析実行を行うコマンド解
析２２５を具備している。上記物理処理部２３は、アク
セスしたデータの条件判定、編集、レコード追加などを
実現するデータアクセス制御２３０と、データベースレ
コードの読み書きなどのアクセス制御を行うデータベー
スバッファ制御２３１と、システムで共用するリソース
の排他制御２３２とを具備している。さらに、データベ
ース３０の読み出し及び書き込みはデータベースバッフ
ァ２４を介して行われる。システムログ４０は、データ
ベース３０へのデータ挿入、更新、削除などの更新履歴
情報を蓄積する。ディクショナリ５０は、データベース
３０の表、インデクスなどデータベース・スキーマ情
報、データベース３０のデータ分割方法、格納管理する
領域名称、ページサイズなどの格納情報からなる。ま
た、データ分割方法の変更などのコマンドが実行される
と、ディクショナリ５０が変更される。
【００２６】次に、販売履歴表を時系列で分割する一実
施例として、データベース分割方法としてキーレンジ分
割手法を用いる。データベース分割方法には、キーレン
ジ分割手法以外にハッシュ分割手法、ラウンドロビン分
割手法、及びこれらの手法を多元的に組合せる手法など
があり、これらを分割手法として適用することは可能で
ある。図３は、販売履歴表を時系列で分割して管理して
いる。販売履歴表は、年度、半期、月毎で分割管理され
ている。具体的には、９７年度はエリア１の３００、９
８年度はエリア２の３０１、９９年度第１四半期はエリ
ア３の３０２、９９年度第二四半期はエリア４の３０
３、９９年度７月分はエリア５１の３０４、９９年度８
月分はエリア５２の３０５、９９年度９月分はエリア５
３の３０６に格納されている。この場合、ディクショナ
リ５０には、各々キーレンジ区間とその区間に対応する
エリア名が設定される。
施例として、データベース分割方法としてキーレンジ分
割手法を用いる。データベース分割方法には、キーレン
ジ分割手法以外にハッシュ分割手法、ラウンドロビン分
割手法、及びこれらの手法を多元的に組合せる手法など
があり、これらを分割手法として適用することは可能で
ある。図３は、販売履歴表を時系列で分割して管理して
いる。販売履歴表は、年度、半期、月毎で分割管理され
ている。具体的には、９７年度はエリア１の３００、９
８年度はエリア２の３０１、９９年度第１四半期はエリ
ア３の３０２、９９年度第二四半期はエリア４の３０
３、９９年度７月分はエリア５１の３０４、９９年度８
月分はエリア５２の３０５、９９年度９月分はエリア５
３の３０６に格納されている。この場合、ディクショナ
リ５０には、各々キーレンジ区間とその区間に対応する
エリア名が設定される。
【００２７】例えば、このデータベース分割は次の表定
義文で実行される。 CREATE TABLE 販売履歴表 (購買コード CHAR(16), 商品コード CHAR(16), 地域コード CHAR(16), 時刻コード DATE, 売上げ額 DEC(10) ) IN ( (エリア１) 時刻コード>='1997-12', (エリア２) 時刻コード>='1998-12', (エリア３) 時刻コード>='1999-03', (エリア４) 時刻コード>='1999-06', (エリア５１) 時刻コード>='1999-07', (エリア５２) 時刻コード>='1999-08', (エリア５３) 時刻コード>='1999-09' ); また、この例では、９９年度第三四半期に対してエリア
が割当てられていないが、９９年度９月分にデータ反映
し終えた時点で、各々９９年度７、８、９月分に割当て
られているエリア５１の３０４、エリア５２の３０５、
エリア５３の３０６を併合し、エリア５として管理され
る。
義文で実行される。 CREATE TABLE 販売履歴表 (購買コード CHAR(16), 商品コード CHAR(16), 地域コード CHAR(16), 時刻コード DATE, 売上げ額 DEC(10) ) IN ( (エリア１) 時刻コード>='1997-12', (エリア２) 時刻コード>='1998-12', (エリア３) 時刻コード>='1999-03', (エリア４) 時刻コード>='1999-06', (エリア５１) 時刻コード>='1999-07', (エリア５２) 時刻コード>='1999-08', (エリア５３) 時刻コード>='1999-09' ); また、この例では、９９年度第三四半期に対してエリア
が割当てられていないが、９９年度９月分にデータ反映
し終えた時点で、各々９９年度７、８、９月分に割当て
られているエリア５１の３０４、エリア５２の３０５、
エリア５３の３０６を併合し、エリア５として管理され
る。
【００２８】図４は、９９年度９月分にデータ反映し終
えた時点でのデータベース分割方法の変更を行う場合の
表変更文の実行を示す。エリア５１の３０４、エリア５
２の３０５の分割区間で管理されていたデータベースを
エリア５３の３０６を含め、エリア５の３０７とする表
変更文は次のようになる。 ALTER TABLE 販売履歴表 MERGE AREA (エリア５１,エリア５２,エリア５３) INTO ( (エリア５) 時刻コード>='1999-09'); この表変更文によって、ディクショナリ５０には、各々
キーレンジ区間とその区間に対応するエリア５１、エリ
ア５２、エリア５３エリア名が、エリア５に変更され、
設定される。
えた時点でのデータベース分割方法の変更を行う場合の
表変更文の実行を示す。エリア５１の３０４、エリア５
２の３０５の分割区間で管理されていたデータベースを
エリア５３の３０６を含め、エリア５の３０７とする表
変更文は次のようになる。 ALTER TABLE 販売履歴表 MERGE AREA (エリア５１,エリア５２,エリア５３) INTO ( (エリア５) 時刻コード>='1999-09'); この表変更文によって、ディクショナリ５０には、各々
キーレンジ区間とその区間に対応するエリア５１、エリ
ア５２、エリア５３エリア名が、エリア５に変更され、
設定される。
【００２９】図５は、論理処理部２２の処理フローであ
る。表定義文及び表変更文などのコマンド解析実行、問
合せ解析、問合せ実行は、この論理処理部２２で実現さ
れる。ユーザから入力されたコマンドが、解析要求、実
行要求、あるいはコマンド解析実行であるか確認される
（２２５）。解析要求であれば、問合せ解析（２２
０）、最適化処理（２２１）、コード生成（２２２）が
行われる。また、実行要求であれば、コード解釈実行が
行われる（２２３）。さらに、コマンド解析実行要求で
あれば、コマンド解析が行われる（２２４）。表定義コ
マンドであれば（２２６）、表のデータベース分割方
法、各エリア名への対応付けなどをディクショナリ５０
へ登録する（２２７）。表定義コマンドであれば（２２
８）、表のデータベース分割方法の変更及び各エリアの
追加、削除、併合、分割などに応じてディクショナリ５
０へ登録する。エリア−Ｖｏｌマッピング・コマンドで
あれば（２３０）、各エリアに対応する正副Ｖｏｌ情報
をディクシュナリ５０へ登録する。正副Ｖｏｌ制御コマ
ンドであれば（２３２）、正副Ｖｏｌへの切り離し指
示、再接続指示を該当するディスク装置へ発行する（２
３３）。
る。表定義文及び表変更文などのコマンド解析実行、問
合せ解析、問合せ実行は、この論理処理部２２で実現さ
れる。ユーザから入力されたコマンドが、解析要求、実
行要求、あるいはコマンド解析実行であるか確認される
（２２５）。解析要求であれば、問合せ解析（２２
０）、最適化処理（２２１）、コード生成（２２２）が
行われる。また、実行要求であれば、コード解釈実行が
行われる（２２３）。さらに、コマンド解析実行要求で
あれば、コマンド解析が行われる（２２４）。表定義コ
マンドであれば（２２６）、表のデータベース分割方
法、各エリア名への対応付けなどをディクショナリ５０
へ登録する（２２７）。表定義コマンドであれば（２２
８）、表のデータベース分割方法の変更及び各エリアの
追加、削除、併合、分割などに応じてディクショナリ５
０へ登録する。エリア−Ｖｏｌマッピング・コマンドで
あれば（２３０）、各エリアに対応する正副Ｖｏｌ情報
をディクシュナリ５０へ登録する。正副Ｖｏｌ制御コマ
ンドであれば（２３２）、正副Ｖｏｌへの切り離し指
示、再接続指示を該当するディスク装置へ発行する（２
３３）。
【００３０】図６は、ディスク２重書きの原理を示す。
以下の説明で、ディスク２重書き機能を適用するため、
ここで開示する。ディスク装置へ正副Ｖｏｌ対を設け２
重に書き込む場合、ディスク２重書き機能が存在するか
否かで動作が異なる。
以下の説明で、ディスク２重書き機能を適用するため、
ここで開示する。ディスク装置へ正副Ｖｏｌ対を設け２
重に書き込む場合、ディスク２重書き機能が存在するか
否かで動作が異なる。
【００３１】ディスク２重書き機能が存在しない場合
（(a)）、データベースバッファ管理２３１から正Ｖｏ
ｌのエリア２の３０及び副Ｖｏｌのエリア２の３１に対
して、各ディスク装置に書き込み要求が発行される。即
ち、ソフトウェア的に２つのディスク装置上で同一のデ
ータを常に保持することになる。
（(a)）、データベースバッファ管理２３１から正Ｖｏ
ｌのエリア２の３０及び副Ｖｏｌのエリア２の３１に対
して、各ディスク装置に書き込み要求が発行される。即
ち、ソフトウェア的に２つのディスク装置上で同一のデ
ータを常に保持することになる。
【００３２】また、ディスク２重書き機能が存在する場
合（(b)）、データベースバッファ管理２３１から正Ｖ
ｏｌのエリア２の３０に対して書き込み要求が発行され
る。ディスク２重書き機能を有するディスク装置では、
正Ｖｏｌのエリア２の３０と副Ｖｏｌのエリア２の３１
の対応付けを指定されており、この対応付けにより正Ｖ
ｏｌのエリア２の３０への書き込みを副Ｖｏｌのエリア
２の３１の書き込みとして反映させる。即ち、ディスク
装置側の機能としてハードウェア的に２つのディスク装
置上で同一のデータを常に保持することになる。
合（(b)）、データベースバッファ管理２３１から正Ｖ
ｏｌのエリア２の３０に対して書き込み要求が発行され
る。ディスク２重書き機能を有するディスク装置では、
正Ｖｏｌのエリア２の３０と副Ｖｏｌのエリア２の３１
の対応付けを指定されており、この対応付けにより正Ｖ
ｏｌのエリア２の３０への書き込みを副Ｖｏｌのエリア
２の３１の書き込みとして反映させる。即ち、ディスク
装置側の機能としてハードウェア的に２つのディスク装
置上で同一のデータを常に保持することになる。
【００３３】さらに、正Ｖｏｌのエリア２の３０及び副
Ｖｏｌのエリア２の３１を次のエリア−Ｖｏｌマッピン
グ文で定義させる。 CREATE AREA エリア２ AS PRIMARY 正ボリューム２ SECONDARY 副ボリューム２; このエリア−Ｖｏｌマッピング文によって、ディクショ
ナリ５０には、各々エリアとそのエリアに対応する正Ｖ
ｏｌ名「正ボリューム２」、副Ｖｏｌ名「副ボリューム
２」が設定される。
Ｖｏｌのエリア２の３１を次のエリア−Ｖｏｌマッピン
グ文で定義させる。 CREATE AREA エリア２ AS PRIMARY 正ボリューム２ SECONDARY 副ボリューム２; このエリア−Ｖｏｌマッピング文によって、ディクショ
ナリ５０には、各々エリアとそのエリアに対応する正Ｖ
ｏｌ名「正ボリューム２」、副Ｖｏｌ名「副ボリューム
２」が設定される。
【００３４】図７は、データベースバッファ管理２３１
のフロー詳細である。データアクセス処理２３０でデー
タベースのページへの読み書き要求があると呼び出され
る。まず、データベースバッファ上に該当するページが
存在するか否かを確認する（２３１０）。存在すれば、
該当バッファ位置を通知し終了する（２３１１）。存在
しなければ、該当するページをデータベースバッファに
読み込むために、替わりに掃き出すべきページを決定す
る（２３１２）。ページを書き出す場合、ディスク装置
に２重書き機能があるか否かを確認する（２３１３）。
２重書き機能が存在すれば、ディスク装置の正Ｖｏｌに
書き込み要求を発行し（２３１５）、ディスク装置の正
Ｖｏｌ内容を副Ｖｏｌに反映する（２３１６）。２重書
き機能が存在しなければ、ＯＳなどの手段でディスク装
置の正副Ｖｏｌ対に対してそれぞれ書き込み要求を発行
する（２３１４）。その次、空いたデータベースバッフ
ァに要求ページを読み込み（２３１７）、終了する。次
に、ＲＤＢシステムからＯＬＡＰシステムへデータ反映
する一実施例を示す。
のフロー詳細である。データアクセス処理２３０でデー
タベースのページへの読み書き要求があると呼び出され
る。まず、データベースバッファ上に該当するページが
存在するか否かを確認する（２３１０）。存在すれば、
該当バッファ位置を通知し終了する（２３１１）。存在
しなければ、該当するページをデータベースバッファに
読み込むために、替わりに掃き出すべきページを決定す
る（２３１２）。ページを書き出す場合、ディスク装置
に２重書き機能があるか否かを確認する（２３１３）。
２重書き機能が存在すれば、ディスク装置の正Ｖｏｌに
書き込み要求を発行し（２３１５）、ディスク装置の正
Ｖｏｌ内容を副Ｖｏｌに反映する（２３１６）。２重書
き機能が存在しなければ、ＯＳなどの手段でディスク装
置の正副Ｖｏｌ対に対してそれぞれ書き込み要求を発行
する（２３１４）。その次、空いたデータベースバッフ
ァに要求ページを読み込み（２３１７）、終了する。次
に、ＲＤＢシステムからＯＬＡＰシステムへデータ反映
する一実施例を示す。
【００３５】まず、ディスク２重化する場合とシステム
ログベースのデータ反映する場合に分けられる。さら
に、ディスク２重化する場合も、ディスク２重書き機能
の有無で分けられる。各々の場合について、以下では図
８、９、１０で説明する。
ログベースのデータ反映する場合に分けられる。さら
に、ディスク２重化する場合も、ディスク２重書き機能
の有無で分けられる。各々の場合について、以下では図
８、９、１０で説明する。
【００３６】図８は、ディスク２重書きなしの場合であ
る。これば、図６の（ａ）に相当し、ソフトウェア的に
ディスク２重化を実現している。まず、（ｉ）指定時刻
データ作成フェーズとして、副Ｖｏｌに指定時刻で整合
が取れたデータベース状態を作成する。データベースバ
ッファ２３１から副Ｖｏｌのエリア２の３１への書き込
みが抑止される。次に、データ抽出部２００がシステム
ログ４０から指定時刻までにトランザクションが完了し
たデータベースとするために、システムログ情報を時系
列で反映する。次に、（ii）データ抽出反映フェーズと
して、データ抽出部２００が副Ｖｏｌのエリア２の３１
からデータを抽出して、データ反映部６００を介しＯＬ
ＡＰサーバシステムのスキーマ分割方法に従いエリア１
の７００、エリア２の７０１、エリアｍの７０２へデー
タ登録される。さらに、（iii）正副Ｖｏｌ再接続フェ
ーズとして、上記（ｉ）、（ii）のフェーズ実行中に正
Ｖｏｌのエリア２の３０に書き込まれた状態と副Ｖｏｌ
のエリア２の３１の状態との整合を保つため、データ抽
出部２００がシステムログ４０から現時点までの最新の
データベースとするために、システムログ情報を時系列
で反映する。
る。これば、図６の（ａ）に相当し、ソフトウェア的に
ディスク２重化を実現している。まず、（ｉ）指定時刻
データ作成フェーズとして、副Ｖｏｌに指定時刻で整合
が取れたデータベース状態を作成する。データベースバ
ッファ２３１から副Ｖｏｌのエリア２の３１への書き込
みが抑止される。次に、データ抽出部２００がシステム
ログ４０から指定時刻までにトランザクションが完了し
たデータベースとするために、システムログ情報を時系
列で反映する。次に、（ii）データ抽出反映フェーズと
して、データ抽出部２００が副Ｖｏｌのエリア２の３１
からデータを抽出して、データ反映部６００を介しＯＬ
ＡＰサーバシステムのスキーマ分割方法に従いエリア１
の７００、エリア２の７０１、エリアｍの７０２へデー
タ登録される。さらに、（iii）正副Ｖｏｌ再接続フェ
ーズとして、上記（ｉ）、（ii）のフェーズ実行中に正
Ｖｏｌのエリア２の３０に書き込まれた状態と副Ｖｏｌ
のエリア２の３１の状態との整合を保つため、データ抽
出部２００がシステムログ４０から現時点までの最新の
データベースとするために、システムログ情報を時系列
で反映する。
【００３７】図９は、ディスク２重書きありの場合であ
る。これば、図６の（ｂ）に相当し、ディスク装置で具
備するディスク２重化を前提としている。まず、（ｉ）
指定時刻データ作成フェーズとして、副Ｖｏｌに指定時
刻で整合が取れたデータベース状態を作成する。正Ｖｏ
ｌのエリア２の３０から副Ｖｏｌのエリア２の３１への
書き込みが抑止されると同時に、正Ｖｏｌのエリア２の
３０への書き込み情報は差分情報３０００に反されるよ
う設定される。次に、データ抽出部２００がシステムロ
グ４０から指定時刻までにトランザクションが完了した
データベースとするために、システムログ情報を時系列
で反映する。次に、（ii）データ抽出反映フェーズとし
て、データ抽出部２００が副Ｖｏｌのエリア２の３１か
らデータを抽出して、データ反映部６００を介しＯＬＡ
Ｐサーバシステムのスキーマ分割方法に従いエリア１の
７００、エリア２の７０１、エリアｍの７０２へデータ
登録される。さらに、（iii）正副Ｖｏｌ再接続フェー
ズとして、上記（ｉ）、（ii）のフェーズ実行中に正Ｖ
ｏｌのエリア２の３０に書き込まれた状態と副Ｖｏｌの
エリア２の３１の状態との整合を保つため、差分情報３
０００が副Ｖｏｌのエリア２の３１へ反映され現時点ま
での最新のデータベースとなる。
る。これば、図６の（ｂ）に相当し、ディスク装置で具
備するディスク２重化を前提としている。まず、（ｉ）
指定時刻データ作成フェーズとして、副Ｖｏｌに指定時
刻で整合が取れたデータベース状態を作成する。正Ｖｏ
ｌのエリア２の３０から副Ｖｏｌのエリア２の３１への
書き込みが抑止されると同時に、正Ｖｏｌのエリア２の
３０への書き込み情報は差分情報３０００に反されるよ
う設定される。次に、データ抽出部２００がシステムロ
グ４０から指定時刻までにトランザクションが完了した
データベースとするために、システムログ情報を時系列
で反映する。次に、（ii）データ抽出反映フェーズとし
て、データ抽出部２００が副Ｖｏｌのエリア２の３１か
らデータを抽出して、データ反映部６００を介しＯＬＡ
Ｐサーバシステムのスキーマ分割方法に従いエリア１の
７００、エリア２の７０１、エリアｍの７０２へデータ
登録される。さらに、（iii）正副Ｖｏｌ再接続フェー
ズとして、上記（ｉ）、（ii）のフェーズ実行中に正Ｖ
ｏｌのエリア２の３０に書き込まれた状態と副Ｖｏｌの
エリア２の３１の状態との整合を保つため、差分情報３
０００が副Ｖｏｌのエリア２の３１へ反映され現時点ま
での最新のデータベースとなる。
【００３８】図１０は、システムログベースのデータ反
映する場合である。まず、前回までにデータ反映したシ
ステムログ・ポイントを取得する。このシステムログ・
ポイントは、指定時刻を表したものである。次に、当該
システムログ・ポイント以降で、指定された時刻までの
システムログをデータ反映する。基本的には、システム
ログは時系列順に蓄積されているので、この順にデータ
反映すればよい。具体的には、システムログ４０からデ
ータを抽出して、データ反映部６００を介しＯＬＡＰサ
ーバシステムのスキーマ分割方法に従いエリア１の７０
０、エリア２の７０１、エリアｍの７０２へデータ登録
される。
映する場合である。まず、前回までにデータ反映したシ
ステムログ・ポイントを取得する。このシステムログ・
ポイントは、指定時刻を表したものである。次に、当該
システムログ・ポイント以降で、指定された時刻までの
システムログをデータ反映する。基本的には、システム
ログは時系列順に蓄積されているので、この順にデータ
反映すればよい。具体的には、システムログ４０からデ
ータを抽出して、データ反映部６００を介しＯＬＡＰサ
ーバシステムのスキーマ分割方法に従いエリア１の７０
０、エリア２の７０１、エリアｍの７０２へデータ登録
される。
【００３９】上記のデータ抽出及びデータ反映の詳細フ
ローを示す。図１１は、データ抽出部２００のフローで
ある。システムログベースのデータ反映か否かをか確認
する（２００１）。システムログベースのデータ反映で
あれば、前回までにデータ反映したシステムログ・ポイ
ントを取得し通知する（２００２）。次に、当該システ
ムログ・ポイント以降で、指定された時刻までのシステ
ムログ情報をデータ反映する（２００３）。システムロ
グベースのデータ反映でなければ、ディスク装置に２重
書き機能が存在するか否かを確認する（２００４）。
ローを示す。図１１は、データ抽出部２００のフローで
ある。システムログベースのデータ反映か否かをか確認
する（２００１）。システムログベースのデータ反映で
あれば、前回までにデータ反映したシステムログ・ポイ
ントを取得し通知する（２００２）。次に、当該システ
ムログ・ポイント以降で、指定された時刻までのシステ
ムログ情報をデータ反映する（２００３）。システムロ
グベースのデータ反映でなければ、ディスク装置に２重
書き機能が存在するか否かを確認する（２００４）。
【００４０】ディスク装置に２重書き機能が存在すれ
ば、ディスク装置の正Ｖｏｌと副Ｖｏｌとのデータ反映
同期関係を切り離す（２００５）と同時に、正Ｖｏｌへ
の書き込み内容を差分情報３０００へ反映するモードに
ディスク装置を設定する（２００６）。次に、システム
ログを基にして、副Ｖｏｌを指定時刻までにトランザク
ションが完了したデータベース状態にするため、システ
ムログ情報を反映する（２００７）。さらに、副Ｖｏｌ
の内容を抽出し、データ反映する（２００８）。最後
に、上記ステップで正Ｖｏｌに書き込まれた状態と副Ｖ
ｏｌの状態との整合を保つため、差分情報３０００を副
Ｖｏｌに反映し（２００９）、ディスク装置の正Ｖｏｌ
と副Ｖｏｌとを再接続する（２０１０）。
ば、ディスク装置の正Ｖｏｌと副Ｖｏｌとのデータ反映
同期関係を切り離す（２００５）と同時に、正Ｖｏｌへ
の書き込み内容を差分情報３０００へ反映するモードに
ディスク装置を設定する（２００６）。次に、システム
ログを基にして、副Ｖｏｌを指定時刻までにトランザク
ションが完了したデータベース状態にするため、システ
ムログ情報を反映する（２００７）。さらに、副Ｖｏｌ
の内容を抽出し、データ反映する（２００８）。最後
に、上記ステップで正Ｖｏｌに書き込まれた状態と副Ｖ
ｏｌの状態との整合を保つため、差分情報３０００を副
Ｖｏｌに反映し（２００９）、ディスク装置の正Ｖｏｌ
と副Ｖｏｌとを再接続する（２０１０）。
【００４１】ディスク装置に２重書き機能が存在しなけ
れば、ＯＳなど手段でのディスク装置への正Ｖｏｌのみ
の書き込みモードとし、副Ｖｏｌへの書き込みを抑止す
る（２０１１）。次に、システムログを基にして、副Ｖ
ｏｌを指定時刻までにトランザクションが完了したデー
タベース状態にするため、システムログ情報を反映する
（２０１２）。さらに、副Ｖｏｌの内容を抽出し、デー
タ反映する（２０１３）。最後に、上記ステップで正Ｖ
ｏｌに書き込まれた状態と副Ｖｏｌの状態との整合を保
ち、現時点までの最新のデータベースとするために、シ
ステムログ情報を副Ｖｏｌに反映し（２０１４）、正副
Ｖｏｌ書き込みモードに戻す（２０１５）。
れば、ＯＳなど手段でのディスク装置への正Ｖｏｌのみ
の書き込みモードとし、副Ｖｏｌへの書き込みを抑止す
る（２０１１）。次に、システムログを基にして、副Ｖ
ｏｌを指定時刻までにトランザクションが完了したデー
タベース状態にするため、システムログ情報を反映する
（２０１２）。さらに、副Ｖｏｌの内容を抽出し、デー
タ反映する（２０１３）。最後に、上記ステップで正Ｖ
ｏｌに書き込まれた状態と副Ｖｏｌの状態との整合を保
ち、現時点までの最新のデータベースとするために、シ
ステムログ情報を副Ｖｏｌに反映し（２０１４）、正副
Ｖｏｌ書き込みモードに戻す（２０１５）。
【００４２】図１２は、データ反映部６００のフローで
ある。データ抽出部２００からのデータを受け取り（６
０００）、初期作成、追加ロードを行い、分割スキーマ
に従い、各エリアへデータを登録する（６００１）。ま
た、ＯＬＡＰシステムにデータ反映された内容に基づ
き、管理情報９０００を更新する（６００２）。
ある。データ抽出部２００からのデータを受け取り（６
０００）、初期作成、追加ロードを行い、分割スキーマ
に従い、各エリアへデータを登録する（６００１）。ま
た、ＯＬＡＰシステムにデータ反映された内容に基づ
き、管理情報９０００を更新する（６００２）。
【００４３】図１３に示す公知技術のレプリカＤＢ方式
とＲＤＢ−ＯＬＡＰ連携方式についての差異を開示す
る。レプリカＤＢ方式は、抽出元のＲＤＢ３０１への更
新によって変更された部分を抽出し、これらを即時ある
いはある時間遅れで反映先ＲＤＢ３０２へ反映させる。
レプリカＤＢでは、抽出元、反映先ともＲＤＢであるの
で、基本的には同一のデータ（一部ジョインあるいは複
数の表への分類なども含まれる）の複製が作成される。
従って、反映先ＲＤＢ３０２のデータを問合せでアクセ
スする場合、特別に抽出元ＲＤＢ３０１との関連性を考
慮することはない。一方、ＲＤＢ−ＯＬＡＰ連携方式
は、ＲＤＢシステムへの更新によって変更された部分を
抽出し、これらを即時あるいはある時間遅れでＯＬＡＰ
システムへ反映される。ＲＤＢ−ＯＬＡＰ連携方式で
は、ＯＬＡＰシステムを問合せでアクセスする場合、Ｏ
ＬＡＰシステムで管理するデータ３０１とＲＤＢ−ＯＬ
ＡＰ連携で管理される管理情報９０００（反映までの時
間隔、時刻、地域区分、顧客区分など）との組合せで意
味を持つ。事実に関するデータを管理するのがＲＤＢシ
ステムであり、それらから導き出せるトレンド分析結果
などを引き出すのがＯＬＡＰシステムであるため、分析
業務の前提条件は上記の管理情報９０００から導出され
ることになる。例えば、顧客購買分析では、時間隔・時
刻などの時系列、販売された商品の地域別売上げ、商品
を買った顧客の分類に基づき、様々な分析軸で評価する
必要がある。その中で時系列をベースにすると、前年
比、四半期比、先週比、前日比などの尺度で分析するた
めには、分析対象となるＯＬＡＰシステムのデータ７０
１が、事実情報が蓄積管理されているＲＤＢシステムか
ら上記尺度に従って適切に反映されていなければならな
い。即ち、ＯＬＡＰシステムへの問合せでは、これらの
尺度を反映した管理情報とＯＬＡＰシステムのデータ７
０１とで始めて意味ある結果が得られることとなる。
とＲＤＢ−ＯＬＡＰ連携方式についての差異を開示す
る。レプリカＤＢ方式は、抽出元のＲＤＢ３０１への更
新によって変更された部分を抽出し、これらを即時ある
いはある時間遅れで反映先ＲＤＢ３０２へ反映させる。
レプリカＤＢでは、抽出元、反映先ともＲＤＢであるの
で、基本的には同一のデータ（一部ジョインあるいは複
数の表への分類なども含まれる）の複製が作成される。
従って、反映先ＲＤＢ３０２のデータを問合せでアクセ
スする場合、特別に抽出元ＲＤＢ３０１との関連性を考
慮することはない。一方、ＲＤＢ−ＯＬＡＰ連携方式
は、ＲＤＢシステムへの更新によって変更された部分を
抽出し、これらを即時あるいはある時間遅れでＯＬＡＰ
システムへ反映される。ＲＤＢ−ＯＬＡＰ連携方式で
は、ＯＬＡＰシステムを問合せでアクセスする場合、Ｏ
ＬＡＰシステムで管理するデータ３０１とＲＤＢ−ＯＬ
ＡＰ連携で管理される管理情報９０００（反映までの時
間隔、時刻、地域区分、顧客区分など）との組合せで意
味を持つ。事実に関するデータを管理するのがＲＤＢシ
ステムであり、それらから導き出せるトレンド分析結果
などを引き出すのがＯＬＡＰシステムであるため、分析
業務の前提条件は上記の管理情報９０００から導出され
ることになる。例えば、顧客購買分析では、時間隔・時
刻などの時系列、販売された商品の地域別売上げ、商品
を買った顧客の分類に基づき、様々な分析軸で評価する
必要がある。その中で時系列をベースにすると、前年
比、四半期比、先週比、前日比などの尺度で分析するた
めには、分析対象となるＯＬＡＰシステムのデータ７０
１が、事実情報が蓄積管理されているＲＤＢシステムか
ら上記尺度に従って適切に反映されていなければならな
い。即ち、ＯＬＡＰシステムへの問合せでは、これらの
尺度を反映した管理情報とＯＬＡＰシステムのデータ７
０１とで始めて意味ある結果が得られることとなる。
【００４４】図１４は、ＯＬＡＰ問合せ処理部９００の
詳細フローである。まず、ＯＬＡＰ問合せの解析処理を
行い、その問合せの結果としてアクセスするべきＯＬＡ
Ｐシステムのデータ７０１を決定する（９０１）。次
に、ＯＬＡＰシステムへのデータ反映状況を設定してい
る管理情報９０００を読み出し、問合せ結果で必要とな
るデータを作成する（９０２）。最後に、ＯＬＡＰシス
テムのデータ７０１をアクセスし、管理情報９０００と
マージすることで問合せへの結果として返却する（９０
３）。
詳細フローである。まず、ＯＬＡＰ問合せの解析処理を
行い、その問合せの結果としてアクセスするべきＯＬＡ
Ｐシステムのデータ７０１を決定する（９０１）。次
に、ＯＬＡＰシステムへのデータ反映状況を設定してい
る管理情報９０００を読み出し、問合せ結果で必要とな
るデータを作成する（９０２）。最後に、ＯＬＡＰシス
テムのデータ７０１をアクセスし、管理情報９０００と
マージすることで問合せへの結果として返却する（９０
３）。
【００４５】図１５は、システムログの構成内容であ
る。システムログは、ログシーケンス番号、タイムスタ
ンプ、ログ種別、ログ内容から構成される。ログシーケ
ンス番号は、ＲＤＢシステムでユニークとなる識別子が
割り当てられる。タイムスタンプは、当該システムログ
に関するイベントが発生した時刻を記録するために設定
される。ログ種別は、抽出反映処理の開始（event_star
t）、抽出反映処理の中断（event_suspend）、抽出反映
処理の再開（event_restart）、データのコミット（eve
nt_commit）、データの更新（event_update）、データ
の抽出反映（event_reflect）がある。ログ内容は、デ
ータベースへの更新履歴情報を記録する。これらのシス
テムログを基にして、ＲＤＢシステムからＯＬＡＰシス
テムへの抽出反映処理の制御を行うことができる。
る。システムログは、ログシーケンス番号、タイムスタ
ンプ、ログ種別、ログ内容から構成される。ログシーケ
ンス番号は、ＲＤＢシステムでユニークとなる識別子が
割り当てられる。タイムスタンプは、当該システムログ
に関するイベントが発生した時刻を記録するために設定
される。ログ種別は、抽出反映処理の開始（event_star
t）、抽出反映処理の中断（event_suspend）、抽出反映
処理の再開（event_restart）、データのコミット（eve
nt_commit）、データの更新（event_update）、データ
の抽出反映（event_reflect）がある。ログ内容は、デ
ータベースへの更新履歴情報を記録する。これらのシス
テムログを基にして、ＲＤＢシステムからＯＬＡＰシス
テムへの抽出反映処理の制御を行うことができる。
【００４６】本発明は、密結合／疎結合マルチプロセッ
サシステム、大型計算機のソフトウェアシステムを介し
て実現することも、また各処理部のために専用プロセッ
サが用意された密結合／疎結合マルチプロセッサシステ
ムを介して実現することも可能である。さらに、単一の
プロセッサシステムでも各々システム稼動にためにプロ
セスを割当ててあれば適用可能である。複数のプロセッ
サが各々複数のディスクをお互いに共用する構成にも適
用可能である。なお、前述したフローチャートの処理
は、図２に示したような一般的なデータ処理装置でプロ
グラムを実行することによって実現できる。また、その
プログラムは、ハードディスク装置、フロッピー（登録
商標）ディスクなどのコンピュータで読み書きができる
記憶媒体に格納することができ、ネットワークを通して
プログラムにアクセスすることができる。
サシステム、大型計算機のソフトウェアシステムを介し
て実現することも、また各処理部のために専用プロセッ
サが用意された密結合／疎結合マルチプロセッサシステ
ムを介して実現することも可能である。さらに、単一の
プロセッサシステムでも各々システム稼動にためにプロ
セスを割当ててあれば適用可能である。複数のプロセッ
サが各々複数のディスクをお互いに共用する構成にも適
用可能である。なお、前述したフローチャートの処理
は、図２に示したような一般的なデータ処理装置でプロ
グラムを実行することによって実現できる。また、その
プログラムは、ハードディスク装置、フロッピー（登録
商標）ディスクなどのコンピュータで読み書きができる
記憶媒体に格納することができ、ネットワークを通して
プログラムにアクセスすることができる。
【００４７】
【発明の効果】本発明によれば、データベースへのデー
タ反映をデータベースサービスと並行して処理すること
が可能となる。
タ反映をデータベースサービスと並行して処理すること
が可能となる。
【図１】データベースシステムにおけるデータ抽出格納
処理の概要を示す概念図
処理の概要を示す概念図
【図２】本発明の実施例におけるデータベース管理シス
テムの構成を示す概略図
テムの構成を示す概略図
【図３】表定義時のスキーマ分割方法を適用した場合の
構成図
構成図
【図４】表変更時のスキーマ分割方法を適用した場合の
構成図
構成図
【図５】論理処理部の詳細フローの構成図
【図６】ディスク２重書き機能の構成図
【図７】データベースバッファ管理の詳細フローの構成
図
図
【図８】ディスク２重書き機能なしの場合のデータ抽出
格納方法の構成図
格納方法の構成図
【図９】ディスク２重書き機能ありの場合のデータ抽出
格納方法の構成図
格納方法の構成図
【図１０】システムログベースのデータ抽出格納方法の
構成図
構成図
【図１１】データ抽出部の詳細フローの構成図
【図１２】データ格納部の詳細フローの構成図
【図１３】ＲＤＢ−ＯＬＡＰ連携方式の従来の概念図
【図１４】ＯＬＡＰ問合せ処理部の詳細フローの構成図
【図１５】システムログの構成図
１０、１１、１２、１３…アプリケーションプログラム ２０…データベース管理システム ３０…データベース ４０…システムログ ５０…ディクショナリ ６０…ＯＬＡＰサーバシステム ８０…ＳＡＮ
フロントページの続き (51)Int.Cl.7 識別記号 ＦＩ テーマコート゛(参考） Ｇ０６Ｆ 17/30 ２４０ Ｇ０６Ｆ 17/30 ２４０Ａ (72)発明者 山下 信之 神奈川県川崎市幸区鹿島田890番地 株式 会社日立製作所ビジネスソリューション事 業部内 Ｆターム(参考） 5B075 KK03 NR02 PR03 5B082 DE04 GA04 5B085 AC05 AC12 AC14
Claims (20)
- 【請求項１】第１のデータベースと第２のデータベース
とを有するデータベース管理システムにおけるデータベ
ース管理方法において、 入力されたデータを上記第１のデータベースに格納する
第１のステップと、設定された条件を満たしたとき、上
記第２のデータベースに登録したデータを管理する管理
情報に基づいて上記第２のデータベースに登録さていな
いデータを上記第１のデータベースから得て、該得られ
たデータを上記第２のデータベースへ登録し、該得られ
たデータについて上記管理情報を更新する第２のステッ
プとを有することを特徴とするデータベース管理方法。 - 【請求項２】請求項１記載のデータベース管理方法にお
いて、 上記第１のステップは、上記第１のデータベースにデー
タを登録するときに、該データが登録されたことを示す
システムログを作成し、 上記第２のステップは、設定された条件を満たしたと
き、上記第２のデータベースに登録したデータを管理す
る管理情報に基づいて上記第２のデータベースに登録さ
ていないデータをシステムログから得て、該得られたデ
ータを上記第２のデータベースへ登録し、該得られたデ
ータについて上記管理情報を更新することを特徴とする
データベース管理方法。 - 【請求項３】請求項１記載のデータベース管理方法にお
いて、 上記条件は、所定時刻であることを特徴とするデータベ
ース管理方法。 - 【請求項４】請求項１記載のデータベース管理方法にお
いて、 上記条件は、所定時間であることを特徴とするデータベ
ース管理方法。 - 【請求項５】請求項１記載のデータベース管理方法にお
いて、 上記条件は、上記得られたデータを上記第２のデータベ
ースへ登録する処理の終了であることを特徴とするデー
タベース管理方法。 - 【請求項６】請求項１記載のデータベース管理方法にお
いて、 上記第２のステップは、上記得られたデータを記憶領域
に複数格納し、該格納されたデータを上記第２のデータ
ベースへ登録することを特徴とするデータベース管理方
法。 - 【請求項７】請求項１記載のデータベース管理方法にお
いて、 上記条件は、上記複数の得られたデータを上記第２のデ
ータベースへ登録する処理の終了であることを特徴とす
るデータベース管理方法。 - 【請求項８】第１のデータベースと第２のデータベース
と有するデータベース管理システムにおけるデータベー
ス管理システムにおいて、 入力されたデータを上記第１のデータベースに格納する
第１の手段と、設定された条件をしたとき、上記第２の
データベースに登録したデータを管理する管理情報に基
づいて上記第２のデータベースに登録さていないデータ
を上記第１のデータベースから得て、該得られたデータ
を上記第２のデータベースへ登録し、該得られたデータ
について上記管理情報を更新する第２の手段とを有する
ことを特徴とするデータベース管理システム。 - 【請求項９】請求項１記載のデータベース管理システム
において、 上記第１の手段は、上記第１のデータベースにデータを
登録するときに、該データが登録されたことを示すシス
テムログを作成し、 上記第２の手段は、設定された条件を満たしたとき、上
記第２のデータベースに登録したデータを管理する管理
情報に基づいて上記第２のデータベースに登録さていな
いデータをシステムログから得て、該得られたデータを
上記第２のデータベースへ登録し、該得られたデータに
ついて上記管理情報を更新することを特徴とするデータ
ベース管理システム。 - 【請求項１０】請求項１記載のデータベース管理システ
ムにおいて、 上記条件は、所定時刻であることを特徴とするデータベ
ース管理システム。 - 【請求項１１】請求項１記載のデータベース管理システ
ムにおいて、 上記条件は、所定時間であることを特徴とするデータベ
ース管理システム。 - 【請求項１２】請求項１記載のデータベース管理システ
ムにおいて、 上記条件は、上記得られたデータを上記第２のデータベ
ースへ登録する処理の終了であることを特徴とするデー
タベース管理システム。 - 【請求項１３】請求項１記載のデータベース管理システ
ムにおいて、 上記第２の手段は、上記得られたデータを記憶領域に複
数格納し、該格納されたデータを上記第２のデータベー
スへ登録することを特徴とするデータベース管理方法。 - 【請求項１４】請求項１記載のデータベース管理システ
ムにおいて、 上記条件は、上記複数の得られたデータを上記第２のデ
ータベースへ登録する処理の終了であることを特徴とす
るデータベース管理システム。 - 【請求項１５】第１のデータベースと第２のデータベー
スと有するデータベース管理システムにおけるデータベ
ース管理プログラムを格納した計算機読み取り可能な記
憶媒体において、 入力されたデータを上記第１のデータベースに格納する
第１のステップと、設定された条件を満たしたとき、上
記第２のデータベースに登録したデータを管理する管理
情報に基づいて上記第２のデータベースに登録さていな
いデータを上記第１のデータベースから得て、該得られ
たデータを上記第２のデータベースへ登録し、該得られ
たデータについて上記管理情報を更新する第２のステッ
プとを有するデータベース管理プログラムを格納したこ
とを特徴とする計算機読み取り可能な記憶媒体。 - 【請求項１６】第１のデータベースと第２のデータベー
スと有するデータベース管理システムにおけるデータベ
ース管理プログラムを格納した計算機読み取り可能な記
憶媒体において、 入力されたデータを上記第１のデータベースに格納する
第１のステップと、設定された条件を満たしたとき、上
記第２のデータベースに登録したデータを管理する管理
情報に基づいて上記第２のデータベースに登録さていな
いデータを上記第１のデータベースから得て、該得られ
たデータを上記第２のデータベースへ登録し、該得られ
たデータについて上記管理情報を更新する第２のステッ
プとを有するデータベース管理プログラム。 - 【請求項１７】第１のデータベース格納領域と第２のデ
ータベース格納領域を割当て、第１の格納領域に格納さ
れたデータの複写を第２の格納領域に格納し、上記複写
の指示が解除の要求を入力したとき第１の格納領域への
データの書き込みを行い、再複写の要求を入力したとき
上記複写指示解除の間に第１の格納領域に書き込まれた
データを第２の格納領域に格納することを特徴とするデ
ータベース管理方法。 - 【請求項１８】第１のデータベース格納領域と第２のデ
ータベース格納領域を割当て、第１の格納領域への書き
込み履歴であるシステムログから前回まで格納された時
点以降の該当するデータを第２の格納領域に格納するこ
とを特徴とするデータベース管理方法。 - 【請求項１９】第１の記憶手段と、第２の記憶手段と、
第１の記憶手段に格納されたデータの複写を第２の記憶
手段に格納し、上記複写の指示が解除の要求を入力した
とき第１の記憶手段へのデータの書き込みを行い、再複
写の要求を入力したとき上記複写指示解除の間に第１の
記憶手段に書き込まれたデータを第２の記憶手段に格納
するコントローラとを備えたことを特徴とするデータベ
ース管理システム。 - 【請求項２０】第１の記憶手段と第２の記憶手段と、第
１の記憶手段への書き込み履歴であるシステムログから
前回まで格納された時点以降の該当するデータを第２の
記憶手段に格納するコントローラとを備えたこと特徴と
するデータベース管理システム。
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 true JP2002157156A (ja) | 2002-05-31 |
| JP4895437B2 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) |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2005108187A (ja) * | 2003-09-26 | 2005-04-21 | Microsoft Corp | アクティビティの複数のインスタンスに関する情報を維持する方法 |
| JP2007507811A (ja) * | 2003-09-30 | 2007-03-29 | ヴェリタス・オペレーティング・コーポレーション | データ・ストレージ内の時相データを維持するためのシステムおよび方法 |
| JP2008117300A (ja) * | 2006-11-07 | 2008-05-22 | Mitsubishi Electric Corp | 検索装置、データ処理装置および検索方法 |
| JP2009505281A (ja) * | 2005-08-19 | 2009-02-05 | マイクロソフト コーポレーション | データベースフラグメントのクローン化および管理 |
| JP2009230706A (ja) * | 2008-03-25 | 2009-10-08 | Fujitsu Ltd | 情報記憶システム |
| JP2013517585A (ja) * | 2010-01-20 | 2013-05-16 | アリババ グループ ホールディング リミテッド | データベース内の大容量コレクションオブジェクトテーブルにアクセスするための方法 |
| WO2016157492A1 (ja) * | 2015-04-02 | 2016-10-06 | 株式会社日立製作所 | 共有リソース更新装置及び共有リソース更新方法 |
-
2001
- 2001-06-28 JP JP2001195684A patent/JP4895437B2/ja not_active Expired - Fee Related
Cited By (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2005108187A (ja) * | 2003-09-26 | 2005-04-21 | Microsoft Corp | アクティビティの複数のインスタンスに関する情報を維持する方法 |
| JP2010262670A (ja) * | 2003-09-26 | 2010-11-18 | Microsoft Corp | アクティビティの複数のインスタンスに関する情報を維持する方法 |
| 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 |
| JP2007507811A (ja) * | 2003-09-30 | 2007-03-29 | ヴェリタス・オペレーティング・コーポレーション | データ・ストレージ内の時相データを維持するためのシステムおよび方法 |
| JP2009505281A (ja) * | 2005-08-19 | 2009-02-05 | マイクロソフト コーポレーション | データベースフラグメントのクローン化および管理 |
| JP2008117300A (ja) * | 2006-11-07 | 2008-05-22 | Mitsubishi Electric Corp | 検索装置、データ処理装置および検索方法 |
| JP2009230706A (ja) * | 2008-03-25 | 2009-10-08 | Fujitsu Ltd | 情報記憶システム |
| JP2013517585A (ja) * | 2010-01-20 | 2013-05-16 | アリババ グループ ホールディング リミテッド | データベース内の大容量コレクションオブジェクトテーブルにアクセスするための方法 |
| WO2016157492A1 (ja) * | 2015-04-02 | 2016-10-06 | 株式会社日立製作所 | 共有リソース更新装置及び共有リソース更新方法 |
| JPWO2016157492A1 (ja) * | 2015-04-02 | 2017-11-24 | 株式会社日立製作所 | 共有リソース更新装置及び共有リソース更新方法 |
| US10838949B2 (en) | 2015-04-02 | 2020-11-17 | Hitachi, Ltd. | Shared resource update apparatus and shared resource update method |
Also Published As
| Publication number | Publication date |
|---|---|
| JP4895437B2 (ja) | 2012-03-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7321907B2 (en) | Method and system for managing multiple database storage units | |
| US10997148B2 (en) | Processing transactions on journaled tables | |
| JP7263297B2 (ja) | ハイブリッドクラウド弾性スケーリングおよび高性能データ仮想化のためのリアルタイムクロスシステムデータベースレプリケーション | |
| KR101323500B1 (ko) | 데이터 웨어하우징을 위한 장치 및 방법 | |
| US7334002B2 (en) | System and method for recovery units in databases | |
| US8122284B2 (en) | N+1 failover and resynchronization of data storage appliances | |
| KR100926880B1 (ko) | Ｄｂｍｓ에서의 데이터 복제 방법 및 시스템 | |
| JP4586019B2 (ja) | 非故障ノードによる並列な回復 | |
| CN1746893B (zh) | 事务文件系统 | |
| EP2572296B1 (en) | Hybrid oltp and olap high performance database system | |
| US7263537B1 (en) | System and method for creating multiple QUIESCE database copies at a single server | |
| US20030009473A1 (en) | Method, system, and computer program product for providing an extensible file system for accessing a foreign file system from a local data processing system | |
| CN109739935A (zh) | 数据读取方法、装置、电子设备以及存储介质 | |
| CN102591982A (zh) | 执行增量sql服务器数据库备份的方法和系统 | |
| CN113868028B (zh) | 一种在数据节点上回放日志的方法、数据节点及系统 | |
| JP4895437B2 (ja) | データベース管理方法およびシステム並びにその処理プログラムおよびそのプログラムを格納した記録媒体 | |
| JP4432087B2 (ja) | データベース更新管理システム、プログラムおよび方法 | |
| CA2618938C (en) | Data consistency control method and software for a distributed replicated database system | |
| Team | Distributed Transactions | |
| Tinnefeld | Building a Columnar Database on RAMCloud | |
| Agrawal et al. | ElasTraS: An Elastic, Scalable, and Self Managing Transactional Database for the Cloud | |
| Frank | Electronic commerce: using distributed ERP-systems with approximated ACID properties | |
| Deris et al. | Data replication model for remote procedure call transactions | |
| 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 |