| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: How to precreate tables for migration?
Hey Don!
GREAT info! I'm wiping out my test DB right now to try it out. I already have the scripts to create the TSs (I've learned a little in three years), so that's no biggie. I'll letcha know what happens.
THANKS! :)
Rich Jesse System/Database Administrator Rich.Jesse_at_qtiworld.com Quad/Tech International, Sussex, WI USA
-----Original Message-----
Sent: Thursday, July 05, 2001 14:11
To: Multiple recipients of list ORACLE-L
As I impose order on our servers, (moving from project-managed to
dba-managed
db's) I perform this sort of task for individual schemas. The short form is
the
same as yours except:
3.5) create schemas where tables or tablespace assignments will change. 4.5) create tables that are to have storage parameters different from the source.
... and ...
5) import using IGNORE=Y parameter
Imp fills the tables as they exist, or creates them using the info in the
export
file where they do not exist. After all, if you're migrating all the tables
you
pre-created should be "clean" at the beginning, so you won't get duplicate
rows
and DESTROY is hardly necessary. One caveat -- IIRC you don't need to
create
all the tables, but you must create all the tablespaces in order to use this
method. Or this could be a local effect as my new servers have different
data
file paths.
It is useful to compose the creation in scripts, and compose a script to
destroy
the structures, in case your new storage parameters are flawed somehow and
the
import ends badly. That way you can iterate more easily. In my shop we
move
off the old server and into a test server first, then when the iterations
are
done I can replicate the refined procedure for production. In a few cases
the
project managers failed to move the db to production when they went live, so
we
move to different schemas on the same server first, then drop one and move
the
data (and client connections) to production.
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Jesse, Rich
INET: Rich.Jesse_at_qtiworld.com
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists --------------------------------------------------------------------To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). Received on Thu Jul 05 2001 - 14:49:52 CDT
 |
 |