Sziasztok,
nem biztos hogy jo a cim, mert nem megoldani kell performanszot problemat, hanem megfejteni, hogy mi futott az adott szerveren visszamenoleg par hete.
Adott egy oracle db amin van egy SQL query aminek a futas ideje eleg hektikus. Egyszer 2,5 masszor 5 ora. Tehat nem a kodot okoljak erte a fejlesztok, hanem a szerverre gyanakszanak. OS szinten nem en adminolom az application servert - en csak az apache/tomcat-jukat hekkelem- de szeretnek tudni a fejlszetok, par napra/hetre visszamenoleg, hogy az adott ido intervallumban - vagyis mikor a query fut - futott e valami heavy cuccra rajta (pl backup abban az idopontban. Monitoringra hyperic es nagios van, de ezek nem annyira alkalmassak erre..
Valami otlet hogy tudnam kihamozni mik futottak a gepen par napja ejjel :)?
koszi elore is
- 1325 megtekintés
Hozzászólások
Ha futtatsz AWR reportot az adott idointervallumra akkor fog latni mit csinal sz adatbazis.
- A hozzászóláshoz be kell jelentkezni
Tehat nem a kodot okoljak erte a fejlesztok
B+, minden fejlesztő ilyen.
"Én biztos jó query-t írtam, csak a géppel lehet a baj."
Most akkor értenek hozzá, vagy nem? Ha csak találgatnak, akkor nem értenek hozzá. Ha csak a "jelenség" paramétereiből (egyszer 2.5 óra, máskor 5) következtetnek, akkor nem értenek hozzá. Ha nem értenek hozzá, akkor értelmetlen bármiféle spekuláció a részükről, hozzáértő szemmel kéne megnézni _pontosan_, hogy mi is történik a query futtatásakor (plan, trace).
Valami otlet hogy tudnam kihamozni mik futottak a gepen par napja ejjel
Ha be van kapcsolva az oracle-ben a statisztikagyűjtés, meg fent van az enterprise manager, akkor szépen meg lehet nézni a webes felületen, még szép grafikákat is ki lehet nyerni ott. De ez nem helyettesíti a fentebb írt pontos query elemzést.
Egyébként mekkora az adatbázis, és mennyi és milyen diszkek vannak alatta?
- A hozzászóláshoz be kell jelentkezni
Nem irtad milyen OS, de mondjuk a sysstat elárul pár dolgot OS oldalról.
-
Debian Squeeze
- A hozzászóláshoz be kell jelentkezni
igaz bocs, RHEL 5.7.
egyebkent egy kis analizalas utan ugydontottunk, ez bizony oracle db related cucc, szoval ment a dba-knek nyomozasra.
Igazabol csak azt kellet volna megerositenem, hogy estenkent 8 es ejfel kozott, mikor is ez az sql futkarozik, nincs valami heavy cucc kozben ami lefogja a gepet.
koszi sracok!
- A hozzászóláshoz be kell jelentkezni
ők meg valszeg visszaköpnek egy statisztikát, hogy a lekérdezés ígymegúgy eltér az optimálistól, s vissza a developernek.
- A hozzászóláshoz be kell jelentkezni
Jó és szükséges dolog a specifikálódás, de pont a DB szint az, ahol a szélsőséges szegmentálódással (csak hogy ne hívjam a nevén: felelősséghárítás) jól meg lehet szívni.
A fejlesztőnek muszáj legalább informálódás szintjén törődnie azzal, hogy milyen a db kialakítása (pl. nemlétező indexnek megfelelő feltételre akaszkodni, feleslegesen index nélkül order/group byolgatni halálos ítélet a teljesítményre).
A dba-nek muszáj ismernie a db-je alatt lévő vas kialakítását, hogy ne okozzon tragédiát - hasonlóképpen a fejletsztők szándékait.
Az os adminjának pedig muszáj tudnia, hogy milyen igényei vannak a dba-nek ahhoz, szolgáltasson és ne megkeserítsen.
Amúgy ha reverse engineeringnek kell sorra kerülnie, az azt jelenti, hogy potenciálisan mindenki elcseszett vmit, és az a minimum, hogy mindenki párhuzamosan debuggolja a saját oldalán, amit csak lehet - valami javítanivaló úgyis lesz mindenhol.
- A hozzászóláshoz be kell jelentkezni
2.5-5 órán át futó SQL oracle-n?
* vagy el van baszva maga a lekérdezés (nincs/rosszul van optimalizálva)
* vagy el van baszva maga a cél, amiért ez a query kell
ez a kettő lehetséges.
Ja, és MINDEN fejlesztő olyan, hogy minden (és mindenki) mást okol, kivéve a saját kódját, szóval ne hagyd magad :-)
- A hozzászóláshoz be kell jelentkezni