I've missed the version, and possibly if this has already been mentioned bu=
t I haven't seen DBMS_METADATA listed as an option for you if you are on 9i=
.=20
I like the B&R test as well.=20
Niall Litchfield
Oracle DBA
Audit Commission
+44 117 975 7805=20
> -----Original Message-----
> From: Gsais_at_co.palm-beach.fl.us=20
> Sent: 18 February 2004 20:46
> To: Gsais_at_co.palm-beach.fl.us; oracle-l_at_freelists.org
> Subject: Re: PreCreate Oracle Tables
>=20
>=20
> Thank you for your response. I forgot to mention, its not an exact
> copy. I need to move some tables, indexes, change storage,=20
> and exclude
> one schema. I do like option #5, can never test=20
> backup/recovery enough!
> But, if you had to choose 2 or 3, which would you choose?
> >>> Daniel.Fink_at_Sun.COM 2/18/2004 3:34:09 PM >>>
> Don't forget option 5) Use a backup from production and perform a full
> recovery. It not only creates the database, it tests your production
> backups and refreshes your recovery skills.
>=20
> If there are not any changes to the db, I like 4 as it is very quick
> and
> painless.
>=20
>=20
> Gene Sais wrote:
>=20
> > When copying a database, what are the best practices?
> >
> > 1) I typically, perform a full export from db A, create db B, import
> > dump from A into B.
> >
> > 2) Same as 1, but precreate tables with indexfile and then import
> > ignore=3Dy.
> >
> > 3) Same as 1, but precreate tables with dynamic sql (create table
> emp
> > as select * from emp_at_dblink where 1=3D2), then import ignore=3Dy.
> >
> > 4) Copy datafiles, recreate controlfile and rename db.
> >
> > I am looking to precreate the objects before importing the data and
> in
> > the past, I have used #2, but #3 is more flexible and requires no
> > editing of indexfile.
> >
> > Are they any disadvantages of using #3 from #2?
> >
> > Thanks,
> > Gene
> >
> > ----------------------------------------------------------------
> > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > ----------------------------------------------------------------
> > To unsubscribe send email to: oracle-l-request_at_freelists.org
> > put 'unsubscribe' in the subject line.
> > --
> > Archives are at http://www.freelists.org/archives/oracle-l/
> > FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> > -----------------------------------------------------------------
>=20
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request_at_freelists.org
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
>=20
>=20
>=20
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request_at_freelists.org
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
>=20
>=20
This email contains information intended for
the addressee only. It may be confidential
and may be the subject of legal and/or
professional privilege. Any dissemination,
distribution, copyright or use of this
communication without prior permission of
the sender is strictly prohibited.
Please see the official ORACLE-L FAQ:
http://www.orafaq.com
To unsubscribe send email to: oracle-l-request_at_freelists.org
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Received on Thu Feb 19 2004 - 04:19:44 CST
