3

次の問題があります。データベースにバイナリを格納するデータベースがあります。データベースのサイズが大きくなる可能性があることはわかっているため、データベースからすべてのバイナリを削除し、「縮小」タスクを使用しました。このようにして、データベースがはるかに小さくなることを期待しました。結果は次のとおりです。

削除前のサイズ: 20 ギガバイト 削除後のサイズ: 25 ギガバイト (ログ ファイルを含む) 縮小後のサイズ: 13 ギガバイト

データベース内の最大のテーブルはログテーブルであり、1.3ギガであり、残りのすべてを合わせても200メガバイトかかりません...

圧縮タスクで削除できないデータがログファイルに残っている可能性がありますか? この問題の解決策はありますか?

4

4 に答える 4

3

スペースの使用状況に関する詳細情報を取得するには、次を試してください。

EXEC sp_spaceused;
于 2009-08-11T10:43:39.410 に答える
3

復旧モデルが「完全」で、バックアップを作成しておらず、トランザクション ログを圧縮していない場合でも、サイズが大きいままになる可能性があります。

状況に応じて、トランザクション ログを圧縮する最も簡単な方法の 1 つは、復旧モデルを単純に設定し、次にトランザクション ログ ファイルを圧縮してから、復旧モデルを完全に戻すことです。ポイント イン タイム リカバリが必要な場合は、代わりにトランザクション ログのバックアップを実行する必要があります。

于 2009-08-11T10:05:05.417 に答える
0

Robin Day のアドバイスに従ってログを縮小した後は、トランザクション ログのバックアップを設定することを忘れないでください (データベースのバックアップだけでなく、ログを小さく保つことができないことがわかりました)。そうしないと、ログが再び大きくなります。トランザクション ログは 15 分ごとにバックアップされます。障害が発生した場合に失われるデータの量に応じて、スケジュールの頻度を増減する必要がある場合があります。少なくとも、ログを適切なサイズに保つためだけに、毎日のログ バックアップを行います。

于 2009-08-11T13:13:53.710 に答える
0

1 つの可能性は、データを削除したテーブルがヒープ (クラスター化されたインデックスがないことを意味します) であり、ヒープから削除すると、テーブルに割り当てられたスペースが必ずしも解放されないことです。MS のこの記事を確認してください: http://support.microsoft.com/kb/913399

于 2009-08-11T15:22:01.710 に答える