Architettura fisica del log delle transazioni
Il log delle transazioni viene utilizzato per garantire l'integrità dei dati del database e per il recupero dei dati. Negli argomenti di questa sezione vengono fornite informazioni sull'architettura fisica del log delle transazioni. Tali informazioni consentono di gestire più efficacemente i log delle transazioni.
Il log delle transazioni di un database viene mappato su uno o più file fisici. Concettualmente, il file di log è una stringa di record di log. Fisicamente, la sequenza di record di log viene archiviata in modo efficiente nel set di file fisici che implementano il log delle transazioni.
In Motore di database di SQL Server ogni file di log fisico viene diviso internamente in diversi file di log virtuali. I file di log virtuali non hanno dimensioni fisse e non è previsto un numero fisso di file di log virtuali per un file di log fisico. Il Motore di database definisce dinamicamente le dimensioni dei file di log virtuali durante la creazione o l'estensione. Il Motore di database tende a mantenere ridotto il numero di file virtuali. Le dimensioni dei file virtuali dopo l'estensione di un file di log corrispondono alla somma delle dimensioni del log esistente e del nuovo incremento del file. Le dimensioni o il numero di file di log virtuali non possono essere configurati o impostati dagli amministratori.
I file di log virtuali influenzano le prestazioni del sistema solo quando per le relative opzioni size e growth_increment vengono definiti valori bassi. Se tali file di log assumono dimensioni considerevoli in seguito a una serie di piccoli incrementi, includeranno un numero elevato di file di log virtuali. Questo potrebbe provocare un rallentamento delle operazioni di avvio del database e di backup e ripristino del log. È consigliabile assegnare ai file di log un valore size simile a quello delle dimensioni finali necessarie e un valore growth_increment relativamente alto.
Il log delle transazioni è un file circolare. Si consideri, ad esempio, un database con un file di log fisico diviso in quattro file di log virtuali. Quando viene creato il database, il file di log logico comincia all'inizio del file di log fisico. Vengono aggiunti nuovi record di log alla fine del log logico, che si espandono verso la fine del log fisico. Il troncamento del log libera tutti i log virtuali i cui record vengono visualizzati tutti davanti al numero minimo di sequenza del file di log (MinLSN, Minimun Log Sequence Number) per il recupero. MinLSN è il numero di sequenza del file di log del record di log meno recente necessario per un corretto rollback a livello di database. Il log delle transazioni del database di esempio sarebbe simile a quello illustrato nella figura seguente.
.gif "File di log diviso in quattro file di log virtuali")
Quando la fine del log logico raggiunge la fine del file di log fisico, i nuovi record di log vengono nuovamente inseriti a partire dall'inizio del file di log fisico.
.gif "I record del log vengono riportati all'inizio del file di log")
Questo ciclo viene ripetuto all'infinito, a condizione che la fine del log logico non raggiunga mai l'inizio del log stesso. Se i vecchi record di log vengono troncati abbastanza frequentemente in modo da lasciare sempre spazio sufficiente per i nuovi record di log creati fino al checkpoint successivo, il log non viene mai riempito completamente. Se, tuttavia, la fine del log logico raggiunge l'inizio del log stesso, può verificarsi uno dei due eventi indicati di seguito:
Se è attiva l'impostazione FILEGROWTH per il log e sul disco vi è spazio disponibile, il file viene esteso in base al valore specificato in growth_increment e i nuovi record di log vengono aggiunti all'estensione. Per ulteriori informazioni sull'impostazione FILEGROWTH, vedere ALTER DATABASE (Transact-SQL).
Se l'impostazione FILEGROWTH non è attiva oppure se lo spazio libero sul disco in cui risiede il file di log è inferiore a quello specificato in growth_increment, viene generato un errore 9002.
Se il log include più file di log fisici, il log logico utilizzerà tutti i file di log fisici prima di tornare all'inizio del primo file di log fisico.