Home > Transaction Log Reuse and Transactional Replication

Transaction Log Reuse and Transactional Replication

Recentemente, ho avuto l’occasione di dare assistenza, su SQL Server, a un cliente che mi ha segnalato errori applicativi di diverso tipo, ma il più frequente era "Errore in scrittura sulla tabella ‘nome_tabella’".

Dopo aver verificato il recovery model del DB su cui si basa l’applicativo, che era impostato su SIMPLE, ho verificato lo spazio libero sulle unità che contengono i file del database e la presenza di transazioni attive. Lo spazio libero sull’unità che contiene i file del DB era insufficiente per salvare altri dati a causa delle dimensioni del transaction log, arrivato a occupare circa 29GB a fronte di un file dati (modesto) di circa 400MB. Il T-Log aveva saturato lo spazio sull’unità disco che lo ospitava e i backup del database erano ovviamente cresciuti di conseguenza.

Per quale motivo il transaction log era cresciuto tanto? E perché SQL Server non era in grado di rilasciarlo? Anche forzando il rilascio con un’operazione di Shrink?

Ho utilizzato la vista sys2.logs_usage, il cui script è disponibile per il download dal sito di CodePlex, per conoscere il motivo che impediva a SQL Server di troncare il file di log per liberare spazio e consentirne il riutilizzo.

Il motivo è descritto nella colonna log_reuse_wait_desc che sulla riga relativa al DB incriminato riportava il valore "REPLICATION"… ho scoperto che il database in questione pubblicava, attraverso una replica transazionale, alcune tabelle. Questo valore, quando il DB è interessato in una replica transazionale, indica la presenza di transazioni avvenute nel database di pubblicazione, ma non ancora distribuite nei sottoscrittori dal distributore, da qui l’impossibilità di compattare il transaction log.

Alcuni agenti di replica erano, infatti, in errore con il messaggio: "L’utente [dominio\utente] non ha accesso al server ‘nome_server’".

Dopo aver corretto l’anomalia sugli agenti di replica, il distributore ha potuto aggiornare i sottoscrittori e in seguito l’enorme spazio impegnato dal transaction log è stato rilasciato per consentirne il riutilizzo.

Articoli correlati:

Chi è Sergio Govoni

Sergio Govoni è laureato in Scienze e Tecnologie Informatiche. Da oltre 16 anni lavora presso una software house che produce un noto sistema ERP, distribuito a livello nazionale ed internazionale, multi azienda client/server su piattaforma Win32. Attualmente si occupa di progettazione e analisi funzionale, coordina un team di sviluppo ed è responsabile tecnico di prodotto. Lavora con SQL Server dalla versione 7.0 e si è occupato d'implementazione e manutenzione di database relazionali in ambito gestionale, ottimizzazione delle prestazioni e problem solving. Nello staff di UGISS si dedica alla formazione e alla divulgazione in ambito SQL Server e tecnologie a esso collegate, scrivendo articoli e partecipando come speaker ai workshop e alle iniziative del primo e più importante User Group Italiano sulla tecnologia SQL Server. Ha conseguito la certificazione MCP, MCTS SQL Server. Per il suo contributo nelle comunità tecniche e per la condivisione della propria esperienza con altri, dal 2010 riceve il riconoscimento SQL Server MVP (Microsoft Most Valuable Professional). Nel corso dell'anno 2011 ha contribuito alla scrittura del libro SQL Server MVP Deep Dives Volume 2 (http://www.manning.com/delaney/).

Leggi Anche

Azure Key Vault e certificati code-signing: Strategie per la conformità post 1° Giugno 2023!

In questi giorni, ho avuto l’opportunità di esplorare il rinnovo di un certificato di code-signing …