- - PR -
FETCHが遅い
投稿者 | 投稿内容 |
---|---|
|
投稿日時: 2005-12-14 09:16
単純に推測すると、
1. 大量の行の中からごく少量の行を抽出している 2. あるいは現行の行は少なくても、過去の大量の挿入・更新・削除があってHWMが高い 3. その抽出が全表スキャンで実行されている と考えられるのですが(それでもZingBayも指摘の通り「SQL*PLUSとの実行時間の差」とは矛盾しますが)、 そもそも それほど大きなテーブルなのでしょうか? 何万件、何十万件というテーブルならば影響は大きいですが、数千件であれば 別の原因かも? 抽出対象が少量ならば、例え全表スキャンで実行されていても それほど待たされるとは思えないからです。 |
|
投稿日時: 2005-12-14 09:43
同様の不具合に遭遇しているケース。
BULK COLLECT INTOを利用することで解消しています。 http://216.239.51.104/search?q=cache:LgjcKgZg1zoJ:www6.big.or.jp/~beyond/bbsnews/j2ch.cgi%3Fbbs%3Ddb%26num%3D1111185428%26sub%3D0+%E6%9C%80%E7%B5%82%E8%A1%8C%E3%81%AE%E3%83%95%E3%82%A7%E3%83%83%E3%83%81&hl=ja&lr=lang_ja |
|
投稿日時: 2005-12-14 10:07
> 発行したSQLにおいてのHWMを確認できる方法はありますか?
発行したSQL文とHWMって関係ないのでは!? (私の認識では・・・) SQL文毎に実行計画を取得する方法ならあります。 それで、全表スキャンになっているかどうかの判断ならできますが。 HWMはテーブル毎に存在するものだと思います。 HWMの値というのがあるかどうかは知りませんが、 analyze table テーブル名 compute statistics; select blocks, empty_blocks from user_tables where table_name='テーブル名'; で、そのテーブルは使用しているブロック数を確認することはできます。 但しこの値だけで「中にどれくらいの歯抜けがある」かは判りません。 empty_blocks = 空き領域 というわけではないようです。 使用されるであろうブロック数を計算するのが大変なら(多分大変だと思います)もう1つ同じテーブルを作成して比較してみては? |