Keresés

Szerintem ez kell neked:

Parse out columns of a weakly typed ref cursor
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1895778276754

Az trivi, hogy a ref cursor egy szimpla pointer és esélyed nincs normál körülmények között kinyerni a describing infókat. Thomas Kyte a fenti cikkben láthatóan vázol egy workaroundot, de bevallom férfiasan kétszeri elolvasás után sem értem az elgondolása magvát, meglehet azért mert egésznapi agymunka után, hullafáradt vagyok már.

Holnap ha nagyon nem boldogulsz, megpróbálhatunk ismét nekifutni...

Sziasztok,

van valami ötletetek arra, hogyan lehetne a ref cursor által visszaadott öszlopokról leírást kinyerni (dinamikusan szeretném megnyitni a cursort, nem a ismerem előre a szerkezetét).
DBMS_SQL.DESCRIBE_COLUMNS eljárással találtam megoldást (http://www.oracle.com/technology/oramag/code/tips2003/042003.html) , de ahhoz a ref cursor-t is ezzel a csomaggal kell kezelni, nálam a ref cursor-t visszaadó eljárások adottak, abba nem tudok belenyúlni).

Az Sql*Plus tudja valahogy, ezt a kiírást szeretném megcsinálni egy pl/sql eljárásból:

create or replace procedure emp_refcursor (p_dept in emp.deptno%type, p_cur out Sys_Refcursor ) is
begin
Open p_Cur For 'select empno,ename,job from emp where deptno='||p_dept;
end;
/

SET LINESIZE 1000;
SET PAGESIZE 1000;
VAR X REFCURSOR;

BEGIN
emp_refcursor(10,:x);
END;
/

PRINT X;

Egyrol beszelunk, csak nem tudom kifejezni magam.

A scenario annyi volt, hogy egy reporting adatbazis frissult ejjelente. A webes reportok az MV-bol kerdeztek le. A refresh idotartamara a web nem volt leallitva.

Amig a fast refresh megy, addig jo, mert a report vagy a tegnapi adatokat mutatja, vagy mar a maiakat, koztes allapot nincs.

Viszont ha complete refresh van, akkor amig az fut, addig az MV ures, a report meg hulyeseget mutat. Ha valaki felkel hajnalban dolgozni, baromsagot lat.

vajk

Lehet, hogy el kéne olvasnod a referenciát... ;) ->NEXT SYSDATE + 1 a naponkénti;

Itt is lehet gáz a sysdate elcsúszásával... (például shutdown+startup után). Én jobb szeretem vagy kézzel vezéreltetni a frissítést (operátori indítás), vagy külső plsql progival - a dbms_job segítségével - korrekten beállítani az aktuálisan következő effektíve helyes adattartalmú konkrét időpontot.

Nem vagyok DBA, viszont szívtam már meg ilyen jellegű üzemeltetési gondokat ("egyik kéz nem tudja mit csinál a másik"). Lehet, hogy van korrektebb kezelés is, nekem a fenti módszer vált be.

Majd' elfelejtettem érdekes adalékként megemlítve (nem konkréten az alapkérdéshez kapcsolódva):

Nálunk egyszer volt olyan gond, hogy a végletekig optimalizált belött rendszerről készített MV-k 'on demand' Fast Refresh-e sem fért bele, a mentés előtt. Ezért felmerült a gondolat bennem (és implementáltam is, mivel nem nagy varázslás), hogy a logokat és a változást szenvedett rekordtartalmakat unloadoltam filerendszerbe, ahonnan ftp után az MV-k oldalán le lehetett 'játszani' (play) a scripteket a forrás rendszertől immáron függetlenül. A dolog működik, egyetlen szépséghibája volt: az Oracle egy nemdokumentált feature-ét használta ki megkerülhetetlenül, amit a megrendelő nem akart tolerálni semmiképp (ezért nem állt élesbe).

>Azt hiszem a válaszok megértéséhez is sokkal jobban kellene ismernem ezt a környezetet

Azt gondolom ('függetlenként' és nem 'hazabeszélve'), hogy az MV-k Oracle implementációja
- Nagyon jól megtervezett
- Nagyon jól sikerült fejlesztés (és fejlődik folyamatosan, pl.: limitek eltörlésével, vagy legalább kijjebb tolásával)
- Nagyon hasznos, nagyon jól használhatók a való életben
- és bizony nem kevés információ van a témában. 'query_rewrite' korrekt megértése például önmagában megér egy misét... Az Oracle maga is tán 2-3 napos tanfolyamot ajánl a témában (tán elsősorban inkább csak külföldön)

>Ez alatt azt értem, hogy a felh -k nem rögzítenek, töltenek be semmit csak és kizárólag lekérdeznek.
Ez szimpatikus, jól hangzik... Ráadásul, ha jól értem instance-on belül, ami külön öröm a párhuzamosítás lehetősége miatt.

>A feltöltés havonta több alkalommal, akár naponta többször is történik egy automatizmus alapján, de nem állandóan. Mikor a MV-k frissülnének az adatbetöltés, átemelés szünetel.

Ez a típikus 'on demand' frissítés igénye. Én is ezt szeretem jobban (ugyanis a MV-célplatform a frissítés megkezdéséig akár offline-ban is lehet, ami nagyon kellemes feature). Frissítés alatt elvben mehet adatbetöltés is, hisz a Fast Refresht támogató MV-logok mindig csak SQL-Insertekkel bővülnek bármely típusú DML esetén... Sőt mint mondtam a betöltés + frissítés vége utáni commit eredményezhet két adatkonzisztens Oracle objektumot (betöltött táblát + MV-t)

>Adatkonzisztencia
Ha jól értem elvben nem kell neked a refresh group. Hisz, ha nem töltesz, akkor a refresh groupon kívüli MV Fast Refresh-ek nem tudnak inkonzisztenciát okozni hiszen az alapadatok nem változnak.

Azaz szerintem jók a peremfeltételeid és elvben mindent tudsz a sikeres MV-zés megkezdéséhez... :o)

>a fast refresh az tranzakcios, tehat mindig ott az adat az MV-ben, csak delete/update/insert tortenik.

Szerintem 'lokális' értelemben nem 'tranzakciós' azaz nem 'DML'-enként, hanem csak a frissítés végén van commit (azaz 'globális' értelemben tranzakciós csak). Ennek legfőbb oka, hogy a hatékonyság miatti internal C-s Fast Refresh DML -> _nem_ SQL-szintű DML. Ezen közben persze selectálható az MV, de nem látható a menetközbeni fast-refresh-es változás.

Hogyha kétirányú szinkronizációt támogató updateable MV-kről beszélünk, akkor hogy milyen DML-ek megengedettek az mv-n a frissítés alatt, az külön történet. Nem is nagyon mélyedtem bele, nem is nagyon szimpatikus a lehetőség (noha elismerem, hogy az ügynökök laptopjain lévő változásokról akarhat tudni a 'központ')

>De a complete az a truncate miatt ugye committol az urites vegen.
A truncate DDL-művelet, tehát implicit - Oracle SQL-engine által kezdeményezett - commit van, így a frissítés során MV-be átjött rekordok a globális frissítési tranzakciós commit után láthatók csak, az én emlékeim szerint is. Mondjuk a magam részéről én _annyira_ nem voltam elégedett a performanciájával, annyira nem találtam tuningolhatónak és annyival jobban bejött az 'offline' módszer, hogy nem nagyon firtattam az egész complett refresh témát, sose... (És csak 9iR2-ig van csak tapasztalatom)

Milért van az hogy beírom ezt:

 

"

create materialized view tmp_mv_teszt_mv
REFRESH START WITH ROUND(SYSDATE-1) + 13/24 + 15/24/60
as
select INTID as mv_id,
INTKOD as mv_kod,
INTOEPKOD as mv_oep,
INTNEV as mv_nev,
INTTELJNEV as mv_telj_nev,
MEGJ as mv_megj,
INTKOD || ' - ' || INTNEV as mv_nev_kod
from tmp_mv_teszt;

"

 

és ez lessz belőle:

"

create materialized view TMP_MV_TESZT3_MV
refresh force on demand
start with to_date('04-05-2007 13:15:00', 'dd-mm-yyyy hh24:mi:ss') next null
as
select INTID as mv_id,
INTKOD as mv_kod,
INTOEPKOD as mv_oep,
INTNEV as mv_nev,
INTTELJNEV as mv_telj_nev,
MEGJ as mv_megj,
INTKOD || ' - ' || INTNEV as mv_nev_kod
from tmp_mv_teszt
"

hogy lehet megoldani hogy

minden nap ebben az időpntban frissüljön,

ne csak ma?

 

dz

 

Huuu

Azt hiszem a válaszok megértéséhez is sokkal jobban kellene ismernem

ezt a környezetet

Inkább leírom egy kicsit  pontosabban mire szeretném használni:

1.) Ez az adatbázis (10.2.0.0.0)  egy lekérdező adatbázis.

     Ez alatt azt értem, hogy a felh -k nem rögzítenek, töltenek be semmit

     csak és kizárólag lekérdeznek.

2.) A feltöltés havonta több alkalommal, akár naponta többször is

     történik egy automatizmus alapján, de nem állandóan.

     Mikor a mv-k frissülnének az adatbetöltés, átemelés szünetel. 

3.) Nem baj ha az új adatok, csak másnap lesznek hozzáférhetők a lekérdező

     felhasználók részére.

4.) Az mv-k pl. egy részletes adatkör felösszesítési szintjei lennének,

     illetve adattárház _jellegű_ működéshez használt BI-os

     adattartalom létrehozásához kellenének.

 

remélem érthetően fogalmaztam

köszönöm

dz

Javits ki, ha rosszul emlekszem, de mintha az lenne, hogy a fast refresh az tranzakcios, tehat mindig ott az adat az MV-ben, csak delete/update/insert tortenik. De a complete az a truncate miatt ugye committol az urites vegen. Regen hasznaltam mar...

vajk

Nagyon oda kell figyelni, valóban!

Rettenetes nagy futási idő különbségek vannak a full és fast refresh között. A fast refresh-t ugyanis agyon optimalizálták (internal C) Oracle Corp-nál, ezért is meglepően gyors... Míg a complett hiába truncate-tel kezdődik: a nagy teljesítmény veszteség a hálón keresztüli átnyomáson van, típikusan (adatmennyiség, dblink, -nemparallelizálhatóság, unoptimális Oracle hálózati architektúra rengeteg réteggel etc.)

A vázolt szituban meglehet nem elég a complett refresh preformanciája (nekem volt erre precedensem), ilyenkor ajánlott a klasszikus BCP/DR megoldás: eredeti tábla például tablespace transportos (fileszintű!) átmozgatása (de ezer más akár gyorsabb és/vagy drágább technika is létezik) és egyetlen paranccsal mv-vé alakítása.

Oda kell figyelni nagyon tehát az adminisztrációra, és a BCP/DR-re. És az ugye mindenkinek trivi, hogy a fast refresh log generálása jelentős overheadet tud generálni az eredeti OLTP folyamatokra nézvést?

Na és még két egymással összefüggő dolgot érdemes megfontolni, mivel több mv-t kell csinálnod:

- Konzisztensnek kell-e lennie a frissítés során a tábláknak? -> refresh group megfontolása

- A frissítési folyamat _kezdési_ időpontjára avagy _befejezési_ időpontjára legyen konzisztens?

BTW1: amit szeretnél az az 'on demand' frissítés (létezik szinkron frisssítés is, csak azért mondom)

BTW2: Vannak prerekvizitumai az fast refreshnek, mindenek előtt Primary Key, gondolom ez nem probléma...

BTW3: Nem kétirányú a frissítésed, ugye (kölcsönös szinkronizáció)?

Na ébredés után első nekifutásra... ;)

Egy dolgot nagyon meg lehet szivni:

a force azt jelenti, hogy ha lehet akkor fast refresht csinal, de ha nem lehet akkor fullt.

megy szepen a dolog, mindenki boldog, aztan egyszer valami miatt kimarad a refresh vagy hasonlo, es nem lesz eleg a refresh log (asszem igy hivjak) es inkabb fullt csinal.

a full viszont truncate majd insert, ergo lesz egy adatmennyisegtol es egyebektol fuggo nagysagu idoablak, amikor a tabla URES! ha kozben futnak dolgok amik hasznaljak az mv-t, jol pofara tudnak esni, es neha nem trivialis rajonni mi volt, mert napkozben nem reprodukalhato, es atlagember nappal dolgozik.

vajk

Köszönöm, kipróbálom.

Automatic Refresh Times for Materialized Views: Example The following statement creates the complex materialized view all_customers that queries the employee tables on the remote and local databases:

CREATE MATERIALIZED VIEW all_customers
PCTFREE 5 PCTUSED 60
TABLESPACE example
STORAGE (INITIAL 50K NEXT 50K)
USING INDEX STORAGE (INITIAL 25K NEXT 25K)
REFRESH START WITH ROUND(SYSDATE + 1) + 11/24
NEXT NEXT_DAY(TRUNC(SYSDATE), 'MONDAY') + 15/24
AS SELECT * FROM sh.customers@remote
UNION
SELECT * FROM sh.customers@local;

Oracle Database automatically refreshes this materialized view tomorrow at 11:00 a.m. and subsequently every Monday at 3:00 p.m. The default refresh method is FORCE. The defining query contains a UNION operator, which is not supported for fast refresh, so the database will automatically perform a complete refresh.

Sziasztok!

 

Kellene jó néhány MATERIALIZED VIEW -t csinálnom

amiknek egy beállított időben kell frissülniük. (pl 01:00-kor)

Melyik refresh-t használjam?

Hogy frissithetem a megjelölt pillanatban?

(Ha szabad kérni egy példán keresztül...)

köszönöm:

dz

-l

erdemes lenne leirnod, hogy mire ;))) csak hogy nem halljunk meg tudatlanul :)

Na,csak írnom kellett és rá is jöttem...:)

Hello!

 

Nem vagyok túl otthon a témában, így most egy kis segítségre lenne szükségem. Némely sorra azt írja ki az Oracle, mikor létre akarok hozni egy táblát, hogy ORA-01756 az idézőjelbe tett karakterlánc nem megfelelően végződik.

Az idézőjelek ugyanúgy vannak, mint a többi sorban, ahol nem ír ki ilyet. Tudna valaki segíteni?

Előre is köszönöm!

Lehetoleg 1K-s kiviteluekbol osszeallitva :-)

Valszeg igazad van, nem kell feltétlen anglománnak lenni...

Az szerintem is fontos, hogy egy adattárházakról szóló topic címében még véletlenül se szerepeljen az adattárház szó :-))

Egyébként is, ZX81 cluster rulez.

:-))

A thread már kezd lassan olyan lenni, mint egy nyílvános szellentés... ;)

>Framework :-)
Pfújjjj! :o) /Tényleg volt ilyen is... De erre már engem is emlékeztetni kellett... :o)/

Szigoruan III+ :-))
Melle office rendszernek Framework :-)

Ashton-Tate Dbase III+ vagy Dbase IV. Marhára nem mindegy! ;)

Megérdemelné, de ahhoz topicírók és topiclátogatók kellenének legelébb is, hogy ne fulladjon unalomba. Mindenesetre ha valaki létrehozza és még én is tudok róla, akkor felveszem a topic-favoritok közé, mindaddig amíg szinten tudjuk művelni az eszmecserét... :o)

Topiccím javaslat lehet a Business Intelligence és/vagy Knowledge Management D(ata)W(arehouse) alapokon. Abban triviálisan benne van a DW, mégis nagyobb esélyt kaphatna az érdeklődésre.

Dbase? :-))