Questa sembra essere una domanda comune nella maggior parte dei forum e in tutto il web, qui viene posta in molti formati che in genere suonano così:

In SQL Server -

• Quali sono alcuni dei motivi per cui il registro delle transazioni diventa così grande?
• Perché il mio file di registro è così grande?
• Quali sono alcuni modi per prevenire questo problema?
• Cosa devo fare quando mi metto in pista con la causa sottostante e voglio impostare il file di registro delle transazioni su una dimensione corretta?

Una risposta più breve:

Probabilmente hai una transazione in esecuzione da lungo tempo (manutenzione dell'indice? Eliminazione o aggiornamento di grandi lotti?) Oppure sei nella modalità di ripristino "predefinita" (più sotto su cosa si intende per impostazione predefinita) Fulle non hai eseguito un backup del registro (o non li stanno prendendo abbastanza frequentemente).

Se si tratta di un problema relativo al modello di recupero, la risposta semplice potrebbe essere Passa alla Simplemodalità di ripristino se non sono necessari il ripristino temporizzato e i backup regolari del registro. Molte persone, tuttavia, fanno la loro risposta senza comprendere i modelli di recupero. Continua a leggere per capire perché è importante e poi decidi cosa fai. Potresti anche iniziare a fare i backup dei log e rimanere in Fullrecupero.

Potrebbero esserci altri motivi, ma questi sono i più comuni. Questa risposta inizia ad approfondire i due motivi più comuni e ti fornisce alcune informazioni di base sul perché e come dietro i motivi, oltre ad esplorare altri motivi.

Una risposta più lunga: quali scenari possono far crescere il registro? Esistono molte ragioni, ma di solito queste sono le seguenti due configurazioni: c'è un malinteso sui modelli di recupero o ci sono transazioni a lungo termine. Continua a leggere per i dettagli.

Motivo principale 1/2: Non capire i modelli di recupero

( Essere in modalità di recupero completo e non eseguire backup del registro - Questa è la ragione più comune - lo sono la stragrande maggioranza di coloro che riscontrano questo problema. )

Sebbene questa risposta non sia un approfondimento nei modelli di recupero di SQL Server, l'argomento dei modelli di recupero è fondamentale per questo problema.

In SQL Server esistono tre modelli di recupero :

• Full,
• Bulk-Logged e
• Simple.

Ignoreremo Bulk-Loggedper ora diremo in un certo senso che si tratta di un modello ibrido e la maggior parte delle persone che si trovano in questo modello sono lì per un motivo e capiscono i modelli di recupero.

I due ci sta a cuore e la loro confusione sono la causa della maggior parte dei casi di persone che hanno questo problema sono Simplee Full.

Intervallo: recupero in generale

Prima di parlare di modelli di recupero: parliamo di recupero in generale. Se vuoi approfondire ulteriormente questo argomento, leggi il blog di Paul Randal e tutti i post che desideri. Per questa domanda, però:

1. Ripristino
   da arresto anomalo / riavvio Uno scopo del file di registro delle transazioni è il ripristino da arresto anomalo / riavvio . Per il roll forward e il rollback del lavoro svolto (roll forward / redo) prima di un arresto anomalo o riavvio e il lavoro avviato ma non terminato dopo un arresto anomalo o riavvio (rollback / annulla). È compito del registro delle transazioni verificare che una transazione sia iniziata ma non è mai terminata (il rollback o l'arresto anomalo / riavvio si è verificato prima del commit della transazione). In quella situazione, è compito del registro dire "Ehi ... questo non è mai veramente finito, facciamolo tornare indietro" durante il recupero. È anche compito del registro vedere che hai finito qualcosa e che alla tua applicazione client è stato detto che era finito (anche se non si era ancora indurito nel tuo file di dati) e dire"Ehi .. è successo davvero, facciamolo avanti, facciamo in modo che le applicazioni pensino che fosse" dopo un riavvio. Ora c'è di più ma questo è lo scopo principale.

2. Ripristino temporizzato
   L'altro scopo di un file di registro delle transazioni è quello di essere in grado di darci la possibilità di ripristinare in un momento nel tempo a causa di un "oops" in un database o di garantire un punto di ripristino in caso di un guasto hardware che coinvolge i dati e / o i file di registro di un database. Se questo registro delle transazioni contiene i record delle transazioni che sono state avviate e completate per il ripristino, SQL Server può e utilizza queste informazioni per portare un database dove si trovava prima che si verificasse un problema. Ma questa non è sempre un'opzione disponibile per noi. Perché ciò funzioni dobbiamo avere il nostro database nel giusto modello di recupero e dobbiamo fare i backup dei log .

Modelli di recupero

Sui modelli di recupero:

• Modello di recupero semplice
  Quindi, con l'introduzione di cui sopra, è più semplice parlare Simple Recoveryprima del modello. In questo modello, stai dicendo a SQL Server: "Sto bene usando il tuo file di registro delle transazioni per crash e riavvio del recupero ..." (Non hai davvero scelta lì. Cerca le proprietà ACID e questo dovrebbe avere senso rapidamente.) "... ma una volta che non ne hai più bisogno per quello scopo di recupero crash / riavvio, vai avanti e riutilizzi il file di registro."

  SQL Server ascolta questa richiesta in Simple Recovery e conserva solo le informazioni necessarie per eseguire il crash / riavvio del ripristino. Una volta che SQL Server è sicuro che possa essere ripristinato poiché i dati sono induriti nel file di dati (più o meno), i dati che sono stati induriti non sono più necessari nel registro e sono contrassegnati per il troncamento, il che significa che vengono riutilizzati.

• Modello di recupero completo
  Con Full Recovery, si dice a SQL Server che si desidera poter eseguire il ripristino in un determinato momento, purché il file di registro sia disponibile o in un determinato momento coperto da un backup del registro. In questo caso, quando SQL Server raggiunge il punto in cui sarebbe sicuro troncare il file di registro in Simple Recovery Model, non lo farà. Invece consente al file di registro di continuare a crescere e gli consentirà di continuare a crescere, fino a quando non si esegue un backup del registro (o si esaurisce lo spazio sull'unità del file di registro) in circostanze normali.

Il passaggio da Semplice a Completo ha un Gotcha.

Ci sono regole ed eccezioni qui. Di seguito parleremo di transazioni a lungo termine.

Ma un avvertimento da tenere a mente per la modalità di recupero completo è questo: se si passa alla Full Recoverymodalità, ma non si esegue mai un backup completo iniziale, SQL Server non rispetterà la richiesta di essere nel Full Recoverymodello. Il registro delle transazioni continuerà a funzionare come è stato Simplefino a quando non si passa al modello di recupero completo e si prende il primo Full Backup.

Il modello di recupero completo senza backup dei registri è errato.

Quindi, questa è la ragione più comune per la crescita incontrollata dei tronchi? Risposta: Essere in modalità di recupero completo senza alcun backup del registro.

Questo succede sempre alle persone.

Perché è un errore così comune?

Perché succede sempre? Perché ogni nuovo database ottiene l'impostazione del modello di recupero iniziale guardando il database del modello.

L'impostazione del modello di recupero iniziale del modello è sempre Full Recovery Model, fino a quando e a meno che qualcuno non lo modifichi. Quindi si potrebbe dire che il "modello di recupero predefinito" è Full. Molte persone non ne sono a conoscenza e hanno i loro database in esecuzione Full Recovery Modelsenza backup dei registri, quindi un file di registro delle transazioni molto più grande del necessario. Questo è il motivo per cui è importante modificare le impostazioni predefinite quando non funzionano per l'organizzazione e le sue esigenze)

Il modello di recupero completo con un numero insufficiente di backup dei registri è errato.

Puoi anche metterti nei guai qui non eseguendo backup dei log abbastanza frequentemente.
L'esecuzione di un backup del registro al giorno può sembrare soddisfacente, poiché un ripristino richiede meno comandi di ripristino, ma tenendo presente la discussione sopra, il file di registro continuerà a crescere e crescere fino a quando non si eseguono i backup del registro.

Come faccio a sapere di quale frequenza di backup del registro ho bisogno?

È necessario considerare la frequenza di backup del registro tenendo presente due aspetti:

1. Bisogni di recupero - Speriamo che questo sia il primo. Nel caso in cui l'unità che contiene il registro delle transazioni vada in errore o si verifichi una grave corruzione che influisce sul backup del registro, quanti dati possono essere persi? Se quel numero non supera i 10-15 minuti, è necessario eseguire il backup del registro ogni 10-15 minuti, fine della discussione.
2. Crescita dei log : se la tua organizzazione non ha problemi a perdere più dati a causa della possibilità di ricrearli facilmente quel giorno, potresti avere un backup dei log molto meno frequente di 15 minuti. Forse la tua organizzazione va bene ogni 4 ore. Ma devi guardare quante transazioni generi in 4 ore. Consentire al registro di continuare a crescere in quelle quattro ore renderà troppo grande un file di registro? Ciò significa che i backup del log impiegheranno troppo tempo?

Motivo principale 2/2: transazioni a lungo termine

( "Il mio modello di recupero va bene! Il registro è ancora in crescita! )

Questo può anche essere una causa di crescita dei tronchi incontrollata e incontrollata. Indipendentemente dal modello di recupero, ma spesso viene visualizzato come "Ma sono nel modello di recupero semplice: perché il mio registro continua a crescere ?!"

Il motivo qui è semplice: se SQL utilizza questo registro delle transazioni per scopi di recupero, come ho descritto sopra, deve vedere l'inizio di una transazione.

Se si dispone di una transazione che richiede molto tempo o di apportare molte modifiche, il registro non può troncarsi sul checkpoint per nessuna delle modifiche che sono ancora in transazioni aperte o che sono state avviate dall'inizio della transazione.

Ciò significa che una grande eliminazione, l'eliminazione di milioni di righe in un'istruzione di eliminazione è una transazione e il registro non può eseguire alcun troncamento fino a quando non viene eseguita l'intera eliminazione. In Full Recovery Model, questa eliminazione viene registrata e potrebbero essere molti record di registro. Stessa cosa con l'ottimizzazione dell'indice durante le finestre di manutenzione. Significa anche che una cattiva gestione delle transazioni e il mancato rispetto e la chiusura delle transazioni aperte possono davvero danneggiare te e il tuo file di registro.

Cosa posso fare per queste transazioni a lungo termine?

Puoi salvarti qui:

• Ridimensionare correttamente il file di registro per tenere conto dello scenario peggiore, come la manutenzione o operazioni note di grandi dimensioni. E quando cresci il tuo file di registro dovresti consultare questa guida (e i due collegamenti a cui ti manda) di Kimberly Tripp. Il giusto dimensionamento è estremamente critico qui.
• Osservando il tuo utilizzo delle transazioni. Non avviare una transazione nel server delle applicazioni e iniziare conversazioni lunghe con SQL Server e rischiare di lasciarne una aperta troppo a lungo.
• Guarda le transazioni implicite nelle tue dichiarazioni DML. Ad esempio: UPDATE TableName Set Col1 = 'New Value'è una transazione. Non ci ho messo BEGIN TRANe non c'è bisogno, è ancora una transazione che si impegna automaticamente al termine. Quindi, se si eseguono operazioni su un numero elevato di righe, considerare di raggruppare tali operazioni in blocchi più gestibili e dare al registro il tempo di recuperare. O considera la giusta dimensione per affrontarlo. O forse cercare di modificare i modelli di recupero durante una finestra di caricamento di massa.

Questi due motivi si applicano anche alla spedizione dei log?

Risposta breve: si. Risposta più lunga di seguito.

Domanda: "Sto utilizzando il log shipping, quindi i miei backup del log sono automatizzati ... Perché vedo ancora la crescita del log delle transazioni?"

Risposta: continua a leggere.

Che cos'è il log shipping?

Il log shipping è proprio quello che sembra: stai spedendo i tuoi backup del log delle transazioni a un altro server per scopi di DR. C'è qualche inizializzazione ma dopo che il processo è abbastanza semplice:

• Un lavoro per il backup del registro su un server,
• un lavoro per copiare quel registro di backup e
• un lavoro per ripristinarlo senza ripristino (o NORECOVERYo STANDBY) sul server di destinazione.

Ci sono anche alcuni lavori da monitorare e avvisare se le cose non vanno come previsto.

In alcuni casi, potresti voler eseguire il ripristino della spedizione dei log solo una volta al giorno o ogni tre giorni o una volta alla settimana. Questo va bene. Ma se si apporta questa modifica su tutti i lavori (incluso il backup del registro e i processi di copia) significa che si sta aspettando tutto quel tempo per eseguire un backup del registro. Ciò significa che avrai un sacco di crescita dei log - perché sei in modalità di recupero completo senza backup dei log - e probabilmente significa anche un file di log di grandi dimensioni da copiare. È necessario modificare solo la pianificazione del processo di ripristino e lasciare che i backup e le copie del registro vengano eseguiti su una base più frequente, altrimenti si risentirà del primo problema descritto in questa risposta.

Risoluzione dei problemi generali tramite codici di stato

Ci sono ragioni diverse da queste due, ma queste sono le più comuni. Indipendentemente dalla causa: esiste un modo per analizzare la ragione di questa crescita / mancanza di tronchi inspiegabile e vedere quali sono.

Interrogando la sys.databasesvista del catalogo è possibile visualizzare informazioni che descrivono il motivo per cui il file di registro potrebbe essere in attesa di troncamento / riutilizzo.

Esiste una colonna chiamata log_reuse_waitcon un ID di ricerca del codice motivo e una log_reuse_wait_desccolonna con una descrizione del motivo di attesa. Dall'articolo online dei libri di riferimento sono la maggior parte dei motivi (quelli che è probabile che tu veda e quelli per cui possiamo spiegare i motivi. Quelli mancanti sono fuori uso o per uso interno) con alcune note sull'attesa in corsivo :

• 0 = Niente
  Come sembra .. Non dovresti aspettare

• 1 = Checkpoint In
  attesa che si verifichi un checkpoint. Questo dovrebbe accadere e dovresti andare bene, ma ci sono alcuni casi da cercare qui per risposte o modifiche successive.

• 2 = Backup del registro
  Stai aspettando che si verifichi un backup del registro. O li hai programmati e accadrà presto, oppure hai il primo problema descritto qui e ora sai come risolverlo

• 3 = Backup o ripristino attivo
  Nel database è in esecuzione un'operazione di backup o ripristino

• 4 = Transazione attiva
  Esiste una transazione attiva che deve essere completata (in entrambi i modi - ROLLBACKo COMMIT) prima di poter eseguire il backup del registro. Questa è la seconda ragione descritta in questa risposta.

• 5 = Mirroring del database
  Un mirror si trova in ritardo o in fase di latenza in una situazione di mirroring ad alte prestazioni o il mirroring viene sospeso per qualche motivo

• 6 = Replica
  Ci possono essere problemi con la replica che potrebbero causare questo - come un agente del lettore di registri non in esecuzione, un database che pensa che sia contrassegnato per la replica che non esiste più e vari altri motivi. Puoi anche vedere questo motivo ed è perfettamente normale perché stai guardando al momento giusto, proprio come le transazioni vengono consumate dal lettore di log

• 7 = Creazione dello snapshot del database
  Stai creando uno snapshot del database, lo vedrai se guardi il momento giusto mentre viene creato uno snapshot

• 8 = Log Scan
  Devo ancora riscontrare un problema con questo per sempre. Se guardi abbastanza a lungo e abbastanza frequentemente puoi vedere che ciò accada, ma non dovrebbe essere una causa dell'eccessiva crescita del registro delle transazioni, che ho visto.

• 9 = Una replica secondaria dei gruppi di disponibilità AlwaysOn applica i record del registro delle transazioni di questo database a un database secondario corrispondente. Circa la descrizione più chiara ancora ..

Dal momento che non sono davvero soddisfatto delle risposte su Stack Overflow , incluso il suggerimento più votato, e poiché ci sono alcune cose che vorrei affrontare a cui la risposta di Mike non lo fa, ho pensato che avrei fornito il mio contributo anche qui. Ho inserito anche una copia di questa risposta.

La riduzione di un file di registro dovrebbe essere riservata agli scenari in cui si è verificata una crescita imprevista che non si prevede si ripeta. Se il file di registro tornerà alla stessa dimensione, non si ottiene molto ridimensionandolo temporaneamente. Ora, a seconda degli obiettivi di recupero del database, queste sono le azioni da intraprendere.

Innanzitutto, esegui un backup completo

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

Se ti interessa il recupero temporizzato

(E per ripristino temporizzato, intendo che ti interessa poter ripristinare qualsiasi cosa diversa da un backup completo o differenziale.)

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

ALTER DATABASE yourdb SET RECOVERY FULL;

Anche se si eseguono backup completi regolari, il file di registro aumenterà e crescerà fino a quando non si esegue un backup del registro - questo è per la propria protezione, per non consumare inutilmente lo spazio su disco. Dovresti eseguire questi backup dei log abbastanza frequentemente, in base ai tuoi obiettivi di recupero. Ad esempio, se si dispone di una regola aziendale in base alla quale è possibile permettersi di perdere non meno di 15 minuti di dati in caso di emergenza, è necessario disporre di un processo che esegua il backup del registro ogni 15 minuti. Ecco uno script che genererà nomi di file con data e ora in base all'ora corrente (ma puoi anche farlo con piani di manutenzione, ecc., Non scegliere alcuna delle opzioni di riduzione nei piani di manutenzione, sono orribili).

DECLARE @path NVARCHAR(255) = N'\\backup_share\log\yourdb_' 
  + 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\dovrebbe essere su un computer diverso che rappresenta un dispositivo di archiviazione sottostante diverso. Il backup di questi sullo stesso computer (o su un computer diverso che utilizza gli stessi dischi sottostanti o una macchina virtuale diversa che si trova sullo stesso host fisico) non ti aiuta davvero, poiché se il computer esplode, hai perso il database e i suoi backup. A seconda dell'infrastruttura di rete potrebbe essere più sensato eseguire il backup in locale e trasferirli in una posizione diversa dietro le quinte; in entrambi i casi, si desidera eliminarli dal computer di database primario il più rapidamente possibile.

Ora, una volta eseguiti regolarmente i backup dei registri, dovrebbe essere ragionevole ridurre il file di registro a qualcosa di più ragionevole di qualsiasi cosa sia stata fatta saltare in aria. Ciò non significa eseguire SHRINKFILEripetutamente fino a quando il file di registro non è 1 MB - anche se si esegue il backup del registro frequentemente, deve comunque contenere la somma di tutte le transazioni simultanee che possono verificarsi. Gli eventi di crescita automatica dei file di registro sono costosi, poiché SQL Server deve azzerare i file (diversamente dai file di dati quando l'inizializzazione dei file è abilitata) e le transazioni degli utenti devono attendere mentre ciò accade. Volete eseguire questa routine di crescita, riduzione, riduzione, il meno possibile e certamente non volete che i vostri utenti paghino.

Si noti 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 che cosa è senza sapere molto di più sul tuo sistema, ma se hai spesso ridotto il file di registro ed è cresciuto di nuovo, una buona filigrana è probabilmente del 10-50% più alta di quella che è stata . Supponiamo che arrivi a 200 MB e desideri che eventuali eventi di crescita automatica successivi siano 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

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 temporizzato

Se si tratta di un database di prova e non ti interessa il ripristino temporizzato, devi assicurarti che il database sia in SIMPLEmodalità di ripristino.

ALTER DATABASE yourdb SET RECOVERY SIMPLE;

Mettendo il database in SIMPLEmodalità di ripristino si accerterà che SQL Server riutilizzi parti del file di registro (essenzialmente eliminando gradualmente le transazioni inattive) invece di crescere per tenere un registro di tutte le transazioni (come FULLfa il recupero fino a quando non si esegue il backup del registro). CHECKPOINTgli eventi aiuteranno a controllare il registro e ad assicurarsi che non debba crescere a meno che non si generi molta attività t-log tra CHECKPOINTi messaggi.

Successivamente, dovresti assolutamente assicurarti che questa crescita del registro sia stata davvero dovuta a un evento anomalo (diciamo, una pulizia annuale della primavera o alla ricostruzione dei tuoi più grandi indici) e non al normale utilizzo quotidiano. Se riduci il file di registro a dimensioni ridicolmente ridotte e SQL Server deve semplicemente ingrandirlo nuovamente per adattarsi alla tua normale attività, che cosa hai guadagnato? Sei riuscito a sfruttare lo spazio su disco che hai 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
-- 200 MB
DBCC SHRINKFILE(yourdb_log, 200);
GO

In caso contrario, impostare una dimensione e un tasso di crescita adeguati. Come nell'esempio nel caso del recupero 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 l' TRUNCATE_ONLYopzione e quindiSHRINKFILE . Per uno, questa TRUNCATE_ONLYopzione è stata deprecata e non è più disponibile nelle versioni correnti di SQL Server. In secondo luogo, se si è nel FULLmodello di recupero, 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 possa essere pericoloso. Il database potrebbe non essere ripristinato, potrebbe essere considerato sospetto, potrebbe essere necessario ripristinare un backup (se ne hai uno), ecc. Ecc.

• Utilizzare l'opzione "riduci database" . DBCC SHRINKDATABASEe l'opzione del piano di manutenzione per fare lo stesso è una cattiva idea, soprattutto se è necessario solo risolvere un problema di registro. Scegli come target il file che desideri regolare e modificalo in modo indipendente, utilizzando DBCC SHRINKFILEo ALTER DATABASE ... MODIFY FILE(esempi sopra).

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

• Crea un secondo file di registro . Ciò fornirà un sollievo temporaneo all'unità che ha riempito il disco, ma è come provare a 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), dal momento che solo uno dei file può mai essere utilizzato alla volta. Paul Randal spiega anche perché più file di registro possono morderti in seguito .

Sii proattivo

Invece di ridurre il file di registro in una piccola quantità e lasciarlo costantemente in automatico a una piccola velocità da solo, impostalo su una dimensione ragionevolmente grande (uno che soddisferà la somma del tuo più grande insieme di transazioni simultanee) e imposta un ragionevole aumento automatico impostazione come fallback, in modo che non debba crescere più volte per soddisfare le singole transazioni e che sarà relativamente raro che debba mai crescere durante le normali operazioni aziendali.

Le impostazioni peggiori 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 ho chiesto modifiche senza risultati ) - 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 a eventi sempre più lunghi ogni volta (diciamo, il tuo file di registro è di 500 MB, la prima crescita è di 50 MB, la prossima crescita è di 55 MB, la crescita successiva è di 60,5 MB , ecc. ecc. - e su I / O lento, credimi, noterai davvero questa curva).

Ulteriori letture

Per favore, non fermarti qui; mentre molti dei consigli che vedi là fuori sulla riduzione dei file di registro sono intrinsecamente cattivi e persino potenzialmente disastrosi, ci sono alcune persone che si preoccupano più dell'integrità dei dati che della liberazione dello 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 Brent Ozar ha scritto quattro anni fa, indicando più risorse, in risposta a un articolo della rivista SQL Server 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 dovresti nemmeno ridurre i tuoi file di dati .

• Mike Walsh ha un'ottima risposta sopra, ovviamente, che copre anche alcuni di questi aspetti, compresi i motivi per cui potresti non essere in grado di ridurre immediatamente il tuo file di registro .

Puoi anche vedere il contenuto del tuo file di registro. Per fare ciò, è possibile utilizzare il fn_dbloglettore non documentato o un registro delle transazioni, come ApexSQL Log .

Non mostra indice di riorganizzazione, ma mostra tutto DML e DDL vari eventi: ALTER, CREATE, DROP, grilletto abilitare / disabilitare, concessione / autorizzazioni, oggetto Rinomina revoca.

Disclaimer: lavoro per ApexSQL come tecnico dell'assistenza

Questo è il problema più frequente per quasi tutti i DBA in cui i log crescono e riempiono il disco.

• Quali sono alcuni dei motivi per cui il registro delle transazioni diventa così grande?

1. Transazione attiva lunga
2. Transazioni con registrazione elevata come ricostruzione degli indici, riorganizzazione, inserimento in blocco, eliminazione ecc.
3. Qualsiasi HA come Replication, Mirroring configurato che contiene il registro e non gli consente di rilasciare lo spazio del registro

• Perché il mio file di registro è così grande?

Controlla la log_reuse_wait_descolonna c nella sys.databasestabella per sapere cosa trattiene i tronchi dal troncamento:

select name, log_reuse_wait_desc 
from sys.databases

• Quali sono alcuni modi per prevenire questo problema?

I backup dei log ti aiuteranno a controllare la crescita dei log a meno che non ci sia qualcosa che li trattiene dal riutilizzo.

• Cosa devo fare quando mi metto in pista con la causa sottostante e voglio che il mio file di registro delle transazioni abbia dimensioni adeguate?

Se hai identificato ciò che lo sta effettivamente causando, prova a risolverlo di conseguenza, come spiegato nella pagina seguente.

https://www.brentozar.com/archive/2016/03/my-favorite-system-column-log_reuse_wait_desc/

La pianificazione dei backup dei log corretti è il modo migliore per gestire la crescita dei log a meno che non si verifichi una situazione insolita.