Oracle exp

Adatbázis: SQL, XML DB

Kaptam egy 9.2.0.8.0 adatbázist, amiről szeretném az adatbázist kiexportálni.
Viszont csak 10.x kliensem van linux 64 bit.
Ezzel sajnos nem megy az exp.

Tudna valaki segíteni, hogy honnan tudok letölteni 9.x linux 64 bit klienst, vagy van valami megoldás hogy a 10.x-et használjam, bár ez utóbbira nem találtam megoldást.

  • 7236 megtekintés

( sfeher v | 2012. 10. 17., sze – 15:27 )

Elvileg felülről kompatibilis, tehát menni kellene az exp-nek.
Hibaüzenet esetleg ?

( zwei | 2012. 10. 17., sze – 15:30 )

A telepített 9.2 -es adatbázis szerverén a kéne legyen exp.
Álltalában a $ORACLE_HOME/bin alatt szokott lakni. Azzal kellene exportálni.

"van valami megoldás hogy a 10.x-et használjam"

nincs.

Ezt a dump-ot át tudom valahogy alakítani, hogy megegye egy pgsql?

Az "exp" dump emlékeim szerint egy bináris byte-halmaz, amit csak az "imp" utility tud megérteni.

Vagy mindenképpen egy oracle-ba kell tölteni, és onnan átemelni?

Maga az adatáttöltés is kérdéses, mivel ha csak a sorokra vágysz (INSERT-ek), akkor sem lesz sétagalopp, de az még megoldható szokott lenni.
De ha a táblastruktúrát is át akarod emelni, az tuti csak kézzel fog menni, ha pedig PL/SQL rutinok is vannak az adatbázisban, akkor "sok szerencsét"...

Csak az adatokra lenne szükségem.
A sima select célravezetőbb lenne, csak sajnos indexek hiánya miatt lassú a query és ebbe futok:
ORA-12801: error signaled in parallel query server P000
ORA-01555: snapshot too old: rollback segment number 18 with name "_SYSSMU18$" too small

Sajnos az egész egy fekete doboz, nem tudok hozzányúlni.

Ezt még1x mert nem teljesen jött át a mondandód :)

A query nem lockolja a táblát, a snapshot too old üzenetet azért kapod, mert amikor indult a lekérdezésed X időpontba neki az akkori adatokat kell felolvasnia, csakhogy változnak az adatok és a "régi" X időponti adatok az undo vagy rollback segmensbe kerülnek, ha viszont annyira sok a változás, hogy mire a query lefutna a "régi" adat már innen is kikerül és a szerencsétlen DB már sehonnan nem tudja visszaolvasni. ( na jó ez így nem teljesen igaz mert 10g óta a flashback technolgiák már ezt is megoldhatják de ez számodra nem játszik).

Szerk: Ha nem tudsz undo-t növelni akkor az egy nagyon jó 5let amit vl ajánlott, hogy egy backupot valahova máshova visszatölteni és ott "nyugodtan" kiexportálni/kiloadolni az adatokat.

Szerk2:Még 1 észrevétel: nem lehet, hogy most megy valami betöltés (sok adatot módosít) és ha más időpontba csinálnád a query-t akkor talán le is lefutna?

Sajnos a legutolsó, hogy a DB-hez hozzá nyúlhassak :(

Sajnos az adat betöltés folyamatos, illetve a kihulló adatok is valamilyen rendszerességgel kitörlődnek.
Nekem kizárólag a "tegnapi" adatokra van szükségem, ami nem változik, és nem érdekel, hogy a többi adat milyen változáson megy keresztül.
Azt szerettem volna mondani, hogy lehetséges olyan query-t megadni, vagy induló paraméterrel jelezni a session-ben, hogy ne törődjön a változásokkal, keresse csak meg az illeszkedést. Bár ez még kimondva is kicsit bugyuta, de hátha tud egy ilyen lebutított keresést.

Ha nem tudsz az adatbázishoz hozzáférni (nem vagy DBA, nem is engednek oda), akkor az egyedüli megoldás az marad, hogy írsz egy iteratív szinkronizáló programot, vagy megvárod, hogy ne legyen terhelés/folyamatos írás az adatbázisban.

Ha van primary key a táblában, és tudod, hogy a téged érdeklő adatok nem változnak meg, akkor szépen kulcs alapján elkezded olvasni, és amikor megáll a query, akkor újrakezded, az általad ismert legnagyobb kulcstól.

Ha semmi kulcs nincs a táblában, és nagy a tábla, akkor kb. a megoldhatatlan kategóriába esik a feladat.

Az a probléma, hogy olvasás közben valaki matatja alattad az adatbázist.
Vagy lemondasz arról, hogy konzisztens adatbázisképet tudjál kidumpolni (lecsökkented az sql sessionben az izolációt):
SET CURRENT ISOLATION = READ COMMITTED vagy READ UNCOMMITTED
Vagy kell sok és nagy rollback + undo tablespace.
Vagy meg kell állítani az adatbázist matató folyamatot.
Vagy kell csinálni egy online backup másolatot az adatbázisfájlokról, a másolatot máshol beindítani, és ekkor ezt a példányt immáron senki nem fogja alattad matatni, ergó simán lefut rajta a lekérdezés.

select * from tabla as of timestamp (to_date('2012.10.26 13:51','YYYY.MM.DD HH24:MI'));

ezt úgy hívják flashback query. Persze ettől még snapshot too oldot kaphatsz.
Kérd meg a dba-t hogy növelje meg az undo (régebben redo) táblateret és/vagy növelje az undo_retention_time db paraméter értékét.

Ha átadod a tudásod neked attól még nem lesz kevesebb belőle..

A dumpot nem fogod tudni átalakítani.
Több választásod van átemelni adatokat vagy csinálsz csv-ket és a másik oldalról valamilyen loader-rel betöltöd, vagy legyártatod az sql utasításokat és azokat töltöd be (ez sok adatnál szívás, a szerkezetet neked kell átírni és lassú) vagy használsz valami migráló toolt ami nem mindig ingyenes. (SQL developer-t nézd meg mert ingyenes csak nem minden másik sql-hez van migráló plugin)

http://www.oracle.com/technetwork/database/migration/omwb-getstarted-09…

pgsql-re nincs plugin.

( tamsa | 2012. 10. 26., p – 20:51 )

sqldeveloper a Te eszközöd ... az tud sql-t generálni, create, insert stb...

Ha átadod a tudásod neked attól még nem lesz kevesebb belőle..