Biztalkサーバーの1つに関する問題の分析を依頼されました。特定のドライブの空き容量を増やすように求められましたが、BiztalkMsgBoxDB_log.bakファイルがドライブの90%近くを占めていることがわかりました。次のクエリを実行すると、後で使用されたログスペースがわずか1.25%であることがわかりました。
EXEC( 'DBCC sqlperf(LOGSPACE)WITH NO_INFOMSGS')
**Database Name** **Log Size (MB)** **Log Space Used (%)** **Status**
BizTalkMsgBoxDb 24930.49 1.257622 0
現在、リカバリモードは:FULLであり、トランザクションログのバックアップは1時間前に取得されました。
ログファイルがなぜこれほど大きく作成されたのか、私にはわかりません。このドライブのデータを解放するにはどうすればよいですか。
ログを縮小する必要があります。削除しないでください!
SQL Server MGMNT Studioで、データベースを右クリックし、[タスク]> [縮小]> [ファイル]を選択します。下の図のようにログを選択し(または適切なサイズに縮小して)、[OK]をクリックします。
後で自動拡張の設定を確認し、制限を設定して、将来これが発生しないようにすることをお勧めします。
私が最もお勧めするのは、ログファイルを別のディスク(またはディスクを追加できない場合はパーティション)に置くことです。そうすれば、ログファイルは他に何も中断することなくドライブをいっぱいにすることができます。 (ちなみにtempdbについても同じことが言えます)。
これを実行した後もログファイルがこれほど大きいままである場合は、アクションをブロックしているトランザクションがまだ存在する可能性があります。 sp_who2
または sp_whoisactive
で見つけて、停止できるかどうかを確認してください。殺すだけでなくボーナスポイント。
どこかでレプリケーションに固執していないことを確認してください。 DBをシンプルモードにしてフルに戻すこともできますが、これは最後の手段です。後でバックアップを確認することを忘れないでください!
SQL Serverが実行されていると仮定すると、ファイルを実際に削除することはできません。ファイルは、実際にはSQLServerで使用されているデータベースのログファイルです。名前が.bak
で終わることを確認しました。これは通常、SQL ServerBackupファイル用に予約されており、logファイル。通常、ログファイルの拡張子は.ldf
です。それが実際にバックアップファイルである場合は、削除できます。ただし、SQL Serverがそのファイルに対して定期的にバックアップを作成している場合は、もちろん、次にバックアップが実行されたときに再表示されます。バックアップファイルはディザスタリカバリにとって重要である可能性があるため、おそらく削除したくないでしょう。
SQL Serverログファイルには、データベース自体に加えられたすべての変更のレコードが含まれています。ログをバックアップすると、通常、ファイルの一部が再利用できるようにマークされます。したがって、バックアップを作成した後にDBCC LOGPERF
を見ると、ログファイルが1%しかないのに、なぜ「非常に大きい」のか不思議に思うかもしれません。使用する。 SQL Servermayは、次回ファイルをそのサイズに戻すだけなので、縮小する前に、ファイルの必要なサイズを確認する必要があります。メンテナンスはデータベースに対して実行されます。ログファイルが大きくなる理由はたくさんありますが、大きくなると、一時的に応答時間が大幅に遅くなります。 dba.stackexchange.com サイトの詳細については、 この質問 および回答を参照してください。