Come si cancella il registro delle transazioni di SQL Server?

https://stackoverflow.com/questions/56628

09-06-2019
|

Domanda

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

Soluzione

La riduzione delle dimensioni di un file di registro dovrebbe essere riservata agli scenari in cui ha riscontrato una crescita imprevista che non ti aspetti si ripeta.Se il file di registro raggiunge nuovamente le stesse dimensioni, non si ottiene molto riducendolo temporaneamente.Ora, a seconda degli obiettivi di ripristino del tuo database, queste sono le azioni da intraprendere.

Innanzitutto, esegui un backup completo

Non apportare mai modifiche al tuo database senza assicurarti di poterlo ripristinare nel caso qualcosa andasse storto.

Se ti interessa il recupero puntuale

(E per ripristino point-in-time intendo che ti interessa poter ripristinare qualcosa di diverso da un backup completo o differenziale.)

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

ALTER DATABASE testdb SET RECOVERY FULL;

Anche se si eseguono regolarmente backup completi, il file di registro aumenterà di dimensioni fino a quando non si esegue un file tronco d'albero backup: serve per la tua protezione, per non consumare inutilmente spazio su disco.Dovresti eseguire questi backup del log con una certa frequenza, in base ai tuoi obiettivi di ripristino.Ad esempio, se hai una regola aziendale che stabilisce che non puoi permetterti di perdere più di 15 minuti di dati in caso di disastro, dovresti avere un processo che esegua il backup del registro ogni 15 minuti.Ecco uno script che genererà nomi di file con timestamp in base all'ora corrente (ma puoi farlo anche con piani di manutenzione ecc., basta non scegliere nessuna delle opzioni di riduzione 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;

Notare che \\backup_share\ dovrebbe trovarsi su una macchina diversa che rappresenta un diverso dispositivo di archiviazione sottostante.Eseguire il backup sulla stessa macchina (o su una macchina diversa che utilizza gli stessi dischi sottostanti o su una VM diversa che si trova sullo stesso host fisico) non ti aiuta davvero, poiché se la macchina esplode, hai perso il database E i suoi backup.A seconda della tua infrastruttura di rete potrebbe avere più senso eseguire il backup localmente e poi trasferirli in una posizione diversa dietro le quinte;in entrambi i casi, è necessario rimuoverli dal computer del database primario il più rapidamente possibile.

Ora, una volta eseguiti i backup regolari del registro, dovrebbe essere ragionevole ridurre il file di registro a qualcosa di più ragionevole di quello che è stato ingrandito fino ad ora.Questo sì non significa correre SHRINKFILE più e più volte finché il file di registro non raggiunge 1 MB: anche se si esegue frequentemente il backup del registro, è comunque necessario che contenga la somma di tutte le transazioni simultanee che possono verificarsi.Gli eventi di aumento automatico dei file di registro sono costosi, poiché SQL Server deve azzerare i file (a differenza dei file di dati quando è abilitata l'inizializzazione istantanea dei file) e le transazioni degli utenti devono attendere mentre ciò avviene.Vuoi eseguire questa routine di crescita-riduzione-crescita-riduzione il meno possibile e certamente non vuoi che i tuoi utenti paghino per questo.

Tieni presente che potrebbe essere necessario eseguire il backup del registro due volte prima che sia possibile una riduzione (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 ridotto spesso il file di registro e questo è cresciuto di nuovo, una buona filigrana è probabilmente del 10-50% più alta della più grande che fosse .Supponiamo che arrivi a 200 MB e desideri che tutti gli eventi di crescita automatica successivi siano di 50 MB, quindi puoi regolare la dimensione del file di registro in questo modo:

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

Tieni presente che se il file di registro è attualmente > 200 MB, potrebbe essere necessario eseguirlo prima:

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

Se non ti interessa il recupero puntuale

Se si tratta di un database di prova e non ti interessa il ripristino point-in-time, dovresti assicurarti che il tuo database sia in SIMPLE modalità di recupero.

ALTER DATABASE testdb SET RECOVERY SIMPLE;

Inserimento del database SIMPLE la modalità di ripristino farà in modo che SQL Server riutilizzi parti del file di registro (sostanzialmente eliminando gradualmente le transazioni inattive) invece di ingrandirle per tenere un record di Tutto transazioni (come FULL il ripristino viene eseguito finché non viene eseguito il backup del registro). CHECKPOINT gli eventi aiuteranno a controllare il registro e ad assicurarsi che non abbia bisogno di crescere a meno che non si generi molta attività t-log tra CHECKPOINTS.

Successivamente, dovresti assicurarti assolutamente che questa crescita del registro sia realmente dovuta a un evento anomalo (ad esempio, una pulizia di primavera annuale o la ricostruzione dei tuoi indici più grandi) e non dovuta al normale utilizzo quotidiano.Se riduci il file di registro a dimensioni ridicolmente piccole e SQL Server deve solo ingrandirlo di nuovo per soddisfare la tua normale attività, cosa ottieni?Sei riuscito a utilizzare lo spazio su disco liberato solo temporaneamente?Se hai bisogno di una soluzione 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 dimensioni e tasso di crescita appropriati.Come nell'esempio del caso di ripristino temporizzato, è possibile utilizzare lo stesso codice e la stessa logica per determinare quale dimensione del file è appropriata e impostare parametri di crescita automatica ragionevoli.

Alcune cose che non vuoi fare

Eseguire il backup del registro con TRUNCATE_ONLY opzione e poi SHRINKFILE.Per prima cosa, questo TRUNCATE_ONLY l'opzione è stata deprecata e non è più disponibile nelle versioni correnti di SQL Server.Secondo, se sei dentro FULL modello di ripristino, ciò distruggerà la catena di log e richiederà un nuovo backup completo.
Scollegare il database, eliminare il file di registro e ricollegarlo.Non posso sottolineare quanto questo possa essere pericoloso.Il tuo database potrebbe non essere ripristinato, potrebbe risultare sospetto, potresti dover ripristinare un backup (se ne hai uno), ecc.eccetera.
Utilizza l'opzione "riduci database".. DBCC SHRINKDATABASE e l'opzione del piano di manutenzione per fare lo stesso sono cattive idee, soprattutto se hai davvero solo bisogno di risolvere un problema di registro.Scegli come target il file che desideri modificare e regolalo in modo indipendente, utilizzando DBCC SHRINKFILE O ALTER DATABASE ... MODIFY FILE (esempi sopra).
Riduci il file di registro a 1 MB.Sembra allettante perché, ehi, SQL Server me lo consente in determinati scenari e guarda tutto lo spazio che libera!A meno che il tuo database non sia di sola lettura (e lo è, dovresti contrassegnarlo come tale utilizzando ALTER DATABASE), ciò porterà assolutamente a molti eventi di crescita non necessari, poiché il registro deve contenere le transazioni correnti indipendentemente dal modello di ripristino.Qual è lo scopo di liberare temporaneamente quello spazio, solo in modo che SQL Server possa riprenderlo lentamente e faticosamente?
Creare un secondo file di registro.Ciò fornirà un sollievo temporaneo all'unità che ha riempito il disco, ma è come cercare di riparare un polmone perforato con un cerotto.Dovresti gestire direttamente il file di registro problematico invece di aggiungere semplicemente un altro potenziale problema.Oltre a reindirizzare alcune attività del registro delle transazioni su un'unità diversa, un secondo file di registro non fa davvero nulla per te (a differenza di un secondo file di dati), poiché è possibile utilizzare solo uno dei file alla volta. Paul Randal spiega anche perché più file di registro possono attaccarti in seguito.

Sii proattivo

Invece di ridurre il file di registro a una piccola quantità e lasciarlo crescere costantemente automaticamente a una velocità ridotta, impostalo su una dimensione ragionevolmente grande (che possa ospitare la somma del tuo insieme più grande di transazioni simultanee) e imposta un aumento automatico ragionevole impostandolo come riserva, 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 aziendali.

Le peggiori impostazioni possibili qui sono una crescita di 1 MB o una crescita del 10%.Abbastanza divertente, queste sono le impostazioni predefinite per SQL Server (di cui mi sono lamentato e ha 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 è 500 MB, la prima crescita è 50 MB, la crescita successiva è 55 MB, la crescita successiva è 60,5 MB , eccetera.eccetera.- e con I/O lento, credetemi, noterete davvero questa curva).

Ulteriori letture

Per favore, non fermarti qui;sebbene molti dei consigli che vedi in giro sulla riduzione dei file di registro siano intrinsecamente cattivi e persino potenzialmente disastrosi, ci sono alcune persone che si preoccupano più dell'integrità dei dati che della liberazione di spazio su disco.

Un post sul blog che ho scritto nel 2009, quando ho visto spuntare alcuni post "ecco come ridurre il file di registro".

Un post sul blog che Brent Ozar ha scritto quattro anni fa, indicando più risorse, in risposta a un articolo di SQL Server Magazine che dovrebbe non sono stati pubblicati.

Un post sul blog di Paul Randal che spiega perché la manutenzione del t-log è importante E perché non dovresti nemmeno ridurre i tuoi file di dati.

Mike Walsh ha un'ottima 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.

Altri suggerimenti

DISCLAIMER: Si prega di leggere attentamente i commenti qui sotto e presumo che tu abbia già letto la risposta accettata.Come ho detto quasi 5 anni fa:

Se qualcuno ha qualche commento da aggiungere per situazioni in cui questa non è una soluzione adeguata o ottimale, si prega di commentare di seguito

Fare clic con il tasto destro sul nome del database.
Seleziona Attività → Riduci → Database
Quindi fare clic OK!

Di solito apro la directory di Windows Explorer contenente i file del database, quindi posso vedere immediatamente l'effetto.

In realtà sono rimasto piuttosto sorpreso che abbia funzionato!Normalmente ho già utilizzato 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

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

PS:Apprezzo ciò che alcuni hanno commentato riguardo ai pericoli di ciò, ma nel mio ambiente non ho avuto problemi a farlo da solo, soprattutto perché prima eseguo sempre un backup completo.Quindi, prima di continuare, prendi in considerazione qual è il tuo ambiente e come questo influisce sulla tua strategia di backup e sulla sicurezza del lavoro.Tutto quello che stavo facendo era indirizzare le persone a 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 fare prima il backup.

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

Se riduci semplicemente il file perderai un sacco di dati che potrebbero salvarti la vita in caso di disastro.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 uno sforzo estremo).

Il registro delle transazioni è anche un must quando si tratta di ripristino puntuale, quindi non buttarlo via, ma assicurati di eseguirne il backup in anticipo.

Di seguito sono riportati diversi post in cui le persone hanno utilizzato i dati archiviati nel registro delle transazioni per eseguire il ripristino:

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

"Impossibile ridurre il file di registro (nome del file di registro) perché il file di registro logico situato alla fine del file è in uso"

Ciò significa che TLOG è in uso.In questo caso prova a eseguirlo più volte di seguito o trova un modo per ridurre le attività del database.

Se non si utilizzano i log delle transazioni per i ripristini (ad es.Se esegui solo backup completi), puoi impostare la modalità di ripristino su "Semplice" e il registro delle transazioni si ridurrà in breve tempo e non si riempirà mai più.

Se utilizzi SQL 7 o 2000, puoi abilitare "tronca registro al checkpoint" nella scheda delle opzioni del database.Questo ha lo stesso effetto.

Ovviamente questo non è consigliato negli ambienti di produzione, poiché non sarà possibile ripristinare un punto nel tempo.

Ecco un semplice e molto inelegante & potenzialmente pericoloso modo.

DB di backup
Stacca DB
Rinominare il file di registro
Allega DB
Il nuovo file di registro verrà ricreato
Elimina il file di registro rinominato.

Immagino che tu non stia eseguendo i backup del registro.(Che troncano il registro).Il mio consiglio è di cambiare modello di recupero da pieno A semplice.Ciò impedirà il gonfiamento del registro.

La maggior parte delle risposte qui finora presuppone che non sia effettivamente necessario il file di registro delle transazioni, tuttavia se il database utilizza il file FULL modello di ripristino e desideri conservare i backup nel caso in cui sia necessario ripristinare il database 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 a qualsiasi momento dall'ultimo backup completo, differenziale o del registro delle transazioni, fino al successivo backup completo. oppure viene eseguito il backup differenziale.

Dal Articolo Microsoft suBACKUP

Ti consigliamo di non utilizzare mai no_log o truncate_only per troncare manualmente il registro delle transazioni, perché questo interrompe la catena del log.Fino al successivo backup del database completo o differenziale, il database non è protetto dall'errore dei media.Utilizzare il troncamento del registro manuale in solo circostanze molto speciali e creare immediatamente backup dei dati.

Per evitare ciò, esegui il backup del file di registro su disco prima di rimpicciolirlo.La sintassi 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 registro delle transazioni di SQL Server deve essere mantenuto correttamente per prevenirne la crescita indesiderata.Ciò significa eseguire i backup del log delle transazioni con una frequenza sufficiente.In caso contrario, rischi che il registro delle transazioni si riempia e inizi a crescere.

Oltre alle risposte a questa domanda, consiglio di leggere e comprendere i miti comuni del registro delle transazioni.Queste letture possono aiutare a comprendere il registro delle transazioni e a decidere quali tecniche utilizzare per "cancellarlo":

Da I 10 miti più importanti sui log delle transazioni di SQL Server:

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

Una delle operazioni che richiedono maggiori prestazioni in SQL Server è un evento di aumento automatico delle dimensioni del file di registro delle transazioni online.Se non si eseguono backup del registro delle transazioni abbastanza spesso, il registro delle transazioni online si riempirà e dovrà crescere.La dimensione di crescita predefinita è 10%.Più busase è il database, più velocemente il registro delle transazioni online aumenterà se i backup del registro delle transazioni non vengono creati creando un backup del registro delle transazioni SQL Server non blocca il registro delle transazioni online, ma un evento di crescita automatica.Può bloccare tutte le attività nel registro delle transazioni online

Da Miti sul registro delle transazioni:

Mito:Il restringimento regolare dei tronchi è 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 interrompono su quel database fino al termine dell'azzeramento e se la scrittura del disco è lenta o le dimensioni di crescita automatica sono elevate, la pausa può essere enorme e gli utenti se ne accorgeranno.Questo è uno dei motivi per cui vuoi evitare la crescita.Se riduci il registro, crescerà di nuovo e stai solo sprecando operazioni sul disco in un inutile gioco di rimpicciolimento e crescita di nuovo

Questa tecnica consigliata da John non è consigliata poiché non vi è alcuna garanzia che il database venga collegato senza il file di registro.Cambia il database da completo a semplice, forza un checkpoint e attendi qualche minuto.SQL Server cancellerà il registro, che sarà quindi possibile ridurre utilizzando DBCC SHRINKFILE.

Controllare innanzitutto il modello di ripristino del database.Per impostazione predefinita, SQL Server Express Edition crea un database per il modello di ripristino semplice (se non sbaglio).

Registro di backup NomeDatabase con Truncate_Only:

DBCC ShrinkFile(yourLogical_LogFileName, 50)

SP_helpfile ti fornirà il nome del file di registro logico.

Fare riferimento a:

Ripristino da un registro completo delle transazioni in un database SQL Server

Se il tuo database è in modello di recupero completo e se non stai eseguendo il backup TL, modificalo in SIMPLE.

Usa il DBCC ShrinkFile ({logicalLogName}, TRUNCATEONLY) comando.Se questo è un database di prova e stai cercando di risparmiare/recuperare spazio, questo ti aiuterà.

Ricorda però che i log TX hanno una sorta di dimensione minima/stazionaria fino a cui cresceranno.A seconda del modello di ripristino, potresti non essere in grado di ridurre il registro: se è COMPLETO e non stai emettendo backup del registro TX, il registro non può essere ridotto: crescerà per sempre.Se non hai bisogno dei backup del log TX, passa al modello di ripristino Semplice.

E ricorda, non eliminare mai e in nessun caso il file di registro (LDF)!Avrai praticamente un danneggiamento istantaneo del database.Cucinato!Fatto!Dati persi!Se lasciato "non riparato", il file MDF principale potrebbe danneggiarsi in modo permanente.

Non eliminare mai il registro delle transazioni: perderai i dati!Parte dei tuoi dati si trova nel registro TX (indipendentemente dal modello di ripristino)...se scolleghi e "rinomini" il file di registro TX in modo efficace elimina parte del tuo database.

Per coloro che hanno eliminato il registro TX potresti voler eseguire alcuni comandi checkdb e correggere il danneggiamento prima di perdere ulteriori dati.

Dai un'occhiata ai post del blog di Paul Randal proprio su questo argomento, cattivo consiglio.

Inoltre, in generale, non utilizzare il file termoretraibile sui file MDF poiché può frammentare gravemente i dati.Controlla la sua sezione Cattivi consigli per maggiori informazioni ("Perché non dovresti ridurre i tuoi file di dati")

Dai un'occhiata al sito web di Paul: copre proprio queste domande.Il mese scorso ha affrontato molti di questi problemi nel suo Mito Un Giorno serie.

Per troncare il file di registro:

Eseguire il backup del database
Scollegare il database utilizzando Enterprise Manager o eseguendo: Sp_DetachDB [NomeDB]
Eliminare il file di registro delle transazioni.(o rinominare il file, per ogni evenienza)
Ricollegare nuovamente il database utilizzando: Sp_AttachDB [NomeDB]
Quando il database viene collegato, viene creato un nuovo file di registro delle transazioni.

Per ridurre il file di registro:

Log di backup [DBName] con No_Log
Riduci il database in uno dei seguenti modi:

Utilizzo di Enterprise Manager:- Fare clic con il tasto destro sul database, tutte le attività, il database di restringimento, i file, selezionare File di registro, OK.

Utilizzando T-SQL: -File di riduzione Dbcc ([Log_Logical_Name])

È possibile trovare il nome logico del file di registro eseguendo sp_helpdb o esaminando le proprietà del database in Enterprise Manager.

Secondo la mia esperienza, sulla maggior parte dei server SQL non è disponibile il backup del registro delle transazioni.I backup completi o differenziali sono una pratica comune, ma i backup del log delle transazioni sono davvero rari.Pertanto il file di registro delle transazioni cresce all'infinito (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 ripristino di questo db dovrebbe essere sempre "semplice".

Effettua un backup del file MDB.
Interrompere i servizi SQL
Rinominare il file di registro
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 → clic destro 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.

DB di backup
Stacca DB
Rinominare il file di registro
Allega DB (mentre alleghi rimuovi il file .ldf rinominato (file di registro). Selezionalo e rimuovi premendo il pulsante Rimuovi)
Il nuovo file di registro verrà ricreato
Elimina il file di registro rinominato.

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)

A me è successo che il file di registro del database fosse di 28 GB.

Cosa puoi fare per ridurlo?In realtà, i file di registro sono quei dati di file che il server SQL conserva quando ha avuto luogo una transazione.Affinché una transazione venga elaborata, il server SQL alloca le pagine per la stessa.Ma dopo il completamento della transazione, questi non vengono rilasciati improvvisamente sperando che possa verificarsi una transazione simile.Questo mantiene lo spazio.

Passo 1:Prima eseguire questo comando nella query del database esplorato

Passo 2:Fare clic con il tasto destro sull'attività del database> Backup Seleziona Tipo di backup come registro delle transazioni Aggiungi un indirizzo di destinazione e il nome del file per mantenere i dati di backup (.Bak)

Ripetere questo passaggio ancora una volta e in questo momento assegnare un altro nome al file

Passaggio 3:Ora vai al database facendo clic con il pulsante destro del mouse sul database

Attività> Riduci> File Scegliere Tipo di file come Azione di rimpasto di registro come Rilascio inutilizzato

Passaggio 4:

Controlla il tuo file di registro normalmente in SQL 2014 Questo può essere trovato su

C:\Programmi\Microsoft SQL Server\MSSQL12.MSSQL2014EXPRESS\MSSQL\DATA

Nel mio caso, è ridotto da 28 GB a 1 MB

Alcune delle altre risposte non hanno funzionato per me:Non è stato possibile creare il checkpoint mentre il db era online, perché il log delle transazioni era pieno (che ironia).Tuttavia, dopo aver impostato il database in modalità di emergenza, sono riuscito a ridurre il file di registro:

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

Registro delle transazioni DB Riduci alla dimensione minima:

Backup:Registro delle transazioni
Riduci i file:Registro delle transazioni
Backup:Registro delle transazioni
Riduci i file:Registro delle transazioni

Ho effettuato test su diversi numeri di DB: questa sequenza funziona.

Di solito si riduce a 2 MB.

OPPURE tramite uno script:

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

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow