JP4596902B2 - ストレージ管理装置、計算機システム、ストレージ管理方法及びストレージ管理プログラム - Google Patents

Description

本発明は、ワークフローを適用したストレージシステムに関し、特に、データを保存する論理デバイスの属性を動的に変更できる計算機システムに関する。

従来、ワークフロー基づいた電子商取引システムでは、顧客の注文を受けて、注文に応じた商品を集め、配送計画を作成し、配送を終えたら決裁の手続きを行い、出荷及び決済完了のメールを顧客へ送付する、というような一連の処理の流れがある。この一連の処理は、データベース等に格納されているデータ（フォーム）への情報を更新しながら処理が流れる（例えば、特許文献１参照。）。

このフォームは、処理が進むに連れて、セキュリティを確保する必要がある情報、アクセ速度が要求される情報等が追加されていく。
特願２００２−２５９８３９号公報

電子商取引システムにおいて、前記のようにワークフロー（ビジネスプロセスともいう）の処理が進むにつれて、処理対象のデータに要求されるセキュリティやアクセス速度等の属性を変更することが望ましい。この属性はデータ単位では変更することはできず、データを格納する記憶装置（例えば論理デバイス）の属性を変更する必要がある。しかしながら、データを格納する記憶装置の属性を変更するためには、その記憶装置のフォーマット等の処理が必要となり現実的ではない。

本発明は、前記のような問題点に鑑みてなされたものであり、ワークフローに基づいたアプリケーションの処理に応じて、データを格納する記憶装置の属性を動的に変更できる計算機システムを提供する。

本発明は、データを格納するストレージ装置にデータを読み書きするストレージ管理装置であって、ストレージ装置には、異なる属性が設定された複数の論理デバイスを含むデータ格納領域が設けられ、ストレージ管理装置は、受け付けたアクセス要求に基づいて、ストレージ装置にデータを読み書きする読み書き制御部と、論理デバイスの属性を設定する属性制御部と、を備え、属性制御部は、ストレージ装置に格納されたデータの属性の変更契機であって、電子商取引に係る注文記入処理、注文承認処理、決済処理、発注処理及び納品処理を順次実行するアプリケーションプログラムの進行に応じて生成される属性変更契機を検出すると、当該属性変更に係るデータを他の属性の論理デバイスに移動するものであり、属性制御部は、注文記入処理が実行される場合、所定のデータを当該注文記入処理によって更新後、第１の論理デバイスに格納し、注文承認処理が実行される場合、第１の論理デバイスに格納されたデータを当該注文承認処理によって更新後、第１の論理デバイスよりも安全性の高い第２の論理デバイスに格納し、決済処理又は発注処理が実行される場合、第２の論理デバイスに格納されたデータを当該決済処理又は発注処理によって更新し、納品処理が実行される場合、決済処理又は発注処理によって更新されたデータを当該納品処理によって更新後、第１の論理デバイスよりもアクセス速度の高い第３の論理デバイスに格納することを特徴とする。

本発明によると、ストレージシステムの外部からの指示によって、ストレージのデータベース格納領域（論理ユニット）に割り当てられる記憶装置（論理デバイス）を動的に変更することができる。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。

図１は、本発明の実施の形態の計算機システムの処理のブロック図である。

アプリケーションプログラムサーバ（以下、ＡＰサーバ）１０は、データベースにアクセスするアプリケーションプログラム（業務プログラムやプログラム、オブジェクトでもよい）が稼働している。図１の例では、電子商取引を実現するための電子商取引アプリケーションプログラム１０３がＡＰサーバ１０で稼働している。

この電子商取引ＡＰ１０３は、注文記入処理１０３Ａ、注文承認処理１０３Ｂ、決済処理１０３Ｃ、発注処理１０３Ｄ、及び納品処理１０３Ｅの５つの処理からなる。これらの処理が順次実行されることでワークフロー（ビジネスプロセスともいう）が構成される。

データベース管理システム２０は、ＡＰサーバ１０のアプリケーションからの要求に基づいて、ストレージシステム４０に格納されているデータベースにアクセスする。

データベース管理システム２０は、データ更新処理を実行している。

データ更新処理部１５０は、ＡＰサーバ１０のアプリケーションによってＤＢバッファ２０５でのデータベースのデータの更新があるかを監視する。また、更新されたデータがデータベースのどの表のどの列であるかを判定する。

データベース管理システム２０は、カテゴリ変更テーブル２１００、表・ＤＢ領域定義テーブル２２００、及びＤＢ領域情報テーブル２３００を備えている。

カテゴリ変更テーブル２１００は、ＡＰサーバ１０のアプリケーションからの操作の種類、当該操作対象のデータベースのデータの場所（すなわち、データベースの表の列）が格納される。

表・ＤＢ領域定義テーブル２２００は、データベースの表とデータベースの格納領域名とが格納される。

ＤＢ領域情報テーブル２３００は、データベースの格納領域とストレージシステム４０のＬＵ名とが格納される。

ストレージ管理部３０は、データ書き出し処理を実行している。

データ書き出し処理部１６０は、データベース管理システム２０からのストレージシステム４０へのアクセスを受け付けて、当該要求に係る論理ユニット（ＬＵ）は、どの論理デバイス（ＬＤＥＶ）であるかを決定する。そして、受け付けたアクセスのアクセス先を、判定したＬＤＥＶに決定する。

ストレージ管理部３０は、ＬＵカテゴリ管理テーブル３１００、カテゴリ情報テーブル３２００及びＬＤＥＶカテゴリ情報テーブル３３００を備えている。

ＬＵカテゴリ管理テーブル３１００は、ストレージシステム４０が備えているＬＵと、ＬＤＥＶと、カテゴリの変更順序とが格納される。

カテゴリ情報テーブル３２００は、ストレージシステム４０に設定されているカテゴリの情報が格納される。

ＬＤＥＶカテゴリ情報テーブル３３００は、ＬＤＥＶと、そのＬＤＥＶに設定されている属性（カテゴリ）と、そのＬＤＥＶの使用状況との対応が格納される。

ストレージシステム４０は、複数のハードディスクからＲＡＩＤ構成等によって複数の論理デバイス（ＬＤＥＶ）が構成される。そして、一つ以上のＬＤＥＶが何れかの論理ユニット（ＬＵ）に割り当てられている。

データベース管理システム２０は、ストレージシステム４０にアクセスする場合は、このＬＵをアクセス先とする。ストレージ管理部３０は、アクセス先として指示されたＬＵから、要求に係るデータが格納されているＬＤＥＶを決定する。

本実施の形態のストレージシステムは、複数のＬＤＥＶがＬＵに割り当てられている。そして、この複数のＬＤＥＶは、それぞれが異なる「カテゴリ」に設定される。

カテゴリとは、当該ＬＤＥＶの属性を示す。例えば、アクセス速度、セキュリティ、信頼性等のレベルである。

ワークフローにおいて、それぞれの処理段階で操作対象となるデータが格納されるＬＤＥＶに要求される属性はそれぞれ異なる。そこで、必要な場合にこの属性を変更できるように、データが格納されるＬＤＥＶを変更することで、ワークフローにおける処理効率や信頼性を高めることができる。

図１の例では、ストレージシステム４０は２つのＬＵ（ＬＵ１、ＬＵ２）で構成されており、それぞれのＬＵが３つのカテゴリに分類されている。すなわち、ＬＵ１は、カテゴリ１のＬＤＥＶ１、カテゴリ２のＬＤＥＶ２、及びカテゴリ３のＬＤＥＶ３によって構成されている。

ＡＰサーバ１０からデータベースには、データベース管理システム２０のＤＢバッファ２０５を介してアクセスされる。具体的には、次のような処理となる。

ＡＰサーバ１０からデータベースの表の列に読み込み要求があった場合は、データベース管理システム２０は、要求に係る表がどのデータベース領域であるかを表・ＤＢ領域定義テーブル２２００を参照して取得する。さらに、ＤＢ領域情報テーブル２３００を参照して、取得したデータベース領域はストレージシステム４０のどのＬＵに格納されているかを取得する。

次に、データベース管理システム２０は、取得したＬＵに格納されている列のデータをストレージシステム４０から読み込んでＤＢバッファ２０５に格納する。そして、データベース管理システム２０は、ＤＢバッファ２０５に格納された列のデータを、ＡＰサーバ１０に返却する。

また、ＡＰサーバ１０からデータベースの表の列への書き出し要求があった場合は、データベース管理システム２０は、要求に係る書き出しデータを一旦ＤＢバッファ２０５に格納する。次に、データベース管理システム２０は、表・ＤＢ領域定義テーブル２２００を参照して、要求に係る表がどのデータベース領域であるかを取得する。さらに、ＤＢ領域情報テーブル２３００を参照して、取得したデータベース領域はストレージシステム４０のどのＬＵに格納されているかを取得する。

次に、データベース管理システム２０は、取得したＬＵを書き出し先として、ＤＢバッファ２０５に格納されたデータを、ストレージシステム４０に書き出す。

また、ＡＰサーバ１０からデータベースのデータへの更新要求があった場合は、データベース管理システム２０は、要求に係る書き出しデータを一旦ＤＢバッファ２０５に格納する。次に、データベース管理システム２０は、表・ＤＢ領域定義テーブル２２００を参照して、要求に係る表がどのデータベース領域であるかを取得する。さらに、取得したデータベース領域はストレージシステム４０のどのＬＵに格納されているかを、ＤＢ領域情報テーブル２３００を参照して取得する。

次に、データベース管理システム２０は、取得したＬＵに格納されているデータ（更新前データ）をストレージシステム４０から読み込んでＤＢバッファ２０５に格納する。そして、データベース管理システム２０は、ＤＢバッファ２０５に格納された更新前データを要求に基づいて更新して、更新後データとする。

このデータの更新の際に、データ更新処理１５０は、ＡＰサーバ１０のアプリケーションが、データベースのどの表のどの列にどのような操作をしたかを取得する。そして、取得した内容とカテゴリ変更テーブル２１００とを照合して、カテゴリを変更すべき操作であるか否かを判定する。

データ更新処理１５０は、カテゴリ変更をすべき操作であると判定した場合は、「カテゴリ変更要求」をストレージ管理部３０に送信することを決定する。

次に、データベース管理システム２０は、更新前データを読み込んだＬＵを書き出し先として、ＤＢバッファ２０５に格納された更新後データをストレージシステム４０に書き出す。この際に、カテゴリ変更要求を送信することを決定していた場合は、更新後データの書き出し要求に、カテゴリ変更指示を付加してストレージ管理部３０に送信する。

ストレージ管理部３０のデータ書き出し処理１６０がカテゴリ更新要求を受信する。データ書き出し処理１６０は、カテゴリ変更要求が付加されていると判定すると、カテゴリを変更する。具体的には、ＬＵカテゴリ管理テーブル３１００を参照して、カテゴリ変更順序に基づいて、変更されたカテゴリのＬＤＥＶを取得し、取得したＬＤＥＶをデータの書き出し先に決定する。

ＡＰサーバ１０の電子商取引ＡＰ１０３の処理について説明する。

電子商取引ＡＰ１０３は、注文記入処理１０３Ａ、注文承認処理１０３Ｂ、決済処理１０３Ｃ、発注処理１０３Ｄ、及び納品処理１０３Ｅの５つの処理を順次実行する。これらの処理が順次実行されることでワークフローが構成される。

まず、注文記入処理１０３Ａが実行される。注文記入処理１０３Ａでは、データベースの所望のデータに更新処理をし、このデータをＤＴ１とする。このＤＴ１は、ストレージシステム４０のＬＵ１に属するカテゴリ１のＬＤＥＶに格納される。

注文記入処理１０３Ａの次に注文承認処理１０３Ｂが実行される。注文承認処理１０３Ｂでは、注文記入処理１０３Ａによって処理されたデータであるＤＴ１に処理をする。

注文承認処理１０３Ｂのデータ格納先は、セキュリティレベルの高いカテゴリであるカテゴリ２が予め設定されている。

データ更新処理１５０は、カテゴリ変更テーブル２１００を参照し、この注文承認処理１０３Ｂによるデータの更新によって、更新後データを格納するカテゴリの変更を判定する。そして、カテゴリ更新指示を生成する。

データベース管理システム２０は、更新されたデータの書き出し要求と共に、カテゴリ更新指示をストレージ管理部３０に送信する。

ストレージ管理部はこの書き出し要求を受信する。ストレージ管理部３０のデータ書き出し処理１６０が、カテゴリ更新指示を受信すると、ＬＵカテゴリ管理テーブル３１００を参照して、当該書き出し要求データの書き出し先のカテゴリ２に対応するＬＤＥＶ２を取得する。ストレージ管理部３０は、取得したＬＤＥＶ２をデータの書き出し先として決定する。そして、当該ＬＤＥＶ２に要求データを書き出す。このデータをＤＴ２とする。

次に、決済処理１０３Ｃ及び発注処理１０３Ｄが実行される。この決済処理１０３Ｃ及び発注処理１０３Ｄでは、注文承認処理１０３Ｂによって更新されたデータであるＤＴ２に処理をする。

決済処理１０３Ｃ及び発注処理１０３Ｄは、セキュリティレベルの高いカテゴリであるカテゴリ２をデータ格納先として予め設定されている。

データ更新処理１５０は、カテゴリ変更テーブル２１００を参照し、この決済処理１０３Ｃ及び発注処理１０３Ｄによるデータの更新は、既にカテゴリ２に変更されているので、更新後データを格納するカテゴリを変更しないと判定する。従って、カテゴリ更新指示は生成されない。すなわち、決済処理１０３Ｃ及び発注処理１０３Ｄによる更新データは、カテゴリ２のＬＤＥＶ２に格納される。

次に、納品処理１０３Ｅが実行される。納品処理１０３Ｅでは、決済処理１０３Ｃ及び発注処理１０３Ｄによって更新されたデータであるＤＴ２に処理をする。

納品処理１０３Ｅは、アクセス速度の高いカテゴリであるカテゴリ３をデータ格納先として予め設定されている。

データ更新処理１５０は、カテゴリ変更テーブル２１００を参照し、納品処理１０３Ｅによるデータの更新は、更新後データを格納するカテゴリを変更させることを判定する。そして、カテゴリ更新指示を生成する。

データベース管理システム２０は、更新されたデータの書き出し要求と共に、カテゴリ更新指示をストレージ管理部３０に送信する。

ストレージ管理部はこの書き出し要求を受信する。ストレージ管理部３０のデータ書き出し処理１６０が、カテゴリ更新指示を受信すると、ＬＵカテゴリ管理テーブル３１００を参照して、当該書き出し要求データの書き出し先のカテゴリ３に対応するＬＤＥＶ３を取得する。ストレージ管理部３０は、取得したＬＤＥＶ３をデータの書き出し先として決定する。そして、当該ＬＤＥＶ３に要求データを書き出す。このデータをＤＴ３とする。

このように、ワークフローの処理の処理内容及び処理対象によって、ストレージシステム４０に格納されたデータのカテゴリが順次変更される。

図２は、本発明の実施の形態の計算機システムの機能ブロック図である。

ＡＰサーバ１０には、ワークフロー処理を実行するアプリケーション（ＡＰ１０１、ＡＰ１０２・・・ＡＰ１０ｎ）が格納される
データベース管理システム２０は、処理要求受付／結果返却部２０１、処理制御部２０２、カテゴリ情報編集部２０３、データベースバッファ管理部２０４、及びＤＢバッファ２０５を備えている。

処理要求受付／結果返却部２０１は、ＡＰサーバ１０、ストレージ管理部３０及びストレージシステム４０からの要求を受け付け、その結果を返却するインターフェースである。

処理制御部２０２は、データベース管理システム２０における処理を実行する。具体的には、処理要求受付／結果返却部２０１が受け取った要求に基づいた処理を実行し、その実行結果を、処理要求受付／結果返却部２０１を介して要求発行元に返却する。

カテゴリ情報編集部２０３は、データベース領域とＬＵとの対応の定義、表とデータベース領域との対応の定義、及びカテゴリの設定等を処理する。

ＤＢバッファ管理部２０４は、ＤＢバッファ２０５へのデータの格納を管理する。

ストレージ管理部３０は、データ読み書き制御部３０１及びカテゴリ制御部３０２を備えている。

データ読み書き制御部３０１は、データベース管理システム２０からのデータの読み込み要求及び書き出し要求を受け付け、当該要求をストレージシステム４０に実行する。

カテゴリ制御部３０２は、ストレージシステム４０のＬＤＥＶに設定したカテゴリの情報を制御する。

ストレージシステム４０は、データベース格納領域４０１〜４０４、データベース管理システムテーブル格納領域４０５、ストレージ管理部テーブル格納領域４０６を備えている。これらの領域は一つ以上のＬＵによって構成される。

データベース管理システムテーブル格納領域４０５は、カテゴリ変更テーブル２１００、表・ＤＢ領域定義テーブル２２００、及びＤＢ領域情報テーブル２３００が格納される。

ストレージ管理部テーブル格納領域４０６は、ＬＵカテゴリ管理テーブル３１００及びカテゴリ情報テーブル３２００が格納される。

図３は、本発明の実施の形態の計算機システムのハードウェア構成のブロック図である。

複数のホストコンピュータ５０Ａ、５０Ｂ、５０Ｃ及び５０Ｄがネットワーク７０に接続されている。また、情報処理装置６０Ａ及び６０Ｂがネットワーク７０に接続されている。このホストコンピュータ５０は、情報処理装置６０Ａにおいて実行されるＡＰサーバ１０に要求を送り、その要求の結果を受け取る。

情報処理装置６０Ａは、通信制御装置６１Ａ、ＣＰＵ６２Ａ、主記憶装置６３Ａ及びＩ／Ｏ制御装置６４Ａを備えている。また、Ｉ／Ｏ制御装置６４Ａを介して外部記憶装置６５Ａが接続されている。

通信制御装置６１Ａは、ネットワーク７０を介して、ホストコンピュータ５０又は他の情報処理装置６０Ｂとデータを送受信する。

ＣＰＵ６２Ａは、外部記憶装置６５Ａに格納された処理プログラム６６Ａを主記憶装置６３Ａに読み込む。ＣＰＵ６２Ａは、この処理プログラム６６Ａを実行することによって、当該処理プログラムに規定された処理を実行する。図３の例では、主記憶装置６３ＡにはＡＰサーバ１０が格納されており、これをＣＰＵ６２Ａが実行することによって、情報処理装置６０ＡがＡＰサーバ１０として機能する。

主記憶装置６３Ａは、プログラムや一時的なデータを格納する。

Ｉ／Ｏ制御装置６４Ａは、外部記憶装置６５Ａとデータを送受信する。

外部記憶装置６５Ａは、ハードディスクによって構成される。外部記憶装置６５Ａには処理プログラム６６Ａが格納される。

情報処理装置６０Ｂは、通信制御装置６１Ｂ、ＣＰＵ６２Ｂ、主記憶装置６３Ｂ及びＩ／Ｏ制御装置６４Ｂを備えている。また、Ｉ／Ｏ制御装置６４Ｂを介して外部記憶装置６５Ｂ及び６７Ｂが接続されている。

通信制御装置６１Ｂは、ネットワーク７０を介して、ホストコンピュータ５０又は他の情報処理装置６０Ａとデータを送受信する。

ＣＰＵ６２Ｂは、外部記憶装置６５Ｂに格納された処理プログラム６６Ｂを主記憶装置６３Ｂに読み込む。ＣＰＵ６２Ｂは、この処理プログラム６６Ｂを実行することによって、当該処理プログラムに規定された処理を実行する。図３の例では、主記憶装置６３Ｂにはデータベース管理システム２０及びストレージ管理部３０が格納されており、これをＣＰＵ６２Ｂが実行することによって、情報処理装置６０Ｂがデータベース管理システム２０及びストレージ管理部３０として機能する。

主記憶装置６３Ｂは、プログラムや一時的なデータを格納する。

Ｉ／Ｏ制御装置６４Ｂは、外部記憶装置６５Ｂ及び外部記憶装置６７Ｂとデータを送受信する。

外部記憶装置６５Ｂは、ハードディスクによって構成される。外部記憶装置６５Ｂには処理プログラム６６Ｂが格納される。

外部記憶装置６７Ｂは、ハードディスクによって構成される。外部記憶装置６７Ｂにはデータベース６８Ｂが格納される。

なお、図３では、ストレージ管理部３０は、情報処理装置６０Ｂの処理プログラムとして示されているが、その他の構成でもよい。例えば、外部記憶装置６７Ｂに備えられていてもよい。また、他の情報処理装置６０の処理プログラムとして実現されていてもよい。また、他の情報処理装置６０のハードウェアとして実現されていてもよい。

図４は、本発明の実施の形態のカテゴリ変更テーブル２１００の説明図である。

カテゴリ変更テーブルは、アプリケーション名２１０１、表名２１０２、列名２１０３及び操作名２１０４から構成される。

アプリケーション名２１０１には、データを操作するアプリケーションの識別子が格納される。

表名２１０２には、操作対象のデータが属する表の識別子が格納される。

列名２１０３には、操作対象のデータの属する列の識別子が格納される。

操作名２１０４には、アプリケーションによってなされる操作の内容の識別子が格納される。例えば、「更新」はその列データへの操作がデータの更新であることを示す。

データベース管理システム２０のデータ更新処理１５０は、ＡＰサーバ１０のアプリケーションからデータベースへの操作要求がされると、当該操作要求からアプリケーション名、操作対象のデータベースの表及び列、並びに、操作の内容を取得する。そして、取得した内容とこのカテゴリ変更テーブル２１００とを照合する。照合の結果、取得した情報とカテゴリ変更テーブル２１００のエントリの何れかとが合致した場合は、カテゴリの変更を指示するためのカテゴリ変更指示をストレージ管理部３０に送信することを決定する。

図５は、本発明の実施の形態の表・ＤＢ領域定義テーブル２２００の説明図である。

表・ＤＢ領域定義テーブル２２００は、表名２２０１及びＤＢ領域２２０２から構成される。

表名２２０１には表の識別子が格納され、ＤＢ領域２２０２にはデータベースの領域の識別子が格納される。

データベース管理システム２０は、この表・ＤＢ領域テーブル２２００を参照することで、データベースの表がどのデータベース領域に属しているかを取得できる
図６は、本発明の実施の形態のＤＢ領域情報テーブル２３００の説明図である。

ＤＢ領域情報テーブル２３００は、ＤＢ領域２３０１及びＬＵ名２３０２から構成される。

ＤＢ領域２３０１にはデータベースの領域の識別子が格納され、ＬＵ名２３０２にはＬＵの識別子が格納される。

データベース管理システム２０は、このＤＢ領域情報テーブル２３００を参照することで、データベース領域がストレージシステム４０のどのＬＵに属しているかを取得できる。

すなわち、データベース管理システム２０は、図５の表・ＤＢ領域定義テーブル２２００及び図６のＤＢ領域情報テーブル２３００を参照することで、データベースの表がそのデータベース領域であるかを取得でき、そのデータベース領域は、ストレージシステム４０のどのＬＵに属しているかを取得できる。

図７は、本発明の実施の形態のＬＵカテゴリ管理テーブル３１００の説明図である。

ＬＵカテゴリ管理テーブル３１００は、ＬＵ名３１０１、ＬＤＥＶ名３１０２、カテゴリ名３１０３及びカテゴリ変更順序３１０４から構成される。

ＬＵ名３１０１には、ＬＵの識別子が格納される。

ＬＤＥＶ名３１０２には、ＬＤＥＶの識別子が格納される。

カテゴリ名３１０３には、そのＬＤＥＶに設定されたカテゴリ名が格納される。

カテゴリ変更順序３１０４には、そのＬＵに設定された複数のカテゴリの変更順序が格納される。

ストレージ管理部３０のデータ書き出し処理１６０は、データベース管理システム２０からカテゴリ変更指示を受信すると、このカテゴリ変更順序に従って、アクセス先のカテゴリを変更して、データの書き出し対象のＬＤＥＶを決定する。

データベース管理システム２０は、データベースへのアクセス先はＬＵを指示して要求する。このＬＵは、ストレージ管理部３０によってこのＬＵカテゴリ管理テーブル３１００で示されるＬＤＥＶのうちの何れか一つが割り当てられている。データベース管理システム２０からカテゴリ変更指示が送信された場合は、カテゴリ変更順序に従ってＬＤＥＶが変更され、変更されたＬＤＥＶが新たにＬＵに割り当てられる。結果として、データベース管理システム２０からのアクセス先であるＬＵを変更することなく、ＬＤＥＶの割り当てが変更されることによって、カテゴリ、すなわちＬＤＥＶの属性を変更することができる。

図８は、本発明の実施の形態のカテゴリ情報テーブル３２００の説明図である。

カテゴリ情報テーブル３２００は、デバイス情報及びカテゴリ名から構成される。

デバイス情報は、アクセス速度３２０１、セキュリティ３２０２及び信頼性３２０３から構成される。

アクセス速度３２０１には、そのカテゴリに要求されるアクセス速度を決定する情報が格納される。アクセス速度を決定する情報は、キャッシュ容量３２０４、ドライブ速度３２０５、圧縮率３２０６が含まれる。

セキュリティ３２０２には、そのカテゴリに要求されるセキュリティのレベルを決定する情報が格納される。セキュリティのレベルを決定する情報は、暗号化方式３２０７、バックアップレベル３２０８が含まれる。

信頼性３２０３には、そのカテゴリに要求される信頼性を決定する情報が格納される。信頼性を決定する情報は、ＲＡＩＤレベル３２０９が含まれる。

このカテゴリ情報テーブル３２００を参照することによって、カテゴリの内容を取得できる。

具体的には、例えば、カテゴリ１は、アクセス速度３２０１では、キャッシュ容量３２０４が「未使用」に、ドライブ速度３２０５が「低速」に、圧縮率３２０６が「圧縮なし」に、それぞれ設定されている。また、セキュリティ３２０２では、暗号化方式３２０７が「なし」に、バックアップレベル３２０８が「簡易バックアップ」に、それぞれ設定されている。また、信頼性３２０３では、ＲＡＩＤレベル３２０９が「冗長性なし」に設定されている。

なお、このカテゴリ情報テーブル３２００に格納されたカテゴリの情報は、予め設定し、ストレージシステム全体で共有しておく。

図９は、本発明の実施の形態のＬＤＥＶカテゴリ情報テーブル３３００の説明図である。

ＬＤＥＶカテゴリ情報テーブル３３００は、カテゴリ名３３０１、ＬＤＥＶ名３３０２及び使用状況３３０３から構成される。

カテゴリ名３３０１はカテゴリの識別子が格納され、ＬＤＥＶ名３３０２はＬＤＥＶの識別子が格納される。

使用状況３３０３は、そのＬＤＥＶが既に使用中であるか否かの識別子が格納される。

例えば、図９のエントリ３３１０では、カテゴリ１として設定されたＬＤＥＶ１は、使用状況が「済」、すなわち、既にＬＵに割り当てられて使用中であることを示す。また、エントリ３３１２は、カテゴリ１として設定されたＬＤＥＶ７は、使用状況が「未済」すなわち、まだ割り当てられていないことを示す。

データベース管理システム２０が新たなデータベース領域を設定するときは、このＬＤＥＶカテゴリ情報テーブル３３００を参照し、そのデータベース領域に使用するカテゴリに対応するＬＤＥＶを取得できる。

図１０は、本発明の実施の形態のデータベース管理システム２０の表登録処理のフローチャートである。

ＡＰサーバ１０のアプリケーションが、当該アプリケーションが要求するカテゴリ名、その順序及びカテゴリ変更の契機情報を含むカテゴリ登録要求を、データベース管理システム２０に送信する。データベース管理システム２０がこのカテゴリ登録要求を受信すると、本フローチャートの処理が開始する。

アプリケーションが送信したカテゴリ登録要求は、処理要求受付／結果返却部２０１が受信する。処理要求受付／結果返却部２０１は、受信したカテゴリ登録要求を処理制御部２０２に送信する。処理制御部２０２は、受信したカテゴリ登録要求をカテゴリ情報編集部２０３に送信する。以降の処理は、このカテゴリ情報編集部２０３で実行される。

カテゴリ情報編集部２０３は、受信したカテゴリ登録要求に含まれる情報から、カテゴリ名、その順序及びカテゴリ変更契機の各情報を取得する。

カテゴリ情報編集部２０３は、取得したカテゴリ名及びその順序を用いて、ＬＵ割り当て要求を生成する。そして、ＬＵ割り当て要求をストレージ管理部３０に送信する（ステップ１００１）。

この要求を受信したストレージ管理部３０は、図１１に示すＬＵ割り当て処理を実行する。このＬＵ割り当て要求の結果、ストレージ管理部３０のＬＵカテゴリ管理テーブル３１００に、要求に基づく新たなＬＵのエントリが格納される。ストレージ管理部３０は、この新たなＬＵの識別子を、データベース管理システム２０に送信する。

次に、カテゴリ情報編集部２０３は、受信したＬＵの識別子と当該アプリケーションの用いるデータベースの表を格納するデータベース領域とを対応付けてデータベース領域情報を定義する。そして定義されたデータベース領域情報を、ＤＢ領域情報テーブル２３００の新たなエントリとして追加する（ステップ１００２）。

次に、カテゴリ情報編集部２０３は、定義したデータベース領域とアプリケーションの用いるデータベースの表とを対応付けて、表・ＤＢ領域情報を定義する。そして定義された表・ＤＢ情報を、表・ＤＢ領域定義テーブル２２００の新たなエントリとして追加する（ステップ１００３）。

次に、カテゴリ情報編集部２０３は、取得したカテゴリの変更契機と当該アプリケーションとを対応付けてカテゴリ変更契機情報を定義する。そして定義したカテゴリ変更契機情報を、カテゴリ変更テーブル２１００の新たなエントリとして追加する（ステップ１００４）。

以上の処理によって、新たにアプリケーションが用いるデータベースの表に対応した情報が定義される。定義された情報は、それぞれＬＵカテゴリ管理テーブル３１００、ＤＢ領域情報テーブル２３００、表・ＤＢ領域定義テーブル２２００及びカテゴリ変更テーブル２１００に、新たなエントリとして格納される。

図１１は、本発明の実施の形態のストレージ管理部３０のＬＵ割り当て処理のフローチャートである。

図１０のステップ１００１においてデータベース管理システム２０から送信されたＬＵ割り当て要求を、ストレージ管理部３０が受信すると、本フローチャートの処理が開始する。

ストレージ管理部３０において、カテゴリ制御部３０２がこのＬＵ割り当て要求を受信し、処理を実行する。

まず、カテゴリ制御部３０２は、受信したＬＵ割当て処理の内容を取得する。そして、割り当てるＬＵの識別子である新規ＬＵ名を決定する（ステップ１１０１）。

次に、カテゴリ制御部３０２は、順序変数に１を設定する（ステップ１１０２）。この順序変数はＬＵ割り当て要求に含まれるカテゴリ情報を順次取得するために用いる。

次に、カテゴリ制御部３０２は、受信したＬＵ割り当て要求から一つのカテゴリ分の情報を取得する（ステップ１１０３）。そして、カテゴリの情報が取得できたか否かを判定する（ステップ１１０４）。カテゴリ情報が取得できた場合はステップ１１０５に移行する。カテゴリ情報が取得できない、すなわち、全てのカテゴリ情報を取得していた場合は、ステップ１１０９に移行する。

ステップ１１０５では、カテゴリ制御部３０２は、ＬＤＥＶカテゴリ情報テーブル３３００を参照し、取得したカテゴリ情報のカテゴリ名のうち、カテゴリの使用状況３３０３が「未済」であるＬＤＥＶ名を取得する。

次に、カテゴリ制御部３０２は、取得したＬＤＥＶ名の使用状況３３０２を「済」に変更する（ステップ１１０６）。

次に、カテゴリ制御部３０２は、ＬＵカテゴリ管理テーブル３１００に新規のエントリを追加する（ステップ１１０７）。このエントリは、ステップ１１０１で決定した新規ＬＵ名、ステップ１１０３で取得したカテゴリ情報のカテゴリ名及びその順序、並びに、ステップ１１０５で取得したＬＤＥＶ名が含まれる。

次に、順序変数を、現在の順序変数の値に１を加算する（ステップ１１０８）。そして、ステップ１１０３に戻る。

ステップ１１０９では、ＬＵ割り当て要求の送信元に、ステップ１１０１で決定した新規ＬＵ名を送信し、ＬＵ割り当て要求が完了した旨を通知する。

以上の処理によって、データベース管理システム２０のＬＵ割り当て要求に基づいた、ＬＵがストレージ管理部３０に設定される。

次に、ＡＰサーバ１０のアプリケーションによるデータベースへのアクセスの処理を説明する。

図１２は、本発明の実施の形態のデータベース管理システム２０のデータ挿入処理のフローチャートである。

ＡＰサーバ１０のアプリケーションが、新規のデータをデータベースの表に挿入するためのデータ挿入要求をデータベース管理システム２０に送信する。データベース管理システム２０がこのデータベース挿入要求を受信すると、本フローチャートの処理が開始する。

アプリケーションが送信したデータ挿入要求は、処理要求受付／結果返却部２０１が受信する。処理要求受付／結果返却部２０１は、受信したデータ挿入要求を処理制御部２０２に送信する。以降の処理は、この処理制御部２０２で実行される。

処理制御部２０２は、データ挿入要求を受信すると、ＤＢバッファ２０５に、新規のデータ格納領域を確保する（ステップ１２０１）。具体的には、データベースバッファ管理部２０４にデータ格納領域の確保の要求を送信する。この要求を受信したデータベースバッファ管理部２０４は、ＤＢバッファ２０５の空き領域に、データ格納領域を確保する。

次に、処理制御部２０２は、データ挿入要求に含まれる挿入データを取得し、確保したデータ格納領域に格納する（ステップ１２０２）。

次に、処理制御部２０２は、データ挿入要求の挿入先の表の情報を取得する。そして、まず、表・ＤＢ領域定義テーブル２２００を参照して、取得した表に対応するデータベース領域名を取得する。次に、ＤＢ領域情報テーブルを参照して、取得したデータベース領域に対応するＬＵ名を取得する（ステップ１２０３）。

次に、処理制御部２０２は、取得したＬＵ名を書き出し先とする書き出し要求をストレージ管理部３０に送信する（ステップ１２０４）。この要求を受信したストレージ管理部３０は、図１４に示すデータ書き出し処理を実行し、当該書き出しデータをストレージシステムに格納する。

以上の処理によって、アプリケーションからのデータ挿入要求が処理され、挿入データがストレージシステム４０のデータ格納領域であるＬＵに格納される。

図１３は、本発明の実施の形態のデータベース管理システム２０のデータ更新処理のフローチャートである。

ＡＰサーバ１０のアプリケーションが、既にデータベースの表に存在するデータを更新するためのデータ更新要求をデータベース管理システム２０に送信する。データベース管理システム２０がこのデータベース更新要求を受信すると、本フローチャートの処理が開始する。

アプリケーションが送信したデータ更新要求は、処理要求受付／結果返却部２０１が受信する。処理要求受付／結果返却部２０１は、受信したデータ更新要求を処理制御部２０２に送信する。以降の処理は、この処理制御部２０２で実行される。

処理制御部２０２は、データ更新要求を受信すると、まず、ＤＢバッファ２０５に更新要求に係るデータ（更新前データ）が格納されているか否かを判定する。（ステップ１３０１）。具体的には、データベースバッファ管理部２０４に当該データが格納されているかの問い合わせを送信し、その結果で判定する。

データが格納されていないと判定した場合は、ストレージ管理部３０に当該データを指示してデータ読み込み要求を送信する（ステップ１３０２）。この要求を受信したストレージ管理部３０は、図１５に示すデータ読み込み処理を実行して要求に係るデータをデータベース管理システム２０に返却する。このデータはＤＢバッファ２０５に格納される。

データがＤＢバッファに格納されていると判定した場合は、ステップ１３０２を実行することなくステップ１３０４に移行する。

次に、処理制御部２０２は、カテゴリ変更テーブル２１００を参照して、データ更新要求元のアプリケーション名、並びに、更新データの属する表及び列がテーブルのエントリと合致するかを判定する（ステップ１３０３）。この判定の結果、カテゴリ変更テーブル２１００のエントリと合致し、当該アプリケーションのデータ更新要求はカテゴリ変更が発生する操作であるか否かを判定する（ステップ１３０４）。

カテゴリ変更が発生する操作であると判定した場合は、ＤＢバッファ２０５に格納されている更新データをストレージ管理部３０に書き出し要求を送信する際に、カテゴリ変更指示を付加することを決定する（ステップ１３０５）。

カテゴリ変更が発生する操作でないと判定した場合は、ステップ１３０５を実行することなくステップ１３０６に移行する。

次に、処理制御部２０２は、データ更新要求に基づいて、ＤＢバッファ２０５に格納されている更新前データを更新する（ステップ１３０６）。

次に、処理制御部２０２は、ストレージ管理部３０に送信するデータ書き出し要求を生成する（ステップ１３０７）。このとき、ステップ１３０５でカテゴリ変更指示を付加することが決定されている場合は、生成されたデータ書き出し要求にカテゴリ変更指示を付加する。

次に、処理制御部２０２は、このデータ書き出し要求をストレージ管理部３０に送信する。この書き出し要求を受信したストレージ制御部３０は、図１４に示すデータ書き出し処理を実行し、当該書き出しデータをストレージシステムに格納する。

以上の処理によって、アプリケーションからのデータ更新要求が処理され、ストレージシステム４０のデータ格納領域であるＬＵに格納された更新前データが更新される。

図１４は、本発明の実施の形態のストレージ管理部３０のデータ書き出し処理のフローチャートである。

図１２のステップ１２０４又は図１３のステップ１３０８において、データベース管理システム２０から送信されたデータ書き出し要求をストレージ管理部３０が受信すると、本フローチャートの処理が開始する。

ストレージ管理部３０において、データ読み書き制御部３０１がこのデータ書き出し要求を受信し、処理を実行する。

データ読み書き制御部３０１は、データ書き出し要求を受信すると（ステップ１４０１）、その要求データが新規データであるかデータの更新であるかを判定する（ステップ１４０２）。新規データの書き出しである場合は、ステップ１４０４に移行する。データの更新である場合は、ステップ１４０７に移行する。

ステップ１４０４において、カテゴリ制御部３０２は、ＬＵカテゴリ管理テーブル３１００を参照して、当該書き出し要求に係るＬＵに属するＬＤＥＶのうち、カテゴリ変更順序が「１」であるＬＤＥＶを取得する。そして取得したＬＤＥＶをデータ書き出し先に決定する。そして、決定したＬＤＥＶに新規データを書き出す（ステップ１４０５）。

一方、ステップ１４０３では、データ書き出し要求にカテゴリ変更指示が付加されているか否かを判定する。カテゴリ変更指示が付加されていると判定した場合は、ステップ１４０７に移行する。カテゴリ変更指示が付加されていない場合は、ステップ１４０６に移行する。

ステップ１４０６において、カテゴリ制御部３０２は、当該更新データの更新前データが格納されていたＬＤＥＶをデータ書き出し先に決定する。そして、決定したＬＤＥＶに更新データを書き出す（ステップ１４１１）。

一方、ステップ１４０７において、カテゴリ制御部３０２は、ＬＵカテゴリ管理テーブル３１００を参照して、当該更新データの更新前データが格納されていたＬＤＥＶのカテゴリ変更順序を取得する。

次に、データ読み書き制御部３０１は、取得したカテゴリ変更順序に「１」を加算したカテゴリ変更順序に対応するＬＤＥＶを取得する。そして取得したＬＤＥＶをデータ書き出し先に決定する（ステップ１４０８）。そして、決定したＬＤＥＶに更新データを書き出す（ステップ１４０９）。

更新データの書き出しが完了すると、データ読み書き制御部３０１は、更新前データの格納されていたＬＤＥＶ、すなわち、カテゴリ変更前のカテゴリに対応するＬＤＥＶに格納されている更新前データを削除する（ステップ１４１０）。

以上の処理によって、データベース管理システム２０からの書き出し要求に係るデータがストレージシステムに格納される。このとき、カテゴリ変更要求が付加されている場合は、更新前データのカテゴリの次の順序に指定されているカテゴリのＬＤＥＶに更新データが格納される。

図１５は、本発明の実施の形態のストレージ管理部３０のデータ読み込み処理のフローチャートである。

図１３のステップ１３０２においてデータベース管理システム２０から送信されたデータ読み込み要求を、ストレージ管理部３０が受信すると、本フローチャートの処理が開始する。

ストレージ管理部３０において、データ読み書き制御部３０１がこのデータ読み込み要求を受信し、処理を実行する。

データ読み書き制御部３０１は、データ読み込み要求を受信すると（ステップ１５０１）、カテゴリ制御部３０２に要求を送信する。カテゴリ制御部３０２は、ＬＵカテゴリ情報テーブル３１００を参照して、その要求に係るＬＵに対応するＬＤＥＶを取得し、読み込み先のＬＤＥＶを決定する（ステップ１５０２）。

そして、データ読み書き制御部３０１は、決定した読み込み先ＬＤＥＶから要求データを読み込む。そして、読み込んだデータを要求元のデータベース管理システム２０に返却する（ステップ１５０３）。

以上の処理によって、ストレージシステム４０からデータが読み込まれる。

以上説明した本発明の実施の形態の計算機システムでは、アプリケーションのワークフローの処理の流れに基づいて、ストレージシステムのＬＵに割り当てられるＬＤＥＶを、異なるカテゴリ（属性）に変更することができる。カテゴリの変更の契機はアプリケーションの処理内容及び処理対象によって決定される。

次に、本発明の実施の形態の変形例を説明する。

前述した実施の形態では、ストレージ管理部３０は、データベース管理システム２０からカテゴリ変更指示があった場合に、ＬＵに割り当てられているＬＤＥＶを変更するように構成した。すなわち、カテゴリ変更指示があった場合に、ＬＵカテゴリ管理テーブル３１００を参照して、次のカテゴリ変更順序のカテゴリのＬＤＥＶをＬＵに割り当てる。

これに対して、本発明の実施の形態の変形例では、ストレージ管理部３０は、データベース管理システム２０からカテゴリ変更指示があった場合に、ＬＵに割り当てられているＬＤＥＶのカテゴリそのものを変更する。

図１６は、本発明の実施の形態の変形例のＬＵカテゴリ管理テーブル４１００の説明図である。

ＬＵカテゴリ管理テーブル４１００は、前述したＬＵカテゴリ管理テーブル３１００と同じ構成である。

ただし、ＬＤＥＶ名４１０２で示されるＬＤＥＶは、同一のＬＵではすべて同一である。すなわち、ＬＵに割り当てられるＬＤＥＶは一つであり、カテゴリの変更に伴って、割り当てられているＬＤＥＶのカテゴリそのものを変更する。

ストレージ管理部３０のデータ書き出し処理１６０は、データベース管理システム２０からカテゴリ変更指示を受信すると、このカテゴリ変更順序に従って、アクセス先のカテゴリを変更する。そして、カテゴリの変更に伴ってデータの書き出し対象のＬＤＥＶのカテゴリが変更される。

データベース管理システム２０は、データベースへのアクセスはＬＵを指示して要求する。このＬＵは、ストレージ管理部３０によって、このＬＵカテゴリ管理テーブル３１００で示されるＬＤＥＶに割り当てられている。データベース管理システム３０からカテゴリ変更指示が送信された場合は、カテゴリ変更順序に従って当該ＬＤＥＶのカテゴリが変更される。結果として、データベース管理システム２０からのアクセス対象であるＬＵを変更することなく、ＬＤＥＶのカテゴリが変更されることによって、複数のＬＤＥＶの割り当てを変更することなくＬＤＥＶの属性を変更することができる。

この変形例は、例えば、アプリケーションの処理履歴等を格納しているＬＤＥＶの容量の上限近くまでデータが格納された場合に用いられる。すなわち、処理履歴等の、アクセス速度の要求は低いが長期にデータを格納しておく必要があるデータは、そのデータの格納されたＬＤＥＶそのもののカテゴリを変更する。例えば、アクセス速度要求は低いが容量が大きく、信頼性の高いカテゴリに変更して、これをアーカイブとする。そして、リアルタイムに処理履歴を格納する新たなＬＤＥＶを別に用意する。このようにすることで、データベースのライフサイクルに対応することができる。

本発明の実施の形態の計算機システムの処理のブロック図である。 本発明の実施の形態の計算機システムの機能ブロック図である。 本発明の実施の形態の計算機システムのハードウェア構成のブロック図である。 本発明の実施の形態のカテゴリ変更テーブルの説明図である。 本発明の実施の形態の表・ＤＢ領域定義テーブルの説明図である。 本発明の実施の形態のＤＢ領域情報テーブルの説明図である。 本発明の実施の形態のＬＵカテゴリ管理テーブルの説明図である。 本発明の実施の形態のカテゴリ情報テーブルの説明図である。 本発明の実施の形態のＬＤＥＶカテゴリ情報テーブルの説明図である。 本発明の実施の形態のデータベース管理システムの表登録処理のフローチャートである。 本発明の実施の形態のストレージ管理部のＬＵ割り当て処理のフローチャートである。 本発明の実施の形態のデータベース管理システムのデータ挿入処理のフローチャートである。 本発明の実施の形態のデータベース管理システムのデータ更新処理のフローチャートである。 本発明の実施の形態のストレージ管理部のデータ書き出し処理のフローチャートである。 本発明の実施の形態のストレージ管理部のデータ読み込み処理のフローチャートである。 本発明の実施の形態の変形例のＬＵカテゴリ管理テーブルの説明図である。

符号の説明

１０ ＡＰサーバ
２０ データベース管理システム
３０ ストレージ管理部
４０ ストレージシステム
２０１ 処理要求受付／結果返却部
２０２ 処理制御部
２０３ カテゴリ情報編集部
２０４ データベースバッファ管理部
２０５ ＤＢバッファ
３０１ データ読み書き制御部
３０２ カテゴリ制御部

Claims (10)

1. データを格納するストレージ装置にデータを読み書きするストレージ管理装置であって、
   前記ストレージ装置には、異なる属性が設定された複数の論理デバイスを含むデータ格納領域が設けられ、
   前記ストレージ管理装置は、
   受け付けたアクセス要求に基づいて、前記ストレージ装置にデータを読み書きする読み書き制御部と、
   前記論理デバイスの属性を設定する属性制御部と、を備え、
   前記属性制御部は、前記ストレージ装置に格納されたデータの属性の変更契機であって、電子商取引に係る注文記入処理、注文承認処理、決済処理、発注処理及び納品処理を順次実行するアプリケーションプログラムの進行に応じて生成される属性変更契機を検出すると、当該属性変更に係るデータを他の属性の論理デバイスに移動するものであり、
   前記属性制御部は、
   前記注文記入処理が実行される場合、所定のデータを当該注文記入処理によって更新後、第１の論理デバイスに格納し、
   前記注文承認処理が実行される場合、前記第１の論理デバイスに格納されたデータを当該注文承認処理によって更新後、前記第１の論理デバイスよりも安全性の高い第２の論理デバイスに格納し、
   前記決済処理又は発注処理が実行される場合、前記第２の論理デバイスに格納されたデータを当該決済処理又は発注処理によって更新し、
   前記納品処理が実行される場合、前記決済処理又は発注処理によって更新されたデータを当該納品処理によって更新後、前記第１の論理デバイスよりもアクセス速度の高い第３の論理デバイスに格納することを特徴とするストレージ管理装置。
2. 電子商取引に係る注文記入処理、注文承認処理、決済処理、発注処理及び納品処理を順次実行するアプリケーションサーバと、
   データベースを格納するストレージ装置と、
   前記アプリケーションサーバによる処理に基づいて、前記データベースを管理するデータベース管理装置と、
   前記データベース管理装置からの要求に基づいて、前記ストレージ装置にデータを読み書きするストレージ管理装置と、を備えた計算機システムにおいて、
   前記ストレージ装置に設けられたデータベース格納領域は、異なる属性が設定された複数の論理デバイスを含み
   前記データベース管理装置は、
   前記アプリケーションサーバからの要求を受け付け、処理の結果を返却する処理要求受付返却部と、
   前記アプリケーションサーバからの要求に基づいて処理を実行する処理制御部と、を備え、
   前記ストレージ管理装置は、
   前記データベース管理装置からの要求に基づいて、前記ストレージ装置にデータを読み書きする読み書き制御部と、
   前記論理デバイスの属性を設定する属性制御部と、を備え、
   前記処理制御部は、前記アプリケーションサーバによる処理内容及び処理対象が所定の条件を満たす場合に、前記論理デバイスの属性を変更する属性変更指示を前記ストレージ管理部に送信し、
   前記属性制御部は、前記データベース管理装置から属性変更指示を受信すると、前記アプリケーションサーバによる処理対象のデータが格納される論理デバイスを他の属性に変更するものであり、
   前記処理制御部は、
   前記アプリケーションサーバの処理内容が前記注文記入処理である場合、所定のデータを当該注文記入処理によって更新後、第１の論理デバイスに格納する指示を前記ストレージ管理部に送信し、
   前記アプリケーションサーバの処理内容が前記注文承認処理である場合、前記第１の論理デバイスに格納されたデータを当該注文承認処理によって更新後、前記第１の論理デバイスよりも安全性の高い第２の論理デバイスに格納する指示を前記ストレージ管理部に送信し、
   前記アプリケーションサーバの処理内容が前記決済処理又は発注処理である場合、前記第２の論理デバイスに格納されたデータを当該決済処理又は発注処理によって更新する指示を前記ストレージ管理部に送信し、
   前記アプリケーションサーバの処理内容が前記納品処理である場合、前記決済処理又は発注処理によって更新されたデータを当該納品処理によって更新後、前記第１の論理デバイスよりもアクセス速度の高い第３の論理デバイスに格納する指示を前記ストレージ管理部に送信することを特徴とする計算機システム。
3. 前記処理制御部は、前記アプリケーションサーバの処理対象に基づいて、前記アプリケーションサーバによって実行されている処理を特定し、当該処理対象のデータが格納されている論理デバイスを特定することを特徴とする請求項２に記載の計算機システム。
4. 前記属性制御部は、前記データベース管理装置から属性変更指示を受信すると、当該属性変更指示に係るデータを他の属性の論理デバイスに移動することによって、前記アプリケーションサーバの処理対象のデータが格納される論理デバイスを他の属性に変更することを特徴とする請求項２に記載の計算機システム。
5. 前記属性制御部は、前記データベース管理装置から属性変更指示を受信すると、前記データベース格納領域に割り当てられている論理デバイスの属性を他の属性に変更することによって、前記アプリケーションサーバの処理対象のデータが格納される論理デバイスを他の属性に変更することを特徴とする請求項２に記載の計算機システム。
6. 電子商取引に係る注文記入処理、注文承認処理、決済処理、発注処理及び納品処理を順次実行するアプリケーションサーバと、
   データベースを格納するストレージ装置と、
   前記アプリケーションサーバによる処理に基づいて、前記データベースを管理するデータベース管理装置と、
   前記データベース管理装置からの要求に基づいて、前記ストレージ装置にデータを読み書きするストレージ管理装置と、を備え、
   前記ストレージ装置には、異なる属性が設定された複数の論理デバイスを含むデータベース格納領域が設けられた計算機システムにおけるストレージ管理方法であって、
   前記データベース管理装置は、
   前記アプリケーションサーバからの要求を受け付け、
   前記アプリケーションサーバによる処理内容及び処理対象が予め定めた所定の条件を満たす場合に、前記論理デバイスの属性を変更する属性変更指示を前記ストレージ管理装置に送信し、
   前記ストレージ管理装置は、
   前記データベース管理装置からの要求に基づいて、前記ストレージ装置にデータを読み書きし、
   前記データベース管理装置から属性変更指示を受信すると、前記アプリケーションサーバの処理対象のデータが格納される論理デバイスを他の属性に変更し、
   前記データベース管理装置が、前記アプリケーションサーバに、処理の結果を返却するものであり、
   前記データベース管理装置は、
   前記アプリケーションサーバの処理内容が前記注文記入処理である場合、所定のデータを当該注文記入処理によって更新後、第１の論理デバイスに格納する指示を前記ストレージ管理装置に送信し、
   前記アプリケーションサーバの処理内容が前記注文承認処理である場合、前記第１の論理デバイスに格納されたデータを当該注文承認処理によって更新後、前記第１の論理デバイスよりも安全性の高い第２の論理デバイスに格納する指示を前記ストレージ管理装置に送信し、
   前記アプリケーションサーバの処理内容が前記決済処理又は発注処理である場合、前記第２の論理デバイスに格納されたデータを当該決済処理又は発注処理によって更新する指示を前記ストレージ管理装置に送信し、
   前記アプリケーションサーバの処理内容が前記納品処理である場合、前記決済処理又は発注処理によって更新されたデータを当該納品処理によって更新後、前記第１の論理デバイスよりもアクセス速度の高い第３の論理デバイスに格納する指示を前記ストレージ管理装置に送信することを特徴とするストレージ管理方法。
7. さらに、前記データベース管理装置が、前記アプリケーションサーバの処理対象に基づいて、前記アプリケーションサーバによって実行されている処理を特定し、当該処理対象のデータが格納されている論理デバイスを特定することを特徴とする請求項６に記載のストレージ管理方法。
8. 前記論理デバイスを他の属性に変更する手順は、前記データベース管理装置から属性変更指示を受信すると、当該属性変更指示に係るデータを他の属性の論理デバイスに移動することを特徴とする請求項６に記載のストレージ管理方法。
9. 前記論理デバイスを他の属性に変更する手順は、前記データベース管理装置から属性変更指示を受信すると、前記データベース格納領域に割り当てられている論理デバイスの属性を他の属性に変更することを特徴とする請求項６に記載のストレージ管理方法。
10. データを格納するストレージ装置にデータを読み書きするストレージ管理装置に以下の手順を実行させるプログラムであって、
    前記ストレージ装置に設けられたデータ格納領域は、異なる属性が設定された複数の論理デバイスを含み、
    前記プログラムは、
    受け付けたアクセス要求に基づいて、前記ストレージ装置にデータを読み書きする手順と、
    前記ストレージ装置に格納されるデータの属性の変更契機であって、電子商取引に係る注文記入処理、注文承認処理、決済処理、発注処理及び納品処理を順次実行するアプリケーションプログラムの進行に応じて生成される属性変更契機を検出すると、当該属性変更に係るデータを異なる属性の論理デバイスに移動する手順と、を含み、
    前記移動する手順において、
    前記注文記入処理が実行される場合、所定のデータを当該注文記入処理によって更新後、第１の論理デバイスに格納し、
    前記注文承認処理が実行される場合、前記第１の論理デバイスに格納されたデータを当該注文承認処理によって更新後、前記第１の論理デバイスよりも安全性の高い第２の論理デバイスに格納し、
    前記決済処理又は発注処理が実行される場合、前記第２の論理デバイスよりも安全性の高い第２の論理デバイスに格納し、
    前記納品処理が実行される場合、前記決済処理又は発注処理によって更新されたデータを当該納品処理によって更新後、前記第１の論理デバイスよりもアクセス速度の高い第３の論理デバイスに格納することを特徴とするストレージ管理プログラム。

Images