SQL Serverトランザクションログをクリアするにはどうすればよいですか？
回答:
ログファイルを小さくすることは、実際には予期しない増加が発生し、再び発生することはないと思われるシナリオのために予約する必要があります。ログファイルが再び同じサイズに拡大する場合、一時的に縮小してもあまり効果はありません。これで、データベースのリカバリ目標に応じて、これらのアクションを実行する必要があります。
まず、完全バックアップを取ります
何か問題が発生した場合に復元できることを確認せずに、データベースを変更しないでください。
ポイントインタイムリカバリが気になる場合
（そして、ポイントインタイムリカバリとは、完全バックアップまたは差分バックアップ以外に復元できることを気にかけていることを意味します。）
おそらくデータベースは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
ポイントインタイムリカバリを気にしない場合
これがテストデータベースであり、Point-in-Timeリカバリを気にしない場合は、データベースがSIMPLEリカバリモードであることを確認する必要があります。
ALTER DATABASE testdb SET RECOVERY SIMPLE;データベースをSIMPLE回復モードにすると、SQL Serverは、すべてのトランザクションの記録を保持するために成長するのではなく、ログファイルの一部を再利用します（基本的には非アクティブなトランザクションを段階的に廃止します）（FULL回復はログをバックアップするまで行われます）。CHECKPOINTイベントは、ログを制御するのに役立ち、CHECKPOINTs 間に多くのt-logアクティビティを生成しない限り、ログが大きくなる必要がないことを確認します。
次に、このログの増加が本当に異常なイベント（たとえば、毎年の春の大掃除または最大のインデックスの再構築）によるものであり、通常の日常的な使用によるものではないことを確認する必要があります。ログファイルを途方もなく小さいサイズに圧縮し、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。1TRUNCATE_ONLYつには、このオプションは廃止されており、SQL Serverの現在のバージョンでは使用できなくなりました。次に、FULL復旧モデルを使用している場合、ログチェーンが破壊され、新しい完全バックアップが必要になります。データベースをデタッチし、ログファイルを削除して、再度アタッチします。これがどれほど危険かを強調することはできません。データベースが復旧しない可能性があります。疑わしいとして復旧する可能性があります。バックアップがある場合は、バックアップに戻す必要がある場合もあります。
「データベースの縮小」オプションを使用します。
DBCC SHRINKDATABASE同じことを行う保守計画オプションは、特にログの問題の問題を本当に解決する必要があるだけの場合は、悪い考えです。調整するファイルをターゲットにして、DBCC SHRINKFILEまたはALTER DATABASE ... MODIFY FILE（上記の例）を使用して個別に調整します。ログファイルを1 MBに圧縮します。SQL Serverでは特定のシナリオでそれを実行でき、解放されたすべての領域を確認できるため、これは魅力的に見えます。データベースが読み取り専用でない限り（そして、それを使用してそのようにマークする必要があります
ALTER DATABASE）、リカバリモデルに関係なくログが現在のトランザクションに対応する必要があるため、これは多くの不必要な拡張イベントを引き起こすだけです。SQL Serverがゆっくりと苦痛に取り戻すことができるように、そのスペースを一時的に解放する目的は何ですか？2つ目のログファイルを作成します。これにより、ディスクがいっぱいになったドライブが一時的に軽減されますが、これは、パンクした肺をバンドエイドで固定しようとするようなものです。別の潜在的な問題を追加するのではなく、問題のあるログファイルを直接処理する必要があります。一部のトランザクションログアクティビティを別のドライブにリダイレクトする以外は、2番目のログファイルは（2番目のデータファイルとは異なり）実際には何もしません。Paul Randalは、複数のログファイルが後であなたに噛まれる理由も説明しています。
積極的に
ログファイルを少しだけ小さくして、それ自体が常に小さな速度で自動拡張できるようにする代わりに、ある程度大きなサイズ（最大の同時トランザクションセットの合計に対応できるサイズ）に設定し、適切な自動拡張を設定します。フォールバックとして設定することで、単一のトランザクションを満たすために複数回拡張する必要がなくなり、通常のビジネスオペレーション中に拡張が必要になることは比較的まれになります。
ここで考えられる最悪の設定は、1 MBの増加または10％の増加です。おかしなことに、これらはSQL Serverのデフォルトです（私は不満を言って変更を要求しました）-データファイル用に1 MB、ログファイル用に10％。前者はこの日と年齢では非常に小さすぎ、後者は毎回イベントが長くなります（たとえば、ログファイルは500 MB、最初の増加は50 MB、次の増加は55 MB、次の増加は60.5 MBです） 、等々-そして遅いI / Oでは、私を信じて、あなたは本当にこの曲線に気づくでしょう）。
参考文献
ここで止めないでください。ログファイルの圧縮に関するアドバイスの多くは本質的に悪いものであり、破滅的なものになる可能性さえありますが、ディスク領域を解放するよりもデータの整合性を重視する人もいます。
2009年に私が書いたブログの投稿で、「ログファイルを圧縮する方法はここにあります」という投稿がいくつか出てきたのを目にしました。
SQL Server Magazineの記事が公開されるべきではなかったため、Brent Ozarが4年前に投稿したブログ記事で、複数のリソースを指摘しています。
t-logのメンテナンスが重要である理由と、データファイルも縮小すべきではない理由を説明するPaul Randalのブログ投稿。
マイクウォルシュは、ログファイルをすぐに圧縮できない理由を含む、これらの側面のいくつかをカバーする素晴らしい答えを持っています。
-- 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
From：DBCC SHRINKFILE（Transact-SQL）
最初にバックアップすることをお勧めします。
免責事項：以下のコメントを注意深くお読みください。承認された回答はすでに読んだと思います。5年近く前に言ったように：
これが適切または最適な解決策ではない場合に誰かがコメントを追加する場合は、以下にコメントしてください
データベース名を右クリックします。
タスク→縮小→データベースを選択します
次にOK！
私は通常、データベースファイルを含むWindowsエクスプローラーのディレクトリを開いているので、その影響をすぐに確認できます。
これがうまくいったことに本当に驚いた！通常、私は以前にDBCCを使用したことがありますが、それを試しただけで何も縮小しなかったので、GUI（2005）を試してみたところ、10秒で17 GBが解放されました。
完全復旧モードではこれが機能しない可能性があるため、まずログをバックアップするか、単純復旧に変更してからファイルを圧縮する必要があります。[@onupdatecascadeに感謝]
-
PS：これの危険性についてコメントしていただいたことに感謝しますが、私の環境では特にフルバックアップを最初に行っているので、自分でこれを実行しても問題はありませんでした。したがって、続行する前に、ご使用の環境と、これがバックアップ戦略とジョブのセキュリティにどのように影響するかを考慮してください。私がやっていたことは、Microsoftが提供する機能を人々に示すことだけでした。
以下はトランザクションログを圧縮するスクリプトですが、圧縮する前にトランザクションログをバックアップすることをお勧めします。
ファイルを圧縮するだけでは、災害発生時に救命者になる可能性のある大量のデータが失われます。トランザクションログには、サードパーティのトランザクションログリーダーを使用して読み取ることができる多くの有用なデータが含まれています（手動で読み取ることもできますが、非常に手間がかかります）。
トランザクションログは、ポイントインタイムリカバリに関しても必須であるため、単に破棄するのではなく、必ず事前にバックアップしてください。
以下は、トランザクションログに格納されたデータを使用してリカバリを実行したいくつかの投稿です。
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が使用されています。この場合、これを数回続けて実行するか、データベースのアクティビティを減らす方法を見つけてください。
ここでは、シンプルであり非常に洗練＆潜在的に危険な 道。
- バックアップDB
- DBを切り離す
- ログファイルの名前を変更
- DBを接続
- 新しいログファイルが再作成されます
- 名前を変更したログファイルを削除します。
ログのバックアップを行っていないようです。（ログを切り捨てる）。私のアドバイスは、からの復旧モデルを変更することで、フルにシンプル。これにより、ログの膨張が防止されます。
復元にトランザクションログを使用しない場合（つまり、完全バックアップのみを実行する場合）、リカバリモードを「シンプル」に設定できます。トランザクションログはすぐに縮小され、再びいっぱいになることはありません。
SQL 7または2000を使用している場合は、データベースオプションタブで「チェックポイント時のログの切り捨て」を有効にできます。これは同じ効果があります。
これは、特定の時点に復元することができないため、本番環境では明らかに推奨されません。
Simple...そして二度と一杯になることはない」-真実ではない。復旧モデルが「シンプル」に設定されているデータベースで（過去48時間に）発生することを確認しました。ログファイルのファイル拡張は「制限付き」に設定されており、ログファイルに対して非常に大きなアクティビティを行っていました...異常な状況であったことは理解しています。（私たちの状況では、十分なディスク領域があったので、ログファイルのサイズを増やし、ログファイルのファイル拡張を「制限なし」に設定しました...ところで、変更後、「インターフェースのバグ」が「制限付き」と表示されます"2,097,152 MBの
Johnが推奨するこの手法は、データベースがログファイルなしで接続される保証がないため、推奨されません。データベースをフルからシンプルに変更し、チェックポイントを強制して数分待ちます。SQL Serverはログをクリアします。ログは、DBCC SHRINKFILEを使用して縮小できます。
これまでのほとんどの回答は、トランザクションログファイルが実際には必要ないことを前提としていますが、データベースがFULL復旧モデルを使用していて、データベースを復元する必要がある場合に備えてバックアップを保持したい場合は、トランケートまたは削除しないでくださいこれらの回答の多くが示唆する方法でログファイル。
ログファイルを削除すると（切り捨て、破棄、消去などにより）、バックアップチェーンが壊れ、最後の完全バックアップ、差分バックアップ、またはトランザクションログバックアップから次の完全バックアップまでの時点に復元できなくなります。または差分バックアップが作成されます。
ログチェーンが破損するため、トランザクションログを手動で切り捨てるために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), 1)一部を除いて、あなたの答えに同意します。問題は、1 MBに縮小すると、通常のログサイズにつながる成長イベントにかなりのコストがかかり、成長率をデフォルトの10％のままにしておくと、その多くが発生することです。
SQL Serverのトランザクションログは、不要な増加を防ぐために適切に維持する必要があります。これは、トランザクションログのバックアップを頻繁に実行することを意味します。そうしないと、トランザクションログがいっぱいになり、成長し始めるリスクがあります。
この質問に対する回答の他に、トランザクションログの一般的な神話を読んで理解することをお勧めします。これらの読み取り値は、トランザクションログを理解し、それを「クリア」するために使用する手法を決定するのに役立ちます。
以下からの10の最も重要なSQL Serverのトランザクションログの神話：
神話：SQLサーバーがビジー状態です。SQL Serverトランザクションログのバックアップを作成したくない
SQL Serverで最大のパフォーマンスを必要とする操作の1つは、オンライントランザクションログファイルの自動拡張イベントです。トランザクションログのバックアップを頻繁に作成しないと、オンライントランザクションログがいっぱいになり、拡張する必要があります。デフォルトの拡張サイズは10％です。データベースがビジーであるほど、トランザクションログバックアップが作成されない場合、オンライントランザクションログの成長が速くなります。SQLServerトランザクションログバックアップを作成しても、オンライントランザクションログはブロックされませんが、自動拡張イベントはブロックされます。オンライントランザクションログのすべてのアクティビティをブロックできます
神話：定期的なログの縮小はメンテナンスの良い習慣です
偽。新しいチャンクをゼロにする必要があるため、ログの増加は非常にコストがかかります。ゼロ化が完了するまで、すべての書き込みアクティビティがそのデータベースで停止します。ディスクの書き込みが遅いか、自動拡張のサイズが大きい場合、その一時停止は非常に大きくなる可能性があり、ユーザーはそれに気づくでしょう。これが、成長を避けたい理由の1つです。ログを縮小すると、ログは再び大きくなり、不要な縮小と再成長のゲームでディスク操作を浪費しているだけです。
まず、データベースの復旧モデルを確認します。デフォルトでは、SQL Server Express Editionは単純な復旧モデル用のデータベースを作成します（私が間違っていない場合）。
Truncate_Onlyを使用したバックアップログDatabaseName：
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ファイルでshrinkfileを使用しないでください。詳細については彼の悪いアドバイスのセクションをチェックしてください（「なぜデータファイルを縮小すべきでないのか」）
ポールのウェブサイトをチェックしてください-彼はこれらの非常に質問をカバーしています。先月、彼はMyth A Dayシリーズでこれらの問題の多くを紹介しました。
ログファイルを切り捨てるには：
- データベースをバックアップする
- Enterprise Managerを使用するか、次のコマンドを実行して、データベースを切断します。Sp_DetachDB [DBName]
- トランザクションログファイルを削除します。（または念のためファイルの名前を変更してください）
- Sp_AttachDB [DBName]を使用して、データベースを再接続します。
- データベースが接続されると、新しいトランザクションログファイルが作成されます。
ログファイルを圧縮するには：
- ログなしのバックアップログ[DBName]
次のいずれかの方法でデータベースを縮小します。
Enterprise Managerの使用：-データベースを右クリックし、[すべてのタスク]、[データベースの縮小]、[ファイル]、[ログファイルの選択]、[OK]の順にクリックします。
T-SQLの使用： -Dbcc Shrinkfile（[Log_Logical_Name]）
ログファイルの論理名を見つけるには、sp_helpdbを実行するか、Enterprise Managerでデータベースのプロパティを調べます。
ほとんどのSQLサーバーでの私の経験では、トランザクションログのバックアップはありません。フルバックアップまたは差分バックアップは一般的な方法ですが、トランザクションログのバックアップはほとんどありません。したがって、トランザクションログファイルは永久に大きくなります（ディスクがいっぱいになるまで）。この場合、復旧モデルは「シンプル」に設定する必要があります。システムデータベース「model」と「tempdb」も変更することを忘れないでください。
データベース「tempdb」のバックアップは意味をなさないため、このデータベースの復旧モデルは常に「単純」である必要があります。
データベースログファイルのサイズが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に減少しました
これを試して：
USE DatabaseName
GO
DBCC SHRINKFILE( TransactionLogName, 1)
BACKUP LOG DatabaseName WITH TRUNCATE_ONLY
DBCC SHRINKFILE( TransactionLogName, 1)
GO データベース→ プロパティを右クリック→ファイル→別の名前の別のログファイルを追加し、パスを別のファイル名の古いログファイルと同じに設定します。
データベースは、新しく作成されたログファイルを自動的に取得します。
- バックアップDB
- DBを切り離す
- ログファイルの名前を変更
- DBを接続します（名前を変更した.ldf（ログファイル）を削除しながら添付します）。DBを選択し、[削除]ボタンを押して削除します）
- 新しいログファイルが再作成されます
- 名前を変更したログファイルを削除します。
これは機能しますが、最初にデータベースのバックアップを取ることをお勧めします。
他のいくつかの回答は私にとってうまくいきませんでした：トランザクションログがいっぱいだったため（皮肉なことに）、データベースがオンラインのときにチェックポイントを作成できませんでした。ただし、データベースを緊急モードに設定した後、ログファイルを圧縮できました。
alter database <database_name> set emergency;
use <database_name>;
checkpoint;
checkpoint;
alter database <database_name> set online;
dbcc shrinkfile(<database_name>_log, 200);例：
DBCC SQLPERF(LOGSPACE)
BACKUP LOG Comapny WITH TRUNCATE_ONLY
DBCC SHRINKFILE (Company_log, 500)
DBCC SQLPERF(LOGSPACE)MSSQL 2017、SQLサーバー管理スタジオを使用するための、わずかに更新された回答。私は主にこれらの指示から行きましたhttps://www.sqlshack.com/sql-server-transaction-log-backup-truncate-and-shrink-operations/
最近のdbバックアップがあったので、トランザクションログをバックアップしました。それから、私はそれを十分にバックアップしました。最後に、ログファイルを縮小して、20Gから7MBに変更しました。これは、データのサイズにはるかに一致しています。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