(57)【要約】【課題】データベースに格納したデータの配置を考慮に入れてチューニング情報をサンプリングして取得することで、チューニング情報の取得時間を抑えつつ、チューニングの精度を保ち、トランザクションのスループット低下を防止する。【解決手段】データベースにデータを格納する際に、直前の行と同じページに格納される行の密度を示すクラスタ率を算出するステップと、前記算出したクラスタ率によりスキャン対象ページを決定してデータを取得し、その取得したデータを基にチューニング情報を算出するステップと、前記算出したチューニング情報を用いてデータベースへのアクセスをチューニングする為の実行プランを決定し、その実行プランを実行することでデータベース処理を行うステップとを有するものである。【選択図】        図１
2004234066.tif 000002
【特許請求の範囲】
【請求項１】
チューニング情報をサンプリングにより取得してデータベース処理をチューニングするデータベース管理方法において、
データベースにデータを格納する際に、直前の行と同じページに格納される行の密度を示すクラスタ率を算出するステップと、前記算出したクラスタ率によりスキャン対象ページを決定してデータを取得し、その取得したデータを基にチューニング情報を算出するステップと、前記算出したチューニング情報を用いてデータベースへのアクセスをチューニングする為の実行プランを決定し、その実行プランを実行することでデータベース処理を行うステップとを有することを特徴とするデータベース管理方法。
【請求項２】
前記算出したクラスタ率により決定されるスキャン対象ページを提示した後、スキャン対象ページの指定をユーザから受け付けて、その受け付けたスキャン対象ページによりチューニング情報を算出することを特徴とする請求項１に記載されたデータベース管理方法。
【請求項３】
前記取得したデータの種別に合わせてチューニング情報の算出手法を選択してチューニング情報の算出を行うことを特徴とする請求項１または請求項２のいずれかに記載されたデータベース管理方法。
【請求項４】
チューニング情報をサンプリングにより取得してデータベース処理をチューニングするデータベース管理システムにおいて、
データベースにデータを格納する際に、直前の行と同じページに格納される行の密度を示すクラスタ率を算出するデータ格納処理部と、前記算出したクラスタ率によりスキャン対象ページを決定してデータを取得し、その取得したデータを基にチューニング情報を算出するチューニング情報処理部と、前記算出したチューニング情報を用いてデータベースへのアクセスをチューニングする為の実行プランを決定し、その実行プランを実行することでデータベース処理を行うデータベース処理部とを備えることを特徴とするデータベース管理システム。
【請求項５】
チューニング情報をサンプリングにより取得してデータベース処理をチューニングするデータベース管理システムとしてコンピュータを機能させる為のプログラムにおいて、
データベースにデータを格納する際に、直前の行と同じページに格納される行の密度を示すクラスタ率を算出するデータ格納処理部と、前記算出したクラスタ率によりスキャン対象ページを決定してデータを取得し、その取得したデータを基にチューニング情報を算出するチューニング情報処理部と、前記算出したチューニング情報を用いてデータベースへのアクセスをチューニングする為の実行プランを決定し、その実行プランを実行することでデータベース処理を行うデータベース処理部としてコンピュータを機能させることを特徴とするプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はデータベースの検索処理手順をチューニングするデータベース管理システムに関し、特にチューニングの精度を決定する統計情報（以下チューニング情報と記述）をサンプリングにより取得し、ユーザが指定したＳＱＬの検索処理手順をコストベースでチューニングするデータベース管理システムに適用して有効な技術に関するものである。
【０００２】
【従来の技術】
多くのデータベース管理システム（以下ＤＢＭＳと記述）製品は、ユーザが指定したＳＱＬに対する最適化に、ＤＢＭＳが予測する検索処理実行手順の実行コストを基に最適と思われる実行プランを決定するコストベース最適化を用いており、このコストベース最適化では、実行コストを算出する際に、ＤＢＭＳがディクショナリに保持している最適化情報を用いている。
【０００３】
前記コストベース最適化で用いられる最適化情報は、実行コスト算出時に基となる情報であり、ＤＢＭＳは、データベース管理者の最適化情報取得要求により、最適化情報を更新している。
【０００４】
前記更新時に最適化情報を取得する際、最適化情報取得対象となる表及びインデクスの全体をスキャンしてしまうと、膨大な時間を要し、場合によっては、一般ユーザによるＤＢＭＳの運用を圧迫することになる。この為、この対策として、多くのＤＢＭＳ製品は、最適化情報をサンプリングして取得することにより、最適化情報取得時間を削減することができる様なインタフェースを提供している。
【０００５】
また、ＲＤＢＭＳの種類やバージョンの違いによるＳＱＬの違いを吸収し、利用者の入力したＳＱＬ文を最適化して効率的な情報検索可能とする最適ＳＱＬ文自動生成装置では、ＳＱＬ文が入力されると、最適化ルールに従って最も効率的な検索ができる最適ＳＱＬ文に変換し、ＲＤＢＭＳサーバプロセスに出力している（例えば特許文献１参照）。
【０００６】
【特許文献１】
特開平１１−０２５１１６号公報（第４−５頁、第４図）
【０００７】
【発明が解決しようとする課題】
従来の最適化情報取得におけるサンプリングでは、無作為に対象を選択してサンプリングを行っていた為、最適化情報の精度が悪く、コストベース最適化の精度が低下し、結果としてＳＱＬ検索性能の低下によるトランザクションのスループット低下を招いてしまう問題があった。
【０００８】
本発明の目的は上記問題を解決し、データベースに格納したデータの配置を考慮に入れてチューニング情報をサンプリングして取得することで、チューニング情報の取得時間を抑えつつ、チューニングの精度を保ち、トランザクションのスループット低下を防止することが可能な技術を提供することにある。
【０００９】
【課題を解決するための手段】
本発明は、チューニング情報をサンプリングにより取得してデータベース処理をチューニングするデータベース管理システムにおいて、クラスタ率によりスキャン対象ページを決定してチューニング情報を算出し、データベース処理をチューニングするものである。
【００１０】
本発明では、データベースにデータを格納する際に、各データの行が直前の行と同じページに格納されるかどうかを調べて、その行の密度を示すクラスタ率を算出した後、そのクラスタ率をディクショナリに格納しておく。
【００１１】
次に、チューニング情報のサンプリングの際にサンプリング対象となるスキャン対象ページを、前記算出したクラスタ率を用いて決定した後、そのスキャン対象ページからインデクスキーや列中のユニーク値数、列中のＮＵＬＬ値数、列中の値の最大値、最小値及び分布情報を示すデータを取得し、その取得したデータを基にチューニング情報を算出してディクショナリに設定する。
【００１２】
データベースへのアクセスを行う際には、前記算出したチューニング情報を用いて当該アクセスをチューニングする為の実行プランを決定し、その実行プランを実行することでデータベース処理を行う。
【００１３】
データベースへデータを入力する際には、全くランダムなデータ入力が行われるのではなく、所定の順番でデータ入力が行われ、例えば商品の売り上げを管理する為のデータベースでは日付順で商品の販売数や売り上げ金額等が入力されている。この為、多くのデータの行が直前の行と同じページに格納されたクラスタ率の高いデータの場合、全てのページをサンプリングしなくても、最初の数ページをサンプリングすることにより、列中のユニーク値、ＮＵＬＬ値、最大値、最小値やその分布の傾向を知ることができると考えられる。よってクラスタ率が高い場合にはスキャン対象ページ数を少なくし、クラスタ率の低下に伴ってスキャン対象ページを増やすことにより、コストベースによるチューニングの精度を保ちつつ、チューニング情報の取得に要する時間を削減することができる。
【００１４】
前記の様に本発明では、チューニング情報取得時にデータのクラスタ率を考慮してサンプリングすることで、コストベースによるチューニングの精度を保ちつつチューニング情報取得に要する時間を削減することができる。また、コストベースによるチューニングの精度を保つことで、ＳＱＬ検索性能の低下によるトランザクションのスループット低下を防止することができる。
【００１５】
以上の様に本発明のデータベース管理システムによれば、クラスタ率によりスキャン対象ページを決定してチューニング情報を算出し、データベース処理をチューニングするので、データベースに格納したデータの配置を考慮に入れてチューニング情報をサンプリングして取得することで、チューニング情報の取得時間を抑えつつ、チューニングの精度を保ち、トランザクションのスループット低下を防止することが可能である。
【００１６】
【発明の実施の形態】
以下にチューニング情報をサンプリングにより取得してデータベース処理をチューニングする一実施形態のデータベース管理システムについて説明する。
【００１７】
図１は本実施形態のデータベース管理システムの処理概略を示す図である。図１に示す様に本実施形態のデータベース管理システムは、データ格納処理部１１０と、チューニング情報処理部１２０と、ＳＱＬ処理部１３０とを有している。
【００１８】
データ格納処理部１１０は、データベース１５０にデータを格納する際に、直前の行と同じページに格納される行の密度を示すクラスタ率を算出してディクショナリ１４０に格納する処理部である。チューニング情報処理部１２０は、前記算出したクラスタ率によりスキャン対象ページを決定して、インデクスキーや列中のユニーク値数、列中のＮＵＬＬ値数、列中の値の最大値、最小値及び分布情報を示すデータを取得し、その取得したデータを基にチューニング情報を算出してディクショナリ１４０に設定する処理部である。
【００１９】
ＳＱＬ処理部１３０は、前記算出したチューニング情報を用いてデータベース１５０へのアクセスをチューニングする為のコストベースの実行プランを決定し、その実行プランを実行することでデータベース処理を行うデータベース処理部である。
【００２０】
データベース管理システムを、データ格納処理部１１０、チューニング情報処理部１２０及びＳＱＬ処理部１３０として機能させる為のプログラムは、ＣＤ−ＲＯＭ等の記録媒体に記録され磁気ディスク等に格納された後、メモリにロードされて実行されるものとする。なお前記プログラムを記録する記録媒体はＣＤ−ＲＯＭ以外の他の記録媒体でも良い。また前記プログラムを当該記録媒体から情報処理装置にインストールして使用しても良いし、ネットワークを通じて当該記録媒体にアクセスして前記プログラムを使用するものとしても良い。
【００２１】
図２は本実施形態のＤＢＭＳ全体の構成を示す図である。本実施形態のデータベース管理システムでは、クライアント２０１でユーザの要求を受け付け、フロントエンドサーバ２０２へ転送し、フロントエンドサーバ２０２でユーザ要求の解析、チューニング、実行を行う。
【００２２】
フロントエンドサーバ２０２は、データ格納処理部１１０、チューニング情報処理部１２０及びＳＱＬ処理部１３０を有し、表及びインデクスの構成や格納先を示す表定義情報、コストベースによるチューニングに用いるチューニング情報、チューニング情報取得時に使用するクラスタ率はディクショナリ２０４に格納されており、ディクショナリサーバ２０３を介してフロントエンドサーバ２０２で取得する。
【００２３】
図２ではフロントエンドサーバ２０２とディクショナリサーバ２０３を別ノードとして記述しているが、同一ノード上にまとめることも可能である。表のデータはデータベース２０６に格納されており、バックエンドサーバ２０５を介してフロントエンドサーバ２０２が取得する。最後に検索結果、実行時間及びアクセスプランをクライアント２０１に返却して検索を終了する。各サーバはネットワーク２０７で接続されている。
【００２４】
図３は本実施形態のデータ格納処理時のデータ格納処理部１１０の処理手順を示すフローチャートである。図３では、クライアント２０１からのデータ格納処理要求を入力とし、データベースにデータを格納する処理を表しており、データベース管理システムのデータ格納処理部１１０は、データベース１５０にデータを格納する際に、直前の行と同じページに格納される行の密度を示すクラスタ率を算出してディクショナリ２０４に格納する処理を行う。
【００２５】
フロントエンドサーバ２０２のデータ格納処理部１１０は、クライアント２０１のデータ格納処理要求を契機としてこの処理を開始する。ステップ３０１〜ステップ３０３は、クラスタ率算出部１１１の処理であり、ステップ３０４及びステップ３０５がクラスタ率設定部１１２、ステップ３０６及びステップ３０７がデータ格納部１１３の処理である。
【００２６】
フロントエンドサーバ２０２のクラスタ率算出部１１１が、ステップ３０１でクライアント２０１からデータ格納処理要求を受け付けると、ステップ３０２でディクショナリサーバ２０３を介してディクショナリ２０４から格納データの格納先となる表及びインデクスの表定義情報を取得する。
【００２７】
フロントエンドサーバ２０２のクラスタ率算出部１１１は、ステップ３０３でクラスタ率を算出する。クラスタ率は、直前の行と同じページに格納される行の密度を示す値であり、クラスタ率算出部１１１は、（１−（直前の行と異なるページに格納される行数−全ページ数）／全行数）を算出してクラスタ率を求める。ここで、全ページ数は、表またはインデクスにデータを格納する際に必要となるページ数であり、全行数は、表またはインデクスに格納するデータの行数である。クラスタ率は、データが完全に物理ページ順に並ぶ場合に最大値である１となり、データが完全にランダムに並ぶ場合に最小値である（全ページ数／全行数）となるものである。
【００２８】
ステップ３０４でクラスタ率設定部１１２は、ステップ３０３において算出したクラスタ率を、ディクショナリサーバ２０３を介してディクショナリ２０４に格納する。
【００２９】
ステップ３０５では、データ格納時に同時に求めることができるチューニング情報である表の行数、表を格納したページ数、インデクスを格納したページ数を、ディクショナリサーバ２０３を介してディクショナリ２０４に格納する。
【００３０】
ステップ３０６でデータ格納部１１３は、バックエンドサーバ２０５がステップ３０２で取得した表定義情報が示すデータの格納先に、データ格納する。ステップ３０７では、データ格納処理が正常に終了したか否かをクライアント２０１に対して出力する。
【００３１】
図４は本実施形態のチューニング情報取得処理時のチューニング情報処理部１２０の処理手順を示すフローチャートである。図４では、クライアント２０１からのチューニング情報取得要求を入力とし、チューニング情報をディクショナリ２０４に設定する処理を表しており、データベース管理システムのチューニング情報処理部１２０は、前記算出したクラスタ率によりスキャン対象ページを決定して、インデクスキーや列中のユニーク値数、列中のＮＵＬＬ値数、列中の値の最大値、最小値及び分布情報を示すデータを取得し、その取得したデータを基にチューニング情報を算出してディクショナリ２０４に設定する処理を行う。
【００３２】
フロントエンドサーバ２０２のチューニング情報処理部１２０は、クライアント２０１のチューニング情報取得要求を契機としてこの処理を開始する。ステップ４０１〜ステップ４０３がクラスタ率取得部１２１の処理であり、ステップ４０４がチューニング情報基データ取得先決定部１２２の処理である。またステップ４０５がチューニング情報基データ取得部１２３の処理であり、ステップ４０６がチューニング情報算出部１２４の処理、ステップ４０７及びステップ４０８がチューニング情報設定部１２５の処理である。
【００３３】
フロントエンドサーバ２０２のクラスタ率取得部１２１は、ステップ４０１でクライアント２０１からチューニング情報取得要求を受け付け、ディクショナリサーバ２０３を介してディクショナリ２０４から、チューニング情報取得対象となる表の表定義情報をステップ４０２で取得し、クラスタ率をステップ４０３で取得する。
【００３４】
ステップ４０４において、チューニング情報基データ取得先決定部１２２は、ステップ４０２及びステップ４０３で取得した情報を基に図７で説明する手法を用いてチューニング情報算出の基となるデータ取得の為のスキャン対象ページを決定し、ステップ４０５でチューニング情報基データ取得部１２３は、バックエンドサーバ２０５を介して前記決定されたスキャン対象ページからチューニング情報算出の基となるデータを取得する。
【００３５】
ステップ４０６でフロントエンドサーバ２０２のチューニング情報算出部１２４は、ステップ４０５で取得したデータを基に図８で説明する手法を用いてチューニング情報を算出し、ステップ４０７でチューニング情報設定部１２５は、ディクショナリサーバ２０３を介してディクショナリ２０４にチューニング情報を設定する。ステップ４０８では、チューニング情報取得処理が正常に終了したか否かをクライアント２０１に出力する。
【００３６】
図５は本実施形態のユーザからのＳＱＬを用いたデータベース検索処理時のＳＱＬ処理部１３０の処理手順を示すフローチャートである。図５では、クライアント２０１からの検索要求（ＳＱＬ）を入力とし、データベースに格納されているデータの中からユーザが必要とするものをクライアント２０１に出力する処理を表しており、データベース管理システムのＳＱＬ処理部１３０は、前記算出したチューニング情報を用いてデータベース１５０へのアクセスをチューニングする為のコストベースの実行プランを決定し、その実行プランを実行することでデータベース処理を行うデータベース処理を行う。
【００３７】
フロントエンドサーバ２０２のＳＱＬ処理部１３０は、クライアント２０１の検索処理要求を契機としてこの処理を開始する。ステップ５０１〜ステップ５０３は、ＳＱＬ解析部１３１の処理である。ステップ５０４及びステップ５０５は、ＳＱＬチューニング部１３２の処理であり、ステップ５０６及びステップ５０７はＳＱＬ実行部１３３の処理である。
【００３８】
フロントエンドサーバ２０２のＳＱＬ解析部１３１が、ステップ５０１でクライアント２０１からＳＱＬを受け付け、ステップ５０２でＳＱＬの字句解析及び構文解析を行う。ディクショナリサーバ２０３を介してディクショナリ２０４から、検索対象となる表及びインデクスの表定義情報をステップ５０３で取得し、チューニング情報をステップ５０４で取得する。
【００３９】
ステップ５０５でフロントエンドサーバ２０２のＳＱＬチューニング部１３２は、ステップ５０４で取得したチューニング情報を用いてコストベースによるチューニングを行い、実行プランを決定する。ステップ５０６でＳＱＬ実行部１３３は、実行プランを実行し、バックエンドサーバ２０５を介してデータを取得する。ステップ５０７では、前記取得したデータを検索結果としてクライアント２０１に出力する。
【００４０】
図６は本実施形態の代表的なチューニング情報の一覧及びコストベースによるチューニングにおける主な用途の例を示す図である。図６のチューニング情報一覧６０１は、本実施形態で取得される代表的なチューニング情報の一覧を示しており、主な用途６０２は、チューニング情報一覧６０１に示した各チューニング情報に対応するコストベースによるチューニングにおける用途を表している。
【００４１】
図６において、ユニーク値数とは、重複する値を排除した結果として残る件数、ＮＵＬＬ値数とは、保持する値がＮＵＬＬである件数、ヒット率とは、条件が真となる割合、列中の値の分布情報とは、列を昇順に並べてｎ個の区間に分割した場合の各区間での列の値の最大値及び最小値等を示すものである。
【００４２】
ここに示したチューニング情報が実際にデータベースに格納されているデータの条件に近い場合に、ステップ５０５の実行プラン決定におけるコストベースによるチューニングにおいて、ステップ５０６の検索処理の実行プラン実行時における効果的な表のスキャン方法、結合順序を選択することができるものである。
【００４３】
図７は本実施形態のチューニング情報の基となるデータ取得の為のスキャン対象ページを求めるサンプリング手法の例を示す図である。図７において、記号「↓ｘｘｘ↓」は「ｘｘｘ」の計算結果の少数点以下を切り捨てた値を示すものである。
【００４４】
本実施形態においてスキャン対象ページを求める場合、ユーザの指定により、サンプリング手法７０１に示す手法１と手法２を使い分ける。
【００４５】
手法１はスキャンページ数をフロントエンドサーバ２０２が決定する手法であり、ステップ３０４のクラスタ率設定でディクショナリ２０４に格納したクラスタ率を用いて（全ページ数×（１−クラスタ率）＋１）の少数点以下を切り下げた値を使用してスキャンページ数を決定する。
【００４６】
この際、ディクショナリ２０４に格納されている表定義情報により、チューニング情報取得対象が、複数のデータ格納領域に分割して格納されていることが判る場合には、各データ格納領域に対して均等にデータ格納ページを選択する。また、スキャン時はＤＢバッファによるディスク入出力処理削減の効果を鑑み、（ＤＢバッファサイズ／ページサイズ）の小数点以下を切り下げた値が示す連続スキャンページ単位でページをスキャンする。
【００４７】
手法２はスキャンページ数をユーザが決定する手法であり、前記算出したクラスタ率により決定されるスキャン対象ページを提示した後、スキャン対象ページの指定をユーザから受け付けて、その受け付けたスキャン対象ページによりチューニング情報を算出する。この手法は、チューニング情報の精度を多少低下させても、チューニング情報取得時間を大幅に短縮したい場合等、ユーザがチューニング情報取得時間を積極的に制御したい場合に有効である。ユーザ指定には、行数でスキャン対象ページを決定する指定、パーセンテージでスキャン対象ページを決定する指定、または、ページ数でスキャン対象ページを決定する指定が可能であるものとする。
【００４８】
この際、ディクショナリ２０４に格納されている表定義情報により、チューニング情報取得対象が、複数のデータ格納領域に分割して格納されていることが判る場合には、各データ格納領域に対して均等にデータ格納ページを選択する。また、スキャン時はＤＢバッファによるディスク入出力処理削減の効果を鑑み、（ＤＢバッファサイズ／ページサイズ）の小数点以下を切り下げた値が示す連続スキャンページ単位でページをスキャンする。ここで、全ページ数とは、表またはインデクスにデータを格納する際に必要となるページ数であり、ページサイズは、データを格納するページの１ページあたりの容量、ＤＢバッファサイズは、データベース上のデータを入出力する為のバッファ容量のことである。
【００４９】
図８は本実施形態のチューニング情報の算出手法の例を示す図である。図８の様に本実施形態では、前記取得したデータの種別に合わせてチューニング情報の算出手法を手法１〜３から選択してチューニング情報の算出を行う。
【００５０】
手法１は、データ格納処理時にステップ３０６のチューニング情報設定で求めたチューニング情報（表の行数、表の格納ページ数、インデクスの格納ページ数）をそのまま用いる手法である。
【００５１】
手法２は、累計を示すチューニング情報（インデクスキーのユニーク値数、列中のユニーク値数、列中のＮＵＬＬ値数）を求める場合に用いる手法である。サンプリングしたチューニング情報にスキャンしたページの全ページに対する割合を掛け合わせることで、全ページでのチューニング情報を算出する。
【００５２】
手法３は、最大値、最小値、割合を示すチューニング情報（列中の値の最大値、列中の値の最小値、列中の値の分布情報）を求める場合に用いる手法である。サンプリングしたチューニング情報をそのまま用いて算出する。
【００５３】
図９は本実施形態のチューニング情報取得の具体例を示す図である。図９のデータ格納条件９１０に示す条件を満たす場合、データ格納処理部１１０のクラスタ率算出部１１１は、格納データのクラスタ率を算出し、チューニング情報の基となるデータの取得の為のスキャン対象ページを求める。
【００５４】
ＴＡＢＬＥ１に格納されるデータは、テーブル例９６０に示す様に複数のページにランダムにまたがるものとする。この場合、クラスタ率算出例９３０に示す様に、クラスタ率は、格納データ行数、格納先全ページ数、直前の行と異なるページに格納される行を用いてステップ３０３のクラスタ率算出より「０．８」であると求めることができる。
【００５５】
更に取得先決定例９４０の様に、サンプリング手法７０１に示した手法１より、スキャン対象ページ数は、クラスタ率、格納先全ページ数を用いて２６ページとなり、連続スキャンページ数は、ＤＢバッファサイズ及びページサイズを用いて４ページと求めることができる。結果として、２６／１２５（１２５ページ中の２６ページ）のデータをサンプリングし、図８に示したチューニング情報算出手法８０１を用いることで、この場合のチューニング情報を求めることができることになる。求めたチューニング情報は、ステップ５０４のチューニング情報取得処理で取得され、ステップ５０５の実行プラン決定処理でコストベースによるチューニングの際に用いられる。
【００５６】
一般に、データベースへデータを入力する際には、全くランダムなデータ入力が行われるのではなく、所定の順番でデータ入力が行われ、例えば商品の売り上げを管理する為のデータベースでは日付順で商品の販売数や売り上げ金額等が入力されている。この為、多くのデータの行が直前の行と同じページに格納されたクラスタ率の高いデータの場合、全てのページをサンプリングしなくても、最初の数ページをサンプリングすることにより、列中のユニーク値、ＮＵＬＬ値、最大値、最小値やその分布の傾向を知ることができると考えられる。よってクラスタ率が高い場合にはスキャン対象ページ数を少なくし、クラスタ率の低下に伴ってスキャン対象ページを増やすことにより、コストベースによるチューニングの精度を保ちつつ、チューニング情報の取得に要する時間を削減することができる。
【００５７】
前記の様に本実施形態では、チューニング情報取得時にデータのクラスタ率を考慮してサンプリングすることで、コストベースによるチューニングの精度を保ちつつチューニング情報取得に要する時間を削減することができる。また、コストベースによるチューニングの精度を保つことで、ＳＱＬ検索性能の低下によるトランザクションのスループット低下を防止することができる。
【００５８】
以上説明した様に本実施形態のデータベース管理システムによれば、クラスタ率によりスキャン対象ページを決定してチューニング情報を算出し、データベース処理をチューニングするので、データベースに格納したデータの配置を考慮に入れてチューニング情報をサンプリングして取得することで、チューニング情報の取得時間を抑えつつ、チューニングの精度を保ち、トランザクションのスループット低下を防止することが可能である。
【００５９】
【発明の効果】
本発明によればクラスタ率によりスキャン対象ページを決定してチューニング情報を算出し、データベース処理をチューニングするので、データベースに格納したデータの配置を考慮に入れてチューニング情報をサンプリングして取得することで、チューニング情報の取得時間を抑えつつ、チューニングの精度を保ち、トランザクションのスループット低下を防止することが可能である。
【図面の簡単な説明】
【図１】
本実施形態のデータベース管理システムの処理概略を示す図である。
【図２】
本実施形態のＤＢＭＳ全体の構成を示す図である。
【図３】
本実施形態のデータ格納処理時のデータ格納処理部１１０の処理手順を示すフローチャートである。
【図４】
本実施形態のチューニング情報取得処理時のチューニング情報処理部１２０の処理手順を示すフローチャートである。
【図５】
本実施形態のユーザからのＳＱＬを用いたデータベース検索処理時のＳＱＬ処理部１３０の処理手順を示すフローチャートである。
【図６】
本実施形態の代表的なチューニング情報の一覧及びコストベースによるチューニングにおける主な用途の例を示す図である。
【図７】
本実施形態のチューニング情報の基となるデータ取得の為のスキャン対象ページを求めるサンプリング手法の例を示す図である。
【図８】
本実施形態のチューニング情報の算出手法の例を示す図である。
【図９】
本実施形態のチューニング情報取得の具体例を示す図である。
【符号の説明】
１１１…クラスタ率算出部、１１２…クラスタ率設定部、１１３…データ格納部、１２１…クラスタ率取得部、１２２…チューニング情報基データ取得先決定部、１２３…チューニング情報基データ取得部、１２４…チューニング情報算出部、１２５…チューニング情報設定部、１３１…ＳＱＬ解析部、１３２…ＳＱＬチューニング部、１３３…ＳＱＬ実行部、１４０…ディクショナリ、１５０…データベース、１１０…データ格納処理部、１２０…チューニング情報処理部、１３０…ＳＱＬ処理部、２０１…クライアント、２０２…フロントエンドサーバ、２０３…ディクショナリサーバ、２０４…ディクショナリ、２０５…バックエンドサーバ、２０６…データベース、２０７…ネットワーク、６０１…チューニング情報一覧、６０２…主な用途、７０１…サンプリング手法、８０１…チューニング情報算出手法、９１０…データ格納条件、９３０…クラスタ率算出例、９４０…取得先決定例、９６０…テーブル例。
【図１】
2004234066.tif 000003
【図２】
2004234066.tif 000004
【図３】
2004234066.tif 000005
【図４】
2004234066.tif 000006
【図５】
2004234066.tif 000007
【図６】
2004234066.tif 000008
【図７】
2004234066.tif 000009
【図８】
2004234066.tif 000010
【図９】
2004234066.tif 000011