まず、データベースで完全復旧モードを使用しており、SQL Server 2014を実行していると言います。
過去数日間、バックアップが急増して制御不能になり、完全/差分バックアップが失敗し、非常に大規模なトランザクションバックアップのみが作成されました。もちろん、これによりディスク容量の問題が発生し、順序を復元するためにかなりの手動操作が必要になりました。
各データベースで手動でフルバックアップを実行してから、トランザクションバックアップを実行してフォローアップを試みました。この期間中、1つのデータベースのログファイルのサイズが増加し、ディスク領域が不足するまでになりました。通常、ログファイルは約1 GBですが、現在は約30 GBになっています。
トランザクションバックアップを実行してもログファイルのサイズは減少せず、ログファイルがいっぱいになり、ディスクに空き領域がなくなってしまいました。最後の努力として、私はSHRINKFILE(dbname、4096)を実行しました。これにより、即座にサイズが縮小され、すべて正常に見えました。
そうした後、バックアップが機能しておらず、エラーを受け取っていました。
データエラー(巡回冗長検査)が失敗しました。 CheckDBを実行しようとすると、次のメッセージが表示されました。
現在のコマンドで重大なエラーが発生しました。結果があれば破棄します。
データベースをバックアップできなかったため、その日の早い段階から、フルバックアップと作成した1つのトランザクションバックアップをオフにして復元することを決定しました。これらのファイルはどちらも大きかった。トランザクションバックアップが1つしかなかったのは、事態がさらに制御不能にならないように、ジョブの実行を無効にしたためです。
新しいDBは稼働しており、バックアップは正常に機能しますが、大きなログファイルの問題が依然として発生しています。現在、トランザクションバックアップは非常に小さいですが、DBを縮小できないようです。
誰かアイデアはありますか?または、元のデータベースの冗長性の問題を解決する方法がある場合は、データの損失がないため、これが望ましい解決策になります。
開いているトランザクションはありません。 _log_reuse_wait_desc
_は "LOG_BACKUP"です。これは、ログバックアップが実行されるのを待っていることを理解しています。私はいくつかのことをしたので、これは狂気です;)dbcc sqlperf(logspace)
は、92%のスペースを使用していると主張しています。
ログのバックアップは通常の状況では15分ごとに実行されますが、前述したように、週末は失敗していました。当面は、ドライブがいっぱいになるのをやめるためにオフにし、トランザクションバックアップを手動で実行しています。データベースは現在稼働していないため、そこに追加のデータはありません。過去1時間程度のテストとして、おそらく4つのトランザクションバックアップを実行しました。
ここでは、レプリケーション、ミラーリング、AOAGのいずれも構成されていません。
ログバックアップの頻度はどのくらいですか?
Dbcc sqlperf(logspace)を使用して、ログの空き領域の割合(%)を確認します。
ログを保持しているものがあります。そのデータベースのlog_reuse_wait_descを確認し、それに応じてアクションを実行します。
以下の記事に従ってください:
https://www.brentozar.com/archive/2016/03/my-favorite-system-column-log_reuse_wait_desc/
データベースのsys.databasesのlog_reuse_wait_descは、2つの状況でLOG_BACKUPを表示できます。