次の問題があります。 データベースにバイナリを格納するデータベースがあります。 データベースのサイズが大きいので、データベースからすべてのバイナリを削除し、その上で "縮小"というタスクを使用しました。 この方法で、データベースがはるかに小さくなることを期待しました。 これらの結果である：脱サイズだった前データベースのサイズが大きい
：除去サイズ後の20ギガバイト されました：25ギガバイト（税込ログファイル） シュリンクサイズだった後：13ギガバイト
今私はその13見当がつかないギグは、データベースの中で最大のテーブルはログテーブルであり、残りのすべては残りのすべてが200MBをとることはありません。
ログファイルにはまだ縮小タスク削除できませんか？ この問題の解決方法はありますか？
リカバリモデルが "フル"で、トランザクションログをバックアップしてから縮小していない場合は、依然として大きなままです。
トランザクションログを縮小する最も簡単な方法の1つは、回復モデルを単純に設定し、次にトランザクションログファイルを縮小し、回復モデルを完全に戻すことです。運用システムでは、特定の時点でのリカバリが必要な場合は、代わりにトランザクションログのバックアップを実行する必要があります。
ログファイルを削除して添付する方法は別です。http://bloggingabout.net/blogs/mglaser/archive/2007/01/12/sql-server-tip-shrinking-a-sql-server-log.aspx – RichardOD
ログファイルを削除するのは悪い考えです！それについて考えることもありません！ –
t-logファイルを削除するのはひどい考えです。 – SQLChicken
あなたが試すことができますスペースの使用状況に関する詳細情報を入手するには、次の
EXEC sp_spaceused;
（あなたが判明しているとして、彼らは小さなログを維持しないだろうとだけでなく、データベースのバックアップ）トランザクションログのバックアップを設定することを忘れないでください後あなたはロビンデイのアドバイスを取ってログを縮小するか、ログが再び大きくなるでしょう。私たちのトランザクションログは15分ごとにバックアップされます。障害発生時に失う可能性のあるデータ量に応じて、スケジュールを頻繁に変更する必要があります。少なくとも、ログを適切なサイズに保つために、毎日のログバックアップを実行します。
データベースの毎日のバックアップはログに影響しません。ログもバックアップする必要があります。 – HLGEM
1つの可能性は、データを削除したテーブルがヒープ（つまり、クラスタ化インデックスがないこと）であり、ヒープから削除するときに、テーブルに割り当てられたスペースが必ずしも解放されないということです。この記事をMSからチェック：http://support.microsoft.com/kb/913399
ログファイルとMDFのサイズを確認しましたか？ – RichardOD
どのSQLのバージョンを使用していますか？ –