SQL Serverログファイルのサイズを縮小する方法


10

データベースのldfファイルのサイズを縮小する方法がわかりません。

DBAは私が使うべきだと言っています backup log dbname with truncate_only

SQLクエリアナライザで正しく実行されたように見えますが、ldfファイルはまだ2 GBを超えています。

**いくつかのコメントと以下のいくつかの回答に基づいた明確化。***問題の特定のデータベースは、私のラップトップ上のデータベースであり、開発プロセスにのみ使用しています。ログファイルが増加して、ディスクがいっぱいになる原因になりました。関連する生産リスクはありません。私が尋ねた質問の方法と受け入れた回答は、実稼働環境では危険であることを理解しています。*


確かにこれは重複した質問ですか?
JamesRyan、2010

SHRINKFILEがいつ失敗するかについて質問していた1つだけを探して見つけました。当時は意味がなかったので、この質問を投稿しました。私は質問を削除することを検討しましたが、同じボートにいる他の人がいるだろうと考えました。重複する質問(実際には同じ質問ではなく、同じ質問をする)が見つかった場合は、削除させていただきます。
Ron Tuffin 2010

それを含む検索の最初のページには約8つの回答がありますが、私はあなたが探しているものを知っている必要があると思います。私はそれを回答の一部として非常に定期的に見ていますが、これほど簡単な方法で尋ねられていないことに驚きました。
JamesRyan、2010

その答えは、データベースのリカバリオプションに大きく依存します。
リチャード

1
明確にしてくれてありがとう、ロン。devデータベースなので、ログファイルを縮小することに加えて、復旧モデルをSIMPLEに変更する必要があります。そうしないと、問題が再発します。
BradC 2010年

回答:


11

ああ、恐怖!ログファイルを圧縮する必要があることをユーザーに伝えないでください。

この状況に陥った場合は、次のいずれかの可能性が非常に高くなります。

  1. データベースは完全復旧モードであり、実際にはシンプルモードである必要があります
  2. データベースは完全復旧モードであり、定期的なログバックアップを行う必要があります
  3. データベースが完全復旧モードであり、ログバックアップが何らかの理由で失敗している
  4. あなたはログファイルを巨大なサイズに爆破している巨大なトランザクションを実行しています

これらのそれぞれの答えは次のとおりです。

(1)の場合は、データベースをシンプルモードに切り替えます
(2)の場合、定期的なログバックアップをスケジュールします
(3)の場合、スケジュールされたログバックアップを修正します
(4)の場合は、それを行わないでください:)代わりに、小さなバッチで作業します。

これらのどれもが(非推奨)「truncate_onlyを使用したバックアップログdbname」を使用する必要があることに注意してください。

代わりに、上記の方法のいずれかを使用してログファイルを消去したら、次のようにして(現在は空の)ログを圧縮します。

DBCC SHRINKFILE ('log logical name', 2000)

常に適切な最終サイズを指定してください。そうしないと、サイズはほぼ0に縮小され、次に必要になったときに、成長するのに時間がかかるようになります。


受け入れられた答えが非常に速かったのはあまりにも悪かった。これは、インタビュー中にSQL管理者を排除するために使用する質問の1つです。彼らがtruncate_onlyでバックアップを取り戻した場合、2が打たれたと見なされます。
ジムB

2
ファイルを圧縮することは絶対に最後のことだと私は同意します。正しいメンテナンスはこれの必要性を取り除きます。しかし、いったん大きくして小さくしたい場合は、縮小する必要があります。ただし、圧縮する場合は、ファイルをできるだけ小さく圧縮してから、ファイルを8GB単位で正しいサイズに拡張することをお勧めします。これにより、ファイル内のVLFの数が最適化されます。-sqlskills.com/BLOGS/KIMBERLY/post/…を参照してください。
ブライアンナイト

1
おもしろいリンク、それはあなたのトランスログが8Gb以上の場合にのみ適用されるようです。BradCのポイント(または少なくとも私のもの)は、ログファイルを圧縮する必要がある緊急事態が存在することですが、悪名高いbackup / w truncを実行した後、shrinkfileを実行すると、バックアップチェーンをホースしたことを認識する必要があります(それが何も重要ではないことを願っています)、そしてディスク領域の問題は別として、おそらくデータベース設計の観点から、またはアーキテクチャ上の観点から、SQLサーバーに関する深刻な問題が発生している可能性があります。根本的な原因を修正せずに、せいぜい自分の時間を購入しました。
ジムB

4

「truncate_onlyを使用したバックアップ」を実行した後、次のコマンドを発行して縮小する必要があります

dbcc SHRINKFILE (logfilename,shrink_tosize)

例えば

dbcc SHRINKFILE (mydatabase_Log,512)

3

上記で作成したスクリプトは、ログの内容に再利用のマークを付けます。そのスクリプトに従ってください:

USE <database>;

DBCC SHRINKFILE (<log logical file name>)

それはあなたのためにそれを縮小します。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.