Június 21-én prágai állomására érkezik a kifejezetten fejlesztőknek szóló 2 napos konferencia, az Oracle Develop: The Premier Conference for Developers. Korai regisztráció május 21-ig, valamint az első 30 magyar regisztráló között 2 ingyen éjszaka kerül kisorsolásra! További információ a konferencia honlapján. Remélem találkozunk!
Az idei nyár Oracle konferenciáiról olvashatnak a weblogomon.
Oracle konferencia fejlesztőknek!
Június 21-22-én Prágában Oracle Develop konferencia lesz. Az első 30 magyar regisztráló között 2 ingyen éjszaka kerül kisorsolásra! Bővebb infók a konferencia honlapján.
További Oracle konferenciákról infó található az első magyar Oracle Apex blogon.
Lajos
Még egy kérdésem lenne, hogyantudok több sort beszúrni egymás után.
Mysql insert into blalala (oszlopnevek) VALUES (blabal) és vesszővel elválsaztva be tudom rakni a sorokat.
Oracle alatt minden egyes insert nél meg kell ismételni a parancsot.
vagy lehetséges a 'mysql-es' felsorolás is?
Egyébként elég érdekes,hogy debian 4.0 magyar nyelven van telepítve,de angol
beállításokkal települ, nls táblákhoz sys felhasználóval ninsc hozzáférés (legalábbis nem tudom megváltoztatni alter sessionnal).
Windows alatt minden okés.
Szaiasztok!
Az NLS beállításokat hogyan tudom megváltoztatni
jelen pillanatban:
NLS_LANGUAGE american
teritory america
date language america stb
Köszönöm
Akkor is invalid lesz, ha simán szelektálok a táblából, szóval csak az kell, hogy az oracle számára nyilvánvaló legyen a függőség. A TAR-t egyébként nem találtam.
Ez a hozzáállás, hogy automatikusan újrafordul úgyis a következő hívásnál, nagyon jó, csak néhány bajom van vele: - honnan a szöszből tudom, hogy az adatbázisomban csak olyan invalidok vannak, amik lehetnének validok is - nem szeretem a felhasználótól megtudni, hogy valami baj van... - bizonyos csillagállásnál nem fogja lefordítani a kódot, hanem hibát jelez, hogy nem tudja futtatni (sajnos erre a csillagállásra még nem jöttem rá, hogy mikor is van, de jött már elő olyankor is, amikor én utána simán lefordítottam a procedúrát)
Az bíztató, hogy 10g-ben jobb lesz a helyzet - kár, hogy ezévben még nem állunk át :( Amúgy igaz, hogy sokat javultunk. 8i-ben ha hozzáadtál egy partíciót, az is invalidálta a proc-okat (legalábbis, ha volt global index is), mostmeg nem :)
A truncate egész jó ötlet, csak nem mi írjuk az alkalmazást, de most fogják kicsit átirogatni, akár bele is kerülhet.
Már régóta csináljuk így, automatikus újrafordigatással, csak egyre hosszabb ideig tart. Persze a delete egy nem partícionált táblán hosszabb lenne - meg sokat kéne move-olgatni.
Egy invaliddá vált procedúra simán továbbfut. Csak pl. visszahívni már nem tudja magát (meg más sem tudja hívni), mert először az Oracle implicite le akarja fordítani, ami nem megy neki, mert ugyebár fut. Na erre ítéletnapig képes várni az oracle (4 órát biztos :) hogy hátha befejezi a futását végre a procedúra. Explicit fordításkor ha jól emlékszem, 300 másodperc múlva a recompile hibára fut, ha nem tudja zárolni a procedúrát magának - márpedig ha fut, akkor nem tudja. Ráadásul újrafordítás után, azon sessionökben, ahol korábban már futtatták, a procedúra legközelebbi meghívásakor kapsz egy "object's state is modified" (vagy ilyesmi) hibát. Az ezután következő hívásnál ugyanebből a sessionből viszont szépen lefut!
Valóban "kicsit" problémás a dolog a motor oldaláról, de engem ettől még zavar :) Belegondolva, nem is tudom, hogy megy-e a drop partition, ha éppen select fut a táblára. Ha nem megy, akkor egyátalán nem értem, hogy minek invalidál. Ha megy, akkor triviális - elég nehéz kitalálni, hogy éppen kersztbe teszel-e a futó selectnek.
Nem találtam sehol olyan parnacsot, amivel le tudnám kérdezni, hogy egy táblában létezik-e az adott oszlop. Nagyon sok táblán kell lefuttatni vmit, de csak amiben egy adott mező megtalálható. Köszönöm.
Mar regen tul vagyunk rajta, az elso feladatok kozott volt annak idejen. Mondjuk erdekes, hogy a tobbi, altalunk hasznalt adatbaziskezelo automatikusan megoldja ezt a kerdest, csak az Oracle-es verziohoz kellett megirnunk.
>A legszebb az, amikor az invalidda valt objektumok kozott is van fuggoseg, es nem mindegy, hogy milyen sorrendben validalod... Ja-ja. Épp ezért erre a célra van a dba_dependencies (+order by). Vagy a brute force (isméltelten kellő számban végrehajtott fordítási ciklus kísérlet -> mindaddig legalábbis, amíg legalább egy objektum sikeresen fordul le) Egyébként ez érdekes téma, jó játék. :o)
"Package becomes INVALID when a partiiton is dropped" http://www.freelists.org/archives/oracle-l/06-2005/msg01247.html
A fenti link szerint, azért válik invaliddá egyes tárolt eljárások, mert nem varchar2(2), hanem t1.col%type-ként deklaráltál. Az előbbi esetben nincs invaliddá válás.
Kiegészítés1: külön történet az automatikus recompilálás. Ilyen kódot pár sorban nagyon könnyű írni. (És drop partition után futtatni). És aztán karosszékben kényelmesen hátradőlve azon merengeni, helyes-e az oracle Corp részéről ilyesmivel fárasztani a szegény usereket... ;) Másik lehetőség, ahogy mondják is: szétválasztani a drop partition témát az application témától.
Kiegészítés2: valaki nyitott TAR-t a témában a metalinken. Azt meglehet érdemes lenne megnézni (ha van élő supportod)
"Compile procedure automatically -- how to avoid cascading invalidations" http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:286816015990
"yes, that'll invalidate the package since the package is dependent on the TABLE (not the partitions therein) and the table has been structurally modified to a degree that necessitates recompilation."
"incremental refinements happens all of the time in Oracle - there are fewer invalidations in 10g than there were in 9i than there were in 8i than there were......."
>Van valakinek valami használható ötlete arra, hogy a függőség ne invalidáljon drop partition-ál? /9i2-őt használok/
Na azért szerintem óvatosabban az ilyen igényekkel... ;)
- First lookra megalapozottnak tűnik annak felvetése, hogy partició eldobáskor miért válik invalidussá az alattvaló objektumok. Valszeg azért, mert bonyolult művelet a drop partition (indexek azonnal mennek a levesbe, garmadányi data dictionary view stb.). És azért el lehet képzelni némi fantáziával, hogy van olyan pillanat, amikor _nem_ selectálható a folyamat során a tábla (és DDL-probléma miatt, nem DML-tranzakció probléma miatt!). De ez maradjon nyitott kérdésnek a továbbiakra.
- Nem mindegy, hogy view avagy store procedure válik invalidussá. De ezt most nem ragozom tovább, egyébként könnyen belátható.
- BTW.: Az első kézenfekvő ötlet: dinamikus sql használata a tárolt eljárásban. Ne nevessen senki: ez szerintem nem olyan hülyeség, ha egy eljárás több instance-ban érintett, és fel-le kapcsolgatják az instance-okat az üzemeltetés során. Az más kérdés, hogy ökölszabálynak ('mindent dinamikus sql-be!') én sem mondanám ki.
- Ha 8i-ben tennéd fel a kérdést, az némileg érdekesebb lenne. De ott is van megoldás (egy igen kevéssé dokumentált view): sys.order_object_by_dependency. Kombinálva /join formájában/ mondjuk a dba_objects-cel már lekérdezhető lenne a neked szükséges infó. Drop partition elött, of course.
- 9i-ben már van: dba_dependencies. Type-ok is korrektek már benne.
- Nem akarok hülyeséget mondani, de invaliddá vált procedure mintha nem nagyon futkorászhatna tovább szerintem az RDBMS-ben.
Sziasztok! Némi kényelmetlenséget okoz nekem az objektumok közti függőség: ha idő szerint partícionált táblákból régi partíciót eldobálok, minden ezt használó eljárás/view invalid lesz, aztán fordigathatom újra bőszen a fél adatbázist. Ami nem is olyan egyszerű, ha pl. fut egy frissen invalidált procedúra. Van valakinek valami használható ötlete arra, hogy a függőség ne invalidáljon drop partition-ál? Tudom, hogy az oracle által látott függőséget meg lehet szüntetni az "execute immediate" sűrű használatával (persze view-ra ez sem megoldás). De magával a függőség létezésével nincs bajom, mert segít az adatbázis egységét fenntartani (legalább tudom, hogy kinek mi kell, hogy működjön). 9i2-őt használok Köszi az ötleteket :)
