Riduzione di un registro delle transazioni di SQL Server

Al momento ho a che fare con un registro delle transazioni di SQL Server fuori controllo. Disclaimer: non sono un dba e questa non è la mia area di competenza, quindi per favore abbi pazienza con me.

Al momento ho un file di registro delle transazioni da 115 GB per un database da 500 MB che è stato (ovviamente) mal gestito da un po 'di tempo per arrivare in questo stato.

La massima priorità è recuperare lo spazio sul disco occupato da questo file prima che finiamo! Mi è stato detto che aumentare le dimensioni dell'unità non è un'opzione, nemmeno temporanea, e in base alla crescita passata, dobbiamo agire abbastanza presto.

A quanto ho capito, l'approccio migliore è mantenere il db in modalità di ripristino completo ma eseguire backup regolari del file di registro, monitorarlo per un periodo di tempo e regolare le dimensioni iniziali e l'incremento in base alle esigenze. Tutto ok.

Visto che eseguiamo regolarmente i backup completi del db a mezzanotte, sarebbe sicuro per me mettere temporaneamente il database in modalità di ripristino semplice (dopo l'esecuzione di uno di questi backup), ridurre il file di registro per recuperare (praticamente tutto) lo spazio e quindi reinserirlo in Full Recovery con la strategia di backup sopra menzionata?

Il mio pensiero è che se qualcosa accadesse in questo periodo, potremmo semplicemente ripristinare il backup completo senza usare i registri.

AGGIORNARE

Alcuni dettagli extra in risposta ad alcune delle risposte e dei commenti:

• Vogliamo mantenere la possibilità di eseguire un ripristino temporizzato in modo che il database rimanga in modalità di ripristino completo.

• Il motivo per cui il file t-log è diventato così grande è che non è mai stato eseguito il backup . Verificato come log_reuse_wait_desc restituisce 'LOG_BACKUP'.

Il registro delle transazioni per quel database contiene tutte le transazioni dall'ultimo backup del registro delle transazioni o l'ultima volta che è stato cambiato dalla modalità di recupero semplice. Eseguire quanto segue per ottenere la risposta definitiva sul motivo per cui SQL Server non è in grado di troncare il registro e successivamente perché il registro sta crescendo.

SELECT  d.Name
        ,d.log_reuse_wait_desc
FROM    sys.databases d
ORDER BY
        d.name

Se si desidera il ripristino temporizzato, lasciare il DB nel modello di recupero completo e eseguire backup di log frequenti. Ogni backup del registro conterrà tutte le transazioni dall'ultimo backup del registro. Il processo di backup del registro è anche responsabile della cancellazione del registro e della marcatura dello spazio per il riutilizzo, vale a dire che la successiva transazione effettuata nel DB verrà scritta all'inizio del registro troncato in modo circolare. Questo backup e riutilizzo del registro è ciò che impedisce la crescita del file di registro.

Se non si è interessati al recupero temporizzato e si desidera semplificare l'amministrazione del database. Quindi impostare il database sul modello di recupero semplice e non eseguire backup t-log. SQL Server troncherà automaticamente il registro delle transazioni dopo il commit di ogni transazione. Ciò significa che una volta che la transazione è stata impegnata nel registro, il record viene sovrascritto dalla transazione successiva, ecc.

Ad ogni modo, una volta che hai preso una di queste due decisioni, puoi ridurre il file di registro a una dimensione più ragionevole. Nota idealmente che vuoi renderlo abbastanza grande in modo che non cresca ma non così grande che dovrai ridurlo di nuovo. Si noti inoltre che non è possibile ridurre la parte attiva del registro.

Scarica e distribuisci https://ola.hallengren.com/ soluzione di amministrazione del database per coprire backup, frammentazione dell'indice, statistiche e CHECKDB.

È inoltre possibile trovare il report "Utilizzo del disco" restituito facendo clic con il pulsante destro del mouse su DB in Esplora oggetti> Rapporti> Rapporti standard> "Utilizzo del disco" utile per restituire lo spazio libero nel registro t.

Ti consiglio anche a Google perché è così importante mantenere intatta la catena di tronchi da un punto di vista del DR e come il passaggio da completo a semplice interrompe la catena lasciandoti esposto alla perdita di dati.

Visto che eseguiamo regolarmente i backup completi del db a mezzanotte, sarebbe sicuro per me mettere temporaneamente il database in modalità di ripristino semplice (dopo l'esecuzione di uno di questi backup), ridurre il file di registro per recuperare (praticamente tutto) lo spazio e quindi reinserirlo in Full Recovery con la strategia di backup sopra menzionata?

Sì, sarebbe sicuro a condizione che tu non interferisca con nessuna transazione quando lo fai, come un carico a tarda notte. In generale, se un database deve essere in modalità di ripristino completo, si desidera eseguire regolarmente backup di T-Log. Ciò ridurrà il problema che stai affrontando. Scrivo "in generale" perché in alcuni casi ho visto persone impostare un database pieno senza sapere perché l'hanno fatto. Supponiamo che non sia così.

Tuttavia, è possibile considerare il motivo per cui il registro ha questa dimensione rispetto alla dimensione del database. Un database da 500 MB con un registro da 116 GB sembra molto sproporzionato per un evento singolo. Suggerirei di monitorare ciò che sta accadendo nel database per vedere come è arrivato a quella dimensione in primo luogo.