Pozdrav, evo uhvatih i malo vremena da napišem štogod korisno, nadam se da će vam pomoći, posebno onima kojima DB administracija nije jača strana (nije ni meni, ali štaš sad).
Nažalost, na veliku većinu optimizacije baze, administratori i nemogu utjecati. Ukoliko programeri ili DB arhitekti su već dobrano opteretili bazu s koje kakvim suludim upitima vjerojatno nikakve optimizacije vam i neće pomoći.
No ukoliko imate bazu koja se čini radi, ali nekako se se vuče ko krepana krava preko 3 tablice, vrijeme je da počente razmišljati o optimizaciji a samim time i održavanju baza. Dakle, otvorite resource monitor i pogledajte u čemu je zapravo problem.
Resource monitor je sjajan kod pin-pointa di je zagusenje
Procesor: Ukoliko kod upita nad bazom zakucavate šiljkom vrh, onda ili morate zvati navedene doktore znanosti (programere), prepoloviti bazu, ili pak zamjeniti procesor. Mislim da kod small i medium buissness baza ovo ne bi trebalo biti problem, svaki procesor s 4 jezgre i HTTom i 64-bit OS i SQL Serverom ne opterećuje procesor previše.
Memorija: Ukoliko SQL servis uzima previše RAMa, ili ga nadodajte, ili nazovite navedene doktore.
Network: Ah, dodajte još kakav Gbit NIC i agregirajte ga s postojećim.
Disk: E, tu su đavli. Kako su još SSDovi skupi, možda vam uprava i da odobrenje za nabavku više 500GB SSD-ova u RAID 1+0. Ukoliko ste ostali na starim diskovima/RAID polju, najbolje bi vam bilo početi odavde optimizaciju.
Ovdje nastupa jaka fragmentacija podataka, jer se podaci pišu uzastopno u bazi u redu diskova u RAIDu. Kada se želi isti takav pročitati dolazi do povećanja I/O na diskovima, pri čemu se do traženog podatka teže (sporije) dolazi.
Većina baza koje sam viđao imaju checkiranu auto-growth opciju, pa kad se rašire po diskovima, postaju dosta fragmentirane. Ukoliko nemate DB Administratora u firmi (e to sam često viđao), onda bi vam i bolje bilo ostaviti ovo checkirano. Nek ona raste i bude fragmentirana kad neće da zaposle nekog tko bi se brinuo o njoj. Za log bazu vrijedi sve rečeno. Također, morate voditi računa o fragmentaciji TEMP baze. Čuo sam prakse di se stavlja TEMP u RAM disk, iskreno nemam muda da to napravim.
Fragmentacija indexa u bazi. E to zbilja morate pogledati. S vremenom indexu se preraspodijele, ili se dodijele "rupama" u bazi, ili slično. Ono što trebate napraviti je vidjeti postotak fragmentacije indexa.
Najprije saznajmo ID baze.
USE MOJA_BAZA
SELECT DB_ID() AS [Database ID];
GO
Zamjeniti MOJA_BAZA s imenom svoje baze.
DB ID
SELECT ps.database_id, ps.OBJECT_ID,
ps.index_id, b.name,
ps.avg_fragmentation_in_percent
FROM sys.dm_db_index_physical_stats (8, NULL, NULL, NULL, NULL) AS ps
INNER JOIN sys.indexes AS b ON ps.OBJECT_ID = b.OBJECT_ID
AND ps.index_id = b.index_id
WHERE ps.database_id = DB_ID()
ORDER BY ps.avg_fragmentation_in_percent DESC
GO
Žuto označen broj osam, zamjenite s ID brojem koji ste dobili u prethodnom qureyu. Output querya:
Izgled outputa
- manji od 5% - ne raditi ništa, sve ok
- ukoliko je 5-30, radite maintence plan i reorganizaciju indexa
- ukoliko je 30-100%, radite kompletan rebuild indexa.
Dakle, na Mangeru, Managemnt->Maintence Plan, odaberite wizard, odaberite baze i kada se treba izvršiti reorganizacija. Ovo je potpuno bezopasno. Npr, ja svoj radim svaku noć.
Maintence plan
Ukoliko trebate raditi Rebuild svih indexa, ista stvar, samo izaberite rebuild i manulano to napravite! Ukoliko imate Standard SQL server, onda morate postaviti bazu u offline mode. Ovo može biti opasno ukoliko neznate što radite malo guglajte best practice.
Ja radim rebuild jednom godišnje, nakon što arhiviram produkcijsku bazu na prelazu godine i prebacim u drugu bazu, odradim i rebuildanje i vratim fragemntaciju na minimum.
Optimizacije za anti-virus:
Kako moderni AVovi prate gotovo sve I/O s računala, pa tako i bazu, potrebno je dodatno optimizirati AV na serveru na ne skenira bazu. Molim proučiti:
http://support.microsoft.com/kb/309422/
I to je čega se mogu sjetiti. BTW, ja nisam nikakav DB admin (niti bi htio biti), samo vam prenosim svoja iskustva koja su mi pomogla pri optimizaciji.
