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.
