Path: news.f.de.plusline.net!news-fra1.dfn.de!newsfeed.hanau.net!news.tiscali.de!tiscali!newsfeed1.ip.tiscali.net!proxad.net!64.233.178.134.MISMATCH!postnews.google.com!y80g2000hsf.googlegroups.com!not-for-mail From: sam Newsgroups: comp.databases.oracle.server Subject: Re: import issue Date: 27 Apr 2007 15:56:11 -0700 Organization: http://groups.google.com Lines: 44 Message-ID: <1177714571.800906.247530@y80g2000hsf.googlegroups.com> References: <1177688327.625382.146640@r30g2000prh.googlegroups.com> <1177706677.114242.155230@n15g2000prd.googlegroups.com> NNTP-Posting-Host: 201.28.39.227 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1177714572 15417 127.0.0.1 (27 Apr 2007 22:56:12 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 27 Apr 2007 22:56:12 +0000 (UTC) In-Reply-To: <1177706677.114242.155230@n15g2000prd.googlegroups.com> User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3,gzip(gfe),gzip(gfe) X-HTTP-Via: 1.1 kenny:8080 (squid/2.5.STABLE9) Complaints-To: groups-abuse@google.com Injection-Info: y80g2000hsf.googlegroups.com; posting-host=201.28.39.227; posting-account=4T9VIQ0AAABd-BGdA5Ui77_gYs-6oHzA Xref: news.f.de.plusline.net comp.databases.oracle.server:197039 On 27 abr, 17:44, joel garry wrote: > On Apr 27, 8:38 am, sam wrote: > > > I receive a dump of a schema from an external db and I got to import > > it on my db. This have to be done on a daily basis. > > Problem: There are objects on the dump specifically mapped to various > > tablespaces, that did not exists on my db, and when I do the import > > with the 'fromuser' 'touser', it does the imp from some objects, > > mapping them from the default tablespace of the user on my db, but it > > fails on the tables with *lobs... > > The first thing that come to mind is use an indexfile, create the > > structure and then perform the import, 'but' as this have to be > > performed on a daily basis, it could lead to a big problem when > > dealing with changes on the other side, this is a critical db and I > > cannot risk to have an error on this imp due to a change made on the > > structure of the other db... > > Maybe I am missing something, I made a workaround here, but id there > > some 'correct' way of doing that? > > One way would be to use the indexfile and have a script that handles > checking for proper tablespaces, if new ones are needed create them > and let you know you need to pay some manual attention to the old > ones. Shouldn't be too difficult given a modicum of shell or perl > expertise. A lot depends on the specifics, such as which platform, do > you have enough disk space to have new tablespaces for some period > until you can look at it, the range of changes to be handled, how you > handle stats creation, how long all this stuff takes, etc. > > jg > -- > @home.com is bogus. > "The only thing I can compare it to is to flying in dreams." - Peter > Diamandis, soon to be offering microgravity flights at $3500/per > through the Sharper Image - rides formerly known as the Vomit Comet. Yes, actually my workaround is a perl script that looks through the dump and cleans all the tablespaces definitions, doing this on the index file sure is a better approach, I am working on this right now, but wish I could do this using only oracle standard tools Looks like even the new data pump ultility have some limitations regarding lobs and raw data types http://www.oracle.com/technology/deploy/availability/htdocs/xtts.htm --(Transportable Tablespace Considerations)