(57)【要約】【課題】データベースに対し最適なインデックスを付与するのは容易でない。【解決手段】情報処理システムの第１サーバ１２の通常運用において、プログラム実行部２６はデータベース１６に対しデータ処理を行う。インデックス最適化部２０の監査ログ分析部２８はデータベース１６の監査ログを取得し、各ＳＱＬを処理パターンにまとめる。インデックス候補決定部３０は、効率化対象の処理パターンに対し取得したインデックス修正案を簡易評価してインデックス候補を決定する。評価部３２は監査ログに記録された処理をサンプリングしてシミュレーションを行うことにより、インデックス候補を適用した場合の実行コストの改善量を見積もる。インデックス選定部３４は改善量と選定ポリシーとに基づき最適なインデックスを選定する。適用部３６は所定の手続きを経て選定したインデックスを実運用に適用する。【選択図】図２
2009245351.tif 000002
【特許請求の範囲】
【請求項１】
データベースを用いて所定のデータ処理を行う情報処理システムであって、
データ処理中に記録されたデータベースの処理履歴に含まれる処理のいずれかを効率化するためのインデックス候補を決定するインデックス候補決定部と、
前記インデックス候補決定部が決定したインデックス候補を適用した場合の処理時間の変化量を、前記処理履歴に含まれる処理からサンプリングしシミュレーションを行うことにより予測する評価部と、
前記評価部が予測した処理時間の変化量に基づき、最適なインデックス候補を選定するインデックス選定部と、
前記インデックス選定部が選定したインデックス候補を実際のデータ処理時のインデックスに適用する適用部と、
を備えたことを特徴とする情報処理システム。
【請求項２】
前記処理履歴に含まれる各処理における処理対象の行を特定する条件に基づき、各処理を処理パターンに分類するログ分析部をさらに備え、
前記インデックス候補決定部は、実際になされた処理の頻度が所定のしきい値を超える処理パターンを抽出し、当該処理パターンに属する処理を効率化対象の処理とすることを特徴とする請求項１に記載の情報処理システム。
【請求項３】
前記インデックス候補決定部は、前記処理履歴に含まれる処理のうち処理パターンごとに抽出した処理を、前記効率化対象の処理に対し取得したインデックス修正案および元のインデックスで実行し、実行コストを表す所定のパラメータの改善量に基づき、前記修正案を前記インデックス候補とするか否かを決定することを特徴とする請求項２に記載の情報処理システム。
【請求項４】
前記実行コストを表すパラメータは、ＣＰＵ時間、各処理要求から終了までの経過時間、データ読み出し量の少なくともいずれかを含むことを特徴とする請求項３に記載の情報処理システム。
【請求項５】
前記インデックス候補決定部は、前記所定のパラメータの改善量と、各パラメータに対しあらかじめ設定された優先順位とを照合し、両者の適合度合に応じて前記インデックス候補を決定することを特徴とすることを特徴とする請求項３または４に記載の情報処理システム。
【請求項６】
前記評価部は、前記処理履歴において所定の処理が繰り返されている場合、当該所定の処理を所定の割合で抽出して実行することにより処理時間の変化量を実測し、当該変化量に実際の繰り返し回数を積算することにより実際の処理時間の変化量を予測することを特徴とする請求項１から５のいずれかに記載の情報処理システム。
【請求項７】
前記評価部は、一のテーブルを構成するデータのうち、前記処理履歴に含まれる処理によって更新されたデータの割合が所定のしきい値を超える場合、前記処理履歴に含まれる、データを更新する処理を全てサンプリングに含めることを特徴とする請求項１から５のいずれかに記載の情報処理システム。
【請求項８】
前記評価部は前記シミュレーションにより、前記インデックス候補を適用した場合の実行コストを表す所定のパラメータの変化量をさらに予測し、
前記インデックス選定部は、前記処理時間の変化量に加え前記評価部が取得した前記パラメータの変化量に基づき、最適なインデックス候補を選定することを特徴とする請求項１に記載の情報処理システム。
【請求項９】
前記評価部は、前記シミュレーションに用いるシミュレーション用ハードウェアと、実際のデータ処理において用いる通常運用用ハードウェアとで所定の処理を実行して所定のパラメータを取得し、当該パラメータの差異に応じて、前記処理時間の変化量の予測値を補正することを特徴とする請求項１に記載の情報処理システム。
【請求項１０】
データベースを用いて所定のデータ処理を行う情報処理システムが行う情報処理方法であって、
データ処理中に記録されたデータベースの処理履歴をメモリより読み出し、当該処理履歴に含まれる処理のいずれかを効率化するためのインデックス候補を決定するステップと、
前記インデックス候補を適用した場合の処理時間の変化量を、前記処理履歴に含まれる処理からサンプリングしシミュレーションを行うことにより予測するステップと、
予測した前記処理時間の変化量に基づき、最適なインデックス候補を選定するステップと、
選定したインデックス候補を実際のデータ処理時のインデックスに適用するステップと、
を含むことを特徴とする情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は情報処理技術に関し、特にプログラムを実行してデータベースを操作する情報処理システムおよび当該システムに適用できる情報処理方法に関する。
【背景技術】
【０００２】
近年の情報処理技術の発展およびネットワーク環境の充実化に伴い、様々な情報がネットワークを行き来し、企業、社内の部門など、端末に入力された個々のデータを統括管理する組織には、入力された膨大なデータを厳密に管理する技術が必要不可欠となっている。そのような膨大なデータを効率的かつ厳密に管理するため、データベースに係る技術が発展してきた。
【０００３】
例えばデータベースを管理するＤＢＭＳ（Data Base Management System）を専用のソフトウェアとして確立することにより、データベースへのアクセス処理を本体のアプリケーションプログラムから切り離し、効率の良い処理を行うことができる。ＤＢＭＳでは通常、管理対象のデータベースにインデックスを付与することが可能となっている。インデックスは例えば、データによって構成されるマトリクスのうち、所定のカラムに対して付与され、当該カラムに含まれる値と行とを対応づけたものであり、これによりアクセス対象の行を効率的に検出することが可能となる（例えば特許文献１参照）。
【０００４】
インデックスをどのカラムに付与するか、また、カラムごとにインデックスを付与するか、複数のカラムのデータセットによる複合条件で検索する複合インデックスとするか、といった判断は、データベースへのアクセス効率に大きく影響を与える。例えばインデックスが多くのカラムに対して付与されるほど、データ参照の際の実行コストは減少するが、データの追加や更新時には、インデックス自体を更新するための実行コストが増加する。また一のカラムがほとんど同じ値で占められる場合など、インデックスの効果がほとんどない場合もある。
【特許文献１】特開２００７−２５７３５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
このようにインデックスを最適化することは重要な問題であるが、上記のような様々な条件を考慮して最適化を行うのは容易でない。例えば通常運用に用いられるデータベースと同様の環境を開発機に構築したり、インデックス候補のテストや検証を行ったり、と複雑な作業を行う必要がある。また複数のプログラムをバッチ処理するシステムなどでは、一のプログラムについて最適化を行ったとしても、他のプログラムへの影響を考慮することが難しい。これらのことを総合的に判断して最適なインデックスを付与するには、インデックスや各プログラムに精通する相応のスキルを有する担当者が必要であり、人件費や時間的コストが増大していた。
【０００６】
本発明はこうした状況に鑑みてなされたものであり、その目的は、効率的にインデックスを最適化することのできる技術を提供することにある。
【課題を解決するための手段】
【０００７】
本発明のある態様は、情報処理システムに関する。この情報処理システムは、データベースを用いて所定のデータ処理を行う情報処理システムであって、データ処理中に記録されたデータベースの処理履歴に含まれる処理のいずれかを効率化するためのインデックス候補を決定するインデックス候補決定部と、インデックス候補決定部が決定したインデックス候補を適用した場合の処理時間の変化量を、処理履歴に含まれる処理からサンプリングしシミュレーションを行うことにより予測する評価部と、評価部が予測した処理時間の変化量に基づき、最適なインデックス候補を選定するインデックス選定部と、インデックス選定部が選定したインデックス候補を実際のデータ処理時のインデックスに適用する適用部と、を備えたことを特徴とする。
【０００８】
本発明の別の態様は、情報処理方法に関する。この情報処理方法は、データベースを用いて所定のデータ処理を行う情報処理システムが行う情報処理方法であって、データ処理中に記録されたデータベースの処理履歴をメモリより読み出し、当該処理履歴に含まれる処理のいずれかを効率化するためのインデックス候補を決定するステップと、インデックス候補を適用した場合の処理時間の変化量を、処理履歴に含まれる処理からサンプリングしシミュレーションを行うことにより予測するステップと、予測した処理時間の変化量に基づき、最適なインデックス候補を選定するステップと、選定したインデックス候補を実際のデータ処理時のインデックスに適用するステップと、を含むことを特徴とする。
【０００９】
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システムなどの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１０】
本発明によれば、データベースに付与するインデックスを容易に最適化することができる。
【発明を実施するための最良の形態】
【００１１】
図１は本実施の形態を適用できるシステムの構成例を示している。同図において情報処理システム１０は第１サーバ１２、第２サーバ１４の２つのサーバを含む。また第１サーバ１２はデータベース１６に接続している。第１サーバ１２や第２サーバ１４で実行されるプログラムによって、データベース１６内のデータが参照されたり更新され、データの保存や管理がなされる。なお、サーバやデータベースの数、データベースの接続先は図１に示したものに限らず、プログラムを処理できるシステムであればいかなる構成においても本実施の形態を適用できる。また各サーバにさらにクライアント端末などが接続していてもよい。
【００１２】
第１サーバ１２および第２サーバ１４はそれぞれ、一以上のＣＰＵとメモリ、記憶装置、入出力装置、表示装置など、あるいはそのいずれかの組み合わせを備えた一般的な情報処理装置であればよく、パーソナルコンピュータ、汎用大型コンピュータなどその規模は限定されない。また第１サーバ１２、第２サーバ１４はネットワーク１８に接続され、互いにデータを送受することができる。データベースへのアクセスは、第１サーバ１２から直接行ってもよいし、第２サーバ１４からネットワーク１８を介して行ってもよい。どのような形態でデータベースへアクセスを行い、どのような処理を行うかはプログラムに依存するところであり、一般的な情報処理で実施されているいかなる形態も適用範囲である。
【００１３】
なお情報処理システム１０は、各種機能やサービスをユーザに提供する本番機でよい。すなわち情報処理システム１０は、ネットワーク１８を介してアクセスを行った端末（図示せず）などにサービスを提供したり、各支店から計上されるデータを当該支店の端末から取得してデータベース１６を更新したり、その他、一般的に実現されているいかなる機能を発揮してもよい。以後、このような処理を「通常運用」と呼ぶ。本実施の形態ではデータベース１６のインデックスの最適化を以下に述べるように情報処理システム１０が自律的に行う。これにより、データベース１６や情報処理システム１０の構成や実行するプログラムなどの環境を開発機で再構築させることなく、かつ安全に最適化を行うことができる。ただし本実施の形態をそれに限る趣旨ではなく、情報処理システム１０を開発機としてもよい。
【００１４】
図２は第１サーバ１２の構成をより詳細に示している。第２サーバ１４も同様の構成としてよい。第１サーバ１２は、データベース１６のインデックスを最適化するインデックス最適化部２０、データベース１６のインデックスや第１サーバ１２内での処理に必要な情報を記憶する情報記憶部２２、通常運用時にプログラムを実行するプログラム実行部２６を含む。
【００１５】
図２において、様々な処理を行う機能ブロックとして記載される各要素は、ハードウェア的には、ＣＰＵ、メモリ、その他のＬＳＩで構成することができ、ソフトウェア的には、演算やファイル操作、データベースへのアクセスを行うプログラムなどによって実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。
【００１６】
プログラム実行部２６は、情報記憶部２２に記憶されたプログラムを実行する。例えば情報処理システム１０が、ユーザが登録した複数のジョブをバッチ処理するシステムであった場合は、登録された処理内容で登録された順にジョブを実行する。このためプログラム実行部２６はユーザの登録に用いる入力装置、各種演算を行うＣＰＵ、必要な情報を出力する出力装置などを含んでよいが、一般的な情報処理装置における構成と同様とすることができるため個々の図示は省略する。ただし本実施の形態におけるプログラム実行部２６が実行するプログラムには、データベース１６のデータを操作するプログラムが含まれているとする。
【００１７】
インデックス最適化部２０は、データベース１６の監査ログを分析し、通常運用時のデータベース１６へのアクセスに係る処理内容を分析する監査ログ分析部２８、処理内容ごとに取得したインデックス修正案の簡易評価を行いインデックス候補を決定するインデックス候補決定部３０、シミュレーションによりインデックス候補の評価を行う評価部３２、評価結果と最適化のポリシーに則り最適なインデックスを選定するインデックス選定部３４、選定されたインデックスを通常運用の環境に適用する適用部３６、インデックス修正案の簡易評価やシミュレーションに用いる仮想データベース３８を含む。
【００１８】
監査ログ分析部２８は、通常運用時にプログラム実行部２６がプログラムを実行し、データベース１６に対してアクセスを行った際に記録される監査ログを取得する。監査ログは一般的なデータベースの機能によって記録され、データに対する処理内容を表すＳＱＬ(Structured Query Language）を含んでいる。監査ログ分析部２８はさらに、得られた監査ログから必要な情報を抽出してログテーブルを作成したうえ、それを分類して処理内容テーブルを作成する。以後の説明ではバッチ処理を行うシステムにおいて一回のバッチ処理において発行されたＳＱＬを処理の対象の単位とするが、その単位は処理時間などを評価できる処理群であればよく、単一のプログラムで発行されるＳＱＬなどでもよい。
【００１９】
ログテーブルは監査ログのＳＱＬ文ごとに、各データ処理を行った日時、追加・更新・抽出といった処理区分、処理対象となったテーブルとカラム、処理対象となる行を特定するための条件、ＳＱＬを発行したプログラムなどの情報を表したテーブルである。処理内容テーブルはログテーブルに含まれる各ＳＱＬのうち、個々のデータを除いて処理対象となる行を特定するための条件が同様であるＳＱＬをまとめて得られた処理内容のパターンごとに、処理内容、処理対象となったテーブルとカラム、処理対象となる行を特定するための条件、発生頻度、発行元のプログラムなどの情報を記載したテーブルである。各テーブルの具体例は後に述べる。
【００２０】
なお、ＳＱＬの処理時間に大きな差がある場合は、処理時間の範囲によってＳＱＬを分類した後に処理内容のパターンをまとめる。同じ処理パターンでも処理時間の異なるＳＱＬはデータ自体のばらつき（カーディナリティ）が異なるテーブルを対象としていることが考えられる。カーディナリティによって最適なインデックスも異なることから、データのカーディナリティを処理時間で推測して処理パターンを区別することにより、インデックスの最適化を正確に行う。そのために、個々のデータを除いて処理対象となる行を特定するための条件が同様であるＳＱＬの処理時間を統計分析し、標準偏差があらかじめ設定した値を超えていた場合に、処理時間を所定の規則で区切りＳＱＬを分類するようにしてもよい。
【００２１】
なお、本実施の形態ではデータベースを操作する命令としてＳＱＬ文の一例を示しているが、同様の操作を行うためのプログラムであればその言語は限定されない。またデータベースの形式として、各項目は各「カラム」に対応し、各「行」に複数の項目のデータが羅列している、という設定で説明を行うが、「カラム」と「行」の関係を限定するものではない。
【００２２】
インデックス候補決定部３０は、処理内容テーブルに記載された処理内容のパターンに対するインデックスの修正案を取得し、簡易的な評価を行うことにより修正案の絞り込みを行う。具体的には、発生頻度の高い処理内容のパターンを効率化対象の処理として抽出し、当該パターンに属する具体的なＳＱＬをログテーブルより選択する。そして当該ＳＱＬに対するインデックス修正案を取得する。次いで当該修正案適用前後の実行コストを、各処理パターンのＳＱＬを例えば１つずつ実行することにより比較する。ＳＱＬとデータからインデックスの修正案を作成する技術は既存のものを適用できる。比較する実行コストとして、処理コスト、レスポンス、ディスク負荷といった指標を用意し、それらの指標を表す数値をＳＱＬの実行中に取得する。
【００２３】
単一のＳＱＬについての処理コストを表す数値として、例えばＣＰＵを占有して動作させている時間の総計であるＣＰＵ時間を取得する。レスポンスを表す数値として、例えばＳＱＬ発行から終了までの経過時間を取得する。ディスク負荷を表す数値として、例えばバッファ取得数、データブロック取得数などのデータ読み出し量を取得する。これらの数値はＤＢＭＳが提供する機能を利用して取得できる。ただし実行コストの指標やそれを表す数値はここに挙げたものに限定されず、システムの処理内容や性能、データベースの内容などに鑑み適宜設定する。各指標にはユーザなどによりあらかじめ優先順位を設定しておいてもよい。そして優先順位とそれらの指標の改善量とを照合した場合の適合度合いなどを総合的に判断し、より効果が高いと予測できる修正案をインデックス候補として決定する。決定したインデックス候補は情報記憶部２２に格納する。
【００２４】
評価部３２は、元のインデックスを用いた場合と、インデックス候補を適用した場合とで、通常運用時の状況により近い状況でＳＱＬを実行し、通常運用時のバッチ処理などの総処理時間の短縮量を見積もる。具体的には、通常運用時に発行されたＳＱＬから所定の割合でサンプリングを行い同じ順序で実行して処理時間または短縮量を実測し、通常運用時の総処理時間または短縮量に換算する。サンプリングの詳細は後に述べるが、例えばある処理単位で所定のＳＱＬが発行され、その処理単位が繰り返し実行されるようなシステムにおいては、当該処理単位の所定割合分に発行されるＳＱＬのみを実行し処理時間の短縮量を取得する。
【００２５】
ただし、ＳＱＬの処理時間に大きな差がある場合は、カーディナリティの異なるデータを対象とするＳＱＬであることが考えられるため、上述のように処理時間の範囲によってＳＱＬを分類し、サンプリングは分類後のＳＱＬの中から所定割合を抽出することにより行う。そして通常運用時に繰り返された回数を積算すると、通常運用時の総処理時間に対する短縮量が算出できる。あるいは１００％のサンプリングで、通常運用時と同じ処理を行ってもよい。
【００２６】
情報処理システム１０が、複数のプログラムを並列にバッチ処理するシステムであった場合などは、バッファ容量の制限などに起因し、並列に処理されるＳＱＬの数が多いほど処理速度が減少する傾向を有する。そのため、効率化対象の処理と並列に処理された実績のあるＳＱＬをシミュレーションにおいても並列に処理することにより処理時間予測の精度を上げる。評価部３２はこの並列実行によるシミュレーションを効率的に行うため、並列に処理されるＳＱＬの組み合わせを実際の発生頻度に対応する割合でログテーブルから抽出することによりサンプリングを行ってもよい。
【００２７】
また、評価部３２がシミュレーションのために用いることのできるＣＰＵの処理速度やメモリ容量、ハードディスク容量などのハードウェア性能が、プログラム実行部２６が通常運用で用いるハードウェア性能と異なる場合を考慮し、並列に処理するＳＱＬの数を調整したうえでシミュレーションを行ってもよい。さらに、ハードウェア性能の差を厳密に計測し、予測する処理時間を補正するようにしてもよい。具体的な手法は後に述べる。
【００２８】
仮想データベース３８は、インデックス候補決定部３０が行うインデックス修正案の簡易的な評価や、評価部３２が行うシミュレーションにおいて、データベース１６の代わりに処理対象となる。正確な評価のためには、仮想データベース３８はデータベース１６と同様のデータを保持していることが望ましい。そのため評価の前段階としてデータベース１６の内容を仮想データベース３８に反映させる。そして仮想データベース３８のその時点でのチェックポイントを取得してから評価を行う。
【００２９】
ある評価が終了したら、取得しておいたチェックポイントまで仮想データベース３８をロールバックすることにより評価前の状態へ戻す。これによりインデックス修正案やインデックス候補の適用前後で仮想データベース３８を同じ初期状態として評価を行うことができる。仮想データベース３８の容量がデータベース１６より小さく全てのデータを保持することができない場合は、データベース１６におけるデータのカーディナリティを考慮したうえでデータを抽出し、仮想データベース３８へ格納するようにしてもよい。
【００３０】
インデックス選定部３４は、評価部３２が行ったシミュレーションの結果に基づき、最終的に適用するインデックスを選定する。この際、あらかじめユーザなどにより設定された選定ポリシーを参照し、当該ポリシーに則った選定を行ってもよい。選定ポリシーとは、実行コストの指標や、プログラムと実行コストの指標との組み合わせに対し優先順位を設定したものである。
【００３１】
適用部３６は、情報記憶部２２の通常運用で参照されるインデックスを選定されたインデックスで更新することにより、通常運用への適用処理を行う。適用部３６はユーザなどの設定によっては、図示しない出力装置へシミュレーションの結果などを出力し、選定されたインデックスの適用を行うかについての最終判断をユーザに求めるようにしてもよい。あるいは実行コストを改善することのできるインデックスが存在することを出力装置に出力するのみで、適用処理はユーザが行うようにしてもよい。
【００３２】
情報記憶部２２は、プログラム実行部２６などで実行されるプログラム、監査ログ、インデックスを記憶するほか、監査ログ分析部２８が作成したログテーブル、処理内容テーブル、インデックス候補決定部３０が決定したインデックス候補、ユーザなどが設定する選定ポリシーなどを記憶する。
【００３３】
次にこれまで説明した構成による、第１サーバ１２の動作について説明する。図３はインデックスを最適化する処理手順を示すフローチャートである。前提として情報処理システム１０は、プログラム実行部２６によりデータベース１６のデータ操作を含むシステムの運用処理を行っているとする。あるいは情報処理システム１０を開発機として、各種テストを行っているとする。いずれの場合においても、データベースの監査機能を利用して、情報記憶部２２などの記憶装置に監査ログが記録されているとする。
【００３４】
そのような状況において、まずユーザがインデックスの最適化を開始したい旨の入力を第１サーバ１２の図示しない入力装置より入力すると、インデックス最適化部２０の監査ログ分析部２８は、記録された監査ログを分析し必要な情報を抽出することにより、ログテーブルを作成し、次いで処理内容テーブルを作成する（１０）。次にインデックス候補決定部３０は、所定のしきい値を超える頻度で、または所定のしきい値を超える性能劣化が発生している処理内容のパターンを抽出し、さらに当該パターンに属する具体的なＳＱＬのいずれかを効率化対象のＳＱＬとしてログテーブルより抽出する（Ｓ１２）。次いでインデックス候補決定部３０は、既存の技術などを利用して当該ＳＱＬに対するインデックスの修正案を取得し（Ｓ１４）、元のインデックスと当該修正案を適用した場合とで各処理パターンから抽出したＳＱＬを実行することにより実行コストを算出する（Ｓ１６）。
【００３５】
次いでインデックス候補決定部３０は実行コストを総合的に評価してインデックス修正案の中からインデックス候補を決定する（Ｓ１８）。すると評価部３２は、並列に実行されるＳＱＬの組み合わせや同じＳＱＬの繰り返し、通常運用時とのハードウェア性能の差などを考慮したうえでシミュレーションを行い、インデックス候補を適用した場合の総処理時間の短縮量などを予測する（Ｓ２０）。インデックス選定部３４はシミュレーション結果と選定ポリシーとの適合度合いなどに基づきインデックス候補の中から最終的なインデックスを選定し（Ｓ２２）、適用部３６が通常運用への適用を行う（Ｓ２４）。
【００３６】
次に具体的なデータ例に沿って上述の処理手順を説明する。図４はデータベース１６におけるデータの具体例を示している。データテーブル５０は例えば自動車保険の顧客データであり、顧客の名前欄５０ａ、生年月日欄５０ｂ、車の型番欄５０ｃ、見積もり依頼日欄５０ｄ、および見積もり金額欄５０ｅの５つのカラムを含む。それぞれの欄には、顧客の名前、生年月日、保有する車の型番、保険見積もりを依頼した日、保険の見積もり金額が記載されている。
【００３７】
データ操作において各カラムは、カラムの識別情報で識別される。同図の例では、名前欄５０ａのカラムを「a-label」、生年月日欄５０ｂのカラムを「b-label」、車の型番欄５０ｃのカラムを「c-label」、見積もり依頼日欄５０ｄのカラムを「d-label」、見積もり金額欄５０ｅのカラムを「e-label」なる名称で識別する。またデータテーブル５０は情報処理システム１０では「aaa-table」なる名称で他のテーブルと区別するとする。
【００３８】
このような構造のデータに対しプログラム実行部２６がデータ操作を行う都度、ＤＢＭＳが提供する機能により監査ログが記録される。図５は監査ログのデータ構造例を示している。監査ログ５２は日付欄５２ａ、時刻欄５２ｂ、ＳＱＬ文欄５２ｃ、対象プログラム欄５２ｄといったフィールドを含むデータ構造を有する。日付欄５２ａおよび時刻欄５２ｂにはデータ操作が行われた日付と時刻が記録される。ＳＱＬ文欄５２ｃには具体的な操作内容であるＳＱＬが、対象プログラム欄５２ｄには操作元のプログラム名が記録される。
【００３９】
例えば同図１行目では、「20070801」（２００７年８月１日）の「12:00:00」（１２時００分００秒）に「insert into aaa-table(a-label, b-label, c-label, d-label) values('山田  太郎', '1977/1/1', 'RA11', '2007/8/1')」なる操作を「見積もり依頼登録」プログラムにより行っていることが記録されている。このＳＱＬ文は、「aaa-table」なるデータテーブルに、カラム「a-label」、「b-label」、「c-label」、「d-label」の値がそれぞれ、「山田  太郎」、「1977/1/1」、「RA11」、「2007/8/1」である行を追加する、という操作である。これは図５のデータテーブル５０における２行目のデータのうち、カラム「e-label」以外のデータを追加した操作にあたる。例えば保険料の見積もり依頼を受け付け、データベース１６に登録する時点にそのような操作を行う。
【００４０】
２行目では、「20070801」（２００７年８月１日）の「22:00:00」（２２時００分００秒）に「update aaa-table set e-labe=2400 where a-label='山田  太郎' and b-label='1977/1/1'」なる操作を「見積もり」プログラムにより行っている。このＳＱＬ文は、「aaa-table」なるデータテーブルのうち、「a-label」および「b-label」がそれぞれ「山田  太郎」および「1977/1/1」である行の、カラム「e-label」を「2400」なる値で更新する、という操作である。これは図５のデータテーブル５０における２行目のデータのうち、カラム「e-label」に値を代入した操作にあたる。例えばある顧客の保険料の見積もり金額を算出し、登録する場合にそのような操作を行う。
【００４１】
３行目では「20070801」（２００７年８月１日）の「22:30:00」（２２時３０分００秒）に「select a-label, b-label from aaa-table where d-label='2007/8/1' and e-label='2400'」なる操作を「見積もり印刷」プログラムにより行っている。このＳＱＬ文は、「aaa-table」なるデータテーブルのうち、「d-label」および「e-label」がそれぞれ「2007/8/1」および「2400」である行の、カラム「a-label」、「b-label」の値を抽出する、という操作である。例えばある条件に属する顧客の登録情報を確認したり比較したりする場合にそのような操作を行う。４行目、５行目は３行目と同様であるが、「d-label」または「e-label」に対する条件が３行目と異なっている。
【００４２】
図６は、図５の監査ログ５２に基づき監査ログ分析部２８が生成するログテーブルの例を示している。ログテーブル５４は、日付欄５４ａ、時刻欄５４ｂ、処理区分欄５４ｃ、対象テーブル欄５４ｄ、対象カラム欄５４ｅ、条件欄５４ｆ、ＳＱＬ文欄５４ｇ、対象プログラム欄５４ｈを含む。ログテーブル５４の各行は、監査ログ５２の各行、すなわち各データ操作に対応している。なお、ログテーブル５４は監査ログ５２以外の情報に基づき作成してもよい。例えば、アプリケーションとＤＢＭＳ間の通信電文を解析するなど、ＳＱＬの発行内容が特定できれば情報の取得先は限定されない。
【００４３】
日付欄５４ａおよび時刻欄５４ｂにはデータ操作を行った日付と時刻が記録される。このデータは監査ログ５２の日付欄５２ａおよび時刻欄５２ｂのデータに対応する。処理区分欄５４ｃには、処理の区分、すなわち「insert」（追加）か「select」（抽出）か「update」（更新）か、が記録される。対象テーブル欄５４ｄには、データ操作を行う対象であるテーブルの名称が、対象カラム欄５４ｅには、操作を行う対象であるカラムの名称が記録される。条件欄５４ｆには、操作対象の行を特定できる条件が記録される。例えば処理区分が「insert」の場合は各カラムに追加されたデータそのものにより操作対象の行が特定できる。処理区分が「select」および「update」の場合は処理対象の行を指定している条件で行が特定できる。
【００４４】
処理区分欄５４ｃ、対象テーブル欄５４ｄ、対象カラム欄５４ｅ、条件欄５４ｆのデータは、対応するＳＱＬ文から簡単なパターン解析によって抽出できる。「ＳＱＬ文欄５４ｇにはＳＱＬ文の原文がそのまま記録されるが同図では省略している。対象プログラム欄５４ｈには操作元のプログラム名が記録される。このデータは監査ログ５２の対象プログラム欄５２ｄのデータに対応する。副問い合わせを行うなど複雑なＳＱＬの場合でも、条件欄５４ｆには副問い合わせの部分を記録する。これにより、複雑なＳＱＬでも後続の処理の対象とすることができる。
【００４５】
なお図５に示したように、通常は監査ログから操作元のプログラムが特定できるが、監査ログにそのような情報が含まれていない場合でも、オンラインの稼働ログの開始・終了時刻に基づきジョブログを参照することなどから操作元のプログラムを割り出すことができる。開始・終了時刻が重なる場合は、端末識別子などからプログラムの切り分けを行うこともできる。さらに、各プログラムを既知の順序で実際に実行してみて、記録された監査ログからＳＱＬ文とプログラムとの関連づけを行ってもよいし、開発機での実験時に得られたジョブログとオンラインの稼働ログに基づき関連づけてもよい。解析したデータ量に応じて、より正確な関連づけを行うことができる。
【００４６】
図７は、図６のログテーブルに基づき監査ログ分析部２８が作成する処理内容テーブルの例を示している。処理内容テーブル５６は、処理区分欄５６ａ、対象テーブル欄５６ｂ、対象カラム欄５６ｃ、条件欄５６ｄ、対応ＳＱＬ欄５６ｅ、対象プログラム欄５６ｆ、発生頻度欄５６ｇを含む。処理内容テーブル５６は、ログテーブル５４に含まれるＳＱＬのうち、処理区分欄５４ｃ、対象テーブル欄５４ｄの値が同一であり、かつ条件欄５４ｆで指定するカラムが同一であるＳＱＬを一の処理パターンとしてまとめたものである。図７のログテーブル５４の場合、３行目、４行目、５行目のＳＱＬは、処理区分欄５４ｃ、対象テーブル欄５４ｄの値がそれぞれ「select」、「aaa-table」であり、条件欄５４ｆで指定するカラムが「d-label」および「e-label」であるため、一の処理パターンとしてまとめられる。
【００４７】
処理内容テーブル５６の各行は、まとめた後の処理パターンに対応する。また処理内容テーブル５６の処理区分欄５６ａ、対象テーブル欄５６ｂ、対象カラム欄５６ｃ、条件欄５６ｄは、ログテーブル５４の処理区分欄５４ｃ、対象テーブル欄５４ｄ、対象カラム欄５４ｅ、条件欄５４ｆにそれぞれ対応する。ただし、条件欄５６ｄにおける記載は、ログテーブル５４の条件欄５６ｄに記載された各カラムに対する設定値を「？」でマスクすることにより、個々のＳＱＬをパターン化している。
【００４８】
対応ＳＱＬ欄５６ｅは、各処理パターンと、ログテーブル５４の行との対応関係を記載している。同図の例では、１行目、２行目の処理パターンはログテーブル５４の「１」行目、「２」行目にそれぞれ対応し、３行目の処理パターンはログテーブル５４の「３」、「４」、「５」行目をまとめたものであることを表している。ただし、上述のとおりＳＱＬの処理時間の標準偏差がしきい値を超え、処理時間の範囲によってＳＱＬを分類した場合に、分類後のＳＱＬを区別しサンプリングを忠実に行うため、条件欄５６ｄにおける設定値の記載は「？」以外の変数としてもよい。
【００４９】
対象プログラム欄５６ｆはログテーブル５４の対象プログラム欄５４ｈに対応する。発生頻度欄５６ｇには、その処理パターンが発生した頻度、すなわちＳＱＬが発行された回数を記載する。図７のログテーブル５４の場合、処理内容テーブル５６の１行目、２行目、３行目の処理パターンに属するＳＱＬが発行された回数がそれぞれ「１」回、「１」回、「３」回、となる。インデックスの参照形態や更新形態が同様のＳＱＬを一の処理パターンとしてまとめることにより、形態ごとに発生頻度を導出することができる。インデックスの参照形態や更新形態が同様のＳＱＬは最適なインデックスが共通していることから、発生頻度に応じて処理パターン単位で修正案を模索することにより、インデックスの最適化を効率よく行うことができる。
【００５０】
インデックス候補決定部３０は、処理内容テーブル５６の発生頻度があらかじめ設定されたしきい値より大きい処理パターンを抽出し、効率化対象の処理パターンとする。そして当該処理パターンの対応ＳＱＬ欄５６ｅに記載の値に基づきログテーブル５４を参照して当該処理パターンに属するＳＱＬのいずれかを抽出し、そのＳＱＬに対するインデックスの修正案を取得する。あるいは、通常運用時に発行されたＳＱＬの実行コストに係る情報を記録しておき、当該実行コストの高いＳＱＬを抽出して効率化対象としてもよい。あるいは発生頻度と実行コストの双方を考慮してＳＱＬを抽出してもよい。
【００５１】
例えば、図７の処理内容テーブル５６における３行目の処理パターンに対し、「d-label」および「e-label」にそれぞれインデックスを作成する案、「d-label」および「e-label」の複合インデックスを作成する案、「d-label」にのみインデックスを作成する案、の３案が作成される。するとインデックス候補決定部３０は、処理内容テーブル５６に含まれる各処理パターンに属するＳＱＬを、効率化対象か否かに関わらず、例えば１つずつログテーブル５４から抽出し、元のインデックスを利用した場合と各修正案を適用した場合とで実行することにより実行コストを比較する簡易評価を行う。効率化対象の処理パターンが複数存在する場合は、同様の処理を繰り返す。
【００５２】
図８は簡易評価における実行コストの記録例を示している。実行コストテーブル６０は、処理区分欄６０ａ、対象カラム欄６０ｂ、条件欄６０ｃ、修正前実行コスト欄６０ｄ、修正後実行コスト欄６０ｅを含む。実行コストテーブル６０の各行は、処理内容テーブル５６に記載された各処理パターンにそれぞれ対応し実行されたＳＱＬに対応する。１行目は処理内容テーブル５６の１行目の処理パターンとして抽出された、ログテーブル５４の１行目のＳＱＬに対応する。２行目、３行目はそれぞれ、処理内容テーブル５６の２行目、３行目の処理パターンとして抽出された、ログテーブル５４の２行目、３行目のＳＱＬに対応する。
【００５３】
したがって、実行コストテーブル６０の処理区分欄６０ａ、対象カラム欄６０ｂは処理内容テーブル５６の処理区分欄５６ａ、対象カラム欄５６ｃにそれぞれ対応し、条件欄６０ｃはログテーブル５４の条件欄５４ｆに対応する。そして修正前実行コスト欄６０ｄおよび修正後実行コスト欄６０ｅには、各ＳＱＬを元のインデックスで実行した場合、およびある修正案で実行した場合にそれぞれ記録した、実行コストの各指標を表す数値を記載している。同図の例では前述のとおり、単一の処理コストを表す数値として「ＣＰＵ時間」、レスポンスを表す数値として「経過時間」、ディスク負荷を表す指標としてデータの「読み出し量」を記録している。ただし同図は一例であり、各指標を表す物理量はこれに限らない。また指標の数や指標に対する物理量の数も限定されない。修正案が上述のように複数ある場合は、修正後実行コスト欄６０ｅは修正案の数に応じて存在することになる。
【００５４】
インデックス候補決定部３０は図８のように記録された実行コストにより元のインデックスと修正案のインデックスとで実行コストを比較する。図９は実行コストの比較結果例を示している。実行コスト比較テーブル６２は、ＣＰＵ時間欄６２ａ、経過時間欄６２ｂ、読み出し量欄６２ｃ、および合計欄６２ｄを含む。インデックス候補決定部３０は、各処理パターンに属するＳＱＬをそれぞれ１つずつ処理して図８に示す実行コストテーブル６０を記録する。そして当該記録に基づき、各処理パターンの発生頻度を考慮して総実行コストを簡易的に算出し、実行コスト比較テーブル６２を作成する。
【００５５】
図９に示した実行コスト比較テーブル６２の１行目は元のインデックスを用いた場合の総実行コスト、２行目はある修正案を適用した場合の総実行コスト、３行目は修正案を適用した場合の元のインデックスからの改善度を表している。各行において、ＣＰＵ時間欄６２ａ、経過時間欄６２ｂ、読み出し量欄６２ｃに記録される数値は、実行コストテーブル６０の修正前実行コスト欄６０ｄおよび修正後実行コスト欄６０ｅの対応する欄における各数値を全処理パターンで足し合わせた値に対応する。ただし、実行コストテーブル６０の３行目の処理パターンは発生頻度が３回であることが、図７の処理内容テーブル５６の発生頻度欄５６ｇから特定できるため、実行コストを表す数値も３倍する。
【００５６】
たとえば修正前実行コスト欄６０ｄにおいて「ＣＰＵ時間」は１行目の処理パターンが「２５」、２行目の処理パターンが「１５」、３行目の処理パターンが「１０」であるため、実行コスト比較テーブル６２における「修正前総実行コスト」のうちＣＰＵ時間欄６２ａに記載される値は、２５＋１５＋１０×３＝「７０」と算出される。このように、各処理パターンに属するＳＱＬを１つずつ実行し、得られた実行コストを表す数値を、実際の発生頻度によって重み付けすることにより、バッチ処理やプログラム内での総実行コストを簡易的に比較することができる。
【００５７】
図９の実行コスト比較テーブル６２のＣＰＵ時間欄６２ａによれば、元のインデックスを利用した際の総実行コスト（修正前総実行コスト）が「７０」、ある修正案を適用した場合（修正後総実行コスト）は「５６」であるため、その差が１４であり「改善度」は「２０％」となっている。同様に経過時間欄６２ｂによれば、元のインデックスの場合が「７５」、修正案の場合が「６１」であるため、「改善度」は「１９％」となっている。また読み出し量欄６２ｃによれば、元のインデックスの場合が「６」、修正案の場合が「８」であるため、「改善度」は「−３３％」となっている。これはインデックスを増加させたことによりインデックスを読み出す処理が増えたことを表している。
【００５８】
「ＣＰＵ時間」、「経過時間」、「読み出し量」は実行コストの指標を表す物理量の例であり、それぞれ実行コストの指標である「処理コスト」、「レスポンス」、「ディスク負荷」と置き換えることができる。すなわち図９に示した修正案は、「処理コスト」と「経過時間」が改善し、「ディスク負荷」が悪化するといえる。この結果を総合評価するために、ユーザなどによりあらかじめ各指標に対する優先度を設定するようにしてもよい。
【００５９】
図９は各指標に対して設定された優先度の例も示している。優先度テーブル６４では、「処理コスト」、「レスポンス」、「ディスク負荷」の各指標に対し、「７０％」、「２０％」、「１０％」の優先度が設定されている。このような重み付けを実行コスト比較テーブル６２の「ＣＰＵ時間」、「経過時間」、「読み出し量」の改善度に施したうえで合計することにより、合計欄６２ｄに示されるように総合的な改善度が「１４％」と算出できる。優先度は、ハードウェアの実際のＣＰＵ利用率やディスク負荷を取得し、それに応じてインデックス候補決定部３０が決定するようにしてもよい。
【００６０】
なお実行コストの総合的な評価の手法は上述したものに限定されず、その他の統計処理等のいずれを適用してもよい。図９に示した例では、設定された優先度を考慮すると、修正案による改善が見込めると判定できる。このような処理を、取得したインデックスの修正案のそれぞれに対して行い、あらかじめ設定した基準に則り修正案を絞り込み、インデックス候補を決定する。例えば改善が見込める修正案を全てインデックス候補としてもよいし、総合的な改善度が所定のしきい値を超える修正案をインデックス候補としてもよい。また総合的な改善度を比較し、所定の差をもって改善度が大きい修正案や、上位の所定数の修正案をインデックス候補としてもよい。
【００６１】
インデックス候補を決定するうえでのポリシーをさらに細かく設定するようにしてもよい。例えば「見積もり依頼登録」プログラムの「レスポンス」を優先させる、など、操作元のプログラムと実行コストの指標との組み合わせで優先順位を設定してもよい。図７の処理内容テーブル５６によれば、「見積もり登録」プログラムは処理区分が「insert」のＳＱＬを発行するため、インデックスを追加する修正を行うとインデックスの更新処理に時間を要し、そのレスポンスが悪くなることが予測できる。従って上述のような優先順位の設定がなされている場合には、インデックスを追加する修正案はインデックス候補から除外する。
【００６２】
このような処理を行うためには例えば、あらかじめ「insert」、「update」、「select」などの処理区分と実行コストの指標との組み合わせと、各組み合わせを優先する際に除外すべきインデックスの修正案とを対応づけたテーブルを準備しておく。そして優先するプログラムが発行するＳＱＬの処理区分を処理内容テーブル５６から取得して、準備しておいたテーブルを参照することにより、除外すべき修正案を取得できる。
【００６３】
あるいは実行コストテーブル６０を参照し、優先度の高いプログラムが発行するＳＱＬの実際のコストに基づき修正案の是非を判断するようにしてもよい。上記の設定例では、図８の実行コストテーブル６０の１行目が「見積もり登録」プログラムが発行するＳＱＬに対応することが図７の処理内容テーブル５６からわかる。そして当該行においてレスポンスを表す数値である「経過時間」を修正前実行コスト欄６０ｄ、修正後実行コスト欄６０ｅからそれぞれ抽出して比較を行う。
【００６４】
図８の例では修正案を適用することにより「経過時間」が「２６」から「３１」に増加していることから、この修正案は設定された優先順位に適合しないことが判定できる。さらに実行コストを表す数値の増加に許容範囲を設定し、より臨機応変な判定を可能としてもよい。優先順位は操作元のプログラム以外に、オンライン処理かバッチ処理か、といった処理形態に優先順位を設定するなど、ログとして記録されるいずれのカテゴリに優先順位を設定してもよい。
【００６５】
このようにして決定したインデックス候補を適用し、評価部３２が上述のとおりシミュレーションを行うことにより、インデックス候補を適用した際に見込める処理時間の短縮量を取得する。図１０は図３のＳ２０において評価部３２が行うシミュレーションの処理手順を示すフローチャートである。まず通常運用に用いられるハードウェア性能と、シミュレーションに用いることのできるハードウェア性能の差を考慮して、シミュレーションを行う際に並列で実行するＳＱＬの数を決定する（Ｓ３０）。ここでハードウェア性能とはプロセッサの数、メモリ容量、ハードディスク容量などである。例えばシミュレーションに用いるハードウェア性能が通常運用のハードウェア性能の１／１０であった場合、通常運用における並列実行数が１０００件であれば、シミュレーションにおける並列実行数を１００件とする。
【００６６】
ハードウェア性能の縮小率と合致する数のＳＱＬを並列に実行してシミュレーションを行うことにより、実行コストや総処理時間の見積もり精度が向上し、同時、あるいは連続して実行される全てのプログラムに対するインデックス修正の影響を正確に予測することができる。また通常運用時に異常に遅延したＳＱＬが存在している場合に、並列に実行されているＳＱＬを正確に再現することにより改善の有無を確認することができる。そのために、遅延が確認されているＳＱＬと並列に実行されているＳＱＬは、後述のサンプリング時に全て抽出するようにしてもよい。
【００６７】
ハードウェア性能に対応した並列実行数は、例えば次のように求められる。まず、元のインデックスを利用してログテーブルに記録されたＳＱＬのいずれかをシミュレーションの環境で実行し、そのときのＣＰＵ利用率、メモリ利用率、ディスク利用率、ＩＯバッファ利用率など、ハードウェアの利用率を取得する。そして並列実行数を増減させ、それぞれの利用率があらかじめ設定した基準値になったときの並列実行数を取得する。例えば通常運用時にＤＢＭＳが利用するハードウェアの利用率と同一、あるいは当該利用率から所定の範囲内に基準値を設定する。
【００６８】
あるいは、通常運用時にＤＢＭＳが利用するハードウェアの利用率に所定の倍率をかけた値を基準値とすることにより、過負荷シミュレーションを行ってもよい。この場合もシミュレーションを行うハードウェアを利用してＳＱＬを実行し、あらかじめ設定した割合のＣＰＵ利用率、メモリ利用率、ディスク利用率、ＩＯバッファ利用率が記録されるまで並列実行数を増減させ、最終的な並列実行数を決定する。さらに、利用率にかける倍率とその持続時間とによって過負荷の状態を形成してもよい。
【００６９】
次に、各処理パターンに属する具体的なＳＱＬと、当該ＳＱＬと並列に実行されているＳＱＬとからなる、並列実行数分のＳＱＬの組をログテーブル５４から抽出するサンプリング処理を行う（Ｓ３２）。図１１は並列実行されているＳＱＬの組の例を示している。並列実行ＳＱＬテーブル６６は、対象プログラム欄６６ａ、第１並列実行ＳＱＬ欄６６ｂ、第２並列実行ＳＱＬ欄６６ｃ、発生数欄６６ｄ、および発生頻度欄６６ｅを含む。
【００７０】
同図は、図７の処理内容テーブル５６で示した処理パターンのうち、３行目の処理パターンを基準として示した例であるが、各処理パターンを基準として同様の処理を行う。対象プログラム欄６６ａには当該処理パターンのＳＱＬの発行元として「見積もり印刷」プログラムと示されているが、これは処理内容テーブル５６の対象プログラム欄５６ｆの記載に対応する。第１並列実行ＳＱＬ欄６６ｂ、第２並列実行ＳＱＬ欄６６ｃにはそれぞれ、基準のＳＱＬと並列に実行されていることがログテーブル５４などに記録されているＳＱＬの識別情報とその発行元のプログラムを示している。ＳＱＬの識別情報は例えば各処理パターン内で固有の識別情報が付与されているとする。あるいはログテーブル５４の行番号を識別情報としてもよい。
【００７１】
同図の例は並列実行数を２とした場合であるが、並列実行数がＮの場合は第１並列実行ＳＱＬ欄、第２並列実行ＳＱＬ欄、・・・、第Ｎ並列実行ＳＱＬ欄のＮ個の欄に対応するＳＱＬが存在することになる。発生数欄６６ｄには第１並列実行ＳＱＬ欄６６ｂ、第２並列実行ＳＱＬ欄６６ｃに記載されたＳＱＬと基準のＳＱＬとの組み合わせが並列に実行された回数を、発生頻度欄６６ｅには基準のＳＱＬが実行された回数のうち、当該組み合わせが実行された回数の割合を示している。さらに発生数欄６６ｄの最下段には、基準のＳＱＬが実行された回数の合計が記載されている。同図の例では「３０００」回となっている。
【００７２】
同図１行目の組み合わせの場合、「見積もり依頼登録プログラム」の「ＳＱＬ１」と、「見積もりプログラム」の「ＳＱＬ１」とが並列に実行された回数が「１５０」回であるため、発生頻度は「５％」となる。他の組み合わせも同様である。当然、発生頻度は合計で「１００％」となる。
【００７３】
このような発生頻度で各ＳＱＬの組み合わせが並列に実行されるとき、発生頻度とサンプリング割合に応じてサンプリングを行うことにより、基準のＳＱＬ以外のＳＱＬによる処理の負荷を考慮したシミュレーションを行うことができ、処理時間の短縮量の見積もり精度を上げることができる。例えば図１１の例でサンプリングを行う割合を１０％とすると、基準のＳＱＬを３００回実行することになるが、その際に並列に実行するＳＱＬの内訳が、発生頻度欄６６ｅに記載された数値と同じ割合となるようにそれぞれの組み合わせに属するＳＱＬをサンプリングする。例えば、図１１の１行目の組み合わせは１５回、２行目の組み合わせは１２回サンプリングする。発生頻度が所定のしきい値を下回る組み合わせについてはサンプリング対象から除外してもよい。
【００７４】
実際には次のようにサンプリングを行うことができる。抽出したいＳＱＬの割合をＮ％としたとき、１００／Ｎが平均値となるような乱数を発生させる。そしてログテーブルを順に読み込み、対象のＳＱＬが検出される都度、発生させた乱数をデクリメントして、乱数が０になった際のＳＱＬ文を実行対象として抽出する。これを繰り返すことにより、Ｎ％の割合でのサンプリングが実現できる。これを基準のＳＱＬ全体、あるいは並列実行ＳＱＬテーブル６６の各行に対応する組み合わせごとに行う。
【００７５】
サンプリング割合は、シミュレーションにかかるコストと要求される精度に基づきあらかじめ設定しておく。例えば、元のインデックスに対するシミュレーションはサンプリング割合を低くし、インデックス候補のシミュレーションを行う際はサンプリング割合を高くする、といった調整をしてもよい。また、サンプリング割合を１００％として、ログテーブルに記録されたＳＱＬを全て実行するようにしてもよい。さらに、インデックス付加対象のテーブルごとにサンプリング割合を設定するようにしてもよい。インデックスと関連しないＳＱＬはサンプリングから除外するようにしてもよい。
【００７６】
また、対象となるテーブルを構成するデータのうち、ログに記録されたＳＱＬによって更新されるデータの割合が所定のしきい値を超える場合は、データを更新する処理、すなわちログテーブル５４の処理区分欄５４ｃなどに「insert」や「update」が記録されるＳＱＬを全てサンプリングするようにしてもよい。これにより、通常運用時と同等のデータをシミュレーションを実行しながら構築することができ、シミュレーションの精度が向上する。更新されるデータの個数は、データを更新する処理が対象とする行を特定し、各行における更新対象のデータ数を特定した行で合計することによって得られる。
【００７７】
同じ行に対する複数の更新処理を２重にカウントしないため、行をデータキーの値で区別する。ここでデータキーとは同じ行に含まれるデータを一意に特定するキーである。データキーの値は、データを更新する処理を一度行い、その直後にデータキーのカラムとして設定されたカラムの値を取得することにより得られる。この処理は、インデックス候補を決定する際にインデックス候補決定部３０がＳＱＬを実行する処理と兼ねていてもよい。
【００７８】
図１０に戻り、次に、サンプリングしたＳＱＬを、ログテーブルに記録された通常運用時と同様の順序および組み合わせで、元のインデックスを利用した場合と、インデックス候補を利用した場合についてそれぞれ実行する（Ｓ３４）。そして各ＳＱＬ実行の開始、終了時刻を読み込むことにより総処理時間の短縮量を見積もる（Ｓ３６）。
【００７９】
図１２はシミュレーションを行った結果の例を示している。処理時間テーブル６８は、処理区分欄６８ａ、対象カラム欄６８ｂ、条件欄６８ｃ、修正前処理時間欄６８ｄ、修正後処理時間欄６８ｅ、短縮時間欄６８ｆを含む。同図は、図７の処理内容テーブル５６で示した処理パターンのうち、３行目の処理パターンのＳＱＬ文を３つサンプリングして実行した場合を示している。この際、上述のように別のＳＱＬも並列で処理されていてよい。処理区分欄６８ａ、対象カラム欄６８ｂ、条件欄６８ｃは、実際に行ったＳＱＬの内容を示しており、例として図６のログテーブルの３、４、５行目のＳＱＬの処理区分欄５４ｃ、対象カラム欄５４ｅ、条件欄５４ｆに記載された内容に対応させている（１行目、３行目、５行目）。
【００８０】
さらに処理時間テーブル６８には、一行前のＳＱＬの実行終了から一行下のＳＱＬの実行開始までの実行間隔についても示している（２行目、４行目）。修正前処理時間欄６８ｄ、修正後処理時間欄６８ｅには、元のインデックスを用いた場合と、インデックス候補を適用した場合の、各ＳＱＬの処理時間の実測値をそれぞれ記載している。ただし実行間隔はインデックスの修正によって変化しないため、修正前処理時間欄６８ｄ、修正後処理時間欄６８ｅに同じ時間が記載されている。当該時間は、ターンアラウンドタイムとレスポンスタイムを測定することによって得られる。
【００８１】
図１２の処理時間テーブル６８の最下段における合計によれば、元のインデックスを用いた場合の処理時間の合計が「１１００ｍｓｅｃ」、インデックス候補による処理時間の合計が「１０７９ｍｓｅｃ」で、短縮時間の合計は「２１ｍｓｅｃ」となる。このような処理時間の短縮量を、各処理パターンおよび各インデックス候補に対して求めることにより、処理時間の短縮に最も有効なインデックスを取得することができる。インデックス選定部３４は、そのようにして取得したインデックスを最終的に採用するインデックスとして決定する。
【００８２】
図１２は上述のとおり、一の処理パターンについて３つのサンプリングを実行した結果を示している。これにより、インデックス候補を適用する前後の処理時間の比較を行うことができる。さらにサンプリングの割合を考慮することにより、通常運用時の総処理時間に換算することもできる。例えば、図１２で実行した３つのＳＱＬが、一の見積もり依頼について発行される場合、見積もり依頼の数を積算することにより実際の処理時間や短縮量をおよそ予測することができる。
【００８３】
さらに、シミュレーションに用いたハードウェア性能と通常運用時のハードウェア性能が異なる場合に、図１２に示したシミュレーションの結果から通常運用時の総処理時間を厳密に求めるには、例えば次のような処理を行う。すなわち、フルスキャンや行のＩＤを利用した単一データのクエリーなど特徴的なＳＱＬを双方の環境で実行し、ＣＰＵ時間、経過時間などの実行コストの指標を表す時間的な数値を取得する。そしてその割合に基づきシミュレーションにおける各時間から通常運用時の各時間への換算を行う。
【００８４】
図１２に示したシミュレーション結果は処理時間を着眼点としているが、シミュレーション中に、各実行コストの指標を表す時間以外の数値を記録し、図８に示した実行コストテーブル６０や図９に示した実行コスト比較テーブル６２と同様の構造を有するテーブルを作成してもよい。そしてインデックス修正案からインデックス候補を決定するときと同様、あらかじめ設定した選定ポリシーと照合してその適合度合いなどに基づき実行コストを評価し、最終的なインデックスを決定してもよい。
【００８５】
例えば総実行コストの合計、「見積もり依頼登録」プログラムの「レスポンス」、「見積もり印刷」プログラムの「レスポンス」、といった順に優先順位が設定されていたとする。このとき、インデックス候補を適用することにより「見積もり依頼登録」プログラムの「レスポンス」が悪化しても、総実行コストの合計が改善する場合は、当該インデックス候補を採用する。一方、総実行コストの合計がほとんど変化せず、「見積もり印刷」プログラムの「レスポンス」が向上しても、「見積もり依頼登録」プログラムが悪化する場合は当該インデックス候補を採用しない。このように優先順位のパターンとそれによってなされる評価のスキームをあらかじめ準備しておくことにより、インデックス候補の評価を行う。優先順位に応じて実行コストや総処理時間に対する点数付けをし、合計点によって採用するインデックスを決定するようにしてもよい。
【００８６】
適用部３６は選定されたインデックスを、通常運用時に用いられるように情報記憶部２２の通常運用時に参照される領域に格納する。格納する前に、図示しない出力装置などに選定されたインデックスやそれによる改善量を出力することにより、ユーザが最終的な適用判断を行うようにしてもよい。あるいは適用を行わず、インデックスを修正すると改善が見込まれる旨の警告を行うのみでもよい。また、本格的に適用する前に、通常運用時の環境下で仮の処理を行うようにしてもよい。この場合、通常運用時と同等のハードウェア性能で実行する必要があるため、プログラム実行部２６に仮の処理を行わせる。当該処理は通常運用が行われていない時間内に行う。
【００８７】
ここで仮の処理としては、想定したハードウェア性能の差に大きな誤差がないことを確認できればよいため、上述の、フルスキャン処理など特徴的なＳＱＬを実行させればよい。そしてＣＰＵ時間、経過時間、データ読み出し量などを記録する。記録した値と、インデックス選定時に予測した値とに所定のしきい値以上の差がない場合、実際の適用処理を行う。
【００８８】
例えばインデックス選定時にハードウェア性能の差を予測する際、上述の特徴的なＳＱＬを通常運用の環境とシミュレーションの環境でいくつか実行し、その際に記録されるＣＰＵ時間などの時間差を統計処理する。そして最も発生確率の高い時間差を予測値とする一方、発生確率が所定のしきい値以下となる際の時間差を、インデックス修正による効果を保証するレベルとして導出しておく。そして仮の処理を行った際の時間差が保証レベルをはずれた場合に、予想外の誤差が生じていると判定する。このような場合は、選定したインデックスを通常運用へ適用しても効果が得られにくいと考えられるため、ユーザに警告を与え、ユーザが了承した場合にのみ適用を行ってもよい。
【００８９】
以上述べた本実施の形態によれば、データベースを含むシステムにおいてインデックスの最適化を行う。具体的には、まず実際に発行されたＳＱＬを取得し分析することにより処理内容のパターンを取得する。そして処理パターンに属するＳＱＬを抽出して修正案を取得後、その他の処理パターンとともに実際に処理を行うことにより実行コストを見積もり、修正案の絞り込みを行う。これにより、効率化対象の処理パターンのみでなく、その他の処理パターンへの影響も考慮してインデックス修正案の評価を行ったうえで、効果の大きいインデックス候補を決定することができる。
【００９０】
また、絞り込み後のインデックス候補について、より詳細にシミュレーションを行うことにより最適なインデックスを導出する。シミュレーションにおいては、通常運用時のハードウェア性能との差を考慮してＳＱＬの並列実行数を決定する。そして実際に並列実行されているＳＱＬの組み合わせの発生頻度に応じてサンプリングを行い、通常運用時と同様の順序で実行する。これにより、ハードウェア性能が異なっていてもより忠実に通常運用時の状況を再現したうえでシミュレーションを行うことができ、より正確な処理時間や実行コストの改善量を見積もることができる。フルスキャンなど特徴的なＳＱＬを通常運用時の環境とシミュレーションにおける環境とで実行することにより得たハードウェア性能の差を適用することにより総処理時間を補正し、さらに処理時間を正確に見積もることもできる。
【００９１】
そしてシミュレーションによって得られた処理時間や実行コストを設定された選定ポリシーに照らしたうえで、最終的なインデックスを決定する。そしてユーザへの問い合わせや通常運用環境での予測値の確認などを適宜行いインデックスを適用する。これにより、新たなインデックスを適用するか否かの決定を臨機応変に行うことができるとともに、場合によっては人手を介さずにインデックスの修正が必要なＳＱＬの検出から、その他のＳＱＬへの影響を考慮した総合的な改善量の見積もり、および最適化したインデックスの適用までを全てシステムが行うことができ、正確かつ効率的にインデックスを最適化することができる。
【００９２】
結果的にインデックスの最適化を速やかに行うことができるため、通常運用されているシステムの環境と同じ環境を開発機に再現せずとも、通常運用機での最適化処理が可能となる。これにより、開発機や最適化を行うための人員の準備に係るコストを削減することができる。またデータベースを開発機にコピーする場合は、情報保護の観点からデータをマスクする必要があるが、これにより本来のデータベースのばらつきが崩れ、正確なシミュレーションができないことがあり得る。本実施の形態では通常運用機での最適化が可能であるため、マスクの必要がなくシミュレーションの正確性が増す。
【００９３】
以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００９４】
例えば、クラスタリングなどのために通常運用と同等の環境を開発環境として用意することは特異なことではないため、通常運用時のハードウェア性能と同等の性能を有する環境をシミュレーション用に与えるようにしてもよい。そして、通常運用時に行われた全ＳＱＬをリアルタイムで実行することによりシミュレーションを行ってもよい。この場合、通常運用で実行されたＳＱＬの情報を得るための遅延時間のみでほぼ同時にシミュレーションを行う。このようにすると、双方の環境でデータの内容が同様となるため、シミュレーション環境で最適化を行った後、通常運用の環境とシミュレーション環境をスワップすることにより、インデックスの最適化や適用にかかる停止時間を短縮することができる。
【００９５】
また、新たなインデックス適用後に何らかの性能上の障害が発生した場合に、容易に元の状態に戻すことができるため、切り戻しにかかるダウンタイムを短縮することができる。また通常運用機でハードウエア上に障害が発生した場合など、通常運用に用いるハードウェアとシミュレーションで用いたハードウェアは最適化処理に係る極僅かな差のみであるため、シミュレーションに用いるハードウェアをバックアップに用いることもできる。
【００９６】
また本実施の形態ではインデックスの最適化を行ったが、ＤＢＭＳが有する機能を利用して、バッファサイズの修正、パーティショニング、ＤＢＭＳ用のメモリエリアの指定、ＤＢＭＳ用のセグメント等の修正などを同様の手順で行ってもよい。その際、シミュレーションを行うハードウェア性能が通常運用時と異なる場合は、本実施の形態における並列実行数の決定手法と同様に、ＤＢＭＳのメモリエリアを調整するなどの処理を行うことにより、より正確なシミュレーションが可能となる。
【図面の簡単な説明】
【００９７】
【図１】本実施の形態を適用できるシステムの構成例を示す図である。
【図２】本実施の形態における第１サーバの構成をより詳細に示す図である。
【図３】本実施の形態においてインデックスを最適化する処理手順を示すフローチャートである。
【図４】本実施の形態のデータベースにおけるデータの具体例を示す図である。
【図５】本実施の形態の監査ログ分析部が取得する監査ログのデータ構造例を示す図である。
【図６】図５の監査ログに基づき監査ログ分析部が生成するログテーブルの例を示す図である。
【図７】図６のログテーブルに基づき監査ログ分析部が作成する処理内容テーブルの例を示す図である。
【図８】本実施の形態におけるインデックス候補決定部が行う簡易評価における実行コストの記録例を示す図である。
【図９】本実施の形態におけるインデックス候補決定部が行う簡易評価における実行コストの比較例を示す図である。
【図１０】図３のＳ２０において本実施の形態における評価部が行うシミュレーションの処理手順を示すフローチャートである。
【図１１】本実施の形態において考慮する、並列実行されているＳＱＬの組の例を示す図である。
【図１２】本実施の形態において評価部がシミュレーションを行った結果の例を示す図である。
【符号の説明】
【００９８】
１０  情報処理システム、１２  第１サーバ、  １４  第２サーバ、  １６  データベース、  ２０  インデックス最適化部、  ２２  情報記憶部、  ２６  プログラム実行部、  ２８  監査ログ分析部、  ３０  インデックス候補決定部、  ３２  評価部、  ３４  インデックス選定部、  ３６  適用部、  ３８  仮想データベース、  ５４  ログテーブル、  ５６  処理内容テーブル。
【図１】
2009245351.tif 000003
【図２】
2009245351.tif 000004
【図３】
2009245351.tif 000005
【図４】
2009245351.tif 000006
【図５】
2009245351.tif 000007
【図６】
2009245351.tif 000008
【図７】
2009245351.tif 000009
【図８】
2009245351.tif 000010
【図９】
2009245351.tif 000011
【図１０】
2009245351.tif 000012
【図１１】
2009245351.tif 000013
【図１２】
2009245351.tif 000014