ORACLE(オラクル)における統計情報とは?

ORACLE(オラクル)における統計情報とは?

こんにちは、おもちです。


今回は少し専門的な内容を書くので、興味のある人だけ見てください。


ORACLE(オラクル)の統計情報という分野について、統計情報とは何なのか?取得する意味等についてまとめてみました!

ORACLE統計情報(オプティマイザ統計情報)とは

ORACLE統計情報とは、以下の4つの統計から構成されます。

表に対する統計
表のサイズ、行数、1行当たり平均サイズ等

表内の列に対する統計
列データの種類数、データ分布(ヒストグラム)等

索引に対する統計
索引のサイズ、階層数、クラスタ化係数等

システムに対する統計(9i~)
サーバのI/OやCPUの処理能力等

つまり、統計情報とは使用しているサーバやデータベースの特性を数値で表したものといえます。

それでは、なぜ別名がオプティマイザ統計情報なのか。

まず統計情報は、OracleがSQLを解析して最適な実行計画を作成するために利用する情報です。

実行計画を作成する機能のことをCBO(コスト・ベース・オプティマイザ)といい、このオプティマイザ向けの統計的な情報だから、オプティマイザ統計情報と呼ばれるのです。

更に具体的に、統計情報の実体は何かというと、データベースの各テーブル・各インデックスカラムの傾向を表したデータディクショナリデータです。

例えばユーザテーブルに100万件のデータが入っていたら、
テーブル統計情報として100万件のレコードがあるということが記録されます。

でも、100万件と、1000件では最適なアクセスパスは全く異なりますよね。100万件を全表走査などしようものなら、SQLは100秒は返ってこない。しかし1000行なら、インデックスアクセスしてる分だけ無駄もあるかもしれない・・ということです。

統計情報と実行計画の関係性

上で説明した通り、オプティマイザは統計情報をもとに実行計画を作成します。

注意したいのは、実際のデータベースの情報をもとに実行計画を作成するのではなく、統計情報をもとに実行計画を作成する、という点。

つまり、テーブルに対してデータの登録・更新・削除が行われたのに、統計情報が最新化されていないと、オプティマイザは古い情報をもとに実行計画を作ろうとします。

よって、ある時点では最適な実行計画が選ばれSQLのパフォーマンスも問題はない場合でも、データの登録・更新・削除が頻繁に行われるにつれ、パフォーマンスが劣化していく、といった事あよくあるのです。

これを回避するには、テーブルのデータに更新が入ったら併せて統計情報も最新化する必要があるということです。

統計情報はなぜ必要か?

統計情報の一番大きな目的は最適な実行計画を立てられる可能性を高めるためです。

逆にいえば発行する全てのSQLがヒント等により最適な実行計画で固定されていれば統計情報を取得する必要性は大幅に低下します 。

また、実行計画が決まってしまえばその実行計画の通りに処理されるだけなので実行計画が決まった後の処理時間には統計情報は影響しません。

統計情報のよくあるFAQ

Q1:統計情報と実行計画にはどんな関係があるんですか?

A:実行計画はOracle Databaseによって生成されますが、統計情報をインプットの一部にしています。表や列の統計情報を使用する事によって、最もアクセス効率の良い実行計画を生成する事が可能になります。

Q2:各オブジェクトの統計情報を確認したいのですが、統計情報はどうやって確認できますか?

A:SYSユーザーが所有するディクショナリ・ビューから確認することができます。次の統計情報が、下記のビューに格納されています。

•表の統計情報→DBA_TABLES
•索引の統計情報→DBA_INDEXES
•列の統計情報→DBA_TAB_COLUMNS

Q3:統計情報を収集しようと思うのですが、どのような方法で収集できますか?

A:統計情報には、以下のような収集方法があります。

Q4:特定のObjectに対する統計情報だけ取得することはできる?

A:DBMS_STATSパッケージを使用すると、特定のオブジェクトの統計情報だけを取得することができます。

Q5:統計情報を収集しようと思いますが、システムの負荷上、どのようなタイミングで取得するべきでしょうか。 統計情報収集処理は、どのくらいリソースへ負荷を与えるものでしょうか?

A:統計情報収集処理自体の負荷は、収集対象オブジェクトの数と収集方法によって異なります。

統計情報に関する注意

・最適な実行計画が選択されるとは限らない
実態に即した正確な統計情報が収集されていたとしてもORACLEが最も早い実行計画を選択するとは限りません。

逆に統計情報がないほうが早い実行計画が選択されてしまう可能性さえあります。

特定のSQLのみ遅くなる場合は該当SQLに対して実行計画の固定を検討し、 個々のSQLに対する対処が困難であれば実行計画の選定に影響するパラメータの変更等を検討、テストします。

・統計情報を収集しなおすと実行計画が変わる可能性がある
実行計画はパフォーマンスに影響する非常に大きな要因であり不適切な実行計画に変わると今まで1分で終わっていたクエリが1時間かかるようになるといった事象が発生することも珍しくありません。

上述の通り統計情報を最新にしたとしてもパフォーマンスがよい実行計画が選択されるかはわからないため、本番運用中に統計の自動収集ジョブを有効にするなどで統計情報が常に変化する状態にしておくことはパフォーマンス悪化の可能性というリスクが常に発生していることを認識しておく必要があります。

本番運用開始前の段階で統計情報を定期的に収集すべき表とすべきでない表を切り分けし、基本的には一部を除き統計情報は良好なパフォーマンスが得られている状態でロックしておいたほうがよいでしょう。

・システム統計情報を取得すると開発環境と本番環境で実行計画が変わる可能性が高くなる
システム統計情報を取得することでサーバのI/O性能等を考慮した実行計画が立てられることになり、性能が大きく異なる開発環境等と異なる実行計画が選択される可能性が高くなります。

・統計情報のサンプリング率は100%でなくともよい
統計情報のサンプリング率は表が大きい場合は100%のデータをサンプリングしなくともほぼ正確な統計となります。 

社会カテゴリの最新記事