- PR -

FETCHが遅い

投稿者投稿内容
Desmo
大ベテラン
会議室デビュー日: 2004/03/24
投稿数: 149
投稿日時: 2005-12-14 09:16
単純に推測すると、
1. 大量の行の中からごく少量の行を抽出している
2. あるいは現行の行は少なくても、過去の大量の挿入・更新・削除があってHWMが高い
3. その抽出が全表スキャンで実行されている
と考えられるのですが(それでもZingBayも指摘の通り「SQL*PLUSとの実行時間の差」とは矛盾しますが)、
そもそも それほど大きなテーブルなのでしょうか?
何万件、何十万件というテーブルならば影響は大きいですが、数千件であれば 別の原因かも?
抽出対象が少量ならば、例え全表スキャンで実行されていても それほど待たされるとは思えないからです。
Anthyhime
ぬし
会議室デビュー日: 2002/09/10
投稿数: 437
投稿日時: 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
Desmo
大ベテラン
会議室デビュー日: 2004/03/24
投稿数: 149
投稿日時: 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つ同じテーブルを作成して比較してみては?

スキルアップ/キャリアアップ(JOB@IT)