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)【要約】
【課題】 リレーショナルデータベース（ＲＤＢ）のイ
ンデックス自動付加システムに関し、管理者の技量やシ
ステムの運用形態などに関わらず、ＲＤＢ運用効率を総
合的に向上可能とする。 【解決手段】 実際の業務運用を行う場合と同等の試行
条件下で業務プログラムを実行させ、発行された全ＳＱ
Ｌコマンドについてその実行時間などの稼動情報をジャ
ーナルに取得する。業務プログラム終了後、蓄積された
稼動情報に基づいて、処理内容が一致する同種のＳＱＬ
コマンドごとに上記実行時間を集計した総実行時間を求
める。そして、総実行時間の値が上位半数に含まれるＳ
ＱＬコマンドの処理対象となるカラムに新たなインデッ
クスを付加した後、再度業務プログラムを実行させ、上
述した処理を繰り返す。これを各ＳＱＬコマンドの総実
行時間の累計値が最小となるまで繰り返し、検索と更新
のバランスがとれた最適なインデックスを自動生成・付
加する。
ンデックス自動付加システムに関し、管理者の技量やシ
ステムの運用形態などに関わらず、ＲＤＢ運用効率を総
合的に向上可能とする。 【解決手段】 実際の業務運用を行う場合と同等の試行
条件下で業務プログラムを実行させ、発行された全ＳＱ
Ｌコマンドについてその実行時間などの稼動情報をジャ
ーナルに取得する。業務プログラム終了後、蓄積された
稼動情報に基づいて、処理内容が一致する同種のＳＱＬ
コマンドごとに上記実行時間を集計した総実行時間を求
める。そして、総実行時間の値が上位半数に含まれるＳ
ＱＬコマンドの処理対象となるカラムに新たなインデッ
クスを付加した後、再度業務プログラムを実行させ、上
述した処理を繰り返す。これを各ＳＱＬコマンドの総実
行時間の累計値が最小となるまで繰り返し、検索と更新
のバランスがとれた最適なインデックスを自動生成・付
加する。
Description
【０００１】
【発明の属する技術分野】本発明はリレーショナルデー
タベースのインデックス自動付加システムに係り、特
に、リレーショナルデータベースの運用効率を向上させ
るインデックスを自動的に生成・付加するリレーショナ
ルデータベースのインデックス自動付加システムに関す
る。
タベースのインデックス自動付加システムに係り、特
に、リレーショナルデータベースの運用効率を向上させ
るインデックスを自動的に生成・付加するリレーショナ
ルデータベースのインデックス自動付加システムに関す
る。
【０００２】
【従来の技術】従来、リレーショナルデータベース（Ｒ
ＤＢ）の検索効率を向上させるためのインデックスの作
成・付加は、ＲＤＢに関する知識を持つシステム管理者
が、ティムマーティン及びティムハートレー著「ＤＢ２
／ＳＱＬ ア・プロフェッショナル・プログラマーズ・
ガイド」（１９８９年）の２０８〜２１６ページ（TimM
artyn,Tim Hartley DB2/SQL A Professional Programme
r's Guide(1989）P208-216)に記載されているような専
用のインデックス作成コマンドを使用して行っていた。
ＤＢ）の検索効率を向上させるためのインデックスの作
成・付加は、ＲＤＢに関する知識を持つシステム管理者
が、ティムマーティン及びティムハートレー著「ＤＢ２
／ＳＱＬ ア・プロフェッショナル・プログラマーズ・
ガイド」（１９８９年）の２０８〜２１６ページ（TimM
artyn,Tim Hartley DB2/SQL A Professional Programme
r's Guide(1989）P208-216)に記載されているような専
用のインデックス作成コマンドを使用して行っていた。
【０００３】
【発明が解決しようとする課題】上記従来技術におい
て、システム管理者は、これまで蓄積されてきた経験則
や管理対象のシステムの運用形態などを勘案しながらＲ
ＤＢの検索効率を予測し、最適と考えられるインデック
スの作成・付加を行っていくのが一般的である。このた
め、管理対象のシステムが経験則を活用しにくい特殊な
ものであった場合や、システム管理者の個人的技量が不
十分であった場合、実際の検索効率が当初予想した検索
効率を達成しているとは限らないという問題点があっ
た。また、システムの運用が進むにしたがって、ＲＤＢ
の内容やその検索を行う業務プログラムの使用頻度など
に少しずつ変化が生じ、ＲＤＢの検索効率が低下してし
まうことがあるという問題点があった。さらに、インデ
ックス付加によって検索効率を向上させると、インデッ
クス維持のためのオーバヘッドによって更新効率が低下
してしまう結果を招く（トレードオフ）ため、検索効率
および更新効率のバランスがとれた最適なインデックス
を作成・付加してＲＤＢの運用効率を総合的に向上させ
ることは困難であるという問題点があった。
て、システム管理者は、これまで蓄積されてきた経験則
や管理対象のシステムの運用形態などを勘案しながらＲ
ＤＢの検索効率を予測し、最適と考えられるインデック
スの作成・付加を行っていくのが一般的である。このた
め、管理対象のシステムが経験則を活用しにくい特殊な
ものであった場合や、システム管理者の個人的技量が不
十分であった場合、実際の検索効率が当初予想した検索
効率を達成しているとは限らないという問題点があっ
た。また、システムの運用が進むにしたがって、ＲＤＢ
の内容やその検索を行う業務プログラムの使用頻度など
に少しずつ変化が生じ、ＲＤＢの検索効率が低下してし
まうことがあるという問題点があった。さらに、インデ
ックス付加によって検索効率を向上させると、インデッ
クス維持のためのオーバヘッドによって更新効率が低下
してしまう結果を招く（トレードオフ）ため、検索効率
および更新効率のバランスがとれた最適なインデックス
を作成・付加してＲＤＢの運用効率を総合的に向上させ
ることは困難であるという問題点があった。
【０００４】したがって本発明の目的は、上記の問題点
を解決して、システム管理者の技量やシステムの運用形
態などに関わらず、ＲＤＢの運用効率を総合的に向上さ
せることが可能なリレーショナルデータベースのインデ
ックス自動付加システムを提供することにある。
を解決して、システム管理者の技量やシステムの運用形
態などに関わらず、ＲＤＢの運用効率を総合的に向上さ
せることが可能なリレーショナルデータベースのインデ
ックス自動付加システムを提供することにある。
【０００５】
【課題を解決するための手段】上記の目的を達成するた
め、本発明のリレーショナルデータベースのインデック
ス自動付加システムは、リレーショナルデータベースに
対し、その処理効率を最適化させるインデックスの生成
・付加を行うリレーショナルデータベースのインデック
ス自動付加システムにおいて、業務プログラムが発行す
るリレーショナルデータベース処理操作用のＳＱＬコマ
ンドを解析し、前記リレーショナルデータベースを対象
とする検索処理および更新処理の実行制御を行うＳＱＬ
解析・実行処理部と、発行されたすべての前記ＳＱＬコ
マンドについて、前記検索処理の実行に要した検索時間
および前記更新処理の実行に要した更新時間の記録処理
を行うデータベース処理情報記録部と、処理内容が一致
する同種のＳＱＬコマンドの各々について、前記データ
ベース処理情報記録部に記録されている前記検索時間お
よび前記更新時間を集計した総実行時間を求め、前記総
実行時間をキーに前記同種のＳＱＬコマンドの順序付け
を行う集計・ソート部と、前記集計・ソート部の順序付
けにしたがって前記総実行時間が上位半数に含まれるＳ
ＱＬコマンドを選択し、そのＳＱＬコマンドに該当する
前記検索処理に要する前記検索時間を短縮させるインデ
ックスの生成・付加を行うインデックス制御部と、を具
備し、所定の試行条件下での前記ＳＱＬ解析・実行処理
部による前記実行制御および前記データベース処理情報
記録部による前記記録処理と、前記集計・ソート部およ
び前記インデックス制御部の処理とを、前記同種のＳＱ
Ｌコマンドごとに求められた前記総実行時間すべての累
計値が最小となるまで繰り返すものである。
め、本発明のリレーショナルデータベースのインデック
ス自動付加システムは、リレーショナルデータベースに
対し、その処理効率を最適化させるインデックスの生成
・付加を行うリレーショナルデータベースのインデック
ス自動付加システムにおいて、業務プログラムが発行す
るリレーショナルデータベース処理操作用のＳＱＬコマ
ンドを解析し、前記リレーショナルデータベースを対象
とする検索処理および更新処理の実行制御を行うＳＱＬ
解析・実行処理部と、発行されたすべての前記ＳＱＬコ
マンドについて、前記検索処理の実行に要した検索時間
および前記更新処理の実行に要した更新時間の記録処理
を行うデータベース処理情報記録部と、処理内容が一致
する同種のＳＱＬコマンドの各々について、前記データ
ベース処理情報記録部に記録されている前記検索時間お
よび前記更新時間を集計した総実行時間を求め、前記総
実行時間をキーに前記同種のＳＱＬコマンドの順序付け
を行う集計・ソート部と、前記集計・ソート部の順序付
けにしたがって前記総実行時間が上位半数に含まれるＳ
ＱＬコマンドを選択し、そのＳＱＬコマンドに該当する
前記検索処理に要する前記検索時間を短縮させるインデ
ックスの生成・付加を行うインデックス制御部と、を具
備し、所定の試行条件下での前記ＳＱＬ解析・実行処理
部による前記実行制御および前記データベース処理情報
記録部による前記記録処理と、前記集計・ソート部およ
び前記インデックス制御部の処理とを、前記同種のＳＱ
Ｌコマンドごとに求められた前記総実行時間すべての累
計値が最小となるまで繰り返すものである。
【０００６】これにより、システム管理者の個人的技量
やシステムの運用形態などに関わらず、指定した試行条
件下における検索効率および更新効率のバランスがとれ
た最適なインデックスを自動的に作成・付加して、ＲＤ
Ｂの運用効率を総合的に向上させることができる。
やシステムの運用形態などに関わらず、指定した試行条
件下における検索効率および更新効率のバランスがとれ
た最適なインデックスを自動的に作成・付加して、ＲＤ
Ｂの運用効率を総合的に向上させることができる。
【０００７】
【発明の実施の形態】以下、本発明のリレーショナルデ
ータベースのインデックス自動付加システムの実施の形
態を図面を用いて詳細に説明する。
ータベースのインデックス自動付加システムの実施の形
態を図面を用いて詳細に説明する。
【０００８】図１は、本発明のリレーショナルデータベ
ースのインデックス自動付加システムの一実施形態を適
用したシステム構成例を示すブロック図である。同図
中、１１は業務プログラム、１２は業務プログラム１１
により発行されるＳＱＬ( Structured Query Language)
コマンド、２１はＳＱＬコマンド１２に応じた制御を実
現するデータベース管理システム（ＤＢＭＳ）、２２は
ＳＱＬコマンド１２の内容を解析して対応する検索処理
や更新処理の実行制御を行うＳＱＬ解析・実行処理部、
２３はＳＱＬ解析・実行処理部２２における処理に関す
る稼動情報２５を求める稼動情報取得処理部、２４は稼
動情報取得処理部２３で求めた稼動情報２５を蓄積記録
しておくジャーナル、２６は稼動情報２５の集計処理お
よびソート処理を行う集計・ソート部、２７は集計・ソ
ート部２６の処理結果に応じてインデックスの生成・付
加制御を行うインデックス制御部、３１は業務プログラ
ム１１の処理対象となるリレーショナルデータベース
（ＲＤＢ）、３２は検索処理の初期段階で参照されるイ
ンデックス、３３は検索処理や更新処理で最終的な目的
とされるデータである。ここで、稼動情報取得処理部２
３およびジャーナル２４が請求項中の“データベース処
理情報記録部”に相当する。
ースのインデックス自動付加システムの一実施形態を適
用したシステム構成例を示すブロック図である。同図
中、１１は業務プログラム、１２は業務プログラム１１
により発行されるＳＱＬ( Structured Query Language)
コマンド、２１はＳＱＬコマンド１２に応じた制御を実
現するデータベース管理システム（ＤＢＭＳ）、２２は
ＳＱＬコマンド１２の内容を解析して対応する検索処理
や更新処理の実行制御を行うＳＱＬ解析・実行処理部、
２３はＳＱＬ解析・実行処理部２２における処理に関す
る稼動情報２５を求める稼動情報取得処理部、２４は稼
動情報取得処理部２３で求めた稼動情報２５を蓄積記録
しておくジャーナル、２６は稼動情報２５の集計処理お
よびソート処理を行う集計・ソート部、２７は集計・ソ
ート部２６の処理結果に応じてインデックスの生成・付
加制御を行うインデックス制御部、３１は業務プログラ
ム１１の処理対象となるリレーショナルデータベース
（ＲＤＢ）、３２は検索処理の初期段階で参照されるイ
ンデックス、３３は検索処理や更新処理で最終的な目的
とされるデータである。ここで、稼動情報取得処理部２
３およびジャーナル２４が請求項中の“データベース処
理情報記録部”に相当する。
【０００９】図１において、最初にシステム管理者は、
インデックス３２を全く付加せずにＲＤＢ３１を作成し
た後、実際に業務運用を行う場合と同等の試行条件下で
業務プログラム１１を実行させる。業務プログラム１１
がＳＱＬコマンド１２を発行すると、ＤＢＭＳ２１内の
ＳＱＬ解析・実行処理部２２は、そのＳＱＬコマンド１
２を解析して、ＲＤＢ３１を対象とする検索処理や更新
処理を実行する。このとき、稼動情報取得処理部２３
は、ＳＱＬコマンド１２の内容と対応する検索処理の実
行に要した検索時間あるいは更新処理の実行に要した更
新時間を稼動情報２５として取得し、ジャーナル２４に
蓄積記録する。したがって、ＲＤＢ３１を対象とする検
索処理や更新処理に関わるＳＱＬコマンド１２の発行を
伴うすべての業務プログラム１１を実行させることによ
り、ＲＤＢ３１に関わるすべてのＳＱＬコマンド１２の
稼動情報２５がジャーナル２４に記録される。集計・ソ
ート部２６は、ジャーナル２４に記録されたＲＤＢ３１
に関わるすべてのＳＱＬコマンド１２の稼動情報２５に
ついて、その処理内容が一致する同種のＳＱＬコマンド
ごとに検索時間と更新時間を集計した後、その時間の降
順にＳＱＬコマンドをソートする。インデックス制御部
２７は、ソートされたＳＱＬコマンドのうち、上位半数
に含まれるＳＱＬコマンドについてインデックス３２の
生成・付加制御を行う。
インデックス３２を全く付加せずにＲＤＢ３１を作成し
た後、実際に業務運用を行う場合と同等の試行条件下で
業務プログラム１１を実行させる。業務プログラム１１
がＳＱＬコマンド１２を発行すると、ＤＢＭＳ２１内の
ＳＱＬ解析・実行処理部２２は、そのＳＱＬコマンド１
２を解析して、ＲＤＢ３１を対象とする検索処理や更新
処理を実行する。このとき、稼動情報取得処理部２３
は、ＳＱＬコマンド１２の内容と対応する検索処理の実
行に要した検索時間あるいは更新処理の実行に要した更
新時間を稼動情報２５として取得し、ジャーナル２４に
蓄積記録する。したがって、ＲＤＢ３１を対象とする検
索処理や更新処理に関わるＳＱＬコマンド１２の発行を
伴うすべての業務プログラム１１を実行させることによ
り、ＲＤＢ３１に関わるすべてのＳＱＬコマンド１２の
稼動情報２５がジャーナル２４に記録される。集計・ソ
ート部２６は、ジャーナル２４に記録されたＲＤＢ３１
に関わるすべてのＳＱＬコマンド１２の稼動情報２５に
ついて、その処理内容が一致する同種のＳＱＬコマンド
ごとに検索時間と更新時間を集計した後、その時間の降
順にＳＱＬコマンドをソートする。インデックス制御部
２７は、ソートされたＳＱＬコマンドのうち、上位半数
に含まれるＳＱＬコマンドについてインデックス３２の
生成・付加制御を行う。
【００１０】以上によってＲＤＢ３１に新たなインデッ
クス３２が付加されると、再び業務プログラム１１を実
行させ、稼動情報取得処理部２３により新たなインデッ
クス３２が反映された新たな稼動情報２５をジャーナル
２４に記録させる。そして、集計・ソート部２６は、こ
の新たな稼動情報２５に基づいて上記と同様の集計・ソ
ートを行い、インデックス制御部２７は、ソートされた
ＳＱＬコマンドの上位半数についてインデックス３２の
生成・付加制御を行う。このとき、すべてのＳＱＬコマ
ンドに対応する処理に要する実行時間の累計値を求め、
インデックス制御部２７により新たなインデックス３２
を付加しても上記実行時間の累計値が短縮されなくなる
まで、上述した一連の処理を繰り返し実行する。
クス３２が付加されると、再び業務プログラム１１を実
行させ、稼動情報取得処理部２３により新たなインデッ
クス３２が反映された新たな稼動情報２５をジャーナル
２４に記録させる。そして、集計・ソート部２６は、こ
の新たな稼動情報２５に基づいて上記と同様の集計・ソ
ートを行い、インデックス制御部２７は、ソートされた
ＳＱＬコマンドの上位半数についてインデックス３２の
生成・付加制御を行う。このとき、すべてのＳＱＬコマ
ンドに対応する処理に要する実行時間の累計値を求め、
インデックス制御部２７により新たなインデックス３２
を付加しても上記実行時間の累計値が短縮されなくなる
まで、上述した一連の処理を繰り返し実行する。
【００１１】図２は、図１のシステムによるインデック
ス自動付加の全体的な手順の一例を示すフローチャート
である。同図中、最初にシステム管理者がインデックス
を付加しないデータベース（ＲＤＢ）を新規に作成する
（ステップ２０１）。そして、業務プログラムを実行す
るが、最初に実行される業務プログラムはインデックス
を使用せずにＳＱＬコマンドを発行し、ＲＤＢの検索処
理および更新処理を行う（ステップ２０２）。業務プロ
グラムがＳＱＬコマンドを発行したとき、ＤＢＭＳはそ
のＳＱＬコマンドの内容と該当する処理に要した実行時
間とを稼動情報としてジャーナルに取得する（ステップ
２０３）。ひとつの業務プログラムが終了すると、イン
デックス自動付加の対象とする該当ＲＤＢの検索・更新
を伴う業務プログラムがすべて実行済みか否か判定し
（ステップ２０４）、まだ実行していない業務プログラ
ムがあればステップ２０２に戻り、すべての業務プログ
ラムが実行済みであればステップ２０５へ進む。すなわ
ち、ステップ２０２〜２０４を繰り返すことにより、該
当ＲＤＢに対する検索処理および更新処理を実行するあ
らゆるＳＱＬコマンドの稼動情報がジャーナルに取得さ
れる。
ス自動付加の全体的な手順の一例を示すフローチャート
である。同図中、最初にシステム管理者がインデックス
を付加しないデータベース（ＲＤＢ）を新規に作成する
（ステップ２０１）。そして、業務プログラムを実行す
るが、最初に実行される業務プログラムはインデックス
を使用せずにＳＱＬコマンドを発行し、ＲＤＢの検索処
理および更新処理を行う（ステップ２０２）。業務プロ
グラムがＳＱＬコマンドを発行したとき、ＤＢＭＳはそ
のＳＱＬコマンドの内容と該当する処理に要した実行時
間とを稼動情報としてジャーナルに取得する（ステップ
２０３）。ひとつの業務プログラムが終了すると、イン
デックス自動付加の対象とする該当ＲＤＢの検索・更新
を伴う業務プログラムがすべて実行済みか否か判定し
（ステップ２０４）、まだ実行していない業務プログラ
ムがあればステップ２０２に戻り、すべての業務プログ
ラムが実行済みであればステップ２０５へ進む。すなわ
ち、ステップ２０２〜２０４を繰り返すことにより、該
当ＲＤＢに対する検索処理および更新処理を実行するあ
らゆるＳＱＬコマンドの稼動情報がジャーナルに取得さ
れる。
【００１２】この後、ジャーナルに取得した稼動情報中
の実行時間を処理内容が一致する同種のＳＱＬコマンド
ごとに集計して、同種のＳＱＬコマンド別の総実行時間
を求める（ステップ２０５）。そして、インデックスの
生成・付加が１回目であればステップ２０７をスキップ
し（ステップ２０６＝ＹＥＳ）、ステップ２０５で得た
総実行時間をキーとしてＳＱＬコマンドをソートするこ
とにより、総実行時間が長いものほど上位となるように
同種のＳＱＬコマンドを順序付ける（ステップ２０
８）。
の実行時間を処理内容が一致する同種のＳＱＬコマンド
ごとに集計して、同種のＳＱＬコマンド別の総実行時間
を求める（ステップ２０５）。そして、インデックスの
生成・付加が１回目であればステップ２０７をスキップ
し（ステップ２０６＝ＹＥＳ）、ステップ２０５で得た
総実行時間をキーとしてＳＱＬコマンドをソートするこ
とにより、総実行時間が長いものほど上位となるように
同種のＳＱＬコマンドを順序付ける（ステップ２０
８）。
【００１３】続くステップ２０９〜２１３において、総
実行時間の長い上位のＳＱＬコマンドから総実行時間の
短い下位のＳＱＬコマンドへと、１つづつ順番にカレン
トのＳＱＬコマンドを交替させながら、以下の処理を行
う。すなわち、まずカレントのＳＱＬコマンドで使用し
たカラムにインデックスがすでに存在しているか否かを
判定する（ステップ２０９）。この結果、該当カラムに
インデックスが存在しなければ（ステップ２０９＝Ｎ
Ｏ）、カレントのＳＱＬコマンドに対応するインデック
スを単一カラムインデックスとして生成・付加する（ス
テップ２１０）。また、該当カラムにインデックスがす
でに存在していれば（ステップ２０９＝ＹＥＳ）、その
インデックスを削除してから（ステップ２１１）、削除
したインデックスとカレントのＳＱＬコマンドに対応す
るインデックスとをマージして得られる複合カラムイン
デックスを生成・付加する（ステップ２１２）。ステッ
プ２１１および２１２により、同種インデックスの２重
追加が防止されるとともに、同一カラムに対する異なる
条件のインデックスの蓄積が可能となる。最後に、カレ
ントのＳＱＬコマンドを次に総実行時間の短い下位のＳ
ＱＬコマンドに交替させてから、新たなカレントのＳＱ
Ｌコマンドの総実行時間が上位半数に含まれていれば
（ステップ２１３＝ＹＥＳ）、ステップ２０９へ戻る。
すなわち、ステップ２０９〜２１３の繰り返しにより、
業務プログラム中で発行されるすべてのＳＱＬコマンド
のうち、その総実行時間の長さが上位半数に含まれるＳ
ＱＬコマンドに対するインデックスの生成・付加が行わ
れる。
実行時間の長い上位のＳＱＬコマンドから総実行時間の
短い下位のＳＱＬコマンドへと、１つづつ順番にカレン
トのＳＱＬコマンドを交替させながら、以下の処理を行
う。すなわち、まずカレントのＳＱＬコマンドで使用し
たカラムにインデックスがすでに存在しているか否かを
判定する（ステップ２０９）。この結果、該当カラムに
インデックスが存在しなければ（ステップ２０９＝Ｎ
Ｏ）、カレントのＳＱＬコマンドに対応するインデック
スを単一カラムインデックスとして生成・付加する（ス
テップ２１０）。また、該当カラムにインデックスがす
でに存在していれば（ステップ２０９＝ＹＥＳ）、その
インデックスを削除してから（ステップ２１１）、削除
したインデックスとカレントのＳＱＬコマンドに対応す
るインデックスとをマージして得られる複合カラムイン
デックスを生成・付加する（ステップ２１２）。ステッ
プ２１１および２１２により、同種インデックスの２重
追加が防止されるとともに、同一カラムに対する異なる
条件のインデックスの蓄積が可能となる。最後に、カレ
ントのＳＱＬコマンドを次に総実行時間の短い下位のＳ
ＱＬコマンドに交替させてから、新たなカレントのＳＱ
Ｌコマンドの総実行時間が上位半数に含まれていれば
（ステップ２１３＝ＹＥＳ）、ステップ２０９へ戻る。
すなわち、ステップ２０９〜２１３の繰り返しにより、
業務プログラム中で発行されるすべてのＳＱＬコマンド
のうち、その総実行時間の長さが上位半数に含まれるＳ
ＱＬコマンドに対するインデックスの生成・付加が行わ
れる。
【００１４】総実行時間の長さが上位半数に含まれるＳ
ＱＬコマンドに対するインデックスの生成・付加が完了
すると（ステップ２１３＝ＮＯ）、ステップ２０２に戻
って業務プログラムを実行するが、これ以後、業務プロ
グラムは新たに付加されたインデックスを使用してＳＱ
Ｌコマンドを発行し、ＲＤＢの検索処理および更新処理
を行う（ステップ２０２）。そして、再びステップ２０
２〜２０４を繰り返して、インデックスを使用した場合
のすべての業務プログラムの稼動情報がジャーナルに取
得された後、この稼動情報に基づいて同種のＳＱＬコマ
ンド別の総実行時間を求める（ステップ２０５）。イン
デックスの生成・付加は２回目以降なので（ステップ２
０６＝ＮＯ）、新たなインデックスを使用して取得した
稼動情報に基づく今回の総実行時間の累計値と前回の総
実行時間の累計値との比較を行う（ステップ２０７）。
比較の結果、前回の総実行時間の累計値より今回の総実
行時間の累計値の方が小さくなっていれば（ステップ２
０７＝ＮＯ）、新たなインデックスの生成・付加を行っ
たことでＲＤＢに対する処理性能が向上したものとみな
してステップ２０８へ進み、総実行時間の長さが上位半
数に含まれるＳＱＬコマンドに対するさらに新たなイン
デックスの生成・付加を行う（ステップ２０８〜２１
３）。
ＱＬコマンドに対するインデックスの生成・付加が完了
すると（ステップ２１３＝ＮＯ）、ステップ２０２に戻
って業務プログラムを実行するが、これ以後、業務プロ
グラムは新たに付加されたインデックスを使用してＳＱ
Ｌコマンドを発行し、ＲＤＢの検索処理および更新処理
を行う（ステップ２０２）。そして、再びステップ２０
２〜２０４を繰り返して、インデックスを使用した場合
のすべての業務プログラムの稼動情報がジャーナルに取
得された後、この稼動情報に基づいて同種のＳＱＬコマ
ンド別の総実行時間を求める（ステップ２０５）。イン
デックスの生成・付加は２回目以降なので（ステップ２
０６＝ＮＯ）、新たなインデックスを使用して取得した
稼動情報に基づく今回の総実行時間の累計値と前回の総
実行時間の累計値との比較を行う（ステップ２０７）。
比較の結果、前回の総実行時間の累計値より今回の総実
行時間の累計値の方が小さくなっていれば（ステップ２
０７＝ＮＯ）、新たなインデックスの生成・付加を行っ
たことでＲＤＢに対する処理性能が向上したものとみな
してステップ２０８へ進み、総実行時間の長さが上位半
数に含まれるＳＱＬコマンドに対するさらに新たなイン
デックスの生成・付加を行う（ステップ２０８〜２１
３）。
【００１５】このようなステップ２０２〜２１３の処理
を何度か繰り返し、やがて前回の総実行時間の累計値よ
り今回の総実行時間の累計値の方が大きくなってしまっ
た場合（ステップ２０７＝ＹＥＳ）、新たなインデック
スの生成・付加を行ったことでトレードオフによる処理
性能の低下が発生したものとみなし、ステップ２２１へ
進む。ステップ２２１において、新たなインデックスの
ために総実行時間が前回より増加してしまったＳＱＬコ
マンドがあるか否かを判定し、総実行時間が増加したＳ
ＱＬコマンドがあれば（ステップ２２１＝ＹＥＳ）、該
当するＳＱＬコマンドに対応して付加されているインデ
ックスを前回の状態に戻す（ステップ２２２）。
を何度か繰り返し、やがて前回の総実行時間の累計値よ
り今回の総実行時間の累計値の方が大きくなってしまっ
た場合（ステップ２０７＝ＹＥＳ）、新たなインデック
スの生成・付加を行ったことでトレードオフによる処理
性能の低下が発生したものとみなし、ステップ２２１へ
進む。ステップ２２１において、新たなインデックスの
ために総実行時間が前回より増加してしまったＳＱＬコ
マンドがあるか否かを判定し、総実行時間が増加したＳ
ＱＬコマンドがあれば（ステップ２２１＝ＹＥＳ）、該
当するＳＱＬコマンドに対応して付加されているインデ
ックスを前回の状態に戻す（ステップ２２２）。
【００１６】図３は、図２のインデックス自動付加の処
理前後における各種性能値の一具体例を示す図である。
同図中、あるＲＤＢ中に存在する４つのカラムＡ，Ｂ，
Ｃ，Ｄに対して検索処理および更新処理を実行するＳＱ
Ｌコマンドを仮定する。そして、上記ＳＱＬコマンドの
発行を伴うある業務プログラムを実行させたときの検索
処理および更新処理の回数が、カラムＡに対して各４０
回、カラムＢに対して各３０回、カラムＣに対して各４
０回、カラムＤに対して各３５回となるものとする。さ
らに、説明を簡略化するため、上記カラムのいずれかに
ついて１つのインデックスを付加すると、付加する以前
にくらべて１回当りの検索時間は１／２倍に、１回当り
の更新時間は２倍になるものと仮定する。
理前後における各種性能値の一具体例を示す図である。
同図中、あるＲＤＢ中に存在する４つのカラムＡ，Ｂ，
Ｃ，Ｄに対して検索処理および更新処理を実行するＳＱ
Ｌコマンドを仮定する。そして、上記ＳＱＬコマンドの
発行を伴うある業務プログラムを実行させたときの検索
処理および更新処理の回数が、カラムＡに対して各４０
回、カラムＢに対して各３０回、カラムＣに対して各４
０回、カラムＤに対して各３５回となるものとする。さ
らに、説明を簡略化するため、上記カラムのいずれかに
ついて１つのインデックスを付加すると、付加する以前
にくらべて１回当りの検索時間は１／２倍に、１回当り
の更新時間は２倍になるものと仮定する。
【００１７】最初に、ＲＤＢを作成した直後のインデッ
クスが全く付加されていない初期状態において、上述し
たステップ２０３でジャーナルに取得される同種のＳＱ
Ｌコマンド別の稼動情報は、例えば図３に示す具体例の
場合、 カラムＡの総検索時間：ＴＲA0=160（ミリ秒） カラムＢの総検索時間：ＴＲB0=120（ミリ秒） カラムＣの総検索時間：ＴＲC0= 40（ミリ秒） カラムＤの総検索時間：ＴＲD0= 70（ミリ秒） カラムＡの総更新時間：ＴＷA0= 40（ミリ秒） カラムＢの総更新時間：ＴＷB0= 30（ミリ秒） カラムＣの総更新時間：ＴＷC0= 80（ミリ秒） カラムＤの総更新時間：ＴＷD0= 70（ミリ秒） である。そこで、 カラムＡの総実行時間：ＴＲＷA0=200（ミリ秒） カラムＢの総実行時間：ＴＲＷB0=150（ミリ秒） カラムＣの総実行時間：ＴＲＷC0=120（ミリ秒） カラムＤの総実行時間：ＴＲＷD0=140（ミリ秒） とともに、これら総実行時間の累計値 610（ミリ秒）が
求められる。
クスが全く付加されていない初期状態において、上述し
たステップ２０３でジャーナルに取得される同種のＳＱ
Ｌコマンド別の稼動情報は、例えば図３に示す具体例の
場合、 カラムＡの総検索時間：ＴＲA0=160（ミリ秒） カラムＢの総検索時間：ＴＲB0=120（ミリ秒） カラムＣの総検索時間：ＴＲC0= 40（ミリ秒） カラムＤの総検索時間：ＴＲD0= 70（ミリ秒） カラムＡの総更新時間：ＴＷA0= 40（ミリ秒） カラムＢの総更新時間：ＴＷB0= 30（ミリ秒） カラムＣの総更新時間：ＴＷC0= 80（ミリ秒） カラムＤの総更新時間：ＴＷD0= 70（ミリ秒） である。そこで、 カラムＡの総実行時間：ＴＲＷA0=200（ミリ秒） カラムＢの総実行時間：ＴＲＷB0=150（ミリ秒） カラムＣの総実行時間：ＴＲＷC0=120（ミリ秒） カラムＤの総実行時間：ＴＲＷD0=140（ミリ秒） とともに、これら総実行時間の累計値 610（ミリ秒）が
求められる。
【００１８】また、上記業務プログラムを実行させたと
きの検索処理および更新処理の回数にしたがって、 カラムＡの１回当りの検索時間：ＲA0=4（ミリ秒） カラムＢの１回当りの検索時間：ＲB0=4（ミリ秒） カラムＣの１回当りの検索時間：ＲC0=1（ミリ秒） カラムＤの１回当りの検索時間：ＲD0=2（ミリ秒） カラムＡの１回当りの更新時間：ＷA0=1（ミリ秒） カラムＢの１回当りの更新時間：ＷB0=1（ミリ秒） カラムＣの１回当りの更新時間：ＷC0=2（ミリ秒） カラムＤの１回当りの更新時間：ＷD0=2（ミリ秒） が求められる。
きの検索処理および更新処理の回数にしたがって、 カラムＡの１回当りの検索時間：ＲA0=4（ミリ秒） カラムＢの１回当りの検索時間：ＲB0=4（ミリ秒） カラムＣの１回当りの検索時間：ＲC0=1（ミリ秒） カラムＤの１回当りの検索時間：ＲD0=2（ミリ秒） カラムＡの１回当りの更新時間：ＷA0=1（ミリ秒） カラムＢの１回当りの更新時間：ＷB0=1（ミリ秒） カラムＣの１回当りの更新時間：ＷC0=2（ミリ秒） カラムＤの１回当りの更新時間：ＷD0=2（ミリ秒） が求められる。
【００１９】上述した初期状態で図２に示したインデッ
クス自動付加を行うと、４つのカラムＡ，Ｂ，Ｃ，Ｄの
うち、総実行時間が上位半数に含まれる２つのカラムＡ
（符号＃，ＴＲＷA0=200）およびカラムＢ（符号＃
，ＴＲＷB0=150）に対して新たなインデックスの生成
・付加が行われるため、カラムＡおよびＢの１回当りの
検索時間は１／２倍、同じく１回当りの更新時間は２倍
となる。すなわち、インデックスの１回目の付加が行わ
れた各カラムの１回当りの検索時間と更新時間は、 カラムＡの１回当りの検索時間：ＲA1=2（ミリ秒） カラムＢの１回当りの検索時間：ＲB1=2（ミリ秒） カラムＣの１回当りの検索時間：ＲC1=1（ミリ秒） カラムＤの１回当りの検索時間：ＲD1=2（ミリ秒） カラムＡの１回当りの更新時間：ＷA1=2（ミリ秒） カラムＢの１回当りの更新時間：ＷB1=2（ミリ秒） カラムＣの１回当りの更新時間：ＷC1=2（ミリ秒） カラムＤの１回当りの更新時間：ＷD1=2（ミリ秒） となる。
クス自動付加を行うと、４つのカラムＡ，Ｂ，Ｃ，Ｄの
うち、総実行時間が上位半数に含まれる２つのカラムＡ
（符号＃，ＴＲＷA0=200）およびカラムＢ（符号＃
，ＴＲＷB0=150）に対して新たなインデックスの生成
・付加が行われるため、カラムＡおよびＢの１回当りの
検索時間は１／２倍、同じく１回当りの更新時間は２倍
となる。すなわち、インデックスの１回目の付加が行わ
れた各カラムの１回当りの検索時間と更新時間は、 カラムＡの１回当りの検索時間：ＲA1=2（ミリ秒） カラムＢの１回当りの検索時間：ＲB1=2（ミリ秒） カラムＣの１回当りの検索時間：ＲC1=1（ミリ秒） カラムＤの１回当りの検索時間：ＲD1=2（ミリ秒） カラムＡの１回当りの更新時間：ＷA1=2（ミリ秒） カラムＢの１回当りの更新時間：ＷB1=2（ミリ秒） カラムＣの１回当りの更新時間：ＷC1=2（ミリ秒） カラムＤの１回当りの更新時間：ＷD1=2（ミリ秒） となる。
【００２０】そこで、 カラムＡの総検索時間：ＴＲA1= 80（ミリ秒） カラムＢの総検索時間：ＴＲB1= 60（ミリ秒） カラムＣの総検索時間：ＴＲC1= 40（ミリ秒） カラムＤの総検索時間：ＴＲD1= 70（ミリ秒） カラムＡの総更新時間：ＴＷA1= 80（ミリ秒） カラムＢの総更新時間：ＴＷB1= 60（ミリ秒） カラムＣの総更新時間：ＴＷC1= 80（ミリ秒） カラムＤの総更新時間：ＴＷD1= 70（ミリ秒） カラムＡの総実行時間：ＴＲＷA1=160（ミリ秒） カラムＢの総実行時間：ＴＲＷB1=120（ミリ秒） カラムＣv総実行時間：ＴＲＷC1=120（ミリ秒） カラムＤの総実行時間：ＴＲＷD1=140（ミリ秒） とともに、これら総実行時間の累計値 540（ミリ秒）が
求められる。この値は前回の総実行時間の累計値 610
（ミリ秒）より小さいので、ＲＤＢに対する処理性能が
向上したものとみなされる。
求められる。この値は前回の総実行時間の累計値 610
（ミリ秒）より小さいので、ＲＤＢに対する処理性能が
向上したものとみなされる。
【００２１】したがって引き続き、４つのカラムＡ，
Ｂ，Ｃ，Ｄのうち、総実行時間が上位半数に含まれる２
つのカラムＡ（符号％，ＴＲＷA1=160）およびカラム
Ｄ（符号％，ＴＲＷD1=140）に対してさらに新たなイ
ンデックスの生成・付加が行われ、カラムＡおよびＤの
１回当りの検索時間は１／２倍、同じく１回当りの更新
時間は２倍となる。すなわち、インデックスの２回目の
付加が行われた各カラムの１回当りの検索時間と更新時
間は、 カラムＡの１回当りの検索時間：ＲA2=1（ミリ秒） カラムＢの１回当りの検索時間：ＲB2=2（ミリ秒） カラムＣの１回当りの検索時間：ＲC2=1（ミリ秒） カラムＤの１回当りの検索時間：ＲD2=1（ミリ秒） カラムＡの１回当りの更新時間：ＷA2=4（ミリ秒） カラムＢの１回当りの更新時間：ＷB2=2（ミリ秒） カラムＣの１回当りの更新時間：ＷC2=2（ミリ秒） カラムＤの１回当りの更新時間：ＷD2=4（ミリ秒） となる。
Ｂ，Ｃ，Ｄのうち、総実行時間が上位半数に含まれる２
つのカラムＡ（符号％，ＴＲＷA1=160）およびカラム
Ｄ（符号％，ＴＲＷD1=140）に対してさらに新たなイ
ンデックスの生成・付加が行われ、カラムＡおよびＤの
１回当りの検索時間は１／２倍、同じく１回当りの更新
時間は２倍となる。すなわち、インデックスの２回目の
付加が行われた各カラムの１回当りの検索時間と更新時
間は、 カラムＡの１回当りの検索時間：ＲA2=1（ミリ秒） カラムＢの１回当りの検索時間：ＲB2=2（ミリ秒） カラムＣの１回当りの検索時間：ＲC2=1（ミリ秒） カラムＤの１回当りの検索時間：ＲD2=1（ミリ秒） カラムＡの１回当りの更新時間：ＷA2=4（ミリ秒） カラムＢの１回当りの更新時間：ＷB2=2（ミリ秒） カラムＣの１回当りの更新時間：ＷC2=2（ミリ秒） カラムＤの１回当りの更新時間：ＷD2=4（ミリ秒） となる。
【００２２】そこで、 カラムＡの総検索時間：ＴＲA2= 40（ミリ秒） カラムＢの総検索時間：ＴＲB2= 60（ミリ秒） カラムＣの総検索時間：ＴＲC2= 40（ミリ秒） カラムＤの総検索時間：ＴＲD2= 35（ミリ秒） カラムＡの総更新時間：ＴＷA2=160（ミリ秒） カラムＢの総更新時間：ＴＷB2= 60（ミリ秒） カラムＣの総更新時間：ＴＷC2= 80（ミリ秒） カラムＤの総更新時間：ＴＷD2=140（ミリ秒） カラムＡの総実行時間：ＴＲＷA2=200（ミリ秒） カラムＢの総実行時間：ＴＲＷB2=120（ミリ秒） カラムＣの総実行時間：ＴＲＷC2=120（ミリ秒） カラムＤの総実行時間：ＴＲＷD2=175（ミリ秒） とともに、これら総実行時間の累計値 615（ミリ秒）が
求められる。この値は前回の総実行時間の累計値 540
（ミリ秒）より大きいので、ＲＤＢに対する処理性能が
低下したものとみなされる。そこで、総実行時間の合計
値を増大させる原因となったカラムＡおよびＤに対する
新たなインデックスの付加を取り消して、前回の状態に
戻す。以上により、検索効率と更新効率のバランスがと
れている最適化されたインデックスの付加が完了する。
求められる。この値は前回の総実行時間の累計値 540
（ミリ秒）より大きいので、ＲＤＢに対する処理性能が
低下したものとみなされる。そこで、総実行時間の合計
値を増大させる原因となったカラムＡおよびＤに対する
新たなインデックスの付加を取り消して、前回の状態に
戻す。以上により、検索効率と更新効率のバランスがと
れている最適化されたインデックスの付加が完了する。
【００２３】図４は、図１中のジャーナルに記録される
稼動情報の一例を示す図であり、業務プログラムからＳ
ＱＬコマンドが発行される都度、ジャーナルに取得す
る。稼動情報は、ＳＱＬコマンド発行年月日４０および
発行時刻４１、ＳＱＬコマンド実行時間４２、インデッ
クス付加回数４３、ＳＱＬコマンド内容４４から構成さ
れる。インデックス付加回数４３は、稼動情報をジャー
ナルに取得したときのインデックスの状態を識別するた
めの番号である。本実施形態においては、インデックス
が付加されていないとき“０”を設定し、新たにインデ
ックスの生成・付加を行う都度、“１”，“２”のよう
に増加させた値を設定する。これにより、例えば、現在
のインデックス付加回数４３が“５”である場合に前回
の稼動情報を求めるためには、インデックス付加回数４
３が“４”に設定された稼動情報をジャーナルから選択
すればよい。ＳＱＬコマンド内容４４は、発行したＳＱ
Ｌコマンドを識別するコマンド名称４５、処理対象のカ
ラム数４６、処理対象のカラム名称４７から構成され
る。そして、処理対象のカラム数４６が複数であれば、
それに対応したカラム数分に相当する複数個のカラム名
称４７，４８、……が設けられる。
稼動情報の一例を示す図であり、業務プログラムからＳ
ＱＬコマンドが発行される都度、ジャーナルに取得す
る。稼動情報は、ＳＱＬコマンド発行年月日４０および
発行時刻４１、ＳＱＬコマンド実行時間４２、インデッ
クス付加回数４３、ＳＱＬコマンド内容４４から構成さ
れる。インデックス付加回数４３は、稼動情報をジャー
ナルに取得したときのインデックスの状態を識別するた
めの番号である。本実施形態においては、インデックス
が付加されていないとき“０”を設定し、新たにインデ
ックスの生成・付加を行う都度、“１”，“２”のよう
に増加させた値を設定する。これにより、例えば、現在
のインデックス付加回数４３が“５”である場合に前回
の稼動情報を求めるためには、インデックス付加回数４
３が“４”に設定された稼動情報をジャーナルから選択
すればよい。ＳＱＬコマンド内容４４は、発行したＳＱ
Ｌコマンドを識別するコマンド名称４５、処理対象のカ
ラム数４６、処理対象のカラム名称４７から構成され
る。そして、処理対象のカラム数４６が複数であれば、
それに対応したカラム数分に相当する複数個のカラム名
称４７，４８、……が設けられる。
【００２４】図５は、図１中の集計・ソート部による稼
動情報の処理に使用される作業テーブルの一例を示す図
である。この作業テーブルはＳＱＬコマンドの内容別対
応に作成するものであり、ＳＱＬコマンド総実行時間５
０、前回のＳＱＬコマンド総実行時間５１、ＳＱＬコマ
ンド内容５２から構成される。上述した稼動情報と同様
に、ＳＱＬコマンド内容５２は、発行したＳＱＬコマン
ドを識別するコマンド名称５３、処理対象のカラム数５
４、処理対象のカラム名称５５から構成され、処理対象
のカラム数５４が複数であれば、それに対応したカラム
数分に相当する複数個のカラム名称５５，５６、……が
設けられる。ＳＱＬコマンド総実行時間５０は、ジャー
ナルに記録蓄積されている稼動情報のうち、同種のＳＱ
Ｌコマンドの稼動情報に含まれるＳＱＬコマンド実行時
間６３の合計値である。本実施形態においては、ジャー
ナルの稼動情報をすべて集計した後、総実行時間５０を
キーにソートすることにより、実行時間のより長いＳＱ
Ｌコマンドと新たなインデックスを付加すべきカラムを
求める。前回のＳＱＬコマンド総実行時間５１は、稼動
情報中の現在のインデックス付加回数６２から１を減算
した値に等しいインデックス付加回数６２が含まれてい
るすべての稼動情報について、そのＳＱＬ実行時間６３
を集計することによって求められる。
動情報の処理に使用される作業テーブルの一例を示す図
である。この作業テーブルはＳＱＬコマンドの内容別対
応に作成するものであり、ＳＱＬコマンド総実行時間５
０、前回のＳＱＬコマンド総実行時間５１、ＳＱＬコマ
ンド内容５２から構成される。上述した稼動情報と同様
に、ＳＱＬコマンド内容５２は、発行したＳＱＬコマン
ドを識別するコマンド名称５３、処理対象のカラム数５
４、処理対象のカラム名称５５から構成され、処理対象
のカラム数５４が複数であれば、それに対応したカラム
数分に相当する複数個のカラム名称５５，５６、……が
設けられる。ＳＱＬコマンド総実行時間５０は、ジャー
ナルに記録蓄積されている稼動情報のうち、同種のＳＱ
Ｌコマンドの稼動情報に含まれるＳＱＬコマンド実行時
間６３の合計値である。本実施形態においては、ジャー
ナルの稼動情報をすべて集計した後、総実行時間５０を
キーにソートすることにより、実行時間のより長いＳＱ
Ｌコマンドと新たなインデックスを付加すべきカラムを
求める。前回のＳＱＬコマンド総実行時間５１は、稼動
情報中の現在のインデックス付加回数６２から１を減算
した値に等しいインデックス付加回数６２が含まれてい
るすべての稼動情報について、そのＳＱＬ実行時間６３
を集計することによって求められる。
【００２５】本実施形態によれば、システム管理者の個
人的技量やシステムの運用形態などに関わらず、指定し
た試行条件下における検索効率および更新効率のバラン
スがとれた最適なインデックスを自動的に作成・付加し
て、ＲＤＢの運用効率を総合的に向上させることができ
る。そして、該当するＲＤＢに対して何らかの処理を行
うあらゆるＳＱＬコマンドについて検索効率および更新
効率の測定が可能なため、これまでシステム管理者が手
作業で行ってきたときのようなインデックスの作成漏れ
が生じるおそれがなくなり、システムの本番運用当日か
ら最適な運用状態を実現させることができる。また、定
期的あるいは運用に何らかの変化があったときインデッ
クスの最適化を行うようにすれば、常に最適なシステム
の運用状態を保持することができる。
人的技量やシステムの運用形態などに関わらず、指定し
た試行条件下における検索効率および更新効率のバラン
スがとれた最適なインデックスを自動的に作成・付加し
て、ＲＤＢの運用効率を総合的に向上させることができ
る。そして、該当するＲＤＢに対して何らかの処理を行
うあらゆるＳＱＬコマンドについて検索効率および更新
効率の測定が可能なため、これまでシステム管理者が手
作業で行ってきたときのようなインデックスの作成漏れ
が生じるおそれがなくなり、システムの本番運用当日か
ら最適な運用状態を実現させることができる。また、定
期的あるいは運用に何らかの変化があったときインデッ
クスの最適化を行うようにすれば、常に最適なシステム
の運用状態を保持することができる。
【００２６】
【発明の効果】以上詳しく説明したように、本発明のＲ
ＤＢのインデックス最適化システムによれば、システム
管理者の個人的技量やシステムの運用形態などに関わら
ず、指定した試行条件下における検索効率および更新効
率のバランスがとれた最適なインデックスを自動的に作
成・付加して、ＲＤＢの運用効率を総合的に向上させる
ことができる。
ＤＢのインデックス最適化システムによれば、システム
管理者の個人的技量やシステムの運用形態などに関わら
ず、指定した試行条件下における検索効率および更新効
率のバランスがとれた最適なインデックスを自動的に作
成・付加して、ＲＤＢの運用効率を総合的に向上させる
ことができる。
【図１】本発明のリレーショナルデータベースのインデ
ックス自動付加システムの一実施形態を適用したシステ
ム構成例を示すブロック図である。
ックス自動付加システムの一実施形態を適用したシステ
ム構成例を示すブロック図である。
【図２】図１のシステムによるインデックス自動付加の
全体的な手順の一例を示すフローチャートである。
全体的な手順の一例を示すフローチャートである。
【図３】図２のインデックス自動付加の処理前後におけ
る各種性能値の一具体例を示す図である。
る各種性能値の一具体例を示す図である。
【図４】図１中のジャーナルに記録される稼動情報の一
例を示す図である。
例を示す図である。
【図５】図１中の集計・ソート部による稼動情報の処理
に使用される作業テーブルの一例を示す図である。
に使用される作業テーブルの一例を示す図である。
２２ ＳＱＬ解析・実行処理部 ２３ 稼動情報取得処理部 ２４ ジャーナル ２６ 集計・ソート部 ２７ インデックス制御部
Claims (1)
- 【請求項１】 リレーショナルデータベースに対し、そ
の処理効率を最適化させるインデックスの生成・付加を
行うリレーショナルデータベースのインデックス自動付
加システムにおいて、 業務プログラムが発行するリレーショナルデータベース
処理操作用のＳＱＬコマンドを解析し、前記リレーショ
ナルデータベースを対象とする検索処理および更新処理
の実行制御を行うＳＱＬ解析・実行処理部と、 発行されたすべての前記ＳＱＬコマンドについて、前記
検索処理の実行に要した検索時間および前記更新処理の
実行に要した更新時間の記録処理を行うデータベース処
理情報記録部と、 処理内容が一致する同種のＳＱＬコマンドの各々につい
て、前記データベース処理情報記録部に記録されている
前記検索時間および前記更新時間を集計した総実行時間
を求め、前記総実行時間をキーに前記同種のＳＱＬコマ
ンドの順序付けを行う集計・ソート部と、 前記集計・ソート部の順序付けにしたがって前記総実行
時間が上位半数に含まれるＳＱＬコマンドを選択し、そ
のＳＱＬコマンドに該当する前記検索処理に要する前記
検索時間を短縮させるインデックスの生成・付加を行う
インデックス制御部と、を具備し、 所定の試行条件下での前記ＳＱＬ解析・実行処理部によ
る前記実行制御および前記データベース処理情報記録部
による前記記録処理と、前記集計・ソート部および前記
インデックス制御部の処理とを、前記同種のＳＱＬコマ
ンドごとに求められた前記総実行時間すべての累計値が
最小となるまで繰り返すことを特徴とするリレーショナ
ルデータベースのインデックス自動付加システム。
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) | リレーショナル・データベースにおけるキーワード管理方式 |