web-dev-qa-db-ja.com

SQL Server：ログファイルの縮小

SCCM 2012 r2 Reporting servicesを実行しています。バックアップが適切に設定されていないため、SQL Serverログファイルが使用できなくなりました。続行する前に何かを確認したいと思います。

DBのフルバックアップを実行するようにバックアップソリューションを設定し、定期的なスケジュールでログを切り捨てるように設定された増分バックアップを設定しましたが、私が読んだ内容から、パフォーマンスの問題によりログファイルを縮小することは悪い考えです。しかし、ログファイル用に約220GBを座っているため、これは適切なケースのようです。

まず、私は間違いなくログファイルを圧縮しようとしているのでしょうか。それを行うための最良の方法は何ですか。単にDBCC SHRINKFILE？

次に、縮小後のログファイルのサイズに適切な制限を設定する必要があると思いますが、この制限をどのように作成するかわかりません。それはちょうど中間の切り捨てバックアップを取るのに満足しているサイズですか、それともベストプラクティスがありますか？.

ご存知かもしれませんが、私はSQL Serverにあまり慣れていないので、間違った言葉を言ったら申し訳ありません。前もって感謝します。

sql-serversql-server-2012shrinktruncate
2
Crimsonfox

フルバックアップと増分/差分バックアップに加えて、ログファイルで切り捨てを行う代わりに、ログファイルのすべての場所にコミット済みのエントリを再利用可能としてマークするために、トランザクションログのバックアップを妥当な頻度で行う必要があります。正しいサイズのログファイルを使用すると、トランザクションログバックアップはログファイルが継続的に増大するのを防ぐのに役立ち、予測したバックアップウィンドウの間に大量の変更が発生した場合にのみ増大する可能性があります。

次に、ログファイルの圧縮について説明します。ログファイルを圧縮することは必ずしも悪いことではありません。正しく実行するには、少し計画が必要です。 （これは、開始する前に、他のユーザーが接続していない状態で可能な場合は、完全バックアップのあるメンテナンスウィンドウで実行していることを確認してください。）DBCCの縮小コマンドを使用して、1MBに減らすことができますが、データベースで発生している変更の割合に適したサイズにログファイルを再成長させ、通常の量よりも多いデータ変更を処理するための空き領域バッファを追加します。また、特定の一定の増分でログファイルを拡張すると、ログのパフォーマンスに役立つ均等なサイズのVLFが作成されます。たとえば、それを1MBに縮小した後、5GBのサイズに達するまで、ログファイルを1GBの増分で再成長させます。

Kimberly Trippには、 VLFs および トランザクションログのスループット を説明する優れた記事がいくつかあります。ログファイルを4 GB増やすことに関するバグについての彼女の警告に注意してください。

ここに別の [〜＃〜] vlf [〜＃〜] からの参照 Brent Ozar からの参照があり、さらに詳細があり、キンバリーの投稿も参照しています。

注目に値します。ありがとう@BradC。ログファイルの縮小と再成長は、ログファイルが大きくなり、VLFのサイズが不均一になる場合にのみ、一度だけ実行する必要があります。ただし、ログファイルの自動拡張サイズを、元々1MBから拡張するために使用された特定のサイズ増分に設定すると、自動拡張後でもVLFが不均一になることはありません。

2
Aaron

データベースは完全復旧モードのようですが、トランザクションログのバックアップを実行していません。これは互換性のある組み合わせではありません。

2つの選択肢があります。

  1. 完全復旧モードのままにして、完全バックアップと差分バックアップに加えて、定期的なトランザクションログバックアップを作成（および保持）します。
  2. simpleリカバリモードに切り替えます。

これはビジネス上の決定であり、技術的な決定ではないことに注意してください。

完全復旧モードは、「ポイントインタイム」復旧、任意のポイントに巻き戻す機能完全/差分バックアップ間何か問題が発生した場合にのみ必要です。

データベースがシンプルリカバリモードで、何か問題が発生した場合（破損、誰かがテーブルを削除したなど）、最新の完全バックアップまたは差分バックアップに戻る必要があり、データベースに加えられた最新の変更が失われる可能性があります。ただし、特定の種類のデータベース（レポート/処理データベース、開発/テスト/ QA環境など）の場合、これは許容されます。

どのモードをサポートする必要があるかを決定し、適切な変更を行ったら、tranログのサイズが増減しません。次のようなクエリを使用して、ファイル内で実際に使用されている内部スペースの量を確認します。

SELECT DB_NAME() as dbname, type_desc, name as logical_name, 
    CONVERT(decimal(12,1),size/128.0) as TotalMB,
    CONVERT(decimal(12,1),FILEPROPERTY(name,'SpaceUsed')/128.0) as UsedMB,
    CONVERT(decimal(12,1),(size - FILEPROPERTY(name,'SpaceUsed'))/128.0) as FreeMB,
    physical_name
FROM sys.database_files WITH (NOLOCK)
ORDER BY type, file_id;

Tranログバックアップの間に、ログファイルの「使用済み」スペースが増加することがわかります。ログバックアップが実行されると、そのスペースは減少するはずです。合計ファイルサイズは同じままにする必要があります。ログファイルを、表示されている最大の「使用済み」値に加えて、たとえば20％まで縮小し、2GBまたは4GBの拡張設定のままにして、必要に応じて少し拡張できるようにすることをお勧めします。

1
BradC

ログの圧縮に関する主なパフォーマンスの問題は、（あなたのような異常な状況以外では）ログを再び大きくする必要があるという事実です。実際には、ログファイルをデータファイルよりも大きくするのに時間がかかることがあります（データファイルの新しいスペースは、基本的に「空き」としてマークできます。新しいログファイルのスペースは、実際にはゼロで上書きする必要があります）。さらに、ログファイルを縮小してから、そのスペースを別のスペースに使用した場合、ログファイルを拡大する必要がある場合、拡大できないことがあります。

DBCC SHRINKFILEは私が使用するものです。疑わしい場合は、yououがSSMSを介して必要な設定を行い（DBを右クリックし、[タスク]-> [縮小]-> [ファイルの縮小]を選択）、スクリプトを生成します。基本的には、縮小するファイルとターゲットサイズを指定するだけです。

通常、ログファイルの圧縮はすぐに行われます。ただし、ファイルが圧縮されていなくてもエラーは発生しません。 SQLはログファイルを再配置してファイルの最後のスペースを解放しません。また、dは最後からスペースを削除するだけです。必要に応じて、コマンドを複数回発行します。これにより、ログ内の現在のアクティビティポイントをシフトし、それを最後まで移動するのに十分なアクティビティを生成できます。他のすべてが失敗した場合は、後で再試行してください。

ログファイルの増加を制限することはできますが、ある時点で許可されているよりも多くのスペースが必要になる可能性があり、ログがいっぱいであるために操作が失敗します。空き容量がある場合は、ログを定期的にチェックして、すべてが正常に見えることを確認します。

0
RDFozz