JP6613357B2 - 統計的ｓｑｌパターン分析を通じてのｓｑｌチューニング自動化方法およびシステム - Google Patents

Description

本発明はＳＱＬチューニング自動化方法およびシステムに関するものであって、さらに詳細には、クライアントとデータベース（Ｄａｔａｂａｓｅ）間に送受信されるネットワークストリーム（Ｎｅｔｗｏｒｋ Ｓｔｒｅａｍ）からＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ：構造化質疑語、以下「ＳＱＬ」とする。）を収集してＳＱＬの処理時間、データの大きさなどを分析し、これを利用して収集されたＳＱＬの改善案を提案する、ＳＱＬチューニング自動化方法およびシステムに関するものである。

情報化時代を越えてモバイル時代への発展に伴い、データベース管理システム（ＤＢＭＳ：Ｄａｔａｂａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）の使用量が再び急増している。これに伴い、データベースを使用するシステムが多くなり、ソフトウェアの開発周期が次第に短くなることによって、データベースの性能管理に多くの費用が発生し、人によるデータベースの管理が限界となってデータベースの性能管理に専門化されたシステムが要求されている。

特許文献１に開示された「データベースシステムに接続せずにデータベースシステムをモニタリングする方法」は、ネットワークプロトコルによりデータパケットが送受信される時、モニタリングプロセスによるスニッフィング（Ｓｎｉｆｆｉｎｇ）を通じて、データパケットを収集して運営サーバーとクライアント応用プロセス間に伝送されるすべてのＳＱＬ情報およびデータベースの性能情報を抽出するものである。

また、特許文献２に開示された「自動生成されたＳＱＬ構文に対する自動チューニング方法および装置」は、ソースサーバーに保存されたデータに対するソース位置識別情報とデータがターゲットサーバーに保存される位置に対するターゲット位置識別情報を抽出する段階と、データをターゲットサーバーに移管させるための構文を含む移管ロジックにソース位置識別情報とターゲット位置識別情報を適用してマッピングロジックを生成する段階と、生成されたマッピングロジックによりデータの移管を遂行する場合の移管速度よりも早くデータの移管が実行されるように、マッピングロジックに含まれた条件文を再構成する段階を含む。

ところが、このような従来のモニタリングシステムは、プロキシ方式への適用が難しく、データの移管作業などの特定の作業にその機能が限定されるため、より向上した統計的技法を適用したモニタリングシステムに対する要求が増加している。

韓国登録特許第１０−０４８１１３０号公報 韓国登録特許第１０−１７３７５７８号公報

本発明の目的は、クライアント端末機とデータベース間に送受信されるＳＱＬを含むトランザクション情報および応答時間、処理結果などをスニッフィング方式とプロキシ方式で抽出し、これを利用してデータベースの現状と性能の問題を分析して改善案を提案できる、統計的ＳＱＬパターン分析を通じてのＳＱＬチューニング自動化方法およびシステムを提供することである。

また、本発明の他の目的は、従来、データベースの性能に問題が発生すると、人によってその原因を分析して改善案を模索し、改善案の反映に長時間がかかる構造を改善するために、常時モニタリングしつつ改善案を模索し、必要に応じて改善案を検証することまでの全過程をシステム化して、性能に問題が発生した時に迅速に対応しながらもデータベースシステムに殆ど負荷を与えない、統計的ＳＱＬパターン分析を通じてのＳＱＬチューニング自動化方法およびシステムを提供することである。

本発明の一見地に係るシステムは、データベースを運営する運営サーバーと、クライアントと前記運営サーバー上のデータベース（Ｄａｔａｂａｓｅ）間に送受信されるネットワークストリームからＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）を含むトランザクション情報および応答時間、処理結果を抽出して性能をモニタリングしつつ、性能低下の原因を分析して改善案を提供するモニタリングサーバーで構成される。

前記モニタリングサーバーのスニッフィングモジュールは、クライアントと前記運営サーバー間に送受信されるパケットをキャプチャーし、プロキシモジュールはクライアントと前記運営サーバー間の連結を中継しパケットを収集する。パケット分析モジュールは、スニッフィングモジュールとプロキシモジュールによってキャプチャーされたパケットを分析してトランザクション情報を抽出する。

トランザクション分析モジュールは、抽出されたトランザクション情報からユーザー情報、接続ＤＢＭＳサーバー、ＳＱＬと該当ＳＱＬで使われたテーブル、カラム、関数、データ量、条件節、ジョインテーブル、処理結果、処理時間を分析してＳＱＬ属性情報をリポジトリに保存する。

オプティマイジングモジュールは、前記リポジトリに保存された処理時間の平均を基準に早いＳＱＬグループと遅いＳＱＬグループに区分し、類義語辞典と過去の最適化内訳を参照して同一テーブルに対するＳＱＬ特性を分析した後、遅いＳＱＬに早いＳＱＬの特性を反映して改善案を提供する。

検証モジュールは、前記改善案と元のＳＱＬとを実際のデータベースで比較検証する。

本発明の他の見地に係る方法は、性能モニタリングサーバーがユーザーとデータベース間のパケット送受信時にネットワークからパケットを獲得する第１段階と、前記獲得したパケットを分析してトランザクション情報を抽出する第２段階と、前記抽出したトランザクション情報からユーザー情報、接続ＤＢＭＳサーバー、ＳＱＬおよびＳＱＬで使われたテーブル、カラム、関数、条件節、ジョインテーブルおよび結果値、所要時間および統計を計算する第３段階と、前記分析されたデータを利用して性能改善案を模索する第４段階と、前記改善案を検証する第５段階を含めて監視対象データベースをモニタリングし、性能低下の原因を分析して改善案を提案することを特徴とする。

前記性能改善案を模索する第４段階は、ＳＱＬで使われたテーブル、カラム、関数、条件節、ジョインテーブル、結果値、所要時間などを確認する段階と、前記各値をＳＱＬの属性としてデータマイニング方式を利用して所要時間とＳＱＬ属性値の関係を抽出する段階と、抽出した所要時間とＳＱＬ属性値を利用して該当原因に対してあらかじめ定義された改善案を適用して新しいＳＱＬを生成する段階を含む。

前記ネットワークからパケットを獲得する第１段階は、スニッフィング（Ｓｎｉｆｆｉｎｇ）方式とプロキシ（Ｐｒｏｘｙ）方式を利用する。

本発明に係るＳＱＬチューニング自動化方法は、スニッフィング方式とプロキシ方式を利用することによってデータベース運営システムの性能に影響を与えずにユーザーとデータベース間に伝送されるパケットの獲得が可能であり、これを利用して性能低下の原因を探索し、持続的にデータベースの監視と性能の改善を殆ど自動化して管理者の負担を減らし、ＤＢＭＳ運営費用と時間を節約することができる。

また、既存の方式とは異なり、カタログを参照せず統計的な方式を利用することによって、システムカタログの支援が足りないＤＢＭＳも同様に支援が可能であるとの効果がある。

本発明の実施例に係るデータベースの性能モニタリングシステムの概略図。 本発明の実施例に係る性能モニタリングサーバーの細部構成を図示した構成ブロック図。 本発明の実施例に係る性能モニタリングシステムでパケットをキャプチャーおよび選別してトランザクション情報を抽出し、改善案を模索するフローチャート。 本発明の実施例に係る性能モニタリングシステムで改善案を摸索する詳細フローチャート。 本発明の実施例に係る改善案の検証手続きを図示したフローチャート。

本発明と本発明の実施によって達成される技術的課題は、下記で説明する本発明の好ましい実施例によって、より明確となるはずである。下記の実施例は単に本発明を説明するために例示されたものに過ぎず、本発明の範囲を制限するためのものではない。

図１は、本発明の実施例にしたがって、別途の性能モニタリングサーバー１２０を利用してスニッフィング方式によりパケットをキャプチャーするか、又は、プロキシ方式により接続を中継しつつパケットを収集してデータベースの性能をモニタリングし改善するための自動チューニングシステムの概略図である。

本発明の実施例に係るスニッフィング方式とプロキシ方式のネットワークパケット収集方法を利用したデータベースの性能モニタリングおよびＳＱＬチューニング自動化システム１００は、図１に図示された通り、データベースを運営する運営サーバー１１０と、データベース１１１とインターネット３０を通じて通信する複数のクライアント２０−１〜２０−Ｎ、ネットワークストリームで運営サーバー１１０のＤＢＭＳ１１１とクライアント２０−１〜２０−Ｎ間のトランザクション情報を抽出してモニタリングするモニタリングサーバー１２０で構成される。

図１を参照すると、ユーザーはクライアント端末機２０−１〜２０−Ｎを利用して運営サーバー１１０のＤＢＭＳ１１１に接続したり、モニタリングサーバーのプロキシモジュール１２８を通じて運営サーバーのＤＢＭＳに接続したりすることができる。モニタリングサーバー１２０は、ネットワークストリームでスニッフィング方式でキャプチャーしたパケットと、プロキシモジュール１２８を通じて運営サーバー１１０に接続する時に収集されたパケット１４３でトランザクション情報を抽出し分析して改善案をユーザーに提供する。

図２は、本発明の実施例に係るデータベース性能モニタリングサーバー１２０の細部構成を図示した構成ブロック図である。

本発明の実施例に係る性能モニタリングサーバー１２０は、図２に図示された通り、スニッフィングモジュール１２１、パケット分析モジュール１２２、トランザクション分析モジュール１２３、オプティマイザーモジュール１２４、検証モジュール１２５、リポジトリ１２６、プロキシモジュール１２８で構成される。

図２を参照すると、スニッフィングモジュール１２１は、クライアント２０と運営サーバー１１０間に送受信されるパケット１４１をキャプチャーし、プロキシモジュール１２８は、クライアント２０と運営サーバー１１０間の接続を中継しつつパケット１４３を収集する。

パケット分析モジュール１２２は、スニッフィングモジュール１２１でキャプチャーされたパケット１４２とプロキシモジュール１２８で収集されたパケット１４３を分析してトランザクション情報を抽出する。

トランザクション分析モジュール１２３は、収集されたパケット１４２、１４３から抽出されたトランザクション情報を利用して性能の分析および改善案の探索に必要とされる情報を抽出してリポジトリ１２６にテーブル形態で保存する。すなわち、トランザクション分析モジュール１２３は、各セッションのユーザー、要請したＳＱＬ、該当ＳＱＬのテーブル、カラム、使われた関数、ジョインテーブル、照会結果のデータの大きさ、処理時間のようなＳＱＬ属性情報を探し、統計値を計算してリポジトリ（Ｒｅｐｏｓｉｔｏｒｙ、１２６）に保存する。リポジトリ１２６に保存されたＳＱＬ属性情報テーブルの例は下記の表１の通りである。

オプティマイザーモジュール１２４は、収集されたＳＱＬと各種データ、統計値と処理時間の相関関係を探索し、速度低下の原因を分析して該当原因に対してあらかじめ定義された改善案を反映したＳＱＬを提供する。例えば、オプティマイザーモジュール１２４は、処理時間の平均値を基準に早いＳＱＬグループと遅いＳＱＬグループに区分し、類義語辞典と過去の最適化内訳を参照して同一テーブルに対するＳＱＬの特性を分析した後、遅いＳＱＬに早いＳＱＬの特性を反映する。

検証モジュール１２５は、リポジトリ（Ｒｅｐｏｓｉｔｏｒｙ；１２６）に保存された元のＳＱＬと改善されたＳＱＬをＤＢＭＳ１１１で比較テストして改善されたかどうかを確認し、結果値をオプティマイザーモジュール１２４にフィードバックして性能の改善に参考できるようにする。

図３は、本発明の実施例に係る性能モニタリングシステムでパケットをキャプチャーおよび選別してトランザクション情報を抽出し、改善案を模索するフローチャートである。

図３を参照すると、クライアント端末２０−１〜２０−ＮがＤＢＭＳ１１１にＳＱＬを伝送すると、スニッフィングモジュール１２１やプロキシモジュール１２８がパケットをキャプチャーする（Ｓ１０１、Ｓ１０２）。引き続き、パケット分析モジュール１２２がキャプチャーされたパケットからトランザクション情報を抽出し、抽出されたトランザクション情報から統計値を計算する（Ｓ１０３、Ｓ１０４）。その後、統計値を利用して改善案を模索し、改善案を検証した後、改善されたかを確認して改善されていると改善案をレポーティングし、改善されていないと統計値を利用した改善案の摸索を繰り返す（Ｓ１０５〜Ｓ１０７）。

引き続き、データベースの性能モニタリングシステムで改善案を模索する方法を図４と図５を参照して説明する。

図４は、本発明の実施例に係る性能モニタリングシステムで性能の改善案を模索するフローチャートである。

オプティマイザーモジュール１２４は、トランザクション分析モジュール１２３で抽出した各ＳＱＬのテーブル、カラム、関数、データの大きさ、ジョインテーブル、所要時間などの値を使用する。前述したテーブル、カラムなどの値をＳＱＬの属性といい、データマイニング技法を利用して所要時間とＳＱＬ属性値間の相関関係を探し出して処理が長くかかるスロークエリ（Ｓｌｏｗ Ｑｕｅｒｙ）の原因を探し、該当原因の分類に沿ってあらかじめ定義された改善案を適用した新しいＳＱＬを提供する。

図４を参照すると、オプティマイザーモジュール１２４は、トランザクション情報からテーブル、カラム、関数、データ量、条件節、ジョインテーブル、所要時間（処理時間）のような属性を抽出し、データマイニング技法を通じて性能低下の原因を分析する（Ｓ１１１、Ｓ１１２）。引き続き、該当原因に対する改善案を確認し、改善案が適用されたＳＱＬを提案する（Ｓ１１３、Ｓ１１４）。

例えば、オプティマイザーモジュール１２４は、処理時間の平均値を基準に早いＳＱＬグループと遅いＳＱＬグループにグループ化し、類義語辞典と過去の最適化内訳を参照して同一テーブルに対するＳＱＬの特性を分析した後、遅いＳＱＬに早いＳＱＬの特性を反映して改善案を提供する。

図５は、本発明の実施例にしたがってオプティマイザーで生成された改善案の実際の検証を遂行する検証モジュールの動作フローチャートである。

図５を参照すると、改善案の検証モジュール１２５は、リポジトリ（Ｒｅｐｏｓｉｔｏｒｙ；１２６）で改善対象ＳＱＬと改善されたＳＱＬを確認し、検証対象ＤＢＭＳ１１１に接続して元のＳＱＬと改善されたＳＱＬを実行した後、実行結果を比較測定して改善の有無を検証する（Ｓ１２１〜Ｓ１２４）。

その後、測定結果を記録すると共に、改善が確認されたＳＱＬは最終的にモニタリングシステムの管理者コンソール１２７で確認し、これを実際のユーザーであるクライアント端末２０−１〜２０−Ｎに伝達してデータベースの性能低下の原因を除去することができる（Ｓ１２５）。

以上、本発明において実施例を参照して説明したが、本技術分野の通常の知識を有する者であれば、これから多様な変形および均等な他の実施例が可能であることが理解できるはずである。したがって、本発明の権利範囲はこれに限定されず、下記の特許請求の範囲で定義している本発明の基本概念を利用した当業者の多様な変形および改良形態も本発明の権利範囲に属するものである。

２０−１〜２０−Ｎ：クライアント端末機
３０：インターネット
１００：運営環境
１１０：運営サーバー
１１１：データベース
１２０：モニタリングサーバー
１２１：スニッフィングモジュール
１２２：パケット分析モジュール
１２３：トランザクション分析モジュール
１２４：オプティマイザーモジュール
１２５：検証モジュール
１２６：リポジトリ
１２７：管理者コンソール
１２８：プロキシモジュール
１４１、１４２、１４３：パケット

Claims (3)

1. データベースを運営する運営サーバーと、クライアントと前記運営サーバーのデータベース（Ｄａｔａｂａｓｅ）間に送受信されるネットワークストリームからＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）を含むトランザクション情報および応答時間、処理結果を抽出して性能をモニタリングしつつ、性能低下の原因を探して改善案を提供するモニタリングサーバーを含む統計的ＳＱＬパターン分析を通じてのＳＱＬチューニング自動化システムにおいて、
   前記モニタリングサーバーが
   クライアントと前記運営サーバー間に送受信されるパケットをキャプチャーするスニッフィングモジュールと、
   クライアントと前記運営サーバー間の連結を中継しパケットを収集するプロキシモジュールと、
   前記スニッフィングモジュールと前記プロキシモジュールによってキャプチャーされたパケットを分析してトランザクション情報を抽出するパケット分析モジュールと、
   前記抽出したトランザクション情報からユーザー情報、接続ＤＢＭＳサーバー、ＳＱＬと該当ＳＱＬで使われたテーブル、カラム、関数、データ量、条件節、ジョインテーブル、処理結果、処理時間を分析してＳＱＬ属性情報をリポジトリに保存するトランザクション分析モジュールと、
   前記リポジトリに保存された処理時間の平均を基準に早いＳＱＬグループと遅いＳＱＬグループに区分し、同義語辞典と過去の最適化内訳を参照して同一テーブルに対するＳＱＬの特性を分析した後、遅いＳＱＬに早いＳＱＬの特性を反映して改善案を提供するオプティマイジングモジュールと、
   前記改善案と元のＳＱＬを実際のデータベースで比較検証する検証モジュールと、を備え、
   対象データベースの性能をモニタリングし性能低下の原因を分析して改善案を提案できることを特徴とする、統計的ＳＱＬパターン分析を通じてのＳＱＬチューニング自動化システム。
2. 性能モニタリングサーバーがユーザーとデータベース間のパケット送受信時にネットワークからパケットを獲得する第１段階と、
   性能モニタリングサーバーが前記獲得したパケットを分析してトランザクション情報を抽出する第２段階と、
   性能モニタリングサーバーが前記抽出したトランザクション情報からユーザー情報、接続ＤＢＭＳサーバー、ＳＱＬと該当ＳＱＬで使われたテーブル、カラム、関数、データ量、条件節、ジョインテーブル、処理結果、処理時間を分析してＳＱＬ属性情報をリポジトリに保存する第３段階と、
   性能モニタリングサーバーが前記リポジトリに保存された処理時間の平均を基準に早いＳＱＬグループと遅いＳＱＬグループに区分し、同義語辞典と過去の最適化内訳を参照して同一テーブルに対するＳＱＬの特性を分析した後、遅いＳＱＬに早いＳＱＬの特性を反映して改善案を提供する第４段階と、
   前記改善案を検証する第５段階と、
   を含み、
   監視対象データベースをモニタリングし性能低下の原因を分析して改善案を提案することを特徴とする、統計的ＳＱＬパターン分析を通じてのＳＱＬチューニング方法。
3. 前記ネットワークからパケットを獲得する第１段階は、
   スニッフィングモジュールがクライアントと前記運営サーバー間に送受信されるパケットをキャプチャーするか、プロキシモジュールがクライアントと前記運営サーバー間の連結を中継しつつパケットを収集することを特徴とする、請求項２に記載の統計的ＳＱＬパターン分析を通じてのＳＱＬチューニング方法。

Images