ログファイルを圧縮してもサイズは小さくなりません


23

350 MBのデータファイル(.mdf)と4.9 GBのログファイル(.ldf)を持つデータベースがあります。復旧モデルはに設定されFULLます。

ログファイルを圧縮しようとしても、圧縮されません。

データベースの縮小は良くないことを知っています。しかし、私はまだログファイルを縮小するためにそれをやろうとしています。

走ったとき

DBCC SQLPerf(logspace) 

ログサイズは4932 MBで、使用されるログ領域は98.76%であることがわかりました。

それから私はこのコマンドを試しました

USE <databasename>;
DBCC loginfo;

現在、ほとんどすべてのVLFは「ステータス2」であり、すべてが使用中であることを意味します。

ログのバックアップを取り、ログファイルを圧縮しようとしました。縮小してもサイズは小さくなりませんでした。

復旧モデルをに変更し、SIMPLE再度縮小しようとしましたが、これも役に立ちませんでした。

未処理のトランザクションを確認しました

DBCC opentran (database);

現在開いているトランザクションがないことがわかりました。

ログファイルの縮小を妨げているのは何ですか?どうすれば解決できますか?

回答:


12

これが私の質問に対する答えです。

以下のクエリを実行して、ログファイルの再利用待機に関する情報を取得します。

SELECT log_reuse_wait_desc
FROM sys.databases
WHERE name = 'DBName'

私は次の出力を得ました:

log_reuse_wait_desc
-------------------
REPLICATION 

レプリケーションを削除した後でも、データベースにいくつかのレプリケーション関連オブジェクトが残っていました。

データベースからレプリケーションを削除するには、sp_removedbreplication使用できます。しかし、複製はその時点ではアクティブではなく、実際には複製はずっと前に削除されていたため、機能しませんでした。

解決策は、SQL Serverのインポートオプションを使用して、データベースの内容を別のデータベースにインポートすることでした。


同じ問題があり、これを使用して、dbにアクティブなトランザクションがあることを確認しました。 log_reuse_wait_desc与えたACTIVE_TRANSACTION。トランザクションが完了するとすぐに、縮小は正常に機能しました。
squillman

10

ログを縮小する手順は次のようになります

SSMSまたはT-SQLを介してトランザクションログをバックアップしてから、縮小を実行します

データベース名を右クリックすると、SSMSのコマンドがタスクの下に表示されます

BACKUP LOG <Databasename> TO DISK N'<path\database_log.ldf';
GO

DBCC SHRINKFILE (<FileName>, <TargetSize>) WITH NO_INFOMSGS

あなたはおそらくこれを複数回行う必要があります

アクションをブロックしているトランザクションまたはジョブがある場合、アクティビティモニターを使用してプロセスを識別して強制終了するか、SQLエージェントジョブアクティビティモニターを使用してジョブを終了します。

ソース:http : //support.microsoft.com/kb/907511


しかし、私が遭遇した問題は異なります。以下の私の答えを参照してください
Navaneet

更新してくれてありがとうございます!
Cougar9000

構文が正しくありません-等号がありません:BACKUP LOG <データベース名> TO DISK = N '<パス\ database_log.ldf';
リバースエンジニア


0

データベースを圧縮する前に、データベースに設定されているバックアップモデルに応じて、最初にバックアップを作成する必要があります。

これを実行してみてください:

USE <databasename>
GO

BACKUP DATABASE <databasename> TO DISK '<absolute path goes here>\<databasename>.bak';
GO

または、SSMSからそれを行い、利用可能なグラフィカルツールを使用することができます(詳細については、http://msdn.microsoft.com/en-us/library/ms187510.aspxを参照してください

データベースをバックアップしたら、圧縮できます。ただし、大量のインデックスの断片化が発生し、データの検索が遅くなるため、データベースを縮小することはお勧めできません。

お役に立てれば。


バックアップを行い、ログを切り捨て、ログファイルのサイズを小さくする方法を知っています。しかし、このデータベースには問題があります。名前を「dbname」とするsys.databasesからlog select それでは、ログ再利用wait_descに示されているこのdbから複製を削除する方法は?
Navaneet

どのSQL Serverバージョンを使用していますか?
トニKostelac

レプリケーションはそうSQL Serverエージェント]フォルダを開き、およびジョブフォルダを展開し、設定するレプリケーションジョブがあるかどうかを確認しますので、右クリックして、それをオフにして、停止ジョブを選択した場合、ジョブとして設定されることがあります
トニKostelac

SQL Server 2005以降を使用している場合、sp_removedbreplication 'DB_NAME'はレプリケーションを削除します。SQL Server 2000については、blogs.msdn.com / b / repltalk / archive / 2010/11/17
Kin Shah

しかし、私が遭遇した問題は異なります。私の答えを参照してください
-Navaneet

0

トランザクションログのサイズを実際に小さくするには、データベースとトランザクションログの両方を2〜3回バックアップする必要があることがわかりました。完全復旧モデルで作成されたデータベースがあります。毎晩データベースとトランザクションログのバックアップを実行しますが、トランザクションログは必然的に2〜3週間にわたって継続的に増大するようです。残りのディスク容量が1GBに達すると、トランザクションログが約30GBであることがわかります。Microsoftが推奨する手順に従い、データベースとトランザクションログの両方を4回または5回バックアップした後、トランザクションログは最終的に余分なスペースを解放して縮小します。その後、戻って、作成した複数のバックアップを削除します。


あなたは何か間違ったことをしていると思います。ログのバックアップを適切に行うと、未使用のログは切り捨てられます。私の質問にあるコマンドは、問題の解決に役立つ場合があります。
ナヴァネエト14年

-8

縮小ログファイルをブロックしているレプリケーションの回避策は次のとおりです。

  1. DB復旧モデルをシンプルに設定
  2. DBをオフラインにする
  3. ログファイルのバックアップを作成します(念のため)
  4. ログファイルを削除する
  5. DBをオンラインにする

私の場合、うまくいきました。DBをオンラインにすると、ログが自動的に作成され、サイズは70GBではなく512kbになりました。ただし、これは回避策にすぎません。根本的な問題は解決されません。私の場合、レプリケーションを使用しています。


4
これはひどいアドバイスです。トランザクションログは決して削除しないでください。破損など、あらゆる種類の問題がこれに起因する可能性があります
トムV-チームモニカ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.