Buna ziua,

Daniel din Bucuresti, primul post pe forum, bine vam gasit!

 Sunt DBA incepator la o firma cu profil comert, server SQL2000, baza de date de productie are 8giga in doar 6luni. 100+ useri concurenti.

Am un plan de backup: de 2ori pe zi la ora 2AM si 2PM full db backup, si din ora in ora transaction log backup. In mod normal fisierul .BAK (full db backup) are 8GB, si tranlogul are in timpul zilei 300MB, noaptea nu se lucreaza, are doar 4MB sa zicem.

Intrebarile sunt:

1. Din cand in cand, fisierul .BAK rezultat la full db backup este foarte mare, dublu decat in mod normal, adica vreo 16GB, si fisierul .TRN (tran log-ul) de la aceiasi ora cu .BAK-ul cel mare) e la fel foarte mare, de gen 8GB.  De ce se intampla acest lucru?

2. Vreau sa schimb modelul de recovery din full in simple, si sa schimb  modul de backup, in un full db backup la 2AM si differential backup din ora in ora. Credeti ca e OK asa? Eu urmaresc un plus de performanta pe server, care in timpul zilei, in orele de varf cand operatorii introduc facturile de vanzare/achizitie, se misca mai greu.

Multumesc,

spor la treaba si have fun!

1. Pentru cauzele cresterii log-ului:

http://support.microsoft.com/kb/317375/

2. Nu stiu daca este OK - alegerea unui "maintenance plan" depinde de activitatea departamentului si de "business rules". De exemplu, in ce masura iti poti permite pierderi de date (---> cat de critice sunt datele introduse), ce volum de date se introduce zilnic / pe ora...,  care ar fi  "downtime" - ul  pe care ti-l poti acorda daca se intampla "necazul",  este nevoie de "restore at a point in time", etc...vezi si Books Online--->Administering SQL Server ---> Designing a Backup and Restore Strategy

Pentru problemele de performanta, este bine sa revezi structura bazei de date - tabele, indecsi - si sa folosesti profiler-ul si "database tuning wizard" (sper ca nu gresesc numele...).

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
 

Multumesc de raspunsuri in primul rand.

 M-am uitat acum la un job de reindexare ce ruleaza vineri si duminica noaptea la ora 1Am si se termina la 1:30AM si mi-am dat seama ca din cauza lui se intampla problema cu fisierul .BAK ce se dubleaza ca dimensiune+ TRN-ul f mare, deci Razvan u were right :) Totusi cred ca nu e normal sa se intample ce se intampla.. o sa mai citesc pe net de problema asta, daca aveti voi un link cu detalii va rog sa il postati.

 Din cate vad, nu am alta solutie decat Full recovery model, Diff backups sunt ok dar din cauza ca sunt multe inserturi/updateuri fisierul diff o sa fie mare si nu rezolv nimic practic.

Multumesc,

Dani 

la ce s-a spus pana acum adauga urmatoarele:

1. o baza de date in care se introduc multe date ar trebui sa contina cati mai putini indecsi.

2. nu iti recomand sub nici o forma recovery cu simple