0

138GBのデータベース.mdfファイルと55GBのトランザクションログファイルがあります。

リカバリモデルはフルに設定されました（フルに設定する必要はありません）。データベースとトランザクションログの完全バックアップを実行しました。トランザクションログは55GBのままで、ファイルを縮小するための空き領域がありません。

そのバックアップはSQLServerManagementStudioGUIを介して実行しました。次に、次のコマンドを実行して、トランスログを強制的に縮小しようとしました。

BACKUP LOG database WITH TRUNCATE_ONLY
DBCC SHRINKFILE (logfile, TRUNCATEONLY )

ログファイルはまだ55GBです。次に、リカバリモデルをに変更しSimple、数日間そのままにしましたが、まだ55GBです。上記の2つのコマンドをもう一度試しましたが、それでも何も切り捨てられません。

何を試しても、このログファイルは縮小しません。トランザクションログはまったく必要ないので、データベースをデタッチし、ログファイルの名前を変更して、再度アタッチしてみました。実際には2つのトランザクションログがあるため、これも機能しません。ログなしで再接続しようとするとエラーが発生します。もう1つのログファイルはわずか1MBで、これも削除しようとしましたが、空ではないというエラーも表示されます。

足りないもの、または他に試すことができるものはありますか？

助けてくれてありがとう！

4

7 に答える 7

2

トランザクション ログを圧縮する必要があるまれなケースでは、SQL Server 2005 で試したコマンドとは少し異なるコマンドを使用します。

backup log database with no_log
dbcc shrinkfile (logfile,1)

(...with no_logの代わりに...with truncate_only、 の 2 番目のパラメーターはdbcc shrinkfileログ ファイルの新しいサイズにする必要があります)

ログ ファイルの名前を正しく取得するために (データベースの名前を入力するのが面倒なので)、データベースとログ ファイルの名前を自動的に取得する次のスクリプトを使用します。

declare @dbname varchar(255)
declare @logfile varchar(255)

select @dbname = db_name()
select @logfile = name from sysfiles where filename like '%.ldf'

backup log @dbname with no_log
dbcc shrinkfile (@logfile,1)

ログファイルを圧縮したいデータベースで直接実行する必要があります。
免責事項：あなたのような複数のログファイルを持つデータベースで使用したことはありません。デフォルトで間違ったログファイルが見つかった場合は、変更する必要があるかもしれません。

とにかく回復モードSimpleが必要ない場合は、スクリプトを実行する前に回復モードをに設定できます。Full

また、ログを圧縮した直後に完全バックアップを取る必要があります。これは、データベースをリカバリ モード
のままにしておく場合に非常に重要Fullです。
(ログを圧縮するとログ チェーンが壊れるため、次の完全バックアップを実行するまで、後続のログ バックアップは役に立たなくなります)

于 2012-05-10T23:19:48.830 に答える
0

それはms sqlサーバーの問題でしたが、ここに解決策があります....

データベースを強制的に切り捨てるには、ff を実行します。

  1. 縮小する前にデータベースの完全バックアップを実行する
  2. リカバリをフルからシンプルに設定
  3. dbcc シュリンクファイル
  4. 回復を完全に戻す
  5. 圧縮後にフル db バックアップを実行する

これが強制収縮のコードです

 use master
 Alter database dbname set Recovery simple; 

 use dbname
 DBCC SHRINKFILE (dbname_log, 0, TRUNCATEONLY)
 Alter database dbname set Recovery full;

お役に立てれば。

于 2012-05-11T02:23:46.273 に答える
0

まず、ログファイルの初期サイズを小さく設定できますか? 誰かが 55GB で開始した場合、それより低くなることはありません。

次に、おそらく2 つのトランザクション ログは必要ありません。2 番目は「アクティブ」になりますが、最初のものがいっぱいになるまで使用されません。拡張が制限されておらず、まだディスク容量が残っている場合、最初の容量がいっぱいになることはありません。

3番目に、@JohnNolanが提案したように（そして私が提案しようとしていたように）、チェックポイントを試してください。これにより、単純な復旧モデルでログの切り捨てが可能になるはずです。

また、使用を避けることをTRUNCATE_ONLYお勧めします。

于 2012-05-10T21:57:52.047 に答える
0

これをトラブルシューティングする方法：

1) name = 'your_db_name' である sys.databases から log_reuse_wait_desc を選択します。

これにより、VLF の再利用を妨げているものがわかります。遅い期間中 (つまり、ログがあまり使用されていない場合、これは 'NONE' であるべきです)。別の値が表示される場合は、トラブルシューティングが必要になる場合があります。

2) dbcc loginfo の出力を見てください。ログ ファイルにある VLF ごとに 1 行が返されます。ステータス列は、VLF が使用中かどうかを示します。ログを圧縮するには、未使用の VLF をファイルの末尾に配置する必要があります。これを行うには、自然な活動を待つ必要がある場合があります。VLF は一種のリングで使用されるため、未使用の VLF は最終的にファイルの最後にあるはずです。

于 2012-05-11T03:08:07.287 に答える
0

http://msdn.microsoft.com/en-us/library/ms188748.aspxを設定してみてくださいcheckpoint

これにより、すべてのダーティ ページがディスクに書き込まれ、現在のデータベースのバッファ キャッシュからログ ページがフラッシュされ、リカバリ中にロール フォワードする必要がある変更の数が最小限に抑えられます。新しい最小回復ログ シーケンス番号 (lsn) を作成し、その lsn より前のすべてのレコードを削除して、ファイルを縮小します。

于 2012-05-10T21:52:41.693 に答える
0

「データベースをデタッチして、ログ ファイルの名前を変更して再アタッチしてみました」: ログはオプションのコンポーネントではありません。DBCC CHECKDB をすぐに実行して、破損が発生したかどうかを確認します。何らかの理由でフラッシュされていないページがあった場合、破損が発生します。そうでなくてもギャンブルです。

SQL Server ログ ファイルは、情報を提供するテキスト ログではありません。

ログが必要ない場合は、簡易モードに切り替えてログ ファイルを圧縮します (既に実行済みです)。TRUNCATE_ONLY は廃止されました。何かを行うかどうかはわかりません。

sys.databasesを見て、log_reuse_wait_desc 列の値を見てください。ログを維持しているものがわかります。

于 2012-05-10T21:56:28.250 に答える
0

以下のクエリを使用します。

backup log [dbname] with truncate_only
go
DBCC SHRINKDATABASE ([dbname], 10, TRUNCATEONLY)
go
于 2014-10-27T09:12:37.740 に答える