Ed Wood DBA
Član broj: 189254 Poruke: 14 *.cpe.vektor.net.
|
Oracle baza od 1G je, da izvines, smesno mala baza! Sa bazom te velicine ne bi trebalo da imas nikakve performance probleme, cak i bez nekog narocitog fine-tuniga.
Ovi serveri koje imas su ti sasvim dovoljni za tako malu bazu, uz, naravno, dodatnih 1Gb kao sto lepo rece prethodni komentator. Cudi me da to vec niste probali. Oracle je tako koncipiran da (logicno) "zdere" memoriju. Tacnije, potrosi onoliko koliko mu das! Pa, cak ni obicna Windows Vista Home premium se "gusi" na 1G RAM-a, a kamo li jedan tako robustan sistem kao sto je Oracle RDBMS (nisi naglasio, jel koristis Enterprise Edition?) I, ne zaboravi, nije dovoljno da samo dodas modul od 1G RAM-a u server, mnogo je vaznije da prekonfigurises SGA tako da tu dodatnu moemoriju i alocira prilikom stratup-a. Narocitno je bitno da povecas "buffer cache", tj cache za same podatke iz tabela. Da sad ovde ne pricam o stalim cachevima koji su takodje bitni (PGA, Shared pool).
Za primer: ja trenutno odrzavam bazu veliku oko 140Gb, na HP rack serveru sa Xeon procesorom na 3Gh i sa SAMO 2Gb RAM-a i radi nam prilicno solidno, uz, naravno, neke spore upite, koje ja obicno resim tjuniranjem (hintovima najcesce, jer u dizajn baze ne smem da diram). A ti neki upiti koji su jako spori su takvi zato sto su "bolesno kompleksni", spajaju po 7-8 velikih tabela, sa neverovatno uslovima za selekciju, tako da po mom misljenju ovakav server cak iste izvrsava vrlo brzo. Drugi, iole jednostavniji upiti, rade savrseno dobro.
Sto se tice sporih batch obrada, one su po svojoj priordi SPORE, tako da 5h za neku obradu na tako "slabim" serverima i nije los rezultat. Medjutim, svaka batch obrada se finim tjuniranjem moze dovesti na vrlo prihvatljivo vreme izvrsavanja. Ali, takve akcije zahtevaju veliko znanje i iskustvo, koje se nalazi u knjigama kao sto je ona koju sam ja ponudio na ovom forumu, a NIKO pod milim bogom se nije za istu ni zainteresovao. A, za taj posao, konsultanti na zapadu naplacuju velike sume.
Sto se tice sporih batch obrada, savetujem ti da obratis paznju na to kako su ti indeksirane tabele, jer tu njacesce lezi odgovor na sve sto je sporo (upiti, batch obrade). Ja sam, recimo, jednu mesecnu batch obradu kod nas u firmi sveo sa 8-1o sati na samo 45 min, tako sto sam jednostavno drop-nuo sve indekse na toj tabeli, na kojoj su inace isti bili potpuno nepotrebi (citaj:igrali se programeri, tj. ucili se programiranju na Oracle-u). To je bio banalan slucaj, opet na drugim mestima sam spore batch obrade resio materijalizirajucim vjuovima, negde samo hintom, itd...
Jedina stvar oko koje se ne slazem sa Knezom, i licno ti savetujem da se NE upustas u tu avanturu je promena OS, na Linux i slino. Iz licnog dugogodisnjeg iksutva znam, ni Linux ni Unix ti nece doneti NIKAKVO poboljsanje na performnsama ako nemas dovoljno hardverskih resursa, a unece ti znacajnu kompleksnot u tvoj sistem, koju mozda ne zelis. Jer, raditi sa Linuxom ili unixima je znantno teze nego sa Windowsima, tako da, osim ako nisi Unix epert, ne upustaj se u tu avanturu. Sama instalacija Oracle na unixima je mnogo vece glavobolja nego na Windowsima. Uverio sam se da Oracle jako lepo radi na Windows Serverima, narocito 2003 (nikako professional, ne daj boze home edicije), ako je server dovoljno "jak" i ako je sam Oracle adekvatno tjuniran i ako je fizicki dizajn baze (broj i odnosi izmedju tabela, dizajn index-a) dobro izveden. I, naravno, pod uslovom da na tom Windows serveru niko osim DBA i sistem admiona ne "divlja" i "experimentise", bas kao sto (obicno) niko to ne radi sa Unix serverima (jer po svojo prirodi nisu zgodni za igranje), tj. poenta je da bude "cist i utegnut".
|