- ベストアンサー
実行計画の「COST」と「BYTE」について教えていただきたいです。
実行計画の「COST」と「BYTE」について教えていただきたいです。 書籍には COST・・・・CBOによって見積もられた操作コスト。 BYTE・・・・アクセスされるバイト数のCBOのアプローチによる見積もり。 と書かれていますが、いまいちピンときません。 私は、 COSTは、検索するテーブルのデータ量が多いほうがコスト値が大きくなる。 BYTEは、検索条件に合致して取得できるデータが多いほうがバイト値が大きくなる。 と思っているのですが、正しいでしょうか？
- みんなの回答 （2）
- 専門家の回答
質問者が選んだベストアンサー
その他の回答 (1)
- SaKaKashi
- ベストアンサー率24% (755/3136)
BYTEは >アクセスされるバイト数のCBOのアプローチによる見積もり ですね。あくまで予想される読み込みバイト数です。実際の値ではありません。 これくらいは読むだろうと言う予測です。 >検索条件に合致して取得できるデータが多いほうがバイト値が大きくなる 検索条件に合致しているかどうかも、読んでみなければわかりませんから。 結果のバイト数ではありませんよ。
お礼
ご回答ありがとうございます。 あくまで目安ということですね。 よく覚えておきます。
関連するQ&A
- コストベースについて
データ量を基に最適な実行計画を立てることができるとありますが、具体的に実行計画を立てる場合、コストベースの場合、どのようなメリットがあるのでしょうか？ また、今回の現場ではデータ量は各テーブル１００万～８００万くらいですが、コストベースに切り替えただけでは特に速くなったりはしないですよね？ どなたかアドバイスお願いします。
- ベストアンサー
- Oracle
- 9iと10gでの実行計画の違いについて
SQLの実行計画について教えていただきたいです。 【現状】 9iと10gそれぞれの環境で /*+ ALL_ROWS */ を使用したあるSQLの 実行計画を出したところ、全く異なった実行計画になっていました。 コストは9iが2000、10ｇが150で、10gでは数秒で結果が返ってくるのに対し、 9iではいつまで経っても結果が返ってきません。 9i環境と10g環境とではテーブルの構造やINDEXは同じですが データの中身は別で、件数は9iが100万件、10gが150万件です。 【教えていただきたいこと】 このように9iと10gとで実行計画や処理の時間が異なる原因は データの中身が違うこと以外では何が考えられるでしょうか。 解決策があれば合わせてお教えいただきたいです。 /*+ ALL_ROWS */を使えば9iでもSQLをコストベースにできると 思っているのですが、それが間違いなのでしょうか。。。 そもそも実行計画がよく分かっていないので申し訳ないのですが、 何かお気づきのことがあればお教えいただきたいと思います。 よろしくお願いします！
- ベストアンサー
- Oracle
- DBの実行計画って？
先日、開発者求人の面接に行ってきました。 顧客のDBを解析、DBの検索機能を最適化して、パッケージで納品・・・というようなことを行う企業なのですが、 そこで「DBの実行計画にはどんな種類がありますか？」という質問を受けました。 （え？DBの実行計画の種類？ SQL実行する前にEXPLAINとか、で実行計画見て、コストが低くなるように 色々やったことはあるけど、実行計画の種類って？） という感じで何を聞かれているのか見当が付かず、答えられませんでした。 分かる方、教えてください！ 何を聞かれたのでしょう？ また、なんと答えればよかったのでしょう？ ※ちなみに、その企業の扱っているDBはOracle,postgres,SQL server 等 顧客に合わせて何でも扱うみたいです。
- ベストアンサー
- Oracle
- SQLの実行計画の取得について。
SQLの実行計画の取得について。 一つ目の質問 実行計画にはコストベースとルールベースがあるようですが、実行計画を取得した時にcostいくつとでるのはコストベースなのでしょうか？ それともここでいうcostは単純にパフォーマンスの指標みたいなものでコストベースだろうがルールベースだろうが、costの数値をチューニングの目安にするのでしょうか？ もし前者の場合だとすると、ルールベースの目安はどのように確認するのでしょうか。 二つ目の質問 ネットで調べると、コストベースは統計情報というものを参考にして実行計画を決めるとありました。 ということは本番で想定されるデータ量をDBにいれて統計情報を取得して実行計画を確認しないと意味がないということでしょうか？ 統計情報が保持される表も表に過ぎないから、本番からコピーすればOKという記述もありましたが、新規システムの場合は自分で必要なダミーデータを作成するものなのでしょうか。 よろしければアドバイス頂けると助かります。 データベースはDB2 Express-C 9.7になります。
- ベストアンサー
- その他(データベース)
- Oracle 実行計画について
数千万件が格納されているテーブルにINDEXキーを新設して そのINDEXキーを条件句にもつSQL文にヒント句をつけて必ず参照するように変更し、 実行計画を取得したら、新設したINDEXキーを参照してはいるのですが、 逆にRowsやBYTESなどが増加してしまいました。 Rows | Bytes | Cost ⇒ Rows | Bytes | Cost 1 | 23 | 5 2862 |65826 | 16 ただ、体感速度はINDEXキーを新設した方が早いです。 この場合考えられる原因とは何がありますか？ Oracle１１gです。
- 締切済み
- Oracle
- 実行計画HASH JOIN RIGHT OUTER
以下のようなSQLがあるとします。 ------------------------ SELECT * from (select * from TABLE-A where 条件色々) AA, TABLE-B BB where BB.x(+) = AA.x ------------------------ TABLE-Aの件数は非常に多く（例100万)、条件は複雑です。 TABLE-Bの件数は少ないです（例30件） この時、実行計画が HASH JOIN RIGHT OUTER TABLE ACCESS FULL TABLE-B のように出ましたが、どのように解釈すれば良いのでしょう？ TABLE-Bは件数が少ないのでACCESS FULLでも問題ないでしょうか？ HASH JOIN RIGHT OUTER のコストが高くなってて気になってます。 たとえば、この場合のより適切な実行計画ってありますか？
- ベストアンサー
- Oracle
- Byte error rateってあるんですか？
通信実験を行う際にBit error rate(BER)測定を行うことはよくあると思うのですが、 もし、これがBit単位ではなくByte単位で行う場合何と呼ぶのでしょうか？ 個人的にはByte error rateという名前になるのかと思うのですが、 インターネットで検索してみても特にありませんでした。 データをBit単位ではなくByte単位で調べるということは、特に珍しいことではないような気がするのですが、正式名称はあるのでしょうか？ どなたかご存知の方いらっしゃいましたら教えていただけると幸いです。
- ベストアンサー
- 物理学
- コストベース・オプティマイザについて。
オプティマイザには、 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) 上記の統計情報を取得することで、どのように実行計画を定めているのでしょうか。 統計情報を取得することで、どのような意味があるのでしょうか。 宜しければ、教えて頂きたいと思います。
- ベストアンサー
- Oracle
- 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
- Access2000での複合検索について
コンボボックスを使い検索をしたいと考えております！ 名前は テーブル1:ビル区分マスタ←フィールド:ビル区分、ビル名 テーブル2：テナントマスタ←フィールド:ビル区分、テナントコードetc…があります コンボボックス：cbo検索ビル区分、cbo検索テナントコード コマンドボタン：btn検索 cbo検索ビル区分に01,02があり、例えば01を選んだときcbo検索テナントコードにビル区分が01のテナントコードを出したいのです！そしてbtn検索をクリックするとフォームにそのデータを出したいのです！ こんな文章じゃわかりにくいかとも思われますが、よろしくお願いします！！もんすごい初心者です！
- ベストアンサー
- その他(データベース)
お礼
ご回答ありがとうございます。 COST値は検索するデータ量という単純な値ではないのですね。 バイト値は取得したデータ量と思ってよろしいものなのでしょうか？