Hat erre kategorikus valaszt nem nagyon tudnek adni.
A DBMS_SQL-el ugye tudsz csinalni parse, majd bind-execute, bind-execute, bind-execute ciklust pl, ami ugye hatekonyabb mint ha mindig van parse. De mostanaban ugye a query rewrite meg nemtomhogyhivjak cache ami a parseolt statementeket cacheolja kb ugyanazt tudhatja. Persze execute immediate-ben nincsenek bind variable-k (vagy vannak es tudatlan vagyok??), ha meg belekonkatenalod a parametereket, akkor ugyse tud reuseolni. Szoval nem vagyok egy tuning guru :-)
Ja! Jut eszembe! Mi manapság a deal? Az én emlékeim szerint a dbms_sql, korszerütlen már, halálraítélt, egyre kevésbé támogatott (fejlesztésileg). Mintha mindenhol az Execute Immediate-t támogatnák. Rosszul vélem?
Az elöző munkahelyemen security ok miatt tiltott volt a synonym. Bevallom én sem nagyon rajongtam érte sosem, mert óriási hibákra ad lehetőséget egy téves definició. Egyébként persze teljesen jogos észrevétel.
>Szeretnék egy függvényt, ami megkap egy tábla és egy mező nevét,
Igen, ahogy kiderült, akárhogy is fáj (pláne egy DW-snek), a táblanevet 'variálni' egy sql-ben csak dinamikus sql-lel lehet (és tárolt eljárásból, of course) -> nincs hack-lehetőség workaroundra.
Pedig milyen fincsi lehetne adott riportálásnál tYYYYMM táblákat valahogy kényelmesen kezelni statikus sql-lel is, ha úgy adódna -> pláne, hogy DW esetén brutál sql-ek is bírnak előfordulni, amit dinamikusra átírni csak ezért, nem mindig felemelő érzés.
Nem tudom hány rekordod van, OLTP-rendszerben-e, mennyire sokszor kellene mennyire párhuzamosan futtatni, egy-egy rekordra vagy full-táblára, meg egyáltalán hogyan állsz a NULL-okkal, de hogy mediánkeresésileg csak 12 meződ van mindenesetre biztatóan hangzik. ;)
Én első nekifutásra a 100% pure sql/view-ben gondolkoznék. Azaz sor-oszlop transzformációval minden rekordból csinálnék 12-et, majd inline-view-s order by után a 6-7-dik rekordokra group by-os avg-t csinálnék. Leginkább azért, mert az Oracle gyári internal order by, biztosan optimálisabban fog futni, mint a VARRAY-os rendezési implementációd, ráadásul e vázolt sql-sem ígérkezik nagyon durvának.
BTW: Nem tudom mennyire közismert: létezik O(n)-s algoritmus (rendezés nélkül) mediánkeresésre, ha egyszerre nagyon sok rekord nagyon sok elemjének mediánja kellene, nagyon sokszor, nagyon párhuzamosan, gyengébb szerveren etc.
Egy olyan rekord szintű függvény elkészítéséhez kérem a segítségeteket, amelynek a bemenete a rekord 12 number típusú mezője, amely értékeket beteszi egy VARRAY tömbbe, majd rendezi, és meghatározza a medián értékét. Majd további műveleteket végez.
A kérdésem az, hogy tartalmaz-e a PL/SQL a VARRAY-re vonatkozó rendező eljárást, vagy ezt nekem kell megírnom.
Nezd meg itt: http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_rls.htm#i1000830
En nem neztem vegig, de talan megtalalod a Neked legjobb policy beallitasokat. Vagy, ha mas nincs akkor meg talan itt: http://download.oracle.com/docs/cd/B19306_01/network.102/b14266/apdvcntx.htm#sthref2414
Az eredeti problemam (http://forum.index.hu/Article/viewArticle?a=69893049&t=1001339) annyiban lett egy kicsit cifrabb, hogy nem a tiltott rekordok elrejtese a cel, hanem meghatarozott adatmezok kimaszkolasa. Ha a DBMS_RLS.ADD_POLICY-t sec_relevant_cols_opt => DBMS_RLS.ALL_ROWS hivom, akkor a sec_relevant_cols-ban megadott mezoket kimaszkolja, de sajnos NULL ertekre. Meg lehet valahogy oldani, hogy ne NULL, hanem egy altalam definialt erteket kapjanak a kimaszkolt mezok? (raadasul mezonkent mas-mas) Elore is koszi!
Aztan nagyon vigyazni, nehogy letrejohessen olyan szituacio, amikor a p_tabla ertekekent valami vicces sql jojjon, ami letorol ezt azt, vagy olyan adatot ad vissza amit nem kellene.
marmint hogy a keresett tabla nem abban a semaban van az exportfileban, mint amelyik semat importalod? O beimportalta azt, amit kertel. Nem sorolhatja fel hogy mik azok az objektumok, amiket nem kertel...
Újból egy kérdésem lenne, és ismét csak importálással kapcsolatos;-)
A héten kaptam legalább 20 kiexportált Oracle fájlt. Ezeknek a fele double-byte adatbázisból van, a másik fele normál. Az utóbbiakat sikerült is importálnom gond nélkül, viszont az előbbiekkel gondom akadt. Az UTF-8-as környezetet létrehoztam, és két idődimenzió forrásául szolgáló táblát importálni is tudtam, viszont többet nem. Amikor log file-t kérek, abban az található, hogy: "Az import sikeresen, figyelmeztetések nélkül fejeződött be."
Ilyen viszont nincs benne: "a következő tábla importálása:"CPOS_MDNE_TIME_PERD_CUBE" 2925 sor importálva "
És amikor megnézem az adatbázist, abban sem szerepel új tábla.
Két gépen is próbálkoztam, ugyanolyan eredménnyel.
Ha pl. letrehozok egy ugyfel tablara egy olyan policyt, hogy csak az "A" betuvel kezdodo ugyfelek jojjenek a selectbe, akkor a select jol muxik, a count csak az "A" betuvel kezdodo ugyfelek szamat adja vissza, de a Max(ugyfelnev) siman vissza adja az "XY Kft."-t.
Miert kellet sajat NLS? Migraltunk egy Sybase-s rendszert, es ott olyan sajat collate seq volt definialva, ahol a kis-nagybetuk nem voltak megkulonboztetve, es a program is ennek megfeleloen mukodott (http://forum.index.hu/EditArticle/ReplayEditArticle?a=49546315&t=1001339) Vegul is letre hoztunk egy HUNGARIAN2 a Local Builder-el es azzal allitottuk fel az adatbazist. Minden ok volt, kiveve a Min-Max, az tojt ra. Kaptunk egy athidalo megoldast a supporttol, de az olyan lassu volt, hogy elsirtam magam. Vegul sajat fuggvenyeket irtunk helyettuk.
