Egy módszer lehet még a rossz tárbecslés kivédésre a "-szor kettő" mechanizmus... :o)) (Igaz ahhoz is kell némi számolás, mert közel sem garantált minden esetre az elégségesség)
Azert kerdeztem a compresst, mert gyakori hiba a helyigeny rossz becslese. Megsaccolod hogy mennyi adatrol beszelunk, pl a dmp file merete alapjan. Ha volt compress, akkor minden obj egy extent-be fog kerulni, es a becsels viszonylag jo, kicsi lesz a overhead. De ha nincs compress, akkor senki nem tudhatja hogy igazibol mekkora helyre lesz szukseg, hacsak nem kerdezed le az igazi helyfoglalast a forras oldalon.
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.
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...)
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...
>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).
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.
É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.
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'. ;)
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)
>>>>>>>>>>>>>> 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)
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.
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...
>>>>>>>>>> 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))))
>"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.
>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... ;)
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.
"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 :)
