私は SQL の専門家ではありませんが、基本を超えた何かをする必要があるたびに、その事実を思い出します。サイズが大きくないテスト データベースがありますが、トランザクション ログは確かに大きいです。トランザクション ログをクリアするにはどうすればよいですか?
1368549 次
21 に答える
832
ログ ファイルのサイズを小さくすることは、予期しないサイズの増加が発生し、再び発生することが予想されない場合に備えて確保する必要があります。ログ ファイルが再び同じサイズに拡大する場合、一時的に圧縮してもあまり効果はありません。ここで、データベースの復旧目標に応じて、次のアクションを実行する必要があります。
まず、完全バックアップを取ります
何か問題が発生した場合に復元できることを確認せずに、データベースに変更を加えないでください。
ポイントインタイム リカバリが必要な場合
(そして、ポイント イン タイム リカバリとは、完全バックアップまたは差分バックアップ以外に復元できることを気にしていることを意味します。)
おそらく、データベースはFULL回復モードになっています。そうでない場合は、次のことを確認してください。
ALTER DATABASE testdb SET RECOVERY FULL;
定期的に完全バックアップを取っている場合でも、ログバックアップを実行するまで、ログ ファイルはどんどん大きくなります。これは、ディスク領域を不必要に消費しないようにするためです。回復の目的に応じて、これらのログ バックアップをかなり頻繁に実行する必要があります。たとえば、災害時に 15 分以内のデータ損失を許容できるというビジネス ルールがある場合、15 分ごとにログをバックアップするジョブが必要です。これは、現在の時刻に基づいてタイムスタンプ付きのファイル名を生成するスクリプトです (ただし、メンテナンス プランなどでこれを行うこともできます。メンテナンス プランで縮小オプションを選択しないでください。ひどいものです)。
DECLARE @path NVARCHAR(255) = N'\\backup_share\log\testdb_'
+ CONVERT(CHAR(8), GETDATE(), 112) + '_'
+ REPLACE(CONVERT(CHAR(8), GETDATE(), 108),':','')
+ '.trn';
BACKUP LOG foo TO DISK = @path WITH INIT, COMPRESSION;
\\backup_share\別の基盤となるストレージ デバイスを表す別のマシン上にある必要があることに注意してください。これらを同じマシン (または、同じ基本ディスクを使用する別のマシン、または同じ物理ホスト上の別の VM) にバックアップしても、マシンが爆発するとデータベースが失われるため、実際には役に立ちません。およびそのバックアップ。ネットワーク インフラストラクチャによっては、ローカルにバックアップしてから、バックグラウンドで別の場所に転送する方が理にかなっている場合があります。どちらの場合でも、プライマリ データベース マシンからできるだけ早くそれらを削除する必要があります。
ここで、定期的なログ バックアップを実行したら、ログ ファイルをこれまでに圧縮されたものよりも適切なサイズに圧縮するのが合理的です。これは、ログ ファイルが 1 MB になるまで何度も実行するという意味ではありませんSHRINKFILE。ログを頻繁にバックアップしている場合でも、発生する可能性のある同時トランザクションの合計に対応する必要があります。ログ ファイルの自動拡張イベントは、SQL Server がファイルを消去する必要があり (ファイルの即時初期化が有効な場合のデータ ファイルとは異なり)、ユーザー トランザクションはこれが発生するまで待機する必要があるため、負荷が高くなります。あなたは、この成長、縮小、拡大、縮小のルーチンをできるだけ少なくしたいと考えており、ユーザーに料金を支払わせたくありません。
圧縮が可能になる前に、ログを 2 回バックアップする必要があるかもしれないことに注意してください (Robert に感謝します)。
したがって、ログ ファイルの実用的なサイズを考え出す必要があります。システムについて詳しく知らなければ、それが何であるかを知ることはできませんが、ログ ファイルを頻繁に縮小し、再び大きくなっている場合、適切なウォーターマークはおそらく、以前の最大値よりも 10 ～ 50% 高くなります。 . それが 200 MB になり、その後の自動拡張イベントを 50 MB にしたい場合は、次の方法でログ ファイルのサイズを調整できます。
USE [master];
GO
ALTER DATABASE Test1
MODIFY FILE
(NAME = yourdb_log, SIZE = 200MB, FILEGROWTH = 50MB);
GO
ログ ファイルが現在 200 MB を超えている場合は、最初にこれを実行する必要があることに注意してください。
USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);
GO
ポイントインタイム リカバリを気にしない場合
これがテスト データベースであり、ポイント イン タイム リカバリを気にしない場合は、データベースがSIMPLEリカバリ モードであることを確認する必要があります。
ALTER DATABASE testdb SET RECOVERY SIMPLE;
データベースを復旧モードにすると、SQL Server がすべてのトランザクションの記録を保持するために拡大するのではなく (ログをバックアップするまで復旧が行うようSIMPLEに)、ログ ファイルの一部を再利用します (基本的に非アクティブなトランザクションを段階的に除外します)。イベントは、ログを制御するのに役立ち、s 間で多くの t-log アクティビティを生成しない限り、ログが大きくなる必要がないことを確認します。FULLCHECKPOINTCHECKPOINT
次に、このログの増加が異常なイベント (たとえば、毎年恒例の春の大掃除や最大のインデックスの再構築など) によるものであり、通常の日常的な使用によるものではないことを絶対に確認する必要があります。ログ ファイルを途方もなく小さいサイズに縮小し、SQL Server が通常のアクティビティに対応するために再びサイズを大きくする必要があるとしたら、何を得ることができるでしょうか? 一時的に解放したディスク容量を活用できましたか? すぐに修正が必要な場合は、次を実行できます。
USE yourdb;
GO
CHECKPOINT;
GO
CHECKPOINT; -- run twice to ensure file wrap-around
GO
DBCC SHRINKFILE(yourdb_log, 200); -- unit is set in MBs
GO
それ以外の場合は、適切なサイズと成長率を設定してください。ポイントインタイム リカバリの例のように、同じコードとロジックを使用して、適切なファイル サイズを判断し、妥当な自動拡張パラメータを設定できます。
やりたくないこともある
TRUNCATE_ONLYオプションでログをバックアップし、SHRINKFILE次に. 1 つには、このTRUNCATE_ONLYオプションは廃止され、現在のバージョンの SQL Server では使用できなくなりました。次に、FULL復旧モデルの場合、これによりログ チェーンが破棄され、新しい完全バックアップが必要になります。データベースをデタッチし、ログ ファイルを削除して、再度アタッチします。これがどれほど危険であるかを強調することはできません。データベースが復旧しない、疑わしいと判断される、バックアップ (バックアップがある場合) に戻さなければならないなどの可能性があります。
「データベースの縮小」オプションを使用します。
DBCC SHRINKDATABASE同じことを行うメンテナンス プラン オプションは、特にログの問題を解決する必要がある場合は特に、悪い考えです。DBCC SHRINKFILEまたはALTER DATABASE ... MODIFY FILE(上記の例)を使用して、調整するファイルをターゲットにして個別に調整します。ログ ファイルを 1 MB に縮小します。これは魅力的に見えます。なぜなら、SQL Server では、特定のシナリオでそれを行うことができ、解放されるすべての領域を確認できるからです! データベースが読み取り専用である場合を除き (そうであるため、 を使用してそのようにマークする必要があります
ALTER DATABASE)、ログは復旧モデルに関係なく現在のトランザクションに対応する必要があるため、多くの不要な成長イベントが発生するだけです。そのスペースを一時的に解放して、SQL Server がゆっくりと苦労してスペースを取り戻せるようにする意味は何ですか?2 番目のログ ファイルを作成します。これにより、ディスクがいっぱいになったドライブが一時的に解放されますが、これは、パンクした肺をバンドエイドで修復しようとするようなものです. 別の潜在的な問題を追加するのではなく、問題のあるログ ファイルを直接処理する必要があります。一部のトランザクション ログ アクティビティを別のドライブにリダイレクトする以外に、2 番目のログ ファイルは (2 番目のデータ ファイルとは異なり) 実際には何もしません。一度に使用できるファイルは 1 つだけだからです。また、Paul Randal は、複数のログ ファイルが後であなたを苦しめる理由についても説明しています。
積極的に
ログファイルを少量に縮小し、それ自体で小さな速度で常に自動拡張するのではなく、ある程度大きなサイズ (同時トランザクションの最大セットの合計に対応するサイズ) に設定し、妥当な自動拡張を設定します。これにより、単一のトランザクションを満たすために複数回拡張する必要がなくなり、通常のビジネス運用中に拡張する必要が比較的まれになります。
ここで考えられる最悪の設定は、1 MB の増加または 10% の増加です。面白いことに、これらは SQL Server の既定値です (私はこれについて不平を言い、変更を求めましたが無駄でした) - データ ファイル用に 1 MB、ログ ファイル用に 10% です。前者はこの時代には小さすぎ、後者は毎回より長いイベントにつながります (たとえば、ログ ファイルが 500 MB、最初の成長が 50 MB、次の成長が 55 MB、次の成長が 60.5 MB であるとします)。などなど - そして遅い I/O では、信じてください、あなたは本当にこの曲線に気付くでしょう)。
参考文献
ここでやめないでください。ログ ファイルの圧縮に関するアドバイスの多くは、本質的に悪いものであり、破滅的な結果をもたらす可能性さえありますが、ディスク領域を解放することよりもデータの整合性を重視する人もいます。
2009 年に私が書いたブログ投稿で、「ログ ファイルを圧縮する方法は次のとおりです」という投稿がいくつか見られました。
Brent Ozar が 4 年前に書いたブログ投稿では、公開されるべきでなかった SQL Server Magazine の記事に応えて、複数のリソースを指摘しています。
Paul Randal によるブログ投稿で、t-log のメンテナンスが重要である理由と、データ ファイルを圧縮してはならない理由を説明しています。
Mike Walsh は、ログ ファイルをすぐに圧縮できない理由など、これらの側面のいくつかをカバーする優れた回答を提供しています。
于 2013-08-17T18:38:59.043 に答える
237
-- DON'T FORGET TO BACKUP THE DB :D (Check [here][1])
USE AdventureWorks2008R2;
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE AdventureWorks2008R2
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (AdventureWorks2008R2_Log, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE AdventureWorks2008R2
SET RECOVERY FULL;
GO
差出人: DBCC SHRINKFILE (Transact-SQL)
最初にバックアップすることをお勧めします。
于 2011-10-31T10:51:12.487 に答える
190
免責事項：以下のコメントを注意深く読んでください。受け入れられた回答をすでに読んでいると思います。私が5年近く前に言ったように：
これが適切または最適な解決策ではない場合に追加するコメントがある場合は、以下にコメントしてください
データベース名を右クリックします。
タスクを選択→縮小→データベース
次にクリックOK！
私は通常、データベース ファイルを含む Windows Explorer ディレクトリを開くので、すぐに効果を確認できます。
私は実際にこれがうまくいったことにかなり驚きました！通常、以前はDBCCを使用していましたが、それを試しただけで何も縮小しなかったため、GUI（2005）を試してみましたが、うまく機能しました-10秒で17 GBを解放しました
完全復旧モードではこれが機能しない可能性があるため、最初にログをバックアップするか、単純復旧に変更してからファイルを圧縮する必要があります。[@onupdatecascade に感謝]
--
PS: これの危険性についてコメントしてくださったことに感謝しますが、私の環境では、特に最初に完全バックアップを行うため、自分でこれを行うことに問題はありませんでした. したがって、続行する前に、環境がどのようなものであるか、およびこれがバックアップ戦略とジョブのセキュリティにどのように影響するかを考慮してください。私がしていたのは、Microsoft が提供する機能を人々に紹介することだけでした!
于 2009-01-19T20:31:50.693 に答える
56
以下はトランザクションログを縮小するためのスクリプトですが、縮小する前にトランザクションログをバックアップすることを強くお勧めします。
ファイルを縮小するだけでは、災害時に命の恩人となる可能性のある大量のデータが失われます。トランザクションログには、サードパーティのトランザクションログリーダーを使用して読み取ることができる多くの有用なデータが含まれています（手動で読み取ることはできますが、非常に手間がかかります）。
トランザクションログは、ポイントインタイムリカバリに関しても必須であるため、単に破棄するのではなく、事前にバックアップしておく必要があります。
トランザクションログに保存されているデータを使用してリカバリを実行した投稿は次のとおりです。
USE DATABASE_NAME;
GO
ALTER DATABASE DATABASE_NAME
SET RECOVERY SIMPLE;
GO
--First parameter is log file name and second is size in MB
DBCC SHRINKFILE (DATABASE_NAME_Log, 1);
ALTER DATABASE DATABASE_NAME
SET RECOVERY FULL;
GO
上記のコマンドを実行すると、次のようなエラーが発生する場合があります
「ファイルの最後にある論理ログファイルが使用されているため、ログファイル（ログファイル名）を縮小できません」</ p>
これは、TLOGが使用中であることを意味します。この場合、これを連続して数回実行するか、データベースアクティビティを減らす方法を見つけてください。
于 2013-03-18T12:16:45.517 に答える
30
復元にトランザクション ログを使用しない場合 (つまり、フル バックアップのみを行う場合)、リカバリ モードを「シンプル」に設定すると、トランザクション ログはすぐに縮小され、再びいっぱいになることはありません。
SQL 7 または 2000 を使用している場合は、データベース オプション タブで「チェックポイントでログを切り捨てる」を有効にできます。これは同じ効果があります。
特定の時点に復元できないため、これは明らかに本番環境ではお勧めできません。
于 2008-09-15T14:31:27.220 に答える
9
SQL Server トランザクション ログは、不要な増大を防ぐために適切に維持する必要があります。これは、トランザクション ログのバックアップを十分頻繁に実行することを意味します。そうしないと、トランザクション ログがいっぱいになり、大きくなり始める危険があります。
この質問への回答に加えて、トランザクション ログの一般的な神話を読んで理解することをお勧めします。これらの読み取り値は、トランザクション ログを理解し、それを「クリア」するために使用する手法を決定するのに役立ちます。
10 の最も重要な SQL Server トランザクション ログの神話から:
誤解: SQL Server がビジー状態です。SQL Server トランザクション ログのバックアップを作成したくない
SQL Server で最大のパフォーマンス集中型操作の 1 つは、オンライン トランザクション ログ ファイルの自動拡張イベントです。トランザクション ログのバックアップを十分な頻度で作成しないと、オンライン トランザクション ログがいっぱいになり、増大しなければならなくなります。デフォルトの成長サイズは 10% です。トランザクション ログ バックアップが作成されていない場合、データベースがビジーであるほど、オンライン トランザクション ログが急速に拡大します。SQL Server トランザクション ログ バックアップを作成しても、オンライン トランザクション ログはブロックされませんが、自動拡張イベントはブロックします。オンライントランザクションログのすべてのアクティビティをブロックできます
神話: 定期的なログの縮小は、優れたメンテナンス方法です
間違い。新しいチャンクをゼロにする必要があるため、ログの増加には非常にコストがかかります。ゼロ化が完了するまで、そのデータベースでのすべての書き込みアクティビティは停止します。ディスクの書き込みが遅いか、自動拡張サイズが大きい場合、その一時停止は非常に大きく、ユーザーは気付くでしょう。これが、成長を避けたい理由の 1 つです。ログを縮小すると、ログは再び大きくなり、不必要な縮小と拡大を繰り返すゲームでディスク操作を浪費するだけです
于 2015-06-10T11:41:04.310 に答える
9
これまでのほとんどの回答は、実際にはトランザクション ログ ファイルが必要ないことを前提としていますが、データベースがFULL復旧モデルを使用していて、データベースを復元する必要がある場合に備えてバックアップを保持したい場合は、切り捨てたり削除したりしないでください。これらの回答の多くが示唆する方法でログファイルを作成します。
ログ ファイルを (切り詰める、破棄する、消去するなどして) 削除すると、バックアップ チェーンが壊れ、最後の完全バックアップ、差分バックアップ、またはトランザクション ログ バックアップ以降の任意の時点に復元できなくなります。または差分バックアップが作成されます。
マイクロソフトの記事よりBACKUP
NO_LOG または TRUNCATE_ONLY を使用して手動でトランザクション ログを切り捨てることはお勧めしません。これにより、ログ チェーンが壊れてしまうためです。次の完全バックアップまたは差分データベース バックアップまで、データベースはメディア障害から保護されません。非常に特殊な状況でのみ手動でのログの切り捨てを使用し、データのバックアップをすぐに作成してください。
これを回避するには、ログ ファイルを圧縮する前にディスクにバックアップします。構文は次のようになります。
BACKUP LOG MyDatabaseName
TO DISK='C:\DatabaseBackups\MyDatabaseName_backup_2013_01_31_095212_8797154.trn'
DBCC SHRINKFILE (N'MyDatabaseName_Log', 200)
于 2013-01-31T15:02:35.337 に答える
5
コマンドを使用しDBCC ShrinkFile ({logicalLogName}, TRUNCATEONLY)ます。これがテスト データベースであり、スペースを節約/再利用しようとしている場合は、これが役に立ちます。
ただし、TX ログには一定の最小/定常状態のサイズがあり、それが最大になることを覚えておいてください。リカバリ モデルによっては、ログを圧縮できない場合があります。FULL で TX ログ バックアップを発行していない場合、ログは圧縮できません。ログは永久に大きくなります。TX ログのバックアップが必要ない場合は、復旧モデルをSimpleに切り替えます。
また、決してログ (LDF) ファイルを削除しないでください。ほとんどの場合、すぐにデータベースが破損します。調理済み！終わり！データ紛失！「修復しない」ままにしておくと、メインの MDF ファイルが完全に破損する可能性があります。
決してトランザクション ログを削除しないでください。データが失われます。データの一部は (復旧モデルに関係なく) TX ログにあります...データベースの一部を効果的に削除する TX ログ ファイルを切り離して「名前を変更」すると。
TX ログを削除した場合は、いくつかの checkdb コマンドを実行して、さらにデータを失う前に破損を修正することをお勧めします。
まさにこのトピックに関する Paul Randal のブログ記事、悪いアドバイスを確認してください。
また、データが大幅に断片化される可能性があるため、一般的には MDF ファイルで Shrinkfile を使用しないでください。詳細については、彼の悪いアドバイスのセクションを参照してください (「データ ファイルを圧縮しない理由」)。
ポールのウェブサイトをチェックしてください - 彼はまさにこれらの質問をカバーしています. 先月、彼はMyth A Dayシリーズでこれらの問題の多くを取り上げました。
于 2010-05-24T15:50:36.783 に答える
4
ほとんどの SQL Server での私の経験では、トランザクション ログのバックアップはありません。完全バックアップまたは差分バックアップは一般的な方法ですが、トランザクション ログのバックアップはほとんどありません。したがって、トランザクション ログ ファイルは永久に (ディスクがいっぱいになるまで) 大きくなります。この場合、復旧モデルは「シンプル」に設定する必要があります。システム データベース「model」と「tempdb」も変更することを忘れないでください。
データベース「tempdb」のバックアップは意味がないため、このデータベースの復旧モデルは常に「単純」でなければなりません。
于 2008-09-23T16:41:23.010 に答える
4
データベース ログ ファイルが 28 GB の場合に発生しました。
これを減らすために何ができますか？実際、ログ ファイルは、トランザクションが発生したときに SQL サーバーが保持するファイル データです。トランザクションを処理するために、SQL サーバーは同じページを割り当てます。しかし、トランザクションが完了した後、同じようなトランザクションが来ることを期待して、これらは突然解放されるわけではありません。これでスペースが確保されます。
ステップ 1: まず、データベース クエリの探索チェックポイントでこのコマンドを実行します。
ステップ 2: データベースを右クリックします。 [タスク] > [バックアップ] バックアップ タイプを [トランザクション ログ] として選択します。 バックアップ データ (.bak) を保持するための宛先アドレスとファイル名を追加します。
この手順をもう一度繰り返し、この時点で別のファイル名を付けます
ステップ 3: データベースに移動します データベースを右クリックします
タスク > 縮小 > ファイル 未使用領域の解放として、ログ縮小アクションとしてファイル タイプを選択します。
ステップ 4:
通常、SQL 2014 でログ ファイルを確認します。これは次の場所にあります。
C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQL2014EXPRESS\MSSQL\DATA
私の場合、28 GB から 1 MB に減りました。
于 2018-02-02T15:15:55.027 に答える
3
- MDBファイルのバックアップを取ります。
- SQLサービスを停止します
- ログファイルの名前を変更します
- サービスを開始します
（システムは新しいログファイルを作成します。）
名前を変更したログファイルを削除または移動します。
于 2011-06-17T14:52:07.633 に答える
3
ログ ファイルを切り捨てるには:
- データベースのバックアップ
- Enterprise Manager を使用するか、Sp_DetachDB [DBName]を実行して、データベースを切り離します。
- トランザクション ログ ファイルを削除します。（または念のため、ファイルの名前を変更します）
- Sp_AttachDB [DBName]を使用して、データベースを再度アタッチします。
- データベースが接続されると、新しいトランザクション ログ ファイルが作成されます。
ログファイルを圧縮するには:
- ログ [DBName] を No_Log でバックアップ
次のいずれかでデータベースを縮小します。
Enterprise Manager の使用:- データベースを右クリックし、[すべてのタスク]、[データベースの圧縮]、[ファイル]、[ログ ファイルの選択]、[OK] の順にクリックします。
T-SQL の使用 :- Dbcc Shrinkfile ([Log_Logical_Name])
sp_helpdb を実行するか、Enterprise Manager でデータベースのプロパティを調べると、ログ ファイルの論理名を見つけることができます。
于 2008-09-14T18:44:25.780 に答える
1
これを試して：
USE DatabaseName
GO
DBCC SHRINKFILE( TransactionLogName, 1)
BACKUP LOG DatabaseName WITH TRUNCATE_ONLY
DBCC SHRINKFILE( TransactionLogName, 1)
GO
于 2011-01-03T12:58:22.527 に答える
0
- バックアップDB
- DB を切り離す
- ログファイルの名前を変更
- DB をアタッチします (アタッチ中に、名前が変更された .ldf (ログ ファイル) を削除します。それを選択し、[削除] ボタンを押して削除します)
- 新しいログ ファイルが再作成されます
- 名前を変更したログ ファイルを削除します。
これは機能しますが、最初にデータベースのバックアップを取ることをお勧めします。
于 2010-12-01T08:12:56.053 に答える
-2
DB トランザクション ログを最小サイズに縮小:
- バックアップ: トランザクション ログ
- ファイルの圧縮: トランザクション ログ
- バックアップ: トランザクション ログ
- ファイルの圧縮: トランザクション ログ
いくつかの DB でテストを行いました。このシーケンスは機能します。
通常は2MB に縮小されます。
またはスクリプトによる:
DECLARE @DB_Name nvarchar(255);
DECLARE @DB_LogFileName nvarchar(255);
SET @DB_Name = '<Database Name>'; --Input Variable
SET @DB_LogFileName = '<LogFileEntryName>'; --Input Variable
EXEC
(
'USE ['+@DB_Name+']; '+
'BACKUP LOG ['+@DB_Name+'] WITH TRUNCATE_ONLY ' +
'DBCC SHRINKFILE( '''+@DB_LogFileName+''', 2) ' +
'BACKUP LOG ['+@DB_Name+'] WITH TRUNCATE_ONLY ' +
'DBCC SHRINKFILE( '''+@DB_LogFileName+''', 2)'
)
GO
于 2011-01-11T10:20:17.640 に答える