Registro delle transazioni enorme con database SQL Server in modalità di ripristino semplice

Question

Ho un database SQL Server abbastanza grande che utilizza la modalità di ripristino SIMPLE. Non abbiamo davvero bisogno del secondo recupero, quindi preferirei rimanere in questa modalità.

Per qualche motivo il log delle transazioni per questo database è massiccio (410 GB) con il 99% dello spazio non allocato.

Ho provato a ridurre il file utilizzando (DBCC SHRINKFILE (MyDatabase_log, 20000)) ma non sembra funzionare.

Qualcuno ha qualche consiglio sul perché un database in modalità di ripristino SIMPLE abbia un file così grande? Mi piacerebbe davvero farla rimpicciolire.

Answer 1

Significa che una volta una singola transazione è durata così a lungo da costringere il log a crescere 410 GB. Il registro non può essere riutilizzato se esiste una transazione attiva poiché le informazioni di rollback non possono essere cancellate. Un esempio del genere sarebbe se qualcuno apre una query SSMS, avvia una transazione, aggiorna un record e poi va in vacanza. La transazione sarà attiva e imporrà il log a crescere fino a quando non verrà infine eseguito il commit o il rollback. Quando la transazione finisce, lo spazio utilizzato può finalmente essere recuperato, lasciando un enorme file di registro vuoto.

Un altro scenario è se si avessero circa 200 GB di dati aggiornati in un'unica transazione. Il log memorizzerà le immagini prima e dopo delle modifiche, consumando il doppio dello spazio e non può essere riutilizzato, perché è tutto una singola transazione.

Aggiornamento

ho trascurato di menzionare la replica che è anche un fattore che può impedire il troncamento del log. E così anche Mirroring, una transazione distribuita (tecnicamente è la stessa di una "transazione attiva", ma l'implicazione del DTC lo rende un caso distinto). L'elenco completo e le spiegazioni sono a Factors That Can Delay Log Truncation.

Answer 2

ti manca un argomento a dbcc shrinkfile:

dbcc shrinkfile (MyDatabase_log, 20000, TRUNCATEONLY) 

NOTRUNCATE è il default, che si muove allocato blocchi per l'inizio di spazio non allocato. TRUNCATEONLY rimuove lo spazio non allocato. Quindi se fai un NOTRUNCATE seguito da uno TRUNCATEONLY, ottieni un registro ridotto.

Answer 3

Se si dispone di un solo file mdf e un file di registro, il modo più semplice è quello di staccare il database, rinominare il registro e ricollegare il database. SQL Server creerà un nuovo file di registro. Dopo che il tuo enorme file di registro può essere cancellato in sicurezza.

Questo però non funzionerà se si dispone di più file di dati.

Answer 4

Editore di replica? Potrebbe essere questo il motivo dell'enorme registro delle transazioni?

Answer 5

Come detto in altre risposte, Transazioni attive e repliche sono cause tipiche per questo problema.
Un altro, meno visibile, è Change Data Capture (CDC).

Ho avuto un problema simile di recente e la procedura che mi ha permesso di liberare il registro è stato come segue:

• Disabilita CDC: EXEC sys.sp_cdc_disable_db
• creare una pubblicazione su un tavolo arbitraria all'interno del database in questione
• Elimina questa/tutte le pubblicazioni. EXEC sp_removedbreplication 'my_db' è un modo conveniente per farlo.
• compattare il registro, se lo desideri

Non sono sicuro perché il creazione/eliminazione di questa manichino/mai usato pubblicazione era necessario ma era così. A titolo di prova il database potrebbe aver avuto pubblicazioni precedenti che non erano state smaltite correttamente (si dice che succeda frequentemente con database ripristinati da un backup precedente).

Un altro utile idioma diagnostica è quello di verificare la log_reuse_wait_desc in sys.databases per il database incriminato. Questo campo ha letto REPLICATION finché non ho completato la procedura sopra riportata.

SELECT log_reuse_wait_desc, * FROM sys.databases where name = 'my_db'