0

1 つのサーバーに 2 つのデータベースがあります。それらを db A および B と呼びましょう。データベース A は約 11 GB で、データベース B は非常に小さい (155 MB) です。データベース B には、データベース A のデータに常にアクセスして更新しているいくつかのビューとプロシージャがあります。

興味深いことに、データベース B のログは急速に巨大なサイズになり、1 週間足らずで約 12 GB まで大きくなったと思います。データベース A はそれほど速くは大きくなりません。

ログが大きくなる原因は何ですか? 別のデータベースからデータを選択すると、ログがそのように大きくなるようなことが起こっていますか?

別のサーバー上のデータベースに対して同様のことを行うと、データはすべて呼び出し元のデータベースに移動してから、結合して選択することを知っています...これがログの増加を引き起こしていることがわかります。同じサーバーで同じことが起こっている可能性があります?

SQL2000 SP4 STD 版
フルリカバリモデル

前もって感謝します、ジョン

ところで、リカバリ モデルをシンプルに変更すると解決する可能性があることは理解していますが、最初になぜこれが発生するのかを知りたいと思います。

4

1 に答える 1

0

単純な SELECT ステートメントでトランザクション ログに何かが追加される理由は想像できませんが、私はリンク サーバーの経験があまりないので、バックグラウンドで何が起こっているのかはっきりとは言えません。

ただし、「データベース B には、データベース A のデータに常にアクセスして更新しているビューとプロシージャがいくつかある」と言うので、基礎となるデータがデータベース A に存在していても、新しいアプリケーションはデータベース B に接続してそのオブジェクトを使用するため、これらの操作が B の tran ログに記録されるのは妥当と思われます。

しかし、それは私の側の単なる推測です。トランザクション ログを直接調べて、その内容が適切かどうかを確認してみてはいかがでしょうか。RedGate には、SQL 2000 で動作する無料のログ エクスプローラがあります ( http://www.red-gate.com/products/SQL_Log_Rescue/index.htmを参照)。以前に一度しか使用したことがありませんが、うまく機能しているようで、その特定のインスタンスでベーコンを本当に節約しました.

詳細に興味があることは認めますが、あなたの状況では、好奇心を抑えてログファイルを処理したくなるでしょう。結局のところ、これは単なる一時的なものであり、ログの増加がリンク サーバーのアーティファクトである場合は、新しいアプリを終了してデータベース A を廃止すると、自動的に修正されるはずです。

また、Godeke はバックアップについても良い点を指摘しました。ログ ファイルが大きくなりすぎた場合は、より頻繁にバックアップしてください。バックアップするとログが切り捨てられますが、内部的にのみです。つまり、使用されるログ ファイルの割合は縮小されますが、ディスク上のファイルの実際のサイズは、DBCC SHRINKFILE を使用するまで変更されません。

于 2008-10-19T02:21:58.953 に答える