SQL Server2000でトランザクションログを圧縮（ほぼ切り捨て）しようと考えています。backup log db_name with no_log【改行】dbcc shrinkfile(’file_name’)でおこなう予定です。場合によっては圧縮後容量も指定します。この場合、DBのパフォーマンスになんらかの影響はあるのでしょうか？現在、重い処理の直後にreindexをし同様の重い処理が発生したときのパフォーマンスを高めています。このあたりに対して何らかの影響があるかを知りたいので、よろしくお願いいたします。

すいません。質問の仕方が悪かったです。

トランザクションログファイルを削除することによってindexの再構築（reindex）の結果に変化があるのかを質問したかったです。。。

過去のSQLがトランザクションログに格納されているので、トランザクションログを切り捨てると、やはり、reindexに影響がありますよね…

重い処理は大きめのテーブルを複数結合しgroup byしている処理（複数）です。

SQLServerではオプティマイザがある程度チューニングしてくれるので、SQLの変更では

あまり期待した結果が得られず、ストアド化をおこなおうか迷っている段階でした。

現在は運用形態の関係でreindexで事足りているのですが、トランザクションログを圧縮することによって

reindexの効果が落ちるのではと悩んでいるところです。

たびたびありがとうございます。

現在、日々ARCServeでDATにバックアップを取っているのですが、トランザクションログが

肥大化しすぎて、DATに入りきらない状況です。

いろいろと考えたのですが、トランザクションログの切捨て＋ストアド化がいいのかなと思ってます。

reindexは直近のクエリーを重点的に意識した再構築をしているようなので（憶測ですが）、

トランザクションログを切り捨てても、reindexによる期待している再構築の

パフォーマンスダウンはさほどないのでは？と考えました。

（運用では、同様のクエリーを投げることが多いため）

また、検索項目（Where句）が100近くありまして、各検索条件の演算子の関係で

全表検索がどうしても多く発生してしまいます。

（!=等）

このあたりがオプティマイザの負荷を高めて、クエリの実行というより

オプティマイザの負荷（実行計画の作成時間）が増加しているのではとおもいます。

統計による細かい調査はしていないのですが…

もしも、またなにかお気づきになりましたら、1ポイント送信等でお知らせいただければ

ポイントをお渡しいたしますので、よろしくお願いいたします。