Perché non riesco a ridurre un file di registro delle transazioni, anche dopo il backup?

Question

Ho un database con un file di registro delle transazioni da 28gig. La modalità di recupero è semplice. Ho appena preso un backup completo del database, e poi corse entrambi:

backup log dbmcms with truncate_only

DBCC SHRINKFILE ('Wxlog0', TRUNCATEONLY)

Il nome del db è db_mcms e il nome del file di log delle transazioni è Wxlog0.

Nessuno dei due ha aiutato. Non sono sicuro di cosa fare dopo.

Answer 1

Grazie a tutti per rispondere.

Abbiamo finalmente trovato il problema. In sys.databases, log_reuse_wait_desc era uguale a "replica". Apparentemente questo significa qualcosa per l'effetto di SQL Server in attesa del completamento di un'attività di replica prima che possa riutilizzare lo spazio del log.

La replica non è mai stata utilizzata su questo DB o su questo server è stato giocato con una volta su questo db. Abbiamo cancellato lo stato errato eseguendo sp_removedbreplication. Dopo averlo eseguito, il registro di backup e il file dbcc shrinkfile funzionavano perfettamente.

Sicuramente uno per il bag-of-trick.

Fonti:

http://social.technet.microsoft.com/Forums/pt-BR/sqlreplication/thread/34ab68ad-706d-43c4-8def-38c09e3bfc3b

http://www.eggheadcafe.com/conversation.aspx?messageid=34020486&threadid=33890705

Answer 2

Hai provato da studio di gestione SQL Server con la GUI. Fare clic con il tasto destro del mouse sul database, attività, riduci, file. Seleziona filetype = Log.

Ho lavorato per me una settimana fa.

Answer 3

non avete bisogno di questo

DBCC SHRINKFILE ('Wxlog0', 0) 

Basta essere sicuri che siete a conoscenza dei pericoli: vedi qui: Do not truncate your ldf files!

E qui Backup Log with Truncate_Only: Like a Bear Trap

Answer 4

tenta di utilizzare dimensioni di destinazione è necessario insted di TRUNCATEONLY in DBCC:

DBCC SHRINKFILE ('Wxlog0', 1)

E controllare questo per articoli:

http://msdn.microsoft.com/en-us/library/ms189493(SQL.90).aspx

http://support.microsoft.com/kb/907511

Edit:

Si può cercare di spostare le pagine allocate all'inizio del file di registro prima con

DBCC SHRINKFILE ('Wxlog0', NOTRUNCATE)

ea poppa er che

DBCC SHRINKFILE ('Wxlog0', 1)

Answer 5

Prova a creare un altro backup completo dopo aver eseguire il backup del registro w/truncate_only (IIRC si dovrebbe fare questo comunque a mantenere la catena di log). Nella modalità di ripristino semplice, il tuo registro non dovrebbe crescere molto in quanto è effettivamente troncato dopo ogni transazione. Quindi prova a specificare la dimensione desiderata per il file di log, ad es.

-- shrink log file to c. 1 GB 
DBCC SHRINKFILE (Wxlog0, 1000); 

L'opzione TRUNCATEONLY non riordinare le pagine all'interno del file di registro, quindi si potrebbe avere una pagina attiva alla "fine" del file, che potrebbe impedire che venga ridotto.

È inoltre possibile utilizzare DBCC SQLPERF (LOGSPACE) per assicurarsi che sia disponibile spazio nel file di registro per essere liberato.

Answer 6

Reinserire il DB in modalità Completa, eseguire il backup del log delle transazioni (non solo un backup completo) e quindi il restringimento.

Dopo che è ridotto, è possibile ripristinare il DB in modalità semplice e il registro txn rimarrà della stessa dimensione.

Answer 7

Non è possibile ridurre un registro delle transazioni inferiore alla dimensione inizialmente creata.

Answer 8

Se si imposta la modalità di ripristino sul database nel 2005 (non si conosce per il 2005), il file di registro verrà rilasciato tutto insieme e quindi sarà possibile reinserirlo in modalità di ripristino completo per riavviare/ricreare il file di registro . Ci siamo imbattuti in questo con SQL 2005 Express in quanto non siamo riusciti ad avvicinarci al limite di 4 GB con i dati finché non abbiamo cambiato la modalità di ripristino.

Answer 9

Si può incorrere in questo problema se il database è impostato per aumentare automaticamente il registro & si finisce con un sacco di file di registro virtuali.
Esegui DBCC LOGINFO('databasename') & guarda l'ultima voce, se questo è un 2 allora il tuo file di log non si restringerà. A differenza dei file di dati, i file di registro virtuali non possono essere spostati all'interno del file di registro.

Sarà necessario eseguire BACKUP LOG e DBCC SHRINKFILE diverse volte per ridurre il file di registro.

Per i punti bonus extra correre DBBC loginfo tra registro & si sottrae

Answer 10

che ho avuto lo stesso problema in passato. Normalmente è necessario che si verifichino più volte una riduzione e un backup trn. In casi estremi, ho impostato il DB per il recupero "Semplice" e quindi ho eseguito un'operazione di riduzione sul file di registro. Questo funziona sempre per me. Comunque recentemente ho avuto una situazione in cui ciò non avrebbe funzionato. Il problema è stato causato da una query di lunga durata che non è stata completata, quindi qualsiasi tentativo di riduzione è stato inutile fino a quando non ho potuto terminare il processo e quindi eseguire le mie operazioni di riduzione. Stiamo parlando di un file di registro cresciuto a 60 GB e ora ridotto a 500 MB.

Ricordare, non appena si passa dalla modalità di ripristino FULL a Simple e si esegue il restringimento, non dimenticare di riportarlo su FULL. Quindi subito dopo è necessario eseguire un backup FULL DB.

Answer 11

'sp_removedbreplication' non ha risolto il problema per me quando SQL ha appena restituito che il database non faceva parte di una replica ...

Ho trovato la mia risposta qui:

• http://www.sql-server-performance.com/forum/threads/log-file-fails-to-truncate.25410/
• http://blogs.msdn.com/b/sqlserverfaq/archive/2009/06/01/size-of-the-transaction-log-increasing-and-cannot-be-truncated-or-shrinked-due-to-snapshot-replication.aspx

Fondamentalmente ho dovuto creare una replica, ripristinare tutte le indicazioni di replica a zero; quindi elimina la replica che avevo appena creato. cioè

Execute SP_ReplicationDbOption {DBName},Publish,true,1 
GO 
Execute sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0, @time = 0, @reset = 1 
GO 
DBCC ShrinkFile({LogFileName},0) 
GO 
Execute SP_ReplicationDbOption {DBName},Publish,false,1 
GO 

Answer 12

Questa risposta è stato sollevato da here ed è postato qui nel caso in cui l'altro thread viene eliminato:

Il fatto che si dispone di non distribuito LSN nel registro è il problema. L'ho già visto una volta, non sono sicuro del motivo per cui non deselezioniamo la transazione come replicata. Lo esamineremo internamente. È possibile eseguire il seguente comando per deselezionare la transazione come replicato

EXEC sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0, @time = 0, @reset = 1 

A questo punto si dovrebbe essere in grado di troncare il log.

Answer 13

Ho provato tutte le soluzioni elencate e nessuna ha funzionato. Ho finito per dover fare uno sp_detach_db, quindi eliminare il file ldf e ricollegare il database forzandolo per creare un nuovo file ldf. Ha funzionato.

Answer 14

So che questo ha qualche anno, ma volevo aggiungere qualche informazione.

Ho trovato in registri di grandi dimensioni, in particolare quando il DB non era impostato per il backup dei registri delle transazioni (i registri erano molto grandi), il primo backup dei registri non avrebbe impostato log_reuse_wait_desc a nient'altro che lasciare lo stato come backup. Questo bloccherebbe lo strizzacervelli. Eseguendo il backup una seconda volta, reimpostare correttamente log_reuse_wait_desc su NOTHING, consentendo l'elaborazione del restringimento.