Come si cancella il log delle transazioni di SQL Server?

Non sono un esperto di SQL e mi viene in mente ogni volta che devo fare qualcosa oltre le basi. Ho un database di test di dimensioni non grandi, ma il log delle transazioni lo è sicuramente. Come posso cancellare il registro delle transazioni?

Rendere più piccolo un file di registro dovrebbe essere riservato agli scenari in cui ha riscontrato una crescita inaspettata che non ti aspetti di accadere di nuovo. Se il file di registro tornerà a essere di dimensioni uguali, non si otterrà molto più spesso riducendolo temporaneamente. Ora, a seconda degli obiettivi di recupero del database, queste sono le azioni da intraprendere.

Per prima cosa, fai un backup completo

Non apportare mai modifiche al database senza assicurarsi di poterlo ripristinare in caso di problemi.

Se ti interessa il recupero point-in-time

(E con la recovery point-in-time, voglio dire che ti interessa essere in grado di ripristinare qualcosa di diverso da un backup completo o differenziale.)

Presumibilmente il tuo database è in modalità di recupero FULL . In caso contrario, assicurati che sia:

 ALTER DATABASE testdb SET RECOVERY FULL; 

Anche se si stanno eseguendo regolari backup completi, il file di registro crescerà e si espanderà fino a quando non si eseguirà un backup del registro : questo è per la vostra protezione, non per consumare inutilmente il vostro spazio su disco. Dovresti eseguire questi backup del log abbastanza frequentemente, in base ai tuoi obiettivi di recupero. Ad esempio, se si dispone di una regola aziendale che afferma che è ansible permettersi di non perdere più di 15 minuti di dati in caso di disastro, è necessario disporre di un lavoro che esegua il backup del registro ogni 15 minuti. Ecco uno script che genererà nomi di file con data e ora basati sull’ora corrente (ma è ansible farlo anche con piani di manutenzione ecc., Semplicemente non scegliere nessuna delle opzioni di restringimento nei piani di manutenzione, sono orribili).

 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; 

Si noti che \\backup_share\ deve essere su una macchina diversa che rappresenta una diversa periferica di archiviazione sottostante. Il backup di questi sulla stessa macchina (o su una macchina diversa che utilizza gli stessi dischi sottostanti, o una VM diversa che si trova sullo stesso host fisico) in realtà non ti aiuta, poiché se la macchina esplode, hai perso il tuo database e i suoi backup. A seconda dell’infrastruttura di rete, può essere più logico eseguire il backup localmente e quindi trasferirli in una posizione diversa dietro le quinte; in entrambi i casi, si desidera rimuoverli dalla macchina del database principale il più rapidamente ansible.

Ora, una volta che si eseguono regolarmente i backup del log, dovrebbe essere ragionevole ridurre il file di registro a qualcosa di più ragionevole di qualsiasi altra cosa sia saltata in aria. Ciò non significa eseguire SHRINKFILE più e più volte fino a quando il file di registro non è 1 MB, anche se si esegue spesso il backup del log, ma deve comunque contenere la sum di tutte le transazioni simultanee che possono verificarsi. Gli eventi autogrow del file di registro sono costosi, poiché SQL Server deve azzerare i file (diversamente dai file di dati quando l’inizializzazione del file istantaneo è abilitata) e le transazioni dell’utente devono attendere mentre ciò accade. Vuoi fare questa routine di restringimento-crescita-restringimento il meno ansible, e certamente non vuoi che i tuoi utenti paghino per questo.

Si noti che potrebbe essere necessario eseguire il backup del registro due volte prima che una riduzione sia ansible (grazie Robert).

Quindi, devi trovare una dimensione pratica per il tuo file di registro. Nessuno qui può dirti di cosa si tratta senza sapere molto di più sul tuo sistema, ma se hai frequentemente ridotto il file di registro ed è nuovamente cresciuto, una buona filigrana è probabilmente del 10-50% più alta della più grande che sia stata . Diciamo che arriva a 200 MB e vuoi che gli eventi successivi di aumento automatico siano di 50 MB, quindi puoi regolare le dimensioni del file di registro in questo modo:

 USE [master]; GO ALTER DATABASE Test1 MODIFY FILE (NAME = yourdb_log, SIZE = 200MB, FILEGROWTH = 50MB); GO 

Si noti che se il file di registro è attualmente> 200 MB, potrebbe essere necessario eseguire prima questo:

 USE yourdb; GO DBCC SHRINKFILE(yourdb_log, 200); GO 

Se non ti interessa il recupero point-in-time

Se si tratta di un database di test e non ti interessa il recupero temporizzato, devi assicurarti che il tuo database sia in modalità di recupero SIMPLE .

 ALTER DATABASE testdb SET RECOVERY SIMPLE; 

Mettendo il database in modalità di ripristino SIMPLE si assicurerà che SQL Server riutilizzi porzioni del file di registro (essenzialmente eliminando gradualmente le transazioni inattive) anziché crescere per mantenere un record di tutte le transazioni (come il ripristino FULL finché non si esegue il backup del log) . CHECKPOINT eventi CHECKPOINT aiuteranno a controllare il log e assicurarsi che non abbia bisogno di crescere a meno che non si generi molta attività di t-log tra i punti CHECKPOINT .

Successivamente, dovresti essere assolutamente sicuro che questa crescita del log sia stata veramente dovuta a un evento anormale (ad esempio, una pulizia annuale di spring o la ricostruzione dei tuoi indici più grandi), e non a causa del normale utilizzo quotidiano. Se si riduce il file di registro a una dimensione ridicolmente piccola, e SQL Server deve solo ricominciare a crescere per adattarsi alla normale attività, cosa hai ottenuto? Sei riuscito a utilizzare lo spazio su disco che hai liberato solo temporaneamente? Se hai bisogno di una correzione immediata, puoi eseguire quanto segue:

 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 

Altrimenti, imposta una dimensione e un tasso di crescita appropriati. Come nell’esempio nel caso di recupero temporizzato, è ansible utilizzare lo stesso codice e la stessa logica per determinare quale dimensione del file è appropriata e impostare parametri di autogrowth ragionevoli.

Alcune cose che non vuoi fare

  • Eseguire il backup del registro con l’opzione TRUNCATE_ONLY e quindi SHRINKFILE . Per uno, questa opzione TRUNCATE_ONLY è stata deprecata e non è più disponibile nelle versioni correnti di SQL Server. In secondo luogo, se si è nel modello di recupero FULL , questo distruggerà la catena di log e richiederà un nuovo backup completo.

  • Scollega il database, elimina il file di registro e ricollegalo . Non posso sottolineare quanto possa essere pericoloso. Il tuo database potrebbe non essere ripristinato, potrebbe sorgere il sospetto, potresti dover ripristinare un backup (se ne hai uno), ecc. Ecc.

  • Utilizzare l’opzione “Shrink database” . DBCC SHRINKDATABASE e l’opzione del piano di manutenzione per fare lo stesso sono idee sbagliate, specialmente se si ha davvero bisogno solo di risolvere un problema di log. Indirizzare il file che si desidera regolare e regolarlo in modo indipendente, utilizzando DBCC SHRINKFILE o ALTER DATABASE ... MODIFY FILE (esempi sopra).

  • Riduci il file di registro a 1 MB . Questo sembra allettante perché, ehi, SQL Server mi permetterà di farlo in determinati scenari, e guarderà tutto lo spazio che libera! A meno che il tuo database sia di sola lettura (e lo è, dovresti contrassegnarlo come tale utilizzando ALTER DATABASE ), questo porterà solo a molti eventi di crescita non necessari, poiché il log deve contenere le transazioni correnti indipendentemente dal modello di recupero. Qual è lo scopo di liberare temporaneamente quello spazio, solo così SQL Server può riprenderlo lentamente e dolorosamente?

  • Creare un secondo file di registro . Ciò fornirà un sollievo temporaneo per l’unità che ha riempito il disco, ma questo è come provare a riparare un polmone perforato con un cerotto. Dovresti gestire direttamente il file di registro problematico invece di aggiungere un altro potenziale problema. A parte il reindirizzamento di alcune attività del registro delle transazioni su un’unità diversa, un secondo file di registro non fa realmente nulla per te (diversamente da un secondo file di dati), poiché solo uno dei file può essere utilizzato in qualsiasi momento. Paul Randal spiega anche perché più file di registro possono morderti in seguito .

Sii proattivo

Invece di ridurre il file di registro a una piccola quantità e lasciarlo aumentare automaticamente a una velocità ridotta, impostarlo su dimensioni ragionevolmente grandi (uno che soddisferà la sum della più grande serie di transazioni simultanee) e impostare un aumento di volume ragionevole impostazione come fallback, in modo che non debba crescere più volte per soddisfare singole transazioni e in modo che sia relativamente raro che debba crescere durante le normali operazioni commerciali.

Le peggiori impostazioni possibili qui sono una crescita di 1 MB o una crescita del 10%. Abbastanza divertente, questi sono i valori predefiniti per SQL Server (di cui mi sono lamentato e ho chiesto modifiche senza alcun risultato ): 1 MB per i file di dati e il 10% per i file di registro. Il primo è troppo piccolo al giorno d’oggi, e il secondo porta ogni volta a eventi sempre più lunghi (ad esempio, il file di registro è di 500 MB, la prima crescita è di 50 MB, la crescita successiva è di 55 MB, la crescita successiva è di 60,5 MB ecc. ecc. – e sull’I / O lento, credetemi, noterete davvero questa curva).

Ulteriori letture

Per favore non fermarti qui; mentre molti dei consigli che si vedono sulla riduzione dei file di registro sono intrinsecamente cattivi e persino potenzialmente disastrosi, ci sono alcune persone che si preoccupano maggiormente dell’integrità dei dati piuttosto che liberare spazio su disco.

Un post sul blog che ho scritto quattro anni fa, quando ho visto alcuni “ecco come ridurre il file di registro” .

Un post sul blog Brent Ozar ha scritto quattro anni fa, puntando a più risorse, in risposta a un articolo di SQL Server Magazine che non avrebbe dovuto essere pubblicato .

Un post sul blog di Paul Randal che spiega perché la manutenzione di t-log è importante e perché non si dovrebbero ridurre i file di dati .

Mike Walsh ha una grande risposta che copre anche alcuni di questi aspetti, inclusi i motivi per cui potresti non essere in grado di ridurre immediatamente il tuo file di registro .

NOTA BENE: Si prega di leggere attentamente i commenti di seguito, e presumo che abbiate già letto la risposta accettata. Come ho detto quasi 5 anni fa:

se qualcuno ha commenti da aggiungere per situazioni in cui questa NON è una soluzione adeguata o ottimale, si prega di commentare qui sotto


  • Fare clic con il tasto destro sul nome del database.

  • Seleziona Attività → Riduci → Database

  • Quindi fare clic su OK !

Solitamente apro la directory di Windows Explorer che contiene i file del database, quindi posso immediatamente vedere l’effetto.

In realtà ero abbastanza sorpreso che funzionasse! Normalmente ho usato DBCC in precedenza, ma l’ho appena provato e non ha ridotto nulla, quindi ho provato la GUI (2005) e ha funzionato benissimo – liberando 17 GB in 10 secondi

In modalità di ripristino completo potrebbe non funzionare, quindi è necessario eseguire prima il backup del registro o passare al ripristino semplice, quindi ridurre il file. [grazie a @onupdatecascade per questo]

PS: Apprezzo ciò che alcuni hanno commentato riguardo ai pericoli di questo, ma nel mio ambiente non ho avuto problemi a farlo da solo, soprattutto perché faccio sempre un backup completo prima. Quindi, per favore, prendi in considerazione quale sia il tuo ambiente e come questo influenzi la tua strategia di backup e la sicurezza del tuo lavoro prima di continuare. Tutto quello che stavo facendo era indirizzare le persone verso una funzionalità fornita da 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 

Da: DBCC SHRINKFILE (Transact-SQL)

Potresti voler eseguire il backup per primo.

Di seguito è riportato uno script per ridurre il log delle transazioni, ma consiglio di eseguire il backup del log delle transazioni prima di ridurlo.

Se riduci il file, perdi una tonnellata di dati che potrebbero venire salvati in caso di emergenza. Il registro delle transazioni contiene molti dati utili che possono essere letti utilizzando un lettore di registri delle transazioni di terze parti (può essere letto manualmente ma con estremo sforzo).

Il log delle transazioni è anche un must quando si tratta di recupero in tempo reale, quindi non buttarlo via, ma assicurati di eseguirne il backup in anticipo.

Ecco alcuni post in cui le persone hanno utilizzato i dati memorizzati nel log delle transazioni per eseguire il ripristino:

  • Come visualizzare i registri delle transazioni in SQL Server 2008

  • Leggere il file di registro (* .LDF) in SQL Server 2008

 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 

Potresti ricevere un errore simile a questo quando esegui i comandi sopra

“Imansible ridurre il file di registro (nome file di registro) perché è in uso il file log logico situato alla fine del file”

Ciò significa che TLOG è in uso. In questo caso, provare a eseguire questa operazione più volte di seguito o trovare un modo per ridurre le attività del database.

Se non si utilizzano i registri delle transazioni per i ripristini (ad esempio, si eseguono solo backup completi), è ansible impostare la Modalità di ripristino su “Semplice” e il log delle transazioni si restringerà molto rapidamente e non si riempirà mai più.

Se si utilizza SQL 7 o 2000, è ansible abilitare “Truncate log on checkpoint” nella scheda delle opzioni del database. Questo ha lo stesso effetto.

Questo non è consigliato in ambienti di produzione, ovviamente, dal momento che non sarà ansible ripristinarlo in un dato momento.

Ecco un modo semplice, molto inelegante e potenzialmente pericoloso .

  1. DB di backup
  2. Scollega DB
  3. Rinomina file di registro
  4. Allega DB
  5. Nuovo file di registro verrà ricreato
  6. Elimina il file di registro rinominato.

Suppongo che tu non stia facendo i backup del log. (Che tronca il log). Il mio consiglio è di cambiare il modello di recupero da completo a semplice . Ciò impedirà il log bloat.

La maggior parte delle risposte qui finora presuppongono che non sia effettivamente necessario il file Registro transazioni, tuttavia se il database utilizza il modello di recupero FULL e si desidera conservare i backup in caso sia necessario ripristinare il database, quindi non troncare o eliminare il file di registro come suggeriscono molte di queste risposte.

L’eliminazione del file di registro (troncandolo, scartandolo, cancellandolo, ecc.) Interromperà la catena di backup e impedirà il ripristino in qualsiasi momento dopo l’ultimo backup completo, differenziale o del log delle transazioni, fino al successivo completo o il backup differenziale è fatto.

Dall’articolo di Microsoft su BACKUP

Ti consigliamo di non utilizzare mai NO_LOG o TRUNCATE_ONLY per troncare manualmente il log delle transazioni, poiché ciò interrompe la catena di log. Fino al successivo backup completo o differenziale del database, il database non è protetto dall’errore del supporto. Utilizzare il troncamento del registro manuale solo in circostanze molto speciali e creare immediatamente backup dei dati.

Per evitare ciò, eseguire il backup del file di registro sul disco prima di ridurlo. La syntax sarebbe simile a questa:

 BACKUP LOG MyDatabaseName TO DISK='C:\DatabaseBackups\MyDatabaseName_backup_2013_01_31_095212_8797154.trn' DBCC SHRINKFILE (N'MyDatabaseName_Log', 200) 

Il log delle transazioni di SQL Server deve essere gestito correttamente per evitare una crescita indesiderata. Ciò significa eseguire i backup del log delle transazioni abbastanza spesso. Non facendolo, rischi che il log delle transazioni diventi pieno e inizi a crescere.

Oltre alle risposte a questa domanda, consiglio di leggere e comprendere i miti comuni del log delle transazioni. Queste letture possono aiutare a capire il log delle transazioni e decidere quali tecniche utilizzare per “cancellarle”:

Dai 10 miti più importanti del log delle transazioni di SQL Server :

Mito: il mio SQL Server è troppo occupato. Non voglio creare backup del log delle transazioni di SQL Server

Una delle operazioni con prestazioni più elevate in SQL Server è un evento di crescita automatica del file di registro delle transazioni online. Non facendo abbastanza spesso i backup del log delle transazioni, il log delle transazioni online diventerà pieno e dovrà crescere. La dimensione di crescita predefinita è del 10%. Più il database è più occupato, più veloce sarà il registro delle transazioni online se i backup del log delle transazioni non vengono creati. La creazione di un backup del log delle transazioni di SQL Server non blocca il log delle transazioni online, ma avviene un evento di auto-crescita. Può bloccare tutte le attività nel registro delle transazioni online

Dai miti dei log delle transazioni :

Mito: la riduzione periodica del registro è una buona pratica di manutenzione

FALSO. La crescita del log è molto costosa perché il nuovo blocco deve essere azzerato. Tutte le attività di scrittura si fermano su quel database fino al termine dell’azzeramento, e se la scrittura del disco è lenta o la dimensione dell’aumento automatico è grande, tale pausa può essere enorme e gli utenti lo noteranno. Questa è una delle ragioni per cui vuoi evitare la crescita. Se riduci il log, questo ricrescerà di nuovo e stai solo sprecando l’operazione del disco in un inutile gioco di differenze inventariali

Questa tecnica consigliata da John non è consigliata in quanto non vi è alcuna garanzia che il database si alleghi senza il file di registro. Modificare il database da completo a semplice, forzare un checkpoint e attendere alcuni minuti. SQL Server cancellerà il registro, che potrà quindi essere ridotto utilizzando DBCC SHRINKFILE.

Innanzitutto controlla il modello di recupero del database. Per impostazione predefinita, SQL Server Express Edition crea un database per il modello di recupero semplice (se non sbaglio).

Log di backup DatabaseName con Truncate_Only:

 DBCC ShrinkFile(yourLogical_LogFileName, 50) 

SP_helpfile ti darà il nome log log del file.

Fare riferimento a:

Ripristina da un registro transazioni completo in un database SQL Server

Se il database è in Full Recovery Model e se non si sta eseguendo il backup TL, quindi modificarlo in SIMPLE.

Utilizzare il DBCC ShrinkFile ({logicalLogName}, TRUNCATEONLY) . Se si tratta di un database di test e si sta tentando di salvare / recuperare spazio, questo sarà di aiuto.

Ricorda però che i registri TX hanno una sorta di dimensioni minime / stabili a cui cresceranno. A seconda del modello di recupero, potresti non essere in grado di ridurre il registro: se in PIENO e non stai eseguendo il backup del registro TX, il registro non può essere ridotto: crescerà per sempre. Se non è necessario il backup del registro TX, impostare il modello di recupero su Semplice .

E ricorda, mai e poi mai in nessun caso cancellare il file di registro (LDF)! Avrai praticamente il danneggiamento immediato del database. Cucinato! Fatto! Dati persi! Se lasciato “non riparato” il file MDF principale potrebbe essere danneggiato in modo permanente.

Mai e poi mai cancellare il log delle transazioni: perderete i dati! Parte dei dati è nel Registro TX (indipendentemente dal modello di recupero) … se si scollega e “rinominare” il file di registro TX che elimina effettivamente parte del database.

Per coloro che hanno cancellato il registro TX, si consiglia di eseguire alcuni comandi checkdb e correggere il danneggiamento prima di perdere più dati.

Dai un’occhiata ai post sul blog di Paul Randal su questo argomento, un cattivo consiglio .

Inoltre, in generale, non utilizzare shrinkfile nei file MDF poiché può frammentare gravemente i dati. Controlla la sua sezione Bad Advice per maggiori informazioni (“Perché non dovresti ridurre i tuoi file di dati”)

Controlla il sito Web di Paul – egli copre queste stesse domande. Il mese scorso ha affrontato molti di questi problemi nella sua serie Myth A Day .

Per troncare il file di registro:

  • Backup del database
  • Scolbind il database, utilizzando Enterprise Manager o eseguendo: Sp_DetachDB [DBName]
  • Elimina il file di registro delle transazioni. (o rinominare il file, nel caso in cui)
  • Ricolbind nuovamente il database utilizzando: Sp_AttachDB [DBName]
  • Quando il database è collegato, viene creato un nuovo file di registro delle transazioni.

Per ridurre il file di registro:

  • Registro di backup [DBName] con No_Log
  • Riduci il database con:

    Utilizzo di Enterprise manager: – Fare clic con il tasto destro del mouse sul database, Tutte le attività, Riduci database, File, Seleziona file di registro, OK.

    Utilizzo di T-SQL: – Dbcc Shrinkfile ([Log_Logical_Name])

È ansible trovare il nome logico del file di registro eseguendo sp_helpdb o cercando nelle proprietà del database in Enterprise Manager.

Alla mia esperienza sulla maggior parte dei server SQL non è presente alcun backup del log delle transazioni. Backup completi o backup differenziali sono una pratica comune, ma i backup del log delle transazioni sono davvero rari. Quindi il file di registro delle transazioni cresce per sempre (fino a quando il disco è pieno). In questo caso il modello di recupero dovrebbe essere impostato su ” semplice “. Non dimenticare di modificare anche i database di sistema “model” e “tempdb”.

Un backup del database “tempdb” non ha senso, quindi il modello di recupero di questo db dovrebbe sempre essere “semplice”.

  1. Fai un backup del file MDB.
  2. Arresta i servizi SQL
  3. Rinominare il file di registro
  4. Avvia il servizio

(Il sistema creerà un nuovo file di registro.)

Elimina o sposta il file di registro rinominato.

Prova questo:

 USE DatabaseName GO DBCC SHRINKFILE( TransactionLogName, 1) BACKUP LOG DatabaseName WITH TRUNCATE_ONLY DBCC SHRINKFILE( TransactionLogName, 1) GO 

Database → tasto destro del mouse Proprietà → file → aggiungi un altro file di registro con un nome diverso e imposta il percorso come il vecchio file di registro con un nome file diverso.

Il database preleva automaticamente il file di registro appena creato.

  1. DB di backup
  2. Scollega DB
  3. Rinomina file di registro
  4. Allega DB (durante la connessione rimuovi rinominato .ldf (file di registro). Seleziona e rimuovi premendo il pulsante Rimuovi)
  5. Nuovo file di registro verrà ricreato
  6. Elimina il file di registro rinominato.

Questo funzionerà ma si consiglia di eseguire prima il backup del database.

Esempio:

 DBCC SQLPERF(LOGSPACE) BACKUP LOG Comapny WITH TRUNCATE_ONLY DBCC SHRINKFILE (Company_log, 500) DBCC SQLPERF(LOGSPACE) 

It happened with me where the database log file was of 28 GBs.

What can you do to reduce this? Actually, log files are those file data which the SQL server keeps when an transaction has taken place. For a transaction to process SQL server allocates pages for the same. But after the completion of the transaction, these are not released suddenly hoping that there may be a transaction coming like the same one. This holds up the space.

Step 1: First Run this command in the database query explored checkpoint

Step 2: Right click on the database Task> Back up Select back up type as Transaction Log Add a destination address and file name to keep the backup data (.bak)

Repeat this step again and at this time give another file name

inserisci la descrizione dell'immagine qui

Step 3: Now go to the database Right-click on the database

Tasks> Shrinks> Files Choose File type as Log Shrink action as release unused space

inserisci la descrizione dell'immagine qui

Passaggio 4:

Check your log file normally in SQL 2014 this can be found at

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

In my case, its reduced from 28 GB to 1 MB

DB Transaction Log Shrink to min size :

  1. Backup: Transaction log
  2. Shrink files: Transaction log
  3. Backup: Transaction log
  4. Shrink files: Transaction log

I made tests on several number of DBs: this sequence works .

It usually shrinks to 2MB .

OR by a script:

 DECLARE @DB_Name nvarchar(255); DECLARE @DB_LogFileName nvarchar(255); SET @DB_Name = ''; --Input Variable SET @DB_LogFileName = ''; --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