JP5256173B2 - データベース管理方法、データベース管理システム及びデータベース管理プログラム - Google Patents

データベース管理方法、データベース管理システム及びデータベース管理プログラム Download PDF

Info

Publication number
JP5256173B2
JP5256173B2 JP2009263031A JP2009263031A JP5256173B2 JP 5256173 B2 JP5256173 B2 JP 5256173B2 JP 2009263031 A JP2009263031 A JP 2009263031A JP 2009263031 A JP2009263031 A JP 2009263031A JP 5256173 B2 JP5256173 B2 JP 5256173B2
Authority
JP
Japan
Prior art keywords
data
database
database management
storage location
location information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2009263031A
Other languages
English (en)
Other versions
JP2011108027A (ja
Inventor
昌大 熊谷
憲宏 原
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2009263031A priority Critical patent/JP5256173B2/ja
Priority to US13/389,548 priority patent/US9002796B2/en
Priority to PCT/JP2010/001527 priority patent/WO2011061869A1/ja
Publication of JP2011108027A publication Critical patent/JP2011108027A/ja
Application granted granted Critical
Publication of JP5256173B2 publication Critical patent/JP5256173B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/275Synchronous replication
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1446Point-in-time backing up or restoration of persistent data
    • G06F11/1448Management of the data involved in backup or backup restore
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/18File system types
    • G06F16/182Distributed file systems
    • G06F16/184Distributed file systems implemented as replicated file system
    • G06F16/1844Management specifically adapted to replicated file systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor

Landscapes

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

Description

本発明は、データベース管理方法、データベース管理システム及びデータベース管理プログラムに関し、特にインメモリデータベースとディスク型データベースとの間におけるデータ連動に適用して好適なものである。
従来、インメモリデータベース(以下、「インメモリDB」という。)は、アクセス要求に対する高速なスポンスを提供するために、データを例えば揮発性メモリ上に常駐させ、時間のかかる外部記憶装置への入出力を行わない或いは制限するようになっている。
ところで、データベース管理システムにおいて、インメモリDBは、データがシステム停止時にメモリ上から消失するため、外部記憶装置にデータを保持するディスク型データベース(以下、「ディスク型DB」という。)にデータをバックアップするようにしている。
データをディスク型DBにバックアップするためには、インメモリDBとディスク型DBとのデータを一致させるデータ連動の技術が必要となる。
データ連動の技術において、非特許文献4には、、連動させる2つのデータベースのテーブルに定義されたユニークインデクスを利用することで、データベースのデータ内の各レコードに対応するレコードを、もう一方のデータベースのデータから一意に識別する技術が開示されている。
上述したデータ連動の技術で利用されるユニークインデクスは、ユーザのデータベース設計では存在しない場合がある。この場合、ユニークインデクスをデータベースに追加するユーザの手間の増加、ユニークインデクスを格納することによる外部記憶装置の使用量の増加、ユニークインデクスの更新に伴う処理オーバヘッドの増加という問題がある。
この問題に対して、特許文献1には、異なるデータベース間の物理格納位置情報のマッピング表を作成することで、ユニークインデクスの定義を不要とする技術が開示されている。
そして、データ連動元にレコードを追加した際、データ連動元へアクセスするだけでなく、データ連動先にもアクセスし、データ連動先が決定した物理格納位置情報を取得して、当該レコードのデータ連動が完了するようになっている。
これは、非特許文献2及び3に記述されているように(非特許文献3は非特許文献2の日本語訳)、データベース内に空き領域の情報を保持しているため、レコードの追加先である物理格納位置情報を決定するために、当該空き領域の情報を参照するからである。
特開2001-273175号公報
松浦 龍夫著「日経システム構築2006年3月号 特集 使える!インメモリーDB」、日経BP社、2006年2月26日、P.50−P.52 Jim Gray and Andreas Reuter、Transaction Processing:Concepts and Techniques、Morgan Kaufmann Publishers、1993年、P.757−P.760 ジム・グレイ(著)、アンドレアス・ロイター(著)、喜連川 優(翻訳)「トランザクション処理〈下〉―概念と技法」、日経BP社、2001年10月、P.897−P.900 Marie Buretta著「Data Replication: Tools and Techniques for Managing Distributed Information」WILEY COMPUTER PUBLISHING、1997年、P.144
しかしながら、特許文献1の技術では、データ連動先の外部記憶装置の障害等を原因とするデータ連動失敗時の再実行に備え、データ連動先で実行するSQLなどのデータ連動時に利用する情報を、データ連動が完了するまで削除することができない。
ここで、インメモリDBは、前述のように大量のデータを高速に処理するシステムで使用するため、レコードの追加が継続的に要求されることが多い。そのため、データ連動が遅延すると、データ連動時に利用する情報が削除できずに蓄積し、外部記憶装置の容量を圧迫する結果、新たな情報の出力ができなくなり、インメモリDBへレコードの追加ができなくなる。
本発明は以上の点を考慮してなされたもので、インメモリDBへレコードを追加した際のデータ連動時に高速にデータ連動を行い、インメモリDBへのレコードの追加を継続的に受け付けることのできるデータベース管理方法、データベース管理システム及びデータベース管理プログラムを提案するものである。
かかる課題を解決するため、本発明の一側面は、第1のデータベースを配置する主記憶を有する第1データベース管理装置と、第2のデータベースを配置する二次記憶を有する第2データベース管理装置とがネットワークを介して接続され、前記第1及び第2データベース管理装置が格納するデータを互いに反映させるシステムのデータベース管理方法であって、前記第1データベース管理装置は、前記第1のデータベースに追加するデータの前記第2のデータベースにおける書き出し先を示す格納位置情報を保持する第1のリストを備え、前記第1データベース管理装置が、前記第1のデータベースに任意のデータが追加された時に、当該データに前記第1のリストから前記格納位置情報を付加する第1のステップと、前記第1データベース管理装置が、前記格納位置情報を付加した前記データを前記第2データベース管理装置に送信し、該第2データベース管理装置に当該データの追加を要求する第2のステップと、前記第2データベース管理装置が、前記第2データベース管理装置からの前記データの追加の要求に応じて、前記データに付加された前記格納位置情報が示す前記第2のデータベースの格納位置に前記データを追加する第3のステップと、を有することを特徴とするデータベース管理方法。
さらに、本発明の一側面は、第1のデータベースを配置する主記憶を有する第1データベース管理装置と、第2のデータベースを配置する二次記憶を有する第2データベース管理装置とがネットワークを介して接続され、前記第1及び第2データベース管理装置が格納するデータを互いに反映させるシステムのデータベース管理方法であって、前記第1データベース管理装置は、前記第1のデータベースに追加するデータの前記第2のデータベースにおける書き出し先を示す格納位置情報を保持する第1のリストを備え、前記第1のデータベースに任意のデータが追加された時に、当該データに前記第1のリストから前記格納位置情報を付加し、当該格納位置情報を付加した当該データを前記第2データベース管理装置に送信し、前記第2データベース管理装置に当該データの追加を要求し、前記第2データベース管理装置は、前記第1データベース管理装置からの前記データの追加の要求に応じて、前記データに付加された前記格納位置情報が示す前記第2のデータベースの格納位置に前記データを追加することを特徴とする。
さらに、本発明の一側面は、データベース管理プログラムにおいて、第2のデータベースを配置する二次記憶を有する第2データベース管理装置に接続され、第1のデータベースを配置する主記憶を有するとともに該第1のデータベースに追加するデータの前記第2のデータベースにおける書き出し先を示す格納位置情報を保持する第1のリストを有する第1データベース管理装置に、前記第1のデータベースに任意のデータが追加された時に、当該データに前記第1のリストから前記格納位置情報を付加する第1のステップと、前記格納位置情報を付加した前記データを前記第2データベース管理装置に送信し、該第2データベース管理装置に当該データの追加を要求する第2のステップと、を実行させることを特徴とする。
本発明によれば、第1のデータベースへのレコード追加を継続的に受け付けることのできるデータベース管理方法、データベース管理システム及びデータベース管理プログラムを提供することができる。
本実施の形態によるデータベース管理システムの構成を示すブロック図である。 予約済みリストを説明するための図である。 予約指示リストを説明するための図である。 位置情報予約パラメタファイルを説明するための図である。 本実施の形態によるデータベース管理システムの動作を説明するための概念図である。 本実施の形態によるデータベース管理システムの動作を説明するための概念図である。 インメモリデータベース更新処理を説明するためのフローチャートである。 ディスク型データベース反映処理を説明するためのフローチャートである。 ディスク型データベース更新処理を説明するためのフローチャートである。 インメモリ型データベース反映処理を説明するためのフローチャートである。 予約済みリスト作成処理を説明するためのフローチャートである。 予約指示リスト作成処理を説明するためのフローチャートである。 予約済みリスト補充処理を説明するためのフローチャートである。 予約済み物理格納位置情報の表示結果の例を示す図である。 他の実施の形態による予約済みリストを説明するための図である。 他の実施の形態によるデータベース管理システムの動作を説明するための概念図である。
1……データベース管理システム、2……インメモリDB管理装置、3……ディスク型DB管理装置、4……端末装置、5……ネットワーク、6……外部記憶装置、61……予約指示リスト、63……ディスク型データベース、235……予約済みリスト、236……インメモリデータベース。
以下、図面を用いて、本発明の一実施の形態を詳述する。
(1)本実施の形態によるデータベース管理システムのハードウェア構成
図1において、1は全体として本実施の形態によるデータベース管理システムを示す。データベース管理システム1は、インメモリDB管理装置2(「第1データベース管理装置」に相当する。)とディスク型DB管理装置3(「第2のデータベース管理装置」に相当する。)と端末装置4とがネットワーク5を介して接続されている。また、ディスク型DB管理装置3が外部記憶装置6に接続されている。
インメモリDB管理装置2は、端末装置4からインメモリデータベース236へアクセス要求があった場合の管理やインメモリデータベース236のデータに変更があった場合のディスク型DB63(第2のデータベースに相当する。)への反映等を行う。また、インメモリDB管理装置2は、CPU21とインタフェース22とメモリ23とを備える。
CPU21は、インメモリDB管理装置2全体の動作制御を司るプロセッサであり、メモリ23に格納された各種制御プログラムに基づいて必要な処理を実行する。インタフェース22は、ネットワーク5に接続され、ディスク型DB管理装置3又は端末装置4とインメモリDB管理装置2との間の通信時にプロトコル制御を行う。
メモリ23は、半導体メモリ、ハードディスク等から構成され、OS(Operating System)などの制御プログラムを保持するために用いられるほか、CPU21のワークメモリとしても用いられる。また、メモリ23は、DBアクセス要求部231とDBアクセス処理部232と位置情報管理部233と予約済みリスト235(「第1のリスト」に相当する。)とインメモリDB236(「第1のデータベース」に相当する。)とを格納する。
DBアクセス要求解析部231は、端末装置4又はディスク型DB管理装置3からの要求を解析し、解析した要求に応じて、インメモリDB236へのアクセスをDBアクセス処理部232に要求する。
DBアクセス処理部232は、DBアクセス要求解析部231の要求に応じて、インメモリDB236にアクセスする。
位置情報管理部233は、インメモリDB236へのアクセス要求がレコードの追加である場合、予約済みリスト235から、インメモリDB236に追加するレコードのディスク型DB63における書き出し先を示す物理格納位置情報を取得する。
なお、本実施の形態では、データの格納位置情報として、物理的格納位置(例えば、HDDの物理的なアドレス等を適用する例について説明するが、論理的格納位置情報(例えば、HDD等から構成される論理ボリュームの論理アドレス等)をデータの格納位置情報としてもよい。
データ連動要求部234は、インメモリDB236に更新、追加及び削除等があった場合、その更新、追加及び削除をディスク型DB63(「第2のデータベースに相当する。」に反映させるようにディスク型DB管理装置3に要求する。
予約済みリスト235は、インメモリDB236に追加するレコードのディスク型DB63における反映先を示す物理格納位置情報を格納する。詳細に説明すると、予約済みリスト235は、図2に示すように、テーブル形式で、インメモリDB236に追加するレコードのディスク型DB63における反映先を示す予約済み物理格納位置情報欄2351と、その状態(使用中又は未使用)を示す状態欄2352と、予約済み物理格納位置情報数欄2353と、使用中物理格納位置情報数欄2354とから構成される。また、予約済みリスト235は、後述する予約指示リスト61に基づいて作成される。
インメモリDB236は、半導体メモリ内に形成されるデータベースであり、図5及び6に示すように、テーブル2361とインデクス2362とを備える。
テーブル2361は、データと、そのデータに対応するディスク型DB63におけるデータの物理格納位置の情報とから構成される。インデクス2362は、テーブル2361のデータを検索するために用いられ、ここでは、ディスク型DB63におけるデータの物理格納位置の情報が用いられている。
ディスク型DB管理装置3は、外部記憶装置6が格納するディスク型DB63に対する問い合わせやリソース管理などのディスク型DB63全体の管理を行う。また、ディスク型DB管理装置3は、CPU31とインタフェース32とメモリ33と外部記憶装置入出力インタフェース34とを備える。
CPU31は、ディスク型DB管理装置3全体の動作制御を司るプロセッサであり、メモリ33に格納された各種制御プログラムに基づいて必要な処理を実行する。インタフェース32は、ネットワーク5に接続され、インメモリDB管理装置2又は端末装置4とディスク型DB管理装置3との間の通信時にプロトコル制御を行う。
メモリ33は、半導体メモリ、ハードディスク等から構成され、OS(Operating System)などの制御プログラムを保持するために用いられるほか、CPU31のワークメモリとしても用いられる。また、メモリ33は、DBアクセス要求部331とDBアクセス処理部332と位置情報管理部333とデータ連動要求部334と予約指示リストバッファ335とDBバッファ336とを格納する。
DBアクセス要求解析部331は、端末装置4又はインメモリDB管理装置2からの要求を解析し、DBアクセス処理部332に、ディスク型DB63へのアクセスを要求する。
DBアクセス処理部332は、DBアクセス要求解析部331の要求に応じて、DBバッファ336を介して、ディスク型DB63にアクセスする。
位置情報管理部333は、ディスク型DB63に対するアクセス要求がレコードの追加である場合、予約指示リストバッファ335を介して、予約指示リスト61を参照し、予約指示リスト61(「第2のリスト」に相当する。)に登録されていない物理格納位置情報を取得する。
データ連動要求部334は、ディスク型DB63に更新があった場合、その更新をインメモリDB236に反映させるようにインメモリDB管理装置2に要求する。
ディスク型DB管理装置3は、外部記憶装置6と入出力インタフェース250を介して接続されている。
外部記憶装置6は、予約指示リスト61と位置情報予約パラメタファイル62とディスク型DB63とを格納する。
予約指示リスト61は、図3に示すように、ユーザが予約した、インメモリDB236に追加するレコードのディスク型DB63における反映先を示す物理格納位置情報欄611と、そのサイズの単位を示す予約単位欄612とから構成される。ディスク型DB管理装置3は、予約指示リストバッファ335を介して予約指示リスト61を参照する。予約単位は、ユーザが物理格納位置を予約する単位であり、ファイル、エクステント、ページ及びレコードの何れかである。ここで、ファイルは、データベースのデータを外部記憶装置6に1つのかたまりとして格納するため単位であり、1つ以上のエクステントから構成される。エクステントは、ファイル中の領域を割り当てる単位であり、1つ以上のページから構成される。ページは、外部記憶装置の入出力の単位であり、1つ以上のレコードから構成される。
位置情報予約パラメタファイル62は、ユーザが物理格納位置情報を予約するために、事前に作成するファイルである。予約指示リスト61は、複数の位置情報予約パラメタファイル62を読み込むことによって作成される。位置情報予約パラメタファイル62には、テーブル毎に、予約済み物理格納位置情報を登録する。予約の単位は、レコード単位の他、ファイル、エクステント、ページという複数のレコードをまとめた単位での指定をしても良い。例えば、図4に示す例において、「表1」という名前の位置情報予約パラメタファイル62には、レコード単位で「#3−1」、「#3−2」及び「#3−3」が予約され、ページ単位で「#5」及び「#6」が予約され、エクステント単位で「EXT3」が予約され、ファイル単位で「FILE2」が予約されている。
ディスク型DB63は、ハードディスク装置内に形成され、図5及び6に示すようにテーブル631を備える。テーブル631は、物理格納位置632が示す各格納位置に各データを保持する。なお、本実施形態では、ディスク型DB63をハードディスク装置内に形成する例について説明するが、本発明は、例えば、インメモリDB管理装置2のメモリ23を主記憶メモリと位置付けた場合に、二次記憶メモリとしての記憶領域として機能するものであれば、種々の記憶デバイスを適用することができる。例えば、光学ディスク、不揮発の半導体デバイス(例えば、SSD(Solid state disk))等でもよい。本実施の形態において、「ディスク」とは、これら回転磁気ディスク(HDD等)、光学ディスク及び不揮発の半導体デバイスを含むものとする。
(2)データベース管理システムの動作の概要
次に、図5及び6を参照して、データベース管理システム1の動作を簡単に説明する。
インメモリDB236は、レコード(図5の例では「CCC」)の追加要求を受け付けた場合に、テーブル2361にレコード「CCC」と、インデクス2362と予約済みリスト235を参照して取得した予約済みの物理格納位置情報「#3−1」とを追加する。
その後、インメモリDB236は、物理格納位置情報「#3−1」をレコード「CCC」に付加してディスク型DB63に送信し、ディスク型DB63に対してレコード追加要求を行う。
ディスク型DB63は、前記レコード追加要求を受け付け、テーブル112の前記物理格納位置情報「#3−1」が示す位置にレコード「CCC」を追加する。
以上のように、データベース管理システム1は、インメモリDB236へレコードを追加した際に予約済みリスト235を参照し、データ連動先であるディスク型DB63の物理格納位置情報632を決定する。これにより、ディスク型DB63のテーブル631を参照しなくとも、データ連動元であるインメモリDB管理装置236で連動先を判別することができ、データ連動性能を向上することが可能である。
また、ディスク型DB63が、レコード(図6の例では「DDD」)追加要求を受け付けた場合、テーブル631にレコード「DDD」を追加する。この時、予約指示リストバッファ335を介して、予約指示リスト61を参照し、予約指示リスト61に登録されている物理格納位置(図6の例では「#3−1」、「#3−2」及び「#3−3」)にはレコードを格納しないようにする。
その後、ディスク型DB63は、レコード「DDD」を格納した位置を示す物理格納位置情報113(図6の例では「#4−1」)をレコード「DDD」に付加してインメモリDB236に送信し、インメモリDB236に対して、レコード「DDD」の追加を要求する。
インメモリDB236は、レコード「DDD」の追加要求を受け付け、テーブル2361の空き領域にレコード「DDD」及び物理格納位置情報「#4−1」を追加する。また、インメモリDB236は、インデクス2362に物理格納位置情報「#4−1」を追加する。
以上のように、データベース管理システム1は、ディスク型DB63へレコードを追加した場合に、当該レコードの追加先であるディスク型DB63の物理格納位置情報632をインメモリDB236のテーブル2361に設定する。インメモリDB236に追加されたレコードは、予約済みの物理格納位置情報を利用しないため、予約済みリスト235を変更する必要が無い。
(3)データベース管理システム1における具体的な処理
(3−1)インメモリデータベース更新処理
ここで、図7を参照して、端末装置4からインメモリDB236へ更新要求があった場合のインメモリDB236の更新処理を説明する。
まず、インメモリDB管理装置2が端末装置4から更新要求SQLを受信すると、インメモリDB管理装置2のDBアクセス要求解析部231は、端末装置4からのインメモリDB236に対する更新要求SQLの解析を行いSQLの種別を決定し(SP101)、SQLの種別が追加、更新、削除の何れかであるかを判別する(SP102)。
ステップSP102において、SQLの種別が追加の場合、DBアクセス処理部232は、レコードの追加先を決定する(SP103)。位置情報管理部233は、予約済みリスト235を参照して、予約済みリスト104の先頭から予約済み物理格納位置情報を1つ取得し(SP104)、DBアクセス処理部232は、テーブル2361に、取得した予約済み物理格納位置情報とレコードとを追加し(SP105)、ステップSP114に進む。
ステップSP102において、SQLの種別が更新の場合、DBアクセス処理部232は、更新するレコードを選択し(SP106)、選択するレコードが存在するか否かを判別する(SP107)。ステップSP107において、否定結果を得た場合(SP107:NO)、処理を終了する。ステップSP107において、肯定結果を得た場合(SP107:YES)、位置情報管理部233は、インデクス2362を参照して、物理格納位置情報を取得し(SP108)、DBアクセス処理部232は、テーブル2361におけるレコードを更新し(SP109)、ステップSP114に進む。
ステップSP102において、SQLの種別が削除の場合、DBアクセス処理部262は、削除するレコードを選択し(SP110)、選択するレコードが存在するか否かを判別する(SP111)。ステップSP111において、否定結果を得た場合(SP111:NO)、処理を終了する。ステップSP111において、肯定結果を得た場合(SP111:YES)、位置情報管理部263は、インデクス2362を参照して、物理格納位置情報を取得し(SP112)、DBアクセス処理部262は、テーブル2361におけるレコードを削除し(SP113)、ステップSP114に進む。
ステップSP105,SP109,SP113において、レコードを追加、更新、又は削除した後に、データ連動要求部234は、ディスク型DB111にデータ連動するためのデータ連動SQLを生成する(SP114)。ただし、データ連動SQLには、取得した物理格納位置情報が付加されたレコードが含まれる。そして、データ連動要求部234は、ディスク型DB管理装置3にデータ連動SQLを送信し、その実行を要求する(SP115)。
その後、インメモリDB管理装置2は、SQLに記載された全てのレコードについて処理を終了したか否かを判別する(SP116)。ステップSP116において、肯定結果を得た場合(SP116:YES)、処理を終了する。ステップSP116において、否定結果を得た場合(SP116:NO)、ステップSP102から処理を繰り返す。
(3−2)ディスク型データベース反映処理
次に、図8を参照して、インメモリDB236に更新があった場合のディスク型DB63への反映処理を説明する。
ディスク型DB管理装置3のDBアクセス要求解析部331が、インメモリDB管理装置2がステップSP115で送信したデータ連動SQLを受信した場合(SP201)、DBアクセス要求解析部331は、ディスク型DB63に対するデータ連動SQLの解析を行いSQLの種別を決定し(SP202)、SQLの種別が追加、更新又は削除の何れかであるかを判別する(SP203)。
ステップSP203において、データ連動SQLの種別が追加の場合、DBアクセス処理部332は、データ連動SQLに含まれる物理格納位置情報からデータ連動SQLに含まれるレコードの追加先を判別する(SP204)。そして、DBアクセス処理部332は、テーブル631におけるステップSP204で判別した追加先に、レコードを追加し(SP205)、ステップSP212に進む。
ステップSP203において、SQLの種別が更新の場合、DBアクセス処理部332は、更新するレコードを選択し(SP206)、選択するレコードが存在するか否かを判別する(SP207)。ステップSP207において、否定結果を得た場合(SP207:NO)、処理を終了する。ステップSP207において、肯定結果を得た場合(SP207:YES)、DBアクセス処理部332は、テーブル631におけるデータ連動SQLに含まれる物理格納位置情報が示す格納位置に格納されるレコードを更新し(SP208)、ステップSP212に進む。
ステップSP203において、SQLの種別が削除の場合、DBアクセス処理部332は、削除するレコードを選択し(SP209)、選択するレコードが存在するか否かを判別する(SP210)。ステップSP210において、否定結果を得た場合、処理を終了する(SP210:NO)。ステップSP210において、肯定結果を得た場合(SP210:YES)、DBアクセス処理部332は、テーブル631におけるデータ連動SQLに含まれる物理格納位置情報が示す格納位置に格納されるレコードを削除し(SP211)、ステップSP212に進む。
ステップSP205、SP208、SP211において、レコードを追加、更新、又は削除した後に、ディスク型DB管理装置3は、SQLに記載された全てのレコードについて処理を終了したか否かを判別する(SP212)。ステップSP212において、肯定結果を得た場合(SP212:YES)、処理を終了する。ステップSP212において、否定結果を得た場合(SP212:NO)、ステップSP203から処理を繰り返す。
このようにして、ディスク型DB63にインメモリDB236の更新を連動させる。
(3−3)ディスク型データベース更新処理
次に、図9を参照して、端末装置4からディスク型DB63へ更新要求があった場合のディスク型DB63の更新処理を説明する。
まず、ディスク型DB管理装置3が端末装置4からのディスク型DB63に対する更新系SQLを受信すると、ディスク型DB管理装置3のDBアクセス要求解析部331は、受信した更新要求SQLの解析を行い、SQLの種別を決定し(SP301)、SQLの種別が追加、更新、削除の何れかであるかを判別する(SP302)。
ステップSP302において、SQLの種別が追加の場合、DBアクセス処理部332は、レコードの追加先を決定する(SP303)。次に、位置情報管理部263は、予約指示リスト61を参照して、追加先が予約指示のある物理格納位置情報と一致しているか否かを判別する(SP304)。ステップSP304において肯定結果を得た場合には(SP304:YES)、ステップSP303に戻る。ステップSP304において否定結果を得た場合には(SP304:NO)、ステップSP303で決定した追加先にレコードを追加し(SP305)、ステップSP314に進む。
ステップSP302において、SQLの種別が更新の場合、DBアクセス処理部332は、更新するレコードの選択を行い(SP306)、選択するレコードがあるか否かを判別する(SP307)。ステップSP307において、否定結果を得た場合(SP307:NO)、処理を終了する。ステップSP307において、肯定結果を得た場合(SP307:YES)、位置情報管理部333は、物理格納位置情報を取得して(SP308)、DBアクセス処理部332は、レコードの更新を行う(SP309)。
ステップSP302において、SQLの種別が削除の場合、DBアクセス処理部332は、削除するレコードの選択を行い(SP310)、選択するレコードがあるか否かを判別する(SP311)。ステップSP311において、否定結果を得た場合(SP311:NO)、処理を終了する。ステップSP311において、肯定結果を得た場合(SP311:YES)、位置情報管理部333は、物理格納位置情報を取得して(SP312)、DBアクセス処理部332は、レコードの削除を行う(SP313)。
ステップSP305,SP309,SP313において、レコードを追加、更新、又は削除した後に、データ連動要求部334が、インメモリDB236にデータ連動するためのデータ連動SQLを生成する(SP314)。ただし、データ連動SQLには、追加先の物理格納情報又は取得した物理格納情報が付加されたレコードを含む。そして、データ連動要求部334は、インメモリDB管理装置2にデータ連動SQLを送信し、その実行を要求する(SP315)。
その後、ディスク型DB管理装置3は、SQLに記載された全てのレコードについて処理を終了したか否かを判別する(SP316)。ステップSP316において、肯定結果を得た場合(SP316:YES)、処理を終了する。ステップSP316において、否定結果を得た場合(SP316:NO)、ステップSP302から処理を繰り返す。
(3−4)インメモリデータベース反映処理
次に、図10を参照して、ディスク型DB63に更新があった場合のインメモリDB236への反映処理を説明する。
インメモリDB管理装置2のDBアクセス要求解析部231が、ディスク型DB管理装置3がステップSP315で送信したデータ連動SQLを受信した場合(SP401)、DBアクセス要求解析部231は、インメモリDB236に対するデータ連動SQLの解析を行いSQLの種別を決定し(SP402)、SQLの種別が追加、更新又は削除の何れかであるかを判別する(SP403)。
ステップSP403において、データ連動SQLの種別が追加の場合、DBアクセス処理部232は、データ連動SQLに含まれる物理格納位置情報からデータ連動SQLに含まれるレコードの追加先を判別する(SP404)。そして、DBアクセス処理部232は、テーブル2361におけるステップSP404で判別した追加先に、レコードを追加し(SP405)、ステップSP412に進む。
ステップSP403において、SQLの種別が更新の場合、DBアクセス処理部232は、更新するレコードを選択し(SP406)、選択するレコードが存在するか否かを判別する(SP407)。ステップSP407において、否定結果を得た場合(SP407:NO)、処理を終了する。ステップSP407において、肯定結果を得た場合(SP407:YES)、DBアクセス処理部232は、テーブル2361におけるデータ連動SQLに含まれる物理格納位置情報が示す格納位置に格納されるレコードを更新し(SP408)、ステップSP412に進む。
ステップSP403において、SQLの種別が削除の場合、DBアクセス処理部232は、削除するレコードを選択し(SP409)、選択するレコードが存在するか否かを判別する(SP410)。ステップSP410において、否定結果を得た場合(SP410:NO)、処理を終了する。ステップSP410において、肯定結果を得た場合(SP410:YES)、DBアクセス処理部232は、テーブル2361におけるデータ連動SQLに含まれる物理格納位置情報が示す格納位置に格納されるレコードを削除し(SP411)、ステップSP412に進む。
ステップSP405,SP408,SP411において、レコードを追加、更新、又は削除した後に、インメモリDB管理装置2は、SQLに記載された全てのレコードについて処理を終了したか否かを判別する(SP412)。ステップSP412において、肯定結果を得た場合(SP412:YES)、処理を終了する。ステップSP412において、否定結果を得た場合(SP412:NO)、ステップSP403から処理を繰り返す。このようにして、インメモリDB236にディスク型DB63の更新を連動させる。
(3−5)予約済みリスト作成処理
ここで、図11を参照して、インメモリDB管理装置2及びディスク型DB管理装置3が協働することによって予約済みリスト235を作成する処理を説明する。インメモリDB管理装置2は、インメモリDB236を作成した後に、予約済みリスト104を作成する。
先ず、インメモリDB管理装置2は、インメモリDB236を作成した場合、ディスク型管理装置3にインメモリDB236を作成した旨を通知する。
ディスク型管理装置3がその通知を受信すると、DBアクセス処理部332は、DBバッファ336を介して、ディスク型DB63のデータをエクスポートする(SP501)。次に、位置情報管理部333が、予約指示リストバッファ335を介して、予約指示リスト61の予約済み物理格納位置情報をエクスポートし(SP502)、データ連動要求部334が、インメモリDB管理装置2に、エクスポートしたデータの読み込み要求を行う(SP503)。
次に、ディスク型DB装置3は、ディスク型DB63の全データ及び予約指示リスト61の全予約済み物理格納位置情報を読み込んだか否かを判別する(SP504)。ステップSP504において、肯定結果を得ると、処理を終了する。ステップSP504において、否定結果を得ると、ステップSP501に戻る。
このようにして、ディスク型DB装置3は、ディスク型DB63の全データ及び予約指示リスト61の全予約済み物理格納位置情報についてエクスポートし、エクスポートしたデータの読み込み要求をインメモリDB236に対して行う。
一方、インメモリDB管理装置2のDBアクセス解析部231が、ディスク型DB管理装置3がステップSP503において行った要求を受け付けた場合に(SP601)、DBアクセス処理部262は、インメモリDB236のテーブル2361に対して、ディスク型DB63のデータのインポートを行う(SP602)。その後、位置情報管理部263が、インデクス2362を作成し(SP603)、読み込んだ予約済み物理格納位置情報に基づいて予約済みリスト235を作成し(SP604)、処理を終了する。
(3−6)予約指示リスト作成処理
ここで、図12を参照して、ディスク型DB管理装置3が予約指示リスト61を作成する処理を説明する。
まず、ディスク型DB管理装置3の位置情報管理部333が、ユーザが作成した位置情報予約パラメタファイル62を読み込み(SP701)、パラメタファイルの内容を予約指示リスト61に登録する(SP702)。ディスク型DB管理装置3は、全ての位置情報予約パラメタファイル62を読み込んだか否かを判別する(SP703)。ステップSP703において、肯定結果(SP703:YES)を得た場合には、処理を終了する。ステップSP703において、否定結果を得た場合には(SP703:NO)、ステップSP701に戻る。
このようにして、ユーザは、複数の位置情報予約パラメタファイル62を作成することができ、複数の位置情報予約パラメタファイル62から予約指示リスト61を作成することができる。
(3−7)予約済みリスト補充処理
ここで、図13を参照して、予約済みリスト235の物理格納位置が少なくなった場合に、物理格納位置を補充する予約済みリスト補充処理を説明する。本処理は、ステップSP104において、位置情報管理部233が、予約済みリスト235から予約済み物理格納位置情報を取得した時に開始される。
先ず、インメモリDB管理装置2の位置情報管理部233は、予約済みリスト235から予約済み物理格納位置情報を取得した場合に、予約済みリスト235の未使用状態の位置情報のうち、先頭の情報の状態を使用中に変更する(SP801)。
次に、位置情報管理部233が、予約済みリスト104の使用中物理格納位置情報数2354から「1」を減算する(SP802)。位置情報管理部233は、予約済み物理格納位置情報数における使用中物理格納位置情報数の割合である使用率が8割以上であるか否かを判別する(SP803)。
ステップSP803において、否定結果が得られた場合(即ち使用率が8割以上の場合(SP803:YES))、補充の必要がないと判断し、その時点で処理を終了する。
ステップSP803において、肯定結果が得られた場合(即ち使用率が8割未満の場合(SP803:NO))、位置情報管理部233が、ディスク型DB管理装置3に予約済み物理格納位置情報の補充を要求し(SP804)、ディスク型DB管理装置3からの予約済みリスト連動要求を受け付け(SP805)、予約済みリスト235を連動させて補充し(SP806)、処理を終了する。
一方、ディスク型DB管理装置3の位置情報管理部333は、予約済み物理格納位置情報の補充要求を受け付けると(SP901)、補充サイズを計算する(SP902)。補充サイズの計算は、例えば次の計算式で行う。
補充する予約済み物理格納位置情報数
=補充前の予約済み物理格納位置情報数×0.2
その後、位置情報管理部333は、計算した補充サイズ分だけ、ディスク型DB63における物理格納位置を確保し、予約指示リスト61の予約済み物理格納位置情報を補充し(SP903)、インメモリDB管理装置2に予約済みリスト235への連動要求を行い(SP904)、処理を終了する。このようにして、使用中の予約済み物理格納位置情報が多くなった場合には、物理格納位置情報を確保して補充することによって、常に未使用の予約済み物理格納位置情報を確保することができる。
図14は、予約済み物理格納位置情報の表示結果の例を示す図である。予約済み物理格納位置情報は、インメモリDB236のテーブル毎に分類できる。例えば、ユーザはコマンドなどのインタフェースを用いて、テーブル単位に、テーブル名と予約済み物理格納位置情報の使用率、使用中の位置情報を表示させる。予約済み物理格納位置情報は、ディスク型DB管理装置3の位置情報管理部333が、予約指示リスト61から求める。位置情報は、ファイル、エクステント、ページ、レコードから構成される。予約済み物理格納位置情報の使用率は、インメモリDB管理装置2の位置情報管理部233が、予約済みリスト235から以下の計算式で求める。
予約済み物理格納位置情報の使用率
=使用中物理格納位置情報数÷予約済み物理格納位置情報数
(5)他の実施の形態
なお、上述の実施の形態では、予約済みリスト235をテーブル形式で保持したが、インデクス形式で保持してもよい。
この場合、図15に示すように、インデクスを構成するインデクスエントリ2355において、予約済み物理格納位置情報をインデクスキー2356として保持し、インデクスキー2356と合わせて物理格納位置情報2357を保持することで実現できる。ここで、インデクスキー2356は、ディスク型DB63におけるレコードの格納位置を示し、これに対応するインメモリDB236のレコードの格納位置を物理格納位置情報2357が示す。物理格納位置情報2357が「0」の場合、予約済み物理格納位置情報が示すインメモリDB236の格納位置が未使用であることを示す。
また、上述の実施の形態では、ディスク型DB63における物理格納位置情報632をインデクスとして用いたが、インメモリDB236が格納するデータとディスク型DB63が格納するデータとの間に一意性が保証できるユニークインデクスが存在する場合には、そのユニークインデクスを用いてもよい。
図16は、ユニークキーが存在するインメモリDBの更新処理を示す概念図である。インメモリDB236は、レコード(図16の例では「CCC」)追加要求を受け付け、テーブル2363にレコード「CCC」と、予約済みリスト235から取得したユニークキー(図16の例では「0004」)を追加する。
その後、ユニークキー「0004」をレコード「CCC」に付加し、ディスク型DB63に対して、レコード追加要求を行う。その後、ディスク型DB63は、ユニークキー「0004」が付加されている物理格納位置にレコード「CCC」を格納する。
以上のように、テーブルが既にユニークキーを保持している場合、物理格納位置情報として、ユニークキーを使用し、データを連動することが可能である。

Claims (8)

  1. 端末装置と、第1のリスト及び第1のデータベース配置された主記憶装置を有する第1データベース管理装置と、第2のリスト及び第2のデータベース配置された二次記憶装置を有する第2データベース管理装置とが互いに通信可能に接続して構成され、前記第1及び第2データベース管理装置が格納するデータを互いに反映させるデータベース管理システムのデータベース管理方法であって、
    前記第1及び第2のリストは、前記第1のデータベースに追加するデータの前記第2のデータベースにおける書き出し先を示す格納位置情報を保持し、
    前記第1データベース管理装置が、前記端末装置からデータの追加要求を受け付けた場合、前記第1のリストを参照して、当該データに前記格納位置情報を付加し、前記格納位置情報を付加したデータを前記第2データベース管理装置に送信するとともに、送信したデータの追加要求を行うのステップと、
    前記第2データベース管理装置が、前記端末装置からデータの追加要求を受け付けた場合、前記第2のリストを参照して、前記第2のリストに保持されている前記格納位置情報が示す格納位置以外の格納位置に当該データを追加し、追加したデータの格納位置を格納位置情報として当該データに付加し、当該格納位置情報を付加したデータを前記第1データベース管理装置に送信するとともに、送信したデータの追加要求を行う第2のステップと、
    前記第1データベース管理装置が、前記第2データベース管理装置からデータの追加要求を受け付けた場合、前記第1のデータベースに当該データ及び当該データに付加された格納位置情報を追加する第3のステップと
    を備えることを特徴とするデータベース管理方法。
  2. 前記格納位置情報には、前記第1のデータベースのデータと前記第2のデータベースのデータとを対応付け且つ前記第1及び第2のデータベースが格納するデータにユニークキーを使用する
    ことを特徴とする請求項1に記載のデータベース管理方法。
  3. 前記第2データベース管理装置は、
    前記第1のデータベースの作成時に、前記第2のリストが保持する前記格納位置情報を前記第1データベース管理装置に送信し、
    前記第1データベース管理装置は、
    受信した前記格納位置情報に基づいて前記リストを作成する
    ことを特徴とする請求項1に記載のデータベース管理方法。
  4. 前記第1データベース管理装置は、
    前記リストに保持された前記格納位置情報のうちのデータが書き込まれている前記格納位置情報の割合を算出し、
    前記割合が所定の閾値以上の場合に、前記第2データベース管理装置に対して前記第1のリストが保持する前記格納位置情報の補充を要求し、
    前記第2データベース管理装置は、
    前記補充を要求された場合に、前記第1のデータベースに追加するデータの前記第2データベースにおける新たな書き出し先を確保し、
    確保した前記新たな書き出し先の格納位置情報を前記第1データベース管理装置に送信し、
    前記第1データベース管理装置は、
    受信した前記新たな書き出し先の格納位置情報を前記第1のリストに補充する
    ことを特徴とする請求項1に記載のデータベース管理方法。
  5. 前記第2データベース管理装置は、
    前記補充を要求された場合に、前記第1のリストに保持されている前記格納位置情報の数が所定数倍になるように、前記第1のデータベースに追加するデータの前記第2のデータベースにおける新たな書き出し先を確保し、
    確保した前記新たな書き出し先の格納位置情報を前記第1データベース管理装置に送信する
    ことを特徴とする請求項に記載のデータベース管理方法。
  6. 前記第2データベース管理装置は、
    前記第2のデータベースに対してデータを更新又は削除した場合に、当該データに当該データの格納位置情報を付加して、前記第1データベース管理装置に送信し、当該データの更新又は削除を要求し、
    前記第1データベース管理装置は、
    前記第1のデータベースが格納するデータと前記第2のデータベースが格納するデータとを対応付ける前記第2のデータベースのデータの格納位置を示す格納位置情報からなるインデクスを備え、
    前記データと前記データに付加された前記格納位置情報とを受信した場合に、前記インデクスを参照して、受信した当該格納位置情報に対応する前記第1のデータベースにおけるデータを更新又は削除する
    ことを特徴とする請求項に記載のデータベース管理方法。
  7. 端末装置と、第1のリスト及び第1のデータベース配置された主記憶装置を有する第1データベース管理装置と、第2のリスト及び第2のデータベース配置された二次記憶装置を有する第2データベース管理装置とが互いに通信可能に接続して構成され、前記第1及び第2データベース管理装置が格納するデータを互いに反映させるデータベース管理システムであって、
    前記第1及び第2のリストは、前記第1のデータベースに追加するデータの前記第2のデータベースにおける書き出し先を示す格納位置情報を保持し、
    前記第1データベース管理装置は、
    前記端末装置からデータの追加要求を受け付けた場合、前記第1のリストを参照して、当該データに前記格納位置情報を付加し、当該格納位置情報を付加した当該データを前記第2データベース管理装置に送信するとともに、送信したデータの追加要求を行い
    前記第2データベース管理装置からデータの追加要求を受け付けた場合、前記第1のデータベースに当該データ及び当該データに付加された格納位置情報を追加し、
    前記第2データベース管理装置は、
    前記端末装置からデータの追加要求を受け付けた場合、前記第2のリストを参照して、前記第2のリストに保持されている前記格納位置情報が示す格納位置以外の格納位置に当該データを追加し、追加したデータの格納位置を格納位置情報として当該データに付加し、当該格納位置情報を付加したデータを前記第1データベース管理装置に送信するとともに、送信したデータの追加要求を行う
    ことを特徴とするデータベース管理システム。
  8. 端末装置と、第2のデータベース及び前記第2のデータベースにおけるデータの格納位置情報を保持する第2のリストが配置された二次記憶装置を有する第2データベース管理装置に接続され、第1のデータベース及び前記第2のデータベースにおける格納位置情報を保持する第1のリストが配置された主記憶装置を有する第1データベース管理装置に、
    前記端末装置からデータの追加要求を受け付けた場合、前記第1のリストを参照して、前記格納位置情報を追加対象のデータに付加する第1のステップと、
    前記格納位置情報を付加したデータを前記第2データベース管理装置に送信するとともに、送信したデータの追加要求を行う第2のステップと、
    前記第2データベース管理装置からデータの追加要求を受け付けた場合、前記第1のデータベースに当該データ及び当該データに付加された格納位置情報を追加する第3のステップと
    を実行させることを特徴とするデータベース管理プログラム。
JP2009263031A 2009-11-18 2009-11-18 データベース管理方法、データベース管理システム及びデータベース管理プログラム Expired - Fee Related JP5256173B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2009263031A JP5256173B2 (ja) 2009-11-18 2009-11-18 データベース管理方法、データベース管理システム及びデータベース管理プログラム
US13/389,548 US9002796B2 (en) 2009-11-18 2010-03-04 Database management method, database management system and database management program
PCT/JP2010/001527 WO2011061869A1 (ja) 2009-11-18 2010-03-04 データベース管理方法、データベース管理システム及びデータベース管理プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2009263031A JP5256173B2 (ja) 2009-11-18 2009-11-18 データベース管理方法、データベース管理システム及びデータベース管理プログラム

Publications (2)

Publication Number Publication Date
JP2011108027A JP2011108027A (ja) 2011-06-02
JP5256173B2 true JP5256173B2 (ja) 2013-08-07

Family

ID=44059358

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009263031A Expired - Fee Related JP5256173B2 (ja) 2009-11-18 2009-11-18 データベース管理方法、データベース管理システム及びデータベース管理プログラム

Country Status (3)

Country Link
US (1) US9002796B2 (ja)
JP (1) JP5256173B2 (ja)
WO (1) WO2011061869A1 (ja)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10114908B2 (en) * 2012-11-13 2018-10-30 International Business Machines Corporation Hybrid table implementation by using buffer pool as permanent in-memory storage for memory-resident data
US9952975B2 (en) 2013-04-30 2018-04-24 Hewlett Packard Enterprise Development Lp Memory network to route memory traffic and I/O traffic
KR101679011B1 (ko) * 2014-06-26 2016-11-24 주식회사 알티베이스 데이터베이스에서 데이터 이동을 처리하는 방법 및 장치
JP6690829B2 (ja) * 2015-08-28 2020-04-28 国立大学法人 東京大学 計算機システム、省電力化方法及び計算機
CN107704196B (zh) * 2017-03-09 2020-03-27 深圳壹账通智能科技有限公司 区块链数据存储***和方法

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001160942A (ja) * 1999-12-02 2001-06-12 Matsushita Electric Ind Co Ltd サーバシステム
JP3698947B2 (ja) 2000-03-27 2005-09-21 日立ソフトウエアエンジニアリング株式会社 データベース処理方法およびデータベース処理システム
US7403945B2 (en) * 2004-11-01 2008-07-22 Sybase, Inc. Distributed database system providing data and space management methodology
US7634507B2 (en) * 2006-08-30 2009-12-15 Inmage Systems, Inc. Ensuring data persistence and consistency in enterprise storage backup systems
WO2008049102A2 (en) * 2006-10-19 2008-04-24 Fair Thomas T System and methods for zero-configuration data backup
WO2008105098A1 (ja) * 2007-02-28 2008-09-04 Fujitsu Limited メモリミラー化制御方法
JP2008310517A (ja) * 2007-06-13 2008-12-25 Hitachi Ltd データ同一化方法、データ同一化プログラム、および、現用系装置

Also Published As

Publication number Publication date
US9002796B2 (en) 2015-04-07
JP2011108027A (ja) 2011-06-02
WO2011061869A1 (ja) 2011-05-26
US20120209891A1 (en) 2012-08-16

Similar Documents

Publication Publication Date Title
TWI492077B (zh) 檔案系統的檢查點
JP5082310B2 (ja) データ移行装置及びプログラム
US8103847B2 (en) Storage virtual containers
US7809779B2 (en) Method of creating symbolic link capable of being compatible with file system, and method and apparatus for accessing file or directory by using symbolic link
JP5869661B2 (ja) ネットワークストレージシステムにリンクされるローカルストレージ
JP5485866B2 (ja) 情報管理方法、及び情報提供用計算機
US8024363B2 (en) Information processing apparatus, information processing method, program and program recording medium
US20150193434A1 (en) Storage media abstraction for uniform data storage
JP5256173B2 (ja) データベース管理方法、データベース管理システム及びデータベース管理プログラム
US7305537B1 (en) Method and system for I/O scheduler activations
KR101587631B1 (ko) 클라우드 기반 로컬 장치와 로컬 장치의 파일 읽기 및 저장 방법
JP4837378B2 (ja) データの改竄を防止する記憶装置
TW201520889A (zh) 混合儲存的控制方法及混合儲存系統
CN103597440A (zh) 用于创建克隆文件的方法以及采用该方法的文件***
KR101365438B1 (ko) Mtp 디바이스가 미디어 파일을 관리하는 방법 및 이를위한 장치
CN103999058A (zh) 带驱动器***服务器
EP1837783A1 (en) Managing data in a file system
CN109804359A (zh) 用于将数据回写到存储设备的***和方法
US20120005233A1 (en) Computer system and recording medium
JP4227931B2 (ja) 情報記憶装置、情報格納方法及び情報記憶処理プログラム
US10359964B2 (en) Reducing time to read many files from tape
US10838641B2 (en) Defragmenting backup objects
CN107172152B (zh) 一种基于ceph集群cap机制统计配额***及方法
JP2010225024A (ja) ストレージ装置とそのファイル制御方法およびストレージシステム
US8082230B1 (en) System and method for mounting a file system on multiple host computers

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20121218

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130214

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20130326

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130422

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

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

Free format text: PAYMENT UNTIL: 20160426

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees