SQL Server のトランザクションログをクリアするにはどうすればよいですか?

https://stackoverflow.com/questions/56628

09-06-2019
|

質問

私は SQL の専門家ではないので、基本を超えた何かをする必要があるたびにその事実を思い出します。サイズが大きくないテストデータベースがありますが、トランザクションログは間違いなく大きくなります。トランザクションログを消去するにはどうすればよいですか?

解決

ログファイルのサイズを小さくするのは、二度と起こらないと思われる予期せぬ増大が発生した場合のシナリオのために確保する必要があります。ログファイルが再び同じサイズに増加する場合、一時的に縮小してもあまり効果はありません。ここで、データベースの回復目標に応じて、次のアクションを実行する必要があります。

まず、完全バックアップを取得します

何か問題が発生した場合にデータベースを復元できることを確認せずに、データベースに変更を加えないでください。

ポイントインタイムリカバリを重視する場合

(ポイントインタイムリカバリとは、完全バックアップまたは差分バックアップ以外に復元できるかどうかを重視していることを意味します。)

おそらくデータベースは次のとおりです 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) にバックアップしても、あまり役に立ちません。マシンが故障するとデータベースが失われるためです。 そして そのバックアップ。ネットワークインフラストラクチャによっては、ローカルにバックアップしてから、バックグラウンドで別の場所に転送する方が合理的な場合があります。いずれの場合も、プライマリデータベースマシンからできるだけ早くそれらを削除する必要があります。

定期的なログバックアップを実行したら、ログファイルをこれまでのサイズよりも適切なサイズに圧縮するのが合理的になるはずです。これはそうなりますない走るという意味 SHRINKFILE ログファイルが 1 MB になるまで何度も繰り返します。ログを頻繁にバックアップする場合でも、発生する可能性のある同時トランザクションの合計に対応する必要があります。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;

データベースを入れる SIMPLE リカバリモードでは、SQL Server がログファイルの記録を保持するために拡張するのではなく、ログファイルの一部を再利用します (基本的に非アクティブなトランザクションを段階的に廃止します)。全てトランザクション（のような FULL リカバリはログをバックアップするまで行われます)。 CHECKPOINT イベントはログの制御に役立ち、次の期間に大量の t-log アクティビティを生成しない限り、ログが増大する必要がないようにします。 CHECKPOINTs.

次に、このログの増加が本当に異常なイベント (年に一度の春の大掃除や最大のインデックスの再構築など) によるものであり、日常的な通常の使用によるものではないことを絶対に確認する必要があります。ログファイルをとんでもなく小さいサイズに縮小し、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. 。一つには、これ 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 の記事に応えて複数のリソースを指摘しています。ない出版されました.

t-log メンテナンスが重要である理由を説明した Paul Randal によるブログ投稿そしてデータファイルも圧縮すべきではない理由.

Mike Walsh は、ログファイルをすぐに縮小できない理由など、これらの側面のいくつかをカバーする素晴らしい回答を提供しています。.

他のヒント

免責事項: 以下のコメントを注意深く読んでください。受け入れられた回答はすでに読んでいると思います。5年近く前に私が言ったように：

これが適切または最適なソリューションではない状況に追加するコメントがある場合は、以下にコメントしてください

データベース名を右クリックします。
「タスク」→「縮小」→「データベース」を選択します。
次にクリックします わかりました!

私は通常、データベースファイルを含む Windows エクスプローラーディレクトリを開くので、その効果をすぐに確認できます。

実際、これがうまくいったことにかなり驚きました！通常、以前は DBCC を使用していましたが、試してみたところ何も縮小されなかったので、GUI (2005) を試してみたところ、うまくいきました。10 秒で 17 GB を解放できました。

完全回復モードではこれが機能しない可能性があるため、最初にログをバックアップするか、単純回復に変更してからファイルを圧縮する必要があります。[@onupdatecascade に感謝します]

追伸：この危険性についてコメントしていただいた方の意見は承知していますが、私の環境では、特に最初に必ず完全バックアップを行うので、自分でこれを行うのに問題はありませんでした。したがって、続行する前に、ご使用の環境がどのようなものであるか、またそれがバックアップ戦略や雇用の安全にどのような影響を与えるかを考慮してください。私がしていたのは、Microsoft が提供する機能を人々に紹介することだけでした。

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)

最初にバックアップすることをお勧めします。

以下はトランザクションログを圧縮するスクリプトですが、圧縮する前にトランザクションログをバックアップすることを強くお勧めします。

ファイルを圧縮するだけでは、災害時に救命手段となる可能性のある大量のデータが失われることになります。トランザクションログには、サードパーティのトランザクションログリーダーを使用して読み取ることができる多くの有用なデータが含まれています (手動で読み取ることもできますが、非常に手間がかかります)。

トランザクションログはポイントインタイムリカバリの際にも必須であるため、ただ捨てずに、必ず事前にバックアップしてください。

以下に、トランザクションログに保存されたデータを使用して回復を達成したいくつかの投稿を示します。

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

上記のコマンドを実行すると、次のようなエラーが発生する場合があります。

「ファイルの最後にある論理ログファイルが使用されているため、ログファイル（ログファイル名）を縮小できません」

これはTLOGが使用されていることを意味します。この場合は、これを数回続けて実行するか、データベースのアクティビティを減らす方法を見つけてください。

復元にトランザクションログを使用しない場合 (つまり、完全バックアップのみを実行する場合)、リカバリモードを「シンプル」に設定すると、トランザクションログはすぐに縮小し、再びいっぱいになることはありません。

SQL 7 または 2000 を使用している場合は、データベースオプションタブで「チェックポイントでのログの切り捨て」を有効にすることができます。これも同様の効果があります。

特定の時点に復元できないため、これは運用環境では明らかに推奨されません。

ここではシンプルで、 とても品がない & 潜在的に危険な 方法。

バックアップDB
DBの切り離し
ログファイルの名前を変更する
DBをアタッチする
新しいログファイルが再作成されます
名前を変更したログファイルを削除します。

ログのバックアップをとっていないのではないかと思います。(ログが切り詰められます)。私のアドバイスは、復旧モデルを以前から変更することです。満杯に単純. 。これにより、ログの肥大化を防ぐことができます。

これまでのところ、ここでのほとんどの回答は、実際にはトランザクションログファイルが必要ないことを前提としていますが、データベースが 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)

SQL Server トランザクションログは、不要な増大を防ぐために適切に維持する必要があります。これは、トランザクションログのバックアップを十分な頻度で実行することを意味します。これを行わないと、トランザクションログがいっぱいになり、増大し始める危険があります。

この質問に対する答えに加えて、トランザクションログの一般的な通説を読んで理解することをお勧めします。これらの読み取り値は、トランザクションログを理解し、それを「クリア」するためにどのような手法を使用するかを決定するのに役立ちます。

から SQL Server トランザクションログに関する最も重要な 10 の誤解:

神話：SQL Server がビジー状態です。SQL Server トランザクションログのバックアップを作成したくない

SQL Server における最もパフォーマンスを重視する操作の 1 つは、オンライントランザクションログファイルの自動拡張イベントです。トランザクションログのバックアップを十分な頻度で作成しないと、オンライントランザクションログがいっぱいになり、増大する必要があります。デフォルトの成長サイズは 10% です。データベースが忙しいほど、トランザクションログのバックアップが作成されていない場合、オンライントランザクションログが速くなります。オンライントランザクションログ内のすべてのアクティビティをブロックできます

から トランザクションログに関する神話:

神話：定期的にログを圧縮することは良いメンテナンス方法です

間違い。新しいチャンクをゼロにする必要があるため、ログの増加には非常にコストがかかります。ゼロ化が完了するまで、そのデータベースに対するすべての書き込みアクティビティは停止します。ディスクへの書き込みが遅い場合、または自動拡張サイズが大きい場合、その一時停止が大きくなり、ユーザーが気付く可能性があります。それが成長を避けたい理由の1つです。ログを縮小すると再び大きくなり、不必要に縮小して再度拡張するゲームでディスク操作を無駄にしているだけです。

John が推奨するこの手法は、ログファイルなしでデータベースが接続されるという保証がないため、推奨されません。データベースをフルデータベースからシンプルデータベースに変更し、チェックポイントを強制的に作成して、数分間待ちます。SQL Server はログをクリアします。その後、DBCC SHRINKFILE を使用してログを圧縮できます。

まずデータベースの復旧モデルを確認します。デフォルトでは、SQL Server Express Editionは、単純な回復モデルのデータベースを作成します（私が間違っていない場合）。

バックアップログ DatabaseName (Truncate_Only の場合):

DBCC ShrinkFile(yourLogical_LogFileName, 50)

SP_helpfile により、論理ログファイル名が得られます。

参照する：

SQL Server データベース内の完全なトランザクションログから回復する

データベースが完全復旧モデルであり、TL バックアップを取得していない場合は、それを SIMPLE に変更します。

使用 DBCC ShrinkFile ({logicalLogName}, TRUNCATEONLY) 指示。これがテストデータベースであり、スペースを節約/再利用しようとしている場合、これは役に立ちます。

ただし、TX ログには、最大/定常状態のサイズのようなものがあることに注意してください。復旧モデルによっては、ログを縮小できない場合があります。FULL で TX ログバックアップを発行していない場合、ログは縮小できません。ログは永久に増大します。TX ログのバックアップが必要ない場合は、復旧モデルを次のように切り替えます。単純.

また、ログ (LDF) ファイルはいかなる状況でも決して削除しないでください。すぐにデータベースが破損してしまいます。調理済み！終わり！データが失われた!「未修復」のままにしておくと、メインの MDF ファイルが永久に破損する可能性があります。

トランザクションログは絶対に削除しないでください。データが失われます。データの一部は (復旧モデルに関係なく) TX ログにあります...TX ログファイルを切り離して「名前変更」すると、効果的に 削除します データベースの一部です。

TX ログを削除した場合は、データがさらに失われる前に、いくつかの checkdb コマンドを実行して破損を修正することをお勧めします。

このトピックに関する Paul Randal のブログ投稿をチェックしてください。 悪いアドバイス.

また、データが大幅に断片化する可能性があるため、通常は MDF ファイルに対して shrinfile を使用しないでください。詳細については、彼の悪いアドバイスのセクション (「データファイルを圧縮してはいけない理由」) を参照してください。

Paul の Web サイトをチェックしてください。彼はまさにこれらの質問をカバーしています。先月、彼は著書でこれらの問題の多くを取り上げました。 一日の神話 シリーズ。

ログファイルを切り詰めるには:

データベースをバックアップする
Enterprise Managerを使用するか、次のコマンドを実行して、データベースを接続解除します。 Sp_DetachDB [DB名]
トランザクションログファイルを削除します。(念のためファイル名を変更することもできます)
次のコマンドを使用して、データベースを再度接続します。 Sp_AttachDB [DB名]
データベースが接続されると、新しいトランザクションログファイルが作成されます。

ログファイルを圧縮するには:

No_Log を使用したバックアップログ [DBName]
次のいずれかの方法でデータベースを縮小します。

エンタープライズマネージャーの使用： - データベースを右クリック、すべてのタスク、データベースの縮小、ファイル、[ログファイル]を選択します。

T-SQL の使用:-Dbcc 圧縮ファイル ([ログ論理名])

ログファイルの論理名は、sp_helpdb を実行するか、Enterprise Manager でデータベースのプロパティを確認することで確認できます。

私の経験では、ほとんどの SQL Server ではトランザクションログのバックアップはありません。完全バックアップまたは差分バックアップは一般的に行われますが、トランザクションログのバックアップは実際にはほとんど行われません。そのため、トランザクションログファイルは永久に (ディスクがいっぱいになるまで) 大きくなります。この場合、 回復モデル 「」に設定する必要があります単純」。システムデータベース「model」と「tempdb」も忘れずに変更してください。

データベース「tempdb」のバックアップは意味がないため、このデータベースの復旧モデルは常に「単純」である必要があります。

MDB ファイルのバックアップを取得します。
SQLサービスを停止する
ログファイルの名前を変更する
サービスを開始する

(システムにより新しいログファイルが作成されます。)

名前を変更したログファイルを削除または移動します。

これを試して：

USE DatabaseName

GO

DBCC SHRINKFILE( TransactionLogName, 1)

BACKUP LOG DatabaseName WITH TRUNCATE_ONLY

DBCC SHRINKFILE( TransactionLogName, 1)

GO

データベース→右クリック プロパティ → ファイル → 別の名前で別のログファイルを追加し、別のファイル名で古いログファイルと同じパスを設定します。

データベースは、新しく作成されたログファイルを自動的に取得します。

バックアップDB
DBの切り離し
ログファイルの名前を変更する
DBのアタッチ（アタッチ中に、名前を変更した.ldf（ログファイル）を削除します。それを選択し、削除ボタンを押して削除します）
新しいログファイルが再作成されます
名前を変更したログファイルを削除します。

これでも機能しますが、最初にデータベースのバックアップを取ることをお勧めします。

例：

DBCC SQLPERF(LOGSPACE)

BACKUP LOG Comapny WITH TRUNCATE_ONLY

DBCC SHRINKFILE (Company_log, 500)

DBCC SQLPERF(LOGSPACE)

データベースログファイルが28GBの場合にそれが起こりました。

これを減らすために何ができるでしょうか?実際、ログファイルは、トランザクションが発生したときに SQL サーバーが保持するファイルデータです。SQL サーバーはトランザクションを処理するためにページを割り当てます。しかし、トランザクションの完了後、同じようなトランザクションが来るかもしれないことを期待して、これらは突然解放されることはありません。これでスペースが確保されます。

ステップ1：最初にデータベースクエリでこのコマンドを実行しましたチェックポイントの探索

ステップ2：データベースタスクを右クリック>バックアップバックアップタイプを[トランザクション]ログ宛先アドレスとファイル名を追加して、バックアップデータを保持します（.bak）

この手順をもう一度繰り返し、この時点で別のファイル名を付けます

ステップ 3:次に、データベースに移動して、データベースを右クリックします

タスク> shrinks>ファイルは、リリースされていないスペースとしてログシュリンクアクションとしてファイルタイプを選択します

ステップ 4:

sql 2014でログファイルを正常に確認してくださいこれはで見つかります

C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQL2014EXPRESS\MSSQL\DATA

私の場合、28 GB から 1 MB に減りました。

他の回答のいくつかは私にとっては役に立ちませんでした:トランザクションログがいっぱいだったので、DB がオンラインの間にチェックポイントを作成することはできませんでした (なんと皮肉なことでしょう)。ただし、データベースを緊急モードに設定した後は、ログファイルを縮小することができました。

alter database <database_name> set emergency;
use <database_name>;
checkpoint;
checkpoint;
alter database <database_name> set online;
dbcc shrinkfile(<database_name>_log, 200);

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

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow

SQL Server のトランザクション ログをクリアするにはどうすればよいですか?