ROWIDのチューニング事例

先日、ROWIDを使用している箇所で、レスポンス悪化を確認しました。
ということで備忘録。

環境はOracle9i

WHERE
ROWID = 'XXXXX' OR
ROWID = 'YYYYY' OR
ROWID = 'ZZZZZ' ...以下続く。

数10件レベルであれば、問題なくさくっと動作しますが、
件数が増えると結局FULLアクセスとなってしまいレスポンス悪化の要因となりました。
#まあ当たり前といえば、当たり前なのですが。

投稿日時 : 2007年7月25日 13:59

# re: ROWIDのチューニング事例 2007/07/25 14:30 片桐

ORでつないだら、どんどん遅くなるのって、昔から変わってないのね、オラクルさんったら。
この場合に　ＩＮ　で検索しても同じなのかしら。
少なくとも、Oracle8までは、ORと同じ探し方をするので結局は一緒だとプラチナさんから聞いた事がありますけれど。

# re: ROWIDのチューニング事例 2007/07/25 14:40 kox

一緒だと思います。
さらに　ＩＮ句は件数に制限があるので、注意が必要ですね。
#9iでは999件だったかな。

書き忘れていましたが、
対応方法としては、個別処理に変えました。
件数が多くなるケースが少ないので、この方法で対応。

#ROWIDだけ持つ一時テーブルを作った場合ってどうなるんだろう。

# re: ROWIDのチューニング事例 2007/07/26 0:04 通り＊

確認させてください。
オプティマイザがフルアクセスにしてしまうと言う意味ではないですよね？
ROWIDを１個だけ指定して検索したとしても、テーブルに１レコードしかなければ、結果的にフルアクセスになるとか、全レコードの主キー項目をorでつなげて検索すれば、結果的にフルアクセスになるということですよね？
試しに100個のROWIDをＯＲでつなげてみたけど、フルアクセスに変わったりはしませんでした。
＃統計とってないのでRULEベースだけど...
ＯＲが無意味に遅くなるというのもあまり経験がなかったりします...

>#ROWIDだけ持つ一時テーブルを作った場合ってどうなるんだろう。
ネットワークを行き来する量を減らすために、私は作ってます～

# re: ROWIDのチューニング事例 2007/07/26 11:01 通り＊

思い出しました！
＃昨日の夜、すぐにｗ
私もＯＲで遅くなることありました...m(；。_。)m
そのときじっくり調べたら、オプティマイザくんが変な計画を組んでくれていましたorz
ヒントを与えて直せる場合もあるけど、条件によってはだめでしょうしねぇ。
＃同じ項目をＯＲした時ではまだ経験ないけど...
そういえば、その時からなるべくＳＱＬを分けて実行するようにしてました。
＃分けるようになった理由、すっかり忘れていましたｗ

# re: ROWIDのチューニング事例 2015/10/19 21:58 はぬ

rowidの一時テーブル作って、
ヒント入れれば最速です

Post Feedback

タイトル	タイトルを入力してください
名前	名前を入力してください
Url:
コメントコメントを入力してください
名前をブラウザに記憶する

Kox Blog

ニュース

書庫

日記カテゴリ

リンク

コメント

Post Feedback