JP6669571B2 - リレーショナルデータベースのチューニング装置及び方法 - Google Patents

Description

本発明は、リレーショナルデータベースのチューニング装置及び方法に関し、特に、リレーショナルデータベースのパフォーマンスを分析及び改善する装置及び方法に関するものである。

各種データベースの方式のうち、リレーショナルデータベースは、現在、最も普及している方式であるが、累積的に増大するデータ量、ユーザ数に対して、レスポンス時間の短縮による性能向上は、パフォーマンスの良否を左右し、ビジネス上重要な課題になっている。

リレーショナルデータベースの性能向上のために、パフォーマンスを分析、改善するチューニング装置（以下、本明細書において「チューニング」とは、リレーショナルデータベースのパフォーマンスを分析及び／又は改善することをいうものとする。）、方法は多数提案されている。比較的簡易なチューニングとしては、高性能なＣＰＵの搭載、メモリの増強などのハードウェアリソースの改善やデータベースオブジェクトの最適化等が考えられる。しかしながら、大規模なテーブルへのアクセスに適切なインデックスが適用されず、非効率なアクセスが大量に発生し、無駄なデータがキャッシュに多数存在している場合、上記チューニング手法では効果的な改善は期待できない。そこで、効果的なパフォーマンス改善のチューニング手法は、照会言語に対するチューニングが主流になっている。

ここで、照会言語とは、リレーショナルデータベースに対して、データベースの作成、削除、情報の登録、検索などの操作を行うために用いられる言語であり、典型的には、ＳＱＬ（Ｓｔｒｕｃｔｕａｌ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）である。本明細書では、以下、特に明記しない限り、ＳＱＬを例として説明する。

ところで、ＳＱＬ単位のチューニングは、小規模なデータベースであれば、比較的データベース管理者の技量の差は生じにくい。しかし、大規模なデータベースの場合、ＳＱＬ単位で分析するには、相当の経験が要求される属人的な手法であるうえ、仮に、当該管理者の経験値が高くても、ボトルネックになっているＳＱＬを捜し当てるのは、大きな作業負荷となり、必ずしも効率的とはいえないという問題がある。

また、ＳＱＬ単位のチューニングでは、前記ボトルネックとなったＳＱＬを捜し当てた後、最適なインデックスの付加が必要になるが、係るインデックスの付加についても、管理者の技量に依存するため、均質な改善効果は期待できない。

ＳＱＬ単位の分析の上記問題点を解決するものとして、従来、例えば、データベースに対して実行されたＳＱＬの統計情報を、トランザクション単位でまとめて表示するようにし、それぞれのＳＱＬの利用状況をトランザクションごとに解析することができるデータベースチューニング装置が提案されていた（例えば、特許文献１参照）。この構成によれば、ＳＱＬの重複部分を除去したり、利用頻度が極端に高いＳＱＬを他のＳＱＬに振り分けたり、ＳＱＬの順番の入れ替え等が可能になり、ＳＱＬ単位の分析に比べて比較的容易にチューニングを行うことができる。

また、発行された全ＳＱＬコマンドの稼働情報を変更履歴として取得し、蓄積された稼働情報に基づいて、処理内容が一致する同種のＳＱＬコマンドごとに実行時間を集計した総実行時間を求め、総実行時間の値が上位半数に含まれるＳＱＬコマンドの処理対象となるカラムに、新たなインデックスを付加するとともに、これらの処理を各ＳＱＬコマンドの総実行時間の累計値が最小となるまで繰り返す、インデックスの自動生成・付加システムが提案されていた（例えば、特許文献２参照）。この構成によれば、システム管理者の個人的技量等に関わらず、指定した試行条件下における検索効率および更新効率のバランスがとれた最適なインデックスを自動的に作成・付加して、ＲＤＢの運用効率を総合的に向上させることができる。

特開２００１−１７５６７８号公報 特開平１０−１１１８１９号公報

しかしながら、上記特許文献１に係る先行技術によれば、ＳＱＬのまとめ方が、トランザクション単位になっているため、ＩＮＳＥＲＴ、ＵＰＤＡＴＥ及びＤＥＬＥＴＥを使用した更新処理に限定されており、チューニングにおいて最も重要な検索系の処理には対応できないという問題があった。

また、上記特許文献２に係る先行技術によれば、所定のＳＱＬコマンドの処理対象となるコラムに自動的に作成・付加されたインデックスが、他のＳＱＬコマンドにおいて使用されている場合の影響について何ら考慮されておらず、係る新たなインデックスの作成・付加が、却ってパフォーマンスに悪影響を及ぼすおそれがあった。

本発明は、上記課題を解消させるためのものであり、リレーショナルデータベースの操作で使用される照会言語単位のチューニング作業負荷を軽減しつつ、精度の高い検索系のチューニングを可能にするとともに、チューニング処理対象外のコマンドに対するパフォーマンスの影響も考慮した上で最適なインデックスを提示するチューニング装置及び方法を提供することを目的とする。

上記目的を達成させるために、本発明に係るチューニング装置は、ＳＱＬ等の個々の照会言語を介して発行されたコマンドをリレーショナルデータベースに対するデータの検索結果を取得するための検索条件情報及び検索方法情報から成る取得パターンとして集約させ、前記発行されたコマンドが実行されたときの所定の実行情報を前記取得パターンと対応させてチューニング情報とし、この各チューニング情報から前記リレーショナルデータベースを構成するオブジェクト単位にチューニング用テーブルを生成することで、チューニングによる分析の対象を物理的に低減させることを最も主要な特徴とする。

すなわち、本発明に係るチューニング装置は、リレーショナルデータベースのパフォーマンスを分析及び改善するチューニング装置であって、
前記リレーショナルデータベースに対して所定の照会言語を介して発行されたすべてのコマンドが、データベースマネージメントシステムで実行されたときの所定の実行情報を収集する収集手段と、
前記各コマンドの実行によってデータの検索結果を取得するための検索条件情報及び検索方法情報を一対の取得パターンとして抽出する抽出手段と、
前記抽出された各取得パターンを前記リレーショナルデータベースのオブジェクト単位に組分けした取得パターン群として一覧可能にグルーピングするとともに、各取得パターンと各取得パターンに対応する前記収集された実行情報とを一連のチューニング情報として構成したチューニング用テーブルを生成する生成手段と、を有することを特徴とする。

この構成によれば、照会言語に対するチューニングを当該照会言語単位に個々に分析するのではなく、取得パターンとしてまとめられた前記オブジェクト単位での分析が可能となる。

前記各取得パターンは、少なくとも、前記データベースマネージメントシステムによって作成された実行計画情報から抽出されたものであればよい。

前記検索条件情報は、例えば、検索対象を絞り込むためのカラムデータと該カラムデータに対する検索条件を前記照会言語で表記した演算子データによって特定し、前記検索方法情報は、前記検索対象を絞り込むためのカラムデータに対して設定されたインデックスデータと前記オブジェクトに対して設定された検索経路を示す走査方式データによって特定すればよい。

前記収集手段が収集する実行情報は、前記実行計画情報のほか、少なくとも、前記各取得パターンの対象となるオブジェクトを参照するための前記照会言語のコマンド数、実行回数、処理の経過時間、ＣＰＵの使用時間、待機時間からなる実行実績情報を含むものであればよい。

前記収集手段は、前記リレーショナルデータベースが稼働中に、該リレーショナルデータベースに実際に格納されているオブジェクトとは別に、継続的に更新される仮想のテーブルから前記実行情報を定期的に収集し、時系列に管理するようにしてもよい。

前記収集手段は、前記実行実績情報を、前記リレーショナルデータベース稼働時からの累計データの収集と、前記収集された累計データから所定の算定手段によって得られた前記リレーショナルデータベース稼働後の特定の期間内のデータの収集との２種類のデータを収集可能とするようにしてもよい。

前記各取得パターンの検索条件情報に対する検索方法情報のアクセス効率を所定の演算式によって評点として算出する算出手段を備え、前記生成手段は、算出された前記各評点情報を前記実行情報に含めるようにしてもよい。

前記生成手段は、前記各オブジェクトの取得パターン群から、前記実行情報に基づいて、チューニングの対象となる取得パターンを特定する選出手段と、選出された取得パターンから、インデックスデータとして選定されていないカラムデータを読み出し、所定の条件に従って当該カラムデータからインデックスデータを選定する選定手段とを有し、前記チューニング用テーブルに選定したインデックスデータを含めるようにしてもよい。

前記選定手段は、少なくとも、前記実行実績情報から、前記選定されていないカラムデータの使用回数を優先的選定基準とする第１の基準と、実行回数を優先的選定基準とする第２の基準との２種の選定基準を備え、前記生成手段は、前記チューニング用テーブルから、前記２種の選定基準によって選定されたインデックスデータを選択可能としたものであってもよい。

前記生成手段は、前記選出手段によって特定された取得パターンのインデックスデータと同一のインデックスデータが、前記取得パターン群のいずれかで設定されている数を前記特定された取得パターンに対応させて表示するようにしてもよい。

所定の目的で発行される１以上のコマンド群に付されたクエリオプティマイザに対する指示、コマンドの説明であって、前記コマンドの実行後でも自動的に変更されないテキストに対して、前記コマンド群を特定するＩＤを付与するＩＤ付与手段を有し、前記生成手段は、前記付与されたＩＤによって特定される前記コマンド群における前記取得パターンを閲覧可能とするようにしてもよい。

さらに、本発明に係るチューニング方法は、リレーショナルデータベースのパフォーマンスを分析及び改善するチューニング方法であって、
前記リレーショナルデータベースに対して所定の照会言語を介して発行されたすべてのコマンドが、データベースマネージメントシステムで実行されたときの所定の実行情報を収集するステップと、
前記各コマンドの実行によってデータの検索結果を取得するために、検索対象を絞り込むためのカラムデータと該カラムデータに対する検索条件を前記照会言語で表記した演算子データによって特定された検索条件情報及び前記検索対象を絞り込むためのカラムデータに対して設定されたインデックスデータと前記オブジェクトに対して設定された検索経路を示す走査方式データによって特定された検索方法情報を一対の取得パターンとして抽出するステップと、
前記抽出された各取得パターンを前記リレーショナルデータベースのオブジェクト単位に組分けした取得パターン群として一覧可能にグルーピングするとともに、各取得パターンと各取得パターンに対応する前記収集された実行情報とを一連のチューニング情報として構成したチューニング用テーブルを生成するステップとを有し、
前記収集は、前記リレーショナルデータベースが稼働中に、該リレーショナルデータベースに実際に格納されているオブジェクトとは別に、継続的に更新される仮想のテーブルから前記実行情報を定期的に収集し、専用のリポジトリに格納するとともに、時系列に管理することによって行われることを特徴とする。

この構成によれば、照会言語に対するチューニングを当該照会言語単位に個々に分析するのではなく、取得パターンとしてまとめられた前記オブジェクト単位での分析が可能になるとともに、分析のターゲットとなるリレーショナルデータベースのオブジェクトデータを直接収集するのではなく、前記ターゲットのデータディクショナリから専用のリポジトリにデータを収集することができる。

前記各取得パターンの検索条件情報に対する検索方法情報のアクセス効率を所定の演算式によって評点として算出するステップを有し、算出された前記各評点情報を前記実行情報に含めるようにしてもよい。

前記各オブジェクトの取得パターン群から、前記実行情報に基づいて、チューニングの対象となる取得パターンを特定して選出するステップと、選出された取得パターンから、インデックスデータとして選定されていないカラムデータを読み出し、所定の条件に従って当該カラムデータからインデックスデータを選定するステップとを有し、前記チューニング用テーブルに前記選定したインデックスデータを含めるようにしてもよい。

前記オブジェクトの設計時に行われる複数の段階のテストにおいて、前記実行情報の収集と前記取得パターンの抽出を順次実行するとともに、前記チューニング用テーブルに加えて、前記抽出された取得パターンの検索条件情報から、前記カラムデータごとに分解し、検索時の使用回数が多い順に前記カラムデータをソートしたテーブルを生成するようにしてもよい。

前記リレーショナルデータベースの本番環境での稼働時において、新たなデータの登録、削除、定義の変更が発生したときに、当該発生の前後におけるチューニング用テーブルの差分から新たに発生した取得パターンを特定するようにしてもよい。

前記実行情報は、前記仮想のテーブルからの定期的な収集に代えて、前記リレーショナルデータベースから直接収集するものとし、前記選定したインデックスデータを介して前記リレーショナルデータベースで検索のシミュレーションを行うと、前記選定されたインデックスを適用する前後の前記実行情報に基づくデータ分布を閲覧できるようにしてもよい。

本発明に係るチューニング装置及びチューニング方法は、前記取得パターンを抽出することにより、ＳＱＬ等の照会言語単位ではなく、オブジェクト単位でのチューニングを可能とするため、分析する事項を飛躍的に低減でき、チューニング作業の負荷を軽減させることができるという効果を奏する。

また、前記取得パターンによって、照会言語単位の分析では直ちに把握しにくいと考えられる各オブジェクトに対する検索条件情報、検索方法情報を容易に把握することができるため、精度の高い検索系のチューニングを容易に行うことが可能となるという効果を奏する。

さらに、チューニング処理対象外のコマンドに対するパフォーマンスの影響も考慮した上で最適なインデックスを提示することができるという効果を奏する。

図１は本発明に係るチューニング装置のブロック構成図である。 図２は本発明に係るチューニング装置の実行実績情報を取得する期間の算定機能を示した線表図である。 図３は本発明に係るチューニング方法を示したフロー図である。 図４は第１基準のインデックス選定の処理フロー図である。 図５は第２基準のインデックス選定の処理フロー図である。 図６はチューニング用テーブル例を示した図である。 図７は図６の取得パターンの順番１のＳＱＬ実行計画情報を示した図である。 図８は図６のチューニング用テーブルの一部を成すチューニング対象の取得パターンのインデックス情報を示した図である。 図９は取得パターンの検索条件情報から検索時の使用回数が多い順にカラムデータをソートしたテーブル例を示した図である。

図１を参照して、１は、本発明に係るチューニング装置である。チューニング装置１は、後述する諸機能を発揮させるための専用装置であってもよいが、好適には、主に、中央処理装置（ＣＰＵ）、メインメモリ、磁気ディスク、その他周辺機器から構成されるパーソナルコンピュータであればよい。ＣＰＵは、主として本発明に係るチューニング装置１の各構成要素の動作を制御する。メインメモリは、ＣＰＵが実行する制御プログラムを格納し、ＣＰＵによるプログラム実行時の作業領域を提供する。磁気ディスクは、オペレーティングシステム、周辺機器のデバイスドライブ、本発明に係る各種処理を行うプログラムを含む各種アプリケーションを格納する。図１では、専ら本発明の機能の説明に必要となる機能のみを記載し、汎用的に機能する前記諸機能等の説明は省略する。

本実施の形態では、チューニング装置１は、データベースシステムＤに接続され、さらに、リレーショナルデータベースシステムＤは、ユーザ端末Ａに接続されている。リレーショナルデータベースシステムＤは、データベース本体Ｄ１とデータベース管理システムＤ２から構成されている。データベース本体Ｄ１は、各種テーブル等（以下特に限定しない限り、本実施の形態では「オブジェクト」という。）を蓄積し、データベース管理システムＤ２は、ユーザ端末Ａからの特定データの閲覧要求に応じてデータを抽出するとともに、複数ユーザからのアクセスでデータの矛盾が生じないように監視を行うことでデータベース本体Ｄ１を管理、運用する。ユーザ端末Ａは、搭載された業務プログラム等のデータベースアプリケーションによって、データベース管理システムＤ２に対し、ＳＱＬコマンドを発行すると、データベース管理システムＤ２は、当該コマンドの解析、書換処理を介して、処理命令のコマンド群を生成し、効率的な処理手続を実行するために、実行計画を作成する。作成された実行計画（すでに、キャッシュに保存されたものを利用する場合もある。）により、ＳＱＬが実行され、前記ユーザが所望した検索の対象となるオブジェクトを提供する。また、データベース管理システムＤ２は、前記実行されたＳＱＬの実行情報、統計情報等も生成する。ここで、実行情報とは、前記生成された実行計画情報のほか、前記ＳＱＬの実行によって得られる情報であり、ＳＱＬ数、実行回数、実行処理の経過時間、ＣＰＵの使用時間、待機時間等の実行実績情報をいう。

なお、本実施の形態では、チューニング装置１と、リレーショナルデータベースシステムＤと、ユーザ端末Ａとは、別々のハードウェアで構成され、相互に接続されている形態であるが、これに限定する趣旨ではない。したがって、例えば、リレーショナルデータベースシステムＤとユーザ端末Ａが、同一のハードウェアであってもよく、ユーザ端末Ａとチューニング装置１とが同一のハードウェアであってもよい。すなわち、本明細書で記載する機能を発揮する限り、ハードウェア構成は、図１のものに限定されない。

チューニング装置１は、データベース管理システムＤ２から、前記実行情報を収集する収集部１１を備える。収集部１１は、本発明に係るチューニングを行うための専用のリポジトリを有し、これに前記実行情報が格納される。収集部１１による前記実行情報の収集元は、データベース本体Ｄ１が稼働中に、データベース本体Ｄ１に実際に格納されているオブジェクトとは別に、継続的に更新される仮想のテーブルである。一般に、リレーショナルデータベースは、データの冗長性を減らすために、閲覧に供する仮想のテーブル（以下「ビュー」という。）を提供するようになっているが、収集部１１では、特に、稼働中のデータベースのダイナミックなビュー（以下「動的パフォーマンスビュー」という。）を定期的に取得する。

また、収集部１１は、前記実行実績情報の収集のタイミングとして、リレーショナルデータベースシステムＤの稼働時からの累計データを収集するものと、前記収集された累計データから算定部１１１によって得られたリレーショナルデータベースシステムＤの稼働後の特定の期間内のデータの収集をするものとの２種類の収集機能を備える。すなわち、図２で示す通り、リレーショナルデータベースシステムＤの稼働開始時点Ｒ１に対して、チューニング装置１の稼働開始時点をＲ２とした場合、前記稼働開始時点Ｒ１からの累計データを収集するものは、Ｒ１からの実行実績情報の収集Ｃ１及びＣ２があり、算定部１１１で算定された前記Ｃ１とＣ２の差分から、特定の時点Ｒ３からのデータを収集するものは、Ｒ３からの実行実績情報の収集Ｃ３がある。

なお、実行実績情報の収集Ｃ１及びＣ２は、チューニング装置１の稼働開始時点Ｒ２において、データベース管理システムＤ２が、リレーショナルデータベースシステムＤの稼働開始時点Ｒ１から生成した実行実績情報が含まれるため、チューニング装置１の稼働開始時点Ｒ２は、実行実績情報の収集のタイミングに直接関係しない。

以上の通り、収集部１１は、実行情報を動的パフォーマンスビューから収集するとともに、実行実績情報の収集のタイミングとして、２種のタイプを選択することが可能なため、チューニングの目的に応じて必要なデータをタイムリーに収集することができる。

収集部１１で収集された実行計画情報から、抽出部１２では、ＳＱＬの実行によってデータの検索結果を取得するための検索条件情報及び検索方法情報を一対の取得パターンとして抽出する。図６で後述するように、前記検索条件情報は、検索対象を絞り込むためのカラムデータと該カラムデータに対する検索条件をＳＱＬで記述された演算子データによって特定し、前記検索方法情報は、前記検索対象を絞り込むためのカラムデータに対して設定されたインデックスデータと前記オブジェクトに対して設定された検索経路を示す走査方式データによって特定する。

一般に、リレーショナルデータベースに対して所望のデータを検索する場合、少数のデータを検索するために、膨大なデータすべてを検索するとアクセス効率が著しく低下する。そこで、通常、インデックスを設定することによってアクセス効率を向上させるが、ある特定のＳＱＬの実行に利するインデックスを設定しても、他のＳＱＬの実行に伴うアクセス効率を低下させる可能性もある。また、特定のオブジェクトへのアクセスの方法は、通常、多数存在し、当該オブジェクトに対して、検索要求ごとに、異なる条件式が設定され、膨大なＳＱＬが使われているため、ＳＱＬ単位で、高効率なアクセス効率の阻害原因を探ることは多大な作業負荷となるおそれがある。

そこで、本発明に係るチューニング装置１は、アクセス効率の改善点を分析する情報として、前記検索条件情報及び検索方法情報から成る一対の取得パターンを提供する。後述するように、実行されたＳＱＬコマンドをアクセス効率の視点で取得パターンという形式に再構築することにより、分析する対象の数を物理的に低減させるとともに、高精度に前記阻害原因となる部分の特定を可能とする。

さらに、本実施の形態では、チューニング装置１の機能として、前記アクセス効率を所定の計算式で評点化する算出部１３を備える。例えば、ＳＱＬの実行によって求める件数が１件である場合に、実行計画によって当該データに到達するまでのアクセス件数が、１件と１００万件では著しくアクセス効率が異なる。アクセス効率の算出方法は、多種多様なものが考えられるが、算出部１３は、前記一対の取得パターンに基づき、下記の通り評点を算出する。

各検索条件情報に対して、所与の評点として１００点を付与し、各検索条件情報を構成する各カラムの平均値を求め、当該平均値に対して、各カラムの機能（役割）に応じた調整係数を乗算し、乗算結果の総和を当該取得パターンの評点とする。ここで、調整係数とは、当該カラムの役割が、インデックスによるアクセスの場合、上記平均値を維持（調整係数＝１）、インデックスのフィルタリングの場合、上記平均値の半分（調整係数＝１／２）、テーブルのフィルタリングの場合、ゼロ（調整係数＝０）とする。

例えば、特定の取得パターンにおける検索条件情報が、Ｘ、Ｙ、Ｚの３つのカラムから構成されている場合であって、Ｘがインデックスアクセス、Ｙがインデックスフィルタリング、Ｚがテーブルフィルタリングとすると、下記演算式により、上記特定の取得パターンの評点が求められる。

ただし、前記取得パターンから得られる情報に基づき、アクセス効率を定量的に算出できるものであれば、前記演算式に限定する趣旨ではない。また、前記調整係数も、検索方法情報の走査方式の種類に応じて、さらに細分化した係数を設定してもよい。

収集部１１で収集された実行情報、抽出部１２で抽出された取得パターン及び算出部１３で算出された評点に基づき、生成部１４では、チューニング用テーブルを生成する。チューニング用テーブルは、抽出部１２で抽出された各取得パターンをオブジェクト単位に組分けした取得パターン群としてグルーピングするとともに、各取得パターンと各取得パターンに対応する収集部１１で収集された実行情報、及び算出部１３によって算出された評点とを一連のチューニング情報として構成したものである。チューニング用テーブルによって、オブジェクトごとの取得パターン群を一覧し、アクセス効率の悪い取得パターンを容易に特定することが可能となる。また、後述するように、取得パターン群の数は、上記取得パターンの抽出過程からも明らかな通り、ＳＱＬ数と比較して飛躍的に少ない数に絞り込まれるため、短時間で、アクセス効率の悪い箇所を特定でき、チューニング作業の付加を軽減することが可能となる。

さらに、生成部１４は、前記各オブジェクトの取得パターン群から、前記実行情報に基づいて、チューニングの対象となる取得パターンを特定する選出部１４１、選出された取得パターンから、インデックスデータとして選定されていないカラムデータを読み出し、所定の条件に従って当該カラムデータからインデックスデータを選定する選定部１４２とを有し、図８で後述するように、前記チューニング用テーブルに、前記選定したインデックスデータを含めることができる。

図３は、本発明に係るチューニング方法の処理フローを示した図である。以下、図１のチューニング装置１を参照しながら説明する。

リレーショナルデータベースシステムＤに接続されたチューニング装置１を稼働させ、図２で説明した収集部１１の収集タイミングを選択すると、選択されたタイミングに応じて、収集部１１で実行情報が収集される（Ｓ１）。このとき、実行情報の収集元は、データベース本体Ｄ１に格納されたオブジェクトではなく、動的パフォーマンスビューとして表示されるオブジェクトであり、これを定期的に収集する。

収集された実行情報から、抽出部１２により、検索条件情報及び検索方法情報から構成される一対の取得パターンを抽出する（Ｓ２）。さらに、算出部１３により、前記抽出された各取得パターンの検索条件情報に対する検索方法情報のアクセス効率を所定の演算式によって評点として算出してもよい（図示せず）。

収集された実行情報、抽出された取得パターン、さらには、算出された評点に基づき、生成部１４により、チューニング用テーブルを生成する（Ｓ３）。

生成されたチューニング用テーブルは、抽出部１２で抽出された各取得パターンをオブジェクト単位に組分けした取得パターン群としてグルーピングするとともに、各取得パターンと各取得パターンに対応する収集部１１で収集された実行情報、及び算出部１３によって算出された評点とを一連のチューニング情報として形成するが、前記各オブジェクトの取得パターン群から、前記実行情報に基づいて、チューニングの対象となる取得パターンを特定して選出する（Ｓ４）。

前記選出された取得パターンから、インデックスデータとして選定されていないカラムデータを読み出し、所定の条件に従って当該カラムデータから最適なインデックスデータを選定する（Ｓ５）。

ここで、選定されたインデックスデータが、他の取得パターンのアクセス効率に影響するかどうかを判断する（Ｓ６）。影響がある場合は（Ｓ６のＮ）、再度、前記Ｓ５の最適なインデックスの選定を行う。影響がない場合は（Ｓ６のＹ）、全取得パターンのチューニングが終了しているかどうかの確認をし（Ｓ７）、終了していなければ（Ｓ７のＮ）、再度、Ｓ４のチューニング対象の取得パターンの選出を行い、終了していれば（Ｓ７のＹ）、チューニング結果をリレーショナルデータベースシステムＤに反映させて（Ｓ８）、チューニングを終了する。

なお、本実施の形態では、図３のＳ５のインデックスの選定について、前記選定されていないカラムデータの使用回数を優先的選定基準とする第１の基準と、実行回数を優先的選定基準とする第２の基準との２種の選定基準を設けている。

前記第１の基準の処理フローは、図４に示す通りである。第１の基準は、検索条件情報から、カラムの使用頻度を順次絞り込んで最適なインデックスを選定する基準である。

チューニング対象の取得パターンを選出すると（Ｓ４）、選出された取得パターンにインデックスとして選定されていないカラムがあるかどうかを判断する（Ｓ５１１）。選定されていないカラムがない場合（Ｓ５１１のＮ）、選定処理は終了する。一方、選定されていないカラムがある場合（Ｓ５１１のＹ）、使用回数が最大のカラムを選定する（Ｓ５１２）。

前記選定されたカラムと同等のカラムが複数ない場合（Ｓ５１３のＮ）、当該選定されたカラムをインデックスとして追加し（Ｓ５１４）、前記Ｓ５１１からのステップを繰り返す。一方、同等のカラムが複数ある場合（Ｓ５１３のＹ）、検索条件情報の演算子情報で「＝」条件での使用回数が多いカラムを選定する（Ｓ５１５）。係る条件で選定されたカラムと同等のカラムが複数ない場合（Ｓ５１６のＮ）、当該選定されたカラムをインデックスとして追加し（Ｓ５１４）、前記Ｓ５１１からのステップを繰り返す。一方、同等のカラムが複数ある場合（Ｓ５１６のＹ）、実行回数の多いカラムを選定する（Ｓ５１７）。

前記選定されたカラムと同等のカラムが複数ない場合（Ｓ５１８のＮ）、当該選定されたカラムをインデックスとして追加し（Ｓ５１４）、前記Ｓ５１１からのステップを繰り返す。一方、同等のカラムが複数ある場合（Ｓ５１８のＹ）、インデックスを選定せず、既存のインデックスの順番を優先する（Ｓ５１９）。

一方、前記第２の基準の処理フローは、図５に示す通りである。第２の基準は、実行回数が多いカラムを優先して最適なインデックスを選定する基準である。第１の基準との相違は、第１の基準の最初の判断基準であるＳ５１２の使用回数が最大のカラムを選定する処理に代えて、使用回数と実行回数を乗算した結果の合計が最大のカラムを選定する処理の点のみである（Ｓ５２２）。その他の処理手順は、第１の基準と同じである（すなわち、第１の基準のＳ５１１と第２の基準の５２１及び第１の基準のＳ５１３乃至Ｓ５１９と第２の基準のＳ５２３乃至Ｓ５２９は同じである。）

図６は、生成部１４によって生成されたチューニング用テーブルＴ１を示した図である。テーブルの構成は、あくまで例示であって、この構成に限定する趣旨ではない。

チューニング用テーブルＴ１は、テーブル欄Ｔ１１と取得パターン及び実行実績情報から成る欄（Ｔ１１１乃至Ｔ１１９）から構成されている。テーブル欄Ｔ１１は、チューニングの対象となったデータベース本体Ｄ１に格納されているオブジェクトの一覧である。各テーブル名の横の括弧内の数字は、当該テーブルを参照するＳＱＬを前記取得パターンとしてまとめた数を示す。

本実施の形態では、テーブル欄Ｔ１１のトップのテーブルは、「ｔｂ０１（４７）」となっているのでテーブル名「ｔｂ０１」の取得パターンは、４７個あることになる。各テーブルは、括弧内に表示された取得パターン群を有する。そして、所望のテーブルを選択すると（図６では反転表示になっている）、「ｔｂ０１」の４７個の取得パターン及び実行実績情報が各々一連のチューニング情報（タプル）として表示される。すなわち、番号欄Ｔ１１１、取得パターン欄Ｔ１１２、評点欄Ｔ１１３、ＳＱＬ数欄Ｔ１１４、実行数欄Ｔ１１５、経過時間欄Ｔ１１６、ＣＰＵ時間欄Ｔ１１７、待機時間欄Ｔ１１８、ブロック数欄Ｔ１１９に表示されたデータから構成された情報を閲覧することができる。なお、取得パターン欄Ｔ１１２は、検索条件情報欄Ｔ１１２ａと検索方法情報欄Ｔ１１２ｂとから構成される。検索条件情報欄Ｔ１１２ａの検索条件情報は、カラムデータ（例えば、店舗コードを示す「ＴＥＮＰＯ＿ＣＯＤＥ」、日付コードを示す「ＹＭ」「ＹＭＤ」）及び演算子データ（例えば、「＝」「＜」「＞」）で特定される。検索方法情報欄Ｔ１１２ｂの検索方法情報は、インデックスデータ（例えば「ｔｂ０１＿ｉｎｄｅｘ０１」）及び走査方式データ（例えば「ＩＮＤＥＸ＿ＲＡＮＧＥ＿ＳＣＡＮ」）で特定される。なお、走査方式が、インデックスを使用せず、全表走査の場合は、インデックスデータは表示されず、例えば「ｔｂ０１＿ＴＡＢＬＥ＿ＡＣＣＥＳＳ＿ＦＵＬＬ」という表示で特定される。

取得パターンは、実行情報のうち、実行計画情報から抽出されて取得されるが、図７は、図６の取得パターン中、順番１の 実行計画情報Ｐを示す図である。Ｐ１は、所定のインデックスから選別されたデータの特別な走査方式でテーブルにアクセスすることを示している。この特別な走査方式は、データベース内にデータ・ファイル、データ・ブロック及びレコードの番号をピンポイントで特定するもの（ＲＯＷＩＤ）であり、これを指定してアクセスすると、直接目的のレコードを含むデータ・ブロックへのアクセスが可能となるため、高速の検索を実現することができる。Ｐ２は、Ｐ１の所定のインデックス、走査方式を示している（ＩＮＤＥＸ ＲＡＮＧＥ ＳＣＡＮ）。また、Ｐ３は、Ｐ１のデータフィルタリング情報、Ｐ４は、Ｐ２の詳細実行情報を示している。

図８は、図６のチューニング対象となる取得パターンが使用しているインデックス情報テーブルＴ２であり、チューニング用テーブルの一部を成すものである。インデックス情報テーブルＴ２は、番号欄Ｔ２１１、インデックス名欄Ｔ２１２、インデックスの使用数欄Ｔ２１３、カラム欄Ｔ２１４及びＴ２１５、改善インデックス欄Ｔ２１６、Ｓ Ｑ Ｌ 数欄Ｔ２１７、実行数欄Ｔ２１８、経過時間欄Ｔ２１９、ＣＰＵ時間欄Ｔ２２０、待機時間欄Ｔ２２１、ブロック数欄Ｔ２２２から構成される。

評点を参照すると、番号欄Ｔ１１１の１番目は、３３であるため、改善の余地があると判断される。そこで、チューニング対象の取得パターンとしてこれを選出すると、その取得パターンのインデックス情報テーブルＴ２（図８）が表示されるようになっている。なお、この選出は、評点の閾値を設定しておき、閾値以下の取得パターンが自動的に選出され、対応するインデックス情報テーブルＴ２が表示されるようにしてもよい。チューニングによる最適インデックスは、図６の検索条件情報、検索方法情報、図８の現行使用しているインデックス名、カラムに基づいて選定が行われる。選定されたインデックスが図６の他の取得パターンに影響を与えるか否かを図６の検索条件情報から判断し、影響範囲を考慮の上、最終的に最適インデックスが決定される。

図６の順番１の取得パターンはテーブル「ＴＢ０１」に対し、以下のように特定店舗コードの特定日のデータを参照している（下記の通り、使用インデックス詳細情報Ｐ４ 、データフィルタリング情報Ｐ３から判断可能である）。
ｆｉｌｔｅｒ（（“ＴＢ０１”.“ＹＭ”='２０１００７' ＡＮＤ “ＴＢ０１”.“ＹＭＤ”＝ＴＯ＿ＣＨＡＲ（ＬＡＳＴ＿ＤＡＹ（ＴＯ＿ＤＡＴＥ（“ＴＢ０１”.“ＹＭ”｜｜‘０１’、‘ｙｙｙｙｍｍｄｄ’））、‘ｙｙｙｙｍｍｄｄ’）））
ａｃｃｅｓｓ（“ＴＢ０１”.“ＴＥＭＰＯ＿ＣＯＤＥ”＝‘００００００１９３９’）

上記取得パターンは、図６の順番１の検索方法情報と図８の順番１のインデックスのカラム情報から店舗コード（ＴＥＭＰＯ＿ＣＯＤＥ）のみを参照し、データを選別しているので特定の店舗コードの全てのデータを読み取っているという非効率が発生していることがわかる。

そこで、図８のインデックス情報テーブルＴ２の改善インデックス欄Ｔ２１６では、図６の順番１の検索条件情報を参照し、「基準１（ＹＭ）（ＹＭＤ）」のインデックスを最適インデックスカラムとして追加することを提示している。最適インデックスカラムとして「ＹＭ」、「ＹＭＤ」を追加すれば、図６の順番１のアクセスパターンの特定店舗コードの全てのデータを読み取る非効率は解消され、特定店舗コードの特定日データを取得することによりアクセス効率は改善される。

なお、最適インデックスカラムの追加のとき、図８のインデックス情報テーブルＴ２の使用数欄Ｔ２１３を参照すると、同等のインデックスが、４か所で使用されていることがわかる。最終的には、これら４つの影響範囲を考慮して最適インデックスカラムの追加の選定を決定すればよい。

図９は、取得パターンの検索条件情報から検索時の使用回数が多い順にカラムデータをソートしたテーブルＴ３である。オブジェクトの設計時に行われる複数の段階のテスト（例えば、単体テスト、結合テスト及び総合テストなど）において、図６の場合同様、前記実行情報の収集と前記取得パターンの抽出を順次実行し、設計時のチューニング用テーブルを生成する。そして、生成部１４は、抽出された取得パターンの検索条件情報Ｔ３１をカラムデータごとに分解し、前記各テスト段階の検索において使用回数が多い順に前記カラムデータをソートしたテーブルＴ３４を生成する。一般に、リレーショナルデータベースにおいて、インデックスは一番多く使用されているカラムに設定することを原則としているので、テーブルＴ３４から、「ＹＭＤ」をインデックスカラムとして最優先で設定できるということが分かる。

ところで、リレーショナルデータベースシステムＤには、各ＳＱＬに自動的にＩＤを付与し、当該ＩＤがどのようなアクセスをするか追跡可能なものがあるが、例えば、検索条件が変わるたびに、新たなＩＤが付与されるため、前記ＩＤでは、ある項目の検索状況の追跡又は特定の開発者が設定したＳＱＬの評価を行う場合など、特定の目的による追跡、評価を正確に行うことができない。

そこで、チューニング装置１は、係る追跡を正確ならしめるために、所定のＳＱＬ群に不動のＩＤを付与するＩＤ付与部を有するものとしてもよい（図示せず）。ＩＤ付与部は、例えば、ＳＱＬ文において、所定の目的で発行される１以上のコマンド群に付されたクエリオプティマイザに対する指示、コマンドの説明（以下「コメント等」という。）のように、所定の記号（通常、スラッシュ及びアスタリスク）によって囲まれ、コマンドの実行後でも自動的に変更されないテキストに対してＩＤを付与するようにすればよい。コメント等の末尾の特定桁分をＩＤとして認識できるように設定すればよい。

係るＩＤを付与されたコマンド群は、前記のように新たなＩＤが付与されることなく維持されるため、当該ＩＤによって正確な追跡が可能となる。チューニング装置１では、係るＩＤを検索すると、生成部１４において、当該ＩＤで特定されるコマンド群の実行情報と取得パターンを表示するテーブルが生成され、これを閲覧可能とすれば、上記追跡を正確に行うことができる。

リレーショナルデータベースシステムＤの本番環境での稼働時において、新たなデータの登録、削除、定義の変更が発生したときに、当該発生の前後における２つのチューニング用テーブルの差分、すなわち、従前の取得パターンにない新たな取得パターンの発生を特定して表示させ、当該特定表示された取得パターンのうち、評点が、所定の閾値以下のものについて、最適なインデックスの検討を行うことができるようにしてもよい（図示せず）。

また、前記実行情報の収集を動的パフォーマンスビューから、チューニング装置１側に設けたリポジトリに定期的に収集する形態に代えて、リレーショナルデータベースシステムＤから直接収集するようにしてもよい（図示せず）。この構成によれば、前記選定したインデックスデータを介して前記リレーショナルデータベースで検索のシミュレーションを行うと、前記選定されたインデックスを適用する前後の実行情報が閲覧可能となり、併せてデータ分布情報を提供することができ、チューニングの成果をダイレクトかつ迅速に取得することができる。

以下、本発明に係るチューニング装置１を所定の条件下で稼働させた場合の作業量と、チューニング装置１を使用せず、ＳＱＬ単位でのチューニングを行った場合の作業量の比較を示す。作業期間は、３カ月であり、リレーショナルデータベースの規模は、ＳＱＬ数が１，０００，０００、テーブル数が１，４００であり、作業を行った技術者のランクは、いずれも同じである（少なくとも、ＳＱＬ単位のチューニングについては、予め学習する必要がないスキルを有している）。

表１からも明らかな通り、チューニング装置１の環境構築、利用方法の理解に１０人日の作業量を要しているにもかかわらず、実作業フェーズ（分析、運用・監視）段階では、すべてにおいてチューニング装置１を使用した方が、効率的に作業を完了しており、特に、分析フェーズの機能別の作業では顕著な仕事量の差が認められた。

１ チューニング装置
１１ 収集部
１２ 抽出部
１３ 算出部
１４ 生成部
１１１ 算定部
１４１ 選出部
１４２ 選定部
Ａ ユーザ端末
Ｄ リレーショナルデータベースシステム
Ｄ１ データベース本体
Ｄ２ データベース管理システム
Ｔ１ チューニング用テーブル
Ｔ２ インデックス情報テーブル

Claims (17)

1. リレーショナルデータベースのパフォーマンスを分析及び改善するチューニング装置であって、
   前記リレーショナルデータベースに対して所定の照会言語を介して発行されたすべてのコマンドが、データベースマネージメントシステムで実行されたときの所定の実行情報を収集する収集手段と、
   前記各コマンドの実行によってデータの検索結果を取得するための検索条件情報及び検索方法情報を一対の取得パターンとして抽出する抽出手段と、
   前記抽出された各取得パターンを前記リレーショナルデータベースのオブジェクト単位に組分けした取得パターン群として一覧可能にグルーピングするとともに、各取得パターンと各取得パターンに対応する前記収集された実行情報とを一連のチューニング情報として構成したチューニング用テーブルを生成する生成手段と、を有することを特徴とするチューニング装置。
   
2. 前記抽出手段は、少なくとも、前記データベースマネージメントシステムによって作成された実行計画情報から前記各取得パターンを抽出することを特徴とする請求項１記載のチューニング装置。
3. 前記検索条件情報は、検索対象を絞り込むためのカラムデータと該カラムデータに対する検索条件を前記照会言語で表記した演算子データによって特定し、前記検索方法情報は、前記検索対象を絞り込むためのカラムデータに対して設定されたインデックスデータと前記オブジェクトに対して設定された検索経路を示す走査方式データによって特定することを特徴とする請求項１又は請求項２記載のチューニング装置。
4. 前記収集手段が収集する実行情報は、前記実行計画情報のほか、少なくとも、前記各取得パターンの対象となるオブジェクトを参照するための前記照会言語のコマンド数、実行回数、処理の経過時間、ＣＰＵの使用時間、待機時間からなる実行実績情報を含むことを特徴とする請求項２又は請求項３記載のチューニング装置。
5. 前記収集手段は、前記リレーショナルデータベースが稼働中に、該リレーショナルデータベースに実際に格納されているオブジェクトとは別に、継続的に更新される仮想のテーブルから前記実行情報を定期的に収集し、時系列に管理することを特徴とする請求項１から請求項４までのいずれか１項に記載のチューニング装置。
6. 前記収集手段は、前記実行実績情報を、前記リレーショナルデータベース稼働時からの累計データの収集と、前記収集された累計データから所定の算定手段によって得られた前記リレーショナルデータベース稼働後の特定の期間内のデータの収集との２種類のデータを収集可能とすることを特徴とする請求項４又は請求項５記載のチューニング装置。
7. 前記各取得パターンの検索条件情報に対する検索方法情報のアクセス効率を所定の演算式によって評点として算出する算出手段を備え、前記生成手段は、算出された前記各評点情報を前記実行情報に含めることを特徴とする請求項２から請求項６までのいずれか１項に記載のチューニング装置。
8. 前記生成手段は、前記各オブジェクトの取得パターン群から、前記実行情報に基づいて、チューニングの対象となる取得パターンを特定する選出手段と、選出された取得パターンから、インデックスデータとして選定されていないカラムデータを読み出し、所定の条件に従って当該カラムデータからインデックスデータを選定する選定手段とを有し、前記チューニング用テーブルに選定したインデックスデータを含めることを特徴とする請求項３から請求項７までのいずれか１項に記載のチューニング装置。
9. 前記選定手段は、少なくとも、前記実行実績情報から、前記選定されていないカラムデータの使用回数を優先的選定基準とする第１の基準と、実行回数を優先的選定基準とする第２の基準との２種の選定基準を備え、前記生成手段は、前記チューニング用テーブルから、前記２種の選定基準によって選定されたインデックスデータを選択可能としたものであることを特徴とする請求項８記載のチューニング装置。
10. 前記生成手段は、前記選出手段によって特定された取得パターンのインデックスデータと同一のインデックスデータが、前記取得パターン群のいずれかで設定されている数を前記特定された取得パターンに対応させて表示することを特徴とする請求項８又は請求項９記載のチューニング装置。
11. 所定の目的で発行される１以上のコマンド群に付されたクエリオプティマイザに対する指示又はコマンドの説明であって前記コマンドの実行後でも自動的に変更されないテキストに対して、前記ファイルを特定するＩＤを付与するＩＤ付与手段を有し、前記生成手段は、前記付与されたＩＤによって特定される前記ファイルにおける前記取得パターンを閲覧可能とすることを特徴とする請求項１から請求項１０までのいずれか１項に記載のチューニング装置。
12. リレーショナルデータベースのパフォーマンスを分析及び改善するチューニング方法であって、
    前記リレーショナルデータベースに対して所定の照会言語を介して発行されたすべてのコマンドが、データベースマネージメントシステムで実行されたときの所定の実行情報を収集するステップと、
    前記各コマンドの実行によってデータの検索結果を取得するために、検索対象を絞り込むためのカラムデータと該カラムデータに対する検索条件を前記照会言語で表記した演算子データによって特定された検索条件情報及び前記検索対象を絞り込むためのカラムデータに対して設定されたインデックスデータと前記オブジェクトに対して設定された検索経路を示す走査方式データによって特定された検索方法情報を一対の取得パターンとして抽出するステップと、
    前記抽出された各取得パターンを前記リレーショナルデータベースのオブジェクト単位に組分けした取得パターン群として一覧可能にグルーピングするとともに、各取得パターンと各取得パターンに対応する前記収集された実行情報とを一連のチューニング情報として構成したチューニング用テーブルを生成するステップとを有し、
    前記収集は、前記リレーショナルデータベースが稼働中に、該リレーショナルデータベースに実際に格納されているオブジェクトとは別に、継続的に更新される仮想のテーブルから前記実行情報を定期的に収集し、専用のリポジトリに格納するとともに、時系列に管理することによって行われることを特徴とするチューニング方法。
    
13. 前記各取得パターンの検索条件情報に対する検索方法情報のアクセス効率を所定の演算式によって評点として算出するステップを有し、算出された前記各評点情報を前記実行情報に含めることを特徴とする請求項１２記載のチューニング方法。
14. 前記各オブジェクトの取得パターン群から、前記実行情報に基づいて、チューニングの対象となる取得パターンを特定して選出するステップと、選出された取得パターンから、インデックスデータとして選定されていないカラムデータを読み出し、所定の条件に従って当該カラムデータからインデックスデータを選定するステップとを有し、前記チューニング用テーブルに前記選定したインデックスデータを含めることを特徴とする請求項１２又は請求項１３記載のチューニング方法。
15. 前記オブジェクトの設計時に行われる複数の段階のテストにおいて、前記実行情報の収集と前記取得パターンの抽出を順次実行するとともに、前記チューニング用テーブルに加えて、前記抽出された取得パターンの検索条件情報から、前記カラムデータごとに分解し、検索時の使用回数が多い順に前記カラムデータをソートしたテーブルを生成することを特徴とする請求項１２から請求項１４までのいずれか１項に記載のチューニング方法。
16. 前記リレーショナルデータベースの本番環境での稼働時において、新たなデータの登録、削除、定義の変更が発生したときに、当該発生の前後におけるチューニング用テーブルの差分から新たに発生した取得パターンを特定することを特徴とする請求項１２から請求項１４までのいずれか１項に記載のチューニング方法。
17. 前記実行情報は、前記仮想のテーブルからの定期的な収集に代えて、前記リレーショナルデータベースから直接収集するものとし、前記選定したインデックスデータを介して前記リレーショナルデータベースで検索のシミュレーションを行うと、前記選定されたインデックスを適用する前後の前記実行情報に基づくデータ分布を閲覧可能とすることを特徴とする請求項１２から請求項１４までのいずれか１項に記載のチューニング方法。
    

Images