Impostare manualmente la dimensione del file di registro dopo aver ridotto SQL Server 2008 R2

Sto diventando un DBA alquanto involontario al lavoro al momento attuale e ho davvero bisogno di aiuto su qualcosa.

Abbiamo un database da 40 GB in modalità di recupero completo, nessun backup del registro configurato e un enorme file di registro di 84 GB. Il mio piano finora per salvare questa situazione è quello di eseguire un backup completo del registro sul database, ridurre il file di registro e istigare un piano di manutenzione per eseguire un backup del registro ogni notte con il backup del database per tenerlo sotto controllo.

Il mio problema è che non voglio che il file di registro si riduca a nulla e passi la prima mattina di lunedì in costante crescita. Ho una stima approssimativa di come dovrebbe essere il file (circa il 20% del database) e vorrei impostarlo fin dall'inizio per garantire quanto più spazio contiguo possibile. È solo un caso di modifica della "Dimensione iniziale" in Proprietà database -> File? Immagino anche che il database dovrebbe essere offline per questo?

Grazie in anticipo

Riduci a quello che pensi sia la dimensione ottimale. Non utilizzare l'interfaccia utente, fai solo questo: supponiamo che 200 MB siano le dimensioni ottimali:

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

Se sei interessato a eseguire un backup del registro solo una volta al giorno e non sei interessato al recupero temporizzato, devi passare al modello di recupero semplice. Ciò significa che i backup del registro non sono necessari (in realtà impossibile) ma i contenuti del registro si autogestiscono.

Se si desidera che i backup del log siano significativi, non pianificare di eseguire un backup completo durante la notte e quindi un backup del log singolo subito dopo. Questo ti mantiene nel modello di recupero completo, rende il registro molto duro e non ti compra nulla. Pertanto, se si desidera il ripristino temporizzato, eseguire i backup dei log più frequentemente a una velocità che soddisfi la tolleranza della perdita di dati. Se non vuoi mai perdere più di 15 minuti di dati, esegui un backup del registro ogni 15 minuti.

La gestione dei file può essere un'operazione completamente online. Esistono due percorsi, a seconda della necessità di conservare le informazioni del registro a fini di recupero:

Ripristino temporizzato non necessario

1. Converti il ​​database in SIMPLErecupero. Eseguire un checkpoint per scrivere le transazioni sul disco.
2. Appiattire il registro.
3. Ridimensionare il registro alla dimensione appropriata.

Consiglio anche di impostare un importo di crescita fisso e crescita illimitata (in modo da aiutare a gestire meglio il tuo registro). Nota, la quantità di crescita fissa è molto e dipende dalla quantità, inizialmente raccomanderei di andare con 1-2 GB a seconda della crescita che il log potrebbe aspettarsi di vedere. Idealmente, il tuo registro non crescerà molto, quindi questo non dovrebbe avere un grande impatto. Se il registro cresce regolarmente, potrebbe essere necessario rivisitare le dimensioni.

Compiuto utilizzando:

ALTER DATABASE [foo] 
SET RECOVERY SIMPLE;

CHECKPOINT;

DBCC SHRINKFILE (foo_log,0);

ALTER DATABASE [foo]
MODIFY FILE (NAME=foo_log,SIZE=8000MB,MAXSIZE=UNLIMITED,FILEGROWTH=1000MB);

--Optional if you want the database in full recovery mode 
--for point in time recovery going forward
ALTER DATABASE [foo] 
SET RECOVERY FULL;

Necessario recupero temporizzato

Il problema principale sarà che non è possibile ridurre il file di registro oltre il segmento VLF attualmente attivo. Per vedere questo, è possibile utilizzare DBCC LOGINFOnel contesto del database. Qualsiasi segmento con uno stato = 2 è attivo. Per cancellare i segmenti attivi, sarà necessario eseguire un backup del registro delle transazioni quando al momento non sono attive transazioni in quel segmento. I tuoi passi sono:

1. Eseguire un backup del registro delle transazioni.
2. Riduci il tuo file. (Idealmente appiattire, ma se il database è attivo questo sarà difficile da fare).
3. Ripetere i passaggi 1 e 2 fino a quando il registro non ha le dimensioni appropriate, idealmente il più piccolo possibile.
4. Ridimensionare il registro alla dimensione appropriata.

Compiuto utilizzando:

BACKUP LOG [foo] TO DISK='<Location of t-log backup>';

DBCC SHRINKFILE (foo_log,0);

--Repeat the above until your log file is small "enough"

ALTER DATABASE [foo]
MODIFY FILE (NAME=foo_log,SIZE=8000MB,MAXSIZE=UNLIMITED,FILEGROWTH=1000MB);

Alcune risorse aggiuntive per capire cosa sta succedendo qui:

• Modelli di recupero di SQL Server

• Le raccomandazioni t-log di Kimberly Tripp

• Checkpoint del database

In realtà no, non è necessario che il database sia offline per ridurre il registro. E dirò che questo è probabilmente uno dei pochi casi in cui ridurre il registro è una buona idea. È possibile impostare la dimensione iniziale, ma sarebbe più semplice eseguire la riduzione e dire che si riduce a una dimensione specifica.

USE [DBName]
GO
DBCC SHRINKFILE (N'LogName' , SizeInMg)
GO

Puoi anche farlo utilizzando la GUI e utilizzando il secondo pulsante di opzione e la casella di controllo che indica la dimensione del registro alla fine. È possibile accedere alla GUI facendo clic con il pulsante destro del mouse sul database in Esplora oggetti in SSMS, selezionando attività, riduci, file.

In aggiunta alla risposta di Aaron sulla modalità semplice , è possibile pianificare 2 (o più) backup differenziali al giorno, riducendo in tal modo la finestra di perdita di dati del funzionamento del database mantenendo la modalità SEMPLICE.