oracle alá hardver

Adatbázis: SQL, XML DB

Hátha csinált valaki itt ilyet, vagy van tapasztalata: oracle alá kellene egy vasat méretezni nagyjából. Amit kb tudni lehet:

-egyszerűbb query 150 db/sec,
-bonyolultabb query/tárolt eljárás 75db/sec,
-kb 40-50 tábla,
-összesen úgy 2-3M rekord hosszú távon,
-mindezt napi 12 órában (a maradékban nem fut az alkalmazás),
-Solaris 10

Azt tudom, hogy a több ram/több ghz/gyorsabb diszk az jó. De kb mi a minimum cpu/órajel, amin ez képes elfutni? Az se baj, ha nem sparc-ra, x86-ra tud adni valaki kb valamilyen becslést. És van értelme itt a 64bites cpu-knak?

  • 2276 megtekintés

( t-bee | 2007. 10. 31., sze – 23:20 )

Némi hivatalos támpontot itt kaphatsz. Tapasztalataim csak Win környezetben vannak, főleg mert amikor alkalmam volt tesztelgetni, akkor még Solarisra nem volt 11g.
Amúgy mit kéne használni Oracleben? OLAP ROLAP; adattárházat építenek rá; esetleg PL/SQL vagy csak SQL?

pl/sql, sql, oraclejvm, ilyesmi. Kesz holmit nem akarok erre hasznalni, mert tovabb tart megtanulni, minthogy elkeszulne. Annyira elnagyolt a feladatleiras jelenleg, hogy ezeknel sokkal tobbet nem tudok en se. Szoval igazabol jo altalanos dolgok kellenek, azokbol sok, a tobbit meg majd megoldja az egyedi cucc korulotte. A tranzakciok szama is ugy hasrautessel, nagyjabol. A lenyeg, h ne tevedjek nagyot. A win-es tapasztalat erdekel.

( gabrielakos v | 2007. 11. 01., cs – 09:09 )

Szerintem:

- nem túl nagy ez a terhelés, jó diszk alrendszer kell hozzá, a többi szinte mindegy.
- 4GB RAM
- BBWC-s kontroller, 128M vagy több memóriával (ez a legnagyobb durranás az egészben), mindegy hogy SATA v SCSI
- 4 diszk, RAID10-ben
- valami mostani modern Opteron proci, 1 db, alaplapon legyen opció 2-re
- esetleg valami dual-core Xeonnal ugyanez, bár ez lassabb

A 64 bitnek ott van értelme, hogy nem küzdesz a 4GB RAMmal, plusz 2GB-nál nagyobb SGA-t tudsz csinálni ha muszáj (első körben nem muszáj sztem)

--
Gabriel Akos

( gabrielakos v | 2007. 11. 01., cs – 09:10 )

... nekünk van ilyen konfigunk, BBWC nélkül 80tr/sec, BBWC-vel 1100tr/sec :)

--
Gabriel Akos

( okarika | 2007. 11. 01., cs – 09:57 )

A solaris-t nem ajánlom. Lesújtóak a tapasztalok. Sparc- on nincs mihez hasonlítani, de az ár/teljesítmény arány tragikus.

X86-on ugyanazon a vason linux alatt 1,5-2 x gyorsabb az oracle. (persze lehet, hogy én nem értek eléggé a solaris-hoz)

(a diszk kiosztás is ugyanaz, mielőtt valaki megkérdezi)

Ez a teljesítmény igény meglehetősen szolíd, úgyhogy mindenképpen pc-ben gondolkoznék. Ha hosszú távon kell mennie, akkor azért valami tisztességes gépet kell venni, amihez pár év múlva is lesz support, és nem a legolcsóbb/legócskább cuccokból készült. (persze ennek ára van)

Az ora sebességének alfája és omegája a diszk teljesítmény és a jó sql-ek. Minél jobbak az sql-ek, annál kevésbé gond a diszk teljesítmény. Főállásban foglalkozok mindenféle (közepes és nagy) cégnél ora teljesítményhangolással, és hihetetlen sql-eket írnak azok is, akiket profiknak tekint a szakma.

láttam már olyan sql-t, ami a monitotozó progink 32k-s pufferébe nem fért be, és a where-nél még nem jártunk!

És még tudnám sorolni.

Szóval nem hátrány, ha nem csak oracle hangolással, hanem oracle sql hangolással is foglalkozol egy kicsit. Ha jók az sql-ek, fele-harmad akkora teljesítményú gép is bőven elég.

Az oracle dbconsole-ja elég sok infót tud mutatni, de az ajánlásaival csak óvatosan. Sokszor jók az ajánlatok, de néha teljesen le tudja egy két rosszul sikerült ajánlat megvalósítása ültetni a rendszert.

Nincs az a vas, amit akár egyetlen rossz sql-el le ne lehetne ültetni!

Nem tudom, hogy hogyan szereztél rossz tapasztalatokat, viszont annyira nem gáz a Solaris.
Ha teljesítmény gondjaid voltak vele, akkor nem szabad elfelejteni, hogy a Solaris egy általános célú unix, amit nagyon jól be lehet hangolni egy adott feladatra. Az Oracle tipikusan olyan dolog, amihez a Solaris-t erősen javallott hozzáidomítani.
Persze érteni kell hozzá, de mihez nem kell?

Ha az oracle enterprise linux-ra gonodolsz, az egy redhat enterprise linux, plusz pár oracle funkció. A legnagyobb előnye, hogy az alapszintű támogatás kb 100$ / év. A redhat jóval drágábban adja a támogatást. Másik előnye, hogy az oracle nem tud az os-re mutogatni, ha valami nem működik.

A hátránya, hogy bármilyen frissítőcsomagot csak akkor érsz el, ha van rá támogatásod. De ez minden enterprise (oracle által támogatott) linuxra igaz.

Jelen pillanatban az OEL5 a legfrissebb, gyakorlatilag RHEL5.

ASM-hez van asmlib, nem kell raw device-al szívni.
Egyszerűen tudsz rá ocfs-t rakni, és a redhat féle gfs is benne van. Van ora támogató csomag, ami beállítja a kernel paramétereket, usereket, groupokat, limiteket,... = gyorsabb az ora telepítés.

Szóval nem most jött ki, és nem is egészen saját. (de az oracle-t ismerve ez inkább előny.)

Én 1-2 helyen használom, jól működik.

Windowson az ora tud meglepetéseket okozni, elég bugos a stuff. (nem tudom, és nem is akarom eldönteni, hogy ez az ora, vagy az ms hibája)

nezd, ez nem egy olyan dolog, h odamegyek es linux lesz rajta. Naluk a linux nem tamogatott platform, es ha nem akarjak, akkor nem lesz. Es nem komplett rendszert szallitok, csak alkalmazast. Az, h ki fogja uzemeltetni, az mas kerdes.

Azert jo lenne, ha valaki mondana jot is a solarisrol (zwei?).

Tapasztalataim szerint nincs semmi baj a Solarissal, ha szakértő kéz nyúl hozzá. Amúgy meg nem a linux vs. solaris volt a téma, hanem a HW.

Azert jo lenne, ha valaki mondana jot is a solarisrol (zwei?).

SZVSZ a Solaris a legjobb választás mert robosztus, megbízható, jól dokumentált és ingyenes, valamint jó pénz kérhető a szakértői támogatásért. Ez az a pont ahol esetleg a Windows is megfontolás tárgya lehet; hátránya és előnye hogy nem ingyenes, remek pénzt lehet érte kérni. Ha meg nagyon inyenc akarsz lenni akkor az AIX is szóba jöhet.

Volt néhány hasznos tipp itt is, de véleményem szerint adatbázis műveletekhez scsi vagy sas diskrendszert használj.

Most nem értelek.

Ha más fogja üzemeltetni, akkor nem teljesen mindegy, hogy milyen OS van rajta?

Baromi sok helyen van Solaris Oracle alatt. Nincs azzal semmi baj. Ha csak az alkalmazást szállítod, akkor majd az üzemeltető fogja ügyesen beállítani. Nem? Aki feltételezhetően hozzáértő ember.

G

A tapasztalat nem ezt mutatja. Sokan mondják, hogy értenek hozzá (nem emberek, cégek!) és az eredmény...

Sajnos tényleg hozzáértő nagyon kevés van. Én sem vagyok az. De legalább nem állítom magamról. Én az ora gondjaihoz értek, csak nagyon fáj, amikor a húde solaris képzett rendszergazda néz rám mint a borjú, ha kérdezem.

Szivesen elmélyülnék benne, csak akkora a téma, hogy nem is tudom hol kezdjem. Leginkább az i/o tűnik gázosnak, jó lenne tudni, hogy mihez nyúljak, mit olvassak.

Hi,

Nincs összehasonlítási alapom, hogy Linux v. Solaris jobb -e Oracle alá.
Solarison elég sokat láttam, és a legtöbb esetben gond nélkül, és jól fut rajta. Ez nem nagyon mondható el pl. az eddig általam látott windows+oracle kombókról.

A Solaris nagy előnye, hogy nagyon jól tuningolható. Érdemes a /etc/system-be beállítható kernel paramétereket (shared mem, és szemafor paramáterek) az adatbázishoz hangolni. Ezekről az Oracle telepítési leírásokban elég jó útmutatók vannak.
Nem szabad elfelejteni, hogy a 10-es solarisban ezek egy része kikerült a /etc/system-ből, és a /etc/project-ben kell állítani. (Asszem a shminfo_shmseg ilyen, de most fejlből nem vagyok biztos benne.)

Fontos, hogy a diszkek minnél gyorsabbak legyenek, a BBWC nem hülyeség.
Ha file rendszerben lesznek az adatbázis fájlok, érdemes kikapcsolni a file rendszeren az IO cache-t, az Oracle úgyis cache-el, így elkerülhető a double-buffering. Érdemes az egyéb IO paramétereket is kicsit az Oracle-hez hozzáidomítani.

A hardverről:
A Solaris és az Oracle is jól skálázódik több processzoron.
Egyetlen hátránya, hogy az Oracle processzor, illetve processzor-mag szerint licenszelődik. :)
Érdemes, a licenszelési szempontokat is figyelembe venni, hogy kevesebb, de gyorsabb processzor legyen esetleg a rendszerben.

A Sun-nak az új x4150-es szervere elég jónak tűnik. 2 darab quadcore Xeon-fér bele, és max 64GB RAM. Ami a korábbi szerverekhez képest igen pozitívum, hogy 8 darab SAS diszk fér bele, és normális hardveres RAID-et is lehet vele csinálni.
Ha nem csak egy Oracle adatbázis lesz a vason, hanem esetleg egy alkalmazás, vagy webszerver is , akkor a több processzort nagyon jól szét lehet osztani Solarissal az adatbázis, és az alkalmazás szerver között, akár eltérő processz ütemezési stratégiával is.
(Az Oracle-t Solaris alatt Time-sharing-on kell futtatni, alkalmazás szerver, webszerver pedig Fair-Share-schedulerrel elég jól elvan.)

Egyetlen hátránya, hogy az Oracle processzor, illetve processzor-mag szerint licenszelődik.

Az egyes kiadásonként változó: Express Edition 1db processzort, a Standard Edition One 2 processzor magot; Standard Edition 4 processzor magot, míg az Enterprise Edition nincs limitálva. Itt megtalálható minden tudnivaló.

Amennyiben Express Edition minden szempontból megfelelő neked, akkor nyilvánvalóan a HW igény 1db 32 bites CPU, 1GB RAM, viszont ekkor az OS is csak Linux vagy Win lehet.

Viszont azt nem látom sehol leírva hogy 10g vagy 11g ami kell a témaindítónak? Mert tudomásom szerint 11g egyelőre csak Linuxra és Win-re elérhető, míg a 64 bites csak Linuxra és csak x86-ra.

Ha futja rá, akkor az Unbreakable Linux programot fizettetném elő. Ha probléma van, akkor tőlük van az OS és az alkalmazás is és nem megy a mutogatás az OS vendorra, onnan meg vissza az Oracle-re. Gondolom ők is ezt javasolnák. 350 ezer forintnyi dollárért 7x24-es szupportot ígérnek / rendszer. Ez komoly helyen nem nagy pénz. hardverben nekünk az x86(_64) jött be. Ár / teljesítményben biztos, hogy a legjobb. A gyártó pedig vallási kérdés, így azt döntse el mindenki maga :)

--
trey @ gépház

( poperator v | 2007. 11. 01., cs – 20:44 )

Az scsi es sas diszk eldonteskor jo ha figzelembe veszed hogy ugy tunik jelenleg a sas
all nyeresre es 4-5 ev mulva ha kihullik egy diszk valszeg egyszerubb lesz a sas diszk
beszerzes mint egy scsi.Az adatbazist es a redologokat kulon raid tombokre (nem particiokra)
tennem. Nomeg nem felejtkeznek el egy hot-spare diszkrol se..
A 32 vagy 64 bit oprendszerhez csak annyit tennek hozza, hogyha
32 bites pocit valasztasz, es 4G rammal indulsz, akkor ha bovitened kell, az azt jelenti
hogy uj gep, uj oprendszer, uj install, stb.... Erdemes elore gondolkozni.

PO

( Mico v | 2007. 11. 02., p – 02:03 )

En csak a sajat gepeinkhez tudok viszonyitani, ide egy X4100/X4200/X4150 kategoriaju gep eleg.
Utobbival talan a legkenyelmesebb, annyi belso diszk joval elnezobb a "tuningolast" illetoen.

Fenti kollega hozzaszolasanak solaris-ra vonatkozo reszevel nem ertek egyet, SPARC-ra vonatkozoval reszben. Ahol nagy sparc-on fut valami, oda neha nehezebben talalsz x86 alternativat, es ezen az sem segit hogy ma egy 3 millios szerver hozza a par evvel ezelotti szuperszamitogepek teljesitmenyet - cpu-ban. a niagaras gepekkel pedig tobb teruleten is bonyolultabb lett a helyzet megeri/nem eri szempontbol. mindenesetre neked itt pl., ha a legolcsobb jo megoldast keresed, egy x4150 szerver kell 1 db quad core cpu-val (bovitve, ha esedekes), 4 gb ram-mal, 4-6 db belso diszkkel es belso raid vezerlovel. sparc-bol attol tartok, kevesnek bizonyulhat egy V245.

arulnak ma meg nem 64 bit cpu-t amugy ?

aztan ne engem okolj, ha nem birja, fenti kolleganak igaza van minden azon mulik mit csinalsz vele. :)

gyakori problema volt pl. a niagara gepekkel, hogy nem nagyon teszteltek elotte sok cpu-s gepen az alkalmazast, akkoriban meg nem voltak 4 magos x86 procik se, meg jellemzoen web felhasznalas, lelkes de tapasztalatlan fejlesztok, aztan jon a web2.0 forgoszel, vele egyutt meg a load, a sok processzor egymasra var table lock miatt. (myisam..)
szerk: termeszetesen nem az engine sajat, belso lockjarol beszelunk hanem a user altal explicit kiadott 'lock tables' parancsrol (!), ahol az unlock elott jo par dolog tortenik meg. single/dual cpu gepen tobbnyire az egesz blokk lefut egy utemben, meg nagyobb loadnal is, de sok cpu-nal ugy tunik, mar kisebb loadnal is "szetdarabolodik", aztan egymasra varnak a szalak. persze, alapveto programozasi hiba. szamitok ra, hogy az olcson mert, alacsony orajelu quad core xeonokkal sokan fognak ilyen problemakkal talalkozni.

persze ennek semmi koze a te problemadhoz, csak annyi, hogy igazabol az alkalmazason mulik.

Háhá, akkor azok már "fejlett" programozók, mert explicite használják a lock tables-t, örüljünk, hogy odáig eljutottak...
Altalaban a lock-kal szerializaciot akarnak emulalni (wtf innodb?!).
off://de a legjobb, amikor cron-bol megy az unlock, mert az mar elfelejtik explicite... és nem értik mi a bajom...
Sajnos a php is kenyelmesen van megirva, igy nem a legskalazhatobb mpm modellt hasznalja az apache sem...
Tudom, nem kell php-t hasznalni :)

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

Nagy vasnak nem is az x86 az alternatívája.

Nekem pl az ibm nagyobb vasaival jók a tapasztalataim, de ne várd, hogy komoly elemzést mutassak róla. Odamentünk, dolgoztunk azzal ami volt, és a kb egy árban levő rendszerek között jóval gyorsabb volt a power/aix, mint a sparc/solaris.

Lehet hogy egy másik osztályban ez fordítva van, és lehet, hogy az egyik tisztességesen volt felrakva, a másik meg csak felhányva.

Nem vagyok rendszergazda egyik platformon se, rendszermérnök meg pláne nem. Ezek az én szubjektív benyomásaim. Ha valaki tud tippeket mondani, hogy mitől lehet lassú egy frissen, új vasra telepített solarisos rendszer (olyasmire gondolok, hogy mi az amit a telepítésnél nem érdemes alapértelmezetten hagyni) azt megköszönöm. Nem vagyok a sparc/solaris ellensége, csak keveset tudok róla, és kénytelen vagyok a benyomásaimra hagyatkozni.

és a kb egy árban levő rendszerek között jóval gyorsabb volt a power/aix, mint a sparc/solaris.

Igen, ez régebben tényleg így volt. Az IBM power szériája jóval jobb ár/teljesítmény arányban voltak, mint a Sun hasonló kategóriás vasai.
Anno a Sun lemaradt egy kicsit a processzor fejlesztéseivel, de asszem erről Erik tudna többet mesélni. :)

"Lehet hogy egy másik osztályban ez fordítva van, és lehet, hogy az egyik tisztességesen volt felrakva, a másik meg csak felhányva. "

Így kb. ez. Itt ez a jobb, ott az. Az "egy árban" is így működik, ez a cégcsoport ezt kapja olcsón, a másik azt, mondjuk Sun-t. Szóval ezt így elég bonyolult bárhogyan is összevetni.

Ezért merek én is csak szubjektív benyomásokról beszélni. Egy tisztességes összehasonlításra isten ideje sem elég, és még ha van is rá idő, az ember legfejebb saját magát tudja meggyőzni, mást aligha. Ebben a szakmában úgy tűnik senkinek sem érdeke, hogy igazán megalapozott döntéseket lehessen hozni, néha olyan érzésem van, hogy minden egyes benchmark úgy van kitalálva, hogy ne lehessen kétkedni az hiteltelenségében.

Jó lenne, ha volna egy olyan társaság, amelyiknek az eredményeit a kritizált is elfogadná, de ehelyett megmagyarázzák, hogy mi torzította a mérést, és a valós viszonyok között úgyis az övék a jobb.

Azért én ebben az országban még olcsón kapott sun vasat nem láttam. Ennek ellenére vannak olyan helyek, ahol még a gépterem kulcsa is sun emblémás. Az üzletpolitikájukról/gyakorlatukról nem nyilatkozom, egyrészt mert nem szeretném, ha beperelnének, másrészt mert a többi nagy cég is gyakran hasonlóan győzi meg a döntéshozókat.

Elnézést ez már nagyon off lett, eldugulok.

Debreceni Egyetem infókarának pár éve akartak ajándékozni egy szervert SUN-ék.
Egy probléma volt. Nem fért be a kapun az épületbe.

Később kiderült, hogy ez a szerver már megjárt jópár másik egyetemet, főiskolát is, de sehol máshol se tudták bevinni az épületbe... :-D

Most hoztak egy másikat, bár az is érdekesen volt csomagolva, a kisebbik doboz (~=15" crt doboza), benne két még kisebb doboz, ezekben volt a KÉT TÁPKÁBEL külön-külön elcsomagolva...

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

"Azért én ebben az országban még olcsón kapott sun vasat nem láttam. Ennek ellenére vannak olyan helyek, ahol még a gépterem kulcsa is sun emblémás. Az üzletpolitikájukról/gyakorlatukról nem nyilatkozom, egyrészt mert nem szeretném, ha beperelnének, másrészt mert a többi nagy cég is gyakran hasonlóan győzi meg a döntéshozókat."

Mi főleg kisebb vasakat árulunk (20 milla alatt), a meggyőzés módszere a teszt gép, a benchmark, a hozzáértés. Zsebbe senki nem kapott még. Hogy mi megy efölött, azt nem tudom, de nem is érdekel, az biztos, hogy Mo.-n a "nagyok" közül a Sun-nál találkoztunk a legkorrektebb hozzáállással (ezért is ezt áruljuk - amellett, hogy jók a termékek).

Az E25k -s story nem feltétlenül urban legend, mi is hónapokig próbáltunk "vevőt" szerezni egy ingyen darabra (talán ha nem is 25k volt, hanem 12k vagy 15k), nem kellett senkinek, túl nagy.

a meggyőzés módszere a teszt gép, a benchmark, a hozzáértés. Zsebbe senki nem kapott még.

+1.
Egyébként van példa a zsebbe-módszerre is (személyes tapasztalat nincs, csak hallottam sztorikat) viszont itt mindig a vevő volt az, aki a zsebét tartotta. Olyanról még nem hallottam, hogy a kereskedő kezdte volna úgy, hogy x%-megy a döntéshozó zsebébe.

Én már láttam nagyon olcsón kapott Sun-vasakat, éppen úgy ahogy nagyon olcsón kapott IBM, vagy HP vasakat. A több(tíz)millás kategóriában a listaár baromira nem játszik szerepet. A gyártó cég kereskedőjének van egy elég nagy játéktere az árban, és ha úgy látja jónak (piacszerzés, stb.) akkor jelentős kedvezményt is adhat (20-50%) a listaárból.

Ráadásul vannak nemzetközi nagy cégek, akik globális keretszerződések miatt alapból 30-40% kedvezményt kapnak a legtöbb nagy gyártócég termékeiből.

A Sun-os hozzáállásról én is csak elismerően tudok nyilatkozni, úgyis mint volt (nagy) ügyfél, és úgyis mint jelenlegi (kicsi) partner.

( Droptable | 2007. 11. 05., h – 11:22 )

SUSE alatt Oracle memóriafelhasználás:
Az alapokon túl 1 szál evett kb. 40 mb-ot és userenként volt 6-10 szál. Ez persze alkalmazásfüggő. Meg ugye illik alapból 2 GB az orának meg az oprendszernek minimum. és ezen fellül az usereknek. Tapasztalat, hogy 200 user 4 GB ramot semmi pillanat alatt felzabált és lelassult az egész. ja éez egy 4 db dual xeonnal szerelt FU-SI szerver volt.

Amúgy SUSE és REDHAT alatt tökéletessen működik, win-es felületet én sem javasolnék,árcsak a sebesség miatt sem.

Diskben kizárólag SCSI jöhet szóba, lehetőleg RAID 1-0, mer a RAID 5-t elvileg nem szeresse linux alatt az ORA,de én láttam már ilyet működni, szóval a fene tudja.... Ha lassú a disked az mindent le fog lassítani, hiába teszel bámilyen vasat alá.

Diskben kizárólag SCSI jöhet szóba, lehetőleg RAID 1-0, mer a RAID 5-t elvileg nem szeresse linux alatt az ORA,de én láttam már ilyet működni, szóval a fene tudja.... Ha lassú a disked az mindent le fog lassítani, hiába teszel bámilyen vasat alá.

SCSI, SAS, FC.
A leggyorsabb az FC, bár linuxon előfordulhat, hogy nem. :)
RAID 5 egyébként oké tud lenni pl. EMC diszkalrendszeren (elég jó a RAID5 implementációjuk), de általánosságban nem javasolt adatbázis alá RAID5.
Ökölszabály adatbázisokhoz a RAID1-0.

Te mit szívtál?
Az Oracle linux alatt, meg minden épkézláb unix alatt processzeket használ, nem szálakat.
Szálak csak Win alatt jellemzik az Oracle-t.
Ezen kívül az a dedikált szerver processzenkénti 40 MB memóriaigény elmebetegül félrekonfigurált adatbázisra utal.
200 konkurrens kapcsolat meg sem kottyanhat. Nagyjából 1-1,5 GB memóriát szokás fenntartani a dedikált szerver processzeknek 150-200 processz esetén.

El lehet gondolkozni a shared szerveren is, de ezt már inkább több ezer usernél szokták használni.

Ha megnézed a 200 userből 20-30 lehet, aki tényleg aktív. Legalábbis általában ez az arány. Úgyhogy nekem is gyanús a 40M/processz. (persze ettől még lehet igaz, de nem ez a jellemző)

Félig jogos az észrevétel, de a szálak mint magyar szó nekem jobban tetszett. A process-re nem tudok most hirtelen rendes magyar megfelelőt. Dehát te is rájöttél mire gondoltam.... :)

Nem kell félrekonfigolni, csak egy 3-400 táblás, többszáz tárolt eljárásos adatbázis kell hozzá 30-40 GB méretben.

Processz=folyamat, ha valaki ennyire szeret magyarkodni, én személy szerint nem, mert rontja az érthetőséget.

~75 Oracle adatbázist üzemeltetek, sok közülük 100-300 GB méretben, szintén sok közülük többszáz táblával (hozzáteszem, amihez 400 tábla kell, az vagy ~SAP, vagy nagyon el van b*szva), némelyiknek a tárolt eljárások adják nem csak az üzleti logika részét, hanem a megjelenítést is, és egyiken sem zabál ennyit egyetlen dedikált szerver processz sem.

Még 64 bites platformokon sem, még ha ott kicsit nagyobb is a processz "footprint".
A 30-40 MB memóriahasználat minden egyes dedikált processznek Oracle esetén tipikusan az a helyzet, ami azonnal szakértőért kiált => félre van konfigurálva.

( Droptable | 2007. 11. 05., h – 11:50 )

Ja, és igen, van értelme a 64 bites cpu-nak, mivel akkor oprendszer és ora is 64 bites lehet. Nem haszontalan dolog. Szerencsére dualos proci licencileg 1-nek kezeli.

( lacika v | 2007. 11. 06., k – 12:46 )

Egy Sun Fire V240 megteszi 4GB memóriával. (Igaz már csak 245 -öst lehet kapni, de használtan is lehet szerezni V240 -et)

--
http://laszlo.co.hu/