Úgy szeretnék egy tárolt eljárást elindítani, hogy az elindítást követően nem várnám meg míg lefut (az eredmény táblában lesz, így mikor lefut ráérek vele foglalkozni). Ha job-ként adom fel úgy működik, de kérdezném, hogy nincs-e valami egyszerűbb megoldás.
Még a 11g doksiban is az szerepel, hogy csak NULL lehet a maszk.
Annyit tehetsz esetleg, hogy teszel rá egy nézetet, és ebben alakítod át a NULL-okat a neked kellő értékre. Így a jogosultságkezelés érdemi részét elvégzi az RLS, a nézet pedig a megjelenítést szabályozza.
Bizony. És az milyen szép lesz majd, amikor a 11g-ben holmi unalmas aggregált táblák helyett majd OLAP kockákra fognak átíródni a lekérdezések. Előre könnybe lábad a szemem ;-)
Tényleg, ki jön jövő csütörtökön a magyar 11g kickoffra a MOM park mozijába? Állítólag maga Ken Jacobs (dr. DBA) fogja tartani a keynote előadást. Róla ennyit érdemes tudni: "Since helping to establish the first Oracle office in Washington , DC in 1981, Mr. Jacobs has been a prominent spokesperson for Oracle and an advocate inside the company for customers' interests."
>De mostanaban ugye a query rewrite meg nemtomhogyhivjak
A query_rewrite azt gondolom egy kicsit más cucc, noha végsősoron neki is az a célja hogy általa jobb legyen a performancia -> Szemben a bindolással, amit az OLTP rendszerek szeretnek nagyon, a query_rewrite-ot a DW-sek szeretik nagyon, elsősorban nekik lett kitalálva, az MV-k kapcsán. Az elemzésére nem vállalkozhatom egy szűk fórumos hozzászólásban így alvás felé kacsintgatva :o) -> tudható, hogy vonatkozó Oracle tanfolyamon órák mennek el rendszerszermléletű tárgyalásával.
Egy first lookos tárgyalása itt van (amikor New Feature volt) http://www.akadia.com/services/ora815nf.html
>tudsz csinalni parse, majd bind-execute, bind-execute, bind-execute ciklust pl, ami ugye hatekonyabb mint ha mindig van parse.
Ha ezt nem tudná az execute immediate, akkor erősen kukába való cucc lenne. Az Oracle egyik legnagyobb fejlesztése volt, annó, tán Oracle 6 környékén. Nélküle nagyon sok OLTP-rendszer bírna döglődni, főleg manapság.
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.
