テーブル・インデックス数が多いときの効率的な統計情報取得方法

前へ 次へ
このQ&Aのポイント
  • テーブル・インデックス数が多い場合、ANALYZEコマンドを使用して統計情報を取得する方法が手間がかかります。
  • 効率的な方法としては、一括で統計情報を取得するツールやライブラリを使用することがオススメです。
  • また、オプティマイザ（コストベース）についても調べることで、より効果的な統計情報の取得方法を見つけることができます。
回答を見る
  • ベストアンサー

【ANALYZE】　テーブル・インデックス数が多い

過去の質問を検索しても該当するものが無かったのでご質問させていただきます。 現在、オプティマイザ（コストベース）について調べています。 ANALYZEコマンドを使用して、テーブルおよびインデックスの 統計情報を取りたいのですが、以下のコマンドのようにテーブル名もしくはインデックス名を指定することしかできないのでしょうか？ ANALYZE TABLE テーブル名　COMPUTE STATISTICS; ANALYZE INDEX インデックス名　COMPUTE STATISTICS; テーブル数及びインデックス数が非常に多いため、上記の方法では手間がかかります。 もう少し効率の良い方法を探しているのですが、ご存知であれば教えてください。 よろしくお願いいたします。

  • Oracle
  • 回答数1
  • ありがとう数1

質問者が選んだベストアンサー

  • ベストアンサー
回答No.1

PL/SQLパッケージに、DBMS_UTILITYがあります。 これを利用すると一括して行えるはずです。 具体的には、マニュアルでご確認ください。

aroha12099
質問者

お礼

ご回答ありがとうございました。 DBMS_UTILITYで検索し、以下のコマンドで希望の作業を 行うことができました。 EXECUTE DBMS_UTILITY.ANALYZE_SCHEMA('スキーマ名','COMPUTE'); 大変助かりました。

  1. カテゴリ
  2. [技術者向] コンピューター
  3. データベース
  4. Oracle

関連するQ&A

  • oracle：統計情報とテーブル削除

    oracle１０ｇを使用しております。 統計情報について質問させていただきます。 テーブルAについて、[statistics = none]を指定しExportします。 統計情報取得コマンドを実行します。 analyze table TABLE_A compute statistics; 後に、テーブルAを削除します。 drop table TABLE_A; バックアップファイルを基に、テーブルAをImportします。 このとき、テーブルAの統計情報はExport実行時と同じになるのでしょうか？

  • db2 index テーブルについて

    いつもお世話になっております。 ＤＢ２について、質問です。 テーブルにcsvファイルをインポートしようとしたところ 割り込みエラーが発生してしまいました。 詳しくはわかっていないのですが、 原因として考えられることとして indexテーブルが破壊されているのではないかと 思われます。 そこで、indexを使用しているかどうかについては 下記コマンドで確認しました。 describe indexes for table [user].[table] show detail ただ、indexテーブルが壊れているかどうかはわかりません。 どうすれば、わかりますでしょうか。 大変申し訳ございませんが ご教示くださいますよう宜しくお願いいたします。

  • 大きいデータ数のテーブルに対するインデックス作成

    mySQL server 5.1　でのindex作成について質問です かなり大きいデータ数(1000億)のテーブルを扱う必要があり検索速度向上のためにindexを作成しようとしています。テーブルのdouble型のカラムに対してインデックス作成コマンドを入力しましたが（create index）、数日経ってもまだインデックス作成が終わりません。長すぎて何か問題でも起きているのでは、と思ってのですが同様の形式のサイズの小さいデータベースに対して同様の処理を行うと問題なく終わります。 なんらかの方法でインデックス作成のスピードを上げることは可能でしょうか？たとえばint型のデータ型に変換するとスピードが向上するなどはあるでしょうか？

    • ベストアンサー
    • MySQL
  • コストベース・オプティマイザについて。

    オプティマイザには、 　1)ルールベース・オプティマイザ(RBO) 　2)コストベース・オプティマイザ(CBO) があります。 RBO は、決められたアクセスパスの優先順位に従って 実行計画を選択することが分かりました。 CBO は、最適なアクセスパスを選択する為に、 オプティマイザ統計を取得し、実行計画のコストを 見積もることが分かりました。 ★このオプティマイザ統計に関して、質問があります。 　オプティマイザ統計は、ANALYZE や DBMS_STATS パッケージを 　使用することで取得する統計情報ということが分かりました。 　しかし、統計情報を取得することでどのように実行計画が 　改善されるのか、この部分のイメージが掴めません。 ================================================================ 例えば、表の統計情報を取得すると、以下のようになりました。 SQL> select NUM_ROWS,BLOCKS,EMPTY_BLOCKS,AVG_SPACE,CHAIN_CNT 2 ,AVG_ROW_LEN 3 from user_tables where table_name='EMP'; NUM_ROWS BLOCKS EMPTY_BLOCKS AVG_SPACE CHAIN_CNT AVG_ROW_LEN ---------- ------ ------------ --------- ---------- ----------- 　 15 5 0 0 0 35 ================================================================ 　それぞれのカラムの意味は以下であることが分かりました。 　　《上記のカラムの説明》 　　NUM_ROWS　　 = 行数 　　BLOCKS 　　　= 使用ブロック数 　　EMPTY_BLOCKS = 未使用ブロック数 　　AVG_SPACE 　= 空き領域の平均サイズ(bytes) 　　CHAIN_CNT 　 = 行連鎖・行移行の行数 　　AVG_ROW_LEN　= 行の平均長(bytes) 　 　上記の統計情報を取得することで、どのように実行計画を定めているのでしょうか。 　統計情報を取得することで、どのような意味があるのでしょうか。 　宜しければ、教えて頂きたいと思います。

  • CREATE TABLEのUSING　INDEXについて

    題名通りなのですが、実際に CREATE TABLE テーブル名 (各種列作成, 制約） USING INDEX　～ USING INDEX以降に列と関係のないものをごちゃごちゃと置いていて 何をやっているかがいまいちよく分かりません。 色々とサイトなど調べたのですがいまいちよく分かりませんでした。 分かる方いらっしゃいましたら、教えていただけると幸いです。 どうかご教授よろしくお願い致します。

  • テーブルにはったインデックスは、ビューに対しても効力があるのか

    環境：RedHat Linux AS3.0 / PostgresSQL 7.3.6 Publicスキーマにインデックス付きのテーブルを作成し、 複数のスキーマにビューを作成してそのテーブルをそのまま参照したいと思っています。 （スキーマの数が非常に多いので、実体をひとつにし、 　ディスク容量を抑えるのが目的です。） 環境のイメージは以下の通りです。 ◆Publicスキーマにテーブル作成------- create table TEST_TABLE ( id int, data varchar ); ◆test_tableにインデックスを作成------- create unique index TEST_KEY on TEST_TABLE ( id ); ◆test_schemaスキーマを作成------- create schema TEST_SCHEMA; ◆test_schemaスキーマにビューを作成------- create view TEST_SCHEMA.TEST_VIEW as select id, data from TEST_TABLE ; このような環境にて「TEST_VIEW」にSELECTをかけた場合、 「TEST_KEY」は踏襲されるのでしょうか？ ビューに対してインデックスは作成できないようなので、 テーブルに対してはられたインデックスはビューでも生きている のではないかと考えたのですが、 上記認識で合っているかどうか ご存知の方がいらっしゃいましたらご教授頂けると助かります。 宜しくお願い申し上げます。

  • indexを使おうとしない間違ったcost計算

    postgres 7.2.4で質問させてください。 以下のような構成のテーブルの抽出をしようとしています。 テーブル名　：t_name カラム名　　：k1、k2、k3 インデックス：t_name_idx　 テーブルt_nameの全体件数は約70万件で、上記のSQLから期待 される抽出結果件数は約1万5千件です。t_nameにはk3のみを対象としたインデックス、t_name_idxが作成してあります。次のようなSQLを実行した際に、シーケンス検索になり応答までに６秒ほどかかってしまいます。 　select k1,k2 from t_name where k3 in ("100","200"); explain analyzeで実行計画を見ると (cost=26.29..15304.62 rows=523 width=104) Total runtime: 6427.32 msec です。シーケンスをSET enable_seqscan TO off;　で使用しないようにして、強制的にt_name_idxを使うと次のような結果になります。 (cost=0.00..42009.05 rows=523 width=104) Total runtime: 423.81 msec 実際にはindexを使用したほうが10倍以上も速いのに、プランナはシーケンス検索のほうがコストが小さいと判断しています。何故このようになってしまうのでしょうか？VACUUM ANALYZEを行っても結果は変わりませんでした。 私のイメージでは、index検索のほうがコストが小さく計算されて、それを使うべき。というイメージなのですが、考え方自体が間違っているのでしょうか？ 原因を調べ始めて１週間経ち、行き詰っています。 どなたかヒントだけでもいいので教えてください。

  • PostgreSQLのanalyzeとは

    PostgreSQLのanalyzeについてですが。 [TABLE]の統計情報を再取得する為に 　analyze TABLE; と実行した場合。 該当のテーブルへの影響というのは全く無いものなのでしょうか。 （同じタイミングでアクセスしたselectが遅延してしまう等）

  • インデックス名の重複(MySQL5.1+Windows2008)

    インデックス名の重複(MySQL5.1+Windows2008) テーブルを次のSQLでコピーしました。 mysql>create table 新テーブル名 like 元テーブル名; インデックスもコピーされたのですが、インデックス名が重複します。 これは、問題ないのでしょうか？ 新テーブルにも、同じインデックスを張りたいので、問題がなければこのままにしておきたいと思っています。 よろしくお願いします。

    • ベストアンサー
    • MySQL
  • テーブルを作ろうとしたら。

    下記のようなエラー文が表示されます。 NOTICE: CREATE TABLE will create implicit sequence 'テーブル名とフィールド名をくっつけたような名前' fo r SERIAL column 'テーブル名.フィールド名' NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index 'テーブル名_pke y' for table 'テーブル名' このデーターベースには他にもテーブルがありますが、 名前が主キーで名前が同じものがあるからエラーがでると思い、名前を変更して実行しましたが、同じような エラーがでました。 テーブル名とフィールド名をくっつけたような名前はもともとなかったものなのですが、実行後にデータベースに作成されました。 どなたかわかる方がいたら、ご教授お願いいたします。

注目のQ&A

カテゴリ

専門家に質問してみよう

職業から探して質問する

あなたにピッタリな商品が見つかる！ OKWAVEセレクト

質問する