Hi Raja Kumar,
If you don't know what are the differences use the parameters touser and fromuser
During importation
Oracle will recreate those tables
I think if you not use the ignore = y you will get error message since Oracle cannot
insert due to different table structure
Just guessing
If
The best method that I know is:
1) export from production.
2) drop user cascade in development or at least drop all tables.
3) create user in development.
4) import into development with indexes=n and constraint=n.
5) import again into development with rows = n and ignore = y.
Step 4 will build
To fine tune the suggestions aready made, you probably don't want to drop
all the table but just tables both in production and development/test. I
would create a list of tables exported from production via export / show and
use this to create a drop table script.
Mike
-Original
You will need to apply the structural changes before
importing for existing tables. If you want to make a
test db as copy of original one try cloning! It is
easy and quick.
--- [EMAIL PROTECTED] wrote:
I have 2 8i database out of which one is production
and the other is for
development and
Amar - I was just thinking about suggesting. And as a bonus, you can test
your backups, always a good idea.
Dennis Williams
DBA, 40%OCP
Lifetouch, Inc.
[EMAIL PROTECTED]
-Original Message-
Sent: Monday, January 06, 2003 11:10 AM
To: Multiple recipients of list ORACLE-L
You will need
Title: RE: Help with IMPort
Yeah ... yeah ... but after cloning will you submit the databases for a DNA test to prove that it is a true clone?
Oops ... Sorry ... I almost forgot we are talking databases here ... is cloning legal yet?
Raj
Dennis, Amar -
My interpretation of the environment was that dev/test has a different set
of tables, some of the tables match production table names but may not have
the same columns or data. In this case, my first suggestion to drop
matching table names from dev/test is insufficient. Maybe
Michael - Yeah but the developers are always whining about something anyway
:-) Just kidding. Yes, timing of the refresh can be an issue. We are looking
toward a staging environment. Now that will be identical to production. Then
we can execute a script that will create or modify tables and other
Title: RE: Help with Import
Dennis,
We do almost the same thing that you described.
We have a 140G database. Everyday we *clone* that production database and call it 'DAYOLD'. This database is used by app support to investigate data related issues and bugs. But a day before release, we
Raj - Thanks for sharing the details of how this method works in practice
for you.
Dennis Williams
DBA, 40%OCP
Lifetouch, Inc.
[EMAIL PROTECTED]
-Original Message-
Sent: Monday, January 06, 2003 1:44 PM
To: Multiple recipients of list ORACLE-L
Dennis,
We do almost the same
:
Sent by: Subject: RE: Help with Import
[EMAIL PROTECTED
11 matches
Mail list logo
