[quote:42c3ddb241="anr"]
Nem azzal van gond, hogy erteni kell hozza, hanme az informacio elerhetosegerol. Ha valami bajom van linux kernel/postgress/perl/... ugyben, akkor rakeresek a doksiban/kerem a google segitseget, es KAPOK valaszt. Az Oracle-vel kapszolatos keresesek minimalis/zero hasznalhato valaszt eredmenyeznek. Ez oriasi gond.
...
Ne viccelj már, kevés jobban dokumentált rendszert tudnék mondani, mint az Oracle, ráadásul mindez szabadon elérhető az http://otn.oracle.com-on, ingyenes regisztráció után. És ha netán azt mondanád, hogy oké, de mivel drága, nem tudod autodidakta módon megtanulni, ugyaninnen az Oracle összes termékét letöltheted, és fejlesztésre/tanulásra használhatod legálisan...
Mondj még egy nagy szoftverfejlesztőt, aki ennél jobban támogatja a termékei megismerését és a tanulást....
Mi regebben rengeteget tokoresztunk az opitmalizalassal, mert irto lassu volt a rendszer, meg valami profi monitorozo program is futott ami alapjan indexelesi roham volt mind a 20xx tablara ;) . Eredmeny eszlelheto, de meg nem az igazi.
Nalunk a legtobb novekedest az adta, amikor szetdobaltam kulon raid tombokre(amik kulon HDD-k voltak) a legtobbszor hasznalt tablakat. tora-val es "Varangyal" nezegettem stat-okat es figyelgettem melyik tablat hanyszor hasznaljak es milyen osszefuzesben a masikkal. Sajnos most itt vagyok 6db 9GB es 4db 36GBs SCSI-vel a gepben, ugy sivit mint egy Jumbo Jet :D
Mondjuk azt is hozza kell tennem, hogy irto sz@r a mi SCSI Raid vezerlonk, de legalabb qva dragan vette az elodom. :evil:
Az is igaz, hogy ez nem 9-es hanem meg 8.1.6/7.
Most nem emlekszem, de sokat szamitott, hogy 1+0 vagy 0+1-es atomb, de azt tudom hogy a raid5 semmit kozelukbe sem ert.
[quote:ef59449c94="profeta"]
...Mindezt a csodalatos oemapp console alkalmazassal.
Kb. ket oraja fut, 1-es load-ot general. Amugy az adatbazis el. Terheles nincs rajta, a ra csatlakozo alkalmazast leallitottam.
Mit lehet tenni ilyenkor? Elore mondom, az adatbazist leallitani nem lehetseges!
Legyszi, ha valakinek van _pontos_ infoja ossza meg, mert ebbol sulyos para lesz holnap...
Hi!
Remélem, most nem az én megkövezésem következik, mint aki rossz tanácsot adott... Egyrészt, az OEM egy vacak, ha lehet, ne használd, legalábbis pl paraméterváltoztatásra ne. Azért vannak a szép SQL parancsok, ott legalább tudod, mi történik előre láthatólag...
Másrészt, bár most hirtelen nem vágom, lehet, hogy mind dinamikus paraméter, de én akkor sem szoktam nagyon játszani a memóriaparaméterekkel menet közben, tehát általában [code:1:ef59449c94] ALTER SYSTEM SET pga_aggregate_target = 300M SCOPE = SPFILE;[/code:1:ef59449c94] jellegű parancsokkal babrálom az SPFILE-t, és utána biz újraindítom az adatbázist...
Sajna ez ezzel jár, de legalább tuti módszer. A tuningnál amúgy is fel kell készülnöd rá, hogy párszor újra kell indítanod a rendszert. Persze lehet csak bambán indexek gyártásával is operálni, de ez sokszor veszélyesebb, mint a paraméterek közt turkálni...
Harmadrészt, ez az 1-es load kicsit arra enged következtetni, mintha állandó swap alatt lenne a rendszer. Biztos, hogy nem lépted túl a fizikai memória korlátait?
Amúgy meg no para... :mrgreen:
[quote:35e3c3d8aa="cheeky"][quote:35e3c3d8aa="anr"]
Nem azzal van gond, hogy erteni kell hozza, hanme az informacio elerhetosegerol. Ha valami bajom van linux kernel/postgress/perl/... ugyben, akkor rakeresek a doksiban/kerem a google segitseget, es KAPOK valaszt. Az Oracle-vel kapszolatos keresesek minimalis/zero hasznalhato valaszt eredmenyeznek. Ez oriasi gond.
...
Ne viccelj már, kevés jobban dokumentált rendszert tudnék mondani, mint az Oracle, ráadásul mindez szabadon elérhető az http://otn.oracle.com-on, ingyenes regisztráció után. És ha netán azt mondanád, hogy oké, de mivel drága, nem tudod autodidakta módon megtanulni, ugyaninnen az Oracle összes termékét letöltheted, és fejlesztésre/tanulásra használhatod legálisan...
Mondj még egy nagy szoftverfejlesztőt, aki ennél jobban támogatja a termékei megismerését és a tanulást....
Azert kaptam en tobbszor is olyan Oracle hibat, amire az osszes dokumentacio annyi volt, hogy majd kesobbi verzioban dokumentaljak.
Na szerencsere megoldodott.
A konzolban (oracle-on belul) kilottem a tegnap este indult processzt.
Azert ez eleg ciki a piacvezeto adatbaziskezelotol nem?
Mi ez windows hogy allandoan ujra kell inditani?
Mindegy nem akarok flamelni, de baromira megijedtem.
Egyebkent azert nem lehet leallitani, mert ez egy failover cluster, ami ugy van osszedrotozva, es ha leallitanam, akkor egy masik gep atvenne az ip-jet.
Es amugy is szinkronizalva van az adatbazis arra a gepre, amiatt sem engedi egyszeruen leallitani.
Ja es persze nem en raktam ossze es nincs semmi doksi, kiserletezni meg nem merek vele. :-((
Anr, ha már dokumentálásnál tartunk nagyon tudom ajánlani ez a helyet:
http://metalink.oracle.com/
Ha oracle alapokon van rendszered tuti, hogy vásárolt rendszerről van szó, akkor pedig metalinken szinte minden problémát tudnak orvosolni, feltétel hogy regisztráld magad és legyen licenszed :)
A queryk optimalizálásán iszonyatosan sok múlik (tapasztalat, a rendszerünk elindulása után közel 1 évig elcseszett riportok optimalizálásán fáradoztam többek között)
Ehhez szakirodalomnak ajánlom az 'Oracle tervezés' című könyvet.
(szuverin vélemény: left join-t és like-ot én erősen kerülöm, képesek lassítani sokat, ez a select nekem olyan MSQL környezetből jövőnek tűnik.... :) )
Emellett az adatbázis fizikai fájljainak jó elhelyezése-elosztása a diszkeken is tud eredményt produkálni, nem ördöngősség, csak tudnod kell a géped felépítését és józan paraszti ésszel egy kis gondolkodással jó eredményt el lehet érni.
Viszont egy esetben nincs segítség: ha a gép a felhasználók számához fizikailag nagyon-nagyon alul van tervezve.... (Ez is tapasztalati út sajna...)
[quote:e406013ded="profeta"]Na szerencsere megoldodott.
A konzolban (oracle-on belul) kilottem a tegnap este indult processzt.
Azert ez eleg ciki a piacvezeto adatbaziskezelotol nem?
Mi ez windows hogy allandoan ujra kell inditani?
Mindegy nem akarok flamelni, de baromira megijedtem.
:) Leesett a kő a szívemről, legalább nem romlott el nagyon semmi.
A flame-ről annyit, hogy igen, ez egy piacvezető termék, de legalább csak egy beragadt processzt kellett kilőnöd... Próbálj egyszer segíteni egy MS SQL szerver beragadásán... Úgyhogy IMHO korrekt, hogy ha van is bibi, ennyivel meg lehet úszni.
A magyarázatod értem, ekkor viszont méginkább kérdéses, hogy milyen diszkleosztás van, egyrészt amiket már korábban kérdeztem, másrészt pedig hogy a két gép közt a diszkek is vándorolnak-e, és ha igen hogyan...
Meg persze hogy ez most akkor RAC, vagy vmi kézzel hackelt cluster?
Ha nagyon alultervezett a vas az optimalizálás akkor is eredményes, csak nem olyan átütően látványos a javulás (nálunk pl. vas csere után akkora volt az áttörés, hogy a felhasználók külön azért telefonáltak napokig délutánonként, hogy hálálkodjanak... bár előtte is lehetett dolgozni a rendszerrel, csak nem volt engedve riportok futtatása százassával... :lol: )
[quote:92013aa5dd="gmano"]Ha nagyon alultervezett a vas az optimalizálás akkor is eredményes, csak nem olyan átütően látványos a javulás (nálunk pl. vas csere után akkora volt az áttörés, hogy a felhasználók külön azért telefonáltak napokig délutánonként, hogy hálálkodjanak... bár előtte is lehetett dolgozni a rendszerrel, csak nem volt engedve riportok futtatása százassával... :lol: )
Tudsz mondani valamilyen kb vasakat es kb terehelest?
[quote:ac2b888072="mocsi"]
Tudsz mondani valamilyen kb vasakat es kb terehelest?
Mire? Ne viccelj már... Egy vacak lekérdezésből 3 is megfoghat egy kemény vasat is, egy jól kihangoltból meg 150 is elmegy egy 1 GHz-es procin jó válaszidővel...
Legalább valami támpontot, hogy végülis mire vagy kiváncsi... :mrgreen:
[quote:2996f61d99="gmano"]
A queryk optimalizálásán iszonyatosan sok múlik (tapasztalat, a rendszerünk elindulása után közel 1 évig elcseszett riportok optimalizálásán fáradoztam többek között)
Az a problema, hogy nekem nincs idom egy olyan query optimalizalasaval heteket szorakozni, amirol ranezesre latszik, hogy kellene vegrehajtani. A megfelelo indexeket persze rarakom.
Itt nem is optimalizalasrol van szo, hanem arrol, hogy probalom olyan formara hozni a query-t, amibol mar az idiota optimizernek is leesik, hogy mit kene csinalnia.
Amennyire lattam az a gond, hogy az oracle-ben nincs limit, emiatt subquery kell, az meg mar az optimalizalonak beteszi a kaput.
[quote:2996f61d99="gmano"]
(szuverin vélemény: left join-t és like-ot én erősen kerülöm, képesek lassítani sokat, ez a select nekem olyan MSQL környezetből jövőnek tűnik.... :) )
Nem tudom mibol gondolod ezt az MSQL kornyezet dolgot, de ha ez megnyugtat eletemben nem lattam olyat, es mint mar elobb szo volt rola a query-t program generalja, egy graf es megadott feltetelek alapjan.
Amugy persze, magyarazd el a usernek, hogy nem lehet csak pontos ertekre keresni, es a nagybetu nem egyenlo a kisbetuvel.
A left join meg ne lassitson mar, semmi nem indokolja. Hogy akarsz anelkul atmenni egy idegen kulcson, ha az nem kotelezo?
Ennyi erovel legjobb ha csak egy, de nem tul nagy tabla van a queryben, amin a sequential scan is gyors, es akkor az se baj ha az optimalizalo tokhulye.
[quote:2996f61d99="gmano"]
Viszont egy esetben nincs segítség: ha a gép a felhasználók számához fizikailag nagyon-nagyon alul van tervezve.... (Ez is tapasztalati út sajna...)
Mano
Ez pontosan igy van, csak nem lehet ugy tervezni, ha az ember elore azt sem tudja, milyen lekerdezesek varhatok milyen tablakon. Ehhez kell a tapasztalat, meg a felhasznalok hulye igenyeinek verbe fojtasahoz.
Kedvencem a szovegben keres opcio: az oszes mezore upper(mezo) like '%felteltel%' vaggyal osszekapcsolva.
Sajnos ezeket az ordas baromsagokat keszen kaptuk.
Osszefoglalva a fo bajom az oracle-el az optimizer benasaga, a szar dokumentacio, es a lehetetlen adminisztracios "eszkozok".
Pl. csak a query plan lekerese egy remalom.
[quote:21fbadf35b="cheeky"][quote:21fbadf35b="mocsi"]
Tudsz mondani valamilyen kb vasakat es kb terehelest?
Mire? Ne viccelj már... Egy vacak lekérdezésből 3 is megfoghat egy kemény vasat is, egy jól kihangoltból meg 150 is elmegy egy 1 GHz-es procin jó válaszidővel...
Legalább valami támpontot, hogy végülis mire vagy kiváncsi... :mrgreen:
Egy vacakbol egy is megfog egy gepet... eleg ha Java-ban rakod ossze a jo nagy PL/SQL keresorutint String konkatenacioval :) Tudnek rola meselni... :-)
[quote:18cf1dfb24="cheeky"][quote:18cf1dfb24="mocsi"]
Tudsz mondani valamilyen kb vasakat es kb terehelest?
Mire? Ne viccelj már... Egy vacak lekérdezésből 3 is megfoghat egy kemény vasat is, egy jól kihangoltból meg 150 is elmegy egy 1 GHz-es procin jó válaszidővel...
Legalább valami támpontot, hogy végülis mire vagy kiváncsi... :mrgreen:
A rohej az hogy itt van mogottem ket kibaszott Alpha irto dragan, osztan vettunk egy gepet IDE felulettel gyakorolgatni Alpha ara/100 Ft-ert, utolag meg kiderult, hogy egy db sima mirror IDE tomb 4x gyorsabb ugyanaz az a tranzakcio (tranzakciok, lekerdezesek stb), mint az agyonoptimalizalt (masok altal es altalam) Digital/Cpq/HP. Azota ruhellem a SCSI az ami jo mas nem. meg RISC, meg ne x86-ot oracle ala, meg faszomtudja milyen hiper tehnologia szoveget. Amikor ilyet hallok kereskedoktol legszivesebben pofan csapnam oket.
Szoval min futott, most min fog futni? Roviden, de ha sokat meselsz, akkor imadni foglak :D :twisted:
[quote:7285575a8c="profeta"]Na szerencsere megoldodott.
Azert ez eleg ciki a piacvezeto adatbaziskezelotol nem?
Mi ez windows hogy allandoan ujra kell inditani?
Az Oracle-nek mindig is eleg nagy hibaja volt az adminisztraciohoz szukseges pilotavizsga. A 10-es sorozattal viszont allitolag egesz kellemesen valtozott a helyzet, ez a legnagyobb elonye a 9-eshez kepest. Meg persze az allitolagos sebessegnovekedes.
Ár/teljesítmény arányban az x86 verhetetlen. Mégis, mit vártál?
Amúgy szerintem az használjon oracle-t, aki tényleg ért is hozzá. Aki épp most készül megtanulni, hogy optimizer meg explain, jobban jár egy mysql/innodb-el. Nem tud annyit, de meg lehet lenni vele, cserébe viszont eszméletlen gyors.
Ja, es az se veletlen, hogy az osszes nagygépárus annyira nyomja az opteront mostanaban. Teljesitmenyre osszevetheto a sajat meregdraga rendszereikkel, 64bites, es nagyon durvan olcso.
[quote:bb749c65e5="Finrod"]
Az Oracle-nek mindig is eleg nagy hibaja volt az adminisztraciohoz szukseges pilotavizsga. A 10-es sorozattal viszont allitolag egesz kellemesen valtozott a helyzet, ez a legnagyobb elonye a 9-eshez kepest. Meg persze az allitolagos sebessegnovekedes.
Az még sose volt gond, hogy valamihez érteni kellett ahhoz, hogy használhasd... Jobb az M$ féle hozzáálás, van 3 opció, ahhoz színes-szagos felület, aztán ha hangolni kell, akkor megáll az ész a vasnál?
Akkor inkább legyen 250 parancssorból állítható paraméterem, amik lehetőséget nyújtanak a dolog lelkébe való beletúrásra...
A 10g pedig nem csak elvileg gyorsabb, tipikusan egy web-es felületű tranzakciós rendszer ugyanazon a vason kb 20-30%-al teljesít jobban... Tapasztalat... Legalábis Linuxon.
Azért a komolyabb adatbázisok mind hasonlítanak az Oracle-re ebből a szempontból, lásd pl. DB2...
[quote:1b46ea8583="cheeky"][quote:1b46ea8583="Finrod"]
Az Oracle-nek mindig is eleg nagy hibaja volt az adminisztraciohoz szukseges pilotavizsga. A 10-es sorozattal viszont allitolag egesz kellemesen valtozott a helyzet, ez a legnagyobb elonye a 9-eshez kepest. Meg persze az allitolagos sebessegnovekedes.
Az még sose volt gond, hogy valamihez érteni kellett ahhoz, hogy használhasd... Jobb az M$ féle hozzáálás, van 3 opció, ahhoz színes-szagos felület, aztán ha hangolni kell, akkor megáll az ész a vasnál?
Akkor inkább legyen 250 parancssorból állítható paraméterem, amik lehetőséget nyújtanak a dolog lelkébe való beletúrásra...
A 10g pedig nem csak elvileg gyorsabb, tipikusan egy web-es felületű tranzakciós rendszer ugyanazon a vason kb 20-30%-al teljesít jobban... Tapasztalat... Legalábis Linuxon.
Azért a komolyabb adatbázisok mind hasonlítanak az Oracle-re ebből a szempontból, lásd pl. DB2...
Azert eleg kellemes dolog volt, mikor idonkent kozolte a rollback szegmensre hogy kevesli a meretet... magyarul azert kellett egy dba aki ugyelt a rendszerre... ez allitolag mar a multe a 10-es sorozattal, amig van winyo addig nem jatszik ilyesmit...
Meg ugye az ertes az eleg durva mennyisegu penzbe kerul, mert ugye autodidakta modon egy DBA szintre eleg nehez eljutni Oracleben. Az errol szolo oklevelrol meg ugye ne is beszeljunk.
[quote:cb2a90e453="hory"]Ár/teljesítmény arányban az x86 verhetetlen. Mégis, mit vártál?
Amúgy szerintem az használjon oracle-t, aki tényleg ért is hozzá. Aki épp most készül megtanulni, hogy optimizer meg explain, jobban jár egy mysql/innodb-el. Nem tud annyit, de meg lehet lenni vele, cserébe viszont eszméletlen gyors.
nem akarok flémet, de mysql-t soha... pgsql :D
jó teljesítmény, jó tudás, jó dokumentáció szvsz sokkaljobb mint a mysql
az oraclehez nem volt még szerencsém mélyebben... de valamiért nem is nagyon vágyom rá :)
[quote:786a462e48="cheeky"]
Az még sose volt gond, hogy valamihez érteni kellett ahhoz, hogy használhasd...
Nem azzal van gond, hogy erteni kell hozza, hanme az informacio elerhetosegerol. Ha valami bajom van linux kernel/postgress/perl/... ugyben, akkor rakeresek a doksiban/kerem a google segitseget, es KAPOK valaszt. Az Oracle-vel kapszolatos keresesek minimalis/zero hasznalhato valaszt eredmenyeznek. Ez oriasi gond.
Nem vagyok DBA, nem is akarok az lenni, de neha szukseges, hogy bizonyos reszproblemakban ertsem mi tortenik. Na ilyen esetekben a Postgres-nel megtalalom a segitseget Oracle-nel nem.
Ebbol annyi jon le, hogy Postgress-re dolgozni szeretek, az Oracle meg a pokolba kivanom.;)
No, egyesek nagyon rákaptak itt az Oracle fikázására, hát nem tudom, csak egyet tudok érteni horyval, az használja, aki ért is hozzá, de komolyan. Azért értő kezek között még mindig kenterbe veri bármelyik open source cuccot... Még a pgsql-t is, bár e tekintetben az áll hozzá legközelebb.
Ne nyissunk flame-et, nem azért írtam, hanem tapasztalatból.
Igaz, tapasztalat az is, hogy hogy lehet nagyon elrontani Oracle adatbázist, épp most került a kezem alá egy PC, duál 2.4 Xeon 2M, 6 diszk hw RAID, 2.5 giga memória, és a rátelepített Oracle adatbázist egy 1 giga memóriájú gépen 1 db ide diszken optimalizált Oracle-el meg lehet verni... Iszonyú blama, a szállító cégről lerí, hogy fingja nincs az Oracle-höz.
[quote:96be3a97b4="cheeky"]No, egyesek nagyon rákaptak itt az Oracle fikázására, hát nem tudom, csak egyet tudok érteni horyval, az használja, aki ért is hozzá, de komolyan. Azért értő kezek között még mindig kenterbe veri bármelyik open source cuccot... Még a pgsql-t is, bár e tekintetben az áll hozzá legközelebb.
Ne nyissunk flame-et, nem azért írtam, hanem tapasztalatból.
Igaz, tapasztalat az is, hogy hogy lehet nagyon elrontani Oracle adatbázist, épp most került a kezem alá egy PC, duál 2.4 Xeon 2M, 6 diszk hw RAID, 2.5 giga memória, és a rátelepített Oracle adatbázist egy 1 giga memóriájú gépen 1 db ide diszken optimalizált Oracle-el meg lehet verni... Iszonyú blama, a szállító cégről lerí, hogy fingja nincs az Oracle-höz.
Hat ja, a szallito cegnek kellett volna megfizetni egy DBA-t hogy installalja fel az adatbazist RENDESEN :-) Mondjuk 2 embernap :-)
[quote:ae1f1145a8="Finrod"]
Hat ja, a szallito cegnek kellett volna megfizetni egy DBA-t hogy installalja fel az adatbazist RENDESEN :-) Mondjuk 2 embernap :-)
Hát ja. Így most átvehetem így, aztán küzdhetek vele pár hétig menet közben, míg rájövök, hol, mit, és hogyan egyszerűsíthetek ki... :)
Gyanítom, a két szerver, amit vettek hozzá, simán fölösleges... Nem baj, előbb felszabadítom őket, aztán majd lesz jobb helyük :D
Visszatérve kicsit az eredeti problémához: anr, végülis jutottál valamire a cuccal, vagy inkább nem kísérletezel? :twisted:
[quote:8987f6b97e="Finrod"]
Hat ja, a szallito cegnek kellett volna megfizetni egy DBA-t hogy installalja fel az adatbazist RENDESEN :-) Mondjuk 2 embernap :-)
Szerintem ennyi nem eleg, mert az alkalmazas es terheles fuggvenyeben kell akar az adatbazisszerkezeten esetlegesen tobbszor optimalizalni.
A gond az a TCO. Agyonkepzett ember kell hozza, olyan szakmai gyakorlattal, amit doksibol nem igazan lehet megszerezni.
Az oracle lehet hogy sokat tud, de egy dinoszaurusz.
Ma mar egy szoftverrel szemben elvaras, hogy az elmeleti hatter ismerete mellett intuitiven meg lehessen ismerni es hasznalni.
Foleg ha egy iszonyu dragan mert szoftverrol beszelunk.
Egyebkent pedig nem tudom elhinni hogy annyira profin van megirva, ha pl. az sql szintaktikus elemzoje nem kepes egy normalis hibauzenetet adni. Latszik hogy akarki is irta , fogalma sem volt a forditoprogramokrol.
Lattam mar egypar projektet, amihez baromira nem kellett volna oracle, de a management megvette, mert akkor az o segguk vedve van, hiszen a piacvezeto termek nem lehet rossz.
[quote:cc689e1f41="cheeky"]
Visszatérve kicsit az eredeti problémához: anr, végülis jutottál valamire a cuccal, vagy inkább nem kísérletezel? :twisted:
A surgos problemat megoldotta, hogy az userek leszoktak nehany olyan keresesi feltetel hasznalatarol, amig a terheles nagyreszet okoztak, es valojaban nem is igazan volt ra szukseguk.
Kozeptavon meg ugy tunik kenytelen lesz valaki kozulunk Oracle DBA-va kepezni magat;-)
Legalabb annyira, hogy pontosabban tudjunk kerdezni.;)
Egyebkent bevalt a tuti gyors modszer.
Programobol karbantartott szamolt mezokkel kivegezni a problemas joinokat. Mivel minimalis insert/update van a select-ekhez kepest ez megcsinalhato.
Egy ideig kacerkodtunk, hogy kidobjuk az Oracle-t, es teszunk helyere postgress-t;))) (fejlesztoi laptopokon egesz normalis valaszidokat adott ugyanazzal az adatbazissal), de tobb het lenne, mire az ember biztonsaggal/korrekten megcsinal egy ekkora atallast.
[quote:56211177dc="profeta"][quote:56211177dc="Finrod"]
Hat ja, a szallito cegnek kellett volna megfizetni egy DBA-t hogy installalja fel az adatbazist RENDESEN :-) Mondjuk 2 embernap :-)
Szerintem ennyi nem eleg, mert az alkalmazas es terheles fuggvenyeben kell akar az adatbazisszerkezeten esetlegesen tobbszor optimalizalni.
Egy explain plan-el tudjon eljatszani a fejleszto is, vagy ne mondja magarol hogy ert az Oracle-hoz. A DBA-t arra ertettem, hogy a vasra feltelepiti az Oracle-t nagyjabol idealisan (hasznalja ki a hardver lehetosegeit).
[quote:56211177dc="profeta"]A gond az a TCO. Agyonkepzett ember kell hozza, olyan szakmai gyakorlattal, amit doksibol nem igazan lehet megszerezni.
Az oracle lehet hogy sokat tud, de egy dinoszaurusz.
Ma mar egy szoftverrel szemben elvaras, hogy az elmeleti hatter ismerete mellett intuitiven meg lehessen ismerni es hasznalni.
Foleg ha egy iszonyu dragan mert szoftverrol beszelunk.
Egy fejlesztovel meg relative gyorsan olcson meg lehet ismertetni azt amit neki tudni kell, tehat hogy egy rendesen beallitott adatbazison egy query vagy egy muvelet mitol gyors, mitol lassu, mikor mit csinal, mit nem szabad csinalni, stb. Innentol mar ugyis a fejleszto kreativitasan mulik, hogy ki tudja-e hasznalni a lehetosegeket.
Nem Oracle SQL-ben programozni kell megtanitani a fejlesztot, az ugyanis tul hosszu idobe telne, hanem az Oracle SQL motor mukodeset kell nagyjabol elmagyarazni neki.
Az adatbazisadmin, na az az ami sok penzbe kerul. Neki azt kell tudni, hogy ha ide ezt irok, oda azt, na akkor hirtelen ez meg az 10-szer gyorsabb lesz (az meg 2-szer lassabb), es ezeket ossze kell tudnia kombinalni egy idealis egyvelegge...
[quote:a1a7c3b431="Finrod"]
Egy explain plan-el tudjon eljatszani a fejleszto is, vagy ne mondja magarol hogy ert az Oracle-hoz. A DBA-t arra ertettem, hogy a vasra feltelepiti az Oracle-t nagyjabol idealisan (hasznalja ki a hardver lehetosegeit).
Hát ezaz, bakke, nem egy 4 lemezből álló RAID5 tömbre rakom az adatbázist, hanem beáldozok még egy lemeznyi kapacitást, és rakom 1+0-ba, aztán hadd röpüljön az az adatbázis! :) Agyrém, egyesek mire képesek... Vagy pl nem hagyom a memória 2/3-át üresen, inkább block_buffer-t csinálok belőle (oh, pardon, db_cache-t, változnak az idők... :wink: )
[quote:a1a7c3b431="Finrod"]
Az adatbazisadmin, na az az ami sok penzbe kerul. Neki azt kell tudni, hogy ha ide ezt irok, oda azt, na akkor hirtelen ez meg az 10-szer gyorsabb lesz (az meg 2-szer lassabb), es ezeket ossze kell tudnia kombinalni egy idealis egyvelegge...
De tudod milyen kellemesen meg lehet belőle élni? :mrgreen:
Viccet félretéve, igen, drága az ilyen ember. De azt se lehet vitatni, hogy megéri, ha egy utasítás, ami hozzányúlás előtt 23 mp volt, hozzányúlás után meg 0.48 mp... És nem index feldobálásával barom módon, mert azzal sokszor többet árt az ember, mint használ.
Az egyetlen probléma, hogy a fejlesztőcégeknél egyre kevesebb helyen fogadják el, hogy szükség van ilyen emberre, és inkább megoldják magasabb hw követelménnyel.
Így aztán a megrendelő vagy a vasért fizet többet, vagy alkalmaz ilyen tudású ember(eke)t, cégmérete válogatja, melyik az olcsób...
[quote:5f32079955="cheeky"][quote:5f32079955="Finrod"]
Egy explain plan-el tudjon eljatszani a fejleszto is, vagy ne mondja magarol hogy ert az Oracle-hoz. A DBA-t arra ertettem, hogy a vasra feltelepiti az Oracle-t nagyjabol idealisan (hasznalja ki a hardver lehetosegeit).
Hát ezaz, bakke, nem egy 4 lemezből álló RAID5 tömbre rakom az adatbázist, hanem beáldozok még egy lemeznyi kapacitást, és rakom 1+0-ba, aztán hadd röpüljön az az adatbázis! :) Agyrém, egyesek mire képesek... Vagy pl nem hagyom a memória 2/3-át üresen, inkább block_buffer-t csinálok belőle (oh, pardon, db_cache-t, változnak az idők... :wink: )
[quote:5f32079955="Finrod"]
Az adatbazisadmin, na az az ami sok penzbe kerul. Neki azt kell tudni, hogy ha ide ezt irok, oda azt, na akkor hirtelen ez meg az 10-szer gyorsabb lesz (az meg 2-szer lassabb), es ezeket ossze kell tudnia kombinalni egy idealis egyvelegge...
De tudod milyen kellemesen meg lehet belőle élni? :mrgreen:
Viccet félretéve, igen, drága az ilyen ember. De azt se lehet vitatni, hogy megéri, ha egy utasítás, ami hozzányúlás előtt 23 mp volt, hozzányúlás után meg 0.48 mp... És nem index feldobálásával barom módon, mert azzal sokszor többet árt az ember, mint használ.
Van benne valami... csak az a baj, hogy mas nem is tudja megfizetni, csak azok a cegek, akiknek ugyfeluk is van, akinek Oracle kell.
Igy az eleg valoszinutlen, hogy az ember sajat maga befizet ilyen tanfolyamra, akkor is ha jol meg lehet elni belole...
Na mindegy, ha sikerul megcsipni valami jo melot Angliaban, akkor lehet hogy beruhazok majd valami ilyesmire is...
[quote:6051f41244="hory"]Ár/teljesítmény arányban az x86 verhetetlen. Mégis, mit vártál?
Amúgy szerintem az használjon oracle-t, aki tényleg ért is hozzá. Aki épp most készül megtanulni, hogy optimizer meg explain, jobban jár egy mysql/innodb-el. Nem tud annyit, de meg lehet lenni vele, cserébe viszont eszméletlen gyors.
Amúgy szerintem az használjon oracle-t, aki tényleg ért is hozzá.
Oracle hasznalni es alapveto dolgokban relative egyszeru (szerintem).
En ezt ugy modositanam, hogy optimalizalni oracle-t csak az kezdjen el akinek mar van tapasztalata hasznalatbol, optimalizalasbol es tudja mi miert tortenik. Egy jol belott rendszer akar evekig el tud futni annelkul hogy a szokasos evenkenti/2 evenkenti import->drop->recreate-en kivul mas komolyabb beavatkozas nem kell.
A legtobb dba-nak adott egy (altalaban k. draga) kifejlesztett Adatbazis/forms/application/akarmiUI egyuttes amihez O hozza sem nyulhat megha megtalalja mekkora futyisegeket irtak a programozok, mert kulonben egy mashol mas miatt bekovetkezett hibat siman rakeni a fejleszto veg. Ez a proprietary license lenyege :D
[quote:f6d48c2cf1="anr"][quote:f6d48c2cf1="cheeky"]
Visszatérve kicsit az eredeti problémához: anr, végülis jutottál valamire a cuccal, vagy inkább nem kísérletezel? :twisted:
A surgos problemat megoldotta, hogy az userek leszoktak nehany olyan keresesi feltetel hasznalatarol, amig a terheles nagyreszet okoztak, es valojaban nem is igazan volt ra szukseguk.
Kozeptavon meg ugy tunik kenytelen lesz valaki kozulunk Oracle DBA-va kepezni magat;-)
Legalabb annyira, hogy pontosabban tudjunk kerdezni.;)
Egyebkent bevalt a tuti gyors modszer.
Programobol karbantartott szamolt mezokkel kivegezni a problemas joinokat. Mivel minimalis insert/update van a select-ekhez kepest ez megcsinalhato.
Egy ideig kacerkodtunk, hogy kidobjuk az Oracle-t, es teszunk helyere postgress-t;))) (fejlesztoi laptopokon egesz normalis valaszidokat adott ugyanazzal az adatbazissal), de tobb het lenne, mire az ember biztonsaggal/korrekten megcsinal egy ekkora atallast.
Sokkal jobb optimalizalast ertel volna el, ha mondjuk az osszes usert leszoktatod a munkarol :D
[quote:1e36ea6411="mocsi"]
Sokkal jobb optimalizalast ertel volna el, ha mondjuk az osszes usert leszoktatod a munkarol :D
Az userekkel nem az a gond, hogy dolgoznak, hanem az, hogy rendkivul erossen ragaszkodnak valami aprosaghoz. Soxor ezeket rendkivul nehez megcsinalni. Ha hajlando lenne az user egy picit mast csinalni, aminek az eredmenye teljesen ugyanaz lenne, akkor sokat egyszerusudnenek a dolgok.
Viszont az user fizet, es ezert kovetel, neha semilyen kompromisszumra sem hajlando.
Most a lassulas miatt olyan kovetelt featurerol modntak le, amirol elotte megeskudtek, hogy nelkule elkepzelhetetlen a munka.
Persze aki dolgozott mar fizetos ugyfellel az tudja, hogy lazan ellentmond onmaganak, es az ilyeneket nagyrutinnal probalja a fejlesztore kenni akar a penzel valo zsarolas aran is.
Ja meg: "a hibat ki kell javitani. Ez hiba, mert nincs benne" mondta az user egy bonyolult feature-t hianyolva.;)
A nagy cegek (pl: SAP) megtehetik, hogy rendkivul dragan dolgoznak, es ezzel tartjak az user igenyeit kordaban. A kis cegek nem tehetik meg. :(
[quote:d934661b86="mocsi"]A legtobb dba-nak adott egy (altalaban k. draga) kifejlesztett Adatbazis/forms/application/akarmiUI egyuttes amihez O hozza sem nyulhat megha megtalalja mekkora futyisegeket irtak a programozok, mert kulonben egy mashol mas miatt bekovetkezett hibat siman rakeni a fejleszto veg. Ez a proprietary license lenyege :D
Kellőképp agresszív dba kellőképp agresszív ügyfélként lép fel, és igenis a lassúság is hiba, ha indokolatlan, és jól látható tervezési hiányosságokból fakad. Ha a szállító akarja, megteszem neki azt a szívességet, hogy felderítem az ilyen típusú hibáit, de ha bebizonyítom, hogy vmi úgy jobb, akkor kutya kötelessége kijavítani a _hibát_.
Hát ez az én álláspontom azokkal a szállítókkal szemben, akik nem képesek, vagy inkább nem hajlandóak megfizetni egy szakembert ezért. Így legalább annyit költ el hibajavításra. Mondjuk nem is szeretnek nagyon a szállítók, de hát vessenek magukra... :twisted:
[quote:150868e2c5="mrbond"]nem akarok flémet, de mysql-t soha... pgsql :D
jó teljesítmény, jó tudás, jó dokumentáció szvsz sokkaljobb mint a mysql
az oraclehez nem volt még szerencsém mélyebben... de valamiért nem is nagyon vágyom rá :)
Gratulálok. Innováció a köbön.
Van egyáltalán fogalmad arról, hogy mit tud az innodb? :x
Az Oracle adatbázisunk terhelése kezdi kinőni a hardware-t. Pénz nincs, tehát optimalizálni kéne. Az egész egy Redhat AS-en fut onmagaban, semmi egyeb szolgaltatas. 1.5G memoria van a gepben, kb a teljes adatbazis belefer. A queryk rondak, es egyediek (nem optimalizalhatok)
A problemak:
-ha a redhat loadja 0.98-nal kisebb, gond nincs, ha 1.02-nel nagyobb akkor az Oracle valaszidok 8-10-szeresere emelkednek. Normalis ez igy?
-kimertuk, hogy ha 4 query fut parhuzamosan, akkor meg jok a valszidok, ha bejon az 5., vagy tovabbiak akkor _drasztikusan_ lecsokken az osszes valaszido. Be lehet valahogy allitani, hogy az 5. queryt el se kezdje megvalaszolni addig, amig nem vegzett eggyel az elozok kozul?
[quote:f23f17d6c0="anr"]Az Oracle adatbázisunk terhelése kezdi kinőni a hardware-t. Pénz nincs, tehát optimalizálni kéne. Az egész egy Redhat AS-en fut onmagaban, semmi egyeb szolgaltatas. 1.5G memoria van a gepben, kb a teljes adatbazis belefer. A queryk rondak, es egyediek (nem optimalizalhatok)
Mit jelent az, hogy rondák és nem optimalizálhatók? Kis ideje foglalkozom Oracle-lel, és az a tapasztalat, hogy mindig van mit optimalizálni... :D
Ha gondolod, privátban megbeszélhetjük, biztos van még min javítani...
Amit leírtál, arra is van tippem, de ehhez tudni kellene pár dolgot:
-Mennyi és milyen proci van a gépben (HT-s vagy sem)?
-Milyen diszkeken van az adatbázis?
-Dedikált szerver, vagy shared server (régebben Multi Threaded Server)?
-Adatbázis indítóparaméterek?
Hint: Az otodik query miatt (pl: nem fer mar bele a memoriaba) mas pl disk alapu vagy tobbmenetes algoritmust hasznal az oracle? Sasold meg es hasonlitsd ossze a query plan-eket amikor csak nehany van, ill amikor
bejon a degradacio.
[quote:ed32d567ae="cheeky"]
Amit leírtál, arra is van tippem, de ehhez tudni kellene pár dolgot:
-Mennyi és milyen proci van a gépben (HT-s vagy sem)?
-Milyen diszkeken van az adatbázis?
1 db proci.
model name : Intel(R) XEON(TM) CPU 2.00GHz
IBM ServerRAID kartya jo diszkekkel, de a kartyan bonnie-val mert IO teljesitmeny, hat nem a legjobb.
failover cluster-ben 2 gep. az oracle vmekkora kesessel csinal adatszinkront a ket gep kozott.
[quote:73471264a2="hory"][quote:73471264a2="mrbond"]nem akarok flémet, de mysql-t soha... pgsql :D
jó teljesítmény, jó tudás, jó dokumentáció szvsz sokkaljobb mint a mysql
az oraclehez nem volt még szerencsém mélyebben... de valamiért nem is nagyon vágyom rá :)
Gratulálok. Innováció a köbön.
Van egyáltalán fogalmad arról, hogy mit tud az innodb? :x
igen, mert olvasni tudok... nem is arról volt szó, hanem a mysql-ról.
az innodb azért került bele mert quotoltam...
amit tudok az az, hogy amit eddig meg kellett csinálnom azt a pgsqllel mindent megtudtam...nem volt szügségem sem innodb-re, sem oraclere. ezzel szemben a munkám során már futottam olyanba bele, amit a mysql nem tud(ott).
szvsz manapság az nem nevezheti magát adatbáziskezelőnek aki sem tranzakciót (ez a legalapabb...) sem triggert, sem stb nem tud.
uff! vallás háborút akarsz :) menjünk át a flémes topikba. láttam már régebben pgsql vs mysql topikot ami betonkeverőben végezte :twisted:
[quote:99b2820770="cheeky"]
Mit jelent az, hogy rondák és nem optimalizálhatók? Kis ideje foglalkozom Oracle-lel, és az a tapasztalat, hogy mindig van mit optimalizálni... :D
-Adatbázis indítóparaméterek?
a query-k a userek kattintgatasai alakitjak ki, gyakorlatilag nincs ket egyforma query. van egy query szerverunk, ami a beallitasok alapjan legyartja az SQL-t ez a query gyarto algoritmus mar agyon van optimalizalva. Ezzel kezdtuk;) Itt nem hiszem, hogy sokat tudnak okosodni;))
Ime egy ronda query, nem ez a legrondabb, csak hirtelen ezt talaltam;)
A postgres gyengebb vason ugyanolyan gyorsan hajtja vegre.
[code:1:99b2820770]
SELECT * FROM (
SELECT ROWNUM AS ROWNUM1, ROWNUM3.* FROM (
SELECT
Entity8950046.OID AS OID , Entity8950046.fk_Adatgazda AS Id9410,
Entity8950046.Szallitoi_megnevezes AS Id9417, Entity8950046.fk_Utolso_modosito AS Id9416,
Entity8950046.Szallitoi_cikkszam AS Id9404, Entity8950046.Statusz AS Id9400,
Entity10170046.XML_Generalas_ideje AS Id11147, Entity10170046.fk_Szervezet AS Id11148,
Entity10170046.Elso_akt_idopontja AS Id11149, Entity10090046.Nev AS Id11058,
Entity10140046.Cikkszam AS Id11132, Entity10140046.Nyilvantartasi_nev AS Id11122,
Entity10140046.fk_Tree_order AS Id11142, Entity10140046.GTIN_eklista AS Id11123,
Entity10070046.fk_HSZ_azonosito AS Id11054, Entity10170046.OID AS DELEGATION_OID,
Entity10170046.Statusz AS DELEGATION_STATUSZ
FROM
Szallito___aru_viszony Entity8950046
LEFT JOIN Szallito___aru_viszo_D Entity10170046
ON Entity8950046.OID = Entity10170046.fk_Application_OID
AND Entity10170046.fk_Szervezet='1000430'
LEFT JOIN Partner Entity10090046
ON Entity10090046.OID = Entity8950046.fk_Szallito_azonosito_OID
LEFT JOIN Partner Entity12600046
ON Entity12600046.OID = Entity8950046.fk_Adatgazda_OID
LEFT JOIN Cikk Entity10140046
ON Entity10140046.OID = Entity8950046.fk_Cikkszam_OID
LEFT JOIN Cikk Entity10120046
ON Entity10120046.OID = Entity10140046.fk_Tapadogongyoleg_OID
LEFT JOIN Cikk_regi_azonosito_MN Entity10070046
ON Entity10140046.OID = Entity10070046.fk_Cikk_uj_azonosito_OID
AND Entity10070046.fk_HSZ_azonosito='1000430'
LEFT JOIN COOP_cikkcsoport Entity10130046
ON Entity10130046.OID = Entity10140046.fk_Tree_order_OID
LEFT JOIN Kisker__jovedekicsoport Entity10100046
ON Entity10100046.OID = Entity10140046.fk_Kisker__jov_csop_OID
WHERE
UPPER( Entity10140046.Cikkszam) LIKE UPPER('1026864%')
ORDER BY Entity10140046.Cikkszam DESC) ROWNUM3
WHERE
ROWNUM <= 100 ) ROWNUM2
WHERE
ROWNUM1 >= 1
[/code:1:99b2820770]
[quote:320d497fe3="mocsi"]Oracle hasznalni es alapveto dolgokban relative egyszeru (szerintem). En ezt ugy modositanam, hogy optimalizalni oracle-t csak az kezdjen el akinek mar van tapasztalata hasznalatbol, optimalizalasbol es tudja mi miert tortenik.
Persze, csak epp ha nem tudod optimalizalni, akkor a teljesitmenye bizony harmatgyenge mar egy psql-hez kepest is. Innodb meg egyszeruen szarra veri.
De azert szemezgetek vele, mert a particiok, bitmap es funkcionalis indexek meg az oracle jvm elegge brutalis teljesitmenytobbletet tudnak adni. Es ezeken kivul meg annyi kis szirszar feature-e van, amivel gyorsitani lehet az adatbazist, hogy ihaj.
Szoval jo az, csak kifejezetten user-taszito (doksi+admin feluletetek), meg szerintem el is van bonyolitva. Valahogy olyan erzesem van, mintha ugyanazt ganyolnak mar tizenX eve...
[quote:54fe2fa3dd="mrbond"]igen, mert olvasni tudok... nem is arról volt szó, hanem a mysql-ról. az innodb azért került bele mert quotoltam...
mysql/innodb-tol volt szo.
amit tudok az az, hogy amit eddig meg kellett csinálnom azt a pgsqllel mindent megtudtam...nem volt szügségem sem innodb-re, sem oraclere. ezzel szemben a munkám során már futottam olyanba bele, amit a mysql nem tud(ott).
szvsz manapság az nem nevezheti magát adatbáziskezelőnek aki sem tranzakciót (ez a legalapabb...) sem triggert, sem stb nem tud.
Ezert mondtam, hogy fingod sincs rola. Annyit kellett volna tenned, hogy elkukkantasz az innodb.com -ra, es a lap tetejen ott van nagy betukkel, hogy "transactions, row-level locking, hot backup and foreign keys for mysql".
De ott van a berkeleyDB storage engine is a mysql-hez - az is tud tranzakciokat, es gyanithatolag az a leggyorsabb.
Ez nem vallashaboru, hanem tudatlansag-ellenes haboru. Sokan becsmerlik, kevesen tudjak egyaltalan, hogy mi fan terem...
[quote:7d47d0b9e9="hory"]
Ezert mondtam, hogy fingod sincs rola. Annyit kellett volna tenned, hogy elkukkantasz az innodb.com -ra, es a lap tetejen ott van nagy betukkel, hogy "transactions, row-level locking, hot backup and foreign keys for mysql".
De ott van a berkeleyDB storage engine is a mysql-hez - az is tud tranzakciokat, es gyanithatolag az a leggyorsabb.
Ez nem vallashaboru, hanem tudatlansag-ellenes haboru. Sokan becsmerlik, kevesen tudjak egyaltalan, hogy mi fan terem...
Na akkor ennyit a vallásháborúról... Szép dolog a row level locking, meg az online backup, de könyörgöm, akkor aki eddig itt fikázta az Oracle-t, az mondja már meg, melyik csodás open source db-ben van row level security, advanced queuing, procedural gateway, stored procedure, two-phase commit, autonomous transactions, replikáció, meg még egy rakat feature egyszerre? Márpedig ha valaki _rendszerben_ gondolkodik, és nem világtól elzárt alkalmazást ír, akkor bizony ezekre együtt van szüksége. Egy rendszer attól integrált rendszer, hogy átrántja az alapadatokat a vállalatirányító szoftverből, az ügyféladatokat a közös ügyféltörzsből, a számlaadatokat számlavezető rendszerből, az aktuális kondíciókat a scoring rendszerből, és a végén nyit egy hitelkártyaszámlát a kártyarendszerben (most lehet, hogy hülye példa volt, de a lényeg a szemléltetés... :roll: ). És ezek közül az egyik DB2/AS400, a másik Oracle/Windows, a harmadik Informix/Solaris, a negyedik esetleg Linux, és mégis minden működik, mert közéteszel mondjuk egy MQSeries-t, és az egész gyötrődés az adatbázis elől szépen el van rejtve.
Egy szó, mint száz, szép-szép az open source db, elszigetelt kisalkalmazásokra csodálatos is, de ha integrációról van szó egy erősen heterogén környezetben, akkor sajnos még sehol sincs. De drukkolok, hogy egyszer odaérjen, félreértés ne essék, csak addig viszont nem szeretem, ha valaki fröcsögve lefikázza azt, amiről ezek szerint gőze sincs.
Na akkor ennyit a vallásháborúról... Szép dolog a row level locking, meg az online backup, de könyörgöm, akkor aki eddig itt fikázta az Oracle-t, az mondja már meg, melyik csodás open source db-ben van
row level security,
ez egy jo cuccos lenne, csak akkor az adatbazissal kene az authentikaciot vegeztetni (vagy tud ldap-bol authentikalni az Oracle?)
advanced queuing, procedural gateway,
Ez mit is takar?
stored procedure,
Nezzuk csak... postgres biztos, es asszem a mysql5 es a firebird is...
two-phase commit,
Szerintem postgres tudja, firebird is valoszinuleg...
autonomous transactions,
postgres valszinuleg, tobbit nem tudom
replikáció,
postgres, mysql5, tobbit nem tudom
meg még egy rakat feature egyszerre? Márpedig ha valaki _rendszerben_ gondolkodik, és nem világtól elzárt alkalmazást ír, akkor bizony ezekre együtt van szüksége. Egy rendszer attól integrált rendszer, hogy átrántja az alapadatokat a vállalatirányító szoftverből, az ügyféladatokat a közös ügyféltörzsből, a számlaadatokat számlavezető rendszerből, az aktuális kondíciókat a scoring rendszerből, és a végén nyit egy hitelkártyaszámlát a kártyarendszerben (most lehet, hogy hülye példa volt, de a lényeg a szemléltetés... :roll: ). És ezek közül az egyik DB2/AS400, a másik Oracle/Windows, a harmadik Informix/Solaris, a negyedik esetleg Linux, és mégis minden működik, mert közéteszel mondjuk egy MQSeries-t, és az egész gyötrődés az adatbázis elől szépen el van rejtve.
Egy szó, mint száz, szép-szép az open source db, elszigetelt kisalkalmazásokra csodálatos is, de ha integrációról van szó egy erősen heterogén környezetben, akkor sajnos még sehol sincs. De drukkolok, hogy egyszer odaérjen, félreértés ne essék, csak addig viszont nem szeretem, ha valaki fröcsögve lefikázza azt, amiről ezek szerint gőze sincs.
Ilyen rendszereknel altalaban van penz Oracle-re jo eros supporttal, es ez szokott lenni a fo ok... ne erts felre, en is az Oracle-t partolom minden nagyobb rendszerbe, de azert az open source cuccokat se fikazzuk, ha nem vagyunk tisztaban a kepessegeikkel... Altalaban nem a kepessegeikkel szokott gond lenni, hanem hogy meg nem bizonyitottak nagy kornyezetben, akkor sem, ha tudnak amire szukseg van...
Es nincs mindenhol szukseg a felsorolt feature-okre, mert nem mindenhol kell sok rendszer koze integralni az ujat... bar ketsegtelen hogy ezekkel lehet jol keresni, csak az ilyen munkahoz hozza is kell jutni :-)
Ha mar langolunk, akkor azert egy beloginolas idejet is meg kellene nezni. Mire az Oracle mindenfele vm-et, mem pool-t, roll back instance-t stb hozzarendel egy loginhoz eleg sok ido el tud telni...
[quote:4f1781967f="mocsi"]Ha mar langolunk, akkor azert egy beloginolas idejet is meg kellene nezni. Mire az Oracle mindenfele vm-et, mem pool-t, roll back instance-t stb hozzarendel egy loginhoz eleg sok ido el tud telni...
Akkor sorjában, legalább tanulunk egymástól, ezt már szeretem... :P
[quote:ce7f746142="Finrod"]
Na akkor ennyit a vallásháborúról... Szép dolog a row level locking, meg az online backup, de könyörgöm, akkor aki eddig itt fikázta az Oracle-t, az mondja már meg, melyik csodás open source db-ben van
row level security,
ez egy jo cuccos lenne, csak akkor az adatbazissal kene az authentikaciot vegeztetni (vagy tud ldap-bol authentikalni az Oracle?)
Nos, tud. Van egy ún. Oracle Internet Directory, ami tulajdonképp egy Oracle féle LDAP implementáció. Mielőtt azt mondanád, hogy okés, de akkor ez nem LDAP, elmondom, hogy van benne egy piszkos kis trükk, és a benne nyilvántartott objektum authentikációját le tudod cserélni gyakorlatilag BÁRMIRE, amit meg tudsz írni Java-ban. Persze van mód az authentikációs kérés egyszerű továbblökésére egy másik LDAP felé, nyilván ez a legegyszerűbb...
[quote:ce7f746142="Finrod"]
advanced queuing, procedural gateway,
Ez mit is takar?
AQ: message queue az adatbázisban, aszinkron üzenetküldés adatbázison belül, vagy több távoli adatbázis között.
PG: például az előzőt fejeli meg annyival, hogy az alkalmazásod módosítása nélkül kicserélheted alatta a queue-t egy MQSeriesben definiált queue-ra, ami innentől értelemszerűen nem csak Oracle adatbázissal tarthat kapcsolatot a túlvégen.
[quote:ce7f746142="Finrod"]
stored procedure,
Nezzuk csak... postgres biztos, es asszem a mysql5 es a firebird is...
Okés, ezt elismerem, ezért írtam, hogy együtt ezek a feature-ök. Mondjuk nem tudom, a fentiek hogy állnak pl a session triggerekkel, azért az is egy érdekes terület.
[quote:ce7f746142="Finrod"]
two-phase commit,
Szerintem postgres tudja, firebird is valoszinuleg...
Erről tényleg nem tudtam, de örülök neki... :)
[quote:ce7f746142="Finrod"]
autonomous transactions,
postgres valszinuleg, tobbit nem tudom
Igen, a többi ha jól tudom még nem.
[quote:ce7f746142="Finrod"]
replikáció,
postgres, mysql5, tobbit nem tudom
Oda-vissza, több master-több slave viszonylatban? Ezt azért kétlem, különösen, hogy annyira bonyolult, hogy az Oracle implementációja is távol áll a tökéletestől... :D
[quote:ce7f746142="Finrod"]
Ilyen rendszereknel altalaban van penz Oracle-re jo eros supporttal, es ez szokott lenni a fo ok... ne erts felre, en is az Oracle-t partolom minden nagyobb rendszerbe, de azert az open source cuccokat se fikazzuk, ha nem vagyunk tisztaban a kepessegeikkel... Altalaban nem a kepessegeikkel szokott gond lenni, hanem hogy meg nem bizonyitottak nagy kornyezetben, akkor sem, ha tudnak amire szukseg van...
Es nincs mindenhol szukseg a felsorolt feature-okre, mert nem mindenhol kell sok rendszer koze integralni az ujat... bar ketsegtelen hogy ezekkel lehet jol keresni, csak az ilyen munkahoz hozza is kell jutni :-)
Ez utóbbival csak egyetérteni tudok, de hidd el, elhivatottsággal és érdeklődéssel nem is olyan nehéz ilyen munkát találni.
És bocsánat, ha úgy tűnt volna, hogy fikkantom az open source cuccokat, nem erről van szó, csak szerettem volna rávilágítani, mi az, amiben még nagyon messze járnak. Ettől függetlenül már most is nagyon sok mindenre alkalmasak, ezt elismerem.
[quote:d545c78f88="anr"]
1 db proci.
model name : Intel(R) XEON(TM) CPU 2.00GHz
IBM ServerRAID kartya jo diszkekkel, de a kartyan bonnie-val mert IO teljesitmeny, hat nem a legjobb.
failover cluster-ben 2 gep. az oracle vmekkora kesessel csinal adatszinkront a ket gep kozott.
Az 1 db proci HyperThreading? (/proc/cpuinfo két procit mutat?)
A RAID tömb, amin az adatfileok vannak, hogy van konfigurálva? Minimum tükör javallott, de méginkább RAID 1+0... Az adja messze a legjobb IO teljesítményt, még írás esetén is, bár ahogy írtad, valószínűleg elszősorban olvasásról van szó.
Ellenben remélem, az archív log nem ugyanarra a volume-ra megy, mint ahol az adatfileok vannak... Akkor már az a volume is jobb, amin az Oracle software van...
[quote:9216d5571b="cheeky"]
[quote:9216d5571b="Finrod"]
Es nincs mindenhol szukseg a felsorolt feature-okre, mert nem mindenhol kell sok rendszer koze integralni az ujat... bar ketsegtelen hogy ezekkel lehet jol keresni, csak az ilyen munkahoz hozza is kell jutni :-)
Ez utóbbival csak egyetérteni tudok, de hidd el, elhivatottsággal és érdeklődéssel nem is olyan nehéz ilyen munkát találni.
Na ez kicsit felreertheto lett, munka alatt itt nem allast, hanem megrendelest ertettem :-)
[quote:c2224145f8="anr"]
a query-k a userek kattintgatasai alakitjak ki, gyakorlatilag nincs ket egyforma query. van egy query szerverunk, ami a beallitasok alapjan legyartja az SQL-t ez a query gyarto algoritmus mar agyon van optimalizalva. Ezzel kezdtuk;) Itt nem hiszem, hogy sokat tudnak okosodni;))
Ime egy ronda query, nem ez a legrondabb, csak hirtelen ezt talaltam;)
A postgres gyengebb vason ugyanolyan gyorsan hajtja vegre.
Wow. Hát egy dologban abszolút igazad volt, ez ténlyeg undorító... :?
Viszont a paraméterek elég ellentmondásosnak tűnnek számomra, most akkor ez Shared Server, amire a dispatchers utal, vagy dedicated?
Esetleg Shared volt, de később visszavettétek? Akkor viszont gyomlálni kellene.
Ugyanígy érdekes a sort_area_size használata, amit teljességgel kiüt a nyeregből a pga_aggregate_target. Amúgy is elég alacsony lenne az érték, ennél azért 150-es processes-nél bátrabban is lehetne adni, úgy másfél-két megát legalább. De így mindegy is. Viszont azt mondtad, az adatbázis gyakorlatilag elférne a memóriában, ehhez képest azért a pga_aggregate_target lehetne magasabb is, jót tesz. Sokszor csodát. Ha sakkozni kell, akkor is elvennék 64-100 megát az Shared Pool-tól, és elosztanám a pga_aggregate_target és a db_cache_size között. Sőt, cache-t még többet is allokálnék, ha egszer fizikailag elérhető. Ahogy néztem, kb 1 gigát használ a db, azt mondtad, másfél van, hát használjuk... Kell még legyen kb 300-400 szabadon...
Így hirtelen ennyi, de lehet, hogy átdobhatnád levélben a komplett paraméterlistát sql-ből lekérdezve, egyértelműbb lenne... Persze a path-okat meg egyéb érzékeny infókat strip-elheted, nem arra vagyok kíváncsi... :)
[quote:ccaf8472fe="anr"]Hamar Oracle, most futottunk bele:
Oracleban tenyleg nem lehet 1000-nel tobb elem az " IN (A,B,C,...)"-ben?
most eppen 1044 kene;)
Konnyen elkepzelheto. Kerulo megoldas:
1. Csinalsz egy tablat ilyesmi celokra, temporary result set-eknek, lehetoleg memoriaban. Ket oszlop, egyik egy resultset_id, masik a value amit felsorolnal.
2. Beleinsertalod az in-ben levo ertekeket azonos resultset_id-val.
3. Rajoinolsz a tablara ertelemszeruen (resultset_id-ra szursz, a value-kra joinolsz).
[quote:dd849d55e4="anr"]Hamar Oracle, most futottunk bele:
Oracleban tenyleg nem lehet 1000-nel tobb elem az " IN (A,B,C,...)"-ben?
most eppen 1044 kene;)
Ha jól értem, literálisokra gondolsz.
Konkrétan ilyen limitáció nincs, legalábbis nem tudok róla, de az adatbázislimitációk közt szerepel egy ezres szám, mégpedig az oszlopok maximális száma egy táblában, valószínű, hogy ezzel van valahogy összefüggésben... Tényleg érdemes kirakni egy táblába ilyenkor, teljesítményre is jobb lesz, ráadásul kis gondolkodással valszeg ki tudod fordítani az IN-t EXISTS-es subquery-re, aminek általában sokkal jobb a futásideje... :)
a query-k a userek kattintgatasai alakitjak ki, gyakorlatilag nincs ket egyforma query. van egy query szerverunk, ami a beallitasok alapjan legyartja az SQL-t ez a query gyarto algoritmus mar agyon van optimalizalva. Ezzel kezdtuk;) Itt nem hiszem, hogy sokat tudnak okosodni;))
Ime egy ronda query, nem ez a legrondabb, csak hirtelen ezt talaltam;)
A postgres gyengebb vason ugyanolyan gyorsan hajtja vegre.
[code:1:ddf9700938]
SELECT * FROM (
SELECT ROWNUM AS ROWNUM1, ROWNUM3.* FROM (
SELECT
Entity8950046.OID AS OID , Entity8950046.fk_Adatgazda AS Id9410,
Entity8950046.Szallitoi_megnevezes AS Id9417, Entity8950046.fk_Utolso_modosito AS Id9416,
Entity8950046.Szallitoi_cikkszam AS Id9404, Entity8950046.Statusz AS Id9400,
Entity10170046.XML_Generalas_ideje AS Id11147, Entity10170046.fk_Szervezet AS Id11148,
Entity10170046.Elso_akt_idopontja AS Id11149, Entity10090046.Nev AS Id11058,
Entity10140046.Cikkszam AS Id11132, Entity10140046.Nyilvantartasi_nev AS Id11122,
Entity10140046.fk_Tree_order AS Id11142, Entity10140046.GTIN_eklista AS Id11123,
Entity10070046.fk_HSZ_azonosito AS Id11054, Entity10170046.OID AS DELEGATION_OID,
Entity10170046.Statusz AS DELEGATION_STATUSZ
FROM
Szallito___aru_viszony Entity8950046
LEFT JOIN Szallito___aru_viszo_D Entity10170046
ON Entity8950046.OID = Entity10170046.fk_Application_OID
AND Entity10170046.fk_Szervezet='1000430'
LEFT JOIN Partner Entity10090046
ON Entity10090046.OID = Entity8950046.fk_Szallito_azonosito_OID
LEFT JOIN Partner Entity12600046
ON Entity12600046.OID = Entity8950046.fk_Adatgazda_OID
LEFT JOIN Cikk Entity10140046
ON Entity10140046.OID = Entity8950046.fk_Cikkszam_OID
LEFT JOIN Cikk Entity10120046
ON Entity10120046.OID = Entity10140046.fk_Tapadogongyoleg_OID
LEFT JOIN Cikk_regi_azonosito_MN Entity10070046
ON Entity10140046.OID = Entity10070046.fk_Cikk_uj_azonosito_OID
AND Entity10070046.fk_HSZ_azonosito='1000430'
LEFT JOIN COOP_cikkcsoport Entity10130046
ON Entity10130046.OID = Entity10140046.fk_Tree_order_OID
LEFT JOIN Kisker__jovedekicsoport Entity10100046
ON Entity10100046.OID = Entity10140046.fk_Kisker__jov_csop_OID
WHERE
UPPER( Entity10140046.Cikkszam) -- ez itt csak functional index-el indexelheto
LIKE UPPER('1026864%')
ORDER BY Entity10140046.Cikkszam DESC) ROWNUM3
WHERE
ROWNUM <= 100 ) ROWNUM2
WHERE
ROWNUM1 >= 1
[/code:1:ddf9700938]
Hat ezen bizony azert lehet mit optimalizalni:
Az osszes olyan hely, ahol adatbazisbol jon az upper fuggveny bemenete, optimalizalhato ket modon:
- functional index felvetele a kerdeses mezore (itt pl. a cikkszam a cikk tablaban)
vagy functional index hianyaban
- egy plusz oszlop felvetele a tablaban ahol az upper-re konvertalt erteket tarolod a cikkszam-nak, vagy az iro kodbol beallitva, vagy triggerbol generalva az upperes mezo erteket, es ezt a mezot indexeled, esetleg mas mezoket is beleteve az indexbe, pl. itt az OID.
Az order by-ba itt nyugodtan teheted ezutan az upper-elt mezot.
Ezutan a szureshez fog index-t hasznalni, eddig pedig nem onnan szedte (kiveve volt functional index az upper(cikkszam)-ra a cikk tablan).
Persze nem arthat plusz oszlopokat beletenni az index-be.
Mindenesetre celszeru explain plan-t nyomogatni egy-egy ilyen query-re is, hogy lassad tenylegesen mit is csinal. Akkor is tanulsagos, ha nem jellemzo a query.
Szoval. Megfogadvan az elottem szolo tanacsat, megprobaltam kicsit varialni a shared pool es a masik ket memoriaparameter ertekevel.
A shared pool-t 300M-rol megprobaltam 200-ra csokkenteni, a masik kettot meg 50-50-el novelni.
Mindezt a csodalatos oemapp console alkalmazassal.
Kb. ket oraja fut, 1-es load-ot general. Amugy az adatbazis el. Terheles nincs rajta, a ra csatlakozo alkalmazast leallitottam.
Mit lehet tenni ilyenkor? Elore mondom, az adatbazist leallitani nem lehetseges!
Legyszi, ha valakinek van _pontos_ infoja ossza meg, mert ebbol sulyos para lesz holnap.
Hozzászólások
[quote:42c3ddb241="anr"]
Nem azzal van gond, hogy erteni kell hozza, hanme az informacio elerhetosegerol. Ha valami bajom van linux kernel/postgress/perl/... ugyben, akkor rakeresek a doksiban/kerem a google segitseget, es KAPOK valaszt. Az Oracle-vel kapszolatos keresesek minimalis/zero hasznalhato valaszt eredmenyeznek. Ez oriasi gond.
...
Ne viccelj már, kevés jobban dokumentált rendszert tudnék mondani, mint az Oracle, ráadásul mindez szabadon elérhető az http://otn.oracle.com-on, ingyenes regisztráció után. És ha netán azt mondanád, hogy oké, de mivel drága, nem tudod autodidakta módon megtanulni, ugyaninnen az Oracle összes termékét letöltheted, és fejlesztésre/tanulásra használhatod legálisan...
Mondj még egy nagy szoftverfejlesztőt, aki ennél jobban támogatja a termékei megismerését és a tanulást....
Mi regebben rengeteget tokoresztunk az opitmalizalassal, mert irto lassu volt a rendszer, meg valami profi monitorozo program is futott ami alapjan indexelesi roham volt mind a 20xx tablara ;) . Eredmeny eszlelheto, de meg nem az igazi.
Nalunk a legtobb novekedest az adta, amikor szetdobaltam kulon raid tombokre(amik kulon HDD-k voltak) a legtobbszor hasznalt tablakat. tora-val es "Varangyal" nezegettem stat-okat es figyelgettem melyik tablat hanyszor hasznaljak es milyen osszefuzesben a masikkal. Sajnos most itt vagyok 6db 9GB es 4db 36GBs SCSI-vel a gepben, ugy sivit mint egy Jumbo Jet :D
Mondjuk azt is hozza kell tennem, hogy irto sz@r a mi SCSI Raid vezerlonk, de legalabb qva dragan vette az elodom. :evil:
Az is igaz, hogy ez nem 9-es hanem meg 8.1.6/7.
Most nem emlekszem, de sokat szamitott, hogy 1+0 vagy 0+1-es atomb, de azt tudom hogy a raid5 semmit kozelukbe sem ert.
[quote:ef59449c94="profeta"]
...Mindezt a csodalatos oemapp console alkalmazassal.
Kb. ket oraja fut, 1-es load-ot general. Amugy az adatbazis el. Terheles nincs rajta, a ra csatlakozo alkalmazast leallitottam.
Mit lehet tenni ilyenkor? Elore mondom, az adatbazist leallitani nem lehetseges!
Legyszi, ha valakinek van _pontos_ infoja ossza meg, mert ebbol sulyos para lesz holnap...
Hi!
Remélem, most nem az én megkövezésem következik, mint aki rossz tanácsot adott... Egyrészt, az OEM egy vacak, ha lehet, ne használd, legalábbis pl paraméterváltoztatásra ne. Azért vannak a szép SQL parancsok, ott legalább tudod, mi történik előre láthatólag...
Másrészt, bár most hirtelen nem vágom, lehet, hogy mind dinamikus paraméter, de én akkor sem szoktam nagyon játszani a memóriaparaméterekkel menet közben, tehát általában [code:1:ef59449c94] ALTER SYSTEM SET pga_aggregate_target = 300M SCOPE = SPFILE;[/code:1:ef59449c94] jellegű parancsokkal babrálom az SPFILE-t, és utána biz újraindítom az adatbázist...
Sajna ez ezzel jár, de legalább tuti módszer. A tuningnál amúgy is fel kell készülnöd rá, hogy párszor újra kell indítanod a rendszert. Persze lehet csak bambán indexek gyártásával is operálni, de ez sokszor veszélyesebb, mint a paraméterek közt turkálni...
Harmadrészt, ez az 1-es load kicsit arra enged következtetni, mintha állandó swap alatt lenne a rendszer. Biztos, hogy nem lépted túl a fizikai memória korlátait?
Amúgy meg no para... :mrgreen:
[quote:35e3c3d8aa="cheeky"][quote:35e3c3d8aa="anr"]
Nem azzal van gond, hogy erteni kell hozza, hanme az informacio elerhetosegerol. Ha valami bajom van linux kernel/postgress/perl/... ugyben, akkor rakeresek a doksiban/kerem a google segitseget, es KAPOK valaszt. Az Oracle-vel kapszolatos keresesek minimalis/zero hasznalhato valaszt eredmenyeznek. Ez oriasi gond.
...
Ne viccelj már, kevés jobban dokumentált rendszert tudnék mondani, mint az Oracle, ráadásul mindez szabadon elérhető az http://otn.oracle.com-on, ingyenes regisztráció után. És ha netán azt mondanád, hogy oké, de mivel drága, nem tudod autodidakta módon megtanulni, ugyaninnen az Oracle összes termékét letöltheted, és fejlesztésre/tanulásra használhatod legálisan...
Mondj még egy nagy szoftverfejlesztőt, aki ennél jobban támogatja a termékei megismerését és a tanulást....
Azert kaptam en tobbszor is olyan Oracle hibat, amire az osszes dokumentacio annyi volt, hogy majd kesobbi verzioban dokumentaljak.
Na szerencsere megoldodott.
A konzolban (oracle-on belul) kilottem a tegnap este indult processzt.
Azert ez eleg ciki a piacvezeto adatbaziskezelotol nem?
Mi ez windows hogy allandoan ujra kell inditani?
Mindegy nem akarok flamelni, de baromira megijedtem.
Egyebkent azert nem lehet leallitani, mert ez egy failover cluster, ami ugy van osszedrotozva, es ha leallitanam, akkor egy masik gep atvenne az ip-jet.
Es amugy is szinkronizalva van az adatbazis arra a gepre, amiatt sem engedi egyszeruen leallitani.
Ja es persze nem en raktam ossze es nincs semmi doksi, kiserletezni meg nem merek vele. :-((
Anr, ha már dokumentálásnál tartunk nagyon tudom ajánlani ez a helyet:
http://metalink.oracle.com/
Ha oracle alapokon van rendszered tuti, hogy vásárolt rendszerről van szó, akkor pedig metalinken szinte minden problémát tudnak orvosolni, feltétel hogy regisztráld magad és legyen licenszed :)
A queryk optimalizálásán iszonyatosan sok múlik (tapasztalat, a rendszerünk elindulása után közel 1 évig elcseszett riportok optimalizálásán fáradoztam többek között)
Ehhez szakirodalomnak ajánlom az 'Oracle tervezés' című könyvet.
(szuverin vélemény: left join-t és like-ot én erősen kerülöm, képesek lassítani sokat, ez a select nekem olyan MSQL környezetből jövőnek tűnik.... :) )
Emellett az adatbázis fizikai fájljainak jó elhelyezése-elosztása a diszkeken is tud eredményt produkálni, nem ördöngősség, csak tudnod kell a géped felépítését és józan paraszti ésszel egy kis gondolkodással jó eredményt el lehet érni.
Viszont egy esetben nincs segítség: ha a gép a felhasználók számához fizikailag nagyon-nagyon alul van tervezve.... (Ez is tapasztalati út sajna...)
Mano
[quote:e406013ded="profeta"]Na szerencsere megoldodott.
A konzolban (oracle-on belul) kilottem a tegnap este indult processzt.
Azert ez eleg ciki a piacvezeto adatbaziskezelotol nem?
Mi ez windows hogy allandoan ujra kell inditani?
Mindegy nem akarok flamelni, de baromira megijedtem.
:) Leesett a kő a szívemről, legalább nem romlott el nagyon semmi.
A flame-ről annyit, hogy igen, ez egy piacvezető termék, de legalább csak egy beragadt processzt kellett kilőnöd... Próbálj egyszer segíteni egy MS SQL szerver beragadásán... Úgyhogy IMHO korrekt, hogy ha van is bibi, ennyivel meg lehet úszni.
A magyarázatod értem, ekkor viszont méginkább kérdéses, hogy milyen diszkleosztás van, egyrészt amiket már korábban kérdeztem, másrészt pedig hogy a két gép közt a diszkek is vándorolnak-e, és ha igen hogyan...
Meg persze hogy ez most akkor RAC, vagy vmi kézzel hackelt cluster?
Ha nagyon alultervezett a vas az optimalizálás akkor is eredményes, csak nem olyan átütően látványos a javulás (nálunk pl. vas csere után akkora volt az áttörés, hogy a felhasználók külön azért telefonáltak napokig délutánonként, hogy hálálkodjanak... bár előtte is lehetett dolgozni a rendszerrel, csak nem volt engedve riportok futtatása százassával... :lol: )
[quote:92013aa5dd="gmano"]Ha nagyon alultervezett a vas az optimalizálás akkor is eredményes, csak nem olyan átütően látványos a javulás (nálunk pl. vas csere után akkora volt az áttörés, hogy a felhasználók külön azért telefonáltak napokig délutánonként, hogy hálálkodjanak... bár előtte is lehetett dolgozni a rendszerrel, csak nem volt engedve riportok futtatása százassával... :lol: )
Tudsz mondani valamilyen kb vasakat es kb terehelest?
[quote:ac2b888072="mocsi"]
Tudsz mondani valamilyen kb vasakat es kb terehelest?
Mire? Ne viccelj már... Egy vacak lekérdezésből 3 is megfoghat egy kemény vasat is, egy jól kihangoltból meg 150 is elmegy egy 1 GHz-es procin jó válaszidővel...
Legalább valami támpontot, hogy végülis mire vagy kiváncsi... :mrgreen:
[quote:2996f61d99="gmano"]
A queryk optimalizálásán iszonyatosan sok múlik (tapasztalat, a rendszerünk elindulása után közel 1 évig elcseszett riportok optimalizálásán fáradoztam többek között)
Az a problema, hogy nekem nincs idom egy olyan query optimalizalasaval heteket szorakozni, amirol ranezesre latszik, hogy kellene vegrehajtani. A megfelelo indexeket persze rarakom.
Itt nem is optimalizalasrol van szo, hanem arrol, hogy probalom olyan formara hozni a query-t, amibol mar az idiota optimizernek is leesik, hogy mit kene csinalnia.
Amennyire lattam az a gond, hogy az oracle-ben nincs limit, emiatt subquery kell, az meg mar az optimalizalonak beteszi a kaput.
[quote:2996f61d99="gmano"]
(szuverin vélemény: left join-t és like-ot én erősen kerülöm, képesek lassítani sokat, ez a select nekem olyan MSQL környezetből jövőnek tűnik.... :) )
Nem tudom mibol gondolod ezt az MSQL kornyezet dolgot, de ha ez megnyugtat eletemben nem lattam olyat, es mint mar elobb szo volt rola a query-t program generalja, egy graf es megadott feltetelek alapjan.
Amugy persze, magyarazd el a usernek, hogy nem lehet csak pontos ertekre keresni, es a nagybetu nem egyenlo a kisbetuvel.
A left join meg ne lassitson mar, semmi nem indokolja. Hogy akarsz anelkul atmenni egy idegen kulcson, ha az nem kotelezo?
Ennyi erovel legjobb ha csak egy, de nem tul nagy tabla van a queryben, amin a sequential scan is gyors, es akkor az se baj ha az optimalizalo tokhulye.
[quote:2996f61d99="gmano"]
Viszont egy esetben nincs segítség: ha a gép a felhasználók számához fizikailag nagyon-nagyon alul van tervezve.... (Ez is tapasztalati út sajna...)
Mano
Ez pontosan igy van, csak nem lehet ugy tervezni, ha az ember elore azt sem tudja, milyen lekerdezesek varhatok milyen tablakon. Ehhez kell a tapasztalat, meg a felhasznalok hulye igenyeinek verbe fojtasahoz.
Kedvencem a szovegben keres opcio: az oszes mezore upper(mezo) like '%felteltel%' vaggyal osszekapcsolva.
Sajnos ezeket az ordas baromsagokat keszen kaptuk.
Osszefoglalva a fo bajom az oracle-el az optimizer benasaga, a szar dokumentacio, es a lehetetlen adminisztracios "eszkozok".
Pl. csak a query plan lekerese egy remalom.
[quote:21fbadf35b="cheeky"][quote:21fbadf35b="mocsi"]
Tudsz mondani valamilyen kb vasakat es kb terehelest?
Mire? Ne viccelj már... Egy vacak lekérdezésből 3 is megfoghat egy kemény vasat is, egy jól kihangoltból meg 150 is elmegy egy 1 GHz-es procin jó válaszidővel...
Legalább valami támpontot, hogy végülis mire vagy kiváncsi... :mrgreen:
Egy vacakbol egy is megfog egy gepet... eleg ha Java-ban rakod ossze a jo nagy PL/SQL keresorutint String konkatenacioval :) Tudnek rola meselni... :-)
[quote:18cf1dfb24="cheeky"][quote:18cf1dfb24="mocsi"]
Tudsz mondani valamilyen kb vasakat es kb terehelest?
Mire? Ne viccelj már... Egy vacak lekérdezésből 3 is megfoghat egy kemény vasat is, egy jól kihangoltból meg 150 is elmegy egy 1 GHz-es procin jó válaszidővel...
Legalább valami támpontot, hogy végülis mire vagy kiváncsi... :mrgreen:
A rohej az hogy itt van mogottem ket kibaszott Alpha irto dragan, osztan vettunk egy gepet IDE felulettel gyakorolgatni Alpha ara/100 Ft-ert, utolag meg kiderult, hogy egy db sima mirror IDE tomb 4x gyorsabb ugyanaz az a tranzakcio (tranzakciok, lekerdezesek stb), mint az agyonoptimalizalt (masok altal es altalam) Digital/Cpq/HP. Azota ruhellem a SCSI az ami jo mas nem. meg RISC, meg ne x86-ot oracle ala, meg faszomtudja milyen hiper tehnologia szoveget. Amikor ilyet hallok kereskedoktol legszivesebben pofan csapnam oket.
Szoval min futott, most min fog futni? Roviden, de ha sokat meselsz, akkor imadni foglak :D :twisted:
[quote:7285575a8c="profeta"]Na szerencsere megoldodott.
Azert ez eleg ciki a piacvezeto adatbaziskezelotol nem?
Mi ez windows hogy allandoan ujra kell inditani?
Az Oracle-nek mindig is eleg nagy hibaja volt az adminisztraciohoz szukseges pilotavizsga. A 10-es sorozattal viszont allitolag egesz kellemesen valtozott a helyzet, ez a legnagyobb elonye a 9-eshez kepest. Meg persze az allitolagos sebessegnovekedes.
Ár/teljesítmény arányban az x86 verhetetlen. Mégis, mit vártál?
Amúgy szerintem az használjon oracle-t, aki tényleg ért is hozzá. Aki épp most készül megtanulni, hogy optimizer meg explain, jobban jár egy mysql/innodb-el. Nem tud annyit, de meg lehet lenni vele, cserébe viszont eszméletlen gyors.
Ja, es az se veletlen, hogy az osszes nagygépárus annyira nyomja az opteront mostanaban. Teljesitmenyre osszevetheto a sajat meregdraga rendszereikkel, 64bites, es nagyon durvan olcso.
[quote:bb749c65e5="Finrod"]
Az Oracle-nek mindig is eleg nagy hibaja volt az adminisztraciohoz szukseges pilotavizsga. A 10-es sorozattal viszont allitolag egesz kellemesen valtozott a helyzet, ez a legnagyobb elonye a 9-eshez kepest. Meg persze az allitolagos sebessegnovekedes.
Az még sose volt gond, hogy valamihez érteni kellett ahhoz, hogy használhasd... Jobb az M$ féle hozzáálás, van 3 opció, ahhoz színes-szagos felület, aztán ha hangolni kell, akkor megáll az ész a vasnál?
Akkor inkább legyen 250 parancssorból állítható paraméterem, amik lehetőséget nyújtanak a dolog lelkébe való beletúrásra...
A 10g pedig nem csak elvileg gyorsabb, tipikusan egy web-es felületű tranzakciós rendszer ugyanazon a vason kb 20-30%-al teljesít jobban... Tapasztalat... Legalábis Linuxon.
Azért a komolyabb adatbázisok mind hasonlítanak az Oracle-re ebből a szempontból, lásd pl. DB2...
[quote:1b46ea8583="cheeky"][quote:1b46ea8583="Finrod"]
Az Oracle-nek mindig is eleg nagy hibaja volt az adminisztraciohoz szukseges pilotavizsga. A 10-es sorozattal viszont allitolag egesz kellemesen valtozott a helyzet, ez a legnagyobb elonye a 9-eshez kepest. Meg persze az allitolagos sebessegnovekedes.
Az még sose volt gond, hogy valamihez érteni kellett ahhoz, hogy használhasd... Jobb az M$ féle hozzáálás, van 3 opció, ahhoz színes-szagos felület, aztán ha hangolni kell, akkor megáll az ész a vasnál?
Akkor inkább legyen 250 parancssorból állítható paraméterem, amik lehetőséget nyújtanak a dolog lelkébe való beletúrásra...
A 10g pedig nem csak elvileg gyorsabb, tipikusan egy web-es felületű tranzakciós rendszer ugyanazon a vason kb 20-30%-al teljesít jobban... Tapasztalat... Legalábis Linuxon.
Azért a komolyabb adatbázisok mind hasonlítanak az Oracle-re ebből a szempontból, lásd pl. DB2...
Azert eleg kellemes dolog volt, mikor idonkent kozolte a rollback szegmensre hogy kevesli a meretet... magyarul azert kellett egy dba aki ugyelt a rendszerre... ez allitolag mar a multe a 10-es sorozattal, amig van winyo addig nem jatszik ilyesmit...
Meg ugye az ertes az eleg durva mennyisegu penzbe kerul, mert ugye autodidakta modon egy DBA szintre eleg nehez eljutni Oracleben. Az errol szolo oklevelrol meg ugye ne is beszeljunk.
[quote:cb2a90e453="hory"]Ár/teljesítmény arányban az x86 verhetetlen. Mégis, mit vártál?
Amúgy szerintem az használjon oracle-t, aki tényleg ért is hozzá. Aki épp most készül megtanulni, hogy optimizer meg explain, jobban jár egy mysql/innodb-el. Nem tud annyit, de meg lehet lenni vele, cserébe viszont eszméletlen gyors.
nem akarok flémet, de mysql-t soha... pgsql :D
jó teljesítmény, jó tudás, jó dokumentáció szvsz sokkaljobb mint a mysql
az oraclehez nem volt még szerencsém mélyebben... de valamiért nem is nagyon vágyom rá :)
[quote:786a462e48="cheeky"]
Az még sose volt gond, hogy valamihez érteni kellett ahhoz, hogy használhasd...
Nem azzal van gond, hogy erteni kell hozza, hanme az informacio elerhetosegerol. Ha valami bajom van linux kernel/postgress/perl/... ugyben, akkor rakeresek a doksiban/kerem a google segitseget, es KAPOK valaszt. Az Oracle-vel kapszolatos keresesek minimalis/zero hasznalhato valaszt eredmenyeznek. Ez oriasi gond.
Nem vagyok DBA, nem is akarok az lenni, de neha szukseges, hogy bizonyos reszproblemakban ertsem mi tortenik. Na ilyen esetekben a Postgres-nel megtalalom a segitseget Oracle-nel nem.
Ebbol annyi jon le, hogy Postgress-re dolgozni szeretek, az Oracle meg a pokolba kivanom.;)
No, egyesek nagyon rákaptak itt az Oracle fikázására, hát nem tudom, csak egyet tudok érteni horyval, az használja, aki ért is hozzá, de komolyan. Azért értő kezek között még mindig kenterbe veri bármelyik open source cuccot... Még a pgsql-t is, bár e tekintetben az áll hozzá legközelebb.
Ne nyissunk flame-et, nem azért írtam, hanem tapasztalatból.
Igaz, tapasztalat az is, hogy hogy lehet nagyon elrontani Oracle adatbázist, épp most került a kezem alá egy PC, duál 2.4 Xeon 2M, 6 diszk hw RAID, 2.5 giga memória, és a rátelepített Oracle adatbázist egy 1 giga memóriájú gépen 1 db ide diszken optimalizált Oracle-el meg lehet verni... Iszonyú blama, a szállító cégről lerí, hogy fingja nincs az Oracle-höz.
[quote:96be3a97b4="cheeky"]No, egyesek nagyon rákaptak itt az Oracle fikázására, hát nem tudom, csak egyet tudok érteni horyval, az használja, aki ért is hozzá, de komolyan. Azért értő kezek között még mindig kenterbe veri bármelyik open source cuccot... Még a pgsql-t is, bár e tekintetben az áll hozzá legközelebb.
Ne nyissunk flame-et, nem azért írtam, hanem tapasztalatból.
Igaz, tapasztalat az is, hogy hogy lehet nagyon elrontani Oracle adatbázist, épp most került a kezem alá egy PC, duál 2.4 Xeon 2M, 6 diszk hw RAID, 2.5 giga memória, és a rátelepített Oracle adatbázist egy 1 giga memóriájú gépen 1 db ide diszken optimalizált Oracle-el meg lehet verni... Iszonyú blama, a szállító cégről lerí, hogy fingja nincs az Oracle-höz.
Hat ja, a szallito cegnek kellett volna megfizetni egy DBA-t hogy installalja fel az adatbazist RENDESEN :-) Mondjuk 2 embernap :-)
[quote:ae1f1145a8="Finrod"]
Hat ja, a szallito cegnek kellett volna megfizetni egy DBA-t hogy installalja fel az adatbazist RENDESEN :-) Mondjuk 2 embernap :-)
Hát ja. Így most átvehetem így, aztán küzdhetek vele pár hétig menet közben, míg rájövök, hol, mit, és hogyan egyszerűsíthetek ki... :)
Gyanítom, a két szerver, amit vettek hozzá, simán fölösleges... Nem baj, előbb felszabadítom őket, aztán majd lesz jobb helyük :D
Visszatérve kicsit az eredeti problémához:
anr, végülis jutottál valamire a cuccal, vagy inkább nem kísérletezel? :twisted:
[quote:8987f6b97e="Finrod"]
Hat ja, a szallito cegnek kellett volna megfizetni egy DBA-t hogy installalja fel az adatbazist RENDESEN :-) Mondjuk 2 embernap :-)
Szerintem ennyi nem eleg, mert az alkalmazas es terheles fuggvenyeben kell akar az adatbazisszerkezeten esetlegesen tobbszor optimalizalni.
A gond az a TCO. Agyonkepzett ember kell hozza, olyan szakmai gyakorlattal, amit doksibol nem igazan lehet megszerezni.
Az oracle lehet hogy sokat tud, de egy dinoszaurusz.
Ma mar egy szoftverrel szemben elvaras, hogy az elmeleti hatter ismerete mellett intuitiven meg lehessen ismerni es hasznalni.
Foleg ha egy iszonyu dragan mert szoftverrol beszelunk.
Egyebkent pedig nem tudom elhinni hogy annyira profin van megirva, ha pl. az sql szintaktikus elemzoje nem kepes egy normalis hibauzenetet adni. Latszik hogy akarki is irta , fogalma sem volt a forditoprogramokrol.
Lattam mar egypar projektet, amihez baromira nem kellett volna oracle, de a management megvette, mert akkor az o segguk vedve van, hiszen a piacvezeto termek nem lehet rossz.
[quote:726f15beaf="anr"]
Ebbol annyi jon le, hogy Postgress-re dolgozni szeretek, az Oracle meg a pokolba kivanom.;)
Valami jo Postgres-es konyvajanlo vagy jo Postgres leiras?
[quote:cc689e1f41="cheeky"]
Visszatérve kicsit az eredeti problémához:
anr, végülis jutottál valamire a cuccal, vagy inkább nem kísérletezel? :twisted:
A surgos problemat megoldotta, hogy az userek leszoktak nehany olyan keresesi feltetel hasznalatarol, amig a terheles nagyreszet okoztak, es valojaban nem is igazan volt ra szukseguk.
Kozeptavon meg ugy tunik kenytelen lesz valaki kozulunk Oracle DBA-va kepezni magat;-)
Legalabb annyira, hogy pontosabban tudjunk kerdezni.;)
Egyebkent bevalt a tuti gyors modszer.
Programobol karbantartott szamolt mezokkel kivegezni a problemas joinokat. Mivel minimalis insert/update van a select-ekhez kepest ez megcsinalhato.
Egy ideig kacerkodtunk, hogy kidobjuk az Oracle-t, es teszunk helyere postgress-t;))) (fejlesztoi laptopokon egesz normalis valaszidokat adott ugyanazzal az adatbazissal), de tobb het lenne, mire az ember biztonsaggal/korrekten megcsinal egy ekkora atallast.
[quote:56211177dc="profeta"][quote:56211177dc="Finrod"]
Hat ja, a szallito cegnek kellett volna megfizetni egy DBA-t hogy installalja fel az adatbazist RENDESEN :-) Mondjuk 2 embernap :-)
Szerintem ennyi nem eleg, mert az alkalmazas es terheles fuggvenyeben kell akar az adatbazisszerkezeten esetlegesen tobbszor optimalizalni.
Egy explain plan-el tudjon eljatszani a fejleszto is, vagy ne mondja magarol hogy ert az Oracle-hoz. A DBA-t arra ertettem, hogy a vasra feltelepiti az Oracle-t nagyjabol idealisan (hasznalja ki a hardver lehetosegeit).
[quote:56211177dc="profeta"]A gond az a TCO. Agyonkepzett ember kell hozza, olyan szakmai gyakorlattal, amit doksibol nem igazan lehet megszerezni.
Az oracle lehet hogy sokat tud, de egy dinoszaurusz.
Ma mar egy szoftverrel szemben elvaras, hogy az elmeleti hatter ismerete mellett intuitiven meg lehessen ismerni es hasznalni.
Foleg ha egy iszonyu dragan mert szoftverrol beszelunk.
Egy fejlesztovel meg relative gyorsan olcson meg lehet ismertetni azt amit neki tudni kell, tehat hogy egy rendesen beallitott adatbazison egy query vagy egy muvelet mitol gyors, mitol lassu, mikor mit csinal, mit nem szabad csinalni, stb. Innentol mar ugyis a fejleszto kreativitasan mulik, hogy ki tudja-e hasznalni a lehetosegeket.
Nem Oracle SQL-ben programozni kell megtanitani a fejlesztot, az ugyanis tul hosszu idobe telne, hanem az Oracle SQL motor mukodeset kell nagyjabol elmagyarazni neki.
Az adatbazisadmin, na az az ami sok penzbe kerul. Neki azt kell tudni, hogy ha ide ezt irok, oda azt, na akkor hirtelen ez meg az 10-szer gyorsabb lesz (az meg 2-szer lassabb), es ezeket ossze kell tudnia kombinalni egy idealis egyvelegge...
[quote:a1a7c3b431="Finrod"]
Egy explain plan-el tudjon eljatszani a fejleszto is, vagy ne mondja magarol hogy ert az Oracle-hoz. A DBA-t arra ertettem, hogy a vasra feltelepiti az Oracle-t nagyjabol idealisan (hasznalja ki a hardver lehetosegeit).
Hát ezaz, bakke, nem egy 4 lemezből álló RAID5 tömbre rakom az adatbázist, hanem beáldozok még egy lemeznyi kapacitást, és rakom 1+0-ba, aztán hadd röpüljön az az adatbázis! :) Agyrém, egyesek mire képesek... Vagy pl nem hagyom a memória 2/3-át üresen, inkább block_buffer-t csinálok belőle (oh, pardon, db_cache-t, változnak az idők... :wink: )
[quote:a1a7c3b431="Finrod"]
Az adatbazisadmin, na az az ami sok penzbe kerul. Neki azt kell tudni, hogy ha ide ezt irok, oda azt, na akkor hirtelen ez meg az 10-szer gyorsabb lesz (az meg 2-szer lassabb), es ezeket ossze kell tudnia kombinalni egy idealis egyvelegge...
De tudod milyen kellemesen meg lehet belőle élni? :mrgreen:
Viccet félretéve, igen, drága az ilyen ember. De azt se lehet vitatni, hogy megéri, ha egy utasítás, ami hozzányúlás előtt 23 mp volt, hozzányúlás után meg 0.48 mp... És nem index feldobálásával barom módon, mert azzal sokszor többet árt az ember, mint használ.
Az egyetlen probléma, hogy a fejlesztőcégeknél egyre kevesebb helyen fogadják el, hogy szükség van ilyen emberre, és inkább megoldják magasabb hw követelménnyel.
Így aztán a megrendelő vagy a vasért fizet többet, vagy alkalmaz ilyen tudású ember(eke)t, cégmérete válogatja, melyik az olcsób...
[quote:5f32079955="cheeky"][quote:5f32079955="Finrod"]
Egy explain plan-el tudjon eljatszani a fejleszto is, vagy ne mondja magarol hogy ert az Oracle-hoz. A DBA-t arra ertettem, hogy a vasra feltelepiti az Oracle-t nagyjabol idealisan (hasznalja ki a hardver lehetosegeit).
Hát ezaz, bakke, nem egy 4 lemezből álló RAID5 tömbre rakom az adatbázist, hanem beáldozok még egy lemeznyi kapacitást, és rakom 1+0-ba, aztán hadd röpüljön az az adatbázis! :) Agyrém, egyesek mire képesek... Vagy pl nem hagyom a memória 2/3-át üresen, inkább block_buffer-t csinálok belőle (oh, pardon, db_cache-t, változnak az idők... :wink: )
[quote:5f32079955="Finrod"]
Az adatbazisadmin, na az az ami sok penzbe kerul. Neki azt kell tudni, hogy ha ide ezt irok, oda azt, na akkor hirtelen ez meg az 10-szer gyorsabb lesz (az meg 2-szer lassabb), es ezeket ossze kell tudnia kombinalni egy idealis egyvelegge...
De tudod milyen kellemesen meg lehet belőle élni? :mrgreen:
Viccet félretéve, igen, drága az ilyen ember. De azt se lehet vitatni, hogy megéri, ha egy utasítás, ami hozzányúlás előtt 23 mp volt, hozzányúlás után meg 0.48 mp... És nem index feldobálásával barom módon, mert azzal sokszor többet árt az ember, mint használ.
Van benne valami... csak az a baj, hogy mas nem is tudja megfizetni, csak azok a cegek, akiknek ugyfeluk is van, akinek Oracle kell.
Igy az eleg valoszinutlen, hogy az ember sajat maga befizet ilyen tanfolyamra, akkor is ha jol meg lehet elni belole...
Na mindegy, ha sikerul megcsipni valami jo melot Angliaban, akkor lehet hogy beruhazok majd valami ilyesmire is...
[quote:122a1f86e6="Finrod"][quote:122a1f86e6="anr"]
Ebbol annyi jon le, hogy Postgress-re dolgozni szeretek, az Oracle meg a pokolba kivanom.;)
Valami jo Postgres-es konyvajanlo vagy jo Postgres leiras?
www.postgresql.org mondjuk kapasbol :)
Van tobb angol konyv is, es online book is:
http://www.postgresql.org/docs/awbook.html
De ha mondjuk erdekel, akkor azt hiszem fel perc google-val minden infot megtalalsz.
[quote:6051f41244="hory"]Ár/teljesítmény arányban az x86 verhetetlen. Mégis, mit vártál?
Amúgy szerintem az használjon oracle-t, aki tényleg ért is hozzá. Aki épp most készül megtanulni, hogy optimizer meg explain, jobban jár egy mysql/innodb-el. Nem tud annyit, de meg lehet lenni vele, cserébe viszont eszméletlen gyors.
Oracle hasznalni es alapveto dolgokban relative egyszeru (szerintem).
En ezt ugy modositanam, hogy optimalizalni oracle-t csak az kezdjen el akinek mar van tapasztalata hasznalatbol, optimalizalasbol es tudja mi miert tortenik. Egy jol belott rendszer akar evekig el tud futni annelkul hogy a szokasos evenkenti/2 evenkenti import->drop->recreate-en kivul mas komolyabb beavatkozas nem kell.
A legtobb dba-nak adott egy (altalaban k. draga) kifejlesztett Adatbazis/forms/application/akarmiUI egyuttes amihez O hozza sem nyulhat megha megtalalja mekkora futyisegeket irtak a programozok, mert kulonben egy mashol mas miatt bekovetkezett hibat siman rakeni a fejleszto veg. Ez a proprietary license lenyege :D
[quote:f6d48c2cf1="anr"][quote:f6d48c2cf1="cheeky"]
Visszatérve kicsit az eredeti problémához:
anr, végülis jutottál valamire a cuccal, vagy inkább nem kísérletezel? :twisted:
A surgos problemat megoldotta, hogy az userek leszoktak nehany olyan keresesi feltetel hasznalatarol, amig a terheles nagyreszet okoztak, es valojaban nem is igazan volt ra szukseguk.
Kozeptavon meg ugy tunik kenytelen lesz valaki kozulunk Oracle DBA-va kepezni magat;-)
Legalabb annyira, hogy pontosabban tudjunk kerdezni.;)
Egyebkent bevalt a tuti gyors modszer.
Programobol karbantartott szamolt mezokkel kivegezni a problemas joinokat. Mivel minimalis insert/update van a select-ekhez kepest ez megcsinalhato.
Egy ideig kacerkodtunk, hogy kidobjuk az Oracle-t, es teszunk helyere postgress-t;))) (fejlesztoi laptopokon egesz normalis valaszidokat adott ugyanazzal az adatbazissal), de tobb het lenne, mire az ember biztonsaggal/korrekten megcsinal egy ekkora atallast.
Sokkal jobb optimalizalast ertel volna el, ha mondjuk az osszes usert leszoktatod a munkarol :D
[quote:1e36ea6411="mocsi"]
Sokkal jobb optimalizalast ertel volna el, ha mondjuk az osszes usert leszoktatod a munkarol :D
Az userekkel nem az a gond, hogy dolgoznak, hanem az, hogy rendkivul erossen ragaszkodnak valami aprosaghoz. Soxor ezeket rendkivul nehez megcsinalni. Ha hajlando lenne az user egy picit mast csinalni, aminek az eredmenye teljesen ugyanaz lenne, akkor sokat egyszerusudnenek a dolgok.
Viszont az user fizet, es ezert kovetel, neha semilyen kompromisszumra sem hajlando.
Most a lassulas miatt olyan kovetelt featurerol modntak le, amirol elotte megeskudtek, hogy nelkule elkepzelhetetlen a munka.
Persze aki dolgozott mar fizetos ugyfellel az tudja, hogy lazan ellentmond onmaganak, es az ilyeneket nagyrutinnal probalja a fejlesztore kenni akar a penzel valo zsarolas aran is.
Ja meg: "a hibat ki kell javitani. Ez hiba, mert nincs benne" mondta az user egy bonyolult feature-t hianyolva.;)
A nagy cegek (pl: SAP) megtehetik, hogy rendkivul dragan dolgoznak, es ezzel tartjak az user igenyeit kordaban. A kis cegek nem tehetik meg. :(
[quote:d934661b86="mocsi"]A legtobb dba-nak adott egy (altalaban k. draga) kifejlesztett Adatbazis/forms/application/akarmiUI egyuttes amihez O hozza sem nyulhat megha megtalalja mekkora futyisegeket irtak a programozok, mert kulonben egy mashol mas miatt bekovetkezett hibat siman rakeni a fejleszto veg. Ez a proprietary license lenyege :D
Kellőképp agresszív dba kellőképp agresszív ügyfélként lép fel, és igenis a lassúság is hiba, ha indokolatlan, és jól látható tervezési hiányosságokból fakad. Ha a szállító akarja, megteszem neki azt a szívességet, hogy felderítem az ilyen típusú hibáit, de ha bebizonyítom, hogy vmi úgy jobb, akkor kutya kötelessége kijavítani a _hibát_.
Hát ez az én álláspontom azokkal a szállítókkal szemben, akik nem képesek, vagy inkább nem hajlandóak megfizetni egy szakembert ezért. Így legalább annyit költ el hibajavításra. Mondjuk nem is szeretnek nagyon a szállítók, de hát vessenek magukra... :twisted:
[quote:150868e2c5="mrbond"]nem akarok flémet, de mysql-t soha... pgsql :D
jó teljesítmény, jó tudás, jó dokumentáció szvsz sokkaljobb mint a mysql
az oraclehez nem volt még szerencsém mélyebben... de valamiért nem is nagyon vágyom rá :)
Gratulálok. Innováció a köbön.
Van egyáltalán fogalmad arról, hogy mit tud az innodb? :x
Az Oracle adatbázisunk terhelése kezdi kinőni a hardware-t. Pénz nincs, tehát optimalizálni kéne. Az egész egy Redhat AS-en fut onmagaban, semmi egyeb szolgaltatas. 1.5G memoria van a gepben, kb a teljes adatbazis belefer. A queryk rondak, es egyediek (nem optimalizalhatok)
A problemak:
-ha a redhat loadja 0.98-nal kisebb, gond nincs, ha 1.02-nel nagyobb akkor az Oracle valaszidok 8-10-szeresere emelkednek. Normalis ez igy?
-kimertuk, hogy ha 4 query fut parhuzamosan, akkor meg jok a valszidok, ha bejon az 5., vagy tovabbiak akkor _drasztikusan_ lecsokken az osszes valaszido. Be lehet valahogy allitani, hogy az 5. queryt el se kezdje megvalaszolni addig, amig nem vegzett eggyel az elozok kozul?
- valami egyeb tipp, amivel erdemes probalkozni?
Thx
Andrej
[quote:f23f17d6c0="anr"]Az Oracle adatbázisunk terhelése kezdi kinőni a hardware-t. Pénz nincs, tehát optimalizálni kéne. Az egész egy Redhat AS-en fut onmagaban, semmi egyeb szolgaltatas. 1.5G memoria van a gepben, kb a teljes adatbazis belefer. A queryk rondak, es egyediek (nem optimalizalhatok)
Mit jelent az, hogy rondák és nem optimalizálhatók? Kis ideje foglalkozom Oracle-lel, és az a tapasztalat, hogy mindig van mit optimalizálni... :D
Ha gondolod, privátban megbeszélhetjük, biztos van még min javítani...
Amit leírtál, arra is van tippem, de ehhez tudni kellene pár dolgot:
-Mennyi és milyen proci van a gépben (HT-s vagy sem)?
-Milyen diszkeken van az adatbázis?
-Dedikált szerver, vagy shared server (régebben Multi Threaded Server)?
-Adatbázis indítóparaméterek?
Üdv
ch
Hint: Az otodik query miatt (pl: nem fer mar bele a memoriaba) mas pl disk alapu vagy tobbmenetes algoritmust hasznal az oracle? Sasold meg es hasonlitsd ossze a query plan-eket amikor csak nehany van, ill amikor
bejon a degradacio.
[quote:ed32d567ae="cheeky"]
Amit leírtál, arra is van tippem, de ehhez tudni kellene pár dolgot:
-Mennyi és milyen proci van a gépben (HT-s vagy sem)?
-Milyen diszkeken van az adatbázis?
1 db proci.
model name : Intel(R) XEON(TM) CPU 2.00GHz
IBM ServerRAID kartya jo diszkekkel, de a kartyan bonnie-val mert IO teljesitmeny, hat nem a legjobb.
failover cluster-ben 2 gep. az oracle vmekkora kesessel csinal adatszinkront a ket gep kozott.
[quote:73471264a2="hory"][quote:73471264a2="mrbond"]nem akarok flémet, de mysql-t soha... pgsql :D
jó teljesítmény, jó tudás, jó dokumentáció szvsz sokkaljobb mint a mysql
az oraclehez nem volt még szerencsém mélyebben... de valamiért nem is nagyon vágyom rá :)
Gratulálok. Innováció a köbön.
Van egyáltalán fogalmad arról, hogy mit tud az innodb? :x
igen, mert olvasni tudok... nem is arról volt szó, hanem a mysql-ról.
az innodb azért került bele mert quotoltam...
amit tudok az az, hogy amit eddig meg kellett csinálnom azt a pgsqllel mindent megtudtam...nem volt szügségem sem innodb-re, sem oraclere. ezzel szemben a munkám során már futottam olyanba bele, amit a mysql nem tud(ott).
szvsz manapság az nem nevezheti magát adatbáziskezelőnek aki sem tranzakciót (ez a legalapabb...) sem triggert, sem stb nem tud.
uff! vallás háborút akarsz :) menjünk át a flémes topikba. láttam már régebben pgsql vs mysql topikot ami betonkeverőben végezte :twisted:
[quote:99b2820770="cheeky"]
Mit jelent az, hogy rondák és nem optimalizálhatók? Kis ideje foglalkozom Oracle-lel, és az a tapasztalat, hogy mindig van mit optimalizálni... :D
-Adatbázis indítóparaméterek?
a query-k a userek kattintgatasai alakitjak ki, gyakorlatilag nincs ket egyforma query. van egy query szerverunk, ami a beallitasok alapjan legyartja az SQL-t ez a query gyarto algoritmus mar agyon van optimalizalva. Ezzel kezdtuk;) Itt nem hiszem, hogy sokat tudnak okosodni;))
Ime egy ronda query, nem ez a legrondabb, csak hirtelen ezt talaltam;)
A postgres gyengebb vason ugyanolyan gyorsan hajtja vegre.
[code:1:99b2820770]
SELECT * FROM (
SELECT ROWNUM AS ROWNUM1, ROWNUM3.* FROM (
SELECT
Entity8950046.OID AS OID , Entity8950046.fk_Adatgazda AS Id9410,
Entity8950046.Szallitoi_megnevezes AS Id9417, Entity8950046.fk_Utolso_modosito AS Id9416,
Entity8950046.Szallitoi_cikkszam AS Id9404, Entity8950046.Statusz AS Id9400,
Entity10170046.XML_Generalas_ideje AS Id11147, Entity10170046.fk_Szervezet AS Id11148,
Entity10170046.Elso_akt_idopontja AS Id11149, Entity10090046.Nev AS Id11058,
Entity10140046.Cikkszam AS Id11132, Entity10140046.Nyilvantartasi_nev AS Id11122,
Entity10140046.fk_Tree_order AS Id11142, Entity10140046.GTIN_eklista AS Id11123,
Entity10070046.fk_HSZ_azonosito AS Id11054, Entity10170046.OID AS DELEGATION_OID,
Entity10170046.Statusz AS DELEGATION_STATUSZ
FROM
Szallito___aru_viszony Entity8950046
LEFT JOIN Szallito___aru_viszo_D Entity10170046
ON Entity8950046.OID = Entity10170046.fk_Application_OID
AND Entity10170046.fk_Szervezet='1000430'
LEFT JOIN Partner Entity10090046
ON Entity10090046.OID = Entity8950046.fk_Szallito_azonosito_OID
LEFT JOIN Partner Entity12600046
ON Entity12600046.OID = Entity8950046.fk_Adatgazda_OID
LEFT JOIN Cikk Entity10140046
ON Entity10140046.OID = Entity8950046.fk_Cikkszam_OID
LEFT JOIN Cikk Entity10120046
ON Entity10120046.OID = Entity10140046.fk_Tapadogongyoleg_OID
LEFT JOIN Cikk_regi_azonosito_MN Entity10070046
ON Entity10140046.OID = Entity10070046.fk_Cikk_uj_azonosito_OID
AND Entity10070046.fk_HSZ_azonosito='1000430'
LEFT JOIN COOP_cikkcsoport Entity10130046
ON Entity10130046.OID = Entity10140046.fk_Tree_order_OID
LEFT JOIN Kisker__jovedekicsoport Entity10100046
ON Entity10100046.OID = Entity10140046.fk_Kisker__jov_csop_OID
WHERE
UPPER( Entity10140046.Cikkszam) LIKE UPPER('1026864%')
ORDER BY Entity10140046.Cikkszam DESC) ROWNUM3
WHERE
ROWNUM <= 100 ) ROWNUM2
WHERE
ROWNUM1 >= 1
[/code:1:99b2820770]
parameterek:
compatible = 9.2.0.0.0
db_block_size = 6144
db_cache_size = 218103808
db_file_multiblock_read_count = 16
dispatchers = '(protocol=TCP)'
fast_start_mttr_target = 300
hash_join_enabled = TRUE
java_pool_size = 0
large_pool_size = 67108864
log_archive_dest_state_2 = ENABLE
log_archive_format = '%t_%s.dbf'
log_archive_start = TRUE
open_cursors = 300
optimizer_index_caching = 80
optimizer_index_cost_adj = 20
pga_aggregate_target = 209715200
processes = 150
query_rewrite_enabled = FALSE
remote_login_passwordfile = EXCLUSIVE
sga_max_size = 839979848
shared_pool_size = 318767104
sort_area_size = 524288
star_transformation_enabled = FALSE
timed_statistics = TRUE
undo_management = AUTO
undo_retention = 10800
undo_tablespace = UNDOTBS1
[quote:320d497fe3="mocsi"]Oracle hasznalni es alapveto dolgokban relative egyszeru (szerintem). En ezt ugy modositanam, hogy optimalizalni oracle-t csak az kezdjen el akinek mar van tapasztalata hasznalatbol, optimalizalasbol es tudja mi miert tortenik.
Persze, csak epp ha nem tudod optimalizalni, akkor a teljesitmenye bizony harmatgyenge mar egy psql-hez kepest is. Innodb meg egyszeruen szarra veri.
De azert szemezgetek vele, mert a particiok, bitmap es funkcionalis indexek meg az oracle jvm elegge brutalis teljesitmenytobbletet tudnak adni. Es ezeken kivul meg annyi kis szirszar feature-e van, amivel gyorsitani lehet az adatbazist, hogy ihaj.
Szoval jo az, csak kifejezetten user-taszito (doksi+admin feluletetek), meg szerintem el is van bonyolitva. Valahogy olyan erzesem van, mintha ugyanazt ganyolnak mar tizenX eve...
[quote:54fe2fa3dd="mrbond"]igen, mert olvasni tudok... nem is arról volt szó, hanem a mysql-ról. az innodb azért került bele mert quotoltam...
mysql/innodb-tol volt szo.
Ezert mondtam, hogy fingod sincs rola. Annyit kellett volna tenned, hogy elkukkantasz az innodb.com -ra, es a lap tetejen ott van nagy betukkel, hogy "transactions, row-level locking, hot backup and foreign keys for mysql".
De ott van a berkeleyDB storage engine is a mysql-hez - az is tud tranzakciokat, es gyanithatolag az a leggyorsabb.
Ez nem vallashaboru, hanem tudatlansag-ellenes haboru. Sokan becsmerlik, kevesen tudjak egyaltalan, hogy mi fan terem...
[quote:7d47d0b9e9="hory"]
Ezert mondtam, hogy fingod sincs rola. Annyit kellett volna tenned, hogy elkukkantasz az innodb.com -ra, es a lap tetejen ott van nagy betukkel, hogy "transactions, row-level locking, hot backup and foreign keys for mysql".
De ott van a berkeleyDB storage engine is a mysql-hez - az is tud tranzakciokat, es gyanithatolag az a leggyorsabb.
Ez nem vallashaboru, hanem tudatlansag-ellenes haboru. Sokan becsmerlik, kevesen tudjak egyaltalan, hogy mi fan terem...
Na akkor ennyit a vallásháborúról... Szép dolog a row level locking, meg az online backup, de könyörgöm, akkor aki eddig itt fikázta az Oracle-t, az mondja már meg, melyik csodás open source db-ben van row level security, advanced queuing, procedural gateway, stored procedure, two-phase commit, autonomous transactions, replikáció, meg még egy rakat feature egyszerre? Márpedig ha valaki _rendszerben_ gondolkodik, és nem világtól elzárt alkalmazást ír, akkor bizony ezekre együtt van szüksége. Egy rendszer attól integrált rendszer, hogy átrántja az alapadatokat a vállalatirányító szoftverből, az ügyféladatokat a közös ügyféltörzsből, a számlaadatokat számlavezető rendszerből, az aktuális kondíciókat a scoring rendszerből, és a végén nyit egy hitelkártyaszámlát a kártyarendszerben (most lehet, hogy hülye példa volt, de a lényeg a szemléltetés... :roll: ). És ezek közül az egyik DB2/AS400, a másik Oracle/Windows, a harmadik Informix/Solaris, a negyedik esetleg Linux, és mégis minden működik, mert közéteszel mondjuk egy MQSeries-t, és az egész gyötrődés az adatbázis elől szépen el van rejtve.
Egy szó, mint száz, szép-szép az open source db, elszigetelt kisalkalmazásokra csodálatos is, de ha integrációról van szó egy erősen heterogén környezetben, akkor sajnos még sehol sincs. De drukkolok, hogy egyszer odaérjen, félreértés ne essék, csak addig viszont nem szeretem, ha valaki fröcsögve lefikázza azt, amiről ezek szerint gőze sincs.
ez egy jo cuccos lenne, csak akkor az adatbazissal kene az authentikaciot vegeztetni (vagy tud ldap-bol authentikalni az Oracle?)
Ez mit is takar?
Nezzuk csak... postgres biztos, es asszem a mysql5 es a firebird is...
Szerintem postgres tudja, firebird is valoszinuleg...
postgres valszinuleg, tobbit nem tudom
postgres, mysql5, tobbit nem tudom
Ilyen rendszereknel altalaban van penz Oracle-re jo eros supporttal, es ez szokott lenni a fo ok... ne erts felre, en is az Oracle-t partolom minden nagyobb rendszerbe, de azert az open source cuccokat se fikazzuk, ha nem vagyunk tisztaban a kepessegeikkel... Altalaban nem a kepessegeikkel szokott gond lenni, hanem hogy meg nem bizonyitottak nagy kornyezetben, akkor sem, ha tudnak amire szukseg van...
Es nincs mindenhol szukseg a felsorolt feature-okre, mert nem mindenhol kell sok rendszer koze integralni az ujat... bar ketsegtelen hogy ezekkel lehet jol keresni, csak az ilyen munkahoz hozza is kell jutni :-)
Ha mar langolunk, akkor azert egy beloginolas idejet is meg kellene nezni. Mire az Oracle mindenfele vm-et, mem pool-t, roll back instance-t stb hozzarendel egy loginhoz eleg sok ido el tud telni...
[quote:4f1781967f="mocsi"]Ha mar langolunk, akkor azert egy beloginolas idejet is meg kellene nezni. Mire az Oracle mindenfele vm-et, mem pool-t, roll back instance-t stb hozzarendel egy loginhoz eleg sok ido el tud telni...
Erre talaltak ki a Connection pool-okat...
Akkor sorjában, legalább tanulunk egymástól, ezt már szeretem... :P
[quote:ce7f746142="Finrod"]
ez egy jo cuccos lenne, csak akkor az adatbazissal kene az authentikaciot vegeztetni (vagy tud ldap-bol authentikalni az Oracle?)
Nos, tud. Van egy ún. Oracle Internet Directory, ami tulajdonképp egy Oracle féle LDAP implementáció. Mielőtt azt mondanád, hogy okés, de akkor ez nem LDAP, elmondom, hogy van benne egy piszkos kis trükk, és a benne nyilvántartott objektum authentikációját le tudod cserélni gyakorlatilag BÁRMIRE, amit meg tudsz írni Java-ban. Persze van mód az authentikációs kérés egyszerű továbblökésére egy másik LDAP felé, nyilván ez a legegyszerűbb...
[quote:ce7f746142="Finrod"]
Ez mit is takar?
AQ: message queue az adatbázisban, aszinkron üzenetküldés adatbázison belül, vagy több távoli adatbázis között.
PG: például az előzőt fejeli meg annyival, hogy az alkalmazásod módosítása nélkül kicserélheted alatta a queue-t egy MQSeriesben definiált queue-ra, ami innentől értelemszerűen nem csak Oracle adatbázissal tarthat kapcsolatot a túlvégen.
[quote:ce7f746142="Finrod"]
Nezzuk csak... postgres biztos, es asszem a mysql5 es a firebird is...
Okés, ezt elismerem, ezért írtam, hogy együtt ezek a feature-ök. Mondjuk nem tudom, a fentiek hogy állnak pl a session triggerekkel, azért az is egy érdekes terület.
[quote:ce7f746142="Finrod"]
Szerintem postgres tudja, firebird is valoszinuleg...
Erről tényleg nem tudtam, de örülök neki... :)
[quote:ce7f746142="Finrod"]
postgres valszinuleg, tobbit nem tudom
Igen, a többi ha jól tudom még nem.
[quote:ce7f746142="Finrod"]
postgres, mysql5, tobbit nem tudom
Oda-vissza, több master-több slave viszonylatban? Ezt azért kétlem, különösen, hogy annyira bonyolult, hogy az Oracle implementációja is távol áll a tökéletestől... :D
[quote:ce7f746142="Finrod"]
Ilyen rendszereknel altalaban van penz Oracle-re jo eros supporttal, es ez szokott lenni a fo ok... ne erts felre, en is az Oracle-t partolom minden nagyobb rendszerbe, de azert az open source cuccokat se fikazzuk, ha nem vagyunk tisztaban a kepessegeikkel... Altalaban nem a kepessegeikkel szokott gond lenni, hanem hogy meg nem bizonyitottak nagy kornyezetben, akkor sem, ha tudnak amire szukseg van...
Es nincs mindenhol szukseg a felsorolt feature-okre, mert nem mindenhol kell sok rendszer koze integralni az ujat... bar ketsegtelen hogy ezekkel lehet jol keresni, csak az ilyen munkahoz hozza is kell jutni :-)
Ez utóbbival csak egyetérteni tudok, de hidd el, elhivatottsággal és érdeklődéssel nem is olyan nehéz ilyen munkát találni.
És bocsánat, ha úgy tűnt volna, hogy fikkantom az open source cuccokat, nem erről van szó, csak szerettem volna rávilágítani, mi az, amiben még nagyon messze járnak. Ettől függetlenül már most is nagyon sok mindenre alkalmasak, ezt elismerem.
[quote:d545c78f88="anr"]
1 db proci.
model name : Intel(R) XEON(TM) CPU 2.00GHz
IBM ServerRAID kartya jo diszkekkel, de a kartyan bonnie-val mert IO teljesitmeny, hat nem a legjobb.
failover cluster-ben 2 gep. az oracle vmekkora kesessel csinal adatszinkront a ket gep kozott.
Az 1 db proci HyperThreading? (/proc/cpuinfo két procit mutat?)
A RAID tömb, amin az adatfileok vannak, hogy van konfigurálva? Minimum tükör javallott, de méginkább RAID 1+0... Az adja messze a legjobb IO teljesítményt, még írás esetén is, bár ahogy írtad, valószínűleg elszősorban olvasásról van szó.
Ellenben remélem, az archív log nem ugyanarra a volume-ra megy, mint ahol az adatfileok vannak... Akkor már az a volume is jobb, amin az Oracle software van...
[quote:9216d5571b="cheeky"]
[quote:9216d5571b="Finrod"]
Es nincs mindenhol szukseg a felsorolt feature-okre, mert nem mindenhol kell sok rendszer koze integralni az ujat... bar ketsegtelen hogy ezekkel lehet jol keresni, csak az ilyen munkahoz hozza is kell jutni :-)
Ez utóbbival csak egyetérteni tudok, de hidd el, elhivatottsággal és érdeklődéssel nem is olyan nehéz ilyen munkát találni.
Na ez kicsit felreertheto lett, munka alatt itt nem allast, hanem megrendelest ertettem :-)
[quote:c2224145f8="anr"]
a query-k a userek kattintgatasai alakitjak ki, gyakorlatilag nincs ket egyforma query. van egy query szerverunk, ami a beallitasok alapjan legyartja az SQL-t ez a query gyarto algoritmus mar agyon van optimalizalva. Ezzel kezdtuk;) Itt nem hiszem, hogy sokat tudnak okosodni;))
Ime egy ronda query, nem ez a legrondabb, csak hirtelen ezt talaltam;)
A postgres gyengebb vason ugyanolyan gyorsan hajtja vegre.
Wow. Hát egy dologban abszolút igazad volt, ez ténlyeg undorító... :?
Viszont a paraméterek elég ellentmondásosnak tűnnek számomra, most akkor ez Shared Server, amire a dispatchers utal, vagy dedicated?
Esetleg Shared volt, de később visszavettétek? Akkor viszont gyomlálni kellene.
Ugyanígy érdekes a sort_area_size használata, amit teljességgel kiüt a nyeregből a pga_aggregate_target. Amúgy is elég alacsony lenne az érték, ennél azért 150-es processes-nél bátrabban is lehetne adni, úgy másfél-két megát legalább. De így mindegy is. Viszont azt mondtad, az adatbázis gyakorlatilag elférne a memóriában, ehhez képest azért a pga_aggregate_target lehetne magasabb is, jót tesz. Sokszor csodát. Ha sakkozni kell, akkor is elvennék 64-100 megát az Shared Pool-tól, és elosztanám a pga_aggregate_target és a db_cache_size között. Sőt, cache-t még többet is allokálnék, ha egszer fizikailag elérhető. Ahogy néztem, kb 1 gigát használ a db, azt mondtad, másfél van, hát használjuk... Kell még legyen kb 300-400 szabadon...
Így hirtelen ennyi, de lehet, hogy átdobhatnád levélben a komplett paraméterlistát sql-ből lekérdezve, egyértelműbb lenne... Persze a path-okat meg egyéb érzékeny infókat strip-elheted, nem arra vagyok kíváncsi... :)
Ja, és milyen verziójú RHAS? 2.1 vagy 3.0?
Hamar Oracle, most futottunk bele:
Oracleban tenyleg nem lehet 1000-nel tobb elem az " IN (A,B,C,...)"-ben?
most eppen 1044 kene;)
[quote:ccaf8472fe="anr"]Hamar Oracle, most futottunk bele:
Oracleban tenyleg nem lehet 1000-nel tobb elem az " IN (A,B,C,...)"-ben?
most eppen 1044 kene;)
Konnyen elkepzelheto. Kerulo megoldas:
1. Csinalsz egy tablat ilyesmi celokra, temporary result set-eknek, lehetoleg memoriaban. Ket oszlop, egyik egy resultset_id, masik a value amit felsorolnal.
2. Beleinsertalod az in-ben levo ertekeket azonos resultset_id-val.
3. Rajoinolsz a tablara ertelemszeruen (resultset_id-ra szursz, a value-kra joinolsz).
[quote:dd849d55e4="anr"]Hamar Oracle, most futottunk bele:
Oracleban tenyleg nem lehet 1000-nel tobb elem az " IN (A,B,C,...)"-ben?
most eppen 1044 kene;)
Ha jól értem, literálisokra gondolsz.
Konkrétan ilyen limitáció nincs, legalábbis nem tudok róla, de az adatbázislimitációk közt szerepel egy ezres szám, mégpedig az oszlopok maximális száma egy táblában, valószínű, hogy ezzel van valahogy összefüggésben... Tényleg érdemes kirakni egy táblába ilyenkor, teljesítményre is jobb lesz, ráadásul kis gondolkodással valszeg ki tudod fordítani az IN-t EXISTS-es subquery-re, aminek általában sokkal jobb a futásideje... :)
a query-k a userek kattintgatasai alakitjak ki, gyakorlatilag nincs ket egyforma query. van egy query szerverunk, ami a beallitasok alapjan legyartja az SQL-t ez a query gyarto algoritmus mar agyon van optimalizalva. Ezzel kezdtuk;) Itt nem hiszem, hogy sokat tudnak okosodni;))
Ime egy ronda query, nem ez a legrondabb, csak hirtelen ezt talaltam;)
A postgres gyengebb vason ugyanolyan gyorsan hajtja vegre.
[code:1:ddf9700938]
SELECT * FROM (
SELECT ROWNUM AS ROWNUM1, ROWNUM3.* FROM (
SELECT
Entity8950046.OID AS OID , Entity8950046.fk_Adatgazda AS Id9410,
Entity8950046.Szallitoi_megnevezes AS Id9417, Entity8950046.fk_Utolso_modosito AS Id9416,
Entity8950046.Szallitoi_cikkszam AS Id9404, Entity8950046.Statusz AS Id9400,
Entity10170046.XML_Generalas_ideje AS Id11147, Entity10170046.fk_Szervezet AS Id11148,
Entity10170046.Elso_akt_idopontja AS Id11149, Entity10090046.Nev AS Id11058,
Entity10140046.Cikkszam AS Id11132, Entity10140046.Nyilvantartasi_nev AS Id11122,
Entity10140046.fk_Tree_order AS Id11142, Entity10140046.GTIN_eklista AS Id11123,
Entity10070046.fk_HSZ_azonosito AS Id11054, Entity10170046.OID AS DELEGATION_OID,
Entity10170046.Statusz AS DELEGATION_STATUSZ
FROM
Szallito___aru_viszony Entity8950046
LEFT JOIN Szallito___aru_viszo_D Entity10170046
ON Entity8950046.OID = Entity10170046.fk_Application_OID
AND Entity10170046.fk_Szervezet='1000430'
LEFT JOIN Partner Entity10090046
ON Entity10090046.OID = Entity8950046.fk_Szallito_azonosito_OID
LEFT JOIN Partner Entity12600046
ON Entity12600046.OID = Entity8950046.fk_Adatgazda_OID
LEFT JOIN Cikk Entity10140046
ON Entity10140046.OID = Entity8950046.fk_Cikkszam_OID
LEFT JOIN Cikk Entity10120046
ON Entity10120046.OID = Entity10140046.fk_Tapadogongyoleg_OID
LEFT JOIN Cikk_regi_azonosito_MN Entity10070046
ON Entity10140046.OID = Entity10070046.fk_Cikk_uj_azonosito_OID
AND Entity10070046.fk_HSZ_azonosito='1000430'
LEFT JOIN COOP_cikkcsoport Entity10130046
ON Entity10130046.OID = Entity10140046.fk_Tree_order_OID
LEFT JOIN Kisker__jovedekicsoport Entity10100046
ON Entity10100046.OID = Entity10140046.fk_Kisker__jov_csop_OID
WHERE
UPPER( Entity10140046.Cikkszam) -- ez itt csak functional index-el indexelheto
LIKE UPPER('1026864%')
ORDER BY Entity10140046.Cikkszam DESC) ROWNUM3
WHERE
ROWNUM <= 100 ) ROWNUM2
WHERE
ROWNUM1 >= 1
[/code:1:ddf9700938]
Hat ezen bizony azert lehet mit optimalizalni:
Az osszes olyan hely, ahol adatbazisbol jon az upper fuggveny bemenete, optimalizalhato ket modon:
- functional index felvetele a kerdeses mezore (itt pl. a cikkszam a cikk tablaban)
vagy functional index hianyaban
- egy plusz oszlop felvetele a tablaban ahol az upper-re konvertalt erteket tarolod a cikkszam-nak, vagy az iro kodbol beallitva, vagy triggerbol generalva az upperes mezo erteket, es ezt a mezot indexeled, esetleg mas mezoket is beleteve az indexbe, pl. itt az OID.
Az order by-ba itt nyugodtan teheted ezutan az upper-elt mezot.
Ezutan a szureshez fog index-t hasznalni, eddig pedig nem onnan szedte (kiveve volt functional index az upper(cikkszam)-ra a cikk tablan).
Persze nem arthat plusz oszlopokat beletenni az index-be.
Mindenesetre celszeru explain plan-t nyomogatni egy-egy ilyen query-re is, hogy lassad tenylegesen mit is csinal. Akkor is tanulsagos, ha nem jellemzo a query.
SOS !!
Szoval. Megfogadvan az elottem szolo tanacsat, megprobaltam kicsit varialni a shared pool es a masik ket memoriaparameter ertekevel.
A shared pool-t 300M-rol megprobaltam 200-ra csokkenteni, a masik kettot meg 50-50-el novelni.
Mindezt a csodalatos oemapp console alkalmazassal.
Kb. ket oraja fut, 1-es load-ot general. Amugy az adatbazis el. Terheles nincs rajta, a ra csatlakozo alkalmazast leallitottam.
Mit lehet tenni ilyenkor? Elore mondom, az adatbazist leallitani nem lehetseges!
Legyszi, ha valakinek van _pontos_ infoja ossza meg, mert ebbol sulyos para lesz holnap.
Elore is koszonom!