Untitled

適切にチューニングされていない環境では DROP TABLE でも TRUNCATE TABLE であっても最悪で約 1 日間*1非効率、または、不適切な実行計画で動作することがある。（Oracle 10g 時点）
双方とも関連のある実行計画はすべて DDL の実行時にご破算にされ、再度 ハード解析 から行われるが、 このときに データディクショナリ が削除されたか、残っているかで以下のように(※) 実行計画が異なることがある。 ⇒ SQL*Plus で実行計画を取得する

(※) 単純なテストでの検証のため、実際には異なっている可能性があります。 統計情報は、適切なタイミングに正しく取得するようにしてください。

• DROP TABLE の場合
  このパターンにおいて、データの投入後に手動の統計情報の収集をしていない場合、 自動メンテナンスが開始されるまでの間は、ハード解析時に動的サンプリングが行われる。

もし投入したデータが以前の統計情報に近似している場合には DROP TABLE はサンプリング自体のオーバヘッドとサンプリングレートの低さから常に最適な実行計画を導き出せるとは限らなくなる、以前よりレスポンスが低下したと感じるであろう。

• TRUNCATE の場合
  TRUNCATE は収集済の統計情報を削除しない。そのため以前の統計情報でハード解析が行われる。

もし投入したデータが以前の統計情報から、かけ離れている場合には劇的に遅くなる可能性がある。これまた TRUNCATE TABLE によってレスポンスが低下したと感じるであろう。

どちらも統計情報を適切に取得する頻度とタイミングについて配慮していないことに原因がある。
また、統計情報を収集するという作業は非常にコストが高い。時系列によるデータの分布の遷移を思慮せずに 統計情報を安易に定期的に収集するのはサーバー資源を浪費することであり注意が必要である(夜間バッチの処理が朝までに間に合わなくなったりする)。