Keresés

mibol futtatod?

a dbms_output az egy utility amivel tudsz plsql-bol kimenetet irni. a set serveroutput on az a szokasos oracle toolokban annak bekapcsolasa hogy a kliens ki is irja a dolgot. sqlplusban vagy sqldeveloperben mukszik tutira, nem szokott kelleni hozza speci jogosultsag. milyen hibauzenetet ad?

Vajk

Köszönöm szépen a segítséget, ezzel együtt, a

- set serveroutput on    

sor nem fut le - itt lesz egy jogosulatlanság hozzá..

Ezt a sort kivéve pedig lefut a többi rész, (declare - end) ám nem jelenik meg a képernyőn az eredmény, csak annyi, hogy Done .... sec alatt lefutott.

Ezzel lehet valamit kezdeni?

Kifaragtam neked:

set serveroutput on
declare
d date;
begin
  for s in (select table_name from user_tables where rownum<6) loop
    begin
      execute immediate 'select scn_to_timestamp(max(ora_rowscn)) from '||s.table_name into d;
      dbms_output.put_line(s.table_name||' '||to_char(d));
    exception
      when others then dbms_output.put_line(s.table_name||' no luck: '||sqlcode);
    end;
  end loop;
end;
/

-- jo lassu a nagy tablakra

-- van benne egy rownum<6 hogy csak az elso 5 tablat mutassa

-- ha regi az scn, nem tudjuk megmondani a pontos datumot

Vajk

Valószínűbb, hogy jogosultsági korlátozás miatt nem tudom ezt futtatni... 

Próbálkozom vele, ám nem megengedett változónév a 7. sornál hibaüzenet, szerintem a max(ora_rowscn) -el lesz valami gond..

Ez pedig saját kútfőből egy eleve rossz próbálkozás? - jelenleg elszáll azzal, hogy a max függvény csak sql statementnél használható.

declare
    cursor mutato is
       select table_name from user_tables;
begin
    for mutato_record in mutato
      loop
          scn_to_timestamp(max(ora_rowscn));
      end loop;
end;

pszeudokod:

set serveroutput on

declare 

 d date;

begin

  for s in (select table_name from dba_tables) loop

    execute immediate 'select max(trallalala) into :1 from '||s.table_name into d;

    dbms_output.put_line(s.table_name||' '||to_char(d));

  end loop;

end;

/

Vajk

Sok táblánál kellene ez az adat, így a unionozásnál hátha lenne szebb megoldás..

Esetleg valamilyen ciklussal/cursorral végig lehetne lépkedni a táblákon (mondjuk egy adott user/schema alá tartozókon) és táblánként kiíratni ezt a frissítési adatot?

síma select-el lehívva ugyan megkapható a teljes táblanév, (pl user||'.'||táblanévŰ) ám azt nem eszi meg a rowscn-el együtt..

select to_char (scn_to_timestamp(max(ora_rowscn)), 'YYYY.MM.DD HH24:MI:SS') AS Utolso_TABLANEV1
from TABLANEV1

union

select to_char (scn_to_timestamp(max(ora_rowscn)), 'YYYY.MM.DD HH24:MI:SS') AS Utolso_TABLANEV2
from TABLANEV2

union

select to_char (scn_to_timestamp(max(ora_rowscn)), 'YYYY.MM.DD HH24:MI:SS') AS Utolso_TABLANEV3
from TABLANEV3;

A dolog azon alapul, hogy minden block header-ben ott van utolsó módosításának az SCN-je.

Még azt is meg lehet(ett volna) csinálni, hogy a táblákat rowdependencies enabled attribútummal hozod létre és akkor még azt is tudod, hogy melyik sor lett utoljára piszkálva.

és a harmadik:

audit insert, update, delete, select on TABLANEV1;

audit insert, update, delete, select on TABLANEV2;

audit insert, update, delete, select on TABLANEV3;

ebből még azt is, hogy ki és mit módosított.

(persze az overhead-del kalkulálni kell)

Arra figyelni kell, hogy csak korlátozott ideig működik:

The association between an SCN and a timestamp when the SCN is generated is remembered by the database for a limited period of time. This period is the maximum of the auto-tuned undo retention period, if the database runs in the Automatic Undo Management mode, and the retention times of all flashback archives in the database, but no less than 120 hours. The time for the association to become obsolete elapses only when the database is open. An error is returned if the SCN specified for the argument to SCN_TO_TIMESTAMP is too old. 

(ha túl régi, hibát kapunk)

1. a select tablabol olvas

2. hogy melyik tablabol, az nem tud parameter lenni

szerintem van esely ra hogy talalsz olyan nezetet, ami megmondja a tabla scn-jet. ha megsem, akkor meg ossze kell unionozt a cuccot

select bbbb from tab1 union all select bbb from tab2 union all...

aztan irhatsz egy select-et, ami a dba_tables alapjan generalja a fenti sql-t.

Vajk

Most már csak arra kellene rájönni, hogy egy listát hogy lehetne kiíratni - 

táblanév 1, utolsó módosítási dátum

táblanév 2, utolsó módosítási dátum

táblanév 3, utolsó módosítási dátum

- módon..

A táblanevek listázása tetszőleges név kezdőbetűkkel megvan:

SELECT table_name
from all_tables
where table_name like 'táblanév előtag%';

de ez nem illeszthető az előző query from részébe, mert nem ismeri annak a ora_rowscn tagját hibaüzenettel nem fut le...

Ha minden igaz ez az:

select to_char (scn_to_timestamp(max(ora_rowscn)), 'YYYY.MM.DD HH24:MI:SS') AS Utolso_modositas
from TABLANEV;

Sziasztok,

Arra van valami parancs, amivel lekérdezhető lenne egymenetben több tábla utolsó frissítési dátuma?

Amikor csak a kerdest olvastam, a LIStAGG fuggveny jutott eszembe

a túl sok adat pedig bekavart a pivot adat rendezésébe - osztályozásába...

Ahh... pivot-al végül könnyedén meglett a megoldás, amit előzőleg azzal hibáztam el, hogy túl sok adatot hívtam le a pivot select részében... Tanulópénz..

Vannak oldschool workaroundok. Meg van a pivot, asszem 10-tol

Sziasztok.

A régi jó öreg kérdés:

Miként lehet függőleges oszlopból vízszintes sort csinálni?

Konkrétan a képen látható megjelenítést szeretném elérni.

Haverszki,

Nemi ismersz minket. Az itteniek Győrig elgurigatnának  egy húszért 1 forintot.

:)

Sziasztok!

1-2 napja foglalkozom az Oracle termékeivel.
Van egy Oracle 11.2.0.3-as db-nk. A kérdésem pedig az, hogy .NET, illetve C# fejlesztés esetén elég-e ODAC telepítése (ami tartalmaz instant klienst) vagy pedig szükséges klienst is telepítenem?

A válaszokat előre is köszönöm!

(Off: Esetleg iskola/egyetem/tudományos intézet? Azokról esetleg el tudom képzelni, hogy a megtakarítás jegyében elfogadnak kisebb-nagyobb üzemszüneteket, átállási gondokat, funkcionalitás-csökkenést.)

Igen view-kra gondoltam aztán végül én is, mert hogy akkor azokat szépen lehetne grantolni adatszótárlekérdezés alapján.

Talenddel szépen le lehet capture-ölni a view-kat, az egyetlen megoldandó feladat )ekkora méreteknél), hogy jó sorrendben kell ezt megtenni a beágyazott view előbb jöjjön létre a PostgreSQL-oldalon.

És igen: nem lesz gyors. ;)

Olyan trükkök persze már előjöttek, hogy userenv-lekérdezéssel rákérdez a LANG(nyelvre), hogy ennek megfelelő nyelven jöjjön a select-resultset,ilyenből van nem is kevés. :)

Én ezen kevésbé csodálkoztam, sokkal inkább azon, hogy az Oracle oldalon hogy bírt ekkora gigantikus méretű kupleráj lenni.

Nekem azt senki ne mondja nekem, hogy nem férne rá egy alapos konszolidáció erre az adatbázisra, csak ugye ki csinálná meg és pláne ki fizetné ki.

(Off: Ez komoly? Volt olyan felelős vezető, aki erre rábólintott? Normálisan egy céges rendszerben egy-egy Oracle alverzióváltást is hosszas 'merjük-ne-merjük' rinyálások előznek meg, mert mindenki tudja, hogy mennyi akna lehet elásva abban is... Na de ez... Még jó, hogy nem sqlite-ra...)

Legalabb meg sok sema is?

Nem hasznaltam meg pgrest sosem, tenyleg nincs benne szinonima? Akkor helyettuk view-kat kell csinálni?

Mivel plsql-ben vagyok otthon, valoszinuleg nekiallnek plsql-ben irni egy generatort, ami olvassa az adatszotart meg a dbms_ddl-t, es fossa ki a pgres ddl-t. Aztan apro lepesenkent tesztelni. Nyilvan elotte jo lenne atlatni hogy van esely arra hogy az egesz mukodjon. Gbyte DDL az durva, mindenkeppen baromi sokaig fog futni.

Aki hasznal tervezoeszkozoket, vajon tud olyat aminek lenne eselye lecapture-olni az oracle db-t, es siman legeneralni a pgres ddl-t?

Vajk

Sziasztok skacok,

Topik: Oracle szinonimák migrálása PostgreSQL alá (ahol nincs is ilyen ugye)

Az adatbázis brutál nagy: többszáz user, soktízezer (egymásba is ágyazott, private és public szinonimákra is hivatkozó) VIEW-t tartalmaz (csak a VIEW-definiciók text-állománya GB-os nagyságrendű)

Nehezítés: VIEW és ctid(PostgreSQL-specifikus ORACLE ROWID) együttes menedzselése.

Amit lehet géppel kéne csinálni, nem kézzel, értelemszerűen.

Ki hogy fogna hozzá? Én ott tartok, hogy egyelőre kaparom össze magamat a romokból, miután letaglózott a kérdés. ;)

Részben csatlakozom.

Továbbá, ha már ide jut a szituáció, akkor azért egyéb kérdések is felmerülnek. Pl., "jó-e" az adatbázis. Megvannak a kulcsok, indexek?

Ha igen, akkor lehet retrofitelni egy ERD-t, ami a Designerben valahol a fogalmi és logikai modell között van, mindenképpen jobb képet ad a dolog felépítéséről mint a tábla diagram, márpedig az eredeti kérdés azt hiszem főleg az áttekintésre irányul.

Ha kulcsok hiányában a retrofit béna, azokat úgyis erősen tanácsos pótolni. 

Egy tábla/séma diagramon ugyan látszanak a konkrét kulcsok/indexek, de inkább csak a káoszt fokozzák. (Nem véletlenül kapcsolható ki-be az összes függelék.)

Én ilyen esetekben igyekszem visszajutni ERD-re, ott szüttyögni, majd ismét "előre" a reprezentáció felé.

Normális db-n működik ez a módszer, de sajnos nagyon sokan nem adatbázist terveznek, hanem csak táblákat hánynak egymásra.

Eszköz. A Designer félholt. A Oracle Data Modeler félig-meddig tudja pótolni.

A 3D megjelenítés nem nagyon megy, az az Asimov-féle Alapítvány hogyishívják-eszköze:-)

Lehet színekkel csoportosítani, kézzel elrendezni egy nagyméretű diagramon sok táblát, és kisebb diagramokra elosztani az entitásokat/táblákat. Ez utóbbi esetben nyilván a szétszedett  kapcsolatokra figyelni kell.

az ember vizualis. viszont a tajekozodasa elegge statikus. tehat idovel jol kiismeri magat egy 3d strukturaban, felteve hogy az a struktura allando. 2D struktura detto. tehat egy olyan abra, ami allandoan talakul, morfolodik annak megfeleloen hogy mit teszel kozepre kiismerhetetlen. automatikusan generalni egy olyat, amin elsore minden ugy van egymas mellett ahogy logikus, az megteljesen eselytelen.

azert erzi az ember elveszettnek magat, mert nem latja at az egeszet. es azert nem latja at, mert nagy, es egyszerre csak kis reszet latja. valahogy particionalni kell. a particiok egyesevel mar atlathatobbak, egymashoz valo magasszintu viszonyuk szinten megertheto. a faba rendezes egy egyszeru particionalasi modszer. 

en korabban ilyen problemakat designerrel kezeltem. capture, behuzom az osszes tablat es FK-t. Feldobja egyetlen diagrammra, oriasi makaroni az egesz. Keresek egy tablat amirol tudom mi, kiteszem a szelere, es a referenciai alapjan elkezdem huzogatni melle a baratait. mikozben kibogozom es atlathatova teszem, kicsit meg is ertem. es vegul is az a cel hogy ertsem. 

persze minden eset mas, en meg csak itt visszaemlekezem a szep idokre.

Vajk

Hosszasan ecsetelni lehetne mi hogy nőtt túl.. igen kb ilyesmi...

Lehet kérdezni hogy minek 3D, meg tessék csak beállni fát vágni, de szerintem nem ez a hozzáállás visz előre. Szerintem könnyebben megérthetővé tenné az adatbázis felépítését / az adattáblák egymáshoz kapcsolódó viszonyát, ha pl egy 3D-s hálót mindig oda forgathatnál amelyik táblának a többiekhez való kapcsolódását (és egyéb infóit: index, kulcs, stb) láthatnád. 

Az ember alapból, biológiailag vizuális típus...

Nem ertem minek 3D. A szokasos sema diagrammok miert nem jok? Par szaz tablara hasznaltam mar sokat, eltart amig kitalalod a megfelelo elrendezest, de kozben pont megerted a tortenetet. Azt meg hogy megertsd nem lehet elkerulni. Idealis esetben persze forditott a sorrend, elobb van a diagramm, es utanna az adatbazis.

Vajk