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 l' TRUNCATE_ONLYopzione, ma questo 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

Ciò tronca completamente il file di registro, ma la mia domanda è: 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.

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 eseguire la gestione dei log 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 quando il file LOG deve essere aumentato (una citazione dal post di blog sopra collegato):

Se riduci il registro, aumenterà di nuovo, causando probabilmente la frammentazione di VLF e causando sicuramente la sospensione del 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 dei file DATA è davvero negativa. Vedi Perché non dovresti ridurre i tuoi file di dati per i dettagli.

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.

Quanto velocemente cresce il registro delle transazioni? Se è piuttosto rapido, influenzerai le prestazioni riducendole quasi a zero, in quanto deve impiegare del tempo per farle 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).