it-swarm.it

In che modo la riduzione di un file di registro di SQL Server influisce sulle prestazioni?

Ho un database SQL Server 2008 che ha un file di dati di circa 2 GB di dimensioni, ma il file di registro è superiore a 8 GB. Con i database precedenti al 2008 ho potuto utilizzare il "Registro di backup" e il TRUNCATE_ONLY ma non è più disponibile con i database del 2008 e successivi.

Ho uno script che tronca il file di registro:

USE [MyDatabase]
GO
ALTER DATABASE [MyDatabase] SET RECOVERY SIMPLE WITH NO_WAIT
DBCC shrinkfile('MyDatabase_log', 1)
ALTER DATABASE [MyDatabase] SET RECOVERY FULL WITH NO_WAIT
GO

Questo tronca completamente il file di registro, ma la mia domanda è: Ciò influisce sulle prestazioni?

Eseguo due backup completi ogni giorno, quindi il registro non dovrebbe essere realmente necessario per quanto riguarda il roll-forward dei dati.

19
MartinHT

Consiglio vivamente di leggere Importanza della corretta gestione delle dimensioni del registro delle transazioni di Paul S. Randal.

La quintessenza è che ci sono solo due modi davvero validi per fare gestione del registro delle transazioni :

  1. O vai con i normali backup dei file LOG e il file LOG riutilizzerà lo spazio dopo ogni backup LOG e non crescerà indefinitamente, oppure

  2. Utilizzare il modello di recupero SEMPLICE e non è necessario preoccuparsi delle dimensioni del file LOG, poiché si eseguono backup completi regolari.

Ciò che riguarda il troncamento e le prestazioni del file LOG è che otterrai sempre un successo prestazionale quando il file LOG deve essere aumentato (una citazione da sopra- post di blog collegato):

Se riduci il registro, aumenterà di nuovo, probabilmente causando la frammentazione VLF e definitivamente facendo sospendere il carico di lavoro mentre il registro cresce, poiché il registro non può utilizzare l'inizializzazione istantanea [. ..]

Aggiornamento: Non confondere il troncamento del file LOG per la riduzione del file DATA. La riduzione del file DATA è davvero negativa. Vedi Perché non dovresti ridurre i tuoi file di dati per i dettagli.

26
MicSim

OK prima di tutto sì, il registro è necessario anche con i backup completi giornalieri se si desidera ripristinare in caso di problemi. Effettuiamo il backup del nostro log delle transazioni ogni 15 minuti. Il problema è che non si esegue il backup del registro delle transazioni ed è per questo che il registro cresce in modo così scandaloso. Non è quasi mai necessario ridurre un registro delle transazioni se si eseguono backup del log delle transazioni corretti.

Sarà necessario eseguire il backup del database prima di troncare il registro. Suggerisco di farlo nelle ore di chiusura, quindi non vengono inseriti nuovi dati tra il backup e il troncamento. Quindi impostare i backup del registro delle transazioni appropriati in modo da non avere più questo problema.

Per quanto riguarda le prestazioni, senza conoscere i dettagli dell'hardware e dell'utilizzo del sistema, sarebbe difficile dirlo.

6
HLGEM

Quanto velocemente cresce il registro delle transazioni? Se è piuttosto rapido, influenzerai le prestazioni riducendole quasi a zero, poiché deve impiegare del tempo per ricrescere. Questo non significa che non dovresti ridurlo di tanto in tanto, ma devi pensare al problema delle dimensioni piuttosto che ridurlo al minimo. Il colpo perfetto è enorme? Probabilmente no, ma dipende dal carico sul server (numero di transazioni, ecc.).

Una cosa che trovo problematica è "Eseguo 2 backup completi ogni giorno, quindi il registro non dovrebbe essere realmente necessario per quanto riguarda il roll-forward dei dati". Il registro è estremamente importante per i punti tra i backup completi. Anche due volte al giorno non elimina la necessità di un file di registro per il ripristino di emergenza, a meno che non si tratti di un database di sola lettura (se lo fosse, non vedresti l'enorme aumento del file di registro).

4
Gregory A Beamer