- ベストアンサー
9iと10gでの実行計画の違いについて
- 9iと10gの環境で同じSQLの実行計画を比較しました。9iでは結果が返ってこず、10gでは数秒で結果が返ってきます。原因はデータの中身以外に何が考えられるでしょうか。
- 9iと10gの環境での実行計画の違いについて教えてください。9iでは結果が返ってこないのに対し、10gでは数秒で結果が返ってきます。データの中身以外に原因はあるのでしょうか。
- 9iと10gの環境で /*+ ALL_ROWS */ を使用したSQLの実行計画を比較しました。9iでは結果が返ってこないのに対し、10gでは数秒で結果が返ってきます。原因を教えてください。
- みんなの回答 （5）
- 専門家の回答
質問者が選んだベストアンサー
その他の回答 (4)
- muyoshid
- ベストアンサー率72% (230/318)
こんにちわ。 > 9i環境と10g環境とではテーブルの構造やINDEXは同じですが > データの中身は別で、件数は9iが100万件、10gが150万件です。 例え実行計画が同じでもデータが異なるのであれば性能に大きな 違いがあるのは普通です。 9i 環境で統計情報の再取得を行うと、実行計画が変化して性能が 向上する可能性があります。
お礼
ご回答ありがとうございます。 >例え実行計画が同じでもデータが異なるのであれば性能に大きな >違いがあるのは普通です。 やっぱりそうですよね。。。 >9i 環境で統計情報の再取得を行うと、実行計画が変化して性能が >向上する可能性があります。 これについては、9iでは統計情報の再取得を行った結果 更にコストがかかるようになってしまいました。。。
- nora1962
- ベストアンサー率60% (431/717)
9iと10gの実行計画出せますか。（Explainなどでの） ヒント句を用いて、実行計画を変更できる可能性はあります。
お礼
ご回答ありがとうございます。 >9iと10gの実行計画出せますか。（Explainなどでの） テーブル名の部分だけ変更させていただきましたが、 それぞれ以下のような実行計画になっています。 （統計情報を取得し直したらコストが変わっていました） 【9i】 SELECT STATEMENT REMOTE Cost = 2933 SORT UNIQUE FILTER NESTED LOOPS NESTED LOOPS HASH JOIN TABLE ACCESS FULL テーブルA INDEX FAST FULL SCAN PK_テーブルB UNIQUE TABLE ACCESS FULL テーブルA INDEX UNIQUE SCAN PK_テーブルB UNIQUE INDEX UNIQUE SCAN PK_テーブルB UNIQUE 【10g】 SELECT STATEMENT REMOTE Cost = 180 SORT UNIQUE TABLE ACCESS BY INDEX ROWID テーブルA TABLE NESTED LOOPS NESTED LOOPS NESTED LOOPS ANTI HASH JOIN TABLE ACCESS FULL テーブルA TABLE INDEX FULL SCAN PK_テーブルB INDEX (UNIQUE) INDEX UNIQUE SCAN PK_テーブルB INDEX (UNIQUE) INDEX RANGE SCAN PK_テーブルB INDEX (UNIQUE) INDEX RANGE SCAN テーブルA_IDX01 INDEX 自分なりに分析・改良をしようとはしているのですが、 まだ勉強不足なため上手くいっていません。 何かアドバイスなどいただけると嬉しいです。
- 山田 太郎（@testman199）
- ベストアンサー率17% (438/2463)
当たり前の話ですが バージョンアップに伴いオプティマイザの改良も行われています。 同じコストベースとは言え、その結果が全く違うことは多々あります。 (PSRでも変更される場合があります。。。)
お礼
ご回答ありがとうございます。 >同じコストベースとは言え、その結果が全く違うことは多々あります。 そうだったんですね。。。 質問してばかりで申し訳ないのですが、『この実行計画で』 と実行計画を指定して実行させる方法はないのでしょうか。 SQL自体の改良も試みてはいるのですが、このままだと 9iの環境では結果が取得できそうにないので。。。
- SaKaKashi
- ベストアンサー率24% (755/3136)
統計情報を確実に取得してますか？全件分の統計情報です。 9i以降標準はコストベースです。 実行計画は9iと10gでは違っても不思議ではないですけどね。
お礼
ご回答ありがとうございます。 >統計情報を確実に取得してますか？全件分の統計情報です。 ANALYZE TABLE テーブル名 COMPUTE STATISTICSで 統計情報を全検分取得してから実行しているので 問題ないと思うのですが。。。
関連するQ&A
- Oracle 実行計画について
数千万件が格納されているテーブルにINDEXキーを新設して そのINDEXキーを条件句にもつSQL文にヒント句をつけて必ず参照するように変更し、 実行計画を取得したら、新設したINDEXキーを参照してはいるのですが、 逆にRowsやBYTESなどが増加してしまいました。 Rows | Bytes | Cost ⇒ Rows | Bytes | Cost 1 | 23 | 5 2862 |65826 | 16 ただ、体感速度はINDEXキーを新設した方が早いです。 この場合考えられる原因とは何がありますか？ Oracle１１gです。
- 締切済み
- Oracle
- Oracle 実行計画の読み方
コメントあれば、よろしくお願い致します。 0 recursive calls 0 db block gets 7,800,000 consistent gets --select文でアクセスしたバッファキャッシュのブロック数。ディスクとメモリへの総アクセス数 A 3,500,000 physical reads --ディスク上のデータファイルにアクセスしたデータ要求の総ブロック数 B 0 redo size 219,000,000 bytes sent via SQL*Net to client 7,100,000 bytes received via SQL*Net from client 500,000 SQL*Net roundtrips to/from client 100 sorts (memory) --メモリ内でソートした回数 C 0 sorts (disk) 9,200,000 rows processed --処理対象となった行数 D 一番、重視しなければいけないのは、A だと思っています。 780万回もアクセスされていますが、 ブロック数が 8K に設定されている環境であったとして、 1024*8*780万 = 63,897,600,000約 63GB の i/o が一つのSQLで発生 B に関しても一応計算してみると、 1024*8*350万 = 28,672,000,000約 28GB の i/o が一つのSQLで発生 D に関しては、920万行という結果は分かるが、1行辺りの幅が分からないので、 幅を別途SQLから計算し、どういった負荷を与えている文なのかを分析する必要がある。 select statement optimizer=choose からの数十行には、 (FULL)が、(UNIQUE INDEX)に比較して、10倍ぐらい表示されていると仮定します。 それぞれの検索テーブルの件数ははっきりしていたとして(1件～2000万件ぐらい(400万件以上が5テーブル))、 何をどうするのがSQLチューニングでしょうか。
- ベストアンサー
- Oracle
- SQLの実行計画の取得について。
SQLの実行計画の取得について。 一つ目の質問 実行計画にはコストベースとルールベースがあるようですが、実行計画を取得した時にcostいくつとでるのはコストベースなのでしょうか？ それともここでいうcostは単純にパフォーマンスの指標みたいなものでコストベースだろうがルールベースだろうが、costの数値をチューニングの目安にするのでしょうか？ もし前者の場合だとすると、ルールベースの目安はどのように確認するのでしょうか。 二つ目の質問 ネットで調べると、コストベースは統計情報というものを参考にして実行計画を決めるとありました。 ということは本番で想定されるデータ量をDBにいれて統計情報を取得して実行計画を確認しないと意味がないということでしょうか？ 統計情報が保持される表も表に過ぎないから、本番からコピーすればOKという記述もありましたが、新規システムの場合は自分で必要なダミーデータを作成するものなのでしょうか。 よろしければアドバイス頂けると助かります。 データベースはDB2 Express-C 9.7になります。
- ベストアンサー
- その他(データベース)
- DBの実行計画って？
先日、開発者求人の面接に行ってきました。 顧客のDBを解析、DBの検索機能を最適化して、パッケージで納品・・・というようなことを行う企業なのですが、 そこで「DBの実行計画にはどんな種類がありますか？」という質問を受けました。 （え？DBの実行計画の種類？ SQL実行する前にEXPLAINとか、で実行計画見て、コストが低くなるように 色々やったことはあるけど、実行計画の種類って？） という感じで何を聞かれているのか見当が付かず、答えられませんでした。 分かる方、教えてください！ 何を聞かれたのでしょう？ また、なんと答えればよかったのでしょう？ ※ちなみに、その企業の扱っているDBはOracle,postgres,SQL server 等 顧客に合わせて何でも扱うみたいです。
- ベストアンサー
- 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
- 実行計画の「COST」と「BYTE」について教えていただきたいです。
実行計画の「COST」と「BYTE」について教えていただきたいです。 書籍には COST・・・・CBOによって見積もられた操作コスト。 BYTE・・・・アクセスされるバイト数のCBOのアプローチによる見積もり。 と書かれていますが、いまいちピンときません。 私は、 COSTは、検索するテーブルのデータ量が多いほうがコスト値が大きくなる。 BYTEは、検索条件に合致して取得できるデータが多いほうがバイト値が大きくなる。 と思っているのですが、正しいでしょうか？
- ベストアンサー
- Oracle
- oo4o。executeSQLにてupdate実行後、実行件数取得は？
今まであまり使ったことの無かったAccess97のVBAを使用しています。単純な質問なんですが、教えてください。 oo4oにてオラクルDBに接続し、executeSQLメソッドにより単純なupdate処理を実行しました。 -----（細かいところは省略） sql= "update TABLE_A set CODE='AAA' where NAME='HOGE'" OraDB.ExecuteSQL sql ----- このExecuteSQLメソッドの、実行結果が０件なのか、１件なのかを知りたいのですが、方法はありますでしょうか？つまり、直前のSQLの実行結果を取得するメソッドはありますか？という質問です。Javaとかなら、戻り値として実行結果の件数が帰ってきますよね。この場合はそれをどうやって取ればいいのでしょうか？ where NAME='HOGE'に当てはまるレコードが無くても、０件の処理が成功として、エラーは出ないんですよねぇ・・・ もし不足の情報がありましたら、補足いたします。 よろしくお願いします。
- ベストアンサー
- Visual Basic
- PHPでMySQLのストアドプロシージャを実行するには？
こんにちは、この件でいろいろ検索していたのですが ストアドの作成まではできているのですが、PHPからの 実行のさせ方がわからず質問させていただきました。 環境は、PHP 5.2.9 + MySQL5.1.32 で MySQLでストアドプロシージャを作成して、実行できるのですが これをphpから実行させたいのですが、どのように記述すればよいのかわからず悩んでおります。 実行したいストアドは Gen_rank という名前でコンソールから実行できることは確認しています。 下記のようにしてみましたが、ストアドは走りませんでした。 <?php require_once("db_connect.php"); // クエリを送信する $sql = "call Gen_rank();"; $sql = "SELECT id, name, phonetic, age, s4, s9, rank FROM tmp_records ORDER BY rank"; $result = executeQuery($sql); // 結果セットの行数を取得する $rows = mysql_num_rows($result); // 表示するデータを作成 if($rows){ while($row = mysql_fetch_array($result)) { $tempHtml .= "<tr>"; $tempHtml .= "<td>".$row["id"]."</td><td>".$row["name"]."</td><td>".$row["phonetic"]."</td><td>".$row["age"]."</td><td>".$row["s4"]."</td><td>".$row["s9"]."</td><td>".$row["rank"]."</td>"; $tempHtml .= "</tr>\n"; } $msg = $rows."件のデータがあります。"; }else{ $msg = "データがありません。"; } // 結果保持用メモリを開放する mysql_free_result($result); ?>
- 締切済み
- PHP
- 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
お礼
ご回答ありがとうございます。 そして、お礼が遅くなり大変失礼いたしました。 結果から申し上げますと、ご回答を受けて色々と修正を 試みたのですが、結局コストの改善はできませんでした。。。 また、スクリプトについてなのですが、少々ロジックを変えて PL/SQLで作成してみたところ9iでも結果が取得できました。 作成期日が迫っていたスクリプトだったため、今回については PL/SQLで対応することにいたしました。 せっかくご回答いただいたのに活かしきれずすみません。 それと、このSQLは仕事に関わるものなためこれ以上情報を 提供することはできそうにありません。。。 中途半端な状態で終わらせてしまい本当に申し訳ないのですが、 本件についてはこれでひと段落とさせていただきたいと思います。 丁寧にご対応くださったnora1962さんをBAに選ばせていただきます。 ご対応いただきありがとうございました。