Sqlserver
 sql >> Database >  >> RDS >> Sqlserver

Come si cancella il registro delle transazioni di SQL Server?

Ridurre un file di registro dovrebbe davvero essere riservato agli scenari in cui ha riscontrato una crescita imprevista che non ti aspetti si ripeta. Se il file di registro crescerà nuovamente alla stessa dimensione, non si ottiene molto riducendolo temporaneamente. Ora, a seconda degli obiettivi di ripristino del tuo database, queste sono le azioni che dovresti intraprendere.

Per prima cosa, fai un backup completo

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

Se ti interessa il ripristino temporizzato

(E per ripristino point-in-time, intendo che ti interessa essere in grado di eseguire il ripristino su qualsiasi cosa diversa da un backup completo o differenziale.)

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

ALTER DATABASE testdb SET RECOVERY FULL;

Anche se stai eseguendo backup completi regolari, il file di registro crescerà fino a quando non eseguirai un log backup - questo è per la tua protezione, per non consumare inutilmente spazio su disco. Dovresti eseguire questi backup del registro abbastanza frequentemente, in base ai tuoi obiettivi di ripristino. Ad esempio, se hai una regola aziendale che afferma che puoi permetterti di perdere non più di 15 minuti di dati in caso di emergenza, dovresti avere un lavoro che esegue 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., ma 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;

Nota che \\backup_share\ dovrebbe trovarsi su una macchina diversa che rappresenta un diverso dispositivo di archiviazione sottostante. Il backup di questi sulla stessa macchina (o su una macchina diversa che utilizza gli stessi dischi sottostanti o 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 dell'infrastruttura di rete, potrebbe avere più senso eseguire il backup in locale e quindi trasferirli in una posizione diversa dietro le quinte; in entrambi i casi, vuoi rimuoverli dalla macchina del database principale il più rapidamente possibile.

Ora, una volta eseguiti i backup dei registri regolari, dovrebbe essere ragionevole ridurre il file di registro a qualcosa di più ragionevole di qualunque cosa sia stato fatto esplodere fino ad ora. Questo non significa eseguire SHRINKFILE più e più volte fino a quando il file di registro è 1 MB, anche se si esegue frequentemente il backup del registro, è comunque necessario contenere 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 utente devono attendere mentre ciò accade. Vuoi eseguire questa routine di crescita-rimpicciolimento-crescita-rimpicciolimento il meno possibile e di certo 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 ed è cresciuto di nuovo, una buona filigrana è probabilmente del 10-50% superiore alla più grande che è stata . Supponiamo che arrivi a 200 MB e desideri che tutti gli eventi di crescita automatica successivi siano 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 eseguire prima questo:

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

Se non ti interessa il ripristino temporizzato

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

ALTER DATABASE testdb SET RECOVERY SIMPLE;

Mettere il database in SIMPLE la modalità di ripristino assicurerà che SQL Server riutilizzi parti del file di registro (essenzialmente eliminando gradualmente le transazioni inattive) invece di aumentare per mantenere un record di tutti transazioni (come FULL il ripristino lo fa fino a quando non esegui il backup del registro). CHECKPOINT events aiuteranno a controllare il registro e ad assicurarsi che non debba crescere a meno che non generi molte attività t-log tra CHECKPOINT s.

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

Alcune cose che non vuoi fare

  • Esegui il backup del registro con TRUNCATE_ONLY opzione e quindi SHRINKFILE . Per uno, questo TRUNCATE_ONLY opzione è stata deprecata e non è più disponibile nelle versioni correnti di SQL Server. Secondo, se sei in FULL modello di ripristino, questo distruggerà la tua catena di log e richiederà un nuovo backup completo.

  • Scollega il database, elimina il file di registro e ricollega . Non posso sottolineare quanto possa essere pericoloso. Il tuo database potrebbe non tornare indietro, potrebbe risultare sospetto, potresti dover ripristinare un backup (se ne hai uno), ecc. ecc.

  • 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 . Questo sembra allettante perché, ehi, SQL Server mi permetterà di farlo in determinati scenari e guarderà tutto lo spazio che libera! A meno che il tuo database non sia di sola lettura (e lo è, dovresti contrassegnarlo come tale usando ALTER DATABASE ), ciò comporterà assolutamente molti eventi di crescita non necessari, poiché il registro deve accogliere le transazioni correnti indipendentemente dal modello di ripristino. Qual è lo scopo di liberare temporaneamente quello spazio, solo così SQL Server può riprenderlo lentamente e faticosamente?

  • Crea un secondo file di registro . Ciò fornirà un sollievo temporaneo per l'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 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 morderti in seguito.

Sii proattivo

Invece di ridurre il tuo file di registro a una piccola quantità e lasciarlo crescere costantemente automaticamente a una piccola velocità da solo, impostalo su una dimensione ragionevolmente grande (una che ospiterà la somma del tuo set più grande di transazioni simultanee) e imposta una crescita automatica ragionevole impostazione come fallback, in modo che non debba crescere più volte per soddisfare singole transazioni e quindi sarà 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 ho chiesto modifiche inutilmente):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 (ad esempio, il tuo file di registro è 500 MB, la prima crescita è 50 MB, la crescita successiva è 55 MB, la crescita successiva è 60,5 MB , ecc. ecc. - e su I/O lento, credetemi, noterete davvero questa curva).

Ulteriori letture

Per favore, non fermarti qui; sebbene molti dei consigli che trovi là fuori sulla riduzione dei file di registro siano intrinsecamente negativi 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 scritto da Brent Ozar quattro anni fa, indicando più risorse, in risposta a un articolo di SQL Server Magazine che non dovrebbe 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.