Path: news.easynews.com!newsfeed1.easynews.com!easynews.com!easynews!news-out.cwix.com!newsfeed.cwix.com!newsfeed.icl.net!newsfeed.fjserv.net!proxad.net!proxad.net!newspeer1-gui.server.ntli.net!ntli.net!newsfep4-gui.server.ntli.net.POSTED!53ab2750!not-for-mail From: "David Sharples" Newsgroups: comp.databases.oracle.server References: Subject: Re: moving tables from to new tablespace. Lines: 52 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: Date: Sun, 2 Feb 2003 23:51:44 -0000 NNTP-Posting-Host: 80.2.240.57 X-Complaints-To: abuse@ntlworld.com X-Trace: newsfep4-gui.server.ntli.net 1044229911 80.2.240.57 (Sun, 02 Feb 2003 23:51:51 GMT) NNTP-Posting-Date: Sun, 02 Feb 2003 23:51:51 GMT Organization: ntl Cablemodem News Service Xref: newsfeed1.easynews.com comp.databases.oracle.server:174537 X-Received-Date: Sun, 02 Feb 2003 16:51:15 MST (news.easynews.com) sorry, ignore my crap "David Sharples" wrote in message news:Ibg%9.3091$Uo5.36682@newsfep4-gui.server.ntli.net... > you can import into the new db then move the tables into the different > tablespaces. This will nto invalidate your indexes because you are not even > touching them. > > > "Glen A Stromquist" wrote in message > news:Njf%9.71834$c41.2292908@news2.telusplanet.net... > > I am replacing a machine with a small database on it, so far I have > created > > a "blank" database on the new machine with just the tablespaces matching > > the one I'm going to replicate. The twist to this is that on the original > > database the tables somehow wound up in the index tablespace when it was > > built by the people who put the application in place. > > > > Whats the best way for me to get this rectified? I was thinking just > import > > it then issue a alter table move tablespace for all the affected tables, > > but I've never had to use this before, I am assuming that once this was > > done I'd have to either rebuild or recreate all the indexes in the schema > > as well? > > > > Or should I create all of the tables in the new schema first, then import? > > I actually did a quick test run of this, but got dozens of constraint > error > > messages, so I'd also have to write a script to disable all the > constraints > > before doing the import. > > > > Time is of the essence for this, as this is supposed to be a 24-7 db and > > although I picked a "quiet" time to do this, I want to keep it as short as > > possible, which means taking an export from the one in place now just > > before I take it offline and importing it into the new one. > > > > anyone have any better ideas? > > > > TIA > > > > > >