Hasonló problémám van, mint amit lejjebb vázolt egy kolléga. Adott egy delphiben írt alkalmazás, ennek az éles verziója egy Oracle 10gR2 64 bites RAC clusteren fut, Standard Edition, egy sémában. Ez a séma át van másolva teszt célból más, 9iR2 single instance db-kre is, sima HP ML350-es hardvereken futnak. A 10g clusteren lassú a programban az ügyködés, de ilyen abszolút egyszerű dolgok, mint 200 rekordos táblában locate-es keresés, homokórát produkálnak. A 9i-n ugyanez mint a villám, ahogy normális lenne, sehol egy homokóra. A kliensprogram ugyanaz mindkettőhöz, csak egy setup.ini-ben van beállítva, milyen adatbázishoz csatlakozik. Ugyanazt a 9-es oracle klienset használják vagy a setup.ini-ben is lehet konfigolni, hogy közvetlenül (de akkor csak az egyik node-ra közvetlenül) csatlakozzék, a helyzet ekkor is ugyanaz. Mindegyik adatbázisban analizálva vannak az objektumok, frissen.
Van ötletetek? RAC-ban nem vagyok túl tapasztalt, hogy mit lehet ott elrontani, nincsen különösebb extra konfig benne.
Szeretnék minnél egyszerübben betölteni egy (fix hosszűságú struktúra)
txt fájlt betölteni egy ora táblába
Tehát minden féle külső .ctl és .bat és egyéb külső fájl segítsége nélkül.
Van rá mód?
(a csv nem megoldás, mindenképpen fix hosszűságú struktúra szükséges)
Vahogy igy szeretném:
:))
load data infile 'D:oracletext.txt' into table prbtbl ( MEZO001 position (01:05) VARCHAR2(5), MEZO002 position (06:10) VARCHAR2(5), MEZO003 position (11:16) VARCHAR2(5) );
ez persze egy HELYTELEN szintaxis csak így hátha érthetőbb mire gondolok.
Mi is áttértünk 9i-ről 10g-re, és korábban (sem) használtunk analitikát (RULE szabály van: a FROM tábla sorrend visszafelé a join sorrend), de a 10 alatt ha van statisztika, akkor azt használja, nem a rule-t (/*+ rule */ talán segít, de nem megoldás minden szelekthez beírni)!!! Ráadásul van fix job (v. hogy híjják újabban), ami minden este 22:00 körül lefut és gyárja az analitikát. Vagy ki kell ezt iktatni, vagy mögé egy job-ot, ami törli az analitikát :) És újra szárnyalnak a régi szelektek!
Inkább célirányosan gondoltam a v$session_wait-et. Amikor fut a lekérdezés, ami lassúnak bizonyul, akkor kellene megnézni, hogy mit mond az event oszlop. De a v$sesstat is jó infókat adhat a munkamenetről.
Az adatbázison belül érdemes esetleg egy v$session_wait-et (10-nél talán már a v$session-ban is meg van az event oszlop). Talán nem ártana egy konkrét lassabb select -nél végrejahtási tervet megnézni. Igaz, hogy 10-nél már nem ajánlják a
/*+ rule */ hintet, de láttam már csudát. Az analyze-al kapcsolatban is voltak negatív tapasztalataim. Leszedtem a statisztikát, és szárnyalt.
A top-on kívül esetleg egy "sar -d 5 5" . Lehet, hogy valamelyik disk jobban terhelt.
A megakasztjak alatt azt erted, hogy a cpu hasznalat felmegy, latod valami progival? Vagy csak hogy egyre lassabb?
Nem vagyok ott mostanaban az uzemeltetesben, de az biztos, hogy a hudeklafa diszk alrendszerek raid5-ben neha gyengebben MB/sec-re mint egy mezitlabas ide vinyo.
Ha teljesitmeny kell, akkor mirrort, vagy ha sok diszk van akkor S.A.M.E. -t ajanlanak. (stripe and mirror everything).
Oracle 10g alatt valaki tapasztalta már a következőket:
Van egy viszonylag nagy adatbázisunk 200GB, rengeteg táblával, a táblákban kb 1 millió rekord.
Amíg Oracle9i volt nem volt semmi sebesség problémánk.
Áttértünk Oracle EE-re, Külön storage, RAC,ASM stb.. új sokkal jobb hardver. (4 CPU, 4GB RAM) HP STORAGE. Ennek ellenére a 10 g sokkal lassabb a jó hardveren mint a 9i
Indexeket újra építettem, analitikák is frissek.
Érdekesség még hogy ha:
select * from table group by oszlop1,oszlop2 akkor használja a megfelelő indexet.
Ha select sum(x) from table group by oszlop1,oszlop2 akkor már nem használ indexet.
Az init.oraban a hash area és a sort area size viszonylag nagy.
