(57)【特許請求の範囲】
【請求項１】
行型のデータベースに対して行われた操作に関する情報を所定の処理単位で列型のデータベースに反映させる反映処理を行うデータベース管理システムにおける処理単位サイズ算出プログラムであって、
前記データベース管理システムにおいて前記処理単位で行われる多版同時実行制御の処理コストに関する情報、及び、前記反映処理が前回実行された後に前記行型のデータベースに対して行われた操作に関する情報を前記列型のデータベースの形態に変換する処理の処理コストに関する情報に基づき、処理単位基準値を算出し、
前記処理単位基準値、及び、複数の前記処理単位に含まれる有効行数の偏りに関する情報に基づき、前記処理単位のサイズを算出する
処理をコンピュータに実行させることを特徴とする処理単位サイズ算出プログラム。
【請求項２】
前記処理単位のサイズを算出する処理は、前記偏りと該偏りの最大値との割合に基づき、前記処理単位のサイズを算出することを特徴とする請求項１に記載の処理単位サイズ算出プログラム。
【請求項３】
前記反映処理は、削除された行を表す削除ベクトルを前記処理単位毎に作成し、
前記処理単位のサイズを算出する処理は、前記削除ベクトルを用いて、前記偏りを算出することを特徴とする請求項２に記載の処理単位サイズ算出プログラム。
【請求項４】
前記反映処理は、現存する全トランザクションから可視のデータを前記列型のデータベースに反映させることを特徴とする請求項１、２又は３に記載の処理単位サイズ算出プログラム。
【請求項５】
行型のデータベースに対して行われた操作に関する情報を所定の処理単位で列型のデータベースに反映させる反映処理を行うデータベース管理システムにおける処理単位サイズ算出方法であって、
前記データベース管理システムにおいて前記処理単位で行われる多版同時実行制御の処理コストに関する情報、及び、前記反映処理が前回実行された後に前記行型のデータベースに対して行われた操作に関する情報を前記列型のデータベースの形態に変換する処理の処理コストに関する情報に基づき、処理単位基準値を算出し、
前記処理単位基準値、及び、複数の前記処理単位に含まれる有効行数の偏りに関する情報に基づき、前記処理単位のサイズを算出する
処理をコンピュータが実行することを特徴とする処理単位サイズ算出方法。
【請求項６】
行型のデータベースに対して行われた操作に関する情報を所定の処理単位で列型のデータベースに反映させる反映処理を行うデータベース管理システムにおける処理単位サイズ算出装置であって、
前記データベース管理システムにおいて前記処理単位で行われる多版同時実行制御の処理コストに関する情報、及び、前記反映処理が前回実行された後に前記行型のデータベースに対して行われた操作に関する情報を前記列型のデータベースの形態に変換する処理の処理コストに関する情報に基づき、処理単位基準値を算出する第１算出部と、
前記第１算出部により算出された処理単位基準値、及び、複数の前記処理単位に含まれる有効行数の偏りに関する情報に基づき、前記処理単位のサイズを算出する第２算出部と
を有することを特徴とする処理単位サイズ算出装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、処理単位サイズ算出プログラム、処理単位サイズ算出方法及び処理単位サイズ算出装置に関する。
【背景技術】
【０００２】
リレーショナルデータベース管理システム（Relational  Database  Management  System：ＲＤＢＭＳ）では、ＯＬＴＰ（Online  Transaction  Processing）とＯＬＡＰ（Online  Analytical  Processing）の２つの処理が行われる。ＯＬＴＰは、データの挿入・更新・削除を行う処理であり、ＯＬＡＰは、すでに蓄積されたデータに統計処理等を行う処理である。【０００３】
図１０は、ＯＬＴＰとＯＬＡＰの特徴を示す図である。図１０において、行型とは、１つの行に含まれるデータをまとめて記憶する行型のデータベースを示し、列（カラム）型とは、１つの列に含まれるデータをまとめて記憶する列型のデータベースを示す。【０００４】
図１０に示すように、ＯＬＴＰでは、更新処理が発生するが、ＯＬＡＰと比較して少数のデータに対する検索が行われる。したがって、ＯＬＴＰでは、行型を用いる方が列型を用いるより処理が速い。一方、ＯＬＡＰでは、特定の列に関する集計等で大量データの集計が行われる。したがって、ＯＬＡＰでは、列型を用いる方が行型を用いるより処理が速い。このため、データの挿入、更新及び削除の操作は行型のデータベースに対して行われ、日毎、週毎等非同期に行型のデータベースのデータを列型のデータベースに移す処理が行われる。【０００５】
近年、直近の集計データをビジネスに生かすことが求められている。例えば、午前の売り上げ状況に基づいて、午後の配送計画を策定することが行われる。このため、行型のデータベースと列型のデータベースの両方の利点を備えたデータベース管理システムに対するニーズが高まっている。【０００６】
なお、データ領域に格納されるページの更新をシャドウ領域から取得される空きページを用いて行い、コミット時毎にシャドウ領域の有効ページのリストを用いてデータ領域を更新することで、データの断片化を防止する技術がある。【０００７】
また、バックアップ開始と終了の間、複数のトランザクションが最新のバージョンを更新していても、データベース管理システムがバックアップ対象であるデータベースの一貫性を保障することで、単純な作業工程でバックアップを可能とする技術がある。【０００８】
また、データベースの各表領域に配置されているセグメント毎の次に割り当てられるエクステントサイズの最大値と各表領域の連続未使用領域の空き容量とを比較することによって、新たなエクステントの割り当ての差異の記憶容量不足を事前に察知する技術がある。【０００９】
また、データ形式を節点とし、変換方法を枝とし、データ変換にかかるコストを重みとする重み付き有向グラフを記憶し、データ変換の組合わせを有向グラフの最短路問題を解くことによって最適なデータ変換の組合せを取得する技術がある。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開２００６−１０６８６８号公報
【特許文献２】特開２００２−３１８７１７号公報
【特許文献３】特開２００１−１７５５１３号公報
【特許文献４】特開２００１−７５８４４号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
ＯＬＴＰによる更新データを同期的に利用するＯＬＡＰにおいては、ＯＬＴＰトランザクションと共存するためにＭＶＣＣ（Multi  Version  Concurrency  Control：多版同時実行制御）が必要になる。ここで、ＭＶＣＣとは、マルチユーザ環境において、データ整合性の維持にデータベースの多版を利用する技術である。同時実行制御には、ロック機構が用いられることもあるが、ロック機構と比較すると、ＭＶＣＣには、読み込みロックの獲得と書き込みロックの獲得が競合しないという利点がある。【００１２】
しかしながら、従来の行単位のＭＶＣＣには、オーバーヘッドが無視できないという問題がある。図１１は、行単位のＭＶＣＣの問題を説明する図である。図１１に示すように、集計処理にかかる時間は、行型のデータベースと比較して列型のデータベースでは短い。このため、列型のデータベースでは、ＭＶＣＣのオーバーヘッドが無視できなくなる。【００１３】
本発明は、１つの側面では、多版同時実行制御の実行コストを下げることを目的とする。
【課題を解決するための手段】
【００１４】
１つの態様では、処理単位サイズ算出プログラムは、行型のデータベースに対して行われた操作に関する情報を所定の処理単位で列型のデータベースに反映させる反映処理を行うデータベース管理システムに関して理単位のサイズを算出する。処理単位サイズ算出プログラムは、まず、二つの情報に基づき、処理単位基準値を算出する処理をコンピュータに実行させる。二つの情報のうち一つは、データベース管理システムにおいて処理単位で行われる多版同時実行制御の処理コストに関する情報である。二つの情報のうち他の一つは、反映処理が前回実行された後に行型のデータベースに対して行われた操作に関する情報を列型のデータベースの形態に変換する処理の処理コストに関する情報である。そして、処理単位サイズ算出プログラムは、処理単位基準値、及び、複数の処理単位に含まれる有効行数の偏りに関する情報に基づき、処理単位のサイズを算出する処理をコンピュータに実行させる。
【発明の効果】
【００１５】
本発明は、１つの側面では、多版同時実行制御の実行コストを下げることができる。
【図面の簡単な説明】
【００１６】
【図１】図１は、ＯＬＴＰクエリによる更新を同期的に反映させるＩＭＣＳを説明する図である。
【図２】図２は、オリジナルテーブルからＩＭＣＳへのデータのコピーを示す図である。
【図３】図３は、ローカルＲＯＳを説明する図である。
【図４】図４は、実施例に係るＲＤＢＭＳの機能構成を示す図である。
【図５Ａ】図５Ａは、エクステントを均すように更新が行われる例を示す図である。
【図５Ｂ】図５Ｂは、データがなくなるまで同一エクステントのデータが更新される例を示す図である。
【図６】図６は、偏りとＥＸの対応付けを示す図である。
【図７】図７は、σmaxを計算するアルゴリズムを示す図である。
【図８】図８は、サイズ決定処理の処理手順を示すフローチャートである。
【図９】図９は、ＲＤＢＭＳを実行するコンピュータのハードウェア構成を示す図である。
【図１０】図１０は、ＯＬＴＰとＯＬＡＰの特徴を示す図である。
【図１１】図１１は、行単位のＭＶＣＣの問題を説明する図である。
【発明を実施するための形態】
【００１７】
以下に、本願の開示する処理単位サイズ算出プログラム、処理単位サイズ算出方法及び処理単位サイズ算出装置の実施例を図面に基づいて詳細に説明する。なお、この実施例は開示の技術を限定するものではない。
【実施例】
【００１８】
まず、ＩＭＣＳ（In-Memory  Column  Store）について説明する。図１は、ＯＬＴＰクエリによる更新を同期的に反映させるＩＭＣＳを説明する図である。図１に示すように、ＩＭＣＳでは、ＤＢバッファ１ａは、列型のデータ構造であるＲＯＳ（Read  Optimized  Storage）１５を有する。ＤＢバッファ１ａは、行型のデータベースであるオリジナルテーブル１１を記憶するメインメモリ上の領域である。また、ＤＢバッファ１ａは、更新性能を維持するために、書き込みバッファとしての行型のデータ構造であるＷＯＳ（Write  Optimized  Storage）１３を有する。【００１９】
データベースへのデータの挿入（INSERT）が指示されると、バックエンド部１２は、オリジナルテーブル１１へのデータの挿入を行う。ここで、バックエンド部１２は、データベースの操作（挿入、更新、削除）に対する処理を行うモジュールである。また、オリジナルテーブル１１へのデータの挿入と同期してＷＯＳ１３への書き込みが行われる。ただし、ＷＯＳ１３には、データは書き込まれることはなく、オリジナルテーブル１１内の行（タプル）の位置を示すＴＩＤ（Tuple-ID）だけが書き込まれる。【００２０】
そして、非同期の処理としてＷＯＳ１３からＲＯＳ１５への変換がエクステントという単位でＷＯＳ変換部１４によって行われる。このとき、ＷＯＳ１３が記憶するＴＩＤに基づいてオリジナルテーブル１１からデータが取り出され、ＲＯＳ１５にエクステント毎に書き込まれ、ＲＯＳ１５に書込まれた行はＷＯＳ１３から削除される。【００２１】
図２は、オリジナルテーブル１１からＩＭＣＳへのデータのコピーを示す図である。図２に示すように、オリジナルテーブル１１では、各行にＴＩＤが付加されている。ＷＯＳ１３は、オリジナルテーブル１１とＲＯＳ１５の差分をＴＩＤを用いて記憶する。また、ＲＯＳ１５は、エクステント毎にデータを記憶する。ＲＯＳ１５は、ＲＯＳ１５での行番号を示すＣＲＩＤ（Columnar  Record  ID）とＴＩＤの対応表も記憶する。【００２２】
検索時には、ＷＯＳ１３は、一時的に列型のデータに変換され、ＲＯＳ１５と合わせて検索される。一時的に変換された列型のデータは、ローカルＲＯＳと呼ばれる。図３は、ローカルＲＯＳを説明する図である。図３において、ＳＱＬプロセッサ１８は、ＳＱＬを処理してデータベースの検索を行うモジュールである。【００２３】
図３に示すように、ＳＱＬプロセッサ１８は、ＳＱＬを受け取ると、ＷＯＳ１３を変換してローカルＲＯＳ１８ａを作成する。そして、ＳＱＬプロセッサ１８は、グローバルＲＯＳ１５ａとローカルＲＯＳ１８ａを合わせて検索を行い、結果を出力する。ここで、グローバルＲＯＳ１５ａは、ＷＯＳ１３から変換済のＲＯＳ１５である。【００２４】
次に、実施例に係るＲＤＢＭＳの機能構成について説明する。図４は、実施例に係るＲＤＢＭＳの機能構成を示す図である。図４に示すように、実施例に係るＲＤＢＭＳ１は、オリジナルテーブル１１と、バックエンド部１２と、ＷＯＳ１３と、第１変換部１４ａと、第２変換部１４ｂと、ＲＯＳ１５と、メタ情報記憶部１６と、削除ベクトル１７と、ＳＱＬプロセッサ１８とを有する。また、ＲＤＢＭＳ１は、システムテーブル１９と、サイズ決定部２０とを有する。【００２５】
オリジナルテーブル１１は、行型のデータベースである。オリジナルテーブル１１には複数のテーブルが含まれる。バックエンド部１２は、オリジナルテーブル１１へのデータの挿入、オリジナルテーブル１１のデータの更新及び削除を行う。また、バックエンド部１２は、オリジナルテーブル１１の操作と同期してＷＯＳ１３を更新する。【００２６】
ＷＯＳ１３は、オリジナルテーブル１１とＲＯＳ１５との差分をＴＩＤを用いて記憶する。ＷＯＳ１３には、データＷＯＳ１３ａと、ホワイトアウトＷＯＳ１３ｂとが含まれる。データＷＯＳ１３ａは、挿入された行のＴＩＤを記憶する。また、データＷＯＳ１３ａは、更新された行に関して、更新後の行として新たに作成された行のＴＩＤを記憶する。ホワイトアウトＷＯＳ１３ｂは、削除された行のＴＩＤを記憶する。また、ホワイトアウトＷＯＳ１３ｂは、更新された行に関して、削除された更新前の行のＴＩＤを記憶する。【００２７】
第１変換部１４ａは、データＷＯＳ１３ａのサイズがエクステントのサイズになると、データＷＯＳ１３ａを変換してＲＯＳ１５とメタ情報記憶部１６を更新する。なお、エクステントのサイズは、可変であり、第１変換部１４ａによる処理が終了後、サイズ決定部２０により決定される。決定されたサイズは、メタ情報記憶部１６に書き込まれ、次に第１変換部１４ａが処理を行うときに利用される。また、第１変換部１４ａは、現存する全トランザクションから可視のデータのみを変換する。ここで、「可視」とは、未コミットでないことを意味する。なお、図１に示したＷＯＳ変換部１４は、第１変換部１４ａに対応する。また、第１変換部１４ａは、作成されたエクステントにトランザクションＩＤを割り振る。【００２８】
第２変換部１４ｂは、ホワイトアウトＷＯＳ１３ｂを変換して削除ベクトル１７とメタ情報記憶部１６を更新する。【００２９】
ＲＯＳ１５は、オリジナルテーブル１１のデータが列型に変換されたデータベースである。ＲＯＳ１５は、エクステントの集合である。列の集計処理等は、ＲＯＳ１５を用いて行われる。【００３０】
メタ情報記憶部１６は、ＩＭＣＳに関するメタ情報を記憶する。メタ情報記憶部１６は、例えば、各エクステントのサイズ、各エクステントのトランザクションＩＤ、サイズ決定部２０により決定されたサイズを記憶する。【００３１】
削除ベクトル１７は、削除されたデータの位置を示すビットベクトルである。１つのエクステントに対応して１つの削除ベクトル１７がある。【００３２】
ＳＱＬプロセッサ１８は、ＳＱＬを処理してデータベースの検索を行う。ＳＱＬプロセッサ１８は、ＳＱＬを受け取ると、ＷＯＳ１３を変換してローカルＲＯＳ１８ａを作成する。また、ＳＱＬプロセッサ１８は、ＭＶＣＣ部１８ｂを有する。【００３３】
ＭＶＣＣ部１８ｂは、ＭＶＣＣを行う。ＭＶＣＣ部１８ｂは、エクステント単位で一括でＭＶＣＣを行う。ＭＶＣＣ部１８ｂは、エクステントに第１変換部１４ａによって割り振られたトランザクションＩＤとＳＱＬプロセッサ１８が有するトランザクションＩＤを比較することでＭＶＣＣ制御を行う。【００３４】
なお、第１変換部１４ａは、現存する全トランザクションから可視のデータのみを変換することで、ＭＶＣＣ処理の一部を完了している。また、ＭＶＣＣ部１８ｂは、削除ベクトル１７を用いてビット演算のみで削除された行を読み飛ばすことで、エクステント内ＭＶＣＣを極小化する。【００３５】
システムテーブル１９は、ＲＤＢＭＳ１に関する情報を記憶する。システムテーブル１９は、例えば、各テーブルの行数を記憶する。【００３６】
サイズ決定部２０は、エクステントサイズを決定する。サイズ決定部２０は、２段階でエクステントサイズを決定する。第１段階では、サイズ決定部２０は、全データ数分の挿入処理のみが行われたと仮定した場合の最良のエクステントサイズを決定する。第２段階では、サイズ決定部２０は、第１段階で決定したエクステントサイズを更新処理が与える影響に基づいて補正する。サイズ決定部２０は、第１段階の処理を行う第１決定部２１と、第２段階の処理を行う第２決定部２２とを有する。第１決定部２１は請求項の第１算出部に対応し、第２決定部２２は請求項の第２算出部に対応する。【００３７】
第１決定部２１は、エクステントサイズが関係するコストに基づいてエクステントサイズを決定する。エクステントサイズが関係するコストには、ＭＶＣＣのコストと、ローカルＲＯＳ１８ａへ変換するコストがある。【００３８】
ＭＶＣＣのコストは、エクステント一つ毎に一回発生し、以下の式（１）で計算される。
【数１】
0006690728.tif 000002
ここで、ＭＶＣＣＣは、１回分のＭＶＣＣコストであり、時間である。ＭＶＣＣＣは、実測に基づく定数である。Ｎは、全データの行数である。ＥＸは、エクステントサイズである。ＭＶＣＣのコストは、エクステントサイズが大きいほど小さい。【００３９】
ローカルＲＯＳ１８ａへ変換するコストは、ＷＯＳ１３の平均サイズがＥＸ／２であることから、以下の式（２）で計算される。
【数２】
0006690728.tif 000003
ここで、ＬＲＯＳは、ローカルＲＯＳ１８ａへの変換の１行あたりのコストであり、時間である。ＬＲＯＳは、実測に基づく定数である。ローカルＲＯＳ１８ａへ変換するコストは、ＥＸが大きいほど大きい。【００４０】
ＭＶＣＣのコストと、ローカルＲＯＳ１８ａへ変換するコストから、ＭＶＣＣのコストＣｏｓｔは、以下の式（３）で計算される。
【数３】
0006690728.tif 000004
【００４１】
また、Ｃｏｓｔの微分Ｃｏｓｔ’は、以下の式（４）となる。
【数４】
0006690728.tif 000005
【００４２】
Ｃｏｓｔは定数値であるからＣｏｓｔ’＝０であり、ＭＶＣＣのコストが最小となるＥＸは、以下の式（５）で計算される。式（５）において、Ｃは定数値である。
【数５】
0006690728.tif 000006
【００４３】
第２決定部２２は、第１決定部２１が決定したエクステントサイズを更新処理が与える影響に基づいて修正する。更新が発生した場合、全データ数が同じであっても、更新による行の削除と追加が発生するため、無効なデータ（空行）により、ＭＶＣＣの必要なデータ量が増える。データ量の増え方は、更新の偏りに依存する。【００４４】
最悪のケースとして、エクステントを均すように更新が行われると、有効データが１つのエクステントが並び、実質データ数はＮ×ＥＸとなる。この場合、式（３）においてＮがＮ×ＥＸとなるため、ＥＸが小さいほどＣｏｓｔは小さくなる。したがって、ＥＸ＝１となる。【００４５】
図５Ａは、エクステントを均すように更新が行われる例を示す図である。図５Ａは、ＥＸ＝３、Ｎ＝９の場合を示す。図５Ａ（ａ）は、初期状態から塗り潰し部分に更新が行われた場合、すなわち、３つのエクステントを均すように更新が行われた場合を示す。【００４６】
塗り潰し部分に更新が行われると、塗り潰し部分は空行となる。図５Ａ（ｂ）では、空行は点線で示される。また、図５Ａ（ｂ）では、３つの更新データで新たな（ｎｅｗ）エクステントが作成される。そして、図５Ａ（ｂ）の塗り潰し部分に更新が行われると、図５Ａ（ｃ）に示すように、塗り潰し部分は空行となり、３つの更新データで新たな（ｎｅｗ）エクステントが作成される。【００４７】
そして、図５Ａ（ｃ）の塗り潰し部分に更新が行われると、図５Ａ（ｄ）に示すように、塗り潰し部分は空行となり、３つの更新データで新たな（ｎｅｗ）エクステントが作成される。同様に、図５Ａ（ｄ）の塗り潰し部分に更新が行われると、図５Ａ（ｅ）に示すように、塗り潰し部分は空行となり、３つの更新データで新たな（ｎｅｗ）エクステントが作成される。【００４８】
そして、図５Ａ（ｅ）の塗り潰し部分に更新が行われると、図５Ａ（ｆ）に示すように、左端のエクステントは、有効な行がなくなるため、削除（ｄｅｌｅｔｅ）される。このため、エクステントの数は増えない。すなわち、エクステント数は（Ｎ−ＥＸ）＋１＝７まで増える。【００４９】
一方、最良のケースとして、データがなくなるまで同一エクステントのデータが更新されると、実質データ数はＮのままであり、最良のエクステントサイズは式（５）に示す値となる。【００５０】
図５Ｂは、データがなくなるまで同一エクステントのデータが更新される例を示す図である。図５Ｂに示すように、塗り潰し部分に更新が行われた場合、新たなエクステントが生成されるとともに、全てのデータが更新されたエクステントが削除されるため、エクステントの数は増えない。【００５１】
第２決定部２２は、ＥＸ＝１の場合（最悪のケース）を偏りが０の場合に対応付け、ＥＸが最大の場合（最良のケース）を偏りの最大値に対応付ける。図６は、偏りとＥＸの対応付けを示す図である。図６において、ＥＸMaxはＥＸの最大値を示し、式（５）に示す更新がない場合の値である。第２決定部２２は、実際の偏りと偏りの最大値を計算し、ＥＸMaxに（実際の偏り）／（偏りの最大値）を乗じることによってＥＸを決定する。【００５２】
例えば、第２決定部２２は、削除ベクトル１７を用いて各エクステントの削除行数を計算し、エクステントの行数と削除行数から各エクステントの有効行数を計算する。そして、第２決定部２２は、有効行数の偏りσと、有効行数の偏りの最大値σmaxを計算し、ＥＸを算出する。【００５３】
有効行数の偏りσは、以下の式（６）で計算される。
【数６】
0006690728.tif 000007
ここで、ＥＸ[ｍ]（１≦ｍ≦Ｍ）は、各エクステントのサイズであり、Ｍはエクステントの数であり、ＤＥＬ[ｍ]は、各エクステントの削除行数であり、ＥＸ[Ｍ]−ＤＥＬ[ｍ]は、各エクステントの有効行数であり、ＲＥＳＴAVは、有効行数の平均値である。【００５４】
また、σmaxは、小さなエクステントから順に削除行を詰めた場合の有効行数の偏りとして計算される。図７は、σmaxを計算するアルゴリズムを示す図である。図７に示すように、第２決定部２２は、配列ｓｉｚｅ[]にエクステントのサイズを小さい順に入れる（１）。【００５５】
そして、サイズ決定部２０は、ｄｅｌ＿ｎｕｍにｒｅｓｔ＿ｄｅｌを超えないようにｓｉｚｅ[ｉ]から削除した行数を記憶し（２）、ｓｉｚｅ[ｉ]から削除した行数ｄｅｌ＿ｎｕｍをｉ＝１から順番に削除行の総数ｒｅｓｔ＿ｄｅｌから引いていく（３）。また、第２決定部２２は、有効行数の偏りをｉ＝１から順番にｓｕｍに集計していく（４）。そして、Ｍ個全てのエクステントについて偏りの集計が完了すると、第２決定部２２は、ｓｕｍ／Ｍをσmaxとする（５）。【００５６】
次に、サイズ決定処理の処理手順について説明する。図８は、サイズ決定処理の処理手順を示すフローチャートである。図８に示すように、サイズ決定部２０は、システムテーブル１９から現在のテーブルの行数を取得し（ステップＳ１）、更新がない場合の最良のエクステントサイズＥＸmaxを求める（ステップＳ２）。【００５７】
そして、サイズ決定部２０は、削除ベクトル１７を走査し、エクステント毎の削除行数を確認してＤＥＬ[ｍ]とする（ステップＳ３）。そして、サイズ決定部２０は、メタ情報記憶部１６の情報から各エクステントのサイズを確認してＥＸ[ｍ]とする（ステップＳ４）。なお、ステップＳ３とステップＳ４の処理の順番は逆でもよい。【００５８】
そして、サイズ決定部２０は、有効行数の偏りσを求め（ステップＳ５）、有効行数の偏りの最大値σmaxを求める（ステップＳ６）。なお、ステップＳ５とステップＳ６の処理の順番は逆でもよい。【００５９】
そして、サイズ決定部２０は、関数ｆにより適切なエクステントサイズｆ(σ)を計算する（ステップＳ７）。ここで関数ｆは、０≦ｘ≦σmaxにおいて、１≦ｆ(ｘ)≦ＥＸmax、かつ、ｘ1≦ｘ2ならばｆ(ｘ1)≦ｆ(ｘ2)を満たす関数である。例えば、関数ｆは、以下の式（７）で定義される。なお、EXminはユーザ定義の定数値であり、エクステントサイズの適当な下限値である。
【数７】
0006690728.tif 000008
【００６０】
このように、サイズ決定部２０は、有効行数の偏りσ、有効行数の偏りの最大値σmax、関数ｆを用いてエクステントのサイズを決定することができる。【００６１】
次に、ＲＤＢＭＳ１を実行するコンピュータについて説明する。図９は、ＲＤＢＭＳ１を実行するコンピュータのハードウェア構成を示す図である。図９に示すように、コンピュータ５０は、メインメモリ５１と、ＣＰＵ５２と、ＬＡＮ（Local  Area  Network）インタフェース５３と、ＨＤＤ（Hard  Disk  Drive）５４とを有する。また、コンピュータ５０は、スーパーＩＯ（Input  Output）５５と、ＤＶＩ（Digital  Visual  Interface）５６と、ＯＤＤ（Optical  Disk  Drive）５７とを有する。【００６２】
メインメモリ５１は、プログラムやプログラムの実行途中結果などを記憶するメモリである。ＣＰＵ５２は、メインメモリ５１からプログラムを読出して実行する中央処理装置である。ＣＰＵ５２は、メモリコントローラを有するチップセットを含む。【００６３】
ＬＡＮインタフェース５３は、コンピュータ５０をＬＡＮ経由で他のコンピュータに接続するためのインタフェースである。ＨＤＤ５４は、プログラムやデータを格納するディスク装置であり、スーパーＩＯ５５は、マウスやキーボードなどの入力装置を接続するためのインタフェースである。ＤＶＩ５６は、液晶表示装置を接続するインタフェースであり、ＯＤＤ５７は、ＤＶＤの読み書きを行う装置である。【００６４】
ＬＡＮインタフェース５３は、ＰＣＩエクスプレス（ＰＣＩｅ）によりＣＰＵ５２に接続され、ＨＤＤ５４及びＯＤＤ５７は、ＳＡＴＡ（Serial  Advanced  Technology  Attachment）によりＣＰＵ５２に接続される。スーパーＩＯ５５は、ＬＰＣ（Low  Pin  Count）によりＣＰＵ５２に接続される。【００６５】
そして、コンピュータ５０において実行されるＲＤＢＭＳ１は、ＤＶＤに記憶され、ＯＤＤ５７によってＤＶＤから読出されてコンピュータ５０にインストールされる。あるいは、ＲＤＢＭＳ１は、ＬＡＮインタフェース５３を介して接続された他のコンピュータシステムのデータベースなどに記憶され、これらのデータベースから読出されてコンピュータ５０にインストールされる。そして、インストールされたＲＤＢＭＳ１は、ＨＤＤ５４に記憶され、メインメモリ５１に読出されてＣＰＵ５２によって実行される。【００６６】
上述してきたように、実施例では、第１決定部２１が、全データ行数（Ｎ）、１回分のＭＶＣＣコスト（ＭＶＣＣＣ）、ローカルＲＯＳ１８ａへの変換の１回分のコストＬＲＯＳを用いて更新がない場合の最良エクステントサイズＥＸMaxを算出する。そして、第２決定部２２が、ＥＸMaxと有効行数の偏りに関する情報とを用いてエクステントのサイズを算出する。したがって、ＲＤＢＭＳ１は、ＭＶＣＣコストを下げることができる。【００６７】
また、実施例では、第２決定部２２は、ＥＸMax、有効行数の偏りσ、有効行数の偏りの最大値σmax、関数ｆを用いてエクステントのサイズを算出する。したがって、第２決定部２２は、更新の偏りをエクステントサイズの算出に反映することができる。【００６８】
また、実施例では、第２変換部１４ｂが、ホワイトアウトＷＯＳ１３ｂを変換して削除ベクトル１７を作成し、第２決定部２２は、削除ベクトル１７を用いて各エクステントの有効行数を算出する。したがって、第２決定部２２は、各エクステントの有効行数を算出する処理を効率よく行うことができる。【００６９】
また、実施例では、第１変換部１４ａは、現存する全トランザクションから可視のデータのみを変換してＲＯＳ１５を更新する。したがって、ＭＶＣＣ部１８ｂは、ＭＶＣＣを効率よく行うことができる。【００７０】
なお、実施例では、ＷＯＳ１３がデータＷＯＳ１３ａとホワイトアウトＷＯＳ１３ｂを有する場合について説明したが、ＷＯＳ１３は他の形態でオリジナルテーブル１１への操作に関する情報を有してよい。
【符号の説明】
【００７１】
１    ＲＤＢＭＳ
１ａ    ＤＢバッファ
１１    オリジナルテーブル
１２    バックエンド部
１３    ＷＯＳ
１３ａ    データＷＯＳ
１３ｂ    ホワイトアウトＷＯＳ
１４    ＷＯＳ変換部
１４ａ    第１変換部
１４ｂ    第２変換部
１５    ＲＯＳ
１５ａ    グローバルＲＯＳ
１６    メタ情報記憶部
１７    削除ベクトル
１８    ＳＱＬプロセッサ
１８ａ    ローカルＲＯＳ
１８ｂ    ＭＶＣＣ部
１９    システムテーブル
２０    サイズ決定部
２１    第１決定部
２２    第２決定部
５０    コンピュータ
５１    メインメモリ
５２    ＣＰＵ
５３    ＬＡＮインタフェース
５４    ＨＤＤ
５５    スーパーＩＯ
５６    ＤＶＩ
５７    ＯＤＤ
【図１】
0006690728.tif 000009
【図２】
0006690728.tif 000010
【図３】
0006690728.tif 000011
【図４】
0006690728.tif 000012
【図５Ａ】
0006690728.tif 000013
【図５Ｂ】
0006690728.tif 000014
【図６】
0006690728.tif 000015
【図７】
0006690728.tif 000016
【図８】
0006690728.tif 000017
【図９】
0006690728.tif 000018
【図１０】
0006690728.tif 000019
【図１１】
0006690728.tif 000020