Gondolom, azzal újat nem mondok, hogy mindezek "ideális" esetben vannak.
Sajnos én még olyan dba+fejlesztői együttműködést nem láttam,tapasztaltam,hallottam, ahol mindenki tudta a dolgát és értette is, amit csinált.
Egyébként a storage paraméterek folyamatos karbantartást kellene, hogy igényeljenek (szerintem) és nincs az a fejlesztő, aki ezeket végig követi és karban tartja.
Lehet, hogy ez a téma örök vita téma marad. (Talán pont azért, mert nem láttam még precedens a tökéletes együttműködésre? Elméletben minden működik) :))
Hát, kedves hentes, ha otthon is így csapkodsz a bárdoddal, akkor ne csodálkozz, hogy nem tudsz zöld ágra vergődni a dbakkal! :(
Soha nem várhatod, hogy egy adatbázis adminisztrátor, aki a db futásáért, mentéséért, helyreállításáért felel meg akarja majd érteni az (1) üzleti igényeket, (2) a rendszer felépítését (3) minden egyes táblád jellemzőit (sorok, mezők száma, indexek, növekedés, update, törlés)
Sajnos ez a te dolgod. Tájékozódnod kell, hogy mi áll rendelkezésre, adhatsz tanácsot, hogy mi lenne hasznos az alkalmazásodnak, sőt kérdezhetsz, hogy melyik paraméter miért annyi, de régen rossz, ha a dba dönti el, hogy mit milyen storage-okkal tároljunk.
No, akkor pontositom a dolgot: a masodik esetben nem egyszeruen nekem kellett megmondanom a tabla novekedesneek merteket es hasonlokat, hanem a create scriptben, amit kuldok, _mindennek_ benne kellett lennie, reszletekbe meno storage parameterezesnek (pedig elvileg meg a blokkmeretet sem tudhatnam :)) es minden egyeb nyalanksagnak.
Az oke, hogy a fejlesztonek illik tisztaban lennie a mennyisegi parameterekkel (bar ugye online rendszereknel ezt a fejleszto elvileg sem tudhatja megbecsulni), de egy fejleszto kompetenciajanak odaig kene terjednie, hogy meg tudja mondani, melyik tablaban varhatoan mekkorak a rekordok, mennyi uj sor keletkezik, mennyi sor torlodik ekozben es igy tovabb.
Ez alapjan eldonteni, hogy melyik tablespace-be, mekkora extenteket, hogyan bovuljon, mekkora blokk-kihasznaltsag kell, ez mar szaz szazalekig a dba feladata es kesz.
(Az optimalizalasnal viszont pont az informalis beszelgetesek tudnak jol jonni, leulsz megdumalni egy problemat a dba-val, es jo esellyel tud szolgalni olyan tippekkel, amikrol nem is hallottal, mert mondjuk te nem toltheted azzal munkanapjaidat, hogy az oracle osszes beepitett csomagjat megismerd, o meg igen.)
Hat rohadtul nem, mert ugy kezdodik, hogy nem tudhatom, hogy melyik tablespace-be lenne jo rakni, mivel nem ismerem (nem is ismerhetem) az adatbazis ilyen iranyu parametereit, a dba-val meg ugye nem lehet normalisan beszelni.
Eleg konnyu lett volna pedig kitalalni, hogy ott volt jobb, ahol mindent meg lehetett dumalni a dba-val, az adattarolas mennyisegi jellemzoit meg a doksiban kell rogzitenie a fejlesztonek, a konkret storage parametereket pedig a dba adja meg, igy helyes.
Azt nem tudom, hogy melyiknél működtek jobban, de az a véleményem, hogy aki adatbázist tervez és olyan rendszert fejleszt, ami adatbázis műveleteket végez, az minimum azzal legyen tisztában, hogy mennyi adat várható és hogyan, plussz nagyon tanácsos ismerni az sql optimalizálási lehetőségeket.
Persze akad olyan dba is, aki vagy szarik az egészbe, vagy fogalma sincs róla, hogy mitől nem megy optimálisan a db, vagy gőze sincs hogyan vizsgálhatja.
Még 1x hangsúlyoznám, nem tartom magam annak aki mindent tökéletesen tud. (de törekszem)
Igazából nem csak erre gondoltam.
Én már sok olyat tapasztaltam, hogy a kedves rendszer tervezők és fejlesztők, nem nagyon tartják be, vagy fogalmuk nincs pl. arról hogyan kell storage allokációkat kezelni, explain plan-t használni és stb...
Azt nem mondom, hogy én mindent nagyon tudok és ismerek, de ha már Oracle-lel foglalkozom, akkor veszem a fáradtságot és utánna olvasok dolgoknak, ha nem vagyok tisztába vele és nem hagyom, hogy - teszem azt- szét fregmentálódjon az adatbázis és a idő után az SMON a kardjába dől.
Mondanom sem kell, melyiknel mukodtek jobban az adatbazisaink. Hát nyilván az, ahol te adtak meg a storage paramétereket.
Ha már egyszer te ismered igazán, melyik táblában mennyi adat van/kerül később, mennyi insert, mennyi update éri melyik mezőit, stb, stb, stb... ;-)))
ez mondjuk nem ez az eset. Az in-ben torteno felsorolas az mint a (x or y or z ...) forma. Ugye a parser leforditja a sajat nyelvere a te beirt sql-edet, es itt is ezt teszi.
Jo kerdes. Gyanitom, hogy RBO-nal lehet szamottevo kulonbseg, de ez csak sejtes. Ha CBO-nal van is kulonbseg kozottuk, annak el kene tunnie fokozatosan, mert elvileg errol szol a CBO.
(Hasonlo kerdes az x > a and x < b es a between kapcsolata.)
azt hiszem fontos tudas ez, de en nem tudom, ezert megkerdezem:
az sql wherejebe irt "id in (1,2,3,4)" es a
"(id=1 or id=2 or id=3 or id=4)" kozott oracle eroforrasok es optimalizalas szempontjabol mi a kulonbseg? Melyik az ajanlott? Es foleg akkor mi van ha tobb szaz elem lenne vizsgalatra?
B.
Na ja, en dolgoztam mindketfele helyen (ahol a dba-val barmikor ki lehetett ulni a konyhaba egy kave mellett megdumalni akar olyan kerdeseket is, hogy egy adott strukturat o hogyan tarolna, hogyan erne el), meg olyat, ahol meg a foglalasi adatokat is nekem kellett megadnom minden tablahoz.
Mondanom sem kell, melyiknel mukodtek jobban az adatbazisaink.
Valahogy ugy. En fejlesztettem 7.3 alatt is, itt instance szinten rule volt beallitva, igy minden egyes sajat session utan session szinten ezt atallitottuk es nagyban ment az SELECT-ek hintelese.
Attol is fugg am, hogy hanyas oracle van. Azt hiszem, a 8-asban meg nem volt default a CBO, de a tanult kollegak majd kijavitanak, ha hulyeseget mondtam. (Ha meg nem default, akkor vagy neked kell beallitanod, hogy olyat akarsz vagy a dba-nak.)
Köszönöm, inkább csak az elvi lehetőségre voltam kiváncsi, szóval, ha jól értem, a megoldás az lehet, hogy követeljem az adminisztrátortól statisztika készítését.
