SQL Server 2005 creștere automată în funcție de dimensiune

M-am uitat la noul server de baze de date pe care îl configuram pentru un client și notăm că fișierele bazei de date sunt setate să crească cu 1 meg fiecare dată când fișierul este plin, iar dimensiunea inițială este de 100 MB.

M-am gândit la acest lucru minuțios și nu sună bine. Am verificat câteva site-uri pe considerente DB și nu au explicat corect aceste valori.

Probabil aș vrea doar ca fișierele bazei de date să se extindă o dată pe lună, să spunem?

Deci, dacă aș calcula cantitatea de date pe care o aștept să fie introdusă pe zi în megaocteți și doar să se înmulțească cu 30, ar trebui să găsesc o cifră adecvată?

i.e. I do know approximately the size of 1 row and approx how many rows will be inserted in an average week per table. I know these are estimates from the ground up so you think once a month is a suitable approximation for the file to extend or is it preferable to extend every hour>? or never?

Folosim întoarcerea completă pentru a ne putea recupera până la un moment dat, iar backup-urile din tranzacțiile de tranzacționare se întâmplă și procedura de recuperare pare să fie 100% eficientă. Aceste tipuri de modificări duc la impactul de backup și recuperare în orice mod?

Mulțumiri.

3

6 răspunsuri

Ceea ce ați sugerat este destul de mult la fața locului. Vrei ca autogrowth-ul să se bazeze pe ceea ce aștepți să vezi.

O bază de date care are autogrowth de 1MB ori de câte ori este plină va experimenta probleme de performanță uriașe, deoarece de fiecare dată când baza de date este plină, orice tranzacție este în desfășurare va trebui să pauză până când a crescut.

Încerc să găsesc un articol pe care l-am citit mai devreme despre subiect, așa că atunci când îl găsesc, voi adăuga un link ...

EDIT: http: //searchsqlserver.techtarget.com/tip/0,289483,sid87_gci1330922,00.html Articolul este despre scăderea bazei dvs. de date, dar detaliază ce se întâmplă atunci când o bază de date crește automat și arată impactul de performanță pe care îl poate avea.

Cu siguranță nu doriți ca baza dvs. de date să crească atât de des cât ar fi la 1Mb un pop!

3
adăugat

În opinia mea, NU aș fi stabilit o bază de date să crească în procente, mai degrabă să crească baza de date pentru o săptămână la 100 MB și apoi să schimbați ritmul creșterii la o săptămână în creștere, să zicem 5 GB. Avem sisteme pe care le-am făcut pentru asta.

În caz contrar, puteți obține informații tehnice și să vedeți câte înregistrări sunt adăugate în sistem în fiecare săptămână, să țineți cont de înregistrările care sunt arhivate sau șterse, apoi să calculați spațiul necesar pentru fiecare înregistrare și să setați autogrowth-ul pe baza acelor vremuri numărul de înregistrări.

Motivul pentru care aș duce o persoană departe de creșterea procentuală este că atunci când sistemul este de 1000 MB, acesta va crește cu 100 MB. Apoi, data viitoare, sistemul este de 1100 MB și îmi va crește 110 MB. Dimensiunea va fi apoi 1210, iar baza de date va crește la 121 MB. Apoi dimensiunea va fi de 1331, iar creșterea va fi de 133 MB. Cu această creștere neuniformă, va fi foarte dificil să calculați cât spațiu de disc a rămas și când trebuie să redimensionați setarea maximă.

Doar 2 cenți.

De asemenea, creșterea implicită menționată mai sus este stabilită în baza de date MODEL. Setarea setărilor bazei de date MODEL atunci când creați o nouă bază de date este ceea ce este implicit în noua dvs. bază de date.

2
adăugat

De fiecare dată când fișierul de date trebuie să crească, acesta necesită o anumită cantitate de resurse, deoarece captează spațiul suplimentar pe disc și extinde fișierul de date. Deci, în mod ideal, doriți să limitați numărul de creșteri.

Personal, încerc să mă asigur că bazele mele de date nu trebuie să crească deloc. Încerc să le cresc proactiv în timpul orelor libere. Acest lucru mă permite, de asemenea, să monitorizez spațiul pe disc mai bine, deoarece nu se poate "auto-dezvolta" cu ușurință;)

Dacă acestea cresc automat o dată pe lună, ar trebui să fie bine. Fiecare minut și veți vedea probabil un impact de performanță.

În afară de capacitatea de rezervă care poate necesita mai mult spațiu și umplerea locației dvs. de rezervă, nu mă pot gândi la nici un motiv că ar cauza o problemă în procesul de copiere de rezervă. Sunt mai mult un dezvoltator SQL decât un DBA, deci nu pot să jur.

0
adăugat

În afară de spațiul alocat redundant, există puțin sau deloc dezavantajul unei creșteri de mărime mare. Stabilirea incrementului la o dimensiune care îi va determina să crească în fiecare lună sau câteva luni este corectă.

În orice caz, ar trebui să aveți o slujbă obișnuită care să monitorizeze spațiul liber pe ambele volume ale discurilor și în cadrul fișierelor și să producă un raport, astfel încât să puteți vedea lipsuri imediate ale discurilor.

0
adăugat

În general, sunteți în regulă cu privire la încercarea de a minimiza numărul de momente în care baza dvs. de date trebuie să crească.

Nu am putut să vă dau valori exacte, dar este întotdeauna mai bine ca dimensiunea fișierului bazei de date să fie atât de mare încât nu trebuie decât să o crească ocazional și apoi trebuie să crească considerabil, astfel încât să nu aveți frecvente modificări ale dimensiunii fișierului.

0
adăugat

Tocmai am verificat SQL Server Management Studio 2008, iar creșterea implicită atunci când creați o bază de date nouă este de 1MB ... probabil că a venit de la setarea dvs. de 1MB (Pariez că a fost aceeași în 2005).

Îmi amintesc că am citit cu mult timp în urmă că s-ar putea lua în considerare stabilirea fișierului bazei de date să se dubleze de fiecare dată când este necesar să crească. Acum, dacă ați avea o bază de date de 5TB, probabil că nu doriți să se dubleze doar o zi, însă pentru o bază de date cu o dimensiune de 1GB este probabil că este minunată dacă se dublează atunci când este necesar (ați avea o rată de creștere a evenimentelor de creștere dacă au o rată constantă de introducere a datelor).

Doar am vrut să prezint ceea ce cred că ar putea fi o strategie viabilă, în funcție de circumstanțele dvs., bineînțeles.

0
adăugat