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 restringendolo 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 testdb 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 non perdere più 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\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\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 del registro, 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 di cosa si tratta 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 qualsiasi evento di crescita automatica successiva sia 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
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 testdb 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 sia necessario che cresca a meno che non si generi molta attività t-log tra CHECKPOINTi messaggi.
Successivamente, dovresti assicurarti assolutamente 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 soddisfare la 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
DBCC SHRINKFILE(yourdb_log, 200); -- unit is set in MBs
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. Scegliere come target il file che si desidera regolare e modificarlo in modo indipendente, utilizzando DBCC SHRINKFILEo ALTER DATABASE ... MODIFY FILE(esempi sopra).
Riduci il file di registro a 1 MB . Questo sembra allettante perché, ehi, SQL Server mi lascerà farlo in determinati scenari e guarderà tutto lo spazio che libera! A meno che il tuo database non sia di sola lettura (ed è, dovresti contrassegnarlo come tale usando 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. È necessario 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é 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 crescere automaticamente da solo a una piccola velocità, 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 scritto da Brent Ozar 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 anche su alcuni di questi aspetti, inclusi i motivi per cui potresti non essere in grado di ridurre immediatamente il tuo file di registro .
