[ MatezYU @ 14.05.2009. 08:32 ] @
Imam tabelu koja je ogromna. Ona se puni svaki dan velikom količinom podataka ali problem je u tome što se nekada podaci brišu unazad za određeni period. Taj broj podataka koji se brišu unazad je dosta veliki pa brisanje traje čitavu večnost. Tako da sam napravio tabelu koja je particionisana i podelio je na dve particije. Jedna particija je taj deo sa podacima koji se nikada ne briše a druga particija je sa podacima koje punim i brišem. Svakog dana menjam particionu funkciju i pomeram joj granicu. E sada interesuje me da li je bolje da te dve particije stavim u dve odvojene fajl grupe ili mogu da ih ostavim sve u primarnu fajl grupu? Granica za particiju je tipa date tako da u jednu particiju ulaze podaci sa datumom manjim od zadatog a u drugu particiju taj datum i veći. Koliko sam ja skontao sa dve fajlgrupe bi možda ubrzao insert podataka ako bi vršio istovremeno insert svih podataka u tabelu ali pošto ja radim samo delete i insert u ovoj zadnjoj particiji mislim da je najbolje da ostavim obe particije u primarnoj fajlgrupi. Da li sam u pravu? Da, u pitanju je SQL server 2008 sp1
[ mmix @ 14.05.2009. 09:32 ] @
pa ne bi ubrzao, u single-disk sistemima fajlgrupa utice na performanse samo u onim granicnim slucajevima (kad se resizuje) a to su u lepo planiranoj bazi retke situacije. fajlgrupe su vise administrativni koncept posto predstavljaju granicu na kojoj mozes da 'prelomis' backup/recovery procedure ja bar jos nisam cuo da je neko imao dobro obrazlozenje oko generalnog poboljsanja performansi koristeci fajl grupe. Izuzetak su naravno podele na fajlgrupe u sistemima koji imaju npr. vise razdvojenih disk sistema pa razlicite fajlgrupe na razlicitim diskovima dovode do poboljsanja performansi kroz minimizaciju IO cekanja, al pretpostavljam da to nije tvoj scenario.


[ MatezYU @ 14.05.2009. 10:59 ] @
Meni je potrebno samo da razdvojim tabelu na dve particije, tako da ta druga particija brze radi (brisanje itd)..
[ mmix @ 14.05.2009. 11:51 ] @
To sto si uradio je sasvim legitiman potez ka resavanju svog problema. I kad vec koristis SQL 2008 onda promeni eskalaciju lockova sa table na partition level:

Code:
ALTER TABLE tabela SET (LOCK_ESCALATION = AUTO);


Ova znaci da ce SQL u situacijama kad bi inace resio da eskalira lock na nivo tabele (sto moze lako da se desi sa bulk brisanjem) da umesto toga prvo proba da eskalira lock samo na nivo particije, time bi ostale particije ostale slobodne za query-e.

Drugi tip za tebe ja da obavezno ukljucis partitioning uslov u delete statement i da prvo indeksiras diskriminaciono polje (datum). Znaci cak iako brises po nekom drugom polju gde si siguran da se svi brisani podaci nalaze u 'dinamicnijoj' particiji ukljuci i diskriminisuci date koji direktno pokazuje na samo jednu particiju (npr where datum >= danas), taj diskriminisuci uslov ce omoguciti query optimizer-u da eliminise nekoriscene particije bez potrebe da skenira tabelu/index
[ MatezYU @ 15.05.2009. 07:00 ] @
Ok hvala ti. Mislim da je to - to. Trebalo bi da radi ok.