Tanto tempo fa un informatico di ottima razza mi prese sotto la sua ala e mi fece da mentore nel mondo dell’IT. Erano ancora i tempi in cui i mainframes la facevano da padrone. Mi imbattei nella teoria dei database relazionali quando ancora non erano in commercio e facevano pure una pessima impressione in quanto a prestazioni...ma erano ancora in fase di concepimento...e trasudavano il fascino del “futuro prossimo venturo”... Con l’affacciarsi di Microsoft sul mercato fui affascinato dalle opportunità che si potevano intravedere, e con l’arrivo di SQL Server compresi finalmente qual era la mia strada. La sto ancora percorrendo, e nello zaino da escursionista di cui mi sono dotato ho collocato anche SharePoint, un viatico essenziale per il mio lungo viaggio. Unico rimpianto: abbandonai l’Università per la passione un pò incosciente per questo lavoro; la cosa più curiosa è che da allora non ho mai smesso di studiare...
Ogni database in una istanza di SQL Server dispone di almeno un file di dati, eventualmente di ulteriori files di dati e ineludibilmente di un file denominato "Transaction log". Lo scopo dei files di dati è spiegato dalla stessa definizione (conterranno i dati...). Ma il Transaction Log è fondamentale per consentire un ripristino consistente del database in caso di errore e corruzione. Questa sessione spiega alcuni tra gli aspetti meno noti di questo componente e alcune tra le best practices adottabili per mantenerlo al massimo livello di efficenza