JPH10111819A - リレーショナルデータベースのインデックス自動付加システム - Google Patents
リレーショナルデータベースのインデックス自動付加システムInfo
- Publication number
- JPH10111819A JPH10111819A JP8264742A JP26474296A JPH10111819A JP H10111819 A JPH10111819 A JP H10111819A JP 8264742 A JP8264742 A JP 8264742A JP 26474296 A JP26474296 A JP 26474296A JP H10111819 A JPH10111819 A JP H10111819A
- Authority
- JP
- Japan
- Prior art keywords
- processing
- index
- sql
- time
- search
- 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.)
- Pending
Links
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
(57)【要約】
【課題】 リレーショナルデータベース(RDB)のイ
ンデックス自動付加システムに関し、管理者の技量やシ
ステムの運用形態などに関わらず、RDB運用効率を総
合的に向上可能とする。 【解決手段】 実際の業務運用を行う場合と同等の試行
条件下で業務プログラムを実行させ、発行された全SQ
Lコマンドについてその実行時間などの稼動情報をジャ
ーナルに取得する。業務プログラム終了後、蓄積された
稼動情報に基づいて、処理内容が一致する同種のSQL
コマンドごとに上記実行時間を集計した総実行時間を求
める。そして、総実行時間の値が上位半数に含まれるS
QLコマンドの処理対象となるカラムに新たなインデッ
クスを付加した後、再度業務プログラムを実行させ、上
述した処理を繰り返す。これを各SQLコマンドの総実
行時間の累計値が最小となるまで繰り返し、検索と更新
のバランスがとれた最適なインデックスを自動生成・付
加する。
ンデックス自動付加システムに関し、管理者の技量やシ
ステムの運用形態などに関わらず、RDB運用効率を総
合的に向上可能とする。 【解決手段】 実際の業務運用を行う場合と同等の試行
条件下で業務プログラムを実行させ、発行された全SQ
Lコマンドについてその実行時間などの稼動情報をジャ
ーナルに取得する。業務プログラム終了後、蓄積された
稼動情報に基づいて、処理内容が一致する同種のSQL
コマンドごとに上記実行時間を集計した総実行時間を求
める。そして、総実行時間の値が上位半数に含まれるS
QLコマンドの処理対象となるカラムに新たなインデッ
クスを付加した後、再度業務プログラムを実行させ、上
述した処理を繰り返す。これを各SQLコマンドの総実
行時間の累計値が最小となるまで繰り返し、検索と更新
のバランスがとれた最適なインデックスを自動生成・付
加する。
Description
【0001】
【発明の属する技術分野】本発明はリレーショナルデー
タベースのインデックス自動付加システムに係り、特
に、リレーショナルデータベースの運用効率を向上させ
るインデックスを自動的に生成・付加するリレーショナ
ルデータベースのインデックス自動付加システムに関す
る。
タベースのインデックス自動付加システムに係り、特
に、リレーショナルデータベースの運用効率を向上させ
るインデックスを自動的に生成・付加するリレーショナ
ルデータベースのインデックス自動付加システムに関す
る。
【0002】
【従来の技術】従来、リレーショナルデータベース(R
DB)の検索効率を向上させるためのインデックスの作
成・付加は、RDBに関する知識を持つシステム管理者
が、ティムマーティン及びティムハートレー著「DB2
/SQL ア・プロフェッショナル・プログラマーズ・
ガイド」(1989年)の208〜216ページ(TimM
artyn,Tim Hartley DB2/SQL A Professional Programme
r's Guide(1989)P208-216)に記載されているような専
用のインデックス作成コマンドを使用して行っていた。
DB)の検索効率を向上させるためのインデックスの作
成・付加は、RDBに関する知識を持つシステム管理者
が、ティムマーティン及びティムハートレー著「DB2
/SQL ア・プロフェッショナル・プログラマーズ・
ガイド」(1989年)の208〜216ページ(TimM
artyn,Tim Hartley DB2/SQL A Professional Programme
r's Guide(1989)P208-216)に記載されているような専
用のインデックス作成コマンドを使用して行っていた。
【0003】
【発明が解決しようとする課題】上記従来技術におい
て、システム管理者は、これまで蓄積されてきた経験則
や管理対象のシステムの運用形態などを勘案しながらR
DBの検索効率を予測し、最適と考えられるインデック
スの作成・付加を行っていくのが一般的である。このた
め、管理対象のシステムが経験則を活用しにくい特殊な
ものであった場合や、システム管理者の個人的技量が不
十分であった場合、実際の検索効率が当初予想した検索
効率を達成しているとは限らないという問題点があっ
た。また、システムの運用が進むにしたがって、RDB
の内容やその検索を行う業務プログラムの使用頻度など
に少しずつ変化が生じ、RDBの検索効率が低下してし
まうことがあるという問題点があった。さらに、インデ
ックス付加によって検索効率を向上させると、インデッ
クス維持のためのオーバヘッドによって更新効率が低下
してしまう結果を招く(トレードオフ)ため、検索効率
および更新効率のバランスがとれた最適なインデックス
を作成・付加してRDBの運用効率を総合的に向上させ
ることは困難であるという問題点があった。
て、システム管理者は、これまで蓄積されてきた経験則
や管理対象のシステムの運用形態などを勘案しながらR
DBの検索効率を予測し、最適と考えられるインデック
スの作成・付加を行っていくのが一般的である。このた
め、管理対象のシステムが経験則を活用しにくい特殊な
ものであった場合や、システム管理者の個人的技量が不
十分であった場合、実際の検索効率が当初予想した検索
効率を達成しているとは限らないという問題点があっ
た。また、システムの運用が進むにしたがって、RDB
の内容やその検索を行う業務プログラムの使用頻度など
に少しずつ変化が生じ、RDBの検索効率が低下してし
まうことがあるという問題点があった。さらに、インデ
ックス付加によって検索効率を向上させると、インデッ
クス維持のためのオーバヘッドによって更新効率が低下
してしまう結果を招く(トレードオフ)ため、検索効率
および更新効率のバランスがとれた最適なインデックス
を作成・付加してRDBの運用効率を総合的に向上させ
ることは困難であるという問題点があった。
【0004】したがって本発明の目的は、上記の問題点
を解決して、システム管理者の技量やシステムの運用形
態などに関わらず、RDBの運用効率を総合的に向上さ
せることが可能なリレーショナルデータベースのインデ
ックス自動付加システムを提供することにある。
を解決して、システム管理者の技量やシステムの運用形
態などに関わらず、RDBの運用効率を総合的に向上さ
せることが可能なリレーショナルデータベースのインデ
ックス自動付加システムを提供することにある。
【0005】
【課題を解決するための手段】上記の目的を達成するた
め、本発明のリレーショナルデータベースのインデック
ス自動付加システムは、リレーショナルデータベースに
対し、その処理効率を最適化させるインデックスの生成
・付加を行うリレーショナルデータベースのインデック
ス自動付加システムにおいて、業務プログラムが発行す
るリレーショナルデータベース処理操作用のSQLコマ
ンドを解析し、前記リレーショナルデータベースを対象
とする検索処理および更新処理の実行制御を行うSQL
解析・実行処理部と、発行されたすべての前記SQLコ
マンドについて、前記検索処理の実行に要した検索時間
および前記更新処理の実行に要した更新時間の記録処理
を行うデータベース処理情報記録部と、処理内容が一致
する同種のSQLコマンドの各々について、前記データ
ベース処理情報記録部に記録されている前記検索時間お
よび前記更新時間を集計した総実行時間を求め、前記総
実行時間をキーに前記同種のSQLコマンドの順序付け
を行う集計・ソート部と、前記集計・ソート部の順序付
けにしたがって前記総実行時間が上位半数に含まれるS
QLコマンドを選択し、そのSQLコマンドに該当する
前記検索処理に要する前記検索時間を短縮させるインデ
ックスの生成・付加を行うインデックス制御部と、を具
備し、所定の試行条件下での前記SQL解析・実行処理
部による前記実行制御および前記データベース処理情報
記録部による前記記録処理と、前記集計・ソート部およ
び前記インデックス制御部の処理とを、前記同種のSQ
Lコマンドごとに求められた前記総実行時間すべての累
計値が最小となるまで繰り返すものである。
め、本発明のリレーショナルデータベースのインデック
ス自動付加システムは、リレーショナルデータベースに
対し、その処理効率を最適化させるインデックスの生成
・付加を行うリレーショナルデータベースのインデック
ス自動付加システムにおいて、業務プログラムが発行す
るリレーショナルデータベース処理操作用のSQLコマ
ンドを解析し、前記リレーショナルデータベースを対象
とする検索処理および更新処理の実行制御を行うSQL
解析・実行処理部と、発行されたすべての前記SQLコ
マンドについて、前記検索処理の実行に要した検索時間
および前記更新処理の実行に要した更新時間の記録処理
を行うデータベース処理情報記録部と、処理内容が一致
する同種のSQLコマンドの各々について、前記データ
ベース処理情報記録部に記録されている前記検索時間お
よび前記更新時間を集計した総実行時間を求め、前記総
実行時間をキーに前記同種のSQLコマンドの順序付け
を行う集計・ソート部と、前記集計・ソート部の順序付
けにしたがって前記総実行時間が上位半数に含まれるS
QLコマンドを選択し、そのSQLコマンドに該当する
前記検索処理に要する前記検索時間を短縮させるインデ
ックスの生成・付加を行うインデックス制御部と、を具
備し、所定の試行条件下での前記SQL解析・実行処理
部による前記実行制御および前記データベース処理情報
記録部による前記記録処理と、前記集計・ソート部およ
び前記インデックス制御部の処理とを、前記同種のSQ
Lコマンドごとに求められた前記総実行時間すべての累
計値が最小となるまで繰り返すものである。
【0006】これにより、システム管理者の個人的技量
やシステムの運用形態などに関わらず、指定した試行条
件下における検索効率および更新効率のバランスがとれ
た最適なインデックスを自動的に作成・付加して、RD
Bの運用効率を総合的に向上させることができる。
やシステムの運用形態などに関わらず、指定した試行条
件下における検索効率および更新効率のバランスがとれ
た最適なインデックスを自動的に作成・付加して、RD
Bの運用効率を総合的に向上させることができる。
【0007】
【発明の実施の形態】以下、本発明のリレーショナルデ
ータベースのインデックス自動付加システムの実施の形
態を図面を用いて詳細に説明する。
ータベースのインデックス自動付加システムの実施の形
態を図面を用いて詳細に説明する。
【0008】図1は、本発明のリレーショナルデータベ
ースのインデックス自動付加システムの一実施形態を適
用したシステム構成例を示すブロック図である。同図
中、11は業務プログラム、12は業務プログラム11
により発行されるSQL( Structured Query Language)
コマンド、21はSQLコマンド12に応じた制御を実
現するデータベース管理システム(DBMS)、22は
SQLコマンド12の内容を解析して対応する検索処理
や更新処理の実行制御を行うSQL解析・実行処理部、
23はSQL解析・実行処理部22における処理に関す
る稼動情報25を求める稼動情報取得処理部、24は稼
動情報取得処理部23で求めた稼動情報25を蓄積記録
しておくジャーナル、26は稼動情報25の集計処理お
よびソート処理を行う集計・ソート部、27は集計・ソ
ート部26の処理結果に応じてインデックスの生成・付
加制御を行うインデックス制御部、31は業務プログラ
ム11の処理対象となるリレーショナルデータベース
(RDB)、32は検索処理の初期段階で参照されるイ
ンデックス、33は検索処理や更新処理で最終的な目的
とされるデータである。ここで、稼動情報取得処理部2
3およびジャーナル24が請求項中の“データベース処
理情報記録部”に相当する。
ースのインデックス自動付加システムの一実施形態を適
用したシステム構成例を示すブロック図である。同図
中、11は業務プログラム、12は業務プログラム11
により発行されるSQL( Structured Query Language)
コマンド、21はSQLコマンド12に応じた制御を実
現するデータベース管理システム(DBMS)、22は
SQLコマンド12の内容を解析して対応する検索処理
や更新処理の実行制御を行うSQL解析・実行処理部、
23はSQL解析・実行処理部22における処理に関す
る稼動情報25を求める稼動情報取得処理部、24は稼
動情報取得処理部23で求めた稼動情報25を蓄積記録
しておくジャーナル、26は稼動情報25の集計処理お
よびソート処理を行う集計・ソート部、27は集計・ソ
ート部26の処理結果に応じてインデックスの生成・付
加制御を行うインデックス制御部、31は業務プログラ
ム11の処理対象となるリレーショナルデータベース
(RDB)、32は検索処理の初期段階で参照されるイ
ンデックス、33は検索処理や更新処理で最終的な目的
とされるデータである。ここで、稼動情報取得処理部2
3およびジャーナル24が請求項中の“データベース処
理情報記録部”に相当する。
【0009】図1において、最初にシステム管理者は、
インデックス32を全く付加せずにRDB31を作成し
た後、実際に業務運用を行う場合と同等の試行条件下で
業務プログラム11を実行させる。業務プログラム11
がSQLコマンド12を発行すると、DBMS21内の
SQL解析・実行処理部22は、そのSQLコマンド1
2を解析して、RDB31を対象とする検索処理や更新
処理を実行する。このとき、稼動情報取得処理部23
は、SQLコマンド12の内容と対応する検索処理の実
行に要した検索時間あるいは更新処理の実行に要した更
新時間を稼動情報25として取得し、ジャーナル24に
蓄積記録する。したがって、RDB31を対象とする検
索処理や更新処理に関わるSQLコマンド12の発行を
伴うすべての業務プログラム11を実行させることによ
り、RDB31に関わるすべてのSQLコマンド12の
稼動情報25がジャーナル24に記録される。集計・ソ
ート部26は、ジャーナル24に記録されたRDB31
に関わるすべてのSQLコマンド12の稼動情報25に
ついて、その処理内容が一致する同種のSQLコマンド
ごとに検索時間と更新時間を集計した後、その時間の降
順にSQLコマンドをソートする。インデックス制御部
27は、ソートされたSQLコマンドのうち、上位半数
に含まれるSQLコマンドについてインデックス32の
生成・付加制御を行う。
インデックス32を全く付加せずにRDB31を作成し
た後、実際に業務運用を行う場合と同等の試行条件下で
業務プログラム11を実行させる。業務プログラム11
がSQLコマンド12を発行すると、DBMS21内の
SQL解析・実行処理部22は、そのSQLコマンド1
2を解析して、RDB31を対象とする検索処理や更新
処理を実行する。このとき、稼動情報取得処理部23
は、SQLコマンド12の内容と対応する検索処理の実
行に要した検索時間あるいは更新処理の実行に要した更
新時間を稼動情報25として取得し、ジャーナル24に
蓄積記録する。したがって、RDB31を対象とする検
索処理や更新処理に関わるSQLコマンド12の発行を
伴うすべての業務プログラム11を実行させることによ
り、RDB31に関わるすべてのSQLコマンド12の
稼動情報25がジャーナル24に記録される。集計・ソ
ート部26は、ジャーナル24に記録されたRDB31
に関わるすべてのSQLコマンド12の稼動情報25に
ついて、その処理内容が一致する同種のSQLコマンド
ごとに検索時間と更新時間を集計した後、その時間の降
順にSQLコマンドをソートする。インデックス制御部
27は、ソートされたSQLコマンドのうち、上位半数
に含まれるSQLコマンドについてインデックス32の
生成・付加制御を行う。
【0010】以上によってRDB31に新たなインデッ
クス32が付加されると、再び業務プログラム11を実
行させ、稼動情報取得処理部23により新たなインデッ
クス32が反映された新たな稼動情報25をジャーナル
24に記録させる。そして、集計・ソート部26は、こ
の新たな稼動情報25に基づいて上記と同様の集計・ソ
ートを行い、インデックス制御部27は、ソートされた
SQLコマンドの上位半数についてインデックス32の
生成・付加制御を行う。このとき、すべてのSQLコマ
ンドに対応する処理に要する実行時間の累計値を求め、
インデックス制御部27により新たなインデックス32
を付加しても上記実行時間の累計値が短縮されなくなる
まで、上述した一連の処理を繰り返し実行する。
クス32が付加されると、再び業務プログラム11を実
行させ、稼動情報取得処理部23により新たなインデッ
クス32が反映された新たな稼動情報25をジャーナル
24に記録させる。そして、集計・ソート部26は、こ
の新たな稼動情報25に基づいて上記と同様の集計・ソ
ートを行い、インデックス制御部27は、ソートされた
SQLコマンドの上位半数についてインデックス32の
生成・付加制御を行う。このとき、すべてのSQLコマ
ンドに対応する処理に要する実行時間の累計値を求め、
インデックス制御部27により新たなインデックス32
を付加しても上記実行時間の累計値が短縮されなくなる
まで、上述した一連の処理を繰り返し実行する。
【0011】図2は、図1のシステムによるインデック
ス自動付加の全体的な手順の一例を示すフローチャート
である。同図中、最初にシステム管理者がインデックス
を付加しないデータベース(RDB)を新規に作成する
(ステップ201)。そして、業務プログラムを実行す
るが、最初に実行される業務プログラムはインデックス
を使用せずにSQLコマンドを発行し、RDBの検索処
理および更新処理を行う(ステップ202)。業務プロ
グラムがSQLコマンドを発行したとき、DBMSはそ
のSQLコマンドの内容と該当する処理に要した実行時
間とを稼動情報としてジャーナルに取得する(ステップ
203)。ひとつの業務プログラムが終了すると、イン
デックス自動付加の対象とする該当RDBの検索・更新
を伴う業務プログラムがすべて実行済みか否か判定し
(ステップ204)、まだ実行していない業務プログラ
ムがあればステップ202に戻り、すべての業務プログ
ラムが実行済みであればステップ205へ進む。すなわ
ち、ステップ202〜204を繰り返すことにより、該
当RDBに対する検索処理および更新処理を実行するあ
らゆるSQLコマンドの稼動情報がジャーナルに取得さ
れる。
ス自動付加の全体的な手順の一例を示すフローチャート
である。同図中、最初にシステム管理者がインデックス
を付加しないデータベース(RDB)を新規に作成する
(ステップ201)。そして、業務プログラムを実行す
るが、最初に実行される業務プログラムはインデックス
を使用せずにSQLコマンドを発行し、RDBの検索処
理および更新処理を行う(ステップ202)。業務プロ
グラムがSQLコマンドを発行したとき、DBMSはそ
のSQLコマンドの内容と該当する処理に要した実行時
間とを稼動情報としてジャーナルに取得する(ステップ
203)。ひとつの業務プログラムが終了すると、イン
デックス自動付加の対象とする該当RDBの検索・更新
を伴う業務プログラムがすべて実行済みか否か判定し
(ステップ204)、まだ実行していない業務プログラ
ムがあればステップ202に戻り、すべての業務プログ
ラムが実行済みであればステップ205へ進む。すなわ
ち、ステップ202〜204を繰り返すことにより、該
当RDBに対する検索処理および更新処理を実行するあ
らゆるSQLコマンドの稼動情報がジャーナルに取得さ
れる。
【0012】この後、ジャーナルに取得した稼動情報中
の実行時間を処理内容が一致する同種のSQLコマンド
ごとに集計して、同種のSQLコマンド別の総実行時間
を求める(ステップ205)。そして、インデックスの
生成・付加が1回目であればステップ207をスキップ
し(ステップ206=YES)、ステップ205で得た
総実行時間をキーとしてSQLコマンドをソートするこ
とにより、総実行時間が長いものほど上位となるように
同種のSQLコマンドを順序付ける(ステップ20
8)。
の実行時間を処理内容が一致する同種のSQLコマンド
ごとに集計して、同種のSQLコマンド別の総実行時間
を求める(ステップ205)。そして、インデックスの
生成・付加が1回目であればステップ207をスキップ
し(ステップ206=YES)、ステップ205で得た
総実行時間をキーとしてSQLコマンドをソートするこ
とにより、総実行時間が長いものほど上位となるように
同種のSQLコマンドを順序付ける(ステップ20
8)。
【0013】続くステップ209〜213において、総
実行時間の長い上位のSQLコマンドから総実行時間の
短い下位のSQLコマンドへと、1つづつ順番にカレン
トのSQLコマンドを交替させながら、以下の処理を行
う。すなわち、まずカレントのSQLコマンドで使用し
たカラムにインデックスがすでに存在しているか否かを
判定する(ステップ209)。この結果、該当カラムに
インデックスが存在しなければ(ステップ209=N
O)、カレントのSQLコマンドに対応するインデック
スを単一カラムインデックスとして生成・付加する(ス
テップ210)。また、該当カラムにインデックスがす
でに存在していれば(ステップ209=YES)、その
インデックスを削除してから(ステップ211)、削除
したインデックスとカレントのSQLコマンドに対応す
るインデックスとをマージして得られる複合カラムイン
デックスを生成・付加する(ステップ212)。ステッ
プ211および212により、同種インデックスの2重
追加が防止されるとともに、同一カラムに対する異なる
条件のインデックスの蓄積が可能となる。最後に、カレ
ントのSQLコマンドを次に総実行時間の短い下位のS
QLコマンドに交替させてから、新たなカレントのSQ
Lコマンドの総実行時間が上位半数に含まれていれば
(ステップ213=YES)、ステップ209へ戻る。
すなわち、ステップ209〜213の繰り返しにより、
業務プログラム中で発行されるすべてのSQLコマンド
のうち、その総実行時間の長さが上位半数に含まれるS
QLコマンドに対するインデックスの生成・付加が行わ
れる。
実行時間の長い上位のSQLコマンドから総実行時間の
短い下位のSQLコマンドへと、1つづつ順番にカレン
トのSQLコマンドを交替させながら、以下の処理を行
う。すなわち、まずカレントのSQLコマンドで使用し
たカラムにインデックスがすでに存在しているか否かを
判定する(ステップ209)。この結果、該当カラムに
インデックスが存在しなければ(ステップ209=N
O)、カレントのSQLコマンドに対応するインデック
スを単一カラムインデックスとして生成・付加する(ス
テップ210)。また、該当カラムにインデックスがす
でに存在していれば(ステップ209=YES)、その
インデックスを削除してから(ステップ211)、削除
したインデックスとカレントのSQLコマンドに対応す
るインデックスとをマージして得られる複合カラムイン
デックスを生成・付加する(ステップ212)。ステッ
プ211および212により、同種インデックスの2重
追加が防止されるとともに、同一カラムに対する異なる
条件のインデックスの蓄積が可能となる。最後に、カレ
ントのSQLコマンドを次に総実行時間の短い下位のS
QLコマンドに交替させてから、新たなカレントのSQ
Lコマンドの総実行時間が上位半数に含まれていれば
(ステップ213=YES)、ステップ209へ戻る。
すなわち、ステップ209〜213の繰り返しにより、
業務プログラム中で発行されるすべてのSQLコマンド
のうち、その総実行時間の長さが上位半数に含まれるS
QLコマンドに対するインデックスの生成・付加が行わ
れる。
【0014】総実行時間の長さが上位半数に含まれるS
QLコマンドに対するインデックスの生成・付加が完了
すると(ステップ213=NO)、ステップ202に戻
って業務プログラムを実行するが、これ以後、業務プロ
グラムは新たに付加されたインデックスを使用してSQ
Lコマンドを発行し、RDBの検索処理および更新処理
を行う(ステップ202)。そして、再びステップ20
2〜204を繰り返して、インデックスを使用した場合
のすべての業務プログラムの稼動情報がジャーナルに取
得された後、この稼動情報に基づいて同種のSQLコマ
ンド別の総実行時間を求める(ステップ205)。イン
デックスの生成・付加は2回目以降なので(ステップ2
06=NO)、新たなインデックスを使用して取得した
稼動情報に基づく今回の総実行時間の累計値と前回の総
実行時間の累計値との比較を行う(ステップ207)。
比較の結果、前回の総実行時間の累計値より今回の総実
行時間の累計値の方が小さくなっていれば(ステップ2
07=NO)、新たなインデックスの生成・付加を行っ
たことでRDBに対する処理性能が向上したものとみな
してステップ208へ進み、総実行時間の長さが上位半
数に含まれるSQLコマンドに対するさらに新たなイン
デックスの生成・付加を行う(ステップ208〜21
3)。
QLコマンドに対するインデックスの生成・付加が完了
すると(ステップ213=NO)、ステップ202に戻
って業務プログラムを実行するが、これ以後、業務プロ
グラムは新たに付加されたインデックスを使用してSQ
Lコマンドを発行し、RDBの検索処理および更新処理
を行う(ステップ202)。そして、再びステップ20
2〜204を繰り返して、インデックスを使用した場合
のすべての業務プログラムの稼動情報がジャーナルに取
得された後、この稼動情報に基づいて同種のSQLコマ
ンド別の総実行時間を求める(ステップ205)。イン
デックスの生成・付加は2回目以降なので(ステップ2
06=NO)、新たなインデックスを使用して取得した
稼動情報に基づく今回の総実行時間の累計値と前回の総
実行時間の累計値との比較を行う(ステップ207)。
比較の結果、前回の総実行時間の累計値より今回の総実
行時間の累計値の方が小さくなっていれば(ステップ2
07=NO)、新たなインデックスの生成・付加を行っ
たことでRDBに対する処理性能が向上したものとみな
してステップ208へ進み、総実行時間の長さが上位半
数に含まれるSQLコマンドに対するさらに新たなイン
デックスの生成・付加を行う(ステップ208〜21
3)。
【0015】このようなステップ202〜213の処理
を何度か繰り返し、やがて前回の総実行時間の累計値よ
り今回の総実行時間の累計値の方が大きくなってしまっ
た場合(ステップ207=YES)、新たなインデック
スの生成・付加を行ったことでトレードオフによる処理
性能の低下が発生したものとみなし、ステップ221へ
進む。ステップ221において、新たなインデックスの
ために総実行時間が前回より増加してしまったSQLコ
マンドがあるか否かを判定し、総実行時間が増加したS
QLコマンドがあれば(ステップ221=YES)、該
当するSQLコマンドに対応して付加されているインデ
ックスを前回の状態に戻す(ステップ222)。
を何度か繰り返し、やがて前回の総実行時間の累計値よ
り今回の総実行時間の累計値の方が大きくなってしまっ
た場合(ステップ207=YES)、新たなインデック
スの生成・付加を行ったことでトレードオフによる処理
性能の低下が発生したものとみなし、ステップ221へ
進む。ステップ221において、新たなインデックスの
ために総実行時間が前回より増加してしまったSQLコ
マンドがあるか否かを判定し、総実行時間が増加したS
QLコマンドがあれば(ステップ221=YES)、該
当するSQLコマンドに対応して付加されているインデ
ックスを前回の状態に戻す(ステップ222)。
【0016】図3は、図2のインデックス自動付加の処
理前後における各種性能値の一具体例を示す図である。
同図中、あるRDB中に存在する4つのカラムA,B,
C,Dに対して検索処理および更新処理を実行するSQ
Lコマンドを仮定する。そして、上記SQLコマンドの
発行を伴うある業務プログラムを実行させたときの検索
処理および更新処理の回数が、カラムAに対して各40
回、カラムBに対して各30回、カラムCに対して各4
0回、カラムDに対して各35回となるものとする。さ
らに、説明を簡略化するため、上記カラムのいずれかに
ついて1つのインデックスを付加すると、付加する以前
にくらべて1回当りの検索時間は1/2倍に、1回当り
の更新時間は2倍になるものと仮定する。
理前後における各種性能値の一具体例を示す図である。
同図中、あるRDB中に存在する4つのカラムA,B,
C,Dに対して検索処理および更新処理を実行するSQ
Lコマンドを仮定する。そして、上記SQLコマンドの
発行を伴うある業務プログラムを実行させたときの検索
処理および更新処理の回数が、カラムAに対して各40
回、カラムBに対して各30回、カラムCに対して各4
0回、カラムDに対して各35回となるものとする。さ
らに、説明を簡略化するため、上記カラムのいずれかに
ついて1つのインデックスを付加すると、付加する以前
にくらべて1回当りの検索時間は1/2倍に、1回当り
の更新時間は2倍になるものと仮定する。
【0017】最初に、RDBを作成した直後のインデッ
クスが全く付加されていない初期状態において、上述し
たステップ203でジャーナルに取得される同種のSQ
Lコマンド別の稼動情報は、例えば図3に示す具体例の
場合、 カラムAの総検索時間:TRA0=160(ミリ秒) カラムBの総検索時間:TRB0=120(ミリ秒) カラムCの総検索時間:TRC0= 40(ミリ秒) カラムDの総検索時間:TRD0= 70(ミリ秒) カラムAの総更新時間:TWA0= 40(ミリ秒) カラムBの総更新時間:TWB0= 30(ミリ秒) カラムCの総更新時間:TWC0= 80(ミリ秒) カラムDの総更新時間:TWD0= 70(ミリ秒) である。そこで、 カラムAの総実行時間:TRWA0=200(ミリ秒) カラムBの総実行時間:TRWB0=150(ミリ秒) カラムCの総実行時間:TRWC0=120(ミリ秒) カラムDの総実行時間:TRWD0=140(ミリ秒) とともに、これら総実行時間の累計値 610(ミリ秒)が
求められる。
クスが全く付加されていない初期状態において、上述し
たステップ203でジャーナルに取得される同種のSQ
Lコマンド別の稼動情報は、例えば図3に示す具体例の
場合、 カラムAの総検索時間:TRA0=160(ミリ秒) カラムBの総検索時間:TRB0=120(ミリ秒) カラムCの総検索時間:TRC0= 40(ミリ秒) カラムDの総検索時間:TRD0= 70(ミリ秒) カラムAの総更新時間:TWA0= 40(ミリ秒) カラムBの総更新時間:TWB0= 30(ミリ秒) カラムCの総更新時間:TWC0= 80(ミリ秒) カラムDの総更新時間:TWD0= 70(ミリ秒) である。そこで、 カラムAの総実行時間:TRWA0=200(ミリ秒) カラムBの総実行時間:TRWB0=150(ミリ秒) カラムCの総実行時間:TRWC0=120(ミリ秒) カラムDの総実行時間:TRWD0=140(ミリ秒) とともに、これら総実行時間の累計値 610(ミリ秒)が
求められる。
【0018】また、上記業務プログラムを実行させたと
きの検索処理および更新処理の回数にしたがって、 カラムAの1回当りの検索時間:RA0=4(ミリ秒) カラムBの1回当りの検索時間:RB0=4(ミリ秒) カラムCの1回当りの検索時間:RC0=1(ミリ秒) カラムDの1回当りの検索時間:RD0=2(ミリ秒) カラムAの1回当りの更新時間:WA0=1(ミリ秒) カラムBの1回当りの更新時間:WB0=1(ミリ秒) カラムCの1回当りの更新時間:WC0=2(ミリ秒) カラムDの1回当りの更新時間:WD0=2(ミリ秒) が求められる。
きの検索処理および更新処理の回数にしたがって、 カラムAの1回当りの検索時間:RA0=4(ミリ秒) カラムBの1回当りの検索時間:RB0=4(ミリ秒) カラムCの1回当りの検索時間:RC0=1(ミリ秒) カラムDの1回当りの検索時間:RD0=2(ミリ秒) カラムAの1回当りの更新時間:WA0=1(ミリ秒) カラムBの1回当りの更新時間:WB0=1(ミリ秒) カラムCの1回当りの更新時間:WC0=2(ミリ秒) カラムDの1回当りの更新時間:WD0=2(ミリ秒) が求められる。
【0019】上述した初期状態で図2に示したインデッ
クス自動付加を行うと、4つのカラムA,B,C,Dの
うち、総実行時間が上位半数に含まれる2つのカラムA
(符号#,TRWA0=200)およびカラムB(符号#
,TRWB0=150)に対して新たなインデックスの生成
・付加が行われるため、カラムAおよびBの1回当りの
検索時間は1/2倍、同じく1回当りの更新時間は2倍
となる。すなわち、インデックスの1回目の付加が行わ
れた各カラムの1回当りの検索時間と更新時間は、 カラムAの1回当りの検索時間:RA1=2(ミリ秒) カラムBの1回当りの検索時間:RB1=2(ミリ秒) カラムCの1回当りの検索時間:RC1=1(ミリ秒) カラムDの1回当りの検索時間:RD1=2(ミリ秒) カラムAの1回当りの更新時間:WA1=2(ミリ秒) カラムBの1回当りの更新時間:WB1=2(ミリ秒) カラムCの1回当りの更新時間:WC1=2(ミリ秒) カラムDの1回当りの更新時間:WD1=2(ミリ秒) となる。
クス自動付加を行うと、4つのカラムA,B,C,Dの
うち、総実行時間が上位半数に含まれる2つのカラムA
(符号#,TRWA0=200)およびカラムB(符号#
,TRWB0=150)に対して新たなインデックスの生成
・付加が行われるため、カラムAおよびBの1回当りの
検索時間は1/2倍、同じく1回当りの更新時間は2倍
となる。すなわち、インデックスの1回目の付加が行わ
れた各カラムの1回当りの検索時間と更新時間は、 カラムAの1回当りの検索時間:RA1=2(ミリ秒) カラムBの1回当りの検索時間:RB1=2(ミリ秒) カラムCの1回当りの検索時間:RC1=1(ミリ秒) カラムDの1回当りの検索時間:RD1=2(ミリ秒) カラムAの1回当りの更新時間:WA1=2(ミリ秒) カラムBの1回当りの更新時間:WB1=2(ミリ秒) カラムCの1回当りの更新時間:WC1=2(ミリ秒) カラムDの1回当りの更新時間:WD1=2(ミリ秒) となる。
【0020】そこで、 カラムAの総検索時間:TRA1= 80(ミリ秒) カラムBの総検索時間:TRB1= 60(ミリ秒) カラムCの総検索時間:TRC1= 40(ミリ秒) カラムDの総検索時間:TRD1= 70(ミリ秒) カラムAの総更新時間:TWA1= 80(ミリ秒) カラムBの総更新時間:TWB1= 60(ミリ秒) カラムCの総更新時間:TWC1= 80(ミリ秒) カラムDの総更新時間:TWD1= 70(ミリ秒) カラムAの総実行時間:TRWA1=160(ミリ秒) カラムBの総実行時間:TRWB1=120(ミリ秒) カラムCv総実行時間:TRWC1=120(ミリ秒) カラムDの総実行時間:TRWD1=140(ミリ秒) とともに、これら総実行時間の累計値 540(ミリ秒)が
求められる。この値は前回の総実行時間の累計値 610
(ミリ秒)より小さいので、RDBに対する処理性能が
向上したものとみなされる。
求められる。この値は前回の総実行時間の累計値 610
(ミリ秒)より小さいので、RDBに対する処理性能が
向上したものとみなされる。
【0021】したがって引き続き、4つのカラムA,
B,C,Dのうち、総実行時間が上位半数に含まれる2
つのカラムA(符号%,TRWA1=160)およびカラム
D(符号%,TRWD1=140)に対してさらに新たなイ
ンデックスの生成・付加が行われ、カラムAおよびDの
1回当りの検索時間は1/2倍、同じく1回当りの更新
時間は2倍となる。すなわち、インデックスの2回目の
付加が行われた各カラムの1回当りの検索時間と更新時
間は、 カラムAの1回当りの検索時間:RA2=1(ミリ秒) カラムBの1回当りの検索時間:RB2=2(ミリ秒) カラムCの1回当りの検索時間:RC2=1(ミリ秒) カラムDの1回当りの検索時間:RD2=1(ミリ秒) カラムAの1回当りの更新時間:WA2=4(ミリ秒) カラムBの1回当りの更新時間:WB2=2(ミリ秒) カラムCの1回当りの更新時間:WC2=2(ミリ秒) カラムDの1回当りの更新時間:WD2=4(ミリ秒) となる。
B,C,Dのうち、総実行時間が上位半数に含まれる2
つのカラムA(符号%,TRWA1=160)およびカラム
D(符号%,TRWD1=140)に対してさらに新たなイ
ンデックスの生成・付加が行われ、カラムAおよびDの
1回当りの検索時間は1/2倍、同じく1回当りの更新
時間は2倍となる。すなわち、インデックスの2回目の
付加が行われた各カラムの1回当りの検索時間と更新時
間は、 カラムAの1回当りの検索時間:RA2=1(ミリ秒) カラムBの1回当りの検索時間:RB2=2(ミリ秒) カラムCの1回当りの検索時間:RC2=1(ミリ秒) カラムDの1回当りの検索時間:RD2=1(ミリ秒) カラムAの1回当りの更新時間:WA2=4(ミリ秒) カラムBの1回当りの更新時間:WB2=2(ミリ秒) カラムCの1回当りの更新時間:WC2=2(ミリ秒) カラムDの1回当りの更新時間:WD2=4(ミリ秒) となる。
【0022】そこで、 カラムAの総検索時間:TRA2= 40(ミリ秒) カラムBの総検索時間:TRB2= 60(ミリ秒) カラムCの総検索時間:TRC2= 40(ミリ秒) カラムDの総検索時間:TRD2= 35(ミリ秒) カラムAの総更新時間:TWA2=160(ミリ秒) カラムBの総更新時間:TWB2= 60(ミリ秒) カラムCの総更新時間:TWC2= 80(ミリ秒) カラムDの総更新時間:TWD2=140(ミリ秒) カラムAの総実行時間:TRWA2=200(ミリ秒) カラムBの総実行時間:TRWB2=120(ミリ秒) カラムCの総実行時間:TRWC2=120(ミリ秒) カラムDの総実行時間:TRWD2=175(ミリ秒) とともに、これら総実行時間の累計値 615(ミリ秒)が
求められる。この値は前回の総実行時間の累計値 540
(ミリ秒)より大きいので、RDBに対する処理性能が
低下したものとみなされる。そこで、総実行時間の合計
値を増大させる原因となったカラムAおよびDに対する
新たなインデックスの付加を取り消して、前回の状態に
戻す。以上により、検索効率と更新効率のバランスがと
れている最適化されたインデックスの付加が完了する。
求められる。この値は前回の総実行時間の累計値 540
(ミリ秒)より大きいので、RDBに対する処理性能が
低下したものとみなされる。そこで、総実行時間の合計
値を増大させる原因となったカラムAおよびDに対する
新たなインデックスの付加を取り消して、前回の状態に
戻す。以上により、検索効率と更新効率のバランスがと
れている最適化されたインデックスの付加が完了する。
【0023】図4は、図1中のジャーナルに記録される
稼動情報の一例を示す図であり、業務プログラムからS
QLコマンドが発行される都度、ジャーナルに取得す
る。稼動情報は、SQLコマンド発行年月日40および
発行時刻41、SQLコマンド実行時間42、インデッ
クス付加回数43、SQLコマンド内容44から構成さ
れる。インデックス付加回数43は、稼動情報をジャー
ナルに取得したときのインデックスの状態を識別するた
めの番号である。本実施形態においては、インデックス
が付加されていないとき“0”を設定し、新たにインデ
ックスの生成・付加を行う都度、“1”,“2”のよう
に増加させた値を設定する。これにより、例えば、現在
のインデックス付加回数43が“5”である場合に前回
の稼動情報を求めるためには、インデックス付加回数4
3が“4”に設定された稼動情報をジャーナルから選択
すればよい。SQLコマンド内容44は、発行したSQ
Lコマンドを識別するコマンド名称45、処理対象のカ
ラム数46、処理対象のカラム名称47から構成され
る。そして、処理対象のカラム数46が複数であれば、
それに対応したカラム数分に相当する複数個のカラム名
称47,48、……が設けられる。
稼動情報の一例を示す図であり、業務プログラムからS
QLコマンドが発行される都度、ジャーナルに取得す
る。稼動情報は、SQLコマンド発行年月日40および
発行時刻41、SQLコマンド実行時間42、インデッ
クス付加回数43、SQLコマンド内容44から構成さ
れる。インデックス付加回数43は、稼動情報をジャー
ナルに取得したときのインデックスの状態を識別するた
めの番号である。本実施形態においては、インデックス
が付加されていないとき“0”を設定し、新たにインデ
ックスの生成・付加を行う都度、“1”,“2”のよう
に増加させた値を設定する。これにより、例えば、現在
のインデックス付加回数43が“5”である場合に前回
の稼動情報を求めるためには、インデックス付加回数4
3が“4”に設定された稼動情報をジャーナルから選択
すればよい。SQLコマンド内容44は、発行したSQ
Lコマンドを識別するコマンド名称45、処理対象のカ
ラム数46、処理対象のカラム名称47から構成され
る。そして、処理対象のカラム数46が複数であれば、
それに対応したカラム数分に相当する複数個のカラム名
称47,48、……が設けられる。
【0024】図5は、図1中の集計・ソート部による稼
動情報の処理に使用される作業テーブルの一例を示す図
である。この作業テーブルはSQLコマンドの内容別対
応に作成するものであり、SQLコマンド総実行時間5
0、前回のSQLコマンド総実行時間51、SQLコマ
ンド内容52から構成される。上述した稼動情報と同様
に、SQLコマンド内容52は、発行したSQLコマン
ドを識別するコマンド名称53、処理対象のカラム数5
4、処理対象のカラム名称55から構成され、処理対象
のカラム数54が複数であれば、それに対応したカラム
数分に相当する複数個のカラム名称55,56、……が
設けられる。SQLコマンド総実行時間50は、ジャー
ナルに記録蓄積されている稼動情報のうち、同種のSQ
Lコマンドの稼動情報に含まれるSQLコマンド実行時
間63の合計値である。本実施形態においては、ジャー
ナルの稼動情報をすべて集計した後、総実行時間50を
キーにソートすることにより、実行時間のより長いSQ
Lコマンドと新たなインデックスを付加すべきカラムを
求める。前回のSQLコマンド総実行時間51は、稼動
情報中の現在のインデックス付加回数62から1を減算
した値に等しいインデックス付加回数62が含まれてい
るすべての稼動情報について、そのSQL実行時間63
を集計することによって求められる。
動情報の処理に使用される作業テーブルの一例を示す図
である。この作業テーブルはSQLコマンドの内容別対
応に作成するものであり、SQLコマンド総実行時間5
0、前回のSQLコマンド総実行時間51、SQLコマ
ンド内容52から構成される。上述した稼動情報と同様
に、SQLコマンド内容52は、発行したSQLコマン
ドを識別するコマンド名称53、処理対象のカラム数5
4、処理対象のカラム名称55から構成され、処理対象
のカラム数54が複数であれば、それに対応したカラム
数分に相当する複数個のカラム名称55,56、……が
設けられる。SQLコマンド総実行時間50は、ジャー
ナルに記録蓄積されている稼動情報のうち、同種のSQ
Lコマンドの稼動情報に含まれるSQLコマンド実行時
間63の合計値である。本実施形態においては、ジャー
ナルの稼動情報をすべて集計した後、総実行時間50を
キーにソートすることにより、実行時間のより長いSQ
Lコマンドと新たなインデックスを付加すべきカラムを
求める。前回のSQLコマンド総実行時間51は、稼動
情報中の現在のインデックス付加回数62から1を減算
した値に等しいインデックス付加回数62が含まれてい
るすべての稼動情報について、そのSQL実行時間63
を集計することによって求められる。
【0025】本実施形態によれば、システム管理者の個
人的技量やシステムの運用形態などに関わらず、指定し
た試行条件下における検索効率および更新効率のバラン
スがとれた最適なインデックスを自動的に作成・付加し
て、RDBの運用効率を総合的に向上させることができ
る。そして、該当するRDBに対して何らかの処理を行
うあらゆるSQLコマンドについて検索効率および更新
効率の測定が可能なため、これまでシステム管理者が手
作業で行ってきたときのようなインデックスの作成漏れ
が生じるおそれがなくなり、システムの本番運用当日か
ら最適な運用状態を実現させることができる。また、定
期的あるいは運用に何らかの変化があったときインデッ
クスの最適化を行うようにすれば、常に最適なシステム
の運用状態を保持することができる。
人的技量やシステムの運用形態などに関わらず、指定し
た試行条件下における検索効率および更新効率のバラン
スがとれた最適なインデックスを自動的に作成・付加し
て、RDBの運用効率を総合的に向上させることができ
る。そして、該当するRDBに対して何らかの処理を行
うあらゆるSQLコマンドについて検索効率および更新
効率の測定が可能なため、これまでシステム管理者が手
作業で行ってきたときのようなインデックスの作成漏れ
が生じるおそれがなくなり、システムの本番運用当日か
ら最適な運用状態を実現させることができる。また、定
期的あるいは運用に何らかの変化があったときインデッ
クスの最適化を行うようにすれば、常に最適なシステム
の運用状態を保持することができる。
【0026】
【発明の効果】以上詳しく説明したように、本発明のR
DBのインデックス最適化システムによれば、システム
管理者の個人的技量やシステムの運用形態などに関わら
ず、指定した試行条件下における検索効率および更新効
率のバランスがとれた最適なインデックスを自動的に作
成・付加して、RDBの運用効率を総合的に向上させる
ことができる。
DBのインデックス最適化システムによれば、システム
管理者の個人的技量やシステムの運用形態などに関わら
ず、指定した試行条件下における検索効率および更新効
率のバランスがとれた最適なインデックスを自動的に作
成・付加して、RDBの運用効率を総合的に向上させる
ことができる。
【図1】本発明のリレーショナルデータベースのインデ
ックス自動付加システムの一実施形態を適用したシステ
ム構成例を示すブロック図である。
ックス自動付加システムの一実施形態を適用したシステ
ム構成例を示すブロック図である。
【図2】図1のシステムによるインデックス自動付加の
全体的な手順の一例を示すフローチャートである。
全体的な手順の一例を示すフローチャートである。
【図3】図2のインデックス自動付加の処理前後におけ
る各種性能値の一具体例を示す図である。
る各種性能値の一具体例を示す図である。
【図4】図1中のジャーナルに記録される稼動情報の一
例を示す図である。
例を示す図である。
【図5】図1中の集計・ソート部による稼動情報の処理
に使用される作業テーブルの一例を示す図である。
に使用される作業テーブルの一例を示す図である。
22 SQL解析・実行処理部 23 稼動情報取得処理部 24 ジャーナル 26 集計・ソート部 27 インデックス制御部
Claims (1)
- 【請求項1】 リレーショナルデータベースに対し、そ
の処理効率を最適化させるインデックスの生成・付加を
行うリレーショナルデータベースのインデックス自動付
加システムにおいて、 業務プログラムが発行するリレーショナルデータベース
処理操作用のSQLコマンドを解析し、前記リレーショ
ナルデータベースを対象とする検索処理および更新処理
の実行制御を行うSQL解析・実行処理部と、 発行されたすべての前記SQLコマンドについて、前記
検索処理の実行に要した検索時間および前記更新処理の
実行に要した更新時間の記録処理を行うデータベース処
理情報記録部と、 処理内容が一致する同種のSQLコマンドの各々につい
て、前記データベース処理情報記録部に記録されている
前記検索時間および前記更新時間を集計した総実行時間
を求め、前記総実行時間をキーに前記同種のSQLコマ
ンドの順序付けを行う集計・ソート部と、 前記集計・ソート部の順序付けにしたがって前記総実行
時間が上位半数に含まれるSQLコマンドを選択し、そ
のSQLコマンドに該当する前記検索処理に要する前記
検索時間を短縮させるインデックスの生成・付加を行う
インデックス制御部と、を具備し、 所定の試行条件下での前記SQL解析・実行処理部によ
る前記実行制御および前記データベース処理情報記録部
による前記記録処理と、前記集計・ソート部および前記
インデックス制御部の処理とを、前記同種のSQLコマ
ンドごとに求められた前記総実行時間すべての累計値が
最小となるまで繰り返すことを特徴とするリレーショナ
ルデータベースのインデックス自動付加システム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP8264742A JPH10111819A (ja) | 1996-10-04 | 1996-10-04 | リレーショナルデータベースのインデックス自動付加システム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP8264742A JPH10111819A (ja) | 1996-10-04 | 1996-10-04 | リレーショナルデータベースのインデックス自動付加システム |
Publications (1)
Publication Number | Publication Date |
---|---|
JPH10111819A true JPH10111819A (ja) | 1998-04-28 |
Family
ID=17407554
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP8264742A Pending JPH10111819A (ja) | 1996-10-04 | 1996-10-04 | リレーショナルデータベースのインデックス自動付加システム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JPH10111819A (ja) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9317539B2 (en) | 2012-11-27 | 2016-04-19 | Hitachi, Ltd. | Time-series database setup automatic generation method, setup automatic generation system and monitoring server |
WO2017183065A1 (ja) | 2016-04-19 | 2017-10-26 | 株式会社シスバンク | リレーショナルデータベースのチューニング装置及び方法 |
JP2023172870A (ja) * | 2022-05-23 | 2023-12-06 | 浙江工商大学 | リレーショナル・データベース向けのインテリジェント・インデックス・チューニング方法およびシステム |
-
1996
- 1996-10-04 JP JP8264742A patent/JPH10111819A/ja active Pending
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9317539B2 (en) | 2012-11-27 | 2016-04-19 | Hitachi, Ltd. | Time-series database setup automatic generation method, setup automatic generation system and monitoring server |
WO2017183065A1 (ja) | 2016-04-19 | 2017-10-26 | 株式会社シスバンク | リレーショナルデータベースのチューニング装置及び方法 |
US10216773B2 (en) | 2016-04-19 | 2019-02-26 | Sysbank Co., Ltd. | Apparatus and method for tuning relational database |
JP2023172870A (ja) * | 2022-05-23 | 2023-12-06 | 浙江工商大学 | リレーショナル・データベース向けのインテリジェント・インデックス・チューニング方法およびシステム |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP0877327B1 (en) | Method and apparatus for performing a join query in a database system | |
US7685104B2 (en) | Dynamic bitmap processing, identification and reusability | |
JP2768433B2 (ja) | 物理データベース設計システム | |
US8447743B2 (en) | Techniques for processing database queries including user-defined functions | |
US7797286B2 (en) | System and method for externally providing database optimizer statistics | |
US5727196A (en) | Optimized query interface for database management systems | |
US7015911B2 (en) | Computer-implemented system and method for report generation | |
US5761654A (en) | Memory structure and method for tuning a database statement using a join-tree data structure representation, including selectivity factors, of a master table and detail table | |
CN108027763B (zh) | 关系型数据库的调整装置和方法 | |
US20030061244A1 (en) | System and method for database query optimization | |
JPH0776936B2 (ja) | アクセス経路選択方法 | |
JP2004518226A (ja) | データベースシステムおよびクエリオプティマイザ | |
US7047231B2 (en) | Getpage-workload based index optimizer | |
JPH07129442A (ja) | 情報管理機構 | |
CN112162983A (zh) | 数据库索引建议处理方法、装置、介质和电子设备 | |
US6999967B1 (en) | Semantically reducing the number of partitions involved in a join | |
US20050108204A1 (en) | System and method for managing OLAP summary tables | |
US20060143206A1 (en) | Interval tree for identifying intervals that intersect with a query interval | |
Pedrozo et al. | A tool for automatic index selection in database management systems | |
JPH10111819A (ja) | リレーショナルデータベースのインデックス自動付加システム | |
US10810196B2 (en) | Materialized view generation | |
US7127457B1 (en) | Method and system for executing database queries | |
US11630819B2 (en) | Techniques for controlling interaction with an application database | |
JPH07105058A (ja) | リレーショナル・データ・ベース・マネージメント・システム | |
JPH05313971A (ja) | リレーショナル・データベースにおけるキーワード管理方式 |