Keresés

Részletes keresés

dorog.zultan Creative Commons License 2007.10.04 0 0 2626
Volt,
így használtam az exp-et:

exp system/jelszo@connect file=./save/dump.dmp owner=schema1 compress=y consistent=y log=./log/log.txt rows=y

baj, hogy benne van?

Ja és: HURRÁ, így bement!
Ezek szerint az a ... tablespace méret volt a gond!
Köszönöm segítségedet, segítségeteket!

Azt hiszem futtatok egy sleep-et magamon :)
jó éjszakát mindenkinek!
dz.
Előzmény: halaloszto (2625)
halaloszto Creative Commons License 2007.10.04 0 0 2625
Kerdes ugye, hogy exportnal volt-e compress extents. a default az igen.

vajk
Előzmény: dorog.zultan (2624)
dorog.zultan Creative Commons License 2007.10.04 0 0 2624
6 Gb volt, ebből maradt 0,85%
ez bizony kevésnek tűnik (megnöveltem 12 Gb-ra)
bár ha jól tudom magától kellene növelnie magát
ha szükséges.
legalábbis ezt mondta a telepítést végző dba.

Előzmény: halaloszto (2623)
halaloszto Creative Commons License 2007.10.04 0 0 2623
Es mennyi hely van abban a TABSPC1 tablaterben?

Előzmény: dorog.zultan (2621)
dorog.zultan Creative Commons License 2007.10.04 0 0 2622
Megnéztem, lehet hogy mégis a tablespace-el
lesz a gond ugyanis 99.15% van
megnövelem aztán meglátjuk...
(Hogy mitől lett tele, az persze más kérdés...)

Előzmény: halaloszto (2620)
dorog.zultan Creative Commons License 2007.10.04 0 0 2621
Igen, léteznek és (szerintem) rendben is vannak.
A hibaüzenet:

IMP-00003: ORACLE error 1659 encountered
ORA-01659: unable to allocate MINEXTENTS beyond 1 in tablespace TABSPC1

(Hozzáteszem, hogy ua a sql hozta létre mind a 2 helyen a táblákat.)

dz
Előzmény: halaloszto (2620)
halaloszto Creative Commons License 2007.10.04 0 0 2620
tablaterek leteznek/rendben vannak? valami hibauzenet csak van...

v
Előzmény: dorog.zultan (2619)
dorog.zultan Creative Commons License 2007.10.04 0 0 2619
Akkor marad a tmp schema + insert.
Bár éppen valamiért egy szűz schemaba sem hajlandó bemenni
minden tábla, eddig x+1 szer bement, most nem.
ez egy ilyen nap...

Vagy valamit kihagytam volna:
imp system/jelszo@connect file=dump.dmp fromuser=schema1 touser=schema2 log=log.txt ignore=y rows=y

dz
Előzmény: tnsnames.ora (2618)
tnsnames.ora Creative Commons License 2007.10.04 0 0 2618
>Arre gondolsz, hogy először egy tmp schema-ba lementem, aztán meg insert...?
Igen erre gondoltam.
Mondjuk nem tudom a méreteket, de nagy adatbázisnál az imp önmagában nem egy sóhajtásnyi fáradság, plusz tud nagyon nyügös jószág is lenni. Azaz nem érdemes egy menetre összesűríteni mindent.
Ha az imp-formátum legalább ascii lenne, már akkor is pédául újabb lehetőség lenne pl.: az external táblák bevetése. Röptében tetszőlegesen tudnád transzformálni az adatokat. Dehát ugye bináris, mint tudjuk, és ezzel megvan kötve a kezed (szvsz).
Előzmény: dorog.zultan (2616)
tnsnames.ora Creative Commons License 2007.10.04 0 0 2617
+kiegészítés.

Az az implicit halvány sejtésem, hogy nincs lehetőség másik neked szimpatikus imp-et kérni. Ha lenne, sőt specifikálhatnád az output-formátumot, akkor én bizony nem egy újabb imp-et kérnék (feltéve, hogy kiesik a 10g-s sokkal hatékonyabb datapump, ugyanakkor mindenképp Oracle-eszközben gondolkozunk), hanem a metalinken megtalálható sql*unload-os extractot (ami _párhuzamosíthatóan_ és ascii-ben (nem bináris dumpban) teszi ki az adatokat valamint generál sql*loader scriptet az egész cucchoz). A dolog igazi nagy hátránya, hogy az Oracle*Export tud compress-álódni, így a fenti megoldás jelentősen több háttértárat igényelne önmagában.

De van ere is megoldás:
Unix alatt pl.: spool pipe -> compress
http://www.lazydba.com/oracle/0__116122.html
Windows alatt
Szimpla beépített röptömörítő

És a *.ctl-ekkel tiéd a világ... :o)

PS: Persze amit írtam az meglehet, hogy szürreális álomvilág (az én tapasztalatom szerint). Ha én kértem volna annó ilyet egy DBA-tól, hogy imp helyett proaktívan sql*unloadoljon, metalink guide alapján, azóta biztos melegebb éghajlaton lennék.
Előzmény: tnsnames.ora (2615)
dorog.zultan Creative Commons License 2007.10.04 0 0 2616
Én sem élvezetből csinálom...
Ha nem is egyszeri de nem üzemszerü (szerencsére)
Arre gondolsz, hogy először egy tmp schema-ba lementem,
aztán meg insert...?
Erre én is gondoltam, de macerásnak tünt,
reméltem van egyszerűbb megoldás.

De ha nincs más megoldás, akkor marad ez.
dz
Előzmény: tnsnames.ora (2615)
tnsnames.ora Creative Commons License 2007.10.04 0 0 2615
Emlékeim szerint, csak where típusú sorszűrési lehetőség van, oszlopszűrés nincs. Ha egyszeri migrációról van szó (és nincs 2x-es importnyi helyed a háttértáradon), akkor miért is nem 'pálya', hogy beimportálod a kapott cuccot és lemented az egészet neked megfelelő módon, a másodszori immáron végleges import elött? Mondjuk erősen szkeptikus vagyok az Oracle-import alatti triggereléssel (amennyiben meglehet, hogy nem szimpla dml-ekről van szó). Az viszont biztos, hogy én kerülném a hasonló 'élvezeteket'. ;)
Előzmény: dorog.zultan (2614)
dorog.zultan Creative Commons License 2007.10.04 0 0 2614
sziasztok
ismét lenne kérdésem.
Van egy schema amiben van sok tábla.
Mindegyik rendelkezik egyedi azonosítóval
(az összes ID névre hallgat)
Aztán van egy ugyan ilyen struktúráju dump állomány amit
egy ügyféltől hoztam át,
a cél az lenne hogy ezek a dump állományban lévő id-k
figyelmen kívül legyenek hagyva,
és a cél schemában keletkezzenek új id-k az import közben.
(mindegyik táblához van erre a célra trigger)
Van erre valami lehetőség?
(az imp -et használnám)

köszönöm
dz
tnsnames.ora Creative Commons License 2007.09.24 0 0 2613
Mondjuk én clobot használtam, annó, mert nekem voltak 32K-nál nagyobb sql-jeim is... :o)))
Előzmény: edesviz (2612)
edesviz Creative Commons License 2007.09.24 0 0 2612
Szia,
az ilyen paramétereknek tekinthető táblák forrása is verziókontroll szinten tárólható, sima varchar2 is elég szokott lenni, nics szükség clobra.

Édesviz


Előzmény: dorog.zultan (2605)
tnsnames.ora Creative Commons License 2007.09.23 0 0 2611
>>>>>>>>>>>>>>
de pl/sql tárolt eljárásaink vannak, így sajnos a cikkben leírt megoldást nem tudom használni.
>>>>>>>>>>>>>>

Ha nekem nem hiszel, itt az Oracle SQL-Reference, ami az Insertnél tárgyalja a témát:
http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/statements_9014.htm#SQLRF01604
Szóval, ha 10gr2-d van, lehet, hogy ez a legegyszerűbb és legkevésbé kellemetlen megoldás: persze félre ne érts, nem akarlak rábeszélni. :o)
Előzmény: dorog.zultan (2604)
tnsnames.ora Creative Commons License 2007.09.23 0 0 2610
Abszolút jogos. :o) Többek közt ezért sem tudott oly nagyon lázba hozni az Oracle*Forms, pedig annó a legjobb OH-oktatók próbálták meg lázba hozni a témát illetően.
Előzmény: NevemTeve (2609)
NevemTeve Creative Commons License 2007.09.23 0 0 2609
Off: Az igazi gányolás az, amikor mondjuk egy Oracle*Forms-ban fejlesztünk, valahogy úgy, hogy aranyos pici PL/SQL kóddarabkákat szórunk szét mindenféle eseménykezelőre, azután vagy emlékszünk rá, hogy hová mit tettünk, vagy nem...
Előzmény: tnsnames.ora (2608)
tnsnames.ora Creative Commons License 2007.09.23 0 0 2608
>>>>>>>>>>
igen, lehetne, de nekem nem tűnik átláthatónak, ha egy táblában vannak az sql-ek ha pl: javítani kell valamit több sqlben is, vagy hibakereséskor. persze ez szokás kérdése is.
>>>>>>>>>>

Naigen... :o) Ezért képezheti megfontolás tárgyát kimenni vele a file-rendszerbe.
És erről (is) beszéltem többtíz hozzászólással korábban a repository-témánál. Persze izlések és pofonok különböznek, ahogy elismertem akkor is.

Kicsiben olyan a dolog, mintha valaki VI-jal fejleszt Oracle alá store procedure-ket és triggereket. Láttam ilyet (még kezdőként annó, azóta hálistennek sose), nagyon gyorsan és profin ment, csak azon izgultam, hogy ne nekem kelljen majd a gányhegyben hibát vadásznom, annyira átláthatatlan lett a forrás.. Persze a zseni az, aki uralja a káoszt, mint tudjuk. :o))))
Előzmény: dorog.zultan (2605)
tnsnames.ora Creative Commons License 2007.09.23 0 0 2607
>"tárolt eljárásba 'beégetett' dinamikus sql-ek"
>így leírva kicsit falsul is cseng, tényleg :)

Én arra gondoltam: ahogy szó is volt már róla, execute immediate-t megfontoltan használ az ember. Nem performancia okból, hanem mert például fordítási időben nem derülnek ki az sql-ek szintaktikai hibái, pl.: string literálok miatt erősen kell tornászni, és nem olyan trivi oda-vissza konvertálni dinamikusból statikusba az sql-eket. És ahogy te is mondtad, az átláthatóságot is erősen tudja rongálni.
Előzmény: dorog.zultan (2604)
tnsnames.ora Creative Commons License 2007.09.23 0 0 2606
>nekem is, de pl/sql tárolt eljárásaink vannak, így sajnos a cikkben leírt megoldást nem tudom használni.

Nem látom be, miért ne tudnád. Valóban sql*plus-os a demó, anonym plsql blokkokkal, de ez nem azt jelenti, hogy csak ott tudod használni, hanem ez az a legkisebb közös nevező, ami minden Oracle-t használó ember egyformán el tud érni. (Még ha nem is akarja... ;)
Előzmény: dorog.zultan (2604)
dorog.zultan Creative Commons License 2007.09.23 0 0 2605
igen, lehetne, de
nekem nem tűnik átláthatónak,
ha egy táblában vannak az sql-ek
ha pl: javítani kell valamit több sqlben is,
vagy hibakereséskor.
persze ez szokás kérdése is.

dz
Előzmény: edesviz (2602)
dorog.zultan Creative Commons License 2007.09.23 0 0 2604
"Nekem tetszik a orafaq-os cikkben emlegetet 10gr2-s ficsőr is."
nekem is, de pl/sql tárolt eljárásaink vannak, így sajnos
a cikkben leírt megoldást nem tudom használni.

"tárolt eljárásba 'beégetett' dinamikus sql-ek"
így leírva kicsit falsul is cseng, tényleg :)

dz

Előzmény: tnsnames.ora (2603)
tnsnames.ora Creative Commons License 2007.09.22 0 0 2603
Nekem volt ilyesmihez keretrendszerem; és annó én könnyebbnek találtam kereshetőség/átláthatóság és szerkeszthetőség szempontjából a file-rendszerbeli sql-file-okat, mint az adatbázis clob-os sql-eket. Így paramétertől függően felolvastam db-be, vagy egyből db-ből futtattam (változatlanság esetén) az ilyen sql-eket.

Nekem tetszik a orafaq-os cikkben emlegetet 10gr2-s ficsőr is.

Hacsak nem numerikus adatok insertjéről van szó én kerülném a tárolt eljárásba 'beégetett' dinamikus sql-ek bármilyen formáját is.
Előzmény: edesviz (2602)
edesviz Creative Commons License 2007.09.22 0 0 2602
Szia,
ha már paraméterkent is hívhatnád az sql-eket, akkor akár a db-ben is tárolhatnád.
Édesviz
Előzmény: dorog.zultan (2593)
dorog.zultan Creative Commons License 2007.09.22 0 0 2601
persze nem jolly-joker, nem mindenhol használható resume next
de sok esetben igen jól tudna jönni...
Előzmény: Mbazsika (2600)
Mbazsika Creative Commons License 2007.09.22 0 0 2600
Azert eletszerubb (bar nem biztos, hogy a legpraktikusabb) szvsz a Begin-End blokk mint egy ilyen Resume Next utasitas, mert mi van akkor, ha a nagytomegu utasitasok nem hajthatoak kulon-kulon is vegre, hanem mondjuk van egy insert egy apa tablaba es utan a3 insert egy fiu tablaba. Ebben az esetben csak egy blokkent kezelhetoek, hiszen az apa insert hibaja utan nem lehet a fiu inserteket vegrehajtani, hanem a kovetkezo blokkon lehet csak folytatni.
Előzmény: dorog.zultan (2599)
dorog.zultan Creative Commons License 2007.09.22 0 0 2599
ok. jövő héten kipróbálom ezt a verziót is.
köszönöm a segítséget.
(halkan:
nem értem miért nincs ilyen utasítás (pl: resume next) beépítve,
kizárt hogy csak nekem van ilyen gondom...)
(de az is lehet, csak én érzem triviálisnak)

dz
Előzmény: Mbazsika (2598)
Mbazsika Creative Commons License 2007.09.22 0 0 2598
Szvsz file-kent, nem kell feleslegesen bonyolitani :-)
Előzmény: dorog.zultan (2597)
dorog.zultan Creative Commons License 2007.09.22 0 0 2597
és a létrehozandó szkripteket szkriptben tárolnád,
vagy egy táblában?
Előzmény: Mbazsika (2596)

Ha kedveled azért, ha nem azért nyomj egy lájkot a Fórumért!