Transaction log is full
Deja nu îmi plăcea cum sună acest tichet. M-am uitat peste site-ul clientului să aflu ce imi raportează. Șiam că site-ul rula într-un mediu shared hosting, pe Windows 2008 R2, cu SQL Server 2008 R2 și că partenerii noștri pe hosting au anumite limite, pe care le înțelegem, respectăm și mai mult, le apreciem. Majoritatea host-urilor nu oferă nici jumătate din ceea ce ne oferă aceștia. În plus lucrăm de mulți ani cu ei și vă putem spune că servicii mai bune decât la ei nu am întâlnit încă. Să nu mai menționez că raportul preț-performanță este optim! În momentul în care un log al tranzacțiilor SQL este plin, mai rămân doar puține opțiuni, dacă site-ul rulează într-un mediu shared. Deși, uneori, la cerere, host-ul modifică dimensiunea log-ului, uneori creșterea acestuia poate reprezenta o problemă care necesită analiză. În cazul nostru știam care este problema – aplicația desktop pe care o utilizează clientul pentru menținerea la zi a bazei de date este foarte „chatty” cu serverul SQL la care se conectează direct.Soluții
În mod normal, când apare o astfel de problemă, preferi să salvezi log-ul, să faci un back-ul al bazei de date sau ceva similar. Din păcate un log plin nu mai permite efectuarea niciunei modificări. Nici măcar un back-up al bazei de date prin intermediul Management Studio sau a WebsitePanel. Puteți încerca, după un back-up, să trunchiați log-urile cu o comandă de genul:1: use bazadedate
2: 3: backup log bazadedate
4: with truncate_only
5: 6: dbcc shrinkfile (bazadedate _log, 1)
Ce ne rămâne atunci de făcut?
Deoarece știam că pe clientul nostru îl interesează doar conținutul tabelelor din baza de date, nu și log-urile și deoarece știam că logurile sunt realizate de discuțiile „aprinse” dintre aplicația desktop și server, am salvat local o copie a tuturor tabelelor din baza de date, pe care clientul le utiliza. Din SQL Server Management Studio puteți exporta sau importa date din baza de date Microsoft SQL Server. Acest lucru se aplică și atunci când doriți să migrați baze de date de la versiuni superioare la versiuni inferioare (ex.: 2008 R2 la 2008, sau 2008 la 2005), deoarece sunt păstrate doar tabelele din baza de date, cele care conțin datele cu care rulează un site fără prea multe pretenții. Totuși pot apărea și aici abateri de la regulă. Rulând un server SQL 2008 R2 pe mașina de development, am făcut un back-up local prin exportarea datelor din baza de date de pe server.
În câțiva pași, urmând wizard-ul, am ajuns la lista tabelelor pe care doream să le salvez. Înainte de a salva aceste tabele local, pentru a nu altera baza de date a clientului, am avut grijă să șterg tot conținutul acelei baze de date în care am facut back-up-ul.
În cazul în care adăugați conținul exportat prin acest wizard, acesta va face merge cu rândurile existente din baza de date, astfel, în funcție de regulile stabilite, pot apărea probleme de exportare a datelor sau de funcționalitate a aplicației, dacă doar acolo se face verificarea. Este cel mai bine să vă asigurați că back-up-ul se va face „pe curat”.
Am ales apoi tabelele care vor fi create local cu conținutul celor de pe server și am finalizat wizard-ul.
Acum aveam pe HDD o imagine a conținutului important al site-ului.
Am șters baza de date care avea log-urile imense și am recreat-o, având grijă să păstrez username-ul și parola din motive de… necomplicații.
După acestea, pe o bază de date nouă și curată, am început procesul invers, cel de Import Data…
După urmarea pașilor wizard-ului, fiind atent la ordinea bazelor de date – ce exportă în ce, am finalizat importarea tabelelor și a datelor din acestea.
Acum aveam o bază de date fără log-uri mari, fără să mă încurce sau să creeze orice fel de probleme în utilizarea site-ului sau a clienților software pentru desktop.
Am verificat pe site și totul revenise la normal.
Deci, cea mai bună metodă în acest caz este un back-up local, refacerea bazei de date și importarea datelor în aceasta.
Numai bine,
