Răspunsuri:
1. Necunoscând detaliile aplicaţiei (dacă cumva se întâmplă recalculări pe perioade mai mari, de exemplu), aş zice că fişierele mai mari pot fi cauzate de o reindexare a tuturor tabelelor din baza de date. O altă chestiune ar fi: cât durează backup-ul full ? Eu cred că durează vreo 10-20 min, nu-i aşa? Nu ştiu ce se întâmplă dacă se face un backup de transaction log în timp ce se face unul full... s-ar putea să fie şi asta o cauză a dimensiunilor mai mari.
2. Nu cred că e o idee bună să treci pe Recovery Model Simple. A fost recent o discuţie pe grupul microsoft.public.sqlserver.programming de unde se poate trage concluzia că recovery model-ul Full este foarte folositor în caz că vrei să recuperezi date modificate/şterse eronat din cauza unei erori umane. Problema cu recovery model-ul simple ar fi că nu poţi să recuperezi tabela afectată decât în forma în care era la momentul când ai făcut backup-ul full.
Exemplu: Să zicem că faci backup-uri full din oră în oră, iar utilizatorii introduc în continuu date în tabela Facturi (la fiecare minut câte una). Să zicem că la ora 10:35 faci un UPDATE Facturi SET Valoare=0 şi uiţi să pui WHERE-ul. La ora 10:40 îţi dai seama de greşeală.
a) Dacă eşti pe Simple Recovery Model, atunci restaurezi backup-ul full de la 10:00 în altă bază de date şi faci un UPDATE Facturi SET Valoare=f.Valoare FROM Facturi INNER JOIN AltaBaza..Facturi f ON Facturi.ID=f.ID, dar ai pierdut cele 35 de facturi introduse de la 10:00 până la 10:35
b) Dacă eşti pe Full Recovery Model, atunci faci acum un backup de transaction log, apoi restaurezi în altă bază de date backup-ul full din noaptea anterioară şi fiecare backup de transaction log, inclusiv cel de acum, dar la ultimul îi spui cu STOPAT să se oprească la 10:34. Faci UPDATE-ul de mai sus şi nu ai pierdut nimic.
Sugestie:
Eu aş zice să faci backup-urile full mai rar: doar odată pe zi, noaptea, e suficient. Poate ar fi util să păstrezi pe DVD câte un backup full la fiecare două săptămâni. Eventual, poţi să faci backup-urile de transaction log mai des, dar doar în timpul programului normal (de la 8 dimineaţa la 8 seara să zicem şi doar în timpul săptămânii) şi să le păstrezi doar timp de o lună. Dacă le faci la fiecare sfert de oră în loc să le faci la fiecare oră atunci dimensiunea fiecăruia ar trebui să scadă la vreo 80M în loc de 300M.
Fac o mică paranteză: backup-urile differential conţin toate paginile de date modificate de la ultimul full, deci dimensiunea differential-urilor creşte în fiecare zi până seara, iar dimineaţa o ia de la început; backup-urile de transaction log conţin fiecare modificare (deci pagini de log) de la backup-ul anterior de transaction log; deci dimensiunea unui singur backup de transaction log ar putea fi mai mare decât dimensiunea unui singur backup diferential (să zicem, dacă faci un full în fiecare noapte şi un diferential sau un log la fiecare prânz), dar dimensiunea tuturor log-urilor probabil ar fi mai mică decât cea a tuturor diferenţialurilor (să zicem, dacă faci un full în fiecare noapte şi un diferenţial sau un log la fiecare oră).
În concluzie, backup-urile de transaction log mai dese ar avea ca avantaj că încarcă server-ul mai puţin timp (de exemplu, 10 sec la fiecare sfert de oră, în loc de 30 sec la fiecare oră), dar mai ales că dacă ai o cădere hardware catastrofală (moare de tot hard disc-ul server-ului) atunci pierzi maxim un sfert de oră în loc să pierzi maxim o oră.
Răzvan